Arquitetura de Software 9.1

Arquitetura de Software
By:
Guilherme Germoglio
By:
Guilherme Germoglio
Online:
< http://cnx.org/content/col10722/1.9/
>
CONNEXIONS
Rice University, Houston, Texas
This selection and arrangement of content as a collection is copyrighted by Guilherme Germoglio. It is licensed under the Creative
Commons Attribution 3.0 license (http://creativecommons.org/licenses/by/3.0/
Collection structure revised: January 5, 2010
PDF generated: October 27, 2012
For copyright and attribution information for the modules contained
in this collection, see p. 254.
Table of Contents
1
2
3
4
Mensagens do Livro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Introduo a Design de Software . . . . . . . . . . . . . . . . . . . 9
Estudo de Caso: SASF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Fundamentos de Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6 Atributos de Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
7 Tcnicas de Design Arquitetural . . . . . . . . . . . . . . . . . 165
8 Documentao da Arquitetura . . . . . . . . . . . . . . . . . . . 189
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Attributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
iv
Available for free at Connexions

<http://cnx.org/content/col10722/1.9>
Chapter 1
Mensagens do Livro
O contedo deste livro est dividido em seis captulos (alm dos

captulos de estudos de caso) e cada captulo serve para transmitir um conjunto especco de mensagens sobre a disciplina
de Arquitetura de Software.
Alm de mensagens, h outros
dois tipos de elementos que so essenciais para a composio

de livro: denies, que descrevem os conceitos fundamentais,
e boas prticas, que so recomendaes a serem seguidas pelo
leitor ao aplicar o conhecimento presente no livro. As recomendaes tm um papel importante, principalmente, nos estudos
de caso, quando o lidamos com os diversos trade-os presentes
na prtica de Arquitetura de Sotware.
A seguir, apresentamos os captulos e suas mensagens:
1.1 Cap. 2: Introduo a Design de

Software
Neste captulo apresentamos design de software e mostramos
que ele essencial no processo de desenvolvimento de software
1 This
content
is
available
<http://cnx.org/content/m17526/1.7/>.
online
at
CHAPTER 1.
MENSAGENS DO
LIVRO
independentemente do nvel de detalhe em que ele aplicado.

No entanto, o design de alto nvel enfatizado, uma vez que
projetar arquitetura fazer design em alto nvel. Mostramos
tambm os elementos que compem os problemas de design.
As mensagens do captulo so:
O design a estrutura ou o comportamento de um sistema que resolve ou contribui para a resoluo das foras
que atuam sobre esse sistema.
Um design representa apenas um ponto no espao de deciso.
Um design pode ser singular, representando apenas uma

folha na rvore de decises ou coletivo, representando
um conjunto de decises.
So cinco os elementos que compem os problemas de

design: objetivos, restries, alternativas, representaes
e solues.
Design necessrio em todos os nveis de detalhe durante

o processo de desenvolvimento do software.
1.2 Cap. 3: Estudo de Caso: SASF

Neste captulo, ilustramos a necessidade de aplicar os conhecimentos de Arquitetura de Software por meio de um problema
de design complexo.
Nele, apresentamos tanto os requisitos
de um sistema web de locao e transmisso de vdeos quanto

seus stakeholders. Uma vez que este captulo apenas descreve
um caso, no h mensagens explcitas a serem transmitidas.

1.3 Cap. 4: Fundamentos de Arquitetura de Software

Este captulo apresenta a denio de Arquitetura de Software usando um padro ISO/IEEE. Como a denio apenas
no o bastante para entendermos o porqu de se aplicar os
conhecimentos de arquitetura durante o ciclo de desenvolvimento, mostramos seus benefcios explicitamente atravs de
exemplos e o estudo de caso.
Alm da denio ISO/IEEE,
mostraremos outras denies que diversos autores zeram ao

longo da histria, uma vez que elas expem caractersticas importantes para o entendimento do assunto. As mensagens deste
captulo so:
Arquitetura design, mas nem todo design arquitetural.
o arquiteto quem dene a fronteira entre o
design arquitetural e o no-arquitetural, denindo quais

decises sero necessrias para atender aos objetivos de
desenvolvimento, de comportamento e de qualidade do
sistema.
A arquitetura tambm um veculo de comunicao entre

stakeholders.
A arquitetura contm as decises antecipadas de design,

que tm o impacto mais caro (caso seja necessrio mudlas ou caso elas estejam erradas).
A arquitetura uma abstrao transfervel do sistema.

A arquitetura facilita a construo do sistema.
A arquitetura facilita o entendimento do sistema.
A arquitetura facilita o reuso durante o ciclo de vida do
sistema.
A arquitetura facilita a evoluo do sistema.

A arquitetura facilita a anlise do sistema.
A arquitetura facilita a gerncia durante o desenvolvimento do sistema.

CHAPTER 1.
MENSAGENS DO
LIVRO
Documentar a arquitetura ajuda no controle intelectual

do software.
Documentar a arquitetura ajuda a manter a integridade

conceitual do sistema.
A arquitetura do software restringe o vocabulrio de alternativas de design.
Documentar a arquitetura permite a ligao entre os requisitos e as decises de design do software.
Documentar a arquitetura tem impacto negativo na impreciso da especicao, que fonte de complexidade do
sistema.
Documentar a arquitetura ajuda na diviso de tarefas

entre os times de desenvolvimento.
1.4 Cap. 5: Stakeholders

Os stakeholders tm grande inuncia no design da arquitetura porque so eles que impem os requisitos que o sistema
deve atender. Por isso, para entendermos essa inuncia, devemos estud-los. Os stakeholders demonstram essa inuncia
porque possuem diversas responsabilidades durante o ciclo de
vida do software.
Neste captulo apresentamos quem so os
stakeholders do software mais comuns e suas caractersticas.

As mensagens deste captulo so:
Stakeholders
inuenciam
arquitetura
de
diversas
maneiras e no necessariamente esto de acordo entre

si e por isso que surgem os trade-os durante o design
do software.
Os seguintes stakeholders devem ser considerados durante o projeto da arquitetura:
o prprio arquiteto ou outros futuros arquitetos;

os engenheiros de requisitos;
os designers;
os desenvolvedores;
os testadores;
os responsveis pela integrao do software com outros sistemas;
os mantenedores do software;
os designers de outros sistemas;
o gerente do desenvolvimento;
o time de controle de qualidade do software.
O arquiteto deve ter pleno conhecimento de todo o ciclo

de vida do software, para ser capaz de lidar com os tradeos que surgiro entre os stakeholders.
O arquiteto deve enteder a relao entre os stakeholders

e os atributos de qualidade do software.
1.5 Cap. 6: Atributos de Qualidade

Uma vez que os atributos de qualidade do software so proporcionados, principalmente, por sua arquitetura e por meio
dos atributos de qualidade que o software atende aos requisitos
no-funcionais, devemos estudar esses atributos. Este captulo
trata tanto dos requisitos no-funcionais quanto dos atributos
de qualidade, enfatizando suas relaes e ferramentas de design
teis para o alcance dos atributos. Usamos o modelo ISO/IEC
9126-1:2001 mas no nos restringimos a ele para denir a
qualidade de software e os atributos que ele deve exibir para
tanto. As mensagens deste captulo so:
A arquitetura se preocupa principalmente com os requisitos no-funcionais, no apenas tcnicos, mas tambm
relacionados a negcio.
No existe a arquitetura correta. Existems arquiteturas

que so mais ou menos adequadas aos requisitos.
A arquitetura permite uma forma de rastreamento entre

a implementao do software e seus requisitos.
CHAPTER 1.
MENSAGENS DO
LIVRO
A arquitetura de software permite diversos atributos de

qualidade, entre eles:
desempenho;
escalabilidade;
conabilidade;
disponibilidade;
segurana;
manutenibilidade;
portabilidade;
extensibilidade.
1.6 Cap. 7: Tcnicas de Design Arquitetural

Ao introduzirmos design de software, citamos alguns princpios
e tcnicas que so fundamentais ao processo, pois facilitam a
representao e a escolha da soluo entre as alternativas de
design.
No entanto, no fomos explcitos sobre como estes
princpios e tcnicas so fundamentais ao processo de design

arquitetural. J no captulo sobre atributos de qualidade, mencionamos a existncia de tticas arquiteturais que ajudam na
implementao de alguns requisitos de qualidade, mas no apresentamos essas tticas a no ser de forma breve e apenas por
meio de exemplos.
Este captulo, por sua vez, tem como objetivo tanto apresentar
os princpios de design em nvel arquitetural, quanto apresentar
algumas tticas arquiteturais que implementam requisitos de
qualidade. Neste captulo, descrevemos os seguintes princpios
de design arquitetural:
uso da abstrao ou nveis de complexidade

separao de preocupaes
uso padres e estilos arquiteturais
Alm disso, apresentamos diversas tticas arquiteturais para

alcanarmos os seguintes atributos de qualidade:
desempenho e escalabilidade
segurana
tolerncia a faltas
compreensibilidade e modicabilidade
operabilidade
1.7 Cap. 8: Documentao da Arquitetura

Depois de entender os conceitos, a importncia e ter noes
de design de arquitetura, o leitor precisar saber como capturar
a informao arquitetura e document-la. Conceitos de vises
arquiteturais so introduzidos para facilitar a documentao
das diferentes dimenses que uma arquitetura apresenta. Este
captulo pretende ser agnstico a linguagens ou modelos de
documentao de arquitetura, mas apresenta um exemplo de
como faz-lo. As mensagens deste captulo so:
O documento de arquitetura auxilia no processo de design, uma ferramenta de comunicao entre stakeholders e pode servir de modelo de anlise do software.
Toda informao presente numa arquitetura uma deciso arquitetural.
Decises arquiteturais podem ser existenciais, descritivas

ou executivas.
Decises arquiteturais se relacionam, podendo restringir,

impedir, facilitar, compor, conitar, ignorar, depender
ou ser alternativa a outras decises arquiteturais.
Um nico diagrama no suciente para conter a quantidade de informao que deve ser mostrada por um arquiteto.
Por isso, a necessidade de mltiplas vises da
arquitetura.
CHAPTER 1.
MENSAGENS DO
LIVRO

Chapter 2
Introduo a Design de
Software
1
Antes de comearmos o estudo e a prtica na disciplina de Arquitetura de Software, apropriado sabermos onde ela se encaixa ao longo do Corpo de Conhecimento em Engenharia de
Software (Software Engineering Body of Knowledge). Design
arquitetural, ou projeto da arquitetura, a primeira das duas
atividades que compem a rea de conhecimento de Design
de Software (Software Design Knowledge Area). A atividade
seguinte design detalhado.
Por ser uma atividade de De-
sign, o design arquitetural se faz por uma mistura de conhecimento e criatividade. Como criatividade algo que se obtm
atravs da experincia, no nosso objetivo ensin-la. No entanto, buscamos ao longo desse livro transmitir o conhecimento
necessrio para a criao de arquiteturas de sistemas de software.
Certamente, uma base conceitual em Design de Software
necessria para uma melhor compreenso desse livro.
Dessa
maneira, este captulo procura fundamentar o conhecimento do
1 This
content
is
available
online
at
CHAPTER 2.
10
INTRODUO A
DESIGN DE SOFTWARE
leitor nessa rea, de forma que sua importncia e seus benefcios proporcionados sejam reconhecidos. Em outras palavras,
esse captulo far com que o leitor seja capaz de:
Reconhecer os conceitos bsicos de design de software

Descrever problemas de design atravs de seus elementos
fundamentais
Identicar princpios de design de software e explicar seus

benefcios
Diferenciar design de baixo-nvel (detalhado) de design

de alto-nvel (arquitetural) e saber quando aplicar cada
um
2.1 Design de Software

A relevncia de se projetar ou fazer design de software
pode ser explicada pela complexidade crescente dos sistemas de
software. Devido a essa complexidade, o risco de se construir
um sistema que no alcance seus objetivos eminente.
Para evitar tal risco, a prtica comum de qualquer engenharia
para se construir um artefato complexo, um sistema de software complexo em nosso caso, constru-lo de acordo com
um plano.
constru-lo.
Em outras palavras, projetar o sistema antes de

O resultado dessa atividade, tambm conhecida
como de atividade de design, tambm chamado de design.

O design facilita duas atividades que so essenciais no ciclo
de vida de um sistema de software.
Primeiro, ele possibilita
a avaliao do sistema contra seus objetivos antes mesmo dele

ser construdo. Dessa maneira, ele aumenta a conana de que
o sistema construdo, se de acordo com o design, alcanar seus
objetivos. Obviamente, uma vez que nesse ponto h apenas o
modelo do sistema o design , a avaliao no ser completa,
mas isso tambm no quer dizer que ela no oferea resultados

11
importantes que levem ao sucesso do sistema. J a outra atividade beneciada pelo design a prpria construo do sistema,
dado que ele tambm serve como guia para a implementao
do software.
A seguir, mostramos um exemplo de quando o design permite a
avaliao do software. O Exemplo 2.1 mostra parte da primeira
verso do design de um sistema distribudo de armazenamento,
o HBase
e, atravs de uma breve avaliao desse design, ob-
servamos uma grave limitao do software.
Exemplo 2.1
O HBase um sistema de armazenamento distribudo.
Isso quer dizer que os dados submetidos a ele no sero
guardados em um nico servidor, mas em vrios. De
forma simplicada, o design do HBase dene dois tipos
de entidades no sistema: o data node, que o subsistema que armazena os dados, e o master node, que
o subsistema que sabe em quais data nodes os dados
foram escritos e podem ser recuperados. Na primeira
verso do HBase, s existia um master node que coordenava todos os data nodes. Assim, para recuperar
ou escrever dados no HBase, um cliente realizava os
seguintes passos: primeiro, o cliente se comunicava com
o master node a m de conseguir, de acordo com uma
chave , o endereo do data node em que ele pode realizar a operao desejada (leitura ou escrita).
Em
seguida, o master node, que coordena onde os dados

devem car, retorna o endereo do data node que deveria possuir dados para referida chave. A partir da, o
cliente, j com o endereo, se comunicava diretamente
com o data node e realizava a operao desejada (escrita ou leitura).
2 Apache
HBase :
urlhttp://hbase.org
3 Os dados so inseridos no HBase na forma (chave,valor).

CHAPTER 2.
12
INTRODUO A
DESIGN DE SOFTWARE
Se avaliarmos este design, podemos perceber duas caractersticas do HBase. A primeira, que ele no adota
o uso de um cliente magro (thin client). Com isso, a
implementao e congurao do cliente se torna mais
complexa, uma vez que o cliente precisa conhecer o protocolo de escrita e leitura do HBase, alm de precisar
acessar tanto o master node quanto os data nodes. Isto
diculta o desenvolvimento, a operabilidade e a eventual evoluo do software, uma vez que mudanas no
protocolo afetam clientes e servidores. Alm disso, por
possuir apenas um master node, a funcionalidade do
HBase ca condicionada sua disponibilidade. Anal,
se o master node estiver inacessvel, nenhum cliente
poder ler ou escrever no sistema, o que o torna um
ponto nico de falhas.
2.1.1 O que Design de Software

Para denir design de software, alguns autores o fazem em dois
sentidos distintos:
quando design de software usado como
produto e quando usado como processo. Quando usado no

primeiro sentido, o termo design de software indica o produto
que emerge do ato (ou processo) de projetar um sistema de
software e sendo assim algum documento ou outro tipo de representao do desejo do projetista (ou designer). Esse produto
o resultado das decises do designer para formar uma abstrao do sistema que desejado no mundo real. Existem diversas formas de como representar essa abstrao do sistema.
Podemos citar, por exemplo, desenhos usando caixas e setas,
textos descritivo, ou ainda uso de linguagens ou ferramentas
criadas para este propsito, como linguagens de modelagem
de software, redes de petri, pseudocdigo, etc.
J quando o
termo usado no segundo sentido, fazer design indica o pro-

13
cesso seguido para se obter um projeto. Esse um processo que

faz parte do processo de desenvolvimento e que orientado aos
objetivos do software. Ele deve ser realizado tendo em mente
os diversos stakeholders do sistema e deve ser fundamentado
no conhecimento do designer sobre o domnio do problema.
A partir da viso de design como artefato, podemos observar
que ele deve descrever diversos aspectos do software para que,
assim, possibilite sua construo. Entre estes aspectos, esto:
a estrutura esttica do sistema, incluindo a hierarquia de

seus mdulos;
a descrio dos dados a serem usados;

os algoritmos a serem usados;
o empacotamento do sistema, em termos de como os mdulos esto agrupados em unidades de compilao; e
as interaes entre mdulos, incluindo as regras de como

elas devem acontecer e porque elas acontecem.
Podemos perceber que, apesar dos exemplos anteriores descreverem
apenas
parte
do
design
de
dois
sistemas,
eles
mostram boa parte dos aspectos que esperamos no design de

um software.
Por m, citamos uma denio de design que engloba todos
estes aspectos:
Denio 2.1: design de software

" tanto o processo de denio da arquitetura,
mdulos, interfaces e outras caractersticas de um
sistema quanto o resultado desse processo.
4 Freny Katki
et al, editors. IEEE Standard Computer Dictionary:

Compilation of IEEE Standard Computer Glossaries. Institute of Electrical and Electronics Engineers Inc., 1991.
CHAPTER 2.
14
INTRODUO A
DESIGN DE SOFTWARE
2.1.2 Caractersticas de Design de Software
Projetar os diversos aspectos de um sistema de software um

processo trabalhoso. No entanto, pode proporcionar diversos
benefcios.
Design de software permite avaliao prvia.
Como desen-
volver software custa tempo e dinheiro, no parece sensato

algum investir seus recursos no desenvolvimento de um sistema que no soluciona os problemas propostos pelos interessados. Dessa maneira, a avaliao prvia do sistema se torna
imprescindvel para garantir que ele alcance os objetivos desses
interessados. Como o design descreve diversos aspectos que estaro presentes no sistema quando construdo, ele permite esse
tipo de avaliao. Alm disso, fazer o design de um sistema ,
geralmente, mais barato que constru-lo.
Exemplo 2.2
Considerando o sistema do Exemplo 2.1 e que um
de seus objetivos fosse a alta disponibilidade, podemos avaliar que design apresentado no seria a melhor
soluo para o objetivo proposto. Isso ocorre porque
seu design possui um ponto nico de falhas, que uma
caracterstica indesejvel para sistemas que buscam
alta disponibilidade. Note ainda que no foi necessrio
ter o HBase desenvolvido para percebermos esse problema (na poca em que implementava tal design, ele
possua cerca de cem mil linhas de cdigo e alguns anos
de desenvolvimento e, portanto, no sendo um software
de desenvolvimento trivial), bastou apenas estudarmos
seu design.
Design de software estimula modelagem. Ao modelar um sistema, o designer se concentra no domnio do problema, ignorando temporariamente detalhes menos signicativos para se
alcanar a soluo. Isso facilita na separao da complexidade
essencial da complexidade acidental do problema. E, como j
15
dito por Fred Brooks em The Mythical Man-Month, essa separao benca para a qualidade nal do sistema projetado.
Design de software envolve planejamento. Uma vez que o design serve de guia para a construo do sistema, o designer deve
ento antecipar o que ser necessrio para tanto. Esse planejamento ajuda na estimativa dos diversos custos envolvidos no
desenvolvimento do sistema. Entre esses custos, podemos citar:
Quanto tempo durar todo o desenvolvimento,

Quantos desenvolvedores sero necessrios para o mdulo
A,
Se comprado, quanto custar o mdulo B, e se for implementado,
Ou qual ser o custo total do desenvolvimento do sistema.
Design de software facilita a comunicao, pois contm conhecimento sobre o sistema que pode ser gravado, transmitido
e discutido entre os interessados. Um caso bem comum o de
apresentar um sistema a novos membros de um time de desenvolvimento. Informaes valiosas, como por exemplo, quais os
principais mdulos e seus diversos comportamentos, lhes podem ser passadas atravs do design do sistema antes de mostrlos o cdigo-fonte.
Dessa maneira, essas informaes de alto
nvel de abstrao ajudaro a situ-los no cdigo posteriormente. No entanto, o design no serve apenas para os desenvolvedores.
Um usurio do sistema pode procurar no design
informaes de um nvel ainda maior de abstrao, como quais

funes o sistema capaz de realizar, ou qual o desempenho
delas.
Por outro lado, design de software tambm demanda algumas
observaes importantes.
O problema a ser resolvido pode no permanecer o mesmo
durante todo o processo de design.
Ao passo que o design

CHAPTER 2.
16
INTRODUO A
DESIGN DE SOFTWARE
implementado, o cliente, que o stakeholder interessado em

que o software construdo solucione um problema em particular, (1) pode mudar de ideia quanto natureza do problema;
(2) pode ter descrito o problema incorretamente; ou ainda (3)
pode decidir que o problema mudou ou mesmo que j fora
resolvido enquanto o design feito. Essas possibilidades no
devem ser ignoradas durante o desenvolvimento, uma vez que
elas podem ocasionar em perda de tempo e dinheiro durante
a fase de design ou ainda ocasionar o fracasso no atendimento
das necessidades do cliente.
H diferenas entre o design e o sistema construdo a partir
dele. O design de um software apenas um modelo, do qual o
nvel de detalhes pode no ser adequado para certos tipos de
avaliao.
Por sinal, avaliar um design insucientemente de-
talhado pode levar a resultados errneos e, consequentemente,

h sistemas que no resolvem os problemas da forma esperada. Isso comum acontecer, por exemplo, quando por erro
do projetista, detalhes importantes para a avaliao no so includos no design. O exemplo a seguir ilustra um caso em que a
avaliao inadequada resultou em um produto com problemas.
Exemplo 2.3
Um caso conhecido de produto com falhas por avaliao inadequada o caso de um sistema de controle de armamento para cruzadores da marinha norteamericana que foi desenvolvido pela empresa Aegis.
Depois
de
desenvolvido,
sistema
de
armamento
foi instalado no cruzador U.S.S. Ticonderoga para o

primeiro teste operacional. No entanto, os resultados
do teste demonstraram que o sistema errava 63% dos
alvos escolhidos devido a falhas no software.
Poste-
riormente, foi descoberto que a avaliao e os testes

do software de controle foram realizados numa escala
menor do que as condies reais e que, alm disso, os

17
casos de teste incluam uma quantidade de alvos menor
que a esperada em campo de batalha.
Por mais ecaz que um design seja, sua implementao pode

no ser. O fato de haver um design bem elaborado para um determinado software no garante que na fase de implementao
os desenvolvedores sigam as regras previamente especicadas e
que o cdigo produzido reita elmente o que foi especicado.
Isto certamente um grande problema na construo de sistemas de software, pois pode acarretar a construo de um produto que no era o esperado, e at mesmo levar ao insucesso em
sua construo. Felizmente, na Engenharia de Software existem dois mecanismos que visam diminuir as divergncias entre
design e implementao. O primeiro mecanismo diz respeito
vericao de software, isto , vericar se o software foi construdo corretamente, se atendeu s especicaes do design.
Por outro lado, a validao de software est ligada satisfao
do cliente diante do produto, isto , se o software construdo
o desejado, se atende aos requisitos do cliente.
2.2 Elementos do processo de design de

software
O processo de design pode ser descrito como o processo de
escolha da representao de uma soluo a partir de vrias alternativas, dadas as restries que um conjunto de objetivos
envolve. Esse processo, ilustrado na Figura 2.1, pode ser dividido em duas fases: diversicao e convergncia.
5 Uma descrio mais completa deste caso pode ser encontrada no artigo
The Development of Software for Ballistic-Missile Defense, de Lin.

CHAPTER 2.
18
INTRODUO A
DESIGN DE SOFTWARE
Figura 2.1:
Ilustrao do processo de design
durante a fase de diversicao em que as alternativas so

geradas. Por alternativas, no nos referimos necessariamente a
documentos descrevendo uma possvel soluo, mas tambm a
ideias de soluo. Essas alternativas so solues em potencial
e so geradas/obtidas a partir do conhecimento e da experincia do designer. J na fase de convergncia, o designer escolhe
a alternativa (ou combinao de alternativas) que satisfaz(em)
aos objetivos esperados.
A escolha compor a soluo que
se sujeitar s restries impostas pelo domnio do problema.

Essa soluo ser descrita por meio de alguma representao
e essa representao escolhida deve estar de acordo com seus
propsitos: descrever a soluo e permitir a construo do sis-

19
tema que melhor alcana os objetivos esperados.

Os elementos enfatizados no pargrafo anterior (objetivos, restries, alternativas, representaes e solues), juntos, denem um arcabouo conceitual que nos ajuda a entender o
processo de design de software.
2.2.1 Objetivos
O processo de design tem incio com uma necessidade. Se algo
projetado, e consequentemente construdo, porque o produto
proveniente do projeto suprir essa necessidade.
Em Engen-
haria de Software, a necessidade parte do cliente que especica
quais suas necessidades e, portanto, quais os objetivos a serem

atingidos pelo sistema de software a ser projetado. Assim, o
objetivo do processo de design pode ser denido como:
Denio 2.2: objetivo de design

Aquilo que se pretende alcanar para resolver as necessidades do cliente.
Em design de software, objetivos tambm so chamados de
requisitos. O design se preocupa com dois tipos de requisitos:
requisitos funcionais e requisitos no-funcionais. Um requisito
funcional especica a funcionalidade que um sistema exibe.
Denio 2.3: requisito funcional

a declarao de uma funo ou comportamento
providos pelo sistema sob condies especcas.
Em outras palavras, o que o sistema faz para alcanar s expectativas do cliente. Por exemplo, um requisito funcional de
6 Vale lembrar que h transitividade nas necessidades do cliente. Um

exemplo de quando acontece quando clientes e usurios do sistema so
entidades distintas.
Ento, entre as necessidades do cliente estaro: as
necessidades do usurio devem ser atendidas. E, portanto, o software ter

que atender ter que satisfazer tambm aos objetivos do usurio, alm dos
objetivos do cliente.

CHAPTER 2.
20
INTRODUO A
DESIGN DE SOFTWARE
um programa de ordenao de nmeros pode ser descrita como

sua capacidade de ordenar inteiros; ou, se estamos falando de
um sistema de informao de uma locadora de lmes em DVD,
temos como requisitos funcionais, entre outros, a capacidade
de buscar um lme usando palavras-chave, a capacidade de realizar o aluguel de um ou vrios DVDs, ou a capacidade de
realizar a devoluo de um ou vrios DVDs.
Por outro lado, um requisito no-funcional, especica propriedades ou caractersticas que o sistema de software deve
exibir diferentes dos requisitos funcionais. Os requisitos nofuncionais so atendidos pelos atributos de qualidade do software.
Denio 2.4: requisito no-funcional

a descrio de propriedades, caractersticas ou restries que o software apresenta exibidas por suas funcionalidades.
Em outras palavras, basicamente como o sistema funcionar.
De volta ao exemplo do programa de ordenar nmeros, um
requisito no-funcional que podemos mencionar o tempo de
execuo da funo de ordenao do sistema (por exemplo,
aceitvel que o tempo de execuo do algoritmo de ordenao
tenha uma taxa de crescimento de
O (nlogn), onde n a quan-
tidade de elementos a serem ordenados).
J no sistema da
locadora de lmes, um exemplo de atributo de qualidade a

exposio de algumas de suas funcionalidades via internet (e.g.,
busca e reserva de lmes atravs de um site disponibilizado pelo
sistema).
Como os requisitos no-funcionais e os atributos de qualidade
tm um papel importante na arquitetura do software, ns dedicaremos um captulo a eles, onde sero descritos, categorizados
e exemplicados em detalhes, alm de serem relacionados aos
stakeholders que os demandam.

21
2.2.2 Restries
O produto de design deve ser vivel. Dessa maneira, restries
so as regras, requisitos, relaes, convenes, ou princpios
que denem o contexto do processo de design, de forma que
seu produto seja vivel.
Denio 2.5: restrio de design

A regra, requisito, relao, conveno, ou princpio
que dene o texto do processo de design.
importante saber que restries so diretamente relacionadas
a objetivos e que, em alguns casos, eles so at intercambiveis.
No entanto, uma vez que no so apenas os objetivos que guiam
o processo de design, necessrio diferenciar objetivos de restries. Em outras palavras, um sistema pode ter objetivos
claros, mas seu design ou algumas alternativas dele podem ser
inviveis devido s restries.
A seguir, apresentamos dois exemplos que nos ajudaro a entender o papel das restries no design. No primeiro exemplo,
apesar do sistema ter um objetivo claro, seu design no vivel
devido a uma restrio.
Exemplo 2.4
Consideremos que um cliente deseje um sistema com
um nico objetivo: o sistema deve decidir se um programa, cuja descrio informada como parmetro de
entrada, termina sua execuo ou no.
Um designer inexperiente pode at tentar encontrar alguma alternativa de design para esse requisito mas
podemos ter certeza que a tentativa ser em vo. Como
bem conhecido, h uma restrio terica em Cincia da Computao, conhecida como o problema da
parada, que impede o desenvolvimento de um programa capaz de alcanar o objetivo proposto.
Como
essa restrio impede a criao de qualquer alternativa

CHAPTER 2.
22
INTRODUO A
DESIGN DE SOFTWARE
de design que satisfaa o cliente, podemos observar que
um design pode ser se tornar invivel mesmo que seus
objetivos sejam bem claros.
J no segundo exemplo, o sistema tambm tem um objetivo

claro. No entanto, uma restrio torna uma possibilidade de
design invivel.
Exemplo 2.5
Um cliente especica o seguinte requisito para seu sistema de software: ele deve ser capaz de ler dados de um
leitor de cartes de um modelo especco. No entanto,
ao estudar o requisito e, consequentemente, o leitor de
cartes, o designer encontra a seguinte restrio.
fabricante do leitor em questo no o fornece driver

necessrio para um dos sistemas operacionais em que
o sistema deve executar.
Podemos observar que, se no fosse por essa restrio, o
design para o mdulo de entrada de dados do sistema
seria simples:
apenas dependeria do driver do leitor
para obter os dados dos cartes. No entanto, agora o

designer ter que criar um design alternativo para contornar a restrio encontrada. Para isso, podemos citar
algumas possibilidades desse design.
Uma possibili-
dade seria emular um dos sistemas operacionais suportados quando o software estivesse executando num ambiente no suportado. Isso signica que seria necessria
a criao de uma camada de abstrao entre o driver do
leitor e o sistema operacional onde o software est executando, onde essa camada representaria o ambiente
operacional suportado. Essa camada de abstrao, ento, seria implementada pelo sistema nativo ou por
um emulado, caso o nativo fosse o no-suportado pelo
driver. Outra possibilidade de design seria o projeto e
implementao do prprio driver para o ambiente no-

23
suportado.
2.2.3 Alternativas
Uma alternativa de design uma possibilidade de soluo.
Uma vez que problemas de design geralmente possuem mltiplas solues possveis, comum que sejam geradas mais de
uma alternativa para a soluo de um nico problema. Note
que o designer no necessariamente documentar todas as possibilidades de soluo, mas, ao menos, considerar algumas delas para eleio de uma soluo, mesmo que informalmente.
Denio 2.6: alternativa de design

Uma possibilidade de soluo representada em nvel
de conhecimento.
O que precisamos observar que o designer deve realizar duas
tarefas essenciais aps entender os objetivos e restries envolvidos no problema de design: gerar alternativas de design e
eleger a soluo do problema dentre as alternativas geradas.
A gerao de alternativas o real desao para os designers.
Diferente dos problemas de deciso, onde alternativas so conhecidas ou buscadas atravs de mtodos conhecidos, problemas de design pedem a criao de alternativas.
O processo
de criao deve ser controlado por princpios de design, pela

experincia e imaginao do designer e deve ser guiado pelos objetivos do produto impostos pelos stakeholders. Alguns
princpios essenciais de design sero apresentados ainda neste
captulo.
J a eleio da soluo simplesmente a escolha de uma dentre
as alternativas geradas, desde que essa sirva para a soluo do
problema. A escolha da soluo deve ser realizada baseada em
avaliaes e experincia.

CHAPTER 2.
24
INTRODUO A
DESIGN DE SOFTWARE
Exemplo 2.6
De volta ao nosso programa de ordenao, consideremos apenas uma de suas caractersticas: o algoritmo
de ordenao a ser usado. Vamos observar quantas alternativas um designer poderia gerar s a partir dessa
caracterstica.
Uma rpida pesquisa na internet retorna nove algoritmos que respeitam o requisito imposto anteriormente
de crescimento do tempo de execuo (O (nlogn)):
binary tree sort, heapsort, in-place merge sort, introsort, library sort, merge sort, quicksort, smoothsort, strand sort. Assim, esses nove algoritmos poderiam ser transformados em nove alternativas de design.
Adicionalmente, um designer mais experiente
em ordenao saberia que os dados de entrada podem

denir o desempenho real do algoritmo, uma vez que
uma das alternativas pode ter um timo desempenho
para uma determinada entrada, enquanto outra alternativa, ainda que respeitando o mesmo desempenho
assinttico
O (nlogn),
pode ter um pssimo desem-
penho real para a mesma entrada.
Neste caso, ele
deniria que dois algoritmos sero usados no design,

de forma que, de acordo com os dados de entrada, o
algoritmo de melhor desempenho real para esses dados
seja escolhido em tempo de execuo.
Assim, ainda
mais alternativas de design so geradas.

Devemos observar que a gerao de alternativas poderia continuar indenidamente caso o designer considerasse outros aspectos do problema. Dessa maneira, quando parar a gerao de alternativas um problema tambm a ser resolvido pelo designer,
uma vez que problemas de design geralmente tm um nmero
innito de solues em potencial. Essa noo de quando parar
o processo de gerao de alternativas, certamente, adquirida
com a experincia.
25
2.2.4 Representaes
A representao a linguagem do design. Apesar do real produto do processo de design ser a representao de um sistema
de software que possibilita sua construo, descrever o sistema
no o nico propsito das representaes. A representao
tambm facilita o prprio processo de design, uma vez que
ajuda na comunicao dos interessados e tambm serve como
registro das decises tomadas.
Denio 2.7: representao de design

A linguagem do processo de design que representa o
produto do design para sua construo e tambm d
suporte ao processo de design como um todo.
A representao facilita a comunicao porque torna as alternativas em produtos manipulveis, que podem ser comunicados,
avaliados, e discutidos, no s por seus criadores, mas tambm
por outros interessados.
importante observar que existem diversas dimenses a serem
representadas numa nica alternativa de design. Essas dimenses abrangem comportamento, estrutura, relaes entre entidades lgicas e entidades fsicas, entre outros.
Essas dimen-
ses so normalmente descritas em diferentes tipos de representaes, que, em outro momento, sero chamadas de vises.
Para exemplicar representaes de design, apresentaremos
duas dimenses derivadas do nosso programa-exemplo de ordenao usando duas representaes diferentes.
A primeira
representao, ilustrada pela Figura 2.2, mostra a dimenso
estrutural de uma alternativa de design usando UML . Examinando essa representao, podemos observar alguns aspectos
da soluo:
como a soluo foi decomposta em classes fun-
cionais, como as diversas classes da estrutura se relacionam

entre si, ou at em que pontos poderamos reusar pedaos de
7 Unied
Modeling Language
(UML)

CHAPTER 2.
26
INTRODUO A
DESIGN DE SOFTWARE
software prontos para a construo, desde que implementem

as mesmas interfaces descritas na representao. No entanto,
devemos tambm observar que essa representao no autocontida, uma vez que necessrio conhecimento em UML para
entend-la completamente.
Figura 2.2:
ordenao
Representao estrutural do programa de
J a segunda representao, Figura 2.3, mostra parte do comportamento do programa de ordenao com alto nvel de detalhe. Apesar de no conseguirmos extrair dessa representao
a mesma informao apresentada na gura anterior, essa nos
permite analisar seu comportamento assinttico em relao ao
crescimento do tamanho dos dados de entrada.
Alm disso,
podemos tambm analisar o espao consumido na execuo do

algoritmo.
27
Figura 2.3:
Pseudocdigo do Merge sort
Ambas as representaes mostram aspectos importantes do design de um software. No entanto, os stakeholders envolvidos no
seu desenvolvimento podem ainda estar interessados em outros
CHAPTER 2.
28
INTRODUO A
DESIGN DE SOFTWARE
aspectos alm da estrutura ou anlise assinttica do algoritmo.

Por isso, outras representaes podem ainda ser necessrias
para mostrar outros aspectos do sistema, e papel do processo
de design e do designer prov-las.
Por m, se considerarmos mltiplas verses ao longo do tempo
de uma nica representao, poderemos observar a evoluo
das decises de design feitas ao longo desse perodo.
Assim,
se considerarmos as diversas verses obtidas at se alcanar

o algoritmo descrito na Figura 2.3, perceberamos a evoluo
desde o merge sort padro at o merge sort in-place considerado pelo designer. Ento, o histrico do design se torna pea
fundamental para se entender quais decises passadas levaram
ao estado atual do design e, consequentemente, do sistema.
2.2.5 Solues
A soluo do design no nada alm do que a descrio que
permite desenvolvedores construir um sistema de software a
partir dos detalhes especicados por uma ou diversas representaes.
Suas principais caractersticas sero descritas nos
pargrafos a seguir.
Denio 2.8: soluo do design

A descrio do design que permite a construo do
sistema de software que alcana os objetivos do design.
Solues de design reetem a complexidade do problema, geralmente por mostrar diversos elementos e relaes que compem
o problema. possvel observar essa caracterstica quando, por
exemplo, fazendo o design do sistema de informao de uma locadora que j mencionamos anteriormente. Qualquer que seja
a soluo, ela conter elementos como lmes, DVDs, clientes
ou gneros de lmes, pois todos eles so inerentes ao problema
em questo. No entanto, s os elementos no so o bastante

29
para compor a soluo.
A soluo deve tambm conter re-
laes do tipo: um cliente pode alugar um ou mais DVDs,

um lme pode ter um ou mais gneros, ou um DVD pode
conter um ou mais lmes. Em outras palavras, a soluo deve
conter relaes similares s relaes encontradas no domnio do
problema. Vale lembrar que, quando diversos elementos tm
diversas relaes diferentes entre si, a complexidade emerge e
por isso que fazer design difcil. Adicionalmente, para complicar ainda mais, comum que os problemas tenham muitos
elementos e relaes que no so completamente conhecidos.
difcil validar solues de design. A complexidade inerente
ao problema faz surgir diversos pontos de possvel validao
em relao aos objetivos de design.
No entanto, o problema
reside na preciso da descrio dos objetivos.
Normalmente,
para problemas complexos, objetivos so descritos num altonvel de abstrao que diculta ou impossibilita bastante a
avaliao das solues.
E, por m, a maioria dos problemas de design aceita diversas
solues. Isso algo natural a problemas de design: uma vez
que diversas alternativas podem ser geradas a partir de um
nico problema de design, diversas solues podem ser obtidas.
2.3 Nveis de design de software

O produto do processo de design sempre uma soluo de
design. Apesar de ser a descrio que permite a construo do
sistema, nada foi dito sobre o nvel de detalhe contido nessa
soluo. Acontece que, na verdade, o design pode ocorrer em
diversos nveis de detalhe.
De acordo com o Guia para o Corpo de Conhecimento em Engenharia de Software, o processo de design de software consiste
em duas atividades: design de alto nvel e design detalhado.

CHAPTER 2.
30
INTRODUO A
DESIGN DE SOFTWARE
O design de alto nvel, tambm conhecido como design arquitetural, trata de descrever a organizao fundamental do sistema,
identicando seus diversos mdulos (e sua relaes entre si e
com o ambiente) para que se alcancem os objetivos propostos
pelo cliente.
Denio 2.9: design arquitetural

Descreve a arquitetura do software ou, em poucas
palavras, como o software decomposto e organizado
em mdulos e suas relaes.
Ao contrrio do design de alto nvel, o design detalhado se
preocupa com a descrio detalhada de cada mdulo possibilitando a construo e se adequando ao design de alto nvel.
Denio 2.10: design detalhado

Descreve o comportamento especco e em detalhes
dos mdulos que compem o design arquitetural.
Apesar dessa diviso conceitual de design em duas atividades,
essa diviso pode no acontecer durante o processo de desenvolvimento do software. Algumas vezes, o designer ou quem
assume seu papel realiza ambas as atividades em paralelo,
concebendo assim um produto de design que permitir tanto o
alcance dos requisitos de qualidade (que normalmente tarefa
da arquitetura), quanto a construo precisa do sistema por
meio de seus detalhes.
No entanto, adotaremos a separao
conceitual das duas atividades de forma que possamos nos focar no design arquitetural, que o principal assunto desse livro
e que ser discutido nos prximos captulos.
2.4 Princpios e tcnicas de design de

software
Antes de iniciarmos nossos estudos em Arquitetura de Software, gostaramos de lembrar alguns princpios e tcnicas que

31
so essenciais ao design de software.

H diversos princpios, tcnicas, e abordagens nessa rea que
geralmente resultam em bons produtos de design de software.
Uma vez que h muitos livros e artigos sobre esse assunto,
gostaramos apenas de fazer uma breve exposio do assunto
nessa seo, fazendo com que o leitor relembre os princpios e
tcnicas caso j os conhea e indicando referncias para um
maior aprofundamento sobre o assunto. Os princpios, tcnicas
e abordagens essenciais para um designer que apresentaremos
so as seguintes:
Diviso e conquista
Abstrao
Encapsulamento
Modularizao
Separao de preocupaes
Acoplamento e coeso
Separao de polticas da execuo de algoritmos
Separao de interfaces de suas implementaes
2.4.1 Diviso e Conquista

Diviso e conquista uma tcnica para resoluo de problemas que consiste em decompor um problema em subproblemas menores e independentes a m de resolv-los separadamente, para que, posteriormente, as solues sejam combinadas e formem a soluo do problema inicialmente proposto.
A estratgia baseada na ideia de que atacar um problema
complexo por diversas frentes mais simples e factvel de
resoluo do que tentar resolv-lo completamente de uma s
vez. A tcnica de diviso e conquista possui trs etapas bem
denidas:

CHAPTER 2.
32
INTRODUO A
DESIGN DE SOFTWARE
Diviso:
dividir o problema original em subproblemas
menores;
Conquista: resolver cada um dos subproblemas gerados

na fase de diviso;
Combinao: combinar as solues de cada subproblema,

compondo a soluo para o problema inicial.
Em Cincia da Computao, essa estratgia muito utilizada

no projeto de algoritmos e, normalmente, instanciada atravs
do uso de recurso, uma vez que os problemas devem ser decompostos e as solues dos subproblemas devem ser combinadas ao nal da execuo para compor a soluo do problema
inicial.
Por exemplo, o algoritmo de ordenao mergesort se
utiliza dessa tcnica para ordenar uma sequncia de inteiros de

maneira eciente. Esse algoritmo se baseia na idia de quem
dadas duas sequncias ordenadas, trivial orden-las em uma
nica sequncia.
Portanto, a estratgia do mergesort par-
ticionar uma sequncia em vrias subsequncias at que seja

trivial orden-las, isto , sequncias de dois elementos.
Por
m, o algoritmo combina as sequncias em uma s sequncia

ordenada.
No entanto, como este livro foi escrito com foco em arquitetura de software, nada mais apropriado do que trazermos exemplos em nvel arquitetural dos assuntos que abordamos. A
estratgia de diviso e conquista tambm aplicada constantemente em decises de mais alto nvel no projeto de software.
Por exemplo, a deciso de organizar uma aplicao web em
camadas nada mais que dividir um problema maior em diferentes nveis de abstrao, onde cada camada ser responsvel
por implementar um servio mais bsico e especco (apresentao, lgica de negcio e armazenamento).
Vrios so os benefcios providos pela estratgia de diviso e
conquista.
No nosso exemplo, a diviso da arquitetura em

33
camadas propicia a implementao de cada camada separadamente. Alm disso, as camadas podem ser tratadas como componentes reusveis de software, uma vez que implementam um
servio nico e bem denido.
Portanto, diviso e conquista
tambm viabiliza o reuso de software.
2.4.2 Abstrao
Abstrao um princpio essencial para se lidar com complexidade. Esse princpio recomenda que um elemento que compe
o design deva ser representado apenas por suas caractersticas
essenciais, de forma que permita a distino de outros elementos por parte do observador.
Como resultado, temos a rep-
resentao de um elemento do design mais simples, uma vez

que detalhes desnecessrios so descartados, facilitando ento
o entendimento, comunicao e avaliao.
O que poderemos observar que a maioria das tcnicas empregadas por designers ajudam na elevao do nvel de abstrao
do design e, assim, baixam o nvel de complexidade da soluo.
2.4.3 Encapsulamento
Encapsulamento est relacionado ocultao de detalhes de
implementao de um elemento de um sistema aos que usaro
esse elemento. Fazendo isso, o acoplamento entre os elementos minimizado e sua contribuio para a complexidade do
sistema restringida s informaes que eles expem.
Encapsulamento pode ser obtido de diferentes maneiras: modularizando o sistema, separando suas preocupaes, separando
interfaces de implementaes, ou separando polticas da execuo de algoritmos.

CHAPTER 2.
34
2.4.4 Modularizao
INTRODUO A
DESIGN DE SOFTWARE
Modularizao a decomposio signicativa do sistema em

mdulos.
A modularizao introduz parties bem-denidas
e documentadas ao sistema ao decidir como estruturas lgicas

do sistema sero divididas sicamente. Podemos citar alguns
benefcios da modularizao:
Facilita o entendimento, uma vez que cada mdulo pode

ser estudado separadamente;
Facilita o desenvolvimento, uma vez que cada mdulo

pode ser projetado, implementado e testado separadamente;
Diminui o tempo de desenvolvimento, uma vez que mdulos podem ser implementados em paralelo, ou ainda
reusados; e
Promove a exibilidade no produto, uma vez que um

mdulo pode ser substitudo por outro, desde que implemente as mesmas interfaces.
2.4.5 Separao de preocupaes

A separao de preocupaes est fortemente ligada ao princpio da modularizao. De certa maneira, a separao de preocupaes dene a regra para denir os mdulos de um sistema: preocupaes diferentes ou no-relacionadas devem se
restringir a mdulos diferentes.
Assim, separando preocu-
paes, obtemos benefcios semelhantes aos da modularizao.
2.4.6 Acoplamento e coeso

Acoplamento e coeso so princpios usados para medir se mdulos de um design foram bem divididos.

35
Acoplamento a medida de interdependncia entre mdulos

de software. Ou seja, quanto mais dependente um mdulo A
da implementao do mdulo B, maior o acoplamento entre
os mdulos A e B. Alto acoplamento implica que (1) os mdulos envolvidos sero mais difceis de entender, uma vez que
precisam ser entendidos em conjunto; (2) os mdulos envolvidos sero mais difceis de modicar, uma vez que as mudanas
impactaro mais de um mdulo; e (3) os mdulos envolvidos
sero mais difceis de manter, uma vez que um problema num
mdulo se espalhar pelos mdulos com quem est altamente
acoplados.
Por outro lado, coeso uma medida intramdulo.
Ela a
medida da relao entre tarefas realizadas dentro de um mesmo

mdulo. As tarefas de um mdulo podem estar relacionadas
entre si por diferentes motivos. Esses motivos so usados para
classicar os diferentes tipos de coeso:
Coeso funcional::
Coeso sequencial::
as
tarefas
esto
agrupadas
por
suas
funes serem similares.

as tarefas esto agrupadas por elas per-
tencerem mesma sequncia de operaes. Elas compartilham dados a cada etapa da sequncia, mas no realizam uma operao completa quando executadas juntas.
Coeso comunicativa::
as tarefas esto agrupadas porque
usam os mesmos dados, mas no esto relacionadas de

nenhuma outra maneira.
Coeso temporal::
Coeso procedural::
Coeso lgica::
as tarefas esto agrupadas por serem ex-
ecutadas no mesmo intervalo de tempo.

as tarefas esto agrupadas porque elas
devem ser executadas numa ordem especca.

as tarefas esto agrupadas por compartil-
harem uma mesma ag de controle, que indicar qual
tarefa ser realizada durante a execuo do sistema.

CHAPTER 2.
36
Coeso coincidente ::
INTRODUO A
DESIGN DE SOFTWARE
as tarefas esto agrupadas sem qual-
quer critrio.
Para alcanarmos bons designs, podemos ordenar os tipos de

coeso dos mais desejveis para os menos desejveis: funcional,
sequencial, comunicativa, temporal, procedural, lgica, e coincidente.
2.4.7 Separao de Decises de Execuo de

Algoritmos
Essa tcnica realiza a separao de preocupaes apresentando
uma abordagem simples:
ou um mdulo deve se preocupar
com as decises sensveis ao contexto do problema ou com a

execuo de algoritmos, mas no ambos. Em outras palavras,
alguns mdulos devem apenas executar algoritmos sem fazer
qualquer deciso sensvel ao domnio do problema. Essas decises devem ser deixadas para os mdulos especcos para realizao dessas decises e que tambm sero responsveis por
suprir parmetros para os mdulos de execuo de algoritmos.
Essa separao facilita o reuso e manuteno, principalmente
dos mdulos de algoritmos, uma vez que eles so menos especcos que os mdulos de decises sensveis a contexto.
2.4.8 Separao de Interfaces de suas Implementaes

A separao entre interfaces e implementaes tambm benecia a modularizao.
Essa tcnica recomenda a descrio
da funcionalidade a ser implementada por algum mdulo por

meio de contratos, chamados interfaces.
Assim, os mdulos
implementaro as interfaces de forma a comporem o sistema.

37
Usando essa tcnica, o acoplamento entre mdulos e seus

clientes diminudo, uma vez que os clientes estaro ligados
apenas a interfaces e no implementaes , e benefcios como
facilidade no reuso, melhor entendimento do cdigo, e menor
custo de manuteno so alcanados.
2.5 Resumo
Esse captulo exps o conhecimento necessrio sobre Design de
Software para o estudo de Arquitetura de Software. Espera-se
que, ao nal desse captulo, o leitor saiba:
o que design software, seja como produto ou como processo, e quais so suas caractersticas e benefcios;
como os problemas de design de software podem ser decompostos; e
o que so os princpios e tcnicas de design de software e

quais seus benefcios.
Pela existncia de timos livros sobre Design de Software j

escritos tendo em vista o mesmo pblico-alvo que ns (o leitor
ainda inexperiente), ns preferimos no nos aprofundar nos assuntos expostos nesse captulo, uma vez que nossa inteno foi
de apenas introduzi-los.
Para informaes mais detalhadas,
recomendamos os livros e artigos sobre Design de Software apresentados na seo de referncias.
2.6 Referncias
2.6.1 Teoria em Design de Software
Recomendamos o livro Software Design [23], de Budgen, aos
interessados em mais informaes sobre a teoria em design de
software. Dois artigos que apresentam discusses teis sobre
CHAPTER 2.
38
INTRODUO A
DESIGN DE SOFTWARE
o assunto so Software Design and Architecture The Once

and Future Focus of Software Engineering [105], de Taylor e
Van der Hoek, e Conceptual Foundations of Design Problem
Solving [97], de Smith e Browne.
Inclusive, este ltimo a
nossa referncia sobre o arcabouo conceitual de design usado

neste captulo.
2.6.2 Processo de Design

Em nvel mais prtico da execuo do processo de design, citamos as seguintes referncias: The Mythical Man-Month: Essays on Software Engineering [20], de Brooks, que discute as
causas da complexidade que assola o processo de design de
software; Software Design: Methods and Techniques[15], que
descreve as etapas que podemos encontrar no processo de design; e o Guide to the Software Engineering Body of Knowledge
(SWEBOK) [5], que apresenta os nveis de design.
2.6.3 Tcnicas e Ferramentas

Por m, citamos referncias que descrevem ferramentas e tcnicas que podemos usar durante o processo de design.
Sobre a linguagem de modelagem UML, mais informaes podem ser encontradas no site do Object Management Group
(OMG) [80].
J sobre tcnicas de design, citamos o livro de Booch et al,
Object-Oriented Analysis and Design with Applications[19], o
de McConnell, Code Complete[76] e o de Buschmann et al,
Pattern-Oriented Software Architecture, Volume 1: A System
of Patterns[26].
Este ltimo mais especco ao design ar-
quitetural.

39
2.7 Exerccios
Exerccio 2.1
Quais os benefcios de se projetar sistemas?
Exerccio 2.2
Duas fases importantes do projeto de software so as
fases de Divergncia e Convergncia. Descreva o que
feito em cada fase.
Exerccio 2.3
Jack Reeves, em What is Software Design? [87], arma
que o cdigo fonte design. Qual a sua opinio a respeito da armativa?
Exerccio 2.4
Qual padro de projeto viabiliza a separao de
poltica e implementao?
Exerccio 2.5
Dena para coeso e acoplamento e sugira mtricas
para medi-las em software.
Exerccio 2.6
Cite diculdades que podem ser encontradas durante
a aplicao de cada tcnica de design apresentada no
captulo.
Exerccio 2.7
Represente um design de software de duas maneiras
diferentes. Para isso, antes ser necessrio descrever o
problema que o software deve resolver.
Exerccio 2.8
Elabore uma soluo de design diferente para o problema descrito na resposta do anterior e descreva-a usando os mesmos tipos de representaes usados anteriormente.

40
CHAPTER 2.
INTRODUO A
DESIGN DE SOFTWARE

Chapter 3
Estudo de Caso: SASF
Como muitos dos problemas relacionados Arquitetura de

Software s fazem sentido em sistemas complexos, difcil ilustrar diversos aspectos dessa rea apenas com exemplos simples.
Assim, resolvemos adotar uma abordagem de ensino orientada
a estudo de caso. Essa abordagem consiste em fazer com que
o leitor acompanhe a construo da arquitetura de um sistema
e, dessa maneira, possa observar na prtica o uso do conhecimento encontrado no livro.
Ao longo deste livro, o leitor acompanhar um processo de design e documentao de uma arquitetura que possibilitar a
implementao de um sistema complexo. Assim, ser durante
esse processo que sero apresentados os conceitos e generalizaes essenciais para se formar um bom arquiteto de software.
Tambm faremos uso de outros exemplos capazes de expor aspectos complementares ao estudo de caso.
1 This
content
is
available

41
online
at
CHAPTER 3.
42
ESTUDO DE CASO:
SASF
3.1 Apresentao do estudo de caso
O sistema atravs do qual acompanharemos o processo de design e documentao de sua arquitetura ser o Sistema de
Aluguel e Streaming de Filmes (SASF). O SASF um sistema de informao com dois grandes objetivos: (1) gerenciar
o processo de locao via web de vdeos e (2) proporcionar
infraestrutura de software para realizar streaming de vdeos
tambm via web.
O SASF um sistema ctcio baseado no
Netix e na iTunes Store.

Esse sistema foi escolhido como estudo de caso por ter funcionalidades e atributos de qualidade no-triviais, alm de pertencer a um domnio de problema mais comum do que os encontrados na literatura. A no-trivialidade de suas funes e
de seus atributos de qualidade servir como alvo para mostrar
a necessidade e aplicao dos conhecimentos em Arquitetura de
Software. J em relao abordagem de um domnio de problema relativamente simples, essa foi um dos fatores-chave para
a escrita deste livro. Nos livros essenciais sobre Arquitetura de
Software, bastante comum acompanharmos estudos de caso
de projetos militares ou da indstria aeroespacial. Esses projetos so riqussimos em detalhes e se encaixam perfeitamente
necessidade de se estudar e aplicar os conhecimentos em Arquitetura de Software. Por outro lado, esses mesmos projetos,
apesar de bem prximos realidade dos autores dos livros em
questo, so distantes da realidade do leitor ainda inexperiente em Engenharia de Software.
Sendo assim, ao encontrar
estudos de caso ou exemplos num domnio de problema pouco

familiar, o leitor no se sente motivado e encontra diculdades
para concretizar os conceitos expostos ao longo dos livros.

43
3.2 Funcionalidades do SASF

Com a popularizao da Internet, muitas empresas perceberam
a oportunidade de, atravs dela, alcanar novos consumidores.
O SASF se alinha com essa idia.
um cliente alugue um lme
Seu papel permitir que
usando apenas um navegador,
sem estar presente sicamente numa loja. Dessa maneira, esse

sistema aumenta o nmero dos clientes em potencial da empresa, uma vez que eles deixam de ser apenas aqueles capazes
de chegar loja fsica para ser todos aqueles presentes na rea
de alcance da infraestrutura usada para entrega e coleta de
vdeos.
3.2.1 Locao e Streaming de vdeo

O principal usurio do SASF aquele interessado em alugar
vdeos. Esse usurio, aps se cadastrar no sistema, ser capaz
de ( Figura 3.1):
enleirar lmes que sero enviados para sua casa obedecendo poltica de sua assinatura,
assistir a um lme via streaming em algum dispositivo

ou aplicativo integrado e autorizado a comunicar com o
SASF.
2 Ao longo deste livro, apesar de usarmos a palavra lme, estamos nos

referindo a vdeos em geral, podendo ser tambm, seriados de TV, musicais, ou mesmo documentrios, alm de lmes. Assim, os termos lme e
vdeo so intercambiveis a no ser que sejamos explcitos quanto suas
diferenas.

CHAPTER 3.
44
ESTUDO DE CASO:
SASF
Figura
3.1:
Principais funcionalidades do SASF:
streaming de vdeo para diversos dispositivos e gerncia

do aluguel de lmes
As opes de assinatura disponveis a esse tipo de usurio

variam em relao ao nmero mximo de vdeos que ele pode
ter em sua casa ao mesmo tempo. Dessa maneira, dado que
o usurio enleirou inicialmente 10 vdeos para aluguel, se sua
assinatura permitir apenas um vdeo em sua casa por vez, o
segundo vdeo da la s ser enviado para sua casa quando o
primeiro for devolvido.
De maneira anloga, se a assinatura
for de trs vdeos por vez, inicialmente, os trs vdeos sero

enviados e, medida que eles forem devolvidos, a la ser esvaziada at que no sobre nenhum vdeo na la ou o usurio
esteja com trs vdeos em sua casa. Vale notar que a la pode
crescer indenidamente.

45
Os vdeos so entregues na casa do usurio pelos correios e ele

pode car com as mdias o tempo que quiser. No h qualquer
tipo de penalidade se o usurio car com elas por muito tempo.
O nico incentivo para que ele as devolva que ele no receber
mais vdeos de sua la at que alguma mdia seja devolvida.
Portanto, a devoluo tambm realizada pelos correios:
usurio envia as mdias para a empresa e, assim, possibilita

que mais vdeos lhe sejam enviados.
Uma outra opo assistir aos lmes atravs da Internet, via
streaming de vdeo usando algum aparelho ou aplicativo que
saiba conversar com o SASF. Assim, no preciso esperar pela
entrega da mdia pelos correios, nem esperar o tempo de download do vdeo para que se comece a assisti-lo, j que a idia
do streaming consumir o arquivo de mdia transmitido medida que ele recebido. Isto, ainda por cima, economiza tempo
do usurio, uma vez que ele pode assistir ao lme agora, e
diminui gastos com logstica por parte da empresa, uma vez
que no precisa usar os servios de uma transportadora para
realizar a entrega do lme, alm de economizar com compra e
manuteno de mdias.
Ao prover um servio de streaming para os usurios, surgem
novas preocupaes.
O streaming de vdeo realizado pelo
SASF pode ter vrios destinos: uma aplicao cliente executando no navegador do usurio ou como aplicativo stand-alone
disponibilizado para download no prprio site, decodicadores
de TV por assinatura, celulares 3G ou outros sistemas capazes
de receber dados e que sejam integrados ao SASF. Por existirem tipos diferentes de destinos, abrangendo de celulares a
computadores pessoais, a qualidade do vdeo transmitido deve
ser tambm varivel de acordo com as caractersticas de cada
destino. Assim, se o vdeo deve ser assistido num celular que
tem resoluo mxima de 240x320, no h a necessidade desse

CHAPTER 3.
46
ESTUDO DE CASO:
SASF
ser transmitido em 1080p
Um vdeo numa resoluo muito maior do que a capacidade

de exibio do aparelho gera dois problemas. O primeiro a
necessidade de redimensionar o vdeo para que caiba na tela,
processo que pode ser bastante custoso em termos de processamento. J o segundo o gasto desnecessrio de banda passante,
uma vez que, neste caso, um vdeo na resoluo suciente seria
menor, signicando menos bytes sendo transferidos. Por outro
lado, se o destino for um decodicador de TV por assinatura,
como a tela de aparelhos de televiso tem em geral uma resoluo maior que telas de celulares, espera-se que o vdeo transmitido seja em maior resoluo. Por isso, so disponibilizadas
e sugeridas diversas opes de streaming para o usurio, cada
uma se adequar melhor ao destino em questo.
3.2.2 Busca, feedback e sugestes ao usurio

O SASF capaz de disponibilizar centenas de milhares de ttulos de vdeos aos seus usurios. Em meio a um acervo deste
tamanho, surge a necessidade de facilitar a vida do usurio
para que esse encontre o que deseja. Assim, operaes de busca
por ttulo (original e traduzido), atores, diretores, gnero, ano
de lanamento ou palavras-chave so requisitos bsicos de um
sistema deste porte.
Alm da funcionalidade bsica de busca, o SASF sugere lmes
ao usurio de acordo com seu histrico de aluguis.
Esse
mecanismo de sugesto alimentado no s pelos lmes assistidos, mas tambm pela nota dada pelo usurio aps t-lo
assistido. Essa nota serve para renar o motor de sugesto e
fazer com que as sugestes automticas se tornem mais precisas
ao longo do tempo.
3 Tambm chamado de
full HD. Sua resoluo
de 1920x1080 pixels.

47
Outra forma de sugesto a manual, onde um usurio sugere

um ou mais lmes a um amigo. J que um membro pode receber sugestes de outros cadastrados, ele deixa de estar isolado
dentro do sistema para estar agrupado com amigos de fora do
SASF. Isto adiciona aspectos sociais ao sistema, alm de melhorar a preciso das sugestes, uma vez que amigos tero, em
potencial, mais informaes sobre o usurio que o motor de
sugesto. Isto tambm servir para estimular mais aluguis a
m da realizao de sesses de cinema junto aos amigos.
Para prover ainda mais informaes que ajudem na escolha de
um vdeo, o SASF tambm disponibiliza trailers e crticas sobre
os lmes. Os trailers so disponibilizados pelas distribuidoras
assim como sua sinopse, fotos de divulgao e documentrios
por trs das cmeras, todos disponveis para streaming ou
leitura independente da assinatura do usurio. J as crticas
podem ser feitas por qualquer um cadastrado no sistema.
3.2.3 Disponibilizao de lmes e administrao do sistema

Devemos nos lembrar que os usurios que alugam lmes no
so os nicos do sistema.
H outros dois tipos de usurios
essenciais para que o sistema tenha sucesso, so eles o Administrador e o Distribuidor de Filmes.
Observe o diagrama
apresentado na Figura Figura 3.2.

CHAPTER 3.
48
ESTUDO DE CASO:
SASF
Figura 3.2:
SASF
Diagrama de Casos de Uso simplicado do
O primeiro o usurio que representa uma empresa distribuidora de lmes.
A viso do sistema para esse tipo de
usurio diferente da viso do usurio comum.
A empresa
ganha dinheiro disponibilizando e incentivando o aluguel de

lmes.
Dessa maneira, como h o interesse em saber como
anda a popularidade de seus vdeos, o SASF prov para a empresa dados sobre aluguis ao longo de intervalos de tempo
customizveis.
Esses dados contm informaes sobre o per-
l de cada usurio que alugou o lme (por exemplo, idade

declarada ou sexo), mas no contm sua identidade, por motivos de respeito privacidade.
Esses dados serviro para a
distribuidora poder direcionar a divulgao de seus lmes ou

vericar se a campanha de publicidade foi efetiva. Para cada
lme disponibilizado pela distribuidora, possvel tambm adicionar sinopses, trailers, fotos de divulgao e documentrios
por trs das cmeras para tornar o lme mais atrativo. Toda
essa informao extra se torna disponvel a todos os usurios
do SASF.
J o segundo tipo de usurio essencial do SASF o administrador do sistema. Ele est interessado em manter o SASF
funcionando. Sua interao com o sistema consiste em obter
informaes de monitorao (por exemplo, quantos servidores
esto no ar, quantas requisies por segundo cada um est
recebendo no momento, o histrico de falhas de comunicao
49
entre servidores, etc.)
e, de acordo com estas informaes,
atuar sobre ele. As aes do administrador sobre o SASF englobam: iniciar novos servidores para atender uma demanda
crescente ou isol-los para manuteno, habilitar ou desabilitar
funcionalidades por excesso de carga ou ns de teste e habilitar
ou desabilitar contas de usurios mal-comportados.
3.3 Capacidades do SASF

O desao de desenvolver o SASF no est na implementao
de suas funcionalidades, uma vez que o desao de desenvolver
um sistema de locadora pequeno e que tambm j existem
vrios aplicativos que realizam streaming de vdeos. O desao
est no atendimento aos seus atributos de qualidade.
Dessa
maneira, para passarmos uma noo do tamanho do problema,

citaremos alguns nmeros presentes no SASF.
3.3.1 Nmeros de usurios e aspectos de segurana

O SASF desenvolvido para atender a 10 milhes de usurios
cadastrados, onde cerca de 20% desses usam o sistema a cada
dia.
Como h diversos tipos de usurios e cada um possui
informaes condenciais (por exemplo, o nmero de carto de

crdito usado para pagar a assinatura), cada usurio deve ser
autenticado para acess-las.
A autenticao servir tambm
para identicar o tipo de usurio e, assim, autoriz-lo a realizar

apenas o conjunto de funes permitidas sua categoria.
3.3.2 Tamanho do inventrio e nmero de operaes por dia

A principal funo do sistema executada pelo usurio que
aluga lmes, e consiste na colocao de lmes em sua respectiva
CHAPTER 3.
50
ESTUDO DE CASO:
SASF
la de aluguis.
O acervo do SASF estimado em cem mil
vdeos cadastrados, que esto disponveis em 55 milhes de

DVDs. Deste acervo, so realizados dois milhes de aluguis
por dia.
Isto signica dois milhes de execues por dia do
processo de aluguel: (1) relacionar o vdeo a ser enviado ao

especco usurio, (2) descobrir de qual ponto distribuidor ser
enviada a mdia a partir do endereo do usurio, (3) noticar
a responsabilidade de entrega da mdia ao ponto distribuidor
responsvel, e (4) realizar o envio pelos correios da mdia em
questo.
3.3.3 Transmisses simultneas

J o streaming de vdeos realizado numa taxa menor que o
aluguel, o que no representa uma baixa taxa de execues.
So cerca de 150 mil vdeos transmitidos por dia, ou seja, um
stream de vdeo sendo iniciado a cada 0.57 segundos caso a as
transmisses fossem distribudas uniformemente ao longo do
dia. Se considerarmos que a transmisso de um vdeo dura em
mdia uma hora, isso gera uma carga de pouco mais de seis mil
usurios simultneos fazendo streaming.
O acervo de vdeos
para stream menor que o de mdias convencionais, apenas 20

mil ttulos, mas cada ttulo est disponvel em alguns nveis de
resoluo e diversas taxas de amostragem. Os ttulos, inicialmente, esto disponveis em dois nveis de resoluo: Standard
Denition (SD) e High Denition (HD), ou 720x480 e 1280x720
pixels respectivamente para vdeos em widescreen (16:9).
importante notar que widescreen no o nico aspecto de

vdeo presente no sistema, uma vez que outros podem estar
presentes, como por exemplo, o aspecto Cinemascope (2.35:1).
Dessa maneira, o fator determinante para qualidade do vdeo
sua taxa de amostragem.
Inicialmente, o SASF prov trs
taxas de amostragem para vdeos em SD e duas para vdeos

em HD. Assim, o usurio receber o vdeo com aquela que mel-

51
hor se adequar sua conexo de internet. A Figura 3.3 mostra

uma tabela com o tamanho esperado para vdeos de duas horas
de durao em cada taxa de amostragem disponvel. A partir
dessa tabela, podemos tambm ter uma noo do espao gasto
no armazenamento de mdias.
Figura 3.3:
Tamanhos e amostragens disponveis
3.3.4 Adio de informaes sobre os vdeos

Os usurios do SASF tambm podem avaliar e escrever crticas
sobre os vdeos que j assistiram. Essa avaliao feita atravs
de uma nota dada ao lme.
O SASF possui cerca de dois
bilhes de notas j registradas, que podem ou no vir acompanhadas de uma crtica escrita sobre o lme. Essas crticas,
inicialmente, no possuem limites de tamanho. Vale tambm
observar que apenas cerca de 5% da notas so acompanhadas
de crticas escritas, mas que totalizam cerca de 100 milhes de
textos sobre lmes do acervo do SASF.
Note que avaliao e crticas no so as nicas informaes
relacionadas a cada vdeo do acervo. Cada vdeo possui ainda
fotos de divulgao, trailers, sinopse, lista de usurios que j
alugaram e lista de usurios com o lme na la de locao.

52
CHAPTER 3.
ESTUDO DE CASO:
SASF
Essas informaes devem sempre estar disponveis ao usurio

para ajud-lo na deciso de alugar um lme.
3.3.5 Tempos de resposta

Por m, observamos que o SASF disponibiliza um grande volume de informao, seja para o usurio comum, atravs do
streaming, da busca ou do aluguel de lmes, seja para o administrador, atravs da monitorao e ao sobre o estado do
sistema. Esse volume de informao aumenta naturalmente o
tempo de resposta dessas operaes. Por outro lado, tempos
de resposta acima do especicado ou acima da expectativa do
usurio contribuem para o fracasso de um sistema. Assim, as
diversas operaes providas pelo SASF devem ser realizadas
na velocidade da satisfao de cada usurio em questo.
No SASF, diferentes classes de usurios tm diferentes operaes sua disposio. Alm disso, essas operaes so bastante diferentes entre classes de usurios.
Por exemplo, um
administrador pode obter a velocidade mdia da realizao da

operao de aluguel executada por dado conjunto de servidores
ao longo da ltima semana, enquanto um usurio quer apenas
ver as cinco ltimas crticas a determinado lme.
Por isso,
todas as operaes disponveis no tero o mesmo tempo de

resposta, mas tempos diferentes de acordo com o volume de
dados que opera, sua criticidade, e o stakeholder envolvido.
Isto ser observado ao longo do livro, alm de estar descrito
de forma mais estruturada no Apndice XXX, que apresenta
fragmentos do documento de requisitos do SASF.
4 Ainda falta escrever o apndice, mostrando requisitos funcionais nofuncionais numerados, para tracking, e com valores quanticveis.

53
3.4 Resumo
Como podemos observar atravs de suas capacidades, o SASF
se mostra um estudo de caso signicativo devido sua relativa
complexidade de seus requisitos.
Esses requisitos dicultam
ou mesmo impossibilitam seu desenvolvimento se no houver

um mnimo de planejamento para atend-los ou ainda caso
no seja adotada uma abordagem, digamos, arquitetural para
atend-los.
Nos prximos captulos estudaremos os aspectos fundamentais
para que possamos desenvolver um sistema como o SASF e,
passo a passo, mostraremos como esses aspectos se aplicam ao
estudo de caso em questo.

54
CHAPTER 3.
ESTUDO DE CASO:
SASF

Chapter 4
Fundamentos de
No captulo introdutrio, mencionamos que o Design de Software pode ser dividido em duas atividades: design de alto-nvel
ou arquitetural e design detalhado e que ambas as atividades
tm um papel importante no ciclo de desenvolvimento do software.
Como no objeto de estudo deste livro Arquitetura
de Software, voltamo-nos agora para a primeira atividade em

questo.
Este captulo tem como objetivo expor o leitor aos fundamentos
de Arquitetura de Software ou, em outras palavras, fazer com
que seja capaz de:
Reconhecer, entender, e comparar as diferentes denies

existentes do termo arquitetura de software
Relacionar as diferentes denies de arquitetura de software com o padro ISO/IEEE 1471
Identicar as caractersticas e benefcios proporcionados

por uma boa arquitetura
1 This
content
is
available
55
online
at
CHAPTER 4.
56
FUNDAMENTOS DE
ARQUITETURA DE SOFTWARE
Avaliar os benefcios de explicitamente projetar a arquitetura durante o desenvolvimento do software
4.1 Motivao para desenvolver melhores sistemas

Desenvolver software no uma tarefa fcil. por esse motivo que muitos projetos de software fracassam durante seu desenvolvimento ou ao obter seus resultados. Entre esses maus
resultados, encontramos os que custaram muito acima do oramento, os incompletos e os que no solucionam os problemas
como deveriam resolver.
No fcil alcanar um bom produto de software devido
complexidade envolvida em seu processo de desenvolvimento.
Alm de lidar com a complexidade inerente ao problema, devemos tambm nos preocupar em como o software resolve esse
problema.
Assim, o software deve, alm de resolver o prob-
lema, resolv-lo da forma esperada.
Ou em outras palavras:
Espera-se que, alm de funo, o produto de software possua

os atributos de qualidade esperados.
Exemplo 4.1
Considere um programa que realize as quatro operaes: soma, subtrao, multiplicao e diviso. Se o
tempo de resposta de suas operaes for sempre maior
do que o tempo que seu usurio est disposto a esperar,
esse programa no ter utilidade mesmo que sempre retorne o resultado correto.
Podemos observar no Exemplo 4.1 que o programa funciona
corretamente, mas, por no exibir o desempenho esperado,
acaba sendo abandonado. Por outro lado, consertar esse programa para que seja til relativamente fcil. Por exemplo,
57
se o programa no multiplica rpido o bastante, basta apenas

reimplementar a funo de multiplicao para que tenha um
melhor desempenho.
Exemplo 4.2
Considere agora o SASF, j apresentado no Captulo
XX. Considere tambm que ele se mostra incapaz de
responder em menos de dois segundos s operaes de
aluguel de lmes. Uma vez que os usurios no esto
dispostos a esperar esse tempo pela principal operao
do sistema, isso resultar numa m experincia de uso,
que ser motivo para que seus usurios deixem de uslo e tambm deixem de pagar pelo servio.
Acontece que diminuir o tempo de resposta de uma funcionalidade no SASF, dado o tamanho do sistema, pode no ser to
simples quanto diminuir o tempo de execuo de uma funo
matemtica. O alto tempo de resposta de um servio no SASF
pode ser funo de uma ou mais decises tomadas ao longo do
desenvolvimento que resultaram na sua estrutura e organizao interna. Essa estrutura e organizao o que chamamos
de arquitetura.
Como o atendimento aos atributos de quali-
dade do software se deve em grande parte sua arquitetura,

surge a necessidade de estud-la. E, por m, atravs do estudo das caractersticas e tcnicas de projeto de arquitetura
que poderemos projetar e desenvolver melhores produtos de
software.
4.2 O que Arquitetura de Software

Desde sua primeira meno em um relatrio tcnico da dcada
de 1970 intitulado Software Engineering Tecnhiques [28], diversos autores se propuseram a denir o termo arquitetura de
software. Por esse motivo, ao invs de criarmos nossa prpria
denio do termo, faremos uso de quatro denies exis-

CHAPTER 4.
58
FUNDAMENTOS DE
tentes a m de ressaltar suas diferentes caractersticas. As trs

primeiras que usaremos so as denies de facto do termo.
Elas foram formuladas por autores que se destacam na rea
desde sua introduo e so usadas atualmente pela grande
maioria dos professores, alunos e praticantes da rea. Por outro
lado, tambm mostraremos a denio de jure de arquitetura
de software. Ela parte do padro ISO/IEEE 1471-2000 [53]
e teve sua criao motivada justamente para fazer com que estudantes, professores e praticantes de arquitetura de software
concordem sobre o termo.
4.3 Denio de Arquitetura de Software por Perry e Wolf

Perry e Wolf introduziram sua denio para arquitetura de
software em seu artigo seminal Foundations for the Study of
Software Architecture [84]. A denio que eles propem consiste na Frmula (4.1) e na explicao de seus termos:
Frmula
Arquitetura = {Elementos, Organizao, Decises} (4.1)
De acordo com essa denio, a arquitetura de software um
conjunto de elementos arquiteturais que possuem alguma organizao. Os elementos e sua organizao so denidos por
decises tomadas para satisfazer objetivos e restries.
So
destacados trs tipos de elementos arquiteturais:
Elementos de processamento: :
Elementos de dados: :
Elementos de conexo: :
so elementos que usam
ou transformam informao;
so elementos que contm a infor-
mao a ser usada e transformada; e

so elementos que ligam elemen-
tos de qualquer tipo entre si.

59
J a organizao dita as relaes entre os elementos arquiteturais. Essas relaes possuem propriedades e restringem como
os elementos devem interagir de forma a satisfazer os objetivos
do sistema. Adicionalmente, essas relaes devem ser ponderadas de modo a indicar sua importncia no processo de seleo
de alternativas.
Exemplo 4.3
Um elemento de dados muito presente no SASF e em
sistemas de informao em geral o banco de dados.
Ele o responsvel por guardar e recuperar dados no
sistema.
No SASF, inicialmente, esto presentes trs tipos de
dados:
1. Informao textual: informaes cadastrais dos
usurios e informaes textuais sobre os lmes;
2. Imagens: imagens que compem a identidade visual do sistema, foto do usurio presente em seu
perl e imagens de divulgao dos lmes;
3. Vdeos:
lmes completos, trailers e documen-
trios por trs das cmeras disponveis para

streaming.
Por isso, consideramos um elemento de dados para
cada tipo. Assim, temos o banco de dados responsvel
por informaes textuais, o banco de dados responsvel
por imagens e o banco de dados responsvel por vdeos.
Essa separao de responsabilidades permite que a implementao de cada elemento de dados disponha de
servios diferenciados ou mesmo tire proveito da natureza de seus dados para atender a algum atributo de
qualidade (desempenho, escalabilidade, etc.).
Dessa
maneira, o elemento responsvel por texto pode ser

otimizado para busca por palavras-chave, enquanto o
CHAPTER 4.
60
FUNDAMENTOS DE
responsvel por vdeos pode ser otimizado para recuperar grandes massas de dados a cada requisio. Por
outro lado, tambm faz sentido dividir logicamente os
elementos de dados em: elemento de dados de usurios
e de dados de lmes.
Vale notar que essa diviso
ortogonal diviso em elementos de texto, imagens e

vdeos e, portanto, o elemento de dados de usurios
pode ser composto por um elemento de dados textuais e outro elemento de dados de imagens, da mesma
maneira que o elemento de dados de lmes pode conter
o elemento de dados textuais, de imagens e de vdeos.
Como exemplo de elemento de processamento, citamos
a lgica de negcio do SASF. Ela contm as regras
de negcio que compem o SASF. Note que podemos
ainda dividir esse elemento de processamento em elementos mais especializados:
o elemento de processa-
mento responsvel por criar, editar, recuperar e remover usurios, o responsvel por criar, editar, recuperar e remover informaes de lmes, o responsvel
pelo aluguel de lmes e o responsvel por controlar a
sesso de streaming, entre outros. Essa diviso, assim
como a diviso dos elementos de dados, pode ser feita
em prol do atendimento aos atributos de qualidade
No entanto, um elemento no capaz de criar, editar,

recuperar ou remover usurios sem se comunicar com
os dados dos usurios. Da mesma maneira, o elemento
responsvel por manipular as informaes dos lmes
deve se comunicar com os elementos que guardam os
dados dos lmes. Ou ainda, para controlar a sesso de
streaming, o responsvel deve obter o lme do elemento
de dados que contm os lmes completos. Essa comu-
2 Trataremos melhor desse assunto no captulo sobre atributos de qualidade

61
nicao feita pelos diversos elementos de conexo do
SASF. Entre eles, podemos citar: o driver JDBC , que

permite a comunicao com o banco de dados responsvel pelos usurios; o protocolo FTP, para transferncia de vdeos; o protocolo HTTP, para transferncias a
partir do banco de imagens; ou o REST
, que uma
especializao do HTTP e usado para comunicao

entre elementos de processamento. A Figura 4.1 ilustra
alguns elementos que formam a arquitetura do SASF.
3 Java Database Connectivity. http://java.sun.com/javase/technologies/database/

4 REpresentational State Transfer [41]

CHAPTER 4.
62
FUNDAMENTOS DE
Alguns elementos de processamento, de dados e de conexo do SASF
Figura 4.1:

63
4.4 Arquitetura de Software por Garlan

e Shaw
Alm de terem uma viso mais concreta sobre arquitetura que
Perry e Wolf, Garlan e Shaw so mais explcitos quando mencionam o propsito de se aplicar conhecimentos de arquitetura
num sistema de software.
Para eles, arquitetura de software
se torna necessria quando o tamanho e a complexidade dos

sistemas de software crescem.
Assim, o problema de se con-
struir sistemas vai alm da escolha dos algoritmos e estruturas

de dados certos. Esse problema envolver tambm decises sobre as estruturas que formaro o sistema, a estrutura global
de controle ser usada, protocolos de comunicao, sincronizao e acesso a dados, atribuio de funcionalidade a elementos
do sistema, ou ainda sobre distribuio fsica dos elementos do
sistema.
Alm disso, o problema envolver decises que im-
pactaro no comportamento do sistema em termos de escala e

desempenho, entre outros atributos de qualidade [45].
A viso sobre arquitetura de software de Garlan e Shaw se
torna importante por conter trs aspectos. O primeiro por
eles serem explcitos em quando devemos aplicar conhecimentos de arquitetura de software quando lidamos com grandes
sistemas. O segundo por serem claros na separao de tarefas entre design detalhado e design arquitetural o primeiro
se preocupa com algoritmos e estruturas de dados, enquanto
o segundo se preocupa com os elementos e organizao do sistema como um todo, sendo em relao estrutura do sistema,
controle, comunicao, ou implantao. E, por m, por eles
citarem que o processo de design da arquitetura precisa se preocupar com atributos de qualidade do sistema alcanar escalabilidade ou desempenho, por exemplo.
Exemplo 4.4
A arquitetura de um sistema operacional, para atingir

CHAPTER 4.
64
FUNDAMENTOS DE
atributos de desempenho e portabilidade, deve se preocupar com diversos aspectos que comporo o sistema.
claro que alguns algoritmos sero tambm responsveis pelo desempenho do S.O. em questo, como o
responsvel pela ordenao por prioridade dos processos em execuo ou o de alocao de memria para um
novo processo; mas a organizao do sistema em camadas de abstrao (abstrao de hardware, sistema
de arquivos e drivers, gerncia de processos, API do
sistema, bibliotecas e aplicaes), a comunicao entre
elas (uma camada s pode se comunicar com a camada
seguinte, ou aplicaes e bibliotecas s podem se comunicar com a API do sistema, etc.) e a sincronizao
(um aplicativo sugere o arquivamento de dados, mas
o sistema de arquivo decidir quando isso ser feito)
tambm impactaro no seu desempenho.
Note que
essa organizao tambm tem impacto na portabilidade: quanto menos acoplado o resto das camadas for
da camada de abstrao de hardware, mais fcil ser
de realizar mudanas para que o sistema operacional
esteja disponvel para uma nova plataforma de hardware idealmente, s havendo que se reimplementar
essa camada.
4.5 Arquitetura de Software por Bass

et al
Como veremos a seguir, a denio de Bass et al bastante similar encontrada no padro ISO/IEEE 1471-2000. No entanto,
sua especicidade sobre quais propriedades dos elementos arquiteturais devem ser consideradas a faz ser mencionada:

65
A arquitetura de um programa ou de sistemas computacionais a estrutura ou estruturas do sistema,

a qual composta de elementos de software, as propriedades externamente visveis desses elementos, e
os relacionamentos entre eles. [13]
Como j observado por Gorton [47], essa denio explcita

quanto ao papel da abstrao na arquitetura (quando fala de
propriedades externamente visveis), e tambm quanto ao papel das mltiplas vises arquiteturais (estruturas do sistema).
Devemos tambm mencionar o uso do termo elementos de
software como as peas fundamentais da arquitetura.
Na
edio anterior dessa denio [10], seus autores usavam componentes de software ao invs de elementos de software. Essa
mudana foi feita para deixar a denio mais geral, principalmente pelo termo componente de software ter um sentido
especco na rea de Engenharia de Software baseada em Componentes.
Exemplo 4.5
Podemos observar a arquitetura do SASF atravs de
uma viso de partes funcionais ( Figura 4.2):
1. mdulo responsvel pelo cadastro de usurios,
2. mdulo responsvel pelo cadastro de lmes,
3. mdulo responsvel pelo aluguel de lmes,
4. mdulo responsvel pela transmisso de lmes,
5. mdulo responsvel pela sugesto de lmes, etc.
Esses mdulos proveem servios e informaes a outras partes do sistema: por exemplo, uma operao de
aluguel ou de transmisso de lmes deve atualizar o
histrico presente na conta do usurio.
Isso ocorre
porque o mdulo de sugesto usar periodicamente esse

histrico a m de gerar listas de lmes de acordo com
as preferncias do usurio.
CHAPTER 4.
66
FUNDAMENTOS DE
Figura 4.2:
Mdulos funcionais do SASF
Mas essa no a nica maneira de observarmos o sistema. Podemos tambm ver o sistema como um conjunto de processos executando e se comunicando em
mquinas diferentes, como observado na Figura 4.3. O
navegador do usurio, que pode ser considerado parte
do sistema e que est executando em uma mquina, se
comunica usando o protocolo HTTPS com um servidor
de aplicaes, que est executando em outra mquina
e que contm parte da lgica do negcio (e os mdulos de cadastro, autenticao, e atualizao do usurio,
entre outros).
O servidor de aplicaes, por sua vez,
se comunica de forma diferente com cada um dos sistemas de armazenamento presentes.
Ele usa JDBC
para obter dados de usurios, FTP para obter vdeos e

HTTP para obter imagens. J o motor de sugesto
visto como outro processo executando numa mquina
diferente do servidor de aplicao.
Esse processo, de
tempos em tempos, l, processa e atualiza informaes

do banco de usurios a m de gerar a lista de lmes
sugeridos. Ele tambm usa JDBC para se comunicar
com o banco de usurios.
67
Figura 4.3:
Processos presentes no SASF
Na viso em que dividimos o sistema em partes funcionais, podemos perceber aspectos do software como a
composio entre elementos ou pontos de reuso. J na
viso em que dividimos o sistema em processos, podemos observar outros aspectos, como propriedades de
comunicao e de interao entre as partes do sistema.
Por exemplo, na primeira viso, os cadastros de lmes
e de usurios podem compor um mdulo maior responsvel por todos os cadastros.
J na segunda viso,
percebemos que a comunicao entre o navegador e o

servidor de aplicaes sncrona, enquanto a comunicao entre o motor de sugesto e o banco de dados
assncrona em relao s aes dos usurios.

CHAPTER 4.
68
FUNDAMENTOS DE
4.6 Arquitetura de Software pelo

Padro ISO/IEEE 1471-2000
O propsito da criao do padro ISO/IEEE 1471-2000 [53]
foi o de ajudar no consenso entre autores, estudantes e prossionais sobre o que e para que serve arquitetura de software.
Assim, esse padro no s dene arquitetura de software, mas
tambm introduz um arcabouo conceitual para descrio arquitetural.
Sua denio de arquitetura de software, a qual
ns adotaremos ao longo do livro, a seguinte:
Denio 4.1: arquitetura de software

Arquitetura a organizao fundamental de um sistema incorporada em seus componentes, seus relacionamentos com o ambiente, e os princpios que conduzem seu design e evoluo.
Podemos perceber que a denio acima consistente com as
anteriores por tambm mencionar que arquitetura compreende
estrutura (ou elementos ou componentes), relaes, e decises
(ou princpios). No entanto, ela vai alm adicionando mais uma
preocupao arquitetura: conduzir a evoluo do software.
Evoluo de software o fenmeno de mudana que ocorre no
software ao longo dos anos e das mltiplas verses, desde seu
incio at o completo abandono do sistema. Essa mudana no
est s relacionada com a adio e remoo de funcionalidades,
mas tambm est relacionada com a manuteno do cdigo ao
longo do ciclo de vida do software. Essa manuteno pode melhorar ou deteriorar tanto atributos externos de qualidade do
software, os quais so percebidos pelos usurios (e.g., desempenho, tolerncia a falhas, disponibilidade), quanto atributos
internos de qualidade do software, os quais so percebidos pelos envolvidos no desenvolvimento (e.g., testabilidade, legibilidade, reusabilidade).

69
Uma vez que um dos principais objetivos de se projetar uma

arquitetura o de atingir a qualidade desejada pelos interessados no sistema, se torna claro o papel da arquitetura em conduzir a evoluo do software, uma vez que ela conter decises
que contribuiro para a preservao da qualidade 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 componente de software. Em Engenharia de Software,
componentes tm vrios signicados divergentes. Um signicado, de acordo com o Standard Computer Dictionary [1],
que um componente uma das partes que compem o sistema.
Dessa maneira, componente pode ser substitudo por mdulo, unidade, ou mesmo elemento de software. esse o
signicado de componente usado no padro ISO/IEEE 14712000 e que ser usado ao longo deste livro.
Por outro lado, um componente tambm pode ter o signicado como o descrito por Kai Qian, em Component-Oriented
Programming [8]: um pedao de cdigo autocontido e autoimplantvel com uma funcionalidade bem denida e que pode ser
agregado com outros componentes atravs de sua interface.
Esse outro signicado estritamente ligado Engenharia de
Software baseada em Componentes e no ser usado a no ser
que sejamos explcitos sobre ele.
O padro ISO/IEEE 1471-2000 tambm dene outros termos
fundamentais para o entendimento de arquitetura de software,
em especial vises (views).
Esse termo ser brevemente de-
scrito na Seo "Vises da Arquitetura" (Section 4.8: Vises

da Arquitetura) e ento detalhado no Captulo XX.

CHAPTER 4.
70
FUNDAMENTOS DE
4.7 Decompondo a denio de Arquitetura de Software
A arquitetura de software mais bem entendida atravs de

suas partes. Considerando as denies expostas acima, podemos ressaltar seus dois principais aspectos, que sero os meios
para alcanar os atributos de qualidade: elementos e decises
arquiteturais. Detalharemos cada aspecto a seguir.
4.7.1 Elementos arquiteturais

A arquitetura de um sistema deve denir os elementos que
formaro o software. Tais elementos denem como o software
particionado em pedaos menores e, assim, denem como o
software entendido.
Elementos arquiteturais so divididos
em dois tipos: elementos estticos e elementos dinmicos.

Os elementos estticos de um sistema de software denem as
partes do sistema e qual sua organizao. Esse tipo de elemento
reete o sistema durante o design e constitudo de elementos de software (e.g., mdulos, classes, pacotes, procedimentos,
ou ainda servios autocontidos), elementos de dados (e.g., entidades 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 estticos no consistem apenas das partes estticas do sistema, mas tambm como eles se relacionam entre si.
Associaes, composies, e outros tipos de relaes entre elementos de software, de dados, e de hardware formam o aspecto
esttico que compe a arquitetura do sistema.
O exemplo a
seguir ilustra elementos estticos de um sistema de software.
Exemplo 4.6
Voltando ao SASF, observar sua arquitetura sob uma
71
tica esttica expe seus elementos estticos.
Em
tempo de design, alguns elementos estticos so cada

pacote, mdulo ou conjunto de classes responsveis por
cada funo do sistema. Alguns desses elementos so
os responsveis por: criao, edio, remoo e recuperao de usurios e lmes, aluguel de lmes, autenticao e autorizao dos usurios, entre outros.
Por outro lado, elementos dinmicos denem o comportamento
do sistema. Esse tipo de elemento reete o sistema durante a
execuo e nele esto includos processos, mdulos, protocolos,
ou classes que realizam comportamento. Elementos dinmicos
tambm descrevem como o sistema reage a estmulos internos
e externos, como mostrado no exemplo a seguir.
Exemplo 4.7
Ainda na arquitetura do SASF, podemos tambm observar o sistema sob uma tica dinmica. Essa exibe
seus elementos dinmicos, a exemplo dos diversos processos executando nas diversas mquinas que compem
o sistema. Esses processos pertencem aos servidores de
aplicao, aos servios de armazenamento, ou mesmo
aos navegadores dos usurios.
4.7.1.1 Elementos Arquiteturais e Atributos do Sistema

Note que quando examinamos os elementos arquiteturais de
um sistema, tanto os estticos quanto os dinmicos, devemos
tambm prestar ateno nas relaes que os ligam. Essas relaes so importantes, pois especicam a comunicao e o
controle da informao e do comportamento que formam o sistema. Assim, as relaes denem diversos aspectos do sistema,
por exemplo, quais dados do objeto da classe A so visveis
pelos objetos da classe B; ou quantas leituras concorrentes so

CHAPTER 4.
72
FUNDAMENTOS DE
feitas no elemento C; ou ainda como o elemento D autorizado

a escrever dados no elemento E. Dessa maneira, essas relaes
tm efeito sobre atributos de qualidade do sistema, sejam os
percebidos pelos usurios, ou os percebidos pelos desenvolvedores. Os exemplos seguintes mostram casos de como relaes
entre elementos arquiteturais afetam atributos de qualidade.
Exemplo 4.8
Se dividirmos a arquitetura do SASF em trs camadas (apresentao, lgica de negcio, e persistncia),
a camada de persistncia pode ser um recurso compartilhado por diversas instncias da lgica de negcio. Se temos diversas instncias da lgica de negcio,
mesmo que algumas saiam do ar, as restantes provero
disponibilidade ao sistema, desde que a camada de persistncia (e.g., o banco de dados) no falhe.
Alm
disso, o compartilhamento do banco de dados pode signicar tambm o acesso concorrente ao mesmo. Assim,
quando uma instncia da lgica de negcio lhe faz uma
requisio, essa requisio lhe ser respondida mesmo
que outras instncias estejam fazendo o mesmo (obviamente, isso s ocorre se alguma instncia da lgica
de negcio no esteja realizando alguma requisio que
precise de acesso exclusivo aos dados).
Exemplo 4.9
A separao do sistema em trs camadas ( Figura 4.4)
pode tambm facilitar a manuteno. Se, alm de adotar essa diviso, a camada de apresentao apenas se
comunicar com a lgica de negcio, mas no com a de
persistncia, mudanas na camada de persistncia afetaro apenas a camada de negcio. Portanto, caso seja
necessrio mudar o fornecedor da camada de persistncia, a assinatura dos mtodos disponveis, ou mesmo o
protocolo de comunicao, apenas a lgica de negcio
ser afetada por essas mudanas, uma vez que no exAvailable for free at Connexions
73
iste acoplamento entre a apresentao e a persistncia.
Ilustrao da diviso de uma arquitetura

em trs camadas.
Figura 4.4:
4.7.2 Decises arquiteturais

Uma arquitetura no deve ter suas estruturas denidas aleatoriamente, uma vez que so elas que permitem o sucesso relativo aos objetivos do sistema. Dessa maneira, trabalho do
arquiteto denir essas estruturas em meio s alternativas de design arquitetural existentes. O arquiteto deve decidir entre as
alternativas, particionando o sistema em elementos e relaes
que possibilitaro o atendimento aos atributos de qualidade.
Essas decises so chamadas decises arquiteturais.

CHAPTER 4.
74
FUNDAMENTOS DE
Denio 4.2: deciso arquitetural

Uma escolha entre as alternativas de design arquitetural. Essa escolha se prope a alcanar um ou mais
atributos de qualidade do sistema, por meio da(s) estrutura(s) arquiteturais que ela envolve ou dene.
4.7.2.1 Caractersticas
As decises arquiteturais tm, basicamente, trs caractersticas
que devem ser consideradas: descrio, objetivos e fundamentao.
A primeira caracterstica bem clara. simplesmente a descrio do que foi decidido para o sistema, seja a descrio
um elemento, mdulo, classe, ou servio que existir da arquitetura, a descrio da comunicao de um elemento da arquitetura com outro, a descrio da agregao de diversos elementos diferentes da arquitetura para formar um servio, ou a
descrio de um princpio ou mais princpios que conduziro a
evoluo do sistema.
Exemplo 4.10
[Deciso Arquitetural 001] A arquitetura do SASF
dividida em trs camadas lgicas: apresentao, lgica
de negcio e persistncia de dados. A camada de apresentao se comunica apenas com a lgica de negcio e
apenas a lgica de negcio de comunica com a camada
de persistncia de dados.
Toda deciso feita com um ou vrios objetivos. Assim, a segunda caracterstica trata de explicitar qual o objetivo de dada
deciso, 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 decises arquiteturais.

75
Exemplo 4.11
(continuao da [Deciso Arquitetural 001]) Objetivo:
Essa diviso diminui o acoplamento entre os elementos
internos da arquitetura, facilitando o desenvolvimento
e a manuteno.
Por m, uma deciso arquitetural s pode ter sido alcanada

em meio a alternativas com algum embasamento ou fundamentao. Ento, cabe ao arquiteto explicitar por que tal deciso
foi tomada, seja por ser um padro conhecido na indstria,
seja por conhecimento prvio de como satisfazer os objetivos
em questo, ou pela atual deciso ter mostrado os melhores
resultados em meio a uma avaliao prvia das alternativas.
Exemplo 4.12
(continuao da [Deciso Arquitetural 001])
vao:
Moti-
Projetar os elementos internos do sistema de
modo que cada um pertena a apenas uma camada

lgica ajuda a aumentar a coeso e diminuir o acoplamento.
A coeso aumenta, pois cada elemento ser
desenvolvido com o objetivo de ser parte da apresentao, da lgica ou da persistncia do sistema. Dessa
maneira, cada elemento ter sua responsabilidade bem
denida, mesmo que em alto nvel.
Como a comuni-
cao entre as camadas pr-denida, a de seus elementos tambm : elementos da camada de apresentao no se comunicaro com elementos da camada
de persistncia, por exemplo.
Assim, o acoplamento
entre elementos internos ser anlogo ao acoplamento

entre camadas.
Com o baixo acoplamento, o desen-
volvimento e a manuteno dos elementos tambm

facilitado, seja por possibilitar o desenvolvimento independente, seja por mudanas em um elemento terem
5 TODO: Adicionar os
drivers
dessa deciso:
o Requisito(s) No-
Funcional(is) XX presente(s) no Apndice. Exemplo de requisito: [RNF

01] Ter mais de uma interface grca.

76
CHAPTER 4.
FUNDAMENTOS DE
menor impacto nos outros.
4.7.2.2 Rastreabilidade
Vale notar que decises denem que elementos comporo o sistema. No exemplo anterior, podemos observar que a deciso
dene elementos como plug-ins, pontos de extenso, etc. Assim, por relacionarem atributos de qualidade (ou requisitos) a
elementos arquiteturais, as decises contidas numa arquitetura
facilitam o chamado rastreamento de requisitos.
Denio 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
caracterstica importante porque facilita o entendimento e a
manuteno do sistema representado pela arquitetura. O entendimento do sistema facilitado porque uma arquitetura permite que um interessado qualquer navegue pelos elementos que
compem o sistema em dois sentidos: tanto do nvel mais abstrato do sistema para seus nveis mais concretos, ou seja, dos
requisitos para os elementos arquiteturais, como mdulos, bibliotecas, servios, ou classes; quanto dos nveis concretos da
arquitetura para os nveis mais abstratos, ou seja, dos elementos arquiteturais para os requisitos do sistema.
O entendimento do sistema facilitado porque uma arquitetura
permite que um interessado qualquer navegue pelos elementos
que compem o sistema em dois sentidos: tanto do nvel mais
abstrato do sistema para seus elementos mais concretos, ou
seja, dos requisitos para as estruturas arquiteturais, como mdulos, bibliotecas, servios, ou classes, quanto dos elementos
concretos da arquitetura para os nveis mais abstratos, ou seja,
das estruturas arquiteturais para os requisitos do sistema.

77
Exemplo 4.13
Se observarmos a arquitetura do SASF e procurarmos
pelas decises responsveis por facilitar a manuteno
do sistema, encontraremos entre elas a deciso do Exemplo 4.12.
Essa deciso sugere uma diviso do sis-
tema em camadas lgicas, mas tambm inuencia na

diviso em pacotes, servios ou mesmo processos. Assim, a satisfao do requisito de manutenibilidade est
diretamente ligada correta diviso das partes do sistema em apresentao, lgica de negcio e persistncia.
Da mesma maneira, se partirmos das partes que formam as camadas de apresentao, lgica de negcio
e persistncia, observaremos que elas esto ligadas
diviso do sistema (e deciso arquitetural) que se
prope a atender a requisitos de manutenibilidade.
Alm de permitir a navegao, um aspecto que merece ser
ressaltado que se os requisitos do sistema forem eventualmente ordenados por importncia para o sucesso do sistema,
os elementos arquiteturais tambm possuiro diferentes nveis
de importncia. Essa ordenao, ento, signicar diferentes
nveis de investimento, seja em tempo ou dinheiro, na construo dos elementos arquiteturais para o sucesso do sistema.
Adicionalmente, a manuteno do sistema facilitada de uma
forma anloga ao seu entendimento. Se algum requisito atendido insatisfatoriamente, por meio da arquitetura possvel
descobrir quais elementos do sistema esto envolvidos na insatisfao desses requisitos.
Da mesma maneira, a arquite-
tura possibilita descobrir quais requisitos sero afetados por

um dado elemento arquitetural caso esse sofra uma mudana
ou manuteno.
Exemplo 4.14
Se uma modicao na camada de apresentao s
CHAPTER 4.
78
FUNDAMENTOS DE
pode ser feita se a camada de persistncia tambm for
modicada, isso pode signicar que a deciso arquitetural do Exemplo 4.12 no est sendo seguida corretamente.
Portanto, o requisito de manutenibilidade
tambm no est sendo atendido corretamente e essa

divergncia da arquitetura deve ser corrigida o quanto
antes.
4.7.2.3 Evoluo
Devido s suas caractersticas, se torna fcil perceber que o
registro das decises arquiteturais na forma de um documento
o documento arquitetural agrega valor ao ciclo de vida do
software, uma vez que facilita o processo de rastreamento de
requisitos. Adicionalmente, se algum tipo de registro histrico
das decises arquiteturais existir, o processo de rastreamento
pode tambm ser realizado para as diversas verses do sistema,
facilitando assim o entendimento da evoluo do mesmo.
Alm de descreverem estruturas arquiteturais, as decises tambm descrevem princpios que conduziro a evoluo do sistema. Isso signica que uma deciso no necessariamente descrever mdulos, classes, ou servios, mas tambm poder
descrever regras que devero ser seguidas ao longo do desenvolvimento do sistema.
A seguir, citamos e exemplicamos
alguns tipos de regras a serem descritas pelas decises arquiteturais.
Regras para adio de funcionalidade ao sistema.
Exemplo 4.15
Uma nova funcionalidade do SASF no poder
adicionar uma carga maior que mil requisies
por segundo ao banco de dados de usurios, con-

79
siderando a mdia atual de dez mil usurios simultneos no sistema.
Exemplo 4.16
Uma nova funcionalidade de um editor de imagens s ser adicionada implementando o ponto
de extenso ProcessImagePlugin. Esse ponto de
extenso permite obter a imagem que est aberta
no workspace do usurio e seus atributos, alm
de permitir a exibio de uma caixa de dilogo
que permitir ao usurio entrar com parmetros
que serviro para a execuo do plug-in.
O re-
torno dessa nova funcionalidade sempre ser uma

imagem (processada ou no). A nova funcionalidade, para ser adicionada, deve conter um arquivo de congurao em texto sem formatao
que conter o atributo extension-class que indicar o caminho para a classe da nova funcionalidade que implementa ProcessImagePlugin.
Exemplo 4.17
Uma nova funcionalidade do sistema de edio
de texto no poder modicar a GUI de forma
que adicione mais do que um boto na rea de
trabalho em sua congurao padro.
Regras para remoo ou desativao de funcionalidades,

seja durante o desenvolvimento, implantao, ou execuo do sistema.
Exemplo 4.18
No SASF, a remoo de um servio do mdulo
responsvel pelo streaming para outros dispositivos ser feita em duas etapas.
Na primeira
etapa, o servio ser marcado como deprecated,

retornando assim, alm da resposta padro, uma

CHAPTER 4.
80
FUNDAMENTOS DE
ag avisando que na prxima verso ele ser
descontinuado.
Ser ainda disponibilizada uma
soluo que contorne a ausncia desse servio

(servios alternativos, por exemplo). Na segunda
etapa, que dever acontecer no mnimo 1 ms
depois da primeira etapa, o servio ser desativado, retornando uma mensagem padro de erro
avisando que o servio deixou de existir.
Exemplo 4.19
Caso o consumo de recursos computacionais do
SASF ultrapasse 80% do total, alguns de seus
servios podem ser completamente ou parcialmente desativados. Um servio que pode ser desativado temporariamente sem que os usurios
percebam o motor de sugesto de lmes. Como
cada usurio est acostumado a ter sua lista de
sugestes atualizada apenas de tempos em tempos, mas no tem certeza qual o real intervalo entre cada atualizao, se dada atualizao
demorar alguns minutos ou horas a mais para
acontecer, dicilmente o atraso ser notado. Em
casos extremos, devido ao seu grande consumo de
recursos, o servio de streaming de vdeo tambm pode ser desativado.
No entanto, essa de-
ciso deve tambm levar em conta o alto grau de

insatisfao de usurios que causar e que, fatalmente, poder ser convertida em perda de faturamento. Uma alternativa desativar a transmisso de vdeo para apenas algumas opes de resoluo. Assim, o grau de insatisfao ser menor,
uma vez que apenas uma parte dos usurios no
ser atendida pelo servio de streaming.
Regras para modicao ou manuteno de funcionaliAvailable for free at Connexions

81
dades.
Exemplo 4.20
No haver modicao do Web Service que realiza busca e aluguel de lmes no SASF que
disponibilizado para uso por servios externos.
Se for realmente necessria a modicao, dois
Web Services caro disponveis: o antigo, completamente suportado, e o novo, que passar a
ser adotado por novos sistemas a partir da data
de seu lanamento. O antigo s ser desativado
depois da adoo do novo servio ser feita por
todos os servios externos.
Regras de atendimento a atributos de qualidade.
Exemplo 4.21
No Exemplo 4.19, a disponibilidade de parte
das funcionalidades, i.e., construo da lista de
sugestes de lmes ou transmisso de vdeos,
mais importante do que a indisponibilidade de
todas as funes: caso o uso dos recursos computacionais alcance 100%, usurios comearo a
no ser atendidos de forma descontrolada.
As-
sim, prefere-se que uma menor parte dos usurios

no seja atendida, apenas os que desejam assistir
a lmes em alta denio, do que a maior parte,
que so os que desejam alugar lmes ou assisti-los
em denio padro.
Exemplo 4.22
A disponibilizao de uma nova funcionalidade
no SASF ser feita em etapas para 10%, 25%,
50%, 100% desses usurios. Dessa maneira, ser
possvel avaliar o comportamento da nova funo
no sistema sob carga real. Alm disso, a desati-

CHAPTER 4.
82
FUNDAMENTOS DE
vao da funcionalidade poder ser feita atravs
de uma ag de controle, permitindo o retorno s
funcionalidades anteriores do sistema em caso de
sobrecarga dos recursos por parte da nova funcionalidade.
Exemplo 4.23
Antes da implantao de uma nova verso de
um servio de infraestrutura, digamos, um novo
banco de dados, a carga gerada pelos usurios da
verso antiga ser espelhada para a nova verso.
Assim, ser possvel avaliar seu comportamento
com uma carga real e, portanto, saber o que esperar quando o novo banco de dados substituir a
verso em produo.
No Captulo XX, Documentao da Arquitetura, voltaremos
s decises arquiteturais, onde aprenderemos a categoriz-las
e document-las.
4.7.3 Atributos de qualidade

Uma das principais preocupaes da arquitetura o atendimento aos atributos de qualidade do sistema.
Atributos de
qualidade, como j introduzidos no captulo anterior, so a

maneira como o sistema executar suas funcionalidades. Esses
atributos so impostos pelos diversos interessados no sistema
e podem ser classicados em trs tipos: atributos do produto,
atributos organizacionais, e atributos externos.
Atributos de qualidade do produto so aqueles que ditam
como o sistema vai se comportar.
Exemplos clssicos desse
tipo de atributo de qualidade so escalabilidade, desempenho,

disponibilidade, nvel de entendimento ou mesmo portabilidade.
Podemos observar requisitos de escalabilidade no Ex-
emplo 4.24 e requisitos de portabilidade no Exemplo 4.25.

83
Exemplo 4.24
Sistemas de redes sociais costumam ter uma grande
massa de usurios. Como, a partir do lanamento de
um sistema desse tipo, sua massa de usurios cresce
bastante, desejvel que o crescimento do consumo
de recursos em relao ao crescimento do nmero de
usurios no seja muito acentuado de forma que a
escala seja vivel para a gerncia do sistema.
Para
atender esse requisito, a arquitetura deve ser muito

bem pensada em termos de consumo de recursos por
usurio, tirando proveito de diversas tcnicas como
caching, processamento assncrono, replicao, entre
outras.
Exemplo 4.25
Um requisito desejvel em um jogo de videogame que
ele esteja disponvel para diversas plataformas de entretenimento. Como diferentes plataformas tm diferentes especicaes ou ainda usam diferentes tipos de
hardware, atingir a portabilidade pode no ser trivial.
Entre as tcnicas de portabilidade, a mais us-
ada acaba sendo a abstrao dos aspectos especcos

plataforma principalmente o hardware, mais especicamente primitivas de desenho em tela ou armazenamento em disco da lgica do jogo.
Assim, toda ou
boa parte da camada lgica reusada, enquanto as camadas de nveis mais baixos de abstrao so portadas
para as diferentes plataformas.
J atributos de qualidade organizacionais, por outro lado, so
consequncia de polticas ou procedimentos organizacionais.
Em outras palavras, o sistema deve respeitar padres ou regras impostas por uma ou mais organizaes envolvidas para
atender a esses requisitos.

CHAPTER 4.
84
FUNDAMENTOS DE
Exemplo 4.26
Se um sistema que servir de infraestrutura ser produzido para uma organizao ou empresa que j possui
diversos sistemas que implementam o padro Web Service Distributed Management (Gerncia Distribuda de
Web Services), a adoo desse padro na arquitetura
do novo sistema um requisito a ser atendido, por ser
imposto pela organizao em questo. A adoo desse
padro implica na disponibilizao via Web Service de
servios de ativao, consulta e desativao do sistema
ou parte dele, que ter impacto na arquitetura do sistema como um todo.
Por m, restam os chamados atributos de qualidade externos,
que no so impostos pelo processo de desenvolvimento nem
pelo projeto do sistema. Neles se encaixam leis impostas sobre
software ou requisitos de interoperabilidade entre sistemas.
Exemplo 4.27
Para o SASF atrair usurios de outros sistemas (p.
ex., redes sociais), percebeu-se que ele deve ser capaz
de agregar o perl do usurio existente nos outros sistemas. Esse tipo de agregao (que permitiria no s a
visualizao dos pers compartilhados entre os diversos servios, mas tambm sua edio), impactar profundamente na arquitetura do sistema, uma vez que
ser necessrio organizar dados locais e dados compartilhados por terceiros, alm de manter todos os dados
sincronizados ao longo do tempo e das eventuais modicaes.
4.7.3.1 Medindo atributos de qualidade

importante notar que para se denir o sucesso do software em
relao aos atributos de qualidade, precisamos medir o quanto

85
o sistema satisfaz esses atributos. Em primeiro momento, essa

medio de sucesso parece simples: basta considerar o valor
esperado do atributo de qualidade, digamos, `o sistema deve
estar disponvel 99,999% do tempo'; medir se ele atinge os valores esperados, `num perodo de 1 ano, o sistema esteve parado
por 1 hora'; e, por m, atestar seu sucesso ou fracasso: `1 hora
equivale a 0,0114% e, portanto, o sistema no atendeu ao requisito de disponibilidade. '
No entanto, no fcil estabele-
cer mtricas quantitativas para atributos de qualidade como

testabilidade, usabilidade, ou manutenibilidade so bem mais
difceis de estabelecer mtricas quantitativas e, portanto, no
fcil atestar o sucesso em relao a esses atributos.
4.7.3.2 Relacionando atributos de qualidade

Alm de serem difceis de medir, atributos de qualidade se
relacionam entre si de forma que um pode permitir, ajudar ou
mesmo dicultar o atendimento de outros. Essas relaes entre
atributos acontecem mesmo que eles sejam de tipos diferentes.
No Exemplo 4.28, notamos que o atributo de qualidade desempenho est afetando os nveis de testabilidade e entendimento
do sistema.
Exemplo 4.28
Uma forma de aumentar o desempenho do sistema
diminuir os nveis de indireo usados na comunicao
entre dois elementos quaisquer no SASF. Um caso simples seria fazer com que algumas chamadas presentes
na camada de apresentao usassem diretamente a camada de persistncia, sem usar a lgica de negcio.
Essa medida tornaria as chamadas da apresentao
mais rpidas, uma vez que menos chamadas remotas
seriam executadas.
No entanto, quando diminumos
as camadas de abstrao entre dois elementos inicialmente distintos, aumentamos o acoplamento entre eles
CHAPTER 4.
86
FUNDAMENTOS DE
e, portanto, dicultamos seu entendimento ou mesmo
sua testabilidade.
J no exemplo a seguir, o atributo de segurana afeta dois

atributos distintos: o desempenho e a usabilidade do sistema.
Exemplo 4.29
Uma forma de aumentar a segurana de um sistema
operacional requerer autorizao do usurio para a
realizao de certas operaes. No entanto, o processo
de vericao do usurio (alm de todos os elementos e abstraes do sistema relacionados segurana:
unidade certicadora, unidade vericadora, listas de
controle de acesso, entre outros.) deteriorar o desempenho da aplicao, dado que consumir recursos que
poderiam ser destinados operao em si - no a um
aspecto dito no-funcional dela. Alm disso, o sistema
vai car menos usvel, uma vez que pedir uma vericao, seja senha, impresso digital, ou certicado,
para cada operao sensvel a ser executada.
O principal motivo que faz com que atributos de qualidade conitem por eles serem impostos por mais de um interessado no
software. Assim, como preocupaes de diferentes interessados
podem conitar, os atributos de qualidade tambm conitaro.
Assim, cabe arquitetura resolver, ponderar, ou ao menos mediar esses conitos, considerando assim os diversos trade-os
envolvidos para se alcanar os objetivos do software. O exemplo seguinte mostra atributos de desempenho e portabilidade
conitando.
Exemplo 4.30
Um cliente de um jogo para celular requisitou que o
jogo tivesse um bom desempenho nos diversos aparelhos disponveis no mercado.
No entanto, o gerente
de projeto sugere que o tempo gasto para portar o

software de um aparelho para outro seja mnimo, uma

87
vez que o prazo do projeto em questo curto. Podemos ento observar dois requisitos conitantes: desempenho e portabilidade.
Esse conito ocorre porque as tcnicas para alcanar
ambos os requisitos so divergentes.
Para alcanar
portabilidade, normalmente necessrio o uso de diversas camadas de abstrao, principalmente de hardware.

No entanto, a adio dessas camadas de abstrao signica uma perda em desempenho, uma vez que aumentar o nmero de chamadas necessrias para se realizar
qualquer operao.
E isso se torna ainda mais signi-
cativo no caso dos aparelhos celulares, que podem ser

limitados em termos de recursos computacionais como
processador ou memria.
Assim, a arquitetura do sistema ter que ponderar entre as tcnicas disponveis de modo que atenda em
parte cada requisito e, assim, ambos os interessados
quem satisfeitos.
Dois outros atributos de qualidade que normalmente conitam
so os atributos usabilidade e segurana, como veremos no exemplo a seguir. Nesse caso, ambos os atributos foram requisitados pelo mesmo interessado, o usurio, e, mesmo assim, se
tornaram conitantes.
Exemplo 4.31
Quando usando um sistema operacional, um mesmo
usurio procura atributos de segurana e usabilidade
para suas operaes.
Para segurana, ele deseja que
suas operaes no sistema ou seus resultados no sejam

afetados por aes de outros usurios. Esse atributo,
que na arquitetura implicar em solues de autenticao, vericao, listas de permisses, etc., impor
que as tarefas realizadas por qualquer usurio eventualmente tero sua autenticidade e permisso veriAvailable for free at Connexions
CHAPTER 4.
88
FUNDAMENTOS DE
cadas.
Essa interrupo para realizar as devidas au-
torizaes deteriora o atendimento do atributo de usabilidade, uma vez que o usurio ter suas atividades
interrompidas por algo que no gera resultado para ele.
Veremos mais sobre atributos de qualidade de software, suas
relaes, como alcan-los, e seus interessados no Captulo Y.
4.8 Vises da Arquitetura

Como consequncia da existncia dos diversos interessados nos
objetivos alcanados pelo software, a arquitetura tambm possuir diversos interessados.
No entanto, uma vez que os in-
teressados no sistema tm diferentes preocupaes e nveis de

conhecimento, a arquitetura no deve ser exposta da mesma
maneira para interessados diferentes. Para resolver esse problema, surge o conceito de vises arquiteturais.
Exemplo 4.32
Considerando a arquitetura do SASF, vejamos as preocupaes de dois interessados diferentes: o implementador e o responsvel pela disponibilidade do sistema
em produo. O implementador est preocupado com
mdulos, classes e algoritmos que ele e seu time tero
que construir, como e com quais subsistemas esses mdulos iro se comunicar ou ainda quais restries de comunicao foram impostas em seu design. J o responsvel pela disponibilidade est preocupado em como
o SASF est distribudo entre as mquinas, que funcionalidades sero afetadas caso um conjunto especco
de mquinas deixe de funcionar, ou como ser possvel
realizar a troca de um servidor sem afetar o tempo de
incio de uma transmisso de vdeo.
Podemos observar que h preocupaes bem diferentes entre
os dois interessados e assim perceber que dimenses bem difer-

89
entes da arquitetura so necessrias para satisfaz-los.
Para
o primeiro, a arquitetura deve mostrar que mdulos lgicos

(pacotes, classes, bibliotecas) compem o sistema, alm das
relaes de comunicao e restrio entre eles. J para o segundo, a arquitetura deve mostrar como o sistema est dividido
sicamente, quais partes do sistema esto executando em quais
computadores, quais os links fsicos entre esses computadores,
etc.
Uma viso arquitetural uma representao da informao
(ou parte dela) contida na arquitetura de forma que se adque
s necessidades de um ou mais interessados.
Ela facilita o
entendimento da arquitetura por parte do interessado, uma

vez que vai ltrar e formatar a informao de acordo com as
necessidades e preocupaes do interessado em questo.
Denio 4.4: viso arquitetural

a representao do sistema ou de parte dele da perspectiva de um conjunto de interesses relacionados.
No podemos esquecer que o prprio arquiteto tambm pode
tirar proveito desse conceito durante o processo de design da
arquitetura. Quando um arquiteto faz design, ele usa o conceito de vises arquiteturais para assim enderear as diferentes
preocupaes do sistema por vez.
Dessa maneira, ele divide
o problema de design em problemas menores e, consequentemente, menos complexos: ele enderea cada atributo de qualidade cada aspecto do sistema que sero alcanados por
essa arquitetura.
Atacando uma viso por vez, o arquiteto
pode, por exemplo:
primeiro denir as parties lgicas, ou
seja, os mdulos funcionais que comporo o sistema e assim

considerar uma viso lgica do sistema; denir as parties
dinmicas do sistema, ou seja, quais processos, threads e protocolos estaro presentes no sistema considerar uma viso de
dinmica; denir as parties do ponto de vista de implementao, ou seja, que classes, pacotes e bibliotecas comporo o

CHAPTER 4.
90
FUNDAMENTOS DE
sistema considerar uma viso de desenvolvimento; e, por m,

denir onde as partes dinmicas executaro, ou seja, onde e em
quais mquinas os diversos executveis do software estaro
implantados, alm de como eles vo se comunicar considerar
uma viso de implantao do sistema.
4.9 O Documento de Arquitetura

Considerando o que mencionamos at agora sobre arquitetura
de software, percebemos que ela prov diversos benefcios: proporciona atendimento de atributos de qualidade, ajuda na comunicao entre os interessados no sistema e guia a evoluo
do sistema. No entanto, at agora, s falamos da arquitetura
como algo abstrato. Ou seja, apenas falamos dela como uma
propriedade imposta ou emergente de um sistema, mas no
falamos em como document-la, nem fomos especcos quanto
aos benefcios proporcionados por sua documentao.
4.9.1 Benefcios
Um documento de arquitetura no nada mais que um documento que descreve a arquitetura do sistema e, portanto, descreve elementos, relaes, e decises arquiteturais do sistema
em questo. Assim, os benefcios de se documentar a arquitetura se tornam anlogos aos benefcios proporcionados pela
prpria arquitetura. No entanto, pelo documento de arquitetura ser um artefato concreto, ele poder ser reproduzido, reusado, comunicado e analisado contra o cdigo gerado a partir
da arquitetura em questo.
Em resumo, a documentao da arquitetura proporcionar os
seguintes benefcios:
Ajudar na introduo de novos membros ao time de desenvolvimento do sistema, uma vez que um documento
91
que abstrai o sistema a diferentes vises que representam

diferentes preocupaes;
Exemplo 4.33
Um novo desenvolvedor acabou de ser contratado e passou a integrar o time de desenvolvimento de um sistema que j soma 250 mil linhas
de cdigo.
Para esse desenvolvedor se familiar-
izar com o sistema, no uma boa idia para ele

mergulhar no cdigo de cabea, mas entender por
partes como as coisas funcionam. Esses diversos
nveis de abstrao at chegar ao cdigo propriamente dito devem estar disponveis na arquitetura do sistema, que se mostrar um bom ponto
de partida para o entendimento do sistema.
Servir de ponte para a comunicao entre os diversos

interessados do sistema.
Uma vez que a arquitetura
projetada para satisfazer diversos interessados, sua documentao tambm o ser. O documento de arquitetura
servir de arcabouo conceitual para comunicao entre
diferentes interessados no sistema, uma vez que dene
seus elementos e relaes que o compem.
Exemplo 4.34
Usando a arquitetura para mapear custos s
funcionalidades que o sistema prover, o gerente
pode justicar ao nanciador do projeto a necessidade de se adquirir uma licena para um banco
de dados especco. Ou ainda citar quais as consequncias caso essa licena no seja adquirida: a
funcionalidade provida pelo banco dever ser ento implementada pelo time de desenvolvimento,
que precisar de dois meses para tanto. Essa possibilidade de navegar pelo sistema e pelas diversas vises, seja a de gerente, seja a de nanciador,
CHAPTER 4.
92
FUNDAMENTOS DE
ou de desenvolvedor, facilitada pelo documento
de arquitetura.
Servir como modelo do sistema para a anlise.
Uma
vez que uma representao manipulvel do sistema, a

documentao poder ser analisada, desde que contenha
informao suciente para tanto.
Exemplo 4.35
A arquitetura do SASF, dividido em trs camadas (apresentao, lgica de negcio e persistncia), descreve que cada camada estar executando em mquinas diferentes.
certo que
a descrio de cada camada possui informaes

de quantas mquinas sero necessrias para determinada carga de usurios, como mquinas da
mesma camada se comunicaro e tambm como
elas se comunicaro com mquinas de diferentes
camadas. Assim, com essas informaes, possvel algum tipo de anlise e estimativa do custo
do sistema em produo (e.g., nmero de CPUs
por hora, banda passante entre as mquinas, ou
banda passante disponvel para os usurios), inclusive com base no crescimento do nmero de
usurios, mesmo que o sistema ainda no tenha
sido construdo.
Dicultar uma especicao imprecisa.
Quando o ar-
quiteto projeta a arquitetura, mas no a materializa em

um documento, pode haver pontos de discordncia que
eventualmente no sero avaliados por, simplesmente,
no estarem explcitos.
Exemplo 4.36
Num sistema de controle de vo, onde vidas
esto em risco, o documento da arquitetura
93
tambm um contrato.
Ele avaliado por cada
interessado em questo, que deve consentir com

a forma de como sero realizadas as funes do
sistema e como sero medidos seus atributos de
qualidade de forma a garantir o sucesso do sistema antes mesmo que esse seja construdo.
4.9.2 Diculdades
No entanto, documentar a arquitetura to ou mais difcil que
cri-la. Os principais motivos so trs: o documento reete a
complexidade da arquitetura, que geralmente alta; o documento reete o tamanho da arquitetura, que o torna custoso
para construir e ser lido; e o documento, por seu tamanho e
complexidade, difcil de manter consistente com o sistema
que ele descreve.
A complexidade do documento surge principalmente da necessidade de mostrar de diferentes maneiras os diferentes aspectos
da arquitetura, ou seja, da necessidade de mostrar as diferentes
vises da arquitetura. Cada viso possui uma forma de melhor ser representada e tambm deve estar consistente com as
outras vises.
Exemplo 4.37
Na documentao da arquitetura do SASF podemos observar,
entre outras,
duas vises diferentes:
uma viso que mostra aspectos dinmicos e outra que

mostra o sistema estaticamente.
A viso esttica mostra os principais mdulos funcionais do software e, na Figura 4.5, foi representada
por um diagrama de classes em Unied Modeling Language (UML) contendo os mdulos funcionais e sua
descrio.
Entre esses mdulos funcionais, podemos

CHAPTER 4.
94
FUNDAMENTOS DE
encontrar o responsvel pelo cadastro de usurios, o
responsvel pelo cadastro de lmes, o responsvel por
sugerir novos lmes a usurios, e o responsvel pelo
streaming de lmes.
Figura 4.5:
Uma viso esttica da arquitetura do SASF
J a viso dinmica da arquitetura se preocupa em

mostrar
os
mdulos
dinmico no sistema.
que
possuem
comportamento
Aqui, eles foram representados
por um diagrama de sequncia, tambm em UML, que

mostra seu comportamento e suas interaes com outros mdulos ( Figura 4.6).
Obviamente, os mdulos
usados nessa viso devem ter correspondentes na viso

esttica.

95
Uma viso dinmica da arquitetura do

SASF, mostrando o comportamento de alguns mdulos
durante o processo de transmisso de um lme.
Figura 4.6:
Documentos grandes levam tempo para serem construdos.

Alm disso, documentos grandes, na prtica, no so usados a
no ser que proporcionem para o desenvolvimento um benefcio
maior que o custo de l-lo. Essa realidade pode ser traduzida
em duas fases.
Na primeira, feito um grande esforo para
se construir o documento de arquitetura. Ainda nessa fase, o

documento completo e consistente com o sistema, alm de ter
o potencial para prover os benefcios de uma arquitetura bem
documentada. No entanto, a segunda fase consiste no processo
de desatualizao do contedo do documento, que ocorre por
falha no processo ou pelo alto custo de se manter o documento
consistente, e que tem por consequncia a inutilizao do documento de arquitetura e o possvel aumento da entropia no
sistema.
O problema da inconsistncia da arquitetura com o cdigo
acontece porque, em muitos processos de desenvolvimento, arquitetura evolui ao longo do tempo, seja uma evoluo planejada ou no. Uma evoluo no-planejada pode acontecer da
CHAPTER 4.
96
FUNDAMENTOS DE
forma descrita no exemplo a seguir.
Exemplo 4.38
Lembrando da arquitetura do SASF, que foi dividida em trs camadas: apresentao, lgica de negcio e persistncia, uma das decises impostas dita que
a camada de apresentao s pode se comunicar com
a lgica de negcio.
No entanto, um desenvolvedor,
medindo que a exibio da interface est demorando

porque o carregamento das imagens necessrias est
lento, resolve modicar a interface para que proceda
da seguinte maneira. O pedido das imagens feito diretamente camada de persistncia, contornando assim o overhead da camada lgica para tanto. Uma vez
que ele nota que o desempenho da exibio da interface
com o usurio agora est satisfatrio, ele adiciona essa
mudana ao cdigo.
Acontece que, com isso, ele adicionou uma mudana
tambm na arquitetura do sistema.
A partir da, h
comunicao entre o mdulo de interface e de persistncia, fazendo assim que a documentao da arquitetura
esteja inconsistente em relao ao cdigo do sistema.
4.10 Por que documentar a arquitetura

de software?
Como j foi mencionado no padro ISO/IEEE 1471-2000, a
arquitetura de um sistema existe independentemente dela ter
sido documentada ou planejada. No entanto, em pequenos sistemas, pensar, planejar, documentar e manter a arquitetura
pode no ser necessrio: um conjunto de classes e pacotes ou
de mdulos com suas relaes e evoluo minimamente pensados (ou uma Big Ball of Mud) pode atender aos requisitos

97
funcionais e os atributos de qualidade do sistema.
Normal-
mente, isso acontece quando os requisitos no so difceis de

serem atendidos. Assim, todos os interessados cam satisfeitos
que podem no ser muitos ou conitantes e o sistema atinge
o sucesso esperado.
Exemplo 4.39
Pensemos num pequeno sistema que servir para a
organizao de uma modesta locadora de lmes.
Ele
ser capaz de cadastrar, recuperar, atualizar e remover

lmes, cadastrar, recuperar, atualizar e remover DVDs
de lmes, cadastrar, recuperar, atualizar e remover
clientes, realizar locaes, devolues e reservas.
Se a execuo desse sistema estiver restrita apenas a
uma nica loja fsica, seus requisitos sero simples o
suciente para nem precisarmos de uma documentao
abrangente (ou mesmo precisar de qualquer documentao!): ele ser desktop, ter apenas um usurio atuando sobre o sistema, sua carga, por ter apenas um
usurio, ser baixssima, alm dos dados armazenados
no sistema, que por maior que seja a loja, no chegar
a limites intratveis por um sistema simples. Podemos
observar que um sistema com esses requisitos pode ser
desenvolvido e mantido at por um programador menos
experiente.
Em casos assim, realmente, os custos de planejar, documentar e manter a arquitetura seriam maiores que os benefcios
proporcionados por ela.
No entanto, quando os sistemas crescem, pensar em arquitetura nos atributos de qualidade e nas mltiplas vises e interessados envolvidos , e document-la se tornam necessrios.
Observaremos essa necessidade nos dois exemplos seguintes:
apesar de serem exemplos de sistemas funcionalmente semelhantes
ao
do
exemplo
anterior,
eles
tm
requisitos

no-
CHAPTER 4.
98
FUNDAMENTOS DE
funcionais que impem a necessidade de uma arquitetura bem

pensada e documentada.
Exemplo 4.40
O sistema de locadora agora tem que servir para mais
duas liais. Assim, o sistema deve estar rodando nas
trs lojas e deve existir um cadastro nico de novos
lmes, novos DVDs e novos clientes, e tanto a locao
quanto a devoluo podem ser feitas em qualquer loja
da rede de locadoras. O sistema se torna multiusurio,
por agora mais de um balconista us-lo ao mesmo
tempo, e distribudo, por ter que manter seu estado
consistente entre as diversas lojas fsicas existentes.
Surgem agora preocupaes de desempenho, tolerncia
a falhas e backup e consistncia de dados. Outras dvidas tambm surgem: Ser um banco de dados central
para as trs lojas? Ser um banco distribudo? Se for
central, o que fazer caso no seja possvel se comunicar
com ele? Se for distribudo, como manter a consistncia entre os dados? Um balconista de uma loja pode
acessar o sistema de outra loja? O que um balconista
de uma loja tem permisso para fazer na instncia do
sistema executando em outra loja?
A reserva de um
lme est restrita a uma loja fsica, ou ser vlida para

todas? E assim por diante.
Assim, podemos perceber que uma simples viso de
decomposio de classes deixa de ser o nico artefato
necessrio para entender o sistema. Precisamos agora
de um artefato que represente os estados do sistema
durante a execuo, seja em condies normais de operao (e.g., como funciona o procedimento de reserva
de lmes entre as lojas da rede de locadoras) , ou seja
quando surgem problemas (e.g., o link de comunicao
entre as lojas caiu), apenas para exemplicar algumas

99
poucas preocupaes.
Podemos notar que todas essas perguntas afetaro como o sistema estar organizado internamente, mas no afetaro suas
funcionalidades, que continuaro sendo as do exemplo anterior. Inferimos tambm que a arquitetura desse sistema e sua
documentao sero mais complexas que a do Exemplo 4.39.
No entanto, no caso do SASF, percebemos que a arquitetura
pode se complicar ainda mais, mesmo considerando quase as
mesmas funcionalidades.
Uma arquitetura ainda mais com-
plexa necessita de uma documentao ainda mais completa

para ajudar no desenvolvimento e manuteno desse sistema
de software.
Exemplo 4.41
A organizao interna do SASF mudar ainda mais
em relao aos Exemplo 4.39 e Exemplo 4.40. As decises que antes permitiam que o sistema rodasse para
as trs lojas numa mesma cidade no sero mais vlidas quando falamos de diversos pontos de distribuio
espalhados pelo pas.
Dessa maneira, observamos que as decises de desempenho, disponibilidade dos dados, e polticas de acesso
mudam e, como aumentam tambm em quantidade, se
torna mais evidente a necessidade do registro dessas
decises em algum tipo de documento para consulta,
resoluo de discusses e vericao de conformidade.
Adicionalmente, num sistema como o SASF, o nmero
de interessados aumenta:
entender
quais
tipos
de
desde o usurio que deve

locao
reserva
esto
disponveis, passando pelos responsveis pelo suporte

ao usurio, os responsveis pela disponibilidade dos diversos subsistemas (aluguel, streaming, dados, backup,
etc.), gerente de marketing, time de desenvolvimento,

100
CHAPTER 4.
FUNDAMENTOS DE
gerente de projeto, gerente da empresa. Aumentando
assim a responsabilidade de se obter um sistema capaz
de satisfazer a todos eles.
Cada um ter um conjunto diferente de preocupaes
sobre o sistema. Seja o responsvel por manter o sistema no ar, que precisa saber quantos recursos esto
sendo consumidos a cada momento; seja o time de
implementao, que precisa descobrir como adicionar
uma nova funcionalidade sem quebrar as anteriores;
seja o gerente do projeto, que deve decidir por contratar mais desenvolvedores para implementao ou
comprar solues prontas.
Cada um desses estar preocupado tambm com qualidades diferentes do sistema: o responsvel pela disponibilidade do sistema quer saber como o sistema escala
se a base de usurios duplicar; j o time de implementao est preocupado em deixar o sistema mais
testvel para que a implementao da nova funcionalidade seja mais fcil; e, por outro lado, o gerente quer
saber o desenvolvimento do sistema possvel com um
time de desenvolvedores menor que o atual.
Essas preocupaes sero endereadas pelo documento
de arquitetura do SASF, que contm diversas vises direcionadas s diversas preocupaes dos interessados.
Uma viso de implementao interessar ao responsvel pela disponibilidade, assim como uma viso de
decomposio interessar ao time de desenvolvimento,
assim como uma viso de implementao interessar
ao gerente do projeto, fazendo ento que o documento
de arquitetura possua diversas vises e se torne um
documento complexo.
O mais importante a se observar nesse exemplo (e no estudo

101
do SASF) que o design e a documentao da arquitetura no

so atividades fceis nem baratas. O arquiteto escolhido para
resolver esse problema deve (1) conhecer os interessados, (2)
conhecer os atributos de qualidade impostos ao sistema por
esses interessados, (3) conhecer as relaes e trade-os entre
interessados e atributos de qualidade, (4) conhecer tcnicas,
padres e ferramentas que permitam o atendimento aos atributos, e (5) documentar a soluo do problema, de forma que os
interessados entendam e tirem proveito do documento gerado.
4.11 Resumo
O objetivo deste livro fazer com que o leitor seja capaz de
enderear todos os aspectos da arquitetura citados anteriormente, podendo realizar algumas das diversas funes realizadas por um arquiteto de software.
Dessa maneira, o ob-
jetivo deste captulo foi dar uma viso geral do conhecimento

necessrio para tanto, fundamentando-o com alguns exemplos
e denies. Assim, esperamos que o leitor, a partir de agora:
entenda e exemplique os principais conceitos relacionados arquitetura de software; e
entenda e exemplique as principais caractersticas e

benefcios proporcionados pela arquitetura de software
no processo de desenvolvimento.
J no prximo captulo, conheceremos os principais interessados que devem ser contemplados pela arquitetura, alm de suas
caractersticas e relaes. No captulo seguinte, entenderemos
melhor os atributos de qualidade impostos por esses interessados, alm de apresentarmos algumas tcnicas para atender
esses atributos. Em seguida, teremos um captulo focado em
padres arquiteturais, uma vez que o uso de padres no design
da arquitetura uma tcnica essencial ao arquiteto. Por m,

CHAPTER 4.
102
FUNDAMENTOS DE
no ltimo captulo, aprenderemos a documentar a soluo que

atender aos interessados e atributos do sistema.
4.12 Referncias
4.12.1 Histrico da rea
Apesar da nfase em Arquitetura de Software como disciplina
ter acontecido apenas durante a dcada de 1990 com autores
a exemplo de Perry e Wolf [84] e Garlan e Shaw [46], podemos
encontrar trabalhos das dcadas de 1960 e 1970 que j citam
algumas tcnicas e benefcios da rea. Entre eles, encontramos
Dijkstra [36], Parnas [82] e outros. Mais informaes sobre o
histrico da disciplina podem ser vistas em The Past, Present,
and Future for Software Architecture, de Kruchten, Obbink e
Staord [60].
4.12.2 Evoluo de software

A evoluo de Software bem estudada no livro editado por
Mens e Demeyer, Software Evolution [2] e nos trabalhos de
Parnas [83], van Gurp e Bosch [107] e Eick et al [40].
Mais
informaes sobre a Big Ball of Mud podem ser encontradas

em Foote e Yoder [42].
4.12.3 Elementos de uma arquitetura

A diviso dos elementos arquiteturais em estticos e dinmicos
feita originalmente por Rozanski e Woods em Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives [88].
J a discusso sobre classi-
cao dos atributos de qualidade pode ser encontrada no livro

Software Engineering, de Sommerville [99].
Por m, pode-
mos citar algumas referncias importantes sobre vises arquite-

103
turais:
The 4+1 View Model of Architecture de Kruchten
[61], Documenting Software Architectures: Views and Beyond

Clements de Clements et al [30] e o padro ISO/IEEE 14712000 [53].

104
CHAPTER 4.
FUNDAMENTOS DE

Chapter 5
Stakeholders
O ciclo de vida do software composto por diversas responsabilidades atribudas a pessoas, grupos e entidades a quem
chamamos de stakeholders ou interessados.
Entre essas re-
sponsabilidades, podemos citar o nanciamento, o projeto, o

desenvolvimento, o teste, o uso e a manuteno do software.
A arquitetura, por sua vez, tem como objetivos tanto facilitar
o cumprimento das responsabilidades dos stakeholders, quanto
atender s suas necessidades. Entre as necessidades, citamos
a urgncia por desempenho, diversos aspectos de segurana
e usabilidade.
Por sua vez, o cumprimento desses objetivos
tem impacto direto nos atributos de qualidade exibidos pelo

software.
Logo, os stakeholders tm forte inuncia sobre a
arquitetura do software e tambm sobre os atributos de qualidade que este exibir ao longo de seu ciclo de vida e por isso
que dedicamos um captulo a eles.
Este captulo tem como objetivo fazer com que o leitor seja
capaz de:
Entender o conceito de stakeholders da arquitetura de
1 This
content
is
available
105
online
at
106
CHAPTER 5.
STAKEHOLDERS
um software
Identicar alguns stakeholders e sua inuncia em uma

arquitetura
Relacionar stakeholders com os atributos de qualidade

impostos a um software
Entender que stakeholders tambm se relacionam entre

si, podendo, inclusive, ser conitantes
5.1 Quem so os interessados em um

sistema de software?
comum termos como principais interessados no ciclo de vida
de um software os seus usurios e desenvolvedores. Acontece
que eles no so os nicos envolvidos ou, ao menos, so grupos homogneos em termos de interesses e necessidades. Entretanto, para termos um ponto de partida, vamos considerar
um cenrio em que existem apenas esses dois grupos e algumas simplicaes.
Nesse cenrio, eles ambos os grupos so
homogneos, ou seja, todos os usurios e desenvolvedores apresentam os mesmos interesses e necessidades, e os usurios se
encarregam de impor as necessidades, enquanto os desenvolvedores cuidam para que essas necessidades sejam alcanadas
atravs do produto de software. Para montarmos esse cenrio,
vamos partir de um sistema parecido com o nosso estudo de
caso e, pouco a pouco, retirar interesses e necessidades dos envolvidos para observar suas inuncias no software e em sua
arquitetura. Esse processo ilustrado atravs do Exemplo 5.1.
Exemplo 5.1
Vamos considerar uma simplicao do SASF que
chamaremos SSF (Sistema de Streaming de Filmes).
Ele mais simples porque realiza apenas uma das
duas principais funcionalidades do SASF: transmitir

107
de lmes.
Por sua semelhana, consideramos que ele
possui um conjunto de interessados parecido com o do

SASF. Entretanto, para compormos um cenrio sem
conitos, vamos comear descartando as distribuidoras de lmes desse conjunto.
Com isso, passamos a
responsabilidade de disponibilizar lmes aos usurios

que inicialmente usam o software apenas para assistilos.
Contudo, as distribuidoras no so consideradas
interessadas apenas por disponibilizarem lmes. Elas

tm tambm a preocupao com que o software respeite os direitos autorais desses lmes.
Para tanto,
o SASF e o SSF so obrigados a s permitir a transmisso de lmes a pessoas autorizadas e impedir a redistribuio de vdeos por parte dos usurios.
Essas
obrigaes tm efeito na arquitetura de ambos os produtos, que tem que prover no s meios de autenticar e
autorizar usurios, para distinguir usurios que assistem dos usurios que distribuem lmes, como tambm
prover meios de impedir ou dicultar a redistribuio
do contedo transmitido.
A autenticao e autorizao so feitas por um mdulo
responsvel pelo cadastro e autenticao de usurios e
criao de sesses de uso. Esse mdulo prov opes
para se cadastrar como distribuidor ou consumidor de
lmes.
Para o cadastro, o usurio deve prover in-
formaes para contato qualquer que seja seu papel.

Porm, enquanto a conta para um consumidor criada assim que o nmero de seu carto de crdito seja
vericado junto a operadora, o mesmo no acontece
para a conta do distribuidor. Para o cadastro de um
consumidor ser efetivado, necessria uma vericao
no-automtica de sua autenticidade. Essa vericao
iniciada a partir de uma noticao por e-mail, que
indica o distribuidor recm-cadastrado e que enviAvailable for free at Connexions
108
CHAPTER 5.
STAKEHOLDERS
ado s pessoas do departamento responsvel pela vericao de usurios.

A proteo contra redistribuio do contedo transmitido, por sua vez, feita por meio da Gesto de Direitos
Digitais (GDD)
. Por isso, a arquitetura no s dene
o servidor de stream, mas tambm o aplicativo cliente e

reprodutor de lmes que o nico capaz de decodicar
o vdeo.
Por outro lado, ao descartarmos as distribuidoras de
lmes de seu grupo de interessados, o SSF ca livre
das restries impostas por elas e passar a no necessitar de uma arquitetura que permita autenticao e
autorizao para distribuio de lmes, nem proteo
do contedo distribudo. Por isso, sua arquitetura pode
ser simplicada. Uma forma de simplicar no mais
usar a GDD. Dessa maneira, ca decidido que a transmisso ser feita usando qualquer formato de vdeo
amplamente adotado por reprodutores de mdia. Essa
deciso exclui at o que antes era a necessidade: implementar um reprodutor de lmes prprio, mas tambm
melhora a usabilidade, uma vez que agora o usurio
est livre para assistir a lmes com o reprodutor que
desejar.
A desconsiderao de apenas um grupo de interessados
causou mudanas profundas tanto nos atributos de segurana, quanto nos de usabilidade do sistema e, como
consequncia, causou mudanas tambm na arquitetura. Se continuarmos a simplicao de nosso cenrio
e desconsiderarmos o cliente do software, poderemos
ento descartar a necessidade de um baixo custo de
desenvolvimento e operao. Assim, para alcanarmos
2 Digital
Rights Management
(DRM)

109
desempenho esperado pelos consumidores de lmes, a

arquitetura do SSF poderia adotar uma tcnica simples, porm cara: para servir mais rpido, basta apenas
dispor de mais recursos computacionais, por exemplo,
processadores, HDs, memria e conexes maiores, mais
rpidos e em maior nmero. Com essa deciso de aumentar os recursos no se importando com o preo, o
SSF poder no s servir os usurios mais rpido, como
tambm servir a mais usurios.
Essa abordagem de
apenas melhorar o hardware para servir a uma maior

demanda o que no prximo captulo chamamos de escalabilidade vertical. A escalabilidade vertical costuma
ser bem cara e ter um limite menor de crescimento em
relao sua alternativa, que a escalabilidade horizontal.
Nesse segundo tipo de escalabilidade, a or-
ganizao do software e como ele se comunica realiza

um papel essencial para atender grande demanda de
usurios, mesmo quando executando em hardware de
menor capacidade. Em outras palavras, h um melhor
aproveitamento dos recursos disponveis, algo que s
pode ser alcanado por meio de uma arquitetura bem
pensada.
importante lembrar que dentro de um mesmo grupo de interessados podem existir interesses conitantes entre si.
A-
nal, um grupo pode se organizar em subgrupos de interesses

comuns, mas um subgrupo pode demonstrar interesses conitantes com outro subgrupo. Portanto, subgrupos diferentes de
usurios ou de desenvolvedores resultam em requisitos diferentes, que signicam atributos de qualidade diferentes e que
so frutos de arquiteturas diferentes.
Podemos observar isso
3 Desempenho um atributo comumente esperado pelos usurios, que

nunca querem esperar pelo servio.
J escalabilidade no um atrib-
uto requerido explicitamente por eles, mas se torna necessria quando o

nmero de usurios aumenta e no se aceita que o desempenho degrade.

110
CHAPTER 5.
STAKEHOLDERS
no estudo de caso (tambm citado no Exemplo 5.1), quando

o grupo de usurios se organiza em dois subgrupos: os que se
cadastram no sistema para alugar lmes e as distribuidoras de
lmes. O resultado dessa diviso e o conito podem tambm
ser observados no exemplo (e na Figura 5.1). Por um lado, as
distribuidoras impem seus requisitos de proteo aos direitos
autorais. Por outro, os usurios tm a forma de interao com o
sistema modicada, uma vez que devem usar um reprodutor de
lmes especco para que os requisitos das distribuidoras sejam
alcanados. Em resumo, mesmo fazendo parte de um mesmo
grupo de envolvidos, a inuncia de cada subgrupo no pode
ser desconsiderada, uma vez que ela pode ser grande o bastante para modicar, inclusive, a forma de outros subgrupos
interagirem com o sistema.
Figura 5.1: Stakeholders de um mesmo grupo, mas divergindo nos requisitos.

111
5.1.1 Importncia dos interessados

Podemos observar por meio do Exemplo 5.1 que a presena
ou ausncia de um interessado tem grande inuncia na arquitetura.
Alm disso, comum que sua ausncia d espao
para simplicaes nas decises arquiteturais.
Entretanto,
no mundo real, os envolvidos no se limitam a usurios e desenvolvedores. H diversos outros tipos de envolvidos que inuenciam o desenvolvimento do software de diversas maneiras
diferentes.
Esses envolvidos que inuenciam o ciclo de vida
do software tambm so chamados stakeholders.
Devido ao
conceito de stakeholder ser bastante amplo e transcender a

Engenharia de Software, preocupamo-nos apenas com aqueles
que impactam a arquitetura e, por isso, usamos a denio
dada por Rozanski e Woods:
Denio 5.1: stakeholder

Um stakeholder em uma arquitetura de software
uma pessoa, grupo ou entidade com um interesse ou
preocupaes sobre a realizao da arquitetura.
Alguns stakeholders tm diferentes responsabilidades durante

o ciclo de vida do software. Entre as responsabilidades, podemos citar nanciamento, projeto, desenvolvimento, teste, uso,
manuteno e at passagem de conhecimento sobre ele. Outros
stakeholders, por sua vez, esperam que o software funcione de
alguma forma especca: eles tm necessidades em relao ao
software. Por exemplo, comum para um usurio esperar que
o resultado alcanado pelo software seja convel ou que seja
alcanado em um tempo hbil. Quando estamos no espao do
problema, costumamos chamar essas responsabilidades e necessidades de requisitos do software. Por outro lado, quando esta-
4 Note que uma arquitetura mais simples no necessariamente signica

um produto com desenvolvimento mais barato ou execuo mais rpida.
5 N. Rozanski and E. Woods.
Software Systems Architecture: Working

With Stakeholders Using Viewpoints and Perspectives, Addison-Wesley
Professional 2005.
112
CHAPTER 5.
STAKEHOLDERS
mos no espao da soluo, costumamos cham-las de atributos

de qualidade.
Logo, os stakeholders tm forte inuncia so-
bre a arquitetura de um software porque ela uma ferramenta

essencial para proporcionar seus atributos de qualidade e atender aos requisitos, como, por exemplo: custo, reusabilidade,
testabilidade, manutenibilidade, legibilidade, desempenho, escalabilidade, segurana, conabilidade, entre outros.
5.2 Tipos de stakeholders e sua relao

com os atributos de qualidade
Entre os diversos tipos de stakeholders que inuenciam a arquitetura, podemos citar os usurios, os desenvolvedores, os
gerentes, os testadores, os clientes (que podem ou no ser
usurios), os designers de outros sistemas e os mantenedores,
alm dos analistas e o prprio arquiteto do sistema.
Con-
siderando que esse um conjunto heterogneo de papis,

natural que cada papel possua diferentes necessidades e responsabilidades que tm efeito sobre a arquitetura e que, eventualmente, resultem em conitos.
Resolver conitos de interesses entre stakeholders est entre as
obrigaes de um arquiteto de software. Ele deve ser consciente
de que muitas vezes no ser possvel agradar perfeitamente a
todos os interessados, uma vez que esses conitos podem impedir o projeto de uma soluo tima. Portanto, sua obrigao
ser a de produzir uma arquitetura boa o suciente e que faa
todos os stakeholders carem satisfeitos. Por isso, importante
que cada envolvido seja informado de como a soluo de seu
interesse foi restringida pelos interesses de outros envolvidos.
A seguir, podemos observar duas situaes de divergncias entre stakeholders que resultam em conitos entre os atributos
de qualidade.

113
Exemplo 5.2
As distribuidoras esperam que os direitos autorais de
seus lmes sejam protegidos, j os usurios querem
apenas assistir a seus lmes sem diculdades ou interrupes. A forma encontrada para proteger os direitos
autorais foi por meio da Gesto de Direitos Digitais.
Essa deciso implica em restringir o reprodutor de mdia que pode ser usado e obrigar o usurio a se autenticar no sistema para assistir a algum lme. Tanto
a restrio do reprodutor de mdia, quanto a autenticao do usurio dicultam a tarefa de assistir a um
lme, uma vez que o usurio pode no se lembrar de
seu login ou senha ou ele pode no estar acostumado
com o reprodutor de lmes permitido.
Por isso, essa
deciso de segurana tem impacto negativo na usabilidade.
Portanto, podemos observar aqui um conito
entre segurana e usabilidade.
Exemplo 5.3
Ainda no SASF e tambm pela deciso de proteger
os direitos autorais usando GDD, o arquivo contendo
o lme transmitido encriptado para o cliente. Essa
encriptao uma forma de dicultar a reproduo do
vdeo em programas no autorizados.
No entanto, o
reprodutor de vdeo autorizado deve pagar um preo

por isso:
para decodicar um arquivo com GDD,
necessrio mais processamento e, portanto, maior consumo de recursos. Isso ocasiona perda de desempenho,
o que pode ser crtico em dispositivos com menos recursos, como celulares. Por isso, a deciso de segurana
tambm tem impacto negativo no desempenho, caracterizando um conito entre esses dois atributos.
Note que para armarmos que uma arquitetura alcanou algum
sucesso, os stakeholders devem se mostrar satisfeitos com o
sistema desenvolvido a partir dela. Para tanto, espera-se que o
114
CHAPTER 5.
STAKEHOLDERS
arquiteto seja capaz de projetar uma arquitetura que alcance

dois principais objetivos: atendimento de requisitos e resoluo
de conitos.
5.2.1 Atendimento aos requisitos como medida

de sucesso
O primeiro objetivo, atender aos requisitos dos stakeholders,
acaba sendo bvio, pois para satisfazer os interessados, o sistema deve fazer o que eles esperam dele. Mas apesar de bvio,
enfatizar esse objetivo serve para o arquiteto iniciante perceber que seu objetivo principal projetar uma arquitetura com
atributos de qualidade capazes de atender aos requisitos do sistema impostos e esperados pelos stakeholders e no s por ele
prprio. No exemplo a seguir, mostramos um caso quando isso
no acontece.
Exemplo 5.4
Em alguns celulares e outros aparelhos que executam
software embarcado, espera-se que esse software tenha
um bom desempenho, principalmente considerando a
escassez de recursos do ambiente de execuo. Anal,
o usurio no quer pressionar uma tecla e esperar vrios
segundos pela resposta.
Por outro lado, no se es-
pera que o software seja extensvel, uma vez que alguns

desses aparelhos nem ao menos permitem atualizaes
de software.
Considerando que, nesse caso, desem-
penho e economia de recursos so requisitos mais crticos que extensibilidade, de nada adianta o arquiteto
do software para aparelhos que no permitem atualizaes projete uma arquitetura que torne o software
extensvel, com diversos nveis de abstrao, quando
esses nveis impactam negativamente no desempenho.
Pode parecer ingenuidade tomar decises em favor da extensibilidade quando se espera desempenho, como ilustrado no
115
Exemplo 5.4.
No entanto, esse erro muito comum e no
s cometido por arquitetos inexperientes.
Muitos arquitetos
no consideram o real impacto de suas decises e se deixam

levar por modas de padres, frameworks
ou abordagens que
prometem resolver todos seus problemas. s vezes, apenas

considerado que assim ser mais fcil vender a arquitetura ao
gerente do projeto.
Por m, poderamos ainda armar a partir do primeiro objetivo: no importa o quanto de acordo com as boas prticas
a arquitetura de um software est, se ela no atende aos requisitos que esperam que ela atenda. Ela, simplesmente, estaria
acertando o alvo errado.
Portanto, a medida de atendimento
aos requisitos do sistema a melhor medida de sucesso da arquitetura, desde que se conheam os requisitos.
5.2.2 Conitos entre requisitos e atributos de

qualidade
Situaes de conito surgem quando requisitos de stakeholders
divergem ou afetam atributos de qualidade comuns.
Pode-
mos observar que esse tipo de situao est presente, inclusive,

em alguns exemplos anteriores (Exemplo 5.2 e Exemplo 5.3).
Nesses exemplos so ilustrados conitos entre atributos de segurana e usabilidade e entre segurana e desempenho.
seguir, citamos outros atributos de qualidade e relacionamos

a alguns stakeholders que tm requisitos que comumente divergem durante o ciclo de vida do software.
6 comum que a adoo de um
framework
seja seguida de decises
arquiteturais impostas por ele e essas decises podem comprometer ou

conitar com os objetivos traados pelo arquiteto e esperados pelos stakeholders.
7 Mas claro que as boas prticas sero
ferramentas
problemas propostos pelos stakeholders.

para resolver os
116
CHAPTER 5.
STAKEHOLDERS
Exemplo 5.5: Desempenho versus custo

Usurios buscam por maior desempenho, enquanto
clientes e gerentes costumam preferir menor custo de
desenvolvimento.
Esses atributos divergem porque
comum que maior desempenho resulte em uma soluo

que necessite de mais recursos computacionais ou ainda
desenvolvedores mais qualicados na sua construo.
Exemplo 5.6: Desempenho versus escalabilidade

O cliente, que espera ganhar dinheiro a partir da popularizao do software, impe o requisito que ele seja
capaz de servir a demanda crescente de usurios. J os
usurios continuam buscando por desempenho do software, no se importando se h dez, mil ou um milho
de usurios usando-o ao mesmo tempo.
Uma forma
simples de servir a demanda crescente de usurios, ou

escalar, seria no se preocupar com o tempo de resposta
do servio para cada usurio e aument-lo drasticamente. No entanto, o aumento do tempo de resposta
um indcio de perda de desempenho, caracterizando o
conito.
Exemplo 5.7: Usabilidade versus segurana

Em um ltimo exemplo, citamos o conito entre usabilidade e segurana. Usurios esperam realizar suas
tarefas rapidamente, sem dvidas e sem erros causados
pela diculdade de usar, ou seja, esperam usabilidade
do software.
Por outro lado, auditores, clientes e os
prprios usurios esperam que suas informaes estejam a salvo, tanto para casos de ataques, quanto para
manipulao indevida.
Medidas de segurana devem
ser projetadas e o software deve prover meios de autenticao, autorizao, condencialidade e auditabilidade.
Ao tomar essas medidas, a usabilidade afe-
tada negativamente, uma vez que mais passos sero

117
necessrios para se realizar as mesmas aes. Por exemplo, para comear a usar o software, agora ser
necessrio inserir uma senha para que o usurio seja
autenticado. Portanto, a adoo de polticas de segurana costuma afetar negativamente a usabilidade do
sistema.
5.2.3 Responsabilidades dos stakeholders

Como j foi mencionado anteriormente, stakeholders tm responsabilidades durante o ciclo de vida do software. A seguir,
agrupamos as responsabilidades em quatro grandes tipos e citamos seu principais interessados:
Uso ou aquisio do sistema, que so responsabilidades

de usurios e clientes;
Desenvolvimento, descrio e documentao da arquitetura do sistema, que so responsabilidades do arquiteto

do sistema;
Desenvolvimento e manuteno do sistema, que so responsabilidades que envolvem o maior nmero de stakeholders:
arquitetos, projetistas, programadores, man-
tenedores, testadores, engenheiros de domnio, gerentes

de projetos e desenvolvedores, entre outros;
Avaliao do sistema e do seu desenvolvimento, que so

responsabilidades de CIOs
, auditores e avaliadores in-
dependentes.
Por m, descrevemos alguns dos stakeholders citados e qual
sua inuncia da arquitetura e em sua documentao.
Para
tanto, mencionamos quais so seus interesses comuns e o que

eles esperam da documentao da arquitetura.
8 Chief Information Ocer ou CIO o nome dado ao diretor do departamento de Tecnologia da Informao de uma empresa.
118
CHAPTER 5.
STAKEHOLDERS
5.2.3.1 Usurios
A principal preocupao dos usurios com as funcionalidades
providas pelo sistema, pouco importando como o software foi
dividido em mdulos ou como esses mdulos se comunicam
entre si.
Podemos armar que um usurio s pensa em um
atributo de qualidade, por exemplo, em desempenho ou em

segurana, quando algum desses lhe faltar.
Essa despreocupao com a organizao interna do software
poderia nos fazer armar ingenuamente que a arquitetura no
interessa ao usurio. No entanto, ela interessa, ainda que indiretamente, uma vez que o sistema deve possuir uma arquitetura que proporcione os atributos de qualidade esperados pelos
usurios para que funcione de forma satisfatria.
J em relao documentao, os usurios esto interessados
em saber as capacidades e o comportamento do sistema. Vale
notar que essa informao pode estar em outros documentos,
como em um manual do usurio, mas esse e outros documentos
devem ser escritos tendo por base o documento de arquitetura,
que deve conter essas informaes.
5.2.3.2 Clientes
Da mesma forma que os usurios, os clientes no costumam
se preocupar em detalhes tcnicos da arquitetura. Eles esto
interessados nas caractersticas da arquitetura ligadas ao seu
negcio: se o sistema faz o que deveria fazer, seus custos, sejam de desenvolvimento ou de execuo, e o planejamento de
seu desenvolvimento.
Isso se faz necessrio para justicar o
dinheiro investido no software.

Clientes tambm se mostram interessados na justicativa de
resoluo dos eventuais conitos, principalmente se essa resoluo tem impacto no negcio.

119
5.2.3.3 Arquiteto
Uma vez que o principal responsvel por projetar a arquitetura, o arquiteto tem a obrigao de conhecer os stakeholders envolvidos no sistema. Isso permitir que ele saiba o que
os stakeholders esperam do sistema e, por m, seja capaz de
projetar o sistema de acordo com os requisitos esperados. O
arquiteto tambm responsvel por negociar os conitos de
interesses entre os stakeholders, o que resultar numa arquitetura com atributos de qualidade que agradem a vrios, mesmo
que parcialmente.
A necessidade de conhecer e dialogar com os diversos stakeholders faz com que o arquiteto precise de habilidades tanto
sociais quanto tcnicas. Em relao ao conhecimento tcnico,
ser experiente no domnio do problema o ajudar a identicar
previamente as diculdades e solues a serem encontradas ao
longo do desenvolvimento. J as habilidades sociais o ajudam
tanto na descoberta de requisitos, quanto na negociao de
divergncias.
5.2.3.4 Desenvolvedor
O desenvolvedor v a arquitetura como base para construir o
sistema.
H dois extremos de como a arquitetura pode ser
apresentada para ele. Ela pode ser apresentada como uma especicao, onde no h qualquer liberdade de design durante
o desenvolvimento. Ou ela pode ser apresentada como um guia,
que apresenta algumas restries essenciais para que o software
alcance o sucesso, mas tambm possui diversas liberdades para
as decises de implementao e design de baixo-nvel que cam a cargo do time de desenvolvimento. Ao longo de todo o
espectro, o desenvolvedor espera pela ideia geral do sistema,
onde as funcionalidades sero implementadas, quem sero os
responsveis por elas e quais as decises de design de alto-nvel
relacionadas a elas.
120
CHAPTER 5.
STAKEHOLDERS
Um desenvolvedor comumente espera que a arquitetura tambm seja vivel e de acordo com suas habilidades, alm de que
possua as decises de design escritas de forma clara e objetiva.
Ele tambm espera que o documento de arquitetura possibilite
a associao dos requisitos do sistema s partes que o compem. Essa associao o que chamamos de rastreabilidade,
que torna mais fcil tanto a manuteno quanto o entendimento do sistema.
5.2.3.5 Testador
O testador procura no documento de arquitetura as restries
as quais o software deve obedecer. Alm disso, ele espera que
o software seja testvel e, para tanto, sua arquitetura deve
proporcionar tal atributo de qualidade.
O nvel de testabilidade de um software est diretamente ligado
a capacidade dele (ou de suas partes) ser posto em execuo em
ambiente de desenvolvimento e de seu comportamento, interno
ou externo, ser vericvel a partir do esperado.
5.2.3.6 Gerente de projeto

O gerente de projeto, assim como o cliente, est interessado em
custos e planejamento. No entanto, ele tambm se preocupa
com detalhes tcnicos da arquitetura e como ela ajudar no desenvolvimento do software. A arquitetura o ajudar a resolver
problemas do tipo:
como dividir o time de desenvolvimento
a m de paralelizar a construo dos mdulos, quais partes

do software podem ter o cdigo reusado, terceirizado ou comprado, ou ainda como as funcionalidades sero divididas entre
os mltiplos releases do software.

121
5.3 Resumo
De maneira alguma esgotamos o assunto sobre stakeholders.
Por outro lado, no devemos nos aprofundar ainda mais para
no perdermos nosso foco que o design da arquitetura. Entretanto, acreditamos alcanar os objetivos deste captulo, mesmo
com uma abordagem supercial sobre o assunto. Assim, esperamos que o leitor, a partir de agora:
entenda e exemplique o conceito de stakeholders da arquitetura de um software;
entenda a inuncia desses stakeholders;

relacione os stakeholders aos atributos de qualidade esperados pelo software; e
entenda que os stakeholders se relacionam entre si, podendo, inclusive, gerar demandas conitantes.
Nos captulos a seguir, voltamos nosso foco aos atributos de

qualidade e s tcnicas de como se projetar uma arquitetura
que atenda a esses atributos. Ainda assim, no podemos esquecer que nossos objetivos como arquitetos so descritos explicita
ou implicitamente pelos stakeholders e por sua inuncia sobre
arquitetura do software.
5.4 Referncias
5.4.1 Denio e papel dos stakeholders
O padro ISO/IEEE 1471-2000 [54], alm de denir stakeholders, modela seu papel em relao aos vrios elementos
relacionados arquitetura de software.
nesse padro que
Rozanski e Woods se baseiam para para chegar denio de

stakeholders no livro Software Systems Architecture:
Work-
ing With Stakeholders Using Viewpoints and Perspectives [89],

onde dedicam um captulo inteiro sobre o assunto. Outras duas
122
CHAPTER 5.
STAKEHOLDERS
importantes referncias sobre o papel dos stakeholders ao longo

da vida da arquitetura so dois livros publicados pelo Software
Engineering Institute, da Carnegie Mellon University:
Soft-
ware Architecture in Practice de Bass et al [14] e Documenting

Software Architecture: Views and Beyond de Clements et al
[31].
Ambos mostram a importncia de considerar os stake-
holders, sendo o segundo mais completo pois tambm trata

das escolhas que o arquiteto deve fazer ao criar as vises da
arquitetura de acordo com os interessados.
5.4.2 Arquiteto como stakeholder

Taylor et al, no livro Software Architecture: Foundations, Theory, and Practice [102], dedicam todo um captulo sobre a responsabilidade do arquiteto como stakeholder, incluindo os diversos papis que ele pode assumir durante o ciclo de vida do
software.
Outros artigos importantes sobre o papel do arquiteto de software que podemos citar so o The Software Architect and
The Software Architecture Team de Kruchten [59], o Who
Needs an Architect?
de Fowler [43] e o The Software Archi-
tect: Essence, Intuition, and Guiding Principles de McBride

[71].
5.4.3 Responsabilidades dos stakeholders

Booch discute sobre a despreocupao dos usurios em relao arquitetura em The Irrelevance of Architecture [18].
J em Goodness of Fit [17], ele escreve sobre o que seria uma
arquitetura de sucesso.
Por m, Hohmann, no livro Beyond Software Architecture [51]
trata das diversas preocupaes ligadas aos atributos de qualidade do software.
Preocupaes que no so apenas do ar-

123
quiteto, mas tambm so dos diversos envolvidos no desenvolvimento do software.
5.5 Exerccios
Exerccio 5.1
Qual a importncia da identicao dos stakeholders
na arquitetura de um sistema de software?
Exerccio 5.2
A identicao de muitos stakeholders em uma arquitetura aumenta a chance de sucesso. No entanto, os
interesses dos stakeholders muitas vezes no so claros
e podem ser conitantes e/ou contraditrios. Cite mais
exemplos desses conitos/contradies.
Exerccio 5.3
impossvel capturar as caractersticas funcionais e
as propriedades de qualidade de um sistema complexo
com um simples modelo.
De que forma poder-se-ia
representar arquiteturalmente sistemas complexos de

forma que seja gerencivel e compreensvel por uma
faixa de stakeholders tcnicos e de negcio?

124
CHAPTER 5.
STAKEHOLDERS

Chapter 6
Atributos de Qualidade
Um software tem como objetivo atender aos seus requisitos

funcionais e no-funcionais. Os requisitos funcionais descrevem
as funes que o software deve ser capaz de realizar, ou seja, o
que o sistema faz. J os requisitos no-funcionais descrevem as
qualidades e restries de como o sistema realiza suas funes,
ou seja, como o sistema funciona. Um software, portanto, deve
exibir atributos de qualidade que atendam aos seus requisitos.
Por sua vez, a arquitetura de software contm a descrio de

como esse alcana aos atributos de qualidade. Essa descrio
de como o software atende aos requisitos no-funcionais feita
pelas diversas decises presentes na arquitetura. Para conceber essas decises arquiteturais e, portanto, para projetar a
arquitetura de fundamental importncia que o arquiteto
conhea tanto os objetivos a serem alcanados pelo software,
quanto as ferramentas para alcan-los.
Em outra palavras,
essencial que ele conhea tanto os atributos de qualidade,

quanto tcnicas e padres de design arquitetural que, ao serem
implementados, possibilitam ao software que exiba os atributos
1 This
content
is
available
125
online
at
CHAPTER 6.
126
ATRIBUTOS DE
QUALIDADE
de qualidade desejados.
Considerando a importncia dos atributos de qualidade de
software, dedicamos dois captulos a eles.
Neste captulo,
mostramos uma viso geral do assunto, abordando diversos

atributos que devem ser alcanados. Este captulo tem como
objetivos:
Identicar o que so atributos de qualidade e qual sua

inuncia na arquitetura de software;
Relacionar atributos de qualidade a decises arquiteturais que os proporcionam;
Entender que os atributos de qualidade se relacionam e

como eles se relacionam.
No captulo seguinte, apresentamos tcnicas de design arquitetural e uma srie de estudos de como alguns atributos foram
alcanados na prtica em diferentes sistemas de software. Esses
estudos mostram que tcnicas e padres de design arquitetural foram aplicados para alcanar tais atributos e quais seus
benefcios e limitaes apresentados.
6.1 Requisitos Funcionais e NoFuncionais

O nico objetivo de um software o de atender a seus requisitos. Esses requisitos so denidos ao longo de seu ciclo desenvolvimento e costumam ser classicados em requisitos funcionais e requisitos no-funcionais.
Os requisitos funcionais descrevem as funes que o sistema
capaz de realizar, ou seja, descrevem o que o sistema faz.
Denio 6.1: requisito funcional

a declarao de uma funo ou comportamento
providos pelo sistema sob condies especcas.
127
Os requisitos do software so impostos pelos seus diversos

stakeholders.
No entanto, os requisitos funcionais costumam
ser ditados pelos clientes do software, anal so eles que esperam ter seus problemas resolvidos pelas funcionalidades do
software.
Exemplo 6.1
Se estamos falando do SASF, entre suas funes, podemos citar:
(RF-01):
O usurio deve ser capaz de inserir um lme
da sua lista de aluguis;
(RF-03):
O usurio deve ser capaz de assistir a um
lme via streaming ;
(RF-06):
O usurio deve ser capaz de adicionar um
comentrio sobre um lme.
Se o problema de desenvolver software fosse apenas o de atender aos requisitos funcionais, desenvolver software j poderia
ser considerado uma tarefa difcil.
Isso porque, para serem
atendidos, muitos dos requisitos funcionais necessitam de conhecimento que ultrapassa os limites da Engenharia de Software, da Cincia da Computao ou mesmo da Matemtica.
Anal, para se implementar sistemas para Computer-Aided
Design (CAD) ou sistemas que analisam os dados extrados do
Large Hadron Collider (LHC)
preciso grande conhecimento
especco ao domnio do problema, ou seja, grande conhecimento de outras engenharias ( por ex., Engenharia Mecnica
e Civil) ou de outras cincias ( por ex., Fsica e Qumica),
respectivamente.
Alm da necessidade de conhecimento especco ao domnio do
problema, h outra diculdade no desenvolvimento de software
2 http://public.web.cern.ch/public/en/LHC/LHC-en.html
(<http://public.web.cern.ch/public/en/LHC/LHC-en.html>)

CHAPTER 6.
128
ATRIBUTOS DE
QUALIDADE
para atender apenas aos requisitos funcionais: o cliente pode

no ter certeza sobre o que ele quer do software. Esta condio
bem conhecida pela Engenharia de Requisitos, que nos prov
algumas tcnicas para resolv-la ou contorn-la. Mas isso no
quer dizer que no possa se tornar um problema durante o
ciclo desenvolvimento.
Anal, se o principal interessado no
sabe bem quais funes se espera que o sistema realize, no

podemos armar que ser fcil desenvolver esse sistema.
Por outro lado, h tambm os requisitos no-funcionais. Esses
esto relacionados qualidade da realizao dos requisitos funcionais, ou seja, como essas funes so realizadas.
Denio 6.2: requisito no-funcional

a descrio de propriedades, caractersticas ou restries que o software apresenta exibidas por suas funcionalidades.
Esses requisitos tambm so impostos pelos diversos stakeholders do software e esto normalmente relacionados a interfaces
com o usurio, capacidades, consumo de recursos e escalas de
tempo.
Exemplo 6.2
Podemos citar alguns exemplos de requisitos nofuncionais do SASF:
(RNF-01):
O sistema deve permitir o uso por diver-
sas interfaces diferentes: navegador de internet,

celular, TV (usando um decodicador de TV por
assinatura compatvel) e aplicao-cliente compatvel com as famlias de sistemas operacionais
Windows, Mac OS e Linux;
(RNF-04):
O sistema deve suportar at 3 milhes de
inseres na la de aluguis por dia (34,7 operaes por segundo);

129
(RNF-09):
Uma transmisso de vdeo via streaming
no pode ser iniciada em mais do que 30 segundos.
As restries feitas pelos requisitos no-funcionais so vrias

e podem incluir restries ao processo de desenvolvimento, restries para atingir ou manter compatibilidade, e restries
legais, econmicas ou de interoperabilidade. As restries ao
processo de desenvolvimento podem ser feitas pela imposio
de padres de desenvolvimento ou mesmo de linguagens a
serem utilizadas pelo sistema. Por exemplo, um requisito nofuncional de um sistema pode ser que ele deva ser implementado usando a linguagem Java
, uma vez que a equipe respon-
svel pela operao e manuteno aps seu desenvolvimento

seja experiente nessa linguagem.
Por m, podemos ainda
citar requisitos no-funcionais conhecidos que foram impostos

em prol de compatibilidade e interoperabilidade e por que
no dizer de questes econmicas, que um caso relacionado
ao sistema operacional Windows NT. O Windows NT possui
requisitos no-funcionais que ditam que ele deve ser capaz de
executar aplicativos originalmente escritos para DOS, OS/2,
verses anteriores do Windows e aplicativos de acordo com o
padro POSIX
. Assim, satisfazendo aos requisitos de poder
executar aplicativos originalmente escritos para sistemas operacionais anteriores, o Windows NT teria um custo de adoo
mais baixo, uma vez as empresas no precisariam renovar seu
ecossistema de aplicativos para poder us-lo. J o requisito de
aderncia ao padro POSIX se mostra necessrio para eventuais contratos com clusulas do tipo: o sistema operacional a
ser utilizado deve estar de acordo com o padro POSIX.
3 Note que no tivemos acesso ao documento de requisitos do Windows

NT. No entanto, a estrutura de seu kernel deixa bem clara esta necessidade de retrocompatibilidade e aderncia ao padro POSIX. Para mais
informaes sobre esse assunto, recomendamos a leitura do captulo
Tale of Two Standards
do livro
Open Sources 2.0
[35].

CHAPTER 6.
130
ATRIBUTOS DE
QUALIDADE
Os requisitos no-funcionais podem ainda ser divididos em trs

tipos: de produto, de processo e externos. Os requisitos nofuncionais de produto podem, primeira vista, nos parecer os
nicos que deveramos estudar. Isso se d por eles estarem diretamente relacionados qualidade do software e serem denidos
como os requisitos que especicam as caractersticas que o software deve possuir.
No entanto, devemos lembrar que a ar-
quitetura de software no inuencia apenas a qualidade nal

do software, mas tambm inuencia (e inuenciada pela) a
forma com que ele desenvolvido e at mesmo a organizao
em que ela est inserida.
Denio 6.3: requisito no-funcional de produto

Requisito que especica as caractersticas que um sistema ou subsistema deve possuir.
Os requisitos no-funcionais de produto, como j dito anteriormente, so relacionados qualidade do software e so alcanados pelo que chamamos de atributos de qualidade. Portanto,
quando existem requisitos em que o software deve ter algum
grau de conabilidade, certo nvel de ecincia, ou ser portvel
para diversos sistemas operacionais, estamos descrevendo quais
atributos de qualidade que o software deve exibir. Todos requisitos presentes no Exemplo 6.2 podem ser classicados como
sendo de produto.
Ainda retornaremos a esse assunto neste
captulo, mas antes devemos mostrar os outros tipos de requisitos no funcionais.

Os requisitos no-funcionais de processo so denidos como as
restries ao processo de desenvolvimento.
Denio 6.4: requisito no-funcional de processo

Requisito que restringe o processo de desenvolvimento
do software.

131
Esse tipo de requisito encontrado em muitas situaes, principalmente em grandes empresas ou organizaes. Por exemplo,
comum que o desenvolvimento de sistemas de software para
o Exrcito Americano tenham como requisito ter o processo de
desenvolvimento de acordo com a Joint Technical Architecture
Por m, h os requisitos no-funcionais externos. Esses, muitas

vezes, podem se classicar tanto como de produto quanto de
processo e so extrados do ambiente em que o sistema desenvolvido. Esse ambiente pode ser tanto a organizao, com
polticas que devem ser seguidas ou seu atual ecossistema de
software com o qual ele deve interoperar, quanto a legislao
vigente do pas em que o sistema est operando.
Denio 6.5: requisito no-funcional externo

Requisito derivado do ambiente em que o sistema
desenvolvido, que pode ser tanto do produto quanto
do processo.
Por m, como exemplo de requisitos externos, podemos citar:
Exemplo 6.3
O sistema de recomendao de livros deve ler as informaes do sistema de aluguel de livros de uma biblioteca, onde cada registro de livro est de acordo com
o padro Dublin Core. Um requisito no-funcional externo desse sistema de recomendao :
(RNF-01):
O sistema deve guardar os dados dos
livros recomendados em um modelo mapevel

para o modelo de dados denido pelo padro
Dublin Core [85].
4A
Department of Defense Joint Technical Architecture (DoD JTA) [6]
um documento que descreve um conjunto de normas a que um sistema

deve aderir para facilitar a interoperabilidade com outros sistemas do
Exrcito Americano. A ttulo de curiosidade, o DoD JTA contm algumas
centenas de normas.
CHAPTER 6.
132
ATRIBUTOS DE
QUALIDADE
Note
que
uso
do
Dublin
Core
realmente
necessrio porque a comunicao entre os dois sistemas

esperada e que um sistema j adota esse padro.
6.1.1 Diferenas entre requisitos funcionais e

no-funcionais
Apesar da classicao dos requisitos de software em requisitos
funcionais e no-funcionais ser bem aceita, devemos observar
que na prtica essa diviso pode no ser to clara. Isso ocorre
devido ao nvel de detalhes contido em sua descrio ou mesmo
devido ao tipo de sistema desenvolvido.
Podemos ilustrar o caso em que o nvel de detalhes faz a diferena com o seguinte exemplo:
Exemplo 6.4
Se
considerarmos
condencialidade
(e
um
requisito
normalmente
de
segurana
considerado
de
no-
funcional):
(RNF-01):
O sistema deve possibilitar o envio de
mensagens de modo que no possam ser lidas a

no ser pelos destinatrios.
Uma vez que no especica nenhuma funcionalidade,
esse pode ser considerado um requisito no-funcional.
Por outro lado, poderamos deixar essa evidente caracterstica de requisito no-funcional um pouco mais
turva se adicionarmos um pouco mais de detalhes a
ele:
(RF-01):
O sistema deve permitir aos usurios que
criptografem suas mensagens usando as chaves

pblicas dos destinatrios.
133
Agora, esse requisito seria melhor classicado como

funcional, uma vez que especica uma funo do sistema, apesar do atributo de qualidade exibido pelo
software ao nal do desenvolvimento ser o mesmo:
segurana, mais especicamente condencialidade das
mensagens enviadas.
J quando mencionamos que o tipo do sistema pode inuenciar
em como classicamos um requisito, basta apenas lembrarmos
dos sistemas de tempo-real. Neles, a corretude do comportamento do sistema no depende s do resultado lgico da funo,
mas tambm quando esse resultado obtido. Portanto, uma
resposta cedo ou tarde demais pode estar to incorreta quanto
uma resposta logicamente errada.
Exemplo 6.5
Em um sistema de informao, consideramos o requisito no-funcional:
(RNF-01):
A busca por nome deve retornar os resul-
tados em no mximo 100 milissegundos.

J em um sistema de controle de voo y-by-wire, devemos considerar o requisito a seguir como funcional,
uma vez que respostas que no respeitam o intervalo
de tempo especicado so to inteis quanto a falta de
resposta dos sensores (podem causar a queda do avio):
(RF-01):
Novas amostras de dados dos sensores da
aeronave devem ser obtidas a cada 20 milissegundos.
Apesar disso, vale notar que ambos os requisitos presentes no

Exemplo 6.5 ditam que tanto o sistema de informao quanto
o sistema y-by-wire devem exibir o atributo de qualidade desempenho, mesmo que em graus diferentes.

CHAPTER 6.
134
ATRIBUTOS DE
QUALIDADE
6.1.2 Conitos entre requisitos

Como requisitos de software tm impacto em um ou mais atributos de qualidade, pode acontecer de impactarem em atributos
relacionados a outros requisitos. Quando isso ocorre, o impacto
pode resultar em reforo do atributo ou em conito.
Podemos perceber que no surgem grandes problemas quando
dois ou mais requisitos reforam o mesmo atributo de qualidade. Anal, caso isso ocorra, o design da soluo que atenda
a um dos requisitos afetar apenas positivamente o design da
soluo que atenda aos outros requisitos.
Apesar do caso de requisitos que se reforam no ser muito
comum, podemos ilustr-lo com requisitos que afetam segurana do software, mais precisamente autenticidade e condencialidade:
Exemplo 6.6
Se temos um sistema de mensagens instantneas com
os seguintes requisitos:
(RNF-01):
O sistema deve prover meios de autenticar
os seus usurios.
(RNF-02):
Uma mensagem enviada a um usurio no
pode ser lida a no ser pelo destinatrio.

Podemos observar que os requisitos RNF-01 e RNF-02
se relacionam, uma vez que afetam a alguns aspectos
de segurana do sistema. Eles se reforam visto que
possvel encontrarmos uma soluo para RNF-01 que
facilite RNF-02 e vice-versa.
A soluo no caso a
utilizao criptograa de chave pblica: tanto ela pode

ser usada para autenticao de usurios quanto pode
ser usada para encriptao de mensagens.
Por outro lado, requisitos conitantes so mais comuns e adicionam diculdade durante o design das solues. Isso ocorre
135
porque a soluo para um requisito conitante afeta negativamente outro requisito.
Assim, o design do software ter que
considerar diversos trade-os a m satisfazer melhor aos requisitos mais importantes, j que atender a todos de forma tima
no possvel.
Se adicionamos alguns requisitos de usabilidade ao Exemplo 6.6, esses novos requisitos certamente afetaro negativamente soluo apresentada.
Isso ocorre porque comum
que solues de segurana afetem aos requisitos de usabilidade, visto que essas solues adicionam conceitos no familiares aos usurios (por exemplo, chaves criptogrcas) ou adicionam mais passos para que os usurios realizem suas tarefas
(por exemplo, inserir login e senha).
6.1.3 Expressando requisitos no-funcionais

Grande parte do trabalho de um arquiteto consiste em projetar sistemas que devem satisfazer requisitos no-funcionais.
No entanto, a Engenharia de Requisitos limitada quanto a
mtodos de anlise e derivao de requisitos no-funcionais.
Essa limitao, muitas vezes, obriga ao arquiteto a trabalhar
com requisitos que carecem de mtricas e valores-alvo.
Isso
diculta o processo de design, uma vez que desconhecer requisitos o mesmo que desconhecer os objetivos do design. Por
este motivo, recomenda-se aos arquitetos que sempre busquem
por requisitos que possuam valores e mtricas bem denidos
e, desta maneira, conheam e possam medir os objetivos e o
sucesso de seu design.
Todavia, nem sempre possvel trabalhar com requisitos bem
denidos,
uma vez que encontramos alguns problemas ao
express-los. Os principais motivos da diculdade de expressar

requisitos no-funcionais so os seguintes:
Alguns requisitos simplesmente no so conhecidos em

CHAPTER 6.
136
ATRIBUTOS DE
QUALIDADE
etapas iniciais do ciclo de desenvolvimento. Por exemplo,

a tolerncia a faltas ou o tempo de recuperao pode ser
muito dependente da soluo de design.
Alguns requisitos, como alguns relacionados usabilidade,
so muito subjetivos,
dicultando bastante a
medio e o estabelecimento de valores-alvo.
E, por m, h os conitos entre requisitos. Como j foi

apresentado, requisitos podem inuenciar atributos de
qualidade comuns ou relacionados, at fazendo com que
requisitos sejam contraditrios.
Mesmo sendo difcil lidar com os requisitos no-funcionais,

obrigao do arquiteto projetar o software de modo que, ao
m do desenvolvimento, este exiba os atributos de qualidade
esperados pelos stakeholders.
6.2 Atributos de qualidade

Apesar de armarmos que o software possui requisitos nofuncionais
a serem atendidos, comum dizermos que o soft-
ware exibe atributos de qualidade que atendem aos requisitos

em questo. Portanto, atributos de qualidade esto mais relacionados aos objetivos j alcanados, enquanto requisitos so
os objetivos propostos.
Podemos chamar de atributos de qualidade do software suas
propriedades externamente visveis. Essas propriedades podem
se manifestar como:
capacidades ou restries de suas funes. Por exemplo,

tempo de resposta de uma determinada funo ou capacidade de execuo de certa quantidade de chamadas
simultneas;
5 Alguns autores preferem o termo
requisitos de qualidade.

137
caractersticas
no
diretamente
relacionadas
suas
funes. Por exemplo, usabilidade ou adoo de padres

para interoperabilidade; ou ainda
caractersticas relacionadas ao ciclo de desenvolvimento.

Por exemplo, testabilidade ou mesmo a capacidade de
facilitar o desenvolvimento por mltiplos times geogracamente distribudos.
Denio 6.6: atributo de qualidade

uma propriedade de qualidade do software ou de
seu ciclo de desenvolvimento, podendo se manifestar
como caractersticas, capacidades ou restries de uma
funo especca ou de um conjunto de funes do software.
Podemos perceber a importncia dos atributos de qualidade,
em especial, quando comparamos dois produtos de software
que tm as mesmas funcionalidades, como fazemos no exemplo
a seguir:
Exemplo 6.7
Vamos considerar um projeto para construo de sistemas de buscas de sites web chamado Hounder
Para deixarmos nosso exemplo ainda mais signicativo em termos de diferenas entre atributos de qualidade, vamos considerar um sistema construdo usando
o Hounder, mas em que todos os seus mdulos executam em apenas um servidor.
servio de busca de HSearch
Vamos chamar esse
Uma vez que o Google Web Search
tambm um
6 http://hounder.org/ (<http://hounder.org/>)
7 Caso
o
leitor
deseje
criar
um
clone
basta
seguir
tutorial
de
cinco
minutos
do
http://code.google.com/p/hounder/wiki/5minuteTutorial
(<http://code.google.com/p/hounder/wiki/5minuteTutorial>)
8 http://www.google.com (<http://www.google.com>)
HSearch,
presente
em
CHAPTER 6.
138
ATRIBUTOS DE
QUALIDADE
servio de busca de web sites, podemos armar que

ambos os servios tm o principal requisito funcional
em comum:
(RF-01):
O sistema deve retornar endereos de web
sites que se relacionem s palavras-chave inseridas pelo usurio.

J que ambos os servios funcionam, percebemos que
ambos atendem ao requisito (RF-01), o que poderia
signicar algum grau de equivalncia entre os servios.
No entanto, se compararmos como ambos os sistemas
atendem a esse requisito, perceberemos que eles so
bem diferentes,
justamente pela diferena entre os
atributos de qualidade que exibem.

Para funcionar, um servio de busca de web sites deve
executar basicamente trs atividades:
(a) crawling,
que a coleta de pginas que serviro de resultados, (b) indexao, que a organizao da informao
obtida na atividade de crawling de forma que facilite
a busca (principalmente em termos de desempenho),
e (c) busca, cujo resultado a realizao do requisito
RF-01.
Note que as trs atividades so I/O bound,
ou seja, as atividades tm uso intensivo de entrada e

sada.
Portanto, elas tm seu desempenho limitado
pela capacidade de entrada e sada dos recursos computacionais em que executam.

Se compararmos as capacidades de ambos os sistemas,
o HSearch est limitado capacidade do nico computador em que est executando.
Isso signica que
ele executa as trs atividades usando o mesmo recurso.

Por outro lado, bem conhecido que a arquitetura do
Google Web Search permite que o sistema utilize diversos data centers ao redor do mundo, usando muitos milAvailable for free at Connexions
139
hares de processadores simultneos e, assim, podendo

dividir a execuo das trs atividades entre esses recursos. Por essa diferena de utilizao de recursos, algumas mtricas de vrios atributos de qualidade, como
tempo de resposta, capacidade de atender a buscas simultneas, tamanho do ndice de busca ou tolerncia
a falhas de hardware sero bem diferentes entre os dois
sistemas.
Quando comparamos as bilhes de consultas dirias
que o Google Web Search capaz de realizar com as
apenas milhares ou poucos milhes do HSearch, dizemos que o desempenho do primeiro melhor. Mas o
desempenho no diferente apenas em termos de operaes por unidade de tempo, mas tambm quando
comparamos os tempos de resposta para cada operao
ou nmero de usurios simultneos no sistema. Se considerarmos que o Google Web Search realiza um bilho
de buscas por dia e cada busca dura em torno de 300
milissegundos, pela Lei de Little [67], temos cerca de
3500 buscas simultneas a qualquer momento ao longo
da vida do sistema. J o HSearch s consegue realizar
3,5 buscas simultneas ao realizar 1 milho de buscas
por dia a 300 milissegundos cada.
Mas h outros atributos que podem ser mencionados. O HSearch dependente do funcionamento de um
nico servidor. Portanto, se esse servidor falhar, todo
o sistema car fora do ar. J o Google Web Search
capaz de tolerar falhas de hardware, uma vez que no
depende de apenas um servidor para funcionar. Assim,
podemos dizer que o grau de conabilidade ou tolerncia a falhas do Google Web Search maior que o do
HSearch. As respostas do HSearch so formadas apenas pelo ttulo e pequenos trechos dos web sites que

CHAPTER 6.
140
ATRIBUTOS DE
QUALIDADE
contm as palavras-chave.
J o Google Web Search
ajuda ao usurio tambm mostrando imagens contidas

no site ou mesmo trechos de vdeo, contribuindo assim
para sua usabilidade. Por m, citamos tambm que o
Google Web Search apresenta o atributo de integrabilidade, dado que ele contm diversos servios alm da
busca numa mesma interface: entre eles calculadora,
previso do tempo, converso de medidas, denio de
palavras, busca de sinnimos, entre outros.
a arquitetura que permite que o software exiba os atributos
de qualidade especicados. J que a especicao dos atributos
feita pelos requisitos (normalmente no-funcionais), requisitos e atributos de qualidade partilham diversas caractersticas.
Tanto que alguns autores usam ambas as expresses com o
mesmo sentido.
As principais caractersticas dos atributos de qualidade so as
seguintes:
Atributos de qualidade impem limites s funcionalidades;
Atributos de qualidade se relacionam entre si; e

Atributos de qualidade podem tanto ser de interesse dos
usurios quanto dos desenvolvedores.
6.2.1 Limites s funcionalidades

Os limites s funcionalidades acontecem da mesma forma que
os requisitos podem restringir ou mesmo impedir funcionalidades, pois atributos de qualidade no se manifestam isolados
no ciclo de vida do software, mas inuenciam e so inuenciados pelo meio. Por exemplo, para que o SASF tenha um time to
market pequeno, ele deve ser lanado inicialmente sem possuir
um cliente de streaming para dispositivos mveis, deixando
141
para implementar essa funcionalidade em outras verses. Isso

uma limitao na funcionalidade de transmisso de lmes em
benefcio do atributo de qualidade custo e planejamento.
tambm bastante comum encontrarmos sistemas que tm funcionalidades podadas simplesmente porque, se estas existissem,
o software no exibiria os atributos de segurana esperados.
6.2.2 Relaes entre atributos de qualidade

Como j foi observado, os atributos no existem isoladamente
e, por afetarem partes em comum da arquitetura, afetam tambm outros atributos de qualidade. Eis que surgem os tradeos entre os atributos de qualidade. Por exemplo, um sistema
mais portvel ter seu desempenho afetado negativamente,
pois necessita de mais camadas de software que abstraiam o
ambiente que pode ser mudado.
J no caso do SASF, para
se obter um nvel de segurana capaz de realizar autorizao

e autenticao, a usabilidade do software prejudicada, uma
vez que o usurio deve ser obrigado de lembrar sua senha ou
mesmo ter o uxo de aes interrompido para que insira suas
credenciais.
papel do arquiteto conhecer e resolver os trade-os entre os
atributos de qualidade durante as fases de design e implementao. Por isso, ao apresentar algumas tcnicas para alcance
da qualidade, apresentaremos tambm quais atributos so inuenciados positiva e negativamente.
6.2.3 A quem interessa os atributos de qualidade

Uma grande gama de atributos podem ser citados. Tanto que,
a seguir, quando apresentamos uma lista deles, restringiremonos a apenas um modelo de qualidade.
Esses atributos po-
dem interessar a vrios envolvidos no ciclo de vida do softAvailable for free at Connexions
CHAPTER 6.
142
ATRIBUTOS DE
QUALIDADE
ware, como usurios e desenvolvedores. Dos exemplos citados

anteriormente, podemos dizer que desempenho e usabilidade
so atributos importantes a usurios, enquanto custo e planejamento so mais importantes aos desenvolvedores.
6.3 Modelo de Qualidade

Para avaliar a qualidade de um software, o ideal seria usar todos os atributos de qualidade que conhecemos. No entanto,
invivel adotar esta abordagem em um processo de desenvolvimento que possua tempo e dinheiro nitos devido grande
quantidade de dimenses
do software que poderamos avaliar.
Para facilitar o processo de avaliao durante o desenvolvimento, foram desenvolvidos o que chamamos de modelos de
qualidade. Modelos de qualidade tm como objetivo facilitar a
avaliao do software, organizando e denindo quais atributos
de qualidade so importantes para atestar a qualidade geral do
software. Alguns exemplos signicativos de modelos de qualidade so os de Boehm [16], o de McCall [72] e o contido no
padro ISO/IEC 9126-1:2001 [4]. Vamos descrever melhor este
ltimo, para assim termos uma melhor noo de quais atributos de qualidade procuramos que a arquitetura permita ao
software.
Denio 6.7: modelo de qualidade

Modelo que dene e organiza os atributos do software
importantes para a avaliao de sua qualidade.
9 Em
Ingls,
qualidade
usando
vrios
atributos.
dades
presente
alguns
o
autores
suxo
Podemos
no
se
-ilities,
endereo:
referem
que
perceber
-idades,
mesmo qualidades.
isso
aos
comum
na
atributos
de
ao
de
lista
nome
de
quali-
http://en.wikipedia.org/wiki/Ilities
(<http://en.wikipedia.org/wiki/Ilities>).
nos referir a
mas preferimos usar
Em Portugus,
poderamos
dimenses, propriedades

ou
143
6.3.1 Padro ISO/IEC 9126-1:2001

Ele um padro internacional para avaliao de software. O
que nos interessa dele o contedo de sua primeira parte, que
o que chamado de qualidades internas e externas do software.
Essas qualidades so apresentadas na forma de uma lista exaustiva de caractersticas ou atributos de qualidade. Os atributos
que um software deve possuir para que possamos dizer que ele
de qualidade so os seguintes:
Funcionalidade
Conabilidade
Usabilidade
Ecincia
Manutenibilidade
Portabilidade
importante enfatizar que essa lista tem como objetivo ser exaustiva. Portanto, de acordo com a norma, todas as qualidades
que venham a ser requisitadas ao software esto presentes nessa
lista. No padro, cada caracterstica ainda quebrada em subcaractersticas, que so mais especcas, a m de facilitar o
entendimento e a avaliao.
A seguir, denimos cada atrib-
uto de qualidade e mostramos algumas subcaractersticas mais

importantes ao atributo.
6.3.1.1 Funcionalidade
Funcionalidade a capacidade do software de realizar as
funes que foram especicadas. Esse primeiro atributo pode
parecer bvio, mas seu propsito claro quando passamos a
avaliar um sistema de software: se esse sistema faz menos que
o mnimo que esperado dele, ele no serve, mesmo que o
(pouco) que ele faa, ele faa de forma usvel e convel ou
ecientemente.

CHAPTER 6.
144
ATRIBUTOS DE
QUALIDADE
Para caracterizarmos melhor a funcionalidade do software, devemos ainda considerar as caractersticas de:
adequao,
ou
capacidade
de
prover
as
funes
necessrias para os objetivos dos usurios. Podemos observar que a mtrica deste atributo de qualidade a satisfao ou no dos requisitos funcionais do sistema.
Exemplo 6.8
Para se adequar s necessidades de seus usurios,
basta que o SASF atenda a seus requisitos funcionais.
Se ele realizar a locao e a transmis-
so de lmes, ele est adequado s necessidades

de seus usurios comuns.
Por outro lado, para
se adequar s necessidades dos usurios que distribuem os lmes, uma das funes que ele deve
prover a funo de upload de lmes.
preciso, ou capacidade de prover os resultados com o

grau de preciso adequado. Para que seja possvel medir
a preciso, necessrio que ela esteja especicada possivelmente no documento de requisitos.
Exemplo 6.9
Podemos observar diferentes necessidades de
preciso quando comparamos como os nmeros
so tratados em um sistema de software bancrio
e numa calculadora. No primeiro, os nmeros so
tratados apenas como racionais e truncados na
quantidade de casas decimais relativa moeda do
pas. No Brasil, por exemplo, o software bancrio
s reconhece at centavos de Real.
Portanto,
se necessrio dividir R$ 1,00 em trs parcelas,

cada parcela no ser representada pela dzima
R$ 0,33333..., mas sim por R$ 0,34. Essa mesma
preciso no poderia ser adotada em um software
145
de calculadora. Nesse, sendo uma calculadora comum, esperado que os nmeros seja representados da forma mais prxima aos nmeros reais
10
interoperabilidade, ou capacidade de interagir com outros sistemas.
Para medir o grau de interoperabilidade,
o ideal que esteja especicado quais sistemas devem

interagir. J para facilitar a satisfao desse atributo, a
soluo mais utilizada a adoo de padres de facto. Alguns tipos de padres so os de representao de dados,
como o Dublin Core ou formatos de arquivos de vdeo,
ou padres de especicao de funcionalidades, como os
padres WS-*.
11
Exemplo 6.10
uma qualidade do SASF ser capaz de interagir com diversos sistemas capazes de reproduzir
o vdeo transmitido.
Para isso, foi escolhido o
padro para transmisso de vdeo amplamente

adotado entre sistemas.
segurana, ou capacidade de funcionar segundo os princpios de autenticao, autorizao, integridade e norepudiao.
Autenticao a capacidade de o sistema
vericar a identidade de usurios ou de outros sistemas

com que se comunica.
Autorizao a capacidade de
garantir ou negar direitos de uso a recursos a usurios

autenticados. Integridade a capacidade de garantir que
10 Possivelmente, a calculadora implementar o padro para aritmtica

de ponto-utuante IEEE 754-2008 [3]
11 A comunidade interessada em
web services
especicou uma srie de
padres que facilitam a interoperabilidade entre os servios. Podemos encontrar uma grande lista deles no seguinte endereo: http://bit.ly/kIEXs
(<http://bit.ly/kIEXs>).

CHAPTER 6.
146
ATRIBUTOS DE
QUALIDADE
os dados no foram alterados indevidamente, principalmente durante a comunicao. E no-repudiao a capacidade de prover meios para a realizao de auditoria
no sistema. No entanto, importante observar que nem
todos os sistemas precisam estar de acordo com todos os
princpios.
Exemplo 6.11
Uma vez que recebe o nmero do carto do
usurio para receber o pagamento, o SASF deve
garantir que apenas o sistema de cobrana da operadora de carto de crdito seja capaz de vericar as informaes necessrias para a autorizao. Outro aspecto de segurana do SASF que
ele precisa diferenciar os usurios que ainda no
esto registrados (e, consequentemente, que no
pagaram a assinatura), dos j registrados. Para
isso, ele deve realizar a autenticao do usurio.
estar de acordo com padres, ou a capacidade de aderir a

normas, convenes ou leis relacionadas funcionalidade.
Exemplo 6.12
Para ser executado no Brasil, o SASF obrigado
por lei a emitir o cupom scal do pagamento da
assinatura do usurio.
6.3.1.2 Conabilidade
Quando armamos que um sistema convel, estamos armando que esse sistema capaz de manter algum nvel de
desempenho quando funcionando sob circustncias determinadas. A conabilidade normalmente denida sob perodos
de tempo. Ou seja, dizer apenas que o SASF deve ser convel

147
no suciente. Temos, por exemplo, que dizer que o SASF

capaz de transmitir vdeos para 6 mil usurios simultneos
sob condies normais durante 99% do ano e para mil usurios
simultneos durante o 1% do ano reservado para o perodo de
manuteno dos servidores. Vale observar que, para uma loja
online, faz mais sentido que a medida de conabilidade seja a
de servir aos seus usurios com o tempo de espera das operaes de compra e busca de 50 milissegundos durante perodos
normais do ano, mas, durante as semanas prximas ao Natal,
ter o tempo de espera das mesmas operaes em torno dos 150
milissegundos, uma vez que o nmero de usurios simultneos
nessa poca do ano aumenta consideravelmente.
A conabilidade pode ainda ser dividida nas seguintes caractersticas:
maturidade, ou capacidade de se prevenir de falhas resultantes de faltas de software. Isso comum em sistemas
distribudos, onde um componente no cona completamente no resultado provido por outro. Isso pode ser vericado em sistemas com sensores de software, onde um
mdulo pode ser responsvel por julgar os valores gerados
pelos sensores. Caso os valores sejam julgados invlidos,
o mdulo pode simplesmente desligar o sensor defeituoso. A medio do grau de maturidade de um sistema
bem difcil, mas podemos ter uma noo ao analisarmos
decises que foram feitas com este objetivo.
Exemplo 6.13
No caso do SASF, o mdulo de transmisso de
vdeo pode vericar quantas conexes esto abertas para um mesmo destinatrio.
Uma grande
quantidade de conexes para um mesmo destinatrio pode signicar um ataque ou mesmo um

bug no reprodutor de vdeo no lado do cliente
que, eventualmente, pode consumir todos os reAvailable for free at Connexions
CHAPTER 6.
148
ATRIBUTOS DE
QUALIDADE
cursos disponveis para streaming. Assim, ao detectar esse problema, o SASF pode recusar abrir
novas conexes para esse cliente,
prevenindo-
se de um problema maior, como uma completa

parada por DoS
12
tolerncia a faltas, ou capacidade de manter alguma qualidade de servio em caso de faltas de software ou comportamento imprevisto de usurios, software ou hardware.
Em outras palavras, a medida de funcionamento do software, mesmo que de forma restrita, em caso de a parada
de servidores, parties de rede, falhas de discos rgidos, insero ou leitura de dados corrompidos, etc. Considerando a grande quantidade de eventos que o software
deve tolerar, tambm so muitas as formas de medir o
grau de satisfao a este atributo de qualidade. As formas mais comuns so: medir se o servio continua funcionando em caso de falha de n servidores, medir qual
a variao no tempo de resposta para as operaes mais
comuns ou quantos usurios simultneos o sistema capaz de servir em caso de falhas de servidores ou ainda
vericar como o sistema se comporta se dados invlidos
so inseridos no sistema.
Exemplo 6.14
A forma mais comum de melhorar o grau de tolerncia a faltas em um servio web fazer com
que no dependa de um nico recurso. Seja esse
recurso hardware, como um nico processador,
roteador ou disco rgido, seja esse recurso software, como depender de um nico banco de dados, um nico servio de cadastro ou um nico
12 O
Denial of Service ou DoS ocorre quando o sistema no pode atender
a novas requisies porque todos os seus recursos esto sendo consumidos,

possivelmente devido a um ataque de um ou vrios agentes maliciosos.

149
servio de inventrio.
Assim, o SASF possui
seus mdulos replicados em diferentes servidores.

Desta maneira, ele evita a dependncia de um
nico recurso, ou o chamado ponto nico de falhas e pode continuar a funcionar mesmo que um
desses mdulos pare por completo. Note que para
a replicao funcionar, devem ser adicionados
arquitetura mdulos responsveis pela vericao
de estado dos servidores e, assim que forem detectados problemas em algum servidor, o trfego
possa ser redirecionado para rplicas sadias. Para
isso ser possvel, h ainda outras complicaes,
como a manuteno da consistncia de estado entre o servidor original e sua rplica.
Falaremos
mais sobre a eliminao do ponto nico de falhas

quanto estivermos tratando das diversas tcnicas
para a obteno de atributos de qualidade.
recuperabilidade, tambm chamada de resilincia, a capacidade de o sistema voltar ao nvel de desempenho anterior a falhas ou comportamento imprevisto de usurios,
software ou hardware e recuperar os dados afetados, caso
existam. comum medirmos o grau de recuperabilidade
ao medirmos quanto tempo o sistema leva para voltar
aos nveis normais de desempenho. Quanto menor esse
tempo, melhor a qualidade do sistema neste sentido.
Exemplo 6.15
No SASF, podemos medir o tempo de substituio de um servidor de streaming pelo tempo da
deteco da falha, somado ao tempo de inicializao do servidor e somado ao tempo de redirecionamento das requisies de transmisso. Uma
forma de ter o tempo total de recuperao minimizado seria manter o servidor auxiliar ligado,

CHAPTER 6.
150
ATRIBUTOS DE
QUALIDADE
apenas esperando a deteco da falha do servidor

principal.
No entanto, essa deciso signicaria
mais custos, uma vez que seriam dois servidores

ligados ao mesmo tempo, gastando mais energia,
diminuindo a vida til do hardware e possivelmente consumindo licenas de software.
6.3.1.3 Usabilidade
Usabilidade a medida da facilidade de o usurio executar
alguma funcionalidade do sistema. Essa facilidade est ligada
diretamente compreensibilidade, facilidade de aprendizado,
operabilidade, a quanto o usurio se sente atrado pelo sistema e adeso de padres de usabilidade, que so as subcaractersticas desse atributo de qualidade. Apesar de muitos
desses critrios serem subjetivos, h maneiras de medi-los para
termos noo da usabilidade do software. A seguir, mostramos
as subcaractersticas da usabilidade:
compreensibilidade, ou a capacidade de o usurio entender o sistema.
Esta caracterstica est ligada quan-
tidade de conceitos que o usurio precisa saber previamente para lidar com o sistema ou qualidade ou quantidade da documentao do sistema.
A compreensibil-
idade serve para o usurio dicernir se o software serve

para ele ou no.
facilidade de aprendizado est ligada diretamente compreensibilidade. No entanto, neste caso, a qualidade a
de o usurio aprender a usar o software, caso ele saiba
que o software serve para ele.
As mtricas dessa qual-
idade tambm esto relacionadas quantidade de conceitos ou operaes que o usurio precisa aprender para
fazer com que o software funcione.

151
operabilidade a capacidade de o usurio operar ou controlar o sistema. Esta qualidade muito importante em
grandes sistemas de software, onde h um tipo de usurio
que o administrador do sistema. O administrador deseja ser capaz de realizar operaes sobre o sistema que,
comumente, no esto entre as funes que interessam
aos usurios mais comuns: ligar, desligar ou vericar estado de servidores, realizar backup dos dados, etc. Em
sistemas de redes sociais, por exemplo, entre os servios
providos ao operador, ainda esto a possibilidade de expulsar usurios do sistema ou moder-los, no permitindo
que esses usurios realizem algumas funes, como enviar
mensagens ou mesmo barrando conexes de acordo com
o endereo de origem.
6.3.1.4 Ecincia
A ecincia ou desempenho talvez a qualidade mais buscada
durante o desenvolvimento de software, uma vez que ela a
mais percebida pelos usurios. Ela a qualidade relacionada
ao uso de recursos do sistema quando esse prov funcionalidade
e tambm a com que os desenvolvedores mais se preocupam.
Quando queremos medir ecincia, medimos basicamente duas
caractersticas:
comportamento no tempo ou desempenho, ou a capacidade do sistema de alcanar a resposta dentro do perodo

de tempo especicado.
Aqui, referimo-nos a tempos
de resposta, latncia, tempo de processamento, vazo (

throughput), etc. Vale observar que, ao medir essa caracterstica, devemos tambm entender as condies em que
o sistema est operando. Anal, no Exemplo 6.7, mesmo
que o HSearch tenha um tempo de resposta menor que o

CHAPTER 6.
152
ATRIBUTOS DE
QUALIDADE
Google Web Search, o primeiro capaz de servir a apenas um milsimo da quantidade de usurios servida pelo
segundo.
uso de recursos, que a capacidade de o software exigir

mais ou menos recursos de acordo com suas condies
de uso.
Normalmente, essa caracterstica tambm
chamada de escalabilidade e pode tambm ser vista de

outra maneira: como a adio ou remoo de recursos
no sistema vai melhorar ou piorar as condies de uso.
Existem dois tipos mais comuns de escalabilidade, que
tambm servem para facilitar o entendimento dessa caracterstica: escalabilidade vertical e escalabilidade horizontal . Eles podem ser melhor explicados por meio de
um exemplo:
Exemplo 6.16
Vamos considerar um sistema servidor de arquivos. Esse servidor de arquivos usa apenas um
disco rgido e capaz de servir a cinco usurios simultneos, cada um usando 10 MB/seg de banda
passante (fazendo upload ou download).
Va-
mos desconsiderar os efeitos da rede que liga os

clientes ao servidor ou qualquer outro gargalo.
Podemos dizer que as condies de uso do software so:
5 usurios simultneos a 10 MB/seg
cada.
No Exemplo 6.16, uma forma de melhorar as condies
de uso, ou mais especicamente, aumentar a quantidade
de usurios simultneos, seria seria substituir um dos recursos do sistema por outro com maior capacidade. Ou
seja, escalar verticalmente.
Exemplo 6.17: (continuao do exemplo

anterior)
Vamos substituir o disco rgido do servidor por
um que seja capaz de transferir arquivos no doAvailable for free at Connexions
153
bro da velocidade do anterior.
Desta maneira,
se o disco rgido fosse o nico fator limitante,

conseguiramos no mais servir 5 usurios a 10
MB/seg, mas sim 10 usurios simultneos a 10
MB/seg, como ilustrado na Figura 6.1.
disso,
Alm
poderamos seguir melhorando vertical-
mente o sistema at encontrarmos um limite, que

pode ser tanto o limite na velocidade possvel
para um disco rgido quanto o limite nanceiro
de comprarmos um disco mais rpido.
Figura 6.1:
Escalando verticalmente um sistema.

CHAPTER 6.
154
ATRIBUTOS DE
QUALIDADE
Outra forma de escalar o sistema seria horizontalmente.

Desta maneira, no substitumos um recurso por um melhor, mas adicionamos um novo recurso ao sistema de
modo que ele faa uso tanto do recurso velho quanto do
novo.
Exemplo 6.18: (continuao do exemplo

anterior)
Ao invs de necessariamente comprar um disco
rgido mais rpido, compramos um novo disco
(que pode at ser igual ao anterior) e fazemos
com que o software divida a carga de escrita e
leitura entre os dois discos rgidos.
Esta abor-
dagem est ilustrada na Figura 6.2.

155
Figura 6.2:
Escalando horizontalmente um sistema.
Note que a soluo do Exemplo 6.18 ((continuao do ex-

CHAPTER 6.
156
ATRIBUTOS DE
QUALIDADE
emplo anterior) ) no vem de graa: alm da camada de

software car mais complicada, h o impacto na ecincia possivelmente, o tempo de resposta ser afetado,
uma vez que uma operao do usurio ter que agora
decidir qual disco rgido usar. No entanto, a vantagem
desta soluo reside no fato de que o teto de desempenho
com a adio de novos discos ser mais alto que o teto
alcanvel com discos mais rpidos. Alm disso, h um
limite de discos rgidos que podem ser utilizados por um
mesmo sistema operacional. Para expandir ainda mais o
limite de discos rigdos sendo usados simultaneamente, o
prximo passo seria adicionar mais uma mquina servidora, o que deixaria o software ainda mais complexo,
pois este agora teria que decidir entre discos presentes
em mquinas diferentes e assim por diante. Esse apenas um exemplo de tcnica de se alcanar escalabilidade
horizontal.
No prximo captulo, quando falarmos de
tcnicas de design, apresentaremos outras abordagens e

padres de design para a escalabilidade.
6.3.1.5 Manutenibilidade
A manutenibilidade uma qualidade, s vezes, negligenciada
pelos usurios, mas muito importante aos desenvolvedores. Ela
a capacidade de o software ser modicado em seu processo de
evoluo. Podemos citar as seguintes caractersticas do atributo de manutenibilidade: a analisabilidade, a modicabilidade
e a testabilidade.
analisabilidade:
o grau de facilidade com que pode-
mos procurar por decincias no software ou por partes

que devem ser modicadas para algum m. Os nveis de
modularidade, de separao de preocupaes e de acomplamento do software se relacionam a essa caracterstica.

157
modicabilidade: a capacidade de realizar mudanas

de implementao no sistema. Essa caracterstica tambm est relacionada s mtricas clssicas de software,
como nveis de coeso e acoplamento e complexidade ciclomtica.
Quanto mais modicvel o software, menor
o impacto da mudana em reas teoricamente no

relacionadas s mudanas.
Exemplo 6.19
No SASF, por termos o mdulo de transmisso
de vdeos separado do gestor de usurios, qualquer mudana ou adio nos formatos suportados
para transmisso no deve afetar ao mdulo de
usurios.
Outra separao comum em sistemas
web que tambm foi adotada no SASF a aplicao do padro Model-View-Controller (MVC)
13
, que separa as interfaces de usurio de lgica de
negcio. Isso permite modicaes na lgica de

negcio que no afetam as interfaces de usurio
e vice-versa.
testabilidade: a capacidade de o software ter suas mudanas validadas.
Para um software ser testvel, antes
de tudo, devemos conhecer seus objetivos.
Mas, alm
disso, precisamos que o sistema seja capaz de executar de

forma controlada a m de podermos medir os resultados
obtidos a partir de entradas conhecidas. Sistemas pouco
testveis so aqueles os quais sua execuo muito cara,
pode custar vidas ou, simplesmente, no podemos medir
seu comportamento deterministicamente. Vale observar
que muitos sistemas distribudos, se mal projetados, podem se encaixar nesse ltimo tipo.
13 Falamos mais do padro arquitetural MVC quando apresentamos as

ferramentas de design de software no captulo sobre tcnicas de design.

CHAPTER 6.
158
ATRIBUTOS DE
QUALIDADE
6.3.1.6 Portabilidade
O ltimo atributo de qualidade presente no padro ISO/IEC
9126-1:2001 o de portabilidade. Esse atributo a medida de
adaptaes necessrias para que o sistema tenha seus requisitos ou ambientes de execuo modicados, podendo ser o ambiente de software, de hardware ou organizacional. Esse atributo
importante, por exemplo, para jogos, uma vez que desejvel que eles sejam capazes de executar no maior nmero de
plataformas, mas tambm desejvel que o custo para tornar
isso possvel seja baixo.
Algo similar acontece com aplica-
tivos para celulares. A necessidade de um aplicativo para celulares ser portvel existe porque comum que seus desenvolvedores queiram que ele esteja disponvel em dezenas de modelos
diferentes. Isso signica que um mesmo aplicativo deve estar
disponvel para dezenas de ambientes de hardware diferentes.
Portanto, no faz sentido que o mesmo aplicativo seja reimplementado diversas vezes, mas sim que seja projetado de forma
a minimizar o esforo para alterar o ambiente de hardware.
A portabilidade pode ainda ser dividida nas seguintes caractersticas:
adaptabilidade: a capacidade de o software ser portado

para outro ambiente sem precisar de modicaes alm
das previstas.
Exemplo 6.20
O Vuze
14
um aplicativo escrito na linguagem
de programao Java e que, por isso, capaz de

executar em qualquer sistema operacional em que
a mquina virtual Java (JVM) esteja disponvel.
No entanto, apesar da portabilidade provida pela
linguagem de programao em que foi escrito, ele
necessita de uma pequena modicao especca
14 http://www.vuze.com (<http://www.vuze.com>)
159
para cada novo sistema operacional suportado

pela JVM. Essa modicao consiste na criao
de um instalador especco para o S.O., uma vez
que diferentes sistemas possuem diferentes formas de instalao de software. No entanto, essa
modicao prevista na arquitetura do Vuze e
no afeta signicativamente sua adaptabilidade a
novos sistemas operacionais.
instalabilidade: a capacidade de o software ser instalado em algum ambiente especco. A instalabilidade

medida junto com o ambiente-alvo.
Portanto, por ex-
emplo, antes do Apple Bootcamp, o sistema operacional

Windows XP no era instalvel em ambientes Apple. J
o sistema GNU/Linux, por sua vez, era instalvel tanto
em PCs quanto em Macs.
co-existncia: a capacidade de o software compartilhar

recursos em um mesmo ambiente com outros sistemas.
6.3.2 Conitos entre atributos de qualidade

Assim como os interesses de cada stakeholder no so isolados e podem afetar os de outro por meio dos requisitos nofuncionais, os atributos de qualidade no surgem isolados no
software.
Uma deciso arquitetural feita com o objetivo de
alcanar um atributo de qualidade pode ter efeito em outros

atributos. Por uma deciso arquitetural nunca ser isolada no
design da arquitetura, o arquiteto deve sempre entender quais
atributos a deciso afeta, seja positivamente ou negativamente,
e fazer as devidas concesses caso ela afete atributos de qualidade conitantes.
No captulo sobre tcnicas de design, ob-
servaremos melhor as relaes entre os atributos de qualidade

ao apresentarmos algumas tcnicas de design arquitetural para

CHAPTER 6.
160
ATRIBUTOS DE
QUALIDADE
alcan-los. Isso acontece porque comum que essas tcnicas

no afetem cada atributo de software isoladamente.
6.4 Atributos de Negcio

Apesar de a lista de atributos de qualidade apresentada anteriormente ter sido criada a m de ser exaustiva, h alguns
atributos adicionais que merecem ser citados. So chamados
os atributos de qualidade de negcio, que, apesar de no serem
ligados diretamente ao software, tm grande inuncia sobre
sua arquitetura. Eles so importantes porque inuenciam principalmente as decises de resoluo de conitos dos atributos
apresentados anteriormente. Os atributos de negcio so:
mercado-alvo
time-to-market
custo e benefcio
vida til do sistema
agenda de lanamento
6.4.1 Mercado-alvo
O arquiteto s capaz de priorizar os atributos de qualidade
em seu design se conhecer o pblico e o mercado para o qual
o software est sendo construdo. Por exemplo, portabilidade
e funcionalidade so buscados para o pblico geral de um pacote de aplicativos de escritrio e, portanto, priorizados neste
caso. Por outro lado, ao se construir um sistema de infraestrutura para uma empresa especca, o arquiteto pode priorizar
a ecincia em detrimento da portabilidade e at mesmo da
usabilidade, uma vez que os usurios comuns desse sistema so
operadores qualicados.

161
6.4.2
Time-to-market
Time-to-market o tempo entre a concepo do software e

sua entrega no mercado.
Esse atributo se torna importante,
principalmente, quando a janela de oportunidade pequena

devido a produtos concorrentes. O time-to-market inuencia
e, quando curto, prioriza decises de compra e reuso de mdulos em detrimento do desenvolvimento in house ou de investimento em decises que dizem respeito a atributos considerados
secundrios ao negcio.
6.4.3 Custo e benefcio

Como os recursos nanceiros para se desenvolver o software so
limitados, cada deciso arquitetural deve ter seu custo e o benefcio proporcionado analisados e, com base nessa anlise, priorizados ou at mesmo descartados. Essa anlise deve levar em
conta o ambiente de desenvolvimento em questo: capacidades
do time de desenvolvimento, ferramentas disponveis para o
reuso e os objetivos do software.
6.4.4 Vida til

O design de sistemas de grande vida til deve priorizar diferentes atributos de qualidade se os compararmos com o design
de sistemas de vida mais curta, como prottipos. No primeiro
tipo de sistemas, atributos de manutenibilidade e portabilidade
so mais valorizados; no segundo, so priorizados atributos de
ecincia e funcionalidade.
6.4.5 Agenda de lanamento

O design do software muito dependente de como ele vai ser
disponibilizado a pblico.
Por exemplo, se o software ser
disponibilizado em fases distintas que englobaro diferentes

CHAPTER 6.
162
ATRIBUTOS DE
QUALIDADE
conjuntos de funcionalidades, ele deve ser dividido de modo que

funcione sem as partes que ainda no foram disponibilizadas,
mas que tambm facilite tanto a modicabilidade, uma vez
que desejvel que novas funcionalidades sejam adicionadas
com menor esforo, quanto a interoperabilidade entre diferentes verses, que eventualmente ocorrer.
J se o software
ser disponibilizado sem possibilidade de posterior atualizao,

como acontece em muitos sistemas embarcados, preocupaes
de modicabilidade e interoperabilidade entre verses podem
ser descartadas.
6.5 Design Arquitetural para Qualidade

de Software
A principal responsabilidade do arquiteto a de conceber o
design que possibilite ao software ser construdo de modo que
satisfaa os requisitos de qualidade impostos pelos stakeholders. Para que o processo de design arquitetural tenha sucesso,
essencial que o arquiteto conhea os objetivos do software,
ou seja, conhea os requisitos funcionais e de qualidade para
os quais ele est projetando.
Alm disso, ele deve conhecer
tanto as tcnicas e prticas de design arquitetural que podem

ajud-lo na concepo da arquitetura. Ele deve tambm conhecer como documentar a arquitetura projetada, uma vez que
preciso comunic-la aos outros membros do time de desenvolvimento.
Neste captulo, ns aprendemos sobre os objetivos que devem
ser alcanados pelo design da arquitetura e esperamos que o
leitor agora seja capaz de:
Identicar o que so atributos de qualidade e qual sua

inuncia na arquitetura de software;

163
Relacionar atributos de qualidade com algumas decises

arquiteturais que os proporcionam; e
Entender quais os atributos de qualidade se relacionam

e como eles se relacionam.
A seguir, apresentaremos tcnicas e prticas de design que o

arquiteto deve conhecer para projetar sistemas com determinados atributos de qualidade.
Por m, no captulo seguinte,
apresentaremos como documentar o design arquitetural.
6.6 Referncias
6.6.1 Requisitos funcionais e no-funcionais
Os livros Software Engineering [100], de Sommerville, Requirements Engineering:
Processes and Techniques [58], de Som-
merville e Kotonya, Software Engineering:
A Practitioner's
Approach [86], de Pressman, dedicam alguns captulos a este

assunto. No entanto, o foco desses livros no papel dos requisitos de software no processo de desenvolvimento. J o artigo
Dening Non-Functional Requirements [70], de Malan e Bredemeyer, mais voltado inuncia dos requisitos na arquitetura.
6.6.2 Diferenas entre requisitos funcionais e

no-funcionais
A discusso sobre a inexistncia de diferenas prticas entre requisitos funcionais e no-funcionais pode ser encontrada
tanto no livro Requirements Engineering: Processes and Techniques [58], de Sommerville e Kotonya, quanto no artigo Distinctions Between Requirements Specication and Design of
Real-Time Systems [56], de Kalinsky e Ready, e no livro RealTime Systems:
Design Principles for Distributed Embedded

CHAPTER 6.
164
ATRIBUTOS DE
QUALIDADE
Applications [57], de Kopetz.
Essa discusso se mostra bas-
tante presente em sistemas de tempo-real porque os requisitos

de desempenho denem a funcionalidade desses sistemas ao
contrrio do que encontramos, por exemplo, em sistemas de informao, onde os requisitos de desempenho so considerados
requisitos no-funcionais.
6.6.3 Atributos de Qualidade

Bass et al, no livro Software Architecture in Practice [11],
mostra o papel dos atributos de qualidade na arquitetura de
software.
Alm dele, Gorton faz uma pequena introduo a
este assunto ao tratar do estudo de caso presente em Essential

Software Architecture [48].
Os livros Software Systems Ar-
chitecture [90], de Rozanski e Woods, e Code Complete [73],

de Steve McConnell, tambm dedicam sees aos atributos de
qualidade de software, sendo o primeiro em nvel de design
arquitetural e o segundo em nvel de design detalhado.
6.6.4 Atributos de Negcio

Por m, podemos encontrar informaes sobre atributos de
qualidade de negcio nos livros Software Architecture in Practice [11], de Bass et al, e Beyond Software Architecture [52],
de Hohmann.

Chapter 7
Tcnicas de Design
Arquitetural
1
Ao introduzirmos design de software, citamos alguns princpios

e tcnicas que so fundamentais ao processo, pois facilitam a
representao e a escolha da soluo entre as alternativas de
design.
No entanto, no fomos explcitos sobre como estes
princpios e tcnicas so fundamentais ao processo de design

arquitetural. J no captulo sobre atributos de qualidade, mencionamos a existncia de tticas arquiteturais que ajudam na
implementao de alguns requisitos de qualidade, mas no apresentamos essas tticas a no ser de forma breve e apenas por
meio de exemplos.
Este captulo, por sua vez, tem como objetivo tanto apresentar
os princpios de design em nvel arquitetural, quanto apresentar
algumas tticas arquiteturais que implementam requisitos de
qualidade. Neste captulo, descrevemos os seguintes princpios
de design arquitetural:
uso da abstrao ou nveis de complexidade;
1 This
content
is
available
165
online
at
CHAPTER 7.
166
TCNICAS DE DESIGN
ARQUITETURAL
separao de preocupaes; e
uso de padres e estilos arquiteturais.
Em relao s tticas arquiteturais, apresentamos as que implementam os seguintes atributos de qualidade:
desempenho e escalabilidade;
segurana;
tolerncia a faltas;
compreensibilidade e modicabilidade; e
operabilidade.
7.1 Princpios e Tcnicas de Design Arquitetural

H alguns princpios e tcnicas que, quando aplicados, geralmente resultam em boas solues de design. Entre eles, podemos citar:
diviso e conquista, abstrao, encapsulamento,
modularizao, separao de preocupaes, acoplamento e coeso, separao de interfaces de suas implementaes, entre
outros. Inclusive, muitos destes j foram apresentados no captulo sobre Design, mas sem o devido foco em design arquitetural. Por isso, nesta seo, descrevemos novamente alguns deles,
desta vez mostrando seu papel na arquitetura. Os princpios e
tcnicas que apresentamos a seguir so trs: uso da abstrao
ou nveis de complexidade, separao de preocupaes e uso de
padres e estilos arquiteturais.
7.1.1 Abstrao
Abstrao a seleo de um conjunto de conceitos que representam um todo mais complexo.
Por ser um modelo do
software, a arquitetura j elimina, ou em outras palavras, abstrai naturalmente alguns detalhes do software. Por exemplo,
167
comum que no tenhamos decises em nvel algortmico na

arquitetura. Mesmo assim, podemos tirar proveito do uso de
nveis de detalhe (ou de abstrao) ao projet-la.
Podemos nos beneciar do uso da abstrao ao realizarmos o
processo de design de forma iterativa, onde cada passo realizado em um nvel de detalhe. De forma simplicada, podemos
dizer que a sequncia de passos pode ocorrer seguindo duas estratgias de acordo com os nveis de abstrao do software.
A primeira estratgia a top-down (do nvel mais alto de
abstrao para o mais baixo).
Se o design ocorre no sen-
tido top-down, o arquiteto usa elementos e relaes arquiteturais descritos em alto nvel de abstrao para iniciar o projeto da arquitetura.
No primeiro nvel de abstrao, o mais
alto, comum que os elementos arquiteturais usados no projeto mostrem apenas o que realizam e no como realizam suas
responsabilidades.
A partir da, a cada passo do processo, o
arquiteto segue renando o design, adicionando mais detalhes

aos elementos arquiteturais e s suas relaes, at que possuam
informaes sobre como realizar suas responsabilidades. Neste
ponto, comum termos elementos arquiteturais que realizam
funes e servios mais bsicos ou de infraestrutura e que, eventualmente, faro parte da composio das funcionalidades em
nveis mais altos.
Um problema recorrente ao se aplicar a estratgia top-down o
de quando parar. Anal, podemos notar que o arquiteto poderia seguir indenidamente adicionando detalhes arquitetura
at que o design deixe de ser um modelo para ser o prprio sistema. Para denir o ponto de parada do processo de adio de
detalhes, o arquiteto deve avaliar se o nvel atual de abstrao
contm ou no informaes sucientes para guiar o time de desenvolvimento na implementao dos requisitos de qualidade
do software. Devemos ainda observar que os dois extremos da

168
CHAPTER 7.
TCNICAS DE DESIGN
ARQUITETURAL
condio de parada podem trazer desvantagens: se as informaes presentes na arquitetura so insucientes, a liberdade
proporcionada ao design de baixo nvel pode resultar numa
soluo que no implementa os requisitos de qualidade esperados. Por outro lado, se so excessivas, a arquitetura pode: (1)
custar mais tempo do que o disponvel para ser projetada; (2)
desmotivar o time de desenvolvimento, por engessar o design
de baixo nvel pela grande quantidade de restries; e (3) ser
invivel, por ter sido projetada sem o conhecimento que muitas
vezes s pode ser obtido durante o processo de implementao .

A outra estratgia, mais usada por quem possui experincia no
domnio do problema, a bottom-up. Esta estratgia consiste
em denir elementos arquiteturais bsicos e com maior nvel de
detalhe (servios ou funes de infraestrutura, por exemplo),
e compor servios presentes em maiores nveis de abstrao a
partir desses elementos. A experincia no domnio do problema
necessria justamente na denio dos elementos mais detalhados, ou seja, experincia necessria para denir o nvel de
abstrao mais baixo que servir de ponto de partida do processo de design. Nesta estratgia, detalhes excessivos ou insucientes no nvel mais baixo de abstrao trazem as mesmas
desvantagens j apresentadas quando falamos sobre o ponto de
parada da estratgia top-down.
7.1.2 Separao de preocupaes

A separao de preocupaes a diviso do design em partes
idealmente independentes. Entre estas partes, podemos citar
aspectos funcionais e no-funcionais do sistema. Os aspectos
funcionais, como de se esperar, so o que o sistema capaz
2 Devemos nos lembrar que alguns requisitos de qualidade no so completamente conhecidos em etapas iniciais do ciclo de desenvolvimento. Por
exemplo, a tolerncia a faltas ou o tempo de recuperao podem ser muito
dependentes da soluo de design de baixo nvel.

169
de fazer. J os no-funcionais so os aspectos de qualidade do

sistema, como desempenho, segurana, monitorao, etc.
separao dos diferentes aspectos permite que cada uma das

partes seja um problema de design a ser resolvido de forma
independente, permitindo maior controle intelectual por parte
do arquiteto, uma vez que agora ele s precisa se focar em um
aspecto da arquitetura de cada vez.
Vale observar que a separao completa das diferentes preocupaes (ou dos diferentes aspectos) da arquitetura do software
o caso timo da aplicao deste princpio, mas no o caso comum. Isto ocorre porque, como j vimos anteriormente, diferentes funcionalidades e qualidades do software se relacionam
entre si. Portanto, apesar de ser vantajoso pensar na soluo
de design de cada aspecto separadamente, o arquiteto deve
tambm projetar a integrao desses aspectos. Esta integrao
fundamental por dois motivos. O primeiro, mais bvio, que
o software composto por seus aspectos trabalhando em conjunto e no separadamente.
J o segundo motivo que a
prpria integrao inuencia nas diferentes solues de design

dos aspectos do software. Por exemplo, aspectos de armazenamento devem estar de acordo com aspectos de segurana do
software, ou aspectos de desempenho devem trabalhar em conjunto com aspectos de comunicao ou mesmo localizao dos
elementos da arquitetura.
7.1.3 Padres e estilos arquiteturais

Outro princpio muito usado durante o processo de design arquitetural o uso de padres. Os padres podem ser considerados como experincia estruturada de design, pronta para ser
reusada para solucionar problemas recorrentes. Um padro de
design arquitetural dene elementos, relaes e regras a serem
seguidas que j tiveram sua utilidade avaliada em solues de
problemas passados.
CHAPTER 7.
170
TCNICAS DE DESIGN
ARQUITETURAL
A principal diferena entre um padro arquitetural
e um
padro de design que o primeiro lida com problemas em nvel

arquitetural, se tornando assim mais abrangente no software.
Por outro lado, a aplicao de um padro de design tem efeito
mais restrito na soluo. Mais uma vez, devemos lembrar que
essa diviso no absoluta e que podemos encontrar padres
inicialmente descritos como arquiteturais tendo efeito apenas
local no design e vice-versa.
De acordo com McConnell no livro Code Complete , podemos

citar os seguintes benefcios do uso de padres em um projeto:
Padres reduzem a complexidade da soluo ao prover

abstraes reusveis.
Um padro arquitetural j dene
elementos, servios e relaes arquiteturais, diminuindo

assim a quantidade de novos conceitos que devem ser
introduzidos soluo.
Padres promovem o reuso. Como padres arquiteturais

so solues de design para problemas recorrentes, possvel que a implementao (parcial ou total) do padro
j esteja disponvel para reuso, facilitando o desenvolvimento.
Padres facilitam a gerao de alternativas. Mais de um

padro arquitetural pode resolver o mesmo problema, s
que de forma diferente.
Portanto, conhecendo diversos
padres, um arquiteto pode avaliar e escolher qual ou

quais padres iro compor a soluo do problema, considerando os benefcios e analisando as desvantagens proporcionadas por eles.
Padres facilitam a comunicao.
Padres arquitetu-
rais facilitam a comunicao da arquitetura porque descrevem conceitos e elementos que estaro presentes no
3 Tambm chamado de estilo arquitetural.

4 McConnell, S. Code Complete. Microsoft Press, Segunda edio,
Junho 2004.

171
design.
Portanto, se uma soluo de design contm
padres que so conhecidos por todos os participantes

da comunicao, os elementos e conceitos denidos pelos
padres no precisam ser explicitados, uma vez que os
participantes j devem conhec-los tambm.
A seguir, citamos alguns padres arquiteturais que foram pop-
ularizados no livro Pattern-Oriented Software Architecture ,

de Buschmann et al:
Layers (ou Camadas)::
este padro dene a organizao
do software em servios agrupados em camadas de ab-
strao. As camadas so relacionadas de modo que cada

uma s deve se comunicar com a camada adjacente acima
ou abaixo dela.
Se apresentamos gracamente as ca-
madas empilhadas, as camadas dos nveis superiores apresentam um nvel de abstrao maior, mais prximas
aos servios disponveis aos usurios. Enquanto isso, nas
camadas inferiores, temos servios mais bsicos, normalmente de infraestrutura, e que servem para compor os
servios de camadas mais acima. Como exemplo de arquitetura que usa este padro, podemos citar a arquitetura da pilha de protocolos TCP/IP. Ela organizada em
cinco camadas, sendo elas: Aplicao, Transporte, Rede,
Enlace e Fsica.
Pipes & Filters::
este padro organiza o software para pro-
cessar uxos de dados em vrias etapas.

tos bsicos so denidos:
Dois elemen-
os chamados lters, que so
os elementos responsveis por uma etapa do uxo de

processamento; e os chamados pipes, que so os canais
de comunicao entre dois lters adjacentes.
Note que
a arquitetura pode conter diferentes pipes e lters, de
5 Buschmann, F.
et al, Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. John Wiley & Sons, Agosto 1996.
CHAPTER 7.
172
TCNICAS DE DESIGN
ARQUITETURAL
modo que possam reusados e recombinados para diferentes propsitos. O exemplo cannico de uso do padro
Pipes & Filters a arquitetura de um compilador, que
pode ser dividida nos seguintes lters:
analisador lx-
ico, analisador sinttico, analisador semntico, gerador

de cdigo intermedirio e otimizador, que so conectados por diferentes pipes. Entre eles, encontramos o pipe
que conecta o analisador lxico ao sinttico e que transmite um uxo de tokens; o pipe que transporta a rvore de derivao sinttica do analisador sinttico para o
analisador semntico; o pipe que transporta a rvore de
sintaxe do analisador semntico para o gerador de cdigo
intermedirio; e, por m, o pipe que conecta o gerador
de cdigo intermedirio ao otimizador.
Model-View-Controller ::
este padro, por sua vez, divide
a arquitetura em trs elementos distintos:
a lgica de
negcio (ou model), que representa as funcionalidades e

os dados do sistema; vises (ou views), que representam a
forma de exibir o estado da lgica de negcio ao usurio;
e os controladores (ou controllers), que so responsveis
pela entrada de dados dos usurios. O padro tambm
dene que deve existir um mecanismo de propagao de
mudanas, de forma que a interface com o usurio (composta das vises e dos respectivos controladores) se mantenha consistente com a lgica de negcio. Este padro
comum em sistemas interativos e foi tambm popularizado em sistemas web por meio de frameworks, a exem-
plo de JSF , Struts
6 JavaServer
e Spring MVC .
Faces
Technology
(JSF):
http://java.sun.com/javaee/javaserverfaces/
(<http://java.sun.com/javaee/javaserverfaces/>)
7 Apache
Struts :
http://struts.apache.org/
(<http://struts.apache.org/>)
8 Spring
Framework :
http://www.springsource.org/
(<http://www.springsource.org/>)

173
Microkernel::
este padro a base de arquiteturas exten-
sveis orientadas a plugins.
Ele dene um elemento
arquitetural que ser o ncleo do sistema e elementos

chamados pontos de extenso. Este ncleo prov servios
de infraestrutura para compor as funcionalidades mais
bsicas do sistema e um servio de registro e congurao de componentes em tempo de execuo. O servio
de registro e congurao tem como responsabilidade a
adio de novas funcionalidades a partir dos pontos de
extenso pr-denidos. Estes pontos de extenso servem
para guiar e restringir os tipos de funcionalidades a serem
adicionadas. Como exemplo de aplicao do padro Mi-
crokernel, podemos citar o sistema operacional MINIX ,

o ambiente de desenvolvimento Eclipse
10
e diversos sis-
temas de manipulao de imagens que so extensveis por

meio de plugins, como o GIMP
11
e o ImageJ
12
7.2 Tticas de Design

Por meio da aplicao de padres, somos capazes de reusar a
experincia de outros projetistas por meio de solues estruturadas de design.
No entanto, h outra forma de reuso de
experincia de design e que no propriamente denida como

padres.
Esta forma chamada de ttica de design e, ape-
sar de cada ttica ter objetivos bem denidos, seu contedo

menos estruturado, normalmente contendo apenas ideias ou
dicas de projeto que ajudam na implementao de atributos
de qualidade. A principal diferena entre tticas e padres de
9 MINIX : http://www.minix3.org/ (<http://www.minix3.org/>)
10 Eclipse : http://www.eclipse.org (<http://www.eclipse.org/>)

11 The
GNU
Image
Manipulation
Program
(GIMP):
http://www.gimp.org (<http://www.gimp.org>)
12 ImageJ
Image
Processing
and
Analysis
http://rsbweb.nih.gov/ij/ (<http://rsbweb.nih.gov/ij/>)

in
Java:
CHAPTER 7.
174
TCNICAS DE DESIGN
ARQUITETURAL
design que, ao contrrio dos padres, as tticas no necessariamente descrevem elementos arquiteturais que devem existir na soluo. Desta maneira, responsabilidade do arquiteto
deni-los de forma a seguir as dicas contidas nas tticas.
Ao aplicar as tticas ao design, assim como durante a aplicao
de padres, o arquiteto deve tambm considerar os trade-os
existentes:
por um lado, uma ttica pode aumentar o grau
de atendimento a um atributo de qualidade, mas, por outro

lado, pode afetar negativamente outros atributos.
Por isso,
para facilitar a avaliao dos trade-os durante o design, apresentaremos algumas tticas de acordo com as qualidades que
elas implementam, mas tambm seremos explcitos sobre o que
afetado negativamente.
A seguir, apresentamos tticas de design de acordo com os
seguintes atributos de qualidade:
segurana;
tolerncia a faltas;
operabilidade.
7.2.1 Desempenho e escalabilidade

Para melhorar desempenho de uma aplicao ou facilitar a
adio de recursos computacionais para atender a uma maior
demanda, podemos citar as seguintes tticas arquiteturais.
7.2.1.1 No mantenha estado

Se os elementos da arquitetura so projetados de forma a no
manter estado (stateless), ou seja, que eles sejam capazes de
realizar suas funes apenas com os parmetros presentes nas
175
requisies, ca mais fcil replic-los para dividir a carga de

requisies entre as rplicas.
Basta apenas que seja denido
uma balanceador de carga para distribuir as chamadas entre

estes elementos. Note que se a demanda aumenta, pode-se tambm aumentar o nmero de elementos stateless para suprimir
a demanda sem muito esforo. Basta ento informar ao balanceador sobre os novos elementos para que ele os considere
na distribuio de novas requisies.
importante observar que nem todos os elementos arquiteturais podem ser stateless. Por exemplo, elementos de dados
essencialmente mantm estado (e, portanto, so stateful). Assim, possvel que, em algum ponto da arquitetura, os diversos
elementos stateless precisem de dados ausentes nos parmetros das requisies e portanto tero que fazer novas requisies
aos elementos stateful.
Se os elementos que mantm estado
no forem capazes de responder a esta carga de novas requisies, eles se tornaro o gargalo da arquitetura, prejudicando
o desempenho de todo o sistema.
7.2.1.2 Partio de dados

Para melhorar o desempenho e a escalabilidade de elementos
de dados, podemos dividir o conjunto de dados entre elementos de execuo. Cada um destes elementos que possui parte
dos dados chamado de partio (ou shard). H duas tcnicas de partio de dados que merecem ser citadas: a partio
horizontal e a partio vertical.
Primeiro, vamos apresentar a partio horizontal por meio de
um exemplo. Se pensamos em dados relacionais, que esto organizados em linhas e colunas, a partio horizontal a diviso
em grupos de linhas entre os elementos arquiteturais de dados
em execuo. Por exemplo, se temos um banco de dados com
dois milhes de usurios e temos dois servidores, A e B, execu-

CHAPTER 7.
176
TCNICAS DE DESIGN
ARQUITETURAL
tando esse banco de dados, os usurios com ndices de zero a

um milho devem estar localizados no servidor A e o restante
dos usurios devem estar localizados no servidor B. A partir
desta diviso, para um cliente do banco de dados encontrar
as informaes de um dado usurio, agora ele deve ser capaz
de localizar em qual servidor os dados esto de acordo com o
ndice que procura.
Note que isso uma forma de dividir a
carga de requisies entre elementos de execuo, mesmo usando elementos stateful.

J a partio vertical consiste na seleo de algumas colunas
do modelo de dados para serem servidas por elementos de execuo diferentes.
Assim, se temos novamente os servidores
A e B, informaes sobre todos os usurios esto em ambos

os servidores. No entanto, informaes mais requisitadas (por
exemplo, nome do usurio e grupo de permisses o qual ele
pertence no sistema) podem ser encontradas no servidor A,
que dispe de hardware melhor, enquanto informaes menos
requisitadas podem ser encontradas no servidor B. Da mesma
forma que no caso anterior, o cliente deve ser capaz de localizar
em qual servidor os dados esto. S que agora, a localizao
feita de acordo com o tipo de dados requisitados e no o seu
ndice.
7.2.1.3
Caching
Em um sistema, existem algumas informaes que so mais

requisitadas que outras.
Por exemplo, a pgina de algum
muito popular numa rede social ou as notcias de primeira

pgina de um portal de notcias.
Portanto, podemos nos
aproveitar desta caracterstica ao projetar sistemas.

Se algumas informaes so muito mais requisitadas que outras, o desempenho aparente de um sistema pode ser melhorado
se conseguirmos servir essas informaes com melhor desem-

177
penho. Uma forma de conseguir isso usando um cache. Um

cache um elemento arquitetural capaz de servir informaes
com maior desempenho do que o elemento de dados que guarda
essas informaes originalmente.
Portanto, ao requisitar al-
guns dados, o cliente pode primeiro requisitar ao cache. Caso o

cache possua os dados requisitados, eles sero retornados mais
rapidamente do que se o cliente tivesse requisitado apenas ao
elemento de dados original. No entanto, precisamos observar
que para desempenhar melhor do que os servidores de dados,
o cache normalmente armazena um conjunto limitado de dados. Esta limitao o obriga a implementar as chamadas polticas de caching, que so diferentes formas de comportamento
para maximizar a quantidade de acertos nas requisies de
disponibilidade de informao e manter a consistncia entre o
cache e o elemento de dados original.
7.2.1.4 Tticas de processamento

Entre as tticas de processamento para melhorar o desempenho
da aplicao (em oposio s tticas de dados vistas anteriormente: partio de dados e caching ), podemos citar: partio,
paralelizao e distribuio de processamento.
A partio de processamento a diviso do processamento entre elementos arquiteturais distintos para tirar proveito das
caractersticas de cada elemento de execuo do software. Um
exemplo simples distribuir um grande processamento de dados entre os elementos da arquiteturais mais prximos a esses
dados, com a nalidade de evitar ao mximo a transferncia
de arquivos. Assim, a caracterstica do elemento de execuo
procurada para realizar a distribuio se o elemento possui ou
no os dados necessrios para o processamento. Por exemplo,
se observarmos a arquitetura de um sistema de processamento
de grandes conjuntos de dados chamado MapReduce
13 A arquitetura do
MapReduce
13
(ou de
brevemente apresentada por Dean e

CHAPTER 7.
178
TCNICAS DE DESIGN
ARQUITETURAL
sua implementao open source, o Hadoop
14
), percebemos que
ele divide o processamento em tarefas menores e tenta associar cada tarefa ao processador que esteja mais prximo dos
dados necessrios. Com esta poltica de atribuio de tarefas,
o MapReduce consegue processar grandes massas de dados em
tempo relativamente pequeno.
J a paralelizao de processamento consiste em permitir que
linhas de execuo independentes, por exemplo, chamadas de
usurios diferentes em um sistema web, ocorram simultaneamente.
Essa paralelizao pode ser realizada de diferentes
maneiras:
em diferentes threads dentro de um mesmo pro-
cesso, em diferentes processos dentro de um mesmo sistema

operacional e em diferentes elementos de execuo de um sistema (tipicamente, em diferentes servidores). Esta paralelizao melhora o desempenho porque aumenta a vazo de respostas e pode utilizar recursos, inicialmente, ociosos.
Por m, h a distribuio de processamento ao longo do tempo.
Esta ttica consiste em permitir que algumas tarefas de processamento requisitadas pelo usurio no sejam executadas sincronamente e, portanto, no fazendo com que ele espere pelo
processamento de algo que no utilizar no momento. Assim,
aumentamos o desempenho aparente do software. Um exemplo de distribuio de processamento ao longo do tempo o de
tratamento de imagens em sistemas de redes sociais. Quando
um usurio faz o upload de uma imagem, essa imagem precisa
ser otimizada para ocupar menos espao de armazenamento
no sistema. No entanto, este tratamento no feito de forma
sncrona, ou seja, quando o usurio envia a imagem, mas sim
agendado para ser executado em algum momento no futuro.
Ghemawat no artigo
Clusters [34].
14 Apache
MapReduce: Simplied Data Processing on Large
Hadoop:
http://hadoop.apache.org/
(<http://hadoop.apache.org/>)

179
7.2.1.5 Menos camadas de abstrao

Apesar de projetar um sistema em diversas camadas de abstrao melhorar o reuso (pela possibilidade das camadas serem
reusadas), o entendimento (porque diferentes camadas representam diferentes nveis de abstrao, facilitando o controle
intelectual da complexidade) e at mesmo a testabilidade do
sistema (dado que as camadas podem ser desenvolvidas e testadas separadamente), a presena de muitas camadas em um
sistema pode prejudicar seu desempenho. Isto ocorre porque
quanto mais camadas de abstrao existem no design, principalmente se desnecessrias, mais recursos sero consumidos.
Entre os recursos consumidos, podemos citar a memria, uma
vez que mais camadas de implementao signicam mais camadas a serem carregadas durante a execuo, e mais ciclos de
processamento, para realizar a comunicao entre diferentes
camadas.
7.2.1.6 Desvantagens das tticas de desempenho e escalabilidade

Podemos observar que as tticas que acabamos de apresentar
aumentam a complexidade da arquitetura, uma vez que apresentam novos elementos tanto em nvel de design, quanto em
nvel de execuo. Em nvel de design, os novos elementos podem prejudicar a modicabilidade e a compreensibilidade do
software, dado que adicionam novas relaes e conceitos e at
sugerem a diminuio dos nveis de abstrao.
J em nvel
de execuo, novos elementos podem dicultar: a segurana,

porque agora os dados estaro ainda mais distribudos no sistema e mais entidades podero acess-los; a tolerncia a falhas,
porque podem surgir mais pontos nicos de falhas; e a operabilidade, considerando que os novos elementos de execuo
impem mais tarefas de congurao.

180
CHAPTER 7.
TCNICAS DE DESIGN
7.2.2 Segurana
ARQUITETURAL
Para implementar a segurana em um sistema de software, o

arquiteto deve conhecer, alm de tcnicas de autorizao, autenticao, criptograa e auditabilidade, os seguintes princpios.
7.2.2.1 Princpio do menor privilgio

O princpio do menor privilgio consiste em garantir ao usurio,
cliente do software ou mdulo do sistema apenas os privilgios
necessrios para que sejam capazes de concluir suas tarefas.
Assim, caso este usurio, cliente ou mdulo sejam comprometidos (passem a se comportar de forma nociva ao sistema),
a quantidade de dano que podero causar ao sistema ser limitada.
7.2.2.2 Princpio da falha com segurana

O princpio de falha com segurana (fail-safe) o de garantir
que em caso de qualquer problema, seja de comunicao, autenticao ou falta em um servio, o comportamento padro seja
um comportamento seguro. Por exemplo, se um usurio com
privilgios de acesso tenta ler um arquivo privado e o sistema de
autorizao est indisponvel, o comportamento padro do sistema de leitura deve ser o de negar o acesso ao arquivo. Dessa
maneira, mesmo que usurios autorizados sejam privados do
acesso aos seus arquivos, os no-autorizados no conseguiro
acesso indevido. O mesmo princpio deve ser aplicado, por exemplo, em sistemas de controle de trfego. Se os indicadores
de estado dos semforos esto com problemas, os semforos devem falhar no estado pare, uma vez que fazer com que todos
os veculos parem nas vias de um cruzamento mais seguro do
que fazer com que mais de uma via seja indicada para seguir.

181
7.2.2.3 Princpio da defesa em profundidade

O princpio da defesa em profundidade sugere que a arquitetura deve aplicar diferentes tcnicas de segurana em diferentes nveis do software. Por exemplo, um cliente autenticado
do software deve no s ser autorizado a chamar uma funo,
mas a funo chamada deve tambm ser autorizada a acessar
as informaes necessrias para o dado cliente.
Esta tcnica
tanto permite que medidas de segurana mais especcas ao

contexto possam ser utilizadas, quanto permite manter a segurana do software mesmo durante a falha de alguma medida
de segurana adotada.
7.2.2.4 Desvantagens das tticas de segurana

Podemos observar que, assim como as tticas de desempenho
e escalabilidade, as tticas de segurana aumentam a complexidade da arquitetura.
Isto ocorre porque tambm adicionam
novos elementos arquiteturais soluo. Estes novos elementos, por serem novos conceitos, prejudicam a compreensibilidade do sistema em tempo de design e a operabilidade durante
a execuo. Alm disso, as tticas de segurana tambm requerem a execuo de passos adicionais de processamento (por
exemplo, criptografar uma mensagem ou checar se senha inserida vlida), o que prejudica o desempenho da aplicao.
7.2.3 Tolerncia a Faltas

A rea de sistemas distribudos contribui com muitas tcnicas
que podem ser aplicadas arquitetura para que os sistemas
sejam projetados para serem mais tolerantes a faltas.
estas tcnicas, podemos citar as seguintes.

Entre
CHAPTER 7.
182
TCNICAS DE DESIGN
ARQUITETURAL
7.2.3.1 Evitar ponto nico de falhas

Se muitas funcionalidades dependem de apenas um servio que
executa em apenas um recurso computacional, todo o sistema
estar comprometido se esse nico servio falhar. Este nico
servio ou recurso computacional no qual o sistema depende
o que chamamos de ponto nico de falhas. Portanto, para que
o software no seja completamente dependente de um nico elemento, o arquiteto deve se preocupar em evitar os pontos nicos de falhas a partir do design. Para isso, ele pode distribuir
responsabilidades entre diferentes elementos da arquitetura ou
mesmo replicar processamento, de forma que o ponto nico
seja eliminado.
7.2.3.2 Partio de dados

J mostramos que a partio de dados benca para o desempenho e a escalabilidade do sistema. No entanto, ao particionarmos os dados por diversos elementos de armazenamento,
distribumos tambm as responsabilidades do servidor de dados. Portanto, se um dos elementos de armazenamento falha,
ainda podemos ter o sistema disponvel para parte dos usurios
(aqueles os quais as informaes ainda esto disponveis por
meio dos elementos de armazenamento que no falharam).
7.2.3.3 Partio e distribuio de processamento

Obtemos benefcios semelhantes aos de particionar os dados
quando particionamos e distribumos processamento por diferentes elementos da arquitetura.
Diferentes responsabilidades
atribudas a diferentes elementos da arquitetura permitem que

o software continue funcionando, mesmo que parcialmente, em
caso de faltas.
Alm disso, quando usamos processamento sncrono, amarramos a conabilidade no processamento aos dois ou mais elAvailable for free at Connexions
183
ementos que esto relacionados sincronamente. Por exemplo,

se o elemento A realiza uma funo que precisa chamar uma
funo sncrona no elemento B, a funo de A s ser executada
com sucesso caso B tambm esteja disponvel. No entanto, se a
chamada a B for assncrona, a funo chamada em A pode ser
executada com sucesso mesmo que B esteja indisponvel temporariamente. Dessa maneira, assim que B estiver novamente
disponvel, sua funo poder ser executada.
7.2.3.4 Redundncia
No s podemos distribuir diferentes responsabilidades de processamento a diferentes elementos da arquitetura, como tambm podemos atribuir a mesma responsabilidade a diferentes
elementos.
Assim, durante a execuo, em caso de qualquer
problema com um dos responsveis, outro pode assumir seu lugar e retornar corretamente a resposta. Isso o que chamamos
de atribuir redundncia a alguns elementos da arquitetura, sejam elementos de dados ou de processamento. Vale observar
que no basta apenas replicar a responsabilidade do elemento
em questo, mas decidir (1) se o elemento redundante car
sempre ativo ou apenas entrar em execuo quando a falha
do original for identicada, (2) como as falhas sero identicadas durante a execuo e (3) como os clientes do elemento
que falhou redirecionaro suas chamadas para o elemento redundante.
7.2.3.5 Desvantagens das tticas de tolerncia a faltas

Como as tticas de tolerncia a faltas se aproveitam de algumas
tticas de desempenho e escalabilidade, elas proporcionam as
mesmas desvantagens em relao compreensibilidade, modicabilidade e operabilidade, uma vez que aumentam a complexidade da soluo de design.

CHAPTER 7.
184
TCNICAS DE DESIGN
ARQUITETURAL
7.2.4 Compreensibilidade e Modicabilidade
Algumas tcnicas que aumentam a compreensibilidade e a

modicabilidade da arquitetura j foram mencionadas anteriormente:
uso de camadas de abstrao;

separao de preocupaes;
aplicao de padres;
alta coeso e baixo acoplamento.
No entanto, no discutimos as desvantagens comuns a essas

tcnicas.
Por ser comum que ambos os atributos sejam al-
canados por meio da abstrao de detalhes e que a abstrao

leva adio de novas camadas de implementao, podemos
notar que as tcnicas mencionadas anteriormente necessitam de
mais recursos computacionais para a execuo, afetando negativamente o desempenho. No entanto, ao termos processadores
e canais de dados cada vez mais rpidos, alm de memria e sistemas de armazenamento cada vez mais baratos, o efeito negativo causado por essas tcnicas pode ser irrisrio comparado
ao benefcio da compreensibilidade e da modicabilidade no
processo de desenvolvimento.
7.2.5 Operabilidade
Por m, para proporcionar operabilidade ao sistema de software, o arquiteto deve aplicar as seguintes tcnicas durante o
design da arquitetura.
7.2.5.1 Monitorao e anlise do estado do sistema

O operador s capaz de agir sobre o software, se ele possuir informaes sobre seu estado interno.
Para isso, van-
tajoso que a arquitetura permita a monitorao do estado de

seus elementos mais importantes durante a execuo. Note que
185
em um grande sistema, o conjunto de elementos monitorados

pode ser grande, gerando assim uma grande massa de dados
de monitorao. Portanto, a monitorao pode ser tornar um
problema, uma vez que a gerao e o consumo dos dados pode
necessitar de muitos recursos computacionais (canal de comunicao, caso os dados sejam transferidos entre elementos do
sistema, e armazenamento, caso os dados sejam armazenados, e
processamento, para extrair informaes dos dados). Portanto,
a arquitetura deve proporcionar meios de gerao e anlise dos
dados de monitorao, mas deve tambm implementar meios
de agregao e compactao dos dados de forma que poupem
o consumo de recursos computacionais.
7.2.5.2 Computao autonmica

Uma forma ainda mais eciente de proporcionar operabilidade
ao software a de delegar tarefas que antes seriam de responsabilidade do operador ao prprio software. Portanto, permitir
que o software seja capaz de pr ou retirar de execuo servidores, realizar backups, ou realizar outras atividades para a
melhoria da qualidade de servio. Realizar automaticamente
estas e outras atividades baseadas apenas no estado atual do
sistema e sem interveno humana o que chamamos de computao autonmica.
Para permitir a adio de aspectos de
computao autonmica ao software, sua arquitetura deve estar preparada de forma que dados sobre o estado atual do
sistema no sejam apenas coletados, mas tambm sejam analisados automaticamente e os resultados dessa anlise sejam
capaz de ativar automaticamente tarefas de administrao do
sistema.
7.2.5.3 Desvantagens das tcnicas de operabilidade

Como j mencionamos anteriormente,
a monitorao e a
anlise do estado atual do sistema podem consumir muitos re-

CHAPTER 7.
186
TCNICAS DE DESIGN
ARQUITETURAL
cursos computacionais, impactando negativamente no desempenho.
Por outro lado, ao possibilitarmos a anlise do soft-
ware em tempo de execuo, podemos identicar problemas

inicialmente desconhecidos na arquitetura, como gargalos de
desempenho ou pontos nicos de falhas. Com estes problemas
identicados, o arquiteto pode ento corrigi-los na arquitetura,
melhorando assim o desempenho e a tolerncia a faltas do software.
7.3 Resumo
Este captulo exps o que um arquiteto deve saber em relao
s tcnicas e princpios de design arquitetural.
Devemos ad-
mitir que seu objetivo ambicioso, uma vez que que existem
muitos livros e artigos de Design de Software sobre o mesmo
assunto. No entanto, a maioria dos livros e artigos disponveis
no so explicitamente escritos sobre Arquitetura de Software
ou no tm como pblico-alvo o leitor ainda inexperiente. Da
nossa tentativa de preencher esta lacuna.
Ao nal deste captulo, esperamos que o leitor conhea os
seguintes princpios de design arquitetural:
uso da abstrao ou nveis de complexidade;

separao de preocupaes; e
uso de padres e estilos arquiteturais.
Mas, alm disso, esperamos que o leitor tambm reconhea

algumas tticas que implementam os seguintes atributos de
qualidade:
segurana;
tolerncia a faltas;
187
operabilidade.
Para informaes mais detalhadas sobre os princpios e tcnicas

apresentados, deixamos uma lista de referncias para estudos
posteriores.
7.4 Referncias
7.4.1 Abstrao e separao de preocupaes
Sobre os benefcios e aplicao da abstrao e separao de
preocupaes no design de software, recomendamos a leitura do
livro Code Complete[74], de McConnell. Alm dele, podemos
citar os seguintes artigos sobre o assunto: The Structure of The
THE-multiprogramming System[37], de Dijkstra, e o On The
Criteria to Be Used in Decomposing Systems Into Modules[81],
de Parnas.
7.4.2 Padres e estilos arquiteturais

H diversos padres e estilos arquiteturais, inclusive catalogados de acordo com seus objetivos.
Apesar de termos citado
apenas quatro padres que foram inicialmente descritos por

Buschmann, existem muito mais padres descritos por este autor e outros autores na srie de livros Pattern-Oriented Software Architecture[27], [95], [24], [25]. Recomendamos tambm
sobre o assunto os livros Patterns of Enterprise Application
Architecture[44], escrito por Fowler, e o Software Architecture
in Practice[12], escrito por Bass et al.
7.4.3 Tcnicas arquiteturais

Sobre tcnicas arquiteturais, podemos citar o livro Beautiful
Architecture[101], editado por Spinellis e Gousios. Ele mostra

CHAPTER 7.
188
TCNICAS DE DESIGN
ARQUITETURAL
na prtica a aplicao de diversas tcnicas para o alcance de

requisitos de qualidade por meio do design arquitetural. Sendo
menos prtico, porm mais abrangente na exposio de tcnicas arquiteturais, podemos citar tanto o livro Software Architecture: Foundations, Theory, and Practice[103], de Taylor et
al, quanto o livro Software Systems Architecture[91], de Rozanski e Woods. O livro The Art of Systems Architecting [68], de
Maier e Rechtin, descreve poucas (porm valiosas) tcnicas de
arquitetura de software. Neste livro, as tcnicas so chamadas
de heursticas.
Podemos ainda mencionar alguns artigos sobre desempenho
de software em geral:
Performance Anti-Patterns[96],
Smaalders; sobre replicao de dados:
de
Optimistic Replica-
tion[94], de Saito e Shapiro; e sobre segurana: In Search of

Architectural Patterns for Software Security [93], de Ryoo et
al.
Por m, mencionamos dois blogs que contm muitas descries
de problemas arquiteturais reais e como foram resolvidos na
indstria: o HighScalability.com[49] e o Engineering @ Facebook[106].

Chapter 8
Documentao da
Arquitetura
1
Aps entendermos os conceitos e a importncia e termos noes

de design de arquitetura de software, precisamos saber como
capturar a informao do projeto e document-lo. Para isso,
introduzimos os conceitos de vises e de pontos de vista arquiteturais, que facilitam a documentao por mostrar diferentes dimenses que uma arquitetura apresenta. Este captulo
no dita uma nica linguagem ou modelo de documentao de
arquitetura, mas apresenta exemplos de como faz-lo.
Este captulo tem como objetivo fazer com que o leitor seja
capaz de entender que:
O documento de arquitetura auxilia no processo de design, uma ferramenta de comunicao entre stakeholders e pode servir de modelo de anlise do software;
Toda informao presente numa arquitetura uma deciso arquitetural;
1 This
content
is
available

189
online
at
CHAPTER 8.
190
DOCUMENTAO DA
ARQUITETURA

ou executivas;

ou ser alternativa a outras decises arquiteturais; e
Um nico diagrama no suciente para conter a quantidade de informao que deve ser mostrada por um arquiteto. Por isso, a necessidade de mltiplas vises arquiteturais;
8.1 Arquitetura e Documento da Arquitetura

A arquitetura de um software existe independente dela ser
projetada ou documentada.
No entanto, ao deixarmos a ar-
quitetura simplesmente emergir a partir do software, ou seja,

evoluir ao longo do processo de desenvolvimento sem projeto
ou documentao, corremos o risco de no tirar proveito dos
benefcios que ela proporciona.
Por outro lado, apenas realizar o design arquitetural e no
document-lo (ou document-lo de forma precria), pode minimizar as vantagens a serem obtidas pela arquitetura. Isto pode
ocorrer porque documentar a arquitetura, alm de auxiliar o
prprio processo de design, tambm proporciona:
uma ferramenta de comunicao entre os stakeholders;

a integridade conceitual ao sistema e ao processo de desenvolvimento;
um modelo para anlise antecipada do sistema; e

uma ferramenta de rastreabilidade entre os requisitos e
os elementos do sistema.

191
8.1.1 Auxlio ao Processo de Design

Apesar de dividirmos conceitualmente o processo de design do
processo de documentao, comum que ambos aconteam
em paralelo na prtica. Quando isto ocorre, a documentao
ajuda no design, principalmente no sentido de separao de
preocupaes.
Ao documentarmos vises arquiteturais diferentes separadamente, preocupamo-nos separadamente com o design de diferentes aspectos do software.
Entre os diversos aspectos de
um software, podemos citar os aspectos funcionais, de dados,

de concorrncia, de desenvolvimento, de implantao e operacionais. Esta separao se torna benca porque h diferentes
linguagens, que podem ser grcas ou textuais, que melhor se
encaixam descrio de cada aspecto, ajudando no s numa
melhor representao, como tambm numa melhor modelagem
e avaliao em relao aos objetivos.
A seguir, vemos dois exemplos que ilustram a documentao
de algumas decises arquiteturais relacionadas a aspectos diferentes do SASF. No p.
191, podemos observar como o SASF
est dividido em grandes mdulos funcionais e, assim, podemos inferir quais so suas principais funcionalidades e algumas
de suas relaes entre si.
Podemos dizer que as decises ar-
quiteturais do exemplo so apresentadas sob o ponto de vista

funcional do sistema, constituindo uma viso funcional do software. Note tambm que esta no a melhor forma de representar, por exemplo, que o desenvolvimento do cadastro dos
usurios ser terceirizado ou ainda que o servio de transmisso de vdeos deve executar em 7 servidores durante dias teis
e em 15 servidores nos nais de semana e feriados, quando
demanda aumenta.
Exemplo 8.1
[Deciso Arquitetural 001] O SASF dividido em cinco

CHAPTER 8.
192
DOCUMENTAO DA
ARQUITETURA
grandes mdulos funcionais.
Cada mdulo respon-
svel por prover um conjunto de funcionalidades relacionadas entre si. Os grandes mdulos do SASF so:
Locadora de Filmes;
Transmissor de Filmes;
Motor de Sugestes;
Cadastro de Usurios;
Cadastro de Filmes.
As principais funcionalidades providas por cada mdulo e suas relaes de uso esto descritas no diagrama
representado na Figura 8.1.

193
Figura 8.1:
Mdulos funcionais do SASF. O esteretipo
Mdulo do diagrama indica os mdulos funcionais

que compem o sistema. J o esteretipo usa in
dica relaes de uso entre os mdulos para que possam implementar suas funes. Por m, o esteretipo

indica uma relao de especializao
dos dados guardados no elemento responsvel pelo cadastro.
especializao
Objetivos: A diviso em mdulos funcionais possibilita

a diviso da implementao entre os times de desenvolvimento de acordo com a especialidade de cada time.
Motivao:
As diversas funes a serem providas
pelo SASF foram agrupadas em preocupaes comuns

CHAPTER 8.
194
DOCUMENTAO DA
ARQUITETURA
(cadastro de dados, locao e transmisso de lmes,

e sugestes ao usurio). O cadastro deve ser especializado em dois tipos para dividir o esforo de desenvolvimento: cadastro de lmes e de usurios. O motor de
sugestes deve ser alimentado com dados de histrico
de locaes do usurio e informaes sobre a base de
lmes no sistema.
No Exemplo 8.2, mostramos o SASF sob um ponto de vista de
implantao.
Neste exemplo, podemos observar informaes
de congurao para implantao de servios para executar o

SASF informaes que estavam ausentes no exemplo anterior.
Exemplo 8.2
[Deciso Arquitetural 002] A implantao do mdulo que implementa as funcionalidades do servio de
transmisso de lmes deve depender apenas de um
parmetro:
endereos.servidores.congurao:
dereos
IP
dos
servidores
que
lista de enconstituem
servio de congurao do SASF.

Os outros parmetros de congurao devem ser obtidos a partir da comunicao com o servio de congurao.
Objetivos: Facilitar a operabilidade do sistema.
Motivao: O servio de congurao do SASF, que
descrito em detalhes na [Deciso Arquitetural 011],
um centralizador da congurao do sistema.
Nele,
o operador do sistema insere endereos de servios

para que estejam disponveis para a congurao de
uma nova instncia. Quando a instncia do servio de
transmisso de lmes iniciada, ela faz requisies ao
195
servio de congurao pelos endereos dos servios de

cadastro e dos servios de armazenamento de lmes,
por exemplo.
Exemplo 8.3
[Deciso Arquitetural 002] A implantao do mdulo que implementa as funcionalidades do servio de
transmisso de lmes deve depender apenas de um
parmetro:
endereos.servidores.congurao:
dereos
IP
dos
servidores
que
lista de enconstituem
servio de congurao do SASF.

Os outros parmetros de congurao devem ser obtidos a partir da comunicao com o servio de congurao.
Objetivos: Facilitar a operabilidade do sistema.
Motivao: O servio de congurao do SASF, que
descrito em detalhes na [Deciso Arquitetural 011],
um centralizador da congurao do sistema.
Nele,
o operador do sistema insere endereos de servios

para que estejam disponveis para a congurao de
uma nova instncia. Quando a instncia do servio de
transmisso de lmes iniciada, ela faz requisies ao
servio de congurao pelos endereos dos servios de
cadastro e dos servios de armazenamento de lmes,
por exemplo.
8.1.2 Ferramenta de Comunicao

J sabemos que diferentes stakeholders demonstram diferentes
preocupaes sobre diferentes aspectos do sistema.
Como a
196
CHAPTER 8.
DOCUMENTAO DA
ARQUITETURA
documentao da arquitetura versa sobre as muitas preocupaes dos stakeholders, ela serve de ferramenta para comunicao, uma vez que prov um vocabulrio comum sobre o
sistema, alm de registrar as relaes entre as preocupaes e
de que forma os eventuais conitos foram ou devem ser resolvidos.
Note que para servir de ferramenta de comunicao, o documento arquitetural deve ser construdo de forma que respeite
o conhecimento e as necessidades dos stakeholders. Para que
isto seja possvel, deve-se conhecer para quem o documento
est sendo escrito. Portanto, devemos escrever a arquitetura
de forma que possua partes que interessem aos usurios, aos
clientes, aos desenvolvedores, aos testadores, ao gerente de projeto ou a outros stakeholders envolvidos no processo.
Por exemplo, os usurios buscam pelas funcionalidades, capacidades e comportamento do sistema, no como ele foi dividido
em mdulos, como os mdulos se comunicam entre si ou se
eles foram desenvolvidos do zero ou tiveram partes reutilizadas
de outros sistemas. Clientes e gerentes tm alguns interesses
semelhantes, como custos de desenvolvimento ou cronograma
de lanamento. No entanto, os clientes tambm se preocupam
com o alinhamento do software ao seu negcio, enquanto o
gerente procura como minimizar os custos para se adequar ao
oramento, ou como as tarefas de implementao sero divididas entre seu time de desenvolvimento. Finalmente, desenvolvedores e testadores esto interessados em aspectos tcnicos
do design, por exemplo, qual a diviso em mdulos do sistema,
quais as alternativas de design disponveis ou como os atributos
de qualidade (desempenho, escalabilidade, tolerncia a faltas,
etc.)
devem ser implementados, cada um motivado pelo seu
papel no processo de desenvolvimento.

197
8.1.3 Integridade Conceitual

Por outro lado, o documento precisa demonstrar consistncia
entre os diversos aspectos do design da arquitetura para que
haja comunicao e integridade conceitual.
A consistncia
necessria porque, apesar da separao de preocupaes ser

uma ferramenta poderosa de design, as solues para as diferentes preocupaes trabalham interligadas durante a implementao, ou seja, quando resolvem o problema. Assim, precisamos de integridade em dois nveis: entre os stakeholders e
entre os diversos aspectos do documento de arquitetura.
A integridade conceitual entre stakeholders a defendida
por Brooks, em The Mythical Man-Month, porque facilita o
sucesso no desenvolvimento de sistemas de software.
Se os
stakeholders e principalmente os desenvolvedores no tm

em mente o mesmo design que se transformar em produto,
so poucas as garantias de que o produto implementado ser
o projetado.
Por isso, no processo, o documento de arquite-
tura serve para restringir eventuais deslizes conceituais em

relao ao design arquitetural e prevenir futuras discordncias
entre stakeholders, inclusive de interesses similares. O Exemplo 8.4 ilustra um caso de restrio aos desenvolvedores, mas
que benca por proporcionar a integridade conceitual entre
times de desenvolvimento.
Este caso a denio das inter-
faces entre dois servios presentes no sistema.
Exemplo 8.4
No SASF, se dividirmos os desenvolvedores em mais
vrios times, comum que haja uma maior interao
entre os membros de um mesmo time do que entre
times diferentes.
Vamos considerar que delegamos a
um time a implementao do servio responsvel pelas

funcionalidades do mdulo Cadastro de Filmes, j apresentado no Exemplo 8.1, e a outro time o mdulo
Transmissor de Filmes.
Para que a implementao

CHAPTER 8.
198
DOCUMENTAO DA
ARQUITETURA
dos dois mdulos possa ser paralelizada e para que

sejam evitadas suposies errneas ou desnecessrias
por parte de cada time sobre outros mdulos (e,
portanto, seja menos custosa a integrao), devemos
denir cuidadosamente as interfaces dos mdulos, sejam os mtodos disponveis, a forma de comunicao e
os tipos de dados usados como parmetros ou retorno.
A integridade conceitual tambm se mostra necessria durante
a incluso de novos membros equipe de desenvolvimento e
ao longo da evoluo e manuteno do software. Novos membros precisam de uma descrio da arquitetura porque normalmente so inseridos ao time sem qualquer conhecimento prvio
do design. J ao longo da evoluo e manuteno do software,
o conhecimento das regras de design a serem seguidas se faz
necessrio para que os requisitos de qualidade permaneam implementados, mesmo durante mudanas. O exemplo a seguir
ilustra uma regra de design para que um software de manipulao de imagens continue exercendo alta portabilidade.
Exemplo 8.5
O software de manipulao de imagens ImageJ
de-
sempenha bem dois atributos de qualidade: a extensibilidade e a portabilidade. Sua extensibilidade garantida por ter sua arquitetura ser baseada no uso de plugins. Com isso, ele composto de um ncleo de funcionalidades bsicas e prov meios para que novas funcionalidades sejam adicionadas em tempo de execuo.
J sua portabilidade garantida por ele ter seu ncleo
e plugins implementados usando a linguagem de programao Java, permitindo sua execuo em qualquer
ambiente que disponha da mquina virtual Java.
Como o cdigo-fonte do ImageJ de domnio pblico,
2 ImageJ
Image
Processing
and
Analysis
http://rsbweb.nih.gov/ij/ (<http://rsbweb.nih.gov/ij/>)

in
Java:
199
qualquer programador pode baix-lo, us-lo e escrever

novos plugins para ele.
Inclusive, possvel usar o
mecanismo Java Native Interface (JNI) para realizar

chamadas a bibliotecas escritas em outras linguagens.
No entanto, se o programador deseja manter o alto
grau de portabilidade do ImageJ, ele deve respeitar a
regra de design do software que de nunca realizar
chamadas nativas durante a implementao de novas
funcionalidades.
Existe tambm a integridade entre os diversos aspectos da arquitetura no documento ou, em outras palavras, a integridade
entre as vises da arquitetura. Este tipo de integridade deve
ser mantido para que as partes do design funcionem em conjunto e que, portanto, o design seja passvel de implementao.
A consistncia entre vises se faz necessria por que, apesar da
separao de preocupaes e de elementos arquiteturais facilitar o design, em conjunto que eles so construdos e executados. Portanto, se h no documento mais de uma viso sobre
os mesmos elementos do sistema, essencial que na documentao dessas vises exista um mapeamento entre as diferentes
representaes desses elementos.
O Exemplo 8.6 ilustra a consistncia entre vises sobre o armazenamento no SASF. Nele, podemos observar (1) os servios
providos pelo sistema de armazenamento do SASF por meio da
viso funcional; (2) que boa parte dos servios de armazenamento no sero implementados do zero, uma vez que sero
obtidos pelo Sistema de Gerncia de Banco de Dados adotado,
por meio da viso de desenvolvimento; e (3) que o sistema de
armazenamento estar executando, no mnimo, em trs servidores, por meio da viso de implantao.
Note que, se al-
guma das vises for inconsistente com as outras, podem surgir dvidas sobre:
(1) quais servios esto disponveis para
quem usa armazenamento, (2) o que ser implementado e o

que ser aproveitado durante a implementao da soluo de
CHAPTER 8.
200
DOCUMENTAO DA
ARQUITETURA
armazenamento do SASF e, por m, (3) que tipo de hardware

ser necessrio para executar a soluo de armazenamento.
Exemplo 8.6
Na [Deciso Arquitetural 001], descrita no Exemplo 8.1, apresentamos trs mdulos que devem lidar diretamente com armazenamento: Cadastro de Usurios,
Cadastro de Filmes e Transmissor de Filmes. No entanto, apenas as funes que eles devem implementar
foram descritas, no como devem implementar. As decises a seguir mostram alguns aspectos de como essas
funes devem ser implementadas.
(Deciso Arquitetural 002). O armazenamento das informaes dos mdulos Cadastro de Usurios e Cadastro de Filmes ser realizado usando um Sistema Gerenciador de Banco de Dados Relacional (SGBDR) de
modo a permitir criao, edio, obteno e remoo
das entradas.
As informaes guardadas no SGBDR so os atributos
dos Usurios e Filmes e so essencialmente textuais ou
metainformaes para localizao de arquivos de mdia (fotos ou vdeos).
O armazenamento de arquivos
de mdia tratado na [Deciso Arquitetural 003]. J o

armazenamento de arquivos textuais que no so atributos dos Usurios ou Filmes, por exemplo, mensagens
para usurios ou comentrios sobre lmes tratado em
outra deciso arquitetural que no descrita aqui.
Objetivo:
Permitir a persistncia dos atributos dos
Usurios e Filmes, facilitando o desenvolvimento.

Motivao:
Os atributos de Usurios e Filmes so
essencialmente
relacionais,
se
encaixando
perfeita-
mente ao paradigma usado para armazenamento. Alm

201
de ser um paradigma bem conhecido pelo time de desenvolvimento.

(Deciso Arquitetural 003). O armazenamento de arquivos de mdia (fotos de Usurios, fotos de Filmes
e arquivos de vdeo) sero armazenados usando uma
Rede de Fornecimento de Contedo ( Content Delivery Network ou CDN).
Objetivo: Permitir a persistncia de arquivos de mdia,
facilitando a implementao e permitindo desempenho
e controle de carga.
Motivao: Os arquivos de mdia presentes no SASF
so contedo esttico, que pode ser distribudo por
uma CDN e, assim, tirar proveito de replicao, distribuio geogrca e caching, sem ter que implementar estas tcnicas.
J as decises da viso de implantao, devem descrever os servidores que executaram os SGBDR e o
servio que se comunica com a CDN para o envio de
arquivos.
8.1.4 Modelo para Anlise

A arquitetura um modelo do sistema, uma vez que descreve
suas caractersticas.
Ao documentar a arquitetura, obtemos
um modelo manipulvel do sistema que tem utilidade no s ao

arquiteto, mas tambm a outros stakeholders. Com o modelo
manipulvel, possvel avaliar as decises arquiteturais registradas e valid-las em relao aos requisitos que o software
deve satisfazer. Alm disso, o documento pode ainda servir de
ferramenta que permita a vericao de se implementao est

CHAPTER 8.
202
DOCUMENTAO DA
ARQUITETURA
de acordo com o design, podendo prevenir eventuais deslizes

arquiteturais.
Podemos citar trs categorias
de validao da arquitetura em
relao aos requisitos: anlise baseada em inspees, anlise

baseada em modelos e anlise baseada em simulaes. No entanto, a possibilidade de aplicao de uma tcnica de uma dada
categoria de validao est diretamente ligada representao
usada no documento de arquitetura.
8.1.4.1 Anlise baseada em inspees

Anlises baseadas em inspees so conduzidas por bancas de
reviso compostas por vrios stakeholders. Entre os stakeholders, podemos encontrar, alm do arquiteto e dos desenvolvedores, interessados menos tcnicos, como o gerente de projeto
e, em alguns casos, o cliente. Durante o processo de inspeo,
os stakeholders denem os objetivos da anlise e estudam as
representaes da arquitetura de forma a avali-la de acordo
com seus objetivos.
Esta categoria de inspeo serve para vericar um conjunto
amplo de propriedades da arquitetura e faz uso de mltiplas
representaes do design, tanto em linguagens formais, quanto
informais. Por ser um processo essencialmente manual, um
tipo de anlise mais caro do que os de outros, mas que possibilita tambm a inspeo em busca de qualidades menos formais do software, a exemplo de escalabilidade, manutenibilidade ou operabilidade. Outra vantagem deste tipo de anlise
a de permitir o uso de representaes informais ou parciais
do design da arquitetura, alm de possibilitar a anlise considerando mltiplos objetivos de mltiplos stakeholders.
3 Esta diviso foi feita originalmente por Taylor
chitecture: Foundations, Theory, and Practice
et al
em
[104].

Software Ar-
203
Como exemplos de anlises baseadas em inspees, podemos

citar alguns mtodos de avaliao de arquitetura criados pelo
Software Engineering Institute, da Carnegie Melon University :
o Software Architecture Analysis Method (SAAM), o Architectural Trade-O Analysis Method (ATAM) e o mtodo Active
Reviews for Intermediate Designs (ARID).
8.1.4.2 Anlise baseada em modelos

Anlises baseadas em modelos so menos custosas do que as
baseadas em inspees, uma vez que demonstram maior nvel
de automao. Este tipo de anlise utiliza ferramentas que manipulam representaes da arquitetura com o objetivo de encontrar algumas de suas propriedades. Para possibilitar a manipulao, as representaes devem ser escritas em linguagens
formais ou semiformais como ADLs ( architecture description
languages ou linguagens de descrio de arquitetura), como por
exemplo, ACME, SADL e Rapide, mquinas de estado nito
ou UML.
Esta categoria de inspeo utilizada na busca de propriedades
formais da arquitetura, como corretude sinttica ou ausncia
de deadlocks e, apesar de seu alto grau de automao, pode
necessitar que o arquiteto guie a ferramenta de inspeo utilizada considerando os resultados parciais. Uma desvantagem
desta categoria seu desempenho na anlise de grandes sistemas. Uma vez que as representaes da arquitetura podem
levar exploso de estados, a anlise de todo o espao de estados do sistema pode ser invivel.
Portanto, comum que
apenas partes da arquitetura sejam analisadas de preferncia

partes mais crticas.
Como exemplos de anlises baseadas em modelos, podemos
4 Podemos encontrar a descrio desses mtodos no livro
Software Architectures, de Paul Clements et al
[33].

Evaluating
CHAPTER 8.
204
DOCUMENTAO DA
ARQUITETURA
citar o uso da linguagem Wright para a vericao de ausncia

de deadlocks
e o uso da linguagem de modelagem MetaH para
anlise de propriedades conabilidade e segurana ( safety ) .
8.1.4.3 Anlise baseada em simulaes

Anlises baseadas em simulaes se utilizam de modelos executveis da arquitetura para extrair caractersticas do software
ou de partes dele. Assim como a anlise baseada em modelos,
esse tipo de anlise tambm se utiliza de ferramentas que automatizam o processo, deixando-o mais barato.
No entanto,
este tipo de anlise produz resultados restritos s propriedades

dinmicas do software e esto sujeitas s imprecises dos modelos de execuo.
Para possibilitar a execuo, as representaes utilizadas devem ser formais, o que diminui sua aplicao na indstria, mas
que proporciona resultados mais precisos em relao s qualidades estruturais, comportamentais e de interao entre as
partes do software, como por exemplo qualidades de desempenho e conabilidade.
Como exemplos de anlises baseadas em simulaes, podemos
citar o uso de simulao de eventos discretos para anlise de de-
sempenho ou o uso da ferramenta XTEAM , que utiliza ADLs

e processos de estado nito para diferentes tipos de anlises
arquiteturais.
5 Tcnica apresentada por Allen e Garlan no artigo
Architectural Connection
6 Mais
contradas
informaes
no
site:
[7]
sobre
linguagem
A Formal Basis for
MetaH
podem
ser
en-
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].

205
8.1.5 Ferramenta de Rastreabilidade

Por m, a documentao permite rastreabilidade entre os requisitos e os elementos da arquitetura e implementao que satisfazem esses requisitos.
Ao documentar as decises arquite-
turais, registramos (1) seus objetivos, que normalmente so

qualidades a serem alcanadas pelo software, e (2) como esses
objetivos so alcanados, por meio da descrio dos elementos
que compem o sistema e suas relaes e regras de design que
devem ser respeitadas durante a implementao. Este registro
serve de ponte entre dois extremos do processo de desenvolvimento:
os requisitos e a implementao, e assim permite a
navegao entre pontos relacionados, sejam eles requisitos, decises de design ou partes da implementao.
A rastreabilidade nos permite analisar qual o impacto de uma
deciso de design, tanto em termos de quais requisitos ela afeta,
quanto quais elementos de software ela dita a existncia ou, em
caso de manuteno, quais elementos so ou devem ser afetados
por mudanas nos requisitos ou nas decises.
O exemplo a
seguir mostra aspectos de rastreabilidade na documentao da

arquitetura do SASF.
Exemplo 8.7
Se observarmos a arquitetura do SASF e procurarmos
pelas decises responsveis por facilitar a manuteno
do sistema,
encontraremos entre elas a deciso de
diviso do sistema em camadas.
Essa deciso sug-
ere uma diviso do sistema em camadas lgicas, mas

tambm inuencia na diviso em pacotes, servios ou
mesmo processos. Assim, a satisfao do requisito de
manutenibilidade est diretamente ligada correta diviso das partes do sistema em apresentao, lgica de
negcio e persistncia.
Da mesma maneira, se partirmos das partes que for-

206
CHAPTER 8.
DOCUMENTAO DA
ARQUITETURA
mam as camadas de apresentao, lgica de negcio

e persistncia, observaremos que elas esto ligadas
diviso do sistema (e deciso arquitetural) que se
prope a atender a requisitos de manutenibilidade.
8.2 Decises Arquiteturais

Em captulos anteriores, denimos arquitetura de software usando o padro ISO/IEEE 1471-2000, que diz que ela a organizao fundamental de um sistema, representada por seus componentes, seus relacionamentos com o ambiente, e pelos princpios que conduzem seu design e evoluo.
Aps a denio,
mencionamos tambm que a arquitetura composta de diversas decises de design (no caso, design de alto-nvel ou arquitetural) e que cada deciso contm, ao menos em nvel conceitual,
uma descrio, objetivos e algum argumento ou motivao.
Como a arquitetura formada por decises arquiteturais, devemos conhecer os tipos de decises arquiteturais para ento
sermos capazes de documentar a arquitetura.
Uma deciso arquitetural, como tambm j denido anteriormente, uma escolha entre as alternativas de design arquitetural, que se prope a alcanar um ou mais atributos de qualidade
do sistema, por meio de estruturas ou regras que ela envolve ou
dene. Em outras palavras, podemos dizer que uma deciso arquitetural descreve parte do design, onde essa descrio pode:
(1) ditar a existncia ou inexistncia de partes do sistema, (2)
especicar propriedades que, durante a construo, partes do
sistema devem satisfazer, ou (3) citar tcnicas que devem ser
seguidas durante a construo de partes do sistema. Podemos
ento dividir as decises arquiteturais em:
Decises arquiteturais existenciais (e no-existenciais);

Decises arquiteturais de propriedades; e

207
Decises arquiteturais executivas.
8.2.1 Decises existenciais

Uma deciso existencial aquela que indica a presena de um
ou vrios elementos arquiteturais no design e na implementao.
Os elementos arquiteturais j foram apresentados anteriormente, mas vamos relembr-los aqui. Estes elementos so as
partes em que o software dividido e podem ser classicados
em dois tipos:
elementos arquiteturais estticos e elementos
arquiteturais dinmicos.
Os elementos estticos descrevem a
estrutura do sistema em tempo de design e so constitudos de

elementos de software (por exemplo, classes, pacotes, procedimentos, servios 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 dinmicos descrevem o comportamento do sistema em tempo de execuo e entre eles podemos incluir processos, mdulos, protocolos, ou classes que realizam comportamento. Note que as relaes entre os elementos arquiteturais,
tanto estticos quanto dinmicos, so representadas tambm
como elementos arquiteturais. Estes elementos so chamados
de conectores e podem ser associaes, composies, generalizaes, entre outros.
No Exemplo 8.1, observamos uma deciso arquitetural que divide o SASF em diversos mdulos menores, constituindo assim
uma deciso existencial que dene diversos elementos e as relaes entre si.
J no Exemplo 8.8, observamos uma deciso arquitetural que
tambm dita a presena de elementos na arquitetura do SASF.
CHAPTER 8.
208
DOCUMENTAO DA
ARQUITETURA
No entanto, ao contrrio do exemplo citado anteriormente que

dita elementos estruturais do software, o Exemplo 8.8 dita elementos comportamentais esperados nele. Assim, podemos encontrar decises existenciais que sejam decises estruturais ou
comportamentais. As decises comportamentais so mais relacionadas implementao dos requisitos de qualidade.
Exemplo 8.8
[Deciso Arquitetural 005] Os dados do Cadastro de
Usurios e do Cadastro de Filmes devem ser particionados horizontalmente.
Objetivo: Distribuir carga, melhorar o desempenho e
aumentar o nmero de pontos de falhas.
Motivao: Ao particionar horizontalmente os dados,
permite-se a distribuio da carga de requisies entre vrios servidores de armazenamento, que estaro
executando instncias do SGBDR. Com menor carga,
o desempenho pode ser melhorado.
Alm disso, caso
uma partio que inacessvel (por falha, por exemplo),

parte dos dados ainda estaro acessveis, no inviabilizando o sistema por completo.
Na prtica, importante observarmos que a diviso entre decises estruturais e comportamentais no absoluta. Podemos
encontrar decises que, para descrever um comportamento, necessitem de novas estruturas arquiteturais.
Assim, por con-
venincia, melhor descrever estas novas estruturas na prpria

deciso comportamental do que documentar uma nova deciso
estrutural.
Podemos observar este caso no exemplo anterior,
onde descrevemos as parties do conjunto de dados para ento descrever o comportamento de particionamento dos dados
e assim conseguir algum nvel de escalabilidade horizontal.
Por outro lado, h decises que probem a existncia de elementos arquiteturais. Essas decises so chamadas de decises

209
no-existenciais e elas servem para restringir as alternativas de

design de baixo nvel.
Alguns padres arquiteturais, como o
3- tier ou mesmo o padro Camadas, probem a comunicao

entre alguns dos elementos que eles descrevem, constituindo
decises no-existenciais.
8.2.2 Decises de propriedades

Decises de propriedades no determinam a existncia de
partes do software, mas apresentam alguma qualidade ou caracterstica que uma ou mais partes devem exibir.
O papel
deste tipo de deciso o de guiar tanto o design de baixo nvel,

quanto a implementao, uma vez que descreve os princpios
e regras ou restries de design que devem ser respeitadas ao
longo do desenvolvimento.
Os exemplos mais comuns de decises de propriedades so as
decises sobre preocupaes transversais ao software, como por
exemplo, decises de logging, decises de tolerncia a faltas
ou mesmo decises sobre a preciso na obteno dos resultados.
Podemos observar uma ilustrao mais completa deste
tipo de deciso nos exemplos a seguir (Exemplo 8.9 e Exemplo 8.10).
Note que, em ambos os exemplos, as decises
no descrevem a existncia de elementos que devem estar na

arquitetura, mas descrevem as propriedades de elementos arquiteturais que foram descritos em outras decises.
Exemplo 8.9
[Deciso Arquitetural 008] Os mtodos pblicos de
cada servio que implementa os mdulos descritos na
[Deciso Arquitetural 001] devem seguir as seguintes
regras de logging :
Deve-se
registrar
todos
os
parmetros
das
chamadas em nvel de DEBUG. Este modo deve

CHAPTER 8.
210
DOCUMENTAO DA
ARQUITETURA
poder ser ligado ou desligado em tempo de execuo.
Todas as excees lanadas devem ser logadas em

nvel de ERROR e registrar os parmetros usados
durante a execuo.
Os tempos de execuo de cada chamada ao

mtodo devem ser registrados, para possibilitar a
monitorao de desempenho do sistema. O canal
de logging utilizado neste caso deve ser especializado para coleta de mtricas de desempenho.
Objetivo: Estas regras facilitam a operabilidade do sistema.

Motivao: O registro dos acontecimentos inesperados
no sistema facilita o diagnstico dos problemas e a possibilidade de aumentar o nvel de detalhe dos registros
em tempo de execuo permite que esse diagnstico
seja mais rpido. Por outro lado, o registro de mtricas
de desempenho do sistema permite anlise de capacidade, podendo indicar se o sistema est precisando de
mais recursos computacionais.
Exemplo 8.10
[Deciso Arquitetural 010] Os servios que implementam os mdulos descritos na [Deciso Arquitetural 001]
devem ser replicados, evitando assim pontos nicos de
falha. Para facilitar a replicao, os mdulos no devem manter estado, delegando esta responsabilidade
aos servios de armazenamento.
Objetivo: Replicando instncias de servios, elimina-se
os pontos nicos de falha, aumentando a conabilidade
do sistema e a tolerncia a faltas.
Motivao: Implementando servios stateless, a replicao ca trivial, uma vez que a requisio pode usar
211
qualquer uma das rplicas ativas. Note que sempre

necessrio o registro no balanceador de carga da uma
nova rplica em execuo. Servios de armazenamento
no podem utilizar esta tcnica sem adaptaes, uma
vez que dados so fundamentalmente stateful.
8.2.3 Decises executivas

A ltima classe de decises arquiteturais que apresentamos
a executiva.
Este tipo de deciso est mais relacionado ao
processo de desenvolvimento do que aos elementos de design.

Entre as decises executivas, podemos encontrar decises que
descrevem: a metodologia utilizada durante desenvolvimento,
como o time est dividido durante a implementao do sistema,
como o treinamento de novos membros deve ocorrer, ou quais
tecnologias e ferramentas devem ser adotadas para auxiliar o
processo. Os exemplos a seguir mostram algumas decises executivas.
Exemplo 8.11
Neste exemplo, apresentamos uma deciso hipottica
do software Vuze .
(Deciso Arquitetural 001).
O software ser escrito
usando a linguagem de programao Java.

Objetivo:
Permitir a portabilidade para vrios sis-
temas operacionais.
Motivao: Como um dos objetivos do Vuze alcanar
o maior nmero de usurios possvel, no queremos impor a barreira de instalao em um ou outro sistema
operacional especco. Uma vez que programas escritos
8 Vuze : http://www.vuze.com/ (<http://www.vuze.com/>)

CHAPTER 8.
212
DOCUMENTAO DA
ARQUITETURA
em Java podem executar em qualquer sistema operacional que seja capaz de executar a Mquina Virtual
Java (JVM) e que a maioria dos sistemas para usurios
nais j dispem da JVM, esta linguagem deve ser usada para poupar o trabalho de portar o Vuze para diferentes sistemas.
Exemplo 8.12
[Deciso Arquitetural 011] O time de desenvolvimento
ser dividido em equipes menores e cada equipe ser
responsvel pela implementao do servio responsvel
pelas funcionalidades de mdulo descrito na [Deciso
Arquitetural 001].
Objetivo: Minimizar o tempo de desenvolvimento.
Motivao: A possibilidade de paralelizar o desenvolvimento pode diminuir o tempo total de construo do
software. No entanto, deve-se respeitar as decises arquiteturais que denem as interfaces entre os mdulos,
para que sua integrao seja facilitada. endexample
8.2.4 Atributos das decises arquiteturais

No captulo de fundamentos de arquitetura, mostramos que as
decises arquiteturais devem possuir uma descrio, objetivos
e alguma fundamentao. Estes atributos se tornam essenciais
ao processo de design das decises, pois representam, respectivamente, o que deve ser feito, para que deve ser feito e a
justicativa da soluo. No entanto, h outros atributos que
so especialmente teis quando precisamos documentar as decises arquiteturais.
So eles o escopo, o histrico, o estado
atual e as categorias da deciso arquitetural.

213
Entre as vantagens que eles proporcionam, podemos dizer que

esses atributos facilitam a manuteno de um registro histrico
das decises e a rastreabilidade entre requisitos e elementos do
software. A seguir, mostramos cada atributo de uma deciso
arquitetural separadamente:
8.2.4.1 Descrio
O atributo de descrio, como j mencionamos no captulo
de fundamentos, simplesmente a descrio da deciso, que
mostra o que foi decidido na arquitetura. Na descrio, podemos encontrar (1) quais elementos arquiteturais devem estar
presentes, caso seja uma deciso existencial; (2) quais propriedades devem se manifestar nos elementos ou quais regras
ou princpios de design devem ser seguidos, caso seja uma deciso de propriedade; ou (3) qual metodologia deve ser seguida,
como o time deve ser dividido para a implementao dos mdulos ou qual ferramenta deve ser utilizada para integrao,
caso seja uma deciso executiva.
A descrio pode ser representada usando diversas linguagens,
podendo ser textuais ou grcas e formais ou informais. A escolha da linguagem que ser utilizada na descrio depende dos
objetivos da deciso e dos stakeholders interessados. Se, entre
os seus objetivos, queremos que a deciso permita tambm gerao automtica de parte da implementao, anlise baseada
em modelos ou simulaes, ou vericao de conformidade, a
descrio deve utilizar linguagens formais ou semiformais que
facilitam estas atividades. Por outro lado, se esperamos que a
deciso apenas informe que elementos devem estar na arquitetura e suas caractersticas, mas no esperamos gerao, anlise
ou vericao automticas, linguagens semiformais ou mesmo
informais podem ser utilizadas, como a lngua Portuguesa ou
diagramas caixas e setas, desde que a ambiguidade seja evitada por meio de legendas ou explicaes mais detalhadas.

CHAPTER 8.
214
DOCUMENTAO DA
ARQUITETURA
Vale observar que tanto a utilizao de linguagens formais,

quanto a utilizao de linguagens informais na descrio proporcionam vantagens e desvantagens que devem ser consideradas durante o processo de documentao.
Ao utilizarmos
linguagens formais, permitimos a automatizao de processos,

que podem poupar bastante trabalho durante o desenvolvimento. Por outro lado, no so todos os stakeholders que as
entendem perfeitamente, podendo restringir assim o entendimento da deciso.
As linguagens informais, por sua vez, tm como vantagem a
maior facilidade de entendimento por parte dos stakeholders
(inclusive no-tcnicos, como gerentes, clientes e at usurios).
No entanto, o entendimento s facilitado se a descrio evitar
ambiguidades, que so comuns em linguagens informais.
Uma forma de se conseguir mais vantagens nas decises seria utilizar tanto linguagens formais quanto informais nas descries das decises. Nada impede que isso seja feito, obtendo
assim preciso na descrio, possibilidade de atividades automatizadas, e entendimento por parte dos stakeholders tcnicos
e no-tcnicos.
O problema reside apenas na grande quanti-
dade trabalho empregado ao descrever cada deciso com duas

ou mais linguagens e, ainda por cima, ter que manter a consistncia da descrio entre elas.
A seguir, mostramos a descrio da deciso arquitetural j apresentada no Exemplo 10 do captulo de fundamentos (Exemplo 4.10) usando diferentes linguagens diferentes. O primeiro
exemplo mostra a deciso escrita em Portugus.
Exemplo 8.13
de negcio e persistncia de dados. A camada de apresentao se comunica apenas com a lgica de negcio e
215
apenas a lgica de negcio de comunica com a camada

de persistncia de dados.
J o exemplo a seguir mostra a descrio usando tambm um

cdigo que pode ser interpretado pela ferramenta DesignWizard
e que permite a vericao automtica de conformidade
do cdigo implementado com a arquitetura.
Exemplo 8.14
de negcio e persistncia de dados, que sero mapeadas
respectivamente
para
os
pacotes:
com.sasf.webui,
com.sasf.service, com.sasf.storage. Os testes presentes

na listagem a seguir (p.
215), que podem ser execu-
tados usando o DesignWizard, descrevem as regras de

comunicao entre as camadas.
public class ThreeTierDesignTest extends TestCase {

public void test_communication_web_ui_and_services() {
String sasfClassesDir =
System.getProperties("sasf.classes.directory");
DesignWizard dw = new DesignWizard(sasfClassesDir);
PackageNode services =
dw.getPackage("com.sasf.service");
PackageNode webUI = dw.getPackage("com.sasf.webui");
Set<PackageNode> callers =
services.getCallerPackages();
for (PackageNode caller : callers) {
assertTrue(caller.equals(webUI));
}
}
9 O artigo
Design tests: An approach to programmatically check your

code against design rules [21], de Brunet et al contm mais informaes
sobre o DesignWizard.
CHAPTER 8.
216
DOCUMENTAO DA
ARQUITETURA
public void test_communication_services_and_storage() {

String sasfClassesDir =
System.getProperties("sasf.classes.directory");
DesignWizard dw = new DesignWizard(sasfClassesDir);
PackageNode services =
dw.getPackage("com.sasf.service");
PackageNode storage =
dw.getPackage("com.sasf.storage");
Set<PackageNode> callers =
storage.getCallerPackages();
for (PackageNode caller : callers) {
assertTrue(caller.equals(services));
}
}
}Testes para comunicao entre tiers.
8.2.4.2 Objetivo
O objetivo da deciso serve para registrarmos o motivo da deciso estar sendo tomada. Como decises de design so conduzidas por requisitos, sejam eles funcionais ou de qualidade, a
identicao dos requisitos deve estar presente neste atributo.
Os objetivos das decises arquiteturais ajudam na rastreabilidade da arquitetura.
No Exemplo 8.15, percebemos duas formas de meno aos requisitos implementados pela deciso. A primeira forma presena o identicador do requisito de qualidade, RNF-01. J a
outra forma uma breve descrio do requisito alcanado.
Exemplo 8.15
217
Objetivo:
Atendimento ao requisito no-funcional:
RNF-01. Esta diviso diminui o acoplamento entre os

elementos internos da arquitetura, facilitando o desenvolvimento e a manuteno.
8.2.4.3 Fundamentao
Uma deciso arquitetural deve ser tomada com alguma fundamentao, seja ela uma anlise das alternativas de design,
baseada na experincia prvia do arquiteto, ou baseada em
padres de design. Esta fundamentao resulta no julgamento
das vantagens e desvantagens das alternativas e servem para
justicar a soluo proposta.
No atributo fundamentao, registramos a justicativa da deciso para que haja um registro histrico das motivaes e
consideraes feitas pelo arquiteto para chegar soluo de
design.
Este registro essencial para que este tipo de infor-
mao no seja esquecido ao longo do ciclo de vida do software,

pois importante para o seu processo de evoluo.
Por exemplo, durante uma atividade de refatorao do cdigo,
um novo desenvolvedor pode se interessar pelo motivo de um
mdulo ter sido criado aparentemente de forma desnecessria.
Se no existir algum tipo de registro do motivo para existncia
do mdulo em questo, o novo desenvolvedor pode, simplesmente, modic-lo ou mesmo remov-lo ignorante dos efeitos
que pode causar no design.
A fundamentao normalmente feita por meio de uma descrio textual, mas deve possuir referncias a outros documentos e a outras decises arquiteturais relacionadas. O exemplo
a seguir ilustra a fundamentao de uma deciso arquitetural.

CHAPTER 8.
218
DOCUMENTAO DA
ARQUITETURA
Exemplo 8.16
Motivao: Projetar os elementos internos do sistema
de modo que cada um pertena a apenas uma camada
lgica ajuda a aumentar a coeso e diminuir o acoplamento.
A coeso aumenta, pois cada elemento ser
desenvolvido com o objetivo de ser parte da apresentao, da lgica ou da persistncia do sistema. Dessa
maneira, cada elemento ter sua responsabilidade bem
denida, mesmo que em alto nvel.
Como a comuni-
cao entre as camadas pr-denida, a de seus elementos tambm : elementos da camada de apresentao no se comunicaro com elementos da camada
de persistncia, por exemplo.
Assim, o acoplamento
entre elementos internos ser anlogo ao acoplamento

entre camadas.
Com o baixo acoplamento, o desen-
volvimento e a manuteno dos elementos tambm

facilitado, seja por possibilitar o desenvolvimento independente, seja por mudanas em um elemento terem
menor impacto nos outros.
importante observar que uma deciso arquitetural pode estar relacionada a mais de um atributo de qualidade e, como
veremos a seguir, a mais de uma categoria. Isso ocorre porque
decises arquiteturais se interrelacionam da mesma forma que
os atributos de qualidade e os requisitos impostos pelos stakeholders. Portanto, na fundamentao que devemos tambm
descrever as relaes entre as decises arquiteturais, ou seja,
se uma deciso restringe, probe, possibilita, conita, sobrepe,
compe ou composta de, depende de, ou uma alternativa a
outras decises.

219
8.2.4.4 Escopo
Nem todas as decises arquiteturais so vlidas durante todo o
ciclo de vida do software ou vlidas em todos os mdulos que o
compem. Por isso, surge a necessidade de registrar o escopo
da deciso. Este registro tipo de registro se torna importante
em decises de propriedades, uma vez que normalmente tratam
de preocupaes transversais e abrangem grandes partes do
sistema, e em decises executivas, que devem, por exemplo,
especicar quais etapas do processo de desenvolvimento devem
usar tais metodologias.
O Exemplo 8.17, a seguir, descreve o escopo da Deciso Arquitetural 001, que bem abrangente.
J no Exemplo 8.18,
podemos observar que o escopo da deciso de usar JMX
10
como
tecnologia de monitorao mais limitado.
Exemplo 8.17
Escopo: Esta deciso vlida para todos os servios
que implementam lgica e que tm interface com o
usurio.
Exemplo 8.18
Escopo: A deciso de usar JMX para exposio das
mtricas de desempenho s vlida para os casos
denidos na [Deciso Arquitetural 008].
8.2.4.5 Histrico
A documentao da arquitetura, assim como o que ela representa, evolui ao longo do tempo. Decises so tomadas, avali-
10 Java
Management
Extensions
http://java.sun.com/products/JavaManagement/
(<http://java.sun.com/products/JavaManagement/>)

(JMX):
CHAPTER 8.
220
DOCUMENTAO DA
ARQUITETURA
adas, modicadas ou mesmo contestadas ao longo do ciclo de

vida da arquitetura. Portanto, de se esperar que exista um
registro histrico da evoluo de cada deciso arquitetural. Por
isso consideramos o atributo histrico.
O atributo histrico deve conter, para cada modicao da
deciso, uma marca de tempo, o autor da modicao e um
resumo da modicao.
Se o documento estiver armazenado
em um wiki ou outra forma eletrnica, o histrico pode conter

links para as verses anteriores da deciso.
O Exemplo 8.19 ilustra o registro histrico da Deciso Arquitetural 001.
Exemplo 8.19
Histrico:
revisada,
sugerida
Escopo
(G.
Germoglio,
modicado.
2009/07/15);
(G.
Germoglio,
2009/07/17); aprovada (J. Sauv, 2009/07/18).
8.2.4.6 Estado Atual

O atributo estado atual de uma deciso serve para permitir
mais uma dimenso de organizao das decises.
Da mesma
forma que as decises evoluem ao longo do tempo, elas podem ter diversos estados que merecem ser registrados. Como
o conjunto de estados que podem ser atribudos a uma deciso
arquitetural depende do processo de desenvolvimento adotado,
citamos apenas alguns estados mais comuns:
Sugerida: deciso que ainda no foi avaliada;

Revisada: deciso sugerida e revisada pelo arquiteto ou
time arquitetural;
Aprovada: deciso sugerida, revisada e aprovada;

221
Rejeitada:
deciso sugerida, revisada e rejeitada.
Ela
deve se manter na documentao para referncias futuras.
8.2.4.7 Categoria
Assim como o estado atual, o atributo categoria serve para
possibilitar a organizao das decises arquiteturais em grupos
relacionados. Normalmente, esse atributo composto por uma
lista de palavras-chave associadas s decises.
Esse atributo permite, por exemplo, que os stakeholders selecionem decises relacionadas a um atributo de qualidade especco.
Portanto, se um membro do grupo de garantia de
qualidade do software ( Software Quality Assurance ou SQA)

precisa das decises arquiteturais necessrias para realizar uma
anlise de desempenho do projeto do software, ele deve procurar pelas decises da categoria desempenho.
8.3 Vises arquiteturais

Como consequncia da existncia dos diversos interessados na
arquitetura e que esses interessados tm diferentes preocupaes e diferentes nveis de conhecimento, as decises arquiteturais no so documentadas da mesma maneira para interessados diferentes. Para resolver este problema, fazemos uso do
conceito de mltiplas vises arquiteturais.
Vises arquiteturais so representaes do sistema ou de parte
dele da perspectiva de um conjunto de interesses relacionados.
A vises arquiteturais proporcionam vantagens tanto para o
processo de design, quanto para a documentao da arquitetura.

CHAPTER 8.
222
DOCUMENTAO DA
ARQUITETURA
Durante o design, o arquiteto pode se focar em diferentes vises

separadamente, podendo abstrair os detalhes desnecessrios e
s se ater s preocupaes da viso corrente. Por exemplo, inicialmente, o arquiteto se pode utilizar de uma viso funcional
para projetar os servios primitivos do sistema que constituiro
servios mais complexos e que, por sua vez, serviro de base
para as funcionalidades expostas aos usurios. Em seguida, o
arquiteto pode se utilizar de uma viso de concorrncia para
projetar como as funes sero executadas ao longo do tempo:
de forma sequencial ou em paralelo, de forma sncrona ou assncrona. E, por m, focando-se numa viso informacional, ele
pode denir como os dados esto organizados.
Por outro lado, durante o processo de documentao, o arquiteto pode documentar as vises com diferentes nveis de detalhes e utilizar diferentes linguagens, uma vez que diferentes
vises interessam a diferentes stakeholders.
As vises so concretizaes do que chamamos pontos de vista
11
arquiteturais
Um ponto de vista arquitetural a especi-
cao dos elementos conceituais que devem ser usados para se

construir uma viso.
Um ponto de vista apresenta tambm
qual o seu propsito e quem so os stakeholders interessados

nas vises criadas a partir dele. Em outras palavras, um ponto
de vista arquitetural denido como:
Denio 8.1: ponto de vista arquitetural

um arcabouo conceitual que dene elementos,
conexes e tcnicas que compem uma viso arquitetural, alm especicar seu propsito de acordo com seus
interessados.
Para documentarmos a arquitetura, devemos denir um conjunto pontos de vista que serviro de base para as vises da
11 Viewpoints, de acordo com o padro ISO/IEEE 1471-2000, ou
types (tipos de viso), de acordo com Clements et al

Software Architectures: Views and Beyond.
em

viewDocumenting
223
arquitetura e que estaro presentes no documento. Cada viso

ter uma ou mais decises arquiteturais, que sero descritas a
partir dos elementos, conexes e tcnicas denidos pelo ponto
de vista a que pertence.
Como j existem diversos conjuntos de pontos de vista prontos
para uso na literatura, no h motivo para criarmos o nosso
prprio conjunto. Portanto, a seguir, apresentamos alguns conjuntos os quais achamos essencial o conhecimento. So eles:
4+1 de Kruchten;
Pontos de vista de Rozanski e Woods.
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 inicialmente no artigo The 4+1 View Model of Architecture [62]
e um dos primeiros a serem descritos na literatura. Inicialmente, os pontos de vista so chamados pelo autor de vises.
No entanto, se analisarmos a denio e o uso das vises empregados pelo autor, percebemos ela so compatveis com nossas
denies 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 contm cenrios de uso. Os pontos de
vista mais relevantes desse conjunto so: Lgico, de Processos,
de Desenvolvimento e Fsico.
Como o conjunto de Rozanski
e Woods uma evoluo do 4+1, ao descrev-lo na seo 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:
CHAPTER 8.
224
DOCUMENTAO DA
ARQUITETURA
Working With Stakeholders Using Viewpoints and Perspectives [92]. Ele uma evoluo do conjunto 4+1, pois adiciona
dois novos pontos de vista ao conjunto de Kruchten, e prov
mais informaes que ajudam no design do que na documentao.
Os pontos de vista presentes neste conjunto so:
Funcional: representa o aspecto funcional do software descrito. Vises derivadas deste ponto de vista contm decises sobre as funes presentes no software e os mdulos e submdulos que implementam essas funes. Este
ponto de vista especializado em mostrar a estrutura esttica do software, mostrando suas partes, suas relaes e
suas interfaces. Seu equivalente no conjunto de Kruchten
o ponto de vista Lgico.
de Concorrncia:
representa os aspectos dinmicos e
comportamentais do software.
Vises derivadas deste
ponto de vista contm decises sobre concorrncia, sincronia ou assincronia de chamadas e aspectos temporais
em geral do software e de suas funes. Seu equivalente
no conjunto de Kruchten o ponto de vista de Processo.
de Desenvolvimento:
representa os aspectos e relaes
entre os stakeholders e o processo de desenvolvimento do

software. Vises derivadas deste ponto de vista contm
decises de divises de mdulos, subsistemas, pacotes e
classes e decises sobre a atribuio de tarefas de construo, teste e reuso de partes do sistema aos participantes da equipe de desenvolvimento.
Seu equivalente
no conjunto de Kruchten homnimo.
de Implantao: representa os aspectos de implantao

do software e suas relaes com o ambiente fsico. Vises
derivadas deste ponto de vista contm decises de quantos servidores sero necessrios para execuo de um
225
servio ou como os diferentes servios so implantados

ou atualizados durante o ciclo de vida do software. Seu
equivalente no conjunto 4+1 o ponto de vista Fsico.
Informacional:
representa os aspectos relacionados aos
dados presentes no software.
Vises derivadas deste
ponto de vista contm decises sobre o modelo de dados

e sobre o armazenamento, manipulao, gerenciamento e
distribuio das informaes ao longo da vida do sistema
em produo.
Operacional: representa os aspectos operacionais do software. Ou seja, vises derivadas deste ponto de vista contm decises com estratgias de execuo, administrao
e suporte do software em produo.
8.3.3
Viewtypes
stitute
(SEI)
do
Software Engineering In-
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 documentao, ao contrrio da
maioria descrita na literatura, que tm seu foco no auxlio do
projeto da arquitetura.
O conjunto do SEI possui apenas trs pontos de vista, que
devem ser especializados por meio dos chamados estilos arquiteturais. Os pontos de vista deste conjunto so:
de Componentes e Conectores: este ponto de vista se preocupa em descrever os aspectos dinmicos e de comportamento e interaes entre os elementos da arquitetura.
nele em que encontramos os estilos arquiteturais: Pipesand-lters, Publish-Subscribe, Cliente-Servidor, Peer-toPeer e outros.
CHAPTER 8.
226
DOCUMENTAO DA
ARQUITETURA
de Mdulos: este ponto de vista se preocupa em descrever a estrutura esttica da arquitetura e em como ela
se divide em unidades de cdigo.
O estilo arquitetural
Camadas uma especializao desse ponto de vista.
de Alocao:
este ponto de vista se preocupa em de-
screver as relaes entre o software e o seu ambiente. O

ponto de vista de Alocao se especializa em trs aspectos
diferentes: aspectos de implantao, que descreve as relaes entre as partes do software e os recursos fsicos utilizados (como servidores ou roteadores); aspectos de implementao, que descreve o mapeamento das partes do
software e as partes do cdigo (como pacotes, classes ou
estrutura de diretrios); e aspectos de atribuio de trabalho, relacionados distribuio de responsabilidades
do projeto entre os membros do time de desenvolvimento.
8.4 Documentando a Arquitetura

A partir dos conceitos de decises, vises e pontos de vista arquiteturais, 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 interessados na arquitetura.
Esse conhecimento um parmetro
fundamental para o processo de escolha dos pontos de vista a

serem usados. Depois de denir os pontos de vista relevantes
aos stakeholders da arquitetura, devemos ento registrar as decises arquiteturais que descrevem o design em vises derivadas
a partir dos pontos de vista escolhidos.
Devemos observar que os processos de denio dos stakeholders, de escolha dos pontos de vista arquiteturais e de descrio
das decises em vises so dependentes do processo de desenvolvimento seguido pelo time de desenvolvimento. Alm disso,
apesar de descrevermos separadamente o processo de documen-

227
tao do processo de design, possvel (e bastante comum) que

ocorram em paralelo, uma vez que a documentao e o design
se ajudam mutuamente para alcanar seus objetivos.
Praticamos
os
conceitos
apresentados
neste
captulo
no
Apndice onde ilustramos o documento de arquitetura do

SASF.
8.4.1 Diculdades da Documentao

Apesar dos benefcios proporcionados pela documentao da
arquitetura, document-la no fcil.
A diculdade de doc-
umentar a arquitetura reside, principalmente, em trs caractersticas que descrevemos a seguir:
o documento reete o tamanho da soluo;
custoso manter o documento consistente com o design
o documento reete a complexidade do design da soluo;
atual ao longo do ciclo de vida do software.
8.4.1.1 O tamanho do documento

Projetos de grandes sistemas de software so os que mais se
beneciam com o design e com a documentao da arquitetura.
Isto ocorre porque o design e a documentao propor-
cionam orientao na implementao dos requisitos de qualidade, ajuda no controle intelectual sobre a complexidade da
soluo e servem de ferramenta que promove a integridade conceitual entre os stakeholders.
No entanto, um grande sistema de software implica numa
grande soluo de design, que deve conter muitas decises arquiteturais e que devem ser apresentadas a muitos stakeholders, que demandam vises diferentes. A consequncia disso
228
CHAPTER 8.
DOCUMENTAO DA
ARQUITETURA
que a arquitetura de um grande sistema dever ser apresentada

em um documento extenso.
Documentos muito extensos podem ser fonte de alguns problemas durante o processo de desenvolvimento.
Entre estes
problemas, podemos citar que eles levam muito tempo para

serem construdos e que, em geral, geram uma certa resistncia para serem lidos ou atualizados durante o desenvolvimento.
Se o documento no lido ou no atualizado durante o desenvolvimento (e isso pode ocorrer porque a arquitetura pode
evoluir ao longo do tempo, seja a evoluo planejada ou no),
ele corre o risco de car inconsistente com a realidade do software, tornando-se uma fonte de informao intil e, portanto,
deixando de proporcionar as vantagens de se projetar e documentar a arquitetura.
8.4.1.2 A complexidade do documento

Tanto o tamanho do documento quanto a complexidade do
design inuenciam na complexidade do documento da arquitetura. Um documento muito complexo, que usa muitas vises
e diferentes linguagens para descrever diferentes aspectos do
software, difcil de se construir e de se manter consistente em
caso de mudanas durante a evoluo da arquitetura.
Como j mencionamos anteriormente, existem tcnicas de vericao de conformidade entre o documento de arquitetura e
o software implementado a partir dele, que podem ajudar na
manuteno da consistncia do documento com a realidade.
No entanto, devemos nos lembrar que h tambm o esforo de
se manter as diferentes vises arquiteturais consistentes entre
si. Isso pode at ser facilitado se usarmos algumas linguagens
especcas e ferramentas para descrever as decises arquitetu-
12
rais, como a ferramenta SAVE
12 Software
Architecture
. Por outro lado, estas lingua-
Visualization
and

Evaluation
229
gens no so capazes de descrever todos os tipos necessrios de

decises arquiteturais e isso limita o processo de automao na
manuteno de consistncia entre vises, tornando-o custoso.
8.4.1.3 Consistncia entre o design atual e o documento

A
consistncia
entre
implementao
documento
condio fundamental para que o processo de desenvolvimento

se benecie da arquitetura.
Por isso, deve existir um es-
foro para a manuteno desta consistncia, tanto durante a

evoluo da arquitetura, quanto durante a implementao do
software.
Se a manuteno da consistncia no realizada,
temos o chamado deslize arquitetural ( architectural drift).

O deslize arquitetural a inconsistncia entre implementao
do software e o design planejado. Esta inconsistncia tem dois
efeitos. O primeiro que se a implementao no est seguindo
o que foi planejado, ela pode tambm no estar alcanando
os objetivos propostos.
J o segundo, como foi mencionado
anteriormente, que a inconsistncia do documento com a realidade do software, inutiliza o documento, pois o transforma
numa fonte de informao intil. Assim, considerando que
custoso o processo de criao do documento de arquitetura,
todo o trabalho realizado para tanto pode ter sido em vo.
Para a evitar o deslize arquitetural, recomenda-se que sejam
periodicamente utilizadas durante todo o processo de desenvolvimento tcnicas de vericao de conformidade. Essas tcnicas, quando aplicadas, indicam se a implementao est de
acordo com o design.
H basicamente dois tipos de tcnicas
de vericao de conformidade: as tcnicas manuais, que so

baseadas em inspees do cdigo; e as tcnicas automticas,
que s podem ser realizadas se a descrio da arquitetura uti(SAVE):
http://fc-md.umd.edu/save/default.asp
md.umd.edu/save/default.asp>)

(<http://fc-
CHAPTER 8.
230
DOCUMENTAO DA
ARQUITETURA
lizar linguagens que permitam esse tipo de vericao. Assim

como os tipos de anlise arquitetural, as tcnicas de vericao manuais so mais custosas, mas tm um maior alcance,
podendo vericar aspectos do software que no so formalizados. J as tcnicas de vericao automticas, se beneciam
do baixo custo, mas so limitadas aos aspectos que podem ser
descritos pelas linguagens formais que utilizam.
8.5 Resumo
O objetivo deste livro no s fazer com que o leitor saiba
projetar arquiteturas, mas tambm que tenha noes de como
documentar o projeto. Dessa maneira, o objetivo deste captulo foi fazer com que o leitor conhea a importncia e a tcnica
primordial da documentao da arquitetura, que representla por meio de mltiplas vises. Assim, esperamos que a partir
de agora o leitor, alm de conhecer alguns conjuntos de pontos
de vista arquiteturais de referncia, seja capaz de entender que:
O documento de arquitetura auxilia no processo de design, uma ferramenta de comunicao entre stakeholders e pode servir de modelo de anlise do software;
Toda informao presente numa arquitetura uma deciso arquitetural;

ou executivas;

ou ser alternativa a outras decises arquiteturais; e
Um nico diagrama no suciente para conter a quantidade de informao que deve ser mostrada por um arquiteto. Por isso, a necessidade de mltiplas vises arquiteturais;

231
8.6 Referncias
8.6.1 Benefcios da documentao
Muitos autores armam que a documentao do design arquitetural benca para o processo de desenvolvimento do software. Alm dos trabalhos j referenciados ao longo do texto,
citamos: o livro The Art of Systems Architecting [69] de Maier
e Rechtin, que descreve os benefcios proporcionados quando
o documento de arquitetura consistente entre suas mltiplas
vises; o artigo de Wirfs-Brock, Connecting Design with Code
[108], que cita a importncia de documentar as decises de design em diversos nveis de detalhe, inclusive o arquitetural; o
livro Software Architecture: Foundations, Theory, and Practice [104], de Taylor et al, que mostra este assunto de forma
bem abrangente; e o livro Code Complete [75], de McConnell,
que arma a arquitetura uma ferramenta para o controle da
complexidade do software.
8.6.2 Arquitetura como conjunto de decises

O documento de arquitetura descrito como um conjunto de
decises arquiteturais o tema de diversos artigos.
Entre
eles, podemos citar: Building Up and Reasoning About Architectural Knowledge [64], An Ontology of Architectural Design Decisions in Software Intensive Systems [65] e The Decision View's Role in Software Architecture Practice [63], de
Kruchten et al e que so focados em descrever a arquitetura
como decises arquiteturais e em montar um arcabouo conceitual de como descrever decises arquiteturais, propondo inclusive um ponto de vista neste sentido; Architecture Knowledge Management: Challenges, Approaches, and Tools [9], de
Babar e Gorton, que mostram ferramentas para organizar e
documentar as decises arquiteturais; e The Decision View of
Software Architecture [38], de Dueas e Capilla, e Software
CHAPTER 8.
232
DOCUMENTAO DA
ARQUITETURA
Architecture as a Set of Architectural Design Decisions [55],

de Jansen e Bosch, que mostram a importncia das decises
na arquitetura.
8.6.3 Vises e pontos de vista

Alm dos trabalhos que apresentam conjuntos de pontos de
vista e que j foram referenciados na Seo "Vises arquiteturais" (Section 8.3: Vises arquiteturais), podemos citar o livro
Software Design [22], de Budgen, que arma que diferentes representaes lidam com diferentes qualidades e interesses, alm
de mostrar alguns benefcios de se documentar a arquitetura
por meio de vises. J o artigo Four Metaphors of Architecture in Software Organizations: Finding Out the Meaning of
Architecture in Practice [98], de Smolander, descreve como alguns stakeholders percebem a arquitetura na prtica e assim
justica o uso de vises arquiteturais. Por m, citamos o livro
Applied Software Architecture [50], de Hofmeister et al, que
apresenta mais um conjunto de pontos de vista.
8.6.4 Ferramentas para anlise

Em relao a anlises baseadas em inspees, citamos o livro
da srie do SEI, Evaluating Software Architectures [33], de
Clements et al, que descreve os mtodos SAAM, ATAM e
ARID, inclusive com estudos de casos.
J sobre ADLs, citamos dois surveys sobre o assunto: um conduzido por Clements, A Survey of Architecture Description
Languages [29], e outro por Taylor e Medvidovic, A Classication and Comparison Framework for Software Architecture
Description Languages [77].
E, nalmente, apresentamos alguns trabalhos sobre vericao
de conformidade:
Software Reexion Models:

Bridging The
233
Gap Between Design and Implementation [78] e Software Reexion Models: Bridging The Gap Between Source and HighLevel Models [79], por Murphy et al; Bridging the Software
Architecture Gap [66], de Lindvall e Muthig; e Design tests:
An approach to programmatically check your code against design rules [21], de Brunet et al.

234
GLOSSARY
Glossary
A arquitetura de
software
ou de um conjunto
de funes do
Arquitetura a
organizao
fundamental de
um sistema
software.
D deciso arquitetural
Uma escolha entre
incorporada em
as alternativas de
seus componentes,
design
seus
arquitetural. Essa
relacionamentos
escolha se prope a
com o ambiente, e
alcanar um ou
os princpios que
mais atributos de
conduzem seu
qualidade do
design e evoluo.
sistema, por meio
atributo de
qualidade
uma propriedade
de qualidade do
software ou de seu
ciclo de
desenvolvimento,
da(s) estrutura(s)
arquiteturais que
ela envolve ou
dene.
M modelo de qualidade
Modelo que dene e
podendo se
organiza os
manifestar como
atributos do
caractersticas,
software
capacidades ou
importantes para a
restries de uma
avaliao de sua
funo especca
qualidade.

GLOSSARY
235
P ponto de vista
arquitetural
um arcabouo
conceitual que
dene elementos,
conexes e tcnicas
que compem uma
viso arquitetural,
Requisito que
restringe o
processo de
desenvolvimento
do software.
requisito
no-funcional de
produto
alm especicar
Requisito que
seu propsito de
especica as
acordo com seus
caractersticas que
interessados.
um sistema ou
R rastreamento de
requisitos
o processo/capacidade
de ligar requisitos
subsistema deve
possuir.
requisito
no-funcional
externo
Requisito derivado
do sistema a
do ambiente em
estruturas
que o sistema
arquiteturais.
desenvolvido, que
requisito funcional
a declarao de
uma funo ou
comportamento
providos pelo
sistema sob
condies
especcas.
requisito
no-funcional de
processo
pode ser tanto do

produto quanto do
processo.
requisito
no-funcional
a descrio de
propriedades,
caractersticas ou
restries que o
software apresenta
exibidas por suas
funcionalidades.

236
GLOSSARY
S stakeholder
Descreve a
Um stakeholder em
uma arquitetura
de software uma
pessoa, grupo ou
entidade com um
interesse ou
preocupaes sobre
a realizao da
arquitetura.
13
V viso arquitetural
a representao
arquitetura do
software ou, em
poucas palavras,
como o software
decomposto e
organizado em
mdulos e suas
relaes.
design de software
" tanto o processo
de denio da
arquitetura,
do sistema ou de
mdulos, interfaces
parte dele da
e outras
perspectiva de um
caractersticas de
conjunto de
um sistema quanto
interesses
o resultado desse
relacionados.
processo.
A alternativa de design
Uma possibilidade
14
design detalhado
Descreve o
comportamento
de soluo
especco e em
representada em
detalhes dos
nvel de
mdulos que
conhecimento.
compem o design
D design arquitetural
arquitetural.
13 N. Rozanski and E. Woods.
Software Systems Architecture: Working

With Stakeholders Using Viewpoints and Perspectives, Addison-Wesley
Professional 2005.
14 Freny Katki
et al, editors. IEEE Standard Computer Dictionary:

Compilation of IEEE Standard Computer Glossaries. Institute of Electrical and Electronics Engineers Inc., 1991.
GLOSSARY
237
O objetivo de design
Aquilo que se
pretende alcanar
para resolver as
especcas.
requisito
no-funcional
a descrio de
necessidades do
propriedades,
cliente.
caractersticas ou
R representao de
design
restries que o
software apresenta
exibidas por suas
A linguagem do
processo de design
que representa o
produto do design
para sua
construo e
tambm d
suporte ao
processo de design
como um todo.
requisito funcional
a declarao de
funcionalidades.
restrio de design
A regra, requisito,
relao, conveno,
ou princpio que
dene o texto do
processo de design.
S soluo do design
A descrio do
design que permite
a construo do
uma funo ou
sistema de
comportamento
software que
providos pelo
alcana os
sistema sob
objetivos do
condies
design.

238
BIBLIOGRAPHY

Bibliography
[1]
IEEE Standard Computer Dictionary: Compilation of

IEEE Standard Computer Glossaries. Institute of Electrical and Electronics Engineers Inc., The, 1991.
[2]
Software Evolution.
[3] IEEE Std 754-2008.
Arithmetic.
Springer, March 2008.
IEEE Standard for Floating-Point
Institute of Electrical and Electronics Engi-
neers, 2008.
Software engineering 8211; Product

quality 8211; Part 1: Quality model. International Orga-
[4] ISO 9126-1:2001.
nization for Standardization, Geneva, Switzerland.

[5] Alain Abran, James W. Moore, Pierre Bourque, Robert
Guide to the Software Engineering Body of Knowledge (SWEBOK). IEEE, 2004.

Dupuis, and Leonard L. Tripp.
Department of Defense Joint Technical Architecture, Version 6.0. Volume

2. U.S. Department of Defense, October 2003.
[6] Defense Information Systems Agency.
[7] Robert Allen and David Garlan. A formal basis for architectural connection.
ACM Trans. Softw. Eng. Methodol.,
6(3):2138211;249, July 1997.

[8] Andy and Kai Qian.
Component-Oriented Programming.
Wiley-Interscience, March 2005.

239
240
BIBLIOGRAPHY
[9] Muhammad A. Babar and Ian Gorton.

knowledge management:
Architecture
Challenges, approaches, and
Software Engineering - Companion, 2007.

ICSE 2007 Companion. 29th International Conference
on, page 1708211;171, 2007.
tools.
In
[10] Len Bass, Paul Clements, and Rick Kazman.
Software
Architecture in Practice. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1998.
Architecture in Practice.
Software
Addison-Wesley Professional, 2
edition, April 2003.

Architecture in Practice.
Software
Addison-Wesley Professional, 2

ware Architecture in Practice, Second Edition.
Soft-
Addison-
Wesley Professional, April 2003.

ware Architecture in Practice, Second Edition.
Soft-
Addison-
Wesley Professional, April 2003.
Software Design: Methods and

Techniques (L.J. Peters, author). Yourdon Press, 1981.
[15] L. Belady. Foreword. In
[16] B. W. Boehm, J. R. Brown, and M. Lipow.

tative evaluation of software quality.
Conference on Software Engineering,
In
Quanti-
International
page 5928211;605,
San Francisco, 1976. IEEE Computer Society Press.

[17] G.
Booch.
Goodness
of
t.
Software, IEEE,
23(6):148211;15, 2006.

BIBLIOGRAPHY
241
[18] Grady Booch. The irrelevance of architecture.
IEEE, 24(3):108211;11, 2007.
Software,
[19] Grady Booch, Robert A. Maksimchuk, Michael W. Engel, Bobbi J. Young, Jim Conallen, and Kelli A. Houston.
Object-Oriented Analysis and Design with Applications

(3rd Edition). Addison-Wesley Professional, April 2007.
The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition.
[20] Frederick P. Brooks.
Addison-Wesley Professional, August 1995.

[21] J. Brunet,
D. Guerrero,
and J. Figueiredo.
Design
tests: An approach to programmatically check your code
Software Engineering - Companion Volume, 2009. ICSE-Companion 2009. 31st International Conference on, page 2558211;258, 2009.
against design rules. In
[22] David Budgen.
Software Design.
Addison Wesley, 2 edi-
tion, May 2003.

[23] David Budgen.
Software Design (2nd Edition).
Addison
Wesley, May 2003.

[24] Frank
Buschmann,
Kevlin
Henney,
and
Douglas
C.
Kevlin
Henney,
and
Douglas
C.
Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing.

Schmidt.
Wiley, May 2007.

[25] Frank
Buschmann,
Pattern Oriented Software Architecture Volume 5: On Patterns and Pattern Languages. Wiley, June
Schmidt.
2007.
[26] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter
Sommerlad, Michael Stal, Peter Sommerlad, and Michael
Pattern-Oriented Software Architecture, Volume 1:

A System of Patterns. John Wiley & Sons, August 1996.
Stal.

242
BIBLIOGRAPHY
[27] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter

Sommerlad, Michael Stal, Peter Sommerlad, and Michael
Pattern-Oriented Software Architecture, Volume 1:

A System of Patterns. John Wiley & Sons, August 1996.
Stal.
[28] J. N. Buxton and B. Randell. Software engineering techniques.
Technical report, NATO Science Committee,
Rome, Italy, April 1970.

[29] P. C. Clements.
A survey of architecture description
languages. In Software Specication and Design, 1996.,

Proceedings of the 8th International Workshop on, page
168211;25, 1996.
[30] Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, and Judith
Documenting Software Architectures: Views

and Beyond. Addison-Wesley Professional, September
Staord.
2002.

Staord.
2002.

Staord.
2002.
Evaluating Software Architectures: Methods and Case Studies.
[33] Paul Clements, Rick Kazman, and Mark Klein.

Addison-Wesley Professional, January 2002.

BIBLIOGRAPHY
243
[34] J. Dean and S. Ghemawat. Mapreduce: Simplied data
6th Symposium on Operating

Systems Design & Implementation (OSDI8217;04), 2004.
processing on large clusters.
Open
[35] Chris Dibona, Mark Stone, and Danese Cooper.
Sources 2.0 : The Continuing Evolution. O'Reilly Media,
Inc., October 2005.

[36] Edsger
W.
Dijkstra.
multiprogramming
The
structure
of
the
the-
structure
of
the
the-
Commun.
system.
ACM,
11(5):3418211;346, 1968.
[37] Edsger
W.
Dijkstra.
multiprogramming
The
Commun.
system.
ACM,
11(5):3418211;346, 1968.
[38] Juan C. Due[U+FFFD]nd Rafael Capilla.
The decision
view of software architecture. page 2228211;230. 2005.

[39] George Edwards, Sam Malek, and Nenad Medvidovic.
Scenario-driven dynamic analysis of distributed architectures. page 1258211;139. 2007.
[40] S. G. Eick, T. L. Graves, A. F. Karr, J. S. Marron, and
A. Mockus.
Does code decay?
assessing the evidence
Software Engineering,
IEEE Transactions on, 27(1):18211;12, 2001.
from change management data.
Architectural Styles and the Design of

Network-based Software Architectures. Ph. d. thesis, Uni-
[41] Roy T. Fielding.
versity of California, Irvine, 2000.

[42] Brian Foote and Joseph W. Yoder. Big ball of mud. In
Pattern Languages of Program Design,
volume 4, page
6548211;692. Addison Wesley, 2000.

[43] M. Fowler. Design - who needs an architect?
IEEE, 20(5):118211;13, 2003.

Software,
244
BIBLIOGRAPHY
[44] Martin Fowler.
tecture.
Patterns of Enterprise Application Archi-
Addison-Wesley Professional, November 2002.
[45] David Garlan and Mary Shaw. An introduction to software architecture.
Technical report, Pittsburgh, PA,
USA, 1994.
[46] David Garlan and Mary Shaw. An introduction to software architecture.
Technical report CMU-CS-94-166,
Carnegie Mellon University, Pittsburgh, PA 15213-3890,

January 1994.
[47] Ian Gorton.
Essential Software Architecture.
Springer,
Essential Software Architecture.
Springer,
June 2006.
[48] Ian Gorton.
June 2006.
[49] Todd Ho. High scalability: Building bigger, faster, more
reliable websites. http://highscalability.com.
[50] Christine Hofmeister, Robert Nord, and Dilip Soni.
plied Software Architecture.
Ap-
Addison-Wesley Profes-
sional, November 1999.
Beyond Software Architecture: Creating and Sustaining Winning Solutions. Addison-Wesley
[51] Luke Hohmann.
Professional, January 2003.
Beyond Software Architecture: Creating and Sustaining Winning Solutions. Addison-Wesley
[52] Luke Hohmann.
Professional, January 2003.

[53] IEEE and ISO/IEC. Systems and software engineering
- recommended practice for architectural description of
ISO/IEC 42010 IEEE Std

1471-2000 First edition 2007-07-15, page c18211;24, July
software-intensive systems.
2007.
BIBLIOGRAPHY
245
[54] IEEE and ISO/IEC. Systems and software engineering

- recommended practice for architectural description of
ISO/IEC 42010 IEEE Std

1471-2000 First edition 2007-07-15, page c18211;24, July
software-intensive systems.
2007.
[55] A. Jansen and J. Bosch. Software architecture as a set
Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference on, page 1098211;120, Washington, DC, USA,
of architectural design decisions.
In
2005. IEEE Computer Society.

[56] D. Kalinsky and J. Ready. Distinctions between requirements specication and design of real-time systems. In
Software Engineering for Real Time Systems, 1989., Second International Conference on, page 268211;30, 1989.
Real-Time Systems: Design Principles

for Distributed Embedded Applications. Springer, April
[57] Hermann Kopetz.

1997.
[58] Gerald Kotonya and Ian Sommerville.
Requirements En-
gineering: Processes and Techniques. John Wiley & Sons,

September 1998.
[59] P. Kruchten. The software architect 8211; and the soft-
Software Architecture; TC2

First Working IFIP Conference on Software Architecture
(WICSA1), 2:5658211;583.
ware architecture team.
[60] P. Kruchten, H. Obbink, and J. Staord.

present, and future for software architecture.
IEEE, 23(2):228211;30, 2006.

[61] P. B. Kruchten.
The past,
Software,
The 4+1 view model of architecture.
Software, IEEE, 12(6):428211;50, 1995.

246
BIBLIOGRAPHY
[62] P. B. Kruchten.
The 4+1 view model of architecture.
Software, IEEE, 12(6):428211;50, 1995.
[63] Philippe
Kruchten,
Rafael
Capilla,
and
Juan
C.
Duex00f1;as. The decision view's role in software architecture practice.
IEEE Software, 26(2):368211;42, 2009.
[64] Philippe Kruchten, Patricia Lago, Hans van Vliet, and

Timo Wolf.
Building up and exploiting architectural
knowledge.
In
WICSA '05: Proceedings of the 5th

Working IEEE/IFIP Conference on Software Architecture (WICSA'05), page 2918211;292, Washington, DC,
USA, 2005. IEEE Computer Society.
[65] Philippe Krutchen. An ontology of architectural design
2nd Groningen
Workshop Software Variability, page 548211;61, October
decisions in software intensive systems. In
2004.
[66] M. Lindvall and D. Muthig. Bridging the software architecture gap.
Computer, 41(6):988211;101, June 2008.
[67] John D. C. Little. A proof for the queuing formula: L=

w.
Operations Research, 9(3):3838211;387, 1961.
[68] Mark W. Maier and Eberhardt Rechtin.
tems Architecting.
CRC, 2 edition, June 2000.
[69] Mark W. Maier and Eberhardt Rechtin.
tems Architecting.
[70] Ruth
ing
Malan
The Art of SysThe Art of Sys-
CRC, 2 edition, June 2000.
and
non-functional
Dana
Bredemeyer.
requirements.
DenOnline
at:
http://www.bredemeyer.com/pdf_les/NonFunctReq.PDF,
August 2001.

BIBLIOGRAPHY
247
[71] Matthew R. McBride. The software architect: Essence,
OOPSLA '04: Companion to the 19th annual ACM SIGPLAN conference

on Object-oriented programming systems, languages, and
applications, page 2308211;235. ACM Press, 2004.
intuition, and guiding principles. In
Factors in Software Quality: Preliminary

Handbook on Software Quality for an Acquisiton Manager, volume 1-3. General Electric, November 1977.
[72] J. McCall.
Code Complete.
[73] Steve McConnell.
Microsoft Press, 2
edition, June 2004.

Code Complete.
Microsoft Press, sec-
ond edition, June 2004.
Code Complete.
Microsoft Press, 2
edition, June 2004.
Code Complete, Second Edition.
[76] Steve Mcconnell.
Mi-
crosoft Press, June 2004.

[77] N. Medvidovic and R. N. Taylor.
A classication and
comparison framework for software architecture description languages.
Software Engineering, IEEE Transac-
tions on, 26(1):708211;93, 2000.
[78] G. C. Murphy, D. Notkin, and K. J. Sullivan. Software

reexion models: Bridging the gap between design and
Software Engineering, IEEE Transactions on, 27(4):3648211;380, April 2001.

implementation.
[79] Gail C. Murphy, David Notkin, and Kevin Sullivan. Software reexion models: Bridging the gap between source
SIGSOFT '95: Proceedings

of the 3rd ACM SIGSOFT symposium on Foundations
of software engineering, page 188211;28, New York, NY,
and high-level models.
In
USA, 1995. ACM.

248
BIBLIOGRAPHY
[80] Inc. Object Management Group. Unied modeling language. http://www.uml.org, September 2008.
[81] D. L. Parnas. On the criteria to be used in decomposing
systems into modules.
Classics in Software Engineering,
page 1398211;150.
[82] D. L. Parnas. On the criteria to be used in decomposing
systems into modules.
Classics in Software Engineering,
page 1398211;150, 1979.
ICSE '94: Proceedings of the 16th international conference on Software

engineering, page 2798211;287, Los Alamitos, CA, USA,
[83] David L. Parnas.
Software aging.
In
1994. IEEE Computer Society Press.

[84] Dewayne E. Perry and Alexander L. Wolf. Foundations
SIGSOFT Software Engineering Notes, 17(4):408211;52, October 1992.
for the study of software architecture.
[85] Andy Powell, Mikael Nilsson, Ambjrn Naeve, Pete Johnston, and Thomas Baker. Dcmi abstract model. DCMI
Recommendation, June 2007.
[86] Roger Pressman.
Approach.
Software Engineering: A Practitioner's
McGraw-Hill Science/Engineering/Math, 6

[87] Jack W. Reeves. What is software design?
C++ Journal,
1992.
Software Systems
Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Addison-Wesley Professional,
[88] Nick Rozanski and E[U+FFFD]oods.
April 2005.

BIBLIOGRAPHY
249
Software Systems
April 2005.
Software Systems
April 2005.
Software Systems
April 2005.
Software Systems
April 2005.
[93] Jungwoo Ryoo, Phil Laplante, and Rick Kazman.
In
search of architectural patterns for software security.
Computer, 42(6):988211;100, 2009.
[94] Yasushi Saito and Marc Shapiro. Optimistic replication.
ACM Comput. Surv., 37(1):428211;81, March 2005.
[95] Douglas Schmidt,
Michael Stal,
Hans Rohnert,
and
Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked

Objects. John Wiley & Sons, September 2000.
Frank Buschmann.
[96] Bart Smaalders.
Performance anti-patterns.
Queue,
4(1):448211;50, 2006.
[97] G. F. Smith and G. J. Browne. Conceptual foundations
of design problem solving.
Systems, Man and Cybernet-
ics, IEEE Transactions on, 23(5):12098211;1219, 1993.

250
BIBLIOGRAPHY
[98] Kari Smolander. Four metaphors of architecture in software organizations: Finding out the meaning of architec-
ISESE '02: Proceedings of the 2002

International Symposium on Empirical Software Engineering, Washington, DC, USA, 2002. IEEE Computer
ture in practice. In
Society.
Software Engineering (7th Edition)

(International Computer Science Series). Addison Wes-
[99] Ian Sommerville.

ley, May 2004.
[100] Ian Sommerville.
Software Engineering. Addison Wesley,
8 edition, June 2006.
Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty

in Software Design. O'Reilly Media, Inc., January 2009.
[101] Diomidis Spinellis and Georgios Gousios.
[102] R. N. Taylor, Nenad Medvidovi, and Irvine E. Dashofy.
Software Architecture: Foundations, Theory, and Practice. John Wiley & Sons, January 2009.
[105] Richard N. Taylor and Andre van der Hoek. Software design and architecture 8211; the once and future focus of
software engineering. In
ware Engineering,
FOSE '07: 2007 Future of Soft-
page 2268211;243, Washington, DC,
USA, 2007. IEEE Computer Society.

[106] Facebook
Team.
Engineering
facebook.
http://www.facebook.com/notes.php?id=9445547199.
BIBLIOGRAPHY
251
[107] Jilles van Gurp and Jan Bosch.

lems and causes.
Design erosion: prob-
Journal of Systems and Software,
61(2):1058211;119, March 2002.

[108] Rebecca J. Wirfs-Brock. Connecting design with code.
Software, IEEE, 25(2):208211;21, 2008.

252
INDEX
Index of Keywords and Terms

Keywords
are listed by the section with that keyword
(page numbers are in parentheses).
Keywords do not
necessarily appear in the text of the page.

merely associated with that section. Ex.
(1)
Ex.
Terms
They are
apples, 1.1
are referenced by the page they appear on.
apples, 1
1 1471, 4(55), 8(189)

4 4+1, 8(189)
A alternativa de design, 23
design de alto nvel,

4(55)
design de alto-nvel,
7(165)
arquitetura de software,
design de software,
1(1), 4(55), 68,
2(9), 13, 7(165)
5(105), 6(125),
design detalhado, 30
8(189)
documentao, 8(189)
atributo de qualidade,
137
atributos de qualidade,
1(1), 2(9), 4(55),
3(41), 4(55),
5(105), 6(125)
6(125)
engenharia de software,
escalabilidade, 7(165)
compreensibilidade,
estilos arquiteturais,
7(165)
7(165)
D deciso arquitetural, 74,

8(189)
estudo de caso, 3(41)
H high level design,

4(55)
desempenho, 7(165)
design arquitetural, 30,
4(55), 7(165)
integridade conceitual,
8(189)

INDEX
253
interessados, 5(105)
20, 128
ISO 9126-1:2001,
requisito no-funcional
6(125)
de processo, 130
M modelo de qualidade,
de produto, 130
6(125), 142
modicabilidade,
externo, 131
7(165)
requisitos, 3(41),
N nveis de abstrao,
5(105), 6(125)
requisitos
7(165)
no-funcionais, 6(125)
O objetivo de design, 19
operabilidade, 7(165)
padres arquiteturais,
restrio de design, 21
segurana, 7(165)
separao de
7(165)
preocupaes, 7(165)
ponto de vista
software, 2(9),
arquitetural, 8(189),
8(189)
222
software architecture,
princpios de design,
4(55)
2(9)
software engineering,
projeto arquitetural,
4(55)
7(165)
soluo do design, 28
projeto de alto nvel,
stakeholder, 111
7(165)
stakeholders, 4(55),
projeto de software,
5(105)
7(165)
streaming, 3(41)
Q qualidade, 6(125)
R rastreamento de
requisitos, 76
representao de design,
25
requisito funcional, 19,
126
tolerncia a faltas,
7(165)
tcnicas de design
arquitetural, 7(165)
V video, 3(41)
viso arquitetural, 89,
8(189)
requisito no-funcional,
254
ATTRIBUTIONS
Attributions
Collection: Arquitetura de Software
Edited by: Guilherme Germoglio
URL: http://cnx.org/content/col10722/1.9/
License: http://creativecommons.org/licenses/by/3.0/
Module: "Mensagens do Livro"
By: Guilherme Germoglio
URL: http://cnx.org/content/m17526/1.7/
Pages: 1-8
Copyright: Guilherme Germoglio
Module: "Introduo a Design de Software"
Pages: 9-39
Module: "Estudo de Caso: SASF"
Pages: 41-53
Module: "Fundamentos de Arquitetura de Software"
Pages: 55-103

ATTRIBUTIONS
Module: "Stakeholders"
Pages: 105-123
Module: "Atributos de Qualidade"
Pages: 125-164
Module: "Tcnicas de Design Arquitetural"
Pages: 165-188
Module: "Documentao da Arquitetura"
Pages: 189-233

255
Um livro de Arquitetura de Software para alunos de graduao.
About Connexions
Since 1999, Connexions has been pioneering a global system
where anyone can create course materials and make them fully
accessible and easily reusable free of charge. We are a Webbased authoring, teaching and learning environment open to
anyone interested in education, including students, teachers,
professors and lifelong learners. We connect ideas and facilitate
educational communities.
Connexions's modular, interactive courses are in use worldwide by universities, community colleges, K-12 schools, distance learners, and lifelong learners.
Connexions materials
are in many languages, including English, Spanish, Chinese,

Japanese, Italian, Vietnamese, French, Portuguese, and Thai.
Connexions is part of an exciting new information distribution system that allows for
Print on Demand Books.
Con-
nexions has partnered with innovative on-demand publisher

QOOP to accelerate the delivery of printed course materials
and textbooks into classrooms worldwide at lower prices than
traditional academic publishers.

Arquitetura de Software 9.1

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Arquitetura de Software 9.1

Enviado por

Direitos autorais:

Formatos disponíveis

Arquitetura de Software

Available for free at Connexions

O contedo deste livro est dividido em seis captulos (alm dos

Alm de mensagens, h outros

dois tipos de elementos que so essenciais para a composio

1.1 Cap. 2: Introduo a Design de

independentemente do nvel de detalhe em que ele aplicado.

Um design representa apenas um ponto no espao de deciso.

Um design pode ser singular, representando apenas uma

So cinco os elementos que compem os problemas de

Design necessrio em todos os nveis de detalhe durante

1.2 Cap. 3: Estudo de Caso: SASF

Nele, apresentamos tanto os requisitos

de um sistema web de locao e transmisso de vdeos quanto

Available for free at Connexions

1.3 Cap. 4: Fundamentos de Arquitetura de Software

Alm da denio ISO/IEEE,

mostraremos outras denies que diversos autores zeram ao

Arquitetura design, mas nem todo design arquitetural.

o arquiteto quem dene a fronteira entre o

design arquitetural e o no-arquitetural, denindo quais

A arquitetura tambm um veculo de comunicao entre

A arquitetura contm as decises antecipadas de design,

A arquitetura uma abstrao transfervel do sistema.

A arquitetura facilita a evoluo do sistema.

Available for free at Connexions

Documentar a arquitetura ajuda no controle intelectual

Documentar a arquitetura ajuda a manter a integridade

A arquitetura do software restringe o vocabulrio de alternativas de design.

Documentar a arquitetura permite a ligao entre os requisitos e as decises de design do software.

Documentar a arquitetura ajuda na diviso de tarefas

1.4 Cap. 5: Stakeholders

Neste captulo apresentamos quem so os

stakeholders do software mais comuns e suas caractersticas.

maneiras e no necessariamente esto de acordo entre

Os seguintes stakeholders devem ser considerados durante o projeto da arquitetura:

o prprio arquiteto ou outros futuros arquitetos;

O arquiteto deve ter pleno conhecimento de todo o ciclo

O arquiteto deve enteder a relao entre os stakeholders

1.5 Cap. 6: Atributos de Qualidade

No existe a arquitetura correta. Existems arquiteturas

A arquitetura permite uma forma de rastreamento entre

A arquitetura de software permite diversos atributos de

1.6 Cap. 7: Tcnicas de Design Arquitetural

No entanto, no fomos explcitos sobre como estes

princpios e tcnicas so fundamentais ao processo de design

uso da abstrao ou nveis de complexidade

Alm disso, apresentamos diversas tticas arquiteturais para

1.7 Cap. 8: Documentao da Arquitetura

Toda informao presente numa arquitetura uma deciso arquitetural.

Decises arquiteturais podem ser existenciais, descritivas

Decises arquiteturais se relacionam, podendo restringir,

Por isso, a necessidade de mltiplas vises da

Available for free at Connexions

Por ser uma atividade de De-

maneira, este captulo procura fundamentar o conhecimento do

Reconhecer os conceitos bsicos de design de software

Identicar princpios de design de software e explicar seus

Diferenciar design de baixo-nvel (detalhado) de design

2.1 Design de Software

Em outras palavras, projetar o sistema antes de

como de atividade de design, tambm chamado de design.

Primeiro, ele possibilita

a avaliao do sistema contra seus objetivos antes mesmo dele

Alm da denio ISO/IEEE,

mostraremos outras denies que diversos autores zeram ao

o arquiteto quem dene a fronteira entre o

design arquitetural e o no-arquitetural, denindo quais

Identicar princpios de design de software e explicar seus

Denio 2.1: design de software

Por sinal, avaliar um design insucientemente de-

Por mais ecaz que um design seja, sua implementao pode

durante a fase de diversicao em que as alternativas so

haria de Software, a necessidade parte do cliente que especica

Denio 2.2: objetivo de design

Denio 2.3: requisito funcional

Denio 2.4: requisito no-funcional

locadora de lmes, um exemplo de atributo de qualidade a

Denio 2.5: restrio de design

Denio 2.6: alternativa de design