Posterior a minha postagem, o Professor Jeff Kramer publicou um artigo na CACM cujo título é “Abstraction – the key to Computing?” onde escreve sobre porque acredita que esse conceito é fundamental para a computação. Concordo plenamente. Vale a pena ler.

Estive na UFF no árduo trabalho de membro da banca de um concurso para Professor.   Nesta ocasião,  o Professor Orlando Loques mostrou-me um conto de Jorge Luis Borges que tinha pregado em sua parede. Incrível! Creio que é uma demonstração clara da necessidade da abstração.  Aqui vai o texto, leia-o com atenção.

Del rigor en la ciencia

En aquel Imperio, el Arte de la Cartografía logró tal Perfección que el Mapa de una sola Provincia ocupaba toda una Ciudad, y el Mapa del Imperio, toda una Provincia. Con el tiempo, estos Mapas Desmesurados no satisficieron y los Colegios de Cartógrafos levantaron un Mapa del Imperio, que tenía el Tamaño del Imperio y coincidía puntualmente con él. Menos Adictas al Estudio de la Cartografía, las Generaciones Siguientes entendieron que ese dilatado Mapa era Inútil y no sin Impiedad lo entregaron a las Inclemencias del Sol y los Inviernos. En los Desiertos del Oeste perduran despedazadas Ruinas del Mapa, habitadas por Animales y por Mendigos; en todo el País no hay otra reliquia de las Disciplinas Geográficas.
Suárez Miranda: Viajes de varones prudentes
Libro Cuarto, cap. XLV, Lérida, 1658 (veja a fonte)

Se preferir ouvi-lo na própria voz do grande poeta, veja este vídeo.

--------

Leia sobre Sistemas de Informação.

Veja a página do autor.

"O evento que reuniu o XXI SBES e o XXII SBBD aconteceu na semana
passada na Paraíba.

O SBES atingiu a maioridade. Gostaria de observar que essa
maioridade é apropriada.

Quem esteve em João Pessoa presenciou um congresso
dinâmico e muito bem organizado.

A maioridade é presente também no nível de debate e nos
temas discutidos. Reflete, sem dúvida, a constante preocupação
da comunidade em manter o SBES como um marco para a atividade
de pesquisa em Engenharia de Software. Escutei alguns comentários
sobre o SBES como uma incubadora de eventos, e
isso é notável, ou seja, além de fomentar que grupos de interesse
ganhem autonomia, mantém a tradição da reunião de
muitos (creio que por volta de 500 pessoas) centrados nos
assuntos da pesquisa em Engenharia de Software.

Um das perguntas freqüentes que o SBES se faz é sobre a interação da
comunidade com a indústria. No painel sobre isso, foi perguntado à
platéia, quem vinha da indústria. Creio que cerca de 2% dos presentes
levantaram a mão. No entanto, um dos membros do painel,
o Professor Don Batory, lembrou da importante missão da pesquisa
atrelada às universidades. Segundo sua visão, é aí onde reside a
principal fonte de transferência de conhecimento: os alunos, que
serão os futuros profissionais. O SBES é fundamentalmente um lugar
para o debate de resultados de pesquisas e, portanto, mais próximo
do interesse acadêmico. Creio que isso é positivo.

A integração com a indústria se dá, e se dará como, importante,
efeito colateral.

Em uma das sessões técnicas foi apresentado um trabalho
que surgiu da colaboração entre uma universidade e uma empresa
de software, porque esta empresa assistiu, no ano anterior no SBES,
uma apresentação da ferramenta da universidade. É obvio que isso
é só um exemplo, mas é um fato concreto.

Enfim: na verdade, a mensagem era para agradecer ao
comitê organizador e ao comitê de programa. Fizeram um excelente trabalho. Parabéns!

jcl "

Em comemoração aos 21 anos do SBES, coloco aí ao lado, uma página com elos para artigos publicados no simpósio bem como para as páginas dos simpósios desde de 1998. Quem tiver endereços para eventos anteriores, favor informar, que atualizarei as informações.

-----

Leia sobre Sistemas de Informação.

Veja a página do autor.

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.