Sumário

1. Introdução
2. Fundamentação Teórica
   • 2.1. O Problema do Controle Manual em Estacionamentos
   • 2.2. Cálculos Temporais e Tolerância de Frações
   • 2.3. Prevenção de Fraudes e Evasão de Receitas
   • 2.4. Segurança no Armazenamento de Dados Financeiros
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 Relacional e Script DDL
   • 4.2. Consultas Complexas e Fechamento de Caixa (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

A mobilidade urbana em centros comerciais e acadêmicos gerou uma alta demanda por pátios de estacionamento seguros e eficientes. A gestão desses espaços, no entanto, frequentemente sofre com processos defasados, como o uso de tickets preenchidos à mão, que abrem margem para fraudes (cobranças indevidas), evasão de receitas e gargalos de atendimento no momento da saída dos veículos.

O Projeto Integrador Gestão de Estacionamentos, desenvolvido como projeto acadêmico (2026), propõe uma arquitetura de software abrangente para solucionar essas vulnerabilidades. O sistema projetado automatiza o cálculo de tarifas baseado em tempo (frações e diárias), controla o cadastro de clientes mensalistas e assegura a criptografia e imutabilidade dos dados financeiros das transações. Este documento aborda com rigor técnico a engenharia por trás do sistema, os diagramas estruturais em UML e o embasamento do modelo de persistência relacional.

2. Fundamentação Teórica

2.1. O Problema do Controle Manual em Estacionamentos

Pátios de estacionamento que não possuem automação perdem a capacidade de metrificar sua taxa de ocupação em tempo real. O operador não sabe quantas vagas estão disponíveis sem realizar uma checagem visual, e a dependência do relógio de pulso ou de parede para calcular frações de hora resulta em imprecisões severas. Além do erro humano, há a questão da segurança: veículos podem ser liberados sem o pagamento correspondente caso exista conluio entre o cliente e o operador da cancela.

2.2. Cálculos Temporais e Tolerância de Frações

No desenvolvimento de sistemas de tarifação, o tratamento do domínio temporal (DateTime) é complexo. A arquitetura exige a medição exata do intervalo entre o Timestamp de Entrada e o Timestamp de Saída. Para garantir justiça ao consumidor (em respeito ao Código de Defesa do Consumidor) e rentabilidade à empresa, a lógica matemática do sistema precisa lidar com "Janelas de Tolerância" (ex: 15 minutos iniciais não pagam) e "Arredondamentos de Fração" (ex: passou 5 minutos da primeira hora, cobra-se uma nova fração de hora).

2.3. Prevenção de Fraudes e Evasão de Receitas

A integridade do fluxo de caixa é mantida através de rigorosos controles transacionais. Uma vez que o sistema gera um Ticket de entrada, ele não pode ser excluído fisicamente (DELETE bloqueado no banco de dados) sob nenhuma circunstância. Caso o cliente desista ou ocorra um erro de digitação de placa, o ticket é "Cancelado" (exclusão lógica), mas permanece no log de auditoria associado ao ID do operador logado, evitando "cancelamentos fantasmas" que acobertam desvios de dinheiro.

2.4. Segurança no Armazenamento de Dados Financeiros

Para atender à exigência de auditoria acadêmica rigorosa deste projeto, os parâmetros tarifários e os totais financeiros arrecadados ao longo dos turnos não podem ser adulterados diretamente via SQL. O sistema implementa funções de hashing e encriptação (como o uso de AES-128 em campos VARBINARY do MySQL e bibliotecas de criptografia no back-end) para os saldos de caixa, dificultando adulterações externas ao sistema. Adicionalmente, as senhas dos operadores (Administrador e Operador de Pátio) são armazenadas de forma segura através do algoritmo Bcrypt, prevenindo ataques de força bruta.

3. Engenharia de Software

3.1. Requisitos Funcionais (RF)

1. RF-001 | Registro de Entrada (Ticket): O sistema deve registrar a entrada de um veículo, capturando a placa, tipo de veículo (Moto, Carro, Van), data/hora automática do servidor e gerando um número de ticket único.
2. RF-002 | Cálculo Automático de Tarifa (Saída): O sistema deve, ao ler o ticket, calcular automaticamente o valor devido com base na diferença temporal de permanência e na tabela de preços ativa.
3. RF-003 | Gestão de Mensalistas: O sistema deve permitir o cadastro de clientes frequentes (Mensalistas), dispensando a cobrança de tickets avulsos e alertando o operador caso a mensalidade esteja vencida.
4. RF-004 | Controle de Ocupação: O sistema deve exibir um Dashboard com a lotação atual do pátio, impedindo novas entradas se o limite máximo de vagas (ex: 100) for atingido.
5. RF-005 | Fechamento de Caixa: O sistema deve prover ao administrador um relatório financeiro diário consolidando todos os tickets pagos e isentos.

3.2. Requisitos Não Funcionais (RNF)

1. RNF-001 (Desempenho e Agilidade): A tela de registro de saída e recálculo não deve exceder 500ms de tempo de resposta para não gerar filas de carros na cancela.
2. RNF-002 (Auditoria e Imutabilidade): Nenhuma transação financeira finalizada (ticket "Pago") pode ter seu valor ou horário de saída alterados nem pelo Administrador.
3. RNF-003 (Confiabilidade): O cálculo de tempo deve depender exclusivamente da hora do banco de dados (servidor NTP), ignorando o relógio do navegador/sistema operacional local do operador para evitar adulterações.

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

A modelagem de negócios (Business Logic) faz amplo uso de princípios de Orientação a Objetos para conferir extensibilidade tarifária:

• Abstração e Polimorfismo: Existe uma classe base Veiculo que abstrai as informações essenciais (Placa, Cor). Através do polimorfismo e herança, as classes filhas Carro e Motocicleta interagem com a classe CalculadoraTarifa. O método calcular(Veiculo v, tempo) comporta-se de maneira diferente no nível do polimorfismo, pois busca tarifas distintas na base dependendo se o objeto instanciado for um Carro ou uma Moto.
• Encapsulamento: Na classe Ticket, os atributos horaEntrada e valorTotal são estritamente privados (private). O valorTotal não pode ser definido (setValorTotal) de forma arbitrária pelo Controller; ele só pode ser obtido (getValorTotal) como resultado do processamento dos métodos internos do objeto, garantindo a proteção e integridade do modelo matemático.

3.4. Caso de Uso Principal (UC-01)

Identificador: UC-01
Nome: Registrar Saída/Pagamento do Veículo
Ator Principal: Operador de Pátio
Pré-condição: O veículo deve ter um registro de "Ticket em Aberto" no sistema.

Fluxo Principal:

1. O Operador insere a Placa do veículo no sistema ou realiza a leitura de código de barras do ticket.
2. O sistema recupera a entidade associada ao ticket em aberto.
3. O sistema invoca a função que checa a hora atual (NTP/BD) e subtrai da hora de entrada, extraindo o total de minutos.
4. O sistema consulta a tabela de parâmetros (Tolerância, 1ª Hora, Demais Frações) e executa o algoritmo de cobrança.
5. O sistema exibe o tempo total e o Valor a Pagar na interface.
6. O Operador recebe o montante do cliente e clica em "Confirmar Recebimento".
7. O sistema faz a atualização transacional no Banco de Dados (UPDATE tbl_tickets SET status = 'PAGO', hora_saida = NOW()).
8. O sistema decrementa a métrica de "Lotação Atual" do pátio e libera a cancela virtual.

Fluxo de Exceção (Mensalista): Se no passo 2 o sistema identificar que a Placa pertence a um cliente Mensalista com o status "Ativo", ele pula o cálculo tarifário, exibe o valor "R$ 0,00 (Mensalista Autorizado)" e registra a saída como evento de auditoria simples.

4. Banco de Dados (MySQL)

Para garantir que informações de cobrança resistam a falhas de rede ou energia sem perdas de estado, o uso do modelo de dados relacional foi implementado seguindo estritas regras de normalização (3FN).

4.1. Modelagem Relacional e Script DDL

O script DDL (Data Definition Language) evidencia a criação da base central. Destaca-se o uso de cifragem (VARBINARY) para armazenar o log auditável da movimentação financeira.

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

USE db_estacionamento_corporate;

-- Tabela de Operadores (Hierarquia de Acesso)
CREATE TABLE IF NOT EXISTS tbl_usuarios (
    id_usuario INT AUTO_INCREMENT PRIMARY KEY,
    nome_completo VARCHAR(100) NOT NULL,
    login_acesso VARCHAR(50) NOT NULL UNIQUE,
    senha_hash VARCHAR(255) NOT NULL COMMENT 'Armazena hash Bcrypt do Operador',
    perfil_acesso ENUM('OPERADOR_PATIO', 'ADMINISTRADOR') NOT NULL,
    status BOOLEAN DEFAULT TRUE
);

-- Tabela de Tarifário (Parâmetros Dinâmicos)
CREATE TABLE IF NOT EXISTS tbl_tarifas (
    id_tarifa INT AUTO_INCREMENT PRIMARY KEY,
    tipo_veiculo ENUM('CARRO', 'MOTO', 'VAN') NOT NULL,
    valor_primeira_hora DECIMAL(10,2) NOT NULL,
    valor_fracao_adicional DECIMAL(10,2) NOT NULL,
    minutos_tolerancia INT NOT NULL DEFAULT 15,
    data_vigencia DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- Tabela de Mensalistas
CREATE TABLE IF NOT EXISTS tbl_mensalistas (
    id_mensalista INT AUTO_INCREMENT PRIMARY KEY,
    placa_veiculo VARCHAR(10) NOT NULL UNIQUE,
    nome_cliente VARCHAR(100) NOT NULL,
    telefone_contato VARCHAR(20),
    data_vencimento_plano DATE NOT NULL
);

-- Tabela Central (Tickets de Transação)
CREATE TABLE IF NOT EXISTS tbl_tickets (
    id_ticket BIGINT AUTO_INCREMENT PRIMARY KEY,
    placa_veiculo VARCHAR(10) NOT NULL,
    tipo_veiculo ENUM('CARRO', 'MOTO', 'VAN') NOT NULL,
    hora_entrada DATETIME DEFAULT CURRENT_TIMESTAMP NOT NULL,
    hora_saida DATETIME NULL,
    status_ticket ENUM('ABERTO', 'PAGO', 'ISENTO', 'CANCELADO') DEFAULT 'ABERTO',
    valor_cobrado DECIMAL(10,2) DEFAULT 0.00,
    assinatura_criptografica VARBINARY(256) COMMENT 'Selo de integridade financeira AES',
    id_operador_entrada INT NOT NULL,
    id_operador_saida INT NULL,
    FOREIGN KEY (id_operador_entrada) REFERENCES tbl_usuarios(id_usuario) ON DELETE RESTRICT,
    FOREIGN KEY (id_operador_saida) REFERENCES tbl_usuarios(id_usuario) ON DELETE RESTRICT
);

4.2. Consultas Complexas e Relatórios de Desempenho (DML)

Administradores dependem de Data Manipulation Language sofisticada para métricas gerenciais. A consulta abaixo gera o faturamento líquido, descontando takes isentos (como mensalistas), segmentado por tipo de veículo e filtrando a operação dos últimos 6 meses. O resultado ajuda o negócio a entender o fluxo sazonal.

-- Relatório Estratégico: Faturamento Semestral Consolidado por Tipo de Veículo
SELECT 
    DATE_FORMAT(hora_saida, '%Y-%m') AS 'Mes_Referencia',
    tipo_veiculo AS 'Categoria',
    COUNT(id_ticket) AS 'Volume_Tickets_Emitidos',
    SUM(valor_cobrado) AS 'Faturamento_Bruto',
    (SELECT COUNT(*) FROM tbl_tickets T2 
     WHERE T2.tipo_veiculo = tbl_tickets.tipo_veiculo 
       AND DATE_FORMAT(T2.hora_saida, '%Y-%m') = DATE_FORMAT(tbl_tickets.hora_saida, '%Y-%m') 
       AND T2.status_ticket = 'ISENTO') AS 'Volume_Isencoes_Mensalistas'
FROM 
    tbl_tickets
WHERE 
    status_ticket = 'PAGO'
    AND hora_saida >= DATE_SUB(CURRENT_DATE(), INTERVAL 6 MONTH)
GROUP BY 
    DATE_FORMAT(hora_saida, '%Y-%m'), 
    tipo_veiculo
HAVING 
    SUM(valor_cobrado) > 500
ORDER BY 
    'Mes_Referencia' DESC, 
    'Faturamento_Bruto' DESC;

Justificativa Técnica: A extração do mês com DATE_FORMAT e o agrupamento dinâmico (GROUP BY) em paridade com a cláusula HAVING isola dados inexpressivos. O uso de subquery garante a comparação direta entre o faturamento líquido contra o volume de passes livres (Mensalistas) num único relatório.

5. Gestão, Segurança e LGPD

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

Utilizando a governança ágil, o sistema foi desenhado através de histórias concisas:

História de Usuário 01 - Bloqueio Automático de Inadimplentes

Como um Operador de Pátio,
Eu quero que o sistema notifique e exija a emissão de ticket normal quando a placa lida for de um mensalista com plano vencido,
Para que eu não libere indevidamente clientes inadimplentes.
Critérios de Aceite: Se data_vencimento_plano < data_atual, o sistema bloqueia o status "Isento"; a tela do operador deve exibir um alerta vermelho alertando a inadimplência; o fluxo segue obrigatoriamente para a cobrança comum.

História de Usuário 02 - Dashboard Administrativo de Vagas

Como um Administrador de Estacionamento,
Eu quero visualizar um painel gráfico com a quantidade exata de veículos estacionados versus o número de vagas totais,
Para que eu possa evitar superlotação do pátio físico e fechamento da entrada.
Critérios de Aceite: O cálculo baseia-se num COUNT de registros onde status_ticket = 'ABERTO'; o painel deve ser atualizado via polling ou WebSockets a cada 5 segundos.

5.2. Conformidade com a LGPD e Privacy by Design

A lei geral de proteção de dados exige o cuidado extremo com a Tabela de Mensalistas, única área que cruza dados veiculares com identidade civil.

• Transparência e Finalidade: A coleta de nomes completos e telefones (Art. 6º da LGPD) tem a finalidade exclusiva de gestão do contrato de mensalista.
• Anonimização Protetiva: Caso o contrato de mensalista seja encerrado pelo cliente (Direito ao Esquecimento), o sistema prevê uma rotina de exclusão (Soft Delete + Data Masking), onde a placa histórica registrada na tabela de tickets permanece para contabilidade e auditoria (interesse legítimo fiscal), porém o vínculo civil com o CPF ou telefone associado é destruído criptograficamente de forma irrecuperável.

5.3. Cronograma do Projeto

A estimativa para o Go-Live da aplicação foi programada para 6 semanas de esforço contínuo:

6. Diagramas de Visualização

O emprego de diagramas Mermaid permite uma visualização exata do projeto de classes e comportamentos da arquitetura do estacionamento.

6.1. Diagrama de Casos de Uso

Este diagrama descreve o controle de permissões e as ações disponíveis para o perfil Operacional vs. Administrativo.

Versão em Padrão UML (Boneco de Palito):

6.2. Diagrama de Classes (Cálculo Financeiro)

Mapeia a arquitetura lógica e os construtos orientados a objetos responsáveis pelo core de faturamento (Tarifador).

6.3. Diagrama de Entidade-Relacionamento (DER)

A estrutura de dados que garante a persistência blindada contra perdas e suporta os relatórios de auditoria financeira.

Fim da Documentação do Projeto Integrador (2026). Este material certifica que a modelagem arquitetural e de dados do sistema de controle de estacionamentos foi desenhada com excelência, visando zero perdas financeiras e máxima eficiência transacional.