A Model-Driven Software Reuse Approach (in portuguese)

ase em exemplos do código a ser gerado, com a diferença de que no Pulse-MDD ele é
guiado pela identificação de padrões e critérios econômicos, enquanto nesta tese o processo
está centrado nos diferentes tipos de variabilidade.
A principal diferença desta tese com relação ao Pulse-MDD é que neste último a
preocupação com o MDD começa somente na fase de projeto, enquanto nesta abordagem
argumenta-se que ela deve começar antes, durante a análise, uma vez que os modelos de features
possuem papel importante nesta definição, e normalmente precisam ser adaptados para refletir a
existência dos artefatos MDD. Além disso, iniciando-se na análise, a preocupação com o MDD
pode incluir a identificação e divisão de subdomínios automatizáveis. Segundo defende-se nesta
tese, reconhecer esta divisão natural do domínio é um requisito importante para possibilitar o
uso do MDD em cenários práticos.
Deelstra et al. (2003) discutem como uma abordagem para o desenvolvimento de linhas de
produtos pode se beneficiar do desenvolvimento orientado a modelos. Os autores argumentam
que o MDD pode levar a vários benefícios, e apresentam como ele pode ser utilizado para
representação da variabilidade e derivação automática de produtos. O suporte à variabilidade
com o MDD é através de modelos do domínio, a exemplo da abordagem desta tese. Porém,
os autores passam diretamente da representação da variabilidade à derivação de produtos, sem
entrar em detalhes sobre, por exemplo, a construção de uma arquitetura adequada para este
cenário, como é o caso desta tese.
O mesmo acontece com outros trabalhos encontrados na literatura. Muitas abordagens que
combinam o MDD com engenharia de domínio (ou linhas de produtos de software) possuem
foco maior no estágio de derivação automática de produtos, dando pouca ou nenhuma ênfase ao
projeto do domínio de acordo com os princípios do MDD. Exemplos destas abordagens incluem
(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).
Uma das exceções é o método Kobra (ANASTASOPOULOS; ATKINSON; MUTHIG, 2002).
Originalmente projetado para desenvolvimento de sistemas individuais, o Kobra se integra
bem a um método voltado para linhas de produtos, como o Pulse-DSSA (ANASTASOPOULOS;
ATKINSON; MUTHIG, 2002). O Kobra possui atividades específicas para o projeto arquitetural
orientado a modelos. Os autores argumentam que dessa forma é possível obter independência
de plataforma, pois o Kobra se baseia em modelos UML para especificação, realização e
implementação de componentes de software no contexto de uma linha de produtos.
Assim como a abordagem desta tese, o Kobra utiliza cenários para viabilizar a criação
215