A Model-Driven Software Reuse Approach (in portuguese)

160
Por exemplo, pode-se embutir o código referente a uma feature opcional dentro de uma tag
do tipo condicional, que aceita como parâmetro um tipo booleano em uma DSL que indica a
presença ou ausência da feature. Especificando-se este parâmetro com o valor VERDADEIRO
faz com que o gerador inclua aquele trecho de código, enquanto o valor FALSO faz com que o
gerador não o inclua. Exemplos de tags são aquelas incluídas pelo projeto JET (Java Emitter
Templates), descrito na Seção 2.2.2.
Variabilidades mais complexas podem precisar de mecanismos mais flexíveis do que as tags
para serem implementadas e parametrizadas. Neste caso, pode-se utilizar scriptlets, trechos
de metacódigo que fazem um trabalho mais elaborado de cópia/colagem, produzindo uma
saída que une fragmentos de código de forma a implementar a variabilidade exatamente como
originalmente idealizada.
Geradores baseados em templates representam transformações modelo-para-texto, em um
único passo. Porém, transformações modelo-para-modelo devem ser utilizadas para produzir
geradores mais bem organizados. Nestes casos, cuidado especial deve ser tomado para
que não seja necessário modificar os modelos intermediários, visando evitar problemas de
inconsistência. Pode-se evitar este tipo de problema através de alguns padrões e práticas de
sucesso na construção de geradores (VÖLTER, 2008; VÖLTER; BETTIN, 2004).
O processo de migração de código deve sempre manter a implementação de referência
consistente com o código gerado, ou seja, deve ser possível gerar uma nova implementação
de referência sempre que desejado, utilizando os geradores construídos. A princípio, não
existe nenhum problema, desde que a migração de código não modifique a implementação
de referência. Mas esta situação pode acontecer, já que durante a migração de código pode-se
identificar oportunidades para melhorar o suporte à variabilidade.
Por exemplo, a implementação de referência pode implementar alternativas diferentes para
um ponto de variação através de trechos de código distintos. Após a migração de código para
o template, o implementador pode perceber que a criação de funções separadas, uma para
cada alternativa, é uma solução melhor. Assim, ele modifica o template para implementar esta
solução, fazendo com que a implementação de referência se torne inconsistente.
Mesmo que a migração de código não modifique a implementação de referência, a própria
evolução do domínio normalmente causa este tipo de inconsistência. Sempre que for necessário
corrigir algum erro, seja no gerador ou em outro lugar, deve-se idealmente realizar a manutenção
primeiro na implementação de referência, testá-la e validá-la, e somente então repetir o processo
de migração, de forma que a inconsistência não exista. Mas na prática, principalmente correções
menores ou de erros do próprio gerador, modifica-se diretamente os templates, causando