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.
124<br />
Saídas: PT.8. Táticas e padrões arquiteturais<br />
Descrição: o objetivo desta atividade é selecionar ou def<strong>in</strong>ir táticas e padrões para satisfazer<br />
às diretrizes arquiteturais. O uso de padrões é considerado uma das mais técnicas mais<br />
úteis durante a fase de projeto de software. Através desta técnica, pode-se reaproveitar<br />
soluções recorrentes e já comprovadamente bem sucedidas, poupando-se esforço e riscos<br />
nesta atividade. Em termos de projeto arquitetural, são conhecidos como padrões, estilos<br />
(BASS; CLEMENTS; KAZMAN, 2003) ou abordagens (CLEMENTS; KAZMAN; KLEIN, 2004)<br />
arquiteturais. A diferença entre um padrão arquitetural e um padrão de projeto está na<br />
abrangência e impacto da solução. Enquanto padrões de projeto normalmente são utilizados<br />
para resolver problemas mais detalhados, padrões arquiteturais descrevem soluções mais<br />
abrangentes que envolvem todo o escopo de um domínio ou sistema. Além disso, padrões<br />
arquiteturais normalmente são escolhidos e utilizados conforme requisitos não-funcionais,<br />
como desempenho ou confiabilidade. Normalmente, <strong>in</strong>icia-se com padrões arquiteturais que<br />
def<strong>in</strong>em a macro-estrutura do domínio, até chegar em padrões menores que resolvem problemas<br />
mais específicos de partes do domínio.<br />
Além disso, um padrão arquitetural implementa uma ou mais táticas, que por sua vez tem<br />
o objetivo de alcançar um ou mais atributos de qualidade (BASS; CLEMENTS; KAZMAN, 2003).<br />
Uma tática descreve uma estratégia a ser utilizada para se alcançar um determ<strong>in</strong>ado atributo de<br />
qualidade. Assim, para cada diretriz arquitetural, seleciona-se uma ou mais táticas, e em seguida<br />
são selecionados os padrões para implementar estas táticas. Uma lista de táticas é apresentada<br />
por Bass, Clements e Kazman (2003), porém esta não <strong>in</strong>clui táticas para lidar com variabilidade<br />
em um domínio, nem com a <strong>in</strong>tegração entre subdomínios automatizados, como é o caso desta<br />
abordagem (Sub-atividade PD3.3).<br />
Para implementar as táticas, existe uma grande quantidade de fontes de padrões e estilos<br />
arquiteturais. Vale destacar a série de c<strong>in</strong>co volumes conhecida como POSA (Pattern-Oriented<br />
<strong>Software</strong> Architecture) (BUSCHMANN et al., 1996; SCHMIDT et al., 2000; KIRCHER; JAIN, 2003;<br />
BUSCHMANN; HENNEY; SCHMIDT, 2007a, 2007b), que apresenta diversos padrões voltados para<br />
diferentes tipos de problemas arquiteturais. O catálogo clássico de padrões de projeto (GAMMA<br />
et al., 1995) também pode ser útil nesta atividade, além de outras fontes citadas por Bass,<br />
Clements e Kazman (2003).<br />
Com relação ao problema da variabilidade, existem alguns trabalhos que propõem o uso<br />
de alguns padrões de projeto com este objetivo (ALMEIDA et al., 2007b; KEEPENCE; MANNION,<br />
1999; LEE; KANG, 2004). Existem também diversos trabalhos que apresentam formas de se<br />
implementar variabilidade em uma l<strong>in</strong>ha de produtos, que podem ser adaptadas para o nível