See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/261026207

Coeso e Acoplamento em Sistemas OO

ARTICLE MARCH 2010

READS

116

1 AUTHOR:
Leandro Luque
Centro Paula Souza
23 PUBLICATIONS 1 CITATION
SEE PROFILE

Available from: Leandro Luque

Retrieved on: 10 March 2016

Coeso e Acoplamento em
Sistemas Orientados a Objetos
Melhorando a qualidade de seus projetos.
Conhea os conceitos de coeso e acoplamento e como eles podem
influenciar no desenvolvimento de sistemas com maior qualidade.

De que se trata o artigo:

Neste artigo, apresentada uma viso geral sobre os conceitos de coeso e

acoplamento e sua importncia no desenvolvimento de sistemas orientados a objetos de
qualidade.
Para que serve:

Apresentar conceitos que podem auxiliar desenvolvedores na produo de sistemas

orientados a objetos com maior qualidade, principalmente no que diz respeito
facilidade de manuteno e ao potencial de reuso.
Em que situao o tema til:

O desenvolvimento de software de qualidade, dentro do prazo e com o custo

estabelecido essencial para a sobrevivncia de qualquer organizao desenvolvedora
de software. A facilidade com que se d a manuteno e o potencial de reuso de um
software desempenham papel de destaque nesse contexto, e os conceitos de coeso e
acoplamento podem auxiliar muito neste sentido.
Coeso e acoplamento em sistemas orientados a objetos:

Os conceitos de coeso e acoplamento, surgidos no contexto da anlise e projeto

estruturados, embora tenham um grande impacto na qualidade de sistemas, so
geralmente desconhecidos ou negligenciados por desenvolvedores iniciantes de
sistemas orientados a objetos. O desenvolvimento de softwares com alta coeso e fraco
acoplamento facilita, entre outras coisas, a manuteno e o reuso. Assim sendo, o estudo
desses conceitos e seus desdobramentos torna-se importante para melhorar a qualidade
de projetos de software.

Muitos desenvolvedores de software percorreram caminhos que passaram pelo

desenvolvimento procedural antes de chegarem orientao a objetos.
Desenvolver um programa procedural significa entender e conceber o programa como
um conjunto de procedimentos (tambm conhecidos como rotinas, sub-rotinas ou
funes) que manipulam dados. Neste modelo de desenvolvimento, os procedimentos
so geralmente as unidades de subdiviso ou modularidade de sistemas.
Diferentemente do paradigma orientado a objetos, no qual a subdiviso de sistemas
baseada no mapeamento de objetos do domnio do problema para o domnio da soluo,
o desenvolvimento procedural no possui uma semntica forte que oriente a subdiviso
de sistemas. Por isso, os procedimentos ou conjuntos relacionados de procedimentos de
sistemas procedurais muitas vezes tratam de aspectos distintos do sistema e,
consequentemente, apresentam certas caractersticas, como um alto grau de
interdependncia, que dificultam a manuteno e o reuso.
Neste contexto, muitos conceitos e mtricas foram definidos para avaliar e auxiliar a
subdiviso de sistemas. Dois destes conceitos so especialmente importantes por terem
grande influncia na qualidade dos sistemas desenvolvidos: coeso e acoplamento.
Os conceitos de coeso e acoplamento surgiram em meados da dcada de 1960, a partir
de um estudo conduzido por Larry Constantine sobre o motivo pelo qual certos tipos de
mdulos de sistemas eram definidos e da anlise dos pontos positivos e negativos
relativos a estes tipos. Estes conceitos foram bastante estudados e utilizados no contexto
da anlise e projeto estruturado de sistemas.
A falta de conhecimento ou o negligenciamento destes conceitos e mtricas contribui
para que muitos desenvolvedores de sistemas orientados a objetos, principalmente
iniciantes, desenvolvam sistemas com caractersticas indesejveis.
O objetivo desse artigo apresentar uma introduo aos conceitos de coeso e
acoplamento, buscando demonstrar o efeito de desprez-los na modelagem de sistemas
orientados a objetos atravs de alguns exemplos simples. Os exemplos so apresentados
na forma de diagramas de classes da Linguagem de Modelagem Unificada-UML e
cdigo Java.

Coeso
Estendendo a definio clssica de coeso para o paradigma orientado a objetos, podese definir coeso de um sistema de software como a relao existente entre as
responsabilidades de uma determinada classe e de cada um de seus mtodos. Uma
classe altamente coesa tem responsabilidades e propsitos claros e bem definidos,
enquanto uma classe com baixa coeso tem muitas responsabilidades diferentes e pouco
relacionadas.
Para se ter uma ideia de classes com nveis diferentes de coeso, vamos analisar dois
exemplos de classes retiradas de um sistema bancrio e de um sistema de locadora de
vdeos, representadas nas Figuras 1 e 2, respectivamente.

Figura 1. Exemplo de classe com alta coeso (Sistema bancrio).

No exemplo do sistema bancrio, a classe ContaCorrente responsvel por operaes

relacionadas apenas a contas correntes: sacar e depositar. Nenhum outro assunto no
relacionado a contas correntes tratado por esta classe. Assim sendo, pode-se classificar
esta classe como altamente coesa.

Figura 2. Exemplo de classe com baixa coeso (Sistema de locadora de vdeos).

Por outro lado, a classe Cliente, do sistema de locadora (Figura 2), alm de possuir
atributos referentes a clientes, possui um mtodo para a realizao de aluguel de filmes.
Essa modelagem muito comum entre iniciantes e surge, na maioria das vezes, de um
entendimento incorreto do mapeamento do diagrama de casos de uso para o diagrama
de classes. Como no diagrama de casos de uso de uma locadora geralmente h uma
associao entre o ator Cliente e o caso de uso Alugar Filme, pode-se imaginar que
seja razovel definir um mtodo alugarFilme() na classe Cliente.
No entanto, esse tipo de definio faz com que a classe Cliente tenha baixa coeso (por
tratar de assuntos diferentes: clientes e aluguel de filmes). O problema dessa
modelagem que o reuso e o entendimento das classes, quando observadas
individualmente, ficam prejudicados.
Como exemplo ilustrativo do porqu de um baixo grau de coeso causar estes
problemas, vamos imaginar um cenrio bastante provvel de reuso da classe Cliente em
outros sistemas, como: Oficina Mecnica, Sistema Bancrio, entre outros.
Nestes sistemas, no faz sentido que um cliente alugue filmes (Figura 3). O mtodo
alugarFilme(), embora pudesse simplesmente no ser chamado nesses sistemas,
dificultaria o entendimento da classe Cliente, exigiria que a classe Filme tambm
estivesse disponvel e seria carregado como lixo, podendo inclusive causar algum tipo
de comportamento inesperado ou exceo, caso fosse executado.

Figura 3. Exemplo de reuso da classe Cliente, da locadora de vdeos, em um sistema

bancrio.

Dos estudos de coeso e posteriores aprimoramentos, Stevens, Myers, Constantine e

Yourdon propuseram uma classificao de coeso voltada para sistemas estruturados

baseada em sete nveis: coeso funcional, sequencial, comunicacional, procedural,

temporal, lgica e coincidental.
Estes nveis variavam do melhor tipo de coeso (funcional), que significava que um
mdulo qualquer continha elementos que contribuam para a execuo de uma e apenas
uma tarefa, ao pior tipo de coeso (coincidental), que significava que um mdulo
continha elementos que contribuam para atividades sem relao significativa entre si.
Alguns autores procuraram fazer uma analogia direta destes nveis para sistemas
orientados a objetos, principalmente no que se refere coeso de mtodos quando
individualmente analisados. Outros autores definiram nveis de coeso de classes
considerando o uso de atributos pelos mtodos da classe. Quanto mais os mtodos
usavam os mesmos atributos de uma classe, maior era a coeso. Por fim, outros autores
procuraram uma classificao diferenciada.
Uma destas classificaes diferenciadas, proposta por Meilir Page-Jones, define trs
tipos de coeso para classes e trs tipos para mtodos.
Coeso de classes:
Coeso de instncia mista: ocorre quando uma classe tem caractersticas que
so indefinidas para alguns dos objetos da classe.
Este tipo de coeso pode ser observado na classe Pessoa, representada na
Figura 5. Esta classe foi criada para representar tanto pessoas fsicas quanto
jurdicas. No caso de um objeto que represente uma pessoa fsica, os atributos
cnpj e nomeFantasia sero indefinidos e no faro sentido. Caso outra aplicao
necessite apenas trabalhar com pessoas fsicas, por exemplo, o reuso fica
prejudicado. Classes com esse tipo de coeso, alm de carregarem atributos e
mtodos que no fazem sentido em determinados casos, geralmente exigem um
cdigo costurado para verificar com que tipo de objeto estamos lidando;

Figura 5. Exemplo de classe com coeso de instncia mista.

Coeso de domnio misto: ocorre quando classes de domnios diferentes

(domnio de arquitetura, domnio do negcio, dentre outros), que podem ser
definidas de forma independente, mantm alguma dependncia.
Este tipo de coeso pode ser observado na Figura 6, na qual a classe
ContaPoupanca (domnio do negcio), de um sistema bancrio, possui um
mtodo para imprimir, na impressora do caixa eletrnico, o seu saldo, atravs do
uso da classe Impressora (domnio da arquitetura). Caso o banco desejasse
reutilizar essa classe em uma aplicao de dispositivo mvel, por exemplo, na
qual
os
clientes
pudessem
consultar
saldo,
o
mtodo
imprimirSaldoNaImpressora() no faria sentido;

Figura 6. Exemplo de classe com coeso de domnio misto.

Coeso de papel misto: ocorre quando classes do mesmo domnio, que podem
ser definidas de forma independente, mantm alguma dependncia. Este tipo de
coeso foi o mesmo existente no exemplo da Figura 2, no qual a classe Cliente
(domnio do negcio) apresentava uma dependncia desnecessria em relao
classe Filme (tambm do domnio do negcio). Os efeitos desse tipo de coeso j
foram citados no exemplo dado anteriormente.

Coeso de mtodos:
Coeso alternada: ocorre quando um mtodo agrega diversas etapas do
comportamento da classe, mas s realiza uma delas mediante especificao por
parmetro. Um exemplo deste tipo de coeso pode ser observado no mtodo
calcular() da classe Triangulo (Figura 7), que realiza o clculo da rea (quando o
parmetro area true) ou o permetro do tringulo (quando o parmetro area
false). Este tipo de coeso resulta em mtodos extensos, com muitas linhas de
cdigo, e de difcil manuteno. Este tipo de coeso pode ser percebido pela
existncia do conectivo OU no nome do mtodo;
Coeso mltipla: similar coeso alternada. A diferena que na coeso
mltipla, um mesmo mtodo realiza no s uma, mas diversas etapas do
comportamento da classe. O mtodo moverERedimensionarERotacionar() da
classe Triangulo (Figura 7) um exemplo de mtodo com esse tipo de coeso.
Este mtodo move um tringulo, o redimensiona e o rotaciona ao mesmo tempo
e, para isso, recebe como parmetros as novas posies x e y, as propores para
redimensionamento na horizontal (propH) e vertical (propV), e o ngulo para
rotao (ang). As mesmas observaes feitas sobre os mtodos com coeso
alternada so extensveis a esse tipo de coeso. Este tipo de coeso pode ser
percebido pela existncia do conectivo E no nome do mtodo;
Coeso funcional: ocorre quando um mtodo dedicado a uma nica etapa de
comportamento. Essa a coeso ideal para mtodos. Um exemplo desse tipo de
coeso pode ser observado no mtodo calcularArea() da classe Triangulo, que
realiza apenas o clculo da rea do tringulo e nada mais.

Figura 7. Exemplo de classe com mtodos com coeso alternada, mltipla e funcional.

Independente da forma ou mtrica de classificao usada para definir a coeso de uma

classe, importante atentar para algumas questes que podem ajudar na verificao e
validao da coeso de uma classe:
Se esta classe fosse reutilizada em outro contexto, todos os seus atributos e sua
interface pblica seriam teis?
o Em caso negativo, interessante questionar se no seria o caso de dividir
a responsabilidade desta classe entre outras classes ou mesmo definir
subclasses que assumam parte desta responsabilidade;

Caso esta classe seja isolada do sistema para o qual ela est sendo
implementada, seria possvel entend-la?
o Em caso negativo, pode ser que as responsabilidades da classe no
estejam bem definidas.

Embora seja vlida a lio tirada de metodologias geis que diz que no produtivo
dispensar muito tempo procurando prever todos os cenrios de uso e reuso de uma
classe, a cautela na modelagem, sua verificao e validao, pelo menos em um nvel
superficial, podem ser de grande valia para a definio de um projeto coeso que
contribuir para a reduo do trabalho futuro com manuteno e facilitar o reuso.

Acoplamento
O outro dos conceitos abordados nesse artigo o acoplamento, que pode ser entendido
como a interdependncia existente entre diferentes classes. Quanto mais uma classe
conhece ou depende de outras classes, maior o grau de acoplamento entre elas.
Os conceitos de coeso e acoplamento so geralmente abordados juntos porque esto
correlacionados. Um baixo grau de coeso geralmente acarreta em um forte
acoplamento e vice-versa. Por outro lado, um alto grau de coeso geralmente resulta em
um fraco acoplamento e vice-versa.
Isto pode ser entendido pelo fato de que uma classe com baixa coeso possui
responsabilidades que deveriam ser de outras classes e, assim sendo, dever ser
acessada por essas outras classes para que essas possam cumprir suas tarefas,
fortalecendo assim o acoplamento.
Em sistemas com forte acoplamento, mudanas em uma classe foram mudanas em
classes relacionadas, fica mais difcil entender as classes isoladamente e mais difcil
reusar as classes, j que elas dependem da presena umas das outras.
Como exemplo de um problema causado pela existncia de um forte acoplamento
entre classes, vamos considerar um conhecido conceito de sistemas orientados a
objetos: o encapsulamento.
Encapsulamento (tambm conhecido como ocultamento de informaes) consiste em
manter uma interface pblica para um objeto sem expor os seus detalhes internos de
implementao, que permanecem escondidos dos outros objetos.
O encapsulamento evita que um programa torne-se to interdependente (to fortemente
acoplado) que uma pequena mudana tenha grandes efeitos colaterais. Motivos para
modificar a implementao de um objeto podem ser, por exemplo, aprendizado de
novas caractersticas e funcionalidades da linguagem de programao, melhoria de
desempenho, mudanas legais ou culturais, correo de erros ou mudana de plataforma
de execuo.
Para entender como um forte acoplamento dificulta modificaes em um sistema,
suponha que foi implementada uma classe em Java para um sistema de agenda de
compromissos que representa um evento (Listagem 1). Esta classe possui atributos para
armazenar o nome, a data, uma breve descrio e o status do evento. Os mtodos dessa
classe permitem que eventos sejam criados, cancelados e consultados.
Como voc no conhecia bem a linguagem Java no momento da implementao desta
classe, optou por representar a data do evento atravs de trs atributos (linha 4): dia,
mes e ano, todos do tipo int. Sem se preocupar com o conceito de encapsulamento, no
foi proibido o acesso direto aos atributos da classe (atributos pblicos).
Listagem 1. Cdigo da classe Evento cujos atributos no esto encapsulados.
1
2

public class Evento {

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public
public
public
public

String nome;
int dia, mes, ano;
String descrio;
boolean cancelado;

public void agendar(int dia, int mes, int ano) {

this.dia = dia;
this.mes = mes;
this.ano = ano;
}
public void cancelar() {
// cdigo para cancelar um evento.
}
public void consultar() {
// cdigo para consultar um evento.
}
}

Esta classe foi utilizada em diversas aplicaes (ex.: sistema acadmico, locadora,
entre outras). Em cada uma delas, os valores dos atributos foram definidos diretamente,
conforme Listagem 2.
Listagem 2. Cdigo do sistema acadmico e de locadora que utilizam a classe Evento definida na Listagem 1.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

//... cdigo do sistema acadmico ...

Evento e1 = new Evento();
e1.nome = Reunio com os professores;
e1.dia = 28;
e1.mes = 06;
e1.ano = 2010;
e1.descricao = Reunio entre pais e professores para a discusso + dos resultados
do semestre;
//...
//... cdigo do sistema da locadora ...
Evento e2 = new Evento();
e2.nome = Sesso de autgrafos com a atriz Y;
e2.dia = 12;
e2.mes = 03;
e2.ano = 2010;
e2.descricao = A atriz Y estar na locadora para uma sesso de autgrafos;
//...

Aps algum tempo, voc descobriu que a linguagem Java possui uma classe que
permite o armazenamento e manipulao de datas (java.util.Date) e deseja alterar a
estrutura da classe Evento para que a data passe a ser armazenada atravs de um objeto
da classe Date. Voc decidiu ento alterar a classe Evento, conforme Listagem 3.
Listagem 3. Cdigo da classe Evento aps a alterao dos atributos referentes data do evento.
1
2
3
4
5
6
7
8

import java.util.Date;
public class Evento {
public String nome;
public Date data;
public String descricao;
public boolean cancelado;
//...

Esta alterao acarretar em alteraes em todas as classes que usam a classe Evento,
como o caso dos exemplos anteriores apresentados para o sistema acadmico e da
locadora. Isto ocorre porque as linhas de cdigo que alteravam os atributos dia, mes e
ano (linhas 4, 5, 6, 13, 14 e 15 da Listagem 2) no funcionaro mais, j que estes
atributos no existem na nova verso da classe.

Isto ocorre porque a classe Evento e as classes que a usam esto fortemente acopladas
em relao estrutura de dados. Este acoplamento seria reduzido se a classe Evento
inicialmente tivesse encapsulado seus atributos. Neste cenrio, o cdigo da classe
Evento teria sido escrito conforme a Listagem 4.
Listagem 4. Cdigo da classe Evento com os atributos encapsulados.
1 public class Evento {
2
3
private String nome;
4
private int dia, mes, ano;
5
private String descricao;
6
private boolean cancelado;
7
8
public void agendar (int dia, int mes, int ano) {
9
this.dia = dia;
10
this.mes = mes;
11
this.ano = ano;
12
}
13
14
//... outros mtodos
15 }

As classes que usam este cdigo teriam sido escritas conforme o cdigo da Listagem
5.
Listagem 5. Cdigo do sistema acadmico e de locadora que utilizam a verso encapsulada da classe Evento.
1
2
3
4
5
6
7
8
9
10
11
12
13

//... cdigo do sistema acadmico ...

Evento e1 = new Evento();
e1.setNome(Reunio com os professores);
e1.agendar(28, 06, 2010);
e1.setDescricao(Reunio entre pais e professores);
//...
//... cdigo do sistema da locadora ...
Evento e2 = new Evento();
e2.setNome(Sesso de autgrafos com a atriz X);
e2.agendar(12, 03, 2010);
e2.setDescricao(A atriz X estar na locadora para uma sesso de autgrafos);
//...

Como as classes que utilizam a classe Evento, na Listagem 5, no conhecem sua

estrutura interna, h um enfraquecimento do acoplamento. Isso permitiria que a
alterao dos atributos referentes data fosse feita sem que as classes que a usam
tivessem que ser alteradas. Veja como a alterao poderia ser feita no cdigo da
Listagem 6.
Listagem 6. Cdigo da verso encapsulada da classe Evento aps a alterao dos atributos referentes data do evento.
1 import java.util.Date;
2
3 public class Evento {
4
private String nome;
5
private Date data;
6
private String descricao;
7
private boolean cancelado;
8
9
public void agendar(int dia, int mes, int ano) {
10
Calendar calendario = new GregorianCalendar(ano, mes, dia);
11
data = calendrio.getTime();
12
}
13
14
//...
15 }

Assim sendo, nenhuma outra classe teria que ser alterada. Este um exemplo claro de
benefcio de enfraquecer o acoplamento atravs da aplicao do conceito de
encapsulamento.
No exemplo apresentado, seria possvel fazer algumas alteraes na classe Evento no
encapsulada (Listagem 1) para que as alteraes nos atributos referentes a data no
tivessem ocasionado o efeito em cascata de alterao nas aplicaes do sistema
acadmico e da locadora.
No entanto, essas alteraes acarretariam em um cdigo remendado com diversas
informaes repetidas (data representada tanto pelos atributos dia, mes e ano, quanto
pelo atributo data) e mecanismos de controle de alterao (como algumas aplicaes
antigas usariam os atributos dia, mes e ano e outras, mais novas, o atributo data,
deveriam existir mecanismos para mant-los com o mesmo valor).
Este mesmo efeito de um forte acoplamento poderia ser observado em relacionamentos
de herana, que estabelecem um alto grau de acoplamento entre superclasse e subclasse,
em classes internas, entre outros.
Diversos padres e estratgias de projeto esto relacionados reduo do acoplamento,
como o caso do padro Iterator, Model-View-Controller (MVC), programao para
interfaces, injeo de dependncia, entre outros.
Embora eliminar o acoplamento seja impossvel, visto que, quando uma classe
conhece outra classe, j existe algum acoplamento entre elas, devemos procurar reduzilo atravs da eliminao de relaes desnecessrias, reduo do nmero de relaes
necessrias e do enfraquecimento da dependncia das relaes necessrias.
O encapsulamento um exemplo de enfraquecimento da dependncia das relaes
necessrias. Como mais um exemplo de reduo do acoplamento, vamos analisar o
cdigo de um sistema acadmico no qual existem relaes desnecessrias.
Neste sistema, foram utilizadas duas bibliotecas matemticas (biblioteca estatistica e
matematica) para a realizao do clculo das mdias dos alunos e da produo de outros
dados estatsticos. Uma das classes do sistema utiliza essas duas bibliotecas, conforme
cdigo da Listagem 7.
Listagem 7. Cdigo de um sistema acadmico no qual so utilizadas duas bibliotecas matemticas.
1 import estatistica.*;
2 import matematica.*;
3 //... incio da classe
4
5
public void calcularMedia() {
6
// calcula a mdia ponderada do aluno.
7
MediaPonderada media = new MediaPonderada();
8
//... restante do mtodo.
9
}
10
11 //... fim da classe

Na linha 7 do cdigo da Listagem 7, a classe MediaPonderada, disponvel apenas na

biblioteca estatistica, utilizada para o clculo da mdia ponderada do aluno. Perceba
que, neste cdigo, embora desnecessariamente, todas as classes dos pacotes estatistica e
matematica so importadas, o que cria um acoplamento relacionado referncia entre a
classe em questo e as classes desses pacotes.
Agora suponha que na prxima verso da biblioteca matematica tambm seja
disponibilizada uma classe chamada MediaPonderada e que voc atualize essa biblioteca
no seu sistema. Da prxima vez que sua classe for compilada, um erro anteriormente
inexistente causado pela existncia de duas classes com o mesmo nome ocorrer. Caso
apenas as classes necessrias tivessem sido importadas na nossa classe, o acoplamento
relacionado referncia teria sido enfraquecido e o tipo de erro citado seria evitado.

Assim como para o conceito de coeso, foram definidas diferentes classificaes de

acoplamento. A primeira destas classificaes definiu cinco tipos diferentes de
acoplamento: acoplamento de contedo, acoplamento comum, acoplamento de controle,
acoplamento de imagem e acoplamento de dados.
Estes nveis variavam do melhor tipo de acoplamento (dados), que significava que dois
mdulos comunicavam-se atravs da passagem de dados por parmetros simples, ao
pior tipo de acoplamento (contedo), que ocorria quando um mdulo fazia referncia ao
interior de outro mdulo. Isso era possvel em linguagens de montagem e algumas
outras linguagens, como COBOL, nas quais existiam instrues para alterar um
comando de outro mdulo ou mesmo desviar a sequncia de instrues para um ponto
qualquer de outro mdulo. Esse era considerado o pior tipo de acoplamento porque os
mdulos acoplados dessa forma conheciam muito sobre a estrutura interna do mdulo
respectivo.
Essa classificao foi adotada por muitos autores para sistemas orientados a objetos,
fazendo-se algumas adaptaes. Outros autores, no entanto, optaram por adotar
classificaes diferentes, propostas especificamente para sistemas orientados a objetos.
Alm dessas classificaes de coeso e acoplamento em tipos ou nveis, outras formas
de medir estas caractersticas em sistemas orientados a objetos so as diversas mtricas
propostas com este fim: LCOM (Lack of Cohesion in Methods) e suas variantes, CBO
(Coupling Between Objects), DAC (Data Abstraction Coupling), LORM (Logical
Relatedness of Methods), entre outras.
Estas mtricas tratam de diferentes aspectos relacionados coeso e ao acoplamento
que, quando analisados em conjunto, podem contribuir para a identificao de
problemas na modelagem e implementao de um sistema orientado a objetos.
Existem algumas ferramentas que auxiliam na obteno e anlise de mtricas de
acoplamento para cdigos escritos em Java, tais como o JDepend e JHawk.
O JDepend uma ferramenta de cdigo aberto que permite a anlise de diretrios com
classes e calcula diversas mtricas, algumas das quais esto descritas na Tabela 1.
Tabela 1. Algumas mtricas calculadas pela ferramenta JDepend.

Mtrica

Descrio

Acoplamentos aferentes
(Ca)
Acoplamentos eferentes
(Ce)
Nvel de Abstrao (A)

Nmero de pacotes que dependem das classes do pacote analisado. um indicador

que pode, em conjunto com outros, ser utilizado na anlise do acoplamento.
Nmero de pacotes dos quais as classes do pacote analisado dependem. Assim como
o acoplamento aferente, pode ser utilizado na anlise do acoplamento.
A proporo entre o nmero de classes abstratas (e interfaces) do pacote analisado e
o nmero total de classes dentro do pacote. Por se tratar de uma proporo, esta
mtrica assume valores entre 0 e 1. Um valor igual a 0 indica que um pacote
completamente concreto e um valor igual a 1 indica que um pacote completamente
abstrato. Pacotes com mais classes abstratas podem indicar que h um menor
acoplamento em relao implementao.
A proporo entre o acoplamento eferente (Ce) e o total de acoplamento (Ca + Ce) do
pacote analisado: Ce/(Ce+Ca). Assim como para o nvel de abstrao, esta mtrica
assume valores entre 0 e 1. Um valor igual a 1 indica que nenhum outro pacote
depende das classes do pacote analisado, mas o pacote analisado depende de
classes de outros pacotes (instabilidade). Um valor igual a 0 indica que o pacote
analisado no depende de classes de outros pacotes (estabilidade).

Instabilidade (I)

O JHawk, por sua vez, uma ferramenta paga que calcula mtricas como nmero de
mtodos externos a uma classe chamados por ela, nmero de classes referenciadas por
um cdigo e o nmero de variveis referenciadas por mtodos.

Essas ferramentas possuem plug-ins para IDEs e interfaces grficas que facilitam o
processo de anlise e clculo de mtricas.

Concluso
A coeso e o acoplamento so conceitos que devem ser observados em projetos de
sistemas orientados a objetos, j que a produo de software com baixa coeso e forte
acoplamento dificulta seu entendimento, manuteno e reuso.
A literatura sobre coeso e acoplamento bastante extensa e no existe muito consenso
em relao s classificaes, nem em relao s melhores mtricas para a avaliao
destas caractersticas em projetos de software. No entanto, o estudo destes conceitos e
seus desdobramentos pode contribuir para a produo de sistemas de software com
maior qualidade.
Daqui para frente, nos seus projetos de sistemas orientados a objetos, reserve um
pouco de ateno para analisar a coeso e o acoplamento das suas classes e verifique se
alguma modificao pode ser feita para melhorar a qualidade do seu projeto.

Referncias
http://www.eli.sdsu.edu/courses/spring98/cs635/notes/index.html
Site com vrios materiais da disciplina de Programao e Projeto Orientados a Objetos da Universidade
do Estado de San Diego.
http://clarkware.com/software/JDepend.html
Site da ferramenta JDepend.
http://www.virtualmachinery.com/jhawkprod.htm
Site da ferramenta JHawk.

Leandro Luque (leandro.luque@gmail.com) gestor acadmico e professor da Universidade de Mogi das Cruzes
(UMC) e professor da FATEC-Mogi. Tem formao em Cincia da Computao e mestrado em Computao
Aplicada pelo Instituto Nacional de Pesquisas Espaciais (INPE). Trabalha com Java h 10 anos, tendo atuado no
desenvolvimento de aplicaes de grande porte tanto no segmento empresarial quanto governamental.

Rodrigo Rocha Silva (rrochas@gmail.com) Formado em Cincia da Computao pela Universidade de Mogi das
Cruzes (UMC), mestre em Computao Aplicada pelo INPE e Doutorando pelo ITA. Trabalha com Java h mais de
6 anos, atuando como desenvolvedor, analista e arquiteto em empresas de pequeno e grande porte, nos segmentos

de gesto empresarial, sade e governo. Atua tambm como professor na UMC e na Veris Faculdades. Possui
certificao SCJP 1.4.