Sumário

1. Introdução
2. Fundamentação Teórica
   • 2.1. O Desafio na Gestão de Ativos de TI
   • 2.2. Persistência Local (Web Storage API) vs. Centralizada (SGBD)
   • 2.3. Rastreabilidade e Prevenção de Perdas
   • 2.4. Segurança no Armazenamento de Históricos
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 Relatórios de Fluxo (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

No ambiente corporativo e acadêmico moderno, a rotatividade de equipamentos tecnológicos (notebooks, tablets, projetores e periféricos) atinge volumes substanciais. A gestão inadequada desses ativos frequentemente resulta em equipamentos perdidos, subutilizados ou danificados sem que haja rastreabilidade do responsável. Para mitigar esse problema, o Projeto Integrador Controle de Fluxo de Dispositivos Eletrônicos, desenvolvido como projeto acadêmico (2026), propõe uma arquitetura de software focada na agilidade do front-end e na consistência dos registros em banco de dados.

O projeto foi delineado inicialmente utilizando tecnologias de persistência local (localStorage) para garantir operação off-line e extrema responsividade em dispositivos móveis da equipe técnica. Contudo, para atender às políticas de auditoria institucional, a arquitetura evoluiu para contemplar um sincronismo com um Banco de Dados Relacional (MySQL). Este documento descreve minuciosamente os padrões arquiteturais, modelagem de dados, diagramação orientada a objetos e conformidade legal que alicerçam a solução de inventário.

2. Fundamentação Teórica

2.1. O Desafio na Gestão de Ativos de TI

Controlar equipamentos eletrônicos de uso compartilhado requer um equilíbrio delicado entre segurança (evitar furtos e extravios) e disponibilidade (garantir que o colaborador acesse a ferramenta quando precisar). Planilhas não padronizadas ou controles baseados em assinaturas de papel dificultam a visão global do inventário (o Dashboard), impedindo que os gestores saibam, em tempo real, quantos equipamentos estão disponíveis no estoque versus quantos estão em posse de terceiros.

2.2. Persistência Local (Web Storage API) vs. Centralizada (SGBD)

O projeto inova ao propor uma arquitetura híbrida. A camada de apresentação faz uso massivo da API localStorage do HTML5. Esta tecnologia permite armazenar pares de chave-valor diretamente no navegador do operador de TI. A grande vantagem acadêmica e prática dessa abordagem é o Tempo de Resposta (Zero Latência): registrar a saída de um dispositivo ocorre instantaneamente, sem bloqueios de rede.

No entanto, sistemas de auditoria exigem que os dados não fiquem restritos ao disco rígido de um único terminal. Portanto, a teoria de sistemas distribuídos aplicada a este projeto compreende um serviço Worker em background que lê as strings JSON armazenadas no localStorage e realiza a sincronização transacional para um servidor centralizado hospedado em MySQL, unindo o melhor da portabilidade front-end com a integridade relacional do back-end.

2.3. Rastreabilidade e Prevenção de Perdas

Para a rastreabilidade efetiva, o sistema exige três fatores fundamentais para registrar uma movimentação (Fluxo de Saída):

1. O quê: O Ativo (identificado por MAC Address, Patrimônio ou Número de Série).
2. Para quem: O Colaborador/Aluno responsável pela custódia temporária.
3. Quando: O Timestamp exato (carimbo de data/hora) do evento. Essa tríade gera um log imutável de responsabilidade, dissuadindo o mau uso e acelerando a recuperação do dispositivo em caso de não devolução.

2.4. Segurança no Armazenamento de Históricos

Assim como a manipulação de credenciais exige cuidados (conforme teorias de criptografia e Hashing), a manipulação do inventário exige garantias contra falsificação de dados. Um operador não pode ser capaz de excluir um log de empréstimo para encobrir a perda de um equipamento. Para isso, o banco de dados implementa restrições (Constraints) onde históricos de transação (Logs) são inseridos de modo Append-Only (apenas inserção), e exclusões lógicas são feitas apenas através de estornos autorizados, mantendo a trilha de auditoria intacta.

3. Engenharia de Software

3.1. Requisitos Funcionais (RF)

1. RF-001 | Dashboard Analítico: O sistema deve exibir um painel principal que consolide o total de dispositivos registrados, entradas do dia, saídas pendentes de devolução e o saldo atualizado de equipamentos no almoxarifado.
2. RF-002 | Registro de Movimentação: O sistema deve permitir o registro de Entrada (recebimento/devolução) e Saída (empréstimo/despacho) atrelando um responsável, equipamento e quantidade.
3. RF-003 | Histórico Cronológico: O sistema deve listar todas as movimentações ocorridas em formato de Timeline, permitindo filtros por data ou responsável.
4. RF-004 | Persistência Off-line (localStorage): O sistema deve gravar o registro imediatamente no navegador para garantir operação caso haja instabilidade de rede.
5. RF-005 | Sincronização em Nuvem (MySQL): O sistema deve sincronizar os dados do armazenamento local com o banco de dados central assim que uma conexão segura for detectada.

3.2. Requisitos Não Funcionais (RNF)

1. RNF-001 (Usabilidade): A interface deve ser desenvolvida em padrão Mobile-First, permitindo que técnicos pelo galpão utilizem tablets para ler códigos de barras e registrar o fluxo.
2. RNF-002 (Confiabilidade e Integridade): O saldo (estoque) não pode sofrer inconsistências, como resultar em valor negativo. Operações de saída de equipamentos não disponíveis no saldo devem ser bloqueadas.
3. RNF-003 (Portabilidade): Por não depender de instalação de executáveis, o sistema deve rodar em navegadores Chrome, Edge e Safari de forma idêntica.

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

Os princípios de Orientação a Objetos (OO) foram aplicados tanto no mapeamento das estruturas JavaScript (ES6 Classes) quanto na camada lógica de integração:

• Abstração: O conceito de "Dispositivo" foi abstraído em uma classe abstrata Ativo. As características complexas (especificações de hardware) foram ocultadas, destacando-se apenas atributos de controle (numeroPatrimonio, categoria, status). Classes derivadas como Laptop ou Projetor estendem o Ativo.
• Encapsulamento: No módulo responsável pela manipulação do Storage, os métodos de escrita direta (como localStorage.setItem()) são isolados (privados) dentro de uma classe StorageRepository. O resto da aplicação invoca métodos seguros como repository.salvarMovimentacao(). Essa classe garante que o objeto seja validado e serializado (JSON.stringify) antes da gravação.
• Polimorfismo: Na geração de comprovantes de empréstimo, a interface IComprovante permite que métodos polimórficos gerem diferentes saídas: a função exportar() pode agir de forma polimórfica para gerar um PDF ou enviar um E-mail dependendo da classe concreta instanciada, sem que o controlador precise saber a lógica de exportação.

3.4. Caso de Uso Principal (UC-01)

Identificador: UC-01
Nome: Registrar Saída (Empréstimo) de Dispositivo
Ator Principal: Técnico de Suporte (Almoxarifado)
Pré-condição: O equipamento deve estar com status "DISPONIVEL" no estoque.

Fluxo Principal:

1. O Técnico seleciona a ação "Nova Saída" no Dashboard.
2. O Técnico digita (ou lê com scanner) a Tag Patrimonial do Equipamento.
3. O sistema valida se o equipamento encontra-se disponível.
4. O Técnico informa a Matrícula/Nome do Responsável que receberá o dispositivo.
5. O Técnico confirma a operação.
6. O sistema deduz 1 unidade do Saldo Geral de Ativos.
7. O sistema cria um registro JSON na API localStorage contendo Timestamp e dados do fluxo.
8. O sistema (em background) realiza um POST para a API central (Sincronização BD).
9. O Dashboard é atualizado em tempo real exibindo a nova métrica.

Fluxo de Exceção 1 (Ativo não Disponível): Se no Passo 3 o dispositivo constar como "EMPRESTADO" ou "MANUTENÇÃO", o sistema aborta o registro e exibe a mensagem de erro na interface: "Ativo não se encontra no estoque para liberação". O evento é cancelado.

4. Banco de Dados (MySQL)

Embora a camada de interface utilize armazenamento local, o rigor de um projeto corporativo exige uma fonte central de verdade (Single Source of Truth). O banco relacional MySQL gerencia as restrições e históricos oficiais.

4.1. Modelagem Relacional e Script DDL

O script DDL (Data Definition Language) cria as tabelas de controle, aplicando Chaves Estrangeiras (FK) para relacionar os ativos aos responsáveis. Utilizou-se VARBINARY ou encriptação em campos sensíveis quando aplicável (por exemplo, informações confidenciais associadas a diretoria).

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

USE db_fluxo_dispositivos;

-- Tabela de Responsáveis (Colaboradores/Alunos)
CREATE TABLE IF NOT EXISTS tbl_responsaveis (
    id_responsavel INT AUTO_INCREMENT PRIMARY KEY,
    matricula VARCHAR(20) NOT NULL UNIQUE,
    nome_completo VARCHAR(100) NOT NULL,
    departamento VARCHAR(50),
    data_cadastro DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- Tabela de Dispositivos (Inventário)
CREATE TABLE IF NOT EXISTS tbl_dispositivos (
    id_dispositivo INT AUTO_INCREMENT PRIMARY KEY,
    numero_patrimonio VARCHAR(50) NOT NULL UNIQUE,
    modelo VARCHAR(100) NOT NULL,
    categoria ENUM('NOTEBOOK', 'TABLET', 'PROJETOR', 'PERIFERICO') NOT NULL,
    status_atual ENUM('DISPONIVEL', 'EMPRESTADO', 'MANUTENCAO', 'BAIXA') DEFAULT 'DISPONIVEL',
    detalhes_sensiveis VARBINARY(500) COMMENT 'Armazena notas fiscais ou chaves de licença cifradas'
);

-- Tabela Transacional de Fluxo (Log de Empréstimos)
CREATE TABLE IF NOT EXISTS tbl_fluxo_movimentacao (
    id_movimentacao INT AUTO_INCREMENT PRIMARY KEY,
    id_dispositivo INT NOT NULL,
    id_responsavel INT NOT NULL,
    tipo_movimentacao ENUM('SAIDA', 'ENTRADA') NOT NULL,
    data_evento DATETIME DEFAULT CURRENT_TIMESTAMP,
    observacao VARCHAR(255),
    id_usuario_operador INT NOT NULL COMMENT 'O técnico que liberou o ativo',
    FOREIGN KEY (id_dispositivo) REFERENCES tbl_dispositivos(id_dispositivo) ON DELETE RESTRICT,
    FOREIGN KEY (id_responsavel) REFERENCES tbl_responsaveis(id_responsavel) ON DELETE RESTRICT
);

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

A query avançada abaixo demonstra a capacidade de gerar relatórios de auditoria, cruzando tabelas (INNER JOIN), agrupando resultados (GROUP BY), e filtrando registros (HAVING e DATE_SUB). Este relatório levanta os colaboradores que mais requisitaram notebooks nos últimos 6 meses e ainda possuem equipamentos pendentes de devolução, indicando potencial desvio ou retenção indevida.

-- Relatório de Auditoria: Retenção de Dispositivos nos últimos 6 Meses
SELECT 
    R.nome_completo AS 'Responsável',
    R.departamento AS 'Departamento',
    D.categoria AS 'Tipo_Equipamento',
    COUNT(M.id_movimentacao) AS 'Total_Emprestimos_Realizados',
    MAX(M.data_evento) AS 'Última_Retirada',
    (SELECT COUNT(*) 
     FROM tbl_fluxo_movimentacao M2 
     WHERE M2.id_responsavel = R.id_responsavel 
       AND M2.tipo_movimentacao = 'SAIDA') - 
    (SELECT COUNT(*) 
     FROM tbl_fluxo_movimentacao M3 
     WHERE M3.id_responsavel = R.id_responsavel 
       AND M3.tipo_movimentacao = 'ENTRADA') AS 'Saldo_Retido_Pendente'
FROM 
    tbl_responsaveis R
INNER JOIN 
    tbl_fluxo_movimentacao M ON R.id_responsavel = M.id_responsavel
INNER JOIN 
    tbl_dispositivos D ON M.id_dispositivo = D.id_dispositivo
WHERE 
    M.tipo_movimentacao = 'SAIDA'
    AND M.data_evento >= DATE_SUB(CURRENT_DATE(), INTERVAL 6 MONTH)
    AND D.categoria IN ('NOTEBOOK', 'TABLET')
GROUP BY 
    R.id_responsavel, R.nome_completo, R.departamento, D.categoria
HAVING 
    'Saldo_Retido_Pendente' > 0
ORDER BY 
    'Saldo_Retido_Pendente' DESC, 
    'Total_Emprestimos_Realizados' DESC;

Justificativa Técnica: O uso de subqueries no SELECT permite calcular o saldo dinâmico de equipamentos não devolvidos subtraindo entradas de saídas por usuário. O filtro retroage meio ano para foco em auditorias de inventário semestral exigidas em governança de TI.

5. Gestão, Segurança e LGPD

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

O controle do projeto seguiu diretrizes ágeis, mapeando o produto através de Histórias de Usuário mensuráveis.

História de Usuário 01 - Sincronização em Background

Como um Operador de TI que trabalha em áreas sem Wi-Fi (como garagens/galpões),
Eu quero poder registrar a saída de equipamentos off-line (via localStorage),
Para que o sistema sincronize os dados com o banco MySQL automaticamente quando a internet voltar.
Critérios de Aceite: O sistema não deve travar se a requisição AJAX falhar; os registros off-line devem exibir um ícone "Aguardando Sincronismo"; após o retorno do Wi-Fi, o Service Worker deve enviar os dados em lote e limpar o localStorage.

História de Usuário 02 - Dashboard Analítico

Como um Gestor de TI,
Eu quero um painel que resuma o total de ativos e quantos estão fora da base,
Para que eu possa tomar decisões de compras de novos equipamentos baseadas em métricas reais.
Critérios de Aceite: O saldo total deve ser calculado (Total - Emprestados + Devolvidos) = Saldo Atual; gráficos visuais devem carregar em menos de 500ms na renderização da tela principal.

5.2. Conformidade com a LGPD e Privacy by Design

A plataforma gerencia nomes completos, matrículas e alocações departamentais, enquadrando-se nas obrigações da Lei Geral de Proteção de Dados (Lei nº 13.709/2018):

• Finalidade Específica (Art. 6º, I): Os dados dos colaboradores na tbl_responsaveis são utilizados apenas para o registro de acautelamento de bens corporativos.
• Auditoria vs. Direito ao Esquecimento: Caso o funcionário seja desligado, seus dados transacionais não podem ser apagados se houverem dispositivos vinculados não devolvidos. Como estratégia de Privacy by Design, os registros são bloqueados logicamente (RESTRICT na Foreign Key), assegurando que o interesse legítimo de proteção ao patrimônio prevaleça.

5.3. Cronograma do Projeto

A estimativa para a condução do Projeto Integrador foi projetada em 6 semanas de execução tática:

6. Diagramas de Visualização

A representação arquitetural foi padronizada através da linguagem Mermaid, convertendo modelos de Engenharia de Software em código compreensível.

6.1. Diagrama de Casos de Uso

Ilustra as ações centrais permitidas no escopo da aplicação de gestão de ativos.

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

6.2. Diagrama de Classes (Integração Híbrida)

Aborda a disposição de classes, com destaque para a camada de serviço responsável pelo fluxo dual (Local e Nuvem).

6.3. Diagrama de Entidade-Relacionamento (DER)

A visualização lógica das entidades que garantem o histórico do banco de dados relacional.

Fim da Documentação do Projeto Integrador (2026). O modelo arquitetural híbrido implementado prova a maturidade do sistema ao conciliar a resiliência em falhas de rede (Front-end Web Storage) com a rastreabilidade segura e escalável exigida pela governança corporativa (Back-end Relacional MySQL).