Arquitetura_de_Software
262 pág.

Arquitetura_de_Software


DisciplinaAnálise de Sistemas II85 materiais1.124 seguidores
Pré-visualização50 páginas
pois cada elemento será
desenvolvido com o objetivo de ser parte da apresen-
tação, da lógica ou da persistência do sistema. Dessa
maneira, cada elemento terá sua responsabilidade bem
de\ufb01nida, mesmo que em alto nível. Como a comuni-
cação entre as camadas é pré-de\ufb01nida, a de seus ele-
mentos também é: elementos da camada de apresen-
tação não se comunicarão com elementos da camada
de persistência, por exemplo. Assim, o acoplamento
entre elementos internos será análogo ao acoplamento
entre camadas. Com o baixo acoplamento, o desen-
volvimento e a manutenção dos elementos também é
facilitado, seja por possibilitar o desenvolvimento in-
dependente, seja por mudanças em um elemento terem
menor impacto nos outros.
É importante observar que uma decisão arquitetural pode es-
tar relacionada a mais de um atributo de qualidade e, como
veremos a seguir, a mais de uma categoria. Isso ocorre porque
decisões arquiteturais se interrelacionam da mesma forma que
os atributos de qualidade e os requisitos impostos pelos stake-
holders. Portanto, é na fundamentação que devemos também
descrever as relações entre as decisões arquiteturais, ou seja,
se uma decisão restringe, proíbe, possibilita, con\ufb02ita, sobrepõe,
compõe ou é composta de, depende de, ou é uma alternativa a
outras decisões.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
219
8.2.4.4 Escopo
Nem todas as decisões arquiteturais são válidas durante todo o
ciclo de vida do software ou válidas em todos os módulos que o
compõem. Por isso, surge a necessidade de registrar o escopo
da decisão. Este registro tipo de registro se torna importante
em decisões de propriedades, uma vez que normalmente tratam
de preocupações transversais e abrangem grandes partes do
sistema, e em decisões executivas, que devem, por exemplo,
especi\ufb01car quais etapas do processo de desenvolvimento devem
usar tais metodologias.
O Exemplo 8.17, a seguir, descreve o escopo da Decisão Ar-
quitetural 001, que é bem abrangente. Já no Exemplo 8.18,
podemos observar que o escopo da decisão de usar JMX
10
como
tecnologia de monitoração é mais limitado.
Exemplo 8.17
(continuação da [Decisão Arquitetural 001])
Escopo: Esta decisão é válida para todos os serviços
que implementam lógica e que têm interface com o
usuário.
Exemplo 8.18
Escopo: A decisão de usar JMX para exposição das
métricas de desempenho só é válida para os casos
de\ufb01nidos na [Decisão Arquitetural 008].
8.2.4.5 Histórico
A documentação da arquitetura, assim como o que ela repre-
senta, evolui ao longo do tempo. Decisões são tomadas, avali-
10
Java Management Extensions (JMX):
http://java.sun.com/products/JavaManagement/
(<http://java.sun.com/products/JavaManagement/>)
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
220
CHAPTER 8. DOCUMENTAÇÃO DA
ARQUITETURA
adas, modi\ufb01cadas ou mesmo contestadas ao longo do ciclo de
vida da arquitetura. Portanto, é de se esperar que exista um
registro histórico da evolução de cada decisão arquitetural. Por
isso consideramos o atributo histórico.
O atributo histórico deve conter, para cada modi\ufb01cação da
decisão, uma marca de tempo, o autor da modi\ufb01cação e um
resumo da modi\ufb01cação. Se o documento estiver armazenado
em um wiki ou outra forma eletrônica, o histórico pode conter
links para as versões anteriores da decisão.
O Exemplo 8.19 ilustra o registro histórico da Decisão Arquite-
tural 001.
Exemplo 8.19
(continuação da [Decisão Arquitetural 001])
Histórico: sugerida (G. Germoglio, 2009/07/15);
revisada, \ufffdEscopo modi\ufb01cado.\ufffd (G. Germoglio,
2009/07/17); aprovada (J. Sauvé, 2009/07/18).
8.2.4.6 Estado Atual
O atributo estado atual de uma decisão serve para permitir
mais uma dimensão de organização das decisões. Da mesma
forma que as decisões evoluem ao longo do tempo, elas po-
dem ter diversos estados que merecem ser registrados. Como
o conjunto de estados que podem ser atribuídos a uma decisão
arquitetural depende do processo de desenvolvimento adotado,
citamos apenas alguns estados mais comuns:
\u2022 Sugerida: decisão que ainda não foi avaliada;
\u2022 Revisada: decisão sugerida e revisada pelo arquiteto ou
time arquitetural;
\u2022 Aprovada: decisão sugerida, revisada e aprovada;
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
221
\u2022 Rejeitada: decisão sugerida, revisada e rejeitada. Ela
deve se manter na documentação para referências fu-
turas.
8.2.4.7 Categoria
Assim como o estado atual, o atributo categoria serve para
possibilitar a organização das decisões arquiteturais em grupos
relacionados. Normalmente, esse atributo é composto por uma
lista de palavras-chave associadas às decisões.
Esse atributo permite, por exemplo, que os stakeholders sele-
cionem decisões relacionadas a um atributo de qualidade es-
pecí\ufb01co. Portanto, se um membro do grupo de garantia de
qualidade do software ( Software Quality Assurance ou SQA)
precisa das decisões arquiteturais necessárias para realizar uma
análise de desempenho do projeto do software, ele deve procu-
rar pelas decisões da categoria \ufffddesempenho\ufffd.
8.3 Visões arquiteturais
Como consequência da existência dos diversos interessados na
arquitetura e que esses interessados têm diferentes preocu-
pações e diferentes níveis de conhecimento, as decisões arquite-
turais não são documentadas da mesma maneira para interes-
sados diferentes. Para resolver este problema, fazemos uso do
conceito de múltiplas visões arquiteturais.
Visões arquiteturais são representações do sistema ou de parte
dele da perspectiva de um conjunto de interesses relacionados.
A visões arquiteturais proporcionam vantagens tanto para o
processo de design, quanto para a documentação da arquite-
tura.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
222
CHAPTER 8. DOCUMENTAÇÃO DA
ARQUITETURA
Durante o design, o arquiteto pode se focar em diferentes visões
separadamente, podendo abstrair os detalhes desnecessários e
só se ater às preocupações da visão corrente. Por exemplo, ini-
cialmente, o arquiteto se pode utilizar de uma visão funcional
para projetar os serviços primitivos do sistema que constituirão
serviços mais complexos e que, por sua vez, servirão de base
para as funcionalidades expostas aos usuários. Em seguida, o
arquiteto pode se utilizar de uma visão de concorrência para
projetar como as funções serão executadas ao longo do tempo:
de forma sequencial ou em paralelo, de forma síncrona ou as-
síncrona. E, por \ufb01m, focando-se numa visão informacional, ele
pode de\ufb01nir como os dados estão organizados.
Por outro lado, durante o processo de documentação, o ar-
quiteto pode documentar as visões com diferentes níveis de de-
talhes e utilizar diferentes linguagens, uma vez que diferentes
visões interessam a diferentes stakeholders.
As visões são concretizações do que chamamos pontos de vista
arquiteturais
11
. Um ponto de vista arquitetural é a especi\ufb01-
cação dos elementos conceituais que devem ser usados para se
construir uma visão. Um ponto de vista apresenta também
qual o seu propósito e quem são os stakeholders interessados
nas visões criadas a partir dele. Em outras palavras, um ponto
de vista arquitetural é de\ufb01nido como:
De\ufb01nição 8.1: ponto de vista arquitetural
É um arcabouço conceitual que de\ufb01ne elementos,
conexões e técnicas que compõem uma visão arquitetu-
ral, além especi\ufb01car seu propósito de acordo com seus
interessados.
Para documentarmos a arquitetura, devemos de\ufb01nir um con-
junto pontos de vista que servirão de base para as visões da
11
Viewpoints, de acordo com o padrão ISO/IEEE 1471-2000, ou view-
types (tipos de visão),