TCC Alberto Marcos

UNIO EDUCACIONAL MINAS GERAIS S/C LTDA FACULDADE DE CINCIAS APLICADAS DE MINAS
Autorizada pela Portaria no 577/2000 MEC, de 03/05/2000 BACHARELADO EM SISTEMAS DE INFORMAO
U
Uberlndia 2009
IM
ALBERTO DUMONT ALVES OLIVEIRA MARCOS ARAJO DA CUNHA
IN A
COMERCIAL DE PAPELARIA
SOFTWARE PARA GESTO
SOFTWARE PARA GESTO
IM N U
IN A
Uberlndia 2009
COMERCIAL DE PAPELARIA
Trabalho de Final de curso submetido UNIMINAS como parte dos requisitos para a obteno do grau de Bacharel em Sistemas de Informao.
Orientador: Prof. M.Sc. Francisco J. Muller
SOFTWARE PARA GESTO COMERCIAL DE PAPELARIA
IM
Banca Examinadora:
N U
Prof. M.Sc. Francisco Jos Muller (Orientador) Prof. Dr. Ktia Lopes Silva Prof. Esp. Carlos Henrique de Barros
IN A
Uberlndia 2009
Trabalho de Final de curso submetido UNIMINAS como parte dos requisitos para a obteno do grau de Bacharel em Sistemas de Informao.
Orientador: Prof. M.Sc. Francisco J. Muller
Uberlndia, 08 de Julho de 2009.
U
Dedicado a todos que contriburam direta ou indiretamente para a realizao deste projeto.
IM
IN A
AGRADECIMENTOS
A todos os professores do curso de Sistemas de Informao da UNIMINAS, em especial aos professores Ana Maria, Carlos Barros, Edson Angoti, Francisco Muller e Ktia Lopes, pela pacincia, ateno e pelo tempo dedicado nesse projeto. As famlias, pela confiana, compreenso e motivao. Aos amigos de sala e companheiros de jornada pelo constante apoio e sem os quais tambm no seria possvel a elaborao deste trabalho.
IM
IN A
RESUMO
Este trabalho tem por objetivo o desenvolvimento de um sistema de gesto comercial para a Papelaria Pirmide, uma micro empresa situada na cidade de Uberlndia. Atravs de algumas reunies com os envolvidos no projeto, pde-se conhecer melhor o universo que compe 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 orientao a objetos. Faz parte deste software, a implementao 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 atravs de seus principais diagramas, como o diagrama de casos de uso, o diagrama de classes e o diagrama de Seqncia. O sistema de gesto comercial de papelaria (SIGECOMP) foi desenvolvido seguindo o modelo de software em trs camadas. Utilizou-se o framework Struts2 para implementao do padro Model-View-Controller (MVC). Padres de projeto tambm foram aplicados. O mapeamento objeto relacional foi implementado com o uso do framework Hibernate. Este trabalho utilizou padres e tecnologias amplamente empregados em um ambiente de desenvolvimento de software profissional. O SIGECOMP foi desenvolvido parcialmente. Foram trabalho o levantamento e anlise de requisitos, a definio da arquitetura do
implementados vrios casos de uso, evidenciando a potencialidade desse projeto. Desta forma, este trabalho mostra que viavel a construo de sistemas para gesto comercial por meio dos artefatos apresentados. Palavras Chave: papelaria, gesto comercial, sistema web, engenharia de software,
UML, JSP, Java, JEE, MVC, Struts, padres de projeto.
IM
IN A
ABSTRACT
This work aims at developing a commercial management system for Stationery Pyramid, a small company located in Uberlndia 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 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-ViewController (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 architecture, implementation and approach to the use of current technologies such as
N
displayed. Keywords: stationery, business management, web system, software engineering, UML, JSP, Java, JEE, MVC, Struts, design patterns.
IM
IN A
LISTA DE FIGURAS
Figura 1 Papelaria Pirmide ...........................................................................................................18 Figura 2 Diagrama de casos de uso Papelaria Pirmide.................................................................29 Figura 3 Diagrama de classes de negcio do sistema SIGECOMP.................................................47 Figura 4 Esteretipo de uma classe de fronteira. ............................................................................49 Figura 5 Esteretipo de uma classe de controle. ............................................................................50 Figura 6 Esteretipo de uma classe de entidade. ...........................................................................50 Figura 7 Diagrama de seqncia de anlise do caso de uso Realizar Login. ..................................52 Figura 8 Diagrama de seqncia de anlise do caso de uso Manter Dados de Cliente ...................53 Figura 9 Diagrama de seqncia de anlise do caso de uso Manter Dados de Funcionrio............54 Figura 10 Diagrama de seqncia de anlise do caso de uso Manter Dados de Fornecedor ..........55 Figura 11 Diagrama de seqncia de anlise do caso de uso Manter Dados de Representante. ....56 Figura 12 Diagrama de seqncia de anlise do caso de uso Manter Dados de Produtos. .............57 Figura 13 Diagrama de seqncia de anlise do caso de uso Registrar Compra. ...........................58 Figura 14 Diagrama de seqncia de anlise do caso de uso Registrar Venda...............................59 Figura 15 Diagrama de seqncia de anlise do caso de uso Manter Contas a Pagar....................60 Figura 16 Diagrama de seqncia de anlise do caso de uso Manter Contas a Receber. ...............61 Figura 17 As trs camadas lgicas de um software em camadas. (Adaptado de Sommerville, 2003, p. 208) ..................................................................................................................63 Figura 18 O funcionamento do padro 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 aplicao 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. .....................................76 Figura 25 Diagrama de classes de projeto do caso de uso Manter Dados de Funcionrio...............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 sequncia de projeto do caso de uso Realizar Login..................................81 Figura 29 Diagrama de seqncia de projeto do caso de uso Manter Dados de Funcionrio. .........82 Figura 30 Diagrama de seqncia de projeto do caso de uso Manter Dados de Fornecedor...........83 Figura 31 Diagrama de seqncia de projeto do caso de uso Manter Dados de Produto. ...............84 Figura 32 Estrutura do SIGECOMP. ...............................................................................................85 Figura 33 Arquivo de configurao web.xml. ..................................................................................86 Figura 34 Parte do arquivo struts.xml. ............................................................................................87 Figura 35 Parte do cdigo da pgina funcionario.jsp.......................................................................88 Figura 36 Parte do cdigo da pgina funcionarioForm.jsp...............................................................89 Figura 37 Parte do cdigo da classe FuncionarioAction. .................................................................90 Figura 38 Outros mtodos da classe FuncionarioAction. ................................................................91 Figura 39 Cdigo da classe FuncionarioBO....................................................................................92 Figura 40 Cdigo da classe FuncionarioDAO. ................................................................................93 Figura 41 Parte do cdigo da classe FuncionarioHibernateDAO. ....................................................93 Figura 42 Parte do cdigo da classe FuncionarioHibernateDAO. ....................................................94 Figura 43 Interface grfica do caso de uso manter dados de funcionrio. .......................................95 Figura 44 Diagrama de Entidade e Relacionamento modelo lgico..............................................98 Figura 45 Diagrama de Entidade e Relacionamento modelo fsico...............................................99 Figura 46 Arquivo xml responsvel pela configurao do Hibernate3............................................101 Figura 47 Detalhe do mapeamento objeto relacional. ...................................................................102 Figura 48 Tela inicial do sistema SIGECOMP...............................................................................104 Figura 49 Tela de login do sistema SIGECOMP. ..........................................................................104 Figura 50 Tela com o menu principal do sistema SIGECOMP. .....................................................105 Figura 51 Diagrama de navegabilidade do caso de uso Realizar Login.........................................106
IM
IN A
LISTA DE QUADROS
IM
IN A
Quadro 1 Atividades tpicas de um processo de desenvolvimento de software ...............................12 Quadro 2 Requisitos funcionais e no funcionais............................................................................22 Quadro 3 Regras de Negcio. ........................................................................................................24 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 funcionrio.............................................36 Quadro 7 Documento de caso de uso Manter dados de fornecedor. ............................................37 Quadro 8 Documento de caso de uso Manter dados de representante. .......................................38 Quadro 9 Documento de caso de uso Manter dados de produtos. ...............................................39 Quadro 10 Documento de caso de uso Consultar estoque. .........................................................40 Quadro 11 Documento de caso de uso Registrar compras. .........................................................41 Quadro 12 Documento de caso de uso Registrar vendas. ...........................................................42 Quadro 13 Documento de caso de uso Manter contas a pagar. ...................................................43 Quadro 14 Documento de caso de uso Manter contas a receber. ................................................44
LISTA DE ABREVIATURAS E SMBOLOS
API CEP CNPJ CPF CSS DAO DER EA GOF HQL HTML HTTP JDBC IDE JEE JSP MVC PDF POJO SGBD SQL UC
Application Programming Interface Cdigo e Endereamento Postal Cadastro Nacional da Pessoa Jurdica Cadastro de Pessoa Fsica Cascading Style Sheets Data Access Object Diagrama Entidade-Relacionamento Gang of four Hibernate Query Language HyperText Markup Language Hypertext Transfer Protocol Java Database Connectivity Enterprise Architect
Integrated Development Environment Java Enterprise Edition Java Server Pages
U
UML XML
SIGECOMP Sistema de Gesto Comercial de Papelaria Structured Query Language Use Case Unified Modeling Language EXtensible Markup Language
IM
Model-view-controller Portable Document Format Plain Old Java Object
Sistema Gerenciador de Banco de Dados
IN A
SUMRIO
1 INTRODUO...............................................................................................................................11 1.1 CENRIO ATUAL ........................................................................................................................11 1.1.1 O Desenvolvimento de Softwares.....................................................................................11 1.1.2 O Apoio da Tecnologia aos Processos Comerciais...........................................................13 1.2 IDENTIFICAO DO PROBLEMA ....................................................................................................15 1.3 OBJETIVOS DO TRABALHO ..........................................................................................................15 1.3.1 Objetivo Geral..................................................................................................................15 1.3.2 Objetivos Especficos.......................................................................................................15 1.4 JUSTIFICATIVA PARA A PESQUISA .................................................................................................16 1.5 ORGANIZAO DO TRABALHO .....................................................................................................16 2 ESPECIFICAO DO PROBLEMA...............................................................................................18
4 ARQUITETURA E CDIGO...........................................................................................................62 4.1 O ENFOQUE DE CAMADAS ..........................................................................................................63 4.2 O PADRO MVC .......................................................................................................................64 4.3 SERVLETS E JAVA SERVER PAGES ..............................................................................................66 4.4 O FRAMEWORK STRUTS 2 ..........................................................................................................66 4.5 JAVA ENTERPRISE EDITION (JEE) ...............................................................................................68 4.6 PADRES DE PROJETO ..............................................................................................................69 4.7 CONTINER WEB E APLICAES WEB .........................................................................................72 4.8 ARQUITETURA E PROJETO DO SISTEMA SIGECOMP ....................................................................73 4.8.1 Diagrama de Pacotes.......................................................................................................74 4.8.2 Diagrama de Classes de Projeto ......................................................................................75 4.8.3 Diagrama de Seqncia de Projeto..................................................................................80 4.8.4 Como o SIGECOMP foi Implementado.............................................................................85 5.1 PADRO DE PROJETO DAO........................................................................................................96 5.2 DIAGRAMA DE ENTIDADE E RELACIONAMENTO ..............................................................................96 5.3 MAPEAMENTO OBJETO RELACIONAL ..........................................................................................100 5.3.1 Mapeamento Objeto Relacional utilizando JDBC............................................................100 5.3.2 Mapeamento Objeto Relacional utilizando o Hibernate...................................................100 6.1 TECNOLOGIAS UTILIZADAS ........................................................................................................103 6.2 DIAGRAMA DE ESTADOS DE NAVEGAO ....................................................................................105 7 CONCLUSES............................................................................................................................107 REFERNCIAS BIBLIOGRFICAS ...............................................................................................109 ANEXO A- DADOS IMPORTANTES ..............................................................................................110
5 PERSISTNCIA DE DADOS .........................................................................................................96
6 PROJETO DE INTERFACE .........................................................................................................103
IM
IN A
3.1 UML........................................................................................................................................25 3.2 FERRAMENTAS CASE................................................................................................................27 3.3 DIAGRAMA DE CASOS DE USO ....................................................................................................28 3.4 DOCUMENTOS DE CASO DE USO .................................................................................................30 3.5 CLASSES DE A NLISE ................................................................................................................45 3.5.1 Diagrama de Classes de Anlise......................................................................................46 3.5.2 Descriminao das classes de negcio. ...........................................................................48 3.5.3 Esteretipo das Classes...................................................................................................48 3.6 DIAGRAMAS DE SEQNCIA ........................................................................................................51
3 ANLISE DO SISTEMA ................................................................................................................25
11
1 INTRODUO
1.1 Cenrio Atual
1.1.1 O Desenvolvimento de Softwares
Pressman (2006), afirma que software mais que um produto, um conjunto de processos, documentaes, diagramas, enfim, tudo que foi utilizado do tamanho, complexidade ou domnio de aplicao, o software evolui com o tempo. As modificaes orientam esse processo de evoluo, seja quando erros so corrigidos, quando o sistema adaptado a um novo ambiente ou quando o cliente solicita novas caractersticas ou funes para a aplicao. Atualmente, a utilizao de sistemas computacionais tornou-se transporte, mdica, comercial, industrial, entretenimento, entre tantas outras. Devido importncia do seu uso e ao aumento da demanda de sistemas informatizados, a comunidade de software tem continuamente tentado desenvolver tecnologias que tornem mais fcil, mais rpido e menos dispendioso construir e manter programas de computador de alta qualidade. De acordo ainda com Pressman (2006), a importncia do software tem passado mudanas significativas em pouco mais de 50 anos. Dentre as varias mudanas pode-se citar o surgimento da Engenharia de Software (ES), que uma rea do conhecimento da computao voltada para a especificao, desenvolvimento e manuteno de sistemas de software aplicando tecnologias e prticas de gerncia 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 sistemtico e controlado, ao desenvolvimento de sistemas de software complexos, permitindo ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e para chegar ao software, que o produto final. Ainda segundo o autor, independente
IM
indispensvel para o desempenho de atividades nas mais diversas reas como
IN A
12
garantido suas qualidades. Alm disso, ela oferece mecanismos para se planejar e gerenciar o processo de desenvolvimento.
O desenvolvimento de software uma atividade complexa. Essa complexidade corresponde sobreposio 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 definio de processos de desenvolvimento de software. Um processo de desenvolvimento de software compreende todas as atividades necessrias para definir, desenvolver, testar e manter um produto de software. (Bezerra, 2002, p. 19).
Existem vrios processos propostos e cada um deles tem suas particularidades em relao ao modo de arranjar e encadear as atividades de processos existentes. Tais atividades so listadas no quadro 1 a seguir.
Atividades tpicas de um processo de desenvolvimento de software Atividade Levantamento de Requisitos Anlise de Requisitos Projeto Descrio
Corresponde etapa de compreenso do problema aplicada ao desenvolvimento do software. Usurios e desenvolvedores devem ter a mesma viso do problema a ser resolvido. realizado um estudo detalhado dos requisitos, para ento construir modelos para representar o sistema a ser desenvolvido. Nesta atividade, os requisitos so especificados e uma estratgia de soluo construda, 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 tecnolgicos existentes. O sistema codificado, ou seja, ocorre a traduo da descrio computacional programao.
N
Testes Implantao
Implementao da fase de projeto em cdigo executvel atravs do uso de uma linguagem de

So realizadas diversas atividades de testes para verificao do sistema construdo, levando-se em conta a especificao feita na anlise. O sistema empacotado, distribudo e instalado no ambiente do usurio. Os manuais do sistema so escritos e ocorre o treinamento dos usurios.
Quadro 1 Atividades tpicas de um processo de desenvolvimento de software
importncia para o projeto de desenvolvimento de um software. O produto dessas atividades a base para as demais atividades, sendo que o mesmo pode sofrer
IM
As atividades de levantamento e anlise de requisitos so de extrema
IN A
desenvolvimento. Entretanto, algumas atividades so comuns maioria dos
13
alteraes 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 no est apenas relacionada estrutura e ao comportamento, mas tambm a uma srie de validaes, que iro mostrar se o projeto vivel ou no. So exemplos de validaes: a funcionalidade, a questo do desempenho, a reutilizao e restries como a de carter econmico e tecnolgico. De posse dos requisitos e com a arquitetura j definida, o sistema codificado na atividade de implementao, atravs de uma linguagem de software e a entrega do produto final.
objetivando organizao, produtividade e qualidade. Tais artefatos englobam linguagens de programao, banco de dados, ferramentas, plataformas, bibliotecas, padres, metodologias, processos e a questo da qualidade de software.
1.1.2 O Apoio da Tecnologia aos Processos Comerciais
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 cenrio, no entanto, vem mudando, pois agora existem disponveis no mercado sistemas de gesto inovadores e de custo mais acessvel. Fazendo uso da tecnologia, os empresrios conseguem aumentar a produtividade, cortar custos, simplificar a gesto 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 cdigo de barra e tantos outros aparatos tecnolgicos deixaram de ser um diferencial competitivo para se transformar em um kit de sobrevivncia. O fato de no investir em tecnologia pode deixar uma empresa quilmetros atrs de seu
IM
A tecnologia da informao oferece inmeros recursos para auxiliar nos
IN A
Tecnologias e prticas fazem parte da Engenharia de Software,
programao. As duas atividades finais abordam a questo de testes, qualidade de
14
concorrente. Atualmente as micro, pequenas e medias empresas conquistam um espao cada vez maior na preferncia dos consumidores. Ao irem s compras, os consumidores percebem que, na maioria dos casos, essas empresas dispem 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 populao 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 invivel uma boa gerncia destes processos sem a ajuda de um software. Uberlndia e regio, possvel encontrar desde o mais simples software de prateleira facilmente encontrados e possuem um preo acessvel, visto que, uma vez produzido, este software vendido em larga escala. No entanto, boa parte destes, no oferecem garantias de atualizao, treinamento, implantao ou suporte tcnico. Existe ainda, a possibilidade de comprar ou alugar um sistema completo de gesto comercial. Em Uberlndia, essa uma prtica comum. Estes softwares lojas de autopeas, entre outros. Ao adquirir este tipo de software, muitas das vezes necessrio que alguns processos da empresa se adaptem ao software. Alm disso, pode ocorrer da empresa adquirir um software que talvez no seja ideal para o seu tipo de negcio. No geral, um sistema de gesto comercial de papelarias deve prover: Controle de compras e vendas. Controle de Estoque. Controle de Clientes. Controle de Fornecedores. Controle de Funcionrios. Financeiro (Contas a receber, a pagar e fluxo de caixa). Emisso e leitura do cdigo de barras do produto. Consulta de estoques e consultas diversas. Consulta e atualizao do cadastro de clientes. Permite pagamentos em diversas formas. Vendedores (cadastro completo dos vendedores). atendem no s as papelarias, mas vrios outros setores do comrcio, como padarias,
IM
IN A
at uma soluo sofisticada e/ou personalizada. Os softwares de prateleira so
Em se tratando de software de gesto comercial para papelarias, em
15
Unidade de venda. Ex: kit, pea, metro, cm, pacote. Em sua maioria, os sistemas para gesto comercial para papelarias aqui pesquisados, so aplicaes desktop, desenvolvidos em Pascal, com ferramenta Delphi, utilizando banco de dados gratuitos como Firebird e MySql. No 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 necessrio o desenvolvimento de um aplicativo personalizado. Nesse caso, o software desenvolvido especialmente para o cliente em particular.
desenvolvimento de um sistema web para gesto comercial de papelaria, que armazene as transaes comerciais e que possibilite a gerao de informaes relevantes para a empresa. Para o desenvolvimento deste projeto sero utilizados os conceitos da Engenharia de Software e do paradigma de orientao a objetos.
1.3.1 Objetivo Geral
N
objetos.
base nos conceitos da Engenharia de Software e do paradigma de orientao a
1.3.2 Objetivos Especficos Levantar e Analisar os requisitos do sistema. Documentar os requisitos utilizando a UML. Utilizar uma ferramenta CASE para o desenvolvimento da anlise e projeto orientados a objetos. Utilizar o padro Model-View-Controller (MVC). Implementar o aplicativo utilizando a linguagem Java.
IM
1.3 Objetivos do trabalho
Desenvolver um sistema web para gesto comercial de papelaria com
IN A
O problema em questo se resume em como realizar um projeto para o
1.2 Identificao do problema
16
Utilizar os padres de projeto Java Enterprise Edition (JEE). Utilizar o framework Struts2 para a camada de apresentao. Utilizar framework Hibernate3 para persistncia dos dados. Utilizar banco de dados MySql. 1.4 Justificativa para a pesquisa
A construo de um software, seguindo os conceitos da ES, envolve diversos profissionais e at mesmo equipes, cada qual responsvel por determinada funo; tem-se uma equipe para anlise, outra responsvel pela arquitetura e assim sucessivamente. Mesmo assim necessrio possuir uma viso global dos processos que envolvem o desenvolvimento de um aplicativo.
realidade, num contato analtico com o existente, para comprov-lo, plenamente e praticamente. Seguindo essa premissa, este projeto se apia na aplicao dos conceitos e utilizao das boas prticas no desenvolvimento de sistemas, contribuindo com a validao dos conceitos, atravs da pratica. A relevncia da pesquisa, em seus aspectos profissionais e cientficos, software profissionalmente e utilizando linguagens atuais, passando pelas diversas etapas, como visitas ao cliente, anlise dos requisitos, planejamento, desenvolvimento, armazenamento de dados, entre tantas outras.
N
de negocio.
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 acadmicas e cientficas. 1.5 Organizao do Trabalho
Este trabalho organizado como se segue: O captulo 2 descreve o problema a ser abordado. Ainda neste captulo sero apresentados os requisitos levantados nas reunies com o cliente e as regras
IM
sustenta-se na necessidade de um estudo mais profundo de como desenvolver um
A percepo da empresa parceira em utilizar a plataforma web,
IN A
De acordo com Freire (1999), a teoria implica numa insero na
17
O captulo 3 aborda a parte de anlise. O uso da UML foi fundamental para essa pesquisa e neste captulo so abordados os principais diagramas dessa linguagem. O captulo 4 dedicado arquitetura e cdigo do sistema. Nele constam todas as tecnologias, padres de projetos e metodologias utilizadas para a implementao do software. Neste tpico tambm so apresentados os digramas de classe e de seqncia a nvel de projeto, alm 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 compem o aplicativo. mapeamento objeto relacional e a persistncia dos dados.
mostrando algumas telas do sistema e o que foi utilizado para implementlas. Por fim, o capitulo 7 apresenta as concluses obtidas com o desenvolvimento da pesquisa. Neste ltimo captulo tambm so apresentadas sugestes para continuidade deste trabalho.
IM
IN A
O capitulo 6 faz uma breve introduo relativa ao projeto de interface,
No captulo 5, feita uma sntese das tecnologias utilizadas para o
18
2 ESPECIFICAO DO PROBLEMA
A empresa parceira, a Papelaria Pirmide (Figura 1) uma micro empresa que atua no ramo de papelarias na cidade de Uberlndia-MG. Fundada em 1999, oferece produtos para clientes do segmento corporativo (empresas, escritrios, escolas), universitrio e estudantes em geral. Atualmente, a empresa j possui a maioria de seus processos informatizados atravs do uso de um software de gesto comercial. Na viso do proprietrio da empresa, existe a necessidade das informaes estarem disponveis a todo o momento, inclusive fora do ambiente da implantao de um e-commerce. loja. Alm disso, pretende-se expandir os negcios futuramente, atravs da
U
Figura 1 Papelaria Pirmide
N
Deseja-se atravs do novo sistema gerenciar os processos do estabelecimento, como os diversos cadastros e o controle de compra e venda de
IM
IN A
19
mercadorias, uma vez que o sistema atual no satisfaz os requisitos necessrios. O sistema deve permitir o login do usurio, controle de clientes, de funcionrios, 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 Gesto Comercial de Papelaria (SIGECOMP), voltado para a plataforma web, de maneira que o usurio possa utiliz-lo independente de instalao em uma mquina local e que possibilite a expanso futura desse sistema, de acordo com as necessidades da empresa. Para o detalhamento do projeto, foi de fundamental importncia a pois atravs dela possibilitado que usurios e desenvolvedores tenham a mesma procurou entender o domnio do negcio, no caso o setor de papelarias. Nesta fase do projeto, foram realizadas reunies com os envolvidos (stackholders). Na primeira reunio, o escopo do projeto foi definido e foram compartilhados alguns processos de negcio da empresa. Nas reunies seguintes, a documentao de requisitos foi apresentada ao proprietrio da empresa, para de um sistema, as dvidas e divergncias devem ser tratadas nessa etapa, afim de no restarem duvidas acerca do que deve ser implementado e evitar problemas futuros. A seguir, so descritos os principais processos da Papelaria Pirmide voltado a: validaes e modificaes necessrias, afinal quando se trata do desenvolvimento
N
Funcionrios Apesar de ser uma empresa familiar, em determinadas pocas, como o perodo de volta s aulas, surge a necessidade de ampliar o nmero de funcionrios. Uma vez cadastrado, os dados desse funcionrio podem ser consultados, alterados ou excludos. Os dados relevantes para a empresa so os documentos de identificao (CPF, RG, N Carteira de Trabalho, PIS), data de entrada e sada da empresa, nome do funcionrio, contato (telefones e e-mail) e endereo completo. Os dados obrigatrios para o cadastro so CPF, RG, N Carteira de Trabalho, nome completo e data de entrada na empresa.
IM
IN A
viso do problema a ser resolvido. Durante o levantamento de requisitos, a equipe
aplicao da atividade de levantamento de requisitos da Engenharia de Software,
20
Clientes Ao cliente, pessoa fsica ou jurdica permitido o cadastro na loja. Uma vez cadastrado, os dados desse cliente podem ser consultados, alterados ou excludos. Os dados relevantes para a empresa so os documentos de identificao (CPF, RG, CNPJ, IE), nome do cliente, contatos (telefones e e-mail) e endereo completo. Os dados obrigatrios para o cadastro so o nome e documento (CPF ou CNPJ). Fornecedores e Representantes A empresa mantm o cadastro dos fornecedores. O fornecedor pode possuir os dados do fornecedor e representante podem ser consultados, alterados ou (CNPJ, IE), nome fantasia e razo social, contato (telefones e e-mail) e endereo completo. Os dados obrigatrios para o cadastro de fornecedor so os documentos de identificao (CNPJ e IE), nome fantasia e razo social. Os dados relevantes para representante so o nome, os telefones de contato e endereo de e-mail. 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, alteraes ou excluses. A empresa faz uso de uma leitora de cdigo de barras para agilizar esse processo, pois a grande maioria dos produtos j possui esse cdigo na embalagem. Os dados relevantes para a empresa so: cdigo de barras, descrio, tipo de apresentao (refere-se embalagem, se pacote, caixa, etc), referncia (fornecida pelo fabricante), marca, quantidade em estoque, quantidade de estoque mnima e quantidade de estoque mxima, prazo de validade (existem produtos perecveis como tintas diversas), preo de custo e preo de venda. Os dados obrigatrios para o cadastro so descrio, tipo de apresentao, marca, estoque mnimo e estoque mximo, preo de custo e preo 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
IM
IN A
excludos. Os dados relevantes para fornecedor so os documentos de identificao
representantes locais, que so os contatos com o fornecedor. Uma vez cadastrado,
21
fornecedor, a mercadoria pode demorar menos de um dia para ser entregue. Ao chegar, as mercadorias so separadas, os produtos novos so cadastrados, feito o lanamento da compra, atravs da nota fiscal. O estoque atualizado. Dependendo da forma de pagamento, o valor da compra lanado 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 e-mail), as mercadorias so separadas, feito o lanamento da venda. O estoque atualizado. Dependendo da forma de pagamento, o valor da venda moeda, cheque ou carto de dbito) ou a prazo (parcelamento carto de crdito, venda, obrigatrio relacionar um funcionrio, um cliente e no mnimo um produto (item da venda). Caso o cliente no seja cadastrado e o mesmo no queira realizar o cadastro naquele momento, a venda deve ser concluda de toda forma. Nesses casos o cliente lanado como consumidor. Estoque
O estoque atualizado conforme um compra ou uma venda realizada. Consultas ao estoque so realizadas para que no faltem produtos na loja. Contas a Pagar
U
prazo. prazo.
N
Contas a Receber
Contas a pagar podem ser lanadas, consultadas, alteradas ou excludas. As contas
tambm podem ser lanadas automaticamente no caso de compra realizada a
Contas a receber podem ser lanadas, consultadas, alteradas ou excludas. As contas tambm podem ser lanadas automaticamente, no caso de venda realizada a
IM
IN A
cheque pr-datado ou credirio prprio para clientes pessoa jurdica). Ao lanar a
lanado no contas a receber. Uma venda pode ser feita vista (pagamento em
22
As reunies com o cliente resultaram no documento de requisitos. Estes requisitos so divididos entre Requisitos funcionais e Requisitos no funcionais. De acordo com Sommerville (2003), os requisitos funcionais so aqueles que definem funes que o sistema deve fornecer, e os no funcionais podem estar relacionados s restries que o sistema deve atender, como por exemplo, requisitos de qualidade ou desempenho. O quadro 2, especifica os requisitos funcionais e no funcionais do sistema proposto. Requisitos funcionais
1. O sistema dever permitir ao usurio realizar login atravs de usurio e senha. 3. O sistema dever permitir ao usurio manter dados de funcionrios. 4. O sistema dever permitir ao usurio manter dados de fornecedores. 5. O sistema dever permitir ao usurio manter dados de representantes dos devidos fornecedores. 6. O sistema dever permitir ao usurio manter dados de produtos. 7. O sistema dever permitir ao usurio registrar vendas. 9. O sistema dever permitir consultar estoque. 8. O sistema dever permitir ao usurio registrar compras. 10. O sistema dever permitir o controle de contas a pagar.
11. O sistema dever permitir o controle de contas a receber.
N
venda. barras.
1. O sistema dever operar no Sistema Operacional Windows XP. 2. Utilizar banco de dados Software Livre. 3. Desenvolvimento em Java conforme convenes prprias da linguagem. 4. Oferecer uma interface amigvel. 5. Toda operao de venda dever ser feita em tela nica. 6. Valor default (cliente consumidor) para um cliente no cadastrado, no ato de uma 7. Leitura de cdigo de produtos poder ser feita atravs de uma leitora de cdigo de
Quadro 2 Requisitos funcionais e no funcionais.
mente so polticas, validaes, restries ou condies especificas. Tais regras
IM
As regras de negcio definem como uma empresa funciona, normal
IN A
Requisitos No-funcionais
2. O sistema dever permitir ao usurio manter dados de clientes.
23
podem determinar um comportamento do sistema. No Quadro 3 esto descritas as regras de negcio, obtidas atravs das reunies com o cliente.
RN-01
Para efetuar o cadastro de novos fornecedores, os campos obrigatrios devem ser preenchidosl. Campos obrigatrios: CNPJ, IE, nome e razo social. Para efetuar o cadastro de novos clientes, os campos obrigatrios devem ser preenchidos. Campos obrigatrio para pessoa fsica: nome e CPF. Cmapos obrigatrios para pessoa juridica: nome, razo social e CNPJ. Para efetuar o cadastro de novos produtos, os campos obrigatrios devem ser preenchidos. Campos obrigatrios: descrio, tipo de apresentao, marca, estoque mnimo e estoque mximo, preo de custo e preo de venda. Para cada operao de compra obrigatria a existncia de um fornecedor, um funcionrio e pelo menos um item. Para cada operao de venda obrigatria a existncia de um cliente, um funcionrio e pelo menos um item. Para realizar venda no credirio, o cliente deve ser pessoa jurdica.
RN-02
RN-03
RN-04
RN-05
RN-06
RN-08 RN-09 RN-10 RN-11 RN-12 RN-13 RN-14
IM
RN-07
Para efetuar o cadastro de funcionrios, os campos obrigatrios devem ser preenchidos. Campos obrigatrios: CPF, RG, N Carteira de Trabalho, nome completo e data de entrada na empresa.
Para efetuar o acesso ao sistema, o usurio deve entrar com usurio 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 necessrio 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 manuteno de dados de representantes deve-se acessar a manuteno de fornecedores e selecionar o item relativo manuteno de representantes de um determinado fornecedor. Para venda de produtos necessrio que o estoque deste produto no seja negativo, ou seja, o programa no aceita venda sem ter estoque.
IN A
24
RN-15 RN-16 RN-17 RN-18 RN-19 RN-20 RN-21
O cadastro do primeiro funcionrio deve ser efetuado pelo proprietrio da empresa, para no correr risco de omisso de informaes. Para cada fornecedor cadastrado pode-se ter pelo menos um representante vinculado neste cadastrado. Para excluso de qualquer cadastro deve-se fazer uma pesquisa antes de exclu-lo. Para contas a pagar de fornecedor deve-se ter nota fiscal de compras vinculadas. 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 possveis despesas, tais como: juros, taxas administrativas etc.
Para documentao do sistema foram usados diagramas estticos e dinmicos, a saber, diagrama de casos de uso, diagrama de classes e os diagramas de seqncia, que sero apresentados nos prximos tpicos.
IM
IN A
Quadro 3 Regras de Negcio.
25
3 ANLISE DO SISTEMA
A anlise inicia as atividades na produo de sistemas computacionais e evidncia quais funes devem ser implantadas e suas caractersticas de funcionamento, sendo a anlise a responsvel pela definio do problema. De acordo com Bezerra (2002, p. 24):
Formalmente, o termo anlise corresponde a quebrar um sistema em seus componentes e estudar como tais componentes interagem com o objetivo de entender como esse sistema funciona. [...] A razo desta prtica tentar obter a melhor soluo para o problema sem se preocupar com os detalhes da tecnologia a ser utilizada. necessrio saber o que o sistema proposto deve fazer para, ento, definir como esse sistema ir faz-lo.
A qualidade do produto de software aumenta cada vez mais, na de uso do sistema computacional so bem claros, o resultado no acerto e na eficcia do produto final eminente, provendo um bom grau de satisfao do usurio final. Sendo assim, o processo da anlise de sistemas fundamental para a elaborao de um projeto que visa o desenvolvimento de um software, pois alicera a correo das falhas que por ventura viro acontecer, dando tranqilidade para as
(EA) e padro de diagramas baseado na Unified Modeling Language (UML) possibilita mostrar de maneira clara e consistente a modelagem do sistema, atravs
U
3.1 UML A Unified Modeling Language (UML) uma linguagem de modelagem unificada que possibilita modelar sistemas computacionais de forma prtica, atravs de diagramas que especificam a construo, documentao e visualizao de artefatos que compem estes sistemas. Nessa linguagem, os desenvolvedores visualizam os produtos de seu trabalho em diagramas padronizados. Junto com uma notao grfica, a UML
de seus principais diagramas, como o diagrama de casos de uso, o diagrama de classes e o diagrama de seqncia.
IM
fases seguintes deste processo at um produto fim de alta qualidade. Na etapa da anlise, ferramentas como o aplicativo Enterprise Architect
IN A
medida em que se aplica anlise neste desenvolvimento, pois quando os atributos
26
tambm especifica significados, isto , semntica. uma notao independente de processos, estes diagramas descrevem aspectos de uma mesma soluo com diferentes pontos de vista, divididos em cinco vises: Viso de Caso de Uso; Viso de Lgica; Viso de Processo; Viso de Implementao e Viso de Implantao. Sendo que cada uma dessas vises assume um papel caracterstico na descrio 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 padro escolhido no mercado de fabrica de software. Especificamente as vises que compem a UML so: Diagrama de Casos de uso Diagrama de Colaborao Diagrama de Seqncia Diagrama de Classes Diagrama de Objetos Diagrama de Estado
Diagrama de Atividade
Diagrama de Componente Diagrama de Execuo
do sistema a ser construdo.
N U
(2009):
IM
Estes nove diagramas quando combinados mostram todas as vises A UML caracterizada, segundo o OMG - Object Management Group
[...] um modelo UML pode ser independente de plataforma ou de plataforma especfica, como podemos escolher, o MDA o processo de desenvolvimento utiliza as duas formas: Toda norma MDA ou aplicao baseia-se, normalmente, em um modelo independente de plataforma (PIM), que representa o seu negcio funcionalidade e comportamento muito precisa, mas no inclui os aspectos tcnicos. [...]Aumentar o nvel de abstrao: Modelos nos ajudar, deixando-nos trabalhar a um nvel mais elevado de abstrao. Um modelo pode fazer isso por esconder ou mascarar detalhes, trazendo a imagem grande, ou por se concentrar em diferentes aspectos do prottipo. [...]O OMG's Unified Modeling Language (UML ) ajuda voc a especificar, visualizar, e documentar modelos de sistemas de software, incluindo a sua estrutura e concepo, de uma forma que satisfaz todos estes requisitos. (Voc pode usar para as empresas de modelagem UML e modelagem de outros sistemas de software no demasiado.) Usando qualquer um do grande nmero de UML ferramentas baseadas no mercado, voc pode analisar a sua futura aplicao de requisitos e concepo de uma soluo que v ao encontro deles, [...] (traduo nossa)
IN A
27
Ficou claro que o uso dos padres propostos pela UML, somaria preciosa contribuio no desenvolvimento do software SIGECOMP (Sistema de Gesto Comercial de Papelaria), bem como de qualquer artefato de software. 3.2 Ferramentas CASE
As ferramentas CASE atuais propiciam a visualizao das funes do software atravs de diagramas, papeis dos colaboradores envolvidos e a documentao das funes a serem desenvolvidas. Antes dessa fase quando no se tinha no mercado ferramentas CASE, fazia-se a documentao com editores de texto, que, todavia no mostrava informaes para o
IN A
desenvolvimento, impactando
realmente o que se queria e precisava ser feito bem como no fornecia as reais num tempo maior de desenvolvimento e falhas perceptveis na comunicao entre as equipes envolvidas. As ferramentas CASE ocuparam o papel que faltava para completar esse ciclo no processo de anlise e no desenvolvimento dos artefatos de software, gerindo e diminuindo o tempo gasto, uma vez que melhora a comunicao, facilita o
IM
reuso do cdigo e traz timo desempenho aos desenvolvedores. Segundo Bezerra (2002, p.39), o termo CASE:
[...] uma sigla em ingls para Engenharia de Software Auxiliada por Computador (Computer Aided Software Engineering). A utilizao desta sigla j se consolidou no Brasil. [...]seguir algumas caractersticas que podem ser encontradas em ferramentas CASE so sucintamente descritas. - Criao de diagramas e manuteno da consistncia entre esses diagramas. - Rond-Trip engeneering: gerao de cdigo fonte a partir de diagramas e gerao de diagramas a partir de cdigo fonte. - Depurao de cdigo fonte: ferramentas que permitem encontrar erros de lgica em partes de um programa - Relatrios de testes: ferramentas que geram relatrio informando sobre partes de um programa que no foram testadas. - Testes automticos: ferramentas que realizam testes automaticamente no sistema - Gerenciamento de verses: ferramentas que permitem gerenciar as diversas verses dos artefatos de software gerando durante o ciclo de vida de um sistema. - Verificao de desempenho: averiguar o tempo de execuo de mdulos de um sistema, assim como o trfego de dados em sistemas em rede. - Verificao de erros em tempo de execuo. - Gerenciamento de mudanas nos requisitos. (traduo nossa)
28
Neste projeto utilizou-se, como ferramenta de modelagem, o software Enterprise Architect, verso 6.5.802 Esta verso totalmente aderente especificao da UML 2.0, pois ela prov diversos diagramas para construo de um sistema, ainda fornece a capacidade de modelagem dos requisitos funcionais do sistema deste o inicio at o fim do ciclo de construo do software, com gerao de documentao, controles de mudanas destes requisitos, manuteno e teste do artefato, bem como engenharia reversa das classes citadas. 3.3 Diagrama de Casos de Uso
Os diagramas de casos de uso tm o propsito de auxiliar a identificao das funes e objetivos do usurio, sendo que as funes do sistema de uso e seus relacionamentos.
Conforme Bezerra (2002, p.57):
U
atores.
simples, se consegue mostrar as funes do sistema a serem desenvolvidas aps a anlise, os elementos do caso de uso so: 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 interaes, geralmente representado pela figura de um balo ou circulo oval (elipse). Interao: Ato da troca de solicitao e resposta do sistema com os respectivos Sistema: Conjunto de casos de uso dentro da fronteira, com propsitos especficos a serem realizados, geralmente representados pela figura de um retngulo.
IM
O diagrama de caso de uso (DCU) corresponde a uma viso 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 nvel alto de abstrao 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
IN A
sero representadas atravs de grficos e figuras que representam os atores, casos
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 comunicao representado por um segmento de reta ligando ator e caso de uso. Um ator pode estar associado a vrios casos de uso em um diagrama de caso de uso.[...] Pode-se tambm representar a fronteira do sistema em um diagrama de caso de uso. Essa fronteira representada por um retngulo no qual so inseridos os casos de usos. Os atores so posicionados do lado de fora do retngulo, para enfatizar a diviso 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 aps o levantamento de requisitos feitos nas reunies com o cliente, ele mostra por meio de uma linguagem simples, o comportamento entre os atores que so caracterizados por serem agentes externos ao sistema e o sistema.
U
Casos de Uso Implementados Casos de Uso No Implementados
N
Figura 2 Diagrama de casos de uso Papelaria Pirmide
IM
IN A
30
O Funcionrio, at o presente momento, o nico ator que ir interagir diretamente com o sistema. Trata-se do proprietrio, ou mesmo outros funcionrios que podem auxilia-l com os processos da empresa. Diante da apresentao do diagrama de caso de uso e suas definies, mostra-se a seguir os artefatos que comporo o sistema SIGECOMP. 3.4 Documentos de Caso de Uso
Os documentos de caso de uso do suporte para a evoluo de todo sua participao, desde o comportamento dos seus usurios at a arquitetura que o 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 descrio de um conjunto de seqncia de aes, incluindo variantes realizadas pelo sistema para produzir um resultado observvel 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 necessrio especificar como esse comportamento implementado. Os casos de uso fornecem uma maneira para os desenvolvedores chegarem a uma compreenso comum com os usurios finais do sistema e com os especialistas do domnio. Alm disso, os casos de uso servem para ajudar a validar a arquitetura e para verificar o sistema medida que ele evolui durante seu desenvolvimento.
IM
Define-se como
IN A
caso de uso, uma
mesmo ser implementada.
processo do desenvolvimento deste projeto, a seguir descreve-se seu significado e
abstrao
simples
do
comportamento de um ator (usurio ou algo que interage com o sistema) no manejo com o software, descrevendo um roteiro coeso com o comportamento dos artefatos em uso. Segundo Booch, Rambaugh e Jacobson (2000, p.219): casos de usos
[...] Voc poder aplicar os casos de uso a todo seu sistema. Tambm aplic-los a uma parte do sistema, incluindo subsistemas e at interfaces e classes individuais. Em cada situao, os casos de uso no apenas representam o comportamento desejado desses elementos, mas tambm podem ser utilizados como a base de casos de teste para esses elementos, medida que evoluem durante o desenvolvimento. [...]Os casos de uso so classificadores e, portanto podero ter atributos e operaes 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
e suas aplicaes:
31
semelhante, considere essas operaes como as aes do sistema cujo fluxo de eventos ser necessrio descrever. Esses objetos e operaes podero ser utilizados em diagramas de interao para especificar o comportamento do caso de uso.
As atividades da identificao dos casos de uso, embora paream simples, no o so, pois diante de varias opes e caminhos a se seguir, pode se perder o foco das funes que o ator deve desempenhar diante do software. Esta atividade realizada no inicio do projeto por antever possveis erros e problemas nesta interao. Dentre as perguntas mais importantes a serem formuladas nesta fase destacam-se: Quais foram os atores? As informaes de leitura, mudanas, criao e armazenamento no software Quais atores receberiam informaes do software?
Quais atores manteriam estas informaes no software? Quais possveis usos de outro software ou Hardware neste software (Leitura de cdigo de barra)? estado de origem? atores a fariam? Este software deveria informar mudanas realizadas pelo autor em seu Se o software teria necessidade de comunicao de eventos externos e quais Booch, Rambaugh e Jacobson (2000, p.228) mostram as tcnicas
N U
bsicas 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 realizao de suas tarefas ou que so necessrios direta ou indiretamente para a realizao de funes do elemento. Organize os atores, identificando papis gerais e mais especializados. Para cada ator, considere as formas primrias em que o ator interage com o elemento. Considere tambm interaes que alteram o estado do elemento ou seu ambiente ou que envolvam uma resposta a algum evento. Considere tambm as formas excepcionais em que cada ator interage com o elemento. Organize esses comportamentos como casos de uso, aplicando relacionamentos de incluso e estendidos com a finalidade de fazer a fatorao do comportamento comum e diferenciar o comportamento excepcional.
de produo e reversa, os casos de uso so documentos de texto, e refletem a
IM
Apesar de serem similares aos diagramas que permitem a engenharia
IN A
caberiam a quais atores?
Quais seriam as funes de cada ator?
32
implementao dos sistemas, subsistemas e classes a serem criadas bem como seus comportamentos. Entretanto no permitem a engenharia de produo, outras tcnicas que utilizam casos de uso j estruturados podem ser utilizados na engenharia direta. Tais tcnicas evitam erros na fabricao do software e conseqente impacto na reduo do ciclo de vida desta etapa. Conforme Bezerra (2002, p.45):
O modelo de Casos de Uso uma representao das funcionalidades externamente observveis do sistema e dos elementos externos ao sistema que interage com ele. [...] Desde ento, esse modelo vem se tornando cada vez mais popular para realizar a documentao de requisitos funcionais de uma aplicao, devido sua notao grfica simples e descrio em linguagem natural, o que facilita a comunicao de desenvolvedores e usurios. [...] Alm disso, o modelo de casos de uso fora os desenvolvedores a moldarem o sistema de acordo com o usurio, e no o usurio de acordo com o sistema.
funes 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 padres UML e constitudo Nome: A identificao do nome do caso de uso em questo deve ser a mesma que Identificador: Cdigo que referncia os diversos documentos relacionados com o modelo de caso de uso, recomenda-se o uso do sufixo CSU seguido de um numeral, ex. CSU07 frases.
U
uso. uso
Sumrio: resumo das descries do caso de uso. Recomendam-se no mximo duas
Ator primrio: A identificao do ator ou algo que inicia ou beneficia-se do caso de
Ator(es) Secundrio(s): A identificao dos demais atores que participam do caso de Pr-condies: regras que define em que hipteses sero assumidas como verdadeiras para que o caso de uso tenha incio. Ex. O usurio deve inserir senha para ter acesso ao sistema. Ps-condio: e o estado do sistema aps ter sido executado. Fluxo Principal: Define a descrio da seqencia de passos do fluxo principal. Toda
IM
aparece no diagrama de caso de uso, cada caso de uso ter um nico nome.
IN A
At um usurio sem experincia na rea de sistemas identificaria as
33
descrio de caso de uso deve ter um item descrevendo o fluxo principal, pois contribuem para o sucesso na descrio da realizao 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 so diferentes das alternativas do fluxo principal, para alcanar seu foco proposto, estes tambm descrevem situaes de escolhas exclusivas entre si (quando existem diferentes possibilidades e somente uma deve ser realizada). Fluxo de Exceo: relatam as atividades de exceo, onde algo inesperado acontece entre o caso de uso e o ator.(Por exemplo: usurio executa ao Regras de Negcio: Quando um caso de uso faz referncia a uma ou mais regras de na execuo dos processos existentes em uma organizao, estas devem estar completas e serem apresentadas em documento nico chamado de modelo de regras de negcio. Apresenta-se a seguir, os documentos de caso de uso do Software SIGECOMP, que foram escritos baseados nas melhores prticas de identificao impactaram sistematicamente na reduo de erros e no tempo gasto em seu desenvolvimento. apresentadas pela UML. Devidamente organizados e estruturados, estes
IM
IN A
negcio, ou seja so polticas, condies ou restries que precisam ser explicitadas
invalidada pelo sistema).
34
No quadro 4 esto descritos no documento de caso de uso as funes que o ator (funcionrio) deve aplicar ao realizar login no sistema. Aps o preenchimento dos campos solicitados, se estes forem vlidos, o sistema exibe a tela principal do programa, caso contrrio, o sistema permanece na tela de login, na qual exibida a mensagem de erro no login.
Nome Sumrio Ator primrio: Funcionrio
Realizar Login Este caso de uso descreve o processo para realizar login.
CSU-01
Pr-condio: Possuir nome de usurio e senha validos Ps-condio: Acesso ao menu principal do sistema Fluxo Principal
1. O sistema exibe a tela inicial
2. O funcionrio entra com os respectivos dados: usurio e senha. 3. O sistema verifica se o usurio e senha so validos. 4. O sistema apresenta o menu principal e o caso de uso encerrado.
No h.
Fluxo de Exceo [3]: Usurio ou Senha invlida a) b) O usurio informa dados incorretos ou invlidos. O sistema emite uma mensagem. Regras de Negcio Associadas
RN-08 Quadro 4 Documento de caso de uso Realizar login.
IM
Fluxo Alternativo [ ]:
IN A
Ator(es) secundrio(s): -
35
No quadro 5 esto descritos no documento de caso de uso as funes que o ator (funcionrio) deve exercer para Manter dados do Cliente.
Nome Sumrio
Manter Dados de Cliente
CSU-02
Esse caso de uso descreve as etapas necessrias para a manuteno dos dados de clientes (incluso, alterao, excluso).
Ator primrio: Funcionrio Ator(es) secundrio(s): Pr-condio: Estar logado no sistema Ps-condio: Funcionrio cadastrado, atualizado ou excludo. 1. 2. 3. 4.
Fluxo Principal O funcionrio solicita a manuteno de clientes no sistema. O sistema apresenta as opes (incluir, alterar, excluir). O funcionrio indica a opo desejada.
O sistema registra a operao e o caso de uso e encerrado.
Fluxo Alternativo [3.1]: Incluir a) O funcionrio solicita a incluso de um cliente. b) c) d) O funcionrio informa os dados
O sistema solicita os dados a serem preenchidos.
O funcionrio confirma incluso e o caso de uso retorna ao passo 4.
Fluxo Alternativo [3.2]: Alterar a) b) c) d)
O funcionrio solicita a alterao dos dados de um cliente. O sistema apresenta o formulrio para a alterao dos dados. O funcionrio altera os dados. O funcionrio confirma a alterao e o caso de uso retorna ao passo 4.
U
b) c) b)
Fluxo Alternativo [3.3]: Excluir a) O usurio solicita a excluso do cadastro de um cliente. O sistema exibe uma mensagem de alerta para confirmao da excluso. O funcionrio confirma a excluso e o caso de uso retorna ao passo 4.
Fluxo de Exceo [3]: no preenchimento dos dados obrigatrios a) O usurio no informa os dados obrigatrios O sistema emite uma mensagem. Regras de Negcio Associadas RN-02 Quadro 5 Documento de caso de uso Manter dados de cliente.
IM
IN A
36
No quadro 6 esto descritos no documento de caso de uso as funes que o ator (funcionrio) deve exercer para Manter dados de Funcionrio.
Nome Sumrio Manter Dados de Funcionrio CSU-03
Esse caso de uso descreve as etapas necessrias para a manuteno dos dados de funcionrios (incluso, alterao, excluso).
Ator primrio: Funcionrio Ator(es) secundrio(s): Funcionrio Pr-condio: Estar logado no sistema Ps-condio: Funcionrio cadastrado, atualizado ou excludo. Fluxo Principal 1. 2. 3. 4.
O funcionrio solicita a manuteno de funcionrios no sistema. O sistema apresenta as opes (incluir, alterar, excluir). O funcionrio indica a opo desejada.
Fluxo Alternativo [3.1]: Incluir a) O funcionrio solicita a incluso de um funcionrio. b) c) d) a) b) c) d) a) b) c) O sistema solicita os dados a serem preenchidos. O funcionrio informa os dados
Fluxo Alternativo [3.2]: Alterar
O funcionrio solicita a alterao dos dados de um funcionrio. O sistema apresenta o formulrio para a alterao dos dados. O funcionrio altera os dados. O usurio confirma a alterao e o caso de uso retorna ao passo 4.
U
b)
Fluxo Alternativo [3.3]: Excluir O funcionrio solicita a excluso do cadastro de um funcionrio. O sistema exibe uma mensagem de alerta para confirmao da excluso. O funcionrio confirma a excluso e o caso de uso retorna ao passo 4.
Fluxo de Exceo [ 3 ]: no preenchimento dos dados obrigatrios a) O usurio no informa os dados obrigatrios O sistema emite uma mensagem. Regras de Negcio Associadas RN-07, RN-15 Quadro 6 Documento de caso de uso Manter dados de funcionrio.
IM
IN A
37
No quadro 7 esto descritos no documento de caso de uso as funes que o ator (funcionrio) deve exercer para Manter dados de Fornecedor.
Nome Sumrio
Manter Dados de Fornecedor
CSU-04
Esse caso de uso descreve as etapas necessrias para a manuteno de dados de Fornecedores (incluso, alterao, excluso).
Ator primrio: Funcionrio Ator(es) secundrio(s): Pr-condio: Estar logado no sistema Ps-condio: Fornecedor cadastrado, atualizado ou excludo. Fluxo Principal O funcionrio solicita a manuteno de fornecedor no sistema. O sistema apresenta as opes (incluir, alterar, excluir). O funcionrio indica a opo desejada.
1. 2. 3. 4.
Fluxo Alternativo [ 3.1 ]: incluir a) O funcionrio solicita a incluso de um fornecedor. b) c) d) a) b) c) d) O sistema solicita os dados a serem preenchidos. O funcionrio informa os dados.
Fluxo Alternativo [ 3.2]: Alterar
O funcionrio solicita a alterao dos dados de um fornecedor. O sistema apresenta o formulrio para a alterao dos dados. O funcionrio altera os dados. O funcionrio confirma a alterao e o caso de uso retorna ao passo 4.
U
b) c)
Fluxo Alternativo [ 3.3 ]: excluir a) O funcionrio solicita a excluso do cadastro de um Fornecedor. O sistema exibe uma mensagem de alerta para confirmao da excluso. O funcionrio confirma a excluso e o caso de uso retorna ao passo 4.
Fluxo de Exceo [ 3 ]: no preenchimento dos dados obrigatrios Caso no sejam informados os dados obrigatrios do cadastro o sistema emite uma mensagem e o caso de uso retorna ao passo 4. Regras de Negcio Associadas RN-01 Quadro 7 Documento de caso de uso Manter dados de fornecedor.
IM
IN A
38
No quadro 8 esto descritos no documento de caso de uso as funes que o ator (funcionrio) deve exercer para Manter dados de Representantes.
Nome Sumrio
Manter Dados de Representantes
CSU-05
Esse caso de uso descreve as etapas necessrias para a manuteno de dados de Representantes (incluso, alterao, excluso).
Ator primrio: Funcionrio Ator(es) secundrio(s): Pr-condio: Estar logado no sistema Ps-condio: Representante cadastrado, atualizado ou excludo. 1. 2. 3. 4. Fluxo Principal O funcionrio solicita a manuteno de Fornecedores no sistema. O sistema apresenta as opes (incluir, alterar, excluir). O funcionrio indica a opo desejada.
5. O sistema registra a operao e o caso de uso e encerrado. Fluxo Alternativo [ 3.1 ]: incluir a) O funcionrio solicita a incluso de um representante. b) c) d) O sistema solicita os dados a serem preenchidos.
O funcionrio confirma a incluso e os caso de uso retorna ao passo 3.
Fluxo Alternativo [ 3.2 ]: alterar a) O funcionrio solicita a alterao dos dados de um representante. b) c) d) O sistema apresenta o formulrio para a alterao dos dados. O funcionrio altera os dados. O funconrio confirma a alterao e o caso de uso retorna ao passo 3.
U
b) c)
Fluxo Alternativo [ 3.3 ]: excluir a) O funcionrio solicita a excluso total de dados de um representante. O sistema exibe uma mensagem de alerta para confirmao da excluso. O funcionrio confirma a excluso e o caso de uso retorna ao passo 3.
Fluxo de Exceo [ 3 ]: no preenchimento dos dados obrigatrios Caso no sejam informados os dados obrigatrios do cadastro o sistema emite uma mensagem e o caso de uso retorna ao passo 3. Regras de Negcio Associadas RN-01, RN-13, RN-16 Quadro 8 Documento de caso de uso Manter dados de representante.
IM
O funcionrio informa os dados.
IN A
O funcionrio solicita a manuteno de Representantes no sistema.
39
No quadro 9 esto descritos no documento de caso de uso as funes que o ator (funcionrio) deve exercer para Manter Produtos.
Nome Sumrio Manter Produtos CSU-06 Esse caso de uso descreve as etapas necessrias para a manuteno de produtos. (incluso, alterao, excluso).
Ator primrio: funcionrio Ator(es) secundrio(s): Pr-condio: estar logado no sistema Ps-condio: produto cadastrado, atualizado ou excludo. 1. 2. 3. 4. Fluxo Principal O funcionrio solicita a manuteno de produtos no sistema. O funcionrio indica a opo desejada.
Fluxo Alternativo [ 3.1 ]: incluir a) O funcionrio solicita a incluso de um Produto. b) c) d) O funcionrio informa os dados
O funcionrio confirma a excluso e o caso de uso retorna ao passo 4
Fluxo Alternativo [ 3.2 ]: alterar a) O funcionrio solicita a alterao dos dados de um produto. c) d) O funcionrio altera os dados.
O funconrio confirma a alterao e o caso de uso retorna ao passo 4.
N
b) c)
Fluxo Alternativo [ 3.3 ]: excluir a) O funcionrio solicita a excluso total de dados de um produto. O sistema exibe uma mensagem de alerta para confirmao da excluso. O funcionrio confirma a excluso e o caso de uso retorna ao passo 4.
Fluxo de Exceo [ 3 ]: no preenchimento dos dados obrigatrios Caso no sejam informados os dados obrigatrios do cadastro, o sistema emite uma mensagem e o caso de uso retorna ao passo 4. Fluxo de Exceo [ 3 ]: fornecedor no cadastrado O sistema permite apenas o cadastro de produtos que tenham seus fornecedores j cadastrados. Caso o produto no possua fornecedor, sistema emite mensagem. Regras de Negcio Associadas RN-03, RN-10 Quadro 9 Documento de caso de uso Manter dados de produtos.
IM
b)
O sistema apresenta o formulrio para a alterao dos dados.
IN A
O sistema apresenta as opes (incluir, alterar, excluir).
40
No quadro 10 esto descritos no documento de caso de uso as funes que o ator (funcionrio) deve exercer para Consultar Estoque.
Nome Sumrio
Consultar Estoque Este caso de uso descreve o processo para consultar o estoque.
CSU-07
Ator primrio: Funcionrio Ator(es) secundrio(s): Pr-condio: Existir movimentao de produtos (Compra/Venda) Ps-condio: A empresa ter informaes do estoque Fluxo Principal O funcionrio solicita a consulta a ser realizada no sistema. O sistema apresenta o formulrio de consulta. O funcionrio preenche os dados para a consulta caso de uso encerrado. Fluxo Alternativo [ ]: No h.
2. 3. 4.
O sistema apresenta os dados de estoque de todos os produtos cadastrados e o
Fluxo de Exceo [ 4 ]: Produto no cadastrado
cadastrados. b)
O caso de uso retorna ao passo 2. Regras de Negcio Associadas
RN-09
Quadro 10 Documento de caso de uso Consultar estoque.
IM
a)
O sistema informa que os dados solicitados no conferem com os dados
IN A
1.
41
No quadro 11 esto descritos no documento de caso de uso as funes que o ator (funcionrio) deve exercer para Registrar Compras.
Nome Sumrio
Registrar Compras
CSU-08
Este caso de uso descreve as etapas necessrias para controlar o movimento de compras.
Ator primrio: Funcionrio Ator(es) secundrio(s): Pr-condio: Efetuar uma compra de algum produto. Ps-condio: Compra efetuada e estoque atualizado. Fluxo Principal O funcionrio solicita a opo de registrar uma compra no sistema.
1. 2.
3. O funcionrio informa os dados (funcionrio, fornecedor, produtos e contas a pagar) e confirma a operao. 4. O sistema registra a operao, atualiza o estoque e o caso de uso e encerrado. Fluxo Alternativo [ 3 ]: Dados incorretos a) b)
O sistema solicita o preenchimento correto dos dados, conforme a regra de negcio RN 04.
RN-04, RN-11, RN-19
Quadro 11 Documento de caso de uso Registrar compras.
IM
O caso de uso retorna ao passo 02.
IN A
Regras de Negcio Associadas
42
No quadro 12 esto descritos no documento de caso de uso as funes que o ator (funcionrio) deve exercer para Registrar Vendas.
Nome Sumrio
Registrar Vendas
CSU-09
Este caso de uso descreve as etapas necessrias para controlar o movimento vendas.
Ator primrio: Funcionrio Ator(es) secundrio(s): Cliente Ps-condio: Venda efetuada e estoque atualizado. Fluxo Principal Pr-condio: Efetuar uma venda de algum produto.
1. 2. 3. 4.
O funcionrio solicita a opo de registrar uma venda no sistema. O sistema solicita os dados a serem preenchidos. O funcionrio informa os dados e confirma a operao.
O sistema registra a operao, atualiza o estoque e o caso de uso encerrado.
a) b)
O sistema solicita o preenchimento correto dos dados. O caso de uso retorna ao passo 02. Regras de Negcio Associadas
RN-05, RN-06, RN-12, RN-14 Quadro 12 Documento de caso de uso Registrar vendas.
IM
Fluxo Alternativo [ 3 ]: Dados incorretos
IN A
43
No quadro 13 esto descritos no documento de caso de uso as funes que o ator (funcionrio) deve exercer para Manter Contas a Pagar.
Nome Sumrio
Manter Contas a Pagar
CSU-10
Esse caso de uso descreve as etapas necessrias para controlar contas a pagar.
Ator primrio: Funcionrio Ator(es) secundrio(s): Pr-condio: Existir uma movimentao de compras de produtos e servios. Fluxo Principal 1. 2. 3. 4. Ps-condio: O sistema atualiza contas a pagar.
O funcionrio solicita a manuteno de contas a pagar. O funcionrio indica a opo desejada.
O sistema apresenta as opes (incluir, alterar, excluir).
Fluxo Alternativo [ 3.1 ]: incluir a) O funcionrio solicita a incluso de uma conta a pagar. b) c) d) O sistema solicita os dados a serem preenchidos. O funcionrio informa os dados
O funcionrio confirma a excluso e o caso de uso retorna ao passo 4.
Fluxo Alternativo [ 3.2 ]: alterar a) O funcionrio solicita a alterao dos dados de uma conta a pagar. b) c) d) O sistema apresenta o formulrio para a alterao dos dados. O funcionrio altera os dados. O funconrio confirma a alterao e o caso de uso retorna ao passo 4.
U
b) c)
N
RN-18, RN-20
Fluxo Alternativo [ 3.2 ]: excluir a) O funcionrio solicita a excluso de uma conta a pagar. O sistema exibe uma mensagem de alerta para confirmao da excluso. O funcionrio confirma a excluso e o caso de uso retorna ao passo 4.
Fluxo de Exceo [ ]: No h. -
Quadro 13 Documento de caso de uso Manter contas a pagar.
IM
IN A
Regras de Negcio Associadas
44
No quadro 14 esto descritos no documento de caso de uso as funes que o ator (funcionrio) deve exercer para Manter Contas a Receber.
Nome Sumrio
Manter Contas a Receber
CSU-11
Esse caso de uso descreve as etapas necessrias para controlar contas a receber.
Ator primrio: Funcionrio Ator(es) secundrio(s): Pr-condio: Existir uma movimentao de vendas de produtos. Ps-condio: O sistema atualiza contas a receber. 1. 2. 3. 4.
O sistema apresenta as opes (incluir, alterar, excluir). O funcionrio indica a opo desejada.
Fluxo Alternativo [ 3 ]: incluir a) b) c) d) a) b) c) d)
O funcionrio solicita a incluso de uma conta a receber. O sistema solicita os dados a serem preenchidos. O funcionrio informa os dados.
Fluxo Alternativo [ 3.1 ]: alterar
O funcionrio solicita a alterao dos dados de uma conta a receber. O sistema apresenta o formulrio para a alterao dos dados. O funcionrio altera os dados. O funconrio confirma a alterao e o caso de uso retorna ao passo 4.
U
b) c) No h.
RN-21
Fluxo Alternativo [ 3.2 ]: excluir a) O funcionrio solicita a excluso de uma conta a receber. O sistema exibe uma mensagem de alerta para confirmao da excluso. O funcionrio confirma a excluso e o caso de uso retorna ao passo 4.
Fluxo de Exceo [ ]: Regras de Negcio Associadas Quadro 14 Documento de caso de uso Manter contas a receber.
IM
O funcionrio confirma excluso e o caso de uso retorna ao passo 4
IN A
Fluxo Principal O funcionrio solicita a manuteno de contas a receber.
45
3.5 Classes de Anlise
As classes descrevem caractersticas semelhantes em seus atributos, operaes, relacionamentos e semntica. So de essenciais na distribuio equilibrada de responsabilidades em um sistema, pois so caracterizadas por blocos de construes, implementando uma ou mais interfaces, bem como capturando o vocabulrio do sistema a ser desenvolvido, so essenciais em qualquer sistema orientado a objeto. Conforme Booch, Rumbaugh, Jacobson (2000, p.48):
suas principais abstraes so caracterizadas pelo: nome, atributos e operaes. 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 caracterstica que a classe pode apresentar nas instncias de seus valores, podendo esta classe ter um ou mais atributos, sendo at permitido no ter nenhum atributo, estes atributos definiro o tipo de dados ou estados que os objetos da classe cobriro. As operaes so implementaes de uma atividade, que quando solicitada por qualquer objeto da classe modifica o seu comportamento, esta especificao deve conter assinatura, que contm o nome, o tipo e o valor-padro
IM
[...] Uma classe uma abstrao de itens que fazem parte do seu vocabulrio. A classe no 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 no pesos e assim por diante. Voc pode tambm considerar instncias individuais de paredes, como a parede do lado sudoeste do meu escritrio. [...] No caso de software, muitas linguagens de programao dispem de suporte direto para o conceito de classe. Isso excelente, pois significa que as abstraes que voc criar podem ser mapeadas diretamente para a linguagem de programao, ainda que sejam abstraes de itens que no sejam software, como cliente, transao ou conversao.
A UML usa a figura de um retngulo para representar uma classe, e
IN A
46
das funes e o tipo de valor a ser retornado.
3.5.1 Diagrama de Classes de Anlise
O diagrama de classe de anlise mostra as colaboraes e relacionamentos de um conjunto de classes, bem como as interfaces que um determinado sistema possui, estes diagramas so mais presentes em sistemas de modelagem orientados a objetos. As classes de negcios indicam o que ser implantado, pois possuem a estrutura e funcionalidades lgicas e tambm as regras de negcios a serem desenvolvidas no sistema proposto.
funcionais do sistema. Estas classes usam detalhes para representar uma modelagem conceitual primria para elementos da estrutura e do comportamento dos objetos. do sistema que possuem atributos e responsabilidades especficas, entre elas enfatiza-se o encapsulamento
SIGECOMP, demonstrando suas classes, interfaces e colaboraes e seus relacionamentos.
IM
A figura 3 apresenta o diagrama de classes de negcio do sistema
IN A
As classes de anlise sintetizam as aes relacionadas aos requisitos
47
Figura 3 Diagrama de classes de negcio do sistema SIGECOMP.
U N IM A IN S
48
3.5.2 Descriminao das classes de negcio.
As classes de negcio que compem o sistema SIGECOMP: Login: classe responsvel por funes e caractersticas inerentes ao login no sistema. Fornecedor: mantm as funes relacionadas as associaes de fornecedor e seu relacionamento com a classe representante e suas possveis reas. de funcionrio. Cliente: mantm as funes relacionadas Pedido: mantm as funes relacionadas
possveis reas, entre elas pessoa fsica e jurdica. as
IN A
as
possveis reas entre elas pedido de compra e contas a pagar; pedido de venda e contas a receber, bem como item e produto. possveis reas, entre elas item e pedido. reas, entre elas pedido e produto. Diante das informaes j vistas das classes de negcios que Produto: mantm as funes relacionadas as associaes do produto e suas
Item: mantm as funes relacionadas as associaes do item e suas possveis
estruturaram o sistema, a seguir apresenta-se a modelagem deste sistema, seu comportamento e o tratamento das requisies externas a ele compostas.
3.5.3 Esteretipo das Classes
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 esteretipo graficamente, por um nome entre << >>(dois sinais
IM
Os esteretipos classificam as classes de anlise. Esse conceito
S
associaes associaes
Funcionrio: classe responsvel por funes e caractersticas inerentes ao cadastro de cliente e suas
do pedido e suas
49
de menor e dois sinais de maior), ou por texto, se esse no modificar o desenho padro do componente representado. Conforme Guedes (2005, p.42):
Esteretipos so uma maneira de destacar ou diferenciar um componente ou relacionamento de outros componentes ou relacionamentos iguais, atribuindo-lhe caractersticas especiais ou modificando-as de alguma forma. Esteretipos podem ser de texto, quando no modificam o desenho padro do componente, ou grficos quando modificam a forma padro do componente.
classes que servem de comunicao entre os atores e o sistema. Essas classes traduzir os eventos gerados por um ator em eventos relevantes ao sistema. Objetos destas classes tambm so responsveis por traduzir os resultados de uma operao das classes internas em informaes que possam ser entendidas pelos atores. A figura 4 mostra como so representadas graficamente as classes de fronteira.
N U
<<control>> identifica as classes que servem de intermdio entre as classes <<boundary>> e as outras classes do sistema. Essas classes so responsveis por controlar a lgica de execuo de um caso de uso, sendo seus objetos responsveis por interpretar os eventos gerados pelos usurios e repass-los aos outros objetos
IM
sd Classe Fronteira
Figura 4 Esteretipo de uma classe de fronteira.
O esteretipo de controle, tambm conhecido como esteretipo
IN A
<< nome da classe >>
contm o cdigo de controle das interfaces do sistema, e so responsveis por
O esteretipo de fronteira ou esteretipo <<boundary>>, identifica as
50
que participam da solicitao. A figura 5 mostra como so representadas graficamente as classes de controle.
sd Classe Controle
Figura 5 Esteretipo de uma classe de controle.
O esteretipo de entidade, tambm conhecido como esteretipo <<entity>> tem por objetivo tornar explicito que uma classe uma entidade, ou seja, a classe contm informaes recebidas ou geradas por meio do sistema. So responsveis por manter as informaes manipuladas pelo sistema, desta maneira, representam conceitos do domnio do negcio, e normalmente do origem s bases de dados do sistema. A figura 6 mostra como so representadas graficamente as classes de entidade.
N U
IM
estes objetos (instncias de entidade) geralmente so persistentes. Essas classes
sd Classe Entidade
Figura 6 Esteretipo de uma classe de entidade.
IN A
51
3.6 Diagramas de Seqncia
Os diagramas de seqncia tm o propsito de auxiliar a cronologia das funes e objetivos do usurio, focando na ordem em que so trocadas as mensagens entre os objetos que o compem. Conforme Booch, Rumbaugh, Jacobson (2000), um diagrama de sequncia enfatiza a ordenao temporal das mensagens. Os elementos grficos que compem um diagrama de seqncia e suas principais abstraes so: ator, objeto, classe, mensagem, linha da vida e foco de controle. software SIGECOMP, que foram escritos baseados nas melhores prticas de identificao apresentadas pela UML. Devidamente organizados e estruturados, estes impactaram sistematicamente na reduo de erros e no tempo gasto em seu desenvolvimento, pois mostram uma viso do sistema em funcionamento, alm de agrupar as classes de anlise precedidas neste documento. Apresenta-se a seguir os diagramas de seqncia de anlise do
IM
IN A
52
Diagrama de Seqncia de Anlise do Caso de Uso Realizar Login A figura 7 mostra o diagrama de seqncia de anlise do caso de uso realizar login. descrito neste diagrama as funes que o ator (funcionrio) deve aplicar ao realizar login no sistema. Aps o preenchimento dos campos solicitados, se estes forem vlidos, o sistema exibe a tela principal do programa, se o funcionrio for invalido ou inserir senha errada o sistema volta a exibir a interface inicial com mensagem de alerta.
N
Figura 7 Diagrama de seqncia de anlise do caso de uso Realizar Login.
IM
IN A
53
Diagrama de Seqncia de anlise do Caso de Uso Manter Dados de Cliente A figura 8 mostra o diagrama de seqncia de anlise do caso de uso Manter Dados de Cliente.
U
Figura 8 Diagrama de seqncia de anlise do caso de uso Manter Dados de Cliente
IM
IN A
54
Diagrama de Seqncia de anlise do Caso de Uso Manter Dados de Funcionrio A figura 9 mostra o diagrama de seqncia de anlise do caso de uso Manter Dados de Funcionrio.
U
Figura 9 Diagrama de seqncia de anlise do caso de uso Manter Dados de Funcionrio
IM
IN A
55
Diagrama de Seqncia de anlise do Caso de Uso Manter Dados de Fornecedor
A figura 10 mostra o diagrama de seqncia de anlise do caso de uso Manter Dados do Fornecedor.
U
Figura 10 Diagrama de seqncia de anlise do caso de uso Manter Dados de Fornecedor
IM
IN A
56
Diagrama de Seqncia de anlise do Caso de Uso Manter Dados de Representante A figura 11 mostra o diagrama de seqncia de anlise do caso de uso Manter Dados de Representante, descrito neste diagrama as funes que o ator (funcionrio) deve exercer para Manter dados de Representante.
U
Figura 11 Diagrama de seqncia de anlise do caso de uso Manter Dados de Representante.
IM
IN A
57
Diagrama de Seqncia de anlise do Caso de Uso Manter Dados de Produto A figura 12 mostra o diagrama de seqncia de anlise do caso de uso Manter Dados de Produto, descrito neste diagrama as funes que o ator (funcionrio) deve exercer para Manter dados do Produto.
sd Seq. Anlise Manter Dados de Produto
Funcionrio Usurio sol icita a opo produto no menu principal
M enu
Produto
Produto
Produto
Sol icitao direcionada ao controlador Busca produtos cadastrados
exibida a tela de manuteno de dados de produtos Usurio escolhe a opo desejada
Lista de produtos
opt Manter Dados de Produto [Incluir]
exibido o formulri o de cadastro para preenchimento Usurio preenche o formulrio e envia os dados
IN A
Solicitao de incluso Ok Dados enviados Produto cadastrado Busca dados para alterao Devolve dados solicitados Dados enviados Dados do Produto alterados com sucesso Sol icitao de excluso Produto excludo com sucesso
exibida a tela de m anuteno de dados de produtos
[Alterar]
IM
Usurio seleciona Produto ser excludo
Usurio escolhe o produto a ter os dados alterados
exibido o formulrio contendo os dados do sol icitados Usurio altera os dados necessrio e envia os dados Dados a serem alterados Alterao de dados ok
N
[Exclui r]
Figura 12 Diagrama de seqncia de anlise do caso de uso Manter Dados de Produtos.
S
Ok Busca dados Ok Ok
Produtos exi stentes
Dados do cadastro
Produto a ser excludo
58
Diagrama de Seqncia de anlise do Caso de Uso Registrar Compra A figura 13 mostra o diagrama de seqncia de anlise do caso de uso Registrar Compra, descrito neste diagrama as funes que o ator (funcionrio) deve exercer para Registrar Compra.
N
Figura 13 Diagrama de seqncia de anlise do caso de uso Registrar Compra.
IM
IN A
59
Diagrama de Seqncia de anlise do Caso de Uso Registrar Venda A figura 14 mostra o diagrama de seqncia de anlise do caso de uso Registrar Venda, descrito neste diagrama as funes que o ator (funcionrio) deve exercer para Registrar Venda.
Figura 14 Diagrama de seqncia de anlise do caso de uso Registrar Venda.
IM
IN A
60
Diagrama de Seqncia de anlise do Caso de Uso Manter Contas a Pagar A figura 15 mostra o diagrama de seqncia de anlise do caso de uso Manter Contas a Pagar, descrito neste diagrama as funes que o ator (funcionrio) deve exercer para Manter Contas a Pagar.
sd Seq. Anlise Manter Contas a Pagar
Funcionrio
Menu
Contas a pagar Solicitao direcionada ao control ador
Contas a pagar
Contas a pagar
Usurio sol icita a opo Contas a pagar no m enu principal
Busca Contas a pagar cadastradas
exibida a tela de manuteno de dados de Contas a pagar
Usurio escolhe a opo desejada
opt Manter Dados de Contas a pagar [Incluir]
exi bido o formulrio de cadastro para preenchim ento
Usurio preenche o formulrio e envia os dados
IN A
Solicitao de incluso Direciona para o formulrio de cadastro Dados enviados Busca dados para alterao Devolve dados solicitados Dados enviados Dados da Contas a pagar alterados com sucesso Solicitao de excluso Contas a pagar excluda com sucesso
exibi da a tela de manuteno de dados de Contas a pagar
[Alterar]
IM
Usurio escolhe a Contas a pagar a ter os dados alterados
exibido o formulrio contendo os dados do solicitados
N U
[Excluir]
Usurio altera os dados necessrio e envi a os dados Dados a serem alterados Alterao de dados ok
Usurio sel eciona Contas a pagar ser excluda Fornecedor a ser excludo Ok
Figura 15 Diagrama de seqncia de anlise do caso de uso Manter Contas a Pagar.
S
Lista de Contas a pagar Direciona solicitao Contas a pagar cadastrada Ok Ok
Contas a pagar existentes
Dados do cadastro
Busca dados
61
Diagrama de Seqncia de anlise do Caso de Uso Manter Contas a Receber A figura 16 mostra o diagrama de seqncia de anlise do caso de uso Manter Contas a Receber, descrito neste diagrama as funes que o ator (funcionrio) deve exercer para Manter Contas a Receber.
sd Seq. Anlise Manter Contas a Receber
Funcionrio Usurio soli cita a opo Contas a receber no menu principal
Menu
Contas a receber Solicitao direcionada ao control ador
Contas a receber
Contas a receber
Busca Contas a receber cadastradas
exibida a tela de m anuteno de dados de Contas a receber
Usurio escolhe a opo desejada
opt Manter Dados de Contas a receber [Incluir]
exi bido o formulrio de cadastro para preenchim ento
Usurio preenche o formulrio e envia os dados
IN A
Solicitao de incluso Direciona para o formulrio de cadastro Dados enviados Busca dados para alterao Devolve dados solicitados Dados enviados Solicitao de excluso Contas a receber excluda com sucesso
exibida a tela de manuteno de dados de Contas a receber
[Alterar]
IM
Usurio escolhe a Contas a receber a ter os dados alterados
exibido o formulrio contendo os dados do solicitados
N U
[Excluir]
Usurio altera os dados necessrio e envi a os dados Dados a serem alterados Alterao de dados ok
Usurio seleciona Contas a receber ser excluda Fornecedor a ser excludo Ok
Figura 16 Diagrama de seqncia de anlise do caso de uso Manter Contas a Receber.
S
Lista de Contas a receber Direciona solicitao Contas a receber cadastrada Ok Ok Dados da Contas a receber alterados com sucesso
Contas a receber existentes
Dados do cadastro
Busca dados
62
4 ARQUITETURA E CDIGO
Arquitetura de software refere-se estrutura global do software. Ela representa a estrutura e a organizao dos componentes do sistema. Alm disso, a arquitetura mostra como esses componentes interagem entre si. Pressman (2006), afirma que a arquitetura de software e sua representao explcita, 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. construo de um software, pois permite ao profissional de Tecnologia da Informao (TI) examin-lo em seu todo. Alm disso, sua representao constitui um facilitador da comunicao entre todas as partes envolvidas no desenvolvimento e destaca decises iniciais de projeto. A definio da arquitetura de extrema importncia no processo de
de distribuio e de manuteno de um sistema, portanto a escolha da arquitetura
pode depender dos requisitos no funcionais do sistema. Para a definio da arquitetura de um sistema especifico, pode-se ter como base um modelo de arquitetura j existente, porm necessrio ter uma conscientizao da aplicabilidade desses modelos e de seus pontos fortes e fracos. Sommerville (2003) afirma que requisitos no funcionais como desempenho, disponibilidade, segurana e facilidade de manuteno, impactam na definio da arquitetura. Pode ocorrer, por exemplo, que um sistema exija alto desempenho e segurana. Se tais caractersticas forem importantes requisitos do sistema, deve-se encontrar alguma soluo intermediaria para a arquitetura. Uma maneira de solucionar essa questo atravs do uso de diferentes estilos de arquitetura para diferentes partes do sistema. O autor afirma ainda que grandes sistemas raramente so compatveis com um nico modelo de arquitetura.
IM
A arquitetura de software no est apenas relacionada estrutura e ao comportamento, mas tambm ao uso, a funcionalidade, ao desempenho, a flexibilidade, a reutilizao, a abrangncia, a adequaes e a restries de carter econmico e tecnolgico, alm de questes estticas. (BOOCH, RUMBAUGH & JACOBSON, 2000, p. 32)
A arquitetura do sistema afeta o desempenho, a robustez e a facilidade
IN A
63
4.1 O Enfoque de Camadas
Um modelo de software em camadas especifica o uso de trs camadas lgicas, a saber: camada de apresentao, camada de processamento de aplicao (lgica de negcio) e camada de integrao ou acesso. importante ressaltar que a diviso em camadas independente da diviso fsica dos objetos. As camadas so logicamente visualizadas de forma separada, de maneira que uma camada no esteja estritamente acoplada com a camada adjacente. Desta forma, o sistema representado em uma pilha de camadas. camadas. A figura 17 mostra a diviso entre
N U
sistema. A camada de apresentao responsvel pela interao com o usurio. Os componentes da interface grfica residem nesta camada. A camada de aplicao, tambm conhecida como camada de negcios, determina de que maneira os dados sero utilizados. Nesta camada encontram-se as regras de negocio. Por fim, a camada de integrao ou camada de dados tem a responsabilidade de manter os dados da aplicao, nela reside o banco de dados que fornece toda a informao
IM
Figura 17 As trs camadas lgicas de um software em camadas. (Adaptado de Sommerville, 2003, p. 208)
A cada camada atribuda uma responsabilidade distinta ou nica no
IN A
64
necessria para o funcionamento da aplicao de negcios. De acordo com Bezerra (2002) um software em trs camadas tem como vantagem um maior grau de reutilizao dos objetos implementados e a facilidade na manuteno destes, de maneira que esses softwares possam ser facilmente estendidos. O principio bsico a ser seguido que as camadas mais altas devem depender das camadas mais baixas e no o contrrio. O sistema deve funcionar de maneira que os componentes executados em cada camada, possam ser alterados e no gerem prejuzos para o sistema como todo. Desse modo, as atualizaes e correes devem ocorrer sem prejudicar as demais camadas. Como exemplo, toda a interface com o usurio pode ser alterada
4.2 O Padro MVC
Model View Controller (MVC) um padro arquitetural utilizado em engenharia de software, que divide uma aplicao interativa em trs componentes. regras de negcio e dados do sistema. Os trs componentes so: o modelo, a viso ou visualizao e o controlador. Presmam (2006), afirma que o MVC na verdade um padro
arquitetural desenvolvido na dcada de 80 para o ambiente smaltalk, porm pode ser usado para qualquer aplicao interativa e atualmente ganhou grande visibilidade em aplicaes web. A figura a seguir detalha o funcionamento do MVC.
IM
utilizado de forma bem sucedida para desacoplar a interface com o usurio das
IN A
sem comprometer as regras de negcios.
65
Figura 18 O funcionamento do padro MVC. (Adaptado de Presman, 2006, p.443)
de dados. A visualizao responsvel pela interao grfica com o usurio. a apresentao da aplicao. Em uma aplicao Java pode ser uma interface Swing ou uma interface web. O controlador gerencia as requisies do usurio. Ele se encontra entre a visualizao e o modelo e, dependendo daquilo que o usurio faz, criar e modificar o modelo. Ao criar esses trs componentes, as responsabilidades da aplicao
N
da aplicao.
so divididas, sendo a melhor maneira de trabalhar com aplicaes complexas. A implementao do MVC pode agregar vantagens como: reaproveitamento de cdigo, facilidade de manuteno da aplicao, integrao de equipes e/ou diviso de tarefas, camada de persistncia independente e facilidade na alterao da interface
IM
O modelo contm o ncleo das funcionalidades, regras de negocio e
IN A
66
4.3 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 so armazenados em um servidor web e a partir deste, recebem e respondem requisies de clientes atravs do protocolo HTTP, o HyperText Transfer Protocol. Atualmente, quando se refere construo de aplicaes web dinmicas, os Servlets se tornaram uma escolha popular, pois fornecem vantagens comuns linguagem Java, como portabilidade, performance e reusabilidade. Alm Java Server Pages, mais conhecida como JSP, uma tecnologia que permite servir contedo dinmico em uma aplicao web. JSP uma extenso da tecnologia Servlet. Segundo Todd e Szolkowski (2003) atravs de pginas JSPs, possvel por exemplo, criar e manipular arquivos XML ou mesmo gerar contedo mais avanado, como imagens dinmicas e documentos PDF. Uma JSP permite a mistura de tags HTML, tags de JSP e cdigo Java em um nico arquivo. De maneira prtica, os Sevlets e JSPs so especificaes da plataforma JEE, que ser abordada adiante. Ambos so utilizados para prover contedo dinmico em aplicaes web, utilizando a linguagem Java. disso, os Servles acessam todas as APIs do Java.
4.4 O Framework Struts 2
N
(JSPs).
desenvolvido por Craig McClanahan e doado, em maio de 2002, Apache Foundadtion. um framework free open-source, ou seja, possui cdigo aberto. Ele utilizado para construir aplicaes web em Java, que utilizam o padro MVC, pois fornece uma srie de recursos tais como: Um Servlet controlador. Uma classe action com algumas descries. Esta pode ser estendida para subclasses, fornecendo classes que chamam a lgica de negcio. Biblioteca de tags para facilitar a construo de pginas web dinmicas
IM
De acordo com Alur, Crupi e Malks (2004), o framework Struts foi
IN A
67
O framework Struts pertence camada de apresentao, no entanto, fornece componentes para implementao do controle da aplicao. Desta forma, ele responsvel pelo gerenciamento de ao e visualizao. O gerenciamento de ao refere-se localizao e ao roteamento de aes especificas que serviro a uma solicitao, enquanto o gerenciamento de visualizao refere-se localizao e distribuio para a visualizao adequada. A figura a seguir representa de maneira simplificada o funcionamento do framework Struts2.
Figura 19 Framework Struts2. (Fonte: Roughley, 2006, p.11)
implementao do controlador, que recebe e delega requisies. As actions, que so estendidas da classe ActionSupport, manipulam as classes de negcio (modelo). Por fim, as pginas JSPs so responsveis pela apresentao do contedo dinmico. So necessrios dois arquivos xml para configurao. O arquivo web.xml, que um arquivo necessrio em qualquer aplicao web, contm as informaes de configurao para a aplicao, como por exemplo, definio do controlador e definio da pgina inicial. O arquivo struts.xml responsvel pelo mapeamento das aes. Cada requisio do usurio tratada como uma ao. Existe ainda a
IM
No Struts2, o FilterDispatcher bem como os Interceptors, constituem a
IN A
68
possibilidade de utilizar um terceiro arquivo, o struts.properties, responsvel por configuraes de propriedades. Como visto, o Struts2 encapsula toda a lgica das requisies e resposta. O desenvolvedor modifica apenas o arquivo struts.xml, cria as classes actions derivadas da classe ActionSupport e desenvolve as pginas JSPs com o auxilio das tags do Struts2. Os passos de uma requisio podem ser resumidos da seguinte forma: 1. Usurio envia requisio 2. O FilterDispatcher analisa a requisio e determina a ao. funcionalidades comuns tais como validao, upload de arquivos, etc. 5. A sada gerada
6. Ocorre o retorno da requisio
7. O resultado exibido para o usurio
O framework Struts2 centraliza todas as requisies e as respostas em desenvolvedor, os principais so o encapsulamento da lgica do modelo MVC e a reduo do tempo de desenvolvimento e consequentemente nos custo do projeto.
4.5 Java Enterprise Edition (JEE)
aplicao web desenvolvida na linguagem Java, optou-se pela plataforma JEE. Essa plataforma ligada ao desenvolvimento de aplicaes multicamadas e organizada em componentes modularizados. Java Enterprise Edition oferece uma srie de especificaes e APIs, cada uma com funcionalidades distintas. Dentre estas, podese citar os Sevlets e JSPs utilizados nessa pesquisa e j comentados anteriormente.
IM
um nico ponto. O uso deste framework resulta em uma srie de benefcios para o
Para implementao da arquitetura, uma vez que se trata de uma
IN A
4. Execuo da ao: o mtodo relativo ao executado.
3. Interceptors so aplicados: Interceptors so configurados para aplicar
69
4.6 Padres de Projeto
Os design patterns ou padres de projeto so solues de projetos j aplicadas em um problema recorrente e que mostraram resultado satisfatrio, por esta razo, os padres se referem comunicao de problemas e solues. Alur, Crupi e Malks (2004), afirmam que esses padres foram popularizados atravs da obra Design Patterns: Elements of Reusable Object-Oriented Software, de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (tambm conhecidos como Gang of Four Gof, ou gangue dos quatro).
Sommerville (2003) caracteriza padro como uma descrio do problema e a essncia de sua soluo, de modo que essa soluo possa ser pensar que um padro uma descrio de conhecimentos e experincias acumuladas. Ainda segundo o autor, os padres de projeto tm estado inevitavelmente associados com os projetos baseados na orientao a objetos. De acordo com Alur, Crupi e Malks (2004), o catalogo de padres JEE utilizada em diversos casos. O padro no uma especificao detalhada, pode-se
inclui atualmente 21 padres. Cada padro classificado dentro de uma das trs camadas de arquitetura lgica: camada de apresentao, camada de negcios e camada de integrao. Para o desenvolvimento da aplicao SIGECOMP, utilizouse os padres Context Object e Front Controller (implementados pelo framework Struts2), da camada de apresentao; Business Object, da camada de negcios e Data Acess Object, da camada de integrao. A figura a seguir, mostra a diviso em camadas aplicada plataforma JEE, que foi utilizada na arquitetura do sistema SIGECOMP (Figura 16).
IM
IN A
Padres de projeto apresentam a essncia de uma soluo de projeto para problemas recorrentes em engenharia de software. Como definido na literatura, um padro nomeia, abstrai e identifica aspectos-chave de uma estrutura de projeto comum. Padres nos ajudam a construir sistemas de software seguindo bons princpios de OO, como alta coeso e baixo acoplamento, resultando em sistemas mais flexveis e de mais fcil manuteno. (GAZOLA & MARQUES, 2009, p.50)
70
Camada de Apresentao
Servlets, JSPs e outros elementos de interface com o usurio
Interao com o usurio, criao de contedo, formato e entrega
Business Object e outros objetos de negcio
Camada de Negcios
Lgica de negcios
Camada de Integrao
JDBC, dados
Acesso aos dados
Figura 20 Enfoque em camadas. (Adaptado de Alur, Crupi e Malks, 2004, p.102)
Nesta plataforma, observa-se que a camada de apresentao encapsula toda a lgica de representao exigida para servir os clientes que servios de negcios, constri as respostas e entrega aos clientes. As classes de fronteira so encontradas aqui. Os Servlets e JSPs tambm residem nessa camada, importante ressaltar que ambos no so elementos de interface com o usurio propriamente ditos, mas produzem esse elementos. Os padres de projeto utilizado aqui foram: acessam o sistema. Ela intercepta as solicitaes dos clientes, controla o acesso a
Context Object: seu principal objetivo compartilhar as informaes do sistema de um modo independente de camada, melhorando a capacidade de reutilizao e manuteno da aplicao. Este padro implementado atravs de uma classe POJO, que uma vez criado um objeto desta classe, seu estado ser compartilhado por toda a aplicao. Desta maneira, o uso deste padro possibilita um melhor desacoplamento entre as camadas. Front Controller: fornece um ponto de entrada centralizado para tratar as solicitaes. Centralizando a lgica de controle, esse design pattern tambm ajuda a
IM
IN A
O Catlogo de Padres JEE lida com estas camadas
71
reduzir a quantidade de lgica de programao embutida diretamente nas vizualizaes. Neste trabalho, o padro Front Controller foi implementado atravs do uso do framework Struts2.
Problema: voc deseja um ponto de acesso centralizado para o tratamento da solicitao da camada de apresentao. [...] Soluo: Use um Front Controller como o ponto inicial de contato para tratar todas as solicitaes relacionadas. O Front Controller centraliza a lgica de controle, a qual, de outro modo, poderia ser duplicada, e gerencia as atividades de tratamento de solicitaes principais. (ALUR, CRUPI & MALKS, 2004, p.143)
J a camada de negcios fornece os servios de negcios necessrios processamento de negcios para a aplicao, est centralizado nela. Aqui foi
Business Object: esse padro utilizado para separar a lgica de persistncia da lgica de negocio. Estes objetos encapsulam e gerenciam os dados de negocio e ainda permitem que o armazenamento e recuperao dos dados sejam delegados para um outro objeto de persistncia, por exemplo.
N
persistncia.
negcios e recursos externos como sistemas de integrao de comrcio eletrnico entre empresas, servios de autorizao de cartes de credito, entre outros. O Data Access Object foi o padro utilizado nessa camada. Data Access Object: esse padro consiste em abstrair o mecanismo de persistncia utilizado na aplicao. O uso deste padro ser discutido no captulo de importante ressaltar que os padres de projeto no so de uso exclusivo da plataforma JEE. Padres de projeto so amplamente utilizados no
IM
Problema: voc tem um modelo de domnio conceitual com lgica de negcios e relacionamentos.[...] Soluo: use Business Objects para separar os dados e a lgica de negcios usando um modelo de objeto. (ALUR, CRUPI & MALKS, 2004, p.334)
Por fim, a camada de integrao contm o acesso aos dados de
IN A
utilizado o padro Business Object descrito a seguir:
aos clientes das aplicaes. Essa camada contm a lgica de negcios, logo, o
72
desenvolvimento de softwares, e muitos so independentes da plataforma ou linguagem de programao a ser utilizada. Pode-se citar o DAO, que foi catalogado
na especificao JEE e tambm pode ser visto em aplicaes desenvolvidas em linguagem PHP, por exemplo.
4.7 Continer Web e Aplicaes Web
Todd e Szolkowski (2003), afirmam que o continer web o local onde as aplicaes Web baseadas em Servlets e JSPs so hospedadas. Ele tambm Alm disso, o continer capaz de entregar outros formatos de dados como HTML, Neste trabalho foi utilizado o continer Web gratuito da Apache, o TomCat. Ele tem a capacidade de atuar tambm como servidor web, ou pode funcionar integrado a um servidor web dedicado como o Apache. Tanto Servlets como JSPs precisam estar em um continer web. Nele, ao ser processada, uma JSP torna-se um Servlet. A seguir, apresentada uma estrutura de pastas predefinida para uma aplicao web. hospeda toda a lgica de apresentao de uma aplicao JEE baseada na Web. imagens grficas e dados XML para clientes.
U
Figura 21 A estrutura de uma aplicao Web. (Adaptado de Todd e Szolkowski, 2003, p.90)
IM
IN A
73
Observa-se que a pasta raiz o primeiro nvel de uma aplicao web. A pasta WEB-INF contm informaes de configurao como o arquivo web.xml, o diretrio de lib, onde encontram-se as bibliotecas utilizadas pela aplicao e o diretrio onde ficam as classes da aplicao. A pgina index e os diretrios de contedo (HTML, JSP, entre outros), podem ser distribudos no mesmo nvel da pasta WEB-INF.
4.8 Arquitetura e Projeto do Sistema SIGECOMP
Como descrito anteriormente, para o projeto de arquitetura do sistema alguns padres de projeto. A figura 22 ilustra como ficou definida a arquitetura do aplicativo SIGECOMP.
U
Figura 22 Arquitetura utilizada no aplicativo SIGECOMP.
IM
IN A
web proposto, foram utilizados o padro MVC e a plataforma JEE juntamente com
74
Desta forma, as classes de fronteira so representadas pelas pginas JSPs que tm sua interface grfica configurada por arquivos CSS. Essas classes tm a responsabilidade de interagir com o usurio do sistema, exibindo as funcionalidades do aplicativo e os resultados das solicitaes. As classes de controle foram implementadas atravs das classes Action. Existe ainda, um controlador central implementado pelo framework Struts2. Todas as requisies do usurio passam por ele. Atravs do mapeamento das aes no arquivo struts.xml, esse controlador reconhece quem deve executar determinada solicitao. A solicitao ento delegada para uma classe Action, que uma classe extendida da classe ActionSupport contida neste framework. de uso enquanto que nas classes BO ficam as regras de negcio, o que permite um Para as classes de entidade tm-se as classes DAO e Entity, responsveis pelo mapeamento objeto relacional e persistncia dos dados. O acesso aos dados foi implementado com a utilizao do framework Hibernate3. Para cada caso de uso implementado, tem-se pelo menos duas pginas JSPs, uma classe Action, uma classe BO, uma classe DAO e uma classe requisies e respostas. Isso ser mostrado nos itens seguintes, atravs do diagrama de pacotes, dos diagramas de classe de projeto e diagramas de seqncia de projeto, especificados pela UML. Entity. E como mencionado existe um controlador central que faz o roteamento das
4.8.1 Diagrama de Pacotes
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 compem. Pode ser utilizado tambm para auxiliar a demonstrar a arquitetura de um sistema. Na figura 23, mostrado o diagrama de pacotes do sistema SIGECOMP.
IM
O diagrama de pacotes um dos diagramas estruturais que fazem
IN A
melhor desacoplamento entre as camadas.
Desta maneira, a classe Action tem o papel de ser um mini-controlador de um caso
75
Figura 23 Diagrama de pacotes do software SIGECOMP.
4.8.2 Diagrama de Classes de Projeto
de software e interfaces de uma aplicao. Atravs deste diagrama possvel especificar as classes que devem ser implementadas, quais so seus atributos e mtodos. possvel tambm verificar o relacionamento entre as classes, a visibilitade dos atributos e mtodos, bem como os parmetros e tipo de retorno de um mtodo. A seguir, so mostrados por caso de uso, alguns diagramas de classe de projeto do sistema SIGECOMP.
IM
O diagrama de classe de projeto ilustra as especificaes para classes
IN A
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 nvel de projeto e mostra quais classes foram implementadas para este caso de uso.
N
Figura 24 Diagrama de classes de projeto do caso de uso Realizar Login.
mtodos pblicos para acesso, a saber, um mtodo get e um mtodo set. No entanto, alguns destes mtodos foram omitidos na representao dos diagramas seguintes, por se tratarem de mtodos bsicos de uma aplicao Java.
IM
Observa-se que para cada atributo de visibilidade privada, tm-se dois
IN A
77
Diagrama de Classes de Projeto do Caso de Uso Manter Dados de Funcionrio
A figura 25 apresenta o diagrama de classes do caso de manter dados de funcionrio, este um diagrama a nvel de projeto e mostra quais classes foram implementadas para este caso de uso.
N
Figura 25 Diagrama de classes de projeto do caso de uso Manter Dados de Funcionrio.
IM
IN A
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 nvel de projeto e mostra quais classes foram implementadas para este caso de uso.
N
Figura 26 Diagrama de classes de projeto do caso de uso Manter Dados de Fornecedor.
IM
IN A
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 nvel de projeto e mostra quais classes foram implementadas para este caso de uso.
N
Figura 27 Diagrama de classes de projeto do caso de uso Manter Dados de Produto.
IM
IN A
80
4.8.3 Diagrama de Seqncia de Projeto
Usados para a modelagem do comportamento dinmico, os diagramas de seqncia de projetos oferecem uma viso panormica das interaes, pois mostram uma viso do sistema em funcionamento.
Um diagrama de seqncia um diagrama de interao que d nfase ordenao temporal de mensagens. Um diagrama de seqncia mostra conjunto de objetos e as mensagens enviadas e recebidas por esses objetos. Tipicamente os objetos so instncias de classes. Use os diagramas de colaborao para ilustrar a viso dinmica de um sistema. (BOOCH, RUMBAUGH & JACOBSON, 2000, p. 96).
IM
IN A
Apresentam-se a seguir, por caso de uso, alguns diagramas de seqncia de projeto do sistema SIGECOMP.
81
Diagrama de Sequncia de Projeto do Caso de Uso Realizar Login A figura 28 mostra o diagrama de seqncia de projeto do caso de uso Realizar Login. descrito neste diagrama as funes que o ator (funcionrio) deve aplicar ao realizar login no sistema, aps o preenchimento dos campos solicitados, se estes forem vlidos, o sistema exibe a tela principal do programa, se o funcionrio for invlido ou inserir senha errada o sistema volta a exibir a tela inicial com mensagem de alerta.
Figura 28 Diagrama de sequncia de projeto do caso de uso Realizar Login.
IM
IN A
82
Diagrama de Seqncia de Projeto do Caso de Uso Manter Dados de Funcionrio A figura 29 mostra o diagrama de seqncia de projeto do caso de uso Manter Dados de Funcionrio, descrito neste diagrama as funes que o ator (funcionrio) deve exercer para Manter dados de Funcionrio.
U
Figura 29 Diagrama de seqncia de projeto do caso de uso Manter Dados de Funcionrio.
IM
IN A
83
Diagrama de Seqncia de Projeto do Caso de Uso Manter Dados de Fornecedor A figura 30 mostra o diagrama de seqncia de projeto do caso de uso Manter Dados de Fornecedor, descrito neste diagrama as funes que o ator (funcionrio) deve exercer para Manter dados de Fornecedor.
U
Figura 30 Diagrama de seqncia de projeto do caso de uso Manter Dados de Fornecedor.
IM
IN A
84
Diagrama de Seqncia de Projeto do Caso de Uso Manter Dados de Produto A figura 31 mostra o diagrama de seqncia de projeto do caso de uso Manter Dados de Produtos, descrito neste diagrama as funes que o ator (funcionrio) deve exercer para Manter dados do Produto.
U
Figura 31 Diagrama de seqncia de projeto do caso de uso Manter Dados de Produto.
IM
IN A
85
4.8.4 Como o SIGECOMP foi Implementado
A inteno deste tpico mostrar como foi implementado o software, mostrando seus principais arquivos de configurao como o web.xml e o struts.xml. Neste tpico o caso de uso manter dados de funcionrio descrito passo a passo, evidenciando partes do cdigo implementado. importante ressaltar que at o momento foram implementados os seguintes casos de uso: Realizar Login, Manter Dados de Cliente Manter Dados de Funcionrio, Manter Dados de Fornecedor e Manter Dados de Produto. Para o desenvolvimento do cdigo, utilizou-se a ferramenta IDE Eclipse. Esta uma ferramenta de ambiente integrado, bastante flexvel e ainda possui licena baseada nas especificaes open source. A figura 32 mostra a estrutura de diretrios definida para implementao do SIGECOMP.
U
Figura 32 Estrutura do SIGECOMP.
IM
IN A
86
A figura 33 mostra o arquivo web.xml. Como j foi mencionado, este um arquivo comum a qualquer aplicao web. Neste projeto ele foi utilizado para definio 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 pginas o Struts2 deve controlar; /* representa todas as pginas do diretrio raiz. Aqui tambm foi definida qual a pgina inicial do sistema, a index.jsp, configurada pela tag <welcome-file-list>. Finalmente, foram mapeados alguns erros especficos atravs da marcao <error-page>.
 <filter> <filter-name>struts2</filter-name> <filter-class> org.apache.struts2.dispatcher.FilterDispatcher </filter-class> </filter>  <filter-mapping> <filter-name>struts2</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
 <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list>  <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 configurao web.xml.
IM
A figura 34 mostra o parte do cdigo contido no arquivo struts.xml.
IN A
<?xml version="1.0" encoding="UTF-8"?> <web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" mlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> <display-name>sigecomp</display-name>
87
Neste arquivo so mapeadas todas as aes da aplicao. atravs deste mapeamento que o controlador central gerencia e executa o roteamento das aes. Cada funcionalidade do sistema representa uma ao que deve ser mapeada. Tais aes so disparadas ao controlador atravs das solicitaes do usurio, que so feitas atravs de um navegador web. Basicamente, para cada ao mapeada pela tag <action> atribui-se um nome. necessrio especificar a classe relativa ao (sempre so as classes Action do projeto). Se a classe Action possuir mais de um mtodo, necessrio especificar o nome do mtodo que se pretende utilizar. Dentro da ao, necessrio configurar o(s) resultado(s) da mesma. O resultado, mapeado pela tag <result>
<!DOCTYPE struts PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN" "http://struts.apache.org/dtds/struts-2.0.dtd">
<struts> <package name="default" extends="struts-default">  [...]
<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.
IM
 <action name="getTodosFuncionarios" method="getTodosFuncionarios" class="br.com.sigecomp.action.FuncionarioAction"> <result name="success">/jsp/funcionario.jsp</result> </action>
IN A
pode ser o direcionamento para uma pgina ou mesmo a chamada de outra ao.
88
A figura 35 mostra parte do cdigo contido na pgina funcionario.jsp. Est pgina responsvel pela exibio da relao de funcionrios cadastrados e permite ao usurio do sistema acesso a incluir novos funcionrios, alterar dados de um funcionrio ou mesmo excluir um funcionrio cadastrado. Um ponto forte utilizado aqui, foi o uso da tag library do Struts2, que encapsula o cdigo, tornando-o mais simples e de fcil manuteno.
<%@ taglib prefix="s" uri="/struts-tags"%> [] <s:url id="incluirFuncionario" action="formFuncionario.action"/> <s:a href="%{incluirFuncionario}">Incluir Funcionrio</s:a> [] <h1><s:text name="Listagem de Funcionrios"/></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. Admisso"/></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> []
U
A
N
varivel
Figura 35 Parte do cdigo da pgina funcionario.jsp.
do struts, nesse caso ficou definido que todas as tags so precedidas pela letra s. funEntity utilizada neste cdigo est declarada na classe FuncionarioAction, nesta classe constam tambm os mtodos get e set dessa variavel, o struts trabalha diretamente com esses mtodos.
IM
A primeira linha do cdigo mostra a declarao para utilizao das tags
IN A
89
A figura 36, mostra o arquivo formFuncionario.jsp. Este arquivo segue o mesmo padro do arquivo anterior. Ele responsvel por apresentar o formulrio relativo aos dados de funcionrios. utilizado tanto para o cadastro quanto para alterao de dados. A ao neste caso acionada ao clicar no boto de envio do formulrio.
[...] <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 Admisso"/></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 cdigo da pgina funcionarioForm.jsp.
IM
IN A
90
A figura 37, representa partes do cdigo da classe FuncionarioAction. Essa uma classe extendida da classe ActionSupport do Struts2. Nela constam os mtodos mapeados no arquivo struts.xml e que so chamados nas pginas JSPs. importante ressaltar que as variveis criadas abaixo, possuem mtodos get e set, pois atravs deles que Struts2 faz a interao com as pginas JSPs. No mtodo validationSuccessful() foi implementada a tratativa para cadastro de novos funcionrios.
private FuncionarioBO funBO = new FuncionarioBO(); private FuncionarioEntity funEntity; private List<FuncionarioEntity> funcionarios;
N
A
private boolean validationSuccessful() { if (funEntity.getFunNome() == null||funEntity.getFunNome().trim().length() < 1) addActionMessage("O campo Nome obrigatrio"); if (funEntity.getFunCpf()== null|| funEntity.getFunCpf().trim().length() < 1) addActionMessage("O campo CPF obrigatrio"); if (funEntity.getFunRg()== null|| funEntity.getFunRg().trim().length() < 1) addActionMessage("O campo RG obrigatrio"); if (funEntity.getFunCarteiraTrabalho()== null) addActionMessage("O campo Carteira de trabalho obrigatrio"); if (funEntity.getDataAdmissao()== null) addActionMessage("O campo Data de admisso obrigatrio"); if (this.hasActionMessages()) return false; else return true; } [...]
Figura 37 Parte do cdigo da classe FuncionarioAction.
IM
figura 38
IN A
apresenta outros
public class FuncionarioAction extends ActionSupport {
S
mtodos contidos na classe
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;
FuncionarioAction. Todos os mtodos apresentados retornam uma String que configurada no arquivo struts.xml. atravs deste mapeamento que ocorrem os direcionamentos para outros mtodos ou pginas JSPs.
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"; } []
so utilizados tanto para incluso de novos funcionrios, como para alterao dos
dados de um funcionrio. O primeiro mtodo responsvel por apresentar o formulrio de incluso/alterao. O segundo responsvel por efetuar a incluso ou a alterao. A validao realizada pelo campo cdigo do funcionrio. Todos estes mtodos delegam a ao para outro mtodo, contido nas classes BO.
IM
Figura 38 Outros mtodos da classe FuncionarioAction.
Nesta classe os mtodos trazParaIncluirOuAlterar e incluirOuAlterar
IN A
92
A figura 39 mostra o cdigo contido na classe FuncionarioBO. Esta classe possui apenas um atributo chamado dao. Este utilizado para acessar os mtodos de persistncia 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); }
N
}
Figura 39 Cdigo da classe FuncionarioBO.
uma interface e define quais mtodos devem ser implementados na classe FuncionarioHibernateDAO.
IM
A figura 40 apresenta o cdigo da classe FuncionarioDAO. Essa classe
IN A
93
package br.com.sigecomp.dao; import java.util.List; import br.com.sigecomp.entity.FuncionarioEntity; public interface FuncionarioDAO { public public public public public } List getTodosFuncionarios(); FuncionarioEntity getFuncionario(Integer codigo); void alterarFuncionario(FuncionarioEntity fun); void incluirFuncionario(FuncionarioEntity fun); void excluirFuncionario(Integer codigo);
Figura 40 Cdigo da classe FuncionarioDAO.
A FuncionarioDAO.
figura
41
apresenta
parte
do
cdigo
da
classe
FuncionarioHibernateDAO. Essa classe implementa a interface definada na classe
package br.com.sigecomp.dao; import import import import import public
java.util.List; org.hibernate.Query; org.hibernate.Session; org.hibernate.Transaction; br.com.sigecomp.entity.FuncionarioEntity; 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 cdigo da classe FuncionarioHibernateDAO.
IM
IN A
94
O uso do framework hibernate3 permite o encapsulamento da persistncia dos dados. Utilizou-se a linguagem Hibernate Query Language (HQL). A figura 42 mostra parte do cdigo da classe FuncionarioEntity, responsvel pelo mapeamento objeto relacionarl. Como possvel observar, utilizou-se a anotaes do framework Hibernate3. Esse cdigo foi gerado automaticamente pelo Eclipse com o uso do Hibernate Code Generation.
package br.com.sigecomp.entity; //Generated 29/05/2008 00:29:56 by Hibernate Tools 3.2.0.beta8 import import import import import import import import import java.util.Date; javax.persistence.Column; javax.persistence.Entity; javax.persistence.GeneratedValue; javax.persistence.GenerationType; javax.persistence.Id; javax.persistence.Table; javax.persistence.Temporal; javax.persistence.TemporalType;
/** * Funcionario generated by hbm2java */ @Entity public class FuncionarioEntity {
@Table(name = "funcionario", catalog = "piramidebd", uniqueConstraints = {})
// Fields @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name = "fun_codigo", unique = true, nullable = false, insertable = true, updatable = false) private Integer funCodigo; @Column(name = "fun_nome", unique = false, nullable = true, insertable = true, updatable = true, length = 40) private String funNome; @Column(name = "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 cdigo da classe FuncionarioHibernateDAO.
IM
IN A
95
A figura 43 mostra a interface grfica do sistema. As funcionalidades relativas ao controle de funcionrio mostrada na pgina funcionario.jsp. Os links incluir funcionrio, alterar e excluir, como descrito anteriormente, so repsonsveis pela chamada dos mtodos da classe FuncionarioAtion. Tais mtodos esto mapeados no arquivo struts.xml.
Figura 43 Interface grfica do caso de uso manter dados de funcionrio.
IM
IN A
96
5 PERSISTNCIA DE DADOS
A persistncia dos dados refere-se em converter os dados volteis utilizados no sistema em dados no volteis, inserindo-os em um banco de dados, por exemplo. Neste captulo apresentado o Diagrama Entidade Relacionamento, muito conhecido como DER. Faz parte deste tpico tambm, apresentar como foi feito o mapeamento objeto relacional e a persistncia dos dados com o auxilio do framework Hibernate3.
5.1 Padro de Projeto DAO
Problema: voc deseja encapsular o acesso e a manipulao de dados em uma camada separada. [...] Soluo: use um Data Access Object para abstrair e encapsular todo o acesso ao armazenamento persistente. O DAO gerencia a conexo 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 padres de projeto utilizados para o mapeamento objeto relacional com a funo de persistir objetos em uma base de dados. O DAO permite abstrair e encapsular todo o acesso a uma fonte de persistncia e gerenciar automaticamente a conexo com esta fonte de dados para obter e armazenar os dados. Ele ainda implementa o mecanismo de acesso necessrio 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, possvel desacoplar a implementao do armazenamento do restante da aplicao. 5.2 Diagrama de Entidade e Relacionamento
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 relaes entre as entidades. A figura 45
IM
A figura 44 ilustra o modelo lgico do DER (Diagrama Entidade
IN A
97
mostra o DER de maneira fsica. Para o desenvolvimento do DER foi utilizado o software Platinum ErWin.
IM
IN A
98
Figura 44 Diagrama de Entidade e Relacionamento modelo lgico.
U N IM A IN S
99
Figura 45 Diagrama de Entidade e Relacionamento modelo fsico.
U N IM A IN S
100
5.3 Mapeamento Objeto Relacional
Mapeamento Objeto relacional uma tcnica de desenvolvimento utilizada para reduzir a impedncia da programao orientada aos objetos utilizando bancos de dados relacionais. As tabelas do banco de dados so representadas atravs de classes e os registros de cada tabela so representados como instncias das classes correspondentes.
O Java Database Connectivity (JDBC) o padro da indstria para conectividade entre a linguagem de programao 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. Atravs 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.
N U
5.3.2 Mapeamento Objeto Relacional utilizando o Hibernate
framework Hibernate da camada de integrao. Trata-se de um framework escrito na linguagem Java, mas tambm disponvel 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 aplicao. importante ressaltar que o
IM
Persistncia automtica 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 essncia, transforma dados de uma representao para a outra. (BAUER, Hibernate em ao, 2005)
Neste projeto utilizou-se, para o mapeamento objeto relacional, o
IN A
5.3.1 Mapeamento Objeto Relacional utilizando JDBC
101
Hibernate um framework de cdigo aberto, distribudo com a licena LGPL. Foi utilizado o Hibernate Annotations, que permite anotaes (linguagem utilizada pelo framework Hibernate3) em classes POJO. Atravs 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: localizao do banco, usurio, 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" "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"> <!- tag raiz --> <hibernate-configuration> <session-factory> <!-tag para inserir a localizao(url) da base de dados--> <property name="hibernate.connection.url"> jdbc:mysql://localhost:3306/piramidebd </property> <!- tag para declarar o usurio no banco de dados --> <property name="hibernate.connection.username">root</property> <!- tag para declarar a senha utilizada por este usurio --> <property name="hibernate.connection.password">root</property> <property name="hibernate.current_session_context_class">thread</property>  <property name="hibernate.dialect"> org.hibernate.dialect.MySQLDialect</property>  <property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>  <property name="show_sql">true</property>  <property name="connection.pool_size">1</property> 
 <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 responsvel pela configurao do Hibernate3
IM
Utilizou-se dois tipos de classes para o mapeamento e persistncia de
IN A
102
dados, cada qual com suas responsabilidades e atribuies. Para as classes de entidade atribuiu-se a responsabilidade de mapear os dados, enquanto as classes DAO ficaram responsveis pela persistncia dos dados. Classes de Entidade: os POJOS, que so as classes persistentes, so as nossas entidades. Nessa classe encontram-se os atributos, um construtor, os mtodos de acesso getters and setters e as anotaes do hibernate3. Dentre as mais utilizadas esto: @Id, @Column, @Table, @generatedValue. Classes DAO: so utilizadas para persistir as entidades. Atravs do HibernateUtil mtodos responsveis 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 contm os atributos, construtor e mtodos getters and setters. Nessa classe encontram-se as annotations do Hibernate
Detalhe do Mapeamento Objeto Relacional

Tabela do SGBD
Import import import import javax.persistence.Column; javax.persistence.Entity; javax.persistence.Id; javax.persistence.Table;
N U
IM
Classe LoginEntity
Figura 47 Detalhe do mapeamento objeto relacional.
IN A
//atributos @Id
@Entity @Table (name = "login" , catalog = "piramidebd" , uniqueConstraints = {}) public class LoginEntity implements java.io.Serializable {
@GeneratedValue (strategy = GenerationType.Auto)

@Column(name = "log_codigo") private int logCodigo ; @Column(name = "log_usuario") private String logUsuario; @Column(name = "log_senha") private String logSenha ; . . .
pode-se realizar as transaes (select, save, update, delete). Aqui encontram-se os
103
6 PROJETO DE INTERFACE
projeto
de
interface
de
importncia
relevante
para
desenvolvimento de sistemas, pois a interface est diretamente ligada ao usurio do sistema. Caso a interface seja esteticamente desagradvel ou de difcil navegabilidade, o usurio pode ter dificuldades em utilizar o software. As cores tambm devem ser usadas com equilbrio, de maneira harmnica. Sommerville (2003, p. 278) afirma que:
O bom projeto de interface com o usurio fundamental para o sucesso de um sistema. Uma interface que difcil de ser utilizada, na melhor das hipteses, resultar em um alto nvel de erros do usurio. Pior ainda, os usurios simplesmente se recusaro a utilizar o sistema de software, independentemente de sua funcionalidade. Se as informaes forem apresentadas de maneira confusa ou enganosa, os usurios podero se confundir com o significado dessas informaes. Eles podem iniciar uma seqncia de aes que venham a corromper os dados ou mesmo a causar falhas catastrficas no sistema.
6.1 Tecnologias utilizadas
aplicativos web, possvel encontrar uma grande diversidade de tecnologias e linguagens para o desenvolvimento da interface grfica. Neste projeto utilizou-se Java Server Pages para gerao das pginas dinmicas. A configurao do layout ficou isolada atravs do uso de arquivos CSS (Cascading Style Sheets), de forma que
todas as informaes sobre formataes de fontes e tabelas ficaram em um nico local. Desta maneira, possvel facilitar a manuteno do sistema, separando ainda mais
o cdigo de programao, do cdigo utilizado para interface. A figura a seguir, apresenta a tela inicial do SIGECOMP
IM
Na rea de desenvolvimento de softwares, quando se trata de
IN A
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 aes indevidas por parte do usurio. Caso o usurio no entre com usurio e senha validos, uma mensagem exibida.
U
Figura 49 Tela de login do sistema SIGECOMP.
IM
IN A
105
A figura abaixo apresenta o menu principal do sistema SIGECOMP. Aps realizar login no sistema, o usurio direcionado para esta tela. importante ressaltar que caso seja necessrio, o layout do sistema pode ser totalmente refeito sem interferir nas funcionalidades da aplicao.
6.2 Diagrama de estados de navegao
N
uso realizar login.
IM
Figura 50 Tela com o menu principal do sistema SIGECOMP.
A figura 51 apresenta o diagrama de estado de navegao do caso de
IN A
106
Figura 51 Diagrama de navegabilidade do caso de uso Realizar Login.
IM
IN A
107
7 CONCLUSES
Este trabalho utilizou padres e tecnologias amplamente empregados em um ambiente de desenvolvimento de software profissional. O sistema web SIGECOMP, apesar de ter sido desenvolvido parcialmente, mostrou a viabilidade da construo de um sistema para gesto comercial de papelaria por meio dos artefatos apresentados. No que tange ao uso da engenharia de software, conclui-se que ela conduziu esse processo de construo do sistema, desde a especificao, passando pelo projeto e desenvolvimento, podendo ainda ser utilizada no O levantamento e a anlise dos requisitos foram fundamentais para o conhecimento das necessidades do cliente e compreenso dos processos usados pela empresa. Propiciou, ainda, uma interao entre os desenvolvedores e os funcionrios da empresa, estabelecendo um clima de confiana mtua. O emprego da UML foi fundamental para documentar o desenvolvimento do software e mostrar de maneira clara e consistente o funcionamento do sistema atravs de seus principais diagramas, como o diagrama de casos de uso, o diagrama de classes e o diagrama de seqncia. A ferramenta CASE, o Entreprise Architect, permitiu a elaborao dos diagramas com facilidade. Trata-se de um software de operao simples, com inmeros recursos. A equipe considera importante explor-lo melhor, para conhecer com mais profundidade as suas funcionalidades. gerenciamento de modificaes e evoluo do SIGECOMP.
N
de orientao a
IM
objeto
O emprego da linguagem de programao Java, atravs do paradigma amplamente utilizado no mercado, permitiu o
desenvolvimento de uma soluo dentro de padres atuais e possibilitou o uso de recursos tecnolgicos, como as ferramentas de desenvolvimento e frameworks que imprimiram grande produtividade no processo de construo do software. O uso do padro MVC contribuiu para que o sistema fosse projetado, com uma melhor separao entre os dados do negcio e a interface com usurio. Durante o desenvolvimento foi possvel perceber que essa separao favorece a independncia dos componentes, de modo que as alteraes que se fizeram necessrias durante a implementao foram realizadas de forma simples, interferindo pouco na codificao de outras classes. Observa-se que a manuteno
IN A
108
do sistema, tambm, dever ser facilitada. O emprego do framework Struts2 foi de grande importncia, uma vez que otimizou a implementao da estrutura MVC. Caso contrrio seria necessrio a criao de classes Servlets para atuarem como controlador, o que tornaria mais complexa a implementao do sistema. O uso dos padres de projeto possibilitou a diviso clara das responsabilidades de cada classe e reforou o conceito da diviso em camadas. Implementou-se, com os recursos do Struts2, o padro Front Controller garantindo o gerenciamento centralizado das requisies. O emprego do padro Business Object possibilitou o isolamento das regras de negcio dos demais componentes da responsvel pela manipulao dos dados. Dessa forma, tornaram-se transparentes apresentou boa performance.
Finalmente, este projeto mostra que possvel desenvolver um sistema de gesto comercial para papelaria utilizando os conceitos da Engenharia de Software, juntamente com o paradigma de orientao a objetos e as boas prticas de programao. Entretanto, de acordo com a proposta de projeto, os mais superficial. captulos Persistncia de Dados e Projeto de Interface foram abordados de forma implementao deste projeto, bem como melhorias na documentao do mesmo.
IM
Assim, sugere-se, como trabalhos futuros, a continuidade da
IN A
para os desenvolvedores as operaes junto ao banco de dados, o MySQL, que
aplicao. O padro Data Access Objetct conjugado com o framework Hibernate3 foi
109
REFERNCIAS BIBLIOGRFICAS
TORRES, Silvana. Os pequenos tm a nova cara do varejo. Disponvel em: <http://www.empreendedor.com.br/_novo/_br/?secao=Noticias&categoria=137&codi go=2370>. Acesso em: 15 mar. 2009 MAIA, Viviane. Tecnologia j. Pequenas Empresas & Grandes Negcios, So Paulo, set. 2007, p.51-73. FREIRE, Paulo. Educao como prtica da liberdade. Rio de Janeiro: Paz e Terra, 1999. 158 p. PRESSMAN, Roger. Engenharia de Software. Traduo Rosngela Delloso Penteado. 6 ed. So Paulo: McGraw-Hill, 2006. 720p. SOMMERVILLE, Ian. Engenharia de Software. Traduo Andr Maurcio de Andrade Ribeiro. 6 ed. So Paulo: Addison Wesley, 2003. 592p. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: Guia do Usurio. Traduo de Fbio Freitas da Silva. Rio de Janeiro: Campus, 2000. 472 p. GUEDES, Gilleanes. UML 2. Guia da Consulta Rpida. 2.ed. So Paulo: Novatec, 2005. 109p. BEZERRA, Eduardo. Princpios de Anlise e Projeto de Sistemas com UML. Rio de Janeiro: Elsevier, 2002. 286 p. OMG - Object Management Group. Unified Modeling Language. Disponvel em <http://www.uml.org>. Acesso em 08 Mai. 2009. DEITEL, Harvey. Java como programar. Traduo Edson Furmankiewicz Reviso Tcnica Fbio Lucchini. 6 ed. So Paulo: Person Education, 2006. 1199p. TODD, Nick; Mark Szolkowski. Java Server Pages. O Guia do Desenvolvedor. Traduo Edson Furmankiewicz. Rio de Janeiro: Elsevier, 2003. 621p. ALUR, Deepak; Crupi, John; Malks, Dan; Core J2EE Patterns. As melhores prticas e estratgias de design. Traduo Alair Dias Caldas de Morais. 2.ed. Rio de Janeiro: Elsevier Campus, 2004. 587p. ROUGHLEY, Ian. Starting Struts 2. USA: C4Media, 2006. 122p. BAUER, Christian.; King, Gavin ; Hibernate em ao. Traduo Cludio Rodrigues Pistilli, Geane Girotto e Fabio Makoto. Rio de Janeiro: Cincia Moderna, 2005. 532p. GAZOLA, Alexandre; MARQUES, Alex. Mundo OO: Padres de Projeto com Generics. Revista Mundo Java, Curitiba, n. 35, ano VI, maro / abril, 2009. 74p.
IM
IN A
110
ANEXO A- DADOS IMPORTANTES
//ARQUIVO struts.xml <!DOCTYPE struts PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN" "http://struts.apache.org/dtds/struts-2.0.dtd"> <struts> <package name="default" extends="struts-default">    <action name="showLogin"> <result>/jsp/acesso/login.jsp</result> </action>  <action name="login" class="br.com.sigecomp.action.LoginAction"> <result name="input">/jsp/acesso/login.jsp</result> <result name="sucesso">/jsp/acesso/menu.jsp</result> <result name="erro">/jsp/acesso/login.jsp</result> </action>   <action name="listaFuncionarios" method="getTodosFuncionarios" class="br.com.sigecomp.action.FuncionarioAction"> <result name="success">/jsp/funcionario/funcionario.jsp</result> </action>  <action name="formFuncionario" method="trazParaIncluirOuAlterar" class="br.com.sigecomp.action.FuncionarioAction"> <result name="success">/jsp/funcionario/funcionarioForm.jsp</result> </action>  <action name="dadosFuncionario" method="incluirOuAlterar" class="br.com.sigecomp.action.FuncionarioAction"> <result name="success">/jsp/funcionario/funcionario.jsp</result> <result name="input">/jsp/funcionario/funcionarioForm.jsp</result> </action>  <action name="excluirFuncionario" method="excluirFuncionario" class="br.com.sigecomp.action.FuncionarioAction"> <result name="success">/jsp/funcionario/funcionario.jsp</result> </action>   <action name="getTodosClientes" method="getTodosClientes" class="br.com.sigecomp.action.ClienteActionPF"> <result name="success">/jsp/cliente.jsp</result> </action> 
IM
IN A
111 <action name="formClientePF" method="trazParaIncluirOuAlterar" class="br.com.sigecomp.action.ClienteActionPF"> <result name="success">/jsp/clientepfForm.jsp</result> </action>  <action name="formClientePJ" method="trazParaIncluirOuAlterar" class="br.com.sigecomp.action.ClienteActionPJ"> <result name="success">/jsp/clientepjForm.jsp</result> </action>  <action name="dadosClientePF" method="incluirOuAlterar" class="br.com.sigecomp.action.ClienteActionPF"> <result name="success" type="redirect-action"> getTodosClientes </result> <result name="input">/jsp/clientepfForm.jsp</result> </action>  <action name="dadosClientePJ" method="incluirOuAlterar" class="br.com.sigecomp.action.ClienteActionPJ"> <result name="success" type="redirect-action"> getTodosClientes </result> <result name="input">/jsp/clientepjForm.jsp</result> </action>  <action name="excluirClientePF" method="excluirCliente" class="br.com.sigecomp.action.ClienteActionPF"> <result name="success" type="redirect-action"> getTodosClientes </result> </action> <action name="excluirClientePJ" method="excluirCliente" class="br.com.sigecomp.action.ClienteActionPJ"> <result name="success" type="redirect-action"> getTodosClientes </result> </action> </package>   <action name="getTodosFornecedores" method="getTodosFornecedores" class="br.com.sigecomp.action.FornecedorAction"> <result name="success">/jsp/fornecedor.jsp</result> </action>  <action name="formFornecedor" method="trazParaIncluirOuAlterar" class="br.com.sigecomp.action.FornecedorAction"> <result name="success">/jsp/fornecedorForm.jsp</result> </action>  <action name="dadosFornecedor" method="incluirOuAlterar"
IM
IN A
112 class="br.com.sigecomp.action.FornecedorAction"> <result name="success" type="redirect-action"> getTodosFornecedores </result> <result name="input">/jsp/fornecedorForm.jsp</result> </action>  <action name="excluirFornecedor" method="excluirFornecedor" class="br.com.sigecomp.action.FornecedorAction"> <result name="success" type="redirect-action"> getTodosFornecedores </result> </action>
  <action name="getTodosProdutos" method="getTodosProdutos" class="br.com.sigecomp.action.ProdutoAction"> <result name="success">/jsp/produto.jsp</result> </action>
 <action name="formProduto" method="trazParaIncluirOuAlterar" class="br.com.sigecomp.action.ProdutoAction"> <result name="success">/jsp/produtoForm.jsp</result> </action>  <action name="dadosProduto" method="incluirOuAlterar" class="br.com.sigecomp.action.ProdutoAction"> <result name="success" type="redirect-action"> getTodosProdutos </result> <result name="input">/jsp/produtoForm.jsp</result> </action>  <action name="excluirProduto" method="excluirProduto" class="br.com.sigecomp.action.ProdutoAction"> <result name="success" type="redirect-action"> getTodosProdutos </result> </action> </struts>
IM
IN A

TCC Alberto Marcos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC Alberto Marcos

Enviado por

Direitos autorais:

Formatos disponíveis

UNIO EDUCACIONAL MINAS GERAIS S/C LTDA FACULDADE DE CINCIAS APLICADAS DE MINAS

Autorizada pela Portaria no 577/2000 MEC, de 03/05/2000 BACHARELADO EM SISTEMAS DE INFORMAO

ALBERTO DUMONT ALVES OLIVEIRA MARCOS ARAJO DA CUNHA

SOFTWARE PARA GESTO

ALBERTO DUMONT ALVES OLIVEIRA MARCOS ARAJO DA CUNHA

SOFTWARE PARA GESTO

Orientador: Prof. M.Sc. Francisco J. Muller

ALBERTO DUMONT ALVES OLIVEIRA MARCOS ARAJO DA CUNHA

SOFTWARE PARA GESTO COMERCIAL DE PAPELARIA

Orientador: Prof. M.Sc. Francisco J. Muller

Uberlndia, 08 de Julho de 2009.

UML, JSP, Java, JEE, MVC, Struts, padres de projeto.

LISTA DE ABREVIATURAS E SMBOLOS

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

5 PERSISTNCIA DE DADOS .........................................................................................................96

6 PROJETO DE INTERFACE .........................................................................................................103

3 ANLISE DO SISTEMA ................................................................................................................25

1.1 Cenrio Atual

1.1.1 O Desenvolvimento de Softwares

indispensvel para o desempenho de atividades nas mais diversas reas como

Implementao da fase de projeto em cdigo executvel atravs do uso de uma linguagem de

Quadro 1 Atividades tpicas de um processo de desenvolvimento de software

As atividades de levantamento e anlise de requisitos so de extrema

desenvolvimento. Entretanto, algumas atividades so comuns maioria dos

1.1.2 O Apoio da Tecnologia aos Processos Comerciais

A tecnologia da informao oferece inmeros recursos para auxiliar nos

Tecnologias e prticas fazem parte da Engenharia de Software,

programao. As duas atividades finais abordam a questo de testes, qualidade de

at uma soluo sofisticada e/ou personalizada. Os softwares de prateleira so

Em se tratando de software de gesto comercial para papelarias, em

1.3.1 Objetivo Geral

base nos conceitos da Engenharia de Software e do paradigma de orientao a

1.3 Objetivos do trabalho

Desenvolver um sistema web para gesto comercial de papelaria com

O problema em questo se resume em como realizar um projeto para o

1.2 Identificao do problema

sustenta-se na necessidade de um estudo mais profundo de como desenvolver um

A percepo da empresa parceira em utilizar a plataforma web,

De acordo com Freire (1999), a teoria implica numa insero na

O capitulo 6 faz uma breve introduo relativa ao projeto de interface,

No captulo 5, feita uma sntese das tecnologias utilizadas para o

viso do problema a ser resolvido. Durante o levantamento de requisitos, a equipe

aplicao da atividade de levantamento de requisitos da Engenharia de Software,

excludos. Os dados relevantes para fornecedor so os documentos de identificao

representantes locais, que so os contatos com o fornecedor. Uma vez cadastrado,

Contas a pagar podem ser lanadas, consultadas, alteradas ou excludas. As contas

tambm podem ser lanadas automaticamente no caso de compra realizada a

cheque pr-datado ou credirio prprio para clientes pessoa jurdica). Ao lanar a

11. O sistema dever permitir o controle de contas a receber.

Quadro 2 Requisitos funcionais e no funcionais.

mente so polticas, validaes, restries ou condies especificas. Tais regras

As regras de negcio definem como uma empresa funciona, normal

2. O sistema dever permitir ao usurio manter dados de clientes.

RN-08 RN-09 RN-10 RN-11 RN-12 RN-13 RN-14

RN-15 RN-16 RN-17 RN-18 RN-19 RN-20 RN-21

Quadro 3 Regras de Negcio.

medida em que se aplica anlise neste desenvolvimento, pois quando os atributos

Diagrama de Componente Diagrama de Execuo

do sistema a ser construdo.

Conforme Bezerra (2002, p.57):

Usando basicamente quatro elementos apresentados de forma