Arquitetura_de_Software
262 pág.

Arquitetura_de_Software


DisciplinaAnálise de Sistemas II85 materiais1.123 seguidores
Pré-visualização50 páginas
de acordo com Clements et al em Documenting
Software Architectures: Views and Beyond.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
223
arquitetura e que estarão presentes no documento. Cada visão
terá uma ou mais decisões arquiteturais, que serão descritas a
partir dos elementos, conexões e técnicas de\ufb01nidos pelo ponto
de vista a que pertence.
Como já existem diversos conjuntos de pontos de vista prontos
para uso na literatura, não há motivo para criarmos o nosso
próprio conjunto. Portanto, a seguir, apresentamos alguns con-
juntos os quais achamos essencial o conhecimento. São eles:
\u2022 4+1 de Kruchten;
\u2022 Pontos de vista de Rozanski e Woods.
\u2022 Pontos de vista do Software Engineering Institute;
8.3.1 4+1 de Kruchten
O conjunto de pontos de vista 4+1 de Kruchten foi descrito ini-
cialmente no artigo The 4+1 View Model of Architecture [62]
e é um dos primeiros a serem descritos na literatura. Inicial-
mente, os pontos de vista são chamados pelo autor de visões.
No entanto, se analisarmos a de\ufb01nição e o uso das visões empre-
gados pelo autor, percebemos ela são compatíveis com nossas
de\ufb01nições e usos dos pontos de vista.
O conjunto é composto por quatro pontos de vista, sendo cada
um especializado em um aspecto da arquitetura, e um ponto
de vista redundante, que contém cenários de uso. Os pontos de
vista mais relevantes desse conjunto são: Lógico, de Processos,
de Desenvolvimento e Físico. Como o conjunto de Rozanski
e Woods é uma evolução do 4+1, ao descrevê-lo na seção a
seguir, apresentaremos melhor os pontos de vista de Kruchten.
8.3.2 Viewpoints de Rozanski e Woods
Outro conjunto importante de pontos de vista é o descrito
por Rozanski e Woods no livro Software Systems Architecture:
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
224
CHAPTER 8. DOCUMENTAÇÃO DA
ARQUITETURA
Working With Stakeholders Using Viewpoints and Perspec-
tives [92]. Ele é uma evolução do conjunto 4+1, pois adiciona
dois novos pontos de vista ao conjunto de Kruchten, e provê
mais informações que ajudam no design do que na documen-
tação.
Os pontos de vista presentes neste conjunto são:
\u2022 Funcional: representa o aspecto funcional do software de-
scrito. Visões derivadas deste ponto de vista contêm de-
cisões sobre as funções presentes no software e os módu-
los e submódulos que implementam essas funções. Este
ponto de vista é especializado em mostrar a estrutura es-
tática do software, mostrando suas partes, suas relações e
suas interfaces. Seu equivalente no conjunto de Kruchten
é o ponto de vista Lógico.
\u2022 de Concorrência: representa os aspectos dinâmicos e
comportamentais do software. Visões derivadas deste
ponto de vista contêm decisões sobre concorrência, sin-
cronia ou assincronia de chamadas e aspectos temporais
em geral do software e de suas funções. Seu equivalente
no conjunto de Kruchten é o ponto de vista de Processo.
\u2022 de Desenvolvimento: representa os aspectos e relações
entre os stakeholders e o processo de desenvolvimento do
software. Visões derivadas deste ponto de vista contêm
decisões de divisões de módulos, subsistemas, pacotes e
classes e decisões sobre a atribuição de tarefas de con-
strução, teste e reuso de partes do sistema aos partici-
pantes da equipe de desenvolvimento. Seu equivalente
no conjunto de Kruchten é homônimo.
\u2022 de Implantação: representa os aspectos de implantação
do software e suas relações com o ambiente físico. Visões
derivadas deste ponto de vista contêm decisões de quan-
tos servidores serão necessários para execução de um
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
225
serviço ou como os diferentes serviços são implantados
ou atualizados durante o ciclo de vida do software. Seu
equivalente no conjunto 4+1 é o ponto de vista Físico.
\u2022 Informacional: representa os aspectos relacionados aos
dados presentes no software. Visões derivadas deste
ponto de vista contêm decisões sobre o modelo de dados
e sobre o armazenamento, manipulação, gerenciamento e
distribuição das informações ao longo da vida do sistema
em produção.
\u2022 Operacional: representa os aspectos operacionais do soft-
ware. Ou seja, visões derivadas deste ponto de vista con-
têm decisões com estratégias de execução, administração
e suporte do software em produção.
8.3.3 Viewtypes do Software Engineering In-
stitute (SEI)
O último conjunto de pontos de vista que apresentamos é o
descrito por Clements et al no livro Documenting Software
Architectures: Views and Beyond [32]. Este conjunto foi criado
com o objetivo de facilitar a documentação, ao contrário da
maioria descrita na literatura, que têm seu foco no auxílio do
projeto da arquitetura.
O conjunto do SEI possui apenas três pontos de vista, que
devem ser especializados por meio dos chamados estilos ar-
quiteturais. Os pontos de vista deste conjunto são:
\u2022 de Componentes e Conectores: este ponto de vista se pre-
ocupa em descrever os aspectos dinâmicos e de comporta-
mento e interações entre os elementos da arquitetura. É
nele em que encontramos os estilos arquiteturais: Pipes-
and-\ufb01lters, Publish-Subscribe, Cliente-Servidor, Peer-to-
Peer e outros.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
226
CHAPTER 8. DOCUMENTAÇÃO DA
ARQUITETURA
\u2022 de Módulos: este ponto de vista se preocupa em descr-
ever a estrutura estática da arquitetura e em como ela
se divide em unidades de código. O estilo arquitetural
Camadas é uma especialização desse ponto de vista.
\u2022 de Alocação: este ponto de vista se preocupa em de-
screver as relações entre o software e o seu ambiente. O
ponto de vista de Alocação se especializa em três aspectos
diferentes: aspectos de implantação, que descreve as re-
lações entre as partes do software e os recursos físicos uti-
lizados (como servidores ou roteadores); aspectos de im-
plementação, que descreve o mapeamento das partes do
software e as partes do código (como pacotes, classes ou
estrutura de diretórios); e aspectos de atribuição de tra-
balho, relacionados à distribuição de responsabilidades
do projeto entre os membros do time de desenvolvimento.
8.4 Documentando a Arquitetura
A partir dos conceitos de decisões, visões e pontos de vista ar-
quiteturais, estamos aptos a registrar o design da arquitetura
em um documento. O primeiro passo para sermos capazes de
escrever um bom documento arquitetural é conhecer os inter-
essados na arquitetura. Esse conhecimento é um parâmetro
fundamental para o processo de escolha dos pontos de vista a
serem usados. Depois de de\ufb01nir os pontos de vista relevantes
aos stakeholders da arquitetura, devemos então registrar as de-
cisões arquiteturais que descrevem o design em visões derivadas
a partir dos pontos de vista escolhidos.
Devemos observar que os processos de de\ufb01nição dos stakehold-
ers, de escolha dos pontos de vista arquiteturais e de descrição
das decisões em visões são dependentes do processo de desen-
volvimento seguido pelo time de desenvolvimento. Além disso,
apesar de descrevermos separadamente o processo de documen-
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
227
tação do processo de design, é possível (e bastante comum) que
ocorram em paralelo, uma vez que a documentação e o design
se ajudam mutuamente para alcançar seus objetivos.
Praticamos os conceitos apresentados neste capítulo no
Apêndice onde ilustramos o documento de arquitetura do
SASF.
8.4.1 Di\ufb01culdades da Documentação
Apesar dos benefícios proporcionados pela documentação da
arquitetura, documentá-la não é fácil. A di\ufb01culdade de doc-
umentar a arquitetura reside, principalmente,