Aula 18 Métricas e Anomalias de Modularidade

Aula 18

Métricas e Anomalias de

Modularidade

Hoje...

• Ferramentas para contagem de Métricas

Métricas

• Existem diversas métricas que possamos executar a medição de software. Porém…

• Por que medir?

• O que medir? Q d di ?

• Quando medir?

Set 2009 Alessandro Garcia © LES/DI/PUC-Rio 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

P d f t di ó ti d i t d

• Podem oferecer aumento no diagnóstico de sintomas de problemas

• Como algumas medições revelam problemas no design?

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

Set 2009 Alessandro Garcia © LES/DI/PUC-Rio 5 /32

Métricas

• Existem diversas métricas para diferentes tipos de necessidades

Tipo de Métrica Nome

Unidade de

Medida Descrição 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 Qualidade Bugs por Release B / R

Bugs encontrado em cada release, em média

Qualidade Bugs por Ponto por Função B / PF Bugs por Ponto por Função Qualidade Bugs por Mês B / Mês

Bugs entregues por mês pela equipe do projeto

Pontualidade Índice de Pontualidade %

Tarefas no prazo dividido por tarefas entregues fora do prazo

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 P edição

• Predição

– Exemplo: esforço para desenvolver um software = nº de pontos de função

Set 2009 Alessandro Garcia © LES/DI/PUC-Rio 7 /32

Diferentes métricas e contagens

– 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)( p p g p )

• racional

– O software proposto é duas vezes maior que o software desenvolvido até então

• Absoluta

– O software possui 350.000 linhas de código

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 Métricas estáticas • Acoplamento • Coesão

Set 2009 Alessandro Garcia © LES/DI/PUC-Rio 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)

Ex 1: Número de Linhas de Código (LOC)

char*cmd, // command string

char**list, // array of strings

unsignedn) // max. no. of elements

Comentários e espaços em branco devem ser contabilizados? 01 02 03 04 { unsignedi;

// search entire list for command string

for ( unsignedi=0; i < n; i++ ) // for each element {

if( stricmp( cmd, list[i]) == 0)// matched? {

returntrue; // found match

05 06 07 08 09 10

11 returntrue; // found match

} }

returnfalse; // no match }

Set 2009 Alessandro Garcia © LES/DI/PUC-Rio 11 /32

11 12 13 14 15

Ex 2: Número de Linhas de Código (LOC)

// search entire list for command string

for(unsignedi=0; i < n; i++)

if( stricmp(cmd, list[i]) == 0) returntrue; 01

02 03

returnfalse; }

• Ex1 - escrito de forma “verbosa” e possui LOC = 15

• Ex2 - escrito de forma concisa e possui LOC = 5 é

04 05

• 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

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áficoN o número de nós do gráfico

– p = o número de componentes conectados

Set 2009 Alessandro Garcia © LES/DI/PUC-Rio 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

01 ‐ 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)

Exemplo de medição da complexidade

• 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

Set 2009 Alessandro Garcia © LES/DI/PUC-Rio 15 /32

Revisão: Acoplamento

• O acoplamentoé uma medida do volume, da dificuldade de assegurar a corretudee do risco de errocomo 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 acessoa uma dessas variáveis

– no caso de funções é uma chamada

Mar 2009 Alessandro Garcia © LES/DI/PUC-Rio 16 /32

Influência de acoplamento no...

• O risco de erro e a dificuldade de assegurar corretude está relacionada com o esforço humanopara 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

Set 2009 Alessandro Garcia © LES/DI/PUC-Rio 17 /32

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

Métricas de acomplamento

• Sistemas que precisam ter independência entre suas partes!

• Comum adotar a estratégia de módulos com forte g independência de outros módulos e com forte unicidade

• Ou seja, sistemas com fraco acoplamento entre sub-sistemas com cada subsistema é fortemente coeso

• Como minimizar dependências e maximizar o reuso?

• Como minimizar dependências e maximizar o reuso?

– Atribuir responsabilidades de forma a minimizar o

Como medir acoplamento?

• Como medir acoplamento?

Set 2009 Alessandro Garcia © LES/DI/PUC-Rio 19 /32

Baixo Acoplamento entre Módulos Alto Acoplamento entre Módulos

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 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)

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 incidentalos elementos estão juntos somente por conveniência ou falta – incidentalos elementos estão juntos somente por conveniência ou falta

de cuidado do programador

– lógicaos elementos possuem alguma funcionalidade correlata mas não existe uma definição única e bem delimitada para o conjunto

– temporalos elementos interdependem somente pelo fato de serem manipulados em um mesmo intervalo de tempo

– proceduralos elementos interdependem pelo fato de serem ativados um após ao outro

Mar 2009 Alessandro Garcia © LES/DI/PUC-Rio 21 /32

um após ao outro

– funcionalos elementos definem uma única função que implementa exatamente um conceito

– abstração de dadosos elementos definem uma único tipo abstrato de dados

• Na verdade, é um caso particular de coesão funcional

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

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

H d S ll Henderson-Sellers.

• NOTA: As métricas de coesão são muito mais utilizadas em

sistemas orientados a objetos (classes, métodos e atributos)

Set 2009 Alessandro Garcia © LES/DI/PUC-Rio 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 incrementa-se 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

Falta de Coesão: Forma 2

– 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

Set 2009 Alessandro Garcia © LES/DI/PUC-Rio 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

particionada em duas ou mais classes.

• Se existe apenas um método na classe RESULTADO = 0.

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 ferramentas podem ser encontradas em:e sas e a e as pode se e co adas e

– www.chris-lott.org/resources/cmetrics

– spinroot.com/static/

Set 2009 Alessandro Garcia © LES/DI/PUC-Rio 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.

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

Set 2009 Alessandro Garcia © LES/DI/PUC-Rio 29 /32

A l 16

Aula 16

Métricas e Anomalias de

Modularidade

(continua...)