centro estadual de educação tecnológica “paula souza”

CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA “PAULA SOUZA”
FACULDADE DE TECNOLOGIA DE LINS
CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS
CLÓVIS GRETE
USO DE DISPOSITIVO MÓVEL PARA ACOMPANHAMENTO DE
PACIENTES HIPERTENSOS
LINS/SP
2º SEMESTRE/2011
CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA “PAULA SOUZA”
FACULDADE DE TECNOLOGIA DE LINS
CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS
CLÓVIS GRETE
USO DE DISPOSITIVO MÓVEL PARA ACOMPANHAMENTO DE
PACIENTES HIPERTENSOS
Trabalho de Conclusão de Curso apresentado à
Faculdade de Tecnologia de Lins para obtenção
do Título de Tecnólogo em Banco de Dados.
Orientador: Prof. Me. João Luís Cardoso de
Moraes
LINS/SP
2º SEMESTRE/2011
CLÓVIS GRETE
USO DE DISPOSITIVO MÓVEL PARA ACOMPANHAMENTO DE
PACIENTES HIPERTENSOS
Trabalho de Conclusão de Curso apresentado à
Faculdade de Tecnologia de Lins, como parte dos
requisitos necessários para a obtenção do título de
Tecnólogo em Banco de Dados sob orientação do
Prof. Me. João Luís Cardoso de Moraes.
Data de aprovação:___/_________/_____
____________________________________________
Orientador (Prof. Me. João Luís Cardoso de Moraes)
______________________________
Examinador 1 (Nome do Examinador)
______________________________
Examinador 2 (Nome do Examinador)
AGRADECIMENTOS
À minha esposa, pela compreensão e incentivo nas horas de dificuldades.
Aos meus filhos, que são a minha fortaleza e a luz do meu caminho.
Aos meus amigos, que sempre me animaram e me mantiveram no foco.
Ao meu orientador, João Luís Cardoso de Moraes, pela ajuda e o incentivo
incansável sempre acreditando que eu seria capaz de concluir este trabalho.
Aos demais professores que, por três anos transmitiram seus conhecimentos e me
guiaram, tornando possível a conclusão deste trabalho.
RESUMO
Atualmente celulares fazem parte do cotidiano das pessoas e tornaram-se um meio
não apenas para realizar chamadas por voz, como também para o envio de
mensagens e acesso a internet, possibilitando assim a transferência remota de
dados. Com base nesta realidade o objetivo deste trabalho é apresentar uma
proposta de desenvolvimento para um sistema de informação, que visa o
gerenciamento e acompanhamento de pacientes hipertensos com a utilização de
dispositivo móvel. A utilização da tecnologia de comunicação móvel permite aos
pacientes receberem informações, bem como enviar dados referente à aferição de
sua pressão arterial de maneira on-line, sem a necessidade de dirigir-se ao
consultório médico. Aos médicos permite acompanhar o paciente com base no
registro dos dados recebidos.
Palavras chaves: Mobilidade, dispositivos móveis, sistema de informação,
prontuário.
ABSTRACT
Currently mobile phones are part of everyday life and became a means not only to
make calls by voice, but also for messaging and internet access, allowing the remote
data transfer. Based on this fact the aim of this paper is to present a development
proposal for an information system aimed at monitoring and management of
hypertensive patients with the use of mobile device. The use of mobile
communication technology allows patients to receive information and send data on
the measurement of your blood pressure so online, and send data on the
measurement of your blood pressure so online without having to go to the doctor's
office, allows doctors to monitor the patient based on the received data record.
Keywords: Mobility, mobile devices, information systems, medical records.
LISTA DE ILUSTRAÇÕES
Figura 1.1 – Exemplo de diagrama de atividade ...................................................... 19
Figura 1.2 – Exemplo de diagrama de caso de uso ................................................. 20
Figura 1.3 – Exemplo de diagrama de classe........................................................... 21
Figura 1.4 – Exemplo de diagrama de sequência .................................................... 21
Figura 1.5 – Exemplo de modelo conceitual. ............................................................ 22
Figura 1.6 – Exemplo de diagrama modelo entidade-relacionamento. ..................... 23
Figura 1.7 – Exemplo de diagrama de estrutura de dados. ...................................... 23
Figura 1.8 – Exemplo de tabela de banco de dados. ............................................... 24
Figura 2.1 – Diagrama de Caso de Uso: Cadastrar Paciente ................................... 34
Figura 2.2 – Diagrama de sequência: Cadastrar Paciente. ...................................... 35
Figura 2.3 – Diagrama de atividades: Cadastrar Paciente. ...................................... 35
Figura 2.4 – Diagrama de MVC: Cadastrar Paciente. .............................................. 36
Figura 2.5 – Diagrama de Caso de uso: Cadastrar médico ...................................... 37
Figura 2.6 – Diagrama de sequência: Cadastrar Médico.......................................... 38
Figura 2.7 – Diagrama de atividades: Cadastrar médico .......................................... 38
Figura 2.8 – Diagrama de MVC: Cadastrar Médico. ................................................. 39
Figura 2.9 – Diagrama de Caso de uso: Cadastrar Secretária ................................. 40
Figura 2.10 – Diagrama de sequência: Cadastrar Secretária ................................... 40
Figura 2.11 – Diagrama de atividades: Cadastrar Secretaria ................................... 41
Figura 2.12 – Diagrama de MVC: Cadastrar Secretária. .......................................... 41
Figura 2.13 – Diagrama de Caso de Uso: Cadastrar Convênio................................ 42
Figura 2.14 – Diagrama de sequência: Cadastrar Convênio .................................... 43
Figura 2.15 – Diagrama de atividades: Cadastrar Convênio .................................... 43
Figura 2.16 – Diagrama de MVC: Cadastrar Convênio. ........................................... 44
Figura 2.17 – Diagrama de Caso de Uso: Cadastrar Procedimento ......................... 45
Figura 2.18 – Diagrama de sequência: Cadastrar Procedimento. ............................ 45
Figura 2.19 – Diagrama de atividades: Cadastrar Procedimento ............................. 46
Figura 2.20 – Diagrama de MVC: Cadastrar Procedimento. .................................... 46
Figura 2.21 – Diagrama de Caso de Uso: Agendar Consulta ................................... 47
Figura 2.22 – Diagrama de sequência: Agendar Consulta. ...................................... 48
Figura 2.23 – Diagrama de atividades: Agendar Consulta ....................................... 48
Figura 2.24– Diagrama de MVC: Agendar Consulta. ............................................... 49
Figura 2.25 – Diagrama de Caso de Uso: Registrar Prontuário ............................... 50
Figura 2.26 – Diagrama de sequência: Registrar Prontuário. ................................... 51
Figura 2.27 – Diagrama de atividades: Registrar Prontuário .................................... 51
Figura 2.28 – Diagrama de MVC: Registrar Prontuario. ........................................... 52
Figura 2.29 – Diagrama de Caso de Uso: Registrar Aferição ................................... 53
Figura 2.30 – Diagrama de sequência: Registrar Aferição ....................................... 53
Figura 2.31 – Diagrama de atividades: Registrar Aferição ....................................... 54
Figura 2.32 – Diagrama de MVC: Registrar Aferição................................................ 54
Figura 2.33 – Diagrama de Classes ......................................................................... 55
Figura 2.34 – Diagrama Modelo Entidade-Relacionamento ..................................... 56
Figura 2.35 – Diagrama de Estrutura de Dados ....................................................... 57
Figura 3.1 – Organização dos pacotes da aplicação ................................................ 58
Figura 3.2 – Tela inicial............................................................................................. 59
Figura 3.3 – Tela para gerenciamento da agenda diária .......................................... 60
Figura 3.4 – Tela para gerenciamento de convênios ................................................ 60
Figura 3.5 – Tela para gerenciamento de médicos .................................................. 61
Figura 3.6 – Tela para gerenciamento de pacientes ................................................ 61
Figura 3.7 – Tela para gerenciamento de secretárias .............................................. 62
Figura 3.8 – Tela para gerenciamento de procedimentos ........................................ 62
Figura 3.9 – Tela para gerenciamento de relatórios ................................................. 63
Figura 3.10 – Tela para envio das aferições via celular............................................ 63
LISTA DE QUADROS
Quadro 1.1 – Fórmula para calculo da pressão ideal nas diversas idades............... 15
Quadro 1.2 – Classificação da pressão arterial ........................................................ 15
Quadro 1.3 – Classificação e segmento para acompanhamento de pacientes
hipertensos ............................................................................................................... 16
Quadro 1.4 – Exemplo de descrição de caso de uso ............................................... 20
Quadro 1. 5 – Crescimento da telefonia celular........................................................ 30
Quadro 1.6 – Lista de caso de uso ........................................................................... 33
LISTA DE ABREVIATURAS E SIGLAS
ANATEL – Agência Nacional de Telecomunicações
API - Application Programming Interface
CDC - Connected Device Configuration
CLDC - Connected Limited Device Configuration
DAO - Data Access Object
EJB - JavaBeans
GPS – Global Positioning System
HTML - Hyper Text Markup Language
HTTP – Hyper Text Transfer Protocol
IDE - Integrated Development Environment
JAD - Java Application Descriptor
JAR - Java Archive
JCP - Java Community Proccess
JDBC - Java Database Connectivity
JEE – Java Enterprise Edition
JME – Java Micro Edition
JSE – Java Standard Edition
JSP – Java Server Pages
JVM - Java Virtual Machine
MER - Modelo Entidade Relacionamento
MIDP – Mobile Information Device Profile
MMHG – Milímetros de Mercúrio
MVC – Model View Controller
PC - Personal Computer
PDA – Personal Digital Assistant
SGBD - Sistema de Gerenciamento de Banco de Dados
SGML - Standard Generalized Markup Language
SMS – Short Mensage Service
UML - Unified Modelling Language
WPAN – Wireless Personal Area Networks
XML – Extensible Markup Language
SUMÁRIO
Introdução................................................................................................................. 12
1 Revisão Bibliográfica ............................................................................................. 14
1.1 Pressão Arterial .................................................................................................. 14
1.1.1 Níveis de Pressão Arterial ............................................................................... 14
1.1.2 Classificação.................................................................................................... 15
1.1.3 Hipertensão Arterial Sistêmica (HAS) .............................................................. 15
1.2 linguagem de modelagem unificada (UML) ........................................................ 17
1.2.1 Histórico da UML ............................................................................................. 17
1.2.2 Objetivos da UML ............................................................................................ 18
1.2.3 A Notação da Linguagem ................................................................................ 18
1.2.4 Diagramas da UML .......................................................................................... 19
1.3 Banco de Dados ................................................................................................. 22
1.3.1 Definição .......................................................................................................... 22
1.3.3 Banco de dados Relacional ............................................................................. 24
1.4 Tecnologias Java ................................................................................................ 24
1.4.1 Plataforma Java ............................................................................................... 24
1.4.2 Distribuições da tecnologia Java ..................................................................... 25
1.4.3 Servlets ............................................................................................................ 27
1.4.4 Persistência de dados em Java ....................................................................... 27
1.4.5 JavaServer Faces (JSF) .................................................................................. 28
1.5. dispositivos móveis ............................................................................................ 29
1.5.1. Celular no Brasil ............................................................................................. 29
1.6 Ferramentas Integrated Development Environment (IDE) .................................. 30
1.6.1 NetBeans ......................................................................................................... 31
2 Análise e Projeto de Sistema ................................................................................. 32
2.1 Análise de Negócio ............................................................................................. 32
2.1.1 Instrução do Problema..................................................................................... 32
2.1.2 Atores e Envolvidos no Processo .................................................................... 32
2.1.3 Descrição do Ambiente Atual .......................................................................... 33
2.2 Análise de Requisitos ......................................................................................... 33
2.2.1 Análise de Requisitos Funcionais .................................................................... 33
2.2.2 Casos de Uso .................................................................................................. 34
2.2.3 Diagrama de Classes ...................................................................................... 55
2.2.4 Diagrama Modelo Entidade-Relacionamento .................................................. 56
2.2.5 Diagrama de Estrutura de Dados .................................................................... 57
3 Implementação e Testes ....................................................................................... 58
3.1 Interfaces gráficas(telas) .................................................................................... 59
3.1.1 Tela inicial ........................................................................................................ 59
3.1.2 Tela para gerenciamento de agenda ............................................................... 59
3.1.3 Tela para gerenciamento de convênios ........................................................... 60
3.1.4 Tela para gerenciamento de médicos.............................................................. 61
3.1.5 Tela para gerenciamento de pacientes............................................................ 61
3.1.6 Tela para gerenciamento de secretárias ......................................................... 62
3.1.7 Tela para gerenciamento de procedimentos ................................................... 62
3.1.8 Tela para gerenciamento de relatórios ............................................................ 63
3.1.9 Tela para envio de aferição via celular ............................................................ 63
4 considerações finais .............................................................................................. 64
4.1 conclusão ........................................................................................................... 64
4.2 Contribuições ...................................................................................................... 64
4.3 Trabalhos Futuros............................................................................................... 64
5 Referências Bibliográficas ..................................................................................... 65
12
INTRODUÇÃO
A evolução da tecnologia possibilita cada vez mais que o homem desenvolva
soluções integradas ao ambiente com o intuito de facilitar o seu dia-a-dia, diminuir o
esforço físico necessário ao desempenho das mais variadas tarefas, proporcionar
um melhor conforto e uma maior expectativa de vida. Aliado as melhorias e
facilidades proporcionadas pelo avanço tecnológico, distúrbios como stress,
depressão e hipertensão ocorrem com maior frequência e em alguns casos não são
identificados com facilidade.
Em um mundo moderno, no qual o tempo se torna cada vez mais insuficiente
para realização de tarefas cotidianas, doenças como estas prejudicam a saúde,
dificultam a qualidade de vida e apresentam uma perda de tempo considerável no
seu diagnóstico, acompanhamento e tratamento e, nesses casos qualquer ganho de
tempo é importante tanto para o paciente quanto para o médico.
A medicina sempre utilizou novas invenções com a intenção de diagnosticar
doenças precocemente, desenvolver novos medicamentos, acompanhar o paciente
durante o tratamento, elaborar gráficos sobre a evolução do seu quadro clínico, a
maneira correta de combater cada doença e nas últimas décadas o emprego da
tecnologia provocou uma contínua transformação no meio médico. Por ser um
campo vasto a medicina possibilita que projetos desenvolvidos nas mais diversas
áreas sejam estudados, adaptados e adotados, não só para o tratamento como
também na forma como os profissionais médicos acompanham seus pacientes, um
exemplo do emprego dessa variedade de tecnologia é o telefone celular que
possibilita a localização do médico quando necessário.
Atualmente, algumas tecnologias evoluíram de tal maneira que permitem a
realização do que em um passado recente era inviável, como por exemplo, acessar
remotamente dados e informações antes apenas disponíveis através de um terminal
ou servidor de dados conectados a uma rede interligada por cabos.
Hoje a tecnologia disponibiliza dispositivos móveis como handhelds, Personal
Digital Assistants (PDAs) e telefones celulares cada vez mais poderosos com
relação às suas capacidades de armazenamento, de processamento e de
comunicação, possibilitando conectividade e poder de uso em qualquer lugar e em
13
qualquer momento, tornando-se importantes, tanto para uso pessoal quanto
profissional, ao mesmo tempo em que se tornam mais acessíveis aos consumidores.
A arquitetura dos dispositivos móveis aliada ao avanço da comunicação sem
fio e o aprimoramento da tecnologia Java através do Java Micro Edition (JME) para
desenvolvimento de aplicações voltadas a mobilidade, permite desenvolver projetos
computacionais simples e práticos utilizando vários recursos como tabelas, gráficos,
cores, imagens e o envio de informações por meio de comunicação sem fio,
recursos que antes não estavam disponíveis ou não eram possíveis implementá-los
em uma aplicação para dispositivo móvel.
Com base nesse contexto, o presente trabalho tem por objetivo principal
desenvolver um protótipo para acompanhamento de pacientes com hipertensos,
empregando as tecnologias Java. O sistema permitirá que o paciente envie dados
referentes à sua pressão arterial via dispositivo móvel e que o médico, através de
comandos enviados a um servidor, realize todos os cadastros, consultas e
alterações referentes aos dados de cada paciente cadastrado no banco de dados,
possibilitando assim acessar e controlar de forma rápida e simples toda e qualquer
operação referente aos pacientes durante o acompanhamento médico.
Com base no objetivo principal deste trabalho, são definidos alguns objetivos
específicos: Desenvolver uma aplicação para aparelho celular que possibilite acesso
remoto a um servidor, desenvolver uma aplicação web que possibilite enviar
comandos a um servidor e realizar operações no banco de dados, disponibilizar
outra forma de monitoramento da pressão arterial sem a necessidade da presença
do paciente no consultório médico, e proporcionar ao aluno conhecimentos
necessários e satisfatórios para atuação no mercado de trabalho.
14
1 REVISÃO BIBLIOGRÁFICA
1.1 PRESSÃO ARTERIAL
Segundo Moreira (1981), a pressão arterial é o resultado de três fatores
principais, tais como o bombeamento cardíaco, a elasticidade das artérias e a
resistência oferecida pela artéria de médio e pequeno calibre situada na periferia do
corpo. A pressão sistólica é o resultado obtido durante a fase de bombeamento
cardíaco que através da contração da musculatura do coração lança o sangue na
circulação. Essa fase definida como sístole faz com que o sistema circulatório atinja
um valor máximo, esse valor é comumente chamado de pressão máxima.
Durante a fase da sístole a pressão produzida pelo volume de sangue
injetado na corrente sanguínea faz com que as artérias se dilatem permitindo a sua
passagem, entre o final dessa fase e o início da próxima, o coração tem um breve
repouso e nesse momento acontece a ação de contração das artérias que ao
tentarem retornar para a posição original, gera uma força que mantém a pressão
arterial e o fluxo sanguíneo. A força exercida pelo sangue contra a parede das
artérias e a resistência oferecida a ele pelas artérias da periferia resulta em um valor
mínimo que é chamado de pressão mínima e definido como pressão diastólica.
1.1.1 Níveis de Pressão Arterial
Vários fatores como, idade, sexo, estado emocional, etc., determinam que o
nível da pressão arterial varie de uma pessoa para outra, de modo geral tomando
como base um indivíduo jovem que encontra-se em condições normais de saúde a
sua pressão sistólica será em torno de 120 milímetros de mercúrio (mmHg) e a
diastólica em torno de 70 ou 80mmHg, em indivíduos idosos a pressão sanguínea
apresenta um aumento de cerca de 20mmHg na sistólica e 10mmHg na diastólica, o
quadro 1.1 apresenta a fórmula para cálculo da pressão arterial nas diversas idades.
(MOREIRA, 1981)
15
Quadro 1.1 – Fórmula para calculo da pressão ideal nas diversas idades
Fonte: Moreira, 1981, p. 351
1.1.2 Classificação
A classificação da pressão arterial tem por finalidade determinar os níveis de
pressão
arterial
apresentados
por
grupos
de
pacientes
que
apresentem
características similares. Segundo a Revista Brasileira de Hipertensão (2010), o que
é mostrado no quadro 1.2, indica os níveis para a classificação da pressão arterial
de acordo com a medida casual no consultório.
Quadro 1.2 – Classificação da pressão arterial
Categoria
PA diastólica(mmHg)
PA sistólica(mmHg)
Pressão ótima
< 80
< 120
Pressão normal
< 85
< 130
Pressão limítrofe
85 - 89
130-139
Hipertensão estágio 1
90-99
140-159
Hipertensão estágio 2
100-109
160-179
Hipertensão estágio 3
> ou = 110
> ou = 180
< 90
> ou = 140
Hipertensão sistólica isolada
Fonte: VI Diretrizes Brasileiras de Hipertensão, 2010, p15 (modificado pelo autor)
1.1.3 Hipertensão Arterial Sistêmica (HAS)
A hipertensão arterial sistêmica (HAS) é uma condição clínica multifatorial
caracterizada por níveis elevados e sustentados de pressão arterial (PA).
Associa-se frequentemente a alterações funcionais e/ou estruturais dos
órgãos-alvo (coração, encéfalo, rins e vasos sanguíneos) e a alterações
metabólicas,
com
consequente
aumento
do
risco
de
eventos
16
cardiovasculares
fatais
e
não-fatais.
(REVISTA
BRASILEIRA
DE
HIPERTENSÃO. Jan/Mar, 2010, p.7)
A HAS pode ser também definida por Hipertensão Arterial (HTA) e
classificada como uma doença causada pelo aumento constante da pressão
sanguínea além dos níveis considerados normais. O fato de uma pessoa apresentar
a sua pressão arterial acima dos níveis tidos como normais, não a classifica como
hipertensa. Para que um indivíduo adulto seja considerado como hipertenso, é
necessário que após um período de monitoramento o valor da pressão arterial
sistólica seja igual ou superior a 140 mmHg ou a pressão arterial diastólica seja igual
ou superior a 90 mmHg. Para fins de diagnóstico, prognóstico ou tratamento médico,
pessoas acima de 18 anos devem apresentar pressão arterial sistólica inferior a 130
mmHg e pressão arterial diastólica inferior a 85 mmHg. (REVISTA BRASILEIRA DE
HIPERTENSÃO, 2010).
Os valores indicados para classificação e segmento para acompanhamento
de pacientes hipertensos são apresentados no quadro 1.3.
Quadro 1.3 – Classificação e segmento para acompanhamento de pacientes
hipertensos
Fonte: Revista Brasileira de Hipertensão, 2010, p14 (modificado pelo autor)
1.1.3.1 HAS e Suas Complicações
Considerada uma doença silenciosa, pois muitos dos seus sintomas não são
claramente identificáveis e, de acordo com estudos apresentados pela revista
brasileira de hipertensão (2010), a prevalência da HAS nas cidades brasileiras está
17
acima de 30% e é considerada um dos mais importantes problemas de saúde
publica, estando associada a um grande número de óbitos e internações. A HAS é o
agente que provoca, antecipa, influencia e muitas vezes agrava outras doenças
como: cardíacas, cerebrais, renais e oculares.
1.2 LINGUAGEM DE MODELAGEM UNIFICADA (UML)
1.2.1 Histórico da UML
O início da linguagem orientada a objeto foi um pouco lento, contudo ela
cresceu a medida que possibilitou cada vez mais o desenvolvimento de projetos
grandiosos e complexos. Essa complexidade exigiu a pesquisa e criação de
metodologias e modelos para a análise orientada a objetos com a finalidade de
planejar e projetar a construção de sistemas e representá-los através de modelos.
Graças ao trabalho de vários autores surgiram muitos modelos, entretanto as
propostas apresentadas possuíam muitas qualidades e algumas deficiências, por
isso não atendiam plenamente o que buscavam os construtores de softwares.
(FOWLER; KENDAL, 2000)
Durante anos, vários autores trabalharam arduamente em pesquisas com o
intuito de se construir um método pessoal para a orientação a objetos, passando de
um número de dez métodos nas décadas de 70 e 80, para cinquenta entre o final
dos anos 80 e meados dos anos 90. Com o aumento dos modelos existentes, ficou
complicado dar continuidade a manutenção da orientação a objetos, tomando como
exemplo: era necessário conhecer as várias formas de se construir um diagrama de
classes e o grande volume de modelos existentes na época tornava isso impossível.
(MEDEIROS, 2004)
A busca incessante por um padrão de construção de software orientado a
objetos, fez com que três autores com seus respectivos métodos pessoais, se
unissem em meados dos anos 90 unificando suas ideias em um único modelo o qual
nomearam de Método Unificado e em 1996 deram o nome definitivo de Unified
Modeling Language, mais conhecida pelo acrônimo de UML. Os referidos autores
18
eram Ivar Jacobson que valorizava a descrição de requisitos, Grady Booch que se
prestava a fase do projeto e Jim Rumbaugh que se destacava na fase de análise.
Em 1999 a organização Object Management Group (OMG), adotou a UML e busca
desde então torná-la um padrão para a modelagem de objetos e componentes na
produção de softwares. (MEDEIROS, 2004)
1.2.2 Objetivos da UML
O foco central da UML é fazer a descrição de qualquer tipo de sistema, em
forma de diagramas, permitindo que os desenvolvedores aproveitem ao máximo os
conceitos da orientação a objetos com o mínimo de dependência na busca de
resultados em seus projetos, para isso fazem uso dos vários diagramas que
constituem a linguagem para detalhar passo a passo as informações sobre
elementos de um modelo, concentrando-se em um ponto do sistema por vez. O
resultado é um conjunto de diagramas que auxiliam na visualização do desenho final
do sistema, na comunicação entre os objetos e na representação de cada parte do
sistema. (FURLAN, 1998)
Alguns dos objetivos da UML são: aplicá-la ao mundo real e ao ambiente de
desenvolvimento de software para descrever modelos de sistema em forma de
diagramas baseados em conceitos de orientação a objeto, permitir facilidades de
modelagem através de uma linguagem orientada a objetos e aplicar e integrar as
melhores práticas no desenvolvimento de sistemas orientados a objetos.
1.2.3 A Notação da Linguagem
Um modelo de elemento é cada representação utilizada pelos diagramas.
Cada modelo de elemento possui uma definição própria com seu significado exato e
uma representação gráfica, e regras que definem a sua utilização. Podemos citar
como exemplo de modelo de elemento as classes, objetos, estados, pacotes e
19
componentes. Outro modelo de elemento é o relacionamento utilizado para conectar
um modelo ao outro. (ALMEIDA; DAROLT, 2001)
1.2.4 Diagramas da UML
Os diagramas são os gráficos que descrevem o conteúdo em uma visão, a
combinação dos diagramas existentes na UML, representa todas as visões de um
sistema, de acordo com Medeiros (2004) alguns dos diagramas integrantes da UML
2.0 são: diagrama de atividades, caso de uso, classe, objetos, sequência,
comunicação – colaboração, estado, pacotes, componentes, implantação, interação
– visão geral.
1.2.4.1 Diagrama de Atividade
Descreve as regras de negócio de alto nível, incluindo fluxo de dados. Pode
ser ainda utilizado para descrever lógicas complexas em um sistema. A figura 1.1
demonstra um exemplo de diagrama de atividades.
Figura 1.1 – Exemplo de diagrama de atividade
Fonte: Elaborado pelo autor
20
1.2.4.2 Diagrama de Caso de Uso
Descreve a interação entre o usuário e o sistema ou mesmo parte do sistema
ou de outro sistema com o mesmo. O quadro 1.4 descreve a sequência para o caso
de uso cadastrar aluno e a figura 1.2 demonstra o diagrama de caso de uso
consultar aluno.
Quadro 1.4 – Exemplo de descrição de caso de uso
Descrição do caso de uso: 01 cadastrar aluno
Este caso de uso é responsável pelo cadastro de alunos.
Curso Normal
a. Aluno solicita cadastro
b. Atendente solicita documentos de identificação
c. Aluno entrega documento de identificação
d. Sistema verifica se o aluno é cadastrado
e. Atendente solicita opção de cadastro de aluno
f. O sistema emite msg:01 “Aluno cadastrado com sucesso”
Cursos Alternativos
Caso c. Aluno falta documento
c.1 Finaliza cadastro e abandona caso de uso
Caso d. Aluno já é cadastrado
d.1. Atualizar cadastro de aluno
d.1.1. Atendente altera os dados do aluno
d.1.2. O sistema atualiza o aluno e emite msg: 02 “Alteração realizada com
sucesso!”.
d.2. Sistema fecha cadastro abandona o caso de uso e emite a msg: 03
“operação não realizada”.
Fonte: Elaborado pelo autor
Figura 1.2 – Exemplo de diagrama de caso de uso
Fonte: Elaborado pelo autor
21
1.2.4.3 Diagrama de Classes
Descreve uma coleção de classes de objetos com seus tipos, conteúdos e
relacionamentos. A figura 1.3 exemplifica um diagrama de classes.
Figura 1.3 – Exemplo de diagrama de classe
Fonte: Elaborado pelo autor
1.2.4.4 Diagrama de Sequência
Modela a lógica sequencial de um negócio, em consequência da ordenação
das mensagens na linha do tempo. Veja na figura 1.4 um exemplo de diagrama de
sequencia.
Figura 1.4 – Exemplo de diagrama de sequência
Fonte: Elaborado pelo autor
22
1.3 BANCO DE DADOS
1.3.1 Definição
Um banco de dados pode ser definido como um conjunto de dados
devidamente relacionados. Podemos compreender como dados os objetos
conhecidos que podem ser armazenados e que possuem um significado
implícito. (MACHADO, 2010 p.20)
1.3.2.1 Modelo Conceitual
Representa, descreve a realidade do ambiente do problema, constituindo-se
em uma visão global dos principais dados e seus relacionamentos
(estruturas de informação), completamente independente dos aspectos de
sua implementação tecnológica. (MACHADO, 2010 p. 20)
Este modelo é o ponto de partida, a etapa inicial de um projeto de banco de
dados, deve captar e retratar toda a realidade, fornecendo uma descrição de alto
nível do ambiente analisado e apresentando uma visão clara das regras de negócio.
De acordo com Machado (2010), o modelo conceitual mostra a estrutura dos dados,
sem vínculo com o banco de dados ou sistema gerenciador de banco de dados que
será utilizado. Este modelo é representado graficamente através do modelo
conceitual, mostrado na figura 1.5.
Figura 1.5 – Exemplo de modelo conceitual.
Fonte: Elaborado pelo autor
1.3.2.2 Modelo Lógico
23
O modelo lógico é uma evolução do modelo conceitual, neste momento é
necessário definir a abordagem da tecnologia do sistema gerenciador de banco de
dados (hierárquica, rede, relacional ou orienta a objetos) que será aplicada ao
modelo. Após a escolha do tipo de abordagem, ocorre a descrição da estrutura do
banco de dados, para essa descrição é utilizado o diagrama de entidaderelacionamento, mostrado na figura 1.6. (MACHADO, 2010)
Figura 1.6 – Exemplo de diagrama modelo entidade-relacionamento.
Fonte: Elaborado pelo autor
1.3.2.3 Modelo Físico
O modelo físico tem como base o modelo lógico, aqui já ocorre uma
dependência total do SGBD que será utilizado, pois são definidas as características
como: dimensões dos campos, índices que serão utilizados, tipo de dados de cada
campo, formando a estrutura física de armazenamento. A figura 1.7 apresenta um
exemplo de diagrama de estrutura de dados. (MACHADO, 2010).
Figura 1.7 – Exemplo de diagrama de estrutura de dados.
Fonte: Elaborado pelo autor
24
1.3.3 Banco de dados Relacional
O banco de dados relacional foi idealizado por Cod em 1970 com o propósito
de tornar o mundo mais simples na visão dos usuários e dar aos SGBDs a
capacidade de processar os dados de forma mais eficiente. O modelo de banco de
dados relacional representa seus dados por meio de um conjunto de relações. Essas
relações são denominadas tabelas e possuem como função armazenar informações
sobre os dados e seus relacionamentos. Uma tabela é estruturada por linhas e
colunas, cada linha de uma tabela faz referencia a um conjunto de dados de
diferentes tipos. Cada coluna de uma tabela faz referência a um conjunto de valores
que devem pertencer a um mesmo tipo de dado. A junção de uma linha e uma
coluna representam um campo, que contém algum valor. O conjunto de valores que
um campo pode representar é chamado de domínio. O conjunto de valores que cada
campo assume em um determinado momento consiste na instância de uma tabela.
(MACHADO, 2010)
Tabela de Aluno
Código
Nome
Curso
Telefone
111
José Carlos
Banco de dados
(14) 1111 – 2222
222
Antonio Marcos
Logística
(15) 3333 – 4444
333
Laura Santos
Redes
(16) 5555 - 6666
Figura 1.8 – Exemplo de tabela de banco de dados.
Fonte: Elaborado pelo autor
1.4 TECNOLOGIAS JAVA
1.4.1 Plataforma Java
A plataforma Java é constituída de uma linguagem de programação orientada
a objetos, que se utiliza das interfaces de programação de aplicativos (APIs), e de
25
uma máquina virtual Java (JVM). As APIs são um conjunto de classes e interfaces
com funcionalidades já implementadas disponibilizadas pela SUN ou por
programadores que a desenvolvem ao redor do mundo. A JVM tem a função de
interpretar um programa escrito em Java permitindo a sua execução em qualquer
computador que possua uma JVM instalada. (ORACLE, 2011)
1.4.2 Distribuições da tecnologia Java
Existem três distribuições para a tecnologia Java, Java Standart Edition (JSE),
Java Enterprise Edition (JEE) e Java Micro Edition. (NETO, 2009)
1.4.2.1 Java Standard Edition (JSE)
Plataforma Java para o desenvolvimento de aplicações para computadores
pessoais (Personal Computer - PC). As demais plataformas Java (JEE e JME),
derivaram desta. JSE disponibiliza diversos recursos, como por exemplo: interface
gráfica de usuário, gráficos 2D e 3D, operações de áudio e de acessibilidade.
(ORACLE, 2011)
1.4.2.2 Java Enterprise Edition (JEE)
A plataforma Java EE é construída em cima da plataforma Java SE, ela
fornece uma API e um ambiente de execução para o desenvolvimento de aplicações
de rede multicamadas, escalonável, confiável e segura, oferece um suporte à parte
visual (interface), desenvolvimento e implantação das aplicações baseadas em
componentes. Os componentes do JEE estão divididos em: Aplicações cliente e
applets, Java Servlets e Java Server Pages (JSP), Enterprise JavaBeans (EJB).
26
Esses componentes também podem recuperar dados armazenados, processá-los e
enviá-los para as aplicações. (ORACLE, 2011)
1.4.2.3 Java Micro Edition (JME)
É um conjunto de APIs Java, voltado ao desenvolvimento de aplicativos
capazes de rodarem em dispositivos com baixo poder de processamento e memória,
no caso dos celulares, PDAs, controle remoto. (ORACLE, 2011)
Por causa da diversidade dos aparelhos, a camada de configuração do JME
está dividida em CLDC (Connected Limited Device Configuration) e CDC (Connected
Device Configuration). O CLDC é utilizado em dispositivos que possuem uma
capacidade de memória muito baixa, variando de 128KB a 512KB para memória
ROM e 32KB para memória RAM, possui também uma interface restrita com o
usuário, um display pequeno, utiliza-se de uma conectividade de rede nos
dispositivos móveis, sem fio, com largura de banda baixa e acesso intermitente e,
ainda é alimentado por bateria no caso dos celulares. O CDC foi desenvolvido para
dispositivos com mais capacidade de processamento, utiliza no mínimo, 512KB de
memória ROM para poder executar o Java e 256KB de memória RAM em tempo de
execução, permitem interfaces gráficas elaboradas e permite ter uma conexão de
rede e largura de banda bem mais alta e persistente. (MUCHOW, 2004)
O JME possui também os perfis, que é uma extensão da camada de
configuração, ele possibilita o desenvolvimento de aplicações, disponibilizando um
conjunto de APIs destinadas a um tipo de aparelho. Esse conjunto de APIs, quando
combinadas, definem o ciclo de vida da aplicação, a interface com o usuário e o
acesso às propriedades específicas do aparelho. (ORACLE, 2011)
A Java Community Proccess (JCP) define alguns tipos de perfis para o Java,
neste trabalho é citado apenas o Mobile Information Device Profile (MIDP), devido
sua abordagem em relação aos dispositivos para o qual o sistema será desenvolvido
e a sua necessidade para o desenvolvimento do projeto da comanda móvel. O MIDP
que, atualmente, possui duas versões: a versão MIDP 1.0 suportada por todos os
aparelhos da atualidade e a versão MIDP 2.0 que ainda encontra-se em fase de
27
testes e é suportada por um número pequeno de aparelhos como celulares e PDAs.
(CARNIEL; TEIXEIRA, 2005)
Para usar o JME nos aparelhos, os mesmos têm que trabalhar com dois tipos
de arquivos, os que têm a extensão jad (Java Application Descriptor), arquivo
utilizado para descrever o aplicativo, onde dentro dele estão localizadas as
informações referente ao fabricante, versão e link para o .jar; e os arquivos com
extensão jar (Java Archive), que são todas as classes compiladas, imagens usadas
na aplicação.(CARNIEL; TEIXEIRA, 2005)
1.4.3 Servlets
São aplicações feitas em Java que são executadas no lado do servidor,
permitindo que as funcionalidades do servidor Web sejam estendidas. O servlet
utiliza a funcionalidade de servidores request response, permitindo uma interação
com o cliente. Os métodos init(), service() e destroy(), determinam o ciclo de vida de
um servlet. O init() aloca recursos, o service() faz com que múltiplas requisições
sejam executadas de forma simultânea, o destroy() utilizado quando o servidor
apaga uma instância do Servlet, não sendo chamado a cada nova requisição.
(NETO, 2009)
1.4.4 Persistência de dados em Java
O processo de construção de uma aplicação Java com interface (gráfica ou
não) usando um repositório de armazenamento de informações para os
objetos que devem ser persistentes é orientado pelos critérios de
funcionalidade e responsabilidade. (NETO, 2009, p. 232)
Segundo Neto (2009), para uma melhor organização da estrutura de uma
aplicação Java, é importante definir e separar suas camadas, de acordo com suas
funcionalidades e responsabilidades: As classes de negócio (model ou modelo) são
28
responsáveis por armazenar dados nos atributos e permitem a execução das
funções (métodos).
As classes que devem garantir os mecanismos de persistência são chamadas
de classes de acesso a objeto ou Data Access Object (DAO), As classes de interface
devem prover a usabilidade da aplicação permitindo a execução das chamadas das
classes de persistência e ao modelo, as classes de serviço de negócio permitem que
uma aplicação Java migre entre as plataformas fazendo uma ponte entre a interface
gráfica, o modelo e a persistência. (NETO, 2009)
1.4.4.1 Hibernate
É um framework escrito em Java para auxiliar na persistência de dados, ele
permite o mapeamento do atributo ou classe de modo que os dados sejam
persistidos como se fossem objetos. Hibernate implementa a Java Persistence API
(JPA), destinada apenas para persistência, a JPA proporciona a combinação de
módulos do Hibernate, core, annotations e entityManager. (ALGAWORKS, 2010)
1.4.5 JavaServer Faces (JSF)
É uma tecnologia para desenvolvimento web foi definida pelo Java
Community Process (JCP), como um padrão de desenvolvimento. JSF utiliza o
conceito de componentes para criação de interfaces gráficas e é baseado no padrão
MVC, que separa a visualização das regras de negócio. Este padrão define três
responsabilidades para o sistema, o modelo que é responsável por representar os
objetos do negócio e permitir acesso aos dados. A visão se encarrega da interface,
definindo a apresentação dos dados e encaminhando as ações do usuário ao
controlador. Ao controle cabe ligar o modelo a visão, atendendo as solicitações e
devolvendo as respostas. (ALGAWORKS, 2010)
1.4.5.1 PrimeFaces
29
É um framework desenvolvido pela Prime Teknoloji, uma empresa turca. Esta
ferramenta possui um conjunto de componentes destinados ao JSF e para realizar
chamadas assíncronas ao servidor já tem implementado por padrão o Ajax, isso
diminui consideravelmente o esforço do desenvolvedor. O PrimeFaces possui
também uma variedade de temas, que permite mudar a aparência dos componentes
de forma fácil e simples. (PRIMEFACES, 2011)
1.5. DISPOSITIVOS MÓVEIS
Os dispositivos móveis, celulares, smartphones, PDA, notebook, estão cada
vez mais presentes em nosso dia-a-dia, estes aparelhos geralmente são compactos,
possuem uma pequena tela e alguns possuem tela sensível ao toque, e também um
teclado que possibilita a entrada de informações, eles se popularizaram graças a
tecnologia atual que permitiu uma invasão do mercado com uma variedade de
modelos e funcionalidades, isso, sem dúvida conquistou os consumidores.
(DEVMEDIA, 2011)
Os primeiros projetos para celulares foram apresentados na década de 70 e
no início da década de 80 foram comercializados os primeiros modelos. Com o
avanço dos meios de comunicação e a transmissão de dados realizada por meio de
satélites, o telefone celular se tornou algo economicamente viável no inicio da
década de 90 e a partir daí, a evolução foi constante e hoje o mercado possui
aparelhos com recursos tecnológicos altamente avançados, como por exemplo,
localização através de satélite (GPS – Global Positioning System). (PORTAL SÃO
FRANCISCO, 2011)
1.5.1. Celular no Brasil
De acordo a Agência Nacional de Telecomunicações , em 1990 foi lançado no
rio de janeiro o primeiro aparelho celular do Brasil. No mesmo ano, foram
comercializados 667 aparelhos, no ano seguinte, saltou para 6.700 unidades.
30
Atualmente no Brasil existem cidades onde o número de aparelhos celulares
ultrapassa o número de habitantes.
Quadro 1. 5 – Crescimento da telefonia celular
Fonte: Anatel, 2011.
Notícia publicada no portal da Anatel em 25 de maio de 2011, destacava o
seguinte: “Brasil fecha abril com 212,6 milhões de acessos móveis”. Nos quatro
primeiros meses do ano, o Serviço Móvel Pessoal (SMP) registrou 9,6 milhões de
novas habilitações (crescimento de 4,74% no ano) e teledensidade de 109,32
acessos por 100 habitantes (crescimento de 4,43% no ano), esse crescimento é o
maior em 11 anos e uma outra confirmação foi que em abril de 2011, dezessete
Estados Brasileiros já possuíam mais de um celular por habitante, provando que
esta é uma ferramenta importante e cada vez mais presente na sociedade.
(ANATEL, 2011)
1.6 FERRAMENTAS INTEGRATED DEVELOPMENT ENVIRONMENT (IDE)
O que nos auxilia e muito no desenvolvimento de aplicações é um editor, no
caso uma IDE, ou seja, um software que integra um conjunto de recursos com o
intuito de facilitar o trabalho dos programadores, facilitando a digitação e
31
implementação do sistema em desenvolvimento, através do código da linguagem
escolhida. Na maioria das vezes, uma IDE é basicamente composta por um editor de
código-fonte que reconhece as expressões reservadas, um compilador, um
depurador e demais recursos específicos.
Vale ressaltar que existem diversas ferramentas de desenvolvimento Java,
cada uma atendendo as especificações que seus desenvolvedores julgaram mais
úteis. De fato a melhor ferramenta é aquela que o programador tem conhecimento e
uma melhor intimidade e, neste trabalho foi utilizado o NetBeans.
1.6.1 NetBeans
É um projeto de código aberto com suporte para aplicações Java e também
para HTML, C, C++, JSP, JSF entre outros. Possui várias versões gratuitas e
comerciais e atualmente se encontra na versão 7.0.1. Integra as tecnologias JSP,
XML, RMI, CORBA, JINI, JDBC e Servlet; suporte a Ant, CVS e outros sistemas de
controle de versão, além de disponibilizar suporte para compiladores e depuradores,
assistentes,
e
ferramentas
(NETBEANS, 2011)
para
geração
automática
de
alguns
códigos.
32
2 ANÁLISE E PROJETO DE SISTEMA
2.1 ANÁLISE DE NEGÓCIO
2.1.1 Instrução do Problema
As instituições de saúde, sejam elas públicas ou privadas, afirmam que o
acompanhamento da pressão arterial é importante para a qualidade de vida do ser
humano. Por exemplo, no Brasil cerca de 30 milhões de pessoas possuem um grau
de hipertensão, muitas vezes o acompanhamento destes indivíduos se torna difícil
devido a localização ou falta de tempo para se deslocar até um consultório médico
ou posto de saúde, além do mais, os prontuários preenchidos manualmente não
permitem agilidade na busca dos registros e quando o médico está fora do local de
trabalho não tem como saber a atual situação do seu paciente. Tudo isso dificulta e
as vezes até representa uma ausência de informações para um diagnóstico médico
claro e preciso, principalmente em situações de emergência quando o paciente
necessita de um apoio médico, em sua residência ou qualquer outro local longe de
uma clínica. (PORTAL SAÚDE, 2011)
2.1.2 Atores e Envolvidos no Processo
Médico:
Deve conhecer o funcionamento do Sistema e do preenchimento das
informações.
Paciente:
Deve conhecer básico para envio das informações sobre sua pressão arterial
via celular.
Secretária:
Deve conhecer o funcionamento do sistema e do preenchimento das
informações.
33
2.1.3 Descrição do Ambiente Atual
Para que seja realizado o acompanhamento da pressão arterial é necessário
que o paciente mesmo que possua em sua residência um aparelho de aferição, se
desloque até um consultório, clínica médica outra unidade de saúde para que sua
pressão arterial seja aferida e anotada em seu prontuário.
2.2 ANÁLISE DE REQUISITOS
2.2.1 Análise de Requisitos Funcionais
2.2.1.1 Lista de Casos de uso
Quadro 1.6 – Lista de caso de uso
Nº
Descrição
Evento
Caso de uso
UC 1
Paciente solicita um cadastro na
clínica
DadosPaciente
Cadastrar paciente
UC 2
Médico é admitido para atender na
clínica
DadosMedico
Cadastrar médico
UC 3
Secretária é admitida para trabalhar
na clínica
DadosSecretária
Cadastrar secretária
UC 4
Empresa de convênio solicita parceria
DadosConvenio
Cadastrar convênio
UC 5
Manter procedimentos
Dados
Procedimento
Cadastrar procedimento
UC 6
Paciente solicita uma consulta médica
DadosAgenda
Agendar consulta
UC 7
Manter histórico do paciente
DadosProntuario
Registrar prontuário
UC 8
Paciente envia dados de sua pressão
arterial
dadosPressao
Registrar aferição
Fonte: Elaborado pelo autor
34
2.2.2 Casos de Uso
Caso de Uso UC 1. Cadastrar Paciente
Este caso de uso é responsável pelo cadastro de um paciente.
Curso Normal:
UC 1.1 O paciente solicita cadastro
UC 1.2 A secretária acessa a visão paciente.
UC 1.3 A secretária informa os dados do paciente.
UC 1.4 O sistema verifica se o paciente já está cadastrado.
UC 1.5 O sistema adiciona um novo paciente e exibe a msg01 “Paciente cadastrado
com sucesso!”.
UC 1.6 Encerrar caso de uso.
Cursos Alternativos:
UC 1.4.1 Caso o paciente já conste no cadastro.
UC 1.4.1.2 O sistema oferece a opção de atualização.
UC 1.4.1.3 O sistema obtém os dados do paciente.
UC 1.4.1.4 O sistema atualiza os dados do paciente e emite msg02 “Alteração
realizada com sucesso!”.
UC 1.4.1.5 Abandonar caso de uso.
UC 1.4.2 Caso o paciente já conste no cadastro e deseja-se excluí-lo.
UC 1.4.2.1 O sistema exclui o paciente e emite msg03 “Exclusão realizada com
sucesso!”.
UC 1.4.2.3 Abandonar caso de uso.
Figura 2.1 – Diagrama de Caso de Uso: Cadastrar Paciente
Fonte: Elaborado pelo autor
35
Figura 2.2 – Diagrama de sequência: Cadastrar Paciente.
Fonte: Elaborado pelo autor.
Figura 2.3 – Diagrama de atividades: Cadastrar Paciente.
Fonte: Elaborado pelo autor
36
Figura 2.4 – Diagrama de MVC: Cadastrar Paciente.
Fonte: Elaborado pelo autor
Caso de Uso UC 2. Cadastrar Médico
Este caso de uso é responsável pelo cadastro de um médico.
Curso Normal:
37
UC 1.1 O médico solicita cadastro
UC 1.2 A secretária acessa a visão médico.
UC 1.3 A secretária informa os dados do médico.
UC 1.4 O sistema verifica se o médico já está cadastrado.
UC 1.5 O sistema adiciona um novo médico e exibe a msg01 “Médico cadastrado
com sucesso!”.
UC 1.6 Encerrar caso de uso.
Cursos Alternativos:
UC 1.4.1 Caso o médico já conste no cadastro.
UC 1.4.2 O sistema oferece a opção de atualização.
UC 1.4.3 O sistema obtém os dados do médico.
UC 1.4.4 O sistema atualiza os dados do médico e emite msg02 “Alteração realizada
com sucesso!”.
UC 1.4.5 Abandonar o caso de uso.
UC 1.4.1.1 Caso o médico já conste no cadastro e deseja-se excluí-lo.
UC 1.4.1.2 O sistema exclui o médico e emite msg03 “Exclusão realizada com
sucesso!”.
UC 1.4.1.3 Abandonar o caso de uso.
Figura 2.5 – Diagrama de Caso de uso: Cadastrar médico
Fonte: Elaborado pelo autor.
38
Figura 2.6 – Diagrama de sequência: Cadastrar Médico
Fonte: Elaborado pelo autor
Figura 2.7 – Diagrama de atividades: Cadastrar médico
Fonte: Elaborado pelo autor
39
Figura 2.8 – Diagrama de MVC: Cadastrar Médico.
Fonte: Elaborado pelo autor
Caso de Uso UC 3. Cadastrar Secretária
Este caso de uso é responsável pelo cadastro de uma secretária.
Curso Normal:
UC 1.1 Uma secretária é admitida.
UC 1.2 A secretária acessa a visão secretária.
UC 1.3 A secretária informa os dados da secretária.
UC 1.4 O sistema verifica se a secretária já está cadastrada.
UC 1.5 O sistema adiciona uma nova secretária e exibe a msg01 “Secretária
cadastrada com sucesso!”.
UC 1.6 Encerrar caso de uso.
40
Cursos Alternativos:
UC 1.4.1 Caso a secretária já conste no cadastro.
UC 1.4.2 O sistema oferece a opção de atualização.
UC 1.4.3 O sistema obtém os dados da secretária.
UC 1.4.4 O sistema atualiza os dados da secretária e emite msg02 “Alteração
realizada com sucesso!”.
UC 1.4.5 Abandonar o caso de uso.
UC 1.4.1.1 Caso a secretária já conste no cadastro e deseja-se excluí-la.
UC 1.4.1.2 O sistema exclui a secretária e emite msg03 “Exclusão realizada com
sucesso!”.
UC 1.4.1.3 Abandonar o caso de uso.
Figura 2.9 – Diagrama de Caso de uso: Cadastrar Secretária
Fonte: Elaborado pelo autor
Figura 2.10 – Diagrama de sequência: Cadastrar Secretária
Fonte: Elaborado pelo autor
41
Figura 2.11 – Diagrama de atividades: Cadastrar Secretaria
Fonte: Elaborado pelo autor
Figura 2.12 – Diagrama de MVC: Cadastrar Secretária.
Fonte: Elaborado pelo autor
42
Caso de Uso UC 4. Cadastrar Convênio
Este caso de uso é responsável pelo cadastro de um convênio.
Curso Normal:
UC 1.1 Uma empresa de convênio solicita parceria.
UC 1.2 A secretária acessa a visão convênio.
UC 1.3 A secretária informa os dados da empresa.
UC 1.4 O sistema verifica se a empresa está cadastrada.
UC 1.5 O sistema adiciona um novo convênio e exibe a msg01 “Convênio
cadastrado com sucesso!”.
UC 1.6 Encerrar caso de uso.
Cursos Alternativos:
UC 1.4.1 Caso o convênio já conste no cadastro.
UC 1.4.2 O sistema oferece a opção de atualização.
UC 1.4.3 O sistema obtém os dados do convênio.
UC 1.4.4 O sistema atualiza os dados do convênio e emite msg02 “Alteração
realizada com sucesso!”.
UC 1.4.5 Abandonar o caso de uso.
UC 1.4.1.1 Caso o convenio já conste no cadastro e deseja-se excluí-lo.
UC 1.4.1.2 O sistema exclui o convênio e emite msg03 “Exclusão realizada com
sucesso!”.
UC 1.4.1.3 Abandonar o caso de uso.
Figura 2.13 – Diagrama de Caso de Uso: Cadastrar Convênio
Fonte: Elaborado pelo autor
43
Figura 2.14 – Diagrama de sequência: Cadastrar Convênio
Fonte: Elaborado pelo autor.
Figura 2.15 – Diagrama de atividades: Cadastrar Convênio
Fonte: Elaborado pelo autor
44
Figura 2.16 – Diagrama de MVC: Cadastrar Convênio.
Fonte: Elaborado pelo autor
Caso de Uso UC 5. Cadastrar Procedimento
Este caso de uso é responsável pelo cadastro de um procedimento.
Curso Normal:
UC 1.1 Um novo procedimento será cadastrado
UC 1.2 A secretária acessa a visão procedimento.
UC 1.3 A secretária informa os dados do procedimento.
UC 1.4 O sistema verifica se o procedimento já está cadastrado.
UC 1.5 O sistema adiciona um novo procedimento e exibe a msg01 “Procedimento
cadastrado com sucesso!”.
UC 1.6 Encerrar caso de uso.
Cursos Alternativos:
45
UC 1.4.1 Caso o procedimento já conste no cadastro.
UC 1.4.2 O sistema oferece a opção de atualização.
UC 1.4.3 O sistema obtém os dados do procedimento.
UC 1.4.4 O sistema atualiza os dados do procedimento e emite msg02 “Alteração
realizada com sucesso!”.
UC 1.4.5 Abandonar o caso de uso.
UC 1.4.1.1 Caso o procedimento já conste no cadastro e deseja-se excluí-lo.
UC 1.4.1.2 O sistema exclui o procedimento e emite msg03 “Exclusão realizada com
sucesso!”.
UC 1.4.1.3 Abandonar o caso de uso.
Figura 2.17 – Diagrama de Caso de Uso: Cadastrar Procedimento
Fonte: Elaborado pelo autor
Figura 2.18 – Diagrama de sequência: Cadastrar Procedimento.
Fonte: Elaborado pelo autor.
46
Figura 2.19 – Diagrama de atividades: Cadastrar Procedimento
Fonte: Elaborado pelo autor
Figura 2.20 – Diagrama de MVC: Cadastrar Procedimento.
Fonte: Elaborado pelo autor
47
Caso de Uso UC 6. Agendar Consulta
Este caso de uso é responsável pelo agendamento de uma consulta.
Curso Normal:
UC 1.1 O paciente solicita agendar uma consulta.
UC 1.2 A secretária acessa a visão agenda.
UC 1.3 A secretária seleciona a data desejada.
UC 1.4 O sistema exibe a agenda do dia.
UC 1.5 A secretária informa os dados da agenda.
UC 1.6 O sistema adiciona um novo agendamento e exibe a msg01 “Agendamento
realizado com sucesso!”.
UC 1.7 Encerrar caso de uso.
Cursos Alternativos:
UC 1.3.1 Caso não tenha horário disponível.
UC 1.3.2 A secretária verifica uma nova data.
UC 1.3.3 Retorna ao fluxo 1.4.
Figura 2.21 – Diagrama de Caso de Uso: Agendar Consulta
Fonte: Elaborado pelo autor
48
Figura 2.22 – Diagrama de sequência: Agendar Consulta.
Fonte: Elaborado pelo autor.
Figura 2.23 – Diagrama de atividades: Agendar Consulta
Fonte: Elaborado pelo autor
49
Figura 2.24– Diagrama de MVC: Agendar Consulta.
Fonte: Elaborado pelo autor
50
Caso de Uso UC 7. Registrar Prontuário
Este caso de uso é responsável pelo registro de um prontuário.
Curso Normal:
UC 1.1 O paciente passou pela consulta
UC 1.2 A secretária acessa a visão prontuário.
UC 1.3 A secretária informa os dados do prontuário.
UC 1.4 O sistema verifica se os dados do prontuário.
UC 1.5 O sistema registra um novo prontuário e exibe a msg01 “Prontuário
registrado com sucesso!”.
UC 1.6 Encerrar caso de uso.
Cursos Alternativos:
UC 1.4.1 Caso os dados estejam inválidos.
UC 1.4.2 Retornar ao fluxo 1.3.
Figura 2.25 – Diagrama de Caso de Uso: Registrar Prontuário
Fonte: Elaborado pelo autor
51
Figura 2.26 – Diagrama de sequência: Registrar Prontuário.
Fonte: Elaborado pelo autor.
Figura 2.27 – Diagrama de atividades: Registrar Prontuário
Fonte: Elaborado pelo autor
52
Figura 2.28 – Diagrama de MVC: Registrar Prontuario.
Fonte: Elaborado pelo autor
53
Caso de Uso UC 8. Registrar Aferição
Este caso de uso é responsável pelo registro das aferições referente a pressão
arterial realizadas pelos pacientes e enviadas via celular.
Curso Normal:
UC 1.1 O paciente inicia a aplicação móvel
UC 1.2 Acessa a visão celular.
UC 1.3 Insere os dados.
UC 1.4 escolhe a opção enviar.
UC 1.5 O sistema envia as informações.
UC 1.6 Encerrar caso de uso.
Cursos Alternativos:
UC 1.4.1 Caso os dados estejam inválidos.
UC 1.4.2 Retornar ao fluxo 1.3.
Figura 2.29 – Diagrama de Caso de Uso: Registrar Aferição
Fonte: Elaborado pelo autor
Figura 2.30 – Diagrama de sequência: Registrar Aferição
Fonte: Elaborado pelo autor.
54
Figura 2.31 – Diagrama de atividades: Registrar Aferição
Fonte: Elaborado pelo autor
Figura 2.32 – Diagrama de MVC: Registrar Aferição.
Fonte: Elaborado pelo autor
55
2.2.3 Diagrama de Classes
Figura 2.33 – Diagrama de Classes
Fonte: Elaborado pelo autor.
56
2.2.4 Diagrama Modelo Entidade-Relacionamento
Figura 2.34 – Diagrama Modelo Entidade-Relacionamento
Fonte: Elaborado pelo autor.
57
2.2.5 Diagrama de Estrutura de Dados
Figura 2.35 – Diagrama de Estrutura de Dados
Fonte: Elaborado pelo autor.
58
3 IMPLEMENTAÇÃO E TESTES
Seguindo o que foi especificado na análise e para atender as funcionalidades
do sistema e visando a sua organização, para a implementação deste trabalho as
classes foram separadas em pacotes como apresentado na figura 3.1. O diretório
páginas Web organiza as páginas responsáveis pela interface (visão), o diretório
pacotes de código fonte organiza os pacotes responsáveis pelas regras de negócio,
manipulação de objetos e alguns arquivos de configuração.
- o pacote padrão especifica a classe hibernate.cfg.xml, responsável pela
configuração de conexão com o base de dados.
- o pacote controller especifica as classes que controlam a comunicação da
interface com a aplicação.
- o pacote dao especifica as classes responsáveis pela persistência e ou
apresentação dos dados.
- o pacote model especifica as classes responsáveis pela manipulação dos
objetos, controlando as suas transformações ou instanciando novos objetos.
- o pacote util é responsável pela fábrica de conexões, instanciando ou
encerrando uma sessão.
Figura 3.1 – Organização dos pacotes da aplicação
Fonte: Elaborado pelo autor.
59
3.1 INTERFACES GRÁFICAS(TELAS)
3.1.1 Tela inicial
Ao iniciar a aplicação, a tela inicial do sistema apresenta a agenda diária e um
menu que permite o acesso as demais telas de gerenciamento da aplicação,
conforme mostrado na figura 3.2.
Figura 3.2 – Tela inicial
Fonte: Elaborado pelo autor.
3.1.2 Tela para gerenciamento de agenda
A tela para gerenciamento de agenda permite realizar as operações
60
referentes ao agendamento, alteração e exclusão de agendamento, conforme
mostrado na figura 3.3.
Figura 3.3 – Tela para gerenciamento da agenda diária
Fonte: Elaborado pelo autor.
3.1.3 Tela para gerenciamento de convênios
A tela para gerenciamento de convênios permite realizar as operações
referentes ao cadastro, alteração e exclusão de convênios, conforme mostrado na
figura 3.4.
Figura 3.4 – Tela para gerenciamento de convênios
Fonte: Elaborado pelo autor.
61
3.1.4 Tela para gerenciamento de médicos
A tela para gerenciamento de médicos permite realizar as operações referentes
ao cadastro, alteração e exclusão de médicos, conforme mostrado na figura 3.5.
Figura 3.5 – Tela para gerenciamento de médicos
Fonte: Elaborado pelo autor.
3.1.5 Tela para gerenciamento de pacientes
A tela para gerenciamento de pacientes permite realizar as operações
referentes ao cadastro, alteração e exclusão de pacientes, conforme mostrado na
figura 3.6.
Figura 3.6 – Tela para gerenciamento de pacientes
Fonte: Elaborado pelo autor.
62
3.1.6 Tela para gerenciamento de secretárias
A tela para gerenciamento de secretárias permite realizar as operações
referentes ao cadastro, alteração e exclusão de secretárias, conforme mostrado na
figura 3.7.
Figura 3.7 – Tela para gerenciamento de secretárias
Fonte: Elaborado pelo autor.
3.1.7 Tela para gerenciamento de procedimentos
A tela para gerenciamento de procedimentos permite realizar as operações
referentes ao cadastro, alteração e exclusão de procedimentos, conforme mostrado
na figura 3.8.
Figura 3.8 – Tela para gerenciamento de procedimentos
Fonte: Elaborado pelo autor.
63
3.1.8 Tela para gerenciamento de relatórios
A tela para gerenciamento de relatórios permite realizar as operações
referentes a relatórios de agendamentos, prontuários, procedimentos, pacientes,
médicos, secretárias e convênios, conforme mostrado na figura 3.9.
Figura 3.9 – Tela para gerenciamento de relatórios
Fonte: Elaborado pelo autor.
3.1.9 Tela para envio de aferição via celular
A tela para envio de aferição da pressão arterial permite ao paciente inserir os
dados nos campos do formulário e enviá-los via celular, conforme mostrado na figura
3.10.
Figura 3.10 – Tela para envio das aferições via celular
Fonte: Elaborado pelo autor.
64
4 CONSIDERAÇÕES FINAIS
4.1 CONCLUSÃO
As tecnologias indicadas e exemplificadas pelo orientador, por estarem de
acordo com a necessidade do mercado e atenderem as minhas expectativas em
relação ao curso. Dentre estas tecnologias destacam-se a JME (Java Micro Edition),
JPA (Java Persistence API), Hibernate, JSF (JavaServer Faces) e o Primefaces,
além das ferramentas utilizadas para a fase de análise e de implementação. As
tecnologias e ferramentas são encontradas gratuitamente, e o conhecimento
adquirido neste trabalho, pode servir como complemento para futuros trabalhos
acadêmico com a utilização de dispositivos móveis.
4.2 CONTRIBUIÇÕES
Neste trabalho foram exploradas tecnologias (como as já citadas na
conclusão), o resultado foi o desenvolvimento de um protótipo de baixo custo para o
acompanhamento de pacientes hipertensos com a utilização de dispositivos móveis.
4.3 TRABALHOS FUTUROS
É possível desenvolver outros projetos como continuação deste trabalho, uma
solução completa para o acompanhamento de sinais vitais, geração de gráficos de
controle com base nos dados coletados, controle de exames clínicos. Tudo isso
poderia resultar em um sistema embarcado em um aparelho de aferição, que
disponibilizaria os dados através de sincronização com dispositivo móvel.
65
5 REFERÊNCIAS BIBLIOGRÁFICAS
ALGAWORKS. Softwares e Treinamentos Desenvolvimento Web com JavaServer
Faces set 2010, 204p. Apostila do curso de JavaServer Faces
ALMEIDA, A.; DAROLT, R. Pesquisa e Desenvolvimento em UML,. Araranguá,
2001.
CARNIEL, J.; TEXEIRA, C. Introdução ao J2ME. Web Mobile, n. 1, ano I, p. 11, Rio
de Janeiro, 2005.
FOWLER, M.; KENDAL, S. UML Essencial : um breve guia para a linguagem
padrão de modelagem de objetos. Tradução Vera Pezerico e Christian Thomas
Price. 2. ed. Porto Alegre: Bookman, 2003.
FURLAN, J. D.. Modelagem de Objetos através da UML. São Paulo: Makron
Books, 1998.
MACHADO, F. N. R. Projeto e implementação de banco de dados. São Paulo:
Érica, 2008. 398 p.
MARAFON, T. A. Camada de Persistência em Java Estudo Comparativo entre
EJB, JDO e Hibernate. Trabalho de Conclusão de Curso. UFSC, Florianópolis,
2005.
MEDEIROS, E. S. DE. Desenvolvendo software com UML 2.0: definitivo. São
Paulo: Pearson Makro Books, 2004. 264 p.
MOREIRA H. G. Biologia e Saúde. Biologia e saúde 1981.
MUCHOW, J. W. Core J2ME – Tecnologia & MIDP. São Paulo: Pearson Makron
Books, 2004.
NETO, Oziel Moreira. Entendendo e dominando o Java. São Paulo: Digetari
Books, 2009. 416p.
REVISTA BRASILEIRA DE HIPERTENSÃO. VI Diretrizes Brasileiras
Hipertensão. volume 17, NÚMERO 1, jan/mar de 2010.
de
ANATEL, Crescimento da telefonia celular no brasil. Disponível em:
<http://www.anatel.gov.br/Portal. Acesso em: 05 set. 2011.
DEVMEDIA Disponível em: <http://www.devmedia.com.br/post-21157-Dispositivosmoveis-e-telefonia-para-2011.html> .Acesso em 18 dez 2011
NETBEANS Disponível em: <http://netbeans.org/features/ide/buildtools_pt_BR.html> acesso em 19 dez 2011.
66
ORACLE - Plataforma Java Disponível em:
<http://www.oracle.com/technetwork/java/compile-136656.html#platform> Acesso
em 19 de dez 2011.
PRIMEFACES Disponível em: < http://www.primefaces.org > acesso em 5 out 2011.
PORTAL SAÙDE disponível em:
<http://portal.saude.gov.br/portal/saude/visualizar_texto.cfm?idtxt=22837> Acesso
em 18 dez 2011
PORTAL SÃO FRANCISCO disponível em:
<http://www.portalsaofrancisco.com.br/alfa/historia-do-telefone/telefone-celular7.php> acesso em 17 dez 2011.