A UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA
FACULDADE DE CIÊNCIAS APLICADAS DE MINAS
Autorizada pela Portaria no 577/2000 – MEC, de 03/05/2000
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
AS
DESENVOLVIMENTO DO SISTEMA DE
IN
GERENCIAMENTO DA SATIKA ÓPTICA
IM
ARIANE GRACIELE SANTOS SOUZA
IRON MARTIM FERREIRA JÚNIOR
UN
LUCIANA CAMPOS CARMO
Uberlândia
2008
ARIANE GRACIELE SANTOS SOUZA
IRON MARTIM FERREIRA JÚNIOR
LUCIANA CAMPOS CARMO
DESENVOLVIMENTO DO SISTEMA DE
AS
GERENCIAMENTO DA SATIKA ÓPTICA
IN
Trabalho de Final de curso submetido à
UNIMINAS como parte dos requisitos
para a obtenção do grau de Bacharel em
Sistemas de Informação.
UN
IM
Orientador: Prof. Msc. Silvio Bacalá Júnior
Uberlândia
2008
ARIANE GRACIELE SANTOS SOUZA
IRON MARTIM FERREIRA JÚNIOR
LUCIANA CAMPOS CARMO
DESENVOLVIMENTO DO SISTEMA DE
AS
GERENCIAMENTO DA SATIKA ÓPTICA
IN
Trabalho de Final de curso submetido à
UNIMINAS como parte dos requisitos
para a obtenção do grau de Bacharel em
IM
Sistemas de Informação.
Orientador: Prof. M. Sc. Silvio Bacalá
Junior
UN
Banca Examinadora:
Uberlândia, 17 de julho de 2008.
Prof. Carlos Henrique Barros
Prof. Dra. Kátia Lopes Silva
Prof. M. Sc. Sílvio Bacalá
Uberlândia
2008
AS
IN
IM
UN
A nossa família pelo costumeiro apoio e aos nossos amigos.
AGRADECIMENTOS
À professora Ana Maria Árabe pela paciência e ajuda na conclusão
deste trabalho. Ao nosso querido orientador Silvio Bacalá pelos ensinamentos e
brincadeiras para descontração e incentivo nos momentos de angústia. A nossa
família, pela confiança e motivação. Ao nosso amigo querido amigo Luis Carlos
pela ajuda com a infra-estrutura deste trabalho. À querida Poliana pela paciência
UN
IM
IN
AS
e compreensão em nossas ausências.
RESUMO
A fidelização é uma necessidade atual das empresas para agilizar
o contato com os clientes e o processo de venda de serviços e produtos.
Deseja-se aumentar a satisfação dos clientes com os serviços prestados. É
importante ter um único centralizador de informações, em que os cadastros dos
clientes estejam armazenados e também suas últimas transações com a
empresa, principalmente entre matriz e filiais.
Assim sendo, este trabalho
apresenta o protótipo de um sistema para uma empresa de Óptica com a
AS
finalidade de cadastrar clientes, produtos, receituários e médicos que
recomendem a empresa, emitir relatórios e também registrar vendas e compras
de produtos juntamente com seus fornecedores cadastrados. As etapas do
desenvolvimento do sistema são descritas desde o momento do recebimento da
IN
proposta a ser desenvolvida até o momento da codificação do sistema,
considerando-se as fases de análise, modelagem, interface, persistência de
dados e implementação. O produto final é um sistema pronto para ser
implantado na empresa, com suporte a Web e personalizado para suas
IM
necessidades de operação, utilizando apenas um sistema de banco de dados
para armazenar todas as informações necessárias para a operação da empresa.
O sistema possibilitará agilizar o atendimento aos clientes pelos funcionários
como também fornecerá informações que serão usadas pelo administrador da
UN
empresa para identificar pontos de melhoria no seu negócio.
Palavras Chave: Sistema Web, Desenvolvimento de software, Análise de software,
banco de dados, Java.
ABSTRACT
Customer relationship is a current need of companies to expedite the contact
between their customers and the process of sales of services and products as means
to increase customer satisfaction with the services provided. It is important to have a
single, centralized information platform, where customer entries and latest
transactions are stored, particularly between the parent company and its
subsidiaries. Thus, this work presents the prototype of a system for an Optical
AS
company with the purpose of registering customers, products, prescriptions and
recommended doctors, as well as report record sales and product purchases along
with their registered suppliers. The stages of development of the system are
described from the time of receipt of the proposal being developed till the time of the
IN
codification of the system, considering the stages of analysis, modeling, interface,
persistence and data implementation. The final product is a system ready to be
deployed by the company, with support for Web and customized for its operational
needs, using a single electronic storage system database. The system will streamline
the service to customers by the employees, but also provide information that will be
UN
business.
IM
used by the company administrator to identify points of improvement in their
LISTA DE FIGURAS
UN
IM
IN
AS
Figura 1 - Loja matriz Rua Duque de Caxias ........................................................................... 20
Figura 2 - Loja filial Avenida Santos Dumont ......................................................................... 21
Figura 3 - Loja filial Avenida Raulino Cotta Pacheco ............................................................. 21
Figura 4 - Diagrama de Caso de Uso 1 ..................................................................................... 31
Figura 5 - Diagrama de Caso de Uso 2 ..................................................................................... 32
Figura 6 - Diagrama de seqüência efetuar login ....................................................................... 72
Figura 7 - Diagrama de seqüência cadastrar cliente ................................................................. 72
Figura 8 - Diagrama de seqüência cadastrar funcionário ......................................................... 73
Figura 9 - Diagrama de seqüência cadastrar fornecedor .......................................................... 74
Figura 10 - Diagrama de seqüência cadastrar médico .............................................................. 75
Figura 11 - Diagrama de seqüência cadastrar produto ............................................................. 76
Figura 12 - Diagrama de seqüência cadastrar receituário......................................................... 77
Figura 13 - Diagrama de seqüência registrar venda ................................................................. 78
Figura 14 - Diagrama de seqüência registrar compra ............................................................... 79
Figura 15 - Diagrama de seqüência alterar cliente ................................................................... 80
Figura 16 - Diagrama de seqüência alterar funcionário ........................................................... 81
Figura 17 - Diagrama de seqüência alterar fornecedor............................................................. 82
Figura 18 - Diagrama de seqüência alterar médico .................................................................. 83
Figura 19 - Diagrama de seqüência alterar produto ................................................................. 84
Figura 20 - Diagrama de seqüência alterar venda .................................................................... 85
Figura 21 - Diagrama de seqüência alterar compra .................................................................. 86
Figura 22 - Diagrama de seqüência alterar receituário ............................................................. 87
Figura 23 - Diagrama de seqüência excluir cliente .................................................................. 88
Figura 24 - Diagrama de seqüência excluir funcionário........................................................... 89
Figura 25 - Diagrama de seqüência excluir fornecedor ............................................................ 90
Figura 26 - Diagrama de seqüência excluir médico ................................................................. 91
Figura 27 - Diagrama de seqüência excluir produto................................................................. 92
Figura 28 - Diagrama de seqüência Excluir Venda .................................................................. 93
Figura 29 - Diagrama de seqüência Excluir Compra ............................................................... 94
Figura 30 - Diagrama de seqüência Excluir Receituário .......................................................... 95
Figura 31 - Diagrama de seqüência Pesquisar Cliente ............................................................. 96
Figura 32 - Diagrama de seqüência Pesquisar Funcionário ..................................................... 97
Figura 33 - Diagrama de seqüência Pesquisar Fornecedor....................................................... 98
Figura 34 - Diagrama de seqüência Pesquisar Médico............................................................. 99
Figura 35 - Diagrama de seqüência Pesquisar Produto .......................................................... 100
Figura 36 - Diagrama de seqüência Pesquisar Venda ............................................................ 101
Figura 37 - Diagrama de seqüência Pesquisar Compra .......................................................... 102
Figura 38 - Diagrama de seqüência Pesquisar Receituário .................................................... 103
Figura 39 - Diagrama de seqüência Relatório Melhores Clientes .......................................... 104
Figura 40 - Diagrama de seqüência Relatório Produtos Mais Vendidos ................................ 105
Figura 41 - Diagrama de pacotes ............................................................................................ 109
Figura 42 - Classe de análise pacote login ............................................................................. 110
Figura 43 - Diagrama de análise cliente ................................................................................. 111
Figura 44 - Classe de análise Funcionário .............................................................................. 113
Figura 45 - Classe de análise fornecedor ................................................................................ 114
Figura 46 - Classe de análise pacote médico .......................................................................... 116
Figura 47 - Classe de análise pacote produto ......................................................................... 117
Figura 48 - Classe de análise pacote receituário..................................................................... 119
UN
IM
IN
AS
Figura 49 - Classe de análise pacote venda ............................................................................ 120
Figura 50 - Classe de análise pacote compra .......................................................................... 122
Figura 51 - Classe de análise do pacote Relatório Produtos Mais Vendidos ......................... 123
Figura 52 - Classe de análise do pacote Relatório Melhores Clientes.................................... 124
Figura 53 - Diagrama de classes do projeto registrar venda................................................... 126
Figura 54 - Marca empresa Satika .......................................................................................... 131
Figura 55 - Estrutura do Satika System .................................................................................. 132
Figura 56 - Fragmento menu.js............................................................................................... 133
Figura 57 - Menu categoria Retrátil ....................................................................................... 134
Figura 58 - Modelos de disposição de informações em um site............................................. 135
Figura 59 - Modelo do menu do sistema ................................................................................ 136
Figura 60 - Arquitetura do site ............................................................................................... 137
Figura 61 - Controle de acesso ............................................................................................... 138
Figura 62 - Trecho da página de login .................................................................................... 138
Figura 63 - Diagrama de estados de navegação ..................................................................... 139
Figura 64 - Menu e área de resposta ....................................................................................... 140
Figura 65 - Fotografia usada pela empresa ............................................................................. 141
Figura 66 - Trecho página index.jsp ....................................................................................... 143
Figura 67 - Chamada do arquivo CSS .................................................................................... 144
Figura 68 - Trecho do arquivo css_index.css ......................................................................... 145
Figura 69 - Tela de login do sistema ...................................................................................... 146
Figura 70 - Página IndexAdm.jsp ........................................................................................... 146
Figura 71 - Código página indexAdm.jsp .............................................................................. 147
Figura 72 - Trecho menu.css .................................................................................................. 148
Figura 73 - Trecho página indexAdm.jsp ............................................................................... 149
Figura 74 - Trecho menu.js .................................................................................................... 150
Figura 75 - Trecho da página receituário.jsp .......................................................................... 151
Figura 76 - Página receituário ................................................................................................ 152
Figura 77 - Esquema de Níveis............................................................................................... 158
Figura 78 - DER Satika System .............................................................................................. 161
Figura 79 - Cardinalidade : um-para-um ................................................................................ 163
Figura 80 - Cardinalidade : um-para-muitos .......................................................................... 164
Figura 81 - Cardinalidade : muitos-para-um .......................................................................... 164
Figura 82 - Cardinalidade um para muitos ............................................................................. 165
Figura 83 - Visão Geral da Arquitetura do Hibernate ............................................................ 168
Figura 84 - Arquivo Hibernate.cfg ......................................................................................... 169
Figura 85 - Parte do diagrama de Classes Satika System ....................................................... 171
Figura 86 - Arquivo fornecedor.cfg.xml ................................................................................ 173
Figura 87 - Arquivo Endereco.cfg.xml................................................................................... 175
Figura 88 - Arquivo Compra.cfg.xml ..................................................................................... 176
Figura 89 - Arquivo ItemCompra.cfg.xml.............................................................................. 177
Figura 90 - Arquivo Produto.cfg.xml ..................................................................................... 178
Figura 91 - Pesquisa para encontrar todos os clientes ............................................................ 181
Figura 92 - Pesquisa para encontrar todos os clientes ............................................................ 184
Figura 93 - Classe HibernateUtility da aplicação Satika System ........................................... 186
Figura 94 - Classe EnderecoDAO .......................................................................................... 187
Figura 95 - Classe FornecedorDAO ....................................................................................... 188
Figura 96 - Classe PessoaDAO parte 1 .................................................................................. 189
Figura 97 - Classe PessoaDAO parte 2 .................................................................................. 190
Figura 98 - Classe Action.Login ............................................................................................ 195
UN
IM
IN
AS
Figura 99 - Código do FormLogin ......................................................................................... 197
Figura 100 - Classes DAO ...................................................................................................... 199
LISTA DE QUADROS
UN
IM
IN
AS
Quadro 1 - Modelo de ata de reunião ....................................................................................... 24
Quadro 2 - Requisitos funcionais e não funcionais .................................................................. 25
Quadro 3 - Regras de negócios ................................................................................................. 35
Quadro 4 - Especificação do caso de uso: efetuar login ........................................................... 36
Quadro 5 - Especificação do caso de uso: cadastrar cliente ..................................................... 37
Quadro 6 - Especificação do caso de uso: cadastrar receituário ............................................... 38
Quadro 7 - Especificação do caso de uso: cadastrar funcionário ............................................. 39
Quadro 8 - Especificação do caso de uso: cadastrar fornecedor .............................................. 40
Quadro 9 - Especificação do caso de uso: cadastrar médico .................................................... 41
Quadro 10 - Especificação do caso de uso: cadastrar produto ................................................. 42
Quadro 11 - Especificação do caso de uso: registrar compra ................................................... 43
Quadro 12 - Especificação do caso de uso: registrar venda ..................................................... 44
Quadro 13 - Especificação do caso de uso: excluir cliente ...................................................... 45
Quadro 14 - Especificação do caso de uso: excluir fornecedor ................................................ 46
Quadro 15 - Especificação do caso de uso: excluir funcionário ............................................... 47
Quadro 16 - Especificação do caso de uso: excluir médico ..................................................... 48
Quadro 17 - Especificação do caso de uso: excluir produto..................................................... 49
Quadro 18 - Especificação do caso de uso: excluir registro de venda ..................................... 50
Quadro 19 - Especificação do caso de uso: excluir registro de compra ................................... 51
Quadro 20 - Especificação do caso de uso: excluir receituário ................................................ 52
Quadro 21 - Especificação do caso de uso: pesquisar cliente .................................................. 53
Quadro 22 - Especificação do caso de uso: pesquisar fornecedor ............................................ 54
Quadro 23 - Especificação do caso de uso: pesquisar funcionário........................................... 55
Quadro 24 - Especificação do caso de uso: pesquisar médico ................................................. 56
Quadro 25 - Especificação do caso de uso: pesquisar produto................................................. 57
Quadro 26 - Especificação do caso de uso: pesquisar registro de venda ................................. 58
Quadro 27 - Especificação do caso de uso: pesquisar registro de compra ............................... 59
Quadro 28 - Especificação do caso de uso: pesquisar receituário ............................................ 60
Quadro 29 - Especificação do caso de uso: alterar dados cliente ............................................. 61
Quadro 30 - Especificação do caso de uso: alterar dados fornecedor ...................................... 62
Quadro 31 - Especificação do caso de uso: alterar dados funcionário ..................................... 63
Quadro 32 - Especificação do caso de uso: alterar dados médico ............................................ 64
Quadro 33 - Especificação do caso de uso: alterar dados produto ........................................... 65
Quadro 34 - Especificação do caso de uso: alterar venda ........................................................ 66
Quadro 35 - Especificação do caso de uso: alterar compra ...................................................... 67
Quadro 36 - Detalhe do caso de uso alterar receituário ............................................................ 68
Quadro 37 - Detalhe do caso de uso relatório melhores clientes.............................................. 69
Quadro 38 - Detalhe do caso de uso relatórios produtos mais vendidos .................................. 70
LISTA DE ABREVIATURAS E SÍMBOLOS
CNPJ – Cadastro Nacional de Pessoas Jurídicas
CPF – Cadastro de pessoas físicas
CSS – Cascate Style Sheet
DADI – Definition, Architecture, Design, Implementation ou Definição, Arquitetura,
Design e Implementação
DER – Diagrama de Entidade e Relacionamento
HTTP – Hypertext Transfer Protocol
MS SQL – Microsoft SQL Server
AS
JSP – Java Server Pages
OOHDM – Object-Oriented Hypermedia Design Method
PK – Primary Key ou Chave Primária
SQL - Structured Query Language ou Linguagem de Consulta Estruturada
IN
UC – Use Case ou Caso de Uso
UML - Unified Modeling Language ou Linguagem de Modelagem Unificada
UN
IM
W3C – World Wide Web Consortium
SUMÁRIO
1
INTRODUÇÃO ........................................................................................................... 15
1.1
Cenário Atual .............................................................................................................. 15
1.2
Foco no problema de gestão a ser resolvido ........................................................ 16
1.3
Objetivos do Trabalho ............................................................................................... 17
1.3.1 Objetivo Geral ............................................................................................................. 17
1.3.2 Objetivo Específico .................................................................................................... 17
Justificativa .................................................................................................................. 18
1.5
Organização do Trabalho ......................................................................................... 19
2
DESCRIÇÃO DO PROBLEMA ................................................................................ 20
3
ANÁLISE DO SISTEMA ............................................................................................ 26
3.1
Análise de sistema utilizando a UML ...................................................................... 26
AS
1.4
3.1.1 Diagramas de Caso de Uso ..................................................................................... 30
Especificações dos Casos de Uso .......................................................................... 33
3.3
Diagramas de Seqüência ......................................................................................... 70
3.4
Classes de Análise .................................................................................................. 106
IN
3.2
3.4.1 Classe de Fronteira ................................................................................................. 106
3.4.2 Classe de Controle .................................................................................................. 107
3.4.3 Classe de Entidade .................................................................................................. 108
3.4.4 Classes do Projeto ................................................................................................... 108
Classes de Projeto ................................................................................................... 125
4
PROJETO DE INTERFACE ................................................................................... 128
4.1
Introdução ................................................................................................................. 128
4.2
Definição de interface .............................................................................................. 128
4.3
Padrões de construção de interface ..................................................................... 129
4.4
Definição da interface do sistema ......................................................................... 130
4.5
Arquitetura da interface do sistema ...................................................................... 132
4.6
Design ........................................................................................................................ 139
4.7
Implementação ......................................................................................................... 141
4.8
Caso de uso .............................................................................................................. 145
5
PERSISTÊNCIA ....................................................................................................... 153
5.1
Organização do banco de dados........................................................................... 154
5.2
Sistema de informação Gerencial do Banco de Dados ..................................... 155
UN
IM
3.5
5.2.1 A escolha do MYSQL .............................................................................................. 156
5.3
Arquitetura do banco de dados .............................................................................. 157
5.4
Modelagem do banco de dados ............................................................................ 158
5.4.1 Explicando o Modelo ............................................................................................... 161
5.4.2 Restrições em relacionamentos ............................................................................ 162
5.4.3 Atributos chaves ....................................................................................................... 165
5.5
Hibernate ................................................................................................................... 166
5.5.1 Mecanismo de persistência do Hibernate ............................................................ 178
5.6
Padrão de persistência DAO(Data Access object) ............................................. 182
6
ARQUITETURA E CÓDIGO................................................................................... 192
6.1
JEE ............................................................................................................................. 192
6.2
Struts .......................................................................................................................... 193
7
CONCLUSÃO ........................................................................................................... 201
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 203
APÊNDICE A – Código menu.jsp: .................................................................................... 205
AS
APÊNDICE B – Código index.jsp ...................................................................................... 212
APÊNDICE C – Código css_index.css............................................................................. 215
APÊNDICE D – Código css_int.css .................................................................................. 217
APÊNDICE E – Código menu.css..................................................................................... 220
UN
IM
IN
APÊNDICE F – Código sdmenu.css................................................................................. 222
15
1 INTRODUÇÃO
1.1
Cenário Atual
Segundo pesquisas o mercado de ópticas encontra grande deficiência
em soluções que atendam à demanda deste crescente setor. A existência de
softwares nesta área é escassa e os mesmos possuem preços elevados se
comparados às funcionalidades que apresentam. Quando se fala em informatizar, há
que se fazerem necessárias diferenciações: ter um computador na empresa com
acesso a Internet é um bom começo, mas ainda significa estar na idade das pedras
AS
em relação ao que um software pode operacionalizar. O sistema pode permitir o
armazenamento de infinitas informações, até mesmo da data de aniversário dos
clientes fiéis, que geralmente é anotado, ainda hoje, numa caderneta. Apesar do
computador ser uma ferramenta amplamente difundida no mundo atual, a
IN
receptividade do setor ainda é fraca, os ópticos ainda preferem anotações em
cadernos e gerenciamento baseado na própria experiência de muitos anos. Ou seja,
o setor ainda é muito conservador, muito resistente à informatização.
IM
Uma empresa com um sistema totalmente informatizado, funcionando
eficiente e eficazmente, proporcionará grandes vantagens, seja em relação
ao tempo otimizado, à organização, à facilidade de obtenção de
informações, à previsão e muitos outros aspectos que contribuirão para o
sucesso
ou
para
o
fracasso
da
pequena
empresa.
(COMO
UN
INFORMATIZAR, 2006).
Não há estatísticas oficiais, mas os profissionais do setor acreditam
que menos de 50% das ópticas em todo o Brasil estejam informatizadas e, destas,
apenas 20%, dispõem de ferramentas tecnológicas arrojadas. A informatização da
loja significa mais do que simplesmente comprar um microcomputador e impressora
para emitir nota fiscal. Significa ter um sistema fácil e eficaz que faça parte do
processo da loja, facilitando o trabalho e aumentando a qualidade no atendimento e
a produtividade. Muitos empresários ainda pensam que não têm porte ou
necessidade de utilizar um sistema de gestão específico para óptica, mas o mercado
brasileiro mostra que o cliente tem mais confiança e interesse em ser cliente de uma
16
óptica que se preocupa em oferecer inovação e tecnologia em conjunto com um
atendimento personalizado.
Os empresários, proprietários de óptica, devem olhar para o seu
negócio com mais empreendedorismo. Em algumas lojas, existem instalações muito
precárias em relação à iluminação, vitrines, uniformes. É preciso pensar que a óptica
representa uma extensão da visita ao oftalmologista, ela tem o papel importante de
dar informações ou prestar serviços complementares à prescrição médica. O cliente
tem que ter, e perceber, que a óptica, onde ele quer fazer os seus óculos, tem um
nível de atendimento igual ou superior ao de onde ele começou a consulta, até
mesmo nas instalações. Sabe-se que existem ópticas que superam quaisquer
AS
expectativas em atendimento, suas instalações são de excelente qualidade e os
serviços, exemplares. Mas essa situação não retrata a maioria do mercado.
Portanto, a orientação é que os empresários comecem a rever seus negócios,
colocando mais tecnologia em serviços.
IN
Os softwares podem ajudar a armazenar e gerenciar os receituários de
todos os clientes, números de faturamento a demanda de compras, pagamentos a
fazer, controle de estoque e até mesmo a medida da satisfação dos clientes. O
1.2
IM
óptico ganha completo controle sobre o negócio, podendo evitar até mesmo roubos.
Foco no problema de gestão a ser resolvido
Realizou-se um estudo sobre o desenvolvimento de um sistema para
UN
gerenciar, administrar e armazenar todas as operações realizadas pela empresa.
Utilizando a linguagem de programação Java, este sistema possui três camadas na
Web, isto é, camada de apresentação, camada de negócios e por fim a camada de
integração, utilizando padrões de projeto.
Desenvolveu-se um sistema por meio do qual foram armazenadas
todas as informações e operações da empresa. A criação do sistema possibilita
orientar a empresa no desenvolvimento do seu planejamento estratégico e
operacional através do estabelecimento de metas, controle e melhorias dos
processos. Através de levantamentos de requisitos, o sistema possibilita um controle
de cadastro de clientes, fornecedores, funcionários e médicos. Possibilita também o
envio de mala direta, controle de estoque, cadastro de produtos e controle de
17
vendas, caixa mensal, caixa diário e controle financeiro. Com a ajuda de gráficos o
sistema auxilia a tomada de decisões, identificando as saídas de produtos por
período, produtos mais vendidos e menos vendidos. A etapa posterior ao
levantamento de requisitos é a análise de requisitos onde terá os requisitos
funcionais e não funcionais de um sistema e assim começar a fazer os diagramas.
Através da mala direta e dos gráficos com as saídas de produtos por
período a empresa terá maior controle nas decisões a serem tomadas na sua
política estratégica, efetivando assim um poder maior na concorrência.
Portanto, através dessa crescente necessidade de se cada vez mais
procurar formas de gerenciar, manipular e organizar informações desenvolveu-se
Objetivos do Trabalho
1.3.1 Objetivo Geral
IN
1.3
AS
um sistema que atenderá as expectativas do cliente.
Implementar um aplicativo comercial com suporte a Web para gestão
de Óptica e Optometria. Desenvolver um software para gerenciar, administrar e
IM
armazenar todas as operações realizadas pela empresa.
UN
1.3.2 Objetivo Específico
Levantar dos requisitos do sistema;
Documentar dos Casos de Uso;
Analisar o desenvolvimento do projeto;
Implementar o aplicativo em três camadas;
Implementar o sistema utilizando a linguagem de programação
Java;
Implementar o diagrama de classes no nível de projeto;
Implementar camada de apresentação através de Front
Controller, Application Controller e Context Object.
Implementar camada de negócio através de Business Delegate,
Service Locator, Session Facade e Transfer Object;
18
Implementar camada de integração utilizando DAO - Data
Access Object;
Utilizar o Hibernate para mapeamento objeto-relacional;
Utilizar Struts;
Utilizar Tiles;
Testar o sistema implementado.
1.4
Justificativa
AS
O mercado de softwares apresenta carência na área de soluções para
o setor óptico. No Brasil não existe muitos software capazes de suprir totalmente as
necessidades de uma óptica.
O alto custo envolvido na aquisição de soluções importadas torna-se
inviável sua aplicação em aproximadamente 90% das ópticas no Brasil, pois
IN
conforme estatísticas são de pequeno e médio porte. As pesquisas revelam que a
grande maioria destas empresas adquirem softwares gerenciais simples. Com a falta
de rotinas técnicas e específicas, utilizam aplicativos mais genéricos para suprirem
interinamente o papel especializado inexistente no sistema implantado na óptica.
IM
Desta forma, a falta de automatização, deixou para trás o
desenvolvimento da tecnologia de informação do setor. É possível ainda observar a
lentidão deste processo que ainda é feito de forma manual, tendo como
conseqüência a irritação e até a perda de alguns clientes. Com o sistema
UN
desenvolvido, estes problemas são minimizados, aumentando consideravelmente o
controle de qualidade da óptica.
Com a expansão da informatização, principalmente relacionada a
questões de saúde, observa-se o grande avanço tecnológico dessa área, pois cada
vez mais se buscam soluções eficazes e inovadoras que possam contribuir para
uma melhor qualidade de vida. Devido a esse crescente aumento das informações
comerciais no setor de óptica, juntamente com a necessidade de armazená-las,
surgiu o interesse para o estudo mais profundo de um sistema para esse tipo de
controle.
Observando estas necessidades, desenvolveu-se um sistema que
implementa uma solução eficaz e consistente de gerenciamento, manipulação e
19
armazenamento de dados e que possibilita a maior lucratividade, maior rapidez no
atendimento ao cliente e armazenamento seguro de dados importantes.
A relevância do estudo, em seus aspectos profissionais e científicos,
sustenta-se no interesse pessoal pelo tema, na necessidade de um estudo mais
profundo de como pode ser desenvolvido um projeto com utilização de linguagens
atuais. Tem-se a oportunidade de desenvolver um projeto utilizando-se a linguagem
de programação (JAVA) altamente utilizada no mercado atual, juntamente com todo
o processo de software para verificação dos requisitos iniciais bem como o
armazenamento dos dados da empresa em um banco de dados.
Este sistema utiliza tecnologias como Struts, Java Server Pages,
AS
Servlets, dentre outras, no desenvolvimento de uma aplicação para Web Service.
Isto poderá servir como objeto de estudo para futuras pesquisas acadêmicas e
científicas.
Organização do Trabalho
IN
1.5
O capítulo 2 consiste na descrição do problema e as características
básicas do sistema, bem como a apresentação da empresa Satika Óptica e Design,
IM
cuja as regras de negócio foram baseadas na mesma.
O capítulo 3 consiste na apresentação da análise e projeto do sistema,
exemplificado com os diagramas UML (Unified Modeling Language). Consistem em
descrição de Caso de Uso e atores, classes de análise, comportamento dinâmico e
UN
comportamento estático, juntamente com uma breve explicação dos mesmos.
O capítulo 4 refere-se à interface do sistema, serão apresentadas as
telas bem como os respectivos códigos juntamente com uma breve explicação das
tecnologias utilizadas.
O capítulo 5 será mostrado toda a parte de persistência dos dados
num banco de dados, bem como trechos de códigos responsáveis por tal atividade.
O capítulo 6 é descrito toda a arquitetura utilizada para o
desenvolvimento do sistema.
O capítulo 7 serão mostradas as conclusões obtidas no trabalho e
sugestões para a continuidade de trabalhos futuros.
20
2 DESCRIÇÃO DO PROBLEMA
A Satika Óptica & Design é uma empresa do ramo da optometria que
se trata de “uma ciência especializada no estudo da visão, especificamente nos
cuidados primários e secundários da saúde visual” (COSTA, 2008) e óptica que
comercializa óculos de grau, escuros e lentes.
Com mais de 30 anos no mercado, a empresa se mantém sólida com
um atendimento personalizado e de excelência, desenvolvendo e oferecendo o que
AS
há de melhor em produtos com intensa tecnologia e qualidade aos seus clientes.
Busca sempre estar à frente de seus concorrentes e satisfazendo cada vez mais
seus clientes.
Está no mercado uberlandense em três locais composta de uma matriz
IN
situada à R. Duque de Caxias, 146 figura 1, e duas filiais na Av. Santos Dumont,
UN
IM
548, figura 2 e Av. Raulino Cotta Pacheco, 242 figura 3.
Figura 1 - Loja matriz Rua Duque de Caxias
AS
21
UN
IM
IN
Figura 2 - Loja filial Avenida Santos Dumont
Figura 3 - Loja filial Avenida Raulino Cotta Pacheco
Atualmente a maioria dos processos executados pela Satika Óptica e
Design já são automatizadas. O sistema que a empresa possui hoje é baseado em
uma arquitetura cliente servidor para desktop.
Segundo Basham, Sierra e Bates(2005) a arquitetura cliente-servidor é
um modelo computacional que separa máquinas clientes e servidores. Sendo assim
estes computadores são interligados entre si geralmente utilizando-se uma rede de
computadores o objetivo foi construir uma aplicação que os computadores clientes
22
de qualquer ponto do planeta com permissão o sistema e acesso à web consigam
acessar as informações contidas no Satika System.
Cada filial possui uma cópia do sistema que está instalado nas
estações de trabalho dos profissionais da Satika. O sistema tem uma base de dados
central acessada por todos os desktops clientes da empresa no qual estão
armazenados de forma persistente todos os dados e informações referentes ao
negócio da empresa. Cada desktop da franquia Satika envia requisições de dados
para o servidor conectado e espera pela resposta. Por sua vez, o servidor aceita tais
requisições, processando-as e retornando o resultado para o desktop.
Apesar do bom funcionamento, a diretoria da empresa tem o interesse
AS
de implementar novas funcionalidades no sistema, agilizando ainda mais os
processos e garantindo melhor desempenho em todos os processos da empresa. O
desejo baseia-se, principalmente, na visão da empresa que se fundamenta na
seguinte idéia: “Expandir o número de franquias com excelência em atendimento,
IN
produtos e serviços”.
Para que essa visão possa ser alcançada, verificou-se a necessidade
do desenvolvimento de um sistema que permita ser acessado de qualquer desktop,
sem a necessidade de uma instalação prévia e que fosse de fácil manutenção. Com
IM
isto, espera-se que o desenvolvimento de um sistema web que consiga unir todas
as funcionalidades que a empresa já possui, faça com que suas franquias
compartilhem informações de uma maneira mais dinâmica e, principalmente, em
tempo real.
UN
O projeto Satika System baseia-se na implementação de um sistema
baseado na arquitetura web. Este sistema será de gestão de negócios e utilizará
novas
tecnologias
de
desenvolvimento
para
aplicações
Web,
tais
quais
armazenamento persistente estruturado, layout que facilita e agiliza sua usabilidade,
e tecnologia de desenvolvimento JAVA. Com isto, possibilitará a criação de uma
aplicação em que o cliente poderá desempenhar as funções básicas de sua
empresa que compreendam cadastros, alterações, exclusões e consultas, bem
como a visualização de relatórios funcionais e gerenciais que ajudam a direção da
empresa na obtenção de informações para a tomada de decisões estratégicas para
o negócio.
No sistema são manipuladas informações referentes a colaboradores
que compreendem clientes, funcionários, médicos e fornecedores. Com relação aos
23
processos de negócio, deverão ser armazenadas informações referentes a produtos
em estoque e compra e venda de produtos.
Todas essas informações armazenadas servirão de insumos para a
elaboração de relatórios gerencias que podem ser gerados quando necessário ou
automaticamente.
Para o levantamento desses e demais requisitos foram realizados três
visitas à empresa. Na primeira visita foram descritos os principais requisitos e nas
demais foram identificadas e sanadas as principais dúvidas para aprimoramento das
idéias propostas pela empresa, visando sempre ter um sistema que atenda todas as
necessidades funcionais da Satika e que venha agregar facilidades ao negócio. Em
AS
cada visita à empresa foram elaboradas as atas de reunião conforme modelo
mostrado na figura 4. Nestas reuniões foram levantados vários requisitos para o
sistema que será demonstrado neste documento. Estes requisitos referem-se às
dia com este software.
IN
necessidades dos usuários do sistema, ou seja, aqueles que vão trabalhar no dia-aPara que sejam percebidos quais são tais requisitos realizaram-se
vários contatos com o cliente, várias reuniões a fim de avaliar as suas reais
necessidades. É de fundamental importância a compreensão total dos requisitos
IM
apontados pelo cliente durante as reuniões, para se obter sucesso no
desenvolvimento do software. Esta análise de requisitos é para garantir o
desenvolvimento de acordo com modelo de negócio e com as funcionalidades do
sistema. É de suma importância também perceber que quando existem erros na
UN
definição requisitos geralmente serão percebidos na fase de testes, sendo que a
detecção tardia poderá, até mesmo, inviabilizar o projeto.
Estas reuniões mostraram para o cliente todas as funcionalidades
desenvolvidas e foi mostrado um modelo de layout da página do sistema e antes de
repassar os requisitos para o desenvolvimento do sistema foi validado com a Satika
para possíveis sugestões de melhorias e facilidades, é apresentado no quadro 1 a
ata de reunião que foi utilizada para documentar as reuniões.
IN
AS
24
Quadro 1 - Modelo de ata de reunião
IM
Sabe-se que para ter um software de qualidade é necessário um
cronograma para mapear prazos, responsabilidades e desta forma cumprir a
contento a entrega dos módulos solicitados.
O desenvolvimento do software deverá cumprir com todas as
UN
solicitações feitas pelo cliente desde a primeira reunião estando estas registradas no
levantamento de requisitos mostrado no quadro 2.
25
IN
AS
Requisitos funcionais
Efetuar Login
Efetuar Logout
Cadastrar Cliente
Cadastrar Funcionário
Cadastrar Médico
Cadastrar Fornecedor
Cadastrar Receituário
Cadastrar Produto
Registrar Venda
Registrar Compra
Atualizar Dados Cadastrais do Cliente
Atualizar Dados Cadastrais do Funcionário
Atualizar Dados Cadastrais do Fornecedor
Atualizar Dados Cadastrais do Receituário
Atualizar Dados Cadastrais do Produto
Atualizar Dados Cadastrais do Médico
Remover Dados Cadastrais, Vendas e Compras
Gerar Relatórios Melhores Clientes
Gerar Relatórios Produtos mais Vendidos
UN
IM
Requisitos Não-funcionais
1) A aplicação será construída utilizando as seguintes tecnologias: Servlets;
Java Server Pages; Struts; EJB; Hibernate; Java script; XML; 25TML Forms
e o banco de dados MySql.
2) Nem todas as funcionalidades do sistema estarão disponíveis através da
Web, neste, as operações poderão ser feitas diretamente no banco de
dados.
3) A codificação Java deverá ser feita de acordo com as convenções adotadas
pela SUN. Maiores informações no endereço:
http://java.sun.com/docs/codeconv/
4)
Deverá ser utilizado o padrão de Projeto J2EE para o
desenvolvimento da aplicação WEB.
Quadro 2 - Requisitos funcionais e não funcionais
26
3
ANÁLISE DO SISTEMA
3.1
Análise de sistema utilizando a UML
Entende-se como análise de sistemas,
AS
[...] a atividade inicial de desenvolvimento de sistemas em que se
determina e especifica o que um sistema deve fazer, bem como
circunstâncias pelas quais deve operar, envolvendo geralmente um esforço
colaborativo entre analistas de sistemas e utilizadores, no qual os primeiros
procuram obter a partir dos segundos, num processo gradual e cumulativo,
o maior conhecimento possível a cerca do domínio do discurso do sistema
e respectivo ambiente (ROCHA, 2004, p. 13).
O desenvolvimento de sistemas de software tem como base os
métodos de análise e projeto que modelam tal sistema de modo a fornecer para toda
a equipe envolvida (cliente, analista e programador) uma compreensão única do
IN
projeto.
A análise enfatiza a investigação do problema. O objetivo é levar o analista
a investigar e a descobrir. Para que essa etapa seja realizada em menos
tempo e com maior precisão, deve-se ter um bom método de trabalho
(WAZLAWICK, 2004, v. 4, p. 20).
IM
A Linguagem de Modelagem Unificada é uma linguagem “unificadora”
de notações, diagramas e formas de representação existentes em diferentes
técnicas. É uma linguagem gráfica para visualização, especificação, construção e
documentação de artefatos de sistemas complexos de software. Ela proporciona
UN
uma forma-padrão para a preparação de planos de arquitetura de projetos de
sistemas, incluindo aspectos conceituais como processos de negócio e funções do
sistema, além de itens concretos como as classes escritas em determinadas
linguagens de programação, esquemas de banco de dados e componentes de
software reutilizáveis.
A UML é uma linguagem muito expressiva, abrangendo todas as
visões necessárias ao desenvolvimento e implantação de sistema. É independente
tanto de linguagens de programação quanto de processos de desenvolvimento. Isso
quer dizer que a UML pode ser utilizada para a modelagem de sistemas, não
importa qual linguagem de programação será utilizada na implementação do
sistema, ou qual a forma de desenvolvimento adotada.
27
A UML é uma linguagem de modelagem visual, ou seja, é um conjunto de
notações e semântica correspondente para representar visualmente uma
ou mais perspectivas de um sistema (BEZERRA, 2002, v.9, p.17).
A modelagem é uma técnica de engenharia aprovada e bem aceita.
Um modelo é uma simplificação da realidade. Os modelos oferecem uma cópia do
projeto de um sistema, podendo abranger planos detalhados ou gerais. Todos os
sistemas podem ser descritos sob diferentes aspectos, com a utilização de modelos
distintos, e cada modelo será, portanto, uma abstração semântica específica do
sistema. Os modelos podem ser estruturais, dando ênfase à organização do
sistema, ou podem ser comportamentais, dando ênfase à dinâmica do sistema.
AS
É importante construir modelos para poder compreender melhor o
sistema que estamos desenvolvendo. Existem limites para a capacidade humana de
compreender complexidades. Com a ajuda da modelagem, delimitamos o problema
que estamos estudando, restringindo nosso foco a um único aspecto por vez.
IN
Para desenvolver software de forma rápida, eficiente e efetiva, com o
mínimo de desperdício e de retrabalho, será preciso dispor pessoas certas, com
ferramentas adequadas e no enfoque correto. Para fazer tudo isso de maneira
previsível e consistente, com uma avaliação dos custos reais do sistema, será
IM
necessário um processo seguro de desenvolvimento que possa ser adaptado às
necessidades do cliente.
Na tentativa de lidar com a complexidade do sistema e de minimizar os
problemas envolvidos no projeto de software, foi utilizado o chamado processo de
UN
desenvolvimento de software (ou simplesmente processo de desenvolvimento), que
compreende todas as atividades necessárias para definir, desenvolver, testar e
manter um produto de software. Alguns dos objetivos do processo de
desenvolvimento são: definir quais as atividades a serem executadas ao longo do
projeto; quando, como e por quem tais atividades serão executadas; prover pontos
de controle para verificar o andamento do projeto; padronizar a forma de
desenvolver o software.
Serão descritas abaixo algumas atividades típicas do processo de
desenvolvimento utilizado no projeto do sistema Satika:
levantamento de requisitos - a atividade de levantamento de
requisitos correspondente a etapa de compreensão do problema aplicado ao
desenvolvimento de software. Seu objetivo principal é o entendimento por parte de
28
usuários, desenvolvedores e clientes, nas funcionalidades que o sistema deverá
possuir, para que os futuros usuários possam utilizar o software de acordo com as
suas necessidades. É a etapa onde são feitas reuniões no intuito de levantar e
definir quais os requisitos o sistema deve conter.
análise de requisitos - é a etapa na qual os analistas realizam um
estudo detalhado dos requisitos levantados na etapa anterior a partir desse estudo,
são construídos os modelos para representar o sistema a ser desenvolvido. Assim
como a etapa de levantamento de requisitos, a análise de requisitos não leva em
conta o ambiente a ser utilizado; o objetivo é tentar construir uma solução sem se
preocupar com a maneira de como será realizada. Nesta fase começaram a ser
AS
definidos os requisitos funcionais e não funcionais, e iniciou a elaboração de um
planejamento detalhado para o ciclo de vida de desenvolvimento do sistema do
projeto Satika. Durante as duas primeiras visitas os requisitos foram coletados,
validados e aprovados de acordo com as políticas e metodologias adotadas pela
IN
empresa. Foram também identificados os controles internos e os requisitos de
segurança, pois são de suma importância nessa fase afim de que não acarretem em
sérios problemas futuros. É claro que durante as fases seguintes do projeto muitos
requisitos foram modificados, pois com o tempo acaba se adquirindo um melhor
fase.
IM
entendimento do problema. No entanto a idéia principal do sistema foi definida nessa
O sistema deverá possibilitar ao usuário:
cadastro
de
clientes,
funcionários,
fornecedores,
médicos
e
UN
receituário do cliente;
alteração de dados cadastrais;
exclusão de dados cadastrais;
pesquisa de dados no sistema;
emissão de relatório contendo os dados dos clientes que fizeram as
maiores compras na empresa;
emissão de relatório contendo os dados dos produtos que mais
foram vendidos pela empresa.
Ainda nessa fase foi preparado o Plano de Projeto Satika que definiu
os objetivos e as atividades para as fases seguintes, incluindo-se um cronograma. O
Plano de Projeto documenta a forma como este será executado para atingir o
29
objetivo para o qual foi criado. Não é fixo e por isso foi atualizado sempre que em
certos eventos tal atualização se justificava, como por exemplo, a ocorrência de um
risco ou uma mudança no escopo do projeto.
A seguir descreve-se cada fase da elaboração do plano de projeto:
projeto - diferentemente da etapa de análise de requisitos, o objetivo
da fase de projeto é “como” o sistema funcionará para atender os requisitos de
acordo com os recursos tecnológicos existentes. Na fase de projeto existem alguns
aspectos que devem ser considerados como: arquitetura o sistema, padrão de
interface gráfica a ser utilizada, a linguagem de programação, gerenciador de banco
de dados, entre outros. As atividades executadas durante esta fase resultaram na
AS
especificação da solução para os diversos aspectos que iriam compor o sistema:
funcionalidade (como os usuário verão o sistema), dados (modelos e estrutura dos
dados) e técnica (modelo de rede e de operação do sistema). O Plano de Projeto
maior precisão aos planos;
IN
nessa fase foi revisto novamente para espelhar as novas informações e fornecer
implementação - é a etapa onde o sistema é codificado, ou seja,
ocorre a transcrição em código da fase de projeto através do uso de uma linguagem
de programação;
IM
testes - diversas atividades de testes são realizadas para verificação
do sistema construído, levando-se em conta a especificação feita na fase de projeto.
O resultado é o relatório de testes, contendo informações sobre erros detectados no
sistema, logo após são feitas as correções e o que se tem é o resultado, isto é,
UN
finalmente o produto de software;
Implantação - o sistema é instalado e configurado no ambiente do
usuário. Os manuais do sistema são escritos e os usuários são treinados para
utilizar o sistema de forma correta.
É preciso ter em mente que para construir bons softwares, o problema
não se restringirá a uma questão de escrever uma grande quantidade de software de fato o segredo está em criar o código correto e pensar em como será possível
elaborar menos software - mas também ficar atento a possíveis vulnerabilidades,
que podem acarretar grandes prejuízos para a empresa. Isso faz com que o
desenvolvimento de software de qualidade se torne uma questão de arquitetura,
processo e ferramentas.
30
3.1.1 Diagramas de Caso de Uso
Existe um diagrama na UML para representar casos de uso e seus atores.
A principal utilidade desse diagrama está no fato de se poder associar a
ele, caso se use uma ferramenta CASE, um conjunto de outros artefatos
que representam a interação entre os atores e o sistema (WAZLAWICK,
2004, v. 4, p. 47).
Um caso de uso é uma modelagem usada para descrever o que um
sistema deve fazer. São iterações entre atores e o sistema, isto é, ações do ator e
ações do sistema, sendo que os atores são quem sempre iniciam essa ação. É
elaborado através de um processo iterativo, no qual reuniões são realizadas com
AS
analistas juntamente com o cliente a fim de se ter uma especificação do sistema, em
que ambos devem estar de acordo. Na UML, o modelo de caso de uso consiste em
um diagrama que mostram os atores, os casos de uso e seus respectivos
relacionamentos. Tem como finalidade decidir e descrever os requisitos funcionais
IN
do sistema.
IM
O modelo de casos de uso é uma representação das funcionalidades
externamente observáveis do sistema e dos elementos externos ao sistema
que interagem com ele. Este modelo é parte integrante da especificação de
requisitos. Na verdade, o modelo de casos de uso molda os requisitos
funcionais do sistema. O diagrama UML utilizado na modelagem de casos de
uso é o diagrama de casos de uso (BEZERRA, 2002, v.9, p. 45).
A UML descreve um ator como sendo qualquer elemento externo (que
não faz parte do sistema) que interage (troca de informações) com o sistema. No
projeto Satika existe apenas um ator, o funcionário.
UN
O funcionário é o principal ator do sistema Satika sendo a pessoa que
atua diretamente no sistema e efetua todas as tarefas da empresa. É ele quem faz
os cadastros de clientes, de receituário, de médico, de fornecedores e de produtos.
É responsável também por efetuar as vendas com os clientes, fazer compras com os
fornecedores, gerar relatórios de produtos mais vendidos e também de melhores
clientes.
Com base na análise dos requisitos, obtido através de reuniões com o
cliente, foi possível desenvolver um diagrama de caso de uso que fornecesse uma
visão geral dos requisitos funcionais bem como seus atores, para que fossem
especificadas as reais necessidades do cliente, foram desenvolvidos dois diagramas
31
de Caso de Uso para o melhor entendimento conforme mostrado nas figura 4 e
UN
IM
IN
AS
figura 5.
Figura 4 - Diagrama de Caso de Uso 1
IN
AS
32
IM
Figura 5 - Diagrama de Caso de Uso 2
Com os diagramas das figura 4 figura 5, tem-se uma visão externa do
que o sistema deverá fazer; representa-se graficamente os atores, casos de uso e
UN
os relacionamentos de comunicação entre esses elementos. Cada elipse representa
um caso de uso que foi especificado na fase de análise de requisitos, o boneco
representa o ator (usuário) e o retângulo, a fronteira do sistema.
33
3.2
Especificações dos Casos de Uso
Nos dizeres de Bezerra (2002), um caso de uso define o uso de uma
parte da funcionalidade, sem revelar o comportamento e a estrutura de um sistema.
Especifica uma seqüência de iterações entre o sistema e os atores que o utilizam. É
feito através de descrições narrativas das iterações externas com o sistema.
AS
Todos os casos de uso da análise são do tipo essencial. Essencial, nesse
contexto, não significa importante ou fundamental, mas que ele é descrito
em um nível de discurso no qual apenas a “essência” das operações é
apresentada, em oposição à sua realização concreta. Em outras palavras,
o analista deve descrever “o que” acontece entre o usuário e o sistema,
sem, entretanto, informar “como” essa interação ocorre. O analista não
deve, portanto, na fase de análise, tentar descrever a tecnologia de
interface entre o sistema e o usuário (WAZLAWICK, 2004, v. 4, p. 63).
O modelo usado para descrever os casos de uso, os atores e a
documentação do caso de uso, utiliza os seguintes itens:
IN
nome - é o mesmo que aparece no diagrama de caso de uso;
sumário - é uma pequena descrição do caso de uso;
ator primário - nome do ator que inicia o caso de uso;
ator(s) secundário(s): nomes dos demais atores participantes do
IM
caso de uso;
pré-condição e pós-condição - define que hipóteses são assumidas
como verdadeiras para que se tenha início um caso de uso. E a pós-condição é a
UN
finalização do caso de uso, encerramento deste;
fluxo principal - descreve o que normalmente acontece quando o
caso de uso é realizado, é uma descrição da seqüência de passos;
fluxo alternativo - utilizado para descrever o que acontece quando o
ator faz uma escolha alternativa, diferente da descrita no fluxo principal, para
alcançar o seu objetivo;
fluxo de exceção - descrição de situações que acontecem quando
algo inesperado ocorre na iteração entre o caso de uso e o usuário;
regras de negócio - a descrição de caso de uso pode fazer uma
referencia a uma ou mais regras de negócio, são políticas, condições ou restrições.
Abaixo serão apresentadas as regras de negócios identificadas
referente aos casos de uso do Satika System no quadro 3.
34
RN-01
O funcionário precisa ser cadastrado no sistema e possuir usuário e senha.
RN-02
É necessário que o cliente deseje efetuar alguma compra na empresa.
RN-03
Para cadastrar receituário o cliente deve possuir cadastro no sistema.
RN-04
Para cadastrar funcionário é necessário que outro funcionário o cadastre.
RN-05
Fornecedor deve possuir número de CNPJ e Inscrição Estadual.
RN-06
Para efetuar o cadastro é necessário o preenchimento de todos os dados.
RN-07
Para efetuar o cadastro do produto é necessário que o fornecedor esteja
cadastrado no sistema.
Só poderá registrar uma compra se o fornecedor estiver cadastrado.
RN-09
Só poderá registrar uma venda se o cliente estiver cadastrado.
RN-10
Deverá fazer uma pesquisa do cliente antes de excluí-lo.
RN-11
Deverá fazer uma pesquisa do fornecedor antes de excluí-lo.
RN-12
Deverá fazer uma pesquisa do funcionário antes de excluí-lo.
RN-13
Deverá fazer uma pesquisa do médico antes de excluí-lo.
RN-14
Deverá fazer uma pesquisa do produto antes de excluí-lo.
RN-15
Deverá fazer uma pesquisa da venda antes de excluí-la.
RN-16
Deverá fazer uma pesquisa de compra antes de excluí-la.
RN-17
Deverá fazer uma pesquisa do receituário antes de excluí-lo.
RN-18
Para realizar uma pesquisa de cliente deverá ser informado nome ou CPF.
RN-19
Para realizar uma pesquisa de fornecedor deverá ser informado Razão
IM
IN
AS
RN-08
Social e CNPJ.
RN-20
Para realizar uma pesquisa de funcionário deverá ser informado nome ou
UN
CPF.
RN-21
Para realizar uma pesquisa de médico deverá ser informado nome ou CPF.
RN-22
Para realizar uma pesquisa de produto deverá ser informado o tipo ou a
grife.
RN-23
Para realizar uma pesquisa da venda deverá ser informada a data da
venda.
RN-24
Para realizar uma pesquisa da compra deverá ser informada a data da
compra.
RN-25
Para realizar uma pesquisa do receituário deverá ser informado nome ou
CPF.
RN-26
Para alterar dados do cliente deverá ser feito antes uma pesquisa do
35
mesmo.
RN-27
Para alterar dados do fornecedor deverá ser feito antes uma pesquisa do
mesmo.
RN-28
Para alterar dados do funcionário deverá ser feito antes uma pesquisa do
mesmo.
RN-29
Para alterar dados do médico deverá ser feito antes uma pesquisa do
mesmo.
RN-30
Para alterar dados do produto deverá ser feito antes uma pesquisa do
mesmo.
RN-31
Para alterar dados da venda deverá ser feito antes uma pesquisa do
RN-32
AS
mesmo.
Para alterar dados da compra deverá ser feito antes uma pesquisa do
mesmo.
Para alterar dados do receituário deverá ser feito antes uma pesquisa do
mesmo.
RN-34
IN
RN-33
Para gerar relatório Melhores Clientes é necessário informar o período de
venda a ser pesquisado.
RN-35
Para gerar relatório Produtos mais Vendidos é necessário informar o
IM
período de venda a ser pesquisado.
Quadro 3 - Regras de negócios
UN
Abaixo serão demonstrados os quadros com as especificações dos
casos de uso identificados no sistema.
36
No quadro 4 mostra-se o processo para realizar o login no sistema
Satika, descrevendo-se as etapas necessárias para a realização do mesmo.
Nome
Sumário
Efetuar Login
CSU-1
Descreve as etapas para realizar o login
AS
Ator primário: Funcionário
Ator(es) secundário(s): Funcionário
Pré-condição: A pessoa tem que ser funcionário da empresa e possuir usuário e senha
cadastrada.
Pós-condição: Funcionário terá acesso ao sistema.
Fluxo Principal
1. O sistema fornece os campos para preenchimento do login;
2. O funcionário digita o usuário e a senha;
3. O sistema lê o nome de usuário e a senha e valida o login;
4. O sistema exibe a tela inicial e o Menu com as funcionalidades;
5. O funcionário tem acesso ao sistema.
IN
Fluxo Alternativo [ ]:
Fluxo de Exceção [ 3 ]: Usuário e senha inválidos
IM
a. O sistema emite uma mensagem de erro, informando que o usuário ou a senha foram
preenchidos incorretamente.
b. O caso de uso retorna ao passo 1.
Regras de Negócio Associadas
UN
RN-01 O funcionário precisa ser cadastrado no sistema e possuir usuário e senha
Quadro 4 - Especificação do caso de uso: efetuar login
37
No quadro 5, é mostrado o processo para cadastrar um cliente no
sistema Satika, mostrando as etapas necessárias para a realização do mesmo bem
como os dados solicitados para sua realização.
Nome
Sumário
Cadastrar Cliente
CSU02
Descreve as etapas necessárias para cadastrar clientes.
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): Cliente
Pré-condição: O cliente deve efetuar alguma compra na empresa e usuário logado
Pós-condição: Cadastro do cliente concluído
Fluxo Principal
1. O funcionário seleciona opção de cadastro de clientes;
2. O sistema solicita o código do cliente para validação;
3. O sistema fornece formulário para preenchimento dos dados do cliente;
4. O funcionário entra com os dados do cliente (Nome, CPF, data de nascimento, e-mail,
telefone, endereço, cidade, estado, CEP);
5. O funcionário seleciona a opção de concluir o cadastro do cliente.
6. O sistema verifica se foram preenchidos todos os campos, se teve algum campo preenchido
incorretamente ou o número de CPF inválido.
7. O sistema armazena os dados cadastrados.
8. Sistema exibe mensagem de cadastro realizado com sucesso.
Fluxo Alternativo [ 1 ]: Desistência do cadastro de cliente
IM
a. Caso o funcionário não conclua ou desista de incluir o cadastro do cliente, o sistema volta ao
passo 1.
UN
Fluxo de Exceção [ 6 ]: Dados do cliente incorretos ou inválido.
a. O sistema emite uma mensagem de erro, caso tenha sido digitado número de CPF inválido.
b. O sistema emite uma mensagem de erro, caso tenha sido digitado algum dado
incorretamente.
c. O caso de uso retorna ao passo 3.
Regras de Negócio Associadas
RN - 02 É necessário que o cliente deseje efetuar alguma compra na empresa
Quadro 5 - Especificação do caso de uso: cadastrar cliente
38
No quadro 6, é mostrado o processo para cadastrar um receituário do
cliente no sistema Satika. São também mostradas as etapas necessárias para a
realização do mesmo, bem como os dados solicitados.
Nome
Cadastrar Receituário
CSU03
Sumário
Descreve as etapas necessárias para o cadastro do receituário
Ator primário: Funcionário
Ator(es) secundário(s): Cliente
Pré-condição: O cliente precisa efetuar pelo menos uma compra de óculos tendo em mãos a
prescrição do médico, e usuário esteja logado no sistema.
Pós-condição: Cadastro do receituário concluído.
IN
AS
Fluxo Principal
1. O funcionário seleciona opção de cadastrar receituário;
2. O funcionário seleciona opção de pesquisar pelo CPF ou nome do cliente para verificar se o
cliente é cadastrado no sistema;
3. O funcionário seleciona opção de pesquisar pelo CPF ou nome do médico para verificar se o
médico é cadastrado no sistema;
4. O sistema fornece formulário para preenchimento dos dados do receituário (data da
consulta, grau esquerdo, grau direito, eixo, prisma, estrios, cilíndrica, naso pupilar e lente);
5. O funcionário seleciona a opção de concluir o cadastro do receituário
6. O sistema verifica se foram preenchidos todos os campos ou se teve algum campo
preenchido incorretamente.
7. O sistema armazena os dados cadastrados.
8. Sistema exibe mensagem de cadastro realizado com sucesso.
IM
Fluxo Alternativo [ 1 ]: Desistência do cadastro do receituário
a. Caso o funcionário não conclua ou desista de incluir o cadastro do receituário, o sistema
volta ao passo 1.
UN
Fluxo de Exceção [ 2, 6 ]:, Caso cliente ou médico não cadastrados no sistema, ou não
preenchimento de dados
a. Caso funcionário entre com o nome ou CPF do cliente para pesquisar e o cliente não é
cadastrado. Sistema envia mensagem “cliente não cadastrado”;
b. Funcionário deverá primeiramente cadastrar o cliente.
c. Caso funcionário entre com o nome ou CPF do médico para pesquisar e o médico não é
cadastrado. Sistema envia mensagem “médico não cadastrado”;
d. Funcionário deverá primeiramente cadastrar o médico.
e. Sistema volta ao passo 3.
f. Sistema envia mensagem “realmente deseja não incluir este dado do receituário?”;
g. Sistema obtém confirmação;
h. Sistema volta ao passo 7.
Regras de Negócio Associadas
RN - 03 Para cadastrar receituário o cliente deve possuir cadastro no sistema.
Quadro 6 - Especificação do caso de uso: cadastrar receituário
39
No quadro 7, é mostrado o processo para cadastrar um funcionário no
sistema Satika, representando as etapas necessárias para a realização do mesmo
bem como os dados solicitados.
Nome
Sumário
Cadastrar Funcionário
CSU04
Descreve as etapas necessárias para o cadastro do funcionário
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): Funcionário
Pré-condição: Necessário que a pessoa faça parte da equipe de funcionários da empresa, e
um usuário esteja logado no sistema para realizar o cadastro.
Pós-condição: Cadastro de funcionário concluído.
Fluxo Principal
1. O funcionário seleciona opção de cadastro de funcionário;
2. O sistema solicita o código do funcionário para validação;
3. O sistema fornece formulário para preenchimento dos dados do funcionário;
4. O funcionário entra com os dados do funcionário (Nome, CPF, Carteira de trabalho, data de
nascimento, telefone, endereço, cidade, estado, CEP, usuário e senha);
5. O funcionário seleciona a opção de concluir o cadastro do funcionário.
6. O sistema verifica se foram preenchidos todos os campos, se teve algum campo preenchido
incorretamente ou o número de CPF do funcionário é inválido.
7. O sistema armazena os dados cadastrados.
8. Sistema exibe mensagem de cadastro realizado com sucesso.
IM
Fluxo Alternativo [ 1 ]: Desistência cadastro funcionário
a. Caso o funcionário não conclua ou desista de incluir o cadastro do funcionário, o sistema
volta ao passo 1.
UN
Fluxo de Exceção [ 6 ]: Caso CPF do funcionário for inválido ou outro dado preenchido errado
incorretos ou inválido.
a. O sistema emite uma mensagem de erro, caso tenha sido digitado número de CPF inválido.
b. O sistema emite uma mensagem de erro, caso tenha sido digitado algum dado
incorretamente.
c. O caso de uso retorna ao passo 3.
Regras de Negócio Associadas
RN - 4 Para cadastrar funcionário é necessário que outro funcionário o cadastre.
Quadro 7 - Especificação do caso de uso: cadastrar funcionário
40
No quadro 8 é mostrado o processo para cadastrar um funcionário no
sistema Satika, descrevendo-se as etapas necessárias para a realização do mesmo
bem como os dados solicitados.
Nome
Sumário
Cadastrar Fornecedor
CSU05
Descreve as etapas necessárias para o cadastro do fornecedor
Ator primário: Funcionário
Ator(es) secundário(s): Fornecedor
Pré-condição: Ter CNPJ e Inscrição Estadual
Pós-condição: Cadastro do fornecedor concluído.
Fluxo Principal
IM
IN
AS
1. O funcionário seleciona opção de cadastro de fornecedor;
2. O sistema solicita o código do fornecedor para validação;
3. O sistema fornece formulário para preenchimento dos dados do fornecedor;
4. O funcionário entra com os dados do fornecedor (Razão Social, Inscrição Estadual, CNPJ,
telefone, fax, endereço, cidade, CEP, contato da empresa, e-mail);
5. O funcionário seleciona a opção de concluir o cadastro do fornecedor.
6. O sistema verifica se foram preenchidos todos os campos, se teve algum campo preenchido
incorretamente ou o número de CNPJ da empresa é inválido.
7. O sistema armazena os dados cadastrados.
8. Sistema exibe mensagem de cadastro realizado com sucesso.
9. Sistema exibe mensagem de cadastro realizado com sucesso.
Fluxo Alternativo [ 1 ]: Desistência de cadastro de fornecedor
a. Caso o funcionário não conclua ou desista de incluir cadastro do fornecedor, o sistema volta
ao passo 1.
UN
Fluxo de Exceção [ 6 ]: Caso CNPJ do fornecedor for inválido ou outro dado preenchido
errado.
a. O sistema emite uma mensagem de erro, caso tenha sido digitado número de CPF inválido.
b. O sistema emite uma mensagem de erro, caso tenha sido digitado algum dado
incorretamente.
c. O caso de uso retorna ao passo 3.
Regras de Negócio Associadas
RN - 05 Fornecedor deve possuir número de CNPJ e Inscrição Estadual.
Quadro 8 - Especificação do caso de uso: cadastrar fornecedor
No quadro 9 é mostrado o processo para cadastrar um médico no
sistema Satika, descrevendo-se as etapas necessárias para a realização do mesmo,
bem como os dados solicitados.
41
Nome
Sumário
Cadastrar Médico
CSU06
Descreve as etapas necessárias para o cadastro do médico
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): Médico
Pré-condição: Necessário o médico constar no receituário do cliente, e usuário esteja logado
no sistema.
Pós-condição: Cadastro do médico concluído.
Fluxo Principal
1. O funcionário seleciona opção de cadastro de Médico;
2. O sistema solicita o código do médico para validação;
3. O sistema fornece formulário para preenchimento dos dados do médico;
4. O funcionário entra com os dados do médico (Nome, CPF, CRM, clínica, data de
nascimento, e-mail, telefone, endereço, cidade, estado, CEP);
5. O funcionário seleciona a opção de concluir o cadastro do médico.
6. O sistema verifica se foram preenchidos todos os campos, se teve algum campo preenchido
incorretamente ou o número de CPF do médico é inválido.
7. O sistema armazena os dados cadastrados.
8. Sistema exibe mensagem de cadastro realizado com sucesso.
Fluxo Alternativo [ 1 ]: Desistência de cadastro médico
IM
a. Caso o funcionário não conclua ou desista de incluir o cadastro do médico, o sistema volta
ao passo 1.
Fluxo de Exceção [ 6 ]: Caso CPF do médico for inválido ou outro dado for preenchido errado.
UN
a. O sistema emite uma mensagem de erro, caso tenha sido digitado número de CPF inválido.
b. O sistema emite uma mensagem de erro, caso tenha sido digitado algum dado
incorretamente.
c. O caso de uso retorna ao passo 3.
Regras de Negócio Associadas
RN - 06 Para efetuar o cadastro é necessário o preenchimento de todos os dados
Quadro 9 - Especificação do caso de uso: cadastrar médico
42
No quadro 10 é mostrado o processo para cadastrar um produto no
sistema Satika, representando-se as etapas necessárias para a realização do
mesmo bem como, os dados solicitados.
Nome
Sumário
Cadastrar Produto
CSU07
Descreve as etapas necessárias para o cadastro de produtos
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): Funcionário
Pré-condição: Necessário os dados dos produtos a serem cadastrados e que este possua um
fornecedor, e que o usuário esteja logado no sistema.
Pós-condição: Cadastro dos produtos concluído.
Fluxo Principal
1. O funcionário seleciona opção de cadastrar produto;
2. O sistema solicita o código do produto para validação;
3. O sistema fornece formulário para preenchimento dos dados do produto (descrição, tipo
normal, tipo grife, nome da grife, cor e preço);
4. O funcionário entra com os dados do produto;
5. O funcionário seleciona a opção de concluir o cadastro do produto.
6. O sistema verifica se foram preenchidos todos os campos, se teve algum campo preenchido
incorretamente.
7. O sistema armazena os dados cadastrados.
8. Sistema exibe mensagem de cadastro realizado com sucesso.
Fluxo Alternativo [ 1 ]: Desistência de cadastro de produto
IM
a. Caso o funcionário não conclua ou desista de incluir o cadastro de produto, o sistema volta
ao passo 1.
UN
Fluxo de Exceção [ 6 ]: Caso algum dado preenchido errado
b. O sistema emite uma mensagem de erro, caso tenha sido digitado algum dado
incorretamente.
c. O caso de uso retorna ao passo 3.
Regras de Negócio Associadas
RN - 07 Para efetuar o cadastro do produto é necessário que o fornecedor esteja cadastrado
no sistema.
Quadro 10 - Especificação do caso de uso: cadastrar produto
43
No quadro 11 é mostrado o processo para registrar uma compra no
sistema Satika, descrevendo-se as etapas necessárias para a realização do mesmo
bem como, os dados solicitados. O ator só poderá registrar a compra se o
fornecedor já for cadastrado no sistema.
Nome
Sumário
Registrar Compra
CSU08
Descreve as etapas necessárias para registrar compra com fornecedor
IM
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): Funcionário
Pré-condição: Necessário escolher o produto a ser comprado, e que o usuário esteja logado
no sistema.
Pós-condição: Registro de compra concluído
Fluxo Principal
1. O funcionário seleciona opção de registrar compra;
2. Sistema solicita os dados do cliente (CNPJ ou Nome da empresa);
3. O funcionário informa o CNPJ ou o nome da empresa;
4. O sistema fornece formulário para preenchimento dos dados do registro (forma de
pagamento, quantidade de parcelas, observações e os produtos);
5. O funcionário entra com os dados do registro de compra;
6. O funcionário seleciona a opção de concluir o registro de compra.
7. O sistema verifica se foram preenchidos todos os campos, se teve algum campo preenchido
incorretamente.
8. O sistema armazena os dados cadastrados.
9. Sistema exibe mensagem de cadastro realizado com sucesso.
Fluxo Alternativo [ 1 ]: Desistência de registro de compra
a. Caso o funcionário não conclua ou desista de incluir o registro de compra, o sistema volta ao
passo 1.
UN
Fluxo de Exceção [ 2, 6 ]: Caso CNPJ ou o nome do fornecedor for inválido ou outro dado for
preenchido errado.
a. Caso funcionário entre com o nome ou CNPJ do fornecedor para pesquisar e o fornecedor
não é cadastrado, o sistema envia mensagem “fornecedor não cadastrado”;
b. Funcionário deverá primeiramente cadastrar o fornecedor.
c. O sistema emite uma mensagem de erro, caso tenha sido digitado algum dado
incorretamente.
d. O caso de uso retorna ao passo 2.
Regras de Negócio Associadas
RN - 08 Só pode registrar compra com fornecedor já cadastrado.
Quadro 11 - Especificação do caso de uso: registrar compra
O quadro 12 exemplifica o processo para registrar uma venda no
sistema Satika, mostrando as etapas necessárias para a realização do mesmo bem
44
como, os dados solicitados. O ator só poderá registrar a venda se o cliente já for
cadastrado no sistema.
Nome
Sumário
Registrar Venda
CSU09
Descreve as etapas necessárias para registrar uma venda
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): Funcionário
Pré-condição: Necessário que o cliente tenha efetuado uma compra, e que o usuário esteja
logado no sistema.
Pós-condição: Registro de venda concluído.
Fluxo Principal
1. O funcionário seleciona opção de registrar compra;
2. Sistema solicita os dados do cliente (CPF ou Nome do cliente);
3. O funcionário informa o CPF ou o nome do cliente;
4. O sistema fornece formulário para preenchimento dos dados do registro (forma de
pagamento, quantidade de parcelas, observações e os produtos);
5. O funcionário entra com os dados do registro de venda;
6. O funcionário seleciona a opção de concluir o registro de venda.
7. O sistema verifica se foram preenchidos todos os campos, se teve algum campo preenchido
incorretamente.
8. O sistema armazena os dados cadastrados.
9. Sistema exibe mensagem de cadastro realizado com sucesso.
IM
Fluxo Alternativo [ 1 ]: Desistência de registro de venda
a. Caso o funcionário não conclua ou desista de incluir o registro de venda, o sistema volta ao
passo 1.
Fluxo de Exceção [ 2, 6 ]: Caso CPF ou o nome do cliente for inválido ou outro dado for
preenchido errado.
UN
a. Caso funcionário entre com o nome ou CPF do cliente para pesquisar e o cliente não é
cadastrado, o sistema envia mensagem “cliente não cadastrado”;
b. Funcionário deverá primeiramente cadastrar o cliente.
c. O sistema emite uma mensagem de erro, caso tenha sido digitado algum dado
incorretamente.
d. O caso de uso retorna ao passo 2.
Regras de Negócio Associadas
RN - 9 Só pode registrar venda com fornecedor já cadastrado.
Quadro 12 - Especificação do caso de uso: registrar venda
45
Mostra-se no quadro 13, é mostrado o processo para excluir um cliente
no sistema Satika, descrevendo as etapas necessárias para a realização do mesmo
bem como, os dados solicitados. O ator só poderá excluir um cliente após a
pesquisa do mesmo e confirmar a exclusão.
Nome
Sumário
Excluir Cliente
CSU10
Descreve as etapas necessárias para excluir cliente
IM
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): Cliente
Pré-condição: Cliente já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Exclusão do cliente concluído
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo nome do cliente ou CPF;
2. O funcionário entra com o nome ou CPF do cliente para fazer a pesquisa e clica em
pesquisar;
3. Sistema carrega os dados do cliente pesquisado e exibe para o funcionário;
4. O funcionário seleciona opção de excluir cadastro do cliente;
5. O sistema emite mensagem de confirmação de exclusão;
6. O funcionário confirma a exclusão;
7. O sistema é carregado;
8. O sistema exclui o cadastro do cliente.
9. Sistema exibe mensagem de exclusão realizado com sucesso.
Fluxo Alternativo [ 3 ]: Desistência da exclusão
UN
a. Caso o funcionário veja que o cliente exibido após a pesquisa não é o que ele deseja excluir,
o sistema fornece opção de voltar para fazer uma nova pesquisa.
Fluxo de Exceção [ 3 ]: Caso CPF e nome inválido ou CPF e nome não encontrado
a. Caso funcionário entre com o nome ou CPF do cliente para pesquisar e o cliente não é
cadastrado ou não encontrado, o sistema envia mensagem “Nenhum cliente foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 2.
Regras de Negócio Associadas
RN 10 - Deverá fazer uma pesquisa do cliente antes de excluí-lo.
Quadro 13 - Especificação do caso de uso: excluir cliente
O quadro 14 exemplifica o processo para excluir um fornecedor no
sistema Satika, mostrando as etapas necessárias para a realização do mesmo bem
46
como, os dados solicitados. O ator só poderá excluir um fornecedor após a pesquisa
do mesmo e confirmar a exclusão.
Nome
Sumário
Excluir Fornecedor
CSU11
Descreve as etapas necessárias para excluir receituário
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): Fornecedor
Pré-condição: Fornecedor já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Exclusão do fornecedor concluído
Fluxo Principal
1. O sistema fornece formulário de pesquisa pela Razão Social do fornecedor ou CNPJ;
2. O funcionário entra com a Razão Social ou CNPJ do fornecedor para fazer a pesquisa e
clica em pesquisar;
3. Sistema carrega os dados do fornecedor pesquisado e exibe para o funcionário;
4. O funcionário seleciona opção de excluir cadastro do fornecedor;
5. O sistema emite mensagem de confirmação de exclusão;
6. O funcionário confirma a exclusão;
7. O sistema é carregado;
8. O sistema exclui o cadastro do cliente.
9. Sistema exibe mensagem de exclusão realizado com sucesso.
IM
Fluxo Alternativo [ 3 ]: Desistência de exclusão
a. Caso o funcionário veja que o fornecedor exibido após a pesquisa não é o que ele deseja
excluir, o sistema fornece opção de voltar para fazer uma nova pesquisa.
Fluxo de Exceção [ 2 ]: Caso CPF e nome inválido ou CPF e nome não encontrado
UN
a. Caso funcionário entre com a Razão Social ou CNPJ do fornecedor para pesquisar e o
fornecedor não é cadastrado ou não encontrado, o sistema envia mensagem “Nenhum
fornecedor foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 2.
Regras de Negócio Associadas
RN - 11 Deverá fazer uma pesquisa do fornecedor antes de excluí-lo.
Quadro 14 - Especificação do caso de uso: excluir fornecedor
47
O quadro 15 demonstra o processo para excluir um funcionário no
sistema Satika, mostrando as etapas necessárias, bem como os dados solicitados
para sua realização. O ator só poderá excluir um funcionário após a pesquisa do
mesmo e confirmar a exclusão.
Nome
Sumário
Excluir Funcionário
CSU12
Descreve as etapas necessárias para excluir funcionário
IM
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): Funcionário
Pré-condição: Funcionário já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Exclusão do funcionário concluído
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo nome do funcionário ou CPF;
2. O funcionário entra com o nome ou CPF do funcionário para fazer a pesquisa e clica em
pesquisar;
3. Sistema carrega os dados do funcionário pesquisado e exibe para o funcionário;
4. O funcionário seleciona opção de excluir cadastro do funcionário;
5. O sistema emite mensagem de confirmação de exclusão;
6. O funcionário confirma a exclusão;
7. O sistema é carregado;
8. O sistema exclui o cadastro do cliente.
9. Sistema exibe mensagem de exclusão realizado com sucesso.
Fluxo Alternativo [ 3 ]: Desistência da exclusão
a. Caso o funcionário veja que o funcionário exibido após a pesquisa não é o que ele deseja
excluir, o sistema fornece opção de voltar para fazer uma nova pesquisa.
UN
Fluxo de Exceção [ 2 ]: Caso CPF e nome inválido ou CPF e nome não encontrado
a. Caso funcionário entre com o nome ou CPF do funcionário para pesquisar e o funcionário
não é cadastrado ou não encontrado, o sistema envia mensagem “Nenhum funcionário foi
encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 2.
Regras de Negócio Associadas
RN - 12 Deverá ser feito uma pesquisa do funcionário antes de excluí-lo.
Quadro 15 - Especificação do caso de uso: excluir funcionário
No quadro 16 é mostrado o processo para excluir um médico no
sistema Satika, representando as etapas necessárias, bem como os dados
48
solicitados para sua realização. O ator só poderá excluir um médico após a pesquisa
do mesmo e confirmar a exclusão.
Nome
Excluir Médico
CSU13
IN
AS
Sumário
Descreve as etapas necessárias para excluir médico
Ator primário: Funcionário
Ator(es) secundário(s): Médico
Pré-condição: Médico já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Exclusão do médico concluído
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo nome do médico ou CPF;
2. O funcionário entra com o nome ou CPF do médico para fazer a pesquisa e clica em
pesquisar;
3. Sistema carrega os dados do médico pesquisado e exibe para o funcionário;
4. O funcionário seleciona opção de excluir cadastro do médico;
5. O sistema emite mensagem de confirmação de exclusão;
6. O funcionário confirma a exclusão;
7. O sistema é carregado;
8. O sistema exclui o cadastro do cliente.
9. Sistema exibe mensagem de exclusão realizado com sucesso.
IM
Fluxo Alternativo [ 3 ]: Desistência de exclusão
a. Caso o funcionário veja que o médico exibido após a pesquisa não é o que ele deseja
excluir, o sistema fornece opção de voltar para fazer uma nova pesquisa.
Fluxo de Exceção [ 2 ]: Caso CPF e nome inválido ou CPF e nome não encontrado
UN
a. Caso funcionário entre com o nome ou CPF do médico para pesquisar e o médico não é
cadastrado ou não encontrado, o sistema envia mensagem “Nenhum médico foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 2.
Regras de Negócio Associadas
RN - 13 Deverá ser feito uma pesquisa do médico antes de excluí-lo.
Quadro 16 - Especificação do caso de uso: excluir médico
49
No quadro 17 demonstra-se o processo para excluir um produto no
sistema Satika, mostrando as etapas necessárias, bem como os dados solicitados
para sua realização. O ator só poderá excluir um produto após a pesquisa do
mesmo e confirmar a exclusão.
Nome
Sumário
Excluir Produto
CSU14
Descreve as etapas necessárias para excluir produto
IM
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Produto já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Exclusão do produto concluído
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo tipo do produto nacional ou de grife;
2. O funcionário seleciona opção do produto para pesquisa e clica em pesquisar;
3. Sistema carrega os dados do produto pesquisado e exibe para o funcionário;
4. O funcionário seleciona opção de excluir cadastro do produto;
5. O sistema emite mensagem de confirmação de exclusão;
6. O funcionário confirma a exclusão;
7. O sistema é carregado;
8. O sistema exclui o cadastro do cliente.
9. Sistema exibe mensagem de exclusão realizado com sucesso.
Fluxo Alternativo [ 3 ]: Desistência de exclusão
a. Caso o funcionário veja que o produto exibido após a pesquisa não é o que ele deseja
excluir, o sistema fornece opção de voltar para fazer uma nova pesquisa.
UN
Fluxo de Exceção [ 2 ]: Caso produto não encontrado
a. Caso funcionário selecione o tipo do produto para pesquisar e o produto não é cadastrado
ou não encontrado, o sistema envia mensagem “Nenhum produto foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 2.
Regras de Negócio Associadas
RN - 14 Deverá ser feito uma pesquisa do produto antes de excluí-lo.
Quadro 17 - Especificação do caso de uso: excluir produto
O quadro 18 exemplifica o processo para excluir um registro de venda
no sistema Satika, mostrando as etapas necessárias, bem como os dados
50
solicitados para sua realização. O ator só poderá excluir uma venda após a pesquisa
do mesmo através de um cliente e confirmar a exclusão.
Nome
Sumário
Excluir Registro de Venda
CSU15
Descreve as etapas necessárias para excluir venda realizada
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Venda já realizada, e que o usuário esteja logado no sistema.
Pós-condição: Exclusão de venda concluída.
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo nome do cliente ou CPF;
2. O funcionário entra com o nome ou CPF do cliente para fazer a pesquisa e clica em
pesquisar;
3. Sistema carrega os dados da venda realizada e exibe para o funcionário;
4. O funcionário seleciona a venda que deseja excluir;
5. O sistema emite mensagem de confirmação de exclusão;
6. O funcionário confirma a exclusão;
7. O sistema é carregado;
8. O sistema exclui o cadastro do cliente.
9. Sistema exibe mensagem de exclusão realizado com sucesso.
IM
Fluxo Alternativo [ 3 ]: Desistência de exclusão
a. Caso o funcionário veja que a venda exibida após a pesquisa não é o que ele deseja excluir,
o sistema fornece opção de voltar para fazer uma nova pesquisa.
Fluxo de Exceção [ 2 ]: Caso não houve venda na data escolhida.
UN
a. Caso funcionário entre com uma data para pesquisar e a data é inválida ou não encontrada,
o sistema envia mensagem “Nenhuma venda foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 2.
Regras de Negócio Associadas
RN - Deverá ser feita uma pesquisa de venda antes de excluí-la.
Quadro 18 - Especificação do caso de uso: excluir registro de venda
51
No quadro 19 é mostrado o processo para excluir uma compra no
sistema Satika, representando-se as etapas necessárias, bem como os dados
solicitados para sua realização. O ator só poderá excluir uma compra após a
pesquisa do mesmo através de um fornecedor e confirmar a exclusão.
Nome
Sumário
Excluir Registro de Compra
CSU16
Descreve as etapas necessárias para excluir compra realizada
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Compra já realizada, e que o usuário esteja logado no sistema.
Pós-condição: Exclusão de compra concluída.
Fluxo Principal
1. O sistema fornece formulário de pesquisa pela data da compra;
2. O funcionário entra com o CNPJ ou razão social para fazer a pesquisa e clica em pesquisar;
3. Sistema carrega os dados da compra realizada na data escolhida e exibe para o funcionário;
4. O funcionário seleciona a compra que deseja excluir;
5. O sistema emite mensagem de confirmação de exclusão;
6. O funcionário confirma a exclusão;
7. O sistema é carregado;
8. O sistema exclui o cadastro do cliente.
9. Sistema exibe mensagem de exclusão realizado com sucesso.
IM
Fluxo Alternativo [ 3 ]: Desistência de exclusão
a. Caso o funcionário veja que a compra exibida após a pesquisa não é o que ele deseja
excluir, o sistema fornece opção de voltar para fazer uma nova pesquisa.
UN
Fluxo de Exceção [ 2 ]: Caso não houve compra na data escolhida.
a. Caso funcionário entre com uma data para pesquisar e a data é inválida ou não encontrada,
o sistema envia mensagem “Nenhuma compra foi encontrada”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 2.
Regras de Negócio Associadas
RN - 16 Deverá ser feita uma pesquisa de compra antes de excluí-la.
Quadro 19 - Especificação do caso de uso: excluir registro de compra
No quadro 20 demonstra-se o processo para excluir um receituário do
cliente no sistema Satika, mostrando as etapas necessárias, bem como os dados
52
solicitados para sua realização. O ator só poderá excluir um receituário após a
pesquisa do mesmo através de um cliente e confirmar a exclusão.
Nome
Sumário
Excluir Receituário
CSU17
Descreve as etapas necessárias para excluir receituário
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Receituário cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Exclusão de receituário concluído.
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo nome ou CPF do cliente;
2. O funcionário entra com o nome ou CPF do cliente para fazer a pesquisa do receituário e
clica em pesquisar;
3. Sistema carrega os dados do receituário do cliente e exibe para o funcionário;
4. O funcionário seleciona opção de excluir cadastro do receituário;
5. O sistema emite mensagem de confirmação de exclusão;
6. O funcionário confirma a exclusão;
7. O sistema é carregado;
8. O sistema exclui o cadastro do cliente.
9. Sistema exibe mensagem de exclusão realizado com sucesso.
IM
Fluxo Alternativo [ 3 ]: Desistência de exclusão
a. Caso o funcionário veja que o receituário exibido após a pesquisa não é o que ele deseja
excluir, o sistema fornece opção de voltar para fazer uma nova pesquisa.
Fluxo de Exceção [ 2 ]: Caso CPF ou nome inválido ou não encontrado.
UN
a. Caso funcionário entre com um CPF ou nome para pesquisar e os dados são inválidos ou
não encontrados, o sistema envia mensagem “Nenhum cliente foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 2.
Regras de Negócio Associadas
RN - 17 Deverá ser feita uma pesquisa do receituário antes de excluí-lo.
Quadro 20 - Especificação do caso de uso: excluir receituário
No quadro 21 exemplifica-se o processo para pesquisar um cliente no
sistema Satika, mostrando as etapas necessárias, bem como os dados solicitados
para a realização da pesquisa.
53
Nome
Sumário
Pesquisar Cliente
CSU18
Descreve as etapas necessárias para pesquisar cliente
Ator primário: Funcionário
Ator(es) secundário(s): Cliente
Pré-condição: Cliente já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Pesquisa do cliente concluído
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo nome do cliente ou CPF;
2. O funcionário entra com o nome ou CPF do cliente para fazer a pesquisa;
3. Sistema carrega os dados do cliente pesquisado (nome, CPF, data nascimento, e-mail,
telefone, endereço, cidade, estado, CEP)e exibe para o funcionário;
AS
Fluxo Alternativo [ ]:
Fluxo de Exceção [ 1 ]: Caso CPF ou nome não encontrado
IN
a. Caso funcionário entre com o nome ou CPF do cliente para pesquisar e o cliente não é
cadastrado ou não encontrado, o sistema envia mensagem “Nenhum cliente foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 1.
IM
Regras de Negócio Associadas
UN
RN - 18 Para realizar uma pesquisa de cliente deverá ser informado nome ou CPF.
Quadro 21 - Especificação do caso de uso: pesquisar cliente
54
No quadro 22 mostra-se o processo para pesquisar um fornecedor no
sistema Satika, representando-se as etapas necessárias, bem como os dados
solicitados para a realização da pesquisa do fornecedor.
Nome
Sumário
Pesquisar Fornecedor
CSU19
Descreve as etapas necessárias para pesquisar fornecedor
Ator primário: Funcionário
Ator(es) secundário(s): Fornecedor
Pré-condição: Fornecedor já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Pesquisa do fornecedor concluído
Fluxo Principal
IM
Fluxo Alternativo [ ]:
IN
AS
1. O sistema fornece formulário de pesquisa pela Razão Social ou CNPJ do fornecedor;
2. O funcionário entra com a Razão Social ou CNPJ do fornecedor para fazer a pesquisa;
3. Sistema carrega os dados do fornecedor pesquisado (Razão Social, CNPJ, inscrição
estadual, nome representante, CPF do representante, telefone do representante, e-mail do
representante, telefone da empresa, fax, endereço, cidade, estado, CEP) e exibe para o
funcionário;
Fluxo de Exceção [ 1 ]: Caso CNPJ ou Razão Social não encontrado
UN
a. Caso funcionário entre com a Razão Social ou CNPJ do fornecedor para pesquisar e o
fornecedor não é cadastrado ou não encontrado, o sistema envia mensagem “Nenhum
fornecedor foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 1.
Regras de Negócio Associadas
RN - 19 Para realizar uma pesquisa de fornecedor deverá ser informado Razão Social e CNPJ.
Quadro 22 - Especificação do caso de uso: pesquisar fornecedor
55
No quadro 23 é mostrado o processo para pesquisar um funcionário no
sistema Satika, descrevendo-se as etapas necessárias, bem como os dados
solicitados para a realização da pesquisa.
Nome
Sumário
Pesquisar Funcionário
CSU20
Descreve as etapas necessárias para pesquisar funcionário
Ator primário: Funcionário
Ator(es) secundário(s): Funcionário
Pré-condição: Funcionário já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Pesquisa do funcionário concluído
Fluxo Principal
Fluxo Alternativo [ ]:
IN
AS
1. O sistema fornece formulário de pesquisa pelo nome do cliente ou CPF;
2. O funcionário entra com o nome ou CPF do funcionário para fazer a pesquisa;
3. Sistema carrega os dados do funcionário pesquisado (Nome, CPF, Carteira de trabalho, data
de nascimento, telefone, endereço, cidade, estado, CEP) e exibe para o funcionário;
IM
Fluxo de Exceção [ 1 ]: Caso CPF ou nome não encontrado
UN
a. Caso funcionário entre com o nome ou CPF do funcionário para pesquisar e o funcionário
não é cadastrado ou não encontrado, o sistema envia mensagem “Nenhum funcionário foi
encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 1.
Regras de Negócio Associadas
RN 20 - Para realizar uma pesquisa de funcionário deverá ser informado nome ou CPF.
Quadro 23 - Especificação do caso de uso: pesquisar funcionário
56
No quadro 24 exemplifica-se o processo para pesquisar um médico no
sistema Satika, mostrando-se as etapas necessárias, bem como os dados
solicitados para a realização da pesquisa.
Nome
Sumário
Pesquisar Médico
CSU21
Descreve as etapas necessárias para pesquisar médico
Ator primário: Funcionário
Ator(es) secundário(s): Médico
Pré-condição: Médico já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Pesquisa do médico concluído
Fluxo Principal
Fluxo Alternativo [ ]:
IN
AS
1. O sistema fornece formulário de pesquisa pelo nome do médico ou CPF;
2. O funcionário entra com o nome ou CPF do médico para fazer a pesquisa;
3. Sistema carrega os dados do médico pesquisado (Nome, CRM, CPF, clínica, data
nascimento, e-mail, telefone, endereço, cidade, estado, CEP) e exibe para o funcionário;
IM
Fluxo de Exceção [ 1 ]: Caso CPF ou nome não encontrado.
UN
a. Caso funcionário entre com o nome ou CPF do médico para pesquisar e o médico não é
cadastrado ou não encontrado, o sistema envia mensagem “Nenhum médico foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 1.
Regras de Negócio Associadas
RN - 21 Para realizar uma pesquisa de médico deverá ser informado nome ou CPF.
Quadro 24 - Especificação do caso de uso: pesquisar médico
57
No quadro 25 demonstra-se o processo para pesquisar um produto no
sistema Satika, mostrando-se as etapas necessárias, bem como os dados
solicitados para a realização da pesquisa.
Nome
Sumário
Pesquisar Produto
CSU22
Descreve as etapas necessárias para pesquisar produto
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Produto já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Pesquisa do produto concluído
Fluxo Principal
Fluxo Alternativo [ ]:
IN
AS
1. O sistema fornece formulário de pesquisa pelo tipo do produto nacional ou de grife;
2. O funcionário seleciona opção do produto para pesquisa;
3. Sistema carrega os dados do produto pesquisado (Descrição, tipo, grife, cor e preço) e exibe
para o funcionário;
IM
Fluxo de Exceção [ 1 ]: Caso tipo do produto não encontrado.
UN
a. Caso funcionário entre com o tipo do produto (nacional ou grife) para pesquisar e o produto
não é cadastrado ou não encontrado, o sistema envia mensagem “Nenhum produto foi
encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 1.
Regras de Negócio Associadas
RN - 22 Para realizar uma pesquisa de produto deverá ser informado o tipo ou a grife.
Quadro 25 - Especificação do caso de uso: pesquisar produto
58
No quadro 26 é mostrado o processo para pesquisar uma venda no
sistema Satika, descrevendo-se as etapas necessárias, bem como os dados
solicitados para a realização da pesquisa do registro de venda.
Nome
Sumário
Pesquisar Registro de Venda
CSU23
Descreve as etapas necessárias para pesquisar venda realizada
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Venda já realizada, e que o usuário esteja logado no sistema.
Pós-condição: Pesquisa da venda concluída.
Fluxo Principal
Fluxo Alternativo [ ]:
IN
AS
1. O sistema fornece formulário de pesquisa pela data da venda;
2. O funcionário entra com a data da venda para fazer a pesquisa;
3. Sistema carrega os dados da venda realizada (Cliente, forma de pagamento, quantidade de
parcelas, observações, produto vendido, e a data da venda) e exibe para o funcionário;
IM
Fluxo de Exceção [ 1 ]: Caso data da venda não encontrada.
UN
a. Caso funcionário entre com data da venda para pesquisar e a data não é válida ou não
encontrada, o sistema envia mensagem “Nenhuma venda foi encontrada”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 1.
Regras de Negócio Associadas
RN - 23 Para realizar uma pesquisa da venda deverá ser informada a data da venda.
Quadro 26 - Especificação do caso de uso: pesquisar registro de venda
59
No quadro 27 exemplifica-se o processo para pesquisar uma compra
no sistema Satika, mostrando-se as etapas necessárias, bem como os dados
solicitados para a realização da pesquisa do registro de compra.
Nome
Sumário
Pesquisar Registro de Compra
CSU24
Descreve as etapas necessárias para pesquisar compra realizada
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Compra já realizada, e que o usuário esteja logado no sistema.
Pós-condição: Pesquisa da compra concluída.
Fluxo Principal
Fluxo Alternativo [ ]:
IN
AS
1. O sistema fornece formulário de pesquisa pela data da compra;
2. O funcionário entra com a data da compra para fazer a pesquisa;
3. Sistema carrega os dados da compra realizada (Fornecedor, forma de pagamento,
quantidade de parcelas, observações, produto e data da venda) e exibe para o funcionário;
IM
Fluxo de Exceção [ 1 ]: Caso data da compra não encontrada.
UN
a. Caso funcionário entre com data da compra para pesquisar e a data não é válida ou não
encontrada, o sistema envia mensagem “Nenhuma compra foi encontrada”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 1.
Regras de Negócio Associadas
RN - 24 Para realizar uma pesquisa da compra deverá ser informada a data da compra.
Quadro 27 - Especificação do caso de uso: pesquisar registro de compra
60
No quadro 28 é mostrado o processo para pesquisar um receituário do
cliente no sistema Satika, descrevendo-se as etapas necessárias, bem como os
dados solicitados para a realização da pesquisa do receituário.
Nome
Sumário
Pesquisar Receituário
CSU25
Descreve as etapas necessárias para pesquisar receituário
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Venda já realizada, e que o usuário esteja logado no sistema.
Pós-condição: Pesquisa da venda concluída.
Fluxo Principal
IN
Fluxo Alternativo [ ]:
AS
1. O sistema fornece formulário de pesquisa pelo nome ou CPF do cliente;
2. O funcionário entra com o nome ou CPF do cliente para fazer a pesquisa do receituário;
3. Sistema carrega os dados do receituário do cliente e exibe para o funcionário;
IM
Fluxo de Exceção [ 1 ]: Caso CPF ou nome inválido ou não encontrado
a. Caso funcionário entre com um CPF ou nome para pesquisar e os dados são inválidos ou
não encontrados, o sistema envia mensagem “Nenhum cliente foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 1.
Regras de Negócio Associadas
UN
RN - 25 Para realizar uma pesquisa do receituário deverá ser informado nome ou CPF do
cliente.
Quadro 28 - Especificação do caso de uso: pesquisar receituário
61
No quadro 29 é mostrado o processo para alterar dados de um cliente
no sistema Satika, descrevendo-se as etapas necessárias, bem como os dados
solicitados para realizar a alteração. O ator só poderá alterar um cliente após a
pesquisa do mesmo e confirmar a alteração.
Nome
Alterar Dados Clientes
CSU26
IM
IN
AS
Sumário
Descreve as etapas necessárias para alterar dados de um cliente
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Cliente já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Alteração do cliente concluído
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo nome do cliente ou CPF;
2. O funcionário entra com o nome ou CPF do cliente para fazer a pesquisa e clica em
pesquisar;
3. Sistema carrega os dados do cliente (Nome, CPF, CRM, clínica, data de nascimento, e-mail,
telefone, endereço, cidade, estado, CEP) pesquisado e exibe para o funcionário.
5. O funcionário escolhe o dado que deseja fazer a alteração;
6. O sistema emite mensagem de confirmação de alteração;
7. O funcionário confirma alteração;
8. O sistema é carregado;
9. O sistema completa a alteração do dado.
10. O sistema exibe mensagem de alteração concluída com sucesso.
Fluxo Alternativo [ ]: Desistência de alteração
a. Caso o funcionário veja que o cliente exibido após a pesquisa não é o que ele deseja alterar,
o sistema fornece opção de voltar para fazer uma nova pesquisa.
UN
Fluxo de Exceção [ 2, 6 ]: Caso CPF e nome inválido ou CPF e nome não encontrado, ou a
alteração seja feita com dados incorretos
a. Caso funcionário entre com o nome ou CPF do cliente para pesquisar e o cliente não é
cadastrado ou não encontrado, o sistema envia mensagem “Nenhum cliente foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 2.
d. Caso o funcionário digite algum dado incorreto para fazer a alteração, o sistema envia uma
mensagem de erro, “Dado digitado incorretamente”.
e. O caso de uso retorna ao passo 3.
Regras de Negócio Associadas
RN - 26 Para alterar dados do cliente deverá ser feito antes uma pesquisa do mesmo.
Quadro 29 - Especificação do caso de uso: alterar dados cliente
62
No quadro 30 exemplifica-se o processo para alterar dados de um
fornecedor no sistema Satika, mostrando-se as etapas necessárias para a
realização, bem como os dados solicitados para realizar a alteração. O ator só
poderá alterar um fornecedor após a pesquisa do mesmo e confirmar a alteração.
Nome
Alterar Dados Fornecedor
CSU27
IM
IN
AS
Sumário
Descreve as etapas necessárias para alterar dados do fornecedor
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Fornecedor já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Alteração do fornecedor concluído
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo Razão Social do fornecedor ou CNPJ;
2. O funcionário entra com a Razão Social ou CNPJ do cliente para fazer a pesquisa e clica em
pesquisar;
3. Sistema carrega os dados do fornecedor (Razão Social, Inscrição Estadual, CNPJ, telefone,
fax, endereço, cidade, CEP, contato da empresa, e-mail) pesquisado e exibe para o
funcionário.
5. O funcionário escolhe o dado que deseja fazer a alteração;
6. O sistema emite mensagem de confirmação de alteração;
7. O funcionário confirma alteração;
8. O sistema é carregado;
9. O sistema completa a alteração do dado.
10. O sistema exibe mensagem de alteração concluída com sucesso.
Fluxo Alternativo [ ]: Desistência de alteração
a. Caso o funcionário veja que o fornecedor exibido após a pesquisa não é o que ele deseja
alterar, o sistema fornece opção de voltar para fazer uma nova pesquisa.
Fluxo de Exceção [ 2, 6 ]: Caso CPF e nome inválido ou CPF e nome não encontrado, ou a
alteração seja feita com dados incorretos
UN
a. Caso funcionário entre com a Razão Social ou CNPJ do fornecedor para pesquisar e o
fornecedor não é cadastrado ou não encontrado, o sistema envia mensagem “Nenhum
fornecedor foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 2.
d. Caso o funcionário digite algum dado incorreto para fazer a alteração, o sistema envia uma
mensagem de erro, “Dado digitado incorretamente”.
e. O caso de uso retorna ao passo 3.
Regras de Negócio Associadas
RN - 27 Para alterar dados do fornecedor deverá ser feito antes uma pesquisa do mesmo.
Quadro 30 - Especificação do caso de uso: alterar dados fornecedor
No quadro 31 é mostrado o processo para alterar dados de um
funcionário no sistema Satika, descrevendo-se as etapas necessárias, bem como os
63
dados solicitados para realizar a alteração. O ator só poderá alterar um funcionário
após a pesquisa do mesmo e confirmar a alteração.
Nome
Alterar Dados Funcionário
CSU28
IN
AS
Sumário
Descreve as etapas necessárias para alterar dados do funcionário
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Funcionário já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Alteração do funcionário concluído
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo nome do funcionário ou CPF;
2. O funcionário entra com o nome ou CPF do funcionário para fazer a pesquisa e clica em
pesquisar;
3. Sistema carrega os dados do funcionário (Nome, CPF, Carteira de trabalho, data de
nascimento, telefone, endereço, cidade, estado, CEP, usuário e senha) pesquisado e exibe
para o funcionário.
5. O funcionário escolhe o dado que deseja fazer a alteração;
6. O sistema emite mensagem de confirmação de alteração;
7. O funcionário confirma alteração;
8. O sistema é carregado;
9. O sistema completa a alteração do dado.
10. O sistema exibe mensagem de alteração concluída com sucesso.
IM
Fluxo Alternativo [ ]: Desistência da alteração
a. Caso o funcionário veja que o funcionário exibido após a pesquisa não é o que ele deseja
alterar, o sistema fornece opção de voltar para fazer uma nova pesquisa.
Fluxo de Exceção [ 2, 6 ]: Caso CPF e nome inválido ou CPF e nome não encontrado, ou a
alteração seja feita com dados incorretos
UN
a. Caso funcionário entre com o nome ou CPF do funcionário para pesquisar e o funcionário
não é cadastrado ou não encontrado, o sistema envia mensagem “Nenhum funcionário foi
encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 2.
d. Caso o funcionário digite algum dado incorreto para fazer a alteração, o sistema envia uma
mensagem de erro, “Dado digitado incorretamente”.
e. O caso de uso retorna ao passo 3.
Regras de Negócio Associadas
RN - 28 Para alterar dados do funcionário deverá ser feito antes uma pesquisa do mesmo.
Quadro 31 - Especificação do caso de uso: alterar dados funcionário
64
No quadro 32 demonstra-se o processo para alterar dados de um
médico no sistema Satika, descrevendo-se as etapas necessárias, bem como os
dados solicitados para realizar a alteração. O ator só poderá alterar um médico após
a pesquisa do mesmo e confirmar a alteração.
Nome
Sumário
Alterar Dados Médico
CSU29
Descreve as etapas necessárias para alterar dados do médico
IM
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Médico já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Alteração do médico concluído
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo nome do médico ou CPF;
2. O funcionário entra com o nome ou CPF do médico para fazer a pesquisa e clica em
pesquisar;
3. Sistema carrega os dados do médico (Nome, CPF, CRM, clínica, data de nascimento, e-mail,
telefone, endereço, cidade, estado, CEP) pesquisado e exibe para o funcionário.
5. O funcionário escolhe o dado que deseja fazer a alteração;
6. O sistema emite mensagem de confirmação de alteração;
7. O funcionário confirma alteração;
8. O sistema é carregado;
9. O sistema completa a alteração do dado.
10. O sistema exibe mensagem de alteração concluída com sucesso.
Fluxo Alternativo [ ]: Desistência da alteração
a. Caso o funcionário veja que o médico exibido após a pesquisa não é o que ele deseja
alterar, o sistema fornece opção de voltar para fazer uma nova pesquisa.
UN
Fluxo de Exceção [ 2, 6 ]: Caso CPF e nome inválido ou CPF e nome não encontrado, ou a
alteração seja feita com dados incorretos
a. Caso funcionário entre com o nome ou CPF do médico para pesquisar e o médico não é
cadastrado ou não encontrado, o sistema envia mensagem “Nenhum médico foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 2.
d. Caso o funcionário digite algum dado incorreto para fazer a alteração, o sistema envia uma
mensagem de erro, “Dado digitado incorretamente”.
e. O caso de uso retorna ao passo 3.
Regras de Negócio Associadas
RN - 29 Para alterar dados do médico deverá ser feito antes uma pesquisa do mesmo.
Quadro 32 - Especificação do caso de uso: alterar dados médico
65
No quadro 33 é mostrado o processo para alterar dados de um produto
no sistema Satika, descrevendo-se as etapas necessárias, bem como os dados
solicitados para realizar a alteração. O ator só poderá alterar um produto após a
pesquisa do mesmo e confirmar a alteração.
Nome
Sumário
Alterar Dados Produto
CSU30
Descreve as etapas necessárias para alterar dados do produto
IM
IN
AS
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Produto já cadastrado, e que o usuário esteja logado no sistema.
Pós-condição: Alteração do produto concluído.
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo tipo (nacional ou grife) do produto;
2. O funcionário entra com o tipo do produto para fazer a pesquisa e clica em pesquisar;
3. Sistema carrega os dados do produto (Descrição, tipo, grife, cor, preço) pesquisado e exibe
para o funcionário.
5. O funcionário escolhe o dado que deseja fazer a alteração;
6. O sistema emite mensagem de confirmação de alteração;
7. O funcionário confirma alteração;
8. O sistema é carregado;
9. O sistema completa a alteração do dado.
10. O sistema exibe mensagem de alteração concluída com sucesso.
Fluxo Alternativo [ ]: Desistência da alteração
a. Caso o funcionário veja que o produto exibido após a pesquisa não é o que ele deseja
alterar, o sistema fornece opção de voltar para fazer uma nova pesquisa.
UN
Fluxo de Exceção [ 1, 6 ]: Caso tipo do produto inválido ou não encontrado, ou a alteração
seja feita com dados incorretos
a. Caso funcionário entre com o tipo do produto para pesquisar e o produto não é cadastrado
ou não encontrado, o sistema envia mensagem “Nenhum produto foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 1.
d. Caso o funcionário digite algum dado incorreto para fazer a alteração, o sistema envia uma
mensagem de erro, “Dado digitado incorretamente”.
e. O caso de uso retorna ao passo 4.
Regras de Negócio Associadas
RN - 30 Para alterar dados do produto deverá ser feito antes uma pesquisa do mesmo.
Quadro 33 - Especificação do caso de uso: alterar dados produto
No quadro 34 exemplifica-se o processo para alterar dados de uma
venda no sistema Satika, descrevendo-se as etapas necessárias, bem como os
66
dados solicitados para realizar a alteração. O ator só poderá alterar uma venda após
a pesquisa através do cliente e confirmar a alteração.
Nome
Alterar Venda
CSU31
IN
AS
Sumário
Descreve as etapas necessárias para alterar dados da venda
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Venda já cadastrada, e que o usuário esteja logado no sistema.
Pós-condição: Alteração da venda concluído.
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo nome do cliente ou CPF;
2. O funcionário entra com o nome ou CPF do cliente para fazer a pesquisa e clica em
pesquisar;
3. Sistema carrega os dados da venda (Cliente, forma de pagamento, quantidade de parcelas,
observações, produto vendido, e a data da venda) pesquisados e exibe para o funcionário.
5. O funcionário escolhe o dado que deseja fazer a alteração;
6. O sistema emite mensagem de confirmação de alteração;
7. O funcionário confirma alteração;
8. O sistema é carregado;
9. O sistema completa a alteração do dado.
10. O sistema exibe mensagem de alteração concluída com sucesso.
IM
Fluxo Alternativo [ ]: Desistência da alteração
a. Caso o funcionário veja que a venda exibida após a pesquisa não é o que ele deseja alterar,
o sistema fornece opção de voltar para fazer uma nova pesquisa.
Fluxo de Exceção [ 1, 6 ]: Caso CPF ou nome inválidos, ou a alteração seja feita com dados
incorretos
UN
a. Caso funcionário entre com o nome ou CPF do cliente para pesquisar a venda não é
cadastrado ou não encontrado, o sistema envia mensagem “Nenhum produto foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 1.
d. Caso o funcionário digite algum dado incorreto para fazer a alteração, o sistema envia uma
mensagem de erro, “Dado digitado incorretamente”.
e. O caso de uso retorna ao passo 4.
Regras de Negócio Associadas
RN - 31 Para alterar dados da venda deverá ser feito antes uma pesquisa do mesmo.
Quadro 34 - Especificação do caso de uso: alterar venda
No quadro 35 é mostrado o processo para alterar dados de uma
compra no sistema Satika, descrevendo-se as etapas necessárias, bem como os
dados solicitados para realizar a alteração. O ator só poderá alterar uma compra
após a pesquisa através do fornecedor e confirmar a alteração.
67
Nome
Alterar Compra
CSU32
IN
AS
Sumário
Descreve as etapas necessárias para alterar dados da compra
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Compra já cadastrada, e que o usuário esteja logado no sistema.
Pós-condição: Alteração da compra concluída.
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo CNPJ ou razão social do fornecedor;
2. O funcionário entra com o CNPJ ou razão social do fornecedor para fazer a pesquisa e clica
em pesquisar;
3. Sistema carrega os dados da venda (Fornecedor, forma de pagamento, quantidade de
parcelas, observações, produto e data da venda) pesquisados e exibe para o funcionário.
5. O funcionário escolhe o dado que deseja fazer a alteração;
6. O sistema emite mensagem de confirmação de alteração;
7. O funcionário confirma alteração;
8. O sistema é carregado;
9. O sistema completa a alteração do dado.
10. O sistema exibe mensagem de alteração concluída com sucesso.
Fluxo Alternativo [ ]: Desistência da alteração
a. Caso o funcionário veja que a venda exibida após a pesquisa não é o que ele deseja alterar,
o sistema fornece opção de voltar para fazer uma nova pesquisa.
IM
Fluxo de Exceção [ 1, 6 ]: Caso CNPJ ou razão social, ou a alteração seja feita com dados
incorretos
UN
a. Caso funcionário entre com o CNPJ ou razão social do fornecedor para pesquisar a compra
não é cadastrado ou não encontrado, o sistema envia mensagem “Nenhum produto foi
encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 1.
d. Caso o funcionário digite algum dado incorreto para fazer a alteração, o sistema envia uma
mensagem de erro, “Dado digitado incorretamente”.
e. O caso de uso retorna ao passo 4.
Regras de Negócio Associadas
RN - 32 Para alterar dados da compra deverá ser feito antes uma pesquisa do mesmo.
Quadro 35 - Especificação do caso de uso: alterar compra
No quadro 36 é demonstrado o processo para alterar dados de um
receituário no sistema Satika, descrevendo-se as etapas necessárias, bem como os
dados solicitados para realizar a alteração. O ator só poderá alterar um receituário
após a pesquisa através do cliente e confirmar a alteração.
68
Nome
Alterar Receituário
CSU33
AS
Sumário
Descreve as etapas necessárias para alterar receituário
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Compra já cadastrada, e que o usuário esteja logado no sistema.
Pós-condição: Alteração da compra concluída.
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo nome ou CPF do cliente;
2. O funcionário entra com o nome ou CPF do cliente para fazer a pesquisa do receituário e
clica em pesquisar;
3. Sistema carrega os dados do receituário (cliente, médico, data da consulta, grau esquerdo,
grau direito, eixo, prisma, estrios, cilíndrica, naso pupilar e lente) pesquisados e exibe para o
funcionário.
5. O funcionário escolhe o dado que deseja fazer a alteração;
6. O sistema emite mensagem de confirmação de alteração;
7. O funcionário confirma alteração;
8. O sistema é carregado;
9. O sistema completa a alteração do dado.
10. O sistema exibe mensagem de alteração concluída com sucesso.
IN
Fluxo Alternativo [ ]: Desistência da alteração
a. Caso o funcionário veja que o receituário exibida após a pesquisa não é o que ele deseja
alterar, o sistema fornece opção de voltar para fazer uma nova pesquisa.
Fluxo de Exceção [ 1, 6 ]: Caso CPF ou nome do cliente inválidos, ou a alteração seja feita
com dados incorretos
UN
IM
a. Caso funcionário entre com o CPF ou nome do cliente para pesquisar o receituário, não é
cadastrado ou não encontrado, o sistema envia mensagem “Nenhum cliente foi encontrado”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 1.
d. Caso o funcionário digite algum dado incorreto para fazer a alteração, o sistema envia uma
mensagem de erro, “Dado digitado incorretamente”.
e. O caso de uso retorna ao passo 4.
Regras de Negócio Associadas
RN - 33 Para alterar dados do receituário deverá ser feito antes uma pesquisa do mesmo.
Quadro 36 - Detalhe do caso de uso alterar receituário
No quadro 37 é demonstrado o processo para gerar o relatório
melhores clientes no sistema Satika, isto é, clientes que efetuaram as maiores
compras na empresa. O quadro exemplifica as etapas necessárias, bem como os
dados solicitados para sua realização. O ator só poderá gerar um relatório após
informar o período desejado para consulta. O sistema fornece os dados dos clientes
69
que mais consumiram na empresa. O funcionário pode imprimir o relatório ou
apenas visualizar.
Nome
Sumário
Relatório Melhores Clientes
CSU34
Descreve as etapas necessárias para gerar relatório de clientes que mais
efetuaram compras na empresa.
AS
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Venda já cadastrada, e que o usuário esteja logado no sistema.
Pós-condição: Relatório melhores clientes exibido.
Fluxo Principal
1. O sistema fornece formulário de pesquisa pelo período de venda para consulta;
2. O funcionário entra com o período de venda para fazer a pesquisa;
3. Sistema carrega os dados das vendas com os clientes que mais efetuaram compras, em
ordem crescente e exibe para o funcionário.
4. O funcionário imprimi relatório.
5. O sistema exibe mensagem de impressão concluída com sucesso.
IN
Fluxo Alternativo [ ]: Desistência na geração do relatório
a. Caso o funcionário veja que o período exibido após a pesquisa não é o que ele deseja
visualizar, o sistema fornece opção de voltar para fazer uma nova pesquisa.
Fluxo de Exceção [ 1, 6 ]: Caso data do período inválidos.
IM
a. Caso funcionário entre com a data do período para pesquisar as vendas, não é válido ou não
encontrado, o sistema envia mensagem “Nenhuma venda foi encontrada”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 1.
Regras de Negócio Associadas
UN
RN - 34 Para gerar relatório Melhores Clientes é necessário informar o período de venda a ser
pesquisado.
Quadro 37 - Detalhe do caso de uso relatório melhores clientes
No quadro 38 é exemplificado o processo para gerar o relatório de
produtos mais vendidos no sistema Satika, mostrando as etapas necessárias, bem
como os dados solicitados para sua realização. O ator só poderá gerar um relatório
após informar o período de venda desejado para consulta. O sistema fornece os
dados dos produtos que mais foram vendidos na empresa. O funcionário pode
imprimir relatório ou apenas visualizar.
70
Nome
Sumário
Relatório Produtos Mais Vendidos
CSU35
Descreve as etapas necessárias para gerar relatório de produtos mais vendidos
na empresa
Ator primário: Funcionário
Ator(es) secundário(s): -Pré-condição: Venda já cadastrada, e que o usuário esteja logado no sistema.
Pós-condição: Relatório de produtos mais vendidos.
Fluxo Principal
AS
1. O sistema fornece formulário de pesquisa pelo período de venda para consulta;
2. O funcionário entra com o período de venda para fazer a pesquisa;
3. Sistema carrega os dados das vendas com os produtos mais vendidos de forma crescente e
exibe para o funcionário.
4. O funcionário imprimi relatório.
10. O sistema exibe mensagem de impressão concluída com sucesso.
IN
Fluxo Alternativo [ ]: Desistência na geração do relatório.
a. Caso o funcionário veja que o período exibido após a pesquisa não é o que ele deseja
visualizar, o sistema fornece opção de voltar para fazer uma nova pesquisa.
Fluxo de Exceção [ 1, 6 ]: Caso data do período inválidos.
IM
a. Caso funcionário entre com a data do período para pesquisar as vendas, não é válido ou não
encontrado, o sistema envia mensagem “Nenhuma venda foi encontrada”;
b. Funcionário deverá fazer uma nova pesquisa.
c. O caso de uso retorna ao passo 1.
Regras de Negócio Associadas
RN - 35 Para gerar relatório Produtos mais Vendidos é necessário informar o período de venda
a ser pesquisado.
UN
Quadro 38 - Detalhe do caso de uso relatórios produtos mais vendidos
3.3
Diagramas de Seqüência
O diagrama de seqüência é uma das ferramentas da UML usadas para
representar de forma visual interações entre objetos de um cenário, realizadas
através de operações e métodos. Mostra a seqüência explícita de mensagens para
ilustrar as realizações de casos de uso, isto é, mostra como os objetos interagem
para executar o comportamento total ou parcial de um caso de uso. Possui um
conjunto de elementos gráficos que descrevem o comportamento de um ponto de
71
vista interno do sistema. Os diagramas de seqüência ajudam a documentar e a
entender os aspectos dinâmicos do sistema de software. Eles descrevem a
seqüência de mensagens enviadas e recebidas pelos objetos que participam em um
caso de uso.
É utilizado para modelar o cenário de um caso de uso, modelando a
troca de mensagens entre os objetos. No sistema Satika, foram desenvolvidos vários
diagramas de seqüência para exibir de forma cronológica, o que o sistema
internamente deverá realizar de acordo com o diagrama de caso de uso já realizado.
AS
O diagrama de seqüência pode ser construído para o fluxo principal do
caso de uso e eventualmente também para alguns cenários com fluxos
alternativos. O importante nessa fase não é ter o diagrama em si, mas
identificar corretamente que operações e consultas de sistema são
necessárias. A existência dos diagramas completos com o fluxo de
informações entre os atores e do sistema para os atores será interessante
na fase do projeto da interface, mas, por enquanto, na análise, é suficiente
saber quais são as informações repassadas dos atores para o sistema e
vice-versa (WAZLAWICK, 2004, v. 4, p. 95).
IN
O diagrama de seqüência é uma ferramenta importante no projeto de
sistemas. Embora a elaboração dos diagramas possa consumir muito tempo, eles
oferecem as bases para a definição de uma boa parte do projeto como: os
relacionamentos necessários entre as classes, métodos e atributos das classes e
IM
comportamento dinâmico dos objetos.
A seguir serão mostrados os diagramas de seqüência, para
exemplificar os processos internos do sistema através dos casos de uso do sistema
Satika.
UN
A figura 6 mostra o procedimento interno para efetuar o login no
sistema Satika. O sistema valida o usuário e a senha do usuário.
72
AS
Figura 6 - Diagrama de seqüência efetuar login
A figura 7 mostra o procedimento interno para realizar o cadastro de
um cliente no sistema Satika, descrevendo atores, telas, classes, objetos e a troca
UN
IM
IN
de mensagens entre eles.
Figura 7 - Diagrama de seqüência cadastrar cliente
73
O cadastro de um funcionário deverá ser realizado por outro
funcionário que já seja cadastrado no sistema Satika. Além da entrada de dados
como nome, CPF, número da carteira de trabalho, endereço, telefone, deverá
também ser cadastrado o usuário e a senha deste novo funcionário, para que tenha
acesso ao sistema. O sistema valida além do código do cliente, o CPF do
funcionário, bem como as informações, se estão todas preenchidas corretamente ou
se está faltando algum dado. A figura 8, detalha o processo de cadastro do
UN
IM
IN
AS
funcionário.
Figura 8 - Diagrama de seqüência cadastrar funcionário
74
Para realizar o cadastro de um fornecedor de produtos para a empresa
é necessário que sejam preenchidos os dados do mesmo. O cadastro é realizado
pelo funcionário. O sistema valida o código do fornecedor e também o número do
CNPJ. A figura 9 demonstra o processo para a realização do cadastro do fornecedor
UN
IM
IN
AS
no sistema Satika.
Figura 9 - Diagrama de seqüência cadastrar fornecedor
75
A figura 10 exemplifica os processos que o sistema realiza para
cadastrar um médico. O sistema Satika primeiramente valida o código do médico
passado pelo funcionário e só então solicita que os outros dados do médico sejam
UN
IM
IN
AS
preenchidos.
Figura 10 - Diagrama de seqüência cadastrar médico
76
A figura 11 abaixo descreve o processo para cadastrar um produto. O
sistema valida o código do produto e solicita o preenchimento dos dados do produto
UN
IM
IN
AS
para a realização do cadastro.
Figura 11 - Diagrama de seqüência cadastrar produto
77
Abaixo, pode-se ver na figura 12, o processo para o cadastro de um
receituário. Para isso é necessário que o usuário do sistema faça primeiramente
uma busca no registro pelo nome ou CPF do cliente para a verificação do cadastro.
Assim o sistema carregará os dados do cliente. Posteriormente, é realizada a
consulta do médico no registro para a verificação do cadastro, e assim o sistema
carrega os dados do médico para o cadastro do receituário. Caso o cliente ou o
médico ainda não estejam cadastrados, o sistema emite uma mensagem informando
UN
IM
IN
AS
que não consta nenhum registro com os parâmetros informados.
Figura 12 - Diagrama de seqüência cadastrar receituário
78
A figura 13 abaixo exemplifica o processo de registrar no sistema uma
venda que a empresa realizou. Para isso, é necessário que o usuário realize uma
busca com o nome ou CPF do cliente que está adquirindo um produto, para verificar
se o cliente já está cadastrado no sistema. O segundo passo é preencher os dados
UN
IM
IN
AS
solicitados para a conclusão do registro da venda.
Figura 13 - Diagrama de seqüência registrar venda
79
Para registrar uma compra de produtos junto ao fornecedor, é
necessário que o usuário realize primeiramente uma busca para verificar se o
fornecedor já é cadastrado no sistema. Após a busca, o usuário poderá concluir o
UN
IM
IN
AS
registro informando os dados solicitados, conforme a figura 14 abaixo.
Figura 14 - Diagrama de seqüência registrar compra
80
Para efetuar alguma alteração nos dados do cliente, o usuário deverá
realizar a busca deste cliente no sistema. Se o cliente for encontrado, o sistema
carrega os dados do cliente, e assim poderá ser feita a alteração do dado pelo
usuário. A figura 15 exemplifica o processo para fazer uma alteração em algum dado
UN
IM
IN
AS
do cliente.
Figura 15 - Diagrama de seqüência alterar cliente
81
A figura 16 abaixo demonstra o processo para alterar dados de um
funcionário. Para que isso seja feito, o funcionário deverá fazer uma busca para ver
se o funcionário já é cadastrado no sistema. Se for, o sistema carrega os dados do
UN
IM
IN
AS
funcionário, e assim poderá ser feita pelo usuário a alteração do dado que desejar.
Figura 16 - Diagrama de seqüência alterar funcionário
82
UN
IM
IN
AS
A figura 17 abaixo demonstra o processo para alterar dados de um
fornecedor. Para que isso seja feito, o fornecedor deverá fazer uma busca para
verificar se o fornecedor já é cadastrado no sistema. Caso seja, o sistema carrega
os dados, e assim poderá ser feita pelo usuário a alteração do dado que desejar.
Figura 17 - Diagrama de seqüência alterar fornecedor
83
Para realizar alteração de dados no cadastro de um médico,
primeiramente o usuário deverá realizar uma busca pelo nome ou CPF do médico
para verificar se o mesmo se encontra cadastrado no sistema. O sistema carrega os
dados do médico e assim o usuário poderá fazer alguma alteração no cadastro. A
UN
IM
IN
AS
figura 18 mostra o processo de alteração de dados no cadastro do médico.
Figura 18 - Diagrama de seqüência alterar médico
84
Para realizar o processo de alteração de algum produto, o funcionário
deverá fazer uma busca pelo produto que deseja alterar. Para isso é necessário que
o mesmo informe o tipo de produto a ser buscado. Se houver esse produto
cadastrado, o sistema carrega os dados e assim fornece a opção de alterar o dado
que o funcionário desejar. A figura 19 abaixo demonstra os passos internos do
UN
IM
IN
AS
sistema para realizar a alteração do produto.
Figura 19 - Diagrama de seqüência alterar produto
85
Para realizar o processo de alteração de uma venda, o funcionário
deverá fazer uma busca pelo nome ou CPF do cliente que foi feita a venda. Se a
venda já estiver registrada, o sistema carrega os dados da venda e assim fornece a
opção de alterar o dado que o funcionário desejar. A figura 20 abaixo demonstra os
UN
IM
IN
AS
passos internos do sistema para realizar a alteração de uma venda já realizada.
Figura 20 - Diagrama de seqüência alterar venda
86
A figura 21 abaixo demonstra os passos internos do sistema para
realizar a alteração de uma compra já realizada. Para realizar o processo de
alteração de uma compra, o funcionário deverá fazer uma busca pelo CNPJ ou
razão social do fornecedor que foi feita a compra. Se a compra já estiver registrada,
o sistema carrega os dados da compra e assim fornece a opção de alterar o dado
UN
IM
IN
AS
que o funcionário desejar.
Figura 21 - Diagrama de seqüência alterar compra
87
A figura 22 abaixo demonstra os passos internos do sistema para
realizar a alteração de um receituário já cadastrado. Para realizar o processo de
alteração de um receituário, o funcionário deverá fazer uma busca pelo nome ou
CPF do cliente que foi feito o cadastro. Se receituário já estiver cadastrado, o
sistema carrega os dados do receituário e assim fornece a opção de alterar o dado
UN
IM
IN
AS
que o funcionário desejar.
Figura 22 - Diagrama de seqüência alterar receituário
88
Para realizar a exclusão de um cliente no cadastro do sistema, o
funcionário deverá primeiramente informar qual cliente quer excluir fazendo uma
pesquisa, informando o nome ou CPF do cliente a ser excluído. Logo após, o
sistema carrega os dados do cliente, o funcionário seleciona e confirma a opção de
excluir cadastro do cliente. A figura 23 mostra o processo interno do sistema para
UN
IM
IN
AS
efetuar a exclusão do cadastro.
Figura 23 - Diagrama de seqüência excluir cliente
89
A figura 24 mostra o processo interno do sistema para efetuar a
exclusão do cadastro de um funcionário. Para realizar esta exclusão, o usuário
deverá primeiramente informar qual funcionário quer excluir fazendo uma pesquisa,
informando o nome ou CPF do funcionário a ser excluído. Logo após, o sistema
carrega os dados do funcionário pesquisado, o usuário seleciona e confirma a opção
UN
IM
IN
AS
de excluir cadastro.
Figura 24 - Diagrama de seqüência excluir funcionário
90
A figura 25 mostra o processo interno do sistema para efetuar a
exclusão do cadastro de um fornecedor. Para isto, o usuário deverá primeiramente
informar qual fornecedor deseja excluir fazendo uma pesquisa, informando o CNPJ
ou razão social do fornecedor a ser excluído. Logo após, o sistema carrega os dados
do fornecedor pesquisado, o usuário seleciona e confirma a opção de excluir
UN
IM
IN
AS
cadastro.
Figura 25 - Diagrama de seqüência excluir fornecedor
91
A figura 26 abaixo demonstra o processo de iteração do sistema para
realizar exclusão do cadastro do médico no sistema. Para realizar esta exclusão, o
usuário deverá primeiramente informar qual médico deseja excluir fazendo uma
pesquisa, informando o nome ou CPF do médico a ser excluído. Logo após, o
sistema carrega os dados do médico pesquisado, o usuário seleciona e confirma a
UN
IM
IN
AS
opção de excluir cadastro.
Figura 26 - Diagrama de seqüência excluir médico
92
A figura 27 abaixo demonstra o processo de iteração do sistema para
realizar exclusão do cadastro do produto no sistema. Para realizar a exclusão, o
usuário deverá primeiramente informar qual produto deseja excluir fazendo uma
pesquisa, informando o tipo do produto a ser excluído. Logo após, o sistema carrega
os dados do produto pesquisado, o usuário seleciona e confirma a opção de excluir
UN
IM
IN
AS
cadastro.
Figura 27 - Diagrama de seqüência excluir produto
93
Para excluir um registro de venda, é necessário que o usuário informe
qual venda deseje excluir, os parâmetros para fazer essa busca são o nome ou o
CPF do cliente que compraram na empresa. O sistema então carrega os dados da
venda e assim o usuário poderá excluir o cadastro. Abaixo a figura 28 mostra o
UN
IM
IN
AS
processo de exclusão de venda.
Figura 28 - Diagrama de seqüência Excluir Venda
94
Para excluir um registro de compra, é necessário que o usuário informe
qual compra deseje excluir; os parâmetros para fazer essa busca são o CNPJ ou a
razão social do fornecedor. O sistema então carrega os dados da compra e assim o
usuário poderá excluir o cadastro. Abaixo a figura 29 mostra o processo de exclusão
UN
IM
IN
AS
de compra.
Figura 29 - Diagrama de seqüência Excluir Compra
95
A figura 30 é o diagrama de seqüência que mostra a iteração do
UN
IM
IN
AS
sistema para excluir um receituário do cadastro no sistema.
Figura 30 - Diagrama de seqüência Excluir Receituário
96
A figura 31 abaixo é um diagrama de seqüência que mostra o processo
para fazer uma pesquisa de um cadastro do cliente no sistema Satika, bem como os
UN
IM
IN
AS
dados solicitados para a realização do mesmo e exibi-los na tela.
Figura 31 - Diagrama de seqüência Pesquisar Cliente
97
A figura 32 mostra o processo para realizar uma pesquisa do cadastro
do funcionário no sistema Satika, informando os parâmetros de pesquisa e exibi-lo
UN
IM
IN
AS
na tela.
Figura 32 - Diagrama de seqüência Pesquisar Funcionário
98
A figura 33 representa o diagrama de seqüência que mostra o
processo para realizar uma pesquisa do cadastro do fornecedor no sistema Satika,
UN
IM
IN
AS
bem como os dados solicitados para a realização do mesmo e exibi-lo na tela.
Figura 33 - Diagrama de seqüência Pesquisar Fornecedor
99
Segue abaixo a figura 34 que demonstra o diagrama de seqüência que
exibe passo a passo o processo para a pesquisa do cadastro de um médico no
sistema Satika, bem como os dados solicitados para a realização do mesmo e exibi-
UN
IM
IN
AS
lo na tela.
Figura 34 - Diagrama de seqüência Pesquisar Médico
100
A figura 35 exibe o diagrama de seqüência que mostra o processo
passo a passo para realizar uma pesquisa do cadastro do produto no sistema
IM
IN
AS
Satika, informando os parâmetros de pesquisa e exibi-lo na tela.
UN
Figura 35 - Diagrama de seqüência Pesquisar Produto
101
A figura 36 demonstra o diagrama de seqüência que mostra passo a
passo o processo para a pesquisa do registro de uma venda no sistema Satika, bem
IM
IN
AS
como os dados solicitados para a realização do mesmo e exibi-lo na tela.
UN
Figura 36 - Diagrama de seqüência Pesquisar Venda
102
Segue abaixo a figura 37 é o diagrama de seqüência que demonstra
passo a passo o processo para a pesquisa do registro de uma compra no sistema
IM
IN
AS
Satika, informando os parâmetros de pesquisa e exibi-lo na tela.
UN
Figura 37 - Diagrama de seqüência Pesquisar Compra
103
A figura 38 apresenta o diagrama de seqüência que mostra o processo
passo a passo para realizar uma pesquisa do cadastro do receituário no sistema
Satika, bem como os dados solicitados para a realização do mesmo e exibi-lo na
UN
IM
IN
AS
tela.
Figura 38 - Diagrama de seqüência Pesquisar Receituário
104
A figura 39 é um diagrama de seqüência que demonstra o processo
para gerar um relatório de melhores clientes. É um relatório que informa ao usuário
uma lista dos clientes que efetuaram as maiores compras na empresa, podendo
imprimir ou apenas visualizar na tela do monitor. Este relatório serve para que o
usuário possa de alguma forma, utilizar a informação para possíveis malas diretas
IM
IN
AS
ou alguns benefícios ao cliente.
UN
Figura 39 - Diagrama de seqüência Relatório Melhores Clientes
105
A figura 40 é um diagrama de seqüência que demonstra o processo
para gerar um relatório de produtos mais vendidos. É um relatório que informa ao
usuário uma lista dos produtos que mais foram vendidos na empresa, podendo
imprimir ou apenas visualizar na tela do monitor. Este relatório serve para que o
IM
IN
AS
usuário possa de alguma forma, utilizar a informação para supervisores da empresa.
UN
Figura 40 - Diagrama de seqüência Relatório Produtos Mais Vendidos
106
3.4
Classes de Análise
As classes de análise são usadas para obter as principais classes que
compõem o projeto, é onde se tem a primeira representação estática dos casos de
uso. Representam um primeiro modelo conceitual para os elementos que possuam
responsabilidades e comportamento. Quando se fala em identificação das classes
que irão pertencer a um diagrama de classes, o objetivo na verdade é identificar
quais objetos farão parte do sistema.
A identificação de classes é dividida em duas etapas. Primeiramente
AS
são identificadas as classes candidatas, são entidades que podem a vir tornarem-se
classes. A segunda etapa é a mais complicada, é realizada a identificação das
possíveis classes do sistema, o problema é eliminar desse conjunto o que não é
necessário. Na maioria dos casos, ele omite o detalhamento de um modelo de
IN
design, a fim de fornecer uma visão geral da funcionalidade do sistema. No fim, o
modelo de análise se converte no modelo de design e as classes de análise
evoluem diretamente para elementos do modelo de design.
“Uma boa modelagem de classes deve separar a informação contida no
IM
domínio de negócio (objetos de entidade), as várias maneiras de visualizar
uma informação (objetos de fronteira) e a lógica da aplicação (objeto de
controle) (BEZERRA, 2002, v.9, p. 115).
Algumas classes foram identificadas no início do projeto, a seguir será
UN
detalhada a responsabilidade de cada classe assim como seus atributos detectados.
As classes dos quais o sistema é composto foi dividido de acordo com suas
responsabilidades em: classes de entidade, classes de controle e classes de
fronteira.
3.4.1 Classe de Fronteira
A classe de fronteira é responsável por apresentar ao ator, os
resultados de uma interação dos objetos internos, em algo que possa ser entendido
107
pelo ator. As Classes de Fronteira são as classes responsáveis em fazer a interface
com o usuário, ou seja, são as classes que tem “contato” com o usuário do sistema.
As classes de fronteira têm tipicamente as seguintes responsabilidades
de fazer:
Informar aos objetos de controle os eventos gerados externamente
ao sistema;
Informar aos atores o resultado de interações entre os objetos
internos.
As classes de fronteira isolam o núcleo da aplicação do mundo
exterior, evitando que mudanças na interface com o mundo exterior afetem outras
AS
classes da aplicação. Portanto, devem ser consideradas somente como informações
externas que são recebidas pelo sistema e as informações que são enviadas para o
exterior, sendo os detalhes de interface ignorados.
No
caso
do
sistema
Satika,
as classes
de
fronteira
foram
IN
desenvolvidas utilizando a tecnologia JSP (Java Server Pages), são as responsáveis
em fazer a interação “usuário x sistema”.
IM
3.4.2 Classe de Controle
As classes de controle são responsáveis pela comunicação entre as
classes de fronteira e as classes de entidade, servem para controlar a lógica de
UN
execução correspondente ao caso de uso. Essas classes decidem o que, e quando
ocorre um evento externo relevante.
Tipicamente, uma classe de controle possui um comportamento
relacionado a transações, ou seja, um serviço que separa os objetos de entidade a
partir dos objetos de fronteira. Basicamente, uma classe de controle, é uma classe
que modela o comportamento de controle especifico para uma ou mais Casos de
Uso.
Segundo Bezerra (2002), as responsabilidades da classe de controle
são:
Fazer monitoramento, com o objetivo de responder a eventos
externos oriundos da classe de fronteira.
108
Garantir que as regras de negócios estão sendo cumpridas
corretamente.
Garantir a realização de um caso de uso através do envio de
mensagens às classes de fronteira e a classes de entidade.
3.4.3 Classe de Entidade
A classe de entidade representa os conceitos do domínio do negócio,
os conceitos principais da aplicação, e as fontes de informação que a aplicação
AS
manipula. É uma classe que modela objetos cuja informação e o comportamento
associado são, de maneira geral, persistentes, isto é, serão armazenados num
arquivo ou banco de dados. Os atores do sistema não possuem acesso direto a
classe de entidade, portanto se comunicam com o exterior por intermédio de outras
IN
classes.
Segundo Bezerra (2002), algumas responsabilidades da classe de
entidade são:
Informar os valores dos atributos a classe de entidade;
IM
Realizar funções simples, alguns métodos, com a ajuda de outras
classes de entidade associadas através de agregações;
UN
3.4.4 Classes do Projeto
Para o desenvolvimento das classes do projeto, foi necessária a
separação das mesmas em pacotes. Cada pacote contém um conjunto de outras
classes que pertencem a esse pacote. É onde se encontra as classes de fronteira,
de controle e de entidade. A figura 41 descreve os pacotes de classes pertencentes
ao system Satika.
IN
AS
109
IM
Figura 41 - Diagrama de pacotes
A figura 41 exemplifica as classes de análise que possui o pacote login
e seus relacionamentos.
A classe de fronteira neste caso é a Tela Login. Nela estão contidos os
UN
atributos e métodos necessários para realizar o login no sistema Satika. Somente
após o login é possível ter acesso ao restante do sistema.
A classe Efetuar Login é a classe de controle. Nessa classe estão
contidas as funções responsáveis por fazer a comunicação entre a classe de
fronteira e a classe de entidade, possuindo métodos específicos para tratar essa
comunicação. Na figura 42 esta descrita os métodos que compõem essas classes.
A classe de entidade esta representada pela classe Usuário, que é
responsável por armazenar as informações vindas da classe de fronteira, bem como
os métodos para realização da mesma. A classe Funcionário representada na figura
usa a classe Login, pois somente o funcionário terá acesso autorizado para usar o
sistema Satika, conforme demonstrado na figura 42.
UN
IM
IN
AS
110
Figura 42 - Classe de análise pacote login
A figura 43 mostra os atributos, os métodos e os relacionamentos entre
as classes de fronteira, de controle e entidade do pacote Cliente. As classes de
fronteira estão representadas na figura com os nomes de Tela Cliente e de Tela
Pesquisar Cliente, onde é possível visualizar o resultado da iteração do usuário e o
sistema, contém os atributos e os métodos para buscar esses atributos. As classes
de controle do sistema Satika são: Cadastrar Cliente, Alterar Cliente, Excluir Cliente
111
e Pesquisar Cliente. Essas classes são responsáveis pela comunicação entre as
classes de fronteira e a classe de entidade. Essas classes possuem métodos
específicos para tratar as requisições, conforme descrito na figura. A classe de
entidade esta representada pela Classe Cliente, onde serão registradas as
alterações realizadas pelo usuário. Fazem parte também as classes que usam esse
pacote, como a classe Receituário, classe Vendam, classe Médico, conforme
UN
IM
IN
AS
demonstrado na figura 43.
Figura 43 - Diagrama de análise cliente
112
A figura 44 exemplifica as classes de análise que possui o pacote
funcionário e seus relacionamentos.
As classes de fronteira neste caso são: Tela Funcionário e Tela
Pesquisar Funcionário. Nelas estão contidas os atributos necessários para essa
classe e seus métodos para obter os dados do funcionário. Também são
responsáveis por exibir na tela os dados do funcionário pesquisado.
As classes de controle são: Cadastrar Funcionário, Alterar Funcionário,
Excluir Funcionário e Pesquisar Funcionário. Nessas classes estão contidas as
funções responsáveis por fazer a comunicação entre a classe de fronteira e a classe
de entidade, possuindo métodos específicos para tratar essa comunicação. Na
AS
figura 44 esta descrita os métodos que compõem essas classes.
A classe de entidade esta representada pela classe Funcionário, que é
responsável por armazenar as informações vindas da classe de fronteira, bem como
os métodos para realização da mesma. Fazem parte também deste pacote as
UN
IM
IN
classes que utilizam a classe Funcionário, conforme citado na figura.
UN
IM
IN
AS
113
Figura 44 - Classe de análise Funcionário
A figura 45 descreve as classes do pacote fornecedor bem como seus
relacionamentos, atributos e métodos que a compõem.
As classes de fronteira são: classe Tela Fornecedor, classe Tela
Pesquisar Fornecedor. São responsáveis por fazer a iteração com o usuário do
sistema Satika, nelas possuem os atributos e os métodos necessários para fazer a
iteração. São exibidos também nessas classes, os dados do fornecedor após uma
pesquisa.
114
As classes de controle são as classes Cadastrar, Alterar, Excluir e
Pesquisar Fornecedor. Nessas classes estão contidos os métodos específicos para
tratar os requisitos do sistema, fazendo a comunicação entre as classes de fronteira
e a classe de controle.
A classe de entidade no sistema Satika é chamada de Fornecedor,
onde é responsável por armazenar as informações e ações vindas das classes de
fronteira. Na figura 45 é possível ver os métodos que realizam essa tarefa. Fazem
parte também deste pacote as classes que utilizam para realizar suas funções a
UN
IM
IN
AS
classe Fornecedor, conforme demonstrado na figura 45.
Figura 45 - Classe de análise fornecedor
115
A figura 46 descreve as classes do pacote médico bem como seus
relacionamentos, atributos e métodos que a compõem.
As classes de fronteira do pacote são: classe Tela Médico, classe Tela
Pesquisar Médico. São responsáveis por fazer a iteração com o usuário do sistema
Satika, nelas possuem os atributos e os métodos necessários para fazer a iteração.
São exibidos também nessas classes, os dados do médico após uma pesquisa.
As classes de controle do pacote são as classes Cadastrar, Alterar,
Excluir e Pesquisar Médico. Nessas classes estão contidos os métodos específicos
fronteira e a classe de controle.
AS
para tratar os requisitos do sistema, fazendo a comunicação entre as classes de
A classe de entidade do pacote no sistema Satika é chamada de
Médico, onde é responsável por armazenar as informações e ações vindas das
classes de fronteira. Na figura 46 é possível ver os métodos que realizam essa
IN
tarefa.
Fazem parte também do pacote médico, as classes que utilizam a
UN
IM
classe Medico para realizar suas funções, conforme citado na figura 46.
UN
IM
IN
AS
116
Figura 46 - Classe de análise pacote médico
A figura 47 mostra os atributos, os métodos e os relacionamentos entre
as classes de fronteira, de controle e entidade do pacote Produto. As classes de
fronteira estão representadas na figura com os nomes de Tela Produto e de Tela
Pesquisar Produto, onde é possível visualizar o resultado da iteração do usuário e o
sistema, contendo os atributos e os métodos específicos para essa classe. As
classes de controle do sistema Satika são: Cadastrar Produto, Alterar Produto,
117
Excluir Produto e Pesquisar Produto. Essas classes são responsáveis pela
comunicação entre as classes de fronteira e a classe de entidade. Possuem
métodos específicos para tratar as requisições, conforme descrito na figura. A classe
de entidade esta representada pela Classe Produto, onde serão registradas as
alterações realizadas pelo usuário.
Fazem parte do pacote produto, as classes que utilizam a classe
UN
IM
IN
AS
Produto para suas realizar funções, conforme demonstrado na figura 47.
Figura 47 - Classe de análise pacote produto
A figura 48 mostra os atributos, os métodos e os relacionamentos entre
as classes de fronteira, de controle e entidade do pacote receituário. As classes de
118
fronteira estão representadas na figura com os nomes de Tela Receituário e de Tela
Pesquisar Receituário, onde é possível visualizar o resultado da iteração do usuário
e o sistema, contendo os atributos e os métodos para essa classe. As classes de
controle do sistema Satika são: Cadastrar Receituário, Alterar Receituário, Excluir
Receituário e Pesquisar Receituário. Essas classes são responsáveis pela
comunicação entre as classes de fronteira e a classe de entidade. Possuem
métodos específicos para tratar as requisições, conforme descrito na figura. A classe
de entidade esta representada pela Classe Receituário, onde serão registradas as
alterações realizadas pelo usuário na classe de fronteira. Faz parte deste pacote a
UN
IM
IN
AS
classe Cliente, conforme citado na figura 48.
UN
IM
IN
AS
119
Figura 48 - Classe de análise pacote receituário
A figura 49 descreve as classes do pacote venda bem como seus
relacionamentos, atributos e métodos que a compõem.
As classes de fronteira do pacote são: classe Tela Venda, classe Tela
Pesquisar Vendas. São responsáveis por fazer a iteração com o usuário do sistema
Satika, nelas possuem os atributos e os métodos necessários para fazer a iteração.
São exibidos também nessas classes, os dados da venda após uma pesquisa.
As classes de controle do pacote são as classes Cadastrar, Alterar,
Excluir e Pesquisar Venda. Nessas classes estão contidos os métodos específicos
120
para tratar os requisitos do sistema, fazendo a comunicação entre as classes de
fronteira e a classe de controle.
A classe de entidade do pacote no sistema Satika é chamada de
Venda, onde é responsável por armazenar as informações e ações vindas das
classes de fronteira. Na figura 49 é possível ver os métodos que realizam essa
tarefa. Fazem parte deste pacote as classes Cliente, Funcionário e Produto,
UN
IM
IN
AS
conforme demonstrado na figura 49.
Figura 49 - Classe de análise pacote venda
121
A figura 50 mostra os atributos, os métodos e os relacionamentos entre
as classes de fronteira, de controle e de entidade do pacote compra. As classes de
fronteira estão representadas na figura com os nomes de Tela Compra e de Tela
Pesquisar Compra, onde é possível visualizar o resultado da iteração do usuário e o
sistema, contendo os atributos e os métodos para essa classe. As classes de
controle do pacote no sistema Satika são: Cadastrar, Alterar, Excluir e Pesquisar
Compra. Essas classes são responsáveis pela comunicação entre as classes de
fronteira e a classe de entidade. Possuem métodos específicos para tratar as
requisições, conforme descrito na figura 50. A classe de entidade esta representada
na classe de fronteira.
AS
pela Classe Compra, onde serão registradas as alterações realizadas pelo usuário
Fazem parte deste pacote as classes Fornecedor e Funcionário,
UN
IM
IN
conforme demonstrado na figura 50.
UN
IM
IN
AS
122
Figura 50 - Classe de análise pacote compra
A figura 51 exemplifica os atributos, métodos e os relacionamentos
entre as classes do pacote Relatório PV. Essas classes são responsáveis por gerar
relatório de produtos mais vendidos.
A classe de fronteira do pacote é classe Tela Relatório PV. Essa classe
é responsável por fazer a iteração com o usuário do sistema Satika, possui os
atributos e os métodos necessários para fazer a iteração.
123
A classe de controle do pacote é a classe Emitir Relatório PV. Nela
estão contidos os métodos específicos para tratar os requisitos do sistema, fazendo
a comunicação entre a classe de fronteira e a classe de controle.
As classes de entidade do pacote no sistema Satika são chamadas de
Venda e Produto, onde são responsáveis por emitir as informações necessárias,
requisitadas pela classe de fronteira. Na figura 51 é possível ver os métodos que
realizam essa tarefa. A classe Produto também faz parte deste pacote, conforme
UN
IM
IN
AS
mostrado na figura 51.
Figura 51 - Classe de análise do pacote Relatório Produtos Mais Vendidos
A figura 52 exemplifica os atributos, métodos e os relacionamentos
entre as classes do pacote Relatório MC. Essas classes são responsáveis por gerar
relatório de clientes que efetuaram as maiores compras na empresa.
A classe de fronteira do pacote é classe Tela Relatório MC. Essa
classe é responsável por fazer a iteração com o usuário do sistema Satika, possui os
atributos e os métodos necessários para fazer a iteração.
124
A classe de controle do pacote é a classe Emitir Relatório MC. Nela
estão contidos os métodos específicos para tratar os requisitos do sistema, fazendo
a comunicação entre a classe de fronteira e a classe de controle.
As classes de entidade do pacote no sistema Satika são chamadas de
Venda e Cliente, onde são responsáveis por emitir as informações necessárias,
requisitadas pela classe de fronteira. Na figura 52 é possível ver os métodos que
realizam essa tarefa. A classe cliente também faz parte deste pacote, conforme
UN
IM
IN
AS
mostrado na figura 52 abaixo.
Figura 52 - Classe de análise do pacote Relatório Melhores Clientes
125
3.5
Classes de Projeto
O diagrama de classes do projeto é geralmente construído para ser
utilizado como uma espécie de “validador” dos requisitos obtidos nos levantamentos
realizados. O diagrama de classes levanta questões como "o que pode acontecer" e
também verifica o que o sistema deve fazer quando questionado a fazer. Este
diagrama fornece ricas visões ao corpo técnico de um projeto, especialmente aos
programadores.
Nos diagramas de classes as visões lógicas e físicas juntamente com
AS
os relacionamentos entre objetos de uma solução, são diagramados. Isto significa
que as classes identificadas nos diagramas de caso de uso estão modeladas no
diagrama de classes.
Os diagramas de classe são chamados diagramas de diagramas
IN
estáticos, porque mostram as classes, com seus métodos e atributos bem como os
relacionamentos estáticos entre elas. Exemplificam quais classes “conhecem” quais
classes ou quais classes “são partes” de outras classes, mas não mostram a troca
de mensagens entre elas.
Os diagramas de classe de um projeto mostram as
diferentes classes que fazem um sistema e como elas se relacionam entre si.
IM
Uma classe define os atributos e os métodos de um conjunto de
objetos. Em UML, essas classes são representadas por retângulos, com o nome da
classe, e contém também os atributos e operações da classe em dois outros
“compartimentos” dentro do retângulo.
UN
Os atributos na UML são mostrados com pelo menos seu nome, e
podem também mostrar seu tipo, valor inicial e outras propriedades. Atributos podem
também ser exibidos com sua visibilidade: públicos, protegidos ou privados.
Os métodos na UML também são exibidos com pelo menos seu nome,
e podem também mostrar seus parâmetros e valores de retorno. Os métodos podem
igualmente aos atributos, mostrar sua visibilidade como: públicos, protegidos ou
privados.
Para exemplificar o diagrama de classes de projeto do sistema Satika,
foi detalhado o caso de uso Registrar Venda, devido a grande quantidade de classes
pertencentes ao projeto como um todo, seria inviável demonstrar o diagrama com
todas as suas classes, portanto, este caso de uso foi detalhado. Esta representada
126
na figura 53, o diagrama de classes Registrar Venda, bem como seus
relacionamentos e métodos. Este diagrama mostra todas as classes responsáveis
por realizar uma venda no sistema Satika.
Para o desenvolvimento do sistema foram utilizados alguns padrões de
UN
IM
IN
AS
projeto que serão descritos juntamente com as classes do sistema.
Figura 53 - Diagrama de classes do projeto registrar venda
127
Na arquitetura MVC (Model View Controler), as classes de negócio e o
código de acesso ao banco de dados geram resultados que devem ser
apresentados pela página JSP. Para transferir dados entre camadas utilizamos
beans. Esses beans representam apenas o grupo de informações geradas após o
processamento.
A classe ActionVenda representa a chamada para a camada de
negócios, gravando os resultados a serem apresentados em beans, tomando a
medida necessária caso algum erro ocorra e informar para o Struts qual deve será a
página apresentada. O método execute deve fazer um cast no parâmetro
ActionVenda para utilizar a classe FormVenda.
AS
A classe FormVenda representa passagem de dados entre a camada
view e a camada controler. Para cada ação dos formulários deverá ser chamado a
classe ActionVenda. Esta classe possui atributos e métodos capazes de buscar os
dados do cliente para ser realizada a venda.
IN
A classe Delegate permite que o código só enxergue invocações
locais, e toda a complexidade das chamadas remotas ficam ocultas dentro dele.
Serve para reduzir o acoplamento entre os clientes da camada de apresentação e os
seviços de negócios. O Delegate oculta os detalhes de implementação por trás do
IM
serviço de negócios, além de facilitar o desenvolvimento da aplicação cliente, o uso
desta classe desata as amarras entre as camadas de apresentação e a tecnologia
da camada de negócio. Atuando como uma abstração para a implementação dos
serviços dos negócios no lado cliente.
UN
A classe VendaDAO herda a classe DAO, que é responsável por todas
as comunicações com o mecanismo de persistência são mediadas por um objeto o
DAO. Esse objeto mapeia informações transportadas em objetos para instruções da
API de persistência e mapeia resultados obtidos dela de volta para os mesmos
objetos de transporte. Toda a lógica de mapeamento e execução das instruções é
deixada dentro do objeto DAO desta forma isolando a aplicação da API de
persistência por completo.
As classes Venda, ItemVendaId e ItemVenda possuem atributos e
métodos responsáveis por registrar uma venda, todas usam a classe Delegate, que
contém um método que insere a venda nessas classes, conforme demostrado na
figura 53.
128
4 PROJETO DE INTERFACE
4.1
Introdução
O projeto de interface considera o protocolo Hypertext Transfer
Protocol (http) para acesso ao sistema, velocidade de acesso às informações e
usabilidade. Todos estes itens devem atender às necessidades da empresa para
a organização de seu negócio. Segundo Husted e outros (2004), o protocolo http
define a forma através da qual os computadores trocam informações entre si,
AS
trata do processo de codificação e decodificação de uma mensagem,
obedecendo a padrões que viabilizam a comunicação. Neste capítulo são
abordados os itens relativos a interface e usabilidade do sistema quais as
melhores técnicas para a construção da interface e é apresentado alguns
4.2
IN
padrões que podem facilitar esta construção.
Definição de interface
Segundo de Wazlawick (2004), o projeto de interface de um
sistema web divide-se em duas camadas: apresentação e aplicação. A camada
IM
de apresentação terá classes com objetos gráficos fazendo a interação direta
com o usuário, ou seja, o usuário entra com suas ações no sistema, enquanto
que, a camada de aplicação é responsável pela parte lógica da interface,
tratando de controlar a abertura e fechamento de janelas, habilitando e
UN
desabilitando botões, entre outras ações. Estas duas camadas são responsáveis
pelo resultado da interação do usuário com o sistema.
Tais princípios são levados em consideração na construção do
Satika System, pois conforme Nielsen (2000, p. 100), “os estudos de usabilidade
indicam um violento foco no conteúdo por parte dos usuários”, Sendo assim, os
dispositivos de interação do sistema foram deixados em destaque, possibilitando
aos usuários que as respostas estejam dispostas no centro da tela de maneira a
direcionar o usuário ao conteúdo do sistema.
O sistema web além de apresentar conteúdo de consistência e
credibilidade, deve ter uma boa apresentação e navegabilidade, tornando o site
acessível ao seu público alvo e atendendo às expectativas do negócio. Sendo
129
assim dispensará treinamentos e reduzirá custos para a empresa. O tempo para
acesso ao sistema deve ser o menor possível, portanto ele precisa ser leve e
exigir o mínimo de recursos da estação que o executa.
O Satika System tem boa aparência, é fácil de usar como também
apresenta conteúdo que atende às necessidades da Satika, com informações
dispostas em local adequado para visualização das funcionalidades fornecidas
pelo sistema. Neste trabalho é apresentado o resultado de usar um padrão para
o desenvolvimento da interface.
4.3
Padrões de construção de interface
AS
Para se obter sucesso na construção da interface de um sistema
web pode-se adotar algumas das metodologias já existentes para facilitar o
desenvolvimento, reduzir erros e também facilitar a manutenção do sistema por
equipes diferentes.
IN
Existem, também, alguns padrões ou frameworks que, de acordo
com (JOHNSON, 1988 apud HUSTED;DUMOULIN,2004), são “uma aplicação
reutilizável e semicompleta que pode ser especializada para produzir aplicações
personalizadas”. No dizer de Husted (2004), os sistemas têm tendência de
IM
serem mais semelhantes que diferentes. Assim, existem padrões tanto para a
construção de um sistema como também para a construção de uma interface
gráfica de acesso ao sistema, sendo que este framework fornece aos
desenvolvedores conjuntos estruturais conhecidos por outros desenvolvedores e
UN
que têm garantia de funcionamento. Estes frameworks já estão pré-formatados e
podem ser usados em outros sistemas fazendo as devidas alterações de acordo
com a necessidade deste novo sistema.
Para criar uma cultura de uso dos padrões de desenvolvimento
usando todos os recursos fornecidos pelo framework corretamente, foi criado um
consórcio chamado World Wide Web Consortium (W3C, 2004),
[...]
que
desenvolve
tecnologias
interoperáveis
(especificações,
manuais, software e ferramentas) para levar a utilização da rede
130
mundial da Internet ao seu potencial pleno. W3C é um fórum para troca
de informações, de comércio, comunicação e conhecimento coletivo.
(W3C DEVELOPS, 2004)
Este consórcio promove o uso de todo o potencial da internet
tornando seu uso mais confiável e agradável para os usuários.
O padrão para construção de interfaces conhecido como ObjectOriented Hypermedia Design Method (OOHDM) utiliza padrões específicos de
AS
atividades para descrever dados relacionados ao modelo conceitual da
navegação e a interface. Trabalha com fases como: atividades, produtos,
mecanismos e interesses do projeto para a construção da interface. O nível de
detalhamento desta metodologia é elevado e é utilizado para a construção de
de
grande
porte.
Esta
metodologia
também
não
abrange
IN
sistemas
profundamente o esquema de projeto e de manutenção do sistema. Visto que o
Satika System não é de grande porte como também não necessita de
detalhamento em profundidade este modelo foi descartado.
IM
Existe também é o Methodology: definition, architecture, design,
implementation (DADI) (Definição, Arquitetura, Design, Implementação). Usa
etapas, tornando o projeto com fases evolutivas desde a idéia inicial até a
implementação.
UN
Neste trabalho foi desenvolvido um sistema web baseando-se no
modelo DADI e estas etapas estão descritas a seguir.
4.4
Definição da interface do sistema
Nesta fase ocorreu o primeiro contato com o protótipo do projeto
que foi desenvolvido. Foi realizada uma reunião de todos os participantes do
projeto com o cliente, buscando informações sobre o negócio da empresa e
sobre como vincular a imagem da empresa com o layout do site. Layout referese ao desenho do site, um esquema do que será apresentado, o resultado que
será mostrado pelo sistema. Esta fase teve as seguintes definições:
131
1. recebimento formal da proposta do projeto apresentado pela
faculdade UNIMINAS por meio do professor Carlos Barros;
2. reunião do grupo para planejar a execução do cronograma e
definição das estratégias iniciais;
3. reunião com o cliente Satika apresentando o projeto e colhendo
as informações referentes ao negócio; nesta etapa obteve-se a
marca da empresa Satika, o padrão de cores adotado pela
empresa como também algumas características de marketing
que a empresa usa atualmente.
AS
A Satika utiliza duas cores para sua marca: o branco e o vermelho.
Estas cores devem estar presentes no sistema. A figura 54 apresenta o logotipo
IM
IN
da empresa Satika.
Figura 54 - Marca empresa Satika
UN
A empresa transmite na sua marca e apresentação das lojas:
credibilidade, segurança e qualidade. Estas características devem ser
repassadas ao sistema que será usado pelos funcionários da empresa. Em um
sistema tais qualidades se refletem em disponibilidade de uso, e numa
visualização agradável. Desenvolvendo o layout buscou-se a valorização dos
produtos e serviços prestados pela Satika.
Na etapa de definição decidiu-se que para a otimização do site
seriam usadas as tecnologias Cascate Style Sheet (CSS), Javascript,
JavaServer Pages (JSP) como padrões de desenvolvimento da interface que
são demonstrados no item 4.7 Implementação .
132
4.5
Arquitetura da interface do sistema
Todas
as
informações
captadas
foram
organizadas
e
documentadas para consulta e histórico do andamento do projeto de interface.
Foram relatados os problemas com relação à navegação, ao fluxo de informação
à interatividade e à praticidade de uso.
Identificou-se que o tempo gasto com a interface não deveria ser
superior ao tempo de desenvolvimento do sistema, pois o que agregará valor
AS
para a empresa é o sistema funcionando corretamente e atendendo aos
requisitos propostos.
A estrutura do site foi definida com um menu fixo à esquerda da
página e a marca da empresa no topo da tela, o menu fixo é inserido a
IN
esquerda, pois o padrão de leitura ocidental inicia a leitura do texto da esquerda
para direita, portanto será o ponto de partida dos usuários, como mostra a figura
UN
IM
55.
Figura 55 - Estrutura do Satika System
133
Este menu usa a tecnologia JavaScript para a abertura de submenus para trabalho no sistema. Quando o usuário selecionar alguma opção do
menu, o sub-menu surgirá com as opções relacionadas a ele.
O JavaScript trata-se de um método padronizado para realizar a
codificação que será usada pelos computadores, ou seja, uma linguagem de
programação que foi desenvolvida em 1955 pela empresa Netscape. Pretende
atender à necessidade de validação de formulários feita pelo navegador
utilizado. O JavaScript também realiza a interação com a página que foi
desenvolvida, e tem sintaxe semelhante a do Java, porém é diferente em seu
AS
conceito como também em seu uso para desenvolvimento.
O código usado para confecção do menu chamado menu.js, cujo
fragmento é mostrado na figura 56, é apresentado no Apêndice A, demonstra o
menu que está implementado usando JavaScript.
IN
//Contents for menu 1
var menuCliente=new Array()
menuCliente[0]='<a href="./cadastroCli.jsp">Cadastro</a>'
menuCliente[1]='<a href="./atualizaBusCli.jsp">Atualizacao</a>'
menuCliente[2]='<a href="./excluiBusCli.jsp">Exclusao</a>'
menuCliente[3]='<a href="./pesquisaCli.jsp">Pesquisa</a>'
menuCliente[4]='<a href="./receituario.jsp">Receituario</a>'
IM
//Contents for menu 2, and so on
var menuMedico=new Array()
menuMedico[0]='<a href="./cadastroMed.jsp">Cadastro</a>'
menuMedico[1]='<a href="./atualizaBusMed.jsp">Atualizacao</a>'
menuMedico[2]='<a href="./excluiBusMed.jsp">Exclusao</a>'
menuMedico[3]='<a href="./pesquisaMed.jsp">Pesquisa</a>'
UN
//Contents for menu 3, and so on
var menuFornecedor=new Array()
menuFornecedor[0]='<a href="./cadastroFor.jsp">Cadastro</a>'
menuFornecedor[1]='<a href="./atualizaBusFor.jsp">Atualizacao</a>'
menuFornecedor[2]='<a href="./excluiBusFor.jsp">Exclusao</a>'
menuFornecedor[3]='<a href="./pesquisaFor.jsp">Pesquisa</a>'
Figura 56 - Fragmento menu.js
Ao clicar nas opções do menu, são exibidos os sub-menus com as
funcionalidades do sistema de acordo com os devidos links. O JavaScript
possibilitou a abertura dos menus de forma deslizante para baixo. O menu
principal, tem-se as opções: Parceiros, Movimentação, Relatórios, Painel. De
forma rápida, este recurso possibilita ao usuário do sistema deixar em exibição
apenas os links que são necessários para seu trabalho, retraindo os demais.
Para a Satika, este recurso é importante, pois o funcionário da
134
empresa ao usar o sistema juntamente com o cliente, no momento de exibir uma
tela para mostrar algum produto, deixará retraído o menu que contém
informações confidenciais, como por exemplo, relatórios. Com isto pode-se usar
a mesma interface para a realização de atividades diferentes, sem a
necessidade de mudar de ambiente dentro do sistema.
Esta funcionalidade
pode ser vista na figura 57, que exibe o item Parceiros retraída, e este recurso é
IM
IN
AS
o mesmo para os itens Movimentação, Relatórios e Painel.
Figura 57 - Menu categoria Retrátil
UN
Todas as ações realizadas exibem seus resultados ao centro da
página, destacando as informações e ocupando a maior parte da tela do monitor
do usuário. Existem alguns padrões para a disposição das informações em um
site, como mostram os modelos avaliados apresentados na figura 58.
AS
135
IN
Figura 58 - Modelos de disposição de informações em um site.
Basicamente estes modelos apresentam a forma de seqüência da
informação em um site, ou seja, os relacionamentos dos menus. O modelo
adotado foi o hierárquico, uma vez que apresenta facilidade de organização para
IM
o modelo de sistema direcionado à venda e compra de produtos e, também,
caso exista a necessidade de disponibilizar o sistema para internet, facilita a
criação de módulos para clientes e funcionários.
Neste modelo, as informações são dispostas de maneira dependente,
UN
onde o menu abrirá sub-menus relacionados a ele. Portanto, facilita a atualização de
informações do site pelo administrador do sistema, de maneira rápida e eficiente,
reduzindo erros e replicação de informação no site. A figura 59 apresenta o modelo
do menu com as opções sendo demonstradas.
IN
AS
136
IM
Figura 59 - Modelo do menu do sistema
A figura 60 a arquitetura da disposição das informações para o
sistema Satika que segue o modelo hierárquico, contendo os menus e telas do
sistema. Por meio deste diagrama foi possível mostrar ao cliente como o site
UN
seria construído e verificar a existência de alguma necessidade adicional
percebida após as reuniões de definição do projeto.
IM
IN
AS
137
Figura 60 - Arquitetura do site
Na fase de arquitetura do sistema estudou-se o controle de
UN
segurança de acesso, os perfis dos usuários e as telas e botões que deveriam
ser liberados de acordo com o perfil do usuário. O sistema deve possuir dois
perfis que devem ter acessos a menus e botões diferentes. O perfil de
funcionário terá acesso às informações usuais do sistema sendo possível
realizar uma venda e cadastrar um cliente entre outros acessos, enquanto que, o
usuário administrador poderá realizar qualquer tipo de alteração no sistema,
inclusive alterar informações sobre outros usuários. Com isto ele consegue
cadastrar novos funcionários, administrar as senhas destes usuários, cadastrar
produtos e remover um funcionário, entre outras ações. A figura 61 apresenta a
primeira tela do sistema que é a de login, que retrata o caso de uso Efetuar
Login CSU - 1. Porém nesta etapa foi desenvolvido apenas o perfil de
administrador.
AS
138
IN
Figura 61 - Controle de acesso
A página de login que é apresentada na Figura 61 foi desenvolvida
usando o código apresentado no Apêndice B. Na figura 62 tem-se um fragmento
UN
<center>
IM
deste código.
<form name="login" action="login.do" method="post">
<table width=225 border=1 bgcolor="gray" cellpadding=3 >
<tr>
<td colspan=2 height="13">
<center>
<p>
<font face="Arial Black" style="font-size: 14pt;">
Ã; rea restrita:
</font>
</p>
</center>
Figura 62 - Trecho da página de login
Segue a estrutura do site mostrada na figura 63, tendo o Diagrama
de Estados de Navegação, este indica quais são as janelas que compõem o
sistema e quais eventos permitem aos usuários navegar de uma janela para
outra.
139
Figura 63 - Diagrama de estados de navegação
Na figura 63, vemos que o site tem apenas duas telas, facilitando
ao usuário encontrar suas funcionalidades no sistema. O usuário do Satika
System não precisará mudar de tela para realizar suas operações, agilizando o
Design
IN
4.6
AS
trabalho e dispensando treinamentos.
Nesta fase de criação da interface do sistema, foi planejada a
harmonia entre cores, traçados, imagens, ilustrações, fotografias e animações,
que aliadas às providências tomadas nas etapas anteriores, dão formas
IM
agradáveis para as telas nas quais o usuário navegue.
A marca Satika estará presente em todas as telas do sistema
sendo assim por possuir a cor vermelha em sua marca, não foi usada esta cor
em outras páginas, deixando em evidencia a marca. O sistema é o instrumento
UN
de trabalho dos funcionários da Satika, portanto toda a área de resposta para o
usuário possui o fundo branco para não causar desconforto quando o
funcionário utilizar o sistema por um longo período de tempo.
O menu de funcionalidades do sistema foi feito em dois tons de
cinza, a tonalidade mais escura trata-se de uma categoria que pode ser
escolhida pelo usuário ao clicar sobre ela. O tom mais claro é para
funcionalidades do sistema. Para interação com o menu não é necessário clicar
sobre todas as opções. O usuário do sistema deve clicar na categoria, após ela
estar selecionada basta passar o mouse sobre as opções desta categoria para
ter acesso as funcionalidades vinculadas a ela. Com o sub-menu aberto é
necessário clicar na ação desejada.
140
O resultado das ações do usuário é apresentado no centro da tela
em cor preta e fina com o fundo da tela branco, com isto a tela é de leitura fácil e
eficiente.
O contorno do menu é arredondado fazendo sistema ter uma
IN
AS
imagem de refinamento, pode-se identificar estas características na figura 64.
IM
Figura 64 - Menu e área de resposta
São considerados pontos importantes:
Tipografia – tipo de fonte utilizado para construção do Satika
UN
System - uma fonte aliada à marca Satika; as fontes usadas no sistema são
VERDANA no menu e nos conteúdos dispostos no site, e ARIAL nos sub-
menus;
Redação e textos – voltados ao usuário que não dispõe de tempo e
paciência para ler textos demasiadamente extensos, sendo exibido apenas o
que é relevante para a compra e venda dos produtos da empresa; limitou-se a
características técnicas dos produtos e a seu preço;
Imagens – as imagens utilizadas foram repassadas pela equipe de
marketing da empresa; no Satika System não serão apresentadas as fotos dos
produtos à venda pela empresa, visto que o cliente estará fisicamente na loja e a
empresa apresenta os produtos ao cliente no momento da compra.
141
Atualmente a empresa Satika usa a figura 65 em divulgações
através de outdoors pela cidade como também em seu web site: a saber,
www.satika.com.br; sendo assim esta imagem foi incluída no sistema afim de
atender às necessidades da marca Satika, tornando o sistema ainda mais
personalizado.
4.7
AS
Figura 65 - Fotografia usada pela empresa
Implementação
IN
A fase de implementação começa com a aprovação do modelo de
layout pelo cliente. Inicia-se o desenvolvimento e os testes de scripts do menu e
da compatibilidade com os browsers usados pela empresa. A empresa usa o
browser Microsoft Internet Explorer 6, e o sistema foi desenvolvido para ser
IM
compatível com versões superiores. No sistema Satika foram usadas páginas
desenvolvidas em JavaServer Pages (JSP), sendo o menu formatado em
JavaScript e o layout usando estilos definidos em Cascate Style Sheet (CSS).
O Satika System é um sistema web que segundo Basham, Sierra e
UN
Bates(2005) é uma relação entre cliente e servidor, cujo cliente é o browser que
o usuário estiver utilizando para realizar pedidos ao servidor, e o servidor é o
computador que processa as requisições dos clientes e retorna aos clientes a
resposta do pedido feito. Para que os browsers realizem estas consultas no
servidor de aplicação eles acessam o sistema que está escrito em forma de
páginas JSP, sendo que traz à funcionalidade de inserir o código JAVA a página
desenvolvida para o sistema.
Segundo Husted e outros (2004), um sistema para aplicações
complexas que exigem regras de negócios elaboradas são inviáveis de serem
construídos apenas através do padrão de desenvolvimento HyperText Markup
Language (HTML) que geralmente são as respostas ou instruções que os
142
servidores retornam para o browser.
Basicamente o HTML diz ao browser como ele deve se comportar
e como apresentar o conteúdo ao usuário que fez a requisição ao servidor.
“Para construir JavaServer Pages, os desenvolvedores começam
criando as páginas HTML da antiga maneira, usando a mesma antiga
sintaxe HTML. Para trazer o conteúdo dinâmico para a pagina, o
desenvolvedor pode também colocar os elementos do script JSP na
página. Os elementos do script são tags que encapsulam a lógica que
AS
é reconhecida pelo JSP.” (Husted et. al., 2004)
Conforme os autores mencionados na citação acima, se o
desenvolvedor criou uma página e inseriu uma tag, esta marca de codificação
IN
por sua vez pode representar muitas instruções Java e este código de
programação ficará oculto na página no cliente sendo possível acesso através
da tag que está em um arquivo da classe Java no servidor.
As páginas do Satika System estão definidas em JSP como visto
IM
na figura 66 que apresenta um trecho da página index.jsp que é a página de
UN
login do Satika System. O código completo pode ser encontrado no Apêndice B.
143
<%@ page contentType="text/html; charset=utf-8"
language="java"
errorPage=""%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" />
<title>Sátika Ótica e Design</title>
<link href="css/css_index.css" rel="stylesheet"
type="text/css" />
<script type="text/javascript" language="JavaScript"
src="js/login.js"></script>
</head>
IM
IN
AS
<body class="oneColFixCtrHdr">
<div id="container">
<div id="header">
<img src="imagens/cabecalho_index.jpg"/>
</div>
<div id="mainContent">
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<center>
<form name="login" action="login.do" method="post">
Figura 66 - Trecho página index.jsp
Com a divisão da página em JSP e HTML o trabalho da equipe de
desenvolvimento pôde ser divido em camadas, sendo aplicação e apresentação.
Na aplicação as regras de negócio foram desenvolvidas em JAVA e usando
UN
Java Server Pages e a apresentação da página HTML. Sendo assim as
camadas são claramente divididas e podendo ser realizadas por equipes
diferentes.
O uso de JSP também agrega rapidez ao desenvolvimento do
sistema, pois como o JSP trabalha marcas de codificação (tags) estas podem
ser utilizadas em outras páginas durante o desenvolvimento tendo reutilização
de código.
A manutenção do site também é favorecida com o uso das tags,
uma vez que no momento de atualização do código que faz referencia a esta tag
pelo desenvolvedor, todas as páginas que tiverem a tag referenciada serão
144
atualizadas automaticamente, uma vez que a tag é uma chamada para um
conjunto de instruções que está em um único arquivo. O sistema será mais
consistente e seguro com o uso das tags.
Portanto toda a regra de negócio do sistema fica fora do
desenvolvimento da interface, possibilitando ao responsável se dedicar apenas à
usabilidade e à disposição das informações no site, e até mesmo não exigindo
conhecimentos profundos em programação e regras de negócio da empresa
para a construção da interface.
No sistema Satika System a interface foi incrementada com
AS
Cascading Style Sheets CSS, fazendo que todas as informações sobre
formatações de fontes, layout e imagens da página fiquem em um único local e
evitando ser inserido no código da página principal.
A linguagem do CSS traz folhas de estilos que são utilizadas para
IN
definir a forma de apresentação de documentos feitos para web. Durante o
desenvolvimento arquivos .css, que estão apresentados nos Apêndices C,D,E e
F são criados e, no Satika System, tem-se como exemplo, o css_index.css que
apresenta as definições da página índex.jsp. Neste documento não são
IM
inseridas classes que definem a página e este arquivo de CSS é inserido nas
páginas JSP. A figura 67 mostra um fragmento da página índex.jsp.
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" />
<title>Sátika Ótica e Design</title>
UN
<link href="css/css_index.css" rel="stylesheet"
type="text/css" />
<script type="text/javascript" language="JavaScript"
src="js/login.js"></script>
</head>
Figura 67 - Chamada do arquivo CSS
No trecho apresentado na figura 67 possui o caminho do arquivo que
contém todas as características de exibição da página, o css_index.css.
Apresentado na figura 68 um trecho do código do arquivo
css_index.css que está completo no Apêndice C no qual estão descritas as
configurações das características dos elementos que são carregadas pelas páginas
que fizerem referência a este arquivo de folha de estilo.
145
body {
font: 100% Verdana, Arial, Helvetica, sans-serif;
background: #666666;
margin: 0; padding: 0;
text-align: center;
color: #000000;
}
.oneColFixCtrHdr #container {
width: 800px;
background: #FFF000;
margin: 0 auto;
border: 1px solid #000000;
text-align: left border-width: 1px;
border-color: black;
}
Figura 68 - Trecho do arquivo css_index.css
Sendo assim, para o desenvolvimento de uma nova interface ou
AS
uma mudança na interface do site, basta ao desenvolvedor da interface alterar o
arquivo CSS. Existem outras folhas de estilos para o sistema Satika System que
estarão exibidos nos Apêndices C,D,E,F .
As folhas de estilos trazem facilidades de gerenciamento da
IN
interface, rápida identificação de problemas e solução caso seja necessária
alguma intervenção no sistema.
A implementação da interface se deu através do uso destas várias
tecnologias tornando o Satika System um sistema capaz de acompanhar
IM
possíveis mudanças de usabilidade e permitindo a qualquer desenvolvedor que
conheça as soluções aqui usadas prestar manutenção.
Caso de uso
UN
4.8
No estudo de caso é apresentado todas as tecnologias já
explicadas nos tópicos anteriores sendo utilizadas no site tendo a página
principal do usuário, indexAdm.jsp como foco.
A figura 69 mostra tela de login do sistema índex.jsp que é a
primeira tela do sistema.
146
AS
Figura 69 - Tela de login do sistema
Após o usuário ter validado suas credenciais no sistema, ele é
direcionado para a página indexAdm.jsp possuindo a tela de trabalho do usuário,
esta tela contém todas as funcionalidades do sistema, como mostrada na figura
UN
IM
IN
70.
Figura 70 - Página IndexAdm.jsp
Na página indexAdm.jsp são exibidas configurações de imagens,
fundo e fontes de acordo com as informações contidas nos arquivos css_int.css,
sdmenu.css e menu.css.
No arquivo indexAdm.jsp foi feita a divisão do site em menu,
cabeçalho, e corpo da página, cada parte possui seu arquivo de CSS
147
correspondente, existe uma imagem que é carregada apenas quando o usuário
ainda não selecionou nenhuma funcionalidade do sistema, chamada “logo” que
é apresentada nas últimas linhas da figura 71. Esta figura mostra o código da
página indexAdm.jsp e em negrito estão as chamadas para os arquivos CSS.
<%@ page contentType="text/html; charset=utf-8" language="java" errorPage="" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Sática Óptica e Design</title>
<link href="css/css_int.css" rel="stylesheet" type="text/css" />
<link rel="stylesheet" type="text/css" href="css/sdmenu.css" />
<script type="text/javascript" src="js/sdmenu.js"></script>
UN
IM
IN
AS
<link rel="stylesheet" type="text/css" href="css/menu.css" />
<script type="text/javascript" src="js/menu.js"></script>
<script type="text/javascript">
// <![CDATA[
var myMenu;
window.onload = function() {
myMenu = new SDMenu("my_menu");
myMenu.init();
mladdevents();
};// ]]></script></head>
<body class="twoColFixLtHdr">
<div id="container">
<div id="header"><img src="imagens/cabecalho_admin.jpg"></img></div>
<div id="sidebar1">
<div style="float: left" id="my_menu" class="sdmenu">
<div>
<span>Parceiros</span>
<a href="#"
onmouseover="dropdownmenu(this, event, menuCliente, '165px')"
onmouseout="delayhidemenu()">Cliente</a> <a href="#"
onmouseover="dropdownmenu(this, event, menuMedico, '165px')"
onmouseout="delayhidemenu()">Médico</a>
<a href="#"
onmouseover="dropdownmenu(this, event, menuFornecedor, '165px')"
onmouseout="delayhidemenu()">Fornecedor</a>
<a href="#"
onmouseover="dropdownmenu(this, event, menuFuncionario, '165px')"
onmouseout="delayhidemenu()">Funcionário</a>
</div>
<div>
<span>Movimentação</span>
<a href="./produto.jsp">Produto</a>
<a href="./venda.jsp">Venda</a>
<a href="#">Compra</a>
<a href="#">Fluxo de Caixa</a>
</div>
<div >
<span>Relatórios</span>
<a href="#">Melhores Clientes</a>
<a href="#">Vendas</a>
<a href="#">Produtos vendidos</a>
<a href="#">Médico mais indicados</a>
</div>
<div>
<span>Painel</span>
<a href="./logout.do">Logout</a>
</div>
</div>
</div>
<div id="mainContent" >
<br /> <br /> <br /> <br /> <br /> <br /> <br />
<center>
<img src="imagens/logo.jpg"/>
</center>
<br /> <br /> <br /> </div></div></body>
</html>
Figura 71 - Código página indexAdm.jsp
148
A formação do menu no arquivo indexAdm.jsp, utiliza a tecnologia
JavaScript para seu funcionamento. Na figura 72 segue o trecho correspondente
a chamada do recurso JavaScript e suas configurações de fonte e cor de fundo
oriundas do arquivo menu.css.
<script type="text/javascript" src="js/sdmenu.js"></script>
AS
<link rel="stylesheet" type="text/css" href="css/menu.css" />
<script type="text/javascript" src="js/menu.js"></script>
<script type="text/javascript">
// <![CDATA[
var myMenu;
window.onload = function() {
myMenu = new SDMenu("my_menu");
myMenu.init();
mladdevents();
};// ]]></script></head>
Figura 72 - Trecho menu.css
IN
Após a chamada do menu.js dando continuidade ao código da
página indexAdm.jsp verifica-se as opções disponíveis do menu que são
UN
IM
Movimentação, Parceiros, Relatórios e Painel como apresentado na figura 73.
149
IN
AS
<body class="twoColFixLtHdr">
<div id="container">
<div id="header"><img src="imagens/cabecalho_admin.jpg"></img></div>
<div id="sidebar1">
<div style="float: left" id="my_menu" class="sdmenu">
<div>
<span>Parceiros</span>
<a href="#"
onmouseover="dropdownmenu(this, event, menuCliente, '165px')"
onmouseout="delayhidemenu()">Cliente</a>
<a href="#"
onmouseover="dropdownmenu(this, event, menuMedico, '165px')"
onmouseout="delayhidemenu()">Médico</a>
<a href="#"
onmouseover="dropdownmenu(this, event, menuFornecedor, '165px')"
onmouseout="delayhidemenu()">Fornecedor</a>
<a href="#"
onmouseover="dropdownmenu(this, event, menuFuncionario, '165px')"
onmouseout="delayhidemenu()">Funcionário</a>
</div>
<div>
<span>Movimentação</span>
<a href="./produto.jsp">Produto</a>
<a href="./venda.jsp">Venda</a>
<a href="#">Compra</a>
<a href="#">Fluxo de Caixa</a>
</div>
<div >
<span>Relatórios</span>
<a href="#">Melhores Clientes</a>
<a href="#">Vendas</a>
<a href="#">Produtos vendidos</a>
<a href="#">Médico mais indicados</a>
</div>
<div>
<span>Painel</span>
<a href="./logout.do">Logout</a>
</div>
</div>
</div>
<div id="mainContent" >
IM
Figura 73 - Trecho página indexAdm.jsp
Neste trecho acima verificamos que são usadas as configurações
do arquivo css_int.css, esta identificação foi invocada na classe twoColFixLtHdr.
A característica “onmouseover” faz que seja exibido o menu assim que o usuário
colocar o ponteiro do mouse sobre o texto. Também identificamos a variável que
utilizada
UN
será
pelo
menu.js,
que
são
menuCliente,
menuFornecedor,
menuMedico, menuFuncionário.
Através destas variáveis o JavaScript se encarrega de direcionar o
usuário através do sistema, pois o estará fixo à esquerda e todas as respostas
das interações dos usuários com o menu é apresentada no centro da página.
Com o uso do menu.js verificamos para quais páginas os usuários
serão direcionados pelo sistema. Segue outro trecho do menu.js na figura 74.
150
//Contents for menu 1
var menuCliente=new Array()
menuCliente[0]='<a href="./cadastroCli.jsp">Cadastro</a>'
menuCliente[1]='<a href="./atualizaBusCli.jsp">Atualizacao</a>'
menuCliente[2]='<a href="./excluiBusCli.jsp">Exclusao</a>'
menuCliente[3]='<a href="./pesquisaCli.jsp">Pesquisa</a>'
menuCliente[4]='<a href="./receituario.jsp">Receituario</a>'
//Contents for menu 2, and so on
var menuMedico=new Array()
menuMedico[0]='<a href="./cadastroMed.jsp">Cadastro</a>'
menuMedico[1]='<a href="./atualizaBusMed.jsp">Atualizacao</a>'
menuMedico[2]='<a href="./excluiBusMed.jsp">Exclusao</a>'
menuMedico[3]='<a href="./pesquisaMed.jsp">Pesquisa</a>'
Figura 74 - Trecho menu.js
Para tanto com estas definições podemos concluir que o menu
AS
possui configurações concentradas em um único arquivo JavaScript, chamado
menu.js sendo destinado ao programador administrá-lo. Para alteração na forma
de exibição do menu como alterar letras, cores deve-se alterar o arquivo CSS
correspondente a esta funcionalidade que são os arquivos menu.css e
IN
sdmenu.css permitindo ao responsável pela interface realizar todas suas
modificações sem necessidade de trabalhar com a codificação do sistema. O
arquivo indexAdm.jsp está enxuto e com chamadas para outros arquivos do
sistema, facilitando a divisão de trabalho e a administração do sistema.
IM
Quando o usuário selecionar alguma opção do menu a respectiva
página o resultado da solicitação é exibido no centro da página. Será
apresentado o usuário selecionando a opção do menu Cadastrar Receituário e
UN
segue um trecho da página receituário.jsp na figura 75.
151
IM
IN
AS
<form action="./cadastroRec.do" method="post"
name="receituario">
<input type="hidden" name="cpf" />
<input type="hidden" name="medico" />
<table width="457" border="0" cellpadding="5">
<tr>
<td width="400">
<div align="left">
Cliente(cpf):
</div>
</td>
<td width="800">
<div align="left">
<input type="text" name="cpf1" style="WIDTH: 200px; height:
20" disabled="disabled" maxlength="11" />
<input type="button" name="pesqCli" value="Pesquisar"
onclick="PopUp('pesCli.jsp',500,400);"/>
</div>
</td>
</tr>
<tr>
<td width="400">
<div align="left">
Médico(cpf):
</div>
</td>
<td width="800">
<div align="left">
<input type="text" name="medico1" style="WIDTH: 200px; height:
20" disabled="disabled"maxlength="11" /
<input type="button" name="pesqMed" value="Pesquisar"
onclick="PopUp('pesMed.jsp',500,400);"/>
</div>
</td>
</tr>
<tr>
<td>
<div align="left">Data Consulta:
UN
Figura 75 - Trecho da página receituário.jsp
O resultado deste código é apresentado na figura 76, o resultado
estará no centro da página, sendo assim de qualquer ponto do site pode voltar
ao menu e navegar através de suas funcionalidades.
IN
AS
152
Figura 76 - Página receituário
Os botões exibidos pela página têm cantos arredondados que
IM
seguem o padrão de apresentação do menu e apresentam o efeito de sombra
para proporcionar sensação de relevo para o usuário, sugerindo que o
pressione.
No Capítulo 6 deste trabalho serão apresentadas as solução de
UN
implementação de codificação e regras de negócios do Satika System. Será
evidenciado ainda mais a separação entre a camada de interface e a camada de
aplicação.
153
5 PERSISTÊNCIA
Os bancos de dados surgiram graças à necessidade das empresas
de armazenar grandes quantidades de informação, de forma rápida, simples e
confiável, e que pudessem ser acessadas em qualquer momento, sem a
necessidade de se deslocar às salas dedicadas a arquivar documentação, como
até a pouco tempo se fazia.
De acordo com Sanches (2005), os bancos de dados nasceram no
final dos anos sessenta. No entanto, com relação aos programas que os
utilizavam, não era preciso se preocupar com manutenção nem armazenagem,
AS
pois qualquer mudança no banco de dados, à princípio, não os afetaria.
Normalmente um dado está associado a um conceito completo e é
dividido em campos, ou atributos, que dão valores a propriedades
IN
desses conceitos. Possivelmente alguns dados podem apontar
diretamente ou referenciar indiretamente outros dados, o que faz parte
da caracterização do modelo adotado pelo banco de dados. (BANCO
de Dados, 2008).
IM
No projeto a ser desenvolvido, o banco de dados servirá para
armazenar todas as informações que serão inseridas e manipuladas no sistema
Satika System. O banco será utilizado pela aplicação bem como pelos usuários
UN
operadores de aplicação ou outros usuários sofisticados.
Os
operadores
de
aplicação
são
usuários
de
transações
parametrizadas cujas interfaces são padronizadas, pré-programadas e
previamente testadas. [...]. Não requerem nenhum conhecimento do
sistema além da própria aplicação. Usuários sofisticados lidam com
problemas complexos que requerem familiaridade com as facilidades
do SGBD para atender aos seus requisitos. Utilizam pacotes de
programas em estação de trabalho próprias, alimentadas com dados
extraídas do banco de dados. (MELO; SILVA; TANAKA, 1997, p. 18).
O banco de dados permitirá inserir, modificar e excluir dados,
sendo que serão salvas informações de dois tipos: dados de usuários (usados
pela aplicação) e os dados do sistema (aqueles que o banco de dados utiliza
154
para sua administração, como por exemplo, dados dos usuários que têm acesso
ao banco de dados).
Em se tratando de persistência de dados, Melo, Silva e Tanaka
(1997) afirmam que persistência significa a capacidade dos objetos do banco de
dados persistirem a diferentes execuções de rotinas de aplicação. Os objetos
persistentes são armazenados fora dos programas que os utilizam e sobrevivem
a falhas, por exemplo, de transação e de hardware. Eles sofrem mudanças de
estado e podem recuperar seu estado inicial através de um mecanismo de
controle de versão do Sistema de Gerenciamento de Banco de Dados, por
5.1
AS
exemplo.
Organização do banco de dados
IN
O banco de dados da aplicação Satika System está organizado de
forma a cumprir os seguintes objetivos:
atender com rapidez adequada à aplicação de acordo com as
solicitações dos usuários da empresa;
ter índice de redundância baixo;
IM
ter alta capacidade de acesso para ganhar o maior tempo possível na
realização de consultas;
ter alto índice de integridade, o que significa que ao ter muitos usuários
atacando o banco de dados não terá falhas na inserção e/ou atualização de
UN
dados. Não ocorrerão erros por redundância ou lenta atualização;
ter um nível satisfatório de segurança e privacidade já que os dados
que serão armazenados no banco de dados serão confidenciais e importantes.
Neste ponto, também entram os meios físicos de proteção contra fogo, roubo,
etc;
deverá ser possível sua constante atualização para não deixar o banco
de dados antigo e sem utilidade. O banco possuirá uma independência física e
lógica dos dados, possibilitando que, ao mudar algum aspecto físico em sua
organização ou fazer mudanças na estrutura lógica, como por exemplo, agregar
novos campos a uma tabela, a aplicação não será afetada.
155
5.2
Sistema de informação Gerencial do Banco de Dados
“O Gerenciamento de banco de dados está evoluindo, deixando de
ser uma aplicação especializada para tornar-se o componente central de um
ambiente moderno de computação.” (SILBERSCHATZ; KORTH; SUDARSHAN,
1999, p.XV)
O banco de dados da aplicação Satika System será criado e
mantido pelo sistema gerencial de banco de dados MYSQL que está composto
de:
Gerenciamento do banco de dados: conjunto de programas não visíveis ao
AS
usuário final que se encarregarão da privacidade, da integridade, da segurança
dos dados e a interação com o sistema operacional. Proporcionará uma interface
entre os dados, a aplicação e o usuário final.
Dicionário de dados: onde se salvam todas as propriedades do banco de
dicionário conterá:
IN
dados tais como, descrição da estrutura, relações entre os dados, etc. O
a descrição externa, conceitual e interna do banco de dados;
as restrições sobre os dados;
o acesso aos dados;
IM
as descrições das contas de usuário;
as permissões dos usuários;
os esquemas externos de cada programa.
Administrador do banco de dados: pessoa responsável pelo controle do
UN
sistema de gerenciamento do banco de dados. As principais tarefas do
administrador são:
a definição do esquema lógico e físico do banco de dados;
a atribuição e edição de permissões para os usuários;
manutenção da segurança no banco de dados;
manutenção geral do sistema de gerenciamento do banco de dados.
Linguagens: o sistema de gerenciamento de banco de dados proporcionará
uma série de linguagens para a definição e manipulação do banco de dados.
Estas linguagens são as seguintes:
linguagem de definição de dados (DDL) - para definir os esquemas do
banco de dados;
156
linguagens de manipulação de dados (DML) - para manipular os dados
do banco de dados;
linguagem de controle de dados(DCL) - para a administração de
usuários e segurança no banco de dados.
O tipo de linguagem de manipulação de dados usada no projeto é
a procedimental que requer do usuário especificação de quais dados são
desejados e como chegar até eles. Para isso é feita uma query (pergunta) que é
um pedido de consulta de informação.
AS
5.2.1 A escolha do MYSQL
A escolha do gerenciador de banco de dados deve ser bem feita e
aspectos como desempenho, recursos, documentação e suporte devem ser
considerados. Para escolher o SGBD, foi preciso entender bem quais recursos a
IN
aplicação precisa, tentar estimar o volume de dados, avaliar o hardware
disponível, certificar-se das funcionalidades necessárias e, posteriormente,
procurar por informações mais detalhadas.
A aplicação a ser desenvolvida é ligada à internet, mas no entanto
IM
é bem simples, necessitando-se apenas de um banco de dados para armazenar
o conteúdo do site. Foi escolhido o MySQL que é uma opção satisfatória e é
facilmente encontrado em serviços de hospedagem.
O MySQL é focado na agilidade. Assim, como a aplicação
UN
necessita de retornos rápidos e não envolve operações complexas, foi a opção
mais adequada, pois é otimizado para proporcionar processamento rápido dos
dados e tempo curto de resposta sem exigir muito do hardware.
A união da base de dados com o sistema gerenciador de base de
dados é denominada Sistema de base de dados.
O Sistema de base de dados terá os seguintes objetivos:
evitar a redundância de dados e a incoerência - o sistema de base
de dados garantirá que eventuais mudanças em alguns dados sejam feitas
mantendo a coerência de toda a base de dados;
facilidade no acesso aos dados - o sistema provê mecanismos
para recuperar dados específicos de qualquer natureza, a partir de subconjuntos
157
inter-relacionados da base de dados;
compartilhamento de dados - os dados serão armazenados em
uma base de dados de acordo com um pequeno conjunto de formatos definidos
pelo sistema gerenciador de base de dados;
controle de acesso para múltiplos usuários - será permitido que
vários usuários atualizem os dados simultaneamente, sendo supervisionadas
atualizações concorrentes para evitar dados inconsistentes;
segurança - serão gerenciados quais dados serão visíveis
(acessíveis) por quais usuários, impedindo que usuários não autorizados tenham
5.3
Arquitetura do banco de dados
AS
acesso a dados sigilosos.
Um propósito geral do sistema de base de dados é esconder certos
IN
detalhes de como os dados são armazenados ou mantidos, mas permitindo que
os mesmos sejam recuperados eficientemente. Em outras palavras, proporcionar
aos usuários uma visão abstrata dos dados. Assim foram definidos três níveis de
abstração pelos quais a base de dados pode ser vista:
IM
Nível Interno ou Físico: é o nível mais perto do armazenamento
físico dos dados (nível mais baixo). Permite escrevê-los tal qual estão
armazenados no computador. Neste nível são definidos os arquivos que contêm
a informação, a localização dos mesmos e sua organização, ou seja, criam-se os
UN
arquivos de configuração.
Nível conceitual: Neste nível representam-se os dados que vão ser
utilizados sem levar em conta aspectos como o que representamos no nível
interno.
Descrevem-se
quais
dados
são
armazenados
e
quais
os
relacionamentos entre eles (a base de dados é descrita como um número de
estruturas relativamente simples).
Nível externo ou de Visão: é o mais próximo ao usuário (nível mais
alto). Este nível expõe apenas parte da base de dados. Este nível simplifica a
interação, com o sistema, de usuários que necessitam apenas de uma parte da
base de dados.
Na figura 77 é possível visualizar o esquema que representa a
classificação de níveis utilizada pelo Satika System:
IN
AS
158
Figura 77 - Esquema de Níveis
Modelagem do banco de dados
IM
5.4
“[...] o projetista escolhe o modelo de dados e, por meio da
aplicação de seus conceitos, transcreve as necessidades específicas em um
esquema
conceitual
de
banco
de
dados.”
(SILBERSCHATZ;
KORTH;
UN
SUDARSHAN, 1999, p.47)
A Modelagem conceitual é uma fase importante no projeto de uma
aplicação de base de dados bem sucedida. O Modelo de dados é uma coleção
de ferramentas conceituais para descrição, relacionamentos, semântica e
restrições dos dados. Hay (1999) trata o modelo de dados como uma
representação das coisas significativas para a empresa e o relacionamento entre
elas. Também afirma que o modelo de dados é a estrutura fundamental dos
dados da empresa, que depois será refletida na estrutura do banco de dados
criado para lhe dar sustentação.
O modelo de dados usado no projeto foi o Modelo Entidade–
Relacionamento que é um tipo de modelo lógico baseado em objetos. Este
159
modelo se obtém em tempo de projeto do banco de dados. Foi proposto por
Peter Chen em 1976 e desde então vem sendo utilizado de uma forma muito
global. Ele facilita a descrição de dados nos níveis conceituais e de visão,
proporcionando ampla e flexível capacidade de estruturação por permitir a
especificação de restrições de dados de forma explícita.
O modelo Entidade–Relacionamento baseia-se numa percepção
do mundo real que consiste em uma coleção de entidades e de relacionamentos
entre essas entidades, permitindo representar graficamente a estrutura lógica do
banco de dados da aplicação Satika System.
Durante a construção do modelo de dados é essencial a abstração
AS
do mundo real, ou seja, do negócio que se deseja modelar. Segundo Gödel
(apud Hay, 1999, p. 255), o teorema de Gödel na matemática afirma que todo
sistema lógico tem uma inconsistência fundamental, alguma coisa que pode ser
expressa no sistema, mas não pode ser comprovado. Ele sugere que, a medida
IN
que se aproxima dos limites da modelagem de dados, se percebe que este
teorema é válido, mas, no entanto, é possível descrever o mundo a nossa volta
se estivermos dispostos a libertar a mente do concreto e enfrentarmos cada vez
mais os conceitos abstratos.
IM
Os principais elementos do modelo Entidade-Relacionamento são
as entidades com seus atributos e as relações entre entidades.
Entidade: trata-se de um objeto do qual se recolherá uma informação de
UN
interesse para o banco de dados e é representada graficamente por um
retângulo. A modelagem desenvolvida apresenta entidades que podem ser tanto
um objeto de existência física (entidade concreta), como um produto ou um
fornecedor, quanto pode ser conceitual (entidade abstrata) como, por exemplo,
uma venda, uma compra, etc. As entidades serão normais ou fracas. As normais
são as que não dependem de outras entidades para existir, como exemplo a
entidade Fornecedor, enquanto que as entidades fracas sempre dependem de
outra entidade, não têm sentido por elas mesmas. Exemplificando, é possível
visualizar que a entidade Item_Compra depende da entidade Compra , pois não
haverá item de compra se não houver compra.
Um conjunto de entidades é um grupo de entidades do mesmo
tipo. Por exemplo, é possível definir o conjunto de entidades de todos os clientes
160
de uma mesma filial da Satika Óptica (Clientes). Uma entidade Pessoa pode ser
uma entidade Funcionário, uma entidade Cliente, uma entidade Médico, ambas
ou nenhuma delas.
Cada entidade tem atributos – propriedades particulares que a
descrevem. Por exemplo, uma entidade Cliente é descrita pelos atributos
“PES_CPF”, “PES_NOME” e “REC_COD”, etc, já uma entidade Funcionário é
descrita pelos atributos “PES_FUN_USUARIO” , “PES_FUN_SENHA” etc.
Assim, a base de dados compreende uma coleção de conjuntos de
entidades contendo, cada uma, certo número de entidades do mesmo tipo. Uma
AS
entidade em particular possui um valor para cada um de seus atributos.
Relação: A relação é definida como uma associação entre duas ou mais
entidades. Por exemplo, foi definida uma relação que associa um fornecedor a
uma compra e uma pessoa a uma venda; isto especifica que uma compra é feita
IN
de um fornecedor e uma venda é feita pra um cliente, respectivamente.
Outra característica é o grau de relação, sendo as de grau 1
relações que só relacionam uma entidade consigo mesma. As de grau 2 são
relações que associam duas entidades diferentes, e as de grau n que se tratam
IM
de relações que unem mais de duas entidades. No projeto Satika System foram
relacionadas entidades apenas com grau 2.
Atributo: Define-se como cada uma das propriedades de uma entidade ou
UN
relação. Cada atributo tem um nome e todos os possíveis valores que pode ter.
Dentro de uma entidade tem que haver um atributo principal que identifica à
entidade e seu valor tem que ser único. Um exemplo de atributo é o
“PES_COD”, dentro da entidade Pessoa.
Na figura 78 é possível visualizar o DER (Diagrama Entidade-
Relacionamento) que foi o resultado do processo de modelagem do projeto:
IN
AS
161
IM
Figura 78 - DER Satika System
5.4.1 Explicando o Modelo
No modelo proposto apresentado na figura 78 é possível observar
as seguintes entidades: Receituário, Pessoa, Endereço, Fornecedor, Compra,
UN
Item_Compra, Produto, Item_Venda e Venda.
Uma entidade Pessoa pode ser um funcionário (expresso pelos
atributos de prefixo PES_FUN_), um médico (expresso pelos atributos de prefixo
PES_MED_) ou um cliente da empresa (expresso pelos demais atributos). Os
atributos PES_DATA_CRIACAO, PES_STATUS e END_COD (migrado da
entidade Endereço) são atributos comuns a todas as pessoas. A chave da
entidade Pessoa é expressa por seu código. Uma pessoa tem um endereço e
pode ou não ter um receituário.
O endereço é composto pelos atributos básicos de qualquer
endereço: rua, número, cep, cidade, bairro e estado. A entidade Endereço é
identificada pelo atributo chave END_COD.
162
O receituário é descrito como o documento do cliente onde
constam seus dados optométricos, a data da consulta seu código e o código de
seu médico. O atributo que identifica a entidade é o REC_COD. O receituário
não é obrigatório, uma vez que o cliente pode apenas querer comprar um óculos
de sol, por exemplo.
A entidade Fornecedor possui atributos referentes a ele bem como
à pessoa física que o representa; também possui a data de sua criação
(cadastramento), seu status(ativo e inativo) e o atributo END_COD, chave
primária da entidade Endereço.
Dados de uma compra serão gravados na entidade Compra que
AS
possui como atributos seu código, data, valor total, forma de pagamento e
descrição. O fornecedor e o cliente são derivados das entidades Fornecedor e
Pessoa respectivamente.
A entidade Item_Compra representa os itens de uma compra. Suas
IN
chaves primárias são COM_COD e ITE_COD representando que uma compra
pode conter apenas vários itens. Os itens são de um produto, possuem um
preço unitário e uma quantidade.
O produto é identificado por seu código, possui um tipo, uma
IM
descrição, uma grife e uma cor.
Dados de uma venda serão gravados na entidade Venda que
possui como atributos seu código, data, valor total, forma de pagamento,
descrição e comissão. O Cliente que efetuou a compra e o funcionário de quem
UN
ele comprou (aquele que receberá a comissão) são derivados das entidades
Pessoa, com os atributos PES_COD_CLIENTE e PES_COD_FUN.
Uma venda possui itens que são derivados da entidade
Item_Venda. A entidade Item_Venda possui os atributos ITE_COD e VEN_COD
que
a
identificam
bem
como
PRO_COD,
ITE_PRECO_UNITARIO
e
ITE_QUANTIDADE.
5.4.2 Restrições em relacionamentos
Durante o processo de modelagem para os relacionamentos foram
definidas certas restrições que limitam as possíveis combinações de entidades
que podem participar do conjunto de relacionamentos. Tais restrições foram
163
determinadas a partir da situação real que o modelo entidade-relacionamento
representa.
Segundo estudos de Bertei (2008) uma restrição importante é a
cardinalidade, que expressa o número de entidades ao qual outra entidade pode
estar associada via um relacionamento. No processo de modelagem do banco
para a aplicação Satika System foram usados os seguintes tipos de
cardinalidade:
um-para-um: uma entidade em A está associada com no máximo
uma entidade em B; e vice-versa. Pode-se ver na figura 79 o diagrama
UN
IM
IN
fornecedor tem um endereço.
AS
expressando a cardinalidade, bem como, um exemplo da aplicação onde um
Figura 79 - Cardinalidade : um-para-um
um-para-muitos: uma entidade em A está associada a qualquer
número de entidades em B, enquanto que uma entidade em B está associada
com no máximo uma entidade em A. Isto pode ser visto na figura 80.
164
AS
Figura 80 - Cardinalidade : um-para-muitos
Se as posições de A e B forem trocadas, pode-se denominar sua
IM
IN
cardinalidade como muitos-para-um. A figura 81,figura 80 mostra isto.
Figura 81 - Cardinalidade : muitos-para-um
UN
É possível encontrar também algumas versões da cardinalidade
um-para-muitos havendo também do tipo um-para-um-ou-muitos e um-parazero-ou-muitos. Assim na figura 82 é possível observar um exemplo onde uma
venda tem um ou muitos itens de venda e por sua vez zero ou muitos itens de
venda são relativos a um produto.
AS
165
5.4.3 Atributos chaves
IN
Figura 82 - Cardinalidade um para muitos
Uma tarefa importante na modelagem do banco de dados foi
especificar a distinção entre entidades e relacionamentos. Para ser feita tal
IM
distinção, foi assinalada para cada conjunto de entidades uma chave – conjunto
de um ou mais atributos que nos permitirá identificar inequivocamente uma
entidade em um conjunto de entidades. No processo de definição das chaves
percebeu-se que havia diversos conjuntos distintos de atributos que poderiam
UN
servir como chaves candidatas; no entanto procurou-se escolher e nomear as
menores chaves possíveis (cujos subconjuntos não sejam chaves), que
passaram a ser conhecidas como chaves primárias.
Organização de Arquivos
O objetivo do sistema de base de dados é simplificar e facilitar o
acesso aos dados. Entretanto, um fator principal de satisfação (ou de
insatisfação) do cliente é o desempenho da base de dados, uma vez que se o
tempo de resposta ao realizar uma consulta for muito grande o sistema será
desvalorizado. O desempenho do sistema de base de dados dependerá da
166
eficiência das estruturas computacionais usadas para representar os dados na
base e de como o sistema é capaz de operar nessas estruturas de dados.
5.5
Hibernate
Mudanças significativas foram provocadas na forma como os
softwares são produzidos e mantidos. Isso se deu com a introdução da
Orientação a Objetos no contexto de desenvolvimento de software. Essas
mudanças foram motivadas pela nova perspectiva adotada pelo paradigma
Orientado a Objetos, em oposição ao paradigma Estruturado.
É inegável que o mercado há algum tempo já percebeu que a
AS
adoção da orientação a objetos melhora a qualidade do produto final, pois utiliza
conceitos já consagrados em outras áreas, que facilitam a manutenção e a
evolução dos sistemas. Sendo assim, muitas áreas do desenvolvimento de
software foram reestruturadas, pois práticas, teorias e técnicas que eram
IN
adequadas ao modelo convencional não puderam ser aplicadas de forma
irrestrita na criação de software Orientado a Objetos. Uma dessas áreas é a que
trata da persistência dos dados.
Os SGBDs conquistaram um lugar de destaque em comparação a
IM
outras tecnologias de armazenamento de dados. Embora estes produtos
realizem seu papel de modo satisfatório no mundo relacional, quando utilizados
no contexto orientado a objetos adquirem alta complexidade, pois a aplicação
passa a necessitar de um processo intermediário de conversão dos dados.
UN
Para que não fosse necessária nenhuma conversão, a opção ideal
seria a adoção de um banco de dados orientado a objetos, pois a camada de
persistência encontrar-se-ia no mesmo nível de abstração da aplicação. Outra
opção seria o uso de bancos de dados relacionais estendidos, que também
fornecem transparência, pois o processo de conversão OO-Relacional é
realizado automaticamente. No entanto existe um obstáculo para adoção dessas
duas soluções: a grande quantidade de dados armazenados em bancos
relacionais, além do elevado grau de aceitação que os SGBDs conquistaram no
mercado.
Uma solução para usar software orientado a objetos mantendo a
base relacional instalada é a criação de classes de mapeamento objetorelacional. No entanto, a criação dessas classes aumenta o trabalho de
167
codificação. Por outro lado, tem-se a opção de utilizar ferramentas que
automatizam essa tarefa, reduzindo o esforço de integração entre os dois
mundos.
Existem diversos utilitários que se propõem a realizar o
mapeamento objeto/relacional. No sistema Satika System utiliza-se o Hibernate,
um projeto Open Source e Free, desenvolvido em linguagem Java. Como
ferramenta para automação do mapeamento das tabelas foi utilizado o
MyEclipse Persistence Tools, que é capaz de criar uma unidade de persistência
e associar o projeto a base de dados. Através da engenharia reversa os
processos são totalmente personalizados. É possível escolher os artefatos para
AS
gerar tabelas do banco de dados fornecendo total suporte para o Hibernate.
Hibernate é um framework de persistência que permite a utilização
de banco de dados relacional, porém, trabalhando com objetos. Ele constitui-se
de uma biblioteca de classes Java (Hibernate.jar), que deve ser adicionada ao
IN
classpath, e é uma camada adicional entre a aplicação e o banco de dados. Seu
objetivo, e uma das principais vantagens, é eliminar a existência de instruções
SQL nas classes de negócio, atuando como uma fronteira entre as duas
tecnologias. Assim uma instrução do tipo:
IM
INSERT INTO produto (pro_tipo, pro_descricao, pro_grife, pro_cor)
VALUES("oculos escuros", "modelo aviado, sem grau", "rayban", "preto");
UN
É substituída por uma única linha:
session.save(objeto);
O Hibernate permite ainda ir mais além, com apenas essa linha
citada acima ele salva todos os relacionamentos bastando apenas configurar a
propriedade Cascade. Essa propriedade tem alguns tipos como:
All: persiste o objeto pai para todos os filhos;
None: é o default, as operações relacionadas ao objeto pai apenas
sofrerão alguma mudança nele mesmo e em mais ninguém;
Save Update: o objeto pai pode salvar ou atualizar os filhos;
Persist: Apenas para operações de salvar;
All Delete Orphan: a partir do objeto pai ele deleta os filhos;
168
Mas o framework não é uma boa opção para aplicações que fazem
uso de stored procedures e triggers. Na aplicação Satika System foi utilizado o
Hibernate, pois ele não faz uso extensivo de stored procedures nem de triggers.
A implementação da lógica de negócios da aplicação fica na própria aplicação
Java, dependendo pouco de funções específicas do banco de Dados. Assim o
Hibernate se tornou uma ferramenta muito útil.
IM
IN
AS
A figura 83 apresenta uma visão geral da arquitetura do Hibernate.
Figura 83 - Visão Geral da Arquitetura do Hibernate
Toda a configuração do Hibernate é feita através de arquivos XML,
UN
os quais contém mapeamentos de tabelas/Java, detalhes de pooling de
conexões.
Combinados,
estes arquivos
fornecem
flexibilidade
de
total
configuração da aplicação.
Na l dois componentes se sobressaem: Hibernate.properties e XML
Mapping.
O
Hibernate.properties,
também
chamado
de
Hibernate.cfg
(nomenclatura utilizada na aplicação), é o arquivo que contém as informações
sobre a conexão com o banco de dados. Nele é definido o tipo do banco, o
dialect,o driver, a URL, o usuário e a senha. O Hibernate suporta os bancos de
dados Oracle, DB2, MySQL, PostgreSQL, Sybase, SAP DB, HypersonicSQL,
Microsoft SQL Server, Progress, Mckoi SQL, Pointbase e Interbase. Como visto
anteriormente a aplicação Satika System utilizará o banco de dados MySQL.
169
Para facilitar o processo de configuração do arquivo Hibernate.properties foram
fornecidos modelos que foram customizados pelo desenvolvedor. Abaixo é
possível visualizar na figura 84 o arquivo Hibernate.cfg utilizado pela aplicação
Satika System. Nele é possível verificar a tag <session-factory> que delimita as
configurações para a sessão. Dentro dela existem as tags <property> cujos
atributos definem as configurações com o banco de dados e <mapping
resource> que definem os arquivos mapeados. Todas essas informações ficam
UN
IM
IN
AS
dentro da tag <Hibernate-configuration>.
Figura 84 - Arquivo Hibernate.cfg
No XML Mapping são registradas as informações a respeito do
mapeamento das classes feitas pelo MyEclipse Persistence Tools e suas
respectivas tabelas relacionais. Cada classe é mapeada para uma tabela. Além
170
disso, são registradas informações sobre os relacionamentos, cardinalidade e
identificadores, entre outras.
Para melhor organização dos arquivos da aplicação, foi criada uma
pasta denominada mapping e dentro dela existem todos os arquivos de
mapeamento .xml: Compra.hbm.xml, Endereço.hbm.xml, Fornecedor.hbm.xml,
ItemCompra.hbm.xml, ItemVenda.hbm.xml, Pessoa.hbm.xml, Produto.hbm.xml,
Receituario.hbm.xml e Venda.hbm.xml.
O arquivo de mapeamento é definido como um arquivo XML que
descreve as propriedades e os relacionamentos de uma classe para o Hibernate.
É uma boa prática usar um arquivo de mapeamento para cada classe, e usar
AS
como extensão do arquivo “.hbm.xml” para diferenciar de outros arquivos XML
utilizados na aplicação.
Para exemplificar como foram mapeados os arquivos descritos
anteriormente, são utilizadas as classes Produto, ItemCompra, Compra,
UN
IM
IN
Fornecedor e Endereço. Na figura 85 é possível visualizar essas classes.
UN
IM
IN
AS
171
.
Figura 85 - Parte do diagrama de Classes Satika System
172
A classe Produto associa-se a um ou mais itens de compra
(ItemCompra), uma vez que para se ter um Produto é preciso comprá-lo. Uma
Compra é caracterizada por ter um ou mais itens de compra (ItemCompra). As
compras (zero ou mais) são feitas de um ou mais fornecedores. Um Fornecedor
tem um Endereço.
O primeiro mapeamento abordado é o da classe Fornecedor e do
seu relacionamento com a classe Endereço. Na modelagem descrita, um
Fornecedor tem apenas um Endereço e um mesmo Endereço é de apenas um
Fornecedor.
Vejamos
o
mapeamento
para
a
classe
Fornecedor
(Fornecedor.hbm.xml) mostrado na figura 86.
AS
Todo e qualquer arquivo de mapeamento deve declarar no
cabeçalho do XML o Hibernate-mapping-3.0.dtd, pois ele garante a integridade
do mapeamento. Logo depois vem o nó raiz <Hibernate-mapping>, e em seguida
o nó <class>.
IN
No nó <class> é definida a classe que está sendo mapeada e para
qual tabela ela vai ser mapeada. O único atributo obrigatório deste nó é “name”,
que deve conter o nome completo da classe.
Dando continuidade tem-se o nó <id> que é o identificador dessa
IM
classe no banco de dados. No Hibernate toda classe persistente deve ter o
atributo id, que será utilizado para garantir a integridade dos objetos. Neste nó é
definida a propriedade que guarda o identificador do objeto no atributo “name”,
que no caso do sistema desenvolvido é “for_cod”. Também é definido o atributo
UN
<generator> que guarda a informação de como os identificadores(as chaves do
banco de dados) são gerados; existem diversas classes de geradores, que são
definidas no atributo “class” do nó, no presente caso o gerador usado é o
“native”, que escolhe dentre os tipos de geradores identity, sequence e hilo,
dependendo das capacidades do SGBD.
Os próximos nós do arquivo são os <property> que indicam
propriedades simples da classe. Neste nó os atributos mais importantes são
“name”, que define o nome da propriedade, “column” para definir o nome da
coluna na tabela e “type” para definir o tipo do objeto que a propriedade guarda.
Normalmente, o próprio Hibernate é capaz de descobrir qual é o tipo de objeto
que a propriedade guarda; ele também usa o mesmo nome da propriedade para
acessar a coluna, se o atributo não tiver sido preenchido.
UN
IM
IN
AS
173
Figura 86 - Arquivo fornecedor.cfg.xml
174
O último nó do arquivo, <one-to-one>, define o relacionamento de 1-para-1 que
a classe Fornecedor tem com a classe Endereço. Este nó tem os atributos
“name”, que define o nome da propriedade no objeto (neste caso, “Endereco”),
“type” que define a classe da propriedade e “cascade” que define como o
Hibernate deve “cascatear” as ações feitas nesta classe para a classe
relacionada, como atualizações, inserções e exclusões de registro. Nesse caso o
“cascade” foi escolhido como “save-update” para que quando uma classe
pessoa for inserida ou atualizada no banco, a propriedade “endereco” também
UN
IM
IN
AS
seja inserida ou atualizada.
UN
IM
IN
AS
175
Figura 87 - Arquivo Endereco.cfg.xml
Com isso, é finalizado o mapeamento da classe Fornecedor, mas
este mapeamento faz referência a uma outra classe que o Hibernate ainda não
conhece, a classe Endereço. Na figura 87 tem-se o mapeamento dessa classe
(o arquivo “Endereco.hbm.xml”).
A classe Endereco está relacionada com a classe Pessoa sendo
que uma ou mais pessoas podem ter um mesmo endereço. Por isso para
caracterizar esse relacionamento é definido o nó <one-to-many>.
Nas figuras: figura 88, figura 89 e figura 90 descreve-se o
mapeamento das classes Compra, ItemCompra e Produto, sendo mostrados os
176
arquivos
Compra.cfg.xml,
ItemCompra.cfg.xml
e
UN
IM
IN
AS
respectivamente:
Figura 88 - Arquivo Compra.cfg.xml
produto.cfg.xml,
IM
IN
AS
177
Figura 89 - Arquivo ItemCompra.cfg.xml
Há uma diferença no mapeamento da tabela ItemCompra em
relação ao mapeamento das outras tabelas. O que ocorre é que a tabela
UN
Compra identifica a tabela ItemCompra com o atributo “com_cod”. Isso significa
que uma Compra não pode ter dois ItemCompra iguais. Essa especificação foi
mapeada no identificador da classe definindo-se um novo nó <key-property>
onde foi mapeado a atributo “com_cod”.
UN
IM
IN
AS
178
Figura 90 - Arquivo Produto.cfg.xml
5.5.1 Mecanismo de persistência do Hibernate
Uma vez que o Hibernate possui im mecanismo de persistência
transparente - e as classes são alheias à sua própria capacidade de
persistência – é possível escrever lógica de aplicativo que seja alheia
dos objetos sobre os quais ela opera ao representar o estado persistente
ou o estado temporário que só existe e, memória. (BAUER; KING, 2005,
p.150)
179
Para o Hibernate, existem três tipos de objetos: objetos “transient”
(transientes), “detached” (desligados) e “persistent” (persistentes). Objetos
“transient” são aqueles que ainda não têm uma representação no banco de
dados (ou que foram excluídos). Eles ainda não estão sobre o controle do
framework e podem não ser mais referenciáveis a qualquer momento, como
qualquer objeto normal em Java. Objetos “detached” têm uma representação no
banco de dados, mas não fazem mais parte de uma sessão do Hibernate, o que
significa que o seu estado pode não estar mais sincronizado com o banco de
dados. Objetos “persistent” são os objetos que têm uma representação no banco
de dados e que ainda fazem parte de uma transação do Hibernate, garantindo
AS
assim que o seu estado esteja sincronizado com o banco de dados (nem sempre
claro).
A aplicação não precisa se preocupar se um objeto é persistente
ao invocar os seus métodos, mas deve interagir com a camada de persistência
IN
sempre que precisar propagar o estado do objeto contido na memória para o
banco de dados e vice-versa.
No Hibernate, existem os conceitos de sessão e transação. Uma
sessão é uma conexão aberta com o banco de dados, onde se pode executar
IM
consultas, inserir, atualizar e deletar objetos. Já a transação é a demarcação das
ações; uma transação faz o controle do que acontece e pode fazer um rollback
se forem encontrados problemas.
Para utilizar esses mecanismos é feita uma autenticação de acordo
UN
com o arquivo de configuração Hibernate.cfg (nome de usuário, senha, URL de
conexão, etc). Assim é criada a classe HibernateUtility.java para configurar e
abrir as sessões do Hibernate.
A classe possui um bloco estático que instancia um objeto de
configuração do Hibernate. Esse chama o método configure() que lê o arquivo
Hibernate.cfg.xml e depois que ele está configurado, cria uma SessionFactory,
que é a classe que vai ficar responsável por abrir as sessões de trabalho do
Hibernate. Se ele não lançou nenhuma exceção, então o ambiente está
configurado corretamente. Depois que a SessionFactory é inicializada, o método
getSession() retorna uma nova sessão para o código dentro do main(). Após a
sessão ter sido retornada, é iniciada uma transação, na qual o objeto em
questão é instanciado e, depois de realizadas as devidas instruções, é chamado
180
o método save() na sessão. Após o método save(), a transação é finalizada e a
sessão fechada.
O
código
de
toda
a
aplicações
mostrará
esse
mesmo
comportamento, ou seja, abrir a sessão, iniciar a transação, chamar os métodos
save(), update(), get(), delete(), etc, fechar a transação e a sessão.
Uma parte muito importante do funcionamento do framework são
as pesquisas. Existem três meios de se fazer buscas usando o Hibernate:
Hibernate Query Language (HQL), Criteria Query API (para montar buscas
programaticamente) e usando SQL puro. Na aplicação Satika System foi
utilizado apenas o SQL puro.
AS
Na figura 91 abaixo é mostrado parte da classe PessoaDAO onde
é possível visualizar um exemplo de como foram feitas as pesquisas na
aplicação. Ela descreve a pesquisa de todos os clientes da Satika Óptica, ou
UN
IM
IN
seja de todas as pessoas do tipo cliente que estejam ativas na aplicação.
IN
AS
181
Figura 91 - Pesquisa para encontrar todos os clientes
IM
Para desenvolver a camada de persistência foi preciso entender
bem suas interfaces de programação. O Hibernate possui algumas interfaces
importantes que executam CRUD´s básicos dos aplicativos e incluem sessão,
transação e consulta:
UN
Interface de sessão (Session): principal interface do Hibernate;
de peso leve e mais fácil de criar e destruir. O objeto Session ajudará na
aplicação porque há uma grande necessidade de se criar e destruir objetos
Session a todo instante. A Session é chamada de gerenciador de persistência
porque é também a interface para operações relacionadas com persistência
como armazenar e obter dados.
Interface SessionFactory: a interface SessionFactory não é
considerada peso leve, sendo compartilhada entre muitas threads do aplicativo.
Para a SessionFactory há um único aplicativo, criado na inicialização. Esta
interface controla dados armazenados e que foram lidos em uma unidade de
trabalho, podendo ser reutilizados em uma unidade futura. Geralmente a
182
SessionFactory armazena instruções SQL (Structured Query Language) e outros
metadados que são executados em tempo de execução.
Interface de Transação: é uma API (Application Programming
Interface) opcional do Hibernate; permite controlar os limites das transações
usando uma API consistente e, com isso, tornam-se portáveis os aplicativos do
Hibernate em diferentes ambientes de execução.
Interfaces de Consulta e critérios: usada para executar consultas
no banco de dados. As consultas são “escritas” em SQL, para ligar parâmetros
de consultas e limitar o número de resultados devolvidos pela consulta.
Existem também as interfaces Configuration chamadas pelo código
AS
de infra-estrutura da aplicação para configurar o Hibernate:
Interface de Configuração: é a primeira a ser encontrada quando
Hibernate é usado. Essa interface é muito importante porque depois de
5.6
IN
configurada, o Hibernate vai criar o SessionFactory.
Padrão de persistência DAO(Data Access object)
Um dos designs patterns mais populares é o Data Access Object
IM
(DAO). Ele é utilizadado para persistência de objetos, ou seja, utilizado para
gravar, recuperar, alterar e excluir objetos separando o código de apresentação
do código para acesso aos dados da aplicação e das rotinas de negócio de tal
modo que os objetos de negócio não saibam como estão sendo gravados.
UN
O padrão DAO possui como objetivo abstrair as complexidades de
acesso a banco de dados e facilitar a migração de bases de dados e como
vantagens destacam-se:
Transparência: os objetos podem utilizar a base de dados sem
saber detalhes específicos de sua implementação, isto porque todo o detalhe de
implementação está encapsulado ns objetos DAO.
Facilidade de Migração: a camada DAO permite que a aplicação
possa variar de fabricante de banco de dados de forma facilitada, isto porque
toda mudança a ser feita está centralizada da camada DAO
Centralização de Acesso a Dados: Como toda operação de
acesso a dados está delegada aos DAOs, essa camada separa, isola, o restante
183
da aplicação das implementações de acesso a dados. Essa centralização torna
a aplicação mais fácil de ser mantida e gerenciada.
Para todas as classes da aplicação Satika System foi criada uma
classe DAO abstrata onde ficam todas as operações de persistência genéricas.
E para cada classe da aplicação que possui operações específicas foi criado um
DAO correspondente à classe que herda dados da classe DAO genérica.
UN
IM
IN
AS
Na figura 92 é possível visualizar a classe DAO da aplicação.
UN
IM
IN
AS
184
Figura 92 - Pesquisa para encontrar todos os clientes
185
A classe DAO possui os métodos responsáveis pelas operações de
persistência: saveOrUpdate, delete, find e findAll. Para cada método a sessão
(session) é recuperada com ajuda da classe HibernateUtility mostrada na figura
UN
IM
IN
AS
93.
UN
IM
IN
AS
186
Figura 93 - Classe HibernateUtility da aplicação Satika System
187
Depois, a sessão é usada para iniciar uma transação, persistir o
objeto
no banco de dados e, por último, commitar a transação. A sessão é iniciada
sempre que o método getCurrentSession é invocado e terminado atráves de um
commit ou rollback.
Para as situações específicas onde são necessárias operações de
persistência específicas para cada classe foram criados DAOs específicos da
classe que são listados abaixo:
Classe EndereçoDAO: Esta classe possui o método Endereco
findAllId que é responsável por listar todos os endereços através do recebimento
UN
IM
IN
AS
de um id. Na figura 94 é possível verificar o código desta classe.
Figura 94 - Classe EnderecoDAO
188
Classe FornecedorDAO: Esta classe possui o método List
findAllCnpj que é responsável por listar todos os fornecedores através do
recebimento de um cnpj. O método List findAllRazao responsável por listar todos
os fornecedores através do recebimento de uma razão social e o método List
findAllId responsável por listar todos os fornecedores através do recebimento de
UN
IM
IN
AS
um id. Na figura 95 é possível verificar o código desta classe.
Figura 95 - Classe FornecedorDAO
189
Classe PessoaDAO: Esta classe possui os métodos que
encontram pessoas através do CPF, Nome, Id, de médicos por id, CPF e nome e
os funcionários por CPF, nome e Id. Nas figura 96 figura 97 é possível verificar o
UN
IM
IN
AS
código desta classe.
Figura 96 - Classe PessoaDAO parte 1
UN
IM
IN
AS
190
Figura 97 - Classe PessoaDAO parte 2
191
As classes Produto, Receituário, Venda, ItemVenda, Compra e
ItemCompra não possuem implementação específica.
As
classes
Endereço,
Fornecedor
e
Pessoa
UN
IM
IN
AS
características da classe abstrata DAO.
herdam
as
192
6 ARQUITETURA E CÓDIGO
O desenvolvimento de software pode ser descrito como a
elaboração e de um sistema computacional, atendendo a necessidade de um
cliente ou empresa http://pt.wikipedia.org/wiki/Desenvolvimento_de_software cite_note-0#cite_note-0. Pode também se entendido como a aplicação dos
processos da engenharia de software combinados com a pesquisa das
necessidades do produto e do cliente para desenvolver software.
O desenvolvimento de software orientado a objetos não é uma
tarefa trivial, pois requer experiências que são adquiridas através de práticas e
AS
de estudos.
O software produzido foi o Satika System, uma aplicação Web
específica para a empresa Satika Óptica e Design, tendo como principal objetivo
atender as necessidades exatas do cliente adotando a metodologia já utilizada
IN
na empresa, ou seja, o software irá se adaptar à empresa e não o contrário.
O Satika System foi implementado na linguagem JAVA, utilizando a
plataforma Java Enterprise Edition (JEE) e os frameworks Struts e Hibernate.
JEE
IM
6.1
A plataforma JEE foi criada para simplificar problemas complexos
de aplicações multi-camadas baseadas em web, tornando possível projetar,
UN
desenvolver, empacotar e implantar a aplicação baseada em componentes. No
caso do Satika System é a tecnologia de componentes Enterprise Java Beans
(EJB).
A plataforma oferece um modelo multi-camada distribuído com a
possibilidade de reutilização de componentes, transferência de dados feita em
XML, um modelo de segurança unificado e um flexível controle transacional.
JEE não é um produto, trata-se de uma especificação padrão e
aberta baseada na linguagem JAVA. O fato de ser uma especificação aberta,
possibilita o desenvolvimento sem vínculo com fornecedores. Para explicitar
melhor, pode-se criar um único arquivo para toda uma aplicação e em qualquer
plataforma como por exemplo, Windows, Linux, etc.
Assim os desenvolvedores podem escrever o código Java que é
193
compilado em bytecode, um código intermediário entre o código fonte e a
linguagem de máquina. Quando o código está pronto para rodar, uma máquina
virtual Java (JRE - Java Runtime Environment) interpreta esse bytecode e
executa a aplicação. Seus componentes JEE são transformados em bytecode e
executados pela JRE. Os containers descritos anteriormente são tipicamente
escritos em Java.
A aplicação JEE é hospedada em um container, o qual provê
serviços necessários, como transações, segurança, e serviços de persistência. A
6.2
AS
camada de negócio age como um processador dos dados de negócio.
Struts
Dentre os frameworks disponíveis para desenvolvimento de
aplicações web utilizando a linguagem Java o que se destaca é o Struts, devido
IN
principalmente aos recursos oferecidos, a sua simplicidade e a grande facilidade
de aprendizado, uma vez que existem muitos materiais disponíveis na internet e
em livros. Outras vantagens relevantes é que o Struts possui código aberto e
gratuito.
Struts
oferece
IM
O
um
componente
controlador
chamado
ActionServlet para controlar o fluxo e navegação da aplicação. Esse controlador
é auxiliado por outros componentes tais como Action, ActionForm e
ActionForward entre outros para acessar dados, vindos das requisições HTTP
UN
ou do banco de dados. Oferece também os componentes necessários para
implementação dessa camada de controle e o integra com outras tecnologias
como os JavaBeans que é utilizado na camada de modelo para gerenciar os
dados da aplicação e as Java Server Pages ou JSP usadas na camada de visão
para manipulação e inserção de dados.
Outra característica é que disponibiliza bibliotecas de tags para
apresentação, captação e manipulação de dados nas páginas JSP, bem como
frameworks que facilitam as tarefas de implementação, como validação de
dados e criação de layout das páginas.
Além dos componentes citados acima, o Struts utiliza vários
arquivos
de
configurações
como
struts-config.xml
que
armazena
as
194
configurações padrões para os objetos do controlador que inclui as ações do
usuário, as alterações de estado, as consultas de estado etc.
No desenvolvimento da aplicação além dos conhecimentos básicos
em em Struts foi necessário aprender conceitos envolvendo componentes,
arquivos de configuração, bibliotecas de tags etc.
O
Struts
é
composto
por
pacotes
tais
como
org.apache.struts.action, org.apache.struts.config, org.apache.struts.titles etc, e
esses pacotes são compostos por componentes e frameworks com funções
específicas em cada camada da aplicação.
A aplicação Satika System é dividida nas seguintes camadas:
negócio e camada de apresentação.
AS
camada de integração, também conhecida por camada de dados, camada de
O framework Struts pertence a camada de apresentação de dados,
e no entanto, como já visto anteriormente fornece componentes para
IN
implementação do controle da aplicação. O framework Struts não contepla
tecnologias para acesso a dados e implementação do negócio. A seguir serão
abordados os componentes responsáveis pelo controle da aplicação Satika
System:
IM
Action Servlet: O componente do pacote org.apache.struts.action
é a Implementação do padrão de projeto FrontController. É o controlador do
Struts e com o auxilio de outros componentes implementa a camada de controle.
Ele centraliza todas as requisições e as respostas em um único ponto. Para
UN
atender a requisições o ActionServlet é auxiliado por vários componentes como
Action, ActionForm, ActionForward e ActionMapping, tendo como base o
Struts.config.]
No anexo X é possível visualizar o StrutsConfig da aplicação Satika
System.
Action: Tem como finalidade fazer a ligação entre as requisições e
a lógica do negócio. Uma classe de ação é uma classe que estende a classe
Action e faz a ligação com a camada de modelo, responsável por buscar, inserir,
alterar e excluir dados.
O Action também é mapeado no Struts.Config.
Na figura 98 é possível verificar uma classe de ação, a classe
Action.Login é responsável pelo controle de acesso ao sistema Satika System.
195
package satika.action;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
AS
import satika.delegate.Delegate;
import satika.form.FormLogin;
public class ActionLogin extends Action {
public ActionLogin() {
IN
}
@Override
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response) throws Exception {
FormLogin frm = (FormLogin)form;
IM
Delegate delegate = new Delegate();
int retorno = delegate.login(frm);
if(retorno == -2){
request.setAttribute("user","Usuário Inválido");
return mapping.findForward("index");
UN
}
else{
if(retorno == -1){
request.setAttribute("senha","Senha
Inválida");
return mapping.findForward("index");
}
else{
request.getSession().setAttribute("func",frm.getUsuario());
request.getSession().setAttribute("funcId", retorno);
return mapping.findForward("adm");
}
}
}}
Figura 98 - Classe Action.Login
196
A classe Action.Login apresenta o código que executa uma ação e
retorna um ActionForward, que guarda o caminho de uma página JSP, para que
o ActionServlet apresente-a como resposta a uma requisição. Dependendo do
retorno recebido pelo delegate é que será decidido qual página será chamada:
Se o retorno for -2, é apresentada uma mensagem de “Usuário Inválido” e é
mostarda a página inicial (Index). Se o retorno for -1, é apresentada uma
mensagem de “Senha Inválida” e também é mostarda a página inicial (Index).
Caso contrário está tudo correto e a página do administrador é chamada.
O componente ActionForm é responsável por recolher e validar os
AS
dados contidos em um formulário, nesse caso o FormLogin. Após receber os
dados o FormLogin consulta o Delegate que consulta as informações na camada
de modelo com a finalidade de verificar se estão corretos.
UN
IM
IN
Na figura 99 é mostrado o código do FormLogin em questão:
197
package satika.form;
import javax.servlet.http.HttpServletRequest;
import org.apache.struts.action.ActionErrors;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionMapping;
public class FormLogin extends ActionForm {
private static final long serialVersionUID = 1L;
private String usuario;
private String senha;
public String getSenha()
{return senha;}
AS
public FormLogin() {}
public void setSenha(String senha)
IN
{this.senha = senha;}
public String getUsuario()
{return usuario;}
public void setUsuario(String usuario)
IM
{this.usuario = usuario;}
@Override
public void reset(ActionMapping arg0, HttpServletRequest arg1) {
UN
this.usuario = "";
this.senha = "";
}
@Override
public
ActionErrors
validate(ActionMapping
HttpServletRequest arg1) {
return super.validate(arg0, arg1);
}
}
Figura 99 - Código do FormLogin
arg0,
198
Quando o formulário LoginForm for submetido para fazer a
captação dos dados é necessária a criação da classe Java que estende a classe
ActionForm, no caso a FormLogin. Na classe FormLogin são criados os atributos
get e set correspondentes aos campos do formulário.
Todos os componentes citados trabalharão juntos dando suporte a
implementação da camada de controle. Assim cada requisição HTTP é
direcionada para o ActionServlet que aciona outros componentes para auxilia-lo
na apresentação da resposta a essa requisição. Quando o ActionServlet recebe
uma requisição, ele aciona o componente Action para acessar a classe na
camada modelo através do Delegate. Assim o Action aciona o componente
AS
ActionForm para fazer o recolhimento dos dados que serão inseridos no modelo.
O Action tem como retorno um ActionForward. O componente ActionForward é o
componente responsável por guardar o caminho de uma página JSP, que será
repassado ao ActionServlet para que ele apresente-a como resposta. Todos
IN
esses processos são definidos no arquivo de configuração struts-config.xml,
dentro da tag action-Mappings.
Quando o ActionServlet recebe uma requisição, ele consulta o
ActionMapping para saber quais os passos a serem seguidos para atender a
IM
essa requisição.
Os componentes do modelo têm como finalidade manter o estado
da aplicação. Para acessar e mudar os objetos da camada modelo, o Struts faz
o uso das tecnologias para promover o acesso aos dados. Como descrito no
UN
capítulo de Persistência a aplicação Satika System utiliza o framework Hibernate
para essa finalidade.
Para desenvolver a camada de apresentação o Struts usa o JSP e
oferece as bibliotecas de tags contidas no pacote org.apache.struts.taglib. Essas
tecnologias e componentes dão suporte a criação de interfaces gráficas da
aplicação web Satika System aplicação, bem como a captação e apresentação
dos dados inseridos pelo usuário.
A configuração dos componentes do Struts é feita em arquivos
XML. Os arquivos de configuração são: web.xml, struts-config.xml, além destes
também existem outros opcionais, para caso seja necessário utilizar alguns
componentes ou framework adicionais como: framework Tiles, que é usado para
a construção de layout em páginas JSP facilitando a implementação e
199
diminuindo a complexidade e Hibernate usado para acesso a dados.
Como visto anteriormente o Struts faz parte da camada de
apresentação e não disponibiliza tecnologias para implementação de negócio e
de acasso a dados. Para suprir essa necessidade além da utilização do
Hiberante como framework para acesso a dados foram utilizados padrões de
Projetos, tais como Business Object (BO) para negócio e Data Acces Object
(DAO) para acesso a banco de dados. Além desses, o Struts representa outros
através de seus componentes com o Action Servlet que é a implementação do
padrão FrontController.
O BO (Business Object) é a camada responsável por montar a
AS
regra de negócio e fazer o acesso e atualização do banco, cuida para que os
dados estejam todos preenchidos corretamente.
O DAO (Data Acces Object) é um padrão para persistência de
dados que permite separar regras de negócio das regras de acesso a banco de
IN
dados. O DAO deve buscar os dados do banco e converter em objetos para ser
usado pela aplicação provendo pontos unificados de acesso a dados, isto é,
conhece como pegar os objetos, converter em instruções SQL e mandar para o
banco de dados. Temos um DAO para cada objeto do domínio do sistema,
UN
IM
conforme demonstrado na figura 100 abaixo.
Figura 100 - Classes DAO
200
Ao por exemplo fazer uma solicitação através de um form. A
solicitação é enviada para o Action que consulta um delegate. Depois passa pelo
BO em seguida pelo DAO chegando à base onde a consulta é feita e é retornado
pelo mesmo caminho sendo finalmente apresentada em outro form. Os mapping
do Hibernate têm a função de gerenciar e separar a parte de negócio da parte de
UN
IM
IN
AS
acesso a banco.
201
7 CONCLUSÃO
Para a construção do sistema foram cumpridas várias etapas para
se chegar a um produto final com qualidade. A primeira etapa foi a etapa de
análise, desde o início do projeto sofreu melhoramentos contínuos. Com o
passar das fases foram identificadas melhorias nos processos e na forma que os
estes poderiam melhorar o sistema, os diagramas de caso de uso, de seqüência,
de classes de projeto foram alterados para melhor atender a especificação do
cliente. A evolução da fase de análise é importante e também é um processo
AS
natural para que se obtenha um produto final de qualidade.
A escolha de uma ferramenta de análise buscou a melhor opção
que atendesse de forma objetiva a construção de diagramas UML. Foi utilizada
para isso a ferramenta de Enterprise Architect para documentação, visualização
IN
e especificação das funcionalidades do sistema.
A forma de interação do sistema com o usuário foi estudada para
possibilitar que o sistema ajude o usuário em suas ações diárias para agregar
uma ferramenta prática para o usuário, foram implementados JSP, CSS e para
IM
aperfeiçoamentos futuros pode-se migrar para a tecnologia AJAX ou Microsoft
SilverLigh que apresenta uma nova experiência para o usuário do sistema em
sua interação com o sistema.
A integração dos aspectos logísticos e administrativo-financeiros
UN
num único software foi uma solução viável para que a empresa Satika Óptica e
Design pudesse melhorar e otimizar seu negócio.
Em virtude disso foi desenvolvido o projeto que resultou em uma
aplicação Web específica para atender todas as necessidades de negócio da
Empresa Satika Óptica e Design o Satika System. Através dele foram
automatizados cadastros, compras e vendas e a visualização de alguns
relatórios gerencias.
Uma informatização pode ser considerada eficiente quando
implementa melhoria da qualidade de funcionamento da empresa à situação que
existia antes do uso da informática. A eficiência fundamenta-se em dados
confiáveis e gera como efeito agilidade na recuperação de dados e diminuição
dos custos. A otimização dos processos da empresa ajudaram muito no que diz
202
respeito a consistência e uniformidade das informações nas três unidades da
empresa.
A aplicação Satika System produz informação que tem de ser
preservada para uso futuro. Como tal, existem mecanismos que possibilitam o
armazenamento dessas informações garantindo assim persistência, e é preciso
estudar tanto as opções quanto os casos em que elas serão implementadas,
enumerando as diferenças entre os diversos tipos de abordagens e analisando a
sua melhor aplicação.
Foi importante compreender alguns desses mecanismos e
principalmente adquirir o conhecimento necessário para escolher entre eles o
Estes
mecanismos
evitam
AS
que mais se adaptava e traria mais benefícios a aplicação Satika System.
a
complexidade
intrínseca
à
implementação do mecanismo de persistência por parte dos programadores. A
linguagem Java suporta intrinsecamente a persistência através de entre outras
IN
ferramentas do Hibernate que foi o framework escolhido para implementação.
Utilizando o Hibernate juntamente com o padrão do projeto DAO foi
possível implementar satisfatoriamente toda a camada de persistência da
aplicação Satika System.
IM
Com dedicação, foi possível aprender e dominar essas ferramentas
realizando um salto na qualidade, facilidade e manutenção da aplicação.
Todo o processo de desenvolvimento do sistema levou em
consideração
vários
aspectos
de
segurança
(protegendo
o
ambiente
UN
computacional contra as perdas repentinas ou por deterioração gradativa do
sistema), agilidade, tempo, custo e viabilidade. Além de aspectos da dinâmica
operacional e o perfil dos recursos humanos que manipulariam a aplicação, uma
vez que quanto mais integrado um software ao seu meio, maior será a sua
aceitação. Programas que não abordam adequadamente estes aspectos têm
mais probabilidade de ser abandonados pelas dificuldades em utilizá-los como
instrumento de aperfeiçoamento dos trabalhos diários.
A
implementação
desse
Software
favorece
a
automação,
contribuindo assim para o aumento da eficiência dos processos produtivos,
resultando em maior lucratividade e qualidade da empresa Satika System.
203
REFERÊNCIAS BIBLIOGRÁFICAS
ARAÚJO, A. AllFusion ERwin Data Modeler. 2007. Disponível em:
<http://www.devmedia.com.br/articles/viewcomp.asp?comp=1802>. Acesso em: 01
maio 2008.
BANCO de Dados: Definições., 2008. Disponível em:
<http://pt.wikipedia.org/wiki/Banco_de_dados >. Acesso em: 20 maio 2008.
AS
BASHAM, B.; SIERRA, K.; BATES, B.; Use a cabela! Servlets & JSP. Rio de
Janeiro: Alta books LTDA., 2005. 534 p.
BAUER C; KING G. Hibernate em Ação. Rio de Janeiro: Editora Ciência Moderna
Ltda., 2005
IN
BEZERRA, E. Princípios de análise e projeto de sistemas com uml. 9. ed. São
Paulo: Campus, 2002. 17p. 45p.
IM
COMO informatizar. 2006. Apresenta a importância de informatizar uma empresa.
Disponível em:< http://www.softgran.com.br/art01.pdf>. Acesso em: 25 jun. 2008.
UN
COSTA, A. Quem tem medo do optometrista?. São Paulo, 07 feb. 2008.
Disponível em
<HTTP://WWW.CROOSP.ORG.BR/WORK/CRONICA/INDEX1.HTML> Acesso em
22 de abr. de 2008.
HAY D.C. Princípio de Modelagem de dados. Tradução de M. C. Ribeiro. Prefácio
de R. Barker. São Paulo: Makron Books, 1999.
HUSTED, T.; DUMOULIN, C.; FRANCISCUS, G.; WINTERFELDT, D.; Struts em
ação. Rio de Janeiro:Ciência Moderna LTDA.,2004. 604 p.
MELO, R.N; SILVA, S.D. da; TANAKA, A.K. Banco de dados em aplicações
cliente – servidor: distribuição de processamento, fundamentos de banco de
dados, banco de dados distribuídos e banco de dados heterogêneos. Rio de Janeiro:
Infobook, 1997.
204
NIELSEN, J.; Projetando websites. Tradução de Ana Gibson. Rio de Janeiro:
Elsevier,2000. 416 p.
PORQUE MYSQL, 2008. Disponível em:
<http://www.mysqlbrasil.com.br/?q=node/2>. Acesso em: 30 abr. 2008.
SANCHES, A.R. Disciplina:Fundamentos de Armazenamento e Manipulação de
Dados bancos. 2005. Disponível em: <
http://www.ime.usp.br/~andrers/aulas/bd2005-1/aula3.html >. Acesso em: 10 maio
2008.
AS
SILBERSCHATZ A.; KORTH, H.F.; SUDARSHAN, S. Sistema de Banco de Dados.
3. ed. São Paulo: Pearson Makron Books, 1999.
IN
W3C DEVELOPS Web Standards and Guidelines. 2008. Disponível em <
http://www.w3.org/Consortium/>. Acesso em 13 de Jun. de 2008.
UN
IM
WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientados a
objetos. Rio de Janeiro: Campus, 2004. 253p
205
APÊNDICE A – Código menu.jsp:
Segue o código completo para Menu.jsp.
/***********************************************
* AnyLink Vertical Menu- © Dynamic Drive (www.dynamicdrive.com)
* This notice MUST stay intact for legal use
* Visit http://www.dynamicdrive.com/ for full source code
AS
***********************************************/
//Contents for menu 1
var menuCliente=new Array()
IN
menuCliente[0]='<a href="./cadastroCli.jsp">Cadastro</a>'
menuCliente[1]='<a href="./atualizaBusCli.jsp">Atualizacao</a>'
menuCliente[2]='<a href="./excluiBusCli.jsp">Exclusao</a>'
menuCliente[3]='<a href="./pesquisaCli.jsp">Pesquisa</a>'
IM
menuCliente[4]='<a href="./receituario.jsp">Receituario</a>'
//Contents for menu 2, and so on
UN
var menuMedico=new Array()
menuMedico[0]='<a href="./cadastroMed.jsp">Cadastro</a>'
menuMedico[1]='<a href="./atualizaBusMed.jsp">Atualizacao</a>'
menuMedico[2]='<a href="./excluiBusMed.jsp">Exclusao</a>'
menuMedico[3]='<a href="./pesquisaMed.jsp">Pesquisa</a>'
//Contents for menu 3, and so on
var menuFornecedor=new Array()
menuFornecedor[0]='<a href="./cadastroFor.jsp">Cadastro</a>'
menuFornecedor[1]='<a href="./atualizaBusFor.jsp">Atualizacao</a>'
206
menuFornecedor[2]='<a href="./excluiBusFor.jsp">Exclusao</a>'
menuFornecedor[3]='<a href="./pesquisaFor.jsp">Pesquisa</a>'
//Contents for menu 4, and so on
var menuFuncionario=new Array()
menuFuncionario[0]='<a href="./cadastroFun.jsp">Cadastro</a>'
menuFuncionario[1]='<a href="./atualizaBusFun.jsp">Atualizacao</a>'
menuFuncionario[2]='<a href="./excluiBusFun.jsp">Exclusao</a>'
AS
menuFuncionario[3]='<a href="./pesquisaFun.jsp">Pesquisa</a>'
var disappeardelay=250 //menu disappear speed onMouseout (in miliseconds)
/////No further editting needed
var ie4=document.all
IN
var horizontaloffset=2 //horizontal offset of menu from default location. (0-5 is a good value)
if (ie4||ns6)
IM
var ns6=document.getElementById&&!document.all
document.write('<div id="dropmenudiv" style="visibility:hidden;width: 160px"
UN
onMouseover="clearhidemenu()" onMouseout="dynamichide(event)"></div>')
function getposOffset(what, offsettype){
var totaloffset=(offsettype=="left")? what.offsetLeft : what.offsetTop;
var parentEl=what.offsetParent;
while (parentEl!=null){
totaloffset=(offsettype=="left")? totaloffset+parentEl.offsetLeft : totaloffset+parentEl.offsetTop;
parentEl=parentEl.offsetParent;
}
return totaloffset;
207
}
function showhide(obj, e, visible, hidden, menuwidth){
if (ie4||ns6)
dropmenuobj.style.left=dropmenuobj.style.top=-500
dropmenuobj.widthobj=dropmenuobj.style
dropmenuobj.widthobj.width=menuwidth
if (e.type=="click" && obj.visibility==hidden || e.type=="mouseover")
AS
obj.visibility=visible
else if (e.type=="click")
obj.visibility=hidden
function iecompattest(){
IN
}
return (document.compatMode && document.compatMode!="BackCompat")?
}
IM
document.documentElement : document.body
function clearbrowseredge(obj, whichedge){
UN
var edgeoffset=0
if (whichedge=="rightedge"){
var windowedge=ie4 && !window.opera? iecompattest().scrollLeft+iecompattest().clientWidth-15 :
window.pageXOffset+window.innerWidth-15
dropmenuobj.contentmeasure=dropmenuobj.offsetWidth
if (windowedge-dropmenuobj.x-obj.offsetWidth < dropmenuobj.contentmeasure)
edgeoffset=dropmenuobj.contentmeasure+obj.offsetWidth
}
else{
var topedge=ie4 && !window.opera? iecompattest().scrollTop : window.pageYOffset
208
var windowedge=ie4 && !window.opera? iecompattest().scrollTop+iecompattest().clientHeight-15 :
window.pageYOffset+window.innerHeight-18
dropmenuobj.contentmeasure=dropmenuobj.offsetHeight
if (windowedge-dropmenuobj.y < dropmenuobj.contentmeasure){ //move menu up?
edgeoffset=dropmenuobj.contentmeasure-obj.offsetHeight
if ((dropmenuobj.y-topedge)<dropmenuobj.contentmeasure) //up no good either? (position at top of
viewable window then)
edgeoffset=dropmenuobj.y
}
AS
}
return edgeoffset
function populatemenu(what){
if (ie4||ns6)
IN
}
dropmenuobj.innerHTML=what.join("")
IM
}
function dropdownmenu(obj, e, menucontents, menuwidth){
UN
if (window.event) event.cancelBubble=true
else if (e.stopPropagation) e.stopPropagation()
clearhidemenu()
dropmenuobj=document.getElementById? document.getElementById("dropmenudiv") : dropmenudiv
populatemenu(menucontents)
if (ie4||ns6){
showhide(dropmenuobj.style, e, "visible", "hidden", menuwidth)
dropmenuobj.x=getposOffset(obj, "left")
dropmenuobj.y=getposOffset(obj, "top")
209
dropmenuobj.style.left=dropmenuobj.x-clearbrowseredge(obj,
"rightedge")+obj.offsetWidth+horizontaloffset+"px"
dropmenuobj.style.top=dropmenuobj.y-clearbrowseredge(obj, "bottomedge")+"px"
}
return clickreturnvalue()
}
function clickreturnvalue(){
AS
if (ie4||ns6) return false
else return true
function contains_ns6(a, b) {
while (b.parentNode)
if ((b = b.parentNode) == a)
return false;
}
IM
return true;
IN
}
UN
function dynamichide(e){
if (ie4&&!dropmenuobj.contains(e.toElement))
delayhidemenu()
else if (ns6&&e.currentTarget!= e.relatedTarget&& !contains_ns6(e.currentTarget, e.relatedTarget))
delayhidemenu()
}
function hidemenu(e){
if (typeof dropmenuobj!="undefined"){
if (ie4||ns6)
210
dropmenuobj.style.visibility="hidden"
}
}
function delayhidemenu(){
if (ie4||ns6)
delayhide=setTimeout("hidemenu()",disappeardelay)
}
AS
function clearhidemenu(){
if (typeof delayhide!="undefined")
clearTimeout(delayhide)
function radioCheck(){
var a;
IN
}
IM
for (a=0;a<document.atualiza.radio.length;a++){
if (document.atualiza.radio[a].checked){
document.atualiza.id.value = document.atualiza.radio[a].value
};
UN
};
};
function PopUp(u, w, h){
// t = (screen.width - w) / 2;
t = 100;
l = (screen.height - h) / 2;
window.open(u, 'wpopup', 'top=' + t + ', left=' + l + ', width=' + w + ', height=' + h + ', scrollbars=yes,
resizable=no, menubar=no, location=no, status=no, toolbar=no');
}
211
function carrega(){
window.opener.document.receituario.cpf1.value = document.viu.cpf.value;
window.opener.document.receituario.cpf.value = document.viu.id.value;
window.close();
}
function carregaM(){
window.opener.document.receituario.medico1.value = document.vil.cpf.value;
AS
window.opener.document.receituario.medico.value = document.vil.id.value;
window.close();
function carregaV(){
IN
}
window.opener.document.venda.cpf1.value = document.viu.cpf.value;
window.opener.document.venda.cliente.value = document.viu.id.value;
UN
}
IM
window.close();
212
APÊNDICE B – Código index.jsp
Segue o código completo para Index.jsp.
<%@ page contentType="text/html; charset=utf-8" language="java"
errorPage=""%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
AS
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
IN
<title>Sátika Ótica e Design</title>
<link href="css/css_index.css" rel="stylesheet" type="text/css" />
<script type="text/javascript" language="JavaScript" src="js/login.js"></script>
IM
</head>
<body class="oneColFixCtrHdr">
<div id="container">
UN
<div id="header">
<img src="imagens/cabecalho_index.jpg"/>
</div>
<div id="mainContent">
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<center>
<form name="login" action="login.do" method="post">
<table width=225 border=1 bgcolor="gray" cellpadding=3 >
<tr>
<td colspan=2 height="13">
213
<center>
<p>
<font face="Arial Black" style="font-size: 14pt;">
Õ rea restrita:
</font>
</p>
</center>
</td>
<tr>
AS
</tr>
<td height="30">
<p align="right"/>
<font face="Verdana" style="font-size: 10pt; bafont-weight:700">
</font>
<p align="right"/>
IM
<br/>
IN
<img border="0" src="imagens/user.gif" width="80" height="80" align="left"/>
<font face="Verdana" style="font-size: 10pt; font-weight:700">
<br/>
Usuário:
UN
</font>
</td>
<td height="30" align="center">
<input type="text" name="usuario" size="20" maxlength="20"/><font style="font-size: 12px; color:
red;"><br />${user }</font>
</td>
</tr>
<tr>
<td height="30">
<p align="right"/>
214
<font style="font-size: 10pt"
face="Verdana">
<b>
<img border="0" src="imagens/senha.gif" align="left" width="80" height="80"/>
<br/>
<br/>
Senha
</b>:
</font>
AS
</td>
<td height="30">
<input type="password" name="senha" size="20" maxlength="10"/><font style="font-size: 12px; color:
red;"><br />${senha }</font>
IN
</td>
</tr>
<tr>
IM
<td colspan=2 align=center height="26">
UN
<input type="submit" value="Efetuar Login"/>
</td>
</tr>
</table>
</form>
</center>
<p/>
<p align="center" style="margin-top: 0; margin-bottom: 0">
</p>
<br/>
<br/>
<br/>
<br/>
<br/>
</div> </body>
</html>
<br/>
</div>
215
APÊNDICE C – Código css_index.css
Segue o código completo para css_index.css.
@charset "utf-8";
body {
font: 100% Verdana, Arial, Helvetica, sans-serif;
background: #666666;
for differing browser defaults */
padding: 0;
AS
margin: 0; /* it's good practice to zero the margin and padding of the body element to account
text-align: center; /* this centers the container in IE 5* browsers. The text is then set to the left
color: #000000;
}
.oneColFixCtrHdr #container {
IN
aligned default in the #container selector */
IM
width: 800px; /* using 20px less than a full 800px width allows for browser chrome and avoids
a horizontal scroll bar */
background: #FFF000;
margin: 0 auto; /* the auto margins (in conjunction with a width) center the page */
UN
border: 1px solid #000000;
text-align: left; /* this overrides the text-align: center on the body element. */
border-width: 1px;
border-color: black;
}
.oneColFixCtrHdr #header {
background: black;
padding: 0 10px 0 0px; /* this padding matches the left alignment of the elements in the divs
that appear beneath it. If an image is used in the #header instead of text, you may want to remove the
padding. */
216
height: 101px;
}
.oneColFixCtrHdr #header h1 {
margin: 0; /* zeroing the margin of the last element in the #header div will avoid margin
collapse - an unexplainable space between divs. If the div has a border around it, this is not necessary
as that also avoids the margin collapse */
padding: 10px 0; /* using padding instead of margin will allow you to keep the element away
from the edges of the div */
}
AS
.oneColFixCtrHdr #mainContent {
padding: 0 20px; /* remember that padding is the space inside the div box and margin is the
space outside the div box */
background: gray;
UN
IM
IN
}
217
APÊNDICE D – Código css_int.css
Segue o código completo para css_int.css.
@charset "utf-8";
body {
font: 100% Verdana, Arial, Helvetica, sans-serif;
AS
background: #666666;
margin: 0; /* it's good practice to zero the margin and padding of the body element to account
for differing browser defaults */
padding: 0;
IN
text-align: center; /* this centers the container in IE 5* browsers. The text is then set to the left
aligned default in the #container selector */
color: #000000;
}
IM
.twoColFixLtHdr #container {
width: 800px; /* using 20px less than a full 800px width allows for browser chrome and avoids
a horizontal scroll bar */
height: 800px;
UN
background: #FFFFFF;
margin: 0 auto; /* the auto margins (in conjunction with a width) center the page */
border: 1px solid #000000;
text-align: left; /* this overrides the text-align: center on the body element. */
border-width: 1px;
border-color: black;
}
.twoColFixLtHdr #header {
background: #000000;
218
padding: 0 0px 0 0px; /* this padding matches the left alignment of the elements in the divs
that appear beneath it. If an image is used in the #header instead of text, you may want to remove the
padding. */
position: relative;
height: 101px;
}
.twoColFixLtHdr #header h1 {
margin: 0; /* zeroing the margin of the last element in the #header div will avoid margin
as that also avoids the margin collapse */
AS
collapse - an unexplainable space between divs. If the div has a border around it, this is not necessary
padding: 0px 0; /* using padding instead of margin will allow you to keep the element away
from the edges of the div */
.twoColFixLtHdr #sidebar1 {
IN
}
float: left; /* since this element is floated, a width must be given */
width: 177px; /* the actual width of this div, in standards-compliant browsers, or standards
IM
mode in Internet Explorer will include the padding and border in addition to the width */
background: #FFFFFF; /* the background color will be displayed for the length of the content
in the column, but no further */
padding: 15px 10px 15px 20px;
UN
position: relative;
}
.twoColFixLtHdr #mainContent {
margin: 0 0 0 150px; /* the left margin on this div element creates the column down the left
side of the page - no matter how much content the sidebar1 div contains, the column space will
remain. You can remove this margin if you want the #mainContent div's text to fill the #sidebar1 space
when the content in #sidebar1 ends. */
padding: 0 20px; /* remember that padding is the space inside the div box and margin is the
space outside the div box */
}
219
.fltrt { /* this class can be used to float an element right in your page. The floated element must
precede the element it should be next to on the page. */
float: right;
margin-left: 8px;
}
.fltlft { /* this class can be used to float an element left in your page */
float: left;
margin-right: 8px;
}
AS
.clearfloat { /* this class should be placed on a div or break element and should be the final element
before the close of a container that should fully contain a float */
clear:both;
font-size: 1px;
line-height: 0px;
UN
IM
}
IN
height:0;
220
APÊNDICE E – Código menu.css
Segue o código completo para menu.css.
#dropmenudiv{
position:absolute;
background-color: white;
AS
border:1px solid black;
border-bottom-width: 0;
font:normal 12px Verdana;
line-height:18px;
}
width: 100%;
display: block;
IM
#dropmenudiv a{
IN
z-index:100;
text-indent: 1px;
border-bottom: 1px solid black;
UN
padding: 1px 0;
text-decoration: underline;
font-weight: bolder;
color: black;
}
#dropmenudiv a:hover{ /*hover background color*/
background-color: gray;
}
221
/* Sample CSS definition for the example list. Remove if desired */
.navlist li {
list-style-type: square;
width: 135px;
background-color: #FFFFB9;
}
#dropmenudiv a:VISITED {
color: black;
UN
IM
IN
AS
}
222
APÊNDICE F – Código sdmenu.css
Segue o código completo para sdmenu.css.
div.sdmenu {
width: 150px;
font-family: Arial, sans-serif;
AS
font-size: 12px;
padding-bottom: 10px;
background: url("../imagens/bottom.gif") no-repeat right bottom;
color: #fff;
div.sdmenu div {
IN
}
background: url("../imagens/title.gif") repeat-x;
}
IM
overflow: hidden;
div.sdmenu div:first-child {
background: url("../imagens/toptitle.gif") no-repeat;
}
UN
div.sdmenu div.collapsed {
height: 25px;
}
div.sdmenu div span {
display: block;
padding: 5px 25px;
font-weight: bold;
color: white;
background: url("../imagens/expanded.gif") no-repeat 10px center;
cursor: default;
223
border-bottom: 1px solid #ddd;
}
div.sdmenu div.collapsed span {
background-image: url("../imagens/collapsed.gif");
}
div.sdmenu div a {
padding: 5px 10px;
background: #eee;
border-bottom: 1px solid #ddd;
color: #066;
}
background : #fff;
}
div.sdmenu div a:hover {
IN
div.sdmenu div a.current {
AS
display: block;
IM
background : black url("../imagens/linkarrow.gif") no-repeat right center;
color: #fff;
text-decoration: none;
UN
}