Acoplamento e Coeso

Acoplamento uma medida inter componentes. Isto , uma medida entre

componentes de um conjunto. No caso de um sistema uma medida do
relacionamento entre subsistemas. No caso de um programa composto de funes,
uma medida do relacionamento entre funes. Os dois espectros dessa medida: so
alto acoplamento e baixo acoplamento. Componentes que tm baixo ou fraco
acoplamento so considerados mais independentes um do outro. O inverso vale para
alto ou forte acoplamento.
Coeso uma medida intra componentes. Isto , procura medir um componente
individualmente. No caso de um sistema, mede-se a coeso de cada sub-sistema. No
caso de um programa organizado por funes, mede-se a coeso de cada funo. A
coeso pode ser alta ou baixa. Obter coeso alta imprescindvel em todo sistema
bem organizado. Entende-se coeso alta, quando os integrantes de um componente
esto relacionados a um tema comum, isto tem o mesmo objetivo, fazem uma nica
coisa. A coeso alta tambm conhecida como coeso funcional. Um bom indicativo
de componentes com baixa coeso o ttulo ou nome do componente: todo
componente que se utiliza do conector e ou do conector ou um forte candidato para
ser classificado como tendo baixa coeso. Veja que o ttulo dessa nota
(propositalmente) apresenta uma baixa coeso.
O conceito de organizao modular fundamental em Teoria Geral de Sistemas, por
um motivo bvio: um sistema sempre um subsistema de um sistema mais abstrato,
ou de nvel hierrquico mais alto, representando-se a idia da decomposio como
uma hierarquia. Usa-se o termo modularidade para refletir a propriedade de algo ter
uma organizao modular. Veja que usei o termo subsistema, mas poderia ter utilizado
o termo sub-mdulo.

Organizao Modular
A organizao modular tem como finalidade bsica auxiliar o gerenciamento de
sistemas complexos.
Creio que um bom resumo sobre organizao modular texto inicial do Captulo 3 e
do Captulo 4 do livro de Abelson, Sussman and Sussman. Cito algumas partes
desses dois textos a seguir: a) A Sntese efetiva de programas tambm precisa de
princpios organizacionais que nos guie na formulao do desenho de um programa.
Em particular, precisamos de estratgias para nos ajudar a estruturar grandes
sistemas de tal maneira que eles tenham uma organizao modular, isto que eles
possam ser divididos naturalmente em partes coerentes que possam ser
separadamente desenvolvidas e mantidas e b) Em nosso estudo de desenho de
programas, nos vimos que especialistas controlam a complexidade de seus desenhos
usando tcnicas gerais usadas por desenhistas de todos os sistemas complexos. Eles

combinam elementos primitivos para formar objetos compostos, eles abstraem objetos
compostos para formar blocos de construo de alto-nvel, e eles preservam a
modularidade atravs da adoo de vises de larga escala para a estrutura do
sistema.
No tratado de Teoria Geral de Sistemas, Bertallanfy escreve na pgina 55 que o ditado
O todo maior que a soma das partes na verdade o fato de que as caractersticas
constitutivas no so explicadas a partir das caractersticas das partes isoladas, mas a
partir dessas partes e das suas relaes.
No entanto, fica no ar a questo de como identificar mdulos, como fracionar um todo?
A idia de que forma segue funo uma das mais importantes heursticas para
organizar de forma modular. O livro de Abelson, Sussman e Sussman, no incio do
Capitulo 3 menciona explicitamente essa estratgia.
No entanto, como saber se nosso todo est bem organizado modularmente. Ou seja,
como qualificar o resultado de termos organizado o sistema de maneira modular. Qual
a modularidade desse sistema?
Em sistemas que precisam ter independncia entre suas partes para facilitar sua
evoluo comum adotar-se a estratgia de mdulos com forte independncia de
outros mdulos e com forte unicidade. Isso caracteriza sistemas onde o acoplamento
entre sub-sistemas fraco e onde cada sub-sistema fortemente coeso.
Em engenharia de software, principalmente nos escritos de Constantine e Yourdon as
noes de acoplamento e coeso foram definidas de maneira clara, mas sem um
formalismo adjacente. Essas noes foram herdadas dos conceitos de organizao da
teoria geral de sistemas e da ciberntica.
Alm do trabalho de Constantine e Yourdon importantssimo o trabalho do Prof.
Parnas, que tambm tem relao com a teoria geral de sistemas. Alm de ressaltar a
idia de independncia de mdulos no sentido tanto de coeso e acoplamento, coube
a Parnas criar um conceito sobre o compartilhamento de informao que se tornou um
dos conceitos gerais mais citados na literatura de software. Refiro-me ao conceito de
information hiding ou de proteo da informao. Esse conceito prega que cada
mdulo ou sub-sistema deve guardar para si as informaes que s a ele interessa.
claro, que o conceito, ao ser aplicado a sistemas, gera como efeito um acoplamento
fraco, em funo da heurstica de minimizar o conhecimento compartilhado.
No mundo de orientao a objetos o conceito de acoplamento ficou um tanto confuso.
Vrios autores definem mtricas de acoplamento como sendo uma enumerao de
quantas relaes existem entre as partes e no observam que o fundamental no o
nmero de relaes que um objeto possui, mas sim a qualidade dessa relao. Aqui,
qualidade entende-se pelo quanto cada objeto se deixa conhecer pelo outro. No
entanto, o fato de que a orientao a objetos mistura taxonomia com mereologia1
dificulta a aplicao do conceito de acoplamento fraco.

(Lgica) teoria ou estudo lgico-matemtico das relaes entre as partes e o todo e das
relaes entre as partes no interior de um todo.

Existem mtricas que procuram medir acoplamento e coeso, mas mtricas sobre
proteo de informao so raras e menos utilizadas.

importante ressaltar que o acoplamento forte pode algumas vezes ser necessrio.
Um exemplo onde o acoplamento forte positivo no emprego em engenharia de
produo do conceito de produo just in time. Em alguns casos essa forte
dependncia entre produtores e fornecedores justificada pela reduo de custos. Em
software, muitas vezes um compartilhamento de memria comum plenamente
justificvel em algumas situaes, caracterizando um acoplamento forte entre os
componentes que dividem esse recurso.
Uma heurstica fundamental: o uso do conector e ou ou em um ttulo de um mdulo
(ou subsistema) um forte indicativo da falta de coeso!

Baixo Acoplamento
Problema
Como minimizar dependncias e maximizar o reuso? O acoplamento uma medida de
quo fortemente uma classe est conectada, possui conhecimento ou depende de
outra classe. Com fraco acoplamento, uma classe no dependente de muitas outras
classes. Com uma classe possuindo forte acoplamento, temos os seguintes
problemas:

Mudanas em uma classe relacionada fora mudanas locais classe

A classe mais difcil de entender isoladamente
A classe mais difcil de ser reusada, j que depende da presena de outras
classes

Soluo
Atribuir responsabilidades de forma a minimizar o acoplamento

Exemplo
Considere o seguinte diagrama parcial de classes no estudo de caso:

Suponha que temos que criar um Pagamento e associ-lo a uma Venda

Que classe deveria ter essa responsabilidade?

Alternativa 1: No mundo real, um TPDV "registra" um pagamento e o padro Creator

sugere que TPDV poderia criar Pagamento. TPDV deve ento passar o pagamento
para a Venda.
Veja o resultado abaixo:

Alternativa 2: Criar o Pagamento com Venda e associ-lo Venda

Veja o resultado abaixo

Supondo que a Venda deva ter conhecimento do pagamento (depois da criao) de

qualquer jeito, a alternativa 2 tem menos acoplamento (TPDV no est acoplado a
Pagamento). Dois padres (Creator e Low Coupling) sugeriram diferentes solues.
Minimizar acoplamento ganha

Discusso
Minimizar acoplamento um dos princpios de ouro do projeto OO.
Acoplamento se manifesta de vrias formas:

X tem um atributo que referencia uma instncia de Y

X tem um mtodo que referencia uma instncia de Y
Pode ser parmetro, varivel local, objeto retornado pelo mtodo
X uma subclasse direta ou indireta de Y
X implementa a interface Y

A herana um tipo de acoplamento particularmente forte.

No se deve minimizar acoplamento criando alguns poucos objetos monstruosos (God
classes). Exemplo: todo o comportamento numa classe e outras classes usadas como
depsitos passivos de informao
Tipos de acoplamentos (do menos ruim at o pior):

Acoplamento de dados

Acoplamento de controle
Acoplamento de dados globais
Acoplamento de dados internos

Acoplamento de dados
Situaes:

Sada de um objeto entrada de outro

Uso de parmetros para passar itens entre mtodos

Ocorrncia comum:

Objeto a passa objeto x para objeto b

Objeto x e b esto acoplados
Uma mudana na interface de x pode implicar em mudanas a b

Exemplo:
class Servidor {
public void mensagem(MeuTipo x) {
// cdigo aqui
x.faaAlgo(Object dados); // dados e x esto acoplados
// (se interface de dados mudar x ter que mudar)
// mais cdigo
}
}
Exemplo pior:

Objeto a passa objeto x para objeto b

x um objeto composto ou agregado (contm outro(s) objeto(s))
Objeto b deve extrair objeto y de dentro de x
H acoplamento entre b, x, representao interna de x, y
Exemplo: ordenao de registros de alunos por matrcula
class Aluno {
String nome;
long matrcula;
public String getNome() { return nome; }
public long getMatrcula() { return matrcula; }
// etc.
}
ListaOrdenada listaDeAlunos = new ListaOrdenada();
listaDeAlunos.add(new Aluno(...));
//etc.

Agora, vamos ver os problemas:

class ListaOrdenada {
Object[] elementosOrdenados = new Object[tamanhoAdequado];
public void add(Aluno x) {
// h cdigo no mostrado aqui
long matrcula1 = x.getMatrcula();
long matrcula2 = elementosOrdenados[k].getMatrcula();
if(matrcula1 < matrcula2) {
// faa algo
} else {
// faa outra coisa
}
}
O problema da soluo anterior que h forte acoplamento

ListaOrdenada sabe muita coisa de Aluno

O fato de que a comparao de alunos feito com a matrcula
O fato de que a matrcula obtida com getMatrcula()
O fato de que matrculas so long (representao de dados)
Como comparar matrculas (com <)
O que ocorre se mudarmos qualquer uma dessas coisas?

Soluo 2: mande uma mensagem para o prprio objeto se comparar com outro
class ListaOrdenada {
Object[] elementosOrdenados = new Object[tamanhoAdequado];
public void add(Aluno x) {
// cdigo no mostrado
if(x.compareTo(elementosOrdenados[K]) < 0) {
// faa algo
} else {
// faa outra coisa
}
}
Reduzimos o acoplamento escondendo informao atrs de um mtodo
Problema: ListaOrdenada s funciona com Aluno
Soluo 3: use interfaces para desacoplar mais ainda
interface Comparable {
public int compareTo(Object outro);
}
class Aluno implements Comparable {
public int compareTo(Object outro) {
// compare registro de aluno com outro

// retorna valor < 0, 0, ou > 0 dependendo da comparao

}
}
class ListaOrdenada {
Object[] elementosOrdenados = new Object[tamanhoAdequado];
public void add(Comparable x) {
// cdigo no mostrado
if(x.compareTo(elementosOrdenados[K]) < 0) {
// faa algo
} else {
// faa outra coisa
}
}
Em C++, teria outras solues possveis:

Apontador de funo
Apontador de funo com tipos genricos (templates)

Acoplamento de controle
Passar flags de controle entre objetos de forma que um objeto controle as etapas de
processamento de outro objeto
Ocorrncia comum:

Objeto a manda uma mensagem para objeto b

b usa um parmetro da mensagem para decidir o que fazer
class Lampada {
public final static int ON = 0;
public void setLampada(int valor) {
if(valor == ON) {
// liga lampada
} else if(valor == 1) {
// desliga lampada
} else if(valor == 2) {
// pisca
}
}
}
Lampada lampapa = new Lampada();
lampada.setLampada(Lampada.ON);
lampada.setLampada(2);

Soluo: decompor a operao em mltiplas operaes primitivas

class Lampada {

public void on() { // liga lampada }

public void off() { // desliga lampada }
public void pisca() { // pisca }
}
Lampada lampada = new Lampada();
lampada.on();
lampada.pisca();
Ocorrncia comum:

Objeto a manda mensagem para objeto b

b retorna informao de controle para a
Exemplo: retorno de cdigo de erro
class Teste {
public int printFile(File aImprimir) {
if(aImprimir est corrompido ) {
return CORRUPTFLAG;
}
// etc. etc.
}
}
Teste umTeste = new Teste();
int resultado = umTese.printFile(miniTeste);
if(resultado == CORRUPTFLAG) {
// oh! oh!
} else if(resultado == -243) {
// etc. etc.

Soluo: use excees

class Teste {
public int printFile(File aImprimir) throws PrintExeception {
if(aImprimir est corrompido ) {
throw new PrintExeception();
}
// etc. etc.
}
}
try {
Teste umTeste = new Teste();
umTeste.printFile(miniTeste);
} catch(PrintException printError) {
// mail para a turma: no tem miniteste amanh!
}

Acoplamento de dados globais

Dois ou mais objetos compartilham estruturas de dados globais.
um acoplamento muito ruim pois est escondido.
Uma chamada de mtodo pode mudar um valor global e o cdigo no deixa isso
aparente.
Um tipo de acoplamento muito ruim!

Acoplamento de dados internos

Um objeto altera os dados locais de outro objeto.
Ocorrncia comum:

Friends em C++
Dados pblicos, package visibility ou mesmo protected em java

Use com cuidado!

Consequncias

Uma classe fracamente acoplada no afetada (ou pouco afetada) por

mudanas em outras classes.
Simples de entender isoladamente.
Reuso mais fcil.

Alta Coeso
Problema
Como gerenciar a complexidade?
A coeso mede quo relacionadas ou focadas esto as responsabilidades da classe
Tambm chamada de "coeso funcional" (ver frente)
Uma classe com baixa coeso faz muitas coisas no relacionadas e leva aos
seguintes problemas:

Difcil de entender
Difcil de reusar
Difcil de manter
"Delicada": constantemente sendo afetada por outras mudanas

Uma classe com baixa coeso assumiu responsabilidades que pertencem a outras
classes

Soluo
Atribuir responsabilidades que mantenham alta coeso

Exemplo
Mesmo exemplo usado para Low Coupling
Na primeira alternativa, TPDV assumiu uma responsabilidade de efetuar um
pagamento (mtodo faaPagamento())

At agora, no h problema
Mas suponha que o mesmo ocorra com vrias outras operaes de sistema:

TPDV vai acumular um monte de mtodos no muito focados

Resultado: baixa coeso

A segunda alternativa delega faaPagamento() para a classe Venda

Mantm maior coeso em TPDV

Discusso
Alta coeso outro princpio de ouro que deve ser sempre mantido em mente durante
o projeto
Tipos de coeso entre mdulos:

Coincidente (pior)
Lgico
Temporal
Procedural
De comunicao
Sequencial
Funcional (melhor)

Coeso coincidental
H nenhuma (ou pouca) relao construtiva entre os elementos de um mdulo
No linguajar OO:

Um objeto no representa nenhum conceito OO

Uma coleo de cdigo comumente usado e herdado atravs de herana
(provavelmente mltipla)
class Angu {
public static int acharPadro(String texto, String padro) {
// ...
}
public static int mdia(Vector nmeros) {
// ...
}
public static outputStream abreArquivo(string nomeArquivo) {
// ...
}
}
class Xpto extends Angu { // quer aproveitar cdigo de Angu
...
}

Coeso lgica
Um mdulo faz um conjunto de funes relacionadas, uma das quais escolhida
atravs de um parmetro ao chamar o mdulo
Semelhante a acoplamento de controle
Cura: quebrar em mtodos diferentes
public void faa(int flag) {
switch(flag) {
case ON:
// coisas para tratar de ON
break;
case OFF:
// coisas para tratar de OFF
break;
case FECHAR:
// coisas para tratar de FECHAR
break;
case COR:
// coisas para tratar de COR
break;
}
}

Coeso temporal
Elementos esto agrupados no mesmo mdulo porque so processados no mesmo
intervalo de tempo
Exemplos comuns:

Mtodo de inicializao que prov valores defaults para um monte de coisas

diferentes
Mtodo de finalizao que limpa as coisas antes de terminar
procedure inicializaDados() {
font = "times";
windowSize = "200,400";
xpto.nome = "desligado";
xpto.tamanho = 12;
xpto.localizao = "/usr/local/lib/java";
}

Cura: usar construtores e destrutores

class Xpto {
public Xpto() {
this.nome = "desligado";
this.tamanho = 12;
this.localizao = "/usr/local/lib/java";
}
}
Outro exemplo: arquivo de configurao tpico
[Macintosh]
EquationWindow=146,171,406,661
SpacingWindow=0,0,0,0
[Spacing]
LineSpacing=150%
MatrixRowSpacing=150%
MatrixColSpacing=100%
SuperscriptHeight=45%
SubscriptDepth=25%
LimHeight=25%
LimDepth=100%
LimLineSpacing=100%
NumerHeight=35%
DenomDepth=100%
FractBarOver=1pt
FractBarThick=0.5pt
SubFractBarThick=0.25pt
FenceOver=1pt

SpacingFactor=100%
MinGap=8%
RadicalGap=2pt
EmbellGap=1.5pt
PrimeHeight=45%
[General]
Zoom=200
CustomZoom=150
ShowAll=0
Version=2.01
OptimalPrinter=1
MinRect=0
ForceOpen=0
ToolbarDocked=1
ToolbarShown=1
ToolbarDockPos=1
[Fonts]
Text=Times
Function=Times
Variable=Times,I
LCGreek=Symbol,I
UCGreek=Symbol
Symbol=Symbol
Vector=Times,B
Number=Times
[Sizes]
Full=12pt
Script=7pt
ScriptScript=5pt
Symbol=18pt
SubSymbol=12pt

Coeso procedural
Associa elementos de acordo com seus relacionamentos procedurais ou algortmicos
Um mdulo procedural depende muito da aplicao sendo tratada

Junto com a aplicao, o mdulo parece razovel

Sem este contexto, o mdulo parece estranho e muito difcil de entender

No pode entender o mdulo sem entender o programa e as condies que existem

quando o mdulo chamado
Cura: reprojete o sistema!

Coeso de comunicao
Todas as operaes de um mdulo operam no mesmo conjunto de dados e/ou
produzem o mesmo tipo de dado de sada
Cura: isole cada elemento num mdulo separado
"No deveria" ocorrer em sistemas OO usando polimorfismo (classes diferentes para
fazer tratamentos diferentes nos dados)

Coeso sequencial
A sada de um elemento de um mdulo serve de entrada para o prximo elemento
Cura: decompor em mdulos menores

Coeso funcional (a melhor)

Um mdulo tem coeso funcional se as operaes do mdulo puderem ser descritas
numa nica frase de forma coerente
Num sistema OO:

Cada operao na interface pblica do objeto deve ser funcionalmente coesa

Cada objeto deve representar um nico conceito coeso

Exemplo: um objeto que esconde algum conceito ou estrutura de dados ou recurso e

onde todos os mtodos so relacionados por um conceito ou estrutura de dados ou
recurso

Meyer chama isso de "information-strength module"

Consequncias

Melhor claridade e facilidade de compreenso do projeto

Simplificao da manuteno
Frequentemente vai mo na mo com acoplamento fraco
Com granularidade baixa e funcionalidade bem focada, aumenta o reuso