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.

96<br />

premissas, enquanto novos comportamentos são adicionados ou ref<strong>in</strong>ados; e<br />

• Variabilidade negativa: remove comportamento da base comum, no sentido em que uma<br />

ou mais premissas que eram válidas na base comum passam a ser violadas.<br />

No exemplo do domínio web citado anteriormente, a busca avançada (Quadro 5) <strong>in</strong>troduz<br />

uma variabilidade positiva no passo 1, pois este é um ref<strong>in</strong>amento que acrescenta um<br />

comportamento adicional, não violando as premissas do cenário orig<strong>in</strong>al. Também <strong>in</strong>troduz<br />

uma comb<strong>in</strong>ação de variabilidades negativa e positiva no passo 2, pois neste cenário, não mais<br />

ocorre uma busca no conteúdo todo, apenas no conteúdo especificado pelo usuário. Os fluxos<br />

alternativos <strong>in</strong>troduzem apenas variabilidades positivas, pois eles ref<strong>in</strong>am o comportamento<br />

normal.<br />

Em essência, e pr<strong>in</strong>cipalmente na fase de análise, ambos os tipos são válidos e ocorrem<br />

naturalmente dentro de um domínio. Porém, podem levar a decisões de projeto diferentes.<br />

Enquanto variabilidades positivas podem ser implementadas de maneira mais simples, as<br />

variabilidades negativas exigem mecanismos para suprimir comportamento da base comum<br />

(COPLIEN, 2000), o que pode levar a uma maior complexidade da arquitetura f<strong>in</strong>al. Assim, o<br />

uso de variabilidades positivas é preferido (COPLIEN; HOFFMAN; WEISS, 1998; COPLIEN, 2000).<br />

Nesta tese, foram def<strong>in</strong>idos os segu<strong>in</strong>tes passos, numa forma sistemática, de se tomar a<br />

decisão sobre quais cenários fazem parte da base comum e quais <strong>in</strong>troduzem variabilidades:<br />

1. Começar com as features mandatórias, pois estas estarão presentes no domínio. Estas irão<br />

fazer parte dos casos de uso – os cenários que descrevem o comportamento “normal”;<br />

2. Para cada feature opcional, criar um caso de mudança;<br />

3. Para as features alternativas onde é obrigatória a existência de ao menos uma variante,<br />

escolher aquela que representa a maioria dos casos para fazer parte da base comum.<br />

No exemplo acima, se a busca simples está presente em mais produtos do que a busca<br />

avançada, esta seria escolhida para <strong>in</strong>clusão como um caso de uso. A busca avançada<br />

seria modelada como caso de mudança; e<br />

4. Caso o processo resulte em casos de mudança que apresentam variabilidade negativa,<br />

avaliar a possibilidade de transformação em variabilidade positiva, pois esta é preferível<br />

(COPLIEN; HOFFMAN; WEISS, 1998; COPLIEN, 2000).<br />

Para realização do último passo, o segu<strong>in</strong>te método pode ser utilizado.

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

Saved successfully!

Ooh no, something went wrong!