Mendes Estilos Arquiteturais

Prévia do material em texto

CAPÍTULO 2 
Estilos Arquiteturais 
Objetivos 
• Entender o que é um estilo arquitetural. 
• Apresenta r um conjunto de estilos arquiteturais que vem sendo 
usado em projetos de sistemas. 
• Identificar tl vantagens e desvantagens de cada estilo apresen-
tado, discutindo os compromissos assumidos quando um estilo 
é selecion,1clo em detrimento de outro. 
2.1 Introdução 
No capítulo anterior, verificamos que a arquitetura de software de um sist1· 
ma possui papel impmt.111te na obtenção de metas de qualidade e manutc:111h1 
!idade. A arquitetura dl' -.oftware de um sistema é composta de subsistt111.1-. 011 
componentes (respon sáveis pelo comportamento do sistema), de conectores 
(interligando os componentes) e de padrões de conexão (possibilitando vári -
os tipos de interação e compartilhamento de informações entre esses compo -
nentes): 
(~ pertinente aind.1 ,ll lT'>n'nt.1r que um sistema bem organizado exibe uma es-
t111tura l<'>gict e mud11l.11 lw111 l<>lll<> provê suporte à ocultação de informações. 
T,11., p1111l ip10-, l ,11,ll lt 111.1111 11111 prnjcto de software. Note que, ao utilizar uma 
nt 1111111 .1 111rnl1 il,11, .1-. de 1 1-.1 w-. d1 prnJeto deveriam ser tomadas isoladamente 
11111,1-, d,1., 111111 1 , , 1 111d11 111111111111, 11 o impacto de mudanças de uma decisão so-
lm· 0111 rn(s), p111 11111 d11 111 d 1111 "" d1 q11.1I idade de sistema que tem suma impor 
t.11111,1 '>ohre 1\111 l""i' 111 ili 1111\\ 111• t ,1 111od11laridade (Parnas, 1972). Nesse 
caso, a efetividade da organização de um sistema dependerá do(s) critério(s) usa-
do(s) para decompor o sistema em componentes. 
Observamos que à medida que os sistemas de software começaram a tor-
nar-se maiores e mais complexos, mais atenção foi dedicada à organização de tais 
sistemas. Ao longo de todo esse período no qual temos feito uso de sistemas de 
software, uma técnica fundamental utilizada pelos engenheiros (projetistas) tem 
sido a abstração. Ela nos permite entender questões complexas de projeto e re-
solver problemas, fazendo com que nos concentremos em um nível mais genéri-
co sem nos ater a detalhes irrelevantes à organização de sistemas. A abstração ain-
da nos possibilita trabalhar num problema, usando conceitos e termos que sejam 
familiares no domínio do problema antes de transformá-los em alguma estrutura 
de mais baixo nível. 
Desde seu uso inicial em sistemas (há aproximadamente quatro décadas), o 
software tem cada vez mais se constituído em um elemento pervasivo de nosso 
cotidiano. Ao longo de todo esse período da história do software, diversas arqui-
teturas foram usadas, muitas vezes informalmente, por engenheiros e projetistas 
de software sem que houvesse qualquer preocupação em cohlpreendê-las me-
lhor e tratá-las de forma sistemática a fim de identificar suas principais caracterís-
ticas, objetivando catalogá-las. O objetivo de organizar e expressar o conheci-
mento do projeto de software de maneira útil é uma necessidade natural do enge-
nheiro (projetista) de software. Uma forma de codificar tal conhecimento é dis-
por de um vocabulário do conjunto de conceitos (terminologia, propriedades, 
restrições), estruturas (componentes, conectores) e padrões de uso existentes. 
Ao caracterizar as arquiteturas de software que são utilizadas nos sistemas, 
identificando seus componentes, mecanismos de interação e propriedades, po-
demos classificá-las. Como resultado, isso nos possibilita o reuso desse conheci-
mento. No decorrer da década de 1990, houve uma crescente preocupação em 
compreender a organização dos sistemas de software, culminando com o surgi-
mento da área de arquitetura de software. Assim, começou-se a identificar famí-
lias de arquiteturas, isto é, classes de arquiteturas que possuíam aspectos e com-
ponentes peculiares a elas bem como formas de combiná-los. Isso caracteriza um 
l'"I do arquitetural. 
llm estilo arquitetural permite que um profissional (engenheiro, projetista 
e 111 .11 q11iteto de software ) determine a classe a qual pertence a organização de um 
.,,.,1l·111,1. C:.1racterísticas dos componentes (subsistemas) e conectores do sistema, 
111polog1,1 d.1 ,1rquitetura, restrições semânticas e mecanismos de interação entre 
m componentes ,1judam a identificar o estilo que retrata a arquitetura de softwa-
1 l' do sistema. 
Além disso, o estilo arquitetural pode ser utilizado como ponto de partida em 
11111 projeto, desde que tenhamos em mãos o conjunto de características desejadas 
p.11.1 o sistema a ser desenvolvido. Nesse caso, procura-se identificar qual estilo 
,11 quitetural provê suporte às características desejadas do sistema e, portanto, es-
L1ríamos reutilizando conhecimento e arquitetura de software (já catalogada) 
11..,,,da em algum projeto anterior da mesma ou outra instituição. O reuso de com-111 
(1 
ponentes (ou -..ubsistemas) integrados numa estrutura, caracterizando uma arqui-
tetura, surge rnmo benefício da classificação de arquiteturas de software. Retor-
naremos a esse tópico ainda neste capítulo e também no Capítulo 6. 
Cada estilo arquitetural oferece suporte a um conjunto de requisitos não-
funcionais e atributos de projeto que permitem distinguir uma arquitetura de ou-
tra. Por exemple>, considere o estilo arquitetural de camadas, o qual permite a de-
finição de vários níveis e implica um aumento da flexibilidade do sistema. Entre-
tanto, essa característica ocorre em detrimento de outra, isto é, o desempenho do 
sistema. Este é reduzido numa arquitetura de camadas. Note que o estilo mais 
apropriado a um sistema dependerá de seus requisitos, envolvendo requisitos 
funcionais e não-funcionais. Uma discussão mais detalhada é apresentada no Ca-
pítulo 3. 
A partir disso, pergunta-se qual a utilidade de termos estilos arquiteturais? É 
fácil perceber que possuir estilos arquiteturais bem definidos com suas caracte-
rísticas especificadas nos permite fazer um menor esforço para entender o proje-
to de sistema de outra pessoa e, portanto, reduz a quantidade de informações a 
serem assimiladas num novo projeto. 
Também há um interesse de compor um manual, a exemplo de outros que 
existem nas engenharias, a fim de que possamos consultá-lo e reutilizar conheci-
mentos e arquiteturas de projeto anteriores. Isso é um sinal de amadurecimento 
de um novo campo. Afinal, por que reinventar a roda? 
A seguir, um conjunto de estilos arquiteturais é apresentado, procurando 
identificar seus componentes, mecanismos de interação e propriedades. Obvia-
mente, não pretendemos ser completos quanto aos possíveis estilos existentes. 
Entretanto, esses estilos constituem aqueles mais proeminentes nos sistemas 
computacionais. Além disso, um conjunto de arquiteturas de software peculiares 
a alguns domínios específicos são apresentadas no Capítulo 6. 
2.2 Pipes e Filtros 
O estilo arquitetural de pipes e filtros geralmente considera a existência de uma 
rede pela qual flui dados de uma extremidade (origem) à outra (destino). O fluxo 
de dados se dá através de pipes e os dados sofrem transformações quando proces-
sados nos filtros. 
Um pipe provê uma forma unidirecional de fluxo de dados, uma vez que atua 
como um condutor para o fluxo de dados entre a fonte (extremidade de origem 
dos dados) até um destino (receptor de dados). O exemplo mais comumente co-
nheddo do estilo pipes e filtros é utilizado no sistema operacional Unix. 
A maioria dos usuários do sistema operacional Unix sabe como canalizar asa-
ída, resultante de um programa (progl), para a entrada de um outro programa 
(prog2). Isso poderia, facilmente, ser feito digitando-se a seguinte linha de co-
mando: 
12\ exemplol# progl I prog2 
O exemplo anterior ilustra um encadeamento da saída de um programa 
(progl) para a entrada de outro programa (prog2). Note que se trata de um meca-
nismo de comunicação (fluxo) de dados unidirecional. Um exemplo prático, ilus-
trando o uso de pipes e filtros no sistema operacional Unix, é apresentado a seguir: 
exemplo2# who I sort 
A linha de comando anterior executao programa who (apenas uma vez) e en-
caminha sua saída para o programa sort. O resultado do programa who é uma lis-
ta dos usuários que encontram-se conectados naquele instante enquanto o pro-
grama sort ordena essa lista de usuários em ordem alfabética (dos nomes de lo-
gin). Isso é mostrado na Figura 2.1. 
Filtros 
=f mgcama wh,l=I ====,====::-~rograma '°'li=====: 1~~ ~~~ ~ ~ ~~ i 
pipe 
Figura 2.1 Exemplo de pipes e filtros. 
Os dois programas who e sort constituem dois componentes e são denomina-
dm, de filtros, uma vez que realizam transformações no fluxo de entrada. Uma ou-
11.1 l°,1racterística interessante de um filtro é que ele começa a colocar a saída resul-
1.111tt· da transformação realizada no pipe antes que todos os dados de entrada se-
j,1111 totalmente consumidos. Perceba ainda que a saída do segundo filtro (progra-
111.1 sort ) poderia ser conduzida por um outro pipe conectado a um terceiro filtro 
(tl11.,trado através de um retângulo com linhas tracejadas na Figura 2.1). 
Uma seqüência de pipes e filtros geralmente é chamada de tubulação de pro-
' ,·s.-.;i1111ento, onde os filtros incrementam, extraem ou transformam os dados rece-
l11dos de alguma fonte de dados (que pode ser outro filtro) e os pipes conectam 
dn1~ filtros ou alguma fonte de dados e um filtro ou ainda um filtro a algum recep-
1111 dl' dados (isto é, a extremidade final de uma tubulação de processamento). 
E importante observar que o estilo de pipes e filtros constitui-se numa arqui-
11·1111,1 adequada para ser usada no projeto de um sistema que requer vários está-
1•,111.., de processamento, conforme vimos na Figura 2.1. Cada estágio de processa-
11 H'I ,to seria implementado, fazendo-se uso de um filtro, o qual recebe dados de 
ilg11111a fonte (podendo ser outro filtro), realiza alguma transformação sobre os 
d.ui os (extraindo ou acrescentando informações) e prod11z dados na saída, que 
,,111 1..111alizados por meio de pipe ao próximo estágio. / 13 
U t l·xemplo de uso do estilo arquitetural de pipes e filtros é encontra-m ouro · . . . 
do no modelo L l.íssico de compiladores (Garlan, 1993). Os primeiros compila-
dores realizavam, basicamente, duas funçõer a análise da linguagem fonte e a 
síntese do código <le máquina (Aho, 1987). A medida que o processo .de d~sen-
volvimento de compiladores foi sendo aprimorado, a função de anáhs~ foi de-
composta em três funções: análise lé~i~a'. ~nálise sintática e anál~se. se~ântica. 
Por outro lado a função de síntese foi dividida em duas etapas: otimizaçao e ge-
ração de códig~. Uma ilustração dessa arquitetura é mostrada na Figura 2.2. 
análise 
léxica 
análise 
sintática 
análise 
semântica 
otimização 
Figura 2.2 Decomposição de um compilador. 
geração 
de código 
A arquitetura de compilador apresentada anteriormente prevaleceu durante 
a década de 1970. Nesse tipo de arquitetura, cada etapa do processo de compila-
ção é realizada separadamente. Os resultados parciais de cada fase são encami-
nhados à etapa seguinte. Isso caracteriza o estilo arquitetural de pipes e filtros, no 
qual o compilado, e funcionalmente decomposto num conjunto de cinco com-
ponentes que est .10 associados às cinco fases do processo de compilação. Cada 
componente é visl o como um filtro em que ele efetua uma transformação sobre 
os dados de entrad .1 resultando em dados de saída, os quais são canalizados atra-
vés de pipes ao pr ox1mo componente. 
Com a evolw~·"' do hardware que ocorreu durante as décadas de 1970 e 
1980, surgiu a neu·ss1dade de os compiladores oferecerem suporte a diferentes 
plataformas. Com 0111itante a esse fato, devemos ainda levar em conta tanto a 
complexidade qu.11110 o custo em desenvolver um compilador. 
Em razão disso, houve a necessidade de tornar o compilador portável a várias 
plataformas a fim dl' reduzir os custos de desenvolver diferentes produtos (isto é, 
compiladores pa1.1 plataformas distintas). Como resultado dessa necessidade, 
houve a inserção dl' um novo componente que resultou numa arquitetura que 
possuía uma etap;1 111termcdiária de geração de código entre suas principais fun 
ções de análise e s111tese. Isso é ilustrado na Figura 2.3. 
------
1 ..... 
Função de análise 
análise 
sintática 
Função de síntese 
análise 
semântica 
otimização 
geração 
de código 
geração 
intermediária 
de código 
Figura 2.l Evolução na arquitetura de um compilador. 
E~sa arquitetura oferecia suporte à portabilidade, um dos requisitos de um 
compilador. No entanto, com o avanço tecnológico, o compilador deixou de ser 
uma ferramenta isolada e então houve a necessidade de integrá-lo a outras ferra-
mentas como, por exemplo, editor e depurador. Esse novo requisito acarretou 
num redesenho da arquitetura para compiladores similar à apresentada na Figu-
ra 2.4. Nessa nova arquitetura, existem conexões entre as várias fases do proces-
so de compilação, o que pode ser visto como fluxo de controle. 
análise 
léxica 
1 
1 
1 
Geração 
intermediária 
de código 
I 
I 
I 
,,' :.&r--.....i.. ___ .z::_ __ --, , 
Tabela de símbolos 
de estrutura sintática 
/ 
geração 
de código 
/ 
/ 
/ 
Figura 2.4 Nova evolução na arquitetura de compiladores. 
Perceba que essa nova arquitetura é centrada num conjunto de recursos compar-
1 i I hados bem como permite que novas ferramentas sejam adicionadas à arquitetura. 
É importante observar que a arquitetura mostrada na Figura 2.4 lembra a arqui-
t l' t ura mais simples de um sistema de quadro-negro (blackboard), o qual possui um 
ll'positório central de dados compartilhados. Essa arquitetura será discutida em de-
t.ilhes na Seção 2.3. A semelhança aqui observada deve-se ao fato de a informação 
111.1111pulada ser centralizada, sobre a qual diferentes componentes interagem. Apesar 
, ll·ss,1 L,tractcrística, o compilador possui uma ordem de execução predeterminada. 
A evolução da arquitetura de compiladores, utilizada como exemplo em nossa 
d I scussão, aconteceu como resultado da necessidade de atender o requisito de por-
1.1hi l idade. A integração de outras ferramentas também causou modificação na ar-
qirrtetura. Isso, contudo, não significa ver o estilo arquitetural de pipes. e_ ~iltros 
l orno um estilo que possui deficiências. Cabe salientar que a manutem?i~i?ade 
1111111 estilo arquitetural de pipes e filtros é, geralmente, mais flexível, possibilitan-
do ,1 reorganização de filtros e pipes. Embora esse estilo arquitetural ofereça ~u-
l l< >rt e à manutenibilidade em termos da facilidade de reorganização, podemos am-
d.1 nos deparar com a desvantagem de mudanças freqüentes em um componente 
(liltro) impactar outros componentes. Assim, face à propag~çã~ ~e ~udanças de 
11111 filtro a outro(s), o suporte~ manutenibilidade desse estilo e limitado. 115 
2.3 Camadas 
O estilo arquitetural de camadas estrutura um sistema num conjunto de camadas, 
onde cada uma delas agrupa um conjunto de tarefas num determinado nível de 
abstração. Geralmente, numa arquitetura de camadas, uma camada no nível N 
oferece um conjunto de serviços à camada no nível superior (isto é, N + 1). Para 
tanto, a camada N utiliza suas funções bem como faz uso dos serviços disponíveis 
na camada inferior (N-1). 
Indubitavelmente, o melhor exemplo de uma arquitetura de camadas é o mo-
delo de referência OSI (Reference Model for Open Systems Interconnection) da 
ISO (International Organization for Standization) (ISO, 1984; ISO, 1994; Tanen-
baum, 1988). Nesse modelo, cada camada pode ser vista como um componente 
que pode ser implementado por software ou hardware. O modelo OSI da ISO pos-
sui sete camadas e serve como arquitetura dos protocolos de redes de computado-
res. A Figura 2.5 ilustra a arquitetura de camadas do modelo OSI da ISO. 
A arquitetura de rede é formada através de uma estrutura hierárquica, com-
posta de camadas com interfaces entre elas. Associado a cada camada, há um pro-
tocolo, como mostrado na Figura 2.6. Cada camada oferece um conjunto de ser-
viços à camada superior. Assim, a camada N de um sistemaX se comunica com a 
camada N de um sistema Y, fazendo uso do protocolo do nível N associado àque-
las camadas. Assim, projetar um protocolo para cada camada constitui-se na ma-
neira mais eficiente para organizar uma rede. Note que é necessário definir as in-
terfaces entre as diversas camadas. 
Considere a Figura 2.6 que ilustra como ocorre a comunicação entre dois 
sistemas. Note que associado a cada camada existe um protocolo. Assim, a ca-
mada 7 do sistema X se comunica com a camada 7 do sistema Y. O protocolo 
consiste de um conjunto de regras e convenções que descrevem como sistemas 
podem se comunicar via rede. Em outras palavras, o protocolo define o for-
mato, conteúdo e significado dos dados trocados entre as camadas associadas 
a ele. 
Embora a figura anterior ilustre a comunicação entre camadas, fazendo -se 
uso de protocolo específico, a transferência de dados não ocorre horizontalmen 
te. Na realidade, a movimentação dos dados se dá verticalmente com os dados 
descendo camada a camada até atingir a camada mais baixa (camada 1 ), ou seja, ,1 
camada física, quando de fato há a comunicação com o outro sistema. Do outro 
lado (sistema Y), ocorre um processo inverso. Os dados sobem até atingir ,1 l,1111,1 
da mais alta (camada 7), camada de aplicação. 
Uma pergunta que poderia surgir é: em que situação o estilo arquitetural de 
camadas seria mais adequado? 
A arquitetura de camadas não especifica qual deveria ser a granulosidade de 
componentes. Entretanto, componentes complexos, geralmente, exigirão de-
composição adicional. De modo geral, o estilo arquitetural de camadas faz a 
decomposição do sistema em um conjunto de camadas, onde cada camada acres-
161 centa um nível de abstração sobre a camada inferior. 
camada 7 aplicação 
camada 6 
camada 5 
camada 4 
camada 3 
camada2 
camada 1 física 
Figura 2.5 Arquitetura de protocolos de rede de computadores. 
sistema X sistema Y 
camada 7 aplicação ___ protocolo da camada 7 __ aplicação 
camada 6 ___ protocolo da camada 6 ___ 
camada 5 ___ protocolo da camada 5 ___ 
cnmada 4 __ _pJotocolo da camada 4 ___ 
('. 111111(11\ 3 pr9to_ç9lo da camada ~ • rede r_ 
cnrnada 2 _ _protocolo da camada 2 ~- onl11co / 
t 
1:11rnada 1 física ___ Qr:_otocolo da camada 1 . _ •I li ,Ir 1 1 
1 acura 2.6 Comunicação entre dois sistemas numa arquitetura de camadas. 
O número de camadas dependerá da funcionalidade a ser oferecida pelo sis-
tema. A funcion ,1lidade do sistema pode ser pensada como um conjunto de tare-
fas que o sistema desempenhará. Assim, faz-se necessário definir critérios de abs-
tração a serem observados quando desejarmos agrupar subtarefas para compo-
rem uma camada. Exemplo de critérios a serem considerados são tipos de com-
ponentes (específicos) da aplicação e interface com o sistema operacional. 
Além disso, poderíamos ter variações sobre o estilo de camadas simples onde 
uma camada N utiliza os serviços oferecidos pela camada N-1 a fim de realizar 
suas funções. Um exemplo de variação desse estilo seria permitir que a camada N 
tivesse acesso não apenas à camada N-1, mas também às camadas N-2, N-3 ou 
qualquer outra abaixo dela. 
Note, contudo, que essa variação na arquitetura de camadas pode compro-
meter a manutenihilicfode de um sistema. Haver um maior grau de dependência 
entre as camadas implica que mais de uma camada necessitará ser modificada 
para atender à mudança de requisitos. 
Outra observ.1<,.10 pertinente ao estilo arquitetural de camadas é que, uma 
vez permitindo ullla definição de vários níveis de abstração (camadas), ele pro-
porciona uma m:11or flexibilidade ao sistema. Todavia, isso tem um custo associ-
ado. O desempenho da arquitetura de camadas fica comprometido face à neces-
sidade de umas< 1111.:1 tação externa ao sistema precisar passar por várias camadas a 
fim de ser trat:id,1. 
Também, i111pkmentar um sistema ou protocolo de rede como um bloco mo-
nolítico não com,! 11 ui uma solução apropriada. Isso requer buscar uma arquitetu-
ra com menor 1111111ero de camadas que atenda ao requisito de desempenho, mas 
que ao mesmo tl'111po leve em conta a manutenibilidade. Obviamente que outros 
requisitos, dito, 11,10 funcionais, como confiabilidade, poderiam ser considera-
dos também. 
Na realidade, o que determinará o número de camadas de um sistema não é 
simplesmente,, funcionalidade a ser provida por ele, mas também os requisitos 
não-funcionai ., desejados. Entretanto, determinar o número adequado de cama-
das é tarefa mwto difícil. Pode-se ainda chegar a conclusão que o estilo arquitetu-
ral de camad,1-. 11,10 constitui uma solução adequada e, assim, buscar-se-á um ou-
tro estilo qm· s,11 is faça aos requisitos funcionais e não-funcionais. 
Conside1 l', por exemplo, a arquitetura OSI apresentada anteriormente (Fi-
gura 2.5). Tr;1t,1 se de uma arquitetura que possui sete camadas. Contudo, devi-
do ao surgimento de diferentes tecnologias tanto a fim de atender a uma gama de 
usuários que precisa de redes de alta velocidade numa área específica quanto de 
conectar equ1p.11nentos separados a milhares de quilômetros de distância, houve 
nova ênfase 11.1 .1rquitetura de redes. Assim, entra em cena a arquitetura Internet 
TCP/IP. 
A .11 q11it('l 11r:1 1 nternet baseia-se, principalmente, em um serviço de transpor-
,, 11111 111 11111 ,1 conexão, oferecido pelo Transmission Control Protocol (TCP) 
(Poste!, l 11H l ,1) L' em um serviço de rede não orientado à conexão oferecido pelo 
181 Internet P,otornl (IP) (Postei, 19816). 
A arquitetura Internet é estruturada em quatro camadas construídas sobre 
uma quinta camada (intra-rede) que não faz parte do modelo (Comer, 1991). A Fi-
gura 2. 7 ilustra a arquitetura Internet juntamente com a arquitetura OSI da ISO. 
Arquitetura Internet Arquitetura OSI 
aplicação 
aplicação apresentação 
sessão 
transporte transporte 
inter-rede 
rede 
interface de rede \, 
enlace 
intra-rede 
física 
Figura 2.7 Arquiteturas Internet e OS/. 
A arquitetura Internet constitui-se numa solução simples e funcional, per-
11111111do a interconexão de sistemas abertos 1. Com a arquitetura Internet, tor-
111111 se possível a interligação de redes de computadores com tecnologias dis-
1111 t.1s. A solução encontrada foi agrupar os níveis físico, de enlace e de rede da 
11 q111tetura OSI na camada intra-rede da arquitetura Internet, havendo uma in-
11 1 l.1Cc entre essa camada e a camada inter-rede, conforme ilustra a Figura 2. 7. 
\ll'111 disso, as camadas de sessão e de transporte são implementadas, diferente-
1111 11te, para cada aplicação. Note que a arquitetura de camadas permite o reuso 
d, l ,1111adas. Por exemplo, TCP pode ser utilizado em diferentes aplicações, tais 
11111111 telnet e ftp. 
1 
11111 ,l\tl'ma aberto é aquele preparado para se comunicar com qualquer outro sistema aberto, fa-
;1 11, I,, 11,0 <lc regras que definem o formato, conteúdo e significado dos dados trocados entre os siste-
1111 l .11, regras são comumente denominadas de protocolos. 119 
2.4 Objetos 
O paradigma de projeto orientado a objetos acrescenta uma outra abstração ao 
projetodesoftware.Aidéiafundan11111dp 11111.1 d 1,1h111il 11•1111111111111 l 1,111 
jetosécombinarnumaúnicaentid::uh t.11111111-,d.1d11.,q11111111 1 11111 rw q111•,1111 
am sobre esses dados. Essa entidad r e dl'1111111i11.1d.1 0l 11,•to 
Para fazermos uma analogia, com.idnc 11111.1 c111p1Ts.1 )IH po-,.,111 d1v1 '"º" til · 
partamentos como, por exemplo, vcnd ,1s, rc<..11rws h11m,111m, l.011t.1hil1d.1dl' l ' 
marketing. A divisão em departamento s ajuda na organi za ·ao da i11:-.t1t111ç;10, 
onde cada departamento possui seu pessoal e tarefo as ·ociada s. Tamb ~m, cada 
departamento dispõe de seus próprios dados, ou seja, números da vendas, regis-
tros de pessoal, inventário, folha de pagamento e outros, a depender do departa -
mento. As pessoas de cada departamento atuam sobre os dados de seu departa -
mento. Assim, ao dividir uma empr e a num conjunto de departam entos pod e-
mos compreender melhor suasnecessidades e ter maior controle sobre as ativida-
des da mesma. 
Similarmente, a abordagem orientada a objetos permite a organização de 
programas ao mesmo tempo em que ajuda a manter a integridade dos dados do 
sistema. Num projeto orientado a objetos, os projetistas de sistema podem en-
capsular dados e comportamento em objetos os quais possuem interfaces com 
outros objetos. A interação entre objetos se dá através de canais de comunicação, 
abstraindo-se o mecanismo de passagem de mensagens. 
O estilo arquitetural de objetos tem como base o uso de um tipo de dados abs-
trato - o objeto. Esse estilo possui várias propriedades importantes, dentre as 
quais destacamos: 
• Objetos são entidades independentes (um tipo de dado abstrato) que po-
dem sofrer modificação uma vez que toda informação pertinente é manti-
da no próprio objeto. 
• É possível fazer o mapeamento entre as entidades reais e os objetos que 
atuam no controle de um sistema, resultando numa melhor compreensão 
do sistema. 
• Os objetos fazem uso de um mecanismo de troca de mensagens para se co-
municar em vez de utilizar variáveis compartilhadas. 
• Objetos podem ser reutilizados devido à sua independência. 
• Os objetos pod em estar distribuídos e executar seqüencialmente ou em 
paralelo, a depender das decisões tomadas no início do projeto. 
l)i ft·1 t·111 rnH·111 · da abordagem funcional, a abordagem orientada a objetos 
11·111 11111H1 1 ,1.,1· .1 na ocultação de informações, que é uma estratégia de projeto 
11111l1 111111111111 m·s são escondidas em componentes do projeto. O estilo arquitetu-
ral de objete,., Vl' 11111 sistema de software como um conjunto de objetos comunican-
201 tes com est,11l0 .1ssociado a eles. Nesse caso, quando um objeto obj 1 necessita seco-
municar com um objeto obJ2, ele precisa conhecer a identidade do ,>bjeto ao qu,11 
enviará uma mensagem. Isso é ilustrado na Figura 2.8. Perceba q11l' 11m sistema ori 
entado a objetos pode ser vislumbrado como uma rede de objctm 111111 1 1 1il11 
stado 1 
obj1 
1 ld <' 
obj2 
estado 4 
obj4 
estado 3 
obj3 
Figura 2.8 Arquitetura de um projeto orientado a objetos. 
Dessa forma, numa arquitetura de objetos, teríamos um conjunto de objetos 
1.0111 estados próprios (escondidos) e as operações associadas àqueles estados. Em 
t.tl arquitetura, os objetos (comunicantes) podem requisitar QU oferecer serviços 
., outros objetos. 
Embora os conceitos do paradigma de projeto orientado a objetos possa ser 
11 ti I izado para tratar alguns aspectos do projeto arquitetural, existem algumas di-
1 n enças entre as características e benefícios do projeto orientado a objetos e o 
projeto da arquitetura de software. 
O projeto da arquitetura de software visa a decompor o sistema em compo-
11e11tes e identificar as interações existentes entre esses componentes. Essa de-
wmposição em componentes fornece uma visão global do sistema, permitindo 
que o engenheiro/arquiteto de software analise e raciocine sobre as propriedades 
1· restrições do sistema. 
Assim, dado que os estilos arquiteturais podem descrever famílias de proje-
lm, parece intuitivo vislumbrar o paradigma de projeto orientado a objetos 
1 wno um estilo arquitetural no qual todos os componentes são objetos, e todas as 
1 rn1cxões são associações ou agregações (segundo a terminologia da Técnica de 
f\.lodclagem de Objetos(OMT) (Rumbaugh, 1991). 
Entretanto, existem questões que são relevantes e, portanto, tratadas na abor-
il.1gcm orientada a objetos, mas não que fogem ao escopo do projeto arquitetural. 
< 111110 exemplo, podemos citar as formas de modelar os requisitos bem como o 
111, 11eto de estrutura de dados e algoritmos. Tais aspectos não precisariam ser trata-
dt)', ou especificados numa descrição arquitetural, embora pudessem ser conside-
1 idos durante o projeto da arquitetura de software do sistema a ser desenvolvido. 
Assim, a arquitetura de software orientada a objetos constitui-se em mais um 
1 t do arquitetural que pode ser utilizado pelo projetista /arquiteto de software.121 
1 
Sua opção dcpl'nderá dos requisitos funcionais e não-funcionais do sistema a ser 
desenvolvid1 ,. 
~.d11·111m, l l)Jd1111111 d i,1 111 idn anteriormente, que para um objeto (obj 1) se 
l 01111111iL11 u1111 11111rn1111111hw111 (oh li), a identidade do segundo (obj2) precisa 
:-.l'I LllllltL·ud.1 pl'lo p1111\L'll'O (ollj 1) ,1 11111 de q11t· o/Jj I po-.-.., 111v1,11 111111-.,1g1111 .1 
obj2. lsso se constitui numa desva11t,1gl'm p.1r.1 o rL·uso po1-. ll' tt·1110-. de .1llt·1.11 :1 
especificação de classes quando houver mudanças. Esse probll ·111,1 C- t 1,,t.Hlo 1111 
estilo arquitetural orientado a eventos (discutido na seção 2.5). 
Se considerarmos a manutenibilidade como requisito não -funcional prl' 
ponderante, é fundamental considerar que qualquer modificação de requisitos 
deveria afetar o menor número possível de objetos. Além disso, se o arquiteto 
de software tiver de levar em conta o desempenho do sistema, então os cenários 
de uso mais freqüentes deveriam ocorrer num menor número de objetos a fim 
de minimizar a comutação de contextos que viria a comprometer o desempe -
nho do sistema. 
2.5 Invocação Implícita 
Vimos na seção anterior que o estilo arquitetural com base em objetos requer que 
os objetos comunicantes conheçam a identidade do objeto com o qual deseja se 
comunicar, isto é, enviar uma mensagem. Essa dependência maior entre os obje-
tos implica uma desvantagem em termos de manutenibilidade. 
Um estilo arquitetural com base em arquitetura de objetos faz uso de um me-
canismo de invocação implícita para organizar o sistema. Em razão disso, ele é 
denominado de invocação implícita. Uma discussão inicial sobre este estilo foi 
feita por Garlan e Shaw (Garlan, 1993; Shaw,1996). 
Diferentemente do estilo arquitetural com base em objetos, no qual um com-
ponente (objeto) invoca o outro diretamente (conhecendo a identidade do outro) 
por meio de passagem de mensagens, o estilo arquitetural de invocação implícita 
requer que os componentes interessados em um evento registrem-se a fim de rece-
bê-lo. Assim, componentes podem tanto registrar interesse em receber eventos 
quanto de divulgar eventos. Tais eventos podem e, provavelmente, contêm dados. 
Nesse caso, o sistema dispõe de um mecanismo para tratamento de eventos, o qual 
encarrega-se de encaminhar os eventos aos componentes destinatários. 
Um exemplo recente fazendo uso do estilo arquitetural de invocação implíci-
ta é JavaBeans (Sun, 1999; Morrison; 1997). Assim como outras tecnologias 
com base em componentes, JavaBeans possibilita o engenheiro/arquiteto de soft-
ware fazer uso de componentes a fim de criar ou desenvolver novas aplicações 
com a funcionalidade desejada. Em tal situação, o arquiteto de software não tem 
necessidade de conhecer detalhes de implementação. Ele, simplesmente, precisa 
saber quais os serviços oferecidos por um componente, de modo a interagir e 
usar esse componente. Outros exemplos são discutidos por Garlan, Kaiser e Not-
221 kin (Garlan, 1992). 
Diante do que foi dito anteriormente, uma pergunta pode emanar: 
Qual a contribuição desse estilo arquitetural? 
Ou, colocando de outra forma: 
Em que situações o estilo arquitetural de invocação implícita seria apropriado? 
Sabemos que à medida que a quantidade de modificações e aperfeiçoamen-
tos aumenta, também cresce a complexidade das interações entre os componen-
tes do sistema. Isso faz com que projetistas/arquitetos de software busquem uma 
abordagem para tratar tais mudanças de modo que componentes do sistema pos-
sam ser modificados independentemente, bem como aperfeiçoamentos possam 
ocorrer incrementalmente. Alguns sistemas se aproximam desses objetivos. 
Considere, por exemplo, o sistema de produção. Esse paradigma de imple-
mentação para sistemas especialistas consiste de um conjunto de regras (conjun-
to de pares padrão - ação) que são ativadas quando um ou m'àis padrões corres-
pondem àqueles existentes na memória de trabalho (istoé, um banco de dados 
compartilhado). A Figura 2.9 ilustra a organização de tal sistema. 
. memória de 
1,---
base de 
.... 
trabalho conhecimento 
·~ 
~, ,r 
~ .. 
máquina de ~ unidade de 
inferência 
..... controle 
~ ~ .. .. 
Figura 2.9 Organização de um sistema de produção . 
l 1111 rnnjunto de regras compõem a base de conhecimento, em que cada regra 
q111'M'1tl.1 um formato: 
,. 1,i1drão então ação. 
< > p.1dri'io define as condições sob as quais a ação aswL iada deveria sl'r apli 
1d ,. <)., p.H.lrões têm como base elementos (objetos) q11c \l' 1t·11111.1111c111011.1 de 
11 d, 1ll111 (.1 qual poderia ser vista como um banco de d.ido s ln111p.111ill1.1d11) 
1111 q11,111do um conjunto de padrões é identificado, P" 111111 d, p111d11 111 
1, I• 1111i11,1 a ordenação das regras aplicáveis bem como l:ontrola as ações cor-
' 11111Hkntcs. 123 
Num sistema de produção, similar ao exemplificado anteriormente, pode-se 
em princípio incrementar o sistema através da adição de novas regras. O sistema de 
produção pode ser vislumbrado como um exemplo de estilo arquitetural de invo-
cação implícita. Uma forma mais simplista de ver essa organizaçã, 11 111,1\, , d, , ,li 
jetos comunicantes os quais interagem com um banco de dados 111111p.111 ilh,1d11. 
Algumas observações referentes à diferença entre esse , , 1 d11 ,11q11111·1111.il l' 
outros devem ser feitas. Por exemplo, a diferença entre 11 1i-.1, d1· 1·v1·111 º" no t·s 
tilo arquitetural de invocação implícita e o uso de 111e11s.1gt·11s 110 ,·-.1 do ,11 q111tetu 
ral com base em objetos é que eventos são assíncronos, pern11t111do o L<>mponen 
te que gerou o evento continuar realizando alguma outra ativicbde (computa -
ção) após o envio do evento. Além disso, o componente gerador de eventos des-
conhece a identidade do componente consumidor de eventos. 
O mecanismo com base em eventos do estilo arquitetural de invocação implí-
cita provê suporte à manutenibilidade desde que este estilo permita fácil inserção e 
remoção de componentes. A principal razão por trás disso é que os geradores de 
eventos não precisam saber quais componentes serão afetados por esses eventos. 
Note, portanto, que os componentes não podem fazer qualquer suposição 
sobre o tipo de computação a ser realizada ou ordem de processamento. Não sa-
ber a ordem de processamento de eventos ou mesmo qual componente respon-
derá constitui numa desvantagem pois, nesse caso, os componentes não detêm 
mais controle sobre a computação realizada pelo sistema. 
Similarmente ao estilo arquitetural de repositórios, apresentado a seguir, 
tem-se que o estilo arquitetural de invocação implícita poderia utilizar o meca-
nismo de difusão de eventos para indicar a existência de erros ou falhas. Isso per-
mite que esse mecanismo seja usado em todo o sistema a fim de lidar com a exis-
tência de falhas, oferecendo assim um suporte indireto à confiabilidade. 
2.6 Quadro-Negro 
O estilo quadro-negro ou blackboard originou-se no campo de inteligência artifi-
cial, no qual ele era utilizado como um mecanismo para o compartilhamento de 
conhecimento ou dados por vários componentes inteligentes (Nii, 1986). Esse 
estilo considera a existência de um repositório central de dados circundado por 
um conjunto de componentes (células de conhecimento). 
A idéia do estilo arquitetural quadro-negro tem como base um modelo de so-
lução de problema que fornece uma estrutura conceitua! para organizar o conhe-
cimento do domínio bem como uma estratégia para aplicar esse conhecimento. 
Esse estilo arquitetural prescreve a organização do conhecimento do domínio, 
toda s as entradas e soluç6e s p,1rciais para solucionar o problema. 
A ,1rq11Íll'1111.1 q11,1d1 o 111·g1 o consiste basicamente de três componentes: 
• < °l·l11I." d,· 1 0111.n 1111111fu - O conhecimento necessário para solucionar 
um problema é particionado em células de conhecimento. Tais células são 
separadas e independentes. 
• Estrutura de dados do quadro-negro - Os dados de solução de problemas 
são mantidos num banco de dados compartilhado, denominado de qua-
dro-negro. As células de conhecimento causam modificações no quadro-
1J1r.1111(111 d, ',( 111,11111,1111.11!11,11,.111 .. ,111 1 lll l',,11 1111111,1 , 111111,.,111 11111.111111 1,1 
, 10 l ' l 11111111111,11,..101·11111· ,1, u •hil.1, 1h· u11tl1t·111111·1110 ou111t·111 111111.1111t·1111• 
:111.1vt·s do q11;1dro negro . 
• Controle - As células de conhecimento respondem de forma oportunista l 
às mudanças no quadro -negro. 
A figura 2.10 ilustra o estilo arquitetural quadro-negro. 
célula de 
conhecimento 
célula de 
conhecimento 
quadro-negro 
(banco de dados 
compartilhado) 
Figura 2.1 O Organização quadro-negro." 
célula de 
conhecimento 
célula de 
conhecimento 
O estilo arquitetural quadro-negro possui um banco de dados compartilhado 
(quadro-negro) que possui uma organização dependente da aplicação. Existe, 
também, um conjunto de células de conhecimento que são logicamente indepen-
dentes e respondem às mudanças que ocorrem no quadro-negro. 
As células de conhecimento podem ser ativadas através do estado do qua-
dro-negro. Dessa forma, as células de conhecimento respondem às alterações 
que acontecem no quadro-negro. É importante observar que o fluxo de controle 
do sistema não é explicitamente definido. Em vez disso, o fluxo de controle é de-
terminado pelo conjunto de componentes ativos em um determinado instante. 
Esse tipo de estilo arquitetural é adequado em aplicações, onde diversos ti-
pos de conhecimento devem ser considerados a fim de dar suporte à interpreta-
ção de um conjunto de dados iniciais. Tipicamente, a arquitetura quadro-negro 
era utilizada em casos onde não havia soluções gerais para um problema. Nesse 
caso, um ou mais componentes (células de conhecimento) interagem com o ban-
co de dados compartilhado (quadro-negro) buscando encontrar uma solução 
parcial ou total. No caso de uma solução parcial, outro componente pode vir a 
ser ativado. 
2 A resposta oportunista é baseada num modelo de raciocínio oportunista, onde fragmentos de co-
nhecimento são aplicados regressivamente ou progressivamente no momento mais oportuno. Em 
outras palavras, para solucionar um problema, quais/quando /como os fragmentos de conhecimento 
deveriam ser utilizados? / 25 
Podemos ainda considerar a organização dos dados em um repositório. A ar-
quitetura quadro-negro mais simples envolve apenas um único repositório cen-
tral de dados (quadro-negro). Entretanto, problemas mais complexos podem 
exigir múltiplos repositórios organizados num sistema distribuído de acordo 
com os tipos de dados. 
A necessidade de um componente (célula de conhecimento) 'passear' pelo 
repositório de dados (quadro-negro) em busca de uma solução constitui-se numa 
desvantagem em termos de desempenho para esse estilo arquitetural. Além disto, 
pode haver redundância na tentativa de múltiplos componentes processarem da-
dos de um problema. 
Um aspecto positivo desse estilo arquitetural é a facilidade na qual conse-
gue-se adicionar ou remover quantidade e tipos de dados. Uma vez que o proces-
samento de cada componente é independente dos demais, componentes podem 
ser adicionados ou removidos sem acarretar modificações nos demais. A manute-
nibilidade é, portanto, um dos principais requisitos não-funcionais a que este es-
tilo dá suporte. Essa característica, contudo, é dependente de como o componen-
te de controle é definido. 
2. 7 Outros Estilos Arquiteturais 
Os estilos arquiteturais discutidos anteriormente constituem aqueles mais co-
nhecidos face a seu uso nos mais variados sistemas. Outros, entretanto, também 
são encontrados em diversas aplicações. Um subconjunto deles é apresentado 
aqui nesta seção. Note que nosso intuito não é catalogar todos os estilos arquite-
turais existentes, mas apresentar ao leitor aqueles que oferecem suporte a um 
conjunto de requisitos de qualidade desejados em diversas aplicações práticas e 
sistemas. 
2. 7 .1 Repositório (Passivo) 
Um repositóriopossui dois componentes básicos: um conjunto de dados com-
partilhado (o qual representa o estado atual) e um conjunto de clientes indepen -
dentes que tem acesso e atualiza a base de dados compartilhada. Este tipo de esti -
lo arquitetural no qual se tem um conjunto de componentes independentes aces-
sando e atualizando uma base de dados compartilhada é comumente chamada de 
repositório. 
A seção anterior apresentou o estilo arquitetural quadro-negro ou black-
board. Esse estilo pode ser visto como um repositório ativo. Ele é denominado de 
ativo porque a base de dados (central) compartilhada notifica os clientes a ela co-
11ect.1dos q11,111do ocorrem mudanças que possam interessar a tais clientes. Daí, 
n"l ' t 1po d1· 11 ·positório ser chamado de ativo. 
11111 , 1111, tJ l.1do, se o controle ou o mecanismo de acionamento dos clientes 
decorre dos tipo s de transações existentes, ele então é visto como um repositório 
261 passivo, diferl'lltcmente do que se tem num estilo arquitetural quadro-negro. 
Geralmente, os conectores no estilo arquitetural de repositório são os me-
canismos de consulta. Note que, a exemplo do estilo quadro-negro, a topologia 
does tilo repositório é estrela. Esse tipo de estilo arquitetural t, 11111111111 11, i 111 1 
pal c-.11, tl t1, 1-.111,1 11 -.1q1111 tl q111· nll ·t n l' ., q11.tl1d.1d1 dr 111tq\1,11,.111 A,-.1111, v.11 i 
o, s1-.1l'111.,.., lOlllpo stos ., p.11111 dt· Lo111po11l'llll's p, l'l'\.t,tl ' lltt·, podr111 pt OVl't s11 
prnte .1 esse requisito, fazendo uso do s mecanismos utilizados 110 estilo qua 
dro negro. 
2. 7 .2 Arquiteturas de Aplicações Distribuídas 
Existe considerável discordância na literatura quanto ao que constitui um siste-
ma distribuído. Dentre as diversas definições encontradas, há um ponto de con-
cordância: a presença de múltiplos processadores. Parte da discordância existen-
te pode se dever à grande quantidade de modelos arquiteturais. Aqui, concentra-
mo-nos em dois estilos arquiteturais mais comuns: multiprocessadores e multi-
computadores. ' 
Uma arquitetura multiprocessadores compreende vários processadores au-
tônomos compartilhando uma memória primária comum. Esse estilo arquite-
tural é apropriado para executar, simultaneamente, diversas subtarefas de um 
mesmo programa. Por outro lado, uma arquitetura multicomputadores é simi-
lar à multiprocessadores, exceto que os processadores não.,compartilham me-
mória. Ao invés, eles se comunicam através de passagem de mensagens numa 
rede de comunicação. Uma ilustração do mecanismo de comunicação é mostra-
da na Figura 2.11. 
memória memória 
processador processador 
rede 
Figura 2.11 Mecanismo de comunicação via passagem de mensagens. 
Dessa forma, a arquitetura de um sistema distribuído consiste de múltiplos 
processadores autônomos os quais fazem uso do mecanismo de passagem de 
mensagem para se comunicarem uns com os outros. Note que eles não comparti-
lham memória. Nesse caso, uma aplicação distribuída pode ser vista como um 
programa concorrente no qual os processos se comunicam por meio da passagem 
de mensagens. Essa denominação é resultante do fato de tais programas serem 
executados em arquiteturas distribuídas. 
Uma aplicação distribuída possui quatro tipos de processos (ou componen-
tes) : filtros, clientes, servidores e pares (ou peers). 
127 
Um filtro é um transformador de dados. Ele recebe um fluxo de dados através 
de sua entrada, efetua computações sobre esses dados e coloca os dados resultan-
tes na sua saída a fim de enviar a algum outro componente. Exemplos dele po-
dem ser encontrados nos comandos do sistema operacional Unix 3 . 
lJlll ditntt· podl' Sl'I v1,to L<>l1H> 11111 p1ou ·,,o N.1 11111 1 1~ 11,, 11111 1111•1111· 1• ,1·1 • 
v1dor, o dtente é o componentt qut 1111ci.1 ,dg11111,1 .1tivid.1d1, ,\11·111 d1.,,o, lrl' 
qüentemente, ele pode causar algum atraso enqua1110 .1g11.1nl.1 o t 1.11.11111·1110 de 
alguma solicitação feita. 
AgQra, diferentemente de um cliente, o servidor aguarda solt<.:1t.1çoes Je di -
entes a fim de tratá-las. Em outras palavras, um servidor é um processo reativo 
uma vez que reage às solicitações feitas por clientes Ele pode atender a mais de 
um cliente e, geralmente, opera de forma não determinística. 
Assim, por exemplo, um servidor de arquivos em um sistema distribuído tipi-
camente contro la um conjunto de arquivos e solicitações de serviço (de clientes) 
que aguardam o acesso àqueles arquivos. 
Um par (ou peer) é um dentre um conjunto de processos idênticos que intera-
ge a fim de oferecer algum serviço ou realizar alguma computação. Por exemplo, 
dois pares poderiam controlar a cópia de um arquivo de dados, interagindo um 
com o outro a fim de manter a consistência das duas cópias. Outro exemplo é en-
contrado em programação paralela, no qual vários pares interagem a fim de re-
solver um problema. Nesse caso, cada par é responsável pela solução de uma par-
te do problema. 
Processos Comunicantes 
Um estilo arquitetural que se enquadra dentro do conjunto de arquiteturas de 
aplicações distribuídas é o de processos comunicantes. O estilo arquitetural de 
processos comunicantes é utilizado quando as metas prioritárias do sistema a ser 
desenvolvido são escalabilidade e facilidade de modificações. Andrews discute 
um conjunto de variantes desse estilo que podem atender a metas distintas 
(Andrews, 1991 ). 
Um exemplo de variante do estilo arquitetural de processos comunicantes é 
aquele em que se tem um conjunto de trabalhadores (componentes computacio-
nais) replicados que compartilham um repositório de tarefas. Diferente dos ser-
vidores descentralizados que mantêm múltiplas cópias de dados, esse estilo for-
nece múltiplas cópias dos componentes computacionais. Esse estilo é utilizado 
em programação paralela quando lidando com o paradigma SIMD (Single 
Instruction, Multiple Data). 
Cliente-Servidor 
Outro estilo arquitetural que se enquadra no conjunto de arquiteturas distribuí-
das é cliente-servidor. Este estilo permite que as tarefas sejam divididas entre 
2813 Unix é uma marca registrada da AT&T, Bell Labs. 
produtores e consumidores de dados. Um servidor é um processo que fica num 
estado de espera, aguardando solicitação de serviço de um ou mais clientes. Um 
cenário típico envolvendo cliente e servidor seria: 
1. Um sistema computacional acomoda um (processo ) servidor, o qual é inici-
.tl11.1dn -.0111tl1<1. J\po-. 1t1tl 1,tl1,.1do, 1 ll' 1·1111.111<1111 estado de espera e aguar-
d.1 q1tl' ,1 lg11111 d 11·11tl' l'tlt n· l'lll l 0111.11 ou 1111 l'k, n·quisitando algum serviço. 
2. Um (procl'sso) diente, qul' podl' l'st,11110 111L·s111n sistema ou em algum ou-
tro, é conectado ao servidor via rede. (;er,1ln1l'11te, os clientes podem inte-
ragir com o usuário que digita algum rn111.u1do. Assim, o cliente envia 
uma solicitação via rede ao servidor para que l'Ste último atenda a solicita-
ção, possivelmente, efetuando alguma co111p11t.tção. 
3. Após o servidor tratar a solicitação, ele retorna o resultado para o cliente, 
voltando em seguida para o estado de espera, no qual permanecerá até 
que chegue nova solicitação de algum cliente. 
Perceba que o servidor pode trabalhar de forma síncro'ha ou assíncrona. 
Quando operando no modo síncrono, o servidor retorna o controle ao cliente no 
mesmo instante em que ele envia os dados resultantes. Agora, se o servidor traba-
lha de forma assíncrona, ele retornará apenas os dados resultantes ao cliente ao 
término do tratamento da solicitação recebida. 
É interessante ainda observar que os clientes no estilo arquitetural clien-
te-servidor podem ser vistos como processos que atuam de forma independente, 
isto é, a execução de um processo não interfere em outro(s). Essa independência 
entre os processos implica nos seguintes benefícios para esse estilo: 
(a) Facilidade de remover e/ou adicionar clientes. Essa facilidade de mudança 
decorre da independência existente entre os processos. 
(b) Facilidade de modificar a funcionalidade de um cliente (visto queoutros 
clientes não serão afetados) . 
Tais benefícios podem não se verificar se houver acoplamento entre os clien-
tes, o que acarreta em maior nível de dependência entre os (processos) clientes. 
2. 7 .3 Chamada de Procedimento Remoto 
Chamada de procedimento remoto ou remore procedure cal! (RPC), também de-
nominado de chamada de sub-rotina, é um mecanismo de transf erên<.:ia de <.:on 
trole de um processo (chamador) para outro (chamado), Sl'ndo dl'pois o co111 rok 
retornado ao processo que emitiu a chamada. 
Sistemas com base no uso de chamada de procedimentc, 11·111<1101•.1•1 tl1111' 11ti• 
são decompostos em partes que ficam em computadores u 1111 1 1.1il11,, 1,1 11 d, ,, \ 
chamada de procedimento remoto permite a comunicação l11d1111 1,111 d l 1111 d,,. 
objet:ivos é aumentar o desempenho do sistema ao distriblllr a computação a ser 
realizada entre vários processadores. 129 
Em uma chamada de procedimento remoto (RPC), um processo no sistema 
local invoca um procedimento em algum sistema remoto. A Figura 2.12 ilustra o 
estilo arquitetural de chamada de procedimento remoto no qual temos a comu-
nicação entre o processo cliente e o processo servido via rede. 
Processo c11ente 
rotinas do 
cliente 
ada de -~ cham 
proce 
lo 
dimento 
cal 
,. 
instância do 
cliente 
... Jl . .................. 
ada ao cham 
sis tema 
1 
rotinas de 
rede 
kernel local 
-~ 
.... 
········processo serv1aor 
rotinas do 
servidor 
a 
1J 
instância do 
servidor 
. ..................... 
comunicação via rede 
rotinas de 
rede 
kernel remoto 
Figura 2.12 Chamada de procedimento remoto. 
Nessa figura, temos dois processos: cliente e servidor. O processo cliente faz 
uma solicitação, isto é, uma chamada de procedimento remoto, a algum outro 
processo. O processo que recebe a solicitação, após tratá-la, retorna o(s) resulta-
do(s) ao processo cliente. 
Abaixo, descrevemos a seqüência de passos executados durante uma cha-
mada de procedimento remoto, feita por um processo cliente, a algum pro-
cesso. 
1. O cliente invoca um procedimento local, denominado na Figura 2.12 de 
instância de cliente (isto é, client stub). Dessa forma, tudo se passa como 
se o cliente estivesse chamando o procedimento do processo (servidor) o 
qual deseja chamar. O propósito dessa instância de cliente é empacotar os 
argumentos a serem passados ao procedimento remoto, possivelmente 
colocando os em algum formato a fim de enviá-los como mensagens via 
n·d1· F,,1· 1·1111Mcotamento de argumentos do cliente é normalmente co-
11l1n 1d1111111111 marshaling. 
2. As t11l"t1sag,ens de rede são enviadas ao processo (do sistema remoto) atra-
vés d., 111stância do cliente. Isso requer uma chamada ao kernel local. 
3. Depois disso, as mensagens de rede são transferidas ao processo do siste-
ma remoto, utilizando algum protocolo que pode ou não ser orientado à 
conexão. 
4. Uma instância do servidor (server stub) fica esperando por alguma solici-
tação do cliente. A instância do servidor desempacota os argumentos da 
mensagem de rede. Esse processo de desempacotamento é chamado de 
unmarshaling. 
5. A instância do servidor ou server stub faz uma chamada a um procedimen-
to local a fim de invocar um procedimento (próprio) do servidor, passan-
do a ele os argumentos recebidos na mensagem de rede enviada pela ins-
tância do cliente. 
6. Quando o procedimento do servidor é encerrado, ele retorna resultados à 
instância do servidor. 
7. A instância do servidor, se necessário, efetua alguma conversão e empaco-
ta o(s) resultado(s) em uma ou mais mensagens de rede,'"enviando-as à ins-
tância do cliente. 
8. As mensagens são transferidas de volta ao cliente via rede. 
9. A instância do cliente lê as mensagens do kernel local. 
1 O. Após efetuar conversão, os resultados são passados pela instância do cli-
ente ao cliente. 
Note que tudo se passa como se um processo fizesse uma chamada a outro 
processo e tudo acontecesse localmente. Há uma concepção de ocultar a porção 
dl' código de rede nos procedimentos das instâncias de processo (stub). 
Perceba que nesse estilo arquitetural, uma das metas é a decomposição do sis-
1 l"l11a em partes menores de modo a facilitar modificações necessárias. É interes-
s,1111 e observar que o processo cliente não avançará em alguma computação a ser 
l 1·11,1 até que o processo invocado por meio de uma chamada de procedimento re-
111010 retorne a ele o resultado da chamada. Dessa forma, quando da interação 
1·111 re dois componentes (processos) fazendo uso de um conector (chamada de 
111 ocedimento remoto), o componente que fez a invocação ao componente re-
111010 permanecerá aguardando o(s) resultado(s) de sua solicitação. 
2.8 Variações de Estilos 
1 11 •ic, já dispomos de uma quantidade razoável de estilos arquiteturais. Também 
1 11u>ntramos algumas variações sobre os estilos arquiteturais apresentados ante-
11111 mente. Note que os estilos discutidos ao longo deste capítulo compreendem 
q w11,1s parte daqueles existentes. 
<iuando da apresentação dos estilos, sempre destacamos requisitos não-fun-
1 11111,11s ou requisitos de qualidade desejados nos sistemas a serem desenvolvidos. \ 31 
1 Exemplo de tais ~eq~isitos são d~sempenho, facilidade de moMicação, manut~-
1 ~ibiHdade e conf,abd1dade do sistema. 
Os estilos arquiteturais introduzidos neste capítulo são, em alguns casos, ge-
néricos. Isto é, eles ainda requerem que decisões de projetos sejam tomadas já 
que algumas, senão muitas, ficaram indefinidas. 
Na prática, contudo, a arquitetura de um sistema quase nunca é obtida a par-
tir de um único estilo. Assim, o arquiteto de software necessita compreender pos-
síveis relacionamentos existentes entre estilos. Isso requer conhecer os atributos 
de projetos, requisitos não-funcionais bem como exige um processo de análise 
arquitetural. Tais tópicos serão discutidos nos dois capítulos subseqüentes. 
Um projetista ou arquiteto de software tem uma visão do sistema decompos-
to em seus principais componentes. Assim, ele identifica os componentes exis-
tentes bem como as interações entre esses componentes. Vale lembrar que pode-
mos ter interações de controle ou de dados entre componentes. Quando investi-
gando se um ou mais estilos arquiteturais é/são adequado(s) ao sistema em desen-
volvimento, o projetista levanta questões como: 
• Qual a topologia do estilo arquitetural? 
• Como ocorre a transferência de dados e/ou controle entre componentes? 
• Quais tipos de componentes e conectores são utilizados nesse estilo? 
• Como o controle é compartilhado entre componentes? 
• Há algum tipo de interação entre dados e controle? 
• O tipo de análise a ser feita tem qualquer influência sobre o estilo? 
• Os componentes interagem de forma síncrona ou assíncrona? 
Essas questões ajudam a compreender o quão apropriado é o uso de um estilo 
num sistema em desenvolvimento. Como veremos no Capítulo 3, cenários são 
desenvolvidos objetivando verificar se o estilo oferece suporte aos requisitos de 
qualidade desejados no sistema. 
Note que a maioria dos sistemas, na prática, faz uso de mais de um estilo ar-
quitetural. Essa heterogeneidade pode se dar de maneira hierárquica. Considere 
um sistema organizado em camadas a qual pode ser composta de objetos. Uma 
ilustração desse exemplo é mostrada na Figura 2.13. 
Em sistemas de grande porte, verificamos que a arquitetura do sistema é na 
realidade uma combinação de estilos, a exemplo do que foi ilustrado na Figura 
2.13. Um exemplo de sistema comercial faz uso da arquitetura CORBA (Com-
mon Object Request Broker Architecture) que acomoda tanto o estilo arquitetu-
ral de camadas quanto o de objetos. A Figura 2.14 mostra a interação entre um 
cliente e uma implementação de objeto na arquitetura CORBA. 
Essa figura mostra uma solicitação de um cliente sendo passada a uma imple-
mentação de objeto na arquitetura CORBA. Nesse caso, tanto cliente quanto ob-
321 jeto encontram-se em máquinas distintas e a comunicação ocorre via rede. Existe 
umaIDL (Interface Definition Language) entre objeto e a ORB (Object Request 
Broker). Perceba que tanto cliente quanto objeto são isolados da ORB através da 
IDL. Isso porque a arquitetura CORBA requer que toda interface de objeto seja 
expressa através de IDL. 
1 
__________ Estilo de objetos----------, 
1 
obj2 
--1 , ........ 
1 ', 
1 
1 
', 1 
Estilo de camadas 
1 
1 
obj1 
obj3 
,, 
r-, 
" obj4 
' \ 
\ 
\ 
\ 
\ 
\ 
\ 
\ 
\ 
\ 
\ 
\ 
--------
\ , ~...-__,__., 
\ 
\ 
\ 
L--------------------------------
\ 
\ 
' ' ':, ,-------
Figura 2.1 l Combinação de estilos. 
cliente 
1 1 
lmplem.Obj 
1 1 
lmplem.Obj 
1 
cliente 
IDL IDL IDL IDL 
ORB 1 ORB 
..... ~ rede 
..... 
Figura 2.14 Interação entre cliente e objeto na arquitetura CORBA. 
..... ... 
1 
Note que os clientes vêem apenas a interface de um objeto. Isso assegura a 
sL1bstituição ou modificação de qualquer implementação por trás da interface. 
D essa forma, poderíamos conectar ou desconectar componcnrcs sem implicar 
mudanças nos demais componentes. 
A ORB é encarregada de tratar as comunicações via I nk p.11,1 l lit·111t·s t· oh)l' 
t<•s. Perceba que qualquer solicitação de um cliente não p.,., .1 d11 cl,11111 1111 p 11 1 
uma implementação de objeto. As solicitações sãos ·111p1r 11,11,1d I IH l 1 ( llU\ 
Nesse caso, qualquer invocação a um objeto é passada p1 IIIH 1111 1 < li' li 
Note que a Figura 2.14 dá ênfase a comunicação de Ol{B para ORB. Entre-
ta nto, não há qualquer diferença seja na implementação d<, 111 )jeto local ou remo-133 
ta. Se remota, a invocação passa da ORB do cliente para a ORB da implementa-
ção do objeto. , . . . _ , . 
É importante acrescentar que as IDLs provêm suporte a d1stnbmçao de van-
,1., llll 111,1-.: d,10 c11l.1s1 · ,11, t ' lll ,q1s1d,111111110, dl l11H 111 111H 1,1 111 , 1 11p,,.., 11 111 .1111h1 
gu,1111t·11te. Akm disso, 11111 rcpos1tor10 dl' 111tt•d,tLl'S 011 1111c1 l.1l l l l'po -.lllll y (IR) 
compartilhado assegura que todas as ORHs na rede tenh,1111 ,lll 's-.o ,Is dl'/11111,m·-, 
de interface IDL. 
A Figura 2.15 ilustra o modelo de gerenciamento de objetos da arquitetura 
CORBA. Esse modelo inclui as facilidades e serviços oferecidos. 
objetos da 
aplicação 
facilidades verticais 
CORSA(domínio) 
ORB (Object Request Broker) 
serviços CORSA 
facilidades 
horizontais CORSA 
Figura 2.15 Modelo de gerenciamento de objetos. 
O modelo apresentado nessa figura define os serviços e facilidades ofereci-
dos para arquitetura de objetos em CORBA. Perceba que várias facilidades são 
providas na arquitetura. Além disso, CORBA oferece diversos serviços, tais 
como serviços de nome e serviços de notificação de eventos. 
Uma discussão mais detalhada sobre CORBA exigiria, na realidade, outro li-
vro. Aqui, nosso interesse se restringe a identificar os aspectos mais importantes 
e qualidades que essa arquitetura suporta. 
Cabe destacar que a arquitetura CORBA oferece suporte a manutenibilida-
de em que a adição, remoção ou modificação da implementação de objetos 
ocorre de forma independente não acarretando necessidade de alteração em 
outros componentes. Ademais, ela provê suporte e confiabilidade e tolerância a 
falhas. 
2.9 Resumo 
Um dos principais aspectos do projeto arquitetural é o uso de padrões de organiza-
ção de um sistema. Muitos desses padrões, também chamados de estilos arquitetu-
rais, têm sido desenvolvidos ao longo do tempo à medida que projetistas de siste-
341 mas reconhecem o valor de princípios de organização bem como estruturas para 
certas categorias de software. Este capítulo fez a introdução de um novo tópico de 
estudo apresentando um conjunto de estilos arquiteturais. Foram indicados com-
promissos e características associados às várias opções de estilo arquitetural. 
2.1 O Exercícios 
1. Sclnio11r grupos tk du,1s pesso,1<, · sol1l1t1· que cada grupo enumere as 
v,111t,1ge11s e desvnntagens de <.:.1d,1 u111 dos l''>lilos arquiteturais estudados 
neste capítulo. 
2. Com base no resultado obtido na questao 1, p ·ça que cada grupo propo-
nha istemas onde o estilo arquitetural estudado seja adequado. 
3. Em que situação a heterogeneidade de estilos pode ser necessária? 
135 
	Mendes Estilos Arquiteturais pag1 1_stitch
	Mendes Estilos Arquiteturais pag2 1_stitch
	Mendes Estilos Arquiteturais pag3 1_stitch
	Mendes Estilos Arquiteturais pag5 1_stitch
	Mendes Estilos Arquiteturais pag6 1_stitch
	Mendes Estilos Arquiteturais pag7 1_stitch
	Mendes Estilos Arquiteturais pag8 1_stitch
	Mendes Estilos Arquiteturais pag9 1_stitch
	Mendes Estilos Arquiteturais pag10 1_stitch
	Mendes Estilos Arquiteturais pag11 1_stitch
	Mendes Estilos Arquiteturais pag12 1_stitch
	Mendes Estilos Arquiteturais pag13 1_stitch
	Mendes Estilos Arquiteturais pag14 1_stitch