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.
162<br />
identificação das variabilidades no código f<strong>in</strong>al. Porém, conforme discutido na atividade<br />
ID.3, a implementação de referência também serve como base para o desenvolvimento de<br />
um framework do domínio. Nesta atividade, portanto, o objetivo é transformar o restante da<br />
implementação de referência em um framework reutilizável.<br />
De acordo com as características essenciais de um framework 1 , a implementação de<br />
referência está relativamente próxima de se tornar um framework de domínio, pois:<br />
• As classes da implementação de referência encapsulam conhecimento sobre um domínio<br />
de problema;<br />
• Ela foi desenvolvida com base em uma arquitetura bem def<strong>in</strong>ida a partir de um processo<br />
centrado no suporte à variabilidade e com o objetivo de implementar diferentes diretrizes<br />
arquiteturais;<br />
• A implementação de referência não def<strong>in</strong>e somente as classes de forma isolada, mas<br />
também as <strong>in</strong>terfaces e conexões entre as mesmas, em uma estrutura que representa parte<br />
do conhecimento daquele domínio; e<br />
• A implementação de referência possui suporte para pontos fixos e pontos variáveis,<br />
a exemplo de um framework, que podem ser estendidos e <strong>in</strong>stanciados por um<br />
desenvolvedor de aplicações;<br />
Portanto, para transformar a implementação de referência em um framework de domínio, a<br />
pr<strong>in</strong>cípio só é necessário tornar explícito os pontos variáveis, em termos de código não-gerado,<br />
uma vez que o restante das variabilidades será implementada somente pelos transformadores e<br />
geradores de código.<br />
O código não-gerado, idealmente, já foi estruturado utilizando padrões de software que<br />
facilitam a seleção e implementação de algumas variabilidades, na atividade PD.3. Desta forma,<br />
aqui é necessário especificar as <strong>in</strong>terfaces resultantes da aplicação dos padrões. Por exemplo,<br />
caso tenha sido utilizado o padrão Decorator para features alternativas complementares,<br />
aqui são def<strong>in</strong>idas as <strong>in</strong>terfaces de cada alternativa, com seus métodos sendo descritos<br />
<strong>in</strong>dividualmente.<br />
Pode ser necessário o desenvolvimento de algum mecanismo para facilitar a <strong>in</strong>stanciação<br />
dos pontos variáveis. Por exemplo, pode-se criar um objeto S<strong>in</strong>gleton para facilitar a<br />
<strong>in</strong>stanciação das features implementadas utilizando-se o padrão Abstract Factory. Pode-se<br />
1 Uma discussão mais aprofundada sobre frameworks e seu papel na reutilização de software é apresentada no<br />
Apêndice A.