SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE...
1
Transcript of SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE...
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE
CONSULTAS CLÍNICAS
PABLO DOS SANTOS ALVES
BLUMENAU 2007
2007/6-08
PABLO DOS SANTOS ALVES
SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE
CONSULTAS CLÍNICAS
Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Sistemas de Informação - Bacharelado.
Prof. Alexander Roberto Valdameri, Mestre - Orientador
BLUMENAU 2007
2007/6-08
SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE
CONSULTAS CLÍNICAS
Por
PABLO DOS SANTOS ALVES
Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:
______________________________________________________ Presidente: Prof. Alexander Roberto Valdameri, Mestre – Orientador, FURB
______________________________________________________ Membro: Prof. Ricardo Alencar de Azambuja, Mestre – FURB
______________________________________________________ Membro: Prof. Everaldo Artur Grahl, Mestre – FURB
Blumenau, dia 26 de junho de 2007
Dedico este trabalho aos meus esforços e à maior fortaleza de minha vida: Vanda Marques, minha mãe.
AGRADECIMENTOS
À Deus, pela vida, a morte, e às inumeráveis possibilidades de ser e mudar.
À minha mãe Vanda, pelo exemplo e por seu amor.
Aos grandes amigos João Júnior, Valacio e Alexsander, assim como meus irmãos Igor
e Erick, pelo apoio incondicional em todos os momentos.
À namorada Kerolyn, pela inspiração, atenção e paciência nos momentos mais difíceis
no desenvolvimento deste trabalho.
À humanidade e a prospecção da tecnologia, por suas infinitas possibilidades.
Um homem é um sucesso se pula da cama pela manhã, vai dormir à noite e, nesse meio tempo, faz o que gosta.
Bob Dylan
RESUMO
Este trabalho apresenta uma aplicação para automatizar o processo de agendamento, confirmação e gerenciamento de consultas clínicas on-line, através de um portal corporativo. O sistema foi concebido para utilização tanto pelos profissionais de uma clínica de fisioterapia, quanto para pacientes. Tem a função principal de permitir o agendamento e confirmação de consultas via Internet, informando os usuários do sistema através do envio de mensagens de notificação. Para gerenciar o aplicativo foi utilizado o servidor de aplicações Java JBoss e container WEB Tomcat. Foi utilizada tecnologia de Portais e Portlets em conjunto com a JSF, implementando por sua vez a arquitetura MVC. Para a camada de Banco de Dados foi utilizada a JPA e EJB 3.0 com o padrão de projeto DAO, e tendo como provedor o framework de persistência objeto relacional Hibernate.
Palavras-chave: Agendamento. Fisioterapia. Portais.
ABSTRACT
This work presents a tool to automate the process of scheduling, confirmation and management of clinical appointments on-line, through a corporate portal. The system was conceived as much for the usage by professionals of a physiotherapy clinic, as for the patients. It has the main function of allowing the schedule and confirmation of clinical appointments through the Internet, informing the users of the system by sending notification messages. In order to manage the application, the application Java Server Jboss and container WEB Tomcat were used. The technology of Portals and Portlets joined with JSF were also used, implementing the MVC architecture. Concerning the database layer, it was used the JPA and EJB 3.0 with the project pattern DAO, and having as a provider the framework of object relational persistence Hibernate.
Key-words: Scheduling. Physiotherapy. Portals.
LISTA DE ILUSTRAÇÕES
Figura 1 – Página inicial do Portal Fisioterapia .......................................................................26
Figura 2 – Página inicial do portal Fisioterapia.com................................................................27
Figura 3 – Pacotes dos casos de uso.........................................................................................44
Figura 4 – Casos de uso dos profissionais da clínica ...............................................................45
Figura 5 – Casos de uso dos pacientes .....................................................................................46
Figura 6 – Diagrama de classes de domínio.............................................................................48
Figura 7 – Pacotes do módulo WEB do diagrama de classes de projeto..................................48
Figura 8 – Diagrama de classes do pacote br.com.sagcc.portlets.............................................49
Figura 9 – Diagrama de classes do pacote br.com.sagcc.control .............................................50
Figura 10 – Diagrama de classes do pacote br.com.sagcc.validator ........................................51
Figura 11 – Diagrama de classes do pacote br.com.sagcc.util.mail .........................................52
Figura 12 – Diagrama de classes do pacote br.com.sagcc.util .................................................53
Figura 13 – Diagrama de classes do pacote br.com.sagcc.servlet............................................54
Figura 14 – Pacotes do módulo EJB do diagrama de classes de projeto..................................54
Figura 15 – Diagrama de classes do pacote br.com.sagcc.dao.interfaces ................................55
Figura 16 – Diagrama de classes do pacote br.com.sagcc.dao.ejb...........................................56
Quadro 1 – Trecho do arquivo que contém as regras de navegação para cada Portlet ............60
Quadro 2 – Trecho da classe “Paciente” demonstrando o uso de anotações............................61
Quadro 3 – Arquivo que contém as configurações de conexão com o BD..............................62
Quadro 4 – Arquivo que contém as configurações da JPA e Hibernate ..................................62
Quadro 5 – Trecho de código responsável por localizar todos agendamentos de um paciente63
Quadro 6 – Trecho de código responsável por iniciar uma transação com o BD a fim de
buscar todos agendamentos de um paciente ..........................................................64
Quadro 7 – Consulta declarada para recuperar todos agendamentos de um paciente..............65
Figura 17 – Ilustração do funcionamento do sistema do ponto de vista do usuário.................66
Figura 18 – Página de apresentação do portal ..........................................................................67
Figura 19 – Acesso ao sistema pelo administrador do portal ...................................................67
Figura 20 – Página de administração do portal ........................................................................68
Figura 21 – Cadastro de pacientes pelo administrador do portal .............................................68
Figura 22 – Consulta de pacientes pelo administrador do portal .............................................69
Figura 23 – Resultado da consulta de pacientes pelo administrador do portal.........................69
Figura 24 – Alteração de um paciente pelo administrador do portal........................................70
Figura 25 – Cadastro de fisioterapeutas pelo administrador do portal .....................................70
Figura 26 – Consulta de fisioterapeutas pelo administrador do portal .....................................71
Figura 27 – Resultado da consulta de fisioterapeutas pelo administrador do portal ................71
Figura 28 – Alteração de um fisioterapeuta pelo administrador do portal ...............................72
Figura 29 – Cadastro de usuários de notificação pelo administrador do portal .......................72
Figura 30 – Consulta de usuários de notificação pelo administrador do portal .......................73
Figura 31 – Resultado da consulta de usuários de notificação pelo administrador do portal...73
Figura 32 – Alteração de um usuário de notificação pelo administrador do portal..................74
Figura 33 – Atalho para o cadastro de um usuário do portal....................................................75
Figura 34 – Lista de usuários cadastrados no portal.................................................................75
Figura 35 – Cadastro de um usuário do portal..........................................................................76
Figura 36 – Cadastro de informações detalhadas de um usuário do portal ..............................76
Figura 37 – Associação de papéis a um usuário do portal........................................................77
Figura 38 – Atalho para acessar as comunidades definidas no portal ......................................78
Figura 39 – Lista de comunidades do portal ............................................................................79
Figura 40 – Lista de usuários de uma comunidade ..................................................................79
Figura 41 – Associação de usuários a uma comunidade..........................................................80
Figura 42 – Visão da agenda de pacientes por mês..................................................................80
Figura 43 – Consulta do paciente da agenda de pacientes .......................................................81
Figura 44 – Associação de um paciente à agenda de pacientes................................................81
Figura 45 – Seleção do mês e ano do agendamento da agenda de pacientes ...........................82
Figura 46 – Visão da agenda de pacientes por ano ..................................................................83
Figura 47 – Agendamentos do dia de um determinado paciente..............................................83
Figura 48 – Lista com todos agendamentos de um determinado paciente ...............................84
Figura 49 – Página de inclusão de um novo agendamento pela agenda de pacientes..............84
Figura 50 – Correio de notificação acessado por um webmail.................................................85
Figura 51 – Página de alteração de um agendamento pela agenda de pacientes......................86
Figura 52 – Consulta de um agendamento cancelado por meio da agenda de pacientes .........87
Figura 53 – Consulta de um agendamento rejeitado pela clínica por meio da agenda de
pacientes ................................................................................................................87
Figura 54 – Consulta de um agendamento confirmado pela clínica por meio da agenda de
pacientes ................................................................................................................88
Figura 55 – Visão da agenda de fisioterapeutas por mês .........................................................88
Figura 56 – Consulta do fisioterapeuta da agenda de fisioterapeutas ......................................89
Figura 57 –Associação de um fisioterapeuta à agenda de fisioterapeutas................................90
Figura 58 – Seleção do mês e ano do agendamento da agenda de fisioterapeutas...................90
Figura 59 – Visão da agenda de fisioterapeutas por ano e seleção do ano do agendamento ...91
Figura 60 – Agendamentos do dia de um determinado fisioterapeuta .....................................91
Figura 61 – Lista com todos agendamentos de um determinado fisioterapeuta.......................92
Figura 62 – Página de inclusão de um novo agendamento pela agenda de fisioterapeutas .....93
Figura 63 – Página de alteração de um agendamento pela agenda de fisioterapeutas .............93
Figura 64 – Consulta de um agendamento cancelado por meio da agenda de fisioterapeutas.94
Figura 65 – Consulta de um agendamento rejeitado pela clínica por meio da agenda de
fisioterapeutas ........................................................................................................94
Figura 66 – Consulta de um agendamento confirmado pela clínica por meio da agenda de
fisioterapeutas ........................................................................................................95
Figura 67 – Visão da agenda geral por mês .............................................................................95
Figura 68 – Seleção do mês e ano do agendamento da agenda geral .......................................96
Figura 69 – Visão da agenda geral por ano e seleção do ano do agendamento........................96
Figura 70 – Agendamentos do dia listados na agenda geral.....................................................97
Figura 71 – Lista com todos agendamentos .............................................................................97
Figura 72 – Página de inclusão de um novo agendamento pela agenda geral..........................98
Figura 73 – Página de alteração de um agendamento pela agenda geral .................................99
Figura 74 – Consulta de um agendamento cancelado por meio da agenda geral.....................99
Figura 75 – Consulta de um agendamento rejeitado pela clínica por meio da agenda geral..100
Figura 76 – Consulta de um agendamento confirmado pela clínica por meio da agenda geral
.............................................................................................................................100
Figura 77 – Página de apresentação do portal ........................................................................101
Figura 78 – Cadastro de paciente pela página de apresentação do portal ..............................102
Figura 79 – Confirmação de cadastro de paciente pela página de apresentação do portal.....102
Figura 80 – Acesso ao sistema pelo paciente .........................................................................103
Figura 81 – Página de alteração do cadastro do paciente .......................................................103
Figura 82 – Visão da agenda do paciente por mês .................................................................104
Figura 83 – Seleção do mês e ano do agendamento da agenda do paciente...........................104
Figura 84 – Visão da agenda do paciente por ano..................................................................105
Figura 85 – Agendamentos do dia do paciente.......................................................................105
Figura 86 – Lista com todos agendamentos do paciente ........................................................106
Figura 87 – Página de inclusão de um novo agendamento pela agenda do paciente .............106
Figura 88 – Página de alteração de um agendamento pela agenda do paciente .....................107
Figura 89 – Consulta de um agendamento cancelado por meio da agenda do paciente.........107
Figura 90 – Consulta de um agendamento rejeitado pela clínica por meio da agenda do
paciente ................................................................................................................108
Figura 91 – Consulta de um agendamento confirmado pela clínica por meio da agenda do
paciente ................................................................................................................108
LISTA DE TABELAS
Tabela 1 - Ferramentas utilizadas na especificação e implementação .....................................57
Tabela 2 - Tecnologias utilizadas na especificação e implementação......................................58
LISTA DE SIGLAS
AJAX - Asynchronous Javascript And XML
API – Application Programming Interface
ASF - Apache Software Foundation
BD – Banco de Dados
CASE - Computer Aided Software Enginnering
CREFITO - Conselho Regional de Fisioterapia e Terapia Ocupacional
CRUD - Create, Read, Update and Delete
DAO - Data Access Object
EA - Enterprise Architect
EAR – Enterprise Archive
EJB - Enterprise JavaBeans
EJB-QL - Enterprise JavaBeans Query Language
HTML - HyperText Markup Language
HTTP - HyperText Transfer Protocol
IDE - Itegrated Development Environment
JAR – Java Archive
JDBC – Java Database Connectivity
JDK - Java 2 Platform Standard Edition Development Kit
J2EE - Java 2 Platform Enterprise Edition
J2SE - Java 2 Platform Standard Edition
JMS - Java Messaging Service
JNDI - Java Naming and Directory Interface
JPA – Java Persistence API
JRE - Java Runtime Enviroment
JSR - Java Specification Request
JSF – JavaServer Faces
JSP – JavaServer Pages
JTA - Java Transaction API
JTS - Java Transaction Service
JVM – Java Virtual Machine
LOV – List Of Values
MVC – Model View Controller
OMG - Object Management Group
OO – Orientação a Objetos
PEP – Prontuário Eletrônico do Paciente
POO – Programação Orientada a Objetos
SAGCC – Sistema de Agendamento e Gerenciamento de Consultas Clínicas
SGBD – Sistema de Gerenciamento de Banco de Dados
SMS - Short Message Service
SMTP - Simple Mail Transfer Protocol
SQL - Structured Query Language
TI – Tecnologia da Informação
UML - Unified Modeling Language
URL - Uniform Resource Locator
W3C - World Wide Web Consortium
WAR – WEB Archive
WEB – World Wide Web
XML - eXtensible Markup Language
SUMÁRIO
1 INTRODUÇÃO..................................................................................................................17
1.1 OBJETIVOS DO TRABALHO ........................................................................................19
1.2 ESTRUTURA DO TRABALHO......................................................................................19
2 FUNDAMENTAÇÃO TEÓRICA....................................................................................21
2.1 INFORMÁTICA EM SAÚDE..........................................................................................21
2.1.1 A Internet e a saúde.........................................................................................................22
2.1.2 A informática e a fisioterapia..........................................................................................23
2.2 PORTAIS DA INTERNET ...............................................................................................24
2.2.1 Portais quanto às funções ................................................................................................24
2.2.2 Portais quanto ao contexto ..............................................................................................25
2.2.3 Portais e a fisioterapia .....................................................................................................26
2.2.4 O portal Liferay...............................................................................................................27
2.2.5 Portlets ............................................................................................................................29
2.3 PADRÕES DE PROJETO DE SOFTWARE....................................................................30
2.3.1 O padrão MVC................................................................................................................31
2.3.2 O padrão DAO ................................................................................................................31
2.3.2.1 Mecanismos de persistência e mapeamento objeto/relacional .....................................32
2.4 TRABALHOS CORRELATOS........................................................................................33
3 DESENVOLVIMENTO DA APLICAÇÃO....................................................................35
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO.......................35
3.2 ESPECIFICAÇÃO ............................................................................................................43
3.2.1 Diagrama de casos de uso ...............................................................................................43
3.2.2 Diagrama de classes ........................................................................................................47
3.3 IMPLEMENTAÇÃO ........................................................................................................57
3.4 OPERACIONALIDADE DA IMPLEMENTAÇÃO........................................................66
3.4.1 Módulo da clínica de fisioterapia....................................................................................66
3.4.2 Módulo do paciente.......................................................................................................101
3.5 RESULTADOS E DISCUSSÃO ....................................................................................109
4 CONSIDERAÇÕES FINAIS..........................................................................................111
4.1 EXTENSÕES ..................................................................................................................111
REFERÊNCIAS BIBLIOGRÁFICAS ...............................................................................114
APÊNDICE A – Definição das principais classes..............................................................117
APÊNDICE B – E-mails de notificação..............................................................................129
17
1 INTRODUÇÃO
A Tecnologia da Informação (TI) é utilizada atualmente no intuito de permitir
dinamizar processos, medida essencial para o sucesso das organizações. Esta realidade é cada
vez mais comum a empresas e profissionais autônomos do segmento da saúde.
O médico e outros profissionais de saúde lidam constantemente com um grande
volume e complexidade de conceitos e procedimentos. Este contato diário, através do acesso e
manipulação da informação, está relacionado diretamente com a qualidade e a eficácia da
assistência ao paciente. Portanto, qualquer solução que ajude esse trabalho passa a ser
essencial, e de uso praticamente obrigatório (SABBATINI, 1999, p. 1). Fez-se necessário, por
conseguinte, o estudo e implementação de sistemas no intuito de melhorar a comunicação,
entendimento e gerenciamento de informações em saúde.
Conforme Costa (2001, p. 29), “a saúde tem um mercado altamente distribuído, que
precisa compartilhar informações e isso é feito atualmente, na maioria das vezes, de forma
manual, principalmente no Brasil, e na maioria dos casos isso ocorre de forma ineficiente.” As
clínicas hoje em um número considerável de casos, contam com meios não automatizados
para controle de tarefas fundamentais.
Uma problemática analisada foi o agendamento e gerenciamento de consultas clínicas.
Em muitas situações este controle é feito de forma manual, através de fichários de papel. O
registro de consultas em papel apresenta diversas limitações, tanto práticas como lógicas,
sendo ineficiente para o armazenamento e organização dos dados (SABATTINI, 1982, p. 15).
Podem-se destacar diversas desvantagens em relação ao registro eletrônico, como: a agenda
pode estar somente num único lugar ao mesmo tempo, elegibilidade, ambigüidade, perda
freqüente da informação, dificuldade de pesquisa coletiva, falta de padronização, dificuldade
de acesso e fragilidade do papel.
Em alguns casos o controle é feito por softwares que não foram desenvolvidos
especificamente para essa finalidade, como por exemplo, utilização de planilhas e documentos
eletrônicos de texto.
Este tipo de prática acaba trazendo certos problemas aos profissionais da saúde, como
dificuldade de manipulação, organização e acesso às informações de consultas dos pacientes.
Uma das principais contribuições à inovação no desenvolvimento de soluções que
pode ser considerada, é a utilização da Internet e seus importantes recursos. Segundo Costa
(2001, p. 30), “a área de saúde, mesmo com o histórico atraso no uso de novas tecnologias,
18
vem crescentemente aderindo à Internet e fazendo uso desta sob diferentes aspectos, desde
processos administrativos até a assistência ao paciente.”
Portanto, utilizou-se das grandes vantagens trazidas por aplicações WEB, no
desenvolvimento de um aplicativo de agendamento e gerenciamento on-line de consultas
clínicas, eliminando ou reduzindo drasticamente problemas identificados na utilização de
ferramentas não automatizadas.
Um importante aspecto das soluções WEB concebidas atualmente, é a facilidade de
personalização e gerenciamento. Estas características são incorporadas em um conceito
denominado portal corporativo. “Atualmente existem muitos sites na Internet brasileira,
conhecidos como portais (com a função de portas de entrada ou pontos de partida) com
informações exclusivas na área de saúde.” (CARVALHO JUNIOR, 2002, p. 54). Este tipo de
tecnologia agrega informações e serviços, de forma que a maior parte das operações que o
usuário deseja efetuar possa ser feita dentro do portal (SANTOS, 2005, p. 54).
Para desenvolvimento dos aplicativos que são disponibilizados dentro do Portal, por
exemplo, a agenda de consultas, foi necessário uma Application Programming Interface (API)
e um paradigma. Na linguagem de programação Java, essa API e conceito são definidos
através da especificação de Portlets (SANTOS, 2005, p. 54). Portlets são fragmentos
customizáveis de páginas feitas utilizando a HyperText Markup Language (HTML). Esta
tecnologia gera conteúdo interativo e dinâmico de forma personalizada, automatizando o
processo de gerenciamento dos agendamentos clínicos.
Um fator importante considerado no que tange ao desenvolvimento da aplicação, foi a
falta de heterogeneidade em relação aos Sistemas Gerenciadores de Bancos de Dados
(SGBDs), fazendo com que o sistema ficasse dependente do SGBD para o qual foi
desenvolvido. Existia ainda a dificuldade de implementação e manutenção da camada de
persistência1. A fim de solucionar estes problemas utilizou-se o Hibernate como provedor da
Java Persistence API (JPA), que conceitualmente é um framework2 de acesso a banco de
dados, construído na linguagem Java. O mesmo realiza o mapeamento das tabelas do modelo
relacional para classes da linguagem, servindo como uma ponte entre a aplicação e o SGBD.
O controle transacional com o Banco de Dados (BD) foi implementado utilizando a
tecnologia Enterprise JavaBeans 3.0 (EJB 3.0) e o padrão de projeto Data Access Object
(DAO), garantindo uma hierarquia flexível e escalável para a camada de persistência.
1 Denominação de uma ação que consiste em manter em meio físico recuperável, de modo a garantir a permanência das informações em um determinado estado. 2 É uma estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido.
19
Ainda focando aspectos de desenvolvimento, a fim de propiciar a divisão de camadas e
garantir a modularidade3 da aplicação, utilizou-se o padrão de projeto Model View Controller
(MVC) que, conforme definição de Lozano (2004, p. 22), “[...] é um padrão pelo qual
componentes de uma aplicação são classificados como componentes de Modelo, Visualização
e Controle.” A utilização de um padrão como o MVC trouxe reusabilidade, extensão e
facilidade de manutenção à aplicação. Este padrão foi implementado de forma robusta pela
utilização do framework Java Server Faces (JSF), que também trouxe a facilidade de
organização do fluxo de navegação entre as diferentes páginas da aplicação.
1.1 OBJETIVOS DO TRABALHO
O objetivo deste trabalho é apresentar um Sistema de Agendamento e Gerenciamento
de Consultas Clínicas (SAGCC), que visa apoiar profissionais da área de fisioterapia através
da automatização de tarefas fundamentais ao exercício de suas profissões.
Os objetivos específicos incluem:
a) disponibilizar funcionalidades de agendamento de consultas clínicas aos pacientes;
b) disponibilizar funcionalidades de agendamento e gerenciamento de consultas
clínicas aos profissionais de uma clínica de fisioterapia.
1.2 ESTRUTURA DO TRABALHO
A seguir será apresentada uma síntese dos quatro capítulos desse trabalho.
O capítulo de introdução apresenta o assunto correspondente à justificativa do
trabalho, seus objetivos específicos e como está disposto o texto em relação à sua
organização.
No segundo capítulo apresenta-se uma fundamentação teórica do tema, além de
apresentar as tecnologias utilizadas para desenvolver o presente trabalho.
3 Propriedade de um sistema que foi decomposto em um conjunto de partes coesas e fracamente acopladas.
20
O ciclo de vida do trabalho desenvolvido é apresentado no terceiro capítulo, onde se
tem a descrição dos requisitos funcionais, não-funcionais e regras de negócio do sistema,
assim como a apresentação do sistema proposto e do sistema atual. É demonstrada a
especificação do problema e a operacionalidade das páginas do sistema.
As conclusões sobre o desenvolvimento do trabalho, as limitações e sugestões para
trabalhos futuros encontram-se no quarto capítulo.
21
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo procura-se dar uma visão dos principais conceitos, técnicas e
ferramentas abordadas no trabalho, tais como informática em saúde, portais da Internet e
padrões de projeto de software, além de serem apresentados alguns trabalhos correlatos a este.
2.1 INFORMÁTICA EM SAÚDE
A Informática Médica ou Informática em Saúde (do inglês: Medical Informatics) é um
campo de rápido desenvolvimento científico que lida com armazenamento, recuperação e uso
da informação, dados e conhecimentos biomédicos para a resolução de problemas e tomada
de decisão (SHORTLIFFE, 2001, p. 3, tradução nossa).
Sigulem (1997, p. 1), cita que
A primeira aplicação prática da computação relevante para a área da saúde foi o desenvolvimento de um sistema de processamento de dados baseado em cartões perfurados, criado por Herman Hollerith em 1890. Primeiramente utilizado para a realização do censo dos Estados Unidos daquele ano, o sistema foi, logo a seguir, adotado para solucionar problemas nas áreas de epidemiologia e saúde pública.
A utilização dos cartões perfurados foi amadurecida e largamente utilizada nas décadas
de 20 e 30. Somente no final da década de 40 começaram a surgir novas técnicas de
armazenamento de seqüências de instruções (SIGULEM, 1997, p. 1). Nesta época, segundo
Sigulem (1997, p. 1), “Os profissionais da área da ciência da computação desenvolviam
programas em códigos extremamente complexos e eram indivíduos altamente especializados,
com profundo conhecimento sobre a máquina.”
Apenas após a substituição das válvulas por transistores e mais tarde por chips, os
computadores se tornaram acessíveis tanto aos laboratórios de pesquisas das universidades
quanto às empresas. As potencialidades de utilização dessas máquinas eram amplamente
acompanhadas e avaliadas por todas as áreas do conhecimento humano, inclusive a médica.
Seguindo a tendência geral de evolução da computação, os primeiros sistemas de
informação nos serviços de saúde foram desenvolvidos com a implementação de arquiteturas
centralizadas que integravam várias funções em um único sistema. Estes aplicativos
permitiam o controle da instituição, caracterizando os sistemas de informação como simples
22
gerenciadores de contas a pagar e de cobrança dos pacientes. Esse modelo era de grande
utilidade para os administradores, visto que funcionava de acordo com a abordagem dos
negócios em saúde vigente na época: a preocupação maior então era o controle da captação de
recursos em troca dos serviços de saúde. Os principais investimentos hospitalares em sistemas
de informação não estavam de acordo com a prática da medicina de qualidade, pois tinham o
objetivo financeiro de capturar cada unidade de atividade dos profissionais da saúde para
fazer a cobrança (VIEIRA, 2007).
No entanto, o grande crescimento das técnicas médicas de investigação e tratamento
forçou a reorganização dos provedores de serviços de saúde, visando o controle do custo e da
qualidade de atendimento. Ao mesmo tempo houve uma transformação nos cuidados de
saúde, onde os dados médicos poderiam ser produzidos não apenas no hospital, mas também
na casa do paciente, no consultório ou no local de trabalho.
Com a exigência de um maior compartilhamento de informações entre pacientes e
médicos, esse tipo de relacionamento interligado se transformou praticamente em regra entre
os profissionais da área de saúde e os provedores de recursos de sistemas de informação,
resultando em uma carência por desenvolvimento de sistemas mais complexos e abrangentes
(VIEIRA, 2007). Considerando o contexto tecnológico atual e a importância da informação
para a saúde, faz-se necessário utilizar um recurso indispensável para concepção de tais
sistemas: a Internet.
2.1.1 A Internet e a saúde
Ao longo dos anos a Internet tem influenciado fortemente o mundo dos negócios e o
comércio. Acessar a Internet através de um computador pessoal já se tornou um fato comum
na vida de milhões de pessoas. A grande rede mundial de computadores tem transformado o
dia-dia das pessoas e, principalmente, das empresas e profissionais que as constituem.
A prática médica diária necessita, invariavelmente, de informação para funcionar, sem
a qual é impossível um adequado atendimento ao paciente. Isso torna a saúde uma indústria
altamente dependente de informação. Considerando este contexto, a Internet contribui muito
para informar os profissionais de saúde, permitindo, por exemplo, buscar artigos recentes em
bibliotecas eletrônicas de todo o mundo, atualizando os seus conhecimentos e tendo a
possibilidade de participar de discussões on-line sobre os diversos assuntos da área da saúde.
Além disso, o profissional da saúde pode abrir a sua própria página na Internet, deixando os
23
seus conhecimentos e resultados mais recentes à disposição de todas as pessoas que têm
acesso à rede mundial (RODRIGUES, 2007).
Nesse cenário de uma indústria que precisa compartilhar e utilizar francamente a
informação, a Internet surgiu com a possibilidade de dar suporte não só a necessidades de
comunicação e pesquisa, mas também a um novo conjunto de aplicações que antes eram de
difícil realização ou mesmo não existiam. A área de saúde vem crescentemente aderindo à
Internet e fazendo uso desta sob diferentes aspectos, desde processos administrativos até a
assistência ao paciente, como é o caso da telemedicina (COSTA, 2001, p. 30).
Com o amadurecimento de novas tecnologias, e à medida que os protagonistas do
mercado de saúde se conectarem, ocorrerá gradativamente um aumento no número de
usuários desses serviços, levando à redução de custos e maior eficiência do trabalho em saúde
(DARVES, 2006, p. 10).
Observando as diversas ciências em que a saúde está dividida, percebe-se um ator
potencial para utilização de sistemas desenvolvidos com base nestas novas tecnologias: o
fisioterapeuta.
2.1.2 A informática e a fisioterapia
Fisioterapia é o ramo da saúde que estuda, avalia, previne e trata os distúrbios da
cinesia4 humana, decorrentes de alterações de órgãos e sistemas humanos, sendo atualmente
administrada em consultórios, clínicas, centros de reabilitação, asilos, escolas, clubes,
residências, hospitais, empresas, entre outros, tanto por serviços públicos como privados
(FISIOTERAPIA, 2007a).
A presença do fisioterapeuta se faz necessária quanto mais grave é a seqüela do
paciente, criando condições para desenvolvimento do mesmo e evitando o agravamento do
quadro clínico. No intuito de facilitar os meios de integração entre o fisioterapeuta e paciente,
a fisioterapia conta atualmente com um importante instrumento: o computador.
Integrada num processo multidisciplinar a fisioterapia caminhou junto ao avanço da
informática, incentivando, experimentando e obtendo resultados positivos no uso clínico da
computação. A informática a cada dia vem se consolidando na área de fisioterapia como o
mais importante e indispensável instrumento a ser associado a um trabalho de habilitação e
4 Estudo da relação do movimento com a educação, a higiene e a terapêutica
24
reabilitação do paciente (UNIIFMU-FISIOTERAPIA, 2003, p.12).
A utilização da informática na fisioterapia estende-se desde sistemas administrativos
para controle de contas a pagar e cobrança dos pacientes, a aplicativos de apoio a portadores
de deficiências neuromotoras5 crônicas e avaliação postural computadorizada.
Com a crescente utilização da Internet nas diversas ciências da saúde, a fisioterapia,
mais especificamente as clínicas fisioterapêuticas devido a seu aspecto coorporativo, passou a
contar com um importante meio para obtenção e organização da informação de qualidade,
especializada, de forma rápida e centralizada: os portais.
2.2 PORTAIS DA INTERNET
Um portal é uma página na Internet que reúne diversos serviços e informações, de
forma que a maior parte das operações que o usuário deseja efetuar possa ser feita dentro do
portal, ou pelo menos a partir dele (SANTOS, 2005, p. 54).
Alguns destes serviços são: pesquisa, navegação por categorias, capacidade de
personalização e funções expandidas para outras áreas dos mundos informacionais e
comerciais (DIAS, 2001, p. 51).
Segundo Dias (2001, p. 53), os portais podem ser classificados de duas formas
diferentes: em relação às suas funções (suporte à decisão e/ou processamento coorporativo) e
em relação ao contexto de utilização (público ou coorporativo).
2.2.1 Portais quanto às funções
Quanto à funcionalidade, os portais podem ser subdivididos em portais de suporte à
decisão e portais de processamento coorporativo.
Portais com ênfase em suporte à decisão auxiliam executivos, gerentes e analistas de
negócio a acessar as informações coorporativas para tomada de decisões de negócio. Nesta
categoria estão incluídos os portais de informações ou de conteúdo, capazes de armazenar
25
grandes repositórios de dados a partir dos temas e assuntos a que o mesmo está direcionado, e
os portais de negócios, que possuem a função principal de tornar disponíveis informações
para tomada de decisão de negócio da instituição (DIAS, 2001, p. 54).
Já os portais com ênfase em processamento cooperativo, lidam com informações tanto
da cadeia produtiva tradicional, armazenadas e manipuladas por aplicativos coorporativos,
como informações geradas por grupos ou indivíduos fora desta cadeia. Nesta divisão são
incluídos portais que utilizam ferramentas cooperativas de trabalho em grupo, e portais
especialistas, que relacionam pessoas com base em sua experiência e habilidades. Conforme
Dias (2001, p. 55), esta categoria de portais é a que menos se desenvolveu no mercado.
Existem portais mais abrangentes que unem as funções de suporte à decisão e
processamento cooperativo, interligando os usuários a todas as informações e pessoas
necessárias para realização dos negócios da empresa.
2.2.2 Portais quanto ao contexto
Devido à variação de propósitos e diferentes grupos de usuários, os portais são
subdivididos em duas categorias enquanto ao contexto de atuação: portais públicos e portais
corporativos. Portais públicos são comumente denominados portais Internet, portais WEB, ou
portais de consumidores. Estes portais trazem ao consumidor uma única interface à imensa
rede de serviços que compõe a Internet, atraindo para seu site o público em geral que navega
na grande rede. Um número maior de consumidores acessando o portal indica um aumento
potencial da probabilidade de que os consumidores comprarão os itens anunciados,
constituindo uma mídia adicional para o marketing de produtos (DIAS, 2001, p. 53).
Portais corporativos se concentram em expor e fornecer informações específicas de
negócio, dentro de determinado contexto, contribuindo para que os usuários dos sistemas
corporativos informatizados encontrem as informações de que precisam para fazer frente aos
concorrentes (REYNOLDS, 1999, p. 30).
O portal corporativo é tido por Collins (1999, p. 55) como o mais importante projeto
de gestão da informação da próxima década.
5 Deficiência neuromotora refere-se à dificuldade ou impossibilidade da realização dos movimentos mais simples por um indivíduo, como por exemplo, caminhar, sentar ou escrever.
26
2.2.3 Portais e a fisioterapia
Na Internet existem diversos portais voltados à área da fisioterapia, sendo que a
maioria deles enfatiza o contexto de atuação dos portais públicos, ou portais WEB. Estas
páginas assumem a função principal dos portais de informações ou de conteúdo, reunindo a
comunidade de fisioterapeutas em um local específico, onde são disponibilizados materiais e
serviços direcionados, como artigos, cursos e salas de discussão. Como exemplo, existe o site
Portal Fisioterapia (PORTALFISIOTERAPIA, 2007), ilustrado na Figura 1.
Figura 1 – Página inicial do Portal Fisioterapia
Outro portal WEB existente é o Fisioterapia.com (FISIOTERAPIA, 2007b),
demonstrado na Figura 2.
27
Figura 2 – Página inicial do portal Fisioterapia.com
Portanto, há uma escassez de portais corporativos e de processamento cooperativo
desenvolvidos para a área da fisioterapia.
Para implementação de um portal corporativo que suprisse as necessidades de
agendamento e gerenciamento de consultas clínicas de uma clínica de fisioterapia, optou-se
por utilizar um portal já existente, no intuito de especializá-lo. Existem várias distribuições
livres de portais para download disponíveis na Internet. No desenvolvimento do aplicativo,
utilizou-se o Portal Liferay desenvolvido na linguagem Java.
2.2.4 O portal Liferay
O Liferay é um portal corporativo de código aberto, desenvolvido na linguagem de
programação Java. Liferay (2005b), lista alguns benefícios da utilização deste portal:
a) provê experiência intuitiva e colaborativa aos usuários;
b) consolida, organiza e permite o acesso a todos os dados e aplicações a partir de um
único ponto;
c) aperfeiçoa os investimentos em TI;
d) se adapta as demandas de marketing;
28
e) provê escalabilidade aos negócios;
Este portal possui vasta documentação disponibilizada em sua página oficial
(LIFERAY, 2007c). Existe também um site para troca de experiências que reúne a
comunidade que utiliza o Liferay (LIFERAYPEDIA, 2007).
O portal Liferay foi desenvolvido com base em tecnologias conceituadas da linguagem
de programação Java. Possui duas distribuições: corporativa e profissional.
A versão profissional é voltada para a concepção de aplicações WEB de menor porte
(LIFERAY, 2007a). Esta distribuição possui embutido o servidor Tomcat da Apache Software
Foundation, que é um servidor capaz de suportar o desenvolvimento e execução, em ambiente
de produção, de aplicações WEB criadas segundo padrões da plataforma Java (LOZANO,
2004, p. 20). O Tomcat possui a função principal de oferecer infra-estrutura para
gerenciamento e execução das tecnologias de Servlets e JavaServer Pages (JSP). Os Servlets e
JSPs possuem a função principal de gerar conteúdo dinâmico em HTML. (LEME, 2004, p.
32).
Já a versão corporativa é utilizada para criação de aplicações robustas, utilizando para
isto tecnologias escaláveis como os Enterprise JavaBeans (EJBs). EJB é um padrão para
desenvolvimento e gerenciamento do lado do servidor (server-side), de componentes
distribuídos em Java. Ele define um acordo (contrato) entre componentes e servidores de
aplicação, possibilitando um componente ser executado em qualquer servidor de aplicação
que esteja de acordo com a especificação6 Java de EJBs (BURKE, 2006, p. 10).
Para utilização do padrão EJB, o portal na versão corporativa foi construído com base
no servidor de aplicações JBoss.
O JBoss é um servidor de aplicações livre baseado na plataforma Java 2 Enterprise
Edition (J2EE), que segundo Burke (2006, p. 567), provê a seguinte pilha de serviços voltados
para o desenvolvimento de aplicações corporativas em Java:
• tecnologias de componentes através dos EJBs.
• persistência com o banco de dados pela JPA.
• troca de mensagens utilizando a Java Messaging Service (JMS).
• gerenciamento de transações utilizando a Java Transaction Service (JTS) e a Java
Transaction API (JTA).
6 Uma definição descrevendo algum aspecto da tecnologia Java, como características da linguagem, edições de plataformas ou APIs, por exemplo.
29
• gerenciamento e execução de Servlets e JSPs: o JBoss possui o container WEB7
Tomcat embutido.
• provê uma interface de nomes e diretórios através da Java Naming and Directory
Interface (JNDI).
Excluindo o foco tecnológico das distribuições do portal, ambas possuem
essencialmente as mesmas funcionalidades (LIFERAY, 2007a). Para o desenvolvimento do
SAGCC, fez-se necessário utilizar a versão corporativa, pois como será descrito nos próximos
tópicos, um dos requisitos foi a integração com a tecnologia EJB.
A arquitetura do portal Liferay foi construída tendo em vista a utilização da API de
Portlets, que será descrita detalhadamente a seguir.
2.2.5 Portlets
Um Portlet pode ser definido como um componente WEB Java responsável pela
geração dinâmica de um fragmento de página em HTML, e gerenciado por um Portlet
container. Um Portlet container é um componente do portal, responsável por gerenciar e
invocar os Portlets. As tarefas de organização e agregação dos fragmentos dos Portlets são de
responsabilidade do portal (SANTOS, 2005, p. 54).
A API de Portlets é definida pela Java Specification Request 168 (JSR - 168) da Sun
Microsystems, empresa que possui os direitos sobre a linguagem de programação Java. Uma
JSR, segundo Pires (2006, p. 15), é um documento propondo o desenvolvimento de uma nova
especificação Java, ou uma revisão significativa a uma especificação já existente.
O desenvolvimento de Portlets provê uma mudança em como o site deverá gerar o
conteúdo dinâmico. Portlets são concebidos normalmente utilizando as tecnologias de
Servlets ou JSPs. A diferença está na forma em que os Servlets e JSPs são desenvolvidos:
normalmente eles são responsáveis pela geração da página inteira, enquanto que os Portlets
são responsáveis somente pela criação de fragmentos de página relativos à sua área. As
demais áreas do HTML são gerenciadas pelo portal, que incluirá na página resultante o
fragmento gerado por cada Portlet (SANTOS, 2005, p. 55).
Os Portlets podem possuir diferentes estados de janela (window states): normal,
maximizados e minimizados, sendo que a visualização destes estados é controlada pelo portal.
7 Container WEB é uma aplicação responsável pela criação e destruição de Servlets, como também pela
30
Além dos diferentes estados de janela, os fragmentos de página podem ser renderizados em
três modos predefinidos, sendo estes, visualização, edição e ajuda (SANTOS, 2005, p. 56).
Considerando as características da tecnologia apresentada e os benefícios que esta
poderia trazer para o sistema proposto, optou-se por sua utilização no desenvolvimento do
SAGCC.
Procurando garantir a estruturação do aplicativo, e dividir a lógica de visualização dos
Portlets da lógica de controle e processamento de regras de negócio dos agendamentos de
consultas, assim como o acesso seguro aos dados da clínica de Fisioterapia, o SAGCC foi
desenvolvido utilizando alguns padrões de projeto de software, que serão detalhados na
próxima sessão.
2.3 PADRÕES DE PROJETO DE SOFTWARE
Más escolhas em como desenvolver software, conduzem a sistemas e a componentes
que são frágeis e difíceis de manter, compreender, reutilizar, ou estender. Uma
implementação habilidosa deve estar fundamentada em princípios fundamentais do bom
projeto de software.
Os desenvolvedores experientes em orientação a objetos (OO) em conjunto com outros
desenvolvedores de software, criaram um repertório de princípios gerais e soluções
idiomáticas que os guiam na concepção de sistemas computacionais. Esses princípios e
idiomas, se codificados em um formato estruturado, descrevendo o problema e a solução e
recebendo um nome, podem ser chamados de padrões de projeto de software (LARMAN,
1999, p. 194).
Um padrão de projeto pode ser definido como uma descrição nomeada de um
problema, uma solução, e uma orientação sobre quando aplicar a solução e como aplica-la a
novos casos (LARMAN, 1999, p. 483).
Os padrões apresentam soluções para problemas que ocorrem de maneira semelhante,
mesmo em projetos voltados para áreas completamente diferentes. No caso de padrões de
projeto de software orientado a objetos, tais problemas costumam ser a criação de objetos,
estruturação de classes, modos de acesso a dados, formas de troca de mensagens e outros que
delegação de requisições do protocolo Hypertext Transfer Protocol (HTTP) para Servlets existentes.
31
se enfrenta de maneira semelhante em diversos sistemas (LARMAN, 1999, p. 52).
Objetivando garantir a separação das camadas do SAGCC, e o encapsulamento da
implementação da camada de banco de dados, buscou-se utilizar os padrões Model View
Controller (MVC) e Data Acess Object (DAO), que serão detalhadamente descritos nos
próximos tópicos.
2.3.1 O padrão MVC
MVC é um padrão onde os componentes de uma aplicação são classificados em
componentes de modelo (model), visualização (view) e controle (control). Componentes de
modelo cuidam do armazenamento e da recuperação de informações, assim como o
processamento de regras de negócio do sistema. Componentes de visualização se limitam a
exibir informações segundo um formato ou layout pré-definido. Os componentes de controle
por sua vez cuidam de interpretar ações do usuário, como cliques e eventos de teclado, por
exemplo, chamando os componentes de modelo ou visualização que devem responder a essas
ações (LOZANO, 2004, p. 22).
Um framework conceituado que provê, dentre outras características, a implementação
da arquitetura MVC é o JavaServer Faces (JSF). Resumidamente, a JSF é uma biblioteca de
tags e classes que facilita a interação de usuários com os elementos de formulários HTML,
provendo também um prático mecanismo de navegação entre as páginas da aplicação. A JSF é
especificada pela JSR–127, permitindo que sejam produzidas ferramentas de desenvolvimento
e componentes de terceiros, o que traz compatibilidade e independência de fornecedor às
aplicações que a utilizam (FAERMAN, 2004, p. 58).
A versão do portal Liferay utilizada no desenvolvimento do SAGCC possui suporte à
JSF, permitindo uma padronização e maior facilidade de implementação dos Portlets, além de
garantir a utilização do padrão MVC. Considerando estas vantagens, a tecnologia JSF foi
adotada na concepção do aplicativo.
2.3.2 O padrão DAO
De forma simplificada, um DAO é um objeto intermediário, responsável pelo acesso a
32
dados, que encapsula detalhes de um determinado banco de dados, ou de outro mecanismo de
persistência (FAERMAN, 2005, p. 53). A motivação deste padrão é tornar o código de
persistência mais organizado, reutilizável e desacoplado da lógica de negócio.
Uma das grandes vantagens do padrão DAO é a garantia de independência do
mecanismo de persistência8.
2.3.2.1 Mecanismos de persistência e mapeamento objeto/relacional
Os sistemas de persistência mais conceituados em Java são precisamente aqueles que
se distinguem por suportar a persistência sobre objetos de valor, também chamados de Plain
Old Java Objects (POJO), em contraste a outros sistemas que exigem a implementação de
uma série de interfaces (DOEDERLEIN, 2005, p. 25). Segundo Bauer (2007, p. 114), POJOs
são classes Java que implementam métodos de negócio que definem comportamento, e
propriedades que representam estado, sendo que algumas destas propriedades podem ser
outros POJOs pré-definidos.
Estes mecanismos de persistência são capazes de realizar operações de criação,
restauração, atualização e remoção de registros da base de dados que estão relacionados a
qualquer POJO, gerando de forma automática instruções na Structured Query Language
(SQL). Para isso geralmente utilizam arquivos de metadados ou descritores, que especificam
o mapeamento entre tabelas e POJOs, para que seja possível, por exemplo, definir atributos de
um POJO após a leitura de um registro do BD (DOEDERLEIN, 2005, p. 30). Porém, até
então não havia na linguagem Java uma padronização em relação a como os mecanismos de
persistência deveriam ser implementados.
A Java Persistence API (JPA), definida pela JSR-220 (EJB 3.0) padroniza o
mapeamento objeto-relacional na plataforma Java, para desenvolvimento de componentes da
camada de persistência. A JPA é baseada no conceito de POJOs, que incorpora idéias de
conceituados frameworks de persistência. Rocha (2007, p. 29) cita suas principais vantagens:
• modo declarativo de descrever mapeamentos objeto/relacionais.
• provê uma linguagem própria de consulta.
• conjunto de ferramentas para manipular entidades.
Uma das vantagens de se utilizar a JPA é que, por ser um padrão da Sun
33
Microsystems, existe a possibilidade de diversos fabricantes trabalharem sobre os mesmos
conceitos, e que o desenvolvedor escolha a implementação de sua preferência. Para
implementação da JPA, podem ser utilizados provedores de qualquer fornecedor que esteja de
acordo com a especificação. Portanto, é possível alterar entre fabricantes distintos sem
nenhum esforço adicional. (ROCHA, 2007, p. 29) Utilizando a JPA em conjunto com a
tecnologia EJB 3.0, é possível implementar de forma transparente e descomplicada o controle
transacional e de conexões com o BD.
Atualmente um produto muito utilizado no que tange a mecanismos de mapeamento
objeto/relacional é o Hibernate. Segundo Bauer (2007, p. 4), o Hibernate é um projeto
ambicioso que busca ser eficiente em resolver o problema de gerenciamento de dados em
Java, intermediando a interação do sistema com o BD relacional e deixando o desenvolvedor
livre para se concentrar nos aspectos da aplicação referentes ao negócio. Além das vantagens
citadas, o Hibernate garante a heterogeneidade em relação aos SGBDs, não sendo necessário
codificar instruções para o dialeto do BD que a aplicação foi construída.
A implementação do padrão DAO utilizando as tecnologias citadas proveu à camada
de persistência do SAGCC organização, robustez, reusabilidade e desacoplamento das outras
camadas do sistema.
2.4 TRABALHOS CORRELATOS
Alguns trabalhos similares a este são:
a) a Empresa Reckon Engenharia de Sistemas (2006) possui um serviço que possibilita
o agendamento de consultas por reconhecimento de voz. Quem assina o serviço recebe
um número de telefone exclusivo para sua agenda. Neste número um computador vai
atender a ligação e conversar com o usuário. Assim como sugerido nesta monografia,
salvo que por meio de ligações telefônicas e não pela WEB, é possível agendar, alterar,
confirmar e consultar compromissos ou consultas através da agenda;
b) Siqueira (2004) apresentou um Sistema de Agendamento Universal para a área da
saúde e discutiu o contexto de implantação desta ferramenta na Secretaria de Saúde do
Estado de São Paulo, a fim de garantir a heterogeneidade entre os tipos de
8 Mecanismo utilizado para garantir a persistência de objetos em uma aplicação. Pode ser uma API como a Java Database Connectivity (JDBC), ou um framework de persistência como Hibernate.
34
agendamento e a emergente necessidade de integração entre elas. O Sistema proposto,
assim como o desta monografia, utiliza a linguagem Java, o servidor Tomcat para
desenvolvimento WEB, o conceito de divisões de camadas (MVC) e diagramas da
Unified Modeling Language (UML);
c) Costa (2001) em sua dissertação de mestrado apresentada à Faculdade de
Engenharia Elétrica e de Computação da Universidade Estadual de Campinas, fala
sobre o Desenvolvimento e Avaliação Tecnológica de um Sistema de Prontuário
Eletrônico do Paciente, Baseado nos Paradigmas da World Wide Web e da Engenharia
de Software. O autor foca o desenvolvimento de um Prontuário Eletrônico do Paciente
(PEP), trazendo considerações relevantes e comuns a esta monografia como utilização
da Internet para produção de soluções em saúde.
35
3 DESENVOLVIMENTO DA APLICAÇÃO
O presente trabalho resulta na construção de um Sistema de Agendamento e
Gerenciamento de Consultas Clínicas (SAGCC), o qual permite pacientes e profissionais de
uma clínica fisioterapêutica agendar e confirmar consultas pela Internet. Na seqüência serão
apresentados os quatro tópicos do desenvolvimento do trabalho. O primeiro tópico descreve
os requisitos e regras de negócio atendidas pela aplicação. O segundo tópico refere-se à
especificação do sistema, onde são apresentados alguns diagramas na UML visando uma
melhor compreensão do mesmo. O terceiro tópico refere-se a implementação da aplicação,
onde está descrito seu funcionamento, tecnologias utilizadas e operacionalidade da
implementação. No quarto e último tópico são apresentados os resultados obtidos.
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO
Os requisitos e regras de negócio da aplicação compreendem o levantamento das
funcionalidades e/ou necessidades dos usuários para criação do sistema, definindo suas
características e comportamento. Estes requisitos e regras são no presente trabalho, resultados
de um estudo realizado junto à clínica de fisioterapia Nova Físio.
A Nova Físio surgiu em meados do ano 2000 com a missão de atender pacientes no
diagnostico, prevenção e tratamento das mais variadas disfunções de órgãos humanos. Nos
últimos três anos conta com a administração de Adriana Freygang, que junto a outros sete
fisioterapeutas atendem pacientes de Blumenau e região.
A clínica possui uma infra-estrutura de computadores bastante simples: existe apenas
um micro-computador com acesso discado à Internet, que é utilizado na maior parte do tempo
pela secretária para fazer consultas a informações de pacientes. Através do computador é feito
o cadastro resumido dos pacientes, utilizando uma planilha do software Microsoft Excel. Um
cadastro mais detalhado é feito em fichas de papel. Hoje a clínica possui cerca de mil e
quatrocentos pacientes cadastrados na planilha (ativos ou não). O computador é utilizado
praticamente para este fim, sendo que a Internet é acessada essencialmente para envio de e-
mails à empresa cooperada Unimed. Não existe nenhum tipo de registro de informações dos
fisioterapeutas que trabalham na clínica.
36
As atividades de agendamento e gerenciamento de consultas clínicas são atualmente
realizadas através de uma ficha de papel que contém tabelas relacionando dias, horários e
pacientes, assim como o status do atendimento: atendido, em caso da consulta já realizada; ou
cancelado, caso o paciente ligue solicitando cancelar o atendimento.
A atendente agrupa as consultas por fisioterapeuta, formando agendas separadas a fim
de controlar colisões de horários. Este agrupamento é feito colocando-se os horários lado a
lado, propondo facilitar a visualização e comparação.
Cerca de 80% dos agendamentos são realizados por telefone, onde o paciente liga
solicitando um horário e a atendente negocia a disponibilidade. Nos outros 20% o
agendamento é feito pessoalmente na clínica. Apesar de ser uma tarefa desempenhada na
maioria das ocasiões pela secretária, os fisioterapeutas também eventualmente manipulam a
agenda de acordo com suas necessidades. Os custos da clínica com serviços de telefonia são
relevantes, considerando os percentuais citados.
Nota-se, portanto, que a falta de automatização dos processos de agendamento e
gerenciamento de consultas clínicas traz vários problemas, como por exemplo, o da agenda
poder estar somente num único lugar ao mesmo tempo, impedindo o acesso simultâneo. O
controle dos atendimentos ser feito através de papel pode causar ilegibilidade, ambigüidade,
perda freqüente da informação devido a fragilidade do material, dificuldade de pesquisa
coletiva, falta de padronização do processo de agendamento, assim como dificuldade de
acesso e manipulação.
Outro fator a ser pontuado é a necessidade de a clínica ter uma atendente disponível a
fim de realizar o agendamento de consultas para os pacientes, assim como a falta de diferentes
possibilidades de confirmação de atendimento, restringindo-se apenas ao contato pessoal ou
uso do telefone.
A Nova Físio não possui hoje nenhum meio para utilização e divulgação de serviços de
atendimento aos pacientes por meio da Internet, o que pode ser considerado fator relevante
enquanto à competitividade frente a outras clínicas de Fisioterapia, levando-se em conta o
número cada vez maior de adeptos à utilização da WEB.
A criação do SAGCC teve como objetivo automatizar as operações realizadas no
decorrer do processo de agendamento e gerenciamento de consultas, proporcionando aos
profissionais e pacientes da clínica maior facilidade de acesso, controle e manipulação de
informações tangentes aos atendimentos.
O paciente terá a oportunidade de efetuar o cadastramento e acesso ao SAGCC através
do portal. Após acessar a aplicação o paciente terá a oportunidade de realizar a alteração de
38
g) o sistema deverá permitir ao profissional da clínica cadastrar pacientes (RF07);
h) o sistema deverá permitir ao profissional da clínica cadastrar fisioterapeutas
(RF08);
i) o sistema deverá permitir ao profissional da clínica agendar consultas (RF09);
j) o sistema deverá permitir ao profissional da clínica confirmar um agedamento
(RF10);
k) o sistema deverá permitir ao profissional da clínica rejeitar um agedamento
(RF11);
l) o sistema deverá permitir ao profissional da clínica cancelar qualquer agedamento
(RF12);
m) o sistema deverá permitir ao profissional da clínica selecionar o fisioterapeuta
responsável pelo tratamento de uma consulta (RF13);
n) o sistema deverá permitir aos pacientes ou profissionais da clínica visualizar as
consultas por dia, semana, mês ou ano (RF14);
o) o sistema deverá permitir ao profissional da clínica visualizar uma agenda que
relaciona todas consultas agendadas e os horários disponíveis (RF15);
p) o sistema deverá permitir ao profissional da clínica visualizar uma agenda para
cada um dos fisioterapeutas cadastrados (RF16);
q) o sistema deverá permitir ao profissional da clínica visualizar uma agenda para
cada um dos pacientes cadastrados (RF17);
r) o sistema deverá mostrar o status de uma determinada consulta: agendada,
cancelada, confirmada pela clínica ou rejeitada pela clínica (RF18);
s) o sistema deverá permitir aos pacientes cancelar agendamentos realizados por eles
(RF19);
t) o sistema deverá permitir ao profissional da clínica cadastrar e excluir endereços
de destinatários onde serão enviados e-mails de notificação de agendamentos e
cancelamentos de agendamentos realizados por pacientes (RF20);
u) o sistema deverá permitir ao profissional da clínica escolher no momento do
cadastramento de um novo fisioterapeuta, se o mesmo receberá e-mails de
notificação de agendamentos e cancelamentos de agendamentos realizados por
pacientes (RF21);
v) o sistema deverá permitir listar em uma tabela todos os agendamentos de um
determinado paciente ou fisioterapeuta (RF22);
w) o sistema deverá permitir ao administrador do portal cadastrar e excluir usuários
39
do portal (RF23);
x) o sistema deverá permitir ao administrador do portal adicionar ou retirar um
determinado perfil de acesso de qualquer usuário do portal (RF24);
y) o sistema deverá permitir ao administrador do portal adicionar ou remover Portlets
para um determinado usuário ou perfil, assim como escolher a disposição dos
mesmos na tela (RF25);
z) o sistema deverá permitir ao administrador do portal realizar todas as operações
disponíveis aos profissionais da clínica (RF26).
Como principais requisitos funcionais, podem-se destacar a possibilidade de
agendamento de consultas tanto por profissionais da clínica quanto por pacientes (RF09 e
RF03 respectivamente), assim como a confirmação ou rejeição das mesmas pela clínica
(RF10 e RF11 respectivamente). Outro requisito funcional importante é a possibilidade de
cadastrar quais endereços de e-mail receberão a notificação de um agendamento agendado ou
cancelado por um paciente (RF20).
Os requisitos não-funcionais para o desenvolvimento do sistema incluem:
a) o sistema deverá controlar o acesso dos usuários de acordo com o perfil (RNF01);
b) as configurações de software do computador onde o sistema será acessado deverão
ser: navegador Internet Explorer 6.0 com suporte a Java Script habilitado
(RNF02);
c) o sistema deverá ser desenvolvido em três camadas respeitando o modelo MVC
(RNF03);
d) as configurações mínimas de hardware do computador onde o sistema será
acessado são: processador Pentium 2, 500 MHz e 128 MB de memória RAM
(RNF04);
e) as configurações mínimas de hardware do computador Servidor onde o sistema
será executado serão: processador Pentium 4, 2.6 GHz e 1 GB de memória RAM
(RNF05);
f) as configurações de software do computador Servidor onde o sistema será
executado deverão ser: JBoss 4.0.5.GA com Tomcat 5.5, Liferay Portal 4.2, Java
Runtime Enviroment (JRE) 1.5 e banco de dados MySQL 5.0 (RNF06);
g) todas as telas do sistema não devem levar mais de 15 segundos para serem
carregadas no navegador, considerando o uso do programa em condições ideais de
hardware e software (RNF07);
h) a camada de persistência do sistema deverá ser desenvolvida com base no padrão
40
de projeto DAO (RNF08);
i) para implementação do padrão DAO, deverá ser utilizada tecnologia EJB 3.0 e a
JPA (RNF09);
j) para implementação do modelo MVC, deverá ser utilizado o framework JSF 1.1
(RNF10).
Pode-se destacar os principais requisitos não-funcionais como a implementação
respeitando os padrões de projeto MVC e DAO (RNF03 e RNF08 respectivamente), e a
utilização do servidor de aplicações JBoss em sua versão 4.0.5.GA (RNF06). Esta versão do
servidor JBoss com o container EJB 3.0 instalado, possibilita a utilização da tecnologia EJB
3.0 requerida no RNF09. Além destes, é importante detalhar o RNF01, que trata do controle
de acesso dos usuários do portal de acordo com o perfil.
Os perfis de usuário para acesso ao sistema são:
• administrador do portal: pode efetuar todas as operações do sistema e tem acesso a
todas configurações internas do portal.
• profissional da clínica: pode efetuar operações de agendamento e confirmação de
consultas, visualizar todos os tipos de agenda, assim como realizar o cadastro de
pacientes e fisioterapeutas.
• paciente: pode efetuar operações de agendamento de consultas e tem acesso às
informações cadastrais do paciente.
As regras de negócio identificadas para o desenvolvimento do aplicativo incluem:
a) o paciente poderá consultar, cancelar e efetuar apenas agendamentos para seu
usuário no sistema (RN01);
b) no momento que o paciente cancelar, alterar ou efetuar um agendamento, o
sistema deverá enviar um e-mail para os destinatários cadastrados previamente
para receber a mensagem de notificação (RN02);
c) após a confirmação, cancelamento ou rejeição de um agendamento que possua o
tipo de confirmação por e-mail, o sistema deverá enviar um e-mail com um texto
padrão para o paciente da consulta informando a confirmação, cancelamento ou
rejeição (RN03);
d) após a confirmação, cancelamento ou rejeição de um agendamento que possua o
tipo de confirmação por SMS, o sistema deverá enviar uma mensagem SMS com
um texto padrão para o paciente da consulta informando a confirmação,
cancelamento ou rejeição (RN04);
e) no momento em que realizarem o cadastramento de pacientes, fisioterapeutas ou
41
usuários de notificação, caso o campo referente a e-mail não estiver preenchido, o
sistema deverá apresentar mensagem de erro informando que é preciso informar
um e-mail (RN06);
f) não poderão ser realizados agendamentos para datas e hora anteriores a data atual
do servidor da aplicação (RN07);
g) todo agendamento deve ter pelo menos uma forma de confirmação associada. Caso
não houver, o sistema deverá apresentar mensagem informando que pelo menos
uma forma de confirmação deve ser selecionada (RN08);
h) no momento em que realizarem o cadastramento de pacientes, fisioterapeutas ou
usuários de notificação, caso o campo referente a nome não estiver preenchido, o
sistema deverá apresentar mensagem de erro informando que é necessário
informar um nome (RN09);
i) no momento em que realizarem o cadastramento de pacientes ou fisioterapeutas,
caso o campo referente a CGC/CPF não estiver preenchido, o sistema deverá
apresentar mensagem de erro informando que é necessário informar um nome
(RN10);
j) no momento em que realizarem o cadastramento de pacientes ou fisioterapeutas,
caso o campo referente a cidade não estiver preenchido, o sistema deverá
apresentar mensagem de erro informando que é necessário informar uma cidade
(RN11);
k) no momento em que realizarem o cadastramento de pacientes/fisioterapeutas, caso
o campo referente a CGC/CPF estiver preenchido com caracteres alfanuméricos, o
sistema deverá apresentar mensagem de erro informando permitir apenas números
para o campo (RN12);
l) no momento em que realizarem o cadastramento de pacientes, fisioterapeutas ou
usuários de notificação, caso o e-mail estiver em um formato inválido, o sistema
deverá apresentar mensagem de erro informando que é necessário informar um e-
mail válido (RN13);
m) no momento em que realizarem o cadastramento de pacientes ou fisioterapeutas,
caso o campo de data de nascimento estiver preenchido com uma data inválida, o
sistema deverá apresentar mensagem de erro (RN14);
n) no momento em que realizarem o cadastramento de pacientes ou fisioterapeutas,
caso o CGC/CPF já existir para um cadastro na base de dados, o sistema deverá
apresentar mensagem de erro informando que já existe um cadastro para o
42
CGC/CPF informado (RN15);
o) no momento em que realizarem o cadastramento de fisioterapeutas, caso o campo
referente ao número do Conselho Regional de Fisioterapia e Terapia Ocupacional9
(CREFITO) não estiver preenchido, o sistema deverá apresentar mensagem de erro
informando que é necessário informar um número de CREFITO (RN16);
p) no momento em que realizarem um agendamento, caso o paciente não for
selecionado, o sistema deverá apresentar mensagem de erro informando que é
necessário informar um paciente para o agendamento (RN17);
q) no momento em que realizarem a confirmação de um agendamento, caso o
fisioterapeuta não for selecionado, o sistema deverá apresentar mensagem de erro
informando que é necessário informar um fisioterapeuta para confirmar o
agendamento (RN18);
r) agendamentos com a situação "Confirmado pela Clínica" não poderão ser
alterados, apenas cancelados (RN19);
s) agendamentos com a situação "Rejeitado pela Clínica" não poderão ser alterados
nem cancelados (RN20);
t) o sistema não deverá permitir ao usuário alterar o campo CGC/CPF de um
paciente ou fisioterapeuta após o cadastramento (RN21);
u) o sistema não deverá permitir a edição de informações de agendamentos
cancelados (RN22);
v) o sistema deverá permitir apenas a visualização de agendamentos do ano corrente,
anterior e posterior. O ano corrente deverá ser o ano atual do servidor da aplicação
(RN23);
w) no momento em que realizarem o cadastramento de fisioterapeutas ou pacientes,
caso for informado um CGC/CPF numérico porém com dígitos "." e/ou "-", o
sistema deverá retirar os dígitos de separação e inserir apenas o número na base de
dados (RN24);
x) o sistema deverá permitir apenas ações de agendamento e cancelamento de
consultas através da Agenda de Pacientes (RN25);
y) após inclusão de um agendamento, independente do status do mesmo, o sistema
não deverá permitir alterar o paciente (RN26).
9 Órgão regional responsável perante o Conselho Federal e o Ministério do Trabalho, pelo atendimento dos objetivos de interesse público que determinaram a regulamentação das atividades da Fisioterapia e da Terapia Ocupacional.
43
Dentre as regras de negócio apresentadas, a RN18 pode ser destacada, pois é necessário
existir um fisioterapeuta para atender uma determinada consulta, portanto um agendamento
não poderá ser confirmado sem que antes um fisioterapeuta seja selecionado.
Através da Agenda de Pacientes não é possível selecionar o fisioterapeuta do
agendamento. Com base neste comportamento, a RN25 restringe apenas a realização das
ações de agendamento e cancelamento de consultas por esta interface, visto que a RN18
obriga o usuário selecionar um fisioterapeuta ao realizar a confirmação de um agendamento.
A RN21 restringe a alteração do CGC/CPF de um paciente ou fisioterapeuta após o
cadastramento, pois este é o identificador único destas entidades.
3.2 ESPECIFICAÇÃO
Neste tópico são apresentadas as especificações do aplicativo, feitas através da análise
orientada a objetos.
Para descrição do SAGCC, expõem-se os diagramas criados com base na UML e
gerados com a utilização da ferramenta Enterprise Architect (EA).
A fim de ilustrar as principais funcionalidades do SAGCC, são demonstrados os
diagramas de pacote e casos de uso do paciente e profissional da clínica. Posteriormente no
diagrama de classes, é apresentada a arquitetura das classes do sistema.
3.2.1 Diagrama de casos de uso
Esta seção demonstra a representação gráfica dos casos de uso da aplicação, assim
como seu detalhamento. Para melhor visualização dos casos de uso da ferramenta foram
utilizados pacotes. Os pacotes são mecanismos de propósitos gerais para a organização de
elementos em grupos (BOOCH, 2000, p. 168). A visão de pacotes dos casos de uso é
representada graficamente pela Figura 4.
44
pd 3.1 Diagrama de pacotes
PCT01 - Módulo Clínica
+ Administrador do Portal
+ Profissional da Clínica
+ UC01.01 Efetua Login
+ UC01.02 Cadastra paciente
+ UC01.03 Cadastra Fisioterapeuta
+ UC01.04 Agenda consulta
+ UC01.05 Confirma agendamento
+ UC01.06 Rejeita agendamento
+ UC01.07 Cancela consulta
+ UC01.08 Associa Fisioterapeuta à consulta
+ UC01.09 Visualiza agenda por dia, semana, mês ou ano
+ UC01.10 Visualiza agenda geral
+ UC01.11 Visualiza agenda Fisioterapeuta
+ UC01.12 Visualiza agenda paciente
+ UC01.13 Cadastra e-mail de notificação
+ UC01.14 Exclui e-mail de notificação
+ UC01.15 Lista todos agendamentos do paciente ou fisioterapeuta
+ UC01.16 Gerencia usuários do portal
+ UC01.17 Gerencia conteúdo do portal
(from 3.2 Diagrama de casos de uso)
PCT02 - Módulo Paciente
+ Paciente
+ UC02.01 Efetua login
+ UC02.02 Cadastra paciente
+ UC02.03 Agenda consulta
+ UC02.04 Visualiza agenda por dia, semana, mês ou ano
+ UC02.05 Visualiza agenda paciente
+ UC02.06 Cancela consulta
+ UC02.07 Lista todos agendamentos paciente
(from 3.2 Diagrama de casos de uso)
Figura 3 – Pacotes dos casos de uso
A Figura 4 apresenta os casos de uso do pacote 01 (Módulo Clínica). Estes casos de
uso referem-se às operações tangíveis aos profissionais da clínica de fisioterapia.
45
ud PCT01 - Módulo Clínica
Profissional da Clínica
UC01.01 Efetua Login
UC01.02 Cadastra paciente
UC01.03 Cadastra Fisioterapeuta
UC01.04 Agenda consulta
UC01.05 Confirma agendamento UC01.06 Rejeita
agendamento
UC01.07 Cancela consulta
UC01.08 Associa Fisioterapeuta à
consulta
UC01.09 Visualiza agenda por dia,
semana, mês ou ano
UC01.10 Visualiza agenda geralUC01.11 Visualiza
agenda Fisioterapeuta
UC01.12 Visualiza agenda paciente
UC01.13 Cadastra e-mail de
notificação
UC01.14 Exclui e-mail de notificação
UC01.15 Lista todos agendamentos do
paciente ou fisioterapeuta
Administrador do Portal
UC01.16 Gerencia usuários do portal
UC01.17 Gerencia conteúdo do portal
Figura 4 – Casos de uso dos profissionais da clínica
O ator “Profissional da Clínica” representa uma pessoa que trabalha para a clínica de
fisioterapia que utiliza o SAGCC. No UC01.01 o profissional da clínica realiza o login no
portal através de um usuário e senha pré-cadastrados. O ator “Administrador do Portal” é um
profissional da clínica com perfil para incluir e excluir usuários do portal através do UC01.16.
Por este mesmo caso de uso, este ator pode realizar a inclusão ou remoção de um determinado
perfil de acesso de qualquer usuário do portal. O administrador do portal pode, por meio do
UC01.17, adicionar ou remover Portlets para um profissional da clínica ou paciente, assim
como escolher a disposição dos mesmos na tela.
No UC01.02 e UC01.03 o profissional da clínica efetua a manutenção (inclusão,
alteração) dos dados cadastrais de um paciente ou fisioterapeuta. Já no UC01.04 o profissional
da clínica mantém um agendamento (inclusão, alteração), informado o paciente, dia e hora,
descrição da patologia, título, assim como uma ou mais formas de confirmação. Este caso de
uso é efetivado através dos tipos de agendas disponíveis no sistema: agenda do fisioterapeuta,
do paciente e agenda geral. A visualização destas agendas é representada pelos casos de uso
UC01.10, UC01.11 e UC01.12. Para localizar um agendamento, o profissional da clínica pode
utilizar diferentes visões das agendas, conforme representado no UC01.09, sendo também
possível listar todos agendamentos por meio do UC01.15.
Através do UC01.05 o profissional da clínica confirma um agendamento, e no
UC01.06 realiza a rejeição de um agendamento efetuado por um profissional da clínica ou
46
paciente. Antes de confirmar um agendamento, é necessário associar um fisioterapeuta à
consulta. Esta ação é realizada pelo UC01.08. Os agendamentos cadastrados por um
profissional da clínica ou paciente podem ser cancelados pelo UC01.07.
O profissional da clínica, por meio dos casos de uso UC01.13 e UC01.14, efetua a
manutenção (inclusão, alteração e exclusão) dos dados cadastrais de um e-mail de notificação,
para que uma determinada pessoa passe ou deixe de receber correios de notificação quando
um paciente inclui, altera ou cancela um agendamento.
A Figura 5 demonstra os casos de uso do pacote 02 (Módulo Paciente). Estes casos de
uso referem-se às operações possíveis a um paciente da clínica de fisioterapia.
ud PCT02 - Módulo Paciente
Paciente
UC02.01 Efetua login
UC02.02 Cadastra paciente
UC02.03 Agenda consulta
UC02.04 Visualiza agenda por dia,
semana, mês ou ano
UC02.05 Visualiza agenda paciente
UC02.06 Cancela consulta
UC02.07 Lista todos
agendamentos paciente
Figura 5 – Casos de uso dos pacientes
O ator “Paciente” representa uma pessoa que necessita de tratamento fisioterapêutico,
e escolhe agendar uma consulta em uma clínica de fisioterapia que utiliza o SAGCC. No
UC02.01 o paciente realiza o acesso no portal através de um usuário e senha pré-cadastrados.
No UC02.02 o paciente efetua a manutenção (inclusão, alteração) de seus dados cadastrais. Já
no UC02.03 o paciente da clínica mantém um agendamento (inclusão, alteração), informado o
dia e hora, descrição da patologia, título, assim como uma ou mais formas de confirmação. O
paciente poderá visualizar seus agendamentos, independente destes serem cadastrados pela
clínica ou por ele. A visualização da agenda pelo paciente é representada no caso de uso
UC02.05.
Para localizar um agendamento, o paciente pode utilizar diferentes visões das agendas,
47
conforme demonstrado no UC02.04, sendo também possível listar todos agendamentos por
meio do UC02.07. Caso considere necessário, o paciente pode cancelar um agendamento
através do UC02.06.
3.2.2 Diagrama de classes
Esta seção demonstra os diagramas de classes criados durante o desenvolvimento da
aplicação. Os métodos e atributos, assim como suas descrições, foram omitidos das figuras a
fim de facilitar a visualização das classes e seus relacionamentos. A definição completa das
principais classes é apresentada no Apêndice A.
A Figura 6 apresenta o diagrama de classes de domínio que representa as classes no
domínio do negócio em questão. Este modelo é construído na fase de análise (BEZERRA,
2003, p. 96).
O diagrama de classes de projeto é apresentado a partir da Figura 7. Este diagrama é
uma extensão do diagrama de classes de domínio, que recebe a adição de detalhes específicos
conforme a solução de software escolhida (BEZERRA, 2003, p. 96).
As classes de projeto do sistema foram divididas em dois módulos: WEB e EJB. O
módulo WEB possui os pacotes com as classes responsáveis pela camada de controle da
aplicação, e está ilustrado na Figura 7. O módulo EJB por sua vez contém os pacotes das
classes responsáveis pela camada de modelo, sendo este demonstrado na Figura 14. A divisão
de um software em camadas permite que este seja mais portável e modificável. Uma mudança
em uma camada mais baixa que não afete sua interface não implicará em mudanças nas
camadas mais altas (BEZERRA, 2003, p. 246).
As classes da camada de controle são ilustrados nas Figuras 8, 9, 10, 11, 12 e 13. As
classes da camada de persistência, ou modelo, são apresentadas nas Figuras 15 e 16.
48
cd br.com.sagcc.model
«Entidade»Pessoa
«Entidade»Paciente
«Entidade»Agendamento
«Entidade»Fisioterapeuta
«Entidade»SituacaoAgendamento
«Entidade»UsuarioNotificacao
Associação criada pararepresentar conceitualmente a relação de um Agendamento de um Paciente com um UsuarioNotificacao. Para maiores detalhes sobre esta associação, consultar descrição da Regra de Negócio 02 (RN02.)
«Entidade»FormaConfirmacao
*
*
3
*
1
*
*1
1
*
Figura 6 – Diagrama de classes de domínio
As classes de domínio representam os POJOs, ou entidades da aplicação. Neste
modelo, cada POJO é considerado um objeto que pode ser persistido, ou seja, um objeto que
está mapeado para uma tabela do BD. A forma de realização deste mapeamento é
demonstrada em detalhes no tópico 3.3.
pd 4.3.1 Módulo WEB
PCT01 - br.com.sagcc.portlets
+ AgendaFisioterapeutasPortlet
+ AgendaGeralPortlet
+ AgendaPacientesPortlet
+ com.sun.faces.portlet.FacesPortlet
+ FisioterapeutasPortlet
+ PacientesPortlet
+ UsuarioNotificacaoPortlet
PCT02 - br.com.sagcc.control
+ AgendaFisioterapeutasControl
+ AgendaGeralControl
+ AgendaPacientesControl
+ FisioterapeutasControl
+ PacientesControl
+ UsuarioNotificacaoControl
PCT03 - br.com.sagcc.v alidator
+ FisioterapeutasValidator
+ PacientesValidator
+ UsuarioNotificacaoValidator
PCT04 - br.com.sagcc.util.mail
+ Autenticador
+ EnviadorDeEmail
+ javax.mail.Authenticator
PCT05 - br.com.sagcc.util
+ ApplicationResources.properties
+ ResourcesReader
+ ValidateUtil
PCT06 - br.com.sagcc.serv let
+ AgendaFisioterapeutasServlet
+ AgendaPacientesServlet
+ javax.servlet.http.HttpServlet
Figura 7 – Pacotes do módulo WEB do diagrama de classes de projeto
49
cd br.com.sagcc.portlets
«Portlet»FisioterapeutasPortlet
«Portlet»PacientesPortlet
«Validator»PCT03 - br.com.sagcc.v alidator::FisioterapeutasVali dator
«Validator»PCT03 - br.com.sagcc.v alidator::
PacientesValidator
«Controlador»PCT02 - br.com.sagcc.control::
FisioterapeutasControl
«Controlador»PCT02 - br.com.sagcc.control::
PacientesControl
«Portlet»AgendaPacientesPortlet
«Portlet»UsuarioNotificacaoPortlet
«Validator»PCT03 - br.com.sagcc.v alidator::
UsuarioNotificacaoValidator
«Controlador»PCT02 - br.com.sagcc.control::
AgendaPacientesControl
«Portlet»com.sun.faces.portlet.FacesPortlet
«Controlador»PCT02 - br.com.sagcc.control::
UsuarioNotificacaoControl
«Portlet»AgendaFisioterapeutasPortlet «Portlet»
AgendaGeralPortlet
«Controlador»PCT02 - br.com.sagcc.control::AgendaFisioterapeutas Control
«Controlador»PCT02 - br.com.sagcc.control::AgendaGeralControl
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Figura 8 – Diagrama de classes do pacote br.com.sagcc.portlets
No pacote “br.com.sagcc.portlets” estão localizadas as classes que representam os
Portlets do aplicativo. Cada Portlet herda da classe “com.sun.faces.portlet.FacesPortlet”, que
é uma classe padronizada pela empresa Sun Microsystems para que seja possível utilizar a
tecnologia JSF (JavaServer Faces) em conjunto com a especificação de Portlets. Os métodos
“processAction”, “render”, “renderEdit”, “renderView” e “renderHelp” são operações padrões
da API de Portlets, e devem ser sobrescritos em suas subclasses, como é o caso por exemplo
da classe “AgendaFisioterapeutasPortlet”. Estes métodos têm basicamente a função de
renderizar estados de um Portlet, e processar o controle de ações executadas sobre o mesmo.
50
cd br.com.sagcc.control
com.sun.faces.portlet.FacesPortlet
«Portlet»PCT01 - br.com.sagcc.portlets::AgendaFisioterapeuta sPortlet
«Controlador»AgendaFisioterapeutasControl
com.sun.faces.portlet.FacesPortlet
«Portlet»PCT01 - br.com.sagcc.portlets::AgendaPacientesPortl et
«Controlador»AgendaPacientesControl
«util i ty»PCT04 - br.com.sagcc.util.mail::Env iadorDeEmail
«uti l ity»PCT05 - br.com.sagcc.util::ResourcesReader
«Controlador»AgendaGeralControl
com.sun.faces.portlet.FacesPortlet
«Portlet»PCT01 - br.com.sagcc.portlets::AgendaGeralPortlet
«Controlador»FisioterapeutasControl
«Controlador»PacientesControl
com.sun.faces.portlet.FacesPortlet
«Portlet»PCT01 - br.com.sagcc.portlets::
FisioterapeutasPortlet
com.sun.faces.portlet.FacesPortlet
«Portlet»PCT01 - br.com.sagcc.portlets::PacientesPortlet
«uti l i ty»PCT05 - br.com.sagcc.util::ValidateUtil
«Controlador»UsuarioNotificacaoControl
com.sun.faces.portlet.FacesPortlet
«Portlet»PCT01 - br.com.sagcc.portlets::UsuarioNotificacaoPo rtlet
1
1
*1
*
1
1
1
*
1
*
1
6
1
1
*
11
1
1
*
1
*
11
1
*
1
1
1
Figura 9 – Diagrama de classes do pacote br.com.sagcc.control
No pacote “br.com.sagcc.control” estão as classes que representam os controladores do
aplicativo. Cada controlador é um objeto especial gerenciado pela JSF. Estes controladores,
também conhecidos como Beans Gerenciados (Managed Beans) ou Backing Beans, têm
propriedades privadas com métodos de acesso (getters e setters), associadas aos campos do
formulário JSP. Além disso, possuem também métodos correspondentes aos event listners, ou
ouvidores de eventos, tratando adequadamente eventos disparados pela camada de visão
representada pelas JSPs.
Os Backing Beans são intermediários entre as telas e a lógica do sistema, assumindo o
papel de controladores na arquitetura MVC. Cada Portlet em seu método “processAction” é
responsável por delegar as responsabilidades de controle a um Backing Bean correspondente.
51
cd br.com.sagcc.v alidator
«Validator»FisioterapeutasValidator
«Validator»PacientesValidator
«util ity»PCT05 - br.com.sagcc.util::
ValidateUtil
com.sun.faces.portlet.FacesPortlet
«Portlet»PCT01 - br.com.sagcc.portlets::FisioterapeutasPortl et
com.sun.faces.portlet.FacesPortlet
«Portlet»PCT01 - br.com.sagcc.portlets::PacientesPortlet
«Validator»UsuarioNotificacaoValidator
com.sun.faces.portlet.FacesPortlet
«Portlet»PCT01 - br.com.sagcc.portlets::UsuarioNotificacaoPo rtlet
1
1
1
1
*
1
*
1
*
1
1
1
Figura 10 – Diagrama de classes do pacote br.com.sagcc.validator
Neste pacote estão as classes utilizadas para realizar as validações dos dados digitados
na camada de visão.
Na JSF estas classes são conhecidas como validadores, ou validators. Caso algum
componente de interface da JSP, como um campo texto por exemplo, esteja associado a um
método de um validator, quando o usuário submeter o formulário, a JSF irá invocar
automaticamente este método a fim de realizar a validação do dado digitado. Se for
identificado algum erro de validação, o fluxo da aplicação é retornado à camada de visão
informando uma mensagem de erro ao usuário.
52
cd br.com.sagcc.util.mail
«uti li ty»Env iadorDeEmail
«uti l ity»Autenticador
«uti l ity»javax.mail.Authenticator
«uti l ity»PCT05 - br.com.sagcc.util::ResourcesReader
«Controlador»PCT02 - br.com.sagcc.control::
AgendaPacientesControl
«Controlador»PCT02 - br.com.sagcc.control::AgendaFisioterapeutasControl
«Controlador»PCT02 - br.com.sagcc.control::AgendaGeralControl
*
1
*
1
*
1
*
1
1
*
6
1
*
1
1
1
Figura 11 – Diagrama de classes do pacote br.com.sagcc.util.mail
No pacote “br.com.sagcc.util.mail” estão as classes responsáveis pelo envio de e-mails.
A classe “EnviadorDeEmail” é utilizada para o envio de mensagens de e-mail através do
protocolo Simple Mail Transfer Protocol (SMTP). A classe “Autenticador” encapsula a
codificação para autenticação em servidores SMTP, herdando “javax.mail.Authenticator”. A
classe “javax.mail.Authenticator” representa um objeto que sabe como obter uma
autenticação para uma conexão de rede. Para isso esta classe necessita de informações como
usuário e senha da conta do servidor SMTP.
53
cd br.com.sagcc.util
«uti l i ty»ResourcesReader
«uti l ity»ValidateUtil
«Controlador»PCT02 - br.com.sagcc.control::
FisioterapeutasControl
«Controlador»PCT02 - br.com.sagcc.control::
PacientesControl
«uti l i ty»PCT04 - br.com.sagcc.util.mail::Env iadorDeEmail
«Validator»PCT03 - br.com.sagcc.v alidator::
FisioterapeutasValidator
«Validator»PCT03 - br.com.sagcc.validator::
PacientesValidator
«Controlador»PCT02 - br.com.sagcc.control::
AgendaPacientesControl
«properties fi le»
ApplicationResources.properties
«Controlador»PCT02 - br.com.sagcc.control::AgendaFisioterapeutasControl
«Validator»PCT03 - br.com.sagcc.validator::
UsuarioNotificacaoValidator
«Controlador»PCT02 - br.com.sagcc.control::
AgendaGeralControl
*
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1
1
1
1
*
6
1
*
1
*
1
Figura 12 – Diagrama de classes do pacote br.com.sagcc.util
Neste pacote estão as classes responsáveis pela validação e formatação de valores,
assim como acesso a informações parametrizadas em um arquivo de propriedades.
“ValidateUtil” é uma classe utilitária contendo métodos estáticos para validação e
formatação de valores, enquanto a classe “ResourcesReader” é responsável pela recuperação
dos valores do arquivo de propriedades da aplicação, denominado
“ApplicationResources.properties”. Neste arquivo de parâmetros estão contidas informações
utilizadas na classe “EnviadorDeEmail” para autenticação em um Servidor SMTP, assim
como o HTML do e-mail de notificação enviado na criação, cancelamento e alteração de
agendamentos pela Agenda de Pacientes, e também o HTML do e-mail enviado para o
paciente na confirmação, rejeição ou cancelamento de um agendamento.
54
cd br.com.sagcc.serv let
«Servlet»AgendaPacientesServ let
«Servlet»javax.servlet.http.HttpServlet
«Servlet»AgendaFisioterapeutasServ let
Figura 13 – Diagrama de classes do pacote br.com.sagcc.servlet
O pacote “br.com.sagcc.servlet” contém Servlets codificados especialmente para o
processamento de controle das JSPs que não estão diretamente associadas a um Portlet. No
SAGCC, estas JSPs são os diálogos utilizados para busca de um paciente ou fisioterapeuta,
também conhecidas como List Of Values (LOVs). O controle destes diálogos foi tratado de
forma especial às outras JSPs pois são páginas independentes do HTML principal onde os
Portlets são renderizados.
Os Servlets herdam de “javax.servlet.http.HttpServlet”, que é uma classe abstrata que
possibilita às subclasses a criação de um Servlet que utiliza o protocolo HTTP.
A Figura 14 apresenta o módulo EJB, que contém os pacotes das classes responsáveis
pela camada de modelo.
pd 4.3.2 Módulo EJB
PCT01 - br.com.sagcc.dao.interfaces
+ AgendamentoDAO<Agendamento, Integer>
+ FisioterapeutaDAO<Fisioterapeuta, String>
+ FormaConfirmacaoDAO<FormaConfirmacao, Short>
+ GenericDAO<T, ID extends Serializable>
+ PacienteDAO<Paciente, String>
+ SituacaoAgendamentoDAO<SituacaoAgendamento, Short>
+ UsuarioNotificacaoDAO<UsuarioNotificacao, Integer>
PCT02 - br.com.sagcc.dao.ejb
+ AgendamentoDAOBean
+ FisioterapeutaDAOBean
+ FormaConfimacaoDAOBean
+ GenericEJBDAO<T, ID extends Serializable>
+ PacienteDAOBean
+ SituacaoAgendamentoDAOBean
+ UsuarioNotificacaoDAOBean
Figura 14 – Pacotes do módulo EJB do diagrama de classes de projeto
55
cd br.com.sagcc.dao.interfaces
«interface»GenericDAO<T, ID extends Serializable>
«interface»AgendamentoDAO<Agendamento, Integer>
«interface»FisioterapeutaDAO<Fisioterapeuta, String>
«interface»PacienteDAO<Paciente, String>
«interface»UsuarioNotificacaoDAO<UsuarioNotificacao, Integer>
«interface»FormaConfirmacaoDAO<FormaConfirmacao, Short>
«interface»SituacaoAgendamentoDAO<SituacaoAgendamento, Short>
«EJB»PCT02 - br.com.sagcc.dao.ejb::AgendamentoDAOBean
«EJB»PCT02 - br.com.sagcc.dao.ejb::FisioterapeutaDAOBean
«EJB»PCT02 - br.com.sagcc.dao.ejb::FormaConfimacaoDAOBea n
«EJB»PCT02 - br.com.sagcc.dao.ejb::PacienteDAOBean
«EJB»PCT02 - br.com.sagcc.dao.ejb::SituacaoAgendamentoDA OBean
«EJB»PCT02 - br.com.sagcc.dao.ejb::UsuarioNotificacaoDAO Bean
«type»PCT02 - br.com.sagcc.dao.ejb::GenericEJBDAO<T, ID extends Serializable>
«real ize»
«real ize»
«real ize»
«real ize»
«real ize»
«realize»
«realize»
Figura 15 – Diagrama de classes do pacote br.com.sagcc.dao.interfaces
Neste pacote estão as interfaces responsáveis pela implementação do padrão DAO.
“GenericDAO” é uma interface compartilhada por todos DAOs de negócio, que são objetos
utilizados para realizar operações em um BD. Operações básicas de DAOs como create, read,
update e delete, conhecidas como operações CRUD, são isoladas nesta interface e
compartilhadas através de todas as implementações dos DAOs.
56
cd br.com.sagcc.dao.ejb
«type»GenericEJBDAO<T, ID extends Serializable>
«interface»PCT01 - br.com.sagcc.dao.interfaces::GenericDAO<T, ID extends Serializable>
«EJB»AgendamentoDAOBean
«interface»PCT01 - br.com.sagcc.dao.interfaces::AgendamentoDAO<Agendamento, Integer>
«EJB»FisioterapeutaDAOBean
«EJB»FormaConfimacaoDAOBean
«interface»PCT01 - br.com.sagcc.dao.interfaces::FisioterapeutaDAO<Fisioterapeuta, String>
«interface»PCT01 - br.com.sagcc.dao.interfaces::FormaConfirmacaoDAO<FormaConfirmacao, Short>
«interface»PCT01 - br.com.sagcc.dao.interfaces::PacienteDAO<Paciente, String>
«interface»PCT01 - br.com.sagcc.dao.interfaces::SituacaoAgendamentoDAO<SituacaoAgendamento, Short>
«interface»PCT01 - br.com.sagcc.dao.interfaces::UsuarioNotificacaoDAO<UsuarioNotificacao, Integer>
«EJB»PacienteDAOBean
«EJB»SituacaoAgendamentoDAOBean
«EJB»UsuarioNotificacaoDAOBean
«realize»
«realize»
«realize»«realize»
«realize»
«realize»
«realize»
Figura 16 – Diagrama de classes do pacote br.com.sagcc.dao.ejb
Neste pacote está contida a classe “GenericEJBDAO” e os EJBs que herdam a mesma.
“GenericEJBDAO” é uma classe que implementa as operações genéricas CRUD dos
DAOs utilizando a JPA (Java Persistence API) e o framework Hibernate, respeitando a
definição da interface “GenericDAO” contida no pacote “br.com.sagcc.dao.interfaces”. Os EJBs
devem herdar desta classe, parametrizando se necessário outros métodos específicos
responsáveis pela codificação das operações não CRUD já implementadas na superclasse.
Esta arquitetura assume a utilização de uma abordagem 1:1 para o modelo
entidade/DAO, ou seja, para cada entidade deverá existir um DAO. Conforme explicado
anteriormente, as entidades são relacionadas no diagrama de classes de domínio.
A classe “AgendamentoDAOBean”, por exemplo, é um EJB que herda as operações
CRUD de “GenericEJBDAO”, e provê outros métodos específicos para uma entidade
“Agendamento”, como “buscaAgendamentosDia” e “buscaAgendamentosPeriodo”.
57
3.3 IMPLEMENTAÇÃO
Este tópico contém o detalhamento da implementação da aplicação, apresentando
primeiramente as técnicas e ferramentas utilizadas no desenvolvimento do SAGCC, e
posteriormente trechos contendo características relevantes da codificação do sistema.
As ferramentas utilizadas na especificação e implementação são conceituadas no
mercado de desenvolvimento de software. A maioria delas é livre e possui rica documentação,
sendo disponibilizada para download gratuito na Internet. Estas ferramentas juntamente com
seus produtores e versões são apresentadas na Tabela 1. Em seguida é apresentada a descrição
detalhada das ferramentas e a utilização das mesmas na implementação.
Tabela 1 - Ferramentas utilizadas na especificação e implementação
Ferramentas Produtores Versões Enterprise Architect Sparx Systems 6.0.780 Eclipse IDE Eclipse Foundation 3.2 J2EE (Java 2 Platform Enterprise Edition) Sun Microsystems 5.0 J2SE (Java 2 Platform Standard Edition) Sun Microsystems 5.0 Java 2 Platform Standard Edition Development Kit (JDK) Sun Microsystems 5.0 MyEclipse Enterprise Workbench Genuitec 5.1.0 GA MySQL MySQL AB 5.0 MySQL Query Browser MySQL AB 1.2.5 (Beta)
A especificação foi realizada através da ferramenta Computer Aided Software
Enginnering (CASE) Enterprise Architect (EA). Através desta foram construídos os
diagramas de pacote, casos de uso e classes.
Para a implementação da aplicação foi utilizado o quite de desenvolvimento da
plataforma Java 2 Platform Standard Edition (J2SE): o J2SE System Development Kit (JDK).
O JDK 5.0 contém recursos como as “Anotações”, por exemplo, necessários para utilização
das tecnologias da Java 2 Platform Enterprise Edition (J2EE) implementadas no SAGCC.
Anotações são uma nova forma de definir metadados diretamente nas classes Java, através de
tipos pré-definidos.
O ambiente de desenvolvimento utilizado foi o Eclipse Itegrated Development
Environment (IDE). O Eclipse traz uma série de editores úteis para o desenvolvimento de
aplicações Java, e provê outras funcionalidades essenciais para o desenvolvedor, como
diferentes perspectivas para depuração dos fontes (debug), e navegação através dos pacotes da
aplicação. Porém foi necessário instalar um plugin que trouxesse um ambiente completo com
58
suporte às diferentes tecnologias utilizadas no desenvolvimento do sistema: o MyEclipse
Enterprise Workbench.
As principais funcionalidades do MyEclipse utilizadas foram os editores com suporte à
JSF para construção de páginas JSP, que possibilitam a pré-visualização das páginas HTML
resultantes. Além disso, o MyEclipse possui a característica de integração com vários
servidores de aplicação Java, incluindo o servidor JBoss utilizado no SAGCC. Esta função
trouxe a possibilidade de depurar em tempo de execução o código fonte dos Portlets, EJBs e
também do gerenciamento da aplicação pelo JBoss (deploy), facilitando a identificação e
solução de problemas.
O SGDB (Sistema Gerenciador de Banco de Dados) utilizado para persistir os dados
do SAGCC e do portal foi o MySQL.
A ferramenta MySQL Query Browser possibilitou a consulta dos dados tanto do
aplicativo desenvolvido quanto do portal, através de comandos SQL. Esta ferramenta trouxe a
possibilidade de gerenciamento dos dados através de uma interface gráfica, que permitiu
visualizar e editar as definições das tabelas do BD.
Além das ferramentas utilizadas para a especificação e implementação, também foram
utilizadas tecnologias que facilitaram o desenvolvimento do trabalho e agregaram
padronização e qualidade ao mesmo. Estas tecnologias, os órgãos responsáveis pelas mesmas,
e suas versões são apresentadas na Tabela 2.
Tabela 2 - Tecnologias utilizadas na especificação e implementação
Tecnologias Órgãos Responsáveis Versões Ant Apache Software Foundation (ASF) 1.6.5 EJB (Enterprise JavaBeans) Sun Microsystems 3.0 Extensible Markup Language (XML) Object Management Group (OMG) 1.0 Hibernate RedHat 3.2 HiperText Markup Language (HTML) World Wide Web Consortium (W3C) 4.0.1 JavaMail Sun Microsystems 1.5 Java Naming and Directory Interface (JNDI) Sun Microsystems 1.2 JBoss Server RedHat 4.0.5.GA JPA (Java Persistence API) Sun Microsystems 1.0 JSF (JavaServer Faces) Sun Microsystems 1.1 JSP Sun Microsystems 2.0 Liferay Portal Liferay 4.2.0 Servlets Sun Microsystems 2.4 Tomcat Apache Software Foundation (ASF) 5.5 UML (Unified Modeling Language) Object Management Group (OMG) 2.0
A linguagem UML foi utilizada em conjunto com a ferramenta CASE Enterprise
59
Architect para a especificação da aplicação, a fim de construir os modelos e diagramas de
pacotes, casos de uso e classes.
Para o envio dos e-mails de notificação, foi utilizada a API JavaMail. Esta API é
padronizada pela Sun Microsystems, provendo suporte a vários protocolos de envio e leitura
de e-mails, suporte a mensagens HTML e a mensagens com anexos.
O Ant é uma ferramenta indispensável em praticamente qualquer projeto Java. É
responsável por automatizar tarefas como compilação, geração de Java Archives (JARs)10,
WEB Archives (WARs)11 ou Enterprise Archives (EARs)12, criar, alterar ou excluir diretórios,
gerar código e executar classes Java, dentre outros. Neste trabalho as principais tarefas
executadas pelo Ant foram compilar os fontes e gerar os JARs, WARs e EARs do SAGCC e
do portal Liferay, assim como realizar gerenciamento automático de novos arquivos criados
(hot-deploy) tanto do módulo EJB quanto do WEB. O hot-deploy contribuiu para aumentar a
produtividade no desenvolvimento da aplicação, pois após realizar uma alteração nos fontes e
executar o Ant, as alterações são automaticamente detectadas pelo servidor de aplicação
JBoss. Para tanto foi construído um arquivo “build.xml” utilizando a Extensible Markup
Language (XML), contendo a definição das tarefas citadas. Estas tarefas são denominadas
tasks no dialeto do Ant.
A XML foi utilizada em outras tecnologias além do Ant, como para declarar o fluxo de
navegação das JSPs através da JSF e definir as configurações de conectividade com o BD
através do Hibernate e a JPA. Além disso, foi utilizada para declarar as características de cada
Portlet, como nome e perfis de acesso, e também definir as configurações da aplicação WEB.
O Quadro 1 ilustra um trecho do arquivo “faces-config.xml”, onde são declaradas as
regras de navegação para cada Portlet, utilizando para isto a JSF.
10 Arquivos compactados contendo classes Java. 11 Arquivos compactados contendo classes Java ou JARs. São utilizados para representar uma aplicação WEB. 12 Arquivos compactados contendo classes Java, JARs e/ou WARs. São utilizados para representar uma aplicação finalruída na J2EE (Java 2 Platform Enterprise Edition).
60
Quadro 1 – Trecho do arquivo que contém as regras de navegação para cada Portlet
No Quadro 1 estão definidas as regras de navegação para uma JSP do Portlet de
cadastro de pacientes.
A página de origem é a “pacientesCadastro.jsp”, definida na tag XML “from-view-id”.
Após a especificação da página de origem, são incluídas todas as possibilidades de navegação
a partir desta página. Dependendo do retorno do controlador deste Portlet à requisição
submetida pelo usuário, ilustrado neste caso pelas tags “from-outcome”, a resposta será
redirecionada para uma JSP específica, descrita na tag “to-view-id”.
Considerando o caso ilustrado, a partir da página “pacientesCadastro.jsp” é possível
ser redirecionado para as páginas “pacientesConsulta.jsp”, caso o usuário clique no botão da
interface para localizar um paciente, ou para a própria “pacientesCadastro.jsp”, caso o usuário
tenha cadastrado um paciente com sucesso, ou se foi identificado algum problema durante o
processamento da requisição pelo controlador, como por exemplo um erro de validação (este
tipo de verificação é realizada em uma classe validadora ou no controlador). Todas regras de
navegação da aplicação estão definidas desta forma, permitindo um fácil mapeamento de
quais condições poderão redirecionar uma requisição para uma determinada JSP. Este modelo
garante também a divisão eficiente das camadas de visão e controle, requisito fundamental do
padrão de projeto MVC. Uma das tecnologias utilizadas para separação da camada de
controle da camada de modelo, foram os POJOs (Plain Old Java Objects) e o mapeamento
61
objeto-relacional através de anotações.
O Quadro 2 demonstra uma classe Java anotada, mais especificamente um POJO que
representa um “Paciente”. Nesta classe é realizado o mapeamento da entidade para uma tabela
do BD, assim como dos atributos da classe para suas
colunas.
Quadro 2 – Trecho da classe “Paciente” demonstrando o uso de anotações
A anotação “Entity” garante que os objetos desta classe serão gerenciados pela JPA
como objetos que podem ser persistidos. A anotação “Table” mapeia a classe “Pessoa” para
uma tabela do BD relacional, enquanto que as anotações “Column” declaram para quais
campos os atributos da classe estão mapeados, assim como suas características (no caso do
Quadro 2, são tamanho e obrigatoriedade). Em outros POJOs são realizados diferentes tipos
de mapeamento, como o de chaves estrangeiras, chave primária, multiplicidade e herança.
Estas entidades são manipuladas através da JPA e o Hibermate, que utilizam conexões com o
BD.
O Quadro 3 apresenta o arquivo “sagcc-ds.xml”, que define uma fonte de dados
62
(datasource) para o SAGCC.
Quadro 3 – Arquivo que contém as configurações de conexão com o BD
Neste arquivo é definido o nome do datasource (SAGCCDS), e as configurações para
conexão com o BD, como a classe do driver de conexão JDBC do SGBD (neste caso o
MySQL), a Uniform Resource Locator (URL) de conexão com o banco de dados (nesta URL
está descrito qual o nome do BD para a conexão, sendo neste caso “SAGCC”), usuário e
senha do banco, e a quantidade possível (mínima e máxima), de conexões ativas com o BD
em um determinado momento.
O datasource é carregado pelo servidor JBoss quando este é iniciado, podendo ser
requerido a qualquer momento pela aplicação a fim de solicitar uma conexão com o BD. Esta
fonte de dados é utilizada pela JPA e o Hibernate para realizar as operações de persistência. A
associação entre o datasource e a JPA/Hibernate é realizada no arquivo “persistence.xml”,
ilustrado no Quadro 4.
Quadro 4 – Arquivo que contém as configurações da JPA e Hibernate
O arquivo “persistence.xml” define uma unidade de persistência com o banco de
dados, que possuirá um número arbitrário de propriedades dependentes do provedor da JPA
utilizado. Como não é especificado nenhum fornecedor, a JPA assume a utilização do
Hibermate. A associação do datasource à unidade de persistência é realizada na tag “jta-data-
63
source”. A propriedade “hibernate.hbm2ddl.auto” configurada com o valor update faz com
que qualquer alteração nas classes anotadas seja refletida automaticamente na base de dados
selecionada no datasource. O Hibernate gera e executa o código de definição das tabelas e
seus relacionamentos automaticamente, tendo como base os POJOs anotados, não sendo
necessário nenhum esforço adicional para criar o BD físico. As demais propriedades do
arquivo definem a exibição em logs e formatação das sentenças SQL geradas pelo Hibernate.
O Quadro 5 demonstra o método “localizarTodos” da classe controladora
“AgendaPacientesControl”. Este método é responsável por localizar todos os agendamentos
de um determinado paciente e adiciona-los a um mapa (representado na linguagem Java pela
classe “java.util.HashMap”), para que posteriormente a camada de apresentação através de
uma JSP, liste os registros para o usuário.
Quadro 5 – Trecho de código responsável por localizar todos agendamentos de um paciente
A primeira elipse representa o código responsável por recuperar o EJB
“AgendamentoDAOBean” para que posteriormente o mesmo seja utilizado para acesso ao
BD, recuperando todos os agendamentos do paciente.
O objeto é obtido através do contexto da Java Naming and Directory Interface (JNDI),
que neste caso é a tecnologia responsável por recuperar os EJBs instanciados na memória. Os
EJBs são instanciados em memória após o gerenciamento, ou seja deploy da aplicação pelo
servidor JBoss. Este EJB pode ser recuperado a qualquer momento pelo aplicativo, a fim de
64
que seus serviços sejam utilizados, apenas informando à JNDI qual o nome que o objeto está
anexado ao contexto. Conforme explicitado no Quadro 5, este texto é composto pelo nome da
aplicação EAR (“sagcc”), o nome do EJB (“AgendamentoDAOBean”), e o tipo de acesso
(“local”, visto se tratar de uma aplicação WEB, e não cliente/servidor).
Após recuperar o EJB com a instrução explicada, cria-se um novo objeto do tipo
“Paciente”, o qual será utilizado para busca dos agendamentos na BD. A segunda elipse
evidencia a configuração do atributo “cgcCpf” do objeto, que para a classe “Paciente”
representa a chave primária da tabela “PACIENTE”. O valor configurado é obtido do
controlador, que mantém o estado do “cgcCpf” dos agendamentos a serem buscados.
A terceira elipse chama o método “buscaAgendamentosPessoa” de
“AgendamentoDAOBean”, que retornará uma lista contendo todos “Agendamentos” do
paciente. A codificação deste método é ilustrada no Quadro 6.
Quadro 6 – Trecho de código responsável por iniciar uma transação com o BD a fim de buscar todos agendamentos de um paciente
Quando um método de um EJB é invocado, inicia-se automaticamente uma transação
com o BD. Esta transação é finalizada após a execução do método, caso não seja antes
programaticamente encerrada pelo desenvolvedor. A forma que a conexão com o BD é
recuperada e utilizada fica transparente, pois é tratada pela tecnologia EJB 3.0 e a JPA.
65
O retângulo vermelho no Quadro 6 evidencia o código responsável por executar a
consulta no BD, considerando o objeto “Paciente” passado como parâmetro no controlador.
Primeiramente é recuperado um objeto do tipo “javax.persistence.EntityManager”, herdado da
superclasse “GenericEJBDAO”. Este objeto encapsula uma sessão com o BD. Posteriormente
é criada uma consulta nomeada, ou named query, com o “cgcCpf” do “Paciente”, retornando
uma lista contendo todos agendamentos para o controlador.
O retângulo vermelho no Quadro 7 demonstra a named query anotada na classe
“Agendamento”, responsável por retornar os agendamentos de um paciente.
Quadro 7 – Consulta declarada para recuperar todos agendamentos de um paciente
As named queries são consultas estáticas escritas através da Enterprise JavaBeans
Query Language (EJB-QL), que é uma linguagem de consultas orientada a objetos,
sintaticamente muito parecida com a SQL. Esta tecnologia traz portabilidade às consultas,
66
pois usam classes anotadas (entidades) para o modelo de dados, não dependendo portanto do
dialeto SQL utilizado pelo SGBD configurado.
3.4 OPERACIONALIDADE DA IMPLEMENTAÇÃO
Esta seção apresenta um estudo de caso, do ponto de vista do usuário, objetivando
demonstrar a funcionalidade e operacionalidade do aplicativo. O conteúdo apresentado é
composto por uma ilustração simplificada do funcionamento do sistema, representado na
Figura 17, e a explicação detalhada das interfaces e seu funcionamento relativo aos módulos
da clínica de fisioterapia e do paciente.
Figura 17 – Ilustração do funcionamento do sistema do ponto de vista do usuário
A Figura 17 demonstra de forma simplificada o funcionamento do SAGCC.
Primeiramente o usuário acessa o portal por meio de um navegador WEB instalado em um
microcomputador. Cada ação executada é enviada através da Internet ao servidor onde o
aplicativo está instalado. Este servidor processa a informação, acessa o banco de dados caso
seja necessário, e retorna o resultado para o usuário.
3.4.1 Módulo da clínica de fisioterapia
Ao digitar o endereço do SAGCC, o usuário é direcionado para a página principal do
portal apresentada na Figura 18. Para acessar o sistema o usuário clica na aba “Acesso”.
67
Figura 18 – Página de apresentação do portal
A Figura 19 ilustra um profissional da clínica com perfil de administrador do portal
acessando o SAGCC. Este usuário possui um cadastro pré-definido no banco de dados do
portal.
Figura 19 – Acesso ao sistema pelo administrador do portal
Após efetuar o login informando o nome de usuário e senha, o administrador tem
68
acesso aos Portlets de administração do portal, delimitados na página “Administração”
ilustrada na Figura 20, assim como os Portlets do SAGCC configurados nas demais páginas.
As funcionalidades dos Portlets de administração serão detalhadas mais à diante. Para acessar
uma página específica o usuário deve clicar sobre o nome da aba.
Figura 20 – Página de administração do portal
A Figura 21 apresenta o Portlet de cadastro de pacientes acessado por meio da aba
“Paciente”.
Figura 21 – Cadastro de pacientes pelo administrador do portal
69
Após cadastrar um paciente, é possível localiza-lo clicando no botão “Localizar”. A
página de consulta de pacientes é demonstrada na Figura 22. Para listar todos pacientes
cadastrados, o administrador do portal não deve informar nenhum valor nos campos desta
página.
Figura 22 – Consulta de pacientes pelo administrador do portal
A Figura 23 ilustra a página de resultado de uma consulta de pacientes.
Figura 23 – Resultado da consulta de pacientes pelo administrador do portal
70
Após realizar a consulta de um paciente, o administrador do portal pode alterar os
dados cadastrais clicando no botão “Alterar”. A página de alteração de um paciente está
disponível na Figura 24.
Figura 24 – Alteração de um paciente pelo administrador do portal
A Figura 25 ilustra a página de cadastro de fisioterapeutas acessada por meio da aba
“Fisioterapeuta”. Neste cadastro, conforme indicado, é possível informar se o fisioterapeuta
em questão deve receber e-mails de notificação no momento que um paciente cancelar, alterar
ou efetuar um agendamento.
Figura 25 – Cadastro de fisioterapeutas pelo administrador do portal
71
Assim como no cadastro de pacientes, é possível localizar todos os fisioterapeutas ou
um em específico clicando no botão “Localizar”. A página de consulta de fisioterapeutas é
demonstrada na Figura 26.
Figura 26 – Consulta de fisioterapeutas pelo administrador do portal
A Figura 27 ilustra a página de resultado de uma consulta de fisioterapeutas.
Figura 27 – Resultado da consulta de fisioterapeutas pelo administrador do portal
72
Após realizar a consulta de um fisioterapeuta, o administrador do portal pode alterar os
dados cadastrais clicando no botão “Alterar”. A página de alteração de um fisioterapeuta está
disponível na Figura 28.
Figura 28 – Alteração de um fisioterapeuta pelo administrador do portal
Para incluir um cadastro a fim de receber os e-mails de notificação, o administrador do
portal utiliza o Portlet de usuários de notificação ilustrado na Figura 29. Este Portlet é
acessado através da aba “Usuário Notificação”.
Figura 29 – Cadastro de usuários de notificação pelo administrador do portal
73
Após cadastrar um usuário de notificação, é possível localiza-lo clicando no botão
“Localizar”. A página de consulta de usuários de notificação é demonstrada na Figura 30.
Para listar todos os usuários de notificação cadastrados, assim como nos demais cadastros
apresentados, o administrador do portal não deve informar nenhum valor nos campos desta
página.
Figura 30 – Consulta de usuários de notificação pelo administrador do portal
A Figura 31 ilustra a página de resultado de uma consulta de usuários de notificação.
Figura 31 – Resultado da consulta de usuários de notificação pelo administrador do portal
74
Ao realizar a consulta de um usuário de notificação, o administrador do portal pode
alterar os dados cadastrais clicando no botão “Alterar”, ou excluí-los utilizando o botão
“Excluir”. A página de alteração de um usuário de notificação está disponível na Figura 32.
Figura 32 – Alteração de um usuário de notificação pelo administrador do portal
Os Portlets de administração do portal, conforme citado no início desta seção, estão
disponíveis na aba “Administração”. Estes Portlets são utilizados para administração de perfis
de acesso e usuários, sendo também responsáveis por alterar outras configurações do portal.
As principais funcionalidades do SAGCC configuradas em cada Portlet de administração são
detalhadas abaixo:
• Administração de Usuários: responsável pelo cadastro de usuários no portal e
associação de um usuário a um perfil de acesso, ou seja, a um papel.
• Administração de Comunidades: responsável pela associação de uma comunidade
a um usuário do portal.
A Figura 33 indica o atalho de acesso à página responsável pelo cadastro de um
usuário no portal. A partir da visão demonstrada nesta figura é possível consultar um usuário
específico informando o nome, sobrenome, e-mail ou status.
75
Figura 33 – Atalho para o cadastro de um usuário do portal
Na Figura 34 está ilustrada a lista dos usuários cadastrados no portal. Para incluir um
novo usuário é necessário clicar no botão “Adicione”. Para editar as informações de um
usuário já existente, deve-se clicar no botão “Edite”. O botão “Desative” é utilizado para
desativar um usuário pré-cadastrado no portal.
Figura 34 – Lista de usuários cadastrados no portal
76
A página de cadastro de usuários no portal está demonstrada na Figura 33.
Figura 35 – Cadastro de um usuário do portal
Após incluir um usuário no portal é disponibilizada uma área para digitação de
informações mais detalhadas do usuário, como idioma e mensagem de boas vindas. Estas
características são demonstradas na Figura 36. Nesta figura a aba “Papéis” indica o atalho
para editar os perfis de acesso, ou seja, papéis, configurados para o usuário.
Figura 36 – Cadastro de informações detalhadas de um usuário do portal
77
Existem quatro papéis padrão no portal Liferay. São eles:
a) Administrator – representa um usuário administrador que pode gerenciar os
Portlets, usuários, comunidades, e perfis de acesso do portal;
b) Power User – representa um usuário que pode gerenciar os Portlets disponíveis
para o seu perfil de acesso, assim como alterar informações relativas à sua conta no
portal;
c) User - representa um usuário que pode acessar os Portlets disponíveis para o seu
perfil de acesso e alterar informações relativas à sua conta no portal;
d) Guest – representa um visitante do portal, que ainda não possui uma conta de
acesso. Estes usuários estão restritos apenas à página de apresentação do portal.
A Figura 36 demonstra os papéis que os usuários são adicionados automaticamente ao
criar uma nova conta. Com base na descrição de cada papel, o administrador opta por quais
perfis o usuário deverá pertencer. Caso queira excluir um papel em especial para o usuário, o
administrador pode utilizar o botão indicado na Figura 37.
Figura 37 – Associação de papéis a um usuário do portal
Após cadastrar um usuário no portal, o administrador pode adicioná-lo a uma das
comunidades existentes. Comunidades são modelos de páginas pré-definidos, que tendem a
padronizar a utilização do portal por determinados grupos de usuários. Por exemplo, a
78
comunidade dos pacientes deve conter apenas os Portlets de cadastro de pacientes e agenda de
pacientes, restringindo o acesso às funcionalidades tangíveis a este tipo de usuário.
A Figura 38 ilustra como acessar as comunidades definidas no portal. É também
possível buscar uma comunidade específica pelo nome.
Figura 38 – Atalho para acessar as comunidades definidas no portal
Existem três tipos de comunidades configuradas no portal:
a) Guest – comunidade destinada aos usuários visitantes do portal. Restringe quais
Portlets deverão ser apresentados na página de apresentação do portal;
b) Pacientes - comunidade destinada aos usuários do sistema que são pacientes da
clínica de fisioterapia. Restringe quais Portlets deverão ser apresentados aos
pacientes da clínica que possuem acesso ao portal;
c) Profissional da Clínica - comunidade destinada aos usuários do sistema que são
profissionais da clínica de fisioterapia. Restringe quais Portlets deverão ser
apresentados aos profissionais da clínica que possuem acesso ao portal.
A lista das comunidades é ilustrada na Figura 39.
79
Figura 39 – Lista de comunidades do portal
Ainda na página da Figura 39, é possível delegar uma determinada comunidade a um
ou mais usuários pré-cadastrados. A Figura 40 demonstra a página que contém todos os
usuários associados à comunidade “Profissional da Clínica”. Para adicionar um ou mais
usuários à comunidade, o administrador do portal acessa a aba “Disponível”.
Figura 40 – Lista de usuários de uma comunidade
80
Após selecionar os novos usuários que farão parte da comunidade, o administrador do
portal clica sobre o botão “Associações Do Update” e finaliza a operação. Esta ação está
demonstrada na Figura 41.
Figura 41 – Associação de usuários a uma comunidade
O administrador do portal possui acesso a três tipos diferentes de agenda: agenda do
paciente, agenda do fisioterapeuta e agenda geral. A visão de meses da agenda de pacientes é
demonstrada na Figura 42. A agenda de pacientes é acessada através da aba “Agenda
Paciente”.
Figura 42 – Visão da agenda de pacientes por mês
81
Para visualizar os agendamentos de um paciente em específico, o administrador do
portal deve selecionar o paciente clicando sobre o botão “Localizar”. O Portlet não irá
considerar nenhum agendamento, caso o paciente da agenda não seja previamente
selecionado. A Figura 43 ilustra a página de consulta do paciente.
Figura 43 – Consulta do paciente da agenda de pacientes
Após consultar o paciente da agenda, o administrador do portal deverá clicar sobre seu
nome na página de consulta, fazendo com que o Portlet associe o paciente à agenda.
A Figura 44 demonstra um paciente associado à agenda de pacientes.
Figura 44 – Associação de um paciente à agenda de pacientes
82
O administrador do portal pode selecionar o mês e ano do agendamento pelas caixas de
diálogo, conforme a Figura 45.
Figura 45 – Seleção do mês e ano do agendamento da agenda de pacientes
Após selecionar o mês e ano do agendamento, o administrador do portal pode
selecionar o dia do agendamento clicando sobre o link associado ao dia do mês no calendário.
A partir desta página o administrador pode ainda criar um novo agendamento para o paciente,
clicando no botão “Novo Agendamento”, acessar a visão da agenda por ano clicando no botão
“Calendário Ano”, ou listar todos agendamentos do paciente clicando no botão “Todos
Agendamentos”.
A Figura 46 demonstra a página com a visão de agendamentos por ano. Por esta visão
o administrador do portal pode acessar os agendamentos de qualquer dia de um ano
selecionado na caixa “Ano”. Pode-se selecionar o dia do agendamento clicando sobre o link
associado ao dia do mês no calendário, ou acessar as demais páginas da agenda de pacientes
através dos botões disponíveis na parte inferior do Portlet.
83
Figura 46 – Visão da agenda de pacientes por ano
Ao clicar em um dia em específico da visão por mês ou ano, o administrador do portal
é direcionado para a página ilustrada na Figura 47.
Figura 47 – Agendamentos do dia de um determinado paciente
84
Nesta página o administrador do portal possui a oportunidade de alterar um
determinado agendamento clicando no botão “Alterar”, ou acessar as demais páginas da
agenda de pacientes através dos botões disponíveis na parte inferior do Portlet.
A Figura 48 ilustra uma lista contendo todos agendamentos de um paciente, acessada
por meio do botão “Todos Agendamentos”.
Figura 48 – Lista com todos agendamentos de um determinado paciente
A Figura 49 demonstra a página de inclusão de um novo agendamento pela agenda de
pacientes.
Figura 49 – Página de inclusão de um novo agendamento pela agenda de pacientes
85
Nesta página o administrador do portal pode selecionar o paciente do novo
agendamento, assim como o ano, mês, dia e hora, uma ou mais formas de confirmação, digitar
o título do agendamento e uma descrição da patologia. O administrador do portal pode
também acessar as demais páginas da agenda de pacientes através dos botões disponíveis na
parte inferior do Portlet.
Após efetuar um agendamento pela agenda de pacientes o sistema envia
automaticamente um e-mail para os usuários de notificação cadastrados. O modelo do e-mail
de notificação de um novo agendamento realizado pela agenda de pacientes é apresentado no
Apêndice B. Na Figura 50 é ilustrado o correio acessado por um webmail.
Figura 50 – Correio de notificação acessado por um webmail
Por meio das páginas de consultas de agendamentos apresentadas, o administrador do
portal pode alterar os dados de um agendamento pré-cadastrado. A Figura 51 demonstra a
página de alteração de um agendamento pela agenda de pacientes.
86
Figura 51 – Página de alteração de um agendamento pela agenda de pacientes
A partir desta tela o administrador do portal pode alterar os dados de um agendamento
cadastrado, assim como acessar as demais páginas da agenda de pacientes através dos botões
disponíveis na parte inferior do Portlet. O administrador pode ainda cancelar o agendamento
por meio do botão “Cancelar Agendamento”. A Figura 51 ilustra a página de um
agendamento incluído, com os campos habilitados para edição.
Caso o administrador do portal cancele ou altere o agendamento por meio da agenda
de pacientes, o sistema envia automaticamente um e-mail para os usuários de notificação
cadastrados informando a ação. O modelo do e-mail de notificação de um agendamento
alterado ou cancelado pela agenda de pacientes é apresentado no Apêndice B.
A Figura 52 demonstra a página de um agendamento cancelado, com os campos
desabilitados para edição.
87
Figura 52 – Consulta de um agendamento cancelado por meio da agenda de pacientes
A Figura 53 ilustra a página de um agendamento rejeitado pela clínica, com os campos
desabilitados para edição.
Figura 53 – Consulta de um agendamento rejeitado pela clínica por meio da agenda de pacientes
A Figura 54 apresenta a página de um agendamento confirmado pela clínica, com os
88
campos desabilitados para edição, exceto pelo botão para cancelamento do agendamento.
Figura 54 – Consulta de um agendamento confirmado pela clínica por meio da agenda de pacientes
A Figura 55 ilustra a visão de meses da agenda de fisioterapeutas, acessada por meio
da aba “Agenda Fisioterapeuta”.
Figura 55 – Visão da agenda de fisioterapeutas por mês
89
Para visualizar os agendamentos de um fisioterapeuta em específico, assim como na
agenda de pacientes, o administrador do portal deve selecionar o fisioterapeuta clicando sobre
o botão “Localizar”. O Portlet não irá considerar nenhum agendamento, caso o fisioterapeuta
da agenda não seja previamente selecionado. A Figura 56 ilustra a página de consulta do
fisioterapeuta.
Figura 56 – Consulta do fisioterapeuta da agenda de fisioterapeutas
Após consultar o fisioterapeuta da agenda, o administrador do portal deverá clicar
sobre seu nome na página de consulta, fazendo com que o Portlet associe o fisioterapeuta à
agenda.
A Figura 57 demonstra um fisioterapeuta associado à agenda de fisioterapeutas.
90
Figura 57 –Associação de um fisioterapeuta à agenda de fisioterapeutas
O comportamento das outras páginas da agenda de fisioterapeutas é singular ao
descrito para agenda de pacientes.
Figura 58 – Seleção do mês e ano do agendamento da agenda de fisioterapeutas
91
Figura 59 – Visão da agenda de fisioterapeutas por ano e seleção do ano do agendamento
Figura 60 – Agendamentos do dia de um determinado fisioterapeuta
92
Figura 61 – Lista com todos agendamentos de um determinado fisioterapeuta
A Figura 62 demonstra a página de inclusão de um novo agendamento pela agenda de
fisioterapeutas. O cadastro é semelhante ao existente na agenda de pacientes, porém o
administrador do portal também deve informar o fisioterapeuta do atendimento, além do
paciente, podendo escolher um dos status disponíveis para o agendamento.
Ao realizar a confirmação, rejeição ou cancelamento de um agendamento por meio da
agenda de fisioterapeutas, e se este agendamento possuir a forma de confirmação por e-mail,
o sistema irá enviar um correio eletrônico para o paciente do agendamento. Os modelos dos e-
mails de confirmação, rejeição e cancelamento dos agendamentos estão descritos no Apêndice
B.
93
Figura 62 – Página de inclusão de um novo agendamento pela agenda de fisioterapeutas
Figura 63 – Página de alteração de um agendamento pela agenda de fisioterapeutas
94
Figura 64 – Consulta de um agendamento cancelado por meio da agenda de fisioterapeutas
Figura 65 – Consulta de um agendamento rejeitado pela clínica por meio da agenda de fisioterapeutas
95
Figura 66 – Consulta de um agendamento confirmado pela clínica por meio da agenda de fisioterapeutas
A Figura 67 ilustra a visão de meses da agenda geral, acessada por meio da aba
“Agenda Geral”. O comportamento das páginas da agenda geral é singular ao descrito para a
agenda dos pacientes e fisioterapeutas, com a característica de não ser necessário informar o
paciente ou fisioterapeuta nas páginas de consulta, pois são considerados todos agendamentos
da base de dados, respeitando o filtro por dia caso seja especificado.
Figura 67 – Visão da agenda geral por mês
96
Figura 68 – Seleção do mês e ano do agendamento da agenda geral
Figura 69 – Visão da agenda geral por ano e seleção do ano do agendamento
97
Figura 70 – Agendamentos do dia listados na agenda geral
Figura 71 – Lista com todos agendamentos
98
A Figura 72 demonstra a página de inclusão de um novo agendamento pela agenda
geral. O cadastro é semelhante ao existente na agenda de fisioterapeutas, porém o
administrador do portal não precisa informar necessariamente o fisioterapeuta do
atendimento, apenas o paciente, podendo escolher um dos status disponíveis para o
agendamento. Caso seja selecionada a forma de confirmação “Confirmado pela Clínica”, faz-
se necessário informar o fisioterapeuta do atendimento.
Os modelos dos e-mails de confirmação, rejeição e cancelamento dos agendamentos
realizados pela agenda geral são idênticos aos da agenda de fisioterapeutas, estando descritos
no Apêndice B.
Figura 72 – Página de inclusão de um novo agendamento pela agenda geral
99
Figura 73 – Página de alteração de um agendamento pela agenda geral
Figura 74 – Consulta de um agendamento cancelado por meio da agenda geral
100
Figura 75 – Consulta de um agendamento rejeitado pela clínica por meio da agenda geral
Figura 76 – Consulta de um agendamento confirmado pela clínica por meio da agenda geral
101
As páginas disponíveis para um profissional da clínica sem o perfil de administrador
do portal são idênticas às apresentadas até então, exceto pela possibilidade de acesso à aba de
administração e seus Portlets, e às opções de customização do portal, como adicionar páginas
ou editar preferências dos Portlets. Portanto as telas de um profissional da clínica não serão
detalhadas neste trabalho.
3.4.2 Módulo do paciente
Ao digitar o endereço do SAGCC, o paciente é direcionado para a página principal do
portal apresentada na Figura 77. Caso o paciente não seja um usuário do portal, o mesmo
poderá realizar seu cadastro através do Portlet disponível na página de apresentação,
informando um usuário e senha. Para isso, o paciente deverá clicar no link indicado na Figura
74.
Figura 77 – Página de apresentação do portal
A tela de cadastramento do paciente pela página de apresentação é demonstrada na
Figura 78.
102
Figura 78 – Cadastro de paciente pela página de apresentação do portal
A página de confirmação exibida ao visitante após o cadastramento é apresentada na
Figura 79.
Figura 79 – Confirmação de cadastro de paciente pela página de apresentação do portal
Após o cadastramento, ou caso já possua um usuário e senha pré-definidos no banco de
103
dados do portal, o paciente poderá acessar o sistema clicando na aba “Acesso”. A Figura 80
ilustra um usuário com perfil de paciente acessando o SAGCC.
Figura 80 – Acesso ao sistema pelo paciente
Após efetuar o login informando o nome de usuário e senha, o paciente tem acesso ao
Portlet de alteração de seu cadastro, delimitado na página “Meu Cadastro” ilustrada na Figura
81, assim como o Portlet de agenda do paciente acessível pela aba “Minha Agenda”.
Figura 81 – Página de alteração do cadastro do paciente
O Portlet da agenda do paciente irá considerar apenas agendamentos realizados para o
104
usuário que está acessando o portal. O comportamento das outras páginas da agenda do
paciente é singular ao descrito para o acesso do administrador do portal, demonstrado na
seção 3.4.1.
Figura 82 – Visão da agenda do paciente por mês
Figura 83 – Seleção do mês e ano do agendamento da agenda do paciente
105
Figura 84 – Visão da agenda do paciente por ano
Figura 85 – Agendamentos do dia do paciente
106
Figura 86 – Lista com todos agendamentos do paciente
Figura 87 – Página de inclusão de um novo agendamento pela agenda do paciente
O e-mail de notificação de um agendamento novo, alterado ou cancelado pela agenda
107
do paciente é apresentado no Apêndice B.
Figura 88 – Página de alteração de um agendamento pela agenda do paciente
Figura 89 – Consulta de um agendamento cancelado por meio da agenda do paciente
108
Figura 90 – Consulta de um agendamento rejeitado pela clínica por meio da agenda do paciente
Figura 91 – Consulta de um agendamento confirmado pela clínica por meio da agenda do paciente
109
3.5 RESULTADOS E DISCUSSÃO
No decorrer da fase inicial do trabalho houve uma grande preocupação em relação ao
tempo disponível para o desenvolvimento da aplicação, devido à quantidade considerável de
tecnologias utilizadas. Dentre estas tecnologias destacam-se a EJB 3.0 (Enterprise JavaBeans
3.0), JPA (Java Persistence API), Hibernate, JSF (JavaServer Faces), Portlets e o portal
Liferay, além das ferramentas utilizadas tanto na fase de análise como na implementação.
Para a utilização de temas e estilos do portal, por exemplo, assim como para o
gerenciamento de usuários e permissões, foi necessário estudar detalhes do funcionamento da
API do portal Liferay.
A base de dados do portal foi migrada para utilizar o banco MySQL, a fim de que o
SAGCC e o portal Liferay utilizassem o mesmo SGBD, unificando e facilitando o
gerenciamento dos dados da aplicação.
As customizações realizadas no coração do Liferay, como por exemplo, desabilitar
Portlets não utilizados pelo SAGCC visando o aumento de desempenho do sistema, foram
efetuadas por meio do ambiente extensível (EXT), assim como recomendado na
documentação do portal. O ambiente extensível disponibiliza o código fonte do Liferay, a
partir de onde é possível alterar as classes e configurações de infra-estrutura do portal.
Alterações feitas utilizando este ambiente permitem que atualizações futuras do portal possam
ser realizadas sem a necessidade de se preocupar com revisões nos fontes para garantir a
compatibilidade entre novas versões.
Antes de iniciar a utilização destas tecnologias foi necessário estudar os padrões MVC
e DAO, a fim de definir a modelagem da arquitetura do sistema.
Uma grande dificuldade encontrada após o estudo dos padrões e tecnologias, foi fazer
com que estas funcionassem em conjunto. O portal Liferay em sua versão corporativa, por
exemplo, possui o servidor JBoss integrado, porém este não contém um containter EJB 3.0
embutido, que é um recurso necessário para realizar o gerenciamento (deploy) de EJBs 3.0.
Foi necessário instalar e configurar no JBoss o container EJB 3.0 separadamente.
Ocorreram outros problemas após a instalação do container, como o estouro da
memória reservada para os objetos da Java Virtual Machine (JVM), em decorrência da
execução de ciclos consecutivos de alteração e gerenciamento da aplicação (hot-deploy). Para
corrigir este problema, fez-se necessário configurar a JVM e criar tarefas exclusivas
utilizando a tecnologia Ant, a fim de limpar o cache de JSPs mantido pelo JBoss que
110
originava o problema.
Outra situação identificada foi a incompatibilidade de horários entre o JBoss e o portal
Liferay. Ao inserir e recuperar valores de dada/hora na base de dados, mesmo configurando
programaticamente o fuso horário de Brasília na JVM, os objetos que guardavam a
informação de data/hora dos agendamentos se comportavam de forma inesperada,
adicionando ou subtraindo horas ao valor original persistido na base de dados.
O estudo dos padrões, ferramentas, tecnologias, e os métodos e recursos utilizados para
que estas se comunicassem, consumiram uma grande parcela do tempo destinado ao
desenvolvimento do trabalho.
O estudo realizado na fundamentação teórica demonstrou-se de suma importância na
fase de modelagem da aplicação, em especial os estudos realizados sobre os padrões de
projeto MVC e DAO. O conhecimento destes padrões foi um requisito essencial para garantir
a utilização e a comunicação efetiva entre as diferentes tecnologias.
A implementação do SAGCC foi totalmente baseada no diagrama de classes definido
previamente na fase de especificação. Esse foi um fator muito importante, pois possibilitou
prever problemas que poderiam ocorrer durante a fase de desenvolvimento. Houveram poucos
casos durante o desenvolvimento que levaram à alteração da especificação, não representando
muito esforço em modificar a modelagem.
Ao se comparar a aplicação desenvolvida com os sistemas destinados ao agendamento
de consultas clínicas disponíveis no mercado, nota-se que a mesma apresenta uma
característica não encontrada nas demais: a utilização de um portal corporativo e da
tecnologia de Portlets como meio de disponibilizar serviços de agendamento e gerenciamento
de consultas. A preocupação em utilizar padrões de projeto e tecnologias Java também é
perceptível no trabalho correlato de Siqueira (2004).
111
4 CONSIDERAÇÕES FINAIS
O objetivo do trabalho foi atingido, o qual consistia no desenvolvimento de uma
aplicação para automatizar o processo de agendamento, confirmação e gerenciamento de
consultas clínicas on-line, através de um portal corporativo. O sistema foi concebido para
utilização tanto pelos profissionais de uma clínica de fisioterapia, quanto para pacientes,
conforme os requisitos levantados, tendo a função principal de permitir o agendamento e
confirmação de consultas via Internet, informando os usuários do sistema através do envio de
mensagens de notificação.
O sistema automatizou as operações de agendamento e gerenciamento de consultas
utilizando novas tecnologias, incorporando assim a extensão da informática em um processo
essencial aos profissionais e pacientes de uma clínica de fisioterapia, trazendo maior
facilidade de acesso, controle e manipulação de informações tangentes aos agendamentos.
Para o desenvolvimento do sistema foram utilizadas tecnologias, padrões e ferramentas
conceituadas no mercado de desenvolvimento de software. Algumas tecnologias como o
Servidor de aplicações Java JBoss, container WEB Tomcat, tecnologia de Portais e Portlets e
os padrões de projeto DAO e MVC foram considerados pré-requisitos para a implementação
do SAGCC.
O Liferay demonstrou ser um portal corporativo muito robusto e ao mesmo tempo
flexível, oferecendo todos os requisitos necessários para cobrir, por exemplo, a
implementação dos Portlets utilizando em conjunto a tecnologia JSF. Outra característica
positiva do Liferay foi a facilidade de customização do portal, assim como a intuitiva
interface para tratar a lógica de acesso de usuários.
A JPA e o Hibernate em conjunto com a tecnologia EJB 3.0 apresentaram
características importantes como praticidade no desenvolvimento, que contribuíram
enormemente para a produtividade, economizado código e mantendo as preocupações na
lógica do negócio que diz respeito ao agendamento e gerenciamento de consultas.
4.1 EXTENSÕES
Os objetivos específicos do trabalho foram atingidos, salvo por dois requisitos
112
funcionais e uma regra de negócio apresentados no tópico 3.1 (Requisitos Principais do
Problema a Ser Trabalhado) que não foram completamente implementados, devido ao tempo
gasto no estudo e integração das tecnologias e padrões utilizados no desenvolvimento.
Tratam-se dos RF05 e RF14, assim como a RN04. O aspecto do RF05 não implementado no
SAGCC foi o envio de mensagens de confirmação por SMS, abrangendo também o escopo da
RN04. A característica não realizada do RF14 foi a disponibilidade de visualização das
agendas por semana e mês.
As sugestões para trabalhos futuros incluem a implementação de uma interface rica
com o usuário, incorporação das visões das agendas por semana e mês, implementação da
forma de confirmação por SMS, criação de relatórios assim como novos módulos para o
portal.
Se comparado à HTML pura, a tecnologia de Portlets trás para o SAGCC uma maior
proximidade das aplicações desktop tradicionais, enquanto ao maior grau de iteração e
personalização. A interface do sistema pode ser melhorada ainda mais para possibilitar uma
experiência contínua ao usuário enquanto à utilização dos componentes gráficos, trazendo
recursos como arrastar e soltar, ou autocomplete de textos, por exemplo. Estas características
poderiam ser implementadas utilizando tecnologias como o Asynchronous Javascript And
XML (AJAX).
As visões das agendas por semana e mês podem ser implementadas com base na lógica
das demais visões já existentes no SAGCC. Melhorando a interface do sistema conforme
sugerido, estas visões poderiam assumir um aspecto mais usual, indicando dinamicamente os
agendamentos realizados em um determinado dia assim como seus dados, sem a necessidade
de submeter a página HTML inteira. Outra melhoria na interface seria a distinção dos dias em
que existem consultas agendadas por cores nas diferentes visões da agenda. O Sistema
poderia ainda sugerir dias e horários para realização de um novo agendamento.
A forma de confirmação de agendamento por SMS pode ser implementada no sistema
sem haver necessidade de alterar o modo que as tecnologias e padrões foram utilizados.
Outras formas de confirmação podem ainda ser incorporadas, aumentando a flexibilidade do
sistema em relação às notificações de agendamentos.
Para extração de informações gerenciais, poderiam ser desenvolvidos relatórios
relacionando os agendamentos por paciente, fisioterapeuta, ou o número de atendimentos
realizados por convênio.
Por ter sido construído com base em uma arquitetura flexível, o SAGCC pode ser visto
como um módulo de um sistema completo para uma clínica de fisioterapia. Para tanto, fica a
113
possibilidade de desenvolver outros módulos do portal corporativo da clínica, como o
gerenciamento de prontuários clínicos do paciente, por exemplo.
114
REFERÊNCIAS BIBLIOGRÁFICAS
BAUER, Christian; KING, Gavin. Java Persistence with Hibernate: Revised edition of Hibernate in Action. New York: Manning Publications, 2007. 822 p.
BEZZERA, Eduardo. Princípios da análise e projeto de sistemas com UML. Rio de Janeiro: Campus, 2003. 286 p.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML, guia do usuário. Rio de Janeiro: Campus, 2000. 472 p.
BURKE, Bill; MONSON, Richard. Enterprise JavaBeans 3.0. Santa Clara: O'reilly Media, 2006. 760 p.
CARVALHO JUNIOR, Paulo Marcondes. Modelo de uso da tecnologia de informação no suporte ao processo de ensino-aprendizagem baseado em problemas no curso médico: desenvolvimento e avaliação. 2002. 235 f. Tese (Doutorado - Engenharia Elétrica e Computação) Departamento de Engenharia Biomédica, Universidade Estadual de Campinas, Campinas, 2002. Disponível em: <http://libdigi.unicamp.br/document/?code=vtls000242814>. Acesso em: Apr. 2007.
COLLINS, Daniel. Data warehouses, enterprise information portal, and the SmartMart meta directory. Information Builders Systems Journal, New York, v. 12, n. 2, p.53-61, 01 abr. 1999.
COSTA, Claudio Giulliano Alves da. Desenvolvimento e avaliação tecnológica de um sistema de prontuário eletrônico do paciente, baseado nos paradigmas da World Wide Web e da engenharia de software. 2001. 268 f. Dissertação (Mestrado - Engenharia Elétrica e de Computação) Universidade Estadual de Campinas, Campinas, 2001. Disponível em: <http://libdigi.unicamp.br/document/?code=vtls000231024>. Acesso em: Apr. 2007.
DARVES, B. A saúde on-line. Bibliomed, Belo Horizonte, n. 1962, p.1-20, 01 jun. 2001. Disponível em: <http://www.bibliomed.com.br/lib/showdoc.cfm?LibCatID=-1&Search=saude%20online&LibDocID=137>. Acesso em: Maio 2007.
DIAS, Cláudia Augusto. Portal corporativo: conceitos e características. Brasília: ISSN, 2001. 30 v. Disponível em: <http://www.scielo.br/scielo.php?script=sci_abstract&pid=S0100-19652001000100007&lng=pt&nrm=iso&tlng=pt>. Acesso em: Maio 2007.
DOEDERLEIN, Osvaldo Pinali. Persistência Turbinada: DAOs otimizados, Caching e JDBC Avançado. Java Magazine, Rio de Janeiro, n. 25, p. 28-41, Jun. 2005.
FAERMAN, Julio. JavaServer Faces na Prática. Java Magazine, Rio de Janeiro, n. 22, p. 58-66, Mar. 2004.
115
FAERMAN, Julio. Design Patterns Aplicados. Java Magazine, Rio de Janeiro, n. 20, p. 52-58, Jan. 2005.
FISIOTERAPIA. Definição e áreas de atuação, [2007a]. Disponível em: <http://www.fisioterapia.com.br/fisioterapia.asp>. Acesso em: Maio 2007.
______. Desenvolvendo ações para o crescimento da Fisioterapia, [2007b]. Disponível em: <http://www.fisioterapia.com.br>. Acesso em: Maio 2007.
LARMAN, Graig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos. Porto Alegre: Bookman, 1999. 493 p.
LEME, Felipe. Servlets Parte 1: conceitos e técnicas básicas. Java Magazine, Rio de Janeiro, n. 18, p. 32-42, Nov. 2004.
LIFERAY. Downloads, [2007a]. Disponível em: <http://www.liferay.com/web/guest/products/portal#Optimize%20existing%20IT%20investments>. Acesso em: Maio 2007.
______. Key business benefits, [2007b]. Disponível em: <http://www.liferay.com/web/guest/products/portal#Optimize%20existing%20IT%20investments>. Acesso em: Maio 2007.
______. Liferay, [2007c]. Disponível em: <http://www.liferay.com/>. Acesso em: Maio 2007.
LIFERAYPEDIA. LiferayPedia, [2007]. Disponível em: <http://wiki.liferay.com/>. Acesso em: Maio 2007.
LOZANO, Fernando. Aplicações WEB no Tomcat 5 Parte 1: primeiros passos no desenvolvimento JSP. Java Magazine, Rio de Janeiro, n. 18, p. 20-31, Nov. 2004.
PIRES, Waldir. Entendendo o Java Community Process (JCP). Mundo Java, Curitiba, n. 18, p.13-20, Set. 2006.
PORTALFISIOTERAPIA. O universo da Fisioterapia na Internet, [2007]. Disponível em: <http://www.portalfisioterapia.com.br>. Acesso em: Maio 2007.
RECKON ENGENHARIA DE SISTEMAS (Org.). Sistema de Agendamento Reckon, [2006]. Disponível em: <http://www.reckon.com.br/Agendamento_de_Consultas>. Acesso em: Abr. 2007.
REYNOLDS, Hadley; KOULOPOULOS, Tom. Enterprise knowledge has a face. Intelligent Enterprise, New York, v. 2, n. 5, p.29-34, 30 fev. 1999. Disponível em: <http://www.intelligententerprise.com/db_area/archives/1999/993003/feat1.jhtml;jsessionid=IWJCJT5QJQFVIQSNDLQSKH0CJUNN2JVN>. Acesso em: Maio 2007.
116
ROCHA, Andre Dantas; KUBOTA, Sergio Oliveira. Persistência no Java: iniciando com a Java Persistence API. Java Magazine, Rio de Janeiro, n. 39, p. 28-37, Fev. 2007.
RODRIGUES, Denise Munari et al. Saúde intermediada. Disponível em: <http://www.virtual.epm.br/material/tis/curr-med/temas/med5/med5t32000/grupo5/apresent.htm>. Acesso em: Maio 2007.
SABBATINI, Renato Marcos Endrizzi. Porque usar a informática? Informática Médica, Campinas, v. 2, n. 1, 1999. Disponível em: <http://www.informaticamedica.org.br/informaticamedica/n0201/editorial.htm/>. Acesso em: Apr. 2007.
SABBATINI, Renato Marcos Endrizzi. Introdução à microinformática para usuário em saúde. São Paulo: Academia de Ciências de São Paulo, 1982.
SANTOS, Alexandre Denes Dos. Portlets na Prática. Java Magazine, Rio de Janeiro, n. 25, p. 54-61, Jun. 2005.
SHORTLIFFE, E.H; BLOIS, M.S. The computer meets medicine and biology: emergence of a discipline. 2. ed. New York: Springer, 2001.
SIGULEM, Daniel. Um novo paradigma de aprendizado na prática médica da UNIFESP/EPM. 1997. 1 f. Tese (Mestrado - Livre- Docência, Departamento de Centro de Informática em Saúde) CIS-EPM, São Paulo, 1997. Cap. 1. Disponível em: <http://www.virtual.epm.br/material/tis/curr-med/infosaude/index.htm>. Acesso em: Maio 2007.
SIQUEIRA, Sandra Regina Cardoso. Sistema de Agendamento Universal. In: CONGRESSO BRASILEIRO DE INFORMÁTICA EM SAÚDE, 9., 2004, Ribeirão Preto. IX Congresso Brasileiro de Informática em Saúde. Ribeirão Preto: Atech/vidatis Sistemas de Informação em Saúde, 2004. p. 1 - 6. Disponível em: <http://www.sbis.org.br/cbis9/arquivos/862.doc>. Acesso em: Abr. 2007.
UNIIFMU-FISIOTERAPIA: revista de fisioterapia do centro universitário do UniFMU. São Paulo: ISNN, n. 2, 01 jun. 2003. Semestral. Disponível em: <http://www.fmu.br/pdf/edi_04_fisio_i_n.2.pdf>. Acesso em: Maio 2007.
VIEIRA, Ana Cristina Trench et al. Informática em saúde, [2000]. Trabalho das turmas do 3º e 5º ano do curso de medicina da UNIFESP. Disponível em: <http://www.virtual.epm.br/material/tis/curr-med/temas/med5/med5t32000/grupo3/grupoiii.htm>. Acesso em: Abr. 2007.
117
APÊNDICE A – Definição das principais classes
A seguir são apresentados os atributos e métodos dos principais tipos de classes da aplicação.
Primeiramente é demonstrado um exemplo para cada tipo de classe mais relevante do módulo
WEB, e posteriormente do módulo EJB. Abaixo um exemplo de uma classe que representa
um Portlet de agendamento para fisioterapeutas.
Métodos da classe “br.com.sagcc.portlets.AgendaFisioterapeutasPortlet”
Método Detalhes
public processAction( ActionResponse response, ActionRequest request):void
Notas: Método padrão da API de Portlets. É responsável por processar uma ação executada em um Portlet.
public render( RenderResponse response, RenderRequest request):void
Notas: Método padrão da API de Portlets. É responsável por renderizar o Portlet.
private renderEdit( RenderResponse response, RenderRequest request):void
Notas: Método padrão da API de Portlets. É responsável por renderizar o estado de Edição de um Portlet.
private renderHelp( RenderResponse response, RenderRequest request):void
Notas: Método padrão da API de Portlets. É responsável por renderizar o estado de Ajuda de um Portlet.
private renderView( RenderResponse response, RenderRequest request):void
Notas: Método padrão da API de Portlets. É responsável por renderizar o estado de Visão de um Portlet.
Abaixo definição da classe responsável por realizar o processamento de controle do Portlet da
Agenda Geral.
Atributos da classe “br.com.sagcc.control.AgendaGeralControl”
118
Atributo Detalhes
private String ano
Notas: Ano selecionado no formulário de visão da Agenda por mês e ano
private String anoAgendamento
Notas: Ano do Agendamento
private List anosFormularioCadastro
Notas: Lista contendo o número dos anos para popular o combo de ano
private String cgcCpfFisioterapeuta
Notas: Atributo utilizado na consulta do Fisioterapeuta do Agendamento
private String cgcCpfPaciente
Notas: Atributo utilizado na consulta do Paciente do Agendamento
private InicialContext ctx
Notas: Contexto JNDI para o lookup dos EJBs
private boolean desabilitaBtnCancelar
Notas: Flag para desabilitar o botão de cancelamento de Agendamentos do form de alteração
private boolean desabilitaCamposTela
Notas: Flag para desabilitar todos os campos do form de alteração de Agendamentos, excluindo o botão de cancelamento e os botões de consulta
private String descricaoPatologia
Notas: Descrição da patologia do Agendamento
private String diaAgendamento
Notas: Dia do Agendamento
private String diaConsulta
Notas: Dia a ser passado como parâmetro para localizar os Agendamentos de um determinado dia Este valor é configurado na jsp geralAgendaCalendario.jsp
private List diasFormularioCadastro
Notas: Lista contendo o número dos dias do mês para popular o combo de dia
private final int EMAIL_CANCELAR_AGENDAMENTO
Inicial: 3 Notas: Tipo de E-mail de Notificação para
Cancelamento de Agendamento
private final int EMAIL_CONFIRMAR_AGENDAMENTO
Inicial: 1 Notas: Tipo de E-mail de Notificação para
Confirmação de Agendamento
private final int EMAIL_REJEITAR_AGENDAMENTO
Inicial: 2 Notas: Tipo de E-mail de Notificação para Rejeição
de Agendamento
private String formaConfirmacaoEmail
Notas: Forma de confirmação por e-mail do Agendamento
private String formaConfirmacaoSMS
Notas: Forma de confirmação por SMS do Agendamento
119
private String formaConfirmacaoTelefone
Notas: Forma de confirmação por telefone do Agendamento
private String horaAgendamento
Notas: Hora do Agendamento
private String idAgendamentoAlterar
Notas: Id do Agendamento a ser alterado a partir da JSP geralAgendamentosDia
private String idSituacaoAgendamento
Notas: Situação do Agendamento
private List listaAgendamentosDia
Notas: ArrayList com os Agendamentos de um determinado dia
private List listaAgendamentosGeral
Notas: ArrayList com todos os Agendamentos
private List listaDiasMesAbril
Notas: Lista do mês de Abril do ano para montar a visão do Calendário por Ano
private List listaDiasMesAgenda
Notas: ArrayList com os dias do mês de um determinado dia da semana
private List listaDiasMesAgosto
Notas: Lista do mês de Agosto do ano para montar a visão do Calendário por Ano
private List listaDiasMesDezembro
Notas: Lista do mês de Dezembro do ano para montar a visão do Calendário por Ano
private List listaDiasMesFevereiro
Notas: Lista do mês de Fevereiro do ano para montar a visão do Calendário por Ano
private List listaDiasMesJaneiro
Notas: Lista do mês de Janeiro do ano para montar a visão do Calendário por Ano
private List listaDiasMesJulho
Notas: Lista do mês de Julho do ano para montar a visão do Calendário por Ano
private List listaDiasMesJunho
Notas: Lista do mês de Junho do ano para montar a visão do Calendário por Ano
private List listaDiasMesMaio
Notas: Lista do mês de Maio do ano para montar a visão do Calendário por Ano
private List listaDiasMesMarco
Notas: Lista do mês de Março do ano para montar a visão do Calendário por Ano
private List listaDiasMesNovembro
Notas: Lista do mês de Novembro do ano para montar a visão do Calendário por Ano
private List listaDiasMesOutubro
Notas: Lista do mês de Outubro do ano para montar a visão do Calendário por Ano
private List listaDiasMesSetembro
Notas: Lista do mês de Setembro do ano para montar a visão do Calendário por Ano
private String mes
Notas: Mês selecionado no formulário de visão da Agenda por mês e ano
120
private String mesAgendamento
Notas: Mês do Agendamento
private String mesConsulta
Notas: Mês a ser passado como parâmetro para localizar os Agendamentos de um determinado dia Este valor é configurado na jsp geralAgendaCalendarioAno.jsp
private List mesesFormularioCadastro
Notas: Lista contendo o nome dos mêses do ano para popular o combo de mês
private String minutoAgendamento
Notas: Minuto do Agendamento
private String nomeFisioterapeuta
Notas: Atributo utilizado na consulta Geral do Agendamento
private String nomePaciente
Notas: Atributo utilizado na consulta Geral do Agendamento
private boolean primeiraRenderizacaoAgenda
Notas: Flag indicando se é a primeira vez que a Agenda será renderizada Se for a primeira vez, o método montaVisaoMes() é invocado dentro da JSP geralAgendaCalendario a fim de montar o calendário de mês
private String tituloAgendamento
Notas: Título do Agendamento
Métodos da classe “br.com.sagcc.control.AgendaGeralControl”
Método Detalhes
public AgendaGeralControl():
Notas: Construtor padrão do Controlador. Responsável por invocar o método open()
public alterar():String
Notas: Atualiza objetos do tipo Agendamento @return String informando à camada de visão qual JSP deverá ser renderizada
public cancelar():String
Notas: Cancela um Agendamento e desabilita os campos do form para edição @return String informando à camada de visão qual JSP deverá ser renderizada
private enviarEmailNotificacaoAgendamento( int tipoEmail,
121
Agendamento agendamento):void Notas: Método responsável por enviar um e-mail de notificação ao Paciente do Agendamento quando realizarem a confirmação, rejeição ou cancelamento de um Agendamento de acordo com o tipoEmail informado
protected finalize():void
Notas: Seta o contexto JNDI para nulo quando o objeto é retirado da memória.
public getAnosFormularioCadastro():List
Notas: Popula valores do ComboBox de Anos do Form da Agenda Geral
public getDiasFormularioCadastro():List
Notas: Popula valores do ComboBox de Dias do Form da Agenda Geral
public getMesesFormularioCadastro():List
Notas: Popula valores do ComboBox de Mêses do Form da Agenda Geral
private limparCampos():void
Notas: Limpa todos os atributos do Controlador mapeados para os campos da JSP
public localizar():String
Notas: Localiza os Agendamentos de um dia @return String informando à camada de visão qual JSP deverá ser renderizada
public localizarListener( ActionEvent actionEvent):void
Notas: Listner utilizado para receber o dia que o usuário selecionou na página geralAgendaCalendario.jsp
public localizarTodos():String
Notas: Localiza todos os Agendamentos @return String informando à camada de visão qual JSP deverá ser renderizada
public montarVisaoAno():String
Notas: Cria doze calendários por ano, um para cada mês, a partir do ano selecionado pelo usuário no Form
public montarVisaoMes():String
Notas: Cria um calendário por mês a partir do mês
122
selecionado pelo usuário no Form
private open():void
Notas: Recupera o contexto JNDI para realizar posteriormente o lookup dos EJBs
public salvar():String
Notas: Torna persistente um objeto do tipo Agendamento Se o método salvar() for chamado a partir do form de alteração, configura o id do Agendamento para que seja feito o update Senão, será criado um novo agendamento (insert) @return String informando à camada de visão qual JSP deverá ser renderizada
public selecionaAnoAgendamento( ValueChangeEvent event):void
Notas: Listner para o evento de seleção do Ano no formulário de Cadastro do Agendamento Geral
public selecionaAnoCalendarioAno( ValueChangeEvent event):void
Notas: Listner para o evento de seleção do Ano no formulário de visão da Agenda por Ano
public selecionaAnoCalendarioMes( ValueChangeEvent event):void
Notas: Listner para o evento de seleção do Ano no formulário de visão da Agenda por Mês
public selecionaMesAgendamento( ValueChangeEvent event):void
Notas: Listner para o evento de seleção do Mês no formulário de Cadastro do Agendamento Geral
public selecionaMesCalendarioMes( ValueChangeEvent event):void
Notas: Listner para o evento de seleção do Mês no formulário de visão da Agenda por Mês
Abaixo definição da classe que representa um validator invocado para validar informações
digitadas no formulário de Cadastro de Pacientes.
Métodos da classe “br.com.sagcc.validator.PacientesValidator”
Método Detalhes
123
public validaFormPaciente( Object value, UIComponent componet, FacesContext context):void
Notas: Valida dados digitados no Form de Cadastro de Pacientes => Valida se o cgcCpf digitado no Formulário é um número válido; Se for um número válido, verifica se já existe um registro na base de dados com o mesmo CGC/CPF =>Valida o e-mail digitado pelo usuário =>Valida formato da Data de Nascimento digitada pelo usuário
Definição da classe que representa um Servlet utilizado na LOV de consulta de Pacientes do
Agendamento.
Atributos da classe “br.com.sagcc.servlet.AgendaPacientesServlet”
Atributo Detalhes
private InicialContext ctx
Inicial: null Notas: Contexto para o lookup dos EJBs
Métodos da classe “br.com.sagcc.servlet.AgendaPacientesServlet”
Método Detalhes
public AgendaPacientesServlet():
Notas: Construtor padrão sem argumentos
public destroy():
protected finalize():void
public init( ServletConfig config):
Notas: Processamento inicial do Servlet Recupera o contexto JNDI para realizar posteriormente o lookup dos EJBs
private listarPacientes( HttpServletResponse response, HttpServletRequest request):void
protected service( HttpServletResponse response, HttpServletRequest request):void
124
Definição da classe utilizada para o envio de mensagens de e-mail, através do protocolo
SMTP.
Atributos da classe “br.com.sagcc.util.mail.EnviadorDeEmail”
Atributo Detalhes
private static String EMAIL_REMETENTE
Inicial: enviador.email.remetente
private static String NOME_REMETENTE
Inicial: enviador.nome.remetente
private static String PORTA_SMTP
Inicial: enviador.porta.smtp
private static String SENHA_REMETENTE
Inicial: enviador.senha.smtp
private static String SERVIDOR_SMTP
Inicial: enviador.servidor.remetente
private static String SSL_FACTORY
Inicial: enviador.ssl.factory Notas: Provê um socket para conexões autenticadas por
SSL
Métodos da classe “br.com.sagcc.util.mail.EnviadorDeEmail”
Método Detalhes
private adicionarConteudoEAnexo( String arquivo, String destinatario, String conteudo, Message mensagem):void
private criarMensagem( Pessoa destinatario, String assunto, Session session):Message
private criarMensagem( UsuarioNotificacao destinatario, String assunto, Session session):Message
public enviarEmail( boolean requerAutenticacaoSMTP, String assunto, Pessoa... destinatarios, String conteudo, String arquivo):void
125
public enviarEmail( boolean requerAutenticacaoSMTP, String assunto, UsuarioNotificacao... destinatarios, String conteudo, String arquivo):void
private obterSessao():Session
A diante são descritas as definições dos principais tipos de classes e interfaces do módulo
EJB. A figura abaixo demonstra a definição de uma interface implementada por todos DAOs
de negócio. Operações CRUD (create, read, update e delete) básicas dos DAOs são isoladas
nesta interface, e compartilhadas através de todas as implementações dos DAOs.
Métodos da interface “br.com.sagcc.dao.interfaces.GenericDAO”
Método Detalhes
package abstract buscaPorExemplo( String... propiedadeExcludente, T exemploDeInstancia):List
package abstract buscaPorId( boolean lock, ID id):T
package abstract buscarTodos():List
package abstract tornaPersistente( T entidade):T
package abstract tornaTransiente( ID id):void
A interface abaixo encapsula operações DAO de negócio referentes à entidade Agendamento.
Métodos da interface “br.com.sagcc.dao.interfaces.AgendamentoDAO”
Método Detalhes
package abstract buscaAgendamentosDia( Date dia):List
126
package abstract buscaAgendamentosDia( Pessoa pessoa, Date dia):List
package abstract buscaAgendamentosPeriodo( Date dataFinal, Date dataInicial):List
package abstract buscaAgendamentosPeriodo( Pessoa pessoa, Date dataFinal, Date dataInicial):List
package abstract buscaAgendamentosPessoa( Pessoa pessoa):List
package abstract buscarTodos():List
A classe abaixo implementa as operações genéricas CRUD dos DAOs utilizando a JPA e o
Hibernate. Os DAOs herdam desta classe, e parametrizam outros métodos específicos, se for
necessário.
Atributos da classe “br.com.sagcc.dao.ejb.GenericEJBDAO”
Atributo Detalhes
private EntityManager em
Notas: Se este DAO estiver gerenciado pelo JBoss por exemplo, o container irá injetar o correto contexto de persistência se um método deste DAO for chamado. Se o invocador for um componente conversasional statefull (Statefull SessionBean), o contexto de persistencia será ajustado para o escopo da conversação, não para o escopo da chamada do método. (no caso de EJBs stateless)
private Class tipoEntityBean
Notas: Representa a Entidade da superclasse genérica. O atributo tipoEntityBean deve ser atribuído automaticamente na chamada no Construtor da classe GenericEJBDAO.
Métodos da classe “br.com.sagcc.dao.ejb.GenericEJBDAO”
Método Detalhes
protected buscaPorCriteria( Criterion... criterio):List
127
public buscaPorExemplo( String... excludeProperty, T exampleInstance):List
public buscaPorId( boolean lock, ID id):T
public buscarTodos():List
public clear():void
Notas: Deve executar uma chamada do método "clear()" sobre a EntityManager a fim de "limpa-la"
public flush():void
Notas: Deve executar uma chamada do método "flush()" sobre a EntityManager afim de "descarrega-la"
public GenericEJBDAO():void
Notas: O atributo tipoEntityBean deve ser atribuído automaticamente na chamada no Construtor da classe GenericEJBDAO.
protected getEntityManager():EntityManager
Notas: Se este DAO estiver gerenciado pelo JBoss por exemplo, o container irá injetar o correto contexto de persistência se um método deste DAO for chamado. Se o invocador for um componente conversasional statefull (Statefull SessionBean), o contexto de persistencia será ajustado para o escopo da conversação, não para o escopo da chamada do método. Este método pode ser chamado para setar o EntityManager manualmente, em um teste de integração por exemplo.
public getTipoEntityBean():Class
public setEntityManager( EntityManager em):void
Notas: Implementado apenas para utilização em testes, visto que o PersistenceContext gerencia automaticamente as transações atravéz de injeção de depenência, quando é utilizado um container EJB.
public tornaPersistente( T entity):T
public tornaTransiente( ID id):void
128
Implementação EJB 3.0 (stateless) da interface “PacienteDAO” relacionada à operações não
CRUD. Operações CRUD já estão implementadas na superclasse “GenericEJBDAO”.
Métodos da classe “br.com.sagcc.dao.ejb. PacienteDAOBean”
Método Detalhes
public buscaPacientePorCriterio( String cidade, String email, String nome, String cgcCpf):List
Notas: Método responsável por buscar Pacientes utilizando a cláusula 'like', a fim de restringir a consulta aos parâmetros passados no método.
129
APÊNDICE B – E-mails de notificação
Abaixo são apresentados os modelos dos e-mails de notificação enviados pela aplicação. Os
valores delimitados pelas chaves são parâmetros que o SAGCC insere dinamicamente ao
HTML, antes de enviar o correio para o(s) destinatário(s).
Modelo do e-mail de notificação de um novo agendamento realizado pela agenda de
pacientes.
Caro(a), Você está cadastrado(a) em nosso sistema e esta é uma mensagem para informar a inclusão de um novo Agendamento por um Paciente. Dados do novo Agendamento: Nome do Paciente: {0} E-mail do Paciente: {1} Data do Agendamento: {2} Título do Agendamento: {3} Descrição da Patologia: {4} Situação do Agendamento: {8} Forma(s) de confirmação: {5} {6} {7} Pedimos a gentileza de analisar no Portal da Clínica o Agendamento efetuado pelo Paciente a fim de enviar um parecer. Se você não quer mais receber nossos e-mails de notificação, por favor escreva para {9} solicitando descadastramento.
130
Cordialmente, Portal Clínica Nova Físio
Modelo do e-mail de notificação de um agendamento alterado pela agenda de pacientes.
Caro(a), Você está cadastrado(a) em nosso sistema e esta é uma mensagem para informar a alteração de Agendamento por um Paciente. Dados Agendamento Alterado: Nome do Paciente: {0} E-mail do Paciente: {1} Data do Agendamento: {2} Título do Agendamento: {3} Descrição da Patologia: {4} Situação do Agendamento: {8} Forma(s) de confirmação: {5} {6} {7} Pedimos a gentileza de analisar no Portal da Clínica o Agendamento alterado pelo Paciente a fim de enviar um parecer. Se você não quer mais receber nossos e-mails de notificação, por favor escreva para {9} solicitando descadastramento. Cordialmente, Portal Clínica Nova Físio
131
Modelo do e-mail de notificação de um agendamento cancelado pela agenda de pacientes.
Caro(a), Você está cadastrado(a) em nosso sistema e esta é uma mensagem para informar o cancelamento de um Agendamento por um Paciente. Dados do Agendamento cancelado: Nome do Paciente: {0} E-mail do Paciente: {1} Data do Agendamento: {2} Título do Agendamento: {3} Descrição da Patologia: {4} Situação do Agendamento: {8} Forma(s) de confirmação: {5} {6} {7} Pedimos a gentileza de analisar no Portal da Clínica o Agendamento cancelado pelo Paciente. Se você não quer mais receber nossos e-mails de notificação, por favor escreva para {9} solicitando descadastramento. Cordialmente, Portal Clínica Nova Físio
Modelo do e-mail de confirmação do agendamento enviado ao paciente.
Prezado(a) {0}, Você está cadastrado(a) em nosso sistema e esta é uma mensagem para informar a confirmação de um Agendamento pela Clínica.
132
Dados do Agendamento Confirmado: Nome do Paciente: {0} E-mail do Paciente: {1} Nome do Fisioterapeuta: {10} Data do Agendamento: {2} Título do Agendamento: {3} Descrição da Patologia: {4} Situação do Agendamento: {8} Forma(s) de confirmação: {5} {6} {7} Caso exista alguma dúvida, pedimos a gentileza de analisar no Portal o Agendamento confirmado pela Clínica. Caso não queira mais receber nossos e-mails de notificação, basta ao realizar um novo Agendamento não selecionar a Forma de Confirmação por E-mail. Havendo alguma dificuldade, pedimos que entre em contato diretamente com a Clínica a fim de receber os devidos esclarecimentos. Aguardamos sua presença na consulta. Muito obrigado. Cordialmente, Portal Clínica Nova Físio
Modelo do e-mail de rejeição de um agendamento enviado ao paciente.
Prezado(a) {0},
133
Você está cadastrado(a) em nosso sistema e esta é uma mensagem para informar a rejeição de um Agendamento pela Clínica. Dados do Agendamento Rejeitado: Nome do Paciente: {0} E-mail do Paciente: {1} Data do Agendamento: {2} Título do Agendamento: {3} Descrição da Patologia: {4} Situação do Agendamento: {8} Forma(s) de confirmação: {5} {6} {7} O motivo da rejeição do Agendamento pode variar. As causas mais comuns são conflitos de horários de outros Agendamentos ou falta de recursos disponíveis para atender a consulta. A Clínica ficará responsável por entrar em contato a fim de que seja acordado um novo horário e/ou dia para o Agendamento. Caso exista alguma dúvida, pedimos a gentileza de analisar no Portal o Agendamento rejeitado pela Clínica. Caso não queira mais receber nossos e-mails de notificação, basta ao realizar um novo Agendamento não selecionar a Forma de Confirmação por E-mail. Havendo alguma dificuldade, pedimos que entre em contato diretamente com a Clínica a fim de receber os devidos esclarecimentos. Agradecemos a compreensão. Cordialmente, Portal Clínica Nova Físio
Modelo do e-mail de cancelamento do agendamento enviado ao paciente.
134
Prezado(a) {0}, Você está cadastrado(a) em nosso sistema e esta é uma mensagem para informar o cancelamento de um Agendamento pela Clínica. Dados do Agendamento Cancelado: Nome do Paciente: {0} E-mail do Paciente: {1} Data do Agendamento: {2} Título do Agendamento: {3} Descrição da Patologia: {4} Situação do Agendamento: {8} Forma(s) de confirmação: {5} {6} {7} O motivo do cancelamento do Agendamento pode variar. Na maioria das vezes o cancelamento está associado à impossibilidade de presença do Paciente no dia da consulta, sendo necessário a criação de um novo agendamento em uma data futura. A Clínica ficará responsável por entrar em contato a fim de que seja acordado um novo horário e/ou dia para o Agendamento. Caso exista alguma dúvida, pedimos a gentileza de analisar no Portal o Agendamento cancelado pela Clínica. Caso não queira mais receber nossos e-mails de notificação, basta ao realizar um novo Agendamento não selecionar a Forma de Confirmação por E-mail. Havendo alguma dificuldade, pedimos que entre em contato diretamente com a Clínica a fim de receber os devidos esclarecimentos. Agradecemos a compreensão.
Cordialmente,
Portal Clínica Nova Físio
