Arquitetura_de_Software
262 pág.

Arquitetura_de_Software


DisciplinaAnálise de Sistemas II85 materiais1.124 seguidores
Pré-visualização50 páginas
aplicação na indústria, mas
que proporciona resultados mais precisos em relação às qual-
idades estruturais, comportamentais e de interação entre as
partes do software, como por exemplo qualidades de desem-
penho e con\ufb01abilidade.
Como exemplos de análises baseadas em simulações, podemos
citar o uso de simulação de eventos discretos para análise de de-
sempenho ou o uso da ferramenta XTEAM
7
, que utiliza ADLs
e processos de estado \ufb01nito para diferentes tipos de análises
arquiteturais.
5
Técnica apresentada por Allen e Garlan no artigo A Formal Basis for
Architectural Connection [7]
6
Mais informações sobre a linguagem MetaH podem ser en-
contradas no site: http://www.htc.honeywell.com/metah/index.html
(<http://www.htc.honeywell.com/metah/index.html>)
7
A ferramenta eXtensible Tool-chain for Evaluation of Architectural
Models (XTEAM) é descrita por Edwards et al no artigo Scenario-Driven
Dynamic Analysis of Distributed Architectures [39].
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
205
8.1.5 Ferramenta de Rastreabilidade
Por \ufb01m, a documentação permite rastreabilidade entre os req-
uisitos e os elementos da arquitetura e implementação que sat-
isfazem esses requisitos. Ao documentar as decisões arquite-
turais, registramos (1) seus objetivos, que normalmente são
qualidades a serem alcançadas pelo software, e (2) como esses
objetivos são alcançados, por meio da descrição dos elementos
que compõem o sistema e suas relações e regras de design que
devem ser respeitadas durante a implementação. Este registro
serve de ponte entre dois extremos do processo de desenvolvi-
mento: os requisitos e a implementação, e assim permite a
navegação entre pontos relacionados, sejam eles requisitos, de-
cisões de design ou partes da implementação.
A rastreabilidade nos permite analisar qual o impacto de uma
decisão de design, tanto em termos de quais requisitos ela afeta,
quanto quais elementos de software ela dita a existência ou, em
caso de manutenção, quais elementos são ou devem ser afetados
por mudanças nos requisitos ou nas decisões. O exemplo a
seguir mostra aspectos de rastreabilidade na documentação da
arquitetura do SASF.
Exemplo 8.7
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 de
divisão do sistema em camadas. Essa decisão sug-
ere uma divisão do sistema em camadas lógicas, mas
também in\ufb02uencia na divisão em pacotes, serviços ou
mesmo processos. Assim, a satisfação do requisito de
manutenibilidade está diretamente ligada à correta di-
visão das partes do sistema em apresentação, lógica de
negócio e persistência.
Da mesma maneira, se partirmos das partes que for-
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
206
CHAPTER 8. DOCUMENTAÇÃO DA
ARQUITETURA
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.
8.2 Decisões Arquiteturais
Em capítulos anteriores, de\ufb01nimos arquitetura de software us-
ando o padrão ISO/IEEE 1471-2000, que diz que ela é a organi-
zação fundamental de um sistema, representada por seus com-
ponentes, seus relacionamentos com o ambiente, e pelos princí-
pios que conduzem seu design e evolução. Após a de\ufb01nição,
mencionamos também que a arquitetura é composta de diver-
sas decisões de design (no caso, design de alto-nível ou arquite-
tural) e que cada decisão contém, ao menos em nível conceitual,
uma descrição, objetivos e algum argumento ou motivação.
Como a arquitetura é formada por decisões arquiteturais, de-
vemos conhecer os tipos de decisões arquiteturais para então
sermos capazes de documentar a arquitetura.
Uma decisão arquitetural, como também já de\ufb01nido anterior-
mente, é uma escolha entre as alternativas de design arquitetu-
ral, que se propõe a alcançar um ou mais atributos de qualidade
do sistema, por meio de estruturas ou regras que ela envolve ou
de\ufb01ne. Em outras palavras, podemos dizer que uma decisão ar-
quitetural descreve parte do design, onde essa descrição pode:
(1) ditar a existência ou inexistência de partes do sistema, (2)
especi\ufb01car propriedades que, durante a construção, partes do
sistema devem satisfazer, ou (3) citar técnicas que devem ser
seguidas durante a construção de partes do sistema. Podemos
então dividir as decisões arquiteturais em:
\u2022 Decisões arquiteturais existenciais (e não-existenciais);
\u2022 Decisões arquiteturais de propriedades; e
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
207
\u2022 Decisões arquiteturais executivas.
8.2.1 Decisões existenciais
Uma decisão existencial é aquela que indica a presença de um
ou vários elementos arquiteturais no design e na implemen-
tação.
Os elementos arquiteturais já foram apresentados anterior-
mente, mas vamos relembrá-los aqui. Estes elementos são as
partes em que o software é dividido e podem ser classi\ufb01cados
em dois tipos: elementos arquiteturais estáticos e elementos
arquiteturais dinâmicos. Os elementos estáticos descrevem a
estrutura do sistema em tempo de design e são constituídos de
elementos de software (por exemplo, classes, pacotes, proced-
imentos, serviços remotos), elementos de dados (por exemplo,
entidades e tabelas de bancos de dados, arquivos ou classes de
dados), e elementos de hardware (por exemplo, servidores em
que o sistema vai executar ou armazenar dados). Por sua vez,
os elementos dinâmicos descrevem o comportamento do sis-
tema em tempo de execução e entre eles podemos incluir pro-
cessos, módulos, protocolos, ou classes que realizam comporta-
mento. Note que as relações entre os elementos arquiteturais,
tanto estáticos quanto dinâmicos, são representadas também
como elementos arquiteturais. Estes elementos são chamados
de conectores e podem ser associações, composições, general-
izações, entre outros.
No Exemplo 8.1, observamos uma decisão arquitetural que di-
vide o SASF em diversos módulos menores, constituindo assim
uma decisão existencial que de\ufb01ne diversos elementos e as re-
lações entre si.
Já no Exemplo 8.8, observamos uma decisão arquitetural que
também dita a presença de elementos na arquitetura do SASF.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
208
CHAPTER 8. DOCUMENTAÇÃO DA
ARQUITETURA
No entanto, ao contrário do exemplo citado anteriormente que
dita elementos estruturais do software, o Exemplo 8.8 dita ele-
mentos comportamentais esperados nele. Assim, podemos en-
contrar decisões existenciais que sejam decisões estruturais ou
comportamentais. As decisões comportamentais são mais rela-
cionadas à implementação dos requisitos de qualidade.
Exemplo 8.8
[Decisão Arquitetural 005] Os dados do Cadastro de
Usuários e do Cadastro de Filmes devem ser parti-
cionados horizontalmente.
Objetivo: Distribuir carga, melhorar o desempenho e
aumentar o número de pontos de falhas.
Motivação: Ao particionar horizontalmente os dados,
permite-se a distribuição da carga de requisições en-
tre vários servidores de armazenamento, que estarão
executando instâncias do SGBDR. Com menor carga,
o desempenho pode ser melhorado. Além disso, caso
uma partição \ufb01que inacessível (por falha, por exemplo),
parte dos dados ainda estarão acessíveis, não inviabi-
lizando o sistema por completo.
Na prática, é importante observarmos que a divisão entre de-
cisões estruturais e comportamentais não é absoluta. Podemos
encontrar decisões que, para descrever um comportamento, ne-
cessitem de novas