Documentação Arquitetural do Sistema

EBCP - Sistema de Integração e Gestão de Estágios (SIGE)

1. Introdução
1.1 Finalidade

Este documento oferece uma visão geral arquitetural abrangente do SIGE (Sistema de Integração e Gestão de Estágios) e do módulo integrado SIGE Concursos. O objetivo deste documento é capturar e comunicar as decisões arquiteturais significativas que foram tomadas em relação ao sistema.

1.2 Escopo

O SIGE é uma plataforma corporativa integrada voltada para o gerenciamento de estájáros, controle de termos e aditivos (TCE), portal de vagas/candidaturas, controle financeiro em lote, auditoria de dados e automação de processos seletivos públicos e concursos da EBCP.

1.3 Definições, Acrônimos e Abreviações
  • SIGE / SIGEBR: Sistema de Integração e Gestão de Estágios.
  • TCE: Termo de Compromisso de Estágio.
  • DER: Diagrama de Entidade-Relacionamento.
  • UML: Unified Modeling Language (Linguagem de Modelagem Unificada).
  • RBAC: Role-Based Access Control (Controle de Acesso Baseado em Nível).
  • CNAB: Centro Nacional de Automação Bancária (Layouts CNAB240 para remessas).
  • ZapSign: Plataforma integrada de assinatura eletrônica.
1.4 Referências
  • Laravel Framework Official Documentation.
  • ZapSign API Reference Guide.
  • Notaas NFSe API documentation.
1.5 Visão Geral

O restante deste documento detalha a arquitetura lógica, dados, implantação, fluxos e qualidade sob o padrão do Rational Unified Process (RUP).

2. Representação Arquitetural

O SIGE utiliza a arquitetura MVC (Model-View-Controller) robusta implementada pelo framework Laravel 11 / PHP 8.2. O banco de dados relacional MySQL é o motor de persistência principal. O frontend utiliza templates Blade integrados a Javascript assíncrono para listagens interativas e CSS Vanilla otimizado.

A portabilidade móvel é garantida através da tecnologia PWA (Progressive Web App), que possibilita instalação nativa em sistemas operacionais Android e iOS com suporte a Service Worker de cacheamento.

3. Metas e Restrições da Arquitetura
  • Segurança (RBAC): Restrição física de rotas administrativas via middleware baseado em nível de usuário (admin, operador, empresa, estagiario, candidato).
  • Auditabilidade e Imutabilidade Jurídica: Os contratos gerados contam com campos duplicados com sufixo _fixo (ex: desc_atividades_fixo) que espelham e salvam de forma permanente os dados no momento da contratação, mitigando alterações retroativas.
  • Desempenho no Processamento: Rotinas de alta demanda (como processamento de folhas e remessas bancárias) são divididas em lotes automáticos (batches) para evitar estouro de memória PHP e timeouts.
  • Requisitos de Setup: PHP 8.2 ou superior, MySQL 5.7+ ou MariaDB.
4. Visão de Casos de Uso

O diagrama abaixo detalha a interação dos diversos atores com as frentes de negócios do SIGE:

graph TD
    subgraph Atores
        Admin[Admin / Operador]
        Empresa[Unidade Concedente]
        Estag[Estagiário]
        Cand[Candidato Público]
    end

    subgraph Administrativo
        Admin --> AD1(Gerenciar Estagiários, Escolas e Supervisores)
        Admin --> AD2(Criar Termos e Contratos TCE)
        Admin --> AD3(Processar Folha e Remessas CNAB)
        Admin --> AD4(Configurar Concursos e Salas)
    end

    subgraph Unidade Concedente
        Empresa --> EM1(Publicar e Gerenciar Vagas)
        Empresa --> EM2(Abrir Chamados de Suporte)
        Empresa --> EM3(Consultar Contratos e Chat)
    end

    subgraph Estagiário
        Estag --> ES1(Atualizar Perfil e Upload de Docs)
        Estag --> ES2(Gerar Avaliações para Supervisor)
        Estag --> ES3(Recuperar Acesso por CPF)
    end

    subgraph Concursos
        Cand --> CA1(Inscrição e Envio de Currículo)
        Cand --> CA2(Consultar Local de Prova e Sala)
    end
                        
4.1 Realizações de Casos de Uso
  • Assinatura Eletrônica: Envio do PDF do TCE para a API ZapSign. O status do termo muda e a sincronização final ocorre sob webhook da API.
  • Avaliações com Token de Segurança: Rotina agendada gera questionários de 6 meses; links de acesso público utilizam hashes seguros que expiram imediatamente após a resposta.
  • Distribuição de Concursos: Algoritmo automatizado que balanceia em ordem alfabética os candidatos entre as salas físicas de prova do local selecionado.
5. Visão Lógica
5.1 Visão Geral

A arquitetura lógica do sistema divide-se em componentes lógicos bem isolados para separar as responsabilidades do ecossistema de Estágios frente ao de Processos Seletivos (SIGE Concursos):

5.2 Pacotes de Design Significativos
Acesso Restrito: Os pacotes de design detalhados, diagramas lógicos, models e controladores associados a cada caso de uso são privados para preservação de propriedade intelectual e segurança do sistema.
6. Visão de Processos

O sistema implementa processos assíncronos e agendados no backend para lidar com integrações externas e automação:

  • Filas de Jobs assíncronos: Gerenciamento de tarefas em background como envio de e-mails de notificação e processamentos em lotes.
  • Webhooks: Sincronização automática em tempo real para os módulos ZapSign e Notas Fiscais Notaas.
  • Scheduler (Cron): Agendador de tarefas diário (rodando via php artisan schedule:run) responsável por rodar o processamento do job GerarAvaliacoesAutomaticasJob às 02:00 da manhã.
7. Visão de Implantação

O ecossistema é hospedado em ambiente web padrão e possui integrações externas:

graph LR
    User[Navegador / App PWA] -->|HTTPS| Web[Servidor Apache/Nginx Web]
    Web -->|SQL Query| DB[(Banco de Dados MySQL)]
    Web -->|REST API| Zap[API ZapSign]
    Web -->|REST API| Notaas[API Notaas NFSe]
                        
8. Visão da Implementação
8.1 Camadas do Sistema

O código-fonte está estruturado sob as seguintes camadas de software:

  • Camada de Apresentação (Views): Blade templates com Javascript assíncrono localizados em resources/views.
  • Camada de Controle (Controllers): Lógica de fluxo do sistema em app/Http/Controllers.
  • Camada de Dados (Models / Eloquent ORM): Representação e relações das tabelas em app/Models.
  • Camada de Integrações (Services): Consumo de APIs externas e lógica separada em app/Services.
9. Visão de Dados (DER)

O banco de dados do sistema possui um alto nível de normalização, mantendo a integridade referencial física por meio de constraints de chaves estrangeiras (FK).

Abaixo está o modelo resumido das tabelas principais e seus relacionamentos:

erDiagram
    USERS ||--o| tb_empresas : fk_id_empresa
    USERS ||--o| tb_estagiarios : fk_id_estagiario
    tb_empresas ||--o{ tb_supervisores : fk_id_empresa
    tb_empresas ||--o{ tb_local : fk_id_empresa
    tb_empresas ||--o{ tb_termos : fk_id_empresa
    tb_estagiarios ||--o{ tb_termos : fk_id_estagiario
    tb_escolas ||--o{ tb_termos : fk_id_escola
    tb_supervisores ||--o{ tb_termos : fk_id_supervisor
    tb_termos ||--o{ tb_alteracao_termo : fk_id_termo
    tb_termos ||--o| tb_rescisao : fk_id_termo
    tb_termos ||--o{ tb_avaliacoes : fk_id_termo
                        
Diagrama Entidade-Relacionamento Completo
Acesso Restrito: O diagrama detalhado vetorial do banco de dados (DER) e suas colunas físicas estão ocultos para proteção da infraestrutura e governança de segurança corporativa.
10. Tamanho e Desempenho

Para suportar volumes massivos de dados em ambientes compartilhados de hospedagem, o SIGE implementa:

  • Carregamentos Parciais (Batch Processing): Processamento em lotes de 50 registros por vez para a folha de pagamento de estagiários.
  • Select2 Assíncrono: Inputs de buscas de empresas e estagiários utilizam requisições AJAX paginadas de até 50 itens para evitar gargalos na renderização DOM.
  • Limitação Física de Arquivos: Limite rígido de 5MB para uploads de PDF/imagens no perfil do estagiário e chamados.
11. Qualidade e Segurança
  • Controle Transacional: Operações cruciais no banco de dados utilizam transações SQL (DB::beginTransaction()) para garantir rollback completo caso ocorra falha de hardware ou rede no meio da execução.
  • Token de Validação: Avaliações acessíveis publicamente utilizam chaves geradas por criptografia forte com descarte imediato após o processamento.
  • Segurança HTTP: Todos os endpoints administrativos são protegidos por middlewares de autenticação com restrições rígidas baseadas em RBAC.