Model Driven Architecture: Como criar aplicações através de modelos

Este artigo discute como o uso da Model Driven Architecture pode aprimorar as atividades de desenvolvimento de software centrando as atividades na elaboração e refinamento de modelos.

Fique por dentro
O desenvolvimento de software em sua forma tradicional, através de codificação, apresenta problemas já conhecidos de produtividade e dificuldades em manutenção. Os documentos gerados na tentativa de atacar tais problemas costumam ser extensos e desatualizados. Neste cenário surge a ideia de gerar todo o software a partir de modelos abstratos, como UML por exemplo, sem que seja necessária a codificação em linguagens de programação como Java e .Net, onde o nível de abstração é muito baixo. Os modelos, então, seriam evoluídos até se tornarem ricos o suficiente para que todo código fosse gerado a partir dos mesmos. Essa é a estratégia do framework MDA da OMG, descrito neste artigo.

O desenvolvimento de software foi, ao longo dos anos, frequentemente comparado ao desenvolvimento de hardware. Enquanto a criação de componentes físicos apresentou grandes progressos em produtividade, a produção de software parece não ter evoluído tanto. A evolução na construção de software pode ser facilmente observada quando analisadas características como aumento de complexidade e tamanho dos produtos, porém, esta evolução não pode ser igualmente percebida quando a análise foca na velocidade e no custo da produção. Escrever software é uma atividade intensa, e com o surgimento de novas tecnologias, mais trabalho precisa ser feito e refeito. Um único produto deste trabalho não é composto por apenas uma tecnologia, o que demonstra o aumento da complexidade e, consequentemente, o impacto na velocidade de desenvolvimento e custo.

Os processos de desenvolvimento de software mais tradicionais, como RUP (Rational Unified Process) por exemplo, são guiados por um baixo nível de abstração de design e código. Grande parte destes processos, não apenas o Processo Unificado citado, incluem um número de fases/etapas que podem ser sumarizadas da seguinte forma:

1. Elicitação de Requisitos;

2. Análise e Projeto do Sistema;

3. Codificação;

4. Testes;

5. Implantação.

Com variações iterativas incrementais, cascatas ou alguma versão ágil, este esboço de processo produz documentos e diagramas nas fases 1 e 2. Estes documentos incluem descrições em linguagem natural das funcionalidades e diagramas UML como casos de uso, diagrama de classes, entre outros. Tradicionalmente esses documentos não são executáveis e tendem a perder o link com a implementação real do sistema à medida que o processo avança nas fases. Neste momento, os documentos deixam de ser a exata especificação do código e passam a ser uma documentação superficial do sistema, muitas vezes errada.

Dado o problema mencionado, a distância da documentação para o código, populariza-se então a ideia de eXtreme Programming (XP). Uma das razões que levaram a isso foi o foco no código fonte, que permanece sendo atualizado até depois da implantação do projeto. Este é o artefato central de qualquer processo de desenvolvimento. Entretanto, o XP resolve apenas parte do problema. Com o desmembramento da equipe, novos integrantes necessitam de indicações de alto nível para manter o software, sem as quais a nova equipe estaria completamente perdida. Com isso, fica claro que apesar da latente necessidade do foco no artefato executável do software, a documentação/modelos ainda é necessária. "

[...] continue lendo...

Artigos relacionados