Aula 18 Métricas e Anomalias de Modularidade

Transcrição

1 Aula 18 Métricas e Anomalias de Modularidade Marcos Silva LES/DI/PUC-Rio Maio 2010 Hoje... Introdução à Métricas Tipos de Métricas Métricas de Tamanho Métricas de Complexidade Métricas de Acoplamento Métricas de Coesão Ferramentas para contagem de Métricas Introdução a Anomalias 2/32 1

2 Métricas Existem diversas métricas que possamos executar a medição de software. Porém Por que medir? O que medir? Quando medir? 3/32 Métricas Não se pode controlar o que não se pode medir. (Morris A. Cohen) As métricas são necessárias para analisar os níveis de qualidade do design do software. Provê insights valiosos sobre particularidades do software Vêm se tornando populares e bem utilizadas Podem oferecer aumento no diagnóstico de sintomas de problemas Como algumas medições revelam problemas no design? 4/32 2

3 Métricas As métricas de software ajudam a entender o comportamento e funcionamento de processos, produtos e serviços de software. Podem se utilizadas para tomar decisões e determinar: o estabelecimento de padrões metas e critérios de aceitação controlar processo produtos e serviços de software prever valores de atributos aperfeiçoar o processo de desenvolvimento gerenciar contratos de software indicar a qualidade de um produto de software avaliar a produtividade do processo entre outras 5/32 Métricas Existem diversas métricas para diferentes tipos de necessidades Unidade de Tipo de Métrica Nome Medida Descrição Básica Esforço Hora Horas utilizadas por uma pessoa em determinada tarefa Básica Pontos por Função PF Tamanho do software, em Pontos por Função Básica Casos de Uso Caso de Uso Quantidade de casos de uso em um sistema Básica Pontos de Casos de Uso UCP Use Case Points, pontos totais somados dos casos de uso, abrangendo a complexidade Básica Linhas de Código KLOC Kilo Lines of Codes - Linhas de código Produtividade Horas por Ponto por Função Hrs / PF Horas por ponto de função Produtividade Linhas de Código por Hora LOC / Hr Linhas de Código desenvolvidas por hora Bugs encontrado em cada release, em Qualidade Bugs por Release B / R média Qualidade Bugs por Ponto por Função B / PF Bugs por Ponto por Função Bugs entregues por mês pela equipe do Qualidade Bugs por Mês B / Mês projeto Tarefas no prazo dividido por tarefas Pontualidade Índice de Pontualidade % entregues fora do prazo 6/32 3

4 Tipos de Métricas Métricas podem ser utilizadas de forma: Direta Exemplo: tamanho = quantidade de linhas de código Indireta ou Derivada Exemplo: densidade de defeitos = nº de defeitos / tamanho Pedição Predição Exemplo: esforço para desenvolver um software = nº de pontos de função 7/32 Diferentes métricas e contagens nominal Sem ordem, simplesmente com base em nomes (linguagem: 3GL, 4GL) ordinal Ordenada, mas sem comparação quantitativa (capacidade do programador: baixa, média, alta) intervalar Define o valor entre determinados valores definidos (capacidade do programador: entre 55 e 75 pontos de 100) ) racional O software proposto é duas vezes maior que o software desenvolvido até então Absoluta O software possui linhas de código 8/32 4

5 Métricas de Software Métricas de software tem como foco o software funcional e orientado a objetos Possível fazer predição de manutenibilidade e reusabilidade através de atributos de software bem conhecidos: Tamanho Complexidade Acoplamento Coesão Métricas estáticas 9/32 Métricas de Tamanho As métricas de tamanho tratam de diferentes aspectos do tamanho do sistema As métricas de tamanho mais comuns são: Linhas de Código (LOC) Número de Atributos (variáveis) (NOA) Número de Operações (funções) (NOM) 10 /32 5

6 Ex 1: Número de Linhas de Código (LOC) 01 bool searchlist( Comentários e espaços 02 char *cmd, // command string em branco devem ser 03 char **list, // array of strings contabilizados? 04 unsigned n) // max. no. of elements 05 { 06 unsigned i; // search entire list for command string 07 for ( unsigned i=0; i < n; i++ ) // for each element 08 { 09 if ( stricmp( cmd, list[i]) == 0) // matched? 10 { 11 return true; // found match 12 } 13 } } return false; // no match 11 /32 Ex 2: Número de Linhas de Código (LOC) bool searchlist( char *cmd, char **list, unsigned n ) { // search entire list for command string for(unsigned i=0; i < n; i++) if ( stricmp(cmd, list[i]) == 0) return true; return false; } Ex1 - escrito de forma verbosa e possui LOC = 15 Ex2 - escrito de forma concisa e possui LOC = 5 Como existem diferentes formas de observar a métrica são necessárias regras que definam a forma adequada de contar Em tamanho, o estilo de programação influencia na contagem 12 /32 6

7 Métricas de Complexidade Complexidade Ciclomática: é uma das métricas mais amplamente utilizadas em se tratando de métricas estáticas 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 arestas do gráfico N = o número de nós do gráfico p = o número de componentes conectados 13 /32 Benefícios da Métrica de Complexidade Estudos mostram uma correlação entre a complexidade Ciclomática de um programa e sua freqüência de erro Uma baixa complexidade Ciclomática contribui para a facilidade de compreensão de um programa 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 Complexidade Ciclomática Avaliação de Risco Programa simples, sem muito risco Complexo, risco moderado Complexo, Programa de alto risco. maior que 50 Programa quase impossível de ser testado. (altíssimo risco) 14 /32 7

8 Exemplo de medição da complexidade E=8 n=7 p=2 CC=5 if ( a == b ) { if ( a < b) { menor = a ; } else { menor = b ; } } else { menor = \0 ; } Cada nó corresponde a uma bloco sequencial de código Cada aresta corresponde a um caminho criado a partir de uma estrutura de decisão 15 /32 Revisão: Acoplamento O acoplamento é uma medida do volume, da dificuldade de assegurar a corretude e do risco de erro como conseqüência de se estabelecer uma instância de relacionamento (conexão) entre cliente e servidor. Exemplos de relacionamento: no caso de variáveis globais é um acesso a uma dessas variáveis no caso de funções é uma chamada no caso de um módulo é um #include Mar 2009 Alessandro Garcia LES/DI/PUC-Rio 16 /32 8

9 Influência de acoplamento no... O risco de erro e a dificuldade de assegurar corretude está relacionada com o esforço humano para assegurar a corretude será menos difícil quanto mais puder ser verificado pelo compilador ou por alguma ferramenta de verificação será mais difícil quanto mais depender da ação humana Exemplo, na função double * OpMatriz( int dimlinhas, int dimcolunas, int tamlinhas, int tamcolunas, double * pmatriz ) em uma chamada qualquer permutação dos quatro primeiros argumentos é válida do ponto de vista do compilador A manutenibilidade: qualquer mudança na implementação do conector, afeta os módulos clientes A reusabilidade: o módulo cliente precisa depender de mais detalhes do módulo servidor sendo reusado 17 /32 Métricas de acomplamento Sistemas que precisam ter independência entre suas partes! Comum adotar a estratégia de módulos com forte independência de outros módulos e com forte unicidade Ou seja, sistemas com fraco acoplamento entre subsistemas com cada subsistema é fortemente coeso Como minimizar dependências e maximizar o reuso? Atribuir responsabilidades de forma a minimizar o acoplamento 18 /32 9

10 Como medir acoplamento? Como medir acoplamento? Baixo Acoplamento entre Módulos Alto Acoplamento entre Módulos 19 /32 Como medir acoplamento? Algumas métricas para medir acoplamento: Acoplamento entre módulos: mede o quão fortemente os módulos estão dependentes e Acoplamento intra-módulos: mede o quão fortemente estão dependentes suas funções e atributos entre si Nos quais são contabilizados o número de tipos utilizados em variáveis, parâmetros, retornos e etc. Acoplamento entre dados abstratos: mede o número total de tipos referenciados na declaração das variáveis Acoplamento entre funções: mede o número de funções as quais uma outra função é dependente Volume de acoplamento de fuñção: mede o número de tipos existentes numa função (retorno, tipos e parâmetros) 20 /32 10

11 Revisão: Coesão A coesão avalia o inter-relacionamento entre os elementos que constituem uma interface ou um conector quanto mais forte for o inter-relacionamento, melhor será a coesão incidental os elementos estão juntos somente por conveniência ou falta de cuidado do programador lógica os elementos possuem alguma funcionalidade correlata mas não existe uma definição única e bem delimitada para o conjunto temporal os elementos interdependem somente pelo fato de serem manipulados em um mesmo intervalo de tempo procedural os elementos interdependem pelo fato de serem ativados um após ao outro funcional os elementos definem uma única função que implementa exatamente um conceito abstração de dados os elementos definem uma único tipo abstrato de dados Na verdade, é um caso particular de coesão funcional Mar 2009 Alessandro Garcia LES/DI/PUC-Rio 21 /32 Métricas de coesão Cohesão significa dizer que um certo módulo possui elementos (funções, variáveis, etc) relacionados a ele. Falta de coesão significa que um módulo (ou mesmo um subconjunto do mesmo) está fazendo coisas além de sua responsabilidade. De forma geral, a falta de coesão não impacta na funcionalidade do módulo (nem do sistema) Entretanto, o sistema acabará com problemas de: legibilidade, entendimento e gerência do código dado que as funcionalidades estão espalhadas e acabaram em lugares (módulos) errados 22 /32 11

12 Falta de Coesão Falta de Coesão entre métodos (funções) (LCOM) Possui três formatos: LCOM 1: com base no acesso as variáveis LCOM 2: versão melhorada de LCOM1 e LCOM 3: melhoria do LCOM1 e LCOM2 proposta por Henderson-Sellers. NOTA: As métricas de coesão são muito mais utilizadas em sistemas orientados a objetos (classes, métodos e atributos) 23 /32 Falta de Coesão: Forma 1 LCOM 1: Tomamos então duas variáveis, P e Q Escolhe-se pares de funções criando um conjunto de variáveis acessadas para cada uma delas. Caso os conjuntos sejam disjuntos incrementa-se P. Caso contrário, para cada variável compartilhada incrementase Q RESULTADO = (P > Q)? (P - Q) : 0 Um valor baixo indica alta coesão entre as funções. Também pode indicar que o módulo possui bom nível reusabilidade e design 24 /32 12

13 Falta de Coesão: Forma 2 LCOM 2: Definidos m: número de métodos (funções) de uma classe (módulo) a: número de atributos (variáveis) de uma classe ma: número de métodos (funções) que acessam um dado atributo (variável) A. soma(ma): soma de todos os valores para ma no módulo. RESULTADO = 1- soma(ma)/(m*a) Caso o número de funções ou variáveis for 0, então: RESULTADO = 0 25 /32 Falta de Coesão: Forma 3 LCOM 3 é definida da seguinte forma: RESULTADO = (m - sum(ma)/a) ) / (m-1) m, a, ma soma(ma) definidas como em LCOM2 LCOM 3 varia entre 0 e 2 LCOM3 > 1 indica falta de coesão e é considerado um problema. Nesse caso é melhor que a classe seja particionada em duas ou mais classes. Se existe apenas um método na classe RESULTADO = 0. O mesmo ocorre se não existirem variáveis na classe 26 /32 13

14 Ferramentas A grande maioria das ferramentas para medição de software funcional utilizam-se de análise estática Resource Standard Metrics Versão 7.75 (bem estável) Possui versão free Website: msquaredtechnologies.com/m2rsm Diversas esasferramentas e podem ser encontradas em: spinroot.com/static/ 27 /32 Sintomas de Problemas Assim como um médico pode usar os números extraídos de exames para diagnosticar doenças e prescrever tratamentos números de plaquetas ph taxas de glicose e colesterol e outras centenas de índices possíveis Desenvolvedores também podem detectar sintomas de problemas de design por meio da análise numérica de informações extraídas do código-fonte. 28 /32 14

15 Problemas de Design Existem diversos tipos de problemas no design Veremos Anomalias de Modularidade Code Smells Geralmente levam aos padrões de refatoração Podemos encontrar pontos de refatoração à partir de métricas coletadas no código-fonte 29 /32 Aula 16 Métricas e Anomalias de Modularidade (continua...) Marcos Silva Marcos Silva LES/DI/PUC-Rio Maio