Métricas de Chidamber e Kemerer

Glauco Pollo De Marchi de Godoi RA:0910643Rodrigo Mathias de Oliveira Abreu RA:0910066Verônica Costa Carvalho RA:0910279

BACH MA 4

Agenda

Introdução Diagrama de Classes estudado Descrição e aplicação das métricas Conclusão Referências

Introdução

Revisar um software é caro e demorado.

Para facilitar esse processo foram criadas algumas métricas, que quando comparados os valores com alguns padrões de uma orgranização, podem ajudar na avaliação da qualidade de um software.

Introdução

Essas métricas são tomadas a partir de atributos internos do software e são associados aos atributos externos.

Métricas podem ser utilizadas para: Fazer previsões gerais sobre um sistema Identificar componentes anômalos

Métricas de Chidamber e Kemerer

As métricas orientadas a objetos mais conhecidas foram propostas por Chidamber e Kemerer.

Exemplos: WMC (Weighted Methods Per Class) DIT (Depth of Inheritance Tree) NOC (Number of Children) CBO (Coupling between Object Classes) RFC (Response for a Class) LCOM (Lack of Cohesion of Methods)

Tabela de Métricas Orientadas a Objetos

© Ian Sommerville – Engenharia de Software – 8ª edição

Diagrama de Classes

WMC (Weighted Methods Per Class)

WMC: contagem dos métodos de uma classe.

Ideal: baixo numero de WMC. Número de WMC alto: normalmente

acabam acontecendo mais falhas, e o reuso da classe acaba sendo mais limitado.

WMC: prevê quanto tempo e esforço é necessário para manter uma classe.

Estudo de Caso – WMC

Classe Nº

métodos

Classe Nº

métodosApartamento 2 Pagamento 1

ApartamentoDAO 4 PagamentoDAO 4

Proprietario 2 Despesa 1

ProprietarioDAO 4 DespesaDAO 4

Telefone 0 Variavel 1

Condominio 3 Geral 1

CondominioDAO 4 Interface DAO 4

Estudo de Caso – WMC

Conclusão: o número WMC é baixo.

DIT (Depth of Inheritance Tree)

DIT: profundidade da árvore de herança. Quanto mais profunda uma classe está numa

relação de hierarquia, e quanto mais métodos e atributos são herdados, acabam causando uma complexidade maior.

Alto número de DIT: maior número de falhas. Não necessariamente é a ultima classe de uma

hierarquia que terá maior número de falhas, normalmente é a classe que fica no meio. Uma recomendação seria 5 ou menos.

Estudo de Caso - DIT

Há apenas uma superclasse, e esta possui duas filhas que herdam 3 atributos e 1 método.

Há apenas 1 nível de hierarquia.SuperclasseDespesaAtributos- valor : Double- codDespesa : Double- nome : StringMétodo+ CalcularDespesa() : doubleSubclasses VariávelGeral

Estudo de Caso - DIT

Conclusão: a profundidade DIT é baixa.

NOC (Number of Children)

NOC: número das classes imediatas filhas derivadas de uma super classe. Mede a largura de uma hierarquia.

Alto número de NOC pode indicar: Alto reuso da classe A classe mãe deve ser testada. Abstração incorreta da classe mãe. Uso incorreto de subclasses.

Número alto de NOC indica poucas falhas. O alto reuso está altamente relacionado, pois é algo desejado.

Uma classe que tenha um alto número de NOC e WMC indica complexidade no inicio de uma hierarquia. Uma classe está gerando um número grande de descendentes. Isso pode indicar um design incorreto. Nem todas as classes devem ter o mesmo número de subclasses. As classes que ficam mais no topo devem ter mais subclasses do que as que estão abaixo.

Estudo de Caso - NOC

Há apenas uma superclasse, e esta possui duas filhas que herdam 3 atributos e 1 método.

Estudo de Caso - NOC

Conclusão: o número NOC é baixo.

RFC (Response for a Class)

O conjunto de respostas é um conjunto de métodos que podem ser executados em resposta a uma mensagem recebida por um objeto de outra classe. RFC é simplesmente o número de métodos nesse conjunto.

RFC = M + R M = número de métodos na classe R = número de métodos remotos chamados por

métodos da classe Um alto número de RFC tem indicado mais falhas,

além de serem mais complexas e mais difíceis de entender

Estudo de Caso - RFCApartamento RFC = 2 + 0 = 2

ApartamentoDAO RFC = 4 + 4 = 8

Proprietario RFC = 2 + 0 = 2

ProprietarioDAO RFC = 4 + 4 = 8

Telefone RFC = 0 + 0 = 0

Condominio RFC = 3 + 1 = 4

CondominioDAO RFC = 4 + 4 = 8

Pagamento RFC = 1 + 0 = 1

PagamentoDAO RFC = 4 + 4 = 8

Despesa RFC = 1 + 2 = 3

DespesaDAO RFC = 4 + 4 = 8

Variavel RFC = 1 + 0 = 1

Geral RFC = 1 + 0 = 1

InterfaceDAO RFC = 4 + 0 = 4

Estudo de Caso - RFC

Conclusão: o número RFC é baixo.

CBO (Coupling between Object Classes)

CBO: acoplamento entre objetos de classes. Duas classes são consideradas acopladas quando os métodos declarados em uma, usam métodos ou instâncias definidas por outra classe. Uma classe pode ter métodos usados, como pode ser usada, entrando na conta, porém apenas uma vez. Acessos múltiplos para a mesma classe são contados como um único acesso.

Se um método é polimórfico (Override ou Overload), todas as classes onde a mensagem vai são incluídos na contagem.

Alto número de CBO: não é desejável, indica propensão a falhas. Um alto acoplamento é prejudicial design modular e não é ideal para reuso.

Ideal: classes mais independentes, facilitando o reuso. CBO maior que 14 é considerado alto.

Estudo de Caso - CBO

Condominio-Pagamento-verificaJuros()-calculaMulta()

Condominio-Apartamento-numQuartos: int;

Condominio-Despesa-valor: double;

Pagamento-Proprietário-nome: String;-confirmação: bool;

Despesa – Despesa Variavel/Despesa FixacalcularDespesa()

Estudo de Caso - CBO

Conclusão: baixo número CBO.

LCOM (Lack of Cohesion of Methods)

Leve em consideração um par de métodos numa classe. Se eles acessam instâncias de forma disjuntas, aumentar o P em 1. Se eles dividem ao menos um acesso a variável, aumentar o Q por 1.

LCOM1 = P - Q LCOM1 = 0 indica uma classe coesa LCOM1 > 0 indica que a classe necessita ser dividida em duas ou

mais classes Classes com alto número de LCOM1 são mais propensas a falhas.Crítica ao LCOM1 LCOM1 tem sido bastante criticada, pois apresentou um número de

inconvenientes, portanto deve ser utilizada com cuidado. Primeiramente, LCOM1 acaba dando o valor zero para várias

classes diferentes. Em Segundo lugar, A definição da LCOM é baseada em interação

método-dado, que pode não ser uma boa medida para coesão de classes orientadas a objetos.

LCOM (cont)

Estudo de Caso - LCOM

Condominio LCOM = 2-0 = 2calculaCond() = numQuartos, despesa, valorcondverificaJuros() = pagamento, vencimento

calculaMulta() = vencimento, valormulta, pagamento

Apartamento LCOM = 0-0 = 0 validarNumQuartos() - numquartos

validarNumApto() - numApto Proprietario LCOM = 0-0 = 0

validarCPF() = cpfvalidarCEP() = cep

Estudo de caso – LCOM (cont)

Pagamento LCOM = 0-0 = 0

geraBarCode() - codigoPg Despesa LCOM = 0-0 = 0

calcularDespesa() - valor

Estudo de Caso - LCOM

Conclusão:Classes com LCOM = 0, consideradas coesas:

Pagamento Proprietario Despesa Apartamento

Classes com LCOM > 0, que precisam ser divididas: Condominio

Conclusão

Medições de software podem ser usadas para juntar dados quantitativos sobre o software e o processo de software. [Ian Sommerville, 2007]

Os valores das métricas coletados podem ser utilizados para fazer inferências sobre a qualidade de produto e de processo.

Conclusão

Analisando as métricas de Chidamber e Kemerer utilizadas nesse projeto, pode-se perceber que em alguns pontos o SSOO pode ser considerado coeso e com baixo acoplamento (características importantes para uma alta qualidade de um software). Porém o SSOO deixa a desejar em certas métricas, e deveria ser melhor refinado.

Referências

SOMMERVILLE, Ian. Engenharia de Software, 2007, 8ªedição, Pearson Education.

Aivosto – acessado em 03/11/2010

http://www.aivosto.com/project/help/pm-oo-ck.html

Perguntas