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 Hipertensão sistólica isolada < 90 > ou = 140 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

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. Figura 1.2 Exemplo de diagrama de caso de uso

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 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

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. 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. 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.

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. 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 para geração automática de alguns códigos. (NETBEANS, 2011)

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 Paciente envia dados de sua pressão UC 8 arterial dadospressao Registrar aferição

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

35 Figura 2.2 Diagrama de sequência: Cadastrar Paciente.. Figura 2.3 Diagrama de atividades: Cadastrar Paciente.

36 Figura 2.4 Diagrama de MVC: Cadastrar Paciente. 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.

38 Figura 2.6 Diagrama de sequência: Cadastrar Médico Figura 2.7 Diagrama de atividades: Cadastrar médico

39 Figura 2.8 Diagrama de MVC: Cadastrar Médico. 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 Figura 2.10 Diagrama de sequência: Cadastrar Secretária

41 Figura 2.11 Diagrama de atividades: Cadastrar Secretaria Figura 2.12 Diagrama de MVC: Cadastrar Secretária.

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

43 Figura 2.14 Diagrama de sequência: Cadastrar Convênio. Figura 2.15 Diagrama de atividades: Cadastrar Convênio

44 Figura 2.16 Diagrama de MVC: Cadastrar Convênio. 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 Figura 2.18 Diagrama de sequência: Cadastrar Procedimento..

46 Figura 2.19 Diagrama de atividades: Cadastrar Procedimento Figura 2.20 Diagrama de MVC: Cadastrar Procedimento.

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

48 Figura 2.22 Diagrama de sequência: Agendar Consulta.. Figura 2.23 Diagrama de atividades: Agendar Consulta

Figura 2.24 Diagrama de MVC: Agendar Consulta. 49

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

51 Figura 2.26 Diagrama de sequência: Registrar Prontuário.. Figura 2.27 Diagrama de atividades: Registrar Prontuário

Figura 2.28 Diagrama de MVC: Registrar Prontuario. 52

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 Figura 2.30 Diagrama de sequência: Registrar Aferição.

54 Figura 2.31 Diagrama de atividades: Registrar Aferição Figura 2.32 Diagrama de MVC: Registrar Aferição.

55 2.2.3 Diagrama de Classes Figura 2.33 Diagrama de Classes.

56 2.2.4 Diagrama Modelo Entidade-Relacionamento Figura 2.34 Diagrama Modelo Entidade-Relacionamento.

57 2.2.5 Diagrama de Estrutura de Dados Figura 2.35 Diagrama de Estrutura de Dados.

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.