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.

• Como a ferramenta se enquadra no projeto? Ela gera código executável? Se não, pode<br />

ser adaptada para gerar código? Quanto esforço é necessário para se utilizar a ferramenta<br />

neste projeto?<br />

• Foi conduzido um projeto piloto para este subdomínio, utilizando-se uma l<strong>in</strong>guagem de<br />

modelagem e ferramenta para geração de código?<br />

Para determ<strong>in</strong>ar o nível de confiança de forma mais sistemática, o analista do domínio pode<br />

desenvolver uma métrica envolvendo estas e outras possíveis questões que possam surgir. Uma<br />

maneira simples é desenvolver um questionário com estas questões, atribu<strong>in</strong>do um peso para<br />

cada resposta. A soma de todos os valores é o nível de confiança.<br />

O analista do domínio deve consultar todos os stakeholders quando def<strong>in</strong>ir esta métrica,<br />

uma vez que existem diferentes fatores a serem considerados. Dependendo do cenário,<br />

diferentes situações podem requerer valores diferentes. Por exemplo, para sistemas críticos,<br />

é razoável utilizar somente l<strong>in</strong>guagens e ferramentas bem conhecidas, e portanto maiores pesos<br />

podem ser atribuídos para estas questões. Em projetos com prazos mais curtos de entrega, esta<br />

também pode ser a única opção. Porém, em projetos com mais tempo disponível, os valores<br />

podem ser ajustados para <strong>in</strong>cluir mais subdomínios, já que há mais tempo para desenvolver<br />

ferramentas e l<strong>in</strong>guagens de modelagem. Este é também o caso de domínios mais abrangentes.<br />

Sub-atividade AD.3.5. Documentação dos candidatos a subdomínio<br />

Nesta atividade, o analista do domínio documenta os subdomínios identificados, <strong>in</strong>clu<strong>in</strong>do<br />

toda <strong>in</strong>formação coletada nos passos anteriores: as features envolvidas, l<strong>in</strong>guagens e<br />

ferramentas, e o nível de confiança. Na prática, a maior parte da documentação vai sendo<br />

construída durante o processo, e portanto esta atividade é realizada em paralelo com as<br />

anteriores.<br />

Os Quadros 6 e 7 ilustram exemplos de documentação obtida nesta atividade. O Quadro<br />

6 mostra a documentação do subdomínio de navegação, onde são <strong>in</strong>formadas a descrição, as<br />

features envolvidas, l<strong>in</strong>guagens e ferramentas identificadas. O Quadro 7 mostra a documentação<br />

do nível de confiança dos subdomínios identificados. Neste exemplo, somente quatro perguntas<br />

foram utilizadas, com peso atribuído conforme <strong>in</strong>dicado no quadro.<br />

Aqui o analista também descreve a <strong>in</strong>teração entre o candidato a subdomínio e o restante<br />

do domínio. Neste ponto, esta descrição deve ser focada na cooperação em alto nível entre<br />

as features, com o objetivo de ajudar na decisão de <strong>in</strong>vestir na automação do subdomínio ou<br />

não. Em estágios posteriores, caso seja decidido que este subdomínio será automatizado, esta<br />

105

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

Saved successfully!

Ooh no, something went wrong!