Sumário

1. Introdução
2. Fundamentação Teórica
   • 2.1. O Problema do Processo Manual e Impacto Ambiental
   • 2.2. Tecnologia Sustentável e Redução de Desperdício
   • 2.3. Arquitetura Web em Java e Padrão MVC
   • 2.4. Persistência de Dados Relacional (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 Gerenciais (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 fora do lar (food service) tem enfrentado constantes desafios na modernização de seus processos internos. Muitos estabelecimentos, mesmo com alto volume de vendas, ainda dependem fortemente de comandas de papel e anotações manuais, resultando em gargalos de atendimento, falhas de comunicação entre salão e cozinha, e perdas financeiras. O Projeto Integrador Pedidos DoThi Sushi, desenvolvido como projeto acadêmico (2026), propõe uma solução arquitetônica robusta para digitalizar a gestão de comandas, empregando tecnologias consolidadas como Java e MySQL.

Além da otimização operacional, o projeto carrega um forte viés de Sustentabilidade. A eliminação da comanda física atua diretamente na redução do consumo de celulose e na diminuição do volume de lixo gerado pelo restaurante. Este documento consolida o escopo completo do projeto, desde os fundamentos teóricos até os diagramas de engenharia e scripts de banco de dados, atendendo a critérios de excelência acadêmica e alinhamento com metodologias ágeis de desenvolvimento.

2. Fundamentação Teórica

2.1. O Problema do Processo Manual e Impacto Ambiental

O uso de anotações em papel para registro de pedidos em restaurantes introduz diversas vulnerabilidades no fluxo de trabalho. A caligrafia ilegível de atendentes pode levar à preparação incorreta de pratos, gerando insatisfação no cliente e desperdício de insumos. Ademais, o trânsito físico da comanda entre a mesa, o caixa e a cozinha aumenta significativamente o lead time (tempo total do ciclo) do atendimento. Além das ineficiências operacionais, o uso intensivo de talões de pedidos representa um passivo ambiental. Restaurantes de médio porte podem descartar milhares de comandas de papel térmico (que frequentemente contém Bisfenol-A, dificultando sua reciclagem) mensalmente, contrariando os princípios ESG (Environmental, Social, and Governance).

2.2. Tecnologia Sustentável e Redução de Desperdício

A implementação do sistema DoThi Sushi substitui o meio físico pelo digital por meio de uma interface acessível (HTML5/CSS3) a partir de dispositivos móveis ou terminais touch-screen. Essa digitalização não apenas garante a Sustentabilidade através do conceito Paperless (Zero Papel), como também assegura que a informação trafegue de forma assíncrona e imediata para a área de preparo. A adoção de Tecnologia Verde na TI agrega valor à marca do estabelecimento e reduz os custos operacionais (OpEx) associados à compra recorrente de material de escritório.

2.3. Arquitetura Web em Java e Padrão MVC

Para garantir alta disponibilidade, segurança e escalabilidade, o back-end da aplicação foi arquitetado na linguagem Java. A robustez da Máquina Virtual Java (JVM) aliada ao gerenciamento automático de memória (Garbage Collector) proporciona uma estabilidade necessária para ambientes de missão crítica como o de restaurantes em horário de pico. A arquitetura de software fundamenta-se no padrão de projeto estrutural MVC (Model-View-Controller):

• Model: Representa os objetos de negócio (Pedido, Cliente, Prato) e encapsula as regras de validação.
• View: Componentes em HTML/CSS (com auxílio de frameworks front-end ou Servlets/JSP) que fornecem a interface de usabilidade para o atendente.
• Controller: Intercepta as requisições HTTP, coordena a interação entre a View e o Model, e delega o processamento lógico.

2.4. Persistência de Dados Relacional (MySQL)

A escolha do MySQL baseia-se na sua capacidade comprovada de gerenciar transações ACID (Atomicidade, Consistência, Isolamento, Durabilidade). Para um sistema financeiro e de pedidos, a garantia de que as informações (o que foi pedido, qual o valor, qual o status) não sejam corrompidas durante quedas de energia ou falhas de rede é imprescindível. O mapeamento objeto-relacional (ORM) converte as classes Java em tabelas estruturadas, permitindo consultas complexas para auditoria e tomada de decisão.

3. Engenharia de Software

3.1. Requisitos Funcionais (RF)

O escopo do sistema abrange os seguintes requisitos funcionais essenciais para a operação:

1. RF-001 | Identificação do Cliente e Pedido: O sistema deve permitir o registro de um novo pedido, associando-o ao nome/identificação do cliente (ou mesa) e os pratos/itens selecionados.
2. RF-002 | Gestão de Pagamentos: O sistema deve permitir a seleção e o registro da forma de pagamento (Dinheiro, Cartão, PIX) vinculada ao pedido.
3. RF-003 | Listagem e Visualização: O sistema deve exibir, em tempo real, uma listagem organizada de todos os pedidos ativos.
4. RF-004 | Exclusão/Cancelamento: O sistema deve permitir que usuários autorizados cancelem ou excluam um pedido, exigindo uma justificativa.
5. RF-005 | Gestão de Status (Workflow): O sistema deve fornecer botões de ação para alterar o fluxo de estado de um pedido (ex: Recebido → Em Preparo → Pronto → Entregue).

3.2. Requisitos Não Funcionais (RNF)

1. RNF-001 (Desempenho e Concorrência): O sistema deve processar a inserção de novos pedidos em menos de 1 segundo (tempo de resposta), permitindo acessos concorrentes de múltiplos garçons simultaneamente sem travamento de tabelas (deadlocks).
2. RNF-002 (Integridade Transacional): Todas as gravações no banco de dados devem ocorrer sob transações seguras, prevenindo que um pedido seja cobrado sem que os itens tenham sido devidamente salvos.
3. RNF-003 (Usabilidade): A interface web (HTML5/CSS3) deve possuir design responsivo e elementos visuais de alto contraste, garantindo que o fluxo de inserção de pedidos seja efetuado com no máximo 3 toques/cliques.

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

A engenharia estrutural do projeto explora profundamente os preceitos da Orientação a Objetos no Java:

• Abstração: O processo de negócio "Pedido" é abstraído em uma entidade PedidoDomain no Java. Aspectos irrelevantes para o software são ignorados, enquanto atributos cruciais (data, total, itens, status) são modelados em código. A persistência é isolada em classes do tipo DAO (Data Access Object) ou repositórios, ocultando o SQL da lógica de negócio.
• Encapsulamento: As variáveis de instância nas classes de entidade (ex: List<ItemPedido> itens, BigDecimal valorTotal) são estritamente private. Modificações nesses valores ocorrem apenas através de métodos controlados (ex: adicionarItem(Item item)), os quais recalculam automaticamente o total, protegendo o estado do objeto contra mutações indevidas.
• Polimorfismo: A aplicação do polimorfismo é visível na camada de pagamentos. Define-se uma interface PagamentoStrategy com o método processarPagamento(). Classes concretas como PagamentoPix, PagamentoCartao e PagamentoDinheiro implementam essa interface, permitindo que o sistema adicione novas formas de recebimento sem alterar o código do controlador principal (aplicação do Open/Closed Principle do SOLID).

3.4. Caso de Uso Principal (UC-01)

Identificador: UC-01
Nome: Registrar Novo Pedido e Comanda
Ator Principal: Atendente / Garçom (Usuário Logado)
Pré-condição: O Atendente deve estar autenticado e a conexão com o banco de dados ativa.

Fluxo Principal:

1. O Atendente seleciona a opção "Novo Pedido" na interface.
2. O sistema exibe o formulário de captura (Mesa/Cliente) e o catálogo de produtos (sushis, bebidas).
3. O Atendente seleciona os itens desejados e a quantidade.
4. O sistema calcula dinamicamente o subtotal e o valor total.
5. O Atendente seleciona a Forma de Pagamento e clica em "Confirmar Pedido".
6. O sistema valida os dados e envia as informações (via API/Controller) para a camada de serviço (Java).
7. O sistema executa as rotinas SQL (INSERT nas tabelas de Pedido e Itens do Pedido).
8. O sistema atualiza o Dashboard da Cozinha (alterando o status para Em Preparo).
9. O sistema exibe a mensagem de sucesso para o Atendente.

Fluxo de Exceção 1 (Falha na Persistência): Se, no passo 7, ocorrer uma exceção SQL (ex: banco offline ou falha de constraint), o sistema intercepta o erro no Java (SQLException), realiza o rollback da transação para evitar inconsistências e informa o Atendente: "Erro de Comunicação com o Servidor. O pedido não foi salvo. Tente novamente."

4. Banco de Dados (MySQL)

A arquitetura de dados relacional assegura a normalização e a consistência exigida por aplicações comerciais.

4.1. Modelagem e Script DDL

O Data Definition Language define o schema, tabelas e a integridade referencial essencial para não haver orfandade de dados (ex: Itens pertencentes a um Pedido inexistente).

-- Criação do Schema
CREATE DATABASE IF NOT EXISTS db_dothi_sushi
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

USE db_dothi_sushi;

-- Tabela de Produtos (Cardápio)
CREATE TABLE IF NOT EXISTS tbl_produtos (
    id_produto INT AUTO_INCREMENT PRIMARY KEY,
    nome_produto VARCHAR(100) NOT NULL,
    descricao_produto TEXT,
    preco_unitario DECIMAL(10,2) NOT NULL,
    categoria ENUM('ENTRADA', 'SUSHI', 'TEMAKI', 'BEBIDA', 'SOBREMESA') NOT NULL,
    disponivel BOOLEAN DEFAULT TRUE
);

-- Tabela de Clientes
CREATE TABLE IF NOT EXISTS tbl_clientes (
    id_cliente INT AUTO_INCREMENT PRIMARY KEY,
    nome_cliente VARCHAR(100) NOT NULL,
    telefone VARCHAR(15),
    data_cadastro DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- Tabela Central de Pedidos (Comanda Eletrônica)
CREATE TABLE IF NOT EXISTS tbl_pedidos (
    id_pedido INT AUTO_INCREMENT PRIMARY KEY,
    id_cliente INT NOT NULL,
    status_pedido ENUM('RECEBIDO', 'EM_PREPARO', 'PRONTO', 'ENTREGUE', 'CANCELADO') DEFAULT 'RECEBIDO',
    forma_pagamento ENUM('PIX', 'CARTAO_CREDITO', 'CARTAO_DEBITO', 'DINHEIRO') NOT NULL,
    valor_total DECIMAL(10,2) NOT NULL DEFAULT 0.00,
    data_pedido DATETIME DEFAULT CURRENT_TIMESTAMP,
    observacao VARCHAR(255),
    FOREIGN KEY (id_cliente) REFERENCES tbl_clientes(id_cliente) ON DELETE RESTRICT
);

-- Tabela de Itens do Pedido (Relacionamento N:M resolvido)
CREATE TABLE IF NOT EXISTS tbl_itens_pedido (
    id_item_pedido INT AUTO_INCREMENT PRIMARY KEY,
    id_pedido INT NOT NULL,
    id_produto INT NOT NULL,
    quantidade INT NOT NULL DEFAULT 1,
    preco_na_data DECIMAL(10,2) NOT NULL COMMENT 'Garante o histórico financeiro caso o produto mude de preço no futuro',
    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 Gerenciais (DML)

A tomada de decisão em um restaurante depende de análises de inteligência de negócios. A instrução DML abaixo consolida dados de múltiplos pontos (com INNER JOIN e GROUP BY) para formar um relatório de auditoria e desempenho dos últimos 6 meses, essencial para a gestão identificar os produtos mais rentáveis e o fluxo de caixa agregado.

-- Relatório Gerencial: Faturamento e Volume de Vendas nos últimos 6 Meses
SELECT 
    DATE_FORMAT(P.data_pedido, '%Y-%m') AS 'Mes_Referencia',
    PR.categoria AS 'Categoria_Produto',
    COUNT(DISTINCT P.id_pedido) AS 'Total_Pedidos_Executados',
    SUM(IP.quantidade) AS 'Itens_Vendidos',
    SUM(IP.quantidade * IP.preco_na_data) AS 'Receita_Bruta_Categoria'
FROM 
    tbl_pedidos P
INNER JOIN 
    tbl_itens_pedido IP ON P.id_pedido = IP.id_pedido
INNER JOIN 
    tbl_produtos PR ON IP.id_produto = PR.id_produto
WHERE 
    P.status_pedido IN ('ENTREGUE', 'PRONTO')
    AND P.data_pedido >= DATE_SUB(CURRENT_DATE(), INTERVAL 6 MONTH)
GROUP BY 
    DATE_FORMAT(P.data_pedido, '%Y-%m'), 
    PR.categoria
HAVING 
    SUM(IP.quantidade) > 20
ORDER BY 
    'Mes_Referencia' DESC, 
    'Receita_Bruta_Categoria' DESC;

Justificativa Técnica: O uso do DATE_FORMAT permite criar agregações cronológicas. A manutenção de um histórico imutável (através de preco_na_data) assegura que o relatório financeiro permaneça preciso independentemente de reajustes tarifários futuros no catálogo. A filtragem restringe os cálculos apenas a pedidos validados, excluindo cancelamentos.

5. Gestão, Segurança e LGPD

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

O gerenciamento do projeto segue metodologias ágeis, com requisitos traduzidos em Histórias de Usuário de alto valor.

História de Usuário 01 - Tela de Cozinha (KDS - Kitchen Display System)

Como um Sushiman (operador da cozinha),
Eu quero um painel que exiba automaticamente os novos pedidos sem a necessidade de atualizar a página,
Para que eu possa iniciar o preparo imediatamente, reduzindo o tempo de espera do cliente e evitando impressões em papel.
Critérios de Aceite: A tela deve buscar novos pedidos no banco a cada 10 segundos ou via WebSockets; os pedidos Recebidos devem ser exibidos em ordem cronológica (FIFO); deve haver um botão claro para marcar o pedido como Pronto.

História de Usuário 02 - Controle de Cancelamento

Como um Gerente de Salão,
Eu quero que o sistema bloqueie o cancelamento de pedidos que já estão "Em Preparo",
Para que o restaurante não sofra perdas com insumos já utilizados.
Critérios de Aceite: O botão de exclusão/cancelamento deve ficar desabilitado caso o status_pedido seja diferente de RECEBIDO; apenas um usuário com role de "Administrador" pode sobrepor essa regra registrando um motivo.

5.2. Conformidade com a LGPD e Privacy by Design

Sistemas comerciais lidam com informações identificáveis (PII) dos clientes, exigindo aderência à LGPD (Lei nº 13.709/2018):

• Transparência e Consentimento: Caso o sistema passe a integrar delivery, a coleta de telefones (como na tabela tbl_clientes) deve possuir finalidade declarada exclusivamente para comunicação operacional do pedido, evitando marketing sem opt-in.
• Retenção de Dados: O sistema deve incorporar rotinas de anonimização. Um cliente esporádico que solicite exclusão deve ter seus dados cadastrais (Nome/Telefone) convertidos em hash irreversível ou strings genéricas ("Cliente Anônimo"), enquanto o valor financeiro do pedido (tbl_pedidos) é mantido para fins de conformidade fiscal e contábil, resolvendo o conflito entre o Direito ao Esquecimento e obrigações tributárias.

5.3. Cronograma do Projeto

A estimativa para entrega de valor (MVP) engloba 6 semanas intensas:

6. Diagramas de Visualização

Os modelos abaixo utilizam Mermaid, garantindo uma representação diagramática clara e unificada como código.

6.1. Diagrama de Casos de Uso

Apresenta as fronteiras e as interações primárias entre os colaboradores do restaurante e a aplicação.

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

6.2. Diagrama de Classes (Camada de Domínio)

Expõe as entidades e a arquitetura de encapsulamento no Java, demonstrando dependências estruturais.

6.3. Diagrama de Entidade-Relacionamento (DER)

A modelagem lógica dos dados persistidos no banco de dados MySQL para rastreabilidade financeira e operacional.

Fim da Documentação do Projeto Integrador (2026). Este documento foi concebido para certificar as habilidades de Engenharia de Software e Banco de Dados, aliando rigor metodológico, tecnologia sustentável e melhores práticas do mercado de desenvolvimento corporativo.