SS

RESUMO

ABSTRACT

ABREVIATURAS
TICS- TECNOLOGIA DA INFORMAO E COMUNICAO EM SADE
SUS- SISTEMA NICO DE SADE
AOO- ANLISE ORIENTADA A OBJETOS
RIA- RICH INTERNET APPLICATIONS
HMC- HOSPITAL MUNICIPAL DE CASTANHAL
SRC- SISTEMA DE REGISTRO CLNICO
PEP- PRONTURIO ELETRNICO DO PACIENTE
SI- SISTEMA DE INFORMAO
OOAD - OBJECT-ORIENTED ANALYSIS AND DESIGN

LISTA DE FIGURAS

LISTA DE QUADROS

SUMRIO
CAPTULO 1- INTRODUO.....................................................................................3
1.1. ESTRUTURA DA DISSERTAO..................................................................6
1.2. JUSTIFICATIVA..............................................................................................6
1.2. OBJETIVOS....................................................................................................6
CAPTULO 2- REFERENCIAL TERICO..................................................................3
CAPTULO 3- TECNOLOGIAS..................................................................................3
3.1. APLICAES WEB........................................................................................6
CAPTULO 4- ANLISE E ESPECIFICAO DO SISTEMA....................................3
8

CONCLUSES...................................................................................................46

REFERNCIAS BIBLIOGRFICAS..................................................................48

CAPTULO 1- INTRODUO

A utilizao da Tecnologia da Informao e Comunicao em Sade (TICS)

cresce a cada dia. Hoje so inmeras as possibilidades, os recursos e os benefcios
que a informtica pode trazer para a rea de sade, especialmente para o mdico.
Segundo Martins (2009, p.8) a gesto das informaes do paciente uma
prtica muito antiga e essencial no acompanhamento clnico. Entretanto, com a
evoluo da medicina e da Tecnologia da informao; modificou-se a forma de
armazenamento dos dados clnicos, bem como quais informaes eram mais
relevantes a serem registradas.
Para Triana (2009) a semiologia mdica estuda atravs das anamneses,
exames clnicos, observaes, tabelas, sndromes, entre outros; os sinais e
sintomas das doenas humanas com o propsito de se estabelecer um diagnstico.
A medicina sempre buscou o uso de uma gesto eficiente dos dados da semiologia
mdica. Com o advento da informtica, mais precisamente com o surgimento da
rea sistemas da informao, foram desenvolvidos os pronturios eletrnicos do
paciente para armazenar os diagnsticos e realizar os acompanhamentos clnicos.
Portanto, a presente dissertao tem como objetivo desenvolver
uma soluo informtica para o registro clnico eletrnico do Hospital
Municipal de Urgncia e Emergncia de Castanhal (HMC), Dra. Maria Laise Pereira
Lima, utilizando ambiente web. Deste modo, a dissertao assume um carter
essencialmente tcnico, isto , mais direcionado para as questes de
desenvolvimento de software.

1.1

ESTRUTURA DA DISSERTAO

O processo de organizao da monografia inclui dividi-la em XXX

captulos chaves, alm desse captulo de informaes iniciais; cada um
contendo um tema fundamental.

No captulo 2 so abordados alguns aspectos, com base em reviso

bibliogrfica, para construo de sistemas de informao a sade (SIS).
Apresenta-se, em linhas gerais, os fundamentos conceituais associados
aos SIS, bem como, os principais fundamentos conceituais da anlise
Orientada a objetos e da Unified Modeling Language- UML- tcnicas de anlise e
modelagem de sistemas, que foram utilizadas para desenvolvimento da aplicao
para o HMC.
No captulo 3, especifica-se o contexto do cenrio do HMC. Caracteriza-se
esse local de estudo;
O Captulo 4 apresenta o conjunto de tecnologias que foram utilizadas para
tornar possvel o desenvolvimento do projeto desta dissertao. Especifica-se a
linguagem JAVA, o Sistema Gerenciador de Banco de Dados e as ferramentas
utilizadas no desenvolvimento do sistema.
O Captulo 5 explica o processo de anlise e modelagem para o
desenvolvimento de software adotado segundo a anlise Orientada a objetos. Nesse
sentido, realizada uma anlise aos requisitos da aplicao; assim como a todo o
processo de planejamento dos componentes que iro dar origem aplicao
propriamente dita. Especificou-se, tambm, nesse captulo, os diagramas de caso de
uso, diagramas de classe, diagramas de sequncia e o projeto do banco de dados.
No captulo 6 apresenta-se os layouts das telas e suas descries.
1.2

JUSTIFICATIVA
Para Costa, Alves e Martins (2010) a obteno da informao por meio

eletrnico reflete positivamente no resultado do atendimento com qualidade nas

instituies vinculadas a rea da sade, pois a dificuldade e a perda de informao
com pronturios obsoletos e pouco precisos podem causar danos irreversveis para
o profissional e para o paciente.
Sendo assim, a necessidade de armazenar dados, como: cadastros de
pacientes, ficha de anamnese- onde informado o estado de sade do paciente,
dados clnicos e agenda do mdico; passou a ser uma grande necessidade dos
centros ambulatoriais pelo Brasil.
A realidade vivenciada pelo hospital Municipal de Urgncia e Emergncia de
Castanhal, Dra. Maria Laise Pereira Lima, de ausncia de um software para

gerenciamento aos registros eletrnicos de sade. Por isso, o atual processo de

agendamento de consultas acaba sendo feito somente com a presena fsica do
usurio e o registro das informaes clinicas do paciente est vinculada a fichas de
papel.
Esse fato conduz a fatores que dificultam e causam transtornos aos usurios
do Sistema nico de Sade que se utilizam do Pronto Socorro para atendimento
clnico. Tais problemas dizem respeito: (1) elevado tempo de espera e de
atendimento dos pacientes, resultando no atendimento inadequado no registro em
papel dos dados do paciente- ficando incompleto por falta de preenchimento na ficha
de atendimento;
O Sistema de Registro Clnico (SRC) dever trazer mais praticidade para o
dia a dia dos usurios, evitando que eles tenham de se preocupar com pilhas de
arquivos, ou similar, aproveitando mais o tempo para se dedicar a tarefas mais
importantes, para assim melhorar os servios prestados pelo hospital.
Alm disso, o Sistema ir trazer maior facilidade para os funcionrios
realizarem as suas tarefas reduzindo o tempo com a procura de registros de
pacientes e proporcionar ao usurio maior praticidade na hora de efetuar os
agendamentos de consultas e exames.

1.3

OBJETIVOS

1.4.1- Objetivo Geral:

Este trabalho buscou desenvolver um sistema de informao para registro
eletrnico a sade, com a finalidade de auxiliar os trabalhos clnicos de atendimento
no Hospital Municipal de Urgncia e Emergncia de Castanhal, Dra. Maria Laise
Pereira Lima, utilizando ambiente web;
1.4.2- Objetivos Especficos:
Possibilitar melhor controle e praticidade dos agendamentos das consultas,
exames, atendimentos de urgncia e emergncia no pronto Socorro
Municipal de Castanhal, atravs de um sistema web;
Disponibilizar e agilizar a emisso de receitas, exames e laudos mdicos
atravs da impresso e gerao de pronturios eletrnicos;
Permitir a criao de histrico das receitas, exames e laudos mdicos
repassados ao paciente atravs do armazenamento em banco de dados;

CAPTULO 2- REFERENCIAL TERICO

O estudo de Sistemas de Informao em sade (SIS) est, ainda, evoluindo

no mundo e no Brasil. Desde o incio, as publicaes e pesquisas sobre os SIS
focaram a tecnologia em computao como o ponto central. Entretanto, Segundo
Giuse e Kuhn (2003), as excessivas orientaes tecnolgicas, no passado, em
detrimento da perspectiva social e do usurio, levaram a diferentes falhas nos
projetos; e, consequentemente, resultaram em fracasso na implantao do software.
Um sistema de informao (SI) na rea da sade necessita lidar com
aspectos de sobrecarga de informao, com comportamentos clnicos adversos; o
que resulta, em constantes alteraes na estrutura e comportamento do SI. O
desenvolvimento de cuidados e servios de sade um processo complexo que
envolve

diferentes

profissionais

com

diferentes

perspectivas,

diferentes

organizaes e recursos fsicos. O termo SI clnico est associado a uma

organizao de sade e constitudo por um conjunto de recursos humanos e
fsicos e por um conjunto de aplicaes de software que permitem recolher,
processar e distribuir informao clnica.
O principal propsito de um SI clnico o incremento da qualidade dos
servios de sade. Segundo Littlejohns, Wyatt e Garvican (2003) existe um conjunto
de objetivos que um SI clnico deve facultar de modo a atingir o referido propsito:

Disponibilizar informao do paciente em todas as unidades de sade,

principalmente nos hospitais centrais;

Disponibilizar ao paciente informao mdica contextualizada com o seu

perfil de sade, assim como informao sobre o seu estado clnico e
respectivo trajeto clnico;

Desenvolver mecanismos de acesso, distribuio e partilha de informao

mdica aos diferentes agentes na rea da sade.

Incrementar o desempenho dos processos administrativos das unidades de

sade, de modo a melhorar a qualidade e a monitorizao dos servios de
sade.

Padronizar os servios de gesto de pacientes e os procedimentos de gesto

em todas as unidades de sade, principalmente nos hospitais pblicos.

2.1- SISTEMA DE INFORMAO APLICADO A HOSPITAIS

utilizao

de

Sistemas

de

Informao

em

hospitais

evoluiu

significativamente, partindo de uma realidade em que os computadores eram

empregados somente para operar tarefas simples e isoladas, at a integrao global
das informaes, por intermdio de um sistema nico. Segundo Johanston (1993),
um Sistema de Informao hospitalar definido como um sistema computadorizado
que, instalado em um ambiente hospitalar, objetiva registrar informaes sobre os
pacientes de tal forma que possam ser compartilhadas por todos os setores do
hospital que delas necessitem.
A rea de abrangncia do Sistema de Informao hospitalar pode ser
subdividida em duas: rea clnica ou Assistencial e Administrativa. Segundo Sigulem
(1997), por um perodo de 30 anos (19601990), a funo primordial dos
computadores, dentro das instituies hospitalares, eram facilitar a gerao de
documentos indispensveis para o reembolso do atendimento de pacientes e, com o
passar do tempo, foi utilizado para automatizar a produo de relatrios. Hoje, os
administradores podem ter acesso aos recursos necessrios para administrao e
gerenciamento do hospital por meio da utilizao de sistemas de informao.
Os sistemas de informao hospitalares que antes tinham foco apenas
administrativo esto mudando seu foco, tornando-se clnico-administrativos,
executando entre outros servios, gerenciamento da farmcia, laboratrios, nutrio,
faturamento, ambulatrio, financeiro etc.
Dentre os sistemas aplicados gesto clnica dos hospitais est o chamado
pronturio eletrnico do paciente (PEP). Segundo Bianchini et al.(2002), o PEP pode
ser reconhecido como um sistema utilizado para informatizar o histrico do paciente.
Seu objetivo principal permitir a integrao dos sistemas departamentais. Deve
prover ao mdico informaes imediatas e de simples entendimento a respeito das

condies de sade atuais e passadas do paciente, com a finalidade de permitir uma

adequada assistncia.
De acordo com publicao do Departamento de Informtica em Sade da
Universidade Federal de So Paulo (Unifesp), o PEP armazena informaes
relacionadas com a sade da pessoa, utilizando recursos computacionais,
organizadas por um identificador nico do paciente. Essas informaes deveriam
representar todos os eventos relacionados sade do indivduo, desde o
nascimento at a morte. Pode ser entendido de uma forma clara e simples como a
transcorrncia das informaes do papel para um Sistema de Informao.

2.2- FUNDAMENTOS CONCEITUAIS

Para a anlise da problemtica do Hospital Municipal de Urgncia e

Emergncia de Castanhal; empregou-se, a metodologia de anlise orientada a
objetos com UML (ver captulo 5, pgina XXX). A modelagem do banco de dados se
baseou no Modelo Entidade Relacionamento e a arquitetura de modelagem MVC.
Por isso, faz-se necessrio, um aprofundamento conceitual dos princpios que
norteiam esses tipos de modelagens para o desenvolvimento de sistemas de
informao.

2.2.1- Anlise orientada a objetos

Atualmente, a forma mais moderna de abordagem no desenvolvimento de

sistemas a Anlise e Projeto Orientado a Objetos (Object-Oriented Analysis and
Design - OOAD). Rumbaugh (1994) define orientao a objetos como: "uma nova
maneira de pensar os problemas utilizando modelos organizados a partir de
conceitos do mundo real. O componente fundamental o objeto que combina
estrutura e comportamento em uma nica entidade". Dizer que um software

10

orientado a objetos significa que ele organizado como uma coleo de objetos
separados, que incorporam tanto a estrutura como o comportamento dos dados. A
Orientao a Objetos (OO) trouxe vrios novos conceitos ao desenvolvimento de
software, como: Abstrao, Encapsulamento, Objeto, Classe, Atributo, Operao,
Mtodo, Mensagem, Evento, Interface, Generalizao, Herana e Polimorfismo
(Jacobson et al., 1996; Furlan, 1998; Fuzion, 1999).
A abordagem orientada a objetos possibilita uma melhor organizao,
versatilidade e reutilizao do cdigo fonte, o que facilita atualizaes e melhorias
nos programas. Dessa forma, o enfoque OO procura analisar um sistema como uma
coletnea de objetos que interagem entre si, com caractersticas prprias,
representadas por atributos (dados) e operaes (processos). Segundo Correia e
Tafner (2006), os princpios que regem a orientao a objetos so definidos como:
a) Classe: mostra o comportamento dos objetos, atravs de mtodos, sendo
capaz de manter, atravs de atributos. Exemplo: os seres humanos;
b) Objeto: a instncia de uma classe, ou seja capaz de armazenar estados(so
os valores que cada atributo recebe) e atributos, assim como relacionar e
enviar mensagens, para outros objetos. Exemplo de objetos da classe
Humanos: Joo, Jos, Maria;
c) Atributos: caractersticas de um objeto. Estrutura de dados que representa a
classe. Exemplos: Funcionrio: nome, endereo, telefone, CPF;
d) Mtodos: definem as capacidades dos objetos. Por exemplo, Beto uma
instncia da classe Cachorro, portanto ele tem habilidade para latir, atravs
do mtodo deUmLatido(). Numa classe o mtodo apenas uma definio. A
ao s vai ocorrer quando o mtodo for invocado atravs do objeto, que no
caso o cachorro Beto. Basicamente, uma classe possui vrios mtodos, que
no exemplo da classe cachorro poderiam ser, senta, come e morde;
e) Mensagem: chama o objeto para inovar um de seus mtodos, ativando o
comportamento de sua classe. Podendo ser tambm diretamente direcionada
a uma classe (atravs de um mtodo esttico);
f) Herana: o mecanismo que permite uma classe (sub-classe), pode estender
outra classe (super-classe), aproveitando os seus comportamentos (mtodos)
e variveis (atributos). Pode ser definida como um relacionamento do tipo
um;

11

g) Associao: utilizada para que um objeto utilize os recursos de outros. Em

todo caso pode se tratar de uma associao simples como: usa um ou de
uma interao parte de . Exemplo: Uma pessoa usa o telefone. Onde a tecla
1 faz parte do telefone;
h) Encapsulamento: a separao dos aspectos internos e externos de um
objeto. utilizado um mecanismo que impede o acesso direto do estado do
objeto (atributos), apenas disponibilizando os mtodos que alteram seus
estados. Exemplo: no precisa conhecer o que se passa dentro do circuito de
um telefone para us-lo e sim a interface onde vou acessar (os botes, o fone
e o sinal);
i) Abstrao: tem a caracterstica de concentrar nos aspectos essenciais de um
contexto qualquer, ignorando os aspectos menos importantes ou acidentais.
Falando de modelagem de objetos, uma classe uma entidade de abstrao
existente no domnio de sofware;
j) Polimorfismo: usado como referncias de classes mais abstratas, tornando
a aplicao mais clara, podendo tambm representar uma interface bem
abstrata. O polimorfismo originrio do grego, (poli = muitas e morphos =
formas) significado muitas formas.

2.2.1- Programao orientada a objetos

Correia e Tafner (2006) esclarecem que a Programao Orientada a Objeto

tem como meta utilizar estruturas de dados que determina o comportamento dos
objetos para facilitar a programao. Os objetos so implementados para a
funcionalidade do sistema, a grande vantagem da Orientao a Objetos consiste
numa estrutura de dados e processos, organizando e facilitando o programa. O POO
uma vez criado pode ser reutilizado, significa que o cdigo pode ser usado por
diferentes sistemas.
Os Benefcios da Orientao a Objetos [...] esto se tornando cada vez

12
mais popular entre os desenvolvedores de sistema. Essa popularidade
no fruto do acaso ou da moda, e sim das vantagens de que os
desenvolvedores passam a usufruir quando adotam a metodologia da
Orientao a Objetos. (CORREIA; TAFNER, 2006, p. 08).

2.2.1- UML - Unified Modeling Language

Em Pender (2004) a UML, foi criada por desenvolvedores com o intuito de
solucionar problemas antes da implementao do cdigo evitando o trabalho extra
de reescrita e a cada mudana no sistema que levaria projetos mais lentos com
custos de manuteno mais altos, permite a comunicao, organizao da
documentao do sistema quando a idia trabalhar orientado a objeto. Tornou-se
um padro para a modelagem de software orientado a objeto e tem sido adotada por
empresas do mundo inteiro, com o intuito de evitar problemas futuros.
UML (Unified Modeling Language) a sucessora da onda de mtodos de
anlise e projeto orientado a objetos (OOA& D) que surgiu no final dos
anos oitenta e no incio dos anos noventa. Mais especificamente, ela
unifica os mtodos de Booch, Rumbaugh OMT (Object Modeling
Technique) e Jacobson, mas o seu alcance bem maior. UML passou
por um processo de padronizao pela OMG (Object Managment Group)
e agora um padro OMG..( FOWLER; SCOTT, 2000, p.19)

O objetivo da UML prover uma linguagem padro que permita modelar um

sistema, bem como visa dotar o mercado mundial de orientao a objetos de uma
linguagem nica de modelagem, que permita a troca de modelos de forma natural
entre os construtores de softwares (Fuzion, 1999).
Com a UML possvel (Mattiazzi, 1998): descrever eficazmente requisitos de
software, caracterizar a arquitetura (lgica e fsica) de um sistema, focalizar na
arquitetura em vez da implementao e direcionar programadores, aumentando a
produtividade e diminuindo os riscos.
Segundo Furlan (1998), "a UML uma linguagem de modelagem, no uma
metodologia". Assim, na construo de um software, a UML deve ser usada em
conjunto com uma metodologia de Engenharia de Software Orientada a Objetos, tais
como a metodologia Vincit, metodologia gil e a RUP (Rational Unified Process).

13

UML apresenta os seguintes diagramas que, em conjunto, modelam todo o

sistema (Mattiazzi, 1998; Furlan, 1998; Fuzion, 1999):

Diagrama de Classe: utilizado para representar as diversas classes de

objetos do sistema, seus atributos e operaes, bem como a associao
entre cada uma delas (herana, generalizao, composio, agregao, etc.);

Diagrama de Caso de Uso: usado para demonstrar o relacionamento entre

atores e casos de uso;

Diagramas de Seqncia: tipo de diagrama de interao que apresenta a

interao de seqncia de tempo dos objetos que participam na interao;

Diagrama de Colaborao: tipo de diagrama de interao que mostra uma

interao dinmica de um caso de uso e seus objetos relacionados;

Diagrama de Estado: utilizado para demonstrar as seqncias de estados

que um objeto assume em sua vida, em funo do seu uso no sistema;

Diagrama de Atividade: tipo de diagrama de estado no qual a maioria dos

estados so aes. Descreve o fluxo interno de uma operao;

Diagrama de Componente: usado para representar os diversos componentes

dos sistemas e suas dependncias;

Diagrama

de

Implantao:

utilizado

configurao de processamento run-time;

para

demonstrar

elementos

de

14

CAPITULO 3 - HOSPITAL MUNICIPAL DE CASTANHAL

O Hospital Municipal de Urgncia e Emergncia de Castanhal (HMC), Dra.
Maria Laise Pereira Lima, localizado em Castanhal- PA, dispe de XXX m2
construda, com XXX leitos, XXX para internao e XXX para observao, alm de
um centro cirrgico, composto de XX salas, ambulatrio, emergncia e demais reas
de apoio. Dispe, ainda, de laboratrio de anlise clnicas, servios de radiologia, de
atendimento psicolgico e de assistncia social.
Desde sua inaugurao, em XXX, o HMC uma unidade vinculada
Secretaria Municipal de Sade de Castanhal, com regime oramentrio vinculado
Prefeitura Municipal de Castanhal. Desde xxx, o Planejamento Estratgico
utilizado como ferramenta de Gesto utilizado como ferramenta de gesto e definiu
para o binio XXX a seguinte misso: Receber pacientes vtimas de agresses
externas emergncias clnicas ou cirrgicas, garantido um atendimento inicial de
excelncia, compartilhando a assistncia integral com as demais instituies do
municpio ou da microrregio. E o perfil: Hospital de pacientes agudos, com nfase
no atendimento de vtimas de trauma.
O servio de urgncia e emergncia do HMC recebe em mdia XXX
usurios a cada dia. A estrutura fsica composta por: Sala de Politraumatizados,
sala de sutura, sala de traumatologia, sala de observao e consultrios mdicos
adultos e peditricos. A equipe constituda de quatro mdicos emergenciais, dois
mdicos pediatras, trs enfermeiras, quartoze tcnicos de enfermagem...tr~es
recepcionista, tr~es seguranas......
O processo de atendimento do HMC, inicia-se, na recepo, onde so
realizados o acolhimento do paciente, agendamento de consultas ou de exames
( ver figura 5.1, pgina xxx, capitulo 5). Para o Ministrio da Sade ( Brasil, 2004), o
acolhimento uma ao tecnoassistencial que visa atender todos os que procuram
os servios, acolhendo, escutando e pactuando respostas adequadas aos usurios.
Dessa forma, o acesso dos pacientes ao servio hospitalar de urgncia e
emergncia do HMC se faz por demanda espontnea por meio de Servios PrHospitalares de Urgncia e Emergncia (SAMU, Corpo de Bombeiros e prhospitalar mvel privado). Os pacientes demandados de Servios Pr-Hospitalares
Mveis de Urgncia e Emergncia podem ser pr-classificados, dependendo do
contato prvio da regulao mdica. Os pacientes pr-classificados podem ter

15

acesso direto sala de reanimao de pacientes graves. Os demais pacientes

devero passar pelo processo de Acolhimento com Classificao de Risco.

O municpio de Castanhal/PA encontra-se em localizao estratgica onde

perpassa a BR- 316 sendo ele referencia da Regio de Sade Metropolitana III com
cobertura atualmente de mais de 35 municpios sejam oriundos dos municpios pactuados
na PPI ou de demanda espontnea de outros considerando que as urgncias mdicas
caracterizam-se como um dos maiores problemas no contexto do funcionamento do
Sistema nico de Sade. O Plano Estadual de Ateno s Urgncias do Par- PAR-RUE/PA
aprovado pela Portaria n 1.649 de 02/08/2012 concebido para atuao no quadrinio
2012/2015 uma proposta de reorganizao das aes e servios e junto a implantao
e implementao da rede de urgncia e emergncia organizando o fluxo dos pacientes no
sistema desde as Unidades Bsicas de Sade passando pelos cuidados pr- hospitalar
hospitalar e ps-hospitalar representado pela ateno domiciliar. O Hospital Municipal de
Urgncia e Emergncia Dra Maria Laise Pereira localizado em castanhal/PA CNES
2674769 CNPJ n 07918201/0001-11 est inserido no PAR-RUE como porta de entrada
de urgncia e emergncia com atendimento ininterrupto nas 24 horas durante os 7 dias
da semana sendo necessrio realizar adequaes com reforma e ampliao para dar
continuidade e garantir a qualificao dos servios hoje ofertados a populao.

16

CAPITULO 4- TECNOLOGIAS
Segundo Costa (2011, p.19) Quando se pretende desenvolver uma
aplicao informtica, a escolha das tecnologias a usar uma das
decises mais importantes a realizar no planeamento do desenvolvimento
da aplicao. Contudo, esse processo acaba sendo complexo e difcil. Isso
porque complicado afirmar que existe uma escolha ideal para resolver um
problema; j que, no mercado de tecnologia da informao, existem uma variedade
enorme de opes com caractersticas semelhantes; e, que, dificilmente atendem
todas as necessidades e particularidades para construo e manuteno da
aplicao.
Porm, existe uma escolha que ir se adequar, melhor, s necessidades do
programa a ser desenvolvido. Por isso, o projeto do SRC para o HMC considerou as
seguintes premissas para a escolha das tecnologias utilizadas ao longo do projeto:
I.

Anlise aprofundada dos objetivos e pr- requisitos da aplicao, de

forma a perceber quais as caractersticas tecnolgicas so mais
importantes no produto final;

II.

O contexto da aplicao, ou seja, suas restries, especificaes de

acesso e armazenamento de dados, condies de integrao com
outras aplicaes, etc.;

III.

Experincia do programador em desenvolver aplicaes recorrendo a

determinadas tecnologias.

4.1

APLICAES WEB

Uma das principais questes que se colocam atualmente ao planear o

desenvolvimento de uma aplicao a escolha do paradigma de funcionamento,
sendo que neste contexto surge a opo entre duas vertentes: as aplicaes Web e
as aplicaes Desktop.
As aplicaes tradicionais instaladas no sistema operativo do utilizador
foram durante muitos anos a nica opo para o desenvolvimento de aplicaes.

17

Estas aplicaes Desktop continuam a ser utilizadas, principalmente, devido ao

aproveitamento completo das potencialidades do hardware disponvel na mquina
do utilizador, tanto a nvel de processamento como a nvel grfico. Outro aspeto que
continua a ser favorvel o total controlo sobre o aspeto final da aplicao no ecr
do utilizador. (Dearle, 2007).
Apesar das suas vantagens, uma aplicao Desktop pode no ser a soluo
mais indicada. Isto devido necessidade de instalao, necessidade de esforo
extra para realizar atualizaes, dependncia do sistema operativo para o qual
criada, ou devido complicada integrao com utilizadores remotos (Rossi
et al., 2008).
A Web por seu turno, tem evoludo a um ritmo que seria
impensvel quando em 1991 foram publicados os primeiros documentos
com a inteno de partilhar informao e investigaes cientficas. Desde
ento, em menos de 20 anos, tornou-se uma ferramenta indispensvel
para a maioria das pessoas e empresas. De uma Web que fornecia
informao sobre produtos e servios atravs de um conjunto de websites
estticos que apenas podiam ser consultados pelos visitantes, passou-se a
uma Web centrada no utilizador, sendo este o principal responsvel pelo
contedo de cada pgina que visualiza, seja atravs das suas preferncias
como atravs da partilha da sua prpria informao.
Este novo modo de funcionamento, juntamente com um forte
componente interativa, levou designao de Web 2.0. Esta forma mais
dinmica e interativa de utilizar a Web foi em grande parte impulsionada
pela habilidade criar pginas Web recorrendo a contedo armazenado em
bases de dados (Rossiet al., 2008; Sven et al., 2009).
A melhoria funcional e esttica das aplicaes Web esteve
inicialmente relacionada com desenvolvimentos de tecnologias que
permitiram o processamento do lado do cliente, tais como AJAX, Javascript,
ActiveX, Java ou Flash. As aplicaes Web com este tipo de tecnologia so
descarregadas por completo para o Browser do cliente, que as executa
localmente. Para alm de fazer com que a aplicao seja pesada para a
mquina do cliente, o maior problema das tecnologias que permitem o
processamento do lado do cliente facto de no serem suportadas de

18

igual modo por todos os Browsers e sistemas operativos (Sven et al.,

2009). principalmente por estas razes que surgem tecnologias Web,
tais como ASP, PHP, Java EE ou ASP.NET, que levam o processamento para
o lado do servidor. Em aplicaes que usam este tipo de tecnologias, todo
o cdigo executado do lado do servidor, e quando a sua execuo
termina, enviada para o utilizador uma pgina HTML normal que pode
ser visualizada em qualquer Browser (Rossi et al., 2008). A Figura 4
demonstra as diferenas entre os modelos de processamento no cliente e
no servidor.

Figura 4- Diferenas entre a execuo de cdigo do lado do servidor (a) e do lado docliente
(b) (adaptado de Macdonald, 2009)

Um dos maiores impulsos dados ao crescimento da utilizao de aplicaes

Web foi o aparecimento do conceito de Rich Internet Applications (RIA), que se
refere a aplicaes Web independentes da plataforma, que so executadas no Web
Browser do utilizador, no necessitando de instalao, mas que ainda assim
apresentam

caractersticas

funcionalidades

semelhantes

aplicaes

tradicionais. O conceito de RIA representa a evoluo do Browser de uma interao

esttica pedido resposta para uma interao dinmica e assncrona. Este tipo de
aplicaes orientado usabilidade e interatividade que normalmente falhava nas
aplicaes tradicionais ( Busch e Koch, 2009).

19

Assim, apesar do domnio das aplicaes Web que efetuam o

processamento de cdigo no servidor, a programao de determinadas
funcionalidades no lado do cliente uma realidade e permite criar
interfaces mais ricas e robustas que respondem de forma mais afirmativa
s necessidades do utilizador. Desta forma normal surgirem associados
os

dois

tipos

de

processamento,

tirando

partido

das

melhores

caractersticas de cada um deles (Rossi et al., 2008). Um exemplo da

juno destas tecnologias a incluso das potencialidades do AJAX como
extenso plataforma ASP.NET.
Com os avanos nas tecnologias que permitem uma interao natural e
fluente entre o utilizador e a interface da aplicao Web, estas aplicaes parecem
aproximar-se das aplicaes tradicionais em quase todos os aspetos. Assim, as
aplicaes Web perfilam-se como o futuro para a realizao da maioria das nossas
tarefas, atravs da explorao de vantagens como a facilidade de utilizao, a
independncia da plataforma usada pelo utilizador, ou a menor quantidade de
recursos exigidos mquina do utilizador (Jazayeri, 2007).
As aplicaes na Web so denominadas multicamadas. Primariamente, trs
camadas se destacam, estando sempre presentes em qualquer aplicao Web
(Safran e Goldberg, 2000):
1. Camada de apresentao: tambm denominada de "interface com o
usurio", esta camada utiliza, em geral, um browser na internet para interpretar as
pginas HTML oriundas do servidor.
2. Camada middleware: tambm denominada de "objetos e programas serverside", a segunda camada responsvel pelo processameno do sistema, recebendo
as solicitaes do usurio e interagindo com o banco de dados. O retorno das
informaes aos usurios so na forma de pginas HTML.
3. Camada de banco de dados: a camada onde as informaes sero
armazenadas.
No caso do SRC para o HMC, optou-se por uma aplicao web. Dessa
forma, esse sistema deve se basear na arquitetura em trs camadas. Sendo assim,
a seguir ir se exemplificar sobre cada uma das tecnologias utilizadas em cada
camada para o desenvolvimento dessa aplicao.

20

4.2

LINGUAGEM JAVA

A Linguagem Java for criada pelo grupo liderado por James Gosling na Sun
Microsystems, e uma linguagem computacional completa, independente de
plataforma e com uma srie de facilidades para a integrao com a internet.
A Linguagem Java de alto nvel, orientada a objetos, simples, portvel, de
arquitetura neutra, distribuda, de alto desempenho, interpretada, que d suporte a
paralelismo e concorrncia, com coletor de lixo, robusta, dinmica e segura.
Os programas escritos em Java so executados por uma mquina virtual
Java, ou Java VM (Java Virtual Machine), que interpreta o cdigo, e independente
de plataforma.

4.3

ARQUITETURA J2EE
J2EE, ou Java 2 Enterprise Edition, uma plataforma para desenvolvimento

de aplicaes distribudas. Apresenta facilidades para a utilizao dos recursos

computacionais e distribudos tais como acesso a banco de dados, componentes
Web, utilizao de mensagens assncronas, execuo de processos transacionais,
persistentes ou no etc.
A

arquitetura

J2EE

apresenta

uma

API,

especificada

pela

Sun

MicroSystems, que proporciona um padro para a implementao dos diversos

servios que oferecem, sendo que isto pode ser feito diferentemente por vrias
empresas, de formas distintas mas ainda assim oferecendo as mesmas facilidades,
por estarem de acordo com as especificaes impostas para a sua construo
(BOND et al, 2003).

4.3.1

VISO DA PLATAFORMA
A arquitetura J2EE se apresenta em vrias camadas, sendo que cada uma

composta por componentes e servios que so providos por um container. Segundo

Temple (2004), pode-se entender como container o prprio navegador que fornece

21

recursos e facilidades para o componente, neste caso as pginas HTML. O

componente por sua vez, pode oferecer diversos servios ao usurio, atravs do
suporte do containers, tais como facilidades visuais como botes, hiperlinks, figuras
e tabelas, e o prprio servio de navegao. Em um servidor J2EE, podemos ter
diversos containers interagindo entre si.
A seguir uma breve explicao de cada camada da arquitetura e de seus
Componentes:

Camada cliente: acesso por meio de interfaces standalone (aplicaes Java),

pginas HTML ou Applets. Nesta camada os componentes residem em um
Applet Container, em um HTML container (Web browser) ou em um
Application Client

Container.

Camada Web: esta camada implementada por JSPs e Servlets, que

fornecem a lgica para a camada cliente (ou de apresentao) do negcio.
JSPs e Servlets residem no Web Container. JSPs oferecem a facilidade de
utilizar algumas lgicas de apresentao em uma pgina Web sem muitas
dificuldades tecnolgicas. O Servlet apresenta-se como um controlador das
aes executadas pelos usurios nas pginas de apresentao, e fornece
recursos para obter dados dessas aes e realizar as operaes desejadas.

Camada de Negcios: esta camada trata da lgica de negcio da aplicao.

nela que se implementa todas as regras de negcio, alocao de recursos,
persistncia de dados, validao de dados, gerncia de transaes e
segurana, providos por componentes conhecidos por EJBs.

Camada EIS - Enterprise Information System, ou Sistema de informaes

empresariais: nesta camada que se encontram os sistemas de banco de
dados, sistemas legados, e a integrao com outros sistemas que no so do
Padro J2EE.
O desenvolvimento de aplicaes em camadas torna o sistema mais

complexo na fase de anlise e desenvolvimento, mas quando se trata da

manuteno os programadores de computador tem mais facilidades, pois cada
camada tem sua independncia, embora integradas, conforme est ilustrador na
Figura 4.1.

22

Figura 4.1- Camadas, componentes, containers e sua iterao

Fonte: Bond (2003, p.1)

4.3.1

CAMADAS DA APLICAO

3.3. Camadas da Aplicao

No mundo do J2EE, existem geralmente quatro camadas: um cliente, uma
aplicao Web construda ou com servlets Java ou com JavaServerPages (JSP),
uma camada de lgica de negcio construda em Enterprise JavaBeans (EJB) e uma
camada de persistncia que acessa um banco de dados relacional (DESIGN
PATTERNS, 2003).
A Plataforma J2EE basicamente um modelo de aplicao distribudo em
multicamadas no qual a lgica da aplicao dividida em componentes de acordo
com sua funo. Isto permite que vrios componentes da aplicao que compem
uma aplicao J2EE sejam instalados em mquinas diferentes.
Os patterns a seguir propiciaro a melhoraria no desempenho de seus
sistemas em multicamadas e iro torna-los mais fceis de se manter ao reduzir a
complexidade. Como todos eles esto relacionados ao particionamento da
aplicao, esses so patterns essenciais para quase todas as aplicaes J2EE e
altamente relevantes para todos os desenvolvedores. O pattern Model-ViewController (MVC) refora um projeto modular e de fcil manuteno e fora a
separao de camadas. O session (EJB) organiza a lgica de negcio para o cliente.
O Data Access Object (DAO) fornece uma interface flexvel entre a lgica de negcio
e as fontes de dados reais. Finalmente, o Data Transfer Object (DTO), tambm
conhecido como um value object, facilita a comunicao entre as camadas.

23

3.4. Aplicaes em Trs Camadas

Neste modelo de trs camadas, a lgica de apresentao est separada em
sua prpria camada lgica. A separao em camadas torna os sistemas mais
flexveis permitindo que as partes possam ser alteradas de forma independente. As
funcionalidades da camada de negcio podem ser divididas em classes e essas
classes podem ser agrupadas em pacotes ou componentes reduzindo as
dependncias entre as classes e pacotes; podem ser reutilizadas por diferentes
partes do aplicativo e at por aplicativos diferentes. O modelo de trs camadas
tornou-se a arquitetura padro para sistemas corporativos com base na WEB.
De acordo com Lautert e Oliveira (2004), a idia do modelo MVC facilitar
as atividades de desenvolvimento de software, utilizando orientao a objetos e
dividindo os sistemas em trs camadas: modelo (ou camada de negcios), viso (ou
PPGEP Gesto Industrial - 2005

apresentao) e controle, conforme Figura 4. Basicamente, esta viso busca

diminuir o tempo perdido com atividades repetidas em algumas etapas do
desenvolvimento de sistemas semelhantes. Desta forma, obtm-se um ganho
significativo em produtividade, h uma reduo na quantidade de erros durante o
processo de desenvolvimento e melhora a manutenibilidade e suporte dos sistemas,
incrementando a qualidade do produto final.
Figura 3 Diviso do modelo MVC (Modelo 2)
Fonte: Lautert e Oliveira (2004, p. 1).
Os autores descrevem o modelo de forma a reduzir o acoplamento entre as
partes, e as dividem em:
Camada de Controle: a camada responsvel pelo fluxo, qualidade e
segurana das informaes no sistema. a ligao entre as
camadas de negcio e apresentao;
Camada de Modelo: so as atividades relativas ao prprio negcio do
sistema, como classes de persistncia que conversam com a base de
dados, "beans" da prpria modelagem do sistema e suas relaes;
Camada de Viso: so os formulrios, relatrios - a interface em
geral do sistema com os utilizadores. Elas mostram os resultados
gerados na camada de modelo. Geralmente utilizam tecnologias
como JSP, HTML ou XSL.
Na arquitetura MVC o modelo representa os dados da aplicao e as regras
do negcio que governam o acesso e a modificao dos dados. O modelo mantm o
PPGEP Gesto Industrial - 2005

estado persistente do negcio e fornece ao controlador a capacidade de acessar as

funcionalidades da aplicao encapsuladas pelo prprio modelo.
A tecnologia JSP foi projetada para ser flexvel, mas a maneira como sua
aplicao ir se comportar poder ser realizada de diversas maneiras:
Combinar livremente HTML e scriplets JSP.
Combinar livremente HTML e scriplets JSP e delegar funcionalidades
para Servlets.
Utilizar Servlets, pginas JSP e beans (distribudos ou no) para
implementar uma arquitetura do tipo MVC.
A primeira abordagem, combinao de grandes quantidades de cdigo Java
com HTML em pginas JSP, conduz, freqentemente, a aplicaes difceis de serem
utilizadas, mantidas e estendidas e, assim, portanto, no recomendada pela Sun.
Delegar funcionalidades para beans uma abordagem vivel, porque o
cdigo Java passa a estar centralizado em estrutura de dados possivelmente
reutilizvel, a partir do momento que o mesmo retirado das pginas de scripts JSP.
Esta arquitetura comumente conhecida como Model 1 da Sun (GEARY, 2002).

24

A ltima abordagem, a combinao de Servlets, pginas JSP e beans

(classes de negcios da aplicao) em uma arquitetura MVC, resulta em um
software extensvel e sustentvel, porque encapsula funcionalidades e reduzir o
impacto de futuras mudanas. Esta arquitetura de desenvolvimento, conhecida pela
Sun como Model 2 , anlogo ao padro arquitetural MVC (GEARY, 2002).
Figura 4 Modelo MVC para Aplicaes Web
PPGEP Gesto Industrial - 2005

A Figura 4 mostra o diagrama de seqncia para o Padro MVC no caso de

um Cliente HTML. O Controlador recebe a requisio do Navegador e realiza a ao
correspondente no Modelo. Em seguida, ele escolhe a Viso a ser exibida. A Viso
obtm os dados necessrios do modelo e a pgina HTML gerada exibida no
navegador.
3.5. Camada de Controle
3.5.1. Struts
Em uma definio breve, struts um framework que implementa o modelo
MVC. Explicando melhor, JavaServlets foram criados para lidar com os requests
feitos pelos browsers. Pginas JSP foram criadas para criar contedo dinmico para
exibio. Struts um framework que atravs de um servlet especial l um arquivo
XML de configurao, e assim envia os requests primeiramente a uma classe Java
que tratar esse request, realizando toda a lgica do negcio, e logo aps chama
uma pgina JSP que tratar de exibir a pgina para o navegador. Desta maneira,
aplicaes WEB tornam-se mais fceis de serem projetadas, criadas e
especialmente, mantidas.
A sua principal caracterstica prover uma camada de controle flexvel
baseada em padres de tecnologia j bem estabelecidos, Struts. Entre as
tecnologias usadas pelo framework, esto: Servlets, JavaBeans e XML (eXtensible
Markup Language - Linguagem de Marcao Extensvel) (BITTENCOURT, 2004).
Segundo Souza (2004), o Struts prov a sua prpria camada de controle,
bastando que as classes da aplicao estendam a classe
org.apache.struts.action.Action para que elas executem o processamento desejado.
Para a configurao do fluxo da aplicao, deve-se construir um arquivo (strutsconfig)
no formato XML definindo quais aes devem ser mapeadas para os objetos
responsveis. Essa facilidade permite que todo o fluxo do sistema permanea
separado do cdigo-fonte.
Para auxiliar na criao das pginas JSP, existe a taglib que faz parte da
distribuio do framework. As tags que compem essa taglib possuem funes que
permitem desde a criao de formulrios at a renderizao de erros provenientes
da camada de controle.
PPGEP Gesto Industrial - 2005

Struts tem o objetivo de gerenciar uma aplicao. Para tanto, configura-se no

descritor da aplicao (o arquivo WEB-INF/web.xml) que a classe ActionServlet do
struts ir receber as requisies do browser atravs do comando /do/. Nesse mesmo
arquivo configura-se um ou mais arquivos que serviro de configurao ao struts. Na
Figura 5, representado o funcionamento do struts.
Figura 5 Funcionamento do struts.
Fonte: Costa et al (2004, p.15).
3.6. Camada de Modelo
3.6.1. OJB
Object-Relational Java Bridge (OJB) um framework que implementa
persistncia objeto/relacional para Java, permite desenvolver classes persistentes
em Java. O OJB permite que objetos sejam manipulados sem a necessidade de
implementar nenhuma interface em especial ou estender alguma classe especfica.
A biblioteca d suporte a cenrios cliente-servidor (aplicaes distribudas) ou

25

standalone, de forma que possvel utilizar a API OJB para persistncia de objetos
mesmo em ambientes J2EE (Entity Beans utilizando Bean-Managed Persistence).
PPGEP Gesto Industrial - 2005

3.6.2. Pattern DAO

O DAO (Data Access Object) utilizado para encaplusar a lgica de acesso
a dados. Assim, se for necessrio a alterao de banco de dados, no necessrio
alterar todo sistema, mas somente os DAOs.
Dentro do DAO so realizadas as consultas ou o acesso aos mtodos do
OJB. A inteno real de existncia dos DAOs que eles no possuam nenhuma
lgica de negcio, apesar de algumas vezes ser necessrio encaplusar algo dentro
deles, especialmente quando outros patterns da camada de modelo no esto
presentes (LAUTERT e OLIVEIRA, 2004).
Quando utilizado junto com OJB, ambos realizam o trabalho de abstrair a
base, pois o OJB j mascara o tipo do banco de dados, ficando para o DAO a parte
de controlar as conexes, excees, retornos para os nveis superiores, entre outros.
O Framework OJB, tem a funcionalidade de mapear via objetos XML, os
atributos de uma base de dados PostgresSQL. Uma classe DAO, ir possuir
implementao referente utilizao deste Framework para persistir, recuperar e
atualizar os dados provenientes de uma requisio de uma regra de negcio.
Depois que a regra de negcio, propriamente dita, for executada, a vez de
uma classe DAO (Data Access Object) entrar em ao. Ela dever pegar o objeto
que recebe como argumento e saber trat-lo de acordo com os mtodos de negcio
que foram invocados na regra de negcio.
Figura 6 Diagrama de seqncia DAO.
PPGEP Gesto Industrial - 2005

Nesta situao, uma requisio feita antes dos dados chegarem regra de
negcio da aplicao, ela passa por uma ao especfica, um Action que ir
identificar qual Business Delegate est associada com aquela requisio (Figura 6).
3.6.3. Value Object
Os Value Objects trabalham coletando conjuntos de informaes
relacionadas em um nico objeto. Este objeto pode ser transferido do EJB para o
cliente com uma nica chamada remota. Em vez de fazer chamadas separadas para
receber nome, endereo e formas de pagamento, o cliente pode receber um objeto
contendo tudo em uma nica chamada. J que cada chamada na rede pode
adicionar uma frao de segundo ao tempo que ela gasta para executar uma
atividade, reduzir este overhead geralmente o mais efetivo melhoramento de
desempenho possvel para uma aplicao J2EE.
Um objeto que pertencente ao Value Object tem como principal funo
mapear os dados digitados pelos clientes em uma aplicao e posteriormente
trafeg-los pela rede, confrontando-se com as mais diversas camadas da aplicao.
Um Value Object popularmente conhecido como VO, ele deve ser constitudo
apenas com atributos e mtodos de acesso.
3.6.4. Pattern EJB
Enterprise Java Beans (EJB) uma arquitetura para componentes no lado
servidor que possibilita e simplifica o processo de construir aplicaes de objetos
distribudos em Java. Usando EJB, pode-se escrever aplicaes escalveis,
robustas e seguras sem escrever sua prpria infra-estrutura complexa para objetos
distribudos. EJB um ambiente de desenvolvimento rpido para aplicaes do lado
do servidor; pode-se rpida e facilmente construir componentes do lado do servidor
em Java atravs de uma infra-estrutura de objetos distribudos provida pela indstria.
EJB desenvolvido para prover portabilidade e reusabilidade qualquer que seja o
vendedor de servios corporativos da camada do meio, ou seja, da middlleware.
O principal objetivo do EJB administrar os objetos de negcio (incluindo os

26

DAOs), e fornecer uma camada padro para acesso a camada de modelo, definindo
uma interface de alto nvel aos subsistemas da aplicao, facilitando assim seu uso.
Quando utilizada juntamente com Struts, chamada de dentro das Actions, e assim,
PPGEP Gesto Industrial - 2005

essas duas classes formam a 'cola' entre a camada de modelo e a camada de

controle.
Variao do EJB: em vez do EJB chamar mtodo de negcios que
chamariam DAOs, ele mesmo trata de chamar os DAOs e executar a lgica de
negcio, eliminando assim mais um nvel de abstrao.
Um enterprise beans pode conter um ou mais objetos Java porque um
componente pode ser mais do que um simples objeto. Sem levar em considerao a
composio dos enterprise beans, os clientes do beans manipulam com uma
simples interface do componente exposta para os clientes. Esta interface, assim
como o enterprise bean propriamente dito, deve ser escrito conforme a especificao
para Enterprise Java Beans. A especificao requer que os beans declarem alguns
mtodos requeridos, estes mtodos permitem que o container EJB gerencie os
beans uniformemente, sem levar em considerao em qual container o bean estar
rodando (ENTERPRISE JAVA BEANS, 2003).
O cliente de um enterprise bean pode ser qualquer um talvez um servlet,
um applet, ou at mesmo outro bean corporativo. Em ltimo caso, uma requisio do
cliente a um bean pode resultar que um canal de bean seja executado.
A implementao do sistema trabalha com o tratamento de objetos distribudos,
garantindo segurana, persistncia, transaes e confiabilidade para o sistema,
onde os chamados Enterprise Java Beans (ENTERPRISE JAVA BEANS, 2003),
componentes de negcio so registrados em um servidor J2EE.
3.7. Camada View
A camada View feita atravs de pginas JSP, que contm a parte HTML
das pginas e toda a lgica para exibio dos dados.
Pginas JSP so como templates usados para produo automtica de
servlets. Escreve-se uma pgina HTML com alguns comandos Java, que so
traduzidos em tempo de execuo a um servlet com as seguintes propriedades:
a. O texto HTML na pgina convertido em comandos Java de escrita de
HTML e
b. os comandos Java na pgina so apenas copiados para dentro do
servlet.
PPGEP Gesto Industrial - 2005

3.8. XML: (eXtensible Markup Language):

O XML um padro para publicao, combinao e intercmbio de
documentos multimdia, desenvolvido pelo consrcio W3C (World Wide Web
Consortium). Assim como outras linguagens de marcao, XML lida com instrues
embutidas no corpo de documentos chamadas tags, que permitem a descrio de
dados. XML tem como base, linguagens mais antigas como, SGML e HTML, onde
atualmente so empregadas na representao de estruturas de dados estruturados
e semi-estruturados e seu intercmbio na WEB.
3.9. XSL
Um documento XSL um XML que consegue transformar um documento
XML em outros formatos de documentos (HTML, Texto, PostScrip e RTF), alm de
poder utilizar alguns elementos de estilo disponveis. A linguagem XSL pode ser
utilizada para acrescentar aspectos de apresentao aos elementos de um
documento XML. Desta forma, possvel criar mltiplas representaes da mesma
informao a partir de vrios documentos XSL diferentes aplicados a um nico
documento XML.

3.2- Hibernat

27

O Hibernate uma ferramenta de mapeamento objeto relacional de grande

aceitao entre os desenvolvedores de sistemas orientados a objetos.
Esta uma ferramenta gratuita e considerada uma das mais utilizadas por
especialistas da rea. Toda a configurao do Hibernate feita atravs de arquivos
em XML, os quais contem detalhes sobre o mapeamento de dados e detalhes sobre
as conexes com bancos de dados. Uma nova verso do Hibernate, o Hibernate
Annotations permite fazer anotaes sobre o mapeamento em cada classe que se
deseja mapear no sistema, substituindo assim os arquivos XML de mapeamento que
cada classe deve possuir para realizar o mapeamento, exceto o arquivo de
configurao do Hibernate (FERNANDES, 2005).
O hibernate, portanto, consiste em um Framework de persistncia para
aplicaes Java de cdigo aberto distribudo com a licena Lesser GNU Public
License (LGPL), possui verso .NET o NHibernate. Criado por desenvolvedores
Java no mundo e liderado por Gavin King. Com benefcio de ser uma soluo
madura, compatvel com diversos bancos relacionais e servidores de aplicao, com
curva de aprendizado rpido e principalmente variedade na documentao, livros,
artigos, tutoriais, entre outros.
Sua principal funo reduzir a complexidade nos programas Java, baseado
no modelo orientado a objeto, que trabalhem com banco de dados relacionais.
Permite facilidade para o mapeamento dos atributos com uso de XML ou Anotaes
nas classes conforme Figura 15. Com o HQL (Hibernate Query Language) uma
linguagem de consulta orientada a objetos, faz a recuperao das consultas por
meio de uma camada de cache eficiente (SILVA, A.G. da, 2005, p. 42).

28

Figura 3.2- Alto nvel da arquitetura Hibernate

Fonte: Silva, A.G. da.(2005, p.43)

29

CAPTULO 5- ANLISE E ESPECIFICAO DO SISTEMA

5.1

MEDOLOGIA DE ANLISE

Segundo Larman (2007, p.29), A anlise enfatiza uma investigao do

problema e dos requisitos, em vez de uma soluo. Por exemplo, se desejamos um
novo sistema online de comercializao, como ele ser usado? Quais so suas
funes?. Por isso, a anlise acaba sendo um termo de significado amplo, melhor
qualificado como anlise de requisitos ou investigao de requisitos.
Para a anlise da problemtica do Hospital Municipal de Urgncia e
Emergncia de Castanhal; empregou-se, a metodologia de anlise orientada a
objetos. Segundo Richards e Castilho (2009) a abordagem orientada a objetos
possibilita uma melhor organizao, versatilidade e reutilizao do cdigo
fonte, o que facilita atualizaes e melhorias nos programas.
Dentro os motivos que levaram a adoo dessa metodologia,
destacam-se:
I.

A necessidade de ter disponvel uma viso mais contemplativa possvel sobre

os problemas de agendamento de consultas, atendimento de internao hospitalar e

os fluxos de tarefas realizados pelos funcionrios do hospital;
II.

A dificuldade de se definir os requisitos para o Sistema de Registro

eletrnico a Sade(SRES) para a realidade do Hospital Municipal de

Castanhal;
Portanto, a construo do SRC para o HMC ocorreu em trs etapas:

Levantamento de requisitos: levantamento das necessidade, para a

construo de ums sistema que venha minimizar os problemas de
agendamento e registro de dados do paciente;

Modelagem: Interpretao dos requisitos levantados, bem como sua

traduo em especificaes do sistema;

30

Implementao: Converso das especificaes do sistema em

cdigo.

5.2

LEVANTAMENTO DE REQUISITOS
Nesta etapa foi realizado um levantamento das principais funcionalidades do

sistema para registro hospitalar, identificando seu modo de organizao e

visualizao de dados. Para isso, foi necessrio o levantamento dos seguintes
fluxos:
1. Fluxo de Atendimento de urgncia e emergncia: Procurou rastrear a
sequncia de eventos desde o momento que o paciente chega ao Hospital
Municipal at o momento que ele sai. Dentro os eventos, destacam-se:
recepo do usurio, acolhimento com classificao de risco, atividades de
mdicos e enfermeiros na sala de poli- traumatizados e de observao; e, por
fim, internao ou alta do paciente.
2. Fluxo de agendamento de consultas:
3. Fluxo de agendamento de exames laboratoriais:
Na figura 5.1, possvel visualizar esses fluxos, detectado em pesquisa de
campo; atravs do dilogo direto com funcionrios, enfermeiros e mdicos que
prestam atendimento no HMC; o que permitiu, gradualmente, a construo do
seguinte organograma geral para ser utilizado para a criao do modelo do sistema.
A partir da anlise do sistema, observou-se as seguintes rotinas:
I.

Cadastrar Funcionrios, enfermeiros, mdicos, supervisores e salas;

II.

Cadastrar a disponibilidade de horrios para os atendimentos de

consultas e exames;

III.

Agendamento de Consultas e exames;

IV.

gerar relatrios.

31

32

Figura 5.1- Fluxo geral de atendimento Hospitalar

Para construo dos Registros Eletrnicos-Pronturios eletrnicos, foram

necessrios, primeiramente, a definio do conjunto de informaes que deveriam
estar

presentes

nesses

documentos

eletrnicos.

Para

isso,

levou-se

em

considerao as normas definidas pela resoluo do Conselho federal de Medicina

N 1638/2002 e 1821/2007, a Cartilha da Sociedade Brasileira de Pronturio
eletrnico e, principalmente, os aspectos levantados pela Comisso de Reviso de
Pronturios no Hospital Municipal de Urgncia e Emergncia de Castanhal, Dra.
Maria Laise Pereira Lima.
A base das informaes deve ser resultante dos atendimentos prestados
pelos diferentes profissionais da sade no Hospital Municipal. O registro das aes
executadas armazenado em Fichas de Atendimento Hospitalar (FAH), de exames
e de agendamento a consultas.
Para

5.3- OBJETIVOS LEVANTADOS

O sistema tem por objetivo auxiliar os trabalhos oferecidos pela clnica, e agilizar as
tarefas dirias como manipular e alterar, dados de pronturios, de cadastramento. Alem
disso o sistema deve manter protegidas as informaes pessoais de cada paciente, pois
devido existncia de um cdigo de tica da profisso que exercem os funcionrios,
terceiros no podero ver as informaes, pois muitas vezes podem trazer certo
constrangimento ao paciente, e tambm no menos importante fazer o controle de
reservas das salas para consultas de diversificados tipos de atendimento, e tambm
salas de reunies.
O sistema dever trazer mais praticidade para o dia a dia dos usurios, evitando que
eles tenham de se preocupar com pilhas de arquivos, ou similar, aproveitando mais 12

33

o tempo para se dedicar a tarefas mais importantes, para assim melhorar os servios
prestados pela clinica.
Alm disso, o Sistema ir trazer maior facilidade para os funcionrios realizarem
as suas tarefas reduzindo o tempo com a procura de registros de pacientes e
proporcionar ao usurio maior praticidade na hora de efetuar os agendamentos, tanto de
consultas quanto de salas.

Este captulo apresenta o sistema proposto e como este foi realizado.

Consciente de que
o sistema atual de marcao de consulta apresenta alguns problemas
como centralizao
do servio, ocasionando _las, prope-se reformul-lo. Esse projeto tem
como principal
objetivo descentralizar a marcao de consultas dos Hospitais. Busca
possibilitar que o
agendamento de consultas seja feito de outras localidades alm do prprio
hospital, bem
como permitir que de um mesmo local se possa agendar consultas em um
conjunto de
hospitais mais abrangente e disponibilizar mais informaes aos
pacientes.
A construo do sistema consiste em trs etapas:
Levantamento de Requisitos: Levantamento das necessidades, para a
construo de
um sistema que venha minimizar os problemas existentes.
Modelagem: Interpretao dos requisitos levantados, bem como sua
traduo em
especi_caes do sistema.
Implementao: Converso das especi_caes do sistema em
cdigo.

34

5.4

REQUISITOS FUNCIONAIS

5.4.1

Cadastros

a) O SRC deve permitir o cadastro de trs tipos de usurios, interno ( Mdico,

enfermeiro e funcionrio) e web (paciente);
b) O SRC possui um usurio administrador pr- cadastrado com login e senha;
c) O usurio administrador deve ser capaz de manter o cadastro dos usurios
do tipo Mdico e enfermeiro;
d) Os usurios do tipo mdico devem possuir os seguintes atributos: nome, cpf,
sexo, data de nascimento, cidade, bairro, rua, nmero, estado, cep, telefone,
celular, e-mail, tipo de usurio, login, senha e CRM;
e) Os usurios do tipo enfemeiro devem possuir os seguintes atributos: nome,
cpf, sexo, data de nascimento, cidade, bairro, rua, nmero, estado, cep,
telefone, celular, e-mail, tipo de usurio, login, senha e CRE;
f) Os usurios do tipo interno devem ser capazes de manter, paciente com os
seguintes atributos: nome, cpf, data de nascimento, nmero do carto do
SUS, cidade, bairro, sexo, rua, nmero, estado, cep, telefone, celular, e-mail,
tipo de usurio, login, senha e convnio;
g) Os usurios do tipo interno devem ser capazes de manter o cadastro de
agenda com os seguintes atributos: data, horrio, motivo, anotao e
telefone;
h) Os usurios do tipo funcionrio devem ser capazes de manter o cadastro da
ficha de anamnese com os seguintes atributos: medicamento, tipo sanguneo,
doena, alergia, fumante e gestante;
i) Os usurios do tipo interno devem ser capazes de manter o cadastro das
ocorrncias em cada consulta com os seguintes atributos: login do paciente,
login do dentista, data, hora do atendimento e anotaes.

35

5.4.2

Controle de usurio

a) O SRC deve permitir o acesso pelo login e senha dos usurios do tipo interno
e web;
b) O sistema deve permitir a consulta dos usurios cadastrados, prevendo uma
pesquisa por nome;
c) O usurio interno deve ser capaz de emitir relatrio de usurios cadastrados.
5.4.3
a)

Controle de Anamnese
O SRC deve permitir a consulta da ficha de anamnese de cada paciente pelo
nome;

5.4.4 Controle de Agendamento

a) O usurio do tipo interno informa a disponibilidade da agenda de cada

dentista ao sistema;
b) Somente os horrios previamente cadastrados como disponveis e ainda no
agendados, devem ser disponibilizados para acesso aos usurios na web;
c) O usurio do tipo web j cadastrado pode visualizar o dia, horrio e o nome
do dentista agendado;
d) O SRC deve permitir que o usurio web faa o agendamento somente uma
vez por semana;
e) O SRC deve permitir que o usurio interno faa o agendamento quantas
vezes forem necessrias;
f) O SRC deve permitir que o usurio interno deve ser capaz de emitir relatrio
de: agendamento cadastrado por data, horrios cadastrados e excluir
disponibilidade gerada.
5.4.5

Requisitos no funcionais - Portabilidade

36

a) O SRC deve permitir ser executado em computadores com sistemas

operacionais Windows e Linux e deve ser capaz de ser executado
atravs dos navegadores web: Microsoft Internet Explorer, Mozilla Firefox
e Google Chrome;
b) O SRC deve ser executado em computadores Pentium IV ou superior.

37

CAPTULO 6- MODELAGEM DO SISTEMA DE REGISTRO

CLINICO
O grande desafio das equipes de desenvolvimento de aplicaes ,
sobretudo, produzir aplicativos seguros, eficientes, de fcil manuteno, reutilizveis
e em prazos cada vez menores. Por isso, devido os benefcios discutidos do
paradigma da orientao a objetos (ver capitulo 3), terem apresentado um grande
avano nestes ltimos tempos para o desenvolvimento de software ligados ao
campo da sade; adotou-se esse padro para o desenvolvimento do SRC para o
HMC.
Segundo Ranthum (2006, p.53) O sucesso para o desenvolvimento de
aplicaes com tecnologia orientada a objetos est intimamente associada a
arquitetura que vamos usar para construir a aplicao. A tendncia indica que est
arquitetura estar baseada na organizao da aplicao em camadas e na
observao dos padres utilizados pelo mercado.
A organizao em camadas a chave para a independncia entre os
componentes; e, esta independncia, que vai atingir os objetivos de eficincia,
escalabilidade, reutilizao e facilidade de manuteno.
Em um primeiro instante, produzir aplicativos multicamadas pode parecer
mais complexo. O termo camada pode significar uma separao fsica ou lgica. No
contexto de apresentao deste trabalho, a produo de software vai considerar
camada como uma referncia separao lgica de responsabilidades.

38

6.1- APLICAES EM TRS CAMADAS

Com o advento da Internet houve um movimento para separar a lgica de
negcio da interface com o usurio. A idia que os usurios da WEB possam
acessar as mesmas aplicaes sem ter que instalar estas aplicaes em suas
mquinas locais.
No modelo em trs camadas (Figura 6.1), o aplicativo movido para o
Servidor e um navegador WEB usado. O aplicativo executado em servidores
WEB com os quais o navegador WEB se comunica e gera o cdigo HTML para ser
exibido no cliente.
Figura 6.1- Aplicao em trs camadas.
Fonte: MVC, 2004.
Neste modelo de trs camadas a lgica de apresentao est separada em
sua prpria camada lgica. A separao em camadas torna os sistemas mais
flexveis permitindo que as partes possam ser alteradas de forma independente.
As funcionalidades da camada de negcio podem ser divididas em classes e
essas podem ser agrupadas em pacotes ou componentes, reduzindo as
dependncias entre as mesmas e pacotes; podem ser reutilizadas por diferentes
partes do aplicativo e at por aplicativos diferentes. O modelo de trs camadas
tornou-se a arquitetura padro para sistemas corporativos com base na WEB, e o
modelo escolhido para apresentao deste estudo.
O crescimento do POO ajudou a promover uma maior modularidade, pois os
objetos

encapsulam

seus

dados

(propriedades,

mtodos)

oferecem

funcionalidades atravs de seus mtodos. Projetando-se de forma adequada os

objetos podem ter reduzido as dependncias entre si, ficando assim fracamente
acoplados e sero mais fceis de manter e evoluir.
O modelo de trs camadas fsicas (3-tier) divide um aplicativo, de modo que
a lgica de negcio resida no meio das trs camadas fsicas. Isto chamado de
camada fsica intermediria ou camada fsica de negcios. A maior parte do cdigo
escrito reside na camada de apresentao e de negcio.
A arquitetura MVC - (Modelo, Visualizao, Controle) fornece uma maneira
de dividir a funcionalidade envolvida na manuteno e apresentao dos dados de

39

uma aplicao. A arquitetura MVC no recente e foi originalmente desenvolvida

para mapear as tarefas tradicionais de entrada, processamento e sada para o
modelo de interao com o usurio. Usando o padro MVC fica fcil mapear esses
conceitos no domnio de aplicaes WEB multicamadas.
Na arquitetura MVC o modelo representa os dados da aplicao e as regras
do negcio que governam o acesso e a modificao dos dados. O modelo mantm o
estado persistente do negcio e fornece ao controlador a capacidade de acessar as
funcionalidades da aplicao encapsuladas pelo prprio modelo.
Um componente de visualizao renderiza o contedo de uma parte
particular do modelo e encaminha para o controlador as aes do usurio;
acessando tambm os dados do modelo via controlador e definem como esses
dados devem ser apresentados.
O controlador define o comportamento da aplicao, ele que interpreta as
aes do usurio e as mapeia para chamadas do modelo. Em um cliente de
aplicaes WEB essas aes do usurio poderiam ser cliques de botes ou
selees de menus. As aes realizadas pelo modelo incluem ativar processos de
negcio ou alterar o estado do modelo. Com base na ao do usurio e no resultado
do processamento do modelo, o controlador seleciona uma visualizao a ser
exibida como parte da resposta a solicitao do usurio. H normalmente um
controlador para cada conjunto de funcionalidades relacionadas.
A arquitetura de trs camadas, que est representada na Figura 6.2, uma
implementao do modelo MVC. O modelo MVC est preocupado em separar a
informao de sua apresentao.

40

Figura 6.2- Aplicando MVC em um modelo de trs camadas

Fonte: MVC, 2004.

Camada de apresentao ou visualizao - No est preocupada em como

a informao foi obtida ou onde ela foi obtida, apenas exibe a informao.

Inclui os elementos de exibio no cliente: HTML, XML, ASP, Applets;

a camada de interface com o usurio;

usada para receber a entrada de dados e apresentar o resultado.

Camada de lgica da Aplicao - o corao da aplicao. Responsvel por

tudo que a aplicao vai fazer.

Modela os dados e o comportamento por atrs do processo de negcios;
Preocupa-se apenas com o armazenamento, manipulao e gerao de
dados;
um encapsulamento de dados e de comportamento independente da
apresentao.
Camada de Controle - determina o fluxo da apresentao servindo como
uma camada intermediria entre a camada de apresentao e a lgica de negcios,
responsvel por controlar e mapear as aes.

41

6.2- ABORDAGEM DE DESENVOLVIMENTO

De acordo com a fase de criao da aplicao, alguns conjuntos de etapas
foram desenvolvidas na abordagem de desenvolvimento do projeto. Para este, ser
utilizado um paradigma chamado Modelo Evolutivo, que baseado no principio
de desenvolvimento incremental e interativo, onde novas funes sero adicionadas
a cada ciclo, gerando uma nova verso do software permitindo um feedback mais
imediato do usurio.
Ciclo de Requisitos e Anlise do sistema.
Ciclo Projeto/Modelagem.
Ciclo Implementao.
Ciclo Testes
6.2.1

CICLO DE REQUISITOS E ANLISE DO SISTEMA

Como foi discutido no capitulo 5, a anlise de requisitos garante uma

estrutura de dados que atenda s necessidades dos usurios. Devido aos benefcios
da AOO- como: reusabilidade, manutebilidade, entre outros; empregou-se, essa
tcnica para o desenvolvimento do SRC para o HMC.
Na rea da sade, e em especial no desenvolvimento de PEPs, a AOO tem
sido bastante utilizada, existindo vrias publicaes a respeito (Dolin, 1994; Dore et
al., 1995; Sakamoto, 1998; Egyhazy et al., 1998; Krol e Reich, 1999) que destacam
o uso da OO, suas vantagens, o ganho de produtividade, a melhoria na qualidade do
produto, a reutilizao de cdigo, dentre outros pontos positivos (Seto, Kamiyama e
Matsuo, 1998).
6.2.2

CICLO DE PROJEO E MODELAGEM

Segundo Ranthum (2005, p.62) A grande dificuldade de construo de

aplicaes consiste no fato de que at 60% de todo o cdigo produzido destinado

a construo de interfaces e problemas de interao com o usurio. Por isso, o SRC
desenvolvido, seguindo a tcnica de deciso de anlise adotada no capitulo 5, AOO,

42

adotou o Design Orientado a Objetos (DOO), j que, essa tcnica segue as mesmas
caractersticas da anlise orientada objetos.
Atravs da DOO foi possvel obter ferramentas de 4 a gerao, como as
ferramentas CASE, que combinadas com as tcnicas da UML, permitiram a
modelagem (desenho) da aplicao. Alm disso, essa abordagem permitiu
especificar, padronizar e documentar as entidades do sistema.
6.2.3

CICLO DE IMPLEMENTAO
A Linguagem de desenvolvimento escolhida foi Java, por ser uma linguagem

orientada a objetos, portvel, extensvel e que abrange um grande nmero de

frameworks disponvel no mercado para incrementar e especializar diversas tarefas
do projeto.
O paradigma OO foi utilizado tanto para fase de anlise e especificao do
sistema, bem como para a fase de implementao. Isso poder garantir, para o SRC
desenvolvido, confiabilidade de regra de negcio, escalabilidade da aplicao e
tratamento de objetos distribudos.

6.2.3

CICLO DE TESTES

Tcnicas de testes podem ser implementadas para assegurar que o

software
est realmente em acordo com suas especificaes e livre de erros. Testes de
unidade, testes de integrao, testes de sistema e testes de instalao so
exemplos de tcnicas que podero ser utilizadas.
De acordo com as necessidades do projeto, testes de unidades sero
aplicados na fase de implementao do projeto. O teste de unidade, realizado
atravs do Framework Junit, ser realizado de dois modos: Em Alfa-test: os testes
foram realizados pelos prprios desenvolvedores no ambiente de desenvolvimento e
em Beta-Tests, onde os testes sero realizados em um ambiente de execuo pelos
prprios usurios do software.

43

CAPITULO 7 IMPLEMENTAO
A implementao do sistema foi baseada nos padres descritos a seguir, as
figuras que compes este captulo foram extradas de Matos (2005, p. 65 e 95), que
utiliza a tcnica da UML de desenvolvimento e implementao de sistemas.

Padres Arquiteturais
MVC (Modelling View Controller).

44

REFERNCIAS BIBLIOGRFICAS
MASSAD,

Eduardo.

Pronturio

Eletrnico

do

Paciente

na Assistncia,

Informao e Conhecimento Mdico. Faculdade de Medicina da Universidade

Federal de So Paulo. 2003.

TRIANA, A. A semiologia biomdica e seus limites: desvendando o caminho

entre o sutil e o evidente. UNICAMP. Campinas. 1999.

MARTINS, S. L. Pronturio Eletrnico do Paciente para Cardiologia e

Odontologia. Escola Politcnica de Pernambuco- Universidade de Pernambuco.
2009.

MEDICINA, Conselho Federal. Resolues do CFM, 1331/89, 1605/00, 1638/02,

1639/02, 1821/2007. Disponvel em: <http://www.cfm.gov.br>.

COSTA, H. N.; ALVES, M. M., MARTINS, V. SCO - Sistema para clnica

odontolgica: gerenciamento de agendamento. 2010.88 f. Dissertao (Trabalho
de Concluso do Curso em Tecnologia de Sistemas para Internet)- Centro
Universitrio Catlico Salesiano Auxilium, UNISALESIANO, So Paulo, 2010.
FERNANDEZ, Luiz Rafael . Construindo aplicaes utilizando Thinlet e
Hibernate - Parte 02, Disponvel em : <http://www.imasters.com.br/artigo /
3510/oracle/construindo_aplicacoes_utilizando_thinlet_e_Hibernate_-_parte_02/>,
Acesso em: 03 maio 2014.
SILVA, A. G. da. Estudo Comparativo de Ferramentas de Mapeamento ObjetoRelacional. Jaguarina: FAJ, 2005.
LARMAN, C. Utilizando UML e padres: uma introduo anlise e ao projeto
orientado a objetos. 3 ed. Porto Alegre: Bookman, 2007.

45

Rossi, G.; Pastor, O.; SchWabe, D.; Olsina, L. Web Engineering:

Modelling and Implementing Web Applications. London: Springer, p.
7-29. 2008
DEARLE, A. Software Deployment, Past, Present and Future.. Future
of Software Engineering.pp. 269-284.FOSE, 2007.
SVEN, C., FLORIAN, D., DOLOG, P. E MARISTELLA, M.,. Engineering Web
Applications. p. 1-4..Berlin: Springer, 2009.
MACDONALD, M. Beginning ASP.NET 4 in VB: Apress, p. 6-15, 863-865.
USA, 2010.
BUSCH, M. E KOCH, N.,. Rich Internet Applications. IEEE Internet
Computing, p.9-12. 2009.
JAZAYERI, M. Some Trends in Web Application Development Future
of Software Engineering. pp. 199-213. FOSE , 2007.
JOHANSTON, H. Sistemas de Informao Hospitalar: presente e futuro. 1993.
Revista Informdica, 1993;1(2):5-9. Disponvel em:
http://www.informaticamedica.org.br / informed/halley.htm. Acesso em: 22 dez 2014.
Jacobson, I., Christerson, M., Jonsson, P. et al. Object-Oriented Software Engineering: A Use
Case Driven Approach. Addison-Wesley, 1996.
SIGULEM, D. Introduo Informtica em Sade. So Paulo. Captulo
Introdutrio da Tese de Livre-Docncia: Um Novo Paradigma de Aprendizado na
Prtica Mdica da UNIFESP/EPM. 1997. Disponvel em: http://www.virtual.
epm.br/material/tis/curr-med/infosaude/index.htm. Acesso em: 28 nov 2014.
GIUSE, D. A. e KUHN, K. A. Health information systems challenges: the
Heidelberg conference and the future. International Journal of Medical
Informatics, v.69, p.105-114. 2003.
LITTLEJOHNS, P, WYATT, J., GARVICAN, L..Evaluating Computerised Health
Information Systems: hard lessons to be learnt, Information in Practice, BMJ Vol.
326, bmj.com, pp. 860-863. 2003.

46

BRASIL. Ministio da Sade. HumanizaSUS: acolhimento com avaliao e

classificao de risco: um paradigma tico- esttico no fazer em sade. Braslia:
Ministrio da Sade, 2004. Dsiponvel em:
http://bsvms.saude.gov.br/bvs/publicacoes/acolhimento.pdf. Acesso em: o2 de fev.
2015.
UML. A unificao dos mtodos para a criao de um novo padro,[s.l.], 2001.
Disponvel em:
<http://www.infotem.hpg.ig.com.br/lin_progr_uml.htm#aunificacao> Acesso em: 10 jan.
2015.
CORREIA, C.H.; TAFNER, M. A. Anlise orientada a objetos. 2. Edio. ed. Visual
Books. Santa Catarina, 2006.
Safran, C. e Goldberg, H. (2000). Electronic patient records and the impact of the
internet.
International Journal of Medical Informatics, 60(2):7783.

Dolin, R.H. A high-level object-oriented model for representing relationship in an

electronic medical record. Proceedings of the Annual Symposium on Computer
Application in Medical Care, p.514-8, 1994.
Dore, L., Lavril, M., Jean, F.C., Degoulet, P. An object oriented computer-base patient record
reference model. Proceedings of the Annual Symposium on Computer Application in Medical
Care, p.377-81, 1995
Sakamoto, N. A practical object-oriented approach to a development of a next generation
hospital information systems. Proceedings Medinfo, p.957-61, 1998
Krol, M., Reich, D.L. Object-oriented analysis and design of a health care management
information system. Journal of Medical Systems, v.23, n.2, p.145-58, abr. 1999.
Furlan, J.D. Modelagem de objetos atravs da UML. So Paulo: Makron Books, 1998.
Fuzion. Introduo a Orientao a Objetos. Rio de Janeiro, 1999. CD-ROM. E-book.
Mattiazzi, L.D. Orientao a Objetos e a UML: Finalmente um Rumo a Seguir.
Developers' Magazine, Rio de Janeiro, ano III, n.26, p.26-29, jul. 1998.
Rumbaugh, J., Blaha, M., Premerlani et al. Modelagem e projetos baseados em objetos. Rio
de Janeiro: Editora Campus, 1994.

47

Ranthum, Rogrio Modelagem e implementao de um sistema de informao para

otimizao deexames de diagnsticos por imagens. / Rogrio Ranthum. -- Ponta
Grossa : UTFPR, Campus Ponta Grossa, 2006.
MVC, Web-Tier Application Framework Design. Disponvel em
<http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web
-tier/web-tier5.html >. Acessado em: 22 de fev. de 2015.
BOND, M. et al.: Aprenda J2EE com EJB, JSP, Servlets, JNDI, JDBC e XML em
21 dias. So Paulo: MAKRON Books, 2003.
TEMPLE, A. Jsp, Servlets e J2EE (2004). Disponvel em
<www.inf.ufsc.br/~bosco/downloads/>. Acessado em: 2 de janeiro de 2015.