tcc - sistemas de informação

FACULDADE PITÁGORAS DE UBERLÂNDIA

BACHARELADO EM SISTEMAS DE INFORMAÇÃO

LOJA VIRTUAL DE PRODUTOS ARTESANAIS

BRUNO HENRIQUE VINHADEL SILVA

JULIANO GARCIA DE ALMEIDA

MARCUS VINÍCIUS MOTA

Uberlândia

2010





Trabalho de Final de curso submetido à

Faculdade Pitágoras de Uberlândia como

parte dos requisitos para a obtenção do

grau de Bacharel em Sistemas de

Informação.

Orientador: Prof. Ms. Edson Angoti

Júnior.

Uberlândia

2010





Trabalho de Final de curso submetido à

Faculdade Pitágoras de Uberlândia como

parte dos requisitos para a obtenção do

grau de Bacharel em Sistemas de

Informação.

Orientador: Prof. Ms. Edson Angoti

Júnior.

Uberlândia, 25 de junho de 2010.

Banca Examinadora:

Prof. Ms. Edson Angoti Júnior (Orientador)

Prof. Esp. Carlos Henrique Barros

Prof. Esp. Walteno Martins Parreira Júnior

Uberlândia

2010

DEDICATÓRIA

Dedicamos esse projeto às nossas famílias que sempre nos apoiaram na

decisão de nos tornarmos Bacharéis em Sistemas de Informação, que sempre

estiveram presentes quando precisávamos, que nos motivaram quando as

dificuldades eram mais pesadas do que podíamos suportar, que nos apoiaram até

as mais altas horas da madrugada enquanto trabalhávamos nesse projeto, que

nunca nos deixaram desistir dos nossos sonhos e finalmente, a todos nossos

colegas, parceiros e amigos de grupo que cumpriram perfeitamente com todo o

trabalho realizado sempre acreditando que um dia conseguiríamos tudo pelo que

batalhamos.

AGRADECIMENTOS

Primeiramente a Deus, por nos dar a oportunidade de vivenciar as

mais variadas experiências dessa vida. Aos nossos grandes professores do curso

de Sistemas de Informação da faculdade PITAGORAS, que sempre demonstraram

paciência e dedicação nos ensinando e nos tornando melhores profissionais. Um

agradecimento em especial ao professor Edson Angoti, que dedicava seu tempo

nos auxiliando com as dificuldades do curso, melhorando nossos aspectos pessoais

e profissionais e sempre fornecendo muita atenção para que esse trabalho fosse

concluído da melhor maneira possível. Aos nossos amigos que estiveram ao nosso

lado nessa jornada de aprendizado e trabalho. As famílias que confiaram em

nossas decisões, nos motivando e apoiando no que precisávamos.

RESUMO

Este projeto teve por objetivo a modelagem de uma loja virtual para um grupo de

artesãos. Através de algumas reuniões com os membros do grupo, pudemos

conhecer mais a fundo o universo que compõe esses trabalhos artesanais e saber

as reais necessidades do nosso cliente. Com o levantamento dos requisitos em

mãos, nosso próximo passo seria iniciar a documentação do sistema, aplicando os

conhecimentos adquiridos.Foi de extrema importância o uso da UML (Unified

Modeling Language), para mostrar de maneira clara e consistente o funcionamento

do sistema, através de seus principais diagramas, como o Diagrama de Casos de

Uso, o Diagrama de Classes e o Diagrama de Seqüência. O sistema foi batizado de

SYSARTS. Foi utilizado o modelo MVC2 (Model-View-Controller) seguindo alguns

padrões de desenvolvimento JEE (Java Enterprise Edition), entre eles o

FrontController, o Data Access Object e o Business Object, dando ênfase às

camadas de apresentação, negócios e integração. Como se trata de uma aplicação

web distribuída, usamos o Framework Struts, o qual implementa o padrão JEE

FrontController; o mapeamento objeto relacional foi implementado com o uso do

Framework Hibernate.

Palavras Chave: Java, Struts, Hibernate, Framework, MVC, UML, sistema, padrões

de projeto, artesãos.

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 Artesão...............................................................................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 Artesão.............................................................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 Seqüência Manter Dados de Artesão...............................60

Figura 17 - Diagrama de Seqüência Manter Categoria............................................61

Figura 18 - Diagrama de Seqüência Manter Dados de Cliente................................62

Figura 19 - Diagrama de Seqüência Manter Newsletter..........................................63

Figura 20 - Diagrama de Seqüência Manter Produto...............................................64

Figura 21 - Diagrama de Seqüência Gerar consultas..............................................65

Figura 22 - Diagrama de Seqüência Gerar relatórios...............................................65

Figura 23 - Diagrama de Seqüência Realizar encomenda.......................................66

Figura 24 - Diagrama de Seqüência Gerar carrinho................................................67

Figura 25 - Diagrama de Seqüência Cancelar pedido.............................................68

Figura 26 - Diagrama de Seqüência Efetuar pedido................................................69

Figura 27 - Diagrama de Seqüência Efetuar pagamento.........................................70

Figura 28 – Funcionamento da persistência de dados..............................................71

Figura 29 – Modelo Arquitetural do Padrão de Projetos

DAO....................................73

Figura 30 - Diagrama de Sequência – Utilização 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 Negócio RN-01.......................................................................26

Quadro 2 – Regra de Negócio RN-02......................................................................26








Quadro 10 – Regra de Negócio RN-10....................................................................28




Quadro 14– Caso de Uso – Manter dados do cliente..............................................38

Quadro 15 – Caso de Uso – Manter dados do artesão............................................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 relatórios...........................................................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 – Manipulação de dados no SGBD......77

Quadro 30 – Hibernate.cfg.xml – Configuração de conexão a base de dados..........81

Quadro 31 – Hibernate.cfg.xml – Comunicação 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 – Sessão Hibernate..................................................82

Quadro 35 – Hibernate.cfg.xml – Sessão 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 SÍMBOLOS

API - Application Programming Interface

BO - Business Object

CEP - Código e Endereçamento Postal

CNPJ - Cadastro Nacional da Pessoa Jurídica

CPF - Cadastro de Pessoa Física

CSS - Cascading Style Sheets

DAO - Data Acess Object

HTML - Hypertext Markup Language

HTTP - Hypertext Transfer Protocol

JEE - Java Enterprise Edition

JSP - Java Server Pages

MVC - Model-view-controller

SQL - Structured Query Languague

UML - Unified Modeling Language

XML - Extensible Markup Language

SUMÁRIO

1 INTRODUÇÃO.................................................................................................................................. 17

1.1 CENÁRIO ATUAL DO .....................................................................................................................171.2 IDENTIFICAÇÃO DO PROBLEMA.......................................................................................................171.3 OBJETIVOS DO TRABALHO.............................................................................................................17

1.3.1 Geral................................................................................................................................... 171.3.2 Específicos.......................................................................................................................... 18

1.4 JUSTIFICATIVA PARA A PESQUISA...................................................................................................181.5 ORGANIZAÇÃO DO TRABALHO.......................................................................................................19

2 ESPECIFICAÇÃO DO PROBLEMA.................................................................................................21

2.1 DESCRIÇÃO DO NEGÓCIO E DA EMPRESA.......................................................................................21 2.1.1 REQUISITOS FUNCIONAIS........................................................................................................21 2.1.2 REQUISITOS NÃO FUNCIONAIS.................................................................................................22 2.2 REGRAS DE NEGÓCIO...................................................................................................................25

3 ANÁLISE DE PROJETO DO SISTEMA............................................................................................25

3.1 INTRODUÇÃO...............................................................................................................................28 3.2 FERRAMENTA DE MODELAGEM......................................................................................................29 3.3 UNIFIED MODELING LANGUAGE – UML..........................................................................................31 3.3.1 FASES DO DESENVOLVIMENTO DE UM SISTEMA EM UML..........................................................32 3.4 CASOS DE USO............................................................................................................................34 3.4.1 FLUXOS DA DOCUMENTAÇÃO DE CASOS DE USO......................................................................34 3.5 CLASSES.....................................................................................................................................35 3.6 REGRA DE NEGÓCIO.....................................................................................................................36 3.7 DIAGRAMA DE CASOS DE USO.......................................................................................................37 3.8 DESCRIÇÃO DOS CASOS DE USO E ATORES...................................................................................37 3.8.1 DESCRIÇÃO DOS CASOS DE USO............................................................................................37 3.8.2 DESCRIÇÃO DOS ATORES.......................................................................................................52 3.9 CLASSES DE ANÁLISE...................................................................................................................53 3.9.1 DIAGRAMA DE CLASSES DE NEGÓCIO......................................................................................53 3.9.2 CLASSES DE FRONTEIRA........................................................................................................54 3.9.3 CLASSE CONTROLADORA.......................................................................................................55 3.9.4 CLASSE DE ENTIDADE............................................................................................................57 3.10 DIAGRAMA DE SEQÜÊNCIA..........................................................................................................59

4 PERSISTÊNCIA DE DADOS.............................................................................................................70

4.1 INTRODUÇÃO...............................................................................................................................70

5 CONCLUSÕES..................................................................................................................................84

REFERÊNCIAS BIBLIOGRÁFICAS.....................................................................................................86

16

1 INTRODUÇÃO

1.1 Cenário atual

O artesanato é o ato no qual o produtor (artesão) possui

os meios de produção e trabalha geralmente em sua própria casa, realizando

todas as etapas da produção, desde o preparo da matéria-prima, até o

acabamento do produto.

A implantação de uma Loja Virtual é uma etapa muito importante

para o sucesso de um negócio, com o avanço da tecnologia e com o

aquecimento da Internet, a divulgação de produtos via Web possibilita um

maior

reconhecimento além de atingir vários nichos de mercado.

Comércio Eletrônico é o canal mais moderno e simples de

vendas, não envolve pesados recursos de investimentos ou de pessoal e pode

ser acessado em qualquer lugar do mundo através da INTERNET.

Os dados são reais: o comércio eletrônico (e-commerce) no país está

crescendo a taxas médias de 40% ao ano. Em 2008 fechou com R$ 8,2

bilhões de faturamento, e a previsão para 2010 está na casa dos R$ 15,4

bilhões.

17

Veja o histórico:

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 negócios com

maior velocidade. E as micro, pequenas e

médias empresas (MPMEs) que representam 93% dos estabelecimentos

formais em operação, também já entenderam o recado.

É preciso entrar no mundo do Comércio Eletrônico (e-commerce)

para se tornarem mais competitivas. Aliás, o Comércio Eletrônico é a maior

revolução na democratização do livre comércio e da igualdade de competição

entre grandes e pequenas empresas.

http://www.lojistaonline.com.br/wtk/pagina/lojista_oque

18

Dentro deste contexto, o sistema de Comércio Eletrônico se

destina a:

Empreendedores que querem abrir seu negócio 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 território nacional.

Pequenas indústrias em busca de divulgação e ampliação de sua rede

de clientes.

Artesãos que necessitam de um canal para divulgação de seu

trabalho e manutenção de um catálogo atualizado de produtos.

Empresas de serviços e profissionais autônomos buscando

divulgação do seu negócio.

Empresas com alta rotatividade de produtos requerendo atualização

constante dos sites, como imobiliárias e agências de automóveis.

Cooperativas que desejam romper com as barreiras geográficas e

exportar seus produtos.

Com base nas informações relatadas acima,

a não ser que haja uma reversão completa do quadro evolutivo da tecnologia e

de todas as tendências observadas até aqui, as empresas que apostarem no

Comércio Eletrônico terão um enorme e qualificado mercado para conquistar

nos próximos anos. Quem duvidar disso corre o risco de perder o foguete da

história.

19

1.2 Identificação do problema

O problema abordado consiste em realizar um projeto para o

desenvolvimento de um software Web no modelo de um Comercio Eletrônico

onde serão comercializados produtos artesanais realizados por um grupo de

Artesãos autônomos. Através dessa Loja Virtual, será possível uma maior

divulgação dos produtos dos Artesãos 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 a divulgação e

comercialização de produtos artesanais. Este documento tem como finalidade

a formalização dos processos de elaboração do projeto de uma Loja Virtual.

20

1.3.2 Específicos

Levantar os requisitos funcionais e não funcionais do sistema;

Definir as regras de negócio juntamente com o cliente;

Documentar os requisitos utilizando uma linguagem de modelagem

específica (UML);

Utilizar o framework Struts 2 para camada de apresentação e o

Hibernate para persistência;

Utilizar banco de dados MYSQL;

Implementar o sistema utilizando linguagem de programação Java;

Utilizar linguagem HTML e CSS para implementação da Interface;

Utilizar uma ferramenta para elaboração dos diagramas de Casos de

Uso, Classes e de Seqüência;

Utilizar os padrões de projeto DAO, Front Controller, JEE e MVC;

Utilizar uma ferramenta para modelagem de dados;

1.3.3 Justificativa

A exposição de produtos e serviços pela Internet torna mais

prática à vida dos fornecedores e consumidores dos mesmos, pois com a

visualização e processo de compras online faz com que aumente a

abrangência de exposição por todo país (em alguns casos internacionalmente

divulgados) e acessibilidade a uma maior variedade de produtos/serviços

prestados.

21

Assim o desenvolvimento de um software para exposição e comercialização

de produtos artesanais por todo o território nacional trará aos artesãos uma

integração maior entre si, podendo visualizar e criar novos produtos à partir da

idéia da variedade encontrada na Loja Virtual. Além dessa integração, os

consumidores terão um acesso unificado de vários produtos criados por várias

regiões diferentes e assim encontrar com maior facilidade o produto desejado

em questão, além de facilitar na busca do custo x benefício ideal para sua

condição financeira para a aquisição desse tipo de produto.

1.4 Organização do Trabalho

O trabalho descrito está organizado como se segue:

O capítulo 2 descreve o problema a ser abordado. Ainda neste capítulo

serão apresentados os requisitos do sistema a serem implementados

que foram levantados nas reuniões com o cliente e as regras de

negocio.

O capítulo 3 aborda a parte de análise. O estudo do UML foi

fundamental para este capítulo, nele são abordados os principais

diagramas dessa linguagem.

No capítulo 4, é feita uma síntese das tecnologias utilizada para o

mapeamento objeto relacional e a persistência dos dados.

Por fim, o capitulo 5 apresenta as conclusões obtidas com a pesquisa

realizada e o resultado final da experiência do trabalho feito.

22

2 ESPECIFICAÇÃO DO PROBLEMA

2.1 Descrição do negócio e da empresa

Um grupo de artesãos produz e comercializa seus próprios

produtos, sendo todos estes artesanais e feitos individualmente por cada

artesão. Em conjunto, estes artesãos promovem feiras e eventos para que

possam divulgar seu trabalho para a região e de certa maneira, tornarem-se

reconhecidos na sua região de atuação. A partir de um consenso, os artesãos

decidiram que poderiam divulgar seu trabalho e comercializar suas

mercadorias com mais regiões 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 então necessária a criação de uma loja

virtual para exposição e venda destas mercadorias tão como negociações com

demais interessados em seus trabalhos.

2.1.1 Requisitos funcionais

De acordo com Sommerville (2003), requisitos funcionais são aqueles que

definem funções que o sistema deve fornecer.

Manter clientes: O sistema deve permitir o gerenciamento de novos clientes

(Inclusão, visualização, alteração, exclusão). O visitante do site poderá se

cadastrar através de uma área disponibilizada na página e posteriormente

visualizar seus dados fazer alterações que forem necessárias.

Manter artesãos: O sistema deve permitir o gerenciamento de artesãos

(Inclusão, visualização, alteração, exclusão). O gerenciamento total é feito

pelo administrador do sistema. O artesão já cadastrado pelo administrador

poderá visualizar seus dados fazer alterações que forem necessárias.

23

Manter produtos: O sistema deve permitir o gerenciamento de produtos

(Inclusão, visualização, alteração, exclusão). O artesão é responsável por

cadastrar o produto e suas especificações, fazer alterações e excluir caso haja

necessidade. O administrador do sistema também pode efetuar o

gerenciamento total de produtos.

Manter categorias: O sistema deve permitir o gerenciamento de categorias

(Inclusão, visualização, alteração, exclusão). O artesão é responsável por

cadastrar a categoria, fazer alterações e excluir caso haja necessidade. O

administrador do sistema também pode efetuar o gerenciamento total.

Realizar encomendas: O sistema deverá permitir a realização de

encomendas. Visitantes já cadastrados podem, através de um formulário,

fazer uma encomenda em particular para algum artesão. Esse pedido é

enviado via e-mail ao artesão selecionado. Toda encomenda é negociada a

parte com o artesão, 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 específica 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 opção aparece previamente selecionada. O conteúdo

do newsletter é definido preferencialmente pelo artesão.

24

Gerar carrinho de compras: O sistema deverá gerar um carrinho de

compras. O cliente ao selecionar a opção Comprar de determinado produto,

adicionará automaticamente o mesmo em seu carrinho de compras. É

permitida a inclusão, alteração e remoção de itens e produtos do carrinho.

Cancelar pedidos: O sistema deverá permitir o cancelamento de um pedido

onde não foi confirmado o pagamento. O usuário pode desistir da compra caso

ainda não tenha feito o pagamento. O cancelamento deve ser notificado ao

artesão do respectivo produto.

Confirmar pagamento: O sistema deverá permitir a confirmação de

pagamento. Clientes que já tenham fechado o pedido podem através de uma

opção no seu painel de controle, confirmar o pagamento enviando o

comprovante de depósito bancário.

Confirmar pedido: O sistema deverá permitir a confirmação do pedido. Ao

escolher todos os produtos desejados e a quantidade de itens, o cliente terá a

opção de fechar seu pedido, calculando o frete e confirmando assim sua

compra e o valor final.

Gerar relatórios: O sistema deverá permitir que sejam gerados relatórios. O

administrador do sistema poderá através de seu painel de controle, gerar

relatórios atualizados com dados sobre produtos, artesãos, vendas, etc.

Enviar notificação: O sistema deverá enviar notificação ao artesão sobre sua

peça vendida ou sobre a venda cancelada. Todo artesão 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 movimentação no estoque deverá ser controlado pelo sistema, que

deverá manter o mesmo sempre atualizado.

Visualizar status do pedido: O sistema deverá permitir a visualização de

status do pedido. O cliente poderá acessar seu pedido e conferir se o

pagamento foi confirmado pelo artesão, se a mercadoria já foi enviada,

rastrear o transporte do pedido, etc.

2.1.2 Requisitos não funcionais

De acordo com Sommerville (2003), requisitos não funcionais

são aqueles que podem estar relacionados às restrições 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

disponível no mercado, para todas as plataformas.

SGBD Free – O sistema de gerenciamento de banco de dados do web site

deverá ser grátis , já que o cliente não deseja adquirir uma licença sendo que

um software gratuito pode suprir todas as necessidades desejáveis.

Linguagem de programação Java – Todo o software deve utilizar da

linguagem de programação JAVA para seu desenvolvimento, suas

funcionalidades e obrigações, excluindo assim qualquer outra tecnologia que

não possa ser utilizada em JAVA.

26

Interface Amigável – O aspecto visual do sistema deve ter aparência

agradável, usual e de fácil compreensão do usuário.

Usabilidade – Artesãos devem ser capazes de utilizar as funcionalidades do

software após um treinamento. Clientes devem ser capazes de compreender a

linguagem visual do site e utilizar suas funções de maneira fácil e intuitiva.

2.2 Regras de negócio

São políticas, condições ou restrições que devem ser

consideradas na execução dos processos existentes em uma organização.

Descrevem a maneira pela qual a organização funciona.

Nome Pagamentos RN- 01

DescriçãoSó serão permitidos pagamentos à vista e efetuados por depósito

bancário.

Quadro 1 – Documentação da regra de negócio RN – 01

Nome Alteração de pedidos RN- 02

DescriçãoPedidos já fechados não poderão ser alterados.


27

Nome Notificar venda RN- 03

DescriçãoEm todas as vendas realizadas, o artesão responsável pela mercadoria

deverá ser comunicado sobre a venda.


Newsletter RN- 04

Descrição

O usuário que deseja receber notícias sobre a associação de artesãos deverá concordar com os termos de uso, tais como: - Os emails não deverão ser respondidos;- Qualquer novidade que a empresa julgar relevante será enviado sem questionamento do usuário.


Nome Envio para transportadora RN- 05

DescriçãoA mercadoria só será enviada para a transportadora após a confirmação

de pagamento.


Nome Prazo para a confirmação de pagamento RN- 06

DescriçãoO cliente tem o prazo máximo de cinco dias úteis para confirmar o depósito, não havendo essa confirmação o pedido será cancelado.


Nome Encomenda RN- 07

DescriçãoO valor e o prazo de entrega de encomendas serão definidos pelo

artesão responsável, que notificará o cliente por email ou outra forma de contato.


28

Nome CPF RN- 08

DescriçãoSó será permitido o cadastro de cliente com CPF válido.


Nome Campos Obrigatórios RN- 09

DescriçãoTodos os campos obrigatórios devem ser preenchidos para conclusão

de cadastro.

Quadro 09 – Documentação da regra de negócio RN –09

Nome Reserva de produto RN- 10

DescriçãoAo realizar um pedido, a quantidade de itens requeridos deve ser

existente no estoque. Os itens devem ser reservados para o pedido em questão.


Nome Cancelamento de pedido RN- 11

DescriçãoSerão cancelados pedidos sem pagamentos efetuados.


29

Nome Validação RN- 12

Descrição

O usuário deverá estar previamente autenticado no sistema para realizar as seguintes funções: fechar pedido, cancelar pedido, efetuar

pagamento, realizar encomenda, manutenção da conta de cliente, manutenção de produtos, manutenção de categorias, manutenção de

conta de artesão, gerar relatórios e manutenção de newsletter.


Nome Gerenciamento de produtos RN- 13

Descrição O artesão só poderá gerenciar (incluir, editar, excluir) os seus próprios produtos.


30

3 ANÁLISE DE PROJETO DO SISTEMA

3.1 Introdução

A atividade que tem como finalidade realizar estudos de

processos a fim de encontrar o melhor caminho racional para que a

informação possa ser processada denomina-se Análise de Sistemas. Os

analistas de sistemas estudam os diversos sistemas existentes entre

hardwares (equipamentos), softwares (programas) e o usuário final. Os seus

comportamentos e aplicações são desenvolvidos a partir de soluções que

serão padronizadas e transcritas da forma que o computador possa executar.

Como é uma ênfase, o foco e o núcleo de trabalho estão

voltados para Administração da Produção de Software, levando em conta a

área tecnológica em que irá auxiliar. O analista de sistemas deve servir como

um tradutor entre as necessidades do usuário e o programa a ser

desenvolvido pelo programador.

A análise é requisito primário para desenvolvimento de softwares

nos dias atuais partindo do princípio de que é a estrutura inicial para

desenvolvimento dos mesmos. Com uma análise bem estrutura pode-se obter

um trabalho melhor organizado e com uma estrutura sólida, o que permite que

erros mais comuns e simples possam ser dados como inexistentes.

http://pt.wikipedia.org/wiki/Programador

http://pt.wikipedia.org/wiki/Usu%C3%A1rio

http://pt.wikipedia.org/w/index.php?title=Administra%C3%A7%C3%A3o_da_Produ%C3%A7%C3%A3o_de_Software&action=edit&redlink=1

31

3.2 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

relações entre esses componentes. Freqüentemente a modelagem de

software usa algum tipo de notação gráfica e são apoiados pelo uso de

ferramentas case. Modelagem de softwares normalmente implica na

construção de modelos gráficos que simbolizam os artefatos de software

utilizados e seus inter-relacionamentos. Uma forma comum de modelagem de

programas procedurais (não orientados a objeto) é através de fluxogramas,

enquanto que a modelagem de programas orientados a objeto normalmente

usam a linguagem gráfica UML(Linguagem de Modelagem Unificada) a qual

os fabricantes líderes de modelagem estão dando suporte. Na criação de

sistemas com qualidade é necessário a utilização de uma boa metodologia

para a modelagem tanto do software, como de seu banco de dados. Algumas

ferramentas já auxiliam na automação da escrita de código e na

implementação da estrutura dos bancos de dados. O banco de dados é

modelado através 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 criação dos modelos, as mais avançadas permitem a

geração de uma parte do código-fonte do software a partir do modelo e até a

geração do banco de dados a partir do modelo de entidade relacionamento.

Pode-se citar uma ferramenta de modelagem que trabalha com

padrões de orientação a objetos: Enterprise Architect

Enterprise Architect é uma ferramenta gráfica projetada para ajudar suas

equipes construir sistemas robustos e de fácil manutenção. Com capacidades

embutidas de gerenciamento de requisitos, ajuda a rastrear as especificações

de alto nível para análise, concepção, implementação, teste e manutenção de

modelos usando UML, SysML, BPMN e outros padrões abertos.

(Traduzido de: http:www. sparxsystems.com.au/products/ea/index.html )

http://pt.wikipedia.org/wiki/UML

3.3 Unified Modeling Language – UML

Unified Modeling Language (UML) é uma linguagem de modelagem

padrão de uso geral no domínio da engenharia de software. O padrão é gerido, e foi

criado pelo Object Management Group.

UML inclui um conjunto de técnicas de notação gráfica 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, não é. 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. Porém, conhecer uma linguagem não

implica habilidade de saber usá-la para produzir artefatos úteis. Por exemplo, a

língua portuguesa é uma linguagem, mas uma pessoa que sabe escrever em

português não sabe necessariamente fazer bons discursos ou boa poesia. Existe

algo por trás da linguagem, denominado método 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 português, escrever

discurso ou poesia corresponde a produzir projetos de sistemas co elegância. Como

diz Booch (1996), não há uma definição precisa sobreo queéum projeto elegante,

mas quem observa um projeto normalmente percebe se ele é elegante ou não.

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 consciência disso.

Os objetivos da UML são:

• A modelagem de sistemas (não apenas de software) usando os conceitos da

orientação a objetos;

• Estabelecer uma união fazendo com que métodos conceituais sejam também

executáveis;

32

• Criar uma linguagem de modelagem usável tanto pelo homem quanto pela

máquina.

3.3.1 Fases do Desenvolvimento de um Sistema em UML

Existem cinco fases no desenvolvimento de sistemas de software:

Comunicação, Análise, Projeto, Implementação e Implantação. Estas cinco fases

não 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.

Comunicação

Esta fase captura as intenções e necessidades dos usuários do

sistema a ser desenvolvido através do uso de funções chamadas caso de uso.

Através do desenvolvimento, as entidades externas ao sistema (em UML chamados

de "atores externos") que interagem e possuem interesse no sistema são

modelados entre as funções que eles requerem. Os atores externos e os casos de

uso são modelados com relacionamentos que possuem comunicação associativa

entre eles ou são desmembrados em hierarquia. Cada caso de uso modelado é

descrito através de um texto, e este especifica os requerimentos do ator externo

que utilizará. O diagrama mostrará o que os atores externos, ou seja, os usuários

do futuro sistema deverão esperar do aplicativo, conhecendo toda sua

funcionalidade sem importar como esta será implementada. A análise de requisitos

também pode ser desenvolvida baseada em processos de negócios, e não apenas

para sistemas de software.

33

Análise

A fase de análise está preocupada com as primeiras abstrações

(classes e objetos) e mecanismos que estarão presentes no domínio do problema.

As classes são modeladas e ligadas através de relacionamentos com outras

classes, e são descritas no Diagrama de Classe. As colaborações entre classes

também são mostradas neste diagrama para desenvolver os casos de uso

modelados anteriormente, estas colaborações são criadas através de modelos

dinâmicos em UML. Na análise, só serão modeladas classes que pertençam ao

domínio principal do problema do software, ou seja, classes técnicas que gerenciem

banco de dados, interface, comunicação, concorrência e outros não estarão

presentes neste diagrama.

Projeto

Na fase de design, o resultado da análise é expandido em soluções

técnicas. Novas classes serão adicionadas para prover uma infra-estrutura técnica:

a interface do usuário e de periféricos, gerenciamento de banco de dados,

comunicação com outros sistemas, dentre outros. As classes do domínio do

problema modeladas na fase de análise são mescladas nessa nova infra-estrutura

técnica tornando possível alterar tanto o domínio do problema quanto à infra-

estrutura. O design resulta no detalhamento das especificações para a fase de

programação do sistema.

Implementação

Na fase de programação, as classes provenientes do design são

convertidas para o código da linguagem orientada a objetos escolhida (JAVA).

Dependendo da capacidade da linguagem usada, essa conversão pode ser uma

tarefa fácil ou muito complicada. No momento da criação de modelos de análise e

design em UML, é melhor evitar traduzi-los mentalmente em código. Nas fases

34

anteriores, os modelos criados são o significado do entendimento e da estrutura do

sistema, então, no momento da geração do código onde o analista conclua

antecipadamente sobre modificações em seu conteúdo, seus modelos não estarão

mais demonstrando o real perfil do sistema. A programação é uma fase separada e

distinta onde os modelos criados são convertidos em código.

Implantação

Um sistema normalmente é rodado em testes de unidade, integração,

e aceitação. Os testes de unidade são para classes individuais ou grupos de

classes e são geralmente testados pelo programador. Os testes de integração são

aplicados já usando as classes e componentes integrados para se confirmar se as

classes estão cooperando uma com as outras como especificado nos modelos. Os

testes de aceitação 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 usuário final e verificará se os resultados

mostrados estão realmente de acordo com as intenções do usuário final.

(WAZLAVICK, 2004)

3.4 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 cenários, onde

cada cenário é uma seqüência de passos a qual descreve uma interação entre um

usuário e o sistema. Os casos de uso são representados em forma de elipse.

35

3.4.1 Fluxos da documentação de Casos de Uso

Conforme Bezerra (2002):

Fluxo principal – descreve uma seqüência de ações que serão executadas

considerando que nada de errado acontecerá durante a execução das ações.

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 alcançar seu objetivo.

Podem descrever escolhas exclusivas entre si.

Fluxos de Exceção – correspondem à descrição das situações de exceção.

Descrevem o que acontece quando algo inesperado ocorre na interação entre ator e

caso de uso (ex.: ator realiza ação inválida)

3.5 Classes

Uma classe é uma descrição de um conjunto de objetos que

compartilham os mesmo atributos, operações, relacionamentos e semântica.

Podem ser implementadas em uma ou mais interfaces. Todos os objetos são

instâncias de classes, onde a classe descreve as propriedades e comportamentos

daquele objeto. Em UML as classes são representadas por um retângulo dividido

em três compartimentos:

- Nome: que conterá apenas o nome da classe modelada;

- Atributos: que possuirá a relação de atributos que a classe possui em sua

estrutura interna;

36

- Operações: que serão os métodos de manipulação de dados e de comunicação de

uma classe com outras do sistema.

A sintaxe usada em cada um destes compartimentos é independente

de qualquer linguagem de programação, embora possam ser usadas outras

sintaxes como a do C++ e Java.

37

3.6 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

3.7 Descrição dos Casos de Uso e Atores

3.7.1 Descrição dos Casos de Uso

38

Nome Manter dados do cliente CSU-01

SumárioEsse caso de uso descreve as etapas necessárias para a manutenção dos dados do cliente (inclusão, alteração).

Ator primário: Cliente.

Ator (es) secundário(s): Não existe.

Pré-condição: Possuir os dados necessários para o cadastro ou estar autenticado no

sistema.

Pós-condição: Cliente cadastrado e\ou apto a utilizar o sistema.

Fluxo Principal

1) O usuário acessa a área de cadastro.

2) O sistema apresenta os campos necessários para o cadastro com a opção para o

recebimento de newsletter.

3) O usuário insere os dados solicitados.

4) O sistema consiste os dados.

5) O sistema informa que o cadastro foi efetuado e envia um email com a

confirmação de cadastro e os dados de acesso para o email do cliente.

6) O sistema apresenta a tela da conta do usuário pronta para manutenção.

Fluxo Alternativo [5]: Alterar dados

a) O usuário seleciona a opção de alterar dados.b) O sistema apresenta os dados para alteração.c) O usuário altera os dados e confirma.d) O sistema valida a alteração e retorna ao passo 5.

Fluxo de Exceção [4]: Validar dados

a) O sistema valida se todos os campos obrigatórios foram preenchidos.b) B.1. Se preenchido, o sistema avança ao passo 4.

B.2. Se não preenchido, o sistema apresenta informa que os dados necessários não foram preenchidos e retorna ao passo 2.

Fluxo de Exceção [4]: CPF inválido

a) O sistema verifica que o CPF é inválido.b) O Sistema apresenta a mensagem de CPF incorreto e solicita a inserção de um

novo CPF válido.c) O sistema retorna ao passo 2.

Regras de Negócio Associadas

RN-04, RN-08, RN-09, RN-12.

Quadro 14 – Documentação de caso de uso – Manter dados do cliente.

39

Nome Manter dados do artesão CSU-02

SumárioEsse caso de uso descreve as etapas necessárias para a manutenção dos dados do artesão (inclusão, alteração, exclusão).

Ator primário: Administrador, Artesão.


Pré-condição: Possuir os dados necessários para o cadastro ou estar autenticado no

sistema.

Pós-condição: Artesão cadastrado ou\e apto a utilizar o sistema.

Fluxo Principal

1) O administrador acessa a área de manutenção de artesão.

2) O sistema apresenta as opções de manutenção.

3) O administrador seleciona a opção de cadastro.

4) O sistema apresenta os campos necessários para a inclusão de artesão.

5) O administrador insere os dados do artesão.

6) O sistema informa que o cadastro foi efetuado e envia um email com a

confirmação de cadastro e os dados de acesso para o email do artesão.

7) O sistema apresenta a conta do artesão pronta para manutenção.

Fluxo Alternativo [7]: Alteração

a) O artesão seleciona a opção de alterar dados.b) O sistema apresenta os dados para alteração.c) O artesão altera os dados e confirma.d) O sistema valida a alteração e retorna ao passo 7.

Fluxo Alternativo [3]: Exclusão

a) O administrador seleciona a opção de exclusão.b) O sistema solicita o cadastro a ser excluído.c) O administrador informa o cadastro.d) O sistema confirma a exclusão e retorna ao passo 2.





RN-09, RN-12.

Quadro 15 – Documentação de caso de uso – Manter dados do artesão.

40

Nome Manter dados do produto CSU-03

SumárioEsse caso de uso descreve as etapas necessárias para a manutenção dos dados dos produtos (inclusão, alteração, exclusão).

Ator primário: Artesão, Administrador.


Pré-condição: Possuir os dados necessários para o cadastro e estar autenticado no

sistema.

Pós-condição: Produto cadastrado, alterado ou excluído com sucesso.

Fluxo Principal

1) O usuário acessa a área de manutenção de produtos.

2) O usuário seleciona a opção de inclusão de produto.

3) O sistema apresenta os campos para inclusão de um novo produto.

4) O usuário insere os dados do produto.

5) O sistema informa que a ação foi efetuada e atualiza o estoque.

6) O sistema apresenta a tela do produto para alteração.

Fluxo Alternativo [2]: Alterar

a) O usuário seleciona a opção de alterar produto.b) O sistema solicita o produto a ser alterado.c) O usuário informa o produto a alterar.d) O artesão insere os dados a serem alterados.e) O usuário avança ao passo 5.

Fluxo Alternativo [2]: Excluir

a) O usuário seleciona a opção de excluir produto.b) O sistema solicita o produto a ser excluído.c) O usuário informa o produto a excluir.d) O sistema avança ao passo 5.





RN-09, RN-12, RN-13.

Quadro 16 – Documentação de caso de uso – Manter dados do produto.

41

Nome Manter dados de categoria CSU-04

SumárioEsse caso de uso descreve as etapas necessárias para a manutenção dos dados das categorias (inclusão, alteração, exclusão).



Pré-condição: Possuir os dados necessários para o cadastro e estar autenticado no

sistema.

Pós-condição: Categoria cadastrada, alterada ou excluída com sucesso.

Fluxo Principal

1) O usuário acessa a área de manutenção de categorias.

2) O usuário seleciona a opção de inclusão de categoria.

3) O sistema apresenta os campos para inclusão de uma nova categoria.

4) O usuário insere os dados da categoria.

5) O sistema informa que a ação foi efetuada.

6) O sistema apresenta a tela de categoria para alteração.


a) O usuário seleciona a opção de alterar categoria.b) O sistema solicita a categoria a ser alterada.c) O usuário informa a categoria a alterar.d) O usuário insere os dados a serem alterados.e) O sistema avança ao passo 6.

Fluxo Alternativo [2]: Excluir

a) O usuário seleciona a opção de excluir categoria.b) O sistema solicita a categoria a ser excluída.c) O usuário informa a categoria a excluir.d) O sistema avança ao passo 6.





RN-09, RN-12.

Quadro 17 – Documentação de caso de uso – Manter dados de categoria.

42

Nome Manter newsletter CSU-05

SumárioEsse caso de uso descreve as etapas necessárias para a manutenção de newsletter (inclusão, alteração, exclusão).



Pré-condição: Possuir as informações para cadastrar a newsletter.

Pós-condição: Newsletter cadastrado e pronto para ser publicado.

Fluxo Principal

1) O usuário acessa a área de newsletter.

2) O usuário seleciona a opção de cadastro de newsletter.

3) O sistema apresenta os campos para o cadastro de newsletter.

4) O usuário insere os dados do newsletter.


6) O sistema apresenta a área de newsletter.


a) O usuário seleciona a opção de alterar newsletter.b) O sistema solicita o newsletter a ser alterada.c) O usuário informa o newsletter a alterar.d) O usuário insere os dados a serem alterados.e) O sistema avança ao passo 5.

Fluxo Alternativo [2]: Publicar

a) O usuário seleciona a opção de publicar newsletter.b) O sistema solicita o newsletter a publicar.c) O usuário informa o newsletter.d) O sistema avança ao passo 5.



B.2. Se não preenchido, o sistema informa que os dados necessários não foram preenchidos e retorna ao passo 3.


RN-12.

Quadro 18 – Documentação de caso de uso – Manter newsletter.

43

Nome Gerar relatórios CSU-06

SumárioEsse caso de uso descreve as etapas necessárias para a geração de relatórios.



Pré-condição: Estar autenticado no sistema.

Pós-condição: Relatório é exibido para o usuário.

Fluxo Principal

1) O usuário acessa a área de relatório.

2) O usuário seleciona a opção de gerar relatório.

3) O sistema apresenta os campos de parâmetro para o relatório.

4) O usuário insere os parâmetros.


6) O sistema exibe o relatório.

Fluxo Alternativo [4]: Parâmetros incorretos

a) O sistema não consegue gerar um relatório com os parâmetros informados.b) O sistema informa que os parâmetros estão incorretos.c) O sistema retorna ao passo 3.

Fluxo de Exceção []: Não existe.


RN-12.

Quadro 19 – Documentação de caso de uso – Gerar relatório.

44

Nome Gerar consultas CSU-07

SumárioEsse caso de uso descreve as etapas necessárias para a realização de consultas.

Ator primário: Cliente, Artesão, Administrador.


Pré-condição: Não existe.

Pós-condição: O sistema exibe os resultados da consulta na tela.

Fluxo Principal

1) O usuário acessa a opção de consulta no sistema.

2) O sistema informa os parâmetros da consulta (produtos, categorias, clientes, entre

outros) variando pela permissão do usuário.

3) O usuário seleciona os parâmetros apresentados e/ou insere parâmetros

adicionais (nomes, datas, entre outros).

4) O sistema efetua a consulta usando os parâmetros informados.

5) O sistema apresenta os resultados encontrados.

Fluxo Alternativo []:

Não existe.

Fluxo de Exceção []:Não existe.


Não existe.

Quadro 20 – Documentação de caso de uso – Gerar consultas.

45

Nome Realizar encomendas CSU-08

SumárioEsse caso de uso descreve as etapas necessárias para solicitar a encomenda de um específico.



Pré-condição: Estar autenticado no sistema.

Pós-condição: A encomenda é enviada para o artesão.

Fluxo Principal

1) O usuário acessa a opção de realizar encomenda.

2) O sistema apresenta o campo de detalhes da encomenda.

3) O usuário insere os detalhes desejados e confirma.

4) O sistema apresenta os artesãos que poderão produzir a encomenda.

5) O usuário seleciona o artesão.

6) O sistema exibe uma mensagem de que o pedido de encomenda foi enviado.

7) O sistema envia ao artesão selecionado os detalhes da encomenda.

8) O sistema retorna a página inicial.


Não existe.



RN-12, RN-07.

Quadro 21 – Documentação de caso de uso – Realizar encomendas.

46

Nome Comprar CSU-09

SumárioEsse caso de uso descreve as etapas necessárias para gerar um carrinho de compras.

Ator primário: Cliente


Pré-condição: Não existe.

Pós-condição: O sistema gera um carrinho de compras com os produtos escolhidos

pelo cliente.

Fluxo Principal

1) O cliente procura no sistema, através de consultas e menus de acesso, o produto

desejado.

2) O cliente seleciona o produto desejado e acessa as especificações do mesmo.

3) O sistema apresenta a opção de incluir o produto no carrinho de compra.

4) O cliente inclui o produto no carrinho de compras.

5) O sistema apresenta o carrinho de compra com os produtos adicionados e o valor

total.

Fluxo Alternativo [5]: Incluir

a) O cliente solicita a opção de continuar comprando.b) O sistema retorna ao passo 1.


a) O usuário executa a alteração da quantidade de itens de determinado produto.b) O sistema faz as alterações.c) O sistema retorna ao passo 5.

Fluxo Alternativo [5]: excluir

a) O usuário solicita a exclusão de um produto do carrinho.b) O sistema exibe a opção e uma mensagem de alerta para confirmação da

exclusão.c) O usuário confirma a exclusão e o caso de uso é encerrado.


Não existe.

Quadro 22 – Documentação de caso de uso – Gerar carrinho de compras.

47

Nome Efetuar pedido CSU-10

SumárioEsse caso de uso descreve as etapas necessárias para efetuar um pedido.



Pré-condição: Produto no estoque

Pós-condição: Pedido realizado com sucesso, artesão notificado sobre o pedido e

estoque atualizado.

Fluxo Principal

1) O cliente seleciona a opção de fechar o pedido.

2) O sistema solicita o CEP para o cálculo de frete.

3) O cliente insere o CEP e confirma.

4) O sistema calcula o valor do frete e apresenta o valor total do pedido.

5) O sistema solicita a confirmação do pedido.

6) O cliente confirma o pedido.

7) O sistema notifica os artesãos correspondentes aos produtos que foram

selecionados pelo cliente por email e atualiza o estoque.

Fluxo Alternativo [6]: Cancelar compra

a) O cliente escolhe a opção de desistir da compra.b) O sistema encerra o caso de uso.

Fluxo de Exceção [1]: Estoque insuficiente

a) O sistema verifica a quantidade disponível de itens no estoque dos produtos selecionados.

b) B.1. Se a quantidade estiver disponível, o sistema avança ao passo 2.B.2. Se a quantidade não estiver disponível, o sistema informa que não há itens disponíveis no estoque e encerra o caso de uso sem fechar o pedido.


RN-02, RN-10.

Quadro 23 – Documentação de caso de uso – Efetuar pedido.

48

Nome Atualizar estoque CSU-11

SumárioEsse caso de uso descreve as etapas necessárias para a atualização de estoque.

Ator primário: CSU-03 (Manter dados produto), CSU-10 (Efetuar pedido), CSU-13

(Cancelar pedido).

Ator (es) secundário(s): Artesão, Cliente.

Pré-condição: Existir algum valor necessário para alterar.

Pós-condição: Estoque atualizado.

Fluxo Principal

1) O sistema recebe uma solicitação de uma operação para atualizar estoque.

2) O sistema solicita os dados para a atualização.

3) A operação informa os dados necessários para atualizar.

4) O sistema valida os dados fornecidos pela operação.

5) O sistema atualiza o estoque.

Fluxo Alternativo [4]: Estoque insuficiente

a) Em caso de exclusão o sistema verifica que a quantidade retirada é maior que a disponível.

b) O sistema exibe uma mensagem de erro informando que o estoque é insuficiente.c) O sistema encerra o caso de uso e não atualiza o estoque.



Não existe.

Quadro 24 – Documentação de caso de uso – Atualizar estoque.

49

Nome Notificar venda CSU-12

SumárioEsse caso de uso descreve as etapas necessárias para a notificação de uma venda.

Ator primário: CSU-10 (Efetuar pedido), CSU-13 (Cancelar pedido).

Ator (es) secundário(s): Cliente.

Pré-condição: Haver uma compra ou cancelamento existente.

Pós-condição: Artesão notificado.

Fluxo Principal

1) A operação solicita o sistema o envio de notificação ao artesão.

2) O sistema identifica o(s) artesão(s) correspondente(s) ao produto do pedido.

3) O sistema envia um e-mail de pedido efetuado/cancelado ao(s) artesão(s) em

questão.

4) O sistema encerra o caso de uso.


Não existe.



Não existe.

Quadro 25 – Documentação de caso de uso – Notificar venda.

50

Nome Cancelar pedido CSU-13

SumárioEsse caso de uso descreve as etapas necessárias para o cancelamento de um pedido.



Pré-condição: Estar autenticado no sistema e existir algum pedido fechado.

Pós-condição: Pedido cancelado com sucesso.

Fluxo Principal

1) O cliente acessa a área de pedidos do sistema.

2) O sistema exibe os pedidos fechados do cliente.

3) O cliente solicita o cancelamento do pedido.

4) O sistema cancela o pedido, notifica o(s) artesão(s) e atualiza o estoque.

Fluxo Alternativo []: -

Não existe.

Fluxo de Exceção []: -Não existe.


RN-11, RN-12.

Quadro 26 – Documentação de caso de uso – Cancelar pedido.

51

Nome Efetuar pagamento CSU-14

SumárioEsse caso de uso descreve as etapas necessárias para efetuar pagamento.



Pré-condição: Existir algum pedido fechado.

Pós-condição: Pagamento efetuado com sucesso.

Fluxo Principal

1) O cliente solicita a opção de efetuar pagamento.

2) O sistema solicita o pedido a ser pago.

3) O usuário informa o pedido.

4) O sistema solicita o comprovante de depósito bancário.

5) O usuário anexa o documento do comprovante e confirma.

6) O sistema envia o comprovante por email aos artesãos que possuem produto no

pedido.

7) O sistema informa ao usuário que o comprovante foi enviado.


a) O sistema valida se o comprovante foi anexado.b) B.1. Se o anexo estiver inserido, o sistema avança ao passo 6.

B.2. Se o anexo não estiver inserido, o sistema informa que o anexo é obrigatório e retorna ao passo 3.


RN-01, RN-06.

Quadro 27 – Documentação de caso de uso – Efetuar pagamento.

52

3.7.2 Descrição dos Atores

Representa qualquer entidade que interage com o sistema.

Administrador

Este ator possui acesso total ao sistema, sendo o único a ter

permissão para listar, cadastrar e modificar todos os clientes, artesãos, produtos e

categorias. Generalizando, tem total acesso as funcionalidades do sistema,

podendo atuar em qualquer área do mesmo.

Artesão

Este ator possui permissão de cadastrar, listar e modificar produtos no

sistema e acompanhar o pedido de seus produtos, tão quanto fazer alterações em

seu perfil de artesão e divulgar newsletter e assuntos afins para clientes.

Cliente

Este ator possui permissão de se cadastrar além de gerenciar seu

perfil. Basicamente o único responsável pela geração um carrinho de compras para

armazenar a quantidade que necessita de produtos para seu pedido e finalizar uma

compra.

53

3.8 Classes de análise

3.8.1 Diagrama de Classes de Negócio

O diagrama de classes é considerado por vários autores como o mais

importante e utilizado diagrama da UML. Ele apresenta uma visão estática da

organização das classes do sistema, permitindo além da visualização das classes e

de seus atributos e métodos, a representação de seus relacionamentos, como estas

se complementam e a transmissão da informação dentro do sistema (SILVA, 2007).

Figura 2 - Diagrama de classes de negócio.

54

3.8.2 Classes de Fronteira

São classes de objetos que permitem a comunicação entre o mundo

externo e o sistema. (GUEDES, 2005).

Figura 3 – Fronteira de Cliente

GUI-Cliente – esta classe, que pertence ao Java Server Pages (jsp), tem a

responsabilidade de apresentar as funcionalidade relativas a manutenção de dados

dos clientes (inclusão, alteração e exclusão).

Figura 4 – Fronteira de Artesão

GUI-Artesão – esta classe, que pertence ao Java Server Pages (jsp), tem a


dos artesãos(inclusão, alteração e exclusão).

Figura 5 – Fronteira de Produto

GUI-Produto – esta classe, que pertence ao Java Server Pages (jsp), tem a


dos produtos(inclusão, alteração e exclusão).

55

Figura 6 – Fronteira de Categoria

GUI-Categoria – esta classe, que pertence ao Java Server Pages (jsp), tem a


das categorias(inclusão, alteração e exclusão).

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 manutenção de

produtos no carrinho (inclusão, alteração e exclusão de itens).

3.8.3 Classe Controladora

São classes que modelam a seqüência de controle específica de um

caso de uso do sistema, ou seja, controlam a execução dos eventos necessários

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 estão centralizadas todas as ações

pertinentes ao cliente, estas ações são mapeadas no arquivo struts.xml para serem

56

usadas nas páginas JSP. Na classe ClienteBO ficam isoladas as regras de negócio,

o que permite um melhor desacoplamento entre as camadas.

Figura 9 – Classe Controladora de Artesão

ArtesaoAction e ArtesaoBO - A classe de controle ArtesaoAction é uma classe que

extend a classe ActionSupport, nela estão centralizadas todas as ações pertinentes

ao artesão, estas ações são mapeadas no arquivo struts.xml para serem usadas

nas páginas JSP. Na classe ArtesaoBO ficam isoladas as regras de negócio, 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 estão centralizadas todas as ações pertinentes

ao produto, estas ações são mapeadas no arquivo struts.xml para serem usadas

nas páginas JSP. Na classe ProdutoBO ficam isoladas as regras de negócio, o que

permite um melhor desacoplamento entre as camadas.

57

Figura 11 – Classe Controladora de Carrinho

CategoriaAction e CategoriaBO - A classe de controle CategoriaAction é uma classe

que estende a classe ActionSupport, nela estão centralizadas todas as ações

pertinentes a categoria, estas ações são mapeadas no arquivo struts.xml para

serem usadas nas páginas JSP. Na classe CategoriaBO ficam isoladas as regras

de negócio, o que permite um melhor desacoplamento entre as camadas.

3.8.4 Classe de Entidade

São classes de objetos que refletem entidades do mundo real, ou seja,

pertence ao domínio 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.

58

Figura 13 – Entidade de Artesão

Artesao e ArtesaoDAO – Artesão faz o papel do mapeamento objeto relacional dos

dados relativos a artesãos, 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.

59

3.9 Diagrama de Seqüência

O diagrama de seqüência é uma ferramenta que deve ser utilizada

sempre em função dos casos de uso. Ele captura o comportamento de um único

caso de uso, ou seja, mostra a interação entre os objetos ao longo do tempo,

apresentando os objetos que participam da interação e a seqüência das mensagens

trocadas. (WAZLAWICK, 2004).

Figura 16 – Diagrama de sequência – Manter artesão

60

A figura 17 mostra o diagrama de seqüência de análise do caso de

uso Manter Categoria, é descrito neste diagrama as funções que o ator

(Artesão) deve exercer para “Manter dados da Categoria”.

Figura 17 – Diagrama de sequência – Manter categoria

61


uso Manter Cliente, é descrito neste diagrama as funções que o ator

(Cliente) deve exercer para seus dados.

Figura 18 – Diagrama de sequência – Manter cliente

62


uso Manter Newsletter, é descrito neste diagrama as funções que o ator

(Artesão) deve exercer para “Manter Newsletter”.

Figura 19 – Diagrama de sequência – Manter newsletter

63


uso Manter Produto, é descrito neste diagrama as funções que o ator

(Artesão) deve exercer para “Manter Produto”.

Figura 20 – Diagrama de sequência – Manter produto

64


uso Gerar Consultas, é descrito neste diagrama as funções que o ator

(Usuário) deve exercer para “Gerar consultas”.

Figura 21 – Diagrama de sequência – Gerar consultas


uso Gerar Relatórios, é descrito neste diagrama as funções que o ator

(Usuário) deve exercer para “Gerar relatório”.

Figura 22 – Diagrama de sequência – Gerar relatórios

65


uso Realizar Encomenda, é descrito neste diagrama as funções que o ator

(Cliente) deve exercer para “Realizar encomenda”.

Figura 23 – Diagrama de sequência – Realizar encomenda

66


uso Compras, é descrito neste diagrama as funções que o ator

(Cliente) deve exercer para comprar.

Figura 24 – Diagrama de sequência – Comprar

67


uso Cancelar Pedido, é descrito neste diagrama as funções que o ator

(Cliente) deve exercer para cancelar o pedido.

Figura 25 – Diagrama de sequência – Cancelar pedido

68


uso Efetuar Pedido, é descrito neste diagrama as funções que o ator

(Cliente) deve exercer para efetuar um pedido.

Figura 26 – Diagrama de sequência – Efetuar pedido

69


uso Efetuar Pagamento, é descrito neste diagrama as funções que o ator

(Cliente) deve exercer para efetuar pagamento.

Figura 27 – Diagrama de sequência – Efetuar pagamento

70

4 PERSISTÊNCIA DE DADOS

4.1 Introdução

A persistência de dados, na computação, refere-se ao

armazenamento não-volátil de dados, por exemplo, em um dispositivo físico de

armazenamento como um disco rígido. Quando se grava um arquivo no disco, por

exemplo, o dado está sendo "eternizado", ou seja, deixa de ficar volátil na memória

RAM e passa a ser escrito em um dispositivo que armazena a informação de modo

que ela não desapareça facilmente, simplificando a persistência de dados é

armazenar dados em um banco de dados relacional.

O termo persistência é associado a uma ação de manter em meio

físico recuperável, sendo esse um banco de dados, arquivo, garantindo a

permanência das informações de um determinado estado de um objeto lógico.

Figura 28 – Funcionamento da persistência de dados

A figura 28 mostra a funcionalidade da persistência de dados para um

sistema genérico. O usuário cria/altera dados dentro do sistema, gerando-os em

71

dados voláteis (em memória, são perdidos após conclusão da execução), a camada

de persistência encapsula esses dados e os eterniza em dados não voláteis

(podendo ser salvos em banco de dados ou arquivo). Após os dados serem

eternizados, a camada de persistência pode recuperar esses dados em qualquer

momento que for solicitado para que o usuário consiga manipular seus próprios

dados novamente, assim reiniciando o fluxo de persistência.

Em Orientação a Objetos, o termo “objetos persistentes” significa que

os dados gerados durante a execução do programa continuam a existir em uma

unidade física não-volátil mesmo após a finalização de sua execução.

Associados à persistência estão o gerenciamento dinâmico da

memória e o armazenamento de objetos em bases de dados. — Somente é

possível "eternizar" um objeto quando este não possui "dados dinâmicos" (runtime),

ou seja, dados que só fazem sentido no contexto do tempo em que estão

executando, como sockets, por exemplo. Se congelados os objetos que possuem

dados de tempo de execução, depois de recuperados os mesmos não farão mais

sentido no contexto do novo tempo, assim sendo ignorados ou perdidos.

Padrão de Projeto DAO

Um dos padrões de projetos mais conhecidos e mais utilizados ainda

hoje é o DAO (Data Access Object). Padrão 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 padrões de

mapeamento de objeto relacional para persistência de objetos em um base de

dados. A função do DAO é abstrair e encapsular o acesso aos dados e criar uma

conexão com a fonte de dados, gerenciando automaticamente o acesso e

armazenamento dos dados. O DAO é responsável por fornecer uma API (Interface

de Programação de Aplicativos) uniforme para que independente do tipo da fonte de

dados haja uma comunicação entre o programa e essas fontes.

O DAO é implementado como um objeto sem informações de estado,

72

onde não armazena em cache os resultados de execução 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 utilização do JDBC e só expor informações como

excessões, estrutura de dados ou objeto para dentro da camada de acesso a

dados.

Usando-se esse padrão a camada de negócios acessa os dados

persistidos sem ter conhecimento se os dados estão em um banco de dados

relacional ou um arquivo XML (eXtensible Markup Language). O padrão DAO

esconde os detalhes da execução da origem dos dados (SUN, 2010).

Figura 29 – Modelo Arquitetural do Padrão de Projetos DAO

(Fonte: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html, 2010)

O modelo arquitetural da figura 29 representa o Objeto de Negócio

(utilizado na camada de negócio) que obtém/modifica dados voláteis. A utilização do

DAO é feita para a criação/utilização dos dados, com a finalidade de ao término

dessa alteração 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 conexão com a fonte de dados para obter e armazenar

dados (SUN, 2010).

73

Figura 30 - Diagrama de Sequência – Utilização do DAO em classes persistentes

(Adaptado de: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html,

2010)

O diagrama de sequência da figura 30 representa a comunicação da

camada de negócios e o banco de dados. A finalidade do DAO é prover uma

interface com operações para acesso a dados que abstraiam os detalhes do

mecanismo de persistência.

A camada de negócios ao criar/alterar os dados manipulados pela

interface, comunica-se com o DAO para que o mesmo verifique se os dados

solicitados já são existentes no banco de dados, assim independentes de existirem

são enviados para a memória para que todas as alterações que a camada de

negócio solicitar sejam feitas. Após a confirmação de todas as alterações a camada

74

de negócios envia para o DAO a solicitação para que recupere os dados da

memória e salve novamente em dados não-voláteis (banco de dados).

Em uma aplicação utilizando a arquitetura MVC (Model View

Controller), todas as conexões relacionadas a fontes de dados, são executadas

dentro das classes de DAO que por sua vez não expõe detalhes sobre a forma de

acesso aos dados pela camada de negócio, porém permite a visualização desses

dados.

O quadro 28 expõe um exemplo de DAO utilizado no projeto para

cadastro de artesãos no banco de dados:

//ArtesaoDAO.classpackage 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 criação da classe ArtesaoDAO tem como finalidade expor os

métodos 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();

75

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();


}}

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;


}}

public void update(Artesao art) {session = HibernateUtil.getSessionFactory().openSession();Transaction tx = null;try {

tx = session.beginTransaction();session.update(art);tx.commit();




}}

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();

76




}}

Quadro 29 – Classe ArtesaoHibernateDAO – Manipulação de dados no SGBD

O quadro 29 representa a classe ArtesaoHibernateDAO, responsável

por fazer a alteração de estado dos dados. As alterações de estado são

gerenciadas por transações criadas automaticamente para redução 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 relações entre as entidades.

Figura 31 - Diagrama de Entidade e Relacionamento

77

Na persistência de dados cada entidade do sistema é exposta em uma

classe de aplicação. A classe de aplicação é utilizada como interface entre a

camada de negócio e a camada de persistência.

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 padrão 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 não o caminho para chegar a ele. Ela é uma

linguagem declarativa em oposição 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 conexão ODBC. Os clientes podem

ser executados no Windows ou Unix. O fonte do Connector/ODBC está disponível.

Todas as funções ODBC são 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 aplicações. A criação e

manutenção de bancos de dados são tarefas de uma pessoa ou grupo de pessoas,

normalmente referenciada como o administrador do banco de dados (DBA). A

manipulação do banco de dados, como atualizações e consultas, é realizada direta

ou indiretamente, através de programas aplicativos, pelos usuários do banco de

dados.

A utilização do MySQL como banco de dados para o projeto foi com

base nas seguintes características:

Existência de drivers ODBC, JDBC e .NET e módulos de interface para

78

diversas linguagens de programação.

Portabilidade – Suporte de várias plataformas diferentes.

Desempenho e estabilidade.

Interfaces gráficas de fácil utilização cedidos pela MySQL Inc.

Utilização de pouco recurso de hardware para seu funcionamento.

Facilidade de construção do banco de dados.

É um Software Livre com base na GPL (Licença Pública Geral).

Framework Hibernate

O mapeamento objeto relacional para o sistema de Loja Virtual de

Produtos Artesanais foi feito utilizando um Framework da camada de integração:

Hibernate. É um framework para o mapeamento objeto-relacional escrito na

linguagem Java, também disponível 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 aplicação, mediante o uso de

arquivos (XML) para estabelecer esta relação. O Hibernate é um software livre de

código aberto distribuído com a licença LGPL (Lesser General Public License).

Uma técnica bastante conhecida da orientação a objetos é o

encapsulamento, onde é possível esconder as regras dentro de objetos e definir

alguns métodos nesses objetos que o mundo externo poderá usar para ter acesso

ao resultado dos códigos. Essa idéia foi adaptada à programação com banco de

dados. Os métodos necessários ao acesso e manipulação do banco ficam

escondidos dentro de classes básicas. As outras partes da aplicação usam essas

classes e seus objetos, ou seja, a aplicação 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 também pesquisa e retorno dos

dados, reduzindo o esforço de desenvolvimento para controlar o relacionamento

79

objeto-relacional.

No sistema de Loja Virtual de Produtos Artesanais foi utilizado o

Hibernate Annotations, onde permite utilizar anotações em classes POJO (Plain Old

Java Object). POJO’S são objetos Java que seguem a estrutura de JavaBeans

(construtor padrão sem argumentos e métodos getters e setters para seus

atributos). Com a utilização 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

A figura 32 representa as bibliotecas utilizadas em um projeto

Hibernate.

Hibernate Configuration File: arquivo utilizado para mapear as

configurações de acesso ao SGBD tais como: localização do banco, usuário, senha

e tabelas envolvidas. A seguir pode-se verificar o arquivo Hibernate.cfg.xml,

localizado na pasta src do projeto.

80

<?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 – Configuração de conexão a base de dados

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>

81

Quadro 31 – Hibernate.cfg.xml – Comunicação com o banco de dados

No quadro 31, são exibidas as propriedades para criar conexão com o

banco de dados, onde é parametrizado o Driver utilizado no SGBD, o endereço

onde está localizado o banco de dados, o usuário 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

conexões” em português. Basicamente, é uma camada que fica entre o cliente de

banco de dados, que faz as conexões com o banco, e o próprio banco, utilizando a

propriedade connection.pool_size = 1, permitiremos no máximo uma conexão

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 – Sessão Hibernate

De acordo com o quadro 34, quando criamos uma sessão hibernate

usando qualquer um dos métodos sessionFactory.openSession, será acoplada a

sessão para o contexto atual. O contexto padrão é "thread" o que significa que será

acoplada a sessão para a thread à partir do método openSession.

<property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>

82

Quadro 35 – Hibernate.cfg.xml – Sessão Hibernate

No quadro 35, o cache provider é utilizado para que seja guardado em

cache a consulta feita na sessão, assim sendo utilizada novamente em consultas

posteriores, porém utilizamos a propriedade org.hibernate.cache.NoCacheProvider

para que o hibernate não utilize provedor de cache e cause inconsistências em

consultas dentro da mesma sessão.

<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 saída padrão do terminal da API utilizada, onde useUnicode e characterEncoding

são configurações para representar o texto exibido por um padrão 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 é

possível escolher se o hibernate deverá ser responsável por criar tabelas ou não.

As opções disponíveis são: validate (validar as tabelas), create-drop (cria as tabelas

mas ao encerrar a aplicação as tabelas são removidas), update (atualiza as tabelas

caso seja necessário).

<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" />

83

<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 então dois tipos de classes:

Entidade: São as classes persistentes. Nessa classe encontram-se os

atributos, um construtor, os métodos de acesso getters and setters e as anotações

do Hibernate. Dentre as mais utilizadas estão: @Id, @Column, @Table,

@generatedValue, @Entity.

DAO (Data Access Object): Gerencia a conexão com a fonte de dados

para obter e armazenar dados, são utilizados para persistir as entidades. Através do

HibernateUtil podemos realizar as transações (select, save, update, delete). No

Data Access Object temos os métodos que farão a persistência dos dados.

A utilização do Hibernate torna a aplicação portável para mais de um

tipo de banco de dados, para que com uma simples alteração no framework altere o

SGBD. O Hibernate também expõe as operações básicas de banco de dados para

a aplicação, como recuperação de dados, inserção, exclusão ou alteração. Um

ponto importante para a utilização do Framework Hibernate é a orientação a objetos

utilizando integração com banco de dados.

84

5 CONCLUSÕES

O contato com o cliente para apuração de suas dificuldades nos

mostrou uma excelente oportunidade de aplicar o conhecimento adquirido durante o

curso, além de podermos utilizar as diversas ferramentas trabalhadas para o

desenvolvimento desse projeto.

A utilização 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 organização e suas intenções do produto

final. A diagramação do projeto possibilitou uma excelente visão para o

desenvolvimento, facilitando o trabalho, comunicação e eficiência de todos os

membros responsáveis pelo desenvolvimento desse projeto.

Utilizando a ferramenta Enterprise Architect, descobrimos uma

maneira extremamente simples de suprir nossas necessidades quanto à aplicação

do UML e propiciou agilidade na realização dos esboços iniciais do projeto tanto

como nos diagramas conclusivos do negócio.

Com a utilização da linguagem de programação Java, que provê toda

a facilidade de uma linguagem orientada a objetos, desenvolvemos uma solução

que está atual no mercado, utilizando dos melhores recursos tecnológicos

disponíveis, como a ferramenta de desenvolvimento Eclipse e frameworks, o que

reduziu drasticamente o tempo empenhado na construção do produto desejado e

até mesmo em manutenções que o software pode vir a receber.

Através do uso da arquitetura MVC, que possibilita a divisão do

software em camadas, o entendimento para a criação do sistema tornou-se mais

claro, possibilitando um trabalho padronizado, o que deixa o produto final com uma

consistência maior e possibilita que uma atualização futura seja realizada de

maneira mais prática e rápida. Sendo assim, o MVC contribuiu para que ocorresse a

separação entre os dados do sistema e a apresentação das aplicações. Os dados

ficam independentes da camada de interface, alterações em uma camada não

85

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 série de Servlets, que dificultaria muito a implementação e

manutenção do sistema.

Pelo uso dos padrões de projeto foi reforçada a importância da divisão

em camadas, onde fizemos o controle das ações com o Front Controller através do

Struts2. As regras de negócio por sua vez foram separadas do restante da

aplicação através das classes BO (Business Object). As classes DAO que se

utilizaram do framework Hibernate3 foram responsáveis por todos os tipos de

interação com os dados, facilitando assim com que os desenvolvedores

visualizassem as interações com o banco MySQL, que atendeu perfeitamente as

nossas necessidades, comportando-se de maneira simples, de fácil utilização e sem

complicar o desenvolvimento do produto.

Tendo o projeto parcialmente desenvolvido, entendemos que é

possível desenvolver um comercio eletrônico com todas as tecnologias

demonstradas aqui e utilizando os conceitos aprendidos no decorrer do curso de

forma profissional. Observando o crescimento da divulgação do trabalho dos

artesãos e de seus produtos, o software poderá ser continuado e possivelmente

aplicado a fins comerciais, se tornado um produto rentável, de boa qualidade e

preparado para o mercado atual e futuro.

86

REFERÊNCIAS BIBLIOGRÁFICAS

ALUR, Deepak; Crupi, John; Malks Dan; Core J2EE Patterns: as melhores práticas e estratégias de design. Tradução Alair Dias Caldas de Morais. 2.ed. Rio de Janeiro: Elsevier Campus, 2004. 587p.

BAUER, Christian.; King, Gavin ; Hibernate em ação. Tradução Cláudio Rodrigues Pistilli, Geane Girotto e Fabio Makoto. Rio de Janeiro: Ciência Moderna, 2005. 532p.

BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. Rio de Janeiro Elsevier, 2002. 286p.

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: Guia do Usuário. Tradução de Fábio Freitas da Silva. Rio de Janeiro: Campus, 2000. 472 p.

DEITEL, Harvey. Java como programar. Tradução Edson Furmankiewicz Revisão Técnica Fábio Lucchini. 6 ed. São Paulo: Person Education, 2006.

DEITEL, Harvey. Java como programar. Tradução Edson Furmankiewicz. 3ed. São Paulo: Person Education, 2001. 1199p

GUEDES, Gilleanes. UML 2 – Guia da Consulta Rápida. 2.ed. São 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. Tradução Rosângela Delloso Penteado. 6 ed. São Paulo: McGraw-Hill, 2006. 720p.

SOMMERVILLE, Ian. Engenharia de Software. Tradução André Maurício de Andrade Ribeiro. 6 ed. São Paulo: Addison Wesley, 2003. 592p.

TODD, Nick; Mark Szolkowski. Java Server Pages – O Guia do Desenvolvedor. Tradução Edson Furmankiewicz. Rio de Janeiro: Elsevier, 2003. 621p.

WAZLAWICK, Raul Sidnei. Analise e projeto de sistemas de informação orientados a objeto. Rio de Janeiro: Elsevier, 2004. 298p.

87

ANEXO A- DADOS IMPORTANTES

CÓDIGO FONTE DO PROGRAMA

//arquivo struts.xml: mapeamento das ações a serem utilizadas nas páginas 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>

88

</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">

<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">

89

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



90

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

91

tcc - sistemas de informação

Documents