A Model-Driven Software Reuse Approach (in portuguese)
A Model-Driven Software Reuse Approach (in portuguese)
A Model-Driven Software Reuse Approach (in portuguese)
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