REGISTRO DOI: 10.69849/revistaft/ni10202511291611
Sérgio Mendes dos Santos Filho1
Maria Hellem Teixeira Abreu2
Resumo:
Este trabalho apresenta o desenvolvimento de um Produto Mínimo Viável (MVP) para processamento automático de arquivos XML de Conhecimento de Transporte Eletrônico (CT-e), com o objetivo de oferecer às micro e pequenas transportadoras uma solução simples e acessível para organização e análise de dados fiscais. O sistema foi construído a partir de uma arquitetura modular composta pelas camadas de entrada, extração, aplicação, persistência e visualização, empregando padrões de projeto que garantiram separação de responsabilidades e consistência no fluxo de processamento. A metodologia adotada seguiu o ciclo MVP Construir–Medir–Aprender, utilizando arquivos reais emitidos pelo sistema GDOOR-CTE. O protótipo realiza a leitura dos XML, extrai campos essenciais do documento, transforma as informações em estruturas padronizadas e as armazena em um banco de dados PostgreSQL enriquecido com dados oficiais do IBGE. Uma interface desenvolvida em Streamlit permite consultar indicadores e visualizar métricas operacionais de forma intuitiva. Testes unitários, funcionais e de integração demonstraram o correto funcionamento das camadas e confirmaram o atendimento dos requisitos definidos. Apesar das limitações relacionadas ao número reduzido de usuários para coleta de feedback, o sistema mostrou-se tecnicamente viável e capaz de transformar dados brutos de CT-e em informações úteis para a gestão logística.
Palavras-chave: CT-e; processamento de XML; banco de dados.
Abstract:
This work presents the development of a Minimum Viable Product (MVP) designed for the automatic processing of XML files from the Brazilian Electronic Transport Document (CT-e), with the aim of providing micro and small transport companies with an accessible solution for organizing and analyzing fiscal data. The system was built using a modular architecture composed of input, extraction, application, persistence, and visualization layers, supported by design patterns that ensured clear separation of responsibilities and consistency throughout the processing pipeline. The methodology followed the MVP Build–Measure–Learn cycle and used real XML documents generated by the GDORR-CTE system. The prototype reads the XML files, extracts essential CT-e fields, transforms the data into standardized structures, and stores them in a PostgreSQL relational database enriched with official IBGE data. A Streamlit-based interface allows users to explore metrics and operational indicators intuitively. Unit, functional, and integration tests confirmed the correct functioning of all components and demonstrated compliance with the defined requirements. Despite limitations related to the reduced number of users available for feedback, the system proved technically feasible and capable of converting raw CT-e data into useful information for logistical decision-making.
Keywords: CT-e; XML processing; database systems.
1 Introdução
O Conhecimento de Transporte Eletrônico (CT-e) representa um marco na digitalização dos processos logísticos brasileiros. Instituído pelo Ajuste SINIEF 09/2007, é um documento fiscal exclusivamente digital, emitido e armazenado eletronicamente para registrar prestações de serviços de transporte de cargas em todos os modais — rodoviário, ferroviário, aquaviário, dutoviário e aéreo. Sua validade jurídica é garantida pela assinatura digital do emitente e pela autorização de uso concedida pela administração tributária, substituindo os antigos documentos fiscais impressos (BRASIL, Receita Federal, 2007).
As micro e pequenas empresas (MPEs) de transporte enfrentam desafios estruturais que afetam sua competitividade e sustentabilidade. Segundo o SEBRAE (2022), cerca de 91,78% das empresas do setor são classificadas como micro e pequenas. O IBGE (2019; 2023) confirma a relevância econômica do segmento, responsável por uma parcela expressiva de empregos e pelo escoamento de bens em todo o território nacional.
Martins et al. (2011) apontam que pequenos embarcadores enfrentam limitações de escala, menor poder de barganha e custos operacionais unitários mais elevados. Além disso, restrições financeiras dificultam investimentos em tecnologias capazes de otimizar a gestão de transporte. O principal problema, portanto, está na limitada capacidade dessas empresas em processar e analisar os dados estruturados contidos nos arquivos XML dos CT-e. Para Wagner (2017), o CT-e funciona como um contrato digital entre as partes envolvidas, reunindo informações fiscais essenciais sobre as operações de transporte.
Os arquivos XML do CT-e possuem estrutura padronizada com dados sobre emitentes, destinatários, mercadorias, valores e rotas. Quando processadas corretamente, essas informações geram insights valiosos para a gestão logística e financeira. Contudo, a ausência de sistemas especializados para extração e visualização impede que as MPEs aproveitem plenamente esse potencial analítico. Parte-se da hipótese de que a integração entre algoritmos de extração XML, bancos de dados relacionais e ferramentas de visualização pode aumentar significativamente a confiabilidade e a agilidade das análises.
O processamento automatizado de documentos fiscais eletrônicos em formato XML tem se mostrado promissor para a modernização da gestão empresarial. Almeida (2002) destaca sua importância na estruturação e intercâmbio de dados, enquanto Terra et al. (2023) apontam que estratégias adequadas de tratamento da informação aprimoram o processo decisório. No contexto do transporte, Vieira (2021) evidencia que sistemas integrados favorecem a disseminação de dados e a agilidade operacional. Assim, a fundamentação teórica deste estudo apoia-se nos princípios da Ciência da Computação aplicada à gestão de documentos eletrônicos, utilizando o XML como linguagem de estruturação e bancos de dados relacionais como base para armazenamento, consulta e análise — alinhando-se às demandas contemporâneas de transformação digital no setor logístico.
1.1 Objetivos
Este trabalho visa desenvolver um Produto Mínimo Viável (MVP) capaz de processar automaticamente e visualizar dados provenientes de arquivos XML de Conhecimentos de Transporte Eletrônico (CT-e), auxiliando pequenas empresas transportadoras na análise e gestão de suas operações logísticas.
– Objetivos específicos:
(I) Implementar algoritmos para leitura, parsing e extração de dados estruturados dos arquivos XML de CT-e;
(II) Projetar uma arquitetura de banco de dados relacional para armazenamento organizado das informações extraídas;
(III) Desenvolver interfaces de visualização que facilitem a análise gerencial e o acompanhamento de indicadores logísticos.
Esses objetivos buscam demonstrar a viabilidade técnica de um protótipo funcional, passível de evolução para um sistema completo de apoio à decisão.
1.2 Justificativa
A justificativa para este estudo fundamenta-se na necessidade de democratizar o acesso a tecnologias de análise de dados para pequenas empresas de transporte, reduzindo as desigualdades competitivas do setor. O Instituto Brasileiro de Geografia e Estatística (IBGE, 2023) ressalta o papel do transporte como elemento estruturante da economia nacional, enquanto a Confederação Nacional do Transporte (CNT, 2022) enfatiza a importância da geração de informação qualificada para o desenvolvimento logístico.
Do ponto de vista tecnológico e científico, este trabalho contribui para a área de Engenharia de Software aplicada à gestão de documentos fiscais eletrônicos, ao propor um modelo de integração entre extração XML, modelagem relacional e visualização de dados. Assim, o projeto busca promover a inclusão digital e a sustentabilidade das MPEs de transporte, alinhando-se à transformação digital e ao uso inteligente de dados no contexto empresarial brasileiro.
1.3 Metodologia
O presente trabalho adota uma abordagem baseada na metodologia de Produto Mínimo Viável (MVP), integrada aos fundamentos de um projeto de software em arquitetura de camadas. Essa abordagem estrutura o processo em ciclos iterativos do tipo construir–medir–aprender, permitindo validar de forma incremental as funcionalidades do sistema e incorporar feedback contínuo dos usuários. Os procedimentos técnicos, ferramentas utilizadas e métricas de avaliação serão detalhadas na Seção 3 (Metodologia).
1.4 Seções
O artigo organiza-se nas seguintes seções: a Seção 2 apresenta a fundamentação teórica de literaturas, abordando os conceitos de CT-e, XML, bancos de dados relacionais, arquitetura de software, engenharia de requisitos; a Seção 3 descreve a metodologia de desenvolvimento adotada; a Seção 4 detalha a arquitetura e a implementação do sistema proposto; a Seção 5 expõe os resultados e a discussão crítica; e, por fim, a Seção 6 apresenta as considerações finais e as perspectivas de continuidade do projeto.
2 Fundamentação Teórica
A presente seção tem como finalidade apresentar os conceitos teóricos que embasam o desenvolvimento deste trabalho, proporcionando uma compreensão aprofundada dos fundamentos técnicos e metodológicos que sustentam a proposta de sistema. Serão abordados os princípios relacionados aos documentos fiscais eletrônicos no Brasil, às tecnologias baseadas em XML, à Engenharia de Requisitos aplicada ao contexto de desenvolvimento incremental, aos fundamentos de bancos de dados relacionais, à Arquitetura de Software, e, por fim, à Metodologia de desenvolvimento MVP (Minimum Viable Product), adotada como orientação central para o ciclo de construção e validação do sistema.
2.1 Documentos Fiscais Eletrônicos e CT-e
O processo de transformação digital da documentação fiscal brasileira tem origem na criação do Sistema Público de Escrituração Digital (SPED), instituído pelo Decreto nº 6.022/2007, que unificou os procedimentos de recepção, validação, armazenamento e autenticação de documentos contábeis e fiscais em formato eletrônico. Segundo a Receita Federal do Brasil (2007), o SPED tem por objetivo modernizar a relação entre o fisco e os contribuintes, assegurando maior transparência e eficiência nos processos de controle tributário.
Entre os projetos integrantes do SPED, destaca-se o Conhecimento de Transporte Eletrônico (CT-e), estabelecido pelo Ajuste SINIEF 09/2007, como documento de existência exclusivamente digital destinado a documentar as prestações de serviços de transporte de cargas em todos os modais, rodoviário, ferroviário, aquaviário, dutoviário e aéreo. Conforme Wagner (2017), o CT-e substitui modelos impressos tradicionais, garantindo validade jurídica por meio da assinatura digital do emitente e da autorização de uso concedida pela administração tributária.
2.2 Extensible Markup Language (XML)
A Extensible Markup Language (XML), desenvolvida pelo World Wide Web Consortium (W3C), é uma linguagem de marcação extensível projetada para estruturar, armazenar e transportar informações de maneira padronizada e legível tanto por humanos quanto por máquinas. De acordo com Almeida (2002), o XML constitui uma metalinguagem capaz de descrever outras linguagens, permitindo a definição de estruturas hierárquicas adaptáveis a diferentes domínios de aplicação.
Segundo o World Wide Web Consortium (W3C, 2025), a estrutura de um documento XML é composta por elementos, atributos e hierarquias de nós que formam uma árvore lógica de dados. Além disso, mecanismos de validação, como Document Type Definitions (DTD) e XML Schemas (XSD), garantem a integridade e consistência dos documentos, assegurando que os arquivos sigam o formato e os tipos de dados esperados.
No contexto dos documentos fiscais eletrônicos brasileiros, o XML é o padrão oficial adotado para a emissão, armazenamento e intercâmbio de informações, sendo utilizado em documentos como a Nota Fiscal Eletrônica (NF-e), o Conhecimento de Transporte Eletrônico (CT-e) e o Manifesto Eletrônico de Documentos Fiscais (MDF-e) (SEFAZ, 2025). Essa escolha tecnológica garante interoperabilidade e transparência no processo de fiscalização e gestão tributária.
2.3 Minimum Viable Product – MVP
A metodologia MVP (Minimum Viable Product), introduzida por Ries (2011) no contexto do movimento Lean Startup, propõe o desenvolvimento de produtos mínimos viáveis que possam ser rapidamente testados no mercado, possibilitando aprendizado validado e adaptação contínua. Essa abordagem tem sido amplamente incorporada à Engenharia de Software por sua capacidade de reduzir riscos e acelerar o ciclo de desenvolvimento.
Segundo Blank (2013), o MVP representa a versão inicial de um produto que contém apenas as funcionalidades essenciais para gerar valor e coletar feedback dos usuários, permitindo validar hipóteses sobre o funcionamento e a aceitação da solução. Essa metodologia fundamentase no ciclo Construir–Medir–Aprender, no qual o produto é constantemente aprimorado a partir da análise dos resultados obtidos e do retorno dos usuários.
2.4 Engenharia de Requisitos no Para MVP
A Engenharia de Requisitos é um dos pilares da Engenharia de Software, responsável pela identificação, análise e documentação das necessidades dos usuários e das restrições do sistema. Segundo Sommerville (2019), essa etapa define a base sobre a qual o software será construído, orientando o desenvolvimento para que o produto atenda às expectativas dos stakeholders e aos objetivos do negócio.
Tradicionalmente, os requisitos de software são classificados em funcionais e nãofuncionais. Os requisitos funcionais descrevem os comportamentos e serviços que o sistema deve executar, enquanto os não funcionais especificam características de qualidade, como desempenho, confiabilidade e usabilidade. Contudo, em abordagens de desenvolvimento ágil e iterativo, como a do Produto Mínimo Viável(MVP), o foco principal recai sobre os requisitos que geram valor imediato e permitem validação precoce junto ao usuário final.
Conforme Pressman e Maxim (2020), o levantamento e a priorização de requisitos em um projeto orientado a MVP devem concentrar-se nas funcionalidades essenciais — aquelas que permitem testar hipóteses e comprovar a viabilidade do produto em seu contexto real. Dessa forma, a Engenharia de Requisitos, neste trabalho, assume um papel estratégico: delimitar o escopo mínimo viável do sistema, assegurando que os recursos desenvolvidos estejam alinhados aos objetivos principais e possam ser avaliados iterativamente.
2.5 Banco de dados Relacional
Os bancos de dados relacionais constituem o principal mecanismo de persistência e organização de informações em sistemas de software. De acordo com Codd (1970), o modelo relacional organiza os dados em tabelas bidimensionais, chamadas de relações, compostas por tuplas (linhas) e atributos (colunas). Essa estrutura permite manipulação por meio de operações matemáticas, garantindo integridade e consistência das informações.
Date (2004) descreve os bancos de dados como “salas de arquivos eletrônicas” que oferecem independência entre os dados e as aplicações que os utilizam, enquanto Elmasri e Navathe (2011) destacam que um Sistema Gerenciador de Banco de Dados (SGBD) tem como objetivo principal controlar o acesso concorrente, manter a integridade dos dados e assegurar a recuperação em caso de falhas.
No contexto deste trabalho, a adoção de um Sistema Gerenciador de Banco de Dados Relacional (SGBDR), é justificada pela natureza estruturada dos dados provenientes dos arquivos XML do CT-e, que podem ser convertidos em entidades relacionais — como emitentes, destinatários, valores e cargas. A normalização, conforme Elmasri e Navathe (2011), é essencial para reduzir redundâncias, evitar anomalias de inserção e exclusão e preservar a integridade referencial.
Além disso, a utilização de consultas SQL (Structured Query Language) possibilita a recuperação e análise eficiente das informações, permitindo a geração de relatórios e indicadores logísticos. Segundo Silberschatz, Korth e Sudarshan (2020), o SQL é a linguagem padrão para manipulação de dados relacionais, oferecendo flexibilidade e desempenho na execução de consultas complexas.
2.6 Arquitetura de Software e Paradigma em Camadas
A arquitetura de software constitui o fundamento estrutural de um sistema computacional, compreendendo os seus componentes essenciais, as inter-relações entre eles e os princípios que norteiam o seu desenvolvimento e evolução. De acordo com Sommerville (2019), a definição de uma arquitetura adequada estabelece a base sobre a qual se sustentam todas as decisões de projeto, assegurando a coerência entre os módulos e promovendo a manutenibilidade e a escalabilidade do sistema. Trata-se, portanto, de um elemento central da Engenharia de Software, cuja função transcende o âmbito técnico e alcança o plano conceitual, na medida em que traduz requisitos abstratos em estruturas concretas e operacionais.
Para Pressman e Maxim (2020), a arquitetura de software desempenha o papel de elo entre o planejamento e a implementação, funcionando como um modelo de referência que orienta o desenvolvimento e viabiliza a comunicação entre projetistas, desenvolvedores e demais partes interessadas. Ao delimitar fronteiras de responsabilidade entre os componentes e definir interfaces claras de interação, a arquitetura contribui para a clareza estrutural do sistema, favorecendo sua extensibilidade, reutilização e confiabilidade. Assim, configura-se como instrumento essencial para o controle da complexidade inerente aos sistemas modernos.
Entre os diversos estilos arquiteturais descritos na literatura, o paradigma em camadas (layered architecture) destaca-se por sua capacidade de promover modularidade e separação de responsabilidades, princípios fundamentais à sustentabilidade de sistemas de médio e grande porte (BASS; CLEMENTS; KAZMAN, 2021). Nesse modelo, as funcionalidades são organizadas em níveis hierárquicos, nos quais cada camada desempenha um conjunto específico de funções e interage com as demais por meio de interfaces bem definidas. Tal organização reduz o acoplamento entre os módulos e assegura elevada coesão interna, permitindo que o sistema evolua de forma controlada e previsível.
No contexto deste trabalho, a adoção desse paradigma revela-se especialmente pertinente, uma vez que o sistema desenvolvido requer a integração harmoniosa de processos distintos — como a extração, transformação e persistência de dados oriundos de documentos fiscais eletrônicos. A estrutura em camadas oferece os mecanismos necessários para que essas operações sejam executadas de maneira independente e coordenada, garantindo estabilidade, integridade e adaptabilidade ao longo das fases de desenvolvimento. Além disso, a natureza incremental da arquitetura alinha-se aos princípios da metodologia MVP (Minimum Viable Product), que privilegia a entrega contínua de valor e a validação progressiva das funcionalidades essenciais.
2.7 Extract, Transform and Load (ETL)
O processo de ETL, Extract, Transform, Load (Extração, Transformação e Carga), representa uma das etapas centrais na integração e preparação de dados para análise em ambientes de apoio à decisão, como Data Warehouses e Data Lakes. Conforme descrito por Kimball e Ross (2011), o ETL constitui um pipeline de dados responsável por coletar informações de múltiplas fontes, tratá-las segundo as regras e necessidades do negócio e, por fim, armazená-las de forma estruturada em um repositório centralizado, viabilizando consultas, relatórios e análises estratégicas.
No contexto do Sistema de Análise de Conhecimentos de Transporte Eletrônico, o processo de ETL viabiliza a integração eficiente entre as etapas de extração e visualização, permitindo transformar dados operacionais dispersos em informações organizadas, confiáveis e prontas para apoiar decisões estratégicas no setor de transporte.
2.8 Padrões de Design
Os padrões de projeto representam soluções consolidadas para problemas recorrentes no âmbito do desenvolvimento de software, constituindo um repertório de abordagens estruturais, criacionais e comportamentais que visam otimizar a organização e a reutilização do código. De acordo com Gamma et al. (1995), os padrões de projeto descrevem formas comprovadamente eficazes de composição e interação entre classes e objetos, proporcionando um vocabulário comum que favorece a comunicação entre projetistas e desenvolvedores, além de promover a manutenibilidade e a extensibilidade das aplicações.
Entre os diversos padrões de projeto descritos na literatura, três assumem papel central no presente trabalho: o Factory, o Facade e o Strategy. O padrão Factory, classificado como criacional, tem por objetivo abstrair o processo de criação de objetos, centralizando a lógica de instanciação e evitando a dependência direta de classes concretas. Conforme Gamma et al. (1995), essa abordagem promove a independência entre a estrutura interna de um objeto e o código que o utiliza, viabilizando a extensão do sistema sem necessidade de modificações substanciais. No contexto deste projeto, tal padrão é aplicado à geração das entidades correspondentes aos elementos do Conhecimento de Transporte Eletrônico (CT-e), assegurando que novas estruturas possam ser incorporadas sem comprometer a integridade da aplicação.
O padrão Facade, por sua vez, classificado como estrutural, estabelece uma interface unificada para o acesso a um subsistema complexo. Segundo os autores supracitados, esse padrão simplifica a interação com conjuntos de classes interdependentes, reduzindo a complexidade percebida pelos módulos externos.
O padrão Strategy, pertencente à categoria de padrões comportamentais descritos por Gamma et al. (1995). Esse padrão permite definir uma família de algoritmos, encapsulá-los e torná-los intercambiáveis em tempo de execução, favorecendo a extensão e a flexibilidade do sistema sem necessidade de modificar seu núcleo.
A utilização combinada dos padrões Factory, Facade e Strategy neste projeto reforça a robustez estrutural e a clareza conceitual do sistema, garantindo baixo acoplamento e alta coesão entre os módulos de extração e persistência. Além disso, tal abordagem assegura alinhamento com os princípios arquiteturais em camadas e com a metodologia MVP, na medida em que favorece a evolução incremental e o aprimoramento contínuo das funcionalidades essenciais.
2.9 Biblioteca tkinter
A biblioteca Tkinter oferece suporte nativo à manipulação de arquivos e diretórios locais por meio do submódulo tkinter.filedialog, permitindo ao desenvolvedor implementar facilmente caixas de diálogo padrão para seleção de arquivos (open/save) ou pastas no sistema operacional do usuário. Essa funcionalidade torna-se fundamental em aplicações que processam ou manipulam dados oriundos de arquivos locais, pois elimina a necessidade de o usuário informar manualmente o caminho do recurso desejado, além de garantir maior usabilidade e flexibilidade à solução desenvolvida.(PYTHON, 2025).
No contexto do desenvolvimento científico e acadêmico, tais recursos facilitam a integração com fluxos de importação/exportação de dados, seleção de fontes em formatos padronizados (como XML) e manipulação automatizada de grandes volumes de arquivos. O uso dessas ferramentas eleva o grau de interação do sistema, tornando-o apto para aplicações modernas e adaptadas às melhores práticas de ergonomia e acessibilidade
2.10 Biblioteca ElementTree
A biblioteca xml.etree.ElementTree (ElementTree) é um módulo padrão do Python que implementa uma API simples e eficiente para análise, manipulação e criação de documentos XML. O processo típico de uso do ElementTree envolve o carregamento do arquivo XML por meio da função parse(), que gera um objeto do tipo ElementTree representando toda a estrutura do documento. A raiz da árvore, elemento principal do XML, é acessada através do método getroot(). A partir disso, é possível navegar, buscar e modificar elementos utilizando métodos como find(), findall() e iter(), que permitem recuperar elementos por nome, caminho ou condição, bem como modificar textos e atributos, facilitando a manipulação programática de dados XML complexos.(PYTHON, 2025).
Em síntese, a biblioteca xml.etree.ElementTree possibilita uma manipulação eficiente e programática de XML integrada ao ecossistema Python, tornando-se ferramenta fundamental para o desenvolvimento de sistemas que demandam interação com documentos eletrônicos estruturados.
2.11 Biblioteca Pytest
A biblioteca pytest constitui um robusto framework de teste desenvolvido para a linguagem Python, cuja principal proposta é favorecer a criação de testes unitários, funcionais e de integração de maneira eficiente e expressiva. Fundamentada em princípios de clareza sintática e mínima necessidade de código repetitivo, pytest permite que casos de teste sejam definidos como funções, dispensando o emprego de complexas estruturas de classes, como ocorre em frameworks tradicionais. O mecanismo de asserção nativo facilita a verificação de resultados esperados através da palavra-chave assert, conferindo máxima transparência e legibilidade às atividades de validação.(PYTEST, 2025).
Outro aspecto fundamental reside na gestão modular e escalável do contexto dos testes por meio das chamadas fixtures. Essas estruturas facultam a configuração, reutilização e isolamento dos ambientes para execução de testes, promovendo a organização e a redução de redundância, sobretudo em projetos de maior porte. A funcionalidade de parametrização, por sua vez, propicia a avaliação sistemática de diferentes cenários e entradas, corroborando para o incremento da abrangência e confiabilidade do conjunto de testes.(PYTEST, 2025).
Por fim, cumpre destacar o potencial de extensibilidade do pytest, viabilizado por um amplo ecossistema de plugins, bem como a inteligência do seu sistema de descoberta automática de testes, ancorada em convenções de nomenclatura e estrutura de diretórios. Tais características fazem do pytest uma ferramenta alinhada aos preceitos do desenvolvimento e à busca incessante por qualidade e manutenção contínua do software.
2.12 Biblioteca Streamlit
Streamlit é uma biblioteca open-source escrita em Python, desenvolvida para permitir a criação ágil de aplicativos web interativos focados em dados e aprendizado de máquina. Sua arquitetura é baseada na execução sequencial de scripts, em que cada interação do usuário com widgets dispara uma nova execução do código, garantindo que o estado da aplicação e as visualizações sejam sempre atualizados conforme as entradas do usuário. Os componentes de interface, como botões, sliders, caixas de seleção e formulários, são integrados de maneira declarativa, tornando a experiência de desenvolvimento acessível até mesmo para profissionais sem conhecimento em front-end. (STREAMLIT, 2025).
O gerenciamento de estado em Streamlit é essencial para manter a interatividade e a continuidade das sessões dos usuários, permitindo que variáveis e inputs sejam preservados durante toda a navegação na aplicação. Além disso, o sistema de cache otimiza o desempenho, armazenando dados e resultados de funções que não mudam com frequência, evitando computações desnecessárias. Essa abordagem favorece o desenvolvimento de painéis analíticos, dashboards e ferramentas de exploração de dados de alto desempenho, sobretudo em ambientes onde o acesso a fontes externas e a manipulação de grandes volumes de dados são constantes. (STREAMLIT, 2025).
Portanto, Streamlit destaca-se no cenário contemporâneo por democratizar o desenvolvimento de soluções de ciência de dados, facilitando a prototipagem rápida de interfaces analíticas e permitindo o compartilhamento ágil de conhecimento e aplicações funcionais. Seu conjunto de recursos e princípios arquiteturais atende tanto a cientistas de dados quanto a desenvolvedores, impulsionando a inovação e a acessibilidade na área de visualização e manipulação de dados em tempo real.
3 Metodologia
No contexto deste estudo, o método MVP será aplicado ao desenvolvimento de um sistema voltado ao processamento automatizado de arquivos XML de Conhecimento de Transporte Eletrônico (CT-e), com o propósito de comprovar a viabilidade técnica da solução e sua aplicabilidade à gestão logística de dados fiscais. Considerando as limitações temporais inerentes à execução desta pesquisa, optou-se pela realização de um ciclo completo do processo MVP, suficiente para validar a arquitetura proposta, medir o desempenho do protótipo e extrair aprendizados aplicáveis a iterações futuras.
O ciclo será estruturado em três fases interdependentes. A fase Construir abrangerá o levantamento e modelagem dos requisitos, a definição da arquitetura e a implementação do protótipo mínimo viável. A fase Medir consistirá na execução de testes de software e na coleta de métricas de desempenho, com vistas a avaliar a eficiência e a estabilidade do sistema. Por fim, a fase Aprender envolverá a análise dos resultados, a identificação de melhorias e a consolidação do aprendizado obtido a partir da experiência experimental. Essa estrutura metodológica assegurou coerência entre o planejamento teórico e a execução prática, em consonância com os princípios da Engenharia de Software e com as práticas de desenvolvimento ágil orientado a evidências.
Para o desenvolvimento e validação do sistema proposto, serão utilizados arquivos XML de Conhecimento de Transporte Eletrônico (CT-e) coletados diretamente do sistema emissor GDOOR-CTE, pertencente à empresa J M Transporte de Cargas EIRELI. A coleta dos documentos será realizada de forma contínua, abrangendo o período de outubro de 2024 a outubro de 2025, assegurando a representatividade dos dados reais do processo de emissão fiscal e permitindo a análise de diferentes cenários operacionais e layouts de documento. Essa base de dados servirá de referência tanto para a modelagem e desenvolvimento das camadas do sistema quanto para os testes de validação e desempenho descritos nas seções subsequentes.
3.1 Construir
A fase Construir abrangerá da modelagem e levantamento de requisitos à definição arquitetural e à implementação do protótipo mínimo viável, com o propósito de materializar a proposta em uma solução operacional capaz de ler, validar, transformar e armazenar, para que seja possível a visualização dos dados provenientes de arquivos XML de CT-e.
3.1.1 Modelagem e Levantamento de Requisitos
O levantamento e a modelagem de requisitos serão conduzidos segundo princípios da Engenharia de Requisitos, a partir de duas fontes primárias: (i) os schemas XML oficiais, que definem estrutura, tipos e regras de validação; e (ii) o corpus de XML reais, disponibilizados mensalmente por sistemas emissores e organizados em lotes. A análise conjunta dessas fontes permitiu identificar entidades e relacionamentos essenciais e derivar o conjunto mínimo de requisitos funcionais e não funcionais, necessários para orientar a construção do MVP, os requisitos serão devidamente rastreados nas seções 4 e 5.
3.1.2 Arquitetura
A arquitetura do sistema será estruturada em cinco camadas logicamente independentes e integradas por contratos bem definidos, favorecendo modularidade, testabilidade e evolução incremental:
(I) Camada de Upload (Interface): ponto de entrada do sistema, responsável pela seleção e importação de arquivos XML em lote, implementada com a biblioteca Tkinter. Padroniza diretórios de trabalho e aciona o fluxo de processamento sem acoplar regras de domínio.
(II) Camada de Extração: núcleo de leitura e validação dos documentos CT-e. Utiliza os padrões de projeto Factory, Facade e Strategy para instanciação, unificação e alternância de estratégias de parsing e cache, além de validação sintática e semântica conforme os schemas oficiais.
(III) Camada de Aplicação (Parsing/Orquestração): realiza a transformação semântica e a orquestração do fluxo ETL. Normaliza campos, trata exceções e consolida estruturas prontas para persistência, registrando métricas operacionais do processamento.
(IV) Camada de Persistência: gerencia a conectividade com o banco de dados e o modelo relacional, controlando transações, chaves e integridade referencial. Armazena os dados transformados em estruturas normalizadas, garantindo consistência e disponibilidade para análise.
(V) Camada de Visualização: apresenta de forma clara e interativa as informações processadas, convertendo dados em painéis, gráficos e indicadores que apoiam a análise e a tomada de decisão. Atua como interface final entre o usuário e o sistema, consolidando o valor informacional do processo.
3.1.3 Modelagem e Enriquecimento do Banco com Dados Complementares
A modelagem do banco de dados é derivada de um mapeamento sistemático das estruturas do XSD do CT-e para o paradigma relacional, seguindo princípios de normalização e integridade referencial. Procedeu-se, inicialmente, à identificação das entidades nucleares e respectivos atributos canônicos, preservando chaves de negócio quando relevantes e adotando chaves substitutas para uniformidade e desempenho. Regras de domínio foram traduzidas em restrições de integridade, chaves estrangeiras e verificações, reduzindo anomalias de inserção/atualização.
A racionalidade do enriquecimento residirá no fato de que o XML do CT-e, embora rico, não esgota os atributos necessários à boa governança de dados e à inteligência gerencial. O vínculo com referenciais oficiais (IBGE) eleva a integridade semântica e a capacidade de agregação por territórios; o cadastro ampliado de veículos sustenta análises de desempenho e conformidade; e as métricas derivadas (como a quilometragem) viabilizam indicadores logísticos de uso cotidiano, sem adulterar os dados de origem. Para isolar fluxos, recomenda-se a adoção de schemas lógicos (e.g., ref para referenciais; core para entidades operacionais; cte para fatos do CT-e), preservando organização e evolução.
Com o fim da etapa Construir, inicia-se a etapa Medir, que será responsável pela coleta de métricas em testes e em feedback de usuário.
3.2 Medir
A fase Medir terá como finalidade avaliar o protótipo mínimo viável a partir de critérios técnicos e operacionais, obtendo evidências quantitativas e qualitativas sobre seu desempenho e aderência aos requisitos estabelecidos. Essa etapa será conduzida de modo empírico e controlado, abrangendo testes automatizados, coleta de métricas de desempenho, e o desenvolvimento de um painel de visualização voltado à interpretação dos resultados e ao feedback do usuário.
3.2.1 Testes e Instrumentação
Os testes serão estruturados em três níveis complementares:
(I) Testes unitários, voltados à verificação das funções críticas de leitura, validação e persistência de dados;
(II) Testes funcionais, destinados à execução de fluxos completos de importação e processamento de lotes de XML;
(III) Testes de integração, responsáveis por avaliar a interoperabilidade entre as cinco camadas (upload, extração, parsing/aplicação, persistência e visualização).
O ambiente de teste utilizará um corpus real de arquivos XML correspondentes a lotes mensais de emissão, incluindo amostras válidas e inválidas segundo os schemas da SEFAZ. Durante a execução, o sistema será instrumentado para registrar automaticamente eventos, tempos de execução, uso de recursos e métricas por etapa, permitindo reprodutibilidade e comparação entre execuções.
3.2.2 Métricas de Avaliação
As métricas serão definidas para quantificar a eficiência, a confiabilidade e a completude do processo ETL, contemplando tanto os módulos centrais quanto o enriquecimento de dados. Entre os principais indicadores avaliados, destacam-se:
(I) Tempo médio de processamento por documento (ms/doc) e throughput (documentos/minuto);
(II) Taxa de sucesso na extração, medida pela proporção de XMLs processados sem erro de schema ou inconsistência de dados;
(III) Cobertura de campos obrigatórios, representando o percentual de elementos XML corretamente extraídos e mapeados para o modelo relacional;
Essas métricas serão consolidadas por lote, camada e execução, permitindo a identificação de gargalos específicos e o acompanhamento da eficiência geral do sistema ao longo dos testes.
3.2.3 Visualização e feedback do usuário
Com o propósito de facilitar a interpretação dos resultados e promover o aprendizado validado, será desenvolvido um painel de visualização interativo (dashboard). Esse painel consolidará as principais métricas de desempenho e integridade do sistema, apresentando-as em formato gráfico e dinâmico, de modo a permitir a análise rápida e intuitiva dos resultados obtidos nas execuções do protótipo.
O painel incluirá um mecanismo simplificado de feedback do usuário, destinado à coleta de avaliações qualitativas quanto à clareza das informações e à utilidade prática do sistema. Esse retorno qualitativo, aliado aos indicadores quantitativos obtidos, servirá de subsídio direto para a fase Aprender, permitindo identificar oportunidades de melhoria técnica e ajustes metodológicos.
Concluída a etapa Medir, inicia-se a fase Aprender, responsável pela análise integrada dos dados coletados e pela definição de aprimoramentos a serem incorporados em ciclos futuros de desenvolvimento.
3.3 Aprender
A fase Aprender corresponderá à etapa de interpretação e análise crítica dos resultados obtidos na fase medir, com o propósito de extrair conhecimento aplicável ao aprimoramento técnico e metodológico do sistema. Essa fase consolida o fechamento do ciclo Construir–Medir– Aprender preconizado pela metodologia MVP, assegurando que o desenvolvimento do software ocorra de forma iterativa e orientada por evidências.
A consolidação dos resultados obtidos permitirá validar as hipóteses iniciais deste estudo: é possível desenvolver, com recursos acessíveis e arquitetura modular, um sistema capaz de processar e enriquecer dados de CT-e de forma automatizada e confiável, agregando valor à gestão de informações logísticas e fiscais. O aprendizado extraído deste ciclo fornecerá base sólida para futuras versões do sistema.
Dessa forma, a fase Aprender encerrará o primeiro ciclo metodológico do MVP, evidenciando que o protótipo desenvolvido atingiu os objetivos propostos e consolidando as diretrizes para sua evolução futura. A experimentação conduzida pretende demonstrar a efetividade da metodologia aplicada e reforçou a importância do aprendizado validado como instrumento de aprimoramento contínuo em projetos de software baseados em dados fiscais eletrônicos.
4 Desenvolvimento do Software
4.1 Requisitos
A definição dos requisitos teve como objetivo assegurar que o sistema atendesse de forma eficiente às necessidades apresentadas na metodologia (veja seção 3), priorizando a automação do processamento de documentos fiscais eletrônicos e a disponibilização de dados gerenciais para fins de análise logística.
A Tabela 1 apresenta o conjunto de requisitos definidos para o sistema, servindo de base para o desenvolvimento, validação e posterior rastreabilidade na implementação.
Tabela 1 – Tabela de Requisitos
| Código | Tipo | Descrição |
| RF1 | Funcional | Importar e validar arquivos XML de Conhecimento de Transporte Eletrônico (CT-e) conforme schemas oficiais da SEFAZ. |
| RF2 | Funcional | Realizar Leitura, o parsing e a extração dos dados estruturados presentes nos documentos XML. |
| RF3 | Funcional | Armazenar os dados extraídos em um banco de dados relacional PostgreSQL, garantindo integridade e consistência |
| RF4 | Funcional | Enriquecer as informações com dados complementares provenientes do IBGE (UFs e Municípios) e do cadastro de veículos. |
| RF5 | Funcional | Calcular e registrar a quilometragem aproximada com base em parâmetros informados pelo usuário |
| RF6 | Funcional | Disponibilizar interface de visualização simplificada e desenvolvida em Steamlit, para exibição de métricas e coleta de feedback do usuário. |
| RNF1 | Não Funcional | Garantir tempo médio de processamento inferior a 3 segundos por documento em ambiente de teste. |
| RNF2 | Não Funcional | Assegurar modularidade e manutenibilidade do código por meio da arquitetura em camadas e dos padrões de projeto aplicados (Factory, Facade e Strategy). |
Esses requisitos compõem o escopo mínimo do produto viável e orientaram o desenvolvimento incremental do sistema conforme os princípios da metodologia MVP.
4.2 Ferramentas e Frameowrk
O sistema foi desenvolvido em Python 3.12, utilizando ferramentas que sustentam cada etapa do pipeline de processamento. A interface de upload dos arquivos XML foi implementada com a biblioteca Tkinter, fornecendo um meio simples e nativo para seleção dos documentos. A extração dos dados utilizou a biblioteca padrão xml.etree.ElementTree, enquanto a manipulação de diretórios e arquivos baseou-se em os e pathlib. A integração com o banco de dados PostgreSQL foi realizada com psycopg2, e a organização dos dados para visualização contou com o uso de pandas. Por fim, o framework Streamlit foi empregado para construção da interface de visualização. O desenvolvimento foi conduzido em Visual Studio Code, com versionamento via Git e repositório no GitHub, garantindo controle de versão e reprodutibilidade.
4.3 Modelagem do Banco de Dados
O modelo relacional implementado no banco PostgreSQL foi estruturado em quatro esquemas principais: staging, core, cte e ibge. O esquema staging funciona como área temporária de recepção dos arquivos brutos, armazenando o conteúdo JSON dos documentos CT-e recebidos antes da validação e transformação. O esquema core concentra os cadastros mestres, como pessoas, endereços e veículos, assegurando reutilização e integridade referencial entre diferentes documentos.
O esquema cte representa o núcleo transacional do sistema, contendo as tabelas documento, carga e documento_parte, responsáveis por armazenar as informações fiscais e logísticas extraídas dos arquivos XML. A tabela documento mantém os dados principais do CT-e (chave, série, número, valores, data de emissão, municípios de origem e destino, e veículo utilizado), enquanto carga e documento_parte armazenam, respectivamente, os detalhes da mercadoria e a identificação dos participantes da operação (emitente, remetente, destinatário e tomador).
O esquema ibge contém as tabelas uf e município, utilizadas para o enriquecimento geográfico dos dados e integradas por meio do identificador id_uf. Essas tabelas são alimentadas automaticamente pelo módulo ibge_loader.py, garantindo conformidade com as bases oficiais do Instituto Brasileiro de Geografia e Estatística (IBGE). A figura 1, anexada abaixo, mostra o diagrama de Entidade-Relacionamento (ER) do banco de dados.
Figura 1 – Diagrama ER do banco
4.3.1 Enriquecimento do Banco com Dados Complementares
O processo de enriquecimento do banco de dados tem como objetivo complementar as informações extraídas dos arquivos XML de Conhecimento de Transporte Eletrônico (CT-e) com dados externos, de modo a ampliar o potencial analítico e garantir maior consistência nas consultas e relatórios gerenciais., para atender o RF5 (veja seção 4.1) Para isso, foram incorporadas três principais fontes de enriquecimento: informações geográficas oficiais do IBGE, cadastro de veículos e estimativas de quilometragem aproximada percorrida.
No primeiro caso, os dados de Unidades da Federação (UFs) e Municípios foram obtidos diretamente por meio das APIs públicas do Instituto Brasileiro de Geografia e Estatística (IBGE), que disponibilizam a divisão político-administrativa oficial do território brasileiro em formato estruturado e atualizado. Essas informações são essenciais para relacionar corretamente os municípios de origem e destino das operações de transporte descritas nos CT-es, permitindo análises geográficas e estatísticas mais precisas.
A origem dessas informações está definida diretamente no código do módulo ibge_loader.py, conforme apresentado a seguir:
Exemplo 1 – Importando os links do diretório do IBGE
Essas URLs correspondem às interfaces oficiais mantidas pelo IBGE, que fornecem dados atualizados em formato JSON. O módulo ibge_loader.py consome essas APIs, processa as respostas e realiza a inserção dos registros nas tabelas ibge.uf e ibge.municipio, assegurando a integridade das chaves primárias e o relacionamento entre as unidades federativas e seus municípios. O trecho a seguir exemplifica a lógica utilizada para inserção e atualização controlada desses registros:
Exemplo 2 – Função de inserção de municípios e UFs
Esse procedimento garante que o banco permaneça constantemente sincronizado com as informações oficiais, permitindo a atualização automática em caso de reorganizações territoriais ou mudanças de nomenclatura. Além disso, a normalização textual aplicada ao campo nome assegura consistência semântica entre consultas e registros.
Complementarmente, o banco de dados foi enriquecido com o cadastro de veículos utilizados nas operações de transporte, incluindo informações como placa, marca, ano de fabricação, chassi e cor. Essa estrutura permite relacionar cada CT-e a um veículo específico, viabilizando análises sobre desempenho e distribuição logística. A tabela também contempla veículos que não estão mais em posse do usuário, sendo preenchidos somente o campo da numeração da placa que forem extraídas dos documentos.
Por fim, foi implementada uma métrica de quilometragem aproximada, calculada com base na distância estimada entre os municípios de origem e destino, complementada por um valor de referência informado pelo usuário, que remete a quantidade ganha por quilômetro, que será inserida na seguinte equação: KMaprox = Valorfrete/R$km. Essa abordagem, por mais que não seja totalmente precisa, consegue fornecer uma informação que é de extrema importância para a análise. É importante que tal métrica seja revisada em ciclos posteriores para atingir maior precisão dos dados quando forem analisados.
Finalmente, tem-se o banco modelado, estruturado e enriquecido com informações complementares, a seguir, na seção 4.4, será apresentada toda a arquitetura em que o sistema foi desenvolvido.
4.4 Arquitetura do Software
A arquitetura do sistema foi estruturada de forma modular e hierárquica, organizada em cinco camadas funcionais, Upload, Extração, Aplicação, Persistência e Visualização (veja seção 3), que refletem o fluxo lógico do processamento dos arquivos XML de Conhecimento de Transporte Eletrônico (CT-e). Essa organização busca garantir a separação de responsabilidades, facilitar a manutenção do código e permitir a evolução incremental do software, mantendo baixo acoplamento entre os módulos, para atender o RNF2 (veja seção 4.1).
O modelo em camadas foi adotado por sua aderência a sistemas orientados a dados e por corresponder ao ciclo natural do pipeline de tratamento dos CT-es. Cada camada executa uma etapa específica do processo de extração, transformação e análise das informações fiscais, favorecendo a escalabilidade e a possibilidade de inclusão de novas funcionalidades sem reestruturação do núcleo do sistema.
O fluxo de execução é unidirecional, partindo da entrada dos arquivos e seguindo até a visualização dos resultados, o que reduz o acoplamento e aumenta a previsibilidade do sistema. Essa estrutura modular permite que cada camada seja testada e aprimorada de forma independente, preservando a coerência arquitetural e a estabilidade geral do software.
A Figura 2 apresenta a representação esquemática da arquitetura em camadas do SOFTWARE.
Figura 2 – Arquitetura do Software
Com a arquitetura definida, inicia-se a fase de implementação do protótipo, aonde ele de fato é construído, na seção a seguir, será feita toda a documentação, como cada camada foi de fato implementada.
4.5 Documentação das Camadas Implementadas
A presente seção tem como objetivo apresentar como as camadas cidatas na seção anterior foram implementadas e quais soluções foram desenvolvidas para cada uma delas, apresentado trechos do código-fonte que foi desenvolvido.
Todos os exemplos de código citados neste e nos módulos a seguir da seção 4, foram referências do código-fonte e de suas respectivas documentações, que estão presentes em: https://github.com/Sergiosmf/SACT.git.
4.5.1 Camada de Upload (file_manager)
A camada de Upload constitui o ponto inicial do fluxo de processamento. Seu principal objetivo é permitir que o usuário selecione e envie, de forma prática, os arquivos XML de Conhecimento de Transporte Eletrônico (CT-e) a serem processados, para atender ao RF1 (veja seção 4.1).
Essa interface foi implementada no módulo file_manager.py, utilizando a biblioteca Tkinter, nativa do Python, escolhida por sua simplicidade e leve integração com sistemas de desktop. O módulo realiza a varredura de diretórios locais, possibilita a seleção de múltiplos arquivos XML e armazena as referências selecionadas em memória, encaminhando-as diretamente para a camada de Aplicação, onde ocorre a orquestração do processamento.
O design dessa camada privilegia a usabilidade e o isolamento funcional: o usuário interage apenas com a interface gráfica, enquanto as operações internas de validação e encaminhamento são executadas de forma automatizada, reduzindo a possibilidade de erro manual e garantindo que somente arquivos válidos sejam enviados ao pipeline.
Exemplo 3 – file_manager.py
Além da função de seleção, o módulo implementa métodos auxiliares para verificação de diretórios e filtragem de arquivos, assegurando que apenas documentos com extensão válida (.xml) sejam encaminhados. A camada de Upload mantém-se independente das regras de negócio, atuando apenas como intermediária entre o usuário e o sistema, em conformidade com o princípio de separação de responsabilidades da arquitetura em camadas, atendendo ao RF1.
Na seção a seguir será descrita a camada de extração, camada essa responsável por toda a lógica de extração de dados XML.
4.5.2 Camada de Extração (cte_extractor)
A camada deExtração constitui o núcleo funcional do sistema, sendo responsável pela leitura, validação e conversão dos arquivos XML de Conhecimento de Transporte Eletrônico (CT-e) em estruturas de dados compreensíveis pelas camadas superiores, para atender ao RF2, (veja seção 4.1).
Essa camada foi implementada dentro do pacote cte_extractor e projetada segundo princípios de baixo acoplamento e alta coesão, incorporando três padrões de projeto clássicos: Factory, Strategy e Facade. Essa combinação assegura flexibilidade e extensibilidade, permitindo que novas versões de layout do CT-e sejam incorporadas sem impacto sobre o restante do sistema.
O padrãoFactory, implementado no módulo factory.py, é responsável pela criação dinâmica dos parsers conforme a versão do layout XML. Ele identifica automaticamente o schema do documento e instancia o parser adequado, abstraindo a complexidade da escolha e garantindo compatibilidade entre versões.
Exemplo 4 – factory.py
O método create_from_file() identifica a versão do layout e retorna dinamicamente o parser correspondente, permitindo que novas versões sejam adicionadas ao sistema sem alteração estrutura.
O padrão Strategy, definido no módulo strategies.py, fornece um conjunto de estratégias intercambiáveis para validação sintática e semântica dos arquivos XML. Cada estratégia é encapsulada em uma classe específica, permitindo alterar o comportamento de validação sem modificar a lógica principal do programa.
Exemplo 5 – strategies.py
Nesse exemplo, a classe SemanticValidation implementa a verificação de campos obrigatórios, assegurando que todos os elementos essenciais do CT-e estejam devidamente preenchidos.
Por fim, o padrão Facade, materializado em facade.py, atua como interface unificada para toda a camada, encapsulando as operações de parsing, validação e tratamento de exceções. Essa abordagem simplifica o uso dos módulos internos e fornece à camada de Aplicação uma interface única para o processamento dos arquivos XML.
Exemplo 6 – facade.py
O método process_file() integra os padrões Factory e Strategy, instanciando o parser adequado e aplicando a validação correspondente, retornando os dados em formato estruturado.
Além desses módulos, a camada de Extração também inclui:
(I) extractors.py, que define as classes responsáveis pela leitura dos blocos XML e extração de elementos como emitente, destinatário, valores e tributos
(II) models.py, que descreve os objetos de domínio intermediários utilizados no pipeline de transformação;
(III) exceptions.py, que centraliza o tratamento de erros e inconsistências de schema;
(IV) utils.py, que oferece funções auxiliares de manipulação e normalização dos nós XML.
Esta camada é responsável por transformar dados brutos e heterogêneos em estruturas padronizadas, reduzindo a complexidade do processamento e garantindo conformidade com os layouts oficiais da SEFAZ. O resultado desse processamento é encaminhado à camada de Aplicação, que realiza a orquestração do fluxo e o armazenamento dos dados.
A implementação reforça os princípios de abstração e modularidade, essenciais para a escalabilidade e a manutenção do sistema, além de representar uma aplicação prática dos fundamentos de Engenharia de Software em um contexto real de processamento de documentos fiscais eletrônicos.
Na seção a seguir, como foi solucionada a camada de persistência e a lógica de inserção.
4.5.3 Camada de Persistência (config e database_manager)
A camada de Persistência é responsável pela gestão e integridade das informações armazenadas no banco de dados relacional PostgreSQL, assegurando que os dados extraídos dos arquivos XML de CT-e sejam gravados de forma estruturada, consistente e segura, para atender RF3 e RF4 (veja seção 4.1).
Essa camada consolida as operações de armazenamento, atualização e recuperação de registros, além de encapsular toda a lógica de conexão com o banco, garantindo o isolamento total entre as camadas de aplicação e de infraestrutura.
Sua implementação é composta principalmente pelos módulos database_config.py e database_manager.py, que centralizam, respectivamente, a configuração de acesso e as operações de manipulação de dados.
O módulo ibge_loader.py, que realiza o enriquecimento do banco com dados complementares de unidades federativas e municípios obtidos diretamente das APIs do IBGE, já foi detalhado na Seção 4.2.1 (Enriquecimento do Banco com Dados Complementares).
O módulo database_config.py define os parâmetros de conexão com o banco e inicializa o connection pool, permitindo múltiplas conexões simultâneas de forma eficiente e controlada. Esse módulo abstrai detalhes técnicos de infraestrutura, oferecendo funções reutilizáveis para as demais partes do sistema.
Exemplo 7 – Inicialização da conexão com o banco de dados (database_config.py)
O módulo database_config.py centraliza a configuração de acesso e controla o pool de conexões, promovendo eficiência e reuso. Essa abordagem evita a reconexão constante ao banco, reduzindo a sobrecarga de processamento.
O módulo database_manager.py implementa as operações de manipulação de dados, incluindo inserções, atualizações e consultas. Ele aplica o padrão Repository, concentrando todas as interações com o banco em um único ponto da aplicação, o que facilita a manutenção e melhora a rastreabilidade.
Exemplo 8 – Inserção de dados de CT-e no banco (database_manager.py)
A função insert_cte_data() utiliza comandos SQL parametrizados e instruções ON CONFLICT, garantindo que registros duplicados sejam atualizados em vez de reinseridos. Essa estratégia preserva a integridade e evita redundâncias no banco de dados.
A camada de Persistência é ainda responsável pela conexão com o módulo ibge_loader.py, que realiza a carga de dados complementares — como unidades federativas, municípios e códigos IBGE — enriquecendo o banco e tornando as análises mais consistentes (ver Seção 4.2.1). Esses dados são utilizados para relacionar informações geográficas aos registros fiscais, ampliando o potencial analítico do sistema.
Essa camada atua, portanto, como a base de sustentação do modelo relacional, isolando detalhes técnicos de acesso e promovendo segurança, consistência e desempenho. Seu desenho modular e a separação entre configuração (database_config) e operações (database_manager) asseguram baixo acoplamento, facilitando futuras migrações de banco ou mudanças na infraestrutura sem afetar o restante do sistema.
A seguir, a camada de aplicação, responsável por unir as camadas anteriores, e executar a fila de processamento.
4.5.4 Camada de Aplicação (Main)
A camada deAplicação desempenha o papel central na orquestração do fluxo de processamento do software, coordenando a interação entre as demais camadas — desde a importação dos arquivos XML até o armazenamento final das informações no banco de dados. Essa camada implementa as regras de negócio e o controle de execução do pipeline, atuando como elo entre os módulos de extração, persistência e visualização. Sua implementação é composta principalmente pelos módulos main.py e etl_service.py.
O módulo main.py atua como ponto de entrada do sistema, responsável por inicializar a aplicação, gerenciar parâmetros de execução e coordenar o processamento em lote dos arquivos XML selecionados pelo usuário (veja seção 4.4.1, camada de upload). Já o módulo etl_service.py concentra a lógica de processamento dos dados, estruturada segundo o paradigma ETL (Extract, Transform, Load), sendo responsável por orquestrar a sequência de operações de extração, transformação e carga no banco de dados, sendo responsável por integrar as etapas de extração (veja seção 4.4.2, camada de extração), transformação dos dados extraídos e carga no bando de dados (veja seção 4.4.3, camada de persistência).
Exemplo 9 – Estrutura do fluxo ETL (etl_service.py)
A função process_cte_files() executa o fluxo completo de processamento, integrando a extração, transformação e persistência dos dados. Cada arquivo XML é validado e seus dados estruturados são inseridos no banco de dados de forma transacional.
O módulo main.py consolida esse comportamento, integrando a camada de Upload (responsável pela seleção dos arquivos) ao pipeline do ETL Service. Esse módulo também executa verificações iniciais de ambiente, como a existência de diretórios de trabalho e permissões de leitura, além de registrar logs básicos de execução.
Exemplo 10 – Ponto de entrada da aplicação (main.py)
O módulo main.py centraliza o fluxo de execução do sistema, conectando a interface de upload (veja seção 4.4.1, camada de upload) à camada de Aplicação e, por meio do etl_service.py, às camadas de Extração e Persistência. Ele atua como o controlador principal, garantindo que a execução siga o pipeline definido e respeite a sequência lógica do processamento.
Essa estrutura promove independência funcional entre as camadas e assegura que o sistema siga um fluxo de execução previsível e controlado, garantindo robustez durante o processamento. Além de coordenar o pipeline principal, essa camada foi projetada para facilitar a extensibilidade do sistema, permitindo futuras incorporações de novas rotinas — como limpeza de dados, enriquecimento adicional ou integração com APIs externas — sem comprometer a estrutura principal.
Por atuar como núcleo de coordenação, mantém a coerência operacional e assegura o cumprimento das regras de negócio, servindo de ponte entre a lógica de domínio e a camada de persistência (veja seção 4.4.3, camada de persistência).
Com a implementação da aplicação finalizada, resta por fim, a camada de visualização, que será documentada no módulo a seguir.
4.5.5 Camada de Visualização (Streamlit)
A camada de Visualização representa o ponto de contato entre o sistema e o usuário, sendo responsável pela apresentação dos dados processados e pela análise interativa dos resultados, para atender ao RF6 (veja seção 4.1).
Implementada com a biblioteca Streamlit, essa camada transforma os dados armazenados no banco PostgreSQL em visualizações dinâmicas e painéis interativos, permitindo a interpretação direta dos indicadores logísticos e o acompanhamento do desempenho do sistema. A comunicação entre o Streamlit e o banco de dados é intermediada pelo módulo database_connector.py, que encapsula as consultas SQL e retorna dataframes prontos para visualização. O módulo principal, app.py, atua como o frontend analítico do sistema, coordenando a exibição das métricas e o carregamento das visualizações. Essa estrutura segue um modelo modular, composto por:
(I) database_connector.py: gerencia a conexão e execução das consultas SQL;
(II) analyze_database.py: realiza consultas consolidadas e cálculos de indicadores;
(III) visualizations.py: gera gráficos e tabelas dinâmicas;
(IV) advanced_views.py: fornece visualizações analíticas complementares;
(V) test_app.py: executa rotinas de verificação da interface, assegurando estabilidade durante o uso.
Exemplo 11 – Interface principal de visualização (app.py)
O módulo app.py inicializa o painel, exibe as métricas consolidadas e integra as visualizações interativas. Essa estrutura favorece clareza, responsividade e uso intuitivo.
Exemplo 12 – Geração de visualizações interativas (visualizations.py)
O módulo visualizations.py centraliza a criação de gráficos e tabelas dinâmicas, permitindo compreender padrões logísticos e valores agregados por região.
As bibliotecas Pandas e Plotly Express são amplamente utilizadas nessa camada: o Pandas fornece estruturas de dados otimizadas para agregação e filtragem, enquanto o Plotly permite a criação de visualizações interativas de alta qualidade, essenciais para a análise exploratória e a interpretação visual dos resultados. A camada de Visualização será também o componente responsável pela fase de feedback do ciclo MVP, permitindo ao usuário observar a consistência das informações apresentadas.
Uma vez com os componentes da arquitetura implementados, a fase Construir do ciclo se finaliza, e inicia-se a fase Medir, que será explorada nos dois módulos subsequentes, a seção 4.5 e a seção 4.6, abrangendo respectivamente, testes e validação, e feedback do usuário.
4.6 Testes e Validação
A presente seção tem como objetivo verificar a correção, desempenho e estabilidade do sistema, assegurando que cada módulo funcionasse de forma independente e integrada conforme os requisitos definidos, com destaque ao RNF1(veja seção 4.1). Os testes foram organizados em quatro níveis principais, unitário, funcional, e de integração, sendo executados de forma incremental durante o desenvolvimento.
4.6.1 Estratégia e Abordagem dos testes
A estratégia de verificação priorizou a reprodutibilidade e a rastreabilidade. Foram utilizados scripts automatizados de teste em Python, com base no módulo pytest, permitindo avaliar o comportamento do sistema em múltiplos cenários. As métricas observadas incluíram: taxa de sucesso por módulo, tempo médio de processamento e cobertura de funcionalidades críticas (extração, inserção e visualização).
Todos os testes foram realizados em ambiente controlado, com banco de dados PostgreSQL local e amostra de 50 arquivos XML de CT-e de diferentes emitentes e layouts (versão 4.00), usando a biblioteca pytest (veja seção 2).
4.6.2 Testes unitários
Os testes unitários verificaram o comportamento isolado das funções de leitura, extração e transformação de dados. Foram aplicados aos módulos cte_extractor.factory, cte_extractor.strategies e database_manager (veja seção 4.4), garantindo a precisão das operações fundamentais do pipeline.
Exemplo 13 – Teste unitário de extração XML (test_unitarios.py)
Esse teste verifica se os campos principais do CT-e são corretamente extraídos e estruturados, garantindo a integridade das informações desde a primeira etapa do processo.
4.6.3 Testes Funcionais
Os testes funcionais avaliaram o comportamento conjunto dos módulos sob condições reais de uso. Esses testes foram aplicados aos componentes file_manager, etl_servicee streamlit_app (veja seção 4.4), simulando o fluxo completo do usuário, desde a importação dos arquivos XML até a visualização dos resultados.
Exemplo 14 – Teste funcional de fluxo completo (test_funcionais.py)
O teste funcional reproduz a execução integral do sistema, validando a comunicação entre camadas e garantindo que o fluxo de dados ocorra sem falhas.
4.6.4 Testes de Integração
Os testes de integração validaram a interoperabilidade entre as camadas de Extração, Aplicação e Persistência (veja, seção 4.3). Foram utilizados cenários que envolvem leitura, extração e gravação de dados no banco PostgreSQL, observando o comportamento transacional e a consistência das operações de escrita.
Exemplo 15 – Teste de integração com o banco de dados (test_integracao.py)
Esse teste assegura que as informações extraídas sejam corretamente armazenadas e recuperadas, garantindo integridade referencial e estabilidade transacional.
4.7 Feedback de usuário
Com o propósito de consolidar o ciclo de aprendizado contínuo proposto pela metodologia MVP, foi desenvolvido um módulo de feedback do usuário integrado à interface principal do software.
Esse módulo, implementado no arquivo feedback.py, possibilita o registro direto de comentários e sugestões por meio de um campo interativo inserido no painel Streamlit, permitindo que o usuário forneça impressões qualitativas sobre a usabilidade, clareza das métricas e utilidade prática do sistema.
O componente de feedback foi desenvolvido utilizando a função st.text_area() para coleta textual e o botão st.button() para submissão das respostas, com armazenamento temporário dos registros em arquivo local e posterior análise pelos desenvolvedores.
Essa abordagem assegura simplicidade de implementação, preservando a privacidade dos usuários e permitindo o uso do recurso em ambientes desconectados de rede corporativa.
Exemplo 16 – Implementação da caixa de feedback (feedback.py)
A função feedback_form() adiciona ao painel uma seção de comentários aberta, registrando as respostas em um arquivo local. Essa implementação foi escolhida por sua leveza, facilidade de integração e compatibilidade com o fluxo interativo do Streamlit.
5 Resultados e Discursão
A presente seção tem por objetivo, apresentar de forma objetiva e descritiva as evidências durante a execução do protótipo, para em sequência discuti-las.
5.1 Resultados
Os resultados que serão apresentados nesta seção incluem registros dos testes, exemplos de arquivos processados, dados persistidos no banco PostgreSQL, visualizações geradas e informações retornadas pelo módulo de feedback.
É importante ressaltar que todos os dados extraídos de clientes para análise da empresa J M Transporte de Cargas EIRELI, não serão apresentados neste artigo. No caso referente a dados da própria empresa, serão sim apresentados, já que foi dada a devida autorização do responsável para apresentação neste documento.
5.1.1 Resultados dos Testes
Os testes automatizados forneceram evidências diretas do funcionamento do sistema nas etapas de leitura dos arquivos XML, extração de campos, transformação de dados, ingestão no banco de dados e verificação de integridade. Nos testes unitários, confirmou-se que os arquivos XML amostrais eram reconhecidos corretamente pelo sistema, estavam bem formados e permitiam a extração dos elementos essenciais do CT-e, incluindo a chave de acesso de 44 dígitos, o número do documento (nCT) e os dados do emitente. As rotinas de validação também retornaram corretamente os formatos esperados de CNPJ, CPF, chaves e valores numéricos.
Nos testes funcionais, foram gerados relatórios JSON contendo os resultados do processamento de arquivos individuais e de lotes. Os fluxos executados registraram, para cada documento, o nome do arquivo, a quantidade aproximada de campos extraídos (cerca de 15 por CT-e) e a indicação de sucesso no processamento. O relatório resumido de descoberta e extração apresenta o seguinte padrão, indicando a detecção e o processamento bem-sucedido de cinco arquivos:
Exemplo 17 – Relatório JSON 1
Os testes de performance registraram o tempo de extração de um arquivo XML específico ao longo de dez execuções consecutivas, medindo tempos individuais em milissegundos e calculando estatísticas como média, mínimo, máximo e desvio-padrão. O relatório correspondente registrou tempos consistentes na faixa de milissegundos e incluiu também o tamanho do arquivo analisado e o total de campos extraídos.
Nos testes que envolvem o banco de dados, verificou-se que a conexão com o PostgreSQL foi estabelecida com êxito, que os schemas cte, core e ibge estavam presentes e que operações de inserção, consulta e remoção foram executadas corretamente. Os testes de integração registraram o processamento completo das quatro camadas do sistema, incluindo extração, transformação do objeto JSON e persistência via função cte.f_ingest_cte_json. Um dos relatórios apresenta o seguinte padrão, indicando o sucesso das etapas:
Exemplo 18 – Relatório JSON 2
Por fim, a rotina de validação de campos registrou a verificação bem-sucedida de vinte e três condições no banco de dados, incluindo presença, igualdade e correspondência entre valores esperados e armazenados nas tabelas cte.documento, cte.carga, core.pessoa, core.endereco e core.veiculo. Nenhuma divergência foi observada.
5.1.2 Resultados do Enriquecimento dos Dados
Executando o script, ibge_loader.py, e posteriormente analisando as tabelas ibge.municipio e ibge.uf (veja seção 4.2), todos os 5571 municípios, com seus dados adicionais, e as 27 uniões federativas do Brasil estavam inseridos, com o devido relacionamento entre as tabelas, demonstrado pela consulta feita ao banco na figura abaixo.
Figura 3 – Relacionamento entre as tabelas ibge.uf e ibge.municipio
Em relação ao enriquecimento com os dados dos veículos e da quilometragem aproximada, todos os veículos tiveram seus dados extraídos dos seus documentos e inseridos um a um na tabela core.veiculo, já a quilometragem, foi corretamente inserida junto dos documentos pela condição que o usuário instanciou durante a execução, assim como conta na consulta da figura abaixo.
Figura 4 – Consulta relacionando as tabelas core.veiculo e cte.documento
5.1.3 Resultados da Visualização
A camada de visualização, retornou insights, que evidenciaram a atividade da empresa no período de outubro de 2024 a outubro de 2025, como demonstrado nos gráficos a seguir.
Figura 5 – Evolução Mensal de CT-e
Figura 6 – Top 10 Veículos por Número de Viagens
Figura 7 – Evolução Mensal de Receita e Crescimento
Figura 8 – Ticket Médio por Distância
5.1.4 Resultados de Feedback do Usuário
Durante os testes de execução do MVP com os internos da empresa, foi pedido que no final do teste deixassem sugestões, seja para melhoria ou seja para reportar alguma falha encontrada, todas os feedbacks foram salvos como mensagens .txt, a seguir, o feedback deixado pelos usuários.
“Desenvolver filtros para análises mensais mais detalhadas”
“Gerar novos filtros para caminhões”
“Melhorar a interatividade dos dashboards”
5.2 Discussão
Os resultados obtidos permitem avaliar de forma crítica em que medida o protótipo desenvolvido cumpre o objetivo central deste trabalho: demonstrar a viabilidade de um sistema capaz de processar automaticamente arquivos XML de CT-e, estruturá-los em um banco de dados relacional e disponibilizá-los em dashboards analíticos. A partir das evidências apresentadas, observa-se que o sistema atendeu integralmente aos requisitos funcionais e não funcionais listados na Tabela 1, especialmente os relacionados à extração, transformação, enriquecimento e persistência dos dados, bem como à geração de visualizações informativas.
Os testes unitários, funcionais e de integração demonstraram que o processamento dos CT-es ocorreu de forma estável e contínua, indicando que o uso de uma arquitetura modular em camadas, fundamentada nos padrões Facade, Factory e Strategy, proporcionou robustez ao sistema. Essa estabilidade era esperada, considerando a aderência da solução às recomendações clássicas de Sommerville (2019) e Bass, Clements e Kazman (2021) sobre separação de responsabilidades e redução de acoplamento. Por outro lado, os tempos de processamento inferiores a milissegundos observados nos testes de performance superaram as expectativas típicas de um MVP, sugerindo que a execução do extrator foi mais eficiente do que o previsto.
A etapa de enriquecimento do banco, apoiada em dados oficiais do IBGE, também se mostrou relevante. A inclusão dessas tabelas ampliou a acurácia semântica das consultas e atendeu ao requisito funcional correspondente, ao permitir a associação entre a origem/destino dos CT-es e localidades validadas. Essa decisão está alinhada à literatura sobre gestão de dados estruturados (TERRA et al., 2023), demonstrando que integrações com fontes de referência fortalecem a qualidade das análises geradas.
Entretanto, a análise crítica evidencia que fragilidades permanecem, sobretudo no que se refere ao cálculo da quilometragem, que depende de parâmetros manuais fornecidos pelo usuário. Embora isso não comprometa o cumprimento dos requisitos essenciais, limita a precisão operacional e aponta a necessidade de integrações futuras com serviços geoespaciais ou APIs de rotas.
Outra fraqueza identificada diz respeito ao módulo de feedback. Embora tenha sido implementado com sucesso e registrado mensagens reais enviadas por usuários, a quantidade de respostas foi limitada, uma vez que a empresa possui poucos colaboradores envolvidos diretamente no processamento de CT-es. Dessa forma, a etapa Medir do ciclo MVP, vinculada à coleta de feedback qualitativo, não atingiu seu potencial máximo de aprendizado. Essa limitação decorre mais do contexto organizacional do que de falhas do sistema, mas ainda assim constitui uma restrição importante, pois reduz a variedade de percepções e a capacidade de identificar necessidades que poderiam orientar novas versões do protótipo.
Além da quantidade reduzida de participantes, a avaliação qualitativa não permitiu observar divergências ou padrões de uso diferenciados, o que limita a profundidade das interpretações sobre a usabilidade. De forma geral, os comentários recebidos foram positivos e úteis, mas não suficientes para validar preferências, dificuldades ou demandas mais complexas. Assim, o módulo de feedback, embora funcional, figura como um ponto fraco do projeto no que diz respeito à amplitude de avaliação, um fator que poderá ser mitigado em iterações futuras envolvendo mais usuários ou ambientes de teste mais amplos.
Outra limitação relevante diz respeito ao conjunto de documentos XML utilizados. Embora todos sejam reais e provenientes do sistema GDOOR-CTE da empresa J M Transporte de Cargas EIRELI, o corpus cobre apenas o período de outubro de 2024 a outubro de 2025, restringindo a diversidade de cenários operacionais representados. A literatura da área sugere que a generalização de sistemas aplicados a documentos fiscais eletrônicos depende da exposição a diferentes emissores, modais, configurações tributárias e variações regionais, o que poderá ser explorado em trabalhos futuros.
Apesar dessas limitações, o conjunto de evidências analisado é suficiente para confirmar a principal descoberta do estudo: é plenamente viável desenvolver, com base em um MVP bem estruturado, um sistema capaz de transformar dados brutos de CT-es em informações gerenciais relevantes para pequenas transportadoras, cumprindo todos os requisitos funcionais essenciais estabelecidos na modelagem (Tabela 1). A combinação entre arquitetura modular, banco relacional enriquecido e camada de visualização integrada representa uma contribuição prática para um segmento carente de ferramentas tecnológicas acessíveis, reforçando o potencial de expansão da solução.
6 Conclusão
Este trabalho teve como propósito desenvolver um Produto Mínimo Viável (MVP) voltado ao processamento estruturado de arquivos XML de Conhecimento de Transporte Eletrônico (CT-e), com armazenamento relacional e visualizações voltadas à análise operacional de pequenas transportadoras. O objetivo foi alcançado, uma vez que o sistema implementado executou o fluxo completo de ingestão, transformação e organização dos dados, permitindo sua posterior exploração em ambiente visual interativo.
A relevância da pesquisa reside no fato de que micro e pequenas empresas do setor de transporte raramente dispõem de soluções acessíveis que permitam transformar documentos fiscais eletrônicos em indicadores gerenciais. Ao integrar extração automática, enriquecimento semântico e visualização, o sistema demonstrou que é possível viabilizar análises consistentes sem a necessidade de plataformas comerciais de alto custo. Assim, o trabalho contribui para a modernização da gestão de informações no setor, oferecendo uma alternativa prática e tecnicamente fundamentada.
As contribuições práticas incluem a implementação de uma arquitetura modular baseada em padrões de projeto amplamente reconhecidos, a modelagem de um banco de dados relacional enriquecido com dados oficiais e a disponibilização de um painel de visualização funcional. Em termos teóricos, o estudo demonstra a adequação do ciclo MVP ao desenvolvimento de sistemas baseados em documentos fiscais eletrônicos, evidenciando sua aplicabilidade em cenários reais de operação.
Entretanto, algumas limitações precisam ser reconhecidas. O conjunto de usuários disponível para avaliação foi reduzido, devido ao porte da empresa analisada, o que restringiu o alcance da etapa de feedback e a amplitude da avaliação de usabilidade. A estimativa de quilometragem permanece dependente de um valor manual informado pelo operador, limitando a precisão de alguns indicadores derivados. Além disso, o corpus de CT-es utilizado abrange documentos de apenas um emissor e de um intervalo temporal restrito, reduzindo a variedade de cenários contemplados.
Diante dessas limitações, sugerem-se como trabalhos futuros: ampliar o conjunto de documentos e empresas avaliadas; incorporar serviços externos de georreferenciamento para cálculo automático de distâncias; evoluir o painel analítico com métricas avançadas; e ampliar o módulo de feedback para captar percepções de um número maior de usuários, fortalecendo o aprendizado validado em ciclos posteriores.
Em síntese, o estudo demonstra que é tecnicamente viável transformar dados brutos de CT-e em informação estruturada e útil para a tomada de decisão em pequenas empresas do setor de transporte, oferecendo uma base concreta para aprimoramentos e pesquisas futuras.
Referências
ALMEIDA, M. B. Uma introdução ao XML, sua utilização na internet e alguns conceitos complementares. Ciência da Informação, Brasília, v. 31, n. 2, p. 5-13, maio/ago. 2002. Disponível em: https://www.scielo.br/j/ci/a/QQ3HX7jLBfTG3gpvPdfGK9j/. Acesso em: 14 out. 2025.
BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. Software Architecture in Practice. 4th ed. Boston: Addison-Wesley, 2021. BLANK, Steve. The Four Steps to the Epiphany: Sucessful Strategies for Product that Win. 2nd ed. Pescaero: K&S Ranch, 2013.
BRASIL. Receita Federal. CT-e – SPED – Sistema Público de Escrituração Digital. Brasília, 2007. Disponível em: http://sped.rfb.gov.br/item/show/1126. Acesso em: 14 out. 2025.
BRASIL. Brasília: ENCAT; Receita Federal do Brasil, 2007. Disponível em: https://www.cte.fazenda.gov.br/portal/principal.aspx. Acesso em: 22 out. 2025.
CODD, E. F. A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, v. 13, n. 6, p. 377-387, 1970.
CONFEDERAÇÃO NACIONAL DO TRANSPORTE. Pesquisa CNT Perfil Empresarial – Transporte Rodoviário de Cargas 2021. Brasília, 2022. Disponível em: https://static.poder360.com.br/2022/04/pesquisa-cnt-perfil-empresarial-transporterodovia%CC%81rio-de-cargas.pdf. Acesso em: 14 out. 2025.
DATE, C. J. Introdução a Sistemas de Bancos de Dados. 8. ed. Rio de Janeiro: Elsevier Campus, 2004. ELMASRI, R.; NAVATHE, S. B. Sistemas de Banco de Dados. 6. ed. São Paulo: Pearson Addison Wesley, 2011.
GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Design Parttens: Elements of Reusable Object-Oriented Software. Reading, MA: AddisonWesley,1995.
INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA. Logística dos Transportes no Brasil. Rio de Janeiro, 2019. Disponível em: https://geoftp.ibge.gov.br/organizacao_do_territorio/redes_e_fluxos_geograficos/logistica_d os_transportes/Nota_tecnica_da_Logistica_dos_Transportes_no_Brasil_2014_20191031.pdf. Acesso em: 14 out. 2025.
INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA. Transportes – Anuário Estatístico do Brasil. Rio de Janeiro, 2023. Disponível em: https://anuario.ibge.gov.br/2023/servicos/transportes.html. Acesso em: 14 out. 2025.
KIMBALL, R; ROSS, M. The Data Warehouse Toolkit. 3rd ed. New York: Wiley, 2013.
MARTINS, R. S. et al. Gestão do transporte orientada para os clientes: nível de serviço desejado e percebido. Revista de Administração Contemporânea, v. 15, n. 6, p. 1100-1119, nov./dez. 2011. Disponível em: https://www.scielo.br/j/rac/a/Bwt7VXZYYxSpgYG8LJnLTPR/. Acesso em: 14 out. 2025.
MENDES, Sérgio. SACT – Sistema de Análise de Conhecimento de Transporte. Disponível em: https://github.com/Sergiosmf/SACT.git. Acesso em 11 nov. 2025.
PYTEST. Full pytest documentation. Disponível em: https://docs.pytest.org. Acesso em: 18 nov. 2025.
PYTHON SOFTWARE FOUNDATION. tkinter — Interface Python para Tcl/Tk. Disponível em: https://docs.python.org/pt-br/3/library/tkinter.html. Acesso em: 30 out. 2025.
PYTHON SOFTWARE FOUNDATION. Diálogos Tkinter — Documentação Python 3.13.9. Disponível em: https://docs.python.org/pt-br/3.13/library/dialog.html. Acesso em: 30 out. 2025.
PYTHON SOFTWARE FOUNDATION. xml.etree.ElementTree — The ElementTree XML API. Disponível em: https://docs.python.org/pt-br/3/library/xml.etree.elementtree.html. Acesso em: 30 out. 2025.
PYTHON SOFTWARE FOUNDATION. xml.etree.ElementTree — Python 3.14 Documentation. Disponível em: https://docs.python.org/3/library/xml.etree.elementtree.html. Acesso em: 30 out. 2025.
RIES, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Sucessful Businesses. New York: Crown Business, 2011.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de Software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2020.
SECRETARIA DE ESTADO DA FAZENDA DO RIO DE JANEIRO. Manual CT-e – Rio de Janeiro. Rio de Janeiro, . Disponível em: https://portal.fazenda.rj.gov.br/dfe/wpcontent/uploads/sites/17/2023/01/DF_e_CT-e.pdf. Acesso em: 14 out. 2025.
SERVIÇO BRASILEIRO DE APOIO ÀS MICRO E PEQUENAS EMPRESAS. Transportes e logística. Brasília, 2022. Disponível em: https://sebraepr.com.br/comunidade/artigo/sebrae-em-dados-transportes-e-logistica. Acesso em: 14 out. 2025.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de Banco de Dados. 7. ed. Rio de Janeiro: LTC, 2020.
SISTEMA PÚBLICO DE ESCRITURAÇÃO DIGITAL. Portal do Conhecimento de Transporte Eletrônico. Brasília, 2025. Disponível em: https://www.cte.fazenda.gov.br/portal/principal.aspx. Acesso em: 14 out. 2025.
SOMMERVILLE, I. Engenharia de Software. 10. ed. São Paulo: Pearson Education do Brasil, 2019. STREAMLIT. “Streamlit documentation.” Disponível em: https://docs.streamlit.io. Acesso em: 18 nov. 2025.
TERRA, A. L. et al. Abordagem à gestão de dados científicos num contexto multidisciplinar. Encontros Bibli: Revista Eletrônica de Biblioteconomia e Ciência da Informação, v. 28, p. 1-24, 2023. Disponível em: https://www.scielo.br/j/eb/a/SNdSnyTLCBb8n4yvh85tymN/. Acesso em: 14 out. 2025.
VIEIRA, G. S. Implementação de um sistema WMS: um estudo das disfunções na operação logística de uma transportadora durante a pandemia do Covid-19. 2021. Dissertação (Mestrado em Engenharia de Produção) – Instituto Federal da Paraíba, João Pessoa, 2021. Disponível em: https://repositorio.ifpb.edu.br/bitstream/177683/1492/1/Gabriel%20da%20Silva%20Vieira% 20-%20Implementa%C3%A7%C3%A3o%20de%20um%20sistema%20WMS- Um%20estudo%20das%20disfun%C3%A7%C3%B5es%20na%20opera%C3%A7%C3%A3o%2 0log%C3%ADstica%20de%20uma%20transportadora%20durante%20a%20pandemia%20do%2 0Covid-19.pdf. Acesso em: 14 out. 2025.
WAGNER, C. S. Conhecimento de Transporte Eletrônico: CT-e. 2017. Dissertação (Mestrado em Gestão da Informação) – Universidade Federal do Paraná, Curitiba, 2017. Disponível em: https://acervodigital.ufpr.br/xmlui/handle/1884/52983. Acesso em: 14 out. 2025.
WORLD WIDE WEB CONSORTIUM. Extensible Markup Language (XML). [S. l.], 2025. Disponível em: https://www.w3.org/XML/. Acesso em: 21 out. 2025.
1Graduando em Engenharia de Software, ICEV – Instituto de Ensino Superior, sergio_mendes.filho@somosicev.com
2Docente de Engenharia de Software, ICEV – Instituto de Ensino Superior, maria_hellem.abreu@somosicev.com