15.04.2013 Views

A Model-Driven Software Reuse Approach (in portuguese)

A Model-Driven Software Reuse Approach (in portuguese)

A Model-Driven Software Reuse Approach (in portuguese)

SHOW MORE
SHOW LESS

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.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!