Castanhal,2015

ODAILSON NOGUEIRA CARDOSO

SISTEMA DE ENSINO PRESENCIAL CONECTADOANÁLISE E DESENVOLVIMENTO DE SISTEMAS

DESENVOLVIMENTO DE UM SISTEMA DE REGISTRO ELETRÔNICO CLINICO PARA O HOSPITAL DE URGÊNCIA

E EMERGÊNCIA DE CASTANHAL-PA

Castanhal2012

SS

RESUMO

DESENVOLVIMENTO DE UM SISTEMA DE REGISTRO ELETRÔNICO CLINICO PARA O HOSPITAL DE URGÊNCIA

E EMERGÊNCIA DE CASTANHAL-PA

Projeto de Estágio apresentado à UNOPAR- Universidade do Norte do Paraná, como requisito parcial para a obtenção do título de Tecnologia em Análise e Desenvolvimento de Sistemas.

Tutor Orientador: Professor Supervisor:

ODAILSON NOGUEIRA CARDOSO

Castanhal,2015

ABSTRACT

ABREVIATURAS

TICS- TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO EM SAÚDE

SUS- SISTEMA ÙNICO DE SAÚDE

AOO- ANÁLISE ORIENTADA A OBJETOS

RIA- RICH INTERNET APPLICATIONS

HMC- HOSPITAL MUNICIPAL DE CASTANHAL

SRC- SISTEMA DE REGISTRO CLÍNICO

PEP- PRONTUÁRIO ELETRÔNICO DO PACIENTE

SI- SISTEMA DE INFORMAÇÃO

OOAD - OBJECT-ORIENTED ANALYSIS AND DESIGN

LISTA DE FIGURAS

LISTA DE QUADROS

SUMÁRIO

CAPÍTULO 1- INTRODUÇÃO.....................................................................................3

1.1. ESTRUTURA DA DISSERTAÇÃO..................................................................6

1.2. JUSTIFICATIVA..............................................................................................6

1.2. OBJETIVOS....................................................................................................6

CAPÍTULO 2- REFERENCIAL TEÓRICO..................................................................3

CAPÍTULO 3- TECNOLOGIAS..................................................................................3

3.1. APLICAÇÕES WEB........................................................................................6

CAPÍTULO 4- ANÁLISE E ESPECIFICAÇÃO DO SISTEMA....................................3

8 CONCLUSÕES...................................................................................................46

9 REFERÊNCIAS BIBLIOGRÁFICAS..................................................................48

CAPÍTULO 1- INTRODUÇÃO

A utilização da Tecnologia da Informação e Comunicação em Saúde (TICS)

cresce a cada dia. Hoje são inúmeras as possibilidades, os recursos e os benefícios

que a informática pode trazer para a área de saúde, especialmente para o médico.

Segundo Martins (2009, p.8) “a gestão das informações do paciente é uma

prática muito antiga e essencial no acompanhamento clínico”. Entretanto, com a

evolução da medicina e da Tecnologia da informação; modificou-se a forma de

armazenamento dos dados clínicos, bem como quais informações eram mais

relevantes a serem registradas.

Para Triana (2009) a semiologia médica estuda através das anamneses,

exames clínicos, observações, tabelas, síndromes, entre outros; os sinais e

sintomas das doenças humanas com o propósito de se estabelecer um diagnóstico.

A medicina sempre buscou o uso de uma gestão eficiente dos dados da semiologia

médica. Com o advento da informática, mais precisamente com o surgimento da

área “sistemas da informação”, foram desenvolvidos os prontuários eletrônicos do

paciente para armazenar os diagnósticos e realizar os acompanhamentos clínicos.

Portanto, a presente dissertação tem como objetivo desenvolver

uma solução informática para o registro clínico eletrônico do Hospital

Municipal de Urgência e Emergência de Castanhal (HMC), Dra. Maria Laise Pereira

Lima, utilizando ambiente web. Deste modo, a dissertação assume um caráter

essencialmente técnico, isto é, mais direcionado para as questões de

desenvolvimento de software.

1.1 ESTRUTURA DA DISSERTAÇÃO

O processo de organização da monografia inclui dividi-la em XXX

capítulos chaves, além desse capítulo de informações iniciais; cada um

3

contendo um tema fundamental.

No capítulo 2 são abordados alguns aspectos, com base em revisão

bibliográfica, para construção de sistemas de informação a saúde (SIS).

Apresenta-se, em linhas gerais, os fundamentos conceituais associados

aos SIS, bem como, os principais fundamentos conceituais da análise

Orientada a objetos e da Unified Modeling Language- UML- técnicas de análise e

modelagem de sistemas, que foram utilizadas para desenvolvimento da aplicação

para o HMC.

No capítulo 3, especifica-se o contexto do cenário do HMC. Caracteriza-se

esse local de estudo;

O Capítulo 4 apresenta o conjunto de tecnologias que foram utilizadas para

tornar possível o desenvolvimento do projeto desta dissertação. Especifica-se a

linguagem JAVA, o Sistema Gerenciador de Banco de Dados e as ferramentas

utilizadas no desenvolvimento do sistema.

O Capítulo 5 explica o processo de análise e modelagem para o

desenvolvimento de software adotado segundo a análise Orientada a objetos. Nesse

sentido, é realizada uma análise aos requisitos da aplicação; assim como a todo o

processo de planejamento dos componentes que irão dar origem à aplicação

propriamente dita. Especificou-se, também, nesse capítulo, os diagramas de caso de

uso, diagramas de classe, diagramas de sequência e o projeto do banco de dados.

No capítulo 6 apresenta-se os layouts das telas e suas descrições.

1.2 JUSTIFICATIVA

Para Costa, Alves e Martins (2010) a obtenção da informação por meio

eletrônico reflete positivamente no resultado do atendimento com qualidade nas

instituições vinculadas a área da saúde, pois a dificuldade e a perda de informação

com prontuários obsoletos e pouco precisos podem causar danos irreversíveis 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 saúde do paciente,

dados clínicos e agenda do médico; passou a ser uma grande necessidade dos

centros ambulatoriais pelo Brasil.

4

A realidade vivenciada pelo hospital Municipal de Urgência e Emergência de

Castanhal, Dra. Maria Laise Pereira Lima, é de ausência de um software para

gerenciamento aos registros eletrônicos de saúde. Por isso, o atual processo de

agendamento de consultas acaba sendo feito somente com a presença física do

usuário e o registro das informações clinicas do paciente está vinculada a fichas de

papel.

Esse fato conduz a fatores que dificultam e causam transtornos aos usuários

do Sistema Único de Saúde que se utilizam do Pronto Socorro para atendimento

clínico. 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 Clínico (SRC) deverá trazer mais praticidade para o

dia a dia dos usuários, 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 serviços prestados pelo hospital.

Além disso, o Sistema irá trazer maior facilidade para os funcionários

realizarem as suas tarefas reduzindo o tempo com a procura de registros de

pacientes e proporcionar ao usuário maior praticidade na hora de efetuar os

agendamentos de consultas e exames.

5

1.3 OBJETIVOS

1.4.1- Objetivo Geral:

Este trabalho buscou desenvolver um sistema de informação para registro

eletrônico a saúde, com a finalidade de auxiliar os trabalhos clínicos de atendimento

no Hospital Municipal de Urgência e Emergência de Castanhal, Dra. Maria Laise

Pereira Lima, utilizando ambiente web;

1.4.2- Objetivos Específicos:

Possibilitar melhor controle e praticidade dos agendamentos das consultas,

exames, atendimentos de urgência e emergência no pronto Socorro

Municipal de Castanhal, através de um sistema web;

Disponibilizar e agilizar a emissão de receitas, exames e laudos médicos

através da impressão e geração de prontuários eletrônicos;

Permitir a criação de histórico das receitas, exames e laudos médicos

repassados ao paciente através do armazenamento em banco de dados;

6

CAPÍTULO 2- REFERENCIAL TEÓRICO

O estudo de Sistemas de Informação em saúde (SIS) está, ainda, evoluindo

no mundo e no Brasil. Desde o início, as publicações e pesquisas sobre os SIS

focaram a tecnologia em computação como o ponto central. Entretanto, Segundo

Giuse e Kuhn (2003), as excessivas orientações tecnológicas, no passado, em

detrimento da perspectiva social e do usuário, levaram a diferentes falhas nos

projetos; e, consequentemente, resultaram em fracasso na implantação do software.

Um sistema de informação (SI) na área da saúde necessita lidar com

aspectos de sobrecarga de informação, com comportamentos clínicos adversos; o

que resulta, em constantes alterações na estrutura e comportamento do SI. O

desenvolvimento de cuidados e serviços de saúde é um processo complexo que

envolve diferentes profissionais com diferentes perspectivas, diferentes

organizações e recursos físicos. O termo SI clínico está associado a uma

organização de saúde e é constituído por um conjunto de recursos humanos e

físicos e por um conjunto de aplicações de software que permitem recolher,

processar e distribuir informação clínica.

O principal propósito de um SI clínico é o incremento da qualidade dos

serviços de saúde. Segundo Littlejohns, Wyatt e Garvican (2003) existe um conjunto

de objetivos que um SI clínico deve facultar de modo a atingir o referido propósito:

Disponibilizar informação do paciente em todas as unidades de saúde,

principalmente nos hospitais centrais;

Disponibilizar ao paciente informação médica contextualizada com o seu

perfil de saúde, assim como informação sobre o seu estado clínico e

respectivo trajeto clínico;

Desenvolver mecanismos de acesso, distribuição e partilha de informação

médica aos diferentes agentes na área da saúde.

Incrementar o desempenho dos processos administrativos das unidades de

saúde, de modo a melhorar a qualidade e a monitorização dos serviços de

saúde.

7

Padronizar os serviços de gestão de pacientes e os procedimentos de gestão

em todas as unidades de saúde, principalmente nos hospitais públicos.

2.1- SISTEMA DE INFORMAÇÃO APLICADO A HOSPITAIS

A utilização de Sistemas de Informação em hospitais evoluiu

significativamente, partindo de uma realidade em que os computadores eram

empregados somente para operar tarefas simples e isoladas, até a integração global

das informações, por intermédio de um sistema único. Segundo Johanston (1993),

um Sistema de Informação hospitalar é definido como um sistema computadorizado

que, instalado em um ambiente hospitalar, objetiva registrar informações sobre os

pacientes de tal forma que possam ser compartilhadas por todos os setores do

hospital que delas necessitem.

A área de abrangência do Sistema de Informação hospitalar pode ser

subdividida em duas: Área clínica ou Assistencial e Administrativa. Segundo Sigulem

(1997), por um período de 30 anos (1960–1990), a função primordial dos

computadores, dentro das instituições hospitalares, eram facilitar a geração de

documentos indispensáveis para o reembolso do atendimento de pacientes e, com o

passar do tempo, foi utilizado para automatizar a produção de relatórios. Hoje, os

administradores podem ter acesso aos recursos necessários para administração e

gerenciamento do hospital por meio da utilização de sistemas de informação.

Os sistemas de informação hospitalares que antes tinham foco apenas

administrativo estão mudando seu foco, tornando-se clínico-administrativos,

executando entre outros serviços, gerenciamento da farmácia, laboratórios, nutrição,

faturamento, ambulatório, financeiro etc.

Dentre os sistemas aplicados à gestão clínica dos hospitais está o chamado

prontuário eletrônico do paciente (PEP). Segundo Bianchini et al.(2002), o PEP pode

ser reconhecido como um sistema utilizado para informatizar o histórico do paciente.

Seu objetivo principal é permitir a integração dos sistemas departamentais. Deve

prover ao médico informações imediatas e de simples entendimento a respeito das

8

condições de saúde atuais e passadas do paciente, com a finalidade de permitir uma

adequada assistência.

De acordo com publicação do Departamento de Informática em Saúde da

Universidade Federal de São Paulo (Unifesp), o PEP armazena informações

relacionadas com a saúde da pessoa, utilizando recursos computacionais,

organizadas por um identificador único do paciente. Essas informações deveriam

representar todos os eventos relacionados à saúde do indivíduo, desde o

nascimento até a morte. Pode ser entendido de uma forma clara e simples como a

transcorrência das informações do papel para um Sistema de Informação.

2.2- FUNDAMENTOS CONCEITUAIS

Para a análise da problemática do Hospital Municipal de Urgência e

Emergência de Castanhal; empregou-se, a metodologia de análise orientada a

objetos com UML (ver capítulo 5, página XXX). A modelagem do banco de dados se

baseou no Modelo Entidade Relacionamento e a arquitetura de modelagem MVC.

Por isso, faz-se necessário, um aprofundamento conceitual dos princípios que

norteiam esses tipos de modelagens para o desenvolvimento de sistemas de

informação.

2.2.1- Análise orientada a objetos

Atualmente, a forma mais moderna de abordagem no desenvolvimento de

sistemas é a Análise e Projeto Orientado a Objetos (Object-Oriented Analysis and

Design - OOAD). Rumbaugh (1994) define orientação 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

9

estrutura e comportamento em uma única entidade". Dizer que um software é

orientado a objetos significa que ele é organizado como uma coleção de objetos

separados, que incorporam tanto a estrutura como o comportamento dos dados. A

Orientação a Objetos (OO) trouxe vários novos conceitos ao desenvolvimento de

software, como: Abstração, Encapsulamento, Objeto, Classe, Atributo, Operação,

Método, Mensagem, Evento, Interface, Generalização, Herança e Polimorfismo

(Jacobson et al., 1996; Furlan, 1998; Fuzion, 1999).

A abordagem orientada a objetos possibilita uma melhor organização,

versatilidade e reutilização do código fonte, o que facilita atualizações e melhorias

nos programas. Dessa forma, o enfoque OO procura analisar um sistema como uma

coletânea de objetos que interagem entre si, com características próprias,

representadas por atributos (dados) e operações (processos). Segundo Correia e

Tafner (2006), os princípios que regem a orientação a objetos são definidos como:

a) Classe: mostra o comportamento dos objetos, através de métodos, sendo

capaz de manter, através de atributos. Exemplo: os seres humanos;

b) Objeto: é a instância de uma classe, ou seja capaz de armazenar estados(são

os valores que cada atributo recebe) e atributos, assim como relacionar e

enviar mensagens, para outros objetos. Exemplo de objetos da classe

Humanos: João, José, Maria;

c) Atributos: características de um objeto. Estrutura de dados que representa a

classe. Exemplos: Funcionário: nome, endereço, telefone, CPF;

d) Métodos: definem as capacidades dos objetos. Por exemplo, Beto é uma

instância da classe Cachorro, portanto ele tem habilidade para latir, através

do método deUmLatido(). Numa classe o método é apenas uma definição. A

ação só vai ocorrer quando o método for invocado através do objeto, que no

caso é o cachorro Beto. Basicamente, uma classe possui vários métodos, que

no exemplo da classe cachorro poderiam ser, senta, come e morde;

e) Mensagem: chama o objeto para inovar um de seus métodos, ativando o

comportamento de sua classe. Podendo ser também diretamente direcionada

a uma classe (através de um método estático);

f) Herança: é o mecanismo que permite uma classe (sub-classe), pode estender

outra classe (super-classe), aproveitando os seus comportamentos (métodos)

10

e variáveis (atributos). Pode ser definida como um relacionamento do tipo “é

um”;

g) Associação: é utilizada para que um objeto utilize os recursos de outros. Em

todo caso pode se tratar de uma associação simples como: “usa um” ou de

uma interação “parte de ”. Exemplo: Uma pessoa usa o telefone. Onde a tecla

“1” faz parte do telefone;

h) Encapsulamento: é a separação dos aspectos internos e externos de um

objeto. É utilizado um mecanismo que impede o acesso direto do estado do

objeto (atributos), apenas disponibilizando os métodos que alteram seus

estados. Exemplo: não precisa conhecer o que se passa dentro do circuito de

um telefone para usá-lo e sim a interface onde vou acessar (os botões, o fone

e o sinal);

i) Abstração: tem a característica 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 abstração

existente no domínio de sofware;

j) Polimorfismo: é usado como referências de classes mais abstratas, tornando

a aplicação mais clara, podendo também representar uma interface bem

abstrata. O polimorfismo é originário do grego, (poli = muitas e morphos =

formas) significado “muitas formas”.

2.2.1- Programação orientada a objetos

Correia e Tafner (2006) esclarecem que a Programação Orientada a Objeto

tem como meta utilizar estruturas de dados que determina o comportamento dos

objetos para facilitar a programação. Os objetos são implementados para a

funcionalidade do sistema, a grande vantagem da Orientação 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 código pode ser usado por

diferentes sistemas.

11

Os Benefícios da Orientação a Objetos [...] estão se tornando cada vez

mais popular entre os desenvolvedores de sistema. Essa popularidade

não é fruto do acaso ou da ‘’moda’’, e sim das vantagens de que os

desenvolvedores passam a usufruir quando adotam a metodologia da

Orientação 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 implementação do código evitando o trabalho extra

de reescrita e a cada mudança no sistema que levaria projetos mais lentos com

custos de manutenção mais altos, permite a comunicação, organização da

documentação do sistema quando a idéia é trabalhar orientado a objeto. Tornou-se

um padrão 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 métodos de

análise e projeto orientado a objetos (OOA& D) que surgiu no final dos

anos oitenta e no início dos anos noventa. Mais especificamente, ela

unifica os métodos de Booch, Rumbaugh OMT (Object Modeling

Technique) e Jacobson, mas o seu alcance é bem maior. UML passou

por um processo de padronização pela OMG (Object Managment Group)

e é agora um padrão OMG..( FOWLER; SCOTT, 2000, p.19)

O objetivo da UML é prover uma linguagem padrão que permita modelar um

sistema, bem como visa dotar o mercado mundial de orientação 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 é possível (Mattiazzi, 1998): descrever eficazmente requisitos de

software, caracterizar a arquitetura (lógica e física) de um sistema, focalizar na

arquitetura em vez da implementação e direcionar programadores, aumentando a

produtividade e diminuindo os riscos.

Segundo Furlan (1998), "a UML é uma linguagem de modelagem, não uma

metodologia". Assim, na construção de um software, a UML deve ser usada em

12

conjunto com uma metodologia de Engenharia de Software Orientada a Objetos, tais

como a metodologia Vincit, metodologia ágil e a RUP (Rational Unified Process).

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 operações, bem como a associação

entre cada uma delas (herança, generalização, composição, agregação, etc.);

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

atores e casos de uso;

Diagramas de Seqüência: tipo de diagrama de interação que apresenta a

interação de seqüência de tempo dos objetos que participam na interação;

Diagrama de Colaboração: tipo de diagrama de interação que mostra uma

interação dinâmica de um caso de uso e seus objetos relacionados;

Diagrama de Estado: utilizado para demonstrar as seqüências de estados

que um objeto assume em sua vida, em função do seu uso no sistema;

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

estados são ações. Descreve o fluxo interno de uma operação;

Diagrama de Componente: usado para representar os diversos componentes

dos sistemas e suas dependências;

Diagrama de Implantação: utilizado para demonstrar elementos de

configuração de processamento run-time;

13

CAPITULO 3 - HOSPITAL MUNICIPAL DE CASTANHAL

O Hospital Municipal de Urgência e Emergência de Castanhal (HMC), Dra.

Maria Laise Pereira Lima, localizado em Castanhal- PA, dispõe de XXX m2

construída, com XXX leitos, XXX para internação e XXX para observação, além de

um centro cirúrgico, composto de XX salas, ambulatório, emergência e demais áreas

de apoio. Dispõe, ainda, de laboratório de análise clínicas, serviços de radiologia, de

atendimento psicológico e de assistência social.

Desde sua inauguração, em XXX, o HMC é uma unidade vinculada à

Secretaria Municipal de Saúde de Castanhal, com regime orçamentário vinculado à

Prefeitura Municipal de Castanhal. Desde xxx, o Planejamento Estratégico é

utilizado como ferramenta de Gestão é utilizado como ferramenta de gestão e definiu

para o biênio XXX a seguinte missão: Receber pacientes vítimas de agressões

externas emergências clínicas ou cirúrgicas, garantido um atendimento inicial de

excelência, compartilhando a assistência integral com as demais instituições do

município ou da microrregião. E o perfil: Hospital de pacientes agudos, com ênfase

no atendimento de vítimas de trauma.

O serviço de urgência e emergência do HMC recebe em média XXX

usuários a cada dia. A estrutura física é composta por: Sala de Politraumatizados,

sala de sutura, sala de traumatologia, sala de observação e consultórios médicos

adultos e pediátricos. A equipe é constituída de quatro médicos emergenciais, dois

médicos pediatras, três enfermeiras, quartoze técnicos de enfermagem...tr~es

recepcionista, tr~es seguranças......

O processo de atendimento do HMC, inicia-se, na recepção, onde são

realizados o acolhimento do paciente, agendamento de consultas ou de exames

( ver figura 5.1, página xxx, capitulo 5). Para o Ministério da Saúde ( Brasil, 2004), o

acolhimento é uma ação tecnoassistencial que visa atender todos os que procuram

os serviços, acolhendo, escutando e pactuando respostas adequadas aos usuários.

Dessa forma, o acesso dos pacientes ao serviço hospitalar de urgência e

emergência do HMC se faz por demanda espontânea por meio de Serviços Pré-

Hospitalares de Urgência e Emergência (SAMU, Corpo de Bombeiros e pré-

hospitalar móvel privado). Os pacientes demandados de Serviços Pré-Hospitalares

Móveis de Urgência e Emergência podem ser pré-classificados, dependendo do

contato prévio da regulação médica. Os pacientes pré-classificados podem ter

14

acesso direto à sala de reanimação de pacientes graves. Os demais pacientes

deverão passar pelo processo de Acolhimento com Classificação de Risco.

O município de Castanhal/PA encontra-se em localização estratégica onde

perpassa a BR- 316 sendo ele referencia da Região de Saúde Metropolitana III com

cobertura atualmente de mais de 35 municípios sejam oriundos dos municípios

pactuados na PPI ou de demanda espontânea de outros considerando que as urgências

médicas caracterizam-se como um dos maiores problemas no contexto do funcionamento

do Sistema Único de Saúde. O Plano Estadual de Atenção às Urgências do Pará- PAR-

RUE/PA aprovado pela Portaria nº 1.649 de 02/08/2012 concebido para atuação no

quadriênio 2012/2015 é uma proposta de reorganização das ações e serviços e junto a

implantação e implementação da rede de urgência e emergência organizando o fluxo dos

pacientes no sistema desde as Unidades Básicas de Saúde passando pelos cuidados pré-

hospitalar hospitalar e pós-hospitalar representado pela atenção domiciliar. O Hospital

Municipal de Urgência e Emergência 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 urgência e emergência com atendimento ininterrupto nas 24 horas durante os

7 dias da semana sendo necessário realizar adequações com reforma e ampliação para

dar continuidade e garantir a qualificação dos serviços hoje ofertados a população.

15

CAPITULO 4- TECNOLOGIAS

Segundo Costa (2011, p.19) “Quando se pretende desenvolver uma

aplicação informática, a escolha das tecnologias a usar é uma das

decisões mais importantes a realizar no planeamento do desenvolvimento

da aplicação”. Contudo, esse processo acaba sendo complexo e difícil. Isso

porque é complicado afirmar que existe uma escolha ideal para resolver um

problema; já que, no mercado de tecnologia da informação, existem uma variedade

enorme de opções com características semelhantes; e, que, dificilmente atendem

todas as necessidades e particularidades para construção e manutenção da

aplicação.

Porém, 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. Análise aprofundada dos objetivos e pré- requisitos da aplicação, de

forma a perceber quais as características tecnológicas são mais

importantes no produto final;

II. O contexto da aplicação, ou seja, suas restrições, especificações de

acesso e armazenamento de dados, condições de integração com

outras aplicações, etc.;

III. Experiência do programador em desenvolver aplicações recorrendo a

determinadas tecnologias.

4.1 APLICAÇÕES WEB

Uma das principais questões que se colocam atualmente ao planear o

desenvolvimento de uma aplicação é a escolha do paradigma de funcionamento,

sendo que neste contexto surge a opção entre duas vertentes: as aplicações Web e

as aplicações Desktop.

As aplicações tradicionais instaladas no sistema operativo do utilizador

foram durante muitos anos a única opção para o desenvolvimento de aplicações.

16

Estas aplicações Desktop continuam a ser utilizadas, principalmente, devido ao

aproveitamento completo das potencialidades do hardware disponível na máquina

do utilizador, tanto a nível de processamento como a nível gráfico. Outro aspeto que

continua a ser favorável é o total controlo sobre o aspeto final da aplicação no ecrã

do utilizador. (Dearle, 2007).

Apesar das suas vantagens, uma aplicação Desktop pode não ser a solução

mais indicada. Isto devido à necessidade de instalação, necessidade de esforço

extra para realizar atualizações, dependência do sistema operativo para o qual é

criada, ou devido à complicada integração com utilizadores remotos (Rossi

et al., 2008).

A Web por seu turno, tem evoluído a um ritmo que seria

impensável quando em 1991 foram publicados os primeiros documentos

com a intenção de partilhar informação e investigações científicas. Desde

então, em menos de 20 anos, tornou-se uma ferramenta indispensável

para a maioria das pessoas e empresas. De uma Web que fornecia

informação sobre produtos e serviços através de um conjunto de websites

estáticos que apenas podiam ser consultados pelos visitantes, passou-se a

uma Web centrada no utilizador, sendo este o principal responsável pelo

conteúdo de cada página que visualiza, seja através das suas preferências

como através da partilha da sua própria informação.

Este novo modo de funcionamento, juntamente com um forte

componente interativa, levou à designação de Web 2.0. Esta forma mais

dinâmica e interativa de utilizar a Web foi em grande parte impulsionada

pela habilidade criar páginas Web recorrendo a conteúdo armazenado em

bases de dados (Rossiet al., 2008; Sven et al., 2009).

A melhoria funcional e estética das aplicações 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 aplicações Web com este tipo de

tecnologia são descarregadas por completo para o Browser do cliente, que

as executa localmente. Para além de fazer com que a aplicação seja

pesada para a máquina do cliente, o maior problema das tecnologias que

permitem o processamento do lado do cliente é facto de não serem

17

suportadas de igual modo por todos os Browsers e sistemas operativos

(Sven et al., 2009). É principalmente por estas razões que surgem

tecnologias Web, tais como ASP, PHP, Java EE ou ASP.NET, que levam o

processamento para o lado do servidor. Em aplicações que usam este tipo

de tecnologias, todo o código é executado do lado do servidor, e quando a

sua execução termina, é enviada para o utilizador uma página HTML

normal que pode ser visualizada em qualquer Browser (Rossi et al., 2008).

A Figura 4 demonstra as diferenças entre os modelos de processamento

no cliente e no servidor.

Figura 4- Diferenças entre a execução de código do lado do servidor (a) e do lado docliente (b) (adaptado de Macdonald, 2009)

Um dos maiores impulsos dados ao crescimento da utilização de aplicações

Web foi o aparecimento do conceito de Rich Internet Applications (RIA), que se

refere a aplicações Web independentes da plataforma, que são executadas no Web

Browser do utilizador, não necessitando de instalação, mas que ainda assim

apresentam características e funcionalidades semelhantes às aplicações

tradicionais. O conceito de RIA representa a evolução do Browser de uma interação

estática “pedido – resposta” para uma interação dinâmica e assíncrona. Este tipo de

aplicações é orientado à usabilidade e interatividade que normalmente falhava nas

aplicações tradicionais ( Busch e Koch, 2009).

18

Assim, apesar do domínio das aplicações Web que efetuam o

processamento de código no servidor, a programação 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

características de cada um deles (Rossi et al., 2008). Um exemplo da

junção destas tecnologias é a inclusão das potencialidades do AJAX como

extensão à plataforma ASP.NET.

Com os avanços nas tecnologias que permitem uma interação natural e

fluente entre o utilizador e a interface da aplicação Web, estas aplicações parecem

aproximar-se das aplicações tradicionais em quase todos os aspetos. Assim, as

aplicações Web perfilam-se como o futuro para a realização da maioria das nossas

tarefas, através da exploração de vantagens como a facilidade de utilização, a

independência da plataforma usada pelo utilizador, ou a menor quantidade de

recursos exigidos à máquina do utilizador (Jazayeri, 2007).

As aplicações na Web são denominadas multicamadas. Primariamente, três

camadas se destacam, estando sempre presentes em qualquer aplicação Web

(Safran e Goldberg, 2000):

1. Camada de apresentação: também denominada de "interface com o

usuário", esta camada utiliza, em geral, um browser na internet para interpretar as

páginas HTML oriundas do servidor.

2. Camada middleware: também denominada de "objetos e programas server-

side", a segunda camada é responsável pelo processameno do sistema, recebendo

as solicitações do usuário e interagindo com o banco de dados. O retorno das

informações aos usuários são na forma de páginas HTML.

3. Camada de banco de dados: é a camada onde as informações serão

armazenadas.

No caso do SRC para o HMC, optou-se por uma aplicação web. Dessa

forma, esse sistema deve se basear na arquitetura em três camadas. Sendo assim,

a seguir irá se exemplificar sobre cada uma das tecnologias utilizadas em cada

camada para o desenvolvimento dessa aplicação.

19

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 série de facilidades para a integração com a internet.

A Linguagem Java é de alto nível, orientada a objetos, simples, portável, de

arquitetura neutra, distribuída, de alto desempenho, interpretada, que dá suporte a

paralelismo e concorrência, com coletor de lixo, robusta, dinâmica e segura.

Os programas escritos em Java são executados por uma máquina virtual

Java, ou Java VM (Java Virtual Machine), que interpreta o código, e é independente

de plataforma.

4.3 ARQUITETURA J2EE

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

de aplicações distribuídas. Apresenta facilidades para a utilização dos recursos

computacionais e distribuídos tais como acesso a banco de dados, componentes

Web, utilização de mensagens assíncronas, execução de processos transacionais,

persistentes ou não etc.

A arquitetura J2EE apresenta uma API, especificada pela Sun

MicroSystems, que proporciona um padrão para a implementação dos diversos

serviços que oferecem, sendo que isto pode ser feito diferentemente por várias

empresas, de formas distintas mas ainda assim oferecendo as mesmas facilidades,

por estarem de acordo com as especificações impostas para a sua construção

(BOND et al, 2003).

4.3.1 VISÃO DA PLATAFORMA

A arquitetura J2EE se apresenta em várias camadas, sendo que cada uma é

composta por componentes e serviços que são providos por um container. Segundo

Temple (2004), pode-se entender como container o próprio navegador que fornece

20

recursos e facilidades para o componente, neste caso as páginas HTML. O

componente por sua vez, pode oferecer diversos serviços ao usuário, através do

suporte do containers, tais como facilidades visuais como botões, hiperlinks, figuras

e tabelas, e o próprio serviço de navegação. Em um servidor J2EE, podemos ter

diversos containers interagindo entre si.

A seguir uma breve explicação de cada camada da arquitetura e de seus

Componentes:

Camada cliente: acesso por meio de interfaces standalone (aplicações Java),

páginas 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 JSP’s e Servlets, que

fornecem a lógica para a camada cliente (ou de apresentação) do negócio.

JSP’s e Servlets residem no Web Container. JSP’s oferecem a facilidade de

utilizar algumas lógicas de apresentação em uma página Web sem muitas

dificuldades tecnológicas. O Servlet apresenta-se como um controlador das

ações executadas pelos usuários nas páginas de apresentação, e fornece

recursos para obter dados dessas ações e realizar as operações desejadas.

Camada de Negócios: esta camada trata da lógica de negócio da aplicação. É

nela que se implementa todas as regras de negócio, alocação de recursos,

persistência de dados, validação de dados, gerência de transações e

segurança, providos por componentes conhecidos por EJBs.

Camada EIS - Enterprise Information System, ou Sistema de informações

empresariais: nesta camada é que se encontram os sistemas de banco de

dados, sistemas legados, e a integração com outros sistemas que não são do

Padrão J2EE.

O desenvolvimento de aplicações em camadas torna o sistema mais

complexo na fase de análise e desenvolvimento, mas quando se trata da

manutenção os programadores de computador tem mais facilidades, pois cada

camada tem sua independência, embora integradas, conforme está ilustrador na

Figura 4.1.

21

Figura 4.1- Camadas, componentes, containers e sua iteração

Fonte: Bond (2003, p.1)

4.3.1 CAMADAS DA APLICAÇÃO

3.3. Camadas da AplicaçãoNo mundo do J2EE, existem geralmente quatro camadas: um cliente, umaaplicação Web construída ou com servlets Java ou com JavaServerPages (JSP),uma camada de lógica de negócio construída em Enterprise JavaBeans (EJB) e umacamada de persistência que acessa um banco de dados relacional (DESIGNPATTERNS, 2003).A Plataforma J2EE é basicamente um modelo de aplicação distribuído emmulticamadas no qual a lógica da aplicação é dividida em componentes de acordocom sua função. Isto permite que vários componentes da aplicação que compõemuma aplicação J2EE sejam instalados em máquinas diferentes.Os patterns a seguir propiciarão a melhoraria no desempenho de seussistemas em multicamadas e irão torna-los mais fáceis de se manter ao reduzir acomplexidade. Como todos eles estão relacionados ao particionamento daaplicação, esses são patterns essenciais para quase todas as aplicações J2EE ealtamente relevantes para todos os desenvolvedores. O pattern Model-View-Controller (MVC) reforça um projeto modular e de fácil manutenção e força aseparação de camadas. O session (EJB) organiza a lógica de negócio para o cliente.O Data Access Object (DAO) fornece uma interface flexível entre a lógica de negócioe as fontes de dados reais. Finalmente, o Data Transfer Object (DTO), tambémconhecido como um value object, facilita a comunicação entre as camadas.3.4. Aplicações em Três CamadasNeste modelo de três camadas, a lógica de apresentação está separada em

22

sua própria camada lógica. A separação em camadas torna os sistemas maisflexíveis permitindo que as partes possam ser alteradas de forma independente. Asfuncionalidades da camada de negócio podem ser divididas em classes e essasclasses podem ser agrupadas em pacotes ou componentes reduzindo asdependências entre as classes e pacotes; podem ser reutilizadas por diferentespartes do aplicativo e até por aplicativos diferentes. O modelo de três camadastornou-se a arquitetura padrão para sistemas corporativos com base na WEB.De acordo com Lautert e Oliveira (2004), a idéia do modelo MVC é facilitaras atividades de desenvolvimento de software, utilizando orientação a objetos edividindo os sistemas em três camadas: modelo (ou camada de negócios), visão (ouPPGEP – Gestão Industrial - 2005

apresentação) e controle, conforme Figura 4. Basicamente, esta visão buscadiminuir o tempo perdido com atividades repetidas em algumas etapas dodesenvolvimento de sistemas semelhantes. Desta forma, obtém-se um ganhosignificativo em produtividade, há uma redução na quantidade de erros durante oprocesso de desenvolvimento e melhora a manutenibilidade e suporte dos sistemas,incrementando a qualidade do produto final.Figura 3 Divisão do modelo MVC (Modelo 2)Fonte: Lautert e Oliveira (2004, p. 1).Os autores descrevem o modelo de forma a reduzir o acoplamento entre aspartes, e as dividem em:Camada de Controle: é a camada responsável pelo fluxo, qualidade esegurança das informações no sistema. É a ligação entre ascamadas de negócio e apresentação;Camada de Modelo: são as atividades relativas ao próprio negócio dosistema, como classes de persistência que conversam com a base dedados, "beans" da própria modelagem do sistema e suas relações;Camada de Visão: são os formulários, relatórios - a interface emgeral do sistema com os utilizadores. Elas mostram os resultadosgerados na camada de modelo. Geralmente utilizam tecnologiascomo JSP, HTML ou XSL.Na arquitetura MVC o modelo representa os dados da aplicação e as regrasdo negócio que governam o acesso e a modificação dos dados. O modelo mantém oPPGEP – Gestão Industrial - 2005

estado persistente do negócio e fornece ao controlador a capacidade de acessar asfuncionalidades da aplicação encapsuladas pelo próprio modelo.A tecnologia JSP foi projetada para ser flexível, mas a maneira como suaaplicação irá se comportar poderá ser realizada de diversas maneiras:Combinar livremente HTML e scriplets JSP.Combinar livremente HTML e scriplets JSP e delegar funcionalidadespara Servlets.Utilizar Servlets, páginas JSP e beans (distribuídos ou não) paraimplementar uma arquitetura do tipo MVC.A primeira abordagem, combinação de grandes quantidades de código Javacom HTML em páginas JSP, conduz, freqüentemente, a aplicações difíceis de seremutilizadas, mantidas e estendidas e, assim, portanto, não é recomendada pela Sun.Delegar funcionalidades para beans é uma abordagem viável, porque ocódigo Java passa a estar centralizado em estrutura de dados possivelmentereutilizável, a partir do momento que o mesmo é retirado das páginas de scripts JSP.Esta arquitetura é comumente conhecida como “Model 1” da Sun (GEARY, 2002).A última abordagem, a combinação de Servlets, páginas JSP e beans(classes de negócios da aplicação) em uma arquitetura MVC, resulta em umsoftware extensível e sustentável, porque encapsula funcionalidades e reduzirá o

23

impacto de futuras mudanças. Esta arquitetura de desenvolvimento, conhecida pelaSun como “Model 2” , é análogo ao padrão arquitetural MVC (GEARY, 2002).Figura 4 Modelo MVC para Aplicações WebPPGEP – Gestão Industrial - 2005

A Figura 4 mostra o diagrama de seqüência para o Padrão MVC no caso deum Cliente HTML. O Controlador recebe a requisição do Navegador e realiza a açãocorrespondente no Modelo. Em seguida, ele escolhe a Visão a ser exibida. A Visãoobtém os dados necessários do modelo e a página HTML gerada é exibida nonavegador.3.5. Camada de Controle3.5.1. StrutsEm uma definição breve, struts é um framework que implementa o modeloMVC. Explicando melhor, JavaServlets foram criados para lidar com os requestsfeitos pelos browsers. Páginas JSP foram criadas para criar conteúdo dinâmico paraexibição. Struts é um framework que através de um servlet especial lê um arquivoXML de configuração, e assim envia os requests primeiramente a uma classe Javaque tratará esse request, realizando toda a lógica do negócio, e logo após chamauma página JSP que tratará de exibir a página para o navegador. Desta maneira,aplicações WEB tornam-se mais fáceis de serem projetadas, criadas eespecialmente, mantidas.A sua principal característica é prover uma camada de controle flexívelbaseada em padrões de tecnologia já bem estabelecidos, Struts. Entre astecnologias usadas pelo framework, estão: Servlets, JavaBeans e XML (eXtensibleMarkup Language - Linguagem de Marcação Extensível) (BITTENCOURT, 2004).Segundo Souza (2004), o Struts provê a sua própria camada de controle,bastando que as classes da aplicação estendam a classeorg.apache.struts.action.Action para que elas executem o processamento desejado.Para a configuração do fluxo da aplicação, deve-se construir um arquivo (strutsconfig)no formato XML definindo quais ações devem ser mapeadas para os objetosresponsáveis. Essa facilidade permite que todo o fluxo do sistema permaneçaseparado do código-fonte.Para auxiliar na criação das páginas JSP, existe a taglib que faz parte dadistribuição do framework. As tags que compõem essa taglib possuem funções quepermitem desde a criação de formulários até a renderização de erros provenientesda camada de controle.PPGEP – Gestão Industrial - 2005

Struts tem o objetivo de gerenciar uma aplicação. Para tanto, configura-se nodescritor da aplicação (o arquivo WEB-INF/web.xml) que a classe ActionServlet dostruts irá receber as requisições do browser através do comando /do/. Nesse mesmoarquivo configura-se um ou mais arquivos que servirão de configuração ao struts. NaFigura 5, é representado o funcionamento do struts.Figura 5 Funcionamento do struts.Fonte: Costa et al (2004, p.15).3.6. Camada de Modelo3.6.1. OJBObject-Relational Java Bridge (OJB) é um framework que implementapersistência objeto/relacional para Java, permite desenvolver classes persistentesem Java. O OJB permite que objetos sejam manipulados sem a necessidade deimplementar nenhuma interface em especial ou estender alguma classe específica.A biblioteca dá suporte a cenários cliente-servidor (aplicações distribuídas) oustandalone, de forma que é possível utilizar a API OJB para persistência de objetosmesmo em ambientes J2EE (Entity Beans utilizando Bean-Managed Persistence).PPGEP – Gestão Industrial - 2005

24

3.6.2. Pattern DAOO DAO (Data Access Object) é utilizado para encaplusar a lógica de acessoa dados. Assim, se for necessário a alteração de banco de dados, não é necessárioalterar todo sistema, mas somente os DAOs.Dentro do DAO são realizadas as consultas ou o acesso aos métodos doOJB. A intenção real de existência dos DAOs é que eles não possuam nenhumalógica de negócio, apesar de algumas vezes ser necessário encaplusar algo dentrodeles, especialmente quando outros patterns da camada de modelo não estãopresentes (LAUTERT e OLIVEIRA, 2004).Quando utilizado junto com OJB, ambos realizam o trabalho de abstrair abase, pois o OJB já mascara o tipo do banco de dados, ficando para o DAO a partede controlar as conexões, exceções, retornos para os níveis superiores, entre outros.O Framework OJB, tem a funcionalidade de mapear via objetos XML, osatributos de uma base de dados PostgresSQL. Uma classe DAO, irá possuirimplementação referente à utilização deste Framework para persistir, recuperar eatualizar os dados provenientes de uma requisição de uma regra de negócio.Depois que a regra de negócio, propriamente dita, for executada, é a vez deuma classe “DAO” (Data Access Object) entrar em ação. Ela deverá pegar o objetoque recebe como argumento e saber tratá-lo de acordo com os métodos de negócioque foram invocados na regra de negócio.Figura 6 Diagrama de seqüência DAO.PPGEP – Gestão Industrial - 2005

Nesta situação, uma requisição é feita antes dos dados chegarem à regra denegócio da aplicação, ela passa por uma ação específica, um Action que iráidentificar qual Business Delegate está associada com aquela requisição (Figura 6).3.6.3. Value ObjectOs Value Objects trabalham coletando conjuntos de informaçõesrelacionadas em um único objeto. Este objeto pode ser transferido do EJB para ocliente com uma única chamada remota. Em vez de fazer chamadas separadas parareceber nome, endereço e formas de pagamento, o cliente pode receber um objetocontendo tudo em uma única chamada. Já que cada chamada na rede podeadicionar uma fração de segundo ao tempo que ela gasta para executar umaatividade, reduzir este overhead é geralmente o mais efetivo melhoramento dedesempenho possível para uma aplicação J2EE.Um objeto que pertencente ao Value Object tem como principal funçãomapear os dados digitados pelos clientes em uma aplicação e posteriormentetrafegá-los pela rede, confrontando-se com as mais diversas camadas da aplicação.Um Value Object é popularmente conhecido como “VO”, ele deve ser constituídoapenas com atributos e métodos de acesso.3.6.4. Pattern EJBEnterprise Java Beans (EJB) é uma arquitetura para componentes no ladoservidor que possibilita e simplifica o processo de construir aplicações de objetosdistribuídos em Java. Usando EJB, pode-se escrever aplicações escaláveis,robustas e seguras sem escrever sua própria infra-estrutura complexa para objetosdistribuídos. EJB é um ambiente de desenvolvimento rápido para aplicações do ladodo servidor; pode-se rápida e facilmente construir componentes do lado do servidorem Java através de uma infra-estrutura de objetos distribuídos provida pela indústria.EJB é desenvolvido para prover portabilidade e reusabilidade qualquer que seja ovendedor de serviços corporativos da camada do meio, ou seja, da middlleware.O principal objetivo do EJB é administrar os objetos de negócio (incluindo osDAOs), e fornecer uma camada padrão para acesso a camada de modelo, definindouma interface de alto nível aos subsistemas da aplicação, facilitando assim seu uso.Quando utilizada juntamente com Struts, é chamada de dentro das Actions, e assim,

25

PPGEP – Gestão Industrial - 2005

essas duas classes formam a 'cola' entre a camada de modelo e a camada decontrole.Variação do EJB: em vez do EJB chamar método de negócios quechamariam DAOs, ele mesmo trata de chamar os DAOs e executar a lógica denegócio, eliminando assim mais um nível de abstração.Um enterprise beans pode conter um ou mais objetos Java porque umcomponente pode ser mais do que um simples objeto. Sem levar em consideração acomposição dos enterprise beans, os clientes do beans manipulam com umasimples interface do componente exposta para os clientes. Esta interface, assimcomo o enterprise bean propriamente dito, deve ser escrito conforme a especificaçãopara Enterprise Java Beans. A especificação requer que os beans declarem algunsmétodos requeridos, estes métodos permitem que o container EJB gerencie osbeans uniformemente, sem levar em consideração 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 requisição docliente a um bean pode resultar que um canal de bean seja executado.A implementação do sistema trabalha com o tratamento de objetos distribuídos,garantindo segurança, persistência, transações e confiabilidade para o sistema,onde os chamados Enterprise Java Beans (ENTERPRISE JAVA BEANS, 2003),componentes de negócio são registrados em um servidor J2EE.3.7. Camada ViewA camada View é feita através de páginas JSP, que contém a parte HTMLdas páginas e toda a lógica para exibição dos dados.Páginas JSP são como templates usados para produção automática deservlets. Escreve-se uma página HTML com alguns comandos Java, que sãotraduzidos em tempo de execução a um servlet com as seguintes propriedades:a. O texto HTML na página é convertido em comandos Java de escrita deHTML eb. os comandos Java na página são apenas copiados para dentro doservlet.PPGEP – Gestão Industrial - 2005

3.8. XML: (eXtensible Markup Language):O XML é um padrão para publicação, combinação e intercâmbio dedocumentos multimídia, desenvolvido pelo consórcio W3C (World Wide WebConsortium). Assim como outras linguagens de marcação, XML lida com instruçõesembutidas no corpo de documentos chamadas tags, que permitem a descrição dedados. XML tem como base, linguagens mais antigas como, SGML e HTML, ondeatualmente são empregadas na representação de estruturas de dados estruturadose semi-estruturados e seu intercâmbio na WEB.3.9. XSLUm documento XSL é um XML que consegue transformar um documentoXML em outros formatos de documentos (HTML, Texto, PostScrip e RTF), além depoder utilizar alguns elementos de estilo disponíveis. A linguagem XSL pode serutilizada para acrescentar aspectos de apresentação aos elementos de umdocumento XML. Desta forma, é possível criar múltiplas representações da mesmainformação a partir de vários documentos XSL diferentes aplicados a um únicodocumento XML.

3.2- Hibernat

26

O Hibernate é uma ferramenta de mapeamento objeto relacional de grande

aceitação entre os desenvolvedores de sistemas orientados a objetos.

Esta é uma ferramenta gratuita e é considerada uma das mais utilizadas por

especialistas da área. Toda a configuração do Hibernate é feita através de arquivos

em XML, os quais contem detalhes sobre o mapeamento de dados e detalhes sobre

as conexões com bancos de dados. Uma nova versão do Hibernate, o Hibernate

Annotations permite fazer anotações 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

configuração do Hibernate (FERNANDES, 2005).

O hibernate, portanto, consiste em um Framework de persistência para

aplicações Java de código aberto distribuído com a licença Lesser GNU Public

License (LGPL), possui versão .NET o NHibernate. Criado por desenvolvedores

Java no mundo e liderado por Gavin King. Com benefício de ser uma solução

madura, compatível com diversos bancos relacionais e servidores de aplicação, com

curva de aprendizado rápido e principalmente variedade na documentação, livros,

artigos, tutoriais, entre outros.

Sua principal função é 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 Anotações

nas classes conforme Figura 15. Com o HQL (Hibernate Query Language) uma

linguagem de consulta orientada a objetos, faz a recuperação das consultas por

meio de uma camada de cache eficiente (SILVA, A.G. da, 2005, p. 42).

27

Figura 3.2- Alto nível da arquitetura Hibernate

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

28

CAPÍTULO 5- ANÁLISE E ESPECIFICAÇÃO DO SISTEMA

5.1 MEDOLOGIA DE ANÁLISE

Segundo Larman (2007, p.29), “A análise enfatiza uma investigação do

problema e dos requisitos, em vez de uma solução. Por exemplo, se desejamos um

novo sistema online de comercialização, como ele será usado? Quais são suas

funções?”. Por isso, a análise acaba sendo um termo de significado amplo, melhor

qualificado como análise de requisitos ou investigação de requisitos.

Para a análise da problemática do Hospital Municipal de Urgência e

Emergência de Castanhal; empregou-se, a metodologia de análise orientada a

objetos. Segundo Richards e Castilho (2009) a abordagem orientada a objetos

possibilita uma melhor organização, versatilidade e reutilização do código

fonte, o que facilita atualizações e melhorias nos programas.

Dentro os motivos que levaram a adoção dessa metodologia,

destacam-se:

I. A necessidade de ter disponível uma visão mais contemplativa possível sobre

os problemas de agendamento de consultas, atendimento de internação hospitalar e

os fluxos de tarefas realizados pelos funcionários do hospital;

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

eletrônico a Saúde(SRES) para a realidade do Hospital Municipal de

Castanhal;

Portanto, a construção do SRC para o HMC ocorreu em três etapas:

Levantamento de requisitos: levantamento das necessidade, para a

construção de ums sistema que venha minimizar os problemas de

agendamento e registro de dados do paciente;

Modelagem: Interpretação dos requisitos levantados, bem como sua

tradução em especificações do sistema;

29

Implementação: Conversão das especificações do sistema em

código.

5.2 LEVANTAMENTO DE REQUISITOS

Nesta etapa foi realizado um levantamento das principais funcionalidades do

sistema para registro hospitalar, identificando seu modo de organização e

visualização de dados. Para isso, foi necessário o levantamento dos seguintes

fluxos:

1. Fluxo de Atendimento de urgência e emergência: Procurou rastrear a

sequência de eventos desde o momento que o paciente chega ao Hospital

Municipal até o momento que ele sai. Dentro os eventos, destacam-se:

recepção do usuário, acolhimento com classificação de risco, atividades de

médicos e enfermeiros na sala de poli- traumatizados e de observação; e, por

fim, internação ou alta do paciente.

2. Fluxo de agendamento de consultas:

3. Fluxo de agendamento de exames laboratoriais:

Na figura 5.1, é possível visualizar esses fluxos, detectado em pesquisa de

campo; através do diálogo direto com funcionários, enfermeiros e médicos que

prestam atendimento no HMC; o que permitiu, gradualmente, a construção do

seguinte organograma geral para ser utilizado para a criação do modelo do sistema.

A partir da análise do sistema, observou-se as seguintes rotinas:

I. Cadastrar Funcionários, enfermeiros, médicos, supervisores e salas;

II. Cadastrar a disponibilidade de horários para os atendimentos de

consultas e exames;

III. Agendamento de Consultas e exames;

IV. gerar relatórios.

30

31

Pacientes

Agendar Exames Agendar Exames

Receber AtendimentoAmbulatorial

Receber AtendimentoAmbulatorial

Cadastrar/ atualizar Paciente

Cadastrar/ atualizar Paciente

Gerar Prontuário

Gerar Prontuário

Abre uma FAHInforma o tipo de

atendimento

Abre uma FAHInforma o tipo de

atendimento

Registra na FAH o resultado da triagem e os

procedimentos realizados

Registra na FAH o resultado da triagem e os

procedimentos realizados

Setor de enfermagem

(Triagem)

Registra na FAH os dados do atendimento

Registra na FAH os dados do atendimento

Médico

LaboratórioClínico

Nutricionista

Psicólogo

ArquivaFAH

ArquivaFAH

InternaçãoHospitalar

Abre um AIH

InternaçãoHospitalar

Abre um AIH

TransferênciaTransferência

Declaraçãoóbito

Declaraçãoóbito

UrgênciaUrgência EmergênciaEmergência

Agendar consultasAgendar consultas

Classificação de risco

Recepcionista

Figura 5.1- Fluxo geral de atendimento Hospitalar

Para construção dos Registros Eletrônicos-Prontuários eletrônicos, foram

necessários, primeiramente, a definição do conjunto de informações que deveriam

estar presentes nesses documentos eletrônicos. Para isso, levou-se em

consideração as normas definidas pela resolução do Conselho federal de Medicina

Nº 1638/2002 e 1821/2007, a Cartilha da Sociedade Brasileira de Prontuário

eletrônico e, principalmente, os aspectos levantados pela Comissão de Revisão de

Prontuários no Hospital Municipal de Urgência e Emergência de Castanhal, Dra.

Maria Laise Pereira Lima.

A base das informações deve ser resultante dos atendimentos prestados

pelos diferentes profissionais da saúde no Hospital Municipal. O registro das ações

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 clínica, e agilizar as tarefas diárias como manipular e alterar, dados de prontuários, de cadastramento. Alem disso o sistema deve manter protegidas as informações pessoais de cada paciente, pois devido à existência de um código de ética da profissão que exercem os funcionários, terceiros não poderão ver as informações, pois muitas vezes podem trazer certo constrangimento ao paciente, e também não menos importante fazer o controle de reservas das salas para consultas de diversificados tipos de atendimento, e também salas de reuniões. O sistema deverá trazer mais praticidade para o dia a dia dos usuários, evitando que eles tenham de se preocupar com pilhas de arquivos, ou similar, aproveitando mais 12

32

o tempo para se dedicar a tarefas mais importantes, para assim melhorar os serviços prestados pela clinica.

Além disso, o Sistema irá trazer maior facilidade para os funcionários realizarem

as suas tarefas reduzindo o tempo com a procura de registros de pacientes e

proporcionar ao usuário maior praticidade na hora de efetuar os agendamentos, tanto de

consultas quanto de salas.

Este capítulo apresenta o sistema proposto e como este foi realizado. Consciente de queo sistema atual de marcação de consulta apresenta alguns problemas como centralizaçãodo serviço, ocasionando _las, propõe-se reformulá-lo. Esse projeto tem como principalobjetivo descentralizar a marcação de consultas dos Hospitais. Busca possibilitar que oagendamento de consultas seja feito de outras localidades além do próprio hospital, bemcomo permitir que de um mesmo local se possa agendar consultas em um conjunto dehospitais mais abrangente e disponibilizar mais informações aos pacientes.A construção do sistema consiste em três etapas:• Levantamento de Requisitos: Levantamento das necessidades, para a construção deum sistema que venha minimizar os problemas existentes.• Modelagem: Interpretação dos requisitos levantados, bem como sua tradução emespeci_cações do sistema.

• Implementação: Conversão das especi_cações do sistema em

código.

33

5.4 REQUISITOS FUNCIONAIS

5.4.1 Cadastros

a) O SRC deve permitir o cadastro de três tipos de usuários, interno ( Médico,

enfermeiro e funcionário) e web (paciente);

b) O SRC possui um usuário administrador pré- cadastrado com login e senha;

c) O usuário administrador deve ser capaz de manter o cadastro dos usuários

do tipo Médico e enfermeiro;

d) Os usuários do tipo médico devem possuir os seguintes atributos: nome, cpf,

sexo, data de nascimento, cidade, bairro, rua, número, estado, cep, telefone,

celular, e-mail, tipo de usuário, login, senha e CRM;

e) Os usuários do tipo enfemeiro devem possuir os seguintes atributos: nome,

cpf, sexo, data de nascimento, cidade, bairro, rua, número, estado, cep,

telefone, celular, e-mail, tipo de usuário, login, senha e CRE;

f) Os usuários do tipo interno devem ser capazes de manter, paciente com os

seguintes atributos: nome, cpf, data de nascimento, número do cartão do

SUS, cidade, bairro, sexo, rua, número, estado, cep, telefone, celular, e-mail,

tipo de usuário, login, senha e convênio;

g) Os usuários do tipo interno devem ser capazes de manter o cadastro de

agenda com os seguintes atributos: data, horário, motivo, anotação e

telefone;

h) Os usuários do tipo funcionário devem ser capazes de manter o cadastro da

ficha de anamnese com os seguintes atributos: medicamento, tipo sanguíneo,

doença, alergia, fumante e gestante;

i) Os usuários do tipo interno devem ser capazes de manter o cadastro das

ocorrências em cada consulta com os seguintes atributos: login do paciente,

login do dentista, data, hora do atendimento e anotações.

34

5.4.2 Controle de usuário

a) O SRC deve permitir o acesso pelo login e senha dos usuários do tipo interno

e web;

b) O sistema deve permitir a consulta dos usuários cadastrados, prevendo uma

pesquisa por nome;

c) O usuário interno deve ser capaz de emitir relatório de usuários cadastrados.

5.4.3 Controle de Anamnese

a) O SRC deve permitir a consulta da ficha de anamnese de cada paciente pelo

nome;

5.4.4 Controle de Agendamento

a) O usuário do tipo interno informa a disponibilidade da agenda de cada

dentista ao sistema;

b) Somente os horários previamente cadastrados como disponíveis e ainda não

agendados, devem ser disponibilizados para acesso aos usuários na web;

c) O usuário do tipo web já cadastrado pode visualizar o dia, horário e o nome

do dentista agendado;

d) O SRC deve permitir que o usuário web faça o agendamento somente uma

vez por semana;

e) O SRC deve permitir que o usuário interno faça o agendamento quantas

vezes forem necessárias;

f) O SRC deve permitir que o usuário interno deve ser capaz de emitir relatório

de: agendamento cadastrado por data, horários cadastrados e excluir

disponibilidade gerada.

5.4.5 Requisitos não funcionais - Portabilidade

35

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

operacionais Windows e Linux e deve ser capaz de ser executado

através dos navegadores web: Microsoft Internet Explorer, Mozilla Firefox

e Google Chrome;

b) O SRC deve ser executado em computadores Pentium IV ou superior.

36

CAPÍTULO 6- MODELAGEM DO SISTEMA DE REGISTRO

CLINICO

O grande desafio das equipes de desenvolvimento de aplicações é,

sobretudo, produzir aplicativos seguros, eficientes, de fácil manutenção, reutilizáveis

e em prazos cada vez menores. Por isso, devido os benefícios discutidos do

paradigma da orientação a objetos (ver capitulo 3), terem apresentado um grande

avanço nestes últimos tempos para o desenvolvimento de software ligados ao

campo da saúde; adotou-se esse padrão para o desenvolvimento do SRC para o

HMC.

Segundo Ranthum (2006, p.53) “O sucesso para o desenvolvimento de

aplicações com tecnologia orientada a objetos está intimamente associada a

arquitetura que vamos usar para construir a aplicação”. A tendência indica que está

arquitetura estará baseada na organização da aplicação em camadas e na

observação dos padrões utilizados pelo mercado.

A organização em camadas é a chave para a independência entre os

componentes; e, esta independência, é que vai atingir os objetivos de eficiência,

escalabilidade, reutilização e facilidade de manutenção.

Em um primeiro instante, produzir aplicativos multicamadas pode parecer

mais complexo. O termo camada pode significar uma separação física ou lógica. No

contexto de apresentação deste trabalho, a produção de software vai considerar

camada como uma referência à separação lógica de responsabilidades.

37

6.1- APLICAÇÕES EM TRÊS CAMADAS

Com o advento da Internet houve um movimento para separar a lógica de

negócio da interface com o usuário. A idéia é que os usuários da WEB possam

acessar as mesmas aplicações sem ter que instalar estas aplicações em suas

máquinas locais.

No modelo em três 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 código HTML para ser

exibido no cliente.

Figura 6.1- Aplicação em três camadas.

Fonte: MVC, 2004.

Neste modelo de três camadas a lógica de apresentação está separada em

sua própria camada lógica. A separação em camadas torna os sistemas mais

flexíveis permitindo que as partes possam ser alteradas de forma independente.

As funcionalidades da camada de negócio podem ser divididas em classes e

essas podem ser agrupadas em pacotes ou componentes, reduzindo as

dependências entre as mesmas e pacotes; podem ser reutilizadas por diferentes

partes do aplicativo e até por aplicativos diferentes. O modelo de três camadas

tornou-se a arquitetura padrão para sistemas corporativos com base na WEB, e é o

modelo escolhido para apresentação deste estudo.

O crescimento do POO ajudou a promover uma maior modularidade, pois os

objetos encapsulam seus dados (propriedades, métodos) e oferecem

38

funcionalidades através de seus métodos. Projetando-se de forma adequada os

objetos podem ter reduzido as dependências entre si, ficando assim fracamente

acoplados e serão mais fáceis de manter e evoluir.

O modelo de três camadas físicas (3-tier) divide um aplicativo, de modo que

a lógica de negócio resida no meio das três camadas físicas. Isto é chamado de

camada física intermediária ou camada física de negócios. A maior parte do código

escrito reside na camada de apresentação e de negócio.

A arquitetura MVC - (Modelo, Visualização, Controle) fornece uma maneira

de dividir a funcionalidade envolvida na manutenção e apresentação dos dados de

uma aplicação. A arquitetura MVC não é recente e foi originalmente desenvolvida

para mapear as tarefas tradicionais de entrada, processamento e saída para o

modelo de interação com o usuário. Usando o padrão MVC fica fácil mapear esses

conceitos no domínio de aplicações WEB multicamadas.

Na arquitetura MVC o modelo representa os dados da aplicação e as regras

do negócio que governam o acesso e a modificação dos dados. O modelo mantém o

estado persistente do negócio e fornece ao controlador a capacidade de acessar as

funcionalidades da aplicação encapsuladas pelo próprio modelo.

Um componente de visualização renderiza o conteúdo de uma parte

particular do modelo e encaminha para o controlador as ações do usuário;

acessando também os dados do modelo via controlador e definem como esses

dados devem ser apresentados.

O controlador define o comportamento da aplicação, é ele que interpreta as

ações do usuário e as mapeia para chamadas do modelo. Em um cliente de

aplicações WEB essas ações do usuário poderiam ser cliques de botões ou

seleções de menus. As ações realizadas pelo modelo incluem ativar processos de

negócio ou alterar o estado do modelo. Com base na ação do usuário e no resultado

do processamento do modelo, o controlador seleciona uma visualização a ser

exibida como parte da resposta a solicitação do usuário. Há normalmente um

controlador para cada conjunto de funcionalidades relacionadas.

A arquitetura de três camadas, que está representada na Figura 6.2, é uma

implementação do modelo MVC. O modelo MVC está preocupado em separar a

informação de sua apresentação.

39

Figura 6.2- Aplicando MVC em um modelo de três camadas

Fonte: MVC, 2004.

Camada de apresentação ou visualização - Não está preocupada em como

a informação foi obtida ou onde ela foi obtida, apenas exibe a informação.

Inclui os elementos de exibição no cliente: HTML, XML, ASP, Applets;

É a camada de interface com o usuário;

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

Camada de lógica da Aplicação - É o coração da aplicação. Responsável por

tudo que a aplicação vai fazer.

Modela os dados e o comportamento por atrás do processo de negócios;

Preocupa-se apenas com o armazenamento, manipulação e geração de

dados;

É um encapsulamento de dados e de comportamento independente da

apresentação.

Camada de Controle - determina o fluxo da apresentação servindo como

uma camada intermediária entre a camada de apresentação e a lógica de negócios,

responsável por controlar e mapear as ações.

40

41

6.2- ABORDAGEM DE DESENVOLVIMENTO

De acordo com a fase de criação da aplicação, 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 funções serão adicionadas

a cada ciclo, gerando uma nova versão do software permitindo um feedback mais

imediato do usuário.

Ciclo de Requisitos e Análise do sistema.

Ciclo Projeto/Modelagem.

Ciclo Implementação.

Ciclo Testes

6.2.1 CICLO DE REQUISITOS E ANÁLISE DO SISTEMA

Como foi discutido no capitulo 5, a análise de requisitos garante uma

estrutura de dados que atenda às necessidades dos usuários. Devido aos benefícios

da AOO- como: reusabilidade, manutebilidade, entre outros; empregou-se, essa

técnica para o desenvolvimento do SRC para o HMC.

Na área da saúde, e em especial no desenvolvimento de PEPs, a AOO tem

sido bastante utilizada, existindo várias publicações 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 reutilização de código, dentre outros pontos positivos (Seto, Kamiyama e

Matsuo, 1998).

6.2.2 CICLO DE PROJEÇÃO E MODELAGEM

Segundo Ranthum (2005, p.62) “A grande dificuldade de construção de

aplicações consiste no fato de que até 60% de todo o código produzido é destinado

a construção de interfaces e problemas de interação com o usuário. Por isso, o SRC

desenvolvido, seguindo a técnica de decisão de análise adotada no capitulo 5, AOO,

42

adotou o Design Orientado a Objetos (DOO), já que, essa técnica segue as mesmas

características da análise orientada objetos.

Através da DOO foi possível obter ferramentas de 4a geração, como as

ferramentas CASE, que combinadas com as técnicas da UML, permitiram a

modelagem (desenho) da aplicação. Além disso, essa abordagem permitiu

especificar, padronizar e documentar as entidades do sistema.

6.2.3 CICLO DE IMPLEMENTAÇÃO

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

orientada a objetos, portável, extensível e que abrange um grande número de

frameworks disponível no mercado para incrementar e especializar diversas tarefas

do projeto.

O paradigma OO foi utilizado tanto para fase de análise e especificação do

sistema, bem como para a fase de implementação. Isso poderá garantir, para o SRC

desenvolvido, confiabilidade de regra de negócio, escalabilidade da aplicação e

tratamento de objetos distribuídos.

6.2.3 CICLO DE TESTES

Técnicas de testes podem ser implementadas para assegurar que o software

está realmente em acordo com suas especificações e livre de erros. Testes de

unidade, testes de integração, testes de sistema e testes de instalação são

exemplos de técnicas que poderão ser utilizadas.

De acordo com as necessidades do projeto, testes de unidades serão

aplicados na fase de implementação do projeto. O teste de unidade, realizado

através do Framework Junit, será realizado de dois modos: Em Alfa-test: os testes

foram realizados pelos próprios desenvolvedores no ambiente de desenvolvimento e

em Beta-Tests, onde os testes serão realizados em um ambiente de execução pelos

próprios usuários do software.

43

CAPITULO 7 – IMPLEMENTAÇÃO

A implementação do sistema foi baseada nos padrões descritos a seguir, as

figuras que compões este capítulo foram extraídas de Matos (2005, p. 65 e 95), que

utiliza a técnica da UML de desenvolvimento e implementação de sistemas.

Padrões Arquiteturais

· MVC (Modelling View Controller).

44

REFERÊNCIAS BIBLIOGRÁFICAS

MASSAD, Eduardo. Prontuário Eletrônico do Paciente na Assistência,

Informação e Conhecimento Médico. Faculdade de Medicina da Universidade

Federal de São Paulo. 2003.

TRIANA, A. A semiologia biomédica e seus limites: desvendando o caminho

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

MARTINS, S. L. Prontuário Eletrônico do Paciente para Cardiologia e

Odontologia. Escola Politécnica de Pernambuco- Universidade de Pernambuco.

2009.

MEDICINA, Conselho Federal. Resoluções do CFM, 1331/89, 1605/00, 1638/02,1639/02, 1821/2007. Disponível em: <http://www.cfm.gov.br>.

COSTA, H. N.; ALVES, M. M., MARTINS, V. SCO - Sistema para clínica odontológica: gerenciamento de agendamento. 2010.88 f. Dissertação (Trabalho de Conclusão do Curso em Tecnologia de Sistemas para Internet)- Centro Universitário Católico Salesiano Auxilium, UNISALESIANO, São Paulo, 2010.

FERNANDEZ, Luiz Rafael . Construindo aplicações utilizando Thinlet eHibernate - Parte 02, Disponível 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 Objeto-Relacional. Jaguariúna: FAJ, 2005.

LARMAN, C. Utilizando UML e padrões: uma introdução à análise 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.. Futureof 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 Informação Hospitalar: presente e futuro. 1993. Revista Informédica, 1993;1(2):5-9. Disponível 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. Introdução à Informática em Saúde. São Paulo. Capítulo Introdutório da Tese de Livre-Docência: Um Novo Paradigma de Aprendizado na Prática Médica da UNIFESP/EPM. 1997. Disponível 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. Ministéio da Saúde. HumanizaSUS: acolhimento com avaliação e classificação de risco: um paradigma ético- estético no fazer em saúde. Brasília: Ministério da Saúde, 2004. Dsiponível em: http://bsvms.saude.gov.br/bvs/publicacoes/acolhimento.pdf. Acesso em: o2 de fev. 2015.UML. A unificação dos métodos para a criação de um novo padrão,[s.l.], 2001. Disponível em: <http://www.infotem.hpg.ig.com.br/lin_progr_uml.htm#aunificacao> Acesso em: 10 jan. 2015.

CORREIA, C.H.; TAFNER, M. A. Análise orientada a objetos. 2. Edição. 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):77–83.

Dolin, R.H. A high-level object-oriented model for representing relationship in anelectronic medical record. Proceedings of the Annual Symposium on ComputerApplication 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 através da UML. São Paulo: Makron Books, 1998.

Fuzion. Introdução a Orientação a Objetos. Rio de Janeiro, 1999. CD-ROM. E-book.

Mattiazzi, L.D. Orientação 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, Rogério Modelagem e implementação de um sistema de informação para otimização deexames de diagnósticos por imagens. / Rogério Ranthum. -- Ponta Grossa : UTFPR, Campus Ponta Grossa, 2006.

MVC, Web-Tier Application Framework Design. Disponível 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 em21 dias. São Paulo: MAKRON Books, 2003.

TEMPLE, A. Jsp, Servlets e J2EE (2004). Disponível em<www.inf.ufsc.br/~bosco/downloads/>. Acessado em: 2 de janeiro de 2015.

48