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.
Nenhum comentário:
Postar um comentário