A Model-Driven Software Reuse Approach (in portuguese)
A Model-Driven Software Reuse Approach (in portuguese)
A Model-Driven Software Reuse Approach (in portuguese)
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
com exatidão o escopo a ser desenvolvido. Para tal def<strong>in</strong>ição, ao <strong>in</strong>vés de buscar atender<br />
a artefatos genéricos do domínio, de acordo com a percepção/<strong>in</strong>tuição de especialistas,<br />
esta abordagem foca em um conjunto f<strong>in</strong>ito de aplicações ou produtos que sejam de<br />
<strong>in</strong>teresse da organização (CLEMENTS; NORTHROP, 2002). Dessa forma, são menores as<br />
chances de um artefato poder ser reutilizado em aplicações não previstas, mas aumenta-se<br />
consideravelmente o seu nível de reutilização dentro deste escopo;<br />
• Criar modelos do domínio: modelos expressam os conceitos do domínio de forma a<br />
facilitar o seu entendimento por parte dos projetistas e desenvolvedores. Além disso, os<br />
modelos devem explicitar as variabilidades e comunalidades dentro do domínio (KANG<br />
et al., 1990; JACOBSON; GRISS; JONSSON, 1997; GRISS; FAVARO; D’ALESSANDRO, 1998;<br />
KANG et al., 1998; KANG; LEE; DONOHOE, 2002), de forma a facilitar o projeto de software<br />
reutilizável; e<br />
• Identificar os subdomínios onde a automação é possível: nesta abordagem, o<br />
desenvolvimento orientado a modelos é utilizado para aumentar o nível de reutilização,<br />
pr<strong>in</strong>cipalmente na implementação das variabilidades. Ao <strong>in</strong>vés de deixar esta tarefa para<br />
ser realizada pelos desenvolvedores de aplicações, o conhecimento de como implementar<br />
as variabilidades é encapsulado em ferramentas de modelagem e transformações<br />
automáticas de software (LEDECZI et al., 2001). O objetivo f<strong>in</strong>al é que, após a engenharia<br />
de domínio, um desenvolvedor possa simplesmente configurar o produto desejado e<br />
acionar as transformações que automaticamente geram uma implementação válida.<br />
Assim, esta fase de análise também tem como objetivo identificar subdomínios onde a<br />
automação é possível.<br />
A abordagem aqui proposta é uma evolução do método descrito por Almeida et al. (2006).<br />
A diferença é que aqui existe a preocupação com a identificação dos subdomínios onde a<br />
automação é possível, e portanto a análise e tratamento das variabilidades é realizada de forma<br />
diferenciada, com este objetivo em mente.<br />
5.2 Atividades da análise de domínio<br />
A análise de domínio começa com uma atividade de planejamento (Atividade AD.1) que<br />
visa coletar <strong>in</strong>formações para decidir se vale a pena <strong>in</strong>vestir no domínio e def<strong>in</strong>ir o escopo do<br />
domínio a ser construído. Em seguida, a modelagem do domínio (Atividade AD.2) cuida da<br />
criação de modelos do domínio, que descrevem as funções, as comunalidades e variabilidades<br />
do mesmo. A seguir, é feita a identificação de possíveis subdomínios (Atividade AD.3),<br />
87