Arquitetura_de_Software
262 pág.

Arquitetura_de_Software


DisciplinaAnálise de Sistemas II85 materiais1.124 seguidores
Pré-visualização50 páginas
de
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
200
CHAPTER 8. DOCUMENTAÇÃO DA
ARQUITETURA
armazenamento do SASF e, por \ufb01m, (3) que tipo de hardware
será necessário para executar a solução de armazenamento.
Exemplo 8.6
Na [Decisão Arquitetural 001], descrita no Exem-
plo 8.1, apresentamos três módulos que devem lidar di-
retamente com armazenamento: Cadastro de Usuários,
Cadastro de Filmes e Transmissor de Filmes. No en-
tanto, apenas as funções que eles devem implementar
foram descritas, não como devem implementar. As de-
cisões a seguir mostram alguns aspectos de como essas
funções devem ser implementadas.
(Decisão Arquitetural 002). O armazenamento das in-
formações dos módulos Cadastro de Usuários e Cadas-
tro de Filmes será realizado usando um Sistema Geren-
ciador de Banco de Dados Relacional (SGBDR) de
modo a permitir criação, edição, obtenção e remoção
das entradas.
As informações guardadas no SGBDR são os atributos
dos Usuários e Filmes e são essencialmente textuais ou
metainformações para localização de arquivos de mí-
dia (fotos ou vídeos). O armazenamento de arquivos
de mídia é tratado na [Decisão Arquitetural 003]. Já o
armazenamento de arquivos textuais que não são atrib-
utos dos Usuários ou Filmes, por exemplo, mensagens
para usuários ou comentários sobre \ufb01lmes é tratado em
outra decisão arquitetural que não é descrita aqui.
Objetivo: Permitir a persistência dos atributos dos
Usuários e Filmes, facilitando o desenvolvimento.
Motivação: Os atributos de Usuários e Filmes são
essencialmente relacionais, se encaixando perfeita-
mente ao paradigma usado para armazenamento. Além
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
201
de ser um paradigma bem conhecido pelo time de de-
senvolvimento.
(Decisão Arquitetural 003). O armazenamento de ar-
quivos de mídia (fotos de Usuários, fotos de Filmes
e arquivos de vídeo) serão armazenados usando uma
Rede de Fornecimento de Conteúdo ( Content Deliv-
ery Network ou CDN).
Objetivo: Permitir a persistência de arquivos de mídia,
facilitando a implementação e permitindo desempenho
e controle de carga.
Motivação: Os arquivos de mídia presentes no SASF
são conteúdo estático, que pode ser distribuído por
uma CDN e, assim, tirar proveito de replicação, dis-
tribuição geográ\ufb01ca e caching, sem ter que implemen-
tar estas técnicas.
Já as decisões da visão de implantação, devem de-
screver os servidores que executaram os SGBDR e o
serviço que se comunica com a CDN para o envio de
arquivos.
8.1.4 Modelo para Análise
A arquitetura é um modelo do sistema, uma vez que descreve
suas características. Ao documentar a arquitetura, obtemos
um modelo manipulável do sistema que tem utilidade não só ao
arquiteto, mas também a outros stakeholders. Com o modelo
manipulável, é possível avaliar as decisões arquiteturais reg-
istradas e validá-las em relação aos requisitos que o software
deve satisfazer. Além disso, o documento pode ainda servir de
ferramenta que permita a veri\ufb01cação de se implementação está
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
202
CHAPTER 8. DOCUMENTAÇÃO DA
ARQUITETURA
de acordo com o design, podendo prevenir eventuais deslizes
arquiteturais.
Podemos citar três categorias
3
de validação da arquitetura em
relação aos requisitos: análise baseada em inspeções, análise
baseada em modelos e análise baseada em simulações. No en-
tanto, a possibilidade de aplicação de uma técnica de uma dada
categoria de validação está diretamente ligada à representação
usada no documento de arquitetura.
8.1.4.1 Análise baseada em inspeções
Análises baseadas em inspeções são conduzidas por bancas de
revisão compostas por vários stakeholders. Entre os stakehold-
ers, podemos encontrar, além do arquiteto e dos desenvolve-
dores, interessados menos técnicos, como o gerente de projeto
e, em alguns casos, o cliente. Durante o processo de inspeção,
os stakeholders de\ufb01nem os objetivos da análise e estudam as
representações da arquitetura de forma a avaliá-la de acordo
com seus objetivos.
Esta categoria de inspeção serve para veri\ufb01car um conjunto
amplo de propriedades da arquitetura e faz uso de múltiplas
representações do design, tanto em linguagens formais, quanto
informais. Por ser um processo essencialmente manual, é um
tipo de análise mais caro do que os de outros, mas que possi-
bilita também a inspeção em busca de qualidades menos for-
mais do software, a exemplo de escalabilidade, manutenibili-
dade ou operabilidade. Outra vantagem deste tipo de análise
é a de permitir o uso de representações informais ou parciais
do design da arquitetura, além de possibilitar a análise con-
siderando múltiplos objetivos de múltiplos stakeholders.
3
Esta divisão foi feita originalmente por Taylor et al em Software Ar-
chitecture: Foundations, Theory, and Practice [104].
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
203
Como exemplos de análises baseadas em inspeções, podemos
citar alguns métodos de avaliação de arquitetura criados pelo
Software Engineering Institute, da Carnegie Melon University :
o Software Architecture Analysis Method (SAAM), o Architec-
tural Trade-O\ufb00 Analysis Method (ATAM) e o método Active
Reviews for Intermediate Designs (ARID).
4
8.1.4.2 Análise baseada em modelos
Análises baseadas em modelos são menos custosas do que as
baseadas em inspeções, uma vez que demonstram maior nível
de automação. Este tipo de análise utiliza ferramentas que ma-
nipulam representações da arquitetura com o objetivo de en-
contrar algumas de suas propriedades. Para possibilitar a ma-
nipulação, as representações devem ser escritas em linguagens
formais ou semiformais como ADLs ( architecture description
languages ou linguagens de descrição de arquitetura), como por
exemplo, ACME, SADL e Rapide, máquinas de estado \ufb01nito
ou UML.
Esta categoria de inspeção é utilizada na busca de propriedades
formais da arquitetura, como corretude sintática ou ausência
de deadlocks e, apesar de seu alto grau de automação, pode
necessitar que o arquiteto guie a ferramenta de inspeção uti-
lizada considerando os resultados parciais. Uma desvantagem
desta categoria é seu desempenho na análise de grandes sis-
temas. Uma vez que as representações da arquitetura podem
levar à explosão de estados, a análise de todo o espaço de es-
tados do sistema pode ser inviável. Portanto, é comum que
apenas partes da arquitetura sejam analisadas \ufffd de preferência
partes mais críticas.
Como exemplos de análises baseadas em modelos, podemos
4
Podemos encontrar a descrição desses métodos no livro Evaluating
Software Architectures, de Paul Clements et al [33].
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
204
CHAPTER 8. DOCUMENTAÇÃO DA
ARQUITETURA
citar o uso da linguagem Wright para a veri\ufb01cação de ausência
de deadlocks
5
e o uso da linguagem de modelagemMetaH para
análise de propriedades con\ufb01abilidade e segurança ( safety)
6
.
8.1.4.3 Análise baseada em simulações
Análises baseadas em simulações se utilizam de modelos exe-
cutáveis da arquitetura para extrair características do software
ou de partes dele. Assim como a análise baseada em modelos,
esse tipo de análise também se utiliza de ferramentas que au-
tomatizam o processo, deixando-o mais barato. No entanto,
este tipo de análise produz resultados restritos às propriedades
dinâmicas do software e estão sujeitas às imprecisões dos mod-
elos de execução.
Para possibilitar a execução, as representações utilizadas de-
vem ser formais, o que diminui sua