UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA PARA CONTROLE DE PLANOS ALIMENTARES, UTILIZANDO
UM DISPOSITIVO MÓVEL
Área de Computação Móvel
por
Thiago Antonio de Sousa Ferreira
Rudimar Luis Scaranto Dazzi, Dr.
Orientador
Itajaí (SC), Agosto de 2007
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA PARA CONTROLE DE PLANOS ALIMENTARES, UTILIZANDO
UM DISPOSITIVO MÓVEL
Área de Computação Móvel
por
Thiago Antonio de Sousa Ferreira
Relatório apresentado à Banca Examinadora do
Trabalho de Conclusão do Curso de Ciência da
Computação para análise e aprovação.
Orientador: Rudimar Luís Scaranto Dazzi, Dr.
ITAJAÍ (SC), AGOSTO DE 2007
DEDICATÓRIA
Aos meus pais, Luiz Antonio Ferreira e Neusa Maria de Sousa Ferreira,
pelo apoio incontestável, dedicação, amor, carinho, educação e
por todos os outros motivos que me fazem sentir orgulho de ser seu filho.
A minha irmã Letícia e meu irmão Davi por fazerem parte da minha vida.
Aos meus tios Lino e Cristina, por me apoiarem e me incentivar sempre que necessário.
Aos verdadeiros amigos, por terem cruzado meu caminho.
ii
AGRADECIMENTOS
Aos meus pais, Luiz Antonio Ferreira e Neusa Maria de Sousa Ferreira, que não pouparam
esforços para minha formação, a quem devo tudo e expresso meu eterno amor e gratidão.
Ao professor Rudimar Luis Scaranto Dazzi pela orientação, compreensão e apoio no
decorrer deste um ano.
Aos professores que compunham a banca examinadora, Anita e Cezar pelas valiosas
sugestões e críticas que fortaleceram o desenvolvimento desse trabalho.
Aos amigos, Rafael Pacheco Luz, Cezar Schwartz, Thiago Ligeiro, Raphael Nascimento,
Héderson Silva, Marcelo Souza e Fábio Moriguchi que me agüentaram nos últimos meses, mesmo
muitas vezes não merecendo, sempre procurando me apoiar, me incentivar e não deixando que eu
desistisse deste sonho que agora se torna realidade.
Aos meus ex-colegas de trabalho e eternos amigos, Ilton, Jessé, Sandra, Geziel, Edvaldo,
Fabiano, João Paulo, Jeane e Anderson, que sempre me incentivaram e muitas vezes me ajudaram
para que hoje eu pudesse chegar aqui.
A todos os demais verdadeiros e grandes amigos, que mesmo estando longe, sempre me
deram força e confiaram em mim.
iii
SUMÁRIO
LISTA DE ABREVIATURAS...............................................................vii
LISTA DE FIGURAS ...........................................................................viii
LISTA DE TABELAS.............................................................................. x
RESUMO.................................................................................................xi
ABSTRACT............................................................................................xii
1 INTRODUÇÃO....................................................................................1
1.1 PROBLEMATIZAÇÃO................................................................................... 3
1.1.1 Formulação do Problema............................................................................... 3
1.1.2 Solução Proposta ............................................................................................ 3
1.2 OBJETIVOS ..................................................................................................... 4
1.2.1 Objetivo Geral................................................................................................ 4
1.2.2 Objetivos Específicos...................................................................................... 4
1.3 METODOLOGIA............................................................................................. 5
1.4 ESTRUTURA DO TRABALHO ..................................................................... 6
2 FUNDAMENTAÇÃO TEÓRICA ......................................................7
2.1 COMPUTAÇÃO MÓVEL............................................................................... 7
2.2 DISPOSITIVOS MÓVEIS ............................................................................... 8
2.3 TECNOLOGIAS DE DESENVOLVIMENTO............................................. 11
2.3.1 .NET.............................................................................................................. 12
2.3.2 BREW ........................................................................................................... 12
2.3.3 SuperWaba ................................................................................................... 13
2.4 J2ME ............................................................................................................... 13
2.4.1 Configuração ................................................................................................ 14
2.4.2 Perfis ............................................................................................................. 15
2.4.3 JVM .............................................................................................................. 16
2.4.4 Vantagens do J2ME ..................................................................................... 16
2.5 AMBIENTE DE DESENVOLVIMENTO .................................................... 16
2.5.1 Java 2 Standard Edition .............................................................................. 17
2.5.2 Wireless Toolkit............................................................................................ 17
2.5.3 Eclipse ........................................................................................................... 18
2.6 WEB SERVICES............................................................................................ 18
2.6.1 Arquitetura dos Web Services..................................................................... 19
2.6.2 Segurança dos Web Services ....................................................................... 20
2.7 TECNOLOGIAS PARA COMUNICAÇÃO SEM FIO ............................... 20
2.7.1 WAP.............................................................................................................. 21
2.7.2 Infra Vermelho............................................................................................. 24
2.7.3 SyncML......................................................................................................... 24
iv
2.7.4 BlueTooth ..................................................................................................... 25
2.8 NUTRIÇÃO .................................................................................................... 26
2.8.1 Avaliação Nutricional .................................................................................. 27
2.8.2 Transtorno Alimentar.................................................................................. 29
2.8.3 Prescrição Alimentar ................................................................................... 32
2.9 TRABALHOS RELACIONADOS ................................................................ 32
2.9.1 Calorie Burner - Diet and Exercise Planner............................................... 33
2.9.2 MyPersonalDiet............................................................................................ 34
2.9.3 PmEB: A Mobile Phone Application for Monitoring Caloric Balance ..... 35
2.9.4 Uso da Tecnologia Móvel no Auxílio à Reeducação Alimentar ................. 36
2.9.5 Análise das ferramentas similares............................................................... 37
2.10 INTEGRAÇÃO COM O SISTEMA PARA PROGRAMAÇÃO
ALIMENTAR UTILIZANDO RBC ..................................................................... 37
3 DESENVOLVIMENTO ....................................................................40
3.1 ANÁLISE DE REQUISITOS ........................................................................ 40
3.1.1 Requisitos Funcionais .................................................................................. 41
3.1.2 Requisitos Não Funcionais........................................................................... 41
3.1.3 Regras de negócio......................................................................................... 42
3.2 MODELAGEM DO SISTEMA ..................................................................... 42
3.2.1 Diagrama de Classes .................................................................................... 42
3.2.2 Diagrama de casos de uso ............................................................................ 45
3.2.3 Diagrama de Implantação ........................................................................... 46
3.2.4 Diagrama de Seqüência................................................................................ 47
3.3 MODELAGEM DO BANCO DE DADOS.................................................... 51
3.4 IMPLEMENTAÇÃO ..................................................................................... 53
3.5 TESTE E VALIDAÇÕES .............................................................................. 59
4 CONCLUSÕES..................................................................................61
REFERÊNCIAS BIBLIOGRÁFICAS..................................................63
GLOSSÁRIO..........................................................................................67
A MODELAGEM DO SISTEMA ........................................................69
A.1 CASOS DE USO ............................................................................................. 69
A.1.1 Pacote 01: Controle de Acesso ..................................................................... 69
A.1.2 Pacote 02: Consultas .................................................................................... 71
A.1.3 Pacote 03: Consultas .................................................................................... 74
A.2 PROTÓTIPOS DAS TELAS DO SISTEMA ................................................ 78
A.2.1 TEL001: Login no sistema........................................................................... 78
A.2.2 TEL002: Mensagens do sistema .................................................................. 78
A.2.3 TEL003: Menu principal do sistema........................................................... 79
A.2.4 TEL004: Tela de cadastro de agendamento de refeições ........................... 79
A.2.5 TEL005: Tela de cadastro de medidas dos pacientes ................................. 80
v
A.2.6 TEL006: Tela de cadastro de dúvidas......................................................... 80
A.2.7 TEL007: Tela de cadastro do questionário 24hrs....................................... 81
A.2.8 TEL008: Tela do Questionário geral de freqüência de alimentos ............. 81
A.2.9 TEL009: Tela de consulta de prescrição alimentar.................................... 82
A.2.10
TEL010: Tela de consulta de dúvidas................................................... 82
A.2.11
TEL011: Tela de resposta ás dúvidas................................................... 83
A.2.12
TEL012: Tela de pesquisa de alimentos semelhantes .......................... 83
A.2.13
TEL013: Tela de alimentos semelhantes encontrados......................... 84
A.2.14
TEL014: Tela de alimentos evitados..................................................... 84
A.2.15
TEL015: Tela de observação sobre o alimento evitado ....................... 85
A.3 MODELO DO BANCO DE DADOS............................................................. 86
A.3.1 Diagrama ER do banco de dados ................................................................ 86
vi
LISTA DE ABREVIATURAS
BREW
CDC
CLDC
GPRS
HTTP
HTTPS
J2EE
J2ME
J2SE
JVM
MVC
PAN
PDA
RDA
RBC
SOAP
SSL
SyncML
TCC
UDDI
UML
UNIVALI
USB
WAP
WSDL
WTLS
WTK
XML
Binary Runtime Environment for Wireless
Connected Device Configuration
Connected Limited Device Configuration
General Packet Radio Service
HiperText Transfer Protocol
HiperText Transfer Protocol Secure
Java 2 Enterprise Edition
Java 2 Micro Edition
Java 2 Standard Edition
Java Virtual Machine (Maquina Virtual Java)
Model, View, Controler
Personal Área Network
Personal Digital Assistants
Recommended Dietary Allowances
Raciocínio Baseado em casos
Simple Object Access Protocol
Secure Sockets Layer
Synchronization Markup Language
Trabalho de Conclusão de Curso
Universal Description, Discovery and Integration
Unified Modeling Language
Universidade do Vale do Itajaí
Universal Serial Bus
Wireless Application Protocol
Web Service Description Language
Wireless Transport Layer Security
Wireless Toolkit
Extensible Markup Language
vii
LISTA DE FIGURAS
Figura 1. Arquitetura da aplicação ...................................................................................................4
Figura 2. Número de celulares no Brasil ........................................................................................10
Figura 3. Camadas de Software do J2ME.......................................................................................14
Figura 4. Tela do Emulador do WTK.............................................................................................17
Figura 5. Interação dos Componentes do Web Service...................................................................19
Figura 6. Pilha de protocolos WAP................................................................................................22
Figura 7. Acesso a internet na forma convencional ........................................................................23
Figura 8. Acesso à internet através da tecnologia WAP..................................................................24
Figura 9. Funcionamento do SyncML............................................................................................25
Figura 10. Tela de controle do Balanço Alimentar e Calendário de atividades físicas.....................34
Figura 11. Tela do Sistema MyPersonal Diet .................................................................................35
Figura 12. Funcionamento do Sistema PmEB ................................................................................36
Figura 13. Integração entre os Sistemas .........................................................................................38
Figura 14. Celular Nokia 6230i......................................................................................................39
Figura 15. Diagrama de Classes do projeto ....................................................................................44
Figura 16. Diagrama de Caso de uso do pacote Cadastro. ..............................................................45
Figura 17. Diagrama de Caso de uso do pacote Consultas. .............................................................46
Figura 18. Diagrama de implantação e de componente da aplicação ..............................................47
Figura 19. Diagrama de seqüência do Cadastro de Agendamento...................................................48
Figura 20. Diagrama de seqüência do Cadastro do Questionário 24 horas ......................................49
Figura 21. Diagrama de seqüência para o Cadastro geral de freqüência de uso de alimentos ..........50
Figura 22. Diagrama de seqüência para a consulta de prescrição alimentar ....................................51
Figura 23. Diagrama ER do banco de dados...................................................................................52
Figura 24. Estrutura de pacotes da aplicação..................................................................................54
Figura 25. Arquivo build.xml ........................................................................................................55
Figura 26. Login no sistema...........................................................................................................56
Figura 27. Menu principal do sistema. ...........................................................................................56
Figura 28. Tela de cadastro de agendamento de refeições. .............................................................57
Figura 29. Tela de cadastro de medidas dos pacientes. ...................................................................57
Figura 30. Tela de cadastro do questionário 24hrs..........................................................................58
Figura 31. Tela do Questionário geral de freqüência de alimentos..................................................58
Figura 32. Tela de pesquisa de alimentos semelhantes. ..................................................................59
Figura 33. Pacotes do sistema ........................................................................................................69
Figura 34. Login no sistema...........................................................................................................78
Figura 35. Mensagens do sistema ..................................................................................................78
Figura 36. Menu principal do sistema. ...........................................................................................79
Figura 37. Tela de cadastro de agendamento de refeições. .............................................................79
Figura 38. Tela de cadastro de medidas dos pacientes. ...................................................................80
Figura 39. Tela de cadastro de dúvidas. .........................................................................................80
Figura 40. Tela de cadastro do questionário 24hrs..........................................................................81
Figura 41. Tela do Questionário geral de freqüência de alimentos..................................................81
Figura 42. Tela de consulta de prescrição alimentar. ......................................................................82
Figura 43. Tela de consulta de dúvidas. .........................................................................................82
Figura 44. Tela de resposta às dúvidas. ..........................................................................................83
Figura 45. Tela de pesquisa de alimentos semelhantes. ..................................................................83
Figura 46. Menu principal do sistema. ...........................................................................................84
viii
Figura 47. Tela de alimentos evitados. ...........................................................................................84
Figura 48. Tela de observação sobre o alimento evitado.................................................................85
Figura 49. Diagrama ER do banco de dados...................................................................................86
ix
LISTA DE TABELAS
Tabela 1. Número de celulares no Brasil........................................................................................10
Tabela 2. Gerações da Telefonia Celular........................................................................................11
Tabela 3. Comparação dos Aplicativos ..........................................................................................37
x
RESUMO
FERREIRA, Thiago Antonio de Sousa. Sistema para controle de planos alimentares, utilizando
um dispositivo móvel. Itajaí, 2007. 97 f. Trabalho de Conclusão de Curso (Graduação em Ciência
da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do
Itajaí, Itajaí, 2006.
A evolução da computação móvel e dos dispositivos móveis tem possibilitado o desenvolvimento
de sistemas de informação em diversas áreas. Tanto os dispositivos móveis como a computação
móvel evoluíram bastante nos últimos anos. Uma das áreas promissoras para desenvolvimento de
aplicações é a área médica, principalmente pela falta de aplicações voltadas a este mercado e a
grande necessidade de uma melhor interação entre paciente e médico. Na área médica, uma área de
destaque é a nutrição, pois nos dias atuais, muitas pessoas estão preocupadas com a saúde do corpo
bem como no controle ou perda de peso e quantidade de nutrientes presentes em cada alimento,
entretanto muitas vezes este controle se torna difícil devido à falta de tempo do paciente em estar
presente junto ao nutricionista. Além disso, para que os tratamentos alimentares sejam eficazes é
necessário um estimulo psicológico ao paciente. Esta necessidade motivou o desenvolvimento deste
projeto que visou criar um sistema para melhorar a interação entre nutricionista-paciente, criando
uma ferramenta que possibilitará um melhor controle, acompanhamento, permitindo assim ao
nutricionista identificar possíveis transtornos alimentares bem como doenças que o paciente tenha
ou possa vir a desenvolver. O presente texto apresenta o desenvolvimento de um software, baseado
em computação móvel, que permite ao usuário do sistema, cadastrar dúvidas ao nutricionista,
agendar refeições, consultar substituição de alimentos, dentre outras características. O protótipo
desenvolvido consiste num aplicativo rodando em J2ME e que irá se comunicar com o Sistema
Programação alimentar utilizando RBC, projeto de conclusão de curso desenvolvido pelo
acadêmico Marcelo Miotto, fornecendo informações sobre o paciente ao nutricionista. Também
foram pesquisadas soluções similares, a fim de reforçar os conhecimentos adquiridos. Para o
desenvolvimento e implementação deste projeto foram estudados os principais conceitos de
computação Móvel, Dispositivos Móveis, comunicação dos dispositivos móveis e da área de
nutrição, também foi utilizado o padrão UML com o auxilio da ferramenta Enterprise Architect para
descrição dos diagramas do projeto, diagramas de caso de uso, diagramas de seqüência e de
componente. Os testes e validações, foram efetuadas no emulador e seguindo os conceitos de testes
de software.
Palavras-chave: Computação Móvel, J2ME, Nutrição.
xi
ABSTRACT
The evolution of the mobile computing and the mobile devices has made possible the development
of systems of information in diverse areas. As much the mobile devices as the mobile computing
developed sufficiently in the last years. One of the promising areas for the development of
applications is the medical area, mainly for the lack of applications directed to this market and the
great necessity of one better interaction between patient and doctor. In the medical area, a
prominence area is nutrition, therefore in current days, many people are worried about the health
of the body as well as the control or loss of weitht and amout of nutrients available in each food,
however several times this control becomes difficult due to the lack of time of the patient in being
with the nutritionist. Moreover, in order to the alimentary treatments be efficient it is necessary one
psychological stimulus to the patient. This necessity motivated the development of this project that
aims to create a system to improve the interaction between nutritionist-patient, creating a tool that
will make possible one better control, attendance, thus allowing to the nutritionist to identify
possible alimentary disturbs as well as illnesses that the patiente has or can develop. The currency
text presents the proposal of a software, based on mobile computing, which allows the user of the
system, to register doubts to the nutritionist, set meals, consult food substitution, amongst other
characteristics. The solution proposed consists of an application twirling in the J2ME (Java 2,
Micro Edition) and that it will integrate to the Alimentary Programming System using RBC, project
in conclusion stage that is being developed by the academic Marcelo Miotto. It has been also
searched similar solutions, in order to strengthen the acquired knowledge. For the development of
this project the main concepts of Mobile Computing had been studied, mobile devices,
communication of the mobile devices and of the nutrition area, also was used the UML standard
with the aid of the tool Enterpise Architect for description of the diagrams of the project.
Keywords: Mobile Computing, J2ME, Nutrition.
xii
1 INTRODUÇÃO
Nos últimos anos, os dispositivos móveis evoluíram bastante, a ponto de suportarem a
execução de softwares funcionais.
Segundo Mateus e Loureiro (1998),
A miniaturização dos dispositivos eletrônicos, o aumento do poder de processamento destes
dispositivos aliado à necessidade do ser humano permanecer informado a qualquer hora e
em qualquer lugar foi um dos motivos da grande popularização dos aparelhos celulares,
hoje são mais de um bilhão de telefones celulares no mundo e esse número cresce a cada
dia.
Segundo Figueiredo e Nakamura (2003),
Computação móvel surge como uma quarta revolução na computação antecedida pelos
grandes centros de processamento da década de sessenta, o surgimento dos terminais nos
anos setenta, e as redes de computadores na década de oitenta.
Cada vez mais o controle para a gestão das informações em saúde tem sido feito pelo uso de
ferramentas tecnológicas, e as pessoas cada vez mais usam sistemas computacionais para controle e
auxílio nas tarefas do dia a dia. (FRANK, 1986).
O uso de Sistemas Computacionais na Área de Saúde e a evolução da tecnologia de
dispositivos Móveis motivaram o desenvolvimento do Sistema para controle de planos alimentares
utilizando um dispositivo móvel. Tendo em vista esta demanda por soluções que se apliquem a
celulares, este projeto teve como objetivo criar um sistema de controle de planos alimentares,
auxiliando na decisão sobre alimentação seja para aumento ou perda de peso.
Este sistema visou ser um complemento ao sistema Programação alimentar utilizando RBC
(Raciocínio Baseado em Casos) que foi desenvolvido por Miotto (2006). O sistema “Programação
alimentar utilizando RBC” é um sistema com o objetivo de fornecer um acompanhamento do
paciente com o nutricionista.
Segundo Miotto (2006), “o sistema Programação Alimentar Utilizando RBC permite ao
paciente estar em contato com o nutricionista através da internet, e não somente nas consultas
pessoais, sendo que esta característica permite uma importante interação ao sucesso do tratamento”.
Ainda segundo Miotto (2006), outra característica importante deste sistema, é a utilização da
Inteligência Artificial, que a partir de avaliações nutricionais anteriores a utiliza como base para
novas prescrições.
O Sistema Programação alimentar utilizando RBC apresenta uma alternativa de substituição
de alimentos sem perdas de valor nutricional conforme os padrões dos alimentos, e com as
peculiaridades de cada individuo, inclusive em casos que durante o tratamento possam ocorrer
situações como festa, deve ter-se a possibilidade do nutricionista responsável recomendar
alternativas de alimentação, de maneira interativa.
O Sistema para controle de planos alimentares utilizando um dispositivo móvel, visou ser
um complemento ao sistema Programação alimentar utilizando RBC. Este sistema criou uma
interação do paciente com o nutricionista, sem que o mesmo esteja necessariamente presente ao
nutricionista, para que isto ocorra, são necessárias algumas funcionalidades tais como:

Permitir o agendamento da alimentação com horário marcado;

Permitir a consulta de substituição de alimentação;

Permitir ao paciente cadastrar e consultar dúvidas e

Permitir ao paciente o cadastro dos seus dados clínicos e antropometricos, dentre outros;
Para redução dos custos com a Internet, a aplicação foi armazenada no celular do usuário
sendo feito o envio de dados para a internet somente quando for necessário ou de acordo com a
capacidade de armazenamento do dispositivo.
O Sistema para controle de planos alimentares utilizando um dispositivo móvel permite ao
paciente informar via celular o alimento consumido a quantidade consumida e o horário em que o
mesmo foi consumido, uma vez que nem sempre é possível se alimentar com o que está proposto no
plano alimentar. Nesse caso deve ser feito um replanejamento para as próximas refeições de forma a
compensar a alimentação errada. O Sistema também permite armazenar data e hora de cada
alimentação, o alimento e a quantidade consumida, e oferecer sugestões de alimentos mais
nutritivos de acordo com a hora e plano alimentar determinado pelo nutricionista.
Devido a grande popularidade dos dispositivos móveis, existe uma grande demanda para
aplicações específicas para tais dispositivos.
2
A tecnologia escolhida para desenvolvimento deste sistema foi o J2ME (Java 2 Micro
Edition), que segundo SUN (2006):
é a plataforma mais utilizada para dispositivos móveis através do globo. Fornece um
ambiente robusto e flexível para as aplicações que funcionam em uma grande quantidade de
dispositivos, tais como telefones móveis e PDAs. O J2ME inclui um modelo robusto de
segurança, uma grande quantidade de protocolos de rede internos, e a sustentação extensiva
para as aplicações em rede e fora de rede. As aplicações baseadas em J2ME são escritas
uma vez para uma grande quantidade de dispositivos, contudo exploram potencialidades
nativas de cada dispositivo.
A escolha do J2ME se deu pelo fato de ser uma tecnologia que alcança o maior número de
micro dispositivos disponíveis no mundo é independente de arquitetura e é gratuita para download e
para uso comercial, o que minimiza os custos de desenvolvimento e aumenta a quantidade de
usuários.
Para suportar a grande variedade de Dispositivos Móveis, com relação ao uso do JAVA, a
SUN dividiu os Dispositivos Móveis em duas categorias chamadas de configurações: CDC
(Connected Device Configuration) e CLDC (Connected Limited Device Configuration). A primeira
para dispositivos com maior capacidade, como PDAs (Personal Digital Assistants), e a segunda
para dispositivos com maior restrição de memória e processamento, como os celulares (SUN,
2006).
A configuração é responsável por definir uma plataforma Java para uma ampla variedade de
dispositivos, e também define os recursos da linguagem Java e as bibliotecas básicas suportadas
pela JVM (Java Virtual Machine) para um tipo de configuração particular (MUCHOW, 2004).
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
O objetivo deste projeto foi desenvolver um sistema para dispositivo móvel que fosse
integrado ao sistema “Programação alimentar utilizando RBC” e que permitisse agendamento dos
horários das refeições e alimentos que o usuário deve ingerir.
1.1.2 Solução Proposta
A solução proposta, ilustrada na Figura 1, consiste de um aplicativo J2ME rodando em um
celular que permita ao usuário acessar o sistema para controle de planos alimentares através de uma
3
rede wireless. Um outro aplicativo, rodando em um computador PC (Aplicativo PC), possui Web
Services que são responsáveis por integrar o sistema proposto ao sistema de Programação
Alimentar utilizando RBC, os Web Services são utilizados para receber esses registros, processá-los
e retornar os dados a aplicação, que serão apresentados ao usuário. Os dois equipamentos (celular e
PC Servidor) se comunicam utilizando uma rede wireless.
Figura 1. Arquitetura da aplicação
A justificativa da utilização do celular é a grande popularização destes dispositivos e o seu
crescimento no poder de processamento. Dado este grande crescimento, surge à oportunidade de
desenvolvimento especifico para tais dispositivos e a possibilidade de agregar funcionalidades aos
mesmos. Devido a grande popularidade dos celulares, existe uma grande demanda para aplicações
especificas para estes dispositivos.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo deste projeto é desenvolver um sistema para dispositivo móvel que seja integrado
ao sistema “Programação alimentar utilizando RBC” e que permita agendamento dos horários e
alimentos que o usuário deve ingerir.
1.2.2 Objetivos Específicos
Os objetivos específicos deste projeto de pesquisa são:

Estudar o funcionamento do sistema “Programação alimentar utilizando RBC”

Pesquisar e analisar soluções similares;

Determinar os requisitos exigidos pelo sistema;

Estudar tecnologias para dispositivos a ser utilizada;
4

Realizar a Análise do Sistema “Programação alimentar utilizando RBC”;

Realizar a modelagem conceitual do sistema;

Implementar o sistema e

Testar e validar a implementação do sistema.
1.3 Metodologia
Para a Fundamentação Teórica as pesquisas foram realizadas para entender os conceitos e
metodologias envolvidas no processo de desenvolvimento para dispositivos móveis bem como
sobre avaliação nutricional, distúrbios alimentares e prescrição alimentar, a evolução da
computação móvel e dos dispositivos móveis. Buscou-se também entender outras tecnologias de
desenvolvimento para dispositivos móveis que não serão aplicadas neste trabalho. Essas pesquisas
foram realizadas através de livros, artigos científicos, sites de instituições de pesquisa, além de
trabalhos acadêmicos, entrevista com os profissionais da área de tecnologia e saúde.
O desenvolvimento do Projeto iniciou com uma análise detalhada do Sistema Programação
Alimentar utilizando RBC e dos pontos onde poderia haver uma integração além de todos os
requisitos que o sistema deveria atender. Alguns dos requisitos foram identificados a partir de
entrevistas com o nutricionista.
A modelagem do sistema buscou apresentar de uma maneira geral, a estrutura do sistema a
partir de diagramas de caso de uso, classes e implantação, todos suportados pela UML (Unified
Modeling Language).
Também será apresentado o modelo ER (Entidade Relacionamento), da base de dados,
identificando as tabelas e atributos necessários ao desenvolvimento do projeto.
A implementação foi feita baseada nos requisitos e modelos já definidos alem de utilizar as
ferramentas que também já foram definidas. São elas: J2ME, para a construção do aplicativo para
celular, Web Services, para comunicação processamento da lógica de negócio, além do Eclipse para
como ferramenta de desenvolvimento Java. A validação e os testes foram efetuados no emulador
pelo próprio desenvolvedor, e com pessoas que auxiliaram na validação do sistema.
Os tópicos foram apresentados, de maneira a deixar bem claro e objetivo, as etapas do
desenvolvimento do projeto.
5
1.4 Estrutura do Trabalho
Este trabalho está estruturado em quatro capítulos. O Capítulo 1, Introdução, apresentou
uma descrição geral do trabalho. No Capítulo 2, Fundamentação Teórica é apresentada uma revisão
bibliográfica sobre os principais conceitos e técnicas sobre computação móvel, dispositivos móveis
e tecnologia envolvida neste trabalho, são apresentadas neste capítulo questões sobre formação de
planos alimentares bem como sua importância. O Capítulo 3 apresenta o projeto do sistema
desenvolvido, incluindo sua especificação e uma modelagem em UML. Esse capítulo também
discute como foi implementado o sistema proposto, apresentando a metodologia utilizada no
desenvolvimento. No Capítulo 4, apresentam-se as considerações finais, onde são abordados,
sucintamente, os assuntos apresentados, problemas encontrados, entre outros. Este trabalho inclui
um apêndice, que complementa as informações apresentadas no trabalho, e os materiais em anexo.
6
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo serão abordados os principais conceitos necessários ao desenvolvimento de
aplicações para celulares, tais como computação móvel, conceito de dispositivos móveis,
tecnologias de desenvolvimento, tecnologias de comunicação (rede móvel/rede física) e questões
sobre a nutrição. Além destas questões, foram feitas pesquisas e comparações entre soluções
semelhantes.
Este capítulo tem como objetivo, apresentar uma descrição sobre o que são e como
funcionam os dispositivos móveis e como é feita a comunicação dos dispositivos móveis,
apresentando também a questão da computação móvel, sua evolução, utilização e crescimento no
cenário mundial.
2.1 Computação móvel
A computação móvel vem surgindo como uma nova proposta de paradigma computacional
advinda da tecnologia de rede sem fio e dos sistemas distribuídos. Nela o usuário, portando
dispositivos móveis tem acesso a uma infra-estrutura compartilhada independente da sua
localização física. Isto fornece uma comunicação flexível entre as pessoas e um acesso contínuo aos
serviços de rede. É esperado que a computação móvel revolucione o modo como os computadores
são usados hoje (ISAN, 2004).
De acordo com Dias (2003), a computação móvel surge com o objetivo de permitir que
usuários tenham acesso à rede independente de sua localização, isto se deve, ao fato de milhões de
usuários passarem muito tempo em trânsito e a necessidade de utilização de cabos para conexão
acaba tornando-se um empecilho para o usuário se conectar a rede.
Segundo Duarte (2005), os usuários dos dispositivos móveis, podem fazer uso dos recursos
da computação móvel de onde quer que estejam e mesmo assim usufruir os mesmos recursos dos
usuários das redes físicas.
De acordo com Dornan (2001), a característica da computação móvel é a possibilidade de
comunicação entre componentes físicos e móveis, como um computador pessoal e um celular.
Ainda segundo Duarte (2005), a rede de telefonia móvel, tem um grande potencial de
exploração seja para operadoras como para empresas de desenvolvimento de software, oferecendo
aplicações voltadas para dispositivos móveis.
“O sistema telefônico tradicional (ainda que ele algum dia chegue a vários gibabits entre
uma extremidade e outra da fibra) não será capaz de satisfazer a um grupo crescente de usuários: as
pessoas em trânsito.” (TANENBAUM, 2003, p 161).
Nos últimos anos, houve um grande crescimento no desenvolvimento de tecnologias para
a computação móvel. A computação móvel, surge como uma forte tendência no mundo moderno.
A questão principal na computação móvel é a mobilidade que introduz restrições
inexistentes na computação tradicional formada por computadores estáticos. Sendo assim, o
objetivo principal da computação móvel é prover para os usuários um ambiente com um conjunto
de serviços similares aos existentes num sistema distribuído de computadores estáticos que permita
a mobilidade (MATEUS e LOUREIRO, 1998).
O mundo móvel tem-se tornado cada vez mais móvel, com a tecnologia wireless a
mobilidade já fornecida pelos dispositivos móveis tem crescido ainda mais, disponibilizando
serviços, informações ao usuário onde quer que ele esteja (PEKUS, 2002).
2.2 Dispositivos Móveis
A computação móvel é caracterizada por um dispositivo móvel, com capacidade de
processamento, em um ambiente sem fio. Exemplos de dispositivos móveis são: PDAs, telefones
celulares e smartcards.
Segundo Mateus e Loureiro (1998), independente do tipo de dispositivo móvel, a maior
parte desses equipamentos deve ter capacidade de se comunicar com a parte fixa da rede e
possivelmente com outros computadores móveis. Fazendo uma análise dos computadores atuais,
estes ficam residentes em um lugar fixo, ou seja, não tem esta característica de mobilidade.
Segundo Lima (2005), um dispositivo móvel é um dispositivo portátil que pode carregar
consigo mesmo sua fonte de energia.
Devido à definição de computação móvel, um dispositivo para este fim deve ter a
capacidade de realizar processamento, trocar informações via rede e ser capaz de ser transportado
8
facilmente por seu usuário. Para isso, é importante que o dispositivo computacional tenha tamanho
reduzido e não necessite de cabos para conectá-lo à rede de dados ou fonte de energia elétrica.
Segundo Figueiredo e Nakamura (2003), os dispositivos móveis devem possuir a
característica de serem menores que as estações de trabalho, que possam caber na palma da mão
outra característica é que os mesmos devem possuir bateria para evitar cabos para conexão com a
energia elétrica e também possuírem a capacidade de conexão com os dados através de tecnologias
de rede sem fio. Dispositivos com tais características são: Celulares, Palmtops, PDAs.
Segundo Figueiredo (2003), os dispositivos móveis, possuem as seguintes características, a
CPU tem um menor poder de processamento. A memória tem menor capacidade. A fonte de
energia, em geral baterias ou pilhas, faz com que o uso destes dispositivos seja restrito. A tela é
muito menor. Os mecanismos de entrada de dados são diferentes. A conexão de rede tem uma
largura de banda reduzida, latência e taxa de erros maiores quando comparados com redes cabeadas.
Além disso, as desconexões podem ser freqüentes.
Segundo Figueiredo e Nakamura (2003), laptops podem ser utilizados como dispositivos
móveis porém não é a melhor opção por necessitar de um apoio para utilização do mesmo e por
possuírem baterias grandes que em geral duram pouco tempo.
A evolução dos dispositivos móveis permitem serviços de conexão e comunicação em
qualquer lugar e a qualquer hora, através de um sistema embarcado. Segundo dados da Agência
Nacional de Telecomunicações (ANATEL, 2006), o número de celulares no Brasil é de mais 93
milhões e a utilização dos aparelhos celulares e dispositivos móveis, tem crescido de forma
vertiginosa no Brasil e no Mundo. Com base nestes números, dá para ter uma idéia do mercado
potencial que pode ser explorado.
Nos últimos anos, os aparelhos celulares evoluíram bastante, a ponto de suportarem a
execução de softwares funcionais e tem notado que muitas vezes este recurso é sub-utilizado, por
falta de softwares desenvolvidos para tais dispositivos.
Segundo Bernardino (2006), os fatores para o aumento da utilização dos celulares são
miniaturização dos dispositivos eletrônicos junto ao aumento do poder de processamento destes
dispositivos aliado à necessidade do ser humano permanecer informado a qualquer hora e em
qualquer lugar. Ainda segundo Bernardino (2006), estima-se hoje que existam mais de um bilhão de
telefones celulares no mundo e esse número cresce a cada dia.
9
De acordo com Teleco (2006), o Brasil passou de 7º para 6º em número de celulares no ano
de 2004, conforme apresentado na Figura 2 e em 2006 o Brasil já possui mais de 95 milhões de
celulares conforme apresentado na Tabela 1.
Figura 2. Número de celulares no Brasil
Fonte: Teleco (2006)
Tabela 1. Número de celulares no Brasil
Mês/Ano
Celulares
Crescimento mês
Set/05
79.997.230
1.049.898
1,3%
Dez/05
86.210.336
3.858.692
4,7%
Ago/06
94.904.998
965.906
1,0%
Set/06
95.870.904
770.895
0,80%
Fonte: Teleco (2006).
Os celulares passaram por uma grande revolução, hoje existem no mercado, celulares
capazes de tirar e armazenar fotos, gravar vídeos e conectar-se a internet. A Tabela 2 apresenta um
quadro que exemplifica a evolução dos celulares:
10
Tabela 2. Gerações da Telefonia Celular
Geração
1G
Características Transmissão
de dados
Analógica
(AMPS);
Taxas de
9600 bps.
2G
Transmissão
digital de
dados(TDMA,
CDMA e
GSM);
2,xG
3G
Disponibilização Evolução
de aplicações
CDMA e GSM;
pré-3G.
Taxas de
9600bps a
14400bps;
Taxas de até
2Mbps;
Surgimento de
aplicações
WAP.
Surgimento de
aplicações
multimídia.
4G
Elevação das
taxas de
transmissão
de dados;
Tecnologias
e aplicações
ainda em
discussão.
Fonte: Figueiredo e Nakamura (2003).
Segundo Lima (2005), as gerações dos celulares foram divididas em 4 categorias onde:

1º Geração – Surgiram em meados dos anos 1970 e 1980 e permitiam apenas comunicação
por voz;

2º Geração – Meados dos anos 1990 surgimento dos primeiros celulares digitais,
possibilidade de transmissão de dados e voz;

2,x Geração – Surgimento de tecnologias para transmissão de pacotes de dados tais como,
GPRS (General Packet Radio Service) e CDMA. Surgiram os serviços diferenciados como
possibilidade de acesso a WEB;

3º Geração – Surgiu no Japão em 2001. Serviço que oferece qualidade na transferência de
voz e suporte a diversos serviços multimídia, como transmissão de vídeo, imagens, músicas
e jogos. Além disso, possui uma grande capacidade para transferência de dados e

4º Geração – Em fase de conclusão, permitirá uma grande elevação nas taxas de transmissão
de dados e voz.
2.3 Tecnologias de Desenvolvimento
Esta seção tem como objetivo apresentar as principais tecnologias atuais de
desenvolvimento para dispositivos móveis. Serão apresentadas as principais características bem
como limitações de cada tecnologia.
11
Serão abordadas também as tecnologias necessárias a implementação deste projeto como
J2ME e Web Services.
2.3.1 .NET
A plataforma .NET pode ser definida basicamente como um modelo de desenvolvimento,
criado pela Microsoft, que visa a implementação de software independente de linguagem,
plataforma e dispositivo. Um dos principais objetivos desse modelo é permitir a integração entre
aplicações através da troca de informações pela internet (BURÉGIO, 2003, p. 9).
O ASP.NET mobile controls, anteriormente conhecido como Microsoft Mobile Internet
Toolkit (MMIT) estende o poder do Framework .NET e do Visual Studio para construção de
aplicações para dispositivos móveis (MICROSOFT, 2006).
A Microsoft disponibiliza o Microsoft Móbile Internet Toolkit (MMIT) que é um SDK
especifico para desenvolvimento de aplicações para dispositivos móveis.
O desenvolvimento pode
ser realizado na ferramenta Visual Studio dotNet ou C#, sendo possível aproveitar o conhecimento
que se tem sobre aplicações ASP.NET e estruturas de linguagens, com restrições apenas às classes
utilizadas para esse tipo de aplicações, um pouco mais limitadas (HADDAD, 2005).
2.3.2 BREW
O BREW (Binary Runtime Environment for Wireless) é uma plataforma aberta
desenvolvida pela empresa Qualcomm para criação e distribuição de aplicações para telefones
celulares.
Segundo Qualcomm (2006), o Brew foi projetado para permitir o desenvolvimento de
aplicações a partir da linguagem que o desenvolvedor escolher para a codificação. Oferece suporte
nativo à linguagem C/C++, mas aceita a integração de browsers e aplicações em outras linguagens
como Java e linguagens de marcação como XML (Extensible Markup Language).
O BREW inclui um pacote de desenvolvimento denomidado BREW SDK® que segundo
Qualcomm (2006),
ajuda o desenvolvedor a começar a trabalhar com o BREW rapidamente, fornecendo
ferramentas de desenvolvimento e depuração gerais, aplicativos de exemplo com seu
código-fonte, materiais de referência e manuais do usuário, bem como um emulador de
12
telefones, que permite que o desenvolvedor execute aplicativos em seu próprio ambiente de
desenvolvimento, antes de começar a testá-los nos dispositivos de destino.
Ainda segundo Qualcomm (2006), o pacote de desenvolvimento da BREW possibilita ao
desenvolvedor criar aplicativos sem precisar conhecer o software de sistema do chip do fabricante
do dispositivo móvel. O SDK de desenvolvimento da BREW está disponível para download
gratuitamente no site da Qualcomm.
2.3.3 SuperWaba
O SuperWaba é uma plataforma para desenvolvimento de aplicações para PDA
e
Smartphones. Possui uma máquina virtual que possibilita a portabilidade entre aplicações e
dispositivos (SUPERWABA, 2006).
O SuperWaba foi criado no início de 2000 por Guilherme Campos Hazan (guich) e é
derivado de um outro projeto de software livre chamado Waba (da empresa WabaSoft).
A plataforma SuperWaba é open-source ou seja, permite acesso ao código fonte e
distribuição gratuita dos softwares incluídos no kit de desenvolvimento SuperWaba (SWSDK). O
SWSDK é formado por uma máquina virtual, bibliotecas básicas e de extensão e ferramentas para
compilação, depuração e instalação de aplicativos. Possui também documentação e exemplos sobre
a tecnologia.
2.4 J2ME
Segundo Muchow (2004), o Java, começou com a idéia da SUN de “Write Once, Run
Anywhere” (Escreva uma vez, execute em qualquer lugar). A idéia original era a de escrever uma
linguagem que fosse portável para qualquer plataforma que possuísse uma Máquina Virtual Java
(JVM).
A SUN possui três plataformas para desenvolvimento, J2ME, J2SE E J2EE. A tecnologia da
SUN voltada para dispositivos com pouca capacidade de processamento é o J2ME. O J2ME é
formado por configurações e perfis, que serão abordados a seguir.
13
Personal Profile
RMI
Profile
TV
Profile
CDC
MIDP
CLDC
Perfil
Configuração
Linguagem de programação JAVA
KVM
Máquina Virtual Java
Foco do TCC
Figura 3. Camadas de Software do J2ME
Fonte: Adaptado de Muchow (2004).
2.4.1 Configuração
A SUN introduziu o conceito de Configurações, para poder suportar a grande quantidade e
variedade de dispositivos móveis.
Uma configuração define o menor denominador comum dos recursos da plataforma Java
suportados por todos os dispositivos com características similares que pertencem a uma
determinada categoria, tanto pela própria linguagem Java como pela máquina virtual, assim
como suas bibliotecas de classes e APIs (SUN, 2006).
O que limita a configuração de uma aplicação é basicamente a memória, vídeo,
conectividade de rede e processamento.
Segundo Muchow (2004), as configurações podem ser divididas em duas categorias distintas
como segue:

Configuração de Dispositivo Conectado Limitado (CLDC): Ambiente de execução com
um conjunto de APIs especificas para dispositivos restritos que possuem baixo poder de
processamento, fonte de energia limitada e display reduzido, caso da maioria dos
celulares encontrados no Brasil atualmente; e
14

Configuração de Dispositivo Conectado (CDC): conjunto de tecnologias destinadas à
utilização em dispositivos mais potentes que aqueles contemplados na configuração
CLDC. Possibilidade de construção de interfaces gráficas mais poderosas a aplicações
com maior poder de processamento quando comparadas com as feitas em CLDC.
2.4.2 Perfis
Mesmo os dispositivos sendo classificados como uma ou outra categoria de configuração
eles podem possuir características diferentes. Tendo em vista esta questão, a SUN incorporou o
conceito de perfil (profile).
Segundo Muchow (2004), ”um perfil é uma extensão de uma configuração. Ele fornece as
bibliotecas para o desenvolvedor escrever aplicativos para um tipo em particular de dispositivo”.
O perfil MIDP (Mobile Information Device Profile) é o perfil responsável por definir as
APIs de entrada, saída, interfaces com o usuário, interligação entre redes, dentre outros, isto sempre
levando em consideração as limitações de cada dispositivo, tais como tamanho da tela e memória
(MUCHOW, 2004).
2.4.2.1
MIDP
Levando em consideração os recursos do dispositivo móvel disponível para este trabalho, foi
escolhido o perfil MIDP. Segundo Muchow (2004), os recursos de hardware são de extrema
importância para a escolha do perfil. Para suportar os requisitos mínimos do MIDP os dispositivos
devem possuir:

Tela de pelo menos 96x54 pixels;

Deve possuir um tipo de entrada de dispositivo como teclado QWERTY1;

128 Kilobytes de memória ROM;

32 Kilobytes de memória RAM e

Conectividade de rede sem fio;
1
QWERTY é o layout de teclados atualmente mais utilizado em computadores e máquinas de escrever. O nome vem
das primeiras 6 letras "QWERTY".
15
O MIDP encontra-se hoje em sua segunda versão com recursos de HTTPS (HiperText
Transfer Protocol Secure), Datagramas, analisador XML e extensões para linguagem de baixo nível
(MUCHOW, 2004).
2.4.3 JVM
Toda aplicação Java, necessita da JVM (Java Virtual Machine) para ser executada. Segundo
Muchow (2004), “a JVM é um programa que carrega e executa os aplicativos Java, convertendo os
bytecodes em código executável de máquina”.
A JVM é responsável pelo gerenciamento dos aplicativos, à medida que são executados,
além disso, de acordo com Muchow (2004), a JVM é responsável pela segurança, gerenciamento da
memória e execução das linhas de comando.
A JVM para dispositivos móveis é conhecida como KVM (Máquina Virtual K), que foi
projetada pela SUN, para execução de aplicativos para pequenos dispositivos. Esta máquina virtual
é responsável por atender os requisitos exigidos pelo CLDC. De acordo com Muchow (2004), “a
KVM não é a maquina virtual tradicional do Java, mas sim, a implementação da SUN de uma JVM,
que se enquadra nas diretrizes da CLDC”.
2.4.4 Vantagens do J2ME
Segundo Muchow (2004), o J2ME é destinado diretamente aos dispositivos com recursos
limitados e pouco poder de processamento. Além disso, o J2ME é a tecnologia que alcança o maior
número de micro dispositivo disponíveis no mundo é independente de arquitetura e é gratuita para
download e para uso comercial, o que minimiza os custos de desenvolvimento e aumenta a
quantidade de usuários.
De acordo com Muchow (2004), estima-se que a quantidade de desenvolvedores Java
(J2ME) seja mais de dois milhões de pessoas no mundo.
2.5 Ambiente de desenvolvimento
Para o desenvolvimento de aplicações utilizando o J2ME, torna-se necessária a utilização de
alguns softwares. Todos estes softwares são gratuitos e encontram-se disponíveis para download na
16
internet. Esta seção apresentará os softwares e ferramentas necessárias para a implementação deste
trabalho.
2.5.1 Java 2 Standard Edition
O J2SE (Java 2 Standard Edition) ou Java SE é a ferramenta necessária para o
desenvolvimento, compilação de aplicações em Java. Ela é composta por um ambiente com
máquina virtual, compilador java e APIs do java.
2.5.2 Wireless Toolkit
O Java Wireless Toolkit (WTK) é o kit de desenvolvimento para dispositivos móvel
desenvolvimento pela SUN e é responsável por emular um dispositivo móvel, no padrão MIDP. O
WTK encontra-se atualmente, na versão 2.0, compilável com a especificação MIDP 2.0.
É importantes salientar, que o WTK não provê um ambiente de desenvolvimento completo,
e sim um compilador para as aplicações móveis e emuladores de alguns dispositivos para testar os
sistemas criados, por isso torna-se necessária a utilização de uma IDE para desenvolvimento. A
Figura 4 apresenta a tela do emulador WTK.
Figura 4. Tela do Emulador do WTK
17
2.5.3 Eclipse
O Eclipse foi a ferramenta utilizada para o desenvolvimento do sistema. Esta ferramenta foi
escolhida por ser de fácil utilização bem como de possibilitar uma fácil integração com o WTK.
O Eclipse é uma ferramenta de desenvolvimento gratuita e licença GNU (Licença Pública
Geral), isto garante que os softwares possam ser de livre distribuição. Além disto, é uma ferramenta
gratuita utilizada por muitos desenvolvedores JAVA.
2.6 Web Services
A utilização do Web Services neste projeto é de vital importância, por se tratar de uma
integração entre dois sistemas desenvolvidos por pessoas diferentes e em tecnologias diferentes. O
sistema proposto, será desenvolvido em J2ME e o sistema para Programação Alimentar utilizando
RBC em PHP.
Os Web Services apresentam uma estrutura arquitetural que permite a comunicação entre
aplicações. As aplicações podem ser desenvolvidas em qualquer plataforma ou tecnologia.
O Web Service é um componente de software que interage com o outro componente de
software através de protocolos de rede.A comunicação ocorre de forma invisível para o cliente, a
transferência das informações é feita através de arquivos XML (CHAPPELL E JEWELL, 2002).
Segundo Chappel e Jewell (2002), Web Service é um componente que implementa uma
lógica de negócio, localizado em algum lugar na Internet, podendo ser acessado através de algum
protocolo padrão. Este serviço pode ser simples, como fazer um logon em um site, ou tão complexo
quanto realizar uma negociação empresarial.
Uma das características do Web Service é que as aplicações o acessam através de protocolos
padrão, como HTTP (HiperText Transfer Protocol) e SOAP (Simple Object Access Protocol) e
transferem os dados no formato XML.
Segundo Chappell e Jewell (2002), baseado nos conceitos de Web Services, pode-se citar
algumas características do seu comportamento como segue:

Interoperabilidade entre plataformas: Os web services não dependem de plataformas;
18

Fraco acoplamento: um cliente não está vinculado diretamente ao serviço. Alterações em
um dos dois serviços (cliente/serviço) não necessariamente obrigam alterações no outro
serviço; e

Habilidade de atender requisições de forma síncrona e assíncrona;
2.6.1 Arquitetura dos Web Services
De acordo com Chappell e Jewell (2002), a arquitetura dos Web Services definem padrões
para interoperabilidade entre diferentes aplicações rodando em diferentes plataformas, a arquitetura
não define como os Web Services devem ser implementados, mas sim como os diversos
componentes do Web Services devem se comunicar.
A relação entre estes componentes pode ser observada na Figura 5.
Figura 5. Interação dos Componentes do Web Service
Fonte: Chappell e Jewell (2002).
O SOAP é o protocolo responsável por troca de mensagens e tem como finalidade a
intercomunicação entre sistemas heterogêneos através da WEB, o HTTP é o protocolo responsável
pelo transporte (CHAPPELL E JEWELL, 2002).
Os Web Services tem que se registrar num repositório central, onde os softwares clientes
necessitaram pesquisa-los para poderem usar as suas funções. Uma vez localizado, o Software
cliente receberá uma referência para o serviço encontrado, podendo usufruir os serviços apenas
19
executando os vários métodos implementados com a ajuda das interfaces públicas (CHAPPELL E
JEWELL, 2002).
Segundo Chappell e Jewell (2002), o WSDL (Web Service Description Language) é a
linguagem que prove informações especificas para que os clientes possam utilizar os serviços
implementados no Web Service. Ainda segundo Chappel e Jewell (2002), o UDDI (Universal
Description, Discovery and Integration) é responsável por prover o registro do Web Service na
Web. Um serviço de registro UDDI é um Web Service que gerencia informação sobre provedores,
implementações e metadados de serviços.
2.6.2 Segurança dos Web Services
Ao se utilizar Web Services com aplicações móveis, deve-se salientar que esses serviços
estarão disponíveis no servidor, e não no dispositivo móvel devido a suas limitações. Desta forma,
são necessárias algumas medidas que garantam uma segurança fim-a-fim, sendo que os Web
Services tem como característica principal a disponibilização de rotinas para acesso remoto.
O WTLS (Wireless Transport Layer Security), é um protocolo semelhante ao protocolo de
segurança de transporte da internet, ele é responsável por fornecer autenticação, integridade de
dados e privacidade de serviços (MILLER, 2001).
Uma transmissão de um site para um dispositivo móvel deve, primeiramente, atravessar um
gateway que converte a encriptação de SSL (Secure Sockets Layer – protocolo criptografado) para
WTLS, neste processo de conversão, a mensagem é codificada e decodificada no destino.
2.7 Tecnologias para Comunicação sem fio
Ao passo que se possui os dispositivos móveis, torna-se necessário a utilização de alguma
tecnologia que viabilize a comunicação entre o dispositivo móvel e a rede física, lembrando que
esta tecnologia deve permitir tal comunicação com o dispositivo móvel por meio de uma rede sem
fio.
Para a comunicação na computação móvel, é necessária uma infra-estrutura que forneça aos
dispositivos móveis a capacidade de troca de informações para uma rede fixa. Esta infra-estrutura
ocorre por meio de tecnologias que possibilitem a comunicação e/ou a troca de informações e
20
podem ser divididas em infra-estrutura interna ou externa, dependendo da área de cobertura da rede
(FIQUEIREDO e NAKAMURA, 2003).
De acordo com Lima (2005), a comunicação entre dispositivos móveis, pode se dar através
de vários meios de comunicação que podem ser via airtime como WI-FI, BlueTooth, conexão
HTTP, SyncML (Synchronization Markup Language) e infra-vermelho ou como não airtime como
conexão via cabos, cabo USB (Universal Serial Bus) por exemplo.
Esta seção tem como objetivo apresentar as principais tecnologias envolvidas na
comunicação entre dispositivos móveis e a rede física, por meio de uma comunicação sem fio. A
seguir são apresentadas as características de tais tecnologias.
2.7.1 WAP
O WAP (Wireless Application Protocol) é uma especificação que fornece métodos para
acesso a internet por meio de um dispositivo móvel.
Segundo Agustini (2000), o WAP é uma especificação aberta e global, que visa permitir que
usuários de dispositivos móveis, sem fio, acessem facilmente informações e serviços de forma
instantânea. A comunicação pode ser feita através de ondas de rádio via satélite ou antenas.
O WAP pode ser comumente utilizado em palmtops, handheds, notebooks e equipamentos
com modens sem fio, entretanto o celular é o dispositivo mais utilizado. O protocolo WAP foi
criado especificamente para o uso com dispositivos sem fio, por este motivo, tornou-se mais
eficiente do que outros protocolos utilizados para este fim.
O WAP surgiu a partir de uma proposta feita pela empresa Ominipoint em 1997 que queria
um serviço de WEB Móvel. A empresa abriu um processo de concorrência à qual as empresas ou
pessoas deveriam apresentar a tecnologia e os serviços a serem aplicados. Quatro empresas
apresentaram suas propostas, dentre elas, três operadoras de telefonia celular. As propostas
apresentadas pelas empresas, embora interessantes comercialmente e tecnologicamente, não foram
aproveitadas por se tratarem de tecnologia proprietária, ou seja, torna obrigatória a utilização de um
software ou equipamento de um único fornecedor. Então a Ominipoint optou pela adoção e criação
de um único padrão, surgindo então a criação do WAP Fórum, formado originalmente pelas quatro
21
empresas. Após um ano, esse fórum foi aberto para novos membros, surgindo então a primeira
versão do WAP (AGUSTINI, 2000).
Nesse ínterim, outras soluções surgiram, porém o WAP se destacou por ser não apenas uma
nova linguagem de marcação, mas todo um conjunto de protocolos utilizados na formação de uma
WEB sem fio. O protocolo WAP é basicamente uma pilha de protocolos de comunicação que tem
como meta unir um servidor de aplicação a um dispositivo sem fio.
Conforme apresentado na Figura 6, observa-se a arquitetura do protocolo WAP, que é
formada por diversos protocolos divididos nas camadas de rede. A seguir são apresentados alguns
componentes da pilha do protocolo (DORNAN, 2001).
Figura 6. Pilha de protocolos WAP
Fonte: Dornan (2001).
22
1. WTA: a finalidade do WTA é fornecer meios para criar serviços de telefonia (voz)
usando WAP;
2. WSP: responsável por decodificar e converter do padrão WAP para o padrão HTTP uma
solicitação recebida; e
3. WML: linguagem de marcação projetada para apresentar principalmente as páginas
baseadas em texto.
De acordo com Dias (2003), o processo de funcionamento do protocolo WAP é semelhante
à de uma página WEB. Uma solicitação é enviada de um computador até um servidor Web através
da Internet. O servidor interpreta a solicitação e envia a resposta ao computador que a solicitou,
onde será exibida.
De acordo com Cani (2000), na forma convencional, uma solicitação é enviada de uma
estação de acesso até um servidor de conteúdo através da Internet. O servidor interpreta a
solicitação e envia a resposta à estação que a solicitou, onde a mesma será recebida , conforme
observado na Figura 7.
Figura 7. Acesso a internet na forma convencional
Fonte: Adaptado de Cani (2000).
Ainda segundo Cani (2000), no caso da tecnologia WAP, o dispositivo envia uma
solicitação através da rede sem fio para um gateway wap, o gateway converte a requisição para o
protocolo na internet e envia para o servidor de conteúdo. O servidor de conteúdo processa as
informações envia a resposta para o gateway onde a mensagem é codificada e enviada através da
rede sem fio para o cliente que fez a requisição. Isto pode ser observado na Figura 8.
23
Figura 8. Acesso à internet através da tecnologia WAP
Fonte: Adaptado de Cani (2000).
2.7.2 Infra Vermelho
Tecnologia para comunicação entre dispositivos móveis e fixos, por meio de uma rede sem
fio. Uma das características destes dispositivos é que não permitem que eles estejam afastados por
pouco mais de alguns metros, assim como um controle remoto de televisão. Possui alta taxa de
transmissão de dados que vai de 9600 b/s a 4 Mb/s (LIMA, 2005).
Hoje a tecnologia de comunicação por infra-vermelho é praticamente restrita a redes
pessoais (PANs) e a algumas aplicações especificas para redes sem fio.
2.7.3 SyncML
O SyncML (Synchronization Markup Language) é um protocolo de sincronização de dados
e informação baseada no formato XML (NOKIA, 2006).
O SyncML surgiu em 2000 como iniciativa de empresas como Nokia, Motorola, Ericsson,
Palm, Pison, Lotus e IBM, com o objetivo de se criar um protocolo para sincronização de dados,
utilizando dispositivos móveis.
Segundo Nokia (2006), o SyncML pretende ser uma linguagem comum que permita a
sincronização eficaz e estável de informações pessoais e profissionais, em redes fixas ou móveis.
24
Como dito anteriormente, o objetivo do SyncML é o de criar um protocolo para troca de
informações e que seja universal não estando imposto a limitações de dispositivos proprietários,
linguagens de programação ou aplicativos de sincronização utilizada em cada dispositiva.
Figura 9. Funcionamento do SyncML
Fonte: Nokia (2006b).
A Figura 9, exemplifica basicamente o funcionamento do protocolo SyncML, onde os
dispositivos A e B possuem softwares compatíveis com o SyncML e o transporte dos dados pode
ser feito utilizando WAP, HTTP, cabo ou bluetooth. Ou seja, utiliza praticamente qualquer tipo de
transporte para troca de informações.
2.7.4 BlueTooth
Segundo Alçada (2004), o Bluetooth é um sistema de comunicação sem fios de curta
distância com alcance de aproximadamente 10 metros levando-se em consideração os obstáculos ou
não. O padrão opera na faixa ISM (Industrial, Scientific, and Medical) de 2,4 GHz e tem como
princípio propor uma tecnologia de baixo custo para conectividade sem fio.
De acordo com Gonçalves (2000), o padrão Bluetooth visa facilitar as transmissões em
tempo real de voz e dados, permitindo conectar quaisquer aparelhos eletrônicos, fixos ou móveis,
que estejam de acordo com a tecnologia.
Vantagens do BlueTooth:

Solução viável e de baixo custo;

Cada vez mais dispositivos possuem chips Bluetooth; e

Permite transmissão tanto de voz quanto de dados.
Desvantagens do BlueTooth:
25

Alcance curto, aproximadamente 10 metros e

Possui uma capacidade limitada de dispositivos que podem se conectar.
2.8 Nutrição
Muitas doenças estão diretamente relacionadas com a alimentação e a receita para este
problema é um cardápio bem elaborado e com critério para evitar uma série de problemas com a
saúde. De acordo com a Organização Mundial da Saúde (OMS), “as doenças causadas por uma má
alimentação ocasionam a morte de mais de seis milhões de pessoas anualmente em todo o mundo.
Metade delas pode ser evitada com medidas de prevenção para reduzir o risco de hipertensão,
colesterol alto e obesidade”. Outras doenças como a Osteoporose, hipertensão, Diabetes Melitus e
Obesidade, podem ser evitadas, com alguns cuidados na alimentação (COCOLO, 2006).
Os resultados demonstrados por um estudo feito pela Pesquisa Nacional de Saúde e Nutrição
(PNSN), no que diz respeito à situação econômica, apresentam que o “Brasil revelou que a
prevalência de excesso de peso aumenta de acordo com o poder aquisitivo, especialmente entre os
homens” (OLIVEIRA 2002).
Para se manter bons hábitos alimentares é necessário saber a quantidade e a qualidade dos
alimentos que se deve consumir. Sendo assim, somente com mudança de hábitos alimentares e
reformulação/adequação da dieta, pode-se alcançar uma alimentação com qualidade e mais saúde.
No entanto, corrigir os hábitos alimentares, apesar de ser uma tarefa essencial, não é fácil,
principalmente quando não há um controle e/ou uma forma de se controlar.
Segundo Cervato (2004), as ações em educação nutricional devem se basear em teorias da
educação e de outras ciências humanas, para que possam, então, contribuir à promoção da saúde.
Esta seção tem como objetivo, apresentar questões sobre avaliação nutricional, transtornos
alimentares e a prescrição alimentar. Esta seção visa apresentar a importância da avaliação
nutricional e o como esta avaliação deve ser feito junto ao acompanhamento de um profissional
especializado nesta área (nutricionista).
26
2.8.1 Avaliação Nutricional
Cada paciente possui uma necessidade específica de alimentação, para isto, é importante o
acompanhamento do nutricionista. A influência da nutrição na saúde do individuo é medida através
da avaliação nutricional ou avaliação do estado nutricional.
Para garantir a qualidade da atenção nutricional o primeiro passo consiste na avaliação das
necessidades especiais de cada paciente (MITCHELL e ANDERSON, 1988).
Para Krause, Mahan e Escott-Stump (2002), a avaliação nutricional serve para medir a
influência da nutrição na saúde do individuo.
Ainda segundo Krause, Mahan e Escott-Stump (2002), os objetivos da avaliação nutricionais
são:
1. Identificar um grupo de pacientes necessitados de acompanhamento nutricional;
2. Estabelecer valores básicos para avaliar a eficácia de regimes nutricionais; e
3. Identificar a probabilidade de riscos de saúde devido a fatores nutricionais.
Segundo Dutra-de-Oliveira e Marchini (1998), a seleção dos alimentos deve se basear na
quantidade necessária de nutrientes para suprir o organismo de cada paciente e não apenas nos tipos
de alimentos que devem ser consumidos.
Segundo Correia (1996), a ingestão inadequada de nutrientes leva a uma diminuição do peso
corporal, como um excesso de ingestão vai resultar num aumento de peso corporal.
Além disso, o importante é saber de quais alimentos retirar os nutrientes necessários ou não
ao organismo de cada paciente.
Para determinar a necessidade de cada paciente, é preciso fazer uma Avaliação nutricional
do mesmo.
Segundo Mitchell e Anderson (1988), os dados objetivos para uma avaliação nutricional são:

Dados antropometricos: Altura, peso, espessura da dobra cutânea e circunferência
muscular do braço; e
27

Dados bioquímicos: exame do plasma, glóbulos vermelhos e brancos, urina ou tecidos,
como fígado, ossos, cabelos e unhas.
Em relação aos dados antropométricos, são métodos relativamente imprecisos e com
grandes margens de erros, se comparados com os métodos laboratoriais, contudo são mais baratos e
ideais para serem utilizados em serviço de campo pelo nutricionista. Este método se baseia em
vários índices, a fim de determinar a composição corporal do paciente (NOBREGA, 1998).
Segundo Nobrega (1998), alguns desses índices são:

Índice da relação de Peso para Estatura (P/E): É a relação entre o peso real e o peso
ideal, correspondente ao percentil 50 da sua idade/altura, multiplicado por 100;

Índice de Quetelet ou Índice de Massa Corporal: Considerado o método antropométrico
mais simples e preciso, e pode ser calculado pela seguinte formula:
 Peso 
IMC  
2 
 Altura 

Equação 1
Pregas Cutâneas: A utilização das medidas baseadas nas pregas cutâneas é a de
identificar a quantidade de gordura corporal. Esta medida se baseia no fato de que
metade do conteúdo corporal total da gordura fica localizada nos depósitos adiposos
existentes diretamente debaixo da pele; e

Circunferência: Relação entre a circunferência da cintura e do quadril e é um índice que
representa a gordura localizada no nível abdominal.
Além dos dados Antropométricos e bioquímicos do pacientes, existem os dados subjetivos
que são levantados do pacientes como a Anamnese alimentar e dados de ingestão.
Segundo Krause, Mahan e Escott-Stump (2002), os dados de ingestão alimentar do paciente,
podem ser obtidos através de:

Questionário 24h: Método mais popular e fácil de obter informações sobre a ingestão
alimentar de uma pessoa. Este método consiste num questionário ou entrevista com o
nutricionista, que pede ao paciente que relate tudo que ele consumiu nas últimas 24h.
Entretanto este método é muito passível de erro, pois o paciente pode não se lembrar do
que comeu no dia anterior, ou as quantidades não podem ser exatas;
28

Questionário de Freqüência de uso de alimentos: Método utilizado muitas vezes para
suprir as deficiências do questionário 24h. Neste método, o nutricionista coleta
informações de quantas vezes no dia, semana ou mês o paciente consumiu determinado
alimento. Este questionário pode determinar um padrão real da alimentação do
indivíduo;

Anamnese Alimentar: É um método mais completo que o questionário 24h e o de
freqüência. A anamnese alimentar requer um certo tempo por parte do nutricionista, e
um outro problema, tendo em vista que a alimentação é algo particular do paciente, é a
de que o paciente não fale a verdade ou não queira falar. Para compensar estes
problemas, a anamnese alimentar pode ser colocada em um questionário objetivo, que
pode ser preenchido pelo paciente, visando assim a obtenção de um padrão mais
próximo da alimentação do paciente; e do

Diário ou Registro Alimentar: Este método consome mais tempo do paciente e
nutricionista. Consiste basicamente na responsabilidade do paciente de descrever tudo
que come ou bebe durante certo período de tempo.
2.8.2 Transtorno Alimentar
Segundo Oliva e Fagundes (2002), o principal responsável pelos transtornos alimentares é a
insuficiente ingestão de nutrientes, muitas vezes associada a outras alterações do comportamento
alimentar.
Os transtornos alimentares ou nutricionais são doenças psiquiátricas ligadas diretamente à
imagem que a pessoa faz de si mesma e caracteriza-se por alterações no comportamento alimentar.
Por isso, torna-se importante o profissional de saúde estar atento, a fim de identificar o problema e a
realizar uma avaliação nutricional adequada a cada paciente. Existem vários diagnósticos possíveis
para doenças de transtornos alimentares, tais como: Bulimia Nervosa, Anorexia Nervosa e
Obesidade, dentre outros.
2.8.2.1
Bulimia Nervosa
Segundo Nobrega (1998), a Bulimia Nervosa é uma doença psiquiátrica onde o padrão e
comportamentos alimentares estão profundamente comprometidos.
29
A bulimia nervosa caracteriza-se por episódios recorrentes de compulsão alimentar seguidos
de vômitos auto-induzidos, uso abusivo de laxantes, diuréticos e jejuns prolongados (NOBREGA,
1998).
Segundo Nobrega (1998), alguns critérios diagnósticos para bulimia nervosa são:

Sensação de falta de controle sobre o comportamento alimentar;

Preocupação excessiva, persistente com peso e formato do corpo;

Uma média mínima de dois episódios de compulsão alimentar por semana, durante no
mínimo três meses;

Compulsão alimentar e grande consumo de alimento em um curto espaço de tempo; e

A pessoa geralmente pratica vômitos induzidos, utiliza-se de laxantes, ou jejum rigoroso.
2.8.2.2
Anorexia Nervosa
A anorexia nervosa caracteriza-se por ser um distúrbio da alimentação, que primariamente,
afetam adolescentes e adultos do sexo feminino, onde se caracterizam pela recusa do individuo em
manter o peso adequado à sua altura e um distúrbio da percepção da própria imagem, em que a
pessoa considera estar acima do peso, mesmo estando aparentemente abaixo do peso (NOBREGA,
1998).
Segundo Nobrega (1998), alguns critérios diagnósticos para anorexia nervosa são:

Medo intenso de ganhar peso ou de ficar obeso mês

Distúrbio na forma de vivenciar o próprio peso, ou seja, a pessoa acredita estar acima do
mo com peso inferior ao normal;
peso, mesmo quando esta obviamente abaixo do peso;

No sexo feminino, ausência de, pelo menos, 3 ciclos menstruais consecutivos, quando
sua ocorrência é normalmente esperada; e

2.8.2.3
Perda de mais de 15% do peso corporal.
Obesidade
Segundo Nobrega (1998), a obesidade é um distúrbio do metabolismo energético, onde
ocorre o armazenamento excessivo de energia.
30
De acordo com Nobrega (1998), o fator de risco mais importante para a causa da obesidade
é a freqüência entre os familiares, isto relacionado a fatores genéticos, hábitos alimentares e estilo
de vida. Nobrega (1998), também afirma que “o risco de uma criança ser obesa aumenta em função
da obesidade dos pais. É baixo quando nenhum dos pais é obeso, alto quando apenas um é obeso e
muito alto quando ambos são obesos”.
Um importante dado é de que a obesidade atinge principalmente os paises desenvolvidos e
estão atingindo no mundo pessoas de todos os fatores econômicos (NOBREGA, 1998).
Os resultados demonstrados por um estudo feito pela Pesquisa Nacional de Saúde e Nutrição
(PNSN), no que diz respeito à situação econômica, apresentam que o “Brasil revelou que a
prevalência de excesso de peso aumenta de acordo com o poder aquisitivo, especialmente entre os
homens” (OLIVEIRA 2002).
Segundo Correia (1996), existem várias doenças associadas à obesidade, dentre elas:

Hipertensão arterial;

Diabetes;

Aumento de gordura no sangue;

Doenças cardiovasculares; e

Osteoartrite;
A prevenção da obesidade deve se dar a partir da infância, evitando que as crianças cresçam
com o peso acima do normal (CZEPIELEWSKI, 2001).
31
2.8.3 Prescrição Alimentar
Segundo Krause, Mahan e Escott-Stump (2002), “a tarefa de planejar refeições nutritivas
está centrada na inclusão de nutrientes essenciais, em quantidades ótimas e com calorias
necessárias”.
Segundo Pessa (1998), para suprir as necessidades de nutrientes que o nosso organismo
precisa para funcionar adequadamente é preciso selecionar os alimentos e as quantidades. Por este
motivo, as recomendações nutricionais foram definidas para orientar as pessoas sadias nas
quantidades que são necessárias dos vários nutrientes.
De acordo com Camargo (1999), após efetuar o diagnóstico do paciente, o nutricionista
elabora uma prescrição alimentar individualizada, compatível com o paciente, seguindo guias de
recomendações nutricionais. Ainda de acordo com Camargo (1999), o Recommended Dietary
Allowances (RDA) é o guia alimentar mais utilizado para a definição das recomendações
nutricionais.
Segundo Camargo (1999), algumas recomendações propostas pelo RDA são:

Não existem alimentos "bons ou maus";

As chaves para uma boa dieta são o balanceamento, a variedade e a moderação;

Deve-se encarar a dieta como um todo e não como alimentos em separado;

A escolha adequada de alimentos deve ser encorajada e

A atividade física regular é um componente essencial para a boa saúde.
2.9 Trabalhos Relacionados
Segundo Larcher (2003), um dos grandes desafios da área de saúde é a integração da parte
médica com a tecnologia da informação, com a construção de sistemas que possam ajudar os
profissionais da saúde na tomada de decisões, tanto no atendimento quanto no momento critico.
Os principais sistemas para auxílio alimentar, são os sistemas baseados em casos (RBC).
Aliado a esta técnica da IA, o uso dos dispositivos móveis para o auxilio a esta atividade tem se
popularizado bastante nos últimos anos, isto pode ser demonstrado com alguns sistemas disponíveis
32
no mercado. O uso da informática na saúde vem crescendo bastante, isto se deve à grande facilidade
que o computador tem trazido no processo e acesso a informações.
Esta seção tem como objetivo elencar os principais sistemas encontrados e que possuem
relevância ao escopo deste projeto. Será feita uma análise comparativa entre as características
desses sistemas com o objetivo de facilitar o entendimento e visando também coletar informações
que serão úteis para utilização como sugestões para o projeto. Foram pesquisados sistemas que
estão em desenvolvimento além de sistemas que já estão em uso comercial no mercado.
2.9.1
Calorie Burner - Diet and Exercise Planner
O Calorie Burner é um software para Pocket PC, destinado a ajudar no controle da
alimentação e nos exercícios diários.
Segundo Handango (2006), este software possui as seguintes características:

Interface intuitiva;

Cálculo automático do metabolismo (Basal Metabolic Rate - BMR);

Cálculo automático do balanço diário e peso equivalente;

Calendário de fácil utilização para controle e duração das atividades físicas; e

Possibilidade de exportação dos dados para formato de arquivo CSV.
Na Figura 10, é possível visualizar duas das principais telas do sistema, a tela de controle
calórico e calendário para exercícios.
33
Figura 10. Tela de controle do Balanço Alimentar e Calendário de atividades físicas
Fonte: Handango (2006).
Este software encontra-se no mercado com o valor de U$24.99 para comercialização.
2.9.2
MyPersonalDiet
O MyPersonalDiet é uma ferramenta que visa facilitar o controle e gerenciamento do peso,
permitindo alcançar o peso ideal, fornecendo para isso meios simples de seguir sua alimentação.
De acordo com Handango (2006b), o MyPersonalDiet consiste basicamente em três telas,
descritas assim:

A tela do dia, que mostra informações relevantes ao dia e permite que o usuário
incorpore informações referentes às refeições e dados do usuário, revise seus objetivos
calóricos diários e ajuste sua dieta;

A tela do mês, que permite ao usuário visualizar os resultados referentes ao seu peso,
indicando se o usuário conseguiu alcançar seu(s) objetivo(s); e

A tela do gráfico, que permite que o usuário visualize dados como peso e o seu
progresso, e dados nutricionais e calóricos sobre os alimentos.
34
Além disso, com o MyPersonalDiet, o usuário pode adicionar seu próprio alimento com
informação nutritiva detalhada, por peso (g/mg) ou pelo valor diário dos por cento (%DV), fazendo
lhe uma pressão para consumir alimentos feitos sob encomenda se o usuário tiver os fatores
nutritivos (encontrados em quase todos os alimentos) (HANDANGO 2006b).
Na Figura 11, é observada uma tela do MyPersonalDiet, onde o usuário pode informar a
quantidade calórica mínima e máxima de cada nutriente que ele possa vir a consumir.
Figura 11. Tela do Sistema MyPersonal Diet
Fonte: Handango (2006b).
2.9.3
PmEB: A Mobile Phone Application for Monitoring Caloric Balance
Aplicação para celular que permite aos usuários monitorar suas calorias como parte no
gerenciamento do peso. O sistema PmEB consiste em uma aplicação do cliente que funciona no
telefone móvel do usuário e uma aplicação server. Foram construídas a aplicação do cliente usando
a edição móvel de Java 2 (J2ME) e a aplicação do Server usando Java no servidor Tomcat. A
aplicação do cliente de J2ME na teoria funciona em todo o telefone móvel que for compatível com
J2ME. Entretanto foram testados somente no Nokia 6620 e no Motorola V300, que eram os únicos
telefones disponíveis para o estudo (LEE at al., 2006). A arquitetura da aplicação pode ser
observada na Figura 12.
35
Figura 12. Funcionamento do Sistema PmEB
Fonte: LEE at al. (2006).
2.9.4
Uso da Tecnologia Móvel no Auxílio à Reeducação Alimentar
Este é um projeto de conclusão de curso desenvolvido na Universidade Federal de Lavras no
ano de 2003 por Garrozi (2003).
Segundo Garrozi (2003) o sistema possui as seguintes características:

Desenvolvido em J2ME;

Permite ao paciente armazenar data e hora de cada alimento consumido;

Permite ao paciente armazenar o alimento e quantidade consumida; e

Permite ao paciente consultar os alimentos mais nutritivos e vantajosos, de acordo com
horários, alimentos já consumidos no dia, semana ou mês.
Outra característica importante do sistema é o controle alimentar em forma de pontos onde
cada paciente tem uma cota de pontos a ser consumida (cada alimento equivale a uma quantidade de
pontos), determinada pelo nutricionista. O sistema permite o controle, agendamento e consulta dos
pontos consumidos pelo paciente (GARROZI, 2003).
36
2.9.5
Análise das ferramentas similares
A utilização dos dispositivos móveis na área de saúde, tem se tornado uma importante
ferramenta no auxilio a obtenção de informações dos pacientes. Com base nas ferramentas descritas
anteriormente, pode-se observar isso.
A seguir, uma breve comparação entre os sistemas encontrados:
Tabela 3. Comparação dos Aplicativos
Projeto
Tecnologia Dispositivo Móvel
Calorie Burner
.NET
Pocket PC
Acompanhamento
do Nutricionista
Não
MyPersonalDiet
.NET
Pocket PC
Não
PmEB
J2ME
Celular
Não
Uso da Tecnologia Móvel no Auxílio à
Reeducação Alimentar
J2ME
Celular
Não
2.10 Integração com o Sistema para Programação Alimentar utilizando RBC
De acordo com Miotto (2006), o Sistema para programação alimentar utilizando RBC
é sistema web que permite a interação do paciente com o nutricionista, através do cadastro
do recordatório da ingestão de alimentos durante o tratamento, a possibilidade do cadastro
de dúvidas referente ao tratamento, consulta a tabela de substituição de alimentos,
respeitando os gostos pessoais do paciente, além de um ambiente para educação alimentar
através de dicas, sugestões e receitas atualizadas pelo nutricionista.
O sistema tem como característica o funcionamento na web, possibilitando assim uma
interação entre paciente e nutricionista, outra característica importante do sistema é a utilização da
técnica de Inteligência Artificial (IA), RBC, sendo utilizado como ferramenta para a partir de
avaliações nutricionais anteriores, prescrever novos planos alimentares para o paciente.
O Sistema para consulta de planos alimentares utilizando dispositivo móvel, é um sistema
que visa interagir diretamente como Sistema para consulta de planos alimentares utilizando RBC,
alimentando o sistema da Web por meio do dispositivo móvel possibilitando assim ao paciente estar
respondendo questões no momento em que elas acontecem, ou que seja mais viável a ele, como o
questionário 24hrs, questionário de freqüência de alimentos e pesos e medidas corporais. Além
disso o usuário poderá agendar refeições, consultar alimentos semelhantes, pois nem sempre o
37
paciente poderá se alimentar com aquilo que foi previamente determinado pelo nutricionista, e
consultar alimentos que ele não deve consumir e porque.
A integração se dará da forma apresentada na Figura 13:
Figura 13. Integração entre os Sistemas
O usuário irá escolher a opção do sistema em que deseja operar o sistema irá pegar as
informações e por meio da internet, enviá-las ao web service, localizado no servidor, a partir daí o
web service irá acessar as classes do sistema Programação alimentar utilizando RBC e retornar a
resposta ao usuário.
O celular utilizado para a fase de implantação e testes foi o Nokia 6230i semelhante ao
encontrado na Figura 14, que é compatível com CLDC e MIDP 2.0, e possui as seguintes
características:

Visor de 208 x 208 pixels;

Memória interna de 32MB;

Memória no MMC de até 512MB;

Compatibilidade com WAP 2.0; e

Possui browser para acesso a internet conectado através do protocolo TCP/IP.
38
Figura 14. Celular Nokia 6230i
39
3 DESENVOLVIMENTO
O protótipo do Sistema para controle de planos alimentares, resultante deste trabalho, é um
software que permite o acompanhamento do paciente pelo nutricionista, fornecendo assim
informações adicionais ao nutricionista, permitindo um maior acompanhamento do paciente. O
sistema visa fornecer informações relevantes ao nutricionista, para que este seja capaz de tomar
decisões e fazer um melhor acompanhamento do paciente.
O Software é composto da seguinte forma:
a) Um módulo que é executado em um dispositivo celular, utilizando J2ME, em que a
comunicação com o banco de dados e a lógica do sistema é feita através de Web Services,
utilizando o protocolo SOAP para transferência de dados e WAP para comunicação com a internet;
b) Componente de negócio implementado em JAVA com Servidor AXIS, onde estarão os
web services, responsáveis por toda a lógica do sistema.
Para modelagem e especificação do sistema, foi utilizada a ferramenta Enterprise Architect,
baseada em UML. Com o Enterprise Architect, foram criados os diagramas de seqüência, de
componente, Caso de Uso, além do diagrama de entidade e relacionamento utilizado no banco de
dados. A ferramenta possibilitou a criação e geração do código em JAVA e o mesmo sincronismo
com os Diagramas.
Neste capítulo serão apresentadas as principais características do sistema, bem como os
requisitos, diagramas, implementação e testes e validações.
3.1 Análise de Requisitos
Segundo Bezerra (2002), é na atividade de levantamento de requisitos que há uma
compreensão do problema aplicado ao desenvolvimento do software, sendo assim, o principal
objetivo do levantamento de requisitos é que os usuários e desenvolvedores tenham a mesma visão
do problema e da solução proposta.
Nesta seção, serão apresentados os requisitos funcionais, não funcionais e regras de negócio
do sistema.
40
3.1.1
Requisitos Funcionais
Com base nas entrevistas com a nutricionista e levando em consideração as informações que
o paciente pode transmitir sem a presença do mesmo, os seguintes requisitos funcionais foram
especificados:

RF01. O sistema deve permitir o agendamento das refeições;

RF02. O sistema deve permitir a consulta de substituições de alimentos;

RF03. O sistema deve permitir o cadastro das medidas do paciente;

RF04. O sistema deve enviar por e-mail o cadastro do paciente e senha de acesso ao
sistema;

RF05. O sistema deve permitir a consulta da prescrição alimentar do paciente;

RF06. O sistema deve permitir o cadastro e a consulta de dúvidas do paciente referente
ao tratamento;

RF07. O sistema deve permitir o cadastro do Questionário de 24h;

RF08. O sistema deve permitir o cadastro do Questionário geral de freqüência de uso
dos alimentos; e

3.1.2
RF09. O sistema deve permitir a consulta dos alimentos evitados pelo paciente.
Requisitos Não Funcionais
Os requisitos não funcionais são restrições sobre como o sistema deve realizar seus
requisitos funcionais. Segundo Bezerra (2002), os requisitos não funcionais declaram as
características de qualidade que o sistema deve possuir.
Os requisitos não funcionais do sistema são:

RNF01: O sistema deve ser executado em um celular;

RNF02: O sistema deve ser implementado utilizando a tecnologia J2ME;

RNF03: O sistema deve ter uma interface de fácil utilização;

RNF04: A troca entre telas não deve demorar mais que 30s;

RNF05: O Banco de dados utilizado deve ser o MySql 4.0 ou superior;
41

RNF06: O web service para integração dos sistemas, deve ser desenvolvido em Java;

RNF07: O sistema deve permitir acesso somente aos pacientes cadastrados no sistema;

RNF08: O celular deve suportar o perfil MIDP 2.0;

RNF09: O celular deve possuir memória para aplicações de no mínimo 16MB; e

RNF10: A comunicação entre celular e rede estática, deve ser implementada sobre o
protocolo WAP.
3.1.3
Regras de negócio

RN01: O sistema deve armazenar as ultimas cinco dúvidas cadastradas pelo paciente;

RN02: O sistema deve armazenar as ultimas cinco respostas a dúvidas recebidas pelo
paciente;

RN03: O sistema deve armazenar somente cinco agendamentos de refeições; e

RN04: Caso o usuário tenha cinco agendamentos cadastrados, ao cadastrar mais um, o
sistema deve excluir o primeiro agendamento cadastrado.
3.2 Modelagem do sistema
Nesta seção, serão apresentados os diagramas de caso de uso, de classe de negócio e de
implantação.
3.2.1
Diagrama de Classes
De acordo com Bezerra (2002), o modelo de classes fornece uma visão dos casos de uso do
sistema e é utilizado para representar um modelo apresentando as classes, tipos, conteúdos e suas
relações. O diagrama de classes é a base para a construção dos diagramas de comunicação,
seqüência e estados.
A Figura 15 apresenta o diagrama de classes de domínio que compõem o sistema, e uma
breve descrição das classes mais importantes do sistema.
As principais classes do Sistema são:
42

Avaliação Nutricional: Cada avaliação nutricional está associada a um questionário
24hrs e a um Questionário de freqüência de alimentos; e

Paciente: A classe paciente está associada ao agendamento, dúvida e alimentos evitados,
permitindo assim as operações do paciente nestas classes.
43
cd 4.1 Diagrama de Classes de Domínio
EA 6.1 Unregistered Trial Version EAAv6.1
Unregistered Trial Version EA 6.1 Questionario24H
Unregistered Trial Version
aliacaoNutricional
MedidaIndice
-
DtAvaliacao: date
1
-
HrAtualDormir: DateT ime
HrDormirAnteontem: DateT ime
HoraHabitual Levantar: DateT ime
HrPrimei raIngestao: DateT ime
DsIngestaoSeguinte: String
DsPrimeiraIngestao: String
DsAposIngestaoSeguinte: String
QtIngestaoSeguinte: int
DsLogalIngSeguinte: String
HrLevantouOntem: DateTime
DsEntrePrimeiraSegunda: String
DsSegundaTerceira: DateT ime
DsEntreTerceiraDormir: DateT ime
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
-
DtMedida: date
VlAl tura: float
VlPeso: float
VlCi ntura: float
VlQuadril: float
VlPregaBicipital: float
VlPregaQuadri l: float
VlPregaSubscapular: float
+
CadastraMedidaIndice() : void
+
ConsultaAval iacao() : void
1
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
1..*
EA 6.1 Unregistered Trial1 Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
+
CadastraQuestionario24H() : void
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
QuestionarioFrequencia
1..*
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA
6.1 Unregistered
Trial Version
- QtFrLeite:
int
1
1 -
TipoLeite: stri ng
QtFreqGordura: stri ng
TipoGordura: String
QtFreCarne: int
QtFreqOvos: int
QtFreqQuei jo: i nt
DsTi poLanche: String
QtFreqFei jao: int
QtFreqCereai s: int
QtFreqLanche: int
QtFreqPao: i nt
QtPao: i nt
QtFreqAcucar: i nt
QtFreqMassa: int
QtFreqAgua: int
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered
Trial Version EA 6.1 Unregistered Trial Version
1
+
CadastraQuestionario() : void
Paciente
Agenda
EA 6.1 Unregistered
Trial Version - EA
6.1 Unregistered Trial Version EA 6.1 Unregistered
Trial Version
Duv ida
NomePessoa: String
-
DtAgenda: Date
DtCadastro: Date
Emiti rLembrete: String
HrAgenda: DateTi me
Observacao: String
0..*
-
IdEstado: String
-
DsPergunta: String
T elefoneResidencial: String
- T ipoPergunta: String
EA 6.1 Unregistered Trial Version -- EA
6.1 Unregistered Trial Version EA
6.1 Unregistered Trial Version
T elefoneCelular: String
- DescPergunta: String
1 -
T elefoneComercial: String
Email: String
Login: String
Senha: Stri ng
1
0..* -
DescResposta: String
IdPessoaResposta: int
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
+
+
+
Incl uirAgenda() : void
AlterarAgenda() : void
ExcluirAgenda() : void
+
+
CadastraDuvida() : void
ConsultaDuvida() : void
BuscaPaciente()
: void
EA 6.1 Unregistered Trial Version + EA
6.1 Unregistered
Trial Version EA 6.1 Unregistered Trial Version
1
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered
Trial Version EA 6.1 Unregistered Trial Version
0..*
Grupo
AlimentoEv itado
EA 6.1 Unregistered Trial Version EA 6.1
Unregistered Trial Version EA 6.1 Unregistered Trial Version
-
DsGrupo: int
-
DsRazao: String
QtT empo: float
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
+
BuscaGrupo() : void
+
BuscaAlimentoEvi tado() : voi d
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
1
0..*
EA 6.1 Unregistered
Trial Version EA 6.1 Unregistered
Trial Version EA 6.1 Unregistered Trial Version
1..*
Produto
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
-
DsProduto: String
QtCalorias: float
EA 6.1
Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
+ BuscaProduto() : void
1
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
Figura 15. Diagrama de Classes do projeto
44
3.2.2
Diagrama de casos de uso
Um caso de uso é a especificação de uma seqüência de interações entre um sistema e
agentes externos (ator) e que descrevem a seqüência de eventos do ator que usa o sistema para
completar um processo (BEZERRA, 2002).
O diagrama de caso de uso deste projeto contém três casos de uso e um ator denominado
Paciente, sendo que cada pacote oferece uma visão de partes da interação do sistema com o usuário.
Os diagramas apresentados na Figura 16 e na Figura 17 representam as principais
funcionalidades do sistema.
ud Cadastro
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
UC02.01 Cadastrar
o agendamento
das refeições
UC02.02 Cadastrar
EA 6.1 Unregistered Trial Version EA 6.1 Unregisteredmedidas
Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
UC02.05 Cadastrar
EA 6.1 Unregistered
Trial Version EA 6.1 Unregistered Trial Version
Questionário geral
de freqüência de
uso dos alimentos
EA 6.1 Unregistered Trial Version EA Paciente
6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
UC02.04 Cadastrar
UC02.03 Cadastrar
EA 6.1 Unregistered Trial
Version
EA 6.1 Unregistereddúv
Trial
questionário
24Hrs
idas Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
Figura 16. Diagrama de Caso de uso do pacote Cadastro.
45
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
ud Consultas
EA 6.1 Unregistered Trial Version EA 6.1
Unregistered Trial Version EA 6.1 Unregistered Trial Version
UC03.02 Consultar
Repostas das
Dúv idas
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
UC03.03 Consultar
tabela de
substituição de
alimentos
UC03.01 Consultar
prescrição
alimentar
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
Paciente
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
UC03.04 Consultar
Alimentos ev itados
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
Figura 17. Diagrama de Caso de uso do pacote Consultas.
3.2.3
Diagrama de Implantação
Segundo Bezerra (2002), o diagrama de implantação (deployment diagram) representa a
topologia física do sistema, ou seja, este diagrama apresenta um mapeamento entre os componentes
de software e hardware utilizado pelo sistema.
Os componentes principais deste diagrama são:

Nó: Representa uma peça física de equipamento na qual o sistema será implantado.

Artefatos: Qualquer pedaço físico de informação usada ou produzida por um sistema.

Especificação de implantação: Especifica um conjunto de propriedades que determina os
parâmetros de execução de um artefato que está instalado em um nó.
O diagrama apresentado na Figura 18 tem como objetivo facilitar a visualização e o
entendimento do processo de integração entre os sistemas.
46
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
dd 3 Diagramas de Implantação
utilizando
RBC
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered TrialProgramação
VersionAlimentar
EA 6.1
Unregistered
Trial Version
Cliente: WebServ ice
Serv idor WEB
Cliente:Celular
EA
6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
Requisita operações
<<SOAP>>
Programação
ice Unregistered Trial Version Alimentar
EA 6.1 Unregistered Trial Version WebServ
EA 6.1
EA 6.1 Unregistered Trial Version
Aplicativ o
J2ME
utilizando RBC
<<HT TP>>
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
Banco de
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version Dados
EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
Figura 18. Diagrama de implantação e de componente da aplicação
3.2.4
Diagrama de Seqüência
O diagrama de seqüência é responsável por demonstrar e atribuir responsabilidade aos
objetos e mostrar a colaboração e interação entre eles.
Os diagramas de seqüência apresentam a interação entre os objetos enfatizando a seqüência
temporal em que as mensagem serão trocadas.
A Figura 19 apresenta o diagrama de seqüência para o caso de uso Cadastra Agendamento
(UC 02.01) e demonstra os métodos utilizados para a implementação do sistema, bem como o que
foi implementado no dispositivo móvel e no Web Services.
A Figura 20, demonstra o diagrama de seqüência para o caso de uso cadastro do
questionário 24 horas também demonstrando o que foi implementado no dispositivo móvel e o que
foi implementado no Web Services.
A Figura 21 representa o diagrama de seqüência para o caso de uso cadastro geral de
freqüência de uso de alimentação (UC 02.05), responsável por registrar os alimentos e quantidades
geralmente consumidas pelo paciente.
A Figura 22 representa o diagrama de seqüência do caso de uso consulta prescrição
alimentar, uma das partes mais importantes do sistema, pois por esta funcionalidade do sistema, o
usuário ira basear a sua alimentação. Toda vez que o nutricionista disponibilizar uma prescrição
alimentar (esta etapa é feita no Programação alimentar utilizando RBC), esta ficará disponível para
consulta pelo paciente.
47
Os diagramas apresentados aqui, demonstram a integração do dispositivo móvel com o Web
Service, apresentando a troca de mensagens (métodos) e o que é de responsabilidade de cada
módulo do sistema. O sistema Programação Alimentar utilizando RBC (T-Diet), é responsável por
alimentar os Web Services, fornecendo as funções que serão invocadas por tal.
Figura 19. Diagrama de seqüência do Cadastro de Agendamento
48
Figura 20. Diagrama de seqüência do Cadastro do Questionário 24 horas
49
Figura 21. Diagrama de seqüência para o Cadastro geral de freqüência de uso de alimentos
50
Figura 22. Diagrama de seqüência para a consulta de prescrição alimentar
3.3 Modelagem do banco de dados
O modelo Entidade Relacionamento (ER), representa graficamente a “arquitetura” da base
de dados e representa as entidades e atributos que farão parte do projeto físico do bando de dados. O
modelo ER que se encontra no Apêndice A e que será utilizado neste projeto, foi criado por Miotto
(2006). Neste modelo estão representadas as entidades, baseados no diagrama de classes, onde as
principais entidades são: Paciente, Avaliação Nutricional, Medida Índice e Prescrição alimentar. O
modelo do banco de dados contento apenas as tabelas utilizadas neste projeto, estão apresentados na
figura 19 . A figura 19, busca dar uma visão geral das entidades e relacionamentos utilizadas no
projeto e que são utilizadas para armazenamento das informações do sistema proposto.
51
Figura 23. Diagrama ER do banco de dados.
A tabela QUESTIONARIO_24, foi utilizada para armazenar informações alimentares do
paciente, esta tabela é responsável por armazenar o que foi consumido pelo paciente nas últimas 24
horas. Esta tabela contém informações tais como: hora em que o paciente foi dormir no ultimo dia,
horário em que o paciente costuma dormir, hora da primeira ingestão de alimentos do dia do
paciente, dentre outras.
A tabela ALIMENTO_EVITADO, é responsável por armazenar todos os alimentos que
devem ser evitados pelo paciente, sejam eles por motivos de dieta, alergia. Esta tabela contém os
produtos evitados e o motivo de o paciente ter que evitar este alimento.
A tabela DUVIDA, é responsável por registrar as dúvidas dos pacientes. Estas dúvidas
poderão ser cadastradas como públicas ou privadas, dependendo do interesse do paciente em que
outras pessoas vejam ou não a resposta para esta dúvida.
A tabela PRESCRICAO_ALIMENTAR é responsável por registrar o que foi prescrito pelo
nutricionista ao paciente, está tabela tem relacionamento com a tabela PRESCRICAO_GRUPO,
que é responsável por armazenar o grupo de pacientes aos quais serão feitas as prescrições do
nutricionista.
A tabela PRODUTO armazena as informações sobre os alimentos e armazena informações
tais como quantidade de calorias, e unidade de medida do produto. Esta tabela se associa a tabela
GRUPO_PRODUTO, e que serão utilizadas para consulta de substituição de alimentos.
Estas são as principais tabelas do sistema, além dessas, existe a tabela PESSOA, responsável
por armazenas as entidades do sistema, tabela MEDIDA_INDICE, que armazena informações
métricas sobre o paciente, dentre outras conforme apresentado na Figura 19.
52
3.4 Implementação
Esta etapa aborda a codificação do projeto em uma aplicação funcional.
Para
implementação, foram utilizadas as tecnologias e ferramentas propostas inicialmente. Além disso,
foi necessária a utilização de um servidor para processar os Web Services o qual se chama AXIS. O
AXIS é responsável por gerar o arquivo WSDL a partir de uma classe Java. O arquivo WSDL, é
uma linguagem baseada em XML utilizada para descrever Web Services. O WSDL trata-se de um
documento escrito em XML que além de descrever o serviço, especifica como acessá-lo e quais as
operações ou métodos disponíveis.
O desenvolvimento do sistema foi feito visando à utilização de dados reais os quais foram
adquiridos junto a profissionais da saúde. Foi utilizado JAVA (J2ME) para criação da aplicação
para o dispositivo móvel, e JAVA (J2EE) para criação dos Web Services. A aplicação foi
desenvolvida utilizando os padrões da edição J2ME, com base nas especificações da configuração
CLDC e perfil MIDP versão 2.0. A ferramenta utilizada para codificação foi o Eclipse, juntamente
com o plugin Carbije.j, que é uma ferramenta gratuita para desenvolvimento de aplicações para a
plataforma J2ME voltada à criação de aplicativos para celulares e smartphones Nokia, nas
plataformas Series 40, S60 e Series 80.
O banco de dados utilizado foi o mesmo proposto no projeto inicial, MYSQL. Para
modelagem e especificação do sistema, foi utilizada a ferramenta Enterprise Architect, baseada em
UML. Com o Enterprise Architect, foram criados os diagramas de seqüência, de componente, caso
de uso e o modelo ER do banco de dados. A ferramenta possibilitou a criação e geração do código
em JAVA e o mesmo sincronismo com os Diagramas.
A integração com o sistema Programação alimentar utilizando RBC (T-Diet) ocorre de
maneira invisível ao usuário, pois as classes de lógica de negócio contidas nos Web Services, fazem
este papel, fornecendo chamadas a métodos contidos no T-Diet e trazendo o retorno
desses
métodos aos usuários.
A implementação do sistema, foi baseada utilizando o conceito de três camadas, utilizando a
técnica de MVC (Model, View, Controler). O MVC é um padrão de projeto, que separa a lógica da
aplicação (Model), da interface do usuário (View) e do fluxo da aplicação (Controller). O Model é
responsável por implementar a camada de persistência ou camada de dados. View é a camada de
apresentação ao usuário, responsável por todas as telas que serão apresentadas ao usuário. Controler
53
é a camada responsável pelos eventos de gerenciamento do projeto, tais como cliques em botões,
eventos e processos. Com esta técnica de programação, fica fácil portar o aplicativo para outros
celulares e/ou dispositivos, tornando necessário apenas, em alguns casos, modificar a camada de
visualização.
Figura 24. Estrutura de pacotes da aplicação
Na Figura 24, é possível observar como foram organizados os pacotes a fim de atender a
especificação do MVC. O pacote src/view é responsável pela camada de visualização à lógica de
negócio do sistema, está todo implementado nos WebServices. Além deste pacote, tornou-se
necessário adicionar outros pacotes ao projeto, para que o mesmo possa ser utilizado no dispositivo
móvel. Estes pacotes são:

Axis.jar – Responsável pela conexão com o WebService;

Log4j-1.2.8.jar – Responsável por gerar arquivo de logs com possíveis erros no sistema;
O arquivo build.xml, é um arquivo de configuração do sistema, neste arquivo são
encontrados os principais parâmetros do sistema, como endereço do servidor e nome da aplicação.
A Figura 25 apresenta a estrutura do arquivo build.xml.
Os WebServices também foram implementados em Java e depois convertidos para XML no
padrão WSDL.
54
Para implementação das funcionalidades no celular, foi necessário utilizar o conceito de
programação paralela (thread) a fim de evitar que o telefone celular fique bloqueado em alguma
tela ou funcionalidade. Com utilização de thread é possível processar as informações, enquanto o
telefone fique livre para processar outras informações. Está técnica foi utilizada, pois com a
utilização do webservice, torna-se necessário aguardar a resposta do servidor para que o usuário
possa prosseguir com a operação desejada.
Figura 25. Arquivo build.xml
A seguir estão relacionadas as principais telas do sistema, para demonstrar como o sistema
se comporta e sua interface, afim de facilitar o entendimento do mesmo.
A Figura 26 apresenta a tela inicial do sistema, onde o usuário irá informar o seu nome e
senha e então poderá ter acesso ao sistema. Este nome e senha serão fornecidos pelo nutricionista,
no momento que o mesmo for cadastrado no sistema “Programação alimentar utilizando RBC”.
Caso o usuário não lembre sua senha, existe a opção “Esqueci minha senha”, que imediatamente
disparará um e-mail ao usuário informando sua senha.
55
Figura 26. Login no sistema
A seguir serão apresentadas ao usuário, as opções disponíveis no sistema, conforme
indicado na Figura 27.
Figura 27. Menu principal do sistema.
A Figura 28 apresenta a tela de Agendamento, que permite ao usuário registrar agendamento
futuro de refeições, possibilitando a emissão de um alerta ou não. O usuário informa data e hora em
que deseja ser lembrado, e a alimentação que deve ser consumida.
56
Figura 28. Tela de cadastro de agendamento de refeições.
A Figura 29 apresenta a tela de cadastro de medidas do paciente, nesta tela o usuário poderá
informar medidas tais como peso, cintura, altura e quadril. Estas informações serão cruciais para a
tomada de decisão do nutricionista, sobre o melhor plano alimentar para o paciente.
Figura 29. Tela de cadastro de medidas dos pacientes.
A Figura 30 apresenta o cadastro do questionário 24 horas. O questionário 24 horas é
responsável por avaliar através de métodos de abordagem a ingestão dietética do paciente. Estas
informações vão desde a hora em que o paciente costuma dormir e foi dormir na noite anterior, até
questões relativas a alimentação.
57
Figura 30. Tela de cadastro do questionário 24hrs.
Outro questionário importante para as avaliações do nutricionista, é o questionário de
freqüência, que registra a quantidade e freqüência de determinados alimentos consumidos pelo
paciente. Nele o usuário irá registrar a quantidade de cada alimento consumido. Esta tela está
representada na Figura 31.
As respostas devem
ser registradas desta
forma: 1/dia,
1/semana, 3/mês ou
o mais exato
possível. Pode ser
usada a notação
"ocasionalmente
”" ou
"raramente".
Figura 31. Tela do Questionário geral de freqüência de alimentos.
A tela representada na Figura 32 apresenta a opção para consulta de alimentos semelhantes.
Ocorreram momentos onde o paciente não poderá consumir o alimento prescrito pelo nutricionista,
então ele terá a opção de consultar algum alimento semelhante que ele poderá consumir. O usuário
irá informar o alimento, e o sistema irá sugerir os alimentos que são semelhantes nutritivamente.
58
Figura 32. Tela de pesquisa de alimentos semelhantes.
3.5 Teste e Validações
Teste de Software é o processo de executar o software de uma maneira controlada com o
objetivo de avaliar se o mesmo se comporta conforme o especificado. O objetivo dos testes, é o de
encontrar o maior número de erros possíveis.
A etapa de testes foi efetuada no momento do desenvolvimento do projeto, efetuando os
testes unitários (testa-se individualmente as unidades do sistema, no caso as classes) e
posteriormente efetuando os testes de integração (testou-se o sistema como um todo, visando
identificar se implementações em alguma classe possa ter interferido em outra).
Os principais testes efetuados no sistema foram:

Testes de funcionalidade. Verificando se o que foi levantado nos requisitos realmente
corresponde ao que foi implementado;

Testes de interface. Visando identificar se as telas correspondem ao que foi prototipado e
se ergonomicamente são fáceis de usar e

Testes de desempenho: A principio encontraram-se problemas com a comunicação com
os Web Services, pois demorava muito para obter uma resposta. Para isso foi utilizado o
conceito de programação concorrente, a fim de aperfeiçoar o tempo de resposta ao
usuário.
As validações do sistema foram efetuadas por pessoas que pouco conheciam a lógica de
negócio do aplicativo, ao todo foram utilizadas cinco pessoas no auxilio a validação do sistema, isso
59
causou certa dificuldade em saber se realmente o que foi feito estava de acordo com as regras
estabelecidas. Para isso foram contatados profissionais de saúde para que pudessem facilitar e
auxiliar no processo de validação do sistema. A principio as validações ocorreram quando o sistema
ainda estava rodando no emulador, pois se tornou mais fácil alterar o sistema conforme fossem
encontrados os problemas.
As principais dificuldades encontradas foram em relação à ergonomia do sistema, pois o
teclado numérico do celular dificulta muito o acesso do usuário, por isso procurou-se facilitar ao
máximo as telas para que os usuários se sentissem familiarizados com o sistema. Outro problema
encontrado foi em relação ao tempo de resposta do servidor, algumas vezes demorando minutos,
isso foi corrigido com a utilização de threads que diminuíram o tempo de resposta de minutos para
segundos.
Todos os problemas encontrados na validação foram corrigidos conforme apresentado
acima.
60
4 CONCLUSÕES
O estudo e pesquisa realizados neste projeto possibilitaram a compreensão sobre a
computação móvel, dispositivos móveis e nutrição. Na etapa de pesquisas, iniciou-se por uma
pesquisa e análise no sistema “programação alimentar utilizando RBC” na qual se buscou
identificar as principais características e quais delas poderiam ser abordadas neste projeto, ou seja, o
que seria viável para um projeto de computação móvel na área de nutrição. Além disso, buscou-se
uma orientação junto a profissionais de saúde tentando identificar os pontos relevantes ao
desenvolvimento do projeto.
Seguindo as pesquisas, partiu-se para análise da computação móvel e dos dispositivos
móveis buscando identificar na tecnologia escolhida para dispositivos móveis quais características
melhor se encaixava na proposta do trabalho, além disso, vale ressaltar que a escolha do dispositivo
móvel adotado (Nokia 6230i) foi feito baseado nos requisitos mínimos do sistema, e por ser um
dispositivo que mais se adequou a solução desenvolvida. Na parte de projeto, foi desenvolvida uma
modelagem inicial do sistema, apresentando os diagramas considerados relevantes ao sistema, e que
pudessem deixar claro o que o sistema está se propondo a fazer e como será feito.
Durante a análise do sistema, foi encontrada muita dificuldade, pois mesmo que o celular
tenha se propagado em todo mundo, ainda há uma certa relutância em utilizá-lo como uma
ferramenta para auxílio as tarefas do dia-a-dia, isto devido à baixa taxa de transmissão de dados e
principalmente a ergonomia. Entretanto, buscou-se desenvolver um projeto que visasse ser o mais
fácil possível em relação à utilização e que pudesse ser efetivamente utilizada no auxilio a
alimentação do paciente.
A modelagem do sistema foi elaborada utilizando os padrões da UML e técnica de
programação MVC, possibilitando assim uma maior portabilidade do sistema. Foram apresentados
os diagramas relevantes ao projeto do software, bem como as telas e suas funcionalidades visando
um maior entendimento do sistema.
A implementação do software seguiu os diagramas descritos e os protótipos de telas
desenvolvidos na etapa de projeto, buscou-se seguir a arquitetura de três camadas facilitando assim
o desenvolvimento do sistema.
61
As validações efetuadas ajudaram a aperfeiçoar o sistema, bem como identificar problemas
ergonômicos e erros de projeto, os testes contribuíram assim para que se pudesse alcançar uma
maior excelência do sistema.
Como sugestão para novos estudos e projetos, baseado nesta proposta, propõe-se
desenvolver uma ferramenta que também seja disponível ao nutricionista, e que o mesmo possa
fazer uso da computação móvel no trabalho do dia a dia, permitindo assim, ainda mais, uma
interação com o paciente. Outra sugestão é portar o sistema para pocket-pc , PDA e Smartphones
além de portar para o maior número de celulares disponíveis no mercado.
62
REFERÊNCIAS BIBLIOGRÁFICAS
AGUSTINI, A.M.V.A. Novos papéis da tecnologia para internet: Wireless Aplication Protocol.
2000. Disponível em <http://www.ccuec.unicamp.br/revista/infotec/> . Acesso em: 21 set. 2006.
ALÇADA, J.A.G. Estudo sobre a utilização de uma aplicação móvel num serviço hospitalar.
2004. 108 f. Trabalho de Conclusão de Curso (Licenciado(a) em Engenharia da Comunicação) –
Universidade Fernando Pessoa, Porto, 2004.
ALVARENGA, M. Bulimia Nervosa - Aspectos Atuais. Disponível em:
<http://www.nutricaoempauta.com.br/lista_artigo.php?cod=99>. Acesso em: 15 set 2006.
ANATEL, Agência Nacional de Telecomunicações. Dados Relevantes do Serviço Móvel Pessoal
- SMP. 2006. Disponível em:
<http://www.anatel.gov.br/Tools/frame.asp?link=/comunicacao_movel/smc/dados_relevantes_smc_
smp.pdf>. Acesso em: 09 Ago. 2006.
BERNARDINO, H. S. J2ME (Java 2 Micro Edition). 2006. Disponível em: <
http://www.ipixel.com.br/artigos_esp.aspx?cod_artigo=12&relacao=2 >. Acesso em: 10 nov. 2006.
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Campus:
Elsevier, 2002.
BURÉGIO, Vanilson A. A. Desenvolvimento de aplicações para dispositivos móveis com
.NET. 2003. 69 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) –
Centro de Informática, Universidade Federal de Pernambuco, Recife.
CAMARGO, K.G. Inteligência Artificial aplicada à nutrição na prescrição de planos
alimentares. 1999. Trabalho de Conclusão de Curso (Mestrando em Engenharia de Produção)–
Universidade Federal de Santa Catarina, Florianópolis, 1999.
CANI, G. E. Protótipo de software para acesso a informações baseado na tecnologia WAP.
2000. 88 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro
de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau, 2000.
CERVATO, A. M. drª et al. Bases Teóricas para a Prática da Educação Nutricional. 2004.
Disponível em < http://www.nutricaoempauta.com.br/lista_artigo.php?cod=45 >. Acesso em: 08
ago. 2006.
CHAPPELL, D.; JEWELL, T. Java Web Services. 2002. O'Reilly, 2002.
COCOLO, A.C. Soja, fonte do bom colesterol. 2006. Disponível em
<http://www.unifesp.br/comunicacao/jpta/ed177/pesquisa1.htm>. Acesso em: 15 ago. 2006.
CORREIA, M.I.T.D. Nutrição, esporte e saúde. Belo Horizonte: Health, 1996.
CZEPIELEWSKI, M. A. Obesidade. Porto Alegre, 2001. Disponível em:
<http://www.abcdasaude.com.br/artigo.php?303>. Acesso em: 04 jun. 2006.
63
DIAS, B. C. Análise da tecnologia WAP via estudo de caso em jogos distribuídos e interativos. 2003.
75 f. Trabalho de Conclusão de Curso (Bacharel em Ciências da Computação) – Departamento de
Ciências da Computação, Universidade Federal de Lavras, Lavras, 2003.
DORNAN, A. Wireless communications. 2001. O guia essencial de comunicação sem fio. São
Paulo: Campus, 2001.
DUARTE, R. L. Utilização da tecnologia J2ME para acesso ao serviço de correio eletrônico.
2005. 146 f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) –
Universidade do Vale do Itajaí, São José, 2005.
DUTRA-DE-OLIVEIRA, J. E; MARCHINI, J. S. 1998. Ciências nutricionais. São Paulo: Sarvier,
1998.
FIGUEIREDO, C. M. S.; NAKAMURA, E. Computação móvel: novas oportunidades e
desafios. 2003. T&C Amazônia, Ano 1, no. 2, jun. 2003.
FIGUEIREDO, T.H.P. MultiMad: Uma ferramenta multimodelo de desenvolvimento de
aplicações para dispositivos móveis. 2005. 90 f. Dissertação (Mestrado em Ciências da
Computação) - Conselho Nacional de Desenvolvimento Científico e Tecnológico, Universidade
Federal de Minas Gerais, 2005.
FRANK, Gail C. Guidelines for selecting a dietary analysis system. Journal of American Dietetic
Association. USA, n. 1, v. 86, pp. 72-75, January, 1986.
GARROZI, C. Uso da tecnologia móvel no auxílio à reeducação alimentar. 2003. Trabalho de
Conclusão de Curso (Graduação em Ciência da Computação) – Departamento de Ciências da
Computação, Universidade de Lavras, Lavras, 2003.
GONÇALVES, P.A.da S. Bluetooth. 2000. Disponível em:
<http://www.gta.ufrj.br/~apaulo/seminarios/adhoc-e-bluetooth/>. Acesso em: 04 nov. 2006.
HADDAD, R. Entendendo aplicações móveis no .NET. 2005. Diponível em:
<http://www.microsoft.com/brasil/msdn/tecnologias/movel/mobilidade_entendendo.aspx>. Acesso
em: 18 ago. 2006.
HANDANGO. Calorie Burner - Diet and Exercise Planner. 2006. Disponível em: <
http://www.handango.com/PlatformProductDetail.jsp?siteId=1&jid=AEB3F8D4E4B9C817AEC55
B7347D3A7A3&platformId=2&N=96806%2095824&productId=140133&R=140133>. Acesso
em: 12 set. 2006.
HANDANGO. MyPersonalDiet. 2006b. Disponível em: <
http://www.handango.com/PlatformProductDetail.jsp?siteId=1&jid=AEB3F8D4E4B9C817AEC55
B7347D3A7A3&platformId=2&N=96806%204294926756&productId=160537&R=160537>.
Acesso em: 12 set. 2006.
KRAUSE, M. V; MAHAN, L. K.; ESCOTT-STUMP, S. Alimentos, nutricao & dietoterapia. 10.
ed. Sao Paulo: Roca, 2002.
64
LARCHER, M. CNPq financia inovações em informação médica. 2003. Disponível em: <
http://memoria.cnpq.br/noticias/150503.htm>. Acesso em: 01 out. 2006.
LEE, G.; TSAI, C.; RAAB, F.; GRISWOLD, W.G.; PATRICK, K.. PmEB: a mobile phone
application for monitoring caloric balance. 2006. Disponível em:
<http://portal.acm.org/citation.cfm?id=1125451.1125645#references>. Acesso em: 21 out. 2006.
ISAN, Infraestrutura de Suporte às Aplicações Móveis Distribuídas. Definição de computação
móvel. Disponível em <http://www.inf.ufrgs.br/~isam/paginaDefComputacaoMovel.html>. Acesso
em 05 ago. 2004.
LIMA, A.L.S. Identificação e exemplificação de aspectos da computação distribuída no
desenvolvimento de aplicações para celulares usando J2ME e Bluetooth. 2005. Trabalho de
Conclusão de Curso (Graduação em Sistemas Distribuídos). Universidade Federal de Pernambuco,
Recife, 2005.
MATEUS, G. R.; LOUREIRO, A. A.F. Introdução à computação móvel. Rio de Janeiro: 11a
Escola de Computação, 1998.
MICROSOFT. Microsoft Mobile Internet Toolkit. 2006. Redmond: Microsoft, 2006. Disponível
em: < http://www.asp.net/mobile/intro.aspx?tabindex=6 >. Acesso em: 26 set. 2006.
MILLER, S. K. Facing the challenge of wireless security. 2001. IEEE Computer, pages 16–18,
July 2001.
MIOTTO, M. Programação alimentar utilizando RBC. 2006. Trabalho de Conclusão de Curso
(Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do Mar,
Universidade do Vale do Itajaí, Itajaí, 2006.
MITCHELL, H. S.; ANDERSON, L. Nutrição. Rio de Janeiro, 1988.
MUCHOW, J. W. Core J2ME: tecnologia e MIDP. 2004. São Paulo: Makron Books, 2004.
NOBREGA, F. J. de. Distúrbios da nutrição. Rio de Janeiro: Revinter, 1998.
NOKIA. Tecnologias: A solução SyncML. 2006. Disponivel em <
http://www.nokia.com.br/nokia/0,8764,43752,00.html>. Acesso em: 15 set. 2006.
NOKIA. Tecnologias: A solução SyncML. 2006b. Disponivel em <
http://www.nokia.com.br/nokia/0,8764,43754,00.html>. Acesso em: 15 set. 2006.
OLIVA, C.A.G.; FAGUNDES, U. Aspectos clínicos e nutricionais dos transtornos alimentares.
2002. Disponível em <http://www.unifesp.br/dpsiq/polbr/ppm/atu1_06.htm>. Acesso em: 18 Set.
2006.
OLIVEIRA, E. Nutrição - Ponto de Vista. 2002. Disponível em
<http://www.saudeemmovimento.com.br/conteudos/conteudo_exibe1.asp?cod_noticia=126>.
Acesso em: 07 ago. 2006.
PESSA, R. P. Seleção de uma alimentação adequada. In : OLIVEIRA J. E. Dutra de; ,
MARCHINI, J.S. Ciências nutricionais. São Paulo: Sarvier, 1998.
65
PEKUS. Wireless. 2002. Disponível em: <http://www.pekus.com.br/wireless.htm> Acesso em: 15
set. de 2006.
QUALCOMM. A Solução BREW. 2006. Disponível em:
< http://brew.qualcomm.com/brew/pt/developer/resources/gs/brew_solution.html >. Acesso em: 18
Set. 2006.
SUN, Introduction to Mobility Java Technology. 2006. Disponível em:
<http://developers.sun.com/techtopics/mobility/getstart/>. Acesso em: 09 de Agosto de 2006.
SUPERWABA. Plataforma: resumo. Rio de Janeiro: SuperWaba, 2006. Disponível em:
<http://www.superwaba.com.br/pt/overview.asp>. Acesso em: 15 Set. 2006.
TANEMBAUM, A.S. Rede de computadores. 4.ed. Tradutor: Vandenberg D. de Souza. Rio de
Janeiro: Campus, 2003.
TELECO. Telefonia celular. 2006. Disponível em <http://www.teleco.com.br/ncel.asp> . Acesso
em: 15 Set. 2006.
66
GLOSSÁRIO
Anamnese
História colhida pelo médico sobre saúde do paciente, bem como hábitos do
paciente.
Antropometricos
Os dados antropometricos são os dados das medidas físicas do corpo
humano. A origem da antropometria remonta-se à antigüidade pois Egípcios
e Gregos já observavam e estudavam a relação das diversas partes do corpo
Anorexia Nervosa
Distúrbio psicológico que leva à diminuição da ingestão de alimentos.
Bulimia
Distúrbio emocional que leva a surtos de abusos alimentares, seguidos por
sentimento de culpa e conseqüentes indução de vômitos.
Tomcat
Servidor de aplicações Java para WEB.
67
APÊNDICES
68
A MODELAGEM DO SISTEMA
Esta seção apresenta a modelagem completa do sistema produzida pela ferramenta case
Enterprise Architect bem como as telas do sistema.
A.1 CASOS DE USO
A modelagem do sistema proposto é composta por 3 pacotes: Controle de Acesso, Consulta
e Cadastros. A figura 20 ilustra os pacotes e a interação deles.
pd 2.1 Diagrama de Pacotes
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered
Trial Version EA 6.1 Unregistered Trial Version
Cadastro
Controle de Acesso
+ Paciente
+ UC02.01 Cadastrar o agendamento das refei ções
EA 6.1
Unregistered Trial Version EA 6.1 Unregistered
Trial Version EA 6.1 Unregistered Trial Version
+ Paciente
+ UC02.02 Cadastrar medidas
+ UC01. Login no Si stema
+ UC02.03 Cadastrar dúvidas
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered
Trial Version
EA 6.1 Unregistered Trial Version
+ UC02.04 Cadastrar
questionário 24Hrs
+ UC02.05 Cadastrar Questionário geral de freqüência de uso dos alimentos
(from 2.2 Diagrama de casos de uso)
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
(from 2.2 Diagrama de casos de uso)
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
Consultas
+ Paciente
EA 6.1
Unregistered Trial Version EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
+ UC03.01 Consultar prescrição alimentar
+ UC03.02 Consultar Repostas das Dúvidas
+ UC03.03
Consultar tabela de
substituição
de al imentos
EA 6.1
Unregistered
Trial
Version
EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
+ UC03.04 Consultar Alimentos evitados
(from 2.2 Diagrama
casos de uso) EA 6.1 Unregistered Trial Version EA 6.1 Unregistered Trial Version
EA 6.1 Unregistered
TrialdeVersion
Figura 33. Pacotes do sistema
A.1.1 Pacote 01: Controle de Acesso
Este caso de uso trata a autenticação dos usuários no sistema. O Ator deste caso de uso é o
Paciente que faz o login no sistema.
A.1.1.1 UC01.01 Login no Sistema
Pré-Condição: O Paciente acessa a tela de login do Sistema.
Pós-Condição: O Paciente está autenticado no sistema.
Cenários do caso de uso:
Fluxo principal: Efetua login no sistema.
1. O Sistema apresenta uma tela solicitando o login e a senha do Paciente (TEL001).
2. O Paciente informa Login e Senha.
3. O Paciente confirma os dados.
4. O Sistema valida o Login e Senha fornecida.
5. O Sistema registra a data e hora que o paciente se conectou no sistema.
6. O Sistema apresenta a tela principal ao paciente (TEL003).
Fluxo Alternativo: Enviar lembrete de senha.
1. O Sistema apresenta uma tela solicitando o login e a senha do Paciente (TEL001).
2. O paciente seleciona a opção “Esqueci minha senha.” (TEL001).
3. O sistema envia para o e-mail do paciente a senha com o seu respectivo login.
4. A mensagem de confirmação de envio de login e senha é enviada ao paciente (TEL002).
Fluxo de Exceção 1: Login ou Senha em branco.
Se no passo 3 do fluxo principal o paciente não informou o login, senha ou a opção “Esqueci
minha senha”, a seguinte mensagem é apresentada: “Favor informar login ou senha.” (TEL002) e
retorna ao passo 1.
Fluxo de Exceção 2: Login e Senha inválidos.
Se no passo 4 do fluxo principal o login e a senha não forem validadas pelo sistema, a
seguinte mensagem é apresentada: “Login ou Senha inválida.” (TEL002) e retorna ao passo 1.
Relações:

RNF07: O sistema deve permitir acesso somente aos pacientes cadastrados no sistema;.

RF04: O sistema deve enviar por e-mail o cadastro do paciente e senha de acesso ao
sistema
70
A.1.2 Pacote 02: Consultas
Neste pacote serão apresentados os casos de uso relacionados aos cadastros dos dados do
paciente, dúvidas e agendamento de refeições.
A.1.2.1 UC02.01 Cadastrar o agendamento das refeições
Pré-Condição: O Paciente precisa estar logado no sistema.
Pós-Condição: Um novo agendamento foi cadastrado no sistema.
Cenários do caso de uso:
Fluxo principal: Cadastrar o agendamento das refeições.
1. O Sistema apresenta a tela de cadastro de agendamento de refeições (TEL004).
2. O paciente preenche as informações necessárias.
3. O paciente salva os dados do agendamento.
4. O sistema grava as informações de agendamento de refeições.
5. O sistema apresenta a mensagem ao paciente “Cadastrado com sucesso.” (TEL002).
Fluxo de Exceção: Data e hora não informadas.
Se no passo 3, caso os campos não tenham sido preenchidos ou o formato não é válido,
apresenta mensagem "Verifique os seguintes campos: <<listar campos>>." (TEL002) e retorna ao
passo 1.
Relações:

RF01: O sistema deve permitir o agendamento das refeições.
A.1.2.2 UC02.02 Cadastrar medidas do paciente
Pré-Condição: O Paciente precisa estar logado no sistema.
Pós-Condição: As medidas do paciente foram cadastradas no sistema.
Cenários do caso de uso:
71
1. O Sistema apresenta a tela de cadastro de medidas do paciente (TEL005).
2. O paciente preenche as informações necessárias.
3. O paciente salva os dados.
4. O sistema grava as informações das medidas do paciente.
5. O sistema apresenta a mensagem ao paciente “Cadastrado com sucesso.” (TEL002).
Fluxo de Exceção: Inconsistência na validação dos dados.
Se no passo 3, caso os campos não tenham sido preenchidos ou o formato não é válido,
apresenta mensagem "Verifique os seguintes campos: <<listar campos>>." (TEL002) e retorna ao
passo 1.
Relações:

RF03: O sistema deve permitir o cadastro das medidas do paciente.
A.1.2.3 UC02.04 Cadastrar dúvidas
Pré-Condição: O Paciente precisa estar logado no sistema.
Pós-Condição: Uma nova dúvida foi cadastrada no sistema.
Cenários do caso de uso:
Fluxo principal: Cadastrar dúvidas.
1. O Sistema apresenta a tela de cadastro de dúvidas (TEL006).
2. O paciente preenche as informações necessárias.
3. O paciente salva os dados da dúvida.
4. O sistema grava as informações da dúvida do paciente.
5. O sistema apresenta a mensagem ao paciente “Cadastrado com sucesso.” (TEL002).
Fluxo de Exceção: Campo “dúvida” não informado.
72
Se no passo 3, caso os campos não tenham sido preenchidos ou o formato não é válido,
apresenta mensagem "Verifique os seguintes campos: <<listar campos>>." (TEL002) e retorna ao
passo 1.
Relações:

RF06: O sistema deve permitir o cadastro e consulta de dúvidas do paciente referente ao
tratamento.
A.1.2.4 UC02.05 Cadastrar questionário 24Hrs
Pré-Condição: O Paciente precisa estar logado no sistema.
Pós-Condição: O questionário 24hrs foi cadastrado no sistema.
Cenários do caso de uso:
Fluxo principal: Cadastrar questionário 24Hrs.
1. O Sistema apresenta a tela do cadastro 24hrs (TEL007).
2. O paciente preenche as informações necessárias.
3. O paciente salva os dados do cadastro 24hrs.
4. O sistema grava as informações do cadastro 24hrs.
5. O sistema apresenta a mensagem ao paciente “Cadastrado com sucesso.” (TEL002).
Fluxo de Exceção: Inconsistência na validação dos dados.
Se no passo 3, caso os campos não tenham sido preenchidos ou o formato não é válido,
apresenta mensagem "Verifique os seguintes campos: <<listar campos>>." (TEL002) e retorna ao
passo 1.
Relações:

RF07: O sistema deve permitir o cadastro do Questionário de 24h.
A.1.2.5 UC02.05 Cadastrar questionário geral de freqüência de uso dos alimentos
Pré-Condição: O Paciente precisa estar logado no sistema.
73
Pós-Condição: Os dados do questionário de freqüência de uso dos alimentos foi cadastrado
no sistema.
Cenários do caso de uso:
1. O Sistema apresenta a tela do cadastro do questionário geral de freqüência de alimentos
(TEL008).
2. O paciente preenche as informações necessárias.
3. O paciente salva os dados do questionário.
4. O sistema grava as informações do cadastro do questionário.
5. O sistema apresenta a mensagem ao paciente “Cadastrado com sucesso.” (TEL002).
Fluxo de Exceção: Inconsistência na validação dos dados.
Se no passo 3, caso os campos não tenham sido preenchidos ou o formato não é válido,
apresenta mensagem "Verifique os seguintes campos: <<listar campos>>." (TEL002) e retorna ao
passo 1.
Relações:

RF08: O sistema deve permitir o cadastro do Questionário geral de freqüência de uso
dos alimentos.
A.1.3 Pacote 03: Consultas
Neste pacote serão apresentados os casos de uso relacionado ás consultas dos dados do
paciente, dúvidas, planos alimentares e agendamento de refeições.
A.1.3.1 UC03.01 Consultar prescrição alimentar do paciente
Pré-Condição: O Paciente precisa estar logado no sistema.
Pós-Condição: A consulta da prescrição alimentar foi efetuada com sucesso.
Cenários do caso de uso:
Fluxo principal: Consultar a programação alimentar
74
1. O Sistema apresenta a tela da prescrição alimentar do paciente contendo a ultima
prescrição cadastrada pelo nutricionista (TEL009).
Fluxo de Exceção: Nenhuma prescrição apresentada.
Se no passo 1, caso a prescrição alimentar do paciente ainda não tenha sido informada pelo
nutricionista, apresenta mensagem "Nenhuma prescrição alimentar cadastrada." (TEL002) e retorna
ao passo 1.
Relações:

RF05: O sistema deve permitir a consulta da prescrição alimentar do paciente.
A.1.3.2 UC03.02 Consultar Repostas das Dúvidas
Pré-Condição: O Paciente precisa estar logado no sistema.
Pós-Condição: A consulta da resposta à dúvida do paciente foi efetuada com sucesso.
Cenários do caso de uso:
Fluxo principal: Cadastrar dúvidas.
2. O Sistema apresenta a tela de Consulta de dúvidas (TEL010).
3. O paciente seleciona uma das 5 últimas dúvidas que ele cadastrou.
4. O sistema apresenta os dados da resposta (TEL011).
5. O paciente visualiza as informações.
Fluxo de Exceção: Resposta à dúvida não encontrada.
Se no passo 2, caso a dúvida do paciente ainda não tenha sido respondida, apresenta
mensagem "A dúvida ainda não foi respondida." (TEL002) e retorna ao passo 1.
Relações:

RF06: O sistema deve permitir o cadastro e consulta de dúvidas do paciente referente ao
tratamento.
75
A.1.3.3 UC03.03 Consultar tabela de substituição de alimentos
Pré-Condição: O Paciente precisa estar logado no sistema.
Pós-Condição: O usuário visualiza o alimento substituto.
Cenários do caso de uso:
Fluxo principal: Consultar tabela de substituição de alimentos.
1. O Sistema apresenta a tela de pesquisa de alimentos (TEL012).
2. O paciente preenche as informações necessárias.
3. O paciente confirma a operação.
4. O sistema apresenta os dados encontrados (TEL013).
5. O paciente visualiza as informações.
Fluxo de Exceção 1: Campo “Alimento” não informado.
Se no passo 2, caso o campo “Alimento” não tenha sido preenchido ou o formato não é
válido, apresenta mensagem "Verifique os seguintes campos: <<listar campos>>." (TEL002) e
retorna ao passo 1.
Fluxo de Exceção 2: Nenhum resultado encontrado.
Se no passo 3, caso não tenha encontrado nenhum alimento semelhante, apresenta
mensagem "Nenhum alimento semelhante encontrado." (TEL002) e retorna ao passo 1.
Relações:

RF02: O sistema deve permitir a consulta de substituições de alimentos.
A.1.3.4 UC03.04 Consultar Alimentos evitados
Pré-Condição: O Paciente precisa estar logado no sistema.
Pós-Condição: A consulta do alimento evitado pelo paciente foi efetuada com sucesso.
Cenários do caso de uso:
76
Fluxo principal: Consultar alimentos evitados.
1. O Sistema apresenta a tela de alimentos evitados (TEL014).
2. O seleciona o alimento que ele deseja visualizar.
3. O sistema apresenta os dados do alimento evitado (TEL015).
4. O paciente visualiza as informações.
Fluxo de Exceção: Nenhum alimento a ser evitado.
Se no passo 1, caso não haja alimentos a ser evitado pelo paciente, apresenta mensagem
"Nenhum alimento a ser evitado." (TEL002) e retorna para a tela principal do sistema (TEL003).
Relações:

RF09: O sistema deve permitir a consulta dos alimentos evitados.
77
A.2 PROTÓTIPOS DAS TELAS DO SISTEMA
Esta seção indica as telas criadas para o sistema, as telas referem-se aos elementos TEL
citados na seção anterior.
A.2.1 TEL001: Login no sistema
Figura 34. Login no sistema
A.2.2 TEL002: Mensagens do sistema
Figura 35. Mensagens do sistema
A.2.3 TEL003: Menu principal do sistema
Figura 36. Menu principal do sistema.
A.2.4 TEL004: Tela de cadastro de agendamento de refeições
Figura 37. Tela de cadastro de agendamento de refeições.
79
A.2.5 TEL005: Tela de cadastro de medidas dos pacientes
Figura 38. Tela de cadastro de medidas dos pacientes.
A.2.6 TEL006: Tela de cadastro de dúvidas
Figura 39. Tela de cadastro de dúvidas.
80
A.2.7 TEL007: Tela de cadastro do questionário 24hrs
Figura 40. Tela de cadastro do questionário 24hrs.
A.2.8 TEL008: Tela do Questionário geral de freqüência de alimentos
As respostas devem ser
registradas desta forma:
1/dia, 1/semana, 3/mês ou
o mais exato possível.
pode ser usada a notação
"ocasionalmente" ou
"raramente".
Figura 41. Tela do Questionário geral de freqüência de alimentos.
81
A.2.9 TEL009: Tela de consulta de prescrição alimentar
Figura 42. Tela de consulta de prescrição alimentar.
A.2.10
TEL010: Tela de consulta de dúvidas
Figura 43. Tela de consulta de dúvidas.
82
A.2.11
TEL011: Tela de resposta ás dúvidas
Figura 44. Tela de resposta às dúvidas.
A.2.12
TEL012: Tela de pesquisa de alimentos semelhantes
Figura 45. Tela de pesquisa de alimentos semelhantes.
83
A.2.13
TEL013: Tela de alimentos semelhantes encontrados
Figura 46. Menu principal do sistema.
A.2.14
TEL014: Tela de alimentos evitados
Figura 47. Tela de alimentos evitados.
84
A.2.15
TEL015: Tela de observação sobre o alimento evitado
Figura 48. Tela de observação sobre o alimento evitado.
85
A.3 MODELO DO BANCO DE DADOS
A.3.1 Diagrama ER do banco de dados
Figura 49. Diagrama ER do banco de dados.
86