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.

pelos stakeholders e a existência dos subdomínios. A cada nova iteração do ciclo<br />

pr<strong>in</strong>cipal, a fase de projeto produz ref<strong>in</strong>amentos na arquitetura, considerando-se os novos<br />

modelos do domínio, novos níveis de decisão sobre os subdomínios ou mais detalhes<br />

sobre as diretrizes arquiteturais que possam ter sido percebidos na iteração anterior. Estes<br />

ref<strong>in</strong>amentos podem <strong>in</strong>clusive resultar no surgimento de novos módulos; e<br />

7. Fase de implementação do domínio: na primeira iteração, esta fase cuida da<br />

implementação das pr<strong>in</strong>cipais partes do domínio, conforme identificado na análise,<br />

com a produção de componentes de software, DSLs, transformações e geradores de<br />

código. A cada iteração do ciclo pr<strong>in</strong>cipal, são <strong>in</strong>troduzidos ref<strong>in</strong>amentos e mudanças na<br />

implementação, para refletir novas decisões de projeto tomadas nesta iteração. Deve-se<br />

tomar cuidado especial para que as mudanças não causem <strong>in</strong>consistências entre as DSLs,<br />

transformações, geradores de código e os componentes.<br />

O resultado de sucessivas iterações no ciclo pr<strong>in</strong>cipal é um crescimento contínuo no<br />

número de artefatos do domínio e também no nível de confiança dos subdomínios a serem<br />

automatizados. Além disso, cada vez mais subdomínios são descartados, à medida que a<br />

experiência demonstra que eles são muito difíceis ou impossíveis de automatizar. Idealmente,<br />

no f<strong>in</strong>al de várias iterações todos os subdomínios são <strong>in</strong>cluídos ou excluídos do processo, ou<br />

seja, a tendência é não existirem candidatos nos níveis <strong>in</strong>termediários de decisão.<br />

Dependendo do domínio, esta evolução pode apresentar algumas características dist<strong>in</strong>tas.<br />

Por exemplo, em sistemas críticos, onde é preferível o uso somente de l<strong>in</strong>guagens e<br />

ferramentas bem conhecidas, as iterações podem parar após estas terem sido <strong>in</strong>cluídas, sem<br />

que haja <strong>in</strong>vestigação ou desenvolvimento extra para desenvolver l<strong>in</strong>guagens e ferramentas<br />

personalizadas. Em projetos com pouco prazo para entrega, uma única iteração pode ser viável,<br />

resultando em vários subdomínios sendo deixados para trás.<br />

Uma sugestão sobre a evolução do domínio, visando reduzir os riscos e problemas<br />

associados à adoção do MDD, é <strong>in</strong>cluir, nas primeiras iterações, apenas subdomínios mais<br />

conhecidos, com ferramentas e l<strong>in</strong>guagens de modelagem disponíveis. Desta forma, pode-se<br />

perceber os benefícios do MDD sem a necessidade de um <strong>in</strong>vestimento <strong>in</strong>icial maior, além de<br />

proporcionar uma evolução mais rápida nestas primeiras iterações.<br />

4.4.2 Ciclo de projeto do modelo de processo: evolução arquitetural<br />

Dentro do ciclo pr<strong>in</strong>cipal, a fase de projeto também ocorre de forma iterativa. A cada<br />

iteração no ciclo de projeto, novos módulos são identificados, formando a arquitetura do<br />

77

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

Saved successfully!

Ooh no, something went wrong!