Upload
victor-almeida
View
49
Download
3
Embed Size (px)
Citation preview
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
ALICE DOMINGUES FERREIRA
VICTOR ANTÔNIO DE ALMEIDA
VITOR SIMÃO FERREIRA
CARTÃO ESPELHO ELETRÔNICO
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
ALICE DOMINGUES FERREIRA
VICTOR ANTÔNIO DE ALMEIDA
VITOR SIMÃO FERREIRA
CARTÃO ESPELHO ELETRÔNICO
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
Ações 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 informações do novo Cliente.
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
Tabela 3 - Fluxo de Evento "cadastrar cartão"
Nome do caso de uso Cadastrar Cartão
Ator Principal Administrador ou AdminUBS
Pre-codições Estar logado como Administrador ou
AdminUBS
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 Cartão 4-Abre a tela de Cadastro de Cartão
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 Cartão já existe no banco de
dados.
9-Impede o cadastro e envia uma mensagem
de „erro‟, caso o Cartão já exista no banco de
dados.
10-Salva as informações do novo Cartão.
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
40
Tabela 4 - Fluxo de Evento "cadastrar aplicação"
Nome do caso de uso Cadastrar Aplicação
Ator Principal Administrador ou AdminUBS
Pre-codições Estar logado como Administrador ou
AdminUBS
Fluxo Principal
Ações do Ator Resposta do Sistema
1-Clica no menu de vacinação 2-Abre a tela de registro de aplicação
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 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.
9-Envia uma mensagem de sucesso.
10-Clica em OK 11-Permanece com o formulário de aplicações
aberto, em branco, optando ao usuário a novas
aplicações.
Fonte: Elaborado pelos autores
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
Ações do Ator Resposta do Sistema
1-Clica no menu cadastro 2-Abre a aba de cadastros
3-Clica em cadastro de Laboratório 4-Abre a tela de Cadastro de Laboratório
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 Laboratório já existe no banco
de dados.
9-Impede o cadastro e envia uma mensagem
de „erro‟, caso o Laboratório já exista no
banco de dados.
10-Salva as informações do novo Laboratório.
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
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.
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.
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