TCC Wagner Alves

FACULDADE SO LOURENO
BACHARELADO EM SISTEMAS DE INFORMAO
PROPRIEDADE DE BENS VIRTUAIS
WAGNER ALVES DA SILVA JUNIOR
So Loureno
2013
Trabalho de Concluso de Curso submetido Faculdade So Loureno de So Loureno, como parte dos requisitos para a obteno do grau de Bacharel em Sistemas de Informao.
Orientador: Prof. Aldyr Amaro.
So Loureno
2013

Trabalho de Concluso de Curso submetido Faculdade So Loureno de So Loureno, como parte dos requisitos para a obteno do grau de Bacharel em Sistemas de Informao.
Orientador: Prof. Aldyr Amaro
So Loureno, xx de _____ de 201x. Banca Examinadora: Prof. Aldyr Amaro (Orientador) Prof. ___________________ Prof. ___________________
So Loureno
2013
DEDICATRIA
Dedico esse projeto minha famlia que sempre me apoiou na deciso de me tornar Bacharel em Sistemas de Informao, que sempre estiveram presentes quando precisei, que me motivou quando as dificuldades eram mais pesadas do que podia suportar, que me apoiou at as mais altas horas da madrugada enquanto trabalhava nesse projeto, que nunca me deixou desistir dos meus sonhos e finalmente, a todos meus colegas, parceiros e amigos que estiveram comigo at aqui.
AGRADECIMENTOS
Ao meu pai que pagou boa parte da faculdade, a minha me que me fez continuar quando eu no mais queria e ao Google.
RESUMO
Este projeto teve por objetivo a modelagem de uma loja virtual para um grupo de artesos. Atravs de algumas reunies com os membros do grupo, pudemos conhecer mais a fundo o universo que compe esses trabalhos artesanais e saber as reais necessidades do nosso cliente. Com o levantamento dos requisitos em mos, nosso prximo passo seria iniciar a documentao do sistema, aplicando os conhecimentos adquiridos.Foi de extrema importncia o uso da UML ( Unified Modeling Language), para 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 foi batizado de SYSARTS. Foi utilizado o modelo MVC2 ( Model-View-Controller) seguindo alguns padres de desenvolvimento JEE ( Java Enterprise Edition), entre eles o FrontController, o Data Access Object e o Business Object, dando nfase s camadas de apresentao, negcios e integrao. Como se trata de uma aplicao web distribuda, usamos o Framework Struts, o qual implementa o padro JEE FrontController; o mapeamento objeto relacional foi implementado com o uso do Framework Hibernate.
Palavras Chave: Java, Struts, Hibernate, Framework, MVC, UML, sistema, padres de projeto, artesos.
ABSTRACT
This project aimed to model a virtual store for a group of artisans. Through several meetings with group members, we know more deeply the universe that make these crafts and learn the real needs of our customer. With the lifting of the requirements in hand, our next step would be to start the system documentation, applying the knowledge acquired. At that stage it was extremely important to use the UML (Unified Modeling Language), to show a clear and consistent system operation, through its principal diagrams such as Use Case Diagram, Class Diagram and Sequence Diagram. The system was named SYSARTS. We made use of the MVC2 model (Model-View-Controller) following some patterns of development JEE (Java Enterprise Edition), including the FrontController, Data Access Object and Business Object, giving emphasis to the presentation layers, and business integration. As this is a distributed web application, we use the Struts Framework, which implements the standard JEE FrontController, the object relational mapping was implemented using the Hibernate framework.
Keywords: Java, Struts, Hibernate, Framework, MVC, UML, system, design patterns, artisans.
LISTA DE FIGURAS
Figura 1 Diagrama de Casos de Uso.....................................................................38 Figura 2 Diagrama de Classes...............................................................................54 Figura 3 Fronteira de Cliente..................................................................................55 Figura 4 Fronteira de Arteso................................................................................55 Figura 5 Fronteira de Produto................................................................................55 Figura 6 Fronteira de Categoria.............................................................................56 Figura 7 Fronteira de Carrinho...............................................................................56 Figura 8 Classe Controladora de Cliente...............................................................56 Figura 9 Classe Controladora de Arteso..............................................................57 Figura 10 Classe Controladora de Produto...........................................................57 Figura 11 Classe Controladora de Carrinho..........................................................57 Figura 12 Entidade de Cliente................................................................................57 Figura 13 Entidade de Artesao..............................................................................58 Figura 14 Entidade de Categoria...........................................................................58 Figura 15 - Entidade de Produto...............................................................................59 Figura 16 - Diagrama de Seqncia Manter Dados de Arteso...............................60 Figura 17 - Diagrama de Seqncia Manter Categoria............................................61 Figura 18 - Diagrama de Seqncia Manter Dados de Cliente................................62 Figura 19 - Diagrama de Seqncia Manter Newsletter...........................................63 Figura 20 - Diagrama de Seqncia Manter Produto...............................................64 Figura 21 - Diagrama de Seqncia Gerar consultas...............................................65 Figura 22 - Diagrama de Seqncia Gerar relatrios...............................................65 Figura 23 - Diagrama de Seqncia Realizar encomenda.......................................66 Figura 24 - Diagrama de Seqncia Gerar carrinho.................................................67 Figura 25 - Diagrama de Seqncia Cancelar pedido..............................................68 Figura 26 - Diagrama de Seqncia Efetuar pedido.................................................69 Figura 27 - Diagrama de Seqncia Efetuar pagamento.........................................70
Figura 28 Funcionamento da persistncia de dados..............................................71 Figura 29 Modelo Arquitetural do Padro de Projetos DAO....................................73 Figura 30 - Diagrama de Sequncia Utilizao do DAO em classes persistentes..74 Figura 31 - Diagrama de Entidade e Relacionamento...............................................77 Figura 32 - Bibliotecas utilizadas pelo Hibernate.......................................................80
LISTA DE QUADROS
Quadro 1 - Regra de Negcio RN-01........................................................................26 Quadro 2 Regra de Negcio RN-02.......................................................................26 Quadro 3 Regra de Negcio RN-03.......................................................................27 Quadro 4 Regra de Negcio RN-04.......................................................................27 Quadro 5 Regra de Negcio RN-05.......................................................................27 Quadro 6 Regra de Negcio RN-06.......................................................................27 Quadro 7 Regra de Negcio RN-07.......................................................................27 Quadro 8 Regra de Negcio RN-08.......................................................................28 Quadro 9 Regra de Negcio RN-09.......................................................................28 Quadro 10 Regra de Negcio RN-10.....................................................................28 Quadro 11 Regra de Negcio RN-11.....................................................................28 Quadro 12 Regra de Negcio RN-12.....................................................................29 Quadro 13 Regra de Negcio RN-13.....................................................................29 Quadro 14 Caso de Uso Manter dados do cliente...............................................38 Quadro 15 Caso de Uso Manter dados do arteso............................................39 Quadro 16 Caso de Uso Manter dados do produto............................................40 Quadro 17 Caso de Uso Manter dados de categoria.........................................41 Quadro 18 Caso de Uso Manter newsletter........................................................42 Quadro 19 Caso de Uso Gerar relatrios...........................................................43 Quadro 20 Caso de Uso Gerar consultas...........................................................44 Quadro 21 Caso de Uso Realizar encomendas.................................................45 Quadro 22 Caso de Uso Comprar......................................................................46 Quadro 23 Caso de Uso Efetuar pedido.............................................................47 Quadro 24 Caso de Uso Atualizar estoque........................................................48 Quadro 25 Caso de Uso Notificar venda............................................................49
Quadro 26 Caso de Uso Cancelar pedido..........................................................50 Quadro 27 Caso de Uso Efetuar pagamento......................................................51
Quadro 28 Classe ArtesaoDAO Interface com o SGBD......................................75 Quadro 29 Classe ArtesaoHibernateDAO Manipulao de dados no SGBD......77 Quadro 30 Hibernate.cfg.xml Configurao de conexo a base de dados..........81 Quadro 31 Hibernate.cfg.xml Comunicao com o banco de dados...................82 Quadro 32 Hibernate.cfg.xml Connection pool.....................................................82 Quadro 33 Hibernate.cfg.xml Dialeto...................................................................82 Quadro 34 Hibernate.cfg.xml Sesso Hibernate..................................................82 Quadro 35 Hibernate.cfg.xml Sesso Hibernate..................................................83 Quadro 36 Hibernate.cfg.xml Show SQL.............................................................83 Quadro 37 Hibernate.cfg.xml Hibernate.hbm2ddl.auto........................................83 Quadro 38 Hibernate.cfg.xml Mapping classes....................................................84
LISTA DE ABREVIATURAS E SMBOLOS
API - Application Programming Interface BO - Business Object CEP - Cdigo e Endereamento Postal CNPJ - Cadastro Nacional da Pessoa Jurdica CPF - Cadastro de Pessoa Fsica CSS - Cascading Style Sheets DAO - Data Acess Object HTML HTTP JEE - Java Enterprise Edition JSP Java Server Pages Hypertext Markup Language - Hypertext Transfer Protocol
MVC - Model-view-controller SQL - Structured Query Languague UML XML - Extensible Markup Language Unified Modeling Language
SUMRIO
1INTRODUO................................................................................................................................... 16 1.1CENRIO ATUAL ............................................................................................................................ 16 1.2IDENTIFICAO DO PROBLEMA........................................................................................................ 19 1.3OBJETIVOS DO TRABALHO ............................................................................................................. 19 1.3.1Geral.................................................................................................................................... 19 1.3.2Especficos.......................................................................................................................... 20 1.3.3Justificativa ......................................................................................................................... 20 1.4ORGANIZAO DO TRABALHO........................................................................................................ 21 2ESPECIFICAO DO PROBLEMA.................................................................................................. 22 1.5DESCRIO DO NEGCIO E DA EMPRESA........................................................................................ 22 1.5.1Requisitos funcionais .......................................................................................................... 22 1.5.2Requisitos no funcionais.................................................................................................... 25 1.6REGRAS DE NEGCIO.................................................................................................................... 26 SO POLTICAS, CONDIES OU RESTRIES QUE DEVEM SER CONSIDERADAS NA EXECUO DOS PROCESSOS EXISTENTES EM UMA ORGANIZAO. DESCREVEM A MANEIRA PELA QUAL A ORGANIZAO FUNCIONA.......................................................................................................................................... 26 QUADRO 1 DOCUMENTAO DA REGRA DE NEGCIO RN 01..........................................................26 QUADRO 2 DOCUMENTAO DA REGRA DE NEGCIO RN 02..........................................................26 QUADRO 3 DOCUMENTAO DA REGRA DE NEGCIO RN 03..........................................................27 QUADRO 4 DOCUMENTAO DA REGRA DE NEGCIO RN 04..........................................................27 QUADRO 5 DOCUMENTAO DA REGRA DE NEGCIO RN 05..........................................................27 QUADRO 6 DOCUMENTAO DA REGRA DE NEGCIO RN 06..........................................................27 QUADRO 7 DOCUMENTAO DA REGRA DE NEGCIO RN 07..........................................................27 QUADRO 8 DOCUMENTAO DA REGRA DE NEGCIO RN 08..........................................................28 QUADRO 09 DOCUMENTAO DA REGRA DE NEGCIO RN 09.........................................................28 QUADRO 10 DOCUMENTAO DA REGRA DE NEGCIO RN 10........................................................28 QUADRO 11 DOCUMENTAO DA REGRA DE NEGCIO RN 11........................................................28 QUADRO 12 DOCUMENTAO DA REGRA DE NEGCIO RN 12........................................................29 QUADRO 13 DOCUMENTAO DA REGRA DE NEGCIO RN 13........................................................29 3ANLISE DE PROJETO DO SISTEMA............................................................................................. 30 1.7INTRODUO................................................................................................................................. 30 1.8FERRAMENTA DE MODELAGEM........................................................................................................ 31 1.9UNIFIED MODELING LANGUAGE UML...........................................................................................32 1.10CASOS DE USO........................................................................................................................... 35 CASOS DE USO ESPECIFICAM O COMPORTAMENTO DO SISTEMA OU PARTE(S) DELE E DESCREVEM A FUNCIONALIDADE DO SISTEMA DESEMPENHADA PELOS ATORES. VOC PODE IMAGINAR UM CASO DE USO COMO UM CONJUNTO DE CENRIOS, ONDE CADA CENRIO UMA SEQNCIA DE PASSOS A QUAL DESCREVE UMA INTERAO ENTRE UM USURIO E O SISTEMA. OS CASOS DE USO SO REPRESENTADOS EM FORMA DE ELIPSE.......................................................................................................................... 35 1.11CLASSES..................................................................................................................................... 36 1.12DIAGRAMA DE CASOS DE USO..................................................................................................... 38 1.13DESCRIO DOS CASOS DE USO E ATORES.................................................................................38 1.13.1Descrio dos Atores......................................................................................................... 53 Administrador............................................................................................................................... 53 Arteso........................................................................................................................................ 53 Cliente......................................................................................................................................... 53 1.14CLASSES DE ANLISE................................................................................................................... 54 1.14.1Diagrama de Classes de Negcio......................................................................................54 1.14.2Classes de Fronteira.......................................................................................................... 55 1.14.3Classe Controladora.......................................................................................................... 56 1.14.4Classe de Entidade............................................................................................................ 58 1.15DIAGRAMA DE SEQNCIA........................................................................................................... 60
4PERSISTNCIA DE DADOS............................................................................................................. 71 1.16INTRODUO............................................................................................................................... 71 5 CONCLUSES............................................................................................................................. 85 REFERNCIAS BIBLIOGRFICAS.................................................................................................... 87 BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: GUIA DO USURIO. TRADUO DE FBIO FREITAS DA SILVA. RIO DE JANEIRO: CAMPUS, 2000. 472 P.......................................................87 DEITEL, HARVEY. JAVA COMO PROGRAMAR. TRADUO EDSON FURMANKIEWICZ REVISO TCNICA FBIO LUCCHINI. 6 ED. SO PAULO: PERSON EDUCATION, 2006............87 DEITEL, HARVEY. JAVA COMO PROGRAMAR. TRADUO EDSON FURMANKIEWICZ. 3ED. SO PAULO: PERSON EDUCATION, 2001. 1199P...........................................................................87 GUEDES, GILLEANES. UML 2 GUIA DA CONSULTA RPIDA. 2.ED. SO PAULO: NOVATEC, 2005. 109P........................................................................................................................................... 87 PRESSMAN, ROGER. ENGENHARIA DE SOFTWARE. TRADUO ROSNGELA DELLOSO PENTEADO. 6 ED. SO PAULO: MCGRAW-HILL, 2006. 720P........................................................87 SOMMERVILLE, IAN. ENGENHARIA DE SOFTWARE. TRADUO ANDR MAURCIO DE ANDRADE RIBEIRO. 6 ED. SO PAULO: ADDISON WESLEY, 2003. 592P....................................87 TODD, NICK; MARK SZOLKOWSKI. JAVA SERVER PAGES O GUIA DO DESENVOLVEDOR. TRADUO EDSON FURMANKIEWICZ. RIO DE JANEIRO: ELSEVIER, 2003. 621P.....................87 WAZLAWICK, RAUL SIDNEI. ANALISE E PROJETO DE SISTEMAS DE INFORMAO ORIENTADOS A OBJETO. RIO DE JANEIRO: ELSEVIER, 2004. 298P...........................................87 ANEXO A- DADOS IMPORTANTES................................................................................................... 88 CDIGO FONTE DO PROGRAMA..................................................................................................... 88
16
1 INTRODUO
1.1 Cenrio atual
O artesanato o ato no qual o produtor (arteso) possui os meios de produo e trabalha geralmente em sua prpria casa, realizando todas as etapas da produo, desde o preparo da matria-prima, at o acabamento do produto. A implantao de uma Loja Virtual uma etapa muito importante para o sucesso de um negcio, com o avano da tecnologia e com o aquecimento da Internet, a divulgao de produtos via Web possibilita um maior reconhecimento alm de atingir vrios nichos de mercado. Comrcio Eletrnico o canal mais moderno e simples de vendas, no envolve pesados recursos de investimentos ou de pessoal e pode ser acessado em qualquer lugar do mundo atravs da INTERNET. Os dados so reais: o comrcio eletrnico ( e-commerce) no pas est crescendo a taxas mdias de 40% ao ano. Em 2008 fechou com R$ 8,2 bilhes de faturamento, e a previso para 2010 est na casa dos R$ 15,4 bilhes.
17 Veja o histrico:
Quadro 1 Faturamento Comercio Eletronico Fonte: http://www.lojistaonline.com.br/wtk/pagina/lojista_oque (2010)
As grandes empresas j entenderam a necessidade de ter uma loja virtual para se tornarem mais competitivas e alavancar seus negcios com maior velocidade. E as micro, pequenas e mdias empresas (MPMEs) que representam 93% dos estabelecimentos formais em operao, tambm j entenderam o recado. preciso entrar no mundo do Comrcio Eletrnico (e-commerce) para se tornarem mais competitivas. Alis, o Comrcio Eletrnico a maior revoluo na democratizao do livre comrcio e da igualdade de competio entre grandes e pequenas empresas.
18 Dentro deste contexto, o sistema de Comrcio Eletrnico se destina a:
Empreendedores que querem abrir seu negcio na Internet com baixo investimento inicial e custos operacionais reduzidos.
Comerciantes que desejam ampliar seu canal de vendas, divulgando e vendendo seus produtos em todo o territrio nacional.
Pequenas indstrias em busca de divulgao e ampliao de sua rede de clientes.
Artesos que necessitam de um canal para divulgao de seu trabalho e manuteno de um catlogo atualizado de produtos.
Empresas de servios e profissionais autnomos buscando divulgao do seu negcio.
Empresas com alta rotatividade de produtos requerendo atualizao constante dos sites, como imobilirias e agncias de automveis.
Cooperativas que desejam romper com as barreiras geogrficas e exportar seus produtos.
Com base nas informaes relatadas acima, a no ser que haja uma reverso completa do quadro evolutivo da tecnologia e de todas as tendncias observadas at aqui, as empresas que apostarem no Comrcio Eletrnico tero um enorme e qualificado mercado para conquistar nos prximos anos. Quem duvidar disso corre o risco de perder o foguete da histria.
19 1.2 Identificao do problema
O problema abordado consiste em realizar um projeto para o desenvolvimento de um software Web no modelo de um Comercio Eletrnico onde sero comercializados produtos artesanais realizados por um grupo de Artesos autnomos. Atravs dessa Loja Virtual, ser possvel uma maior divulgao dos produtos dos Artesos envolvidos, aumentando assim suas respectivas receitas. Aplicaremos nesse trabalho todos os conceitos de Engenharia de Software.
1.3 Objetivos do trabalho
1.3.1 Geral
Desenvolver
um
sistema
Web
para
divulgao
comercializao de produtos artesanais. Este documento tem como finalidade a formalizao dos processos de elaborao do projeto de uma Loja Virtual.
20
1.3.2 Especficos
Levantar os requisitos funcionais e no funcionais do sistema; Definir as regras de negcio juntamente com o cliente; Documentar os requisitos utilizando uma linguagem de modelagem especfica (UML);
Utilizar o framework Struts 2 para camada de apresentao e o Hibernate para persistncia;
Utilizar banco de dados MYSQL; Implementar o sistema utilizando linguagem de programao Java; Utilizar linguagem HTML e CSS para implementao da Interface; Utilizar uma ferramenta para elaborao dos diagramas de Casos de Uso, Classes e de Seqncia;
Utilizar os padres de projeto DAO, Front Controller, JEE e MVC; Utilizar uma ferramenta para modelagem de dados;
1.3.3 Justificativa
A exposio de produtos e servios pela Internet torna mais prtica vida dos fornecedores e consumidores dos mesmos, pois com a visualizao e processo de compras online faz com que aumente a abrangncia de exposio por todo pas (em alguns casos internacionalmente divulgados) e acessibilidade a uma maior variedade de produtos/servios prestados.
21 Assim o desenvolvimento de um software para exposio e comercializao de produtos artesanais por todo o territrio nacional trar aos artesos uma integrao maior entre si, podendo visualizar e criar novos produtos partir da idia da variedade encontrada na Loja Virtual. Alm dessa integrao, os consumidores tero um acesso unificado de vrios produtos criados por vrias regies diferentes e assim encontrar com maior facilidade o produto desejado em questo, alm de facilitar na busca do custo x benefcio ideal para sua condio financeira para a aquisio desse tipo de produto.
1.4 Organizao do Trabalho
O trabalho descrito est organizado como se segue:
O captulo 2 descreve o problema a ser abordado. Ainda neste captulo sero apresentados os requisitos do sistema a serem implementados que foram levantados nas reunies com o cliente e as regras de negocio.
O captulo 3 aborda a parte de anlise. O estudo do UML foi fundamental para este captulo, nele so abordados os principais diagramas dessa linguagem.
No captulo 4, feita uma sntese das tecnologias utilizada para o mapeamento objeto relacional e a persistncia dos dados.
Por fim, o capitulo 5 apresenta as concluses obtidas com a pesquisa realizada e o resultado final da experincia do trabalho feito.
22 2 ESPECIFICAO DO PROBLEMA
1.5 Descrio do negcio e da empresa
Um grupo de artesos produz e comercializa seus prprios produtos, sendo todos estes artesanais e feitos individualmente por cada arteso. Em conjunto, estes artesos promovem feiras e eventos para que possam divulgar seu trabalho para a regio e de certa maneira, tornarem-se reconhecidos na sua regio de atuao. A partir de um consenso, os artesos decidiram que poderiam divulgar seu trabalho e comercializar suas mercadorias com mais regies do Brasil, sendo assim desejam um web site, visando melhorar o processo de venda de suas mercadorias, tornando o mais formal e melhor gerenciado. Tomou-se ento necessria a criao de uma loja virtual para exposio e venda destas mercadorias to como negociaes com demais interessados em seus trabalhos.
1.5.1 Requisitos funcionais
De acordo com Sommerville (2003), requisitos funcionais so aqueles que definem funes que o sistema deve fornecer. Manter clientes: O sistema deve permitir o gerenciamento de novos clientes (Incluso, visualizao, alterao, excluso). O visitante do site poder se cadastrar atravs de uma rea disponibilizada na pgina e posteriormente visualizar seus dados fazer alteraes que forem necessrias.
Manter artesos: O sistema deve permitir o gerenciamento de artesos (Incluso, visualizao, alterao, excluso). O gerenciamento total feito pelo administrador do sistema. O arteso j cadastrado pelo administrador poder visualizar seus dados fazer alteraes que forem necessrias.
23
Manter produtos: O sistema deve permitir o gerenciamento de produtos (Incluso, visualizao, alterao, excluso). O arteso responsvel por cadastrar o produto e suas especificaes, fazer alteraes e excluir caso haja necessidade. O administrador do sistema tambm pode efetuar o gerenciamento total de produtos.
Manter categorias: O sistema deve permitir o gerenciamento de categorias (Incluso, visualizao, alterao, excluso). O arteso responsvel por cadastrar a categoria, fazer alteraes e excluir caso haja necessidade. O administrador do sistema tambm pode efetuar o gerenciamento total.
Realizar
encomendas:
O sistema
dever
permitir a
realizao
de
encomendas. Visitantes j cadastrados podem, atravs de um formulrio, fazer uma encomenda em particular para algum arteso. Esse pedido enviado via e-mail ao arteso selecionado. Toda encomenda negociada a parte com o arteso, que define valor do produto, pagamento de frete e forma de pagamento.
Efetuar consultas: O sistema dever permitir que o visitante pesquise por produtos no site. O visitante digita a palavra-chave que deseja procurar e seleciona a categoria especfica ou procura em todo o site. O sistema apresenta os resultados encontrados.
Enviar newsletter: O sistema dever permitir o envio de newsletter. Ao realizar o cadastro no site, o visitante decide se quer receber noticias sobre a loja virtual, sendo que tal opo aparece previamente selecionada. O contedo do newsletter definido preferencialmente pelo arteso.
24
Gerar carrinho de compras: O sistema dever gerar um carrinho de compras. O cliente ao selecionar a opo Comprar de determinado produto, adicionar automaticamente o mesmo em seu carrinho de compras. permitida a incluso, alterao e remoo de itens e produtos do carrinho.
Cancelar pedidos: O sistema dever permitir o cancelamento de um pedido onde no foi confirmado o pagamento. O usurio pode desistir da compra caso ainda no tenha feito o pagamento. O cancelamento deve ser notificado ao arteso do respectivo produto.
Confirmar pagamento: O sistema dever permitir a confirmao de pagamento. Clientes que j tenham fechado o pedido podem atravs de uma opo no seu painel de controle, confirmar o pagamento enviando o comprovante de depsito bancrio.
Confirmar pedido: O sistema dever permitir a confirmao do pedido. Ao escolher todos os produtos desejados e a quantidade de itens, o cliente ter a opo de fechar seu pedido, calculando o frete e confirmando assim sua compra e o valor final.
Gerar relatrios: O sistema dever permitir que sejam gerados relatrios. O administrador do sistema poder atravs de seu painel de controle, gerar relatrios atualizados com dados sobre produtos, artesos, vendas, etc.
Enviar notificao: O sistema dever enviar notificao ao arteso sobre sua pea vendida ou sobre a venda cancelada. Todo arteso que tiver algum produto seu vendido ou num pedido cancelado, dever receber uma mensagem em seu perfil sobre a venda/cancelamento da mercadoria.
25
Controlar estoque: O sistema dever efetuar o controle de estoque. Qualquer tipo de movimentao no estoque dever ser controlado pelo sistema, que dever manter o mesmo sempre atualizado.
Visualizar status do pedido: O sistema dever permitir a visualizao de status do pedido. O cliente poder acessar seu pedido e conferir se o pagamento foi confirmado pelo arteso, se a mercadoria j foi enviada, rastrear o transporte do pedido, etc.
1.5.2 Requisitos no funcionais
De acordo com Sommerville (2003), requisitos no funcionais so aqueles que podem estar relacionados s restries que o sistema deve atender, como por exemplo, requisitos de qualidade ou desempenho.
Acessibilidade de navegadores O site dever se apresentar perfeitamente, tanto visualmente quanto funcionalmente, em todo e qualquer web browser disponvel no mercado, para todas as plataformas.
SGBD Free O sistema de gerenciamento de banco de dados do web site dever ser grtis , j que o cliente no deseja adquirir uma licena sendo que um software gratuito pode suprir todas as necessidades desejveis.
Linguagem de programao Java Todo o software deve utilizar da linguagem de programao JAVA para seu desenvolvimento, suas funcionalidades e obrigaes, excluindo assim qualquer outra tecnologia que no possa ser utilizada em JAVA.
26
Interface Amigvel O aspecto visual do sistema deve ter aparncia agradvel, usual e de fcil compreenso do usurio.
Usabilidade Artesos devem ser capazes de utilizar as funcionalidades do software aps um treinamento. Clientes devem ser capazes de compreender a linguagem visual do site e utilizar suas funes de maneira fcil e intuitiva.
1.6 Regras de negcio
So polticas, condies ou restries que devem ser consideradas na execuo dos processos existentes em uma organizao. Descrevem a maneira pela qual a organizao funciona.
Nome Descrio
Pagamentos
RN- 01
S sero permitidos pagamentos vista e efetuados por depsito bancrio.
Quadro 1 Documentao da regra de negcio RN 01
Nome Descrio
Alterao de pedidos Pedidos j fechados no podero ser alterados.
RN- 02
27 Nome Descrio
Notificar venda
RN- 03
Em todas as vendas realizadas, o arteso responsvel pela mercadoria dever ser comunicado sobre a venda.
Newsletter
RN- 04
O usurio que deseja receber notcias sobre a associao de artesos dever concordar com os termos de uso, tais como:
Descrio - Os emails no devero ser respondidos;
- Qualquer novidade que a empresa julgar relevante ser enviado sem questionamento do usurio.
Nome Descrio
Envio para transportadora
RN- 05
A mercadoria s ser enviada para a transportadora aps a confirmao de pagamento.
Nome Descrio
Prazo para a confirmao de pagamento
RN- 06
O cliente tem o prazo mximo de cinco dias teis para confirmar o depsito, no havendo essa confirmao o pedido ser cancelado.
Nome Descrio
Encomenda
RN- 07
O valor e o prazo de entrega de encomendas sero definidos pelo arteso responsvel, que notificar o cliente por email ou outra forma de contato.
28 Nome Descrio
CPF S ser permitido o cadastro de cliente com CPF vlido.
RN- 08
Nome Descrio
Campos Obrigatrios
RN- 09
Todos os campos obrigatrios devem ser preenchidos para concluso de cadastro.
Nome Descrio
Reserva de produto
RN- 10
Ao realizar um pedido, a quantidade de itens requeridos deve ser existente no estoque. Os itens devem ser reservados para o pedido em questo.
Nome Descrio
Cancelamento de pedido Sero cancelados pedidos sem pagamentos efetuados.
RN- 11
29
Nome
Validao
RN- 12
Descrio
O usurio dever estar previamente autenticado no sistema para realizar as seguintes funes: fechar pedido, cancelar pedido, efetuar pagamento, realizar encomenda, manuteno da conta de cliente, manuteno de produtos, manuteno de categorias, manuteno de conta de arteso, gerar relatrios e manuteno de newsletter.
Nome Descrio
Gerenciamento de produtos
RN- 13
O arteso s poder gerenciar (incluir, editar, excluir) os seus prprios produtos.
30
3 ANLISE DE PROJETO DO SISTEMA
1.7 Introduo
A atividade que tem como finalidade realizar estudos de processos a fim de encontrar o melhor caminho racional para que a informao possa ser processada denomina-se Anlise de Sistemas. Os analistas de sistemas estudam os diversos sistemas existentes entre hardwares (equipamentos), softwares (programas) e o usurio final. Os seus comportamentos e aplicaes so desenvolvidos a partir de solues que sero padronizadas e transcritas da forma que o computador possa executar. Como uma nfase, o foco e o ncleo de trabalho esto voltados para Administrao da Produo de Software, levando em conta a rea tecnolgica em que ir auxiliar. O analista de sistemas deve servir como um tradutor entre as necessidades do usurio e o programa a ser desenvolvido pelo programador. A anlise requisito primrio para desenvolvimento de softwares nos dias atuais partindo do princpio de que a estrutura inicial para desenvolvimento dos mesmos. Com uma anlise bem estrutura pode-se obter um trabalho melhor organizado e com uma estrutura slida, o que permite que erros mais comuns e simples possam ser dados como inexistentes.
31 1.8 Ferramenta de modelagem
Como parte dos requisitos do sistema e da atividade de projetos, o sistema precisa ser modelado como um conjunto de componentes e de relaes entre esses componentes. Freqentemente a modelagem de software usa algum tipo de notao grfica e so apoiados pelo uso de ferramentas case. Modelagem de softwares normalmente implica na construo de modelos grficos que simbolizam os artefatos de software utilizados e seus inter-relacionamentos. Uma forma comum de modelagem de programas procedurais (no orientados a objeto) atravs de fluxogramas, enquanto que a modelagem de programas orientados a objeto normalmente usam a linguagem grfica UML(Linguagem de Modelagem Unificada) a qual os fabricantes lderes de modelagem esto dando suporte. Na criao de sistemas com qualidade necessrio a utilizao de uma boa metodologia para a modelagem tanto do software, como de seu banco de dados. Algumas ferramentas j auxiliam na automao da escrita de cdigo e na implementao da estrutura dos bancos de dados. O banco de dados modelado atravs do modelo de Entidade Relacionamento. O principal objetivo facilitar o projeto de banco de dados, possibilitando especificar a estrutura geral do banco de dados. Funcionam para modelos conceituais relacionais, objetos-relacionais ou orientado a objetos. As ferramentas de modelagem surgiram para facilitar a criao dos modelos, as mais avanadas permitem a gerao de uma parte do cdigo-fonte do software a partir do modelo e at a gerao do banco de dados a partir do modelo de entidade relacionamento. Pode-se citar uma ferramenta de modelagem que trabalha com padres de orientao a objetos: Enterprise Architect Enterprise Architect uma ferramenta grfica projetada para ajudar suas equipes construir sistemas robustos e de fcil manuteno. Com capacidades embutidas de gerenciamento de requisitos, ajuda a rastrear as especificaes de alto nvel para anlise, concepo, implementao, teste e manuteno de modelos usando UML, SysML, BPMN e outros padres abertos.
(Traduzido de: http:www. sparxsystems.com.au/products/ea/index.html )
32
1.9 Unified Modeling Language UML
Unified Modeling Language (UML) uma linguagem de modelagem padro de uso geral no domnio da engenharia de software. O padro gerido, e foi criado pelo Object Management Group. UML inclui um conjunto de tcnicas de notao grfica para criar modelos visuais de sistemas de software intensivos. Algumas pessoas menos informadas acreditam que UML uma metodologia, por causa do M na sigla. Mas, na verdade, no . A letra mais importante nessa sigla o L, de Linguagem. UML quer dizer Unified Modeling Language (Linguaguem de Modelagem Unificada) e , portanto, uma linguaguem que pode ser usada para descrever coisas. Porm, conhecer uma linguagem no implica habilidade de saber us-la para produzir artefatos teis. Por exemplo, a lngua portuguesa uma linguagem, mas uma pessoa que sabe escrever em portugus no sabe necessariamente fazer bons discursos ou boa poesia. Existe algo por trs da linguagem, denominado mtodo ou processo, que auxilia os grandes oradores e poetas a colocar os elementos da linguagem na ordem e na estrutura adequadas para produzir um efeito esperado. Quando se usa a linguagem UML no lugar do portugus, escrever discurso ou poesia corresponde a produzir projetos de sistemas co elegncia. Como diz Booch (1996), no h uma definio precisa sobreo queum projeto elegante, mas quem observa um projeto normalmente percebe se ele elegante ou no. Pode-se acrescentar ainda o seguinte: quem produz software elegante sabe que est fazendo isso, enquanto quem est fazendo software deselegante em geral nao tem conscincia disso. Os objetivos da UML so: A modelagem de sistemas (no apenas de software) usando os conceitos da orientao a objetos; Estabelecer uma unio fazendo com que mtodos conceituais sejam tambm executveis;
33
Criar uma linguagem de modelagem usvel tanto pelo homem quanto pela mquina. 3.1.1 Fases do Desenvolvimento de um Sistema em UML
Existem cinco fases no desenvolvimento de sistemas de software: Comunicao, Anlise, Projeto, Implementao e Implantao. Estas cinco fases no devem ser executadas na ordem descrita acima, mas concomitantemente de forma que problemas detectados numa certa fase modifiquem e melhorem as fases desenvolvidas anteriormente de forma que o resultado global gere um produto de alta qualidade e desempenho. Falaremos sobre cada fase do desenvolvimento de um sistema em UML. Comunicao
Esta fase captura as intenes e necessidades dos usurios do sistema a ser desenvolvido atravs do uso de funes chamadas caso de uso. Atravs do desenvolvimento, as entidades externas ao sistema (em UML chamados de "atores externos") que interagem e possuem interesse no sistema so modelados entre as funes que eles requerem. Os atores externos e os casos de uso so modelados com relacionamentos que possuem comunicao associativa entre eles ou so desmembrados em hierarquia. Cada caso de uso modelado descrito atravs de um texto, e este especifica os requerimentos do ator externo que utilizar. O diagrama mostrar o que os atores externos, ou seja, os usurios do futuro sistema devero esperar do aplicativo, conhecendo toda sua funcionalidade sem importar como esta ser implementada. A anlise de requisitos tambm pode ser desenvolvida baseada em processos de negcios, e no apenas para sistemas de software.
34
Anlise
A fase de anlise est preocupada com as primeiras abstraes (classes e objetos) e mecanismos que estaro presentes no domnio do problema. As classes so modeladas e ligadas atravs de relacionamentos com outras classes, e so descritas no Diagrama de Classe. As colaboraes entre classes tambm so mostradas neste diagrama para desenvolver os casos de uso modelados anteriormente, estas colaboraes so criadas atravs de modelos dinmicos em UML. Na anlise, s sero modeladas classes que pertenam ao domnio principal do problema do software, ou seja, classes tcnicas que gerenciem banco de dados, interface, comunicao, concorrncia e outros no estaro presentes neste diagrama.
Projeto
Na fase de design, o resultado da anlise expandido em solues tcnicas. Novas classes sero adicionadas para prover uma infra-estrutura tcnica: a interface do usurio e de perifricos, gerenciamento de banco de dados, comunicao com outros sistemas, dentre outros. As classes do domnio do problema modeladas na fase de anlise so mescladas nessa nova infra-estrutura tcnica tornando possvel alterar tanto o domnio do problema quanto infraestrutura. O design resulta no detalhamento das especificaes para a fase de programao do sistema.
Implementao
Na fase de programao, as classes provenientes do design so convertidas para o cdigo da linguagem orientada a objetos escolhida ( JAVA). Dependendo da capacidade da linguagem usada, essa converso pode ser uma tarefa fcil ou muito complicada. No momento da criao de modelos de anlise e design em UML, melhor evitar traduzi-los mentalmente em cdigo. Nas fases
35
anteriores, os modelos criados so o significado do entendimento e da estrutura do sistema, ento, no momento da gerao do cdigo onde o analista conclua antecipadamente sobre modificaes em seu contedo, seus modelos no estaro mais demonstrando o real perfil do sistema. A programao uma fase separada e distinta onde os modelos criados so convertidos em cdigo.
Implantao
Um sistema normalmente rodado em testes de unidade, integrao, e aceitao. Os testes de unidade so para classes individuais ou grupos de classes e so geralmente testados pelo programador. Os testes de integrao so aplicados j usando as classes e componentes integrados para se confirmar se as classes esto cooperando uma com as outras como especificado nos modelos. Os testes de aceitao observam o sistema como uma "caixa preta" e verificam se o sistema est funcionando como o especificado nos primeiros diagramas de casos de uso. O sistema ser testado pelo usurio final e verificar se os resultados mostrados esto realmente de acordo com as intenes do usurio final. (WAZLAVICK, 2004)
1.10 Casos de Uso
Casos de uso especificam o comportamento do sistema ou parte(s) dele e descrevem a funcionalidade do sistema desempenhada pelos atores. Voc pode imaginar um caso de uso como um conjunto de cenrios, onde cada cenrio uma seqncia de passos a qual descreve uma interao entre um usurio e o sistema. Os casos de uso so representados em forma de elipse.
36
3.1.2 Fluxos da documentao de Casos de Uso Conforme Bezerra (2002):
Fluxo principal descreve uma seqncia de aes que sero executadas considerando que nada de errado acontecer durante a execuo das aes. Descreve o que normalmente acontece quando o caso de uso realizado.
Fluxos Alternativos descrevem o que acontece quando o ator faz uma escolha alternativa, diferente da descrita no fluxo principal, para alcanar seu objetivo. Podem descrever escolhas exclusivas entre si.
Fluxos de Exceo correspondem descrio das situaes de exceo. Descrevem o que acontece quando algo inesperado ocorre na interao entre ator e caso de uso (ex.: ator realiza ao invlida)
1.11 Classes
Uma classe uma descrio de um conjunto de objetos que compartilham os mesmo atributos, operaes, relacionamentos e semntica. Podem ser implementadas em uma ou mais interfaces. Todos os objetos so instncias de classes, onde a classe descreve as propriedades e comportamentos daquele objeto. Em UML as classes so representadas por um retngulo dividido em trs compartimentos: - Nome: que conter apenas o nome da classe modelada; - Atributos: que possuir a relao de atributos que a classe possui em sua estrutura interna;
37
- Operaes: que sero os mtodos de manipulao de dados e de comunicao de uma classe com outras do sistema. A sintaxe usada em cada um destes compartimentos independente de qualquer linguagem de programao, embora possam ser usadas outras sintaxes como a do C++ e Java.
38
1.12 Diagrama de Casos de Uso
Casos de uso dizem respeito s principais atividades da empresa ligadas ao sistema a ser implementado, sendo assim, cada caso de uso est ligado a um conjunto de requisitos funcionais do sistema (WAZLAWICK, 2004).
Figura 1 - Diagrama de Casos de Uso
1.13 Descrio dos Casos de Uso e Atores
3.1.3 Descrio dos Casos de Uso
39
Nome Sumrio
Manter dados do cliente
CSU-01
Esse caso de uso descreve as etapas necessrias para a manuteno dos dados do cliente (incluso, alterao).
Ator primrio: Cliente. Ator (es) secundrio(s): No existe. Pr-condio: Possuir os dados necessrios para o cadastro ou estar autenticado no sistema. Ps-condio: Cliente cadastrado e\ou apto a utilizar o sistema. Fluxo Principal 1) 2) 3) 4) 5) 6) O usurio acessa a rea de cadastro. O sistema apresenta os campos necessrios para o cadastro com a opo para o recebimento de newsletter. O usurio insere os dados solicitados. O sistema consiste os dados. O sistema informa que o cadastro foi efetuado e envia um email com a confirmao de cadastro e os dados de acesso para o email do cliente. O sistema apresenta a tela da conta do usurio pronta para manuteno.
Fluxo Alternativo [5]: Alterar dados a) b) c) d) O usurio seleciona a opo de alterar dados. O sistema apresenta os dados para alterao. O usurio altera os dados e confirma. O sistema valida a alterao e retorna ao passo 5.
Fluxo de Exceo [4]: Validar dados a) b) O sistema valida se todos os campos obrigatrios foram preenchidos. B.1. Se preenchido, o sistema avana ao passo 4. B.2. Se no preenchido, o sistema apresenta informa que os dados necessrios no foram preenchidos e retorna ao passo 2.
Fluxo de Exceo [4]: CPF invlido a) b) O sistema verifica que o CPF invlido. O Sistema apresenta a mensagem de CPF incorreto e solicita a insero de um novo CPF vlido. c) O sistema retorna ao passo 2. Regras de Negcio Associadas RN-04, RN-08, RN-09, RN-12.
Quadro 14 Documentao de caso de uso Manter dados do cliente.
40
Nome Sumrio
Manter dados do arteso
CSU-02
Esse caso de uso descreve as etapas necessrias para a manuteno dos dados do arteso (incluso, alterao, excluso).
Ator primrio: Administrador, Arteso. Ator (es) secundrio(s): No existe. Pr-condio: Possuir os dados necessrios para o cadastro ou estar autenticado no sistema. Ps-condio: Arteso cadastrado ou\e apto a utilizar o sistema. Fluxo Principal 1) 2) 3) 4) 5) 6) 7) O administrador acessa a rea de manuteno de arteso. O sistema apresenta as opes de manuteno. O administrador seleciona a opo de cadastro. O sistema apresenta os campos necessrios para a incluso de arteso. O administrador insere os dados do arteso. O sistema informa que o cadastro foi efetuado e envia um email com a confirmao de cadastro e os dados de acesso para o email do arteso. O sistema apresenta a conta do arteso pronta para manuteno.
Fluxo Alternativo [7]: Alterao a) b) c) d) O arteso seleciona a opo de alterar dados. O sistema apresenta os dados para alterao. O arteso altera os dados e confirma. O sistema valida a alterao e retorna ao passo 7.
Fluxo Alternativo [3]: Excluso a) b) c) d) O administrador seleciona a opo de excluso. O sistema solicita o cadastro a ser excludo. O administrador informa o cadastro. O sistema confirma a excluso e retorna ao passo 2.
Fluxo de Exceo [5]: Validar dados a) b) O sistema valida se todos os campos obrigatrios foram preenchidos. B.1. Se preenchido, o sistema avana ao passo 6. B.2. Se no preenchido, o sistema apresenta informa que os dados necessrios no foram preenchidos e retorna ao passo 4. Regras de Negcio Associadas
RN-09, RN-12.
Quadro 15 Documentao de caso de uso Manter dados do arteso.
41
Nome Sumrio
Manter dados do produto
CSU-03
Esse caso de uso descreve as etapas necessrias para a manuteno dos dados dos produtos (incluso, alterao, excluso).
Ator primrio: Arteso, Administrador. Ator (es) secundrio(s): No existe. Pr-condio: Possuir os dados necessrios para o cadastro e estar autenticado no sistema. Ps-condio: Produto cadastrado, alterado ou excludo com sucesso. Fluxo Principal 1) 2) 3) 4) 5) 6) O usurio acessa a rea de manuteno de produtos. O usurio seleciona a opo de incluso de produto. O sistema apresenta os campos para incluso de um novo produto. O usurio insere os dados do produto. O sistema informa que a ao foi efetuada e atualiza o estoque. O sistema apresenta a tela do produto para alterao.
Fluxo Alternativo [2]: Alterar a) b) c) d) e) O usurio seleciona a opo de alterar produto. O sistema solicita o produto a ser alterado. O usurio informa o produto a alterar. O arteso insere os dados a serem alterados. O usurio avana ao passo 5.
Fluxo Alternativo [2]: Excluir a) b) c) d) O usurio seleciona a opo de excluir produto. O sistema solicita o produto a ser excludo. O usurio informa o produto a excluir. O sistema avana ao passo 5.
Fluxo de Exceo [4]: Validar dados a) b) O sistema valida se todos os campos obrigatrios foram preenchidos. B.1. Se preenchido, o sistema avana ao passo 5. B.2. Se no preenchido, o sistema apresenta informa que os dados necessrios no foram preenchidos e retorna ao passo 3. Regras de Negcio Associadas RN-09, RN-12, RN-13.
Quadro 16 Documentao de caso de uso Manter dados do produto.
42
Nome Sumrio
Manter dados de categoria
CSU-04
Esse caso de uso descreve as etapas necessrias para a manuteno dos dados das categorias (incluso, alterao, excluso).
Ator primrio: Arteso, Administrador. Ator (es) secundrio(s): No existe. Pr-condio: Possuir os dados necessrios para o cadastro e estar autenticado no sistema. Ps-condio: Categoria cadastrada, alterada ou excluda com sucesso. Fluxo Principal 1) 2) 3) 4) 5) 6) O usurio acessa a rea de manuteno de categorias. O usurio seleciona a opo de incluso de categoria. O sistema apresenta os campos para incluso de uma nova categoria. O usurio insere os dados da categoria. O sistema informa que a ao foi efetuada. O sistema apresenta a tela de categoria para alterao.
Fluxo Alternativo [2]: Alterar a) b) c) d) e) O usurio seleciona a opo de alterar categoria. O sistema solicita a categoria a ser alterada. O usurio informa a categoria a alterar. O usurio insere os dados a serem alterados. O sistema avana ao passo 6.
Fluxo Alternativo [2]: Excluir a) b) c) d) O usurio seleciona a opo de excluir categoria. O sistema solicita a categoria a ser excluda. O usurio informa a categoria a excluir. O sistema avana ao passo 6.
Fluxo de Exceo [4]: Validar dados a) b) O sistema valida se todos os campos obrigatrios foram preenchidos. B.1. Se preenchido, o sistema avana ao passo 5. B.2. Se no preenchido, o sistema apresenta informa que os dados necessrios no foram preenchidos e retorna ao passo 3. Regras de Negcio Associadas RN-09, RN-12.
Quadro 17 Documentao de caso de uso Manter dados de categoria.
43
Nome Sumrio
Manter newsletter
CSU-05
Esse caso de uso descreve as etapas necessrias para a manuteno de newsletter (incluso, alterao, excluso).
Ator primrio: Arteso, Administrador. Ator (es) secundrio(s): No existe. Pr-condio: Possuir as informaes para cadastrar a newsletter. Ps-condio: Newsletter cadastrado e pronto para ser publicado. Fluxo Principal 1) 2) 3) 4) 5) 6) O usurio acessa a rea de newsletter. O usurio seleciona a opo de cadastro de newsletter. O sistema apresenta os campos para o cadastro de newsletter. O usurio insere os dados do newsletter. O sistema informa que a ao foi efetuada. O sistema apresenta a rea de newsletter.
Fluxo Alternativo [2]: Alterar a) b) c) d) e) O usurio seleciona a opo de alterar newsletter. O sistema solicita o newsletter a ser alterada. O usurio informa o newsletter a alterar. O usurio insere os dados a serem alterados. O sistema avana ao passo 5.
Fluxo Alternativo [2]: Publicar a) b) c) d) O usurio seleciona a opo de publicar newsletter. O sistema solicita o newsletter a publicar. O usurio informa o newsletter. O sistema avana ao passo 5.
Fluxo de Exceo [4]: Validar dados a) b) O sistema valida se todos os campos obrigatrios foram preenchidos. B.1. Se preenchido, o sistema avana ao passo 5. B.2. Se no preenchido, o sistema informa que os dados necessrios no foram preenchidos e retorna ao passo 3. Regras de Negcio Associadas RN-12.
Quadro 18 Documentao de caso de uso Manter newsletter.
44
Nome Sumrio
Gerar relatrios
CSU-06
Esse caso de uso descreve as etapas necessrias para a gerao de relatrios.
Ator primrio: Arteso, Administrador. Ator (es) secundrio(s): No existe. Pr-condio: Estar autenticado no sistema. Ps-condio: Relatrio exibido para o usurio. Fluxo Principal 1) 2) 3) 4) 5) 6) O usurio acessa a rea de relatrio. O usurio seleciona a opo de gerar relatrio. O sistema apresenta os campos de parmetro para o relatrio. O usurio insere os parmetros. O sistema informa que a ao foi efetuada. O sistema exibe o relatrio.
Fluxo Alternativo [4]: Parmetros incorretos a) b) c) O sistema no consegue gerar um relatrio com os parmetros informados. O sistema informa que os parmetros esto incorretos. O sistema retorna ao passo 3.
Fluxo de Exceo []: No existe. Regras de Negcio Associadas RN-12.
Quadro 19 Documentao de caso de uso Gerar relatrio.
45
Nome Sumrio
Gerar consultas
CSU-07
Esse caso de uso descreve as etapas necessrias para a realizao de consultas.
Ator primrio: Cliente, Arteso, Administrador. Ator (es) secundrio(s): No existe. Pr-condio: No existe. Ps-condio: O sistema exibe os resultados da consulta na tela. Fluxo Principal 1) 2) 3) 4) 5) O usurio acessa a opo de consulta no sistema. O sistema informa os parmetros da consulta (produtos, categorias, clientes, entre outros) variando pela permisso do usurio. O usurio seleciona os parmetros apresentados e/ou insere parmetros adicionais (nomes, datas, entre outros). O sistema efetua a consulta usando os parmetros informados. O sistema apresenta os resultados encontrados.
Fluxo Alternativo []: No existe. Fluxo de Exceo []: No existe. Regras de Negcio Associadas No existe.
Quadro 20 Documentao de caso de uso Gerar consultas.
46
Nome Sumrio
Realizar encomendas
CSU-08
Esse caso de uso descreve as etapas necessrias para solicitar a encomenda de um especfico.
Ator primrio: Cliente. Ator (es) secundrio(s): No existe. Pr-condio: Estar autenticado no sistema. Ps-condio: A encomenda enviada para o arteso. Fluxo Principal 1) 2) 3) 4) 5) 6) 7) 8) O usurio acessa a opo de realizar encomenda. O sistema apresenta o campo de detalhes da encomenda. O usurio insere os detalhes desejados e confirma. O sistema apresenta os artesos que podero produzir a encomenda. O usurio seleciona o arteso. O sistema exibe uma mensagem de que o pedido de encomenda foi enviado. O sistema envia ao arteso selecionado os detalhes da encomenda. O sistema retorna a pgina inicial.
Fluxo Alternativo []: No existe. Fluxo de Exceo []: No existe. Regras de Negcio Associadas RN-12, RN-07.
Quadro 21 Documentao de caso de uso Realizar encomendas.
47
Nome Sumrio
Comprar
CSU-09
Esse caso de uso descreve as etapas necessrias para gerar um carrinho de compras.
Ator primrio: Cliente Ator (es) secundrio(s): No existe. Pr-condio: No existe. Ps-condio: O sistema gera um carrinho de compras com os produtos escolhidos pelo cliente. Fluxo Principal 1) 2) 3) 4) 5) O cliente procura no sistema, atravs de consultas e menus de acesso, o produto desejado. O cliente seleciona o produto desejado e acessa as especificaes do mesmo. O sistema apresenta a opo de incluir o produto no carrinho de compra. O cliente inclui o produto no carrinho de compras. O sistema apresenta o carrinho de compra com os produtos adicionados e o valor total. Fluxo Alternativo [5]: Incluir a) b) O cliente solicita a opo de continuar comprando. O sistema retorna ao passo 1.
Fluxo Alternativo [5]: Alterar a) b) c) O usurio executa a alterao da quantidade de itens de determinado produto. O sistema faz as alteraes. O sistema retorna ao passo 5.
Fluxo Alternativo [5]: excluir a) b) O usurio solicita a excluso de um produto do carrinho. O sistema exibe a opo e uma mensagem de alerta para confirmao da excluso. c) O usurio confirma a excluso e o caso de uso encerrado. Regras de Negcio Associadas No existe.
Quadro 22 Documentao de caso de uso Gerar carrinho de compras.
48
Nome Sumrio
Efetuar pedido
CSU-10
Esse caso de uso descreve as etapas necessrias para efetuar um pedido.
Ator primrio: Cliente. Ator (es) secundrio(s): No existe. Pr-condio: Produto no estoque Ps-condio: Pedido realizado com sucesso, arteso notificado sobre o pedido e estoque atualizado. Fluxo Principal 1) 2) 3) 4) 5) 6) 7) O cliente seleciona a opo de fechar o pedido. O sistema solicita o CEP para o clculo de frete. O cliente insere o CEP e confirma. O sistema calcula o valor do frete e apresenta o valor total do pedido. O sistema solicita a confirmao do pedido. O cliente confirma o pedido. O sistema notifica os artesos correspondentes aos produtos que foram selecionados pelo cliente por email e atualiza o estoque. Fluxo Alternativo [6]: Cancelar compra a) b) O cliente escolhe a opo de desistir da compra. O sistema encerra o caso de uso.
Fluxo de Exceo [1]: Estoque insuficiente a) O sistema verifica a quantidade disponvel de itens no estoque dos produtos selecionados. b) B.1. Se a quantidade estiver disponvel, o sistema avana ao passo 2. B.2. Se a quantidade no estiver disponvel, o sistema informa que no h itens disponveis no estoque e encerra o caso de uso sem fechar o pedido. Regras de Negcio Associadas RN-02, RN-10.
Quadro 23 Documentao de caso de uso Efetuar pedido.
49
Nome Sumrio
Atualizar estoque
CSU-11
Esse caso de uso descreve as etapas necessrias para a atualizao de estoque.
Ator primrio: CSU-03 (Manter dados produto), CSU-10 (Efetuar pedido), CSU-13 (Cancelar pedido). Ator (es) secundrio(s): Arteso, Cliente. Pr-condio: Existir algum valor necessrio para alterar. Ps-condio: Estoque atualizado. Fluxo Principal 1) 2) 3) 4) 5) O sistema recebe uma solicitao de uma operao para atualizar estoque. O sistema solicita os dados para a atualizao. A operao informa os dados necessrios para atualizar. O sistema valida os dados fornecidos pela operao. O sistema atualiza o estoque.
Fluxo Alternativo [4]: Estoque insuficiente a) Em caso de excluso o sistema verifica que a quantidade retirada maior que a disponvel. b) O sistema exibe uma mensagem de erro informando que o estoque insuficiente. c) O sistema encerra o caso de uso e no atualiza o estoque. Fluxo de Exceo []: No existe. Regras de Negcio Associadas No existe.
Quadro 24 Documentao de caso de uso Atualizar estoque.
50
Nome Sumrio
Notificar venda
CSU-12
Esse caso de uso descreve as etapas necessrias para a notificao de uma venda.
Ator primrio: CSU-10 (Efetuar pedido), CSU-13 (Cancelar pedido). Ator (es) secundrio(s): Cliente. Pr-condio: Haver uma compra ou cancelamento existente. Ps-condio: Arteso notificado. Fluxo Principal 1) 2) 3) 4) A operao solicita o sistema o envio de notificao ao arteso. O sistema identifica o(s) arteso(s) correspondente(s) ao produto do pedido. O sistema envia um e-mail de pedido efetuado/cancelado ao(s) arteso(s) em questo. O sistema encerra o caso de uso.
Fluxo Alternativo []: No existe. Fluxo de Exceo []: No existe. Regras de Negcio Associadas No existe.
Quadro 25 Documentao de caso de uso Notificar venda.
51
Nome Sumrio
Cancelar pedido
CSU-13
Esse caso de uso descreve as etapas necessrias para o cancelamento de um pedido.
Ator primrio: Cliente. Ator (es) secundrio(s): No existe. Pr-condio: Estar autenticado no sistema e existir algum pedido fechado. Ps-condio: Pedido cancelado com sucesso. Fluxo Principal 1) 2) 3) 4) O cliente acessa a rea de pedidos do sistema. O sistema exibe os pedidos fechados do cliente. O cliente solicita o cancelamento do pedido. O sistema cancela o pedido, notifica o(s) arteso(s) e atualiza o estoque.
Fluxo Alternativo []: No existe. Fluxo de Exceo []: No existe. Regras de Negcio Associadas RN-11, RN-12.
Quadro 26 Documentao de caso de uso Cancelar pedido.
52
Nome Sumrio
Efetuar pagamento
Esse caso de uso descreve as etapas necessrias para efetuar pagamento.
CSU-14
Ator primrio: Cliente. Ator (es) secundrio(s): No existe. Pr-condio: Existir algum pedido fechado. Ps-condio: Pagamento efetuado com sucesso. Fluxo Principal 1) 2) 3) 4) 5) 6) 7) O cliente solicita a opo de efetuar pagamento. O sistema solicita o pedido a ser pago. O usurio informa o pedido. O sistema solicita o comprovante de depsito bancrio. O usurio anexa o documento do comprovante e confirma. O sistema envia o comprovante por email aos artesos que possuem produto no pedido. O sistema informa ao usurio que o comprovante foi enviado.
Fluxo de Exceo [4]: Validar dados a) b) O sistema valida se o comprovante foi anexado. B.1. Se o anexo estiver inserido, o sistema avana ao passo 6. B.2. Se o anexo no estiver inserido, o sistema informa que o anexo obrigatrio e retorna ao passo 3. Regras de Negcio Associadas RN-01, RN-06.
Quadro 27 Documentao de caso de uso Efetuar pagamento.
53
1.13.1 Descrio dos Atores
Representa qualquer entidade que interage com o sistema.
Administrador
Este ator possui acesso total ao sistema, sendo o nico a ter permisso para listar, cadastrar e modificar todos os clientes, artesos, produtos e categorias. Generalizando, tem total acesso as funcionalidades do sistema, podendo atuar em qualquer rea do mesmo.
Arteso
Este ator possui permisso de cadastrar, listar e modificar produtos no sistema e acompanhar o pedido de seus produtos, to quanto fazer alteraes em seu perfil de arteso e divulgar newsletter e assuntos afins para clientes.
Cliente
Este ator possui permisso de se cadastrar alm de gerenciar seu perfil. Basicamente o nico responsvel pela gerao um carrinho de compras para armazenar a quantidade que necessita de produtos para seu pedido e finalizar uma compra.
54
1.14 Classes de anlise
1.14.1 Diagrama de Classes de Negcio
O diagrama de classes considerado por vrios autores como o mais importante e utilizado diagrama da UML. Ele apresenta uma viso esttica da organizao das classes do sistema, permitindo alm da visualizao das classes e de seus atributos e mtodos, a representao de seus relacionamentos, como estas se complementam e a transmisso da informao dentro do sistema (SILVA, 2007).
Figura 2 - Diagrama de classes de negcio.
55
1.14.2 Classes de Fronteira
So classes de objetos que permitem a comunicao entre o mundo externo e o sistema. (GUEDES, 2005).
Figura 3 Fronteira de Cliente GUI-Cliente esta classe, que pertence ao dos clientes (incluso, alterao e excluso). Java Server Pages (jsp), tem a
responsabilidade de apresentar as funcionalidade relativas a manuteno de dados
Figura 4 Fronteira de Arteso GUI-Arteso esta classe, que pertence ao Java Server Pages (jsp), tem a responsabilidade de apresentar as funcionalidade relativas a manuteno de dados dos artesos(incluso, alterao e excluso).
Figura 5 Fronteira de Produto GUI-Produto esta classe, que pertence ao Java Server Pages (jsp), tem a responsabilidade de apresentar as funcionalidade relativas a manuteno de dados dos produtos(incluso, alterao e excluso).
56
Figura 6 Fronteira de Categoria GUI-Categoria esta classe, que pertence ao Java Server Pages (jsp), tem a responsabilidade de apresentar as funcionalidade relativas a manuteno de dados das categorias(incluso, alterao e excluso).
Figura 7 Fronteira de Carrinho GUI-Carrinho esta classe, que pertence ao Java Server Pages (jsp), tem a responsabilidade de apresentar as funcionalidade relativas a manuteno de produtos no carrinho (incluso, alterao e excluso de itens).
1.14.3 Classe Controladora
So classes que modelam a seqncia de controle especfica de um caso de uso do sistema, ou seja, controlam a execuo dos eventos necessrios para um caso de uso. (GUEDES, 2005).
Figura 8 Classe Controladora de Cliente ClienteAction e ClienteBO - A classe de controle ClienteAction uma classe que estende a classe ActionSupport, nela esto centralizadas todas as aes pertinentes ao cliente, estas aes so mapeadas no arquivo struts.xml para serem
57
usadas nas pginas JSP. Na classe ClienteBO ficam isoladas as regras de negcio, o que permite um melhor desacoplamento entre as camadas.
Figura 9 Classe Controladora de Arteso ArtesaoAction e ArtesaoBO - A classe de controle ArtesaoAction uma classe que extend a classe ActionSupport, nela esto centralizadas todas as aes pertinentes ao arteso, estas aes so mapeadas no arquivo struts.xml para serem usadas nas pginas JSP. Na classe ArtesaoBO ficam isoladas as regras de negcio, o que permite um melhor desacoplamento entre as camadas.
Figura 10 Classe Controladora de Produto ProdutoAction e ProdutoBO - A classe de controle ProdutoAction uma classe que extend a classe ActionSupport, nela esto centralizadas todas as aes pertinentes ao produto, estas aes so mapeadas no arquivo struts.xml para serem usadas nas pginas JSP. Na classe ProdutoBO ficam isoladas as regras de negcio, o que permite um melhor desacoplamento entre as camadas.
58
Figura 11 Classe Controladora de Carrinho
CategoriaAction e CategoriaBO - A classe de controle CategoriaAction uma classe que estende a classe ActionSupport, nela esto centralizadas todas as aes pertinentes a categoria, estas aes so mapeadas no arquivo struts.xml para serem usadas nas pginas JSP. Na classe CategoriaBO ficam isoladas as regras de negcio, o que permite um melhor desacoplamento entre as camadas.
1.14.4 Classe de Entidade
So classes de objetos que refletem entidades do mundo real, ou seja, pertence ao domnio do problema. (GUEDES, 2005).
Figura 12 Entidade de Cliente Cliente e ClienteDAO Cliente faz o papel do mapeamento objeto relacional dos dados relativos a clientes, funcionando como uma classe POJO. Tem-se a classe ClienteDAO, que persiste a classe Cliente.
59
Figura 13 Entidade de Arteso Artesao e ArtesaoDAO Arteso faz o papel do mapeamento objeto relacional dos dados relativos a artesos, funcionando como uma classe POJO. Temos a classe ArtesaoDAO, que persiste a classe Artesao.
Figura 14 Entidade de Categoria Categoria e CategoriaDAO Categoria faz o papel do mapeamento objeto relacional dos dados relativos a categorias, funcionando como uma classe POJO.Temos a classe CategoriaDAO, que persiste a classe Categoria.
Figura 15 Entidade de Produto Produto e ProdutoDAO Produto faz o papel do mapeamento objeto relacional dos dados relativos a produtos, funcionando como uma classe POJO.Temos a classe ProdutoDAO, que persiste a classe Produto.
60
1.15 Diagrama de Seqncia
O diagrama de seqncia uma ferramenta que deve ser utilizada sempre em funo dos casos de uso. Ele captura o comportamento de um nico caso de uso, ou seja, mostra a interao entre os objetos ao longo do tempo, apresentando os objetos que participam da interao e a seqncia das mensagens trocadas. (WAZLAWICK, 2004).
Figura 16 Diagrama de sequncia Manter arteso
61
A figura 17 mostra o diagrama de seqncia de anlise do caso de uso Manter Categoria, descrito neste diagrama as funes que o ator (Arteso) deve exercer para Manter dados da Categoria.
Figura 17 Diagrama de sequncia Manter categoria
62
A figura 18 mostra o diagrama de seqncia de anlise do caso de uso Manter Cliente, descrito neste diagrama as funes que o ator (Cliente) deve exercer para seus dados.
Figura 18 Diagrama de sequncia Manter cliente
63
A figura 19 mostra o diagrama de seqncia de anlise do caso de uso Manter Newsletter, descrito neste diagrama as funes que o ator (Arteso) deve exercer para Manter Newsletter.
Figura 19 Diagrama de sequncia Manter newsletter
64
A figura 20 mostra o diagrama de seqncia de anlise do caso de uso Manter Produto, descrito neste diagrama as funes que o ator (Arteso) deve exercer para Manter Produto.
Figura 20 Diagrama de sequncia Manter produto
65
A figura 21 mostra o diagrama de seqncia de anlise do caso de uso Gerar Consultas, descrito neste diagrama as funes que o ator (Usurio) deve exercer para Gerar consultas.
Figura 21 Diagrama de sequncia Gerar consultas A figura 22 mostra o diagrama de seqncia de anlise do caso de uso Gerar Relatrios, descrito neste diagrama as funes que o ator (Usurio) deve exercer para Gerar relatrio.
Figura 22 Diagrama de sequncia Gerar relatrios
66
A figura 23 mostra o diagrama de seqncia de anlise do caso de uso Realizar Encomenda, descrito neste diagrama as funes que o ator (Cliente) deve exercer para Realizar encomenda.
Figura 23 Diagrama de sequncia Realizar encomenda
67
A figura 24 mostra o diagrama de seqncia de anlise do caso de uso Compras, descrito neste diagrama as funes que o ator (Cliente) deve exercer para comprar.
Figura 24 Diagrama de sequncia Comprar
68
A figura 25 mostra o diagrama de seqncia de anlise do caso de uso Cancelar Pedido, descrito neste diagrama as funes que o ator (Cliente) deve exercer para cancelar o pedido.
Figura 25 Diagrama de sequncia Cancelar pedido
69
A figura 26 mostra o diagrama de seqncia de anlise do caso de uso Efetuar Pedido, descrito neste diagrama as funes que o ator (Cliente) deve exercer para efetuar um pedido.
Figura 26
Diagrama de sequncia Efetuar pedido
70
A figura 27 mostra o diagrama de seqncia de anlise do caso de uso Efetuar Pagamento, descrito neste diagrama as funes que o ator (Cliente) deve exercer para efetuar pagamento.
Figura 27
Diagrama de sequncia Efetuar pagamento
71
4 PERSISTNCIA DE DADOS
1.16 Introduo
persistncia
de
dados,
na
computao,
refere-se
ao
armazenamento no-voltil de dados, por exemplo, em um dispositivo fsico de armazenamento como um disco rgido. Quando se grava um arquivo no disco, por exemplo, o dado est sendo "eternizado", ou seja, deixa de ficar voltil na memria RAM e passa a ser escrito em um dispositivo que armazena a informao de modo que ela no desaparea facilmente, simplificando a persistncia de dados armazenar dados em um banco de dados relacional. O termo persistncia associado a uma ao de manter em meio fsico recupervel, sendo esse um banco de dados, arquivo, garantindo a permanncia das informaes de um determinado estado de um objeto lgico.
Figura 28 Funcionamento da persistncia de dados A figura 28 mostra a funcionalidade da persistncia de dados para um sistema genrico. O usurio cria/altera dados dentro do sistema, gerando-os em
72
dados volteis (em memria, so perdidos aps concluso da execuo), a camada de persistncia encapsula esses dados e os eterniza em dados no volteis (podendo ser salvos em banco de dados ou arquivo). Aps os dados serem eternizados, a camada de persistncia pode recuperar esses dados em qualquer momento que for solicitado para que o usurio consiga manipular seus prprios dados novamente, assim reiniciando o fluxo de persistncia. Em Orientao a Objetos, o termo objetos persistentes significa que os dados gerados durante a execuo do programa continuam a existir em uma unidade fsica no-voltil mesmo aps a finalizao de sua execuo. Associados persistncia esto o gerenciamento dinmico da memria e o armazenamento de objetos em bases de dados. Somente possvel "eternizar" um objeto quando este no possui "dados dinmicos" ( runtime), ou seja, dados que s fazem sentido no contexto do tempo em que esto executando, como sockets, por exemplo. Se congelados os objetos que possuem dados de tempo de execuo, depois de recuperados os mesmos no faro mais sentido no contexto do novo tempo, assim sendo ignorados ou perdidos.
Padro de Projeto DAO
Um dos padres de projetos mais conhecidos e mais utilizados ainda hoje o DAO (Data Access Object). Padro este que teve um papel fundamental h muitos anos, e que ainda hoje em determinados projetos de software desempenha muito bem seu trabalho. O Data Access Object, conhecido como DAO, um dos padres de mapeamento de objeto relacional para persistncia de objetos em um base de dados. A funo do DAO abstrair e encapsular o acesso aos dados e criar uma conexo com a fonte de dados, gerenciando automaticamente o acesso e armazenamento dos dados. O DAO responsvel por fornecer uma API (Interface de Programao de Aplicativos) uniforme para que independente do tipo da fonte de dados haja uma comunicao entre o programa e essas fontes. O DAO implementado como um objeto sem informaes de estado,
73
onde no armazena em cache os resultados de execuo de consulta que o cliente possa precisar posteriormente, com isso o DAO um objeto leve que evita problemas de threading e simultaneidade. A responsabilidade do Data Access Object de encapsular a utilizao do JDBC e s expor informaes como excesses, estrutura de dados ou objeto para dentro da camada de acesso a dados. Usando-se esse padro a camada de negcios acessa os dados persistidos sem ter conhecimento se os dados esto em um banco de dados relacional ou um arquivo XML (eXtensible Markup Language). O padro DAO esconde os detalhes da execuo da origem dos dados (SUN, 2010).
Figura 29 Modelo Arquitetural do Padro de Projetos DAO

(Fonte: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html, 2010)
O modelo arquitetural da figura 29 representa o Objeto de Negcio (utilizado na camada de negcio) que obtm/modifica dados volteis. A utilizao do DAO feita para a criao/utilizao dos dados, com a finalidade de ao trmino dessa alterao os mesmos sejam encapsulados e enviados para serem eternizados na Fonte de Dados. Utilizou-se o DAO para abstrair e encapsular todo o acesso fonte de dados. O DAO gerencia a conexo com a fonte de dados para obter e armazenar dados (SUN, 2010).
74
Figura 30 - Diagrama de Sequncia Utilizao do DAO em classes persistentes

(Adaptado 2010) de: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html,
O diagrama de sequncia da figura 30 representa a comunicao da camada de negcios e o banco de dados. A finalidade do DAO prover uma interface com operaes para acesso a dados que abstraiam os detalhes do mecanismo de persistncia. A camada de negcios ao criar/alterar os dados manipulados pela interface, comunica-se com o DAO para que o mesmo verifique se os dados solicitados j so existentes no banco de dados, assim independentes de existirem so enviados para a memria para que todas as alteraes que a camada de negcio solicitar sejam feitas. Aps a confirmao de todas as alteraes a camada
75
de negcios envia para o DAO a solicitao para que recupere os dados da memria e salve novamente em dados no-volteis (banco de dados). Em uma aplicao utilizando a arquitetura MVC ( Model View Controller), todas as conexes relacionadas a fontes de dados, so executadas dentro das classes de DAO que por sua vez no expe detalhes sobre a forma de acesso aos dados pela camada de negcio, porm permite a visualizao desses dados. O quadro 28 expe um exemplo de DAO utilizado no projeto para cadastro de artesos no banco de dados:
//ArtesaoDAO.class package br.uniminas.persistencia; import java.util.List; import br.uniminas.entidades.Artesao; public interface ArtesaoDao { public List<Artesao> getAllArtesaos(); public Artesao getArtesao(Integer id); public void update(Artesao art); public void insert(Artesao art); public void delete(Integer id); }
Quadro 28 Classe ArtesaoDAO Interface com o SGBD A criao da classe ArtesaoDAO tem como finalidade expor os mtodos de acesso ao SGBD para a interface.
//ArtesaoHibernateDAO.class package br.uniminas.persistencia; import java.util.List; import org.hibernate.Query; import org.hibernate.Session; import org.hibernate.Transaction; import br.uniminas.entidades.*; public class ArtesaoHibernateDao implements ArtesaoDao { private List<Artesao> artList; private Artesao art; private Session session = HibernateUtil.getSessionFactory() .getCurrentSession(); @SuppressWarnings("unchecked") public List<Artesao> getAllArtesaos() { session = HibernateUtil.getSessionFactory().openSession(); try { session.beginTransaction();
76 artList = session.createQuery("from Artesao").list(); return artList; } finally { session.close(); } } public Artesao getArtesao(Integer id) { session = HibernateUtil.getSessionFactory().openSession(); try { session.beginTransaction(); Query q = session.createQuery("from Artesao as e where e.id =:id"); q.setInteger("id", id); return (Artesao) q.uniqueResult(); } finally { session.close(); } } public void insert(Artesao art) { session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = null; try { tx = session.beginTransaction(); session.save(art); tx.commit(); } catch (RuntimeException e) { if (tx != null) tx.rollback(); throw e; } finally { session.close(); } } public void update(Artesao art) { session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = null; try { tx = session.beginTransaction(); session.update(art); tx.commit(); } catch (RuntimeException e) { if (tx != null) tx.rollback(); throw e; } finally { session.close(); } } public void delete(Integer id) { session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = null; try { tx = session.beginTransaction(); art = (Artesao) session.get(Artesao.class, id); session.delete(art); tx.commit();
77 } catch (RuntimeException e) { if (tx != null) tx.rollback(); throw e; } finally { session.close(); } }
Quadro 29 Classe ArtesaoHibernateDAO Manipulao de dados no SGBD O quadro 29 representa a classe ArtesaoHibernateDAO, responsvel por fazer a alterao de estado dos dados. As alteraes de estado so gerenciadas por transaes criadas automaticamente para reduo do trabalho do desenvolvedor para comunicar-se com o SGBD.
Diagrama de Entidade e Relacionamento (DER)
A figura 31 ilustra o Diagrama Entidade Relacionamento (DER). 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.
Figura 31 - Diagrama de Entidade e Relacionamento
78
Na persistncia de dados cada entidade do sistema exposta em uma classe de aplicao. A classe de aplicao utilizada como interface entre a camada de negcio e a camada de persistncia.
MySQL
O MySQL um SGBD (Sistema de Gerenciamento de Banco
de
Dados), que utiliza a linguagem SQL (Structured Query Language) como interface. A linguagem SQL um grande padro de banco de dados. Isto decorre da sua simplicidade e facilidade de uso. Ela se diferencia de outras linguagens de consulta a banco de dados no sentido em que uma consulta SQL especifica a forma do resultado e no o caminho para chegar a ele. Ela uma linguagem declarativa em oposio a outras linguagens procedurais. Isto reduz o ciclo de aprendizado daqueles que se iniciam na linguagem ( Navathe, S. B., 2002). A interface Connector/ODBC (Open-DataBase-Connectivity) fornece ao MySQL suporte a progras clientes que usam conexo ODBC. Os clientes podem ser executados no Windows ou Unix. O fonte do Connector/ODBC est disponvel. Todas as funes ODBC so suportadas, assim como muitas outras (MySQL). Um sistema gerenciador de banco de dados o software que permite criar, manter e manipular bancos de dados para diversas aplicaes. A criao e manuteno de bancos de dados so tarefas de uma pessoa ou grupo de pessoas, normalmente referenciada como o administrador do banco de dados (DBA). A manipulao do banco de dados, como atualizaes e consultas, realizada direta ou indiretamente, atravs de programas aplicativos, pelos usurios do banco de dados. A utilizao do MySQL como banco de dados para o projeto foi com base nas seguintes caractersticas:
Existncia de drivers ODBC, JDBC e .NET e mdulos de interface para
79
diversas linguagens de programao. Portabilidade Suporte de vrias plataformas diferentes. Desempenho e estabilidade. Interfaces grficas de fcil utilizao cedidos pela MySQL Inc. Utilizao de pouco recurso de hardware para seu funcionamento. Facilidade de construo do banco de dados. um Software Livre com base na GPL (Licena Pblica Geral).
Framework Hibernate
O mapeamento objeto relacional para o sistema de Loja Virtual de Produtos Artesanais foi feito utilizando um Framework da camada de integrao: Hibernate. um framework para o mapeamento objeto-relacional escrito na linguagem Java, tambm disponvel em linguagem .Net como o nome NHibernate. Este framework facilita ao desenvolvedor o mapeamento dos atributos entre uma base de dados relacionais e o modelo objeto de uma aplicao, mediante o uso de arquivos (XML) para estabelecer esta relao. O Hibernate um software livre de cdigo aberto distribudo com a licena LGPL (Lesser General Public License). Uma tcnica bastante conhecida da orientao a objetos o encapsulamento, onde possvel esconder as regras dentro de objetos e definir alguns mtodos nesses objetos que o mundo externo poder usar para ter acesso ao resultado dos cdigos. Essa idia foi adaptada programao com banco de dados. Os mtodos necessrios ao acesso e manipulao do banco ficam escondidos dentro de classes bsicas. As outras partes da aplicao usam essas classes e seus objetos, ou seja, a aplicao nunca ter acesso diretamente ao banco de dados (LEMES, 2007). O Hibernate possibilita o mapeamento das tabelas do banco de dados com classes Java, e vice-versa, possibilitando tambm pesquisa e retorno dos
80
dados, reduzindo o esforo de desenvolvimento para controlar o relacionamento objeto-relacional. No sistema de Loja Virtual de Produtos Artesanais foi utilizado o Hibernate Annotations, onde permite utilizar anotaes em classes POJO (Plain Old Java Object). POJOS so objetos Java que seguem a estrutura de JavaBeans (construtor padro sem argumentos e mtodos getters e setters para seus atributos). Com a utilizao da ferramenta IDE Eclipse, foi capaz de mapear e gerar as classes trabalhadas no sistema por meio de engenharia reversa.
Figura 32 - Bibliotecas utilizadas pelo Hibernate
81
A figura 32 representa as bibliotecas utilizadas em um projeto Hibernate. Hibernate Configuration File: arquivo utilizado para mapear as configuraes de acesso ao SGBD tais como: localizao do banco, usurio, senha e tabelas envolvidas. 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"> <hibernate-configuration> <session-factory> <property name="connection.driver_class">com.mysql.jdbc.Driver</property> <property name="connection.url">jdbc:mysql://localhost:3306/db_sizarts</property> <property name="connection.username">root</property> <property name="connection.password"></property>  <property name="connection.pool_size">1</property>  <property name="dialect">org.hibernate.dialect.MySQLDialect</property>  <property name="current_session_context_class">thread</property>  <property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>  <property name="show_sql">true</property> <property name="connection.useUnicode">true</property> <property name="connection.characterEncoding">UTF-8</property>  <property name="hibernate.hbm2ddl.auto">create-drop</property>   <mapping class="br.uniminas.entidades.Cliente" /> <mapping class="br.uniminas.entidades.Produto" /> <mapping class="br.uniminas.entidades.Artesao" /> <mapping class="br.uniminas.entidades.Categoria" /> <mapping class="br.uniminas.entidades.Newsletter" /> <mapping class="br.uniminas.entidades.Administrador" /> <mapping class="br.uniminas.entidades.Usuario" /> <mapping class="br.uniminas.entidades.Pedido" /> <mapping class="br.uniminas.entidades.Item" /> </session-factory> </hibernate-configuration>
Quadro 30 Hibernate.cfg.xml Configurao de conexo a base de dados
82
Com base no Hibernate Configuration File, podemos observar que:
<property name="connection.driver_class">com.mysql.jdbc.Driver</property> <property name="connection.url">jdbc:mysql://localhost:3306/db_sizarts</property> <property name="connection.username">root</property> <property name="connection.password"></property>
Quadro 31 Hibernate.cfg.xml Comunicao com o banco de dados No quadro 31, so exibidas as propriedades para criar conexo com o banco de dados, onde parametrizado o Driver utilizado no SGBD, o endereo onde est localizado o banco de dados, o usurio e senha do administrador desse banco de dados.
<property name="connection.pool_size">1</property>
Quadro 32 Hibernate.cfg.xml Connection pool No quadro 32 exibido um connection pool, significaria piscina de conexes em portugus. Basicamente, uma camada que fica entre o cliente de banco de dados, que faz as conexes com o banco, e o prprio banco, utilizando a propriedade connection.pool_size = 1, permitiremos no mximo uma conexo aberta pelo pool no banco de dados.
<property name="dialect">org.hibernate.dialect.MySQLDialect</property>
Quadro 33 Hibernate.cfg.xml Dialeto No quadro 33 exibido a forma do Hibernate saber para qual banco gerar o SQL o "dialect", onde o mesmo gera o sql dinamicamente de acordo com o banco de dados utilizado.
<property name="current_session_context_class">thread</property>
Quadro 34 Hibernate.cfg.xml Sesso Hibernate De acordo com o quadro 34, quando criamos uma sesso hibernate
83
usando qualquer um dos mtodos sessionFactory.openSession, ser acoplada a sesso para o contexto atual. O contexto padro "thread" o que significa que ser acoplada a sesso para a thread partir do mtodo openSession.
<property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>
Quadro 35 Hibernate.cfg.xml Sesso Hibernate No quadro 35, o cache provider utilizado para que seja guardado em cache a consulta feita na sesso, assim sendo utilizada novamente em consultas posteriores, porm utilizamos a propriedade org.hibernate.cache.NoCacheProvider para que o hibernate no utilize provedor de cache e cause inconsistncias em consultas dentro da mesma sesso.
<property name="show_sql">true</property> <property name="connection.useUnicode">true</property> <property name="connection.characterEncoding">UTF-8</property>
Quadro 36 Hibernate.cfg.xml Show SQL No quadro 36, o show_sql utilizado para que exiba a consulta SQL na sada padro do terminal da API utilizada, onde useUnicode e characterEncoding so configuraes para representar o texto exibido por um padro de texto existente.
<property name="hibernate.hbm2ddl.auto">create-drop</property>
Quadro 37 Hibernate.cfg.xml Hibernate.hbm2ddl.auto No quadro 37 exibida a propriedade hibernate.hbm2ddl.auto, onde possvel escolher se o hibernate dever ser responsvel por criar tabelas ou no. As opes disponveis so: validate (validar as tabelas), create-drop (cria as tabelas mas ao encerrar a aplicao as tabelas so removidas), update (atualiza as tabelas caso seja necessrio).
84 <mapping class="br.uniminas.entidades.Cliente" /> <mapping class="br.uniminas.entidades.Produto" /> <mapping class="br.uniminas.entidades.Artesao" /> <mapping class="br.uniminas.entidades.Categoria" /> <mapping class="br.uniminas.entidades.Newsletter" /> <mapping class="br.uniminas.entidades.Administrador" /> <mapping class="br.uniminas.entidades.Usuario" /> <mapping class="br.uniminas.entidades.Pedido" /> <mapping class="br.uniminas.entidades.Item" />
Quadro 38 Hibernate.cfg.xml Mapping classes Conforme o quadro 38, o mapping class utilizado para mapear as entidades existentes no sistema. Desta forma, obtemos ento dois tipos de classes: Entidade: So as classes persistentes. Nessa classe encontram-se os atributos, um construtor, os mtodos de acesso getters and setters e as anotaes do Hibernate. Dentre as mais utilizadas esto: @Id, @Column, @Table, @generatedValue, @Entity. DAO (Data Access Object): Gerencia a conexo com a fonte de dados para obter e armazenar dados, so utilizados para persistir as entidades. Atravs do HibernateUtil podemos realizar as transaes (select, save, update, delete). No Data Access Object temos os mtodos que faro a persistncia dos dados. A utilizao do Hibernate torna a aplicao portvel para mais de um tipo de banco de dados, para que com uma simples alterao no framework altere o SGBD. O Hibernate tambm expe as operaes bsicas de banco de dados para a aplicao, como recuperao de dados, insero, excluso ou alterao. Um ponto importante para a utilizao do Framework Hibernate a orientao a objetos utilizando integrao com banco de dados.
85
5 CONCLUSES
O contato com o cliente para apurao de suas dificuldades nos mostrou uma excelente oportunidade de aplicar o conhecimento adquirido durante o curso, alm de podermos utilizar as diversas ferramentas trabalhadas para o desenvolvimento desse projeto. A utilizao da linguagem UML foi primordial para a modelagem e desenvolvimento do sistema. Interpretamos facilmente as necessidades do cliente e conseguimos transpor para o escopo inicial todos os requisitos fundamentais do projeto tal como as regras definidas pela organizao e suas intenes do produto final. A diagramao do projeto possibilitou uma excelente viso para o desenvolvimento, facilitando o trabalho, comunicao e eficincia de todos os membros responsveis pelo desenvolvimento desse projeto. Utilizando a ferramenta Enterprise Architect, descobrimos uma maneira extremamente simples de suprir nossas necessidades quanto aplicao do UML e propiciou agilidade na realizao dos esboos iniciais do projeto tanto como nos diagramas conclusivos do negcio. Com a utilizao da linguagem de programao Java, que prov toda a facilidade de uma linguagem orientada a objetos, desenvolvemos uma soluo que est atual no mercado, utilizando dos melhores recursos tecnolgicos disponveis, como a ferramenta de desenvolvimento Eclipse e frameworks, o que reduziu drasticamente o tempo empenhado na construo do produto desejado e at mesmo em manutenes que o software pode vir a receber. Atravs do uso da arquitetura MVC, que possibilita a diviso do software em camadas, o entendimento para a criao do sistema tornou-se mais claro, possibilitando um trabalho padronizado, o que deixa o produto final com uma consistncia maior e possibilita que uma atualizao futura seja realizada de maneira mais prtica e rpida. Sendo assim, o MVC contribuiu para que ocorresse a separao entre os dados do sistema e a apresentao das aplicaes. Os dados ficam independentes da camada de interface, alteraes em uma camada no
86
impactam diretamente na outra. Aplicando o framework Struts2, encontramos maior facilidade no ato do desenvolvimento, sendo que este faz o trabalho do controlador, evitando assim que fosse criado uma srie de Servlets, que dificultaria muito a implementao e manuteno do sistema. Pelo uso dos padres de projeto foi reforada a importncia da diviso em camadas, onde fizemos o controle das aes com o Front Controller atravs do Struts2. As regras de negcio por sua vez foram separadas do restante da aplicao atravs das classes BO (Business Object). As classes DAO que se utilizaram do framework Hibernate3 foram responsveis por todos os tipos de interao com os dados, facilitando assim com que os desenvolvedores visualizassem as interaes com o banco MySQL, que atendeu perfeitamente as nossas necessidades, comportando-se de maneira simples, de fcil utilizao e sem complicar o desenvolvimento do produto. Tendo o projeto parcialmente desenvolvido, entendemos que possvel desenvolver um comercio eletrnico com todas as tecnologias demonstradas aqui e utilizando os conceitos aprendidos no decorrer do curso de forma profissional. Observando o crescimento da divulgao do trabalho dos artesos e de seus produtos, o software poder ser continuado e possivelmente aplicado a fins comerciais, se tornado um produto rentvel, de boa qualidade e preparado para o mercado atual e futuro.
87
REFERNCIAS BIBLIOGRFICAS
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. BAUER, Christian.; King, Gavin ; Hibernate em ao. Traduo Cludio Rodrigues Pistilli, Geane Girotto e Fabio Makoto. Rio de Janeiro: Cincia Moderna, 2005. 532p. BEZERRA, Eduardo. Princpios de Anlise e Projeto de Sistemas com UML . Rio de Janeiro Elsevier, 2002. 286p. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: Guia do Usurio. Traduo de Fbio Freitas da Silva. Rio de Janeiro: Campus, 2000. 472 p. DEITEL, Harvey. Java como programar. Traduo Edson Furmankiewicz Reviso Tcnica Fbio Lucchini. 6 ed. So Paulo: Person Education, 2006. DEITEL, Harvey. Java como programar. Traduo Edson Furmankiewicz. 3ed. So Paulo: Person Education, 2001. 1199p GUEDES, Gilleanes. UML 2 Guia da Consulta Rpida. 2.ed. So Paulo: Novatec, 2005. 109p. HIBERNATE. Relational Persistence for Java and .NET. <http://www.hibernate.org> Acesso em: 23 Jun. 2010.
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. TODD, Nick; Mark Szolkowski. Java Server Pages O Guia do Desenvolvedor . Traduo Edson Furmankiewicz. Rio de Janeiro: Elsevier, 2003. 621p. WAZLAWICK, Raul Sidnei. Analise e projeto de sistemas de informao orientados a objeto. Rio de Janeiro: Elsevier, 2004. 298p.
88
ANEXO A- DADOS IMPORTANTES
CDIGO FONTE DO PROGRAMA
//arquivo struts.xml: mapeamento das aes a serem utilizadas nas pginas JSP
<?xml version="1.0" encoding="UTF-8" ?> <!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="index"> <result>/resources/index.jsp</result> </action> <action name="produtoCentro" method="getUltimosProdutos" class="br.uniminas.action.ProdutoAction"> <result name="success">centro.jsp</result> </action> <action name="index1" method="getAllCategorias" class="br.uniminas.action.CategoriaAction"> <result name="success">index.jsp</result> </action>  <action name="comprar" method="comprar" class="br.uniminas.carrinho.Comprar"> <result name="ok">/carrinho.jsp</result> </action> <action name="excluir" method="excluir" class="br.uniminas.carrinho.Comprar"> <result name="ok">/carrinho.jsp</result> </action> <action name="atualizar" method="atualizar" class="br.uniminas.carrinho.Comprar"> <result name="ok">/carrinho.jsp</result> </action> <action name="colocarNoCarrinho" method="addProduto" class="br.uniminas.action.ProdutoAction"> <result name="sucesso">getAllProdutos</result> </action> <action name="showUpload"> <result>/resources/input_upload.jsp </result>
89 </action>  <action name="cadCliente"> <result>/resources/clienteForm.jsp</result> </action> <action name="insertOrUpdateCliente" method="insertOrUpdate" class="br.uniminas.action.ClienteAction"> <result name="success" type="redirect-action">getAllClientes</result> <result name="input">/resources/clienteForm.jsp</result> </action> <action name="setUpForInsertOrUpdateCliente" method="setUpForInsertOrUpdate" class="br.uniminas.action.ClienteAction"> <result name="success">/resources/clienteForm.jsp</result> </action> <action name="getAllClientes" method="getAllClientes" class="br.uniminas.action.ClienteAction"> <result>/resources/clienteView.jsp</result> </action> <action name="deleteCliente" method="deleteCliente" class="br.uniminas.action.ClienteAction"> <result name="success" type="redirect-action">getAllClientes</result> </action>   <action name="cadProduto" method="setUpForInsertOrUpdate" class="br.uniminas.action.ProdutoAction"> <result name="success">/resources/produtoForm.jsp</result> </action> <action name="anexarProduto" class="br.uniminas.action.AnexoAction" method="anexar"> <!-<interceptor-ref name="fileUpload" /> <interceptor-ref name="basicStack" /> --> <result name="success" type="redirect-action">getAllProdutos</result> <result name="erro">/error.jsp</result> </action> <action name="insertOrUpdateProduto" method="insertOrUpdate" class="br.uniminas.action.ProdutoAction"> <result>/resources/produtoForm.jsp</result> </action> <action name="getAllProdutos" method="getAllProdutos" class="br.uniminas.action.ProdutoAction"> <result name="success">/resources/produtoView.jsp</result> </action> <action name="getProdutoCategoria" method="getProdutoCategoria" class="br.uniminas.action.ProdutoAction">
90 <result name="success">/resources/listaProduto.jsp</result> </action> <action name="getPesquisaProdutoCategoria" method="getPesquisaProdutoCategoria" class="br.uniminas.action.ProdutoAction"> <result name="success">/resources/listaProduto.jsp</result> </action> <action name="setUpForInsertOrUpdateProduto" method="setUpForInsertOrUpdate" class="br.uniminas.action.ProdutoAction"> <result name="success">/resources/produtoForm.jsp</result> </action> <action name="insertOrUpdateProduto" method="insertOrUpdate" class="br.uniminas.action.ProdutoAction"> <result name="success" type="redirect-action">getAllProdutos</result> <result name="input">/resources/produtoForm.jsp</result> </action> <action name="deleteProduto" method="deleteProduto" class="br.uniminas.action.AnexoAction"> <result name="success" type="redirect-action">getAllProdutos</result> </action> <action name="produtoDetalhes" method="getProdutoId" class="br.uniminas.action.ProdutoAction"> <result name="success">/resources/produtoDetalhes.jsp</result> </action>   <action name="cadArtesao"> <result>/resources/artesaoForm.jsp</result> </action> <action name="insertOrUpdateArtesao" method="insertOrUpdate" class="br.uniminas.action.ArtesaoAction"> <result name="success" type="redirect-action">getAllArtesaos</result> <result name="input">/resources/artesaoForm.jsp</result> </action> <action name="getAllArtesaos" method="getAllArtesaos" class="br.uniminas.action.ArtesaoAction"> <result name="success">/resources/artesaoView.jsp</result> </action> <action name="setUpForInsertOrUpdateArtesao" method="setUpForInsertOrUpdate" class="br.uniminas.action.ArtesaoAction"> <result name="success">/resources/artesaoForm.jsp</result> </action> <action name="deleteArtesao" method="deleteArtesao" class="br.uniminas.action.ArtesaoAction"> <result name="success" type="redirect-action">getAllArtesaos</result> </action> 
91
 <action name="cadCategoria"> <result>/resources/categoriaForm.jsp </result> </action> <action name="insertOrUpdateCategoria" method="insertOrUpdate" class="br.uniminas.action.CategoriaAction"> <result name="success" type="redirect-action">getAllCategorias</result> <result name="input">/resources/categoriaForm.jsp</result> </action> <action name="getAllCategorias" method="getAllCategorias" class="br.uniminas.action.CategoriaAction"> <result name="success">/resources/categoriaView.jsp</result> </action> <action name="setUpForInsertOrUpdateCategoria" method="setUpForInsertOrUpdate" class="br.uniminas.action.CategoriaAction"> <result name="success">/resources/categoriaForm.jsp</result> </action> <action name="deleteCategoria" method="deleteCategoria" class="br.uniminas.action.CategoriaAction"> <result name="success" type="redirect-action">getAllCategorias</result> </action>  </package> </struts>

TCC Wagner Alves

Enviado por

Dados do documento

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 Wagner Alves

Enviado por

Direitos autorais:

Formatos disponíveis

FACULDADE SO LOURENO

BACHARELADO EM SISTEMAS DE INFORMAO

PROPRIEDADE DE BENS VIRTUAIS

WAGNER ALVES DA SILVA JUNIOR

WAGNER ALVES DA SILVA JUNIOR

PROPRIEDADE DE BENS VIRTUAIS

Orientador: Prof. Aldyr Amaro.

WAGNER ALVES DA SILVA JUNIOR

PROPRIEDADE DE BENS VIRTUAIS

Orientador: Prof. Aldyr Amaro

LISTA DE ABREVIATURAS E SMBOLOS

1.1 Cenrio atual

Quadro 1 Faturamento Comercio Eletronico Fonte: http://www.lojistaonline.com.br/wtk/pagina/lojista_oque (2010)

18 Dentro deste contexto, o sistema de Comrcio Eletrnico se destina a:

Pequenas indstrias em busca de divulgao e ampliao de sua rede de clientes.

Empresas de servios e profissionais autnomos buscando divulgao do seu negcio.

19 1.2 Identificao do problema

1.3 Objetivos do trabalho

Utilizar o framework Struts 2 para camada de apresentao e o Hibernate para persistncia;

1.4 Organizao do Trabalho

O trabalho descrito est organizado como se segue:

1.5 Descrio do negcio e da empresa

1.5.1 Requisitos funcionais

1.5.2 Requisitos no funcionais

1.6 Regras de negcio

S sero permitidos pagamentos vista e efetuados por depsito bancrio.

Quadro 1 Documentao da regra de negcio RN 01

Alterao de pedidos Pedidos j fechados no podero ser alterados.

Quadro 2 Documentao da regra de negcio RN 02

Quadro 3 Documentao da regra de negcio RN 03

Descrio - Os emails no devero ser respondidos;

Quadro 4 Documentao da regra de negcio RN 04

Envio para transportadora

A mercadoria s ser enviada para a transportadora aps a confirmao de pagamento.

Quadro 5 Documentao da regra de negcio RN 05

Prazo para a confirmao de pagamento

Quadro 6 Documentao da regra de negcio RN 06

Quadro 7 Documentao da regra de negcio RN 07

Quadro 8 Documentao da regra de negcio RN 08

Todos os campos obrigatrios devem ser preenchidos para concluso de cadastro.

Quadro 09 Documentao da regra de negcio RN 09

Quadro 10 Documentao da regra de negcio RN 10

Cancelamento de pedido Sero cancelados pedidos sem pagamentos efetuados.

Quadro 11 Documentao da regra de negcio RN 11

Quadro 12 Documentao da regra de negcio RN 12

O arteso s poder gerenciar (incluir, editar, excluir) os seus prprios produtos.

Quadro 13 Documentao da regra de negcio RN 13

3 ANLISE DE PROJETO DO SISTEMA

31 1.8 Ferramenta de modelagem

1.9 Unified Modeling Language UML

1.10 Casos de Uso

3.1.2 Fluxos da documentao de Casos de Uso Conforme Bezerra (2002):

1.12 Diagrama de Casos de Uso

Figura 1 - Diagrama de Casos de Uso

1.13 Descrio dos Casos de Uso e Atores

3.1.3 Descrio dos Casos de Uso

Manter dados do cliente

Quadro 14 Documentao de caso de uso Manter dados do cliente.

Manter dados do arteso

Quadro 15 Documentao de caso de uso Manter dados do arteso.

Manter dados do produto

Quadro 16 Documentao de caso de uso Manter dados do produto.

Manter dados de categoria

Quadro 17 Documentao de caso de uso Manter dados de categoria.