Métricas de código - Acoplamento de classe

O acoplamento de classe também é conhecido como Acoplamento Entre Objetos (CBO), conforme definido originalmente pelo CK94. Basicamente, o acoplamento de classes é uma medida de quantas classes uma única classe usa. Um número alto é ruim e um número baixo geralmente é bom com essa métrica. O acoplamento de classes demonstrou ser um preditor preciso de falha de software e estudos recentes mostraram que um valor 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 atributos. Um bom design de software dita que os tipos e métodos devem ter alta coesão e baixo acoplamento. O acoplamento alto indica um design difícil de reutilizar e manter devido às suas muitas interdependências com outros tipos."

Os conceitos de acoplamento e coesão estão claramente relacionados. Para manter esta discussão sobre o tema, não entraremos em profundidade com a coesão a não ser para dar uma breve definição de KKLS2000:

"A coesão do módulo foi introduzida por Yourdon e Constantine como 'quão fortemente ligados ou relacionados os elementos internos de um módulo estão uns com os outros' YC79. Um módulo tem uma forte coesão se representar exatamente uma tarefa [...], e todos os seus elementos contribuem para esta ú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, manutenibilidade e mutabilidade."

Exemplo de acoplamento de classe

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

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

Vê como o valor de acoplamento da classe aumenta? Observe também que, não importa quantas propriedades você defina, o valor de acoplamento de classe apenas aumenta em 1 e não em algum outro valor. O acoplamento de classe mede cada classe apenas uma vez para esta métrica, independentemente das vezes que é utilizada. Além disso, você pode ver que DoSomething() tem um 1, mas o construtor, PersonStuff(), tem um 0 para o seu valor? Atualmente, não há nenhum código no construtor que está usando outra classe.

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

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

Em seguida, crie outra nova classe. Dê a esta classe algum nome e crie algumas propriedades dentro dela:

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

Como pode ver, o acoplamento de classe para a classe PersonStuff vai até 2 e, se aprofundar na classe, poderá ver que o método DoSomething() tem o maior acoplamento na mesma, mas o construtor ainda consome apenas 1 classe. Usando essas métricas, você pode ver o número máximo geral de uma determinada classe e detalhar os detalhes por membro.

O Número Mágico

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

"Portanto, consideramos que os valores-limite [...] como o mais eficaz. Estes valores-limite (para um único membro) são CBO = 9[...]." (sublinhado nosso)

Análise de código

A análise de código inclui uma categoria de regras de manutenabilidade. Para obter mais informações, consulte Regras de manutenção. Ao usar a análise de código herdado, o conjunto de regras do Extended Design Guideline contém uma área de manutenção:

Na área de manutibilidade, existe uma regra para o acoplamento de classes:

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

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). Consultado 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). Coesão de Classe Revisitada: Um Estudo Empírico sobre Sistemas Industriais (Anais do Workshop sobre Abordagens Quantitativas em Engenharia de Software Object-Oriented). Consultado 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). Análise Empírica de Métricas CK para Complexidade de Projeto Orientado a Objetos: Implicações para Defeitos de Software (IEEE Transactions on Software Engineering, Vol. 29, No. 4).

S2010

Shatnawi, R. (2010). Uma Investigação Quantitativa dos Níveis de Risco Aceitáveis das Métricas orientadas a objetos em sistemas open-source (IEEE Transactions on Software Engineering, Vol. 36, No. 2).

YC79

Edward Yourdon e Larry L. Constantine. Design Estruturado. Prentice Hall, Englewood Cliffs, Nova Jérsei, 1979.