SMRA - Aplicativo de Gestão de Animais para Dispositivos Móveis Com NFC e Plataforma Android

INSTITUTO FEDERAL
DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA

Goiás
Tecnologia em Análise e Desenvolvimento de Sistemas
Aparecido Carlos V. Gonçalves, Íthalo Fabrício G. S. de Oliveira
SMRA - Aplicativo de gestão de animais para dispositivos móveis

com NFC e plataforma Android
Luziânia
05 de Julho de 2017
Instituto Federal de Goiás
Tecnologia em Análise e Desenvolvimento de Sistemas
Aparecido Carlos V. Gonçalves, Íthalo Fabrício G. S. de Oliveira
SMRA - Aplicativo de gestão de animais para dispositivos móveis com NFC e

plataforma Android
Trabalho de Conclusão de Curso apresentado à

Coordenação do Curso de Tecnologia em Análise e
Desenvolvimento de Sistemas do Instituto Federal
de Goiás - Câmpus Luziânia, como requisito parcial
para obtenção do título de Tecnólogo em Analise e
Desenvolvimento de Sistema.
Orientador: Prof. Me. Henrique Pereira de Freitas Filho
Luziânia
05 de Julho de 2017
G635a Gonçalves, Aparecido Carlos V.
SMRA - Aplicativo de gestão de animais para dispositivos móveis com NFC e plataforma
Android. / Aparecido Carlos V. Gonçalves, Íthalo Fabrício G. S. de Oliveira. – 2017.
74 f. ; 30 cm.
Trabalho de Conclusão de Curso (Graduação) – Instituto Federal de Goiás, Luziânia, 2017.

“Orientação: Prof. Me. Henrique Pereira de Freitas Filho.”
I. Oliveira, Ithalo Fabrício D. S. de. II. Título
CDD 005.1
AGRADECIMENTOS
Agradecemos primeiramente a Deus que nos permitiu este momento. Aos nossos pais, que
contribuíram ao longo de nossas vidas servindo-nos de referência para superarmos as dificuldades e
seguirmos em frente, a nossas companheiras que estiveram sempre a nos apoiar, compreender e ajudar nos
momentos que estivemos a precisar, a nossos irmãos, a todos os professores que contribuíram em nosso
processo de formação em especial ao nosso orientador Prof. Me. Henrique que nos prestou importantes
esclarecimentos e sugestões e a todos os demais parente e amigos que estiveram de alguma forma,
seja ela direta ou indiretamente, nos apoiando a cada degrau avançado nesta caminha exploratória de
conhecimentos fazendo com que conseguíssemos alcançar este ponto que marca o início de uma nova
jornada de busca por novos conhecimentos e compartilhamento de tudo o que nos foi compartilhado e
ensinado ao longo deste período que finalizamos.
RESUMO
GONÇALVES, Aparecido Carlos Vieira, OLIVEIRA, Íthalo Fabrício Gonçalves Soares
de. SMRA - Aplicativo de gestão de animais para dispositivos móveis com
NFC e plataforma Android. Luziânia, 05 de Julho de 2017. 74p. Trabalho de
Conclusão de Curso. Instituto Federal de Goiás
Este documento apresenta o Sistema de Manejo e Rastreabilidade Animal (SMRA), desenvolvido para a
plataforma Android que está disponível numa variedade de dispositivos móveis atuais como smartphones
e tablets. o aplicativo visa auxiliar pequenos produtores na gestão de animais, utilizando tecnologia de
fácil acesso e baixo custo, fornecendo ferramentas e informações para facilitar seu trabalho. A capacidade
de trabalhar com NFC e baixo custo de implantação é a principal características do SMRA. O aplicativo
encontra-se descrito neste trabalho.
Palavras-chave: Gestão de animais, Aplicativo, Android, SMRA, NFC, RFID, Rastreabilidade, Manejo.
ABSTRACT
This document introduces the Animal Handling and Traceability System (SMRA), developed to enableArea
that is available on a variety of current mobile devices with smartphones and tablets. The application
aims to assist small producers in the management of animals, using affordable and low-cost technology,
providing tools and information to facilitate their work. The ability to work with NFC and low deployment
cost is the main feature of SMRA. The application is described in this work.
Keywords: Animal Management, Application, Android, SMRA, NFC, Rfid, Traceability.

LISTA DE ILUSTRAÇÕES
Figura 1 – Número de produtores por área por Estado - Ano base 2006 [1]. . . . . . . . . . . . . 15
Figura 2 – Topologia genérica de uma rede para computação móvel [2]. . . . . . . . . . . . . . . . 18
Figura 3 – Estados de uma operação de desconexão [2]. . . . . . . . . . . . . . . . . . . . . . . . . 20
Figura 4 – A unidade móvel (carro) viaja de uma célula para a outra, ainda mantendo a conexão,
graças ao processo de handoff (adaptada de [3]). . . . . . . . . . . . . . . . . . . . . . 20
Figura 5 – PDA - Personal Digital Assistant [4]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figura 6 – Smartphone [5]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figura 7 – Tablet [6]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figura 8 – Notebook [7]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figura 9 – Utilização do celular ultrapassa o uso de microcomputadores no acesso a intertet [8]. . 26
Figura 10 – Ranking de vendas no Brasil de smartphones com sistema operacional Android [9]. . . 28
Figura 11 – Arquitetura do Sistema Android [10]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 12 – Replicação de banco de dados (adaptada de [11]). . . . . . . . . . . . . . . . . . . . . 34
Figura 13 – Acesso da Biblioteca SQLite ao arquivo de banco de dados [12]. . . . . . . . . . . . . . 38
Figura 14 – Tag RFID e suas camadas [13]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figura 15 – Funcionamento do Sistema RFID [14]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figura 16 – Funcionamento do NFC (adaptada de [15]). . . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 17 – Gravando ações para um aplicativo do smartphone em uma Tag NFC [16]. . . . . . . 45
Figura 18 – Efetuando pagamentos com o Smartphone através da tecnologia NFC [17]. . . . . . . 45
Figura 19 – Troca de arquivos através do NFC, bastando encostar os dispositivos na tampa traseira
[18]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 20 – Vários padrões de comunicação sem fio que coexistem atualmente [19]. . . . . . . . . . 46
Figura 21 – Modelos diversos de Tags NFC. Imagens da internet, autor desconhecido. . . . . . . . 47
Figura 22 – Ciclo do Scrum [20]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 23 – Modelo relacional do banco de dados do SMRA. . . . . . . . . . . . . . . . . . . . . . 53
Figura 24 – Fragmento do arquivo scriptdb.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 25 – Arquitetura abstrata do SMRA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 26 – Layout de uma activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 27 – Model é responsável por implementar regras de negocio, recuperar informações e
armazenar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 28 – Controller responsável por mediar as interações do usuário, fornecer os dados do model
para a view se ligar a interface do usuário. . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 29 – View responsável por exibir os dados ao usuário criando assim uma Interface do usuário
(IU). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 30 – Diagrama de classes do SMRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 31 – Tela de apresentação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figura 32 – Tela principal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figura 33 – Tela de cadastro de proprietários. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figura 34 – Tela de cadastro de animais A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figura 35 – Tela de cadastro de animais B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figura 36 – Tela de Cadastro de Eventos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figura 37 – Tela Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 38 – Tela de Cadastro de Raças. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 39 – Tela Cadastros Locais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 40 – Tela de Backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 41 – Tela lançamento de manejo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figura 42 – Tela Cadastros animais por manejo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figura 43 – Aplicativo BovControl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 44 – Aplicativo Brabov. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 45 – Aplicativo SisBov. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
LISTA DE TABELAS
Tabela 1 – Requisitos funcionais do SMRA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Tabela 2 – Requisitos não funcionais do SMRA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Tabela 3 – Explicação do Diagrama de Classes do SMRA. . . . . . . . . . . . . . . . . . . . . . . 59
Tabela 4 – Comparativo entre as aplicações. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
LISTA DE ABREVIATURAS E SIGLAS
3G Terceira Geração
4G Quarta Geração
ABIEC Associação Brasileira das Indústrias Exportadoras de Carne
ACID Atomicidade, Consistência, Isolamento e Durabilidade
API Application Programming Interface
ASN Abstract Syntax Notation
CD Compact Disc
CDMA Code Division Multiple Access
CEO Chief Executive Officer
CEPEA Centro de Estudos de Economia Agrícola
CSMA/CA Carrier Sense Multiple Access Protocol With Collision Avoidance
DML Data Manipulation Language
DVD Digital Versatile Disc
EPC Electronic Product Code
GPRS General Packet Radio Service
GPS Global Positioning System
HAL Hardware Astraction Layer
HF High Frequency
IBGE Instituto Brasileiro de Geografia e Estatística
IDE Integrated Development Environment
IEC International Electrotechnical Commission
IEEE Instituto de Engenheiros Eletricistas e Eletrônicos
IMT International Mobile Telecommunications
IP Internet Protocol
IPC Inter-Process Comunication
ISM Industrial, Scientific, Medical
ISO International Organization for Standardization
IU Interface do usuário
LAN Local Area Network
LF Low Frequency
MAC Media Access Control
MVC Model-View-Controller
NFC Near Field Communication
OFDM Multiplexação por Divisão de Frequência Ortogonal
OHA Open Handset Alliance
PC Computador Pessoal
PCMCIA Personal Computer Memory Card International Association
PDA Personal Digital Assistants
PIB Produto Interno Bruto
POO Programação orientada a objeto
QR Quick Response
SDK Software development kit
SDL Specification and Description Language
SGBD Sistema Gerenciador de Banco de Dados
SMRA Sistema de Manejo e Rastreabilidade Animal
SO Sistema Operacional
SQL Structured Query Language
SyncML Synchronization Markup Language
UHF Ultra Frequency
Wi-Fi Wireless Fidelity
XML Extensible Markup Language
XP Extreme Programming
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.1 Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.2 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5 Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1 Computação móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.1 Características da computação móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1.1 Mobilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1.2 Desconexão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1.3 Handoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.1.4 Adaptação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.2 Tecnologias de comunicação sem fio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.2.1 Telefonia celular 3G e 4G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.2.1.1 3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.2.1.2 4G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.2.2 Wi-Fi (Wireless Fidelity ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.2.3 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.3 Restrições da computação móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Dispositivos móveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Sistemas operacionais para dispositivos móveis . . . . . . . . . . . . . . . . . . . . . . 26
2.3.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1.1 Arquitetura Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.1.2 Desenvolvimento Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.1.3 Definições e Permissões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.1.4 Componentes do Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1.5 Persistência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Gerenciamento de banco de dados móveis . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.1 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.1.1 Replicação e sincronização de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.1.2 Caching e difusão de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.1.3 Gerenciamento de localidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4.1.4 Transações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4.1.5 Recuperação de falhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4.1.6 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4.2 SQLite Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.5 Identificação por radiofrequência (RFID) . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.5.1 Componentes de um sistema RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.5.1.1 Etiqueta eletrônica (Tag ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.5.1.2 Antenas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.5.1.3 Leitor ou Transceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.5.1.4 Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5.2 Funcionamento do sistema RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5.3 Frequências operacionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.5.4 Tipos de memória . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.6 Near Field Communication (NFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.6.1 Etiquetas NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.7 Metodologias ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.7.1 Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.7.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.7.2.1 Papéis do Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.7.2.2 Ciclo do Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.7.2.3 Etapas do Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3 SMRA - SISTEMA DE MANEJO E RASTREABILIDADE ANIMAL . . . . . . . . . 51

3.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2.2 Requisitos não funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3 Modelo de banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.2 Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.3 Tecnologias utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.4.3.0.1 NetBeans IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.4.3.0.2 Android SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4.3.0.3 NBAndroid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4.3.0.4 Internacionalização do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4.3.0.5 SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4.4 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.5 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
14
1 INTRODUÇÃO
1.1 Contextualização
Desenvolvida no espaço rural, a agropecuária consiste no conjunto de atividades que ocupam

o setor primário da economia do país, destacando-se o cultivo de plantas, a criação de animais para
o consumo humano ou para o abastecimento de matérias-primas empregadas na confecção de roupas,
produção de produtos de higiene e limpeza, medicamentos, biocombustíveis, entre outros, denominadas
respectivamente agricultura e pecuária [21, 22, 23].
Exercida a milhares de anos e com fundamental importância para a sobrevivência humana a

agropecuária é responsável pela integração de diversos setores da economia do Brasil com participação
de 8% no Produto Interno Bruto (PIB), sendo o agronegócio o responsável por 23% de participação no
PIB registrado pela economia brasileira em 2014 de acordo com matéria publicada no Portal do planalto
[21, 22, 23].
De acordo com estudo realizado pelo Centro de Estudos de Economia Agrícola (CEPEA) da
Escola Superior de Agricultura Luiz de Queiroz de Piracicaba - SP, publicado em matéria no portal G1,
o agronegócio brasileiro emprega 19 milhões de pessoas representando 20% do total de 91 milhões de
trabalhadores empregados no país. O estudo mostra que o setor do agronegócio que mais emprega é o da
agricultura familiar com 11,5 milhões de trabalhadores, excluindo-se desta contagem os agricultores que
produzem para consumo próprio [24].
De acordo com o relatório anual 2016 sobre o perfil da pecuária no Brasil, disponibilizado no
portal da Associação Brasileira das Indústrias Exportadoras de Carne (ABIEC), a pecuária é responsável
por cerca de 30% do PIB do agronegócio no país, em especial a criação de bovinos. Segundo o relatório,
no ano de 2016 o Brasil possuía cerca de 209,13 milhões de cabeças de gado distribuídos em 167 milhões
de hectares, onde maior parte dessa distribuição se dá entre os produtores classificados como produtores
de médio e pequeno porte que possuem áreas de até 200 Hectares para criação de seus animais. Por meio
da Figura 1 é possível observar o número de produtores de cada estado com dados coletados no censo
2006 [25, 1].
No país, grande parcela dos produtores rurais, aproximadamente 83% de acordo com dados
do censo agropecuário de 2006, exercem a agricultura familiar [26] e conforme observado na Figura 1,
enquadram-se como pequenos produtores tendo como principal fonte de renda a criação de animais. Para
obtenção de melhores resultados, os produtores necessitam de uma gestão efetiva de suas criações, a fim de
assegurar aos produtores qual a quantidade de animais por faixa de idade de sua propriedade, o controle
alimentício e de vacinação, registro histórico de eventos que podem ocorrer com cada animal ao longo de
sua vida e diversas outras informações específicas de cada criação que tornam o manejo destes animais
menos complexo.
A não existência desses dados para o produtor, pode acarretar em autuação por não cumprimento
da legislação vigente e redução de lucros. Atualmente no mercado existem softwares para esta gestão,
porém, está fora da realidade orçamentária de um pequeno produtor por exigir altos investimentos em
equipamentos e mão de obra qualificada. Partindo dessa premissa surge a necessidade de um aplicativo
que permita essa gestão a baixo custo, auxiliando os produtores no manejo de suas criações.
Capítulo 1. Introdução 15
Figura 1 – Número de produtores por área por Estado - Ano base 2006 [1].
Por meio deste trabalho será desenvolvido um aplicativo para dispositivos móveis que possuem o
sistema operacional Android que possibilitará a gestão de animais, e caso este dispositivo móvel possua a
tecnologia Near Field Communication (NFC) ela poderá ser utilizada para a otimização do seu uso.
O aplicativo de gestão de animais para dispositivos móveis chamado de Sistema de Manejo e

Rastreabilidade Animal (SMRA) irá realizar o gerenciamento de dados e prover informações que possibilite
ao produtor melhores resultados em sua atividade de manejo tais como: melhor controle de produção de
leite, carne ou melhoramento genético de animais.
1.2 Problema
Com o aumento crescente das obrigações exigidas pelo Ministério da Agricultura, Pecuária e
Abastecimento, das autarquias estaduais e dos órgãos de defesa sanitária animal, os produtores devem
ficar atentos para o cumprimento das medidas sanitárias obrigatórias, nos prazos e condições determinadas
pelo Serviço Veterinário Oficial (SVO).
Além das diversas regras e normas impostas pela legislação, diversos outros fatores tais como a
falta de tecnologia, as condições precárias das estradas, a baixa qualidade de mão de obra, a concorrência
acirrada, os clientes mais exigentes, a necessidade de otimizar custos e gerenciar a jornada de trabalho,
dentre outros, dificultam e tornam cada vez mais complexa a administração de uma pequena propriedade
rural.
Diante destas dificuldades, produtores de grande porte fazem altos investimentos em software de
gerenciamento de animais existentes no mercado, porém, os pequenos e médios produtores possuem baixo
poder aquisitivo e são obrigados a concorrer com os grandes lideres em produtividade e qualidade.
Considerando que os números de pequenos produtores rurais representam aproximadamente

83% dos estabelecimentos rurais do Brasil de acordo com dados do censo agropecuário de 2006 [26], a
discrepância do poder de investimentos dos pequenos e grandes produtores, a falta de gestão de animais nas
pequenas propriedades com o uso de tecnologias de fácil acesso e baixo custo, deixa estes produtores sem
nenhuma informação que possibilite uma boa gestão de sua propriedade. O uso de um aplicativo permitirá
a gestão de animais nas pequenas propriedades com processos de automação através de dispositivos móveis
e tecnologias de fácil acesso e baixo custo, logo, o pequeno produtor terá acesso a informações valiosas
para a gestão de seus animais sem a necessidade de altos investimentos e estruturas colossais.
1.3 Objetivos
1.3.1 Objetivo geral

Desenvolver um aplicativo para dispositivos móveis capaz de atender as principais necessidades
da gestão de animais com baixo custo de implantação e manutenção. Esse aplicativo gerenciará, por
exemplo: informações nutricionais, sanitárias, vacinas, controle de doenças e emitirá notificações para
eventos periódicos.
1.3.2 Objetivos específicos

Para atingir o objetivo geral, este trabalho tem como objetivos específicos:
a) Realizar a coleta de requisitos a fim de delinear o escopo do aplicativo;

b) Modelar e implementar o banco de dados do aplicativo utilizando um Sistema Gerenciador de
Banco de Dados (SGBD) open source;
c) Desenvolver o aplicativo proposto utilizando ferramentas open source;
d) Integrar o uso da tecnologia NFC que realiza a comunicação por campo de proximidade ao
aplicativo para leitura das TAG’s (Etiqueta eletrônica) ou adesivos NFC;
e) Prova de Conceito;
1.4 Justificativa
Sabendo que a maior parcela dos produtores do país enquadram-se como pequenos e médios
produtores, e que atualmente ferramentas tecnológicas para o gerenciamento de propriedades exigem
investimentos elevados e são de difícil acesso para essa categoria de produtores, identifica-se a necessidade de
um aplicativo que faça melhor aproveitamento de tecnologias existentes, tais como smartphones que muitos
produtores já utilizam em seu dia a dia, ampliando as possibilidades de utilização de seus dispositivos
permitindo obter menores custos de manutenção, implantação e que permita melhores resultados no
gerenciamento de suas propriedades para que essa categoria de pequenos e médios produtores tenham
maior capacidade competitiva de mercado.
1.5 Estrutura
Este trabalho está estruturado nos capítulos assim descritos:
• No capítulo 2 é apresentado o referencial teórico, onde será possível a compreensão dos conceitos
básicos necessários para o entendimento do trabalho.
• No capítulo 3 é apresentado todo o processo de desenvolvimento do aplicativo e alguns trabalhos

relacionados.
• No capítulo 4 é apresentado a conclusão deste trabalho.

18
2 REFERENCIAL TEÓRICO
2.1 Computação móvel
Do surgimento dos computadores pessoais na década de 70, de sua popularização na década de

90 aos dias atuais nota-se um crescente aumento na utilização e dependência do uso de tecnologia para o
desempenho de diversas atividades seja no ambiente profissional ou doméstico. Observa-se ainda que pouco
à frente da crescente elevação do uso e necessidade da tecnologia, está o elevado índice de desenvolvimento
de soluções e tecnologias que permitem a existência da comunicação móvel, permitindo que a qualquer
momento e a qualquer lugar a informação possa ser acessada, disponibilizando aos usuários uma gama de
serviços e aplicações com comodismo e facilidade [27, 28, 29].
Diante do cenário onde as pessoas passaram a utilizar os dispositivos móveis como parte de sua
rotina, a computação móvel é vista como um novo paradigma computacional que permite aos usuários
diversas formas de aplicações a seus dispositivos móveis tais como criar, acessar, processar, armazenar e
compartilhar a informação onde quer que estejam até mesmo durante mudanças de localização, ampliando
o conceito de computação distribuída [28, 30].
A comunicação de dispositivos com redes fixas ou móveis através de um meio sem fio, ignorando
a localização do usuário, podendo inclusive, estar em movimento é descrita através da utilização do termo
computação móvel. Para que a computação móvel seja possível faz-se necessário o uso de dispositivos
móveis, tais como smartphones, tablets, notebooks, Personal Digital Assistants (PDAs) dentre outros
equipados com tecnologia que permita a comunicação sem fio e toda a infraestrutura de comunicação sem
fio viabilizada nas áreas de comunicação celular, serviços via satélite e redes locais sem fio [27, 28, 30, 2] .
Figura 2 – Topologia genérica de uma rede para computação móvel [2].
Através da Figura 2 é possível visualizar a topologia de um ambiente de computação móvel.

Dispositivos móveis e estáticos realizam a comunicação com a rede por meio de comunicação sem fio
(expressa por linhas seccionadas) e comunicação cabeada (expressa por linhas continuas). Observa-se
que essa topologia oferece caminhos alternativos entre os dispositivos da rede, garantindo assim maior
disponibilidade, ou seja, tem-se uma topologia totalmente distribuída. Esse modelo foi adaptado de
Capítulo 2. Referencial teórico 19
[31, 2, 32, 30] e seus principais componentes são:
a) Hosts Fixos: componentes estáticos da rede de computadores;

b) Estações Base: responsáveis pela comunicação entre a unidade móvel e os hosts fixos. São
equipadas com interfaces sem fio para receber e transmitir sinais em uma determinada área
geográfica (célula) e em unidades móveis;
c) Unidades Móveis: dispositivos que se movem no domínio geográfico, tais como telefone
celular, notebooks ou PDAs. Essas unidades acessam serviços de rede, independentemente de
sua localização ou movimento.
2.1.1 Características da computação móvel

Como já apresentado, para que o ambiente de computação móvel exista é necessário o uso de
tecnologias de comunicação sem fio. É importante lembrar que em ambientes de rede sem fio existem
fatores que podem influenciar diretamente na qualidade desta comunicação, que por sua vez possui
baixa largura de banda, oferecendo um índice qualitativo inferior às tecnologias de conexões fixas. Esses
fatores que dificultam a conexão tais como a proximidade a outros equipamentos operantes em frequência
semelhante, condições climáticas e geográficas acabam por ocasionar certas desconexões e lentidão no
trafego e processamento da rede.
2.1.1.1 Mobilidade
Em computação móvel, a capacidade de locomoção de um dispositivo pela rede é denominada

mobilidade. Uma vez que a computação móvel propõe que dispositivos possam ser utilizados onde quer que
estejam localizados, a mobilidade torna-se um de seus principais objetivos, logo, o ambiente computacional
de operação do usuário passa a ser altamente dinâmico, assim como as variações de tráfego devido às
diferenças estruturais inerentes a um sistema móvel [33, 3, 2].
Problemas relativamente bem resolvidos na computação tradicional permanecem praticamente em

aberto em ambientes móveis. Os principais problemas que a mobilidade apresenta vão desde a velocidade
do canal, passando por interferências do ambiente e localização da unidade móvel, até a duração da bateria
dessa unidade [33].
2.1.1.2 Desconexão
Devido a estrutura da comunicação móvel sem fio, a confiabilidade e qualidade das conexões são
comprometidas. Neste ambiente é comum a ocorrência de desconexões intencionais como no caso de um
dispositivo que realizam a desconexão para poupar energia em situações de baixo nível de bateria ou não
intencionais nos casos onde o dispositivo é desconectado espontaneamente por estar em uma região onde
não há cobertura. Devido a essas situações diversas os aplicativos, os sistemas operacionais e os protocolos
de comunicação devem estar aptos a suportar oscilações na qualidade destas conexões [34, 33].
As operações de desconexão envolvem três estados distintos e esses estados podem se alternar a
cada ocorrência de uma desconexão, como visto na Figura 3 [2].
Durante o estado de acumulação (hoarding) ocorre o carregamento de itens na unidade móvel. Os

dados podem ser replicados ou movidos a um banco de dados local, podendo ficar inacessíveis a outros
membros da rede.
O estado de operações locais ocorre no período em que o dispositivo está desconectado da rede
fixa podendo realizar operações apenas dos dados que possuem no banco de dados local, isso ocorre após o
hoarding. Caso os dados necessários não estejam disponíveis, é criada uma fila para execução de operações
futuras que ocorrerão na próxima conexão à rede.
Por fim, o estado de reintegração que ocorre durante a reconexão, quando os dados são sincroni-
zados na unidade fixa conforme as informações provenientes dos dispositivos conectados. Uma situação de
sincronização concorrente entra em funcionamento e deve ser tratada por uma semântica correta para que
não ocorra inconsistência nos dados sincronizados.
Figura 3 – Estados de uma operação de desconexão [2].
2.1.1.3 Handoff
Handoff é a capacidade de uma rede de dar suporte dinâmico à migração de terminais móveis
entre suas células. É através desse processo, ilustrado na Figura 4, que usuários da rede conseguem manter
seus dispositivos móveis conectados ao sair de uma célula para outra vizinha. Ou seja, graças ao handoff
é possível perder o contato com uma estação base numa célula, estabelecendo contato com outra sem, no
entanto, haver desconexão, esta troca deve ocorrer quando o host móvel (o carro da Figura 4) está na
região onde as células se sobrepõem [3].
Figura 4 – A unidade móvel (carro) viaja de uma célula para a outra, ainda mantendo a conexão, graças
ao processo de handoff (adaptada de [3]).
Isto implica que uma estação base pode detectar qualquer entrada e qualquer saída de usuários
dentro e fora da sua célula. Durante o processo de handoff, as estações base são responsáveis pela
comunicação sem fio das unidades móveis, sendo que este processo é realizado de forma transparente ao
usuário [33].
2.1.1.4 Adaptação
Devido a constante mudança de contexto de um usuário móvel, ocasionado por seu deslocamento
no ambiente, faz-se necessário que as unidades móveis sejam adaptativas a fim de garantir o seu correto
funcionamento. À capacidade de ajuste e a possibilidade de produzir resultados apesar de condições
adversas dá-se o nome de adaptação. Dispositivos neste ambiente devem possuir a capacidade de executar
um número crescente de tipos de aplicações e se adaptar a situações onde há uma demanda por recursos
computacionais nem sempre disponíveis e outras, onde os recursos são abundantes e aparentemente
dispensáveis [3].
As estratégias de adaptação de um ambiente móvel variam entre dois pontos extremos. Num
extremo, a adaptação é de inteira responsabilidade das aplicações individuais. Apesar de evitar a necessidade
de suporte do sistema, a este tipo de abordagem falta um gerenciador central a fim de resolver a
incompatibilidade de demanda por recursos em diferentes contextos e impor limites no uso destes recursos.
As aplicações também se tornam mais difíceis de codificar. No outro extremo, a responsabilidade da
adaptação é inteiramente do sistema. O sistema fornece total gerenciamento e controle. Sistema nesse
contexto é a infraestrutura computacional (servidores, links de comunicação e etc.) aos quais as aplicações
individuais funcionam. Entre estes dois extremos, estão as possibilidades que são coletivamente referidas
como adaptações cientes da aplicação. Esta abordagem permite que as aplicações determinem o quanto
devem se adaptar, mas preserva a habilidade do sistema de monitorar os recursos e decidir onde alocá-los
[34, 30].
2.1.2 Tecnologias de comunicação sem fio

Nesta seção serão descritas algumas tecnologias de comunicação sem fio utilizadas atualmente.
2.1.2.1 Telefonia celular 3G e 4G
2.1.2.1.1 3G
A partir do surgimento da tecnologia de terceira geração (3G), iniciou-se uma nova forma de
utilização dos telemóveis que passaram a ter uma nova aparência física e deixaram de ter as chamadas
como principal função dando espaço a novas funcionalidades para estes dispositivos, tais como, envio
de e-mails, registro de imagens através das câmeras de video que passaram a ser incorporadas a estes
dispositivos, além de reproduzirem musicas e interagirem com o meio Web assim como os computadores
[35].
Os sistemas móveis de terceira geração (3G), chamados de sistemas International Mobile Telecom-
munications - 2000 (IMT-2000), foram projetados para prover o acesso a diferentes tipos de serviços de
comunicação de dados, e também voz, dentre eles aplicações multimídia, acesso Web e outras aplicações
que precisam de uma largura de banda não controlada normalmente em redes celulares 2G e 2,5G. Os
sistemas de terceira geração são uma evolução dos sistemas 2G [28].
Esta tecnologia permite às operadoras da rede oferecer a seus usuários uma variedade de avançados
serviços, já que possuem uma capacidade de rede maior por causa de uma melhora na eficiência espectral,
ou seja, uma melhoria na taxa de informação que pode ser transmitida em uma dada largura de banda
quando comparada a tecnologias anteriores a ela. Entre os serviços, há a telefonia por voz e a transmissão
de dados a longas distâncias, tudo em um ambiente móvel. Normalmente, são fornecidos serviços com
taxas de 5 a 10 Megabits por segundo [36].
As principais características dos sistemas 3G segundo [28] são:
a) Alto grau de padronização no projeto de dispositivos móveis;

b) Compatibilidade entre os serviços oferecidos pelas redes fixas e os definidos de acordo com o
padrão IMT-2000;
c) Adoção de terminais de usuário leves e compactos, com capacidade de roaming mundial;
d) Capacidade de tratar aplicações multimídia e uma variedade de serviços;
e) Utilização de comutação por pacote ao invés da comunicação por circuito, utilizada tradicio-
nalmente na telefonia fixa;
f) Assimetria de tráfego, com maior volume de informações transmitidas no enlace rede fixa-
dispositivo móvel, uma vez que o acesso à Internet é um dos pontos fundamentais dos sistemas
3G.
2.1.2.1.2 4G
A tecnologia de quarta geração (4G) também conhecida por LTE (Long Term Evolution) é a
mais recente e atual evolução das redes de comunicação móvel. Essa tecnologia promete a seu utilizador
vantagens superiores ao que é oferecido pela tecnologia 3G. Essa tecnologia consegue fornecer velocidades
de download na ordem dos 150MBps, capacidade de visualizar vídeos em alta definição através dos
dispositivos móveis, menor latência na conexão, dentre outras vantagens [37].
A rede 4G possui uma nova forma de se comunicar, utilizando um IP (Protocolo de Internet),

ou seja, sua infraestrutura é composta por um conjunto de redes que utilizam o protocolo IP em suas
conexões, permitindo através deste protocolo que vários usuários além de fazer ligações com alta qualidade,
acessem a rede de internet e obtenham serviços como dados, fotos streamig de video e musica em qualquer
lugar[37]. Ainda de acordo com [37] Esse processo é feito por um transmissor OFDM (Multiplexação por
Divisão de Frequência Ortogonal) que aceita os dados a partir de uma rede IP, convertendo e codificando
antes de fazer a modulação. O OFDM proporciona uma melhor ligação e qualidade da comunicação sem
muito atraso na escolha dos multi-caminhos.
2.1.2.2 Wi-Fi (Wireless Fidelity )
Conhecido como “Wi-Fi ” abreviação de Wireless Fidelity, utiliza a tecnologia de rádio no padrão
IEEE 802.11 para conectar computadores uns aos outros, à Internet e a outras redes cabeadas usando
Ethernet[36].
O padrão de redes locais sem fio (802.11) define o protocolo e a compatibilidade de interconexão
de equipamentos de comunicação de dados via ar, rádio ou infravermelho em uma rede local (LAN) usando
o “Carrier Sense Multiple Access Protocol With Collision Avoidance” (CSMA/CA) como mecanismo de
compartilhamento do meio. O Media Access Control (MAC) suporta operações abaixo do controle do
ponto de acesso assim como entre as estações independentes. O protocolo inclui autenticação, associação e
reassociação de serviços, um procedimento opcional que cifra e decifra o gerenciamento de energia[36].
O padrão inclui a definição de base de informação gerenciável usando uma linguagem para
descrever informações estruturadas denominada Abstract Syntax Notation One (ASN.1) e especifica o
protocolo MAC formalmente, usando a linguagem de descrição e especificação Specification and Description
Language (SDL) definida pela União Internacional das Telecomunicações [36].
2.1.2.3 Bluetooth
Bluetooth é uma tecnologia para conexão sem fio do padrão IEE/802.15, que é de curta distância
utilizada em dispositivos móveis como celulares, palms, fones de ouvido, microfones, computadores entre
outros. A tecnologia Wireless Bluetooth é um padrão de fato e uma especificação para enlaces entre
dispositivos móveis, usando ondas de rádio de curto alcance.
A proposta da tecnologia Bluetooth é habilitar os usuários para a conexão de uma grande variedade
de dispositivos de computação e telecomunicações de maneira simples e fácil, sem a necessidade de cabos.
Como a tecnologia é baseada em enlace via rádio, é fácil a transmissão rápida e segura de voz e dados
na rede. A operação do Bluetooth é efetuada em uma banda de frequência entre 2.402 e 2.480 Ghz
que está globalmente disponível e tem compatibilidade mundial, sendo portanto um padrão global para
conectividade wireless.
A tecnologia Bluetooth é muito resistente a dificuldades eletromagnéticas, o que garante que as

interferências sejam pequenas, porem a distância entre os dispositivos para estabelecer uma conexão ideal
é pequena chegando apenas a 10 metros e no máximo 100 metros entre os dispositivos. [36]
2.1.3 Restrições da computação móvel

Considerando as características da computação móvel apontadas na seção anterior é possível
observar três principais restrições que afetam o desempenho da computação móvel, conforme [2] descreve:
• Restrições dos dispositivos móveis: devido à limitação de tamanho, dispositivos móveis continu-
arão tendo algumas limitações, como por exemplo, velocidade do processador, capacidade de memória,
tamanho da tela e sua resolução. A diversidade arquitetural proporciona grande variabilidade das
configurações de hardware das unidades móveis;
• Restrições de comunicação: limitações como largura de banda, desconexão, alta latência e área
de cobertura;
• Restrições de mobilidade: o usuário de dispositivos móveis está em constante movimento e,

portanto, realiza diversas mudanças de localização. Devido a essas movimentações, podem existir
desconexões do dispositivo móvel, havendo falhas de comunicação com a rede. A conexão móvel
é altamente variável em desempenho e confiabilidade. Além disso, existe a perda temporária de
comunicação quando ocorre deslocamento entre áreas mantidas por diferentes estações base e
renegociação de características de acesso.
2.2 Dispositivos móveis
Para [38] as redes de dados móveis proporcionaram novas formas de comunicação através do uso
de dispositivos móveis tais como Personal Digital Assistant (PDA), atualmente esse tipo de dispositivo
é pouco utilizado uma vez que as tecnologias atuais ultrapassaram a gama de benefícios que este tipo
de equipamento oferecia em sua época de criação, tablets e smartphones. Estes equipamentos vão muito
além de assistentes pessoais e agendas eletrônicas, são computadores que podem facilmente serem levados
a qualquer lugar com intuito de suprir as necessidades de profissionais e pessoas em movimento que
necessitam de facilidade, rapidez e segurança no acesso a informações sejam elas pessoais ou corporativas.
Existem inúmeros aparelhos que podem ser utilizados no ambiente de computação móvel, no
entanto a escolha do equipamento adequado irá depender de fatores como tipo de atividade, modelo de
captura e apresentação das informações e volumes de dados esperados. Veja a seguir alguns dos dispositivos
móveis mais utilizados [39, 33]:
• Personal Digital Assistant - PDA

São dispositivos móveis com tela monocromática ou colorida e sistema de entrada de dados por
tela sensível ao toque (touch screen). A maioria já possuem aplicativos como calendário, agenda,
bloco de notas entre outros, inclusos juntamente com o sistema operacional, como o ilustrado na
Figura 5. Existem ferramentas comerciais e livres para desenvolvimento de aplicativos para estas
plataformas. A interface física com outros equipamentos pode ser realizada através de comunicação
serial, bluetooth e por alguns slots do tipo PCMCIA e compact flash. Existem comercialmente,
interfaces com estes dispositivos para a utilização de transferência de dados via GPRS e também
utilizando serviços da rede CDMA e WI-FI. Os dois principais sistemas operacionais para PDAs são
o Palm OS da Palm Inc e o Pocket PC da Microsoft Inc. [36]
Figura 5 – PDA - Personal Digital Assistant [4].
• Smartphone
São telefones celulares com funções mais avançadas. O termo “smart” vem do inglês e significa
“inteligente”, sendo assim “telefones inteligentes”, esses dispositivos permitem conexão com a internet
através de meios sem fio (wireless), possuem a capacidade de executar softwares, possuem processa-
mento gráfico e de informações entre outros recursos disponibilizados por eles, a Figura 6 ilustra
alguns desses dispositivos móveis. Atualmente a maior desvantagem é o tamanho da tela, a qual,
geralmente é menor que a de um tablet [36].
Figura 6 – Smartphone [5].
• Tablet
É um dispositivo pessoal em formato de prancheta que pode ser utilizado para acesso à internet,
organização pessoal, comunicação, acesso de informações, leitura de livros, jornais entre outros.
Também pode ser utilizado para tirar fotos e gravar vídeos, além de possuir uma tela sensível ao
toque (touchscreen) sem a necessidade da utilização de periféricos para navegar, por exemplo, mouse
e teclado externos [36]. A Figura 7 ilustra a representação de um tablet.
Figura 7 – Tablet [6].
• Notebook
É um computador portátil como é ilustrado na Figura 8 com as mesmas funções de um desktop.
Tem maior poder de processamento e armazenamento que o palmtop e o handheld. É também mais
caro. Possui teclado, mouse, CD, DVD, etc. [33]
Figura 8 – Notebook [7].
Para aqueles do time de profissionais móveis que maior parte do tempo é despendido em trabalhos
remotos, estes equipamentos além de serem dedicados podem ainda ser versáteis, multifuncionais e em
alguns casos de uso genérico. Diante da quantidade de recursos existentes nestes dispositivos tornam-
se grandes aliados no âmbito empresarial quando aplicados no uso de coleta de dados e produção de
informações estratégicas agregados a outros recursos tais como internet, câmeras de captura de imagens e
sensores de localização GPS (Global Positioning System) [33, 40].
Uma importante observação é feita por [34], onde esclarece que portabilidade e mobilidade são
conceitos diferentes, um dispositivo pode ser portátil e não possuir capacidade de computação móvel
como, por exemplo, um laptop num carro, ou num avião, realizando tarefas comuns (como processamento
de texto e planilha eletrônica), mas sem capacidade de se conectar a uma rede sem fio (sem um cartão
PCMCIA, por exemplo). Analogamente, num Escritório de uma empresa que funcione num prédio sem
fiação, a LAN (Local Area Network ) será uma rede sem fio (wireless), mas esse não será um caso de
computação móvel.
Além da comodidade e mobilidade que os dispositivos móveis proporcionam, a crescente melhoria

dos meios de comunicação e facilidade de aquisição dos dispositivos móveis fez com que o número de
utilizadores crescesse rapidamente. A Figura 9 mostra a pesquisa divulgada pelo IBGE em abril de 2016.
Pesquisa mostra que a proporção de domicilios brasileiros que utilizavam a internet por celular saltou
de 53,6% para 80,4% de 2013 para 2014, ultrapassando dessa forma a quantidade de utilizadores dos
computadores.
Figura 9 – Utilização do celular ultrapassa o uso de microcomputadores no acesso a intertet [8].
Essa elevação do número de usuários fez com que fabricantes destes dispositivos buscassem
melhorias na tecnologia a fim de entregar a estes usuários um melhor desempenho no uso de seus
dispositivos e possibilitando aos desenvolvedores inovar no desenvolvimento de suas aplicações gerando
cada vez mais facilidade de utilização e elevando a quantidade de processos e atividades que antes eram
desenvolvidas apenas por desktops locais para serem utilizados em aparelhos móveis[36].
2.3 Sistemas operacionais para dispositivos móveis
De maneira genérica e simplificada um sistema operacional pode ser entendido como sendo um
programa que realiza o intermédio entre o hardware do computador e seu usuário, de modo que este
usuário consiga de forma descomplicada a realização das operações desejadas sem que ocorra o contato
direto com o hardware do computador[41].
Fica à cargo do sistema operacional realizar o gerenciamento de todo o hardware do computador

que consiste basicamente em alguns componentes de processamento, armazenamento, comunicação, entrada
e saída. Além de gerenciar e otimizar o uso destes componentes o sistema operacional deverá servir de base
para os diversos programas e aplicativos que o usuário venha a instalar em seu dispositivo para a realização
de suas tarefas, provendo ao usuário um ambiente ao qual este possa fazer o uso de uma forma mais
conveniente e eficiente não havendo a necessidade do programador ou usuário entender detalhadamente
como se dá o funcionamento do hardware [41, 42].
Os sistemas operacionais podem variar em sua forma de funcionamento e realização de tarefas de

acordo com sua finalidade. Resumidamente temos três modalidades de sistemas operacionais que são:
• Sistemas operacionais com finalidade de funcionamento em computadores de grande

porte (mainframes): Seu uso é mais comum onde exige enorme capacidade de processamento
como em centros de pesquisas e servidores web, são projetados principalmente para que seja possível
obter o melhor desempenho possível da utilização de seu hardware e orientados para o processamento
de múltiplas tarefas simultâneas. Os sistemas operacionais mais conhecidos para essa finalidade são
z/OS, z/VM, z/VSE e zTPF e algumas distribuições do Linux.
• Sistemas operacionais projetados para o uso em computadores pessoais (PC): Tem maior
ênfase em prover ao usuário uma interface de usuário que seja conveniente e eficiente, permitindo
que games e aplicações comerciais como planilhas, processadores de texto, acesso à internet sejam
facilmente executadas. Os sistemas operacionais mais conhecidos para essa finalidade são Microsoft
Windows, Linux, Mac OS X.
• Sistemas operacionais para dispositivos móveis: Possui características dos sistemas operaci-
onais para computadores pessoais combinados com recursos úteis e necessários para dispositivos
móveis. Os dispositivos portáteis em sua maioria possuem limitações quanto a sua capacidade de
armazenamento e processamento, essa característica os tornam inferiores quando comparados com a
capacidade de armazenamento e processamento dos PC’s no entanto, estes sistemas operacionais são
menores mas possuem capacidade de manipular telefonia, fotografia digital, recursos de localização
GPS e comunicação sem fio, dentre outros. Seu uso é comum em dispositivos que cabem no bolso
tais como telefones celulares, smartphones, tablets e PDAs. Os projetistas deste tipo de sistema
operacional enfatizam a capacidade de gerenciar todo seu hardware com baixíssimo consumo de
energia e a capacidade de prover a informação e a manipulação desta pelo usuário através das
pequenas telas que muitos destes equipamentos possuem. Os sistemas operacionais mais conhecidos
para essa finalidade são Symbian, Windows Phone, IOS e Android que serão abordados na próxima
seção.
2.3.1 Android
O sistema operacional Android foi em outubro de 2003 desenvolvido por uma start-up americana
no vale do Silício chamada Android Inc.. Logo mais, em agosto de 2005 foi adquirida pela empresa
Google que juntamente com a Open Handset Alliance (OHA) que é uma aliança formada por mais de 30
empresas das quais figuram o próprio Google e outras de importância nos ramos de telefonia, fabricação de
semicondutores (Intel) e fabricação de celulares (Motorola), dentre outras, amadureceu o projeto inicial e o
tornou público em 2007 com objetivo de apresentar a primeira plataforma open source de desenvolvimento
para dispositivos móveis baseada no kernel do Linux sendo este, mantido até os dias atuais pela OHA.
Após uma semana do seu lançamento foi liberada a primeira versão do SDK para Android.
Originalmente este sistema foi desenvolvido para câmeras fotográficas, porém, seus desenvolvedores
perceberam um canal de maior exploração no ramo de telefonia ocasionando o desvio de foco do segmento
de câmeras para o segmento de smartphones diretamente competindo com os sistemas Symbian e Windows
Mobile [43, 44].
Seus desenvolvedores o definem como sendo uma pilha de software de código aberto criada para
uma grande variedade de dispositivos com diferentes fatores de forma. Os principais propósitos do Android
são criar uma plataforma de software aberto disponível para operadoras, fabricantes de equipamentos e
desenvolvedores para tornar suas idéias inovadoras uma realidade e para introduzir um produto de sucesso,
real-world que melhora a experiência móvel para os usuários [45].
Em um evento realizado no ano de 2015 o CEO do Google, Sundar Pichai afirmou que o sistema
operacional Android ultrapassou 1,4 bilhão de usuários no mundo [46]. Pesquisa realizada por empresa
americana Kantar Worldpanel, mostra que no ultimo trimeste de 2015 smartphones com sistema Android
se mantiveram na liderança do ranking de vendas no Brasil terminando em dezembro de 2015 com 91,8%
de participação de mercado conforme ilustrado na Figura 10, elevando o indice que em 2014 era de 89%
[47, 9].
Figura 10 – Ranking de vendas no Brasil de smartphones com sistema operacional Android [9].
2.3.1.1 Arquitetura Android
Baseado no kernel Linux, o Android de forma geral tem sua estrutura dividida nas seguintes
camadas conforme ilustrado na Figura 11:
• Application Framework : É a camada que está ao topo da estrutura. Nesta camada são instaladas
as aplicações construídas pelos desenvolvedores [10, 43].
• Binder Inter-Process Comunication (IPC) Proxies: Situada logo abaixo da camada Appli-
cation Framework. É responsável por realizar a ponte entre as aplicações instaladas na camada
imediatamente acima com a próxima camada denominada System Services. É uma interface que
permite a interação de APIs de alto nível com serviços do sistema que estão situados na camada
inferior a ela [10, 43].
• System Services: Abaixo da camada Binder IPC Proxies, esta camada permite através de módulos
o acesso a hardwares específicos. Divididos em duas categorias, Media Server que são os serviços
responsáveis por gerenciar conteúdos de mídia como gravação e reprodução de áudio e vídeo e
System Server que são serviços responsáveis por gerenciar os demais tipos de serviço do sistema
como notificações. Cada serviço dessa camada é responsável pelo gerenciamento de um componente
especifico como notificações e buscas [10, 43].
• Hardware Astraction Layer (HAL): Permite aos fornecedores de hardware criarem interfaces e
drivers para os hardwares que estes produzem. Dessa forma, é possível a criação e implementação de
novas funcionalidades sem que as demais camadas do sistema sejam afetadas [10, 43].
• Linux Kernel : Por fim temos esta camada que nada mais é que uma versão modificada do kernel
do Linux. Esta versão recebeu algumas modificações tais como, gerenciamento de memórias mais
avançados, apropriados para dispositivos móveis e funcionalidades para dispositivos embarcados
[10, 43].
Figura 11 – Arquitetura do Sistema Android [10].
2.3.1.2 Desenvolvimento Android
Recomenda-se para o desenvolvimento de aplicações Android o uso da linguagem de programação

Java. Não se faz necessário o uso de um sistema operacional especifico uma vez que o SDK ou kit
de desenvolvimento Android está disponível para Windows, Linux e MacOS, disponibilizando um rico
conjunto de ferramentas, desde depurador, bibliotecas, emuladores, documentação, código de exemplos e
tutoriais. O Google indica a IDE Android Studio no desenvolvimento das aplicações Android pois esta é
oficialmente a IDE distribuída para tal finalidade [10, 43].
Para que um desenvolvedor tenha seu aplicativo disponibilizado para uso, faz-se necessário a
publicação deste na loja de aplicativos do Google, Google Play Store, no entanto, além do aplicativo
passar por um processo de avaliação a fim de verificar se não está sendo violada nenhuma das políticas
estabelecidas pela loja é cobrada uma taxa única no valor de US$25 [43].
2.3.1.3 Definições e Permissões
Obrigatoriamente para cada aplicação desenvolvida para Android deverá existir em seu diretório
raiz um arquivo que disponha de todas as suas definições e permissões. O principal arquivo de configuração
do aplicativo é o AndroidManifest.xml que possui uma estrutura em Extensible Markup Language (XML)
e fica a cargo do desenvolvedor realizar o preenchimento deste arquivo. Nele ficam declarados todos os
recursos que serão utilizados pela aplicação, bem como as definições de permissões para as execuções
das tarefas e informações gerais sobre o aplicativo, como a versão mínima do Android compatível, o
versionamento do aplicativo, a primeira Activity a ser aberta, dentre outras. [48].
2.3.1.4 Componentes do Android
Toda aplicação desenvolvida para Android realiza sua comunicação através de componentes, onde
cada componente existente possui identidade única e implementa suas próprias regras, podendo ou não
haver dependências com outros componentes. Os componentes dos aplicativos Android são divididos em
dois grupos: os componentes principais que podem servir de ponto de partida e são responsáveis por
funcionalidades de maior complexidade e os componentes adicionais que não foram projetados para servir
como ponto de partida dos aplicativos servindo apenas para suporte para a realização das atividades dos
componentes principais. Os quatro principais tipos de componentes do Android são a Activity, o Service,
o Content Provider e o Broadcast Receiver, onde [49, 48]:
• Activity : é o componente mais utilizado, tendo como responsabilidade a iteração do usuário com a
tela do dispositivo. Sua representação é tida como uma tela do aplicativo e em um aplicativo que
possua mais de uma Activity será necessário configurar no arquivo Manifest apenas uma delas como
sendo a Activity que será exibida quando o aplicativo for aberto;
• Service: é um componente desprovido de interface de usuário sendo utilizado para tarefas em

segundo plano. Sua utilização objetiva é a execução de tarefas que levem um longo período de tempo
para serem completadas;
• Content Provider : é o componente que possui a responsabilidade de realizar o gerenciamento dos

dados de um aplicativo que pode ser compartilhado com outros e realizar o armazenamento desses
dados em qualquer forma persistente de armazenamento que permita às aplicações que possuam as
permissões necessárias a obterem acesso e realizar a leitura e/ou escrita dos dados;
• Broadcast Receiver : é o componente responsável por alertas gerados para todo o sistema, ou seja,
é ativado quando ocorre a transmissão de uma mensagem pelo sistema ou qualquer outro aplicativo
para todos aqueles que estiverem ouvindo.
A reutilização de componentes entres diversos aplicativos é um aspecto único do sistema Android

permitindo que qualquer aplicativo inicie um componente de um outro aplicativo. Os componentes
adicionais existem para tornar fácil a construção de componentes, simplificando a lógica que exite por
trás dos recursos que o aplicativo disponibiliza e possibilitar a conexão entre os componentes principais.
Alguns dos componentes adicionais do Android são [48]:
• Intents: representa uma mensagem assíncrona enviada para ativar Activities, Services ou Broadcast
Receivers. A inicialização de uma Activity, seja para navegar dentro do próprio aplicativo ou para a
utilização do serviço de um outro aplicativo, ocorre utilizado esse componente, sendo possível o envio
de dados nesta mensagem de maneira que o componente chamado saiba de uma forma apropriada
realizar o tratamento desta requisição;
• Fragments: representa uma parte de uma Activity. A utilização deste componente permite que o
conteúdo de uma Activity possa ser alterado conforme o tamanho da tela do dispositivo. Caso a
tela possua um tamanho maior e seja suficiente é possível em uma mesma Activity a disposição de
múltiplos Fragments. A partir desse componente tornou-se possível a criação de aplicativos onde a
implementação de Activities ocorra de maneira mais modular;
• Views: representa o elemento mais básico de uma interface de usuário, sendo este elemento o
responsável pelo desenho e pelo tratamento de eventos da estrutura desta interface. Estes componentes
podem ser adicionados em um arquivo XML para a criação da interface do usuário de forma
declarativa, porém, existe a possibilidade de serem gerenciados dinamicamente por meio de comandos
da API Java do Android ;
• Layouts: é um container para Views que realiza o gerenciamento de sua disposição na tela. É um
componente útil para o ajuste da interface do usuário criada de forma declarativa através de um
arquivo XML. Uma série de diferentes Layouts são disponibilizadas pelo Android cada um com suas
particularidades na configuração para disposição dos elementos;
• Recursos: podem ser utilizados pelo código fonte que implementa a lógica de negócio de um
aplicativo Android. Estes recursos incluem imagens estáticas, definição de cores, temas, estilos,
animações e layouts das interfaces de usuário, arquivos de Strings utilizados para internacionalização
do aplicativo, entre outros arquivos de configuração. É possível ainda armazenar arquivos quaisquer
que seu aplicativo pode necessitar.
2.3.1.5 Persistência
Varias opções de persistência de dados dos aplicativos são oferecidas pelo sistema Android. A
escolha de uma solução ideal pode variar de acordo com cada caso e para que ocorra uma escolha adequada
é importante a observação de alguns fatores, tai como: quanto de armazenamento será exigido para
armazenar os dados? Os dados de uma aplicação deverão ser exclusivos ou poderão ser compartilhados?
As possibilidades de armazenamento de dados disponibilizadas pelo Android são [48]:
• Armazenamento interno: Esta opção de persistência utiliza a memória interna do aparelho para
persistir os dados e enquanto a aplicação estiver instalada no aparelho os dados serão mantidos. Por
padrão outras aplicações não poderão recuperar os dados armazenados de outra aplicação, mantendo
uma exclusividade para determinado aplicativo.
• Armazenamento externo: É comum esse tipo de persistência para todo dispositivo que tenha
suporte para armazenamento externo, podendo ser um cartão de memória removível que geralmente
possuem capacidade de armazenamento elevadas. Neste local os dados persistidos são públicos
podendo ser lidos, modificados e ate mesmo removidos por outros aplicativos ou dispositivos que
tenham capacidade de leitura desse tipo de memória, logo, os dados escritos neste local não são
removidos automaticamente quando o usuário remove o aplicativo e sua disponibilidade deverá
sempre ser verificada antes do uso.
• Shared Preferences: É uma Application Programming Interface (API) disponibilizada pelo Android
para realizar a persistência de dados simples, tais como, as variáveis primitivas da linguagem java. Os
dados permanecerão armazenados ainda que o aplicativo não esteja em execução. Além de ser uma
API de fácil utilização, é uma opção adequada para uma pequena quantidade de dados. Geralmente
é empregado no armazenamento de variáveis que devem manter seu valor entre sessões do usuário.
• Nuvem: Para aqueles que não podem se limitar a capacidade de armazenamento local, o Android
permite que seja realizado a persistência dos dados em um servidor remoto através de serviços
de comunicação em nuvem e web services, porém, esta opção esta limitada a disponibilidade e
capacidade de conexão.
• SGBD SQLite: Para armazenamentos de dados que podem ser estruturados em tabelas assim
como um banco de dados relacional, o Android oferece suporte completo SGBD SQLite. Sendo as
informações armazenadas nesse tipo de persistência privadas ao aplicativo que criou o banco.
2.4 Gerenciamento de banco de dados móveis
Nos dias atuais muitas informações são geradas por meio de agendas eletrônicas, pesquisas
cientificas, operações financeiras, avaliações e análises diversas, dentre outras inúmeras formas de produzir
informações, porém, para que informações sejam produzidas é necessário que existam os dados armazenados
para que as pessoas possam trabalhar esses dados e produzir a informação.
Produzir informações por meio de recursos computacionais tem sido uma atividade muito comum
no cotidiano das pessoas e para que isso seja possível, faz-se necessário a existência de um banco de dados
onde é possível manter os dados de forma organizada e relacionados a fim de recupera-los sempre que
necessário por meio de programas que permitam a manipulação destes dados. De forma genérica um banco
de dados é definido como uma coleção de dados relacionados que por meio de uma coleção de programas
conhecidos como SGBD permite ao usuário acessar e modificar estes dados, formando assim um sistema
de banco de dados [41, 50].
Diante da frequente utilização de dispositivos móveis e dos recursos possibilitados através da

computação móvel, diversas aplicações em banco de dados são desenvolvidas. Como discutido anteriormente,
a computação móvel faz o uso do ambiente de comunicação sem fio, que por sua vez possui algumas
restrições tais como limitação da largura de banda dos canais de comunicação sem fio, o grande número
de usuários, a mobilidade e as desconexões frequentes dos dispositivos móveis e a mobilidade dos dados,
implicando a necessidade de mudanças no gerenciamento e nos mecanismos que garantem a consistência
dos dados gerados por estas aplicações, a fim de garantir que estas aplicações tenham uma execução
efetiva [2].
Como é possível ter a visão de computação móvel como uma variação da computação distribuída,
[50] aponta dois possíveis cenários para a distribuição dos bancos de dados móveis onde, no primeiro
cenário a distribuição da base de dados se dá principalmente entre os componentes sob a rede cabeada,
possivelmente com replicação integral ou parcial dos dados. Um servidor é responsável por gerenciar sua
própria base de dados através de um SGBD com funcionalidades adicionais para realizar a localização
de unidades móveis e para gerenciar consultas e transações que satisfação as necessidades dos ambientes
móveis. No segundo cenário, a distribuição da base de dados é feita entre os componentes sob a rede
cabeada e sob a rede sem fio. Compartilhando a responsabilidade do gerenciamento da base de dados
entre os servidores de base de dados e as unidades móveis.
De acordo com [50], podem ser aplicados aos bancos de dados móveis muitas das questões
de gerenciamento de bancos de dados distribuídos desde que os aspectos a seguir sejam levados em
consideração:
• Distribuição e replicação de dados: Os dados podem estar distribuídos entre os servidores e as

unidades móveis de forma assimétrica. O problema de gerenciamento de dados em cache é elevado
em função das restrições de consistência. Os dados acessados e atualizados com maior frequência
são passados pelos caches para as unidades móveis para que estas possam processarem suas próprias
transações e ficarem desconectadas por um período maior de tempo;
• Modelos de transação: No ambiente móvel as questões de tolerância a falhas e ausência de erro

das transação são ampliadas. A transação móvel é executada sequencialmente por diferentes estações
base e possivelmente, de acordo com o movimento da unidade móvel ocorrem em múltiplos conjuntos
de dados. No cenário onde se tem a distribuição da base pelos componentes da rede cabeada e
sem fio, não existe coordenação central na execução de uma transação. Além do mais, em função
da desconexão em unidades móveis, espera-se que as transações móveis sejam duradouras. Logo
as propriedades de transações tradicionais Atomicidade, Consistência, Isolamento e Durabilidade

(ACID) das transações podem necessitar de modificações levando a definição de novos modelos de
transação;
• Processamento de consultas: A análise de custo benefício do processamento da consulta pode

ser afetada caso não seja dado a devida importância para a ciência da localização dos dados. Ainda
que as unidades móveis estejam em transito e ou atravessando fronteiras de células, a resposta da
consulta deverá ser fornecida a estas de forma que elas a recebam completamente e corretas as
respostas;
• Recuperação e tolerância a falhas: Falhas de mídia, de transação, de comunicação e até mesmo

falhas locais (queda de uma unidade móvel por limitações de bateria) podem ser vistas em um
ambiente de banco de dados móveis, porém, se uma unidade móvel voluntariamente desliga sua
conexão, este fato não deverá ser tratado como falha. Durante a travessia de células por parte dos
dispositivos móveis (handoff ) é que frequentemente ocorrem as falhas nas transações. Espera-se que
o gerenciador de transações esteja apto a lidar com falhas frequentes. Os algoritmos de roteamento
são afetados devido ao particionamento da rede causado por falhas em unidades móveis;
• Serviço baseado na localização: Conforme a locomoção dos clientes, a informação dependente

da localização no cache pode tornar-se defasada. Técnicas de despejo para os clientes são relevantes
nessa situação. Além disso, atualizar constantemente as consultas dependentes de localização, e
então fazer a aplicação destas consultas para atualizar o cache, apresentam um problema;
• Divisão do trabalho: Uma mudança na divisão de trabalho no processamento de consultas pode

ser forçada em função de certas características do ambiente móvel. Em algumas situações é preciso
que o cliente funcione independentemente do servidor;
• Segurança: Por estarem em um ambiente móvel, os dados móveis são mais suscetíveis a perdas e
inconsistências do que os dados que são deixados em uma localização fixa. As técnicas formais para
gerenciamento e autorização de acesso a dados críticos se tornam mais importantes nesse ambiente.
Os dados também são mais voláteis, e as técnicas precisam ser capazes de compensar sua perda.
2.4.1 Características
Alguns fatos que caracterizam os bancos de dados móveis foram citados na seção anterior, nesta
seção serão apresentados individualmente os conceitos de algumas destas características.
2.4.1.1 Replicação e sincronização de dados
Dá-se o nome de replicação ao processo onde um grupo de arquivos ou arquivo individual é copiado
de seu local de armazenamento original para outras maquinas que integram um sistema distribuído. A fim
de obter maior disponibilidade de dados e a performance de aplicações contidas em dispositivos móveis
sobre estes dados, cópias redundantes das informações contidas no banco de dados distribuídos (dados
replicados) são carregadas pelos dispositivos móveis [34]. Através da replicação, recursos de hardware e
rede são otimizados elevando a flexibilidade e a escalabilidade em ambientes heterogêneos, podendo ser
essa replicação parcial ou total. Na replicação parcial apenas uma parte dos dados de um banco de dados
são replicados para outros bancos, já na replicação total todos os dados são replicados de um banco para
outro. Com a replicação total, se pelo menos uma das cópias estiver disponível, a confiabilidade aumenta,
uma vez que o usuário não depende apenas dos dados disponibilizados em uma única localidade. No caso
de acontecer algum problema no sistema, a réplica dos dados é solicitada pelo usuário [2].
A Figura 12 ilustra o cenário onde os dados contidos no banco de dados original são replicados
para outras estações distribuídas na rede, ou seja, cópias idênticas aos dados contidos no banco de dados
original são feitas em outras estações, essas réplicas são sincronizadas com o banco de dados original a
fim de garantir que as transações realizadas pelos dispositivos móveis possam ser realizadas através das
réplicas ainda que o banco de dados original não esteja disponível para acesso direto e imediato pelos
dispositivos móveis.
Figura 12 – Replicação de banco de dados (adaptada de [11]).
A sincronização de dados é o processo onde os dados distribuídos são mantidos e atualizados de

forma que a versão mais recente do arquivo seja seguramente visualizada pelos usuários em cada local.
Quando ocorre a sincronização entre os dados do servidor ou base e suas réplicas é utilizado o log de
transação de cada volume para verificar se os dados foram inseridos, removidos ou atualizados da base
central, após esta verificação as cópias mais recentes são replicadas para todos os outros locais que acessam
esses dados. Sempre que dados compartilhados são modificados por uma aplicação em uma base de dados,
as outras bases que possuem réplicas são propagadas por estas mudanças. Podendo estas modificações
serem propagadas por diversos canais de comunicação ou tipos de protocolos [34]. Quanto a propagação
dos dados, a replicação destes segundo [34] pode ser baseada em:
• Sessão: Neste esquema, a replicação ocorre através de uma linha de comunicação direta entre a base
consolidada e a base remota, dependendo da configuração inicial, os intervalos entre duas destas
sessões podem ser de minutos, horas, dias ou semanas. A base remota cliente abre a comunicação
com o servidor de sincronização, enviando uma lista completa das modificações feitas naquela base
desde a última sincronização. O servidor, então, atualiza a base consolidada e envia de volta as
modificações relevantes. O host remoto incorpora o conjunto de mudanças e fecha a sessão logo após
enviar uma confirmação de sucesso da operação junto com uma tabela que mapeia o conteúdo das
informações que foram atualizadas (mapping table);
• Mensagens: A troca de dados entre as bases pode ocorrer também através de mensagens, que
normalmente são arquivos armazenados em algum diretório particular ou mensagens de correio
eletrônico com formato especial. Um agente de mensagens vinculado a cada base envia mensagens,
informando as mudanças recentes em sua base e recebe mensagens de um ou mais outros agentes,
modificando seus dados de acordo com o conteúdo delas. Este sistema permite replicação entre
bancos de dados que não estão diretamente conectados. Neste tipo de replicação, cada uma das
mensagens carrega informações de controle como o seu endereço de destino para que nenhuma
conexão seja necessária entre as aplicações que se comunicam remotamente;
• Conexão: Algumas tecnologias de replicação dependem de uma conexão contínua, ou praticamente

contínua, entre as bases remotas e a base consolidada. Este tipo de replicação é caracterizado por
ser rápido e confiável, porém de manutenção cara, já que necessita de muitos recursos. Este tipo de
esquema é, desta forma, mais apropriado para replicações entre bases consolidadas.
A falta de padronização do protocolo é um dos desafios enfrentados por sistemas que necessitam de
sincronização[34, 2]. Em fevereiro de 2000, empresas como a Ericsson, IBM, Motorola e Nokia, entre
outras se reuniram para começar a resolver o problema. O primeiro e importante passo foi a criação do
SyncML, um padrão aberto para a sincronização universal de dados e informações pessoais entre vários
tipos de redes, plataformas e dispositivos. O SyncML especifica 7 diferentes tipos de sincronização:
1. Em dois sentidos (Two-way sync), o tipo mais comum de sincronização, onde cliente e servidor
trocam informações sobre as modificações ocorridas em suas bases (ver os passos de uma replicação
baseada em sessão, acima);
2. Lenta (Slow sync) é uma forma de sincronização onde todos os itens da base de dados do cliente são
comparados com os da base consolidada campo a campo. Pode ser requisitada pelo cliente após uma
perda do seu log de operações, por exemplo;
3. Partindo do cliente (One-way sync from client only): neste tipo de sincronização, apenas o cliente
envia suas modificações ao servidor, aquelas ocorridas apenas na base consolidada não são enviadas
ao cliente;
4. Atualização a partir do cliente (Refresh sync from client only): aqui, o cliente exporta todos os seus
dados para o servidor, que deve então substituir os dados da base alvo por eles;
5. Partindo do servidor (One-way sync from server only): o cliente recebe todas as modificações
ocorridas no servidor sem enviar as que ocorreram em sua base;
6. Atualização a partir do servidor (Refresh sync from server only): neste cenário, o servidor exporta
seus dados e exige que o cliente troque os dados da base alvo por eles;
7. Sincronização alertada pelo servidor (Server-alerted sync): aqui, o servidor informa ao cliente que
um típico específico de sincronização deve ser iniciada entre eles.
2.4.1.2 Caching e difusão de dados
Com o intuito de otimizar o tempo de resposta nas consultas realizadas no ambiente de computação
móvel e prover suporte as unidades moveis que estão desconectadas faz-se o uso do mecanismo de
caching, mas para que este mecanismo produza bons resultados é preciso que estejam previamente
definidas as estruturas de dados e as estratégias de gerenciamento do caching levando em consideração as
particularidades de cada aplicação e o padrão de acesso aos dados [2].
Quando os dados consultados não se encontram na cache, é necessária uma solicitação de dados
ao servidor. Esta solicitação pode ser total, quando o cliente precisa receber todos os dados do servidor
ou parcial, quando alguns dados na base remota podem ser utilizados para responder à consulta [34, 2].
Segundo [41], existem dois motivos para se usar difusão de dados. Primeiro, a unidade móvel evita o gasto
de energia com a transmissão de solicitação de dados. Segundo, os dados difundidos podem ser recebidos
por um grande número de unidades móveis de uma só vez, sem um custo adicional, o que é ideal para um
grupo de clientes com as mesmas necessidades de atualizações. As estratégias de envio de mensagens por
difusão se classificam em pull-based, quando o cliente faz o papel ativo, requisitando dados ao servidor e
recebendo estes dados em seguida e push-based, quando a iniciativa de transmissão de dados é do servidor
e o cliente funciona apenas como receptor.
2.4.1.3 Gerenciamento de localidade
Na computação móvel, objetos como softwares ou usuários que usam aparelhos sem fio podem se
movimentar de um local para o outro da rede. Informações sobre o atual posicionamento destes objetos
devem ser mantidas em locais específicos da rede. Este gerenciamento de localidade envolve duas operações
básicas: busca e atualização.
Uma busca é solicitada cada vez que há a necessidade de localizar um objeto, para se comunicar
com usuários móveis ou executar aplicações remotamente. A atualização da localidade armazenada de um
objeto é necessária quando este migra de um local para outro dentro da rede ou para uma outra rede.
As abordagens de armazenamento de informações sobre localidade têm suas vantagens e desvan-

tagens. A informação atualizada da exata localização da unidade móvel é mantida em cada ponto da
rede que acessa suas informações. Isto reduz o tempo de uma consulta nesta unidade móvel, pois sua
localização é imediata. A desvantagem desta abordagem é que muitas atualizações são necessárias. Já na
outra abordagem, nenhuma informação é armazenada na rede a respeito da localização da unidade móvel,
eliminando, portanto o custo de atualização desta informação. Aqui, a desvantagem é o custo da busca do
objeto que tem que ser feita globalmente na rede.
Em termos de disponibilidade, as possibilidades de projeto variam entre dois pontos: salvar

a informação da localização da unidade móvel em todos os pontos da rede e não disponibilizar esta
informação em nenhum local da rede. Há um grande número de critérios para escolher em que pontos da
rede salvar a informação, por exemplo, é interessante manter os dados sobre a localização de uma unidade
móvel nos locais da rede que acessem mais vezes sua base de dados.
A respeito da precisão da informação, ao invés de manter sua exata localização, os servidores

podem manter um conjunto de possíveis localidades do cliente, a partir do seu histórico. Há ainda a
possibilidade de se configurar uma área maior chamada localidade do cliente.
Atualidade se refere com que frequência as atualizações ocorrem a respeito da localidade do

cliente. Por exemplo, para usuários altamente móveis, pode-se abrir mão de atualização da informação
todas as vezes que eles mudam de localidade [3, 34].
2.4.1.4 Transações
Uma transação é uma unidade lógica de processamento de banco de dados que inclui uma ou
mais operações de acesso à base. Entre estas operações estão inserção, exclusão, modificação e consulta de
dados [2].
A concorrência de transações que acessam a mesma base de dados pode levar a problemas como a
perda de consistência dos dados. Portanto, transações têm que apresentar algumas propriedades desejáveis
a fim de evitar estes erros. O controle de concorrência e os métodos de recuperação de falhas devem
assegurar estas que são chamadas de propriedades ACID que são as seguintes [34]:
• Atomicidade: uma transação deve ser uma unidade atômica de processamento sendo completamente
executada ou descartada. O subsistema de recuperação de transações deve assegurar que se uma
falha ocorrer durante a execução da transação, nenhuma das modificações feitas por ela persistam;
• Consistência: a transação deve levar a base de dados de um estado consistente a outro. O estado
do banco de dados é uma coleção de todos os itens de dados armazenados num dado momento. Um
estado consistente é aquele que satisfaz as restrições impostas pelo esquema do banco de dados,
assim como outras que forem especificadas;
• Isolamento: assegurado pelo subsistema de controle de concorrência. A execução de uma transação

não deve ser interferida por outra que ocorra concorrentemente no sistema. Há diferentes níveis de
isolamento possíveis;
• Durabilidade (persistência): depois da transação completar-se com sucesso, as mudanças opera-

das por ela na base de dados persistem, até mesmo se houver falhas no sistema.
O sistema de banco de dados deve controlar a execução concorrente de transações para assegurar
que o estado do banco de dados permaneça consistente. Podem ocorrer alguns conflitos de operações
de transações que acontecem concorrentemente, por isso técnicas como serialização e agendamento de
transações se fazem necessárias para evitar conflitos
Uma transação móvel é uma transação distribuída, onde alguma parte da computação é executada
na unidade móvel e outra parte em umhostfixo. O uso do meio sem fio e a mobilidade resultante dos
consumidores e produtores de dados afetam o processamento das transações [2].
2.4.1.5 Recuperação de falhas
O processo de recuperação se refere à capacidade que um sistema tem de preservar a consistência

do banco de dados após falhas do sistema, de transações ou dos meios de comunicação. Um sistema em
um ambiente móvel está sujeito a falhas tanto de hardware como de software. Em cada um destes casos,
informações que se referem ao sistema de banco de dados podem ser perdidas. Uma parte essencial do
sistema de banco de dados é um esquema de recuperação responsável pela detecção de falhas e pela
restauração do banco de dados para um estado consistente que existia antes da ocorrência da falha.
Para que o sistema não seja prejudicado devido às falhas em seus componentes, erros devem
ser detectados o mais rápido possível, através de um diagnóstico apropriado. Para recuperar os dados,
informações relevantes são armazenadas em um local fixo durante o processamento de transações.
Os sistemas distribuídos utilizam o método de recuperação a falhas tradicional baseado em pontos

de recuperação, conhecidos como checkpoints. No caso de falhas e desconexões, a aplicação usa o último
checkpoint salvo para reiniciar sua execução[2].
2.4.1.6 Segurança
Quando inseridos no ambiente móvel os riscos de segurança de sistemas e de redes de computadores

são agravados, pois estão em um ambiente muito mais propenso a ataques e falhas [3]. Na computação
móvel, a portabilidade dos dispositivos usados pode levar à perda das unidades, o que caracteriza perda
de dados e de confidencialidade.
A única forma de prevenir a falta de confiabilidade é o uso de encriptação (encryption, fase da

criptografia) e de mecanismos que assegurem identificação, autenticação e controle de acesso. Estas não
são características particulares de segurança num ambiente móvel, a não ser pelo fato de que a proteção de
um dispositivo móvel deve ser simplificada, devido à escassez de recursos e pouco poder de processamento
destes computadores [3].
2.4.2 SQLite Database

A plataforma Android oferece suporte completo à biblioteca para criação e acesso a banco de
dados SQLite, que é um Banco de Dados relacional e open-source conhecido pelo uso em aplicações
populares, como o Mozilla Firefox. O Android fornece a possibilidade de acesso a um banco de dados
relacional para cada aplicação via o SQLite, o armazenamento é seguro e eficiente, uma vez que somente a
aplicação que criou o banco de dados possui acesso às suas informações [12].
A biblioteca SQLite é um gerenciador de banco de dados baseado em SQL (Structured Query

Language) que não depende de uma estrutura cliente-servidor, ou seja, é um gerenciador auto-suficiente
que necessita de pouco apoio de bibliotecas externas e até mesmo do sistema operacional, dispensando
configurações adicionais. Em função desta característica a adaptação do SQLite para uso em sistemas
embarcados se torna muito fácil, fazendo com que este seja multiplataforma. O amplo suporte oferecido
pela plataforma Android ao SQLite e o suporte à linguagem SQL reforça a sua facilidade de utilização
[51, 12, 52].
O SQLite armazena tudo que é preciso em um único arquivo, nele está contido toda a estrutura
do banco de dados e os dados nele armazenados indiferentemente do número de tabelas e índices utilizados.
É considerado um gerenciador de banco de dados leve, mas isto não está relacionado à sua capacidade de
armazenamento de dados e sim a questões de complexidade de instalação e administração de recursos. É
independente de servidor, ou seja, os arquivos são acessados diretamente de sua biblioteca, sem necessidades
de configurações extras, necessita de pouco menos de 4MB de memória para seu funcionamento, realizando
o mínimo de configuração (eliminando recursos avançados) pode ser alcançado um funcionamento com
menos de 256KB de memória [12, 49].
A Figura 13 representa a arquitetura da biblioteca SQLite, independente de servidor, ou seja, o

acesso de leitura e escrita é feito diretamente da biblioteca ao arquivo de dados, sem a intervenção de um
servidor de banco de dados [12].
Figura 13 – Acesso da Biblioteca SQLite ao arquivo de banco de dados [12].
A criação e exclusão de tabelas no SQLite são feitas através dos comandos CREATE TABLE
e DROP TABLET da linguagem SQL. Os dados das tabelas são manipulados através dos conhecidos
comandos DML (INSERT, UPDATE e DELETE) e são consultados através do uso do comando SELECT.
O SQLite fornece todo o serviço de persistência de dados [49, 51].
2.5 Identificação por radiofrequência (RFID)
Nos dias atuais é muito frequente a necessidade de sistemas de identificação. O código de barras
que é uma representação gráfica de dados numéricos ou alfanuméricos, pode ser considerado o sistema de
identificação de maior utilização pois é facilmente identificado em uma ampla gama de aplicações tais
como títulos bancários, identificação de produtos e objetos, crachás de identificação, etc.
Devido a limitada quantidade de informações que o código de barras pode carregar, surgiu o QR
Code que nada mais é que a evolução do código de barras em uma representação bidimensional, permitindo
o carregamento de uma quantidade maior de informações.
Ambas as tecnologias citadas até o momento (Código de barras e QR Code) a identificação só é

possível se existir uma superfície impressa que contenha o código de barras ou QR Code para que ocorra
a leitura.
Com a utilização do RFID (Radio Frequency Identification) a leitura pode ocorrer com os produtos
dentro de suas próprias embalagens com etiquetas afixadas aos itens, dispensando a necessidade de ter o
contato visual com o código impresso pois essa identificação é realizada por uso de rádio frequência.
Desde o início da década de 80 a tecnologia de identificação por rádio frequência (RFID) tem
sido testada como meio de identificação alternativo ao uso de códigos de barras e QR Code em virtude de
sua praticidade em dispensar o contato visual e permitir a identificação simultânea de múltiplos objetos.
Enquanto o uso do código de barras e QR Code em virtude de estar impresso permite alterações do
dado que ele carrega apenas por intermédio de modificações no banco de dados de informações associadas
àquele código, a tecnologia RFID permite além da leitura a gravação de novos dados na etiqueta RFID
possibilitando o mantenimento histórico de determinado item, recurso largamente utilizado na cadeia de
logística e armazenamento de produtos [53].
2.5.1 Componentes de um sistema RFID

No geral os sistemas de RFID são compostos por pelo menos quatro itens básicos: etiqueta
eletrônica, antenas, leitor ou transceiver e controlador. Cada um desses itens básicos serão abordados nos
próximos tópico.
2.5.1.1 Etiqueta eletrônica (Tag )
A etiqueta eletrônica em sua grande maioria contém dados sobre um objeto. Tem por função
transmitir e responder aos comandos que são recebidos por radiofrequência. Sua estrutura básica é: um
chip que armazena informações e uma resistência fazendo o papel de antena, envolvidos por algum material
como plástico ou silicone [54]. Na Figura 14 é possivel ver uma Tag RFID e suas camadas. Estas etiquetas
costumam ser classificadas em três tipos:
• Tags Passivas: Não necessitam de alimentação interna. Sua energia vem do próprio sistema de
leitura, através de indução magnética ou campo eletromagnético. Seu alcance típico dificilmente
ultrapassa os 5 metros. São as mais comuns e amplamente utilizadas por um simples motivo: o custo.
As ondas eletromagnéticas geradas pelo dispositivo leitor são transmitidas através de uma antena do
tipo dipolo até a antena instalada na etiqueta, que também é uma antena do tipo dipolo. A antena
da etiqueta recebe o sinal e o transforma em uma diferença de potencial. Como o sinal recebido é
uma corrente alternada e os circuitos internos necessitam de uma corrente contínua, um circuito
retificador de onda completa é utilizado para obtenção de uma tensão contínua que irá carregar os
capacitores que servirão de baterias para a alimentação da etiqueta. O mesmo canal de recepção é
utilizado também para transmitir os dados armazenados na etiqueta para o dispositivo leitor através
de um processo de modulação [54, 55].
Figura 14 – Tag RFID e suas camadas [13].
• Tags Semi-passivas: Têm uma fonte de alimentação interna (bateria), apenas para a recepção
de dados. Isso permite que sejam lidas sem a energia do leitor externo, fazendo-as serem capazes de
trabalhar em ambientes com potência muito baixa de campo magnético. Isto reduz a quantidade de
energia necessária para o sistema funcionar e também as interferências externas ao sistema. Como
tem uma bateria interna, seu alcance pode chegar a 100 m. São mais caras se comparadas com as
passivas, porém garantem distância maior de operação. É comumente utilizada para controle de
acesso devido ao baixo custo e à fácil adaptação em cartões feitos de materiais plásticos e de vidro
[54, 55].
• Tags Ativas: Também conhecidas por etiquetas de duas vias. Esse tipo de etiqueta possui uma
fonte de energia interna (bateria) e um transmissor. Alcance pode chegar a alguns quilômetros.
São muito caras para produção em grande escala e utilizadas em sistemas específicos geralmente
em produtos de alto valor monetário, como por exemplo, caminhões e automóveis. Essas etiquetas
operam em uma faixa de frequência que varia entre 850 MHz e 5,8 GHz. Portanto, as etiquetas ativas
são sistemas de radio completos com bateria, receptor, transmissor e circuito de controle [54, 55].
2.5.1.2 Antenas
As antenas são a base para a comunicação sem fio. Baseadas em transceptores, esses dispositivos
são utilizados tanto para irradiar quanto para receber ondas de rádio, dessa forma, é de sua responsabilidade
a transformação da energia irradiada e energia guiada em um meio de transmissão. A radiação de ondas
eletromagnéticas ocorre em todos os condutores sujeitos a uma diferença de potencial e/ou corrente
elétrica variante no tempo. Uma antena é um componente que é projetado para operar em uma faixa
de frequência especifica baseada nas especificações do projeto. Existem vários tipos de antena e muitas
variações, isto ocorre devido ao fato de cada aplicação geralmente modificar algumas características para
melhor se adaptar a um sistema específico [54].
2.5.1.3 Leitor ou Transceiver
Os Leitores são componentes que se comunicam com as etiquetas através de uma antena pela
emissão de sinais de radiofreqüência. Em outras palavras, são transceptores – transmissores e receptores em
um único dispositivo. Esses sinais ativam a etiqueta que se comporta como um transponder – dispositivo
que recebe um sinal com uma determinada frequência e retransmite, podendo esse sinal retransmitido
possuir uma frequência diferente da recebida – permitindo a comunicação com o dispositivo leitor, que
repassará os dados do produto para um middleware que nada mais é que um software responsável por
pegar informações vindas do leitor ou do gerenciador de eventos e transferi-las para um sistema gerenciador
de produtos ou um software de controle de estoques ou vendas por exemplo [54, 55].
Exitem dois tipos de leitores, os de “leitura” e os de “leitura/escrita”. Os leitores que são capazes
de apenas realizar a leitura são utilizados com etiquetas passivas, que apenas enviam os dados, já os
leitores que realizam tanto a leitura quanto a escrita são utilizados com etiquetas ativas, que enviam e
recebem os dados. O leitor RFID opera em frequências padronizadas que variam de 125 KHz a 2.4 GHz
[54].
2.5.1.4 Controlador
O controlador (middleware) é o componente responsável pelo gerenciamento e implementação das

informações obtidas através do leitor, permitindo que o leitor seja controlado por um agente externo. O
controlador pode estar integrado ao leitor, geralmente chamado de firmware, ou em um microcomputador
com sistema servidor[54, 55].
2.5.2 Funcionamento do sistema RFID

A integração de uma série de componentes permite o funcionamento do sistema de RFID provendo
a identificação e o gerenciamento de objetos. Através da Figura 15 é explicado de forma simplificada o
funcionamento de um sistema RFID [14].
Figura 15 – Funcionamento do Sistema RFID [14].
As informações sobre a identificação de um objeto (incluindo outras possíveis informações passíveis

de monitoramento por sensores, tais como temperatura, pressão etc.) são gravadas nas etiquetas RFID (1).
Essas etiquetas são anexadas em itens (caixas, pallets, containers, veículos, pessoas, ativos ou máquinas)
que se movimentam ou estão dispostos ao longo da cadeia de suprimentos. As informações contidas nas
etiquetas são lidas por um conjunto de sensores (antenas (2) e leitores (3)) por meio de rádio frequência.
Os sensores geralmente estão distribuídos em diferentes estágios e várias posições na cadeia de suprimentos
(docas de recebimento, docas de expedição e pontos de controle em centros de distribuição e armazéns;
pontos de controle em processos de fabricação e linhas de montagem; pontos de controle em rodovias,
ferrovias, portarias, operações de pesagem etc.).
Essa combinação de informação relacionada às identificações, itens, localidades e mensurações

ao longo do tempo, gera um nível de complexidade informacional que necessita gerenciamento específico.
O gerenciamento do grande volume de informações distribuídas ao longo da cadeia de suprimentos é
realizado por meio de um conjunto de sistemas conhecidos como “RFID middleware” (4). Esse componente
gerencia o fluxo de informações entre os diferentes componentes de hardware de RFID (antenas, leitores,
sensores, impressoras de RFID), identifica os eventos associados a essas informações (por exemplo, um
pallet que passou por uma doca de recebimento pode disparar uma atividade de atualização de estoques)
e realiza a integração com os sistemas gerenciais da empresa (5). Esse fluxo de informação é bidirecional,
ou seja, ele ocorre dos sistemas gerenciais para as etiquetas (fluxo de gravação) e dessas para os sistemas
gerenciais (fluxo de leitura). Isso possibilita uma integração entre as informações eletrônicas e os sistemas
gerenciais. Dessa forma, esse conjunto de sistemas possibilita a gestão do fluxo de informações dos objetos
distribuídos ao longo da cadeia de suprimentos, o gerenciamento dos eventos relacionados a esses objetos
e a atualização das informações relevantes nos sistemas gerenciais [14].
2.5.3 Frequências operacionais

A frequência de operação de um leitor ao realizar conexão com etiquetas é um fator importante
podendo variar de acordo com as normas e regulamentos estabelecidos para o uso da tecnologia RFID.
Em geral, a frequência define a taxa de transferência de dados entre a etiqueta e o leitor. Quanto menor a
frequência, mais lenta a taxa de transferência. Todavia, a velocidade não é o único aspecto a ser analisado
no planejamento de uma solução de RFID. As condições ambientais podem desempenhar um papel
significativo na determinação da frequência de operação ideal para uma aplicação em particular [54].
Em sua grande maioria os sistemas de RFID estão delimitados em três faixas de frequências de
operação acordo com [54, 55], sendo elas:
• LF (Low Frequency ): Faixa de operação de 125 kHz até 134 kHz. São denominados sistemas de
baixa frequência. Nesta faixa são encontrados os sistemas RFID mais antigos e estáveis do mercado.
As principais caracteristicas dos sistemas que operam nesta faixa de frequência são:
a) Baixa taxa de transferência de dados (leva até 100 ms para a leitura de um tag de 16
caracteres);
b) Leitura de apenas uma tag por vez;
c) Só existe com sistema de alimentação passivo;
d) Pequenas distâncias de leitura (máximo de 30 cm);
e) Não sofre absorção pelos líquidos;
f) Baixo desempenho próximo a metais;
g) Leitores de baixo custo e tags de alto custo;
h) Tags de tamanho elevado;
i) Aplicações: Identificação de gado, controle de acesso, identificação de atletas.
• HF (High Frequency ): Faixa de operação de 13,56 MHz. São denominados sistemas de alta
frequência. Os sistemas de HF são sistemas já estáveis que estão no mercado a mais de vinte anos. A
faixa de frequência de 13,56 MHz é conhecida como banda ISM (Industrial, Scientific, Medical ) sendo
que é uma faixa de frequência que não necessita de licença para operar. As principais características
dos sistemas que operam nesta faixa de frequência são:
a) Boa taxa de transferência de dados (leva até 20 ms para a leitura de um tag de 16

caracteres);
b) Leitura de múltiplos tags por vez (40 tags por segundo);

c) Só existe com sistema de alimentação passivo;
d) Médias distâncias de leitura (máximo de 1 metro);
e) Não sofre absorção pelos líquidos;
f) Baixo desempenho próximo a metais;
g) Leitores de alto custo e tags com custo médio;
h) Tags de várias dimensões;
i) Tags com várias funcionalidades de memória (password, criptografia);
j) Possui padrões estabelecidos como o ISO 15636 e Electronic Product Code (EPC) que é
um identificador universal que dá uma identidade única a um objeto físico específico;
k) Aplicações: Controle de acesso, identificação de itens, chaves de ignição de veículos,
controle de alimentos e identificação de pacientes.
• UHF (Ultra Frequency ): Faixa de operação de 860 MHz até 960 MHz. São denominados sistemas
de UHF. São os sistemas de RFID UHF que estão gerando a maior expectativa e motivação para
as implantações de RFID. Esta faixa de frequência também é classificada como banda ISM. Além
disso, as características eletromagnéticas desta faixa de frequência contribuem para a implantação de
RFID para toda a cadeia logística e outras aplicações. As principais características destes sistemas
são:
a) Distância de leitura de até 10 metros (para tags passivos) e 100 metros (para tags ativos);
b) Protocolo de anti-colisão, até 1000 tags/segundo;
c) Absorção da energia pelos líquidos;
d) Acoplamento Reflexivo;
e) Alta taxa de transferência de dados;
f) Bom desempenho perto do metal;
g) Tags de menor tamanho;
h) Utilizado para: Controle da cadeia logística, controle de falsificação;
i) Identificação de veículos, Identificação de ferramentas, Padrão mundial EPC.
2.5.4 Tipos de memória

De acordo com a aplicação que esta sendo desenvolvida é realizada a escolha do tipo de etiqueta
a ser utilizada e consequentemente o tipo de memória desta etiqueta. É possível encontrar no mercado
diversos modelos de etiquetas mas cada um é capaz de armazenar uma determinada quantidade de dados
em sua memória variando conforme o tipo de chip utilizado em sua fabricação. Em geral a quantidade de
memória disponível em tags de leitura, podem variar de 42 a 128 bits de informação, enquanto que as
tags de leitura/escrita podem variar de 64 a 32.768 bytes, logo, em tags do tipo leitura/escrita podem ser
armazenadas muitas páginas de texto digitado em sua memória [56]. Podem ser encontradas no mercado
etiquetas com as seguintes características [55]:
• Somente Leitura: Os dados gravados apenas na hora da fabricação da etiqueta tornam a etiqueta
à prova de adulteração (característica nativa das etiquetas sem chips);
• Uma Gravação/Várias Leituras: A capacidade de gravar os dados apenas uma vez torna a
etiqueta à prova de adulteração, mas oferece a flexibilidade de gravação dos dados depois da
fabricação da etiqueta, o que pode reduzir significativamente os custos de produção;
• Leitura/Gravação: A mais flexível. Vulnerável a adulteração e sobreposição de dados.

2.6 Near Field Communication (NFC)
NFC (Near Field Communication) é um padrão de comunicação sem fio de curtíssimo alcance
lançado em 2004 pela Sony, Philips e Nokia. Desenvolvido para fazer uma comunicação simples e intuitiva
entre dois equipamentos eletrônicos. Ela é capaz de transferir energia entre dispositivos, habilitando a
implementação semi-passiva sem qualquer tipo de energia. Entretanto, isso exige da tecnologia do NFC
que suporte uma operação com índices nulos de operação gerando uma espera de ativação do dispositivo
NFC e um gerenciamento de energia durante a comunicação. Em 2005, o NFC IP-2 foi estabelecido como
uma ISO/IEC padrão internacional 21481 [57].
Permitindo a comunicação entre dois dispositivos, não mais que isso, a tecnologia NFC faz uso
da indução magnética para estabelecer o seu funcionamento, respeitando uma distancia máxima de
10 centímetros entre os dois dispositivos. Um dispositivo emite uma pequena corrente elétrica de sua
antena fazendo o papel de iniciador e ficando sob sua responsabilidade a inicialização da comunicação e o
controle da troca de informações, a corrente elétrica emitida através da antena do iniciador cria um campo
magnético que ocupa o espaço entre o iniciador e o outro dispositivo que assume o papel de alvo ( Target)
responsável por responder às solicitações enviadas pelo iniciador, logo, esse campo é recebido por uma
bobina existente na antena do dispositivo, onde novamente é convertido em sinais elétricos possibilitando
dessa forma a comunicação e troca de dados entre os dispositivos [15, 58]. Este cenário é ilustrado na
Figura 16.
Figura 16 – Funcionamento do NFC (adaptada de [15]).
A velocidade de transmissão em uma comunicação NFC pode variar entre 106, 212 e 424 Kb/s
(kilobits por segundo) e pode ocorrer de dois modos, sendo eles o passivo onde apenas um dos dispositivos
gera o sinal elétrico da conexão, normalmente este dispositivo é o iniciador, e o modo ativo onde ambos
os dispositivos podem gerar o sinal elétrico, a exemplo um sistema de pagamento que faz o uso de um
smartphone e um receptor no terminal de recebimento do estabelecimento.
Considerada uma subdivisão do RFID, esta tecnologia visa melhorar a transmissão de dados
ponto a ponto. Sendo a combinação de duas tecnologias complementares. Onde a tecnologia do RFID
possibilita que um dispositivo identifique o outro e a transmissão de dados sem fio permite que, depois de
identificados, os dispositivos se comuniquem e troquem dados [57].
É uma tecnologia extremamente simples de usar, e que permite troca de dados entre dois
dispositivos eletrônicos, num curto espaço físico, da ordem de poucos centímetros. Em virtude de sua
simplicidade o NFC dispensa a necessidade de uma série de elementos que compõem o sistema RFID para
o seu funcionamento [19].
O NFC permite sua utilização em três modos de operação possíveis e diferentes entre si, sendo
eles [57, 15]:
• Escrita e leitura: Neste modo o dispositivo móvel que possui a tecnologia NFC pode realizar
a leitura de informações que estão inseridas em etiquetas com tecnologia RFID ou NFC, desde
que estas etiquetas tenham sido construídas para tal finalidade. O usuário pode ainda através do
dispositivo móvel, realizar a gravação de dados nas etiquetas. Caso a etiqueta esteja gravada com
informações tais como código de produto, descrição, validade, etc. as informações nela contidas
serão lidas e disponibilizadas a aplicativos instalados no dispositivo móvel. A Figura 17 ilustra a
possibilidade de gravar ou executar ações de uma etiqueta NFC afixada no painel de um veículo.
Figura 17 – Gravando ações para um aplicativo do smartphone em uma Tag NFC [16].
• Emulação de cartão: Desta forma o dispositivo móvel atua como um cartão inteligente (Smart
Card contactless) permitindo que o dispositivo móvel seja utilizado para efetuar pagamentos, liberar
catracas de acesso, substituindo a utilização de um cartão de crédito ou débito convencional e até
mesmo os crachás de identificação. A Figura 18 ilustra a utilização de um dispositivo neste modo de
operação para a realização de pagamentos.
Figura 18 – Efetuando pagamentos com o Smartphone através da tecnologia NFC [17].
• Ponto a ponto (Peer-to-Peer ): Neste modo é possível estabelecer uma ponte de comunicação
de dados entre um dispositivo móvel e outro dispositivo eletrônico qualquer que possua a tecnologia
NFC, os dois dispositivos com NFC ativos conversam entre si e realizam a troca de informações. É
possível neste modo, fazer com que dados de uma conexão Wifi seja compartilhado, um dispositivo
móvel seja pareado a uma caixa de som Bluethoot e a troca de dados como cartões de visita ou
fotografias digitais assim como ilustra a Figura 19.
Através da Figura 20 são comparadas as tecnologias sem fio. É possível perceber que o NFC tem
baixo alcance e baixa taxa de transmissão de dados comparado as demais tecnologias [19].
Figura 19 – Troca de arquivos através do NFC, bastando encostar os dispositivos na tampa traseira [18].
Figura 20 – Vários padrões de comunicação sem fio que coexistem atualmente [19].
2.6.1 Etiquetas NFC

Conhecidas como NFC Sticker, SmartTag NFC, Adesivos NFC ou etiquetas NFC, as etiquetas
NFC exitem nos mais variados e diversos formatos podendo ser configuradas para a realização de diversas
atividades [58].
Basicamente as Tags NFC são formadas por um pequeno chip de rádio, uma antena simples e
alguma quantidade de memória utilizada para armazenamento de dados. Estes dispositivos normalmente
operam em modo passivo, dispensando a necessidade de ligação constante com uma fonte de energia.
Ainda que estas Tags possam ser encontradas nas mais diversas formas, ilustradas na Figura 21, tais
como: anel, pulseira, chaveiro, etiqueta adesiva, brinco animal e etc. existem ao menos quatro categorias
de Tags NFC que permitem ser configuradas como somente leitura, onde as informações são gravadas na
fábrica, ou configuradas com permissão 7p.ara reescrita de dados, possibilitando a reutilização dessa Tag
em outra aplicação. Os tipos normalmente encontrados são [58]:
• Tipo 1: normalmente armazena entre 96 bytes e 2 KB de dados e tem velocidade de 106 Kb/s
(kilobits por segundo);
• Tipo 2: armazena entre 48 bytes e 2 KB de dados e tem velocidade de 106 Kb/s. É compatível com
o tipo 1;
• Tipo 3: baseada em uma tecnologia da Sony chamada FeliCa, esse tipo normalmente armazena
2 KB (mas pode chegar a 1 MB) e tem velocidade de 212 Kb/s. A compatibilidade com outros
padrões existe, mas não é garantida;
Figura 21 – Modelos diversos de Tags NFC. Imagens da internet, autor desconhecido.
• Tipo 4: armazena até 32 KB e tem velocidade entre 106 Kb/s e 424 Kb/s. É compatível com os
tipos 1 e 2.
2.7 Metodologias ágeis
As abordagens tradicionais de desenvolvimento de software geralmente são orientadas a pla-

nejamento e aplicadas em situações onde os requisitos do sistema são estáveis com a possibilidade de
previsão dos requisitos futuros do sistema. Dessa forma, as abordagens tradicionais não contemplavam as
necessidades existentes em projetos que ocorrem muitas mudanças, onde os requisitos são passiveis de
alterações, onde refazer partes do código não é uma atividade que apresenta alto custo, as equipes são
pequenas, as datas de entrega do software são curtas e o desenvolvimento rápido é fundamental, logo,
essa inconformidade fez com que surgisse a necessidade de metodologias alternativas conhecidas como
Metodologias Ágeis [59].
Em 2001 dezessete especialistas em processos de desenvolvimento de software se reuniram e

estabeleceram princípios comuns aos métodos de desenvolvimentos Extreme Programming (XP), Scrum,
dentre outros. A partir desta reunião foi criada a Aliança Ágil que deu origem a um documento chamado
Manifesto Ágil que se baseia em valores como [59, 60]:
a) Indivíduos e interações são mais importantes do que processos e ferramentas;

b) Softwares em funcionamento são mais importantes do que documentação abrangente, que por
muitas vezes consome muito tempo;
c) Foco no cliente, pois considera que a colaboração com o mesmo é mais importante do que a
negociação de contratos;
d) Adaptação a mudanças é mais importante do que seguir o plano inicial, tendo em vista as
mudanças que ocorrem durante o processo de desenvolvimento.
As metodologias ágeis geralmente não trazem nada de novo, apenas diferem das metodologias
tradicionais através do enfoque e dos valores, onde o enfoque das metodologias ágeis concentram-se
nas pessoas e não em processos ou algoritmos, além da preocupação de despender mais tempo com a
implementação e menos tempo com a documentação [59].
As metodologias ágeis são capazes de se adaptarem a novos fatores que venham a surgir em
decorrência do desenvolvimento do projeto, dispensando uma análise prévia de tudo o que pode acontecer
no decorrer do desenvolvimento. Essa análise prévia é difícil e apresenta alto custo, além de tornar-se um
problema caso não se queira fazer alterações nos planejamentos, logo, uma característica das metodologias
ágeis é que elas são adaptativas ao invés de serem preditivas conforme as metodologias tradicionais [59].
2.7.1 Extreme Programming

O Extreme Programming habitualmente chamado apenas de XP é um dos métodos mais conhecidos
e utilizado. Baseado no desenvolvimento iterativo, com expressiva participação do cliente, que define um
grupo de funções chamadas de história de usuário [60].
Uma série de caracteristicas que refletem os princípios dos métodos ágeis são identificadas na
metodologia XP conforme aponta [60]:
• Planejamento incremental: O desenvolvimento é divido em liberações, cada liberação possui um

conjunto de iterações;
• Pequenos releases: Desenvolvimento de pequenas versões de software, fornecendo valor ao negócio;
• Projeto simples: Cada projeto deve atender somente as necessidades atuais;
• Desenvolvimento de testes antes do código: É mais fácil implementar código após conhecer os testes
que serão impostos;
• Refatoração do código: Os desenvolvedores devem modificar o código sempre que possível, visando
facilitar sua manutenção futura;
• Programação em pares: Os desenvolvedores trabalham em duplas em um mesmo computador,

melhorando a qualidade do código e diminuindo erros;
• Propriedade coletiva: Todos os desenvolvedores trabalham em todas as áreas do sistema, podendo

alterar qualquer parte do código, desde que atenda os testes;
• Integração contínua: Após a conclusão de uma tarefa, todo o código é reintegrado em um repositório,
sendo novamente testado;
• Ritmo sustentável de trabalho: Para melhor qualidade de código, os desenvolvedores devem estar
motivados a completarem a iteração planejada;
• Cliente no local em tempo integral: Um representante do cliente fica disponível no local, como parte
da equipe.
Sua utilização não é recomendada em projetos de desenvolvimento de softwares complexos, de

grande porte ou críticos, ficando sua indicação limitada a pequenos projetos e tipicamente para ambientes
Web [60].
2.7.2 Scrum
O Scrum é um processo ágil ou ainda um conjunto de boas práticas utilizadas para o gerenciamento
de projetos ágeis. É largamente utilizado no processo de desenvolvimento de software, porém não se limita
apenas a esse tipo de aplicação, o Scrum pode ser utilizado no desenvolvimento de outros produtos e
gerenciamento de qualquer outro trabalho [59, 20].
É um framework iterativo e incremental para desenvolvimento de produtos e gerenciamento de

trabalhos diversos. A entrega de funcionalidades com alto valor de negócio para o cliente é o seu principal
objetivo [59].
Uma das características do Scrum é que ele além de ser um processo ágil para o gerenciamento
e controle de projetos que envolve práticas de engenharia, aborda o desenvolvimento de produtos e
sistemas onde as alterações e mudanças de requisitos são contantes, visa a comunicação otimizada do time
favorecendo a cooperação, é escalável para pequenos projetos e corporações de maior porte, bem como
para para projetos longos, largos e distribuídos [59].
A organização do desenvolvimento do software e a iteração entre o cliente e a equipe de desen-

volvimento se dá através de componentes que o Scrum possui para essa finalidade que são eles: Sprints,
Product Backlog e Sprint Backlog [20, 60].
• Sprints: O Sprint é o ciclo de desenvolvimento do Scrum, caracterizado por ter um curto período
onde a equipe foca na entrega de uma meta específica;
• Product Backlog ou Backlog do Produto: Requisitos de produtos organizados em uma lista

de itens.
• Sprint Backlog : O Sprint Backlog é gerado a partir das histórias retiradas do Product Backlog e
que serão implementadas durante o Sprint.
2.7.2.1 Papéis do Scrum
Visando aperfeiçoar a flexibilidade, criatividade e a produtividade o modelo de equipe proposto

pelo Scrum contém três papeis principais que são os responsáveis pela divisão das responsabilidades: o
Scrum Master, o Product Owner, e o Team [20, 60].
• Scrum Master : é o gerente do projeto, sua função é ser o facilitador do processo e ajudar as
pessoas a resolver os problemas;
• Scrum Team: é o time do projeto com no máximo 10 a 15 participantes e deve ser multidisciplinar
e auto organizado;
• Product Owner : é o cliente de um time Scrum, ele é responsável pelo retorno do investimento de
um produto.
2.7.2.2 Ciclo do Scrum
O progresso de desenvolvimento adotado pelo Scrum é baseado em iterações com durações que
podem variar entre duas e seis semanas, essas iterações são chamadas Sprints. A reunião de planejamento
(Sprint Planning) é a primeira etapa dentro do Sprint. Nesta reunião o time (Scrum Team), em conjunto
com o cliente (Product Owner ) define o que será implementado na iteração, onde a priorização do trabalho
a ser feito fica sob responsabilidade do cliente [20].
Outra etapa é a execução. O time realiza o detalhamento das tarefas necessárias para a implemen-
tação do que foi solicitado pelo cliente e logo em seguida inicia a execução das tarefas definidas. Reuniões
diárias (Daily Meeting) com duração de 15 minutos são realizadas durante o Sprint para verificação e
acompanhamento do progresso do desenvolvimento. Este acompanhamento ocorre através da utilização do
Burn Down Chart, que é um gráfico utilizado para o registro das tarefas a realizar, em andamento e já
concluídas [20].
Ao fim do Sprint, uma reunião para validação da entrega (Sprint Review ) é realizada, nesta reunião
as partes interessadas no produto podem verificar se o objetivo proposto para o Sprint foi alcançado.
Imediatamente após esta reunião é realizada uma nova reunião (Sprint Retrospective) composta apenas
pelo time, com o propósito de avaliar o Sprint sob a perspectiva de processo, time ou produto, quais
foram os acertos e os erros objetivando a melhora do processo de trabalho [20].
O Ciclo do Scrum é representado na Figura 22.
Figura 22 – Ciclo do Scrum [20].
2.7.2.3 Etapas do Sprint
O Sprint é definido como um ciclo de desenvolvimento curto em que o time foca em atingir o
objetivo proposto pelo Product Owner. Durante a execução de um ciclo o time deverá ter plena competência
para o gerenciamento da execução deste, sem que haja interferências externas sejam elas de clientes ou
outras pessoas [20].
Sprint Planning : é a primeira atividade dentro do Sprint, uma reunião, durante essa reunião é
feita uma seleção das histórias que serão implementadas durante aquele ciclo.
Daily Scrum: é uma reunião rápida que deve ter o tempo fechado, realizada todo dia, reuniões
em pé no qual os membros do time explicam entre si o que foi feito desde a última Daily Scrum.
Sprint Review : acontece no final de cada Sprint, durante esta reunião o time mostra o resultado
do seu trabalho para o Product Owner e para outros clientes.
Sprint Retrospective: é a reunião do time realizada sempre ao final de cada Sprint e deve ser
utilizada para a correção dos problemas detectados pelo time no processo de desenvolvimento.
51
3 SMRA - SISTEMA DE MANEJO E RASTREABILI-

DADE ANIMAL
3.1 Metodologia
O sistema proposto neste trabalho é uma aplicação que permite aos produtores cadastrar os
animais de sua propriedade, coletar dados produzidos ao longo do desenvolvimento das diversas atividades
envolvidas no manejo animal e facilmente gravar e recuperar as informações contidas no sistema com o
simples aproximar de seus dispositivos móveis que possuam a tecnologia NFC a Tags que identificam seus
animais e até mesmo a realização de atividades. Com esse aplicativo os produtores terão maior controle e
melhor gestão de propriedades melhorando os ganhos com um investimento de baixo custo.
Manejo é um termo amplo que diz respeito a todas as atividades diariamente desenvolvidas com
os animais. Mais do que assegurar a sanidade dos animais, a preocupação com bem-estar visa reduzir
situações de dor ou injustiça na vida do animal, e ainda garantir que ele possa expressar comportamentos
naturais. De acordo com os padrões internacionais ISSO 8402, rastreabilidade é definida como a habilidade
de descrever a história, aplicação, processos ou eventos e localização, de um produto, a uma determinada
organização, através de registros e identificação. Em outras palavras, rastrear é manter os registros
necessários para identificar a informar os dados relativos à origem e ao destino de um produto. Esse
sistema de controle registra todas as ocorrências relevantes ao longo da vida do animal, desde o seu
nascimento até o abate [61, 62, 63].
Este capítulo descreve os passos na ordem em que foram realizados e apresenta o processo de
desenvolvimento escolhido.
Inicialmente foi identificado que a gestão de uma propriedade rural por parte dos pequenos e
médios produtores tem um grau elevado de complexidade, uma vez que estes produtores não contam com
sistemas que permitam essa gestão a baixo custo, logo, foi discutido a necessidade de um sistema que
resolvesse essa questão apresentada.
Após discutido os problemas existentes e as possíveis soluções, foi realizado o levantamentos

dos aplicativos já existentes e um comparativo de funcionalidades que poderiam atender as necessidades
apresentadas, os resultados obtidos com este levantamento serão apresentados logo mais à frente . De
posse dos requisitos e levando em consideração as críticas obtidas das ferramentas semelhantes, a proposta
do sistema foi descrita em termos das funcionalidades necessárias para cumpri-los.
A coleta de requisitos foi realizada por meio de diálogos com pequenos produtores e logo após
a coleta de requisitos foi feito uma comparação dos requisitos com as funcionalidades dos aplicativos
existentes, e a partir da análise dessas funcionalidades e os requisitos coletados foram descritas as
funcionalidades que seriam necessárias para cumprir com os requisitos levantados.
Após coletados os requisitos e realizado a descrição das funcionalidades foi dado inicio ao passo de
desenvolvimento aplicando conceitos da metodologia Scrum visando o desenvolvimento ágil da aplicação.
Com as tarefas e exigências necessárias para a construção da aplicação listadas, foram definidas e iniciadas
as Sprints sendo que ao termino de cada Sprint era realizada uma reunião com a finalidade de discutir
melhorias, testar as funcionalidades implementadas e verificar a conformidade do desenvolvimento com os
requisitos listados.
Capítulo 3. SMRA - Sistema de Manejo e Rastreabilidade Animal 52
3.2 Requisitos
Nesta sessão são apresentados os requisitos funcionais e não funcionais do sistema, brevemente
descritos e seus relacionamentos.
3.2.1 Requisitos funcionais
Requisitos relacio-
Identificação Descrição
nados
O sistema deve permitir o cadastramento e manuten-
RF01 ção de Espécies. Exemplo: Bovinos, Bubalinos, Equinos,
Caprinos, Ovinos, Suínos, Caninos e etc.
O sistema deve permitir o cadastramento e manutenção
RF02 de Raças. Exemplo: Nelore, Angus, Jersey, Charolês e RF01
etc.
RF03 de Categorias de animais. Exemplo: Leite, Reprodutor,
Engorda, Genética e etc.
O sistema deve permitir o cadastramento e manutenção de
RF04
Locais. Exemplo: Pasto, Curral, Confinamento, Balança
RF05
de Proprietários.
O sistema deve permitir o cadastramento e manutenção RF02, RF03, RF04,
RF06
de Animais. RF05, RF01
O sistema deve permitir o cadastramento e manutenção de
RF07 Eventos. Exemplo: Lactação, Pesagem, Toque, Cirurgia,
Vacinação, Inseminação e etc.
RF08 de eventos bloqueados. Exemplo: Carência para Lactação RF07
de x dias após eventos que utilizem “Antibióticos”
RF09 de Eventos obrigatórios. Exemplo: Durante x dias fazer RF07
Curativos em animais que sofreram Cirurgia.
O sistema deve permitir o cadastramento e manutenção RF04, RF07, RF06,
RF10
de Manejos. RF08, RF09
O sistema deve permitir procurar um animal utilizando
RF11 RF06
Tags RFID.
Tabela 1 – Requisitos funcionais do SMRA.
3.2.2 Requisitos não funcionais
Requisitos relacio-
Identificação Descrição
nados
O sistema deve ser desenvolvido para Android, de versão
RNF01
igual ou superior a 5.1
RNF02 O Sistema deve ser desenvolvido na linguagem JAVA.
O sistema deve ter uma interface de fácil utilização. Pa-
RNF03
dronizada em todos os cadastros.
O sistema deve exporta dados em XML para que possa
RNF04
ser transmitidos a outros dispositivos.
RNF05 O Sistema deve utilizar Banco de Dados SQlite.
RNF06 O Sistema deve ler Tags Rfid utilizando a tecnologia NFC
RNF07 O Sistema deve permitir enviar XML via Email.
Tabela 2 – Requisitos não funcionais do SMRA.
3.3 Modelo de banco de dados
A Figura 23 exibe a estrutura das tabelas na qual serão armazenadas as informações, divididas
em tabelas todas com campo ID utilizados como chave primaria por isso não aceita valores nulos, e serão
utilizados para apontamento de chaves estrangeira para o relacionamento entre outras tabelas para manter
a integridade referencial.
Figura 23 – Modelo relacional do banco de dados do SMRA.
Para o aplicativo SMRA o SGBD utilizado é o SQLite, por se tratar de um banco gratuito que
possui recursos suficientes para persistir dados de uma aplicação, e por ser local o que possibilitará a
criação de aplicação que funcione sem necessidade de estar conectado à internet.
Os aparelhos comercializados com o sistema operacional Android já tem pré-instalado o SQLite,

outra característica determinante para a escolha deste SGBD. Por ser implementado como uma biblioteca,
ele executa no mesmo processo da aplicação que o criou e isso diminui problemas como dependências
externas, transações bloqueadas e sincronismo [64].
Somente a aplicação que criou o banco de dados pode visualiza-lo, sendo que, cada aplicação pode
criar um ou mais banco de dados, que ficam localizados na pasta /data/data/nome_pacote/databases/,
relativa ao nome do pacote do projeto [64].
Para o aplicativo SMRA, as linhas de comando para criação do banco de dados foram armazenadas
como recursos de textos para melhor organização do código visando uma manutenibilidade. Essas
informações podem ser vistas no arquivo scriptdb.xml armazenados no diretório values. A Figura 24
apresenta o fragmento do arquivo.
Figura 24 – Fragmento do arquivo scriptdb.xml
3.4 Implementação
Nesta seção é abordada questões relacionadas a implementação do SMRA, a arquitetura do

sistema e as tecnologias utilizadas.
3.4.1 Arquitetura
A arquitetura do SMRA se baseia no padrão MVC. O padrão Model-View-Controller (MVC)
está dividido em três módulos, chamados de Model, View e Controller, conforme a Figura 25, o MVC
ajudou a impor uma estrutura sobre o desenvolvimento para que o código se torne mais controlado e
com maior qualidade. A separação em MVC torna muito mais fácil a manutenção e entendimento dos
desenvolvedores.
O módulo View é a representação visual do modelo, onde se encontra todo o conteúdo a ser
visualizado pelo usuário. É a camada de apresentação com usuário, é a interface que proporcionará a
entrada de dados e a visualização de respostas geradas. Nas aplicações web é representado pelo HTML que
é mostrado pelo browser, geralmente a visão contém formulários, tabelas, menus e botões para entrada e
saída de dados, com base nisso pode-se dizer que a camada de visão é responsável por mostrar os dados
de uma maneira que o usuário possa entender e pelos inputs de entrada de dados [65].
Figura 25 – Arquitetura abstrata do SMRA.
O módulo Controller controla o comportamento da aplicação, é ele que interpreta as ações

do usuário e as mapeia para as chamadas do modelo. Em um cliente de aplicaçõesWeb essas ações do
usuário poderiam ser cliques em botões ou seleções de menus. As ações realizadas pelo modelo incluem
ativar processos de negócio ou alterar o estado do modelo. Com base na ação do usuário e no resultado do
processamento do modelo, o controlador seleciona uma visualização a ser exibida como parte da resposta a
solicitação do usuário. Há normalmente um controlador para cada conjunto de funcionalidades relacionadas
[66].
O módulo Model é a camada responsável pelas regras de negócio da aplicação. Também é o

encarregado de guardar o estado dos objetos. Em outras palavras, essa camada manipula os dados do
sistema, de maneira que os dados estejam prontos para que as camadas de controle e visão possam
utilizá-las [65].
O módulo View interage com o usuário através de Layouts (. xml) e Activities que formam a
base para o desenvolvimento visual da aplicação SMRA. As Activitys (Controller ) realiza os tratamentos
dos eventos de tela e define qual View será desenhada na tela. Para cada tela deverá ser representada por
uma Activity que é implementada como uma subclasse de Activity. As activities devem possuir um layout
conforme Figura 26.
Figura 26 – Layout de uma activity.
A Classe R é responsável por gerenciar o acesso aos recursos de imagem, layout, menu, values,
por exemplo.
O controller (Activities) fornece os dados do modelo para a view se ligar a interface do usuário.
Quaisquer alterações ao controlador são transparentes para a view e as mudanças de interface do usuário
não afetarão a lógica de negócios e vice-versa.
As Figuras 27, 28 e 29 correspondem a trechos do desenvolvimento utilizando MVC para melhor

entendimento.
Figura 27 – Model é responsável por implementar regras de negocio, recuperar informações e armazenar.
Figura 28 – Controller responsável por mediar as interações do usuário, fornecer os dados do model para
a view se ligar a interface do usuário.
Figura 29 – View responsável por exibir os dados ao usuário criando assim uma Interface do usuário (IU).
3.4.2 Diagrama de classes

Com o diagrama de classes é possível ter uma visão de como os requisitos irão se relacionar, saber
os tipos dos dados e fornecer para os desenvolvedores uma base para a projeção do sistema. Ao analisar o
levantamento de requisitos é possível identificar os repositores de dados que, no diagrama de classes, são
representados por retângulos iniciados por seu nome, os atributos que podem conter, e os métodos que
poderão executar [67].
Na Figura 30 é apresentado o projeto das variáveis, classes, métodos e seus relacionamentos. Esse
modelo foi utilizado para criar e manter proprietários, animais, raças, espécie, categoria, locais, eventos,
manejo e representação da comunicação entre as classes.
Utilizando herança, uma característica da Programação orientada a objeto (POO), todas as classes
herdam o campo ID da classe Gregistro, onde é implementado a interface Serializable (java.io.Serializable),
um recurso que permite que as classes sejam serializadas e trafegadas como texto.
Na Tabela 3 é visualizada a explicação para cada relacionamento do diagrama de classes do

SMRA.
Figura 30 – Diagrama de classes do SMRA

Classe Relacionamento Descrição

Raça pertence a uma Espécie, e Espécie pertence a vá-
Raca Raca e Especie rias Raças. Exemplo: As raças Angus, Girolando e Nelore
pertencem a Espécie Bovinos.
Animal pertence a uma Categoria, e Categoria pertence
Animal e Categoria a vários animais. Exemplo: Vaca Mimosa está dentro da
categoria Leiteira.
Animal
Todo animal pertence a um Proprietário e Proprietários po-
Animal e Proprietario dem ter vários Animais. Exemplo: Boi Soberano e Mimosa
pertencem ao João.
Todo Animal pertence a uma Raça e Raça pertence ou
Animal e Raca
não a vários Animais.
Animal pertence a um Local, e Local pertence ou não a
Animal e Local
vários Animais.
Todo Evento pode ter nenhum ou muitos Eventos de blo-
Evento e Eventobloqueio
Evento queios e Evento bloqueio pode pertence a vários Eventos.
Todo Evento pode ter nenhum ou muitos Eventos de Even-
Evento e Eventoobrigatorio toobrigatorio e Eventoobrigatorio pode pertencer a vários
eventos.
Manejoanimal pertence a um Manejo, e Manejo pertence
Manejo e Manejoanimal
a vários Manejoanimal.
Manejo
Manejo pertence a um Local, e Local pertence ou não a
Manejo e Local
vários Manejos.
Manejo pertence a um Evento, e Evento pertence ou não
Manejo e Evento
a vários Manejos.
Todas as classes herdam o campo ID da classe Gregistro
Gregistro Todas
onde e implementado a interface Serializable.
Tabela 3 – Explicação do Diagrama de Classes do SMRA.
3.4.3 Tecnologias utilizadas

3.4.3.0.1 NetBeans IDE
A utilização de um Ambiente Integrado de Desenvolvimento (Integrated Development Environment

– IDE) no processo de desenvolvimento de software se faz necessário, pois o IDE consiste em um software
que reúne características e ferramentas que dão suporte ao desenvolvimento de sistemas com o intuito de
tornar ágil este processo. Para um desenvolvimento de sucesso a escolha e utilização de um IDE apropriado
é um fator relevante [68].
Com ferramentas de refatoração, recuo de linha, associação de palavras e colchetes, dicas de

codificação, modelos de códigos, compilação, depuração e suporte à internacionalização o NetBeans é um
ambiente de desenvolvimento gratuito e multiplataforma que permite o desenvolvimento de aplicações
mobile, desktop e web de forma rápida, organizada e eficiente com um conjunto de ferramentas para
suporte as linguagens Java, C/C++, XML, HTML, PHP, dentre outras. O NetBeans permite ainda a
instalação de plug-ins para que ocorra a sua extensão de funcionalidades [69].
Para o desenvolvimento do aplicativo SMRA foi utilizado o ambiente de desenvolvimento NetBeans

versão 8.2, este IDE foi escolhido em virtude de sua facilidade de utilização e integração com as demais
tecnologias utilizadas e sua capacidade de agilizar o processo de desenvolvimento.
3.4.3.0.2 Android SDK
Para facilitar o desenvolvimento optou-se pela utilização de um IDE, porém, é possível o de-
senvolvimento de aplicativos Android de forma nativa através do uso do Kit de Desenvolvimento de
Software (Software Development Kit - SDK ) para Android usando linguagem de programação JAVA. O
Android SDK inclui projetos de exemplo com código-fonte, ferramentas de desenvolvimento, emuladores
e bibliotecas necessárias para criar os aplicativos Android [70]. Componentes como o SDK Tools foram
utilizados no desenvolvimento do SMRA e a versão utilizada do SDK é a de número 25.2.2.
3.4.3.0.3 NBAndroid
Para que seja possível o desenvolvimento de um aplicativo Android utilizando o IDE NetBeans é
necessário que um plug-in seja instado, dessa forma suas funcionalidades são expandidas. O NBAndroid é
o plug-in que realiza a integração do NetBeans com o SDK Android, além do mais, através da utilização
deste plug-in é possivel realizar o debug por meio de dispositivo emulado ou físico.
3.4.3.0.4 Internacionalização do sistema
Se utilizado o recurso de texto disponibilizado pelo Android a adaptação do idioma do aplicativo

ao idioma do dispositivo do usuário pode ser realizada sem a necessidade de configuração ou programação
no software [71]. Para o desenvolvimento do SMRA foi adotada a utilização deste recurso e para proceder
com a adaptação do idioma da aplicação, basta realizar a alteração de um arquivo XML contido no
diretório values contendo a tradução.
3.4.3.0.5 SQLite
Para a persistência dos dados do SMRA foi escolhido dentre os tipos de persistência disponibilizados
pelo Android o SQLite, pois esse tipo de persistência permite o armazenamento local das informações de
forma estruturada utilizando SQL e garante a privacidade dos dados do aplicativo.
3.4.4 Interface
Figura 31, tela de apresentação Splash exibida durante alguns segundos enquanto o aplicativo
realiza os processos iniciais de carregamento.
Figura 31 – Tela de apresentação.

Na tela principal, Figura 32 são apresentadas as opções da aplicação, é possível escolher dentre
oito opções distintas.
Figura 32 – Tela principal.
Os oito ícones na tela representam as seguintes funcionalidades da aplicação:
1. Cadastro e manutenção de Proprietários;
2. Cadastro e manutenção de Animais;
3. Cadastro e manutenção de Eventos;
4. Dashboard Gráficos;
5. Cadastro de manutenção de Raças;
6. Cadastro de manutenção de Locais;
7. Cópia de segurança;
8. Cadastro e manutenção de Manejos de animais.
A figura 33 corresponde ao cadastro de Proprietários atendendo ao requisito RF04, onde deverá

ser preenchido todos os dados dos possíveis proprietários dos animais.
Figura 33 – Tela de cadastro de proprietários.
As Figuras 34 e 35 correspondem ao cadastro de animais atendendo ao requisito RF06, deve-se

observar alguns campos como RFID. Caso o animal esteja utilizando um brinco com tecnologia RFID,
deverá ser realizado a leitura deste brinco para identificação e registro da Tag utilizada pelo animal
através do campo RFID, no caso de utilização de brincos convencionais, aqueles que possuem apenas
representação alfanumérica para identificação, deverá ser informado no campo Brinco a representação
alfanumérica contida neste brinco.
No campo Sisbov e possível informar o número de registro do animal junto ao órgão de controle,
no campo grau sanguíneo deve-se informar a fração que indique o cruzamento do animal e no campo
Categoria deve se classificar a finalidade da criação do animal exemplo: engorda, recria, reprodução.
Figura 34 – Tela de cadastro de animais A.

Figura 35 – Tela de cadastro de animais B.
A Figura 36 corresponde ao cadastro de eventos atendendo aos requisitos RF07,RF08 e RF09,

onde deverá ser parametrizado os eventos bloqueados e obrigatórios pós evento principal e quais serão os
campos que deverão aparecer no manejo. Exemplos: no evento lactação apenas o campo resultado será
habilitado durante o manejo.
Os botões Obrigatórios e Bloqueados devem ser utilizados para cadastrar uma lista de eventos.
Exemplo: ao criar o evento Cirurgia o campo Obs deverá estar habilitado e deve-se cadastrar na lista
Obrigatórios o evento Curativos parametrizado para ocorrer durante 3 dias, enquanto na lista Bloqueados
o evento Lactação deverá ser adicionado. A partir desta parametrização, fica a cargo do sistema avisar
sobre os eventos obrigatórios e não permitir a realização de eventos bloqueados no animal.
Figura 36 – Tela de Cadastro de Eventos.
A Figura 37 representa um painel de indicadores utilizados no preenchimentos de guias dos órgãos

de defesa sanitário animal.
Figura 37 – Tela Dashboard.
A Figura 38 corresponde ao cadastro de raças atendendo ao requisito RF02, onde deverá ser
preenchido o nome da raça e uma descrição mais detalhada da raça e sua espécie.
Figura 38 – Tela de Cadastro de Raças.
A Figura 39 corresponde ao cadastro de locais atendendo ao requisito RF04. Caso no local

contenha uma Tag RFID, poderá ser realizado a leitura desta para identificação do local. Exemplo: uma
balança poderá ter uma Tag para facilitar sua localização na hora do manejo.
Figura 39 – Tela Cadastros Locais.
A Figura 40 permite fazer ou recuperar cópias de segurança das informações no formato XML,
onde serão enviadas via email atendendo aos requisitos não funcionais RNF04 e RNF07.
Figura 40 – Tela de Backup.
A Figura 41 corresponde ao lançamento de manejos, atividades diariamente desenvolvidas com os

animais, atendendo ao requisito RF10. Exemplo: no manejo 00002 ocorreu o evento Vacina de Aftosa
executado no curral. No campo responsável, caso necessário, poderá ser informado o nome do veterinário
que executou o procedimento e caso ocorra a necessidade de realizar a anotação de alguma particularidade
do manejo esta deverá ser ser informada no campo Obs.
Após lançados os dados do manejo deverá ser realizado o relacionamento dos animais que recebeu
a dose de vacina, atendendo ao requisito RF11. Conforme a Figura 42 no manejo 00002, foi ministrada
ao animal Boi soberano 1 dose de vacina de aftosa e nenhuma particularidade ocorreu com esse animal
durante esse evento, dispensando a necessidade de preenchimento do campo Obs.
Figura 41 – Tela lançamento de manejo.
Figura 42 – Tela Cadastros animais por manejo.
3.5 Trabalhos relacionados
Para auxiliar na definição do projeto do SMRA, foram identificados, testados e revisados outros
softwares inseridos no mesmo contexto de Gestão de animais com funcionalidades semelhantes às dese-
jadas para este aplicativo. Os aplicativos escolhidos foram o Brabov <https://play.google.com/store/
apps/details?id=com.brabov.mobile>, SisBov <https://play.google.com/store/apps/details?id=com.wmd.
sisbov> e BovControl <https://play.google.com/store/apps/details?id=com.bovcontrol.bovcontrol>. Eles
podem ser baixados gratuitamente pela Google Play Store, plataforma do Google onde se concentram os
aplicativos Android. Nas Figura 43, 44 e 45, pode-se ver screenshots dos aplicativos mencionados.
Figura 43 – Aplicativo BovControl.
Figura 44 – Aplicativo Brabov.
Figura 45 – Aplicativo SisBov.

Os critérios utilizados para a análise dos aplicativos selecionados foram Compartilhamento de

dados, conexão, conectividade e usabilidade, descritos a seguir:
Compartilhamento dos dados: é a capacidade do aplicativo de compartilhar os dados coletados

com outros usuários, seja exportando ou acessando os dados remotamente. O objetivo é identificar a
possibilidade de usar o aplicativo quando se está trabalhando em equipe.
Conexão: verifica se o aplicativo é capaz de trabalhar sem conexão com a Internet, o que é uma
situação muito comum para os produtores.
Conectividade: verifica se o aplicativo permite identificar/localizar animais através de Tags

Rfid utilizando NFC ou Outros leitores conectados via Bluetooth.
Usabilidade: diz respeito à facilidade de uso do aplicativo e à existência de tutoriais ou opções

de ajuda para usuários menos experientes. Também verifica se o usuário possui controle sobre os dados
coletados pelo aplicativo (se ele consegue modificar valores que são obtidos automaticamente pelo software
ou se ele pode colocar seus próprios valores em vez de usar métodos de obtenção automática). Além disso,
é observada a capacidade de adicionar campos personalizados.
Os resultados da comparação entre as 3 aplicações citadas e o SMRA podem ser vistos na Tabela
4.
SMRA Brabov SisBov BovControl

Necessita de coxão à Não Não Não Não
internet para iniciali-
zar?
Necessita de coxão à Não Limitado Não Limitado
internet para sua utili-
zação?
Permite o compartilha- Sim, através de Sincronização Nenhum Sincronização
mento de dados? arquivo XML dentro da dentro da
mesma conta mesma conta
Usabilidade Cadastros Pes- Interface pouco Cadastros Pes- Interface pouco
quisas, Filtros intuitiva: requer quisas, Filtros intuitiva: requer
Padronizados algum treina- Padronizados algum treina-
em todo o mento para sua em todo o mento para sua
aplicativo. utilização aplicativo. utilização
Permite a modificação Sim Sim Não obtém da- Sim
de dados obtidos por dos externos
uma fonte externa?
Permite a adição de no- Não Não Não Sim
vos campos?
Obriga o usuário a uti- Não Sim Sim Sim
lizar apenas dados pre-
definidos para raças,
medicamentos, catego-
rias e etc.?
Realiza leitura de Tags Sim Não Não Não
via NFC
Permite conexão com Sim Sim Não Sim
outros dispositivos de
leitura via Bluetooth?
Sua utilização para ou- Sim, Caprinos, Não, Somente Não, Somente Não, Somente
tros tipos de animais é Equinos, Suínos, Bovinos Bovinos Bovinos
possível? Bovinos e etc...
Tabela 4 – Comparativo entre as aplicações.

Pode-se observar, a partir dos dados apresentados, que a capacidade de utilização sem conectividade
é essencial para o contexto.No que se refere à leitura de Tags, a maioria lida com apenas Bluetooth.
No entanto, nenhum dos aplicativos comparados oferece leitura via NFC. A interface com o
usuário da maioria dos aplicativos é pouco intuitiva e difícil de aprender a usar inicialmente. Neste quesito,
o aplicativo SisBov se destaca, já que sua interface segue um padrão. O formato do compartilhamento de
dados é bastante variado entre os aplicativos. Os Brabov e BovControl oferecem opções de Sincronização
dentro da mesma conta que permite substituir o aparelho ou ate mesmo trabalhar em equipe sem perdas
de dados.
A exportação de todos os dados coletados, incluindo todas as descrições, só é possível para

arquivos no formato XML, oferecido pelo SMRA . A partir destas observações, pode-se concluir que, para
os pequenos produtores, nenhum destes atende todas as necessidades.
A criação de um sistema próprio, que tivesse uma boa usabilidade, atendesse todos animais de
uma pequena propriedade, fornecesse posterior acesso aos dados coletados em planilhas e permitisse
a leitura das Tags via NFC seria imprescindível para que se pudesse de fato solucionar os problemas
relatados por pequenos produtores tais como dificuldade de acesso a tecnologia de baixo custo e de fácil
manuseio e manutenção.
70
4 CONCLUSÃO
Atualmente os pequenos produtores encontram enorme dificuldade em realizar a gestão de seus

animais no que se refere a manejo, controle genético e sanitário, este problema é ocasionado pela falta de
recursos tecnológicos para o registro e controle controle de informações geradas ao longo da vida do animal.
Essa falta de recursos tecnológicos se deve a dificuldade de acesso e o custo elevado para os produtores
quando buscam soluções tecnológicas.
Para resolver este problema foi levado em consideração alguns requisitos: a criação de uma
aplicação para dispositivos móveis, a compatibilidade da aplicação com o sistema Android um dos sistema
mais utilizados atualmente em smartphones e tablets, o uso de NFC para identificação dos animais, e o
baixo custo de implantação.
Em cumprimento aos requisitos, foi proposto neste trabalho o desenvolvimento de um aplicativo

Android chamado Sistema de Manejo e Rastreabilidade Animal (SMRA), cujo objetivo foi melhorar
o controle e a gestão de animais em uma propriedade rural. Para alcançar este resultado os objetivos
específicos deste trabalho foram cumpridos.
Os produtores que antes não tinham uma ferramenta de apoio as suas atividades de gestão de
animais, passaram a ter um aplicativo que pode ser instala em seu dispositivo móvel dispensando a compra
de novos equipamentos, dessa forma é possível realizar a coleta e análise de informações do animal ao longo
de sua vida, permitindo que essas informações sejam utilizadas nas tomadas de decisões e cumprimento
de medidas sanitárias obrigatórias.
Como trabalhos futuros, tem-se o aperfeiçoamento das funcionalidades existentes e a criação de

novas funcionalidades.
71
REFERÊNCIAS
1 ABIEC. Perfil da Pecuária no Brasil Relatório Anual 2016. 2016. <http://www.abiec.com.br/Sumario.

aspx>. Acessado Junho 11, 2017.
2 FILHO, H. P. F. Arquitetura de Coleta de Dados para Pesquisas de Campo em Ambientes
Computacionais Heterogêneos. Dissertação (Mestrado) — Universidade de Brasília, 2014.
3 TRASEL, A. T.; VERONEZ, D. Banco de dados móveis. 2005.
4 SMARTSOLUTION e. THE PORTABLE COMPUTING DEVICES. 2016. <http://e-smartsolution.
co.uk/blog/tag/pda/>. Acessado Dezembro 09, 2016.
5 CONCEIçãO, U. BUILD 2016: Xamarin será open source e gratuito para todos
os desenvolvedores do iOS, Android e Windows. 2016. <https://www.meu-smartphone.com/
build-2016-xamarin-sera-open-source-e-gratuito-para-todos-os-desenvolvedores-do-ios-android-e-windows/
>. Acessado Dezembro 09, 2016.
6 CREWS, E. TOP 3 ANDROID TABLETS OF 2016. 2016. <http://www.geekinsider.com/46197-2/>.
Acessado Dezembro 09, 2016.
7 QUENOTEBOOKCOMPRAR. 5 dicas para melhorar o notebook e aumentar o desempenho. 2016.
<http://quenotebookcomprar.com.br/melhorar-o-notebook/>. Acessado Dezembro 09, 2016.
8 G1, e. S. P. H. S. G. D. Smartphone passa PC no acesso a internet. 2016. <http://g1.globo.com/
tecnologia/noticia/2016/04/smartphone-passa-pc-e-vira-aparelho-n-1-para-acessar-internet-no-brasil.
html>. Acessado Dezembro 09, 2016.
9 SáNCHEZ, R. Android lidera vendas de celulares em dezembro de 2015. 2016. <http:
//www.psafe.com/blog/android-lidera-vendas-de-celulares-em-dezembro-de-2015/>. Acessado Dezembro
07, 2016.
10 ANDROID. Android Interfaces and Architecture. 2016. <http://source.android.com/devices/index.
11 MICROSOFT, T. Troca de dados com usuários móveis. 2008. <https://technet.microsoft.com/pt-br/
library/ms151323(v=sql.105).aspx>. Acessado Março 16, 2017.
12 COSTA, D. P.; SANTOS, M. T. P. Comparativo entre gerenciadores de banco de dados para aplicação
Android. 2015.
13 TAGS http://www.idplate.com/product/rfid-destructible-windshield-tags-and-rfid-vehicle-
security-labels/rfid-tags-rfid-labels-and-asset. RFID DESTRUCTIBLE WINDSHIELD TAG. 2016.
<http://www.idplate.com/product/rfid-destructible-windshield-tags-and-rfid-vehicle-security-labels/
rfid-tags-rfid-labels-and-asset-tags>. Acessado Nov 13, 2016.
14 PEDROSO, M. C.; ZWICKER, R.; SOUZA, C. A. d. Adoção de RFID no Brasil: Um estudo
exploratório. 2009.
15 LIMA, D. S. Proposta para controle de acesso físico seguro baseada em Near Field Communication
(NFC) e Android. 2013.
16 HAMMERSCHMIDT, R. NFC: 17 usos legais para a nova tecnologia que está dominando o mercado.
2015. <https://www.tecmundo.com.br/nfc/73265-nfc-10-usos-legais-nova-tecnologia-dominando-mercado.
htm>. Acessado Abril 09, 2017.
17 LUCY. NFC TECHNOLOGY BASED PAYMENT PARTNERSHIP BEGINS
BETWEEN VERIFONE AND AIRTEL. 2015. <http://www.mobilecommercepress.com/
nfc-technology-based-payment-partnership-begins-between-verifone-and-airtel/8516671/>. Acessado
Abril 09, 2017.
Referências 72
18 PINHEIRO, L. Como usar o NFC do seu smartphone? 2013. <http://www.techtudo.com.br/

dicas-e-tutoriais/noticia/2013/12/como-usar-o-nfc-do-seu-smartphone.html>. Acessado Abril 09, 2017.
19 CUNHA, A. NFC (Near Field Communication) – Aplicações e uso. 2016. <http://www.embarcados.
com.br/nfc-near-field-communication/>. Acessado Dezembro 12, 2016.
20 COSTA, A. P. d. Desenvolvimento de um sistema para o controle do estoque da empresa Auto Molas
JM. 2013.
21 FREITAS, E. de. IMPORTÂNCIA DA AGROPECUÁRIA BRASILEIRA. 2008. <http:
//brasilescola.uol.com.br/brasil/a-importancia-agropecuaria-brasileira.htm>. Acessado Junho 11, 2017.
22 FRANCISCO, W. de Cerqueira e. Agropecuária. 2010. <http://mundoeducacao.bol.uol.com.br/
geografia/agropecuaria-5.htm>. Acessado Junho 11, 2017.
23 PLANALTO, P. Responsável por 23% do PIB, Plano Safra impul-
siona agropecuária. 2015. <http://www2.planalto.gov.br/noticias/2015/06/
responsavel-por-23-do-pib-plano-safra-impulsiona-agropecuaria>. Acessado Junho 11, 2017.
24 G1. Agronegócio brasileiro emprega 19 milhões de pessoas. 2016. <http:
//g1.globo.com/economia/agronegocios/agro-a-industria-riqueza-do-brasil/noticia/2016/12/
agronegocio-brasileiro-emprega-19-milhoes-de-pessoas.html>. Acessado Junho 11, 2017.
25 ABIEC. 5 motivos para valorizar a pecuária bovina do Brasil. 2015. <http://www.abiec.com.br/
NoticiasTexto.aspx?id=1378>. Acessado Junho 11, 2017.
26 RURAL, R. CENSO AGROPECUÁRIO - A IDENTIDADE DO PRODUTOR BRASILEIRO:. 2009.
<http://www.revistarural.com.br/Edicoes/2009/Artigos/rev141_censo.htm>. Acessado Junho 11, 2017.
27 FIGUEIREDO, C. M. S.; NAKAMURA, E. F. Computação móvel: novas oportunidades e novos
desafios. T&C Amazônia, n. 2, Junho 2003.
28 MATEUS, G. R.; LOUREIRO, A. A. F. Introdução a computação móvel. 2a edição. ed. 2004. Edição
preliminar.
29 TONIN, G. S. Tendências em computação móvel. 2012.
30 CAMARGOS, B. D. C. Arquitetura para coleta de opinião sobre serviços públicos em um sistema de
informação geográfica móvel com participação popular. 2015.
31 TANENBAUM, A. S. Rede de computadores. 4a edição. ed. [S.l.]: Campus, 2003.
32 CORTES, S. C.; LUCENA, C. J. P. Um Framework para construção de sistemas de banco de dados
movel com regras ativas. 2001.
33 ITO, G. C. Bancos de dados móveis: uma análise de soluções propostas para gerenciamento de dados.
2001.
34 AMADO, P. G. F. Bancos de dados móveis: Visão geral, desafios e soluções atuais. 2002.
35 FERNANES, D.; EDUARDO, S.; CARVALHO, J.; ALVES, M. Redes de Comunicações Sem Fios:
Gerações de telemóveis (1G, 2G, 3G, 4G). 2014.
36 ROSA, D. d. Aplicação para gerenciamento de projetos de software utilizando scrum com interface
adaptada para dispositivos móveis. 2013.
37 MENDES, J. R. R. 5G: A QUINTA GERAÇÃO. 2014.
38 LAUDON, K.; LAUDON, J. Sistemas de Informações Gerenciais. 9a edição. ed. [S.l.]: Pearson, 2010.
39 SCHAEFER, C. Protótipo de aplicativo para transmissão de dados a partir de dispositivos móveis
aplicado a uma empresa de transportes. 2004.
40 GIMENES, R. J. d. S.; JUNIOR, W. P. Banco de dados móveis e computação móvel: uma discussão
de seus recursos e aplicações. 2004.
Referências 73
41 KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistemas de Bancos de Dados. 5a edição. ed.
[S.l.]: Campus, 2006.
42 TANENBAUM, A. S. Sistemas operacionais modernos. 3a edição. ed. [S.l.]: Pearson, 2009.
43 MATOS, B. R. D.; SILVA, J. G. d. B. e. Estudo comparativo entre o desenvolvimento de aplicativos
móveis utilizando plataformas nativas e multiplataforma. 2016.
44 GOMES, E. W. C. Global interface process usando Android através de webservices. 2011.
45 ANDROID. The Android Source Code. 2016. <http://source.android.com/source/index.html>.
Acessado Dezembro 07, 2016.
46 VINCENT, J. Android is now used by 1.4 billion people. 2015. <http://www.theverge.com/2015/9/
29/9409071/google-android-stats-users-downloads-sales>. Acessado Dezembro 07, 2016.
47 ALVIM, M. Venda de celulares com Android e Windows cresceu no Brasil
em 2015; iOS teve queda. 2016. <http://blogs.oglobo.globo.com/lauro-jardim/post/
vendas-de-celulares-com-sistema-android-e-windows-cresceram-no-brasil-em-2015-ios-teve-queda.
48 MACêDO, B. A. P. d. M.; NUNES, R. C. M. RockDroid - Uma Arquitetura para Coleta de Dados
Geológicos. 2016.
49 NUNES, F. Avaliação de técnicas e mecanismos para entrada e saída de informações em dispositivos
móveis. 2014.
50 ELMASRI, R.; NAVATHE, S. B. Sistemas de Bancos de Dados. 4a edição. ed. [S.l.]: Pearson, 2005.
51 SQLITE. Sobre SQLite. –. <http://www.sqlite.org/about.html>. Acessado Julho 25, 2016.
52 COELHO, T.; PRADO, G. Análise comparativa para avaliação de tecnologias de banco de dados para
dispositivos móveis. 2014.
53 CUNHA, A. RFID – Etiquetas com eletrônica de ponta. 2016. <http://www.embarcados.com.br/
rfid-etiquetas-com-eletronica-de-ponta/>. Acessado Dezembro 12, 2016.
54 QUEIROZ, E. L. d.; ARAÚJO, T. A. d.; HORTA, M. M. B. RFID e o seu uso no indústria. 2014.
55 ALMEIDA, L. C. d. Aplicações da tecnologia de identificação por rádio frequência – RFID. 2011.
56 CARNEIRO, H. M. P. S. Sistemas de Controlo de Acesso. Dissertação (Mestrado) — Universidade de
Porto, 2004.
57 URBINO, N. P.; PEREIRA, S. R.; CARVALHO, E. S.; LODDI, S. A. MOBILE PAYMENT: Uma
visão geral. 2010.
58 ALECRIM, E. O que é NFC (Near Field Communication)? 2017. <https://www.infowester.com/nfc.
php#funcionamento>. Acessado Março 22, 2017.
59 AUGUSTO, M. V. Desenvolvimento de software com apoio de práticas Scrum. 2011.
60 SOUZA, D. R. d. Implantação da metodologia ágil Scrum em um ambiente de desenvolvimento. 2014.
61 VANZIN, I. M. INSEMINAÇÃO ARTIFICIAL E MANEJO REPRODUTIVO DOS BOVINOS. ????
<http://inseminacaoartificial.com.br/manejo.htm>. Acessado Julho 31, 2017.
62 BITTAR, C. M. M.; GALLO, M. P. d. C. Práticas de manejo com efeito no bem-estar
animal: demanda crescente. 2011. <https://www.milkpoint.com.br/radar-tecnico/animais-jovens/
praticas-de-manejo-com-efeito-no-bemestar-animal-demanda-crescente-75482n.aspx>. Acessado Julho 31,
2017.
63 MELDAU, D. C. Rastreabilidade Bovina. 2011. <http://www.infoescola.com/zootecnia/
rastreabilidade-bovina/>. Acessado Julho 31, 2017.
Referências 74
64 ANDRé, V. M. DESENVOLVIMENTO DE UM PROTÓTIPO DE APLICAÇÃO PARA UM

DISPOSITIVO COM SISTEMA OPERACIONAL ANDROID PARA A GESTÃO DE UM EVENTO
POR UM PRODUTOR. 2012.
65 CHERUBINI, E. N. DESENVOLVIMENTO EM ASP.NET MVC, JQUERY E AJAX. 2011.
66 MACORATTI, J. C. Padrões de Projeto : O modelo MVC - Model View Controller. 2004.
<http://www.macoratti.net/vbn_mvc.htm>. Acessado Junho 16, 2017.
67 GUEDES, G. T. A. UML: uma abordagem prática. 3a edição. ed. [S.l.]: NovaTec, 1998.
68 MONTEIRO, P. G. GUIARmaps: SISTEMA DE ADMINISTRAÇÃO DE MAPAS FUNCIONAIS
PARA SUPORTE À LOCOMOÇÃO DE PESSOAS COM DEFICIÊNCIA VISUAL. 2015.
69 NETBEANS. NetBeans IDE - A Forma Mais Inteligente e Rápida de Codificar. 2017.
<https://netbeans.org/features/index_pt_BR.html>. Acessado Junho 13, 2016.
70 CORDEIRO, F. Android SDK: O que é? Para que Serve? Como Usar? 2017. <http:
//www.androidpro.com.br/android-sdk/>. Acessado Junho 13, 2016.
71 ANDROID, D. Localizing with Resources. 2017. <https://developer.android.com/guide/topics/
resources/localization.html>. Acessado Junho 04, 2017.

SMRA - Aplicativo de Gestão de Animais para Dispositivos Móveis Com NFC e Plataforma Android

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SMRA - Aplicativo de Gestão de Animais para Dispositivos Móveis Com NFC e Plataforma Android

Загружено:

Авторское право:

Доступные форматы

INSTITUTO FEDERAL

DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA

Tecnologia em Análise e Desenvolvimento de Sistemas

Aparecido Carlos V. Gonçalves, Íthalo Fabrício G. S. de Oliveira

SMRA - Aplicativo de gestão de animais para dispositivos móveis

Aparecido Carlos V. Gonçalves, Íthalo Fabrício G. S. de Oliveira

SMRA - Aplicativo de gestão de animais para dispositivos móveis com NFC e

Trabalho de Conclusão de Curso apresentado à

Orientador: Prof. Me. Henrique Pereira de Freitas Filho

Trabalho de Conclusão de Curso (Graduação) – Instituto Federal de Goiás, Luziânia, 2017.

I. Oliveira, Ithalo Fabrício D. S. de. II. Título

Keywords: Animal Management, Application, Android, SMRA, NFC, Rfid, Traceability.

Tabela 1 – Requisitos funcionais do SMRA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

ABIEC Associação Brasileira das Indústrias Exportadoras de Carne

ACID Atomicidade, Consistência, Isolamento e Durabilidade

API Application Programming Interface

ASN Abstract Syntax Notation

CDMA Code Division Multiple Access

CEO Chief Executive Officer

CEPEA Centro de Estudos de Economia Agrícola

CSMA/CA Carrier Sense Multiple Access Protocol With Collision Avoidance

DML Data Manipulation Language

DVD Digital Versatile Disc

EPC Electronic Product Code

GPRS General Packet Radio Service

GPS Global Positioning System

HAL Hardware Astraction Layer

IBGE Instituto Brasileiro de Geografia e Estatística

IDE Integrated Development Environment

IEC International Electrotechnical Commission

IEEE Instituto de Engenheiros Eletricistas e Eletrônicos

IMT International Mobile Telecommunications

IPC Inter-Process Comunication

ISM Industrial, Scientific, Medical

ISO International Organization for Standardization

MAC Media Access Control

NFC Near Field Communication

OFDM Multiplexação por Divisão de Frequência Ortogonal

OHA Open Handset Alliance

PCMCIA Personal Computer Memory Card International Association

PDA Personal Digital Assistants

PIB Produto Interno Bruto

POO Programação orientada a objeto

SDK Software development kit

SDL Specification and Description Language

SGBD Sistema Gerenciador de Banco de Dados

SMRA Sistema de Manejo e Rastreabilidade Animal

SQL Structured Query Language

SyncML Synchronization Markup Language

UHF Ultra Frequency

Wi-Fi Wireless Fidelity

XML Extensible Markup Language

3 SMRA - SISTEMA DE MANEJO E RASTREABILIDADE ANIMAL . . . . . . . . . 51

Desenvolvida no espaço rural, a agropecuária consiste no conjunto de atividades que ocupam

Exercida a milhares de anos e com fundamental importância para a sobrevivência humana a

O aplicativo de gestão de animais para dispositivos móveis chamado de Sistema de Manejo e

Considerando que os números de pequenos produtores rurais representam aproximadamente

1.3.1 Objetivo geral

1.3.2 Objetivos específicos

a) Realizar a coleta de requisitos a fim de delinear o escopo do aplicativo;

Este trabalho está estruturado nos capítulos assim descritos:

• No capítulo 3 é apresentado todo o processo de desenvolvimento do aplicativo e alguns trabalhos