Coisas de Criança - Relatório 4 Período

FACULDADE PITÁGORAS DE UBERLÂNDIA
Autorizada pela Portaria no 577/2000 – MEC, de 03/05/2000

BACHARELADO EM SISTEMAS DE INFORMAÇÃO
LOJA COISAS DE CRIANÇA LTDA
ANDRÉ BORSATTI
BRUNO ALVARES DEFENSOR
GABRIEL ARAÚJO GARCIA
MARCOS GUIMARÃES DE MEDEIROS
PAULO HENRIQUE TAVARES
VICTOR HUGO DE OLIVEIRA E SILVA
Uberlândia
2010/1
ANDRÉ BORSATTI
BRUNO ALVARES DEFENSOR
GABRIEL ARAÚJO GARCIA
MARCOS GUIMARÃES DE MEDEIROS
PAULO HENRIQUE TAVARES
VICTOR HUGO DE OLIVEIRA E SILVA
LOJA COISAS DE CRIANÇA LTDA
Relatório Parcial submetido ao curso de

Sistemas de Informação da PITÁGORAS,
como parte dos requisitos para avaliação
do Projeto Interdisciplinar Horizontal
relativo ao 1º semestre de 2010.
Orientador: Prof. Msc. Edson Angoti Júnior
Banca Examinadora:
Uberlândia Junho de 2010.
Prof. Msc. Francisco Muller

Profa. Dra. Kátia L. Silva
Uberlândia
2010/1
DEDICATÓRIA
Dedicamos este trabalho primeiramente a

Deus, pois sem ele nada seria possível.
Aos nossos pais, professores e colegas pelo

esforço, dedicação e, compreensão em todos
os momentos.
A todos àqueles que acreditam que a ousadia

e o erro são caminhos para as grandes
realizações.
RESUMO
O objetivo deste documento é a modelagem do sistema para gerência de vendas,

devoluções e emissão de relatórios para a loja Coisas de Criança LTDA, nossa
parceira que proporcionou a estrutura de negócio necessária para o
desenvolvimento do projeto. A partir de reuniões do grupo com a representante da
empresa, foi possível identificar as reais necessidades da loja e dar inicio a
modelagem do aplicativo a ser desenvolvido, que será aqui apresentada.
Utilizando dos padrões da linguagem UML (Unified Modeling Language) para
desenvolvimento de sistemas, foi possível criar os diagramas propostos e
necessários relacionados ao projeto (o qual será desenvolvido em etapas) e, a cada
etapa, um novo fragmento do software será implementado, testado, revisado e
apresentado à banca de avaliação.
Usando como guia este documento utilizará o padrão de arquitetura de software
MVC (Model View Controller) que visa separar a lógica da aplicação (Model), da
interface do usuário (View) e do fluxo da aplicação (Controller). O Model será
desenvolvido em linguagem de programação Java enquanto a View esta sendo
desenvolvido em JSP e o Controller será feito por um HttpServlet, implementado
com o uso do Eclipse e dos frameworks Struts e Hibernate. O mapeamento objeto
relacional foi realizado pelo JDBC juntamente com a utilização do framewok
Hibernate. Para o acesso ao banco de dados foi empregado o padrão de projeto
DAO, configurado para se conectar ao MySQL, o SGBD escolhido para a
persistência dos dados. O servidor web selecionado foi o TomCat, que implementa
as especificações servlet e JSP.
Com o bom uso deste documento, é possível desenvolver o aplicativo que possa
suprir todas as exigências do cliente e, como resultado, o produto final capaz de
agilizar e personalizar o processo de vendas de mercadorias da empresa além de
auxiliar na gerência das despesas da loja a partir da emissão de relatórios.
Palavras chave: Unified Modeling Language, Model View Controller, HttpServlet,

Data Access Object.
Lista de Figuras
Página
Figura 1 – Diagrama de casos de uso....................................................................................19

Figura 2 – Diagrama de classes de negócio..........................................................................33
Figura 3– Diagrama de sequência – Realizar Login.............................................................36
Figura 4 – Diagrama de sequência – Cadastrar Cliente.......................................................37
Figura 5– Diagrama de sequência – Cadastrar Funcionário................................................38
Figura 6 – Diagrama de sequência – Cadastrar Fornecedor................................................39
Figura 7 – Diagrama de sequência – Cadastrar Mercadoria................................................40
Figura 8 – Diagrama de sequência – Cadastrar Valor da Comissão....................................41
Figura 9 – Diagrama de entidade e relacionamento – DER..................................................43
Figura 10 – Arquivo "hibernate.cfg.xml" .............................................................................45
Figura 11 – Classe de entidade Produto................................................................................46
Figura 12 – Diagrama de estado de navegação.....................................................................49
Figura 13 – Arquitetura MVC................................................................................................51
Figura 14– Arquitetura Framework Struts 2..........................................................................53
Figura 15– Diagrama de classe.............................................................................................57
Figura 16 – Diagrama de classe de projeto por caso de uso implementado........................58
Figura 17– Diagrama de Pacotes..........................................................................................59
Lista de Quadros
Página
Quadro 1 – Tabela de documentação da regra de negócio RN-01........................................17

Quadro 2 – Tabela de documentação da regra de negócio RN-02.......................................17
Quadro 3 - Tabela de documentação da regra de negócio RN-03........................................17
Quadro 6 – Tabela de documentação do caso de uso – Cadastrar Cliente...........................20
Quadro 7 – Tabela de documentação do caso de uso – Cadastrar Funcionário...................21
Quadro 8 – Tabela de documentação do caso de uso – Cadastrar Fornecedor....................22
Quadro 9 – Tabela de documentação do caso de uso – Cadastrar Mercadoria....................23
Quadro 10 – Tabela de documentação do caso de uso – Cadastrar Valor da comissão.......24
Quadro 11 – Tabela de documentação do caso de uso – Efetuar venda................................25
Quadro 12 – Tabela de documentação do caso de uso – Efetuar venda condicional............26
Quadro 13 – Tabela de documentação do caso de uso – Realizar devolução de mercadoria28
Quadro 14 – Tabela de documentação do caso de uso – Realizar login...............................29
Quadro 15 – Tabela de documentação do caso de uso – Emitir relatórios...........................30
Quadro 16 – Tabela de documentação do caso de uso – Atualizar estoque..........................31
LISTA DE ABREVIATURAS
UML (Unified Modeling Language): é uma linguagem de modelagem que permite

aos desenvolvedores visualizem os produtos de seus trabalhos em diagramas
padronizados.não proprietária de terceira geração. A UML não é uma metodologia de
desenvolvimento, o que significa que ela não diz a você o que fazer primeiro e em
seguida ou como projetar seu sistema, mas sim auxilia a visualizar seu desenho e a
comunicação entre objetos.
JSP (JavaServer Pages): é uma tecnologia utilizada no desenvolvimento de

aplicações para Web. Por ser baseada na linguagem de programação Java, tem a
vantagem da portabilidade de plataforma, que permite a sua execução em diversos
sistemas operacionais. Esta tecnologia permite ao desenvolvedor de páginas para
Internet produzir aplicações que acessem o banco de dados, manipulem arquivos no
formato texto, capturem informações a partir de formulários e captem informações
sobre o visitante e sobre o servidor. Uma página criada com a tecnologia JSP,
depois de instalada em um servidor de aplicação compatível com a tecnologia Java EE,
é transformada em um Servlet.
CSS (Cascading Style Sheets): é uma linguagem de estilo utilizada para definir a
apresentação de documentos escritos em uma linguagem de marcação, como
HTML ou XML. Seu principal benefício é prover a separação entre o formato e o
conteúdo de um documento. Ao invés de colocar a formatação dentro do
documento, o desenvolvedor cria um link para uma página que contém os estilos,
procedendo de forma idêntica para todas as páginas de um portal. Quando quiser
alterar a aparência do portal basta portanto modificar apenas um arquivo.
HTML: é um acrônimo para a expressão inglesa HyperText Markup Language, que no

português pode ser entendido como Linguagem de Marcação de Hipertexto. O
HTML é uma linguagem de marcação utilizada para produzir páginas na Web.
Documentos HTML podem ser interpretados por navegadores.
XML (Extensible Markup Language): subtipo de SGML (acrônimo de Standard

Generalized Markup Language, ou Linguagem Padronizada de Marcação Genérica)
capaz de descrever diversos tipos de dados. Seu propósito principal é a facilidade
de compartilhamento de informações através da Internet.
MVC (Model-view-controller): é um padrão de arquitetura de software responsável

pela separação das tarefas de acesso aos dados e lógica de negócio, lógica de
apresentação e de interação com o usuário, introduzindo um componente entre os
dois, que é o Controller. Com o aumento da complexidade das aplicações
desenvolvidas torna-se fundamental a separação entre os dados (Model) e o layout
(View). Desta forma, alterações feitas no layout não afetam a manipulação de dados,
e estes poderão ser reorganizados sem alterar o layout.
EJB ( Enterprise JavaBeans): é um dos principais componentes da plataforma

J2EE (Java 2 Enterprise Edition). É um componente do tipo servidor que executa no
container do servidor de aplicação. O principal objetivo da tecnologia EJB são fornecer
um rápido e simplificado desenvolvimento de aplicações Java baseado em
componentes distribuídas, transacionais, seguras e portáveis.
SGBD (Sistema Gerenciador de Banco de Dados): conjunto de programas de
computador (softwares) responsáveis pelo gerenciamento de uma base de dados. O
principal objetivo é retirar da aplicação cliente a responsabilidade de gerenciar o
acesso, manipulação e organização dos dados. O SGBD disponibiliza uma interface
para que os seus clientes possam incluir, alterar ou consultar dados. Em bancos de
dados relacionais a interface é constituída pelas APIs ou drivers do SGBD, que
executam comandos na linguagem SQL.
JDBC (Java Database Connectivity): conjunto de classes e interfaces (API)
escritas em Java que fazem o envio de instruções SQL para qualquer banco de dados
relacional
API (Application Programming Interface): conjunto de rotinas e padrões

estabelecidos por um software para a utilização das suas funcionalidades por
programas aplicativos que não querem envolver-se em detalhes da implementação do
software, mas apenas usar seus serviços. De modo geral, a API é composta por
uma série de funções acessíveis somente por programação, e que permitem utilizar
características do software menos evidentes ao utilizador tradicional.
WEB (World Wide Web): é um sistema de documentos em hipermídia que são

interligados e executados na Internet.
LTDA: abreviatura de limitada.
CEP (Código de Endereçamento Postal): é um código desenvolvido pelas

administrações postais e criado no sentido de facilitar o encaminhamento e a
entrega das correspondências. Cada administração postal é livre de criar o código
que melhor se adapte à realidade postal e administrativa do seu país.
UF: abreviatura de Unidade da Federação.
CNPJ (Cadastro Nacional da Pessoa Jurídica): é um número único que identifica

uma pessoa jurídica junto à Receita Federal brasileira (órgão do Ministério da
Fazenda), necessário para que a pessoa jurídica tenha capacidade de fazer contratos e
processar ou ser processada. O CNPJ veio substituir o CGC, Cadastro Geral de
Contribuintes e por vezes também é grafado como CNPJ-MF.
IE (Inscrição Estadual): é o registro do contribuinte no cadastro do ICMS mantido
pela Receita Estadual. Com a inscrição, o contribuinte do ICMS passa a ter o registro
formal do seu negócio, junto à Receita Estadual do estado onde está estabelecido.
SUMÁRIO
1INTRODUÇÃO .................................................................................................................................13
1.1FINALIDADE......................................................................................................................................13
1.2ESCOPO.........................................................................................................................................13
2 ESPECIFICAÇÃO DO PROBLEMA.................................................................................................13
2.1DESCRIÇÃO DO NEGÓCIO E DA EMPRESA.................................................................................................13
2.2ESPECIFICAÇÃO DE REQUISITOS.............................................................................................................14
2.2.1Requisitos não funcionais....................................................................................................17
2.3REGRAS DE NEGÓCIO.........................................................................................................................18
3ANÁLISE DO SISTEMA.....................................................................................................................19
3.1INTRODUÇÃO....................................................................................................................................19
3.2FERRAMENTA DE MODELAGEM...............................................................................................................20
3.3DIAGRAMA DE CASOS DE USO.............................................................................................................20
3.4DESCRIÇÃO DOS CASOS DE USO E ATORES............................................................................................21
3.4.1Descrição dos Casos de Uso...............................................................................................21
CADASTRAR FUNCIONÁRIO.............................................................................................................22
CADASTRAR FORNECEDOR............................................................................................................23
CADASTRAR MERCADORIA.............................................................................................................24
CADASTRAR VALOR DA COMISSÃO...............................................................................................25
EFETUAR VENDA...............................................................................................................................26
EFETUAR VENDA CONDICIONAL.....................................................................................................28
REALIZAR DEVOLUÇÃO DE MERCADORIA....................................................................................29
FLUXO ALTERNATIVO [3]: CANCELAMENTO...................................................................................................29
REALIZAR LOGIN...............................................................................................................................30
FLUXO ALTERNATIVO [3]: CANCELAMENTO..................................................................................................30
EMITIR RELATÓRIOS.........................................................................................................................31
ATUALIZAR ESTOQUE.......................................................................................................................32
3.4.2Descrição dos Atores...........................................................................................................33
3.5CLASSES DE ANÁLISE.........................................................................................................................34
3.6DIAGRAMA DE CLASSES DE NEGÓCIO.....................................................................................................34
3.6.1Classes de Fronteira (o bruno já fez)...................................................................................35
3.6.2Classe Controladora............................................................................................................36
3.6.3Classe de Entidade..............................................................................................................37
3.7DIAGRAMA DE SEQUÊNCIA...................................................................................................................38
4PERSISTÊNCIA DE DADOS.............................................................................................................43
4.1.1Introdução............................................................................................................................44
4.2PADRÃO DE PROJETO DAO................................................................................................................44
4.3DIAGRAMA DE ENTIDADE E RELACIONAMENTO..........................................................................................44
4.4MAPEAMENTO OBJETO RELACIONAL......................................................................................................45
4.4.1Acesso a banco de dados com JDBC..................................................................................46
4.4.2Mapeamento Objeto Relacional usando o Hibernate..........................................................46
5PROJETO DE INTERFACE...............................................................................................................49
5.1INTRODUÇÃO....................................................................................................................................49
5.2TECNOLOGIAS UTILIZADAS....................................................................................................................49
5.3DIAGRAMA DE ESTADOS DE NAVEGAÇÃO .................................................................................................51
6ARQUITETURA E CÓDIGO...............................................................................................................52
6.1INTRODUÇÃO....................................................................................................................................52
6.2APLICAÇÃO EM CAMADAS....................................................................................................................52
6.3MODELO MVC................................................................................................................................53
6.3.1Arquitetura MVC..................................................................................................................53
6.3.2Arquitetura Struts.................................................................................................................56
6.4PADRÕES DE PROJETO DA CAMADA DE APRESENTAÇÃO.............................................................................57
6.5PADRÕES DE PROJETO DA CAMADA DE NEGÓCIO.....................................................................................58
6.6PADRÕES DE PROJETO DA CAMADA DE INTERFACE....................................................................................58
6.7-DIAGRAMA DE CLASSES DE PROJETO...................................................................................................61
6.7.1-Diagrama de Classes de Projeto por Caso de Uso Implementado....................................62
.....................................................................................................................................................62
6.7.2-Diagrama de Pacotes.........................................................................................................62
REFERÊNCIAS BIBLIOGRÁFICAS....................................................................................................63
APÊNDICE ..........................................................................................................................................64
13
14
A visão da loja Coisas de Criança é buscar um crescimento relevante e

ser referência para todo o triângulo no setor de moda infantil, buscando sempre
melhorias nos processos e se diferenciando pela qualidade dos produtos vendidos e
pela satisfação dos seus clientes. A empresa pretende, até 2015, atingir estas
conquista.
A missão da empresa e garantir a satisfação total de seus clientes, pais
e filhos de modo que percebam não apenas a qualidade dos produtos mas também
a do atendimento, fazendo com que sejam cultivados vínculos fortes e saudáveis
com a empresa.
O negócio da Coisas de Criança Ltda. é bem definido e transparente.
Trabalhar exclusivamente com o público infantil com artigos de qualidade no setor
de varejo.
Hoje com a nova direção, a loja está em busca de constante
modernização e inovação no setor, pretendendo até o início de 2010 informatizar
toda a loja, permitindo assim um melhor aproveitamento do cadastro de seus cliente,
podendo enxergar suas preferências e estreitando ainda mais o vínculo com estes.
Busca também com esta informatização um cadastro de todos os seus
fornecedores, para um melhor controle dos mesmos e com mais opções de
negociações , cruzando informações de preferência de seus clientes com o que os
fornecedores tem a oferecer, garantindo a loja produtos personalizados de acordo
com cada cliente.
A empresa tem orgulho de suas origens e sua história, orgulho de ser
mineira e brasileira, orgulho de há mais de 26 anos trabalhar para um público
especifico e de se destacar neste mercado, hoje é uma loja sólida e madura no
mercado infantil e busca com a nova administração a inovação e melhoria constante
em seus processo, podendo dizer com certeza que cumpre com as obrigações com
seus clientes garantindo aos mesmo satisfação e confiança na prestação de
serviços.
Devido a isso que a Coisas de Criança Ltda. é hoje em Uberlândia
referência no setor de vestuário infantil.
2.2 Especificação de requisitos

15
Cadastro de clientes: O sistema deve permitir ao funcionário

cadastrar um cliente. Será apresentado um formulário para os dados dos clientes
(inserção do nome do pai ou responsável, contato, endereço, número, CEP,
complemento, bairro, cidade e UF) e também um módulo para cadastrar as crianças
dependentes deste adulto (através do nome da criança, aniversário, sexo, idade e
numeração de vestimenta). Depois de preenchidos os campos obrigatórios e
confirmado o cadastro, o cliente é registrado na base do banco de dados e o sistema
redireciona para a página principal.
Cadastro de fornecedores: O sistema deve permitir ao funcionário

cadastrar um fornecedor. Será apresentado um formulário para os dados dos
fornecedores (CNPJ, IE, nome fantasia, endereço, número, CEP, complemento,
bairro, cidade, UF, contato e marcas da empresa). Depois de preenchidos os
campos obrigatórios e confirmado o cadastro, o fornecedor é registrado na base do
banco de dados e o sistema redireciona para a página principal.
Cadastro de funcionários: O sistema deve permitir ao funcionário

cadastrar um funcionário. Será apresentado um formulário para os dados dos
fornecedores (CPF, CTPS, telefone, endereço, número, CEP, complemento, bairro,
cidade, UF e data da admissão). Depois de preenchidos os campos obrigatórios e
confirmado o cadastro o fornecedor é registrado na base do banco de dados e o
sistema redireciona para a página principal.
Cadastro de mercadorias: O sistema deve permitir ao funcionário

cadastrar produtos. Será apresentado um formulário para os atributos do produto
(código, tamanho, sexo, e quantidade). Depois de preenchidos os campos
obrigatórios e confirmado o cadastro, a mercadoria é registrada na base do banco
de dados e o sistema redireciona para a página principal.
Identificação do usuário: O sistema deve permitir a identificação do

usuário. Será apresentada a interface de login com os requisitos de usuário e
senha. O usuário pode ser administrador e funcionário, sendo que, o administrador
16
possui alguns privilégios em relação ao funcionário. Com o usuário logado, o

sistema apresenta a interface principal de vendas.
Registro da transação de venda: O sistema deve permitir ao

funcionário realizar o registro de venda da mercadoria e deverá manter um registro
de todas as vendas pela loja. Este registro terá o código da mercadoria, valor de
venda, tipo de pagamento e o cliente que efetuou a compra. O funcionário conclui a
venda e é atualizada a base do banco de dados.
Registro de compra condicional: O sistema deve permitir ao

funcionário realizar o registro de mercadoria em condicional para os clientes que
possuem direito a tal, gerando um documento de responsabilidade para o cliente
assinar e ao final do período estipulado efetivar a venda ou devolução da mercadoria
a loja.
Devolução de mercadorias: O sistema deve permitir ao funcionário

realizar devolução das mercadorias desejadas. O funcionário informa ao sistema a
mercadoria que será devolvida e a base do banco de dados é atualizada.
Controle de comissões de vendas: Define a comissão de venda

referente ao funcionário durante o período estipulado. Para cada funcionário será
previamente cadastrado um percentual padrão de comissão como também a meta
do período. Esse percentual poderá ser alterado de acordo com as definições do
gestor da loja, o qual terá permissões para tal. A cada venda realizada pelo
funcionário é armazenada a comissão do mesmo.
Controle financeiro: O sistema deve permitir ao funcionário realizar o

controle financeiro da loja. Será gerado um formulário para o cadastro de despesas
fixas (água, energia, salários de empregados, etc.), mensais (funcionários, contador,
investimentos, etc.) e contas a receber.
São cadastradas as despesas e o sistema gerará todo controle destas.
17
Geração de relatórios: O sistema deve possibilitar a geração de

relatórios de todas as transações da empresa.
Comissões: Por funcionário;
Vendas: Por funcionário;

Por tipo de roupa;
Por roupa mais vendida;
Por clientes;
Por clientes que mais compraram.
Financeiro: Contas a receber ou a pagar por período;

Despesas fixas;
Despesas mensais;
Balanço mensal ou por período (relação de contas
pagas e recebidas).
Funcionário: Dados cadastrais dos funcionários;

Funcionário por tipo.
O Administrador seleciona o tipo de relatório a ser gerado, o sistema emite o

relatório com as informações do determinado tipo de relatório e retorna para a
pagina principal.
2.2.1 Requisitos não funcionais
O sistema deverá ser desenvolvido em Linguagem JAVA: O sistema

será implementado utilizando linguagem de programação Java por ser uma
linguagem moderna e orientada a objetos e pela facilidade de se encontrar material
de apoio.
18
O sistema deverá utilizar o SGBD My SQL: O sistema deverá contem

o SGBD MySQL para guardar as informações que serão armazenadas do sistema e
deverá operar em ambiente WEB.
O sistema deverá permitir o uso de leitor de código de barras. Deve

conter um leitor de código de barras para facilitar o cadastro de mercadorias e
realizar vendas.
O sistema deverá ter controle de acesso com níveis de restrição aos

usuários: O aplicativo terá acesso para administrador e para funcionários, no qual
o acesso para o administrador contém algumas funcionalidades extras.
2.3 Regras de negócio
As regras de negócio dizem respeito às operações, definições e

restrições de uma organização para alcançar seus objetivos. São usadas para
alcançar os objetivos de uma empresa, a comunicação entre ela e terceiros e,
também, demonstrar as obrigações legais. A regra de negócio se aplica diretamente
ao desenvolvimento de determinada plataforma de software voltada para um sistema
de informação.
Nome Pagamento com cheque RN- 01

Um cliente só poderá efetuar pagamento com cheque, caso não possua
restrições de credito no SPC.
Descrição
Quadro 1-Tabela de documentação de regra de negócio RN-01
Nome Compra condicional RN- 02

19
Um cliente só poderá efetuar compra em condicional, com aprovação previa da

gerente da loja.
Descrição
Quadro 2 - Tabela de documentação de regra de negócio RN-02
Nome Compra de mercadoria RN- 03

Fornecedores serão cadastrados no sistema se possuírem marcas conhecida e
de qualidade.
Descrição
Quadro 3- Tabela de documentação de regra de negócio RN-03
Nome Devoluções de Mercadoria RN- 04

Devoluções para serem aceitas devem atender os seguintes requisitos:
Estar dentro do prazo de seis dias decorridos da data de compra;
Descrição
Apresentação do cupom de venda;
A roupa deve apresentar a etiqueta da loja;
Quadro 4- Tabela de documentação de regra de negócio RN -04
Nome Cheque Devolvido RN- 05

Cliente que tiver algum cheque devolvido só poderá comprar a vista ou no
Descrição cartão.
Quadro 5- Tabela de documentação de regra de negócio RN-05
3 ANÁLISE DO SISTEMA
3.1 Introdução
A coleção de notações, metodologias e ferramentas usadas para reunir

detalhes, analisar um problema prévio para o projeto e a implementação do sistema
de informação é conhecida como Análise de Sistemas de Informação.
20
A análise de sistemas deve garantir que o sistema de informação

proposto atenda às necessidades do usuário, seja entregue no tempo e possa ser
atualizado sem muitas despesas. Enfatiza a investigação do problema e a proposta
de solução que atenda os requisitos de análise.
O uso de modelos é importante para padronizar o desenvolvimento dos
sistemas. Estes devem ser utilizados como base na implementação do programa a
fim de proporcionar a melhor conduta em desenvolvimento de sistemas e atingir o
objetivo final que é o produto desenvolvido de acordo com as especificações do
cliente e o mesmo satisfeito com os resultados.
3.2 Ferramenta de modelagem
As ferramentas de modelagem são um importante recurso na criação

dos modelos para a implementação do projeto e interferem diretamente na
qualidade do produto final.
Para softwares desenvolvidos a partir do paradigma da programação
orientada a objeto, a linguagem gráfica mais utilizada é a UML(Linguagem de
Modelagem Unificada), que por meio dos seus diagramas é possível representar
sistemas de software sob diversas perspectivas de visualização, facilitando assim a
comunicação de todas as pessoas e objetos envolvidos no processo de
desenvolvimento de um sistema.
3.3 Diagrama de Casos de Uso

21
uc P G I
C o i sa s d e C ri a n ç a
R e a liz a r L o g in C a d a s tr a r
F u n c i o n a r io
E fe tu a r V e n d a
C a d a s tr a r
Fo rne c e do r
R e g i s tr a r V e n d a« i n c l u d e »
C o n d ic io n a l
C a d a s tr a r
F u n c io n a rio M e r c a d o ria
« in clu d e »
A tu a l i z a r E s to q u e A d m i n i s tr a d o r
« in clu d e »
R e a liz a r D e v o lu ç ã o
d e M e rc a d o ria
C a d a s tr a r V a l o r d a
C o m is s ã o
A d m i n i s tr a d o r C a d a s tr a r C l i e n te s
E m i tir R e l a to r i o s
Figura 1: Diagrama de Caso de uso
3.4 Descrição dos Casos de Uso e Atores
3.4.1 Descrição dos Casos de Uso
Nome Cadastrar Cliente CSU-01

Sumário O caso de uso descreve as etapas para cadastro de cliente.
22
Ator primário: Funcionário

Pré-condição: O funcionário deve estar logado no sistema.
Pós-condição: O cadastro do cliente é efetuado com sucesso.
Fluxo Principal
1. O funcionário seleciona a opção “Cadastrar Cliente”.

2. O sistema apresenta as opções do tipo de cliente (Físico ou Jurídico).
3. O funcionário seleciona a opção desejada.
4. O sistema solicita os dados referentes ao cliente.
5. O funcionário informa os dados solicitados.
6. O sistema valida os dados informados e solicita confirmação.
7. O funcionário confirma os dados.
8. O sistema registra os dados e emite uma mensagem de cadastro concluído com
sucesso
9. O caso de uso é encerrado.
Fluxo Alternativo [3]: Cancelamento
3.1. O usuário seleciona a opção para cancelar o cadastro.

3.2. O caso de uso é encerrado.
Fluxo de Exceção [6]: Erro de Validação
6.1. O sistema acusa algum erro de validação nos dados informados.

6.2. O caso de uso retorna ao passo 5.
Regras de Negócio Associadas

Não há regras de negócio
Quadro 6 - Tabela de documentação de caso de uso - Cadastrar Cliente
Nome Cadastrar Funcionário CSU-02

Sumário O caso de uso descreve as etapas para cadastro de funcionário.
Ator primário: Administrador.

Pré-condição: O administrador deve estar logado no sistema.
Pós-condição: O cadastro do funcionário é efetuado com sucesso.
Fluxo Principal
23
1. O administrador seleciona a opção “Cadastrar Funcionário”.

2. O sistema solicita os dados referentes ao funcionário.
3. O administrador informa os dados solicitados.
5. O administrador confirma os dados.
sucesso.
3.1. O administrador seleciona a opção para cancelar o cadastro.

Fluxo de Exceção [4]: Erro de validação

Quadro 7- Tabela de documentação de caso de uso - Cadastrar Funcionário
Nome Cadastrar Fornecedor CSU-03

Sumário O caso de uso descreve as etapas para cadastro de fornecedor.

Pós-condição: O cadastro do fornecedor é efetuado com sucesso.
Fluxo Principal
24
1. O administrador seleciona a opção “Cadastrar Fornecedor”.

2. O sistema solicita os dados referentes ao fornecedor.
sucesso.



Quadro 8- Tabela de documentação de caso de uso - Cadastrar fornecedor
Nome Cadastrar Mercadoria CSU-04

Sumário O caso de uso descreve as etapas para cadastro de fornecedor.

Pós-condição: O cadastro da mercadoria é efetuado com sucesso.
25
Fluxo Principal
1. O administrador seleciona a opção “Cadastrar Mercadoria”.

2. O sistema solicita os dados referentes à mercadoria.
sucesso.



Quadro 9- Tabela de documentação de caso de uso - Cadastrar mercadoria
Nome Cadastrar Valor da Comissão CSU-05

Sumário O caso de uso descreve as etapas para cadastro do valor de comissão.

26
Pós-condição: O cadastro do valor da comissão é efetuado com sucesso.

Fluxo Principal
1. O administrador seleciona a opção “Cadastrar Valor da Comissão”.

2. O sistema solicita os dados referentes ao valor da comissão.
sucesso.



Quadro 10- Tabela de documentação de caso de uso - Cadastrar valor da comissão
Nome Efetuar Venda CSU-06

O caso de uso descreve o processo de registro da transação de venda.
Sumário

Pós-condição: O registro de venda é efetuado com sucesso.
Fluxo Principal
27
1. O funcionário seleciona a opção “Registrar Transação de Venda”.

2. O sistema solicita os dados referentes ao produto.
4. O sistema apresenta os dados do produto e solicita confirmação.
8. O sistema apresenta os dados do cliente e solicita confirmação.
9. O funcionário confirma os dados
10. O sistema solicita os dados referentes à transação de venda.
14. O sistema armazena as informações e exibe uma mensagem de transação
concluída com sucesso.
13.1. O funcionário seleciona a opção para cancelar a confirmação de dados da

transação de venda.


Quadro 11- Tabela de documentação de caso de uso - Efetuar venda
28
Nome Efetuar Venda Condicional CSU-07

O caso de uso descreve o processo para efetuar venda condicional.
Sumário

Pós-condição: O registro de venda condicional é efetuado com sucesso.
Fluxo Principal
1. O funcionário seleciona a opção “Registrar Venda Condicional”.

2. O sistema solicita os dados referentes ao produto.
4. O sistema apresenta os dados do produto e solicita confirmação.
8. O sistema apresenta os dados do cliente e solicita confirmação.
9. O funcionário confirma os dados
10. O sistema valida os dados informados, os apresenta e solicita confirmação.
12. O sistema armazena as informações e exibe uma mensagem de transação
concluída com sucesso.
3.1. O funcionário seleciona a opção para cancelar a confirmação de dados do produto.

9.1. O funcionário seleciona a opção para cancelar a confirmação de dados do cliente.
11.1. O funcionário seleciona a opção para cancelar a confirmação de dados
informados.
29

10.2. O caso de uso retorna ao passo referente ao formulário que foi preenchido de
forma incorreta (passo 3 ou passo 6).
RN-02
Quadro 12- Tabela de documentação de caso de uso - Efetuar venda condicional
Nome Realizar Devolução de Mercadoria CSU-08

Sumário O caso de uso descreve o processo de devolução de mercadoria

Pós-condição: A devolução da mercadoria é efetuada com sucesso.
Fluxo Principal
1. O funcionário seleciona a opção “Realizar Devolução de Mercadoria”.

2. O sistema solicita os dados referentes à mercadoria.
6. O sistema armazena as informações e exibe uma mensagem de sucesso
3.1. O funcionário seleciona a opção para cancelar a confirmação de dados do

produto.
5.1. O funcionário seleciona a opção para cancelar confirmação de dados
30


RN-04
Quadro 13- Tabela de documentação de caso de uso - Realizar devolução de mercadoria
Nome Realizar Login CSU-09

Sumário O caso de uso descreve o processo de login no sistema.
Ator primário: Administrador

Ator secundário: Funcionário
Pré-condição: O usuário deve estar cadastrado no sistema.
Pós-condição: Usuário logado no sistema
Fluxo Principal
1. O usuário seleciona a opção para login.

2. O sistema apresenta a interface para login e solicita usuário e senha.
3. O usuário informa os dados solicitados.
4. O sistema valida o nome de usuário e a senha.
5. O sistema apresenta a interface principal do programa.
3.1. O usuário seleciona a opção para cancelar login.


31

Quadro 14- Tabela de documentação de caso de uso - Realizar Login
Nome Emitir Relatórios CSU-10

Sumário O caso de uso descreve o processo de emissão de relatórios.

Pré-condição: O usuário deve estar logado no sistema.
Pós-condição: O relatório escolhido deve ser emitido.
Fluxo Principal
32
1. O administrador seleciona a opção para emissão de relatórios.

2. O sistema apresenta as opções de relatórios possíveis a serem emitidos.
3. O administrador seleciona a opção que deseja.
4. O sistema apresenta uma janela solicitando nome de usuário e senha.
6. O sistema valida os dados informados.
7. O sistema emite o relatório desejado.
3.1. O administrador seleciona a opção para cancelar emissão de relatórios.

Fluxo de Exceção [ ]: Erro de validação


Quadro 15- Tabela de documentação de caso de uso - Emitir relatórios
Nome Atualizar estoque CSU-11

Sumário O caso de uso descreve o processo de atualização de estoque.

Ator secundário: Funcionário
Pré-condição: O usuário deve estar cadastrado no sistema.
Pós-condição: Usuário logado no sistema
33
Fluxo Principal
1. O usuário seleciona a opção para efetuar venda.

2. O sistema apresenta o caso de uso efetuar venda.
3. O usuário confirma a venda.
4. È registrado a atualização do estoque.
2.1. O usuário cancela a realização da venda

Fluxo de Exceção [ ]:
Não há fluxo de Exceção

Quadro 16- Tabela de documentação de caso de uso - Atualizar estoque
3.4.2 Descrição dos Atores
Funcionário: um funcionário tem como responsabilidade realizar vendas a

clientes assim como cadastrá-los e realizar devoluções de mercadorias ou vendas
condicionais. Ele deve logar no sistema para poder ter acesso a essas
funcionalidades.
34
Administrador: é uma especialização de funcionário. Além de poder realizar

as mesmas tarefas que um funcionário comum, ele possui privilégios especiais que
são cedidos apenas a este tipo de usuário. Funções que somente um administrador
pode executar: cadastrar funcionário, cadastrar fornecedor, cadastrar mercadoria,
cadastrar valor da comissão e emitir relatórios.
3.5 Classes de análise
3.6 Diagrama de Classes de Negócio

35
class Business Process Model
Cliente
Dependente
- endereco: String
Devolucao - estado: String - cpfTitular: String
realiza - nome: String - nome: String
- codProduto: String cadastra
- obs: String - numeracao: int
1..* 1
0..* - numero: int
+ criaDependente() : void
1..* 1 + realizaCompra() : void Fornecedor
+ realizarDevolucao() : void
- cnpj: String
1
- nome: String
possui
1..*
1 cadastra
1..*
Pagamento Funcionario
pode ter Venda 1..
- forma: String - id: String
é pago por - cpf: String Administrador
- valor: int realiza - nome: String
- item: ArrayList<Item>
1 1- itemCod: int 0..* 1
+ alterar() : void + cadastrarFonecedor(String) : void
+ cadastrarCliente(Cliente) : void
- pedNumero: int + emitirRelatorios() : Relatorio
+ gravar() : void
+ atualizaCodigoItens() : void 1
+ quantidadeDoProduto(String) : int
1..* Item possui + realizaVenda() : void emite
+ removeArray(int) : void
- codProduto: String 1..* 1
- descricaoProduto: String 1..* 0..*
- itemCod: int
- quantidadeProduto: int Relatorios
Estoque
é atualizado - relatorio1: String
* 1 - quantidadeItens: int
é um - relatorio2: String
+ atualizarEstoque() : void + imprimeRelatorio() : void

Produto
1 1
1- cod: String
- descricao: String
contém
- grupo: String
- preco: float 0..*
- qde: int
- tamanho: String
atualiza
Figura 2- Diagrama de Classes de Negócio
3.6.1 Classes de Fronteira (o bruno já fez)
Interface de Menu: Contém todos os links para todas as

funcionalidades do sistema, algumas acessíveis a todos, outras somente a um grupo
de administradores.
Interface Vendas: É a pagina inicial do sistema, é também a pagina que
mais será utilizada, por meio dela serão efetuadas todas as transações de venda da
36
empresa.
Interface Cadastrar Cliente: Formulário para cadastro de cliente e seus
dependentes, para assim manter uma base de cliente para gerar relatórios e
disseminar promoções futuramente.
Interface Cadastrar Produtos: Formulário para cadastro de produtos da
empresa. É ai que ocorre a entrada em estoque de todos os produtos da empresa e
é onde são cadastradas as características de cada produto com seus respectivos
códigos.
Interface Atualiza Estoque: Formulário para se fazer a atualização do
estoque dos produtos da loja, colocando o código do produto se pode colocar a
atualização da quantidades dos produtos para se dar entrada em estoque.
3.6.2 Classe Controladora
Figura (xx) Esteriotipo da classe de controladora
As classes controladoras coordenam o fluxo de um caso de uso

complexo, encapsulando lógica que não se enquadra naturalmente nas
responsabilidades das entidades. São tipicamente dependentes de aplicação.
(isso já mudou)Controlador de Frente (FrontController) –
Responsável por fazer o gerenciamento de todas as requisições WEB. Esta classe
contém o mapa de todas as classes “command” que implementam os métodos das
classes entidades.
Controlador de Comandos(Command)– É uma interface de Command
que responsável por recebe as requisições da classe FrontController e implementar
os métodos das classes entidades. Cada funcionalidade do sistema possui um
caminho no mapa do FrontController e uma classe Command associada para
implementar os métodos.
37
3.6.3 Classe de Entidade
Figura (xx)Esteriotipo da classe de Entidade
As Classes de Entidade modelam informação persistente, sendo

tipicamente independentes da aplicação. Geralmente são necessárias para cumprir
alguma responsabilidade do produto, e freqüentemente correspondem a tabelas de
bancos de dados.
Entidade Cliente – Contém todos os atributos referentes ao cliente,

bem como os métodos associados, e o seu respectivo construtor. Esta classe é
responsável por criar os objetos Cliente para manipulação dentro do programa. A
classe command implementa estes métodos que estão implícitos dentro desta
classe.
Entidade Item – Contém todas as características referentes ao Item,
contém os métodos associados, e o seu respectivo construtor. A command
implementa estes métodos que estão implícitos dentro desta classe.
Entidade Produto – Esta classe possui todos os atributos da classe
produto, com seus respectivos construtores. Ela é responsável por criar o objeto
produto para a persistência em banco de dados. A classe command associada
implementa os métodos desta classe.
Entidade Venda – Contém todas as características referentes a Venda
com seus respectivos atributos, contém também os métodos associados, e o seu
construtor. A command desta classe implementa estes métodos que estão implícitos
dentro desta classe.
Entidades DAO - São responsáveis por fazer a persistência em banco
38
de dados dos objetos criados nas outras entidades, nas entidades DAO são feitas as
conexões com o banco de dados e são feitas as persistências em banco de dados.
Entidade ConectionFactory - Classe responsável por criar a conexão
com o banco de dados, nesta classe estão inclusos informações como usuário e
senha do banco de dados.
3.7 Diagrama de Sequência
Os diagramas de seqüência enfatizam o ordenamento temporal das

ações. Os diagramas de seqüência são orientados para exprimir, de preferência, o
desenrolar temporal de seqüências de ações. É mais difícil representar lógicas de
seleção e repetição sem prejudicar a inteligibilidade do diagrama. Os roteiros
representam desdobramentos da lógica do caso de uso. É preferível usar diagramas
separados para representar roteiros resultantes de diferentes caminhos lógicos.
sd Realizar Login
Usuário JSP Struts Login Interceptor
Preenche dados
login.action
intercept(ActionInvocation
invocation)
return Ok
Página Principal
Página Principal
Figura 3: Diagrama de Sequência – Realizar Login
O diagrama da Figura 3 mostra a sequência de ações para efetuar a realização de login

39
sd Cadastrar Clientes
Usuário JSP Struts ClienteAction ClienteBO DAO
Solicita Cadastro de Cliente
clienteForm.jsp
Usuário fornece dados
insereClienteUpdate.action
insereClienteUpdate()
alt
[Novo cliente] insereCliente(cliente)
grava(cliente)
[Editar cliente]
atualizaCliente(cliente)
atualiza(cliente)
return "ok"
clienteForm.jsp
alt
[Resposta editar cliente]
Inserido com sucesso
[Resposta novo cliente]
Editado com sucesso
Figura 4: Diagrama de Sequência – Cadastrar Clientes
O diagrama da figura 4 mostra a sequencia de ações para a realização do cadastro de um cliente, note que no
diagrama existe a possibilidade tanto de cadastrar um novo cliente como a opção de editar um cliente já
existente, pois o fluxo de ações é o mesmo para ambos.
40
sd cadastrarFuncionario
funcionario JSP struts FornecedorAction FornecedorBO FornecedorDAO
solicita cadastro de funcionario
funcionarioForm.jsp
fornece dados
insertFuncionarioUpdate.action
insertFuncionarioUpdate()
alt
[Novo funcionário]
gravaFuncionario(funcionario)
grava(fun)
[Atualiza funcionário]
editar(funcionario)
editar(funcionario)
buscaTodosFuncionario()
buscaTodosFuncionarios()
return listaFuncionarios
return listaFuncionarios;
return "ok"
listarFuncionarios.jsp
alt
[Resposta novo funcionário]
inserido com sucesso
[Resposta atualiza funcionário]
atualizado com sucesso
Figura 5: Diagrama de Sequência – Cadastrar Funcionário
O diagrama da Figura 5 mostra a sequência de ações para efetuar o cadastramento de um funcionário, note que
no diagrama existe a possibilidade tanto de cadastrar um novo funcionário como também editar um funcionário
já existente no sistema.
41
sd fornecedor
Funcionário JSP Struts

FornecedorAction FornecedorBO FuncionarioDAO
solicita cadastro de fornecedor
cadastroFornecdedorForm.jsp
fornece dados
insereFornecedorUpdate.action
insereFornecedorUpdate()
alt
[Novo Fornecedor]
insereFornecedor(fornecedor)
cadastrar(fornecedor)
[Atualizar Fornecedor]
atualizaFornecedor(fornecedor)
atualiza(fornecedor)
buscaTodosFornecedores()
listarTodos()
listar()
return listaFornecedor
return lista
return "ok"
listaFornecedor.jsp
alt
[Resposta novo fornecedor]
Cadastrado com sucesso!
[Resposta atualiza fornecedor]
Editado com sucesso!
Figura 6: Diagrama de Sequência – Cadastrar Fornecedor
O diagrama da Figura 6 descreve os passos para realizar-se o cadastramento de um novo fornecedor, é possível
tanto o cadastramento de um novo fornecedor como também a edição de dados de um já cadastrado
anteriormente.
42
sd cadastrarMercadoria
Funcionario JSP Struts ProdutoAction ProdutorBO ProdutoDAO
solicita aba produto
produtoForm.jsp
fornece dados
sd cadastrarComissao
insereProduto.action
funcionario JSP struts FuncionarioAction FuncionarioBO FuncionarioDAO

insereProduto()
solicita lista de fornecedores
alt
buscaTodosfuncionarios.action
[Novo produto]
insereProduto(produto)
buscaTodosfuncionarios()
buscaTodosFuncionarios() grava(produto)
[Atualizar produto]
editaProduto(produto)
atualiza(produto)
return "ok"
buscaTodosProduto()
produtoService.buscaT odos()
seleciona editar comissão
todos()
editaComissao.action
buscaFuncionario() listaProdutos
buscaFuncionario(id)
todos
buscaFuncionario(id)
listarProdutos.jsp
return (Funcionario) q.uniqueResult()
listarProdutos.jsp return (Funcionario) q.uniqueResult()
return "ok"
alt
[Resposta novo produto] editarComissao.jsp
Produto gravado com sucesso

formulário para editar comissão
preenche formulário
[Resposta atualizar produto]
Produto alterado com sucesso

alteraComissaoFuncionario.action
alteraComissaoFuncionario()
editar(funcionario)
editar(funcionario)
return buscaTodosFuncionario()
buscaTodosFuncionario()
Figura 7: Diagrama de Sequência – Cadastrar Mercadoria return listaFuncionarios
O diagrama da Figura 7 descreve os passos para se realizar

return "ok"
o cadastramento de uma nova mercadoria (Produto
de Venda), é possível tanto olistarFuncionarios.jsp
cadastramento de uma nova mercadoria como também a edição de dados de uma
mercadoria já cadastrado anteriormente.
43
Figura 8: Diagrama de Sequência – Cadastrar Valor da Comissão
4 PERSISTÊNCIA DE DADOS
44
4.1.1 Introdução
A persistência de dados, na computação, refere-se ao armazenamento

não-volátil de dados, por exemplo, o armazenamento em um dispositivo físico 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 num dispositivo que armazena a informação de modo que ela não
desapareça facilmente.
Verificar isso No desenvolvimento deste sistema, os dados
relacionados aos formulários preenchidos pelos funcionários da loja serão
persistidos no banco de dados MySQL e serão usados na gestão das atividades da
empresa, como por exemplo o controle de estoque, controle de venda, controle
financeiro, emissão de relatórios e cruzamento de pedidos e preferências para a
personalização do atendimento e clientes mais satisfeitos.
4.2 Padrão de Projeto DAO
O padrão de projeto DAO é responsável pela manutenção dos dados

como inserir, apagar e atualizar dados no banco de dados assim como prover
métodos de busca de dados persistidos e listar dados de várias formas.
No caso deste projeto, classe DAO também é a responsável pela
chamada da classe Connection Factory, que cria uma conexão com o banco de
dados e retorna essa conexão a classe DAO.
4.3 Diagrama de Entidade e Relacionamento

45
Cliente
Dependente CLI_CODIGO: INTEGER
CLI_CODIGO: INTEGER (FK) CLI_CPF: CHAR(15)
Fornecedor
DEP_CODIGO: INTEGER CLI_NOME: CHAR(40)
CLI_DATANASC: DATE FOR_CODIGO: INTEGER
DEP_NOME: CHAR(40)
CLI_TELEFONE: CHAR(50) FOR_CNPJ: CHAR(50)
DEP_DATANASC: DATE
CLI_CELULAR: CHAR(50) FOR_IE: CHAR(30)
DEP_SEXO: CHAR(15)
CLI_ENDERECO: CHAR(40) FOR_NOMEFANTASIA: CHAR(60)
DEP_NUMERACAO: INTEGER
CLI_ENDNUMERO: INTEGER FOR_ENDERECO: CHAR(40)
CLI_CEP: CHAR(10) FOR_ENDNUMERO: INTEGER
CLI_COMPLEMENTO: CHAR(15) FOR_CEP: CHAR(15)
CLI_BAIRRO: CHAR(40) FOR_COMPLEMENTO: CHAR(50)
CLI_CIDADE: CHAR(40) FOR_BAIRRO: CHAR(30)
CLI_UF: CHAR(40) FOR_CIDADE: CHAR(40)
FOR_CONTATO: CHAR(60)
Funcionario FOR_UF: CHAR(40)
FUN_CODIGO: INTEGER FOR_MARCAS: TEXT
FOR_NOME: CHAR(50)
FUN_CPF: CHAR(15)
FUN_CTPS: CHAR(50)
FUN_NOME: CHAR(40)
FUN_TELEFONE: INTEGER Pedido
FUN_CELULAR: INTEGER PED_CODIGO: INTEGER
FUN_ENDERECO: CHAR(40) Item
FUN_CEP: CHAR(10) FUN_CODIGO: INTEGER (FK)
FUN_ENDNUMERO: INTEGER CLI_CODIGO: INTEGER (FK) ITE_CODIGO: INTEGER
FUN_COMPLEMENTO: CHAR(15) PED_VALORTOTAL: FLOAT PRO_CODIGO: BIGINT(15) (FK)
FUN_BAIRRO: CHAR(40) PED_DATA: DATETIME PED_CODIGO: CHAR(11) (FK)
FUN_CIDADE: CHAR(40) PED_FORMPAGAMENTO: CHAR(15) ITE_QUANTIDADE: INTEGER
FUN_UF: CHAR(40) PED_TIPO: CHAR(15) ITE_PRECOUNITARIO: FLOAT
FUN_ADMISSAODATA: DATE PED_STATUS: CHAR(15) ITE_NUMERO: INTEGER
FUN_COMISSAO: INTEGER PED_OBSERVACAO: TEXT
Produto
PRO_CODIGO: BIGINT(15)
Login
FOR_CODIGO: INTEGER (FK)
FUN_CODIGO: INTEGER (FK)
PRO_QUANTIDADE: INTEGER
LOG_USUARIO: CHAR(30) PRO_TAMANHO: CHAR(2)
LOG_SENHA: CHAR(15) PRO_SEXO: CHAR(1)
LOG_GRUPO: CHAR(1) PRO_PRECO: FLOAT
PRO_DESCRICAO: CHAR(40)
PRO_CODIGOBARRAS: CHAR(100)
Figura 9: Diagrama de entidade e relacionamento
O diagrama da Figura 9 descreve o modelo de dados de um sistema com alto nível de

abstração. Ele é a principal representação do Modelo de Entidades e Relacionamentos. É
usado para representar o modelo conceitual do negócio.
4.4 Mapeamento Objeto Relacional
O Mapeamento objeto relacional é uma técnica de desenvolvimento

utilizada para reduzir a impedância da programação orientada aos objetos utilizando
bancos de dados relacionais. As tabelas do banco de dados são representadas
através de classes e os registros de cada tabela são representados como instâncias
das classes correspondentes.
46
Com esta técnica, o programador não precisa se preocupar com os

comandos em linguagem SQL; ele irá usar uma interface de programação simples
que faz todo o trabalho de persistência.
Não é necessária uma correspondência direta entre as tabelas de
dados e as classes do programa. A relação entre as tabelas onde originam os dados
e o objecto que os disponibiliza é configurada pelo programador, isolando o código
do programa das alterações à organização dos dados nas tabelas do banco de
dados.
A forma como este mapeamento é configurado depende da ferramenta
que estamos a usar, em nosso projeto usaremos o Hibernate.
4.4.1 Acesso a banco de dados com JDBC
A JDBC(Java Data Base Connectivity) é um conjunto de interfaces e

classes em Java com objetivo de padronizar o modo com que um aplicativo se
conecta com banco de dados, implementando a funcionalidade definida pelo padrão
SQL Call Level Interface ou SQLCLI.
A maioria dos fornecedores de bancos de dados oferece uma
implementação particular de SQLCLI.
A vantagem de JDBC é a portabilidade da aplicação cliente, inerente
da linguagem Java. A JDBC compreende uma especificação para ambos: os
desenvolvedores de drivers JDBC, que A API JDBC permite utilizar caminhos
distintos para acessar a base de dados, e os desenvolvedores de aplicações clientes
que precisem acessar bancos de dados em Java.
4.4.2 Mapeamento Objeto Relacional usando o Hibernate
O Hibernate é um framework de mapeamento objeto/relacional para

Java. Possui um conjunto de classes e interfaces e tem como objetivo
disponibilizar objetos para a função de armazenar, persistir os dados.
Ele permite o mapeamento de objetos relacionais para classes Java
através de annotations para determinar como deverá ser feita a transformação dos
dados entre classes e tabelas e também auxilia no controle das pesquisas e
47
retorno de dados, podendo reduzir significativamente o tempo de desenvolvimento

antes investido em controlar o relacionamento objeto-relacional.
Uma das funcionalidades do Hibernate é a geração de código através
da engenharia reversa, que possibilita a implementação das classes Java de
entidade a partir da estrutura das tabelas criadas no Banco de Dados. Tendo sido
essa a maneira utilizada para iniciar-se a codificação do sistema em questão.
As bibliotecas de Mapeamento Objeto Relacional fazem o mapeamento
de tabelas para classes. Como exemplo o banco de dados desenvolvido para o
sistema possui uma tabela chamada Historico, a aplicação possuirá, uma classe
denominada Historico.
<?xml Essa classe definirá
version="1.0" atributos, que serão usados para receber
encoding="utf-8"?>
<!DOCTYPE hibernate-configuration PUBLIC
e alterar "-//Hibernate/Hibernate
os dados dos campos das tabelas, além
Configuration DTDde3.0//EN"
métodos para realizar as
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
operações. <hibernate-configuration>
<session-factory>
A figura 10 abaixo apresenta o arquivo onde os pacotes e as classes
<property name="connection.driver_class">com.mysql.jdbc.Driver</property>
<property
anotadasname="connection.url">jdbc:mysql://localhost:3306/pgi</property>
são declaradas em um arquivo XML regular, geralmente o
<property name="connection.username">root</property>
"hibernate.cfg.xml".
<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">update</property>
<property name="hibernate.connection.autocommit">true</property>
<mapping class="coisasdecrianca.com.entidade.Cliente" />

<mapping class="coisasdecrianca.com.entidade.Dependente" />
<mapping class="coisasdecrianca.com.entidade.Fornecedor" />
<mapping class="coisasdecrianca.com.entidade.Funcionario" />
<mapping class="coisasdecrianca.com.entidade.Item" />
<mapping class="coisasdecrianca.com.entidade.Produto" />
<mapping class="coisasdecrianca.com.entidade.User" />
<mapping class="coisasdecrianca.com.entidade.Venda" />
</session-factory>
</hibernate-configuration>
48
Figura 10 - Arquivo "hibernate.cfg.xml"
Para uma melhor compreensão, o quandro abaixo, da classe produto,

demonstra as anotações utilizadas nos mecanismos de persistência.
...
@Entity
@Table(name = "produto", catalog = "pgi")
public class Produto implements java.io.Serializable{
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name = "pro_codigo", unique = true, nullable = false)
private Integer id;
@Column(name = "pro_codigobarras", unique = true)

private String codigo;
@Column(name = "for_codigo")
private Integer fornecedorCodigo;
@Column(name = "pro_quantidade")
private int quantidade;
@Column(name = "pro_tamanho")
private String tamanho;
@Column(name = "pro_sexo")
private String sexo;
@Column(name = "pro_preco")
private float preco;
Figura xx Classe de entidade produto
@Column(name = "pro_descricao")
private String descricao;
…
49
Figura 11 – Classe de entidade Produto.
Quanto à aplicabilidade das anotações implementadas:

@Entity: declara a classe como uma classe de entidade (ou uma classe
persistente). Id, todas as classes de entidade (entity classes) persistentes
precisarão de tal atributo se quisermos utilizar todos os recursos do Hibernate.
@Table: usada para definir qual tabela será usada para persistir os objetos dessa
classe. Se essa anotação não for usada, o Hibernate irá procurar por uma tabela
com o mesmo nome da classe.
@Id: declara qual campo, atributo da classe será usado como identificador. Neste
caso, foi definido o atributo "id".
@Column: usada para definir as propriedades dos atributos.
5 PROJETO DE INTERFACE
5.1 Introdução
O projeto de interfaces visa à melhor interação possível entre o usuário

e o sistema, tendo em vista as premissas de desing e funcionalidades que o sistema
necessita, uma interface apresentável e funcional são requisitos indispensáveis para
um sistema limpo e que não canse a pessoa que interage diariamente com ele, a
interface é importante, pois é ela a porta de entrada e o cartão de visita do sistema.
5.2 Tecnologias utilizadas
Java Server Pages (JSP): é uma tecnologia utilizada no

desenvolvimento de aplicações para Web. Por ser baseada na linguagem de
programação Java, tem a vantagem da portabilidade de plataforma, que permite a
sua execução em diversos sistemas operacionais. Esta tecnologia permite ao
50
desenvolvedor de páginas para Internet produzir aplicações que acessem o banco

de dados, manipulem arquivos no formato texto, capturem informações a partir de
formulários e captem informações sobre o visitante e sobre o servidor.
Uma página criada com a tecnologia JSP, depois de instalada em um

servidor de aplicação compatível com a tecnologia Java EE, é transformada em um
Servlet.
São exemplos de servidor compatível com a tecnologia JSP o Tomcat,

que será utilizado no projeto de desenvolvimento do aplicativo web da empresa
Coisas de Criança LTDA e o Glassfish.
Outra tecnologia utilizada foi o Cascading Style Sheets(CSS), que é

uma linguagem de estilo utilizada para definir a apresentação de documentos
escritos em uma linguagem de marcação, como HTML ou XML. Seu principal
benefício é prover a separação entre o formato e o conteúdo de um documento.
Em vez de colocar a formatação dentro do documento, o

desenvolvedor cria um link (ligação) para uma página que contém os estilos,
procedendo de forma idêntica para todas as páginas de um portal. Quando se quiser
alterar a aparência do portal basta, portanto modificar apenas um arquivo.
Utilizamos também da tecnologia JavaScript, que trata de uma

linguagem de programação criada pela Netscape em 1995 para atender,
principalmente, as necessidades de validação de formulários no lado do cliente e
interação com a página.
Javascript tem sintaxe semelhante à do Java, mas é totalmente

diferente no conceito e no uso. Esta linguagem possui tipagem mutável e variáveis
dinâmicas que podem assumir vários tipos diferentes durante a execução já que as
variáveis não são tipadas, é interpretado ao invés de compilado, possui ótimas
ferramentas padrão para listagens e oferece bom suporte a expressões regulares.
Usando o Javascript, é possível modificar dinamicamente os estilos dos

elementos da página em HTML, apesar de que, nesta etapa do projeto o foco do uso
deste script está na validação de formulários e não na dinâmica dos estilos.
51
Para arquitetura o grupo optou pelo uso do MVC, que se trata de um

padrão de arquitetura de software responsável pela separação das tarefas de
acesso aos dados e lógica de negócio, lógica de apresentação e de interação com o
usuário, introduzindo um componente entre os dois, que é o Controller. Com o
aumento da complexidade das aplicações desenvolvidas torna-se fundamental a
separação entre os dados (Model) e o layout (View). Desta forma, alterações feitas
no layout não afetam a manipulação de dados, e estes poderão ser reorganizados
sem alterar o layout.
E na implementação do programa foi utilizado a linguagem de

programação JAVA que é uma linguagem de programação orientada a objetos e que
fornece uma vasta API e recursos além das facilidades de encontrar material de
apoio.
Utilizamos também os frameworks hibernate, struts e tiles, cada um

com suas particularidades. Com o struts foi possível fazer um melhor controle das
ações que o sistema deverá realizar. Já o uso do hibernate facilitou a forma com que
os objetos relacionais serão manipulados e persistência e gerenciamento de
sessões para transações do aplicativo. E com o tiles o reuso de código e todas as
vantagens deste conceito muito importante e utilizado por desenvolvedores, que
entre suas diversas vantagens podemos citar o grande ganho de tempo e
produtividade, característica relevante para o desenvolvimento deste projeto.
5.3 Diagrama de estados de navegação

52
ui B u s in e s s P ro c e s s M o d e l
L o g in p rin c ip a l
Id e n ti fi c a çã o O K
Fin al
In i ci o
C a d a stra r Cl i e n te
C a d a stra r
P ro d u to E fe tu a r
A tu a li z a r E sto q u e
Ven da
Ca d a s tra r Clie nte C a d a s tra r P ro d uto

Atua liz a E s to q u e
C a d a stra r P ro d u to A tu a l i za r E sto q u e
C a d a stra r
C l ie n te Ca d a stra r P ro d u to
C a d a stra r C l i e n te
A tu a l i za r E sto q u e
Figura 12: Diagrama de estado de navegação
6 ARQUITETURA E CÓDIGO
6.1 Introdução
O processo de planejamento do software é fundamental para um

desenvolvimento de um projeto de alta qualidade, pois um planejamento bem feito
reduz a complexidade, o tempo e facilita futuras alterações necessárias no
programa, alem de nortear sobre a responsabilidade de cada área no projeto,
visando sempre atender as necessidades do usuário.
6.2 Aplicação em Camadas

53
Uma das premissas para um desenvolvimento de sistema que tenha

código limpo, seja funcional e tenha a distinção entre tipos de códigos com funções
diferentes é a aplicação em camadas, em que cada camada é responsável por um
tipo de código diferente, fazendo assim que o código se torne mais claro de se
entender. A aplicação em camadas distingue os códigos em Apresentação, Controle
e Persistência em banco de dados, cada camada tem a suas funções definida, com
isso não é valido colocar componentes de uma camada em outra.
6.3 Modelo MVC
6.3.1 Arquitetura MVC

54
Figura 13: Arquitetura MVC
O modelo de três camadas físicas, divide um aplicativo de modo que a lógica de

negócio reside no meio das três camadas físicas. Isto é chamado de camada física
intermediária ou camada física de negócios. A maior parte do código escrito reside
na camada de apresentação e de negócio.
A arquitetura MVC - (Modelo Visualização Controle) fornece uma maneira de dividir

a funcionalidade envolvida na manutenção e apresentação dos dados de uma
aplicação. A arquitetura MVC não é nova e foi originalmente desenvolvida para
mapear as tarefas tradicionais de entrada , processamento e saída para o modelo de
interação com o usuário. Usando o padrão MVC fica fácil mapear esses conceitos no
domínio de aplicações Web multicamadas.
Na arquitetura MVC o modelo representa os dados da aplicação e as regras do

negócio que governam o acesso e a modificação dos dados. O modelo mantém o
estado persistente do negócio e fornece ao controlador a capacidade de acessar as
funcionalidades da aplicação encapsuladas pelo próprio modelo.
Um componente de visualização renderiza o conteúdo de uma parte particular do

modelo e encaminha para o controlador as ações do usuário. Acessa também os
dados do modelo via controlador e define como esses dados devem ser
apresentados.
55
Um controlador define o comportamento da aplicação. É ele que interpreta as ações

do usuário e as mapeia para chamadas do modelo. Em um cliente de aplicações
Web essas ações do usuário poderiam ser cliques de botões ou seleções de menus.
As ações realizadas pelo modelo incluem ativar processos de negócio ou alterar o
estado do modelo. Com base na ação do usuário e no resultado do processamento
do modelo, o controlador seleciona uma visualização a ser exibida como parte da
resposta a solicitação do usuário. Há normalmente um controlador para cada
conjunto de funcionalidades relacionadas.
A arquitetura de 3 camadas que esta representada abaixo é uma implementação do

modelo MVC . O modelo MVC esta preocupado em separar a informação de sua
apresentação.
Camada de apresentação ou visualização - Não esta preocupada em como a

informação foi obtida ou onde ela foi obtida apenas exibe a informação.
• Inclui os elementos de exibição no cliente : HTML , XML , ASP , Applets.

• É a camada de interface com o usuário.
• É usada para receber a entrada de dados e apresentar o resultado.
Camada de lógica da Aplicação - É o coração da aplicação. Responsável por tudo

que a aplicação vai fazer.
• Modela os dados e o comportamento por atrás do processo de negócios;

• Se preocupa apenas com o armazenamento, manipulação e geração de
dados;
• É um encapsulamento de dados e de comportamento independente da
apresentação.
Camada de Controle - determina o fluxo da apresentação servindo como uma

camada intermediária entre a camada de apresentação e a lógica.
• Controla e mapeia as ações.
Vantagens do modelo MVC:

56
1. Como o modelo MVC gerencia múltiplos visualizadores usando o mesmo

modelo é fácil manter, testar e atualizar sistemas múltiplos;
2. É muito simples incluir novos clientes apenas incluindo seus visualizadores e
controles;
3. Torna a aplicação escalável;
4. É possível ter desenvolvimento em paralelo para o modelo , visualizador e
controle pois são independentes;
Desvantagens do modelo MVC:
1. Requer uma quantidade maior de tempo para analisar e modelar o sistema;

2. Requer pessoal especializado;
3. Não é aconselhável para pequenas aplicações;
6.3.2 Arquitetura Struts
Figura 14: Arquitetura Framework Struts 2
Struts é um framework de desenvolvimento da camada controladora, numa

estrutura seguindo o padrão Model 2 (uma variante do MVC oficializada pela Sun),
de aplicações web (principalmente) construído em Java para ser utilizado em um
57
container web em um servidor J2EE. Utilizado parafacilitar a implementação da

arquitetura MVC em aplicações JSP.
Ciclo de vida:
O usuário envia requisição e então os Interceptors configurados são

acionados para aplicar funcionalidades comuns tais como: validação, upload de
arquivos etc.
Após isso, o FilterDispatcher analisa a requisição e determina a ação a

ser executada através do método relativo a ação invocada. O método que executa a
ação devolve uma resposta ao struts que então retorna a requisição exibindo o
resultado para o usuário.
Por que utilizar o Framework Struts 2?
• Padrão de mercado
• Aumento de produtividade
• Foco nas regras do negócio
• Criação de componentes/aplicações reutilizáveis
• Integração com as principais ferramentas
• Separa a lógica do negócio da camada de apresentação
• Facilita a população de beans;
• Simplifica o uso de servlets, necessitando apenas a criação de classes Action;
• Com suas tags dispensa o uso de scriptlets em 98% dos casos.
6.4 Padrões de Projeto da Camada de Apresentação

58
A camada de apresentação encapsula toda a lógica relacionada com a

visualização e comunicação com a interface do usuário. Ela não esta preocupada
em como a informação foi obtida ou onde ela foi obtida, apenas exibe as
informações. É usada para receber a entrada de dados e apresentar os resultados.
É nela que são feitas as requisições e respostas HTTP, o
gerenciamento de sessão http e geração de HTML, JavaScript e recursos no lado-
cliente
Em nosso projeto, a camada de apresentação é feita pela JSP, que,
junto com o CSS são os responsáveis pela apresentação e formatação da interface
do usuário, sendo assim, todos os formulários, objetos e imagens do lado do cliente
são organizados através da Java Server Pages que possui div’s CSS embutidas no
corpo do código JSP.
6.5 Padrões de Projeto da Camada de Negócio
A camada de negócio é a responsável por desacoplar as camadas de

apresentação e de serviço. Nela é feito o encapsulamento da lógica de consulta e
criação de objetos de serviços e é responsável por hospedar toda a lógica de
negócios e provê o acoplamento entre o acesso aos dados e a interface do usuário.
Neste projeto foi utilizado o modelo de componentes Enterprise
JavaBeans (EJB) para a construção de componentes
6.6 Padrões de Projeto da Camada de Interface
A camada de interface com o usuário é projetada para atender as

seguintes considerações:
Gerenciamento do fluxo de controle, que está diretamente relacionado
com o estado de navegação do usuário com a aplicação;
Gerenciamento de estado, que trata da disposição das informações a
outra parte do aplicativo;
Separação da lógica que controla o fluxo e o estado da lógica que
59
exibe a informação para o usuário e a lógica de captura de dados;

Encapsulamento do controle de fluxo e do estado para um caso de uso
especifico, que resulta na possibilidade do re-uso da interface com o usuário do nível
do caso de uso.
Sendo assim, a implementação da camada de interface com o usuário
tem como funcionalidade tornar fácil o desenvolvimento de fluxos de processos e
interfaces de navegação complexos que tenham o potencial de serem re-utilizados
em múltiplos cenários, permitindo a evolução da aplicação.
Especificamente temos:
• Separação do código de controle de fluxo (navegação) das páginas,

formulários e controles com os quais os usuários interagem.
• Abstração do gerenciamento de estado do caso de uso isolando formulários e
controles que atuam com os dados.
• Utilização do mesmo modelo de programação - e até do mesmo código - para
o módulo que gerencia o controle de fluxo e o estado em diferentes tipos de
aplicações, incluindo-se: aplicações Windows, WEB, e para dispositivos
móveis.
• Desenvolvimento de aplicações que gerenciem a navegação do usuário em
cenários complexos; por exemplo: re-atribuição de atividades já iniciadas para
diferentes usuários ou tornar possível interromper uma atividade e reiniciá-la
posteriormente. O trabalho em uma central de atendimento telefônico é um
bom exemplo para as necessidades descritas.
Portanto, a camada de interface foi criada com o intuito de atender as

necessidades comumente encontradas quando do desenvolvimento de aplicações
com um grau de complexidade médio ou maior onde as interações do usuário com a
aplicação envolve fluxos de processos elaborados.
60
61
62
63
Figura 17: Diagrama de Pacotes
REFERÊNCIAS BIBLIOGRÁFICAS
http://www.msdnbrasil.com.br/Tecnologias/arquitetura/nova/blocos_disp/imp_interface
http://www.slideshare.net/brenovit/modelo-de-camadas
http://www.argonavis.com.br/cursos/java/j931/J931_01.pdf
http://pt.wikipedia.org/wiki/P%C3%A1gina_principal
http://pt.wikipedia.org/wiki/Regras_de_neg%C3%B3cio
http://pt.wikipedia.org/wiki/Hibernate
http://pt.wikipedia.org/wiki/Struts
http://www.ucb.br/prg/professores/fgoulart/STRUTS_fgoulart.pdf
64
APÊNDICE
Código do arquivo struts.xml
<?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" namespace="/">
<result-types>
<result-type name="tiles"
class="org.apache.struts2.views.tiles.TilesResult" />
</result-types>
<interceptors>
<interceptor name="login"
class="coisasdecrianca.com.interceptor.LoginInterceptor" />
<interceptor-stack name="loginStack">
<interceptor-ref name="servlet-config" />
<interceptor-ref name="params" />
<interceptor-ref name="login" />
<interceptor-ref name="prepare" />
<interceptor-ref name="chain" />
<interceptor-ref name="model-driven" />
<interceptor-ref name="fileUpload" />
<interceptor-ref name="static-params" />
<interceptor-ref name="params" />
<interceptor-ref name="conversionError" />
<interceptor-ref name="validation" />
65
<interceptor-ref name="workflow" />

</interceptor-stack>
</interceptors>
<default-interceptor-ref name="loginStack" />
<global-results>
<result type="tiles" name="login">tiles.login</result>
</global-results>


<action name="vender" method="verificaVenda"
class="coisasdecrianca.com.action.VendaAction">
<result type="tiles" name="ok">tiles.vender</result>
<result type="tiles" name="erro">tiles.vender</result>
</action>
<action name="cancelarVenda" method="cancelarVenda"
</action>
<action name="insereItem" method="insereItem"
</action>
<action name="deleteItemVenda" method="deleteItemVenda"
</action>
<action name="concluirVenda" method="concluirVenda"
<result type="tiles" name="ok">tiles.concluirVenda</result>
<result type="tiles" name="erro">tiles.concluirVenda</result>
</action>
<action name="insereClienteVenda" method="insereClienteVenda"
<result type="tiles" name="ok">tiles.insereClienteVenda</result>
<result type="tiles" name="erro">tiles.insereClienteVenda</result>
</action>
<action name="insereClienteVendaFinal" method="insereClienteVendaFinal"
</action>
<action name="finalizarVenda" method="finalizarVenda"
</action>


<action name="cadastrarCliente" method="cadastrarCliente"
66
class="coisasdecrianca.com.action.ClienteAction">
<result type="tiles" name="ok">tiles.cadastrar</result>
</action>
<action name="insereClienteUpdate" method="insereClienteUpdate"
<result type="tiles" name="input">tiles.cadastrar</result>
<result type="tiles" name="erro">tiles.cadastrar</result>
</action>
<action name="cadastrarDependente" method="cadastrarDependente"
<result type="tiles" name="ok">tiles.cadastrarDependente</result>
</action>
<action name="insereDependente" method="insereDependente"
</action>
<action name="editarDependente" method="editarDependente"
<result type="tiles" name="ok">tiles.cadastrarDependente</result>
<result type="tiles" name="erro">tiles.cadastrarDependente</result>
</action>
<action name="deleteDependente" method="deleteDependente"
</action>
<action name="buscaTodosClientes" method="buscaTodosClientes"
<result type="tiles" name="ok">tiles.listarClientes</result>
</action>
<action name="editarCliente" method="editarCliente"
</action>


<action name="cadastrarProduto" method="cadastrarProduto"
class="coisasdecrianca.com.action.ProdutoAction">
<result type="tiles" name="ok">tiles.cadastrarProduto</result>
</action>
<action name="insereProduto" method="insereProduto"
<result type="tiles" name="input">tiles.cadastrarProduto</result>
<result name="ok" type="redirect-action">buscaTodosProduto</result>
<result type="tiles" name="erro">tiles.cadastrarProduto</result>
</action>
<action name="buscaTodosProduto" method="buscaTodosProduto"
<result type="tiles" name="ok">tiles.listarProduto</result>
<result type="tiles" name="erro">tiles.listarProduto</result>
</action>
<action name="editarProduto" method="editarProduto"
67
</action>
<action name="atualizarEstoque" method="atualizarEstoque"
<result type="tiles" name="ok">tiles.atualizarEstoque</result>
</action>
<action name="atualizaQuantEstoque" method="atualizaQuantEstoque"
<result type="tiles" name="ok">tiles.atualizarEstoque</result>
<result type="tiles" name="erro">tiles.atualizarEstoque</result>
</action>
<action name="insereFornecedorProduto" method="insereFornecedorProduto"
<result type="tiles" name="ok">tiles.insereFornecedorProduto
</result>
<result type="tiles" name="erro">tiles.cadastrarProduto</result>
</action>
<action name="insereFornecedorProdutoFinal"
method="insereFornecedorProdutoFinal"
<result type="tiles" name="erro">tiles.insereFornecedorProduto
</result>
</action>

<action name="buscaTodosfuncionarios" method="buscaTodosFuncionario"

class="coisasdecrianca.com.action.FuncionarioAction">
<result type="tiles" name="ok">tiles.listarFuncionarios</result>
<result type="tiles" name="erro">tiles.listarFuncionarios</result>
</action>
<action name="cadastrarFuncionario" method="cadastrarFuncionario"

<result type="tiles" name="ok">tiles.cadastrarFuncionario</result>
</action>
<action name="insertFuncionarioUpdate" method="insertFuncionarioUpdate"

<result type="tiles" name="input">tiles.cadastrarFuncionario</result>
<result type="tiles" name="erro">tiles.cadastrarFuncionario</result>
</action>
<action name="excluiFuncionario" method="excluiFuncionario"

</action>
<action name="buscaFuncionarioEditar" method="buscaFuncionario"

<result type="tiles" name="ok">tiles.editarFuncionario</result>
<result type="tiles" name="erro">tiles.editarFuncionario</result>
</action>
<action name="editaFuncionario" method="insertFuncionarioUpdate"

68

</action>

<action name="editaComissao" method="buscaFuncionario"

<result type="tiles" name="ok">tiles.editarComissao</result>
</action>
<action name="alteraComissaoFuncionario" method="alteraComissaoFuncionario"

</action>


<action name="buscaTodosFornecedores" method="buscaTodosFornecedores"
class="coisasdecrianca.com.action.FornecedorAction">
<result type="tiles" name="ok">tiles.listaFornecedor</result>
<result type="tiles" name="erro">tiles.listaFornecedor</result>
</action>
<action name="insereFornecedorUpdate" method="insereFornecedorUpdate"
<result type="tiles" name="input">tiles.cadastrarFornecedor</result>
<result type="tiles" name="ok">tiles.listaFornecedor</result>
<result type="tiles" name="erro">tiles.cadastrarFornecedor</result>
</action>
<action name="novoFornecedor" method="novoFornecedor"
<result type="tiles" name="ok">tiles.cadastrarFornecedor</result>
</action>
<action name="editarFornecedor" method="editarFornecedor"
<result type="tiles" name="ok">tiles.cadastrarFornecedor</result>
<result type="tiles" name="erro">tiles.cadastrarFornecedor</result>
</action>


<action name="login" method="login"
class="coisasdecrianca.com.action.LoginAction">
<result name="ok" type="redirect-action">vender</result>
<result type="tiles" name="erro">tiles.login</result>
</action>
<action name="logout" method="logout"

class="coisasdecrianca.com.action.LoginAction">
<result type="tiles" name="ok">tiles.login</result>
</action>
69
</package>
</struts>

Coisas de Criança - Relatório 4 Período

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Coisas de Criança - Relatório 4 Período

Transféré par

Droits d'auteur :

Formats disponibles

FACULDADE PITÁGORAS DE UBERLÂNDIA

Autorizada pela Portaria no 577/2000 – MEC, de 03/05/2000

LOJA COISAS DE CRIANÇA LTDA

LOJA COISAS DE CRIANÇA LTDA

Relatório Parcial submetido ao curso de

Orientador: Prof. Msc. Edson Angoti Júnior

Uberlândia Junho de 2010.

Prof. Msc. Francisco Muller

Dedicamos este trabalho primeiramente a

Aos nossos pais, professores e colegas pelo

A todos àqueles que acreditam que a ousadia

O objetivo deste documento é a modelagem do sistema para gerência de vendas,

Palavras chave: Unified Modeling Language, Model View Controller, HttpServlet,

Figura 1 – Diagrama de casos de uso....................................................................................19

Quadro 1 – Tabela de documentação da regra de negócio RN-01........................................17

UML (Unified Modeling Language): é uma linguagem de modelagem que permite

JSP (JavaServer Pages): é uma tecnologia utilizada no desenvolvimento de

HTML: é um acrônimo para a expressão inglesa HyperText Markup Language, que no

XML (Extensible Markup Language): subtipo de SGML (acrônimo de Standard

MVC (Model-view-controller): é um padrão de arquitetura de software responsável

EJB ( Enterprise JavaBeans): é um dos principais componentes da plataforma

API (Application Programming Interface): conjunto de rotinas e padrões

WEB (World Wide Web): é um sistema de documentos em hipermídia que são

LTDA: abreviatura de limitada.

CEP (Código de Endereçamento Postal): é um código desenvolvido pelas

UF: abreviatura de Unidade da Federação.

CNPJ (Cadastro Nacional da Pessoa Jurídica): é um número único que identifica

A visão da loja Coisas de Criança é buscar um crescimento relevante e

2.2 Especificação de requisitos

Cadastro de clientes: O sistema deve permitir ao funcionário

Cadastro de fornecedores: O sistema deve permitir ao funcionário

Cadastro de funcionários: O sistema deve permitir ao funcionário

Cadastro de mercadorias: O sistema deve permitir ao funcionário

Identificação do usuário: O sistema deve permitir a identificação do

possui alguns privilégios em relação ao funcionário. Com o usuário logado, o

Registro da transação de venda: O sistema deve permitir ao

Registro de compra condicional: O sistema deve permitir ao

Devolução de mercadorias: O sistema deve permitir ao funcionário

Controle de comissões de vendas: Define a comissão de venda

Controle financeiro: O sistema deve permitir ao funcionário realizar o

Geração de relatórios: O sistema deve possibilitar a geração de

Comissões: Por funcionário;

Vendas: Por funcionário;

Financeiro: Contas a receber ou a pagar por período;

Funcionário: Dados cadastrais dos funcionários;

O Administrador seleciona o tipo de relatório a ser gerado, o sistema emite o

2.2.1 Requisitos não funcionais

O sistema deverá ser desenvolvido em Linguagem JAVA: O sistema

O sistema deverá utilizar o SGBD My SQL: O sistema deverá contem

O sistema deverá permitir o uso de leitor de código de barras. Deve

O sistema deverá ter controle de acesso com níveis de restrição aos

2.3 Regras de negócio

As regras de negócio dizem respeito às operações, definições e

Nome Pagamento com cheque RN- 01

Quadro 1-Tabela de documentação de regra de negócio RN-01

Nome Compra condicional RN- 02

Um cliente só poderá efetuar compra em condicional, com aprovação previa da

Quadro 2 - Tabela de documentação de regra de negócio RN-02

Nome Compra de mercadoria RN- 03

Quadro 3- Tabela de documentação de regra de negócio RN-03

Nome Devoluções de Mercadoria RN- 04

Nome Cheque Devolvido RN- 05

Quadro 5- Tabela de documentação de regra de negócio RN-05

A coleção de notações, metodologias e ferramentas usadas para reunir