APRESENTAÇÃO E COMPREENSÃO DO ARTIGO

O Que Ele Quer Estabelecer  Discutir “modularização” como mecanismo de aprimoração de um sistema enquanto encurta o tempo utilizado em desenvolvimento.  Demonstrar duas maneiras de resolução de um problema de design de sistema e demonstrar como uma é mais eficaz que a outra.  Discutir critérios usados para chegar em tal decomposição.

Introdução  Em um certo paragrafo sobre a filosofia de programação modular encontrado no livro de design de de sistemas por Gouthier e Pont, afirma sobre aspectos de que a segmentação bem definida em um projeto certifica modularidade no sistema, e que cada tarefa formava um modulo distinto e separado, seguindo de o sistema ser mantido em forma modular.  Mas usualmente nada é comentado sobre critéria para usar em dividir sistemas em módulos.

Breve Relatório de Situação  Avanços na época na area de programação modular eram técnicas de códigos e montadores.

Benefícios Esperados de Programação Modular  Gerencial  Flexibilidade  Compreensibilidade

Exemplo com KWIC  Utilizamos um sistema pequeno de KWIC (KeyWord in Context) como uma maneira de demonstrar dois métodos de decomposição, Um convencional e um inconvencional.

Primeiro Método  Módulo 1 - Entrada  Módulo 2 - Circular Shift  Módulo 3 - Alfabetização  Módulo 4 - Sáida  Módulo 5 - Controle Mestre

Segundo Método  Módulo 1 - Armazenamento de Linha  Módulo 2 - Entrada  Módulo 3 - Circular Shifter  Módulo 4 - Alfabetizador  Módulo 5 - Saída  Módulo 6 - Controle Mestre

Comparição entre as duas  Geral  Os dois métodos funcionam, o primeiro é convencional e o segundo é usado com sucesso em um projeto de classe.  Inconstância  Os métodos ainda iram ter decisões de design questionáveis e que podem mudar dependendo da circunstância.

 Desenvolvimento independente  O primeiro metodo possui interfaces entre os módulos são formatos com certa complexidade, e como representam decisões de design são altamente importantes, com o seu desenvolvimento sendo uma grande parte do desenvolvimento do módulo, precisando de esforço conjunto dos vários grupos desenvolvedores.

 O segundo método as interfaces são mais abstratas, focando mais em nomes de funções e nûmeros e tipos de parâmetros, o que são decisões mais simples e o desenvolvimento independente começa mais cedo.

 Compreensibilidade  O primeiro necessita de compreensão dos módulos alfabetizador, circulator shifter, e entrada para que o módulo saída seja entendido, nesse particular caso o autor acredita que para entender ele, precisa entender como um todo, algo que subjetivamente não parece verdade no segundo.

A Critéria  O primeiro método utiliza uma decomposição focada em fazer cada grande passo no processamento um módulo, sendo convencional, se pensa em um usar um fluxograma e então ir atrás de implementação detalhada.  O segundo método foca em “esconder informações”, módulos não correspondem mais a passos no processamento,como o módulo de Armazenamento de Linha ser usado em quase toda ação pelo sistema, pois todo módulo do segundo método é caracterizado por ter seu conhecimento de alguma decisão de design escondida de todos os outros.

Conclusão Com esses exemplos, demonstramos que quase sempre é incorreto começar uma decomposição de um sistema em módulos pela base de um fluxograma, e que ao invés disso, comece com uma lista de decisões de designs difíceis ou que tem mais chance de mudar, com módulos designados para esconder tal tipo de decisão dos outros.