Transcript
Page 1: Arca Sistema Gerencial

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

Page 2: Arca Sistema Gerencial

FRANCINALDO RODRIGUES DE LIMA RICARDO JÚLIO DA SILVA CARVALHO

ARCA - SISTEMA GERENCIAL

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

Page 3: Arca Sistema Gerencial

FRANCINALDO RODRIGUES DE LIMA RICARDO JULIO DA SILVA CARVALHO

ARCA - SISTEMA GERENCIAL

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

Page 4: Arca Sistema Gerencial

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.

Page 5: Arca Sistema Gerencial

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.

Page 6: Arca Sistema Gerencial

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

Page 7: Arca Sistema Gerencial

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.

Page 8: Arca Sistema Gerencial

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.

Page 9: Arca Sistema Gerencial

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

Page 10: Arca Sistema Gerencial

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

Page 11: Arca Sistema Gerencial

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

Page 12: Arca Sistema Gerencial

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

Page 13: Arca Sistema Gerencial

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

Page 14: Arca Sistema Gerencial

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

SGBD Sistema Gerenciador de Banco de Dados

SQL Structured Query Language

UI Users Interface

UML Linguagem de Modelagem Unificada

XP Extreme Programming

Page 15: Arca Sistema Gerencial

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

Page 16: Arca Sistema Gerencial

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

Page 17: Arca Sistema Gerencial

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

Page 18: Arca Sistema Gerencial

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

Page 19: Arca Sistema Gerencial

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.

Page 20: Arca Sistema Gerencial

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.

Page 21: Arca Sistema Gerencial

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).

Page 22: Arca Sistema Gerencial

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.

Page 23: Arca Sistema Gerencial

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)

Page 24: Arca Sistema Gerencial

14

Calendário de Vacinação do Adolescente:

Quadro 2: Calendário do Adolescente Fonte: (PORTAL DA SAÚDE, extraído da Internet, 2012)

Calendário de Vacinação do Adulto e do Idoso:

Quadro 3: Calendário do Adulto e do Idoso

Fonte: (PORTAL DA SAÚDE, extraído da Internet, 2012)

Page 25: Arca Sistema Gerencial

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.

Page 26: Arca Sistema Gerencial

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).

Page 27: Arca Sistema Gerencial

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:

Page 28: Arca Sistema Gerencial

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

Page 29: Arca Sistema Gerencial

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.

Page 30: Arca Sistema Gerencial

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.”

Page 31: Arca Sistema Gerencial

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

Page 32: Arca Sistema Gerencial

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.

Page 33: Arca Sistema Gerencial

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.

Page 34: Arca Sistema Gerencial

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)

Page 35: Arca Sistema Gerencial

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.

Page 36: Arca Sistema Gerencial

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.

Page 37: Arca Sistema Gerencial

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

Fonte: Luckow; Melo (2010, p.495)

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

Page 38: Arca Sistema Gerencial

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

Page 39: Arca Sistema Gerencial

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

Page 40: Arca Sistema Gerencial

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).

Page 41: Arca Sistema Gerencial

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

Fonte: Luckow; Melo (2010, p.180)

Page 42: Arca Sistema Gerencial

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

Page 43: Arca Sistema Gerencial

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.

Page 44: Arca Sistema Gerencial

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:

Page 45: Arca Sistema Gerencial

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;

Page 46: Arca Sistema Gerencial

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;

Page 47: Arca Sistema Gerencial

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

Page 48: Arca Sistema Gerencial

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

Page 49: Arca Sistema Gerencial

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;

Page 50: Arca Sistema Gerencial

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.

Page 51: Arca Sistema Gerencial

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é.

Page 52: Arca Sistema Gerencial

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

Page 53: Arca Sistema Gerencial

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.

Page 54: Arca Sistema Gerencial

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

Page 55: Arca Sistema Gerencial

45

Diagrama de Robustez:

Figura 9: Diagrama de Robustez Fazer Login

Diagrama de Sequência:

Figura 10: Diagrama de Sequência Fazer Login

Page 56: Arca Sistema Gerencial

46

7.1.3 Alterar Senha (CSU002)

Sumário: O Usuário solicita alteração da senha.

Ator Primário: Usuário.

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.

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 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

Page 57: Arca Sistema Gerencial

47

Diagrama de Robustez:

Figura 12: Diagrama de Robustez Alterar Senha

Diagrama de Sequência:

Figura 13: Diagrama de Sequência Alterar Senha

Page 58: Arca Sistema Gerencial

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.

Page 59: Arca Sistema Gerencial

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

Page 60: Arca Sistema Gerencial

50

Diagrama de Robustez:

Figura 15: Diagrama de Robustez Cadastrar Empresa

Page 61: Arca Sistema Gerencial

51

Diagrama de Sequência:

Figura 16: Diagrama de Sequência Cadastrar Empresa

7.1.5 Manter Módulo (CSU004)

Sumário: O Administrador realiza o cadastro (consulta, inclusão, alteração e

remoção) dos dados sobre módulos.

Ator Primário: Administrador

Pré-condições: O Administrador deve está autenticado e autorizado no sistema

(Conforme RN001).

Page 62: Arca Sistema Gerencial

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.

3. O Administrador indica a operação a realizar ou opta por finalizar o caso de

uso.

4. O Administrador seleciona a operação desejada: Inclusão, Alteração e

Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusã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

dados e repete a verificação.

Fluxo Alternativo (4): Alteração

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.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do módulo; 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 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.

Page 63: Arca Sistema Gerencial

53

Protótipo Tela:

Figura 17: Tela Cadastrar Módulo

Diagrama de Robustez:

Figura 18: Diagrama de Robustez Cadastrar Módulo

Page 64: Arca Sistema Gerencial

54

Diagrama de Sequência:

Figura 19: Diagrama de Sequência Cadastrar Módulo

7.1.6 Manter Nível (CSU005)

Sumário: O Administrador realiza o cadastro (consulta, inclusão, alteração e

remoção) dos dados sobre níveis.

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 níveis.

Page 65: Arca Sistema Gerencial

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.

3. O Administrador indica a operação a realizar ou opta por finalizar o caso de

uso.

4. O Administrador seleciona a operação desejada: Inclusão, Alteração e

Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusã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.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo nível; 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 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.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do nível; caso contrário, o sistema reporta o fato, solicita alteração dos

dados e repete a verificação.

Fluxo Alternativo (4): Exclusão

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.

Page 66: Arca Sistema Gerencial

56

Protótipo Tela:

Figura 20: Tela Cadastrar Nível

Diagrama de Robustez:

Figura 21: Diagrama de Robustez Cadastrar Nível

Page 67: Arca Sistema Gerencial

57

Diagrama de Sequência:

Figura 22: Diagrama de Sequência Cadastrar Nível

7.1.7 Manter Menu Grupo (CSU006)

Sumário: O Administrador realiza o cadastro (consulta, inclusão, alteração e

remoção) dos dados sobre grupos de menus.

Ator Primário: Administrador

Page 68: Arca Sistema Gerencial

58

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 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.

3. O Administrador indica a operação a realizar ou opta por finalizar o caso de

uso.

4. O Administrador seleciona a operação desejada: Inclusão, Alteração e

Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusã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.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo grupo de menu; 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 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.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do grupo de menu; 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 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

sistema reporta o fato, solicita alteração dos dados e repete a verificação.

Page 69: Arca Sistema Gerencial

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

Diagrama de Robustez:

Figura 24: Diagrama de Robustez Cadastrar Menu Grupo

Page 70: Arca Sistema Gerencial

60

Diagrama de Sequência:

Figura 25: Diagrama de Sequência Cadastrar Menu Grupo

7.1.8 Manter Menu Item (CSU007)

Sumário: O Administrador realiza o cadastro (consulta, inclusão, alteração e

remoção) dos dados sobre itens de menu.

Ator Primário: Administrador

Pré-condições: O Administrador deve está autenticado e autorizado no sistema

(Conforme RN001).

Page 71: Arca Sistema Gerencial

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.

3. O Administrador indica a operação a realizar ou opta por finalizar o caso de

uso.

4. O Administrador seleciona a operação desejada: Inclusão, Alteração e

Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusã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.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo item de menu; 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 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.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do item de menu; 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 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

sistema reporta o fato, solicita alteração dos dados e repete a verificação.

Pós-Condições: Um item de menu foi inserido ou removido, ou seus detalhes foram

alterados.

Page 72: Arca Sistema Gerencial

62

Protótipo Tela:

Figura 26: Tela Cadastrar Menu Item

Diagrama de Robustez:

Figura 27: Diagrama de Robustez Cadastrar Menu Item

Page 73: Arca Sistema Gerencial

63

Diagrama de Sequência:

Figura 28: Diagrama de Sequência Cadastrar Menu Item

7.1.9 Manter Usuário (CSU008)

Sumário: O Administrador realiza o cadastro (consulta, inclusão, alteração e

remoção) dos dados sobre usuários.

Ator Primário: Administrador

Pré-condições: O Administrador deve está autenticado e autorizado no sistema

(Conforme RN001).

Page 74: Arca Sistema Gerencial

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.

3. O Administrador indica a operação a realizar ou opta por finalizar o caso de

uso.

4. O Administrador seleciona a operação desejada: Inclusão, Alteração e

Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusã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

dados e repete a verificação.

Fluxo Alternativo (4): Alteração

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.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do usuário; 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 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.

Page 75: Arca Sistema Gerencial

65

Protótipo Tela:

Figura 29: Tela Cadastrar Usuário

Diagrama de Robustez:

Figura 30: Diagrama de Robustez Cadastrar Usuário

Page 76: Arca Sistema Gerencial

66

Diagrama de Sequência:

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.

Ator Primário: Usuário.

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.

Page 77: Arca Sistema Gerencial

67

2. O sistema apresenta a tela de alteração de empresa com as empresas

autorizadas para o usuário.

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 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

Page 78: Arca Sistema Gerencial

68

Diagrama de Robustez:

Figura 33: Diagrama de Robustez Alternar Empresa

Diagrama de Sequência:

Figura 34: Diagrama de Sequência Alternar Empresa

Page 79: Arca Sistema Gerencial

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

Page 80: Arca Sistema Gerencial

70

Diagrama de Robustez:

Figura 36: Diagrama de Robustez Consultar Logs

Diagrama de Sequência:

Figura 37: Diagrama de Sequência Consultar Logs

Page 81: Arca Sistema Gerencial

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

Diagrama de Robustez:

Figura 39: Diagrama de Robustez Notificar Falha no Login

Page 82: Arca Sistema Gerencial

72

Diagrama de Sequência:

Figura 40: Diagrama de Sequência Notificar Falha no Login

Page 83: Arca Sistema Gerencial

73

7.2 MODELO ESTÁTICO

7.2.1 Modelo de Domínio

Figura 41: Modelo de Domínio do Módulo Administrativo

Page 84: Arca Sistema Gerencial

74

7.2.2 Diagrama de Classes

Figura 42: Diagrama de Classes do Módulo Administrativo

Page 85: Arca Sistema Gerencial

75

8 MODELAGEM DO MÓDULO ESTOQUE

8.1 MODELO DINÂMICO

8.1.1 Diagrama de Casos de Usos

Figura 43: Caso de Uso do Módulo Estoque

8.1.2 Manter Unidade (CSU012)

Sumário: O estoquista realiza o cadastro (consulta, inclusão, alteração e remoção)

dos dados sobre unidades.

Ator Primário: Estoquista.

Page 86: Arca Sistema Gerencial

76

Pré-condições: O estoquista deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O estoquista requisita a manutenção do cadastro de unidades.

O sistema apresenta listagem das unidades cadastradas com as operações

que podem ser realizadas: inclusão de uma nova unidade, alteração dos

dados da unidade, exclusão de uma unidade.

2. O Estoquista indica a operação a realizar ou opta por finalizar o caso de uso.

3. O Estoquista 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 Estoquista requisita a inclusão de uma unidade.

b) O sistema apresenta um formulário em branco para que os detalhes da

unidade sejam incluídos.

c) O Estoquista informa os detalhes da nova unidade.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui a

nova unidade; 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 Estoquista seleciona uma unidade e requisita ao sistema a sua alteração.

b) O sistema apresenta um formulário preenchido com os detalhes da unidade

que foi requisitada.

c) O Estoquista altera um ou mais dos detalhes da unidade.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados da unidade; 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 Estoquista seleciona uma unidade e requisita ao sistema a sua exclusão.

b) Se a unidade 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 unidade foi inserida ou removida, ou seus detalhes foram

alterados.

Page 87: Arca Sistema Gerencial

77

Protótipo Tela:

Figura 44: Tela Cadastrar Unidade

Diagrama de Robustez:

Figura 45: Diagrama de Robustez Cadastrar Unidade

Page 88: Arca Sistema Gerencial

78

Diagrama de Sequência:

Figura 46: Diagrama de Sequência Cadastrar Unidade

8.1.3 Manter Produto (CSU013)

Sumário: O estoquista realiza o cadastro (consulta, inclusão, alteração e remoção)

dos dados sobre os produtos.

Ator Primário: Estoquista

Pré-condições: O estoquista deve está autenticado e autorizado no sistema

(Conforme RN001).

Page 89: Arca Sistema Gerencial

79

Fluxo Principal:

1. O Estoquista requisita a manutenção do cadastro de produtos.

2. O sistema apresenta listagem dos produtos cadastrados com as operações

que podem ser realizadas: inclusão de um novo produto, alteração dos dados

dos produtos, exclusão de um produto.

3. O estoquista indica a operação a realizar ou opta por finalizar o caso de uso.

4. O estoquista seleciona a operação desejada: Inclusão, Alteração e Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

a) O estoquista requisita a inclusão de um produto.

b) O sistema apresenta um formulário em branco para que os detalhes do

produto sejam incluídos.

c) O estoquista informa os detalhes do novo produto.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo produto; 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 estoquista seleciona um produto e requisita ao sistema a sua alteração.

b) O sistema apresenta um formulário preenchido com os detalhes do produto

que foi requisitado.

c) O estoquista altera um ou mais dos detalhes do produto.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do produto; 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 estoquista seleciona um produto e requisita ao sistema a sua exclusão.

b) Se o produto pode 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 produto foi inserido ou removido, ou seus detalhes foram

alterados.

Page 90: Arca Sistema Gerencial

80

Protótipo Tela:

Figura 47: Tela Cadastrar Produto

Diagrama de Robustez:

Figura 48: Diagrama de Robustez Cadastrar Produto

Page 91: Arca Sistema Gerencial

81

Diagrama de Sequência:

Figura 49: Diagrama de Sequência Cadastrar Produto

Page 92: Arca Sistema Gerencial

82

8.1.4 Manter Fabricante (CSU014)

Sumário: O estoquista realiza o cadastro (consulta, inclusão, alteração e remoção)

dos dados sobre os fabricantes.

Ator Primário: Estoquista

Pré-condições: O estoquista deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O estoquista requisita a manutenção do cadastro de fabricante.

2. O sistema apresenta listagem dos fabricantes cadastrados com as operações

que podem ser realizadas: inclusão de um novo fabricante, alteração dos

dados dos fabricantes, exclusão de um fabricante.

3. O estoquista indica a operação a realizar ou opta por finalizar o caso de uso.

4. O estoquista seleciona a operação desejada: Inclusão, Alteração e Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

a) O estoquista requisita a inclusão de um fabricante.

b) O sistema apresenta um formulário em branco para que os detalhes do

fabricante sejam incluídos.

c) O estoquista informa os detalhes do novo fabricante.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo fabricante; 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 Estoquista seleciona um fabricante e requisita ao sistema a sua alteração.

b) O sistema apresenta um formulário preenchido com os detalhes do fabricante

que foi requisitado.

c) O estoquista altera um ou mais dos detalhes do fabricante.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do fabricante; 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 estoquista seleciona um fabricante e requisita ao sistema a sua exclusão.

Page 93: Arca Sistema Gerencial

83

b) Se o fabricante pode 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 fabricante foi inserido ou removido, ou seus detalhes foram

alterados.

Protótipo Tela:

Figura 50: Tela Cadastrar Fabricante

Diagrama de Robustez:

Figura 51: Diagrama de Robustez Cadastrar Fabricante

Page 94: Arca Sistema Gerencial

84

Diagrama de Sequência:

Figura 52: Diagrama de Sequência Cadastrar Fabricante

8.1.5 Manter Almoxarifado (CSU015)

Sumário: O estoquista realiza o cadastro (consulta, inclusão, alteração e remoção)

dos dados sobre os almoxarifados.

Ator Primário: Estoquista

Pré-condições: O estoquista deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

Page 95: Arca Sistema Gerencial

85

1. O estoquista requisita a manutenção do cadastro de almoxarifado.

2. O sistema apresenta listagem dos almoxarifados cadastrados com as

operações que podem ser realizadas: inclusão de um novo almoxarifado,

alteração dos dados dos almoxarifados, exclusão de um almoxarifado.

3. O estoquista indica a operação a realizar ou opta por finalizar o caso de uso.

4. O estoquista seleciona a operação desejada: Inclusão, Alteração e Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

a) O estoquista requisita a inclusão de um almoxarifado.

b) O sistema apresenta um formulário em branco para que os detalhes do

almoxarifado sejam incluídos.

c) O estoquista informa os detalhes do novo almoxarifado.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo almoxarifado; 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 Estoquista seleciona um almoxarifado e requisita ao sistema a sua

alteração.

b) O sistema apresenta um formulário preenchido com os detalhes do

almoxarifado que foi requisitado.

c) O estoquista altera um ou mais dos detalhes do almoxarifado.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do almoxarifado; 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 estoquista seleciona um almoxarifado e requisita ao sistema a sua

exclusão.

b) Se o almoxarifado pode 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 almoxarifado foi inserido ou removido, ou seus detalhes foram

alterados.

Page 96: Arca Sistema Gerencial

86

Protótipo Tela:

Figura 53: Tela Cadastrar Almoxarifado

Diagrama de Robustez:

Figura 54: Diagrama de Robustez Cadastrar Almoxarifado

Page 97: Arca Sistema Gerencial

87

Diagrama de Sequência:

Figura 55: Diagrama de Sequência Cadastrar Almoxarifado

8.1.6 Manter Grupo de Produtos (CSU016)

Sumário: O estoquista realiza o cadastro (consulta, inclusão, alteração e remoção)

dos dados sobre os grupos de produtos.

Ator Primário: Estoquista

Page 98: Arca Sistema Gerencial

88

Pré-condições: O estoquista deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O estoquista requisita a manutenção do cadastro de grupo de produto.

2. O sistema apresenta listagem dos grupos de produtos cadastrados com as

operações que podem ser realizadas: inclusão de um novo grupo de produto,

alteração dos dados dos grupos de produtos, exclusão de um grupo de

produto.

3. O estoquista indica a operação a realizar ou opta por finalizar o caso de uso.

4. O estoquista seleciona a operação desejada: Inclusão, Alteração e Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

a) O estoquista requisita a inclusão de um grupo de produto.

b) O sistema apresenta um formulário em branco para que os detalhes do grupo

de produto sejam incluídos.

c) O estoquista informa os detalhes do novo grupo de produto.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo grupo de produto; 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 Estoquista seleciona um grupo de produto e requisita ao sistema a sua

alteração.

b) O sistema apresenta um formulário preenchido com os detalhes do grupo de

produto que foi requisitado.

c) O estoquista altera um ou mais dos detalhes do grupo de produto.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do grupo de produto; 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 estoquista seleciona um grupo de produto e requisita ao sistema a sua

exclusão.

b) Se o grupo de produto pode 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.

Page 99: Arca Sistema Gerencial

89

Pós-Condições: Um grupo de produto foi inserido ou removido, ou seus detalhes

foram alterados.

Protótipo Tela:

Figura 56: Tela Cadastrar Grupo de produto

Diagrama de Robustez:

Figura 57: Diagrama de robustez Cadastrar Grupo de Produto

Page 100: Arca Sistema Gerencial

90

Diagrama de Sequência:

Figura 58: Diagrama de Sequência Cadastrar Grupo de Produto

8.1.7 Manter Fornecedor (CSU017)

Sumário: O estoquista realiza o cadastro (consulta, inclusão, alteração e remoção)

dos dados sobre os fornecedores.

Ator Primário: Estoquista

Pré-condições: O estoquista deve está autenticado e autorizado no sistema

(Conforme RN001).

Page 101: Arca Sistema Gerencial

91

Fluxo Principal:

1. O estoquista requisita a manutenção do cadastro de fornecedor.

2. O sistema apresenta listagem dos fornecedores cadastrados com as

operações que podem ser realizadas: inclusão de um novo fornecedor,

alteração dos dados dos fornecedores, exclusão de um fornecedor.

3. O estoquista indica a operação a realizar ou opta por finalizar o caso de uso.

4. O estoquista seleciona a operação desejada: Inclusão, Alteração e Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

a) O estoquista requisita a inclusão de um fornecedor.

b) O sistema apresenta um formulário em branco para que os detalhes do

fornecedor sejam incluídos.

c) O estoquista informa os detalhes do novo fornecedor.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo fornecedor; 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 Estoquista seleciona um fornecedor e requisita ao sistema a sua alteração.

b) O sistema apresenta um formulário preenchido com os detalhes do

fornecedor que foi requisitado.

c) O estoquista altera um ou mais dos detalhes do fornecedor.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do fornecedor; 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 estoquista seleciona um fornecedor e requisita ao sistema a sua exclusão.

b) Se o fornecedor pode 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 fornecedor foi inserido ou removido, ou seus detalhes foram

alterados.

Page 102: Arca Sistema Gerencial

92

Protótipo Tela:

Figura 59: Tela Cadastrar Fornecedor

Page 103: Arca Sistema Gerencial

93

Diagrama de Robustez:

Figura 60: Diagrama de Robustez Cadastrar Fornecedor

Page 104: Arca Sistema Gerencial

94

Diagrama de Sequência:

Figura 61: Diagrama de Sequência Cadastrar Fornecedor

8.1.8 Cadastrar Nota de Almoxarifado (CSU018)

Sumário: O estoquista solicita o cadastramento de uma Nota de Almoxarifado.

Ator Primário: Estoquista

Pré-condições: O estoquista deve está autenticado e autorizado no sistema

(Conforme RN001).

Page 105: Arca Sistema Gerencial

95

Fluxo Principal:

1. O estoquista requisita o cadastro de uma Nota de Almoxarifado.

2. O sistema apresenta tela de Nota de Entrada / Saída.

3. O estoquista informa os detalhes da Nota de Almoxarifado;

4. O sistema verifica a validade dos dados. Se os dados forem válidos, o

sistema solicita detalhes dos itens da Nota de Almoxarifado; caso contrário, o

sistema reporta o fato, e retorna ao passo 3.

5. O estoquista informa os detalhes dos itens da Nota de Almoxarifado.

6. O sistema verifica a validade dos dados. Se os dados dos itens forem válidos,

o sistema salva a Nota de Almoxarifado e finaliza o caso de uso.

Fluxo Alternativo (5): Informação do Lote e Validade

a) Caso o material exija informações de lote, o sistema solicita detalhes sobre

validade e lote dos produtos.

b) O sistema apresenta um formulário em branco para que os detalhes do lote

sejam informados.

c) O sistema verifica a validade dos dados. Se os dados forem válidos, salva os

detalhes do lote; caso contrário, o sistema reporta o fato, solicita alteração

dos dados e repete a verificação.

Fluxo de Exceção (6): Produto não vinculado ao almoxarifado

a) Se o material não estiver vinculado ao almoxarifado (Conforme RN007), o

sistema reporta o fato e o caso de uso retorna ao passo 5.

Pós-Condições: Uma Nota de Almoxarifado foi inserido.

Protótipo Tela:

Figura 62: Tela Cadastrar Nota de Almoxarifado - Etapa 1

Page 106: Arca Sistema Gerencial

96

Figura 63: Tela Cadastrar Nota de Almoxarifado - Etapa 2

Figura 64: Tela Cadastrar Nota de Almoxarifado - Informações Lote/Vencimento

Page 107: Arca Sistema Gerencial

97

Figura 65: Tela Cadastrar Nota de Almoxarifado - Impressão de Nota Estoque

Diagrama de Robustez:

Figura 66: Diagrama de Robustez Nota de Almoxarifado

Page 108: Arca Sistema Gerencial

98

Diagrama de Sequência:

Figura 67: Diagrama de Sequência Nota de Almoxarifado

8.1.9 Estornar Nota de Almoxarifado (CSU019)

Sumário: O estoquista solicita o estorno de uma Nota de Almoxarifado.

Ator Primário: Estoquista

Pré-condições: O estoquista deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O estoquista requisita o estorno de uma Nota de Almoxarifado.

Page 109: Arca Sistema Gerencial

99

2. O sistema apresenta tela de Nota de Estorno.

3. O estoquista informa os detalhes da Nota a ser estornada;

4. O sistema verifica a validade dos dados. Se os dados forem válidos, o

sistema retorna as Notas de Almoxarifado; caso contrário, o sistema reporta o

fato, e retorna ao passo 3.

5. O sistema realiza o estorno da Nota selecionada para o almoxarifado de

origem e finaliza o caso de uso.

Pós-Condições: Uma Nota de Almoxarifado foi estornada.

Protótipo Tela:

Figura 68: Tela Estornar Nota de Almoxarifado

Diagrama de Robustez:

Page 110: Arca Sistema Gerencial

100

Figura 69: Diagrama de Robustez Estornar Nota de Almoxarifado

Diagrama de Sequência:

Figura 70: Diagrama de Sequência Estornar Nota de Almoxarifado

8.1.10 Cadastrar Nota de Transferência (CSU020)

Sumário: O estoquista solicita a transferência dos produtos de um almoxarifado de

origem para outro almoxarifado de destino.

Ator Primário: Estoquista

Pré-condições: O estoquista deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O estoquista requisita a transferência de uma Nota de Almoxarifado.

2. O sistema apresenta tela de Nota de Transferência.

3. O estoquista informa os detalhes da Nota de Transferência.

Page 111: Arca Sistema Gerencial

101

4. O sistema verifica a validade dos dados. Se os dados forem válidos, o

sistema solicita detalhes dos itens da Nota de Transferência; caso contrário, o

sistema reporta o fato, e retorna ao passo 3.

5. O estoquista informa os detalhes dos itens da Nota de Transferência.

6. O sistema verifica a validade dos dados. Se os dados dos itens forem válidos,

o sistema salva a Nota de Almoxarifado e finaliza o caso de uso.

Fluxo Alternativo (5): Informação do Lote e Validade

a) Caso o material exija informações de lote, o sistema solicita detalhes sobre

validade e lote dos produtos.

Fluxo de Exceção (3): Almoxarifado de origem igual ao de destino

a) Se o almoxarifado de origem for o mesmo do almoxarifado de destino

(Conforme RN010), o sistema reporta o fato e o caso de uso retorna ao

passo 3.

Fluxo de Exceção (6): Produto não vinculado ao almoxarifado

a) Se o material não estiver vinculado ao almoxarifado (Conforme RN007), o

sistema reporta o fato e o caso de uso retorna ao passo 5.

Pós-Condições: Uma Nota de Transferência foi inserida.

Protótipo Tela:

Figura 71: Tela Cadastrar Nota de Transferência - Etapa 1

Page 112: Arca Sistema Gerencial

102

Figura 72: Tela Cadastrar Nota de Transferência - Etapa 2

Figura 73: Tela Cadastrar Nota de Transferência - Impressão

Page 113: Arca Sistema Gerencial

103

Diagrama de Robustez:

Figura 74: Diagrama de Robustez Nota de Transferência de Almoxarifado

Page 114: Arca Sistema Gerencial

104

Diagrama de Sequência:

Figura 75: Diagrama de Sequência Nota de Transferência de Almoxarifado

8.1.11 Gerar Relatório de Saldo do Estoque (CSU021)

Sumário: O estoquista solicita o relatório de saldo do estoque.

Ator Primário: Estoquista

Pré-condições: O estoquista deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O estoquista requisita a geração do relatório de saldo de estoque.

2. O sistema apresenta tela de geração do relatório.

Page 115: Arca Sistema Gerencial

105

3. O estoquista informa os detalhes para geração do relatório.

4. O sistema verifica a validade dos dados. Se os dados dos itens forem válidos,

o sistema gera o relatório e finaliza o caso de uso.

Pós-Condições: O relatório é exibido na tela.

Protótipo Tela:

Figura 76: Tela Relatório de Saldo de Estoque

Figura 77: Relatório de Saldo de Estoque

Diagrama de Robustez:

Page 116: Arca Sistema Gerencial

106

Figura 78: Diagrama de Robustez Relatório de Saldo

Page 117: Arca Sistema Gerencial

107

Diagrama de Sequência:

Figura 79: Diagrama de Sequência Relatório de Saldo

Page 118: Arca Sistema Gerencial

108

8.2 MODELO ESTÁTICO

8.2.1 Modelo de Domínio

Figura 80: Modelo de Domínio do Módulo Estoque

Page 119: Arca Sistema Gerencial

109

8.2.2 Diagrama de Classes

Figura 81: Diagrama de Classes do Módulo Estoque

Page 120: Arca Sistema Gerencial

110

9 MODELAGEM DO MÓDULO VACINAÇÃO

9.1 MODELO DINÂMICO

9.1.1 Diagrama de Casos de Usos

Figura 82: Caso de Uso do Módulo Vacinação

Page 121: Arca Sistema Gerencial

111

9.1.2 Manter Cliente (CSU022)

Sumário: O vacinador realiza o cadastro (consulta, inclusão, alteração e remoção)

dos dados sobre os clientes.

Ator Primário: Vacinador

Pré-condições: O vacinador deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O vacinador requisita a manutenção do cadastro de clientes.

2. O sistema apresenta listagem dos clientes cadastrados com as operações

que podem ser realizadas: inclusão de um novo cliente, alteração dos dados

dos clientes, exclusão de um cliente.

3. O vacinador indica a operação a realizar ou opta por finalizar o caso de uso.

4. O vacinador seleciona a operação desejada: Inclusão, Alteração e Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

a) O vacinador requisita a inclusão de um cliente.

b) O sistema apresenta um formulário em branco para que os detalhes do

cliente sejam incluídos.

c) O vacinador informa os detalhes do novo cliente.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo cliente; 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 vacinador seleciona um cliente e requisita ao sistema a sua alteração.

b) O sistema apresenta um formulário preenchido com os detalhes do cliente

que foi requisitado.

c) O vacinador altera um ou mais dos detalhes do cliente.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do cliente; caso contrário, o sistema reporta o fato, solicita alteração

dos dados e repete a verificação.

Fluxo Alternativo (4): Exclusão

Page 122: Arca Sistema Gerencial

112

a) O vacinador seleciona um cliente e requisita ao sistema a sua exclusão.

b) Se o cliente pode 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 cliente foi inserido ou removido, ou seus detalhes foram

alterados.

Protótipo Tela:

Figura 83: Tela Cadastrar Cliente

Page 123: Arca Sistema Gerencial

113

Diagrama de Robustez:

Figura 84: Diagrama de Robustez Cadastrar Cliente

Page 124: Arca Sistema Gerencial

114

Diagrama de Sequência:

Figura 85: Diagrama de Sequência Cadastrar Cliente

9.1.3 Manter Médico (CSU023)

Sumário: O vacinador realiza o cadastro (consulta, inclusão, alteração e remoção)

dos dados sobre os médicos.

Ator Primário: Vacinador

Pré-condições: O vacinador deve está autenticado e autorizado no sistema

(Conforme RN001).

Page 125: Arca Sistema Gerencial

115

Fluxo Principal:

1. O vacinador requisita a manutenção do cadastro de médicos.

2. O sistema apresenta listagem dos médicos cadastrados com as operações

que podem ser realizadas: inclusão de um novo médico, alteração dos dados

dos médicos, exclusão de um médico.

3. O vacinador indica a operação a realizar ou opta por finalizar o caso de uso.

4. O vacinador seleciona a operação desejada: Inclusão, Alteração e Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

a) O vacinador requisita a inclusão de um médico.

b) O sistema apresenta um formulário em branco para que os detalhes do

médico sejam incluídos.

c) O vacinador informa os detalhes do novo médico.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo médico; 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 vacinador seleciona um médico e requisita ao sistema a sua alteração.

b) O sistema apresenta um formulário preenchido com os detalhes do médico

que foi requisitado.

c) O vacinador altera um ou mais dos detalhes do médico.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do médico; 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 vacinador seleciona um médico e requisita ao sistema a sua exclusão.

b) Se o médico pode 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édico foi inserido ou removido, ou seus detalhes foram

alterados.

Page 126: Arca Sistema Gerencial

116

Protótipo Tela:

Figura 86: Tela Cadastrar Médico

Diagrama de Robustez:

Figura 87: Diagrama de Robustez Cadastrar Médico

Page 127: Arca Sistema Gerencial

117

Diagrama de Sequência:

Figura 88: Diagrama de Sequência Cadastrar Médico

9.1.4 Manter Vacinador (CSU024)

Sumário: O vacinador realiza o cadastro (consulta, inclusão, alteração e remoção)

dos dados sobre os vacinadores.

Ator Primário: Vacinador

Pré-condições: O vacinador deve está autenticado e autorizado no sistema

(Conforme RN001).

Page 128: Arca Sistema Gerencial

118

Fluxo Principal:

1. O vacinador requisita a manutenção do cadastro de vacinadores.

2. O sistema apresenta listagem dos vacinadores cadastrados com as

operações que podem ser realizadas: inclusão de um novo vacinador,

alteração dos dados dos vacinadores, exclusão de um vacinador.

3. O vacinador indica a operação a realizar ou opta por finalizar o caso de uso.

4. O vacinador seleciona a operação desejada: Inclusão, Alteração e Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

a) O vacinador requisita a inclusão de um vacinador.

b) O sistema apresenta um formulário em branco para que os detalhes do

vacinador sejam incluídos.

c) O vacinador informa os detalhes do novo vacinador.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo vacinador; 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 vacinador seleciona um vacinador e requisita ao sistema a sua alteração.

b) O sistema apresenta um formulário preenchido com os detalhes do vacinador

que foi requisitado.

c) O vacinador altera um ou mais dos detalhes do vacinador.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do vacinador; 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 vacinador seleciona um vacinador e requisita ao sistema a sua exclusão.

b) Se o vacinador pode 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 vacinador foi inserido ou removido, ou seus detalhes foram

alterados.

Page 129: Arca Sistema Gerencial

119

Protótipo Tela:

Figura 89: Tela Cadastrar Vacinador

Diagrama de Robustez:

Figura 90: Diagrama de Robustez Cadastrar Vacinador

Page 130: Arca Sistema Gerencial

120

Diagrama de Sequência:

Figura 91: Diagrama de Sequência Cadastrar Vacinador

9.1.5 Manter Tabela Preço (CSU025)

Sumário: O vacinador realiza o cadastro (consulta, inclusão, alteração e remoção)

dos dados sobre as tabelas de preços.

Ator Primário: Vacinador

Page 131: Arca Sistema Gerencial

121

Pré-condições: O vacinador deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O vacinador requisita a manutenção do cadastro de tabelas de preços.

2. O sistema apresenta listagem das tabelas de preços cadastrados com as

operações que podem ser realizadas: inclusão de uma nova tabela de preço,

alteração dos dados das tabelas de preços, exclusão de uma tabela de preço.

3. O vacinador indica a operação a realizar ou opta por finalizar o caso de uso.

4. O vacinador seleciona a operação desejada: Inclusão, Alteração e Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

e) O vacinador requisita a inclusão de uma tabela de preço.

f) O sistema apresenta um formulário em branco para que os detalhes da tabela

de preço sejam incluídos.

g) O vacinador informa os detalhes da nova tabela de preço.

h) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui a

nova tabela de preço; caso contrário, o sistema reporta o fato, solicita

alteração dos dados e repete a verificação.

Fluxo Alternativo (4): Alteração

e) O vacinador seleciona uma tabela de preço e requisita ao sistema a sua

alteração.

f) O sistema apresenta um formulário preenchido com os detalhes da tabela de

preço que foi requisitado.

g) O vacinador altera um ou mais dos detalhes da tabela de preço.

h) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados da tabela de preço; caso contrário, o sistema reporta o fato, solicita

alteração dos dados e repete a verificação.

Fluxo Alternativo (4): Exclusão

c) O vacinador seleciona uma tabela de preço e requisita ao sistema a sua

exclusão.

d) Se a tabela de preço 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.

Page 132: Arca Sistema Gerencial

122

Pós-Condições: Uma tabela de preço foi inserida ou removida, ou seus detalhes

foram alterados.

Protótipo Tela:

Figura 92: Tela Cadastrar Tabela de Preço

Page 133: Arca Sistema Gerencial

123

Diagrama de Robustez:

Figura 93: Diagrama de Robustez Cadastrar Tabela de Preço

Page 134: Arca Sistema Gerencial

124

Diagrama de Sequência:

Figura 94: Diagrama de Sequência Cadastrar Tabela de Preço

9.1.6 Manter Vacina (CSU026)

Sumário: O vacinador realiza o cadastro (consulta, inclusão, alteração e remoção)

dos dados sobre as vacinas.

Ator Primário: Vacinador

Page 135: Arca Sistema Gerencial

125

Pré-condições: O vacinador deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O vacinador requisita a manutenção do cadastro de vacina.

2. O sistema apresenta listagem das vacinas cadastradas com as operações

que podem ser realizadas: inclusão de uma vacina, alteração dos dados das

vacinas, exclusão de uma vacina.

3. O vacinador indica a operação a realizar ou opta por finalizar o caso de uso.

4. O vacinador seleciona a operação desejada: Inclusão, Alteração e Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

a) O vacinador requisita a inclusão de uma vacina.

b) O sistema apresenta um formulário em branco para que os detalhes da

vacina sejam incluídos.

c) O vacinador informa os detalhes da nova vacina.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui a

nova vacina; 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 vacinador seleciona uma vacina e requisita ao sistema a sua alteração.

b) O sistema apresenta um formulário preenchido com os detalhes da vacina

que foi requisitado.

c) O vacinador altera um ou mais dos detalhes da vacina.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados da vacina; 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 vacinador seleciona uma vacina e requisita ao sistema a sua exclusão.

b) Se a vacina 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 vacina foi inserida ou removida, ou seus detalhes foram

alterados.

Page 136: Arca Sistema Gerencial

126

Protótipo Tela:

Figura 95: Tela Cadastrar Vacina

Diagrama de Robustez:

Figura 96: Diagrama de Robustez Cadastrar Vacina

Page 137: Arca Sistema Gerencial

127

Diagrama de Sequência:

Figura 97: Diagrama de Sequência Cadastrar Vacina

Page 138: Arca Sistema Gerencial

128

9.1.7 Manter Bandeira de Cartão de Crédito (CSU027)

Sumário: O vacinador realiza o cadastro (consulta, inclusão, alteração e remoção)

dos dados sobre as bandeiras de cartão.

Ator Primário: Vacinador

Pré-condições: O vacinador deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O vacinador requisita a manutenção do cadastro de bandeiras de cartão.

2. O sistema apresenta listagem das bandeiras de cartão cadastradas com as

operações que podem ser realizadas: inclusão de uma bandeira de cartão,

alteração dos dados das bandeiras de cartão, exclusão de uma bandeira de

cartão.

3. O vacinador indica a operação a realizar ou opta por finalizar o caso de uso.

4. O vacinador seleciona a operação desejada: Inclusão, Alteração e Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

a) O vacinador requisita a inclusão de uma bandeira de cartão.

b) O sistema apresenta um formulário em branco para que os detalhes da

bandeira de cartão sejam incluídos.

c) O vacinador informa os detalhes da nova bandeira de cartão.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui a

nova bandeira de cartão; 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 vacinador seleciona uma bandeira de cartão e requisita ao sistema a sua

alteração.

b) O sistema apresenta um formulário preenchido com os detalhes da bandeira

de cartão que foi requisitado.

c) O vacinador altera um ou mais dos detalhes da bandeira de cartão.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados da bandeira de cartão; caso contrário, o sistema reporta o fato, solicita

alteração dos dados e repete a verificação.

Page 139: Arca Sistema Gerencial

129

Fluxo Alternativo (4): Exclusão

a) O vacinador seleciona uma bandeira de cartão e requisita ao sistema a sua

exclusão.

b) Se a bandeira de cartão 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 bandeira de cartão foi inserida ou removida, ou seus detalhes

foram alterados.

Protótipo Tela:

Figura 98: Tela Cadastrar Bandeira de Cartão de Crédito

Diagrama de Robustez:

Figura 99: Diagrama de Robustez Cadastrar Bandeira de Cartão de Crédito

Page 140: Arca Sistema Gerencial

130

Diagrama de Sequência:

Figura 100: Diagrama de Sequência Cadastrar Bandeira de Cartão de Crédito

Page 141: Arca Sistema Gerencial

131

9.1.8 Manter Forma de Pagamento (CSU028)

Sumário: O vacinador realiza o cadastro (consulta, inclusão, alteração e remoção)

dos dados sobre as formas de pagamentos.

Ator Primário: Vacinador

Pré-condições: O vacinador deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1 O vacinador requisita a manutenção do cadastro de formas de pagamentos.

2 O sistema apresenta listagem das formas de pagamentos cadastradas com

as operações que podem ser realizadas: inclusão de uma vacina, alteração

dos dados das formas de pagamentos, exclusão de uma forma de

pagamento.

3 O vacinador indica a operação a realizar ou opta por finalizar o caso de uso.

4 O vacinador seleciona a operação desejada: Inclusão, Alteração e Exclusão.

5 O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

a) O vacinador requisita a inclusão de uma vacina.

b) O sistema apresenta um formulário em branco para que os detalhes da forma

de pagamento sejam incluídos.

c) O vacinador informa os detalhes da nova forma de pagamento.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui a

nova forma de pagamento; 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 vacinador seleciona uma forma de pagamento e requisita ao sistema a sua

alteração.

b) O sistema apresenta um formulário preenchido com os detalhes da forma de

pagamento que foi requisitado.

c) O vacinador altera um ou mais dos detalhes da forma de pagamento.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados da forma de pagamento; caso contrário, o sistema reporta o fato,

solicita alteração dos dados e repete a verificação.

Page 142: Arca Sistema Gerencial

132

Fluxo Alternativo (4): Exclusão

a) O vacinador seleciona uma forma de pagamento e requisita ao sistema a sua

exclusão.

b) Se a vacina 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 forma de pagamento foi inserida ou removida, ou seus

detalhes foram alterados.

Protótipo Tela:

Figura 101: Tela Cadastrar Forma de Pagamento

Page 143: Arca Sistema Gerencial

133

Diagrama de Robustez:

Figura 102: Diagrama de Robustez Cadastrar Forma de Pagamento

Page 144: Arca Sistema Gerencial

134

Diagrama de Sequência:

Figura 103: Diagrama de Sequência Cadastrar Forma de Pagamento

9.1.9 Manter Esquema de Vacina (CSU029)

Sumário: O estoquista solicita o cadastramento de um esquema de vacina.

Ator Primário: Vacinador

Page 145: Arca Sistema Gerencial

135

Pré-condições: O vacinador deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O vacinador requisita o cadastro de um esquema de vacina.

2. O sistema apresenta tela de esquema de vacina.

3. O vacinador informa os detalhes do esquema de vacina.

4. O sistema verifica a validade dos dados (Conforme RN011). Se os dados

forem válidos, o sistema solicita detalhes dos itens do esquema; caso

contrário, o sistema reporta o fato, e retorna ao passo 3.

5. O vacinador informa os detalhes dos itens do esquema de vacina.

6. O sistema verifica a validade dos dados. Se os dados dos itens forem válidos,

o sistema salva o esquema de vacina e finaliza o caso de uso.

Pós-Condições: Um esquema de vacina foi inserido no sistema.

Protótipo Tela:

Figura 104: Tela Cadastrar Esquema de Vacina

Page 146: Arca Sistema Gerencial

136

Diagrama de Robustez:

Figura 105: Diagrama de Robustez Esquema de Vacina

Page 147: Arca Sistema Gerencial

137

Diagrama de Sequência:

Figura 106: Diagrama de Sequência Esquema de Vacina

Page 148: Arca Sistema Gerencial

138

9.1.10 Abrir Caixa (CSU030)

Sumário: O vacinador realiza a abertura de caixa.

Ator Primário: Vacinador

Pré-condições: O vacinador deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O vacinador requisita a rotina de abertura de caixa.

2. O sistema apresenta a rotina de abertura de caixa.

3. O vacinador seleciona a data de abertura.

4. O sistema realiza as validações (Conforme RN008), se os dados forem

validos o sistema finaliza o caso de uso, caso contrário, o sistema retorna ao

passo 2.

Pós-Condições: Um caixa foi aberto para a data selecionada.

Protótipo Tela:

Figura 107: Tela Abrir Caixa

Page 149: Arca Sistema Gerencial

139

Diagrama de Robustez:

Figura 108: Diagrama de Robustez Abrir Caixa

Diagrama de Sequência:

Figura 109: Diagrama de Sequência Abrir Caixa

Page 150: Arca Sistema Gerencial

140

9.1.11 Encerrar Caixa (CSU031)

Sumário: O vacinador realiza o encerramento de caixa.

Ator Primário: Vacinador

Pré-condições: O vacinador deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O vacinador requisita a rotina de encerrar o caixa.

2. O sistema apresenta a rotina de encerramento de caixa.

3. O vacinador seleciona a data de encerramento.

4. O sistema realiza as validações (Conforme RN009), se os dados forem

validos o sistema finaliza o caso de uso, caso contrário, o sistema retorna ao

passo 2.

Pós-Condições: Um caixa foi encerrado com sucesso.

Protótipo Tela:

Figura 110: Tela Encerrar Caixa

Page 151: Arca Sistema Gerencial

141

Figura 111: Tela Encerrar Caixa - Conferência Cartão

Figura 112: Tela Encerrar Caixa - Visualizar Venda

Page 152: Arca Sistema Gerencial

142

Diagrama de Robustez:

Figura 113: Diagrama de Robustez Encerrar Caixa

Page 153: Arca Sistema Gerencial

143

Diagrama de Sequência:

Figura 114: Diagrama de Sequência Encerrar Caixa

9.1.12 Cadastrar Venda (CSU032)

Sumário: O vacinador solicita o cadastramento de uma Venda.

Ator Primário: vacinador

Pré-condições: O vacinador deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

Page 154: Arca Sistema Gerencial

144

1. O vacinador requisita o cadastro de uma venda.

2. O sistema apresenta tela de venda.

3. O vacinador informa os detalhes da venda;

4. O sistema verifica a validade dos dados. Se os dados forem válidos, o

sistema solicita detalhes dos itens da venda; caso contrário, o sistema reporta

o fato, e retorna ao passo 3.

5. O vacinador informa os detalhes dos itens da venda.

6. O sistema verifica a validade dos dados. Se os dados dos itens forem válidos,

o sistema salva a venda e finaliza o caso de uso.

Pós-Condições: Uma venda foi inserida.

Protótipo Tela:

Figura 115: Tela Cadastrar Venda - Etapa 1

Figura 116: Tela Cadastrar Venda - Etapa 2

Page 155: Arca Sistema Gerencial

145

Figura 117: Tela Cadastrar Venda - Selecionar Cliente

Page 156: Arca Sistema Gerencial

146

Diagrama de Robustez:

Figura 118: Diagrama de Robustez Venda

Page 157: Arca Sistema Gerencial

147

Diagrama de Sequência:

Figura 119: Diagrama de Sequência Venda

9.1.13 Realizar Recebimento (CSU033)

Sumário: O vacinador solicita o realizar o recebimento.

Ator Primário: vacinador

Pré-condições: O vacinador deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O vacinador requisita a rotina de recebimento.

2. O sistema apresenta a tela de recebimento.

3. O vacinador informa o caixa desejado.

Page 158: Arca Sistema Gerencial

148

4. O vacinador informa a venda desejada.

5. O vacinador informa os detalhes do recebimento.

6. O sistema verifica a validade dos dados. Se os dados forem válidos, o

sistema salva o recebimento e finaliza o caso de uso.

Pós-Condições: Um recebimento foi inserido.

Protótipo Tela:

Figura 120: Tela Realizar Recebimento

Figura 121: Tela Realizar Recebimento - Selecionar Venda

Page 159: Arca Sistema Gerencial

149

Figura 122: Tela Realizar Recebimento - Alterar Tabela de Preço

Figura 123: Tela Realizar Recebimento - Selecionar Conta do Cliente

Page 160: Arca Sistema Gerencial

150

Diagrama de Robustez:

Figura 124: Diagrama de Robustez Realizar Recebimento

Page 161: Arca Sistema Gerencial

151

Diagrama de Sequência:

Figura 125: Diagrama de Sequência Realizar Recebimento

9.1.14 Realizar Aplicação (CSU034)

Sumário: O vacinador solicita realizar a aplicação.

Ator Primário: vacinador

Pré-condições: O vacinador deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O vacinador requisita a rotina de aplicação de vacina.

2. O sistema apresenta a tela de aplicação.

3. O vacinador informa os detalhes da aplicação.

Page 162: Arca Sistema Gerencial

152

4. O sistema verifica a validade dos dados. Se os dados forem válidos, o

sistema salva o recebimento e finaliza o caso de uso, caso contrário, o

sistema reporta o fato e retorna para o passo 3.

Pós-Condições: Uma aplicação foi inserida.

Protótipo Tela:

Figura 126: Tela Realizar Aplicação

Figura 127: Tela Realizar Aplicação - Selecionar Cliente

Page 163: Arca Sistema Gerencial

153

Diagrama de Robustez:

Figura 128: Diagrama de Robustez Realizar Aplicação

Page 164: Arca Sistema Gerencial

154

Diagrama de Sequência:

Figura 129: Diagrama de Sequência Realizar Aplicação

9.1.15 Lançar Saldo Cliente (CSU035)

Sumário: O vacinador solicita lançar saldo em um cliente.

Ator Primário: vacinador

Pré-condições: O vacinador deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O vacinador requisita a rotina para lançar saldo no cliente.

2. O sistema apresenta a tela de lançar saldo no cliente.

3. O vacinador informa os detalhes do cliente e o valor do saldo.

Page 165: Arca Sistema Gerencial

155

4. O sistema verifica a validade dos dados. Se os dados forem válidos, o

sistema salva o lançamento de saldo e finaliza o caso de uso, caso contrário,

o sistema reporta o fato e retorna para o passo 3.

Pós-Condições: O saldo foi lançado para o cliente selecionado

Protótipo Tela:

Figura 130: Tela Cadastrar Saldo de Cliente

Diagrama de Robustez:

Figura 131: Diagrama de Robustez Cadastrar Saldo de Cliente

Page 166: Arca Sistema Gerencial

156

Diagrama de Sequência:

Figura 132: Diagrama de Sequência Cadastrar Saldo de Cliente

9.1.16 Notificar Vacina Pendente / Indicada (CSU036)

Sumário: O sistema verifica diariamente as aplicações de vacinas pendentes /

indicadas e notifica aos clientes.

Ator Primário: Sistema.

Pré-condições: O cliente deve está previamente cadastrado.

Fluxo Principal:

1. O sistema verifica se existem aplicações de vacinas pendentes / indicadas

para a data atual;

2. O sistema envia as notificações aos clientes encontrados e o caso de uso

termina.

Pós-Condições: O sistema enviou as notificações para os clientes encontrados.

Page 167: Arca Sistema Gerencial

157

Protótipo de Notificação:

Figura 133: Mensagem de Notificação Vacina Pendente / Indicada

Page 168: Arca Sistema Gerencial

158

Diagrama de Robustez:

Figura 134: Diagrama de Robustez Notificar Vacina Pendente / Indicada

Page 169: Arca Sistema Gerencial

159

Diagrama de Sequência:

Figura 135: Diagrama de Sequência Notificar Vacina Pendente / Indicada

9.1.17 Notificar Venda Cancelada (CSU037)

Sumário: O sistema recebe mensagem de que uma venda foi cancelada e envia

uma notificação ao gestor da clínica.

Ator Primário: Sistema.

Pré-condições: O gestor deve está previamente cadastrado.

Fluxo Principal:

3. O sistema recebe mensagem de uma venda cancelada.

4. O sistema envia a notificação ao gestor da clínica e o caso de uso termina.

Pós-Condições: O sistema enviou a notificação de cancelamento para o gestor da

clínica.

Page 170: Arca Sistema Gerencial

160

Protótipo de Notificação:

Figura 136: Mensagem de Notificação Venda Cancelada

Diagrama de Robustez:

Figura 137: Diagrama de Robustez Notificar Venda Cancelada

Page 171: Arca Sistema Gerencial

161

Diagrama de Sequência:

Figura 138: Diagrama de Sequência Notificar Venda Cancelada

9.1.18 Notificação Gerencial (CSU038)

Sumário: O sistema envia os relatórios de acompanhamento gerencial para os

diretores da empresa (uma vez no mês).

Ator Primário: Sistema.

Pré-condições: Os diretores devem está previamente cadastrado.

Fluxo Principal:

1. O sistema gerar os relatórios com base no mês atual.

2. O sistema envia a notificação aos diretores e o caso de uso termina.

Pós-Condições: O sistema enviou os relatórios para os diretores da empresa.

Page 172: Arca Sistema Gerencial

162

Diagrama de Robustez:

Figura 139: Diagrama de Notificação Gerencial

Diagrama de Sequência:

Figura 140: Diagrama de Sequência Notificação Gerencial

Page 173: Arca Sistema Gerencial

163

9.2 MODELO ESTÁTICO

9.2.1 Modelo de Domínio

Figura 141: Modelo de Domínio do Módulo de Vacinação

Page 174: Arca Sistema Gerencial

164

9.2.2 Diagrama de Classes

Figura 142: Diagrama de Classes do Módulo de Vacinação

Page 175: Arca Sistema Gerencial

165

10 MODELAGEM DO MÓDULO FINANCEIRO

10.1 MODELO DINÂMICO

10.1.1 Diagrama de Casos de Usos

Figura 143: Caso de Uso do Módulo Financeiro

10.1.2 Manter Caixa (CSU039)

Sumário: O gerente financeiro realiza o cadastro (consulta, inclusão, alteração e

remoção) dos dados sobre os caixas.

Ator Primário: Gerente Financeiro

Page 176: Arca Sistema Gerencial

166

Pré-condições: O Gerente Financeiro deve está autenticado e autorizado no

sistema (Conforme RN001).

Fluxo Principal:

1. O gerente financeiro requisita a manutenção do cadastro de caixas.

2. O sistema apresenta listagem dos caixas cadastrados com as operações que

podem ser realizadas: inclusão de um novo caixa, alteração dos dados dos

caixas, exclusão de um caixa.

3. O gerente financeiro indica a operação a realizar ou opta por finalizar o caso

de uso.

4. O gerente financeiro seleciona a operação desejada: Inclusão, Alteração e

Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

a) O gerente financeiro requisita a inclusão de um caixa.

b) O sistema apresenta um formulário em branco para que os detalhes do caixa

sejam incluídos.

c) O gerente financeiro informa os detalhes do novo caixa.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo caixa; 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 gerente financeiro seleciona um caixa e requisita ao sistema a sua

alteração.

b) O sistema apresenta um formulário preenchido com os detalhes do caixa que

foi requisitado.

c) O gerente financeiro altera um ou mais dos detalhes do caixa.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do caixa; 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 gerente financeiro seleciona um caixa e requisita ao sistema a sua

exclusão.

b) Se o caixa pode 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.

Page 177: Arca Sistema Gerencial

167

Pós-Condições: Um caixa foi inserido ou removido, ou seus detalhes foram

alterados.

Protótipo Tela:

Figura 144: Tela Cadastrar Caixa

Page 178: Arca Sistema Gerencial

168

Diagrama de Robustez:

Figura 145: Diagrama de Robustez Cadastrar Caixa

Page 179: Arca Sistema Gerencial

169

Diagrama de Sequência:

Figura 146: Diagrama de Sequência Cadastrar Caixa

10.1.3 Manter Plano de Contas (CSU040)

Sumário: O gerente financeiro realiza o cadastro (consulta, inclusão, alteração e

remoção) dos dados sobre as contas.

Ator Primário: Gerente Financeiro

Page 180: Arca Sistema Gerencial

170

Pré-condições: O Gerente Financeiro deve está autenticado e autorizado no

sistema (Conforme RN001).

Fluxo Principal:

1. O gerente financeiro requisita a manutenção do cadastro de contas.

2. O sistema apresenta listagem dos caixas cadastrados com as operações que

podem ser realizadas: inclusão de uma nova conta, alteração dos dados da

conta, exclusão de uma conta.

3. O gerente financeiro indica a operação a realizar ou opta por finalizar o caso

de uso.

4. O gerente financeiro seleciona a operação desejada: Inclusão, Alteração e

Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

a) O gerente financeiro requisita a inclusão de uma conta.

b) O sistema apresenta um formulário em branco para que os detalhes da conta

sejam incluídos.

c) O gerente financeiro informa os detalhes da nova conta.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui a

nova conta; 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 gerente financeiro seleciona uma conta e requisita ao sistema a sua

alteração.

b) O sistema apresenta um formulário preenchido com os detalhes da conta que

foi requisitada.

c) O gerente financeiro altera um ou mais dos detalhes da conta.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados da conta; 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 gerente financeiro seleciona uma conta e requisita ao sistema a sua

exclusão.

b) Se o conta pode 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.

Page 181: Arca Sistema Gerencial

171

Pós-Condições: Uma conta foi inserida ou removida, ou seus detalhes foram

alterados.

Protótipo Tela:

Figura 147: Tela Cadastrar Plano de Conta

Page 182: Arca Sistema Gerencial

172

Diagrama de Robustez:

Figura 148: Diagrama de Robustez Cadastrar Plano de Conta

Page 183: Arca Sistema Gerencial

173

Diagrama de Sequência:

Figura 149: Diagrama de Sequência Cadastrar Plano de Conta

10.1.4 Manter Favorecido (CSU041)

Sumário: O gerente financeiro realiza o cadastro (consulta, inclusão, alteração e

remoção) dos dados sobre os favorecidos.

Page 184: Arca Sistema Gerencial

174

Ator Primário: Gerente Financeiro

Pré-condições: O gerente financeiro deve está autenticado e autorizado no sistema

(Conforme RN001).

Fluxo Principal:

1. O gerente financeiro requisita a manutenção do cadastro de favorecidos.

2. O sistema apresenta listagem dos favorecidos cadastrados com as operações

que podem ser realizadas: inclusão de um novo favorecido, alteração dos

dados dos favorecidos, exclusão de um favorecido.

3. O gerente financeiro indica a operação a realizar ou opta por finalizar o caso

de uso.

4. O gerente financeiro seleciona a operação desejada: Inclusão, Alteração e

Exclusão.

5. O caso de uso retorna ao passo 2.

Fluxo Alternativo (4): Inclusão

a) O gerente financeiro requisita a inclusão de um favorecido.

b) O sistema apresenta um formulário em branco para que os detalhes do

favorecido sejam incluídos.

c) O gerente financeiro informa os detalhes do novo favorecido.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, inclui o

novo favorecido; 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 gerente financeiro seleciona um favorecido e requisita ao sistema a sua

alteração.

b) O sistema apresenta um formulário preenchido com os detalhes do favorecido

que foi requisitado.

c) O gerente financeiro altera um ou mais dos detalhes do favorecido.

d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os

dados do favorecido; 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 gerente financeiro seleciona um favorecido e requisita ao sistema a sua

exclusão.

Page 185: Arca Sistema Gerencial

175

b) Se o favorecido pode 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 favorecido foi inserido ou removido, ou seus detalhes foram

alterados.

Protótipo Tela:

Figura 150: Tela Cadastrar Favorecido

Page 186: Arca Sistema Gerencial

176

Diagrama de Robustez:

Figura 151: Diagrama de Robustez Cadastrar Favorecido

Page 187: Arca Sistema Gerencial

177

Diagrama de Sequência:

Figura 152: Diagrama de Sequência Cadastrar Favorecido

Page 188: Arca Sistema Gerencial

178

10.2 MODELO ESTÁTICO

10.2.1 Modelo de Domínio

Figura 153: Modelo de Domínio do Módulo de Financeiro

Page 189: Arca Sistema Gerencial

179

10.2.2 Diagrama de Classes

Figura 154: Diagrama de Classes do Módulo de Financeiro

Page 190: Arca Sistema Gerencial

180

11 GERAL

11.1 TRIGGER ATUALIZAÇÃO DO SALDO DE ESTOQUE

CREATE TRIGGER "estdocumentoitens_tr_UID" BEFORE INSERT OR UPDATE OR DELETE ON public.estdocumentoitens FOR EACH ROW EXECUTE PROCEDURE public."estdocumentoitens_tr_UID"(); CREATE OR REPLACE FUNCTION public."estdocumentoitens_tr_UID" ( ) RETURNS trigger AS $body$ DECLARE _tipo char(1); _flgcustoultimo integer; _flgcustomedio integer; _flgestorno integer; _flgestoque integer; _flglote integer; _produto varchar(50); _customedio numeric(15,2); _saldo numeric(15,2); _idestdocumento bigint; _idestproduto bigint; _idestalmoxarifado bigint; _qtd numeric(15,2); _qtdmov numeric(15,2); _valorunit numeric(15,2); _idestfabricante bigint; _lote varchar(20); _vencimento timestamp; _row_count bigint; BEGIN /* Carrega as Variáveis de acordo com o tipo */ if (TG_OP = 'UPDATE') or (TG_OP = 'INSERT') then _idestdocumento = NEW.idestdocumento; _idestproduto = NEW.idestproduto; _idestalmoxarifado = NEW.idestalmoxarifado; _qtd = NEW.qtd; _valorunit = NEW.valorunit; _idestfabricante = NEW.idestfabricante; _lote = NEW.lote; _vencimento = NEW.vencimento; else /* EXCLUSÃO - USA OLD */ _idestdocumento = OLD.idestdocumento; _idestproduto = OLD.idestproduto; _idestalmoxarifado = OLD.idestalmoxarifado; _qtd = OLD.qtd; _valorunit = OLD.valorunit; _idestfabricante = OLD.idestfabricante; _lote = OLD.lote; _vencimento = OLD.vencimento; end if; /* Recuperar informacoes do DocumentoTipo */ select t.tipo, t.flgcustoultimo, t.flgcustomedio, t.flgestorno into _tipo, _flgcustoultimo, _flgcustomedio, _flgestorno from estdocumentotipo t inner join estdocumento d on (t.idestdocumentotipo = d.idestdocumentotipo) where

Page 191: Arca Sistema Gerencial

181

d.idestdocumento = _idestdocumento and t.flgativo = 1; IF NOT FOUND THEN RAISE EXCEPTION 'Nenhum registro encontrado(documento / documentotipo).'; END IF; /* Recuperar informacoes do produto e almoxarifado */ select p.flgestoque, p.flglote, p.produto, p.customedio, p.saldo into _flgestoque, _flglote, _produto, _customedio, _saldo from estproduto p inner join estprodutoalmoxarifado pa on (pa.idestproduto = p.idestproduto) where p.flgativo = 1 and pa.idestproduto = _idestproduto and pa.idestalmoxarifado = _idestalmoxarifado; IF NOT FOUND THEN RAISE EXCEPTION 'Produto % não vinculado ao almoxarifado %.', _idestproduto, _idestalmoxarifado; END IF; IF _flgestoque = 1 THEN /* QUANTIDADE MOVIMENTADA */ _qtdmov = 0; if (TG_OP = 'INSERT') then _qtdmov = _qtdmov + NEW.qtd; end if; if (TG_OP = 'UPDATE') then _qtdmov = _qtdmov - OLD.qtd; _qtdmov = _qtdmov + NEW.qtd; end if; if (TG_OP = 'DELETE') then _qtdmov = _qtdmov - OLD.qtd; end if; /* ATUALIZA O SALDO DO PRODUTO */ update estproduto set saldo = saldo + _qtdmov where idestproduto = _idestproduto; /* ATUALIZA O SALDO DO PRODUTO NO ALMOXARIFADO */ update estprodutoalmoxarifado set saldo = saldo + _qtdmov where idestproduto = _idestproduto and idestalmoxarifado = _idestalmoxarifado; /* ATUALIZAR SALDO LOTE */ IF _flglote = 1 THEN if (_qtdmov > 0) then if not exists ( select lote from estprodutolote where idestproduto = _idestproduto and idestalmoxarifado = _idestalmoxarifado and idestfabricante = _idestfabricante and lote = _lote ) then insert into estprodutolote (idestproduto, idestalmoxarifado, idestfabricante, lote, vencimento, saldo) values (_idestproduto, _idestalmoxarifado, _idestfabricante, _lote, _vencimento, _qtdmov); else update estprodutolote set saldo = saldo + _qtdmov where idestproduto = _idestproduto and idestalmoxarifado = _idestalmoxarifado and idestfabricante = _idestfabricante and lote = _lote; end if; else update estprodutolote set saldo = saldo + _qtdmov where idestproduto = _idestproduto and idestalmoxarifado = _idestalmoxarifado and idestfabricante = _idestfabricante and lote = _lote; GET DIAGNOSTICS _row_count = ROW_COUNT; if (_row_count = 0) then RAISE EXCEPTION 'Lote % não encotrado para o produto %.', _lote, _idestproduto; end if; end if; if (_tipo = 'T') then if (_tipo = 'E') then

Page 192: Arca Sistema Gerencial

182

if not exists ( select lote from estprodutolote where idestproduto = _idestproduto and idestalmoxarifado = _idestalmoxarifado and idestfabricante = _idestfabricante and lote = _lote ) then insert into estprodutolote (idestproduto, idestalmoxarifado, idestfabricante, lote, vencimento, saldo) values (_idestproduto, _idestalmoxarifado, _idestfabricante, _lote, _vencimento, _qtdmov); else update estprodutolote set saldo = saldo + _qtdmov where idestproduto = _idestproduto and idestalmoxarifado = _idestalmoxarifado and idestfabricante = _idestfabricante and lote = _lote; end if; end if; if (_tipo = 'S') then update estprodutolote set saldo = saldo + _qtdmov where idestproduto = _idestproduto and idestalmoxarifado = _idestalmoxarifado and idestfabricante = _idestfabricante and lote = _lote; GET DIAGNOSTICS _row_count = ROW_COUNT; if (_row_count = 0) then RAISE EXCEPTION 'Lote % não encotrado para o produto %.', _lote, _idestproduto; end if; end if; end if; END IF; END IF; -- End Atualizar _flgestoque /* ATUALIZA O ULTIMO CUSTO */ IF _flgcustoultimo = 1 THEN update estproduto set custoultimo = _valorunit where idestproduto = _idestproduto; END IF; /* ATUALIZA CUSTO MÉDIO */ IF _flgcustomedio = 1 THEN /* Evitar divisão por 0*/ IF _qtd + _saldo = 0 THEN update estproduto set customedio = 0 where idestproduto = _idestproduto; ELSE update estproduto set customedio = ((_valorunit * _qtd) + (_customedio * _saldo)) / (_qtd + _saldo) where idestproduto = _idestproduto; END IF; END IF; /* Atribuição do retorno */ if (TG_OP = 'DELETE') then RETURN OLD; else RETURN NEW; end if; EXCEPTION WHEN OTHERS THEN RAISE EXCEPTION '%', SQLERRM; END; $body$ LANGUAGE 'plpgsql' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100; CREATE TRIGGER "estprodutoalmoxarifado_tr_UID" BEFORE INSERT OR UPDATE OR DELETE ON public.estprodutoalmoxarifado FOR EACH ROW EXECUTE PROCEDURE public."estprodutoalmoxarifado_tr_UID"(); CREATE OR REPLACE FUNCTION public."estprodutoalmoxarifado_tr_UID" ( ) RETURNS trigger AS $body$ DECLARE _idestalmoxarifado bigint; _idestproduto bigint; _flginversao integer;

Page 193: Arca Sistema Gerencial

183

_saldo numeric(15,3); BEGIN /* Carrega as Variáveis de acordo com o tipo */ if (TG_OP = 'UPDATE') or (TG_OP = 'INSERT') then _idestalmoxarifado = NEW.idestalmoxarifado; _idestproduto = NEW.idestproduto; _saldo = NEW.saldo; else /* EXCLUSÃO - USA OLD */ _idestalmoxarifado = OLD.idestalmoxarifado; _idestproduto = OLD.idestproduto; _saldo = OLD.saldo; end if; if (_saldo < 0) then select flginversao into _flginversao from estalmoxarifado where idestalmoxarifado = _idestalmoxarifado; if (_flginversao <> 1) then RAISE EXCEPTION 'Almoxarifado % não permiti inversão de saldo (produto %).', _idestalmoxarifado, _idestproduto; end if; end if; /* Atribuição do retorno */ if (TG_OP = 'DELETE') then RETURN OLD; else RETURN NEW; end if; EXCEPTION WHEN OTHERS THEN RAISE EXCEPTION '%', SQLERRM; END; $body$ LANGUAGE 'plpgsql' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100;

Page 194: Arca Sistema Gerencial

184

11.2 DIAGRAMA DE MODELO DE DOMÍNIO

Page 195: Arca Sistema Gerencial

185

11.3 DER

Page 196: Arca Sistema Gerencial

186

12 CONSIDERAÇÕES FINAIS

A proposta deste trabalho, é a analise e desenvolvimento de um sistema web,

que teve como objetivo resolver as necessidades existentes na empresa AMI

(Assistência Médica Infantil) Vacinas.

Pode-se dizer que o desenvolvimento do sistema apresentado requer muita

dedicação da equipe. Foram utilizadas no sistema diversas tecnologias que foram

vistas ao longo do curso e foram de extrema importância para a realização do

projeto. Para que as aplicações futuras possam ser desenvolvidas com base neste

trabalho, sugere-se a utilização de programação orientada a objetos, linguagem de

programação JAVA, tendo em vista sua segurança e robustez, além de outros

fatores tecnológicos apresentados.

Para tanto, foi realizado diversas pesquisas bibliográficas com o objetivo

conseguir o maior conhecimento sobre as tecnologias, arquitetura e metodologias

aplicadas neste trabalho.

Considera-se também, que existiram funcionalidades do sistema que foram

selecionadas para serem desenvolvidas futuramente, em virtude de mudanças no

cronograma.

Observando a implantação deste novo sistema, a empresa citada consegue

dar o primeiro passo de melhoria para continuidade dos seus negócios. Com o

sistema implantado, a empresa poderá mensurar de maneira mais adequada os

seus processos, resultando em benefícios importantes para empresa.

Portanto conclui-se que, o sistema desenvolvido e que foi apresentado neste

trabalho, resultará em grandiosos benefícios para empresa AMI (Assistência Médica

Infantil) Vacinas, possibilitando um maior gerenciamento dos processos da empresa

e consequentemente um melhor serviço para sociedade que necessita deste

serviço.

Page 197: Arca Sistema Gerencial

187

REFERÊNCIAS

AMI Vacinas - Quem somos. Disponível em: <http://www.aminatal.com.br/>.

Acesso em: 18 mar. 2012.

BECK, Kent. Extreme Programming Explained: Embrace change. Reading

Massachusetts: Ed. Addison-Wesley, 2000.

BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. Rio

de Janeiro: Elsevier, 2003.

Code Conventions for the Java TM Programming Language. Disponível em:

<http://www.oracle.com/technetwork/java/codeconvtoc-136057.html>. Acesso em: 03 abr. 2012.

COIMBRA, Ewerton. Desenvolvimento para web com java. Florianópolis: Visual Books, 2010.

Conformidade com o Padrão SQL. Disponível em:

<http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html>. Acesso em: 10 abr. 2012.

Core J2EE Patterns - Data Access Object. Disponível em:

<http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html>. Acesso em: 09 abr. 2012.

EVANS, Cal. Guia para Programação com Framework Zend. Rio de Janeiro:

Editora Ciência Moderna, 2008.

FERNANDES, T. M., Vacina Antivariólica: Ciência, Técnica e o Poder dos Homens. Rio de Janeiro: Editora Fiocruz, 1999.

FOWLER, Martin. Padrões de Arquitetura de Aplicações Corporativas. Porto

Alegre: Bookman, 2006.

Page 198: Arca Sistema Gerencial

188

GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Padrões de projeto: soluções reutilizáveis de software orientado a objetos. Porto Alegre:

Bookman, 2000.

GEARY, David; HORSTMAN, Cay. Core JavaServer Faces Fundamentos. 2ª ed.

Rio de Janeiro: Alta Books, 2007.

GEARY, David; HORSTMAN, Cay. Core JavaServer Faces Fundamentos. 3ª ed.

Rio de Janeiro: Alta Books, 2012.

GONÇALVES, Edson. Desenvolvendo Aplicações Web com JSP, Servlets, JavaServer Faces, Hibernate, EJB Persistence e Ajax. Rio de Janeiro: Editora Ciência Moderna, 2007.

GONÇALVES, Edson. Dominando Java Server Faces e Facelets Utilizando Spring 2.5, Hibernate e JPA. Rio de Janeiro: Editora Ciência Moderna, 2008.

History of Java Technology. Disponível em:

<http://www.oracle.com/technetwork/java/javase/overview/javahistory-index-198355.html>. Acesso em: 24 mar. 2012.

ICEFaces JSF Framework Overview - ICEsoft Technologies. Disponível em:

<http://www.icesoft.org/projects/ICEfaces/overview.jsf>. Acesso em: 25 mar. 2012.

Java Specification Requests - detail JSR 127: JavaServer Faces. Disponível em:

<http://www.jcp.org/en/jsr/detail?id=127>. Acesso em: 24 mar. 2012.

JavaServer Faces Technology. Disponível em:

<http://pgdocptbr.sourceforge.net/pg80/features.html>. Acesso em: 24 mar. 2012.

LAMIM, Jonathan. MVC - O padrão de arquitetura de software. 2009. Disponível

em: <http://www.oficinadanet.com.br/artigo/1687/mvc_-_o_padrao_de_arquitetura_de_software>. Acesso em: 09 abr. 2012.

Page 199: Arca Sistema Gerencial

189

LUCKOW, Décio Heinzelman; MELO, Alexandre Altair de. Programação Java para a Web. São Paulo: Novatec Editora, 2010.

MAIA, José Anísio. Construindo Softwares com Qualidade e Rapidez Usando ICONIX. 2005. Disponível em:

<http://www.guj.com.br/content/articles/patterns/iconix_guj.pdf>. Acesso em: 09 abr. 2012.

MILANI, André. PostgreSQL: guia do programador. São Paulo: Novatec Editora,

2008.

MOREIRA, Anderson Luiz Souza. Padrão de Codificação Java. Disponível em: <http://siep.ifpe.edu.br/anderson/blog/?page_id=950>. Acesso em: 03 abr. 2012.

NETO, Oziel Moreira. Melhores práticas no desenvolvimento Java. Disponível

em: <http://www.oziel.com.br/tutoriais/BoasPraticasJavaEE.pdf>. Acesso em: 03 abr. 2012.

Portal da Saúde - Vacinação. Disponível em:

<http://portal.saude.gov.br/portal/saude/profissional/area.cfm?id_area=1448>. Acesso em: 07 abr. 2012.

Portal da Saúde - Vacinas. Disponível em:

<http://www.portalsaofrancisco.com.br/alfa/vacinas/vacinacao.php>. Acesso em: 07 abr. 2012.

PrimeFaces. Disponível em: <http://primefaces.org/whyprimefaces.html>. Acesso

em: 25 mar. 2012.

Programa Nacional de Imunizações. Disponível em:

<http://portal.saude.gov.br/portal/arquivos/pdf/livro_30_anos_pni.pdf>. Acesso em: 01 abr. 2012.

RIBEIRO, M. A. R. Saúde pública e as empresas químico-farmacêuticas.

História, Ciências, Saúde - Manguinhos, Vol VII, 2001, p.607-626.

Page 200: Arca Sistema Gerencial

190

RichFaces Project Page - JBoss Community. Disponível em:

<http://www.jboss.org/richfaces>. Acesso em: 25 mar. 2012.

ROSENBERG, Doug; SCOTT, Kendall. Use Case Driven Object Modeling with UML: A Practical approach. Massachusetts: Addison-Wesley Longman, 1999.

ROSENBERG, Doug; STEPHENS, Matt; COPE, Mark. Agile Development with Iconix Process. Apress, 2005.

SINTES, Tony. Aprenda Programação Orientada a Objetos em 21 Dias. São

Paulo: Pearson Education do Brasil, 2002.

SOMMERVILLE, Ian. Engenharia de Software. 6ª. ed. São Paulo: Addison Wesley,

2003.

The Java Community Process. Disponível em: <http://www.jcp.org/>. Acesso em:

23 mar. 2012.

Page 201: Arca Sistema Gerencial

191

APÊNDICES

Page 202: Arca Sistema Gerencial

192

APÊNDICE A - Check List de Implantação

Page 203: Arca Sistema Gerencial

193

APÊNDICE B – Revisões e Estatísticas do Controle de Versões

Page 204: Arca Sistema Gerencial

194

Page 205: Arca Sistema Gerencial

195

APÊNDICE B - Diário de Bordo da Implementação (último semestre)

2012-12-02 Corrigir estrato de estoque 2012-12-02 Incluir rotina de Previsão de Transferência 2012-11-29 Correção do recebimento para permitir receber valor 0. 2012-11-29 Consulta de Recebimento por Moeda 2012-11-22 Correção de error na geração do cartao da 2012-11-22 Correção de error no recebimento 2012-11-21 Relatório de Crédito de Cartões 2012-11-21 Relatório de Aplicações Pendentes 2012-11-21 Correção do Relatório de Extrato de Estoque 2012-11-19 Relatório de Extrato de estoque 2012-11-16 Correção do error: This Managed Connection is not valid as the physical connection is not usable / Unable to complete container-managed transaction 2012-11-15 Serviço mensagem de aviso de vácinas pendentes/ou sugeridas (AMI AVISA) 2012-11-15 Sugerir vacinas no atendimento 2012-11-14 Vinculação de Produto a Vacina - continuação 2012-11-14 Mudar ordenação no cadastro de esquema de vacinação - vacinas 2012-11-12 Vinculação de Produto a Vacina 2012-11-12 Esquema de Vacinação 2012-11-12 Correção de error ao entrar no cadastro de formas de pagamento 2012-11-09 Correção de Ordenar o map de filtragem 2012-11-09 Relatório de Vencimento de Produtos 2012-11-09 Possibilidade de Subtitulo e passagem de parametros de filtragem para o relatório 2012-11-08 Relatório de Indicações por Médico 2012-11-08 Colocar dialogo modal para escolha de lote nos documentos de estoque 2012-11-08 Documento de Estoque: Permitir visualizar os documentos transferidos 2012-11-08 Corrigir a consulta de documentos de estoque 2012-11-07 Disparar e-mail de falha no login 2012-11-06 Adicionar e-mail no cadastro de usuários do sistema 2012-11-06 Correção do estoro do pool de conexão ocasionado pela geração de relatório 2012-11-06 Enviar log de error por e-mail para acompanhar a demanda 2012-11-06 Corrigir error no calculo da idade = 643 ==== 06/12/2009 ==== 22/10/2012 2012-11-06 Serviço de Email, adicionar a possibilidade de enviar anexo. 2012-11-05 Relatório de Informe de Vacinação 2012-11-05 Serviço de envio de e-mail utilizando JMS 2012-11-03 Informe de Aplicações 2012-11-03 Serializar os DAOS 2012-11-02 Transforme componentes de negócios em EJB; 2012-10-25--11-03 Migração para EJB 2012-10-25 Relatório Saldo inicial em estoque 2012-10-24 Zerar pré-pago antigo na contabilização 2012-10-21 Modificar o recebimento dos pré-pagos 2012-10-21 Adicionar filtro no cadastro de cliente 2012-10-21 Adicionar filtro no cadastro de médico 2012-10-21 Permitir cancelar venda 2012-10-21 Permitir editar recebimento 2012-10-21 Juntar o recebimento com o historico do recebimento em um só 2012-10-18 Permitir exibir detalhes do recebimento e da venda no histórico 2012-10-18 Inclusão do histórico de compras no atendimento 2012-10-18 Permitir exibir detalhes do recebimento no pré-fechamento 2012-10-18 Permitir exibir detalhes da venda no pré-fechamento 2012-10-18 Consulta de Documentos de estoque - continuação 2012-10-16 Consulta de Documentos de estoque 2012-10-16 Relatório de Análise ABC de vendas 2012-10-16 Relatório de Evolução de vendas 2012-10-16 Relatório de Vendas - continuação 2012-10-15 Relatório de Vendas 2012-10-15 Avisar quando o caixa for diferente da data atual 2012-10-15 Não trazer o combo de caixa preenchido se tiver mais de um caixa ou se o caixa diferente do atual 2012-10-15 Adicionar resumo de correntista na tela de pre e encerramento 2012-10-15 Correção de error após um recebimento com error 2012-10-15 Correção de cotexto do cookie em produção 2012-10-15 Rotina no ClienteSaldoBO para retorna o saldo atual 2012-10-14 Controle de correntista - quitar conta a receber 2012-10-14 Correção de problema na inclusão de Tabela de Preços X Forma Pag., está apagando Tabela de Preços X Valor Total 2012-10-14 Controle de correntista - conta a receber 2012-10-14 Não permitir modificar as contas vinculadas a correntista 2012-10-13 Correçção do locate do ireport; 2012-10-13 Mudar forma de selecionar cliente; 2012-10-12 Adiciona Cadastro de Tabela de Preços X Valor Total - continuação; 2012-10-12 Adiciona Cadastro de Tabela de Preços X Valor Total; 2012-10-12 melhoria na consulta de caixa; 2012-10-12 Adicionar abreviação para almoxarifado; 2012-10-12 Refazer o encerramento de caixa - continuação; 2012-10-12 Relatório de saldo de estoque agrupado por almoxarifado; 2012-10-12 Relatório de saldo de estoque agrupado por empresa; 2012-10-10 Juntar cliente duplicados; 2012-10-10 Refazer o encerramento de caixa - continuação; 2012-10-09 Refazer o encerramento de caixa; 2012-10-09 Pré-encerramento de caixa 2012-10-09 Armazer a empresa em um cookie para evitar de entrar na empresa errada; 2012-10-08 Refeito a abertura de caixa; 2012-10-06 No cadastro de cliente, validar nome/pai/mae/e-mail com Regex; 2012-10-06 Alterar tabela de preco na tela de recebimento 2012-10-06 Permitir editar cliente da tela de atendimento 2012-10-06 Permitir mudar empresa sem precisar sair do sistema 2012-10-05 Operação de Perca em Francionamento de Produto 2012-10-05 Operação de Francionamento de Produto 2012-10-04 Relatorio Conferência de Cartão de Crédito 2012-10-03 Consulta de Aplicações de vacinas 2012-10-03 Incluir edição de recebimento mantendo o vinculado com as contas 2012-10-03 Incluir cancelamento de venda 2012-10-02 Correção da trigger de estoque na contabilização dos lotes na transferencia 2012-10-02 Correção de problema ao editar Venda 2012-10-01 Correção de Pendencias das Unidades 2012-10-01 Corrigir lotes de transferencia 2012-10-01 Corrigir relatório de fechamento 2012-10-01 Exibir itens no almoxarifado mesmo sem ter estoque 2012-10-01 Correção da tabela de preço ao voltar na venda 2012-10-01 Trazer os lotes disponíveis no ato da venda 2012-10-01 Permitir modificar venda no ato do recebimento 2012-09-30 Keep Mensage entre os beans. 2012-09-30 Trazer os lotes no ato na aplicação. 2012-09-29 Correção do invalidate de sessão 2012-09-29 Correção da Trigger, error ao cadastrar o saldo do lote 2012-09-29 Correção do cadastro de empresa. 2012-09-29 Adicionado Filtro por Almoxarifado, empresa e produto no relatório de saldo de estoque 2012-09-28 Relatório de saldo de estoque por produto 2012-09-28 Mudar Ajax Load em virtude de problema com campo do tipo data 2012-09-28 Limpar informações de lote na nota de entrada, saída e transferencia 2012-09-27 Logar geração de Relatórios 2012-09-27 Unique index para Médido: CRM + UF 2012-09-27 Ao mandar imprimir, enviar os dados da empresa corrente. 2012-09-27 Validar E-mail com Regex; 2012-09-27 Selecionar cliente pelo Código 2012-09-27 Remover ? do cadastro de usuário 2012-09-27 Correção de problema ao salva preço de tabela de preço 2012-09-26 Substitui os converts pelo Generic 2012-09-26 Criado convert Generic para OBJETOS 2012-09-26 Problema com fechamento de conexão - continuação 2012-09-25 Problema com fechamento de conexão 2012-09-25 Adicionado Pool de conexão com c3p0 2012-09-24 Adicionar cliente no relarório de documento de estoque 2012-09-24 Cadastro Aplicação de vacina - continuação 2012-09-24 Logando o objeto que estava tentado salvar ao ocorre error 2012-09-23 Cadastro de Almoxarifados - Adicionado flag de controle para almoxarifados que permitem venda 2012-09-23 Cadastro Aplicação de vacina - continuação 2012-09-22 Injeção de dependencia por daoFactory em DocumentoBO, VendaBO, RecebBO 2012-09-22 Cadastro Aplicação de vacina - continuação

Page 206: Arca Sistema Gerencial

196

2012-09-22 Adaptar a venda para pedir o número da dose 2012-09-21 Adcionada funções para validação e validator para CPF e CNPJ 2012-09-21 Cadastro Aplicação de vacina 2012-09-21 Cadastro de Forma de Pagamento - inclusão do cartão de crédito 2012-09-21 Cadastro de Bandeira de Cartão de Crédito 2012-09-21 Adaptação para integração com a base de dados existente em produção 2012-09-20 Correção de error que ocorria ao acessar página não permitida 2012-09-19 Integração com a tela de atendimento 2012-09-19 Cadastro simplificado de cliente 2012-09-19 Correção de problema na transição de páginas ajax - continuação 2012-09-18 Correção de problema na transição de páginas ajax 2012-09-18 Correção do documento de estorno 2012-09-17 Criação do recebimento de vendas parcelas - continuação 2012-09-16 Criação do recebimento de vendas parcelas - continuação 2012-09-16 Criação do recebimento de vendas - continuação 2012-09-16 Correção de problema com carga de itens em Venda, Documento e Recebimento, ocasionada por EAGER - continuação 2012-09-15 Correção de problema com carga de itens em Venda, Documento e Recebimento, ocasionada por EAGER 2012-09-14 Criação do recebimento de vendas - continuação 2012-09-13 Analisando uma estrutura para cadastro de vacina; 2012-09-13 Função JAVA para calculo de idade 2012-09-13 Criação do recebimento de vendas - continuação 2012-09-12 Criação do recebimento de vendas 2012-09-11 Atualização da estrutura do banco(Recebimento e Cartao de Vacinação) 2012-09-11 Criação do ConversationUtil para suprir deficiente de CDI do JSF 2012-09-10 Criação do cadastro de venda - Editar 2012-09-10 Criação do cadastro de venda - Finalização 2012-09-10 Criação do cadastro de venda - Itens - continuação 2012-09-10 Correção do javascript de formatação de DATA/MOEDA/INTEIRO 2012-09-09 Criação do cadastro de venda - Itens 2012-09-09 Criação do cadastro de venda - Cabeçalho - continuação 2012-09-08 Criação do cadastro de venda - Cabeçalho 2012-09-08 Adicionado link adicional no admpermissao 2012-09-08 Mudar estrutura da tabela vacVenda para atender o solicitado 2012-09-08 Criação do cadastro de atendimento - selecionar cliente - continuação 2012-09-07 Criação do cadastro de atendimento - selecionar cliente 2012-09-07 Otimização do DaoGeneric para realização de consulta dinâmica 2012-09-07 Cadastro de cliente: Não trazer default para sexo 2012-09-07 Adicionar validação de idade no cadastro de cliente 2012-09-05 Criação do cadastro de tabela preços X formas pag. 2012-09-05 Criação do cadastro de formas de recebimento - continuação. 2012-09-04 Otimização do genericDAO adicionando a coluna de ordenação nele. 2012-09-04 Criação do cadastro de formas de recebimento - continuação. 2012-09-03 Criação do cadastro de formas de recebimento. 2012-09-03 Otimização da persistencia de objetos: Utilizando a rotina correta(insert ou update) em vez do merge e recuperando o id. 2012-09-03 Colocar Painel Div em volta dos botões 2012-08-30 Criação do cadastro de preços produto - continuação 2012-08-30 Criação do cadastro de preços produto 2012-08-30 Criação do cadastro de preços tabela - continuação 2012-08-29 Criação do cadastro de preços tabela 2012-08-29 Correção dos converts de forClass para Value 2012-08-29 Adicionado campo que estava falatando em Cadastro de Vacinadores 2012-08-29 Correção do Cadastro de Tabela de Preços 2012-08-29 Correção do Cadastro de Itens de Menu 2012-08-21 Cadastro de Itens de Menu - correção 2012-08-21 Cadastro de Almoxarifado X Produto - continuação 2012-08-21 Cadastro de Almoxarifado X Produto 2012-08-21 Cadastro de Produto - continuação 2012-08-20 Cadastro de Produto 2012-08-19 Organizar CSS, chamar os arquivos separado para evitar reload; 2012-08-18 Corrigir UI para puxar list 2012-08-18 Mudança nos módulos para iniciar com 3 letras 2012-08-18 Mudança visul nos campos obrigatórios 2012-08-18 Cadastro de Caixa 2012-08-14 Trabalhando no DER - continuação 2012-08-14 Criação de componentes PS para data e numeric - continuação 2012-08-12 Criação de componentes PS para data e numeric 2012-08-12 Desacopla DAOFatory 2012-08-04 Trabalhando no DER - continuação 2012-08-03 Trabalhando no DER - continuação 2012-08-02 Trabalhando no DER


Top Related