UNIMINAS DESENVOLVIMENTO DO SISTEMA DE GERENCIAMENTO DA SATIKA ÓPTICA ARIANE GRACIELE SANTOS SOUZA IRON MARTIM FERREIRA JÚNIOR LUCIANA CAMPOS CARMO

Transcrição

1 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 DESENVOLVIMENTO DO SISTEMA DE GERENCIAMENTO DA SATIKA ÓPTICA ARIANE GRACIELE SANTOS SOUZA IRON MARTIM FERREIRA JÚNIOR LUCIANA CAMPOS CARMO Uberlândia 2008

2 ARIANE GRACIELE SANTOS SOUZA IRON MARTIM FERREIRA JÚNIOR LUCIANA CAMPOS CARMO DESENVOLVIMENTO DO SISTEMA DE GERENCIAMENTO DA SATIKA ÓPTICA Trabalho de Final de curso submetido à como parte dos requisitos para a obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof. Msc. Silvio Bacalá Júnior Uberlândia 2008

3 ARIANE GRACIELE SANTOS SOUZA IRON MARTIM FERREIRA JÚNIOR LUCIANA CAMPOS CARMO Banca Examinadora: DESENVOLVIMENTO DO SISTEMA DE GERENCIAMENTO DA SATIKA ÓPTICA Trabalho de Final de curso submetido à como parte dos requisitos para a obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof. M. Sc. Silvio Bacalá Junior Uberlândia, 17 de julho de Prof. Carlos Henrique Barros Prof. Dra. Kátia Lopes Silva Prof. M. Sc. Sílvio Bacalá Uberlândia 2008

4 A nossa família pelo costumeiro apoio e aos nossos amigos.

5 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 e compreensão em nossas ausências.

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

7 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 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 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 used by the company administrator to identify points of improvement in their business.

8 LISTA DE FIGURAS Figura 1 - Loja matriz Rua Duque de Caxias Figura 2 - Loja filial Avenida Santos Dumont Figura 3 - Loja filial Avenida Raulino Cotta Pacheco Figura 4 - Diagrama de Caso de Uso Figura 5 - Diagrama de Caso de Uso Figura 6 - Diagrama de seqüência efetuar login Figura 7 - Diagrama de seqüência cadastrar cliente Figura 8 - Diagrama de seqüência cadastrar funcionário Figura 9 - Diagrama de seqüência cadastrar fornecedor Figura 10 - Diagrama de seqüência cadastrar médico Figura 11 - Diagrama de seqüência cadastrar produto Figura 12 - Diagrama de seqüência cadastrar receituário Figura 13 - Diagrama de seqüência registrar venda Figura 14 - Diagrama de seqüência registrar compra Figura 15 - Diagrama de seqüência alterar cliente Figura 16 - Diagrama de seqüência alterar funcionário Figura 17 - Diagrama de seqüência alterar fornecedor Figura 18 - Diagrama de seqüência alterar médico Figura 19 - Diagrama de seqüência alterar produto Figura 20 - Diagrama de seqüência alterar venda Figura 21 - Diagrama de seqüência alterar compra Figura 22 - Diagrama de seqüência alterar receituário Figura 23 - Diagrama de seqüência excluir cliente Figura 24 - Diagrama de seqüência excluir funcionário Figura 25 - Diagrama de seqüência excluir fornecedor Figura 26 - Diagrama de seqüência excluir médico Figura 27 - Diagrama de seqüência excluir produto Figura 28 - Diagrama de seqüência Excluir Venda Figura 29 - Diagrama de seqüência Excluir Compra Figura 30 - Diagrama de seqüência Excluir Receituário Figura 31 - Diagrama de seqüência Pesquisar Cliente Figura 32 - Diagrama de seqüência Pesquisar Funcionário Figura 33 - Diagrama de seqüência Pesquisar Fornecedor Figura 34 - Diagrama de seqüência Pesquisar Médico Figura 35 - Diagrama de seqüência Pesquisar Produto Figura 36 - Diagrama de seqüência Pesquisar Venda Figura 37 - Diagrama de seqüência Pesquisar Compra Figura 38 - Diagrama de seqüência Pesquisar Receituário Figura 39 - Diagrama de seqüência Relatório Melhores Clientes Figura 40 - Diagrama de seqüência Relatório Produtos Mais Vendidos Figura 41 - Diagrama de pacotes Figura 42 - Classe de análise pacote login Figura 43 - Diagrama de análise cliente Figura 44 - Classe de análise Funcionário Figura 45 - Classe de análise fornecedor Figura 46 - Classe de análise pacote médico Figura 47 - Classe de análise pacote produto Figura 48 - Classe de análise pacote receituário

9 Figura 49 - Classe de análise pacote venda Figura 50 - Classe de análise pacote compra Figura 51 - Classe de análise do pacote Relatório Produtos Mais Vendidos Figura 52 - Classe de análise do pacote Relatório Melhores Clientes Figura 53 - Diagrama de classes do projeto registrar venda Figura 54 - Marca empresa Satika Figura 55 - Estrutura do Satika System Figura 56 - Fragmento menu.js Figura 57 - Menu categoria Retrátil Figura 58 - Modelos de disposição de informações em um site Figura 59 - Modelo do menu do sistema Figura 60 - Arquitetura do site Figura 61 - Controle de acesso Figura 62 - Trecho da página de login Figura 63 - Diagrama de estados de navegação Figura 64 - Menu e área de resposta Figura 65 - Fotografia usada pela empresa Figura 66 - Trecho página index.jsp Figura 67 - Chamada do arquivo CSS Figura 68 - Trecho do arquivo css_index.css Figura 69 - Tela de login do sistema Figura 70 - Página IndexAdm.jsp Figura 71 - Código página indexadm.jsp Figura 72 - Trecho menu.css Figura 73 - Trecho página indexadm.jsp Figura 74 - Trecho menu.js Figura 75 - Trecho da página receituário.jsp Figura 76 - Página receituário Figura 77 - Esquema de Níveis Figura 78 - DER Satika System Figura 79 - Cardinalidade : um-para-um Figura 80 - Cardinalidade : um-para-muitos Figura 81 - Cardinalidade : muitos-para-um Figura 82 - Cardinalidade um para muitos Figura 83 - Visão Geral da Arquitetura do Hibernate Figura 84 - Arquivo Hibernate.cfg Figura 85 - Parte do diagrama de Classes Satika System Figura 86 - Arquivo fornecedor.cfg.xml Figura 87 - Arquivo Endereco.cfg.xml Figura 88 - Arquivo Compra.cfg.xml Figura 89 - Arquivo ItemCompra.cfg.xml Figura 90 - Arquivo Produto.cfg.xml Figura 91 - Pesquisa para encontrar todos os clientes Figura 92 - Pesquisa para encontrar todos os clientes Figura 93 - Classe HibernateUtility da aplicação Satika System Figura 94 - Classe EnderecoDAO Figura 95 - Classe FornecedorDAO Figura 96 - Classe PessoaDAO parte Figura 97 - Classe PessoaDAO parte Figura 98 - Classe Action.Login

10 Figura 99 - Código do FormLogin Figura Classes DAO

11 LISTA DE QUADROS Quadro 1 - Modelo de ata de reunião Quadro 2 - Requisitos funcionais e não funcionais Quadro 3 - Regras de negócios Quadro 4 - Especificação do caso de uso: efetuar login Quadro 5 - Especificação do caso de uso: cadastrar cliente Quadro 6 - Especificação do caso de uso: cadastrar receituário Quadro 7 - Especificação do caso de uso: cadastrar funcionário Quadro 8 - Especificação do caso de uso: cadastrar fornecedor Quadro 9 - Especificação do caso de uso: cadastrar médico Quadro 10 - Especificação do caso de uso: cadastrar produto Quadro 11 - Especificação do caso de uso: registrar compra Quadro 12 - Especificação do caso de uso: registrar venda Quadro 13 - Especificação do caso de uso: excluir cliente Quadro 14 - Especificação do caso de uso: excluir fornecedor Quadro 15 - Especificação do caso de uso: excluir funcionário Quadro 16 - Especificação do caso de uso: excluir médico Quadro 17 - Especificação do caso de uso: excluir produto Quadro 18 - Especificação do caso de uso: excluir registro de venda Quadro 19 - Especificação do caso de uso: excluir registro de compra Quadro 20 - Especificação do caso de uso: excluir receituário Quadro 21 - Especificação do caso de uso: pesquisar cliente Quadro 22 - Especificação do caso de uso: pesquisar fornecedor Quadro 23 - Especificação do caso de uso: pesquisar funcionário Quadro 24 - Especificação do caso de uso: pesquisar médico Quadro 25 - Especificação do caso de uso: pesquisar produto Quadro 26 - Especificação do caso de uso: pesquisar registro de venda Quadro 27 - Especificação do caso de uso: pesquisar registro de compra Quadro 28 - Especificação do caso de uso: pesquisar receituário Quadro 29 - Especificação do caso de uso: alterar dados cliente Quadro 30 - Especificação do caso de uso: alterar dados fornecedor Quadro 31 - Especificação do caso de uso: alterar dados funcionário Quadro 32 - Especificação do caso de uso: alterar dados médico Quadro 33 - Especificação do caso de uso: alterar dados produto Quadro 34 - Especificação do caso de uso: alterar venda Quadro 35 - Especificação do caso de uso: alterar compra Quadro 36 - Detalhe do caso de uso alterar receituário Quadro 37 - Detalhe do caso de uso relatório melhores clientes Quadro 38 - Detalhe do caso de uso relatórios produtos mais vendidos... 70

12 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 JSP Java Server Pages MS SQL Microsoft SQL Server OOHDM Object-Oriented Hypermedia Design Method PK Primary Key ou Chave Primária SQL - Structured Query Language ou Linguagem de Consulta Estruturada UC Use Case ou Caso de Uso UML - Unified Modeling Language ou Linguagem de Modelagem Unificada W3C World Wide Web Consortium

13 SUMÁRIO 1 INTRODUÇÃO Cenário Atual Foco no problema de gestão a ser resolvido Objetivos do Trabalho Objetivo Geral Objetivo Específico Justificativa Organização do Trabalho DESCRIÇÃO DO PROBLEMA ANÁLISE DO SISTEMA Análise de sistema utilizando a UML Diagramas de Caso de Uso Especificações dos Casos de Uso Diagramas de Seqüência Classes de Análise Classe de Fronteira Classe de Controle Classe de Entidade Classes do Projeto Classes de Projeto PROJETO DE INTERFACE Introdução Definição de interface Padrões de construção de interface Definição da interface do sistema Arquitetura da interface do sistema Design Implementação Caso de uso PERSISTÊNCIA Organização do banco de dados Sistema de informação Gerencial do Banco de Dados A escolha do MYSQL Arquitetura do banco de dados Modelagem do banco de dados Explicando o Modelo

14 5.4.2 Restrições em relacionamentos Atributos chaves Hibernate Mecanismo de persistência do Hibernate Padrão de persistência DAO(Data Access object) ARQUITETURA E CÓDIGO JEE Struts CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A Código menu.jsp: APÊNDICE B Código index.jsp APÊNDICE C Código css_index.css APÊNDICE D Código css_int.css APÊNDICE E Código menu.css APÊNDICE F Código sdmenu.css

15 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 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 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. 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 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 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 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. 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 óptico ganha completo controle sobre o negócio, podendo evitar até mesmo roubos. 1.2 Foco no problema de gestão a ser resolvido Realizou-se um estudo sobre o desenvolvimento de um sistema para 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 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 um sistema que atenderá as expectativas do cliente. 1.3 Objetivos do Trabalho Objetivo Geral Implementar um aplicativo comercial com suporte a Web para gestão de Óptica e Optometria. Desenvolver um software para gerenciar, administrar e armazenar todas as operações realizadas pela empresa 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 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 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 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. 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 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 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, 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. 1.5 Organização do Trabalho 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, 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 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 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 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 situada à R. Duque de Caxias, 146 figura 1, e duas filiais na Av. Santos Dumont, 548, figura 2 e Av. Raulino Cotta Pacheco, 242 figura 3. Figura 1 - Loja matriz Rua Duque de Caxias

21 21 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 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 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, 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 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. 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 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 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 necessidades dos usuários do sistema, ou seja, aqueles que vão trabalhar no dia-adia com este software. Para 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 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 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.

24 24 Quadro 1 - Modelo de ata de reunião 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 solicitações feitas pelo cliente desde a primeira reunião estando estas registradas no levantamento de requisitos mostrado no quadro 2.

25 25 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 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: 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 26 3 ANÁLISE DO SISTEMA 3.1 Análise de sistema utilizando a UML Entende-se como análise de sistemas, [...] 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 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). 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 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 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. É 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. 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á 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 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 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 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 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 entendimento do problema. No entanto a idéia principal do sistema foi definida nessa fase. O sistema deverá possibilitar ao usuário: cadastro de clientes, funcionários, fornecedores, médicos e receituário do cliente; alteração de dados cadastrais; maiores compras na empresa; exclusão de dados cadastrais; pesquisa de dados no sistema; emissão de relatório contendo os dados dos clientes que fizeram as 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 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 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 nessa fase foi revisto novamente para espelhar as novas informações e fornecer maior precisão aos planos; 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; 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 é, 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 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 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 do sistema. 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. 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 31 de Caso de Uso para o melhor entendimento conforme mostrado nas figura 4 e figura 5. Figura 4 - Diagrama de Caso de Uso 1

32 32 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 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 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. 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: caso de uso; 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 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 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 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. RN-08 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 Social e CNPJ. RN-20 Para realizar uma pesquisa de funcionário deverá ser informado nome ou 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 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 mesmo. RN-32 Para alterar dados da compra deverá ser feito antes uma pesquisa do mesmo. RN-33 Para alterar dados do receituário deverá ser feito antes uma pesquisa do mesmo. RN-34 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 período de venda a ser pesquisado. Quadro 3 - Regras de negócios Abaixo serão demonstrados os quadros com as especificações dos casos de uso identificados no sistema.

36 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 Efetuar Login CSU-1 Sumário Descreve as etapas para realizar o login 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. Fluxo Alternativo [ ]: Fluxo de Exceção [ 3 ]: Usuário e senha inválidos 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 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 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 Cadastrar Cliente CSU02 Sumário Descreve as etapas necessárias para cadastrar clientes. 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, , 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 a. Caso o funcionário não conclua ou desista de incluir o cadastro do cliente, o sistema volta ao passo 1. 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 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. 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. 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. 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 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 Cadastrar Funcionário CSU04 Sumário Descreve as etapas necessárias para o cadastro do funcionário 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. 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. 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 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 Cadastrar Fornecedor CSU05 Sumário 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 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, ); 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. 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 41 Nome Cadastrar Médico CSU06 Sumário Descreve as etapas necessárias para o cadastro do médico 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, , 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 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. 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 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 Cadastrar Produto CSU07 Sumário Descreve as etapas necessárias para o cadastro de produtos 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 a. Caso o funcionário não conclua ou desista de incluir o cadastro de produto, o sistema volta ao passo 1. 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 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 Registrar Compra CSU08 Sumário Descreve as etapas necessárias para registrar compra com fornecedor 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. 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 44 como, os dados solicitados. O ator só poderá registrar a venda se o cliente já for cadastrado no sistema. Nome Registrar Venda CSU09 Sumário Descreve as etapas necessárias para registrar uma venda 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. 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. 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 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 Excluir Cliente CSU10 Sumário Descreve as etapas necessárias para excluir 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: 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 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 46 como, os dados solicitados. O ator só poderá excluir um fornecedor após a pesquisa do mesmo e confirmar a exclusão. Nome Excluir Fornecedor CSU11 Sumário Descreve as etapas necessárias para excluir receituário 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. 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 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 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 Excluir Funcionário CSU12 Sumário Descreve as etapas necessárias para excluir 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: 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. 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 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 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. 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 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 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 Excluir Produto CSU14 Sumário Descreve as etapas necessárias para excluir 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: 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. 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 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 Excluir Registro de Venda CSU15 Sumário Descreve as etapas necessárias para excluir 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: 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. 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. 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 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 Excluir Registro de Compra CSU16 Sumário Descreve as etapas necessárias para excluir 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: 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. 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. 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 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 Excluir Receituário CSU17 Sumário Descreve as etapas necessárias para excluir receituário 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. 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. 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 53 Nome Pesquisar Cliente CSU18 Sumário 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, , telefone, endereço, cidade, estado, CEP)e exibe para o funcionário; Fluxo Alternativo [ ]: Fluxo de Exceção [ 1 ]: Caso CPF ou 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 1. Regras de Negócio Associadas 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 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 Pesquisar Fornecedor CSU19 Sumário 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 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, do representante, telefone da empresa, fax, endereço, cidade, estado, CEP) e exibe para o funcionário; Fluxo Alternativo [ ]: Fluxo de Exceção [ 1 ]: Caso CNPJ ou Razão Social não encontrado 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 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 Pesquisar Funcionário CSU20 Sumário 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 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; Fluxo Alternativo [ ]: Fluxo de Exceção [ 1 ]: Caso CPF ou 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 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 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 Pesquisar Médico CSU21 Sumário 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 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, , telefone, endereço, cidade, estado, CEP) e exibe para o funcionário; Fluxo Alternativo [ ]: Fluxo de Exceção [ 1 ]: Caso CPF ou nome não encontrado. 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 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 Pesquisar Produto CSU22 Sumário 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 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; Fluxo Alternativo [ ]: Fluxo de Exceção [ 1 ]: Caso tipo do produto não encontrado. 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 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 Pesquisar Registro de Venda CSU23 Sumário 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 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; Fluxo Alternativo [ ]: Fluxo de Exceção [ 1 ]: Caso data da venda não encontrada. 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 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 Pesquisar Registro de Compra CSU24 Sumário 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 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; Fluxo Alternativo [ ]: Fluxo de Exceção [ 1 ]: Caso data da compra não encontrada. 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 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 Pesquisar Receituário CSU25 Sumário 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 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; Fluxo Alternativo [ ]: 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 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 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 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, , 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. 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 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 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, ) 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 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 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 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. 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 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 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 Alterar Dados Médico CSU29 Sumário Descreve as etapas necessárias para alterar dados do médico 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, , 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. 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 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 Alterar Dados Produto CSU30 Sumário Descreve as etapas necessárias para alterar dados do 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: 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. 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 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 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. 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 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 67 Nome Alterar Compra CSU32 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. Fluxo de Exceção [ 1, 6 ]: Caso CNPJ ou razão social, ou a alteração seja feita com dados incorretos 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 68 Nome Alterar Receituário CSU33 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. 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 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 69 que mais consumiram na empresa. O funcionário pode imprimir o relatório ou apenas visualizar. Nome Relatório Melhores Clientes CSU34 Sumário Descreve as etapas necessárias para gerar relatório de clientes que mais efetuaram compras 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 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. 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. 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 - 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 70 Nome Relatório Produtos Mais Vendidos CSU35 Sumário 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 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. 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. 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. 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 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. 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). 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 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. 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 72 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 de mensagens entre eles. Figura 7 - Diagrama de seqüência cadastrar cliente

73 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 funcionário. Figura 8 - Diagrama de seqüência cadastrar funcionário

74 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 no sistema Satika. Figura 9 - Diagrama de seqüência cadastrar fornecedor

75 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 preenchidos. Figura 10 - Diagrama de seqüência cadastrar médico

76 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 para a realização do cadastro. Figura 11 - Diagrama de seqüência cadastrar produto

77 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 que não consta nenhum registro com os parâmetros informados. Figura 12 - Diagrama de seqüência cadastrar receituário

78 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 solicitados para a conclusão do registro da venda. Figura 13 - Diagrama de seqüência registrar venda

79 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 registro informando os dados solicitados, conforme a figura 14 abaixo. Figura 14 - Diagrama de seqüência registrar compra

80 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 do cliente. Figura 15 - Diagrama de seqüência alterar cliente

81 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 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 82 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 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 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 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 sistema para realizar a alteração do produto. Figura 19 - Diagrama de seqüência alterar produto

85 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 passos internos do sistema para realizar a alteração de uma venda já realizada. Figura 20 - Diagrama de seqüência alterar venda

86 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 que o funcionário desejar. Figura 21 - Diagrama de seqüência alterar compra

87 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 que o funcionário desejar. Figura 22 - Diagrama de seqüência alterar receituário

88 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 efetuar a exclusão do cadastro. Figura 23 - Diagrama de seqüência excluir cliente

89 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 de excluir cadastro. Figura 24 - Diagrama de seqüência excluir funcionário

90 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 cadastro. Figura 25 - Diagrama de seqüência excluir fornecedor

91 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 opção de excluir cadastro. Figura 26 - Diagrama de seqüência excluir médico

92 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 cadastro. Figura 27 - Diagrama de seqüência excluir produto

93 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 processo de exclusão de venda. Figura 28 - Diagrama de seqüência Excluir Venda

94 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 de compra. Figura 29 - Diagrama de seqüência Excluir Compra

95 95 A figura 30 é o diagrama de seqüência que mostra a iteração do sistema para excluir um receituário do cadastro no sistema. Figura 30 - Diagrama de seqüência Excluir Receituário

96 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 dados solicitados para a realização do mesmo e exibi-los na tela. Figura 31 - Diagrama de seqüência Pesquisar Cliente

97 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 na tela. Figura 32 - Diagrama de seqüência Pesquisar Funcionário

98 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, 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 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 exibilo na tela. Figura 34 - Diagrama de seqüência Pesquisar Médico

100 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 Satika, informando os parâmetros de pesquisa e exibi-lo na tela. Figura 35 - Diagrama de seqüência Pesquisar Produto

101 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 como os dados solicitados para a realização do mesmo e exibi-lo na tela. Figura 36 - Diagrama de seqüência Pesquisar Venda

102 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 Satika, informando os parâmetros de pesquisa e exibi-lo na tela. Figura 37 - Diagrama de seqüência Pesquisar Compra

103 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 tela. Figura 38 - Diagrama de seqüência Pesquisar Receituário

104 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 ou alguns benefícios ao cliente. Figura 39 - Diagrama de seqüência Relatório Melhores Clientes

105 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 usuário possa de alguma forma, utilizar a informação para supervisores da empresa. Figura 40 - Diagrama de seqüência Relatório Produtos Mais Vendidos

106 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 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 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 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á 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 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 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 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 desenvolvidas utilizando a tecnologia JSP (Java Server Pages), são as responsáveis em fazer a interação usuário x sistema 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 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 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 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 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 classes. Segundo Bezerra (2002), algumas responsabilidades da classe de entidade são: Informar os valores dos atributos a classe de entidade; Realizar funções simples, alguns métodos, com a ajuda de outras classes de entidade associadas através de agregações; 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.

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

110 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 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 demonstrado na figura 43. Figura 43 - Diagrama de análise cliente

112 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 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 classes que utilizam a classe Funcionário, conforme citado na figura.

113 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 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 classe Fornecedor, conforme demonstrado na figura 45. Figura 45 - Classe de análise fornecedor

115 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 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 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 tarefa. Fazem parte também do pacote médico, as classes que utilizam a classe Medico para realizar suas funções, conforme citado na figura 46.

116 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 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 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 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 classe Cliente, conforme citado na figura 48.

119 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 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, conforme demonstrado na figura 49. Figura 49 - Classe de análise pacote venda

121 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 pela Classe Compra, onde serão registradas as alterações realizadas pelo usuário na classe de fronteira. Fazem parte deste pacote as classes Fornecedor e Funcionário, conforme demonstrado na figura 50.

122 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 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 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 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 mostrado na figura 52 abaixo. Figura 52 - Classe de análise do pacote Relatório Melhores Clientes

125 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 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 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. 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. 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 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 projeto que serão descritos juntamente com as classes do sistema. Figura 53 - Diagrama de classes do projeto registrar venda

127 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. 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. 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 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. 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 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, 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 padrões que podem facilitar esta construção. 4.2 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 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 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 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 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. 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 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 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 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 Object- Oriented Hypermedia Design Method (OOHDM) utiliza padrões específicos de 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 sistemas de grande porte. Esta metodologia também não abrange 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. 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. 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 recebimento formal da proposta do projeto apresentado pela faculdade 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. 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 da empresa Satika. Figura 54 - Marca empresa Satika 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 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 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 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 55. Figura 55 - Estrutura do Satika System

133 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 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. //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>' //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 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 é o mesmo para os itens Movimentação, Relatórios e Painel. Figura 57 - Menu categoria Retrátil 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.

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

136 136 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 seria construído e verificar a existência de alguma necessidade adicional percebida após as reuniões de definição do projeto.

137 137 Figura 60 - Arquitetura do site Na fase de arquitetura do sistema estudou-se o controle de 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.

138 138 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 deste código. <center> <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 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 trabalho e dispensando treinamentos. 4.6 Design 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 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 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 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 imagem de refinamento, pode-se identificar estas características na figura 64. Figura 64 - Menu e área de resposta São considerados pontos importantes: Tipografia tipo de fonte utilizado para construção do Satika 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 submenus; 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 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, sendo assim esta imagem foi incluída no sistema afim de atender às necessidades da marca Satika, tornando o sistema ainda mais personalizado. Figura 65 - Fotografia usada pela empresa 4.7 Implementação 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 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 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 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 é 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 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 na figura 66 que apresenta um trecho da página index.jsp que é a página de login do Satika System. O código completo pode ser encontrado no Apêndice B.

143 143 page contenttype="text/html; charset=utf-8" language="java" errorpage=""%> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " transitional.dtd"> <html xmlns=" <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> <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"> 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 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. Figura 66 - Trecho página index.jsp 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 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 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 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 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> <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 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; } Sendo assim, para o desenvolvimento de uma nova interface ou 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 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 possíveis mudanças de usabilidade e permitindo a qualquer desenvolvedor que conheça as soluções aqui usadas prestar manutenção. 4.8 Caso de uso 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. primeira tela do sistema. Figura 68 - Trecho do arquivo css_index.css A figura 69 mostra tela de login do sistema índex.jsp que é a

146 146 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 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 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" " transitional.dtd"> <html xmlns=" <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> <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 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> <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 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 Movimentação, Parceiros, Relatórios e Painel como apresentado na figura 73.

149 149 <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" > 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 será utilizada pelo menu.js, que são menucliente, menufornecedor, menumedico, menufuncionário. Figura 73 - Trecho página indexadm.jsp 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 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 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 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. 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 segue um trecho da página receituário.jsp na figura 75.

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

152 152 Figura 76 - Página receituário Os botões exibidos pela página têm cantos arredondados que 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 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 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, 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 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). 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 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 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 exemplo. 5.1 Organização do banco de dados 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; 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 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 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 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 dados tais como, descrição da estrutura, relações entre os dados, etc. O dicionário conterá: a descrição externa, conceitual e interna do banco de dados; as restrições sobre os dados; o acesso aos dados; 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 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 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 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 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 é 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 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 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 acesso a dados sigilosos. 5.3 Arquitetura do banco de dados Um propósito geral do sistema de base de dados é esconder certos 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: 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 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:

158 158 Figura 77 - Esquema de Níveis 5.4 Modelagem do banco de dados [...] 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; 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 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 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 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. 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 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 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 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 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 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 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:

161 161 Figura 78 - DER Satika System Explicando o Modelo No modelo proposto apresentado na figura 78 é possível observar as seguintes entidades: Receituário, Pessoa, Endereço, Fornecedor, Compra, 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 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 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 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 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 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 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 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 expressando a cardinalidade, bem como, um exemplo da aplicação onde um fornecedor tem um endereço. 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 164 Figura 80 - Cardinalidade : um-para-muitos Se as posições de A e B forem trocadas, pode-se denominar sua cardinalidade como muitos-para-um. A figura 81,figura 80 mostra isto. Figura 81 - Cardinalidade : muitos-para-um É 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.

165 165 Figura 82 - Cardinalidade um para muitos Atributos chaves Uma tarefa importante na modelagem do banco de dados foi especificar a distinção entre entidades e relacionamentos. Para ser feita tal 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 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 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 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 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 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. 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 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 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 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: INSERT INTO produto (pro_tipo, pro_descricao, pro_grife, pro_cor) VALUES("oculos escuros", "modelo aviado, sem grau", "rayban", "preto"); É 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 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. 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, 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.