A arquitetura de software sempre foi vista como uma disciplina complexa e desafiadora, pois engloba as principais decisões a cerca de um projeto de software. Essas decisões se tornarão a base para todo o projeto a partir do momento em que a arquitetura for definida. Muitas vezes a arquitetura de software projetada é tida como inalcançável tamanha sua complexidade. Isto causa, algumas vezes, a impressão de que o projeto em si nunca estará de acordo com a arquitetura prevista, pois o tempo entre planejamento arquitetural e desenvolvimento de software traz consigo muitas mudanças. Essas mudanças acabam por refletir em alterações no código-fonte que não são mapeadas nos documentos arquiteturais, uma das premissas para a manutenibilidade. Essas mudanças são responsáveis pelo surgimento da disparidade arquitetural, conceito comumente utilizado quando o código fonte e a arquitetura de software estão em descompasso.
À medida que o software evolui, ele se torna cada vez mais complexo, a não ser que se dedique esforço para manter ou reduzir sua complexidade. À medida que a complexidade aumenta, aumenta também a dificuldade de se realizar atividades de evolução e manutenção. O aumento da complexidade ocorre porque, inevitavelmente, o software sofre mudanças ao longo de sua evolução para que defeitos sejam corrigidos, novas funcionalidades sejam incluídas ou outros tipos de adaptações sejam realizadas. A realização de sucessivas mudanças leva à deterioração da arquitetura do software, principalmente devido ao aumento excessivo do tamanho de seus módulos e da inclusão de interações e dependências entre módulos de forma a infringir padrões e princípios de design e arquitetura desejados e planejados para o software.
A disparidade arquitetural sempre esteve presente no meio do desenvolvimento de software e, com o surgimento dos paradigmas ágeis junto com o mito de que a agilidade dispensa a documentação, essa disparidade se tornou mais evidente.
Antes das práticas ágeis tornarem-se populares, já surgiam novas abordagens para lidar com a arquitetura de software a fim de melhorar as disparidades entre código e
documentação. Uma das primeiras propostas foi o MDD (Model Driven Development). Conhecida como desenvolvimento dirigido por modelos, essa abordagem consiste na ideia
de que os modelos abstratos para representação do software sejam criados antes de qualquer linha de código e tendo o mesmo nível de detalhe como definição de tipo de dados e
tamanho de campos. Outro objetivo do MDD é eliminar a necessidade da programação por meio da utilização de modelos extremamente detalhados e que possam ser transformados em
código funcional com o auxílio de ferramentas CASE. Apesar de melhorar os modelos de representação (diagramas UML), tornando-os muito mais detalhados, essa técnica não se
mostrou eficiente em todos os domínios, especialmente em relação à geração automática de código, já que o código criado era problemático e difícil de manter devido à
nomenclatura repleta de códigos internos das ferramentas de geração cujo resultad ...
