TCC Mario Estevam

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
UNIDADE ACADÊMICA ESPECIALIZADA EM CIÊNCIAS AGRÁRIAS –

ESCOLA AGRÍCOLA DE JUNDIAÍ
CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE
SISTEMAS
Mario Estevam de Freitas Neto
TAUROS: TECNOLOGIA APLICADA À UNIDADE DE RESOLUÇÃO PARA
OCORRÊNCIAS
Macaíba, RN
2022
Tauros: Tecnologia Aplicada à Unidade de Resolução Para Ocorrências
Monografia apresentada ao curso superior

de Tecnologia em Análise e
Desenvolvimento de Sistemas, da
Universidade Federal do Rio Grande do
Norte, como requisito parcial à obtenção
do título de Tecnólogo em Análise e
Desenvolvimento de Sistemas.
Orientador(a):
Prof. Dra Carla Da Costa Fernandes
Curvelo.
Coorientador(a): Prof. Dr Taniro Chacon

Rodrigues
Macaíba,
RN 2022
TAUROS: TECNOLOGIA APLICADA À UNIDADE DE RESOLUÇÃO PARA OCORRÊNCIAS
Trabalho de conclusão de curso de graduação apresentado à Unidade

Acadêmica Especializada em Ciências Agrárias – Escola Agrícola de Jundiaí da
Universidade Federal do Rio Grande do Norte como requisito parcial para a
obtenção do título de Tecnólogo (a) em Análise e Desenvolvimento de Sistemas.
Aprovado em: 22 de dezemrbo de 2022.
BANCA EXAMINADORA
__________________________________________
Profa. Dra. Carla da Costa Fernandes - UFRN (orientadora)
__________________________________________
Prof. Dr. Taniro Rodrigues Chacon - UFRN (coorientador)
__________________________________________
Prof. Dra. Tasia Moura do Vale - UFRN (membro interno)
__________________________________________
Prof. Dra. Huliane Medeiros Da Silva - UFRN (membro interno)

AGRADECIMENTOS
Agradeço primeiramente a Deus pela sabedoria e entendimento que me
deu.
Aos meus amigos, em especial Dalania Silva, Luan Magioli, Yuri Felipe,
Jean Fernandes, George Mendonça e Enuch Santos pelo apoio, incentivo e
companheirismo nos dias difíceis da faculdade.
Aos meus familiares e à minha digníssima namorada pelo apoio e incetivo
constante.
A minha orientadora, pelo emprenho dedicado à elaboração deste
trabalho.
A todos que direta ou indiretamente fizeram parte da minha formação, о
meu sincero obrigado.

RESUMO
Neste trabalho de conclusão de curso foi desenvolvido um sistema web para
controle de chamados, voltado especialmente para o setor de suporte de
informática da instituição EAJ (Escola Agrícola de Jundiaí) devido problemas e
bugs encontrados no sistema atualmente utilizado. O sistema desenvolvido fez uso
da linguagem JAVA, e de frameworks como Spring boot e Spring MVC. A
arquitetura utilizada foi a MVC assim como a apresentação das principais
vantagens do uso desta arquitetura. Os módulos de autenticação e autorização
fazem uso do Spring Security. É apresentado os diagramas de caso de uso do
sistema, a modelagem do banco, assim como outras tecnologias utilizadas.
Como resultado o sistema desenvolvido agradou ao usuário principal que é o
gerente de suporte da EAJ, pois resolveu problemas do atual sistema utilizado por
ele, como um simples cadastro de usuário, além de apresentar uma interface
mais elegante também.
Palavras-chave: Java, Spring Boot, Spring MVC, Spring Security,MVC.

ABSTRACT
In this final paper we developed a web system to control calls, especially for the IT
support sector of the institution EAJ (Escola Agrícola de Jundiaí) due to problems
and bugs found in the system currently used. The system was developed using the
JAVA language, and frameworks like Spring boot and Spring MVC. The
architecture used was MVC, as well as the presentation of the main advantages
of using this architecture. The authentication and authorization modules make use
of Spring Security. The system's use case diagrams, the bank modeling, as well as
other technologies used, are presented. As a result, the system developed pleased
the main user, which is the support manager of EAJ, because it solved problems of
the current system used by him, such as a simple user registration, besides
presenting a more elegant interface as well.
Keywords: Java, Spring Boot. Spring MVC.,Spring Security, MVC.

LISTA DE FIGURAS
Figura 1 – Tela de abertura de ocorrência 15
Figura 2 – Tela principal do módulo CMDB 16
Figura 3 – Tela principal do módulo HELP DESK 16
Figura 4 – Tela de gerenciamento do módulo GESTÃO FINANCEIRA 17
Figura 5 – Tela principal do protótipo 18
Figura 6 – Tela de visualização dos chamados 19
Figura 7 – Tela de abertura de chamado 19
Figura 8 – Diagrama MER 22
Figura 9 – Diagrama de casos de uso 25
Figura 10 – Diagrama de Classes 26
Figura 11 – Fluxograma modelo MVC 30
Figura 12 – Tela de Login 32
Figura 13 – Tela de cadastro 33
Figura 14 – Tela de cadastro pelo administrador 34
Figura 15 – Tela inicial do requisitante 34
Figura 16 – Tela de cadastro do chamado 35
Figura 17 – Tela de detalhes do chamado 36
Figura 18 – Tela inicial operador 37
Figura 19 – Modal de finalização de atendimento do chamado 38
Figura 20 – Tela Inicial Responsável do Setor 39
Figura 21 – Tela de Meus Atendimentos 39
Figura 22 – Tela de Usuários 40
Figura 23 – Tela de Problemas 41
Figura 24 – Tela de Cadastro de Problema 41
Figura 25 – Relatório do Setor 42
Figura 26 – Tela Inicial do Administrador 43
Figura 27 – Tela de chamados 43

Figura 28 – Tela de listagem dos setores 44
Figura 29 – Tela de cadastro de setor 44
Figura 30 – Tela de usuários pendentes 45
Figura 31 – Relatório por Setor 46

LISTA DE TABELAS
TABELA 1 – Descrição do diagrama de classes 27

LISTA DE ABREVIATURAS
EAJ Escola Agrícola de JundiaÍ
MER Modelo Entidade Relacional
ITIL Information Technology Infrastructure Library
UML Unified Modeling Language

Sumário
1. INTRODUÇÃO 11
1.1 JUSTIFICATIVA 12
1.2 OBJETIVOS 12
1.2 OBJETIVOS ESPECÍFICOS 13
1.3 ESTRUTURA DO TRABALHO 13
2. REVISÃO DE LITERATURA 14
2.1 OCOMON 14
2.2 GLPI 15
2.2 PROTÓTIPO DE SISTEMA WEB PARA GERENCIAMENTO DE CHAMADOS BASEADO EM ITIL 17
3. MATERIAL E MÉTODOS 20
3.1 METODOLOGIA 20
3.2 MODELAGEM DO SISTEMA 21
3.2.1 REQUISITOS FUNCIONAIS 22
3.2.2 DIAGRAMA DE CASOS DE USO 25
3.2.3 DIAGRAMA DE CLASSES 26
3.3 MÉTODOS 27
3.3.1 TECNOLOGÍAS UTILIZADAS 27
3.3.1.1 JAVA 27
3.3.1.2 SPRING BOOT 28
3.3.1.3 THYMELEAF 29
3.3.1.4 POSTGRESSQL 29
3.2.2 ARQUITETURA DO SISTEMA 29
4.1 AUTENTICAÇÃO E AUTORIZAÇÃO DO USUÁRIO 32
4.2 CADASTRO DE USUÁRIO 33
4.3 MÓDULO DO REQUISITANTE 34
4.4 MÓDULO DO OPERADOR 37
4.5 MÓDULO DO RESPONSÁVEL DO SETOR 38
4.5.1 USUÁRIOS 40
4.5.2 PROBLEMA 40
4.5.3 RELATÓRIO DO SETOR 42
4.6 ADMINISTRADOR 42
4.6.1 SETOR 44
4.6.2 USUÁRIOS PENDENTES 45
4.6.3 RELATÓRIO POR SETOR 45
5. CONSIDERAÇÕES FINAIS 46
5.1 TRABALHOS FUTUROS 47
11
1. INTRODUÇÃO
Vivemos em um meio onde a tecnologia se faz cada vez mais presente no
nosso cotidiano, atendendo a diversas de nossas necessidades. Entre os sistemas
que vêm sendo desenvolvidos atualmente, existem os “Help Desk”, softwares que
tem por objetivo auxiliar equipes de suporte/assistência para coordenar e
solucionar ocorrências com usuários, assegurando que os chamados gerados por
estas ocorrências não sejam perdidos, esquecidos ou negligenciados. Este
software se constitui em um mecanismo computacional facilitador da informação
e comunicação (CAVALARI; COSTA, 2005).
A Escola Agrícola de Jundiaí (EAJ) da Universidade Federal do Rio Grande
do Norte faz uso de um sistema semelhante ao modelo de software Help Desk,
voltado para todos os setores da escola, atendendo às coordenações dos cursos,
aos setores produtivos e administrativos. É possível se basear nesse modelo de
sistema, e desenvolver um que seja próprio da Escola Agrícola, atendendo as
necessidades atuais, de abertura de chamado, relatórios, visualização dos
chamados, cadastro de problemas e setores, acompanhamento dos chamados
em abertos entre outras funções.
O atual sistema em uso na EAJ, se encontra com diversos problemas e
inconsistências, erros na execução de funcionalidades essenciais, como o
cadastro de usuários, erros estes que geram má organização no atendimento dos
chamados e incoerência nos dados que são armazenados.
Visando atender as necessidades da EAJ, este trabalho tem como objetivo
desenvolver um novo sistema baseado nas regras e modelagem de banco do

12
software que já está em funcionamento, porém utilizando uma tecnologia mais
atualizada, gerando uma interface mais moderna, objetivando também corrigir
os problemas que existem no sistema atual.
1.1 JUSTIFICATIVA
O sistema em uso atualmente na Escola Agrícola de Jundiaí tem por
funcionalidade abrir chamados desde ocorrências técnicas para o setor de
informática a ocorrências administrativas pro setor de comunicação, então
tem-se coordenadores, professores, técnicos, operadores e responsáveis
administrativos como principais usuários. Este sistema faz uso de uma tecnologia
antiga, não apresenta uma boa experiência de interface para o usuário,
funcionalidades inconsistentes ou que nem estão mais em funcionamento, como
por exemplo gerar relatórios, cadastrar usuários etc. Visando trazer um sistema
com interface amigável, corrigindo problemas e inconsistências do sistema atual,
como também fazendo uso de tecnologias mais recentes é que este trabalho se
justifica.
1.2 OBJETIVOS
O trabalho tem por objetivo o desenvolvimento de um sistema web para
controle e gerenciamento de chamados para os diversos setores da Escola
Agrícola de Jundiaí.
13
1.2 OBJETIVOS ESPECÍFICOS
● Desenvolver um sistema web dividido por módulos, sendo eles:
Administrador, Responsável de Setor, Operador e Requisitante.
● Conter funcionalidades para gerenciamento de setores, problemas,
usuários e chamados.
● Utilizar um sistema de autenticação e autorização seguro.
● Fazer uso de uma tecnologia mais recente.
1.3 ESTRUTURA DO TRABALHO
Este trabalho está dividido em cinco capítulos:
● Capítulo 1: Dá ênfase ao estado inicial e de apresentação do
projeto, a situação problema, solução proposta, objetivos e a
metodologia de como foi realizado.
● Capítulo 2: Tem por objetivo mostrar os trabalhos relacionados,
sistemas que se assemelham ao que está em desenvolvimento nesse
trabalho.
● Capítulo 3: Apresenta os requisitos funcionais e delimitação do
escopo do sistema. O MER (Modelo Entidade-Relacionamento) do
banco de dados e a descrição das tabelas do mesmo. Os métodos,
tecnologias utilizadas, arquitetura e módulos do sistema.
● Capítulo 4: Apresenta os resultados obtidos após o desenvolvimento
do sistema, como telas e os principais módulos como autenticação,
requisições, etc.
14
● Capítulo 5: Apresenta as considerações finais e ideias de trabalhos
futuros.
2. REVISÃO DE LITERATURA
Nesta seção serão apresentados sistemas encontrados na literatura que
gerenciam pedidos para solução de problemas por requisitantes em um
ambiente de trabalho. Os sistemas têm um objetivo similar ao proposto neste
projeto, e por isso foi feita uma análise comparativa entre as funcionalidades de
cada um deles
2.1 OCOMON
O Ocomon (CUSTÓDIO, 2002) é um sistema de código aberto desenvolvido
utilizando a linguagem PHP, utilizado para gestão de chamados que busca
atender de ordem prática, operacional e gerencial áreas de suporte técnico
como HelpDesks e Service Desks (Figura 1). HelpDesk é um termo designado para
serviços de apoio tecnológicos e Service Desks é para serviços mais complexos
também envolvendo a área tecnológica.
A partir de necessidades dos usuários também foi integrado a este sistema
um controle de inventário.
As funções clássicas do módulo de ocorrências incluem abertura, listagem
e acompanhamento de chamados, e controles gerenciais de tipos de
problemas, níveis de prioridade e tempos de resposta esperados, além de outras
muitas funcionalidades.
15
O módulo de inventário inclui as funcionalidades de controle de
informações contábeis de equipamentos, cadastro detalhado das informações
(configuração) de hardware do equipamento, controle de licenças de softwares,
controle de garantias dos equipamentos, dentre outras.
Figura 1 – Tela de abertura de ocorrência
Fonte: Autoria própria (2022).
2.2 GLPI
O GLPI é um software de código aberto, desenvolvido em PHP, utilizado
para gerenciar ocorrências em um ambiente de trabalho, possuindo também
outras funcionalidades, como gerenciamento de projetos e planejamento de
mudanças de TI, permitindo resolver problemas com eficiência, automatizando
processos de negócios e obtendo controle sobre toda a infraestrutura de TI
(TECLIB).
O sistema é composto por 3 módulos básicos: o CMDB, um módulo
gerenciador de hardware, software e data centers (Figura 2); o Help Desk, um
módulo para abertura de ticket/chamado, podendo escolher entre entre
Incidente ou Requisição (Figura 3); Gestão Financeira, módulo voltado para

16
rastrear as despesas, contratos e fornecedores, criar novos objetos de estoque,
gerenciar banco de dados de usuários e fazer relatórios (Figura 4).
Figura 2 – Tela principal do módulo CMDB
Fonte: (TecLib, 2015).
Figura 3 – Tela principal do módulo HELP DESK

17
Figura 4 – Tela de gerenciamento do módulo GESTÃO FINANCEIRA
2.2 PROTÓTIPO DE SISTEMA WEB PARA GERENCIAMENTO DE CHAMADOS BASEADO EM ITIL
No trabalho de conclusão de curso feito por BAUMGARTEN (2018) foi
desenvolvido um protótipo de sistema de gestão de chamados focado na

18
agilidade e qualidade do atendimento ao usuário final. Este projeto toma por
base práticas dos processos de Gerenciamento de Nível de Serviço, Incidentes,
Problemas e Mudanças, mantidos pela Information Technology Infrastructure
Library (ITIL). As tecnologias utilizadas foram Microsoft SQL Server 2014 Express
como banco de dados, e C# como linguagem principal.
Figura 5 – Tela principal do protótipo
Fonte: (BAUMGARTEN, 2018).
Figura 6 – Tela de visualização dos chamados

19
Figura 7 – Tela de abertura de chamado

20
3. MATERIAL E MÉTODOS
Neste capítulo é documentada a modelagem do sistema com premissas e
objetivos definidos anteriormente, levando em consideração a definição de um
escopo, a análise de requisitos, diagrama de casos de uso e diagrama de classes.
3.1 METODOLOGIA
Abaixo está descrita a metodologia seguida para o desenvolvimento deste
Trabalho de Conclusão de Curso:
1 - Determinação do tema – problema – tese do trabalho: Nesta fase, foi
verificada uma necessidade, um problema que pudesse ser solucionado com uso
da tecnologia;
2 - Levantamento de Requisitos: Com o ponto focal do trabalho
estabelecido, foi efetuado um levantamento de requisitos para capturar as
necessidades do usuário principal (gerente de suporte de TI da EAJ) e definir
aquilo que o sistema trará como solução. Nessa fase foram feitas reuniões com o
usuário para elaboração dos requisitos do sistema, validação da modelagem do
banco, validação de interface etc;
3 - Concepção: A partir dos requisitos levantados, estruturamos como seria
o sistema em questão de design e foi feita a validação com o usuário para iniciar
a fase de desenvolvimento.
4 - Desenvolvimento: Com os requisitos levantados e a concepção feita o
sistema começou a ser desenvolvido, durante esse processo ocorreram reuniões
com o usuário a fim de alinhar o que estava sendo desenvolvido com as reais
necessidades dele.
21
3.2 MODELAGEM DO SISTEMA
O Modelo Entidade Relacional, MER, é a representação lógica de como o
banco de dados está disposto para um sistema.
Para geração deste diagrama foi utilizado o DBEAVER ferramenta de
administração de bancos de dados relacionais SQL, usa interface de
programação de aplicativos JDBC para interagir com bancos de dados por meio
de um driver JDBC (DBEAVER, 2011).
O DBEAVER é compatível com o banco de dados escolhido para o sistema
desenvolvido neste TCC.
Um benefício que levou à sua adoção é a possibilidade de gerar os scripts
SQL de forma automatizada, dando agilidade na criação das tabelas. O sistema
a ser desenvolvido necessita de um banco de dados devido à necessidade de
armazenamento das informações, sobre os chamados, usuários etc. Com isso, o
MER será o principal ponto de entendimento do sistema e como ele está
projetado.
O MER exibe as tabelas, seus relacionamentos e respectivas cardinalidades,
sendo possível, a partir dele, desenvolver o sistema. A Figura 8 mostra o diagrama
do MER do TCC.
22
Figura 8 – Diagrama MER
3.2.1 Requisitos Funcionais
No contexto do sistema a ser desenvolvido há quatro módulos:
● Administrador: Neste módulo é possível fazer gestão geral, de setores,
problemas, chamados, usuários etc;
● Responsável do setor: Neste módulo é possível fazer gestão
problemas do próprio setor, chamados do próprio setor e usuários do
próprio setor;
● Requisitante: Neste módulo é possível apenas abrir, visualizar e editar
os próprios chamados;
23
● Operador: Neste módulo é possível apenas abrir, visualizar e editar os
próprios chamados e atender aos chamados de seu setor;
Administrador
● RF01: O sistema deve permitir criar, alterar, habilitar, desabilitar
e excluir um usuário do sistema;
● RF02: O sistema deve permitir criar, visualizar, alterar e excluir
um Setor;
● RF03: O sistema deve permitir criar, visualizar, alterar e excluir
um Problema;
● RF04: O sistema deve permitir criar, visualizar, atender, alterar e
excluir um Chamado;
● RF05: O sistema deve permitir a visualização de todos os
chamados (Concluídos, Em atraso, Em andamento, Abertos);
setores;
problemas;
● RF07: O sistema deve permitir a visualização relatórios;
Responsável do setor
● RF01: O sistema deve permitir criar, alterar e desabilitar um
usuário do sistema;
24
● RF02: O sistema deve permitir criar, alterar, visualizar e excluir
um problema de seu setor;
● RF03: O sistema deve permitir criar, alterar, atender, visualizar e
excluir um chamado de seu setor;
● RF04: O sistema deve permitir a visualização dos chamados de
seu setor(Concluídos, Em atraso, Em andamento, Abertos);
● RF08: O sistema deve permitir a visualização relatórios do seu
setor;
Requisitante
um chamado próprio;
● RF02: O sistema deve permitir a visualização de seus chamados
(Concluídos, Em atraso, Em andamento, Abertos);
Operador
um chamado próprio;
● RF02: O sistema deve permitir a visualização de seus chamados
e de seu setor (Concluídos, Em atraso, Em andamento, Abertos);
● RF03: O sistema deve permitir o atendimento de chamados de
seu setor;
25
3.2.2 Diagrama De Casos De Uso
Os diagramas de caso de uso são os modelos usados para representar
visualmente as funcionalidades observáveis do sistema e a forma como o usuário
interage com ele. O diagrama de casos de uso mostra o modelo do sistema a
partir da análise de requisitos (BEZERRA, 2002).
A Figura 9 apresenta o diagrama de casos de uso do sistema, no qual é
possível visualizar os 4 diferentes tipos de atores: Requisitante, Operador,
Responsável de Setor e Administrador.
Figura 9 – Diagrama de casos de uso

26
Nos casos de uso expostos podemos perceber uma hierarquia entre as
funções e os tipos de usuário, onde o Operador herda as funções do Requisitante,
o Responsável do setor herda as funções do Operador e do Requisitante, e o
Administrador de todos os anteriores.
3.2.3 Diagrama De Classes
O diagrama de classes expõe as classes do sistema em questão, assim
como as interfaces, colaborações e relacionamentos (BOOCH, RUMBAUGH e
JACOBSON, 2005). Por esse diagrama é apresentada a estrutura do sistema, os
itens que por sua vez, se fazem necessários para o desenvolvimento. Na Figura 10
é representado o Diagrama de Classes do Tauros.
Figura 10 – Diagrama de Classes

27
Para melhor entendimento do diagrama, segue uma tabela descritiva das
classes do sistema:
Tabela 1 – Descrição do diagrama de classes
Classe Descrição
Classe de representação do usuário, possuindo username, senha, email etc.

User
Classe de representação do setor, possuindo como atributo o nome a qual o

Setor
usuário informará no cadastro.
Classe de representação do setor, possuindo como atributo o nome a qual o

Problema
usuário informará no cadastro.
Classe de representação do chamado, sendo uma das classes mais

Chamado
importantes do sistema pois tem como atributo o usuário de abertura do
chamado, usuário de atendimento, setor, problema etc.
Classe responsável pela função do usuário (Operador, Requisitante,

Função
Administrador, Responsável de setor)
3.3 MÉTODOS
Nesta seção será apresentada as tecnologias utilizadas, arquitetura do
sistema e seus módulos.
3.3.1 Tecnologías Utilizadas
3.3.1.1 Java
Java é uma linguagem de programação orientada a objetos, multiplataforma, e
roda em qualquer sistema operacional, necessitando-se apenas de um interpretador
instalado. O interpretador Java tem por nome máquina virtual JAVA(JVM),e é um

28
programa que converte o código Java em comandos que o sistema operacional pode
executar (JAVA, 2013).
Esta linguagem apresenta uma peculiaridade, em vez de gerar um código binário
diferente para cada plataforma, é gerado um binário que pode ser executado em
qualquer plataforma, dentro de uma máquina virtual. Este código binário “universal” é
chamado de bytecode, e esse é o principal motivo pelo qual essa linguagem é
multiplataforma e por isso os programas desenvolvidos nesta linguagem pode ser
utilizados em ambiente web, desktop e dispositivos celulares, estes sendo categorizados
respectivamente por Java SE, EE, ME (JAVA, 2013).
Essa versatilidade é útil pois permite reutilizar códigos de um ambiente para outro
sem se preocupar com incompatibilidades.
3.3.1.2 Spring Boot
O framework Spring no decorrer do tempo passou a ser a tecnologia de
desenvolvimento de aplicações em Java. Ele traz em seu núcleo o conceito de
injeção de dependência. A injeção de dependência possibilita o fácil
gerenciamento de projetos grandes expondo o relacionamento entre objetos
dentro da aplicação através de convenções e anotações, ao invés dos objetos
possuírem alto acoplamento entre eles.
Este framework situa-se como mediador entre as diferentes classes da
aplicação e gerencia as dependências do projeto. Devido a ampla migração de
aplicações da arquitetura monolítica para microsserviços pelas empresas, a
equipe de desenvolvimento do Spring lançou dois projetos: Spring Boot e Spring
Cloud (CARNELL, 2017).
Este framework apresenta um servidor de aplicação Web embutido (Web
Server ),sendo possível a configuração e execução da aplicação por meio dele,
onde o mesmo é iniciado automaticamente, implantando e realiza a inicialização
da aplicação com suas respectivas configurações. O servidor de aplicação

29
nativo ao Spring Boot é o Apache Tomcat. Mas outros servidores também podem
substituí-lo, tais como Jetty e Undertow (WEBB, 2017).
Dentre as principais características do Spring boot temos (GUTIERREZ, 2016):
• Facilidade de rapidez para criação de aplicações;
• Autoconfiguração;
• Integração de dependências automaticamente;
• Gerenciamento de configurações eficaz;
• Suporte em contêiner para Servlet embutido;
• Inicialização da aplicação através de uma classe SpringApplication;
3.3.1.3 Thymeleaf
O Thymeleaf é um template engine bastante utilizado ao lado do Spring
para criação de views. Ele tanto facilita na configuração, como possui por
objetivo principal prover um design elegante e bem estruturado de páginas
(THYMELEAF, 2022).
3.3.1.4 PostgresSql
PostgreSQL é um sistema de banco de dados open source e
objeto-relacional. Possui mais de 15 anos de desenvolvimento e uma arquitetura
sólida que ganhou uma forte reputação de confiabilidade, integridade de dados
e correção. (POSTGRES, 2022).
3.2.2 ARQUITETURA DO SISTEMA
O estilo arquitetural utilizado foi o MVC (Model, View e Controller ), é um
padrão utilizado em muitos projetos devido à sua estruturação, que possibilita a
divisão do projeto em camadas muito bem definidas.

30
A utilização deste padrão traz por praticabilidade o isolamento das regras
de negócios da lógica de apresentação, a interface com o usuário. Com isso é
possível a existência de várias interfaces com o usuário que podem ser
modificadas sem que seja necessário a alteração das regras de negócios,
possibilitando mais flexibilidade em contextos de reuso das classes(MVC, 2011).
As camadas do MVC podem ser definidas como:
● Model: Responsável por gerenciar e controlar a forma como os
dados se comportam por meio das funções, lógica e regras de
negócios estabelecidas.
● Controller: Responsável por fazer intermédio entre as requisições
enviadas pela View com as respostas fornecidas pelo Model,
processando os dados que o usuário informou e repassando para
outras camadas.
● View: Responsável por apresentar as informações de forma visual ao
usuário (as telas das páginas, botões etc).
Figura 11 – Fluxograma modelo MVC

31
Detalhadamente, os passos mostrados na figura 11, são:
1. A partir de uma URL acessada no navegador, essa requisição é enviada

ao controlador do framework, o Spring MVC.
2. Este controler identifica qual classe é responsável por tratar essa
requisição, entregando a ela os dados enviados pelo navegador. Essa classe faz o
papel do controller.
3. O controller, por sua vez, tem a responsabilidade de transmitir os dados
para o model, que por sua vez executa todas as regras de negócio, como
cálculos, validações e acesso ao banco de dados.
4. O resultado das operações realizadas pelo model é retornado ao
controller.
5. O controller retorna o nome da view, junto com os dados que ela precisa
para renderizar a página.
6. O Framework encontra a view que processa os dados, transformando o

resultado em um HTML.
7. Por fim, o HTML é retornado ao navegador do usuário.
Por ser um padrão de projeto bastante utilizado entre os desenvolvedores, o

estilo arquitetural MVC traz consigo diversas vantagens no seu uso, entre elas:
● Manutenção do sistema se torna mais fácil;
● Reaproveitamento de código, principalmente da camada de
modelo, que pode ser reutilizada em outros projetos;
● As alterações na camada de visualização não afetam as regras de
negócios já implementadas na camada de modelo;
● Permite o desenvolvimento, testes e manutenção de forma isolada
entre as camadas;
32
● O projeto passa a ter uma melhor organização em sua arquitetura;
● Torna o entendimento do projeto mais fácil para novos
programadores que não participaram de sua criação(MVC, 2011).
4. RESULTADOS
A aplicação desenvolvida neste trabalho dividiu-se em quatro módulos,
como exposto na seção 3.2.1, e neste tópico serão apresentadas as telas do
sistema, assim como também será apresentada a funcionalidade de
autenticação e autorização do usuário e o framework que utiliza.
4.1 AUTENTICAÇÃO E AUTORIZAÇÃO DO USUÁRIO
A autenticação no sistema se dá através do framework Spring Security, este
framework traz consigo recursos de segurança em aplicações Spring Boot. O foco
dele é o sistema de autenticação e autorização. Na autenticação o processo é
basicamente de validação de credenciais que o usuário inseriu, e o processo
posterior é o de autorização, onde este é verificado as permissões de rota
daquele usuário, e esse processo de autorização se dá através de algumas
interfaces que devem ser implementadas no sistema, e nelas são realizadas as
regras de negócio quanto à autenticação e autorização do usuário. Na figura 12
é exposta a tela de login do sistema.
Figura 12 – Tela de Login

33
4.2 CADASTRO DE USUÁRIO
No sistema o cadastro de usuário pode se dar de duas formas, pode ser
feito diretamente pelo administrador, onde o usuário já fica habilitado pra usar o
sistema, ou pode ser feito pelo “CADASTRAR-SE” da tela login, onde por lá o
usuário fica desabilitado de uso do sistema até que o administrador o habilite, e
por padrão o tipo de usuário neste caso de uso será o “Requisitante”, passível de
alteração pelo administrador, já no cadastro feito diretamente pelo
administrador, o mesmo poderá selecionar qual o tipo daquele usuário que está
sendo cadastrado. Na tela de cadastro de usuário é possível selecionar o setor ao
qual o usuário faz parte, é relevante para identificar o setor em que aquele
usuário abrirá chamados, entre os campos do formulário de cadastro de usuário
se encontra o “Nome de usuário” o valor deste será o utilizado para efetuar login
no sistema.
A figura 13 retrata a tela de cadastro de usuário pelo “CADASTRAR-SE” e a
figura 14 pelo administrador.
Figura 13 – Tela de cadastro

34
Figura 14 – Tela de cadastro pelo administrador
4.3 MÓDULO DO REQUISITANTE
O módulo do requisitante é o mais simples do sistema, contendo função
apenas de abrir, editar e detalhar um chamado. A tela inicial do requisitante
(Figura 15) possui a listagem de chamados referentes ao usuário logado, e se
divide em 4 abas: Abertos, Em Andamento, Em Atraso e Concluídos. Os
chamados em atraso são aqueles que não foram concluídos em até 30 dias
depois de sua abertura.
Figura 15 – Tela inicial do requisitante

35
A tela de cadastro de chamado (figura 16) possui dois campos para
cadastro, sendo a descrição, algo específico do que ocorreu, e um campo para
problema, sendo estes problemas algo mais genérico e que é cadastrado pelo
administrador, esta mesma tela de cadastro de chamado é utilizada na edição
do chamado.
Figura 16 – Tela de cadastro do chamado
A tela de detalhes do chamado contém todas as informações sobre
aquele chamado que foi cadastrado:
● O status (que pode ser: Aberto, Em Andamento, Em atraso ou Concluído);
● O problema;
● O requisitante (usuário que cadastrou aquele chamado);
● A data em que o chamado foi cadastrado;

36
● O operador que está atendendo aquele chamado (caso não tenha um
operador atendendo aparece uma mensagem alertando o usuário sobre
isso “Nenhum operador atendendo a este chamado.”;
● A descrição daquele chamado informada no ato de seu cadastro, uma
descrição dada pelo operador (esta descrição é mais técnica e dada pelo
operador ao concluir/finalizar o atendimento daquele chamado);
● A solução dada pelo operador (este campo é técnico e feito pelo
operador ao concluir/finalizar o atendimento daquele chamado);
● O setor que seria o setor do usuário que abriu aquele chamado;
Na Figura 17 é possível visualizar a tela de detalhes de chamados no
sistema.
Figura 17 – Tela de detalhes do chamado

37
4.4 MÓDULO DO OPERADOR
O Módulo do operador herda todas as funções do módulo requisitante
(como mostrado na figura 9 pelo diagrama de casos de uso), e é acrescentado
funções extras, sendo elas: Atender chamado, Finalizar chamado, e uma
visualização em cards dos chamados (Figura 18) que está atendendo sendo
divididos pelos status dos chamados.
Embora seja similar a tela inicial do requisitante, a listagem é um pouco
diferente, pois além de listar os chamados que o próprio operador possa abrir, na
aba “Abertos” contém todos os chamados abertos para o setor em aquele
usuário opera (Em andamento, em Atraso e Concluídos são apenas referentes ao
usuário e não ao setor).
Figura 18 – Tela inicial operador
Ao finalizar o atendimento de um chamado um modal é exposto ao
operador (Figura 19), nele existem dois campos opcionais que seriam: Descrição
38
do problema (descrevendo de uma forma mais técnica do que se tratava o
problema daquele chamado) e a Solução (descrevendo qual passo a passo,
medidas e/ou ferramentas foram utilizadas no atendimento daquele chamado
para solucioná-lo).
Figura 19 – Modal de finalização de atendimento do chamado
4.5 MÓDULO DO RESPONSÁVEL DO SETOR
O Módulo responsável do setor herda todas as funções do módulo
operador, que por sua vez herda do requisitante (como mostrado na figura 9 pelo
diagrama de casos de uso), porém diferentemente dos outros módulos, este
apresenta um menu lateral com as opções de Página Inicial (Nesta aba é aba
são apresentados cards da contagem de chamados por status de atendimento
como mostrado na figura 20, e a listagem dos chamados). O que diferencia do
módulo do operador é que a listagem dos chamados é geral deste setor, então
39
os chamados abertos, em andamento, em atraso e concluídos são todos
daquele setor, assim como também a contagem destes chamados nos cards.
Figura 20 – Tela Inicial Responsável do Setor
Neste módulo também temos a aba de “Meus Atendimentos” onde esta
traz consigo a listagem dos chamados que o Responsável do setor está
atendendo, dividindo-se em duas abas: Em andamento e Em atraso, como
mostra a figura 21.
Figura 21 – Tela de Meus Atendimentos

40
4.5.1 Usuários
O responsável do setor também tem a funcionalidade de cadastrar
usuários, a mesma pode ser acessada pela aba “Usuários” como mostra a figura
22. Nesta aba é possível fazer o cadastro do usuário que segue a estrutura da
figura 14, e também é possível visualizar a listagem de usuários do setor do
responsável.
Figura 22 – Tela de Usuários
4.5.2 Problema
Na aba de “Problemas” o responsável do setor tem acesso às
funcionalidades de listagem e cadastro de problemas. A listagem dos problemas
traz os problemas cadastrados para o setor do responsável (Figura 23).

41
Figura 23 – Tela de Problemas
Ao cadastrar um problema o responsável terá de preencher um formulário
contendo informações deste problema (Figura 24), sendo o nome e a descrição
do problema.
Figura 24 – Tela de Cadastro de Problema

42
4.5.3 Relatório do Setor
O relatório do setor traz consigo os Operadores mais eficientes (aqueles que
atenderam a mais chamados) e os problemas mais recorrentes para aquele setor.
Figura 25 – Relatório do Setor
4.6 ADMINISTRADOR
O Módulo do Administrador herda todas as funções dos módulos anteriores
(como mostrado na figura 9 pelo diagrama de casos de uso), Sua tela inicial é
similar ao do Responsável do setor diferenciando-se apenas os chamados
listados, pois no módulo do operador na tela inicial serão listados todos os
chamados de todos os setores, assim como a contagem feita nos cards é
referente a todos os chamados do sistema (Figura 26).

43
Figura 26 – Tela Inicial do Administrador
Os chamados do setor do administrador serão listados na aba “Chamados”
e lá ele também terá a opção de atender aos chamados. (Figura 27).
Figura 27 – Tela de chamados

44
4.6.1 Setor
O módulo do administrador tem a funcionalidade de gerenciar os setores.
Na figura 28 temos a tela de listagem dos setores do sistema e na 29 a tela de
cadastro e edição de um setor.
Figura 28 – Tela de listagem dos setores
Figura 29 – Tela de cadastro de setor

45
4.6.2 Usuários pendentes
O Administrador também tem acesso aos “Usuários Pendentes” que seriam
os usuários que fizeram o cadastro pelo “CADASTRAR-SE” da tela de login, como
explicado na seção 4.2, nessa aba é possível que o administrador habilite um
usuário para usar o sistema ou exclua ele, também é possível identificar quantos
usuários estão pendentes para habilitar pelo menu lateral (Figura 30).
Figura 30 – Tela de usuários pendentes
4.6.3 Relatório por Setor
O relatório por setor traz consigo, a partir do setor selecionado, os
Operadores mais eficientes (aqueles que atenderam a mais chamados) e os
problemas mais recorrentes.

46
Figura 31 – Relatório por Setor
5. CONSIDERAÇÕES FINAIS
Este trabalho de conclusão de curso teve seu objetivo concluído, sendo o
desenvolvimento de um sistema web de controle de chamados voltado
especialmente para a Escola Agrícola de Jundiaí (EAJ), visando substituir o atual
sistema utilizado, que é Ocomon, que por sua vez apresenta falhas quanto à
cadastros de usuários, lentidão no sistema, falha em relatórios, e o sistema
desenvolvido (Tauros) buscou solucionar esses problemas, aprimorar essas
funcionalidades e proporcionar uma melhor experiência ao usuário.
O desenvolvimento do sistema foi feito em etapas, e a cada etapa foram
feitas validações com o usuário principal, que é o gerente da equipe de suporte
de informática da EAJ. O trabalho também apresentou como a arquitetura MVC
pode facilitar o desenvolvimento de um sistema web. Além disso, o
desenvolvimento do sistema possibilitou a prática de conceitos importantes nas
etapas do desenvolvimento do software. Para especificação dos requisitos do
sistema, foram utilizados recursos da Linguagem de Modelagem Unificada (UML)

47
como os diagramas de casos de uso. Na modelagem de dados, os diagramas de
classes foram utilizados para definir as entidades do modelo. As demais,
ferramentas como a IDE Intellij e Dbeaver foram usadas durante o
desenvolvimento.
5.1 TRABALHOS FUTUROS
A fim de tornar o sistema desenvolvido mais adequado e otimizado para
os usuários, as seguintes as atividades podem ser realizadas:
• Implementar mais opções de relatórios conforme a necessidade do
usuário, e com opção de exportação em excel ou pdf.
• Transformar o sistema em um container para que possa rodar no docker.
• Realizar um estudo sobre outras formas que a aplicação possa ser
desenvolvida e verificar os ganhos que se pode obter com isso, por exemplo por
uma API REST e um framework front-end separado.

48
REFERÊNCIAS
BAUMGARTEN, Matheus Roberto. DESENVOLVIMENTO DE PROTÓTIPO DE SISTEMA WEB PARA
GERENCIAMENTO DE CHAMADOS BASEADO EM ITIL. 2018. 77 f. TCC (Graduação) - Curso de
Sistemas de Informação, Centro de Ciências Exatas e Naturais, Universidade Regional de
Blumenau, Blumenau, 2018.
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro:
Campus, 2002.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 6ª ed. Rio de
Janeiro: Elsevier, 2005.
CARNELL, J. Spring Microservices in Action. [S.l.]: Manning Publications Company, 2017.
CAVALARI, Gabriel O. T.; COSTA, Heitor A. X. Modelagem e desenvolvimento de um Sistema
Help-Desk para a Prefeitura Municipal de Lavras-MG. Revista Eletrônica de Sistemas de
Informação, Lavras, Dez. 2005. Disponível em: . Acesso em: 05 set. 2006.
CUSTÓDIO, Franque. OcoMon. 2002. Disponível em: https://ocomonphp.sourceforge.io.
Acesso em: 29 jun. 2022.
DBEAVER: Free Universal Database Tool. Dbveaver - Free Universal Database Tool. 2011.
Disponível em: https://dbeaver.io. Acesso em: 05 nov. 2022.
GUTIERREZ, F. Pro Spring Boot. [S.l.]: Springer, 2016.
JAVA Virtual Machine (JVM). 2013. Allan. Disponível em:
https://www.devmedia.com.br/introducao-ao-java-virtual-machine-jvm/27624. Acesso em: 19 nov.
2022.
MVC - Java. 2011. Marcio. Disponível em:
https://www.devmedia.com.br/padrao-mvc-java-magazine/21995. Acesso em: 19 nov. 2022.

49
POSTGRES (Org.). About. 2022. Disponível em: https://www.postgresql.org/about/. Acesso
em: 14 nov. 2022.
TECLIB (Paris). GLPI - PROJECT. 2015. GLPI Copyright © 2015-2022 Teclib. Disponível em:
https://glpi-project.org/pt-br/. Acesso em: 16 jun. 2022.
THYMELEAF. Thymeleaf. 2022. Disponível em:https://www.thymeleaf.org . Acesso em: 14 nov.
2022.
WEBB, P. e. a. How-to guides. 2017. Disponível em: hhttps://docs.spring.io/spring-boot/
docs/current/reference/html/howto-embedded-web-servers.html.

TCC Mario Estevam

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC Mario Estevam

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

UNIDADE ACADÊMICA ESPECIALIZADA EM CIÊNCIAS AGRÁRIAS –

Mario Estevam de Freitas Neto

TAUROS: TECNOLOGIA APLICADA À UNIDADE DE RESOLUÇÃO PARA

Tauros: Tecnologia Aplicada à Unidade de Resolução Para Ocorrências

Monografia apresentada ao curso superior

Coorientador(a): Prof. Dr Taniro Chacon

TAUROS: TECNOLOGIA APLICADA À UNIDADE DE RESOLUÇÃO PARA OCORRÊNCIAS

Trabalho de conclusão de curso de graduação apresentado à Unidade

Aprovado em: 22 de dezemrbo de 2022.

Profa. Dra. Carla da Costa Fernandes - UFRN (orientadora)

Prof. Dr. Taniro Rodrigues Chacon - UFRN (coorientador)

Prof. Dra. Tasia Moura do Vale - UFRN (membro interno)

Prof. Dra. Huliane Medeiros Da Silva - UFRN (membro interno)

Agradeço primeiramente a Deus pela sabedoria e entendimento que me

Jean Fernandes, George Mendonça e Enuch Santos pelo apoio, incentivo e

companheirismo nos dias difíceis da faculdade.

Aos meus familiares e à minha digníssima namorada pelo apoio e incetivo

A minha orientadora, pelo emprenho dedicado à elaboração deste

A todos que direta ou indiretamente fizeram parte da minha formação, о

meu sincero obrigado.

Neste trabalho de conclusão de curso foi desenvolvido um sistema web para

controle de chamados, voltado especialmente para o setor de suporte de

informática da instituição EAJ (Escola Agrícola de Jundiaí) devido problemas e

bugs encontrados no sistema atualmente utilizado. O sistema desenvolvido fez uso

da linguagem JAVA, e de frameworks como Spring boot e Spring MVC. A

arquitetura utilizada foi a MVC assim como a apresentação das principais

vantagens do uso desta arquitetura. Os módulos de autenticação e autorização

fazem uso do Spring Security. É apresentado os diagramas de caso de uso do

sistema, a modelagem do banco, assim como outras tecnologias utilizadas.

Como resultado o sistema desenvolvido agradou ao usuário principal que é o

ele, como um simples cadastro de usuário, além de apresentar uma interface

mais elegante também.

Palavras-chave: Java, Spring Boot, Spring MVC, Spring Security,MVC.

presenting a more elegant interface as well.

Keywords: Java, Spring Boot. Spring MVC.,Spring Security, MVC.

Figura 1 – Tela de abertura de ocorrência 15

Figura 2 – Tela principal do módulo CMDB 16

Figura 3 – Tela principal do módulo HELP DESK 16

Figura 4 – Tela de gerenciamento do módulo GESTÃO FINANCEIRA 17

Figura 5 – Tela principal do protótipo 18

Figura 6 – Tela de visualização dos chamados 19

Figura 7 – Tela de abertura de chamado 19

Figura 8 – Diagrama MER 22

Figura 9 – Diagrama de casos de uso 25

Figura 10 – Diagrama de Classes 26

Figura 11 – Fluxograma modelo MVC 30

Figura 12 – Tela de Login 32

Figura 13 – Tela de cadastro 33

Figura 14 – Tela de cadastro pelo administrador 34

Figura 15 – Tela inicial do requisitante 34

Figura 16 – Tela de cadastro do chamado 35

Figura 17 – Tela de detalhes do chamado 36

Figura 18 – Tela inicial operador 37

Figura 19 – Modal de finalização de atendimento do chamado 38

Figura 20 – Tela Inicial Responsável do Setor 39

Figura 21 – Tela de Meus Atendimentos 39

Figura 22 – Tela de Usuários 40

Figura 23 – Tela de Problemas 41

Figura 24 – Tela de Cadastro de Problema 41

Figura 25 – Relatório do Setor 42

Figura 26 – Tela Inicial do Administrador 43