tccfinal cee

ALICE DOMINGUES FERREIRA

VICTOR ANTÔNIO DE ALMEIDA

VITOR SIMÃO FERREIRA

CARTÃO ESPELHO ELETRÔNICO

UNIVERSIDADE DO VALE DO SAPUCAÍ

POUSO ALEGRE

2010





Trabalho de Conclusão de Curso apresentado ao

Departamento de Sistema de Informação da Faculdade

de Filosofia, Ciências e Letras “Eugênio Pacelli” da

Universidade do Vale do Sapucaí, como requisito para

obtenção do título de Bacharel em Sistemas de

Informação.

Orientador : Professor Ednardo David Segura

UNIVERSIDADE DO VALE DO SAPUCAÍ

POUSO ALEGRE

2010





Monografia defendida e aprovada em ___/___/_____ pela banca examinadora

constituída pelos professores:

_________________________________

Professor EDNARDO DAVID SEGURA

Orientador

_________________________________

Professora CRISHNA IRION

Examinadora

_________________________________

Professor PAULO CÉSAR DO NASCIMENTO

Examinador

Aos nossos pais, aos nossos

amigos e a todos que nos

ajudaram nessa caminhada.

AGRADECIMENTOS

Agradecemos primeiramente a Deus, por nos dar forças para seguir em frente em todos os

momentos difíceis;

Ao nosso professor orientador Ednardo, pelo empenho e dedicação desde o começo do projeto

e pelos conselhos valiosos;

A professora Joelma Pereira de Faria e ao professor José Luiz da Silva, por todo o apoio;

A Gerência Regional de Saúde de Pouso Alegre pela disponibilização de informações vitais

para o desenvolvimento deste projeto.

De Alice:

Agradeço aos meus pais, Antônio e Terezinha, por todo amor, carinho e dedicação

incondicionais, e por acreditarem na minha capacidade;

Aos meus colegas de sala que com o passar dos anos se tornaram verdadeiros amigos e que

levarei por toda minha vida.

De Victor:

Agradeço primeiramente a Deus, pelo dom da vida.

Agradeço aos meus pais que sempre me apoiaram em todas minhas decisões.

Aos amigos e colegas de grupo, Alice Ferreira e Vitor Simão.

Ao Bruno Leite que muito ajudou no desenvolvimento deste trabalho.

De Vitor:

Agradeço aos meus pais e familiares, que foram e é inspiração de todo meu trabalho.

Aos meus colegas e amigos deste projeto, Alice Ferreira e Victor Antônio pela união e

dedicação.

Em especial, ao meu tio, João Luiz, que sempre esteve presente e me estendeu a mão nos

momentos mais difíceis.

"Para realizar grandes conquistas, devemos não apenas agir, mas

também sonhar; não apenas planejar, mas também acreditar."

( Anatole France )

FERREIRA, Alice Domingues; ALMEIDA, Victor Antônio; FERREIRA, Vitor Simão.

Cartão Espelho Eletrônico: 2010. Monografia – Curso de Sistemas de Informação da

Faculdade de Filosofia Ciência e Letras “Eugênio Pacelli”, Universidade do Vale do Sapucaí,

Pouso Alegre, 2010.

RESUMO

Este trabalho de conclusão de curso visa o desenvolvimento de um sistema web para controle

de vacinas aplicadas nos usuários do Sistema Único de Saúde (SUS). A proposta é substituir o

controle de vacinação feito através de cartões de papel. Para a conclusão desse sistema,

utilizamos a linguagem Java para web, juntamente com outras tecnologias web, como o

HTML e CSS e com o auxílio do framework JBoss Seam. Fizemos o uso do banco de dados

PostgreSQL para armazenamento dos dados. Utilizamos a metodologia de desenvolvimento

ICONIX, com os devidos diagramas UML. O tipo de pesquisa é aplicada e foi efetuada na

Gerência Regional de Saúde de Pouso Alegre. Como resultado desse trabalho, foi concluído

um sistema onde serão armazenados dados vacinais de cada usuário do SUS. Esses dados

poderão ser visualizados pelo funcionário da Sala de Vacina no ato da imunização,

verificando a real necessidade de tomar essa vacina e evitando doses repetidas. Tais dados

também poderão ser visualizados pelo próprio usuário, pela internet, para que ele mesmo

verifique se está em dia com sua vacinação e emitir comprovantes. Esse trabalho é de grande

relevância social, pois o recebimento de doses repetidas no organismo pode levar até a morte.

Com isso, os objetivos propostos no trabalho foram concluídos.

Palavras-chave: Imunização. Cartão de vacina. JBoss Seam. ICONIX.

FERREIRA, Alice Domingues; ALMEIDA, Victor Antônio; FERREIRA, Vitor Simão.

Electronic Mirror Card: 2010. Monografia – Curso de Sistemas de Informação da

Faculdade de Filosofia Ciência e Letras “Eugênio Pacelli”, Universidade do Vale do Sapucaí,

Pouso Alegre, 2010.

ABSTRACT

This conclusion research paper aimed at developing a web system for control of vaccines

administered in the Sistema Único de Saúde (SUS) – Brazilian Public Health Care. The

proposal is to replace the control of vaccination done through paper cards. For the conclusion

of this system, we use the Java language for the Web, along with other web technologies like

HTML and CSS and with the help of JBoss Seam. We use the PostgreSQL database for data

storage. We use the ICONIX development methodology, with appropriate UML diagrams.

The type of research is applied and has been made in the Regional Health Management of

Pouso Alegre. As a result of this work, we developed a system where the vaccine data of each

user of SUS will be stored. This data can be viewed by the employee of the vaccine room at

the time of immunization, verifying the real need to take this vaccine and avoiding repeated

doses. Such data will also be viewable by the user via Internet, to make sure that he is current

with his vaccinations and issue vouchers. This work has a great social relevance, since

receiving repeated doses in the body can lead to death. Thus, the objectives proposed in this

research were completed.

Keywords: Immunization. Vaccination card. JBoss Seam, Iconix;

LISTA DE FIGURAS

Figura 01 - Exemplo de cartão de vacina. ................................................................................ 15

Figura 02 - Arquivo de cartões espelho .................................................................................... 16

Figura 03 - Atividades relacionadas à análise de requisitos. .................................................... 21

Figura 04 - Atividades relacionadas à análise e projeto preliminar. ........................................ 22

Figura 05 - Atividades relacionadas ao projeto. ....................................................................... 23

Figura 06 - Integração do JBoss Seam em uma arquitetura Java EE. ...................................... 24

Figura 07 - Arquitetura do JSF baseada no modelo MVC. ...................................................... 25

Figura 08 - Prototipação da tela "Lista de Clientes". ............................................................... 30

Figura 9 - Prototipação da tela "Cadastrar Cliente" ................................................................. 31

Figura 10 - Prototipação da tela "Cliente" ................................................................................ 32

Figura 11 - Prototipação da tela "Inserir Aplicação" ................................................................ 33

Figura 12 - Prototipação da tela "Cartão do Cliente" ............................................................... 34

Figura 13 - Modelo de domínio ................................................................................................ 35

Figura 14 - Identificação dos casos de uso ............................................................................... 36

Figura 15 - Estereótipos utilizados ........................................................................................... 41

Figura 16 - Análise de Robustez - Cadastrar Cliente ............................................................... 42

Figura 17 - Análise de Robustez - Cadastrar Usuário .............................................................. 42

Figura 18 - Análise de Robustez - Cadastrar Vacina................................................................ 43

Figura 19 - Atualização do Modelo de Domínio ...................................................................... 44

Figura 20 - Diagrama de Sequência - Cadastrar Vacina .......................................................... 46

Figura 21 - Diagrama de Sequência - Cadastrar Usuário ......................................................... 47

Figura 22 - Diagrama de Sequência - Cadastrar UBS .............................................................. 48

Figura 23 - Diagrama de Classes 1 - Entidades ........................................................................ 50

Figura 24 - Diagrama de classes 2 - EntityHome ..................................................................... 51

Figura 25 - Diagrama de classes 3 - Classes do Seam.............................................................. 52

Figura 26 - Tela de configuração do ambiente Eclipse. ........................................................... 54

Figura 27 - Geração do Seam Web Project .............................................................................. 55

Figura 28 - Codigo do hibernate.reveng.xml. ........................................................................... 56

Figura 29 - Tela do Login ........................................................................................................ 63

Figura 30 - Tela de Boas Vindas, depois de logado. ................................................................ 63

Figura 31 - Tela de Cadastro e Edição de Usuário do SUS ...................................................... 64

Figura 32 - Tela de Informações de Usuário Cadastrado ......................................................... 64

Figura 33 - Busca e Listagem de Clientes ................................................................................ 65

Figura 34 - Tela de Criação do Cartão ..................................................................................... 65

Figura 35 - Tela de Exibição dos Dados do Cartão .................................................................. 66

Figura 36 - Busca e Listagem de Cartões ................................................................................. 66

Figura 37 - Tela de Aplicação de Vacinas ................................................................................ 67

Figura 38 - Tela de Exibição das Vacinas Aplicadas ............................................................... 67

Figura 39 - Tela de Cadastro de Vacinas .................................................................................. 68

LISTA DE TABELAS

Tabela 1 - Fluxo de Evento "cadastrar vacina" ........................................................................ 38

Tabela 2 - Fluxo de Evento "cadastrar cliente" ........................................................................ 39

Tabela 3 - Fluxo de Evento "cadastrar cartão" ......................................................................... 39

Tabela 4 - Fluxo de Evento "cadastrar aplicação" .................................................................... 40

Tabela 5 - Fluxo de Evento "cadastrar laboratório" ................................................................. 40

LISTA ABREVIATURAS E SIGLAS

AJAX Asynchronous JavaScript and XML

API Application Programming Interface

CEE Cartão Espelho Eletrônico

EE Enterprise Edition

EJB Entrerprise Java Beans

GRS Gerência Regional de Saúde

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

IBM International Business Machines

JSP JavaServer Pages

JSF JavaServer Faces

SQL Structured Query Language

SUS Sistema Único de Saúde

UBS Unidade Básica de Saúde

UML Unified Modeling Language

XML Extensible Markup Language

XP Extreme Programming

SUMÁRIO

INTRODUÇÃO ........................................................................................................................ 14

2 FUNDAMENTAÇÃO TEÓRICA ................................................................................... 19

2.1 Engenharia de Software........................................................................................... 19

2.2 ICONIX....................................................................................................................20

2.2.1 Análise de requisitos ...................................................................................... 20

2.2.2 Análise e Projeto Preliminar ........................................................................... 21

2.2.3 Projeto ............................................................................................................. 22

2.3 Java ......................................................................................................................... 23

2.3.1 JBossSeam ..................................................................................................... 24

2.3.2 Java Server Faces(JSF) .................................................................................. 25

2.3.3 RichFaces ...................................................................................................... 25

2.4 Web Standarts...........................................................................................................26

2.5 Banco de Dados PostGreSQL..................................................................................27

2.6 Justificativa das escolhas de metodologias e tecnologia .......................................... 28

3 METODOLOGIA DE DESENVOLVIMENTO .............................................................. 29

3.1 Análise de Requisitos...............................................................................................29

3.1.1 Prototipação ................................................................................................... 29

3.1.2 Modelo de Domínio.......................................................................................34

3.1.3 Identificação dos casos de Uso ...................................................................... 36

3.2 Análise e Projeto Preliminar ..................................................................................... 37

3.2.1 Descrição dos casos de Uso .......................................................................... 37

3.2.2 Análise de Robustez ..................................................................................... 41

3.2.3 Atualização do modelo de domínio .............................................................. 43

3.3 Projeto ..................................................................................................................... 44

3.3.1 Diagramas de Seqüência ................................................................................ 45

3.3.2 Conclusão do modelo estático ....................................................................... 49

3.4 Codificação ............................................................................................................... 53

4 DISCUSSÃO DOS RESULTADOS ................................................................................ 57

CONCLUSÃO .......................................................................................................................... 58

REFERÊNCIAS ....................................................................................................................... 59

1 INTRODUÇÃO

O objetivo geral deste trabalho é desenvolver um software – Cartão Espelho

Eletrônico – para automatização do atual sistema de vacinação que atualmente é feito através

de cartões de papel.

Para o alcance do objetivo geral do trabalho foi necessário: levantar informações do

atual sistema de vacinação junto à Gerência Regional de Saúde de Pouso Alegre, utilizar

metodologias de desenvolvimento juntamente com algumas tecnologias que serão descritas no

capítulo de Fundamentação Teórica e criar um banco de dados com as informações

necessárias à administração dos postos de saúde do SUS1 – Sistema Único de Saúde – e

também aos seus usuários.

O Cartão Espelho Eletrônico, que neste trabalho será denominado CEE2, trata-se de

uma aplicação web desenvolvida para automatizar o atual sistema de vacinação realizado no

Sistema Único de Saúde - SUS.

A atual situação do sistema de vacinação, na qual falta, por parte do SUS, um

controle efetivo das aplicações de doses por cliente e por parte das UBS‟s o controle das

vacinas aplicadas são problemas existentes que levaram ao desenvolvimento do CEE.

Atualmente muitos cidadãos, denominados neste trabalho, usuários do SUS, perdem

seus cartões de vacinação e, com isso, não têm o controle das doses recebidas nem a data em

que foram aplicadas, o que gera, muitas vezes, o recebimento de doses repetidas sem a real

necessidade ou, ainda, ficam desprevenidos por não saberem se a vacina ainda está no período

de validade no organismo.

1 A partir deste ponto chamaremos o Sistema Único de Saúde somente como SUS.

2 A partir deste ponto chamaremos o Cartão Espelho Eletrônico somente como CEE.

15

Figura 01 - Exemplo de cartão de vacina. Fonte: Elaborado pelos autores.

O desenvolvimento do CEE vem ao encontro da necessidade do SUS em ter um

controle efetivo das aplicações das vacinas nos usuários. Ao ter as informações armazenadas

em um sistema automatizado, o SUS terá condições de controlar as aplicações de doses, bem

como monitorar as vacinas já aplicadas nos usuários, evitando assim a aplicação de doses

repetidas e ainda podendo atualizar vacinas já com a validade expirada no organismo.

O registro das informações vacinais de cada usuário do Sistema Único de Saúde

(SUS) é a tarefa diária daqueles que trabalham na área assistencial de saúde. O chamado

cartão espelho, ou seja, ficha que contém informações sobre aplicações de vacinas por clientes

é o agrupamento das anotações dessas informações. O cartão espelho é denominado assim,

por ser uma cópia armazenada junto às Unidades Básicas de Saúde - UBS3, do cartão de

vacinação (cartão que fica em posse do usuário, contendo das informações de vacinas

recebidas). O cartão espelho é um formulário em papel que fica armazenado na UBS a qual

um usuário a visita pela primeira vez.

3 A partir deste ponto chamaremos as Unidades Básicas de Saúde somente como UBS.

16

Fig. 02 - Arquivo de cartões espelho. Fonte: GRS Pouso Alegre.

Diversos são os problemas, encontrados hoje em dia, para se manter os cartões

espelhos atualizados, ou ainda, com as informações idênticas aos cartões de vacinação.

Primeiramente, pelo fato do cartão espelho ser um formulário de papel e ficar armazenado na

Unidade Básica de Saúde, a qual o usuário visitou a primeira vez. Se este, mudar de endereço,

município ou ainda procurar outra UBS, ele não terá nesta nova Unidade, informações

relativas a seu histórico de vacinação. Outro problema a ser apontado, é a perda do cartão de

vacinação por parte dos usuários. Eles acabam não tendo o controle das doses recebidas nem a

data que foram aplicadas, o que gera muitas vezes, o recebimento de doses repetidas sem a

real necessidade ou, ainda, ficam desprevenidos por não saberem se a vacina ainda está no

período de validade no organismo.

Um problema apontado pela referência técnica de imunização da Gerência Regional

de Saúde - GRS de Pouso Alegre, é que, algumas UBS‟s dos municípios pela qual é

responsável, alegam que quando há campanhas vacinação feitas pelo Ministério da Saúde,

fica praticamente impossível atualizar todos os cartões espelhos, uma vez que a demanda

nestas Unidades é muito alta, tendo atualizações feitas somente nos cartões de vacinação dos

usuários. Com isso, as informações vacinais de cada usuário não são efetivamente

controladas, o que acarreta problemas como doses repetidas no organismo ou o não

recebimento de algumas vacinas.

17

Outro problema grave pode ser considerado como o informado pela FOLHA

ONLINE, em 2008, quando o Brasil teve até o dia 18 de Janeiro daquele ano, 31 casos de

superdosagem de vacina contra febre amarela. Essas pessoas tomaram uma nova dose de

vacina antes que a anterior expirasse no organismo. Segundo o Ministério da Saúde, a

validade da vacina de febre amarela no organismo é de 10 anos, sem a necessidade de reforço.

A superdosagem trás diversas reações como: febre, dores de cabeça, vômito, enrijecimento

dos músculos, problemas neurológicos e ainda a própria contração da doença que pode levar à

morte.

Alguns trabalhos semelhantes já foram desenvolvidos. Costa (2001) desenvolveu um

sistema de armazenamento de informações sobre pacientes que assemelha-se ao nosso

trabalho no que diz respeito às tecnologias e pelo fato de também ser voltado para área da

saúde.

Ainda nesta direção, tivemos contato com o trabalho de Souza (2002), que relata o

quão seria mais fácil se a sala de vacinação fosse informatizada. Ela propõe o uso da

tecnologia a fim de garantir eficácia no atendimento à população.

O uso do CEE torna o controle de vacinação de usuários mais efetivo, reduzindo a

repetição nas aplicações, tornando-as mais ágeis e, ainda, mantendo as informações

arquivadas em um banco de dados, onde consultas poderão ser feitas online, tanto pela UBS,

no ato da aplicação, para verificar a real necessidade do cliente tomar a vacina que ele quer,

quanto pelo usuário, para que ele mesmo verifique se está em dia com sua vacinação e possa

emitir comprovantes, se preciso em viagens ou para outros fins.

Este trabalho foi elaborado por: Alice Domingues Ferreira, estudante do curso de

Sistemas de Informação, na Universidade do Vale do Sapucaí (UNIVAS). Funcionária lotada

na Gerencia Regional de Saúde de Pouso Alegre há dois anos

Juntamente no grupo, Vitor Simão Ferreira, também aluno do curso de Sistemas de

Informação e ex-funcionário da Gerencia Regional de Saúde de Pouso Alegre. Já havia

desenvolvido um sistema de banco de dados que armazenasse as informações de vacinação.

O terceiro integrante do grupo, Victor Antônio de Almeida, técnico em

telecomunicações, formado pelo SENAI em Belo Horizonte/MG, funcionário do SEBRAE

Minas na regional Pouso Alegre, transferido à UNIVAS em agosto de 2008, percebendo a

importância e a relevância do trabalho a ser desenvolvido, decidiu se juntar ao grupo para

auxiliar no desenvolvimento do sistema.

O trabalho conta ainda com a colaboração de Irene Podverseck Reis, referência

técnica de imunização da GRS (Gerência Regional de Saúde) de Pouso Alegre e é orientado

18

por Ednardo David Segura, professor da UNIVAS, especialista em desenvolvimento de

sistemas para internet.

Nos próximos capítulos serão apresentadas a fundamentação teórica, as metodologias

e a documentação necessária para o desenvolvimento do projeto.

1919

2 FUNDAMENTAÇÃO TEÓRICA

Com o surgimento da engenharia de software, atualmente produz-se aplicações com

custos reduzidos, agilidade nos processos de produção, validação e manutenção. Segundo

Pressman(2002), o trabalho associado à engenharia de software pode ser categorizado em

fases genéricas independente da área de aplicação, tamanho do projeto e complexidade. As

fases necessariamente focam na definição(o que fazer), no desenvolvimento (como fazer) e na

manutenção (modificações).

2.1 Engenharia de Software

A engenharia de software vem se desenvolvendo rapidamente. Hoje ela oferece uma

grande variedade de frameworks4, métodos e tecnologias que auxiliam as atividades

comumente encontradas em projetos de software. Têm-se, atualmente, diversas ferramentas

novas, muito poderosas, que auxiliam na organização do processo de desenvolvimento e

oferece suporte total ao processo de desenvolvimento do software. É vista atualmente como a

aplicação dos métodos e tecnologias da engenharia para planejar, especificar, desenhar,

implementar, validar, testar, medir, manter e aprimorar os sistemas de software.

Um recurso importante da engenharia de software é o processo de seu

desenvolvimento que, consiste em atividades, métodos e práticas úteis no desenvolvimento de

um produto de software. As atividades associadas a esse processo de software incluem a

descrição e preparação de esquemas que identifiquem a estrutura de dados e elementos de

controle de um sistema, codificação, verificação e implantação de software.

Uma abordagem de engenharia à engenharia de software. Segundo Peters e Pedrycz

(2001) engenharia de software: caracteriza-se por um desenvolvimento de software prático,

ordenado e medido, com objetivo principal de produzir sistemas satisfatórios que respeitem

prazos e orçamentos.

4 Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de

um subsistema da aplicação

20

Metodologias ágeis se tornaram populares a partir de 2001, e são aplicadas nos

projetos que sofrem mudanças frequentemente. Pode-se destacar as metodologias eXtreme

Programming (XP5) e ICONIX que foi utilizada neste trabalho.

2.2 ICONIX

A metodologia ICONIX pode ser considerada uma metodologia pura, prática e

simples, mas também poderosa e com um componente de análise e representação dos

problemas sólido e eficaz, por isso, a metodologia ICONIX é caracterizada como um Processo

de Desenvolvimento de Software desenvolvido pela ICONIX Software Engineering.

Para Silva e Videira (2001) o ICONIX é um processo não tão complexo como o RUP,

ou seja, não gera tanta documentação nem tão simples quanto o XP. E apesar de ser um

processo simples, não deixa a desejar na Análise e Projeto (Design), e se destaca com um

poderoso processo de desenvolvimento de software.

Este processo também faz uso da linguagem de modelagem UML e possui uma

característica exclusiva chamada "Rastreabilidade dos Requisitos" (Traceability of

Requirements). Mais precisamente, ICONIX nos permite "obrigatoriamente", através de seus

mecanismos, verificar em todas as fases se os requisitos estão sendo atendidos. A abordagem

ICONIX é flexível e aberta, isto é, se for necessário usar outro recurso da UML para

complementar os recursos usados nas fases do ICONIX, não há problema algum.

2.2.1 Análise de Requisitos

Fase da tarefa de análise de requisitos, em que são identificados os objetos existentes

no mundo real e suas relações de associação, agregação e generalização entre os objetos. Cria-

se então, um diagrama de classe de alto-nível que é conhecido como modelo de domínio.

5 A partir deste momento chamaremos a Extreme Programming de XP

21

Fig. 03 - Atividades relacionadas à análise de requisitos. Fonte: Silva e Videira(2001).

Ocorre, nessa fase, a elaboração de um protótipo da interface, com um diagrama de

navegação, que facilita o entendimento do sistema por parte dos clientes. Apontam-se os

casos de uso envolvidos no sistema que foi proposto, exibindo os autores e suas relações. No

diagrama de pacotes associam-se os casos de uso em grupos e agrupa os requisitos funcionais

aos objetos de domínio.

2.2.2 Análise e Projeto Preliminar

Fase em que são descritos os casos de uso do fluxo principal das ações, fluxos

alternativos e fluxos de exceções. É elaborada uma análise de robustez atualizando o modelo

de domínio e diagrama de classes.

22

Fig. 04 - Atividades relacionadas à análise e projeto preliminar. Fonte: Silva e Videira(2001)

Após a atualização do modelo de domínio e do diagrama de classes ocorre a conclusão

da fase de análise e projeto preliminar.

2.2.3 Projeto

Esta é a fase de especificação do comportamento através do diagrama de sequência.

Utiliza os textos de casos de uso e sempre atualiza o diagrama de classe à medida que novos

objetos e atributos vão sendo descobertos.

23

Fig. 05 - Atividades relacionadas ao projeto. Fonte: Silva e Videira(2001)

Ocorre a finalização do modelo estático do diagrama de classe verificando o

atendimento a todos os requisitos. Após as fases descritas, começa-se o desenvolvimento do

projeto, que para alguns autores tal tarefa é considerada uma fase do ICONIX, mas segundo

ICONIXPROCESS(2007), essa etapa não faz parte do ICONIX.

2.3 Java

Criada em 1990, por uma equipe chefiada por James Gosling, na empresa Sun

Microsystems, Java, além de uma linguagem de programação é também uma plataforma. É

uma linguagem orientada a objeto e diferentemente de outras linguagens, seu código é

compilado em um bytecode6 que é interpretado e traduzido pela Java Virtual Machine

(JVM).

É uma plataforma apenas de software e pode ser executada sobre várias plataformas de

hardware. Na JVM, possui um grande conjunto de componentes de software (classes), para

facilitar o desenvolvimento de implantação dos aplicativos.

Java possui três edições de plataformas: Java SE (Java Platform, Standard Edition),

que permite desenvolver e implantar aplicativos Java em desktops e servidores e também

ambientes integrados e em tempo real. O Java EE (Java Platform Enterprise Edition) é uma

versão corporativa que ajuda a desenvolver e implantar aplicativos Java do lado do servidor

24

que são transportáveis, robustos, escaláveis e seguros. A terceira edição é o Java ME (Java

Platform, Micro Edition), voltado para desenvolvimento de aplicativos para dispositivos

móveis e integrados, como telefones, celulares entre outros.

2.3.1 JBoss Seam

O JBoss Seam é um framework utilizado para desenvolvimento de aplicações Java EE

(Enterprise Edition). Ele integra, facilmente, diversas tecnologias como Asynchronous

JavaScript e XML7 (AJAX), JavaServer Faces (JSF), Java Persistence (JPA), Java Beans

(EJB 3.0). Pode ser integrado com Spring, Hibernate, Portlets e iText e ser usado em qualquer

servidor de aplicações Java EE ou Tomcat.

O seu desenvolvimento teve como objetivo eliminar a complexidade em níveis de

arquitetura. Oferece controle sobre a implementação da lógica de negócio sem a necessidade

de se preocupar com as configurações dos arquivos XML.

A principal funcionalidade é integrar JSF e EJB3.

Fig. 06 - Integração do JBoss Seam em uma arquitetura Java EE. Fonte: jboss.com

A partir de um banco de dados modelado, o Seam através de um “gerador”: seam-gen

cria a aplicação. São necessárias algumas configurações para conexão com o banco de dados,

de onde o seam-gen busca s informações para geração da aplicação. Estas serão mostradas no

capítulo de Desenvolvimento.

6 Bytecode é o código gerado pelo compilador de Java e executado pela Máquina Virtual

7 XML ou eXtensible Markup Language que pode ser definido de linguagem padronizada de marcação genérica

e será denominado de XML

25

2.3.2 Java Server Faces (JSF)

JSF é uma tecnologia com características de um framework MVC(padrão que divide

uma aplicação em três camadas: modelo, visualização e controle) para web8 juntamente com

um modelo de interfaces gráficas baseado em eventos. Existe uma clara separação entre a

visualização e regras de negócio. A camada de modelo representa os objetos de negócio. A

visualização é a interface com o usuário, ou seja, a forma como os dados são apresentados. A

camada de controle é responsável por fazer a ligação entre a camada de modelo e a interface,

gerando uma visualização apropriada. A figura abaixo mostra a arquitetura do JSF no modelo

MVC.

Fig. 07 - Arquitetura do JSF baseada no modelo MVC. Fonte: guj.

2.3.3 RichFaces

O RichFaces é uma biblioteca que possui componentes para aplicações para web, que

utilizam o framework JSF. Os componentes possuem suporte AJAX que deixam as interfaces

da aplicação com visual padronizado.

A utilização dos componentes do RichFaces, facilita a incorporação das características

das aplicações de sistema web que utilizam o JavaServer Faces.

26

2.4 Web Standarts

O HTML - HyperText Markup Language ou Linguagem de Marcação Hiper Texto – é

uma linguagem de formatação voltada para criação de paginas Web. Inventado em 1990 por

Tim Berners Lee, HTML pode ser entendido como um código que será lido por um

navegador. É formado por um simples documento de texto com extensão .html que pode ser

criado em qualquer editor e interpretado por diversos navegadores.

Um documento HTML é constituído por tags, ou etiquetas, que são os comandos

existentes no documento. As tags informam ao navegador como o conteúdo do documento

deve ser exibido. Com elas é possível dividir o documento em cabeçalho -<head>e corpo -

<body> e também inserir outros recursos como tabelas, imagens, links, etc. As tags podem

possuir atributos, que são características especificas no documento.

Com a evolução do HTML, surgiu o XHTML, que é a junção do HTML com o

XML(eXtensible Markup Language). O XHTML é a mais nova versão do HTML

Com a expansão da web e a elaboração de páginas e sites cada vez mais complexos, o

HTML sozinho não era capaz de acompanhar essa evolução, pois não oferecia muitos

recursos. Com isso, em 1995, a Nestcape lançou o JavaScript, uma linguagem de

programação capaz de inserir efeitos e funcionalidades especiais, alem de uma interatividade

maior com o usuário.

Segundo Alvarez (2004), o JavaScript é implementado dentro de uma página HTML,

entre as tags <script> e </script>. Para trabalhar com essa linguagem, é necessário apenas um

editor de texto simples( bloco de notas, notepad) ou um programa específico para desenvolver

códigos, e um browser compatível com JavaScript.

Ainda de acordo com Alvarez(2004), apesar de Java e JavaScript terem origens

comuns, são técnicas diferentes, usadas para fins distintos. Java é muito mais complexo que

JavaScript, com ele é possível desenvolver aplicações diversas, enquanto o JavaScript é

utilizado apenas em aplicações web, dentro de um documento HTML.

De acordo com Lima(2006), o JavaScript, assim como o HTML segue normas de

padronização do ECMA-262. Isso garante que as paginas implementadas nesse padrão

funcionarão corretamente em diversos navegadores.

8 Web ou World Wide Web(WWW) é um sistema de hipertexto que funciona sobre a internet.

27

Cascading Style Sheetes (Folhas de Estilo em Cascata) ou simplesmente CSS é uma

linguagem muito utilizada para definir o layout de páginas web em documentos escritos em

linguagens de marcação, como o HTML e o XML. Trata-se de um conjunto de comandos que

define como as informações do HTML serão organizadas na página.

A CSS pode ser inserida dentro do documento HTML, utilizando o atributo Style, ou

em um documento separado. Essa é a grande vantagem das CSS, criar um documento

separado com todas as definições de estilo da pagina, pois assim várias paginas podem

compartilhar o mesmo layout; um documento central que define a aparência de uma ou mais

páginas. Basta “rotular” uma tag do HTML no CSS e alterar seus atributos.

Com a CSS, é possível definir a cor de fundo da página, as imagens de fundo, as

fontes utilizadas, o tamanho das letras, a disposição das imagens, dos textos, dos links, ou

seja, é possível criar layouts únicos e precisos para inúmeras páginas com um só documento e

de maneira mais elegante. Com esse recurso, se for preciso alterar algum componente de

estilo em muitas paginas que estiverem utilizando um único documento CSS, basta alterar

somente no documento central, não necessitando modificar o código em todas as páginas.

A união do JavaScript com a CSS é conhecida como DHTML. Usando o Javascript, é

possível modificar dinamicamente os estilos dos elementos da página em HTML.

2.5 Banco de Dados PostGreSQL

Banco de Dados (ou base de dados) é um conjunto de registros dispostos em estrutura

regular que possibilita a produção de informação.

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

relacional(SGBDOR). Desenvolvido no Departamento de Ciência da Computação da

Universidade da Califórnia em Berkeley, foi pioneiro em muitos conceitos objetos-relacionais

que agora estão se tornando disponíveis em alguns bancos de dados comerciais.

O PostGreSQL possui seu código fonte aberto e fornece suporte à linguagem SQL,

além de outras funcionalidades modernas.

28

2.6 Justificativa das escolhas de metodologias e tecnologia

Optamos por utilizar o ICONIX por ser uma metodologia ágil de desenvolvimento e

por trabalhamos com diagramas simplificados, permitindo o desenvolvimento do software em

curto espaço de tempo.

A opção do framework JBoss Seam se deu pelo desafio aprofundar os conhecimentos

na tecnologia, que é relativamente nova no mercado e também pela facilidade de

produtividade que a ferramenta oferece na implementação de sistemas para web.

A escolha pelo uso do Banco de Dados PostGreSQL se deu pelo fato de os integrantes

do grupo terem mais familiaridade com o sistema SGBD, além de ser uma ferramenta de

gerenciamento de dados bastante confiável pelo meio acadêmico.

29

3 METODOLOGIA DE DESENVOLVIMENTO

Para o desenvolvimento deste trabalho, coletamos informações junto à GRS de

Pouso Alegre, livros, artigos, portal do Ministério da Saúde e trabalhos semelhantes

relacionados ao mesmo tema.

São quatros fases para conclusão do trabalho: análise de requisitos, projeto

preliminar e análise, projeto e desenvolvimento do sistema.

Na fase análise de requisitos foi feita a prototipação do sistema, juntamente com a

identificação dos objetos e suas relações além da identificação dos casos de uso e o modelo de

domínio.

Na fase seguinte, projeto preliminar e análise, fizemos a descrição dos casos de uso,

apresentamos a análise de robustez e a atualização do modelo de domínio.

A fase do projeto que consiste em especificar o comportamento do sistema através do

diagrama de sequência e concluir o modelo estático.

A seguir serão descritas as fases para o desenvolvimento do sistema, utilizando a

metodologia Iconix.

3.1 Análise de Requisitos

É o levantamento de informações, sobre quais especificações o software deve atender.

Para isso, são desenvolvidas três tarefas fundamentais: a prototipação do sistema, o modelo de

domínio e a identificação dos casos de uso. Tais tarefas serão apresentadas a seguir.

3.1.1 Prototipação

Fase que se define como ficarão as telas da aplicação. Com a prototipação é possível

obter uma pré-visualização do que se deseja desenvolver e, segundo Bona(2002), serve

também para o cliente entender melhor o que o sistema irá fazer. Consiste em esboçar as

principais telas, e assim ter uma idéia mais real do comportamento do sistema, além de

30

facilitar as demais fases da metodologia ICONIX, como por exemplo, a Descrição dos Casos

de Uso.

Abaixo, um protótipo da tela “lista de Clientes”. Nessa tela, o usuário SalaVacina tem

as opções de visualizar os dados de cada cliente e de cadastrar um novo cliente através do

botão “novo”.

Fig. 08 - Prototipação da tela "Lista de Clientes". Fonte: Elaborado pelos autores

Se for acionado o botão “novo”, será redirecionado para a tela “Cadastrar Cliente”,

como mostra a figura 9. Nessa tela, o usuário tem que preencher os campos com os dados do

novo cliente e clicar em “salvar”.

31

Fig. 9 - Prototipação da tela "Cadastrar Cliente". Fonte: Elaborado pelos autores

Quando o usuário escolhe a opção de visualizar os dados do cliente, será direcionado

para a tela “Cliente”, como mostra a figura 11. Nessa tela, o usuário tem a possibilidade de

visualizar os dados pessoais do cliente selecionado e as vacinas que ele já recebeu. É possível

também editar os dados do usuário através do botão “editar”, e de cadastrar uma nova

aplicação, através do botão “nova aplicação”.

32

Fig. 10 - Prototipação da tela "Cliente". Fonte: Elaborado pelos autores

Se o usuário clicar no botão “nova aplicação”, abrirá a tela “Inserir aplicação”, como

mostra a figura 12. Nessa tela, o usuário cadastra a nova dose que o cliente está tomando.

33

Fig. 11 - Prototipação da tela "Inserir Aplicação". Fonte: Elaborado pelos autores

O cliente também poderá fazer suas próprias consultas online. Quando ele acessar

seu cartão através de seu login e senha, será direcionado para uma página com todas suas

informações vacinais. O protótipo dessa página pode ser visualizado na figura 13.

34

Fig. 12 - Prototipação da tela "Cartão do Cliente". Fonte: Elaborado pelos autores

Os itens foram projetados de maneira estratégica, pois no menu Sala Vacina por

exemplo, para efetuar uma aplicação de vacina no Cliente, é obrigado a passar pela tela onde

estão cadastradas as doses que o usuário já tomou, assim reduzindo o risco de o profissional

da Sala de Vacina aplicar uma dose indevida no cliente.

3.1.2 Modelo de Domínio

De acordo com Silva(2007), criar o Modelo de Domínio consiste em achar classes,

substantivos, frases de substantivos, verbos e frases de verbos, que se tornarão objetos,

atributos e associações em um diagrama de domínio. É descobrir objetos de um problema do

mudo real e transformar em um diagrama. Bona (2002) destaca que substantivos e frases com

35

substantivos são entendidos como objetos e atributos e verbos e frases com verbos se tornam

operações.

Para realizar o Modelo de Domínio, é preciso primeiramente identificar as classes,

excluindo todos os itens que não serão utilizados. A partir daí deve-se construir os

relacionamentos de generalização e as associações. O resultado é mostrado a seguir.

Fig. 13 - Modelo de domínio. Fonte: Elaborado pelos autores

Para Bona(2002), essa fase é um primeiro levantamento de entidades, que tem de ser o

mais simples possível e sem muitos detalhes. O objetivo principal do Modelo de Domínio é

levantar as entidades que farão parte do sistema, sem muitos detalhes. O detalhamento de

cada entidade será feito posteriormente na Atualização do modelo de domínio e na conclusão

do modelo estático.

36

3.1.3 Identificação dos casos de Uso

Um caso de uso mostra a interação da aplicação com o universo exterior, descreve

quais requisitos a aplicação deverá atender a partir de um ator. Um ator é uma pessoa ou um

papel desempenhado, que vá interagir com o sistema.

A figura a seguir mostra a identificação dos casos de uso do CEE.

Fig. 14 - Identificação dos casos de uso. Fonte: Elaborado pelos autores

A partir da analise de requisitos já é possível ter uma visão geral do que será preciso

para desenvolver a aplicação.

Com essa análise, podemos identificar os seguintes requisitos:

O problema da falta de controle dos dados vacinais de cada usuário do SUS só seria

resolvido se fosse criado um sistema web, pois só assim o cartão poderia ser

atualizado em qualquer UBS procurada pelo usuário. Se o sistema fosse Desktop,

não resolveria totalmente o problema existente.

Os atores definidos na análise de requisitos são: AdmGeral, que teria permissão total

no sistema, mas seu papel principal seria cadastras os demais usuários e seria alguém

37

da GRS; AdmUbs, que seria cadastrado pelo AdmGeral e teria papel principal de

cadastrar usuários do tipo SalaVacina e que poderia ser o responsável pela UBS; e

SalaVacina, que seria o funcionário da Sala de Vacina, o que lida diretamente com

os usuários do SUS.

Os dados do cliente que não podem faltar em seu cadastro, como nome, CPF, RG,

endereço, etc.

O dado principal do cliente, ou seja, sua chave seria o CPF, por ser único.

Quando o cliente em questão for criança e não possuir CPF, será vinculado ao CPF

de um responsável.

Após a Análise de Requisitos, será apresentado a segunda fase do ICONIX: a

Análise e Projeto Preliminar.

3.2 Análise e Projeto Preliminar

Concluída a análise dos requisitos do sistema, iniciamos a fase de Análise e Projeto

Preliminar, onde fizemos a Descrição dos casos de uso(ou Fluxo de Eventos), a Análise de

Robustez e a Atualização do Modelo de Domínio.

3.2.1 Descrição dos casos de Uso

Descreve com detalhes as ações do usuário e as respostas do sistema. Segundo

ICONIX Process, os casos de uso ajudam a identificar o que os usuários do sistema estão

fazendo e qual é a resposta que obteve. A idéia é facilitar da melhor maneira possível, para

que o usuário com conhecimentos em informática, avançados ou não, possa concretizar suas

necessidades com sucesso, com a menor dificuldade possível.

A padronização dos nomes utilizados e a clareza nos textos são questões importantes

para a construção da descrição dos casos de uso, para melhor compreensão dos fluxos.

Também é importante descrever, além das ações do usuário, as respostas do sistema para

essas ações, pois o que está sendo descrito é o comportamento do sistema.

38

Nas tabelas abaixo, temos parte dos casos de uso do sistema descritos.

Tabela 1 - Fluxo de Evento "cadastrar vacina"

Nome do caso de uso Cadastrar Vacina

Ator Principal Administrador

Pre-codições Estar logado como Administrador

Fluxo Principal

Ações do Ator Resposta do Sistema

1-Clica no menu cadastro 2-Abre a aba de cadastros

3-Clica em cadastro de vacinas 4-Abre a tela de cadastro de vacina

5-Preenche os campos e clica em „Salvar‟ 6-Verifica se os campos foram preenchidos

corretamente.

7-Envia mensagem informando para

preencher os campos corretamente, se for o

caso

8-Verifica se a vacina existe no banco de

dados.

9-Impede o cadastro e envia uma mensagem

de „erro‟, caso a vacina já exista no banco de

dados

10-Salva as informações da nova vacina

11-Envia uma mensagem de sucesso

12-Clica em OK 13-Permanece com o formulário de cadastro

aberto, em branco, optando ao usuário a novos

cadastros.

Fonte: Elaborado pelos autores

39

Tabela 2 - Fluxo de Evento "cadastrar cliente"

Nome do caso de uso Cadastrar Cliente

Ator Principal Administrador ou AdminUBS

Pré-condições Estar logado como Administrador ou

AdminUBS

Fluxo Principal



3-Clica em cadastro de Paciente 4-Abre a tela de Cadastro de Cliente


corretamente.



caso

8-Verifica se o Cliente já existe no banco de

dados.


de „erro‟, caso o Cliente já exista no banco de

dados.

10-Salva as informações do novo Cliente.

11-Envia uma mensagem de sucesso.



cadastros.


Tabela 3 - Fluxo de Evento "cadastrar cartão"

Nome do caso de uso Cadastrar Cartão


Pre-codições Estar logado como Administrador ou

AdminUBS

Fluxo Principal



3-Clica em cadastro de Cartão 4-Abre a tela de Cadastro de Cartão


corretamente.



caso

8-Verifica se o Cartão já existe no banco de

dados.


de „erro‟, caso o Cartão já exista no banco de

dados.

10-Salva as informações do novo Cartão.




cadastros.


40

Tabela 4 - Fluxo de Evento "cadastrar aplicação"

Nome do caso de uso Cadastrar Aplicação


Pre-codições Estar logado como Administrador ou

AdminUBS

Fluxo Principal


1-Clica no menu de vacinação 2-Abre a tela de registro de aplicação


corretamente.



caso

6-Verifica se a aplicação não está sendo

duplicada.

7-Impede o registro e envia uma mensagem

de „erro‟, caso o mesmo já exista no banco de

dados.

8-Salva as informações da nova aplicação.


10-Clica em OK 11-Permanece com o formulário de aplicações

aberto, em branco, optando ao usuário a novas

aplicações.


Tabela 5 - Fluxo de Evento "cadastrar laboratório"

Nome do caso de uso Cadastrar Laboratório

Ator Principal Administrador

Pré-codições Estar logado como Administrador ou

Fluxo Principal



3-Clica em cadastro de Laboratório 4-Abre a tela de Cadastro de Laboratório


corretamente.



caso

8-Verifica se o Laboratório já existe no banco

de dados.


de „erro‟, caso o Laboratório já exista no

banco de dados.

10-Salva as informações do novo Laboratório.




cadastros.


41

As informações levantadas na descrição dos casos de uso serão utilizadas na próxima

tarefa do ICONIX, a Análise de Robustez.

3.2.2 Análise de Robustez

A análise de robustez é construída baseada na descrição dos casos de uso. É a

interação entre os objetos. Para Bona(2002), é analisar a descrição de cada caso de uso e

identificar um primeiro conjunto de possíveis objetos que participarão desse caso de uso.

Esses objetos são classificados em estereótipos:

Objetos de limite (boundary objects): os atores usam para se comunicar com o sistema

No caso, representa as telas do sistema que fazem a interação com o usuário.

Objetos de entidade (entity objects): Objetos do modelo de Domínio. São as entidades

do Banco de Dados do Sistema.

Objetos de controle (control objects): fazem a ligação entre os objetos de limite e os

objetos de entidade. São os métodos de objetos de entidade ou de objetos de limite.

A figura abaixo mostra os símbolos utilizados na analise de robustez para identificar cada

estereótipo.

Fig. 15 - Estereótipos utilizados. Fonte: Bona(2002)

Para criação do diagrama de robustez, é preciso prestar atenção em alguns detalhes

muito importantes. Os atores podem se comunicar somente com objetos de limite, pois esse

tipo de estereotipo é a interface do sistema com o usuário. Um objeto de limite não conversa

42

diretamente com objetos de entidade, tendo que fazer sua ligação através de um objeto de

controle.

Para concluirmos a análise de robustez foi necessário revisar as etapas anteriores do

ICONIX.

Figura 16 - Análise de Robustez - Cadastrar Cliente . Fonte: Elaborado pelos autores

Fig. 17 - Análise de Robustez - Cadastrar Usuário. Fonte: Elaborado pelos autores

43

Fig. 18 - Análise de Robustez - Cadastrar Vacina. Fonte: Elaborado pelos autores

3.2.3 Atualização do modelo de domínio

Passada a fase de análise de robustez e as fases anteriores do ICONIX, temos que

atualizar o modelo de domínio feito na analise de requisitos. Nessa fase já foram descobertos

novos objetos com atributos, novas classes e novas associações.

A figura abaixo mostra o Modelo de Domínio atualizado, com os atributos de cada

objeto.

44

Fig. 19 - Atualização do Modelo de Domínio. Fonte: Elaborado pelos autores

Feita a Análise e Projeto Preliminar, pudemos obter características fundamentais do

sistema, para que possamos desenvolver a fase de projeto, que será apresentado no próximo

capítulo.

3.3 Projeto

Na fase de Projeto, segundo Silva e Videira (2001), especificamos o comportamento

para cada caso de uso, com a construção dos diagramas de seqüência e finalizamos o modelo

estático, adicionando informações mais detalhadas. Tais tarefas serão descritas a seguir.

45

3.3.1 Diagramas de Seqüência

Nos diagramas de seqüência é feita a previsão de como o sistema irá funcionar. Para

isso, utilizamos os objetos e classes identificados na Análise de Robustez. Para Silva e

Videira(2001), os diagramas de seqüência mostram a colaboração entre os objetos do sistema

e a seqüência de mensagens enviadas entre estes objetos. Segundo Bona(2002), a cada objeto

de controle atribui-se um comportamento, que define esses objetos como objetos de limite ou

de entidade, e auxilia na finalização da distribuição das operações nas classes, o que acaba

auxiliando também na conclusão do modelo estático.

46

Fig. 20 - Diagrama de Sequência - Cadastrar Vacina. Fonte: Elaborado pelos autores

47

Fig. 21 - Diagrama de Sequência - Cadastrar Usuário. Fonte: Elaborado pelos autores

48

Fig. 22 - Diagrama de Sequência - Cadastrar UBS. Fonte: Elaborado pelos autores

49

3.3.2 Conclusão do modelo estático

Nessa etapa do ICONIX, o Modelo de Domínio criado na Análise de Requisitos e

atualizado com atributos na Analise e Projeto Preliminar ganhará métodos, novos atributos e

novas classes, que formarão diagramas de classes completos. Essa é a Conclusão do Modelo

Estático.

As figuras a seguir, representam essa tarefa do ICONIX concluída. O diagrama foi

dividido em três partes para melhor visualização. a primeira figura apresenta o diagrama de

classe que representa as entidades do sistema. A segunda representa as classes que estende de

EntityHome. A terceira, as classes que estendem de EntityQuery. EntityQuery e EntityHome

são classes do Seam.

50

Fig. 23 - Diagrama de Classes 1 - Entidades. Fonte: Elaborado pelos autores

51

Fig. 24 - Diagrama de classes 2 - EntityHome. Fonte: Elaborado pelos autores

52

Fig. 25 - Diagrama de classes 3 - Classes do Seam. Fonte: Elaborado pelos autores

53

Finalizadas as fases e tarefas do ICONIX, obtivemos as informações necessárias para

o desenvolvimento do sistema. Com os requisitos levantados e os diagramas construídos,

partimos para a fase de desenvolvimento do projeto, no qual foi utilizado o framework JBoss

Seam juntamente com outras tecnologias de personalização do sistema. Tal tarefa será

descrita no próximo capítulo.

3.4 Codificação

Para alguns autores essa etapa do desenvolvimento do projeto é considerada uma fase

do ICONIX, mas conforme ICONIXPROCESS(2007), que é a referência oficial do ICONIX,

são consideradas como fases do ICONIX a análise de requisitos, a análise e projeto preliminar

e o projeto. A codificação é uma tarefa desenvolvida após a utilização do ICONIX, na qual

utilizamos o framework JBoss Seam.

Primeiramente, antes de iniciar o projeto, foi necessário configurar o ambiente de

desenvolvimento Eclipse. Foi necessário instalar os softwares do JBossTools, SeamUpdate

através do menu Help.

54

Fig. 26 - Tela de configuração do ambiente Eclipse. Fonte: Elaborado pelos autores

Depois de configurado o ambiente foi necessário abrir a perspectiva Seam do Eclipe e

mandar gerar um Seam Web Project. O passo a passo para configuração foi aprendido em sala

de aula, na disciplina Tópicos Avançados do oitavo período do curso de Sistemas de

Informação da Univas.

55

Fig. 27 - Geração do Seam Web Project. Fonte: Elaborado pelos autores

Gerado o Seam Web Project, e com o banco de dados já criado, foi necessário gerar a

aplicação utilizando um arquivo de engenharia chamado hibernate.reveng.xml que faz

engenharia reversa, em conexão direta com o banco de dados, criando todas as classes do

projeto. Parte do código do arquivo pode ser visto na figura abaixo.

56

Fig. 28 - Codigo do hibernate.reveng.xml. Fonte: Elaborado pelos autores

Depois disto, a aplicação foi criada, sendo necessário fazer adaptações para tornar a

aplicação mais amigável com o cliente.

Fizemos a internacionalização do sistema, criando o arquivo

<messages_pt_BR.properties>, uma vez que a aplicação foi gerada com mensagens em inglês

e como era necessário traduzir, optamos por fazê-la já no padrão I18N, deixando a aplicação

com dois idiomas.

O framework JBoss Seam tem uma forma particular de gerar a aplicação, que muitas

vezes não atende todas funcionalidades necessárias. Foi preciso então, personalizar a

aplicação, fazendo com que ela atendesse os objetivos deste trabalho.

A usabilidade também foi um item não atendido pela aplicação gerada, e foram

necessárias algumas mudanças em posições de campos de formulários, estruturas de menus,

posições dos botões entre outras. Para realização dessas mudanças foi necessário buscar

informações sobre Richfaces, padrão utilizado pelo framework para geração das telas de

interfaces.

57

4 DISCUSSÃO DOS RESULTADOS

O objetivo geral do trabalho, que era desenvolver um software, que automatizasse o

atual sistema de vacinação das Unidades Básicas de Saúde da Gerência Regional de Saúde de

Pouso Alegre foi atendido. resultados esperados ao final deste trabalho foram satisfatórios.

Foram feitas pesquisas e levantamentos sobre o atual sistema de vacinação do Sistema Único

de Saúde, especificamente da Gerência Regional de Saúde de Pouso Alegre.

A utilização da metodologia ICONIX, seguindo suas 3 fases foram fundamentais para

o desenvolvimento da aplicação. Para implementação da aplicação, fase onde ocorre a

geração dos códigos, foi utilizado o framework: JBoss Seam, que é baseado na plataforma

Java, mais especificamente Java EE, voltada para Web .

A criação do banco de dados, foi fundamental para que a aplicação fosse desenvolvida

pela ferramenta seam-gen do framework JBoss Seam.

Foram diversas vezes em que foram necessárias alterações no banco de dados para que

a geração da aplicação fosse feita mais próxima do ideal. Depois das etapas executadas foram

feitas adequações no código afim de deixar a aplicação com todos os requisitos atendidos.

CONCLUSÃO

Os objetivos desse trabalho foram alcançados. O sistema “Cartão Espelho Eletrônico”

foi concluído com êxito, com a utilização da metodologia de desenvolvimento ICONIX e as

ferramentas descritas no decorrer deste trabalho.

Com a análise realizada através da metodologia ICONIX, foi possível implementar o

projeto com base nos requisitos levantados, sem deixar nenhum desses requisitos para traz.

A implementação do sistema com o auxilio do framework JBoss Seam nos

proporcionou agilidade no desenvolvimento, mas para sua utilização, tivemos que estudar a

fundo o funcionamento desta tecnologia. Também foi necessário adquirirmos conhecimentos

nas tecnologias Web Standards, para fazermos a personalização do sistema e torna-lo mais

atraente aos olhos do usuário, além de melhorar sua usabilidade.

O sistema foi testado pelos usuários finais, que interagiram bem com sua interface.

Como proposta a futuros trabalhos, podemos incluir o controle de estoque de vacinas

de cada UBS, facilitando a distribuição feita pela GRS.

59

REFERÊNCIAS

AHMED, Khawar Zaman; UMRYSH, Cary E., DESENVOLVENDO APLICAÇÕES

COMERCIAIS EM JAVA COM J2EE E UML. Rio de Janeiro. Editora Ciência Moderna

Ltda., 2002. ISBN 85-7393-240-6

ALVAREZ, Michel Angel. TUTORIAL – INTRODUÇÃO A JAVASCRIPT: Disponível

em < http://www.criarweb.com/artigos/156.php>. Acesso em 20/06/2010.

BONA, Cristina. Avaliação de Processos de Software: Um Estudo de Caso em XP e

ICONIX, 2002. Trabalho do Programa de Pós-Graduação. Engenharia da Produção.

Universidade Federal de Santa Catarina. Disponível

em:<http://200.169.53.89/download/CD%20congressos/2003/3%20CBComp/html/artigos/cbc

omp/engenharia%20de%20software/eng123.pdf >. Acesso em 20 de setembro de 2010.

BARROS, Aidil de Jesus Paes de,; LEHFELD, Neide Aparecida de Souza, PROJETO DE

PESQUISA: Propostas metodológicas. 13. ed. Rio de Janeiro. Editora Vozes, 2002. ISBN

85.326.0018-2

COSTA, Claudio Giulliano Alves da, DESENVOLVIMENTO E AVALIAÇÃO

TECNOLÓGICA DE UM SISTEMA DE PRONTUÁRIO ELETRÔNICO DO

PACIENTE, BASEADO NOS PARADIGMAS DA WORLD WIDE WEB E DA

ENGENHARIA DE SOFTWARE. 2001. 288f. Dissertação (Mestrado em Engenharia

Elétrica) – Universidade Estadual de Campinas, 2001.

GALLOIS, Felipe. CURSO BÁSICO DE HTML: Apostila desenvolvida para ser usada em

um curso básico de HTML do comitê Fome-Zero Joinville. 2008; Disponível em

<http://www.apostilando.com/download.php?cod=3174&categoria=HTML >. Acesso em 23

de Junho de 2010.

GUJ. JavaSever Faces: A mais nova tecnologia Java para desenvolvimento WEB.

Disponível em: <www.guj.com.br/content/articles/jsf/jsf.pdf>. Acesso em 07 de setembro de

2010.

IBM. Introdução a Programação Java. Disponível em: <

http://www.ibm.com/developerworks/br/java/newto/ >. Acesso em: 29 de agosto de 2010.

ICONIXPROCESS. Iconix Process, 2007. Disponível em: < http://iconixprocess.com >.

Acesso em: 28 de agosto de 2010.

LIMA, Adriano Gomes. JavaScript : Aplicações Interativas para a Web. Disponível em

<http://www.gico.com.br/site/pdf/JavaScript.pdf>. Acesso em 21/06/2010.

LUIZ, Roberson. APOSTILA DE JAVASCRIPT: Disponível em

<http://www.apostilando.com/download.php?cod=2741&categoria=JavaScript>. Acesso em

24 de Junho de 2010.

http://www.guj.com.br/content/articles/jsf/jsf.pdf

60

MAGALHÃES, Lúcia Helena. INTRODUÇÃO A PROGRAMAÇÃO WEB: Disponível

em <http://www.apostilando.com/download.php?cod=3069&categoria=HTML>. Acesso em

20 de Junho de 2010

PETERS, James F.; PEDRYCZ, Witold. ENGENHARIA DE SOFTWARE: Teoria e

Prática. Rio de Janeiro. Campus, 2001. ISBN 85-352-0746-5

PRESSMAN, RS. Engenharia de Software. São Paulo. Makron Books, 1995.

SILVA, Alberto M. R.; VIDEIRA, Carlos A. E. UML, Metodologias e Ferramentas Case.

Lisboa: Centro Atlântico, 2001.

SILVA, Edna Lúcia da, MENEZES, Estera Muszkat. Metodologia da Pesquisa e Elaboração

de Dissertação. Florianópolis. 3ed. FEESC. 2001.

SOLGATE, Vanessa Rocha. Apostila sobre o Banco de Dados PostGre. 2005. São Paulo:

UNESP, 2005. 58f. Disponível em: <http://www.unesp.br/gs/treinamento/graduacao/apostila

Postgre.pdf>. Acesso em 21/05/2010

SOUZA, Carla Elisabete Huppes de. O USO DA INFORMÁTICA NA SALA DE

VACINAÇÃO. Florianópolis, 2002. 117f. Dissertação (Mestrado em Engenharia de

Produção) - Programa de Pós-graduação em Engenharia de Produção, UFSC, 2002.

TELES, Vinicius Manhães. EXTREME PROGRAMMING: Aprenda como encantar seus

usuários desenvolvendo software com agilidade e alta qualidade. Rio de Janeiro. Novatec

Editora, 2004. ISBN 85.752.2047-0.

TUTORIAL HTML. Disponível em: <http://pt-br.html.net/tutorials/html>. Acesso em:

20/06/2010.

TUTORIAL CSS. Disponível em<http://pt-br.html.net/tutorials/css/introduction.php>.

Acesso em: 20/06/2010.

http://pt-br.html.net/tutorials/html

http://pt-br.html.net/tutorials/css/introduction.php

ANEXOS

APÊNDICES

TELAS DA INTERFACE

Fig. 29 - Tela do Login. Fonte: Elaborado pelos autores

Fig. 30 - Tela de Boas Vindas, depois de logado. . Fonte: Elaborado pelos autores

Fig. 31 - Tela de Cadastro e Edição de Usuário do SUS. Fonte: Elaborado pelos autores

Fig. 32 - Tela de Informações de Usuário Cadastrado. Fonte: Elaborado pelos autores

.

Fig. 33 - Busca e Listagem de Clientes. Fonte: Elaborado pelos autores

Fig. 34 - Tela de Criação do Cartão. Fonte: Elaborado pelos autores

Fig. 35 - Tela de Exibição dos Dados do Cartão. Fonte: Elaborado pelos autores

Fig. 36 - Busca e Listagem de Cartões. Fonte: Elaborado pelos autores

Fig. 37 - Tela de Aplicação de Vacinas. Fonte: Elaborado pelos autores

Fig. 38 - Tela de Exibição das Vacinas Aplicadas. Fonte: Elaborado pelos autores

Fig. 39 - Tela de Cadastro de Vacinas. Fonte: Elaborado pelos autores

tccfinal cee

Documents