UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA
BACHARELADO EM ENGENHARIA DE SOFTWARE
DESENVOLVIMENTO DE UM APLICATIVO MÓVEL PARA CONTROLE PATRIMONIAL
MAYCHELL FERNANDES DE OLIVEIRA
NATAL - RN Novembro de 2017
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE BACHARELADO EM ENGENHARIA DE SOFTWARE
DESENVOLVIMENTO DE UM APLICATIVO MÓVEL PARA CONTROLE PATRIMONIAL
MAYCHELL FERNANDES DE OLIVEIRA
NATAL - RN
DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA Novembro de 2017
DESENVOLVIMENTO DE UM APLICATIVO MÓVEL PARA CONTROLE PATRIMONIAL
Monografia de Graduação apresentada ao Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Universidade Federal do Rio Grande do Norte como requisito parcial para a obten-ção do grau de bacharel em Engenharia de Software.
Orientador: Prof. Mestre Itamir de Morais Barroca Filho
NATAL - RN
DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA Novembro de 2017
Oliveira, Maychell Fernandes de.
Desenvolvimento de um aplicativo móvel para controle patrimonial / Maychell Fernandes de Oliveira. - Natal, 2017. 66f.: il.
Monografia (graduação) - Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. Bacharelado em Engenharia de Software.
Orientador: Itamir de Morais Barroca Filho.
1. Engenharia de software. 2. Android. 3. Controle
patrimonial. 4. IMD. 5. UFRN. 6. Mobilidade. 7. Bem patrimonial. I. Barroca Filho, Itamir de Morais. II. Título.
RN/UF/CCET CDU 004.41 Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
DESENVOLVIMENTO DE UM APLICATIVO MÓVEL PARA CONTROLE PATRIMONIAL
MAYCHELL FERNANDES DE OLIVEIRA
Monografia de Graduação sob o título DESENVOLVIMENTO DE UM APLICATIVO
MÓ-VEL PARA CONTROLE PATRIMONIAL apresentada por MAYCHELL FERNANDES
DE OLIVEIRA e aceita pelo DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA da UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE, sendo aprovada por todos os membros da banca examinadora abaixo especificada:
Orientador: Prof. Mestre Itamir de Morais Barroca Filho
Prof. Dr. Fernando Marques Figueira Filho
“A mente que se abre a uma nova ideia jamais voltará ao seu tamanho original”.
RESUMO
Em diversas instituições públicas e privadas pode-se perceber a presença de diversos bens materiais que precisam de um controle patrimonial para que se possa manter uma melhor gestão dos seus bens. Para auxiliar a realização desta tarefa, diversas instituições utilizam algum software específico de controle patrimonial. Um exemplo é a unidade suplementar Instituto Metrópole Digital (IMD) da Universidade Federal do Rio Grande do Norte (UFRN), que utiliza um sistema de informação web desenvolvido pelo setor de informática
da própria instituição.
Porém, em meio à constante necessidade de mobilidade, este trabalho apresenta o aplicativo Patrimônio Mobile, um software para a plataforma Android como alternativa móvel para o sistema web já existente de controle patrimonial do IMD, permitindo, assim, solucionar problemas como mobilidade, eficiência na execução de tal atividade bem como tolerância à falta de conexão com a internet.
LISTA DE ILUSTRAÇÕES
Figura 1 – Fase de requisitos do Metamorphosis. . . 25
Figura 2 – Fase de projeto do Metamorphosis. . . 27
Figura 3 – Fase de construção do Metamorphosis. . . 28
Figura 4 – Fase de implantação do Metamorphosis. . . 29
Figura 5 – Atividades em ordem de execução e organizadas nas quatro fases do processo Metamorphosis. . . 30
Figura 6 – Tela do aplicativo Inventory Management - menu principal. . . 33
Figura 7 – Tela do aplicativo Inventory Management - gerenciamento de salas. . . 34
Figura 8 – Tela do aplicativo Inventory Management - registrar produtos. . . 34
Figura 9 – Tela do aplicativo Inventory Management - lista de produtos registrados. 35 Figura 10 – Tela do aplicativo Inventory Management - listagem de movimentação de produtos. . . 35
Figura 11 – Tela do aplicativo Goods Order Inventory System Pro - registrar produtos. 37 Figura 12 – Tela do aplicativo Goods Order Inventory System Pro - relatórios dispo-níveis. . . 38
Figura 13 – Tela do aplicativo Goods Order Inventory System Pro - relatório de sincronização de dados com o aplicativo web. . . 38
Figura 14 – Arquitetura do sistema Patrimônio web antes da disponibilização dos serviços via API . . . 48
Figura 15 – Arquitetura do sistema Patrimônio web depois da disponibilização dos serviços via API. . . 48
Figura 16 – Componentes do sistema do Patrimônio com integração da versão móvel com a web. . . 49
Figura 17 – Tela para realizar login para utilizar o sistema. . . 52
Figura 18 – Tela principal contendo todas as opções de navegação pelo aplicativo . 54 Figura 19 – Tela para o cadastro do levantamento patrimonial. . . 55
Figura 20 – Tela de cadastro do levantamento patrimonial - quando o bem já está cadastrado. . . 56
Figura 21 – Tela para a leitura do código de barras dos bens patrimoniais. . . 57
Figura 22 – Tela de listagem de salas. . . 58
Figura 23 – Tela de listagem dos bens materiais pertencentes a uma sala específica. 59 Figura 24 – Tela de listagem de todos os bens cadastrados. . . 60
Figura 25 – Tela de listagem de todo o histórico de transição de status do bem selecionado. . . 61
LISTA DE TABELAS
Tabela 1 – Formato do documento de funcionalidades selecionadas para desenvol-vimento. . . 25 Tabela 2 – Formato do documento de implantação. . . 29 Tabela 3 – Tabela de aplicativos Android para controle patrimonial estudados . . 31 Tabela 4 – Tabela analítica de sistemas encontrados . . . 39 Tabela 5 – Tabela de funcionalidades do sistema de controle patrimonial web
exis-tente do IMD . . . 42 Tabela 6 – documento de funcionalidades selecionadas para desenvolvimento. . . . 46 Tabela 7 – Tabela de serviços disponíveis pela API do sistema de patrimônio web . 50
LISTA DE ABREVIATURAS E SIGLAS ABNT Associação Brasileira de Normas Técnicas
GPS Global Positioning System
REST Representational State Transfer
SQL Structured Query Language
IDE Integrated Development Environment
ADT Android Development Tool
IMD Instituto Metrópole Digital API Application Program Interface
NFC Near Field Communication
HTTP Hypertext Transfer Protocol Secure
JSON JavaScript Object Notation
MVC Model-View-Controller
JVM Java Virtual Machine
XML EXtensible Markup Language
SINFO Superintendência de Informática TI Tecnologia da Informação
SUMÁRIO 1 INTRODUÇÃO . . . 10 1.1 Problema . . . 12 1.2 Objetivos . . . 12 1.3 Metodologia . . . 13 1.4 Declarações e Contribuições . . . 13 1.5 Organização do Trabalho . . . 14 2 FUNDAMENTAÇÃO TEÓRICA . . . 15 2.1 Dispositivos Móveis . . . 15 2.1.1 Android . . . 15
2.2 Aplicações Corporativas e sua Evolução . . . 16
2.3 Computação Distribuída . . . 17
2.3.1 Representational State Transfer - REST . . . 17
2.3.2 Application Program Interface - API . . . 19
2.4 Tecnologias para o Desenvolvimento da Aplicação . . . 20
2.4.1 Java . . . 20
2.4.2 Spring Model-View-Controller - MVC . . . 21
2.5 Metamorphosis: Processo para Criação de Aplicações Móveis Baseadas em Sistemas de Informações Existentes . . . 22
2.5.1 Fase de Requisitos . . . 22
2.5.2 Fase de Projeto . . . 25
2.5.3 Fase de Construção . . . 26
2.5.4 Fase de Implantação . . . 27
3 REVISÃO DE SISTEMAS DE INFORMAÇÃO PARA CON-TROLE PATRIMONIAL . . . . 31
3.1 Sistemas encontrados . . . 31
3.1.1 Inventory Management . . . 31
3.1.2 Goods Order Inventory System Pro . . . 35
3.2 Análise comparativa entre sistemas . . . 39
4 APLICATIVO MÓVEL PARA CONTROLE PATRIMONIAL 40 4.1 Sistema Web Existente para Controle de Patrimônio . . . 40
4.1.1 Principais Funcionalidades . . . 41
4.1.3 Limitações . . . 43
4.2 Patrimônio Mobile: Uma Versão Móvel para o Sistema de Controle Patrimonial do IMD - Utilizando o Processo Metamorphosis . . . 44
4.2.1 Aplicação da Fase de Requisitos . . . 45
4.2.2 Aplicação da Fase de Projeto . . . 47
4.2.3 Aplicação da Fase de Construção . . . 50
4.2.4 Aplicação da Fase de Implantação . . . 50
4.2.5 Dificuldades do Projeto . . . 51
4.3 Patrimônio Mobile . . . 51
5 CONSIDERAÇÕES FINAIS . . . 63
5.1 Trabalhos Futuros . . . 63
1 INTRODUÇÃO
Atualmente, existe uma enorme variedade de dispositivos móveis cada vez mais potentes. Frequentemente, pode se notar novos dispositivos com alto poder de processa-mento lançados no mercado. De acordo com Filho, nos dias atuais, pode se encontrar dispositivos com um poder de processamento que até um tempo atrás existiam apenas em computadores convencionais Desktops. Dispositivos esses que, se comparados com os computadores de cinco anos atrás, possuem melhores configurações, permitindo assim um melhor desempenho (FILHO, 2015).
Um dispositivo móvel é qualquer dispositivo com unidade de processamento que possa transmitir informação em qualquer lugar a qualquer momento. Portanto, existem diversos produtos no mercado que são compreendidos como dispositivos móveis, mas, neste trabalho, serão abordados apenas os Smartphones com o sistema operacional Android, dado que o projeto foi desenvolvido com foco nesses tipos de dispositivos.
Em computação móvel, uma das propriedades mais importantes é o tamanho dos dispositivos, visto que a mobilidade é sua palavra-chave. E, com a diminuição das suas dimensões físicas, os recursos se tornam mais limitados, abrindo espaço para o trade-off : um dispositivo mais potente, portanto maior, ou um com recursos mais limitados, porém com um menor tamanho e, portanto, com maior mobilidade? Esta decisão depende muito do alvo ao qual o dispositivo deve atingir.
De acordo com o funcionário do Google Lockheimer, em 2015 existiam mais de quatro mil dispositivos Android diferentes no mercado mundial (LOCKHEIMER, 2015), o que significa que seus tamanhos, poderes de processamento e formatos também são diferentes, tornando ainda mais difícil o desenvolvimento de software que funcione como esperado na maioria deles. Em termos de usuários ativos de Smartphones Android, o Google anunciou em maio de 2017 que existem mais de dois bilhões de dispositivos ativos mensalmente (POPPER, 2017), o que significa que mais 1/4 da população mundial está utilizando dispositivos com o sistema operacional Android. Ou seja, o mercado de software para Android está aquecido.
Dado isso, os desenvolvedores de software precisam adaptar os seus sistemas a esse novo perfil de dispositivos. Mas essa adaptação muitas vezes não é tão simples. Para se desenvolver a versão móvel de um software, precisa-se levar em consideração a limitação de recursos disponíveis nos aparelhos alvos, além de promover uma melhor utilização dos seus componentes, facilitando assim uma melhor experiência do usuário e também um melhor desempenho ao se realizar as suas tarefas.
recursos (câmera, GPS (Global Positioning System), leitor de código de barras, NFC (Near
Field Communication) etc.) que podem facilitar a execução de tarefas. É possível também
melhorar a experiência do usuário através de técnicas específicas como a de executar operações offline, que podem ser sincronizadas com a base de dados quando o dispositivo estiver online, entre outras.
Com o avanço tecnológico, é cada vez mais possível a automatização de tarefas que eram realizadas manualmente em anos anteriores, o que permite uma melhor eficiência em sua execução. Essas atividades são realizadas em diversas áreas e em diversos locais. Um exemplo é o processo de controle patrimonial em instituições.
Em qualquer instituição, é essencial manter o controle de seus bens materiais. Normalmente, quanto maior uma instituição, maior é o número de seus bens e, muitas vezes, os seus valores. Nenhum órgão pode se submeter a deixar seus recursos totalmente livres a diversos tipos de pessoas que costumam frequentar aquele local.
No contexto de instituições federais, mais especificamente nas de ensino, encontra-se uma situação um pouco mais delicada, pois diariamente há presença de diversas pessoas, o que não se pode confiar totalmente em sua honestidade. Em meio a essa diversidade, não há como prever quem está ou não bem intencionada, o que torna o rígido processo de controle patrimonial ainda mais indispensável.
Normalmente os bens de maior valor financeiro necessitam mais controle que os de menor valor, e o Instituto Metrópole Digital (IMD) da Universidade Federal do Rio Grande do Norte (UFRN) é um ótimo exemplo para analisarmos isso. No instituto, pode se encontrar diversos bens de consumo não-duráveis, que não possuem tombamento (cane-tas/borrachas/lápis, grampeadores, mouses etc.) e também existem os bens de consumo duráveis, que possuem tombamento (veículos, computadores, televisores, projetores de alta tecnologia, monitores etc.). A necessidade do controle patrimonial está nesses produtos que possuem tombamento, pois todos esses itens precisam ser rastreados para que se possa ter um controle dos que ainda estão ou não sob posse do instituto.
Além dessa abordagem do controle patrimonial voltado para a segurança, em instituições desse porte e tipo é preciso também manter a gestão de seus itens. É imprescindível que se possa saber exatamente o local que um determinado item se encontra, qual o seu histórico de transação, estado de conservação e também se ele se encontra ou não no prazo de garantia, melhorando assim a gestão de seus bens.
1.1 Problema
O Instituto Metrópole Digital da UFRN é responsável por diversos bens materiais, os quais, em sua maioria, estão sendo utilizados por servidores e/ou alunos. Para que se possa ter uma melhor gestão desses itens, o IMD precisa manter um controle patrimonial, de forma que se possa identificar se o bem ainda está em utilização, em qual espaço físico ele se encontra, qual o seu estado de conservação e qual o seu período de garantia, assim como é necessário manter o histórico do objeto (os espaços físicos em que esteve alocado e seu local atual).
Para auxiliar nessa tarefa, o setor de desenvolvimento do IMD desenvolveu o sistema do Patrimônio, um software com versão web responsável por guardar todas as informações referentes ao levantamento patrimonial do instituto. O sistema é de grande importância para o setor responsável por fazer o levantamento patrimonial, pois facilita bastante o processo de busca por bens, e também por gerar, facilmente, diversas métricas sobre os bens. Com o aplicativo é possível saber onde cada bem está com uma precisão maior, por contar com a funcionalidade de fazer um rastreamento desses itens, visto que é guardado todo o histórico de movimentação e do seu status.
Porém, dado que o sistema do patrimônio é na plataforma web, em caso de perda de conexão ou se o sistema ficar indisponível, o levantamento patrimonial será suspenso, pois o aplicativo ficará inacessível. Com isso, pode-se presenciar a perda de tempo e de eficiência do processo.
Tem-se também o cenário onde um espaço físico possui dezenas de itens (cadeiras, mesas, computadores, monitores, projetor, televisão, etc.), a tarefa se torna bastante tediosa quando o responsável pelo levantamento patrimonial precisa anotar o tombamento de cada objeto para depois salvar essas informações no sistema e ainda ter que fazer o
upload das imagens de cada bem para então poder vincular com o objeto.
Além disso, o sistema conta também com a ineficiência do processo quando o responsável pelo levantamento patrimonial precisa digitar o tombamento de cada bem para poder registrá-lo. Além da limitada mobilidade para acesso ao aplicativo.
1.2 Objetivos
A solução proposta por este trabalho é o desenvolvimento de um aplicativo como alternativa móvel para o processo de levantamento patrimonial. Com isso, pode-se fazer o uso dos recursos disponíveis no dispositivo, tornando essa atividade mais eficiente e melhorando a experiência do usuário, resolvendo, desta forma, os problemas encontrados anteriormente.
No cenário do aplicativo móvel, pode-se contar com um sistema sempre disponível sem interrupções, mesmo que o usuário não tenha conexão com a internet ou que os servidores do instituto estejam indisponíveis, dado que esse software independe da rede de computadores interligados.
Com a nova versão móvel do patrimônio, pode-se também diminuir o esforço do responsável pelo levantamento patrimonial, pois o aplicativo conta com o recurso de leitor de código de barras disponível na maioria dos smartphones, o que permite o usuário ter uma maior praticidade em apenas apontar a câmera do dispositivo para o tombamento do bem e o dispositivo encontrará o item no banco de dados da aplicação. O dispositivo pode também facilitar o envio das imagens dos objetos, pois a cada item cadastrado no levantamento, o usuário poderá tirar fotos do produto utilizando a câmera do seu dispositivo e fazer o upload juntamente com o levantamento. Salvando assim tempo e esforço para realizar o mesmo processo.
Além de, obviamente, pelo aplicativo possuir característica móvel, ele pode estar sendo utilizado em qualquer local a qualquer momento, sem precisar estar conectado à internet nem muito menos na rede do instituto. Com isso, o usuário tem total liberdade de executar seu trabalho sem as restrições descritas.
1.3 Metodologia
Este trabalho foi realizado no Instituto Metrópole Digital da Universidade Federal do Rio Grande do Norte, como uma forma de solução móvel para o projeto web para controle patrimonial da unidade acadêmica. Os problemas levantados sugiram através do diálogo com os profissionais responsáveis por tal tarefa expondo suas experiências boas e más.
Para o desenvolvimento do sistema de informação descrito neste trabalho, foram utilizadas algumas técnicas e tecnologias de desenvolvimento de software, tendo como principal técnica o processo Metamorphosis, que, como está melhor descrito no capítulo 3, trata-se de uma teoria proposta para se identificar e propor boas práticas para o desenvolvimento de aplicativos móveis baseados em sistemas de informações web existentes (FILHO, 2015).
1.4 Declarações e Contribuições
Este trabalho tem como resultado um aplicativo como alternativa móvel para o sistema web já existente para o controle de patrimônio, que facilita e promove a mobilidade no processo de realizar o levantamento patrimonial de bens do Instituto Metrópole Digital
da Universidade Federal do Rio Grande do Norte.
1.5 Organização do Trabalho
Este trabalho se encontra organizado da seguinte forma: Capítulo 2 - traz a fundamentação teórica do trabalho, focando na apresentação de todas as técnicas e tecnologias utilizadas para o desenvolvimento do aplicativo; Capítulo 3 - faz um levantamento dos principais softwares no mercado para o controle de patrimônio, no qual são explicadas as principais vantagens, e o motivo de não poder ser utilizado no contexto do Instituto Metrópole Digital; Capítulo 4 - explica como foi realizada a aplicação do processo Metamorphosis para construção do aplicativo móvel como alternativa para o sistema web já existente de controle de patrimônio do Instituto Metrópole Digital; e por último, o Capítulo 5 - que aborda as considerações finais sobre o trabalho.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo, serão abordados os conceitos sobre aplicativos nativos para dispositi-vos móveis em Android, aplicações corporativas e sua evolução e o processo Metamorphosis, proposto e definido pelo mestre Itamir de Morais Barroca Filho em 2015, para que possa-mos colocar em prática o estudo realizado a cerca do desenvolvimento de aplicações móveis baseados em aplicações web já existentes, resultando assim em um aplicativo Android que possa suprir as necessidades dos usuários que o sistema web não é capaz (FILHO, 2015).
2.1 Dispositivos Móveis
Atualmente, de acordo com Guenveur, os dispositivos Android e iOS representam juntos 97.3% dos sistemas operacionais no Brasil, porcentagem não muito distante da de diversos países como França, Alemanha, Inglaterra entre outros (GUENVEUR, 2017). Ou seja, a grande maioria dos Smartphones estão executando uma versão dessas duas plata-formas como sistema operacional. Portanto, ao longo deste, vamos levar em consideração apenas essas duas plataformas.
No desenvolvimento de software para dispositivos móveis, contamos com as prin-cipais plataformas Android (código livre do Google) e iOS (código privado da Apple). Cada uma com sua linguagem de programação específica e distintas limitações e recursos disponíveis. Na primeira, temos como base da linguagem de programação Java, enquanto a segunda, temos como base o Swift ou Objective-c. Cada plataforma possui suas vantagens e desvantagens de se trabalhar.
No desenvolvimento de aplicativos para dispositivos móveis, podemos escolher entre as abordagens de desenvolvimento híbrido ou nativo. Isto é, tem-se aplicações que são desenvolvidas em uma linguagem específica para executar no sistema operacional do dispositivo móvel (aplicativos nativos) e se tem, ainda, as aplicações que se utilizam de um determinado framework para garantir a compatibilidade do aplicativo em duas ou mais plataformas (aplicativos híbridos).
Ao realizar uma breve pesquisa em relação ao sistema operacional dos Smartphones no setor responsável pelo controle patrimonial do IMD, e pela possibilidade/facilidade de manter o sistema funcionando, foi decidido e acordado desenvolver o aplicativo apenas na plataforma Android.
2.1.1 Android
O Android é uma plataforma de código aberto criada pelo Google para o desenvol-vimento de aplicações para dispositivos móveis. É a plataforma que está revolucionando o
desenvolvimento de aplicações não apenas para smartphones, mas também para diversos outros dispositivos. O Android inclui um sistema operacional baseado no Linux e diversas aplicações. Utiliza-se de uma rica interface gráfica, banco de dados SQL, entre outros recursos e integrações com APIs do Google como Google Maps, Google Calendar e Gmail (LENCHETA, 2013).
"A plataforma Android contém o sistema operacional móvel, ambiente de desenvol-vimento e uma máquina virtual denominada Dalvik. A Dalvik atua como um middleware entre o hardware do dispositivo móvel e o sistema de operação, e é responsável pela execução das aplicações móveis desenvolvidas para essa plataforma"(FILHO, 2015, P. 26).
As APIs do Android são de código aberto e estão em constante evolução. Atual-mente, encontram-se na versão 8.0 Oreo. Como IDE, temos o Eclipse ADT (que está em desuso) e o Android Studio.
2.2 Aplicações Corporativas e sua Evolução
É indiscutível a importância de softwares no meio corporativo. Seja um simples aplicativo para registro de atividades até um aplicativo bancário com diversas funcionali-dades, por exemplo. Em meio a era digital, é notória uma infinidade de softwares sendo executados nos mais diversos tipos de dispositivos. E cada vez mais estão surgindo, de forma descontrolada, novas aplicações em todas as áreas.
Um segmento de software que ganhou grande visibilidade nas últimas décadas nos meios corporativos foram os aplicativos de mensagens instantâneas. Cada vez mais se precisa desse tipo de aplicativo para conectar pessoas dispostas em diferentes localizações geográficas. O resultante disso é essa facilidade de comunicação que foi criada. Atualmente é possível, por exemplo, presenciar uma única empresa com diversos polos em vários locais do mundo, trabalhando coordenadamente com o auxílio desse tipo de aplicativo.
Com o passar do tempo e com a evolução dos dispositivos móveis, a maioria das empresas nesse mesmo segmento de software começou a ver a possibilidade de expandir os seus projetos para atingir mais pessoas e com mais mobilidade. Foi então quando elas começaram a desenvolver esses aplicativos em uma versão para dispositivos móveis, principalmente para as plataformas iOS e Android.
Com a inserção dos smartphones no meio corporativo, cada vez mais as empresas estão buscando por aplicativos para esse tipo de dispositivo, para que facilite ainda mais o trabalho do levantamento patrimonial de uma empresa ou órgão, por exemplo.
2.3 Computação Distribuída
Segundo Couluris, Dollimore e Kindberg, ”um sistema distribuído é aquele no qual os componentes localizados em computadores interligados em rede se comunicam e coordenam suas ações apenas passando mensagens. Essa definição leva às seguintes características especialmente importantes dos sistemas distribuídos: concorrência de componentes, falta de um relógio global e falha de componentes independentes” (COULURIS, 2007). Ou seja, qualquer software é dito distribuído, se ele está sendo processado por computadores diferentes interligados em rede, de forma a se comunicar através de trocas de mensagens.
Há vários exemplos de sistemas distribuídos no nosso cotidiano, principalmente nos
smartphones, que, em geral, possuem um menor poder de processamento, necessitando,
assim, servir apenas como fornecedor de informações previamente processadas por outro sistema em outro computador.
Para Tanenbaum e Steen, sistemas distribuídos é “coleção de computadores indepen-dentes que se apresenta ao usuário como um sistema único e consistente” (TANENBAUM, 2007). O princípio desse paradigma consiste em executar um mesmo software em diferentes dispositivos, no qual cada um gera sua contribuição com o objetivo de solucionar o mesmo problema (SILVA, 2010).
Porém, para que todos os computadores envolvidos no processamento se comu-niquem entre si, é necessário adotar algumas regras onde cada dispositivo possui um papel bem definido e seja capaz de se comunicar com os demais. Para isso, seguimos o estilo arquitetural para sistemas distribuído de hipermídia, mais conhecido como REST
-Representational State Transfer.
2.3.1 Representational State Transfer - REST
Representational State Transfer (REST) é um estilo arquitetural para sistemas
distribuídos de hipermídia. O estilo descreve os princípios da engenharia de software para orientar o REST e as restrições de interação escolhidas para manter esses princípios, em contraste com as restrições de outros estilos arquiteturais.
REST é um estilo arquitetural híbrido baseado em diversos outros estilos arquite-turais web, combinado com restrições que definem uma interface uniforme para conexão. Examinando o impacto de cada uma dessas restrições, à medida que elas são adicionadas ao estilo, podemos identificar que são propriedades introduzidas pelas restrições web. Restrições adicionais podem então ser aplicadas para formar um novo estilo arquitetural que reflete melhor as propriedades desejadas de uma arquitetura web moderna (FIELDING, 2000).
O que faz o estilo arquitetural possuir uma maior visibilidade é exatamente suas restrições, que permitem uma arquitetura simples de configurar e de se usar. O estilo inicia, por padrão, sem restrições, o que o próprio autor Roy Fielding chama de Null
Style. E a partir dele, começa-se a adicionar restrições com componentes familiares para se
formar o estilo ao qual satisfaz as necessidades do sistema em questão (FIELDING, 2000). As principais restrições do sistema são:
1. Cliente-Servidor
A primeira restrição adicionada ao estilo arquitetural é o modelo Cliente-Servidor. Ele nos traz o princípio da separação de responsabilidades entre o cliente e o servidor. Quando se separam as responsabilidades da interface do usuário da responsabilidade de processamento de dados, por exemplo, também se permite uma maior portabilidade em diversas plataformas, além de melhorar a escalabilidade, por simplificar os seus componentes (FIELDING, 2000).
2. Sem Necessidade de Estado
Depois da restrição do Cliente-Servidor, o segundo item a ser adicionado às restrições da arquitetura, é a falta de necessidade de estado, ou seja, por padrão, toda a comunicação entre o cliente e o servidor deve ser feita sem precisar guardar um estado. Logo, cada requisição deve conter toda a informação suficiente para que o servidor entenda e processe o que está sendo requisitado. Com isso, todo o estado deve ser mantido no cliente (FIELDING, 2000).
Esta restrição introduz as seguintes propriedades: Visibilidade - Cada cliente é responsável por manter o seu próprio estado, sem que o servidor precise sequer conhecer os seus clientes; Escalabilidade - Por não guardar os estados de cada cliente, os servidores são responsáveis por processar a requisição rapidamente e liberar os seus recursos; e Confiabilidade - Garante que, por mais que o serviço em qualquer servidor falhe, os demais continuarão a funcionar normalmente. Além de facilitar a sua recuperação, por ter um escopo pequeno e bem definido (FIELDING, 2000).
3. Interface Uniforme
A principal restrição que diferencia o estilo arquitetural REST de outros baseados na arquitetura web é a ênfase na interface uniforme entres os componentes. Por aplicar os princípios de engenharia de software, temos, em uma visão geral, uma arquitetura simplificada e a melhor visibilidade das interações. Além disso, as implementações de cada serviço são desacopladas, o que torna a independência de cada serviço e sua evolução (FIELDING, 2000).
Em relação aos elementos arquiteturais REST, temos os dados do elemento, que é o conteúdo da requisição feita. Cada um dos dados é composto por: Recurso - É a chave para a abstração da informação. Um recurso é o mapeamento conceitual de um conjunto de entidades, onde uma entidade pode ser um documento, uma imagem, ou mesmo texto. Em outras palavras, uma entidade é um objeto que é transferido em uma requisição; Identificador do Recurso - O identificador do recurso, como o próprio nome diz, é o que vai identificar o recurso envolvido em particular em uma interação entre os componentes; Representação - Consiste no tipo de representação dos dados de retorno do servidor. Normalmente, os tipos de dados incluem: documentos, arquivo, uma mensagem HTTP (Hypertext Transfer Protocol Secure), uma mensagem em JSON (JavaScript Object
Notation), entre outras; Representação em Metadata - São informações sobre o recurso
que não são específicas para a representação fornecida; e Controle de Dados - Define o objetivo da mensagem entre os componentes, como a ação está sendo requisitada (FIELDING, 2000).
2.3.2 Application Program Interface - API
Como foi explicado na seção anterior, pode-se entender que aplicações podem ser desacopladas e independentes, trabalhando cada uma em um local diferente. Mas de alguma forma elas devem trocar informações, e é neste cenário que entra a API (Application
Program Interface). A API do estilo arquitetural web é uma sintaxe com uma semântica
definida para interação entre aplicações.
Uma API não adiciona nenhuma restrição ao código da aplicação além de precisar ler e escrever à rede, mas coloca restrições no conjunto de semântica que pode ser utilizadas para que as duas aplicações possam se comunicar através da interface.
A API possibilita diversas aplicações se comunicarem de forma independente. Para cada aplicação que utiliza um recurso de outra, é necessário fazer uma requisição à interface desta com as informações necessárias para que o processamento possa ser realizado, e aguarda uma resposta. A primeira aplicação não precisa saber o que a segunda faz internamente, porém, ela sabe exatamente como tratar essa resposta, funcionando assim como se, no contexto da primeira aplicação, a segunda fosse uma espécie de caixa preta, que, dadas as informações necessárias, ela vai retornar algum resultado processado esperado.
Como você deve ter notado, através de aplicações RESTful APIs, a linguagem de programação utilizada em cada aplicação é totalmente independente das outras. Neste contexto, cada aplicação pode ser desenvolvida em uma linguagem que mais se adequa às suas características, e mesmo assim, continuará se comunicando com as demais de forma
transparente para o usuário.
2.4 Tecnologias para o Desenvolvimento da Aplicação
Nesta seção iremos abordar as principais tecnologias que ainda não foram mencio-nadas, mas que foram utilizadas para o desenvolvimento da aplicação proposta por este trabalho. Para desenvolver o aplicativo móvel, foram utilizadas as seguintes tecnologias: Java EE e Spring MVC Framework.
2.4.1 Java
Java é uma linguagem de programação de código aberto desenvolvida por James Gosling, juntamente com outros colaboradores, no início da década de 1990, na empresa
Sun Microsystems (CAELUM, -a). Esta linguagem segue o paradigma de orientação a
objetos, que trata como objeto qualquer abstração do mundo real. A grande vantagem do Java é que por ser executado em uma Máquina Virtual Java - JVM, ela permite uma maior compatibilidade, pois os programas em Java podem ser executados em qualquer sistema com suporte a C++ (PROGRESSIVA, 2012).
A linguagem de programação não objetiva projetos de pequeno porte. O seu principal foco da plataforma são projetos de médio a grande porte, onde geralmente temos um grande número de desenvolvedores. Por isso, normalmente, para se desenvolver um projeto nesta linguagem, precisamos sempre fazer bastantes configurações e isso sempre é muito trabalhoso. Mas por outro lado, para se fazer a manutenção de um software desenvolvido em Java é simples e rápido de fazer, caso os desenvolvedores utilizem boas práticas de programação (CAELUM, -a).
Por se tratar de aplicações de grande porte, geralmente sistemas corporativos nessa escala são desenvolvidos nessa linguagem, como sistemas de controle de bens, sistemas acadêmicos, sistemas de banco e outros. Além disso, é mais comum encontrar desenvolvedores com capacidades para desenvolver em Java do que em qualquer outra linguagem. Normalmente, esses aplicativos foram desenvolvidos para ficar legado por décadas, daí a vantagem de terem sido desenvolvidos em Java.
O Java é mais interessante para aplicações que têm um potencial crescimento, com muita conectividade e muitas plataformas distintas, pois possui certa facilidade em se conectar com outras plataformas. A linguagem é simples por possuir poucas regras e ser muito bem definida.
2.4.2 Spring Model-View-Controller - MVC
Antes de explicar sobre o framework Spring MVC (Model-View-Controller), é necessário entender o que é MVC. O MVC é um modelo arquitetural de software. Esse modelo resulta em separar os diferentes aspectos da aplicação (View - responsável por renderizar os dados em algum formato específico (geralmente em HTML ou JSON, no caso de aplicações web); Controladora - responsável por transmitir as informações para a interface e por processar as requisições do usuário; e Modelo - responsável por encapsular os dados da aplicação e o seu comportamento) de forma a diminuir o acoplamento entre esses elementos (POINT, -).
Spring MVC é um framework web de código aberto que provê a arquitetura MVC e componentes prontos que podem ser usados para desenvolver aplicações web desacopladas e flexíveis. O framework provê uma programação abrangente e configuração de modelo para aplicações Java EE. O elemento chave do Spring é o seu suporte à infraestrutura no nível de aplicação: Spring é focado no encantamento das aplicações enterprise, deixando o desenvolvedor nas regras de negócio apenas, sem se preocupar com especificidades do ambiente (CAELUM, -b).
O framework possui sua própria configuração XML (EXtensible Markup Language), o que permite também ser utilizado em ambientes não web, ou seja, nem sempre o Spring pode se basear no seu arquivo de configuração web. Ele permite também criar as lógicas usando convenções ou declarando tudo no XML, porém em sua terceira versão, a maneira indicada é utilizando anotações (CAELUM, -b).
O spring é projetado em torno do DispatcherServlet, que gerencia todas as re-quisições e respostas HTTP. O DispatcherServlet é então responsável por despachar as requisições para cada handler, com configurações de mapeamento, resolução da view, entre outros. O handler por padrão é baseado na controladora e na anotação
@RequestMap-ping, que oferece uma grande flexibilidade de métodos para tratar a requisição. Com a
introdução do Spring 3.0, o mecanismo da controladora também permite criar aplicações RESTful através da anotação @PathVariable (POINT, -).
Quando uma requisição chega à aplicação, o DispatcherServlet verifica o mape-amento do projeto para chamar a controladora correta com a finalidade de processar a solicitação. A controladora então recebe a requisição e a redireciona para o método apropriado, de acordo com o seu verbo (POST, GET, PATCH, PUT ou DELETE) que executa a ação e retorna a resposta para o DispatcherServlet, o qual é responsável por encaminhar o resultado da requisição para quem originou a solicitação (CAELUM, -b).
O framework permite facilmente a definição de uma interface para aplicação, facilitando assim o desenvolvimento de aplicações REST com suas vantagens descritas na
subseção sobre REST. Utilizando o Spring, qualquer aplicação pode então se comunicar com outras através de sua API, permitindo o desacoplamento de funcionalidades e também o seu crescimento e escalabilidade.
O Spring está constantemente em atualização. Sua última versão disponível é a 5.0.
2.5 Metamorphosis: Processo para Criação de Aplicações Móveis Baseadas em Sistemas de Informações Existentes
Metamorphosis é o processo pioneiro em desenvolvimento de sistemas para a
plataforma móvel dado uma versão web já existente. Esse estudo defendido pelo mestre Itamir levanta uma série de passos que forma a técnica para a construção de um aplicativo para a versão móvel de um software web. Como destacado em sua tese, um software para essa plataforma não possui nenhuma relação com a mudança do sistema web existente, nem muito menos a cópia das suas funcionalidades. Por isso, o processo exige a realização de um conjunto de atividades para analisar o que é interessante ou não ser implementado na versão móvel.
Os principais elementos do processo são divididos em quatro principais fases: Requisitos - Fase de levantamento do escopo do projeto na qual são definidos, avaliados e validados os requisitos do sistema; Projeto - Fase relacionada ao projeto arquitetural do sistema, em que são definidas a plataforma, frameworks, arquitetura do sistema e também algumas estratégias para atingir o objetivo do desenvolvimento do aplicativo; Construção Fase de desenvolvimento do código e realização de testes do sistema; e Implantação
-Fase onde o sistema, depois de desenvolvido, testado e validadas as suas funcionalidades, passa a ser disponibilizado para utilização (FILHO, 2015).
O processo define ainda subdivisões das fases descritas em atividades, para facilitar a identificação e o desenvolvimento das funcionalidades mais relevantes que o aplicativo móvel precisa atender.
2.5.1 Fase de Requisitos
A fase de requisitos é a fase mais delicada de qualquer projeto de software, pois é nela que devemos colher e selecionar todos os requisitos do sistema. E caso algum desses requisitos não estejam de acordo com as necessidades do cliente, o projeto irá se comportar de forma diferente da que o usuário espera, abrindo assim um potencial espaço para o desuso do aplicativo e consequentemente o seu insucesso, que é o que todos os envolvidos não almejam.
No contexto de desenvolvimento de aplicativos móveis baseados em sistemas web já existentes, temos a vantagem do escopo já ser bem definido, pois o sistema já existe e funciona como esperado em sua versão web. Porém, esta é ainda uma fase bastante delicada, pois é nela que se deve fazer um levantamento e uma avaliação de todos os requisitos do aplicativo. Ou seja, é nesta fase que se deve definir como o aplicativo deverá se comportar.
Para isso, de acordo com o Metamorphosis, de forma geral, não podemos utilizar todos os requisitos do sistema web já existente para o aplicativo móvel, mas sim gerar uma nova lista de requisitos. Ou seja, não é correto fazer um mapeamento direto das funcionalidades para o aplicativo móvel. Isso pelo fato dos dispositivos móveis possuírem uma lista de limitações em relação a um servidor onde está hospedado o sistema web, além de se ter diversos outros recursos à disposição como câmera, GPS e NFC. Os dispositivos móveis podem ainda ser mais explorados em suas aplicações em termos de usabilidade e portabilidade.
Uma das primeiras abordagens que deve ser levada em consideração ao realizar a fase de requisitos para o desenvolvimento de um aplicativo móvel baseado em um sistema
web existente, é o seu tamanho de tela. Ou seja, qualquer aplicativo deve explorar bem
os recursos do dispositivo, mas por outro lado, deve se ter sempre o cuidado com a simplicidade das operações, com a quantidade de passos necessários para realizar uma atividade e também com a diminuição de informações exibidas.
Com o objetivo de descobrir os requisitos do aplicativo, o Metamorphosis sugere quatro práticas para serem executadas juntamente com usuários e clientes interessados no novo projeto. As práticas sugeridas pelo Metamorphosis são:
1. Escolher funcionalidades populares
2. Evitar funcionalidades de longos passos ou que possuam longos formulários 3. Adaptar funcionalidades existentes no sistema de informação web
4. Criar funcionalidades específicas para o aplicativo móvel
Ao executar essas práticas, o resultado é uma lista de requisitos pré-selecionados, que deverão ser processados, resultando assim em uma lista mais concisa dos requisitos do sistema. Para isso, o processo Metamorphosis subdividiu a fase de requisitos nas seguintes tarefas:
Onde o seu principal objetivo é identificar quais funcionalidades do sistema web são mais relevantes para o sistema móvel.
2. Validação das funcionalidades
Esta tarefa tem o objetivo de validar com o cliente se as funcionalidades identificadas são de fato relevantes para o aplicativo móvel e também incluir funcionalidades importantes que não foram identificadas no item anterior. Com a realização dessa atividade, temos então uma série de funcionalidades bem definidas que deverão ser implementadas no aplicativo.
3. Avaliação no contexto móvel
Esta possui o objetivo de fazer uma avaliação das funcionalidades, levando em consideração as limitações dos dispositivos móveis. Ou seja, algumas funcionalidades poderão ser descartadas, caso as limitações dos dispositivos não permitam o seu desenvolvimento.
4. Análise de adaptação
O seu principal objetivo é analisar a viabilidade de adaptação de funcionalidades importantes para o cliente, mas que são limitadas pelos dispositivos. Esta análise promove então uma solução alternativa para o desenvolvimento dessas funcionalida-des.
5. Seleção de funcionalidades
Essa atividade tem como objetivo catalogar as funcionalidades que restaram depois de passaram por todas as atividades anteriores. Esta nova lista de funcionalidades é a que deverá de fato ser desenvolvida.
6. Avaliação offline
O principal objetivo desta tarefa é avaliar a necessidade da aplicação poder reali-zar algumas operações estando desconectado da rede. Essas operações devem ser destacadas, pois isso influenciará no projeto arquitetural do aplicativo.
Para melhor ilustrar as atividades da fase de requisitos, retiramos a figura 1) da dissertação do processo Metamorphosis de Itamir.
Como resultado da execução dessas tarefas, temos então o Documento de Funci-onalidades Selecionadas para o Desenvolvimento, que consiste em um documento em formato de tabela que contém informações das funcionalidades selecionadas, o link para o acesso às documentações das funcionalidades, a indicação da necessidade de adaptação
Figura 1 – Fase de requisitos do Metamorphosis. Fonte: Retirado de (FILHO, 2015)
e funcionamento offline das mesmas. Para melhor ilustrar, veja a tabela 1) retirada da dissertação do processo Metamorphosis de Itamir.
Tabela 1 – Formato do documento de funcionalidades selecionadas para desenvolvimento. Funcionalidade Link para documentação Necessita Adaptação Necessita Offline
2.5.2 Fase de Projeto
A fase de projeto definida no processo Metamorphosis sugere a escolha da plataforma a qual o projeto atingirá, seja ela iOS, Android ou outra. Ao escolher uma plataforma, é preciso projetar uma arquitetura do sistema, onde deve ser levada em consideração a forma
como o aplicativo móvel se comunicará com o sistema de informações web já existente. É também nesta fase que é necessário realizar um levantamento dos serviços que o aplicativo deve consumir do sistema web.
Para facilitar a execução desta fase, o processo Metamorphosis a subdividiu nas seguintes tarefas:
1. Escolha da plataforma
O objetivo desta atividade é definir qual é a plataforma móvel que o aplicativo deve atingir. A plataforma pode qualquer uma como Android, iOS, entre outras.
2. Projetar a arquitetura
Nesta atividade, deve-se definir a arquitetura do sistema, incluindo a forma na qual o aplicativo móvel deve se comunicar com o sistema de informação web existente. 3. Projetar os serviços
Visto que o aplicativo deve se comunicar com o sistema web existente, esta tarefa é responsável por projetar os serviços que deverão estar disponíveis para conexão e de que forma será esta comunicação.
Para melhor ilustrar as atividades da fase de projeto, retiramos a figura 2 da dissertação do processo Metamorphosis de Itamir.
Como resultado da execução das atividades da fase de projeto, tem-se o projeto de arquitetura de software do aplicativo, assim como uma documentação com as decisões de projeto que acarretaram na criação da mesma. Além disso, deve se gerar também como resultado, o projeto de web services, com o intuito de possibilitar a integração do sistema
web existente com o aplicativo móvel.
2.5.3 Fase de Construção
A fase de construção do projeto ocorre quando o aplicativo começa de fato a ser desenvolvido. Nesta fase, o seu principal resultado é o código e os testes do aplicativo. Para realizar esta fase, o desenvolvedor deve ter um documento de funcionalidades selecionadas para o desenvolvimento. Este documento, como foi aqui explicado, possui todos os requisitos já filtrados e validados com o cliente, onde resultará no aplicativo que atende aos seus requisitos.
Ao final da implementação dos requisitos, o desenvolvedor solicita testes de implan-tação, onde, caso alguma funcionalidade seja indevida, o desenvolvedor deverá corrigi-la, e solicitar novos testes. A fase é finalizada quando todas as funcionalidades são validadas.
Figura 2 – Fase de projeto do Metamorphosis. Fonte: Retirado de (FILHO, 2015)
Para facilitar a execução da fase de construção, o Metamorphosis a subdividiu nas seguintes tarefas:
1. Implementação
Nesta tarefa, é realizada a codificação do aplicativo, de acordo com a sua plataforma escolhida na fase de projeto.
2. Testes
Esta fase objetiva realizar os testes para que o sistema possua uma menor quantidade de erros e que as suas funcionalidades sejam condizentes com o que foi planejado.
Para melhor ilustrar as atividades da fase de construção, retiramos a figura 3) da dissertação do processo Metamorphosis de Itamir.
2.5.4 Fase de Implantação
A fase de implantação, no caso de aplicativos móveis corporativos, é algo que precisa ser analisado, pois, em sua maioria, não é muito interessante lançar um aplicativo desses no mercado global (como o Google Play ou Apple Store), caso ele possa ser disponível apenas
Figura 3 – Fase de construção do Metamorphosis. Fonte: Retirado de (FILHO, 2015)
para os funcionários de uma empresa, por exemplo. Uma solução para esses casos, seria o
in-house, que é um mercado para apenas um grupo de usuários, seja ele de funcionários
ou outro.
Apenas a publicação do aplicativo móvel não é suficiente para fazer com que ele seja conhecido pelos seus usuários. Após a publicação, seja onde for, é de extrema importância a sua divulgação para os potenciais usuários, pois estes precisam conhecer a aplicação e saber o que pode e o que não pode fazer com essa versão móvel, mostrando assim as suas vantagens.
Para facilitar a fase de implantação, o Metamorphosis a subdividiu nas seguintes tarefas:
1. Análise da necessidade de publicação
Esta tarefa objetiva realizar uma análise da viabilidade de se publicar o aplicativo em algum mercado de aplicativos, informando em qual deverá ser publicado. 2. Publicar o aplicativo
Consiste na publicação do aplicativo no mercado de aplicativos selecionados na tarefa anterior.
3. Divulgar o aplicativo
Consiste na divulgação do aplicativo para os potenciais usuários deste.
Para melhor ilustrar as atividades da fase de implantação, retiramos a figura 4) da dissertação do processo Metamorphosis de Itamir.
Figura 4 – Fase de implantação do Metamorphosis. Fonte: Retirado de (FILHO, 2015)
O resultado desta fase é ter gerado um Documento de Implantação do Apli-cativo, que contém uma descrição do aplicativo móvel, o mercado de aplicativos móveis utilizado e um link para o download do aplicativo. Para melhor ilustrar, veja a tabela 2) retirada da dissertação do processo Metamorphosis de Itamir.
Tabela 2 – Formato do documento de implantação. Descrição Mercado de App. Link para download
Dadas todas as tarefas de todas as fases, tem-se então a figura 5 que ilustra de maneira mais geral a ordem de execução e como estão organizadas todas as tarefas das quatro fases do processo Metamorphosis. A figura 5 abaixo foi retirada da dissertação de Itamir para uma melhor visualização das atividades descritas.
Figura 5 – Atividades em ordem de execução e organizadas nas quatro fases do processo Meta-morphosis.
3 REVISÃO DE SISTEMAS DE INFORMAÇÃO PARA CONTROLE PA-TRIMONIAL
Antes de inicializar o projeto Patrimônio Mobile (descrito no capítulo 4) como uma alternativa móvel para o sistema de controle de patrimônio do Instituto Metrópole Digital
web já existente, foi feita uma análise no mercado para verificar se havia alguma solução
pronta para o problema descrito no primeiro capítulo deste documento, evitando assim esforço desnecessário, e também para fazer um levantamento de boas práticas e medidas bem sucedidas que poderiam ser utilizadas no desenvolvimento do projeto apresentado neste trabalho.
3.1 Sistemas encontrados
Os principais sistemas de informação móveis encontrados e aqui descritos foram os que mais se aproximavam do contexto de controle de bens materiais. Esses sistemas são listados na tabela 3
Tabela 3 – Tabela de aplicativos Android para controle patrimonial estudados
Nome Endereço
Inventory Management https://play.google.com/store/apps/details?id= nl.industrialit.warehousemanagement
Goods Order Inventory Pro https://play.google.com/store/apps/details? id=com.metaoption.goodsorder
3.1.1 Inventory Management
O aplicativo Inventory Management é um software para fins genéricos para o controle de estoque de produtos, e que pode ser utilizado em almoxarifados. O sistema está disponível no Google Play para smartphones Android para as versões a partir do 4.0.3 e é um software pago, porém permite o usuário utilizar por trinta dias de testes gratuitamente. O aplicativo está em sua versão 1.094 e passa por constantes atualizações. No mercado de aplicativos Google Play, o Inventory Management foi instalado entre 10.000 e 50.000 dispositivos e possui uma avaliação de 3,9 em um total de 5.
Realizando-se um estudo através da sua descrição no Google Play e navegando pelo aplicativo no smartphone, foram listadas sete funcionalidades importantes que poderiam ser utilizadas no IMD e uma breve descrição de como elas podem ser utilizadas. São elas:
Os itens são customizáveis, ou seja, deixa a aplicação mais genérica para que possa ser utilizada em diversos ambientes. Com isso, qualquer tipo de produto pode ser adicionado à lista.
2. Manter Local (sala)
Permite ao usuário gerenciar uma abstração dos locais físicos reais no dispositivo, facilitando assim encontrar os itens de cada local. Com isso, é possível mapear todas as salas existentes no instituto no dispositivo, permitindo então o gerenciamento dos itens por sala.
3. Movimentar produtos
Permite realizar a movimentação total ou parcial de bens entre salas. 4. Permitir identificar produtos pelo código de barras
Ao cadastrar um produto, é possível associar também um código de barras aos seus atributos. Isso permite uma leitura mais rápida e fácil do item ao realizar um novo levantamento patrimonial posteriormente.
5. Sincronizar os dados com outros dispositivos
O sistema possui a funcionalidade de exportar e importar diversos dados através de arquivos CSV (Comma Separated Values). Com isso, é possível deixar todos os dispositivos sempre atualizados com os dados dos arquivos CSV.
6. Permite trabalhar online e offline
O sistema não precisa estar conectado à internet para funcionar. A sincronização de dados pode ser realizada através de outras formas de comunicação (bluetooth, infravermelho, transferência de arquivos etc.)
7. Permite gerar relatórios
É possível gerar diversos relatórios no aplicativo, permitindo assim ter uma visão melhor do que está acontecendo com os produtos de uma forma mais interativa.
Essas funcionalidades são muito importantes para um sistema de controle patrimo-nial, entretanto por ser um aplicativo genérico, ele falha em relação a eficiência em alguns aspectos como sincronização, visto que a forma na qual o dispositivo faz a sincronização é através de troca de arquivos CSV. Desta forma, se diversos dispositivos fossem utilizados para realizar o controle patrimonial, todos precisariam sincronizar todos os seus dados em um único CSV e fazer a importação dos dados nos demais. Visto que o IMD possui um sistema para controle patrimonial web em execução, seria necessário também fazer a
importação e exportação dos dados através desse tipo de arquivo no sistema web, o que geraria um custo adicional para se ter o conjunto da solução para o controle patrimonial funcionando.
Ao navegar pelo aplicativo, percebe-se que não é possível manter um registro mais detalhado dos bens, pois em nenhum momento foram encontrados dados relacionados a
status customizáveis para os produtos. Os únicos presentes são "ativo"e "inativo", o que
não é suficiente para atender a necessidade do IMD.
Outra funcionalidade importante para o instituto é o registro da imagem de cada bem, e com o Inventory Management não é possível registrar as imagens de um bem.
Além dessas falhas encontradas para a imersão do aplicativo no IMD, a versão paga do aplicativo possui dois planos: Basic subscription e Premium subscription, custando, respectivamente, 45,08 e 90,16 reais. O instituto não tem a intenção de adicionar um custo as suas contas por uma solução que não vai satisfazer as necessidades significantemente, portanto, seria inviável adotar o aplicativo Inventory Management como alternativa móvel para o sistema de controle patrimonial web já existente.
Figura 7 – Tela do aplicativo Inventory Management - gerenciamento de salas.
Figura 9 – Tela do aplicativo Inventory Management - lista de produtos registrados.
Figura 10 – Tela do aplicativo Inventory Management - listagem de movimentação de produtos. 3.1.2 Goods Order Inventory System Pro
O Goods Order Inventory System Pro é, assim como o Inventory Management, um aplicativo para fins genéricos para o controle de estoque de produtos. O sistema está
disponível no Google Play para smartphones Android nas versões a partir do 3.0 e também no Apple Store para smartphones Apple nas versões a partir do iOS 8.0 para instalação gratuita, porém sua utilização é mediante pagamento. O aplicativo está em sua versão 4.0.1 e passa por constantes atualizações. No mercado de aplicativos Google Play, o Goods
Order Inventory System Pro foi instalado entre 10.000 e 50.000 dispositivos e possui uma
avaliação de 3.6 em um total de 5.
Realizando-se um estudo através da sua descrição no Google Play e navegando pelo aplicativo no smartphone, foram listadas sete funcionalidades importantes que poderiam ser utilizadas no IMD e uma breve descrição de como elas podem ser utilizadas. São elas:
1. Versão móvel e web
Ao realizar a assinatura do serviço, o usuário possui acesso à versão web e também a versão móvel do dispositivo. Com isso há uma integração eficiente entre os dados coletados através dos dispositivos móveis e do sistema web.
2. Sincronização em tempo real dos dados
Quando conectado à rede, os dados são sincronizados em tempo real e de forma transparente para o usuário, evitando assim a necessidade de troca de arquivos para realizar a sincronização das informações.
3. Gerenciamento de local (salas)
Permite ao usuário gerenciar uma abstração dos locais físicos reais no dispositivo, facilitando assim encontrar os itens de cada local. Com isso, é possível mapear todas as salas existentes no instituto no dispositivo, permitindo então o gerenciamento dos itens por sala.
4. Movimentar produtos
Permite realizar a movimentação total ou parcial de bens entre salas. 5. Permitir identificar produtos pelo código de barras
Ao cadastrar um produto, é possível associar também um código de barras aos seus atributos. Isso permite uma leitura mais rápida e fácil do item ao realizar um novo levantamento patrimonial posteriormente.
6. Permite trabalhar online e offline
O sistema não precisa estar conectado à internet para funcionar. Porém a sincro-nização dos dados apenas será realizada quando o dispositivo estiver conectado à rede.
7. Permite gerar diversos relatórios
É possível gerar diversos relatórios no aplicativo, permitindo assim ter uma visão melhor do que está acontecendo com os produtos de uma forma mais interativa.
Assim como o aplicativo Inventory Management, existem várias funcionalidades muito importantes para um sistema de controle patrimonial, porém há alguns recursos que deixam um pouco a desejar, por se tratar de um aplicativo genérico. Alguns problemas encontrados anteriormente foram também visualizados no Goods Order Inventory System
Pro, como falta de informações mais detalhadas de um produto como o seu status, que
não é suficiente para atender as necessidades do IMD.
Este aplicativo também não traz a funcionalidade de tirar uma foto do produto, visto que é uma necessidade específica do instituto para esse tipo de levantamento.
Além das falhas encontradas, a versão paga do aplicativo possui apenas o plano
Standard, que custa 79,99 dólares por mês. Assim como explicado anteriormente, o instituto
não possui a intenção de pagar um valor alto por um aplicativo que não satisfaz as suas necessidades. Atualmente o software na versão web que está em execução satisfaz as necessidades do IMD, pois foi desenvolvido especialmente para o instituto. Adicionando o Goods Order Inventory System Pro, seria eliminar o software gratuito em uso e que é suficiente para utilizar um software insuficiente e pago. Ou seja, não é vantajoso para o cliente.
Figura 12 – Tela do aplicativo Goods Order Inventory System Pro - relatórios disponíveis.
Figura 13 – Tela do aplicativo Goods Order Inventory System Pro - relatório de sincronização de dados com o aplicativo web.
3.2 Análise comparativa entre sistemas
Como foi visto, o IMD possui algumas necessidades básicas para a realização da tarefa de levantamento patrimonial e que nem todas são atendidas pelos sistemas encontrados. Portanto, após a análise sobre os sistemas encontrados, foi construída uma tabela analítica para apresentar as necessidades do IMD em relação ao controle patrimonial que são ou não contempladas por esses sistemas. A tabela analítica é apresentada pela tabela 4
Tabela 4 – Tabela analítica de sistemas encontrados Requisitos necessários Sistemas
Inventory Management Goods Order Inventory Pro
Leitor de código de barras X X
Sincronização com a versão
web do patrimônio X
Gerar relatórios X X
Trabalhar offline e online X X
Movimentação de produtos X X
Fotografar bens durante levantamento
Controle de acesso X
Buscar bens por sala X X
Histórico de status do bem Manter status do bem
4 APLICATIVO MÓVEL PARA CONTROLE PATRIMONIAL
Após a finalização do estudo dos sistemas móveis de informação para o controle patrimonial descrito no capítulo 3, nota-se que os sistemas analisados não contemplam todas as necessidades do Instituto Metrópole Digital no contexto de versão móvel para o controle patrimonial. Contudo, as características que mais se destacaram (de forma positiva ou negativa) foram bastante úteis para o desenvolvimento deste trabalho, pois os pontos positivos puderam ser aproveitados enquanto os negativos foram melhorados ou adaptados para que o software desenvolvido pudesse melhor atender as necessidades do instituto.
Dados os problemas presentes no IMD apresentados no capítulo 1, pode se perceber a necessidade do desenvolvimento de um software para auxiliar no controle patrimonial do IMD, pois, o processo antes utilizado, através do sistema web, tornava a atividade muito lenta e trabalhosa. Com um sistema móvel como alternativa para o sistema web existente para auxiliar esse processo poderia melhorar o trabalho dos funcionários responsáveis por tal tarefa, solucionando assim os problemas aqui descritos.
Portanto, neste capítulo é descrito o sistema de patrimônio móvel que foi modelado aplicando na prática o processo Metamorphosis defendido por Itamir em 2015. Esse sistema é um aplicativo móvel para a plataforma Android como uma alternativa para o sistema web já existente do patrimônio da unidade do Instituto Metrópole Digital da Universidade Federal do Rio Grande do Norte - IMD/UFRN.
4.1 Sistema Web Existente para Controle de Patrimônio
O sistema web existente para o controle de patrimônio do Instituto Metrópole Digital (IMD) da Universidade Federal do Rio Grande do Norte (UFRN) é um software desenvolvido pelo setor de desenvolvimento da própria unidade. O objetivo desse software foi para ter um maior controle sobre os bens patrimoniais do instituto. A universidade já possui controle de todos os seus bens, porém, dado a sua dimensão e quantidade de setores e unidades, se torna praticamente impossível manter um real mapeamento de todos os seus materiais. Com base nisso, foi delegado que cada setor ou unidade da universidade fizesse o próprio controle de seus bens.
Sendo assim, a instituição possui um controle de cada equipamento contido nela, porém esta informação pode estar desatualizada, o que torna uma tarefa quase impossível encontrar um bem específico buscando pelo seu código.
Nesse contexto, o sistema do patrimônio do IMD ganha destaque, pois com ele é possível fazer um mapeamento mais real dos materiais que estão na unidade, permitindo
assim controlar as suas movimentações, os seus status, ter uma melhor visualização através de imagens, controlar sua exata localização a qualquer momento, entre outros.
O sistema de patrimônio do IMD possui integração com os principais serviços da Superintendência de Informática (SINFO) da UFRN - órgão independente responsável pelo desenvolvimento dos principais softwares utilizados na universidade) -, o que o torna ainda mais interessante, pois com essa integração, é possível recuperar a lista de todos os bens vinculados a unidade, sem que fosse necessário recadastrar todas essas informações nesse novo sistema. Outra vantagem é que todos os usuários cadastrados nos sistemas da SINFO estão também disponíveis para utilizar o sistema do patrimônio sem precisar se cadastrar novamente, precisando apenas de permissão para isso.
4.1.1 Principais Funcionalidades
O sistema do patrimônio do IMD pode ser considerado um software de pequeno porte, porém possui várias funcionalidades que necessitam de alguns passos que tornam o sistema um pouco trabalhoso de se navegar e executar as suas principais funcionalidades.
As funcionalidades do sistema são concisas e em geral pequenas. Foi feito um levantamento das suas principais funcionalidades para que a partir delas pudesse selecionar as funcionalidades que seriam implementadas na versão móvel. Essas funcionalidades são listadas na tabela 5
Tabela 5 – Tabela de funcionalidades do sistema de controle patrimonial web existente do IMD
Nome Descrição
Gerenciar Instituições Funcionalidade responsável por manter as instituições as quais os bens estão vinculados.
Gerenciar Diretorias Responsável por manter as diretorias que estão presentes no IMD.
Gerenciar Status dos Bens Responsável por manter os possíveis status que os bens podem estar vinculados.
Importar bens Responsável pela importação dos bens através de um arquivo no formato csv - Comma Separated Values. Esta recebe um arquivo no formato csv e faz o processamento para armazenar os bens no banco de dados da aplicação. Gerenciar Bens Patrimoniais Responsável por manter os bens patrimoniais de qualquer
unidade.
Gerenciar Objetos Responsável por manter os objetos da unidade. Os obje-tos representam qualquer tipo de produto, por exemplo: impressora HP, condicionador de ar Midea, computador Apple, etc.
Emitir Termo de Responsabilidade O sistema permite a emissão de termos de responsabili-dade de bens para um usuário. O termo de responsabi-lidade significa que o usuário está se responsabilizando por um ou mais bens.
Listar Termo de Responsabilidade O sistema permite também uma listagem de termos de responsabilidade, exibindo as informações de cada termo registrado.
Transição de Entrada e Saída de
Bens Patrimoniais O sistema possui a funcionalidade de cadastro de entradae saída de bens na instituição. Nela, deve se informar os bens que estão entrando na (saindo da) instituição, assim como sua origem (destino).
Realizar o Levantamento Patrimonial Responsável por realizar o levantamento patrimonial da unidade. Esta funcionalidade é a principal do sistema. É nela que é informado todos os bens que uma determinada sala possui. Facilitando com isso o controle mais real da localização exata de cada bem patrimonial.
Gerenciar Almoxarifados Responsável por gerenciar todos os almoxarifados de qualquer unidade. Esta permite também uma visão geral de todos os bens contidos em cada almoxarifado. Gerenciar Salas Responsável por gerenciar todas as salas de qualquer
unidade. Esta permite também uma visão geral de todos os bens contidos em cada sala.
Gerenciar Unidades Responsável por gerenciar todas as unidades da institui-ção.
Gerenciar Usuário Responsável por fazer o gerenciamento de todos os usuá-rios cadastrados no sistema do patrimônio. Nesta é possível atribuir ou remover permissões de acesso a cada usuário do sistema. Nela também é possível atualizar o perfil do usuário logado.
