Arquitetura_de_Software
262 pág.

Arquitetura_de_Software


DisciplinaAnálise de Sistemas II85 materiais1.123 seguidores
Pré-visualização50 páginas
do sistema
durante seu ciclo de vida.
Antes de entrarmos em detalhes sobre os diversos aspectos de
arquitetura de software, devemos entrar em consenso sobre o
termo \ufffdcomponente de software\ufffd. Em Engenharia de Software,
\ufffdcomponentes\ufffd têm vários signi\ufb01cados divergentes. Um signi\ufb01-
cado, de acordo com o Standard Computer Dictionary [1], é
que um componente é uma das partes que compõem o sistema.
Dessa maneira, \ufffdcomponente\ufffd pode ser substituído por \ufffdmó-
dulo\ufffd, \ufffdunidade\ufffd, ou mesmo \ufffdelemento\ufffd de software. É esse o
signi\ufb01cado de \ufffdcomponente\ufffd usado no padrão ISO/IEEE 1471-
2000 e que será usado ao longo deste livro.
Por outro lado, um componente também pode ter o signi\ufb01-
cado como o descrito por Kai Qian, em Component-Oriented
Programming [8]: \ufffdum pedaço de código autocontido e autoim-
plantável com uma funcionalidade bem de\ufb01nida e que pode ser
agregado com outros componentes através de sua interface.\ufffd
Esse outro signi\ufb01cado é estritamente ligado à Engenharia de
Software baseada em Componentes e não será usado a não ser
que sejamos explícitos sobre ele.
O padrão ISO/IEEE 1471-2000 também de\ufb01ne outros termos
fundamentais para o entendimento de arquitetura de software,
em especial visões (views). Esse termo será brevemente de-
scrito na Seção "Visões da Arquitetura" (Section 4.8: Visões
da Arquitetura) e então detalhado no Capítulo XX.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
70
CHAPTER 4. FUNDAMENTOS DE
ARQUITETURA DE SOFTWARE
4.7 Decompondo a de\ufb01nição de Ar-
quitetura de Software
A arquitetura de software é mais bem entendida através de
suas partes. Considerando as de\ufb01nições expostas acima, pode-
mos ressaltar seus dois principais aspectos, que serão os meios
para alcançar os atributos de qualidade: elementos e decisões
arquiteturais. Detalharemos cada aspecto a seguir.
4.7.1 Elementos arquiteturais
A arquitetura de um sistema deve de\ufb01nir os elementos que
formarão o software. Tais elementos de\ufb01nem como o software
é particionado em pedaços menores e, assim, de\ufb01nem como o
software é entendido. Elementos arquiteturais são divididos
em dois tipos: elementos estáticos e elementos dinâmicos.
Os elementos estáticos de um sistema de software de\ufb01nem as
partes do sistema e qual sua organização. Esse tipo de elemento
re\ufb02ete o sistema durante o design e é constituído de elemen-
tos de software (e.g., módulos, classes, pacotes, procedimentos,
ou ainda serviços autocontidos), elementos de dados (e.g., en-
tidades e tabelas de bancos de dados, arquivos de dados, ou
classes de dados), e elementos de hardware (e.g., computadores
em que o sistema vai executar, ou outros tipos de hardware que
o sistema usará: roteadores, cabos, ou impressoras).
Elementos estáticos não consistem apenas das partes estáti-
cas do sistema, mas também como eles se relacionam entre si.
Associações, composições, e outros tipos de relações entre ele-
mentos de software, de dados, e de hardware formam o aspecto
estático que compõe a arquitetura do sistema. O exemplo a
seguir ilustra elementos estáticos de um sistema de software.
Exemplo 4.6
Voltando ao SASF, observar sua arquitetura sob uma
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
71
ótica estática expõe seus elementos estáticos. Em
tempo de design, alguns elementos estáticos são cada
pacote, módulo ou conjunto de classes responsáveis por
cada função do sistema. Alguns desses elementos são
os responsáveis por: criação, edição, remoção e recu-
peração de usuários e \ufb01lmes, aluguel de \ufb01lmes, auten-
ticação e autorização dos usuários, entre outros.
Por outro lado, elementos dinâmicos de\ufb01nem o comportamento
do sistema. Esse tipo de elemento re\ufb02ete o sistema durante a
execução e nele estão incluídos processos, módulos, protocolos,
ou classes que realizam comportamento. Elementos dinâmicos
também descrevem como o sistema reage a estímulos internos
e externos, como mostrado no exemplo a seguir.
Exemplo 4.7
Ainda na arquitetura do SASF, podemos também ob-
servar o sistema sob uma ótica dinâmica. Essa exibe
seus elementos dinâmicos, a exemplo dos diversos pro-
cessos executando nas diversas máquinas que compõem
o sistema. Esses processos pertencem aos servidores de
aplicação, aos serviços de armazenamento, ou mesmo
aos navegadores dos usuários.
4.7.1.1 Elementos Arquiteturais e Atributos do Sis-
tema
Note que quando examinamos os elementos arquiteturais de
um sistema, tanto os estáticos quanto os dinâmicos, devemos
também prestar atenção nas relações que os ligam. Essas re-
lações são importantes, pois especi\ufb01cam a comunicação e o
controle da informação e do comportamento que formam o sis-
tema. Assim, as relações de\ufb01nem diversos aspectos do sistema,
por exemplo, quais dados do objeto da classe A são visíveis
pelos objetos da classe B; ou quantas leituras concorrentes são
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
72
CHAPTER 4. FUNDAMENTOS DE
ARQUITETURA DE SOFTWARE
feitas no elemento C; ou ainda como o elemento D é autorizado
a escrever dados no elemento E. Dessa maneira, essas relações
têm efeito sobre atributos de qualidade do sistema, sejam os
percebidos pelos usuários, ou os percebidos pelos desenvolve-
dores. Os exemplos seguintes mostram casos de como relações
entre elementos arquiteturais afetam atributos de qualidade.
Exemplo 4.8
Se dividirmos a arquitetura do SASF em três ca-
madas (apresentação, lógica de negócio, e persistência),
a camada de persistência pode ser um recurso com-
partilhado por diversas instâncias da lógica de negó-
cio. Se temos diversas instâncias da lógica de negócio,
mesmo que algumas saiam do ar, as restantes proverão
disponibilidade ao sistema, desde que a camada de per-
sistência (e.g., o banco de dados) não falhe. Além
disso, o compartilhamento do banco de dados pode sig-
ni\ufb01car também o acesso concorrente ao mesmo. Assim,
quando uma instância da lógica de negócio lhe faz uma
requisição, essa requisição lhe será respondida mesmo
que outras instâncias estejam fazendo o mesmo (ob-
viamente, isso só ocorre se alguma instância da lógica
de negócio não esteja realizando alguma requisição que
precise de acesso exclusivo aos dados).
Exemplo 4.9
A separação do sistema em três camadas ( Figura 4.4)
pode também facilitar a manutenção. Se, além de ado-
tar essa divisão, a camada de apresentação apenas se
comunicar com a lógica de negócio, mas não com a de
persistência, mudanças na camada de persistência afe-
tarão apenas a camada de negócio. Portanto, caso seja
necessário mudar o fornecedor da camada de persistên-
cia, a assinatura dos métodos disponíveis, ou mesmo o
protocolo de comunicação, apenas a lógica de negócio
será afetada por essas mudanças, uma vez que não ex-
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
73
iste acoplamento entre a apresentação e a persistência.
Figura 4.4: Ilustração da divisão de uma arquitetura
em três camadas.
4.7.2 Decisões arquiteturais
Uma arquitetura não deve ter suas estruturas de\ufb01nidas aleato-
riamente, uma vez que são elas que permitem o sucesso rel-
ativo aos objetivos do sistema. Dessa maneira, é trabalho do
arquiteto de\ufb01nir essas estruturas em meio às alternativas de de-
sign arquitetural existentes. O arquiteto deve decidir entre as
alternativas, particionando o sistema em elementos e relações
que possibilitarão o atendimento aos atributos de qualidade.
Essas decisões são chamadas decisões arquiteturais.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
74
CHAPTER 4. FUNDAMENTOS DE
ARQUITETURA DE SOFTWARE
De\ufb01nição 4.2: decisão arquitetural