Você está na página 1de 27

Projeto de Arquitetura

Prof. Denise Franzotti Togneri

Arquitetura de Software

A arquitetura de software de um programa ou um sistema


computacional definida como a estrutura ou estruturas do sistema
que englobam:
os componentes de software;
as propriedades externamente visveis desses componentes;
os relacionamentos entre os componentes.
A arquitetura no o software operacional, mas sim uma
representao que permite ao engenheiro de software
analisar a efetividade do projeto em atender aos requisitos
declarados;
considerar as alternativas arquiteturais em um estgios onde
mudanas de projeto so relativamente fceis;
reduzir os riscos associados com a construo do software.
Denise F. Togneri

Arquitetura de Software - Componentes

Componentes so blocos de construo de software que so


desenvolvidos com objetivo de serem posteriormente
reutilizados em diferentes aplicaes.
Esses componentes so empacotados a fim de prover conjuntos de
servios que so acessveis apenas atravs de uma interface bem
definida e documentada.
Devem ser projetados com a preocupao de colaborar e no
interferir uns com os outros.
Sua reutilizao deve ser perseguida; porm, a fcil substituio de
um componente por outro mais especializado um fator mais
importante.
No contexto do projeto de arquitetura, um componente de software
pode ser, por exemplo:
um mdulo de um programa;
bancos de dados;
Middlewares.
Denise F. Togneri

Projeto de Arquitetura (ou arquitetural)

Define os componentes estruturais do software e seus


relacionamentos.
Essa representao de projeto - uma framework modular - pode ser
derivada a partir do modelo de anlise e da interao de subsistemas
definidos no modelo de anlise.
Tem como objetivo representar a estrutura dos componentes do
software, suas propriedades e interaes.
Para alcanar esse objetivo, o arquiteto de software deve selecionar
um estilo de arquitetura que seja apropriado para os requisitos,
restries e atributos de qualidade levantados e documentados na
atividade de Engenharia de Requisitos.
Assim que a alternativa tenha sido selecionada, a arquitetura
elaborada usando um mtodo de projeto de arquitetura.
Denise F. Togneri

Objetivos do Projeto de Arquitetura

At o projeto arquitetural, a questo do hardware ainda no foi tratada,


j que na fase de anlise pressupe-se tecnologia perfeita.
Este o momento para resolver como este modelo ideal ir executar
em uma plataforma restrita.
importante realar que no existe a soluo perfeita. O projeto da
arquitetura uma tarefa de negociao, onde se faz compromissos
entre solues sub-timas.
Em suma, o projeto arquitetural consiste na alocao do modelo
essencial de requisitos em uma tecnologia especfica, determinando
que processos rodaro em quais processadores, onde os dados sero
armazenados e quanta comunicao entre processadores ser
necessria.
Denise F. Togneri

Objetivos do Projeto de Arquitetura

Ao trmino do projeto arquitetural, a equipe de desenvolvimento deve


ter determinado:
a distribuio geogrfica dos requisitos computacionais;
os componentes de hardware para as mquinas clientes;
os componentes de hardware para as mquinas servidoras;
a configurao e o nmero de camadas de hardware clienteservidor;
a plataforma de software de implementao, incluindo linguagens de
codificao e apresentao (interface com o usurio), sistemas
operacionais, os mecanismos e linguagens de comunicao em rede
e sistema gerenciador de banco de dados;
a localizao ou localizaes dos processos;
a localizao ou localizaes dos dados fsicos e
as estratgias de sincronizao para dados distribudos
geograficamente
Denise F. Togneri

Objetivos do Projeto de Arquitetura

Muitas dessas decises j tero sido tomadas previamente, seja


por uma ordem da gerncia, seja pelo fato da organizao j
possuir uma plataforma de hardware e software para
implementao.
Assim, o projeto de arquitetura a busca por um meio menos
objetvel de atingir os requisitos do negcio, reconhecendo as
limitaes da plataforma a ser utilizada (Falbo, 2000).

Denise F. Togneri

Estilo (ou Padro) de Arquitetura

um mecanismo descritivo que diferencia uma categoria de


sistema de outra, alm de ser um padro para construo.
Cada estilo de arquitetura descreve uma categoria de sistemas que
engloba:
um conjunto de componentes (ex. banco de dados, mdulos
computacionais, ...) que executam uma funcionalidade requerida
pelo sistema;
um conjunto de conectores que permitem a comunicao, a
coordenao e a cooperao entre os componentes;
restries que definem como os componentes podem ser integrados
para formar um sistema;
modelos semnticos que permitem ao projetista entender as
propriedades globais do sistema, atravs da anlise das
propriedades conhecidas de suas partes constituintes.
Nesse texto, os termos estilo e padro so usados com mesmo
significado.

Denise F. Togneri

Taxonomia de Estilos de Arquitetura

Arquiteturas centradas em dados;


Repositrio Passivo
Blackboard
Arquitetura de fluxo de dados (pipes and filters);
Arquitetura call and return;
Arquitetura orientada a objetos;
Arquitetura em camadas;
Arquitetura de Aplicaes Distribudas;
Arquitetura Cliente-Servidor de Duas Camadas
Arquitetura Cliente-Servidor de Mltiplas Camadas
Arquitetura de mltiplas camadas com base na Web.

Denise F. Togneri

10

Arquitetura Centrada em Dados

Denise F. Togneri

Arquitetura Centrada em Dados


Caractersticas Principais

11

um depsito de dados reside no centro da arquitetura;


os componentes de software incluem, alteram, consultam e excluem
dados do depsito;
o depsito de dados pode ser:
passivo: chamado de repositrio, onde os softwares clientes
acessam os dados independente de qualquer mudana nos
mesmos ou aes de outros softwares clientes;
blackboard: onde envia notificaes para os softwares clientes
quando dados de interesse do cliente mudam;
os componentes clientes operam de forma independente, permitindo
que novos componentes sejam includos e os existentes sejam
alterados/substitudos.
Denise F. Togneri

12

Repositrio Passivo

Possui 2 componentes bsicos:


Um conjunto de dados compartilhado (que representa o estado atual)
Um conjunto de clientes independentes que tem acesso e atualiza a
base de dados compartilhada.
Caractersticas principais:
Dados compartilhados
Clientes independentes
Arquitetura centralizada
Facilidade de integrao
Repositrio no interage com o cliente
Vantagens
Facilidade de integrao
Independncia dos clientes
Desvantagens
O repositrio compartilhado no interage com os clientes
Possibilidade de clientes diferentes resolverem problemas iguais

Denise F. Togneri

13

BlackBoard
Clula de
conhecimento

Clula de
conhecimento

Quadro-negro
(banco de dados
compartilhado)

Clula de
conhecimento

Clula de
conhecimento
Denise F. Togneri

14

BlackBoard

Este padro usado quando no se conhece uma soluo


determinstica para o problema.
Neste padro, vrios subsistemas especializados unem seus
conhecimentos para construir uma soluo parcial ou aproximada.
Vantagens:
Facilidade para adicionar ou remover quantidade e tipos de
dados.
Manutenibilidade . um dos principais requisitos no-funcionais
a que este estilo da suporte.
Desvantagens:
A necessidade do componente passa pelo repositrio de dados
em busca de uma soluo.
Redundncia na tentativa de mltiplos componentes
processarem dados de um problema.

Denise F. Togneri

Arquitetura de Fluxo de Dados


(Pipes and Filters)

15

Denise F. Togneri

Arquitetura de Fluxo de Dados


(Pipes and Filters)

16

um estilo arquitetural de pipes e filtros que geralmente considera


uma rede pela qual flui dados de uma extremidade (origem) outra
(destino).
Pipe: prov uma forma unidirecional de fluxo de dados, atuando como
um condutor para o fluxo de dados entre a fonte at um destino.
Filtros: incrementam, extraem ou transformam os dados recebidos de
alguma fonte de dados.
aplicada quando dados de entrada so transformados atravs de uma
srie de componentes computacionais ou manipulativos em dados de
sada;
cada componente trabalha de forma independente; preparado para
receber os dados de entrada de certa forma e produzir dados de sada
para o prximo filtro de forma especfica;
o filtro no precisa ter conhecimento do trabalho de seus filtros
vizinhos.
Denise F. Togneri

Arquitetura de Fluxo de Dados


(Pipes and Filters)

17

Vantagem
A manutenibilidade , geralmente, mais flexvel, possibilitando a
reorganizao de filtros e pipes.

Desvantagem
As mudanas freqentes em um componente (filtro) impactam
em outros componentes, limitando o apoio manutenibilidade,
sob esse aspecto.

Denise F. Togneri

Exemplos de Arquitetura de Fluxo de


Dados (Pipes and Filters)

18

Unix
Filtros

programa who

programa sort

Pipes

Denise F. Togneri

Exemplos de Arquitetura de Fluxo de


Dados (Pipes and Filters)

19

Compilador

Anlise lxica

Anlise sinttica

Anlise
semntica

Otimizao

Gerao de
cdigo

Denise F. Togneri

20

Arquitetura Call and Return

Denise F. Togneri

10

21

Arquitetura Call and Return


Permite projetar uma estrutura de programas relativamente fcil de
modificar e escalvel;

Este estilo de arquitetura contm alguns sub-estilos:


arquitetura programa principal/sub-programas
essa estrutura de programas clssica decompe as funes em
uma hierarquia de controle onde um programa principal
chama um nmero definido de componentes de programas
que, por sua vez, podem chamar outros componentes;

arquitetura RPC remote procedure call


os componentes da arquitetura programa principal/subprogramas so distribudos entre vrios computadores de uma
rede.
Denise F. Togneri

22

Arquitetura Orientada a Objetos

tem como base o uso de um tipo de dados abstrato - o objeto.


v um sistema de software como um conjunto de objetos
comunicantes com um estado associado a eles;
os componentes de um sistema encapsulam dados e operaes
que devem ser executadas para manipular os dados;
a comunicao e a coordenao entre os componentes efetuada
via troca/envio de mensagens em vez de utilizar variveis
compartilhadas;
visa decompor o sistema em componentes e identificar as
interaes existentes entre esses componentes.
Denise F. Togneri

11

Propriedades da Arquitetura Orientada a


Objetos

23

Objetos so entidades independentes (um tipo de dado abstrato)


que podem sofrer modificaes uma vez que toda informao
pertinente mantida no prprio objeto;
possvel fazer o mapeamento entre as entidades reais e os objetos
que atuam no controle de um sistema, resultando numa melhor
compreenso do sistema;
Objetos podem ser reutilizados devido sua independncia;
Os objetos podem estar distribudos e executar seqencialmente ou
em paralelo, a depender das decises tomadas no incio do projeto.

Denise F. Togneri

Arquitetura de um projeto Orientado a


Objetos

24

estado2
obj2
estado1
obj1

estado5
obj5

estado3
obj3

estado4
obj4

Denise F. Togneri

12

25

Arquitetura Orientada a Objetos

Vantagens
A abordagem orientada a objetos permite a organizao de
programas ao mesmo tempo em que ajuda a manter a integridade
dos dados do sistema.
Os projetistas de sistema podem encapsular dados e
comportamento em objetos os quais possuem interfaces com outros
objetos.
A interao entre objetos se d atravs de canais de comunicao,
abstraindo-se o mecanismo de passagem de mensagens.
Desvantagens
Para um objeto (obj1) se comunicar com um outro objeto (obj2), a
identidade do segundo (obj2) precisa ser conhecida pelo primeiro
(obj1) a fim de que obj1 possa enviar mensagem a obj2. Isso se
constitui numa desvantagem para o reuso, pois teremos de alterar a
especificao de classes quando houver mudanas.
Denise F. Togneri

26

Arquitetura em Camadas

Denise F. Togneri

13

27

Arquitetura em Camadas

Representa um sistema num conjunto de camadas;


Cada camada agrupa um conjunto de tarefas num determinado nvel
de abstrao;
Uma camada de nvel N oferece servios camada no nvel superior
(N + 1);
diferentes camadas so definidas, cada uma delas executando
operaes que se tornam, progressivamente, mais prximas das
instrues de mquina;
a camada mais interna contm componentes que fazem a interface
com o sistema operacional;
a camada mais externa contm componentes que fazem a interface
com os usurios.
Denise F. Togneri

28

Arquitetura em Camadas

melhor exemplificado pelo modelo de referncia OSI (Reference Model for Open
Systems Interconnection) da ISO.
Cada camada pode ser vista como um componente que pode ser implementado por
software ou hardware.
Aplicao

Camada 7

Apresentao

Camada 6

Sesso
Transporte

Camada 5
Camada 4

Rede

Camada 3

Enlace

Camada 2

Fsica

Camada 1

Denise F. Togneri

14

Arquitetura em Camadas
Comunicao entre dois sistemas

29

Para cada camada associada entre os sistemas existe um protocolo.


Segundo Antnio Mendes, o protocolo define o formato, contedo e
significado dos dados trocados entre as camadas associadas a ele.
A transferncia dos dados no ocorre horizontalmente apesar de
possuir entre as camadas um protocolo especfico.
No sistema X, a movimentao dos dados acontece verticalmente a
partir da camada 7 (aplicao) e vai at a camada 1 (fsica). Nessa
camada acontece a comunicao com o outro sistema (Y).
J no sistema Y, a movimentao acontece inversamente (camada 7
para camada 1).

Denise F. Togneri

Comunicao entre dois sistemas numa


arquitetura de camadas

Camada 7
Camada 6

Camada 5
Camada 4
Camada 3

Camada 2
Camada 1

Aplicao
Apresentao

Sesso
Transporte
Rede

Enlace
Fsica

Protocolo da
camada 7
Protocolo da
camada 6
Protocolo da
camada 5
Protocolo da
camada 4
Protocolo da
camada 3
Protocolo da
camada 2
Protocolo da
camada 1

30

Aplicao
Apresentao

Sesso
Transporte
Rede

Enlace
Fsica
Denise F. Togneri

15

31

Arquitetura em camadas

Vantagens
A associao de um protocolo a cada camada constitui na
maneira mais eficiente para organizar uma rede.
permitida variaes sobre os estilos de camadas onde a
camada N poderia acessar no apenas os servios da camada N1, mas tambm s camadas N-2, N-3 ou qualquer abaixo dela.
Desvantagens
A variao na arquitetura pode comprometer a manutenibilidade
dos sistema.
H um custo em promover a flexibilidade do sistema pelo fato do
mesmo percorrer diversas camadas.
O nmero de camadas depende dos requisitos no-funcionais
desejados.
Denise F. Togneri

32

Arquiteturas de Aplicaes Distribudas

Ponto de concordncia na definio de um sistema distribudo: a


presena de mltiplos processadores;
Dois estilos arquiteturais principais: multiprocessadores e
multicomputadores;
Arquitetura Multiprocessadores
Compreende vrios processadores compartilhando uma memria
primria comum;
apropriado para executar, simultaneamente, diversas subtarefas
de um mesmo programa.
Arquitetura Multicomputadores
similar multiprocessadores, exceto que os processadores no
compartilham memria;
Se comunicam atravs de passagem de mensagens numa rede de
comunicao.
Denise F. Togneri

16

Arquiteturas de Aplicaes Distribudas


Arquitetura Multicomputadores

33

Mecanismo de comunicao via passagem de mensagem

Nessa arquitetura, uma aplicao distribuda pode ser vista


como um programa concorrente no qual os processos se
comunicam por meio da passagem de mensagens.

Denise F. Togneri

34

Arquitetura Cliente-Servidor

A arquitetura Cliente-Servidor hoje uma das tecnologias mais


utilizadas em ambientes corporativos;
Substitui uma arquitetura muito rgida que so os sistemas
envolvendo mainframes.

Denise F. Togneri

17

Componentes da Arquitetura ClienteServidor

35

Servidor
esse processo inicializado em algum sistema computacional, entra
num estado de espera e aguarda que algum cliente entre em
contato com ele, requisitando algum servio;
Cliente
Um processo que pode estar no mesmo sistema ou em algum outro,
conectado ao servidor via rede;
Geralmente, interage com o usurio e tem a funcionalidade bsica
de recuperar dados do servidor;
O cliente envia uma solicitao via rede ao servidor para que este
ltimo atenda solicitao, possivelmente, efetuando alguma
computao;
Aps o servidor tratar a solicitao, ele retorna o resultado para o
cliente, voltando em seguida para o estado de espera, no qual
permanecer at que chegue nova solicitao de algum cliente.
Denise F. Togneri

36

Arquitetura Cliente-Servidor

VANTAGENS
Os dados esto concentrados em um nico lugar, para uma nica
fonte de dados, tornando os sistemas mais gerenciveis e
evitando preocupao com consistncia de dados;
Facilidade de remover e/ou adicionar clientes devido
independncia entre processos;
Facilidade de modificar a funcionalidade de um cliente, pois os
outros no sero afetados.
DESVANTAGENS
Exige ligao em rede podendo afetar o desempenho do sistema;
Os clientes podem ficar sobrecarregados;
A queda do servidor far com que todos os clientes fiquem ser as
informaes e os aplicativos, para sistemas com um nico
servidor.
Denise F. Togneri

18

37

Arquitetura Cliente-Servidor
A Arquitetura Cliente-Servidor pode ser implementada adotandose as seguintes arquiteturas:

Arquitetura Cliente-Servidor de Duas Camadas (ou two-tier


client-server);
Arquitetura Cliente-Servidor de Mltiplas Camadas (ou
multi-tier client-server).

Denise F. Togneri

38

Arquitetura Cliente-Servidor de Duas Camadas

Exige uma interface com o cliente para executar as aplicaes


cliente e um servidor de banco de dados para gerenciar as
transaes de dados;
fcil de ser gerenciado quando h uma pequena quantidade
de usurios e quando o volume de transaes baixo.

Usurio

solicitao

solicitao

resposta

resposta

Cliente
(Interface com o usurio)

Servidor de BD
(acesso a dados)
Denise F. Togneri

19

39

Arquitetura Cliente-Servidor de Duas Camadas

Vantagem
Fcil de gerenciado, quando h uma pequena quantidade de
usurios e volume de transaes;
Desvantagem
Exige que cada cliente acomode uma grande quantidade de
funcionalidades, tornando-o grande e complexo;
Manuteno com custo elevado no lado cliente, principalmente
quando vrios clientes necessitam de atualizaes.

Denise F. Togneri

Arquitetura Cliente-Servidor
(Cliente Pesado x Servidor Pesado)

40

Uma classificao, relativamente incorreta, tem sido utilizada para


designar a filosofia adotada em um projeto no que se refere
localizao da maior parte da camada de lgica do negcio.
O termo cliente pesado indica que a camada de lgica do negcio
colocada principalmente na mquina cliente e o servidor dedicado ao
acesso, distribuio e armazenamento de dados, respondendo a
requisies de clientes.
O termo servidor pesado descreve uma alocao de
responsabilidades na qual o cliente limitado apresentao da
interface e edio mnima, enquanto a maior parte da lgica de negcio
e a imposio de regras so executadas no servidor central.
claro que esta uma viso muito simplificada, j que arquiteturas
cliente-servidor em n-camadas podem suportar uma gama complexa de
camadas de software (Falbo, 2000).
Denise F. Togneri

20

Arquitetura Cliente-Servidor
(Cliente Pesado x Servidor Pesado)

41

A primeira gerao de ferramentas populares de desenvolvimento


de aplicaes cliente-servidor com interfaces grficas assumia
uma arquitetura de hardware de duas camadas e
encorajava uma abordagem de projeto arquitetural de software do
tipo cliente pesado, onde a lgica do negcio era totalmente
amarrada camada de apresentao da aplicao.
Estas mesmas ferramentas tem sido utilizadas, em um segundo
momento, com uma filosofia do tipo servidor pesado, onde a lgica de
negcio fortemente mapeada no servidor de dados, na forma de
stored-procedures e triggers em bancos de dados.

Denise F. Togneri

Arquitetura Cliente-Servidor
(Cliente Pesado x Servidor Pesado)

42

Respondendo s demandas por linguagens mais flexveis de


desenvolvimento, a segunda gerao de ferramentas desta
natureza reconhece a necessidade de separar a camada de lgica do
negcio, com as seguintes vantagens (Falbo, 2000):
Reusabilidade
tem sido apontada como a principal razo para a separao;
Classes de apresentao so extremamente fceis de reutilizar dada
sua natureza altamente mecnica;
Classes de negcio, por outro lado, so altamente complexas e
podem desempenhar diferentes papis dentro dos sistemas
corporativos;
A meta criar classes que garantam todas as regras de negcio
para uma particular classe de negcio e reutiliz-la em todos os
contextos que lidem com a mesma;
Esta abordagem possvel em uma filosofia de servidor pesado, mas
impossvel em uma de cliente pesado.
Denise F. Togneri

21

Arquitetura Cliente-Servidor
(Cliente Pesado x Servidor Pesado)

43

Portabilidade
a segunda razo para se efetuar a separao.
A habilidade de mover a lgica de negcio ao longo da arquitetura
cliente-servidor permite que se tire proveito de diferentes
plataformas de hardware e software, sem ter que reescrever grande
pores do cdigo.
Manutenibilidade
a separao favorece a manuteno, j que concentra a lgica de
negcio em uma camada nica da arquitetura de software,
facilitando a localizao das alteraes e evolues a serem feitas no
sistema.

Denise F. Togneri

Arquitetura Cliente-Servidor de Duas


Camadas Modelos de Distribuio
Apresentao
Distribuda

Apresentao
Remota

Apresentao

Apresentao

Aplicao
Distribuda

Dados
Remotos

Apresentao

Apresentao

Aplicao

Aplicao

44

Dados
Distribudos

Apresentao

Rede

Rede

Apresentao

Rede
Rede

Aplicao

Gerncia dos
Dados

Rede
Aplicao

Gerncia dos
Dados

Aplicao

Aplicao

Gerncia dos

Gerncia dos
Dados

Dados

Gerncia dos
Dados

Gerncia dos
Dados

Denise F. Togneri

22

Arquitetura Cliente-Servidor de Duas


Camadas Modelos de Distribuio

Apresentao distribuda
remonta aos primrdios da computao;
a lgica da aplicao e os dados esto localizados em um nico
equipamento;
O processamento todo feito em uma mquina hospedeira (host),
mas os dados so enviados para um terminal que no possui lgica
de programao, ou seja, um terminal que no faz nada a no ser
apresentar os caracteres recebidos.
Apresentao remota
o prximo passo na lgica de apresentao, onde tudo colocado
em PCs ou estaes de trabalho;
tem-se uma apresentao remota quando toda a apresentao
feita em uma mquina, dita cliente, e a lgica da aplicao, ou
processamento, feita em outra dita servidora;
uma separao completa entre a aplicao e a apresentao
bastante complicada, algumas vezes at impossvel, visto que,
normalmente a aplicao e a apresentao esto intimamente
ligadas.
Denise F. Togneri

Arquitetura Cliente-Servidor de Duas


Camadas Modelos de Distribuio

45

46

Aplicao distribuda
trata da lgica da aplicao sendo executada no lado cliente e
alguma parte desta lgica no lado servidor;
a lgica na parte cliente geralmente necessria para que se possa
ter uma interface grfica;
a lgica na parte servidora necessria para se alcanar o
tratamento dos dados, principalmente quando h uma grande
quantidade deles;
Alm do mais, pode-se querer que no lado servidor estejam as
regras de validao do negcio, que vm a ser a lgica da
aplicao, e estas sejam centralizadas para maior facilidade de
manuteno e gerncia;

Denise F. Togneri

23

Arquitetura Cliente-Servidor de Duas


Camadas Modelos de Distribuio

47

Modelo de dados remotos


coloca toda a lgica da aplicao no lado do cliente e todos os
dados no lado servidor. Isto torna os dados acessveis para
mltiplos clientes e aumenta a facilidade de gerncia e segurana,
uma vez que aplicada somente no lado servidor;
Modelo de dados distribudos
tenta reduzir o trfego no necessrio na rede ao se distribuir os
dados;
pode envolver o uso de cpias, rplicas, arquivos ou tabelas de
dados, e pode fazer uso de sistemas de arquivos distribudos ou
gerenciadores de banco de dados distribudos
(Ligon, citado por Moura, 2000).

Denise F. Togneri

Arquitetura Cliente-Servidor de Mltiplas


Camadas

48

A parte lgica especfica da aplicao foi movida do cliente para uma


camada central;
A camada central assume o papel de servidor de aplicao e
encarregada de fazer a mediao entre clientes e recursos;
Toda a lgica da aplicao fica localizada no servidor de aplicao.
Nesse caso, apenas um programa ser modificado quando ocorre
alteraes na aplicao;
O gerenciamento de janelas e interaes com o usurio fica no
componente cliente.

Denise F. Togneri

24

Arquitetura Cliente-Servidor de Mltiplas


Camadas
solicitao

49

solicitao

resposta
Usurio

Cliente
Interface com o usurio)

Servidor de
aplicao

Fontes de dados
Denise F. Togneri

Arquitetura Cliente-Servidor de Mltiplas


Camadas

50

Vantagens:
Apenas um programa ser modificado quando ocorre alteraes
na aplicao;
O gerenciamento de janelas e interaes com o usurio fica no
componente cliente.
Desvantagens:
Desenvolvida com base em arquiteturas proprietrias;
Possui elevado custo de aquisio/licenciamento e manuteno
Requer pessoal altamente treinado para manuteno do
sistema;
Dificuldade de integrao num ambiente heterogneo,
envolvendo mltiplos vendedores;
O processo de desenvolvimento complexo e dispendioso.
Denise F. Togneri

25

Arquitetura de Mltiplas Camadas com


Base na Web

51

Caractersticas
Aplicaes geralmente residem em um servidor num local central,
tornando possvel o acesso Web a partir de qualquer
computador;
necessrio a existncia de um navegador (browser) e uma
conexo com a Internet;

Denise F. Togneri

Arquitetura de Mltiplas Camadas com


Base na Web

52

Vantagens
Baixo custo de manuteno;
Acesso universal atravs de navegadores para clientes;
Acesso de qualquer lugar;
Influncia sobre a infra-estrutura de tecnologia existente;
Aplicaes/solues com base em padres.
Desvantagens
Usurios no podem ter acesso a aplicaes de qualquer local,
impossibilitando o acesso global;
Usurios em instituies com sistemas operacionais e
navegadores incompatveis no podem ter acesso aplicao.

Denise F. Togneri

26

53

Referncias
FALBO, Ricardo de Almeida. Projeto de Sistemas: notas de aula.
UFES, 2000.
MENDES, Antonio. Arquitetura de software: desenvolvimento
orientado para arquitetura. Rio de Janeiro: Campus, 2002.
MOURA, Elton Siqueira. Um sistema de pronturio eletrnico em
ambiente distribudo baseado na arquitetura CORBA. Tese
(Mestrado em Informtica) - Universidade Federal do Esprito Santo,
Esprito Santo, 2000.
PRESSMAN, Roger S. Engenharia de software. 5 ed. Rio de Janeiro:
McGraw-Hill, 2002.
Denise F. Togneri

27

Você também pode gostar