UNIMINAS SOFTWARE PARA GESTÃO COMERCIAL DE PAPELARIA ALBERTO DUMONT ALVES OLIVEIRA MARCOS ARAÚJO DA CUNHA

Transcrição

1 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 SOFTWARE PARA GESTÃO COMERCIAL DE PAPELARIA ALBERTO DUMONT ALVES OLIVEIRA MARCOS ARAÚJO DA CUNHA Uberlândia 2009

2 ALBERTO DUMONT ALVES OLIVEIRA MARCOS ARAÚJO DA CUNHA SOFTWARE PARA GESTÃO COMERCIAL DE PAPELARIA 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. Francisco J. Muller Uberlândia 2009

3 ALBERTO DUMONT ALVES OLIVEIRA MARCOS ARAÚJO DA CUNHA SOFTWARE PARA GESTÃO COMERCIAL DE PAPELARIA 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. Francisco J. Muller Banca Examinadora: Uberlândia, 08 de Julho de Prof. M.Sc. Francisco José Muller (Orientador) Profª. Drª. Kátia Lopes Silva Prof. Esp. Carlos Henrique de Barros Uberlândia 2009

4 Dedicado a todos que contribuíram direta ou indiretamente para a realização deste projeto.

5 AGRADECIMENTOS A todos os professores do curso de Sistemas de Informação da, em especial aos professores Ana Maria, Carlos Barros, Edson Angoti, Francisco Muller e Kátia Lopes, pela paciência, atenção e pelo tempo dedicado nesse projeto. As famílias, pela confiança, compreensão e motivação. Aos amigos de sala e companheiros de jornada pelo constante apoio e sem os quais também não seria possível a elaboração deste trabalho.

6 RESUMO Este trabalho tem por objetivo o desenvolvimento de um sistema de gestão comercial para a Papelaria Pirâmide, uma micro empresa situada na cidade de Uberlândia. Através de algumas reuniões com os envolvidos no projeto, pôde-se conhecer melhor o universo que compõe uma papelaria e entender as reais necessidades do cliente. Foi proposto o desenvolvimento de um software que utilize a plataforma web. Para o desenvolvimento deste, utilizaram-se os conceitos da Engenharia de Software e do paradigma de orientação a objetos. Faz parte deste trabalho o levantamento e análise de requisitos, a definição da arquitetura do software, a implementação e a abordagem relativa ao uso de tecnologias atuais como Struts, Hibernate, Java, JSPs, entre outras. A Unified Modeling Language (UML) foi fundamental para documentar o desenvolvimento do software e mostrar de maneira clara e consistente o funcionamento do sistema através de seus principais diagramas, como o diagrama de casos de uso, o diagrama de classes e o diagrama de Seqüência. O sistema de gestão comercial de papelaria (SIGECOMP) foi desenvolvido seguindo o modelo de software em três camadas. Utilizou-se o framework Struts2 para implementação do padrão Model-View-Controller (MVC). Padrões de projeto também foram aplicados. O mapeamento objeto relacional foi implementado com o uso do framework Hibernate. Este trabalho utilizou padrões e tecnologias amplamente empregados em um ambiente de desenvolvimento de software profissional. O SIGECOMP foi desenvolvido parcialmente. Foram implementados vários casos de uso, evidenciando a potencialidade desse projeto. Desta forma, este trabalho mostra que é viavel a construção de sistemas para gestão comercial por meio dos artefatos apresentados. Palavras Chave: papelaria, gestão comercial, sistema web, engenharia de software, UML, JSP, Java, JEE, MVC, Struts, padrões de projeto.

7 ABSTRACT This work aims at developing a commercial management system for Stationery Pyramid, a small company located in Uberlândia city. Through several meetings with those involved in the project, it is possible to learn more about the situation and to understand the real needs of the client. It was proposed to develop a software platform that uses the web. For developing the system, the concepts of Software Engineering and the orientation of the object paradigm were used. This work is composed by the survey and analysis of requirements, definition of software architecture, implementation and approach to the use of current technologies such as Struts, Hibernate, Java, JSP, and others. The Unified Modeling Language (UML) was critical to document the software development and shows in a clear and consistent way the system operation through its main diagrams, as the use cases diagram, classes diagram and sequence diagram. The commercial management system for stationeries (SIGECOMP) was developed based in the model of software into three layers. The framework Struts2 was used for implementation of standard Model-View- Controller (MVC). The design patterns were applied, too. The object relational mapping was implemented using the Hibernate framework. This study used standards and technologies widely applied in a development environment for professional software. The SIGECOMP was developed partially. Were implemented various use cases, highlighting the potential of this project. Thus, this work shows that it is feasible to build systems for business management through the artifacts displayed. Keywords: stationery, business management, web system, software engineering, UML, JSP, Java, JEE, MVC, Struts, design patterns.

8 LISTA DE FIGURAS Figura 1 Papelaria Pirâmide...18 Figura 2 Diagrama de casos de uso Papelaria Pirâmide...29 Figura 3 Diagrama de classes de negócio do sistema SIGECOMP...47 Figura 4 Estereótipo de uma classe de fronteira...49 Figura 5 Estereótipo de uma classe de controle Figura 6 Estereótipo de uma classe de entidade Figura 7 Diagrama de seqüência de análise do caso de uso Realizar Login Figura 8 Diagrama de seqüência de análise do caso de uso Manter Dados de Cliente...53 Figura 9 Diagrama de seqüência de análise do caso de uso Manter Dados de Funcionário...54 Figura 10 Diagrama de seqüência de análise do caso de uso Manter Dados de Fornecedor...55 Figura 11 Diagrama de seqüência de análise do caso de uso Manter Dados de Representante Figura 12 Diagrama de seqüência de análise do caso de uso Manter Dados de Produtos Figura 13 Diagrama de seqüência de análise do caso de uso Registrar Compra Figura 14 Diagrama de seqüência de análise do caso de uso Registrar Venda...59 Figura 15 Diagrama de seqüência de análise do caso de uso Manter Contas a Pagar...60 Figura 16 Diagrama de seqüência de análise do caso de uso Manter Contas a Receber...61 Figura 17 As três camadas lógicas de um software em camadas. (Adaptado de Sommerville, 2003, p. 208)...63 Figura 18 O funcionamento do padrão MVC. (Adaptado de Presman, 2006, p.443)...65 Figura 19 Framework Struts2. (Fonte: Roughley, 2006, p.11)...67 Figura 20 Enfoque em camadas. (Adaptado de Alur, Crupi e Malks, 2004, p.102)...70 Figura 21 A estrutura de uma aplicação Web. (Adaptado de Todd e Szolkowski, 2003, p.90)...72 Figura 22 Arquitetura utilizada no aplicativo SIGECOMP...73 Figura 23 Diagrama de pacotes do software SIGECOMP...75 Figura 24 Diagrama de classes de projeto do caso de uso Realizar Login Figura 25 Diagrama de classes de projeto do caso de uso Manter Dados de Funcionário...77 Figura 26 Diagrama de classes de projeto do caso de uso Manter Dados de Fornecedor...78 Figura 27 Diagrama de classes de projeto do caso de uso Manter Dados de Produto...79 Figura 28 Diagrama de sequência de projeto do caso de uso Realizar Login...81 Figura 29 Diagrama de seqüência de projeto do caso de uso Manter Dados de Funcionário Figura 30 Diagrama de seqüência de projeto do caso de uso Manter Dados de Fornecedor...83 Figura 31 Diagrama de seqüência de projeto do caso de uso Manter Dados de Produto Figura 32 Estrutura do SIGECOMP...85 Figura 33 Arquivo de configuração web.xml Figura 34 Parte do arquivo struts.xml Figura 35 Parte do código da página funcionario.jsp...88 Figura 36 Parte do código da página funcionarioform.jsp...89 Figura 37 Parte do código da classe FuncionarioAction...90 Figura 38 Outros métodos da classe FuncionarioAction Figura 39 Código da classe FuncionarioBO...92 Figura 40 Código da classe FuncionarioDAO Figura 41 Parte do código da classe FuncionarioHibernateDAO...93 Figura 42 Parte do código da classe FuncionarioHibernateDAO...94 Figura 43 Interface gráfica do caso de uso manter dados de funcionário Figura 44 Diagrama de Entidade e Relacionamento modelo lógico...98 Figura 45 Diagrama de Entidade e Relacionamento modelo físico...99 Figura 46 Arquivo xml responsável pela configuração do Hibernate Figura 47 Detalhe do mapeamento objeto relacional Figura 48 Tela inicial do sistema SIGECOMP Figura 49 Tela de login do sistema SIGECOMP Figura 50 Tela com o menu principal do sistema SIGECOMP Figura 51 Diagrama de navegabilidade do caso de uso Realizar Login...106

9 LISTA DE QUADROS Quadro 1 Atividades típicas de um processo de desenvolvimento de software...12 Quadro 2 Requisitos funcionais e não funcionais...22 Quadro 3 Regras de Negócio Quadro 4 Documento de caso de uso Realizar login...34 Quadro 5 Documento de caso de uso Manter dados de cliente...35 Quadro 6 Documento de caso de uso Manter dados de funcionário...36 Quadro 7 Documento de caso de uso Manter dados de fornecedor...37 Quadro 8 Documento de caso de uso Manter dados de representante Quadro 9 Documento de caso de uso Manter dados de produtos Quadro 10 Documento de caso de uso Consultar estoque Quadro 11 Documento de caso de uso Registrar compras Quadro 12 Documento de caso de uso Registrar vendas Quadro 13 Documento de caso de uso Manter contas a pagar...43 Quadro 14 Documento de caso de uso Manter contas a receber....44

10 LISTA DE ABREVIATURAS E SÍMBOLOS API CEP CNPJ CPF Application Programming Interface Código e Endereçamento Postal Cadastro Nacional da Pessoa Jurídica Cadastro de Pessoa Física CSS Cascading Style Sheets DAO DER EA GOF HQL HTML HTTP JDBC IDE JEE JSP MVC PDF POJO SGBD Data Access Object Diagrama Entidade-Relacionamento Enterprise Architect Gang of four Hibernate Query Language HyperText Markup Language Hypertext Transfer Protocol Java Database Connectivity Integrated Development Environment Java Enterprise Edition Java Server Pages Model-view-controller Portable Document Format Plain Old Java Object Sistema Gerenciador de Banco de Dados SIGECOMP Sistema de Gestão Comercial de Papelaria SQL UC UML XML Structured Query Language Use Case Unified Modeling Language EXtensible Markup Language

11 SUMÁRIO 1 INTRODUÇÃO CENÁRIO ATUAL O Desenvolvimento de Softwares O Apoio da Tecnologia aos Processos Comerciais IDENTIFICAÇÃO DO PROBLEMA OBJETIVOS DO TRABALHO Objetivo Geral Objetivos Específicos JUSTIFICATIVA PARA A PESQUISA ORGANIZAÇÃO DO TRABALHO ESPECIFICAÇÃO DO PROBLEMA ANÁLISE DO SISTEMA UML FERRAMENTAS CASE DIAGRAMA DE CASOS DE USO DOCUMENTOS DE CASO DE USO CLASSES DE ANÁLISE Diagrama de Classes de Análise Descriminação das classes de negócio Estereótipo das Classes DIAGRAMAS DE SEQÜÊNCIA ARQUITETURA E CÓDIGO O ENFOQUE DE CAMADAS O PADRÃO MVC SERVLETS E JAVA SERVER PAGES O FRAMEWORK STRUTS JAVA ENTERPRISE EDITION (JEE) PADRÕES DE PROJETO CONTÊINER WEB E APLICAÇÕES WEB ARQUITETURA E PROJETO DO SISTEMA SIGECOMP Diagrama de Pacotes Diagrama de Classes de Projeto Diagrama de Seqüência de Projeto Como o SIGECOMP foi Implementado PERSISTÊNCIA DE DADOS PADRÃO DE PROJETO DAO DIAGRAMA DE ENTIDADE E RELACIONAMENTO MAPEAMENTO OBJETO RELACIONAL Mapeamento Objeto Relacional utilizando JDBC Mapeamento Objeto Relacional utilizando o Hibernate PROJETO DE INTERFACE TECNOLOGIAS UTILIZADAS DIAGRAMA DE ESTADOS DE NAVEGAÇÃO CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS ANEXO A- DADOS IMPORTANTES...110

12 11 1 INTRODUÇÃO 1.1 Cenário Atual O Desenvolvimento de Softwares Pressman (2006), afirma que software é mais que um produto, é um conjunto de processos, documentações, diagramas, enfim, tudo que foi utilizado para chegar ao software, que é o produto final. Ainda segundo o autor, independente do tamanho, complexidade ou domínio de aplicação, o software evolui com o tempo. As modificações orientam esse processo de evolução, seja quando erros são corrigidos, quando o sistema é adaptado a um novo ambiente ou quando o cliente solicita novas características ou funções para a aplicação. Atualmente, a utilização de sistemas computacionais tornou-se indispensável para o desempenho de atividades nas mais diversas áreas como transporte, médica, comercial, industrial, entretenimento, entre tantas outras. Devido à importância do seu uso e ao aumento da demanda de sistemas informatizados, a comunidade de software tem continuamente tentado desenvolver tecnologias que tornem mais fácil, mais rápido e menos dispendioso construir e manter programas de computador de alta qualidade. De acordo ainda com Pressman (2006), a importância do software tem passado mudanças significativas em pouco mais de 50 anos. Dentre as varias mudanças pode-se citar o surgimento da Engenharia de Software (ES), que é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de sistemas de software aplicando tecnologias e práticas de gerência de projetos e outras metodologias. A ES surgiu em meados dos anos 70 numa tentativa de contornar a crise do software e dar um tratamento de engenharia mais sistemático e controlado, ao desenvolvimento de sistemas de software complexos, permitindo ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e

13 12 garantido suas qualidades. Além disso, ela oferece mecanismos para se planejar e gerenciar o processo de desenvolvimento. O desenvolvimento de software é uma atividade complexa. Essa complexidade corresponde à sobreposição de complexidades relativas ao desenvolvimento dos seus diversos componentes: softwares, hardware, procedimentos, etc [...] Tentativas de lidar com essa complexidade e de minimizar os problemas envolvidos no desenvolvimento de software envolvem a definição de processos de desenvolvimento de software. Um processo de desenvolvimento de software compreende todas as atividades necessárias para definir, desenvolver, testar e manter um produto de software. (Bezerra, 2002, p. 19). Existem vários processos propostos e cada um deles tem suas particularidades em relação ao modo de arranjar e encadear as atividades de desenvolvimento. Entretanto, algumas atividades são comuns à maioria dos processos existentes. Tais atividades são listadas no quadro 1 a seguir. Atividades típicas de um processo de desenvolvimento de software Atividade Levantamento de Requisitos Análise de Requisitos Projeto Implementação Testes Implantação Descrição Corresponde à etapa de compreensão do problema aplicada ao desenvolvimento do software. Usuários e desenvolvedores devem ter a mesma visão do problema a ser resolvido. É realizado um estudo detalhado dos requisitos, para então construir modelos para representar o sistema a ser desenvolvido. Nesta atividade, os requisitos são especificados e uma estratégia de solução é construída, sem se preocupar com os detalhes de tecnologias a serem utilizadas. Determina como o sistema funcionará para atender aos requisitos de acordo com os recursos tecnológicos existentes. O sistema é codificado, ou seja, ocorre a tradução da descrição computacional da fase de projeto em código executável através do uso de uma linguagem de programação. São realizadas diversas atividades de testes para verificação do sistema construído, levando-se em conta a especificação feita na análise. O sistema é empacotado, distribuído e instalado no ambiente do usuário. Os manuais do sistema são escritos e ocorre o treinamento dos usuários. Quadro 1 Atividades típicas de um processo de desenvolvimento de software As atividades de levantamento e análise de requisitos são de extrema importância para o projeto de desenvolvimento de um software. O produto dessas atividades é a base para as demais atividades, sendo que o mesmo pode sofrer

14 13 alterações no decorrer do projeto. Para documentar tais requisitos, pode-se utilizar a Linguagem de Modelagem Unificada (Unifield Modeling Language UML). Na atividade de Projeto é definida a arquitetura a ser utilizada. De acordo com Booch, Rumbaugh e Jacobson (2000), a arquitetura de software não está apenas relacionada à estrutura e ao comportamento, mas também a uma série de validações, que irão mostrar se o projeto é viável ou não. São exemplos de validações: a funcionalidade, a questão do desempenho, a reutilização e restrições como a de caráter econômico e tecnológico. De posse dos requisitos e com a arquitetura já definida, o sistema é codificado na atividade de implementação, através de uma linguagem de programação. As duas atividades finais abordam a questão de testes, qualidade de software e a entrega do produto final. Tecnologias e práticas fazem parte da Engenharia de Software, objetivando organização, produtividade e qualidade. Tais artefatos englobam linguagens de programação, banco de dados, ferramentas, plataformas, bibliotecas, padrões, metodologias, processos e a questão da qualidade de software O Apoio da Tecnologia aos Processos Comerciais A tecnologia da informação oferece inúmeros recursos para auxiliar nos processos das empresas para que as mesmas alcancem competitividade e, com isso, o aumento de lucros. Até bem pouco tempo os investimentos em tecnologia eram quase sempre de alto custo. O cenário, no entanto, vem mudando, pois agora existem disponíveis no mercado sistemas de gestão inovadores e de custo mais acessível. Fazendo uso da tecnologia, os empresários conseguem aumentar a produtividade, cortar custos, simplificar a gestão e até vender mais. Afinal, na velocidade em que o mundo anda hoje, é preciso ser um empreendedor high tech, estar conectado o tempo todo e economizar minutos, pois eles significam produtividade e dinheiro. Maia (2007), afirma que o uso de computadores, softwares, leitores de código de barra e tantos outros aparatos tecnológicos deixaram de ser um diferencial competitivo para se transformar em um kit de sobrevivência. O fato de não investir em tecnologia pode deixar uma empresa quilômetros atrás de seu

15 14 concorrente. Atualmente as micro, pequenas e medias empresas conquistam um espaço cada vez maior na preferência dos consumidores. Ao irem às compras, os consumidores percebem que, na maioria dos casos, essas empresas dispõem dos mesmos produtos e atrativos que os grandes estabelecimentos. De acordo com Torres (2006), outro ponto a favor dos pequenos varejos é o fato de que 62% da população se dirige a pé aos locais de compra. Uma empresa, seja ela pequena ou de grande porte, precisa gerenciar seus processos internos. Com o decorrer do tempo tornou-se inviável uma boa gerência destes processos sem a ajuda de um software. Em se tratando de software de gestão comercial para papelarias, em Uberlândia e região, é possível encontrar desde o mais simples software de prateleira até uma solução sofisticada e/ou personalizada. Os softwares de prateleira são facilmente encontrados e possuem um preço acessível, visto que, uma vez produzido, este software é vendido em larga escala. No entanto, boa parte destes, não oferecem garantias de atualização, treinamento, implantação ou suporte técnico. Existe ainda, a possibilidade de comprar ou alugar um sistema completo de gestão comercial. Em Uberlândia, essa é uma prática comum. Estes softwares atendem não só as papelarias, mas vários outros setores do comércio, como padarias, lojas de autopeças, entre outros. Ao adquirir este tipo de software, muitas das vezes é necessário que alguns processos da empresa se adaptem ao software. Além disso, pode ocorrer da empresa adquirir um software que talvez não seja ideal para o seu tipo de negócio. No geral, um sistema de gestão comercial de papelarias deve prover: Controle de compras e vendas. Controle de Estoque. Controle de Clientes. Controle de Fornecedores. Controle de Funcionários. Financeiro (Contas a receber, a pagar e fluxo de caixa). Emissão e leitura do código de barras do produto. Consulta de estoques e consultas diversas. Consulta e atualização do cadastro de clientes. Permite pagamentos em diversas formas. Vendedores (cadastro completo dos vendedores).

16 15 Unidade de venda. Ex: kit, peça, metro, cm, pacote. Em sua maioria, os sistemas para gestão comercial para papelarias aqui pesquisados, são aplicações desktop, desenvolvidos em Pascal, com ferramenta Delphi, utilizando banco de dados gratuitos como Firebird e MySql. Não se encontrou um software que utilize a plataforma web. Desta forma, caso uma papelaria necessite de um software mais especifico, que atenda suas necessidades, torna-se necessário o desenvolvimento de um aplicativo personalizado. Nesse caso, o software é desenvolvido especialmente para o cliente em particular. 1.2 Identificação do problema O problema em questão se resume em como realizar um projeto para o desenvolvimento de um sistema web para gestão comercial de papelaria, que armazene as transações comerciais e que possibilite a geração de informações relevantes para a empresa. Para o desenvolvimento deste projeto serão utilizados os conceitos da Engenharia de Software e do paradigma de orientação a objetos. 1.3 Objetivos do trabalho Objetivo Geral Desenvolver um sistema web para gestão comercial de papelaria com base nos conceitos da Engenharia de Software e do paradigma de orientação a objetos Objetivos Específicos Levantar e Analisar os requisitos do sistema. Documentar os requisitos utilizando a UML. Utilizar uma ferramenta CASE para o desenvolvimento da análise e projeto orientados a objetos. Utilizar o padrão Model-View-Controller (MVC). Implementar o aplicativo utilizando a linguagem Java.

17 16 Utilizar os padrões de projeto Java Enterprise Edition (JEE). Utilizar o framework Struts2 para a camada de apresentação. Utilizar framework Hibernate3 para persistência dos dados. Utilizar banco de dados MySql. 1.4 Justificativa para a pesquisa A construção de um software, seguindo os conceitos da ES, envolve diversos profissionais e até mesmo equipes, cada qual responsável por determinada função; tem-se uma equipe para análise, outra responsável pela arquitetura e assim sucessivamente. Mesmo assim é necessário possuir uma visão global dos processos que envolvem o desenvolvimento de um aplicativo. De acordo com Freire (1999), a teoria implica numa inserção na realidade, num contato analítico com o existente, para comprová-lo, plenamente e praticamente. Seguindo essa premissa, este projeto se apóia na aplicação dos conceitos e utilização das boas práticas no desenvolvimento de sistemas, contribuindo com a validação dos conceitos, através da pratica. A relevância da pesquisa, em seus aspectos profissionais e científicos, sustenta-se na necessidade de um estudo mais profundo de como desenvolver um software profissionalmente e utilizando linguagens atuais, passando pelas diversas etapas, como visitas ao cliente, análise dos requisitos, planejamento, desenvolvimento, armazenamento de dados, entre tantas outras. A percepção da empresa parceira em utilizar a plataforma web, contribuiu para o projeto, que aborda o uso de tecnologias atuais como Struts, Hibernate, Java, Java Server Pages, entre outras. Este projeto poderá servir como objeto de estudo para futuras pesquisas acadêmicas e científicas. 1.5 Organização do Trabalho Este trabalho é organizado como se segue: O capítulo 2 descreve o problema a ser abordado. Ainda neste capítulo serão apresentados os requisitos levantados nas reuniões com o cliente e as regras de negocio.

18 17 O capítulo 3 aborda a parte de análise. O uso da UML foi fundamental para essa pesquisa e neste capítulo são abordados os principais diagramas dessa linguagem. O capítulo 4 é dedicado à arquitetura e código do sistema. Nele constam todas as tecnologias, padrões de projetos e metodologias utilizadas para a implementação do software. Neste tópico também são apresentados os digramas de classe e de seqüência a nível de projeto, além do diagrama de pacotes. Um caso de uso foi utilizado para mostrar como o sistema foi desenvolvido e como foram contruidas as diversas classes que compõem o aplicativo. No capítulo 5, é feita uma síntese das tecnologias utilizadas para o mapeamento objeto relacional e a persistência dos dados. O capitulo 6 faz uma breve introdução relativa ao projeto de interface, mostrando algumas telas do sistema e o que foi utilizado para implementálas. Por fim, o capitulo 7 apresenta as conclusões obtidas com o desenvolvimento da pesquisa. Neste último capítulo também são apresentadas sugestões para continuidade deste trabalho.

19 18 2 ESPECIFICAÇÃO DO PROBLEMA A empresa parceira, a Papelaria Pirâmide (Figura 1) é uma micro empresa que atua no ramo de papelarias na cidade de Uberlândia-MG. Fundada em 1999, oferece produtos para clientes do segmento corporativo (empresas, escritórios, escolas), universitário e estudantes em geral. Atualmente, a empresa já possui a maioria de seus processos informatizados através do uso de um software de gestão comercial. Na visão do proprietário da empresa, existe a necessidade das informações estarem disponíveis a todo o momento, inclusive fora do ambiente da loja. Além disso, pretende-se expandir os negócios futuramente, através da implantação de um e-commerce. Figura 1 Papelaria Pirâmide Deseja-se através do novo sistema gerenciar os processos do estabelecimento, como os diversos cadastros e o controle de compra e venda de

20 19 mercadorias, uma vez que o sistema atual não satisfaz os requisitos necessários. O sistema deve permitir o login do usuário, controle de clientes, de funcionários, de fornecedores e representantes, de estoque, dos produtos, o controle de compras e vendas e ainda o controle de contas a pagar e contas a receber. Levando-se em conta as necessidades do cliente, foi proposto o Sistema de Gestão Comercial de Papelaria (SIGECOMP), voltado para a plataforma web, de maneira que o usuário possa utilizá-lo independente de instalação em uma máquina local e que possibilite a expansão futura desse sistema, de acordo com as necessidades da empresa. Para o detalhamento do projeto, foi de fundamental importância a aplicação da atividade de levantamento de requisitos da Engenharia de Software, pois através dela é possibilitado que usuários e desenvolvedores tenham a mesma visão do problema a ser resolvido. Durante o levantamento de requisitos, a equipe procurou entender o domínio do negócio, no caso o setor de papelarias. Nesta fase do projeto, foram realizadas reuniões com os envolvidos (stackholders). Na primeira reunião, o escopo do projeto foi definido e foram compartilhados alguns processos de negócio da empresa. Nas reuniões seguintes, a documentação de requisitos foi apresentada ao proprietário da empresa, para validações e modificações necessárias, afinal quando se trata do desenvolvimento de um sistema, as dúvidas e divergências devem ser tratadas nessa etapa, afim de não restarem duvidas acerca do que deve ser implementado e evitar problemas futuros. A seguir, são descritos os principais processos da Papelaria Pirâmide voltado a: Funcionários Apesar de ser uma empresa familiar, em determinadas épocas, como o período de volta às aulas, surge a necessidade de ampliar o número de funcionários. Uma vez cadastrado, os dados desse funcionário podem ser consultados, alterados ou excluídos. Os dados relevantes para a empresa são os documentos de identificação (CPF, RG, N Carteira de Trabalho, PIS), data de entrada e saída da empresa, nome do funcionário, contato (telefones e ) e endereço completo. Os dados obrigatórios para o cadastro são CPF, RG, N Carteira de Trabalho, nome completo e data de entrada na empresa.

21 20 Clientes Ao cliente, pessoa física ou jurídica é permitido o cadastro na loja. Uma vez cadastrado, os dados desse cliente podem ser consultados, alterados ou excluídos. Os dados relevantes para a empresa são os documentos de identificação (CPF, RG, CNPJ, IE), nome do cliente, contatos (telefones e ) e endereço completo. Os dados obrigatórios para o cadastro são o nome e documento (CPF ou CNPJ). Fornecedores e Representantes A empresa mantém o cadastro dos fornecedores. O fornecedor pode possuir representantes locais, que são os contatos com o fornecedor. Uma vez cadastrado, os dados do fornecedor e representante podem ser consultados, alterados ou excluídos. Os dados relevantes para fornecedor são os documentos de identificação (CNPJ, IE), nome fantasia e razão social, contato (telefones e ) e endereço completo. Os dados obrigatórios para o cadastro de fornecedor são os documentos de identificação (CNPJ e IE), nome fantasia e razão social. Os dados relevantes para representante são o nome, os telefones de contato e endereço de . Produtos Ao receber uma nota fiscal de compras, a empresa realiza o cadastro dos novos produtos adquiridos e uma vez cadastrado pode-se realizar consultas, alterações ou exclusões. A empresa faz uso de uma leitora de código de barras para agilizar esse processo, pois a grande maioria dos produtos já possui esse código na embalagem. Os dados relevantes para a empresa são: código de barras, descrição, tipo de apresentação (refere-se à embalagem, se é pacote, caixa, etc), referência (fornecida pelo fabricante), marca, quantidade em estoque, quantidade de estoque mínima e quantidade de estoque máxima, prazo de validade (existem produtos perecíveis como tintas diversas), preço de custo e preço de venda. Os dados obrigatórios para o cadastro são descrição, tipo de apresentação, marca, estoque mínimo e estoque máximo, preço de custo e preço de venda. Processos de compra É feita uma lista de produtos a serem adquiridos, o pedido é realizado junto ao fornecedor, seja por telefone, fax ou visita do representante. Dependendo do

22 21 fornecedor, a mercadoria pode demorar menos de um dia para ser entregue. Ao chegar, as mercadorias são separadas, os produtos novos são cadastrados, é feito o lançamento da compra, através da nota fiscal. O estoque é atualizado. Dependendo da forma de pagamento, o valor da compra é lançado no contas a pagar. Uma compra pode ser feita à vista ou a prazo. Processos de venda O cliente é atendido pelo vendedor (esse processo é realizado na loja, por telefone, fax ou ), as mercadorias são separadas, é feito o lançamento da venda. O estoque é atualizado. Dependendo da forma de pagamento, o valor da venda é lançado no contas a receber. Uma venda pode ser feita à vista (pagamento em moeda, cheque ou cartão de débito) ou a prazo (parcelamento cartão de crédito, cheque pré-datado ou crediário próprio para clientes pessoa jurídica). Ao lançar a venda, é obrigatório relacionar um funcionário, um cliente e no mínimo um produto (item da venda). Caso o cliente não seja cadastrado e o mesmo não queira realizar o cadastro naquele momento, a venda deve ser concluída de toda forma. Nesses casos o cliente é lançado como consumidor. Estoque O estoque é atualizado conforme um compra ou uma venda é realizada. Consultas ao estoque são realizadas para que não faltem produtos na loja. Contas a Pagar Contas a pagar podem ser lançadas, consultadas, alteradas ou excluídas. As contas também podem ser lançadas automaticamente no caso de compra realizada a prazo. Contas a Receber Contas a receber podem ser lançadas, consultadas, alteradas ou excluídas. As contas também podem ser lançadas automaticamente, no caso de venda realizada a prazo.

23 22 As reuniões com o cliente resultaram no documento de requisitos. Estes requisitos são divididos entre Requisitos funcionais e Requisitos não funcionais. De acordo com Sommerville (2003), os requisitos funcionais são aqueles que definem funções que o sistema deve fornecer, e os não funcionais podem estar relacionados às restrições que o sistema deve atender, como por exemplo, requisitos de qualidade ou desempenho. O quadro 2, especifica os requisitos funcionais e não funcionais do sistema proposto. Requisitos funcionais 1. O sistema deverá permitir ao usuário realizar login através de usuário e senha. 2. O sistema deverá permitir ao usuário manter dados de clientes. 3. O sistema deverá permitir ao usuário manter dados de funcionários. 4. O sistema deverá permitir ao usuário manter dados de fornecedores. 5. O sistema deverá permitir ao usuário manter dados de representantes dos devidos fornecedores. 6. O sistema deverá permitir ao usuário manter dados de produtos. 7. O sistema deverá permitir ao usuário registrar vendas. 8. O sistema deverá permitir ao usuário registrar compras. 9. O sistema deverá permitir consultar estoque. 10. O sistema deverá permitir o controle de contas a pagar. 11. O sistema deverá permitir o controle de contas a receber. Requisitos Não-funcionais 1. O sistema deverá operar no Sistema Operacional Windows XP. 2. Utilizar banco de dados Software Livre. 3. Desenvolvimento em Java conforme convenções próprias da linguagem. 4. Oferecer uma interface amigável. 5. Toda operação de venda deverá ser feita em tela única. 6. Valor default (cliente consumidor) para um cliente não cadastrado, no ato de uma venda. 7. Leitura de código de produtos poderá ser feita através de uma leitora de código de barras. Quadro 2 Requisitos funcionais e não funcionais. As regras de negócio definem como uma empresa funciona, normal mente são políticas, validações, restrições ou condições especificas. Tais regras

24 23 podem determinar um comportamento do sistema. No Quadro 3 estão descritas as regras de negócio, obtidas através das reuniões com o cliente. RN-01 Para efetuar o cadastro de novos fornecedores, os campos obrigatórios devem ser preenchidosl. Campos obrigatórios: CNPJ, IE, nome e razão social. RN-02 RN-03 RN-04 RN-05 RN-06 RN-07 RN-08 RN-09 RN-10 RN-11 RN-12 RN-13 RN-14 Para efetuar o cadastro de novos clientes, os campos obrigatórios devem ser preenchidos. Campos obrigatório para pessoa física: nome e CPF. Cmapos obrigatórios para pessoa juridica: nome, razão social e CNPJ. Para efetuar o cadastro de novos produtos, os campos obrigatórios devem ser preenchidos. Campos obrigatórios: descrição, tipo de apresentação, marca, estoque mínimo e estoque máximo, preço de custo e preço de venda. Para cada operação de compra é obrigatória a existência de um fornecedor, um funcionário e pelo menos um item. Para cada operação de venda é obrigatória a existência de um cliente, um funcionário e pelo menos um item. Para realizar venda no crediário, o cliente deve ser pessoa jurídica. Para efetuar o cadastro de funcionários, os campos obrigatórios devem ser preenchidos. Campos obrigatórios: CPF, RG, N Carteira de Trabalho, nome completo e data de entrada na empresa. Para efetuar o acesso ao sistema, o usuário deve entrar com usuário e senha validos. As consultas de estoque devem evidenciar a quantidade atual, minima e maxima de estoque por produto. Para efetuar o cadastro do produto é necessário que o fornecedor esteja cadastrado no sistema. Uma compra somente poderá ser registrada se o fornecedor estiver cadastrado. Uma venda somente poderá ser registrada se o cliente estiver cadastrado, ou utilizando o cliente consumidor como default. Para a manutenção de dados de representantes deve-se acessar a manutenção de fornecedores e selecionar o item relativo à manutenção de representantes de um determinado fornecedor. Para venda de produtos é necessário que o estoque deste produto não seja negativo, ou seja, o programa não aceita venda sem ter estoque.

25 24 RN-15 RN-16 O cadastro do primeiro funcionário deve ser efetuado pelo proprietário da empresa, para não correr risco de omissão de informações. Para cada fornecedor cadastrado pode-se ter pelo menos um representante vinculado neste cadastrado. RN-17 Para exclusão de qualquer cadastro deve-se fazer uma pesquisa antes de excluí-lo. RN-18 Para contas a pagar de fornecedor deve-se ter nota fiscal de compras vinculadas. RN-19 RN-20 RN-21 Para cada compra poderá ser gerada mais de uma conta a pagar, em caso de compras a prazo. Podem ser inseridas contas a pagar de diversas categorias e centro de custos. Para contas a receber deve-se dar baixa no financeiro no ato do recebimento das mesmas, inserindo possíveis despesas, tais como: juros, taxas administrativas etc. Quadro 3 Regras de Negócio. Para documentação do sistema foram usados diagramas estáticos e dinâmicos, a saber, diagrama de casos de uso, diagrama de classes e os diagramas de seqüência, que serão apresentados nos próximos tópicos.

26 25 3 ANÁLISE DO SISTEMA A análise inicia as atividades na produção de sistemas computacionais e evidência quais funções devem ser implantadas e suas características de funcionamento, sendo a análise a responsável pela definição do problema. De acordo com Bezerra (2002, p. 24): Formalmente, o termo análise corresponde a quebrar um sistema em seus componentes e estudar como tais componentes interagem com o objetivo de entender como esse sistema funciona. [...] A razão desta prática é tentar obter a melhor solução para o problema sem se preocupar com os detalhes da tecnologia a ser utilizada. É necessário saber o que o sistema proposto deve fazer para, então, definir como esse sistema irá fazê-lo. A qualidade do produto de software aumenta cada vez mais, na medida em que se aplica à análise neste desenvolvimento, pois quando os atributos de uso do sistema computacional são bem claros, o resultado no acerto e na eficácia do produto final é eminente, provendo um bom grau de satisfação do usuário final. Sendo assim, o processo da análise de sistemas é fundamental para a elaboração de um projeto que visa o desenvolvimento de um software, pois alicerça a correção das falhas que por ventura virão acontecer, dando tranqüilidade para as fases seguintes deste processo até um produto fim de alta qualidade. Na etapa da análise, ferramentas como o aplicativo Enterprise Architect (EA) e padrão de diagramas baseado na Unified Modeling Language (UML) possibilita mostrar de maneira clara e consistente a modelagem do sistema, através de seus principais diagramas, como o diagrama de casos de uso, o diagrama de classes e o diagrama de seqüência. 3.1 UML A Unified Modeling Language (UML) é uma linguagem de modelagem unificada que possibilita modelar sistemas computacionais de forma prática, através de diagramas que especificam a construção, documentação e visualização de artefatos que compõem estes sistemas. Nessa linguagem, os desenvolvedores visualizam os produtos de seu trabalho em diagramas padronizados. Junto com uma notação gráfica, a UML

27 26 também especifica significados, isto é, semântica. É uma notação independente de processos, estes diagramas descrevem aspectos de uma mesma solução com diferentes pontos de vista, divididos em cinco visões: Visão de Caso de Uso; Visão de Lógica; Visão de Processo; Visão de Implementação e Visão de Implantação. Sendo que cada uma dessas visões assume um papel característico na descrição dos aspectos do sistema, provendo mais qualidade e assertividade no produto final, fato este que favoreceu para que esta linguagem de modelagem se tornasse o padrão escolhido no mercado de fabrica de software. Especificamente as visões que compõem a UML são: Diagrama de Casos de uso Diagrama de Colaboração Diagrama de Seqüência Diagrama de Classes Diagrama de Objetos Diagrama de Estado Diagrama de Atividade Diagrama de Componente Diagrama de Execução Estes nove diagramas quando combinados mostram todas as visões do sistema a ser construído. (2009): A UML é caracterizada, segundo o OMG - Object Management Group [...] um modelo UML pode ser independente de plataforma ou de plataforma específica, como podemos escolher, o MDA é o processo de desenvolvimento utiliza as duas formas: Toda norma MDA ou aplicação baseia-se, normalmente, em um modelo independente de plataforma (PIM), que representa o seu negócio funcionalidade e comportamento muito precisa, mas não inclui os aspectos técnicos. [...]Aumentar o nível de abstração: Modelos nos ajudar, deixando-nos trabalhar a um nível mais elevado de abstração. Um modelo pode fazer isso por esconder ou mascarar detalhes, trazendo a imagem grande, ou por se concentrar em diferentes aspectos do protótipo. [...]O OMG's Unified Modeling Language (UML ) ajuda você a especificar, visualizar, e documentar modelos de sistemas de software, incluindo a sua estrutura e concepção, de uma forma que satisfaz todos estes requisitos. (Você pode usar para as empresas de modelagem UML e modelagem de outros sistemas de software não demasiado.) Usando qualquer um do grande número de UML ferramentas baseadas no mercado, você pode analisar a sua futura aplicação de requisitos e concepção de uma solução que vá ao encontro deles, [...] (tradução nossa)

28 27 Ficou claro que o uso dos padrões propostos pela UML, somaria preciosa contribuição no desenvolvimento do software SIGECOMP (Sistema de Gestão Comercial de Papelaria), bem como de qualquer artefato de software. 3.2 Ferramentas CASE As ferramentas CASE atuais propiciam a visualização das funções do software através de diagramas, papeis dos colaboradores envolvidos e a documentação das funções a serem desenvolvidas. Antes dessa fase quando não se tinha no mercado ferramentas CASE, fazia-se a documentação com editores de texto, que, todavia não mostrava realmente o que se queria e precisava ser feito bem como não fornecia as reais informações para o desenvolvimento, impactando num tempo maior de desenvolvimento e falhas perceptíveis na comunicação entre as equipes envolvidas. As ferramentas CASE ocuparam o papel que faltava para completar esse ciclo no processo de análise e no desenvolvimento dos artefatos de software, gerindo e diminuindo o tempo gasto, uma vez que melhora a comunicação, facilita o reuso do código e traz ótimo desempenho aos desenvolvedores. Segundo Bezerra (2002, p.39), o termo CASE: [...] é uma sigla em inglês para Engenharia de Software Auxiliada por Computador (Computer Aided Software Engineering). A utilização desta sigla já se consolidou no Brasil. [...]seguir algumas características que podem ser encontradas em ferramentas CASE são sucintamente descritas. - Criação de diagramas e manutenção da consistência entre esses diagramas. - Rond-Trip engeneering: geração de código fonte a partir de diagramas e geração de diagramas a partir de código fonte. - Depuração de código fonte: ferramentas que permitem encontrar erros de lógica em partes de um programa - Relatórios de testes: ferramentas que geram relatório informando sobre partes de um programa que não foram testadas. - Testes automáticos: ferramentas que realizam testes automaticamente no sistema - Gerenciamento de versões: ferramentas que permitem gerenciar as diversas versões dos artefatos de software gerando durante o ciclo de vida de um sistema. - Verificação de desempenho: averiguar o tempo de execução de módulos de um sistema, assim como o tráfego de dados em sistemas em rede. - Verificação de erros em tempo de execução. - Gerenciamento de mudanças nos requisitos. (tradução nossa)

29 28 Neste projeto utilizou-se, como ferramenta de modelagem, o software Enterprise Architect, versão Esta versão é totalmente aderente à especificação da UML 2.0, pois ela provê diversos diagramas para construção de um sistema, ainda fornece a capacidade de modelagem dos requisitos funcionais do sistema deste o inicio até o fim do ciclo de construção do software, com geração de documentação, controles de mudanças destes requisitos, manutenção e teste do artefato, bem como engenharia reversa das classes citadas. 3.3 Diagrama de Casos de Uso Os diagramas de casos de uso têm o propósito de auxiliar a identificação das funções e objetivos do usuário, sendo que as funções do sistema serão representadas através de gráficos e figuras que representam os atores, casos de uso e seus relacionamentos. Conforme Bezerra (2002, p.57): O diagrama de caso de uso (DCU) corresponde a uma visão externa do sistema, e representa graficamente os atores, casos de uso e relacionamentos entre esses elementos. O diagrama de caso de uso tem o objetivo de ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidades do sistema. Nesse sentido, a finalidade de um DCU é apresentar um tipo de diagrama de contexto que representa os elementos externos de um sistema e as maneiras segundo as quais eles as utilizam. Usando basicamente quatro elementos apresentados de forma simples, se consegue mostrar as funções do sistema a serem desenvolvidas após a análise, os elementos do caso de uso são: Ator: Quem que inicia ou beneficia-se do sistema, que pode ser tanto pessoa ou algo, geralmente representado pela figura de um boneco. Caso de uso: Descreve o relacionamento do sistema e do ator, e suas interações, geralmente representado pela figura de um balão ou circulo oval (elipse). Interação: Ato da troca de solicitação e resposta do sistema com os respectivos atores. Sistema: Conjunto de casos de uso dentro da fronteira, com propósitos específicos a serem realizados, geralmente representados pela figura de um retângulo.

30 29 Segundo Bezerra (2002, p.57): Cada caso de uso é representado por uma elipse. O nome do caso de uso é posicionado abaixo ou dentro da elipse. Um relacionamento de comunicação é representado por um segmento de reta ligando ator e caso de uso. Um ator pode estar associado a vários casos de uso em um diagrama de caso de uso.[...] Pode-se também representar a fronteira do sistema em um diagrama de caso de uso. Essa fronteira é representada por um retângulo no qual são inseridos os casos de usos. Os atores são posicionados do lado de fora do retângulo, para enfatizar a divisão entre o interior e o exterior do sistema. A figura 2 representa o diagrama de casos de uso do sistema SIGECOMP, este diagrama foi modelado após o levantamento de requisitos feitos nas reuniões com o cliente, ele mostra por meio de uma linguagem simples, o comportamento entre os atores que são caracterizados por serem agentes externos ao sistema e o sistema. Casos de Uso Implementados Casos de Uso Não Implementados Figura 2 Diagrama de casos de uso Papelaria Pirâmide

31 30 O Funcionário, até o presente momento, é o único ator que irá interagir diretamente com o sistema. Trata-se do proprietário, ou mesmo outros funcionários que podem auxilia-ló com os processos da empresa. Diante da apresentação do diagrama de caso de uso e suas definições, mostra-se a seguir os artefatos que comporão o sistema SIGECOMP. 3.4 Documentos de Caso de Uso Os documentos de caso de uso dão suporte para a evolução de todo processo do desenvolvimento deste projeto, a seguir descreve-se seu significado e sua participação, desde o comportamento dos seus usuários até a arquitetura que o mesmo será implementada. Segundo Booch, Rambaugh e Jacobson (2000, p.217): Um caso de uso especifica o comportamento de um sistema ou de parte de um sistema e é uma descrição de um conjunto de seqüência de ações, incluindo variantes realizadas pelo sistema para produzir um resultado observável do valor de um ator. Os casos de uso podem ser aplicados para captar o comportamento pretendido do sistema que está sendo desenvolvido, sem ser necessário especificar como esse comportamento é implementado. Os casos de uso fornecem uma maneira para os desenvolvedores chegarem a uma compreensão comum com os usuários finais do sistema e com os especialistas do domínio. Além disso, os casos de uso servem para ajudar a validar a arquitetura e para verificar o sistema à medida que ele evolui durante seu desenvolvimento. Define-se como caso de uso, uma abstração simples do comportamento de um ator (usuário ou algo que interage com o sistema) no manejo com o software, descrevendo um roteiro coeso com o comportamento dos artefatos em uso. e suas aplicações: Segundo Booch, Rambaugh e Jacobson (2000, p.219): casos de usos [...] Você poderá aplicar os casos de uso a todo seu sistema. Também aplicá-los a uma parte do sistema, incluindo subsistemas e até interfaces e classes individuais. Em cada situação, os casos de uso não apenas representam o comportamento desejado desses elementos, mas também podem ser utilizados como a base de casos de teste para esses elementos, à medida que evoluem durante o desenvolvimento. [...]Os casos de uso são classificadores e, portanto poderão ter atributos e operações que você poderá representar da mesma maneira como faz com as classes. Considere esses atributos como os objetos encontrados no caso de uso cujo comportamento externo você precisará descrever. De modo

32 31 semelhante, considere essas operações como as ações do sistema cujo fluxo de eventos será necessário descrever. Esses objetos e operações poderão ser utilizados em diagramas de interação para especificar o comportamento do caso de uso. As atividades da identificação dos casos de uso, embora pareçam simples, não o são, pois diante de varias opções e caminhos a se seguir, pode se perder o foco das funções que o ator deve desempenhar diante do software. Esta atividade é realizada no inicio do projeto por antever possíveis erros e problemas nesta interação. Dentre as perguntas mais importantes a serem formuladas nesta fase destacam-se: Quais foram os atores? Quais seriam as funções de cada ator? As informações de leitura, mudanças, criação e armazenamento no software caberiam a quais atores? Quais atores receberiam informações do software? Quais atores manteriam estas informações no software? Quais possíveis usos de outro software ou Hardware neste software (Leitura de código de barra)? Este software deveria informar mudanças realizadas pelo autor em seu estado de origem? Se o software teria necessidade de comunicação de eventos externos e quais atores a fariam? Booch, Rambaugh e Jacobson (2000, p.228) mostram as técnicas básicas de modelagem dos casos uso. Para fazer a modelagem do comportamento de um elemento: Identifique os atores que interagem com o elemento. Candidatos a atores incluem grupos que exigem determinado comportamento para a realização de suas tarefas ou que são necessários direta ou indiretamente para a realização de funções do elemento. Organize os atores, identificando papéis gerais e mais especializados. Para cada ator, considere as formas primárias em que o ator interage com o elemento. Considere também interações que alteram o estado do elemento ou seu ambiente ou que envolvam uma resposta a algum evento. Considere também as formas excepcionais em que cada ator interage com o elemento. Organize esses comportamentos como casos de uso, aplicando relacionamentos de inclusão e estendidos com a finalidade de fazer a fatoração do comportamento comum e diferenciar o comportamento excepcional. Apesar de serem similares aos diagramas que permitem a engenharia de produção e reversa, os casos de uso são documentos de texto, e refletem a

33 32 implementação dos sistemas, subsistemas e classes a serem criadas bem como seus comportamentos. Entretanto não permitem a engenharia de produção, outras técnicas que utilizam casos de uso já estruturados podem ser utilizados na engenharia direta. Tais técnicas evitam erros na fabricação do software e conseqüente impacto na redução do ciclo de vida desta etapa. Conforme Bezerra (2002, p.45): O modelo de Casos de Uso é uma representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interage com ele. [...] Desde então, esse modelo vem se tornando cada vez mais popular para realizar a documentação de requisitos funcionais de uma aplicação, devido à sua notação gráfica simples e descrição em linguagem natural, o que facilita a comunicação de desenvolvedores e usuários. [...] Além disso, o modelo de casos de uso fora os desenvolvedores a moldarem o sistema de acordo com o usuário, e não o usuário de acordo com o sistema. Até um usuário sem experiência na área de sistemas identificaria as funções de um caso de uso, pois, ele descreve o que se deve fazer sem se importar como isso será feito. basicamente de: Em linhas gerais um caso de uso nos padrões UML e constituído Nome: A identificação do nome do caso de uso em questão deve ser a mesma que aparece no diagrama de caso de uso, cada caso de uso terá um único nome. Identificador: Código que referência os diversos documentos relacionados com o modelo de caso de uso, recomenda-se o uso do sufixo CSU seguido de um numeral, ex. CSU07 Sumário: resumo das descrições do caso de uso. Recomendam-se no máximo duas frases. Ator primário: A identificação do ator ou algo que inicia ou beneficia-se do caso de uso. Ator(es) Secundário(s): A identificação dos demais atores que participam do caso de uso Pré-condições: regras que define em que hipóteses serão assumidas como verdadeiras para que o caso de uso tenha início. Ex. O usuário deve inserir senha para ter acesso ao sistema. Pós-condição: e o estado do sistema após ter sido executado. Fluxo Principal: Define a descrição da seqüencia de passos do fluxo principal. Toda

34 33 descrição de caso de uso deve ter um item descrevendo o fluxo principal, pois contribuem para o sucesso na descrição da realização do caso de uso, estando presente em todo casos de uso. Fluxo Alternativo: estes fluxos descrevem o que acontece nas escolhas do ator quando estas escolhas são diferentes das alternativas do fluxo principal, para alcançar seu foco proposto, estes também descrevem situações de escolhas exclusivas entre si (quando existem diferentes possibilidades e somente uma deve ser realizada). Fluxo de Exceção: relatam as atividades de exceção, onde algo inesperado acontece entre o caso de uso e o ator.(por exemplo: usuário executa ação invalidada pelo sistema). Regras de Negócio: Quando um caso de uso faz referência a uma ou mais regras de negócio, ou seja são políticas, condições ou restrições que precisam ser explicitadas na execução dos processos existentes em uma organização, estas devem estar completas e serem apresentadas em documento único chamado de modelo de regras de negócio. Apresenta-se a seguir, os documentos de caso de uso do Software SIGECOMP, que foram escritos baseados nas melhores práticas de identificação apresentadas pela UML. Devidamente organizados e estruturados, estes impactaram sistematicamente na redução de erros e no tempo gasto em seu desenvolvimento.

35 34 No quadro 4 estão descritos no documento de caso de uso as funções que o ator (funcionário) deve aplicar ao realizar login no sistema. Após o preenchimento dos campos solicitados, se estes forem válidos, o sistema exibe a tela principal do programa, caso contrário, o sistema permanece na tela de login, na qual é exibida a mensagem de erro no login. Nome Realizar Login CSU-01 Sumário Este caso de uso descreve o processo para realizar login. Ator primário: Funcionário Ator(es) secundário(s): - Pré-condição: Possuir nome de usuário e senha validos Pós-condição: Acesso ao menu principal do sistema 1. O sistema exibe a tela inicial Fluxo Principal 2. O funcionário entra com os respectivos dados: usuário e senha. 3. O sistema verifica se o usuário e senha são validos. 4. O sistema apresenta o menu principal e o caso de uso é encerrado. Fluxo Alternativo [ ]: Não há. Fluxo de Exceção [3]: Usuário ou Senha inválida a) O usuário informa dados incorretos ou inválidos. b) O sistema emite uma mensagem. Regras de Negócio Associadas RN-08 Quadro 4 Documento de caso de uso Realizar login.

36 35 No quadro 5 estão descritos no documento de caso de uso as funções que o ator (funcionário) deve exercer para Manter dados do Cliente. Nome Manter Dados de Cliente CSU-02 Sumário Esse caso de uso descreve as etapas necessárias para a manutenção dos dados de clientes (inclusão, alteração, exclusão). Ator primário: Funcionário Ator(es) secundário(s): Pré-condição: Estar logado no sistema Pós-condição: Funcionário cadastrado, atualizado ou excluído. Fluxo Principal 1. O funcionário solicita a manutenção de clientes no sistema. 2. O sistema apresenta as opções (incluir, alterar, excluir). 3. O funcionário indica a opção desejada. 4. O sistema registra a operação e o caso de uso e encerrado. Fluxo Alternativo [3.1]: Incluir a) O funcionário solicita a inclusão de um cliente. b) O sistema solicita os dados a serem preenchidos. c) O funcionário informa os dados d) O funcionário confirma inclusão e o caso de uso retorna ao passo 4. Fluxo Alternativo [3.2]: Alterar a) O funcionário solicita a alteração dos dados de um cliente. b) O sistema apresenta o formulário para a alteração dos dados. c) O funcionário altera os dados. d) O funcionário confirma a alteração e o caso de uso retorna ao passo 4. Fluxo Alternativo [3.3]: Excluir a) O usuário solicita a exclusão do cadastro de um cliente. b) O sistema exibe uma mensagem de alerta para confirmação da exclusão. c) O funcionário confirma a exclusão e o caso de uso retorna ao passo 4. Fluxo de Exceção [3]: não preenchimento dos dados obrigatórios a) O usuário não informa os dados obrigatórios b) O sistema emite uma mensagem. Regras de Negócio Associadas RN-02 Quadro 5 Documento de caso de uso Manter dados de cliente.

37 36 No quadro 6 estão descritos no documento de caso de uso as funções que o ator (funcionário) deve exercer para Manter dados de Funcionário. Nome Manter Dados de Funcionário CSU-03 Sumário Esse caso de uso descreve as etapas necessárias para a manutenção dos dados de funcionários (inclusão, alteração, exclusão). Ator primário: Funcionário Ator(es) secundário(s): Funcionário Pré-condição: Estar logado no sistema Pós-condição: Funcionário cadastrado, atualizado ou excluído. Fluxo Principal 1. O funcionário solicita a manutenção de funcionários no sistema. 2. O sistema apresenta as opções (incluir, alterar, excluir). 3. O funcionário indica a opção desejada. 4. O sistema registra a operação e o caso de uso e encerrado. Fluxo Alternativo [3.1]: Incluir a) O funcionário solicita a inclusão de um funcionário. b) O sistema solicita os dados a serem preenchidos. c) O funcionário informa os dados d) O funcionário confirma inclusão e o caso de uso retorna ao passo 4. Fluxo Alternativo [3.2]: Alterar a) O funcionário solicita a alteração dos dados de um funcionário. b) O sistema apresenta o formulário para a alteração dos dados. c) O funcionário altera os dados. d) O usuário confirma a alteração e o caso de uso retorna ao passo 4. Fluxo Alternativo [3.3]: Excluir a) O funcionário solicita a exclusão do cadastro de um funcionário. b) O sistema exibe uma mensagem de alerta para confirmação da exclusão. c) O funcionário confirma a exclusão e o caso de uso retorna ao passo 4. Fluxo de Exceção [ 3 ]: não preenchimento dos dados obrigatórios a) O usuário não informa os dados obrigatórios b) O sistema emite uma mensagem. Regras de Negócio Associadas RN-07, RN-15 Quadro 6 Documento de caso de uso Manter dados de funcionário.

38 37 No quadro 7 estão descritos no documento de caso de uso as funções que o ator (funcionário) deve exercer para Manter dados de Fornecedor. Nome Manter Dados de Fornecedor CSU-04 Sumário Esse caso de uso descreve as etapas necessárias para a manutenção de dados de Fornecedores (inclusão, alteração, exclusão). Ator primário: Funcionário Ator(es) secundário(s): Pré-condição: Estar logado no sistema Pós-condição: Fornecedor cadastrado, atualizado ou excluído. Fluxo Principal 1. O funcionário solicita a manutenção de fornecedor no sistema. 2. O sistema apresenta as opções (incluir, alterar, excluir). 3. O funcionário indica a opção desejada. 4. O sistema registra a operação e o caso de uso e encerrado. Fluxo Alternativo [ 3.1 ]: incluir a) O funcionário solicita a inclusão de um fornecedor. b) O sistema solicita os dados a serem preenchidos. c) O funcionário informa os dados. d) O funcionário confirma inclusão e o caso de uso retorna ao passo 4. Fluxo Alternativo [ 3.2]: Alterar a) O funcionário solicita a alteração dos dados de um fornecedor. b) O sistema apresenta o formulário para a alteração dos dados. c) O funcionário altera os dados. d) O funcionário confirma a alteração e o caso de uso retorna ao passo 4. Fluxo Alternativo [ 3.3 ]: excluir a) O funcionário solicita a exclusão do cadastro de um Fornecedor. b) O sistema exibe uma mensagem de alerta para confirmação da exclusão. c) O funcionário confirma a exclusão e o caso de uso retorna ao passo 4. Fluxo de Exceção [ 3 ]: não preenchimento dos dados obrigatórios Caso não sejam informados os dados obrigatórios do cadastro o sistema emite uma mensagem e o caso de uso retorna ao passo 4. Regras de Negócio Associadas RN-01 Quadro 7 Documento de caso de uso Manter dados de fornecedor.

39 38 No quadro 8 estão descritos no documento de caso de uso as funções que o ator (funcionário) deve exercer para Manter dados de Representantes. Nome Manter Dados de Representantes CSU-05 Sumário Esse caso de uso descreve as etapas necessárias para a manutenção de dados de Representantes (inclusão, alteração, exclusão). Ator primário: Funcionário Ator(es) secundário(s): - Pré-condição: Estar logado no sistema Pós-condição: Representante cadastrado, atualizado ou excluído. Fluxo Principal 1. O funcionário solicita a manutenção de Fornecedores no sistema. 2. O funcionário solicita a manutenção de Representantes no sistema. 3. O sistema apresenta as opções (incluir, alterar, excluir). 4. O funcionário indica a opção desejada. 5. O sistema registra a operação e o caso de uso e encerrado. Fluxo Alternativo [ 3.1 ]: incluir a) O funcionário solicita a inclusão de um representante. b) O sistema solicita os dados a serem preenchidos. c) O funcionário informa os dados. d) O funcionário confirma a inclusão e os caso de uso retorna ao passo 3. Fluxo Alternativo [ 3.2 ]: alterar a) O funcionário solicita a alteração dos dados de um representante. b) O sistema apresenta o formulário para a alteração dos dados. c) O funcionário altera os dados. d) O funconário confirma a alteração e o caso de uso retorna ao passo 3. Fluxo Alternativo [ 3.3 ]: excluir a) O funcionário solicita a exclusão total de dados de um representante. b) O sistema exibe uma mensagem de alerta para confirmação da exclusão. c) O funcionário confirma a exclusão e o caso de uso retorna ao passo 3. Fluxo de Exceção [ 3 ]: não preenchimento dos dados obrigatórios Caso não sejam informados os dados obrigatórios do cadastro o sistema emite uma mensagem e o caso de uso retorna ao passo 3. Regras de Negócio Associadas RN-01, RN-13, RN-16 Quadro 8 Documento de caso de uso Manter dados de representante.

40 39 No quadro 9 estão descritos no documento de caso de uso as funções que o ator (funcionário) deve exercer para Manter Produtos. Nome Manter Produtos CSU-06 Sumário Esse caso de uso descreve as etapas necessárias para a manutenção de produtos. (inclusão, alteração, exclusão). Ator primário: funcionário Ator(es) secundário(s): - Pré-condição: estar logado no sistema Pós-condição: produto cadastrado, atualizado ou excluído. Fluxo Principal 1. O funcionário solicita a manutenção de produtos no sistema. 2. O sistema apresenta as opções (incluir, alterar, excluir). 3. O funcionário indica a opção desejada. 4. O sistema registra a operação e o caso de uso e encerrado. Fluxo Alternativo [ 3.1 ]: incluir a) O funcionário solicita a inclusão de um Produto. b) O sistema solicita os dados a serem preenchidos. c) O funcionário informa os dados d) O funcionário confirma a exclusão e o caso de uso retorna ao passo 4 Fluxo Alternativo [ 3.2 ]: alterar a) O funcionário solicita a alteração dos dados de um produto. b) O sistema apresenta o formulário para a alteração dos dados. c) O funcionário altera os dados. d) O funconário confirma a alteração e o caso de uso retorna ao passo 4. Fluxo Alternativo [ 3.3 ]: excluir a) O funcionário solicita a exclusão total de dados de um produto. b) O sistema exibe uma mensagem de alerta para confirmação da exclusão. c) O funcionário confirma a exclusão e o caso de uso retorna ao passo 4. Fluxo de Exceção [ 3 ]: não preenchimento dos dados obrigatórios Caso não sejam informados os dados obrigatórios do cadastro, o sistema emite uma mensagem e o caso de uso retorna ao passo 4. Fluxo de Exceção [ 3 ]: fornecedor não cadastrado O sistema permite apenas o cadastro de produtos que tenham seus fornecedores já cadastrados. Caso o produto não possua fornecedor, sistema emite mensagem. Regras de Negócio Associadas RN-03, RN-10 Quadro 9 Documento de caso de uso Manter dados de produtos.

41 40 No quadro 10 estão descritos no documento de caso de uso as funções que o ator (funcionário) deve exercer para Consultar Estoque. Nome Consultar Estoque CSU-07 Sumário Este caso de uso descreve o processo para consultar o estoque. Ator primário: Funcionário Ator(es) secundário(s): - Pré-condição: Existir movimentação de produtos (Compra/Venda) Pós-condição: A empresa terá informações do estoque Fluxo Principal 1. O funcionário solicita a consulta a ser realizada no sistema. 2. O sistema apresenta o formulário de consulta. 3. O funcionário preenche os dados para a consulta 4. O sistema apresenta os dados de estoque de todos os produtos cadastrados e o caso de uso é encerrado. Fluxo Alternativo [ ]: Não há. Fluxo de Exceção [ 4 ]: Produto não cadastrado a) O sistema informa que os dados solicitados não conferem com os dados cadastrados. b) O caso de uso retorna ao passo 2. Regras de Negócio Associadas RN-09 Quadro 10 Documento de caso de uso Consultar estoque.

42 41 No quadro 11 estão descritos no documento de caso de uso as funções que o ator (funcionário) deve exercer para Registrar Compras. Nome Registrar Compras CSU-08 Sumário Este caso de uso descreve as etapas necessárias para controlar o movimento de compras. Ator primário: Funcionário Ator(es) secundário(s): - Pré-condição: Efetuar uma compra de algum produto. Pós-condição: Compra efetuada e estoque atualizado. Fluxo Principal 1. O funcionário solicita a opção de registrar uma compra no sistema. 2. O sistema solicita os dados a serem preenchidos. 3. O funcionário informa os dados (funcionário, fornecedor, produtos e contas a pagar) e confirma a operação. 4. O sistema registra a operação, atualiza o estoque e o caso de uso e encerrado. Fluxo Alternativo [ 3 ]: Dados incorretos a) O sistema solicita o preenchimento correto dos dados, conforme a regra de negócio RN 04. b) O caso de uso retorna ao passo 02. Regras de Negócio Associadas RN-04, RN-11, RN-19 Quadro 11 Documento de caso de uso Registrar compras.

43 42 No quadro 12 estão descritos no documento de caso de uso as funções que o ator (funcionário) deve exercer para Registrar Vendas. Nome Registrar Vendas CSU-09 Sumário Este caso de uso descreve as etapas necessárias para controlar o movimento vendas. Ator primário: Funcionário Ator(es) secundário(s): Cliente Pré-condição: Efetuar uma venda de algum produto. Pós-condição: Venda efetuada e estoque atualizado. Fluxo Principal 1. O funcionário solicita a opção de registrar uma venda no sistema. 2. O sistema solicita os dados a serem preenchidos. 3. O funcionário informa os dados e confirma a operação. 4. O sistema registra a operação, atualiza o estoque e o caso de uso é encerrado. Fluxo Alternativo [ 3 ]: Dados incorretos a) O sistema solicita o preenchimento correto dos dados. b) O caso de uso retorna ao passo 02. RN-05, RN-06, RN-12, RN-14 Regras de Negócio Associadas Quadro 12 Documento de caso de uso Registrar vendas.

44 43 No quadro 13 estão descritos no documento de caso de uso as funções que o ator (funcionário) deve exercer para Manter Contas a Pagar. Nome Manter Contas a Pagar CSU-10 Sumário Esse caso de uso descreve as etapas necessárias para controlar contas a pagar. Ator primário: Funcionário Ator(es) secundário(s): - Pré-condição: Existir uma movimentação de compras de produtos e serviços. Pós-condição: O sistema atualiza contas a pagar. Fluxo Principal 1. O funcionário solicita a manutenção de contas a pagar. 2. O sistema apresenta as opções (incluir, alterar, excluir). 3. O funcionário indica a opção desejada. 4. O sistema registra a operação e o caso de uso e encerrado. Fluxo Alternativo [ 3.1 ]: incluir a) O funcionário solicita a inclusão de uma conta a pagar. b) O sistema solicita os dados a serem preenchidos. c) O funcionário informa os dados d) O funcionário confirma a exclusão e o caso de uso retorna ao passo 4. Fluxo Alternativo [ 3.2 ]: alterar a) O funcionário solicita a alteração dos dados de uma conta a pagar. b) O sistema apresenta o formulário para a alteração dos dados. c) O funcionário altera os dados. d) O funconário confirma a alteração e o caso de uso retorna ao passo 4. Fluxo Alternativo [ 3.2 ]: excluir a) O funcionário solicita a exclusão de uma conta a pagar. b) O sistema exibe uma mensagem de alerta para confirmação da exclusão. c) O funcionário confirma a exclusão e o caso de uso retorna ao passo 4. Fluxo de Exceção [ ]: Não há. - Regras de Negócio Associadas RN-18, RN-20 Quadro 13 Documento de caso de uso Manter contas a pagar.

45 44 No quadro 14 estão descritos no documento de caso de uso as funções que o ator (funcionário) deve exercer para Manter Contas a Receber. Nome Manter Contas a Receber CSU-11 Sumário Esse caso de uso descreve as etapas necessárias para controlar contas a receber. Ator primário: Funcionário Ator(es) secundário(s): - Pré-condição: Existir uma movimentação de vendas de produtos. Pós-condição: O sistema atualiza contas a receber. Fluxo Principal 1. O funcionário solicita a manutenção de contas a receber. 2. O sistema apresenta as opções (incluir, alterar, excluir). 3. O funcionário indica a opção desejada. 4. O sistema registra a operação e o caso de uso e encerrado. Fluxo Alternativo [ 3 ]: incluir a) O funcionário solicita a inclusão de uma conta a receber. b) O sistema solicita os dados a serem preenchidos. c) O funcionário informa os dados. d) O funcionário confirma exclusão e o caso de uso retorna ao passo 4 Fluxo Alternativo [ 3.1 ]: alterar a) O funcionário solicita a alteração dos dados de uma conta a receber. b) O sistema apresenta o formulário para a alteração dos dados. c) O funcionário altera os dados. d) O funconário confirma a alteração e o caso de uso retorna ao passo 4. Fluxo Alternativo [ 3.2 ]: excluir a) O funcionário solicita a exclusão de uma conta a receber. b) O sistema exibe uma mensagem de alerta para confirmação da exclusão. c) O funcionário confirma a exclusão e o caso de uso retorna ao passo 4. Fluxo de Exceção [ ]: Não há. Regras de Negócio Associadas RN-21 Quadro 14 Documento de caso de uso Manter contas a receber.

46 Classes de Análise As classes descrevem características semelhantes em seus atributos, operações, relacionamentos e semântica. São de essenciais na distribuição equilibrada de responsabilidades em um sistema, pois são caracterizadas por blocos de construções, implementando uma ou mais interfaces, bem como capturando o vocabulário do sistema a ser desenvolvido, são essenciais em qualquer sistema orientado a objeto. Conforme Booch, Rumbaugh, Jacobson (2000, p.48): [...] Uma classe é uma abstração de itens que fazem parte do seu vocabulário. A classe não é um objeto individual, mas representa um conjunto inteiro de objetos. Portanto você pode pensar conceitualmente em parede como uma classe de objetos com determinadas propriedades comuns, como altura, largura, espessura, suportar ou não pesos e assim por diante. Você pode também considerar instâncias individuais de paredes, como a parede do lado sudoeste do meu escritório. [...] No caso de software, muitas linguagens de programação dispõem de suporte direto para o conceito de classe. Isso é excelente, pois significa que as abstrações que você criar podem ser mapeadas diretamente para a linguagem de programação, ainda que sejam abstrações de itens que não sejam software, como cliente, transação ou conversação. A UML usa a figura de um retângulo para representar uma classe, e suas principais abstrações são caracterizadas pelo: nome, atributos e operações. O nome é um conjunto de caracteres, quando sozinho, é conhecido como nome simples, o nome do caminho é o nome da classe, o seu prefixo é o nome do pacote que essa classe pertence. O atributo é uma característica que a classe pode apresentar nas instâncias de seus valores, podendo esta classe ter um ou mais atributos, sendo até permitido não ter nenhum atributo, estes atributos definirão o tipo de dados ou estados que os objetos da classe cobrirão. As operações são implementações de uma atividade, que quando solicitada por qualquer objeto da classe modifica o seu comportamento, esta especificação deve conter assinatura, que contém o nome, o tipo e o valor-padrão

47 46 das funções e o tipo de valor a ser retornado Diagrama de Classes de Análise O diagrama de classe de análise mostra as colaborações e relacionamentos de um conjunto de classes, bem como as interfaces que um determinado sistema possui, estes diagramas são mais presentes em sistemas de modelagem orientados a objetos. As classes de negócios indicam o que será implantado, pois possuem a estrutura e funcionalidades lógicas e também as regras de negócios a serem desenvolvidas no sistema proposto. As classes de análise sintetizam as ações relacionadas aos requisitos funcionais do sistema. Estas classes usam detalhes para representar uma modelagem conceitual primária para elementos do sistema que possuem atributos e responsabilidades específicas, entre elas enfatiza-se o encapsulamento da estrutura e do comportamento dos objetos. A figura 3 apresenta o diagrama de classes de negócio do sistema SIGECOMP, demonstrando suas classes, interfaces e colaborações e seus relacionamentos.

48 47 Figura 3 Diagrama de classes de negócio do sistema SIGECOMP.

49 Descriminação das classes de negócio. As classes de negócio que compõem o sistema SIGECOMP: Login: classe responsável por funções e características inerentes ao login no sistema. Fornecedor: mantém as funções relacionadas as associações de fornecedor e seu relacionamento com a classe representante e suas possíveis áreas. Funcionário: classe responsável por funções e características inerentes ao cadastro de funcionário. Cliente: mantém as funções relacionadas as associações de cliente e suas possíveis áreas, entre elas pessoa física e jurídica. Pedido: mantém as funções relacionadas as associações do pedido e suas possíveis áreas entre elas pedido de compra e contas a pagar; pedido de venda e contas a receber, bem como item e produto. Produto: mantém as funções relacionadas as associações do produto e suas possíveis áreas, entre elas item e pedido. Item: mantém as funções relacionadas as associações do item e suas possíveis áreas, entre elas pedido e produto. Diante das informações já vistas das classes de negócios que estruturaram o sistema, a seguir apresenta-se a modelagem deste sistema, seu comportamento e o tratamento das requisições externas a ele compostas Estereótipo das Classes Os estereótipos classificam as classes de análise. Esse conceito é aplicado para agrupar as classes que tem algo em comum. Essas classes podem ser dividas em classes de fronteira, classes de controle e classes de entidade. Representa-se um estereótipo graficamente, por um nome entre << >>(dois sinais

50 49 de menor e dois sinais de maior), ou por texto, se esse não modificar o desenho padrão do componente representado. Conforme Guedes (2005, p.42): Estereótipos são uma maneira de destacar ou diferenciar um componente ou relacionamento de outros componentes ou relacionamentos iguais, atribuindo-lhe características especiais ou modificando-as de alguma forma. Estereótipos podem ser de texto, quando não modificam o desenho padrão do componente, ou gráficos quando modificam a forma padrão do componente. O estereótipo de fronteira ou estereótipo <<boundary>>, identifica as classes que servem de comunicação entre os atores e o sistema. Essas classes contêm o código de controle das interfaces do sistema, e são responsáveis por traduzir os eventos gerados por um ator em eventos relevantes ao sistema. Objetos destas classes também são responsáveis por traduzir os resultados de uma operação das classes internas em informações que possam ser entendidas pelos atores. A figura 4 mostra como são representadas graficamente as classes de fronteira. sd Classe Fronteira << nome da classe >> Figura 4 Estereótipo de uma classe de fronteira. O estereótipo de controle, também conhecido como estereótipo <<control>> identifica as classes que servem de intermédio entre as classes <<boundary>> e as outras classes do sistema. Essas classes são responsáveis por controlar a lógica de execução de um caso de uso, sendo seus objetos responsáveis por interpretar os eventos gerados pelos usuários e repassá-los aos outros objetos

51 50 que participam da solicitação. A figura 5 mostra como são representadas graficamente as classes de controle. sd Classe Controle << nome da classe >> Figura 5 Estereótipo de uma classe de controle. O estereótipo de entidade, também conhecido como estereótipo <<entity>> tem por objetivo tornar explicito que uma classe é uma entidade, ou seja, a classe contém informações recebidas ou geradas por meio do sistema. São responsáveis por manter as informações manipuladas pelo sistema, desta maneira, estes objetos (instâncias de entidade) geralmente são persistentes. Essas classes representam conceitos do domínio do negócio, e normalmente dão origem às bases de dados do sistema. A figura 6 mostra como são representadas graficamente as classes de entidade. sd Classe Entidade << nome da classe >> Figura 6 Estereótipo de uma classe de entidade.

52 Diagramas de Seqüência Os diagramas de seqüência têm o propósito de auxiliar a cronologia das funções e objetivos do usuário, focando na ordem em que são trocadas as mensagens entre os objetos que o compõem. Conforme Booch, Rumbaugh, Jacobson (2000), um diagrama de sequência enfatiza a ordenação temporal das mensagens. Os elementos gráficos que compõem um diagrama de seqüência e suas principais abstrações são: ator, objeto, classe, mensagem, linha da vida e foco de controle. Apresenta-se a seguir os diagramas de seqüência de análise do software SIGECOMP, que foram escritos baseados nas melhores práticas de identificação apresentadas pela UML. Devidamente organizados e estruturados, estes impactaram sistematicamente na redução de erros e no tempo gasto em seu desenvolvimento, pois mostram uma visão do sistema em funcionamento, além de agrupar as classes de análise precedidas neste documento.

53 52 Diagrama de Seqüência de Análise do Caso de Uso Realizar Login A figura 7 mostra o diagrama de seqüência de análise do caso de uso realizar login. É descrito neste diagrama as funções que o ator (funcionário) deve aplicar ao realizar login no sistema. Após o preenchimento dos campos solicitados, se estes forem válidos, o sistema exibe a tela principal do programa, se o funcionário for invalido ou inserir senha errada o sistema volta a exibir a interface inicial com mensagem de alerta. Figura 7 Diagrama de seqüência de análise do caso de uso Realizar Login.

54 53 Diagrama de Seqüência de análise do Caso de Uso Manter Dados de Cliente Manter Dados de Cliente. A figura 8 mostra o diagrama de seqüência de análise do caso de uso Figura 8 Diagrama de seqüência de análise do caso de uso Manter Dados de Cliente

55 54 Diagrama de Seqüência de análise do Caso de Uso Manter Dados de Funcionário A figura 9 mostra o diagrama de seqüência de análise do caso de uso Manter Dados de Funcionário. Figura 9 Diagrama de seqüência de análise do caso de uso Manter Dados de Funcionário

56 55 Diagrama de Seqüência de análise do Caso de Uso Manter Dados de Fornecedor A figura 10 mostra o diagrama de seqüência de análise do caso de uso Manter Dados do Fornecedor. Figura 10 Diagrama de seqüência de análise do caso de uso Manter Dados de Fornecedor

57 56 Diagrama de Seqüência de análise do Caso de Uso Manter Dados de Representante A figura 11 mostra o diagrama de seqüência de análise do caso de uso Manter Dados de Representante, é descrito neste diagrama as funções que o ator (funcionário) deve exercer para Manter dados de Representante. Figura 11 Diagrama de seqüência de análise do caso de uso Manter Dados de Representante.

58 57 Diagrama de Seqüência de análise do Caso de Uso Manter Dados de Produto A figura 12 mostra o diagrama de seqüência de análise do caso de uso Manter Dados de Produto, é descrito neste diagrama as funções que o ator (funcionário) deve exercer para Manter dados do Produto. sd Seq. Análise Manter Dados de Produto Funcionário Menu Produto Produto Produto opt Manter Dados de Produto [Incluir] [Alterar] [Excluir] Usuário solicita a opção produto no menu principal É exibida a tela de manutenção de dados de produtos Usuário escolhe a opção desejada É exibido o formulário de cadastro para preenchimento Usuário preenche o formulário e envia os dados Solicitação direcionada ao controlador É exibida a tela de manutenção de dados de produtos Usuário escolhe o produto a ter os dados alterados É exibido o formulário contendo os dados do solicitados Usuário altera os dados necessário e envia os dados Lista de produtos Solicitação de inclusão Busca produtos cadastrados Produtos existentes É exibida a tela de manutenção de dados de produtos Usuário seleciona Produto à ser excluído Ok Dados enviados Produto cadastrado Busca dados para alteração Devolve dados solicitados Dados enviados Dados do Produto alterados com sucesso Solicitação de exclusão Produto excluído com sucesso Dados do cadastro Ok Busca dados Ok Dados a serem alterados Alteração de dados ok Produto a ser excluído Ok É exibida a tela de manutenção de dados de produtos Figura 12 Diagrama de seqüência de análise do caso de uso Manter Dados de Produtos.

59 58 Diagrama de Seqüência de análise do Caso de Uso Registrar Compra A figura 13 mostra o diagrama de seqüência de análise do caso de uso Registrar Compra, é descrito neste diagrama as funções que o ator (funcionário) deve exercer para Registrar Compra. Figura 13 Diagrama de seqüência de análise do caso de uso Registrar Compra.

60 59 Diagrama de Seqüência de análise do Caso de Uso Registrar Venda A figura 14 mostra o diagrama de seqüência de análise do caso de uso Registrar Venda, é descrito neste diagrama as funções que o ator (funcionário) deve exercer para Registrar Venda. Figura 14 Diagrama de seqüência de análise do caso de uso Registrar Venda.

61 60 Diagrama de Seqüência de análise do Caso de Uso Manter Contas a Pagar A figura 15 mostra o diagrama de seqüência de análise do caso de uso Manter Contas a Pagar, é descrito neste diagrama as funções que o ator (funcionário) deve exercer para Manter Contas a Pagar. sd Seq. Análise Manter Contas a Pagar Funcionário Menu Contas a pagar Contas a pagar Contas a pagar opt Manter Dados de Contas a pagar [Incluir] [Alterar] [Excluir] Usuário solicita a opção Contas a pagar no menu principal É exibida a tela de manutenção de dados de Contas a pagar Usuário escolhe a opção desejada Solicitação direcionada ao controlador É exibido o formulário de cadastro para preenchimento Usuário preenche o formulário e envia os dados É exibida a tela de manutenção de dados de Contas a pagar Usuário escolhe a Contas a pagar a ter os dados alterados É exibido o formulário contendo os dados do solicitados Usuário altera os dados necessário e envia os dados Lista de Contas a pagar - Direciona solicitação Solicitação de inclusão Direciona para o formulário de cadastro Dados enviados Contas a pagar cadastrada Busca dados para alteração Devolve dados solicitados Dados enviados Dados da Contas a pagar alterados com sucesso Busca Contas a pagar cadastradas Contas a pagar existentes Dados do cadastro É exibida a tela de manutenção de dados de Contas a pagar Usuário seleciona Contas a pagar à ser excluída É exibida a tela de manutenção de dados de Contas a pagar Solicitação de exclusão Contas a pagar excluída com sucesso Ok Busca dados Ok Dados a serem alterados Alteração de dados ok Fornecedor a ser excluído Ok Figura 15 Diagrama de seqüência de análise do caso de uso Manter Contas a Pagar.

62 61 Diagrama de Seqüência de análise do Caso de Uso Manter Contas a Receber A figura 16 mostra o diagrama de seqüência de análise do caso de uso Manter Contas a Receber, é descrito neste diagrama as funções que o ator (funcionário) deve exercer para Manter Contas a Receber. sd Seq. Análise Manter Contas a Receber Funcionário Menu Contas a receber Contas a receber Contas a receber opt Manter Dados de Contas a receber [Incluir] [Alterar] [Excluir] Usuário solicita a opção Contas a receber no menu principal É exibida a tela de manutenção de dados de Contas a receber Usuário escolhe a opção desejada Solicitação direcionada ao controlador É exibido o formulário de cadastro para preenchimento Usuário preenche o formulário e envia os dados É exibida a tela de manutenção de dados de Contas a receber Usuário escolhe a Contas a receber a ter os dados alterados É exibido o formulário contendo os dados do solicitados Usuário altera os dados necessário e envia os dados Lista de Contas a receber - Direciona solicitação Solicitação de inclusão Direciona para o formulário de cadastro Dados enviados Contas a receber cadastrada Busca dados para alteração Devolve dados solicitados Dados enviados Dados da Contas a receber alterados com sucesso Busca Contas a receber cadastradas Contas a receber existentes Dados do cadastro É exibida a tela de manutenção de dados de Contas a receber Usuário seleciona Contas a receber à ser excluída É exibida a tela de manutenção de dados de Contas a receber Solicitação de exclusão Contas a receber excluída com sucesso Ok Busca dados Ok Dados a serem alterados Alteração de dados ok Fornecedor a ser excluído Ok Figura 16 Diagrama de seqüência de análise do caso de uso Manter Contas a Receber.

63 62 4 ARQUITETURA E CÓDIGO Arquitetura de software refere-se à estrutura global do software. Ela representa a estrutura e a organização dos componentes do sistema. Além disso, a arquitetura mostra como esses componentes interagem entre si. Pressman (2006), afirma que a arquitetura de software e sua representação explícita, tornaram-se temas dominantes em engenharia de software. Segundo ele, o ponto chave da arquitetura de software é modelar a estrutura de um sistema e mostrar a maneira pela qual os componentes de dados e procedimentais colaboram entre si. A definição da arquitetura é de extrema importância no processo de construção de um software, pois permite ao profissional de Tecnologia da Informação (TI) examiná-lo em seu todo. Além disso, sua representação constitui um facilitador da comunicação entre todas as partes envolvidas no desenvolvimento e destaca decisões iniciais de projeto. A arquitetura de software não está apenas relacionada à estrutura e ao comportamento, mas também ao uso, a funcionalidade, ao desempenho, a flexibilidade, a reutilização, a abrangência, a adequações e a restrições de caráter econômico e tecnológico, além de questões estéticas. (BOOCH, RUMBAUGH & JACOBSON, 2000, p. 32) A arquitetura do sistema afeta o desempenho, a robustez e a facilidade de distribuição e de manutenção de um sistema, portanto a escolha da arquitetura pode depender dos requisitos não funcionais do sistema. Para a definição da arquitetura de um sistema especifico, pode-se ter como base um modelo de arquitetura já existente, porém é necessário ter uma conscientização da aplicabilidade desses modelos e de seus pontos fortes e fracos. Sommerville (2003) afirma que requisitos não funcionais como desempenho, disponibilidade, segurança e facilidade de manutenção, impactam na definição da arquitetura. Pode ocorrer, por exemplo, que um sistema exija alto desempenho e segurança. Se tais características forem importantes requisitos do sistema, deve-se encontrar alguma solução intermediaria para a arquitetura. Uma maneira de solucionar essa questão é através do uso de diferentes estilos de arquitetura para diferentes partes do sistema. O autor afirma ainda que grandes sistemas raramente são compatíveis com um único modelo de arquitetura.

64 O Enfoque de Camadas Um modelo de software em camadas especifica o uso de três camadas lógicas, a saber: camada de apresentação, camada de processamento de aplicação (lógica de negócio) e camada de integração ou acesso. É importante ressaltar que a divisão em camadas é independente da divisão física dos objetos. As camadas são logicamente visualizadas de forma separada, de maneira que uma camada não esteja estritamente acoplada com a camada adjacente. Desta forma, o sistema é representado em uma pilha de camadas. camadas. Figura 17 As três camadas lógicas de um software em camadas. (Adaptado de Sommerville, 2003, p. 208) A figura 17 mostra a divisão entre A cada camada é atribuída uma responsabilidade distinta ou única no sistema. A camada de apresentação é responsável pela interação com o usuário. Os componentes da interface gráfica residem nesta camada. A camada de aplicação, também conhecida como camada de negócios, determina de que maneira os dados serão utilizados. Nesta camada encontram-se as regras de negocio. Por fim, a camada de integração ou camada de dados tem a responsabilidade de manter os dados da aplicação, nela reside o banco de dados que fornece toda a informação

65 64 necessária para o funcionamento da aplicação de negócios. De acordo com Bezerra (2002) um software em três camadas tem como vantagem um maior grau de reutilização dos objetos implementados e a facilidade na manutenção destes, de maneira que esses softwares possam ser facilmente estendidos. O principio básico a ser seguido é que as camadas mais altas devem depender das camadas mais baixas e não o contrário. O sistema deve funcionar de maneira que os componentes executados em cada camada, possam ser alterados e não gerem prejuízos para o sistema como todo. Desse modo, as atualizações e correções devem ocorrer sem prejudicar as demais camadas. Como exemplo, toda a interface com o usuário pode ser alterada sem comprometer as regras de negócios. 4.2 O Padrão MVC Model View Controller (MVC) é um padrão arquitetural utilizado em engenharia de software, que divide uma aplicação interativa em três componentes. É utilizado de forma bem sucedida para desacoplar a interface com o usuário das regras de negócio e dados do sistema. Os três componentes são: o modelo, a visão ou visualização e o controlador. Presmam (2006), afirma que o MVC é na verdade um padrão arquitetural desenvolvido na década de 80 para o ambiente smaltalk, porém pode ser usado para qualquer aplicação interativa e atualmente ganhou grande visibilidade em aplicações web. A figura a seguir detalha o funcionamento do MVC.

66 65 Figura 18 O funcionamento do padrão MVC. (Adaptado de Presman, 2006, p.443) O modelo contém o núcleo das funcionalidades, regras de negocio e de dados. A visualização é responsável pela interação gráfica com o usuário. É a apresentação da aplicação. Em uma aplicação Java pode ser uma interface Swing ou uma interface web. O controlador gerencia as requisições do usuário. Ele se encontra entre a visualização e o modelo e, dependendo daquilo que o usuário faz, criará e modificará o modelo. Ao criar esses três componentes, as responsabilidades da aplicação são divididas, sendo a melhor maneira de trabalhar com aplicações complexas. A implementação do MVC pode agregar vantagens como: reaproveitamento de código, facilidade de manutenção da aplicação, integração de equipes e/ou divisão de tarefas, camada de persistência independente e facilidade na alteração da interface da aplicação.

67 Servlets e Java Server Pages De acordo com Todd e Szolkowski (2003), Servlet é um pequeno programa em Java que pode ser executado na plataforma web. Estes programas são armazenados em um servidor web e a partir deste, recebem e respondem requisições de clientes através do protocolo HTTP, o HyperText Transfer Protocol. Atualmente, quando se refere à construção de aplicações web dinâmicas, os Servlets se tornaram uma escolha popular, pois fornecem vantagens comuns à linguagem Java, como portabilidade, performance e reusabilidade. Além disso, os Servles acessam todas as APIs do Java. Java Server Pages, mais conhecida como JSP, é uma tecnologia que permite servir conteúdo dinâmico em uma aplicação web. JSP é uma extensão da tecnologia Servlet. Segundo Todd e Szolkowski (2003) através de páginas JSPs, é possível por exemplo, criar e manipular arquivos XML ou mesmo gerar conteúdo mais avançado, como imagens dinâmicas e documentos PDF. Uma JSP permite a mistura de tags HTML, tags de JSP e código Java em um único arquivo. De maneira prática, os Sevlets e JSPs são especificações da plataforma JEE, que será abordada adiante. Ambos são utilizados para prover conteúdo dinâmico em aplicações web, utilizando a linguagem Java. 4.4 O Framework Struts 2 De acordo com Alur, Crupi e Malks (2004), o framework Struts foi desenvolvido por Craig McClanahan e doado, em maio de 2002, à Apache Foundadtion. É um framework free open-source, ou seja, possui código aberto. Ele é utilizado para construir aplicações web em Java, que utilizam o padrão MVC, pois fornece uma série de recursos tais como: Um Servlet controlador. Uma classe action com algumas descrições. Esta pode ser estendida para subclasses, fornecendo classes que chamam a lógica de negócio. Biblioteca de tags para facilitar a construção de páginas web dinâmicas (JSPs).

68 67 O framework Struts pertence à camada de apresentação, no entanto, fornece componentes para implementação do controle da aplicação. Desta forma, ele é responsável pelo gerenciamento de ação e visualização. O gerenciamento de ação refere-se à localização e ao roteamento de ações especificas que servirão a uma solicitação, enquanto o gerenciamento de visualização refere-se à localização e distribuição para a visualização adequada. A figura a seguir representa de maneira simplificada o funcionamento do framework Struts2. Figura 19 Framework Struts2. (Fonte: Roughley, 2006, p.11) No Struts2, o FilterDispatcher bem como os Interceptors, constituem a implementação do controlador, que recebe e delega requisições. As actions, que são estendidas da classe ActionSupport, manipulam as classes de negócio (modelo). Por fim, as páginas JSPs são responsáveis pela apresentação do conteúdo dinâmico. São necessários dois arquivos xml para configuração. O arquivo web.xml, que é um arquivo necessário em qualquer aplicação web, contém as informações de configuração para a aplicação, como por exemplo, definição do controlador e definição da página inicial. O arquivo struts.xml é responsável pelo mapeamento das ações. Cada requisição do usuário é tratada como uma ação. Existe ainda a

69 68 possibilidade de utilizar um terceiro arquivo, o struts.properties, responsável por configurações de propriedades. Como visto, o Struts2 encapsula toda a lógica das requisições e resposta. O desenvolvedor modifica apenas o arquivo struts.xml, cria as classes actions derivadas da classe ActionSupport e desenvolve as páginas JSPs com o auxilio das tags do Struts2. Os passos de uma requisição podem ser resumidos da seguinte forma: 1. Usuário envia requisição 2. O FilterDispatcher analisa a requisição e determina a ação. 3. Interceptors são aplicados: Interceptors são configurados para aplicar funcionalidades comuns tais como validação, upload de arquivos, etc. 4. Execução da ação: o método relativo à ação é executado. 5. A saída é gerada 6. Ocorre o retorno da requisição 7. O resultado é exibido para o usuário O framework Struts2 centraliza todas as requisições e as respostas em um único ponto. O uso deste framework resulta em uma série de benefícios para o desenvolvedor, os principais são o encapsulamento da lógica do modelo MVC e a redução do tempo de desenvolvimento e consequentemente nos custo do projeto. 4.5 Java Enterprise Edition (JEE) Para implementação da arquitetura, uma vez que se trata de uma aplicação web desenvolvida na linguagem Java, optou-se pela plataforma JEE. Essa plataforma é ligada ao desenvolvimento de aplicações multicamadas e organizada em componentes modularizados. Java Enterprise Edition oferece uma série de especificações e APIs, cada uma com funcionalidades distintas. Dentre estas, podese citar os Sevlets e JSPs utilizados nessa pesquisa e já comentados anteriormente.

70 Padrões de Projeto Os design patterns ou padrões de projeto são soluções de projetos já aplicadas em um problema recorrente e que mostraram resultado satisfatório, por esta razão, os padrões se referem à comunicação de problemas e soluções. Alur, Crupi e Malks (2004), afirmam que esses padrões foram popularizados através da obra Design Patterns: Elements of Reusable Object-Oriented Software, de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (também conhecidos como Gang of Four Gof, ou gangue dos quatro). Padrões de projeto apresentam a essência de uma solução de projeto para problemas recorrentes em engenharia de software. Como definido na literatura, um padrão nomeia, abstrai e identifica aspectos-chave de uma estrutura de projeto comum. Padrões nos ajudam a construir sistemas de software seguindo bons princípios de OO, como alta coesão e baixo acoplamento, resultando em sistemas mais flexíveis e de mais fácil manutenção. (GAZOLA & MARQUES, 2009, p.50) Sommerville (2003) caracteriza padrão como uma descrição do problema e a essência de sua solução, de modo que essa solução possa ser utilizada em diversos casos. O padrão não é uma especificação detalhada, pode-se pensar que um padrão é uma descrição de conhecimentos e experiências acumuladas. Ainda segundo o autor, os padrões de projeto têm estado inevitavelmente associados com os projetos baseados na orientação a objetos. De acordo com Alur, Crupi e Malks (2004), o catalogo de padrões JEE inclui atualmente 21 padrões. Cada padrão é classificado dentro de uma das três camadas de arquitetura lógica: camada de apresentação, camada de negócios e camada de integração. Para o desenvolvimento da aplicação SIGECOMP, utilizouse os padrões Context Object e Front Controller (implementados pelo framework Struts2), da camada de apresentação; Business Object, da camada de negócios e Data Acess Object, da camada de integração. A figura a seguir, mostra a divisão em camadas aplicada à plataforma JEE, que foi utilizada na arquitetura do sistema SIGECOMP (Figura 16).

71 70 Camada de Apresentação Servlets, JSPs e outros elementos de interface com o usuário Interação com o usuário, criação de conteúdo, formato e entrega Camada de Negócios Business Object e outros objetos de negócio Lógica de negócios Camada de Integração JDBC, dados Acesso aos dados O Catálogo de Padrões JEE lida com estas camadas Figura 20 Enfoque em camadas. (Adaptado de Alur, Crupi e Malks, 2004, p.102) Nesta plataforma, observa-se que a camada de apresentação encapsula toda a lógica de representação exigida para servir os clientes que acessam o sistema. Ela intercepta as solicitações dos clientes, controla o acesso a serviços de negócios, constrói as respostas e entrega aos clientes. As classes de fronteira são encontradas aqui. Os Servlets e JSPs também residem nessa camada, é importante ressaltar que ambos não são elementos de interface com o usuário propriamente ditos, mas produzem esse elementos. Os padrões de projeto utilizado aqui foram: Context Object: seu principal objetivo é compartilhar as informações do sistema de um modo independente de camada, melhorando a capacidade de reutilização e manutenção da aplicação. Este padrão é implementado através de uma classe POJO, que uma vez criado um objeto desta classe, seu estado será compartilhado por toda a aplicação. Desta maneira, o uso deste padrão possibilita um melhor desacoplamento entre as camadas. Front Controller: fornece um ponto de entrada centralizado para tratar as solicitações. Centralizando a lógica de controle, esse design pattern também ajuda a

72 71 reduzir a quantidade de lógica de programação embutida diretamente nas vizualizações. Neste trabalho, o padrão Front Controller foi implementado através do uso do framework Struts2. Problema: você deseja um ponto de acesso centralizado para o tratamento da solicitação da camada de apresentação. [...] Solução: Use um Front Controller como o ponto inicial de contato para tratar todas as solicitações relacionadas. O Front Controller centraliza a lógica de controle, a qual, de outro modo, poderia ser duplicada, e gerencia as atividades de tratamento de solicitações principais. (ALUR, CRUPI & MALKS, 2004, p.143) Já a camada de negócios fornece os serviços de negócios necessários aos clientes das aplicações. Essa camada contém a lógica de negócios, logo, o processamento de negócios para a aplicação, está centralizado nela. Aqui foi utilizado o padrão Business Object descrito a seguir: Business Object: esse padrão é utilizado para separar a lógica de persistência da lógica de negocio. Estes objetos encapsulam e gerenciam os dados de negocio e ainda permitem que o armazenamento e recuperação dos dados sejam delegados para um outro objeto de persistência, por exemplo. Problema: você tem um modelo de domínio conceitual com lógica de negócios e relacionamentos.[...] Solução: use Business Objects para separar os dados e a lógica de negócios usando um modelo de objeto. (ALUR, CRUPI & MALKS, 2004, p.334) Por fim, a camada de integração contém o acesso aos dados de negócios e recursos externos como sistemas de integração de comércio eletrônico entre empresas, serviços de autorização de cartões de credito, entre outros. O Data Access Object foi o padrão utilizado nessa camada. Data Access Object: esse padrão consiste em abstrair o mecanismo de persistência utilizado na aplicação. O uso deste padrão será discutido no capítulo de persistência. É importante ressaltar que os padrões de projeto não são de uso exclusivo da plataforma JEE. Padrões de projeto são amplamente utilizados no

73 72 desenvolvimento de softwares, e muitos são independentes da plataforma ou linguagem de programação a ser utilizada. Pode-se citar o DAO, que foi catalogado na especificação JEE e também pode ser visto em aplicações desenvolvidas em linguagem PHP, por exemplo. 4.7 Contêiner Web e Aplicações Web Todd e Szolkowski (2003), afirmam que o contêiner web é o local onde as aplicações Web baseadas em Servlets e JSPs são hospedadas. Ele também hospeda toda a lógica de apresentação de uma aplicação JEE baseada na Web. Além disso, o contêiner é capaz de entregar outros formatos de dados como HTML, imagens gráficas e dados XML para clientes. Neste trabalho foi utilizado o contêiner Web gratuito da Apache, o TomCat. Ele tem a capacidade de atuar também como servidor web, ou pode funcionar integrado a um servidor web dedicado como o Apache. Tanto Servlets como JSPs precisam estar em um contêiner web. Nele, ao ser processada, uma JSP torna-se um Servlet. A seguir, é apresentada uma estrutura de pastas predefinida para uma aplicação web. Figura 21 A estrutura de uma aplicação Web. (Adaptado de Todd e Szolkowski, 2003, p.90)

74 73 Observa-se que a pasta raiz é o primeiro nível de uma aplicação web. A pasta WEB-INF contém informações de configuração como o arquivo web.xml, o diretório de lib, onde encontram-se as bibliotecas utilizadas pela aplicação e o diretório onde ficam as classes da aplicação. A página index e os diretórios de conteúdo (HTML, JSP, entre outros), podem ser distribuídos no mesmo nível da pasta WEB-INF. 4.8 Arquitetura e Projeto do Sistema SIGECOMP Como descrito anteriormente, para o projeto de arquitetura do sistema web proposto, foram utilizados o padrão MVC e a plataforma JEE juntamente com alguns padrões de projeto. A figura 22 ilustra como ficou definida a arquitetura do aplicativo SIGECOMP. Figura 22 Arquitetura utilizada no aplicativo SIGECOMP.

75 74 Desta forma, as classes de fronteira são representadas pelas páginas JSPs que têm sua interface gráfica configurada por arquivos CSS. Essas classes têm a responsabilidade de interagir com o usuário do sistema, exibindo as funcionalidades do aplicativo e os resultados das solicitações. As classes de controle foram implementadas através das classes Action. Existe ainda, um controlador central implementado pelo framework Struts2. Todas as requisições do usuário passam por ele. Através do mapeamento das ações no arquivo struts.xml, esse controlador reconhece quem deve executar determinada solicitação. A solicitação é então delegada para uma classe Action, que é uma classe extendida da classe ActionSupport contida neste framework. Desta maneira, a classe Action tem o papel de ser um mini-controlador de um caso de uso enquanto que nas classes BO ficam as regras de negócio, o que permite um melhor desacoplamento entre as camadas. Para as classes de entidade têm-se as classes DAO e Entity, responsáveis pelo mapeamento objeto relacional e persistência dos dados. O acesso aos dados foi implementado com a utilização do framework Hibernate3. Para cada caso de uso implementado, tem-se pelo menos duas páginas JSPs, uma classe Action, uma classe BO, uma classe DAO e uma classe Entity. E como mencionado existe um controlador central que faz o roteamento das requisições e respostas. Isso será mostrado nos itens seguintes, através do diagrama de pacotes, dos diagramas de classe de projeto e diagramas de seqüência de projeto, especificados pela UML Diagrama de Pacotes O diagrama de pacotes é um dos diagramas estruturais que fazem parte da UML. Guedes (2005) afirma que o principal objetivo desse diagrama é representar subsistemas ou sub-modulos englobados por um sistema de forma a determinar as partes que o compõem. Pode ser utilizado também para auxiliar a demonstrar a arquitetura de um sistema. Na figura 23, é mostrado o diagrama de pacotes do sistema SIGECOMP.

76 75 Figura 23 Diagrama de pacotes do software SIGECOMP Diagrama de Classes de Projeto O diagrama de classe de projeto ilustra as especificações para classes de software e interfaces de uma aplicação. Através deste diagrama é possível especificar as classes que devem ser implementadas, quais são seus atributos e métodos. É possível também verificar o relacionamento entre as classes, a visibilitade dos atributos e métodos, bem como os parâmetros e tipo de retorno de um método. A seguir, são mostrados por caso de uso, alguns diagramas de classe de projeto do sistema SIGECOMP.

77 76 Diagrama de Classes de Projeto do Caso de Uso Realizar Login A figura 24 apresenta o diagrama de classes do caso de uso realizar login, este é um diagram a nível de projeto e mostra quais classes foram implementadas para este caso de uso. Figura 24 Diagrama de classes de projeto do caso de uso Realizar Login. Observa-se que para cada atributo de visibilidade privada, têm-se dois métodos públicos para acesso, a saber, um método get e um método set. No entanto, alguns destes métodos foram omitidos na representação dos diagramas seguintes, por se tratarem de métodos básicos de uma aplicação Java.

78 77 Diagrama de Classes de Projeto do Caso de Uso Manter Dados de Funcionário A figura 25 apresenta o diagrama de classes do caso de manter dados de funcionário, este é um diagrama a nível de projeto e mostra quais classes foram implementadas para este caso de uso. Figura 25 Diagrama de classes de projeto do caso de uso Manter Dados de Funcionário.

79 78 Diagrama de Classes de Projeto do Caso de Uso Manter Dados de Fornecedor A figura 26 apresenta o diagrama de classes do caso de manter dados de fornecedor, este é um diagrama a nível de projeto e mostra quais classes foram implementadas para este caso de uso. Figura 26 Diagrama de classes de projeto do caso de uso Manter Dados de Fornecedor.

80 79 Diagrama de Classes de Projeto do Caso de Uso Manter Dados de Produto A figura 27 apresenta o diagrama de classes do caso de manter dados de produtos, este é um diagrama a nível de projeto e mostra quais classes foram implementadas para este caso de uso. Figura 27 Diagrama de classes de projeto do caso de uso Manter Dados de Produto.

81 Diagrama de Seqüência de Projeto Usados para a modelagem do comportamento dinâmico, os diagramas de seqüência de projetos oferecem uma visão panorâmica das interações, pois mostram uma visão do sistema em funcionamento. Um diagrama de seqüência é um diagrama de interação que dá ênfase à ordenação temporal de mensagens. Um diagrama de seqüência mostra conjunto de objetos e as mensagens enviadas e recebidas por esses objetos. Tipicamente os objetos são instâncias de classes. Use os diagramas de colaboração para ilustrar a visão dinâmica de um sistema. (BOOCH, RUMBAUGH & JACOBSON, 2000, p. 96). Apresentam-se a seguir, por caso de uso, alguns diagramas de seqüência de projeto do sistema SIGECOMP.

82 81 Diagrama de Sequência de Projeto do Caso de Uso Realizar Login A figura 28 mostra o diagrama de seqüência de projeto do caso de uso Realizar Login. É descrito neste diagrama as funções que o ator (funcionário) deve aplicar ao realizar login no sistema, após o preenchimento dos campos solicitados, se estes forem válidos, o sistema exibe a tela principal do programa, se o funcionário for inválido ou inserir senha errada o sistema volta a exibir a tela inicial com mensagem de alerta. Figura 28 Diagrama de sequência de projeto do caso de uso Realizar Login.

83 82 Diagrama de Seqüência de Projeto do Caso de Uso Manter Dados de Funcionário A figura 29 mostra o diagrama de seqüência de projeto do caso de uso Manter Dados de Funcionário, é descrito neste diagrama as funções que o ator (funcionário) deve exercer para Manter dados de Funcionário. Figura 29 Diagrama de seqüência de projeto do caso de uso Manter Dados de Funcionário.

84 83 Diagrama de Seqüência de Projeto do Caso de Uso Manter Dados de Fornecedor A figura 30 mostra o diagrama de seqüência de projeto do caso de uso Manter Dados de Fornecedor, é descrito neste diagrama as funções que o ator (funcionário) deve exercer para Manter dados de Fornecedor. Figura 30 Diagrama de seqüência de projeto do caso de uso Manter Dados de Fornecedor.

85 84 Diagrama de Seqüência de Projeto do Caso de Uso Manter Dados de Produto A figura 31 mostra o diagrama de seqüência de projeto do caso de uso Manter Dados de Produtos, é descrito neste diagrama as funções que o ator (funcionário) deve exercer para Manter dados do Produto. Figura 31 Diagrama de seqüência de projeto do caso de uso Manter Dados de Produto.

86 Como o SIGECOMP foi Implementado A intenção deste tópico é mostrar como foi implementado o software, mostrando seus principais arquivos de configuração como o web.xml e o struts.xml. Neste tópico o caso de uso manter dados de funcionário é descrito passo a passo, evidenciando partes do código implementado. É importante ressaltar que até o momento foram implementados os seguintes casos de uso: Realizar Login, Manter Dados de Cliente Manter Dados de Funcionário, Manter Dados de Fornecedor e Manter Dados de Produto. Para o desenvolvimento do código, utilizou-se a ferramenta IDE Eclipse. Esta é uma ferramenta de ambiente integrado, bastante flexível e ainda possui licença baseada nas especificações open source. A figura 32 mostra a estrutura de diretórios definida para implementação do SIGECOMP. Figura 32 Estrutura do SIGECOMP.

87 86 A figura 33 mostra o arquivo web.xml. Como já foi mencionado, este é um arquivo comum a qualquer aplicação web. Neste projeto ele foi utilizado para definição do filtro web a ser utilizado, esse filtro é o Struts2 e foi definido pela tag <filter>. Em seguida, com o uso da tag <filter-mapping> foram definidas quais as páginas o Struts2 deve controlar; /* representa todas as páginas do diretório raiz. Aqui também foi definida qual a página inicial do sistema, a index.jsp, configurada pela tag <welcome-file-list>. Finalmente, foram mapeados alguns erros específicos através da marcação <error-page>. <?xml version="1.0" encoding="utf-8"?> <web-app id="webapp_id" version="2.4" xmlns=" mlns:xsi=" xsi:schemalocation=" <display-name>sigecomp</display-name> <!-- Controlador Central MVC implementado com o uso do framework Struts --> <filter> <filter-name>struts2</filter-name> <filter-class> org.apache.struts2.dispatcher.filterdispatcher </filter-class> </filter> <!-- Aqui encontram-se as urls que o filtro deve controlar --> <filter-mapping> <filter-name>struts2</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <!-- Mapeamento da página principal (index) --> <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> <!-- Mapeamento da páginas para tratativa de erro --> <error-page> <error-code>404</error-code> <location>/pagenotfound.jsp</location> </error-page> <error-page> <exception-type>java.lang.exception</exception-type> <location>/error.jsp</location> </error-page> </web-app> Figura 33 Arquivo de configuração web.xml. A figura 34 mostra o parte do código contido no arquivo struts.xml.

88 87 Neste arquivo são mapeadas todas as ações da aplicação. É através deste mapeamento que o controlador central gerencia e executa o roteamento das ações. Cada funcionalidade do sistema representa uma ação que deve ser mapeada. Tais ações são disparadas ao controlador através das solicitações do usuário, que são feitas através de um navegador web. Basicamente, para cada ação mapeada pela tag <action> atribui-se um nome. É necessário especificar a classe relativa à ação (sempre são as classes Action do projeto). Se a classe Action possuir mais de um método, é necessário especificar o nome do método que se pretende utilizar. Dentro da ação, é necessário configurar o(s) resultado(s) da mesma. O resultado, mapeado pela tag <result> pode ser o direcionamento para uma página ou mesmo a chamada de outra ação. <!DOCTYPE struts PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN" " <struts> <package name="default" extends="struts-default"> <!-- mapeamento das ações --> [...] <!-- CSU ManterDadosDeFuncionarios --> <action name="gettodosfuncionarios" method="gettodosfuncionarios" class="br.com.sigecomp.action.funcionarioaction"> <result name="success">/jsp/funcionario.jsp</result> </action> <action name="formfuncionario" method="trazparaincluiroualterar" class="br.com.sigecomp.action.funcionarioaction"> <result name="success">/jsp/funcionarioform.jsp</result> </action> <action name="dadosfuncionario" method="incluiroualterar" class="br.com.sigecomp.action.funcionarioaction"> <result name="success" type="redirect-action"> gettodosfuncionarios </result> <result name="input">/jsp/funcionarioform.jsp</result> </action> <action name="excluirfuncionario" method="excluirfuncionario" class="br.com.sigecomp.action.funcionarioaction"> <result name="success" type="redirect-action"> gettodosfuncionarios </result> </action> [ ] </package> </struts> Figura 34 Parte do arquivo struts.xml.

89 88 A figura 35 mostra parte do código contido na página funcionario.jsp. Está página é responsável pela exibição da relação de funcionários cadastrados e permite ao usuário do sistema acesso a incluir novos funcionários, alterar dados de um funcionário ou mesmo excluir um funcionário cadastrado. Um ponto forte utilizado aqui, foi o uso da tag library do Struts2, que encapsula o código, tornando-o mais simples e de fácil manutenção. <%@ taglib prefix="s" uri="/struts-tags"%> [ ] <s:url id="incluirfuncionario" action="formfuncionario.action"/> <s:a href="%{incluirfuncionario}">incluir Funcionário</s:a> [ ] <h1><s:text name="listagem de Funcionários"/></h1> [ ] <table align=center class="borderall"> <tr> <th><s:text name="nome"/></th> <th><s:text name="cpf"/></th> <th><s:text name="rg"/></th> <th><s:text name="d. Admissão"/></th> <th> </th> </tr> <s:iterator value="funcionarios" status="status"> <tr class="<s:if test="#status.even">even</s:if><s:else>odd</s:else>"> <td class="nowrap"><s:property value="funnome"/></td> <td class="nowrap"><s:property value="funcpf"/></td> <td class="nowrap"><s:property value="funrg"/></td> <td class="nowrap"><s:property value="fundataadmissao"/></td> <td class="nowrap"><s:url id="alterar" action="formfuncionario.action"/> <s:param name="funentity.funcodigo" value="funcodigo"/> </s:url> <s:a href="%{alterar}">alterar</s:a> <s:url id="excluir" action="excluirfuncionario"> <s:param name="funentity.funcodigo" value="funcodigo"/> </s:url> <s:a href="%{excluir}">excluir</s:a> </td> </tr> </s:iterator> </table> [ ] Figura 35 Parte do código da página funcionario.jsp. A primeira linha do código mostra a declaração para utilização das tags do struts, nesse caso ficou definido que todas as tags são precedidas pela letra s. A variável funentity utilizada neste código está declarada na classe FuncionarioAction, nesta classe constam também os métodos get e set dessa variavel, o struts trabalha diretamente com esses métodos.

90 89 A figura 36, mostra o arquivo formfuncionario.jsp. Este arquivo segue o mesmo padrão do arquivo anterior. Ele é responsável por apresentar o formulário relativo aos dados de funcionários. É utilizado tanto para o cadastro quanto para alteração de dados. A ação neste caso é acionada ao clicar no botão de envio do formulário. [...] <s:form action="dadosfuncionario" method="post"> <table align="center" class="borderall"> <tr> <td class="tdlabel" ><s:text name="nome"/></td> <td><s:textfield name="funentity.funnome" size="30"/></td> </tr> <tr> <td class="tdlabel"><s:text name="cpf"/></td> <td><s:textfield name="funentity.funcpf" size="30"/></td> </tr> <tr><td class="tdlabel"><s:text name="rg"/></td> <td><s:textfield name="funentity.funrg" size="20"/></td> </tr> <tr><td class="tdlabel"><s:text name="carteira Trab"/></td> <td><s:textfield name="funentity.funcarteiratrabalho" size="30"/></td> </tr> <tr> <td class="tdlabel"><s:text name="pis"/></td> <td><s:textfield name="funentity.funpis" size="30"/></td> </tr> <tr><td class="tdlabel"><s:text name="data Admissão"/></td> <td><s:textfield name="funentity.fundataadmissao" size="20"/></td> </tr> [...] <tr> <td><s:text name="cep"/></td> <td><s:textfield name="funentity.funcep" size="30"/></td> </tr> <tr> <s:hidden name="funentity.funcodigo"/> </tr> </table> <br/> <table> <tr> <td><s:submit key="ok" cssclass="butstnd"/></td> <td><s:reset key="cancelar" cssclass="butstnd"/></td> <tr> </table> </s:form> Figura 36 Parte do código da página funcionarioform.jsp.

91 90 A figura 37, representa partes do código da classe FuncionarioAction. Essa é uma classe extendida da classe ActionSupport do Struts2. Nela constam os métodos mapeados no arquivo struts.xml e que são chamados nas páginas JSPs. É importante ressaltar que as variáveis criadas abaixo, possuem métodos get e set, pois é através deles que Struts2 faz a interação com as páginas JSPs. No método validationsuccessful() foi implementada a tratativa para cadastro de novos funcionários. package br.com.sigecomp.action; import com.opensymphony.xwork2.actionsupport; import java.util.*; import br.com.sigecomp.bo.funcionariobo; import br.com.sigecomp.entity.funcionarioentity; public class FuncionarioAction extends ActionSupport { private FuncionarioBO funbo = new FuncionarioBO(); private FuncionarioEntity funentity; private List<FuncionarioEntity> funcionarios; private boolean validationsuccessful() { if (funentity.getfunnome() == null funentity.getfunnome().trim().length() < 1) addactionmessage("o campo Nome é obrigatório"); if (funentity.getfuncpf()== null funentity.getfuncpf().trim().length() < 1) addactionmessage("o campo CPF é obrigatório"); if (funentity.getfunrg()== null funentity.getfunrg().trim().length() < 1) addactionmessage("o campo RG é obrigatório"); if (funentity.getfuncarteiratrabalho()== null) addactionmessage("o campo Carteira de trabalho é obrigatório"); if (funentity.getdataadmissao()== null) addactionmessage("o campo Data de admissão é obrigatório"); if (this.hasactionmessages()) return false; else return true; } [...] Figura 37 Parte do código da classe FuncionarioAction. A figura 38 apresenta outros métodos contidos na classe FuncionarioAction. Todos os métodos apresentados retornam uma String que é configurada no arquivo struts.xml. É através deste mapeamento que ocorrem os direcionamentos para outros métodos ou páginas JSPs.

92 91 [...] public String gettodosfuncionarios() { funcionarios = funbo.gettodosfuncionarios(); return "success"; } public String trazparaincluiroualterar() { if (funentity!= null && funentity.getfuncodigo()!= null) funentity = funbo.getfuncionario(funentity.getfuncodigo()); return "success"; } public String incluiroualterar() { if (!validationsuccessful()) return "input"; else { if (funentity.getfuncodigo() == null) funbo.incluirfuncionario(funentity); else funbo.alterarfuncionario(funentity); } return "success"; } public String excluirfuncionario() { funbo.excluirfuncionario(funentity.getfuncodigo()); return "success"; } [ ] Figura 38 Outros métodos da classe FuncionarioAction. Nesta classe os métodos trazparaincluiroualterar e incluiroualterar são utilizados tanto para inclusão de novos funcionários, como para alteração dos dados de um funcionário. O primeiro método é responsável por apresentar o formulário de inclusão/alteração. O segundo é responsável por efetuar a inclusão ou a alteração. A validação é realizada pelo campo código do funcionário. Todos estes métodos delegam a ação para outro método, contido nas classes BO.

93 92 A figura 39 mostra o código contido na classe FuncionarioBO. Esta classe possui apenas um atributo chamado dao. Este é utilizado para acessar os métodos de persistência contidos na classe FuncionarioDAO. package br.com.sigecomp.bo; import java.util.list; import br.com.sigecomp.dao.funcionariodao; import br.com.sigecomp.dao.funcionariohibernatedao; import br.com.sigecomp.entity.funcionarioentity; public class FuncionarioBO { private FuncionarioDAO dao; public FuncionarioBO() { this.dao = new FuncionarioHibernateDAO(); } public List gettodosfuncionarios() { return dao.gettodosfuncionarios(); } public void incluirfuncionario(funcionarioentity fun) { dao.incluirfuncionario(fun); } public void alterarfuncionario(funcionarioentity fun) { dao.alterarfuncionario(fun); } public void excluirfuncionario(integer codigo) { dao.excluirfuncionario(codigo); } public FuncionarioEntity getfuncionario(integer codigo) { return dao.getfuncionario(codigo); } } Figura 39 Código da classe FuncionarioBO. A figura 40 apresenta o código da classe FuncionarioDAO. Essa classe é uma interface e define quais métodos devem ser implementados na classe FuncionarioHibernateDAO.

94 93 package br.com.sigecomp.dao; import java.util.list; import br.com.sigecomp.entity.funcionarioentity; public interface FuncionarioDAO { public List gettodosfuncionarios(); public FuncionarioEntity getfuncionario(integer codigo); public void alterarfuncionario(funcionarioentity fun); public void incluirfuncionario(funcionarioentity fun); public void excluirfuncionario(integer codigo); } Figura 40 Código da classe FuncionarioDAO. A figura 41 apresenta parte do código da classe FuncionarioHibernateDAO. Essa classe implementa a interface definada na classe FuncionarioDAO. package br.com.sigecomp.dao; import java.util.list; import org.hibernate.query; import org.hibernate.session; import org.hibernate.transaction; import br.com.sigecomp.entity.funcionarioentity; public class FuncionarioHibernateDAO implements FuncionarioDAO { private List<FuncionarioEntity> funlist; private FuncionarioEntity fun; private Session session = HibernateUtil.getSessionFactory().getCurrentSession(); public List gettodosfuncionarios() { session = HibernateUtil.getSessionFactory().openSession(); try { session.begintransaction(); funlist = session.createquery("from FuncionarioEntity").list(); return funlist;} } public void incluirfuncionario(funcionarioentity fun) { session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = null; try { tx = session.begintransaction(); session.save(fun); tx.commit(); } catch (RuntimeException e) { if (tx!= null) tx.rollback(); throw e;} } [ ] Figura 41 Parte do código da classe FuncionarioHibernateDAO.

95 94 O uso do framework hibernate3 permite o encapsulamento da persistência dos dados. Utilizou-se a linguagem Hibernate Query Language (HQL). A figura 42 mostra parte do código da classe FuncionarioEntity, responsável pelo mapeamento objeto relacionarl. Como é possível observar, utilizou-se a anotações do framework Hibernate3. Esse código foi gerado automaticamente pelo Eclipse com o uso do Hibernate Code Generation. package br.com.sigecomp.entity; //Generated 29/05/ :29:56 by Hibernate Tools beta8 import java.util.date; import javax.persistence.column; import javax.persistence.entity; import javax.persistence.generatedvalue; import javax.persistence.generationtype; import javax.persistence.id; import javax.persistence.table; import javax.persistence.temporal; import javax.persistence.temporaltype; /** * Funcionario generated by = "funcionario", catalog = "piramidebd", uniqueconstraints = {}) public class FuncionarioEntity { = = "fun_codigo", unique = true, nullable = false, insertable = true, updatable = false) private Integer = "fun_nome", unique = false, nullable = true, insertable = true, updatable = true, length = 40) private String = "fun_cpf", unique = false, nullable = true, insertable = true, updatable = true, length = 11) private String funcpf; [ ] public Integer getfuncodigo() {return this.funcodigo;} public void setfuncodigo(integer funcodigo) {this.funcodigo = funcodigo;} [ ] Figura 42 Parte do código da classe FuncionarioHibernateDAO.

96 95 A figura 43 mostra a interface gráfica do sistema. As funcionalidades relativas ao controle de funcionário é mostrada na página funcionario.jsp. Os links incluir funcionário, alterar e excluir, como descrito anteriormente, são repsonsáveis pela chamada dos métodos da classe FuncionarioAtion. Tais métodos estão mapeados no arquivo struts.xml. Figura 43 Interface gráfica do caso de uso manter dados de funcionário.

97 96 5 PERSISTÊNCIA DE DADOS A persistência dos dados refere-se em converter os dados voláteis utilizados no sistema em dados não voláteis, inserindo-os em um banco de dados, por exemplo. Neste capítulo é apresentado o Diagrama Entidade Relacionamento, muito conhecido como DER. Faz parte deste tópico também, apresentar como foi feito o mapeamento objeto relacional e a persistência dos dados com o auxilio do framework Hibernate Padrão de Projeto DAO Problema: você deseja encapsular o acesso e a manipulação de dados em uma camada separada. [...] Solução: use um Data Access Object para abstrair e encapsular todo o acesso ao armazenamento persistente. O DAO gerencia a conexão com a fonte de dados para obter e armazenar dados. (ALUR, CRUPI & MALKS, 2004, p.254) O Data Access Object, ou simplesmente DAO, é um dos padrões de projeto utilizados para o mapeamento objeto relacional com a função de persistir objetos em uma base de dados. O DAO permite abstrair e encapsular todo o acesso a uma fonte de persistência e gerenciar automaticamente a conexão com esta fonte de dados para obter e armazenar os dados. Ele ainda implementa o mecanismo de acesso necessário para trabalhar com a fonte de dados. Independente do tipo de fonte de dados utilizado, o DAO sempre fornece uma API uniforme para seus clientes. Fazendo uso desse design pattern, é possível desacoplar a implementação do armazenamento do restante da aplicação. 5.2 Diagrama de Entidade e Relacionamento A figura 44 ilustra o modelo lógico do DER (Diagrama Entidade Relacionamento). Nele, representamos o projeto do banco de dados. As entidades representam coisas do mundo real que devem ser representadas no sistema. Os relacionamentos representam as diversas relações entre as entidades. A figura 45

98 97 mostra o DER de maneira física. Para o desenvolvimento do DER foi utilizado o software Platinum ErWin.

99 98 Figura 44 Diagrama de Entidade e Relacionamento modelo lógico.

100 99 Figura 45 Diagrama de Entidade e Relacionamento modelo físico.

101 Mapeamento Objeto Relacional Mapeamento Objeto relacional é uma técnica de desenvolvimento utilizada para reduzir a impedância da programação orientada aos objetos utilizando bancos de dados relacionais. As tabelas do banco de dados são representadas através de classes e os registros de cada tabela são representados como instâncias das classes correspondentes Mapeamento Objeto Relacional utilizando JDBC O Java Database Connectivity (JDBC) é o padrão da indústria para conectividade entre a linguagem de programação Java e uma vasta gama de bases de dados, entre as mais populares, pode-se citar Microsoft SQL Server, Oracle e MySQL. De acordo com Deitel (2006), os programas Java comunicam-se com bancos de dados e manipulam seus dados utilizando a API do JDBC. Através de um driver JDBC, os aplicativos Java podem se conectar a um banco de dados em um sistema gerenciador de banco de dados, e desta forma é permitido aos programadores manipular esse banco de dados utilizando a API do JDBC Mapeamento Objeto Relacional utilizando o Hibernate Persistência automática e transparente de objetos de um aplicativo Java para tabelas em um banco de dados relacional, utilizando metadados que descrevem o mapeamento entre os objetos e o banco de dados. Em essência, transforma dados de uma representação para a outra. (BAUER, Hibernate em ação, 2005) Neste projeto utilizou-se, para o mapeamento objeto relacional, o framework Hibernate da camada de integração. Trata-se de um framework escrito na linguagem Java, mas também é disponível em.net, com o nome NHibernate. O uso do Hibernate facilita o mapeamento dos atributos entre uma base tradicional de dados relacionais e o modelo objeto de uma aplicação. É importante ressaltar que o

102 101 Hibernate é um framework de código aberto, distribuído com a licença LGPL. Foi utilizado o Hibernate Annotations, que permite anotações (linguagem utilizada pelo framework Hibernate3) em classes POJO. Através da ferramenta IDE Eclipse, pode-se utilizar a engenharia reversa para mapear e gerar automaticamente as classes trabalhadas nessa pesquisa. Este processo facilitou bastante o desenvolvimento desta etapa do projeto. O arquivo hibernate configuration file permite configurar propriedades de acesso ao banco, tais como: localização do banco, usuário, senha e tabelas envolvidas. Na figura a seguir pode-se verificar o arquivo hibernate.cfg.xml, localizado na pasta src do projeto. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" " <! - tag raiz --> <hibernate-configuration> <session-factory> <! -tag para inserir a localização(url) da base de dados--> <property name="hibernate.connection.url"> jdbc:mysql://localhost:3306/piramidebd </property> <! - tag para declarar o usuário no banco de dados --> <property name="hibernate.connection.username">root</property> <! - tag para declarar a senha utilizada por este usuário --> <property name="hibernate.connection.password">root</property> <property name="hibernate.current_session_context_class">thread</property> <!--implementação do dialeto SQL específico do banco de dados a ser utilizado. Usado para identificar as particularidades do banco de dados --> <property name="hibernate.dialect"> org.hibernate.dialect.mysqldialect</property> <!-- nome da classe do driver JDBC do banco de dados que está sendo utilizado ---> <property name="hibernate.connection.driver_class">com.mysql.jdbc.driver</property> <!-- utilizado para definir se os SQL s gerados pelo Hibernate devem ou não ser exibidos --> <property name="show_sql">true</property> <!--Números máximo e mínimo de conexões no pool --> <property name="connection.pool_size">1</property> <!--para gerar as tabelas automaticamente <property name="hibernate.hbm2ddl.auto"> create </property> --> <!-- mapeamento das entidades --> <mapping class="br.com.papelaria.entity.loginentity" /> <mapping class="br.com.papelaria.entity.clienteentity" /> <mapping class="br.com.papelaria.entity.fornecedorentity" /> <mapping class="br.com.papelaria.entity.funcionarioentity" /> <mapping class="br.com.papelaria.entity.pessoafisicaentity" /> <mapping class="br.com.papelaria.entity.pessoajuridicaentity"/> <mapping class="br.com.papelaria.entity.representanteentity" /> <mapping class="br.com.papelaria.entity.produtoentity"/> </session-factory> </hibernate-configuration> Figura 46 Arquivo xml responsável pela configuração do Hibernate3 Utilizou-se dois tipos de classes para o mapeamento e persistência de

103 102 dados, cada qual com suas responsabilidades e atribuições. Para as classes de entidade atribuiu-se a responsabilidade de mapear os dados, enquanto as classes DAO ficaram responsáveis pela persistência dos dados. Classes de Entidade: os POJOS, que são as classes persistentes, são as nossas entidades. Nessa classe encontram-se os atributos, um construtor, os métodos de acesso getters and setters e as anotações do hibernate3. Dentre as mais Classes DAO: são utilizadas para persistir as entidades. Através do HibernateUtil pode-se realizar as transações (select, save, update, delete). Aqui encontram-se os métodos responsáveis por persistir os dados. A figura 47 mostra o detalhamento do processo realizado para mapear as tabelas do banco em classes Java. A classe é um POJO, que contém os atributos, construtor e métodos getters and setters. Nessa classe encontram-se as annotations do Hibernate Detalhe do Mapeamento Objeto Relacional Tabela do SGBD Classe LoginEntity Import javax.persistence.column; import javax.persistence.entity; import javax.persistence.id; = "login", catalog = "piramidebd", uniqueconstraints = {}) public class LoginEntity implements java.io.serializable (strategy = = "log_codigo") private int logcodigo = "log_usuario") private String = "log_senha") private String logsenha;... Figura 47 Detalhe do mapeamento objeto relacional.

104 103 6 PROJETO DE INTERFACE O projeto de interface é de importância relevante para o desenvolvimento de sistemas, pois a interface está diretamente ligada ao usuário do sistema. Caso a interface seja esteticamente desagradável ou de difícil navegabilidade, o usuário pode ter dificuldades em utilizar o software. As cores também devem ser usadas com equilíbrio, de maneira harmônica. Sommerville (2003, p. 278) afirma que: 6.1 Tecnologias utilizadas O bom projeto de interface com o usuário é fundamental para o sucesso de um sistema. Uma interface que é difícil de ser utilizada, na melhor das hipóteses, resultará em um alto nível de erros do usuário. Pior ainda, os usuários simplesmente se recusarão a utilizar o sistema de software, independentemente de sua funcionalidade. Se as informações forem apresentadas de maneira confusa ou enganosa, os usuários poderão se confundir com o significado dessas informações. Eles podem iniciar uma seqüência de ações que venham a corromper os dados ou mesmo a causar falhas catastróficas no sistema. Na área de desenvolvimento de softwares, quando se trata de aplicativos web, é possível encontrar uma grande diversidade de tecnologias e linguagens para o desenvolvimento da interface gráfica. Neste projeto utilizou-se Java Server Pages para geração das páginas dinâmicas. A configuração do layout ficou isolada através do uso de arquivos CSS (Cascading Style Sheets), de forma que todas as informações sobre formatações de fontes e tabelas ficaram em um único local. Desta maneira, é possível facilitar a manutenção do sistema, separando ainda mais o código de programação, do código utilizado para interface. A figura a seguir, apresenta a tela inicial do SIGECOMP

105 104 Figura 48 Tela inicial do sistema SIGECOMP. A figura abaixo mostra a tela de login. Nela pode-se visualizar a tratativa de erros ou ações indevidas por parte do usuário. Caso o usuário não entre com usuário e senha validos, uma mensagem é exibida. Figura 49 Tela de login do sistema SIGECOMP.