Métricas de código – Acoplamento de classes

O acoplamento de classe também atende pelo nome Acoplamento entre Objetos (CBO), conforme definido originalmente pelo CK94. Basicamente, o acoplamento de classe é uma medida de quantas classes uma única classe usa. Um número alto não é satisfatório, e um número baixo nessa métrica geralmente é o ideal. O acoplamento de classe tem se mostrado um preditor preciso de falha de software e estudos recentes mostraram que o valor de limite superior de 9 é o S2010 mais eficiente.

De acordo com a documentação da Microsoft, o acoplamento de classe "mede o acoplamento a classes exclusivas por meio de parâmetros, variáveis locais, tipos de retorno, chamadas de método, instanciações genéricas ou de modelo, classes base, implementações de interface, campos definidos em tipos externos e decoração de atributo. Um bom design de software determina os tipos e métodos que devem ter alta coesão e baixo acoplamento. O alto acoplamento indica um design difícil de reutilizar e manter devido a diversas interdependências em outros tipos".

Os conceitos de acoplamento e coesão estão claramente relacionados. Para manter essa discussão no tópico, não entraremos em detalhes sobre coesão além de fornecer uma breve definição de KKLS2000:

"A coesão do módulo foi introduzida por Yourdon e Constantine como 'quão firmemente associados ou relacionados os elementos internos de um módulo são entre si' YC79. Um módulo terá uma forte coesão se representar exatamente uma tarefa [...], e todos os seus elementos contribuírem para essa única tarefa. Eles descrevem a coesão como um atributo de design, em vez de código, e um atributo que pode ser usado para prever a reutilização, a manutenção e a alterabilidade".

Exemplo de acoplamento de classe

Vamos examinar o acoplamento de classe em ação. Primeiro, crie um novo aplicativo de console e uma nova classe chamada Pessoa com algumas propriedades e, em seguida, calcule imediatamente as métricas de código:

Observe que o acoplamento de classe é 0, pois essa classe não usa outra classe. Agora, crie outra classe chamada PersonStuff com um método que cria uma instância de Person e define os valores da propriedade. Calcule as métricas de código novamente:

Veja como o valor de acoplamento de classe aumenta? Observe também que, independentemente de quantas propriedades você definir, o valor de acoplamento de classe só aumenta em 1 e não em outro valor. O acoplamento de classe mede cada classe apenas uma vez para essa métrica, independentemente do quanto ela seja usada. Além disso, você pode ver que DoSomething() tem um 1, mas o construtor PersonStuff() tem o valor de 0? Atualmente, não há nenhum código no construtor que esteja usando outra classe.

E se você colocar código no construtor que usou outra classe? Aqui está o que você recebe:

Agora, o construtor tem claramente um código que usa outra classe e a métrica de acoplamento de classe mostra esse fato. Novamente, você pode ver que o acoplamento de classe geral para PersonStuff() é 1 e DoSomething() também é 1 para mostrar que apenas uma classe externa está sendo usada, independentemente da quantidade de código interno que você tem que o usa.

Em seguida, crie outra nova classe. Dê um nome a essa classe e crie algumas propriedades nela:

Agora, consuma a classe em nosso método DoSomething() na classe PersonStuff e calcule as métricas de código novamente:

Como você pode ver, o acoplamento de classe para a classe PersonStuff sobe para 2 e, se você analisar a classe, poderá ver que o método DoSomething() tem mais acoplamento, mas o construtor ainda consome apenas uma classe. Usando essas métricas, é possível ver o número máximo geral de uma determinada classe e analisar os detalhes por membro.

O Número Mágico

Assim como acontece com a complexidade ciclomática, não há limite que atenda a todas as organizações. No entanto, o S2010 indica que um limite de 9 é ideal:

"Portanto, consideramos os valores-limite [...] como os mais eficazes. Esses valores-limite (para um único membro) são CBO = 9[...]." (ênfase nossa)

Análise de Código

A análise de código inclui uma categoria de regras de manutenção. Para obter mais informações, confira Regras de manutenção. Ao usar a análise de código herdada, o conjunto de regras da Diretriz de Design Estendido contém uma área de manutenção:

Dentro da área de manutenção, há uma regra para acoplamento de classes:

Essa regra emite um aviso quando o acoplamento de classes é excessivo. Para obter mais informações, consulte CA1506: Evitar acoplamento de classes excessivo.

Citações

CK94

Chidamber, S. R. & Kemerer, C. F. (1994). A Metrics Suite for Object Oriented Design (IEEE Transactions on Software Engineering, Vol. 20, No. 6). Recuperado em 14 de maio de 2011, do site da Universidade de Pittsburgh: http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf

KKLS2000

Kabaili, H., Keller, R., Lustman, F. e Saint-Denis, G. (2000). Class Cohesion Revisited: An Empirical Study on Industrial Systems (Proceedings of the Workshop on Quantitative Approaches in Object-Oriented Software Engineering). Recuperado em 20 de maio de 2011, do site da Université de Montréal http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf

SK2003

Subramanyam, R. & Krishnan, M. S. (2003). Empirical Analysis of CK Metrics for Object-Oriented Design Complexity: Implications for Software Defects (IEEE Transactions on Software Engineering, Vol. 29, No. 4).

S2010

Shatnawi, R. (2010). A Quantitative Investigation of the Acceptable Risk Levels of Object-Oriented Metrics in Open-Source Systems (IEEE Transactions on Software Engineering, Vol. 36, No. 2).

YC79

Edward Yourdon e Larry L. Constantine. Structured Design. Prentice Hall, Englewood Cliffs, N.J., 1979.