Universidade Federal do Rio de Janeiro Escola...
45
Universidade Federal do Rio de Janeiro Escola Politécnica Departamento de Eletrônica e de Computação ID Saúde - Software para Smartphone de gerenciamento de saúde Autor: _________________________________________________ Timóteo Alvarenga da Silva Nascimento Orientador: _________________________________________________ Prof. Sergio Barbosa Villas-Boas Examinador: _________________________________________________ Prof. Aloysio Pedroza Examinador: _________________________________________________ Prof. Flávio Luis de Mello DEL Agosto de 2014
Transcript of Universidade Federal do Rio de Janeiro Escola...
Universidade Federal do Rio de Janeiro
Escola Politécnica
Departamento de Eletrônica e de Computação
ID Saúde - Software para Smartphone de gerenciamento de
saúde
Autor:
_________________________________________________
Timóteo Alvarenga da Silva Nascimento
Orientador:
_________________________________________________
Prof. Sergio Barbosa Villas-Boas
Examinador:
_________________________________________________
Prof. Aloysio Pedroza
Examinador:
_________________________________________________
Prof. Flávio Luis de Mello
DEL
Agosto de 2014
2
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Escola Politécnica – Departamento de Eletrônica e de Computação
Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária
Rio de Janeiro – RJ CEP 21949-900
Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que poderá
incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar qualquer forma
de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas
deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser
fixado, para pesquisa acadêmica, comentários e citações, desde que sem finalidade comercial e
que seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).
3
DEDICATÓRIA
Dedico esse trabalho à minha família, que sempre me deu suporte e incentivo ao estudo.
Se não fosse por ela não teria chegado até aqui.
4
AGRADECIMENTO
Acima de tudo, agradeço a Deus pela oportunidade de ter passado no vestibular e ter
entrado nesse curso. Agradeço à minha família por ser minha base, e aos meus amigos pelo
suporte e por sempre estarem ao meu lado. Agradeço aos professores do Departamento de
Eletrônica da Universidade Federal do Rio de Janeiro pelo conhecimento passado. E
finalmente, agradeço ao povo brasileiro, que paga seus impostos e que, de várias formas,
viabilizou a minha formação acadêmica.
5
RESUMO
O projeto consiste no desenvolvimento de um software para smartphone (Plataforma
Android) que auxilie a saúde do usuário. O aplicativo funciona como uma identidade da saúde
do usuário, guardando informações essenciais (Ex.: tipo sanguíneo), além de registros do
histórico médico do usuário (Ex.: alergias e histórico familiar). O aplicativo ainda possui outras
funcionalidades como encontrar serviços de saúde, mandar mensagem SOS para contatos de
emergência com a localização do usuário, e guardar registros da pressão sanguínea do usuário
mostrando esses dados de forma gráfica.
Palavras-Chave: smartphone, saúde, identidade, informações.
6
ABSTRACT
The project is the development of a mobile application (Android Platform) that would be
helpful to the wellness of the user. The application would work like the user’s health ID, storing
important data (e.g.: blood type) and medical history records (e.g.: allergy and family history).
The application would also have other functionalities as search for health services, send SOS
message to emergency contacts along with the user’s location, and store the user’s blood
pressure records showing these data graphically.
Key-words: Smartphone, health, ID, data.
7
SIGLAS
UFRJ – Universidade Federal do Rio de Janeiro
RF – Requisito Funcional
RN – Regra de Negócios
IDE – Integrated development environment
REST – Representational state transfer
JSON – JavaScript Object Notation
JPA – Java Persistence API
SOA-MC – Service Oriented Architecture - Multiple Clients
JDBC – Java Database Connectivity
API – Application Programming Interface
HTML – HyperText Markup Language
XML – Extensible Markup Language
URL – Uniform Resource Locator
GPS – Global Positioning System
CEP – Complex Event Processing
8
Sumário
1. Introdução .............................................................................................................................................. 11
1.1. Motivação ........................................................................................................................................ 11
1.2. Objetivo ............................................................................................................................................ 12
1.3. Metodologia ..................................................................................................................................... 12
1.4. Descrição .......................................................................................................................................... 12
2. Ferramentas e tecnologias utilizadas .................................................................................................... 14
2.1. Android ............................................................................................................................................ 14
2.2. REST ................................................................................................................................................. 14
2.3. JSON ................................................................................................................................................ 15
2.4. Apache Tomcat ................................................................................................................................ 15
2.5. JPA e Hibernate ............................................................................................................................... 16
2.6. PostgreSQL ...................................................................................................................................... 17
2.7. AChartEngine ................................................................................................................................... 17
2.8. Google Maps Android API ............................................................................................................... 18
2.9. SOA-MC – Arquitetura Orientada a Serviços-Múltiplos Clientes .................................................... 19
3. Desenvolvimento .................................................................................................................................... 20
3.1. WebService ....................................................................................................................................... 20
3.2. Android ............................................................................................................................................. 26
4. Requisitos de Software ........................................................................................................................... 30
4.1. Login ................................................................................................................................................. 30
4.2. Cadastrar novo usuário .................................................................................................................... 31
4.3. Tela principal .................................................................................................................................... 32
4.4. Cadastrar nova pessoa ..................................................................................................................... 33
4.5. Listar pessoas ................................................................................................................................... 34
4.6. Mensagem SOS ................................................................................................................................ 35
4.7. Serviços ............................................................................................................................................. 36
4.8. Grupos de informação ...................................................................................................................... 37
4.9. Lista de exames ................................................................................................................................ 38
4.10. Cadastro de exames ....................................................................................................................... 39
4.11. Pressão sanguínea ......................................................................................................................... 40
4.12. Cadastro de medição de pressão sanguínea .................................................................................. 41
5. Conclusões e Trabalhos Futuros ............................................................................................................. 42
9
5.1. Conclusões ........................................................................................................................................ 42
5.2. Trabalhos Futuros ............................................................................................................................ 42
Referências Bibliográficas .......................................................................................................................... 45
10
Lista de Figuras
2.1 – Utilização de um serviço REST com JSON. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 15
2.2 – Utilização do JPA e Hibernate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 – Figura ilustrativa do uso do AChartEngine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 – Arquitetura SOA-MC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 – Modelo do banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 – Propriedades de conexão com o Postgres. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 – Entidade Usuario e seus atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 – Configuração da persistence-unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 – Classe AlergiaResource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6 – Arquivo web.xml. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1 – Tela de Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 – Tela de cadastro de novo usuário. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 – Tela principal do aplicativo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 – Tela de cadastro de pessoa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5 – Tela de listagem de pessoas cadastradas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6 – Tela de envio de mensagem SOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.7 – Mensagem SOS enviada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.8 – Tela de serviços. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.9 – Tela de grupos de informações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.10 – Tela de listagem de exames. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.11 – Tela de cadastro de exames. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.12 – Tela de registros de medição de pressão sanguínea. . . . . . . . . . . . . . . . . . . . . . . . . 40
4.13 – Tela de cadastro de medição de pressão sanguínea. . . . . . . . . . . . . . . . . . . . . . . . . 41
6.1 – Aparelho de medição de pressão sanguínea. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
11
Capítulo 1
Introdução
1.1 Motivação
Saúde é um tema que vem ganhando cada vez mais destaque nas mídias sociais.
Porém, muitas pessoas parecem não se preocupar com seu próprio corpo até o momento que
adoecem e são forçadas a agir de forma diferente. Este não é o cenário ideal, não deveria ser
necessário um susto para que a pessoa passasse a se preocupar mais com sua saúde. Já
dizia o velho ditado popular: “Prevenir é melhor do que remediar”.
Este é o foco que este trabalho procura dar, qualidade de vida e controle sobre a saúde.
Prevenir problemas de saúde, ou seja, se alimentar bem, fazer exercícios físicos, evitar stress,
e se consultar frequentemente, são apontados por muitos como os melhores métodos para ter
uma vida saudável. O único problema é que para muitos, falta motivação de seguir esse
caminho quando seu quadro atual não apresenta nenhuma complicação.
Além da prevenção de problemas de saúde, ter um controle maior sobre tudo
relacionado ao cuidado com seu corpo pode se mostrar uma ótima ferramenta para continuar a
ter uma vida saudável .
A tecnologia deve ser uma aliada da saúde. Seu potencial não só pode, mas como deve
ser explorado para ajudar as pessoas a ter mais qualidade de vida. Mas como aproveitar os
recursos que temos nos dias de hoje para ajudar nestes pontos citados? Como usar a
tecnologia para motivar uma pessoa a ter uma vida mais saudável?
O mercado de tecnologia móvel cresce com uma velocidade assustadora. Era difícil
imaginar há alguns anos atrás como seria relativamente fácil ter acesso a um smartphone.
Estima-se que até 2017, o Brasil terá 70.5 milhões de usuários de smartphone. Isso leva a crer
que uma aplicação voltada para saúde utilizando os recursos da tecnologia móvel irá não
somente favorecer as classes mais altas, mas também o público comum.
Este trabalho engloba o desenvolvimento de um aplicativo para Smartphones da
plataforma android que visa organizar e manter o histórico médico do usuário e de seus
dependentes, monitorar dados de sua saúde, compartilhar essas informações com seu médico,
e fornecer dicas de saúde personalizadas para o perfil do usuário. Dessa maneira, o usuário
terá controle sobre sua saúde e será constantemente motivado a cuidar melhor de si mesmo.
Sabe-se hoje que a anamnese (entrevista realizada pelo profissional de saúde ao seu
paciente), quando bem conduzida, é responsável por 85% do diagnóstico na clínica médica,
liberando 10% para o exame clínico (físico) e apenas 5% para os exames laboratoriais ou
complementares. [1] Manter uma ficha médica no celular ajuda a organizar seus dados de
saúde e torná-los mais facilmente acessíveis.
Essa facilidade no acesso a informações de saúde também é bastante valiosa em
12
situações de emergência. Com posse de informações sobre a saúde do indivíduo, o socorrista
tem uma atuação mais segura quando do início do atendimento de emergência, e um
planejamento adequado de ações posteriores.
1.2 Objetivo
O objetivo geral é, então, desenvolver um sistema prático, de fácil manuseio, e com
funcionalidades que possibilitam o usuário guardar e compartilhar informações relacionadas à
sua saúde, e receber dicas de saúde em um dispositivo que carrega sempre com ele. Com o
número de Smartphones cada vez mais crescente no mercado, este aplicativo pode se mostrar
ideal para esses tipos de serviço.
O desenvolvimento desse sistema tem como finalidade facilitar o cuidado com a saúde
do usuário. A informação é algo preciosa, e muitas vezes não sabemos o que estamos
perdendo quando não vamos atrás dela. Dessa maneira, trazer a informação diretamente para
o usuário é a forma mais prática de motiva-lo a ter mais qualidade de vida.
As próprias informações de saúde do usuário terão mais fácil acesso. A praticidade de
ter toda sua ficha médica no celular pode ser a diferença entre vida ou morte em uma situação
de emergência. Além disso, seria interessante para o médico ter fácil acesso a todas as
informações de seu paciente de maneira bem documentada e organizada.
Outras funcionalidades, como por exemplo, encontrar um serviço médico baseado na
localização do usuário medida pelo GPS do smartphone, pode ser extremamente útil em casos
de emergência. O resultado almejado se dará ao explorar ao máximo as funcionalidades de um
dispositivo celular moderno para questões ligadas a saúde de um indivíduo.
1.3 Metodologia
A metodologia Scrum é uma metodologia ágil e flexível para controlar o
desenvolvimento de um projeto. A Scrum Academic [2] é uma adaptação para ambientes
acadêmicos. Esta metodologia está de acordo com os princípios da Engenharia de Software, e
seu processo controla o atendimento aos requisitos impostos. Para isso, deve-se maximizar a
comunicação entre as partes interessadas com reuniões regulares, e dessa maneira, tornar o
processo mais interativo.
Na metodologia usada, foi definido primeiro a visão do projeto, e seu público alvo.
Depois, a definição de requisitos e regras de negócios. A implementação do aplicativo teve
como base os requisitos pré-definidos.
1.4 Descrição
No capítulo 2 serão expostas as ferramentas e tecnologias utilizadas para a realização
do projeto. Será detalhado o IDE utilizado, bem como o servidor e banco de dados.
O desenvolvimento do sistema é apresentado no capítulo 3. Nele serão explicitado os
detalhes técnicos de como o código foi construído para atender as funcionalidades desejadas.
13
O capítulo 4 apresenta os requisitos do sistema. Todas as suas funcionalidades são
expostas juntamente com as regras de negócio.
O capítulo 5 é a conclusão do trabalho. Nele são abordados os resultados obtidos.
No capítulo 6 são abordados os possíveis trabalhos futuros.
14
Capítulo 2
Ferramentas e tecnologias utilizadas
2.1 Android
O Android é o sistema operacional para dispositivos móveis criado pela Google e
presente em equipamentos feitos por empresas como LG, Samsung, Sony e Motorola. De
acordo com o Google, mais de um milhão e meio de aparelhos com o sistema operacional
Android são ativados todos os dias.
Android domina 81% do mercado global de Smartphones [3]. Isso significa que quatro
em cada cinco Smartphones no mundo usam o sistema operacional da Google. O Google Play
é a loja online para Android onde o usuário pode baixar aplicativos, filmes, música, livros de
maneira gratuita ou comprando esses conteúdos. Em Abril de 2014, o número de aplicativos
disponíveis no Google Play era aproximadamente um milhão e 200 mil. São aplicativos de
todos os tipos e gostos que estão separados em áreas como games, educação, saúde, música,
finanças, viagens, metereologia, etc.
A linguagem de programação utilizada para criar aplicativos para a plataforma Android é
JAVA. O Android é uma plataforma de código aberto e o desenvolvimento de programas é
amplamente incentivado pelo Google. No website developer.android.com [4] podemos
encontrar todas as ferramentas necessárias e dicas para começar a desenvolver em Android.
2.2 REST
REST - “Representational State Transfer” [5] é um estilo de arquitetura para projetar
aplicações web. Ao invés de usar mecanismos complexos para se comunicar entre duas
máquinas, REST faz uso de protocolos padrões da web para a implementação de um web
service. Um serviço web RESTful usa as ações HTTP GET, PUT, DELETE e POST para
enviar, recuperar ou modificar dados do lado do servidor.
Normalmente, em um serviço web REST, as ações padrões HTTP são usadas da
seguinte forma:
GET - recupera ou realiza consulta de dados, geralmente usando critérios passados por
parâmetro.
PUT - cria uma nova entrada, registro.
DELETE - remove um recurso
POST - atualiza um recurso ou cria um recurso
Os dados que são transmitidos usam tipos MIME (Multipurpose Internet Mail
Extensions) padrão, incluindo imagens, vídeo, texto, HTML, XML e JSON. Uma característica
fundamental de um serviço REST é o uso de caminhos URL como parâmetros de consulta. Por
exemplo, um serviço web fictício para uma sistema de cadastro de usuários poderia retornar
15
uma lista de usuários ativos com esta URL: http://usuariossystem/usuario?ativo=true
2.3 JSON
JSON [6] é a abreviação de JavaScript Object Notation. É uma maneira fácil e
organizada de guardar informações. É feito pelo encapsulamento de uma coleção de dados
que pode ser acessado de uma forma lógica. Abaixo segue o exemplo de uma estrutura JSON:
var jason = {
"age" : "24",
"hometown" : "Missoula, MT",
"gender" : "male"
};
Um objeto JSON é identificado por estar dentro de colchetes. Dentro do objeto JSON,
temos uma série de pares de chave e valor. Na aplicação mobile, é usado uma biblioteca capaz
de ler dados no formato JSON.
Figura 2.1 - Utilização de um serviço REST com JSON
2.4 Apache Tomcat
O servidor Apache Tomcat [7] é um container Web de código fonte aberto baseado em
Java que foi criado para executar aplicações Web que utilizam tecnologias Servlets e JSPs. O
servidor Tomcat foi criado inicialmente como um subprojeto da Apache-Jakarta, no entanto,
devido a sua alta popularidade, acabou sendo designado para um projeto separado da Apache,
sendo assim mantido por um grupo de voluntários da comunidade de código aberto do Java.
16
Apache Tomcat é um servidor bastante estável com todas as características que um container
comercial que aplicações web possui. Atualmente as versões que ainda recebem suporte são
5.5x, 6.0x e 7.0x.
2.5 JPA e Hibernate
O Hibernate [8] é uma ferramenta para mapeamento objeto-relacional (ORM) open
source e é a líder de mercado, sendo a inspiração para a especificação Java Persistence API
(JPA) [8]. O Hibernate nasceu sem JPA, mas hoje em dia é comum acessar o Hibernate pela
especificação JPA.
Figura 2.2 – Utilização do JPA com Hibernate
O Hibernate abstrai o seu código SQL, toda a camada JDBC e o SQL será gerado em
tempo de execução. Mais que isso, ele vai gerar o SQL que serve para um determinado banco
de dados, já que cada banco fala um "dialeto" diferente dessa linguagem. Assim há também a
possibilidade de trocar de banco de dados sem ter de alterar código Java, já que isso fica de
responsabilidade da ferramenta.
Para mapear uma classe, basta adicionar algumas poucas anotações em nosso código.
Anotação é um recurso do Java que permite inserir metadados em relação a nossa classe,
atributos e métodos. Essas anotações depois poderão ser lidas por frameworks e bibliotecas,
para que eles tomem decisões baseadas nessas pequenas configurações. Um exemplo de
como mapear uma classe é mostrado em seguida.
@Entity
public class Tarefa {
@Id
@GeneratedValue
private Long id;
private String descricao;
17
private boolean finalizado;
@Temporal (TemporalType.DATE)
private Calendar dataFinalizacao;
// métodos...
}
@Entity indica que objetos dessa classe se tornem "persistível" no banco de dados.
@Id indica que o atributo id é nossa chave primária (você precisa ter uma chave primária em
toda entidade) e @GeneratedValue diz que queremos que esta chave seja populada pelo
banco (isto é, que seja usado um auto increment ou sequence, dependendo do banco de
dados). Com @Temporal configuramos como mapear um Calendar para o banco, aqui usamos
apenas a data (sem o horário), mas poderíamos ter usado apenas a hora
(TemporalType.TIME) ou timestamp (TemporalType.TIMESTAMP). Essas anotações precisam
dos devidos imports, e pertencem ao pacote javax.persistence.
2.6 PostgreSQL
O PostgreSQL [9] é um SGBD (Sistema Gerenciador de Banco de Dados) objeto-
relacional de código aberto, com mais de 15 anos de desenvolvimento. É extremamente
robusto e confiável, além de ser extremamente flexível e rico em recursos. Ele é considerado
objeto-relacional por implementar, além das características de um SGBD relacional, algumas
características de orientação a objetos, como herança e tipos personalizados. A equipe de
desenvolvimento do PostgreSQL sempre teve uma grande preocupação em manter a
compatibilidade com os padrões SQL92/SQL99.
Pela riqueza de recursos e conformidade com os padrões, ele é um SGBD muito
adequado para o estudo universitário do modelo relacional, além de ser uma ótima opção para
empresas implementarem soluções de alta confiabilidade sem altos custos de licenciamento. É
um programa distribuído sob a licença BSD, o que torna o seu código fonte disponível e o seu
uso livre para aplicações comerciais ou não. O PostgreSQL foi implementado em diversos
ambientes de produção no mundo, entre eles, um bom exemplo do seu potencial é o banco de
dados que armazena os registros de domínio .org, mantido pela empresa Afilias.
2.7 AChartEngine
A AChartEngine [10] é uma biblioteca para gerar gráficos em aplicações Android. Ela é
usada no IDSaúde para gerar gráficos dos registros de pressão, possibilitando o usuário
monitorar sua pressão sanguínea. A biblioteca suporta versões do Android SDK a partir do 1.6.
Um grande número de aplicações usa o AChartEngine para mostrar dados graficamente. No
geral, é uma biblioteca fácil e prática de usar e que atende bem os requisitos da funcionalidade
proposta.
A biblioteca pode gerar gráficos XY e gráficos pizza. É possível editar a aparência dos
gráficos modificando cor, fonte, legenda. O gráfico é gerado basicamente combinando as
18
opções de customização e o dataset contendo os dados a serem mostrados. Há suporte para
zoom e para criar eventos a partir de toques na tela. Para ter gráficos dinâmicos, é só invocar o
método repaint quando o dataset é atualizado.
Figura 2.3: Figura ilustrativa do uso do AChartEngine
2.8 Google Maps Android API
O Google Maps API [11] é usado para a funcionalidade de localização de serviços. Com
esta API, é possível incorporar os mapas da Google em seu aplicativo e customizar a maneira
como você quer usar essa ferramenta. Para utilizar o Google Maps, deve-se criar uma chave
do Google Maps API válida. A chave não tem custo, e o seu proprietário pode usá-la com
qualquer aplicativo seu que use o Google Maps API. Essa chave é gerada no console do
Google APIs.
Além da visualização do mapa incorporado ao aplicativo, o Google Places é utilizado
para pesquisar lugares de acordo com a sua categoria. Para pesquisar um determinado tipo de
lugar, usa-se um query que contém como parâmetros a categoria do lugar a ser encontrado e o
raio de pesquisa tomando como base a posição atual do aparelho. Caso o aparelho mude de
localização, a query é executava novamente, retornando assim resultados diferentes.
19
2.9 SOA-MC - Arquitetura Orientada a Serviços –
Múltiplos Clientes
Este é um estilo de arquitetura de software que possui como regra principal que as
funcionalidades implementadas sejam disponibilizadas na forma de serviços. A arquitetura
SOA-MC [12] é baseada nos princípios da computação distribuída e utiliza o paradigma
request/reply para estabelecer a comunicação entre os sistemas clientes e os sistemas que
implementam os serviços.
A arquitetura orientada a serviços se revela ideal para este projeto, pois facilita a tarefa
de encontrar, definir e gerenciar os serviços disponibilizados para múltiplos clientes. Diferentes
plataformas podem fazer uso do mesmo WebService, evitando retrabalho.
As implementações SOA dependem de uma rede de serviços de software. Cada serviço
implementa uma ação, como persistir um objeto em um banco de dados, ou listar os resultados
de uma query. Ao invés de realizar de chamadas diretas para o código fonte, os serviços
definem protocolos que descrevem como enviar e receber as mensagens.
Algumas vantagens dessa arquitetura são:
● As regras de negócio são escritas somente uma vez para todos os clientes.
● O mesmo sistema pode ser usado pelo mesmo usuário em várias plataformas.
Por exemplo, o usuário pode acessar sua conta pelo smartphone ou pela web.
● A arquitetura permite separar completamente a camada das regras de negócio e
a camada da apresentação.
Figura 2.4 - Arquitetura SOA-MC
20
Capítulo 3
Desenvolvimento
3.1 WebService
Modelo de dados
Figura 3.1 - Modelo do banco de dados
21
A figura acima mostra as tabelas do banco de dados utilizado, juntamente com suas
colunas. Além disso, podemos ver o tipo de dado de cada coluna, e quem é chave primária ou
chave estrangeira. As relações entre as colunas também são apresentadas.
A tabela principal é o usuário. Nela temos as informações referentes à conta do usuário,
ou seja, um e-mail e a senha. Todas as tabelas tem como chave primária um índice auto-
incrementado. A segunda tabela é pessoa. O relacionamento entre usuário e pessoa é de 1:n,
isto é, um usuário pode possuir várias pessoas. Uma regra já mencionada é que um usuário
deverá necessariamente possuir ao menos uma pessoa, e esta será a pessoa titular. A pessoa
titular é gerada quando um novo usuário é criado e não poderá ser apagada, somente editada.
Todas as outras pessoas criadas pelo usuário serão dependentes.
As colunas da tabela pessoa têm informações essenciais como peso, altura, tipo
sanguíneo. Existem três chaves estrangeiras na tabela pessoa. A chave estrangeira usuário
relaciona a pessoa a um usuário existente. As chaves historicofamiliar e segurosaude relaciona
a tabela pessoa para as tabelas Histórico Familiar e Seguro Saúde respectivamente. Essas são
as únicas duas tabelas ligadas a pessoa que possuem relacionamento 1:1.
As tabelas Exames, Doenças e Sintomas possuem tabelas auxiliares para guardar
imagens. Isto significa, por exemplo, que um exame pode ter diversas imagens associadas a
ele. Portanto, a relação entre essas tabelas é de 1:n.
Entidades
As entidades são objetos persistentes que representam uma tabela no banco de dados.
Cada instância de uma entidade corresponde a uma linha na tabela em questão. Como
mencionado anteriormente, JPA e Hibernate são usados para transformar uma classe JAVA
comum em uma entidade. Os métodos getters e setters são utilizados para acessar e modificar
as variáveis da entidade, enquanto equals e hashcode são usados para identificar unicamente
a instância de uma entidade.
As configurações da persistência ficam a cargo do arquivo persistence.xml. Lá
definimos qual banco de dados nosso sistema vai acessar, usuário e senha deste banco, driver
usado para acesso ao banco, qual dialeto SQL deve ser usado apara gerar as queries.
Figura 3.2 - Propriedades de conexão com o Postgres
22
Abaixo, segue como exemplo como é feito o mapeamento da entidade usuário. A
anotação @Entity identifica a classe como uma entidade, e a anotação @Table define o nome
da tabela no banco de dados. A anotação @XmlRootElement diz que esse é um objeto raiz
para as representações JSON ou XML dessa classe. Essa anotação se faz necessária, pois os
dados transmitidos do WebService para a aplicação mobile devem estar no formato JSON. @Id
identifica uma chave primária, @Column nos permite especificar o nome da coluna no banco
de dados. @SequenceGenerator cria uma sequência e @GeneratedValue especifica que
queremos usar a sequence já criada para popular essa coluna. @Index cria um índice para
facilitar a busca que tem como parâmetro a coluna indexada. @Type nos permite especificar o
tipo de dado que queremos ter na tabela.
Figura 3.3 - Entidade Usuario e seus atributos
EntityManager
O nome é bastante intuitivo. É a classe do JPA responsável por administrar as
entidades. Ela é o serviço central para todas as ações de persistência. Ela é a ferramenta
chave que facilita as transações entre as entidades e o banco de dados.
O EntityManager vai mapear as classes entidades para o banco de dados configurado.
O conjunto de classes entidades é chamado de unidade de persistência. Antes de poder fazer
uso das funcionalidades do EntityManager, tal unidade de persistência deve ser configurada no
arquivo persistence.xml, assim como foi configurado as propriedades de acesso ao banco de
dados.
23
Figura 3.4 - Configuração da persistence unit
Para criar uma instância do EntityManager, usamos a classe EntityManagerFactory.
Esse trabalho é feito na classe EntityManagerUtil. Depois de instanciar o EntityManager,
podemos usar seus métodos para gerenciar as entidades. Para persistir uma entidade, por
exemplo, simplesmente usamos o método “persist” ou “merge”. Para fazer uma consulta, é
usado o método “find”, e para excluir um registro no banco de dados relacionado a um banco
de dados, usamos o método “remove”.
Resources
Essas são as classes de recursos do WebService. São elas as responsáveis de realizar
as operações CRUD no banco de dados. Essas classes abstraem e encapsulam os
mecanismos de acesso a dados, escondendo os detalhes da execução da origem dos dados.
Dessa maneira, existe uma classe exclusivamente para trabalhar com cada tipo de objeto e
realizar tarefas como inserir, deletar, atualizar, listar. Este padrão permite dividir as
responsabilidades das operações em classes, o que segue o princípio de uma boa prática de
programação: “Dividir para conquistar!”.
Usando uma camada separada para o acesso a dados, estamos evitando futuros
inconvenientes como dificuldade de replicação do código e propensão a erros. Além disso, este
padrão deixa o código mais organizado e fácil de entender.
As classes Resources serão as interfaces entre as entidades e a web. As diversas
requisições serão enviadas pela aplicação mobile e deverão ser interpretadas no WebService
com a ajuda das anotações da arquitetura REST. Por exemplo, o usuário pode requisitar a
inserção de uma determinada alergia, então a classe AlergiaResource irá executar essa
operação e retornar uma mensagem informando o sucesso ou não dessa operação.
24
Abaixo temos detalhado um pedaço da classe AlergiaResource. A anotação @Path
(“/alergia”) permite definir a URL que terá acesso a esse recurso. As anotações @POST,
@GET e @DELETE nos permite especificar qual método será chamado dependendo do tipo
de requisição do cliente. O nome do método não fará parte da URL de requisição e sim o
caminho definido no @Path.
A anotação @Produces permite definir em qual formato queremos mandar o resultado
da operação de volta para nosso cliente. No nosso caso, iremos transmitir os dados de volta
para a aplicação mobile no formato JSON. Dessa maneira, o objeto Alergia é formatado para o
formato JSON antes de ser enviado. Outros formatos comuns de transmitir dados seriam XML,
HTML, ou simplesmente um texto puro.
As operações do tipo @POST também devem especificar que tipo de dado ela vai
consumir. As informações vindas do cliente não chegam no formato JSON, mas sim uma
coleção de pares Chave-Valor. A anotação @Consumes nos permite especificar que tipo de
dados a operação terá que ler. Nesse caso, é passado para ela um array com pares Chave-
Valor, e podemos de maneira simples ler os valores desse array passando como parâmetro as
chaves utilizadas.
25
Figura 3.5 - Classe AlergiaResource
O arquivo web.xml é essencial para a configuração do serviço REST. Nele
configuramos os caminhos das requisições para o servlet nomeado Jersey REST Service. No
arquivo é especificado a classe que define o servlet bem como o caminho das classes usadas
para mapear as URLs. Ainda definimos um padrão URL. Isso leva todas as requisições que
contém /rest/ sejam mapeadas por nossas classes.
26
Figura 3.6 - Arquivo web.xml
3.2 Android
WebServiceTask
Essa classe é uma extensão da classe AsyncTask. Ela é utilizada para comunicação
com o WebService. Qualquer operação de comunicação com o WebService deve ser feita
através desta classe, pois pode demandar um processamento pesado. Os métodos
implementados nessa classe são executados assincronamente, ou seja, fora da thread
principal.
Não é recomendável rodar tarefas pesadas na thread principal do programa, pois isso
impede que a tela mude até que a tarefa esteja completa, isto é, o aplicativo acaba travando
caso esse processo demore muito. O AsyncTask é uma ótima solução para processar tarefas
pesadas, pois encapsula todo o processo pesado e fornece métodos para modificar a interface
do usuário antes, durante e depois da execução.
Os seguintes métodos podem ser implementados para a execução da tarefa:
● onPreExecute: Prepara o ambiente para a execução da tarefa. Geralmente utiliza um
Progress Dialog para mostrar que algo está sendo carregado.
● doInBackground: Aqui é feita a tarefa propriamente dita em uma thread distinta. Após a
execução da tarefa, um objeto do tipo Resultado é retornado.
● onProgressUpdate: Usada para atualizar a interface com o usuário com informações de
progresso vindas do método doInBackground.
● onPostExecute: Executada assim que terminada a tarefa processada no método
doInBackground. Aqui a barra de progresso deve ser dispensada e a tela de interface
com o usuário deve ser atualizada com as informações do resultado da tarefa.
No ID Saúde, o acesso ao WebService é feito no método doInBackground. O resultado
27
de uma operação do tipo GET pode ser um objeto ou uma lista de objetos, enquanto o
resultado de uma operação do tipo POST ou DELETE é um texto informando o sucesso ou não
dessa operação.
Com respeito à passagem de parâmetros, nas operações do tipo GET ou DELETE, os
parâmetros são passados via URL. Por exemplo, caso se queira resgatar as doenças
registradas de uma pessoa, passamos o identificador da pessoa como parâmetro dentro da
URL que é passada para o WebServiceTask, ou se o caso for de apagar uma doença
cadastrada, o parâmetro a ser passado é o identificador da doença.
Já nas operações do tipo POST, os parâmetros são passados através de um array de
NameValuePair que constitui de uma estrutura que mapeia chaves e valores. No caso do
cadastro de uma doença, antes de executarmos a instância do WebServiceTask que irá
solicitar a persistência de dados, devemos passar os dados da doença para esse array. O
método da classe WebServiceTask chamado addNameValuePair se encarrega dessa tarefa.
O resultado dessas operações, como mencionado anteriormente, é feito dentro do
método onPostExecute. O grande desafio é que esse resultado deve ser tratado de acordo com
a operação que foi feita. Por exemplo, caso a operação ter sido fazer o login no sistema, o
resultado será uma mensagem informando o sucesso ou não da operação, e temos que tratar
essa mensagem. Em outra situação, a operação pode ser listar todas as pessoas cadastradas
por um usuário, e o resultado será uma lista de objetos do tipo Pessoa, então temos que tratar
esse resultado e criar no ID Saúde essa lista e apresentá-la para o usuário.
Para driblar esse problema, é criada uma interface chamada AsyncTaskListener. Ela
implementa o método handleResponse que por sua vez é chamado dentro do onPostExecute.
Isso permite as classes que implementarem o AsyncTaskListener a customizarem o tratamento
dos dados vindos do WebService.
Outro fator importante é o tempo limite de operação. Este deve ser configurado a fim de
evitar que o aplicativo demore muito tempo em uma operação onde não há comunicação com o
WebService. São dois tipos de timeouts que devem ser configurados, o connection timeout e o
socket timeout. O connection timeout se refere ao início da conexão. Ele geralmente acontece
quando o servidor não responde o cliente. No ID Saúde, o connection timeout foi configurado
para 10 segundos. O socket timeout se refere à monitoração contínua dos dados que estão
vindo do servidor. Caso essa esse fluxo seja interrompido por tempo maior que o timeout, a
conexão é dada como perdida. No ID Saúde, o socket timeout foi configurado para 15
segundos.
GPS Tracker
Este é um serviço que implementa a interface LocationListener. Esse serviço serve para
buscar a geolocalização do usuário e é usado na implementação de duas funcionalidades:
Mensagem SOS e Serviços. Para acessar o serviço de GPS do aparelho celular, é usada a
classe LocationManager. Existem duas maneiras possíveis de buscar a geolocalização do
usuário via aparelho celular, uma é com o dispositivo GPS do próprio aparelho, e o outro é por
triangulação de antenas, que utiliza a distância até as antenas de telefonia mais próximas para
28
dar uma localização aproximada do aparelho.
A busca por GPS tem a vantagem de ser absolutamente mais precisa, porém, a busca
por triangulação de antenas é definitivamente mais rápida. Os dois métodos são usados, pois
caso se queira uma resposta rápida ou simplesmente o GPS estiver indisponível, o método de
triangulação de antenas se faz necessário.
O método do LocationManager chamado requestLocationUpdates serve para configurar
como queremos atualizar a localização do usuário. Esse método recebe o tempo mínimo e a
distância mínima entre as atualizações, isto é, se a distância configurada for 10 metros, caso o
aparelho se mova 10 metros, a localização será atualizada. O método getLastKnownLocation
retorna a última localização do usuário de acordo com os critérios já configurados. O serviço
também tem a funcionalidade de verificar se o GPS está ativo, pois caso esteja inativo, um pop-
up aparece perguntando se o usuário deseja ligar o GPS. Caso o usuário confirme, ele será
redirecionado para a tela de configuração do GPS.
Mensagem SOS
A classe SOS trabalha de maneira simples. Ela primeiramente busca os contatos de
emergência se comunicando com o WebService com o auxílio da classe WebServiceTask, que
por sua vez executa uma url do formato “/contatoEmergencia/sos?idUsuario= +
Login.usuarioLogado.getIdUsuario()”. O WebService irá assim retornar todos os contatos de
emergência cadastrados do usuário em questão. Esses são guardados em uma lista de objetos
do tipo ContatoEmergencia.
Caso o usuário confirme o envio da mensagem SOS, o sistema irá buscar a localização
do usuário com o auxílio do serviço GPSTracker. Com os dados da localização do usuário, é
usado um método para traduzir esses dados para um endereço utilizando a classe Geocoder.
Feita essa tradução, a lista de contatos de emergência é percorrida. Dentro desse loop,
utilizamos a classe SMSManager para mandar uma mensagem SMS para os telefones
cadastrados.
Serviços
Como já mencionado anteriormente, o Google Maps API é usado para apresentar ao
usuário um mapa que será populado com marcadores de onde estão os serviços que estão
selecionados por ele. São três as opções de serviço que o usuário pode buscar: hospital,
bombeiro, polícia. A query executada pelo para buscar os serviços deve ser feita fora da main
thread, pois demanda comunicação externa e pode demorar apara ser executada. Para
contornar esse problema, é criada uma classe interna que estende AsyncTask para fazer esse
processamento.
A classe interna em questão é chamada de GetPlaces, e ela recebe como parâmetro
somente a URL para buscar os lugares. Ela faz uma requisição do tipo HttpGet e trata o
resultado para popular um array do tipo Marker para mostrar no mapa os lugares encontrados
juntamente com seus detalhes.
29
São duas as regras para atualizar o mapa. Caso o sistema detecte um evento de
seleção de item de um dos menus, o método de atualizar o mapa é disparado. Ou caso o
sistema detecte uma mudança de localização. O sistema consegue detectar uma mudança de
localização, pois a classe Serviços está implementando a interface LocationListener, o que nos
permite sobrescrever o método onLocationChanged.
30
Capítulo 4
Requisitos de Software
O sistema tem como objetivo facilitar o cuidado com nossa saúde de acordo com o perfil
do usuário. Utilizando o sistema, o usuário terá a funcionalidade de cadastrar, alterar, consultar,
remover um perfil, informar dados de saúde, além de procurar serviços e enviar uma
mensagem SOS para contatos de emergência.
Nesse capítulo, será descrito para cada caso de uso os requisitos funcionais e
eventuais regras de negócio, que serão representadas pelas siglas RF e RN, respectivamente.
Não serão abordados todos os casos de uso, pois muitos são praticamente idênticos, e seria
repetitivo abordar cada um.
4.1 Login
Figura 4.1 - Tela de Login
O usuário deve ser capaz de ao entrar no aplicativo, realizar login para acessar sua conta.
RF01 – Ao clicar no botão Entrar, os dados inseridos (Login/E-mail e senha) serão verificados.
Caso a autenticação tenha sucesso, o usuário será redirecionado para a tela principal do
aplicativo. Caso contrário, o usuário receberá uma mensagem de erro.
RF02 – Ao clicar no botão Cadastre-se, o usuário será redirecionado para uma nova tela onde
31
é possível cadastrar um novo usuário.
RF03 – Caso o Check Box “Login automático“ esteja marcado, o usuário não precisará se logar
toda vez que entrar no aplicativo.
RN01 – Para entrar no sistema, o usuário deverá preencher obrigatoriamente os campos e-mail
e senha.
4.2 Cadastrar novo usuário
Figura 1.2 - Tela de cadastro de novo usuário
O usuário deve ser capaz de cadastrar um novo usuário.
RF01 – Ao clicar no botão “Confirmar”, os dados inseridos serão enviados para um web service
que criará no banco de dados um novo usuário e uma nova pessoa.
RF02 – Após o sucesso do cadastro, o usuário será redirecionado de volta para a tela de Login.
RN01 – Para o cadastro ter sucesso, o e-mail deverá ter um formato válido, e os dois campos
de senha devem ter igual conteúdo.
32
RN02 – A pessoa criada juntamente com o novo usuário será o titular da conta. Todas as
demais pessoas criadas serão dependentes.
4.3 Tela principal
Figura 4.3 - Tela principal do aplicativo
RF01 – Ao clicar no botão cadastrar, o usuário será redirecionado para a tela de cadastro de
pessoa.
RF02 – Ao clicar no botão listar, o usuário será redirecionado para a tela de Listar Pessoas.
RF03 – Ao clicar no botão Mensagem SOS, o usuário estará solicitando um envio de
mensagem de socorro contendo sua atual localização que será enviada para seus contatos de
emergência cadastrados.
RF04 – Ao clicar no botão Serviços, o usuário será redirecionado para uma tela que contém um
mapa com sinalizadores de onde se encontram unidades do tipo de serviço por ele selecionado
(Hospital, Bombeiro, Polícia).
33
4.4 Cadastrar nova pessoa
Figura 4.4 - Tela de cadastro de pessoa
RF01 – Caso seja uma pessoa existente, os campos deverão ser preenchidos com os dados
dessa pessoa. Caso contrário, os campos virão em branco.
RF02 – Ao clicar no botão “Confirmar”, os dados inseridos serão enviados para um web service
que criará no banco de dados uma nova pessoa.
RF03 – Após o sucesso do cadastro, o usuário será redirecionado de volta para a tela de Listar
Pessoas.
34
4.5 Listar pessoas
Figura 4.5 - Tela de listagem de pessoas cadastradas
RF01 – Nesta tela o usuário irá receber uma lista contendo todas as pessoas cadastradas.
RF02 – Ao clicar em uma das pessoas cadastradas, o usuário será redirecionado para a tela de
grupos de Informações.
RF03 – Clicando e segurando o dedo sobre a pessoa cadastrada, o usuário abrirá um menu
com a opção de “Apagar” para apagar a pessoa selecionada.
RF04 – Ao clicar em “Apagar”, a pessoa será removida do banco de dados juntamente com
todas as suas dependências e a lista será atualizada.
35
4.6 Mensagem SOS
Figura 4.6 - Tela de envio de mensagem SOS
Figura 4.7 - Mensagem SOS enviada
36
RF01 – Antes do envio de mensagem SOS, o usuário terá que confirmar a situação de
emergência. Caso ele confirme o envio de mensagem SOS, o sistema irá buscar os contatos
de emergência cadastrados para a pessoa titular.
RF02 – Caso não haja nenhum contato de emergência cadastrado, uma mensagem informativa
irá aparecer e o usuário será redirecionado para a tela principal. Caso contrário, um serviço irá
buscar a localização atual do usuário, e enviará uma mensagem requisitando ajuda para esses
contatos.
4.7 Serviços
Figura 4.8 - Tela de serviços
RF01 – Ao escolher um novo raio de busca, ou uma nova categoria de serviço pelos menus
drop-down presentes na tela, o sistema irá buscar através do Google Places lugares que
37
atendem os critérios definidos.
RF02 – Um mapa do Google Maps API irá mostrar a localização desses lugares juntamente
com a localização do usuário.
RN01 – Há um limite de número de lugares que a query retorna, pois caso o raio seja muito
grande, uma lista muito grande de lugares seria retornada, o que deixaria o processamento
muito pesado.
4.8 Grupos de Informação
Figura 4.9 - Tela de grupos de informação
38
RF01 – Esta tela tem o objetivo de apresentar de maneira intuitiva as categorias de dados que
podem ser guardados e processados pelo ID Saúde.
RF02 – Quando o usuário selecionar um ícone, ele irá ser redirecionado para a tela
correspondente seguindo as seguintes regras:
1. Caso o usuário selecione Dados Pessoais, Seguro Saúde ou Histórico Familiar,
ele será redirecionado para a tela de edição desses itens.
2. Caso o usuário selecione Eventos, ele será redirecionado para a tela que lista
os tipos de eventos.
3. Todos os demais itens, quando selecionados redirecionam o usuário para uma
tela que lista registros dos dados correspondentes.
4.9 Lista de exames
Figura 4.10 - Tela de listagem de exames
39
RF01 – Nesta tela o usuário irá receber uma lista contendo todos os exames cadastrados.
RF02 – Ao clicar em um dos exames cadastrados, o usuário será redirecionado para a tela de
cadastro/edição do exame.
RF03 – Clicando e segurando o dedo sobre o exame cadastrado, o usuário abrirá um menu
com a opção de “Apagar” para apagar o exame selecionado.
RF04 – Ao clicar em “Apagar”, o exame será removido do banco de dados juntamente com
todas as suas dependências e a lista será atualizada.
RF05 – O botão “Adicionar” fará o usuário ser redirecionado para a tela de cadastro de um
novo exame.
4.10 Cadastro de exames
Figura 4.11 - Tela de cadastro de exames
RF01 – Caso seja um exame existente, os campos deverão ser preenchidos com os dados
desse exame. Caso contrário, os campos virão em branco.
RF02 – Ao clicar no botão “Confirmar”, os dados inseridos serão enviados para um web service
40
que criará ou irá editar no banco de dados o exame.
RF03 – Após o sucesso do cadastro, o usuário será redirecionado de volta para a tela de Listar
Exames.
4.11 Pressão sanguínea
Figura 4.12 - Tela de registros de medição de pressão sanguínea
RF01 – A tela deverá apresentar um gráfico que apresenta todos os registros de medições de
pressão sanguínea da pessoa.
RF02 – Ao clicar sobre um número, uma mensagem irá aparecer informando o dia exato da
medição.
RF03 – Ao clicar no botão “Adicionar registro de pressão”, o usuário será redirecionado para a
tela de cadastro de pressão.
41
4.12 Cadastro de medição de pressão sanguínea
Figura 4.13 - Tela de cadastro de medição de pressão sanguínea
RF01 – Ao clicar no botão “Confirmar”, os dados inseridos serão enviados para um web service
que criará no banco de dados um novo registro de medição de pressão.
RF02 – Após o sucesso do cadastro, o usuário será redirecionado de volta para a tela que
apresenta os registros de pressão sanguínea graficamente.
42
Capítulo 5
Conclusões e Trabalhos Futuros
5.1 Conclusões
Este projeto englobou diversos tópicos na área de computação aprendidos durante a
graduação. Foram colocados em prática os conceitos de orientação a objetos e integração de
aplicações com um banco de dados. O desenvolvimento de um sistema funcional ajudou a
consolidar os ensinamentos de sala de aula.
Também foi colocado em prática conceitos da área de engenharia de software. A
decisão de quais tecnologias e arquitetura de software devem ser usadas foi muito importante
para o desenvolvimento de um bom sistema. A comunicação entre a aplicação mobile e o Web
Service foi peça fundamental na construção do sistema. A especificação funcional do sistema
também teve grande importância para guiar o desenvolvimento do sistema.
O projeto também ajudou a amadurecer meu espírito empreendedor. Construir um
sistema que atende uma necessidade real me fez sentir capaz de um dia construir um negócio
de sucesso e me estimulou a estudar um pouco sobre empreendedorismo. Não seria
exagerado dizer que depois da realização deste projeto final, minha mente tem uma visão
diferente. Vejo possibilidades de negócio e tenho novas ideias frequentemente, e agora tenho a
ambição de fazer algo útil para a sociedade com os conhecimentos adquiridos durante a
faculdade.
5.2 Trabalhos futuros
O ID Saúde pode ser ainda muito explorado. A área de saúde ainda carece de muitas
soluções e inovação. A tecnologia tem o papel de prover seus recursos e aplicar na área de
saúde. Dessa maneira, muito ainda pode se fazer para tornar esse projeto ainda mais
funcional.
Aplicação WEB e iOS
O ID Saúde não foi construído para ser acessado somente pelo aplicativo Android. A
ideia de uma arquitetura orientada a serviços é justamente permitir acesso ao sistema por
múltiplos clientes. Dessa maneira, dois clientes poderiam ser desenvolvidos, uma aplicação
web e um aplicativo para Smartphones com o sistema operacional iOS.
A aplicação web seria ideal para melhor visualização dos dados e inserção de grande
volume de dados. E o aplicativo para iOS serviria para atender a grande parte do mercado que
Apple possui. Ambos os clientes teriam o estilo e a aparência parecidas com o cliente Android
e também poderiam consumir o mesmo WebService já criado.
43
Modelo de negócios
O modelo de negócios que mais se encaixa nesse projeto é o modelo Freemium [13].
Nesse modelo, as funcionalidades mais básicas do produto são disponibilizadas sem custos,
porém, funcionalidades mais avançadas tem um preço. A premissa básica por trás do modelo é
a de que, ao oferecer aos potenciais clientes um pedaço gratuito do serviço, diminui-se a
barreira para experimentação inicial e aumenta-se a efetividade na aquisição de clientes
através de marketing boca-a-boca.
Outra forma de receita seria construir parcerias com laboratórios, operadoras de saúde,
e redes de farmácia. Um laboratório poderia disponibilizar o resultado de um exame
diretamente no sistema. Uma operadora de saúde poderia ter acesso aos dados de seus
clientes, facilitando o atendimento e conhecendo mais o paciente. E uma rede de farmácia
poderia fazer propaganda para usuários do sistema.
Dicas de saúde
Para ser um aplicativo de saúde ainda mais completo, disponibilizar dicas de saúde
agregaria mais valor ao sistema. O usuário poderia tanto buscar informações, que seriam
agrupadas em temas, ou receber as dicas de saúde como notificações de acordo com o seu
perfil.
A entrega de informação personalizada para o usuário é uma tendência muito forte. O
usuário vai se sentir mais valorizado e com certeza irá dar mais valor às dicas recebidas. Um
exemplo desse processo seria um usuário com diabetes que poderia configurar seu aplicativo
para receber diariamente uma dica de saúde. Sabendo que o usuário é diabético, o sistema vai
mandar uma informação específica para uma pessoa diabética.
O serviço Google Cloud Messaging seria ideal para o desenvolvimento dessa
funcionalidade. Com esse serviço, ao invés do aplicativo ir buscar a informação, um
WebService pode enviar uma notificação para um determinado dispositivo cadastrado.
Integração com aparelhos de saúde
Outra funcionalidade que iria enriquecer o sistema seria a integração com aparelhos de
saúde. Existem no mercado aparelhos de saúde com Bluetooth, isto é, é possível realizar a
comunicação do aplicativo Android com o aparelho e assim automatizar o envio de medições
de pressão sanguínea por exemplo.
44
Figura 6.1 - Aparelho de medição de pressão sanguínea
Ao medir a pressão sanguínea, o aparelho enviaria automaticamente os dados da
medição para o aplicativo e este faria o registro de uma nova medição. Neste caso, o usuário
deve garantir que o Bluetooth do aparelho celular está ligado.
Esta funcionalidade abre as portas para a inovação em uma área na saúde que já
existe, a área do Home Cair. Para pacientes que precisam ser monitorados remotamente, este
sistema de autoexame seria ideal. O paciente poderia realizar exames como eletrocardiograma
ou glicose e enviar os dados diretamente para uma central com profissionais na área de saúde
que iriam analisar esses dados.
Processamento de eventos complexos
Expandindo essa ideia de monitoração da saúde dos usuários, o conceito de
processamento de eventos complexos cairia como uma luva para a implementação dessa
funcionalidade. O volume de dados a ser processado pode ser de grande proporção. Assim
sendo, o sistema deve possuir uma arquitetura que permita processar um grande volume de
dados em tempo real.
O CEP (Complex Event Processing) é uma tecnologia de rastreamento e análise de um
fluxo de dados. A tecnologia funciona como se fosse um banco de dados de cabeça para baixo.
Ao invés de guardar os dados e rodar queries em cima desses dados, o que são guardados
são as queries, e os dados são enviados para serem processados.
No sistema então teríamos como entrada eventos de saúde, que poderia ser, por
exemplo, uma medição de pressão sanguínea. O sistema iria então processar todos os eventos
que chegam e de acordo com regras estabelecidas iria redirecionar a informação ou executar
alguma ação específica. Uma medição de pressão com valores fora do comum iria criar um
alerta que chegaria ao conhecimento do médico responsável pelo paciente em pouco tempo.
45
Referências Bibliográficas
[1] “Anamnese (saúde)” - http://pt.wikipedia.org/wiki/Anamnese_(sa%C3%BAde)
[2] “Scrum Academic” - http://www.sbvb.com.br/proposals/Scrum-Academic-sbvb.com.br.pdf
[3] “Android dominates 81 percent of world smartphone market” -
http://www.cnet.com/news/android-dominates-81-percent-of-world-smartphone-market
[4] “Official site provides the SDK, Developer's Guide, Reference, and Android Market for the
open source project.” - developer.android.com/
[5] “An Android REST Client and Tomcat REST WebService” - http://avilyne.com/?p=105
[6] “JSON: What It Is, How It Works, & How to Use It” - http://www.copterlabs.com/blog/json-
what-it-is-how-it-works-how-to-use-it/
[7] “Apache Tomcat” - http://tomcat.apache.org/
[8] “Uma introdução prática ao JPA com Hibernate” - http://www.caelum.com.br/apostila-java-
web/uma-introducao-pratica-ao-jpa-com-hibernate/#14-1-mapeamento-objeto-relacional
[9] “PostgreSQL” - http://www.postgresql.org/
[10] “AChartEngine” - http://www.achartengine.org/
[11] “Android working with Google Maps V2” –
http://www.androidhive.info/2013/08/android-working-with-google-maps-v2/
[12] “SOA_MC Service Oriented Architecture – Multiple Client” -
http://www.sbvb.com.br/proposals/SOA-MC-sbvb.com.br.pdf
[13] “O modelo freemium para startups” –
http://www.manualdastartup.com.br/blog/o-modelo-freemium-para-startups-parte-i
