métricas de chidamber e kemerer glauco pollo de marchi de godoira:0910643 rodrigo mathias de...
Post on 28-Apr-2015
110 Views
Preview:
TRANSCRIPT
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
top related