[UFMS Digital] Fundamentos de Web - Videoaula do Módulo 4 - Unidade 1

Prévia do material em texto

Fundamentos de Web
Prof. Dr. Leonardo Souza Silva
Módulo 4 - Tecnologias Front-end
Unidade 1 — Arquiteturas Web
Nesta aula…
● Vamos discutir como evoluímos de páginas estáticas para 
aplicações Web.
● Entender o que é uma arquitetura.
○ Comentar sobre diferentes arquiteturas de software.
● Conhecer a Arquitetura Orientada a Serviços e Microsserviços.
No começo…
● O funcionamento da Web envolvia somente a ligação entre páginas 
desenvolvidas em linguagem HTML.
○ Dessa forma, a comunicação envolvia a transferência do HTML e 
das imagens envolvidas.
● Hoje → Temos inúmeros recursos disponíveis sendo transferidos.
No começo…
● O funcionamento da Web envolvia somente a ligação entre páginas 
desenvolvidas em linguagem HTML.
○ Dessa forma, a comunicação envolvia a transferência do HTML e 
das imagens envolvidas.
● Hoje → Temos inúmeros recursos disponíveis sendo transferidos.
Neste momento, temos uma página HTML, com 
um vídeo incorporado nela e várias funcionalidades 
envolvidas.
Um exemplo
● Ontem → um site para uma pequena loja, reunia muitas vezes 
informações sobre o produto, suas características e informações 
para contato com o vendedor.
● Hoje → temos a possibilidade de construir um site, que apresenta 
as informações do produto, efetiva a venda, se conecta a um banco 
para registrar o pagamento e permite acompanhar as atualizações 
do envio dos produtos.
○ Empresas totalmente online.
Consequência
● Mais profissionais envolvidos no projeto de um site.
● E o projeto deste site se torna mais desafiador, envolvendo 
aspectos que até então não seriam considerados.
○ Segurança, banco de dados, desenvolvimento, desempenho, 
dentre outras.
○ Novo desafio → a manutenção desses sites.
Estratégia
● Planejar a aplicação, seus requisitos e decidir aspectos que 
deverão ser respeitados ao longo de todo o processo de 
desenvolvimento.
● Arquitetar uma aplicação de software, seja ela web ou não, 
permitirá entender as responsabilidades envolvidas e controlar os 
componentes que formam essa aplicação.
● Ajudam a lidar com a complexidade.
Estratégia
● Planejar a aplicação, seus requisitos e decidir aspectos que 
deverão ser respeitados ao longo de todo o processo de 
desenvolvimento.
● Arquitetar uma aplicação de software, seja ela web ou não, 
permitirá entender as responsabilidades envolvidas e controlar os 
componentes que formam essa aplicação.
● Ajudam a lidar com a complexidade.
Estratégia familiar a todos nós, imagine que temos 
um terreno e estamos planejando 
construir uma casa
Projeto de Arquitetura
"Representa a estrutura de dados e os componentes de programa 
necessários para construir um sistema computacional. 
Ele considera o estilo de arquitetura que o sistema assumirá, a 
estrutura e as propriedades dos componentes que constituem o 
sistema, bem como as inter-relações que ocorrem entre todos os 
componentes da arquitetura de um sistema." (Pressman, 2021)
Arquitetura
● Facilita a comunicação entre todos os envolvidos no projeto.
● Orienta, desde o início, as decisões de projeto (que impactam todo 
o processo de desenvolvimento).
● Representa como os componentes do sistema estão estruturados e 
trabalham em conjunto.
Arquitetura
● Orientará inicialmente o desenvolvimento do site.
● Apoiará a equipe de desenvolvimento na produção e gerenciamento 
da aplicação.
○ Redução de custos e riscos.
● E, por fim, irá favorecer a manutenção da aplicação.
○ Melhorias, correção, novas funcionalidades, dentre outras.
Arquitetura Cliente-Servidor
● Cliente → é a interface entre o usuário e o código da aplicação.
● Servidor → repositório dos documentos e/ou dados usados pela 
aplicação, por exemplo, compartilhado pelos usuários.
Fonte: Própria
CLIENTE REDE SERVIDOR
DOCUMENTOS/DADOS
Requisição e 
Resposta
Requisição e 
Resposta
Arquitetura Cliente-Servidor
● Surgiu nos anos 70 na Xerox Palo Alto Research Center (PARC).
● Se caracteriza por ter um servidor atendendo as solicitações de 
vários clientes.
○ Pode usar uma conexão local ou de Internet.
● Base para diversas outras arquiteturas usadas.
Arquitetura Cliente-Servidor 
Prós e Contras
PRÓS CONTRAS
Armazenamento Centralizado Armazenamento Centralizado
Bancos de Dados Centralizados Vulnerabilidade 
Escalabilidade (desempenho) Sobrecarga (servidores)
Gerenciamento de dispositivos Custo dos equipamentos.
Fonte: Própria
Tipos de Arquitetura Cliente-Servidor
● O desenvolvimento de aplicações mais complexas trouxe a 
necessidade de validações, implementação de regras de negócio, 
dentre outros, impondo desafios.
● Arquitetura de 1 camada.
○ Camada de apresentação, lógica de negócio e dados são 
armazenadas em um único dispositivo de armazenamento 
compartilhado.
Tipos de Arquitetura Cliente-Servidor
● Arquitetura de 2 camadas.
○ Camada de apresentação e lógica de negócio são armazenadas 
no cliente, enquanto a camada de dados é armazenada em um 
servidor (exemplo, uma aplicação desktop que exige login).
● Arquitetura de 3 camadas
○ Camada de apresentação é armazenada no cliente, a camada de 
lógica de negócios é armazenada em um servidor e a camada de 
dados é armazenada em outro servidor.
Tipos de Arquitetura Cliente-Servidor
Arquitetura 2 camadas
Fonte: Própria
APLICAÇÃO 
DESKTOP
BANCO DE 
DADOS
SERVIDOR
DOCUMENTOS/DADOS
APLICAÇÃO 
DESKTOP
Conexões 
BD
Tipos de Arquitetura Cliente-Servidor
Arquitetura 3 camadas
Fonte: Própria
APLICAÇÃO 
DESKTOP
BANCO DE DADOS
SERVIDOR DE DADOS
APLICAÇÃO 
DESKTOP
SERVIDOR DE APLICAÇÃO
Conexão 
TCP/IP
Pool de Conexões 
com BD
Arquitetura Model-View-Controller (MVC)
● Muito conhecido no desenvolvimento web.
○ Flexível, apresenta alta escalabilidade e reusabilidade.
● Model → Regras de negócio, interação com o sistema de dados, 
realiza operações associadas a esses dados.
● View → Responsável pela apresentação dos dados aos usuários.
● Controller → camada intermediária, interage com os usuários e 
responde às solicitações. 
Arquitetura Model-View-Controller (MVC)
Fonte: Própria
View
Controller
Model
Interação do 
Usuário
Requisição
Solicita os Dados Retorna os Dados
Renderiza o Conteúdo
Requisição /
 Resposta
BANCO DE DADOS
USUÁRIO
Arquitetura Orientada a Serviços (SOA)
● Serviço - pode ser definido como uma função independente e bem 
definida que representa uma unidade de funcionalidade de um 
negócio.
● Características:
○ Um serviço pode trocar informações com outro serviço.
○ Não possui um estado (stateless), e
○ O estado de um serviço não depende do estado de outro serviço.
Arquitetura Orientada a Serviços (SOA)
● O sistema é apresentado como funcionalidades específicas e 
independentes.
○ A comunicação é feita por meio de uma interface, com 
independência de linguagem ou plataforma.
■ Barramento de serviços corporativos.
■ Do inglês, Enterprise Service Bus (ESB).
Arquitetura Orientada a Serviços (SOA)
Fonte: Própria
ENTERPRISE 
SERVICE 
BUS 
(ESB)
Aplicação
Web
Aplicação
Mobile
Aplicação
Desktop
Serviço A
Serviço B
BANCO DE 
DADOS
Arquitetura baseada em Microsserviços
● Variante da Arquitetura Orientada a Serviços.
○ Antagonista aos monólitos.
○ Serviços menores e independentes.
■ Linguagens e plataformas distintas.
● São aplicações distribuídas, compostas por diversas aplicações 
menores para criar sistemas complexos.
○ Facilitam a escalabilidade e a mobilidade da aplicação.
○ Custos, complexidade de implementação e manutenção altos.
Arquitetura baseada em Microsserviços
Fonte: Própria
Aplicação
Aplicação
Aplicação
MS
BANCO DE DADOS
MS
MS
Arquitetura Monolítica
● Bloco único que agrega com todos os componentes, 
funcionalidades e estruturas implementadas em conjunto.
○ Todas as funcionalidades podem rodar em um único processo.
○ Alto acoplamento entre as partes do software.
● Adoção depende do escopo e da proposta do projeto.
Arquitetura Monolítica
● Vantagens
○ Rápido desenvolvimento.
○ Gerenciamento de produção.
○ Menor complexidade deimplementação.
● Desvantagens
○ Ponto de falha.
○ Baseado em única tecnologia.
○ Pouca flexibilidade para escalabilidade.
Arquitetura Monolítica
Fonte: Própria
Interface do Usuário
Lógica de Negócio
SGBD BANCO DE DADOS
Finalizando
● Arquiteturas representam soluções distintas para diferentes 
desafios.
○ A escolha deve ser orientada pelas características do projeto.
○ Decisão estratégica - baseia-se nos requisitos do negócio.
● Resposta a um cenário em constante evolução.
○ Importantes para o sucesso a longo prazo.
ALURA. Padrões arquiteturais: arquitetura de software descomplicada. Disponível em: 
https://link.ufms.br/J1AbV . Acesso em junho de 2025.
ERL, Thomas. SOA: princípios de design de serviços. 1. ed. São Paulo, SP: Pearson, 2009. Recurso on-line. 
ISBN 9788576051893. Capítulo 3. Disponível na Biblioteca Digital da UFMS.
MARINHO, Antonio Lopes; CRUZ, Jorge Luiz da (org.) Desenvolvimento de aplicações para internet. 2. ed. São 
Paulo: Pearson, 2020. Recurso on-line. (Bibliografia Universitária Pearson). ISBN 9786550110604. Capítulo 2. 
Disponível na Biblioteca Digital da UFMS.
PRESSMAN, Roger S; MAXIM, Bruce R. Engenharia de software. 9. ed. Porto Alegre: Bookman, 2021. 1 recurso 
online 206 p. ISBN 9786558040118. Capítulo 10. Disponível na Biblioteca Digital da UFMS.
Referências
https://link.ufms.br/J1AbV
https://pergamum.ufms.br/
https://pergamum.ufms.br/
https://pergamum.ufms.br/
Licenciamento
Respeitadas as formas de citação formal de autores de acordo com as normas 
da ABNT NBR 6023 (2018), a não ser que esteja indicado de outra forma, todo 
material desta apresentação está licenciado sob uma Licença Creative Commons 
- Atribuição 4.0 Internacional. 
https://creativecommons.org/licenses/by/4.0/
https://creativecommons.org/licenses/by/4.0/