Arca Sistema Gerencial

  • 166 views
Uploaded on

Trabalho de conclusão de curso sobre o Sistema Gerencial ARCA, voltado para controle de vacinação utilizando as tecnologias JAVA com JSF, Hibernate, etc. …

Trabalho de conclusão de curso sobre o Sistema Gerencial ARCA, voltado para controle de vacinação utilizando as tecnologias JAVA com JSF, Hibernate, etc.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
166
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
10
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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
  • 2. 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
  • 3. 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
  • 4. 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.
  • 5. 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.
  • 6. 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
  • 7. 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.
  • 8. 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.
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. LISTA DE ABREVIAÇÕES E SIGLAS AJAX Asynchronous Javascript and XML AMI Assistência Médica Infantil ASF Apache Software Foundation BO Business Object DAO Data Access Object EE Enterprise Edition EJB Enterprise Java Beans EUA Estados Unidos da América FW Framework GUI Graphical User Interface IDE Integrated Development Environment ISO International Organization for Standardization J2EE Java 2 Platform, Enterprise Edition JCP Java Community Process JDBC Java Database Connectivity JPA Java Persistente API JSF JavaServer Faces JSP JavaServer Pages JSR Java Specification Requests MVC Model-view-controller OO Orientação a Objetos ORM Object Relacional Mapping PNI Programa Nacional de Imunizações POJO Plain Old Java Objects POO Programação Orientada a Objetos RI Reference Implementation RUP Rational Unified Processes SGBDSistema Gerenciador de Banco de Dados SQL Structured Query Language UI Users Interface UML Linguagem de Modelagem Unificada XP Extreme Programming
  • 15. 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
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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.
  • 20. 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.
  • 21. 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).
  • 22. 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.
  • 23. 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)
  • 24. 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)
  • 25. 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.
  • 26. 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).
  • 27. 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:
  • 28. 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
  • 29. 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.
  • 30. 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.”
  • 31. 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
  • 32. 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.
  • 33. 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.
  • 34. 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)
  • 35. 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.
  • 36. 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.
  • 37. 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
  • 38. 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
  • 39. 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
  • 40. 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).
  • 41. 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)
  • 42. 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
  • 43. 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.
  • 44. 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:
  • 45. 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;
  • 46. 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;
  • 47. 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
  • 48. 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
  • 49. 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;
  • 50. 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.
  • 51. 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é.
  • 52. 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
  • 53. 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.
  • 54. 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
  • 55. 45 Diagrama de Robustez: Figura 9: Diagrama de Robustez Fazer Login Diagrama de Sequência: Figura 10: Diagrama de Sequência Fazer Login
  • 56. 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
  • 57. 47 Diagrama de Robustez: Figura 12: Diagrama de Robustez Alterar Senha Diagrama de Sequência: Figura 13: Diagrama de Sequência Alterar Senha
  • 58. 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.
  • 59. 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
  • 60. 50 Diagrama de Robustez: Figura 15: Diagrama de Robustez Cadastrar Empresa
  • 61. 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).
  • 62. 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.
  • 63. 53 Protótipo Tela: Figura 17: Tela Cadastrar Módulo Diagrama de Robustez: Figura 18: Diagrama de Robustez Cadastrar Módulo
  • 64. 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.
  • 65. 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.
  • 66. 56 Protótipo Tela: Figura 20: Tela Cadastrar Nível Diagrama de Robustez: Figura 21: Diagrama de Robustez Cadastrar Nível
  • 67. 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
  • 68. 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.
  • 69. 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
  • 70. 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).
  • 71. 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.
  • 72. 62 Protótipo Tela: Figura 26: Tela Cadastrar Menu Item Diagrama de Robustez: Figura 27: Diagrama de Robustez Cadastrar Menu Item
  • 73. 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).
  • 74. 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.
  • 75. 65 Protótipo Tela: Figura 29: Tela Cadastrar Usuário Diagrama de Robustez: Figura 30: Diagrama de Robustez Cadastrar Usuário
  • 76. 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.
  • 77. 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
  • 78. 68 Diagrama de Robustez: Figura 33: Diagrama de Robustez Alternar Empresa Diagrama de Sequência: Figura 34: Diagrama de Sequência Alternar Empresa
  • 79. 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
  • 80. 70 Diagrama de Robustez: Figura 36: Diagrama de Robustez Consultar Logs Diagrama de Sequência: Figura 37: Diagrama de Sequência Consultar Logs
  • 81. 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
  • 82. 72 Diagrama de Sequência: Figura 40: Diagrama de Sequência Notificar Falha no Login
  • 83. 73 7.2 MODELO ESTÁTICO 7.2.1 Modelo de Domínio Figura 41: Modelo de Domínio do Módulo Administrativo
  • 84. 74 7.2.2 Diagrama de Classes Figura 42: Diagrama de Classes do Módulo Administrativo
  • 85. 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.
  • 86. 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.
  • 87. 77 Protótipo Tela: Figura 44: Tela Cadastrar Unidade Diagrama de Robustez: Figura 45: Diagrama de Robustez Cadastrar Unidade
  • 88. 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).
  • 89. 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.
  • 90. 80 Protótipo Tela: Figura 47: Tela Cadastrar Produto Diagrama de Robustez: Figura 48: Diagrama de Robustez Cadastrar Produto
  • 91. 81 Diagrama de Sequência: Figura 49: Diagrama de Sequência Cadastrar Produto
  • 92. 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.
  • 93. 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
  • 94. 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:
  • 95. 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.
  • 96. 86 Protótipo Tela: Figura 53: Tela Cadastrar Almoxarifado Diagrama de Robustez: Figura 54: Diagrama de Robustez Cadastrar Almoxarifado
  • 97. 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
  • 98. 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.
  • 99. 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
  • 100. 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).
  • 101. 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.
  • 102. 92 Protótipo Tela: Figura 59: Tela Cadastrar Fornecedor
  • 103. 93 Diagrama de Robustez: Figura 60: Diagrama de Robustez Cadastrar Fornecedor
  • 104. 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).
  • 105. 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
  • 106. 96 Figura 63: Tela Cadastrar Nota de Almoxarifado - Etapa 2 Figura 64: Tela Cadastrar Nota de Almoxarifado - Informações Lote/Vencimento
  • 107. 97 Figura 65: Tela Cadastrar Nota de Almoxarifado - Impressão de Nota Estoque Diagrama de Robustez: Figura 66: Diagrama de Robustez Nota de Almoxarifado
  • 108. 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.
  • 109. 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:
  • 110. 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.
  • 111. 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
  • 112. 102 Figura 72: Tela Cadastrar Nota de Transferência - Etapa 2 Figura 73: Tela Cadastrar Nota de Transferência - Impressão
  • 113. 103 Diagrama de Robustez: Figura 74: Diagrama de Robustez Nota de Transferência de Almoxarifado
  • 114. 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.
  • 115. 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:
  • 116. 106 Figura 78: Diagrama de Robustez Relatório de Saldo
  • 117. 107 Diagrama de Sequência: Figura 79: Diagrama de Sequência Relatório de Saldo
  • 118. 108 8.2 MODELO ESTÁTICO 8.2.1 Modelo de Domínio Figura 80: Modelo de Domínio do Módulo Estoque
  • 119. 109 8.2.2 Diagrama de Classes Figura 81: Diagrama de Classes do Módulo Estoque
  • 120. 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
  • 121. 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
  • 122. 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
  • 123. 113 Diagrama de Robustez: Figura 84: Diagrama de Robustez Cadastrar Cliente
  • 124. 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).
  • 125. 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.
  • 126. 116 Protótipo Tela: Figura 86: Tela Cadastrar Médico Diagrama de Robustez: Figura 87: Diagrama de Robustez Cadastrar Médico
  • 127. 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).
  • 128. 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.
  • 129. 119 Protótipo Tela: Figura 89: Tela Cadastrar Vacinador Diagrama de Robustez: Figura 90: Diagrama de Robustez Cadastrar Vacinador
  • 130. 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
  • 131. 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.
  • 132. 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
  • 133. 123 Diagrama de Robustez: Figura 93: Diagrama de Robustez Cadastrar Tabela de Preço
  • 134. 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
  • 135. 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.
  • 136. 126 Protótipo Tela: Figura 95: Tela Cadastrar Vacina Diagrama de Robustez: Figura 96: Diagrama de Robustez Cadastrar Vacina
  • 137. 127 Diagrama de Sequência: Figura 97: Diagrama de Sequência Cadastrar Vacina
  • 138. 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.
  • 139. 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
  • 140. 130 Diagrama de Sequência: Figura 100: Diagrama de Sequência Cadastrar Bandeira de Cartão de Crédito
  • 141. 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.
  • 142. 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
  • 143. 133 Diagrama de Robustez: Figura 102: Diagrama de Robustez Cadastrar Forma de Pagamento
  • 144. 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
  • 145. 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
  • 146. 136 Diagrama de Robustez: Figura 105: Diagrama de Robustez Esquema de Vacina
  • 147. 137 Diagrama de Sequência: Figura 106: Diagrama de Sequência Esquema de Vacina
  • 148. 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
  • 149. 139 Diagrama de Robustez: Figura 108: Diagrama de Robustez Abrir Caixa Diagrama de Sequência: Figura 109: Diagrama de Sequência Abrir Caixa
  • 150. 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
  • 151. 141 Figura 111: Tela Encerrar Caixa - Conferência Cartão Figura 112: Tela Encerrar Caixa - Visualizar Venda
  • 152. 142 Diagrama de Robustez: Figura 113: Diagrama de Robustez Encerrar Caixa
  • 153. 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:
  • 154. 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
  • 155. 145 Figura 117: Tela Cadastrar Venda - Selecionar Cliente
  • 156. 146 Diagrama de Robustez: Figura 118: Diagrama de Robustez Venda
  • 157. 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.
  • 158. 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
  • 159. 149 Figura 122: Tela Realizar Recebimento - Alterar Tabela de Preço Figura 123: Tela Realizar Recebimento - Selecionar Conta do Cliente
  • 160. 150 Diagrama de Robustez: Figura 124: Diagrama de Robustez Realizar Recebimento
  • 161. 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.
  • 162. 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
  • 163. 153 Diagrama de Robustez: Figura 128: Diagrama de Robustez Realizar Aplicação
  • 164. 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.
  • 165. 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
  • 166. 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.
  • 167. 157 Protótipo de Notificação: Figura 133: Mensagem de Notificação Vacina Pendente / Indicada
  • 168. 158 Diagrama de Robustez: Figura 134: Diagrama de Robustez Notificar Vacina Pendente / Indicada
  • 169. 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.
  • 170. 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
  • 171. 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.
  • 172. 162 Diagrama de Robustez: Figura 139: Diagrama de Notificação Gerencial Diagrama de Sequência: Figura 140: Diagrama de Sequência Notificação Gerencial
  • 173. 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
  • 174. 164 9.2.2 Diagrama de Classes Figura 142: Diagrama de Classes do Módulo de Vacinação
  • 175. 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
  • 176. 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.
  • 177. 167 Pós-Condições: Um caixa foi inserido ou removido, ou seus detalhes foram alterados. Protótipo Tela: Figura 144: Tela Cadastrar Caixa
  • 178. 168 Diagrama de Robustez: Figura 145: Diagrama de Robustez Cadastrar Caixa
  • 179. 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
  • 180. 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.
  • 181. 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
  • 182. 172 Diagrama de Robustez: Figura 148: Diagrama de Robustez Cadastrar Plano de Conta
  • 183. 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.
  • 184. 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.
  • 185. 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
  • 186. 176 Diagrama de Robustez: Figura 151: Diagrama de Robustez Cadastrar Favorecido
  • 187. 177 Diagrama de Sequência: Figura 152: Diagrama de Sequência Cadastrar Favorecido
  • 188. 178 10.2 MODELO ESTÁTICO 10.2.1 Modelo de Domínio Figura 153: Modelo de Domínio do Módulo de Financeiro
  • 189. 179 10.2.2 Diagrama de Classes Figura 154: Diagrama de Classes do Módulo de Financeiro
  • 190. 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
  • 191. 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
  • 192. 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;
  • 193. 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;
  • 194. 184 11.2 DIAGRAMA DE MODELO DE DOMÍNIO
  • 195. 185 11.3 DER
  • 196. 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.
  • 197. 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.
  • 198. 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.
  • 199. 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.
  • 200. 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.
  • 201. 191 APÊNDICES
  • 202. 192 APÊNDICE A - Check List de Implantação
  • 203. 193 APÊNDICE B – Revisões e Estatísticas do Controle de Versões
  • 204. 194
  • 205. 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 cont ainer-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
  • 206. 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