FACULDADE DE TECNOLOGIA DE ASSIS - FATEC ASSIS

CURSO SUPERIOR DE TECNOLOGIA EM GESTÃO DA TECNOLOGIA DA INFORMAÇÃO

PROJETO INTEGRADOR: DELIVERYEXPRESS

Plataforma Multi-Acesso de Gestão de Pedidos e Roteamento Logístico

Assis
2026

AUTORES DO PROJETO

PROJETO INTEGRADOR: DELIVERYEXPRESS

Plataforma Multi-Acesso de Gestão de Pedidos e Roteamento Logístico

Documentação técnica do Projeto Integrador apresentada à Faculdade de Tecnologia de Assis (FATEC), como parte dos requisitos para avaliação nas disciplinas de Engenharia de Software e Banco de Dados do curso de Gestão da Tecnologia da Informação (GTI).

Assis
2026

Sumário

1. Introdução
2. Fundamentação Teórica
   • 2.1. A Complexidade Logística e o Desafio da Intermediação Multi-Acesso
   • 2.2. Geolocalização, Trilateração e APIs de Mapeamento
   • 2.3. Arquitetura de Sistemas Híbridos e Padrão MVC em Tempo Real
   • 2.4. Persistência em Alta Disponibilidade com MySQL
3. Engenharia de Software
   • 3.1. Requisitos Funcionais (RF)
   • 3.2. Requisitos Não Funcionais (RNF)
   • 3.3. Orientação a Objetos na Arquitetura do Sistema
   • 3.4. Caso de Uso Principal (UC-01)
4. Banco de Dados (MySQL)
   • 4.1. Modelagem e Script DDL
   • 4.2. Consultas Complexas e Relatórios Analíticos (DML)
5. Gestão, Segurança e LGPD
   • 5.1. Backlog e Histórias de Usuário (Padrão INVEST)
   • 5.2. Conformidade com a LGPD e Privacy by Design
   • 5.3. Cronograma do Projeto
6. Diagramas de Visualização
   • 6.1. Diagrama de Casos de Uso
   • 6.2. Diagrama de Classes
   • 6.3. Diagrama de Entidade-Relacionamento (DER)

1. Introdução

O setor de alimentação e entregas (food delivery) vivenciou um crescimento exponencial, exigindo que estabelecimentos gastronômicos adotassem a transformação digital para se manterem competitivos. No entanto, a dependência excessiva de canais informais (como aplicativos de mensagens instantâneas) resulta em gargalos operacionais: perda de pedidos, erros na transcrição de endereços e ausência de feedback sobre o tempo estimado de entrega (ETA).

O Projeto Integrador DeliveryExpress, desenvolvido no escopo do curso de Gestão da Tecnologia da Informação (GTI) da FATEC Assis (2026), emerge como uma solução corporativa para orquestrar a tríade do ecossistema de delivery: Cliente, Restaurante e Entregador. Este projeto consolida as disciplinas de Engenharia de Software e Banco de Dados, propondo uma arquitetura de software escalável, fundamentada em orientação a objetos, design patterns e um banco de dados relacional (MySQL) projetado para suportar transações críticas com máxima integridade.

A documentação a seguir expõe, com denso rigor acadêmico, as justificativas técnicas, as modelagens de caso de uso, as estratégias de conformidade com a LGPD e os scripts de implementação do sistema.

2. Fundamentação Teórica

2.1. A Complexidade Logística e o Desafio da Intermediação Multi-Acesso

O gerenciamento de plataformas de delivery envolve a resolução de problemas assíncronos. Diferente de um sistema de vendas tradicional, onde a compra e a entrega de um produto digital ocorrem instantaneamente, o delivery de bens perecíveis insere a variável do tempo físico e da infraestrutura viária. A arquitetura Multi-Acesso exige que a mesma infraestrutura de banco de dados sirva a três perfis distintos com latências imperceptíveis:

• O Cliente requer uma interface rica (Front-end) voltada para usabilidade, exibição de cardápios com imagens e fluxo de checkout ágil (conversão).
• O Restaurante necessita de um painel de retaguarda (Back-office) em tempo real, assemelhando-se a um KDS (Kitchen Display System), onde pedidos novos acionem alertas sonoros e visuais sem a necessidade de recarregar a página.
• O Entregador depende de um aplicativo móvel enxuto, altamente dependente da API de geolocalização e projetado para poupar a vida útil da bateria do dispositivo.

Esses requisitos divergentes demandam uma API RESTful centralizada que funcione como o único ponto de verdade (Single Source of Truth) para o negócio.

2.2. Geolocalização, Trilateração e APIs de Mapeamento

Um dos diferenciais do DeliveryExpress é o cálculo de rotas e o acompanhamento de frota. O sistema fundamenta-se nos princípios de Sistemas de Informações Geográficas (GIS). Através da integração com APIs de mapas e roteamento, o sistema converte coordenadas de Latitude e Longitude dos entregadores para determinar o Estimated Time of Arrival (ETA).

No backend, são armazenados polígonos geográficos que definem as “Zonas de Entrega” dos restaurantes. A validação espacial é processada para impedir que um cliente solicite pedidos fora do raio de atuação do estabelecimento, o que reduz substancialmente cancelamentos operacionais e otimiza a frota.

2.3. Arquitetura de Sistemas Híbridos e Padrão MVC em Tempo Real

A sustentação lógica do projeto obedece ao padrão arquitetural MVC (Model-View-Controller).

• O Model não apenas mapeia tabelas, mas encapsula as regras de validação logísticas (ex: um pedido não pode transitar para “Entregue” se o status anterior não for “Saiu para Entrega”).
• A View varia conforme o ator (Mobile para o Entregador, Web responsiva para o Cliente, Dashboard Desktop para o Restaurante).
• O Controller gerencia a injeção de dependências e os protocolos HTTP/WebSocket, garantindo o envio de Push Notifications entre os vértices da operação sempre que o estado transacional do banco de dados for alterado.

2.4. Persistência em Alta Disponibilidade com MySQL

Para orquestrar milhares de transações simultâneas e lidar com picos de acesso (ex: horário de almoço ou jantar), o MySQL é utilizado com a engine InnoDB. Essa engine garante o cumprimento total das propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade). A aplicação utiliza Pessimistic Locking (bloqueio pessimista) quando um entregador aceita uma corrida: o registro daquele “Pedido em Transporte” é bloqueado transacionalmente, impedindo que outro entregador tente aceitar a mesma corrida nos mesmos milissegundos, evitando concorrência desleal e anomalias de banco de dados.

3. Engenharia de Software

A metodologia adotada para o levantamento e modelagem do DeliveryExpress focou-se em garantir que a arquitetura suportasse crescimento escalar e blindagem contra falhas sistêmicas.

3.1. Requisitos Funcionais (RF)

1. **RF-001

   Autenticação e Perfis Multi-Acesso:** O sistema deve suportar o registro e login com diferenciação estrita de perfis e permissões: Cliente (comprador), Restaurante (fornecedor) e Entregador (logística).

2. **RF-002

   Gestão de Cardápio e Estoque:** O sistema deve permitir que restaurantes cadastrem produtos, organizem por categorias (ex: Lanches, Bebidas) e alterem a disponibilidade temporária de itens.

3. **RF-003

   Carrinho e Checkout Parametrizado:** O usuário (Cliente) deve conseguir agrupar produtos, inserir cupons promocionais e concluir o pedido, escolhendo o endereço de entrega e a forma de pagamento (Dinheiro ou Pagamento Eletrônico).

4. **RF-004

   Acompanhamento Georreferenciado:** O sistema deve exibir para o cliente uma Timeline do status do pedido e, durante a fase de entrega, fornecer as atualizações do entregador.

5. **RF-005

   Aceite e Atribuição de Entregador:** O sistema deve listar pedidos pendentes de entrega em um painel (Dispatch) para os entregadores ativos aceitarem a corrida de forma concorrencial.

3.2. Requisitos Não Funcionais (RNF)

1. **RNF-001

   Segurança de Dados Sensíveis:** Todo armazenamento de senhas deve utilizar algoritmos de Hashing de alta entropia (como o Bcrypt). Adicionalmente, dados bancários ou de geolocalização não devem ser exibidos em logs em texto plano.

2. **RNF-002

   Disponibilidade e Tolerância a Falhas:** O sistema backend deve apresentar um uptime superior a 99%, utilizando estratégias de balanceamento de carga e reconexão automática ao banco de dados em caso de perda de pacote.

3. **RNF-003

   Desempenho (Latência de Requisição):** A pesquisa de restaurantes e o carregamento do cardápio devem retornar resultados à camada de visão em um tempo de resposta (RTT) não superior a 300 milissegundos sob carga normal.

3.3. Orientação a Objetos na Arquitetura do Sistema

A construção do código-fonte abraça os pilares da Programação Orientada a Objetos (POO), garantindo um ecossistema manutenível e extensível.

• Abstração: O conceito de Usuario atua como uma classe base abstrata que abstrai as propriedades comuns (ID, Nome, E-mail, SenhaHash, DataCadastro). As regras inerentes ao ecossistema de cada tipo de usuário ficam nas subclasses.
• Encapsulamento: Em entidades críticas como Pedido, os atributos status e valorTotal são estritamente privados (private). Nenhuma classe de visão ou controller pode sobrescrever o valor total arbitrariamente; ela deve invocar o método adicionarItem(Produto p, int qtd), que recalcula internamente o total com base no preço cadastrado do produto. Isso blinda o núcleo da aplicação contra ataques de adulteração de preços (parameter tampering).
• Polimorfismo: A interface IEstrategiaPagamento declara o método processarTransacao(). As classes derivadas PagamentoPix, PagamentoCartao e PagamentoEspecie sobrescrevem este método. Quando o controlador invoca a finalização do pedido, ele executa polimorficamente o pagamento, permitindo que a plataforma inclua novas bandeiras ou carteiras digitais no futuro sem modificar a lógica central do carrinho.

3.4. Caso de Uso Principal (UC-01)

Identificador: UC-01
Nome: Realizar Checkout de Pedido (Comprar)
Ator Principal: Cliente Autenticado
Pré-condição: O cliente deve possuir itens válidos no carrinho de compras e o restaurante selecionado deve estar com o status “Aberto”.

Fluxo Principal:

1. O Cliente clica em “Finalizar Pedido” na visualização do Carrinho.
2. O sistema exibe a tela de Checkout, recuperando o endereço padrão do perfil e listando os métodos de pagamento suportados pelo restaurante.
3. O Cliente confirma o Endereço de Entrega ou cadastra um novo.
4. O Cliente seleciona a Forma de Pagamento e clica em “Confirmar Compra”.
5. O sistema encapsula os dados da transação e despacha para a camada de serviço.
6. A lógica de negócios valida o subtotal e verifica a integridade de todos os itens em relação à tabela PRODUTO no MySQL.
7. O sistema executa os comandos DML INSERT INTO PEDIDO e múltiplos INSERT INTO ITEM_PEDIDO envoltos numa única transação (BEGIN TRAN … COMMIT).
8. O sistema notifica o painel web do Restaurante (via WebSocket) e exibe a tela de “Acompanhamento” ao Cliente.

Fluxo de Exceção (Restaurante Fechado no Ato): Se, entre o tempo de montagem do carrinho e o passo 5, o restaurante alterar seu expediente para “Fechado”, a camada de negócios intercepta a requisição, realiza o ROLLBACK da transação (para evitar cobranças) e alerta o cliente na interface: “Desculpe, o restaurante acaba de fechar e não pode receber novos pedidos.”

4. Banco de Dados (MySQL)

O coração do DeliveryExpress reside em um banco de dados relacional desenhado na 3ª Forma Normal (3FN), garantindo que dados estruturados não sofram anomalias de atualização e deleção.

4.1. Modelagem e Script DDL

O script de Data Definition Language evidencia o uso de integridade referencial estrita e o tratamento de dados de alta granularidade (como a separação de logradouros em chaves independentes).

-- Criação do Banco de Dados DeliveryExpress
CREATE DATABASE IF NOT EXISTS db_delivery_express
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

USE db_delivery_express;

-- Tabela Central de Usuários (Autenticação Unificada)
CREATE TABLE IF NOT EXISTS tbl_usuarios (
    id_usuario INT AUTO_INCREMENT PRIMARY KEY,
    tipo_usuario ENUM('CLIENTE', 'RESTAURANTE', 'ENTREGADOR', 'ADMIN') NOT NULL,
    nome_completo VARCHAR(150) NOT NULL,
    email VARCHAR(150) NOT NULL UNIQUE,
    senha_hash VARCHAR(255) NOT NULL COMMENT 'Armazenamento de Hashing Bcrypt',
    telefone VARCHAR(20),
    data_cadastro DATETIME DEFAULT CURRENT_TIMESTAMP,
    status_conta BOOLEAN DEFAULT TRUE
);

-- Tabela de Endereços (Permite múltiplos endereços por Cliente)
CREATE TABLE IF NOT EXISTS tbl_enderecos (
    id_endereco INT AUTO_INCREMENT PRIMARY KEY,
    id_usuario INT NOT NULL,
    cep VARCHAR(10) NOT NULL,
    logradouro VARCHAR(150) NOT NULL,
    numero VARCHAR(10) NOT NULL,
    complemento VARCHAR(100),
    bairro VARCHAR(100) NOT NULL,
    cidade VARCHAR(100) NOT NULL,
    latitude DECIMAL(10,8),
    longitude DECIMAL(11,8),
    FOREIGN KEY (id_usuario) REFERENCES tbl_usuarios(id_usuario) ON DELETE CASCADE
);

-- Tabela Específica de Restaurantes (Dados Cadastrais)
CREATE TABLE IF NOT EXISTS tbl_restaurantes (
    id_restaurante INT PRIMARY KEY,
    razao_social VARCHAR(150) NOT NULL,
    cnpj VARCHAR(18) NOT NULL UNIQUE,
    especialidade_gastronomica VARCHAR(50),
    taxa_entrega_base DECIMAL(10,2) DEFAULT 0.00,
    aberto_agora BOOLEAN DEFAULT FALSE,
    FOREIGN KEY (id_restaurante) REFERENCES tbl_usuarios(id_usuario) ON DELETE CASCADE
);

-- Catálogo de Produtos
CREATE TABLE IF NOT EXISTS tbl_produtos (
    id_produto INT AUTO_INCREMENT PRIMARY KEY,
    id_restaurante INT NOT NULL,
    nome_produto VARCHAR(150) NOT NULL,
    descricao_detalhada TEXT,
    preco_venda DECIMAL(10,2) NOT NULL,
    disponivel BOOLEAN DEFAULT TRUE,
    url_imagem VARCHAR(255),
    CONSTRAINT ck_preco_positivo CHECK (preco_venda >= 0),
    FOREIGN KEY (id_restaurante) REFERENCES tbl_restaurantes(id_restaurante) ON DELETE CASCADE
);

-- Tabela Transacional de Pedidos
CREATE TABLE IF NOT EXISTS tbl_pedidos (
    id_pedido BIGINT AUTO_INCREMENT PRIMARY KEY,
    id_cliente INT NOT NULL,
    id_restaurante INT NOT NULL,
    id_entregador INT NULL,
    id_endereco_entrega INT NOT NULL,
    valor_subtotal DECIMAL(10,2) NOT NULL,
    valor_taxa_entrega DECIMAL(10,2) NOT NULL,
    valor_total DECIMAL(10,2) NOT NULL,
    status_pedido ENUM('AGUARDANDO_CONFIRMACAO', 'PREPARANDO', 'PRONTO_PARA_COLETA', 'EM_ROTA', 'ENTREGUE', 'CANCELADO') DEFAULT 'AGUARDANDO_CONFIRMACAO',
    forma_pagamento ENUM('DINHEIRO', 'PIX', 'CARTAO_CREDITO', 'CARTAO_DEBITO') NOT NULL,
    data_hora_criacao DATETIME DEFAULT CURRENT_TIMESTAMP,
    data_hora_conclusao DATETIME NULL,
    FOREIGN KEY (id_cliente) REFERENCES tbl_usuarios(id_usuario) ON DELETE RESTRICT,
    FOREIGN KEY (id_restaurante) REFERENCES tbl_restaurantes(id_restaurante) ON DELETE RESTRICT,
    FOREIGN KEY (id_entregador) REFERENCES tbl_usuarios(id_usuario) ON DELETE SET NULL,
    FOREIGN KEY (id_endereco_entrega) REFERENCES tbl_enderecos(id_endereco) ON DELETE RESTRICT
);

-- Tabela N:M Resolvida (Itens do Pedido)
CREATE TABLE IF NOT EXISTS tbl_itens_pedido (
    id_item_pedido BIGINT AUTO_INCREMENT PRIMARY KEY,
    id_pedido BIGINT NOT NULL,
    id_produto INT NOT NULL,
    quantidade INT NOT NULL DEFAULT 1,
    preco_unitario_historico DECIMAL(10,2) NOT NULL COMMENT 'Congela o preço no ato da compra',
    FOREIGN KEY (id_pedido) REFERENCES tbl_pedidos(id_pedido) ON DELETE CASCADE,
    FOREIGN KEY (id_produto) REFERENCES tbl_produtos(id_produto) ON DELETE RESTRICT
);

4.2. Consultas Complexas e Relatórios Analíticos (DML)

Para fins de inteligência de negócios e auditoria de parceiros logísticos, elaborou-se uma instrução SQL avançada (Data Manipulation Language) que atua como o motor do relatório gerencial da diretoria. A query abaixo extrai a volumetria de vendas e o desempenho da frota de entregadores nos últimos 6 meses, agregando resultados cruciais para campanhas de marketing ou cortes de repasses financeiros.

-- Relatório Executivo: Desempenho Semestral de Entregadores e Ticket Médio
SELECT 
    U.nome_completo AS 'Nome_Entregador',
    COUNT(P.id_pedido) AS 'Total_Corridas_Concluidas',
    SUM(P.valor_taxa_entrega) AS 'Total_Repasse_Frete',
    AVG(P.valor_subtotal) AS 'Ticket_Medio_Transportado',
    MAX(P.data_hora_conclusao) AS 'Ultima_Corrida_Realizada',
    -- Calcula a média do tempo de entrega em minutos usando a diferença de timestamps
    ROUND(AVG(TIMESTAMPDIFF(MINUTE, P.data_hora_criacao, P.data_hora_conclusao)), 1) AS 'Tempo_Medio_Entrega_Minutos'
FROM 
    tbl_usuarios U
INNER JOIN 
    tbl_pedidos P ON U.id_usuario = P.id_entregador
WHERE 
    U.tipo_usuario = 'ENTREGADOR'
    AND P.status_pedido = 'ENTREGUE'
    AND P.data_hora_criacao >= DATE_SUB(CURRENT_DATE(), INTERVAL 6 MONTH)
GROUP BY 
    U.id_usuario, U.nome_completo
HAVING 
    COUNT(P.id_pedido) > 20 -- Isola amostras irrelevantes de entregadores esporádicos
ORDER BY 
    'Total_Corridas_Concluidas' DESC, 
    'Tempo_Medio_Entrega_Minutos' ASC;

Justificativa Técnica: O uso imperativo do INNER JOIN correlaciona o ator ao evento concluído. A instrução DATE_SUB dinamicamente amarra o período analítico, mitigando o uso de hardcoding de datas. A função TIMESTAMPDIFF aliada à agregação AVG extrai do banco dados valiosos sobre eficiência logística (SLA), enquanto a cláusula HAVING atua como pós-filtro estatístico.

5. Gestão, Segurança e LGPD

O DeliveryExpress foi idealizado seguindo as cerimónias do framework Scrum, priorizando as entregas por geração de valor de negócio e alinhamento normativo de privacidade.

5.1. Backlog e Histórias de Usuário (Padrão INVEST)

O mapeamento ágil do projeto fracionou as funcionalidades em histórias que atendem à heurística INVEST (Independente, Negociável, Valiosa, Estimável, Pequena e Testável).

História de Usuário 01 - Rastreamento por Geolocalização (GPS)

Como um Cliente que acabou de solicitar o jantar,
Eu quero visualizar num mapa o trajeto e a localização exata do entregador em tempo real,
Para que eu possa me preparar para a recepção e tenha segurança sobre o prazo de chegada.
Critérios de Aceite: O ícone do veículo deve ser atualizado na interface do cliente a cada 10 segundos utilizando WebSockets ou Polling; se a conexão GPS do entregador for perdida, o sistema deve exibir a última posição conhecida em coloração cinza.

História de Usuário 02 - Gestão de Aceite Concorrente

Como um Entregador Parceiro disponível na região,
Eu quero receber notificações de novos despachos e poder aceitá-los em um toque único na tela,
Para que eu possa otimizar minha rota de ganhos sem precisar navegar por menus complexos enquanto conduzo a moto.
Critérios de Aceite: O aplicativo mobile deve acionar a vibração e um sinal sonoro; a corrida deve sumir do painel geral (Dispatch) instantaneamente caso outro entregador clique em “Aceitar” milissegundos antes, evitando colisão de atribuições no banco de dados.

5.2. Conformidade com a LGPD e Privacy by Design

A plataforma DeliveryExpress lida com metadados sensíveis que englobam a vida privada do indivíduo, como endereços residenciais e hábitos de consumo alimentar. A arquitetura foi desenhada sobre a premissa de Privacy by Design (Art. 46, Lei nº 13.709/2018):

• Consentimento Explícito (Art. 8º): A coleta de informações de geolocalização deve, obrigatoriamente, ser precedida por um modal (Checkbox não pré-preenchido) com finalidade explícita de operação logística.
• Minimização e Temporalidade: O número de telefone e o endereço exato do cliente são mascarados na interface do Entregador. Tão logo o status do pedido transite para ENTREGUE, o aplicativo móvel do entregador perde acesso irrecuperável aos detalhes daquela corrida, obliterando riscos de assédio, perseguição (stalking) ou mau uso de dados de terceiros.
• Anonimização Protetiva: Caso o usuário acione seu Direito de Eliminação, os registros financeiros vinculados aos seus antigos pedidos têm a Foreign Key de Cliente substituída por um ID pseudo-anônimo de “Conta Excluída”, preservando a coerência contábil (DRE) da empresa sem reter a identidade civil do ex-cliente.

5.3. Cronograma do Projeto

A execução acadêmica e técnica foi parametrizada para um escopo intenso de 6 semanas, visando a homologação final na banca avaliadora da FATEC Assis.

Semana	Sprint e Entregáveis	Responsabilidade	Status
01	Engenharia de Requisitos (RF/RNF), Modelagem UML e Prototipagem UX	Arquiteto de Software	Concluído
02	Modelagem Física de Dados, Criação DDL/DML e Deploy de Infra (MySQL)	DBA Sênior	Concluído
03	Desenvolvimento Back-end (APIs RESTful, Autenticação, WebSockets)	Eng. de Backend	Concluído
04	Desenvolvimento Front-end (Portal do Restaurante e Checkout do Cliente)	Eng. Full-Stack	Concluído
05	Integração Mobile (Painel do Entregador, Geolocalização, Testes ACID)	Equipe de Testes (QA)	Em Andamento
06	Produção dos Relatórios Finais, Auditoria de Segurança e Banca FATEC	Toda a Equipe	Em Andamento

6. Diagramas de Visualização

A adoção da linguagem declarativa Mermaid permite incorporar a modelagem visual das entidades diretamente na infraestrutura de documentação como código (Docs-as-Code).

6.1. Diagrama de Casos de Uso

Mapeia a interação entre a tríade de atores logísticos e as fronteiras do subsistema de intermediação.

flowchart LR
    C(("Cliente"))
    R(("Restaurante"))
    E(("Entregador"))
    
    subgraph Sistema ["DeliveryExpress System"]
        direction TB
        UC1(["Visualizar Cardápio e Buscar"])
        UC2(["Montar Carrinho e Checkout"])
        UC3(["Acompanhar Status (ETA)"])
        UC4(["Gerenciar Menu e Categorias"])
        UC5(["Aceitar Pedido / Alterar Fluxo"])
        UC6(["Visualizar Painel de Corridas (Dispatch)"])
        UC7(["Aceitar Corrida de Entrega"])
        UC8(["Atualizar GPS em Tempo Real"])
    end
    
    C --> UC1
    C --> UC2
    C --> UC3
    
    R --> UC4
    R --> UC5
    
    E --> UC6
    E --> UC7
    E --> UC8
    
    UC3 -.->|<<observa atualizações de>>| UC5
    UC3 -.->|<<observa atualizações de>>| UC8

Versão em SVG (Diagrama de Casos de Uso):

6.2. Diagrama de Classes (Domínio Lógico)

A abstração da lógica de domínio central, evidenciando herança e associações estritas da orientação a objetos antes da persistência no banco.

classDiagram
    class Usuario {
        <<abstract>>
        #int idUsuario
        #String nomeCompleto
        #String email
        #String senhaHash
        +autenticar(credenciais): boolean
    }

    class Cliente {
        -List~Endereco~ enderecosSalvos
        +adicionarEndereco(end: Endereco): void
        +realizarPedido(p: Pedido): boolean
    }

    class Restaurante {
        -String razaoSocial
        -String cnpj
        -boolean abertoAgora
        +atualizarExpediente(aberto: boolean): void
    }

    class Entregador {
        -String veiculoPlaca
        -Coordenada ultimaPosicaoGps
        +aceitarCorrida(p: Pedido): boolean
        +atualizarPosicao(lat: float, lng: float): void
    }

    class Pedido {
        -long idPedido
        -List~ItemPedido~ itens
        -BigDecimal valorSubtotal
        -BigDecimal valorTotal
        -String status
        +adicionarItem(prod: Produto, qtd: int): void
        +calcularTotal(): BigDecimal
        +transitarStatus(novoStatus: String): void
    }

    Usuario <|-- Cliente
    Usuario <|-- Restaurante
    Usuario <|-- Entregador
    Cliente "1" --> "0..*" Pedido : origina
    Restaurante "1" --> "0..*" Pedido : atende
    Entregador "0..1" --> "0..*" Pedido : transporta

6.3. Diagrama de Entidade-Relacionamento (DER)

Este modelo lógico espelha fielmente o script DDL da seção 4.1, blindando o negócio por meio de chaves estrangeiras rígidas.

erDiagram
    TBL_USUARIOS {
        int id_usuario PK
        enum tipo_usuario "CLIENTE/RESTAURANTE/ENTREGADOR"
        string nome_completo
        string email UK
        string senha_hash "Bcrypt"
    }

    TBL_ENDERECOS {
        int id_endereco PK
        int id_usuario FK
        string cep
        string logradouro
        string bairro
    }

    TBL_RESTAURANTES {
        int id_restaurante PK "Referência id_usuario"
        string razao_social
        string cnpj UK
        decimal taxa_entrega_base
    }

    TBL_PRODUTOS {
        int id_produto PK
        int id_restaurante FK
        string nome_produto
        decimal preco_venda "CK: >= 0"
        boolean disponivel
    }

    TBL_PEDIDOS {
        bigint id_pedido PK
        int id_cliente FK
        int id_restaurante FK
        int id_entregador FK
        enum status_pedido
        decimal valor_total
        datetime data_hora_criacao
    }

    TBL_ITENS_PEDIDO {
        bigint id_item_pedido PK
        bigint id_pedido FK
        int id_produto FK
        int quantidade
        decimal preco_unitario_historico
    }

    TBL_USUARIOS ||--o{ TBL_ENDERECOS : "possui (1:N)"
    TBL_USUARIOS ||--o{ TBL_PEDIDOS : "solicita (1:N)"
    TBL_USUARIOS ||--o{ TBL_PEDIDOS : "entrega (1:N)"
    TBL_RESTAURANTES ||--o{ TBL_PRODUTOS : "anuncia (1:N)"
    TBL_RESTAURANTES ||--o{ TBL_PEDIDOS : "prepara (1:N)"
    TBL_PEDIDOS ||--|{ TBL_ITENS_PEDIDO : "engloba (1:N)"
    TBL_PRODUTOS ||--o{ TBL_ITENS_PEDIDO : "compõe (1:N)"

---

Fim da Documentação do Projeto Integrador FATEC Assis 2026. A extensa concepção deste artefato assegura não apenas a aplicabilidade prática no disputado mercado de aplicativos de entrega, mas certifica a fluência dos autores na tríade da engenharia moderna: modelagem de software, persistência relacional de alta concorrência e conformidade regulatória (LGPD).

⬅️ Anterior Próximo ➡️