domingo, 14 de junho de 2020

Métricas orientadas a classes: métricas CK – Chidamber e Kemerer

A classe é a unidade fundamental de um sistema OO e as métricas associadas a uma classe individual e às colaborações entre classes podem ajudar na avaliação da qualidade de um projeto OO. Chidamber e Kemerer propuseram um conjunto de métricas para sistemas OO, denominado CK metrics suite, que é bastante conhecido.

As 6 métricas CK, de acordo com Pressman e Maxim (2016, p. 667-669) são assim definidas:

  • WWC – Weighted Methods per Class (métodos ponderados por classe): suponha que são definidos para uma classe C n métodos de complexidade c1, c2...cn. A métrica específica de complexidade escolhida (como complexidade ciclomática, por exemplo) deve ser normalizada de forma que a complexidade nominal para cada método assuma o valor 1.0.
  • Podemos concluir que o WWC deve ser mantido o mais baixo possível, pois à medida que o número de métodos de uma classe cresce, ela tende a se tornar cada vez mais específica daquela aplicação, deixando seu potencial de reutilização muito baixo.
  • DIT – Depth of the Inheritance Tree (profundidade da árvore de herança): essa métrica se refere ao comprimento máximo do nó até a raiz da árvore de hierarquia de classes. Na medida em que DIT cresce, é possível que classes de nível inferior herdem muitos métodos. Portanto, um DIT baixo mostra-se mais desejável. Um DIT alto leva a uma maior complexidade do projeto, mas por outro lado, pode implicar que haja muitos métodos que possam ser reutilizados. Na árvore de hierarquia de classes da figura, o DIT é 3.
Diagrama de classes: exemplo de árvore de hierarquia de classes
Fonte: Pressman; Maxim (2016, p. 191).
  • NOC – Number of Children (número de filhas): as subclasses diretamente subordinadas a uma classe na hierarquia de classes são chamadas de filhas. Na figura 7 a classe Parede tem 3 subclasses SegmentoParede, Janela e Porta. Na medida em que o NOC aumenta, a quantidade de testes necessários para exercitar cada classe filha também aumenta.
  • CBO – Coupling Between Object classes (acoplamento entre objetos de classes): o modelo CRC pode ser usado para determinar o valor do CBO, que se refere ao número de colaborações para uma classe. Na medida em que o CBO aumenta, as modificações e os testes resultantes destas modificações tornam-se mais complexos e a reutilização da classe pode ser reduzida.
Exemplo de Cartão CRC
 
Fonte: Pressman; Maxim (2016, p. 192).
  • RFC - Response for a Class (resposta para uma classe): corresponde ao conjunto de métodos em potencial que podem ser executados em resposta a uma mensagem recebida por um objeto daquela classe. Na medida em que a RFC aumenta, tanto o trabalho de teste quanto a complexidade da classe também aumentam.
  • LCOM – Lack of Cohesion Methods (falta de coesão em métodos): cada método em uma classe pode acessar um ou mais atributos. LCOM corresponde ao número de métodos que acessam um ou mais atributos em comum. Se nenhum método acessa os mesmos atributos, LCOM = 0. Para exemplificar, considere uma classe com 6 métodos: 4 dos métodos têm um ou mais atributos em comum; portanto, LCOM =4. Para manter a coesão alta, é desejável se manter LCOM baixo.

Cartão CRC - Class-Responsibility-Collaborations

Embora não faça parte de UML, uma técnica chamada Cartões CRC é muito usada para atribuir responsabilidades durante o projeto OO.

CRC cards foram inventados por Ward Cunningham e Kent Beck. Cartão CRC é um cartão pequeno (para só escrever o essencial) para cada classe. Escreve-se o nome da classe, suas responsabilidades e colaborações. Só se pensa nas responsabilidades de alto nível. Os cartões são desenvolvidos em pequenos grupos em que cada pessoa assume o papel (Role) de uma ou mais classes.

Exemplo de Cartão CRC
Fonte: <dsc>.

Nenhum comentário:

Postar um comentário