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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

256<br />

abordagem, conforme descritos a seguir:<br />

Abstração: a abstração é alcançada por meio do encapsulamento das funções desempenhadas<br />

pelo componente, de forma que o desenvolvedor não tome conhecimento dos detalhes<br />

de implementação. Em outras palavras, a parte visível corresponde à <strong>in</strong>terface do<br />

componente, enquanto que a parte escondida corresponde à sua implementação. Para se<br />

conseguir essa separação, podem ser utilizados, por exemplo, os conceitos da orientação<br />

a objetos, como herança e polimorfismo. Também podem ser criadas descrições em<br />

l<strong>in</strong>guagem natural que permitam ao desenvolvedor identificar as funções desempenhadas<br />

pelo componente sem a necessidade de conhecer sua estrutura <strong>in</strong>terna;<br />

Seleção: para o processo de seleção, normalmente os catálogos de componentes dispõem de<br />

uma estrutura organizada de forma a facilitar a sua navegação. Também é comum o<br />

uso de mecanismos automáticos de busca, que reduzem o tempo necessário para que o<br />

desenvolvedor encontre aquilo que está procurando. Existe uma vasta literatura em torno<br />

desse assunto (LUCRÉDIO; ALMEIDA; PRADO, 2004);<br />

Adaptação: a adaptação do componente é normalmente feita por meio de sua parametrização,<br />

na qual o reutilizador especifica parâmetros para que o componente possa executar sua<br />

função no contexto em que está sendo reutilizado. Porém, normalmente a parametrização<br />

só é possível nos casos previstos durante o projeto do componente. Adaptar um<br />

componente para que ele execute em um cenário imprevisto pode exigir que o mesmo<br />

seja modificado <strong>in</strong>ternamente. Neste caso, se o esforço necessário para essa modificação<br />

for muito grande, pode ser mais vantajoso tentar renegociar com o cliente os requisitos<br />

da aplicação do que modificar o próprio componente; e<br />

Integração: a <strong>in</strong>tegração consiste no acoplamento das <strong>in</strong>terfaces requeridas pelo componente<br />

com as <strong>in</strong>terfaces providas pelo restante da aplicação. Normalmente esse acoplamento<br />

exige alguma modificação na aplicação.<br />

Diferentemente da abordagem “copiar e colar”, um componente, ao ser reutilizado, não<br />

precisa ser novamente testado caso não tenha sido modificado. Além disso, a existência de<br />

uma <strong>in</strong>terface bem def<strong>in</strong>ida, assim como os mecanismos de classificação e busca, fazem com<br />

que o desenvolvedor não precise confiar tanto em sua memória para encontrar um componente<br />

candidato à reutilização.

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

Saved successfully!

Ooh no, something went wrong!