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/