Introdução a Decomposição em Software

Nesta série lhes apresento uma breve história da decomposição, pois selecionei os marcos que considerei importantes na minha evolução profissional, pois todos fazem parte do meu dia-a-dia.

Todo novo projeto eu começo com módulos, e assim vou evoluindo conforme as peculiaridades do projeto, da plataforma e tecnologias a serem utilizadas.

Gosto de utilizar técnicas diferentes para facilitar o olhar sobre o software, cada técnica facilita a observação sob um aspecto diferente possibilitando uma visualização mais clara.

A decomposição é um exercício constante que você deve fazer, não importa o tamanho da aplicação.

A tarefa de decompor um sistema é sempre muito difícil, principalmente no início da carreira. No meu caso após aprender o básico de lógica, descobri o sistema operacional Slackware baseado no kernel Linux e ambos mudaram a vida.

Digo isso por que minha primeira linguagem de programação foi ANSI C com gcc e a primeira técnica de decomposição que aprendi foi dividir a aplicação em módulos, só mais tarde fui descobrir um artigo do 1972 David L. Parnas apresentando formalmente essa técnica.

Por estar entrando no universo Unix cedo, conheci a sua filosofia Unix, que é:

Escreva programas que façam apenas uma coisa mas que façam bem feito.

Escreva programas que trabalhem juntos.

Escreva programas que manipulem streams de texto, pois esta é uma interface universal.

Devido a isso, minhas primeiras aplicações já eram modulares, e seguiam o seguinte desenho básico:

Após esse início nunca mais deixei de estudar arquitetura de software, principalmente quando aplicada a sistemas operacionais.

Voltando ao que interessa, nesse artigo pretendo apresentar a evolução do pensamento da decomposição de maneira a tentar mostrar um pouco de como eu uso a história para simplificar, dessa maneira tento evitar a criação de estruturas complexas de se manter ou estender.

Espero que esse artigo sirva de incentivo ao desenvolvimento sem código, ou seja focado no projeto do software, é nessa etapa que você deve gastar mais energia.

Cada hora gasta no projeto do software, você ganha na codificação. Um planejamento melhor possibilita escalar a execução devido a melhor divisão das tarefas, que por sua vez foi realizada após a visualização da solução a ser desenvolvida.

Na série sobre agilidade eu falei um pouco sobre escabilidade de processo, é nessa etapa que você tem a primeira oportunidade de planejar as suas primeiras tarefas.

Abaixo seguem algumas etapas que você pode considerar para facilitar a codificação:

1. Identifique os módulos e os relacione em forma de grafo acíclico
2. Identifique os fluxos de dados
3. Não pense na camada de armazenamento no início
4. Isole a camada de negócio
5. Identifique as dependências de dados
6. Considere o caso de sucesso da execução das regras de negócio como fluxo principal
7. Isole todos os tratamentos de erro

Agora voltamos a decomposição. 🙂

Por que é um Desafio?

Antes de começarmos é importante lembrar-mo-nos do teorema fundamental da engenharia de software, abaixo vou incluir a parte engraçada que complementa:

Podemos resolver qualquer problema introduzindo um nível extra de indireção...

....exceto para o problema de muitos de níveis de indireção

Quem nunca cometeu o pecado de começar a escrever um software sem projeto e terminou com algo extremamente complexo, mesmo após reescrever várias vezes?

Dependendo de como iniciamos nossos estudos em padrões de projeto, podemos acabar aplicando-os indiscriminadamente e forma isolada, sem avaliar a sistemática dos padrões.

Nunca implemente um padrão de projeto de maneira isolada, sempre pense de forma sistêmica

A série de livros Pattern-Oriented Software Architecture trata desse tema de forma fantástica, é um curso completo de arquitetura de software.

Os desafios da decomposição de software são enormes, por isso existem tantas formas de se abordar. É uma área em constante mudança, mas mudança sempre é sinal de evolução e é isso que eu quero mostrar aqui.

Como a decomposição evoluiu e influenciou minha maneira de pensar e construir software. Hoje em todo desenho de solução eu procuro considerar os 4 quatro aspectos abaixo:

• Interrelacionamento: Como tudo irá se relacionar, sejam serviços, componentes, usuários, etc. Conforme o escopo que estiver sendo trabalhado

• Manutenção: Toda solução deve suportar a prova do tempo, mudanças em outros componentes, e até mesmo mudanças sem ter de sofrer manutenção o tempo todo.

• Complexidade: O ritmo de desenvolvimento de poder ser mantido por qualquer integrante do time, o impacto fica restrito a um número limitado de componentes, o escopo da mudança deve poder ser visualizado antes do início do trabalho.

• Gestão: A solução deve contribuir e não ser um problema, não deve ser necessária uma logística para se realizar qualquer modificação.

Com base nesses itens eu consigo desenvolver uma aplicação cuja complexidade de manutenção se mantenha controlada ao longo do tempo, bem como evita que violemos as regras de dependência entre os componentes.

O aumento de complexidade é um dos problemas que acaba fazendo com que desenvolvedores achem aceitável violar uma regra de relacionamento ao invés de implementar a burocracia de efetuar a modificação devidamente.

Um exemplo de violação seria: A interface de uma aplicação que consuma dados a partir de serviços seguindo a arquitetura SDA conforme apresentado na imagem abaixo:

Como pode ver a interface da aplicação e serviços se comunicam via APIs, no entanto por algum motivo seja ele externo como um prazo apertado, o desenvolvedor decide consumir dados direto da interface.

Pode parecer absurdo mas, já presenciei isso em alguns projetos e em alguns casos o desenvolvedor achava que era a abordagem correta.

Evolução do Foco de Análise

Enquanto as abordagens mais diretas de decomposição evoluíam, também surgiam conceitos hoje amplamente usados como os que poderíamos chamar de separação de responsabilidades definido pelo mestre Edsger W. Dijkstra no artigo The separation of concerns.

No artigo ele sugere que determinados elementos em dado contexto deveriam ser tratados com menor relevância ou interesse. O objetivo disso é possibilitar um foco mais puro num único aspecto, mesmo existindo outros.

Hoje fazemos isso parcialmente de maneira natural quando modelamos nossos sistemas, multicamadas:

Onde definimos uma camada de negócio, uma que chamamos de persistência e outra com os objetos de dados a serem transportados.

Outros aspectos que surgiram não menos importantes são: Acoplamento e Coesão que podem ser visualizados no desenho da sua solução, sem nem mesmo escrever uma linha de código, basta responder algumas perguntas do tipo:

• Os componentes compartilham ou dependem de estado externo?
• As funções disponibilizadas pelos componentes estão de acordo com o objetivo do componente?

São simples conceitos que nos possibilitam evitar muito, muitos problemas em manutenções futuras.

Considerações Finais

Optei por deixar esse artigo tratando apenas dos aspectos iniciais com relação a decomposição e aproveitei para dar algumas dicas de maneira a evitar problemas no futuro.

Eles são comuns todas as abordagens da decomposição e não faria sentido falar deles junto com as reais abordagens.

Espero que este primeiro artigo sirva de reflexão, para a primeira etapa de modelagem de uma solução, seja ela qual for. Nunca devemos nos esquecer de usar a tecnologia como:

Ferramenta de entrega de valor.

Até a próxima.

Tags: acoplamento | arquitetura | coesao | decomposicao | decomposition | modelagem | sda | software