Amazing

O conceito de organização modular é fundamental em Teoria Geral de Sistemas, por um motivo óbvio: um sistema é sempre um subsistema de um sistema mais abstrato, ou de nível hierárquico mais alto, representando-se a idéia da decomposição como uma hierarquia. Usa-se o termo modularidade para refletir a propriedade de algo ter uma organização modular. Veja que usei o termo subsistema, mas poderia ter utilizado o termo sub-módulo.

A organização modular tem como finalidade básica auxiliar o gerenciamento de sistemas complexos.

Aprendi o conceito de organização modular logo cedo ao programar em Cobol e procurar dividir a “Procedure Division” em blocos usando o comando “Perform”. Um livro, “Modular Programming“, foi base para um aprendizado mais formal sobre o assunto. A idéia é óbvia, mas ainda, por incrível que pareça, não foi completamente compreendida quer em outras áreas, quer pelos profissionais que produzem software.

Creio que um bom resumo sobre organização modular é texto inicial do Capítulo 3 e do Capítulo 4 do livro de Abelson, Sussman and Sussman. Cito algumas partes desses dois textos a seguir: a) “A Síntese efetiva de programas também precisa de princípios organizacionais que nos guie na formulação do desenho de um programa. Em particular, precisamos de estratégias para nos ajudar a estruturar grandes sistemas de tal maneira que eles tenha uma organização 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 técnicas gerais usadas por desenhadores de todos os sistemas complexos. Eles combinam elementos primitivos para formar objetos compostos, eles abstraem objetos compostos para formar blocos de construção de alto-nível, e eles preservam modularidade através da adoção de visões de larga escala para a estrutura do sistema.”

No tratado de Teoria Geral de Sistemas, Bertallanfy escreve na página 55 que o ditado “O todo é maior que a soma das partes” é na verdade o fato de que as características constitutivas não são explicadas a partir das características das partes isoladas, mas a partir dessas partes e das suas relações.

No entanto, fica no ar a questão de como identificar módulos, como fracionar um todo?

A idéia de que forma segue função é uma das mais importantes heurísticas para organizar de forma modular. O livro de Abelson, Sussman e Sussman, no início do Capitulo 3 menciona explicitamente essa estratégia.

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 independência entre suas partes para facilitar sua evolução é comum adotar-se a estratégia de módulos com forte independência de outros módulos 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 noções de acoplamento e coesão foram definidas de maneira clara, mas sem um formalismo adjacente. Essas noções foram herdadas dos conceitos de organização da teoria geral de sistemas e da cibernética.

Além do trabalho de Constantine e Yourdon é importantíssimo o trabalho do Prof. Parnas, que também tem relação com a teoria geral de sistemas. Além de ressaltar a idéia de independência de módulos no sentido tanto de coesão e acoplamento, coube a Parnas criar um conceito sobre o compartilhamento de informação que se tornou um dos conceitos gerais mais citados na literatura de software. Refiro-me ao conceito de “information hiding” ou de proteção da informação. Esse conceito prega que cada módulo ou sub-sistema deve guardar para si as informações que só a ele interessa. É claro, que o conceito, ao ser aplicado a sistemas, gera como efeito um acoplamento fraco, em função da heurística de minimizar o conhecimento compartilhado.

No mundo de orientação a objetos o conceito de acoplamento ficou um tanto confuso. Vários autores definem métricas de acoplamento como sendo uma enumeração de quantas relações existem entre as partes e não observam que o fundamental não é o número de relações que um objeto possui, mas sim a qualidade dessa relação. Aqui, qualidade entende-se pelo quanto cada objeto se deixa conhecer pelo outro. No entanto, o fato de que a orientação a objetos mistura taxonomia com mereologia dificulta a aplicação do conceito de acoplamento fraco.

Existem métricas que procuram medir acoplamento e coesão, mas métricas sobre proteção de informação são raras e menos utilizadas.

É importante ressaltar que o acoplamento forte pode algumas vezes ser necessário. Um exemplo onde o acoplamento forte é positivo é no emprego em engenharia de produção do conceito de produção “just in time”. Em alguns casos essa forte dependência entre produtores e fornecedores é justificada pela redução de custos. Em software, muitas vezes um compartilhamento de memória comum é plenamente justificável em algumas situações, caracterizando um acoplamento forte entre os componentes que dividem esse recurso.

Uma heurística fundamental: o uso do conector “e” ou “ou” em um título de um módulo (ou subsistema) é um forte indicativo da falta de coesão!

Durante a pesquisa para escrever o texto acima encontrei alguns lugares que recomendo a visita. Alguns estão em Inglês.

a) Noções de acoplamento (Jacques Sauvé)
b) Noções de coesão (Jacques Sauvé)
c) Noções de modularidade (Fabio Kon)
d) Definição de Acoplamento/Coesão de Yourdon/Constantine (Thelma Chiosi)
e) Metrics (Samudra Gupta)
f) Coupling/Cohesion (David Stotts)
g) Cohesion (Page-Jones)

 (17/12/2007).  Relendo a nota, vejo que é necessário explicitar, melhor, o que é acoplamento e coesão.  Siga o elo para ver essa nova explicação.

…………

Leia sobre Sistemas de Informação.

Veja a página do autor.

This entry was posted on maio 3, 2007 at 11:20 am and is filed under acoplamento, acoplamento coesão modularidade abstração, coesão, engenharia de software, information hiding, modularidade, reuso, software engineering. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.