Post on 06-Apr-2020
i
SISTEMA DE FISCALIZAÇÃO EM CAMPO COM
INTEGRAÇÃO ANDROID/WEB – CHECKLISTS
DINÂMICAS
Leonardo Mendes de Moura Carvalho
Projeto de Graduação apresentado ao Curso de
Engenharia Eletrônica e de Computação da Escola
Politécnica, Universidade Federal do Rio de
Janeiro, como parte dos requisitos necessários à
obtenção do título de Engenheiro.
Orientador: Heraldo Luís Silveira de Almeida
Rio de Janeiro
Setembro de 2019
ii
iii
iv
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Escola Politécnica – Departamento de Eletrônica e de Computação
Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária
Rio de Janeiro – RJ CEP 21949-900
Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que
poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar
qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre
bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja
ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem
finalidade comercial e que seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).
v
AGRADECIMENTO
Gostaria de agradecer primeiramente aos meus pais, Luiz e Cristiane, por todo
apoio tanto emocional como estrutural e por todo o esforço para me proporcionar uma
educação de qualidade. Por também serem exemplos profissionais e humanos para
minha formação como indivíduo e cidadão.
À minha irmã e meu cunhado, Luiza e Fabio, que sempre me deram todo apoio e
compreensão que um irmão pode precisar.
À minha prima, Paula, que esteve sempre próxima de mim e me proporcionou
momentos maravilhosos e de descontração durante todos esses anos de formação.
Aos demais familiares e amigos por todo o apoio que sempre deram.
Aos amigos que conheci durante a faculdade por tornar os dias difíceis e as
noites mal dormidas um pouco mais fáceis de superar. Em especial meus amigos Pedro
Coelho, Luiz Vasconcelos e Ignácio Ricart que até hoje se encontram muito presentes
em minha vida e que sei que sempre poderei contar.
Aos demais amigos por todo o apoio e momentos felizes e descontraídos, mesmo
em tempos difíceis. Em especial Adriano, Nathália e Gabriel que sorriram com minhas
vitórias e sofreram minhas derrotas comigo.
Ao professor e orientador Heraldo, pelos esforços nos fins de semana e
madrugadas para me ajudar a concluir este projeto.
E por fim, a todo o corpo docente da UFRJ por ministrar um dos cursos de maior
excelência no país.
vi
RESUMO
Este trabalho tem por objetivo apresentar uma melhoria para uma plataforma de
gestão de força de campo já implementada na área de telecomunicações. A plataforma
original funcionava de forma muito restrita para a criação de novas atividades a serem
fiscalizadas.
Este projeto implementa uma solução que flexibiliza em muito a utilização do
sistema, de maneira que os usuários não dependem dos desenvolvedores para criar
novas atividades, permitindo que a plataforma seja facilmente adaptada para qualquer
tipo de cliente.
Palavras-Chave: Gestão de força de campo, desenvolvimento de software, mapeamento
de processo.
vii
ABSTRACT
This study aims to present an improvement for a workforce management
platform already implemented in the Telecommunications industry. The platform works
in a very limited way for the creation of new activities to be supervised.
This project implements a solution that greatly improves the flexibility of the
system, in such a way that the end-user does not depend on any developer to include
new activities and allows the platform to easily adapt to any other clients need.
Keywords - PI control: Workforce management, software development, process
mapping.
viii
SIGLAS
DOM – Document Object Model
HTML – Hyper Text Markup Language
IDE – Integrated Development Environment
JVM – Java Virtual Machine
JSON – JavaScript Object Notation
MS SQL Server – Microsoft Structured Query Language Server
REST – Representational State Transfer
ix
Sumário
1. Introdução .............................................................................................................. 1
1.1. Tema .............................................................................................................. 1
1.2. Delimitação .................................................................................................... 1
1.3. Justificativa ..................................................................................................... 1
1.4. Objetivo .......................................................................................................... 1
1.5. Metodologia ................................................................................................... 2
1.6. Descrição ........................................................................................................ 2
2. Especificação do Projeto ........................................................................................ 3
2.1. Análise do problema ....................................................................................... 3
2.2. Análise dos Requisitos .................................................................................... 3
2.3. Solução proposta............................................................................................. 5
3. Ferramentas ........................................................................................................... 6
3.1. Software Base ................................................................................................. 6
3.1.1. Linguagem de Programação: Java ................................................................... 6
3.1.2. Web Services: REST ....................................................................................... 6
3.1.3. JavaServer Pages ............................................................................................ 6
3.1.4. Web Server: Apache Tomcat .......................................................................... 7
3.1.5. Banco de Dados: Microsoft SQL Server ......................................................... 7
3.1.6. JavaScript ....................................................................................................... 7
3.1.7. Git .................................................................................................................. 8
3.2. Bibliotecas utilizadas ...................................................................................... 8
3.2.1. JDBC Driver for SQL Server .......................................................................... 8
3.2.2. JSON-Java ...................................................................................................... 8
x
3.2.3. Java-Jackson ................................................................................................... 8
3.2.4. Java-Jersey ..................................................................................................... 9
3.2.5. JavaScript-jQuery ........................................................................................... 9
3.2.6. JavaScript – jQuery-ui .................................................................................... 9
3.2.7. JavaScript – modernizr ................................................................................... 9
4. Descrição técnica ................................................................................................. 10
4.1. Estrutura de dados......................................................................................... 10
4.1.1. Núcleo de tarefas .......................................................................................... 10
4.1.2. Tabelas auxiliares para tarefas ...................................................................... 10
4.1.3. Tabelas de Checklist ..................................................................................... 11
4.1.4. Núcleo de fiscalizações ................................................................................. 12
4.1.5. Tabelas auxiliares para fiscalizações ............................................................. 13
4.2. Portal ............................................................................................................ 14
4.2.1. Hospedagem e Estrutura ............................................................................... 14
4.2.2. Estrutura de classes e back-end ..................................................................... 15
4.2.3. Casos de uso e front-end ............................................................................... 17
5. Resultados ........................................................................................................... 19
6. Conclusões .......................................................................................................... 22
6.1. Avaliação do Projeto ..................................................................................... 22
6.2. Propostas de melhoria do projeto .................................................................. 23
Bibliografia ................................................................................................................. 24
xi
Lista de Figuras
Figura 1 – Schema do banco de dados ........................................................................... 5
Figura 2 – Diagrama de Classe DTO ........................................................................... 15
Figura 3 – Diagrama de casos uso ............................................................................... 18
Figura 4 – Exibição de uma checklist genérica no aplicativo ....................................... 20
Figura 5 – Tela de login do sistema web ..................................................................... 21
Figura 6 – Tela de listagem de checklists ..................................................................... 21
Figura 7 – Tela de edição de checklists ....................................................................... 22
1
Capítulo 1
1.Introdução
1.1. Tema
O trabalho compreende uma funcionalidade de gerenciamento e criação dinâmica de
checklists para permitir a utilização de um sistema de gestão de força de campo, voltado
para fiscalizações, em qualquer tipo de indústria.
1.2. Delimitação
O projeto é parte de um sistema de gestão de força de campo que atualmente é
utilizado no contexto de fiscalizações de instalações da indústria de telecomunicações.
Tanto em ambiente de cliente quanto em instalações nas ruas e locais isolados. O
objetivo deste projeto é permitir a generalização deste sistema para novas áreas.
1.3. Justificativa
Existem inúmeras aplicações para um sistema de fiscalizações com integração entre
a plataforma móvel Android [1] e um sistema Web. O sistema no qual este projeto foi
implementado estava extremamente engessado e preso à realidade dos clientes na área
de Telecomunicações.
A motivação para o desenvolvimento deste projeto era a necessidade de
apresentar protótipos para potenciais clientes de forma rápida e sem grandes esforços,
além disso permitir ao usuário uma maior customização da ferramenta sem a
necessidade de contatar os desenvolvedores para tarefas meramente braçais e
complicadas.
1.4. Objetivo
O objetivo geral é reduzir o trabalho necessário para desenvolver novas checklists e
expandir a abrangência do sistema para novas indústrias e funcionalidades, poupando
assim tempo dos desenvolvedores e disseminando o produto para novos mercados.
2
1.5. Metodologia
O processo de fiscalização começa quando uma pessoa que tem acesso de
coordenador acessa o sistema através de um computador e cria uma fiscalização, esta é
então atribuída a um fiscal que, ao acessar o sistema através do aplicativo, recebe uma
notificação de que uma nova fiscalização foi atribuída a ele.
Na listagem de fiscalizações o técnico tem acesso ao endereço do local a ser
fiscalizado, o tipo de fiscalização, o horário agendado entre outras informações. Uma
vez selecionada uma fiscalização, a respectiva checklist é exibida e deve ser preenchida.
Caso algum dos itens seja rejeitado, ou seja, se não estiver conforme os padrões
estabelecidos, uma foto deve ser tirada para evidenciar essa rejeição.
Uma vez completa, a fiscalização é encerrada pelo fiscal. Se o tablet ou celular tiver
acesso à internet a fiscalização é enviada ao servidor junto com todas as fotos de
evidências. O coordenador então avalia a fiscalização e as fotos dos itens rejeitados. Se
algo não estiver de acordo com os padrões estabelecidos, a fiscalização volta para o
fiscal com os itens que não estão acordados destacados, para que seja feita uma
retificação. Se tudo estiver de acordo, aquela fiscalização é aceita e segue para o setor
financeiro, também contemplado no sistema, que no final do mês fornece o valor total
que deve ser pago pela empresa contratante para a fiscalizadora contratada.
Este é um processo sensível e de extrema importância para as empresas de
telecomunicações pois garante o bom funcionamento e a qualidade de suas
instalações,além de lidar com milhares de reais e informações sobre pagamentos das
empresas.
A expansão desse sistema para novos setores de mercado garante uma margem de
lucro maior para a empresa desenvolvedora, visto que o esforço para o desenvolvimento
das plataformas será cada vez menor.
1.6. Descrição
O capítulo 2 apresenta a origem do problema, a especificação e a solução proposta
para sua resolução.
No capítulo 3 apresento as tecnologias utilizadas e os motivos pelos quais este
projeto foi desenvolvido com elas.
3
No capítulo 4 detalho cada parte da aplicação, tanto do ponto de vista técnico como
do funcional, passando pelo banco de dados, front-end e back-end.
No capítulo 5 são apresentados os resultados e no capítulo 6 as conclusões.
Capítulo 2
2.Especificação do Projeto
2.1. Análise do problema
O problema que este projeto se propõe a solucionar está ligado à criação e
modificação das checklists utilizadas nas fiscalizações de campo realizadas pelos
técnicos de grandes empresas do setor de telecomunicações e terceiros.
Este problema foi identificado após a ferramenta ser utilizada em ambiente de
produção onde, por necessidades que não haviam sido identificadas anteriormente,
novas checklists e checklists já existentes eram criadas e modificadas manualmente por
desenvolvedores diretamente na base de dados, por meio de um processo exaustivo que
podia levar dias, onde planilhas eram enviadas pelo cliente, extrações da base de dados
eram feitas para então comparar o que já estava no formato desejado e o que deveria ser
modificado. A necessidade destas modificações não foi mapeada na fase de
identificação e colheita de insumos para início dos desenvolvimentos.
Além do problema imediatamente supracitado, este projeto facilita substancialmente
a utilização desta ferramenta por novos clientes e até mesmo por clientes de novos
segmentos de mercado, pois a criação de checklists complexas passa a ser feita de forma
simples, com uma interface prática e permitindo modificações futuras sem a intervenção
de desenvolvedores ou qualquer tipo de suporte.
2.2. Análise dos Requisitos
Para a solução do problema, alguns requisitos precisavam ser atendidos de modo
que a criação das checklists fosse completamente flexível para atender qualquer tipo de
demanda. Estes requisitos serão citados a seguir e, posteriormente, serão descritas as
propostas para que sejam cumpridos.
4
O principal requisito era que as checklists pudessem ser alteradas com facilidade e
por uma interface gráfica, também deveria ser possível criar checklists da mesma forma.
Estas checklists deveriam poder conter itens de diferentes formatos, cada um deles com
suas peculiaridades.
Um dos itens mais básicos foi intitulado EVAL, de evaluation, este item se resume à
uma múltipla escolha com as seguintes opções de resposta:
1. Não aplicável – (NA)
2. Rejeitado – (RE)
3. Aceito com restrições – (AC)
4. Aceito sem restrições – (AS)
Este é o item mais básico e mais utilizado nas checklists dos clientes que utilizam o
sistema.
Outro item básico, porém muito importante, é o de título, intitulado title. Este item
serve para separar a fiscalização em seções de forma a melhor organizar os subitens.
Eram importantes itens customizáveis com perguntas que podem ter respostas de
múltipla escolha configuráveis, itens com respostas como contadores e itens que têm
como resposta uma ou mais fotos.
Os itens das checklists também deviam poder ter restrições, ou seja, alguns itens
apenas seriam exibidos dependendo da resposta de um outro item. De forma similar,
alguns itens poderiam ser obrigatórios dependendo da resposta de outros itens.
Itens deveriam poder ser obrigatórios ou opcionais e ter comentários e/ou fotos
também obrigatórios ou opcionais. Os itens também deveriam poder ser aninhados uns
dentro dos outros, por exemplo, um item que tivesse como resposta um contador,
deveria poder ter itens filhos da quantidade selecionada no contador.
5
2.3. Solução proposta
Para atender todos estes requisitos citados na seção anterior, a modelagem do banco
de dados foi uma etapa de suma importância. O modelo final é similar a um snowflake
schema com basicamente duas tabelas fato principais (AUDIT e TASK) e algumas
tabelas secundárias ligadas a elas, como na figura a seguir:
Figura 1– Schema do banco de dados
O banco pode ser separado em duas seções, uma com o núcleo de criação e
customização das tarefas e checklists centrado na tabela TASK, e outro núcleo para o
gerenciamento das fiscalizações e atividades realizadas pela força de campo e equipe de
back office centrado na tabela AUDIT.
Outra etapa importante foi determinar a forma de estruturar, organizar e enviar as
checklists do front-end para o back-end. A abordagem escolhida foi utilizar Servlets para
a comunicação com o servidor, visto que a tecnologia utilizada para o desenvovimento
original da ferramenta era Java [2], é montado no front-end um objeto JSON [3] que
contém todos os itens da checklist, bem como sua ordem e todas as informações
relevantes. Este JSON é enviado para o back-end pelo Servlet anteriormente
mencionado, processado, e inserido no banco de dados. Se tratar de uma inserção de
uma nova checklist ela é apenas inserida na base, caso seja uma edição, a versão
anterior da checklist é desabilitada e a nova versão é criada, este processo é realizado
através da tabela CHECKLIST_VERSION em conjunto com a tabela CHECKLIST.
6
Capítulo 3
3.Ferramentas
3.1. Software Base
3.1.1. Linguagem de Programação: Java
Java é uma linguagem de programação orientada a objetos e, diferentemente de
outras linguagens modernas, é compilada para bytecode que por sua vez é interpretado
por uma máquina virtual, a Java Virtual Machine, mais conhecida como JVM. Esta
característica permite que Java seja executado em qualquer máquina, de forma
independente da arquitetura do processador ou sistema operacional.
Especificamente para este projeto, fazia sentido utilizar Java, por ser uma das
linguagens com maior difusão no mercado, o que facilita encontrar mão de obra
qualificada para realizar novos desenvolvimentos e manutenção. É uma linguagem
simples, o que permite que novos desenvolvedores que não conhecem a linguagem
rapidamente possam contribuir para os desenvolvimentos. Além disso, a quantidade de
recursos disponíveis para consulta é colossal, o que auxilia bastante em
desenvolvimentos como este.
Outro grande motivador é a variedade de bibliotecas e recursos disponíveis para
desenvolvimentos Web na plataforma.
3.1.2. Web Services: REST
Como o sistema possui duas partes que devem se comunicar com o mesmo servidor
(Web e Aplicativo Android), se fez necessária a utilização de Web Services para a
comunicação entre eles.
O sistema desenvolvido é RESTful, ou seja, se enquadra na abstração da arquitetura
da Web chamada REST [4] (Representational State Transfer).
3.1.3. JavaServer Pages
Comumente conhecido como JSP [5], esta tecnologia auxilia na criação de páginas
web dinâmicas, algo que utilizamos com frequência neste projeto, exibindo nossas
checklists por exemplo.
7
Esta tecnologia permite que, por exemplo, uma consulta seja feita no banco de
dados antes mesmo de gerar o código HTML da página e enviar para o cliente.
3.1.4. Web Server: Apache Tomcat
O Apache Tomcat [6] é um Web Server e Servlet container open source que facilita
o desenvolvimento e permite deploy para o servidor de maneira simples e rápida. A
instalação em máquinas para desenvolvimento é bem simples e muitas vezes já vem
instalado ou é facilmente instalado na IDE escolhida para desenvolvimento, que no caso
deste projeto, foi o NetBeans.
3.1.5. Banco de Dados: Microsoft SQL Server
O Microsoft SQL Server [7] foi escolhido para desenvolvimento deste projeto por
possuir opções de baixo ou nenhum custo, dependendo do tamanho da aplicação, além
de ser uma plataforma extremamente consolidada no mercado.
Todos os desenvolvimentos anteriores haviam sido feitos utilizando o MS SQL
Server e portanto fez mais sentido manter, visto ser uma das principais plataformas de
bancos de dados atualmente disponíveis no mercado, possui todas as funcionalidades
necessárias para os desenvolvimentos aqui citados.
É facilmente instalável em qualquer máquina e sua integração com a plataforma
Java é bem simples e estável.
3.1.6. JavaScript
Muitas vezes confundido com Java, JavaScript [8] é uma linguagem de programação
que roda no cliente (navegador) e foi desenvolvida para interação com páginas Web.
Permite a modificação da página em si através da de funções que modificam os códigos
HTML [9] e CSS [10] da página.
Qualquer tipo de interatividade com uma página que não seja estática é
desenvolvida em JavaScript. Mapas interativos, conteúdo atualizado com tempo,
gráficos 2D e 3D, todos são bibliotecas JavaScript.
Neste projeto utilizamos bibliotecas que potencializam o poder do JavaScript,
simplificam o código e permitem a customização do visual das páginas sem a
necessidade de horas escrevendo códigos CSS.
8
3.1.7. Git
Git [11] é uma ferramenta open source extremamente difundida no mercado utilizada
para controle de versão e coordenar desenvolvimentos paralelos feitos por mais de um
programador. Neste projeto, foi utilizado apenas como controle das modificações do
código e como forma de armazenar o código fonte em nuvem para fácil acesso no
futuro.
3.2. Bibliotecas utilizadas
3.2.1. JDBC Driver for SQL Server
Biblioteca Java essencial para o funcionamento deste projeto, a sqljdbc4 [12]
disponibiliza acesso a diversas versões do SQL Server. Está sob uma licença open
source então existem muitas versões disponíveis, porem foi utilizada a versão
distribuída pela própria Microsoft.
3.2.2. JSON-Java
JSON é um formato muito conhecido no mundo da programação, acrônimo para
JavaScript Object Notation, o JSON é uma notação muito utilizada para comunicações
entre clientes e servidores. É um formato de fácil leitura independente da linguagem de
programação escolhida, praticamente todas as linguagens possuem bibliotecas para
manipular dados estruturados desta forma.
Para este projeto, a biblioteca JSON se faz necessária pois a forma que transmitimos
as checklists do cliente (navegador) para o servidor é utilizando esta notação, então
precisamos que nosso servidor saiba interpretá-la de forma rápida e sem código
específico para tal.
3.2.3. Java-Jackson
Jackson [13] é uma biblioteca muito popular que permite serializar ou mapear
objetos Java para JSON e vice versa de forma muito eficiente. Como todas as
bibliotecas utilizadas neste projeto, Jackson é uma biblioteca open source.
Como neste projeto possuímos muitos objetos diferentes, mapea-los manualmente
seria um trabalho extremamente exaustivo. Ao utilizar esta biblioteca diminuímos
bastante o tempo de desenvolvimento e implementação de novas funcionalidades.
9
3.2.4. Java-Jersey
Jersey [14] é uma biblioteca que auxilia no desenvolvimento de Web Services REST
permitindo a utilizaçao de annotations para descrever e construir os Web Services.
Jersey também funciona nativamente com JSON, principal notação utilizada neste
projeto. Outra característica interessante desta biblioteca é que ela funciona sem
nenhum tipo de configuração prévia.
3.2.5. JavaScript-jQuery
jQuery [15] é uma biblioteca JavaScript que foi desenvolvida para simplificar a
manipulação da árvore HTML DOM (Hyper Text Markup Language - Document
Object Model), basicamente uma página HTML é uma árvore de objetos que ficam
aninhados uns dentro dos outros formando assim uma estrutura bem definida. A
biblioteca jQuery facilita em muito a manipulação destes objetos e os objetos
aninhados, normalmente conhecidos como objetos filhos.
jQuery também auxilia na manipulação de eventos, ou seja, quando um clique é
feito em algum objeto, a página é carregada, uma tecla ou sequência de teclas é
pressionada. O jQuery pode ser configurado para executar qualquer código dependendo
de alguma ação esperada.
Esta biblioteca foi amplamente utilizada neste projeto, visto que há muita
manipulação dos elementos do DOM e leitura do mesmo para criar nossas checklists e
então converte-las para JSON e enviar para o servidor.
3.2.6. JavaScript – jQuery-ui
jQuery UI [16] é uma coleção de GUI widget, efeitos visuais animados e temas
implementados em jQuery, portanto para utilizá-la se faz necessário a inclusão de
jQuery no projeto.
Foi utilizada neste projeto para alguns efeitos no menu de navegação e aplicação de
temas, portanto razões estéticas, mas também possui algumas propriedades que
adicionam funcionalidades. Por exemplo, foi utilizada a propriedade ui-sortable para
permitir reordenar as checklists apenas arrastando seus itens para a posição desejada.
3.2.7. JavaScript – modernizr
A biblioteca modernizr [17] auxilia na compatibilidade do sistema com navegadores
antigos ou diferentes em geral. Foi utilizada para garantir que a sistema funcione de
10
forma independente da plataforma, o que é muito importante em um projeto como este,
onde muitas pessoas podem utilizar o portal em máquinas diferentes.
Capítulo 4
4.Descrição técnica
4.1. Estrutura de dados
4.1.1. Núcleo de tarefas
No núcleo de tarefas a principal tabela é a TASK que tem o seguinte script de
criação:
CREATE TABLE DEV.TASK (
TASK_ID int NOT NULL IDENTITY,
TASK_NAME varchar(100) NOT NULL,
PARENT_TASK int,
CHECKLIST_ID int NOT NULL,
TYPE_ID int NOT NULL,
PHOTO_ENABLE bit NOT NULL,
COMMENT_ENABLE bit NOT NULL,
DISPLAY_ORDER int NOT NULL,
MANDATORY bit NOT NULL,
CONSTRAINT Pk_TASK PRIMARY KEY ( TASK_ID )
);
Esta tabela é referenciada por muitas outras tabelas auxiliares, como visto na Figura
2-1, estas tabelas menores servem para melhor descrever a tarefa quando for necessário.
4.1.2. Tabelas auxiliares para tarefas
TASK_OPTION:
11
o Quando a tarefa é do tipo OPTION, contém quais são as opções de
resposta e sua ordem de exibição (DISPLAY_ORDER).
TASK_PHOTO:
o Quando a tarefa é do tipo PHOTO, esta tabela informa a quantidade de
máxima de fotos que podem ser enviadas na resposta e se o
preenchimento de todas elas é obrigatório.
CONDITION_PHOTO_COMMENT:
o Caso os flags PHOTO_ENABLE e COMMENT_ENABEL da tabela
TASK estejam como true, esta tabela dita se a foto e o comentário são
obrigatórios, qual a condição para que as fotos e comentário sejam
obrigatórios e as quantidades mínima e máxima de fotos.
TASK_RESTRICTION:
o Caso a exibição da tarefa dependa da resposta de uma outra tarefa, esta
regra é descrita nesta tabela, onde são armazenadas as informações de
qual é esta tarefa que restringe e qual deve ser a resposta para que seja
exibida.
TASK_TYPE:
o Tabela que contém todos os tipos de tarefas, ela contém ID, nome e
descrição de cada tipo de tarefa.
TASK_EVAL:
o Esta tabela não possui foreign key constraint com a TASK, pois contém
as opções da tarefa do tipo EVAL, que é definida apenas uma vez.
TASK_INCREMENT:
o Quando uma tarefa é do tipo INCREMENT, esta tabela descreve o valor
inicial do contador e seu valor máximo.
TASK_CONDITION:
o Caso uma tarefa dependa da resposta de uma outra para ser respondida,
essa condição é descrita nesta tabela.
4.1.3. Tabelas de Checklist
Basicamente temos duas tabelas referenciadas a checklists, CHECKLIST e
CHECKLIST_VERSION. A tabela CHECKLIST é referenciada pela TASK por sua
12
primary key, desta forma sabemos quais tarefas pertencem a quais checklists. Os
scripts de criação são os seguintes:
CREATE TABLE DEV.CHECKLIST (
CHECKLIST_ID int NOT NULL IDENTITY,
CHECKLIST_NAME varchar(100) NOT NULL,
[ENABLE] bit NOT NULL
CONSTRAINT Pk_CHECKLIST PRIMARY KEY ( CHECKLIST_ID )
);
CREATE TABLE DEV.CHECKLIST_VERSION (
CHECKLIST_ID int NOT NULL,
VERSION int NOT NULL,
ORIGINAL_ID int NOT NULL,
CREATED_BY varchar(50) NOT NULL,
[DATE] datetime NOT NULL
);
O sistema precisava ser completamente retrocompatível, ou seja, checklists que
foram utilizadas em fiscalizações passadas devem permanecer intactas para que
relatórios possam ser gerados e o histórico preservado. Por esta razão, foi criada a
tabela CHECKLIST_VERSION, para que quando uma checklist seja editada,
possamos manter o histórico armazenado. Quando uma checklist é editada, sua
verão anterior é desativada e é gerada uma nova checklist, a checklist original é
referenciada na coluna ORIGINAL_ID, desta forma mantemos o histórico de
versionamento. No caso de edição, na tabela CHECKLIST, um flag é configurado
como false para desativar a checklist anterior.
Quando a checklist é criada, e não editada, ela também é incluída na tabela de
versionamento, porém na coluna ORIGINAL_ID é armazenado o ID dela mesma. A
coluna VERSION serve para controle de qual versão está sendo utilizada e quantas
vezes foi alterada pois é incrementado toda vez que uma checklist é alterada.
4.1.4. Núcleo de fiscalizações
O núcleo de fiscalizações não é o foco deste projeto, mas é importante para
entender o funcionamento do sistema. Ele fica centrado na tabela AUDIT que é
descrita pelo script a seguir:
CREATE TABLE [DEV].[AUDIT](
13
AUDIT_ID int IDENTITY(1,1) NOT NULL,
SITE_ID int NOT NULL,
CHECKLIST_ID int NOT NULL,
CREATOR_USER_ID varchar(50) NOT NULL,
CREATION_DATE datetime NOT NULL,
STATUS_ID int NOT NULL,
OBS varchar(100) NULL,
CONSTRAINT [Pk_AUDIT] PRIMARY KEY CLUSTERED
) ;
Esta tabela, como a TASK, é referenciada por algumas outras tabelas auxiliares,
que ajudam na descrição das fiscalizações.
4.1.5. Tabelas auxiliares para fiscalizações
USER:
o Tabela que contém informações dos usuários, tanto usuários do back
office quanto dos técnicos que realização as fiscalizações em campo. O
usuário que criou a fiscalização é referenciado nela como
CREATOR_USER_ID.
SITE:
o Tabela contém todos os sites, ou seja, os locais físicos onde a
fiscalização será realizada.
STATUS:
o Tabela que contém todos os status que uma fiscalização pode assumir
depois de sua criação, na operação base tínhamos:
1. Por atribuir
2. Atribuído
3. Em execução
4. Executado
5. Aprovado
6. Rejeitado
AUDIT_VERSION:
o Esta tabela controla em que versão a fiscalização está. Ela tem o seguinte
script de criação:
CREATE TABLE [DEV].[AUDIT_VERSION](
14
AUDIT_ID int NOT NULL,
AUDIT_VERSION int NOT NULL,
TECHNICIAN_ID int NOT NULL,
ESTIMATED_START datetime NOT NULL,
ESTIMATED_FINISH datetime NOT NULL,
START datetime NULL,
FINISH datetime NULL,
OBS varchar(200) NULL,
APPROVER_ID int NULL,
APPROVAL_DATE datetime NULL
);
o Como visto na tabela STATUS, uma fiscalização pode ser rejeitada,
neste caso, ela deve ser atribuída novamente a outro técnico e refeita,
apenas os itens que foram rejeitados, por isso, cada uma das versões
pode ter o campo TECHNICIAN_ID com valor diferente.
o As colunas ESTIMATED_START e ESTIMATED_FINISH são
preenchidas na criação da fiscalização, que normalmente são agendadas
para certos horários de início e fim.
o As colunas START e FINISH são as datas e horários que de fato elas
foram realizadas.
o OBS é um campo livre para observações, normalmente preenchidos com
informações técnicas para facilitar o trabalho dos técnicos em campo.
o APPROVER_ID está também ligada a tabela USER e representa o
operador de back office que aprovou a ficalização.
ANSWER:
o A tabela ANSWER contém as respostas individuais de cada tarefa
realizada para uma determinada versão de uma fiscalização.
4.2. Portal
4.2.1. Hospedagem e Estrutura
Os Web Services e o portal deveriam poder ser acessados via internet em qualquer
lugar, por conta desta especificação o sistema foi hospedado no serviço de nuvem da
15
Microsoft, chamado de Azure, em uma máquina virtual que tem como sistema
operacional Windows Server.
Nesta máquina virtual foram instalados o Java, Apache Tomcat e MS SQL Server
para suportar todas as necessidades deste projeto, como mencionado no capítulo de
tecnologias.
4.2.2. Estrutura de classes e back-end
Para a estrutura de classes do back-end as tabelas do banco foram mapeadas para
comportar as tabelas do banco de dados com a mesma estrutura, para tal, foi criado um
package chamado “dto” (Data Transfer Objects), que contém todas as classes utilizadas
para transferência a manuseio dos dados. As classes do pacote dto seguem o diagrama
UML abaixo.
Figura 2 – Diagrama de Classe DTO
16
Como pode ser observado, todas as classes possuem um método chamado toString, este
método retorna a descrição do objeto no tipo String, porém com a notação JSON. Desta
forma podemos facilmente enviar e receber os objetos completos como String.
As tabelas referentes ao núcleo de fiscalizações também possuem seus respectivos
DTOs mas, como não são o foco deste projeto, não serão descritas em detalhe
Na aplicação em sua forma mais crua, ou core, como foi denominada na fase de
desenho e desenvolvimento, no que se trata apenas do essencial para o funcionamento
da ferramenta básica, temos a package “lib”, que contém quatro classes, três delas para
extrair as informações dos bancos e passá-las para os respectivos DTOs e, também, para
escrever dados no banco. A última delas possui alguns métodos essenciais que não estão
diretamente relacionados com o banco de dados. Estas classes serão descritas a seguir.
A primeira destas classes básicas é a SQLEssentials, como o nome sugere, ela é a
classe essencial para o funcionamento básico do sistema especificamente com o que se
relaciona a banco de dados. Ela possui apenas dois métodos no seu estado mais básico,
o checkConnection que recebe apenas um parâmetro, do tipo Connection, verifica se
esta conexão está ativa. Se não estiver, ele apenas retorna um código de erro, caso
contrário, retorna a própria conexão. O segundo método é o getUser que retorna o
usuário baseado no código. O retorno é no formato da classe UserDTO.
A segunda classe é a JavaEssentials, esta classe contém métodos simples, mas que
são recorrentemente utilizados e não estão relacionados com operações no banco de
dados. Os métodos desta classe incluem o escapeString que basicamente higieniza uma
string, removendo caracteres indesejados como “\n” por exemplo. Um outro método
desta classe é o hashPassword, que recebe o valor digitado pelo usuário ao fazer o login
e utiliza o algoritmo MD5 para criação do hash que será comparado com o hash
armazenado no banco. Esta não é a medida mais segura, porém esta não é uma função
final. Dependendo das regras de segurança da empresa que será detentora do sistema,
esta poderá ditar os algoritmos e medidas de segurança necessárias. Por esta razão,
medidas mais seguras não foram implementadas. O terceiro e último método desta
classe é o parseChecklistJson que é utilizado para validar o JSON que é recebido pelo
front-end de uma checklist para seguir como uma inserção ou um update.
Inicialmente parece não haver necessidade da separação destas duas classes, mas
com o avançar de um projeto grande elas podem crescer descontroladamente e a
separação auxilia bastante na manutenção do código.
17
A terceira classe é o SQLChecklist, esta classe contém todos os métodos
relacionados a buscar ou gravar informações relacionadas a checklist. Muitas delas
fazem apenas uma busca no banco baseado em um id específico. Entrarei nos detalhes
apenas dos métodos mais complexos. O primeiro a ser comentado será o getTasks, este
método roda uma query que inicialmente busca no banco uma lista de tarefas baseado
no id de uma checklist e depois chama o método getTask para cara item da lista de
tarefas, preenchendo assim um objeto List<TaskDTO>. O método saveChecklist recebe
um objeto do tipo ChecklistDTO e também recebe um parâmetro do tipo boolean para
determinar se é uma edição de checklist ou apenas uma inclusão. Independentemente de
ser inclusão ou edição, a checklist é criada na tabela CHECKLIST. Posteriormente, se
for criação, é criada apenas a versão da checklist na tabela CHECKLIST_VERSION. Se
for edição é preciso desativar a checklist anterior, selecionar o ID da checklist original,
selecionar o valor da última versão desta checklist orignal e incluir a nova versão no
banco.
A última classe, destas básicas, é a SQLAudit que realiza todas as operações
relacionadas a fiscalizações, porém ela não possui funções complexas em sua forma
original, apenas funções para ler informações do banco baseados em Ids e salvar
informações no banco. Os métodos mais relevantes são o saveAudit, que cria uma
fiscalização no banco, e o assignAudit que atribui a fiscalização a um fiscal.
4.2.3. Casos de uso e front-end
Neste projeto iremos abordar apenas os casos de uso referentes a alteração e criação
de checklists, no diagrama de casos de uso também estão incluídas as funcionalidades
de criação e atribuição de fiscalização, porém estes não serão descritos em detalhe pois
não se incluem no escopo do projeto. O diagrama de casos de uso é ilustrado a seguir.
18
Figura 3 – Diagrama de casos uso
Na funcionalidade de criação de checklist o usuário pode modificar o nome da
checklist, incluir itens, modificar seu tipo com um dropdown e mudar a ordem dos itens.
Como mencionado anteriormente, o principal objetivo deste projeto era simplificar ao
máximo a criação de uma checklist, tendo isto em mente, considerei importante uma
interface simplificada e intuitiva, então quando um item novo é adicionado a uma
checklist ele entra como o último e sempre como o tipo EVAL, caso o usuário queira
modificar ele utiliza o dropdown da linha em questão. Uma parte importante para esta
intuitividade era permitir que o usuário modificasse a ordem dos itens da checklist
arrastando os elementos de uma posição para a outra, esta funcionalidade foi alcançada
utilizando a biblioteca jQuery-ui, mencionada anteriormente.
Sempre que o tipo da linha é modificado, um campo que contém a descrição da
própria linha, no formato JSON, é atualizado com as informações do tipo escolhido. Da
mesma forma, toda vez que a ordem é modificada, é atualizado o JSON de todas as
linhas, alterando, obviamente, sua propriedade “displayOrder”.
19
No fim da edição da checklist, ao clicar no botão “Enviar”, a tabela que contém os
itens é iterada e colocando todos os itens em um array que em seguida é incluído em
um objeto JSON e então enviado, via Servlet para o back-end.
Caso tenha sido uma edição, é enviado para o back-end, como header, um
parâmetro chamado “action” com o valor “editChecklist”, desta forma o back-end sabe
que deve criar uma checklist, cancelar a antiga e enviar para o front-end o novo id de
checklist para que ela seja exibida na página de redirecionamento.
Caso tenha sido uma inclusão apenas, a “action” enviada é “saveChecklist”, neste
caso o back-end sabe que deve apenas criar a nova checklist e enviar o novo id para o
front-end.
Como o back-end, por conta das bibliotecas utilizadas, entende perfeitamente o
formato JSON, o manuseio dos objetos e a inclusão no banco se faz de forma
extremamente simples.
Capítulo 5
5.Resultados
O objetivo deste projeto era otimizar um processo que vinha tomando muito tempo
da equipe de desenvolvedores, além de causar vários problemas de incompatibilidade
com as fiscalizações que já haviam sido concluídas. Levava-se muito tempo para o
próprio cliente determinar e homologar o formato da nova checklist ou até mesmo a
modificação de uma já existente. Uma vez que era finalmente acordado um formato
final, este era passado para a equipe de desenvolvedores que, por sua vez, faziam
alterações diretas nas bases de dados de desenvolvimento para ser testado e mensurar os
impactos que aquelas alterações iriam causar no sistema e na geração de relatórios de
fiscalizações que utilizavam aquelas checklists. Linhas no banco eram removidas, outras
tantas modificadas e, por conta do péssimo desenho e especificação da ferramenta
inicial, este trabalho era extremamente braçal, cansativo e delicado. Um desenvolvedor
às vezes podia levar dias para finalizar as alterações devidamente testadas e
homologadas.
Os resultados deste projeto mostraram que, com um desenho mais cuidadoso da
base de dados, com foco na adaptabilidade do sistema, pudemos reduzir este tempo para
20
apenas alguns minutos. Além disso, pudemos também descentralizar a atividade de
criação e edição de checklists, liberando tempo e recursos dos desenvolvedores que
podem agora passar a realizar atividades mais condizentes com suas capacidades.
Abaixo, uma imagem do módulo Android do Sistema, com uma checklist genérica
em exibição:
Figura 4 – Exibição de uma checklist genérica no aplicativo
21
A seguir alguma figuras do sistema web:
Figura 5 – Tela de login do sistema web
Figura 6 – Tela de listagem de checklists
22
Figura 7 – Tela de edição de checklists
Capítulo 6
6.Conclusões
6.1. Avaliação do Projeto
Este projeto nasceu de uma necessidade de otimizar um processo específico de um
sistema que precisava urgentemente ser otimizado e atualizado. Quando o sistema foi
inicialmente implementado, as especificações foram bem definidas para a realidade na
época, porém, como qualquer sistema, com o tempo, modificações e atualizações se
fazem necessárias.
Tendo isso em mente, foi proposto que fosse feita uma reestruturação completa do
desenho da solução e é exatamente isto que foi realizado neste projeto piloto. Com as
funcionalidades básicas do sistema em mente, foi desenhada uma solução desde a base
de dados até o front e back end para solucionar os gargalos de desenvolvimento já
conhecidos e identificados após anos de uso e amadurecimento do sistema.
Este projeto alcançou seu objetivo e se provou ser uma solução viável para um
problema sistêmico recorrente para a administração e os desenvolvedores do sistema, de
forma que não só a empresa teve a ganhar com os benefícios alcançados, cortando
gastos e investimento de tempo, como o próprio cliente ficou extremamente satisfeito
com a praticidade de utilizar a ferramenta com a nova interface de edição de checklist.
23
Deste projeto também nasceu um MVP (Minimum Viable Product) que pode ser
oferecido e comercializado pela empresa para outros setores da indústria, diferentes de
telecomunicações, disponibilizando de forma rápida e fácil uma POC (Proof Of
Concept) para se mostrada a potenciais clientes.
6.2. Propostas de melhoria do projeto
Muitas melhorias podem ser implementadas neste projeto. Algumas funcionalidades
foram projetadas na etapa de desenho da solução e podem ser vistas na parte de Banco
de Dados, mas nem todas foram implementadas no código. Isto ocorreu por conta de
uma otimização do tempo de projeto. Para que o sistema estivesse pronto com todas as
funcionalidades desejadas, muitos meses de desenvolvimento precisariam ser
investidos. Foi definido que apenas as funcionalidades básicas do principal cliente
usuário do sistema seriam implementadas nesta primeira fase piloto do projeto.
Entre as funcionalidades que foram imaginadas, porém não executadas do projeto estão:
Aninhamento de itens:
o Existe a necessidade de criar itens aninhados, ou seja, itens que podem
estar dentro de um outro item. Esta funcionalidade foi desenhada na
base de dados, porém não implementada no front e back end.
Restrição de itens:
o A funcionalidade de restringir um item, de modo que ele só seja exibido
baseado na resposta de um outro item. Também está contemplado no
desenho da base, porém não no front e back end.
Itens de incremento:
o Estes itens, que tem por resposta um contador, também foi planejado na
base, porém não implementado.
Customização da aparência:
o Permitir customização da aparência da ferramenta para refletir as cores e
marca do cliente.
24
Bibliografia
[1] Android
Acesso em agosto de 2019. https://www.android.com
[2] Oracle Corporation
Acesso em agosto de 2019. https://www.java.com/pt_BR
[3] Douglas Crockford
Acesso em agosto de 2019. https://www.json.org
[4] Roy T. Fielding
Acesso em agosto de 2019. https://restfulapi.net/rest-architectural-constraints/
[5] Oracle Corporation
Acesso em agosto de 2019.
https://docs.oracle.com/javaee/5/tutorial/doc/bnagy.html
[6] The Apache Software Foundation
Acesso em agosto de 2019. http://tomcat.apache.org/
[7] Microsoft
Acesso em agosto de 2019. www.microsoft.com/sqlserver/
[8] Brendan Eich
Acesso em agosto de 2019.
https://developer.mozilla.org/en-US/docs/Web/JavaScript
[9] WHATWG
Acesso em agosto de 2019. https://whatwg.org/
[10] W3C
Acesso em agosto de 2019. https://www.w3.org/Style/CSS/
25
[11] Software Freedom Conservancy
Acesso em agosto de 2019. https://git-scm.com/
[12] Oracle Corporation
Acesso em agosto de 2019.
https://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/
[13] Jackson Project
Acesso em agosto de 2019. https://github.com/FasterXML/jackson
[14] Oracle Corporation
Acesso em agosto de 2019. https://jersey.github.io/
[15] The jQuery Foundation
Acesso em agosto de 2019. https://jquery.com
[16] The jQuery Foundation
Acesso em agosto de 2019. https://jqueryui.com/
[17] “Modernizr”
Acesso em agosto de 2019. https://modernizr.com/