Acoplamento e Coesão talvez sejam as características mais importantes de qualquer sistema.
Muitos sistemas são como um Castelo de Cartas.
Num Castelo de Cartas, ao tirar uma carta da estrutura, a probabilidade de estragos no castelo é alta. Se a carta estiver na base (parte inferior) do castelo, é quase certo que o castelo irá desmoronar.
E nos sistemas, não é muito diferente. Todo profissional da área já passou por algum sistema onde corrigi-se um bug e aparecem outros vinte; exclui-se uma funcionalidade e outras várias param de funcionar ou apresentam defeitos etc.
O que é Acoplamento?
Segundo o Google, Acoplamento é:
“(…) união ou ligação entre dois ou mais corpos, formando um único conjunto. (…)”
Basicamente é isso mesmo. Quando falamos de acoplar uma coisa em outra coisa, estamos falando de conectar estas duas coisas.
Uma Roda está acoplada a um Carro. Uma Bateria está acoplada a um Smartphone. Uma Cabeça está acoplada a um Corpo.
Na estrutura de um sistema temos acoplamento em todo lugar, em qualquer fase do projeto, em qualquer fragmento de escopo do software.
Quando falamos, por exemplo, de relacionamento entre Classes, Tabelas, Domínios, Sub-Sistemas, Casos de Uso etc. estamos falando de acoplamento.
Podemos afirmar que no contexto de um software qualquer relacionamento gera acoplamento.
Entendemos então que o acoplamento é algo determinístico ao processo de produção de software, ou seja, fatalmente estará presente neste tipo de atividade e em suas entregas. E tem que estar mesmo, pois as partes do todo precisam estar conectadas para se formar o todo (que no nosso caso, é um sistema).
Acoplamento Forte e Acoplamento Fraco
Sempre haverá acoplamento na estrutura de um software, é fato.
Mas uma coisa é haver a necessidade natural do acoplamento, outra é o “nível dessa medida”.
Devemos “medir” o nível de acoplamento sempre que lidamos com produção de software.
Mas medir isso é num nível de detalhe muito baixo é algo muito difícil, talvez impraticável para a maioria das empresas e profissionais da área.
Para viabilizar essa mensuração utilizamos duas formas de classificar o nível de acoplamento: Forte Acoplamento e Fraco Acoplamento.
Quando um sistema possui entre seus componentes uma relação de interdependência fraca, significa que a dependência entre seus componentes é baixa, ou seja, estão acoplados, mas fracamente acoplados. Isso chamamos de Fraco Acoplamento.
/* No contexto acima, entenda Componentes como qualquer unidade produzida no sistema, de qualquer tamanho. Seja Módulo, Funcionalidade, Classe, Função, Tabela etc. */
Quando um sistema possui entre seus componentes uma relação de interdependência forte, significa que a dependência entre seus componentes é alta, ou seja, estão acoplados, mas fortemente acoplados. Isso chamamos de Forte Acoplamento.
/* Dependendo da literatura consultada a terminologia pode sofrer alguma variação. Ao invés de Forte Acoplamento pode-se dizer Alto Acoplamento e ao invés de Fraco Acoplamento pode-se dizer Baixo Acoplamento. */
Mas como sabemos, software é algo que demanda manutenção constante, pois é um “organismo vivo”, só “morre” quando é descontinuado. E dificilmente sistemas são descontinuados.
Pensemos no castelo de cartas que citamos no início do post. Dar manutenção nele, tirar uma carta e colocar outra, ou ajustar o posicionamento de uma carta, é tarefa simples? Não, sem dúvida.
Mas qual a causa dessa dificuldade?
O castelo de cartas possui uma estrutura com Forte Acoplamento, onde suas partes possuem uma dependência muito alta umas com as outras, e isso torna sua estrutura complicadíssima de ser alterada.
O mesmo raciocínio se aplica a software. Um software com Forte Acoplamento torna-se um problema na hora de mantê-lo, devido ao alto grau de interdependência entre seus componentes.
Para evitar isso, devemos pensar software sempre com Fraco Acoplamento, focando num nível baixo de interdependência entre seus componentes, para que mantê-lo seja algo menos problemático de fazê-lo.
O que é Coesão?
Coesão, do ponto de vista de significado da palavra, é um termo mais abstrato do que Acoplamento. Mais complexo para compreendermos.
Segundo o Google, Coeso é:
“(…) que apresenta harmonia; ajustado, concorde. (…)”
No contexto de um software podemos entender que Acoplamento é uma medida “inter” componentes, e Coesão é uma medida “intra” componentes.
A primeira refere-se ao mundo externo do componente, como ele se inter-relaciona com os outros componentes do sistema.
A segunda refere-se ao mundo interno do componente, como ele se intra-relaciona consigo mesmo.
Sempre ouvimos falar das duas juntas: Acoplamento e Coesão.
Cada parte de um todo possui seu contexto único, seu escopo, suas responsabilidades. Na estrutura de um software, cada um de seus componentes possuirá coesão, é algo determinístico também. São partes de um todo, e cada parte possui um conteúdo.
Uma “parte vazia” é um contrassenso, pois não teria razão de existir. É necessário haver um “conteúdo” para uma parte, e havendo conteúdo, há coesão.
Alta Coesão e Baixa Coesão
No castelo de cartas, cada carta possui um conteúdo, que é utilizado no contexto do baralho.
Caso queira entender melhor sobre Sintaxe e Semântica no contexto da produção de software veja este nosso post
Um “As de Copas” é uma carta que, como as outras, possui um naipe (copas) e um número ou letra (A).
E essa carta possui apenas uma função: ser um “As de Copas”. Seu conteúdo é este. Ela faz tudo que um “As de Copas” tem que fazer, e nada mais.
Seria viável jogar baralho (qualquer modalidade que seja) com cartas com mais de um naipe, ou mais de um número ou letra? Seria uma confusão total.
/* O conceito da Coesão está intimamente ligado ao Princípio da Responsabilidade Única (SRP) do SOLID. Entretanto os profissionais da nossa área costumam achar que o SRP aplica-se apenas a Classes e Objetos, mas é aderente e necessário há qualquer artefato contido no modelo do software. Vamos falar mais disso ao fim deste post. */
Uma carta de um baralho não pode possuir dois naipes, nem ter dois números, pois assim tem mais de uma responsabilidade, faria mais de uma coisa.
Um componente de software sempre possui alguma Coesão, como falamos. Mas esta Coesão pode ser Alta ou Baixa (ou Fraca ou Forte, dependendo da literatura consultada). E qual a diferença entre ambas?
Um componente com Alta Coesão é um componente que possui apenas uma única responsabilidade, que possui em seu conteúdo/suas funções, apenas aquilo que realmente deve fazer.
Ele não assume responsabilidades de outros componentes e não as mistura com as suas, nem delega suas responsabilidades a outros componentes, e não depende dos outros componentes para realizar suas funções conforme suas responsabilidades.
Já um componente com Baixa Coesão é o inverso disso. Possui responsabilidades além das suas, depende de outros componentes para realizar suas funções etc.
E o efeito da causa “Baixa Coesão” nos componentes de um software é semelhante ao efeito gerado pela causa “Forte Acoplamento”, onde podemos destacar:
- Dificuldades para dar manutenção no software – o grau desta dificuldade será proporcional à medida de Acoplamento e Coesão.
- Dificuldade de reuso de componentes – reuso não combina com responsabilidades misturadas, com falta de unidade.
- Dificuldades de interpretação clara dos modelos utilizados no projeto – gerando baixa performance na equipe devido ao custo adicional para entender o sistema.
Quanto mais baixa for a coesão nos componentes de um software, mais problemático será mantê-lo.
Acoplamento e Coesão aplicam-se apenas à Modelagem de Classes?
Categoricamente: não!
A Modelagem de Classes tem como objetivo definir a estrutura de um sistema (considerando um sistema que será produzido utilizando alguma linguagem de programação Orientada a Objetos).
Mas o Modelo de Classes não é o único modelo produzido no projeto de um software. Temos Modelo de Dados, Modelo de Requisitos, Modelo de Casos de Uso, Modelos de Interfaces Gráficas, e alguns outros.
Não necessariamente todo projeto vai produzir todos os modelos, isso dependerá, naturalmente, do processo de desenvolvimento que a empresa adotará no ciclo de vida de seus projetos.
Mas como deve ser nas empresas que produzem, por exemplo, Modelo de Requisitos ou Modelo de Dados? Como saber “pensar” “Acoplamento e Coesão” nestes momentos do projeto, para se ter um software mais coeso e menos acoplado?
Concluindo
Neste post entendemos o conceito de Acoplamento e Coesão e entendemos ainda que para um software ter boa manutenibilidade, ter qualidade, é fundamental o modelarmos considerando sempre um sistema com Fraco Acoplamento e Alta Coesão.
Vou escrever vários posts onde exemplificarei Acoplamento e Coesão nos vários tipos de modelagem que podemos empregar num projeto de software, desde a definição de Módulos e Funcionalidades, até a Definição da Arquitetura.
À medida que eu for escrevendo estes posts volto aqui e os cito para consulta.
Se você gostou do conteúdo deste post, deixe seus comentários, para ajudar outras pessoas a encontrarem este material! 🙂
Grande abraço!