Geração de Código e MDD
Uma questão interessante no desenvolvimento de software é o fato de que não conseguimos garantir as coisas que fazemos (!) ok, eu explico… Em geral nós fazemos a análise, o projeto, implementamos, testamos (será?), e entregamos ao cliente. Existem algumas variações, mas basicamente é isso que se faz e tem sido razoável.
Existe uma disciplina que prova formalmente que um algoritmo está certo, mas infelizmente isso é pouco prático para grandes sistemas de informação, portanto usamos uma abordagem muito mais prática (em todos os sentidos dessa palavra) nós fazemos o software e testamos, brilhante não ? 
Acontece que isso também não é exatamente simples de fazer, durante as etapas de análise e projetos alguém precisa ser responsável por conceber os testes que serão feitos para garantir que os requisitos funcionais e não-funcionais funcionarão da forma necessária. Até aà tudo bem e nada de novo.
Mas agora pensemos no código que escrevemos, existe a camada funcional, ou seja, código que implementa as funcionalidades que o sistema deve oferecer para resolver o problema do cliente. E existe a camada não-funcional, código que implementa o suporte à camada funcional e que pode ser meramente de interação com outros componentes de suporte tais como: trechos para acesso a bancos de dados, envio de email, acesso a máquinas remotas e assim por diante.
A primeira coisa que nos ocorre quando estamos escrevendo o código não-funcional é: “Bom isso aqui parece muito com o código que eu fiz semana passada para outro problema bem parecido, e se eu…” é isso mesmo, os códigos não-funcionais têm uma tendência enorme para serem repetitivos, embora nem sempre sejam simples ou triviais eles podem ser gerados ! E geração de código é uma coisa interessante uma vez que o código gerado tem uma chance muito maior de estar certo (depende do quanto confiamos na ferramenta que gera o nosso código).
Aqui começa então a reflexão: código gerado está realmente certo?
É fácil usar o Eclipse ou NetBeans para gerar um pequeno par de métodos get/set ou mesmo para algumas gerações maiores nas quais o programador imediatamente olha e consegue “garantir” que foi tudo feito corretamente, mas com isso começamos a gerar códigos maiores que não podemos conferir na integra (nem teria sentido). Isso se torna mais crÃtico ainda quando usamos Model Driven Development (MDD ou em português Desenvolvimento Dirigido por Modelos) nessa técnica usamos os modelos para dirigir o desenvolvimento de software e cortamos etapas através da geração do código baseado em frameworks que estão disponÃveis. Isso parece ótimo ! Exceto por um detalhe quase imperceptÃvel: e se o modelo estiver errado? O código vai ser gerado corretamente para uma funcionalidade errada! Ok isso é possÃvel também com as técnias tradicionais de desenvolvimento, mas como existe a codificação manual várias vezes o desenvolvedor para e se questiona se aquilo que está sendo feito está correto e volta para falar com o analista. Se o código for recebido pronto não há esse questionamento, mais do que isso, não há dúvidas quanto a corretude do códigoo que no final das contas é uma situação perigosa!
O que pode ser feito ? Bom, certas partes do código vão continuar sendo feitas manualmente para juntar todas as partes que estão sendo geradas (ainda não temos 100% de código gerado a partir dos modelos) então as partes manuais precisam ter casos de teste unitários rigorosos. Além disso é bom fazer uma inspeção de validação nos resultados da ferramenta de geração de código que estamos usando, se isso for possÃvel (ferramentas open-source) se não for possÃvel então provavelmente existe um contrato de manutenção e garantia de uso 
Uma outra abordagem mais cansativa é usar testes unitários criados manualmente para códigos gerados automaticamente, mas porque fazer isso? Simples, quando uma pessoa faz o modelo pensa num conjunto de condições e isso é usado para gerar o código posteriormente, quando outra pessoa olha os casos de uso ou estórias de usuários (dependendo da metodologia usada) vai apreender um conjunto potencialmente diferente de condições que podem e devem ser usadas no teste, assim esse teste unitário de um código gerado por ferramenta vai servir para garantir que a modelagem que foi feita a partir dos requisitos está expressando o que é necessário.
Essa abordagem funciona? Na prática será que isso não diminui a produtividade que ganhamos por usar o MDD? Bom essas são questões ainda em aberto para mim, mas que acho que devem ser investigadas e debatidas até porque o fato é que o software precisa ser testado já que não somos capazes de provar formalmente que o código está funcionando.
MDD é baseado em Model Driven Architecture (MDA) proposto pela omg, mais informações aqui.
Uma ferramenta open-source para isso é o AndroMDA que pode ser acessado aqui.
[...] A primeira coisa a entender é que esta ferramenta é visual, no sentido de que define componentes visuais para representar os conceitos identificados em um sistema e as formas como esses conceitos se relacionam. Isto não quer dizer que a ferramenta tenha uma plataforma visual, sendo apenas uma especificação que diversos fabricantes usam para definir suas próprias plataformas (gratuitas ou pagas) para suportar o uso da ferramenta (UML). Isso significa, inclusive, que os fabricantes estão livres para representar internamente essas estruturas que compõe a especificação da forma que acharem mais conveniente. As evoluções no sentido de interpretar modelos para gerar código propostas pela MDA tentam convencer fabricantes para convergir para uma representação unificada (ou pelo menos de fornecer a capacidade de exportar em um modelo comum em XML) a fim de que possa ser possÃvel processar a informação, já que a leitura de imagens seria totalmente sem cabimento. [...]