A Model-Driven Software Reuse Approach (in portuguese)

e links). Para representar esta variabilidade, no lado inferior da figura estão as features de
tecnologia do domínio (Seção 3.1.1): páginas (formulários ou relatórios) e links são utilizados
para exibir a informação em um navegador, e tipos de documentos e relacionamentos descrevem
a estrutura da informação.
A maioria das features, como a busca, conteúdo de usuário e moderação, representa a
variabilidade do tipo presente/ausente, que fica próxima do lado da configuração de rotina
no espectro de variabilidade. Desta forma, grande parte do suporte à variabilidade pode ser
conseguido somente através de configuração, com a ajuda de uma arquitetura bem projetada e
um conjunto de componentes reutilizáveis.
Porém, features como tipos de documentos e relacionamentos contêm variabilidades mais
complexas, para as quais todos os detalhes não podem ser capturados somente com modelos de
features, pois estes são muito genéricos (TOLVANEN; KELLY, 2005). Estruturas ou mecanismos
mais ricos são necessários, com mais poder expressivo capaz de capturar detalhes sobre os
conceitos do domínio, seus relacionamentos e restrições.
Nestes casos, é possível simplesmente implementar manualmente o suporte a esta variação,
que é o que acontece no desenvolvimento tradicional. Para isso, um desenvolvedor utiliza suas
habilidades de programador e uma linguagem de programação, possivelmente com a ajuda de
uma biblioteca ou framework que facilite este trabalho criativo.
Mas no caso do MDD, onde se deseja automatizar o suporte à variabilidade, a tecnologia
escolhida é normalmente uma linguagem específica de domínio (DSL), pois ela pode
complementar o modelo de features com detalhes sobre variabilidades mais complexas em
partes do domínio (TOLVANEN; KELLY, 2005; CZARNECKI, 2005). Adicionalmente, uma
DSL pode ser utilizada junto com transformações para automaticamente gerar artefatos de
implementação, que é o objetivo final do desenvolvimento orientado a modelos (CZARNECKI,
2005).
O elemento que une estes artefatos é a arquitetura do domínio, que deve ser projetada
para dar suporte tanto à variabilidade baseada em features como à variabilidade baseada em
DSLs. Também deve ter preocupações sobre a existência, além dos componentes do domínio, de
artefatos específicos do MDD, como DSLs, transformações de software e geradores de código.
Um problema é que a maioria das abordagens de engenharia de domínio existentes não
define como projetar uma arquitetura de software específica de domínio com este objetivo. A
literatura possui muitos trabalhos que discutem detalhes sobre como produzir uma arquitetura
para reutilização (BASS; CLEMENTS; KAZMAN, 2003; BOSCH, 2000), mas estes não consideram o
MDD. E aqueles que consideram são normalmente focados no processo de derivação automática
117