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

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

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

Saved successfully!

Ooh no, something went wrong!