A Model-Driven Software Reuse Approach (in portuguese)

Nesses casos, é possível remover a dependência entre código não-gerado e gerado por meio
dos padrões de Injeção de dependência ou Localizador de serviço (FOWLER, 2004). Estes
padrões removem as dependências do código (neste caso, do código não-gerado) e as colocam
em agentes externos, responsáveis pela injeção das dependências através de configuração
programática ou textual (normalmente XML). As dependências devem ainda ser definidas
em algum lugar, mas uma vez que isto só ocorre em uma entidade separada, estas são
explícitas, sendo também mais facilmente definidas, o que acaba melhorando o entendimento
do código final. O código original pode ser compilado independentemente, facilitando testes
e manutenção. Além disso, o código de configuração poderia ser gerado, de forma que até o
processo de injeção seja automatizado. Por exemplo, é possível gerar arquivos de configuração
para frameworks de injeção de dependência como o Spring 1 .
Estes padrões assumem que há um elemento fixo entre os dois lados da dependência:
uma interface, uma classe abstrata ou uma assinatura de método. Porém, há casos onde até
mesmo as assinaturas dos métodos são geradas, como por exemplo um gerador que produz
objetos de acesso a dados (Data Access objects - DAO), com métodos para realizar operações
básicas de inserção, remoção e consulta. Cada DAO possui seus próprios conjuntos de métodos
com diferentes assinaturas dependendo dos nomes e atributos das entidades. Nestes casos,
técnicas de reflexão podem ser a única solução para remover dependências em tempo de
compilação. Através da reflexão, é possível transformar todas as chamadas de métodos de
código não-gerado para código gerado em chamadas reflexivas, de forma que o método sendo
chamado é desconhecido pelo compilador.
Código gerado depende de código gerado: isto normalmente acontece quando há dois
subdomínios que dependem um do outro.
Um problema que surge do relacionamento entre múltiplos subdomínios é como garantir a
integridade deste relacionamento. Uma possibilidade é utilizar os nomes dos elementos como
referências, isto é, o nome de uma referência em um modelo deve ser idêntico ao nome do
elemento referenciado, em outro modelo. Apesar de não ser ideal, esta abordagem simplifica
o processo de se implementar referências entre modelos. É efetivamente utilizada devido à
sua praticidade, sendo encontrada em exemplos como Apache OFBiz e algumas Microsoft DSL
Software Factories (HESSELLUND; CZARNECKI; WASOWSKI, 2007).
Outra opção são as pontes entre modelos, que consistem na criação de duplicatas
de elementos, no metamodelo que contém a referência, que correspondem a elementos
do metamodelo referenciado. No exemplo do domínio web de autoria de conteúdo,
1
135