Sistema de agendamento de consultas em hospitais da rede pública

Sistema de agendamento de consultas em

hospitais da rede pública

Florianópolis  SC 2006

Sistema de agendamento de consultas em

hospitais da rede pública

Monograa apresentada ao programa de Bacharelado em Ciências da Computação da Universidade Federal de Santa Catarina como requisito parcial para obtenção do grau Bacharel em Ciências da Computação

Orientador:

Professor Doutor João Bosco Mangueira Sobral

Universidade Federal de Santa Catarina Centro Tecnológico

Florianópolis  SC 2006

Keunecke e aprovada em 17 de abril de 2006, em Florianópolis, Santa Catarina, pela banca examinadora constituída por:

Prof. Dr. João Bosco Mangueira Sobral Orientador

Prof. Dr. Leandro José Komosinski Universidade Federal de Santa Catarina

Clytia Higa Tamashiro

O tempo despendido na la para a marcação de consultas nos hospitais públicos, as diculdades decorrentes do serviço de transporte e todos os problemas que surgem devido a isso devem ser minimizados da vida cotidiana das pessoas que utilizam o serviço de marcação de consultas nos hospitais da rede pública . O presente projeto contempla a construção de um protótipo para minimizar o problema social vivido pela comunidade, em relação à diculdade de locomoção e tempo despendido na la para o agendamento de simples atendimentos (consultas) nos hospitais da rede pública da Grande Florianópolis. No sentido de mostrar a viabilidade de se construir um sistema real que integre hospitais, centros de saúde e entidades governamentais, um protótipo que implementa um serviço integrado de agendamento de consultas é apresentado, utilizando as tecnologias de serviços Web, como benefício ao público carente, através de um sistema de baixo custo, utilizando softwares de livre utilização.

The queue assembly time to set medical consultations, current diculties inherent from the transportation service and all correlated problems must be minimized for the daily users of the service at public hospitals. The present project proposes a possible solution to minimize the local community social situation, considering the diculties of locomotion and time expended in a queue in order to schedule routine appointments at the public hospitals in the city of Florianopolis and outskirts. In order to show the viability of constructing a real system which integrates hospitals, health governmental centers and entities, it is presented a prototype enabled to perform an integrated schedule service of consultations.

Lista de Figuras

Lista de abreviaturas e siglas

1 Introdução p. 13 1.1 Justicativa . . . p. 14 1.2 Objetivos . . . p. 14 1.2.1 Geral . . . p. 14 1.2.2 Especícos . . . p. 14 1.3 Estrutura do Trabalho . . . p. 14 2 Fundamentação Teórica p. 15

2.1 Internet e World Wide Web (1) . . . p. 15 2.2 Java(2) . . . p. 15 2.3 Servlets . . . p. 16 2.4 JSP (JavaServer Pages) . . . p. 17 2.4.1 JavaBeans . . . p. 17 2.5 XML (Extensible Markup Language) . . . p. 18 2.6 SOAP (Simple Object Acess Protocol) . . . p. 18 2.7 Serviços na Web . . . p. 19

2.7.1 Publicação do Serviço - UDDI (Universal Description, Discovery,

and Integration) . . . p. 20 2.7.2 Descrição do Serviço - WSDL (Web Service Description Language) p. 20

2.8 Ferramentas . . . p. 23 2.8.1 Eclipse (3) . . . p. 23 2.8.2 Apache Tomcat (4) . . . p. 24 2.8.3 Apache Axis (5) . . . p. 24 2.8.4 Apache Struts (6) . . . p. 24 2.8.5 Hibernate (7) . . . p. 26 2.8.6 MySql(8) . . . p. 27 3 Sistema Proposto p. 28

3.1 Levantamento de Requisitos - Casos de Uso . . . p. 28 3.2 Modelagem e Implementação . . . p. 29 3.2.1 Confrontando Vertentes . . . p. 30 3.3 Distribuição dos módulos . . . p. 30 3.3.1 Módulo Hospital . . . p. 30 3.3.1.1 Utilizando Hibernate . . . p. 31 3.3.1.2 Banco de Dados bdhospital . . . p. 33 3.3.2 Módulo SUS . . . p. 34 3.3.2.1 Utilizando Serviços Web . . . p. 35 3.3.2.2 Banco de Dados bdsus . . . p. 37 3.3.3 Módulo de Apresentação . . . p. 38 3.3.3.1 Utilizando Struts . . . p. 38 3.3.3.2 Banco de Dados bdagendador . . . p. 39 3.3.4 Considerações do sistema . . . p. 40

Referências p. 43 5 Anexos p. 45 5.1 Módulo de Apresentação . . . p. 45 5.1.1 SistemaAgendador/JavaSource/actions/Gerenciador.java . . . . p. 45 5.1.2 SistemaAgendador/JavaSource/actions/HospitaisAction.java . . p. 46 5.1.3 SistemaAgendador/JavaSource/actions/MedicosAction.java . . . p. 48 5.1.4 SistemaAgendador/JavaSource/actions/PacientesAction.java . . p. 49 5.1.5 SistemaAgendador/JavaSource/actions/UsuariosAction.java . . p. 51 5.1.6 SistemaAgendador/JavaSource/actions/UtilitariosAction.java . . p. 52 5.1.7 SistemaAgendador/JavaSource/bd/hibernate/Banco.java . . . . p. 53 5.1.8 SistemaAgendador/JavaSource/bd/hibernate/tabelas/Hospitais.java p. 54 5.1.9 SistemaAgendador/JavaSource/bd/hibernate/tabelas/Usuarios.java p. 56 5.1.10 SistemaAgendador/JavaSource/beans/Consulta.java . . . p. 58 5.1.11 SistemaAgendador/JavaSource/beans/Endereco.java . . . p. 66 5.1.12 SistemaAgendador/JavaSource/beans/Hospital.java . . . p. 75 5.1.13 SistemaAgendador/JavaSource/beans/Medico.java . . . p. 77 5.1.14 SistemaAgendador/JavaSource/beans/Paciente.java . . . p. 83 5.1.15 SistemaAgendador/JavaSource/actions/Gerenciador.java . . . . p. 98 5.1.16 SistemaAgendador/JavaSource/service/Hospital.java . . . p. 100 5.1.17 SistemaAgendador/JavaSource/service/HospitalProxy.java . . . p. 101 5.1.18 SistemaAgendador/JavaSource/service/HospitalService.java . . p. 105 5.1.19 SistemaAgendador/JavaSource/service/HospitalServiceLocator.javap. 106 5.1.20 SistemaAgendador/JavaSource/service/HospitalSoapBindingStub.javap. 111

5.1.23 SistemaAgendador/JavaSource/service/SUSService.java . . . p. 132 5.1.24 SistemaAgendador/JavaSource/service/SUSServiceLocator.java p. 133 5.1.25 SistemaAgendador/JavaSource/service/SUSSoapBindingStub.java p. 138 5.1.26 SistemaAgendador/JavaSource/service/TestaServiceHospital.java p. 147 5.1.27 SistemaAgendador/JavaSource/service/TestaServiceSUS.java . . p. 150 5.1.28 SistemaAgendador/JavaSource/uteis/Constantes.java . . . p. 152 5.1.29 SistemaAgendador/JavaSource/uteis/ConversorPaciente.java . . p. 153 5.1.30 SistemaAgendador/JavaSource/beans/Hospital.hbm.xml . . . . p. 164 5.1.31 SistemaAgendador/JavaSource/beans/Usuario.hbm.xml . . . p. 165 5.1.32 SistemaAgendador/JavaSource/actions/Gerenciador.java . . . . p. 166 5.1.33 SistemaAgendador/WebContent/WEB-INF/struts-cong.xml . p. 177 5.1.34 SistemaAgendador/WebContent/WEB-INF/struts-cong.xml.bk p. 181 5.1.35 SistemaAgendador/WebContent/WEB-INF/struts-html.tld . . . p. 192 5.1.36 SistemaAgendador/WebContent/WEB-INF/struts-logic.tld . . . p. 287 5.1.37 SistemaAgendador/WebContent/WEB-INF/struts-nested.tld . . p. 306 5.1.38 SistemaAgendador/WebContent/WEB-INF/struts-tiles.tld . . . p. 397 5.1.39 SistemaAgendador/WebContent/WEB-INF/tiles-defs.xml . . . p. 407 5.1.40 SistemaAgendador/WebContent/WEB-INF/validation.xml . . . p. 409 5.1.41 SistemaAgendador/WebContent/WEB-INF/validator-rules.xml p. 411 5.1.42 SistemaAgendador/WebContent/WEB-INF/web.xml . . . p. 420 5.1.43 SistemaAgendador/WebContent/css/Geral.css . . . p. 422 5.1.44 SistemaAgendador/WebContent/jsp/buscarPaciente.jsp . . . p. 426 5.1.45 SistemaAgendador/WebContent/jsp/cadastraConsulta.jsp . . . p. 428 5.1.46 SistemaAgendador/JavaSource/actions/Gerenciador.java . . . . p. 430

5.1.49 SistemaAgendador/WebContent/jsp/index.jsp . . . p. 438 5.1.50 SistemaAgendador/JavaSource/actions/Gerenciador.java . . . . p. 440 5.1.51 SistemaAgendador/WebContent/jsp/listaPacientes.jsp . . . p. 442 5.1.52 SistemaAgendador/WebContent/jsp/menu.jsp . . . p. 444 5.1.53 SistemaAgendador/WebContent/jsp/principal.jsp . . . p. 446 5.1.54 SistemaAgendador/WebContent/jsp/relatorioConsulta.jsp . . . p. 447 5.2 Módulo SUS . . . p. 450 5.2.1 SistemaSUS/JavaSource/bd/hibernate/Banco.java . . . p. 450 5.2.2 SistemaSUS/JavaSource/bd/hibernate/tabelas/Pacientes.java . p. 451 5.2.3 SistemaSUS/JavaSource/beans/Endereco.java . . . p. 455 5.2.4 SistemaSUS/JavaSource/beans/Paciente.java . . . p. 459 5.2.5 SistemaSUS/JavaSource/service/SUS.java . . . p. 466 5.2.6 SistemaSUS/JavaSource/uteis/Constantes.java . . . p. 467 5.2.7 SistemaSUS/WebContent/META-INF/MANIFEST.MF . . . p. 468 5.2.8 SistemaSUS/WebContent/WEB-INF/SUSService/service/deploy.wsddp. 468 5.2.9 SistemaSUS/WebContent/WEB-INF/SUSService/service/undeploy.wsddp. 469 5.2.10 SistemaSUS/JavaSource/bd/hibernate/Banco.java . . . p. 469 5.2.11 SistemaSUS/WebContent/WEB-INF/web.xml . . . p. 472 5.2.12 SistemaSUS/WebContent/wsdl/SUS.wsdl . . . p. 473 5.2.13 SistemaSUS/JavaSource/beans/Paciente.hbm.xml . . . p. 480 5.3 Módulo Hospital . . . p. 483 5.3.1 SistemaHospital/JavaSource/bd/hibernate/Banco.java . . . p. 483 5.3.2 SistemaHospital/JavaSource/bd/hibernate/tabelas/Consultas.java p. 485 5.3.3 SistemaHospital/JavaSource/bd/hibernate/tabelas/Medicos.java p. 491

5.3.6 SistemaHospital/JavaSource/beans/Endereco.java . . . p. 500 5.3.7 SistemaHospital/JavaSource/beans/Medico.java . . . p. 504 5.3.8 SistemaHospital/JavaSource/beans/Paciente.java . . . p. 506 5.3.9 SistemaHospital/JavaSource/service/Hospital.java . . . p. 513 5.3.10 SistemaHospital/JavaSource/uteis/Constantes.java . . . p. 515 5.3.11 SistemaHospital/JavaSource/uteis/Data.java . . . p. 516 5.3.12 SistemaHospital/WebContent/META-INF/MANIFEST.MF . . p. 525 5.3.13 SistemaHospital/WebContent/WEB-INF/HospitalService/service/deploy.wsddp. 526 5.3.14 SistemaHospital/WebContent/WEB-INF/HospitalService/service/undeploy.wsddp. 528 5.3.15 SistemaHospital/WebContent/WEB-INF/server-cong.wsdd . . p. 529 5.3.16 SistemaHospital/WebContent/WEB-INF/web.xml . . . p. 534 5.3.17 SistemaHospital/WebContent/wsdl/Hospital.wsdl . . . p. 536 5.3.18 SistemaHospital/JavaSource/beans/Consulta.hbm.xml . . . p. 551 5.3.19 SistemaHospital/JavaSource/beans/Medico.hbm.xml . . . p. 552 5.3.20 SistemaHospital/JavaSource/beans/Paciente.hbm.xml . . . p. 553

1 Arquitetura de aplicativo servlet. . . p. 16 2 Comunicação em Serviço Web usando SOAP via HTTP. . . p. 18 3 Processo serviço Web. . . p. 20 4 SOAP, UDDI e WSDL em uma interação Web Service. . . p. 22 5 Clássico modelo MVC (Model-View-Controller). . . p. 25 6 Arquitetura Modelo 2 . . . p. 25 7 Visão alto nível da arquitetura Hibernate utilizada. . . p. 26 8 Diagrama entidade relacional do Sistema de Agendamento de Consultas. p. 29 9 Arquivo de conguração do Hibernate no módulo Hospital. . . p. 31 10 Arquivo de mapeamento objeto/relacional para a classe Consulta.java. p. 32 11 Método de acesso ao banco de dados utilizando Hibernate. . . p. 33 12 Modelagem do banco de dados bdhospital. . . p. 33 13 Nome e Localização do serviço no arquivo SUS.wsdl . . . p. 35 14 Uma das diversas operações publicadas no arquivo SUS.wsdl. . . p. 36 15 Resposta SOAP transmitida via HTTP. . . p. 36 16 Requisição SOAP transmitida via HTTP. . . p. 37 17 Cabeçalho HTTP de uma requisição SOAP encapsulada . . . p. 37 18 Modelagem do banco de dados bdsus. . . p. 37 19 Trecho do arquivo de conguração do Struts "struts-cong.xml". . . p. 38 20 Método da classe destino "PacientesAction.java". . . p. 39 21 Modelagem do banco de dados bdagendador. . . p. 39

WWW - World Wide Web SUS - Sistema Único de Saúde

INSS - Instituto Nacional do Seguro Social HTTP - Hypertext Transfer Protocol

JSP - JavaServer Pages JVM - Java Virtual Machine XML - Extensible Markup Language W3C - World Wide Web Consortium SOAP - Simple Object Acess Protocol

UDDI - Universal Description, Discovery, and Integration WSDL - Web Service Description Language

URL - Uniform Resource Locator HTML - HyperText Markup Language

CSS - Cascading Style Sheets SQL - Structured Query Language

MVC - Model-View-Controller

SGBD - Sistema Gerenciador de Banco de Dados JDBC - Java Database Connectivity

1 Introdução

As distâncias de várias localidades nos estados brasileiros, para os hospitais públicos nas grandes cidades (muitas vezes as prefeituras do interior dos estados precisam trazer os pacientes de suas cidades para os grandes centros), as diculdades decorrentes do serviço de transporte nos horários da madrugada (quando os pacientes moram nas próprias cidades dos hospitais), o tempo despendido por uma pessoa carente na la por marcação de consulta nos hospitais públicos são fatores que podem ser eliminados, ou ao menos, minimizados da vida cotidiana dos usuários do SUS (Sistema Único de Saúde).

Assim um sistema que implemente um "Serviço Integrado de Agendamento de Con-sultas"pode ser construído e implantado. O sistema buscará integrar os serviços similares de agendamentos de consultas dos hospitais e o INSS (Instituto Nacional do Seguro So-cial), em benefício do público carente, através de baixo custo nanceiro, utilizando as tecnologias para serviços na Web. Para isso softwares de livre utilização, como os siste-mas operacionais LINUX, as plataforsiste-mas de serviços para Web e as ferramentas para se construir um sistema seguro podem ser utilizados.

O sistema de atendimento proposto é um sistema distribuído entre centros de saúde de um município, as unidades hospitalares públicas e as poli-clínicas do INSS, que são integradas através de um rede segura, na internet, utilizando as tecnologias apropriadas para tal.

Este sistema visa eliminar a la física de pessoas nos casos sem emergência e torná-la uma la virtual (no computador, a la parece existir, mas na realidade não existe).Os hábitos e procedimentos internos aos hospitais não serão alterados. A população de baixa renda será beneciada e as portarias de hospitais serão aliviadas, uma vez que os usuários podem ir a qualquer centro ou posto de saúde, que deve acessar do sistema, sendo este manuseado por funcionário do posto, após a orientação de um médico.

Este projeto diz respeito à concepção e modelagem, desenvolvimento e testes da parte computacional principal, no sentido de se mostrar a viabilidade da implantação do projeto.

1.1 Justicativa

O atual processo de agendamento de simples consultas, sendo feito somente com a presença física do usuário nos hospitais públicos, conduz a fatores que dicultam e causam transtorno. Tais problemas dizem respeito a passar madrugadas em claro, a diculdade de locomoção, a espera numa la com limite do número de pessoas que podem ser atendidas, gastando-se um tempo precioso de vida. Na realidade, a marcação de uma simples consulta requer um tempo mínimo do trabalho de um funcionário (por exemplo, 5 minutos por pessoa), tempo ínmo relativo ao que se despende para se locomover e aguardar numa la.

1.2 Objetivos

Nesta seção são apresentados os objetivos do trabalho proposto.

1.2.1 Geral

Demonstrar e implementar uma possível solução para o problema de las na marcação de consultas nos hospitais públicos e poli-clínicas do INSS.

1.2.2 Especícos

• Utilizar as tecnologias de serviços Web. • Realizar o projeto com baixo custo nanceiro.

1.3 Estrutura do Trabalho

Este trabalho segue com a explicitação do conjunto de ferramentas e tecnologias rela-cionadas à este projeto. Logo em seguida no capítulo 3 temos uma visão da arquitetura, modelagem e implementação do sistema proposto. Por m conclusão e proposta de tra-balhos futuros são apresentados.

2 Fundamentação Teórica

A seguir são apresentados algumas ferramentas e tecnologias envolvidas nesse projeto.

2.1 Internet e World Wide Web (1)

Financiada pelo Departamento de Defesa dos EUA, há mais de três décadas, a Inter-net foi inicialmente projetada para conectar os principais sistemas de computadores das universidades e centros de pesquisas americanos. Hoje são milhões de computadores com acesso a essa tecnologia.

Com o advento da World Wide Web (WWW), possibilitou-se aos usuários de compu-tador pesquisar, localizar e visualizar materiais sobre os mais variados assuntos, fazendo a Internet tornar-se um dos principais mecanismos de comunicação do mundo.

A Internet e a World Wide Web irão listar entre as mais importantes invenções da raça humana. Antes, a grande parte dos aplicativos rodavam em computadores isolados, sem comunicação entre si. Hoje os aplicativos podem ser escritos de maneira a comunicarem-se com centenas de milhares de computadores localizados no mundo.

2.2 Java(2)

Java na atualidade (1), é uma linguagem muito extensa e que está sendo cada vez mais utilizada na Internet como na informática em geral, procurando sempre cobrir as necessidades tecnológicas mais importantes.

Uma das características marcantes de Java é que é uma linguagem independente da plataforma. Isto signica que ao produzir-se um programa em Java este poderá funcionar em qualquer sistema operacional com suporte a Java. É uma vantagem signicativa para os desenvolvedores de software, pois antes havia a necessidade de compilar um programa

para a Internet pois possui uma vasta API que dá suporte para sua utilização, além de existirem frameworks livres facilitando o desenvolvimento de aplicações.

2.3 Servlets

Servlet (9) surgiu em 1996 introduzida pela Sun Microsystems . São classes Java que estendem os pacotes javax.servlet (o framework básico de Servlet) e javax.servlet.http (ex-tensão do framework Servlet para Servlets que respondem a requisições HTTP(Hypertext Transfer Protocol)). Como servlets são escritos em Java e seguem um framework pa-drão, eles proporcionam maneiras de criar sosticados extensões do servidor, indepen-dentemente do servidor e sistema operacional. Um servlet pode ser automaticamente carregado e executado em um servidor Web especial. Como se utilizam tanto servlets como JSP(JavaServer Pages) chamam-se esses servidores de contentor Web ou contentor servlet/JSP. O Tomcat (4) foi o contentor utilizado nesse trabalho.

A seguir a gura 1 mostrando como os servlets interagem com os clientes através de um modelo solicitação/resposta baseado em HTTP.

Figura 1: Arquitetura de aplicativo servlet. Servlets e Jsps oferecem, segundo (9), os seguintes benefícios:

• Desempenho. Não há processo de criação para cada solicitação de cliente. Ao invés, cada solicitação é gerenciada pelo processo contentor do servlet. Depois que um ser-vlet termina de processar uma solicitação, ele permanece na memória, aguardando por outra solicitação.

• Portabilidade. Semelhante a outras tecnologias Java, os aplicativos servlets são portáteis. Podem ser movidos sem maiores problemas para outros sistemas opera-cionais.

• Rápido ciclo de desenvolvimento. Têm acesso à rica biblioteca Java, que ajuda no processo de desenvolvimento.

• Robustez. São gerenciados pela JVM (Java Virtual Machine). Assim os controles de memória, resíduos já estão garantidos.

• Aceitação difundida. Numerosos fabricantes trabalham com tecnologias baseadas em Java. Assim pode-se encontrar com certa facilidade componentes que se ajustem as necessidades do desenvolvedor.

2.4 JSP (JavaServer Pages)

JSP é outra tecnologia Java para desenvolvimento de aplicativos Web. Como descrito no livro (9), surgiu no momento que a tecnologia de servlet tinha atingido popularidade como uma das melhores tecnologias disponíveis. JSP não tem a pretensão de substituir servlet, mas sim é uma extensão dessa tecnologia, e é comum se utilizar ambas as tecno-logias nos mesmos aplicativos Web. Permite, de maneira eciente, a criação de páginas dinâmicas. Como o nome implica, JSP utiliza a linguagem de programação Java para criar esse ambiente dinâmico de exibição de dados. Uma página JSP é usada no lado ser-vidor e é traduzida em um Servlet e compilada após sua primeira invocação. As páginas JSP proporcionam tags que permitem tratar as mais diversas operações dinâmicas sem a necessidade de incluir código java complexo. JSP foi montada tendo como base o servlet e necessita deste para trabalhar.

2.4.1 JavaBeans

JavaBeans (10) são componentes de software que são projetados para serem classes reutilizáveis, que uma vez criados podem ser reusados sem modicação de código, e em qualquer propósito de aplicação, seja um applet, um servlet ou qualquer outra. Um Bean é uma classe Java com determinadas regras. As regras submetidas a uma classe para que ela seja uma classe JavaBeans, são as seguintes:

• Possuir um construtor sem argumentos. Java criará automaticamente um construtor sem argumentos para qualquer classe Java que não tenha um construtor;

• Possuir métodos públicos para ajustar o valor de alguma propriedade. São os mé-todos setter. Não retorna nenhum valor e seu nome inicia com "set", seguido pelo nome da propriedade.

• Possuir métodos públicos para obter o valor de alguma propriedade. São os métodos getter. Retorna um valor do mesmo tipo ao da propriedade em questão. O seu nome inicia com "get" seguido do nome da propriedade.

Os métodos setters e getters são conhecidos como acess methods (métodos de acesso). JavaBeans são exigidos para mapeamento de classes pelo Hibernate (11), utilizados pelas páginas JSP (12). Além disso, apesar de não ser obrigatório, em Struts (6) facilita a transferência dos atributos obtidos em um request para os beans. Por exemplo em "Be-anUtils.copyProperties(hospital, actionForm);". BeanUtils é uma classe da API Jakarta Commons. Percebe-se aí outra vantagem de se utilizar JavaBeans: a possibilidade de se utilizar ferramentas como a API Jakarta Commons.

2.5 XML (Extensible Markup Language)

Desenvolvido (10) a partir de SGML(Standard Generalized Markup Language), é um padrão largamente aceitável para descrição de dados e criação de linguagens de marca-ção. XML foi denido pelo W3C (World Wide Web Consortium) como uma tecnologia de padrão aberto. Assim, por ser uma representação estruturada dos dados, permite que quaisquer aplicações que entendam XML, troquem dados independente de sistema operacional ou linguagem de programação.

2.6 SOAP (Simple Object Acess Protocol)

SOAP é um protocolo leve, para troca de informações em ambientes descentralizados ou distribuídos. É baseado em XML buscando a troca de informações entre computadores e tem como foco principal a chamada remota de procedimentos via HTTP, a opção mais popular para o serviço de transporte.

Na gura 2 vemos um diagrama da comunicação num Serviço Web usando SOAP via HTTP.

SOAP está dividido em três partes:

• Um documento que dene a estrutura para descrever o que vem em uma mensagem e como sua manipulação deve ser realizada;

• Um conjunto de regras codicadas para expressar aplicações de tipos denidos; • Uma convenção para representar as chamadas e respostas remotas de procedimentos.

2.7 Serviços na Web

Os serviços na Web (13) estão fortemente difundidos. Os desenvolvimentos que eram realizados para aplicações clientes estão migrando para os servidores. É cada vez mais comum a distribuição de um projeto. Não há mais a necessidade que todo o sistema desenvolvido esteja contido em um mesmo computador rodando localmente. Além disso o contexto de trabalhar dinamicamente é de suma importância para o sucesso dos sistemas Web. Informações devem trafegar pelos mais diversos protocolos e necessitam também serem armazenadas em meios seguros para uso futuro. Tendo essa necessidade de se trabalhar dinamicamente com os dados, as páginas, do mesmo modo, devem trabalhar dinamicamente. Assim estas páginas e seu contexto são criados assim que uma requisição é feita. Segundo (14) para um serviço na Web ser considerado completo ele deve seguir alguns aspectos:

• Estar disponível na Internet ou em redes privadas; • Usar um sistema padrão de envio de mensagens XML;

• Não estar atado a nenhum sistema operacional ou linguagem de programação; • Ser alto descritivo através de uma gramática XML comum;

• Facilmente encontrado via mecanismos simples de busca.

Aproveitar as vantagens que estão associadas aos serviços Web é um dos principais objetivos desse projeto. São consideradas vantagens (10) de um sistema Web Service os seguintes pontos:

• Promove uma aproximação da programação em módulos, assim múltiplas organiza-ções podem se comunicar utilizando-se do mesmo Web Service;

• São até certo ponto baratos e fáceis de implementar, devido que se utilizam de uma infra-estrutura já existente para transportar informações.

• Pode ser produzida de maneira crescente e incremental, ao invés de o sistema ser um bloco único produzido de uma só vez. Isso diminui os custos de adotar o serviço Web e pode diminuir o impacto em uma organização pela troca de alguma tecnologia envolvida no sistema.

A gura 3 demonstra as camadas envolvidas em um serviço Web.

Figura 3: Processo serviço Web.

2.7.1 Publicação do Serviço - UDDI (Universal Description,

Dis-covery, and Integration)

UDDI é uma especicação técnica para publicar e encontrar serviços Web. É um sis-tema que mantém em repositórios de documentos, os quais descrevem os dados referentes ao serviço.

2.7.2 Descrição do Serviço - WSDL (Web Service Description

Language)

Um dos aspectos relevantes de um serviço Web é ser alto descritivo através de uma gramática XML comum. Para isso utiliza-se o WSDL, que descreve o serviço em um protocolo Web adequado. Representa a camada de descrição do serviço. Assim podem estar inclusos nesse arquivo todas as funções disponíveis, informações dos tipos dos dados

para todas as mensagens XML, trazendo informações do protocolo especíco de transporte à ser usado e os endereços onde os serviços estão disponibilizados.

Usando o WSDL, um cliente pode localizar o serviço Web e invocar qualquer das funções publicadas. Deste modo após localizar o serviço o cliente verica no arquivo de descrição do serviço qual interface deve utilizar para se comunicar e quais operações estão disponíveis ou podem ser tratadas pelo serviço Web.

Um arquivo WSDL possui algumas palavras chaves. Cada palavra chave representa uma das diversas congurações contidas no arquivo. Suas descrições, segundo (14), se-guem abaixo:

• message - Provê a denição da mensagem que será comunicada;

• portType - Dene a interface das operações de serviço que o Web Service suporta; • operation - Descreve uma ação permitida pelo Web Service. É o "lho" de

portType;

• type - Dene os tipos de dados que a mensagem SOAP contém;

• binding - Especica o protocolo pela qual os nodos transportam as mensagens e qual o tipo de codicação dos dados;

• port - Especica o endereço para um binding em particular. É um sub-elemento do service;

• service - Especica a atual localização (URL - Uniform Resource Locator) do Ser-viço Web no servidor.

2.7.3 Mensagens XML

XML tem se consolidado nos últimos anos. Essa ascensão é devido ao fato que este formato permite a diversos sistemas de computadores compartilhar dados facilmente, independentemente do Sistema Operacional ou Linguagem de Programação. Segundo (10) não seria possível implementar um Sistema Web Services sem o uso de XML, pois os arquivos padrões dos Serviços Web SOAP, WSDL e UDDI, interagindo na gura 4 -são baseados em XML.

Figura 4: SOAP, UDDI e WSDL em uma interação Web Service. 1. O cliente chama o registro UDDI para localizar o serviço;

2. O registro aponta ao cliente o documento WSDL; 3. O cliente acessa o documento WSDL;

4. WSDL provê dados para interagir com o serviço;

5. O cliente envia mensagem de requisição SOAP (SOAP request); 6. O serviço Web retorna uma resposta SOAP (SOAP response).

Neste projeto o protocolo utilizado para transporte de dados no formato XML, foi o SOAP. Para tanto zemos uso da plataforma AXIS. O uso de AXIS é importante para a transmissão de dados em um formato conveniente, aumentando assim a segurança e robustez no transporte de dados, nos diversos momentos onde a comunicação entre módulos é realizada. AXIS é implementação do protocolo SOAP.

2.7.4 Serviço de transporte - HTTP (Hypertext Transfer

Proto-col)

Este é um protocolo de solicitação e resposta. É um protocolo que permite aos servi-dores Web e browsers trocarem dados pela Web. O cliente executa uma solicitação, essa é transmitida ao servidor e a resposta retorna ao cliente. Em HTTP é sempre o cliente que inicia uma transação, pois o servidor não está em posição de solicitar algo ao cliente. Desta maneira as conexões HTTP são iniciadas pelo browser do cliente que envia uma solicitação HTTP. HTTP é a opção mais popular para o serviço de transporte. É simples, estável e largamente conhecido.

Ele permite mensagens SOAP serem encapsuladas em mensagens HTTP. Isto facilita a integração de aplicações remotas. Mas infelizmente como cita (14, CERAMI) isto aumenta o número de concessões que devem ser feitas no aspecto da segurança.

2.8 Ferramentas

Para a implementação desse projeto foram utilizados tecnologias para serviços Web, e realizado com baixo custo nanceiro, aproveitando-se ao máximo a infra-estrutura já exis-tente da Internet, usando-se para tal, softwares de livre utilização. Seguem as ferramentas com relevância ao projeto :

2.8.1 Eclipse (3)

É um projeto de fonte aberta, focalizado a fornecer uma plataforma extensível de desenvolvimento e estruturas de aplicação para a construção dos softwares. O Eclipse fornece as ferramentas e as estruturas que medem o ciclo de vida do desenvolvimento do software, incluindo a sustentação para modelar, ambientes em desenvolvimento em Java, C/C++, além de permitir testar e medir desempenho, realizar aplicações clientes, inteligência de negócio e o desenvolvimento embarcado. Outro fator positivo é a grande variedade de plugins de auxilio ao desenvolvimento dos mais diversos tipos de projetos. Neste projeto em particular foram utilizados os plugins WST (15) e CVS, já incluído na versão utilizada (eclipse 3.1), facilitando o controle de versões e o desenvolvimento em equipe.

A visão do plugin WST é estender a plataforma Eclipse, dando suporte a construção de aplicações Web multi-camadas. WST vem a facilitar bastante a vida do programador na hora de desenvolver um projeto Web Service. Ele possibilita diversas facilidades:

• Desenvolver e publicar páginas HTML(HyperText Markup Language);

• Desenvolver páginas Web baseadas em JavaScript e CSS(Cascading Style Sheets); • Gerar um applet para um dado server HTTP;

• Desenvolver SQL(Structured Query Language) statements e gerar páginas Web a partir de chamadas à banco de dados;

• Desenvolver e publicar esquema WSDL em registros UDDI;

• Explorar registros UDDI e dinamicamente testar os serviços Web via WSDL; • Testar Web Services para compilação WS-I.

2.8.2 Apache Tomcat (4)

É o recipiente de Servlet/JSP (contentor servlet/JSP, chamado antigamente de má-quina servlet no início da tecnologia servlet) que é usado para execução de servlets e das tecnologias de Java Page Servers (JSP). No corrente trabalho foi utilizado Apache Tomcat 5.5.x;

2.8.3 Apache Axis (5)

É uma implementação do SOAP (16) ("Protocolo Simples de Acesso ao Objeto") submetido pela W3C (17);

2.8.4 Apache Struts (6)

O objetivo desta ferramenta é prover um "framework" de utilização pública para a construção de projetos Web usando JAVA. Struts possui como característica um controle exível de camadas baseado nas tecnologias padrões como Java Servlets, JSP, JavaBe-ans, XML e os diversos pacotes da Jakarta amplamente utilizadas nesse projeto. Esta é uma ferramenta que disponibiliza um amplo ambiente para o desenvolvimento das apli-cações Web, baseado em padrões de design. O Struts (18), busca aproximar o Sistema Desenvolvido da Arquitetura Modelo 2, uma variação do clássico modelo MVC (Model-View-Controller). Esses dois modelos se diferenciam principalmente na localização na qual o montante de processamento de solicitações ("request") é executado. No modelo clássico, observado na gura 5, todo o processo de recebimento de solicitações e resposta dos mesmos aos clientes é realizado pelas páginas JSP.

Já na Arquitetura Modelo 2, observado na gura 6, trata as solicitações combinando o uso de JSP e servlets. Assim ambas tecnologias são combinadas, utilizando JSP para gerar a camada de apresentação e os servlets para executar o intenso processo de solicitações. É nesse momento que os servlets atuam como controlador, cando responsável por processar os pedidos, a criação dos "Beans" ou objetos utilizados pelas páginas JSP, além de decidir, conforme as ações dos usuários, qual página JSP deve receber a solicitação corrente. Assim

Figura 5: Clássico modelo MVC (Model-View-Controller).

Struts possui seu próprio controlador ("Controller") juntamente com outras tecnologias para prover o "Model" e a "View". Para o "Model" Struts pode interagir com tecnologias padrões de acesso aos dados, por exemplo JDBC, ou até mesmo fazer uso de outras tecnologias como a utilizada nesse projeto, o Hibernate. Para a "View" Struts trabalha com JavaServer Pages (JSP), também utilizado nesse projeto.

Figura 6: Arquitetura Modelo 2

Uma aplicação Web utiliza um descritor de distribuição de serviços para inicializar os recursos como servlets e taglibs. Possui o formato XML e possui o nome "WEB.XML". Struts tem o seu próprio arquivo de conguração para inicializar seus recursos. Entre eles temos ActionForms para receber as entradas dos usuários, ActionMappings para direcio-nar as ações no lado do servidor e ActionForwards para seleciodirecio-nar as páginas utilizadas

Optou-se por utilizar o Struts devido toda as facilidades que ele proporciona para trabalhar com grande número de páginas que estão constantemente sofrendo ações por parte dos usuários que tem acessos a elas.

2.8.5 Hibernate (7)

É uma poderosa ferramenta de persistência objeto/relacional e execução de querys em JAVA. Permite utilizar as vantagens da programação orientada a objetos, como por exemplo associação, herança, polimorsmo e composição. Fica entre o aplicativo e o banco de dados relacional, deixando o desenvolvedor livre para o problema de negócio em suas mãos. Facilita assim a implantação do projeto Web Services multi-camadas. Além disso facilita a troca do Sistema Gerenciador de Banco de Dados (SGBD),desde que algumas regras sejam seguidas, como não utilizar chamadas SQL nativa ou outro recurso não suportado pelo SGBD substituto. Há um arquivo de conguração que permite a troca das propriedades do sistema de persistência utilizado. Esse arquivo possui a conguração do driver de conexão, o dialeto do SGBD, mapeamento de tabelas, entre outros. Todas as especicações dessa ferramenta podem ser encontradas em (11);

Figura 7: Visão alto nível da arquitetura Hibernate utilizada.

Este diagrama (gura 7) mostra o Hibernate acessando o banco de dados e os arquivos de mapeamento (conguração) para prover serviços de persistência (e objetos persistentes) para a aplicação.

2.8.6 MySql(8)

Desenvolve e disponibiliza no mercado um conjunto de ferramentas, de desempe-nho elevado, de base de dados. A versão utilizada nesse projeto foi MySQL 4.1.11-Debian_4sarge2-log. Para acesso cliente ao MySql utilizamos phpMyAdmin (19) versão 2.6.2. Além disso, foi utilizado JDBC (20) (Java Database Connectivity (21)). Assim é possível o uso de declarações SQL, sendo possível a utilização de vários tipos de banco de dados.

3 Sistema Proposto

Este capítulo apresenta o sistema proposto e como este foi realizado. Consciente de que o sistema atual de marcação de consulta apresenta alguns problemas como centralização do serviço, ocasionando las, propõe-se reformulá-lo. Esse projeto tem como principal objetivo descentralizar a marcação de consultas dos Hospitais. Busca possibilitar que o agendamento de consultas seja feito de outras localidades além do próprio hospital, bem como permitir que de um mesmo local se possa agendar consultas em um conjunto de hospitais mais abrangente e disponibilizar mais informações aos pacientes.

A construção do sistema consiste em três etapas:

• Levantamento de Requisitos: Levantamento das necessidades, para a construção de um sistema que venha minimizar os problemas existentes.

• Modelagem: Interpretação dos requisitos levantados, bem como sua tradução em especicações do sistema.

• Implementação: Conversão das especicações do sistema em código.

3.1 Levantamento de Requisitos - Casos de Uso

• Marcar consultas: Agendar uma consulta disponível para um paciente. Requisitos: consulta disponível, paciente cadastrado.

• Desmarcar consultas: Desmarcar uma consulta previamente agendada, tornando-a disponível novamente. Após obter uma consulta agendada o usuário tem a opção de excluí-la. Requisitos: consulta previamente agendada.

• Vericar consultas disponíveis: Vericar as consultas disponíveis para agendamento em um determinado hospital, para determinado médico ou especialidade. Requisi-tos: CRM do médico para pesquisas por médico, especialidade para pesquisas por especialidade, hospital.

• Pesquisar por médicos: Vericar os médicos que trabalham em determinado hospital, por nome ou especialidade. Requisitos: nome parcial ou especialidade do médico; hospital

• Pesquisar por consultas: Vericar as consultas agendadas para um paciente ou mé-dico especico. Requisitos: número de inscrição do paciente para pesquisa por paciente, CRM do médico para pesquisa por médico.

• Cadastrar hospitais: Cadastrar hospital para futura marcação de consultas. Requi-sitos: nome, endereço.

• Cadastrar pacientes: Cadastrar paciente possibilitando que este marque consultas. Requisitos: nome, rua, número, complemento, bairro, cidade, estado, pai, mãe, cônjuge, empresa, nacionalidade, naturalidade, estado civil, nascimento, sexo. • Cadastrar usuários: Cadastrar usuário responsável pela manipulação do sistema.

Requisitos: nome, endereço, telefone.

3.2 Modelagem e Implementação

Seguindo o levantamento de requisitos foram identicados as entidades e relaciona-mentos observados na gura 8. Os médicos atendem nos hospitais e esta associação permite que consultas sejam marcadas pelos usuários para os pacientes cadastrados.

Após levantados os requisitos surgiram duas vertentes principais para a arquitetura do sistema. Na primeira vertente teria-se uma conguração centralizada, onde o Sistema rodaria completamente no servidor. Na segunda o sistema seria composto de módulos distribuídos (modular) entre o servidor e os hospitais.

3.2.1 Confrontando Vertentes

• Na conguração modular há a possibilidade de se reaproveitar parte do sistema atual, tais como bancos de dados e servidores. O aproveitamento em um sistema centralizado será muito menor.

• Em contrapartida um sistema centralizado seria mais rápido, uma vez que, todo o sistema estaria local e não se teria o trafego da rede.

• Na conguração modular a inserção de novos hospitais é facilitada uma vez que conguram um módulo separado com baixo acoplamento ao sistema como um todo. Analisando essas duas possibilidades chegou-se a conclusão de que a conguração modular se enquadrava melhor à proposta de descentralizar e foi a utilizada nesse trabalho.

3.3 Distribuição dos módulos

Neste tópico iremos apresentar como foi dividido o sistema. O sistema possui 3(três) módulos. São eles:

• Módulo Hospital - Responsável pelos casos de uso referentes as consultas e médicos; • Módulo de Apresentação - Responsável pela redirecionamento das requisições ao

sistema;

• Módulo SUS - Responsável pelos casos de uso referentes aos pacientes;

3.3.1 Módulo Hospital

O módulo Hospital tem como missão a gestão de todas as consultas e médicos. Fica a cargo de cada hospital como esse controle será feito, pois sua interligação é realizada como um serviço Web. Para mostrar a viabilidade do sistema foi implementado um serviço Web e vários hospitais ctícios. Para cada hospital foi criado um banco de dados

com suas respectivas informações. Por se tratar de um sistema modular a inserção de novos hospitais é altamente facilitada, exigindo apenas que cada hospital implemente o seu serviço Web.

3.3.1.1 Utilizando Hibernate

O uso desta ferramenta é vasto. Para demonstrar um pouco do uso dessa ferramenta, tomou-se como base o módulo Hospital. Ele possui as seguintes classes JavaBeans para serem mapeados através do Hibernate: Consulta.java, Medico.java e Paciente.java. Temos abaixo o arquivo de conguração do Hibernate no módulo Hospital (gura 9) com as seguintes congurações:

Figura 9: Arquivo de conguração do Hibernate no módulo Hospital.

• Driver de conexão - com.mysql.jdbc.Driver

• O "dialeto" utilizado para comunicar-se com o banco - org.hibernate.dialect.MySQLDialect • O endereço (URL) do banco - jdbc:mysql://localhost:3306/bdhospital

• Número de conexões iniciais - 5 • Login para conexão ao banco - tcc

• Indicação dos arquivos responsáveis pelo mapeamento objeto/relacional para as clas-ses Paciente.java, Consulta.java e Medico.java .

<mapping resource="beans/Paciente.hbm.xml"/> <mapping resource="beans/Consulta.hbm.xml"/> <mapping resource="beans/Medico.hbm.xml"/>

A seguir a gura 10 de um dos mapeamentos objeto/relacional para a classe Con-sulta.java e o banco de dados "bdhospital", onde são mapeadas as propriedades id, data,

hora, paciente, medico da classe JavaBeans para as colunas "ID","DATA","HORA","PACIENTE" e "MEDICO" da tabela "CONSULTAS".

Figura 10: Arquivo de mapeamento objeto/relacional para a classe Consulta.java. O mesmo esquema de mapeamento é feito para os outros módulos e seus respecti-vos bancos de dados. Agora iremos explicitar um método de acesso ao banco de dados "bdhospital" utilizando hibernate no módulo Hospital.

Abaixo um rápida explicação do itens encontrados na gura 11:

• session - objeto de vida curta representando a comunicação entre a aplicação e os dados persistentes;

• transaction - objeto de vida curta representando uma transação;

• session.get(Consulta.class, consulta) - busca a classe consulta no banco a partir do identicador consulta;

Figura 11: Método de acesso ao banco de dados utilizando Hibernate. • setPaciente(paciente) - setando o paciente que terá consulta marcada; • session.saveOrUpdate(paciente) - salvando o paciente no banco de dados; • transaction.commit() - comitando a transação;

• session.close() - fechando a sessão;

Segue a representação do banco de dados bdhospital. 3.3.1.2 Banco de Dados bdhospital

O banco de dados bdhospital é composto por três tabelas: CONSULTAS, MEDI-COS e PACIENTES. A tabela CONSULTAS se relaciona com as tabelas MEDIMEDI-COS e PACIENTES. Cada Hospital irá possuir um banco de dados próprio com suas consultas, médicos e, caso considere adequado, os pacientes com consulta marcada. A gura 12 representa o banco.

3.3.2 Módulo SUS

A idéia do módulo SUS surgiu do problema de onde seriam armazenados os dados dos pacientes. Duas possibilidades foram levantadas:

• Caso 1 - Os dados poderiam ser mantidos em cada hospital, nos quais os pacientes possuissem consulta.

• Caso 2 - Os dados dos pacientes poderiam ser mantidos em um banco de dados único.

Alguns pontos requerem uma análise para escolha adequada da melhor opção: • Redundância

Caso 1 - No caso de pacientes possuírem consultas em mais de um hospital seus dados estariam replicados em mais de um banco de dados.

Caso 2 - Não há redundância, pois o cadastro é único. • Sincronia

Caso 1 - Ao modicar seus dados em um dos hospitais em que esteja cadastrado estes cariam diferentes dos dados presentes nos outros hospitais.

Caso 2 - Não há problema de sincronia, pois o cadastro é único. • Trafego de Rede

Caso 1 - Para corrigir o problema de sincronia é gerado muito tráfego de rede, pois os dados devem ser enviados a todos os hospitais para correta atualização.

Caso 2 - O trafego de rede é menor, pois os dados estão localizados em apenas um local.

• Novo cadastro

Caso 1 - Necessita de novo cadastro para o paciente em cada hospital que deseje marcar consulta.

Caso 2 - O cadastro é realizado uma única vez. • Tolerância a falhas

Caso 1 - Em caso de impossibilidade de acesso a um dos hospitais, outro hospital que possua o cadastro do paciente não será afetado. A consulta não poderá ser marcada no hospital inacessível, mas nos outros isto continua sendo possível.

Caso 2 - Em caso de impossibilidade de acesso ao banco único nenhum hospital poderá marcar consulta.

Após análise dos prós e contras de cada caso escolheu-se a segunda opção. Apesar dessa opção aparentemente tornar-se um gargalo isto não ocorre. O gargalo na verdade estaria no módulo apresentação, pela alta taxa de solicitações, ou no módulo hospital, de-vido ao grande tráfego de dados. Já o problema de tolerância a falhas pode ser contornado com replicação dos dados em um servidor de reserva.

O módulo SUS gerencia então os dados dos pacientes, através de um cadastro único. Para acesso pelos outros módulos foi implementado um sistema de serviço Web, buscando todas as vantagens que os serviços Web proporcionam. Devido ao fato de ser modular e constituir-se num serviço Web outros sistemas poderão fazer uso de suas funcionalidades. Os hospitais conforme sua preferência podem manter uma cópia dos dados atualizados dos pacientes ou simplesmente armazenar os números de registro no SUS dos pacientes. 3.3.2.1 Utilizando Serviços Web

Todos os módulos implementam seu serviço Web. Para mostrar como isso é feito e evitar repetições desnecessárias o módulo SUS é usado como base. Como dito na seção 2.7, WSDL descreve o serviço em um protocolo adequado, no caso desse projeto, no protocolo SOAP. A seguir alguns trechos da descrição do serviço do módulo SUS são apresentados.

Figura 13: Nome e Localização do serviço no arquivo SUS.wsdl .

Esse trecho do arquivo SUS.wsdl, presente na gura 13, indica que o serviço SUS pode ser encontrado em:

Caso algum cliente deseje acessar o módulo SUS para realizar alguma de suas operações disponíveis, poderá, acessando o arquivo SUS.wsdl, vericar onde o serviço está disponi-bilizado.

Figura 14: Uma das diversas operações publicadas no arquivo SUS.wsdl.

Neste outro trecho do arquivo SUS.wsdl, presente na gura 14, uma das diversas operações disponíveis é apresentada. No arquivo WSDL a interface de comunicação e seus parâmetros estão presentes. A seguir nas guras 15 e 16 verica-se os pacotes transmitidos no formato SOAP, após resposta e solicitação para a chamada do método getMedicos(3).

Figura 15: Resposta SOAP transmitida via HTTP.

Todos os médicos com especialidade 3 serão buscados. Neste projeto foi especicado que especialidade 3 corresponde a especialidade oftalmologista.Após a requisição ter sido feita e o serviço disponibilizado é enviado uma resposta SOAP ao requisitor, contendo todos os médico especialistas em oftalmologia. Observe que o formato na qual os arquivos estão escritos e foram enviados é XML.

Figura 16: Requisição SOAP transmitida via HTTP.

Os pacotes SOAP podem ser encapsulados em diversos protocolos de transporte. HTTP é utilizado nesse trabalho, por tratar-se de um protocolo simples e popular. A gura 17 apresenta o cabeçalho do encapsulamento SOAP em uma mensagem HTTP.

Figura 17: Cabeçalho HTTP de uma requisição SOAP encapsulada A seguir uma representação do banco de dados bdsus é apresentada. 3.3.2.2 Banco de Dados bdsus

O banco de dados bdsus é composto por uma tabela PACIENTES com os dados observados no levantamento de requisitos. Esse banco de dados pode estar localizado no servidor do sistema ou num servidor especíco(servidor do SUS). A gura 18 representa o banco e sua tabela PACIENTES.

3.3.3 Módulo de Apresentação

O módulo de Apresentação é responsável pelo redirecionamento das chamadas dos usuários para os hospitais. Para tal ele mantém armazenado em um banco de dados as URLs dos hospitais, que implementam a interface denida para os serviços Web. Con-forme as chamadas dos usuários ele redireciona para o Hospital alvo ou busca entre os Hospitais cadastrados a melhor opção de agendamento de consulta, por exemplo a con-sulta disponível em período mais próximo.

3.3.3.1 Utilizando Struts

Devido a necessidade de redirecionamento das chamadas dos usuários para os hospitais e selecionar as páginas de exibição corretas, este módulo trabalha com a ferramenta Struts para facilitar este processo. Struts utiliza seu próprio descritor de distribuição de serviços para inicializar os recursos necessários. Este arquivo contém as ActionForms para receber as entradas dos usuários, ActionMappings para direcionar as ações no lado do servidor e ActionForwards para selecionar as páginas utilizadas para interação com os usuários.

A seguir pode-se visualizar na gura 19 a URL de redirecionamento ("/pacientes"), a classe de destino ("PacientesAction.java"), o parâmetro ("acao") para a escolha do método a ser utilizado e as paginas JSP ("cadastraPaciente.jsp, listaPaciente.jsp, buscar-Paciente.jsp") que estão mapeadas para utilização posterior.

Figura 19: Trecho do arquivo de conguração do Struts "struts-cong.xml". Após o mapeamento das ações possíveis basta que as páginas JSP realizem a devida chamada à ação desejada. O método que processa a busca de pacientes na classe Paciente-sAction.java está representado na gura 20. Este método busca pacientes através do nome ou do cartão SUS conforme o parâmetro "opcao" e através de chamadas aos métodos da

classe SUSProxy. SUSProxy faz as chamadas ao Serviço SUS, extrai as informações dos pacotes SOAP e as converte em objetos através da API do AXIS.

Figura 20: Método da classe destino "PacientesAction.java".

3.3.3.2 Banco de Dados bdagendador

O banco de dados bdagendador é composto por duas tabelas: HOSPITAIS e USUA-RIOS. A tabela HOSPITAIS corresponde aos hospitais cadastrados no sistema. A tabela USUARIOS identica os usuários responsáveis e com permissão para logar no sistema e executar as operações disponíveis. Para autenticação o usuário tem que estar devida-mente cadastrado com login e senha. Esse banco de dados está localizado no servidor do sistema. A gura 21 representa o banco.

3.3.4 Considerações do sistema

O sistema apresentado possibilita a descentralização do agendamento de consultas, uma vez que vários usuários podem acessar o sistema, ao mesmo tempo, de diversos lugares. Permite assim que os pacientes agendem suas consultas para os hospitais de outros locais além dos próprios hospitais. O acesso pode ser realizado através da URL em um browser pelo usuário cadastrado (login e senha) no sistema. O paciente irá então se dirigir aos locais com máquinas disponíveis e usuários cadastrados para solicitar a marcação de sua consulta. O sistema poderia, por exemplo, ser acessado dos postos de saúde da região e manipulados no browser de um computador conectado por funcionários devidamente treinados e cadastrados.

Figura 22: Estrutura utilizada no sistema como um todo.

A gura 22 nos mostra como a descentralização é feita. As solicitações são realizadas pelos usuários do sistema, funcionários de postos de saúde por exemplo, repassando as requisições para os hospitais ou para o módulo SUS. Assim consultas podem ser agendadas de um único local (posto de saúde, hospital, etc.) para vários hospitais a partir da URL do sistema. O Sistema Agendador presente no centro da gura trata-se do Módulo de Apresentação, responsável pelo redirecionamento das chamadas realizadas pelos outros

módulos.

O sistema está então congurado em três módulos, todos eles conectados através de serviços Web, todos utilizam hibernate para mapeamento O/R e o módulo de apresentação utiliza Struts como framework para facilitar a conguração do sistema no padrão MVC.

4 Conclusões e trabalhos futuros

É apresentada a conclusão do projeto e logo em seguida algumas sugestões de trabalhos futuros.

4.1 Conclusão Final

O presente trabalho mostra a viabilidade de se construir um sistema real integrado, para um sistema de agendamento de consultas, com base nas tecnologias de serviços Web. Ele representa uma base para uma possível solução de um dos problemas sociais vividos pela comunidade carente das grandes cidades brasileiras: as las para marcação de consultas do SUS (Sistema Único de Saúde).

Com as tecnologias disponíveis no presente, com a velocidade do tráfego de infor-mações, não é mais aceitável que uma pessoa tenha que se locomover vários quilometros para marcar uma consulta. Distribuindo a marcação de consultas diminui-se o tempo de espera nas las, de locomoção e o gasto com locomoção para se chegar em um dos diversos hospitais disponíveis, muitas vezes sem a garantia de marcação da consulta desejada.

Um sistema real poderá ser implantado, utilizando apenas ferramentas livres, e ainda ser de grande valia para a sociedade, minimizando os problemas visualizados e constatados pelo Ministério da Saúde (22).

4.2 Trabalhos Futuros

• Enquadrar os dados de pacientes conforme o padrão do SUS. • Inserção de segurança ao Serviço Web.

• Possibilitar o uso do sistema em centrais moveis de marcação de consultas. • Melhorar a interface gráca para o protótipo.

Referências

1 DEITEL H. M. DEITEL, P. J. Java Como Programar. 4. ed. Porto Alegre: BOOKMAN, 2003. 1386 p.

2 SUN. JAVA. [S.l.]: URL:http://java.sun.com/, Fevereiro 2006. Internet. 3 ECLIPSE. [S.l.]: URL:http://www.eclipse.org/, Outubro 2005. Internet. 4 APACHE. Tomcat. [S.l.]: URL:http://jakarta.apache.org/tomcat/, Outubro 2005. Internet.

5 APACHE. AXIS. [S.l.]: URL:http://ws.apache.org/axis/, Outubro 2005. Internet. 6 APACHE. STRUTS. [S.l.]: URL:http://struts.apache.org/, Outubro 2005. Internet.

7 BAUER CHRISTIAN. KING, G. Hibernate em Ação O Guia Denitivo para o Hibernate. 1 ed.. ed. Rio de Janeiro: Ciência Moderna, 2005. 560 p.

8 MYSQL. [S.l.]: URL:http://www.mysql.com/, Outubro 2005. Internet.

9 KURNIAWAN, B. Java para a Web com Servlets, JSP e EJB. Rio de Janeiro: Ciência Moderna Ltda, 2002. 808 p.

10 DEITEL, H. M. e. a. Web Services A technical Introduction. New Jersey: Prentice Hall, 2003. 494 p.

11 JBOSS. Hibernate. [S.l.]: URL:http://http://www.hibernate.org/, Outubro 2005. Internet.

12 HOUGLAND DAMON. TAVISTOCK, A. Core JSP. [S.l.]: Prentice Hall, 2001. 391 p.

13 GALBRAITH, B. e. a. Professional Java Web Services. 1 ed. ed. [S.l.]: Wrox Press, 2002. 575 p.

14 CERAMI, E. Web Services Essencials. 1. ed. Tókio: O'Reilly, 2002. 304 p. 15 ECLIPSE. WST. [S.l.]: URL:http://eclipse.org/webtools/wst/main.xml, Outubro 2005. Internet.

16 APACHE. SOAP. [S.l.]: URL:http://ws.apache.org/soap/, Outubro 2005. Internet.

18 HIGTOWER, R. Jakarta-Struts Live. Colorado: SourceBeat, 2004. 273 p. 19 PHPMYADMIN. [S.l.]: URL:http://www.phpmyadmin.net/, Outubro 2005. Internet.

20 SUN. JDBC. [S.l.]: URL:http://java.sun.com/products/jdbc/, Outubro 2005. Internet.

21 ANSELMO, F. Tudo o que você queria saber sobre JDBC. Florianópolis: Visual Books, 2001. 200 p.

22 SAúDE, M. da. QUALISUS. [S.l.]: URL:http://www.saude.gov.br, Fevereiro 2006. Internet.

5 Anexos

5.1 Módulo de Apresentação

5.1.1 SistemaAgendador/JavaSource/actions/Gerenciador.java

package actions; import javax.servlet.ServletException; import org.apache.struts.action.ActionServlet; import bd.hibernate.Banco;

public class Gerenciador extends ActionServlet{ @Override

public void init() throws ServletException { super.init();

Banco.getInstance(); }

5.1.2 SistemaAgendador/JavaSource/actions/HospitaisAction.java

package actions; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.commons.beanutils.BeanUtils; import org.apache.struts.action.ActionForm; import org.apache.struts.action.ActionForward; import org.apache.struts.action.ActionMapping; import org.apache.struts.actions.DispatchAction; import service.HospitalProxy; import bd.hibernate.tabelas.Hospitais; import beans.Hospital;

public class HospitaisAction extends DispatchAction { Hospitais hospitais = Hospitais.getInstance();

HospitalProxy serviceHospital = new HospitalProxy();

public ActionForward cadastro(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request,

HttpServletResponse response) throws Exception { return actionMapping.ndForward("telaCadastro"); }

public ActionForward cadastrar(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request,

HttpServletResponse response) throws Exception { Hospital hospital = new Hospital();

BeanUtils.copyProperties(hospital, actionForm); hospitais.set(hospital);

return actionMapping.ndForward("telaCadastro"); }

public ActionForward listar(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request,

HttpServletResponse response) throws Exception { request.setAttribute("hospitais", hospitais.get()); return actionMapping.ndForward("listar"); }

public ActionForward mostrar(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request,

HttpServletResponse response) throws Exception {

int hospital = Integer.valueOf(request.getParameter("hospital")); Hospital hospital2 = hospitais.get(hospital);

serviceHospital.setEndpoint(hospital2.getUrl()); System.out.println(hospital2.getNome());

return actionMapping.ndForward(""); }

5.1.3 SistemaAgendador/JavaSource/actions/MedicosAction.java

package actions; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.struts.action.ActionForm; import org.apache.struts.action.ActionForward; import org.apache.struts.action.ActionMapping; import service.HospitalProxy;;

public class MedicosAction {

HospitalProxy proxy = new HospitalProxy();

public ActionForward busca(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request,

HttpServletResponse response) throws Exception { return actionMapping.ndForward("telaBusca"); }

public ActionForward buscar(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request,

HttpServletResponse response) throws Exception { request.setAttribute("pacientes",

proxy.getMedicos(request.getParameter("nome"))); return actionMapping.ndForward("listar"); }

5.1.4 SistemaAgendador/JavaSource/actions/PacientesAction.java

package actions; import java.util.LinkedList; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.commons.beanutils.BeanUtils; import org.apache.struts.action.ActionForm; import org.apache.struts.action.ActionForward; import org.apache.struts.action.ActionMapping; import org.apache.struts.action.DynaActionForm; import org.apache.struts.actions.DispatchAction; import beans.Paciente; import service.SUSProxy; import uteis.ConversorPaciente;

public class PacientesAction extends DispatchAction { SUSProxy proxy = new SUSProxy();

public ActionForward cadastro(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request,

HttpServletResponse response) throws Exception { return actionMapping.ndForward("telaCadastro"); }

public ActionForward busca(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request,

HttpServletResponse response) throws Exception { return actionMapping.ndForward("telaBusca");

public ActionForward cadastrar(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request,

HttpServletResponse response) throws Exception {

ConversorPaciente paciente = new ConversorPaciente(); BeanUtils.copyProperties(paciente, actionForm);

System.out.print(paciente.getNome());

proxy.cadastrarPaciente(paciente.converter());

return actionMapping.ndForward("telaCadastro"); }

public ActionForward buscar(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request,

HttpServletResponse response) throws Exception {

DynaActionForm form = (DynaActionForm) actionForm; String opcao = form.getString("opcao");

if("NOME".equals(opcao))

request.setAttribute("pacientes", proxy.buscar(form.getString("nome"))); else{

LinkedList<Paciente> pacientes = new LinkedList<Paciente>();

pacientes.add(proxy.getPaciente(Long.valueOf(form.getString("nome")))); request.setAttribute("pacientes", pacientes);

}

return actionMapping.ndForward("listar"); }

public ActionForward mostrar(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request,

HttpServletResponse response) throws Exception {

request.getSession().setAttribute("paciente_", new ConversorPaciente().

converter(proxy.getPaciente(Long.valueOf(request.getParameter("paciente"))))); return actionMapping.ndForward("telaCadastro");

} }

5.1.5 SistemaAgendador/JavaSource/actions/UsuariosAction.java

package actions; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.commons.beanutils.BeanUtils; import org.apache.struts.action.ActionForm; import org.apache.struts.action.ActionForward; import org.apache.struts.action.ActionMapping; import org.apache.struts.action.DynaActionForm; import org.apache.struts.actions.DispatchAction; import bd.hibernate.tabelas.Usuarios; import beans.Usuario;

public class UsuariosAction extends DispatchAction { Usuarios usuarios = Usuarios.getInstance();

public ActionForward cadastro(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request,

HttpServletResponse response) throws Exception { return actionMapping.ndForward("telaCadastro"); }

public ActionForward cadastrar(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request,

HttpServletResponse response) throws Exception { Usuario usuario = new Usuario();

BeanUtils.copyProperties(usuario, actionForm); usuarios.set(usuario);

return actionMapping.ndForward("telaCadastro"); }

5.1.6 SistemaAgendador/JavaSource/actions/UtilitariosAction.java

package actions;

public class UtilitariosAction { }

5.1.7 SistemaAgendador/JavaSource/bd/hibernate/Banco.java

package bd.hibernate;

import org.hibernate.Session;

import org.hibernate.SessionFactory; import org.hibernate.cfg.Conguration; public class Banco {

private static Banco banco; SessionFactory sessionFactory; private Banco() {

sessionFactory = new Conguration().congure().buildSessionFactory(); }

public static Banco getInstance() { if (banco == null)

banco = new Banco(); return banco;

}

public Session getSession() {

return sessionFactory.openSession(); }

5.1.8 SistemaAgendador/JavaSource/bd/hibernate/tabelas/Hospitais.java

package bd.hibernate.tabelas; import java.util.List ; import org.hibernate.Query; import org.hibernate.Session; import org.hibernate.Transaction; import bd.hibernate.Banco; import beans.Hospital; public class Hospitais {

private static Hospitais hospitais ; private Banco banco;

public static Hospitais getInstance() { if (hospitais == null)

hospitais = new Hospitais(); return hospitais;

}

private Hospitais(){

banco = Banco.getInstance(); }

public void set(Hospital hospital){ Session session = banco.getSession();

Transaction tx = session.beginTransaction(); session .save(hospital );

tx.commit(); session . close (); }

public List<Hospital> get() {

Session session = banco.getSession();

Transaction tx = session.beginTransaction();

Query query = session.createQuery("from Hospital order by nome asc"); List<Hospital> hospitais = query.list();

tx.commit(); session . close (); return hospitais; }

public Hospital get(int hospital) { Session session = banco.getSession();

Transaction tx = session.beginTransaction();

Hospital h = (Hospital) session .get(Hospital.class, hospital ); tx.commit(); session . close (); return h; } /∗∗ ∗ @param args ∗/

public static void main(String[] args) { // TODO Auto−generated method stub }

5.1.9 SistemaAgendador/JavaSource/bd/hibernate/tabelas/Usuarios.java

package bd.hibernate.tabelas; import java.util.List ; import org.hibernate.Query; import org.hibernate.Session; import org.hibernate.Transaction; import bd.hibernate.Banco; import beans.Hospital; import beans.Usuario; public class Usuarios {

private static Usuarios usuarios; private Banco banco;

public static Usuarios getInstance() { if (usuarios == null)

usuarios = new Usuarios(); return usuarios;

}

private Usuarios(){

banco = Banco.getInstance(); }

public void set(Usuario usuario){

Session session = banco.getSession();

Transaction tx = session.beginTransaction(); session .save(usuario);

tx.commit(); session . close (); }

public List<Usuario> get() {

Session session = banco.getSession();

Transaction tx = session.beginTransaction();

Query query = session.createQuery("from Usuario"); List<Usuario> usuarios = query.list();

tx.commit(); session . close (); return usuarios; }

public Usuario get(int usuario) {

Session session = banco.getSession();

Transaction tx = session.beginTransaction();

Usuario u = (Usuario) session.get(Usuario.class, usuario); tx.commit(); session . close (); return u; } /∗∗ ∗ @param args ∗/

public static void main(String[] args) { // TODO Auto−generated method stub }

5.1.10 SistemaAgendador/JavaSource/beans/Consulta.java

/∗∗

∗ Consulta.java ∗

∗ This le was auto−generated from WSDL

∗ by the Apache Axis 1.2.1 Jun 14, 2005 (09:15:57 EDT) WSDL2Java emitter. ∗/

package beans;

public class Consulta implements java.io.Serializable { private java.lang.String data;

private java.lang.String hora; private long id;

private beans.Medico medico; private beans.Paciente paciente; public Consulta() { } public Consulta( java.lang.String data, java.lang.String hora, long id, beans.Medico medico, beans.Paciente paciente) { this.data = data; this.hora = hora; this.id = id; this.medico = medico; this.paciente = paciente; } /∗∗

∗ Gets the data value for this Consulta. ∗

∗ @return data ∗/

public java.lang.String getData() { return data;

}

/∗∗

∗ Sets the data value for this Consulta. ∗

∗ @param data ∗/

public void setData(java.lang.String data) { this.data = data;

}

/∗∗

∗ Gets the hora value for this Consulta. ∗

∗ @return hora ∗/

public java.lang.String getHora() { return hora;

}

/∗∗

∗ Sets the hora value for this Consulta. ∗

∗ @param hora ∗/

this.hora = hora; }

/∗∗

∗ Gets the id value for this Consulta. ∗

∗ @return id ∗/

public long getId() { return id;

}

/∗∗

∗ Sets the id value for this Consulta. ∗

∗ @param id ∗/

public void setId(long id) { this.id = id;

}

/∗∗

∗ Gets the medico value for this Consulta. ∗

∗ @return medico ∗/

public beans.Medico getMedico() { return medico;

}

∗ Sets the medico value for this Consulta. ∗

∗ @param medico ∗/

public void setMedico(beans.Medico medico) { this.medico = medico;

}

/∗∗

∗ Gets the paciente value for this Consulta. ∗

∗ @return paciente ∗/

public beans.Paciente getPaciente() { return paciente;

}

/∗∗

∗ Sets the paciente value for this Consulta. ∗

∗ @param paciente ∗/

public void setPaciente(beans.Paciente paciente) { this.paciente = paciente;

}

private java.lang.Object __equalsCalc = null;

public synchronized boolean equals(java.lang.Object obj) { if (!( obj instanceof Consulta)) return false;

Consulta other = (Consulta) obj; if (obj == null) return false; if (this == obj) return true; if (__equalsCalc != null) {

return (__equalsCalc == obj); }

__equalsCalc = obj; boolean _equals; _equals = true &&

((this.data==null && other.getData()==null) || (this.data!=null &&

this.data.equals(other.getData()))) &&

((this.hora==null && other.getHora()==null) || (this.hora!=null &&

this.hora.equals(other.getHora()))) && this.id == other.getId() &&

((this.medico==null && other.getMedico()==null) || (this.medico!=null &&

this.medico.equals(other.getMedico()))) &&

((this.paciente==null && other.getPaciente()==null) || (this.paciente!=null &&

this.paciente.equals(other.getPaciente ()))); __equalsCalc = null;

return _equals; }

private boolean __hashCodeCalc = false; public synchronized int hashCode() {

if (__hashCodeCalc) { return 0; } __hashCodeCalc = true; int _hashCode = 1; if (getData() != null) { _hashCode += getData().hashCode(); } if (getHora() != null) { _hashCode += getHora().hashCode(); }