CENTRO ESTADUAL DE ENSINO TECNOLÓGICO “PAULA...

0

CENTRO ESTADUAL DE ENSINO TECNOLÓGICO “PAULA SOUZA”

FACULDADE DE TECNOLOGIA DE LINS CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS

ADRIANO OLIVEIRA CASTRO

SISTEMA DE GESTÃO PARA SALAS DE VACINAÇÃO

LINS/SP 1º SEMESTRE/2011

1

CENTRO ESTADUAL DE ENSINO TECNOLÓGICO “PAULA SOUZA”

FACULDADE DE TECNOLOGIA DE LINS CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS



Trabalho de Conclusão de Curso apresentado à

Faculdade de Tecnologia de Lins para obtenção

do Título de Tecnólogo em Banco de Dados.

Orientador: Prof. Me. Anderson Pazin

LINS/SP

1º SEMESTRE/2011

2



Trabalho de Conclusão de Curso apresentado à

Faculdade de Tecnologia de Lins, como parte dos

requisitos necessários para a obtenção do título de

Tecnólogo em Banco de Dados sob orientação do

Prof. Me. Anderson Pazin.

________________________________________

Orentador: Prof. Me. Anderson Pazin

________________________________________

João Luiz Cardoso de Moraes

________________________________________

Luiz Fernando de Oliveira Silva

3

As minhas duas mães Geni Chagas de O. Castro e Nadir

Cardoso de Lima. Aos meus dois pais que tive na vida e

sei que sempre estiveram junto de mim quando precisei

Antonio Emilio Castro, in memorian e Sérgio Luis

Aparecido de Lima, in memorian. Ao meu irmão que

tanto amo, Everton Henrique Oliveira Castro. A minha

amada noiva Juliana Indaya de Lima pelo

companheirismo e dedicação constante comigo.

4

AGRADECIMENTOS

Nesta oportunidade em que é alcançada uma meta importante na minha vida

profissional, quero expressar os meus sinceros agradecimentos a Secretaria de

Saúde de Lins, ao meu orientador Professor Me. Anderson Pazin, ao Professor Me.

Mario Henrique de Souza Pardo, a Diretora da Divisão de Vigilância Epidemiológica

do município de Lins, Enfermeira Carmen Lucia Budoia, pela sua amizade, apoio

irrestrito e ajuda tão necessária ao desenvolvimento e realização desse trabalho.

Ao diretor da faculdade Prof. Dr. Luciano que sempre quando solicitado por

mim, ou pela turma, nos recebeu com muito carinho e compreensão, ao Endrius e a

Daiane que aceitaram a loucura de serem membros da comissão de formatura

comigo, a Lívia que sempre me ajudou com as correções de grafia neste trabalho,

juntamente com a Profa. Me. Elaine e aos meus colegas de turma Pedro, Jose

Renato, Matheus, Brunna, Rodrigo e Rogério que sempre estiveram presentes neste

período tão importante da minha vida pessoal e profissional.

E por fim, tenho de agradecer a Deus que me deu essa oportunidade única na

minha vida profissional e pessoal, pois sem ele ao meu lado essa conquista não

seria possível.

5

RESUMO

Este trabalho tem como objetivo geral o desenvolvimento de um sistema para o controle específico das salas de vacinação no município de Lins, instituindo-se uma base de dados única na rede de Unidades Básicas de Saúde (UBS) de Lins. Estudos mostram que o município tem a necessidade de realizar a prevenção de doenças, através da vacinação, então fica evidente que é de suma importância o monitoramento fidedigno das vacinas que buscam evitar surtos incontroláveis. Dentre os objetivos específicos estão: criar um sistema gerencial consolidado com todas as informações necessárias para o controle vacinal de cada paciente das salas de vacinação das Unidades Básicas de Saúde; viabilizar mecanismos para o ganho de tempo e agilidade nos processos de controle de uma sala de vacinação; consolidar os dados de forma a unificar o controle vacinal da população em um só local. Inicialmente priorizou-se o levantamento dos dados necessários para a elaboração de um software que atendesse a demanda das unidades básicas de saúde. Após esse estudo, foi pesquisado quais tecnologias poderiam atender essa demanda, assim Java, Flex, BlazeDS, Hibernate e JasperReports, foram utilizadas para o desenvolvimento . O documento visão norteou a continuação do trabalho, auxiliando no desenvolvimento dos diagramas. Quanto à implantação e criação de um software específico para salas de vacinação, tornará o trabalho mais eficiente e abrangente, aumentando a cobertura, organização, qualidade da assistência, pois o modelo atual gera gastos desnecessários ao município. Palavras chave: Vacinação. Unidade Básica de Saúde. Flex, Hibernate. Blazeds

6

ABSTRACT

This work has as general objective the development of a system to the specific control for vaccination room of Lins, creating an unique data base on the Health Basic Unities network. Studies show the municipality has the necessity of put into practice the sickness prevention, through the vaccination, so it's evident that it's very important to monitor the vaccine that try to avoid an uncontrollable outbreak of epidemics. Among the specific objectives are: create a managing system consolidated with all informations necessary for each patient vaccinal control of Health Basic Unities vaccination room; feasible mechanisms to gain time and agility at a vaccine room process control; consolidate the data in a way to unify the population vaccinal control all in one place. First of all, the focus was the search of data necessary to elaborate a software that could supply the demand of a Health Basic Unity. After that, started the search of which technologies could attend this demand, like, Java, Flex, BlazeDS, Hibernate and JasperReports, were used to the development. The main document directed the work continuation, helping with diagrams development. For that matter, the implantation and creation of a specific software for vaccination room, will make the job more efficient and extensive, increasing the covered places, organization, attendance quality, because the present day model generates unnecessary expenses to the municipal district.

Keywords: Vaccine. Health Basic Unities. Flex. Hibernate. Blazeds

7

LISTA DE ILUSTRAÇÕES

Figura 1: Benchamark de desempenho do BlazeDS ................................................. 19 Figura 2: A arquitetura JPA em alto nível .................................................................. 21

Figura 3: Tela Inicial de gerenciamento do banco de dados PostgreSQL ................. 23 Figura 4: Diagrama de caso de uso .......................................................................... 33 Figura 5: Diagrama modelo entidade relacionamento ............................................... 38 Figura 6: Diagrama de atividade – Controlar estoque ............................................... 39

Figura 7: Diagrama de atividade – Consultar histórico vacinal .................................. 39 Figura 8: Diagrama de atividade – Efetuar aplicação vacinal .................................... 40 Figura 9: Diagrama de atividade – Gerar Relatórios ................................................. 40 Figura 10: Diagrama de atividade – Manter Clientes ................................................ 40

Figura 11: Diagrama de atividade – Manter endereços ............................................. 41 Figura 12: Diagrama de atividade – Manter funcionários administrativos ................. 41 Figura 13: Diagrama de atividade – Manter funcionários enfermagem ..................... 41 Figura 14: Diagrama de atividade – Manter insumos ................................................ 41

Figura 15: Diagrama de atividade – Manter unidades ............................................... 42 Figura 16: Diagrama de atividade – Manter usuários do sistema.............................. 42

Figura 17: MVC – Controlar estoque ......................................................................... 42

Figura 18: MVC – Consultar histórico vacinal............................................................ 43 Figura 19: MVC – Efetuar aplicação vacinal.............................................................. 44 Figura 20: MVC – Gerar relatórios ............................................................................ 45

Figura 21: MVC – Manter clientes ............................................................................. 45 Figura 22: MVC – Manter endereços ........................................................................ 46

Figura 23: MVC – Manter funcionários administrativos ............................................. 46 Figura 24: MVC – Manter funcionários enfermagem ................................................. 47 Figura 25: MVC – Manter insumos ............................................................................ 47

Figura 26: MVC – Manter pedidos de insumos ......................................................... 48 Figura 27: MVC – Manter unidades ........................................................................... 48

Figura 28: MVC – Manter usuários do sistema ......................................................... 49

Figura 29: Diagrama de sequência – Controlar estoque ........................................... 50 Figura 30: Diagrama de sequência – Consultar histórico vacinal .............................. 51

Figura 34: Diagrama de sequência – Manter endereços ........................................... 55 Figura 35: Diagrama de sequência – Manter funcionários administrativos ............... 56 Figura 36: Diagrama de sequência – Manter funcionários enfermagem ................... 57

Figura 37: Diagrama de sequência – Manter insumos .............................................. 58 Figura 38: Diagrama de sequência – Manter unidades ............................................. 59 Figura 39: Diagrama de sequência – Manter usuários do sistema ............................ 60 Figura 40: Menu do sistema ...................................................................................... 62 Figura 41: Tela de gerenciamento de clientes........................................................... 63

Figura 42: Tela de gerenciamento de profissionais ................................................... 64

Figura 43: Tela de gerenciamento de insumos ......................................................... 64

Figura 44: Tela de cadastro de histórico vacinal ....................................................... 65 Figura 45: Tela para atendimento de vacinação ....................................................... 65 Figura 46: Tela para lançamento de estoque ............................................................ 66 Figura 47: Relatório de espelho vacinal .................................................................... 67

8

LISTA DE QUADROS

Quadro 1 – O Problema da empresa. ....................................................................... 26 Quadro 2 – Posição do produto. ................................................................................ 27

Quadro 3 – Responsabilidades dos cargos. .............................................................. 27 Quadro 4 – Necessidades e recursos. ...................................................................... 30

9

LISTA DE ABREVIATURAS E SIGLAS AMF – Action Message Format (Formatação das Ações por Mensagens)

API – Application Programming Interface (Interface de Programação de Aplicações)

IDE – Ambiente Integrado de Desenvolvimento

JPA – Java Persistence API (API de Persistência Java)

JPQL – Java Persistence Query Language (Linguagem Query de Persistência Java)

JVM – Java Virtual Machine (Máquina Virtual Java)

OO – Orientado a Objetos

ORM – Mapeamento Objeto Relacional

POJO – Plain Old Java Object (Objeto Simples Java)

RIA – Rich Internet Application (Aplicações de Internet Rica)

SDK – Software Development Kit (Kit para desenvolvimento de software)

SGBD – Sistema de Gerenciamento de Banco de Dados

SGBDOR – Sistema de Gerenciamento de Banco de Dados Objeto-Relacional

SOAP – Simple Object Acess Protocol (Protocolo Simples de Acesso a Objetos)

UBS – Unidade Básica de Saúde

UML – Unified Modeling Language (Modelo Unificado de Linguagem)

XML – Extensible Markup Language (Linguagem de Marcações Extensivas)

10

SUMÁRIO

INTRODUÇÃO .......................................................................................................... 12 1. TECNOLOGIAS ABORDADAS ....................................................................... 15 1.1. INTRODUÇÃO ................................................................................................ 15

1.2. JAVA ............................................................................................................... 16 1.3. ADOBE FLEX .................................................................................................. 16 1.3.1. Linguagens de Programação Flex ............................................................... 18 1.3.2. Flex e programação orientada a objeto ........................................................ 18

1.4. BLAZEDS ........................................................................................................ 19 1.5. NETBEANS ..................................................................................................... 20 1.6. JPA (JAVA PERSISTENCE API – API DE PERSISTÊNCIA JAVA) ................ 20

1.7. HIBERNATE .................................................................................................... 21

1.8. UML ................................................................................................................. 22 1.9. POSTGRESQL ................................................................................................ 23 1.10. JASPERREPORTS E IREPORTS ............................................................... 24 1.11. CONSIDERAÇÕES FINAIS ......................................................................... 24

2. Documento visão ............................................................................................. 26 2.1. INTRODUÇÃO ................................................................................................ 26

2.2. POSICIONAMENTO ........................................................................................ 26

2.2.1. Instrução do Problema ................................................................................. 26 2.2.2. Instrução sobre a Posição do Produto ......................................................... 27 2.3. DESCRIÇÕES DO ENVOLVIDO ..................................................................... 27

2.3.1. Resumo dos Envolvidos ............................................................................... 27 2.3.2. Ambiente do Usuário .................................................................................... 28

2.4. VISÃO GERAL DO PRODUTO ....................................................................... 29 2.4.1. Perspectiva do Produto ................................................................................ 29 2.4.2. Premissas e Dependências .......................................................................... 30

2.4.3. Necessidades e Recursos ............................................................................ 30 2.4.4. Outros Requisitos do Produto ...................................................................... 31

2.5. CONSIDERAÇÕES FINAIS............................................................................. 32

3. DIAGRAMAS ................................................................................................... 33 3.1. INTRODUÇÃO ................................................................................................ 33

3.2. DIAGRAMA DE CASOS DE USO ................................................................... 33 3.3. ESPECIFICAÇÃO DE HISTÓRIAS ................................................................. 34 3.3.1. Manter cliente ............................................................................................... 34

3.3.2. Consultar histórico vacinal ........................................................................... 34 3.3.3. Controlar estoque ......................................................................................... 34 3.3.4. Efetuar aplicação vacinal ............................................................................. 35 3.3.5. Manter pedido de insumos ........................................................................... 35 3.3.6. Gerar relatórios ............................................................................................ 35

3.3.7. Manter insumos ............................................................................................ 36

3.3.8. Manter endereços ........................................................................................ 36

3.3.9. Manter unidades .......................................................................................... 36 3.3.10. Manter funcionários da enfermagem ........................................................ 36 3.3.11. Manter funcionários administrativos .......................................................... 37 3.3.12. Manter usuários do sistema ...................................................................... 37 3.4. MER MODELO ENTIDADE RELACIONAMENTO .......................................... 37

3.5. DIAGRAMAS DE ATIVIDADES ....................................................................... 39 3.6. DIAGRAMAS DE MVC .................................................................................... 42

11

3.7. DIAGRAMAS DE SEQUÊNCIA ....................................................................... 49

3.8. CONSIDERAÇÕES FINAIS............................................................................. 61 4. PROTOTIPAÇÃO ............................................................................................ 62 4.1. INTRODUÇÃO ................................................................................................ 62 4.2. LAYOUT DAS TELAS ..................................................................................... 62 CONCLUSÃO ............................................................................................................ 68

REFERÊNCIAS ......................................................................................................... 70 APÊNDICE ................................................................................................................ 72

12

INTRODUÇÃO

O Programa Nacional de Imunizações (PNI), de 1973, prevê o atual cenário

da saúde no país, em que o governo federal, juntamente, com os estados e

municípios vem investindo fortemente na prevenção das doenças por meio de

vacinações em larga escala de abrangência. Pode-se assim, detectar uma grande

necessidade de se manter um controle forte e confiável dessas ações, já que para o

seu sucesso mesmo, sempre se fazem necessárias informações seguras e precisas

da população já vacinada. (FUNASA, 2001)

O município, por menor que seja, a partir do momento em que se habilita a receber os recursos da União, começa a ser exigido e cobrado no sentido de programar e ofertar em seu território, pelo menos, os serviços básicos, inclusive domiciliares e comunitários, de responsabilidade tipicamente municipal. A vacinação é um serviço básico, passando, obrigatoriamente, a ser planejada no conjunto das ações oferecidas pela rede de serviços de saúde. (FUNASA, 2001, pag. 11).

O Brasil é referência mundial de prevenção de doenças através da vacinação

da população, porém poucos municípios possuem controle fidedigno e informatizado

das vacinações realizadas em seus habitantes. (FEIJÓ; SÁFADI, 2006) No município

de Lins, o controle é realizado manualmente gerando falta de dados ou informações

errôneas que se desencontram de uma Unidade Básica de Saúde (UBS) para outra.

Essa descentralização das informações sobre vacinações pode levar o cidadão a ser

imunizado desnecessariamente por falta do histórico e ou dificuldade de sua

localização.

Desse modo, justifica-se a necessidade de ser implantado um sistema para

aperfeiçoar os atendimentos nas salas de vacinação e melhorar as consultas. Para

tanto, será efetuada análise das necessidades de forma técnica e analítica, pois

conforme Teorey (2006), os requisitos de um banco de dados são determinados

13

entrevistando-se os produtores e os usuários dos dados; sendo que as informações

são usadas para produzir uma especificação formal de requisitos.

Com essa análise, torna-se possível o desenvolvimento de um sistema de

gestão para a coleta e organização dos dados dos munícipes de Lins, referente à

situação vacinal de cada cidadão, gerando, desta forma, um controle maior sobre o

histórico de toda a população e proporcionando a redução de possibilidade de

repetição desnecessária de vacina por falta de informação correta.

Para tanto será feito um levantamento do funcionamento dos ciclos de

vacinação, das características principais de controle e o fluxo de atendimento da

população nas Unidades Básicas de Saúde com intuito de definir a melhor forma de

aplicação de um sistema de gestão para um controle eficaz e rápido da sala de

vacinação. Desse modo, intenciona-se garantir uma melhor gestão dos processos

no atendimento ao público, monitoramento do estoque vacinal e controle em tempo

de real das vacinas realizadas no município.

Sendo assim, este trabalho tem como objetivo geral gerar meios de controle

específico das vacinas realizadas no município, instituindo uma base de dados única

na rede de Unidades Básicas de Saúde (UBS) de Lins, viabilizando desta forma um

melhor controle operacional da sala de vacinação.

Dentre os objetivos específicos, estão criar um sistema gerencial consolidado

com todas as informações necessárias para o controle vacinal de cada paciente das

salas de vacinação das Unidades Básicas de Saúde (UBS); viabilizar mecanismos

que tenham como objetivo o ganho de tempo e agilidade nos processos de controle

de uma sala de vacinação e consolidar os dados de forma a unificar o controle

vacinal da população em um só local.

Para a realização deste projeto foi feita uma pesquisa qualitativa, baseada em

literaturas de autores renomados como Deitel & Deitel (2005), Gassner (2010),

Gonçalves (2008) e também em documentações disponíveis nos sites dos

desenvolvedores das tecnologias utilizadas no projeto; fez-se a utilização, também,

de monografias, artigos científicos e técnicas para o desenvolvimento do software.

O resultado da pesquisa é apresentado, nesta monografia, em quatro

capítulos.

No primeiro capítulo são mostradas as tecnologias utilizadas para o

desenvolvimento do software proposto no projeto.

14

No segundo é tratada a análise de requisitos, onde são levantados os

problemas, apresentadas as necessidades da Vigilância Epidemiológica e propostas

as soluções.

No terceiro capítulo é feito a análise dos casos de uso para o sistema,

juntamente com a descrição de um. Neste capítulo contém também os diagramas

que norteiam o projeto tais como: diagrama de entidade relacionamento; diagramas

de atividades; MVC e diagramas de sequência.

O quarto capítulo é apresentada a interface gráfica das principais telas

presentes no sistema, bem como uma breve descrição das funcionalidades que

envolvem cada tela dentro do sistema. Conclui-se a monografia retomando as

questões que a motivaram e avaliando se os objetivos foram alcançados.

15

1. TECNOLOGIAS ABORDADAS

1.1. INTRODUÇÃO

Este capítulo apresenta de forma simplificada as tecnologias que foram

abordadas para o desenvolvimento do sistema proposto neste trabalho.

Primeiramente, é importante dizer que o Java e o Flex são tecnologias

independentes e que somente está sendo feito a integração do dois na

implementação para potencializar as características visuais e estruturais do sistema.

Importante ressaltar que a UML é essencial para nortear o andamento do projeto,

pois foi utilizada para fazer as análises de negócios, diagramas e esquematizar a

melhor forma de se trabalhar no projeto. Java garante a segurança nas regras de

negócios de sistema e o deixa mais robusto. Os conceitos de OO (Orientada a

Objetos) são usados para deixar o sistema mais compacto, Hibernate é usado para

efetuar a persistência objeto/relacional dos dados no banco de dados, já que o

projeto está baseado no modelo orientado a objetos que se baseia no mundo real e

modelo relacional que é baseado princípios matemáticos como tabelas, compostas

por colunas e linhas.

O BlazeDS tem papel fundamental na integração de tecnologias por ser um

projeto open source (gratuito), destinado a fazer a ponte entre o Java e o Flex. Sem

ele seria necessário trabalhar com tecnologias proprietárias que inviabilizariam o

projeto. O Flex está sendo utilizado por ser uma tecnologia, atualmente, dinâmica

em relação aos recursos visuais, porque traz a sensação do usuário estar

trabalhando em um aplicativo desktop para o navegador de internet. Por fim, o

JasperReports/IReports foi incluído para trazer um tom de profissionalismo e

16

seriedade para os relatórios gerados no sistema, já que ele consegue coletar os

dados do banco de dados e gerar relatórios personalizados em PDF.

1.2. JAVA

Java é uma linguagem de programação que foi desenvolvida pela Sun em

1991. Ela possui centenas de recursos baseados na criação de objetos reutilizáveis,

tornando-o mais seguro para o desenvolvimento de softwares pessoais ou

coorporativos, já que o mesmo se mostra robusto e estável. (Schimtz, 2010, p. 3 )

O Java1 destaca-se atualmente pela sua versatilidade, eficiência e

portabilidade de plataforma deixando desta forma o Java como melhor opção para

os desenvolvedores, segundo dados oficiais da Oracle/Sun atualmente a tecnologia

está presente em mais de 4,5 bilhões de dispositivos, sendo eles: PCs, telefones

celulares e outros dispositivos portáteis, cartões inteligentes, impressoras, webcams,

jogos, sistemas de navegação para automóveis, terminais lotéricos, dispositivos

médicos, guichês de pagamento de estacionamento, entre outros.

A grande vantagem da linguagem Java em relação as outras liguagens, é o

fato de ela ser multiplataforma. O desenvolvimento das aplicações pode ser feito em

qualquer ambiente (sistema operacional) e a aplicação pode ser executada em

qualquer outro ambiente. Isso é possível porque a aplicação Java é interpretada por

uma máquina virtual, chamada JVM.

Deitel & Deitel (2005) exemplifica o Java Virtual Machine como um aplicativo

que simula um computador, para carregar e executar os aplicativos Java,

convertendo os bytecodes em códigos interpretáveis pela máquina virtual, tornando-

as desta forma portáveis, ou seja, podem ser executadas em qualquer plataforma

que tenha a Java Virtual Machine.

1.3. ADOBE FLEX

1 http://www.java.com/pt_BR/about/

17

Segundo Schmitz (2010) o framework Flex possui aproximadamente 5 (cinco)

anos de existência e é uma tecnologia open source (gratuita) com maturidade

suficiente para desenvolvimento de aplicações. O Flex é atualmente utilizado para a

criação de Front End (interface para o usuário) de aplicativos e também para o

desenvolvimento de web sites dinâmicos ou estáticos com grande riqueza de

recursos visuais, já que o mesmo é um framework para criação de aplicações RIA

(Rich Internet Aplication - Aplicações Ricas para Internet), fazendo assim, a

substituição natural dos recursos de linguagem de programação web como o html,

css e javascript.

Conforme Bini (2009) a linguagem de programação que é utilizada pelo Flex,

o ActionScript é amplamente difundida em aplicações web e sites, podendo ser

utilizada por diversos IDE's (Ambiente Integrado de Desenvolvimento) existentes no

mercado, sendo assim para a realização deste projeto foi utilizado a IDE do próprio

desenvolvedor da linguagem Flex e ActionScript que é o Adobe Flash Buider

Premium, possibilitando desta forma, trazer a aplicação web as características dos

tradicionais softwares desktop.

De acordo Schmitz (2010) ara que as aplicações desenvolvidas em Flex

funcionem, é necessário a instalação do plugin chamado Flash Player que

atualmente está presente em 98% dos computadores do mundo e também nos

aparelhos portáteis como smartphones, tables, PDAs e outros, tornando assim o

Flex uma tecnologia portável para qualquer plataforma ou sistema operacional.

Quando uma aplicação em Flex é criada com o Flex 4 SDK (Software

Development Kit – Kit para desenvolvimento de software) ou com o ambiente de

desenvolvimento integrado da Adobe o Flash Builder 4 (anteriormente chamado de

Flex Builder), o mesmo é construido como uma apresentação baseada no já

conhecido e difundido Flash. É importante resaltar que a diferença em entre o Flash

Builder e o SDK, se dá pela segunda opção ser de código aberto, que torna o

desenvolvimento de aplicativos, mais propensos a erros, pois o mesmo não tem um

ambiente de edição definido, já o Flash Builder é uma solução sob licença em nome

da Adobe Systems, porém é a plataforma mais utilizada, por ser mais produtiva,

oferecer um conjunto amplo de ferramentas e minimizar os erros de programação.

(GASSNER, 2010, p. 4)

18

1.3.1. Linguagens de Programação Flex

O Flex trabalha com 3 (três) Linguagens de programação, sendo elas:

ActionScript 3 que é a versão mais recente da linguagem nativa do

Flash, sendo que ela é uma liguagem orientada a objetos, baseada na

especificação da linguagem ECMAScript Edtion 4. A linguagem

ActionScript 3 suporta a utilização de todas as técnicas conhecidas na

orientação a objetos, como modularidade, encapsulamento, herança e

polimorfismo.

MXML linguagem que define um aplicativo Flex, completamente

baseada no conhecido XML (Extensible Markup Language –

Linguagem de Marcação Extensiva), os elementos MXML sempre

correspondem a uma classe ActionScript 3 que é entregue como parte

da biblioteca de classes do Flex.

FXG linguagem também baseada em XML, mas que possibilita

representar objetos gráficos nas marcações XML, por meio de

declarações MXML de baixo nível com objetos gráficos que constarem

dentro das aplicações. (GASSNER, 2010, p. 5)

1.3.2. Flex e programação orientada a objeto

Atualmente as aplicações Flex estão principalmente chamando a atenção dos

desenvolvedores que conhecem a programação orientada a objetos (POO) porque o

Flex trabalha com a linguagem de programação ActionScript 3 que é completamente

orientada a objetos, trazendo desta forma para as aplicações criadas em Flex todo o

conjunto de técnicas de desenvolvimento de software com o uso de “objetos” para

controlar o comportamento de um aplicativo. O uso as POO não garante sucesso na

criação de aplicativos em Flex, mas um bom nível de conhecimento dos princípios

da POO irão contribuir significavelmente para o sucesso do projeto. (GASSNER,

2010, p. 11)

19

1.4. BLAZEDS

O BlazeDS2 é um servidor baseado em Java e remoting com tecnologia web

de mensagens que permite a integração entre o back-end (Camada de negócios) e o

Adobe Flex em tempo real. Com a crescente evolução dos aplicativos RIAs criou-se

a necessidade de melhores opções de conectividade de dados entre o cliente Flash

e os métodos Java no servidor, para tanto foi criado um tipo de dado binário AMF

(Action Message Format - Formatação das Ações por Mensagens) para aumento de

desempenho na transferência, permitindo assim, que cargas de dados sejam

processadas por uma aplicação que utilize BlazeDS e tenha um desempenho de até

10 vezes mais rápida do que os formatos baseados em texto, como XML e SOAP,

conforme demonstra a figura 1.

Figura 1: Benchamark de desempenho do BlazeDS Fonte: WARD (2007)

2 http://opensource.adobe.com/wiki/display/blazeds/BlazeDS

20

1.5. NETBEANS

O NetBeans3 é um projeto open source (gratuita), que foi fundado em junho

de 2000, tendo como principal patrocinador a Sun Microsystem. O projeto netbeans

tem como foco a disponibilização de um ambiente de desenvolvimento para

programadores. O mesmo é escrito em Java, porém suporta as principais linguagens

de programação utilizadas atualmente no mercado. Possui vastos módulos que

podem ser fácilmente acoplados para aprimorar o netbeans.

Conforme Gonçalves (2006, p. 23) o netbeans vem evoluindo a cada versão,

trazendo sempre novas funcionalidades que vem atraindo cada vez mais

desenvolvedores do mundo inteiro, pois o mesmo já vem por padrão com um editor

amigável de telas AWT/Swing, suporte completo ao Java Enterprise Edition,

integração com banco de dados, plug-ins de diversos tipos que estendem a

capacidade do programa, entre outros recursos.

A implementação da tecnologia Adobe Flex na IDE NetBeans, está descrita

no anexo 1, com todas as especificações e passos de como foi feito este projeto.

1.6. JPA (JAVA PERSISTENCE API – API DE PERSISTÊNCIA JAVA)

Segundo GONÇALVES (2008) o JPA tem como base o conceito POJO (Plain

Old Java Object – Objeto Simples Java) que faz o uso de renomados frameworks de

persistência para padronizar o mapeamento objeto/relacional em Java. Os objetos

persistidos com o JPA são chamados de entidades (Entities), sendo que uma

entidade é nada mais que um objeto simples Java que faz a representação de um

conjunto de dados persistidos no banco de dados.

“Como entidades são definidas por classes Java comuns, sem relação com

frameworks ou bibliotecas, elas podem ser abstratas ou herdar de outras classes,

sem restrições.” (GONÇALVES, 2008, p. 101)

3 http://www.netbeans.org/

21

Apesar do mapeamento objeto-relacional ser um componente importante do

JPA, ele também oferece soluções para os desafios da integração arquitetônica de

persistência em aplicações corporativas escaláveis, pois fornece um completo

conjunto de soluções de persistência que incluem recursos de mapeamento

adicionais para diversos provedores de acesso ao banco, por meio do Java

Persistence Query Language (JPQL) que possibilita a flexibilidade no uso dos

provedores JPA sem afetar a comunicação com o banco de dados, como pode ser

visto da figura 2. (KEITH, SCHINICARIOL, 2009, p. 12)

Figura 2: A arquitetura JPA em alto nível Fonte: MENDES (2007)

1.7. HIBERNATE

Segundo Gonçalves (2008) por muitos anos a persistência em banco de

dados foi um grande problema para os desenvolvedores Java, pois a portabilidade

entre banco de dados era tecnicamente impossível, porque cada banco tinha seu

dialeto específico. Porém, com o surgimento dos ORMs (Mapeamentos Objeto

Relacional), este problema foi sanado já que com o ORM a portabilidade total de

22

sistema estava garantido. Dentre os mais famosos ORMs, temos o Hibernate, que

ao longo dos anos tornou-se referência no meio de desenvolvimento.

Porém, com o Java EE 5, através de especificação do EJB3, na introdução do JPA (Java Persistence API), ficou muito popular o uso do JP-QL, Java Persisitence Query Language, onde o mapeamento de objeto/relacional foi padronizado na plataforma Java. Com isso, o ORM Hibernate passou a ser um provedor de persistência que, se for necessário, pode ser substituido por outro sem que ocorram mudanças na comunicação entra a aplicação e o ORM. (Gonçalves, 2008, p. 81)

O Hibernate4 teve início no ano de 2001 por Gavin King, com a objetivo de

ser uma alternativa de uso do beans de entidade EJB2 (Enterprise JavaBeans)

para oferecer melhores recursos de persistência. No início de 2003 a equipe de

desenvolvimento do Hibernate liberou o Hibernate2 que oferecia melhorias

significativas e que impulsinou o Hibernate como o padrão de persistência em Java.

1.8. UML

Com a necessidade de criar-se um padrão para construção de software

orientados a objetos a UML (Unified Modeling Language – Modelo Unificado de

Linguagem) surgiu com o objetivo de criar uma padronização para arquitetura de

projetos de sistema, cuidado dos aspectos conceituais do negócio e do sistema,

além de prever também os aspectos físicos, tais como as classes escritas em

determinada linguagem de programação, modelagem de banco de dados e

componentes reutilizáveis. A UML não tem o objetivo de mostrar como fazer um

software, mas sim apenas dar parâmetros para utilizá-la com intuito de representar

as diversas fases de desenvolvimento, gerando assim, a possibilidade de pensar no

software em um local e codificá-lo em outro, por meio das análises e pelos gráficos

gerados. (MEDEIROS, 2004, p. 9)

A UML5 tem papel fundamental para a criação de uma modelagem de

software muito antes da codificação, tornando-o, assim, parte fundamental para a

criação de pequenos, médios e grandes projetos, visando minimizar os erros nos

cálculos de tempo e investimentos necessários para o sucesso do mesmo. Quando

4 http://www.hibernate.org/

5 http://www.uml.org

23

usado a modelagem, disponibiliza aos responsáveis do projeto a segurança de que

as funcionalidades do negócio está completa e correta, as necessidades do usuário

final e a concepção do programa suporta os requisitos de escalabilidade, robustez,

segurança, extensibilidade e outras características necessárias.

1.9. POSTGRESQL

O PostgreSQL6 é um sistema de gerenciamento de banco de dados objeto-

relacional (SGBDOR), que foi desenvolvido pelo departamento de ciência da

computação da Universidade de Berkeley, e que desde de seu início no ano de 1986

até a sua versão atual, passou por grandes e sérias alterações na estrutura e até

mesmo na linguagem padrão que inicialmente era o PostQUEL e no ano de 1994 a

mesma foi substituída pela difundida linguagem SQL, para apresentar maior

confiabilidade, portabilidade e interface gráfica de fácil entendimento e utilização,

como pode ser visto na figura 3.

Figura 3: Tela Inicial de gerenciamento do banco de dados PostgreSQL Fonte: Elaborado pelo autor .

6 http://www.postgresql.org.br/

24

Segundo Milani ({s.a}) soluções de informática estão presentes em diversas

áreas de negócios, fazendo com que inúmeras aplicações gerem dados para serem

armazenados em algum banco de dados para consultas posteriores. O PostgreSQL

tem como finalidade o armazenamento desses dados e disponibilização dos mesmo

em forma de informação tabulada e organizada, porém somente isso não o faz um

SGBD (Sistema de Gerenciamento de Banco de Dados), pois sem que haja uma

regra de segurança os dados ficam vulneráveis a consultas indesejadas. Por isso o

PostgreSQL oferece controle de restrição as informações por meio de regras a

serem definidas previamente pelo administrador do banco.

1.10. JASPERREPORTS E IREPORTS

O JasperReports7 é uma biblioteca escrita em Java, cujo o código é aberto e

tem como principal foco facilitar a tarefa dos desenvolvedores na criação de

relatórios para as aplicações tanto desktop como web, fornecendo uma ferramenta

que facilita a geração dos mesmos, tendo como resultado de saída relatórios no

formato XML, incentivando, assim, a criação de uma ferramenta para gerar relatórios

visuais que foi chamada de IReport, sendo que o mesmo foi desenvolvido pelo

italiano Giulio Toffoli e logo após com a grande popularização, foi comprada pela

JasperSoft para ser tornar ferramenta oficial na construção de relatórios para o

JasperReports.

O iReport para NetBeans IDE é um programa Open Source, capaz de criar

visualmente os mais complexos relatórios para aplicações Java no formato da

biblioteca JasperReports. (GONÇALVES, 2008, p. 3)

1.11. CONSIDERAÇÕES FINAIS

7 http://jasperforge.org/

25

Este capítulo apresentou uma revisão literária a respeito das tecnologias

envolvidas no projeto, foram mostrados os conceitos de cada tecnologia e suas

principais características. No próximo capítulo iremos tratar do documento visão para

uma maior compreensão da motivação do desenvolvimento deste projeto.

26

2. DOCUMENTO VISÃO

2.1. INTRODUÇÃO

Neste capítulo será feito a análise dos problemas da empresa, um estudo

dos profissionais envolvidos e por fim a propositura de uma solução informatizada

com intuído de sanar todos os entraves encontrados.

2.2. POSICIONAMENTO

2.2.1. Instrução do Problema

Quadro 1 – O Problema da empresa.

O problema de Controle dos processos administrativos das salas de vacinas do município de Lins precisa ser informatizado para gerar um maior controle e evitar problemas, tais como: a) falta de informações sobre usuários; b) aplicação de doses de vacinas desnecessárias; c) falta de controle de estoque real das salas; d) Imprecisão na confecção de relatórios.

Afeta Todas as salas de vacinação do município de Lins, dificultando o processo administrativo.

o impacto do qual é a) Falta de um controle em tempo real das salas de vacinação; b) Prejuízo com a duplicação doses de vacinas desnecessárias; c) Falhas em controle de estoque vacinal.

uma solução bem- A criação de um sistema de gestão das salas de

27

sucedida seria vacinação visando um maior controle dos processos administrativos poderá sanar todos os problemas acima citados, gerando uma confiabilidade plena dos dados e controles vacinais do município.

Fonte: Elaborado pelo autor .

2.2.2. Instrução sobre a Posição do Produto

Quadro 2 – Posição do produto.

Para Secretaria de Saúde de Lins (Vigilância Epidemiológica)

Que Assim como os demais municípios, carecem de uma solução integrada que atinja todos os seus processos administrativos das salas de vacinação.

O (nome do produto) Sistema de Gestão para Salas de Vacinação

Que Busca integrar todos os processos administrativos da Vigilância Epidemiológica, quanto as Salas de Vacinação de sua área de cobertura.

A menos que Os profissionais que estão envolvidos no processo não aceite mudar e atualizar os processos administrativos que são chaves.

Nosso produto Atingirá seus objetivos de forma concisa. Fonte: Elaborado pelo autor .

2.3. DESCRIÇÕES DO ENVOLVIDO

2.3.1. Resumo dos Envolvidos

Quadro 3 – Responsabilidades dos cargos.

Nome Descrição Responsabilidades

Auxiliares de Enfermagem, Técnicos de Enfermagem e Enfermeiros das Unidades Básicas de Saúde.

Pessoas responsáveis por efetuar o atendimento aos usuários nas salas de vacinação.

Os profissionais das Unidades Básicas de Saúde serão os usuários principais do sistema, pois serão os responsáveis pelos processos de cadastro e atualização dos usuários, endereços, lançamento das vacinas realizadas, emissão de segunda via da carteira de vacinação, emissão de pedidos de vacinas e materiais de insumo, lançamento no estoque, emissão de relatório de faltosos.

28

Nome Descrição Responsabilidades

Enfermeiros e Auxiliares Administrativos da Secretaria da Saúde (Vigilância Epidemiológica).

Pessoas responsáveis pelos processos administrativos das salas de vacinação e central de administrativa.

Os profissionais da Vigilância Epidemiológica têm como responsabilidade o cadastro e atualização dos profissionais, das unidades (UBS/Salas), vacinas, insumos, endereços, campanhas vacinais, usuários do sistema, geração dos relatórios de movimentação de estoque, boletim mensal de doses aplicadas, boletim mensal de doses por faixa etária, estoque vacinal, lançamento de doses de campanha, lançamento de estoque, transferência de estoque entre unidades e recepção dos pedidos de estoque das unidades.

Hospitais Hospitais da rede pública e particulares que fazem atendimento de emergência e urgência.

Local responsável em efetuar a primeira dose vacinal a todos os recém-nascidos do município e de outros e também em fazer atendimento emergencial para feridos que necessitem de dose vacinal prevista por lei. Para este usuário sua responsabilidade no sistema será de lançar as vacinas efetuadas em caso de emergência, baixa de estoque e efetuar pedido de vacinas.


2.3.2. Ambiente do Usuário

A Vigilância Epidemiológica do município de Lins, conta hoje com

aproximadamente quarenta profissionais, dentre eles, auxiliares e técnicos de

enfermagem, enfermeiros e auxiliares administrativos, distribuídos em seis salas de

vacinação, sendo que essas estão alocadas nas Unidades Básicas de Saúde (UBS)

do munícipio e na Secretaria da Saúde, atuando na Vigilância Epidemiológica.

Dentre os envolvidos nas salas de vacinação, trinta e cinco deles são vacinadores

que atuam diretamente, atendendo os usuários, efetuando os controles vacinais e

zelando pelo bom funcionamento dos processos administrativos internos; Os demais

são auxiliares administrativos que desempenham suas atividades diretamente na

vigilância epidemiológica, onde é feita a recepção de todos os relatórios de produção

das salas, pedidos de reposição de estoque vacinal e insumos e atualização das

informações do controle vacinal populacional da Secretaria de Saúde Estadual.

29

Atualmente, os processos que englobam desde, o atendimento ao usuário até

a confecção de relatórios de produção, são realizados de forma manual, por meio de

fichas catalográficas. As salas de vacinação contam com dois processos básicos e

distintos para o atendimento ao usuário, sendo que o primeiro processo, que trata

diretamente dos novos usuários, ou seja, os recém-nascidos ou cidadãos vindos de

outros municípios, para esses é feito uma ficha cadastral chamada espelho, que irá

constar todo o histórico vacinal e os dados pessoais, tais como: nome, endereço,

nome da mãe, data de nascimento e outros; e também a carteira de vacinação que

fica com o usuário. Já no segundo processo, o de retorno de dose vacinal, ocorre

apenas a atualização da ficha espelho e carteira de vacinação do usuário. Porém, se

este, por algum motivo necessitar efetuar o retorno em outra unidade básica de

saúde do município que não seja a que ele inicialmente efetuou o cadastro, terá de

passar novamente pelo processo inicial, somente dispensando a confecção da

carteira de vacinação, pois as unidades não compartilham o mesmo cadastro de

usuários das salas de vacinação.

Os profissionais das salas de vacinação também têm como responsabilidade,

o controle de estoque dos insumos e vacinas e a confecção de relatórios de

produção, sendo que quando necessária a reposição de estoque ou até mesmo a

entrega de relatório de produção para vigilância epidemiológica, é utilizado o

telefone para repassar as informações e quando necessário é solicitado um

motorista para ir na UBS para recolher os pedidos e os relatórios, encaminhando-os

para a Secretaria da Saúde Municipal, onde é feito o recebimento dos pedidos de

reposição de estoque, e a recepção dos relatórios de produção para posteriormente,

serem feitas as consolidações dos dados e os despachos de materiais de insumo e

vacinas para UBS solicitante.

2.4. VISÃO GERAL DO PRODUTO

2.4.1. Perspectiva do Produto

30

O desenvolvimento desse produto pode ser considerado uma oportunidade no

mercado que até então está sendo pouco explorada. Atualmente, esse segmento

não tem um produto específico que atenda as necessidades reais de controle

administrativo das salas de vacinação populacional.

É importante que o sistema vislumbre a utilização mínima de requisitos de

hardware, pois o público alvo são as prefeituras, cuja filosofia é a adoção de

soluções baratas e efetivas.

2.4.2. Premissas e Dependências

A Secretaria da Saúde pretende investir apenas em arquitetura física, não

desejando investir em softwares básicos como sistemas operacionais e sistemas

gerenciadores de banco de dados. É desejado, no caso, o uso do Sistema

Operacional Linux, independente de sua distribuição e o banco de dados

PostGreSQL.

2.4.3. Necessidades e Recursos

Quadro 4 – Necessidades e recursos.

Necessidade Prioridade Recursos

Cadastro de Unidades. As unidades básicas de saúde poderão ser cadastradas para sinalizar como ponto de vacinação.

Alta Análise Arquitetura, SGBD

Cadastro de Profissionais. Os auxiliares, técnicos e enfermeiros poderão ser cadastrados pela vigilância epidemiológica para saber quem são os vacinadores.


Cadastro de Usuários do Sistema. Poderá ser cadastrado como usuário todo profissional da sala de vacina.


Cadastro de Vacinas. Todas as vacinas deverão ser cadastradas com todas as informações pertinentes ao mesmo tais como: nome, lote, fabricante, etc.


Cadastro de Insumos. Os materiais utilizados Baixa Análise

31

nas salas de vacinação. Arquitetura, SGBD

Cadastro de Endereço. Para maior controle e confiabilidade de dados será feito o cadastro de endereço por CEP.


Cadastro de Cliente. O usuário poderá ser cadastrado com os dados pertinentes e atual ficha espelho.


Lançamento de Vacinas. O usuário poderá efetuar o lançamento do histórico vacinal do usuário, assim como é feito nas carteiras de vacinação.


Emissão de 2º via da Carteira de Vacinação. Relatório que possibilite a impressão do histórico vacinal do usuário.

Baixa Análise Arquitetura, SGBD

Lançamento de estoque vacinal ou de insumo. Média Análise Arquitetura, SGBD

Pedido de vacinas ou insumos para reposição de estoque das salas de vacinação.

Média Análise Arquitetura, SGBD

Transferência de estoque entre a vigilância epidemiológica e as salas de vacinação de UBS.


Relatório de movimentação de estoque por período.


Relatório de boletim mensal de doses aplicadas, com filtros por período, faixa etária, por bairro, por unidades e geral.


Relatório de usuários faltosos (com vacina em atraso) com possibilidade de filtros por período, bairro, CEP (rua) e geral.


Relatório de posição de estoque vacinal com filtros por período, unidade e geral.



2.4.4. Outros Requisitos do Produto

Intranet ou Internet Banda Larga para comunicação entre as Unidades

Básicas de Saúde (UBS) e a Secretaria de Saúde (Vigilância Epidemiológica).

Uso de um gerenciador de banco de dados confiável, que forneça fácil

implementação via Intranet ou Internet, que ofereça fácil manutenção e, de

preferência, que seja de uso gratuito.

Uso de interface amigável e intuitiva.

32


Neste capítulo foram apresentados os problemas e o cenário atual da

empresa envolvida no projeto e também demonstrado as oportunidades para a

inserção do software proposta nas salas de vacinação. No próximo capítulo será

feito a análise dos casos de usos para o sistema, juntamente com as histórias de

cada um deles e também será apresentado os demais diagramas pertinentes a

análise.

33

3. DIAGRAMAS

3.1. INTRODUÇÃO

Neste capítulo serão apresentados os diversos diagramas que foram

confeccionados para entender melhor o funcionamento do sistema proposto, com

eles a compreensão do funcionamento, das rotinas do software proposto fica mais

clara e entendível.

3.2. DIAGRAMA DE CASOS DE USO

Figura 4: Diagrama de caso de uso Fonte: Elaborado pelo autor

34

3.3. ESPECIFICAÇÃO DE HISTÓRIAS

3.3.1. Manter cliente

O profissional que atua na sala de vacina efetua o atendimento ao cliente,

primeiramente deve saber se este possui ou não cadastro no banco de dados geral

das salas de vacinação que se localiza na vigilância epidemiológica da secretaria de

saúde do município abordado. Caso o cliente não possua cadastro no banco de

dados, ele é cadastrado com as informações pessoais como o nome, data de

nascimento, nome do responsável, endereço, telefone e sexo. Caso já seja

cadastrado, o profissional atualizará seus dados e da vacina que será realizada.

Após o atendimento é feito o agendamento do retorno, de acordo com o tipo da

vacina, mantendo desta forma a manutenção constante do cadastro.

3.3.2. Consultar histórico vacinal

O histórico vacinal é consequência dos atendimentos que geram um

documento chamado espelho vacinal, que tem como objetivo armazenar

informações sobre as vacinas aplicadas no cliente, datas da aplicação, lotes de

vacina, profissional responsável pela aplicação e o retorno do cliente à unidade.

3.3.3. Controlar estoque

Antes de iniciar o expediente nas salas de vacinação, os profissionais que

nela trabalham devem consultar todos os itens, sendo de inteira responsabilidade

desses profissionais o controle de estoque dos materiais, insumos e vacinas,

zelando para que não haja falta, evitando desperdícios na utilização. Para tanto os

35

profissionais deverão periodicamente consultar os insumos, materiais e vacinas em

estoque; analisar os vencimentos e o nível mínimos de segurança e fazer a

atualização do banco de dados, quando necessário, por vencimento, dano ou

inutilização, e assim fazer posteriormente o pedido para reposição do estoque.

3.3.4. Efetuar aplicação vacinal

O profissional que realiza a vacinação ao cliente tem como obrigação efetuar

a atualização do seu histórico vacinal, informando o nome da vacina que está sendo

aplicado, o lote da vacina, a data do procedimento, nome e número de registro do

profissional de enfermagem e o agendamento do retorno do cliente para novas

doses vacinais.

3.3.5. Manter pedido de insumos

O profissional que trabalha na sala de vacina, quando necessitar de algum

insumo, seja ele vacina ou material de uso diário, deve fazer um pedido formal à

vigilância epidemiológica que controla e detêm o estoque central, para a distribuição

às salas de vacina das unidades básicas de saúde. Assim, que recebido o pedido

pelos profissionais que atuam na vigilância epidemiológica, os insumos são

separados, catalogados e enviados a sala de vacinação solicitante.

3.3.6. Gerar relatórios

Os profissionais administrativos que atuam na vigilância epidemiológica têm

como principal função a geração de relatórios para controle da produção ou por

solicitação do órgão de controle regional, relatórios esses que podem ser de

36

produção diária, semanal, mensal e anual ou relatórios de faltosos que é baseado no

retorno do cliente que é utilizado para efeito de métrica de abrangência das ações

de imunização populacional é requerido ao profissional administrativo também dados

vacinais por faixa etária, bairro ou unidade básica de saúde.

3.3.7. Manter insumos

Os profissionais administrativos são os responsáveis diretos em efetuar o

cadastramento dos insumos utilizados nas salas de vacina e atualização se

necessário.

3.3.8. Manter endereços

Todos os profissionais envolvidos com as salas de vacinação sejam eles

administrativos ou da enfermagem, tem como responsabilidade manter o cadastro

de endereços do sistema atualizado, efetuado sem uma revisão dos índices já

cadastros e incluindo os novos que surgirem para manter desta forma à base de

dados atualizada e segura para geração de relatórios por zoneamento municipal.

3.3.9. Manter unidades

A rotina de manter os dados das unidades atualizadas é de responsabilidade

de todos os profissionais envolvidos nos processos das salas de vacinação.

3.3.10. Manter funcionários da enfermagem

37

O pessoal da enfermagem que trabalha nas salas de vacinação tem como

responsabilidade manter seu cadastro no sistema atualizado, com as informações

pessoais e profissionais como o número de registro de classe (COREN), porque

suas informações irão constar no histórico vacinal dos clientes.

3.3.11. Manter funcionários administrativos

A rotina de manter o cadastro de funcionários administrativos atualizados é de

responsabilidade dos profissionais que atuam na vigilância epidemiológica, já que os

profissionais da administração atuam diretamente na Secretaria da Saúde.

3.3.12. Manter usuários do sistema

O cadastro de usuários do sistema é de inteira responsabilidade dos

profissionais administrativo que atuam diretamente na vigilância epidemiológica, pois

eles que irão credenciar o profissional tem ou não acesso ao sistema.

3.4. MER MODELO ENTIDADE RELACIONAMENTO

38

Figura 5: Diagrama modelo entidade relacionamento Fonte: Elaborado pelo autor

39

3.5. DIAGRAMAS DE ATIVIDADES

Figura 6: Diagrama de atividade – Controlar estoque Fonte: Elaborado pelo autor

Figura 7: Diagrama de atividade – Consultar histórico vacinal Fonte: Elaborado pelo autor

40

Figura 8: Diagrama de atividade – Efetuar aplicação vacinal Fonte: Elaborado pelo autor

Figura 9: Diagrama de atividade – Gerar Relatórios Fonte: Elaborado pelo autor

Figura 10: Diagrama de atividade – Manter Clientes Fonte: Elaborado pelo autor

41

Figura 11: Diagrama de atividade – Manter endereços Fonte: Elaborado pelo autor

Figura 12: Diagrama de atividade – Manter funcionários administrativos Fonte: Elaborado pelo autor

Figura 13: Diagrama de atividade – Manter funcionários enfermagem

Figura 14: Diagrama de atividade – Manter insumos Fonte: Elaborado pelo autor

42

Figura 15: Diagrama de atividade – Manter unidades Fonte: Elaborado pelo autor

Figura 16: Diagrama de atividade – Manter usuários do sistema Fonte: Elaborado pelo autor

3.6. DIAGRAMAS DE MVC

Figura 17: MVC – Controlar estoque Fonte: Elaborado pelo autor

43

Figura 18: MVC – Consultar histórico vacinal Fonte: Elaborado pelo autor

44

Figura 19: MVC – Efetuar aplicação vacinal Fonte: Elaborado pelo autor

45

Figura 20: MVC – Gerar relatórios Fonte: Elaborado pelo autor

Figura 21: MVC – Manter clientes Fonte: Elaborado pelo autor

46

Figura 22: MVC – Manter endereços Fonte: Elaborado pelo autor

Figura 23: MVC – Manter funcionários administrativos Fonte: Elaborado pelo autor

47

Figura 24: MVC – Manter funcionários enfermagem Fonte: Elaborado pelo autor

Figura 25: MVC – Manter insumos Fonte: Elaborado pelo autor

48

Figura 26: MVC – Manter pedidos de insumos Fonte: Elaborado pelo autor

Figura 27: MVC – Manter unidades Fonte: Elaborado pelo autor

49

Figura 28: MVC – Manter usuários do sistema Fonte: Elaborado pelo autor

3.7. DIAGRAMAS DE SEQUÊNCIA

50

Figura 29: Diagrama de sequência – Controlar estoque Fonte: Elaborado pelo autor

51

Figura 30: Diagrama de sequência – Consultar histórico vacinal Fonte: Elaborado pelo autor

52

Figura 31: Diagrama de sequência – Efetuar aplicação vacinal Fonte: Elaborado pelo autor

53

Figura 32: Diagrama de sequência – Gerar relatórios Fonte: Elaborado pelo autor

54

Figura 33: Diagrama de sequência – Manter clientes Fonte: Elaborado pelo autor

55

Figura 34: Diagrama de sequência – Manter endereços Fonte: Elaborado pelo autor

56

Figura 35: Diagrama de sequência – Manter funcionários administrativos Fonte: Elaborado pelo autor

57

Figura 36: Diagrama de sequência – Manter funcionários enfermagem Fonte: Elaborado pelo autor

58

Figura 37: Diagrama de sequência – Manter insumos Fonte: Elaborado pelo autor

59

Figura 38: Diagrama de sequência – Manter unidades Fonte: Elaborado pelo autor

60

Figura 39: Diagrama de sequência – Manter usuários do sistema Fonte: Elaborado pelo autor

61


Neste capítulo foram vistos os diagramas confeccionados para uma melhor

compreensão do funcionamento das rotinas do sistema a ser desenvolvido, sendo

que no próximo capítulo será visto o protótipo das principais telas do sistema com a

explanação das funcionalidades envolvidas.

62

4. PROTOTIPAÇÃO

4.1. INTRODUÇÃO

Neste capítulo são apresentadas as principais telas do sistema com a

especificação das funcionalidades de cada uma, sendo que o foco deste capítulo é

mostrar a usabilidade das funções envolvidas no sistema.

4.2. LAYOUT DAS TELAS

Figura 40: Menu do sistema Fonte: Elaborado pelo autor

A figura 40 apresenta o menu onde consta todas as funcionalidades

disponíveis do sistema.

63

Figura 41: Tela de gerenciamento de clientes Fonte: Elaborado pelo autor

A Figura 41 mostra a tela de gerenciamento de clientes, que tem por

finalidade gerenciar todos os dados relativos aos clientes, sendo que as principais

funcionalidades são as de inclusão de novos clientes, mediante o preenchimento

completo dos campos, a atualização dos dados, quando necessário, e a busca de

cliente por nome. Porém quando carregada, a tela tem por funcionalidade gerar uma

tabela. Listando todos os clientes já cadastrados. Isso facilita, pois permite que o

usuário clique em qualquer elemento da lista de clientes e seus dados serão

exibidos nos campos da tela.

A Figura 42 apresenta a tela de gerenciamento de profissionais que tem por

funcionalidade cadastrar os profissionais que irão trabalhar diretamente com o

sistema. Porém para a realização do cadastro do profissional o sistema parte da

premissa que antes da pessoa ser profissional ele foi cliente, já que o esquema

vacinal inicia-se nos primeiro dias de qualquer pessoa, então ao clicar no campo

código será carregada uma tabela com o nome de todos os clientes cadastrados

para que se selecione um, para somente depois, informar se este é profissional da

enfermagem ou administrativo e preencher os campos peculiares ao cargo.

64

Figura 42: Tela de gerenciamento de profissionais Fonte: Elaborado pelo autor

Figura 43: Tela de gerenciamento de insumos Fonte: Elaborado pelo autor

A Figura 43 apresenta a tela de gerenciamento de insumos que tem por

função o cadastro e classificação de todos os insumos que são utilizados nas salas

de vacinação.

65

Figura 44: Tela de cadastro de histórico vacinal Fonte: Elaborado pelo autor

A Figura 44 apresenta a tela de cadastro de histórico vacinal que tem por

função possibilitar gerar índices de histórico vacinal, posteriores ao sistema, criando

desta forma uma maneira de se informatizar gradativamente todos os processos da

sala de vacinação, até mesmo aqueles que já estão em andamento, trazendo desta

forma segurança e comodidade.

Figura 45: Tela para atendimento de vacinação Fonte: Elaborado pelo autor

66

A Figura 45 mostra a tela de atendimento de vacinação, essa que é a tela

principal do sistema, pois é nesta tela que está agrupada várias tabelas do sistema

para consulta e geração de índices, já que quando inicia-se um atendimento é feito a

consulta do cliente, por nome ou código. Após a seleção do cliente as informações

do mesmo são apresentadas por completo. É verificado se existe algum

agendamento para este cliente e também é preenchida a data agendada para que o

atendente saiba se o cliente tem um agendamento prévio marcado.

Feita as confirmações dos dados do cliente e atualização se necessário, gera-

se o atendimento vacinal, informando a vacina a ser tomada, a dose e a data para

retorno, as demais informações serão geradas de forma automática, tais como: lote

da vacina, dados do profissional que fez o atendimento e por a tela também tem a

responsabilidade de fazer as baixas em estoque do material utilizado na aplicação,

que deverá ser informado no momento do atendimento.

Figura 46: Tela para lançamento de estoque Fonte: Elaborado pelo autor

A Figura 46 apresenta a tela responsável por permitir os lançamentos de

insumos no estoque.

67

Figura 47: Relatório de espelho vacinal Fonte: Elaborado pelo autor

A figura 47 apresenta o relatório de espelho vacinal, que é o histórico vacinal

do cliente.

68

CONCLUSÃO

No atual cenário na área da saúde, as salas de vacinação do município de

Lins estão sendo gerenciadas de forma manual e limitada, gerando grandes

dificuldades para o controle sólido e fidedigno das informações vacinais da

população, causando muitas vezes o desperdício de doses vacinais e duplicação de

aplicações.

Tendo em vista esses problemas, foi proposta a criação de um sistema de

gestão específico para salas de vacinação, que tornará o trabalho mais eficiente e

abrangente, aumentando o gerenciamento, organização e qualidade da assistência.

Diante disto, neste trabalho, foram estudas as tecnologias Java para garantir

uma camada de negócio do sistema sólida e confiável, criando entidades e serviços

que juntamente com o Hibernate fizeram as persistências de dados do modelo

objeto/relacional no banco de dados PostgreSQL. O BlazeDS é utilizado para fazer a

ponte de comunicação entre o Java e o Flex por meio de mensagens remotas, já o

Flex é o responsável pela camada de apresentação do sistema possibilitando maior

usabilidade para o sistema e por fim o JasperReports foi usado para personalizar os

relatórios de forma profissional, apresentável e de fácil compreensão da leitura dos

dados.

No modelo atual de administração das salas de vacinação, a geração de um

controle específico que possa instituir uma base de dados única para a rede de

Unidades Básicas de Saúde (UBS) de Lins é de inteira valia para o município,

evidenciando assim, a necessidade da criação de um sistema gerencial consolidado

com todas as informações dos clientes das salas de vacinação, viabilizando

mecanismos que tenham como objetivo o ganho de tempo e agilidade nos

processos de controle, formando, desta forma, uma base de dados única e sólida.

69

Para tanto, foi efetuado um levantamento do funcionamento dos ciclos de

vacinação, das características principais de controle e o fluxo de atendimento da

população nas Unidades Básicas de Saúde (UBS) com intuito de definir a melhor

forma de aplicação de um sistema de gestão para um controle eficaz e rápido da

sala de vacinação.

Feitas as análises necessárias no projeto e o desenvolvimento do software,

conclui-se que com a implantação do sistema de gestão para salas de vacinação

podem-se atingir os objetivos previstos, pois haverá ganho na agilidade do processo

de atendimento aos clientes e uma maior solidez nos controles internos

administrativos como: atualização constante dos dados vacinais dos clientes,

controle de estoque e geração de relatórios.

A implantação do sistema trará a Vigilância Epidemiológica uma gama de

informações úteis, que poderão ser usados no melhor planejamento das futuras

campanhas e ações de vacinações, esses dados também evitará o desperdício de

doses vacinais, pois o software prevê a otimização da utilização, por meio de

controle constante e em tempo real dos estoques vacinas e vacinas que estão em

utilização nas salas de vacinação.

O projeto deixa uma gama de oportunidades para implementações futuras,

como melhorias e refinamentos dos relatórios, relatórios estatísticos, controle das

campanhas vacinais constantes no calendário estadual e federal que não estão

contempladas no atual sistema, geração automática de carteiras vacinais e mais

alguns recursos que podem ser melhorados ou adicionados conforme as

necessidades administrativas.

70

REFERÊNCIAS

DEITEL, H. M.; DEITEL P.J. Java: Como Programar. 6. Ed. São Paulo: Person

Prentice Hall, 2005.

SCHMITZ, D. Dominando Flex e Java. São Paulo: {s.e}, 2010;

GONÇALVES, E. Desenvolvendo Aplicações WEB com NetBeans IDE 6. 1. Ed.

São Paulo: Ciência Moderna, 2008.

GASSNER, D. Flash Bulder 4 and Flex 4 Bible. Indianapolis: Wiley Publishing, Inc.

2010.

KEITH, M.; SCHNICARIOL M. Pro JPA 2 - Mastering the Java™ Persistence API. United States od America: Apress, 2009.

FUNASA. Ministério da Saúde. Manual de Normas de Vacinação. 4.ed. Brasília,

DF, 2001 279 p.

TEOREY T., LIGHTSTONE S., NADEAU T.; tradução de Daniel Vieira. Projeto e

modelagem de banco de dados. Rio de Janeiro: Elsevier, 2007.

MILANI, A. PostgreSQL – Guia do Programador. Novatec, 2008.

BINI, L. A. NEURALIZE.ME – Implementação de Rede Neural Artificial de

Kohonen em Plataforma Web. 2009. Tese (Graduação em Ciências da

Computação) – Instituto de Ensino Superior Thathi, Araçatuba.

71

WARD, J. BlazeBench: Why you want AMF and BlazeDS. 2007. Disponível em:

<http://www.jamesward.com/2007/12/12> Acesso em: 20 mai. 2011.

MENDES, M. O Modelo Unificado para os Frameworks de Persistência em Java

– JPA. 2007. Disponível em: <http://blog.marcomendes.com/2007/04/10> Acesso

em: 02 jun. 2011.

FEIJÓ, R. B.; SÁFADI, M. A.; Imunizações: três séculos de uma história de sucessos

e constantes desafios. Jornal de Pediatria. Rio de Janeiro, V 82, Nº3(Supl), 2006.

JAVA. Saiba mais sobre a tecnologia Java. Disponível em:

<http://www.java.com/pt_BR/about> Acesso em: 26 abr. 2011.

BLAZEDS. BlazeDS overview. Disponível em:

<http://opensource.adobe.com/wiki/display/blazeds/Overview> Acesso em: 26 abr.

2011.

FLEX. Visão geral do Flex. Disponível em:

<http://www.adobe.com/br/products/flex/overview> Acesso em: 02 mai. 2011.

POSTGRESQL. Documentação. Disponível em:

<http://www.postgresql.org.br/docs> Acesso em: 14 mai. 2011.

JASPERREPORTS. Documentation. Disponível em:

<http://jasperforge.org/projects/jasperreports> Acesso em: 26 mai. 2011.

NETBEANS. NetBeans ide 6.9 documentation. Disponível em:

<http://netbeans.org/kb/69/> Acesso em: 30 abr. 2011.

72

APÊNDICE

APÊNDICE A – Manual de integração Java, BlazeDS, Hibernate,

PostgreSQL, Flex e Ireports

Neste manual será apresentado a união de várias tecnologias que

possibilitam o desenvolvimento utilizando o padrão MVC (Model View Control –

Modelo, Controle e Visão). Para tanto faz-se a integração do Flex como Front End

(camada de apresentação) e o Java como Back End (camada de negócios),

juntamente com o framework Hibernate na camada de persistência de dados no

PostgreSQL. Também será utilizado o IReports para geração de relatórios em PDF.

Inicialmente tratou-se as configurações do IDE (ambiente de desenvolvimento

integrado) para criação da aplicação, para tanto será utilizado o NetBeans 6.9 na

sua versão completa onde pode ser encontrada facilmente para download no site do

desenvolvedor da IDE1.

No momento da instalação deve-se marcar a instalação do servidor Apache

Tomcat que será utilizado para o desenvolvimento deste projeto. Será necessário

também o BlazeDS que é o responsável em fazer a ponte entre Flex e o Java, No

site da Adobe2 deve-se fazer o download do BlazeDS 4.x pacote binário. Para

concluir a configuração do NetBeans o PostgreSQL versão 9.x precisa estar

instalado, para criação do projeto com suporte para o Hibernate que pode ser

encontrada no site da PostgreSQL3.

1 http://www.netbeans.org

2 http://opensource.adobe/wiki/display/blazeds/download

3 http://www.postgresql.org/download

73

Neste primeiro momento serão feitas as configurações necessárias para que

o NetBeans possa interpretar os arquivos gerados pelo Flex. Então o primeiro passo

é criar um novo projeto do tipo Java Web, como descrito na figura 1.

Figura 1: Tela para iniciar um novo projeto no NetBeans Fonte: Elaborado pelo autor

Selecionado as opções para criação do projeto Java Web, clique em Próximo

para que se possa configurar o nome do projeto, local onde será salvo o mesmo e

defini-lo como projeto principal, como descrito na figura 2.

Figura 2: Tela de identificação do projeto no NetBeans Fonte: Elaborado pelo autor

74

Feito o preenchimento dos campos necessários, clique em Próximo para

escolher o servidor de aplicação. Neste caso, será utilizado o Apache Tomcat 6.0.26

e logo após clique em finalizar.

Até o momento foi criado um projeto no NetBeans do tipo Java Web que por

padrão está pronto para trabalhar com edição de arquivos JSP (Java Server Pages).

Após isso, configura-se o BlazeDS neste projeto recém criado. Para isso deverá ser

feito o download do arquivo no site da Adobe4, o arquivos deve ser descompactado

que resultará na criação de dois arquivo, como descrito na figura 3.

Figura 3: Arquivo BlazeDS descompactado Fonte: Elaborado pelo autor

Será trabalhado o arquivo com extensão WAR (Web Archive). A extensão

WAR tem as mesmas propriedades de uma arquivo ZIP e como somente será usado

algumas propriedades do BlazeDS no projeto, se fará necessário a descompactação

do arquivo WAR, mas para isso deve-se de renomear o arquivo WAR para ZIP,

como podem ver na figura 4.

Figura 4: Arquivo BlazeDs depois de renomeado Fonte: Elaborado pelo autor

Como o arquivo, agora renomeado, é possível efetuar a descompactação. Da

finalização desse processo será gerado dois diretórios e dois arquivos HTML, como

pode ser visto na figura 5.

4 http://opensource.adobe/wiki/display/blazeds/download

75

Figura 5: Arquivos após a descompactação do BlazaDS.zip Fonte: Elaborado pelo autor

Com os arquivos do BlazeDS descompactados, deve-se configurá-los no

NetBeans, clicando em Projetos > Bibliotecas, como descrito na figura 6.

Figura 6: Painel de projetos do NetBeans Fonte: Elaborado pelo autor

Clique com o botão direito do mouse em cima da pasta Bibliotecas e escolha

a opção Adicionar Biblioteca.

Figura 7: Janela adicionar biblioteca do NetBeans Fonte: Elaborado pelo autor

76

Na janela “Adicionar Biblioteca” que já existem algumas bibliotecas

disponíveis para serem adicionadas ao projeto, porém será criada uma nova

biblioteca chamada BlazDS4. Para isso clique no botão Criar.

Figura 8: Janela para criar uma nova biblioteca do NetBeans Fonte: Elaborado pelo autor

Nesta janela preencha o nome da biblioteca e escolha o tipo da biblioteca que

por padrão vem como Bibliotecas de classe, feito isso clique em OK.

Figura 9: Janela para personalizar biblioteca do NetBeans Fonte: Elaborado pelo autor

Na janela de personalização da biblioteca, adição dos JARs na biblioteca será

efetuada. Esses arquivos JARs estão dentro do blazeDS. Clique no botão “Adicionar

JAR/pasta...” e busque o local onde foi descompactado os arquivos do blazeDS.

Entre na pasta WEB-INF/lib e selecione todos os arquivos de dentro da pasta.

77

Figura 10: Janela de busca dos JARs que irão fazer parte da biblioteca Fonte: Elaborado pelo autor

Figura 11: Janela de personalização de biblioteca após a inclusão dos JARs Fonte: Elaborado pelo autor

Feito a adição dos arquivos na janela “Personalizar biblioteca” clique em OK.

Logo abrirá a janela “Adicionar Biblioteca”.

78

Figura 12: Janela adicionar biblioteca agora com a nova biblioteca BlazeDS Fonte: Elaborado pelo autor

Selecione a biblioteca que acabou de ser criada (BlazeDS4) e clique em

“Adcionar Bliblioteca”. Assim o processo de criação da biblioteca do BlazeDS é

finalizado, para ver o resultado basta expadir a opção biblioteca do projeto que a

nova biblioteca já adicionada ao projeto.

Figura 13: Painel de projetos > bibliotecas Fonte: Elaborado pelo autor

Feito a adição da biblioteca do BlazeDS no projeto, agora é preciso criar os

locais onde os serviços expostos pela aplicação, deverão estar no momento da

complição da aplicação, esses serviços no entando devem ficar claros para o

79

BlazeDS e para o compilador do Flex, para isso são utilizados diversos arquivos de

configuração indicando esses locais que são padronizados . Na aba Projetos localize

a pasta WEB-INF e clique nela com o botão direito, selecionando a opção novo >

diretório.

Figura 14: Painel de opção para o item selecionado Fonte: Elaborado pelo autor

Selecionado a opção deve-se dar o nome de flex ao novo diretório.

Figura 15: Painel de projetos com o novo item adicionado Fonte: Elaborado pelo autor

Agora, precisa-se localizar onde foi descompactado o BlazeDS e achar a

pasta WEB-INF/flex, selecionar todos os arquivos que estão dentro da pasta, copiá-

lo e colar os arquivos no projeto.

80

Figura 16: Local de onde serão copiados os arquivos e para onde serão colados Fonte: Elaborado pelo autor

Feito a cópia dos arquivos do diretório flex para o projeto, é necessário

efetuar algumas alterações no arquivo web.xml, para que o mesmo começe a

visualizar a biblioteca BlazeDS e fazer funcionar o gerenciador de mensagens do

BlazeDS.

Na pasta WEB-INF do arquivo descompactado do BlazeDS, tem o arquivo

web.xml, clique nele com o botão direito do mouse e selecione a opção Editar, que o

mesmo abrirá no Bloco de Notas.

Figura 17: Arquivo web.xml aberto no Bloco de Notas Fonte: Elaborado pelo autor

Feito isso selecione esse trecho do arquivo:

81

 <listener> <listener-class>flex.messaging.HttpFlexSession</listener-class> </listener>  <servlet> <servlet-name>MessageBrokerServlet</servlet-name> <display-name>MessageBrokerServlet</display-name> <servlet-class>flex.messaging.MessageBrokerServlet</servlet-class> <init-param> <param-name>services.configuration.file</param-name> <param-value>/WEB-INF/flex/services-config.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet>  <servlet-mapping> <servlet-name>MessageBrokerServlet</servlet-name> <url-pattern>/messagebroker/*</url-pattern> </servlet-mapping>

Agora vá ao projeto do NetBeans na aba Projetos dê um duplo clique o no

arquivo web.xml, o mesmo se abrirá em modo layout de configuração. Mude para

opção XML.

82

Figura 18: Arquivo web.xml aberto no NetBeans em modo “Geral” Fonte: Elaborado pelo autor

Figura 19: Arquivo web.xml aberto no NetBeans em modo “XML” Fonte: Elaborado pelo autor

Neste modo, percebe-se que o arquivo web.xml criado no projeto do

NetBeans não está ainda pronto para trabalhar com o BlazeDS. Porém, logo abaixo

da tag <session-config/>, cole o trecho de código selecionado anteriormente do

arquivo web.xml do BlazeDS. O arquivo web.xml final ficará assim:

<?xml version="1.0" encoding="UTF-8"?>

<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"> <session-config>

83

<session-timeout> 30 </session-timeout> </session-config>  <listener> <listener-class>flex.messaging.HttpFlexSession</listener-class> </listener>  <servlet> <servlet-name>MessageBrokerServlet</servlet-name> <display-name>MessageBrokerServlet</display-name> <servlet-class>flex.messaging.MessageBrokerServlet</servlet-class> <init-param> <param-name>services.configuration.file</param-name> <param-value>/WEB-INF/flex/services-config.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet>  <servlet-mapping> <servlet-name>MessageBrokerServlet</servlet-name> <url-pattern>/messagebroker/*</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> </web-app>

Agora da mesmo forma que foi criada a pasta flex, deve-se de criar uma

chamada “swf” que servirá de local para compilação dos arquivos gerados pelo

Adobe Flash Builder. Essa nova pasta deverá ser criada no mesmo nível da pasta

WEB-INF.

84

Figura 20: Painel de projetos com a nova pasta já criada Fonte: Elaborado pelo autor

A configuração do BlazeDS no NetBeans está quase finalizada. Falta

somente configurar os commons-logging que é utilizado pelo BlazeDS. Para isso,

prepare o local onde ficará guardado o arquivo de configuração. Vá na raiz do

projeto e clique com o botão direito, selecionando a opção propriedades.

Com isso a janela “Propriedades do Projeto” irá se abrir. Nela, selecione a

opção código-fonte e cliente em adicionar pasta.

Figura 21: Janela de propriedades do projeto Fonte: Elaborado pelo autor

85

Abrirá uma janela para Adicionar Pastas de códigos-fonte, selecione a opção

“criar nova pasta” e nomeie a nova pasta de “logging” e logo após clique em abrir.

Figura 22: Janela para adicionar uma nova pasta de códigos-fonte Fonte: Elaborado pelo autor

Criado a pasta de logging, mude o nome do rótulo para “Configurações de

Logging”.

Figura 23: Janela de propriedades do projeto, com a nova pasta criada Fonte: Elaborado pelo autor

86

Clique em OK para finalizar, assim que voltar ao projeto perceberá que a

pasta que foi criada está logo acima para pasta Pacotes de código-fonte.

Figura 24: Painel de projetos com a nova pasta de código-fonte criada Fonte: Elaborado pelo autor

Agora, novamente, vá no local onde foi descompactado o BlazeDS, localize a

pasta WEB-INF/classes e copie o arquivo commons-logging para a pasta que foi

criada no projeto do NetBeans.

Figura 24: Painel de projetos Fonte: Elaborado pelo autor

Para finalizar a configuração do BlazeDS no NetBeans, deve-se de desabilitar

a opção “Implantar ao salvar” do Tomcat para evitar travamento caso haja muitas

alterações consecutivas no projeto. Para isso clique na raiz do projeto com o botão

direito e vá em propriedades. Selecione a opção Executar e desmarque a opção

“Implantar ao salvar”. Dê um OK e pronto.

87


Para saber se o BlazeDS está funcionando corretamente é necessário

executar o projeto. Se o BlazeDS estiver funcionando corretamente irá aparecer no

navegador a mensagem “Hello World”.

Continuando na IDE do NetBeans , agora deve-se criar as entidades em Java

com persistência em banco de dados pelo Hibernate, sendo que para este projeto

será utilizado o modelo de persistência objeto-relacional, onde somente será criado

o banco de dados no PostgreSQL e a tabelas serão criadas pela classe Java.

Primeiro deve-se abrir o PostgreSQL e criar o banco com o nome de

ManualIntegracao. Clique com o botão direito em Databases > New Database

Figura 26: Painel de controle do banco de dados PostgreSQL Fonte: Elaborado pelo autor

88

Informe o nome do banco de dados a ser criado no campo “Name” e clique

em OK para finalizar.

Figura 27: Painel para criação de um novo banco de dados do PostgreSQL Fonte: Elaborado pelo autor

Pronto, o banco de dados que será utilizado no projeto já está criado.

Figura 28: Painel de controle do PostgreSQL com o novo banco criado Fonte: Elaborado pelo autor

89

No NetBeans, no Pacote de códigos-fontes, deve-se criar 3 (três) novos

pacotes que irão se chamar entidades, persitencia e servicos, como descrito na

figura abaixo:


Com os pacotes prontos agora, deve-se criar uma classe java, porém com

uma diferença que é a de usar uma classe de persistência que é responsável em

refletir os objetos nela contido em uma tabela de banco de dados (isso será

explicado detalhadamente posteriormente). Clique com o botão direito no pacote

entidades e selecione a opção novo > outro.

Irá abrir uma janela onde poderá ser escolhido o tipo de arquivo, então deve-

se selecionar a categoria persistense e o tipo Classe da entidade e clicar em

próximo.

Figura 30: Janela para criação de um novo arquivo Fonte: Elaborado pelo autor

90

Na janela “Novo Classe da entidade” dê o nome a classe de enderecos.

Marque a opção “criar unidade de persistência” que é a responsável em ligar as

classes java diretamente com o banco de dados criado, possibilitando a persistência

dinâmica em banco. É importante esclarecer que o tipo de chave primária é aberta a

escolha do programador, porém quando se trabalha com Hibernate deve-se estar

muito atento já que o mesmo cria uma tabela genérica de Ids. Por exemplo, o

Hibernate cria uma tabela única para Id’s, ou seja, se persistir um objeto do tipo

endereço, o framework guarda o id 1 para esse objeto. Se persistir um objeto do tipo

cliente, quarda-se (na mesma tabela de Id’s) o número 2; e assim sucessivamente.

Figura 31: Janela para criação da nova classe da entidade Fonte: Elaborado pelo autor

Na janela de configuração de provedor de banco de dados deve-se selecionar

na opção biblioteca de persistência o Hibernate(JPA 1.0) e na conexão de banco de

dados, pode-se selecionar um banco de dados existente e já configurado se assim

estiver, ou igual a esse projeto deve-se criar uma nova conexão. Já na opção

estratégia de geração de tabela aconselha-se deixar marcada a opção criar, pois

quando a tabela não existir o mesmo gera automaticamente e caso já existe e

Hibernate somente persiste o objeto.

91

Figura 32: Janela para obtenção do provedor e banco de dados Fonte: Elaborado pelo autor

Na janela “Nova Conexão com Banco de Dados” deve-se primeiramente

selecionar o driver do banco de dados, sendo que alguns já vem instaladosno

NetBeans e os que não estiverem presentes são facilmente instalados pelo

programador, como neste projeto está se fazendo o uso do PostgreSQL o mesmo já

tem driver no NetBeans, para configurar a conexão deve-se preencher os campos e

quando finalizado, clique em OK conforme a figura abaixo:

Figura 33: Janela de nova conexão de banco de dados Fonte: Elaborado pelo autor

92

Automaticamente ao clicar em OK a aba “Avançado” será habilitada e nela

deve-se selecionar o esquema onde será persistido as tabelas, no caso do postgres

como padrão seleciona-se o esquema “public”.

Finalizado esse processo volta-se para a janela de configuração de provedora

de dados, porém percebe-se que a conexão com o banco de dados está

selecionada, restando apenas clicar em finalizar.

Figura 34: Janela com a conexão de banco de dados já criado Fonte: Elaborado pelo autor

Finalizado o processo de configuração do Hibernate é criado a classe java,

porém contendo todas as anotações necessárias para o funcionamento do

Hibernate. Percebe-se que juntamente com a classe já foram carregadas todas as

classes de persistência da API Java, sendo que a sinalização @Entity mostra para o

Hibernate que a classe enderecos é uma entidade de persistência em banco de

dados com as devidas implementações de serialização dos objetos da classe com a

marcação do @Id para demostrar que na classe tem um atributo identiicador único

com geração automática e controlada pela unidade de persistência. E a anotação

@GenerateValue indica a unicidade na criação de id para as classes.

93

Figura 35: Trecho do código criado pelo Hibernate Fonte: Elaborado pelo autor

Para esta classe criada somente deve-se colocar agora os atribuitos cep,

logradouro e bairro e, logo após, gerar os getters e setters do mesmo, conforme

figura 36.

Figura 36: Trecho do código com as implementações feitas Fonte: Elaborado pelo autor

94

Finalizado a classe da entidade, cria-se a classe persistência que é a

JPAController, ou seja, a classe detentora de todos os métodos de persistência em

banco de dados, que trabalha com a linguagem HQL (Hibernate Query Language),

na classe controladora JPA fica descrito o CRUD (Create, Read, Uptade e Delete –

Criação, Leitura, Atualização e Deleção) do sistema com todos os métodos de

inclusão, alteração, exclusão e consulta de dados. Para entender melhor como

funciona a classe controladora JPA, consulte a documentação do Hibernate no site

http://www.hibernate.org. Para criar a classe de persistência, clique com o botão

direito em cima do pacote persistencia e selecione a opção novo > outro.

Na janela do tipo de arquivo, escolha a categoria Persistence e o tipo de

arquivo Classes de controlador do JPA de casses entidades e logo em seguida

clique em próximo.

Figura 37: Janela de nova classe do controlador do JPA de classes entidades Fonte: Elaborado pelo autor

Na janela de nova Classes do controlador do JPA perceba que na coluna

classes de entidade disponíveis está a classe enderecos que acabou de ser criada.

Selecione-a e clique em adicionar e, logo após, no botão próximo.

95

Figura 38: Janela para escolha do pacote onde será gerada a classe Fonte: Elaborado pelo autor

Nesta janela, selecione a localização que é Pacotes de códigos-fonte e

pacote que é o persistencia e clique em finalizar.

Feito a classe JPA, será criado a classe enderecosJpaController.java e

também foi criado um novo pacote chamado persistencia.exceptions que é

responsável em guardar as exeções da controladora JPA. Já a classe JPA gerada

pelo sistema contém os elementos básicos do CRUD via Hibernate.

Figura 39: Trecho de código da classe controladora JPA que foi criada Fonte: Elaborado pelo autor

96

E agora, para finalizar, deve-se fazer a programação da classe java

responsável em chamar os serviços que futuramente será exposto para o Flex

utilizá-lo para fazer a persitência em banco de dados e também as consultas. Então

com o botão direito do mouse clique no pacote serviços, opção nova Classe Java.

Para criar a classe que será responsável em controlar todos os serviços para tanto

será dado o nome a essa classe de ServicosEnderecos e será colocada no pacote

servicos que anteriormente foi criado.

Com a classe ServicosEnderecos.java criada, deve-se criar os métodos de

chamada para que, futuramente, o Flex possa acessá-los por meio do BlazeDS, afim

de manipular todas as funcionalidades nela contidada, o trecho de códigos abaixo

descreve todas a funcionalidades que serão usadas nesse projeto.

public class ServicosEnderecos {

Figura 40: Trecho de código da classe de serviços que foi criada Fonte: Elaborado pelo autor

97

Agora com o NetBeans configurado para funcionar aplicações em Flex com o

mediador BlazeDs, deve-se fazer a configuração da IDE Adobe Flash Buider 4

Premium que será utilizada para criar o Front End (camada de apresenatação) do

projeto, no entanto o Adobe Flash Builder 4 Premium é de licença paga, porém para

o desenvolvimento do projeto sua versão trial será utilizada pois, é facilmente

achada no site da Adobe5 para download.

Figura 41: Visão geral do Adobe Flash Builder 4 Premium Fonte: Elaborado pelo autor

Com o Flash Builder inciado, deve-se criar um novo projeto, completamente

ligado ao projeto criado no NetBeans, clique em File > New > Flex Project.

Na janela “New Flex Project” deve-se preencher os campos da seguinte

forma, no project name: coloque o mesmo nome que foi colocado no projeto do

NetBeans com o sufixo “GUI”, isso para demostrar o tratamento da camada de visão

do projeto. No caso deste projeto, o nome ficaria ManualIntegracaoGUI. Em Project

location desmarque a opção “Use default location” e selecione o local onde se

encontra o seu projeto do NetBeans, como por exemplo no projeto demonstrado o

caminho será “D:\Projects Netbeans\ManualIntegracao\ManualIntegracaoGUI”. Já no

5 http://www.adobe.com/downloads/

98

Application type, selecione a opção Web e por fim em Server tecnology, deve-se

selecionar a opção J2EE e BlazeDS, como descrito na figura abaixo:

Figura 42: Janela para criação de novos projetos Fonte: Elaborado pelo autor

Logo após clicar em próximo irá aparecer uma nova janela para configuração

do servidor que o BlazeDS irá funcionar, para isto deve-se modificar os campos:

Root folder, que deve apontar para a pasta onde se encontra o projeto do

NetBeans, exatamente no diretório onde estão as pasta WEB-IBF, META-INF e swf.

Para este exemplo, o caminho será este D:\Projects

Netbeans\ManualIntegracao\web

Root URL deve-se colocar o endereço da raiz da aplicação que será executa,

neste caso a aplicação do NetBeans, caso esteja utilizando o Tomcat instalado pelo

NetBeans o caminho será algo parecido com isso

http://localhost:8084/ManualIntegracao/

99

Context root que é onde fica definido a raiz do contexto da aplicação, nesta

caso o / ManualIntegracao

Output folder neste campo precisa-se ter cuidado para não idicar o local

errado, pois é aqui que fica definido para onde o projeto do Flash Builder será

compilado, neste caso deve-se indicar a pasta swf do projeto criado no NetBeans

neste exemplo, o caminho ficará desta forma: D:\Projects

Netbeans\ManualIntegracao\web\swf

Figura 43: Janela de configuração do servidor Java Fonte: Elaborado pelo autor

Note que após clicar no botão Finish, automaticamente será aberto um

arquivo com o mesmo nome de projeto com extensão MXML que é onde será criada

a interface da aplicação. Para saber se as configurações estão corretas, deve-se

mudar a perspectiva do Flash Builder para Design e iremos criar um botão e mandar

salvar, para que o mesmo compile o projeto no NetBeans.

100

Figura 44: Flash Builder em modo design Fonte: Elaborado pelo autor

Agora, entre novamente no NetBeans para confirmar se o projeto do Flash

Builder está sendo compilado corretamente dentro da pasta swf do projeto.


Como o projeto do NetBeans é por padrão um projeto Java Web e que no

momento da execução ele irá executar o index.jsp e não o arquivo

ManualIntegracaoGUI.html como desejado, deve-se fazer um redirecionamento na

101

página index para abrir a página que foi construida no Flex, como demonstrado na

figura 46.

Figura 46: Trecho do código do arquivo index.jsp Fonte: Elaborado pelo autor

Agora execute o projeto e verique se o botão que foi criado no projeto do

Flash Buider aparece no navegador, caso apareça as configurações feita no Flash

Builder foram concluidas com sucesso.

Vamos criar agora a interface para a nossa aplicação no Flash Builder como,

pode ser visto na figura 47.

Figura 47: Interface criada com o Flex Fonte: Elaborado pelo autor

102

Figura 48: Código-fonte da interface Fonte: Elaborado pelo autor

Agora inicia-se a produção das funcionalidades a tela, mas primeiramente

deve-se de expor a classe ServicosEndrecos.java do projeto feito no NetBeans para

o Flash Builder, então mapeia-se a classe ServicosEnderecos.java no remoting-

config.xml que está dentro WEB-INF\Flex, para tanto será colocado dentro do

arquivo a tag <destination> que é iniciada para indicar o destino que a camada visão

deverá procurar para executar as funcionalidades da classe Java exposta.

103

Figura 49: Código-fonte do arquivo web.xml Fonte: Elaborado pelo autor

Feito isso no NetBeans, as implementações no projeto Java está finalizadas.

Agora, o trabalho será diretamente no Flash Builder para que ele reconheça a classe

exposta do no Java.

Primeiro no ManualIntegracaoGUI.MXL entre as tags <fx:Declarations> e

</fx:Declarations>, implementa-se as conexão com o objeto remoto java, conforme a

figura 50.

Figura 50: Trecho do código-fonte do Flex Fonte: Elaborado pelo autor

Na linha de comando em destaque na figura 46 mostra a criação da conexão

via BlazeDS do Flex com o Java, percebe-se que na tag “<s:RemoteObject>”

encontra-se um id que será o norteador para as chamadas de serviços dentro do

104

Flex, a tag destination é a mesma que foi utilizada no arquivo web.xml do Java, ou

seja, tem a funcionalidade de indicar onde buscar o serviço exposto no Java e por

fim o ShowBusyCursos é que garante a interatividade entre os objetos Flex e Java.

Feito a conexão com o objeto remoto, deve-se agora criar os métodos para

manipulação dos dados no Java, porém para isso será necessário a criação

ActionScript que constará as mesmas propriedades da classe enderecos.java, isto é

preciso fazer porque quando se envia valor (primitivos e/ou objetos) atráves do canal

AMF implementado pelo BlazeDS os valores passam por uma conversão e o

BlazeDS funciona como um tradutor para que isso seja realizado com sucesso.

O canal AMF funciona da seguinte maneira, quando o cliente serializa objetos

de ActionScript para AMF e envia para a camada Java, o BlazeDS deserializa os

objetos em AMF convertendo-os para objetos Java, para se entender essa

conversão segue abaixo a tabela com os principais de conversões utilizadas em

Java e Flex.

Tabela 01 Conversão das variáveis da tecnologias envolvidas Fonte: Elaborado pelo autor

Variável em Java Variável em ActionScript

Int, Long, Double Number

String String

Date, Timestamp, Time Date

Boolean Boolean

List, ArrayList, Array, Map Array

Para criação da classe ActionScript do projeto Flash Buider, primeiro clique no

pacote padrão selecione a opção New > Package e neste nosso pacote dê o nome

de entidades, novamente clicando encima do pacote recèm criado com o botão

direito selecione a opção New > ActionScript Class e dê o nome de Enderecos,

assim como é a classe Java.

105

Figura 51: Trecho do código-fonte da classe ActionScript Fonte: Elaborado pelo autor

Note que já foi implementado algumas linhas de comando que é descrito da

seguinte forma:

[Bindable] = Essa tag informa que os objetos do tipo Estado podem ser

amarrados aos componentes gráficos e caso o estado do objeto seja alterado, ou

seja, alguma de suas propriedades tenha o valor alterado, essas mudanças serão

refletidas automaticamente no componente gráfico que o estiver usando.

[RemoteClass(alias="entidades.Enderecos")] = Essa tag é muito importante

porque é ela que diz que essa classe é uma classe remota, ou seja, que os objetos

dela podem ser enviadas via AMF, na propriedade “alias” temos o nome completo

para classe Java que corresponde, ou seja, deve-se indicar o pacote e o nome da

classe Java a que a classe ActionScript se refere.

Feito isso perceba que quando dado o nome a variável é implementado o “_”

antes do nome, isso é feito para que não haja confito com o nome da propriedade

que é criada para a variável privada, isso fica mais claro quando fazemos os gets e

sets da classe, pois no retorno do get não podemos declarar o mesmo nome que a

propriedade, por exemplo propriedade “id”, variável “_id”, para ficar mais claro, na

figura abaixo está o código completo.

106

Figura 52: Código-fonte da classe ActionScript Fonte: Elaborado pelo autor

Finalizado a classe ActionScrpt volta-se para a programação da interface.

Inicalmente faz-se a criação do metodo cadastrar, onde dentro da tag

<s:RemoteObject> será incluido a tag <s:method> que é responsável em cuidar do

comportamento de uma determinada ação por meio de um retorno chamado result

para as interações concluidas com sucesso e um outro retorno com o nome da fault

que trata dos erros que podem ocorrer no aplicativo, o código-fonte ficará conforma

a figura 53.

107

Figura 53: Código-fonte do arquivo MXML com as funcionalidades Fonte: Elaborado pelo autor

108

Perceba que foi criado os métodos result e fault e também um método

chamado cadastrar que tem por finalidade pegar os dados digitados no formulário,

criar um objeto do tipo endereço e enviar para o java gerar a persistência. É

importante destacar como a classe ActionScript se comporta, pensando o como a

classe java trabalha, ve-se que a atribuição de valores para os campos, é idêntica ao

Java, ou seja, primeiro faz-se um set dos valores para somente depois consegui

gravar no banco de dados.

Para o funcionamento total das funcionalidades do CRUD no aplicativo tem de

criar ainda os métodos alterar, excluir e listar, sendo que os métodos alterar e excluir

não difere em muito ao método cadastrar. Deve-se criar um método result e um fault

para o retorno do resultado da ação e como não há a necessidade fazer o

tratamento de erros do método fault que será o mesmo para todos, somente se fará

necessário a criação dos métodos result para cada ação, já o método listar. Isso

será feito de forma dinâmica, ou seja, assim que abrirmos o aplicativo,

automaticamente o datagrid criado irá receber os dados já cadastrados no banco de

dados e também toda vez que cadastrar, alterar ou excluir esse mesmo datagrid

será atualizado. Para isso, tem-se algumas coisas novas como a recepção dos

dados em um ArrayColletion do ActionScript que tem a mesma equivalência do

ArrayList do Java, porém a diferença é que o ArrayColletion recebe as informações e

o despõe em forma de uma lista em XML para que seja tratado dentro das

aplicações feitas em Flex como será utilizado no cabeçalho da aplicação MXML o

comando “createComplete” terá a função de chamar o método listarEnderecos()

para popular o datagrid, assim que a aplicação for carregada, como pode-se ver

abaixo:

Código-fonte completo:

<?xml version="1.0" encoding="utf-8"?>

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"

xmlns:s="library://ns.adobe.com/flex/spark"

creationComplete="listaEnderecos()"

xmlns:mx="library://ns.adobe.com/flex/mx"

minWidth="955" minHeight="600">

<fx:Script>

<![CDATA[

import entidades.Enderecos;

import mx.collections.ArrayCollection;

import mx.controls.Alert;

109

import mx.rpc.events.FaultEvent;

import mx.rpc.events.ResultEvent;

[Bindable]

private var catalogoEnderecos:ArrayCollection;

//Método responsável em chamar o objeto remoto e efetuar

o cadastro

private function cadastrar(event:MouseEvent):void{

//Cria um objeto do tipo enderecos para receber os

valores do formulário

var e:Enderecos = new Enderecos();

e.cep = cep.text;

e.logradouro = logradouro.text;

e.bairro = bairro.text;

//Chama o serviço exposto no Java para persistência

dos dados

servicos.cadastrar(e);

}

//Método Fault genérico que traz o erro descrito quando

houver

private function faultResult(event:FaultEvent):void{

Alert.show(event.fault.toString(),"Erro da

Aplicação");

}

//Método Result para cadastro de novos registro

private function resultCadastro(event:ResultEvent):void{

Alert.show("Cadastro Efetuado com

Sucesso!","SisDEMO");

limparCampos(); //Chama o método para limpar os

campos do formulário

listaEnderecos(); //Chama o método para atualizar o

datagrid de endereços

}

//Método para efetuar limpeza dos campos do formulário e

focar o ponteiro para um novo cadastro

private function limparCampos():void{

cep.text = "";

logradouro.text = "";

bairro.text = "";

cep.setFocus();

}


alteração de um determinado objeto

private function alterar(event:MouseEvent):void{

//Cria um objeto do tipo enderecos para receber os

valores do formulário

var e:Enderecos = new Enderecos();

e.id = datagridEnderecos.selectedItem.id;

e.cep = cep.text;

e.logradouro = logradouro.text;

e.bairro = bairro.text;


dos dados

servicos.alterar(e);

}

110

//Método Result para alteração de registros existentes no

BD

private function resultAlteracao(event:ResultEvent):void{

Alert.show("Alteração Efetuada com






}


deleção de um determinado objeto

private function excluir(event:MouseEvent):void{

//Atribui o id para uma variável

var id:Number = datagridEnderecos.selectedItem.id;


dos dados

servicos.excluir(id);

}

//Método Result para alteração de registros existentes no

BD

private function resultExcluir(event:ResultEvent):void{

Alert.show("Exclusão Efetuada com






}

//Método responsável em chamar o objeto remoto para gerar

o ArrayColletion

private function listaEnderecos():void{

servicos.listaEnderecos();

}

//Método Result para a população do datagrid de endereços

private function resultLista(event:ResultEvent):void{

catalogoEnderecos = event.result as

ArrayCollection;

}

]]>

</fx:Script>

<fx:Declarations>



<s:RemoteObject id="servicos" destination="ServicosEnderecos"

showBusyCursor="true">

<s:method name="cadastrar" result="resultCadastro(event)"

fault="faultResult(event)"/>

<s:method name="alterar" result="resultAlteracao(event)"


<s:method name="excluir" result="resultExcluir(event)"


<s:method name="listaEnderecos"

result="resultLista(event)" fault="faultResult(event)"/>

</s:RemoteObject>

</fx:Declarations>

111

<s:Panel x="43" y="40" width="454" height="351" title="Gerenciamento

de Endereços">

<s:Label x="10" y="20" text="Cep:" fontWeight="bold"/>

<s:Label x="10" y="50" text="Logradouro:" fontWeight="bold"/>

<s:Label x="9" y="80" text="Bairro:" fontWeight="bold"/>

<s:TextInput x="39" y="15" id="cep"

text="{datagridEnderecos.selectedItem.cep}"/>

<s:TextInput x="84" y="45" width="290" id="logradouro"

text="{datagridEnderecos.selectedItem.logradouro}"/>

<s:TextInput x="51" y="75" width="184" id="bairro"

text="{datagridEnderecos.selectedItem.bairro}"/>

<s:Button x="10" y="105" label="Cadastrar"

click="cadastrar(event)"/>

<s:Button x="100" y="105" label="Alterar"

click="alterar(event)"/>

<s:Button x="180" y="105" label="Excluir"

click="excluir(event)"/>

<s:Button x="262" y="105" label="Relatório"/>

<mx:DataGrid x="10" y="133" width="432" height="175"

id="datagridEnderecos" dataProvider="{catalogoEnderecos}">

<mx:columns>

<mx:DataGridColumn headerText="Cep" dataField="cep"

fontSize="11" width="80"/>

<mx:DataGridColumn headerText="Logradouro"

dataField="logradouro" fontSize="11" width="200"/>

<mx:DataGridColumn headerText="Bairro"

dataField="bairro" fontSize="11"/>

</mx:columns>

</mx:DataGrid>

</s:Panel>

</s:Application>

Agora, deve-se implementar ao projeto o relatório criado pelo IReports,

voltado, neste momento, a trabalhar com o NetBeans IDE. O primeiro passo é ir no

site do JasperReports6 para fazer o download dos iReport-4.0.2-plugin,

jasperreports-4.0.2-project e o jasperreports-4.0.2.jar.

Já com os arquivos baixados, vamos instalar o plug-in do IReports para o

NetBeans, clique no menu Ferramentas > Plug-ins.

6 http://jasperforge.org/

112

Figura 54: Janela de Plug-ins do NetBeans Fonte: Elaborado pelo autor

Com a Janela de Plug-ins aberta, clique na aba “Baixados” e logo em seguida

clique no botão “Adicionar Plug-ins..”, feito isso vá na pasta onde foi descompactado

o arquivo iReport-4.0.2-plugin.zip e selecione todos os arquivos disponíveis.

Figura 55: Janela para seleção dos plug-ins a serem instalados Fonte: Elaborado pelo autor

113

Feito isso, o botão instalar será habilitado, então é necessário clicar no

mesmo e seguir as instruções para finalizar a instalação, após instalado os plug-ins

irão aparecer na aba “Instalado”, conforme figura 56.

Figura 56: Janela com a opção dos instalado aberta Fonte: Elaborado pelo autor

Realizado as instalações necessárias, vamos criar-se uma nova pasta, no

projeto para fins exclusivo de armazenar os relatórios e seus componentes

necessários. Clique com o botão direito sobre a raiz do projeto e selecione a opção

propriedades.


114

Com a janela de propriedades do projeto aberta, clique no botão “Adicionar

pasta...” e crie uma pasta chamada “relatórios”. Logo após, mude o rótulo da mesma

para “Configurações de relatórios”, conforme a figura 58.

Figura 58: Janela de propriedades do projeto com a nova pasta criada Fonte: Elaborado pelo autor

Criado a pasta de configurações de relatórios, tem-se que carregar as

bibliotecas do JasperReports que foi feito download anteriormente, assim como foi

feito com o BlazeDS, deve-se repetir o processo para a criação da biblioteca, clique

com o botão direito do mouse em “Bibliotecas”, opção adicionar biblioteca > criar.

Para essa biblioteca será dada o nome de JasperReports, feito isso adicione os

repositórios JAR’s que estão no arquivo jasperreports-4.0.2-project e mais o

repositório que foi baixado diretamente do site o arquivo jasperreports-4.0.2.jar,

conforme figura 59.

115

Figura 59: Janela de personalização da biblioteca Fonte: Elaborado pelo autor

Feito isso, é necessário concluir a criação da biblioteca e ela já estará

disponível para utilização, assim como foi com a biblioteca que foi criada para o

BlazeDS. Agora, com o botão direito do mouse clique na pasta “Configurações de

relatórios” selecione a opção novo > outro, na janela de novos arquivos. Nesse

momento, irá aparecer a opção Report para criação de relatórios do IReports, então

basta selecionar a opção “Report Wizard” que é o assistente de criação de relatórios

do IReports e que será utilizado para gerar o relatório para o projeto.

Figura 60: Janela de novos arquivos Fonte: Elaborado pelo autor

116

Selecionado a opção “Report Wizard”, clique no botão próximo para

selecionar o layout que deseja usar, para o projeto será utilizado o modelo “Leaf

Red”, conforme figura 61.

Figura 61: Painel seletor de layout para o relatório Fonte: Elaborado pelo autor

Feito esse passo o próximo é nomear o relatório que iremos chama-lo de

“relatórios”. Dado o nome para o relatório clique em próximo para selecionar a fonte

de dados de onde serão tiradas as informações para o relatório, conforme a figura

62.

Figura 62: Janela para seleção da fonte de dados Fonte: Elaborado pelo autor

117

Na janela para seleção da fonte de dados, tem-se de primeiro que indicar a

fonte para o IReports para somente depois, conseguir prosseguir com a criação.

Para isso clique no botão “New” para criar uma conexão com o banco de dados.

Após clicar no botão, irá aparecer uma tela com várias opções de fontes de dados,

mas para o projeto será utilizada a do tipo JDBC mesmo.

Figura 63: Janela para seleção do tipo de fonte de dados Fonte: Elaborado pelo autor

Selecionado a opção, clique em “next”. Feito isso, irá aparecer a tela de

configuração da conexão com o banco de dados. Nesta, tem-se de informar um

nome para a conexão que, nesse caso, será chamado de “SisDEMO”, selecionar o

driver do banco de dados, mostrar a url para conexão com o banco, informar o

endereço do servidor de banco de dados, informar o nome do banco, informar o

nome de usuário e senha do banco, conforme figura 64.

118

Figura 64: Janela para configuração da conexão com o banco de dados Fonte: Elaborado pelo autor

Perceba que logo que finalizado o processo de configuração do banco de

dados, volta-se para a tela iniciar e, então, a conexão recém criada ira aparecer

como opção a ser utilizada.

Figura 65: Janela para seleção da fonte de dados Fonte: Elaborado pelo autor

Query SQL é digitada aqui!

119

Agora com a fonte de dados selecionada, pode-se montar a query de consulta

de duas formas, a primeira é a de forma manual digitando a Query SQL diretamente

no espaço que tem destinado para isso; a outra forma é pelo Design Query que é

um assistente do IReports feito para auxiliar na criação da query de forma dinâmica,

para o projeto utilizaremos o Design Query. Clique no botão para abrir a janela e

nela selecione a tabela que desejar. Neste caso, selecione a tabela endereços e

desmarque a opção “id” que não será utilizado no relatório, conforme a figura 66.

Figura 66: Janela do query design Fonte: Elaborado pelo autor

Executado esse passo clique em OK, para voltar a janela anterior, porém

agora com a Query SQL preenchida, é só clicar em próximo e ir para a nova janela

onde deve-se selecionar todos os campos para aparecerem no relatório. Feito essa

seleção clique em próximo, pois os próximos passos não serão alterados, até

finalizar a criação do relatório, conforme a figura 67:

120

Figura 67: Perspectiva geral do IReports no NetBeans Fonte: Elaborado pelo autor

Com o IReports aberto, somente faz-se a alteração do cabeçalho do relatório

e nada mais, pois o mesmo está terminado e pode ser testado no botão Preview.

Figura 68: Perspectiva do relatório com as alterações feitas Fonte: Elaborado pelo autor

121

Feito as alterações no cabeçalho do relatório, feche o IReports e volte para o

projeto onde, serão criadas 3 (três) pacotes na pasta “Configurações de relatórios”.

Os pacotes criados serão: jdbc, útil e servlets, conforme figura 69.

Figura 69: Visão da pasta de configurações de relatórios Fonte: Elaborado pelo autor

Os pacotes foram criados para possibilitar a comunicação da aplicação com o

relatório e o porque desses três pacotes, simples no pacote jdbc é onde irá criar uma

classe que será responsável em realizar a conexão com o banco de dados. Classe

responsável e, ássar as informações ao IReports para gerar o relatório será criada

no pacote útil, e por fim, o servlet chama o relatório e a aplicação poderá chamar no

momento da geração do relatório. Abaixo segue os códigos-fontes com a descrição

de cada função deles.

Código-fonte conexaoBD.java:

package jdbc;

import java.sql.Connection;

import java.sql.DriverManager;

import java.sql.SQLException;

import java.util.logging.Level;

import java.util.logging.Logger;

/**

*

* @author Dricz

*/

public class ConexaoBD {

// Este bloco estático será executado assim que esta classe for

carregada,

// sendo assim, será executado apenas uma vez.

static {

try {

//Carrega a classe com driver do PostgreSQL

Class.forName("org.postgresql.Driver");

122

} catch (ClassNotFoundException ex) {

Logger.getLogger(ConexaoBD.class.getName()).log(Level.SEVERE,

null, ex);

}

}

//Método responsável em retorna uma conexão com o banco de dados

baseado nos parâmetros fornecidos.

public static Connection getConnection(String url, String usuario,

String senha) throws SQLException{

return DriverManager.getConnection(url, usuario, senha);

}

//Método que obtem a conexão com o banco de dados

public static Connection getDemoConnection () throws SQLException {

return

getConnection("jdbc:postgresql://localhost:5432/ManualIntegracao",

"postgres", "ju230484");

}

}

Código-fonte ReportUtils.java

package util;

import java.io.IOException;

import java.io.InputStream;

import java.io.OutputStream;

import java.sql.Connection;

import java.util.Map;

import javax.servlet.http.HttpServletResponse;

import net.sf.jasperreports.engine.JRException;

import net.sf.jasperreports.engine.JRExporter;

import net.sf.jasperreports.engine.JRExporterParameter;

import net.sf.jasperreports.engine.JasperFillManager;

import net.sf.jasperreports.engine.JasperPrint;

import net.sf.jasperreports.engine.export.JRPdfExporter;

/**

*

* @author Dricz

*/

public class ReportUtils {

//Método responsável em gerar o relatório baseado HttpServletResponse

public static OutputStream createPDFReport(

InputStream inputStram,

Map<String, Object> parametros,

Connection conexao,

HttpServletResponse response) throws JRException, IOException {

//Configura o content type do response, ou seja, o tipo de saída do

relatório

response.setContentType("application/pdf");

//Obtém o OutoutStream para gerar o relatório

OutputStream out = response.getOutputStream();

123

//Cria a versão preenchida do relatório usando uma conexão

JasperPrint jasperPrint = JasperFillManager.fillReport(inputStram,

parametros, conexao);

//Método responsável em exporta o relatório em PDF

JRExporter exporter = new JRPdfExporter();

exporter.setParameter(JRExporterParameter.JASPER_PRINT,

jasperPrint);

exporter.setParameter(JRExporterParameter.OUTPUT_STREAM, out);

//Gerador do relatório

exporter.exportReport();

//Efetua o retorno do OutputStream

return out;

}

}

Código-fonte ServletReport.java:

package servlets;

import java.io.IOException;

import java.io.InputStream;

import java.io.OutputStream;

import java.sql.SQLException;

import java.util.HashMap;

import java.util.Map;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import jdbc.ConexaoBD;

import net.sf.jasperreports.engine.JRException;

import util.ReportUtils;

/**

*

*

* @author Dricz

*/

public class ServletReport extends HttpServlet {

@SuppressWarnings("CallToThreadDumpStack")

protected void processRequest(HttpServletRequest request,

HttpServletResponse response)

throws ServletException, IOException {

OutputStream out = null;

// obtém o relatório compilado

InputStream inputStream = getClass().getResourceAsStream(

"/enderecos.jasper" );

124

// preenche o mapa de parâmetros

Map<String, Object> parametros = new HashMap<String, Object>();

try {

// gera o relatório e atribui o OutputStream gerado

out = ReportUtils.createPDFReport( inputStream, parametros,

ConexaoBD.getDemoConnection(), response );

} catch ( SQLException exc ) {

exc.printStackTrace();

} catch ( JRException exc ) {

exc.printStackTrace();

} finally {

// se não aconteceu nenhum problema, fecha o output stream

if ( out != null ) {

out.close();

}

}

}

// <editor-fold defaultstate="collapsed" desc="HttpServlet methods.

Click on the + sign on the left to edit the code.">

/**

* Handles the HTTP <code>GET</code> method.

* @param request servlet request

* @param response servlet response

* @throws ServletException if a servlet-specific error occurs

* @throws IOException if an I/O error occurs

*/

@Override

protected void doGet(HttpServletRequest request, HttpServletResponse

response)


processRequest(request, response);

}

/**

* Handles the HTTP <code>POST</code> method.

* @param request servlet request

* @param response servlet response

* @throws ServletException if a servlet-specific error occurs

* @throws IOException if an I/O error occurs

*/

@Override

protected void doPost(HttpServletRequest request, HttpServletResponse

response)


processRequest(request, response);

}

/**

* Returns a short description of the servlet.

* @return a String containing servlet description

*/

@Override

public String getServletInfo() {

return "Short description";

125

}// </editor-fold>

}

Implementado as classes necessárias, agora somente falta criar um link do

Front-End do projeto com o relatório. Então vá ao projeto no Flex e implemente o

método para chamar o relatório, conforme a figura 70 e 71.

Figura 70: Trecho do código onde consta o método Fonte: Elaborado pelo autor

Figura 71: Trecho do código onde dá a função de gerar relatório ao botão Fonte: Elaborado pelo autor

Feito essas alterações, o projeto está finalizado e pode-se utilizá-lo com o

CRUD completo e com a geração de relatório.

CENTRO ESTADUAL DE ENSINO TECNOLÓGICO “PAULA...

Documents

Transcript of CENTRO ESTADUAL DE ENSINO TECNOLÓGICO “PAULA...