Métricas de código – acoplamento de classes

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

Os conceitos de acoplamento e coesão estão claramente relacionados. Para manter essa discussão no foco do assunto, não entraremos em detalhes sobre a coesão, além de dar uma breve definição segundo 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 uns aos outros' YC79. Um módulo terá uma coesão forte se representar exatamente uma tarefa [...], e todos os seus elementos contribuirem 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 crie uma nova classe chamada Person com algumas propriedades e 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 da propriedade. Calcule as métricas de código novamente:

Veja como o valor do acoplamento entre classes aumenta? Observe também que, independentemente de quantas propriedades você definir, o valor de acoplamento de classe aumenta em 1 e não por algum outro valor. O acoplamento de classe mede cada classe apenas uma vez para esta métrica, não importando o quanto ela é utilizada. Além disso, você pode ver que DoSomething() tem um 1, mas o construtor, PersonStuff()tem um 0 para seu valor? 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ê obtém:

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 geral da classe PersonStuff() é 1 e DoSomething() também é 1, para mostrar que apenas uma classe externa está sendo utilizada, independentemente de quanto código interno você tenha que a utilize.

Em seguida, crie outra nova classe. Dê algum nome a essa classe 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 você pode ver, o acoplamento da classe PersonStuff vai até 2 e, se você analisar a classe, poderá ver que o DoSomething() método tem o maior acoplamento dentro dele, mas o construtor ainda consome apenas uma 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

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 de limite [...] como o mais eficaz. Esses valores de limite (para um único membro) são CBO = 9[...]." (ênfase adicionada)

Code Analysis

A análise de código inclui uma categoria de regras de manutenção. Para obter mais informações, consulte Regras de Manutenibilidade. 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 manutenibilidade há uma regra para acoplamento de classe:

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

Citações

CK94

Chidamber, S. R. &Kemerer, C. F. (1994). Um Conjunto de Métricas para Design Orientado a Objetos (Transações IEEE em Engenharia de Software, 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). Coesão de Classe Revisitada: Um Estudo Empírico sobre Sistemas Industriais (Anais do Workshop sobre Abordagens Quantitativas na Engenharia de Software Orientada a Objetos). 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). Análise empírica de métricas de CK para complexidade de design orientado a objetos: implicações para defeitos de software (Transações IEEE em Engenharia de Software, Vol. 29, nº 4).

S2010

Shatnawi, R. (2010). Uma investigação quantitativa dos níveis de risco aceitáveis de métricas orientadas a objetos em sistemas de código aberto (IEEE Transactions on Software Engineering, v. 36, n. 2).

YC79

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