TCC 2016

UNIVERSIDADE DE MOGI DAS CRUZES
EVELIN KAREN PEREIRA MOURA DOS SANTOS

GIOVANI LEITE DE MELO
JONATHAN DE OLIVEIRA MENATTO
LUIZ GUILHERME BARBOSA KISS
RICHARD MONACO RET
DESENVOLVIMENTO DO APLICATIVO DESPERTADOR

INTELIGENTE
SÃO PAULO, SP
2016
2
UNIVERSIDADE DE MOGI DAS CRUZES

RICHARD MONACO RET

INTELIGENTE
Trabalho de conclusão de curso

apresentado ao curso de
Sistemas de Informação da
Universidade Mogi das Cruzes,
Campus Villa Lobos, como parte
dos requisitos para obtenção do
grau de Bacharel em Sistemas de
Informação.
Prof.º Orientador: Bruno Hideo Casillo e Maria Rosilene Ferreira
SÃO PAULO, SP
2016
3

RICHARD MONACO RET

INTELIGENTE
Trabalho de conclusão de curso

apresentado ao curso de Sistemas de
Informação da Universidade Mogi das
Cruzes, Campus Villa Lobos, como parte
dos requisitos para obtenção do grau de
Bacharel em Sistemas de Informação.
São Paulo, ____ de _____________ de 2016.
BANCA EXAMINADORA
________________________________________
Prof. Bruno Hideo Casillo
Universidade Mogi das Cruzes - UMC
________________________________________
Prof. Maria Rosilene Ferreira
________________________________________
Prof. Marco Aurélio Aloise Filho
________________________________________
Prof. Ricardo Luiz da Silva Passos
4
RESUMO
Este trabalho propõe facilitar o dia a dia das pessoas que gostam de dormir
no ônibus devido a rotina diária cansativa. O Bumps é um aplicativo que desperta no
seu lugar de destino, onde não será necessário programar um horário para ele
despertar como os despertadores comuns funcionam, ele simplesmente desperta ao
chegar no destino final, facilitando para aqueles que gostam de dormir no meio do
trajeto para a casa, faculdade e acabam passando do ponto de destino. Pensando
ainda mais nos imprevistos diários que ocorrem no percurso, ele possui uma
funcionalidade do alarme onde ele planeja o percurso para chegar em tempo, ele
lembrará quando for a hora de sair, apenas definindo o horário de chegada e o
destino.
Palavras Chave: Aplicativo, dormir e despertar.

5
LISTA DE FIGURAS
Figura 1: Diagrama de caso de uso Error! Bookmark not defined.

Figura 2: Modelo de estrutura de dados 25
Figura 3: Tela de Login 36
Figura 4: Tela de Cadastro 37
Figura 5: Tela de Menu 38
Figura 6: Tela de Alarme 39
Figura 7: Tela de Cadastro Alarme 40
Figura 8: Tela Meus Bumps 41
Figura 9: Tela Cadastro Novo Bumps 42
Figura 10: Tela Locais Favoritos 43
Figura 11: Cadastro Novo Local Favorito 44
Figura 12: Tela de Configurações 45
6
LISTA DE ABREVIATURAS E SIGLAS

ACID Atomicity, Consistency, Isolation, Durability
AM Ante Meridiem
API Application Programming Interface
APP Aplicação
BAAS Backend as a Service
BSON Binario Object Notation
CSS Cacading Style Sheet
HR Hora
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IBGE Instituto Brasileiro de Geografia e Estatística
JSON JavaScript Object Notation
MIN Minuto
PM Post Meridiem
POST Publicar
REST Representational State Transfer
SDK Software Development Kit
SGBD Sistema de Gerenciamento de Banco de Dados
SQL Structured Query Language
UML Unified Modeling Language
XML Extensible Markup Language

7
SUMÁRIO
1. INTRODUÇÃO 9
1.1 OBJETIVO 9
1.2 JUSTIFICATIVA 10
1.3 METODOLOGIA 10
1.4 ESTRUTURA DO TRABALHO 11
2. VISÃO GERAL DO SISTEMA 13
2.1.1 ALARMES 13
2.1.2 BUMPS 14
2.2 DESENVOLVIMENTO HÍBRIDO 15
2.2.1 WEBVIEW 15
2.2.2 APPS HÍBRIDOS X APPS NATIVOS 16
2.2.3 CORDOVA 16
2.3 BANCO DE DADOS ORIENTADO A DOCUMENTO 17
2.3.1 CHAVE/VALOR 18
2.3.2 ORIENTADO A COLUNAS 18
2.3.3 ORIENTADO A DOCUMENTOS 18
2.3.4 BASEADO EM GRAFOS 19
2.3.5 FIREBASE 19
2.3.5.1 POR QUE USAR? 20
3. REQUISITOS 21
3.1 Requisitos Funcionais 21
3.2 Requisitos Não Funcionais 22
4. MODELAGEM 24
4.3 MODELO DE ESTRUTURA DE DADOS (ÁRVORE JSON 25
4.2 CASO DE USO – DESCRITIVO 26
4.2.1 26
4.2.2 UC02: Cadastrar Usuário 27
4.2.3 UC03 Cadastrar Locais Favoritos 28
4.2.4 UC04 Configurar Perfil 29
4.2.5 UC05 Cadastrar Bumps 30
8
4.2.6 UC06 Cadastrar Alarme 31

4.2.7 UC07 Definir Rota 33
4.2.8 UC08 Calcular Proximidade 33
4.2.9 UC09 Despertar Bumps 34
4.2.10 UC010 Despertar Alarme 34
4.2.11 UC011 Calcular Tempo 35
5. INTERFACES DO SISTEMA 36
6. PLANO DE TESTE 46
7. CONCLUSÃO 90
BIBLIOGRAFIA 91
9
1. INTRODUÇÃO
Todos os dias, nós brasileiros, sofremos com o trânsito existente em nossas

capitais, atrasando nossas atividades cotidianas, muitas vezes sem previsão para
nossa chegada, pois o trânsito não é causado somente pelo grande fluxo de carros.
Algumas vezes o fluxo está tranquilo, porém ocorre um acidente repentino fazendo
com que forme um congestionamento e aqueles 30 minutos estipulados para a
chegada em casa, no trabalho ou outro compromisso, aumente para horas.
Em São Paulo, por exemplo, muitas empresas funcionam 24 horas por dia
fazendo com que a rotina de alguns cidadãos se torne diferenciada. Aquele que
trabalha de madrugada normalmente tem mais facilidade para chegar ao trabalho,
porém há vias que acabam sendo fechadas neste horário para: obras, mudanças,
eventos, etc. O problema maior para estes cidadãos é que estes acontecimentos
são imprevisíveis e o tempo para sua chegada acaba aumentando devido à
necessidade de utilização de caminhos alternativos.
No caso para aqueles que utilizam o transporte público ou fretamento, devido

ao grande número de tarefas e obrigações diárias capazes de realizar, acabam
dormindo nesses meios de transporte devido ao cansaço. E ao dormir passam do
ponto de parada, causando transtornos. A pessoa gostaria até mesmo de dar aquele
cochilo, mas tem medo de não acordar na hora certa, já que o trânsito é imprevisível
em uma megalópole.
Atualmente, só existe uma única solução no mercado com a função

despertador inteligente, capaz de otimizar seu tempo de acordo com o trânsito.
Porém, o mesmo não possui a função de despertar próximo ao ponto de destino.
1.1 OBJETIVO
O objetivo deste trabalho é desenvolver um aplicativo capaz de despertar o

usuário de acordo com o trânsito atual, tanto para transporte privado quanto público,
otimizando suas horas de sono.
10
Além disso, fornece a possibilidade de que o usuário seja notificado quando

estiver próximo ao ponto de destino, se baseando na geolocalização e o trânsito
local.
1.2 JUSTIFICATIVA
De acordo com o balanço do Departamento Nacional de Trânsito (DENATRAN),

o Brasil fechou 2010 com exatos 64.817.974 veículos registrados. Em dez anos, o
aumento acumulado é de 119%, ou seja, mais de 35 milhões de veículos chegaram
às ruas no período. Considerando o resultado do Censo IBGE 2010, que indica que
a população é de 190,732 milhões, o país tem uma média de um carro para cada
2,94 habitantes. (MOREIRA, 2011)
Hoje, existem duas soluções encontradas no mercado voltadas para esse

seguimento, o aplicativo Wup: Traffic Alarm Clock, um despertador inteligente que
calcula seu tempo de acordo com o trânsito. O Wup funciona somente para sistema
Android, para aqueles que fazem o percurso de carro, não se baseia em dados
atuais e não se atualiza conforme acontecimentos inesperados, portanto mais
voltado para a questão de organização do que facilitador para o dia a dia. (Wup,
2014)
E o aplicativo WAZE que em sua última atualização adicionou a função de

despertador inteligente de acordo com o trânsito, vale ressaltar que ambos só
funcionam para aqueles que fazem o percurso de carro.
Pensando nisso, esse estudo desenvolveu um aplicativo multi-plataforma

(Android /Web) que diferentemente do Wup e Waze possui a opção de soar o
alarme quando estiver próximo ao ponto de destino. O mesmo utiliza informações
enviadas pelo próprio aparelho e permite a utilização de rota via transporte público,
abrangendo um número maior de usuários. Além disso, será o primeiro software de
mercado baseado em informações em tempo real como latitude e longitude, sendo
pioneiro no mercado.
1.3 METODOLOGIA
11
A metodologia adotada para o desenvolvimento do aplicativo é composta das

etapas citadas a seguir:
A primeira etapa contempla todas as pesquisas bibliográficas relativas ao

tema em questão, que foram realizadas na Internet baseadas em temas
relacionados e palavras chaves. O resultado desta etapa foi um melhor
conhecimento da área de negócio e dos requisitos necessários.
A segunda etapa foi baseada no entendimento do resultado proveniente da

primeira etapa. Foram definidos todos os requisitos funcionais, requisitos não
funcionais e regras de negócio. Resultando nas funcionalidades e características do
aplicativo proposto.
A terceira etapa teve como objetivo a modelagem do sistema com base nos
requisitos da etapa anterior, baseado na linguagem UML, resultando assim em toda
modelagem do sistema, bem como: diagrama de caso de uso, modelo de estrutura
de dados e fluxos de eventos.
A quarta etapa teve como objetivo o desenvolvimento do sistema com base

no modelo definido e nas boas práticas da engenharia de software, resultando no
produto de software pronto.
A quinta etapa foi baseada no modelo definido na terceira etapa

contemplando o desenvolvimento do plano de teste, que aplicada ao software
resultou em um produto pronto e validado.
1.4 ESTRUTURA DO TRABALHO
Esse trabalho foi dividido em sete capítulos, onde a seguir será explicado
resumidamente o conteúdo de cada um deles.
● Capítulo 2 – Visão Geral do Sistema - Apresenta a ideia geral do sistema

e o estudo detalhado de cada fluxo que compõe o mesmo.
● Capítulo 3 – Requisitos - Apresenta as funcionalidades do sistema, tanto
os funcionais como os não funcionais, para o desenvolvimento do projeto.
12
● Capítulo 4 – Modelagem - Apresenta os modelos que explicam as

características do sistema. Este capítulo contém diagrama de caso de uso,
modelo de estrutura de dados e fluxos de eventos.
● Capítulo 5 – Interfaces do Sistema - Apresenta a prototipação das
funcionalidades e interfaces do sistema.
● Capítulo 6 – Plano de Testes e Conclusão - Apresenta o plano de testes
das funcionalidades.
● Capitulo 7 – Conclusão – Apresenta as conclusões adquiridas com o
desenvolvimento do sistema.
13
2. VISÃO GERAL DO SISTEMA
O aplicativo propõe melhor maneira de administrar recursos e ainda cuidar da

saúde e bem estar dos cães e gatos. Será disponibilizado em versão web. Ao
acessar a aplicação a ONG deverá se cadastrar primeiro, antes de acessar qualquer
função disponível do sistema.
O sistema fornece duas funcionalidades que o caracterizam, a primeira
função, denominada de Notificações e a segunda função, denominada de Ambientes
( ou Alocação, o que preferirem).
2.1.1 Notificações
O primeiro passo para usufruir adequadamente desta funcionalidade começa

com a definição de quatro parâmetros, são eles:
● Nº do Animal;
● Ambiente onde ele está alocado; (Preenchido automáticamente
consultando tabelas internas)
● Tipo de ação (Ex. Medicação, Consulta, Vacinação);
● Horário da primeira dose e periodicidade (Ex. 6h-6h, 12-12).
Após ter os quatro parâmetros acima definidos a configuração da notificação

se inicia. No menu, [localizado esquerda na tela do sistema] o usuário seleciona a
funcionalidade “Console de Notificações”, o sistema redireciona o usuário para a tela
“Notificações”, nesta interface, o usuário poderá listar todas as notificações ativas e
ter acesso à históricos por meio de busca.
Para adicionar um nova notificação, o usuário seleciona a opção “Incluir novo
item” [no canto inferior direito da tela] “Notificações”, então, o sistema o redireciona
para a tela “Nova Notificação”.
Nesta interface, o usuário introduz os cinco parâmetros definidos
anteriormente, após o preenchimento dos campos, [o sistema monta um arquivo de
14
tal tipo,] com os parâmetros informados pelo usuário, que por sua vez é enviado ao
banco de dados.
2.1.2 Ambiente
O primeiro passo para usufruir adequadamente desta funcionalidade começa

com o mapeamento do ambiente disponível dentro do espaço da ONG, que poderá
ser feito mediante apresentação de planta, descrição ou [ sei lá, foto? ]
Será exibida na tela, uma representação digital do ambiente que a ONG de

fato possui, e será possível definir quantidade máxima de cada viveiro.
A disposição será dinâmica, sempre que um novo animal for cadastrado, um
novo ícone móvel será disponibilizado na opção “ Editar Ambientes” localizada na
tela “Ambientes” e será possível arrastar o novo ícone para o viveiro desejado, o que
ocupará 1 espaço daquele viveiro. No menu [localizado a esquerda na tela do
sistema], o usuário seleciona a funcionalidade “Meu Ambiente”, o sistema
redireciona o usuário para a tela “Ambientes”, nesta interface, o usuário visualiza a
tela principal que apresenta a situação atual do ambiente num todo, quantidade de
animais por viveiro, viveiros com restrições( Ex. que contém animais que não podem
estar juntos à outros).
2.2 DESENVOLVIMENTO HÍBRIDO
Uma mobile app nativa é aquela desenvolvida com as linguagens padrão da

SDK do dispositivo. No caso do Android, o Java e no caso do iOS, o Objective-C, e
mais recentemente o Swift. Já uma app híbrida é aquela que é toda desenvolvida
com Html, Css e JavaScript e que mesmo assim pode ser empacotada e distribuída
nas app store como uma app nativa. (Vasconcellos, 2015)
O desenvolvimento híbrido consiste em utilizar Html, Css e JavaScript para a
construção de uma mobile app que depois será instalada e executada do mesmo
15
modo de uma app nativa. Isso só é possível, pois, assim que a app é aberta pelo
usuário, todo esse código roda dentro de algo chamado Webview.
2.2.1 WEBVIEW
Webview é o nome dado a um tipo diferenciado de browser que começa a ser

executado assim que a app híbrida é aberta pelo usuário. É dentro desse browser
que a app funciona. A webview não contém componentes característicos como por
exemplo: barra de endereço e barra de favoritos. A webview contém apenas o
necessário para que o Html, Css e JavaScript funcionem.
Por isso o nome híbrido, uma parte da app é feita em código nativo para ser
empacotada e distribuída nas app store, e a outra parte é feita de código não nativo
que implementa todo o visual e o comportamento da app.
O grande diferencial de uma webview é que ela não se limita à renderização
da app. Ela também consegue acessar recursos nativos do dispositivo como
câmera, microfone, acelerômetro, etc. Isso é possível graças a uma interface
JavaScript que torna a webview apta a executar código nativo nos dispositivos.
No desenvolvimento híbrido é possível usar apenas JavaScript para acessar
os recursos nativos do dispositivo, coisa que nenhum browser comum instalado no
aparelho seria capaz de acessar.
2.2.2 APPS HÍBRIDOS X APPS NATIVOS
A principal limitação de uma app híbrida se dá em termos de desempenho e

fluidez. Atualmente uma app híbrida não consegue ser tão fluída e performática
quanto uma app nativa, já que a renderização nativa ainda está muito à frente do
poder de renderização de uma webview. A principal vantagem de uma app híbrida é
ter uma única base de código capaz de rodar em diversos sistemas diferentes. Ao
invés de dar manutenção para uma base em Java para Android, em outra em
Objective-C para iOS, com uma app híbrida só é necessário dar manutenção em
16
uma única base de código que, por sua vez, poderá ser empacotada e distribuída
para todas as plataformas disponíveis. (Vasconcellos, 2015)
2.2.3 CORDOVA
Atualmente o desenvolvimento híbrido possui duas plataformas principais, o

cordova e o phonegap. Os dois servem ao mesmo propósito, que é de um modo
transparente para o desenvolvedor, que é criar uma app nativa capaz de abrir uma
webview para a execução do Html, Css e JavaScript criados pelo desenvolvedor.
Eles também possuem o conceito de plugins que são usados para acessar os
recursos do dispositivo. Através do comando build do cordova, o código não nativo
da app é empacotado dentro de uma app nativa. O build pode ser considerado a
principal funcionalidade do cordova. Input do build são os arquivos Html, Css e
JavaScript além de alguns arquivos de configuração do seu projeto, e o output é
uma app nativa que ao ser executada, abre a webview que vai renderizar a app.
Outro comando muito importante do cordova é o plugin. Através do plugin
add e do plugin rm os plugins que acessam os recursos nativos da app podem ser
adicionados e removidos. O repositório de plugins do cordova se encontra
em http://plugins.cordova.io. Lá é possível buscar por qualquer plugin registrado, o
cordova por padrão não vem com nenhum plugin instalado. Isso é feito para que o
build final da sua app não fique sobrecarregado com plugins que você não vai
precisar.
Algo interessante sobre os plugins do cordova é que dado algum domínio das
linguagens nativas, é possível criar o seu próprio plugin customizado.
2.3 BANCO DE DADOS ORIENTADO A DOCUMENTO
Termo que descreve uma nova classe de banco de dados que vêm tendo um
crescimento de uso acentuado nos últimos anos, principalmente em função de
algumas limitações existentes nos bancos de dados relacionais. Apesar de o termo
significar Not Only SQL, a principal característica desses bancos é de não ter
comportamento relacional. Inclusive, não há nada que impeça o uso de linguagem
SQL. A implicação do termo NoSQL é que os objetivos desses bancos de dados,
modernos e distribuídos, são, na maioria das vezes, distintos dos objetivos dos
17
bancos de dados relacionais. Os bancos de dados NoSQL geralmente seguem os

princípios de padrão base em detrimento das propriedades ACID, priorizando o
desempenho e a disponibilidade. Esse padrão fornece aos bancos de dados
características como:
- Essencialmente disponível, o sistema parece estar funcionando o tempo todo;
- Estado leve, o sistema não precisa ser consistente o tempo todo;
- Consistência casual, o sistema torna-se consistente no momento devido.
Com NoSQL Database, pode-se gerenciar grande quantidade de dados sem
perda de desempenho. Isso é plausível porque esses bancos prezam pela
inexistência de transações e cláusulas join. Ainda possuem configuração facilitada
para escalabilidade horizontal e na maioria das vezes, suporte nativo à replicação
dos dados. A escalabilidade horizontal corresponde à adição de máquinas
servidoras, enquanto a escalabilidade vertical é o aumento de desempenho de
apenas um servidor central. A escalabilidade vertical pode ter um limite de hardware,
já na horizontal não há limites de nodos, porém é mais complicada de ser
arquitetada e necessita de facilitadores. No caso, o uso de bancos de dados NoSQL
é um facilitador.
Outra característica do NoSQL Database é o armazenamento de dados sem
estrutura pré-definida, ou seja, não é preciso definir no momento de criação do
banco os tipos de dados que serão armazenados, isso é feito dinamicamente à
medida que são inseridos.
Os bancos de dados NoSQL são classificados de acordo com a forma de
armazenar os dados. Existem quatro tipos de categorias: chave/valor, orientado a
colunas, orientado a documentos e baseados em grafos.
2.3.1 CHAVE/VALOR
O armazenamento do tipo chave/valor é semelhante ao uso de mapas ou de

dicionários, onde os dados são endereçados por uma única chave, permitindo aos
clientes colocar e solicitar valores por chaves. Esses sistemas podem conter dados
estruturados ou não estruturados. São úteis para operações simples, que são
baseadas somente em atributos chave. Por exemplo, sistemas com rápida troca de
dados e com frequente escrita. Como a maioria dos armazenamentos chave/valor
18
mantém seu conjunto de dados em memória, eles são bastante usados para cache
de consultas SQL. Alguns bancos desta categoria são: Redis, Riak, Voldemort,
MemcacheDB, etc.
2.3.2 ORIENTADO A COLUNAS
Um SGBD orientado a colunas armazena seu conteúdo de forma inversa aos

bancos de dados orientados a linhas. Este formato de armazenar as informações
torna-se vantajoso para Data Warehouses, onde agregações são processadas sobre
uma quantidade de dados de características similares. Nesta categoria estão
incluídos bancos, tais como Cassandra e Hbase.
2.3.3 ORIENTADO A DOCUMENTOS
Um banco de dados orientado a documentos armazena, recupera e gerencia

dados semiestruturados. O elemento dos dados é chamado documento. Os
documentos são endereçados no banco de dados via uma chave única que
representa o documento. Uma das características de um banco de dados orientado
a documentos é que, além da simples chave/valor de pesquisa, é possível recuperar
um documento através de uma API, ou linguagem de consulta disponibilizada pelo
banco. Todos os bancos de dados correntes fornecem suporte a documentos no
formato JSON.
O JSON é um padrão aberto de estruturação de dados baseado em texto e
legível por humanos, utilizado para a serialização de dados. Foi projetado com o
objetivo de ser simples, portátil, textual, e um subconjunto do JavaScript e tem se
mostrado uma ótima alternativa ao XML, inclusive sendo nativo de armazenamento
em alguns bancos de dados.
Outro formato de documento utilizado é o BSON, semelhante ao JSON,
porém com armazenamento binário, consistindo em uma lista de elementos
chave/valor, onde a chave é uma string e o valor pode ser string, inteiro, data,
booleano, nulo, objeto BSON ou matriz BSON.
Nessa categoria estão incluídos bancos, tais como: FireBase, MongoDB,
CouchDB, Couchbase, RavenDB, SimpleDB, etc.
19
2.3.4 BASEADO EM GRAFOS
O armazenamento baseado em grafos fundamenta-se na teoria dos grafos.

Em geral, vemos que grafo consiste de nós, propriedades e arestas. Os nós
representam as entidades, as propriedades representam os atributos e as arestas
representam as relações. Como exemplos de bancos de dados desta categoria
podemos citar o InfoGrid e Neo4j.
2.3.5 FIREBASE
Firebase é um banco de dados escalável tolerante a falhas e orientado a

documentos de esquema livre. A empresa Firebase foi fundada em 2011 por Andrew
Lee e James Tamplin. Ela está localizada na cidade de São Francisco na Califórnia.
E em outubro de 2014, a empresa foi comprada pela Google. (Renosto, 2015)
O Firebase é um BaaS que oferece diversos serviços para facilitar o
desenvolvimento de aplicações no lado do servidor. Com integração a várias
plataformas como AngularJS, Java Script, Node.js, Android e IOS, o Firebase ajuda
desenvolvedores a focar no desenvolvimento frontend mobile e web.
O coração do Firebase é um banco de dados NoSQL real time que armazena
os dados na nuvem.
O Firebase utiliza uma API HTTP/REST para a manipulação dos dados,
portanto a comunicação entre cliente e servidor pode ser realizada em qualquer
aplicação que possa comunicar-se por HTTP. As operações básicas de um banco
de dados são mapeadas para as operações do protocolo HTTP, como GET, PUT,
POST, DELETE, para ler, armazenar, substituir e remover objetos armazenados.
Além da API REST/HTTP que provê acesso a qualquer aplicação com suporte ao
protocolo HTTP, o Firebase oferece um servidor web, que pode ser acessado pelo
administrador da aplicação, utilizando um browser através da página do Firebase.
A raiz do Firebase nada mais é que um objeto JSON. A partir desse objeto, é
possível criar campos numéricos, alfanuméricos, ou objetos que podem conter
outros objetos.
20
O Firebase transforma automaticamente cada propriedade do objeto JSON

em um resource que poderá ser acessível através da API REST.
2.3.5.1 POR QUE USAR?
● Reduz a complexidade ou até elimina a necessidade de desenvolver uma

aplicação Server side específica.
● Tempo de resposta baixíssimo, o que torna o Firebase ideal para
aplicações real time como chats e jogos multiplayers.
● Crescimento progressivo da aplicação. A aplicação poderá receber a
quantidade de tráfego de dados e de usuários que for necessária.
3. REQUISITOS
Os requisitos da aplicação proposta neste trabalho seguirão a estrutura de

requisitos funcionais e requisitos não funcionais, descrita a seguir:
3.1 Requisitos Funcionais

21
Identificação Nome Descrição

RF01 Efetuar Login Permitir que o usuário previamente
cadastrado se autentique na aplicação.
RF02 Cadastrar Usuário Permitir ao usuário que se cadastre na
aplicação com e-mail e senha.
RF03 Cadastrar Local Favorito Permitir que o usuário cadastre e
exclua pontos de interesses de sua
escolha, que ficam marcados no mapa
com ícones distintos, facilitando sua
identificação, suas coordenadas são
salvas para realizar as pesquisas mais
facilmente.
RF04 Configurar Perfil Permitir ao usuário a alteração do
formato de visualização do horário (24h
ou Am/Pm), alteração do toque e
vibração dos alarmes e Bumps, trocar a
senha e permite sair da conta logada.
RF05 Cadastrar Bumps Permitir que o usuário cadastre Bumps,
podendo utilizar um local favorito
previamente cadastrado durante o
cadastramento.
RF06 Cadastrar Alarme Permitir ao usuário o cadastramento do
alarme, informando local de origem,
local de destino, meio de transporte,
horário de chegada ao local de destino,
tempo hábil para se arrumar e
repetições semanais.
RF07 Definir de Rota A definição de rota é baseada no local
de origem, local de destino e meio de
transporte utilizado, tais informações
são coletadas no cadastramento do
alarme, onde são usufruídas para
realizar uma busca no API Google
Maps, o qual fornece a melhor rota com
as variáveis utilizadas.
RF08 Calcular Proximidade O cálculo de proximidade é baseado no

local de destino e range cadastrados
nos Bumps ativos, com essas
informações uma monitoração é
executada com o API GeoFence, o qual
provê o cálculo de proximidade
RF09 Despertar Bumps A notificação é baseada no RF08, que
monitora os Bumps ativos, quando os
parâmetros indicados no Bumps em
conjunto com a geolocalização do
usuário atendem aos requisitos da
funcionalidade, uma notificação é
enviada ao usuário.
22
RF10 Calcular Tempo O tempo utilizado no processo da

funcionalidade “Alarme” é baseado no
RF07, ou seja, após a definição da rota
utilizando o API GoogleMaps, o tempo
necessário do ponto de origem até o
ponto de destino previamente
cadastrado é monitorado a partir do
dobro do tempo médio utilizado, ou
seja, se por base a rota indicada
demora em média 01:30 horas do ponto
de origem até o ponto de destino, o
Alarme começa a ser monitorado 03:00
horas antes.
RF11 Despertar Alarme A notificação é baseada no RF10, que
monitora o tempo necessário do ponto
de origem até o ponto de destino,
quando o horário de chegada
cadastrado e o horário atual entram em
simetria com o tempo necessário para
chegada do ponto de origem até o
ponto de destino, o alarme notifica o
usuário, o informando que o mesmo
deve sair no exato momento para evitar
atrasos.
3.2 Requisitos Não Funcionais
Identificação Nome Descrição

RNF01 Usabilidade O sistema fornece suas
funcionalidades ao usuário da
maneira mais usual possível, de
modo que em poucas interações e de
forma intuitiva o usuário consiga
encontrar as informações que deseja
facilmente.
RFN02 Customização Há possibilidade de customizar o
sistema, tanto quanto possível, de
forma a ele se moldar, visto as
necessidades dos mais variados tipos
de usuários, sem comprometer as
suas funcionalidades.
RFN03 Compatibilidade É possível executar a aplicação
plenamente em todas as plataformas
suportadas, oferecendo uma
experiência semelhante de interação
quaisquer que sejam essas
plataformas e suas versões.
23
RFN04 Desempenho quanto à O sistema utiliza os recursos

utilização de recursos disponibilizados pelos aparelhos
móveis de forma exata as suas
necessidades, não desperdiçando a
utilização de nenhum destes
recursos, evitando o desperdício de
informações e aumentando a
autonomia da bateria do aparelho.
4. MODELAGEM
4.1 DIAGRAMA DE CASO DE USO
Figura SEQ Figura \* ARABIC 1: Diagrama de caso de uso

Fonte: Autoria própria
24
4.3 MODELO DE ESTRUTURA DE DADOS (ÁRVORE JSON)

25
Figura 2: Modelo de estrutura de dados

4.2 CASO DE USO – DESCRITIVO

26
4.2.1 UC01: Efetuar Login
1.Objetivo: Autenticar usuários no sistema.
2.Ator: Usuário
3.Pré-condições: O usuário deve estar previamente cadastrado no sistema.
4.Pós-condições: O usuário tem acesso ao sistema.
FLUXO DE EVENTOS
Fluxo Principal
1. O usuário acessa a tela de login do sistema;

2. O usuário preenche os campos obrigatórios de e-mail e senha e clica no
botão “Entrar”.
3. O sistema efetua a validação dos dados.
4. O usuário acessa a tela inicial do sistema.
Fluxo Alternativo A
1. Na etapa 3 do fluxo principal, caso os dados não sejam autenticados com

sucesso, o sistema exibe uma janela pop-up com a mensagem “Dados
Inválidos”
2. O sistema limpa o campo senha e redireciona o cursor para o mesmo.
Fluxo Alternativo B
1. Na etapa 1 do fluxo principal, o usuário seleciona a opção “Entrar com o

Facebook”.
2. O sistema apresenta a tela de confirmação do vínculo e redireciona para a
tela inicial do sistema.
Fluxo Alternativo C
1. Na etapa 1 do fluxo principal, o usuário seleciona a opção “Esqueci a

senha”.
2. O sistema exibe uma janela pop-up solicitando o e-mail cadastrado e envia
uma nova senha para o e-mail indicado pelo usuário.
4.2.2 UC02: Cadastrar Usuário
1.Objetivo: Cadastrar o usuário no sistema.
2.Ator: Usuário
27
3.Pré-condições: O usuário deve possuir o aplicativo instalado em seu dispositivo

mobile ou ter acesso ao site.
4.Pós-condições: Usuário cadastrado no sistema.
FLUXO DE EVENTOS
Fluxo Principal
1. O usuário acessa a tela de login do sistema.

2. O usuário seleciona a opção “Cadastrar”.
3. O sistema redireciona o usuário para a tela de cadastro.
4. O usuário preenche o campo “e-mail”.
5. O usuário preenche o campo “senha”.
6. O usuário preenche o campo “repetir senha” com a mesma senha
informada na etapa anterior.
7. O sistema redireciona para a tela de login.
Fluxo Alternativo A
1. Na etapa 4 do fluxo principal, caso já possua um e-mail cadastrado, o

sistema exibe uma janela pop-up com a mensagem “e-mail já cadastrado,
por favor utilize outro e-mail válido”.
Fluxo Alternativo B
1. Na etapa 4 do fluxo principal, caso o e-mail informado não atenda aos

padrões de e-mail válido, o sistema exibe uma janela pop-up com a
mensagem “e-mail informado não é válido”.
2. O sistema limpa o campo “e-mail”.
Fluxo Alternativo C
1. Na etapa 5 do fluxo principal, caso a senha não atenda a regra de negócio

RN01, o sistema exibe uma janela pop-up com a mensagem “A senha
deve possuir 6 ou mais caracteres”.
2. A senha anteriormente informada é apagada.
Fluxo Alternativo D
1. Na etapa 6 do fluxo principal, caso a senha não coincida com a senha

informada na etapa 5, o sistema exibe uma janela pop-up com a
mensagem “Senhas não coincidem”.
2. O sistema limpa o campo “repetir senha”.
Regra de Negócio RN01
28
● A senha deve conter 6 ou mais caracteres.
4.2.3 UC03 Cadastrar Locais Favoritos
1.Objetivo: Cadastrar locais favoritos no sistema.
2.Ator: Usuário
3.Pré-condições: O usuário deve possuir acesso ao sistema.
4.Pós-condições: Local favorito cadastrado.
FLUXO DE EVENTOS
Fluxo Principal
1. Na aba de menu lateral, o usuário deve selecionar a opção “Locais

Favoritos”.
2. O sistema redireciona o usuário para a tela de “Locais Favoritos”.
3. O usuário seleciona a opção “+” em rosa no canto inferior direito da tela
“Locais Favoritos”.
4. O sistema redireciona para a tela “Novo Local Favorito”.
5. Na tela de “Novo Local Favorito” o usuário preenche o primeiro campo de
texto com o endereço que deseja cadastrar.
6. No campo “Apelido” o usuário preenche com o apelido escolhido para o
local favorito em questão.
7. O Usuário verifica o endereço digitado com o mapa localizado na parte
inferior da tela “Novo Local Favorito”.
8. Por último, o usuário confirma a ação clicando no botão de salvar no canto
superior direito.
9. O sistema redireciona o usuário para a tela “Locais Favoritos”.
Fluxo Alternativo A
1. Na etapa 6 do fluxo principal, caso já exista um local favorito cadastrado

com o mesmo apelido que o usuário deseja cadastrar.
2. Uma janela pop-up exibi uma mensagem “Apelido já cadastrado”.
Fluxo Alternativo B
1. Na etapa 2 do fluxo principal, é listado para o usuário os locais favoritos

previamente cadastrados.
2. O usuário possui a funcionalidade de excluir qualquer local favorito
clicando no “X” no canto direito de cada local favorito.
3. Ao clicar no “X” uma janela pop-up é exibida informando se este local
favorito em questão é utilizado em algum alarme ou bumps cadastrado.
29
4.2.4 UC04 Configurar Perfil
1.Objetivo: Configurar o perfil do usuário.
2.Ator: Usuário.
4.Pós-condições: Configurações universais do sistema configuradas.
FLUXO DE EVENTOS
Fluxo Principal
1. Na aba de menu lateral, o usuário deve selecionar a opção

“Configurações”.
2. O sistema redireciona o usuário para a tela de “Configurações”.
3. O usuário seleciona no campo “Formato da hora” qual será o formato de
visualização de horário.
4. O usuário seleciona no campo “Toque” qual será o toque escolhido para
os alarmes e bumps cadastrados.
5. O usuário seleciona no campo “Vibrar” se deseja que o celular vibre ao
soar um alarme ou bumps.
6. O usuário ao clicar na opção “Trocar senha” uma janela pop-up é exibida
com a tela “Trocar senha”.
7. O usuário informa a senha antiga, a senha nova e deve repetir a senha
nova, estando de acordo com a RN01.
8. O usuário clica na opção “trocar” no canto inferior direito da janela pop-up,
então é executada a validação dos dados e ao final a senha é alterada
com sucesso.
9. Ao selecionar a opção “sair”, o usuário se desloga do sistema.
Fluxo Alternativo A
1. Na etapa 7 do fluxo principal, caso a senha informada no campo “senha

antiga” não coincida com a senha atual, uma janela pop-up é exibida com
a mensagem “senha antiga incorreta” ao clicar na opção “trocar”.
Fluxo Alternativo B
1. Na etapa 7 do fluxo principal, caso a senha informada no campo “repetir

senha” não coincida com a senha informada no campo “Senha nova”, uma
30
janela pop-up é exibida com a mensagem “senhas não coincidem” ao

clicar na opção “trocar”.
4.2.5 UC05 Cadastrar Bumps
1.Objetivo: Cadastrar bumps no sistema
2.Ator: Usuário
4.Pós-condições: Bumps cadastrado com sucesso.
FLUXO DE EVENTOS
Fluxo Principal
1. Na aba de menu lateral, o usuário deve selecionar a opção “Meus Bumps”.

2. O sistema redireciona o usuário para a tela “Meus Bumps”.
3. Na tela “Meus Bumps” o usuário clica na opção “+” no canto inferior direito.
4. O sistema redireciona para a tela “Novo Bumps”.
5. O usuário preenche o campo “Endereço” com o local onde deseja criar um
Bumps.
6. Uma linha horizontal que representa a distância em metros é apresentada
abaixo do campo “Endereço”, onde o usuário arrasta da esquerda para a
direita de uma forma crescente com a distância que deseja ser notificado a
partir do endereço citado acima.
7. O usuário preenche o campo “Repetir” com a frequência semanal em que
deseja que o bumps em questão se repita.
8. O usuário confirma a ação clicando no botão de salvar no canto superior
direito da tela “Novo Bumps”.
Fluxo Alternativo A

3. Na tela “Meus Bumps” o usuário seleciona a opção de listagem de bumps,
uma janela pop-up é exibida informando todos os bumps previamente
cadastrados.
4. Na janela pop-up o usuário possui a funcionalidade de ativar ou desativar
o bumps em questão clicando na barra de ativação no lado direito da
própria janela pop-up.
31
Fluxo Alternativo B

3. Na tela “Meus Bumps” o usuário seleciona a opção de listagem de bumps,
uma janela pop-up é exibida informando todos os bumps previamente
cadastrados.
4. Na janela pop-up o usuário seleciona o bumps que deseja alterar.
5. O sistema redireciona o mapa para o bumps selecionado pelo usuário.
6. O usuário clica em cima do bumps cadastrado no mapa.
7. O sistema exibe uma janela pop-up com as informações do bumps em
questão, possibilitando ao usuário que o mesmo exclua ou altere qualquer
informação apenas clicando nos ícones no canto inferior direito da janela
pop-up.
4.2.6 UC06 Cadastrar Alarme
1.Objetivo: Cadastrar alarme no sistema
2.Ator: Usuário
4.Pós-condições: Alarme cadastrado com sucesso.
FLUXO DE EVENTOS
Fluxo Principal
1. Na aba de menu lateral, o usuário deve selecionar a opção “Alarmes”.

2. O sistema redireciona o usuário para a tela “Alarmes”.
3. Na tela “Alarmes” o usuário clica na opção “+” no canto inferior direito.
4. O sistema redireciona para a tela “Novo Alarme”.
5. O usuário preenche o campo “Origem” com o endereço de origem do
alarme.
6. O usuário preenche o campo “Destino” com o endereço de destino do
alarme.
7. O usuário seleciona se o trajeto será feito de carro ou transporte público
clicando na figura de um carro para transporte privado, ou na imagem de
ônibus para transporte público.
8. O usuário preenche o campo “Chegar no destino” com o horário que
deseja estar no endereço de destino.
9. O usuário preenche o campo “Tempo para sair(mn)” com a quantidade de
minutos que o mesmo demora para se arrumar até sair de seu endereço
de origem até o endereço de destino informados acima.
32
10. O usuário selecionar no campo “Repetir” quais serão os dias em que o

alarme em questão será repetido.
11. O usuário clica na opção “Visualizar rota”, o sistema exibe uma janela pop-
up com a melhor rota seleciona pelo API Google Maps designada para os
endereços de origem e destino informados pelo usuário no alarme em
questão.
12. O usuário confirma a ação clicando na opção “salvar” no canto superior
direito da tela “Novo Alarme”.
13. O sistema redireciona o usuário para a tela “Alarme”.
Fluxo Alternativo A
1. Na aba de menu lateral, o usuário deve selecionar a opção “Alarmes”.

3. Na tela “Alarmes” o usuário visualiza todos os alarmes previamente
cadastrados.
4. O usuário pode ativar ou desativar qualquer alarme previamente
cadastrado apenas clicando na barra de ativação rosa no canto direito de
cada alarme.
Fluxo Alternativo B
1. Na etapa 3 do fluxo alternativo A, caso o usuário necessite efetuar

qualquer alteração nos alarmes.
2. O usuário seleciona o alarme que deseja alterar.
3. O sistema exibe uma janela pop-up com todas as informações do alarme.
4. O usuário seleciona o ícone de alteração na janela pop-up no canto
inferior direito.
5. O sistema redireciona o usuário para a tela “Novo Alarme” com todos os
campos preenchidos com as informações do alarme em questão.
6. O usuário executa qualquer alteração e a salva clicando na opção salvar
no canto superior direito.
4.2.7 UC07 Definir Rota
1.Objetivo: Definir rota para alarmes.
2.Atores: API Google Maps e usuário.
3.Pré-condições: Alarme previamente cadastrado pelo usuário.
4.Pós-condições: Rota definida para o alarme.
FLUXO DE EVENTOS
Fluxo Principal
33
1. Na etapa 7 do fluxo principal referente ao UC06 Cadastrar Alarme, o

usuário seleciona qual o meio de transporte utilizado para o alarme em
questão.
2. Após a seleção do meio de transporte, as informações de origem, destino
e meio de transportes são utilizadas para efetuar uma busca de melhor
rota possível para estas condições no API Google Maps.
3. A informação de melhor rota é adquirida pelo sistema, que é exibida na
etapa 11 do fluxo principal referente ao UC06 Cadastrar Alarme.
4.2.8 UC08 Calcular Proximidade
1.Objetivo: Efetuar o cálculo de proximidade do usuário
2.Ator: Sistema
3.Pré-condições: Bumps previamente cadastrado e ativo.
4.Pós-condições: Localização do usuário em relação aos Bumps ativos.
FLUXO DE EVENTOS
Fluxo Principal
1. O sistema utiliza a geolocalização do celular para efetuar o cálculo

necessário de proximidade.
2. Com base nas informações de geolocalização é realizado o cálculo off-line
da posição atual do celular.
3. A localização do celular é calculada a todo o momento.
4. O sistema executa a função descrita no UC09 após o celular entrar no
range de qualquer bumps ativo.
4.2.9 UC09 Despertar Bumps
1.Objetivo: Despertar o usuário
2.Ator: Sistema
3.Pré-condições: Bumps previamente cadastrado pelo usuário
4.Pós-condições: Usuário notificado de acordo com os parâmetros informados pelo

mesmo.
FLUXO DE EVENTOS
34
Fluxo Principal
1. Na etapa 4 do fluxo principal referente ao UC08, o sistema fornece a

informação de que o usuário entrou no parâmetro determinado pelo
Bumps.
2. O sistema notifica o usuário com o toque e vibração configuração na aba
lateral “Configurações”.
3. O sistema exibe uma tela com a notificação descrevendo o nome do
bumps e a opção de desativar o bumps.
4.2.10 UC010 Despertar Alarme
1.Objetivo: Despertar o usuário
2.Ator: Sistema
3.Pré-condições: Alarme previamente cadastrado

mesmo.
FLUXO DE EVENTOS
Fluxo Principal
1. Com base no cálculo efetuado no UC011, o sistema monitora a rota

determinada para o usuário até o ponto de destino cadastrado.
2. Ao atingir o tempo adequado para que o usuário se direcione até o ponto
de destino no horário previamente cadastrado, o sistema exibe uma janela
pop-up.
3. A janela pop-up informa que o usuário deve sair no exato momento para
não se atrasar.
4.2.11 UC011 Calcular Tempo
1.Objetivo: Efetuar o cálculo de proximidade do usuário
2.Ator: Sistema
3.Pré-condições: Alarme previamente cadastrado

mesmo.
FLUXO DE EVENTOS
35
Fluxo Principal
1. O sistema utiliza o API Google Maps para efetuar o cálculo de tempo

necessário até o ponto de destino determinado pelo usuário.
2. Este valor é previamente cadastrado e informado para usuário.
5. INTERFACES DO SISTEMA
36
Figura 3: Tela de Login

Essa é a tela para acessar o sistema, nela é possível acessar via e-mail e Facebook.
37
Figura 4: Tela de Cadastro

Essa é a tela de cadastro para ter acesso ao sistema, é necessário preencher o

nome, e-mail e senha para cadastra-lo.
38
Figura 5: Tela de Menu

Essa é a tela do menu do sistema, onde estão as opções fornecidas pelo software.
39
Figura 6: Tela de Alarme

Essa é a tela de alarme, nela é possível verificar os alarmes cadastrados. No botão

+ é possível cadastra-los.
40
Figura 7: Tela de Cadastro Alarme

Essa é a tela de cadastro de alarmes, para cadastra-lo é preciso definir o horário

para estar no local, selecionar o tipo de trajeto, o local de origem, destino e o tempo
para sair.
41
Figura 8: Tela Meus Bumps

Essa é a tela Meus Bumps. No botão + é possível cadastra-los.

42
Figura 9: Tela Cadastro Novo Bumps

Essa é a tela de cadastro de Bumps, para cadastra-lo é preciso preencher o ponto

do destino e a distância necessária para que ele possa despertar.
43
Figura 10: Tela Locais Favoritos

Essa é a tela de locais favoritos, para cadastra-lo basta clicar no botão +.

44
Figura 11: Cadastro Novo Local Favorito

Essa é a tela de cadastro de locais favoritos, para cadastra-lo será necessário

preencher o endereço e o apelido que será utilizado na busca.
45
Figura 12: Tela de Configurações

Essa é a tela de configurações do aplicativo, nela é possível trocar a senha e sair do

software.
46
6. PLANO DE TESTE
6.1.1 - Cadastro de novo usuário.
Identificação do teste:
T01. Cadastro de novo usuário.
Descrição do teste:
Preencher o campo “Nome” com: Richard
Preencher o campo “E-mail” com: rm.ret@uol.com.br
Preencher o campo “Senha” com: 102030
Preencher o campo “Repetição de Senha” com: 102030
Resultado esperado: O sistema apresenta a mensagem “Cadastro criado com

sucesso”.
Registro do caso de teste: Teste de Caixa Preta.
Levantado por: Richard Monaco.
Data: 04/05/2016 a 04/05/2016.
Descrição do resultado obtido: O teste atende conforme o esperado.
6.1.2 - Cadastro de um novo usuário com dados existentes.
T02. Cadastro de um novo usuário com dados existentes.
Preencher o campo “Nome” com: Luiz
Resultado esperado: O sistema apresenta a mensagem “E-mail existente, tente

novamente. ”
47
Data: 04/05/2016 a 04/05/2016.
6.1.3 - Cadastro de usuário com e-mail inválido.
T03. Cadastro de usuário com e-mail inválido.
Preencher o campo “Nome” com: Richard
Preencher o campo “E-mail” com: rm.ret.com.br
Preencher o campo “Repetição de Senha”: 203040
Resultado esperado:
O sistema apresenta a mensagem “E-mail inválido, tente novamente. ”
Data: 05/05/2016 a 05/05/2016.

48
6.1.4 - Cadastro de usuário com senhas não correspondentes.
T04. Cadastro de usuário com senhas não correspondentes.
Preencher o campo ”Nome” com: Richard
Resultado esperado: O sistema apresenta a mensagem “Senhas não

correspondem. ”
Data: 11/05/2016 a 11/05/2016.
Descrição do resultado obtido:

O teste atende conforme o esperado.
6.1.5 - Cadastro de usuário com senha inválida.
T05. Cadastro de usuário com senha inválida.
Preencher o campo ”Nome” com: Richard
Resultado esperado: O sistema apresenta a mensagem ”Senha deve

conter no mínimo 6 caracteres”.

49
Data: 11/05/2016 a 11/05/2016.
6.1.6 - Autenticação com usuário cadastrado.
T06. Autenticação com usuário cadastrado.
Resultado esperado:
O sistema apresenta a mensagem “Usuário autenticado. ”
Programa automaticamente redireciona para a tela inicial do software. ”
Data: 11/05/2016 a 11/05/2016.

50
6.1.7 - Autenticação com usuário inexistente.
T07. Autenticação com usuário inexistente.
Preencher o campo “E-mail” com: rm.ret.uol.com.br
Resultado esperado: O sistema apresenta a mensagem “Usuário ou senha

inválidos”.
Data: 12/05/2016 a 12/05/2016.
6.1.8 - Autenticação com senha incorreta.
T08. Autenticação com senha incorreta.
Preencher o campo “E-mail” com: rm@ret.uol.com.br
Resultado esperado: O sistema apresenta a mensagem “Usuário ou senha

inválidos. ”

51
Data: 12/05/2016 a 12/05/2016.
6.1.9 - Autenticação com conta cadastrada no Facebook.
T09. Autenticação com conta cadastrada no Facebook.
Clicar no botão de “Conectar com Facebook”
Inserir usuário e senha cadastrados através do Facebook.
Preencher o campo “Usuário” com: guilhermekiss@gmail.com
Aceitar a confirmação de compatibilidade do Facebook com o aplicativo.
Resultado esperado:
O sistema apresenta a mensagem “Usuário autenticado”
Programa automaticamente redireciona para a tela inicial do software”
Levantado por: Richard Monaco Ret.
Data: 12/05/2016 a 12/05/2016.

52
6.1.10 - Autenticação com conta inválida do Facebook.
T10. Autenticação com conta inválida do Facebook.
Conectar com a conta do Facebook.
Inserir usuário e senha cadastrados através do Facebook.
Preencher o campo “Usuário” com: guilherme@gmail.com
Resultado esperado:
O sistema apresenta a mensagem “Usuário ou senha inválidos”.
Levantado por: Luiz Guilherme Barbosa Kiss.
Data: 12/05/2016 a 12/05/2016.
6.1.11 - Cadastrar Bumps.
T11. Cadastrar Bumps.
Selecionar a opção “Meus Bumps”.
Selecionar o ícone “+” no canto inferior direito.
Preencher o campo “Endereço” com: Av. Imperatriz Leopoldina, 1000.
Arrastar o botão da esquerda para a direita até a distância de 1 km.
Confirmar a ação clicando no botão de salvar no canto superior direito da tela.
Resultado esperado:
O sistema apresenta a mensagem “Bumps cadastrado com sucesso. ”
O sistema salva o bumps cadastrado como “Av. Imperatriz Leopoldina, 1.000” na tela de
53
“Meus Bumps”.
Data: 25/05/2016 a 25/05/2016.
6.1.12 - Cadastro de Bumps com endereço inválido.
T12. Cadastro de Bumps com endereço inválido.
Preencher o campo “Endereço” com: Av. Cupertino, 550.
Resultado esperado:
O sistema não localiza o endereço solicitado.
Data: 25/05/2016 a 25/05/2016.

54
6.1.13 - Alteração de Bumps com dados já cadastrados, alterando somente a opção

“Repetir Alarme”.
T13. Alteração de Bumps com dados já cadastrados, alterando somente a opção “Repetir
Alarme”.
Selecionar o bumps já cadastrado.
Resultado esperado: O sistema apresenta a mensagem “Bumps alterado com sucesso. ”
Data: 25/05/2016 a 25/05/2016.
6.1.14 - Alteração de Bumps com dados já cadastrados, alterando somente a opção

“Distância”.
T14. Alteração de Bumps com dados já cadastrados, alterando somente a opção
“Distância”.
Selecionar o bumps já cadastrado.
Arrastar o botão da esquerda para a direita até a distância de 0,5 km.
Selecionar o ícone “Salvar” no canto superior direito da tela.
Resultado esperado: O sistema apresenta a mensagem “Bumps alterado com

sucesso”.
55
Data: 25/05/2016 a 25/05/2016.
6.1.15 - Cadastro de Bumps com dados já cadastrados.
T15. Cadastro de Bumps com dados já cadastrados.
Preencher o campo “Endereço” com: Av. Imperatriz Leopoldina, 1000.
Clicar no botão de salvar no canto superior direito da tela.
Resultado esperado: O sistema apresenta a mensagem “Bumps criado com

sucesso”.
Data: 25/05/2016 a 25/05/2016.

56
6.1.16 - Cadastro de alarme.
T16. Cadastro de alarme.
Selecionar a opção “Alarmes”.
Preencher o campo “Origem” com: Av. Jaguaré, 719.
Preencher o campo “Destino” com: Av. Brigadeiro Faria Lima, 3477.
Selecionar a opção carro (clicando na figura de um carro), como meio de transporte.
Selecionar no relógio “Chegar no destino (hr) ” com: 8:00.
Selecionar no relógio “Tempo para sair (min) ” com: 30.
Selecionar no campo “Repetir” com: Todas as quintas-feiras.
Clicar no botão de salvar no canto superior direito da tela “Novo Alarme”.
Resultado esperado: O sistema apresenta a mensagem “Alarme criado com

sucesso”.
Data: 25/05/2016 a 25/05/2016.
6.1.17 - Cadastro de alarme com dados já cadastrados.
T17. Cadastro de alarme com dados já cadastrados.
57
Preencher o campo “Origem” com: Av Jaguaré, 719.
Preencher o campo “Destino” com: Av. Brigadeiro Faria Lima, 3477.
Selecionar no relógio “Chegar no destino (hr)” com: 8:00.
Selecionar no relógio “Tempo para sair(min)” com: 30.
Selecionar no campo “Repetir” com: Todas as quintas-feiras.
Selecionar o ícone “Salvar” no canto superior direito da tela “Novo Alarme”.
Resultado esperado: O sistema apresenta a mensagem “Alarme já cadastrado. ”
Data: 25/05/2016 a 25/05/2016.
6.1.18 - Alteração de alarme já cadastrado, alterando somente a opção “Origem”.
T18. Alteração de alarme já cadastrado, alterando somente a opção “Origem”.
Preencher o campo “Origem” com: Av. Imperatriz Leopoldina, 550.
58
Resultado esperado: O sistema apresenta a mensagem “Alarme alterado com

sucesso”.
Data: 25/05/2016 a 25/05/2016.
6.1.19 - Alteração de alarme cadastrado, alterando somente a opção “Destino. ”
T19.Alteração de alarme cadastrado, alterando somente a opção “Destino. ”
Selecionar o alarme já cadastrado.

Selecionar o ícone de alteração na janela pop-up no canto inferior direito.
Preencher o campo “Destino” com: Av. Imperatriz Leopoldina, 550.

sucesso”.
Data: 25/05/2016 a 25/05/2016.

59
6.1.20 - Alteração de alarme cadastrado, alterando somente a opção “Meio de

Transporte. ”
T20. Alteração de alarme cadastrado, alterando somente a opção “Meio de
Transporte. ”
Selecionar a opção ônibus (clicando o ícone de um ônibus), como meio de
transporte.
Resultado esperado:
O sistema apresenta a mensagem “Alarme alterado com sucesso”.
Data: 25/05/2016 a 25/05/2016.
6.1.21 - Alteração de alarme cadastrado, alterando somente a opção “Chegar no

Destino. ”
T21. Alteração de alarme cadastrado, alterando somente a opção “Chegar no
Destino. ”
60

Selecionar no relógio “Chegar no destino(hr)” com: 16:00.

sucesso”.
Data: 25/05/2016 a 25/05/2016.
6.1.22 - Alteração de alarme cadastrado, alterando somente a opção “Tempo para sair.
”
T22. Alteração de alarme cadastrado, alterando somente a opção “Tempo para sair.
”
Selecionar no relógio “Tempo para sair (min) ” com: 60.

sucesso”.
Data: 25/05/2016 a 25/05/2016.

61
6.1.23 - Alteração de alarme cadastrado, alterando somente a opção “Repetir”.
T23. Alteração de alarme cadastrado, alterando somente a opção “Repetir”.
Selecionar no campo “Repetir” com: Todas as segundas-feiras.
Resultado esperado:
O sistema apresenta a mensagem “Alarme alterado com sucesso”.
Data: 25/05/2016 a 25/05/2016.
6.1.24 - Cadastro de alarme com endereços de origem e destino inválidos.
T24. Cadastro de alarme com endereços de origem e destino inválidos.
Selecionar o ícone“+” no canto inferior direito.
Preencher o campo “Origem” com: Av. Cupertino
Preencher o campo “Destino” com: Av. Rota 66
62
Selecionar o ícone “Salvar” no canto superior direito da tela “Novo Alarme”.
Resultado esperado:
O sistema não localiza o endereço de origem solicitado.
O sistema não localiza o endereço de destino solicitado.

Data: 25/05/2016 a 25/05/2016.
6.1.25 - Cadastro de alarme com endereços de origem e destino idênticos.
T25. Cadastro de alarme com endereços de origem e destino idênticos.
Selecionar o ícone“+” no canto inferior direito.
Preencher o campo “Origem” com: Av. Imperatriz Leopoldina, 1000
Preencher o campo “Destino” com: Av. Imperatriz Leopoldina, 1000
Clicar no botão de salvar no canto superior direito da tela “Novo Alarme”.
Resultado esperado: O sistema apresenta a mensagem “Endereços de Origem e

Destino não podem ser iguais”.
Data: 25/05/2016 a 25/05/2016.
6.1.26 - Alteração total de alarme já cadastrado.

63
T26. Alteração total de alarme já cadastrado.
Selecionar o alarme que deseja alterar.
Origem: Av. Jaguaré, 719.
Destino: Av. Brigadeiro Faria Lima, 3477.
Meio de transporte: Carro.
Alterar “Chegar no destino (hr) ” com: 18:00.
Tempo para sair (min): 60.
Alterar “Repetir” com: Todas as quartas-feiras.
Selecionar o ícone “Salvar” no canto superior direito.

sucesso. ”
Levantado por: Luiz Guilherme Barbosa Kiss
Data: 25/05/2016 a 25/05/2016.
6.1.27 - Consulta de alarme.
T27. Consulta de alarme.
Selecionar o alarme que deseja consultar pelo horário de chegada no destino
previamente cadastrado.
Verificar os dados do alarme selecionado e clicar no ícone “X” para fechar.
Resultado esperado: O sistema apresenta todos os dados do alarme previamente

cadastrado para o usuário.
Data: 25/05/2016 a 25/05/2016.

64
6.1.28 - Cadastro de local favorito.
T28. Cadastro de local favorito.
Selecionar a opção “Locais Favoritos”.
Preencher o campo “Endereço” com: Av. Imperatriz Leopoldina, 1.000.
Preencher o campo “Apelido” para o local favorito cadastrado com: Trabalho.
Verificar o endereço digitado com o mapa localizado na parte inferior da tela “Adição
de Local Favorito”.
Resultado esperado: O sistema apresenta a mensagem “Local Favorito criado com

sucesso”.
Data: 29/05/2016 a 29/05/2016.
6.1.29 - Cadastro de local favorito com endereço inválido.
T29. Cadastro de local favorito com endereço inválido.
65
Clicar na opção “+” no canto inferior direito.
Preencher o campo “Endereço” com: Av Rota 66
Preencher o campo “Apelido” para o local favorito cadastrado com: Escola. Verificar
o endereço digitado com o mapa localizado na parte inferior da tela “Adição de Local
Favorito”.
Resultado esperado: O sistema não localiza o endereço solicitado.
Data: 29/05/2016 a 29/05/2016.
6.1.30 - Cadastro de local favorito com apelido já cadastrado.
T30. Cadastro de local favorito com apelido já cadastrado.
Clicar na opção “+” no canto inferior direito.
Preencher o campo “Endereço” com: Av. Doutor Gastão Vidigal, 1.132.
Preencher o campo “Apelido” para o local favorito cadastrado com: Trabalho.
Verificar o endereço digitado com o mapa localizado na parte inferior da tela “Adição
de Local Favorito”.
Resultado esperado: O sistema apresenta a mensagem “Apelido já cadastrado”.
Data: 29/05/2016 a 29/05/2016.

66
6.1.31 - Consulta de local favorito.
T31. Consulta de local favorito.
Selecionar apelido cadastrado “Trabalho”.
Verificar os dados do local favorito cadastrado e clicar no botão “Salvar”.
Resultado esperado: O sistema apresenta a consulta dos dados cadastrados

através do apelido definido pelo usuário.
Data: 29/05/2016 a 29/05/2016.
6.1.32 - Alteração de senha de usuário.
T32. Alteração de senha de usuário.
67
Selecionar a opção “Configurações”.
Clicar na opção “Trocar senha”.
Preencher o campo “Senha antiga” com: 102030
Preencher o campo “Senha nova” com: 302010
Preencher o campo “Digite novamente a senha nova” com: 302010
Selecionar o ícone “Alterar” no canto inferior direito.
Resultado esperado: O sistema apresenta a mensagem “Alteração efetuada com

sucesso”.
Data: 29/05/2016 a 29/05/2016.
6.1.33 - Alteração de senha de usuário inválida.
T33. Alteração de senha de usuário inválida.
Preencher o campo “Digite novamente nova senha” com: 555123
Resultado esperado:
O sistema apresenta a mensagem “A senha deve conter no mínimo 06 caracteres”.
Data: 29/05/2016 a 29/05/2016.

68
6.1.34 - Alteração de senha de usuário não correspondentes.
T34. Alteração de senha de usuário não correspondentes.
Preencher o campo “Digite novamente nova senha” com: 302020
Resultado esperado: O sistema apresenta a mensagem “As senhas digitadas não

correspondem. ”
Data: 29/05/2016 a 29/05/2016.
6.1.35 - Despertar Bumps cadastrado.
T35. Despertar Bumps cadastrado.
Selecionar o bumps previamente cadastrado.
Para verificar a função despertar bumps, foi realizado o seguinte teste:
69
O bumps foi ativado em locomoção de carro, em uma velocidade média de 40 km/h,

partindo da Rua Guaipá próximo ao número 1.312 sentido a Avenida Imperatriz
Leopoldina, no qual estava localizado o destino.
Ao chegar próximo a estação de trem Imperatriz Leopoldina, foi detectado que o
aplicativo emitiu uma notificação, onde já estava dentro do raio definido pelo bumps.
Após receber a notificação, o bumps foi desativado.
Resultado esperado: O sistema apresentou a mensagem: “Está na hora de

acordar! ”.

Data: 13/10/2016 a 13/10/2016.
Foram realizados 5 testes, onde houve uma variação pequena de distância
(aproximadamente de 3 a 10 metros) do local em que o usuário deveria ser
despertado.
Concluímos também que a variação citada acima ocorre devido a qualidade de sinal
de internet dos dispositivos testados, onde o dispositivo que apresentou um melhor
sinal de internet, foi notificado pelo sistema com mais precisão comparado com
outros dispositivos e também pela velocidade média, por exemplo, o usuário que
estiver se locomovendo com uma velocidade média menor, será despertado com
maior precisão.
6.1.36 - Despertar bumps cadastrado no modo avião.
T36. Despertar bumps cadastrado no modo avião.
Selecionar o Bumps previamente cadastrado.
Com o dispositivo configurado para o “modo avião”, o teste foi realizado da seguinte
forma:
- Ao atravessar o raio definido pelo bumps, exibido na tela do dispositivo, foi
detectado que o dispositivo não o despertou.
- Logo após o sistema notificou que não havia sinal de internet, sendo assim o
motivo de não ter despertado.
Resultado esperado:
O sistema apresentou a mensagem: “Sem conexão com a internet, tente
novamente. ”
Data: 13/10/2016 a 13/10/2016.

70
6.1.37 - Despertar alarme (1º teste).
T37. Despertar alarme (1º teste).
De acordo com os testes feitos do cadastro de alarme exibido no T16, foi
cadastrado o seguinte alarme para esse teste:
- Origem: Rua Milton Soares, 213.
- Destino: Rua Barão de Jundiaí, 523.
- Selecionar a opção “carro” como meio de transporte.
- Selecionar chegada no destino com: 08:00 hrs.
- Selecionar tempo para sair com: 30 min.
- Ativar o alarme selecionando a opção “Salvar”.
Com o alarme ativado as “23:00 hrs” do dia anterior (12/10/2016), foi verificado que
às “06:56 hrs” do dia seguinte (13/10/2016), o dispositivo começou a vibrar emitindo
uma notificação.
- Após receber a notificação, o alarme foi desativado.
- Chegou no local de destino às 07:45 hrs.
Resultado esperado: O sistema apresentou a mensagem: “Está na hora de

acordar! ”
Data: 12/10/2016 a 13/10/2016.
6.1.38 - Despertar alarme (2º teste) - Teste Grande SP
T38. Despertar alarme (2º teste) - Teste Grande SP
71
Teste feito com alarme previamente cadastrado
- Origem: Av Eng Heitor Antonio Eiras Garcia 396.
- Destino: Av Nsa Senhora de Fátima 96, Cotia
- Selecionar tempo para sair com: 30 min.
uma notificação.
- Chegou no local de destino às 08:55 hs
Resultado esperado:
O sistema apresenta a mensagem “Está na hora de acordar! ”
Data: 17/10/2016 a 17/10/2016.
6.1.39 - Despertar alarme cadastrado (3º teste). Litoral/SP
T39. Despertar alarme cadastrado (3º teste). Litoral/SP
Teste feito com alarme previamente cadastrado
- Origem: Av Eng Heitor Antônio Eiras Garcia 396.
- Destino: Av Prestes Maia, 365 - Tombo - Guarujá
- Selecionar tempo para sair com: 01:30 min.
uma notificação.
- Chegou no local de destino às 13:55 hs, trânsito decorrente engavetamento
por acidente na Av Bandeirantes.
72
Resultado esperado:
O sistema apresenta a mensagem “Está na hora de acordar! ”
Data: 21/10/2016 a 22/10/2016.

6.1.40 - Alteração de Alarme cadastrado.
T40. Alteração de Alarme cadastrado.
Selecionar a opção “Meus Alarmes”.
Selecionar o Alarme previamente cadastrado com destino Av Prestes Maia, 365 -
Tombo - Guarujá
O sistema irá abrir uma janela pop-up com todos os detalhes do alarme criado.
Selecionar o ícone editar no canto superior direito
Inserir o endereço de destino: Av Imperatriz Leopoldina, 1066
Resultado esperado:
O sistema apresenta a mensagem “Alarme criado com sucesso. ”
Data: 17/10/2016 a 17/10/2016.
6.1.41 - Exclusão de Alarme cadastrado.
T41. Exclusão de Alarme cadastrado.
Selecionar a opção “Meus Alarmes”.
73
Selecionar o Alarme previamente cadastrado “Avenida Imperatriz Leopoldina,

1.066”.
O sistema irá abrir uma janela pop-up com todos os detalhes do Alarme criado.
Selecionar o ícone de uma “lixeira” no canto inferior direito e confirmar a exclusão
do Alarme selecionado.
Resultado esperado:
O sistema apresenta a mensagem “Alarme excluído com sucesso. ”
Data: 17/10/2016 a 17/10/2016.
6.1.42 - Consumo de bateria - Sistema: Android 6.0 - Dispositivo: Moto G4

Plus.
T42. Consumo de bateria - Sistema: Android 6.0 - Dispositivo: Moto G4 Plus.
Aplicativo instalado e configurado Alarme
- Origem: Av Eng Heitor Antônio Eiras Garcia, 396.
- Destino: Av Nossa Senhora de Fátima 96, Cotia.
- Raio configurado em: 0,8 km.
Percentual de bateria ao sair do local 100%, apenas notificação do aplicativo ligada.
Resultado esperado:
Saída 08:00hs
Chegada 08:40
Gasto da bateria inferior a 5%
Data: 17/11/2016 a 17/11/2016.

74
6.1.43 - Consumo de bateria - Sistema: Android 6.0 - Dispositivo: Asus

ZenFone 2.
T43. Consumo de bateria - Sistema: Android 6.0 - Dispositivo: Asus ZenFone 2.
Aplicativo instalado e configurado Bump
Origem: Rua Paranavaí, 108.
Destino: UMC, Av. Imperatriz Leopoldina.
Raio configurado em 0,5 km.
Locomoção: Automóvel
Percentual de bateria ao sair do local 87%, apenas notificação do aplicativo ligada.
Resultado esperado:
Saída 08:00 hrs.
Chegada 08:33 hrs.
Gasto da bateria inferior a % 4.
Data: 18/11/2016 a 18/11/2016.
6.1.44 - Recuperar senha cadastrada.
T44. Recuperar senha cadastrada.
Na tela de Login, inserir e-mail cadastrado no campo “E-mail do usuário” como:
75
“guilhermekiss@gmail.com”.
Clicar em “Esqueci a senha”.
O sistema enviará uma mensagem no e-mail informado, com um link para o usuário
trocar a senha.
Abrir a mensagem recebida através do e-mail, e clicar no link para trocar a senha.
“Nova senha” como: umcsi2016
Clicar no botão de “Salvar”.
Resultado esperado: O sistema apresenta a seguinte mensagem: “A senha

solicitada foi enviada para o seu e-mail informado”.
Levantado por: Luiz Guilherme Barbosa Kiss
Data: 19/11/2016 a 19/11/2016.
7. CONCLUSÃO
Criamos o Bumps para melhorar o cotidiano do usuário, devido ao número de

carros que não param de crescer no país, provocando congestionamento
principalmente nos horários de picos, em São Paulo por exemplo tudo é muito
imprevisível, pois além do trânsito enfrentamos manifestações, greves, alagamentos,
vias fechadas, então aquele horário esperado para chegar ao compromisso acaba
não sendo cumprido e como hoje utilizamos muito a tecnologia para facilitar nossas
vidas, a cada dia, novas ferramentas e aplicativos são inventados, invadindo o nosso
cotidiano por que não criar algo que nos ajude com este assunto.
A criação do aplicativo foi desafiadora, pois o conhecimento mobile da equipe não

era amplo, com isso descobrimos e analisamos muitas ferramentas que estão no
mercado para facilitar o desenvolvimento do software, além de gratuitas contribuíram
para o nosso conhecimento, principalmente com o armazenamento de banco dados.
O aplicativo foi uma realização acadêmica e pessoal, com muitos desafios propostos
que foram superados com sucesso, principalmente na ideia objetiva do software,
que é levar conforto ao usuário através da tecnologia cotidiana.
76
BIBLIOGRAFIA
MOREIRA, Ardilhes. Frota de veículos cresce 119% em dez anos no Brasil, aponta
Denatran.
Disponível em G1: <http://g1.globo.com/carros/noticia/2011/02/frota-de-
veiculos-cresce-119-em-dez-anos-no-brasil-aponta-denatran.html>. Acesso
em: 17 Out. 2016 22:42:00
Renosto, Raoni. Google Developer Groups .

Disponível em:<http://gdgpatobranco.org/2015/04/21/firebase-introduction/>.
Acesso em 06 Dez. 2016 21:13:00
Vasconcellos, Luis. Cordova

Disponível em: <http://luisvasconcellos.com/2015/04/06/apps-hibridas-com-
cordova-e-ionic.html>. Acesso em 20 de Out. de 2016 13:15:00
Wup. Google Play.

Disponível em:
<https://play.google.com/store/apps/details?id=br.com.wup.wup&hl=pt_BR>.
Acesso em 20 de Nov. de 2016 10:08:00
77

TCC 2016

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

TCC 2016

Caricato da

Copyright:

Formati disponibili

UNIVERSIDADE DE MOGI DAS CRUZES

EVELIN KAREN PEREIRA MOURA DOS SANTOS

DESENVOLVIMENTO DO APLICATIVO DESPERTADOR

UNIVERSIDADE DE MOGI DAS CRUZES

DESENVOLVIMENTO DO APLICATIVO DESPERTADOR

Trabalho de conclusão de curso

Prof.º Orientador: Bruno Hideo Casillo e Maria Rosilene Ferreira

EVELIN KAREN PEREIRA MOURA DOS SANTOS

DESENVOLVIMENTO DO APLICATIVO DESPERTADOR

Trabalho de conclusão de curso

São Paulo, ____ de _____________ de 2016.

Palavras Chave: Aplicativo, dormir e despertar.

Figura 1: Diagrama de caso de uso Error! Bookmark not defined.

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface

BAAS Backend as a Service

BSON Binario Object Notation

CSS Cacading Style Sheet

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

IBGE Instituto Brasileiro de Geografia e Estatística

JSON JavaScript Object Notation

REST Representational State Transfer

SDK Software Development Kit

SGBD Sistema de Gerenciamento de Banco de Dados

SQL Structured Query Language

UML Unified Modeling Language

XML Extensible Markup Language

4.2.6 UC06 Cadastrar Alarme 31

Todos os dias, nós brasileiros, sofremos com o trânsito existente em nossas

No caso para aqueles que utilizam o transporte público ou fretamento, devido

Atualmente, só existe uma única solução no mercado com a função

O objetivo deste trabalho é desenvolver um aplicativo capaz de despertar o

Além disso, fornece a possibilidade de que o usuário seja notificado quando

De acordo com o balanço do Departamento Nacional de Trânsito (DENATRAN),

Hoje, existem duas soluções encontradas no mercado voltadas para esse

E o aplicativo WAZE que em sua última atualização adicionou a função de

Pensando nisso, esse estudo desenvolveu um aplicativo multi-plataforma

A metodologia adotada para o desenvolvimento do aplicativo é composta das

A primeira etapa contempla todas as pesquisas bibliográficas relativas ao

A segunda etapa foi baseada no entendimento do resultado proveniente da

A quarta etapa teve como objetivo o desenvolvimento do sistema com base

A quinta etapa foi baseada no modelo definido na terceira etapa

1.4 ESTRUTURA DO TRABALHO

● Capítulo 2 – Visão Geral do Sistema - Apresenta a ideia geral do sistema

● Capítulo 4 – Modelagem - Apresenta os modelos que explicam as

2. VISÃO GERAL DO SISTEMA

O aplicativo propõe melhor maneira de administrar recursos e ainda cuidar da

O primeiro passo para usufruir adequadamente desta funcionalidade começa

Após ter os quatro parâmetros acima definidos a configuração da notificação

O primeiro passo para usufruir adequadamente desta funcionalidade começa

Será exibida na tela, uma representação digital do ambiente que a ONG de

2.2 DESENVOLVIMENTO HÍBRIDO

Uma mobile app nativa é aquela desenvolvida com as linguagens padrão da

Webview é o nome dado a um tipo diferenciado de browser que começa a ser

2.2.2 APPS HÍBRIDOS X APPS NATIVOS

A principal limitação de uma app híbrida se dá em termos de desempenho e

Atualmente o desenvolvimento híbrido possui duas plataformas principais, o

2.3 BANCO DE DADOS ORIENTADO A DOCUMENTO

bancos de dados relacionais. Os bancos de dados NoSQL geralmente seguem os

O armazenamento do tipo chave/valor é semelhante ao uso de mapas ou de

2.3.2 ORIENTADO A COLUNAS

Um SGBD orientado a colunas armazena seu conteúdo de forma inversa aos

São Paulo, de _________ de 2016.