Como a Internet funciona, cliente-servidor, HTTP e estrutura de aplicações modernas.
Separação de responsabilidades, camadas de uma aplicação e o papel de cada tecnologia.
Formato de dados JSON, ecosistema Node.js e primeiros passos com Express.
Ao final, o aluno deve compreender como uma requisição web percorre todas as camadas da aplicação.
Rede global de computadores conectados via cabos, fibra óptica e ondas de rádio. Criada como ARPANET em 1969, aberta ao público nos anos 90.
Sistema de documentos e aplicações interligados que rodam sobre a Internet. Inventado por Tim Berners-Lee em 1989. A Web é parte da Internet.
Programa acessível via URL no navegador. Combina interface visual com lógica de negócio em servidores remotos.
https://meuapp.com/usuariosAs 4 operações fundamentais de qualquer sistema (Create · Read · Update · Delete) mapeiam diretamente: POST → GET → PUT/PATCH → DELETE
100 Continue — cliente pergunta "posso mandar o payload grande?" antes de enviar. 101 Switching Protocols — handshake de WebSocket / HTTP/2 upgrade. Você raramente escreve código para 1xx — libs cuidam disso.
200 leitura / update bem-sucedido · 201 recurso criado (sempre com Location:) · 204 ação concluída sem corpo (delete, logout). Nunca retorne 200 com {"error":...} dentro — use 4xx/5xx apropriados.
301 Moved Permanently — browser atualiza bookmarks e caches para sempre · 302 Found — redirect temporário · 304 Not Modified — resposta sem corpo, economiza banda quando ETag ou Last-Modified batem com o cache local.
400 payload inválido (formato, tipo) · 401 não autenticado (sem token ou expirado) · 403 autenticado mas sem permissão · 404 recurso não existe. Sempre inclua mensagem de erro útil no corpo.
500 exceção não tratada no app · 502 proxy reverso não alcançou o upstream · 503 fora do ar / rate-limited (use Retry-After). Log estruturado + X-Request-ID + alerta automático = sobrevida em produção.
| Aspecto | 🖥️ Frontend | ⚙️ Backend |
|---|---|---|
| Onde roda | No navegador do usuário | No servidor (nuvem / on-prem) |
| Linguagens | HTML · CSS · JavaScript | Node.js · Python · Java · Go |
| Responsabilidade | Interface visual, UX, interatividade | Lógica de negócio, segurança, dados |
| Acesso a dados | ❌ Nunca acessa o banco diretamente | ✅ Acessa banco, arquivos, APIs externas |
| Comunicação | Chama APIs via fetch() |
Expõe endpoints REST ou GraphQL |
JavaScript Object Notation — formato leve para troca de dados. Legível por humanos e fácil de parsear por máquinas.
string — "texto entre aspas duplas"number — 42, 3.14 (sem aspas)boolean — true / falsearray — [1, 2, 3]object — {"chave": "valor"}null — ausência de valorReceber: JSON.parse(texto) → objeto JS
Enviar: JSON.stringify(obj) → texto JSON
Uma descrição narrativa de como um ator (pessoa ou sistema) interage com o software para alcançar um objetivo de negócio.
Não é tela, não é código — é o "filme" do que acontece passo a passo, incluindo o que dá errado.
Cada RF de alto nível vira um ou mais UCs detalhados.
Negócio e dev falam a mesma história — sem ambiguidade, sem jargão técnico desnecessário.
Fluxos alternativos capturam o que pode dar errado antes de virar bug em produção.
Cada fluxo vira um cenário de teste com entrada, passos e resultado esperado.
RN-* e RNF-* que o UC precisa respeitar.Comece com verbo + objeto. Evite "o usuário deseja". Use: "Informar CPF", "Selecionar item".
Um UC = um objetivo atômico. Se virou épico, quebre em UCs menores.
Não diga "clicar no botão azul". Diga "Confirmar envio". UI muda; intenção não.
include: reuso obrigatório (autenticar). extend: caminho opcional (aplicar cupom).
Papel externo que interage. Não é pessoa específica — é função.
Cada elipse = um caso de uso. Nome no formato verbo + objeto.
O retângulo tracejado delimita o que é escopo do sistema.
UC-01 sempre executa UC-05 (autenticar). Reuso mandatório.
UC-A sempre executa UC-B. Sem exceção.
"Para Registrar Pedido, o sistema sempre inclui Autenticar."
UC-B pode estender UC-A em condição específica.
"Se o cliente tem cupom válido, Aplicar Cupom estende Registrar Pedido."
| Aspecto | «include» — obrigatório | «extend» — opcional |
|---|---|---|
| Execução | Sempre que UC-A roda | Só se a condição valer |
| Direção da seta | UC base → UC incluído | UC extensão → UC base |
| O UC base sabe? | Sim — referencia UC-B no fluxo | Não — UC-A ignora UC-B |
| Exemplos reais | Autenticar · Validar CPF · Gerar log | Aplicar cupom · Alerta fraude · Upsell |
UC-01 · Nome: Registrar Pedido
role=atendente) · Produto(s) existente(s) no catálogo
status=PENDENTE e decrementa o estoque.id do pedido.503.status=PENDENTE · estoque reduzido · evento PEDIDO_CRIADO emitido.
409 sem gravarrole=atendente → 403"Identificar o problema, os usuários e o fluxo principal do sistema."
| Eixo | Requisito introdutório |
|---|---|
| 🎨 Usabilidade | Interface deve ser clara e intuitiva para o usuário final |
| ⚡ Desempenho | Respostas HTTP em menos de 2 segundos em condições normais |
| 🔒 Segurança | Comunicação via HTTPS; dados sensíveis nunca expostos no front |
| 🔄 Confiabilidade | Sistema deve tratar erros e exibir mensagens compreensíveis |
| 🔧 Suportabilidade | Código organizado, comentado e versionado desde o início |
| ID | Funcionalidade |
|---|---|
| RF-01 | Atendente registra pedido com ≥1 item |
| RF-02 | Sistema consulta estoque antes de confirmar |
| RF-03 | Gerente visualiza relatório diário de vendas |
| RF-04 | Atendente cancela pedido pendente |
| ID | Regra |
|---|---|
| RN-01 | Estoque nunca pode ficar negativo |
| RN-02 | Pedido só é cancelável em ≤ 1h da criação |
| RN-03 | E-mail do cliente é único na base |
| RN-04 | Preço unitário é congelado no momento da venda |
| Eixo | Requisito mensurável |
|---|---|
| ⚡ DES | POST /pedidos p95 < 500ms @ 50 req/s (k6) |
| 🔒 SEG | Rotas /admin exigem role=gerente (401/403) |
| 🔄 CONF | Uptime ≥ 99,5% mensal (UptimeRobot) |
| 📊 CAP | Suporta 100k pedidos/dia; índice (cliente_id, criado_em) |
Serve como comprovação da sprint — válida mesmo quando a presença no momento não for possível.
Estabelecem um ponto de partida. Podem ser refinados nas próximas sprints sem perder rastreabilidade.
Cada requisito funcional priorizado possui ao menos um critério técnico associado.
Numeradas e redigidas de forma a serem implementáveis e testáveis.
Relação explícita entre cada requisito funcional e as regras de negócio que o sustentam.
Permite seguir RF → RN sem lacunas nos fluxos priorizados.
Duas branches principais, sem develop:
Formato obrigatório:
Nada entra em main sem MR revisado.
feature/* → mainmain = bloqueado
"wip", "update", "arrumando", "ajustes". Sem tipo → sem merge.