Uma Aplicação Mobile para Notificação de Acidentes Por

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA
DO AMAZONAS
DEPARTAMENTO DE ENSINO SUPERIOR
CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO
DE SISTEMAS
Patrick Tapajós Pinto
UMA APLICAÇÃO MOBILE PARA NOTIFICAÇÃO DE ACIDENTES POR

ARRAIAS
Manaus, Amazonas
Outubro, 2016
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA
DO AMAZONAS
Patrick Tapajós Pinto
UMA APLICAÇÃO MOBILE PARA NOTIFICAÇÃO DE ACIDENTES POR

ARRAIAS
Trabalho de Conclusão de Curso

apresentado à banca examinadora do
Curso Superior de Tecnologia em Análise
e Desenvolvimento de Sistemas do
Instituto Federal de Educação, Ciências e
Tecnologia do Amazonas (IFAM), Campus
Manaus Centro, como requisito para a
conclusão de curso.
Profª. Dra. Andréa Pereira

Mendonça - IFAM
Profª. Dra. Maria Cristina dos
Santos - UFAM
(Orientadoras)
Manaus – Amazonas
Outubro, 2016
UMA APLICAÇÃO MOBILE PARA NOTIFICAÇÃO DE ACIDENTES
POR ARRAIAS
BANCA EXAMINADORA
Profª. Drª. Andréa Pereira Mendonça

(Orientadora Acadêmica)
Profª Mª. Joyce Miranda dos Santos

(Instituto Federal de Educação, Ciência e Tecnologia do Amazonas)
Prof. Dr. Jucimar Brito de Souza

(Instituto Federal de Educação, Ciência e Tecnologia do Amazonas)
Manaus, 2016
Dedicatória
Dedico à minha família, amigos e professores
Agradecimentos
Primeiramente a Deus, por me dar a capacidade necessária para realizar

este trabalho e ter me presentado com pessoas muito especiais ao longo da vida.
À minha família, por me dar o apoio e confiança necessários em minhas
escolhas e em todas as minhas realizações. É por minha família toda a luta diária,
em especial por meus pais, que sempre se doaram por mim, fazendo o possível e o
impossível para que eu pudesse ser tudo o que sou. Agradeço por todas as vezes
em que precisei me ausentar da minha obrigação como filho para realizar o que
quer que seja.
Aos professores que compõem a banca examinadora, obrigado pela
disponibilidade em avaliar este trabalho. À professora Andrea Mendonça, por me dar
a oportunidade de realizar este projeto, por acreditar na minha capacidade e pelos
bons debates. Obrigado pelos conselhos, dicas e puxões de orelha. Aprendi
bastante e espero que esse seja o primeiro de muitos trabalhos juntos. E à
professora Maria Cristina dos Santos, idealizadora desse projeto, por perceber a
necessidade de melhoria do sistema e por auxiliar na elicitação dos requisitos.
Aos amigos e colegas de trabalho que me acompanharam no
desenvolvimento deste trabalho, pelas boas conversas sobre qualquer coisa
engraçada o suficiente para distrair de um dia estressante de labuta. Em especial ao
amigo Nilson Neto, que me auxiliou bastante no meu aprendizado para este
trabalho, sem ele o início desta caminhada seria mais difícil; e ao amigo Mackesy
Nascimento, por me auxiliar na parte de design da aplicação.
E às pessoas que foram simpáticas comigo em qualquer situação da vida.
RESUMO
Animais peçonhentos são aqueles capazes de inocular veneno em sua vítima,

causando acidentes que podem levar ao óbito. Dentre estes animais estão as
arraias, que, apesar de serem dóceis, causam acidentes que deixam suas vítimas
incapacitadas e afastadas do trabalho por algum tempo, muitas vezes deixando-as
com sequelas, e por isso representam um problema de saúde pública nos locais
onde habitam. No Brasil, os sistemas que catalogam os acidentes envolvendo
animais peçonhentos dão maior ênfase a aracnídeos, serpentes e escorpiões, com
pouca informação direcionada às arraias. Em relação à notificação de acidentes por
arraias no estado do Amazonas, uma contribuição foi realizada por meio do
desenvolvimento de um sistema web denominado SNAA (Sistema de Notificação de
Acidentes por Arraias). No presente trabalho é apresentado uma extensão deste
sistema, na qual são incluídas funcionalidades que possibilitam as notificações dos
acidentes por dispositivos móveis e em condições offline. Esta aplicação é
denominada SNAA mobile e foi desenvolvida para plataforma Android,
implementada com utilização da tecnologia JAVA, e guiada pelo AUP (Agile Unified
Process). O SNAA mobile provê recursos como cadastro de dados da vítima, da
geolocalização do acidente, de dados clínicos (local da picada, sintomas, etc.), bem
como de dados de tratamento (medicamentos, exames, etc.), permitindo a
notificação dos acidentes tanto em condições online quanto offline.
Palavras-chave: Animais peçonhentos, Arraias, Sistema de notificação offline, Aplicação

mobile, SNAA mobile.
ABSTRACT
Poisonous animals are those able to inoculate venom into its victim, causing
accidents that can lead to death. Among these animals there are the stingrays which,
despite being docile, cause accidents that leave their victims incapacitated and with
the need of some time absent from work, often leaving them with sequelae.
Therefore, these animals represent a public health problem in the places where they
live. In Brazil, the systems that catalogue accidents involving venomous animals give
greater emphasis to arachnids, snakes and scorpions, with little information related
to stingrays. Regarding the notification of accidents caused by stingrays in the state
of Amazonas, a contribution was made through the development of a web system
called SNAA (Sistema de Notificação de Acidentes por Arraias, in english Accident
Reporting System for Stingrays). In this work, we present an extension of this
system, in which are included features that enable the reporting of accidents through
mobile devices and offline conditions. This application is called SNAA Mobile and it
was developed for Android platform, using the JAVA technology, and guided by the
AUP (Agile Unified Process). The SNAA Mobile provides features such as the
victim's data register, the geolocation of the accident, clinical data (bite location,
symptoms, etc.) and treatment data (drugs, tests, etc.), allowing the notification of
accidents in both online and offline conditions.
Keywords: Poisonous animals, Stingrays, Offline notification system, Mobile application,

SNAA mobile.
LISTA DE FIGURAS
Figura 1 – Fluxo do SNAA..........................................................................................10

Figura 2 - Processos de identificação de mudanças e evolução...............................14
Figura 3 - Processo de evolução do software............................................................15
Figura 4 - Participação de tecnologias móveis no mercado......................................21
Figura 5 - Ciclo de vida do AUP..................................................................................24
Figura 6 - Arquitetura da plataforma Android.............................................................30
Figura 7 – Ciclo de vida de uma atividade.................................................................35
Figura 8 - Fluxo de notificação de acidente...............................................................40
Figura 9 - Esquema de troca de dados entre a aplicação mobile e o SNAA.............42
Figura 10 - Diagrama de pacotes do SNAA (web e mobile)......................................42
Figura 11 - Diagrama de caso de uso do módulo de notificação...............................44
Figura 12 - Diagrama de máquina de estados do SNAA mobile...............................46
Figura 13 - Diagrama de sequência da sincronização de dados...............................48
Figura 14 – Tela de login............................................................................................51
Figura 15 - Tela de navegação...................................................................................51
Figura 16 - Tela de pesquisar vítima..........................................................................52
Figura 17 - Tela de histórico de acidentes..................................................................52
Figura 18 - Tela de notificação - dados da vítima......................................................53
Figura 19 - Tela de notificação – dados do acidente..................................................53
Figura 20 - Tela de notificação - imagens..................................................................54
Figura 21 - Tela de notificação – dados clínicos........................................................54
Figura 22 - Tela de notificação – tratamento..............................................................55
Figura 23 - Tela de notificação – conclusão...............................................................55
Figura 24- MVP no SNAA mobile...............................................................................57
Figura 25 – Diagrama de classes na visão de análise..............................................59
Figura 26 – Diagrama de classes na visão de projeto...............................................60
Figura 27 – Diagrama de entidade relacionamento...................................................61
Figura 28 – Execução de thread para login na aplicação..........................................67
Figura 29 – Exemplo de permissões solicitadas........................................................68
Figura 30 – Permissões do SNAA mobile..................................................................68
Figura 31 – Estrutura de pastas com a utilização de qualificadores.........................72
Figura 32 – Exemplo de telas com qualificadores.....................................................72
Figura 33 – Ajuste de imagens...................................................................................74
Figura 34 – Transformação de imagem em bytes e vice-versa.................................75
Figura 35 – Verificação de disponibilidade de GPS...................................................77
Figura 36 – Captura de coordenadas.........................................................................77
Figura 37 – Ciclo de vida do broadcast de sinal de Internet......................................79
Figura 38 – Método principal da classe de sincronização.........................................80
Figura 39 – Consulta de notificações para sincronização.........................................81
Figura 40 – Módulo de serviços mobile......................................................................83
Figura 41 – Serviço de processamento de notificações do web service...................84
Figura 42 – Configuração de formatação json...........................................................85
Figura 43 – Trigger para inserção de vítima...............................................................87
Figura 44 – Ambiente de gerenciamento de aplicações Android...............................88
Figura 45 - Tela de login...........................................................................................103
Figura 46 – Tela de navegação................................................................................103
Figura 47 - Tela de pesquisar vítima........................................................................104
Figura 48 - Tela de histórico de notificações............................................................104
Figura 49 - Tela de notificação – dados da vítima....................................................104
Figura 50 - Tela de notificação - dados do acidente................................................104
Figura 51 - Tela de notificação– dados clínicos.......................................................105
Figura 52 - Tela de notificação – dados de tratamento............................................105
Figura 53 - Tela de notificação – concluir.................................................................105
LISTA DE QUADROS
Quadro 1 - Perfil de acesso e módulos do SNAA........................................................9

Quadro 2 - Comparação sobre a abordagem de desenvolvimento de aplicações
mobile.........................................................................................................................20
Quadro 3 - Artefatos produzidos durante a execução do processo...........................26
Quadro 4 - Diagramas da UML..................................................................................27
Quadro 5 – Releases do SNAA mobile......................................................................65
Quadro 6 – Qualificadores de configuração...............................................................71
Quadro 7 - Caso de Uso CDU – 01 – Pesquisar vítima.............................................94
Quadro 8 - Caso de Uso CDU 02 – Cadastrar Vítima...............................................95
Quadro 9 - Caso de Uso CDU 02 – Cadastrar Acidente............................................96
Quadro 10 - Caso de Uso CDU 03 – Cadastrar Imagens..........................................97
Quadro 11 - Caso de Uso CDU 04 – Cadastrar Dados Clínicos...............................98
Quadro 12 - Caso de Uso CDU 05 – Cadastrar Tratamento.....................................99
Quadro 13 - Caso de Uso CDU 06 – Concluir Notificação......................................100
Quadro 14 - Caso de Uso CDU 07 – Editar Notificação..........................................101
Quadro 15 - Caso de Uso CDU 08 – Reativar Notificação......................................102
Quadro 16 – Responsabilidade de classes..............................................................106
SUMÁRIO
Capítulo 1.....................................................................................................................1
Introdução.....................................................................................................................1
1.1 Objetivo...............................................................................................................3
Capítulo 2.....................................................................................................................5
Fundamentação Teórica...............................................................................................5
2.1 Acidentes por arraias e sua notificação..............................................................5
2.2 O Sistema de Notificação de Acidentes por Arraias (SNAA)..............................7
2.2.1 Fluxo do SNAA...............................................................................................10
2.2.2 Tecnologias utilizadas na construção do SNAA............................................11
2.2.3 Limitações do SNAA......................................................................................12
2.3 Evolução/Manutenção de Software..................................................................13
2.4 Desenvolvimento de Aplicações para Dispositivos Móveis..............................16
Capítulo 3...................................................................................................................23
Processo e Tecnologias utilizados no Desenvolvimento do SNAA Mobile................23
3.1 AUP (Agile Unified Process)............................................................................23
3.2 UML - Unified Modeling Language....................................................................27
3.3 Android..............................................................................................................28
3.3.1 Arquitetura......................................................................................................29
3.3.1.1 Applications.................................................................................................30
3.3.1.2 Application Framework................................................................................30
3.3.1.3 Libraries.......................................................................................................31
3.3.1.3.1 SQLite......................................................................................................32
3.3.1.4 Runtime.......................................................................................................32
3.3.1.5 Linux Kernel................................................................................................32
3.3.2 Componentes de aplicativo Android..............................................................33
3.3.3 Ciclo de vida de uma atividade (Activity).......................................................34

3.4 REST.................................................................................................................36
3.5 Web Services....................................................................................................37
Capítulo 4...................................................................................................................38
SNAA Mobile...............................................................................................................38
4.1 Solicitação de mudança....................................................................................38
4.1.1 Descrição geral do SNAA mobile (escopo)....................................................40
4.1.2 Módulo de notificação....................................................................................43
4.1.3 Módulo de sincronização...............................................................................45
4.1.4 Interfaces do usuário......................................................................................50
4.1.5 Arquitetura......................................................................................................56
4.1.6 Diagrama de classes......................................................................................58
4.1.7 Diagrama Entidade Relacionamento (DER)..................................................61
4.2 Análise de impacto............................................................................................62
4.3 Atividade de planejamento de versões.............................................................63
4.4 Implementação de mudanças...........................................................................65
4.4.1 Implementação do SNAA mobile...................................................................66
4.4.1.1 Versão do SDK............................................................................................66
4.4.1.2 Permissões..................................................................................................67
4.4.1.3 Layouts para múltiplas telas.......................................................................69
4.4.1.4 Tratamento de imagens..............................................................................73
4.4.1.5 Geolocalização............................................................................................75
4.4.1.6 Envio e recebimento de dados...................................................................78
4.4.2 Implementação de mudanças no SNAA........................................................83
4.4.2.1 Módulo de serviços mobile.........................................................................83
4.4.2.2 Banco de dados..........................................................................................86
4.5. Implantação......................................................................................................87
Considerações Finais.................................................................................................89
Revisão Bibliográfica..................................................................................................91
Apêndice A – Especificação de Casos de Uso do Módulo de Notificação................94
Apêndice B – Interfaces do usuário (protótipos iniciais)..........................................103
Apêndice C – Responsabilidades de classes..........................................................106

1
Capítulo 1
Introdução
Animais peçonhentos são aqueles que apresentam veneno e algum tipo de

mecanismo que possibilita a inoculação desse veneno em outro organismo (SBH,
2008), algumas vezes responsáveis por acidentes que podem evoluir ao óbito
(DORNELES, 2009). São exemplos deste tipo de animal as serpentes, escorpiões,
aranhas, lagartas, abelhas, sapos, peixes, dentre outros. Dentre os principais peixes
peçonhentos estão as arraias, que, apesar de não serem agressivas, causam um
grande número de acidentes nas regiões que habitam (LAMEIRAS et al., 2013).
No Brasil existem registros de acidentes com arraias nas bacias dos rios
Paraná, Paraguai e Araguaia, localizadas nas regiões Centro-Oeste e Sudeste
(HADDAD JR., 2003), porém são mais comuns na floresta Amazônica, região Norte
(LAMEIRAS et al., 2013). No Amazonas, por exemplo, segundo dados do
BUTANTAN (2009), os casos envolvendo arraias estão no topo do ranking de
acidentes por animais peçonhentos, junto com outros animais perigosos
(GUALBERTO, 2014), como serpentes e aranhas. Geralmente os acidentes por
arraias ocorrem quando elas são acidentalmente pisadas ou têm suas nadadeiras
tocadas, fazendo-as girar o corpo em comportamento defensivo, movimentando a
cauda rapidamente e introduzindo o ferrão na vítima, causando um ferimento ou
laceração irregular (MAGALHÃES et al, 2006).
Apesar da baixa letalidade e alta morbidade, acidentes envolvendo este tipo de
animal merecem atenção, uma vez que a vítima fica incapacitada e afastada do
trabalho por semanas ou mesmo meses, além de poder ficar com sequelas
(HADDAD JR, 2003). Em consequência disto tais acidentes constituem um
importante problema de saúde pública, embora não recebam a mesma atenção
dispensada aos casos de ofidismo (mal causado pela mordida ou picada de
serpentes) e casos envolvendo artrópodes peçonhentos, como aranhas, escorpiões
e lagartas (SÁ-OLIVEIRA et al.,2011).
Nos estados e municípios brasileiros o monitoramento e catalogação dos
casos de acidentes causados por animais peçonhentos vêm sendo continuamente
registrados pelo Sistema de Informação de Agravos de Notificação (SINAN), da
Secretaria de Vigilância em Saúde do Ministério da Saúde, sendo que a maior
2
ênfase de notificação está relacionada aos acidentes causados por serpentes,

escorpiões e aranhas (GUALBERTO, 2014). Os acidentes por arraias são
geralmente subnotificados nos programas de epidemiologia das Unidades
Municipais de Saúde como se esses animais não fossem peçonhentos (SÁ-
OLIVEIRA et al., 2011).
HADDAD JR (2013) comenta que, uma vez que estes acidentes tendem a
ocorrer em áreas remotas, são normalmente negligenciados, não declarados e
tratados com medicina popular, pois os pacientes acidentados geralmente procuram
os serviços de saúde para atendimento apenas quando os ferimentos apresentam
complicações. Além disso, a documentação detalhada destes acidentes é rara, dado
que, na maioria das vezes, ocorrem em lugares distantes e isolados, como a floresta
Amazônica, contribuindo para a falta de conhecimento sobre o assunto (HADDAD
JR. et al., 2004). A informação disponível sobre este problema é baseado em busca
ativa de casos ou registros médicos incompletos das unidades de saúde da região
Norte, com restrições inerentes relativas aos métodos de coleta de dados (HADDAD
JR, 2013).
Uma contribuição para minimizar a falta de notificação de acidentes por
arraias ocorridos no estado do Amazonas foi proposta por GUALBERTO (2014), que
desenvolveu um sistema web denominado SNAA (Sistema de Notificação de
Acidentes por Arraias), com a finalidade de permitir que a comunidade em geral e,
em específico os profissionais de saúde, notifiquem os acidentes envolvendo estes
animais. Este sistema provê recursos para identificação da vítima, localidade
geográfica da ocorrência, identificação do animal causador por meio de imagem,
bem como informação sobre os procedimentos adotados no tratamento. Com base
nessas informações o sistema também disponibiliza um conjunto de relatórios com
dados estatísticos que poderão subsidiar estudos epidemiológicos, pesquisas de
ocorrência e gravidade destes acidentes (GUALBERTO, 2014).
O SNAA representa um avanço no sentido de minimizar o problema da falta de
notificações no estado do Amazonas, tendo em vista a forma de obtenção de dados
sobre estes acidentes, geralmente feitos por formulários de papel impresso e sem
abordagem direta às arraias. Contudo, ainda há algumas demandas, em relação à
utilização deste sistema por profissionais de saúde, que precisam ser supridas. Uma
delas diz respeito à criação de recursos que permitam a notificação de acidentes por
arraias utilizando equipamentos móveis, tais como tablets e smartphones, com
3
operacionalidade online, como é feito atualmente no SNAA, e também offline, dada

a instabilidade de conexão à Internet em muitos municípios do Brasil, em particular
na região Norte. Tendo em vista esse cenário, um suporte à notificação e também
acesso à informações destas notificações de maneira offline podem auxiliar o
trabalho dos profissionais em áreas com dificuldade de acesso à redes.
Outra demanda envolvendo auxílio de equipamentos móveis diz respeito à
geolocalização da ocorrência do acidente. A maioria destes equipamentos já vem
equipada com essa tecnologia, sem nenhum custo adicional, e possibilitam sua
captura tendo uma conexão com a Internet (online) ou não (offline). A
geolocalização consiste em determinar as coordenadas geográficas (latitude e
longitude) de um ponto (pessoa, coisa ou lugar) no planeta. Uma vez que o ponto foi
localizado, esta informação pode ser reutilizada para se obter mais informações
sobre a área ao seu redor e também informações sobre outros pontos próximos
como empresas ou até mesmo outras pessoas (AIRES & HAHN, 2014). Em relação
às notificações, a geolocalização pode garantir precisão no conhecimento e
consolidação de um histórico sobre acidentes com arraias, além da distribuição
geográfica das espécies de arraias presentes no país, auxiliando biólogos e outros
estudiosos da área (GUALBERTO, 2014).
1.1 Objetivo
Com o propósito de atender as demandas acima citadas, este trabalho teve o

objetivo de disponibilizar, e integrar ao SNAA, uma aplicação mobile – denominada
SNAA mobile - direcionada aos profissionais de saúde para permitir a notificação
online e offline de acidentes por arraias ocorridos na região Norte do Brasil. Esta
aplicação foi desenvolvida utilizando a plataforma Android (e suas bibliotecas),
guiada por um processo de desenvolvimento denominado AUP (Processo unificado
ágil) e um processo de evolução/manutenção, e provê recursos como cadastro de
dados da vítima, da geolocalização do acidente, de dados clínicos (local da picada,
sintomas, etc), bem como de dados do tratamento (medicamentos, exames, etc).
Para prover melhor entendimento sobre a aplicação desenvolvida, este
documento foi organizado em cinco capítulos. Nos capítulos 2 e 3 são
apresentados, respectivamente, a fundamentação teórica referente à problemática
que motivou o desenvolvimento do SNAA mobile, e os aspectos tecnológicos
4
considerados no desenvolvimento desta aplicação. O Capítulo 4 destina-se a

apresentação da modelagem e implementação do SNAA Mobile e, em sequência,
são apresentadas as considerações finais e trabalhos futuros.
5
Capítulo 2
Fundamentação Teórica
Neste capítulo são apresentados os conceitos que fundamentam este

trabalho. Primeiramente serão apresentados os acidentes envolvendo arraias e a
situação da notificação destes acidentes em território brasileiro. Em seguida, o
sistema SNAA será explorado, mostrando algumas de suas características e
arquitetura (a apresentação deste sistema se faz necessária para fundamentar o
leitor para o entendimento da aplicação mobile apresentada no Capítulo 4). Na
sequência, serão apresentados alguns conceitos relativos à manutenção/evolução
de software e sua relação com este trabalho. Por fim, será abordado o
desenvolvimento de aplicações para dispositivos móveis.
2.1 Acidentes por arraias e sua notificação
Raias, arraias ou peixes batoides são peixes cartilaginosos, arredondados e

achatados dorsoventralmente, que possuem guelras na parte ventral do corpo,
caudas em forma de chicote com farpas, geralmente com espinhos venenosos, e
que são encontrados em todo o mundo, especialmente as espécies marinhas
(HADDAD JR et al., 2013). Pertencem à classe Chondrichthyes (peixes que
possuem o esqueleto formado por tecido cartilaginoso), subclasse Elasmobranchii
(que agrupa também os tubarões), superordem Batoidea e ordem Myliobatiformes
(LAMEIRAS et al. 2013), ordem esta que possui maior importância médica, pois
compreende as "arraias de ferrão", cuja característica principal da maioria das 180
espécies é possuir ferrões retrosserilhados na porção dorsal da cauda
(GUALBERTO, 2014).
No Brasil, as arraias marinhas estão distribuídas por toda a costa do Oceano
Atlântico, e as espécies de água doce, da família Potamotrygonidae, estão
presentes nos rios das regiões Norte, Centro-Oeste, Sul e Sudeste (CARVALHO et
al., 2003). Espécies da família Potamotrygonidae são membros bem conhecidos da
fauna de peixes neotropicais, mais pelos ferimentos que podem causar do que por
suas propriedades biológicas ou pela história evolutiva intrigante (SILVA &
CARVALHO, 2011).
6
Apesar de arraias serem consideradas animais dóceis, os acidentes são

muito comuns entre pescadores do litoral e na região do Pantanal. Existem registros
de acidentes nas bacias dos rios Paraná, Paraguai e Araguaia (HADDAD JR.,
2003), porém, são mais comuns na bacia Amazônica (LAMEIRAS et al. 2013), onde
constituem um importante problema de saúde pública. Pelo hábito de se manterem
no fundo arenoso ou lodoso das praias, podem ser inadvertidamente pisoteadas por
banhistas. Os acidentes ocorrem quando a região dorsal da arraia é tocada ou
pressionada, o que provoca uma resposta muscular com flexão da cauda para cima
“apontando” o ferrão para o local estimulado, atingindo geralmente o tornozelo ou pé
da vítima. O golpe pode ser de tal intensidade que pode perfurar inclusive calçados.
Também podem acontecer acidentes quando as arraias são manipuladas
propositalmente, por exemplo, ao retirá-las de anzóis, redes, tarrafas ou espinhéis
(PARANÁ, 2012).
De modo diferente com o que ocorreu com os sistemas de notificação
implantados para o dimensionamento dos acidentes ofídicos e, posteriormente, para
os casos de araneísmo e escorpionismo, o estudo dos acidentes provocados por
animais aquáticos sempre foi relegado a um segundo plano, negligenciado pelos
órgãos responsáveis pelo conhecimento, controle e prevenção de agravos
envolvendo animais peçonhentos (GARRONE NETO & HADDAD JUNIOR, 2009).
Acidentes por arraias são geralmente subnotificados nos programas de
epidemiologia das Unidades Municipais de Saúde do país como se esses animais
não fossem peçonhentos (SÁ-OLIVEIRA et al., 2011). Os acidentes são temidos
pela população, pois estão geralmente associados a casos de incapacidade física
temporária ou permanente.
A documentação detalhada desses acidentes é rara, pois, na maioria das
vezes, ocorrem em lugares distantes e isolados, como na floresta Amazônica,
contribuindo para a falta de conhecimento sobre o assunto (HADDAD JR. et al.,
2004). Devido ao pequeno número reportado de casos, não existe uma justificativa
estatística para a produção de um antiveneno específico. Daí a importância dos
estudos epidemiológicos, da notificação dos casos, da divulgação de medidas
profiláticas e de programas educativos junto às populações de risco que possam
prevenir e reduzir o número de acidentes por arraias no Brasil (LAMEIRAS et al,
2013). Além disso, as autoridades de Saúde Pública devem adotar medidas que
estimulem a qualificação adequada aos profissionais de saúde para o atendimento e
7
tratamento de acidentados por arraias e estudos que viabilizem a produção de

imunobiológicos que neutralizem os venenos das arraias existentes no país (SÁ-
OLIVEIRA et al.,2011).
Através da investigação da ficha de notificação individual de acidentes por
animais peçonhentos, disponibilizada pelo Sistema de Informação de Agravos de
Notificação (SINAN), é possível verificar uma seção denominada ‘Dados do
acidente’, no qual deve-se preencher informações sobre o tipo de acidente,
oferecendo opções para diversos tipos de acidentes: por exemplo serpentes,
aranhas e lagartas. No entanto, não oferece opções para preenchimento de
informações específicas de acidentes causados por arraias (GUALBERTO, 2014).
GUALBERTO (2014) também comenta que no site do DATASUS 1
(Departamento de Informática do SUS) é fornecida uma consulta aos dados
estatísticos das notificações registradas no SINAN, oferecendo alguns filtros para a
consulta do tipo de acidente. Dentre eles, existem as opções: Todas as categorias,
Em Branco, Serpente, Aranha, Escorpião e Lagarta. Não há categoria para arraias.
A situação acima citada evidencia o problema da falta de espaço para a
notificação dos acidentes envolvendo arraias, o que dificulta bastante os estudos
epidemiológicos acerca destes agravos. Isso motivou a criação de um sistema web,
denominado SNAA (Sistema de Notificação de Acidentes por Arraias), com a
finalidade de possibilitar que a comunidade em geral e os profissionais de saúde
notifiquem os acidentes por arraias ocorridos no estado do Amazonas. O SNAA será
explorado na seção a seguir.
2.2 O Sistema de Notificação de Acidentes por Arraias (SNAA)
O Sistema de Notificação de Acidentes por Arraias (SNAA) é o produto de um

trabalho realizado por Gualberto (2014), com o objetivo de minimizar o problema da
falta de notificação de acidentes causados por arraias no estado do Amazonas.
Trata-se de um sistema web, disponibilizado aos profissionais de saúde e à
comunidade em geral, que provê recursos para notificar estes acidentes, tais como,
a identificação da arraia causadora, da localidade geográfica de ocorrência do
1 Disponível em http://dtr2004.saude.gov.br/sinanweb/tabnet/dh?
sinannet/animaisp/bases/animaisbrnet.def
8
acidente, bem como os procedimentos adotados no tratamento, entre outros

recursos.
As funcionalidades deste sistema estão divididas nos quatro módulos que o
compõem. São eles:
● Módulo de gerenciamento: disponibiliza as funcionalidades de cadastro e

gerenciamento de contas de usuário, bem como manutenção de cadastros
básicos do sistema;
● Módulo de notificação e acompanhamento de acidentes por unidade de
saúde: disponibiliza, aos profissionais de saúde vinculados a uma unidade
de saúde, as funcionalidades de pesquisar e registrar notificações de
acidentes por arraias, possibilitando-lhes o registro de prontuário e
procedimentos de tratamentos do paciente que sofreu o acidente;
● Módulo de notificação de acidentes não-oficiais: disponibiliza ao público
em geral recursos para a notificação de acidentes que, por algum motivo, não
foram notificados por nenhum órgão de saúde;
● Módulo de consultas e geração de relatórios de acidentes: disponibiliza
consultas e emissão de relatórios dos acidentes por arraias ocorridos no
estado do Amazonas e registrados no sistema, sejam eles notificados por
alguma unidade de saúde ou pelo público em geral.
Para interagir com o sistema são oferecidos os seguintes perfis de acesso:

administrador, representante de unidade de saúde (U.S), profissional de saúde e
público.
O administrador é o responsável pelo módulo de gerenciamento do sistema,
no qual é possível manter os cadastros básicos, necessários para o correto
funcionamento dos outros módulos do sistema. É responsável também por criar
contas de usuário, ativar ou desativar um usuário cadastrado e validar as
solicitações para criação de conta de um representante de unidade de saúde ou de
outro administrador, através de um formulário online, disponível no sistema.
O usuário com perfil de representante de unidade de saúde é responsável por
gerenciar as contas de profissionais de saúde que estão vinculados à unidade de
saúde ao qual ele é o responsável. A principal funcionalidade utilizada por este
usuário é a criação das contas de usuário para os profissionais de saúde. Para este
9
perfil é obrigatória a criação de uma conta de usuário, a qual será solicitada por
meio do preenchimento de um formulário, disponível no sistema.
O usuário com perfil de profissional de saúde, por sua vez, registra
informações sobre acidentes, tais como, a identificação do paciente, identificação
dos dados do acidente e da arraia que causou o agravo, bem como as opções de
cadastro de prontuário e tratamento do paciente. Para este perfil é obrigatória a
criação de uma conta de usuário no sistema, a qual será criada e mantida pelo
representante de sua unidade de saúde.
Para o perfil público será disponibilizada a opção de notificar acidentes não-
oficiais. Neste caso, a notificação é semelhante à realizada pelo profissional de
saúde: é disponibilizado um formulário para cadastro da notificação do acidente,
porém sem as opções para registro de prontuário e tratamento do paciente. Cabe
salientar que, para este perfil, não há necessidade de criação de uma conta no
sistema.
Os perfis de acesso e sua relação com os módulos do SNAA são apresentados
no Quadro 1.
Quadro 1 - Perfil de acesso e módulos do SNAA.
Módulo de Gerenciamento / Módulo de

Consulta e Relatório
Módulo de Gerenciamento / Módulo de

Consulta e Relatório
Módulo de notificação e acompanhamento

de acidentes por unidade de saúde /
Módulo de Consulta e Relatório
Módulo de notificação de acidentes não-

oficiais / Módulo de Consulta e Relatório
Fonte: Próprio autor.

10
As ocorrências registradas pelos profissionais da saúde compõem a base de

dados de acidentes notificados por unidades de saúde. Estes dados serão
utilizados, por exemplo, para a geração de dados estatísticos de acidentes, os quais
serão disponibilizados ao público em geral. As notificações cadastradas pelo público
em geral serão categorizadas como acidentes não-oficiais que, embora sem
comprovação, deverão ajudar na construção de um histórico destes acidentes no
estado do Amazonas. Neste caso, a veracidade dos fatos precisa ser apurada com
o devido acompanhamento.
2.2.1 Fluxo do SNAA
Para um melhor entendimento do processo de notificação de um acidente, é

necessário que se compreenda como ocorre a interação entre os elementos que
compõem o sistema, ou seja, o seu fluxo desde a criação de uma conta de acesso
até a conclusão de uma notificação. Este fluxo é demonstrado na Figura 1.
Figura 1 – Fluxo do SNAA.
O fluxo do sistema tem início quando um representante de uma unidade de

saúde solicita a criação de uma conta de usuário para ter acesso ao SNAA. Esta
11
solicitação é feita através de um formulário, em que o representante cadastra seus

dados e dados de sua unidade de saúde. O administrador, responsável pela criação
e gerenciamento de contas de usuários, então verifica e avalia as solicitações dos
representantes, validando ou reprovando tais solicitações. Dada a deliberação do
administrador, um email é enviado automaticamente ao solicitante. Caso seja
reprovado, o representante deve verificar e resolver o problema pelo qual não teve
acesso concedido, e enviar uma nova solicitação. Caso seja aprovado, poderá
acessar o sistema. Vale ressaltar que um usuário que deseja ter o perfil de
administrador também passa por este mesmo processo.
Após entrar no sistema, o representante poderá cadastrar os profissionais de
saúde relacionados à unidade de saúde ao qual é responsável. Este cadastro
também é feito através de um formulário com os dados do profissional, preenchido
pelo representante de unidade de saúde. Ao contrário do que ocorre com o cadastro
do representante de unidade de saúde - que precisa ser avaliado - um profissional,
após ser cadastrado, já pode entrar no sistema e notificar os acidentes.
Conforme existam vítimas de acidentes, os profissionais de saúde podem
realizar a notificação. Uma notificação é um conjunto de dados cadastrados relativos
ao acidente por arraia, o que inclui o cadastro da vítima, do local da ocorrência,
informar o tipo de arraia que atacou a vítima, dados de prontuário e do tratamento
utilizado. Uma notificação de acidente também pode ser feita diretamente por uma
pessoa, definida na Figura 1 como público, que tenha sido vítima de um acidente,
independente da data deste acidente. Neste último caso, a pessoa não informará os
dados do prontuário e do tratamento do paciente, somente informando seus dados
(ou de outra pessoa que foi vítima) e dados do acidente. Estas notificações são
consideradas como não-oficiais, conforme dito anteriormente.
As estatísticas de ocorrência de acidentes por arraias estão disponíveis em
forma de relatórios gráficos e podem ser acessados por qualquer pessoa,
independente de ter uma conta no sistema ou não. É importante citar que os dados
da vítima não são disponibilizados nestes relatórios.
2.2.2 Tecnologias utilizadas na construção do SNAA
A principal tecnologia utilizada no desenvolvimento do SNAA é a plataforma de

desenvolvimento de software Java, que inclui uma linguagem de programação
12
orientada a objetos, uma coleção de API’s (Application Programming Interface -

Interface de Programação de Aplicativos) e um amplo ambiente de execução. Para
dar suporte ao desenvolvimento web são utilizados o framework de componentes e
interfaces JSF, o Hibernate e JPA como ferramenta de transação de dados entre a
aplicação e o banco de dados MySQL. Como servidor de aplicação, este sistema
utiliza o JBOSS Application Server, um contêiner bastante conhecido por dar
suporte a aplicações Java web.
2.2.3 Limitações do SNAA
O SNAA, conforme descrito anteriormente, permite a notificação de acidentes

por arraias e também controle de acesso, para garantir a autenticidade das
informações fornecidas. Ainda que este sistema represente um avanço no que diz
respeito à geração de recursos para a notificação de acidentes por arraias ocorridos
no estado do Amazonas, há algumas demandas, segundo o próprio Gualberto
(2014), e em contato com clientes do sistema, que precisam ser satisfeitas para
melhor atender as necessidades dos profissionais de saúde.
Uma dessas demandas é a utilização de equipamentos móveis, como tablets e
smartphones, para permitir realização de notificação dos acidentes tendo seu
funcionamento com a presença de sinal de Internet (online), como acontece
atualmente no SNAA, e também sem sinal (offline). A ênfase maior estará no acesso
offline, principalmente por considerar que em determinados municípios da região
Norte a conexão com a Internet ainda é instável e limitada.
Ainda sobre a região Norte, a maioria de seus municípios possuem programas
de atendimento de saúde, onde, geralmente, os acompanhamentos dos moradores
são realizados por profissionais que fazem visitas aos arredores das comunidades,
principalmente por serem municípios pequenos. A utilização de equipamentos
móveis pode auxiliar a mobilidade destes profissionais enquanto notificam acidentes
(nos momentos logo após a ocorrência ou que já tenha ocorrido), tanto dentro
quanto fora de sua unidade de saúde.
Outra demanda a ser sanada é a captura da geolocalização dos acidentes,
que pode garantir precisão no conhecimento e consolidação de um histórico sobre
acidentes com arraias, auxiliando no entendimento dos seus aspectos
epidemiológicos e, consequentemente, na sua prevenção e tratamento, além da
13
distribuição geográfica das espécies de arraias presentes no país. Atualmente,

grande parte, senão todos os equipamentos móveis, já apresentam GPS 2 embutido,
o que possibilita a captura da geolocalização.
Estas demandas, impactantes no trabalho dos profissionais de saúde
utilizando o SNAA, motivaram a realização deste trabalho, cujo produto é uma
aplicação mobile que permite a notificação de acidentes, bem como sua
geolocalização, além de oferecer maior mobilidade no acesso a dados e na própria
notificação, uma vez que aparelhos móveis não necessitam de cabos para acesso à
Internet ou a qualquer rede.
Dado que o atendimento destas demandas gerou uma evolução no próprio
SNAA, trataremos, na próxima seção, sobre alguns conceitos relacionados a esta
temática.
2.3 Evolução/Manutenção de Software
Independente do domínio da aplicação, tamanho ou complexidade, o software

continuará a evoluir (PRESSMAN, 2006). A evolução compreende as mudanças que
irão ocorrer em um sistema, de maneira a torna-lo completo e, se possível, livre de
erros. É uma atividade muito importante dentro da Engenharia de Software,
disciplina cujo foco está em todos os aspectos da produção de software, desde os
estágios iniciais da especificação do sistema até sua manutenção, quando o
sistema já está sendo usado (SOMMERVILLE, 2011).
Uma evolução pode ser desencadeada por necessidades empresariais em
constante mudança, por relatos de defeitos ou por alterações em outros sistemas
em um ambiente de software. É por isso que a evolução de um sistema raramente
pode ser considerada de forma isolada, pois alterações no ambiente podem levar a
mudanças no sistema, que podem, por sua vez, provocar mais mudanças no
ambiente (SOMMERVILLE, 2011). Logo, as propostas de mudança no sistema, uma
vez identificadas, acionam e orientam a evolução. Os processos de identificação de
mudanças (Figura 2) e de evolução de sistema são cíclicos e continuam durante
toda a vida de um sistema (SOMMERVILLE, 2011).
2 Sigla de Global Position System (Sistema de posicionamento global), tecnologia que possibilita a
captura de dados do posicionamento de um objeto, pessoa ou lugar ao redor do planeta.
14
Figura 2 - Processos de identificação de mudanças e evolução.
Fonte: (SOMMERVILLE, 2011).
O Processo de identificação de mudanças (Figura 2) é a etapa que inicia o

ciclo de evolução e resulta em propostas de mudanças no sistema. Essas
propostas podem vir de requisitos já existentes que não tenham sido
implementados na última release (liberação de uma versão funcional) de sistema,
solicitações de novos requisitos, relatórios de bugs (defeitos) apontados pelos
envolvidos no sistema e novas ideias para a melhoria do software vindas da
equipe de desenvolvimento (SOMMERVILLE, 2011).
As propostas são relacionadas aos componentes do sistema que necessitam
ser modificados para implementar essas propostas, o que permite que o impacto
da alteração seja avaliado (SOMMERVILLE, 2011). Tem-se então o início do
processo de evolução. Analistas e desenvolvedores avaliam o impacto dessas
mudanças para ver quanto do sistema é afetado, como irão interferir na utilização
do sistema e os componentes que irão se adaptar às mudanças. Em seguida há
um planejamento de versões, onde é planejada uma nova release do sistema,
levando em consideração os tipos de mudanças propostas (reparo de defeitos,
adaptação de plataforma e/ou aprimoramento do sistema). Este planejamento guia
a próxima etapa, a implementação de mudanças, onde as mudanças são
realizadas e validadas. Por fim, ocorre a liberação do sistema, onde uma nova
versão do sistema é liberada. A Figura 3 mostra uma visão geral do processo de
evolução do software.
15
Figura 3 - Processo de evolução do software.
Fonte: (SOMMERVILLE, 2011).
Neste trabalho, os processos apresentados na Figura 2 e Figura 3 foram

aplicados para auxiliar na identificação de mudanças e guiar a
evolução/manutenção no SNAA. A aplicação destes processos será apresentada
detalhadamente no Capítulo 4.
O resultado da utilização deste processo de evolução será um Novo Sistema
(Figura 2), neste caso, o SNAA mobile. Além disso, na etapa de Análise de
impactos, foi observado que o SNAA deverá receber manutenções para integrar
os serviços desta aplicação. Podemos observar, neste caso, o que foi apresentado
anteriormente, onde SOMMERVILLE (2011) afirma que uma evolução não pode
ser considerada de maneira isolada. As primeiras modificações no SNAA foram
solicitações de clientes, baseados na utilização do sistema pelo profissional de
saúde, o que resultou na proposta de uma aplicação mobile. Esta aplicação, por
sua vez, será integrada ao SNAA, que deverá sofrer novas modificações (a partir
da ideia da aplicação mobile, resposta às primeiras solicitações de mudança),
porém estas não irão originar um novo sistema, apenas uma adaptação para a
integração. Esta é a diferença entre evolução e manutenção.
É considerado como manutenção qualquer trabalho efetuado para modificar o
sistema, depois que ele estiver em operação (PFLEEGER, 2004). As atividades de
manutenção são semelhantes às de desenvolvimento: analisar os requisitos,
avaliar o sistema e o projeto do programa, programar e revisar o código, testar as
modificações e atualizar a documentação.
Segundo PFLEEGER (2004), há quatro tipos de manutenção:
 Manutenção corretiva: para controlar as funções cotidianas do sistema, a

equipe de manutenção trata de problemas resultantes de defeitos. À medida
16
que as falhas ocorrem, elas são relatas à equipe, que encontra a causa da
falha e faz as correções e mudanças nos requisitos, no projeto, no código,
no conjunto de testes e na documentação, conforme necessário.
 Manutenção adaptativa: algumas vezes, uma mudança introduzida em
uma parte do sistema requer modificações em outras partes. A manutenção
adaptativa é a implementação dessas modificações secundárias. Esta
manutenção pode ser realizada para mudanças no hardware, software ou
no ambiente;
 Manutenção perfectiva: a manutenção perfectiva consiste em realizar
mudanças para melhorar alguns aspectos do sistema, mesmo quando
nenhuma das mudanças for consequência de defeitos. Esta manutenção
pode ser desde alterações no documento, para tornar a esclarecer
determinados itens, até modificações no código e no projeto;
 Manutenção preventiva: de modo semelhante à manutenção perfectiva, a
manutenção preventiva consiste em modificar alguns aspectos do sistema,
a fim de prevenir falhas. A manutenção preventiva geralmente ocorre
quando um programador ou analisador de código descobre um defeito real
ou potencial, que ainda não causou uma falha, e decide corrigir o defeito
antes que ele gere uma falha.
Este trabalho envolveu manutenção adaptativa, devido a algumas alterações

em alguns componentes do SNAA, para integração com os serviços do SNAA
mobile, e manutenção perfectiva, pois abrangeu uma nova plataforma para auxiliar
nas notificações offline, neste caso representando uma evolução.
Dado que este trabalho resultou na evolução de um sistema já existente para
uma nova plataforma (móvel), a próxima seção tratará sobre o desenvolvimento de
aplicações para dispositivos móveis.
2.4 Desenvolvimento de Aplicações para Dispositivos Móveis
Um dispositivo móvel é qualquer aparelho equipado com uma tela e um teclado

miniatura, com dimensões pequenas, capaz de processar informações. Há alguns
anos, os dispositivos móveis se resumiam a celulares e laptops com baixo poder
computacional e comunicação digital relativamente lenta. Nos dias de hoje além
destes, temos ainda outros dispositivos como smartphones, consoles e televisões
17
portáteis, netbooks e tablets (ROCHA, 2010). LECHETA (2013) afirma que mais de
três billhões de pessoas possuem um aparelho celular, e isso corresponde a mais
ou menos metade da população mundial. A explicação 3 para o crescimento rápido
no consumo destes dispositivos é dada pelas suas principais características:
mobilidade (capacidade de poder continuar uma comunicação e manter o envio de
dados constante mesmo quando em movimento), facilidade de acesso a dados e
informações a qualquer hora e lugar, principalmente devido ao avanço de
tecnologias como o wireless (conexão de redes sem fios) e a capacidade de ser
multitarefa (rodar aplicativos, ser multimídia, ter agenda telefônica, funcionalidades
de celular, etc).
Segundo ROMEIRO (2005) algumas vantagens dos dispositivos móveis em
relação aos microcomputadores são:
 Tamanho: bastante reduzidos e muito mais leves do que os PCs, podendo

ser transportados de forma muito mais prática;
 Fácil manuseio: os dispositivos móveis possuem uma interface gráfica
simples de manusear se comparado aos computadores;
 Consumo de energia: por serem menores e mais econômicos gastam
menos energia que os computadores visto que o tempo de recarga é menor;
 Custos operacionais: como os dispositivos móveis são mais compactos e
possuem atividades específicas, estes aparelhos não possuem alguns
periféricos internos, como discos rígidos e discos flexíveis, diminuindo
consideravelmente os custos com a manutenção.
Pelo crescente mercado de dispositivos móveis foi necessária uma grande

adaptação das tecnologias já desenvolvidas para os computadores, para que estas
também estejam disponíveis para os dispositivos móveis (ROMEIRO, 2005). Do
ponto de vista do usuário, utilizar um dispositivo que permita acessar aplicativos que
o mantenha conectado as redes sociais, pagar contas ou consultar o transito, por
exemplo, é uma grande vantagem. Do ponto de vista do desenvolvedor de software
isto representa uma grande mudança, pois influencia no desenvolvimento de
aplicações para estes dispositivos, uma vez que esta nova plataforma apresenta
3 Algumas estatísticas da plataforma móvel podem ser conferidas em: http://migre.me/qF3vs e

http://migre.me/qF3xj
18
algumas restrições se comparada ao desenvolvimento desktop. Alguns pontos a

serem levados em consideração no desenvolvimento móvel são:
 Processamento: o processamento de um dispositivo móvel tem melhorado

com o tempo, mas ainda não é comparável ao poder de processamento de
um computador. Principalmente pela característica multitarefa, é necessário
estar atento ao desenvolver aplicações para que elas não sobrecarreguem o
aparelho;
 Recurso de memória limitado: assim como o processamento, a memória
em dispositivos móveis tem aumentado com o tempo, mas ainda é ínfimo
comparado aos computadores. Isto influencia na maneira de armazenar
dados provenientes das aplicações e também no processamento do
aparelho (aparelhos com pouco espaço em memória tendem a ser mais
lentos). Além disso, estes dispositivos não possuem o recurso de memória
virtual, como ocorre em computadores, o que exige que o gerenciamento de
memória seja fundamental;
 Energia: esta é uma questão que não progrediu nos últimos tempos. A
garantia que se tem hoje é de que os dados não serão perdidos caso o
dispositivo fique ‘sem bateria’;
 Interface reduzida: normalmente esses dispositivos possuem uma tela de
pequena dimensão, tornando limitada a quantidade de informações que
pode ser visualizada;
 Mobilidade: pela característica de possuir grande mobilidade, pode
acarretar perda de conexão.
Além destes pontos, ao desenvolver para o ambiente mobile uma das

principais decisões a se discutir é sobre a abordagem que será utilizada para criar
uma aplicação. Caso o desenvolvimento utilize uma determinada plataforma (iOS,
Android, Windows Phone, etc), a aplicação é denominada aplicação nativa, por
trabalhar com o sistema operacional e linguagem própria de determinada tecnologia.
Estas aplicações geralmente são instaladas diretamente no aparelho, através de
alguma loja online (Google Play da empresa Google, por exemplo). Caso seja
direcionada a aplicativos genéricos, na web, que seja acessível por qualquer
aparelho, é denominada aplicação web mobile. A diferença da web mobile para uma
aplicação web comum é que a visualização do conteúdo da aplicação em telas com
19
menores resoluções também são levadas em consideração, com funcionalidades

próprias para dispositivos móveis, e não necessariamente sendo acessadas por um
navegador (na verdade são utilizados navegadores embutidos, escondendo-se as
barras de ferramentas), como é de costume quando acessado por um computador
ou notebook. Esse termo (web mobile) ganhou mais popularidade com a atualização
de tecnologias web, como o HTML54 e o CSS35. Há também o meio termo entre
estas duas soluções, chamadas aplicações híbridas (parcialmente nativos e
parcialmente web), que permite a criação de um núcleo do programa de forma
nativa e, dentro da aplicação, uma parte multiplataforma (web).
Cada abordagem apresenta suas vantagens e desvantagens, por isso a
escolha depende da necessidade e do objetivo que se deseja alcançar com a
aplicação. Neste trabalho, por exemplo, optou-se por utilizar uma aplicação nativa,
baseando-se na comparação apresentada no Quadro 2.
À medida que a demanda por funcionalidades aumenta, as empresas de
telefonia celular vêm acrescentando novas tecnologias a aparelhos móveis,
estimulando nos consumidores o desejo de possuir o mais recente modelo de uma
determinada marca (ROMEIRO, 2005). Para acompanhar essa evolução da
tecnologia e satisfazer os usuários, os fabricantes, operadoras de celulares,
empresas e desenvolvedores, existe uma grande corrida estrelada pelas maiores
empresas do mundo em tecnologia móvel para competir por esse nicho do mercado
(LECHETA, 2013). Entre outras tecnologias geradas ao longo do tempo, até o
momento do desenvolvimento do SNAA Mobile, as fatias de mercado e o
desenvolvimento de aplicações estão divididos entre duas fortes tecnologias:
Android, da empresa Google e iOS, da empresa Apple. A Figura 4 apresenta a
participação destas e de outras tecnologias móveis no mercado.
4 HTML5 é a mais nova versão do Hypertext Markup Language (Linguagem de marcação de texto),
uma linguagem para estruturação e apresentação de conteúdo de páginas web.
5 CSS3 é a mais nova versão das Cascading Style Sheets (Folhas de estilo em cascata), onde se
define estilos para páginas web.
20
Quadro 2 - Comparação sobre a abordagem de desenvolvimento de aplicações mobile.
Quesito Aplicação nativa Aplicação web mobile Aplicação híbrida

Acesso direto ao hardware e recursos Acesso por meio de um navegador, e por razões de Para acesso na web, apresenta um
do sistema operacional, melhor segurança, não tem acesso direto às funcionalidades navegador embutido numa ‘casca’
Funcionalidades do integração com outros aplicativos e da plataforma nativa (câmera, banco de dados, etc). nativa, logo, apresenta as mesmas
dispositivo API’s. Algumas API’s do HTML5 permitem que sejam limitações que uma aplicação web
utilizados alguns recursos, porém o acesso mobile.
apresenta lentidão.
Caso a aplicação necessite operar Atualmente o HTML5 trouxe uma importante Por rodar em navegador embutido,
offline, a aplicação nativa pode utilizar evolução para aplicações rodarem offline, mas é possui mesma limitação que uma
Funcionamento
recursos do próprio aparelho, como limitado se comparado ao nativo. aplicação web mobile
offline
banco de dados embutido para
armazenamento de dados.
Apresenta melhor desempenho, pois a São executados em um navegador, que interpreta Também executados em navegadores,
aplicação é executada direto no HTML, CSS e Javascript6, o que o torna podem apresentar lentidão no
Perfomance
sistema operacional da plataforma relativamente lento (principalmente o carregamento carregamento inicial e quando
específica. inicial) ao requisitar novas páginas. necessitar requisitar novas páginas.
Aplicação tem integração visual com a Aplicação terá um trabalho a mais caso queira deixar Quase obrigatório o uso de layout
plataforma, usabilidade e o layout no estilo nativo. Caso não o faça, tende a semelhante ao nativo, caso contrário
Layout (usabilidade
componentes visuais característicos, o não ter uma boa experiência com o usuário. terá uma péssima experiência com o
e visual)
que melhora a experiência com o usuário tendo dois layouts diferentes em
usuário. uma mesma tela.
6 Linguagem de programação interpretada, incorporada aos navegadores para executar scripts sem necessitar de requisições ao servidor.
21
Figura 4 - Participação de tecnologias móveis no mercado.
Fonte: (IDC7, 2015).
Com relação às duas primeiras tecnologias, PACHECO JÚNIOR e CASTRO

(2011) afirmam que o controle sobre os aplicativos lançados, localidade da
publicação do aplicativo, plataforma de desenvolvimento proprietária e exclusiva,
hardware especifico, design diferenciado e funcionalidades inovadoras, entre outros
pontos, foram focais para a liderança da Apple, com iOS, consequentemente,
apresentando um custo superior na construção de aplicativos. Porém, o controle
total da plataforma e do desenvolvedor pode ter sido um dos fatores a desestimular
os desenvolvedores e consequentemente causado o êxodo do desenvolvimento
com a tecnologia iOS, além de alavancar o crescimento dos concorrentes.
O Android consolidou em sua plataforma todas as expectativas de um
desenvolvedor, plataforma livre, confiável, robusta, de código aberto e fácil de usar,
além de customização fácil, hardware barato e acessível (PACHECO JÚNIOR &
CASTRO, 2011). Segundo pesquisas do International Data Corporation (IDC), já no
segundo trimestre de 2013 foram vendidos 8,3 milhões de smartphones no Brasil,
destacando que 90% dos aparelhos vendidos possuem o sistema móvel Android
(FREITAS & DINIZ, 2013), seguindo um crescimento mundial desde 2012, conforme
ilustrado na figura 4.
7 Site do IDC: http://www.idc.com/prodserv/smartphone-os-market-share.jsp
22
Por estas características, neste trabalho optou-se por utilizar a plataforma

Android para construir uma aplicação nativa, por se tratar de uma aplicação que
também terá funcionamento offline, o que permite utilizar recursos do próprio
aparelho para funcionamento. Para auxiliar na construção desta aplicação, foram
utilizados um processo de desenvolvimento e algumas tecnologias, que serão
apresentados no próximo capítulo.
23
Capítulo 3
Processo e Tecnologias utilizados no Desenvolvimento do

SNAA Mobile
Neste capítulo serão descritos o processo e as tecnologias utilizados no

projeto e implementação do SNAA mobile, produto deste trabalho. Vale ressaltar
que, por se tratar de um trabalho acadêmico, as tecnologias utilizadas são gratuitas
e/ou open source (código-aberto), visando o menor custo possível para utilização
por instituições públicas e unidades de saúde.
3.1 AUP (Agile Unified Process)
Nos anos 90, os cientistas da computação Ivar Jacobson e James Rumbaugh,

juntamente com o engenheiro de software Grady Booch, propuseram o Processo
Unificado (Process Unified, PU), um modelo de processo de desenvolvimento de
software iterativo, incremental e flexível, podendo ser customizado de acordo com
as necessidades de diferentes projetos e organizações.
Baseados no PU surgiram alguns outros modelos de processo. Dentre eles
está o AUP (Agile Unified Process), processo que será utilizado neste trabalho. É
importante citar que o AUP é uma versão simplificada de um outro processo
adaptado do PU, o RUP (Rational Unified Process), da Rational Software
Corporation, um dos processos de desenvolvimento dos mais conhecidos e
utilizados por várias empresas de desenvolvimento. RUP é um processo
preferencialmente aplicável a grandes projetos que envolvem uma grande equipe de
desenvolvimento. Com base nisso, o engenheiro de software Scott W. Ambler, a fim
de adaptar as boas práticas do RUP a pequenos projetos, criou o AUP.
O AUP é uma versão ágil e simplificada do RUP para o desenvolvimento de
software, sequencial, iterativa e disponibiliza versões incrementais ao longo do
tempo. Na Figura 5 é apresentado o ciclo de vida do AUP - constituído por quatro
fases e sete disciplinas.
24
Figura 5 - Ciclo de vida do AUP.
Fonte: (AMBLER, 2005).
As quatro fases do processo são:
● Inception (Concepção): O objetivo é identificar o escopo inicial do projeto

e a arquitetura potencial do sistema a fim de gerar estimativas financeiras
e prover informações que subsidiem a aceitação pelas partes
interessadas;
● Elaboration (Elaboração): O objetivo é prover uma arquitetura central,
resolução dos altos riscos e definição de estimativas mais realistas;
● Construction (Construção): O objetivo é construir o software,
trabalhando em uma base incremental regular, que atende às
necessidades de maior prioridade das partes interessadas no projeto;
● Transition (Transição): O objetivo é validar e implantar o sistema em seu
ambiente de produção, ou seja, no ambiente em que vai operar ‘de
verdade’.
As disciplinas do processo são:
 Model (Modelo ou Modelagem): O objetivo desta disciplina é promover o

entendimento do negócio da organização, o domínio do problema a ser
25
abordado pelo projeto e a identificação de uma solução viável para

resolver o domínio do problema;
 Implementation (Implementação): O objetivo desta disciplina é o de
transformar o(s) modelo(s) em código executável e executar um nível
básico de testes (testes de unidade);
 Test (Teste): O objetivo desta disciplina é a realizaçã o de uma avaliação
objetiva para garantir a qualidade. Isto inclui as atividades de validação e
verificação dos requisitos;
 Deployment (Implantação): O objetivo desta disciplina é planejar a
entrega do sistema e executar este plano a fim de tornar o sistema
disponível para os usuários finais;
 Configuration Management (Gerenciamento de Configuração): O
objetivo desta disciplina é o de gerir o acesso aos artefatos criados durante
todas as fases do desenvolvimento do software. Isso inclui não apenas
controlar versões de artefatos ao longo do tempo, mas também controlar e
gerenciar mudanças;
 Project Management (Gerenciamento de Projetos): O objetivo desta
disciplina é a de dirigir as atividades que ocorrem no projeto. Isto inclui a
gestão de riscos, a coordenação de pessoas e controle de prazos e
orçamento;
 Environment (Ambiente): O objetivo desta disciplina é o de apoiar o resto
do esforço, garantindo que o processo adequado, orientação (normas e
diretrizes) e ferramentas (hardware, software, etc) estejam disponíveis
para a equipe quando necessário.
As disciplinas, que definem um conjunto de atividades (e artefatos

relacionados) são realizadas ao longo das iterações de desenvolvimento. Estas
iterações são realizadas com o objetivo de entregar uma release – uma versão
executável do produto.
O AUP foi escolhido para ser o processo de desenvolvimento da aplicação
mobile por ser de conhecimento do desenvolvedor e por ser aplicável a pequenos
projetos, neste caso, somente com um desenvolvedor, mas que inclui uma
quantidade satisfatória de artefatos de suporte para o entendimento da aplicação.
Além disso, este trabalho está diretamente relacionado a um sistema já existente
que também adotou o mesmo processo.
26
No Quadro 3 são apresentados os artefatos que foram produzidos durante todo

o processo de desenvolvimento deste trabalho. É importante salientar que, por
tratar-se de um trabalho desenvolvido por uma única pessoa, algumas disciplinas do
AUP foram adotadas com algumas simplificações. Por exemplo, o Gerenciamento
de Configuração (Configuration Management) focou somente no controle de versões
do código-fonte e dos artefatos produzidos durante a análise e o desenvolvimento,
realizado através de um sistema de controle chamado Bitbucket8. O Gerenciamento
de Projetos (Project Management) foi realizado pelo estabelecimento de um
cronograma de desenvolvimento, aliado as políticas de gerenciamento de versões e
backup do código e outros artefatos. Quanto às atividades pertinentes a disciplina
de Ambiente (Enviroment), estas foram providenciadas pelo próprio desenvolvedor
que ficou responsável pela instalação e configuração das ferramentas para o
desenvolvimento.
Quadro 3 - Artefatos produzidos durante a execução do processo.
Fase Artefato
- Descrição geral do software (escopo);
- Diagrama de casos de uso;
Inception (Concepção)
- Especificação dos casos de uso;
- Prototipação das interfaces dos usuários.
- Descrição da arquitetura do software;
- Diagrama de classes;
- Diagrama de sequência;
Elaboration (Elaboração)
- Diagrama de máquina de estados.
- Diagrama de entidade e relacionamento
(MER).
Construction (Construção) - Código-fonte e testes
Transaction (Transação) - Plano de Implantação
3.2 UML - Unified Modeling Language
Também concebida pelos cientistas da computação Ivar Jacobson e James

Rumbaugh, juntamente com o engenheiro de software Grady Booch, a UML (Unified
8 Site oficial: https://bitbucket.org/

27
Modeling Language), em português ‘Linguagem de Modelagem Unificada’, é uma

linguagem padrão de modelagem de software para especificar, construir e
documentar os artefatos dos sistemas (LARMAN, 2000), onde cada artefato
(diagrama) se refere a uma visão parcial do sistema, que em conjunto forma um
todo integrado e coerente.
A UML encontra-se na versão 2.4 sendo composta por treze diagramas,
listados no Quadro 4.
Quadro 4 - Diagramas da UML.
Fonte: (FOWLER, 2005).
É importante destacar que não é necessário que todos os diagramas da UML

sejam elaborados ao longo do desenvolvimento de um software. Recomenda-se
apenas criar aqueles que irão colaborar para um melhor entendimento e visão das
partes do sistema. Tendo isso em vista, de acordo com LARMAN (2000), os
diagramas que devem ser produzidos em um processo iterativo são os diagramas
de caso de uso, de classe e o de sequência. Neste trabalho, além destes, foram
realizadas modelagens do diagrama de pacotes e diagrama de máquina de estados,
os quais são apresentados a seguir:
 Diagrama de caso de uso: O diagrama de casos de uso é o diagrama

mais geral e informal da UML, que apresenta uma linguagem simples e de
fácil compreensão para que os usuários possam ter uma ideia geral de
como o sistema irá se comportar (GUEDES, 2010). Os diagramas de caso
28
de uso costumam conter os seguintes elementos: atores, casos de uso, o

relacionamento entre estes elementos e a especificação de casos de uso;
 Diagrama de classes: permite a representação da estrutura e relação
entre as classes de um sistema;
 Diagrama de sequência: O diagrama de sequencia é o diagrama da UML
que enfatiza os atores participantes e a ordem temporal das trocas de
mensagens entre os objetos que participam de determinada interação. O
que vale neste diagrama, assim como nos casos de uso, é o
comportamento do sistema;
 Diagrama de pacotes: O diagrama de pacotes é um diagrama da UML
que permite particionar o sistema de uma forma lógica, separando
elementos que apresentam algo em comum, dando uma visão de nível
mais alto e permitindo visualizar um modelo em agrupamentos simples
(LARMAN, 2000);
 Diagrama de máquina de estados: Um diagrama de máquina de estados
é o diagrama da UML que especifica as sequências de estados pelas quais
um objeto passa durante seu tempo de vida em resposta a eventos,
juntamente com sua resposta a estes eventos.
3.3 Android
O Android consiste em uma plataforma de desenvolvimento para aplicativos

móveis, como smartphones e tablets, baseada em um sistema operacional Linux,
com diversas aplicações já instaladas e um ambiente de desenvolvimento bastante
poderoso e flexível (LECHETA, 2013). No entanto, devido sua característica aberta
e customizável, não está limitado a esses dispositivos, podendo ser embarcado em
outros eletrônicos.
A plataforma foi revelada no final de 2007 pela Open Handset Alliance como
uma plataforma para telefonia móvel com licença open source9, com o objetivo de
definir uma plataforma única e aberta para celulares para deixar os consumidores
mais satisfeitos com o produto final, além de criar uma plataforma aberta e flexível
para o desenvolvimento de aplicações coorporativas (LECHETA, 2013). A Open
Handset Alliance (OHA) é um grupo formado por gigantes do mercado de telefonia
9Traduzido do inglês ‘código aberto’, diz-se do software cujo código-fonte está disponível aos
usuários, para que estes possam estudá-lo, bem como contribuir para aperfeiçoá-lo. Para saber
mais, visite http://opensource.org/.
29
celulares liderados pela empresa Google. Entre alguns integrantes do grupo estão
nomes como HTC, LG, Motorola, Samsung, Intel, Acer, Dell, entre outros, ou seja,
inclui fabricantes de dispositivos móveis, desenvolvedores de aplicativos,
operadoras de telefonia móvel e fabricantes de chips (LECHETA, 2013).
Apesar do desenvolvimento com a linguagem Java, os aplicativos não são
compilados em Java bytecode e interpretados em uma máquina virtual Java (JVM).
Foi desenvolvida uma máquina virtual (VM) específica para o Android, a qual é
otimizada para conseguir trabalhar com baixa energia e com memória e unidades de
processamento central (CPU) limitadas, a Dalvik VM.
No trabalho a ser realizado, Android será a principal tecnologia a ser utilizada,
pois utiliza Java como linguagem de programação, a mesma linguagem adotada no
desenvolvimento do SNAA, facilitando assim as questões de comunicação, o
reaproveitamento de componentes, além de uma redução no tempo de
desenvolvimento. Além disso, como foi apresentado no Capítulo 3, Android é um
dos sistemas mais populares quando se trata do contexto de computação móvel.
3.3.1 Arquitetura
O Android é formado por um conjunto de softwares, composto de um sistema

operacional, middleware e framework de aplicação para dispositivos móveis. O SDK
(kit de desenvolvimento de software) fornece as APIs (Application Programming
Interface - Interface de Programação de Aplicações) necessárias para começar a
desenvolver aplicativos que executam em dispositivos com Android (PACHECO
JUNIOR & CASTRO, 2011). A Figura 6 ilustra a arquitetura do Android. Abaixo dela
uma breve descrição das cinco camadas que compõem esta arquitetura, segundo
(LAET, 2010) e (PACHECO JUNIOR & CASTRO, 2011).
30
Figura 6 - Arquitetura da plataforma Android.
Fonte: LAET (2010).
3.3.1.1 Applications
O Android inclui, em seu sistema operacional, diversos aplicativos que

interagem com o celular. São esses aplicativos que dão a funcionalidade básica do
sistema, dentre os quais estão e-mail, agenda de contatos, mapa, navegador,
discador, calendário, aplicativos de terceiros (como a aplicação a ser desenvolvida
neste trabalho) dentre outros.
3.3.1.2 Application Framework
A arquitetura deste framework foi desenvolvida para simplificar a reutilização

dos componentes. Desta forma qualquer desenvolvedor pode construir um aplicativo
e disponibilizar suas “capacidades”, permitindo que elas sejam utilizadas por outros
programas. O framework de aplicativos fornece vários componentes para que o
desenvolvedor possa utilizar todos os recursos disponíveis, desde hardware até os
serviços mais simples, tais como, execução de serviços de fundo, definir alarmes,
notificações na barra de status, entre outros. Desta forma os componentes ficam
31
livres para serem utilizados e modificados em qualquer aplicação, além de possuir a

integração com todo o sistema.
Dentre os mais importantes serviços disponíveis no framework de aplicativos
do Android estão:
 Conjunto de Visões: pode ser utilizado para construir aplicações com

listas, grades, caixas de texto, navegador web embutido;
 Provedor de Conteúdo: permite que um aplicativo acesse dados de
outros aplicativos ou compartilhe seus dados. Por exemplo, um aplicativo
que busca informações dos contatos da agenda, utiliza o provedor de
conteúdo para isso;
 Gerenciador de Recursos: gerencia e fornece integração com os
arquivos de layouts, gráficos e strings;
 Gerenciador de Notificações: gerencia e fornece aos aplicativos
integração com a barra de notificações do sistema;
 Gerenciador de Atividades: gerencia o ciclo de vida da aplicação e
permite que aplicações executem em segundo plano;
3.3.1.3 Libraries
O Android inclui um conjunto de bibliotecas utilizadas por vários componentes

do sistema. Estas bibliotecas são disponibilizadas para que os desenvolvedores
possam realizar, facilmente, rotinas básicas como abrir arquivos, mostrar
mensagens, realizar cálculos aritméticos etc. As bibliotecas fornecem várias funções
e serviços, que são utilizadas ao longo do desenvolvimento para manipulação de
imagens, sons, vídeos, navegação na Internet, banco de dados e etc. As principais
bibliotecas disponíveis no Android são: System C Library, Media Library, Surface
Manager, Webkit, OpenGL/ES, FreeType, SQLite. A principal biblioteca a ser
utilizada no desenvolvimento deste trabalho será o SQLite.
3.3.1.3.1 SQLite
O SQLite pode definido com uma ferramenta, mais precisamente uma

biblioteca desenvolvida na linguagem C que pode ser integrada a programas
escritos em diversas linguagens com o intuito de possibilitar a manutenção de dados
32
através de instruções SQL (Struct Query Language, utilizada para acesso a bancos
de dados). Na prática, o SQLite funciona como um “mini-SGBD”, capaz de criar um
arquivo em disco, ler e escrever diretamente sobre este arquivo. O SQLite não
possui um processo servidor separado, a gravação e leitura dos dados estão num
único arquivo, foi projetado para funcionar em ambientes de pouca memória como
celulares, PDAs e MP3, com equilíbrio e velocidade.
3.3.1.4 Runtime
Semelhante ao Java, o Android possui uma máquina virtual personalizada,

denominada Dalvik Virtual Machine (DVM), criada para executar com baixo nível de
memória e permitir a execução de várias instâncias de máquinas virtuais, passando
o controle de memória, e processos ao sistema operacional. Como o
desenvolvimento convencional acontece em Java, primeiramente o código é
compilado no bytecode Java (.class), em seguida transformado para o formato
binário, Dalvik Executable (.dex), que pode ser interpretado pela Dalvik VM.
Para que uma aplicação Android possa ser instalada e distribuída, ela precisa
ainda ser compactada em um pacote denominado Android Package File (.apk), que
é a junção de todas as classes compiladas no bytecode Dalvik, imagens, sons,
parâmetros de execução, etc.,opção que também está disponível no SDK (kit de
desenvolvimento).
3.3.1.5 Linux Kernel
O Android usa a o kernel Linux para serviços essenciais do sistema, como

segurança, gerenciamento de memória, gerenciamento de processos, rede e
drivers. O kernel também funciona como uma camada de abstração entre o
hardware do dispositivo e o resto do conjunto de softwares que são desenvolvidos
em paralelo.
33
3.3.2 Componentes de aplicativo Android
Os componentes de aplicativo são os blocos de construção fundamentais de um

aplicativo do Android. Cada componente é um ponto diferente pelo qual o sistema
pode entrar no aplicativo. Nem todos os componentes são pontos de entrada reais
para o usuário e alguns dependem uns dos outros, mas cada um existe como uma
entidade independente e desempenha uma função específica. A seguir são
apresentados alguns destes componentes, utilizados no desenvolvimento da
aplicação mobile.
 Atividades (Activities): É um componente que apresenta uma interface

(tela) com a qual o usuário interage para realizar alguma atividade. Por
exemplo: o SNAA mobile tem uma atividade para efetuar o login de um
usuário e uma outra atividade para notificar um acidente.
 Serviços (Services): Os serviços são componentes executados em
segundo plano para realizar operações de execução longa ou para realizar
trabalho para processos remotos. Eles não apresentam uma interface do
usuário. Por exemplo: o SNAA mobile realiza a busca pelas coordenadas
de um acidente enquanto o profissional pode continuar cadastrando outros
dados deste acidente.
 Receptores de transmissão (Broadcast Receivers): Os receptores de
transmissão são componentes que respondem a anúncios de transmissão
por todo o sistema. Muitas transmissões se originam do sistema — por
exemplo, uma transmissão que anuncia que uma tela foi desligada, a
bateria está baixa ou uma tela foi capturada. Os aplicativos também
podem iniciar transmissões — por exemplo, o SNAA mobile informa
quando a sincronização de dados tem início e fim. Embora os receptores
de transmissão não exibam nenhuma interface do usuário, eles
podem criar uma notificação na barra de status para alertar ao usuário
quando ocorre uma transmissão;
 Fragmentos (Fragments): Um fragmento representa o comportamento ou
uma parte da interface com o usuário em uma atividade (Activity). É
possível combinar vários fragmentos em uma única atividade para
compilar uma interface de usuário de painéis múltiplos e reutilizar um
fragmento em diversas atividades;
34
 Intenções (Intents) : Uma intenção é um objeto de mensagem que pode

ser utilizado para solicitar um outro componente. Eles podem iniciar uma
atividade, um serviço ou fornecer uma transmissão, por exemplo. Um
objeto intent carrega informações que o sistema Android usa para
determinar o componente a iniciar (como o nome exato do componente ou
categoria do componente), além de informações que o componente
receptor usa para realizar a ação adequadamente (como a ação a tomar e
os dados a usar).
3.3.3 Ciclo de vida de uma atividade (Activity)
Como já apresentado, uma atividade (Activity) representa praticamente uma

tela de interface com o usuário, no qual ele realiza alguma atividade, como discar
um número de telefone ou tirar uma foto, por exemplo. Uma aplicação pode conter
várias atividades e cada uma delas tem seu próprio ciclo de vida. A Figura 7
apresenta o ciclo de vida de uma atividade.
Uma aplicação pode estar em cada um dos estados apresentados na Figura
7. Normalmente uma atividade é nomeada principal e, a partir desta, pode-se iniciar
outras atividades. A importância do entendimento desde ciclo de vida auxilia no
melhor gerenciamento de serviços disponíveis pela aplicação, para que estes não
sobrecarreguem o aparelho, por exemplo. O programador não tem controle sobre
estes estados, mas pode recuperá-los e realizar atividades através dos métodos 10
apresentados nas caixas retangulares. Em resumo, os principais métodos
chamados ao longo do ciclo de vida de uma atividade são:
 onCreate: é chamado quando a atividade é criada pela primeira vez,

quando deve-se fazer o carregamento dos elementos que irão compor a
‘tela’;
 onStart: é chamado logo após o método onCreate(), quando a tela está
prestes a ficar visível ao usuário;
 onResume: é chamado quando a atividade está em primeiro plano pronta
para interagir com o usuário;
 onPause: é chamado quando o sistema (operacional) está prestes a
chamar outra atividade;
10 A documentação completa de cada método pode ser encontrada no site:

https://developer.android.com/guide/components/activities.html
35
 onStop: é chamado quando a atividade não está mais visível ao usuário,

devido a ter sido destruída ou sendo coberta por outra atividade;
 onRestart: é chamado quando uma atividade está parada e deve ser
iniciada novamente;
 onDestroy: é chamado quando uma atividade for encerrada.
Figura 7 – Ciclo de vida de uma atividade.
Fonte:https://developer.android.com/gu ide/components/activities.html
3.4 REST
O termo REST (Representational State Transfer – Transferência de Estado

Representacional) é um estilo de arquitetura para comunicação baseada na web,
com intuito de permitir que clientes possam conversar com servidores de maneira
única (RAMOS ; BRUM, 2014). Espera-se que as requisições realizadas (no REST)
36
contenham todas as informações necessárias para definir o processamento no

servidor, não sendo necessário nenhum tipo de armazenamento de estados
(stateless). Os recursos, elementos de informação, localizam-se no centro de
sistemas RESTful, termo esse utilizado para designar sistemas que seguem o
princípio REST (RAMOS ; BRUM, 2014).
Cliente/servidor é um dos principais elementos do REST. Esta arquitetura trata
a captura de dados e o processamento de dados como processos diferentes,
geralmente em máquinas diferentes. O SNAA, por exemplo, por ser um sistema
web, utiliza esta arquitetura. Um cliente (um navegador acessado por um
computador em uma unidade de saúde, por exemplo) solicita alguma informação
(um relatório, por exemplo) do servidor (computador onde está o SNAA) e este
‘responde’ ao cliente fornecendo o serviço ou informação.
Neste estilo de arquitetura (REST) cada recurso dentro de um dado servidor é
representado unicamente por um identificador uniforme de recursos (URI) e podem
possuir diferentes representações, geralmente em forma de dados autodescritivos.
De forma mais clara, estes recursos podem representar objetos de dados usando
uma variedade de tipos, como Hipertext Markup Language (HTML), eXtensible
Markup Language (XML) ou JavaScript Object Notation (JSON). Os recursos podem
ser manipulados por meio de um Uniform Resource Locator (URL) utilizando
operações HTTP padrão, como por exemplo, GET, POST, DELETE e PUT. Usar
HTTP como transporte facilita o desenvolvimento de sistemas RESTful, já que elas
usam um protocolo de base bem conhecido e estável (RAMOS ; BRUM, 2014).
A aplicação mobile desenvolvida, por ter tido a necessidade de realizar troca
de dados, acessou um servidor que processou suas requisições. A comunicação foi
realizada utilizando a tecnologia REST e objetivou trabalhar com os dados através
de web services, apresentados na próxima seção.
3.5 Web Services
De uma maneira geral, pode-se definir Web Services como componentes que
representam serviços remotos possíveis de serem acessados por outras aplicações
(BURÉGIO, 2003). Seu objetivo é permitir a comunicação entre diferentes
aplicações através da Internet. Em termos práticos, tem-se um “serviço de software”
independente de plataforma, linguagem e localização, que recebe requisições de
37
uma aplicação e retorna respostas para o mesmo. A utilização de um Web Service

por uma aplicação também é conhecida como consumo de Web Services
(BURÉGIO, 2003).
Em geral, aplicações utilizavam web services baseados em SOAP, pois a
implementação utilizava as tecnologias SOAP (Simple Object Access Protocol)
como protocolo de comunicação entre as aplicações, XML (eXtensible Markup
Language) como formato de mensagem (não sendo somente este o único formato
existente), WSDL (Web Services Description Language) uma especificação que
fornece uma linguagem para descrição de definições de Web Services, e o HTTP
para transportar as mensagens entre as aplicações. Com o tempo, surgiu outra
forma alternativa às tecnologias baseadas em SOAP para implantação de serviços
na Internet, por fornecer uma interação mais simples entre os componentes e a
capacidade de transmitir dados diretamente via HTTP – os Web Services REST,
baseados na tecnologia REST.
A aplicação mobile desenvolvida utilizou Web Services REST para receber
informações do banco de dados do SNAA, e também enviar informações que estão
no banco de dados da aplicação, de maneira a sincronizar estes dados para
consultas e validações posteriores. O formato utilizado foi o JSON, por ser um
formato ‘leve’, que não sobrecarrega uma requisição, e de fácil leitura, pois trabalha
com o formato chave-valor. A implementação dos Web Services utilizou a API JAX-
RS, uma API da linguagem de programação Java que dá suporte à criação de web
services de acordo com a arquitetura REST. Seguindo esta arquitetura, o JAX-RS
trabalha com anotações (representado por @) que referem-se às operações
suportadas pelo REST: GET, POST, PUT, DELETE.
38
Capítulo 4
SNAA Mobile
Neste capítulo será apresentada a aplicação mobile produto deste trabalho,

denominada SNAA mobile. Suas funcionalidades, ilustradas com o auxílio de
diagramas da UML e interfaces de usuário, e as alterações realizadas no SNAA,
para sua integração com os serviços fornecidos pela aplicação, serão apresentadas
em seções baseando-se no processo de evolução de software ilustrado na Figura 3.
É importante citar que este processo não interferiu na utilização do AUP, apenas
sugeriu etapas para a evolução do SNAA, sem dizer como ou quais artefatos e
produtos deveriam ser gerados durante as fases do processo.
4.1 Solicitação de mudança
Conforme apresentado no Capítulo 1, a proposta da aplicação mobile surgiu

devido a solicitações de mudanças no SNAA, provenientes da seção de trabalhos
futuros do trabalho de conclusão de curso de GUALBERTO (2014) e decorrente de
conversas com clientes11.
As seguintes solicitações foram definidas:
1. Utilização de equipamentos móveis para realizar notificações, visando
maior mobilidade dos profissionais no atendimento aos acidentes, não só
nas unidades de saúde, como também nas comunidades, onde é comum a
realização de visitas às casas dos moradores e aos locais dos acidentes.
2. Possibilidade de realizar notificações offline de acidentes, dada a
instabilidade de conexão à Internet em muitos municípios da região Norte;
3. Captura da geolocalização (coordenadas geográficas) de acidentes, o que
auxiliará no histórico mais apurado destes acidentes, bem como das
arraias presentes na região.
11 Pesquisadoras do Grupo de Imunologia Básica e Aplicada da UFAM (Universidade Federal do

Amazonas, campus Manaus) do qual a professora Dra. Maria Cristina, co-orientadora deste trabalho,
faz parte.
39
Foram realizadas duas reuniões entre clientes, orientando e orientadoras, para

discutir as solicitações de mudança, analisar requisitos baseados no SNAA e definir
o escopo do trabalho. A primeira reunião também contou com a presença do
desenvolvedor deste sistema para apresentar suas funcionalidades e
operacionalidade ao orientando, bem como auxiliar na análise com os clientes.
A partir das solicitações acima citadas, as discussões giraram em torno de
quais informações iriam compor uma notificação na aplicação mobile, uma vez que
o formulário de notificação do SNAA contém bastante informação e seria pouco
funcional utilizá-lo devido ao limitado espaço de tela de equipamentos móveis. Para
auxiliar nesta atividade foram utilizadas técnicas como brainstorm12, onde surgiram
algumas propostas de como abordar as informações preservando o que fosse
essencial ao trabalho dos profissionais, além de protótipos de tela, para simular as
informações de um cadastro em um equipamento móvel.
As reuniões e análises realizadas nesta etapa do processo de evolução
(Solicitação de mudança) atendem o que é solicitado nas fases de Concepção e
Elaboração do ciclo do AUP, apresentados na Figura 5. Seguindo o que foi definido
no Quadro 3, foram produzidos os seguintes artefatos da fase de Concepção:
descrição geral do software (escopo), diagrama de casos de uso, especificações de
caso de uso e interfaces do usuário. E da fase de Elaboração, também seguindo o
Quadro 3, os seguintes artefatos: diagrama de classes, diagrama de sequência e
diagrama de máquina de estados.
As disciplinas do AUP utilizadas nestas fases foram: modelagem,
gerenciamento de configuração, gerenciamento de projeto e ambiente. A disciplina
de modelagem foi a principal, caracterizada pelas reuniões e análises que definiram
o escopo do trabalho e grande parte dos artefatos produzidos. Os artefatos foram
devidamente versionados em um repositório 13, de maneira a mantê-los atualizados,
favorecendo a gerência de configuração. A disciplina de ambiente guiou a
preparação do ambiente de desenvolvimento: instalação do software Android Studio
para desenvolvimento do código do SNAA mobile, instalação do software Eclipse e
do contêiner JBOSS para executar o deployment do SNAA e efetuar as
modificações necessárias.
12 Brainstorm, traduzido do inglês ‘tempestade de ideias’, é uma técnica utilizada para explorar a
capacidade criativa de indivíduos ou de grupos, a fim de reunir o maior número possível de ideias,
que levem à resolução de problemas que impedem um determinado projeto de seguir adiante.
13 Endereço do repositório: https://bitbucket.org/patrick_tapajos/snaamobile

40
De maneira a adequar a apresentação dos artefatos produzidos nestas fases

ao formato do trabalho e ao ciclo do AUP, os resultados da análise das reuniões e
do SNAA mobile serão apresentados nas seções a seguir.
4.1.1 Descrição geral do SNAA mobile (escopo)
Este trabalho tem o objetivo de disponibilizar uma aplicação mobile, e integrar

seus serviços ao SNAA, para permitir aos profissionais de saúde a notificação
online e offline de acidentes por arraias ocorridos na região Norte do Brasil.
Uma notificação é composta por informações tais como a identificação da
vítima, do local onde ocorreu o acidente, dos dados clínicos (sintomas, local da
picada, etc) e do tratamento utilizado (medicamentos, exames, etc), além de anexar
imagens do ferimento e da arraia causadora. A aplicação disponibilizará apenas um
perfil de acesso, o perfil de profissional de saúde. Para ter um perfil de acesso, o
profissional estará sujeito ao fluxo apresentado na Figura 8.
Figura 8 - Fluxo de notificação de acidente.
1. Um representante de unidade de saúde solicita a criação de conta para

acesso ao SNAA;
41
2. Um administrador faz a verificação desta solicitação e responde,

aprovando ou negando a solicitação de acesso;
3. Caso a solicitação seja negada, por algum erro ou falta de dados, o
representante de unidade de saúde poderá reenviar nova solicitação,
corrigindo os problemas informados. Caso tenha a solicitação aprovada, o
representante poderá acessar o sistema e realizar o cadastro dos
profissionais de saúde de sua unidade;
4. Após serem cadastrados no sistema pelos representantes de unidade de
saúde, os profissionais podem baixar o SNAA mobile, efetuar login e
notificar os acidentes pelo aparelho.
Objetivando manter os dados atualizados para posteriores consultas e

geração de relatórios, os dados registrados pelo SNAA mobile são sincronizados
com os dados registrados no SNAA. Na Figura 9 é ilustrado o esquema de troca de
dados.
De forma resumida, o SNAA mobile consulta o banco de dados do dispositivo
móvel, no qual está instalada, para verificar notificações que não foram enviadas ao
SNAA e, havendo dados, os enviará por meio de uma requisição a um web service.
O servidor então recebe os dados e atualiza sua base. Nesta requisição também há
verificação por atualizações em notificações relativas àquelas que estão em seu
aparelho e foram manipuladas pela aplicação web. Havendo notificações, a
aplicação as solicita do servidor, recebe os dados e os insere (ou atualiza) em seu
banco de dados.
Na Figura 10 é apresentado um diagrama de pacotes no qual são exibidos os
módulos do SNAA mobile e os relacionamentos de dependência que estes módulos
possuem com o SNAA, a fim de prover uma visão geral da relação destes
componentes.
42
Figura 9 - Esquema de troca de dados entre a aplicação mobile e o SNAA.
Figura 10 - Diagrama de pacotes do SNAA (web e mobile).

43
Conforme pode ser observado, os módulos que compõem o SNAA mobile são:
 Módulo de notificação: disponibiliza as funcionalidades de pesquisa e

consulta a vítimas, bem como cadastro de notificação de acidentes. Este
módulo disponibiliza suas funcionalidades tanto em operacionalidade
online quanto offline;
 Módulo de sincronização: disponibiliza a funcionalidade de sincronização
de dados do SNAA mobile com dados do servidor (SNAA). Este módulo só
terá funcionamento online.
As funcionalidades do módulo de notificação são apresentadas na próxima

seção.
4.1.2 Módulo de notificação
O módulo de notificação é o mais importante do SNAA mobile, onde os

profissionais de saúde irão registrar e manter dados de acidentes, além de poder
consultar dados das vítimas. O diagrama de casos de uso que o ilustra é
apresentado na Figura 11.
De modo geral, um profissional de saúde pode realizar o cadastro de uma
notificação realizando uma pesquisa prévia da vítima (Pesquisar vítima). Para
efetivar uma pesquisa, deve-se informar os seguintes dados: nome e/ou sexo. A
partir dos resultados, caso já exista uma notificação de acidente relacionada à
vítima pesquisada, pode-se reativar ou editar esta notificação, consultar o histórico
ou cadastrar uma nova notificação para esta vítima.
A reativação de uma notificação (Reativar notificação) ocorre quando um
acidente que já havia sido concluído (registro com a situação CONCLUIDO) passa a
ter alguns de seus dados editáveis (dados do acidente, imagens, dados clínicos e
tratamento). Isto poderá ocorrer devido a alguma vítima apresentar sintomas
posteriores à sua alta, mas que não deverão ser relacionados à uma nova
notificação, e sim àquela que sofreu. O histórico (Consultar histórico) apresenta os
dados de todas as notificações envolvendo a vítima pesquisada. A edição de uma
notificação (Editar notificação) é a alteração dos dados de um acidente, imagens,
dados clínicos e dados do tratamento envolvendo uma vítima.
44
Uma nova notificação compreende o cadastro de dados da vítima (Cadastrar

vítima), dados do acidente (Cadastrar acidente), imagens relativas ao acidente
(Cadastrar imagens), dados clínicos do acidente (Cadastrar dados clínicos) e dados
aplicados no tratamento (Cadastrar tratamento). Este conjunto de casos forma o
caso de uso abstrato14 Cadastrar notificação.
Figura 11 - Diagrama de caso de uso do módulo de notificação.
No cadastro de dados da vítima, o profissional deverá informar os seguintes

dados: nome, CPF, data de nascimento, sexo, escolaridade, profissão, naturalidade
(estado e município) e nacionalidade (país de origem).
Os dados do acidente requeridos são: data do acidente, as coordenadas do
local do acidente (geolocalização), período do dia (Manhã, tarde, noite ou
madrugada), município, o tipo de local, o rio (Solimões, Negro, Tapajós, etc.), o que
a vítima estava fazendo no momento do ocorrido (pescando, tomando banho, etc.),
se a vítima viu a arraia e a situação do animal.
14 Um caso de uso abstrato é um caso de uso que não é propriamente instanciado, ou seja, não
constitui um ciclo concreto de eventos. O caso de uso abstrato é realizado pelos casos com os quais
tem relacionamento.
45
No cadastro de imagens é possível selecionar ou tirar uma foto do local do

ferimento e da arraia causadora do ferimento.
Os dados clínicos referem-se ao local da picada (perna, coxa, braço, etc.), a
escala de dor (em um nível de 0 a 5, sendo 0 nenhuma dor e 5 dor insuportável), os
sintomas locais (náusea, necrose cutânea, etc.), os sintomas sistêmicos (febre, etc.)
se a vítima é portadora de alguma enfermidade (diabetes, pressão alta, etc.), se a
vítima utilizou algum remédio caseiro no ferimento e se a vítima já foi vacinada
contra tétano.
No registro de dados do tratamento, o profissional deverá informar se a vítima
ficou internada, o tratamento para os sintomas locais, tratamento para sintomas
sistêmicos e quais foram os exames realizados. Caso a vítima tenha sido internada,
será necessário informar o tempo (em dias).
Por fim, o profissional de saúde deverá informar qual o quadro clínico da
vítima e, caso necessário, poderá fazer alguns comentários sobre o acidente
(Concluir notificação).
No Apêndice A é apresentada uma descrição detalhada dos casos de uso
apresentados na Figura 11.
4.1.3 Módulo de sincronização
Conforme apresentado na Figura 9, o SNAA mobile deverá realizar troca de

dados com o SNAA, para que este possua dados atualizados para posteriores
consultas e geração de relatórios.
Na plataforma Android esta funcionalidade pode ser disparada por meio de
um evento: a presença de sinal de Internet. Conforme apresentado no Capítulo 1, o
SNAA mobile terá funcionamento online e offline. Na ausência de sinal de Internet,
estará no estado offline. Ao perceber a presença de sinal de Internet, seu estado
será alterado para online e então executará, automaticamente, a sincronia dos
dados. Os estados pelos quais a aplicação passará são ilustrados no diagrama de
máquina de estados apresentado na Figura 12.
46
Figura 12 - Diagrama de máquina de estados do SNAA mobile.

47
Conforme pode ser observado na Figura 12, o evento ‘Presença de sinal de

Internet’ dispara a ação de sincronizar dados e muda o estado de offline para online.
Neste estado, o SNAA mobile verifica notificações no banco de dados que não
foram sincronizadas (Verificando notificações na aplicação) e, caso haja, enviará os
dados ao SNAA (Enviando dados para o servidor). Após enviar dados, ou não
havendo notificações para enviar, há uma verificação por notificações atualizadas no
SNAA (Verificando notificações no servidor) e, caso haja notificações, recebe estas
notificações (Recebendo dados do servidor). Após receber os dados, ou não
havendo dados a receber, a sincronização termina.
A transição dos estados e subestados seguindo esta ordem é muito
importante, dado que uma mesma notificação pode ser manipulada pela aplicação e
pelo SNAA, mesmo que não simultaneamente. A sincronia pode ocorrer quando
houver dados da aplicação a enviar ao servidor, e/ou quando houver dados do
servidor a serem enviados à aplicação, mas não necessariamente será preciso
enviar dados para receber. A ordem aqui estabelecida visa evitar conflito de dados.
Vale ressaltar que, ao realizar a sincronização (tanto na primeira vez quanto nas
posteriores), a aplicação mobile não receberá todos os dados do servidor. Como
abordado na seção 4.1.1, somente serão recebidos dados relacionados àqueles que
já estão no aparelho em questão.
A Figura 13 apresenta um diagrama de sequência que melhor ilustra a
interação entre as classes utilizadas para sincronizar os dados.
48
Figura 13 - Diagrama de sequência da sincronização de dados.

49
A troca de mensagens observadas na Figura 13 tem início quando a

aplicação está online. Ao entrar neste estado, é disparado um método da classe
BaseActivity, o qual cria um objeto da classe SincronizacaoTask, responsável por
gerenciar a sincronização no SNAA mobile. Esta classe realiza uma consulta ao
banco de dados da aplicação (classe NotificacaoDAO) por notificações que não
foram enviadas ao servidor.
Antes das notificações, há uma consulta para verificar se o profissional está
ativo no SNAA. Isso ocorrerá devido ao caso do profissional ter realizado login
offline, onde esta verificação não é realizada (somente ocorre quando há Internet).
Caso não esteja, o sistema informa ao profissional que este não está apto a realizar
a sincronia.
Estando o profissional apto e havendo notificações, estas serão formatadas
(formato json) e enviadas por meio de uma requisição (classe NotificacaoRequest)
para um web service (classe SnaaWebService), componente responsável por
gerenciar a sincronização no lado do SNAA. Esta classe, por sua vez, fará consultas
ao banco de dados do servidor (classe NotificacaoDAO) para determinar se os
dados serão inseridos ou se atualizarão um registro existente. As condições de
verificação são:
1. Caso o acidente não possua registro no banco, será verificado se a vítima

já possui cadastro. Caso não possua, o acidente será inserido como um
novo registro, assim como a vítima, as imagens, dados clínicos e os dados
do tratamento;
2. Caso o acidente possua registro, seus dados serão atualizados;
3. Caso o acidente não possua registro no banco, mas a vítima relacionada
possua, este acidente será inserido como um novo registro e será
relacionado a esta vítima.
Em seguida à inserção ou atualização dos registros na base de dados do

servidor, há uma verificação por notificações provenientes do SNAA mobile
(referentes às notificações que o profissional possui em seu aparelho) e que foram
atualizadas. O servidor enviará, como resposta, objetos populados com as
respectivas chaves primárias das notificações registradas e com dados atualizados,
se for o caso. O web service formatará a resposta (formato json), repassando-a para
50
a classe NotificacaoRequest, para atualizar o mesmo grupo de notificações que

enviou. Isto deverá ocorrer desta maneira para manter o controle dos dados em
ambos os sentidos (do SNAA mobile para o SNAA e vice-versa), uma vez que os
dados poderão ser manipulados ora por um, ora pelo outro. Vale citar que, utilizando
esta abordagem, caso um mesmo registro seja alterado no SNAA e na aplicação,
devido à ordem de atualização apresentada, prevalecerão os dados atualizados
enviados pela aplicação.
Quanto à quantidade de dados no banco da aplicação, ela está diretamente
relacionada à capacidade de armazenamento do aparelho em que estará instalada.
Logo, um profissional poderá utilizar a aplicação em um aparelho dedicado a esta
finalidade, o que permitirá maior quantidade de dados, ou em seu equipamento
pessoal, com a ressalva do espaço de armazenamento.
Também é importante ressaltar que o SQLite, banco de dados nativo da
plataforma Android, tem suporte a um recurso de banco de dados denominado
transação, que, em linhas gerais, trata uma sequência de operações (inserções,
exclusões, atualizações, etc) como um único bloco a ser executado, garantindo que
tudo seja executado ou não (no caso de haver alguma falha, por problemas de
sintaxe ou restrições de chave, por exemplo). A transação garante que o banco de
dados volte ao estado anterior à execução, além de garantir que uma transação não
interfira na outra, caso dois ou mais registros estejam sendo manipulados ao
mesmo tempo. Isto será importante para a sincronia de dados. O mesmo ocorre
com o banco de dados do servidor, MySQL.
4.1.4 Interfaces do usuário
Nesta seção serão apresentadas as interfaces do usuário. Estas interfaces

são baseadas no visual de aplicações mobile Android e, por estas aplicações terem
suporte a múltiplas telas (smartphones e tablets), somente serão apresentadas as
telas relativas ao smartphone modelo Motorola G3. Com relação aos tablets, as
interfaces seguirão o mesmo padrão, apenas diferindo no tamanho de ícones e
fonte. As telas estão dispostas seguindo o fluxo principal da aplicação.
51
Figura 14 – Tela de login. Figura 15 - Tela de navegação.
Fonte: Próprio autor. Fonte: Próprio autor.
A Figura 14 apresenta a tela de login da aplicação mobile, onde um

profissional de saúde irá se autenticar para utilizar seus serviços. Estes serviços
podem ser acessados através da tela de navegação apresentada na Figura 15.
A Figura 16 ilustra a tela que é apresentada ao profissional de saúde após
efetuar login (ou selecionar a opção Pesquisar vítima no menu), onde poderá
realizar uma pesquisa por vítimas de acidentes. Esta ação poderá ser realizada ao
clicar no botão com desenho de lupa, no canto superior direito da tela, e informar o
nome e/ou sexo da vítima. Os resultados da pesquisa serão apresentados em duas
abas: uma contém vítimas com acidentes que possuam status PENDENTE e outra
contém vítimas com acidentes possuam status CONCLUIDO.
Na aba de vítimas com acidentes concluídos, ao clicar em um registro, um
menu oferecerá três opções: Consultar histórico, Reativar notificação, ou Nova
52
notificação. A tela de consulta do histórico de acidentes é apresentada na Figura 17

e disponibilizará a visualização dos dados de todos os acidente relativos à uma
vítima.
Figura 16 - Tela de pesquisar vítima. Figura 17 - Tela de histórico de acidentes.
A opção de reativar acidente modifica o status de um acidente e o registro,

que antes não poderia ser alterado, poderá ser manipulado novamente. A opção de
um novo acidente, neste menu, inicia um novo acidente já relacionando à vítima em
questão e suas telas são as mesmas de um novo cadastro de acidente.
53
Na aba de vítimas com acidentes em andamento, ao clicar em um registro, o

menu apresentará duas opções: Consultar histórico e Editar notificação. As telas
para edição de uma notificação são as mesmas de um novo cadastro.
As figuras de numeração 18 a 23 apresentam as telas de um novo cadastro de
acidente.
Figura 18 - Tela de notificação - dados da vítima. Figura 19 - Tela de notificação – dados do acidente.

54
Figura 20 - Tela de notificação - imagens. Figura 21 - Tela de notificação – dados clínicos.

55
Figura 23 - Tela de notificação – tratamento. Figura 22 - Tela de notificação – conclusão.
Até a presente seção foram abordados assuntos relacionados à fase de

Concepção do AUP (Descrição geral da aplicação, interface do usuário, etc). A
seguir serão abordados assuntos relacionados à fase de Elaboração, como a
apresentação da arquitetura utilizada na aplicação, o diagrama de classes e a
modelagem de banco de dados.
56
4.1.5 Arquitetura
Levando em consideração a aplicação de interfaces de usuário para variados

tamanhos de tela, bem como para organizar a estrutura da aplicação, foi utilizada
uma arquitetura baseada no padrão conhecido como MVP (Model - View -
Presenter). O MVP é uma variação do padrão MVC 15, utilizado principalmente para
construir interfaces gráficas, e é composto por três conceitos:
 Modelo (Model): trata das regras de negócio, dados e lógica de acesso a

estes dados;
 Visão (View): responsável por apresentar os dados (modelo) ao usuário e
guiar os comandos ao apresentador para atuar sobre os dados;
 Apresentador (Presenter): assume a função de mediador entre o modelo
e a visão. Ele recupera dados do modelo e retorna formatado para a
visão, e, ao contrário do típico MVC, ele também decide o que acontece
quando você interage com a visão.
O emprego desta arquitetura no SNAA mobile foi adaptada devido a

peculiaridades no envolvimento do MVP em aplicações Android. Uma grande
discussão entre desenvolvedores da plataforma reside no fato de que uma atividade
(Activity) ou fragmento (Fragment) se comporta como uma visão, recebendo
eventos do usuário e montando elementos de interface, mas também podem
comportar lógica para referenciar objetos do modelo. Muitos afirmam que isto
sobrecarrega estes componentes com responsabilidades, além de ficar fora do
padrão.
Mas há de se levar em consideração a necessidade do desenvolvedor e do
projeto. Por exemplo, no MVP, uma visão sempre está ligada a um apresentador,
independente da quantidade de visões. Em código, este apresentador pode ser
aplicado utilizando-se interfaces, que teriam métodos para intermediar um modelo e
uma visão. Porém, dependendo do tamanho do projeto, a utilização de muitas
interfaces apenas produziria mais código que, ao fim, realizaria a mesma coisa que
seguir um caminho onde o apresentador e a visão estão em uma mesma classe.
Neste sentido, o modo como esta arquitetura foi aplicada neste projeto não
utiliza interfaces para a comunicação entre modelo e visão, a lógica de visão e do
15 MVC – Model-View-Controller – é um padrão de projeto, amplamente utilizado em aplicações web,
cujo objetivo é separar os dados de negócio, a interface do usuário e o fluxo da aplicação.
57
apresentador estará em atividades e/ou fragmentos. Na Figura 24 é ilustrada a

disposição dos conceitos do MVP neste trabalho.
Figura 24- MVP no SNAA mobile.

58
4.1.6 Diagrama de classes
Para apresentar a estrutura das classes utilizadas no SNAA mobile foram

modelados dois diagramas de classe: um sob a visão de análise, em que se leva em
consideração a modelagem dos conceitos e atributos relacionados ao domínio do
problema; e outro sob a visão de projeto, que demonstra aspectos de
implementação. Na Figura 25 apresentado o diagrama de classes sob a visão de
análise e a Figura 26 sob a visão de projeto.
Ao observarmos os diagramas, é possível perceber que a principal diferença
entre eles é a existência de uma classe - na visão de projeto - denominada
AbstractBean, que contem três atributos: id, snaaId e codigoSincronizacao. A
utilização destes atributos será explanada na seção 4.4 – Implementação de
mudanças. No Apêndice C são apresentadas descrições sucintas das
responsabilidades das classes mais relevantes da aplicação, considerando o
diagrama de classes na visão de projeto.
59
Figura 25 – Diagrama de classes na visão de análise.

60
Figura 26 – Diagrama de classes na visão de projeto.

61
4.1.7 Diagrama Entidade Relacionamento (DER)
O diagrama entidade-relacionamento permite visualizar a estrutura de um

banco de dados por meio de tabelas e seus relacionamentos. Em geral, cada
entidade do banco corresponde a uma classe do diagrama de classes, não
necessariamente sendo isto uma regra. No caso da aplicação mobile, podemos
perceber, em comparação ao diagrama de classes (visão de projeto) que somente
algumas classes não tem seu correspondente no banco. Na Figura 27 é
apresentado o DER (Diagrama Entidade Relacionamento) do SNAA mobile.
Figura 27 – Diagrama de entidade relacionamento.

62
Esta seção apresentou a primeira etapa do processo de evolução (Solicitação

de Mudança) ilustrado na Figura 3, encaixando-a nas fases de Concepção e
Elaboração do AUP. Neste trabalho, a próxima etapa do processo de evolução -
Análise de Impacto - também se encaixa nestas fases do AUP e será apresentada a
seguir.
4.2 Análise de impacto
Na análise sobre o SNAA mobile, apresentada na Seção 4.1, foi identificado

que o SNAA deveria receber um trabalho de manutenção para que pudesse integrar
o serviço de sincronia de dados. Este trabalho de manutenção foi realizado em dois
módulos já existentes: o módulo de notificação e acompanhamento; e o módulo de
consultas e geração de relatórios – além da inclusão de um novo módulo,
denominado ‘Módulo de serviços mobile’. Este novo módulo contém uma classe
Web Service e classes de suporte, com as funcionalidades necessárias para
tratamento das requisições provenientes do SNAA mobile. A configuração do SNAA
com a adição deste módulo foi ilustrada na Figura 10.
A alteração no módulo de notificação e acompanhamento foi realizada devido
à necessidade de alterar suas consultas para levar em consideração os dados
obtidos via SNAA mobile, uma vez que eles também serão manipulados pelo SNAA.
Com relação ao módulo de consulta e geração de relatório, o SNAA disponibiliza um
conjunto pré-definido de opções de consultas (por exemplo, consulta de município,
período de acidentes, tipo de relatório etc.) e os resultados das consultas são
exibidos na forma de relatórios. A quantidade de relatórios e as consultas que geram
os relatórios sofreram alterações. Os relatórios atuais gerados pelo SNAA são:
 Relatório de acidentes por Município;
 Ranking de acidentes por Município;
 Ranking de acidentes por Sexo;
 Ranking de acidentes por Faixa Etária;
 Ranking de acidentes por Sintomas;
 Ranking de acidentes por Quadro de Saída
Conforme apresentado anteriormente, algumas informações no cadastro de
acidentes, no SNAA mobile, sofreram modificações para otimizar e melhorar a
interação com os usuários, uma vez que o formulário de cadastro de acidentes do
SNAA é extenso. Esta abordagem diferente para a captura dos dados não implicou
63
em perda de dados necessários para geração de relatórios, mas teve algumas

ressalvas.
O relatório de ‘Ranking de acidentes por sintomas’, por exemplo, foi
desabilitado, devido ao modo diferente em que os dados de sintomas são
cadastrados pelo SNAA, onde os dados relativos aos sintomas apresentados por
uma vítima são inseridos um registro por sintoma, e como serão adquiridos pelo
SNAA mobile, onde os dados relativos aos sintomas será um campo de texto
contendo todos os sintomas, ou seja, um registro por notificação. Logo, a consulta
para a geração deste relatório poderia apresentar margem de erro devido à inclusão
de dados com erros de escrita e palavras com acentuação, além de diferir no modo
em que é filtrado pelo banco de dados.
A situação do módulo de consultas e geração de relatórios, bem como as
diferenças nas informações do cadastro de uma notificação no SNAA mobile, e a
sincronia de dados, evidenciou a necessidade realizar modificações na estrutura da
base de dados do SNAA. As modificações serão abordadas na seção 4.4.2, que
trata de sua implementação.
Desta forma, objetiva-se minimizar o impacto na realização de consultas e
geração de relatórios, bem como na sincronia de dados. Vale ressaltar que a
alteração na estrutura do banco de dados do SNAA respeita as restrições de chaves
estrangeiras e campos obrigatórios.
4.3 Atividade de planejamento de versões
A implementação do SNAA mobile e das modificações no SNAA foram

subdividas nas seguintes atividades:
1. Implementação e testes do módulo de notificação;

2. Implementação e testes da geolocalização de um acidente;
3. Implementação e testes de classe de suporte (web service);
4. Implementação e testes do módulo de sincronização de dados;
5. Implementação e testes da alteração nos módulos de notificação e
acompanhamento;
6. Implementação e testes da alteração no módulo de consulta e geração de
relatórios.
64
As atividades 1, 2, e 4 correspondem à implementação do SNAA mobile e as

atividades 3, 5 e 6 correspondem às modificações realizadas no SNAA, seguindo a
ordem numerada. A ordem foi definida devido às características das atividades: 1 e
2 relacionadas ao cadastro de notificação; 3 e 4 relacionadas à sincronia de dados;
5 e 6 relacionadas às alterações nos módulos do SNAA. Isto que permitiu melhor
integração dos serviços, bem como a realização de testes.
A implementação da aplicação e alterações no SNAA foram divididas para a
entrega em quatro releases. O Quadro 7 apresenta a divisão das atividades
distribuídas em períodos de 60 dias. A primeira release abrangeu as atividades 1 e 2
(duração de 120 dias), focando uma versão do SNAA mobile com módulo de
notificação e a geolocalização de acidentes. A segunda release focou o módulo de
sincronização e dispôs de mais tempo devido à criticidade desta funcionalidade (60
dias). A terceira release teve foco nas alterações dos módulos do SNAA (45 dias). A
última release foi realizada para aperfeiçoamento da aplicação e das alterações no
SNAA, refatoração e correções de código. Durante intervalos de mais ou menos 60
dias houve iterações, para verificar as atividades realizadas, atualizar artefatos,
realizar testes e garantir que a implementação estava seguindo o que foi definido,
principalmente para que não houvesse empecilhos na parte de sincronia dos dados.
65
Quadro 5 – Releases do SNAA mobile.
1ª 4ª
2ª release 3ª release
release release
Atividades
120
60 dias 60 dias 45 dias 20 dias
dias
Implementação e testes do módulo
X
de notificação
Implementação e testes da
X
geolocalização de um acidente
Implementação e testes de classes

X
de suporte (web services)
Implementação e testes do módulo

X X
de sincronização de dados
alteração nos módulos de X X
notificação e acompanhamento
alteração no módulo de consulta e X X
geração de relatórios
Aperfeiçoamento dos módulos da
X
aplicação
Aperfeiçoamento das alterações no

X
SNAA
4.4 Implementação de mudanças
A etapa de implementação de mudanças está relacionada diretamente à fase

de Construção do processo AUP. Esta, por sua vez, está relacionada diretamente à
construção do código-fonte: implementação de classes, interfaces do usuário, web
services, entre outros componentes. A seguir serão descritos alguns detalhes da
implementação, dividida em duas subseções para melhor organização do que foi
realizado no SNAA mobile e no SNAA, incluindo trechos do código relacionados
(apenas para exemplificar o que for explanado) e que foram pertinentes ao seu
funcionamento.
66
4.4.1 Implementação do SNAA mobile
Nesta etapa, a parte com maior dificuldade foi a codificação utilizando a

plataforma Android, que não era totalmente conhecida pelo desenvolvedor, levando
muitos componentes e meios de implementação a serem realizados ao mesmo
tempo em que se estudava a plataforma, utilizando materiais de pesquisa, como
sites, livros, fóruns, etc.
4.4.1.1 Versão do SDK
Para iniciar a construção de uma aplicação na plataforma Android, é

necessário realizar o download do seu kit de desenvolvimento (SDK). Até o
momento da escrita deste trabalho, o Android Studio, ferramenta oficial utilizada
neste trabalho, apresenta as opções de versões junto com um informativo de
quantos dispositivos (segundo estimativas do Google, baseando-se nos aparelhos
que realizam downloads em sua loja virtual, o Google Play), possuem suporte à
opção escolhida, dando uma dimensão da abrangência que sua aplicação terá.
Essa escolha é importante devido ao fato de que, em constante evolução,
há funcionalidades em novas versões que são modificadas, bibliotecas que podem
ser substituídas, entre outras mudanças. É necessário dar atenção aos dispositivos
com versões anteriores e também posteriores à que você utiliza na construção de
sua aplicação, uma vez que há probabilidade de serem lançados dispositivos com
versões superiores à sua. O comportamento esperado de um trecho de código pode
não funcionar da maneira esperada em todos os aparelhos - ou pelo menos
diferente da que você utiliza como parâmetro em seus testes, o que não significa
que sua aplicação irá parar de funcionar instantaneamente, mas é necessário
atenção para componentes e funcionalidades em versões anteriores e superiores.
Apesar de versões mais recentes (a versão atual do SDK no momento da escrita
deste trabalho é a 24, o Android 7.0 Nougat), a escolhida para o desenvolvimento
do SNAA mobile foi a versão 19 do SDK, Android 4.4 KitKat.
O trecho de código apresentado na Figura 28 demonstra a execução de um
procedimento necessário para efetuar o login que verifica a versão do SDK no
aparelho para decidir como será executada. Nesta situação, caso isso não fosse
realizado, causaria o não funcionamento da mesma (em determinada versão).
67
Figura 28 – Execução de thread para login na aplicação.
Fonte – Próprio autor.
4.4.1.2 Permissões
Grande parte das aplicações móveis atuais permitem acesso a vários

recursos do dispositivo em que se encontram: Internet, câmera, localização através
de GPS, acesso à músicas em um cartão de memória, etc. Todas as ações que
necessitam acessar algum recurso do dispositivo (software ou hardware) devem,
obrigatoriamente, solicitar permissão do usuário. Estas solicitações, em geral, são
apresentadas ao usuário antes de sua utilização, no momento da instalação da
aplicação. A Figura 29 ilustra a listagem dos recursos que o SNAA mobile poderá
acessar. Logicamente, se você prosseguir com o download de tal aplicação, estará
dando permissão para que os recursos listados sejam utilizados.
As permissões são restrições que limitam o acesso à parte do código ou aos
dados de um dispositivo. A limitação é imposta para proteger dados essenciais que
podem sofrer mau uso e distorções ou prejudicar a experiência do usuário. O
gerenciamento das permissões necessárias para uma aplicação é organizado em
um arquivo de configuração que descreve todos os recursos utilizados chamado
Android Manifest.
Cada permissão é identificada por uma etiqueta exclusiva. Geralmente a
etiqueta indica a ação que foi restringida. A Figura 30 apresenta um trecho do
arquivo de configuração relativo a algumas permissões necessárias utilizadas pelo
SNAA mobile.
68
Figura 29 – Exemplo de permissões solicitadas.
Figura 30 – Permissões do SNAA mobile.

69
A seguir há uma breve descrição sobre as permissões apresentadas na

Figura 43. A listagem das permissões que podem ser utilizadas pode ser encontrada
no site16 dos desenvolvedores Android, com mais detalhes.
 android.permission.INTERNET: permite o acesso à Internet. Por se tratar

de uma permissão abrangente, é necessário ter cuidado para não permitir
manipulação indesejada de dados do usuário. Na aplicação mobile é
utilizada para efetuar o primeiro login e a sincronização de dados;
 android.permission.ACCESS_NETWORK_STATE: permite acesso à
informações sobre conexões de rede. Esta permissão é utilizada para
saber o tipo de conexão utilizada (WiFi ou rede móvel), auxiliando no
correto uso de dados do usuário. Na aplicação mobile é utilizada para
efetuar login e sincronização de dados;
 android.permission.WRITE_EXTERNAL_STORAGE: permite acesso à
escrita de arquivos no cartão de memória do dispositivo. Na aplicação
mobile é utilizada para armazenamento do banco de dados as imagens
necessárias.
 android.permission.ACCESS_FINE_LOCATION: permite acesso à
localização (coordenadas geográficas) do dispositivo.
 android.permission.CAMERA: permite acesso à câmera do dispositivo.
4.4.1.3 Layouts para múltiplas telas
Não obstante ao limitado espaço de armazenamento e também o reduzido

poder de processamento, o desenvolvimento móvel também trás consigo a
preocupação da construção de interface de tela para uma grande variedade de
dispositivos. Uma boa aplicação deve apresentar layouts confortáveis para seus
usuários, independente do dispositivo que seja utilizado. E isto deve ser realizado
tão cedo o projeto comece a ser codificado, pois mudanças tardias levam a um
retrabalho.
O Android disponibiliza suporte a múltiplas telas levando em consideração
alguns conceitos apresentados a seguir.
16 Site: https://developer.android.com/reference/android/Manifest.permission.html
70
 Tamanho de tela: tamanho físico do dispositivo, baseado na diagonal da

tela;
 Densidade de tela: quantidade de pixels dentro de uma área física da tela
- quanto menor a densidade, menor a quantidade pixels. É referenciado
pela sigla dpi (dots per inch, traduzido pontos por centímetro);
 Orientação da tela: orientação da tela do ponto de vista do usuário,
podendo ser no modo retrato (com o dispositivo na vertical) ou paisagem
(com o dispositivo na horizontal);
 Resolução: número total de pixels físicos em uma tela. Diferentemente da
densidade, este totaliza toda a tela e não uma área específica. Quando
adicionado o suporte à múltiplas telas, as aplicações não devem trabalhar
com a resolução e sim com o tamanho de tela e a densidade.
 Independência de densidade de pixels (dp): é uma unidade virtual de
pixels, adotada pelo Android, para expressar uma dimensão e/ ou uma
posição de um componente de forma independente da densidade.
Estes conceitos têm aplicação em relação a imagens, e à disposição de

componentes em tela. Isto é mais visível quando uma aplicação pode ser utilizada
em smartphones e tablets, pois o layout deverá ser adaptado para cada dispositivo.
O Android lida com a maioria do trabalho de ajuste da interface do usuário à
tela do dispositivo no qual é utilizado (escalamento e redimensionamento de
componentes). Isto é realizado através dos chamados qualificadores de
configuração, que são ‘palavras-chave’ para referenciar dado tamanho de tela, e
que permitem utilizar recursos (imagens, tamanho de fonte, etc) baseados nas
características da tela do dispositivo em questão. O Quadro 7 apresenta os
qualificadores utilizados para configurar uma aplicação à tela de um dispositivo.
Para aplicar os qualificadores de configuração, basta utilizar o nome do
qualificador no nome do diretório correspondente ao tamanho de tela desejado, no
seguinte formato: <recurso>-<qualificador>, onde <recurso> é o padrão de recursos
de uma aplicação Android (drawable, values, etc) e <qualificador> é um dos
qualificadores apresentados no quadro 6. Ao compilar um projeto, o próprio Android
reconhece e direciona o conteúdo da pasta certa ao dispositivo em questão.
71
Quadro 6 – Qualificadores de configuração.
Característica da tela Qualificador Descrição

Pequeno (small) Recursos para telas pequenas.
Recursos para telas normais (é o
Normal (normal)
tamanho base).
Tamanho
Grande (large) Recursos para telas grandes.
Recursos para telas extra
Extra-grande (xlarge)
grandes.
Recursos para telas de baixa
ldpi
densidade (120 dpi).
Recursos para telas de
mdpi densidade média (160 dpi) – é a
densidade base.
Recursos para telas de alta
hdpi
Densidade
Recursos para telas de extra alta
xhdpi
Recursos para telas de extra
xxhdpi
extra alta densidade (480 dpi).
Recursos para telas de extra
xxxhdpi extra extra alta densidade (640
dpi).
Fonte: Próprio Autor.
A Figura 31 ilustra a estrutura de pastas do SNAA mobile utilizando

qualificadores e a Figura 32 apresenta uma da aplicação referente a dispositivos
com tamanhos diferentes. A imagem do tablet está com o qualificador large para
tamanho e mdpi para densidade e o smartphone está com o qualificador normal
para tamanho e mdpi para densidade.
72
Figura 31 – Estrutura de pastas com a utilização de qualificadores.
Figura 32 – Exemplo de telas com qualificadores.
Cada tamanho e densidade geral alcançam uma faixa dos tamanhos e

densidades existentes. Por exemplo, dois dispositivos que reportem um tamanho de
73
tela normal podem ter tamanhos de tela e aparência um pouco diferentes quando
medidos a mão. De forma similar, dois dispositivos que reportem uma densidade de
tela hdpi, por exemplo, podem ter uma densidade de pixel um pouco diferente. O
Android torna essas diferenças abstratas para a aplicação, de forma que você pode
fornecer uma interface de tela para cada tamanho e densidade e deixar que o
sistema manipule qualquer ajuste final necessário.
Além disso, o Android provê recursos para que o desenvolvedor possa
controlar a interface de sua aplicação para algum específico tipo de tela, pois pode
ocorrer que o layout produzido não se encaixe em telas pequenas, ou seja
otimizada para telas grandes, ou ainda seja otimizada para orientação em retrato e
paisagem, por exemplo. A Figura 43 também ilustra esta situação, por meio do
diretório values-w820dp que significa a aplicação de um layout específico para telas
com largura (width) de 820 dp.
Portanto, é importante observar que isto não retira a responsabilidade do
desenvolvedor de trabalhar na construção correta das interfaces. Sabendo destas
diretivas, esta atividade se torna menos trabalhosa.
4.4.1.4 Tratamento de imagens
Por se tratar de uma aplicação direcionada a dispositivos móveis, que em sua

maioria possuem câmera embutida e fácil mobilidade, foi sugerido que o SNAA
mobile realizasse a captura da imagem da arraia causadora do acidente e também
do ferimento causado por ela. A integração de uma aplicação com a câmera de um
dispositivo pode ocorrer de duas maneiras: a primeira, mais simples, utiliza a
câmera nativa disponibilizada pela própria plataforma Android; a outra permite que o
desenvolvedor tenha um controle maior, quase total, do hardware da câmera. Como
o objetivo do SNAA mobile é somente salvar e enviar as imagens a um servidor, não
há necessidade de manipular totalmente a câmera e, por isso, foi utilizada a
primeira maneira.
A chamada da funcionalidade da câmera nativa se dá por meio de um intent
(Capítulo 3, seção 3.3.2), que permite que sejam definidas operações a serem
efetuadas, como iniciar o GPS ou a câmera, por exemplo. Como já apresentado, um
objeto intent carrega informações que o sistema Android usa para determinar o
74
componente a iniciar, além de informações que o componente receptor usa para

realizar a ação adequadamente. No caso da captura de imagem, o componente a
ser chamado é a câmera e a informação a ser passa é o caminho onde salvar a
imagem.
As dimensões da imagem capturada levam em consideração o tamanho do
dispositivo em questão, bem como a resolução da câmera. Em geral, conforme mais
moderno o dispositivo, melhor sua resolução e mais ‘pesada’ é a imagem, o que
tornou sua manipulação necessária para que a sua inserção e recuperação no
banco de dados não fosse sobrecarregar a aplicação.
A plataforma Android possui algumas bibliotecas que permitem a
manipulação de imagens. Na Figura 33 a imagem é ajustada utilizando-se da lógica
dos qualificadores – o caminho R.dimen.image_<width/height> procura de acordo
com o qualificador - , realiza um cálculo, utilizando a biblioteca matemática Math,
para atribuir uma escala redutiva sem que a imagem perca qualidade, e a
transforma em um arquivo bitmap, formato manipulável pela aplicação.
Figura 33 – Ajuste de imagens.

75
Seguindo a forma de armazenamento de imagens do SNAA, o SNAA mobile

salva as imagens obtidas em seu próprio banco de dados. O campo em uma tabela
destinado à imagem é do tipo BLOB (Binary Large Objects), amplamente utilizado
para armazenamento de dados multimídia como fotos e vídeos, e que o MySQL e
SQLite, utilizados neste trabalho, suportam.
A Figura 34 apresenta dois importantes métodos relacionados a
armazenamento e recuperação de imagens: o primeiro é chamado getBytesToArray,
responsável por transformar uma imagem do formato bitmap para uma cadeia de
bytes, para que possa ser armazenada no banco de dados. Isto é realizado por
meio de um objeto que possa comportar os bytes da imagem (classe
ByteArrayOutpurStream) que passa por um processo de compressão de formato
(JPEG é um formato mais leve que PNG, formato padrão gerado pelo Android) e
tamanho (mínimo de 75% de qualidade) – objetivando ficar mais ‘leve’; o segundo
método é chamado setBitmapFromBytes que realiza o contrário do método anterior,
ou seja, é responsável por transformar a cadeia de bytes em bitmap, para que
possa ser manipulado corretamente pela aplicação. Isto é realizado através da
geração de um arquivo temporário onde os bytes são escritos.
Figura 34 – Transformação de imagem em bytes e vice-versa.
4.4.1.5 Geolocalização
Uma das demandas que resultaram neste trabalho foi a determinação da

localização (captura de coordenadas geográficas) da ocorrência de um acidente. A
captura da localização de um dispositivo pode ser feita por meio de provedores,
76
como torres de telefonia celular e redes Wifi, ou pelo GPS embutido no dispositivo.
Obter esta informação pode ser um pouco complicada, há alguns desafios na
captura correta da localização de um usuário. Algumas delas incluem:
 Multiplicidade de fontes: GPS, id do celular, e WiFi - cada um pode

fornecer uma pista para a localização do usuário. Determinar qual usar e
confiar é uma questão de trade-off na precisão, velocidade e consumo de
bateria;
 Movimentação do usuário: o usuário está em constante movimento e então
sua localização muda, devendo ser recalculada frequentemente;
 Variação de precisão: a localização estimada de cada fonte pode não ser
consistente com sua precisão. Uma localização obtida 10 segundos atrás
de uma fonte pode ser mais precisa que uma nova localização de uma
nova (ou até da mesma) fonte.
No Android a classe responsável por fornecer acesso aos serviços de

localização, como determinar a fonte a ser utilizada e atualização de coordenadas, é
a LocationManager. No SNAA mobile, antes de obter as coordenadas, esta classe é
utilizada para verificar se o GPS do aparelho está habilitado ou não. Isto deverá ser
feito devido ao fato da aplicação também ter funcionalidade offline, o que restringirá
a fonte de localização unicamente ao GPS – estando neste estado, o processo não
levará em consideração as outras fontes. Quando houver rede, as outras fontes
serão levadas em consideração para mapear a localização.
O trecho de código da Figura 35 ilustra a situação em que é verificado se o
GPS do dispositivo está habilitado, utilizando o método isProviderEnabled,
passando como parâmetro o provedor do qual deseja obter a localização. Caso o
GPS não esteja, a aplicação dispara um comando (intent) para que as
configurações do aparelho sejam disponibilizadas ao usuário, para que habilite (isto
não será feito de forma automática, pois o usuário é quem deve permitir se informa
sua localização).
77
Figura 35 – Verificação de disponibilidade de GPS.
Para capturar as coordenadas, a classe LocationManager utiliza um método

que requisita do provedor atualizações de localização, e necessita de uma classe
que tenha implementado uma interface chamada LocationListener. Esta interface
implementa métodos que são chamados quando ocorrem eventos relacionados à
localização, sendo o principal deles o método OnLocationChanged, onde ocorre, de
fato, a captura das coordenadas. A Figura 36 apresenta o trecho de código relativo à
situação supracitada.
Figura 36 – Captura de coordenadas.

78
Como já apresentado, obter a localização do usuário pode ser uma tarefa

complicada, e a situação ‘se agrava’ mais em se tratando de obter somente do GPS
– quanto mais longe a fonte, maior o tempo de. Quando há acesso à redes, isto se
torna mais rápido por causa da triangulação feita por torres de telefonia e redes Wifi,
presentes em muitos lugares. De certo é necessário compreender que esta tarefa
será, no mínimo, demorada e poderá apresentar algumas diferenças de precisão.
4.4.1.6 Envio e recebimento de dados
Para cumprir seu principal objetivo, o SNAA mobile deverá, como ressaltado
várias vezes ao longo deste trabalho, sincronizar seus dados com o SNAA. A troca
de dados entre os dois ocorrerá em dois momentos: no primeiro login e na
sincronização de notificações.
O primeiro login deverá, obrigatoriamente, ser realizado com o dispositivo
tendo conexão à Internet, para verificar a autenticidade do profissional de saúde e
registrar seus dados na base de dados do SNAA mobile – para posteriores logins
offline. Neste primeiro momento também será utilizado um recurso do Android
chamado Shared Preferences, o qual permite ler e salvar pequenas informações de
uma aplicação em arquivos do próprio dispositivo, o qual auxiliará ao efetuar login
automaticamente (sem a necessidade do profissional ficar constantemente digitando
seus dados) tanto online quanto offline. Para posteriores logins em que o dispositivo
esteja conectado à Internet, somente haverá verificação do status do profissional,
para saber se está apto a notificar acidentes.
Para ocorrer sincronização de notificações o SNAA mobile deverá, como
apresentado na Figura 18 (diagrama de máquina de estados), perceber a presença
de sinal de Internet. Esta tarefa foi implementada utilizando um recurso chamado
Broadcast Receiver, componente da plataforma Android responsável por receber e
tratar eventos, os broadcasts, provenientes do próprio sistema ou de outras
aplicações. Em geral, este componente é aplicado em uma atividade (activity) e será
utilizado ao longo do ciclo de vida do SNAA mobile, dado que a sincronia, por
consumir dados (dados, neste sentido, são os dados de rede Wifi ou da operadora
telefônica), deve ocorrer somente quando a aplicação estiver sendo utilizada, não
devendo consumir dados quando estiver em segundo plano.
79
A Figura 37 apresenta alguns estados do ciclo de vida da atividade (activity)

que implementa o BroadcastReceiver. Os estados apresentados nesta figura são
aqueles abordados no Capítulo 3, seção 3.3.3.
A Figura 37 apresenta alguns estados do ciclo de vida da atividade (activity)
que registra o broadcast que verifica a conectividade do dispositivo. Isto é
implementado através do método registerReceiver, lógica aplicada no método
onResume, chamado logo antes da atividade ser iniciada (ou reiniciada), para não
haver uma sobrecarga com o recebimento de intents quando a aplicação não estiver
em uso (em segundo plano). Neste caso o broadcast deverá ser cancelado – o
método onPause executa o método unregisterReceiver.
Figura 37 – Ciclo de vida do broadcast de sinal de Internet.
Ao ser informado sobre alterações na conectividade do dispositivo, informado

pelo intent filter, o broadcast irá executar o método onReceive, onde deve ser
implementada a lógica de quando o evento ocorre, neste caso, sendo disparado o
80
método sincronizarDados. Por se tratar de uma operação que demanda tempo, uma
vez que a sincronia depende da velocidade de conexão à Internet do dispositivo,
este método instancia uma classe chamada SincronizacaoTask, que estende a
classe AsyncTask - componente do Android que permite a realizar uma tarefa em
segundo plano (background) e apresentar o resultado na interface de usuário. Isto
permitirá ao usuário continuar os cadastros de notificações durante uma sincronia,
por exemplo.
O principal método de uma AsyncTask é chamado doInBackground. A Figura
38 ilustra a implementação deste método na classe SincronizacaoTask.
Como ilustra a Figura 38, primeiramente há a recuperação da conexão com o
banco de dados do dispositivo (método getDatabase) para realizar consulta às
notificações que precisam ser enviadas ao SNAA. Esta consulta, a principal do
SNAA mobile, é apresentada na Figura 39.
Figura 38 – Método principal da classe de sincronização.

81
Figura 39 – Consulta de notificações para sincronização.
Esta consulta objetiva verificar, nas tabelas que fazem parte da notificação de
um acidente, registros que se encontram com o campo COL_REGISTRO_ENVIADO
igual à false, indicando que estes devem ser enviados ao servidor. Esta situação
ocorre quando um registro é inserido ou alterado no banco de dados do SNAA
mobile. Este campo é sempre atualizado para true quando o registro é enviado.
As notificações resultantes da consulta são armazenadas em uma lista e
enviadas em um objeto da classe NotificacaoSender, o qual também comporta
dados do profissional, para autenticação (haverá validação do profissional
novamente, pois há casos em que o mesmo encontra-se inativo, não podendo
realizar a sincronização). Este objeto é passado como parâmetro para um objeto da
classe NotificacaoRequest, responsável por realizar a requisição, especificando o
caminho requisitado e tratando os dados a serem enviados (transformação do
objeto em json).
Para efetuar a requisição, o método execute da classe NotificacaoRequest é
disparado e tem início o envio das notificações. A resposta desta requisição é
encapsulada em um objeto chamado SincroniaResponse, responsável por informar
à atividade se houve alguma falha (atributo estático RETURN_FAILED), e neste
caso, informa ao profissional qual o problema encontrado; se a sincronia foi
realizada com sucesso (atributo estático RETURN_OK); ou se não há nada a
sincronizar (atributo estático RETURN_NOTHING).
Caso os dados tenham sido enviados com sucesso, tem início uma transação
para tratar a resposta do SNAA, que são as mesmas notificações enviadas, porém
82
atualizadas com os ids gerados (ou atualizados) no banco de dados do servidor, e

são atualizadas no banco de dados do SNAA mobile (método atualizarNotificacoes).
A ordem de sincronização estabelecida foi primeiramente enviar notificações
cadastradas e/ ou alteradas, depois receber as notificações do servidor. Vale
ressaltar que as notificações a serem recebidas são somente referentes àquelas
que já estão presentes na aplicação, ou seja, notificações provenientes da aplicação
e que foram atualizadas no servidor.
Com relação às classes envolvidas em uma notificação, como apresentado
na Figura 38 (diagrama de classes na visão de projeto), elas estendem uma classe
denominada AbstractBean, que possui somente três atributos:
 id: serve para referenciar, na perspectiva de objetos, a chave primária de

um registro no banco de dados do SNAA mobile. Não tem importância para
a sincronização;
 snaaId: serve para referenciar a chave primária de um registro salvo no
banco de dados do SNAA. É a resposta esperada da sincronização;
 codigoSincronizacao: serve como um recurso para a situação em que
algo interfira a sincronização, e faça com que o SNAA mobile não obtenha
a chave primária de um registro salvo no banco de dados do SNAA. O
valor deste atributo é gerado no SNAA mobile, nas classes envolvidas em
uma notificação, e é um código único universal - um UUID 17 - que também
é enviado ao SNAA e faz referência ao registro de notificação.
Para melhor exemplificar a utilização do atributo codigoSincronizacao,

imagine que, em determinado momento da sincronização, haja alguma interrupção,
por uma falha na rede, por exemplo. Neste caso não haverá resposta das
notificações que já foram cadastradas no SNAA. Numa posterior sincronização, não
tendo a referência da chave primária do registro salvo no SNAA, poderá ocorrer
duplicação e/ou exclusão indesejada de registros. O papel do atributo
codigoSincronizacao será dar a referência para que estas situações não ocorram,
até a correta captura das chaves primárias por parte do SNAA mobile.
17 Sigla para Universally Unique Identifier, traduzido identificador único universal, é um identificador
numérico de 128 bits – 32 caracteres hexadecimais - com o objetivo de facilitar a troca de
informações em sistemas distribuídos. Para se ter ideia, é maior a probabilidade de você ser atingido
por um meteorito que haver repetição de UUID’s.
83
4.4.2 Implementação de mudanças no SNAA
A seguir serão apresentadas algumas mudanças implementadas no SNAA

para que pudesse integrar os serviços do SNAA mobile. A principal delas foi a
implementação módulo de serviços mobile, responsável por requisições
provenientes da aplicação.
4.4.2.1 Módulo de serviços mobile
Conforme apresentado na Figura 10, o SNAA deverá comportar mais um

módulo, denominado módulo de serviços mobile, o qual será responsável por tratar
da comunicação com o SNAA mobile. A Figura 40 apresenta um diagrama de
pacotes com principais classes que o compõem.
Figura 40 – Módulo de serviços mobile.
Como já apresentado anteriormente, a troca de dados entre SNAA e SNAA

mobile dar-se-á em dois momentos: login e sincronia de notificações. Estas duas
ações, bem como a validação do profissional realizada em ambas, foram
implementadas na principal classe que, de fato, responderá às requisições,
denominada SnaaWebService, um web service desenvolvido utilizando arquitetura
REST. Como já tratado no Capítulo 3 (seções 3.4 e 3.5), para consumir serviços
84
baseados na arquitetura REST, deve-se informar o caminho do serviço, sua URL.

No SNAA isto foi implementado através da classe RestApp, a qual utiliza uma
anotação, a @ApplicationPath, que identifica o caminho do sistema (diretório em
que se encontram os serviços) que serve como a base para todos os URIs de
recursos fornecidos por este caminho.
Por exemplo, o caminho do serviço que irá processar as notificações é
http://nome_do_servidor/snaa/webservice/processarNotificacoes, sendo ‘/snaa’ o
nome do sistema, ‘/webservice’ o caminho anotado com @ApplicationPath, e
‘/processarNotificacoes’ o nome do serviço (não necessariamente precisa ser
idêntico ao nome do método, mas é uma boa prática de programação). A Figura 41
apresenta o código relacionado a este serviço.
Figura 41 – Serviço de processamento de notificações do web service.
Na Figura 41 é possível perceber a utilização de mais anotações que

auxiliam o correto processamento das notificações. A primeira é @Transactional,
85
uma anotação do framework hibernate que o informa sobre a necessidade de

gerenciamento de transação no método em questão. Em seguida, a anotação
@POST informa que o método em questão somente irá receber requisições do
método POST. As duas anotações seguintes - @Consumes e @Produces informam,
respectivamente, o formato de entrada e saída dos dados a serem processados no
método, que é o json (MediaType.APPLICATION_JSON). A útlima anotação, @Path,
é relativa ao nome com o qual este serviço será acessado.
O método recebe uma string json e utiliza o método gerarMapper para ser
convertida a um objeto da classe NotificacaoReceiver. A classe ObjectMapper é
utilizada para atribuir configurações - como formato de data, uso de anotações,
conversão de números para string, etc - ao json que irá ser gerado e/ou recebido. A
Figura 54 ilustra a configuração aplicada para a formatação json. Vale ressaltar esta
configuração também é utilizada no SNAA mobile.
Figura 42 – Configuração de formatação json.
Em sequência, é verificado se o profissional que envia as notificações está

ativo no sistema. Caso não esteja, nada é processado e é enviada uma mensagem
informando que o profissional não pode sincronizar os dados. Caso contrário, a
sincronia tem início com o método processarNotificacoesRecebidas, onde são
processadas as notificações provenientes do SNAA mobile: cadastro ou atualização
de dados da vítima, acidente, as imagens, dados clínicos e tratamento. Em seguida
é executado o método verificarNotificacoesAEnviar, que executa uma consulta para
resgatar notificações que foram alteradas no SNAA e são provenientes do SNAA
86
mobile. O resultado destes dois métodos é adicionado em uma lista da classe

NotificacoesResponse, formatado em json (método writeValuesAsString) e enviado
como resposta.
Vale ressaltar que o processamento de cada notificação verifica as condições
apresentadas na seção 4.1.3, quando executado o método
processarNotificacoesRecebidas.
4.4.2.2 Banco de dados
Conforme apresentado na seção 4.2, algumas mudanças foram

implementadas no banco de dados do SNAA para entrar em conformidade com o
SNAA mobile e efetuar corretamente a sincronia de dados. Algumas das principais
modificações realizadas estão listadas a seguir:
 Dois campos adicionais na tabela de prontuário, para receber os dados de

sintomas e doenças, que faziam uma relação muitos-para-muitos com a
tabela de prontuário, e que agora farão parte da tabela de prontuário;
 Um campo adicional na tabela de tratamento referente aos exames
realizados, que faziam uma relação com uma tabela de exame;
 Um campo adicional em todas as tabelas que fazem parte de uma
notificação, para saber se o registro foi enviado ao SNAA mobile;
 Adição de uma tabela para registrar as imagens de ferimento, provenientes
do SNAA mobile.
 Criação de duas triggers18 para validação de CPF único na base: uma para
o cadastro e outra para atualização de dados.
As triggers foram necessárias para validação de CPF na base de dados do

SNAA devido a uma restrição de CPFs repetidos. O campo de CPF era obrigatório,
porém foi analisado que não há necessidade, uma vez que pode haver vítimas que
não possuam este documento, como estrangeiros e crianças, por exemplo. Logo,
ao ocorrer o evento de inserção ou atualização na tabela de vítima, a trigger será
disparada e, primeiramente verificará se o campo correspondente ao CPF está
preenchido. Caso esteja, e caso ocorra a restrição de duplicação de registro de
18 Trigger, traduzido gatilho, é um recurso de banco de dados que permite a execução de alguma
lógica de programação sempre que ocorre um evento de inserção, atualização ou exclusão de
registro ou registros em uma tabela.
87
CPF, o SNAA irá informar o problema. A Figura 43 ilustra a trigger utilizada na

inserção de um registro. O mesmo ocorre com a atualização.
Figura 43 – Trigger para inserção de vítima.
4.5. Implantação
As aplicações móveis desenvolvidas com a plataforma Android ficam

disponíveis em sua loja virtual de aplicações móveis, o Google Play. Para realizar a
publicação de uma aplicação é necessário possuir uma conta Google de
desenvolvedor – realizar cadastro e pagamento da taxa de registro, caso seja a
primeira vez em que está publicando. No caso do SNAA mobile, o desenvolvedor foi
convidado a participar de um grupo que já tem aplicações móveis publicadas, não
sendo necessário realizar cadastro ou pagamento de registro.
Neste ambiente de desenvolvimento é possível criar um registro para
gerenciamento de suas aplicações, o qual permitirá homologar, utilizando testes alfa
e beta, e disponibilizar para o usuário final. O ambiente de testes (alfa e beta)
permite que você possa selecionar usuários para teste, fazendo com que somente
eles tenham acesso à aplicação. No ambiente de produção, o real, a aplicação
estará disponível para todos. A configuração também envolve detalhes da aplicação,
como o nome que será disponibilizado, a descrição da aplicação, classificação do
conteúdo, categorização (jogos, arte, entretenimento, educacional, etc), inclusão de
imagens das telas da aplicação, preço, entre outros detalhes. A Figura 44 apresenta
o ambiente de gerenciamento de aplicações móveis Android.
88
Figura 44 – Ambiente de gerenciamento de aplicações Android.
Como apresentado no Capítulo 3, seção 3.3.1.4, para que uma aplicação

Android possa ser instalada e distribuída, ela precisa ser compactada em um pacote
denominado Android Package File (.apk), que é a junção de todas as classes
compiladas pela máquina virtual do Android, uma espécie de executável da
aplicação. O que é enviado para o ambiente de desenvolvimento é este apk, para
que seja disponibilizado para os usuários. Isto sempre ocorerrá a cada nova
release.
Quanto aos requisitos de hardware, a configuração mínima que um tablet ou
smartphone precisa para utilizar o SNAA mobile é possuir o sistema operacional
Android na versão 3.0 ou superior.
89
Considerações Finais
Este trabalho teve o objetivo de disponibilizar uma aplicação mobile para

auxiliar profissionais de saúde da Região Norte do Brasil na notificação de acidentes
envolvendo arraias. A aplicação foi denominada SNAA Mobile e foi desenvolvida
seguindo o processo AUP, utilizou a plataforma Android, e está disponível para
download na loja virtual de aplicações móveis Google Play, bastando realizar uma
busca pelo nome da aplicação.
Do ponto de vista técnico, este trabalho evolui um sistema desenvolvido
anteriormente e é um catalizador para a prática de conhecimento na área de
desenvolvimento de sistemas mobile e evolução/manutenção de software, bem
como em outras disciplinas do curso de TADS tais como Engenharia de Software,
Desenvolvimento de Aplicações Distribuídas e Programação Aplicada. Além disso, o
conhecimento adquirido nestas disciplinas contribuiu para o estudo da plataforma
Android, que era desconhecida pelo desenvolvedor.
Do ponto de vista social, este trabalho proporciona uma contribuição para a
saúde pública na região Norte do Brasil, que passa a contar com uma aplicação
que, possibilitará um maior conhecimento biológico e de estudiosos da área acerca
de acidentes envolvendo arraias, localização das mesmas e suas espécies, por
exemplo.
O desenvolvimento da aplicação foi planejado de maneira a cobrir a região
Norte do Brasil, mas pode facilmente ser utilizado em todo o território nacional,
realizando-se as alterações necessárias quanto à realidade de cada estado.
Quanto às dificuldades que surgiram ao longo do desenvolvimento da
aplicação, alguns dos mais críticos para sua realização foram: o gerenciamento do
tempo, principalmente durante dificuldades na codificação em uma plataforma nova
para o desenvolvedor, bem como manutenções em códigos de terceiros; e a escrita
deste documento, na procura de condensar grande quantidade de informações
necessárias para o entendimento do mesmo. Quanto às limitações do SNAA
mobile, pode-se apresentar a captura de imagens, que são limitadas a uma única
por notificação.
O SNAA mobile abre perspectivas para trabalhos futuros, tais como a
implementação de um módulo para catalogação de arraias, visto que dispositivos
móveis favorecem a mobilidade de profissionais e pesquisadores da área. Outro
90
trabalho futuro, que depende das autoridades de saúde, diz respeito a implantação
desta aplicação e viabilização de seu uso junto aos profissionais de saúde da
Região.
91
Revisão Bibliográfica
AIRES, Fabio J. R.; HAHN, Eliza C. Um estudo da API de geolocalização do

HTML5: Como desenvolver aplicativos para internet. A Revista Eletrônica da
Faculdade de Ciências Exatas e da Terra Produção/construção e tecnologia, v. 3, n.
4, 2014.
AMBLER, S. The Agile Unified Process (AUP). The Agile Unified Process (AUP),
2005. Disponivel em: <http://www.ambysoft.com/unifiedprocess/agileUP.html>.
Acesso em: 17 mar. 2015.
BOOCH, Brady. UML: guia do usuário / Grady Booch, James Rumbaugh, Ivar
Jacobson; tradução de Fábio Freitas da Silva e Cristina de Amorim – Rio de Janeiro:
Elsevier, 2012. – 12ª reimpressão.
BURÉGIO, Vanilson. A. A. Desenvolvimento de aplicações para dispositivos móveis

com .NET. 2003. 69 páginas. Trabalho de Graduação em Ciência da Computação -
Universidade Federal de Pernambuco, Recife.
CARVALHO, M. R.; LOVEJOY, N. R.; ROSA, R. S.Family potamotrygonidae. In:

REIS, R. E.;FERARIS JR., C. J.; KULLANDER, S. O. (Ed.). Checklist of the
freshwater fishes of South andCentral America (CLOFFSCA). 1st. Porto Alegre:
EDIPUCRS, 2003. p.22-29.
DORNELES, Andressa. L. Frequência de acidentes por animais peçonhentos

ocorridos no Rio Grande do Sul, 2001 – 2006. 2009. 49 páginas. Trabalho de
Conclusão de Curso – Universidade Federal do Rio Grande do Sul, Porto Alegre.
FOWLER, M. UML Essencial: um breve guia para a linguagem padrão de

modelagem de negócios. 3. ed. [S.l.]: Bookman, 2005.
FREITAS, John; DINIZ, Franklin. Segurança e persistência: uma análise das

arquiteturas de desenvolvimento de software nas plataformas android e Windows
phone. 2013. 86 páginas. Trabalho de Conclusão de Curso – Faculdade Católica
Salesiana do Espírito Santo, Vitória.
GARRONE NETO, D.; HADDAD JR., V. Acidentes por raias. In: CARDOSO, J. L. C.;
FRANÇA, F. O. S.; WEN, F. H.; MÁLAQUE, C. M.; HADDAD JR., V.
(Ed.). Animais peçonhentos no Brasil: biologia, clínica e terapêutica dos acidentes.
2nd. São Paulo, Brasil: Sarvier, 2009. cap. 30, p.295-313.
GUALBERTO, Ronei. M. Sistema de notificação de acidente por arraias. 2014. 125

páginas. Trabalho de Conclusão de Curso - Instituto Federal do Amazonas, Manaus.
92
GUEDES, G. T. A. UML 2: uma abordagem prática. 2ª Edição. ed. São Paulo:

Novatec, 2011.
LAET, Luis G. L. Utilização da Plataforma Android no desenvolvimento de um

aplicativo para o setor sucroalcooleiro. 2010. 52 páginas. Monografia –
Universidade Estadual do Mato Grosso do Sul, Dourados.
LAMEIRAS, J. L. V.; COSTA, O. T. F.; SANTOS, M. C.; DUNCAN, W. L. P, Arraias de

água doce (Chondrichthyes – Potamotrygonidae): biologia, veneno e acidentes, v. 2,
n.3, 11-27, 2013.
LARMAN, C. Utilizando UML e Padrões Uma introdução à análise e ao projeto

orientados a objetos e ao desenvolvimento iterativo. Porto Alegre: Bookman, 2000.
LECHETA, Ricardo R. Google Android – Aprenda a criar aplicações para

dispositivos móveis com o Android SDK. 3ª Ed. Novatec, 2013.
HADDAD JR., V. Animais aquáticos de importância médica no Brasil. Revista da

Sociedade Brasileira de Medicina Tropical, v. 36, p. 591-597, 2003.
HADDAD JR., V.; GARRONE NETO, D.; PAULA NETO, J. B.; MARQUES, F. P. L.;
BARBARO, K. C. Freshwater stingrays: study of epidemiologic,
clinic and therapeutic aspects based on 84 envenomings in humans and some
enzymatic activities of the venom. Toxicon, v. 43, n. 3, p. 287-94, Mar 1 2004.
HADDAD JR., V; CARDOSO, J. L. C.; GARRONE NETO, D. Injuries by marine and

freshwater stingrays: history, clinical aspects of the envenomations and current
status of a neglected problem in Brazil. Journal of Venomous Animals and Toxins
including Tropical Diseases 2013, 19:16. Disponível em <
http://www.jvat.org/content/19/1/16 >. Acesso em: 19 mar.2015.
IDC, International Data Corporation. Disponível em

<http://www.idc.com/prodserv/smartphone-os-market-share.jsp>. Acesso em 01 ago.
2016
MAGALHÃES, K. W.; LIMA, C.; PIRAN-SOARES, A. A.; MARQUES, E. E.; HIRUMA-

LIMA, C. A.; LOPESFERREIRA, M. Biological and biochemical properties of the
Brazilian Potamotrygon stingrays: Potamotrygon cf. cobina and Potamotrygon gr.
orbignyi. Toxicon, v. 47, n. 5, p. 575-583, 2006.
MELO, A. C. Desenvolvendo aplicações com UML 2.2: Do conceitual à

implementação. 3.ed. Rio de Janeiro: Brasport, 2010.
93
MONTEIRO, João Bosco. Google Android - Crie aplicações para celulares e tablets.
Ed. Casa do código, 2012.
PACHECO JÚNIOR, Marco Antônio, CASTRO, Reinaldo de Oliveira. Um estudo de

caso da plataforma Android com Interfaces Adaptativas. Disponível em:
<http://escoladenegocios.info/fgh/revistaalumni/artigos/Artigo_Marco
%20Antonio.pdf>. Acesso em: 20 Abr. 2015.
PARANÁ. Acidentes com animais aquáticos – arraias e peixes com ferrão, 2012.
Disponível em <http://sesaeventos.saude.ws/zoonose/html/arquivos/NT%2002_
2012%20ARRAIAS%20E%20PEIXES.pdf>.Acesso em: 18 mar. 2015.
PFLEEGER, S. L. Engenharia de Software: Teoria e Prática, Prentice Hall do Brasil,

2ª Edição, 2004.
PRESSMAN, Roger S. Engenharia de Software - Uma abordagem profissional. 7.ed.

São Paulo: Pearson, 2007.
RAMOS, Bruno Barbosa; BRUM, Diego Berg. Sistema na cloud para criação e
processamento de formulários eletrônicos com opção de uso em mobile online e
offline. 2004. 67 páginas. Projeto de Graduação - Universidade Federal do Rio de
Janeiro, Rio de Janeiro.
ROCHA, Rafael Francisco Ferreira. Estudo e desenvolvimento de um sistema de

coleta, análise e visualização de dados georreferenciais aplicado ao setor do
transporte público: módulo móvel. Lavras, 2010.
ROMEIRO, Bruna. Desenvolvimento de aplicativos para dispositivos móveis na

plataforma J2ME. 2005. 52 páginas. Trabalho de Conclusão de Curso – Escola
Politécnica de Pernambuco, Recife.
SÁ-OLIVEIRA, J. C.; COSTA, E. A.; PENA, F. P. S. Acidentes por raias

(Potamotrygonidae) em quatro comunidades da Área de Proteção Ambiental-APA do
rio Curiaú, Macapá-AP. Biota Amazônia, v. 1, n. 2, p. 74-78, 2011.
SILVA, J. P. C. B.; CARVALHO, M. R. A new species of Neotropical freshwater

stingray of the genus Potamotrygon Garman, 1877 from the Río Madrede Díos, Peru
(Chondrichthyes: Potamotrygonidae). Papéis Avulsos de Zoologia (São Paulo), v.
51, p. 139-154, 2011.
SOMMERVILLE, Ian. Engenharia de Software. 9.ed. São Paulo: Pearson, 2011.

94
Apêndice A – Especificação de Casos de Uso do Módulo

de Notificação
Quadro 7 - Caso de Uso CDU – 01 – Pesquisar vítima
Ator principal: Profissional de saúde
Interessados e Interesses:
- Profissional de saúde: deseja buscar um determinado registro de vítima.
Pré-condições: O profissional deverá estar autenticado na aplicação.
Pós-condições (Garantia de Sucesso): Resultado da pesquisa apresentado ao

profissional de saúde.
Cenário de Sucesso Principal (ou Fluxo Básico):
1. O profissional de saúde seleciona a opção ‘Pesquisar vítima’ no menu de

navegação;
2. O profissional clica no botão com desenho de lupa, no canto superior direito;
3. O profissional preenche nenhum ou mais campos de pesquisa;
4. O profissional clica em ‘pesquisar’;
5. A aplicação processa e apresenta o resultado da pesquisa para o profissional;
Extensões (ou Fluxo Alternativo):

a. Nenhum filtro informado: Caso nenhum filtro seja informado, a aplicação
retornará todas as vítimas que o profissional de saúde registrou.
b. Nenhum registro encontrado: Caso a consulta realizada pelo profissional não
contenha nenhum registro, a aplicação emitirá a mensagem: "Nenhum registro
encontrado com este(s) parâmetro(s)".
c. Editar notificação: O profissional pode selecionar, em algum registro pesquisado,
a opção Editar Notificação, então estender Editar notificação.
95
d. Consultar Histórico: O profissional pode selecionar, em algum registro

pesquisado, a opção Consultar Histórico, então estender Consultar Histórico.
e. Reativar Notificação: O profissional pode selecionar, em algum registro
pesquisado, a opção Reativar Notificação, então estender Reativar notificação.
f. Nova Notificação: O profissional pode selecionar, em algum registro pesquisado, a
opção Nova Notificação, então estender Cadastrar Notificação.
Quadro 8 - Caso de Uso CDU 02 – Cadastrar Vítima
- Profissional de saúde: deseja registrar uma nova vítima de acidente por arraia.
Pré-condições: O profissional deverá está autenticado na aplicação.
Pós-condições (Garantia de Sucesso): Cadastro de vítima efetivado e exibição da

mensagem informando que foi realizado o cadastro.
Cenário de Sucesso Principal (ou Fluxo Básico)

1. O profissional de saúde preenche o formulário de cadastro da vítima,
registrando as seguintes informações:
 CPF;
 Nome;
 Data de Nascimento;
 Sexo;
 Escolaridade;
 Profissão;
 Nacionalidade (Caso a vítima seja estrangeira);
 Estado e Naturalidade (Caso a vítima seja brasileira).
2. A aplicação exibe a mensagem "Vítima cadastrada com sucesso".
96

Campos obrigatórios não preenchidos: Caso algum campo obrigatório do
formulário não tenha sido preenchido, a aplicação notificará o profissional,
informando-lhe quais campos que não foram preenchidos.
CPF inválido: Caso o CPF informado seja inválido será mostrada a mensagem:
"CPF inválido".
Vítima existente na aplicação: Caso o CPF informado já exista na aplicação, será
mostrada a mensagem: “CPF de vítima já cadastrado”.
Quadro 9 - Caso de Uso CDU 02 – Cadastrar Acidente
- Profissional de saúde: deseja registrar dados de um acidente por arraia.
Pré-condições:
 O profissional deverá estar autenticado no sistema;
 A vítima do acidente já deverá estar cadastrada.
Pós-condições (Garantia de Sucesso): Cadastro do acidente efetivado e exibição

da mensagem informando que foi realizado cadastro do acidente.
1. O profissional de saúde seleciona a opção Cadastrar Acidente;

2. O profissional preenche o formulário de cadastro de acidente, registrando as
seguintes informações:
 Data do acidente;
 Coordenadas geográficas;
 Período do dia (Manhã, tarde, noite ou madrugada);
97
 Estado/Município da ocorrência;
 Tipo de local (rio, lago,igarapé,etc.);
 Nome do rio;
 O que a vítima estava fazendo na hora do acidente.
3. O profissional clica na opção Salvar;

4. A aplicação exibe a mensagem "Acidente cadastrado com sucesso";
5. O Profissional de saúde continuará cadastrando informações mais detalhadas
do acidente, tais como:
 Cadastro de Imagens (estender Cadastrar Imagens);
 Cadastro de Dados Clínicos (estender Cadastrar Dados Clínicos);
 Cadastro de Tratamento (estender Cadastro de Tratamento);
 Conclusão do registro de notificação (estender Concluir Notificação).

a. Campos obrigatórios não preenchidos: Caso algum campo obrigatório do
formulário não tenha sido preenchido, a aplicação notificará o profissional de saúde,
informando-lhe quais campos não foram preenchidos.
Quadro 10 - Caso de Uso CDU 03 – Cadastrar Imagens
- Profissional de saúde: deseja registrar imagens da arraia e/ou do ferimento
relacionados a um acidente.
Pré-condições:
 O profissional deverá está autenticado no sistema;
 O acidente deverá estar cadastrado.
Pós-condições (Garantia de Sucesso): Cadastro de imagens efetivado e exibição

98
da mensagem informando que foi realizado cadastro de imagens.
1. O profissional de saúde seleciona a opção Cadastrar Imagens;

2. O profissional tem a opção de escolher cadastrar uma imagem do ferimento ou
da arraia causadora do ferimento.
3. O profissional tem a opção de escolher uma imagem de sua galeria ou tirar
foto utilizando a câmera de seu aparelho.
5. A aplicação exibe a mensagem "Imagens cadastradas com sucesso";

a. Campos obrigatórios não preenchidos: Caso nenhuma foto tenha sido escolhida,
a aplicação notificará o profissional de saúde, informando-lhe que o mesmo não
selecionou nenhuma foto.
Quadro 11 - Caso de Uso CDU 04 – Cadastrar Dados Clínicos
- Profissional de saúde: deseja registrar os dados clínicos da vítima;
Pré-condições:
Pós-condições (Garantia de Sucesso): Dados clínicos da vítima cadastrados com

sucesso.
1. O profissional de saúde seleciona a aba Dados Clínicos;
99
2. A aplicação exibe o formulário para preenchimento dos dados clínicos da vítima

com as seguintes informações:
 Local da picada (da arraia);

 Escala de dor (de 0 a 5);
 Sintomas locais;
 Sintomas sistêmicos;
 Exames;

4. A aplicação exibe a mensagem "Dados clínicos cadastrados com sucesso";
Quadro 12 - Caso de Uso CDU 05 – Cadastrar Tratamento
Interessados e Interesses: - Profissional de saúde: deseja registrar os dados sobre

o tratamento da vítima;
Pré-condições:
 O profissional deverá está autenticado no sistema.
Pós-condições (Garantia de Sucesso): Dados do tratamento da vítima

cadastrados com sucesso.

1. O profissional de saúde seleciona a aba Tratamento;
2. A aplicação exibe o formulário com para preenchimento dos dados do tratamento
da vítima com as seguintes informações:
100
 Vítima foi internada? ;

 Tempo de internação;
 Tratamento local;
 Tratamento sistêmico;
 Exames.

4. A aplicação exibe a mensagem "Tratamento cadastrados com sucesso";
Quadro 13 - Caso de Uso CDU 06 – Concluir Notificação
- Profissional de saúde: deseja concluir a notificação
Pré-condições:
 O profissional deverá está autenticado no sistema.
Pós-condições (Garantia de Sucesso): O registro do acidente passa a ter status

de CONCLUÍDO

1. O profissional de saúde seleciona a aba Conclusão;
2. A aplicação exibe o formulário para efetivar a conclusão do acidente com as
seguintes informações:
 Estado da vítima após tratamento;
 O profissional insere um comentário se achar relevante
4. A aplicação exibe a mensagem "Notificação concluída com sucesso";
101
Quadro 14 - Caso de Uso CDU 07 – Editar Notificação
- Profissional de saúde: deseja editar os dados de uma notificação.
Pré-condições:
 A notificação deverá estar cadastrada.
Pós-condições (Garantia de Sucesso): Os dados da notificação serão atualizados.

1. O profissional de saúde seleciona a opção Editar Notificação em algum registro na
tela de pesquisa de vítima ou na tela de histórico de notificações;
2. O Profissional de saúde atualizar informações da notificação, tais como:
 Editar Acidente (estender Editar Acidente);
 Editar Imagens (estender Editar Imagens);
 Editar Dados Clínicos (estender Editar Dados Clínicos);
 Editar Tratamento (estender Editar Tratamento);
 Conclusão do registro de notificação (estender Concluir Notificação).
3. A aplicação exibe a mensagem "(Imagens/Dados clínicos/Tratamento) atualizado

com sucesso";
Regras de Negócio:
RN01 - Somente registro de acidentes com situação igual a PENDENTE poderão
possuir essa opção;
102
Quadro 15 - Caso de Uso CDU 08 – Reativar Notificação
- Profissional de saúde: deseja reabrir para edição um acidente que está com
situação igual à CONCLUÍDO.
Pré-condições:
 A notificação deverá estar com acidente com situação igual à CONCLUIDO.
Pós-condições (Garantia de Sucesso): Após a reativação do registro, o profissional

poderá a editar os dados da notificação, no entanto ele irá gerar os históricos das
mudanças nos dados clínicos e de tratamento.

1. O profissional de saúde seleciona a opção Reativar Acidente em algum registro na
tela de histórico de acidentes;
2. A aplicação altera o estado do registro para PENDENTE;
3. A aplicação exibe a mensagem "Notificação reativada com sucesso";
Regras de Negócio:
RN01 - Somente registro de acidentes com situação igual a CONCLUÍDO poderão
possuir essa opção;
103
Apêndice B – Interfaces do usuário (protótipos iniciais)
Neste apêndice serão apresentadas as interfaces do usuário utilizadas por

um profissional de saúde ao notificar um acidente. As interfaces foram construídas
utilizando a ferramenta Wireframe Sketcher19 e serão dispostas seguindo o fluxo
principal do SNAA mobile.
Figura 46 - Tela de login. Figura 45 – Tela de navegação.
19 Site oficial da ferramenta: http://wireframesketcher.com/

104
Figura 47 - Tela de pesquisar vítima. Figura 48 - Tela de histórico de notificações.
Figura 49 - Tela de notificação – dados da vítima. Figura 50 - Tela de notificação - dados do acidente.

105
Figura 51 - Tela de notificação– dados clínicos. Figura 52 - Tela de notificação – dados de tratamento.
Figura 53 - Tela de notificação – concluir.

106
Apêndice C – Responsabilidades de classes
Neste apêndice serão descritas, de maneira sucinta, as responsabilidades

das classes mais relevantes do SNAA Mobile.
Quadro 16 – Responsabilidade de classes.
Nome da classe Descrição da responsabilidade

Responsável por congregar
informações comuns (identificadores)
AbstractBean
entre as classes que realizam a
sincronização.
informações referentes à vítima (nome,
Vitima
idade, sexo, etc) de um acidente por
arraia.
Responsável por reunir informações
referentes a um acidente (data,
Acidente
coordenadas geográficas, etc)
envolvendo arraia.
ImagemArraia informações referentes à imagem da
arraia causadora do acidente.
Responsável unicamente por auxiliar a
ArquivoImagemArraia sincronizar uma imagem (por meio de
um array de bytes) de arraia.
ImagemFerimento informações referentes (array de bytes)
ao ferimento causado por uma arraia.
informações referentes aos dados
DadosClinicos
clínicos (local da picada, sintomas, etc)
relativos a um acidente por arraia.
informações referentes ao tratamento
Tratamento (medicamento ministrado, exames
realizados, etc) relativos a um acidente
por arraia.

Uma Aplicação Mobile para Notificação de Acidentes Por

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uma Aplicação Mobile para Notificação de Acidentes Por

Enviado por

Direitos autorais:

Formatos disponíveis

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

Patrick Tapajós Pinto

UMA APLICAÇÃO MOBILE PARA NOTIFICAÇÃO DE ACIDENTES POR

Patrick Tapajós Pinto

UMA APLICAÇÃO MOBILE PARA NOTIFICAÇÃO DE ACIDENTES POR

Trabalho de Conclusão de Curso

Profª. Dra. Andréa Pereira

Profª. Drª. Andréa Pereira Mendonça

Profª Mª. Joyce Miranda dos Santos

Prof. Dr. Jucimar Brito de Souza

Primeiramente a Deus, por me dar a capacidade necessária para realizar

Animais peçonhentos são aqueles capazes de inocular veneno em sua vítima,

Palavras-chave: Animais peçonhentos, Arraias, Sistema de notificação offline, Aplicação

Keywords: Poisonous animals, Stingrays, Offline notification system, Mobile application,

Figura 1 – Fluxo do SNAA..........................................................................................10

Quadro 1 - Perfil de acesso e módulos do SNAA........................................................9

2.1 Acidentes por arraias e sua notificação..............................................................5

2.2 O Sistema de Notificação de Acidentes por Arraias (SNAA)..............................7

2.2.1 Fluxo do SNAA...............................................................................................10

2.2.2 Tecnologias utilizadas na construção do SNAA............................................11

2.2.3 Limitações do SNAA......................................................................................12

2.3 Evolução/Manutenção de Software..................................................................13

2.4 Desenvolvimento de Aplicações para Dispositivos Móveis..............................16

Processo e Tecnologias utilizados no Desenvolvimento do SNAA Mobile................23

3.1 AUP (Agile Unified Process)............................................................................23

3.2 UML - Unified Modeling Language....................................................................27

3.3.1.2 Application Framework................................................................................30

3.3.1.5 Linux Kernel................................................................................................32

3.3.2 Componentes de aplicativo Android..............................................................33

3.3.3 Ciclo de vida de uma atividade (Activity).......................................................34

3.5 Web Services....................................................................................................37

4.1 Solicitação de mudança....................................................................................38

4.1.1 Descrição geral do SNAA mobile (escopo)....................................................40

4.1.2 Módulo de notificação....................................................................................43

4.1.3 Módulo de sincronização...............................................................................45

4.1.4 Interfaces do usuário......................................................................................50

4.1.6 Diagrama de classes......................................................................................58

4.1.7 Diagrama Entidade Relacionamento (DER)..................................................61

4.2 Análise de impacto............................................................................................62

4.3 Atividade de planejamento de versões.............................................................63

4.4 Implementação de mudanças...........................................................................65

4.4.1 Implementação do SNAA mobile...................................................................66

4.4.1.1 Versão do SDK............................................................................................66

4.4.1.3 Layouts para múltiplas telas.......................................................................69

4.4.1.4 Tratamento de imagens..............................................................................73

4.4.1.6 Envio e recebimento de dados...................................................................78

4.4.2 Implementação de mudanças no SNAA........................................................83

4.4.2.1 Módulo de serviços mobile.........................................................................83

4.4.2.2 Banco de dados..........................................................................................86

Apêndice A – Especificação de Casos de Uso do Módulo de Notificação................94

Apêndice B – Interfaces do usuário (protótipos iniciais)..........................................103

Apêndice C – Responsabilidades de classes..........................................................106

Animais peçonhentos são aqueles que apresentam veneno e algum tipo de

ênfase de notificação está relacionada aos acidentes causados por serpentes,

operacionalidade online, como é feito atualmente no SNAA, e também offline, dada

Com o propósito de atender as demandas acima citadas, este trabalho teve o

considerados no desenvolvimento desta aplicação. O Capítulo 4 destina-se a

Neste capítulo são apresentados os conceitos que fundamentam este

2.1 Acidentes por arraias e sua notificação

Raias, arraias ou peixes batoides são peixes cartilaginosos, arredondados e

Apesar de arraias serem consideradas animais dóceis, os acidentes são

tratamento de acidentados por arraias e estudos que viabilizem a produção de

2.2 O Sistema de Notificação de Acidentes por Arraias (SNAA)