Sistema ARCA para gestão de vacinação

UNIVERSIDADE POTIGUAR - UNP
PRÓ-REITORIA DE GRADUAÇÃO
CURSO SISTEMAS DE INFORMAÇÃO
FRANCINALDO RODRIGUES DE LIMA
RICARDO JÚLIO DA SILVA CARVALHO
ARCA - SISTEMA GERENCIAL
NATAL
2012

RICARDO JÚLIO DA SILVA CARVALHO
Trabalho de Conclusão de Curso
apresentado a Universidade
Potiguar - UnP, como parte dos
requisitos para obtenção do grau de
Bacharel em Sistemas de
Informação.
Orientador: Profº Hideljundes
Macedo Paulino
NATAL
2012

RICARDO JULIO DA SILVA CARVALHO
Trabalho de Conclusão de Curso
apresentado a Universidade
Potiguar - UnP, como parte dos
requisitos para obtenção do grau de
Bacharel em Sistemas de
Informação.
Aprovado em ____/____/________
BANCA EXAMINADORA
__________________________________________
Profº Hideljundes Macedo Paulino
Orientador
Universidade Potiguar - UnP
__________________________________________
Profº Weinberg de Paiva e Souza
Universidade Potiguar - UnP

Dedico este trabalho primeiramente a Deus que me deu a vida e depois a minha
família que sempre esta do meu lado apoiando nos meus sonhos, quando alcanço
uma vitória agradeço a eles. Também quero agradecer a minha companheira Railma
que foi muito importante no decorrer deste trabalho, me incentivou, apoiou e
acreditou em mim. Dedico também este trabalho a todos aqueles que participaram
deste trabalho como Ricardo Júlio e Professor Hideljundes, compartilhando suas
experiências e aprendizados comigo.
Dedico este trabalho em primeiro lugar a Deus, pois sem ele nada disto seria
possível. À minha família em especial ao meu pai, João Amaro, porque mesmo sem
uma escolaridade alta, sempre nos incentivo a estudar às vezes sacrificando-se para
não abandonarmos os estudos. Aos meus filhos, pelo apoio e compreensão da
minha ausência. À Francinaldo Rodrigues pelo companheirismo nesta jornada. À
Hideljundes pela orientação e aprendizados.

AGRADECIMENTOS
Agradeço primeiramente a Deus que esta permitindo a conquista de mais um
objetivo na nossa vida e também por ter nos concedido o nosso bem maior que é
nossa vida. Agradeço a minha família que estar sempre presente nos orientando e
apoiando em todas as etapas de nossas vidas e não foi diferente neste trabalho de
conclusão de curso. Agradeço também a minha companheira que também me
apoiou na caminha em rumo à realização deste trabalho. Também quero agradecer
ao professor Hidel Junes que nos orientou e com sua grande experiência pode nos
direcionar para o melhor caminho. Devo agradecer também ao meu parceiro Ricardo
Júlio que me apoiou e conduziu de forma eficiente às obrigações do nosso trabalho.
Para finalizar agradeço a todos que participaram diretamente ou indiretamente para
a realização deste trabalho.
A Deus e Jesus Cristo fontes de vida e esperança. A minha família pelo apoio e
compreensão. Ao Professor Hideljundes pela atenção e orientação. A Francinaldo
Rodrigues pelo apoio e paciência. A todos os professores. A Dra. Sônia Mesquita
pela confiança e acreditar em nosso trabalho. A Anne Vaz pelas conversas
esclarecedoras. A todos que contribuíram de forma direta ou indireta para a
conclusão deste trabalho.

Nossa maior fraqueza está em desistir. A maneira mais segura de ter sucesso é
sempre tentar mais uma vez.
Thomas Edison
Uma vez que não podemos ser universais e saber tudo quanto se pode saber acerca
de tudo, é preciso saber-se um pouco de tudo, pois é muito melhor saber-se alguma
coisa de tudo do que saber-se tudo apenas de uma coisa.
Blaise Pascal

RESUMO
Este trabalho apresenta os resultados da análise e desenvolvimento de um sistema
web que foi chamado de “ARCA” para a empresa AMI (Assistência Médica Infantil)
Vacinas, e teve como objetivo atender as necessidades existentes, melhorando
processos e apoiando na tomada de decisão. Na fase de analise, foi adotada a
metodologia ICONIX, proporcionando resultados imediatos. Quanto ao
desenvolvimento, levando em consideração os requisitos funcionais e/ou não
funcionais, foram adotadas as mais modernas tecnologias web: linguagem de
programação JÁVA com JSF, framework UI Primefaces, sistema gerenciador de
banco de dados PostegreSQL, servidor web EJB GlassFish, programação orientada
a objetos, entre outras. O sistema contempla os módulos administrativo, estoque,
vacinação e financeiro, sendo seu principal, o módulo de vacinação, que gerencia o
cadastro e aplicação de vacina, enviando lembretes e sugerindo vacinas aos
pacientes.
Palavras-chave: Arca, AMI, Vacina.

ABSTRACT
This study presents the results of the analysis and development of a web system that
was called "ARCA" for the company AMI (Assistance Medical Child) vaccines, and
aimed to answer existing needs, improving processes and supporting in decision
making. In the analysis phase, the methodology ICONIX was adopted, providing
immediate results. Regarding development, considering the functional and not
functional requirements, were adopted the most advanced web technologies: the
Java programming language with JSF, Primefaces UI framework, system database
manager, PostegreSQL, EJB GlassFish web server, object-oriented programming,
among others. The system includes administrative, inventory, vaccination, and
financial modules, and the vaccination it‟s the principal module, which manages the
registration and use of vaccine, that module suggesting vaccines and sending
reminders to patients
Palavras-chave: Arca, AMI, Vaccine.

LISTA DE ILUSTRAÇÕES
Figura 1: Processo Iconix ..............................................................................................18
Figura 2: Ciclo de Vida das Requisições JavaServer Faces .......................................24
Figura 3: Fluxo de Execução de um Relatório .............................................................27
Figura 4: Padrão MVC JavaServer Faces ....................................................................31
Figura 5: Padrão MVC JavaServer Faces II .................................................................31
Figura 6: Modelo convencional e com o Padrão Façade ............................................32
Figura 7: Caso de Uso do Módulo Administrativo........................................................42
Figura 8: Tela Fazer Login.............................................................................................44
Figura 9: Diagrama de Robustez Fazer Login..............................................................45
Figura 10: Diagrama de Sequência Fazer Login..........................................................45
Figura 11: Tela Alterar Senha........................................................................................46
Figura 12: Diagrama de Robustez Alterar Senha ........................................................47
Figura 13: Diagrama de Sequência Alterar Senha.......................................................47
Figura 14: Tela Cadastrar Empresa..............................................................................49
Figura 15: Diagrama de Robustez Cadastrar Empresa...............................................50
Figura 16: Diagrama de Sequência Cadastrar Empresa.............................................51
Figura 17: Tela Cadastrar Módulo.................................................................................53
Figura 18: Diagrama de Robustez Cadastrar Módulo..................................................53
Figura 19: Diagrama de Sequência Cadastrar Módulo................................................54
Figura 20: Tela Cadastrar Nível ....................................................................................56
Figura 21: Diagrama de Robustez Cadastrar Nível .....................................................56
Figura 22: Diagrama de Sequência Cadastrar Nível ...................................................57
Figura 23: Tela Cadastrar Menu Grupo ........................................................................59
Figura 24: Diagrama de Robustez Cadastrar Menu Grupo .........................................59
Figura 25: Diagrama de Sequência Cadastrar Menu Grupo .......................................60
Figura 26: Tela Cadastrar Menu Item ...........................................................................62
Figura 27: Diagrama de Robustez Cadastrar Menu Item ............................................62
Figura 28: Diagrama de Sequência Cadastrar Menu Item ..........................................63
Figura 29: Tela Cadastrar Usuário................................................................................65
Figura 30: Diagrama de Robustez Cadastrar Usuário.................................................65
Figura 31: Diagrama de Sequência Cadastrar Usuário ...............................................66
Figura 32: Tela Alternar Empresa .................................................................................67

Figura 33: Diagrama de Robustez Alternar Empresa ..................................................68
Figura 34: Diagrama de Sequência Alternar Empresa ................................................68
Figura 35: Tela Consultar Logs .....................................................................................69
Figura 36: Diagrama de Robustez Consultar Logs ......................................................70
Figura 37: Diagrama de Sequência Consultar Logs ....................................................70
Figura 38: Mensagem de Notificação Falha no Login..................................................71
Figura 39: Diagrama de Robustez Notificar Falha no Login........................................71
Figura 40: Diagrama de Sequência Notificar Falha no Login......................................72
Figura 41: Modelo de Domínio do Módulo Administrativo ...........................................73
Figura 42: Diagrama de Classes do Módulo Administrativo........................................74
Figura 43: Caso de Uso do Módulo Estoque................................................................75
Figura 44: Tela Cadastrar Unidade...............................................................................77
Figura 45: Diagrama de Robustez Cadastrar Unidade................................................77
Figura 46: Diagrama de Sequência Cadastrar Unidade ..............................................78
Figura 47: Tela Cadastrar Produto................................................................................80
Figura 48: Diagrama de Robustez Cadastrar Produto.................................................80
Figura 49: Diagrama de Sequência Cadastrar Produto...............................................81
Figura 50: Tela Cadastrar Fabricante ...........................................................................83
Figura 51: Diagrama de Robustez Cadastrar Fabricante ............................................83
Figura 52: Diagrama de Sequência Cadastrar Fabricante ..........................................84
Figura 53: Tela Cadastrar Almoxarifado.......................................................................86
Figura 54: Diagrama de Robustez Cadastrar Almoxarifado........................................86
Figura 55: Diagrama de Sequência Cadastrar Almoxarifado ......................................87
Figura 56: Tela Cadastrar Grupo de produto................................................................89
Figura 57: Diagrama de robustez Cadastrar Grupo de Produto .................................89
Figura 58: Diagrama de Sequência Cadastrar Grupo de Produto ..............................90
Figura 59: Tela Cadastrar Fornecedor..........................................................................92
Figura 60: Diagrama de Robustez Cadastrar Fornecedor...........................................93
Figura 61: Diagrama de Sequência Cadastrar Fornecedor.........................................94
Figura 62: Tela Cadastrar Nota de Almoxarifado - Etapa 1.........................................95
Figura 63: Tela Cadastrar Nota de Almoxarifado - Etapa 2.........................................96
Figura 64: Tela Cadastrar Nota de Almoxarifado - Informações Lote/Vencimento....96
Figura 65: Tela Cadastrar Nota de Almoxarifado - Impressão de Nota Estoque.......97
Figura 66: Diagrama de Robustez Nota de Almoxarifado ...........................................97

Figura 67: Diagrama de Sequência Nota de Almoxarifado .........................................98
Figura 68: Tela Estornar Nota de Almoxarifado ...........................................................99
Figura 69: Diagrama de Robustez Estornar Nota de Almoxarifado ..........................100
Figura 70: Diagrama de Sequência Estornar Nota de Almoxarifado ........................100
Figura 71: Tela Cadastrar Nota de Transferência - Etapa 1 .....................................101
Figura 72: Tela Cadastrar Nota de Transferência - Etapa 2 .....................................102
Figura 73: Tela Cadastrar Nota de Transferência - Impressão.................................102
Figura 74: Diagrama de Robustez Nota de Transferência de Almoxarifado ............103
Figura 75: Diagrama de Sequência Nota de Transferência de Almoxarifado ..........104
Figura 76: Tela Relatório de Saldo de Estoque..........................................................105
Figura 77: Relatório de Saldo de Estoque..................................................................105
Figura 78: Diagrama de Robustez Relatório de Saldo ..............................................106
Figura 79: Diagrama de Sequência Relatório de Saldo.............................................107
Figura 80: Modelo de Domínio do Módulo Estoque...................................................108
Figura 81: Diagrama de Classes do Módulo Estoque................................................109
Figura 82: Caso de Uso do Módulo Vacinação ..........................................................110
Figura 83: Tela Cadastrar Cliente ...............................................................................112
Figura 84: Diagrama de Robustez Cadastrar Cliente ................................................113
Figura 85: Diagrama de Sequência Cadastrar Cliente ..............................................114
Figura 86: Tela Cadastrar Médico...............................................................................116
Figura 87: Diagrama de Robustez Cadastrar Médico................................................116
Figura 88: Diagrama de Sequência Cadastrar Médico..............................................117
Figura 89: Tela Cadastrar Vacinador ..........................................................................119
Figura 90: Diagrama de Robustez Cadastrar Vacinador...........................................119
Figura 91: Diagrama de Sequência Cadastrar Vacinador .........................................120
Figura 92: Tela Cadastrar Tabela de Preço ...............................................................122
Figura 93: Diagrama de Robustez Cadastrar Tabela de Preço ................................123
Figura 94: Diagrama de Sequência Cadastrar Tabela de Preço ..............................124
Figura 95: Tela Cadastrar Vacina ...............................................................................126
Figura 96: Diagrama de Robustez Cadastrar Vacina ................................................126
Figura 97: Diagrama de Sequência Cadastrar Vacina ..............................................127
Figura 98: Tela Cadastrar Bandeira de Cartão de Crédito ........................................129
Figura 99: Diagrama de Robustez Cadastrar Bandeira de Cartão de Crédito.........129
Figura 100: Diagrama de Sequência Cadastrar Bandeira de Cartão de Crédito.....130

Figura 101: Tela Cadastrar Forma de Pagamento.....................................................132
Figura 102: Diagrama de Robustez Cadastrar Forma de Pagamento .....................133
Figura 103: Diagrama de Sequência Cadastrar Forma de Pagamento ...................134
Figura 104: Tela Cadastrar Esquema de Vacina .......................................................135
Figura 105: Diagrama de Robustez Esquema de Vacina..........................................136
Figura 106: Diagrama de Sequência Esquema de Vacina........................................137
Figura 107: Tela Abrir Caixa........................................................................................138
Figura 108: Diagrama de Robustez Abrir Caixa.........................................................139
Figura 109: Diagrama de Sequência Abrir Caixa.......................................................139
Figura 110: Tela Encerrar Caixa .................................................................................140
Figura 111: Tela Encerrar Caixa - Conferência Cartão .............................................141
Figura 112: Tela Encerrar Caixa - Visualizar Venda..................................................141
Figura 113: Diagrama de Robustez Encerrar Caixa ..................................................142
Figura 114: Diagrama de Sequência Encerrar Caixa ................................................143
Figura 115: Tela Cadastrar Venda - Etapa 1..............................................................144
Figura 116: Tela Cadastrar Venda - Etapa 2..............................................................144
Figura 117: Tela Cadastrar Venda - Selecionar Cliente ............................................145
Figura 118: Diagrama de Robustez Venda ................................................................146
Figura 119: Diagrama de Sequência Venda...............................................................147
Figura 120: Tela Realizar Recebimento .....................................................................148
Figura 121: Tela Realizar Recebimento - Selecionar Venda ....................................148
Figura 122: Tela Realizar Recebimento - Alterar Tabela de Preço ..........................149
Figura 123: Tela Realizar Recebimento - Selecionar Conta do Cliente ...................149
Figura 124: Diagrama de Robustez Realizar Recebimento ......................................150
Figura 125: Diagrama de Sequência Realizar Recebimento ....................................151
Figura 126: Tela Realizar Aplicação ...........................................................................152
Figura 127: Tela Realizar Aplicação - Selecionar Cliente .........................................152
Figura 128: Diagrama de Robustez Realizar Aplicação ............................................153
Figura 129: Diagrama de Sequência Realizar Aplicação ..........................................154
Figura 130: Tela Cadastrar Saldo de Cliente .............................................................155
Figura 131: Diagrama de Robustez Cadastrar Saldo de Cliente ..............................155
Figura 132: Diagrama de Sequência Cadastrar Saldo de Cliente ............................156
Figura 133: Mensagem de Notificação Vacina Pendente / Indicada ........................157
Figura 134: Diagrama de Robustez Notificar Vacina Pendente / Indicada...............158

Figura 135: Diagrama de Sequência Notificar Vacina Pendente / Indicada.............159
Figura 136: Mensagem de Notificação Venda Cancelada ........................................160
Figura 137: Diagrama de Robustez Notificar Venda Cancelada...............................160
Figura 138: Diagrama de Sequência Notificar Venda Cancelada.............................161
Figura 139: Diagrama de Notificação Gerencial.........................................................162
Figura 140: Diagrama de Sequência Notificação Gerencial......................................162
Figura 141: Modelo de Domínio do Módulo de Vacinação........................................163
Figura 142: Diagrama de Classes do Módulo de Vacinação ....................................164
Figura 143: Caso de Uso do Módulo Financeiro........................................................165
Figura 144: Tela Cadastrar Caixa ...............................................................................167
Figura 145: Diagrama de Robustez Cadastrar Caixa ................................................168
Figura 146: Diagrama de Sequência Cadastrar Caixa ..............................................169
Figura 147: Tela Cadastrar Plano de Conta...............................................................171
Figura 148: Diagrama de Robustez Cadastrar Plano de Conta................................172
Figura 149: Diagrama de Sequência Cadastrar Plano de Conta ..............................173
Figura 150: Tela Cadastrar Favorecido ......................................................................175
Figura 151: Diagrama de Robustez Cadastrar Favorecido .......................................176
Figura 152: Diagrama de Sequência Cadastrar Favorecido .....................................177
Figura 153: Modelo de Domínio do Módulo de Financeiro........................................178
Figura 154: Diagrama de Classes do Módulo de Financeiro ....................................179
Quadro 1: Calendário da Criança..................................................................................13
Quadro 3: Calendário do Adolescente..........................................................................14
Quadro 4: Calendário do Adulto e do Idoso .................................................................14
Quadro 5: Notas Importantes das Verões do JSF .......................................................24

LISTA DE ABREVIAÇÕES E SIGLAS
AJAX Asynchronous Javascript and XML
AMI Assistência Médica Infantil
ASF Apache Software Foundation
BO Business Object
DAO Data Access Object
EE Enterprise Edition
EJB Enterprise Java Beans
EUA Estados Unidos da América
FW Framework
GUI Graphical User Interface
IDE Integrated Development Environment
ISO International Organization for Standardization
J2EE Java 2 Platform, Enterprise Edition
JCP Java Community Process
JDBC Java Database Connectivity
JPA Java Persistente API
JSF JavaServer Faces
JSP JavaServer Pages
JSR Java Specification Requests
MVC Model-view-controller
OO Orientação a Objetos
ORM Object Relacional Mapping
PNI Programa Nacional de Imunizações
POJO Plain Old Java Objects
POO Programação Orientada a Objetos
RI Reference Implementation
RUP Rational Unified Processes
SGBDSistema Gerenciador de Banco de Dados
SQL Structured Query Language
UI Users Interface
UML Linguagem de Modelagem Unificada
XP Extreme Programming

SUMÁRIO
1 INTRODUÇÃO ..............................................................................................................9
1.1 PROPOSTA............................................................................................................9
1.2 OBJETIVO GERAL ..............................................................................................10
1.3 OBJETIVOS ESPECIFICOS ...............................................................................10
1.4 JUSTIFICATIVA ...................................................................................................10
2 A EMPRESA E A ATIVIDADE...................................................................................11
2.1 IMUNIZAÇÃO.......................................................................................................11
2.2 VACINAS E DOENÇAS.......................................................................................12
2.3 CALENDÁRIO ......................................................................................................13
2.3.1 Vacinação do Viajante ................................................................................15
3 METODOLOGIA .........................................................................................................16
3.1 ORIENTAÇÃO A OBJETOS................................................................................16
3.2 UML.......................................................................................................................17
3.3 ICONIX..................................................................................................................17
3.3.1 Fase de Análise de Requisitos..................................................................18
3.3.2 Fase de Analise e Projeto Preliminar.......................................................19
3.3.3 Fase de Projeto............................................................................................19
3.3.4 Fase de Implementação .............................................................................19
4 ARQUITETURA ..........................................................................................................21
4.1 LINGUAGEM DE PROGRAMAÇÃO E FRAMEWORK .....................................21
4.2 TECNOLOGIAS UTILIZADAS.............................................................................23
4.2.1 JSF.................................................................................................................23
4.2.2 Primefaces....................................................................................................25
4.2.3 Servlets .........................................................................................................25
4.2.4 EJB3 Persistence e JPA.............................................................................26
4.2.5 Jasper Report e iReport .............................................................................26
4.2.6 Tomcat...........................................................................................................27
4.3 SISTEMA GERENCIADOR DE BANCO DE DADOS........................................28
4.3.1 PostgreSQL ..................................................................................................29
4.4 PADRÕES ARQUITETURAIS E DE PROJETO ................................................29
4.4.1 MVC................................................................................................................30
4.4.2 Façade...........................................................................................................32

4.4.3 DAO................................................................................................................32
4.4.4 Abstract Factory..........................................................................................33
4.5 PADRONIZAÇÃO DE CODIFICAÇÃO E NOMENCLATURA ...........................33
4.5.1 Banco de Dados ..........................................................................................34
4.5.2 Linguagem de Programação .....................................................................34
5 ANÁLISE DE REQUISITOS......................................................................................36
5.1 REQUISITOS FUNCIONAIS ...............................................................................36
5.1.1 Módulo Administrativo ...............................................................................36
5.1.2 Módulo Estoque...........................................................................................37
5.1.3 Módulo Vacinação.......................................................................................37
5.1.4 Módulo Financeiro ......................................................................................38
5.2 REQUISITOS NÃO FUNCIONAIS ......................................................................39
6 REGRAS DE NEGÓCIO.............................................................................................41
7 MODELAGEM DO MÓDULO ADMINISTRATIVO ...................................................42
7.1 MODELO DINÂMICO...........................................................................................42
7.1.1 Diagrama de Casos de Usos .....................................................................42
7.1.2 Fazer Login (CSU001).................................................................................43
7.1.3 Alterar Senha (CSU002)..............................................................................46
7.1.4 Manter Empresa (CSU003).........................................................................48
7.1.5 Manter Módulo (CSU004) ...........................................................................51
7.1.6 Manter Nível (CSU005)................................................................................54
7.1.7 Manter Menu Grupo (CSU006)...................................................................57
7.1.8 Manter Menu Item (CSU007) ......................................................................60
7.1.9 Manter Usuário (CSU008)...........................................................................63
7.1.10 Alternar Empresa (CSU009).....................................................................66
7.1.11 Consultar Logs (CSU010) ........................................................................69
7.1.12 Notificar Falha no Login (CSU011).........................................................71
7.2 MODELO ESTÁTICO...........................................................................................73
7.2.1 Modelo de Domínio .....................................................................................73
7.2.2 Diagrama de Classes..................................................................................74
8 MODELAGEM DO MÓDULO ESTOQUE.................................................................75
8.1 MODELO DINÂMICO...........................................................................................75
8.1.1 Diagrama de Casos de Usos .....................................................................75
8.1.2 Manter Unidade (CSU012)..........................................................................75

8.1.3 Manter Produto (CSU013) ..........................................................................78
8.1.4 Manter Fabricante (CSU014)......................................................................82
8.1.5 Manter Almoxarifado (CSU015).................................................................84
8.1.6 Manter Grupo de Produtos (CSU016).......................................................87
8.1.7 Manter Fornecedor (CSU017)....................................................................90
8.1.8 Cadastrar Nota de Almoxarifado (CSU018).............................................94
8.1.9 Estornar Nota de Almoxarifado (CSU019)...............................................98
8.1.10 Cadastrar Nota de Transferência (CSU020)........................................100
8.1.11 Gerar Relatório de Saldo do Estoque (CSU021) ................................104
8.2 MODELO ESTÁTICO.........................................................................................108
8.2.1 Modelo de Domínio ...................................................................................108
8.2.2 Diagrama de Classes................................................................................109
9 MODELAGEM DO MÓDULO VACINAÇÃO...........................................................110
9.1 MODELO DINÂMICO.........................................................................................110
9.1.1 Diagrama de Casos de Usos ...................................................................110
9.1.2 Manter Cliente (CSU022) ..........................................................................111
9.1.3 Manter Médico (CSU023)..........................................................................114
9.1.4 Manter Vacinador (CSU024).....................................................................117
9.1.5 Manter Tabela Preço (CSU025) ...............................................................120
9.1.6 Manter Vacina (CSU026)...........................................................................124
9.1.7 Manter Bandeira de Cartão de Crédito (CSU027).................................128
9.1.8 Manter Forma de Pagamento (CSU028).................................................131
9.1.9 Manter Esquema de Vacina (CSU029) ...................................................134
9.1.10 Abrir Caixa (CSU030)..............................................................................138
9.1.11 Encerrar Caixa (CSU031)........................................................................140
9.1.12 Cadastrar Venda (CSU032) ....................................................................143
9.1.13 Realizar Recebimento (CSU033)...........................................................147
9.1.14 Realizar Aplicação (CSU034).................................................................151
9.1.15 Lançar Saldo Cliente (CSU035).............................................................154
9.1.16 Notificar Vacina Pendente / Indicada (CSU036) .................................156
9.1.17 Notificar Venda Cancelada (CSU037)...................................................159
9.1.18 Notificação Gerencial (CSU038)............................................................161
9.2 MODELO ESTÁTICO.........................................................................................163
9.2.1 Modelo de Domínio ...................................................................................163

9.2.2 Diagrama de Classes................................................................................164
10 MODELAGEM DO MÓDULO FINANCEIRO........................................................165
10.1 MODELO DINÂMICO.......................................................................................165
10.1.1 Diagrama de Casos de Usos .................................................................165
10.1.2 Manter Caixa (CSU039)...........................................................................165
10.1.3 Manter Plano de Contas (CSU040) .......................................................169
10.1.4 Manter Favorecido (CSU041).................................................................173
10.2 MODELO ESTÁTICO.......................................................................................178
10.2.1 Modelo de Domínio .................................................................................178
10.2.2 Diagrama de Classes..............................................................................179
11 GERAL ....................................................................................................................180
11.1 TRIGGER ATUALIZAÇÃO DO SALDO DE ESTOQUE ................................180
11.2 DIAGRAMA DE MODELO DE DOMÍNIO .......................................................184
11.3 DER...................................................................................................................185
12 CONSIDERAÇÕES FINAIS ...................................................................................186
REFERÊNCIAS............................................................................................................187
APÊNDICES.................................................................................................................191
APÊNDICE A - Check List de Implantação.............................................................192
APÊNDICE B – Revisões e Estatísticas do Controle de Versões.........................193
APÊNDICE B - Diário de Bordo da Implementação (último semestre).................195

9
1 INTRODUÇÃO
Para seguir as tendências de mercado, e sobressair da concorrência acirrada,
as empresas precisam investir principalmente na melhoria dos processos, onde a
informatização é um grande aliado, diante disto, a Empresa AMI Vacinas -
Assistência Médica Infantil nos apresentou seus problemas.
Os alicerces para o desenvolvimento são a Linguagem de Programação Java
com JavaServer Faces (JSF) e os componentes PrimeFaces, com a geração de
relatórios no JasperResport e iReport, rodando em servidor web Tomcat, utilizando-
se de um banco de dados PostgreSQL.
Utilizaremos a metodologia de desenvolvimento ICONIX, por ser uma
metodologia ágil, que nos proporcionará os resultados já no começo do projeto, além
de se ater as boas práticas de programação bem como a vários padrões de projeto
de software.
1.1 PROPOSTA
O sistema Arca, é um sistema que em sua concepção, será utilizado em
clínica(s) da rede de imunização privada, mesmo assim o valor agregado para a
clínica, usuários e a sociedade são incontestáveis. O sistema fará o acompanhado
das vacinações informando as vacinas pendentes e enviando lembretes aos pais,
ajudando a manter o cartão de vacinação em dia, sendo que isto não significa que a
aplicação da vacina deverá ser realizada na clinica, porém, demonstra o interesse
da clínica no bem estar e na saúde de seus pacientes, ajudará na sociedade, de
certa forma, aumentando a cobertura na aplicação das vacinas, o que ocasionará
uma diminuição nas chances de contrair a doença, diminuindo problemas futuros e
custos para a rede de saúde, já tão saturada.
Esta iniciativa foi pensada para toda a sociedade, porém o processo de
vacinação pública, como é visto e sentido por todos, não está informatizado ao ponto
de permitir tal ganho.

10
1.2 OBJETIVO GERAL
Criação de um sistema web para a Empresa AMI (Assistência Médica Infantil)
VACINAS para atender as necessidades existentes, melhorando os processos e
apoiando na tomada de decisão.
1.3 OBJETIVOS ESPECIFICOS
● Controle Administrativo do Sistema;
● Controle de Estoque;
● Controle de vendas / vacinação;
● Controle de Financeiro;
1.4 JUSTIFICATIVA
Na área da Saúde, a vacinação contra as doenças imunopreveníveis é
fundamental na diminuição das taxas de mortalidade e na prevenção de doenças.
No entanto, há falta de informatização contribui de forma negativa no combate
epidemiológico. Estando ciente desta carência de informatização deste segmento
surgiu a ideia de seguir por este caminho. Outro ponto que contribuiu para o inicio
do projeto ARCA foi às condições em que encontramos a empresa alvo do projeto
que está com uma grande necessidade de melhoria dos seus processos.

11
2 A EMPRESA E A ATIVIDADE
A empresa AMI (Assistência Médica Infantil) nasceu em 1986 focada no ramo
de assistência médica infantil, atendimentos de pediatria geral ambulatorial e serviço
de urgência, ainda falando sobre o contexto histórico da empresa a AMI visando
comtemplar uma necessidade daquele momento pensou-se na criação de um centro
de estudos, onde seria importante para os médicos e afins que havia certa carência
de atualização técnica, a prova disto foi à evolução deste centro de estudo que
chegava a promover reciclagem de qualidade. Logo em seguida a AMI percebeu que
havia também uma necessidade de atacar mais fortes ações curativas para as
crianças, neste momento que a AMI começou a criar o segmento de “vacinação”. A
AMI também fornece outros serviços que não será o foco do nosso trabalho, tais
como: Consulta médica em diversas especialidades da pediatria, nutrição, psicologia
infantil, fonoaudiologia, terapia do desenvolvimento e exames laboratoriais
(AMINATAL, extraído da internet, 2012).
2.1 IMUNIZAÇÃO
No que diz respeito a imunizações no Brasil o PNI (Programa Nacional de
Imunizações) tem um papel de reduzir as desigualdades regionais e sociais, desta
forma contribuindo para uma ação mais efetiva para facilitar que todas as classes
sociais sejam beneficiadas e imunizadas protegendo-as das doenças assim como
afirmou o secretário de vigilância sanitária, Jarbas Barbosa “Toda criança é
vacinada: seja rica ou pobre todo brasileiro tem acesso à vacina. Pode morar no
Acre ou no Rio Grande do Sul” (PNI, extraído da internet, 2012).
Já sobre as clínicas privadas de imunizações, surgiram no Brasil na década
de 70 antes mesmo da estruturação do PNI (Programa Nacional de Imunizações), e
apesar do estado sempre esta com a hegemonia no ramo de vacinações,
conseguiam se sobressair em casos específicos, e de fato a produção biológica do
ramo privado deu-se a partir do estado (FERNANDES, 1999; RIBEIRO, 2001).

12
2.2 VACINAS E DOENÇAS
Os primeiros indícios de utilização de vacinas no combate as doenças,
surgiram depois que vários sobreviventes de um ataque de varíola não voltavam a
sofrer da doença, percebendo isto, muitos tentaram adquirir a moléstia. Na Turquia,
no Sec. XVII duas inoculadoras ficaram famosas por utilizar esta prática que ficou
sendo chamada de variolização uma delas chegou a imunizar cerca de 40 mil
pessoas.
Nas Américas a variolização chegou através dos jesuítas que inocularam
índios e Thomas Boylston que imunizou 243 pessoas durante uma epidemia em
Boston (PORTAL SÃO FRANCISCO - VACINAS, extraído da internet, 2012).
Atualmente a vacinação no Brasil é regida pelo PNI (Programa Nacional de
Imunizações) e é uma das técnicas mais eficaz na erradicação de doenças
(PORTAL DA SAÚDE - VACINAÇÃO, extraído da internet, 2012).
As ações de vacinação são coordenadas pelo Programa Nacional de
Imunizações (PNI) da Secretaria de Vigilância em Saúde do
Ministério da Saúde que tem o objetivo de erradicar, eliminar e
controlar as doenças imunopreveníveis no território brasileiro.
A vacinação é a maneira mais eficaz de evitar diversas doenças
imunopreveníveis, como varíola (erradicada), poliomielite (paralisia
infantil), sarampo, tuberculose, rubéola, gripe, hepatite B, febre
amarela, entre outras.

13
2.3 CALENDÁRIO
O calendário de vacinação também é regido pelo PNI (Programa Nacional de
Imunizações) e Ministério da Saúde e é extremamente importante para destacar
quais as vacinas de maior prioridade devem ser tomadas para cada faixa etária da
população (PORTAL DA SAÚDE - VACINAÇÃO, extraído da internet, 2012).
O Calendário de vacinação brasileiro é aquele definido pelo
Programa Nacional de Imunizações do Ministério da Saúde (PNI/MS)
e corresponde ao conjunto de vacinas consideradas de interesse
prioritário à saúde pública do país. Atualmente é constituído por 12
produtos recomendados à população, desde o nascimento até a
terceira idade e distribuídos gratuitamente nos postos de vacinação
da rede pública. Confira abaixo os três calendários de vacinação:
Calendário de Vacinação Básico da Criança:
Quadro 1: Calendário da Criança
Fonte: (PORTAL DA SAÚDE, extraído da Internet, 2012)

14
Calendário de Vacinação do Adolescente:
Quadro 2: Calendário do Adolescente
Calendário de Vacinação do Adulto e do Idoso:
Quadro 3: Calendário do Adulto e do Idoso

15
2.3.1 Vacinação do Viajante
A vacinação do viajante é um ponto preocupante que desperta atenção dos
órgãos de vigilância sanitária, pois exige um maior cuidado nas fronteiras,
aeroportos e portos a fim de prevenir a população no âmbito coletivo (PORTAL DA
SAÚDE-VACINAÇÃO DO VIAJANTE, extraído da Internet, 2012).
Essa discussão aborda a experiência das atividades de vigilância
sanitária no âmbito de portos, aeroportos e fronteiras, bem como a
experiência em epidemiologia e controle de doenças, cujo princípio
básico é o conhecimento da saúde coletiva. Para o estabelecimento
de uma política dirigida à saúde dos viajantes deverá ser levado em
consideração o conhecimento epidemiológico e ter como suporte ou
instrumento essencial a informação, com base na orientação e
recomendação voltada para a promoção, prevenção e proteção da
saúde dos viajantes.

16
3 METODOLOGIA
3.1 ORIENTAÇÃO A OBJETOS
A Orientação a Objetos ou simplesmente OO, é um paradigma de
programação, que apesar de ter surgido em 1960, vem crescendo nas últimas
décadas. A Orientação a Objetos tenta trazer para dentro da programação,
aspectos do mundo real. “O mundo real é formado de coisas. Como exemplo de
coisas, pode-se citar um cliente, uma loja, uma venda, um pedido de compra, um
fornecedor este livro etc. Na terminologia da orientação a objetos, estas coisas do
mundo real são denominadas objetos.” (BEZERRA, 2003, p.7).
“OO é um termo geral que inclui qualquer estilo de desenvolvimento que seja
baseado no conceito de „objeto‟ - uma entidade que exibe características e
comportamentos. Você pode aplicar uma estratégia orientada a objetos na
programação, assim como na análise e no projeto”. (SINTES, 2002, p.4).
Sintes (2002, p.14) reforça que assim como outros paradigmas que tentam
corrigir problemas e acentuar vantagens a POO fundamenta a programação
procedural e modular:
A programação modular estrutura um programa em vários módulos.
Do mesmo modo, a POO divide um programa em vários objetos
interativos. Assim como os módulos ocultam representações de
dados atrás de procedimentos, os objetos emcapsulam seu estado
por trás de suas interfaces. A POO empresta este conceito de
encapsulamento diretamente da programação modular. O
encapsulamento difere muito da programação procedural. A
programação procedural não encapsula dados. Em vez disso, os
dados são abertos para todos os procedimentos acessarem. Ao
contrario da programação procedural, a programação orientada a
objetos acopla fortemente dados e comportamentos aos objeto.
Em função disso, a OO é uma evolução dos paradigmas de programação,
onde neste processo evolutivo, tenta associar a percepção do mundo dentro da
programação, em uma tentativa de facilitar a visão de software como produto.
“De certa forma, um programa OO se torna uma simulação viva do problema
que você está tentando resolver.” (SINTES, 2002, p.6).

17
3.2 UML
Com a evolução tecnológica e os sistemas tornando-se mais complexos e a
tarefa de desenvolvimento de software passou a necessitar de mecanismos que
ajudariam aos analistas e desenvolvedores neste processo. A UML surgiu para
facilitar este processo produzindo artefatos que possibilitam o entendimento do
sistema proposto e agilidade no processo de desenvolvimento, assim como define
Bezerra (2003, p.13):
A construção da UML teve muitos contribuintes, mas os principais
atores no processo foram Grady Booch, James Rumbaugh e Ivar
Jacobson. Estes três pesquisadores são frequentemente chamados
de “os três amigos”. No processo definido da UML, procurou-se
aproveitar o melhor das características das notações preexistentes,
principalmente das técnicas propostas anteriormente pelos três
amigos (essas técnicas eram conhecidas pelos nomes Booch
Method, OMT e OOSE). A notação definida para UML é uma união
de diversas notações preexistentes, com alguns elementos
removidos e outros elementos adicionados com o objetivo de torna-la
mais expressiva.
3.3 ICONIX
O ICONIX é um processo de desenvolvimento de software desenvolvido pela
a ICONIX Software Engineering, é uma metodologia ágil e prática, que por sua vez
elimina a complexidade do RUP (Rational Unified Processes) e contempla os
benefícios da simplicidade do XP (Extreme Programming), apresentando os
resultados logo nas primeiras fases. (ROSENBERG e SCOTT, 1999).
Maia (2005) afirma que ICONIX é uma metodologia poderosa e tem um
conjunto de componentes de análise e representação forte e eficaz, podendo ser
dividido em dois grupos: modelo estático e dinâmico, ambos podem ser
desenvolvimentos em paralelo e de forma recursiva:

18
Figura 1: Processo Iconix
Fonte: Rosenberg; Stephens; Cope (2005, p.?)
Na Figura 1 mostra que o Iconix esta dividido em dois modelos: O modelo
Dinâmico e o modelo Estático, veja que todo o processo do Iconix começa a partir
do protótipo passa pelo modelo dinâmico e estático produzindo os testes e as
versões do sistema.
Ainda sobre este contexto Rosenberg e Scott (1999), destacam que o ICONIX
esta dividido da seguinte forma:
3.3.1 Fase de Análise de Requisitos
Momento em que se devem levantar as necessidades do minimundo em
questão descobrindo as relações de associações e generalizações existentes
chegando efetivamente à construção do modelo de domínio. Também, nesse
momento podemos usar, se possível, o artificio de prototipação que auxilia o
processo de entendimento do cliente com o nosso sistema, Em seguida vem à etapa
em que se identificam os casos de usos, ou seja, são apresentados os atores que

19
estarão envolvidos com o nosso sistema, sobre o nosso ponto de vista esta etapa é
fundamental para desenvolvimento do projeto, nesse momento é construído o
modelo de caso de uso. Os casos de usos podem ser lançados em um diagrama de
pacote para garantir a organização dos mesmos.
3.3.2 Fase de Analise e Projeto Preliminar
Neste momento assim como cita Rosenberg e Scott (1999), iremos lançar
mão de documentar os casos de uso, ou seja, escrever os fluxos principais
alternativos, exceções que serão contidas nos casos de usos. Em seguida é
realizada a análise de robustez, onde são identificados objetos e atualizar o
diagrama de classes de domínio terminando com a atualização do diagrama de
classe.
3.3.3 Fase de Projeto
Nesta fase devemos especificar o comportamento do sistema através do
diagrama de sequência, que servirá para nosso alinhamento das mensagens entre
os objetos e a relação da sequência do processo. Neste momento devemos
terminar o nosso modelo estático, finalizando o diagrama de classe. Por fim desta
fase será importante que seja avaliado o tempo do projeto esta de acordo com o
previsto.
3.3.4 Fase de Implementação
Nesta fase é a hora de programar nosso código fonte e promover testes e
verificar os retornos e validações do usuário para cada unidade desenvolvida.

20
Pensando na análise ao projeto foi que chegamos à conclusão que seria
muito importante que o nosso sistema fosse totalmente orientado a objetos, pois
dentre os elementos da UML que será muito útil em ambas às fases do nosso
projeto será o diagrama de classe como afirma Bezerra (2003, p.149): “No
desenvolvimento de sistemas orientados a objetos, a mesma representação é
utilizada durante a análise e o projeto: o modelo de classe é utilizado para
representar a estrutura das classes do sistema em ambas as fases.”

21
4 ARQUITETURA
Arquitetura é um termo que é utilizado em várias áreas de conhecimento e
vem sendo utilizada na área de Software há algum tempo. Fowler (2006, p.23) diz
que “„Arquitetura‟ é um termo que muitas pessoas, com pouca concordância entre si,
tentam definir. Existem dois elementos comuns: um é a decomposição de alto nível
de um sistema em suas partes; o outro são decisões difíceis de alterar”.
Arquitetura é subjetiva, é a compreensão do projeto de sistema compartilhada
pelos desenvolvedores experientes de sistemas, frequentemente é apresentada na
forma de componentes importantes do sistema e de como eles interagem. A
subjetividade existe porque se você descobrir que algo não é tão difícil de alterar e
não causará grandes impactos, como inicialmente tinha sido analisado, este deixa
de ser arquitetural. No final, tudo que é importante é Arquitetural (FOWLER apud
JOHNSON, 2006).
“A Arquitetura do sistema afeta o desempenho, a robustez e a facilidade de
distribuição e de manutenção de um sistema. A estrutura e o estilo especifico
escolhidos para uma aplicação podem, portanto, depender dos requisitos não
funcionais do sistema.” (SOMMERVILLE, 2003, p.183).
Sendo assim, devemos definir a nossa arquitetura, não se esquecendo de
atender os requisitos que dependem desta decisão, e levando em consideração
alguns critérios que estabelecemos: o custo, o nosso conhecimento sobre a
tecnologia, curva de aprendizado, popularidade, mercado e evolução.
Após preponderar os critérios, decidimos que nossa arquitetura partiria de um
ambiente web, com Java Servlet e JSF, em um servidor Tomcat com banco de
dados PostgreSQL, gerando relatórios com Jasper Report, além de outros recursos
incorporados para aumentar a produtividade, como o Primefaces.
4.1 LINGUAGEM DE PROGRAMAÇÃO E FRAMEWORK
A linguagem de programação, no desenvolvimento de sistema, é um dos
fatores arquitetônicos de maior impacto, por está relacionado a desempenho e

22
produtividade. No nosso caso, optamos pela linguagem JAVA em um ambiente
web, de acordo com critérios previamente estabelecidos.
A linguagem Java surgiu em 1991, com um pequeno grupo de engenheiros da
SUN chamado de “Team Green”, acreditando em uma nova face da computação,
tinham como objetivo possibilitar a convergência entre computadores, equipamentos
eletrônicos e eletrodomésticos. Liderados por James Gosling, a equipe trabalhou o
tempo todo e criou a linguagem que iria revolucionar o nosso mundo. (ORACLE,
extraído da internet, 2012).
O que chamava atenção nessa linguagem era o fato de que ela podia
ser portável para outros sistemas operacionais. Além, sua fama
cresceu rapidamente porque a Web como conhecemos hoje estava
em ascensão, e Java possibilitava fazer diversas coisas, como
animações, que até então não eram possíveis em páginas existentes
na World Wide Web. (GONÇALVES, 2007, p.7).
“A linguagem Java nos dias de hoje é utilizada por grandes bancos, pois
fornece extrema segurança. Também é utilizada por grandes empresas que desejam
trafegar uma grande quantidade de dados e necessita de estabilidade e
portabilidade entre outras empresas”. (GONÇALVES, 2007, p.7).
Após a escolha da linguagem de programação, vem o dilema de utilizar ou
não um framework, Evans (2008, p.?) diz que você pode pensar que o seu projeto
não necessita de um framework, mais na verdade você vai acabar construindo algo
que se pareça com um:
Na maioria das vezes ela começa combinando código similar de
áreas diferentes do projeto para simplificar a manutenção. Antes de
você saber isso, você terá uma camada de abstração de base de
dados, classes base, classes abstracts, e, eventualmente, você
próprio terá um framework. Logo, na realidade, isso realmente se
reduz a apenas essas duas escolhas. Quando você observa por essa
perspectiva e considera que seu projeto é não-trivial, o “Porquê” se
torna evidente. Você usa um framework já existente para economizar
o seu tempo e evita ter de, você mesmo, escrever um.
Seguindo a orientação de Evans, iremos utilizar alguns framework‟s para
agilizar o processo de construção do sistema. Entre eles, temos o JavaServer Faces
(JSF) que é o framework java para a web.

23
4.2 TECNOLOGIAS UTILIZADAS
4.2.1 JSF
Geary e Horstman (2007, p.3), baseado nos dados dos anúncios de
empregos da internet, inferem que existem duas técnicas para desenvolvimento
web: o estilo de “desenvolvimento rápido”, que nos lembra da Microsoft com o seu
ASP.NET; e o outro séria a “programação profunda”, muitas linhas de código fonte
como acontece com o Java EE (Java Enterprice Edition):
As equipes de desenvolvedores ficam diante de uma escolha difícil.
O Java EE é uma plataforma atraente altamente escalonável,
apresenta portabilidade para várias plataformas e é suportado por
muitos fabricantes. Por outro lado, o ASP.NET facilita a criação de
interfaces de usuário atraentes sem exigir um tedioso trabalho de
programação. É claro que os programadores desejam as duas
coisas: um backend de alto desempenho e a facilidade para
programar interfaces para de usuário. A vantagem prometida pelo
JSF (JavaServer Faces) é trazer o desenvolvimento rápido de
interfaces de usuário para o Java server-side.
O JavaServer Faces (JSF) é uma especificação de referência (JSR) para um
framework baseado em componentes (component based) para desenvolvimento
web em java. A iniciativa partiu do Java Community Process (JCP), que é a
entidade responsável pela evolução da linguagem de acordo com o interesse do
mercado e não apenas da criadora da linguagem.
O JSF é um framework de alto nível que integra as facilidades de um
desenvolvimento ágil e descomplicado, tendo em sua base uma linguagem de
montagem baseado em servlet e JSP.
“Na prática, a utilização de JavaServer Faces torna fácil o desenvolvimento
através de componentes de interface de usuário (GUI), possibilitando a conexão
desses componentes a objetos de negócios de forma simplificada.” (GONÇALVES,
2008, p.11).
O Framework, apesar de ser considerado novo, está em constante evolução
desde a sua versão 1.0 a atual versão 2.17, tendo uma grande expectativa pela
comunidade no lançamento da versão 2.2, por trazer recursos bem aguardados,
como o HTML5.

24
Versão JSR Ano Nota
1.0 127 2004 Não alcançou o sucesso esperado por problemas de
desempenho.
1.1 127 2004 Corrigiu os erros da versão anterior.
1.2 252 2006 Melhor compatibilidade de JSP 2.1 correção de bugs.
2.0 314 2009 A maior mudança foi na apresentação (View), com a
substituição das páginas JSP por XHTML.
2.2 344 - -
Quadro 4: Notas Importantes das Verões do JSF
Por se tratar de uma especificação, para começar a utilizar é necessária
alguma implementação, as mais populares são Mojarra, mantida pela Oracle, e o
Apache MyFaces, optamos pela implementação Mojarra na versão 2.1.7.
[…] parece ficar evidente que quando se especifica algo, alguém
deve desenvolver (implementar). Como uma especificação pode ser
implementada por diversas pessoas ou empresas, é natural que
existam muitos componentes disponibilizados na internet e aí paira a
dúvida: São todos componentes JSF? é claro que não! Mas, esses
componentes devem/podem ser executados em uma implementação
JSF. (COIMBRA, 2010, p.143).
Outro aspecto importante do JSF é o seu ciclo de vida, que foi muito bem
pensado e desenhado, em alguns casos, é possível pular algumas etapas, o mais
indicado é permitir fluir naturalmente. (LUCKOW; MELO, 2010).
Figura 2: Ciclo de Vida das Requisições JavaServer Faces
Fonte: Luckow; Melo (2010, p.101)

25
4.2.2 Primefaces
Ao trabalhar com JSF, temos uma imensidade de pacotes de componentes,
para integrar ao projeto e aumentar mais as nossas opções. Dentre todos, os mais
populares são:
 PrimeFaces (http://www.primefaces.org/);
 RichFaces, da JBoss (http://www.jboss.org/richfaces);
 ICEFaces, da ICESoft (http://www.icefaces.org);
“O PrimeFaces é uma biblioteca de componentes para JavaServer Faces com
mais de 90 componentes. É certamente uma das mais completas e foi uma das
primeiras a estar totalmente convertida para o JSF2.0.” (LUCKOW; MELO, 2010,
p.373).
Seguindo os critérios previamente definidos e por ter uma conjunto de
componentes vasto, com suporte constante e rápido da comunidade, iremos
trabalhar com o PrimeFaces 3.2.
4.2.3 Servlets
Servlets são classes java, desenvolvidas de acordo com uma estrutura bem
definida
O JSF é um framework que abstrai a complexidade do desenvolvimento
Servlets e JSP.Na sua versão 2.0, a rederização foi otimizada com a substituição
dos JSP por XHTML. Coimbra(2010, p.58) explica que:
Servlets, antes de tudo, são classes java. Mais especificamente
Servlets são classes que são executadas em um Servlet Container
[...] que é requisitado por um cliente, recebendo informações
enviadas por este para que possa realizar algum processo e, ao
término deste processo, ele retorna uma resposta ao cliente.
Além disso, um servidor que implementa Servlet Container, também é
conhecido como Servidor de Aplicações Java.

26
Atendendo a premissa de um Servlet Container, iremos utilizar o Tomcat 7,
que tem a implementação 3.0, e por ser um dos mais leves e de fácil utilização e
integração com as ferramentas de desenvolvimento e produção.
“Com a necessidade de desenvolver aplicações para a web (não apenas
sites), a Sun especificou uma API especifica para o desenvolvimento destas
aplicações, que é conhecida como JSP e Servlet.” (COIMBRA, 2010, p.58).
4.2.4 EJB3 Persistence e JPA
Dentro do mundo Java existe várias maneiras de persistência de objetos,
desde as mais primitivas, usando JDBC (Java Database Connectivity), até as mais
modernas, usando algum ORM (Object Relacional Mapping) como o Hibernate.
(LUCKOW; MELO, 2010).
Em nosso caso, iremos utilizar JPA (Java Persistente API), que surgiu para
padronizar o mapeamento objeto relacional em java, em conjunto com uma
implementação EJB3 Persistence - JSR 220. (GONÇALVES, 2007). É importante
saber que o EJB Persistence faz parte da EJB, mais isso não impede seu uso em
outras tecnologias como servlets:
O EJB (Enterprise Java Beans) é um dos principais componentes da
plataforma JavaEE, assim seu conceito é diferente do conceito de
JavaBeans. Podemos traduzir a filosofia por trás do EJB como uma
arquitetura de componentes multiplataforma criada para o
desenvolvedor de aplicações Java que sejam multicamadas,
distribuídas, escaláveis e orientadas a objetos. O objetivo da
arquitetura EJB é facilitar o trabalho do desenvolvedor para que ele
não tenha que se preocupar com aspectos de infraestrutura.
(LUCKOW; MELO, 2010, p.123).
4.2.5 Jasper Report e iReport
A geração de relatórios é um ponto crucial em qualquer sistema de
informação, no nosso caso, iremos utilizar a biblioteca JasperReports em conjunto
com o iReport 4.5 para geração de relatórios nos mais diversos formatos.

27
“O JasperReports é uma biblioteca Java responsável pela execução dos
relatórios. É esse biblioteca que está por traz do iReport, pois o iReport apenas
monta o relatório, sendo que a execução é totalmente feita pelo JasperReports.”
(LUCKOW; MELO, 2010, p.394).
O iReport, é uma aplicação Java, que nos proporciona um ambiente para
criação visual dos relatórios, resultando nos arquivos JRXML que são a base para o
JasperReport gerar os relatórios. Segue arquitetura de execução em alto nível:
Figura 3: Fluxo de Execução de um Relatório
4.2.6 Tomcat
O Tomcat é um container servlet da arquitetura java J2EE, que é destinado a
utilização de aplicações web em java:
Para que o Java funcione em aplicações escritas para web, você
precisará de um Container Servlet. Um container Servlet pode ser um
servidor, servindo todos os tipos de aplicativos Web, ou a integração

28
de um, trabalhando exclusivamente para servir páginas escritas em
Java. Atualmente no mercado existem diversos servidores e
containeres, sendo os mais famosos: Apache Tomcat, Red Hat
JBoss, IBM WebSphere e etc. (GONÇALVES, 2007, p.7).
O Tomcat teve suas origens junto com a tecnologia servlet. A Sun
Microsystem foi quem criou o primeiro container Servlet para demonstrar a
tecnologia e chamou-o de Java Web Server, em paralelo a Apache Software
Foundation (ASF) criou o JServ, um engine Servlet que integrava no Servidor Web
apache. (GONÇALVES, 2007).
“Em 1999, a Sun Microsystems doou o código do Java Web Server para o
ASF, e os dois projetos se fundiram para criar o Tomcat.” (GONÇALVES, 2007,
p.23). Este foi o começo do tão conhecido servidor web java, que teve a influência
direta do código original da Sun. Contudo, Gonçalves(2007, p.24) ressalta que:
Tecnicamente, o Tomcat é um Container Web. Mas o Tomcat tem a
capacidade de atuar também como servidor Web/HTTP assim como
pode funcionar integrado a um servidor web dedicado como o
Apache ou o Microsoft IIS. O Tomcat, porém, não implementa até.o
momento um container EJB.
No nosso trabalho iremos utilizar o Tomcat 7, vale ressaltar que o mesmo
não é uma implementação completa da plataforma J2EE.
4.3 SISTEMA GERENCIADOR DE BANCO DE DADOS
O SGBD é a parte mais importante de qualquer sistema de informação, sendo
responsável por armazenar e garantir a segurança da informação. Milani (2008,
p.323) define:
SGBD, sigla de Sistema Gerenciador de Banco de Dados (do inglês,
DBMS - DataBase Management System), é um sistema responsável
pela segurança e proteção dos dados de um banco de dados. É a
centralização do conjunto das implementações de segurança que
antes era desenvolvido e mantido em cada aplicação que fosse
acessar os recursos de um arquivo (ou banco).
Para Milani (2008, p.323), o maior diferencial de um SGBD é tornar os dados
independentes da aplicação e complementa dizendo que “Foram desenvolvidos a
partir de demanda existente em separar da camada de negócio as implementações

29
de segurança e outras referentes aos bancos de dados, agora realizada em uma
camada própria”.
4.3.1 PostgreSQL
O PostgreSQL é um Sistema Gerenciador de Banco de Dados (SGBD)
Relacional, que dentro dos SGBD com licença aberta, é o mais robusto, confiável e
completo em suas funcionalidades.
O PostgreSQL surgiu em 1986, na Universidade de Berkeley na Califórnia
(EUA), em um projeto chamado POSTGRES, com a supervisão do professor
Michael Stonebraker, tendo como objetivo criar o modelo e as regras de um novo
sistema de armazenamento de dados. A primeira demonstração foi 1987, onde foi
apresentada em diversos meios. No ano de 1989, surgi a primeira versão estável,
foi lançada com sucessivos release de correções. Futuramente foi adquirida pela
Informix e posteriormente pela IBM. (MILANI, 2008).
O PostgreSQL está dentro dos padrões ISO SQL:1999 e SQL:92, já dando
suporte a muitas das funcionalidades da SQL:2003 e tem suporte as principais
funções de um SGBD como Join, Triggres, views e stored procedures.
Escolhermos o PostgreSQL em sua versão 9.1, como nosso SGBD, por
atender aos requisitos do sistema e ser o mais estável e confiável, segundo Milani
(2008).
4.4 PADRÕES ARQUITETURAIS E DE PROJETO
“Projetar software orientado a objetos é difícil, mas projetar software
reutilizável orientado a objetos é ainda mais complicado”. [...] O seu projeto deve ser
específico para o problema a resolver, mas também genérico o suficiente para
atender problemas e requisitos futuros.” (GAMMA et al., 2000, p.17).
No desenvolvimento de sistemas, aparecem os mais diversos dos problemas,
no entanto, existem certos padrões que já foram testados e retestados por

30
arquitetos, projetistas e cientistas da computação, e pelo resultado apresentado, se
sobrepõem as demais formas de implementação.
“Uma coisa que os melhores projetistas sabem que não devem fazer
é resolver cada problema a partir de princípios elementares ou do
zero. Em vez disso, eles reutilizam soluções que funcionaram no
passado. Quando encontram uma boa solução, eles a utilizam
repetidamente. Consequentemente, você encontrará padrões, de
classes e de comunicação de objetos, que reaparecem
frequentemente em muitos sistemas orientados a objetos.” (GAMMA
et al., 2000, p.17).
“Cada padrão descreve um problema no nosso ambiente e o cerne da sua
solução, de tal forma que você possa usar essa solução mais de um milhão de
vezes, sem nunca fazê-lo da mesma maneira.” (GAMMA, 2000, p.19 et al. apud
ALEXANDER, 1977, p.?).
Além do apresentado, utilizar padrões de projetos, é uma boa prática de
programação, sendo assim, apresentamos a seguir alguns padrões que estarão
presentes no sistema:
4.4.1 MVC
O MVC (Model-view-controller) é um padrão de arquitetura de software que
divide a responsabilidade em camadas, para diminuir a complexidade e separar as
responsabilidades. (LAMIM, 2009). “[...] MVC é uma estratégia testada e que é
popular no setor de software. Se você acabar realizando o trabalho da interface com
o usuário, especialmente em relação à web e ao J2EE da Sun, encontrará o MVC.”
(SINTES, 2002, p.294).
O Model é a representação do domínio do sistema, que gerencia o
comportamento básico e o estado do sistema.
Já a camada View, é a parte visual do sistema, acessível diretamente ao
usuário. É a forma de acesso aos recursos do sistema, que envia as solicitações
para a camada controller, onde é processada e devolvida a view. (LAMIM, 2009).
“O Controlador é a camada que interpreta a entrada do usuário. Em resposta
à entrada do usuário, o controlador pode comandar o modelo ou o modo de
visualização para que mude ou execute alguma ação.” (SINTES, 2002, p.294).

31
Figura 4: Padrão MVC JavaServer Faces
Fonte: http://communities.softwareag.com/ecosystem/communities/public/Developer/
webmethods/tutorials/CAF/CAFandJSF/JSF_Overview.html
Já para Luckow e Melo (2010), há uma integração do controller com a view na
apresentação:
Figura 5: Padrão MVC JavaServer Faces II

32
4.4.2 Façade
Algumas vezes, a complexidade envolvendo o relacionamento de múltiplas
classes ou subsistemas interfere no entendimento do código, bem como, faz com
que o cliente (consumidor do serviço), conheça certos aspectos que não deveriam
ser notório a ação. Para resolver está problemática, temos o padrão Façade:
Estruturar um sistema em subsistemas ajuda a reduzir a
complexidade. Um objetivo comum de todos os projetos é minimizar
a comunicação e a dependência entre subsistemas. Uma maneira
de atingir este objetivo é introduzir um objeto façade (fachada), o
qual fornece uma interface única e simplificada para os recursos e
facilidades mais gerais do sistema. (GAMMA et al., 2000, p.179).
Figura 6: Modelo convencional e com o Padrão Façade
Fonte: GAMMA et. al.(2000, p.179)
4.4.3 DAO
O Padrão DAO (Data Access Object) é um padrão usado para persistência de
dados que foi introduzido na plataforma JEE para simplificar e desacoplar a
aplicação da API de persistência, e é responsável por abstrair e encapsular o acesso
a fonte de dados. O DAO gerencia a conexão com o fonte de dados, obtendo e
armazenando os dados. (ORACLE, extraído da internet, 2012).
Para minimizar o acoplamento e facilitar a implementação, é relevante que o
DAO seja especificado por uma interface, ao invés de uma classe concreta. Outra

33
opção, é utilizar o padrão Factory, criando uma Factory de DAO‟s, o que ajudará na
manutenção, onde todas as instâncias de DAO‟s será gerida pela Factory.
4.4.4 Abstract Factory
“Fornece uma interface para criação de fámilias de objetos relacionados ou
dependentes sem especificar suas classes concretas”. (GAMMA et al., 2000, p.95).
A maior vantagem em utilizar o padrão Abstract Factory é o controle sobre a
criação das classes de objetos da aplicação, encapsulando a responsabilidade de
criação, exclusivamente, para a fábrica, o que facilita na manutenção, quando for
necessário mudar a fábrica concreta, sabendo que a mesma só é instanciado pela
fábrica abstrata, bastando atualizá-la.
O Padrão Abstract Factory, pode ser utilizado com o padrão Singletons, nas
situações onde for necessária apenas uma instância da fábrica no projeto. (GAMMA
et al., 2000). Geralmente está estratégia é adotada em fábricas de conexão ao
Banco de dados.
4.5 PADRONIZAÇÃO DE CODIFICAÇÃO E NOMENCLATURA
Adotando as boas práticas de desenvolvimento, que de certa forma, garantirá
a maturidade do projeto ao longo do tempo, com incremento na equipe e sem
prejuízos nos códigos fontes e a na estrutura de banco de dados, é necessário
definir padrões de codificação e nomenclatura.
De forma geral, iremos utilizar bastante notação prefixal, com a finalidade de
manter a uniformidade no código e na estrutura do banco de dados.

34
4.5.1 Banco de Dados
“É recomendável que o usuário de um banco de dados utilize, sempre que
possível, um padrão de nomenclatura [...]. A vantagem de se manter um padrão é a
sua manutenção futura, bem como melhor entendimento dos campos para as
pessoas que não tiveram contato com o seu banco de dados anteriormente, e até
mesmo para fins de documentação.” (MILANI, 2008, p.341).
Seguindo o exposto, definimos que:
 Só serão utilizados tipos primitivos e comuns de vários SGBD para garantir
maior compatibilidade;
 As tabelas, campos, funções ou qualquer outro artefato do SGBD, será
sempre escrito em caixa de texto baixa (letras minúsculas);
 Cada tabela deve conter o prefixo (três caracteres) identificador do conjunto
de dados ao qual a tabela pertence. Ex.: A tabela “usuario” faz parte das
funções administrativas, devendo conter o prefixo “adm”, resultando em
“admusuario”;
 Abraçando os padrões internacionais, as chaves primárias devem iniciar com
o prefixo “id” seguindo do nome da tabela. Ex.: A tabela “usuario”, a chave
primária seria “idusuario”;
 Campos de controle boolean, serão do tipo integer e terão o prefixo “flg”;
 As triggers, functions, stored procedures, índices iniciaram respectivamente
com os prefixos: “tr”, “fn”, “sp”, “ix”;
 As chaves estrangeiras terão o mesmo nome que tem na tabela estrangeira;
4.5.2 Linguagem de Programação
No desenvolvimento, iremos seguir as convenções de codificação defina para
a linguagem java, onde será complementado:

35
 Será utilizado “tab” como marcador de endentação;
 Os métodos que realização ações, na camada de controle, acessíveis pela
camada de visão, serão iniciadas com a preposição “do”;
 A nomenclatura da classe deve conter o nome da camada a qual ela
pertence. Ex.: o controlador de usuário, será definido como
“UsuarioController”;
 Alguns controladores que tem as finalidade de Cadastrar, Gerar Relatório ou
Executar alguma ação, terão as respectivas preposições Cad, Rel, Exec.
 A regra de negócio será programada na camada DAO, no entanto, se muito
complexa, deverá ser implementado um Façade ou um Bussiness Object;

36
5 ANÁLISE DE REQUISITOS
5.1 REQUISITOS FUNCIONAIS
Segundo Sommerville (2003, p.83), “Requisitos funcionais são declarações de
funções que o sistema deve fornecer, como o sistema deve reagir a entradas
especificas e como deve se comportar em determinadas situações”.
A seguir, relacionamos os requisitos funcionais, e para facilitar a localização e
identificação, foi separado na estrutura modular do sistema:
5.1.1 Módulo Administrativo
RF001: Autenticação e Autorização
O sistema deverá garantir que só tenha acesso aos recursos do sistema, os
usuários devidamente autenticados e autorizados;
RF002: Cadastros Básicos Administrativos
O sistema deverá permitir ao administrador do sistema, cadastrar e administrar
empresas, módulos, menus, níveis de acesso;
RF003: Cadastro de Usuários
O sistema deverá permitir ao administrador do sistema, cadastrar e administrar os
usuários do sistema;
RF004: Alterar Senha
O sistema deverá permitir ao usuário autenticado, alterar sua senha;

37
5.1.2 Módulo Estoque
RF005: Cadastros Básicos de Estoque
O sistema deverá permitir ao usuário do sistema, cadastrar e administrar materiais,
grupo de materiais, fabricantes, fornecedores, almoxarifado, fornecedores;
RF006: Lote e Validade
O sistema deverá permitir ao usuário do sistema, cadastrar e administrar os Lotes e
validades dos materiais que tenham essas características;
RF007: Movimentação de Estoque
O sistema deverá permitir ao usuário do sistema, cadastrar movimentações de
entrada e saída em estoque de vários tipos (Entrada, Saída, Estorno, Devolução);
RF008: Relatórios
O sistema deverá permitir ao usuário do sistema, gerar relatórios de saldo em
estoque, relatório de extrato em estoque, relatório de conferência, relatório de
últimos custos, relatório de previsão de compra;
5.1.3 Módulo Vacinação
RF009: Cadastros Básicos de Vacinação
O sistema deverá permitir ao usuário do sistema, cadastrar e administrar clientes,
médicos, local de aplicação, forma de pagamento e tabela de preços;
RF010: Venda de Produtos
O sistema deverá permitir ao usuário do sistema, realizar venda de produtos com as
respectivas condições de pagamento, podendo opcionalmente realizar a [RF011];
RF011: Aplicação de Vacina

38
O sistema deverá permitir ao usuário do sistema, registrar a aplicação de vacina,
gerando as movimentações de estoque que forem necessárias;
RF012 Atualizar Cartão de Vacinação
O sistema deverá permitir ao usuário do sistema, atualizar o cartão de vacinação
dos clientes, podendo informando vacinas que não foram aplicadas na clínica;
RF013: Relatórios
O sistema deverá permitir ao usuário do sistema, gerar relatórios da movimentação
financeiro do dia e mensal, aplicações de vacinas;
5.1.4 Módulo Financeiro
RF014: Cadastros Básicos Financeiros
O sistema deverá permitir ao usuário do sistema, cadastrar e administrar plano de
contas, caixas e favorecidos;
RF015: Contas a Pagar e Receber
O sistema deverá permitir ao usuário do sistema, registrar contas a pagar e a
receber, disponibilizando consultas e apresentando as próximas pendencias;
RF016: Registro de Movimentação de Caixa
O sistema deverá permitir ao usuário do sistema, registrar movimentações em
múltiplos caixas, podendo ser detalhada por plano de contas e/ou favorecido, com
controle de saldo e fluxo diário, além de possibilitar o estorno de movimentação;
RF017: Transferência entre Caixas
O sistema deverá permitir ao usuário do sistema, registrar movimentação de
transferência entre caixas, atualizando os saldos;
RF018: Relatórios

39
O sistema deverá permitir ao usuário do sistema, gerar relatórios de contas pagas e
a pagar, relatório de contas recebidas e a receber, movimento diário, saldo de caixa,
fluxo de caixa, resumo por conta;
5.2 REQUISITOS NÃO FUNCIONAIS
“Requisitos não funcionais são restrições sobre os serviços ou as funções
oferecidas pelo sistema. Entre eles destacam-se restrições de tempo, restrições
sobre o processo de desenvolvimento, padrões, entre outros.” (SOMMERVILLE,
2003, p.83).
RNF001: Usabilidade
A navegação deve ser simplificada de modo a tornar o sistema produtivo e fácil de
usar. Deve utilizar a nomenclatura própria da área de domínio do cliente.
RNF002: Acessibilidade
O sistema deve permitir acesso de qualquer local que disponha de um computador
com acesso a internet.
RNF003: Confiabilidade
O sistema deverá realizar backups automatizados em locais especificados pelos
usuários, e na ocorrência de erros nestes backups, enviar e-mail informando o
ocorrido.
RNF004: Hardware e Software
Especificação mínima para máquina Servidora:
 Processador duplo núcleo 1.2 GHz;
 Memória RAM de 512 MB;
 Disco Rígido de 10 GB;
 Sistema Operacional Linux;
 Requisitos de software:
o Servidor Web Tomcat 7;

40
o Banco de banco de dados PostgreSQL 9.1;
Especificação mínima para máquina Cliente:
 Qualquer máquina com acesso a internet que possua um navegador
(browser) Internet Explorer ou Firefox Mozilla, ter o software Acrobat Read
para visualização dos relatórios, e opcionalmente, uma impressor a jato de
tinta.

41
6 REGRAS DE NEGÓCIO
RN001: Somente usuários autenticados podem acessar os recursos restritos de
acordo com as permissões de acesso;
RN002: O sistema não permite que um usuário seja cadastrado mais de uma vez;
RN003: O sistema não permite que o usuário acesse uma página que não tenha
permissão;
RN004: O usuário só terá acesso aos dados das empresas previamente liberadas;
RN005: A data Fim não pode ser menor que a data Início;
RN006: A data alteração não pode ser menor que a data anterior da alteração;
RN007: Material deve está vinculado ao almoxarifado;
RN008: A data de abertura não pode ser maior que a data atual, também não pode
ser menor mais de 10 dias da data atual e só deve permitir um caixa aberto por dia;
RN009: Caixa não pode ser encerrado no mesmo dia.
RN010: O almoxarifado de origem não pode ser igual ao almoxarifado de destino.
RN011: A idade de no esquema de vacinação não pode ser maior que a idade até.

42
7 MODELAGEM DO MÓDULO ADMINISTRATIVO
7.1 MODELO DINÂMICO
7.1.1 Diagrama de Casos de Usos
Figura 7: Caso de Uso do Módulo Administrativo

43
7.1.2 Fazer Login (CSU001)
Sumário: O Usuário solicita autenticação no sistema para ter acesso aos recursos
restritos de acordo com o seu nível de acesso.
Ator Primário: Usuário.
Pré-condições: O Usuário deve está previamente cadastrado no sistema.
Fluxo Principal:
1. O Usuário requisita a autenticação no sistema ou acessa uma página que
necessita de autenticação ou de um nível de acesso mais elevado.
2. O sistema apresenta a tela de login.
3. O Usuário informar os detalhes e confirmar a operação ou opta por finalizar o
caso de uso.
4. Se os dados forem inválidos, o sistema reporta o fato e o caso de uso retorna
ao passo 2; caso contrário, o sistema autentica o usuário e o caso de uso
termina.
Fluxo Alternativo (4): Falha no Login
a) Se o login falhou por causa da exceção “Usuário ou Senha Inválido”, o
contador de falha de login é incrementado;
b) Caso a quantidade de falhas seja 3, o sistema bloqueará o usuário, impedido
as tentativas futuras de autenticação.
Fluxo Alternativo (4): Alterar Senha
a) Se o usuário estiver marcado para alterar a senha, é realizado o caso de uso
CSU002 e aguardado o termino;
Fluxo de Exceção (4): Usuário ou Senha inválido
a) Se o sistema não conseguir encontrar o usuário e a senha, o sistema reporta
o fato e o caso de uso retorna ao passo 2.
Fluxo de Exceção (4): Usuário Bloqueado
a) Se o usuário estiver bloqueado, o sistema reporta o fato e o caso de uso
retorna ao passo 2.
Fluxo de Exceção (4): Usuário sem acesso a empresa
a) Se o usuário não tiver acesso à empresa informada, o sistema reporta o fato
e o caso de uso retorna ao passo 2.

44
Pós-Condições: O usuário estará autenticado no sistema e a suas permissões aos
recursos habilitadas.
Protótipo Tela:
Figura 8: Tela Fazer Login

45
Diagrama de Robustez:
Figura 9: Diagrama de Robustez Fazer Login
Diagrama de Sequência:
Figura 10: Diagrama de Sequência Fazer Login

46
7.1.3 Alterar Senha (CSU002)
Sumário: O Usuário solicita alteração da senha.
Pré-condições: O usuário deve está autenticado (Conforme RN001).
Fluxo Principal:
1. O Usuário requisita a alteração da sua senha.
2. O sistema apresenta a tela de alteração de senha.
caso de uso.
ao passo 2; caso contrário, o sistema altera a senha do usuário e o caso de
uso termina.
Fluxo de Exceção (4): Senha Atual Não Conferiu
a) Se o usuário informou a senha atual incorreta, o sistema reporta o fato e o
caso de uso retorna ao passo 2.
Fluxo de Exceção (4): Confirmação de Nova Senha Incorreta
a) Se o usuário confirmou a nova senha incorreta, o sistema reporta o fato e o
caso de uso retorna ao passo 2.
Pós-Condições: O usuário terá sua senha alterada no sistema.
Protótipo Tela:
Figura 11: Tela Alterar Senha

47
Figura 12: Diagrama de Robustez Alterar Senha
Figura 13: Diagrama de Sequência Alterar Senha

48
7.1.4 Manter Empresa (CSU003)
Sumário: O Administrador realiza o cadastro (consulta, inclusão, alteração e
remoção) dos dados sobre empresas.
Ator Primário: Administrador.
Pré-condições: O Administrador deve está autenticado e autorizado no sistema
(Conforme RN001).
Fluxo Principal:
1. O Administrador requisita a manutenção do cadastro de empresas.
O sistema apresenta listagem das empresas cadastradas com as operações
que podem ser realizadas: inclusão de uma nova empresa, alteração dos
dados da empresa, exclusão de uma empresa.
2. O Administrador indica a operação a realizar ou opta por finalizar o caso de
uso.
3. O Administrador seleciona a operação desejada: Inclusão, Alteração e
Exclusão.
4. O caso de uso retorna ao passo 2.
Fluxo Alternativo (4): Inclusão
a) O Administrador requisita a inclusão de uma empresa.
b) O sistema apresenta um formulário em branco para que os detalhes da
empresa sejam incluídos.
c) O Administrador informa os detalhes da nova empresa.
d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui a
nova empresa; caso contrário, o sistema reporta o fato, solicita alteração dos
dados e repete a verificação.
Fluxo Alternativo (4): Alteração
a) O Administrador seleciona uma empresa e requisita ao sistema a sua
alteração.
b) O sistema apresenta um formulário preenchido com os detalhes da empresa
que foi requisitada.
c) O Administrador altera um ou mais dos detalhes da empresa.

49
d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os
dados da empresa; caso contrário, o sistema reporta o fato, solicita alteração
dos dados e repete a verificação.
Fluxo Alternativo (4): Exclusão
a) O Administrador seleciona uma empresa e requisita ao sistema a sua
exclusão.
b) Se a empresa pode ser removida, o sistema realiza a remoção; caso
contrário, o sistema reporta o fato, solicita alteração dos dados e repete a
verificação.
Pós-Condições: Uma disciplina foi inserida ou removida, ou seus detalhes foram
alterados.
Protótipo Tela:
Figura 14: Tela Cadastrar Empresa

50
Figura 15: Diagrama de Robustez Cadastrar Empresa

51
Figura 16: Diagrama de Sequência Cadastrar Empresa
7.1.5 Manter Módulo (CSU004)
remoção) dos dados sobre módulos.
Ator Primário: Administrador
(Conforme RN001).

52
Fluxo Principal:
1. O Administrador requisita a manutenção do cadastro de módulos.
2. O sistema apresenta listagem dos módulos cadastrados com as operações
que podem ser realizadas: inclusão de um novo módulo, alteração dos dados
do módulo, exclusão de um módulo.
uso.
Exclusão.
a) O Administrador requisita a inclusão de um módulo.
b) O sistema apresenta um formulário em branco para que os detalhes do
módulo sejam incluídos.
c) O Administrador informa os detalhes do novo módulo.
d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o
novo módulo; caso contrário, o sistema reporta o fato, solicita alteração dos
a) O Administrador seleciona um módulo e requisita ao sistema a sua alteração.
b) O sistema apresenta um formulário preenchido com os detalhes do módulo
que foi requisitado.
c) O Administrador altera um ou mais dos detalhes do módulo.
dados do módulo; caso contrário, o sistema reporta o fato, solicita alteração
a) O Administrador seleciona um módulo e requisita ao sistema a sua exclusão.
b) Se o módulo puder ser removido, o sistema realiza a remoção; caso contrário,
o sistema reporta o fato, solicita alteração dos dados e repete a verificação.
Pós-Condições: Um módulo foi inserido ou removido, ou seus detalhes foram
alterados.

53
Protótipo Tela:
Figura 17: Tela Cadastrar Módulo
Figura 18: Diagrama de Robustez Cadastrar Módulo

54
Figura 19: Diagrama de Sequência Cadastrar Módulo
7.1.6 Manter Nível (CSU005)
remoção) dos dados sobre níveis.
(Conforme RN001).
Fluxo Principal:
1. O Administrador requisita a manutenção do cadastro de níveis.

55
2. O sistema apresenta listagem dos níveis cadastrados com as operações que
podem ser realizadas: inclusão de um novo nível, alteração dos dados do
nível, exclusão de um nível.
uso.
Exclusão.
a) O Administrador requisita a inclusão de um nível.
b) O sistema apresenta um formulário em branco para que os detalhes do nível
sejam incluídos.
c) O Administrador informa os detalhes do novo nível.
novo nível; caso contrário, o sistema reporta o fato, solicita alteração dos
a) O Administrador seleciona um nível e requisita ao sistema a sua alteração.
b) O sistema apresenta um formulário preenchido com os detalhes do nível que
foi requisitado.
c) O Administrador altera um ou mais dos detalhes do nível.
dados do nível; caso contrário, o sistema reporta o fato, solicita alteração dos
c) O Administrador seleciona um nível e requisita ao sistema a sua exclusão.
d) Se o nível puder ser removido, o sistema realiza a remoção; caso contrário, o
sistema reporta o fato, solicita alteração dos dados e repete a verificação.
Pós-Condições: Um nível foi inserido ou removido, ou seus detalhes foram
alterados.

56
Protótipo Tela:
Figura 20: Tela Cadastrar Nível
Figura 21: Diagrama de Robustez Cadastrar Nível

57
Figura 22: Diagrama de Sequência Cadastrar Nível
7.1.7 Manter Menu Grupo (CSU006)
remoção) dos dados sobre grupos de menus.

58
(Conforme RN001).
Fluxo Principal:
1. O Administrador requisita a manutenção do cadastro de grupo de menu.
2. O sistema apresenta listagem dos grupos de menu cadastrados com as
operações que podem ser realizadas: inclusão de um novo grupo, alteração
dos dados do grupo, exclusão de um grupo.
uso.
Exclusão.
a) O Administrador requisita a inclusão de um grupo de menu.
b) O sistema apresenta um formulário em branco para que os detalhes do grupo
de menu sejam incluídos.
c) O Administrador informa os detalhes do novo grupo de menu.
novo grupo de menu; caso contrário, o sistema reporta o fato, solicita
alteração dos dados e repete a verificação.
a) O Administrador seleciona um grupo de menu e requisita ao sistema a sua
alteração.
b) O sistema apresenta um formulário preenchido com os detalhes do grupo de
menu que foi requisitado.
c) O Administrador altera um ou mais dos detalhes do grupo de menu.
dados do grupo de menu; caso contrário, o sistema reporta o fato, solicita
a) O Administrador seleciona um grupo de menu e requisita ao sistema a sua
exclusão.
b) Se o grupo puder ser removido, o sistema realiza a remoção; caso contrário, o

59
Pós-Condições: Um grupo foi inserido ou removido, ou seus detalhes foram
alterados.
Protótipo Tela:
Figura 23: Tela Cadastrar Menu Grupo
Figura 24: Diagrama de Robustez Cadastrar Menu Grupo

60
Figura 25: Diagrama de Sequência Cadastrar Menu Grupo
7.1.8 Manter Menu Item (CSU007)
remoção) dos dados sobre itens de menu.
(Conforme RN001).

61
Fluxo Principal:
1. O Administrador requisita a manutenção do cadastro de item de menu.
2. O sistema apresenta listagem dos itens de menu cadastrados com as
operações que podem ser realizadas: inclusão de um novo item, alteração
dos dados do item, exclusão de um item.
uso.
Exclusão.
a) O Administrador requisita a inclusão de um item de menu.
b) O sistema apresenta um formulário em branco para que os detalhes do item
de menu sejam incluídos.
c) O Administrador informa os detalhes do novo item de menu.
novo item de menu; caso contrário, o sistema reporta o fato, solicita alteração
a) O Administrador seleciona um item de menu e requisita ao sistema a sua
alteração.
b) O sistema apresenta um formulário preenchido com os detalhes do item de
menu que foi requisitado.
c) O Administrador altera um ou mais dos detalhes do item de menu.
dados do item de menu; caso contrário, o sistema reporta o fato, solicita
a) O Administrador seleciona um item de menu e requisita ao sistema a sua
exclusão.
b) Se o item puder ser removido, o sistema realiza a remoção; caso contrário, o
Pós-Condições: Um item de menu foi inserido ou removido, ou seus detalhes foram
alterados.

62
Protótipo Tela:
Figura 26: Tela Cadastrar Menu Item
Figura 27: Diagrama de Robustez Cadastrar Menu Item

63
Figura 28: Diagrama de Sequência Cadastrar Menu Item
7.1.9 Manter Usuário (CSU008)
remoção) dos dados sobre usuários.
(Conforme RN001).

64
Fluxo Principal:
1. O Administrador requisita a manutenção do cadastro de usuários.
2. O sistema apresenta listagem dos usuários cadastrados com as operações
que podem ser realizadas: inclusão de um novo usuário, alteração dos dados
do usuário, exclusão de um usuário.
uso.
Exclusão.
a) O Administrador requisita a inclusão de um usuário.
b) O sistema apresenta um formulário em branco para que os detalhes do
usuário sejam incluídos.
c) O Administrador informa os detalhes do novo usuário.
d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui a
novo usuário; caso contrário, o sistema reporta o fato, solicita alteração dos
a) O Administrador seleciona um usuário e requisita ao sistema a sua alteração.
b) O sistema apresenta um formulário preenchido com os detalhes do usuário
que foi requisitado.
c) O Administrador altera um ou mais dos detalhes do usuário.
dados do usuário; caso contrário, o sistema reporta o fato, solicita alteração
a) O Administrador seleciona um usuário e requisita ao sistema a sua exclusão.
b) Se o usuário puder ser removido, o sistema realiza a remoção; caso contrário,
o sistema reporta o fato, solicita alteração dos dados e repete a verificação.
Pós-Condições: Um usuário foi inserido ou removido, ou seus detalhes foram
alterados.

65
Protótipo Tela:
Figura 29: Tela Cadastrar Usuário
Figura 30: Diagrama de Robustez Cadastrar Usuário

66
Figura 31: Diagrama de Sequência Cadastrar Usuário
7.1.10 Alternar Empresa (CSU009)
Sumário: O Usuário solicita alternação da empresa atual que está logado.
Pré-condições: O usuário deve está autenticado (Conforme RN001).
Fluxo Principal:
1. O Usuário requisita alternação da empresa atual que estar logado do sistema.

67
2. O sistema apresenta a tela de alteração de empresa com as empresas
autorizadas para o usuário.
caso de uso.
ao passo 2; caso contrário, o sistema alterna a empresa e o caso de uso
termina.
Pós-Condições: O usuário terá a empresa alternada e poderá continuar a operação
anterior.
Protótipo Tela:
Figura 32: Tela Alternar Empresa

68
Figura 33: Diagrama de Robustez Alternar Empresa
Figura 34: Diagrama de Sequência Alternar Empresa

69
7.1.11 Consultar Logs (CSU010)
Sumário: O Administrador solicita consulta de logs do sistema.
Ator Primário: Administrador.
Pré-condições: O administrador deve está autenticado (Conforme RN001).
Fluxo Principal:
1. O Usuário requisita a consulta aos logs do sistema.
2. O sistema apresenta a tela de consulta de logs.
3. O administrador informar nenhum ou algum dos detalhes e confirma a
operação ou opta por finalizar o caso de uso.
4. O sistema apresenta os logs ao administrador e retorna ao passo 3.
Pós-Condições: O usuário terá consultado os logs do sistema.
Protótipo Tela:
Figura 35: Tela Consultar Logs

70
Figura 36: Diagrama de Robustez Consultar Logs
Figura 37: Diagrama de Sequência Consultar Logs

71
7.1.12 Notificar Falha no Login (CSU011)
Sumário: O sistema recebe mensagem de que uma tentativa de autenticação no
sistema falhou e notifica o usuário relacionado.
Ator Primário: Sistema.
Pré-condições: O usuário deve está previamente cadastrado.
Fluxo Principal:
1. O sistema recebe mensagem de uma falha de autenticação.
2. O sistema envia uma notificação ao usuário e o caso de uso termina.
Pós-Condições: O sistema enviou a notificação de falha no login para o usuário
relacionado.
Protótipo de Notificação:
Figura 38: Mensagem de Notificação Falha no Login
Figura 39: Diagrama de Robustez Notificar Falha no Login

Sistema ARCA para gestão de vacinação

Sistema ARCA para gestão de vacinação

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Sistema ARCA para gestão de vacinação

Semelhante a Sistema ARCA para gestão de vacinação (20)

Sistema ARCA para gestão de vacinação