IFPA - Instituto Federal do Pará - Campus Belém

Tecnologia em Análise e Desenvolvimento de Sistemas (TADS)

1 - Arquitetura de Software
(Multicamadas)
(parte 1)
Desenvolvimento de Aplicações Multicamadas

Prof. Claudio Martins

claudio.martins@ifpa.edu.br
claudiomartins2000@gmail.com
 Assuntos
◆Visão geral – Arquitetura de Software
◆História e evolução das arquiteturas de software
◆Arquitetura de duas e três camadas (multicamadas)
◆Computação distribuída x multicamadas
◆Exercícios

2
 Visão geral – Arquitetura de Software

A Arquitetura de
construções:
das ideias às realizações.

Esquema de uma queda d'água de Escher

http://pt.wikipedia.org/wiki/Maurits_Cornelis_Escher
3
A Arquitetura de construções (Ex: Projeto da Catedral de Brasília)

4
 A Arquitetura de construções (Ex: Projeto da Catedral de Brasília)

Projetada pelo arquiteto Oscar

Niemeyer, a catedral de Brasília tem 16

pilares em curvas, cujo formato se

assemelha a mãos voltadas para o alto,

em sinal de súplica.

5
 O que é uma arquitetura de software?
◆“arquitetura é a estrutura do sistema, que compreende:
− componentes ou partes da implementação
− as propriedades visíveis externamente desses componentes,
e
− as relações entre eles.”

Bass, Len, Clements, Paul, Kazman, Rick, “Software Architecture in Practice” – 1998

6
“Arquitetar” é propor soluções (modelar) antes
de se contruir.

7
O papel do Arquiteto de Software
(definido no Processo Unificado)

8
 O que faz um arquiteto de software?
◆ O arquiteto de software define tecnologias, infra-estrutura,
padrões e metodologias que serão utilizadas nos projetos de
software.
◆ O arquiteto estabelece as melhores soluções para resolver as
questões dos requisitos não funcionais de um sistema:
− Desempenho
− Segurança
− Escalabilidade
− Portabilidade
− Usabilidade
− Persistência, e muito mais...
9
 Desejos, preocupações e proposições de
projeto
Direciona para
(propostas)

Preocupações dos Atributos de Qualidades

Interessados (stakeholders)
* Aumentar participação no mercado...
* Manter a reputação e qualidade...
* Adicionar novas características sem problemas...
* Facilitar a programação do software...
* Integrar com outros sistemas facilmente...
(requisitos não funcionais)
- Modificabilidade, Usabilidade
- Desempenho, Usabilidade, Disponibidade
- Desempenho,Disponibidade, Modificabilidade
- Modificabilidade
- Interoperabilidade, Portabilidade, Modificabilidade

FONTE: Software Architecture in Practice (3rd Edition) [2012] -Len Bass, Paul Clements, Rick Kazman 10
O arquiteto de software e visões (modelos) do projeto

Os modelos do Processo Unificado

– Cada modelo representa uma visão do projeto
– Cada modelo é um ponto de vista ou perspectiva de uma
etapa do ciclo de vida do software

11
Desenvolvimento de Aplicações e cuidados
com a arquitetura de software
“Sistemas são frequentemente substituídos ou
redesenhados não porque suas funcionalidades são
deficientes – as substituições geralmente são
idênticas em termos de funcionalidades – mas
porque eles são difíceis de manter, portar, escalar,
ou porque são muito lentos, ou porque foram
comprometidos por eventos inseguros ...”

FONTE: Software Architecture in Practice (3rd Edition) [2012] -Len Bass, Paul Clements, Rick Kazman 12
Software para Aplicações Empresariais
(Corporativas)
O que é Software para Aplicações Empresariais
(Corporativas)?
◆ É um software desenvolvido para atender as necessidades de
processos de negócio e de fluxo de dados de uma empresa.
− Geralmente manipulam grandes bases de dados, necessitam
compartilhar dados com vários usuários ou integrá-los com
outros sistemas.
− São chamados também de Sistemas de Informação Empresarial, ou
simplesmente Aplicações Corporativas

14
O que é Software para Aplicações Empresariais
(Corporativas)?
◆ São exemplos (de domínios de sistemas):
− Controle de gestão: financeiro, recursos humanos, compras
− Processos Industriais: para produção industrial ou processos de
fabricação integrados aos sistemas de gestão
− Comercial: sistemas de vendas e suporte a clientes
− Sistemas bancários, de seguro, entre outros.

15
 O que não é uma aplicação corporativa?
◆O software não é um sistema de informação
empresarial (Aplicação Corpotativa), quando atende
um problema específico de uso pessoal ou industrial,
por exemplo:
− Sistemas embarcadas (em carros, televisão digital, console
de vídeo, controles de um robô, para câmera digital, etc).
− Sistemas para telefonia e telecomunicações;
− Sistemas aplicativos para escritório (editor de texto, planilha,
etc).

16
 Histórico
◆Podemos encontrar algumas formas de organizar a
evolução dos sistemas empresariais, mas em geral,
encontramos três grandes momentos ou “ondas” (com
alguns autores chamam):
− 1a. Onda: aplicações monolíticas (anos 1950 a 70)
− 2a. Onda: aplicações cliente/servidor (anos 1980 a 90)
− 3a. Onda: aplicações distribuídas (metade dos anos 1990)
− Observem que estamos convivendo com a evolução da terceira onda, onde há
computação em “nuvem”, Internet das coisas, computação ubíqua, convergência
entre plataformas e tecnologias (móvel, multimídia, TV Digital, etc). Não sabemos
ainda as consequências dessas mudanças.
17
 1a. onda - aplicações monolíticas
(anos 1950 a 1970)
◆ Uso de “mainframes” (hardware era
muito caro) em salas fechadas (CPD)
◆ aplicações de software monolíticas (uma
camada), com programas e dados
firmemente entrelaçados.
− Cada desenvolvedor de aplicação
escolhia como estruturar e armazenar os
dados e usava freqüentemente técnicas
para minimizar o caro armazenamento
◆ Integração estreita entre
− Um dos problemas que surgiu foi “ano programa e dados
2000” ou “bug do milênio”). dificultava a evolução e
reuso de componentes.
18
2a. onda - aplicações cliente/servidor (anos 1980 a 90)
◆ Sistemas passam a usar software para gerenciamento de banco de dados.
◆ Separação de programa aplicativo dos dados armazenados em SGBD (duas
camadas).
◆ Adoção de interfaces gráficas (janelas) e acesso de informação em tempo
real em estações de trabalho (desktops) ao SGDB das empresas.
◆ Aumento no tamanho e complexidade de aplicações cliente (os clientes
“pesados”)
− Dificuldade em atualizar versões nas estações

◆ Apesar do compartilhamento e separação de dados dos programas, havia

pequeno reuso de lógica empresarial encapsulada (componentes).

19
 Aplicações cliente/servidor – Duas camadas
◆ Camada Cliente
− Aplicação com lógica de negócio e
apresentação (janelas)
− Muito processamento
− Uso de meddleware para conexão ao
servidor
◆ Camada Servidora
− Armazenamento usando um SGBD
(relacional)
− Algumas regras de negócio
armazenadas no banco (em forma de
stored procedure e triggers) 20
 3a. onda - aplicações distribuídas
(metade dos anos 1990 até hoje)
◆Processamento da aplicação é distribuído em várias
máquinas
◆Evolução do C/S

◆Modelos físicos:
− Cliente/Servidor
− Peer-to-peer (ponto-a-ponto)
− Híbrido (ex: Web, Email)
− Várias Camadas
21
 Aplicação Distribuída x Multicamadas
A diferença é conceitual.
◆ Aplicação distribuída é um conceito genérico para denominar a
distribuição de algum tipo de processamento da aplicação entre
máquinas que estão na rede.
◆ Aplicação multicamadas conceitualmente é aquela aplicação
distribuída onde estão claramente identificadas pelo menos as três
principais camadas físicas e a comunicação ocorre com objetos
distribuídos por meio de troca de mensagens:
− Camada de Apresentação e Serviços (das interfaces com outros sistemas ou com o usuário)

− Camada de Negócio (também chamado “Aplicação”)

− Camada de Acesso a Dados (de Persistência e Banco de Dados)
22
 Arquitetura Multicamadas (3 Camadas)
◆ Em tese, em uma aplicação multicamadas qualquer camada pode
se ligar a outra.
◆ O modelo 3 Camadas é similar ao modelo cliente/servidor com um
servidor de chamadas remotas de processamento no meio (entre
o Cliente e o Servidor)
− A lógica do negócio fica disponível na camada do meio
− A camada “do meio” fala com a base de dados

23
Arquitetura típica em Três Camadas
O “cliente” é uma
aplicação com
uma
interface com
o usuário.

Ex: GUI (Janelas),

Browser,
aplicativos
móveis, etc.

24
24
Arquitetura típica em Três Camadas
A camada de
“lógica de negócio”
é responsável pelo
código da
aplicação,
respondendo aos
clientes e
processamento
dados que estão
armazenados em
um banco de
dados, ou
acessando serviços
que estão em
25
outros sistemas.
25
Arquitetura típica em Três Camadas
A camada de
“banco de dados”
(ou de Serviços) é
responsável pelo
armazenamentos
dos dados ou pelo
acesso aos
serviços de dados
que estão em
outros sistemas.

26
26
 Arquitetura Multicamadas (3 Camadas)
A distinção entre 3 níveis lógicos, sugere inúmeras
possibilidades para distribuir a aplicação ou partes do
cliente/servidor sobre diferentes máquinas (camadas físicas).
◆ Pró(s)
− Mais flexibilidade (crescimento, tolerância a falhas, etc)
− Maior independência dos dados por parte do cliente
◆ Contra(s)
− Muita complexidade para controlar/gerenciar
− Muitos tipos de implementação e padrões tecnológicos (Java RMI,
EJB, .Net, RPC, Corba, Web, XML, Ajax, etc) 27
 Arquitetura em Duas Camadas
• Nessa arquitetura, a organização do software acontece em
duas camadas físicas:
 máquinas cliente: contém os programas responsáveis pela
interface com o usuário ou parte da lógica de negócio;
 máquina servidor: contém o banco de dados e os programas
que implementam o processamento do negócio e de dados.
Aplicação
Cliente

Aplicação Conexões Computador

Cliente Servidor Banco de
de BD
Central dados
Aplicação
Cliente
28 Camada 2: Servidor
Camada 1: Cliente
28
 Arquitetura em Duas Camadas
Essa arquitetura prevaleceu nos anos 1980-2000, com o sucesso das
redes locais e o barateamento dos computadores.
Entretanto, o modelo 2 camadas (C/S) apresenta vários problemas, como:
 Falta de escalabilidade (limites de conexões a bancos de dados)

 Enormes problemas de manutenção (mudanças na lógica de

aplicação forçava instalações dos aplicativos clientes)

 Dificuldade de acessar fontes heterogêneas (acesso a múltiplos

bancos, acesso aos sistemas legado CICS, 3270, etc)

Atualmente ainda encontramos softwares construídos com essa estrutura,

como aplicativos de “nicho”. Ex: jogos, CAD-CAM, medicina, etc)

Veremos a seguir as variantes e detalhes do modelo Cliente-Servidor.

29
29
 30

Arquitetura em 2 camadas
2 Camadas é uma arquitetura mais simples de construir, mas possui variantes de
organização das responsabilidades :
Cliente Magro Cliente Gordo
(Thin Cliente) (Fat Cliente)

Camada 1
(Cliente)

Camada 2
(Servidor)

(pag 77, Tanenbaum)

2 Camadas: Abordagem Cliente “magro” (Thin client):
Na solução mais “radical” do cliente “magro”, praticamente
tudo é manipulado pelo servidor enquanto o cliente é
essencialmente um terminal 'burro‘, com alguma interface
gráfica.
 Camada 1 (cliente): interface
 Camada 2 (servidor de BD): bancos de dados + lógica de negócio

Desvantagens:
 todo o processamento é feito no servidor, que exigirá uma
configuração de máquina superestimada para suportar momentos
de sobrecarga.
 difícil de manter (código de negócio oculto no banco, em forma de
31 stored procedures e triggers)
31
2 Camadas: Abordagem Cliente “gordo” (Fat Client):
Nesse caso, as camadas de interface e de aplicação são
unidas em uma única camada, que executa no cliente. A
camada restante continua sendo o banco de dados.

 Camada 1 (cliente): interface + lógica de negócio

 Camada 2 (servidor de BD): bancos de dados

Desvantagens:
 Maior parte do processamento é feito no cliente, portanto, a máquina
cliente deve ter um maior poder de computação.
 difícil de manter (código “misturado”, com muitas responsabilidades)
 difícil de escalar (em número de usuários e acessos) e de implantar
32 (distribuição da aplicação cliente em muitas máquinas)
32
Leitura Adicional

1. Aplicações corporativas multicamadas (Parte 1).

Projetando aplicações em arquitetura multicamadas
usando Java EE. Claudio Martins, Revista Java Magazine.
2012. Disponível no driver virtual e
https://www.devmedia.com.br/aplicacoes-corporativas-
multicamadas-partes-1-e-2/26545
2. Padrões de Arquitetura de Aplicações Corporativas. Martin
Fowler – Ed. Bookman. 2006. Capítulo 1 “Criando Camadas”.
Disponível no Driver Virtual.

33
Exercícios

34
 Questões de Concurso (1)
1 - ( Prova: FCC - 2010 - TRT - 22ª Região (PI) - Técnico Judiciário - Tecnologia da Informação)
Em relação à arquitetura de sistemas multicamadas, considere as assertivas abaixo.

Os itens I a IV referem-se,
respectivamente, aos
modelos de
a) 2, 2, 2 e 2 camadas.
b) 3, 3, 3 e 3 camadas.
c) 2, 2, 3 e 3 camadas.
d) 3, 3, 2 e 2 camadas.
e) 2, 3, 2 e 3 camadas.

35
 Questões de Concurso (2)
2 - ( Prova: FCC - 2010 - TRT - 20ª REGIÃO (SE) - Técnico Judiciário - Tecnologia da
Informação)
A arquitetura multicamadas divide-se em três camadas lógicas. São elas:
a) Apresentação, Negócio e Acesso a Dados.
b) Apresentação, Natureza e Acesso a Dados.
c) Apresentação, Negócio e Alteração.
d) Manipulação, Natureza e Acesso a Dados.
e) Manipulação, Negócio e Acesso a Dados.

36
 Questões de Concurso (3)
3- Prova: ESAF - 2006 - CGU - Analista de Finanças e Controle - Área - Tecnologia da Informação - Prova 3)
Com relação à arquitetura em camadas no desenvolvimento Orientado a Objetos
é correto afirmar que:
a) uma camada é diretamente dependente de todas as outras camadas existentes
na aplicação.
b) as camadas se comunicam da base para o topo.
c) na camada de apresentação a lógica de interface do usuário é o ponto mais
forte.
d) nenhuma camada pode ser desativada de qualquer outra camada, exceto da
camada imediatamente inferior a ela.
e) a camada de negócio é responsável pelo armazenamento e recuperação dos
dados.

37
 Questões de Concurso (4)
4) Ano: 2016 Banca: FGV Órgão: SEE-PE Prova: FGV - 2016 - SEE-PE - Professor de
Desenvolvimento de Sistemas
Com relação às vantagens da arquitetura multicamadas, assinale V para a
afirmativa verdadeira e F para a falsa.
( ) Ajuda a abstrair à lógica do acesso a dados.
( ) Permite a reutilização de objetos por outras aplicações.
( ) Dificulta manutenções na base de dados.

As afirmativas são, respectivamente,

A) F, V e F.
B) F, V e V.
C) V, F e F.
D) V, V e F.
E) F, F e V.
38
 Questões de Concurso (5)
5) Prova: CESPE - 2010 - SAD-PE - Analista de Controle Interno – Tecnologia da
Informação:
A figura a seguir apresenta uma
proposta de organização da arquitetura
de aplicações Internet-web em várias
unidades, denominadas “tiers” ou
camadas, destacando-se, no modelo
indicado, a presença de cinco
unidades: Client, Presentation,
Business Logic, Integration e Data.
Destaca-se, ainda, uma sequência de
comunicações estabelecidas entre
essas unidades, numerada de 1 a 7.

39
A partir dessas informações e dos conceitos de arquitetura de aplicações para ambiente
Internet, arquitetura de três camadas e arquitetura cliente-servidor, julgue os itens
seguintes.

I - A comunicação indicada por 7 é, usualmente, realizada em resposta a um pedido http.

II - Em um sistema de arquitetura em três camadas — apresentação, negócio e dados —
, podem residir, em uma mesma camada, as unidades integração e dados.
III - Do ponto de vista da arquitetura cliente-servidor, existem, na figura apresentada,
vários clientes e vários servidores.
IV - A troca de informações de modo assíncrono é um mecanismo de uso mais frequente
nas comunicações indicadas por 6 e 1 que nas comunicações indicadas por 2 e 5.
V - As comunicações indicadas por 3 e 4 realizam-se, exclusivamente, por meio da
linguagem SQL.
Estão certos apenas os itens:
a) I, II e III.
b) I, II e V.
c) I, III e IV.
d) II, IV e V.
e) III, IV e V
40
 Questões de Concurso (6)
6) Prova: CESPE - 2009 - TCE-TO - Analista de Controle Externo - Informática - Processamento de Dados
Assinale a opção correta, acerca da tecnologia cliente-servidor.

a) Em uma arquitetura do tipo two-tier, as aplicações são normalmente divididas em

duas camadas de serviços: de usuário; e de negócio.
b) A lógica da aplicação pode residir na interface do usuário ou no servidor
produzindo dois modelos, entre eles, o FatClient, em que a interface do usuário e os
dados estão no cliente e a lógica do negócio está no servidor.
c) No modelo ThinClient, a interface do usuário e a lógica do negócio residem no
cliente e a lógica do banco de dados reside no servidor.
d) No ambiente Windows, as camadas do modelo three-tier são conhecidas como
user services, business services e data services.
e) Na arquitetura de três camadas, os dados recebem uma camada separada que
pode ser gerenciada por um middleware como o IIS (Internet information server).

41