Buscar

Automatos Complexidade em qualidade de software

Prévia do material em texto

CENTRO UNIVERSITÁRIO CARIOCA 
Elton Araujo oliveira
Vladimir
Thaís
Eduardo
Felipe Samuel
Complexidade como métrica de qualidade de software
RIO DE JANEIRO
2014
�
SUMÁRIO
�
�
Introdução
O que é Complexidade
 A complexidade de um algoritmo consiste na quantidade de “trabalho” necessário para a sua execução, expressa em função das operações fundamenteis, as quais variam de acordo com o algoritmo, e em função do volume dados. 
 A preocupação com a complexidade de algoritmos é fundamental para projetar algoritmos eficientes. Podemos desenvolver um algoritmo e depois analisar a sua complexidade para verificar a sua eficiência. Mas o melhor ainda é ter a preocupação de projetar algoritmos eficientes desde a sua concepção. Por exemplo, um programa pode ter tempo de execução T(n) = n^2+ n + 1. A unidade de T(n) é em principio instrução executada. Uma instrução neste contexto é uma sequência de operações cujo tempo 
de execução pode ser considerado constante (de certa forma, cada “passo” do algoritmo). 
Por exemplo, o algoritmo a abaixo:
void somavet (int v[n], int *k) {
int i;
*k=0;
for (i=0; i<n; i++)
*k = (*k) + v[i]; }
 Sendo v a entrada, de tamanho n, pode-se ver facilmente que a soma k+v[i] será efetuada n vezes. Consequentemente, T(n) = n+1, incluindo o passo de inicialização. O tempo de execução (em instruções) variará conforme variar n, numa proporção linear. No entanto, como já se frisou, o tempo de execução vai depender de outros fatores, ligados à máquina, linguagens usadas, etc., e mesmo, por vezes, é função de aspectos adicionais de uma particular entrada e não apenas do seu tamanho.
 
.Qualidade de Software
 Qualidade, de forma simplista, significa que o produto deve esta de acordo com a especificação.
• Problemas:
– Tensão entre requisitos do cliente:
• Eficiência, confiança, etc.
– …e os requisitos do desenvolvedor:
• Reusabilidade, Manutenibilidade
– Especificações podem ser ambíguas, incompletas e inconsistentes.
 Visa assegurar que o nível de qualidade requerido é atingido pelo software envolve a definição apropriada de procedimentos e padrões de qualidade. Deve proporcionar uma cultura da qualidade onde esta seja vista como uma responsabilidade de cada um dos envolvidos, não é apenas reduzir defeitos, mas garantir outras qualidades do produto. Complexidade 
 Tamanho dos métodos é muito recomendado evitar funções longas (mais do que 100 linhas), porque funções longas têm muitas desvantagens:
• Se uma função for muito longa, pode ser difícil sua compreensão. Geralmente, pode
se dizer que uma função não deveria ser mais longa que duas páginas, visto que isto
é quanto se pode compreender de uma única vez.
• Funções complexas são difíceis de se testar. Se uma função consiste em 15 declarações “if” aninhados, então há 215 (ou 32768) diferentes ramos para se testar em uma única função.
Número de declarações executáveis por método
 O número de máximo de declarações por método deve ser menor que 10, porque métodos com muitos declarações são difíceis de se entender.
Número de métodos por classe
 É altamente recomendado definir o número de máximo de métodos por classe em 20, porque é importante ter uma implementação clara e muitos métodos aumentam a complexidade e obscurecem a compreensão.
Número de if-then-else, while, for, try and switch aninhados
 O número de máximo de declarações if-then-else, while, for, try and switch aninhados por classe devem ser menor que 4, porque se um número maior de declarações aninhadas são usadas, mais difícil se torna manter um claro entendimento.15 /20
 Número de Caminhos Estáticos
 O número de caminhos estáticos de um método, isto é, o limite máximo de todos os possíveis caminhos de um método, deve ser menor que 20, porque o número de caminhas estáticos está diretamente relacionado a facilidade de teste do software.
Resposta de uma Classe (RFC)
 O número de máximo de métodos que podem ser invocados em resposta a uma mensagem deve ser 20. A RFC é a contagem de todos os métodos que podem ser invocados em resposta a uma mensagem de um objeto de uma classe ou por algum método da classe. Isto inclui todos os métodos acessíveis dentro da hierarquia da classe.
Esta métrica foca na combinação da complexidade de uma classe através do número de métodos e a quantidade de comunicação com outras classes. Quanto maior for o número de métodos de uma classe que podem ser invocados através de mensagens, maior a complexidade da classe. Se um grande número de métodos podem ser invocados em resposta a uma mensagem, o teste e depuração da classe se torna complexo porque irá requerer um conhecimento mais detalhado da mesma por parte de quem efetua os testes.
A elaboração de uma lista com os piores casos possíveis de respostas ajudará na distribuição apropriada do tempo de teste.
Complexidade Ciclomática de métodos
 Complexidade Ciclomática é a métrica mais amplamente utilizada, membro da classe de métricas estáticas de software. Introduzida por Thomas McCabe em 1976, mede o número caminhos linearmente independentes de um módulo de programa. Esta medida provê um único número ordinal que pode ser comparado à complexidade de outros programas. A Complexidade Ciclomática é frequentemente referenciada simplesmente como complexidade do programa, ou como complexidade de McCabe. Pretende ser independente da linguagem e do formato da linguagem.
A complexidade ciclomática de um módulo de software é calculada a partir de um gráfico conectado do módulo:
Complexidade Ciclomática (CC) = E - N + p
Onde E = o número de extremidades do gráfico
N = o número de nós do gráfico
p = o número de componentes conectados
Estudos mostram uma correlação entre a complexidade Ciclomática de um programa e sua frequência de erro. Uma baixa complexidade Ciclomática contribui para a facilidade de compreensão de um programa e indica que este é acessível a modificações com risco menor que um programa mais complexo. A complexidade Ciclomática de um módulo também é um forte indicador de sua facilidade de teste.
Avaliação de Risco
1-10 Programa simples, sem muito risco.
11-20 Complexo, risco moderado.
21-50 Complexo, Programa de alto risco.
maior que 50 Programa quase impossível de ser testado.
(altíssimo risco)16 /20
Exemplo: Profundidade da estrutura de herança
 Representa o número de derivações da mais afastada classe de base (origem) até esta classe. Um valor elevado desta métrica pode indicar que a classe depende de funcionalidade acumulada, que potencialmente dificulta a compreensão da classe.
Quanto mais em baixo uma classe está dentro da hierarquia, maior o número de métodos que provável herdará, o que torna muito mais complexo predizer seu comportamento. Estruturas com ramos mais longos (profundos) ocasionam uma maior complexidade de projeto, visto que mais métodos e classes estão envolvidos, mas temos também um maior potencial para reuso de métodos herdados. Maior profundidade de Herança indica um compromisso entre um incremento na complexidade e um incremento em reuso. Evite profundidade da estrutura de herança maior que 5.
Conclusão
Fontes Bibliográficas:
http://w3.ualg.pt/~hshah/algoritmos/aula8/Aula8.htm
http://www.ime.usp.br/~song/mac5710/slides/01complex.pdf
http://www.univasf.edu.br/~marcelo.linder/arquivos_ed1/aulas/aula21.pdf
http://www.dimap.ufrn.br/~jair/ES/slides/Qualidade.pdf
http://www.angelfire.com/nt2/softwarequality/QualitySoftware.pdf

Continue navegando