A Model-Driven Software Reuse Approach (in portuguese)
A Model-Driven Software Reuse Approach (in portuguese)
A Model-Driven Software Reuse Approach (in portuguese)
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
78<br />
domínio. Trata-se de um processo de ref<strong>in</strong>amento dirigido por padrões. A divisão em<br />
módulos ocorre de acordo com a <strong>in</strong>stanciação de um ou mais padrões que atendem às diretrizes<br />
arquiteturais.<br />
O projeto se <strong>in</strong>icia com uma divisão pr<strong>in</strong>cipal, envolvendo todo o domínio. Esta divisão<br />
produz os módulos pr<strong>in</strong>cipais do sistema. Por exemplo, se for adotado o padrão em camadas<br />
(BUSCHMANN et al., 1996), a primeira divisão resulta na identificação das camadas do domínio.<br />
Se for adotado o padrão MVC (<strong>Model</strong>-View-Controller) (BUSCHMANN et al., 1996), a primeira<br />
divisão resulta na identificação dos elementos de modelo, de visão e de controle, e assim por<br />
diante.<br />
As iterações segu<strong>in</strong>tes ref<strong>in</strong>am cada módulo de acordo com o padrão escolhido. Por<br />
exemplo, ao se aplicar o padrão Observer (GAMMA et al., 1995) em um módulo, serão<br />
identificados novos módulos (ou classes), como o Sujeito, Sujeito Concreto, Observador e<br />
Observador Concreto.<br />
No caso desta abordagem focada em reutilização, os padrões visam, além de identificar<br />
novos módulos, adicionar o suporte à variabilidade prevista durante a análise. Além disso,<br />
tendo foco também no MDD, cada ref<strong>in</strong>amento identifica não somente módulos de software<br />
convencional, como classes e métodos, mas também elementos como transformações e<br />
geradores de código, além de DSLs e ferramentas de modelagem. Todos estes também fazem<br />
parte da arquitetura.<br />
Assim, a evolução do ciclo de projeto ocorre da segu<strong>in</strong>te maneira, para cada atividade:<br />
1. Atividade PD.1. Escolha dos módulos a serem ref<strong>in</strong>ados: a cada iteração, esta atividade<br />
escolhe novos módulos para serem ref<strong>in</strong>ados. Obviamente, na primeira iteração a<strong>in</strong>da<br />
não existem módulos, e a escolha é o domínio todo. As demais atividades são executadas<br />
<strong>in</strong>dividualmente para cada módulo aqui escolhido;<br />
2. Atividade PD.2. Seleção das diretrizes arquiteturais: esta atividade identifica, para cada<br />
módulo sendo ref<strong>in</strong>ado nesta iteração, os pr<strong>in</strong>cipais requisitos de software que podem<br />
<strong>in</strong>fluenciar a arquitetura naquele exato local referente ao módulo. Para cada módulo<br />
seleciona-se, dentre todos os requisitos e objetivos de negócio do domínio, aqueles<br />
que dizem respeito somente ao módulo em questão, e que possuem impacto em sua<br />
arquitetura. Estas são as chamadas diretrizes arquiteturais;<br />
3. Atividade PD.3. Escolha de táticas e padrões arquiteturais: nesta atividade o projetista<br />
do domínio escolhe, para cada módulo sendo ref<strong>in</strong>ado, e com base nas diretrizes