[Nome da Instituição de Ensino]

Curso: [Nome do Curso]

[Nome da Disciplina / Projeto]

Documentação Técnica: Sistema de Gestão de Estacionamentos (ParkFlow)

Autores: [Nome dos Alunos]
Professor Orientador: [Nome do Professor]

Trabalho apresentado à [Nome da Instituição] como requisito para a disciplina de [Nome da Disciplina].

Data: [Mês/Ano]

Resumo

O projeto ParkFlow é uma solução para gestão de pátios de estacionamento. O sistema visa informatizar os processos de controle de entrada e saída de veículos rotativos e mensalistas, automatizando o cálculo de tarifas com base no tempo de permanência e nas tabelas de preços vigentes, além de fornecer recursos de gestão e auditoria essenciais para a administração financeira e controle de acesso.

Sumário

  1. Introdução
  2. Requisitos de Gestão
  3. Engenharia de Software
  4. Banco de Dados
  5. Lógica de Negócio e Algoritmo de Cobrança

1. Introdução

O controle de veículos em estacionamentos é frequentemente realizado de forma manual ou por sistemas defasados, o que pode gerar inconsistências financeiras e de segurança. O ParkFlow propõe uma abordagem moderna, oferecendo painéis tanto para o operador de pátio (focado em agilidade) quanto para o administrador (focado em gestão e relatórios).

2. Requisitos do Sistema

2.1 Requisitos Funcionais (RF)

ID Descrição Prioridade
RF01 O sistema deve permitir o registro de entrada de veículos, capturando a placa, modelo e cor. Alta
RF02 O sistema deve calcular automaticamente o valor devido no momento da saída com base na tabela de preços ativa. Alta
RF03 O sistema deve permitir o cadastro, edição e renovação de clientes mensalistas. Alta
RF04 O sistema deve gerar relatórios financeiros (faturamento rotativo vs. mensalista) diários e mensais. Média
RF05 O administrador deve poder configurar os valores de fração inicial, hora adicional e tolerância. Média

2.2 Requisitos Não Funcionais (RNF)

ID Descrição Categoria
RNF01 O sistema deve ser desenvolvido em arquitetura Web utilizando Spring Boot e Thymeleaf. Arquitetura
RNF02 O banco de dados relacional (PostgreSQL) deve estar na 3ª Forma Normal (3FN). Banco de Dados
RNF03 Segurança e Auditoria: Toda ação de cancelamento de ticket deve registrar um log de acesso imutável. Segurança
RNF04 Conformidade com a LGPD: O armazenamento das placas e CPFs dos clientes deve possuir controle de acesso estrito e mascaramento em telas não administrativas. Legal

3. Engenharia de Software

3.1 Diagrama de Casos de Uso (UML)

Este diagrama ilustra as interações dos atores (Operador e Administrador) com as funcionalidades centrais do sistema.

flowchart LR
    Op((Operador de Pátio))
    Admin((Administrador))

    subgraph Sistema ["Sistema ParkFlow"]
        direction TB
        UC1([Registrar Entrada Ticket])
        UC2([Registrar Saída/Pagamento])
        UC3([Gerenciar Mensalistas])
        UC4([Consultar Vagas Disponíveis])
        UC5([Gerar Relatórios Financeiros])
        UC6([Configurar Tarifário])
    end

    Op --> UC1
    Op --> UC2
    Op --> UC4
    Admin --> UC3
    Admin --> UC5
    Admin --> UC6
    Admin -.->|herda de| Op

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

Descrição Textual dos Casos de Uso:

Detalhamento de Caso de Uso: Registrar Saída/Pagamento (UC2)

3.2 Diagrama de Classes

A estrutura de classes foca na separação de responsabilidades e nos princípios de Orientação a Objetos como herança e encapsulamento.

classDiagram
    class Veiculo {
        +String placa
        +String modelo
        +String cor
        +registrar()
    }
    class Ticket {
        +DateTime entrada
        +DateTime saida
        +Double valorTotal
        +String status
        +calcularValor()
        +encerrar()
    }
    class Cliente {
        +String nome
        +String documento
        +String contato
    }
    class Mensalista {
        +DateTime dataVencimento
        +Double valorMensalidade
        +renovar()
    }

    Veiculo "1" -- "0..*" Ticket : possui
    Cliente <|-- Mensalista : herança
    Mensalista "1" -- "1" Veiculo : vincula
    Ticket "0..*" -- "1" Operador : processado por

Descrição Textual do Diagrama de Classes:

4. Banco de Dados

4.1 Modelo Entidade-Relacionamento (MER - Mermaid)

O modelo relacional foi desenhado na Terceira Forma Normal (3FN) para garantir a integridade dos dados e o histórico de transações.

erDiagram
    USUARIO ||--o{ LOG_ACESSO : "gera"
    VEICULO ||--o{ TICKET : "possui"
    CLIENTE ||--o{ VEICULO : "cadastra"
    TABELA_PRECO ||--o{ TICKET : "define valor"

    USUARIO {
        int id_usuario PK
        string nome
        string email
        string senha_hash
        enum perfil
    }

    VEICULO {
        int id_veiculo PK
        string placa
        string modelo
        string cor
        int id_cliente FK
    }

    TICKET {
        int id_ticket PK
        int id_veiculo FK
        datetime dt_entrada
        datetime dt_saida
        decimal valor_total
        string status
        int id_tabela_preco FK
    }

    CLIENTE {
        int id_cliente PK
        string nome
        string cpf_cnpj
        boolean eh_mensalista
    }

    LOG_ACESSO {
        int id_log PK
        int id_usuario FK
        string acao
        datetime quando
        string ip
    }

    TABELA_PRECO {
        int id_tabela PK
        decimal valor_fracao
        decimal valor_hora
        int minutos_tolerancia
        boolean ativa
    }

Descrição Textual do MER:

4.2 Scripts SQL (DDL e DML)

Conforme os padrões acadêmicos, abaixo apresentamos os scripts DDL de criação e um exemplo de consulta avançada para extração de relatórios.

Estrutura de Criação (DDL - PostgreSQL/H2):

CREATE TABLE TABELA_PRECO (
    id_tabela SERIAL PRIMARY KEY,
    valor_fracao DECIMAL(10,2) NOT NULL,
    valor_hora DECIMAL(10,2) NOT NULL,
    minutos_tolerancia INT NOT NULL,
    ativa BOOLEAN DEFAULT TRUE
);

CREATE TABLE CLIENTE (
    id_cliente SERIAL PRIMARY KEY,
    nome VARCHAR(100) NOT NULL,
    cpf_cnpj VARCHAR(20) UNIQUE NOT NULL,
    eh_mensalista BOOLEAN DEFAULT FALSE
);

CREATE TABLE VEICULO (
    id_veiculo SERIAL PRIMARY KEY,
    placa VARCHAR(10) UNIQUE NOT NULL,
    modelo VARCHAR(50),
    cor VARCHAR(30),
    id_cliente INT REFERENCES CLIENTE(id_cliente)
);

CREATE TABLE TICKET (
    id_ticket SERIAL PRIMARY KEY,
    id_veiculo INT NOT NULL REFERENCES VEICULO(id_veiculo),
    id_tabela_preco INT NOT NULL REFERENCES TABELA_PRECO(id_tabela),
    dt_entrada TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    dt_saida TIMESTAMP,
    valor_total DECIMAL(10,2),
    status VARCHAR(20) DEFAULT 'ABERTO'
);

Exemplo de Consulta (JOIN) - Relatório de Tickets com Dados do Veículo:

SELECT 
    t.id_ticket, 
    v.placa, 
    c.nome AS cliente, 
    t.dt_entrada, 
    t.dt_saida, 
    t.valor_total 
FROM TICKET t
INNER JOIN VEICULO v ON t.id_veiculo = v.id_veiculo
LEFT JOIN CLIENTE c ON v.id_cliente = c.id_cliente
WHERE t.status = 'FECHADO'
ORDER BY t.dt_saida DESC;

5. Lógica de Negócio e Algoritmo de Cobrança

Conforme os requisitos de desempenho (RNF), a lógica de cálculo foi concebida para ser eficiente e precisa.

6. Planejamento e Cronograma

O desenvolvimento foi organizado em um ciclo ágil adaptado de 6 semanas para a entrega do Projeto:

Semana Fase do Projeto Entregáveis e Atividades (Backlog)
Semana 1 Levantamento e Requisitos Reuniões, Definição de RF/RNF, Casos de Uso.
Semana 2 Modelagem de Dados Diagramas de Classes, MER, Scripts DDL iniciais.
Semana 3 Setup e Prototipagem Geração do projeto Spring Boot, telas Thymeleaf base.
Semana 4 Codificação Backend Implementação de Controllers, Repositórios e Serviços (Cobrança).
Semana 5 Integração e Relatórios Conexão Front-Back, Consultas JOIN, Trilha de Auditoria.
Semana 6 Testes e Entrega Testes de fluxo, validação de LGPD, defesa do projeto.