Introdução aos Sistemas Web

1. O que é a Web?

Antes de escrever uma linha de código, precisamos entender o sistema que vamos construir. A World Wide Web (Web) não é sinônimo de Internet — ela é uma aplicação que roda sobre a Internet. A Internet é a infraestrutura física e de protocolos (cabos, roteadores, TCP/IP). A Web é um conjunto de padrões — HTTP, HTML, URLs — que permite que máquinas em qualquer lugar do planeta troquem documentos e dados de forma padronizada.

Tim Berners-Lee criou a Web em 1989 no CERN para resolver um problema simples: físicos precisavam compartilhar documentos entre computadores incompatíveis. A solução foi um protocolo de texto (HTTP) sobre uma rede existente (TCP/IP) com documentos conectados por links (HTML). Essa combinação — simples por design — tornou-se a maior plataforma de software da história.

Hoje, quando falamos em "construir um sistema web", não falamos apenas de sites. Falamos de sistemas que usam HTTP para trocar dados entre um cliente (navegador, aplicativo móvel, outro servidor) e um servidor — independente de ter ou não uma interface visual. Uma API que retorna JSON puro é um sistema web tão legítimo quanto uma plataforma de e-commerce com milhões de páginas.

Por que isso importa para engenheiros?

Porque a arquitetura que escolhemos — e as decisões que tomamos — são moldadas pelas restrições e garantias do protocolo HTTP. HTTP é stateless (sem estado): cada requisição é independente, o servidor não "lembra" de requisições anteriores a não ser que você persista essa informação explicitamente. Essa característica força certas decisões de design — cookies, tokens de sessão, JWTs — que aparecem diretamente no código que você vai escrever.

2. Arquitetura Cliente-Servidor

A arquitetura cliente-servidor é o padrão dominante em sistemas web. Ela divide as responsabilidades em dois papéis fundamentais: o cliente, que faz requisições, e o servidor, que responde a elas. Essa separação não é apenas organizacional — ela tem implicações diretas em escalabilidade, segurança, manutenção e custo.

Clique no diagrama ou role a página para ver a animação

O papel de cada camada

Cada camada tem uma responsabilidade bem definida. Misturar essas responsabilidades — colocar lógica de banco no HTML, ou validação de negócio no SQL — é o início do código espaguete que torna sistemas difíceis de manter.

Escalando além do básico: arquiteturas de múltiplas camadas

O modelo acima é a forma mais simples. Em sistemas reais, essas camadas se multiplicam. Um servidor pode chamar outro servidor (microsserviços). Pode haver um load balancer na frente de múltiplas instâncias do servidor. O banco pode ser lido a partir de uma réplica de leitura. Existe um CDN (Content Delivery Network) que armazena assets estáticos próximo do usuário.

Para esta disciplina, o modelo de três camadas é suficiente — mas saber que ele pode crescer é importante para que suas decisões hoje não criem barreiras para o futuro. Isso é o que a visão Engineering do RM-ODP (que veremos adiante) tenta capturar.

3. O Protocolo HTTP

HTTP — HyperText Transfer Protocol — é o protocolo de comunicação da Web. Foi criado por Tim Berners-Lee em 1991 na versão 0.9 (só GET, só HTML). Hoje, na versão HTTP/3, suporta multiplexação de requisições, compressão de headers e transporte sobre UDP (QUIC). Para sistemas web comuns, a versão que você mais verá é HTTP/1.1 e HTTP/2.

O modelo fundamental é simples: o cliente envia uma requisição e o servidor responde com uma resposta. Ambas têm a mesma estrutura: uma linha de início, headers (cabeçalhos), uma linha em branco e opcionalmente um corpo.

Anatomia de uma requisição HTTP

POST /api/usuarios HTTP/1.1
Host:           api.exemplo.com
Content-Type:   application/json
Authorization:  Bearer eyJhbGciOiJIUzI1NiJ9...
Accept:         application/json

{
  "nome":  "Ana Lima",
  "email": "ana@inteli.edu.br",
  "senha": "minhaSenhaSegura123"
}

Anatomia de uma resposta HTTP

HTTP/1.1 201 Created
Content-Type:   application/json; charset=utf-8
Location:       /api/usuarios/42
X-Request-Id:   a1b2c3d4

{
  "id":        42,
  "nome":      "Ana Lima",
  "email":     "ana@inteli.edu.br",
  "criado_em": "2026-04-03T10:30:00Z"
}

Observe os headers: eles carregam metadados sobre a requisição/resposta sem poluir o corpo. Content-Type diz ao receptor como interpretar o corpo. Authorization carrega as credenciais. Location na resposta indica onde o recurso recém-criado pode ser encontrado — isso é parte do padrão REST.

4. Métodos HTTP

Os métodos HTTP — também chamados de verbos — definem a intenção da operação. Não é apenas convenção: o protocolo define propriedades matemáticas formais para cada método que guiam implementações de caches, proxies e clientes.

Idempotência significa que múltiplas requisições idênticas produzem o mesmo resultado que uma única. GET, PUT, DELETE e PATCH (quando bem implementado) são idempotentes. POST não é: chamar POST /pedidos duas vezes cria dois pedidos.

↑ Clique em qualquer card para expandir os detalhes.

5. Status Codes

Os status codes são números de 3 dígitos que o servidor inclui na resposta para indicar o resultado da operação. Eles são organizados em 5 famílias pelo primeiro dígito. Usar o status correto não é detalhe cosmético — é o que permite que clientes, proxies e ferramentas de monitoramento interpretem o resultado sem precisar ler o corpo da resposta.

6. JSON — A Língua Franca da Web

JSON (JavaScript Object Notation) tornou-se o formato de troca de dados dominante em APIs web. Não porque seja o mais eficiente (protobuf e MessagePack são mais compactos), mas porque é legível por humanos, suportado nativamente em JavaScript e suficientemente simples para ser implementado em qualquer linguagem com poucas linhas de código.

JSON tem exatamente 6 tipos de valor: string, number, boolean, null, array e object. Essa simplicidade é proposital — ela reduz ambiguidades e facilita a interoperabilidade entre sistemas escritos em linguagens diferentes.

{
  "id": 1042,
  "cliente": {
    "id": 7,
    "nome": "Ana Lima",
    "email": "ana@exemplo.com"
  },
  "itens": [
    {
      "produto": "Notebook",
      "quantidade": 1,
      "preco_unit": 2499.90
    },
    {
      "produto": "Mouse",
      "quantidade": 2,
      "preco_unit": 89.90
    }
  ],
  "total": 2679.70,
  "status": "aprovado",
  "criado_em": "2026-04-03T14:22:00Z",
  "enviado": false
}

// number — inteiro positivo (ID gerado pelo banco)
"id": 1042

// object aninhado — recurso relacionado
"cliente": { ... }

// array de objects — coleção de itens
"itens": [ {...}, {...} ]

// number — ponto flutuante (use string para
// dinheiro em sistemas financeiros críticos)
"preco_unit": 2499.90

// string — enum de texto (melhor que 0/1/2)
"status": "aprovado"

// string — datas em ISO 8601 (UTC)
"criado_em": "2026-04-03T14:22:00Z"

// boolean — true ou false, sem aspas
"enviado": false

Parseando JSON em JavaScript

// Aula 8 vai aprofundar isso — por ora, o padrão fundamental:

const resposta = await fetch('/api/pedidos/1042');

if (!resposta.ok) {
  // resposta.ok é true para status 200-299
  throw new Error(`Erro HTTP: ${resposta.status}`);
}

const pedido = await resposta.json(); // parse automático

console.log(pedido.cliente.nome); // "Ana Lima"
console.log(pedido.total);        // 2679.70
console.log(pedido.itens.length); // 2

7. Nossa Stack

A stack é o conjunto de tecnologias que compõe o sistema. Nesta disciplina, usamos uma stack JavaScript de ponta a ponta — tanto no front quanto no back-end — com PostgreSQL como banco relacional. Essa escolha não é por exclusão das alternativas, mas por coerência pedagógica: você aprende uma linguagem profundamente antes de comparar com outras.

8. RF, RN e RNF — Classificando Requisitos

Um dos maiores erros em projetos de software é começar a codificar sem saber ao certo o que o sistema precisa fazer e como precisa operar. Os requisitos são a tradução do problema de negócio em especificações verificáveis. Aprender a distingui-los é fundamental para o trabalho de engenharia.

Requisito Funcional (RF)

Descreve o que o sistema faz — comportamentos observáveis, funcionalidades, ações que o usuário pode realizar. É verificável por testes funcionais: ou o sistema faz, ou não faz.

Regra de Negócio (RN)

Define restrições e condições que governam o comportamento do sistema. Regras de negócio são geralmente derivadas de requisitos legais, contratuais ou de domínio — e mudam com mais frequência que o código. Separar RN de RF permite que mudanças de negócio sejam localizadas sem reescrever a aplicação inteira.

Requisito Não Funcional (RNF)

Descreve como o sistema opera — qualidade, desempenho, segurança, usabilidade. São os atributos que diferenciam um sistema que "funciona" de um sistema que "funciona bem". O erro mais frequente de iniciantes é expressar RNF como opinião vaga.

Um RNF de engenharia precisa responder 6 perguntas: qual eixo de qualidade? qual operação é observada? qual carga ou condição de uso? qual métrica? qual limiar aceitável? como é evidenciado?

No eixo [qualidade], o sistema deve [comportamento observável]
sob [condição/carga], medido por [métrica],
com limite [valor], validado por [teste/ferramenta].

-- Exemplo preenchido:
"No eixo eficiência de desempenho, o endpoint POST /pedidos
 deve responder com p99 abaixo de 500ms sob 50 requisições
 simultâneas em ambiente de staging, medido por k6,
 validado na pipeline de CI após cada deploy."

Como RF, RN e RNF se relacionam

9. Os 8 Eixos de RNF (ISO/IEC 25010)

Nesta disciplina, usamos uma decomposição de qualidade em 8 eixos, baseada na norma ISO/IEC 25010 (SQuaRE — Systems and Software Quality Requirements and Evaluation). Essa norma é a referência internacional para qualidade de software e aparece no SWEBOK v4, o corpo de conhecimento oficial da engenharia de software. Ela evoluiu da ISO/IEC 9126 (1991) e expande o escopo para considerar não só o produto, mas o sistema operando em seu contexto real.

Os eixos não são silos independentes: eles se cruzam, se reforçam e frequentemente conflitam entre si. Uma decisão arquitetural que melhora um eixo pode piorar outro — e reconhecer isso é o que separa o engenheiro que escreve requisitos do que apenas lista desejos. Ao documentar RNF do seu projeto, você deve sempre explicitar em qual eixo está trabalhando, qual métrica será medida e qual limite é aceitável.

Métricas e ferramentas típicas por eixo

Para cada eixo, existem métricas reconhecidas e ferramentas que geram evidência objetiva. Essa tabela é seu ponto de partida — memorize a relação entre eixo, métrica e ferramenta, porque é isso que torna um RNF auditável.

9.1 Trade-offs entre Eixos — quando qualidade é escolha

Nenhum sistema maximiza todos os 8 eixos simultaneamente. Cada decisão arquitetural troca um eixo por outro, e reconhecer essas tensões é o que separa o projeto viável do projeto utópico. Abaixo, as tensões mais frequentes em sistemas web — e como elas se manifestam no seu código.

9.2 Redigindo RNF Mensuráveis — o esqueleto SMART-E

Um RNF mal redigido é pior que um RNF ausente: ele cria a ilusão de que o atributo foi tratado, quando na verdade não há como verificar. Use o esqueleto SMART-E — Specific, Measurable, Achievable, Relevant, Time-bound + Evidence — adaptado para requisitos de qualidade.

[1] EIXO         → Qual dos 8 eixos de qualidade é o alvo?
[2] ESPECIFICAÇÃO→ Qual operação / componente / fluxo está sendo qualificado?
[3] CONDIÇÃO     → Sob qual carga, ambiente ou cenário?
[4] MÉTRICA      → O que é medido? (latência, taxa, tempo, volume)
[5] LIMIAR       → Qual valor numérico define passa/falha?
[6] EVIDÊNCIA    → Qual ferramenta ou teste gera a prova?
[7] PRAZO        → Quando o limite passa a valer? (sprint atual, release X)

─── Exemplo aplicado ───
"No eixo DESEMPENHO [1], o endpoint POST /pedidos [2]
 sob 50 req/s concorrentes em staging [3] deve ter
 latência p95 [4] abaixo de 500 ms [5], validada por
 teste k6 na pipeline de CI [6], a partir da Sprint 3 [7]."

Da frase vaga ao RNF auditável — três exemplos

9.3 Priorização de Eixos por Tipo de Sistema

Nem todo sistema precisa ser ótimo em todos os 8 eixos. A priorização depende do contexto — tipo de negócio, volume de usuários, maturidade da equipe, regulação. A tabela abaixo sugere eixos críticos (onde falha é inaceitável) e importantes (onde se deve investir) em perfis comuns de sistema web.

10. Minimundo — Descrevendo o Domínio

Antes de modelar entidades, desenhar telas ou escrever código, você precisa entender o problema. O minimundo é uma descrição textual do domínio em linguagem natural — sem jargão técnico, sem menção a tecnologias. Ele captura quem são os atores, o que fazem, quais informações manipulam e o que está fora do escopo.

Um bom minimundo é escrito da perspectiva do negócio, não do software. "O sistema tem uma tabela de usuários" não é minimundo — é já uma decisão de implementação. "Atendentes precisam registrar pedidos dos clientes" é minimundo.

Exemplo de minimundo completo

Do minimundo às entidades

Substantivos no minimundo tendem a virar entidades (tabelas). Verbos tendem a virar relacionamentos ou operações. Adjetivos e dados associados tendem a virar atributos.

11. Casos de Uso — a Narrativa de cada Requisito

Quando você escreve um requisito funcional como "o atendente registra um pedido", a frase resume um objetivo. Um caso de uso (use case, UC) é o filme desse objetivo: um roteiro passo a passo que descreve como o ator interage com o sistema para atingir o resultado — incluindo o que dá errado, quais exceções tratar e em que estado o sistema termina.

Use cases preenchem uma lacuna importante na documentação. Os RFs dizem o que o sistema faz. As RNs dizem quais regras governam. Os RNFs dizem como o sistema opera. Mas nenhum deles explica, em linguagem comum, a sequência de passos que precisa existir no código. É aí que os UCs entram.

11.1 Anatomia de um Use Case — os 7 campos obrigatórios

Um UC bem formado segue um template estável. Qualquer pessoa do time — PM, dev, QA, ops — deve conseguir ler e extrair a informação de que precisa sem ter que decifrar estilo pessoal. Os 7 campos abaixo são obrigatórios. Campos adicionais (frequência, restrições de tempo, atores envolvidos, referências) são opcionais e entram caso o domínio exija.

11.2 Diagrama de Use Cases — a visão panorâmica

Antes de escrever cada UC em detalhe, um diagrama UML serve como mapa: quem são os atores, quais UCs existem, que relações há entre eles. Não é um diagrama técnico — é um acordo visual entre quem define o produto e quem o constrói. O diagrama da Loja Universitária abaixo mostra os elementos básicos que você vai usar.

11.3 «include» vs «extend» — os dois tipos de reuso

No diagrama acima você viu uma seta tracejada com rótulo «include» ligando UC-01 e UC-05. UML define dois tipos de relação entre UCs — «include» e «extend» — e confundi-los é um dos erros mais comuns em diagramas mal escritos. A diferença é simples quando você pensa em termos de obrigatoriedade.

11.4 Exemplo Completo — UC-01 Registrar Pedido

Aplicando o template da anatomia ao minimundo da Loja Universitária, o UC-01 fica como abaixo. Note como cada passo do fluxo principal é imperativo, como os desvios estão numerados e como a rastreabilidade aos RFs/RNs/RNFs aparece explicitamente no último bloco.

12. RM-ODP — As 5 Visões do Sistema

O RM-ODP (Reference Model for Open Distributed Processing) foi padronizado conjuntamente pela ISO/IEC 10746 e pelo ITU-T X.901–X.904 no final dos anos 1990. Surgiu de uma necessidade concreta: nos anos 80–90, sistemas distribuídos estavam se multiplicando (CORBA, DCE, cliente-servidor corporativo), e cada fornecedor documentava seus sistemas de uma forma diferente. O RM-ODP propôs uma linguagem comum — 5 visões padronizadas — para descrever qualquer sistema distribuído de forma consistente.

Por que isso importa em IN02? Porque sistemas web são, por definição, sistemas distribuídos: cliente, servidor e banco rodam em processos separados, frequentemente em máquinas diferentes, e a aplicação só funciona quando as partes se comunicam corretamente. Descrever esse sistema a partir de uma única perspectiva (só o código, só o banco, só a interface) é incompleto — gera projetos com bugs arquiteturais que só aparecem em produção.

Ao longo do módulo, você vai revisitar essas visões a cada aula. O objetivo não é preencher formulários burocráticos — é desenvolver o hábito de pensar o sistema a partir de múltiplas perspectivas antes de escrever código.

O que cada visão produz — perguntas, artefatos e stakeholders

Cada viewpoint responde a um conjunto característico de perguntas e produz artefatos que são consumidos por um público específico. A tabela abaixo amarra tudo: pergunta central, artefato típico de sprint, stakeholders que validam e conexão com os eixos de RNF.

12.1 RM-ODP Aplicado — Loja Universitária nas 5 Visões

Vamos aplicar as 5 visões ao minimundo da Loja Universitária da seção 10. O objetivo é mostrar que cada visão produz um artefato diferente do mesmo sistema, e que a coerência entre elas é o que permite começar a implementar com confiança.

12.2 Comparação com Outros Frameworks de Arquitetura

RM-ODP não é o único framework que propõe múltiplas visões de um sistema. Conhecer os vizinhos ajuda a entender o que é específico do RM-ODP e quando outro framework pode ser mais adequado ao contexto.

13. Convergência RNF ↔ RM-ODP — A Matriz de Qualidade

RNF e RM-ODP parecem dois tópicos separados, mas se cruzam em todo projeto real. Cada eixo de RNF vive em uma ou mais visões do RM-ODP — e saber onde cada um vive é o que permite que o requisito seja implementável e não apenas declarado. Esta seção sistematiza essa ponte.

Onde cada eixo de RNF se manifesta nas 5 visões

Do minimundo ao artefato de sprint — fluxo unificado

1. Minimundo → define escopo e atores (visão Enterprise).
2. RF priorizados → derivados do minimundo, descrevem funcionalidades observáveis.
3. RN numeradas → invariantes e restrições, vivem em Information.
4. RNF por eixo → distribuídos nas 5 visões conforme a matriz acima.
5. Matriz de rastreabilidade → cada RF aponta para ≥1 RN e ≥1 critério de aceite técnico.
6. Artefato de entrega → o conjunto coerente: minimundo + RF + RN + RNF + matriz, com evidência de teste.

14. Checklist de Estudo

Clique nos itens à medida que você dominar cada conceito:

• ✓
  Consigo explicar a diferença entre Internet e Web, e o que é um sistema web.
• ✓
  Consigo descrever o papel de cliente, servidor, banco e rede em uma arquitetura web.
• ✓
  Consigo desenhar o fluxo completo de uma requisição HTTP do usuário à resposta.
• ✓
  Consigo diferenciar GET, POST, PUT, PATCH e DELETE e saber quando usar cada um.
• ✓
  Consigo classificar status codes em 2xx, 3xx, 4xx e 5xx e citar exemplos de cada.
• ✓
  Consigo ler e escrever JSON com os 6 tipos de valor, incluindo objetos aninhados e arrays.
• ✓
  Consigo distinguir RF, RN e RNF e dar exemplos de cada um para um sistema real.
• ✓
  Consigo transformar "o sistema é rápido" em um RNF com eixo, métrica, carga e evidência.
• ✓
  Consigo nomear e descrever os 8 eixos de RNF usados na disciplina.
• ✓
  Consigo citar pelo menos 3 trade-offs clássicos entre eixos (ex: SEG × DES) e explicar em que ponto eles aparecem no código.
• ✓
  Consigo aplicar o esqueleto SMART-E para escrever um RNF auditável com eixo, condição, métrica, limiar, evidência e prazo.
• ✓
  Consigo priorizar eixos de RNF de acordo com o tipo de sistema (e-commerce, banco, interno, pipeline de dados).
• ✓
  Consigo redigir um minimundo sem misturar problema e solução técnica.
• ✓
  Consigo identificar as 5 visões do RM-ODP, a pergunta central de cada uma e o artefato que produzem.
• ✓
  Consigo aplicar as 5 visões a um minimundo concreto e verificar coerência cruzando informações entre elas.
• ✓
  Consigo comparar RM-ODP com 4+1, TOGAF e C4 e explicar quando usar cada um.
• ✓
  Consigo preencher a matriz de convergência RNF × RM-ODP para um projeto concreto e identificar lacunas.

Referências

• MDN Web Docs — Overview of HTTP — documentação de referência do protocolo HTTP
• RFC 9110 — HTTP Semantics — especificação oficial dos métodos e status codes
• SWEBOK v4 — Software Engineering Body of Knowledge
• ISO/IEC 25010 — SQuaRE Quality Model
• ISO/IEC 10746 — RM-ODP
• json.org — JSON specification
• Node.js — The Event Loop