A Model-Driven Software Reuse Approach (in portuguese)

90
estão bem claros, porém o desenvolvimento ainda não foi iniciado) e aplicações potenciais
(aplicações para as quais ainda não existem requisitos definidos, mas que são vistas como
relevantes).
Após a identificação das aplicações, a lista de features é desenvolvida. A identificação
de features envolve abstrair o conhecimento obtido com os especialistas do domínio e outros
documentos, tais como livros, manuais de usuário, documentos de projeto e código-fonte (LEE;
KANG; LEE, 2002). Porém, o volume de informação de um domínio tende a ser muito grande.
Neste sentido, quatro diretrizes (ALMEIDA et al., 2006) podem ser úteis:
D1. Analisar as terminologias usadas no domínio para identificar features: em alguns
domínios mais maduros, especialistas normalmente utilizam terminologia padronizada para
comunicar suas idéias, necessidades e problemas. Assim, utilizando-se os mesmos termos
padrões na identificação de features, pode-se acelerar a comunicação entre o analista do domínio
e os provedores de informação (especialista do domínio e usuários finais).
D2. Categorizar as features: as features devem ser categorizadas, utilizando, por exemplo
as quatro categorias descritas na Seção 3.1.1: features de capacitação, features de tecnologia
do domínio, features de técnicas de implementação e features do ambiente operacional.
Para organizações com pouca experiência na análise de domínio, ou que estão trabalhando
com domínios instáveis e pouco amadurecidos, é aconselhável concentrar-se nas features de
capacitação. Após certa maturidade com o domínio ser alcançada, pode-se passar para as
demais features.
D3. Tentar primeiro encontrar diferenças entre as aplicações de um domínio, para só
então tentar identificar as partes em comum: aplicações de um mesmo domínio compartilham
um alto grau de funções em comum (COPLIEN; HOFFMAN; WEISS, 1998). Portanto, o espaço
em comum deve ser consideravelmente maior do que as diferenças, e por consequência é mais
fácil encontrar as diferenças primeiro. A estratégia é, inicialmente, identificar as aplicações
existentes, e listar as features que caracterizam cada uma. Encontradas as diferenças, é mais
fácil identificar as features comuns.
D4. Não identificar todos os detalhes de implementação que não se distinguem entre as
aplicações do domínio: os desenvolvedores tendem a listar todos os detalhes de implementação
e identificá-los como features, mesmo que não haja variações entre eles. Mas é importante notar
que um modelo de features não é um modelo de requisitos, que expressa os detalhes de funções
internas. Por essa razão, esta atividade deve ser realizada pelo analista do domínio, que tende a
abstrair detalhes de implementação.
Por fim, as aplicações e suas features são organizadas na forma de um mapa de