Métricas de Chidamber e Kemerer

Apresentação em tema: "Métricas de Chidamber e Kemerer"— Transcrição da apresentação:

1 Métricas de Chidamber e Kemerer
Glauco Pollo De Marchi de Godoi RA: Rodrigo Mathias de Oliveira Abreu RA: Verônica Costa Carvalho RA: BACH MA 4

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

3 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.

4 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

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

6 Tabela de Métricas Orientadas a Objetos
© Ian Sommerville – Engenharia de Software – 8ª edição

7 Diagrama de Classes

8 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.

9 Estudo de Caso – WMC Classe Nº métodos Apartamento 2 Pagamento 1
ApartamentoDAO 4 PagamentoDAO Proprietario Despesa ProprietarioDAO DespesaDAO Telefone Variavel Condominio 3 Geral CondominioDAO Interface DAO

10 Estudo de Caso – WMC Conclusão: o número WMC é baixo.

11 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.

12 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. Superclasse Despesa Atributos - valor : Double - codDespesa : Double - nome : String Método + CalcularDespesa() : double Subclasses Variável Geral

13 Estudo de Caso - DIT Conclusão: a profundidade DIT é baixa.

14 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.

15 Estudo de Caso - NOC Há apenas uma superclasse, e esta possui duas filhas que herdam 3 atributos e 1 método.

16 Estudo de Caso - NOC Conclusão: o número NOC é baixo.

17 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

18 Estudo de Caso - RFC Apartamento RFC = 2 + 0 = 2 ApartamentoDAO
Proprietario ProprietarioDAO Telefone RFC = = 0 Condominio RFC = = 4 CondominioDAO Pagamento RFC = = 1 PagamentoDAO Despesa RFC = = 3 DespesaDAO Variavel Geral InterfaceDAO RFC = = 4

19 Estudo de Caso - RFC Conclusão: o número RFC é baixo.

20 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.

21 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 Fixa calcularDespesa()

22 Estudo de Caso - CBO Conclusão: baixo número CBO.

23 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.

24 LCOM (cont)

25 Estudo de Caso - LCOM Condominio LCOM = 2-0 = 2
calculaCond() = numQuartos, despesa, valorcond verificaJuros() = pagamento, vencimento calculaMulta() = vencimento, valormulta, pagamento Apartamento LCOM = 0-0 = 0 validarNumQuartos() - numquartos validarNumApto() - numApto Proprietario LCOM = 0-0 = 0 validarCPF() = cpf validarCEP() = cep

26 Estudo de caso – LCOM (cont)
Pagamento LCOM = 0-0 = 0 geraBarCode() - codigoPg Despesa LCOM = 0-0 = 0 calcularDespesa() - valor

27 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

28 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.

29 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.

30 Referências SOMMERVILLE, Ian. Engenharia de Software, 2007, 8ªedição, Pearson Education. Aivosto – acessado em 03/11/2010

31 Perguntas