Arquitetura_de_Software
262 pág.

Arquitetura_de_Software


DisciplinaAnálise de Sistemas II85 materiais1.124 seguidores
Pré-visualização50 páginas
Uma escolha entre as alternativas de design arquite-
tural. Essa escolha se propõe a alcançar um ou mais
atributos de qualidade do sistema, por meio da(s) es-
trutura(s) arquiteturais que ela envolve ou de\ufb01ne.
4.7.2.1 Características
As decisões arquiteturais têm, basicamente, três características
que devem ser consideradas: descrição, objetivos e fundamen-
tação.
A primeira característica é bem clara. É simplesmente a de-
scrição do que foi decidido para o sistema, seja a descrição
um elemento, módulo, classe, ou serviço que existirá da ar-
quitetura, a descrição da comunicação de um elemento da ar-
quitetura com outro, a descrição da agregação de diversos ele-
mentos diferentes da arquitetura para formar um serviço, ou a
descrição de um princípio ou mais princípios que conduzirão a
evolução do sistema.
Exemplo 4.10
[Decisão Arquitetural 001] A arquitetura do SASF é
dividida em três camadas lógicas: apresentação, lógica
de negócio e persistência de dados. A camada de apre-
sentação se comunica apenas com a lógica de negócio e
apenas a lógica de negócio de comunica com a camada
de persistência de dados.
Toda decisão é feita com um ou vários objetivos. Assim, a se-
gunda característica trata de explicitar qual o objetivo de dada
decisão, normalmente, permitindo ou restringido um conjunto
de atributos de qualidade do sistema. Vale notar que, para
atender aos atributos de qualidade do sistema (que podem ser
muitos), uma arquitetura poderá possuir dezenas ou mesmo
centenas de decisões arquiteturais.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
75
Exemplo 4.11
(continuação da [Decisão Arquitetural 001]) Objetivo:
Essa divisão diminui o acoplamento entre os elementos
internos da arquitetura, facilitando o desenvolvimento
e a manutenção.
5
Por \ufb01m, uma decisão arquitetural só pode ter sido alcançada
em meio a alternativas com algum embasamento ou fundamen-
tação. Então, cabe ao arquiteto explicitar por que tal decisão
foi tomada, seja por ser um padrão conhecido na indústria,
seja por conhecimento prévio de como satisfazer os objetivos
em questão, ou pela atual decisão ter mostrado os melhores
resultados em meio a uma avaliação prévia das alternativas.
Exemplo 4.12
(continuação da [Decisão Arquitetural 001]) Moti-
vação: Projetar os elementos internos do sistema de
modo que cada um pertença a apenas uma camada
lógica ajuda a aumentar a coesão e diminuir o acopla-
mento. A coesão aumenta, 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
5
TODO: Adicionar os drivers dessa decisão: o Requisito(s) Não-
Funcional(is) XX presente(s) no Apêndice. Exemplo de requisito: [RNF
01] Ter mais de uma interface grá\ufb01ca.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
76
CHAPTER 4. FUNDAMENTOS DE
ARQUITETURA DE SOFTWARE
menor impacto nos outros.
4.7.2.2 Rastreabilidade
Vale notar que decisões de\ufb01nem que elementos comporão o sis-
tema. No exemplo anterior, podemos observar que a decisão
de\ufb01ne elementos como plug-ins, pontos de extensão, etc. As-
sim, por relacionarem atributos de qualidade (ou requisitos) a
elementos arquiteturais, as decisões contidas numa arquitetura
facilitam o chamado rastreamento de requisitos.
De\ufb01nição 4.3: rastreamento de requisitos
É o processo/capacidade de ligar requisitos do sistema
a estruturas arquiteturais.
A possibilidade de se rastrear requisitos na arquitetura é uma
característica importante porque facilita o entendimento e a
manutenção do sistema representado pela arquitetura. O en-
tendimento do sistema é facilitado porque uma arquitetura per-
mite que um interessado qualquer navegue pelos elementos que
compõem o sistema em dois sentidos: tanto do nível mais ab-
strato do sistema para seus níveis mais concretos, ou seja, dos
requisitos para os elementos arquiteturais, como módulos, bib-
liotecas, serviços, ou classes; quanto dos níveis concretos da
arquitetura para os níveis mais abstratos, ou seja, dos elemen-
tos arquiteturais para os requisitos do sistema.
O entendimento do sistema é facilitado porque uma arquitetura
permite que um interessado qualquer navegue pelos elementos
que compõem o sistema em dois sentidos: tanto do nível mais
abstrato do sistema para seus elementos mais concretos, ou
seja, dos requisitos para as estruturas arquiteturais, como mó-
dulos, bibliotecas, serviços, ou classes, quanto dos elementos
concretos da arquitetura para os níveis mais abstratos, ou seja,
das estruturas arquiteturais para os requisitos do sistema.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
77
Exemplo 4.13
Se observarmos a arquitetura do SASF e procurarmos
pelas decisões responsáveis por facilitar a manutenção
do sistema, encontraremos entre elas a decisão do Ex-
emplo 4.12. Essa decisão sugere uma divisão do sis-
tema em camadas lógicas, mas também in\ufb02uencia na
divisão em pacotes, serviços ou mesmo processos. As-
sim, a satisfação do requisito de manutenibilidade está
diretamente ligada à correta divisão das partes do sis-
tema em apresentação, lógica de negócio e persistência.
Da mesma maneira, se partirmos das partes que for-
mam as camadas de apresentação, lógica de negócio
e persistência, observaremos que elas estão ligadas à
divisão do sistema (e à decisão arquitetural) que se
propõe a atender a requisitos de manutenibilidade.
Além de permitir a navegação, um aspecto que merece ser
ressaltado é que se os requisitos do sistema forem eventual-
mente ordenados por importância para o sucesso do sistema,
os elementos arquiteturais também possuirão diferentes níveis
de importância. Essa ordenação, então, signi\ufb01cará diferentes
níveis de investimento, seja em tempo ou dinheiro, na con-
strução dos elementos arquiteturais para o sucesso do sistema.
Adicionalmente, a manutenção do sistema é facilitada de uma
forma análoga ao seu entendimento. Se algum requisito é aten-
dido insatisfatoriamente, por meio da arquitetura é possível
descobrir quais elementos do sistema estão envolvidos na in-
satisfação desses requisitos. Da mesma maneira, a arquite-
tura possibilita descobrir quais requisitos serão afetados por
um dado elemento arquitetural caso esse sofra uma mudança
ou manutenção.
Exemplo 4.14
Se uma modi\ufb01cação na camada de apresentação só
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
78
CHAPTER 4. FUNDAMENTOS DE
ARQUITETURA DE SOFTWARE
pode ser feita se a camada de persistência também for
modi\ufb01cada, isso pode signi\ufb01car que a decisão arquite-
tural do Exemplo 4.12 não está sendo seguida corre-
tamente. Portanto, o requisito de manutenibilidade
também não está sendo atendido corretamente e essa
divergência da arquitetura deve ser corrigida o quanto
antes.
4.7.2.3 Evolução
Devido às suas características, se torna fácil perceber que o
registro das decisões arquiteturais na forma de um documento
\ufffd o documento arquitetural \ufffd agrega valor ao ciclo de vida do
software, uma vez que facilita o processo