UNIVERSIDADE POTIGUAR - UNP
PRÓ-REITORIA DE GRADUAÇÃO
CURSO SISTEMAS DE INFORMAÇÃO
FRANCINALDO RODRIGUES DE LIMA
RICARDO J...
FRANCINALDO RODRIGUES DE LIMA
RICARDO JÚLIO DA SILVA CARVALHO
ARCA - SISTEMA GERENCIAL
Trabalho de Conclusão de Curso
apre...
FRANCINALDO RODRIGUES DE LIMA
RICARDO JULIO DA SILVA CARVALHO
ARCA - SISTEMA GERENCIAL
Trabalho de Conclusão de Curso
apre...
Dedico este trabalho primeiramente a Deus que me deu a vida e depois a minha
família que sempre esta do meu lado apoiando ...
AGRADECIMENTOS
Agradeço primeiramente a Deus que esta permitindo a conquista de mais um
objetivo na nossa vida e também po...
Nossa maior fraqueza está em desistir. A maneira mais segura de ter sucesso é
sempre tentar mais uma vez.
Thomas Edison
Um...
RESUMO
Este trabalho apresenta os resultados da análise e desenvolvimento de um sistema
web que foi chamado de “ARCA” para...
ABSTRACT
This study presents the results of the analysis and development of a web system that
was called "ARCA" for the co...
LISTA DE ILUSTRAÇÕES
Figura 1: Processo Iconix ..............................................................................
Figura 33: Diagrama de Robustez Alternar Empresa ..................................................68
Figura 34: Diagrama ...
Figura 67: Diagrama de Sequência Nota de Almoxarifado .........................................98
Figura 68: Tela Estornar...
Figura 101: Tela Cadastrar Forma de Pagamento.....................................................132
Figura 102: Diagrama...
Figura 135: Diagrama de Sequência Notificar Vacina Pendente / Indicada.............159
Figura 136: Mensagem de Notificação...
LISTA DE ABREVIAÇÕES E SIGLAS
AJAX Asynchronous Javascript and XML
AMI Assistência Médica Infantil
ASF Apache Software Fou...
SUMÁRIO
1 INTRODUÇÃO ........................................................................................................
4.4.3 DAO................................................................................................................3...
8.1.3 Manter Produto (CSU013) ..........................................................................78
8.1.4 Manter Fa...
9.2.2 Diagrama de Classes................................................................................164
10 MODELAGEM ...
9
1 INTRODUÇÃO
Para seguir as tendências de mercado, e sobressair da concorrência acirrada,
as empresas precisam investir ...
10
1.2 OBJETIVO GERAL
Criação de um sistema web para a Empresa AMI (Assistência Médica Infantil)
VACINAS para atender as n...
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édi...
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 ...
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...
14
Calendário de Vacinação do Adolescente:
Quadro 2: Calendário do Adolescente
Fonte: (PORTAL DA SAÚDE, extraído da Intern...
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ânci...
16
3 METODOLOGIA
3.1 ORIENTAÇÃO A OBJETOS
A Orientação a Objetos ou simplesmente OO, é um paradigma de
programação, que ap...
17
3.2 UML
Com a evolução tecnológica e os sistemas tornando-se mais complexos e a
tarefa de desenvolvimento de software p...
18
Figura 1: Processo Iconix
Fonte: Rosenberg; Stephens; Cope (2005, p.?)
Na Figura 1 mostra que o Iconix esta dividido em...
19
estarão envolvidos com o nosso sistema, sobre o nosso ponto de vista esta etapa é
fundamental para desenvolvimento do p...
20
Pensando na análise ao projeto foi que chegamos à conclusão que seria
muito importante que o nosso sistema fosse totalm...
21
4 ARQUITETURA
Arquitetura é um termo que é utilizado em várias áreas de conhecimento e
vem sendo utilizada na área de S...
22
produtividade. No nosso caso, optamos pela linguagem JAVA em um ambiente
web, de acordo com critérios previamente estab...
23
4.2 TECNOLOGIAS UTILIZADAS
4.2.1 JSF
Geary e Horstman (2007, p.3), baseado nos dados dos anúncios de
empregos da intern...
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 ...
25
4.2.2 Primefaces
Ao trabalhar com JSF, temos uma imensidade de pacotes de componentes,
para integrar ao projeto e aumen...
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...
27
“O JasperReports é uma biblioteca Java responsável pela execução dos
relatórios. É esse biblioteca que está por traz do...
28
de um, trabalhando exclusivamente para servir páginas escritas em
Java. Atualmente no mercado existem diversos servidor...
29
de segurança e outras referentes aos bancos de dados, agora realizada em uma
camada própria”.
4.3.1 PostgreSQL
O Postgr...
30
arquitetos, projetistas e cientistas da computação, e pelo resultado apresentado, se
sobrepõem as demais formas de impl...
31
Figura 4: Padrão MVC JavaServer Faces
Fonte: http://communities.softwareag.com/ecosystem/communities/public/Developer/
...
32
4.4.2 Façade
Algumas vezes, a complexidade envolvendo o relacionamento de múltiplas
classes ou subsistemas interfere no...
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...
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 nome...
35
 Será utilizado “tab” como marcador de endentação;
 Os métodos que realização ações, na camada de controle, acessívei...
36
5 ANÁLISE DE REQUISITOS
5.1 REQUISITOS FUNCIONAIS
Segundo Sommerville (2003, p.83), “Requisitos funcionais são declaraç...
37
5.1.2 Módulo Estoque
RF005: Cadastros Básicos de Estoque
O sistema deverá permitir ao usuário do sistema, cadastrar e a...
38
O sistema deverá permitir ao usuário do sistema, registrar a aplicação de vacina,
gerando as movimentações de estoque q...
39
O sistema deverá permitir ao usuário do sistema, gerar relatórios de contas pagas e
a pagar, relatório de contas recebi...
40
o Banco de banco de dados PostgreSQL 9.1;
Especificação mínima para máquina Cliente:
 Qualquer máquina com acesso a in...
41
6 REGRAS DE NEGÓCIO
RN001: Somente usuários autenticados podem acessar os recursos restritos de
acordo com as permissõe...
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ódul...
43
7.1.2 Fazer Login (CSU001)
Sumário: O Usuário solicita autenticação no sistema para ter acesso aos recursos
restritos d...
44
Pós-Condições: O usuário estará autenticado no sistema e a suas permissões aos
recursos habilitadas.
Protótipo Tela:
Fi...
45
Diagrama de Robustez:
Figura 9: Diagrama de Robustez Fazer Login
Diagrama de Sequência:
Figura 10: Diagrama de Sequênci...
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 u...
47
Diagrama de Robustez:
Figura 12: Diagrama de Robustez Alterar Senha
Diagrama de Sequência:
Figura 13: Diagrama de Sequê...
48
7.1.4 Manter Empresa (CSU003)
Sumário: O Administrador realiza o cadastro (consulta, inclusão, alteração e
remoção) dos...
49
d) O sistema verifica a validade dos dados. Se os dados forem válidos, altera os
dados da empresa; caso contrário, o si...
50
Diagrama de Robustez:
Figura 15: Diagrama de Robustez Cadastrar Empresa
51
Diagrama de Sequência:
Figura 16: Diagrama de Sequência Cadastrar Empresa
7.1.5 Manter Módulo (CSU004)
Sumário: O Admin...
52
Fluxo Principal:
1. O Administrador requisita a manutenção do cadastro de módulos.
2. O sistema apresenta listagem dos ...
53
Protótipo Tela:
Figura 17: Tela Cadastrar Módulo
Diagrama de Robustez:
Figura 18: Diagrama de Robustez Cadastrar Módulo
54
Diagrama de Sequência:
Figura 19: Diagrama de Sequência Cadastrar Módulo
7.1.6 Manter Nível (CSU005)
Sumário: O Adminis...
55
2. O sistema apresenta listagem dos níveis cadastrados com as operações que
podem ser realizadas: inclusão de um novo n...
56
Protótipo Tela:
Figura 20: Tela Cadastrar Nível
Diagrama de Robustez:
Figura 21: Diagrama de Robustez Cadastrar Nível
57
Diagrama de Sequência:
Figura 22: Diagrama de Sequência Cadastrar Nível
7.1.7 Manter Menu Grupo (CSU006)
Sumário: O Adm...
58
Pré-condições: O Administrador deve está autenticado e autorizado no sistema
(Conforme RN001).
Fluxo Principal:
1. O Ad...
59
Pós-Condições: Um grupo foi inserido ou removido, ou seus detalhes foram
alterados.
Protótipo Tela:
Figura 23: Tela Cad...
60
Diagrama de Sequência:
Figura 25: Diagrama de Sequência Cadastrar Menu Grupo
7.1.8 Manter Menu Item (CSU007)
Sumário: O...
61
Fluxo Principal:
1. O Administrador requisita a manutenção do cadastro de item de menu.
2. O sistema apresenta listagem...
62
Protótipo Tela:
Figura 26: Tela Cadastrar Menu Item
Diagrama de Robustez:
Figura 27: Diagrama de Robustez Cadastrar Men...
63
Diagrama de Sequência:
Figura 28: Diagrama de Sequência Cadastrar Menu Item
7.1.9 Manter Usuário (CSU008)
Sumário: O Ad...
64
Fluxo Principal:
1. O Administrador requisita a manutenção do cadastro de usuários.
2. O sistema apresenta listagem dos...
65
Protótipo Tela:
Figura 29: Tela Cadastrar Usuário
Diagrama de Robustez:
Figura 30: Diagrama de Robustez Cadastrar Usuár...
66
Diagrama de Sequência:
Figura 31: Diagrama de Sequência Cadastrar Usuário
7.1.10 Alternar Empresa (CSU009)
Sumário: O U...
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...
68
Diagrama de Robustez:
Figura 33: Diagrama de Robustez Alternar Empresa
Diagrama de Sequência:
Figura 34: Diagrama de Se...
69
7.1.11 Consultar Logs (CSU010)
Sumário: O Administrador solicita consulta de logs do sistema.
Ator Primário: Administra...
70
Diagrama de Robustez:
Figura 36: Diagrama de Robustez Consultar Logs
Diagrama de Sequência:
Figura 37: Diagrama de Sequ...
71
7.1.12 Notificar Falha no Login (CSU011)
Sumário: O sistema recebe mensagem de que uma tentativa de autenticação no
sis...
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Arca Sistema Gerencial
Próximos SlideShares
Carregando em…5
×

Arca Sistema Gerencial

1.205 visualizações

Publicada em

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.

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.205
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
47
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Arca Sistema Gerencial

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 60. 50 Diagrama de Robustez: Figura 15: Diagrama de Robustez Cadastrar Empresa
  61. 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. 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. 63. 53 Protótipo Tela: Figura 17: Tela Cadastrar Módulo Diagrama de Robustez: Figura 18: Diagrama de Robustez Cadastrar Módulo
  64. 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. 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. 66. 56 Protótipo Tela: Figura 20: Tela Cadastrar Nível Diagrama de Robustez: Figura 21: Diagrama de Robustez Cadastrar Nível
  67. 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. 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. 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. 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. 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. 72. 62 Protótipo Tela: Figura 26: Tela Cadastrar Menu Item Diagrama de Robustez: Figura 27: Diagrama de Robustez Cadastrar Menu Item
  73. 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. 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. 75. 65 Protótipo Tela: Figura 29: Tela Cadastrar Usuário Diagrama de Robustez: Figura 30: Diagrama de Robustez Cadastrar Usuário
  76. 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. 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. 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. 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. 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. 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

×