README

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
   • Diagrama de Casos de Uso
   • Diagrama de Classes
4. Banco de Dados
   • Modelo Entidade-Relacionamento
   • Scripts SQL (DDL e DML)
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)

2.2 Requisitos Não Funcionais (RNF)

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.

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

Descrição Textual dos Casos de Uso:

• Atores:
  • Operador de Pátio: Focado nas operações diárias da catraca (entradas, saídas e controle de vagas).
  • Administrador: Possui as mesmas permissões do Operador (por herança Admin --|> Op), somadas às funções gerenciais.
• Casos Principais: O registro de entrada e saída são o core do negócio, demandando validação imediata da placa. A gestão de mensalistas permite o cadastro antecipado para liberação automática. A geração de relatórios e a configuração de tarifas são restritas ao painel administrativo.

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

• Ator Principal: Operador de Pátio.
• Fluxo Principal:
  1. O Operador insere a placa do veículo no sistema ou faz a leitura do ticket.
  2. O sistema busca o ticket em aberto associado à placa.
  3. O sistema calcula o tempo de permanência e o valor total com base na Tabela de Preços vigente.
  4. O sistema exibe o valor na tela.
  5. O Operador confirma o recebimento do pagamento e encerra o ticket.
  6. O sistema atualiza o status do ticket para "Pago" e registra a data/hora exata da saída.
• Fluxo Alternativo (Isenção/Tolerância): No passo 3, se o tempo de permanência for menor que a tolerância configurada (ex: 15 min), o valor total é zero e o ticket é baixado sem cobrança.

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.

Descrição Textual do Diagrama de Classes:

• Relacionamentos: Identifica-se que um Veiculo pode possuir múltiplos Tickets (histórico de passagens), mas um ticket pertence estritamente a um veículo (relação 1 para 0..*).
• Herança: A classe Mensalista herda atributos de Cliente, adicionando comportamentos específicos como renovar() e atributos contratuais.
• Processamento: Cada Ticket guarda a referência do operador que o emitiu/processou, essencial para a auditoria de caixa.

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.

Descrição Textual do MER:

• Tabela de Preços Ativa: Uma entidade TABELA_PRECO foi introduzida no modelo para satisfazer o requisito de controle gerencial. O ticket vincula-se a uma tabela (chave estrangeira), garantindo que alterações futuras nas tarifas não mudem o histórico de tickets já cobrados.
• Log de Acesso: A tabela LOG_ACESSO registra cada ação relevante vinculada ao USUARIO que a executou, com data, hora e IP, atendendo à necessidade de rastreabilidade e segurança.

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.

• Fração Inicial: Cobrança mínima correspondente a um período pré-definido (ex: 15 ou 30 minutos).
• Hora Adicional: Valor fixo somado após a primeira hora de permanência.
• Tolerância: Período de 10 a 15 minutos (configurável pelo admin) sem cobrança para permitir desistências ou manobras após a entrada ou o pagamento.
• Mensalistas: O sistema realiza uma validação automática na entrada. Se a placa pertencer a um mensalista ativo (adimplente), a cancela é liberada sem a geração de um ticket rotativo com cobrança.

6. Planejamento e Cronograma

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