A Model-Driven Software Reuse Approach (in portuguese)

118
de produtos (WEISS et al., 2008; VÖLTER; GROHER, 2007; BOTTERWECK; O’BRIEN; THIEL,
2007; ARBOLEDA; CASALLAS; ROYER, 2007; TRASK et al., 2006; TOLVANEN; KELLY, 2005;
CZARNECKI; HELSEN; EISENECKER, 2004b), e não na tarefa de produzir uma arquitetura de
domínio que é adequada para o MDD, ou seja, que contemple elementos capazes de integrar
DSLs, transformações e geradores de código.
Além disso, a maioria destas abordagens, como as descritas por Almeida et al. (2007b),
Keepence e Mannion (1999), Lee e Kang (2004), baseia-se na identificação da variabilidade
somente em termos de features. Como já discutido anteriormente, há outros tipos de variação,
como aquelas presentes em modelos entidade-relacionamento, por exemplo (BARTHOLDT;
OBERHAUSER; RYTINA, 2008), que são mais complexas do que é possível capturar em um
modelo de features (RABISER; GRÜNBACHER; DHUNGANA, 2007), sendo necessária uma DSL
específica para representar a variabilidade de modo adequado ao MDD.
6.1 Objetivos do projeto de domínio
Existem conceitos relacionados ao MDD que devem ser considerados durante o projeto do
domínio, especialmente durante a definição da arquitetura do domínio. Além da variabilidade
mais complexa discutida anteriormente, nesta abordagem a arquitetura e seus componentes
contam com a existência de DSLs e transformações, que por sua vez devem ser capazes de
produzir artefatos de implementação voltados àquela arquitetura específica.
A fase de projeto do domínio tem os seguintes objetivos:
• Identificar as diretrizes arquiteturais: o projeto arquitetural deve ser direcionado pelos
objetivos de negócio e requisitos mais importantes, considerando-se o ponto de vista
de diferentes stakeholders. Estes são chamados de diretrizes arquiteturais (BASS;
CLEMENTS; KAZMAN, 2003), e são responsáveis por “moldar” a arquitetura de forma a
atender a todos os requisitos da melhor forma possível. Nos contextos de reutilização
e MDD, as diretrizes devem incluir, obrigatoriamente, as variabilidades em forma de
features e DSLs, e a existência de artefatos do MDD, como DSLs e transformações de
software;
• Selecionar/definir táticas e padrões: o projeto arquitetural deve cobrir as diretrizes
arquiteturais, em forma de táticas e padrões que contemplem soluções para cada requisito.
Um padrão consiste em uma solução comprovadamente bem sucedida para determinados
tipos de problema, com um contexto bem definido. Por trás de um padrão existem