A Model-Driven Software Reuse Approach (in portuguese)

140
• Número de cenários indiretamente suportados: para cada arquitetura, conta-se o
número de cenários que requerem alguma alteração para passarem a possuir o suporte
adequado pela arquitetura. Este número deve considerar o peso de cada cenário, conforme
estipulado no passo 1 descrito anteriormente; e
• Quantidade de mudanças: para cada arquitetura, estima-se a quantidade de mudanças
necessárias para que a mesma passe a oferecer suporte a todos os cenários indiretos. Esta
quantidade pode ser medida em termos de número de módulos/componentes modificados
ou, caso já existam mais detalhes sobre a arquitetura, até mesmo o número de classes
envolvidas nas mudanças.
De posse destes números, é possível determinar qual das alternativas oferece o melhor
suporte global para os requisitos. A alternativa que apresentar o melhor suporte aos cenários, e
menor quantidade de mudanças, será selecionada para seguir adiante. Uma vez selecionada a
arquitetura, retorna-se às atividades PD.2 e PD.3, buscando novas táticas/padrões arquiteturais
para implementar as mudanças sugeridas nesta avaliação. Este ciclo se repete até não serem
necessárias mais mudanças para atender aos cenários.
Após esta atividade, tem-se a arquitetura projetada e avaliada com base nas informações
disponíveis até o momento. No entanto, conforme já mencionado anteriormente, este é um
processo iterativo, e a arquitetura pode vir a sofrer alterações posteriormente. Na realidade, o
que acontece é uma iteração em duas vias: a arquitetura influencia a implementação das DSLs
e transformadores, que por sua vez podem influenciar a arquitetura, resultando em mudanças
que melhor acomodem a presença destes novos artefatos.
6.3 Considerações finais
Neste capítulo foi apresentada a fase de projeto de domínio, com atividades para promover
a reutilização através do MDD. As principais contribuições deste capítulo são as atividades para
definição das diretrizes e padrões arquiteturais específicos para o uso do MDD na reutilização de
software: variabilidade baseada em features, variabilidade baseada em DSLs e integração entre
subdomínios. Também apresenta uma atividade de avaliação arquitetural visando melhorar o
resultado do projeto antes da implementação ter iniciado.
O Quadro 10 resume as atividades do projeto de domínio.
O Quadro 11 descreve os produtos de trabalho da fase da projeto de domínio.
O produto do projeto de domínio é a definição da arquitetura e seus componentes. Nesta