A Model-Driven Software Reuse Approach (in portuguese)

de projeto arquitetural (ANASTASOPOULOS; GACEK, 2001; MUTHIG; PATZKE, 2003; RIBEIRO;
MATOS; BORBA, 2008; SVANHBERG; GURP; BOSCH, 2002). Porém, estes não cobrem o aspecto
de integração entre diferentes subdomínios. Para esta abordagem, foram selecionados alguns
padrões que auxiliam na implementação das táticas específicas para variabilidade e integração
entre subdomínios, apresentados mais adiante nesta seção.
A escolha das táticas e padrões a serem utilizados é guiada por dois fatores: o requisito
em si, explicitado pela diretriz arquitetural, e os efeitos colaterais que o emprego de uma tática
ou padrão provoca nas demais diretrizes (BASS; CLEMENTS; KAZMAN, 2003). Caso não seja
possível encontrar alguma tática e/ou padrão que sirva para um cenário específico, pode-se
modificar ou adaptar táticas e padrões existentes, ou mesmo criar novos especialmente para
este domínio. Estes passam então a fazer parte do catálogo da organização e podem ser
reaproveitados em projetos futuros.
Da mesma forma que as diretrizes arquiteturais, nesta abordagem são necessárias táticas
e padrões para pelo menos três aspectos principais: variabilidade baseada em features,
variabilidade baseada em DSLs e integração entre subdomínios. Alguns dos padrões
identificados nesta tese são baseados nos trabalhos de Völter (2003), Völter e Bettin (2004),
que são muito úteis para projetos de MDD, mas não são específicos para o projeto arquitetural
ou para a engenharia de domínio, e portanto são acrescentadas discussões sobre como alguns
desses padrões podem ser incorporados ao contexto de reutilização.
Sub-atividade PD.3.1. Padrões arquiteturais para variabilidade baseada em features
Existe uma série de padrões que podem ser utilizados para ajudar a tornar uma arquitetura
de software específica de domínio preparada para os diferentes tipos de variabilidade baseada
em features. Em particular, os padrões do GoF (GAMMA et al., 1995) podem facilitar
a representação da variabilidade no projeto arquitetural, resolvendo alguns dos problemas
relacionados à implementação das features (ALMEIDA et al., 2007b).
No caso do desenvolvimento orientado a modelos, é necessário considerar também como
os geradores de código são integrados com cada padrão, já que partes do software são
automaticamente geradas e precisam interagir com o restante do software.
O cenário é o seguinte: um modelo de features descreve os pontos comuns e variáveis.
Um gerador de código usa como entrada uma seleção de features/subfeatures que faz parte da
aplicação gerada, e precisa produzir o código correspondente. Para cada tipo de feature, um ou
mais padrões do GoF (GAMMA et al., 1995) é utilizado.
125