Vous êtes sur la page 1sur 69

ALICE DOMINGUES FERREIRA VICTOR ANTNIO DE ALMEIDA VITOR SIMO FERREIRA

CARTO ESPELHO ELETRNICO

UNIVERSIDADE DO VALE DO SAPUCA POUSO ALEGRE 2010

ALICE DOMINGUES FERREIRA VICTOR ANTNIO DE ALMEIDA VITOR SIMO FERREIRA

CARTO ESPELHO ELETRNICO

Trabalho de Concluso de Curso apresentado ao Departamento de Sistema de Informao da Faculdade de Filosofia, Cincias e Letras Eugnio Pacelli da Universidade do Vale do Sapuca, como requisito para obteno do ttulo de Bacharel em Sistemas de Informao. Orientador : Professor Ednardo David Segura

UNIVERSIDADE DO VALE DO SAPUCA POUSO ALEGRE 2010

ALICE DOMINGUES FERREIRA VICTOR ANTNIO DE ALMEIDA VITOR SIMO FERREIRA

CARTO ESPELHO ELETRNICO

Monografia defendida e aprovada em ___/___/_____ pela banca examinadora constituda pelos professores:

_________________________________ Professor EDNARDO DAVID SEGURA Orientador _________________________________ Professora CRISHNA IRION Examinadora _________________________________ Professor PAULO CSAR 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 foras para seguir em frente em todos os momentos difceis; Ao nosso professor orientador Ednardo, pelo empenho e dedicao desde o comeo do projeto e pelos conselhos valiosos; A professora Joelma Pereira de Faria e ao professor Jos Luiz da Silva, por todo o apoio; A Gerncia Regional de Sade de Pouso Alegre pela disponibilizao de informaes vitais para o desenvolvimento deste projeto.

De Alice: Agradeo aos meus pais, Antnio e Terezinha, por todo amor, carinho e dedicao 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: Agradeo primeiramente a Deus, pelo dom da vida. Agradeo aos meus pais que sempre me apoiaram em todas minhas decises. Aos amigos e colegas de grupo, Alice Ferreira e Vitor Simo. Ao Bruno Leite que muito ajudou no desenvolvimento deste trabalho.

De Vitor: Agradeo aos meus pais e familiares, que foram e inspirao de todo meu trabalho. Aos meus colegas e amigos deste projeto, Alice Ferreira e Victor Antnio pela unio e dedicao. Em especial, ao meu tio, Joo Luiz, que sempre esteve presente e me estendeu a mo nos momentos mais difceis.

"Para realizar grandes conquistas, devemos no apenas agir, mas tambm sonhar; no apenas planejar, mas tambm acreditar." ( Anatole France )

FERREIRA, Alice Domingues; ALMEIDA, Victor Antnio; FERREIRA, Vitor Simo. Carto Espelho Eletrnico: 2010. Monografia Curso de Sistemas de Informao da Faculdade de Filosofia Cincia e Letras Eugnio Pacelli, Universidade do Vale do Sapuca, Pouso Alegre, 2010.

RESUMO

Este trabalho de concluso de curso visa o desenvolvimento de um sistema web para controle de vacinas aplicadas nos usurios do Sistema nico de Sade (SUS). A proposta substituir o controle de vacinao feito atravs de cartes de papel. Para a concluso desse sistema, utilizamos a linguagem Java para web, juntamente com outras tecnologias web, como o HTML e CSS e com o auxlio 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 Gerncia Regional de Sade de Pouso Alegre. Como resultado desse trabalho, foi concludo um sistema onde sero armazenados dados vacinais de cada usurio do SUS. Esses dados podero ser visualizados pelo funcionrio da Sala de Vacina no ato da imunizao, verificando a real necessidade de tomar essa vacina e evitando doses repetidas. Tais dados tambm podero ser visualizados pelo prprio usurio, pela internet, para que ele mesmo verifique se est em dia com sua vacinao e emitir comprovantes. Esse trabalho de grande relevncia social, pois o recebimento de doses repetidas no organismo pode levar at a morte. Com isso, os objetivos propostos no trabalho foram concludos.

Palavras-chave: Imunizao. Carto de vacina. JBoss Seam. ICONIX.

FERREIRA, Alice Domingues; ALMEIDA, Victor Antnio; FERREIRA, Vitor Simo. Electronic Mirror Card: 2010. Monografia Curso de Sistemas de Informao da Faculdade de Filosofia Cincia e Letras Eugnio 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 Sade (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 carto de vacina. ................................................................................ 15 Figura 02 - Arquivo de cartes espelho .................................................................................... 16 Figura 03 - Atividades relacionadas anlise de requisitos. .................................................... 21 Figura 04 - Atividades relacionadas anlise e projeto preliminar. ........................................ 22 Figura 05 - Atividades relacionadas ao projeto. ....................................................................... 23 Figura 06 - Integrao do JBoss Seam em uma arquitetura Java EE. ...................................... 24 Figura 07 - Arquitetura do JSF baseada no modelo MVC. ...................................................... 25 Figura 08 - Prototipao da tela "Lista de Clientes". ............................................................... 30 Figura 9 - Prototipao da tela "Cadastrar Cliente" ................................................................. 31 Figura 10 - Prototipao da tela "Cliente" ................................................................................ 32 Figura 11 - Prototipao da tela "Inserir Aplicao" ................................................................ 33 Figura 12 - Prototipao da tela "Carto do Cliente" ............................................................... 34 Figura 13 - Modelo de domnio ................................................................................................ 35 Figura 14 - Identificao dos casos de uso ............................................................................... 36 Figura 15 - Esteretipos utilizados ........................................................................................... 41 Figura 16 - Anlise de Robustez - Cadastrar Cliente ............................................................... 42 Figura 17 - Anlise de Robustez - Cadastrar Usurio .............................................................. 42 Figura 18 - Anlise de Robustez - Cadastrar Vacina................................................................ 43 Figura 19 - Atualizao do Modelo de Domnio ...................................................................... 44 Figura 20 - Diagrama de Sequncia - Cadastrar Vacina .......................................................... 46 Figura 21 - Diagrama de Sequncia - Cadastrar Usurio ......................................................... 47 Figura 22 - Diagrama de Sequncia - 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 configurao do ambiente Eclipse. ........................................................... 54 Figura 27 - Gerao 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 Edio de Usurio do SUS ...................................................... 64 Figura 32 - Tela de Informaes de Usurio Cadastrado ......................................................... 64 Figura 33 - Busca e Listagem de Clientes ................................................................................ 65 Figura 34 - Tela de Criao do Carto ..................................................................................... 65 Figura 35 - Tela de Exibio dos Dados do Carto .................................................................. 66 Figura 36 - Busca e Listagem de Cartes ................................................................................. 66 Figura 37 - Tela de Aplicao de Vacinas ................................................................................ 67 Figura 38 - Tela de Exibio 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 carto" ......................................................................... 39 Tabela 4 - Fluxo de Evento "cadastrar aplicao" .................................................................... 40 Tabela 5 - Fluxo de Evento "cadastrar laboratrio" ................................................................. 40

LISTA ABREVIATURAS E SIGLAS

AJAX API CEE EE EJB GRS HTML HTTP IBM JSP JSF SQL SUS UBS UML XML XP

Asynchronous JavaScript and XML Application Programming Interface Carto Espelho Eletrnico Enterprise Edition Entrerprise Java Beans Gerncia Regional de Sade HyperText Markup Language HyperText Transfer Protocol International Business Machines JavaServer Pages JavaServer Faces Structured Query Language Sistema nico de Sade Unidade Bsica de Sade Unified Modeling Language Extensible Markup Language Extreme Programming

SUMRIO
INTRODUO ........................................................................................................................ 14 2 FUNDAMENTAO TERICA ................................................................................... 19 2.1 Engenharia de Software........................................................................................... 19 2.2 ICONIX....................................................................................................................20 2.2.1 Anlise de requisitos...................................................................................... 20 2.2.2 Anlise 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 Anlise de Requisitos...............................................................................................29 3.1.1 Prototipao ................................................................................................... 29 3.1.2 Modelo de Domnio.......................................................................................34 3.1.3 Identificao dos casos de Uso ...................................................................... 36 3.2 Anlise e Projeto Preliminar ..................................................................................... 37 3.2.1 3.2.2 3.2.3 3.3 Descrio dos casos de Uso .......................................................................... 37 Anlise de Robustez ..................................................................................... 41 Atualizao do modelo de domnio .............................................................. 43

Projeto..................................................................................................................... 44

3.3.1 Diagramas de Seqncia ................................................................................ 45 3.3.2 Concluso do modelo esttico ....................................................................... 49 3.4 Codificao ............................................................................................................... 53 4 DISCUSSO DOS RESULTADOS ................................................................................ 57

CONCLUSO .......................................................................................................................... 58 REFERNCIAS ....................................................................................................................... 59

INTRODUO

O objetivo geral deste trabalho desenvolver um software Carto Espelho Eletrnico para automatizao do atual sistema de vacinao que atualmente feito atravs de cartes de papel. Para o alcance do objetivo geral do trabalho foi necessrio: levantar informaes do atual sistema de vacinao junto Gerncia Regional de Sade de Pouso Alegre, utilizar metodologias de desenvolvimento juntamente com algumas tecnologias que sero descritas no captulo de Fundamentao Terica e criar um banco de dados com as informaes necessrias administrao dos postos de sade do SUS1 Sistema nico de Sade e tambm aos seus usurios. O Carto Espelho Eletrnico, que neste trabalho ser denominado CEE 2, trata-se de uma aplicao web desenvolvida para automatizar o atual sistema de vacinao realizado no Sistema nico de Sade - SUS. A atual situao do sistema de vacinao, na qual falta, por parte do SUS, um controle efetivo das aplicaes de doses por cliente e por parte das UBSs o controle das vacinas aplicadas so problemas existentes que levaram ao desenvolvimento do CEE. Atualmente muitos cidados, denominados neste trabalho, usurios do SUS, perdem seus cartes de vacinao e, com isso, no tm 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 no saberem se a vacina ainda est no perodo de validade no organismo.

1 2

A partir deste ponto chamaremos o Sistema nico de Sade somente como SUS. A partir deste ponto chamaremos o Carto Espelho Eletrnico somente como CEE.

15

Figura 01 - Exemplo de carto de vacina. Fonte: Elaborado pelos autores.

O desenvolvimento do CEE vem ao encontro da necessidade do SUS em ter um controle efetivo das aplicaes das vacinas nos usurios. Ao ter as informaes armazenadas em um sistema automatizado, o SUS ter condies de controlar as aplicaes de doses, bem como monitorar as vacinas j aplicadas nos usurios, evitando assim a aplicao de doses repetidas e ainda podendo atualizar vacinas j com a validade expirada no organismo. O registro das informaes vacinais de cada usurio do Sistema nico de Sade (SUS) a tarefa diria daqueles que trabalham na rea assistencial de sade. O chamado carto espelho, ou seja, ficha que contm informaes sobre aplicaes de vacinas por clientes o agrupamento das anotaes dessas informaes. O carto espelho denominado assim, por ser uma cpia armazenada junto s Unidades Bsicas de Sade - UBS3, do carto de vacinao (carto que fica em posse do usurio, contendo das informaes de vacinas recebidas). O carto espelho um formulrio em papel que fica armazenado na UBS a qual um usurio a visita pela primeira vez.

A partir deste ponto chamaremos as Unidades Bsicas de Sade somente como UBS.

16

Fig. 02 - Arquivo de cartes espelho. Fonte: GRS Pouso Alegre.

Diversos so os problemas, encontrados hoje em dia, para se manter os cartes espelhos atualizados, ou ainda, com as informaes idnticas aos cartes de vacinao. Primeiramente, pelo fato do carto espelho ser um formulrio de papel e ficar armazenado na Unidade Bsica de Sade, a qual o usurio visitou a primeira vez. Se este, mudar de endereo, municpio ou ainda procurar outra UBS, ele no ter nesta nova Unidade, informaes relativas a seu histrico de vacinao. Outro problema a ser apontado, a perda do carto de vacinao por parte dos usurios. Eles acabam no 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 no saberem se a vacina ainda est no perodo de validade no organismo. Um problema apontado pela referncia tcnica de imunizao da Gerncia Regional de Sade - GRS de Pouso Alegre, que, algumas UBSs dos municpios pela qual responsvel, alegam que quando h campanhas vacinao feitas pelo Ministrio da Sade, fica praticamente impossvel atualizar todos os cartes espelhos, uma vez que a demanda nestas Unidades muito alta, tendo atualizaes feitas somente nos cartes de vacinao dos usurios. Com isso, as informaes vacinais de cada usurio no so efetivamente controladas, o que acarreta problemas como doses repetidas no organismo ou o no 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 Ministrio da Sade, a validade da vacina de febre amarela no organismo de 10 anos, sem a necessidade de reforo. A superdosagem trs diversas reaes como: febre, dores de cabea, vmito, enrijecimento dos msculos, problemas neurolgicos e ainda a prpria contrao da doena que pode levar morte. Alguns trabalhos semelhantes j foram desenvolvidos. Costa (2001) desenvolveu um sistema de armazenamento de informaes sobre pacientes que assemelha-se ao nosso trabalho no que diz respeito s tecnologias e pelo fato de tambm ser voltado para rea da sade. Ainda nesta direo, tivemos contato com o trabalho de Souza (2002), que relata o quo seria mais fcil se a sala de vacinao fosse informatizada. Ela prope o uso da tecnologia a fim de garantir eficcia no atendimento populao. O uso do CEE torna o controle de vacinao de usurios mais efetivo, reduzindo a repetio nas aplicaes, tornando-as mais geis e, ainda, mantendo as informaes arquivadas em um banco de dados, onde consultas podero ser feitas online, tanto pela UBS, no ato da aplicao, para verificar a real necessidade do cliente tomar a vacina que ele quer, quanto pelo usurio, para que ele mesmo verifique se est em dia com sua vacinao 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 Informao, na Universidade do Vale do Sapuca (UNIVAS). Funcionria lotada na Gerencia Regional de Sade de Pouso Alegre h dois anos Juntamente no grupo, Vitor Simo Ferreira, tambm aluno do curso de Sistemas de Informao e ex-funcionrio da Gerencia Regional de Sade de Pouso Alegre. J havia desenvolvido um sistema de banco de dados que armazenasse as informaes de vacinao. O terceiro integrante do grupo, Victor Antnio de Almeida, tcnico em telecomunicaes, formado pelo SENAI em Belo Horizonte/MG, funcionrio do SEBRAE Minas na regional Pouso Alegre, transferido UNIVAS em agosto de 2008, percebendo a importncia e a relevncia do trabalho a ser desenvolvido, decidiu se juntar ao grupo para auxiliar no desenvolvimento do sistema. O trabalho conta ainda com a colaborao de Irene Podverseck Reis, referncia tcnica de imunizao da GRS (Gerncia Regional de Sade) de Pouso Alegre e orientado

18

por Ednardo David Segura, professor da UNIVAS, especialista em desenvolvimento de sistemas para internet. Nos prximos captulos sero apresentadas a fundamentao terica, as metodologias e a documentao necessria para o desenvolvimento do projeto.

1919

FUNDAMENTAO TERICA

Com o surgimento da engenharia de software, atualmente produz-se aplicaes com custos reduzidos, agilidade nos processos de produo, validao e manuteno. Segundo Pressman(2002), o trabalho associado engenharia de software pode ser categorizado em fases genricas independente da rea de aplicao, tamanho do projeto e complexidade. As fases necessariamente focam na definio(o que fazer), no desenvolvimento (como fazer) e na manuteno (modificaes).

2.1

Engenharia de Software

A engenharia de software vem se desenvolvendo rapidamente. Hoje ela oferece uma grande variedade de frameworks4, mtodos e tecnologias que auxiliam as atividades comumente encontradas em projetos de software. Tm-se, atualmente, diversas ferramentas novas, muito poderosas, que auxiliam na organizao do processo de desenvolvimento e oferece suporte total ao processo de desenvolvimento do software. vista atualmente como a aplicao dos mtodos 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, mtodos e prticas teis no desenvolvimento de um produto de software. As atividades associadas a esse processo de software incluem a descrio e preparao de esquemas que identifiquem a estrutura de dados e elementos de controle de um sistema, codificao, verificao e implantao de software. Uma abordagem de engenharia engenharia de software. Segundo Peters e Pedrycz (2001) engenharia de software: caracteriza-se por um desenvolvimento de software prtico, ordenado e medido, com objetivo principal de produzir sistemas satisfatrios que respeitem prazos e oramentos.

Framework um conjunto de classes que colaboram para realizar uma responsabilidade para um domnio de um subsistema da aplicao

20

Metodologias geis se tornaram populares a partir de 2001, e so aplicadas nos projetos que sofrem mudanas 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, prtica e simples, mas tambm poderosa e com um componente de anlise e representao dos problemas slido 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 no to complexo como o RUP, ou seja, no gera tanta documentao nem to simples quanto o XP. E apesar de ser um processo simples, no deixa a desejar na Anlise e Projeto (Design), e se destaca com um poderoso processo de desenvolvimento de software. Este processo tambm faz uso da linguagem de modelagem UML e possui uma caracterstica exclusiva chamada "Rastreabilidade dos Requisitos" (Traceability of Requirements). Mais precisamente, ICONIX nos permite "obrigatoriamente", atravs de seus mecanismos, verificar em todas as fases se os requisitos esto sendo atendidos. A abordagem ICONIX flexvel e aberta, isto , se for necessrio usar outro recurso da UML para complementar os recursos usados nas fases do ICONIX, no h problema algum.

2.2.1 Anlise de Requisitos

Fase da tarefa de anlise de requisitos, em que so identificados os objetos existentes no mundo real e suas relaes de associao, agregao e generalizao entre os objetos. Criase ento, um diagrama de classe de alto-nvel que conhecido como modelo de domnio.

A partir deste momento chamaremos a Extreme Programming de XP

21

Fig. 03 - Atividades relacionadas anlise de requisitos. Fonte: Silva e Videira(2001).

Ocorre, nessa fase, a elaborao de um prottipo da interface, com um diagrama de navegao, 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 relaes. No diagrama de pacotes associam-se os casos de uso em grupos e agrupa os requisitos funcionais aos objetos de domnio.

2.2.2 Anlise e Projeto Preliminar

Fase em que so descritos os casos de uso do fluxo principal das aes, fluxos alternativos e fluxos de excees. elaborada uma anlise de robustez atualizando o modelo de domnio e diagrama de classes.

22

Fig. 04 - Atividades relacionadas anlise e projeto preliminar. Fonte: Silva e Videira(2001)

Aps a atualizao do modelo de domnio e do diagrama de classes ocorre a concluso da fase de anlise e projeto preliminar.

2.2.3 Projeto

Esta a fase de especificao do comportamento atravs do diagrama de sequncia. Utiliza os textos de casos de uso e sempre atualiza o diagrama de classe medida que novos objetos e atributos vo sendo descobertos.

23

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

Ocorre a finalizao do modelo esttico do diagrama de classe verificando o atendimento a todos os requisitos. Aps as fases descritas, comea-se o desenvolvimento do projeto, que para alguns autores tal tarefa considerada uma fase do ICONIX, mas segundo ICONIXPROCESS(2007), essa etapa no faz parte do ICONIX.

2.3

Java

Criada em 1990, por uma equipe chefiada por James Gosling, na empresa Sun Microsystems, Java, alm de uma linguagem de programao tambm uma plataforma. uma linguagem orientada a objeto e diferentemente de outras linguagens, seu cdigo compilado em um bytecode6 que interpretado e traduzido pela Java Virtual Machine (JVM). uma plataforma apenas de software e pode ser executada sobre vrias plataformas de hardware. Na JVM, possui um grande conjunto de componentes de software (classes), para facilitar o desenvolvimento de implantao dos aplicativos. Java possui trs edies de plataformas: Java SE (Java Platform, Standard Edition), que permite desenvolver e implantar aplicativos Java em desktops e servidores e tambm ambientes integrados e em tempo real. O Java EE (Java Platform Enterprise Edition) uma verso corporativa que ajuda a desenvolver e implantar aplicativos Java do lado do servidor

24

que so transportveis, robustos, escalveis e seguros. A terceira edio o Java ME (Java Platform, Micro Edition), voltado para desenvolvimento de aplicativos para dispositivos mveis e integrados, como telefones, celulares entre outros.

2.3.1 JBoss Seam

O JBoss Seam um framework utilizado para desenvolvimento de aplicaes 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 aplicaes Java EE ou Tomcat. O seu desenvolvimento teve como objetivo eliminar a complexidade em nveis de arquitetura. Oferece controle sobre a implementao da lgica de negcio sem a necessidade de se preocupar com as configuraes dos arquivos XML. A principal funcionalidade integrar JSF e EJB3.

Fig. 06 - Integrao do JBoss Seam em uma arquitetura Java EE. Fonte: jboss.com

A partir de um banco de dados modelado, o Seam atravs de um gerador: seam-gen cria a aplicao. So necessrias algumas configuraes para conexo com o banco de dados, de onde o seam-gen busca s informaes para gerao da aplicao. Estas sero mostradas no captulo de Desenvolvimento.

Bytecode o cdigo gerado pelo compilador de Java e executado pela Mquina Virtual XML ou eXtensible Markup Language que pode ser definido de linguagem padronizada de marcao genrica e ser denominado de XML
7

25

2.3.2 Java Server Faces (JSF)

JSF uma tecnologia com caractersticas de um framework MVC(padro que divide uma aplicao em trs camadas: modelo, visualizao e controle) para web8 juntamente com um modelo de interfaces grficas baseado em eventos. Existe uma clara separao entre a visualizao e regras de negcio. A camada de modelo representa os objetos de negcio. A visualizao a interface com o usurio, ou seja, a forma como os dados so apresentados. A camada de controle responsvel por fazer a ligao entre a camada de modelo e a interface, gerando uma visualizao 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 aplicaes para web, que utilizam o framework JSF. Os componentes possuem suporte AJAX que deixam as interfaces da aplicao com visual padronizado. A utilizao dos componentes do RichFaces, facilita a incorporao das caractersticas das aplicaes de sistema web que utilizam o JavaServer Faces.

26

2.4

Web Standarts

O HTML - HyperText Markup Language ou Linguagem de Marcao Hiper Texto uma linguagem de formatao voltada para criao de paginas Web. Inventado em 1990 por Tim Berners Lee, HTML pode ser entendido como um cdigo que ser lido por um navegador. formado por um simples documento de texto com extenso .html que pode ser criado em qualquer editor e interpretado por diversos navegadores. Um documento HTML constitudo por tags, ou etiquetas, que so os comandos existentes no documento. As tags informam ao navegador como o contedo do documento deve ser exibido. Com elas possvel dividir o documento em cabealho -<head>e corpo <body> e tambm inserir outros recursos como tabelas, imagens, links, etc. As tags podem possuir atributos, que so caractersticas especificas no documento. Com a evoluo do HTML, surgiu o XHTML, que a juno do HTML com o XML(eXtensible Markup Language). O XHTML a mais nova verso do HTML Com a expanso da web e a elaborao de pginas e sites cada vez mais complexos, o HTML sozinho no era capaz de acompanhar essa evoluo, pois no oferecia muitos recursos. Com isso, em 1995, a Nestcape lanou o JavaScript, uma linguagem de programao capaz de inserir efeitos e funcionalidades especiais, alem de uma interatividade maior com o usurio. Segundo Alvarez (2004), o JavaScript implementado dentro de uma pgina HTML, entre as tags <script> e </script>. Para trabalhar com essa linguagem, necessrio apenas um editor de texto simples( bloco de notas, notepad) ou um programa especfico para desenvolver cdigos, e um browser compatvel com JavaScript. Ainda de acordo com Alvarez(2004), apesar de Java e JavaScript terem origens comuns, so tcnicas diferentes, usadas para fins distintos. Java muito mais complexo que JavaScript, com ele possvel desenvolver aplicaes diversas, enquanto o JavaScript utilizado apenas em aplicaes web, dentro de um documento HTML. De acordo com Lima(2006), o JavaScript, assim como o HTML segue normas de padronizao do ECMA-262. Isso garante que as paginas implementadas nesse padro funcionaro corretamente em diversos navegadores.

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 pginas web em documentos escritos em linguagens de marcao, como o HTML e o XML. Trata-se de um conjunto de comandos que define como as informaes do HTML sero organizadas na pgina. 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 definies de estilo da pagina, pois assim vrias paginas podem compartilhar o mesmo layout; um documento central que define a aparncia de uma ou mais pginas. Basta rotular uma tag do HTML no CSS e alterar seus atributos. Com a CSS, possvel definir a cor de fundo da pgina, as imagens de fundo, as fontes utilizadas, o tamanho das letras, a disposio das imagens, dos textos, dos links, ou seja, possvel criar layouts nicos e precisos para inmeras pginas 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, no necessitando modificar o cdigo em todas as pginas. A unio do JavaScript com a CSS conhecida como DHTML. Usando o Javascript, possvel modificar dinamicamente os estilos dos elementos da pgina 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 produo de informao. O PostGreSQL um sistema de gerenciamento de banco de dados objetorelacional(SGBDOR). Desenvolvido no Departamento de Cincia da Computao da Universidade da Califrnia em Berkeley, foi pioneiro em muitos conceitos objetos-relacionais que agora esto se tornando disponveis em alguns bancos de dados comerciais. O PostGreSQL possui seu cdigo fonte aberto e fornece suporte linguagem SQL, alm 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 espao de tempo. A opo do framework JBoss Seam se deu pelo desafio aprofundar os conhecimentos na tecnologia, que relativamente nova no mercado e tambm pela facilidade de produtividade que a ferramenta oferece na implementao 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, alm de ser uma ferramenta de gerenciamento de dados bastante confivel pelo meio acadmico.

29

METODOLOGIA DE DESENVOLVIMENTO

Para o desenvolvimento deste trabalho, coletamos informaes junto GRS de Pouso Alegre, livros, artigos, portal do Ministrio da Sade e trabalhos semelhantes relacionados ao mesmo tema. So quatros fases para concluso do trabalho: anlise de requisitos, projeto preliminar e anlise, projeto e desenvolvimento do sistema. Na fase anlise de requisitos foi feita a prototipao do sistema, juntamente com a identificao dos objetos e suas relaes alm da identificao dos casos de uso e o modelo de domnio. Na fase seguinte, projeto preliminar e anlise, fizemos a descrio dos casos de uso, apresentamos a anlise de robustez e a atualizao do modelo de domnio. A fase do projeto que consiste em especificar o comportamento do sistema atravs do diagrama de sequncia e concluir o modelo esttico. A seguir sero descritas as fases para o desenvolvimento do sistema, utilizando a metodologia Iconix.

3.1

Anlise de Requisitos

o levantamento de informaes, sobre quais especificaes o software deve atender. Para isso, so desenvolvidas trs tarefas fundamentais: a prototipao do sistema, o modelo de domnio e a identificao dos casos de uso. Tais tarefas sero apresentadas a seguir.

3.1.1 Prototipao

Fase que se define como ficaro as telas da aplicao. Com a prototipao possvel obter uma pr-visualizao do que se deseja desenvolver e, segundo Bona(2002), serve tambm para o cliente entender melhor o que o sistema ir fazer. Consiste em esboar as principais telas, e assim ter uma idia mais real do comportamento do sistema, alm de

30

facilitar as demais fases da metodologia ICONIX, como por exemplo, a Descrio dos Casos de Uso. Abaixo, um prottipo da tela lista de Clientes. Nessa tela, o usurio SalaVacina tem as opes de visualizar os dados de cada cliente e de cadastrar um novo cliente atravs do boto novo.

Fig. 08 - Prototipao da tela "Lista de Clientes". Fonte: Elaborado pelos autores

Se for acionado o boto novo, ser redirecionado para a tela Cadastrar Cliente, como mostra a figura 9. Nessa tela, o usurio tem que preencher os campos com os dados do novo cliente e clicar em salvar.

31

Fig. 9 - Prototipao da tela "Cadastrar Cliente". Fonte: Elaborado pelos autores

Quando o usurio escolhe a opo de visualizar os dados do cliente, ser direcionado para a tela Cliente, como mostra a figura 11. Nessa tela, o usurio tem a possibilidade de visualizar os dados pessoais do cliente selecionado e as vacinas que ele j recebeu. possvel tambm editar os dados do usurio atravs do boto editar, e de cadastrar uma nova aplicao, atravs do boto nova aplicao.

32

Fig. 10 - Prototipao da tela "Cliente". Fonte: Elaborado pelos autores

Se o usurio clicar no boto nova aplicao, abrir a tela Inserir aplicao, como mostra a figura 12. Nessa tela, o usurio cadastra a nova dose que o cliente est tomando.

33

Fig. 11 - Prototipao da tela "Inserir Aplicao". Fonte: Elaborado pelos autores

O cliente tambm poder fazer suas prprias consultas online. Quando ele acessar seu carto atravs de seu login e senha, ser direcionado para uma pgina com todas suas informaes vacinais. O prottipo dessa pgina pode ser visualizado na figura 13.

34

Fig. 12 - Prototipao da tela "Carto do Cliente". Fonte: Elaborado pelos autores

Os itens foram projetados de maneira estratgica, pois no menu Sala Vacina por exemplo, para efetuar uma aplicao de vacina no Cliente, obrigado a passar pela tela onde esto cadastradas as doses que o usurio j tomou, assim reduzindo o risco de o profissional da Sala de Vacina aplicar uma dose indevida no cliente.

3.1.2 Modelo de Domnio

De acordo com Silva(2007), criar o Modelo de Domnio consiste em achar classes, substantivos, frases de substantivos, verbos e frases de verbos, que se tornaro objetos, atributos e associaes em um diagrama de domnio. descobrir objetos de um problema do mudo real e transformar em um diagrama. Bona (2002) destaca que substantivos e frases com

35

substantivos so entendidos como objetos e atributos e verbos e frases com verbos se tornam operaes. Para realizar o Modelo de Domnio, preciso primeiramente identificar as classes, excluindo todos os itens que no sero utilizados. A partir da deve-se construir os relacionamentos de generalizao e as associaes. O resultado mostrado a seguir.

Fig. 13 - Modelo de domnio. Fonte: Elaborado pelos autores

Para Bona(2002), essa fase um primeiro levantamento de entidades, que tem de ser o mais simples possvel e sem muitos detalhes. O objetivo principal do Modelo de Domnio levantar as entidades que faro parte do sistema, sem muitos detalhes. O detalhamento de cada entidade ser feito posteriormente na Atualizao do modelo de domnio e na concluso do modelo esttico.

36

3.1.3 Identificao dos casos de Uso

Um caso de uso mostra a interao da aplicao com o universo exterior, descreve quais requisitos a aplicao 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 identificao dos casos de uso do CEE.

Fig. 14 - Identificao dos casos de uso. Fonte: Elaborado pelos autores

A partir da analise de requisitos j possvel ter uma viso geral do que ser preciso para desenvolver a aplicao. Com essa anlise, podemos identificar os seguintes requisitos: O problema da falta de controle dos dados vacinais de cada usurio do SUS s seria resolvido se fosse criado um sistema web, pois s assim o carto poderia ser atualizado em qualquer UBS procurada pelo usurio. Se o sistema fosse Desktop, no resolveria totalmente o problema existente. Os atores definidos na anlise de requisitos so: AdmGeral, que teria permisso total no sistema, mas seu papel principal seria cadastras os demais usurios e seria algum

37

da GRS; AdmUbs, que seria cadastrado pelo AdmGeral e teria papel principal de cadastrar usurios do tipo SalaVacina e que poderia ser o responsvel pela UBS; e SalaVacina, que seria o funcionrio da Sala de Vacina, o que lida diretamente com os usurios do SUS. Os dados do cliente que no podem faltar em seu cadastro, como nome, CPF, RG, endereo, etc. O dado principal do cliente, ou seja, sua chave seria o CPF, por ser nico. Quando o cliente em questo for criana e no possuir CPF, ser vinculado ao CPF de um responsvel.

Aps a Anlise de Requisitos, ser apresentado a segunda fase do ICONIX: a Anlise e Projeto Preliminar.

3.2

Anlise e Projeto Preliminar

Concluda a anlise dos requisitos do sistema, iniciamos a fase de Anlise e Projeto Preliminar, onde fizemos a Descrio dos casos de uso(ou Fluxo de Eventos), a Anlise de Robustez e a Atualizao do Modelo de Domnio.

3.2.1 Descrio dos casos de Uso

Descreve com detalhes as aes do usurio e as respostas do sistema. Segundo ICONIX Process, os casos de uso ajudam a identificar o que os usurios do sistema esto fazendo e qual a resposta que obteve. A idia facilitar da melhor maneira possvel, para que o usurio com conhecimentos em informtica, avanados ou no, possa concretizar suas necessidades com sucesso, com a menor dificuldade possvel. A padronizao dos nomes utilizados e a clareza nos textos so questes importantes para a construo da descrio dos casos de uso, para melhor compreenso dos fluxos. Tambm importante descrever, alm das aes do usurio, as respostas do sistema para essas aes, 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"

Cadastrar Vacina Administrador Estar logado como Administrador Fluxo Principal Aes 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 informaes da nova vacina 11-Envia uma mensagem de sucesso 12-Clica em OK 13-Permanece com o formulrio de cadastro aberto, em branco, optando ao usurio a novos cadastros. Nome do caso de uso Ator Principal Pre-codies

Fonte: Elaborado pelos autores

39

Tabela 2 - Fluxo de Evento "cadastrar cliente"

Cadastrar Cliente Administrador ou AdminUBS Estar logado como Administrador ou AdminUBS Fluxo Principal Aes do Ator Resposta do Sistema 1-Clica no menu cadastro 2-Abre a aba de cadastros 3-Clica em cadastro de Paciente 4-Abre a tela de Cadastro de Cliente 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 o Cliente j existe no banco de dados. 9-Impede o cadastro e envia uma mensagem de erro, caso o Cliente j exista no banco de dados. 10-Salva as informaes do novo Cliente. 11-Envia uma mensagem de sucesso. 12-Clica em OK 13-Permanece com o formulrio de cadastro aberto, em branco, optando ao usurio a novos cadastros. Nome do caso de uso Ator Principal Pr-condies

Fonte: Elaborado pelos autores


Tabela 3 - Fluxo de Evento "cadastrar carto"

Cadastrar Carto Administrador ou AdminUBS Estar logado como Administrador ou AdminUBS Fluxo Principal Aes do Ator Resposta do Sistema 1-Clica no menu cadastro 2-Abre a aba de cadastros 3-Clica em cadastro de Carto 4-Abre a tela de Cadastro de Carto 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 o Carto j existe no banco de dados. 9-Impede o cadastro e envia uma mensagem de erro, caso o Carto j exista no banco de dados. 10-Salva as informaes do novo Carto. 11-Envia uma mensagem de sucesso. 12-Clica em OK 13-Permanece com o formulrio de cadastro aberto, em branco, optando ao usurio a novos cadastros. Nome do caso de uso Ator Principal Pre-codies

Fonte: Elaborado pelos autores

40

Tabela 4 - Fluxo de Evento "cadastrar aplicao"

Cadastrar Aplicao Administrador ou AdminUBS Estar logado como Administrador ou AdminUBS Fluxo Principal Aes do Ator Resposta do Sistema 1-Clica no menu de vacinao 2-Abre a tela de registro de aplicao 3-Preenche os campos e clica em Salvar 4-Verifica se os campos foram preenchidos corretamente. 5-Envia mensagem informando para preencher os campos corretamente, se for o caso 6-Verifica se a aplicao no 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 informaes da nova aplicao. 9-Envia uma mensagem de sucesso. 10-Clica em OK 11-Permanece com o formulrio de aplicaes aberto, em branco, optando ao usurio a novas aplicaes. Nome do caso de uso Ator Principal Pre-codies

Fonte: Elaborado pelos autores

Tabela 5 - Fluxo de Evento "cadastrar laboratrio"

Cadastrar Laboratrio Administrador Estar logado como Administrador ou Fluxo Principal Aes do Ator Resposta do Sistema 1-Clica no menu cadastro 2-Abre a aba de cadastros 3-Clica em cadastro de Laboratrio 4-Abre a tela de Cadastro de Laboratrio 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 o Laboratrio j existe no banco de dados. 9-Impede o cadastro e envia uma mensagem de erro, caso o Laboratrio j exista no banco de dados. 10-Salva as informaes do novo Laboratrio. 11-Envia uma mensagem de sucesso. 12-Clica em OK 13-Permanece com o formulrio de cadastro aberto, em branco, optando ao usurio a novos cadastros. Nome do caso de uso Ator Principal Pr-codies

Fonte: Elaborado pelos autores

41

As informaes levantadas na descrio dos casos de uso sero utilizadas na prxima tarefa do ICONIX, a Anlise de Robustez.

3.2.2 Anlise de Robustez

A anlise de robustez construda baseada na descrio dos casos de uso. a interao entre os objetos. Para Bona(2002), analisar a descrio de cada caso de uso e identificar um primeiro conjunto de possveis objetos que participaro desse caso de uso. Esses objetos so classificados em esteretipos:

Objetos de limite (boundary objects): os atores usam para se comunicar com o sistema No caso, representa as telas do sistema que fazem a interao com o usurio. Objetos de entidade (entity objects): Objetos do modelo de Domnio. So as entidades do Banco de Dados do Sistema. Objetos de controle (control objects): fazem a ligao entre os objetos de limite e os objetos de entidade. So os mtodos de objetos de entidade ou de objetos de limite.

A figura abaixo mostra os smbolos utilizados na analise de robustez para identificar cada esteretipo.

Fig. 15 - Esteretipos utilizados. Fonte: Bona(2002)

Para criao do diagrama de robustez, preciso prestar ateno 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 usurio. Um objeto de limite no conversa

42

diretamente com objetos de entidade, tendo que fazer sua ligao atravs de um objeto de controle. Para concluirmos a anlise de robustez foi necessrio revisar as etapas anteriores do ICONIX.

Figura 16 - Anlise de Robustez - Cadastrar Cliente . Fonte: Elaborado pelos autores

Fig. 17 - Anlise de Robustez - Cadastrar Usurio. Fonte: Elaborado pelos autores

43

Fig. 18 - Anlise de Robustez - Cadastrar Vacina. Fonte: Elaborado pelos autores

3.2.3 Atualizao do modelo de domnio

Passada a fase de anlise de robustez e as fases anteriores do ICONIX, temos que atualizar o modelo de domnio feito na analise de requisitos. Nessa fase j foram descobertos novos objetos com atributos, novas classes e novas associaes. A figura abaixo mostra o Modelo de Domnio atualizado, com os atributos de cada objeto.

44

Fig. 19 - Atualizao do Modelo de Domnio. Fonte: Elaborado pelos autores

Feita a Anlise e Projeto Preliminar, pudemos obter caractersticas fundamentais do sistema, para que possamos desenvolver a fase de projeto, que ser apresentado no prximo captulo.

3.3

Projeto

Na fase de Projeto, segundo Silva e Videira (2001), especificamos o comportamento para cada caso de uso, com a construo dos diagramas de seqncia e finalizamos o modelo esttico, adicionando informaes mais detalhadas. Tais tarefas sero descritas a seguir.

45

3.3.1 Diagramas de Seqncia

Nos diagramas de seqncia feita a previso de como o sistema ir funcionar. Para isso, utilizamos os objetos e classes identificados na Anlise de Robustez. Para Silva e Videira(2001), os diagramas de seqncia mostram a colaborao entre os objetos do sistema e a seqncia 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 finalizao da distribuio das operaes nas classes, o que acaba auxiliando tambm na concluso do modelo esttico.

46

Fig. 20 - Diagrama de Sequncia - Cadastrar Vacina. Fonte: Elaborado pelos autores

47

Fig. 21 - Diagrama de Sequncia - Cadastrar Usurio. Fonte: Elaborado pelos autores

48

Fig. 22 - Diagrama de Sequncia - Cadastrar UBS. Fonte: Elaborado pelos autores

49

3.3.2 Concluso do modelo esttico

Nessa etapa do ICONIX, o Modelo de Domnio criado na Anlise de Requisitos e atualizado com atributos na Analise e Projeto Preliminar ganhar mtodos, novos atributos e novas classes, que formaro diagramas de classes completos. Essa a Concluso do Modelo Esttico. As figuras a seguir, representam essa tarefa do ICONIX concluda. O diagrama foi dividido em trs partes para melhor visualizao. 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 so 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 informaes necessrias para o desenvolvimento do sistema. Com os requisitos levantados e os diagramas construdos, partimos para a fase de desenvolvimento do projeto, no qual foi utilizado o framework JBoss Seam juntamente com outras tecnologias de personalizao do sistema. Tal tarefa ser descrita no prximo captulo.

3.4

Codificao

Para alguns autores essa etapa do desenvolvimento do projeto considerada uma fase do ICONIX, mas conforme ICONIXPROCESS(2007), que a referncia oficial do ICONIX, so consideradas como fases do ICONIX a anlise de requisitos, a anlise e projeto preliminar e o projeto. A codificao uma tarefa desenvolvida aps a utilizao do ICONIX, na qual utilizamos o framework JBoss Seam. Primeiramente, antes de iniciar o projeto, foi necessrio configurar o ambiente de desenvolvimento Eclipse. Foi necessrio instalar os softwares do JBossTools, SeamUpdate atravs do menu Help.

54

Fig. 26 - Tela de configurao do ambiente Eclipse. Fonte: Elaborado pelos autores

Depois de configurado o ambiente foi necessrio abrir a perspectiva Seam do Eclipe e mandar gerar um Seam Web Project. O passo a passo para configurao foi aprendido em sala de aula, na disciplina Tpicos Avanados do oitavo perodo do curso de Sistemas de Informao da Univas.

55

Fig. 27 - Gerao do Seam Web Project. Fonte: Elaborado pelos autores

Gerado o Seam Web Project, e com o banco de dados j criado, foi necessrio gerar a aplicao utilizando um arquivo de engenharia chamado hibernate.reveng.xml que faz engenharia reversa, em conexo direta com o banco de dados, criando todas as classes do projeto. Parte do cdigo do arquivo pode ser visto na figura abaixo.

56

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

Depois disto, a aplicao foi criada, sendo necessrio fazer adaptaes para tornar a aplicao mais amigvel com o cliente. Fizemos a internacionalizao do sistema, criando o arquivo

<messages_pt_BR.properties>, uma vez que a aplicao foi gerada com mensagens em ingls e como era necessrio traduzir, optamos por faz-la j no padro I18N, deixando a aplicao com dois idiomas. O framework JBoss Seam tem uma forma particular de gerar a aplicao, que muitas vezes no atende todas funcionalidades necessrias. Foi preciso ento, personalizar a aplicao, fazendo com que ela atendesse os objetivos deste trabalho. A usabilidade tambm foi um item no atendido pela aplicao gerada, e foram necessrias algumas mudanas em posies de campos de formulrios, estruturas de menus, posies dos botes entre outras. Para realizao dessas mudanas foi necessrio buscar informaes sobre Richfaces, padro utilizado pelo framework para gerao das telas de interfaces.

57

DISCUSSO DOS RESULTADOS


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

atual sistema de vacinao das Unidades Bsicas de Sade da Gerncia Regional de Sade de Pouso Alegre foi atendido. resultados esperados ao final deste trabalho foram satisfatrios. Foram feitas pesquisas e levantamentos sobre o atual sistema de vacinao do Sistema nico de Sade, especificamente da Gerncia Regional de Sade de Pouso Alegre. A utilizao da metodologia ICONIX, seguindo suas 3 fases foram fundamentais para o desenvolvimento da aplicao. Para implementao da aplicao, fase onde ocorre a gerao dos cdigos, foi utilizado o framework: JBoss Seam, que baseado na plataforma Java, mais especificamente Java EE, voltada para Web . A criao do banco de dados, foi fundamental para que a aplicao fosse desenvolvida pela ferramenta seam-gen do framework JBoss Seam. Foram diversas vezes em que foram necessrias alteraes no banco de dados para que a gerao da aplicao fosse feita mais prxima do ideal. Depois das etapas executadas foram feitas adequaes no cdigo afim de deixar a aplicao com todos os requisitos atendidos.

CONCLUSO

Os objetivos desse trabalho foram alcanados. O sistema Carto Espelho Eletrnico foi concludo com xito, com a utilizao da metodologia de desenvolvimento ICONIX e as ferramentas descritas no decorrer deste trabalho. Com a anlise realizada atravs da metodologia ICONIX, foi possvel implementar o projeto com base nos requisitos levantados, sem deixar nenhum desses requisitos para traz. A implementao do sistema com o auxilio do framework JBoss Seam nos proporcionou agilidade no desenvolvimento, mas para sua utilizao, tivemos que estudar a fundo o funcionamento desta tecnologia. Tambm foi necessrio adquirirmos conhecimentos nas tecnologias Web Standards, para fazermos a personalizao do sistema e torna-lo mais atraente aos olhos do usurio, alm de melhorar sua usabilidade. O sistema foi testado pelos usurios 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 distribuio feita pela GRS.

59

REFERNCIAS
AHMED, Khawar Zaman; UMRYSH, Cary E., DESENVOLVENDO APLICAES COMERCIAIS EM JAVA COM J2EE E UML. Rio de Janeiro. Editora Cincia Moderna Ltda., 2002. ISBN 85-7393-240-6 ALVAREZ, Michel Angel. TUTORIAL INTRODUO A JAVASCRIPT: Disponvel em < http://www.criarweb.com/artigos/156.php>. Acesso em 20/06/2010. BONA, Cristina. Avaliao de Processos de Software: Um Estudo de Caso em XP e ICONIX, 2002. Trabalho do Programa de Ps-Graduao. Engenharia da Produo. Universidade Federal de Santa Catarina. Disponvel 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 metodolgicas. 13. ed. Rio de Janeiro. Editora Vozes, 2002. ISBN 85.326.0018-2 COSTA, Claudio Giulliano Alves da, DESENVOLVIMENTO E AVALIAO TECNOLGICA DE UM SISTEMA DE PRONTURIO ELETRNICO DO PACIENTE, BASEADO NOS PARADIGMAS DA WORLD WIDE WEB E DA ENGENHARIA DE SOFTWARE. 2001. 288f. Dissertao (Mestrado em Engenharia Eltrica) Universidade Estadual de Campinas, 2001. GALLOIS, Felipe. CURSO BSICO DE HTML: Apostila desenvolvida para ser usada em um curso bsico de HTML do comit Fome-Zero Joinville. 2008; Disponvel 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. Disponvel em: <www.guj.com.br/content/articles/jsf/jsf.pdf>. Acesso em 07 de setembro de 2010. IBM. Introduo a Programao Java. Disponvel em: < http://www.ibm.com/developerworks/br/java/newto/ >. Acesso em: 29 de agosto de 2010. ICONIXPROCESS. Iconix Process, 2007. Disponvel em: < http://iconixprocess.com >. Acesso em: 28 de agosto de 2010. LIMA, Adriano Gomes. JavaScript : Aplicaes Interativas para a Web. Disponvel em <http://www.gico.com.br/site/pdf/JavaScript.pdf>. Acesso em 21/06/2010. LUIZ, Roberson. APOSTILA DE JAVASCRIPT: Disponvel em <http://www.apostilando.com/download.php?cod=2741&categoria=JavaScript>. Acesso em 24 de Junho de 2010.

60

MAGALHES, Lcia Helena. INTRODUO A PROGRAMAO WEB: Disponvel 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 Prtica. Rio de Janeiro. Campus, 2001. ISBN 85-352-0746-5 PRESSMAN, RS. Engenharia de Software. So Paulo. Makron Books, 1995. SILVA, Alberto M. R.; VIDEIRA, Carlos A. E. UML, Metodologias e Ferramentas Case. Lisboa: Centro Atlntico, 2001. SILVA, Edna Lcia da, MENEZES, Estera Muszkat. Metodologia da Pesquisa e Elaborao de Dissertao. Florianpolis. 3ed. FEESC. 2001. SOLGATE, Vanessa Rocha. Apostila sobre o Banco de Dados PostGre. 2005. So Paulo: UNESP, 2005. 58f. Disponvel em: <http://www.unesp.br/gs/treinamento/graduacao/apostila Postgre.pdf>. Acesso em 21/05/2010 SOUZA, Carla Elisabete Huppes de. O USO DA INFORMTICA NA SALA DE VACINAO. Florianpolis, 2002. 117f. Dissertao (Mestrado em Engenharia de Produo) - Programa de Ps-graduao em Engenharia de Produo, UFSC, 2002. TELES, Vinicius Manhes. EXTREME PROGRAMMING: Aprenda como encantar seus usurios desenvolvendo software com agilidade e alta qualidade. Rio de Janeiro. Novatec Editora, 2004. ISBN 85.752.2047-0. TUTORIAL HTML. Disponvel em: <http://pt-br.html.net/tutorials/html>. Acesso em: 20/06/2010. TUTORIAL CSS. Disponvel Acesso em: 20/06/2010. em<http://pt-br.html.net/tutorials/css/introduction.php>.

ANEXOS

APNDICES

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 Edio de Usurio do SUS. Fonte: Elaborado pelos autores

Fig. 32 - Tela de Informaes de Usurio Cadastrado. Fonte: Elaborado pelos autores

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

Fig. 34 - Tela de Criao do Carto. Fonte: Elaborado pelos autores

Fig. 35 - Tela de Exibio dos Dados do Carto. Fonte: Elaborado pelos autores

Fig. 36 - Busca e Listagem de Cartes. Fonte: Elaborado pelos autores

Fig. 37 - Tela de Aplicao de Vacinas. Fonte: Elaborado pelos autores

Fig. 38 - Tela de Exibio das Vacinas Aplicadas. Fonte: Elaborado pelos autores

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

Vous aimerez peut-être aussi