TCC Alysson Serra Vasconcellos

UNIVERSIDADE FEDERAL FLUMINENSE
ALYSSON SERRA VASCONCELLOS
PROJETO DE SISTEMA E-COMMERCE: UMA LOJA VIRTUAL PARA

COMERCIALIZAÇÃO DE BICLICLETAS
Niterói
2016

Trabalho de Conclusão de Curso

submetido ao Curso de Tecnologia em
Sistemas de Computação da
Universidade Federal Fluminense como
requisito parcial para obtenção do título
de Tecnólogo em Sistemas de
Computação.
Orientador:
Jean de Oliveira Zahn
NITERÓI
2016
Ficha Catalográfica elaborada pela Biblioteca da Escola de Engenharia e Instituto de Computação da UFF
V331 Vasconcellos, Alysson Serra

Projeto de sistema e-commerce : uma loja virtual para
comercialização de bicicletas / Alysson Serra Vasconcellos. –
Niterói, RJ : [s.n.], 2016.
101 f.
Projeto Final (Tecnólogo em Sistemas de Computação) –

Universidade Federal Fluminense, 2016.
Orientador: Jean de Oliveira Zahn.
1. Comércio eletrônico. 2. Desenvolvimento de software. 3.

Empresa virtual. 4. Bicicleta. I. Título.
CDD 658.84

Trabalho de Conclusão de Curso

submetido ao Curso de Tecnologia em
Sistemas de Computação da
Universidade Federal Fluminense como
requisito parcial para obtenção do título
de Tecnólogo em Sistemas de
Computação.
Niterói, 22 de dezembro de 2016.
Banca Examinadora:
_________________________________________
Prof. Jean de Oliveira Zahn, MSc. – Orientador
UFF – Universidade Federal Fluminense
_________________________________________
Profa. Danubia de Araújo Machado, Msc. – Avaliadora
UFF – Universidade Federal Fluminense

Dedico este trabalho a meus irmãos, a meus
sobrinhos e a meus pais.
AGRADECIMENTOS
Agradeço a todas as pessoas que estiveram

e estão na minha vida, todas elas que
estiveram ao meu lado e contribuíram, direta
e indiretamente, para a realização deste
trabalho.
“A sabedoria é algo que quando nos bate à
porta já não nos serve para nada”.
Gabriel Garcia Marques
RESUMO
O comércio eletrônico tem sido um importante meio de mediar negociações entre

comprador e vendedor. Além da praticidade e conforto na hora da compra, fatores
como a entrega do produto à domicilio e a facilidade de pagamento impulsionam
esse setor. Diante do crescente cenário e demanda por sistemas de comércio
eletrônico, o presente trabalho propõe um projeto de software para lojas virtuais,
com o foco na Análise e projeto de um sistema de loja virtual para a comercialização
de bicicletas. O projeto foi elaborado para funcionar na plataforma Web, com
completa descrição de banco de dados e sua modelagem, soluções propostas e os
casos de uso, bem como as Classes e Métodos, as regras de negócio e os
requisitos funcionais.
Palavras-chaves: Comércio Eletrônico, e-commerce, Análise de Sistemas, Projeto
de Software.
ABSTRACT
In nowadays the eCommerce have been anexcellent tool to handle business

transactions between consumers and Sellers. Beyond the utility and easy way to
shopping, issues as the well-made delivery and the easy payment became the
eCommercesuccess. After the increase and necessity of eCommerce‟s software, this
work proposes a web store software, minding the system analysis of a bike web
store. The project was write to work in a web platform. The Project launches the
model data base, the solution, minding the project uses cases and as well the Class
and Methods, the business rules and functional requirements.
Key words: eCommerce, System Analysis, Software Project.

LISTA DE ILUSTRAÇÕES
Figura 1 - Modelo Entidade-Relacionamento (ER) .................................................... 23

Figura 2 - Mapa dos Casos de Uso do Sistema ........................................................ 90
Figura 3 - Diagrama de Classes ................................................................................ 99
LISTA DE ABREVIATURAS E SIGLAS
B2B – Business To Business (Negócio para Negócio)

C2B – Consumer To Business (Consumidor para Negócio)
SQL – Structured Query Language (Linguagem estruturada para consulta)
MVC – Model View Controler (Modelo, visão e controle)
UDP – User Datagram Protocol (protocolo de data-grama para o usuário)
TCP – Transfer Control Protocol (Protocolo de controle de tráfego)
EDI – electronic data interchange (troca de dados eletrônicos)
UML – Unified Modeling Language (linguagem modelada unificada)
ER –Entidade-Relacionamento
BD – Banco de Dados
UC – User Case (Casos de Uso)
FN – Funcionalidade do Sistema
REQ – Requisição Funcional do Sistema
RNG – Regras de Negócio do Sistema
OO – Orientação a Objetos.
SUMÁRIO
RESUMO..................................................................................................................... 8
ABSTRACT ................................................................................................................. 9
LISTA DE ILUSTRAÇÕES ........................................................................................ 10
LISTA DE ABREVIATURAS E SIGLAS..................................................................... 11
1. INTRODUÇÃO ..................................................................................................... 14
2. O PROJETO LOJA VIRTUAL ............................................................................... 16
2.1. UM BREVE HISTÓRICO DO E-COMMERCE ................................................ 16
2.2. TRABALHOS RELACIONADOS ..................................................................... 18
2.3. MOTIVAÇÕES DO PROJETO ........................................................................ 20
3. MODELODE DADOS DO SISTEMA ..................................................................... 22
3.1. MODELO ENTIDADE RELACIONAMENTO (ER) .......................................... 22
3.2. TABELAS DO BANCO DE DADOS (BD) DO SISTEMA ................................. 24
3.2.1. Tabela Usuario ......................................................................................... 24
3.2.2. Tabela Sessao ......................................................................................... 24
3.2.3. Tabela Bicicleta ........................................................................................ 25
3.2.4. Tabela Produto ......................................................................................... 26
3.2.5. Tabela Oferta ........................................................................................... 26
3.2.6. Tabela Compra......................................................................................... 27
3.2.7. Tabela SolicitacaoDescricao .................................................................... 27
3.2.8. Tabela Carrinho........................................................................................ 28
3.2.9. Tabela Distribuicao................................................................................... 28
3.2.10. Tabela LoteDistribuicao .......................................................................... 29
3.2.11. Tabela Distribuidor ................................................................................. 29
3.3. DESCRIÇÃO JUSTIFICATIVA DOS CAMPOS DAS TABELAS DO BD ......... 30
3.3.1. Descrição Tabela Usuario ........................................................................ 30
3.3.2. Descrição da Tabela Sessao.................................................................... 31
3.3.3. Descrição da Tabela Bicicleta .................................................................. 31
3.3.4. Descrição da Tabela Produto ................................................................... 32
3.3.5. Descrição da Tabela Oferta...................................................................... 33
3.3.6. Descrição da Tabela Compra ................................................................... 33
3.3.7. Descrição da Tabela SolicitacaoDescricao .............................................. 34
3.3.8. Descrição da Tabela Carrinho .................................................................. 34
3.2.9. Descrição da Tabela Distribuicao ............................................................. 35
3.3.10. Descrição da Tabela LoteDistribuicao .................................................... 35
3.3.11. Descrição da Tabela Distribuidor ........................................................... 36
4. SOLUÇÃO PROPOSTA ........................................................................................ 37
4.1. CASO DE USO CADASTRAR CLIENTE ........................................................ 38
4.1.1. Diagrama do caso de uso Cadastrar Cliente ............................................ 38
4.1.2. Descrição do caso de uso Cadastrar Cliente ........................................... 39
4.2. CASO DE USO AUTENTICAR CLIENTE ....................................................... 42
4.2.1. Diagrama do caso de uso Autenticar Cliente ........................................... 42
4.2.2. Descrição do caso de uso Autenticar Cliente ........................................... 43
4.3. CASO DE USO REALIZAR COMPRA ............................................................ 45
4.3.1. Diagrama do caso de uso Realizar Compra ............................................. 45
4.3.2. Descrição do caso de uso Realizar Compra ............................................ 46
4.4. CASO DE USO CALCULAR FRETE .............................................................. 48
4.4.1 Diagrama do caso de uso Calcular Frete .................................................. 48
4.4.2 Descrição do caso de uso Calcular Frete .................................................. 49
4.5. CASO DE USO GERENCIAR CARRINHO ..................................................... 50
4.5.1. Diagrama do caso de uso Gerenciar Carrinho ......................................... 50
4.5.2. Descrição do caso de uso Gerenciar Carrinho ......................................... 51
4.6. CASO DE USO CONFIRMAR PAGAMENTO ................................................ 54
4.6.1. Diagrama do caso de uso Confirmar Pagamento..................................... 54
4.6.2. Descrição do caso de uso Confirmar Pagamento .................................... 55
4.7. CASO DE USO REALIZAR DESCRIÇÃO DETALHADA ................................ 57
4.7.1. Diagrama do caso de uso Realizar Descrição detalhada ......................... 57
4.7.2. Descrição do caso de uso Realizar Descrição detalhada ........................ 58
4.8. CASO DE USO CADASTRAR ADMINISTRADOR ......................................... 61
4.8.1.Diagrama do caso de uso Cadastrar Administrador .................................. 61
4.8.2.Descrição do caso de uso Cadastrar Administrador ................................. 62
4.9. CASO DE USO AUTENTICAR ADMINISTRADOR ........................................ 65
4.9.1. Diagrama do caso de uso Autenticar Administrador ................................ 65
4.9.2. Descrição do caso de uso Autenticar Administrador ................................ 66
4.10.CASO DE USO ADMINISTRAR SOLICITAÇÃO DE DESCRIÇÃO ............... 68
4.10.1. Diagrama do caso de uso Administrar Solicitação de Descrição ........... 68
4.10.2. Descrição do caso de uso Administrar Solicitação de Descrição ........... 69
4.11. CASO DE USO ADMINISTRAR PRODUTOS .............................................. 72
4.11.1. Descrição do caso de uso Administrar Produtos .................................... 72
4.11.2. Descrição do caso de uso Administrar Produtos .................................... 73
4.12. CASO DE USO ADMINISTRAR OFERTAS ................................................. 76
4.12.1. Diagrama do caso de uso Administrar Ofertas ....................................... 76
4.12.2. Descrição do caso de uso Administrar Ofertas ...................................... 77
4.13. CASO DE USO ADMINISTRAR VENDAS .................................................... 80
4.13.1. Diagrama do caso de uso Administrar Vendas ...................................... 80
4.13.2. Descrição do caso de uso Administrar Vendas ...................................... 81
4.14. CASO DE USO ADMINISTRAR DISTRIBUIÇÃO ......................................... 84
4.14.1. Descrição do caso de uso Administrar Distribuição ............................... 84
4.14.2. Descrição do caso de uso Administrar Distribuição ............................... 85
4.15. MAPA DOS CASOS DE USOS DO SISTEMA ............................................. 90
5. REGRAS, CLASSES E FUNCIONALIDADES ...................................................... 91
5.1. FUNCIONALIDADES DO SISTEMA ............................................................... 91
5.2. REGRAS DE NEGÓCIO DO SISTEMA .......................................................... 93
5.3. REQUISITOS FUNCIONAIS DO SISTEMA .................................................... 95
5.4. DIAGRAMA DE CLASSES DO SISTEMA ...................................................... 97
5.4.1. Descrição das Classes ............................................................................. 97
CONCLUSÃO .......................................................................................................... 100
REFERÊNCIAS BIBLIOGRÁFICAS ........................................................................ 101
14
1. INTRODUÇÃO
O presente trabalho propõe um Sistema de comércio eletrônico, a partir

de concepções relacionadas a e-commerce e a análise de uma loja virtual de
bicicletas. Para este fim serão apresentados dados cruciais da análise de Sistemas
deste projeto.
O modelo (na primeira forma normal), tanto quanto, as suas descrições e
características das tabelas do Bando de Dados. A solução proposta, mostrando os
casos de uso do Sistema, assim como os detalhes caso a caso. As regras de
negócio, as funcionalidades e requisitos funcionais do Sistema.
Os elementos fundamentais da análise desse projeto darão um panorama
do que um empreendedor perderia como forma de controle (ao falar-se em controle
em Tecnologia da Informação, entende-se controle de dados, isto é, informação) ao
optar por uma solução pronta, sem necessidade de análise.
O seguinte projeto de análise (utilizando o software free StarUML na
geração dos diagramas do projeto) pretende fornecer um prospecto do que um
empreendedor, que pretende possuir uma loja virtual, vai poder agregar como
recurso de Informação.
Para este fim, será apresentado um trabalho dividido em mais 4
Capítulos. Esta divisão decorre da necessidade de segmentação do projeto, pois um
projeto de software pode ser apreendido separadamente, sem que uma parte
necessariamente implique na outra. Seguem abaixo as descrições dos Capítulos do
projeto:
O Capítulo 2, que é uma definição do que é e-commerce e como esse
conceito é praticado no mercado. Esta conceituação servirá de base para entender a
principal motivação deste projeto. Este Capítulo desenvolverá a ideia de importância
do e-commerce e defenderá pontos a favor da empresa, que pretende abrir sua
própria loja virtual, fazer sua própria análise de sistema e levantar o projeto do zero.
15
Já o Capítulo 3, entrando no projeto, se propõe a exemplificar a

modelagem de dados de um Sistema fictício: Loja Virtual de bicicletas. Será
abordado o diagrama das entidades (referências às tabelas do Sistema) e como se
relacionam, mostrando também suas relações de cardinalidade. Serão descritas
também todas as tabelas do Sistema. Essas noções sobre o Banco de Dados
demonstram o tamanho do Sistema acerca do montante de dados que o Sistema
possuirá.
Dando sequência, o Capítulo 4 abordará o funcionamento específico de
cada ação de cada ator do Sistema. Mostrando alguns fluxos de dados do Sistema,
as possíveis exceções e bugs (erros), assim como as específicas funcionalidades.
Assim, poder-se-á compreender como será o funcionamento do Sistema na prática,
assim também, o nível de trabalho, da mesma forma, o nível de conforto que o
Cliente poderá ter ao navegar na loja virtual. A partir desta visão do Cliente, será
possível fazer a relação trabalho x satisfação que é muito importante para qualquer
negócio empreendedor.
Por fim, o Capítulo 5, majoritariamente, funcionará como referencia,
durante a fase de implementação, à equipe de programação do projeto. Neste
Capítulo as classes trazem os métodos que deverão ser implementados, assim
como os requisitos e regras de negócio deverão também ser levados em conta na
fase de programação.
16
2. O PROJETO LOJA VIRTUAL
O presente Capítulo vai tentar, a partir dos conceitos e exemplos de e-

Commerce, também argumentando pontos a favor de um projeto de análise de
sistemas para lojas virtual, mostrar o porquê do projeto Loja Virtual de bicicletas.
2.1. UM BREVE HISTÓRICO DO E-COMMERCE
E-commerce ou comércio eletrônico, que também pode ser conhecido

como negócio eletrônico (e-business), é compreendido como a “referência das
transações de benefícios e serviços através da comunicação eletrônica" (Zheng,
2009, cap. I). Oe-commerce abrange toda forma de relação comercial entre qualquer
forma de serviço e produtos se utilizando da comunicação eletrônica (internet). As
diferentes formas de serviço podem ser: aulas online, consultorias médicas, legais,
empresarias, etc. As diferentes formas de produtos podem ser de qualquer tipo:
músicas, filmes, eletrodomésticos, móveis, livros, etc. Entre outros diferentes canais
que o e-commerce utiliza são: páginas web própria (com link privado), páginas
públicas de divulgação (como o Facebook), e-mail, etc.
O e-commerce surgiu na década de 1990, considerando a relação Cliente
X Empresa. Pois por volta do ano de 1991, surgem, na forma de “B2C” (Business to
consumer (Becker, 2007, cap. VIII) – Empresa X Consumidor Comum), as vendas de
serviços e artigos online para o consumidor.
Porém, as empresas já praticavam comércio eletrônico entre si na forma
de “B2B” (Business to Business(Becker, 2007, cap. II) – Empresa X Empresa) desde
a década de 1960. Em outras palavras, as empresas já usavam a rede para acordos
comerciais dentro do conceito e-commerce „Empresa para Empresa‟ (B2B). Um dos
fatores que estimulou esta relação foi porque já era tendência na época o
17
paperless(a diminuição do uso de papel) provocando assim a rotina de escritório

entre empresas de troca de dados comercias entre um computador e outro, ao invés
de trocarem correspondências postais. A prática que começou na década de 1960 é
conhecida como EDI – electronic data interchange (troca de dados eletrônicos), o
que passou a ser chamado na década de 1990 como e-commerce.
O e-commerce expandiu-se rapidamente pelo mundo, na década de
1990, não houve uma maior difusão localizada por muito tempo em um local
específico do mundo. No Brasil, como nos EUA, já era possível acessar uma loja
virtual já na década de 1990. O que aconteceu aqui no Brasil, e possivelmente o
mesmo fenômeno em outros países, foi o aumento considerável de acessos às lojas
virtuais em um período posterior ao ano de 1991 (pode-se somente fazer uma
estimativa, pois esses dados são provenientes de empresas, de acordo com o site:
https://www.internetparaempreendedores.com.br/ – vide bibliografia). No Brasil, nota-se
o aumento nos anos de 2002, principalmente com os sites de leilão. Já nos EUA
houve um aumento significativo nos anos 1995.
As empresas quando realizavam entre si transações comerciais,
utilizavam correspondências ou as vezes, sistema de comunicação, como o fax, ou
simplesmente o telefone. O que já era uma forma de comércio não presencial, ou
comércio virtual. O que já demonstra uma tendência à virtualização do comércio
mesmo antes do e-commerce.
Nos anos de 1980 houve uma evolução constante dos modelos de fazer
Negócios pela Internet, exatamente com o surgimento do www (WorldWide Web) o
e-commerce passou a ser Negócio para pessoas comuns.
É também um fato que nos últimos anos desde o surgimento do e-
commerce essa modalidade vem ganhando força por diferencias como a rapidez, a
falta de necessidade de espaço físico e capacidade de se adaptar as necessidades
comerciais sempre vigentes desde antes dos anos de 1990. Essas vantagens fazem
do e-commerce uma modalidade que não teve outro caminho, senão ganhar cada
vez mais espaço ao longo dos anos.
Acima de tudo, o comércio virtual teve outro grande crescimento nos anos
2000 com o aumento da segurança, “permitindo transações monetárias entre
computadores residências” (Becker, 2007, Cap. 113), por intermédio de um Banco
online - Internet banking.
18
Ressalta-se também o comércio por telefone (o telemarketing), um

formato não presencial de negociar mercadorias, o que poderia suprir a demanda da
velocidade e ausência de espaço físico para o comércio mais moderno. O mesmo
acontece para o modelo de vendas pela TV. De qualquer forma o comercial digital
(melhor definição para e-commerce no Brasil) ganhou espaço, pois é mais dinâmico
que a TV e mais visual do que o telemarketing. Poder construir uma vitrine sem
necessitar de espaço físico não poderia ter a rejeição de negociantes e empresários
desde que TI vem ganhando força e espaço no mundo dos negócios.
Portanto, mesmo consolidados os modelos de televendas (venda pela
televisão) e telemarketing (venda pelo telefone), o e-commerce consegue superar
ambos em termos de uso, geração de capital e feedback positivo de clientes. O
modelo televiso foi considerado obsoleto e eficaz com um universo muito restrito de
produtos. O modelo comercial pelo telefone é considerado abusivo e confuso. Por
esses motivos o e-commerce acaba sendo primeira opção empresarial para o
comércio impessoal.
2.2. TRABALHOS RELACIONADOS
Pode-se citar uma gama grande de exemplos de atuações do e-

commerce, modelos de aplicação, nomes de empresas e suas formas de atuação
(veja-se abaixo, de acordo com o artigo „The Business Models of E-Marketplace‟ em
Zheng (2006) – vide bibliografia).
A empresa pode atuar sobre a forma de e-mail, enviando promoções e
vantagens sobre seus produtos e serviços. Ela usa um gerenciador de email (um
software próprio ou pago) para discriminar específicos clientes que vão receber
anúncios de acordo com seus perfis.
A forma mais convencional de atuação de uma empresa é através do e-
shop, a própria loja virtual. É a virtualização de uma loja física, com pelo menos um
dos itens comuns: carrinhos de compras, vitrine para escolha dos produtos, local de
pagamento, local de informações e dúvidas.
Existem outros meios de e-commerce bem diretos também. Como o e-
auctions, que consiste de páginas nas quais clientes dão lances em produtos
19
desejados. E o e-mall, uma plataforma onde anunciantes de e-commerce

disponibilizam seus catálogos, ou seja, os anunciantes utilizam o serviço de um
website para mostrar seus produtos de suas lojas online.
Existem também o Information Broker (Informação de corretores ou
informação de intermediários) e o Third Party Marketplaces (mercado de terceiros).O
Information Broker é um assistente digital, atuando mais de forma indireta, que
oferece informações pessoais e/ ou transações de potenciais clientes às empresas
(B2B - business to business). O Third Party Marketplaces é um modelo na forma de
plataforma web que suporta empresas que não têm e-commerce, podendo facilitar a
logística de entrega, pagamento, ordem de pedido e mostruário de catálogos.
Ao se exemplificar empresas se verifica as diferentes formas de atuação,
do e-commerce, no mercado. Criando essa possibilidade é fácil identificar a
multiplicidade da sua atuação, demonstrando como o e-commerce é importante para
o mercado global atual.
Pode-se citar um gigante, o Ebay. A empresa cria mercado para trazer
compradores e vendedores em um só ambiente, no qual podem vender, comprar,
revender, consumir com total liberdade do usuário do Ebay. A empresa Online cobra
taxas por cada transação realizada. Na America latina, o MercadoLivre tem uma
atuação parecida.
E pode-se citar também o Google, que além de suas variadas formas de
atuação, atua como e-mall (assim como o Buscape e o Zoom) e, através do Google
Apps, vem atuando como provedor de serviços. Usando a internet, os Apps do
Googlevendem serviços para serem usados digitalmente (assim como o DropBox),
usam a tática: free-for-many, fee-for-few. Em outras palavras, disponibilizam serviços
sem custo ao usuário comum, o consumidor, e cobram taxas de poucos, os usuários
representando empresas, os negociantes. Essa tática usada pela Google e por
algumas outras empresas mostra como no cenário do e-commerce o tipo B2B ainda
é muito importante nos dias atuais.
Os exemplos de companhias nacionais e internacionais, tanto os modelos
de aplicações supracitados mostram a gama de atuação e importância do e-
commerce no cenário global atual.
20
2.3. MOTIVAÇÕES DO PROJETO
Cada vez mais surgem lojas virtuais no mercado, a maioria utiliza os

mesmos conceitos de navegabilidade, funcionalidade, modernidade. Grandes nomes
do mercado varejista no Brasil, (como o extra.com, americanas.com, entre outros)
alcançam resultados satisfatórios.
Os grandes varejistas, como os supracitados, não revelam as bases de
seus projetos de loja virtual, assim não se sabe se eles utilizaram projetos próprios
ou modelos prontos para o uso. Porém existe empresas, como a OpenCart, que por
definição “é uma solução pronta e gratuita”.
O OpenCart é um sistema para comércio eletrônico com código aberto,

desenvolvido em PHP e licenciado nos termos da GNU General Public
License, em outras palavras, é uma solução pronta e gratuita para gestão
de loja virtual [www.opencartbrasil.com.br].
Ao optar por uma loja virtual pronta, o empreendedor deixa de ter muitas
formas de controlar o seu negócio, tome-se nota:
 Tecnologia a ser utilizada (a linguagem de programação e de banco
de dados a ser utilizada, assim certos modelos de Banco de Dados,
como o noSQL e padrões de arquitetura, como o MVC).
 A arte a ser utilizada, pois não há como decidir todos os aspectos
gráficos do Sistema.
 A configuração da camada de transporte das Redes, por exemplo: O
Sistema poderia trabalhar a relação distribuidor X Loja utilizando o
protocolo UDP (deveria implementar serviço dentro da aplicação para
garantir entrega segura de entrega de dados) para tornar mais rápido
as comunicações, em oposição ao protocolo comum, o TCP.
 Regras de negócio, pois o empreendedor não poderá tomar certas
decisões do software, como por exemplo: a quantidade definida para
o formato para inclusão de descrição de cada produto da loja.
21
 Não poderá evoluir o sistema para criar novas funcionalidades como,

por exemplo: Gerador de Relatório de Controle para vendas e
pagamento.
A partir da Análise de Sistemas é possível compreender o tamanho de um

software e também dimensionar o problema a se solucionar, neste caso: Criar o
projeto da solução que atenderia aos clientes de uma loja virtual de bicicletas. Para
esse fim este trabalho mostra o que está por de trás de uma loja virtual, somente
aquilo que já deixa claro o tamanho e a complexidade de um projeto de software
Loja virtual. Com o exemplo deste trabalho, pretende-se mostrar o que o
empreendedor não vê, ou simplesmente não conhece, ao obter o serviço de uma
empresa que traz “uma solução pronta”.
22
3. MODELODE DADOS DO SISTEMA
Neste Capítulo serão abordadosos aspectos fundamentais relacionados

ao projeto e desenvolvimento do banco de dados do sistema, i.e., como o sistema
vai se comportar a nível de modelagem de dados.
3.1. MODELO ENTIDADE RELACIONAMENTO (ER)
O modelo Entidade Relacionamento (ER) tem como objetivo descrever os

dados ou aspectos de informação de um domínio de negócio ou seus requisitos de
processo. A Erro! Fonte de referência não encontrada. (segue abaixo) apresenta o modelo
R desenvolvido para a atual abordagem.
23
Figura 1 - Modelo Entidade-Relacionamento (ER)

24
3.2. TABELAS DO BANCO DE DADOS (BD) DO SISTEMA
3.2.1. Tabela Usuario
Nome do Tipo de Permitir

Campo dado Nulo Chave Breve descrição
Chave Código identificador do
idUsuario int Não primária usuário
login text Não - Login do usuário
senha text Não - Senha do usuário
tipoUsuario char Não - Tipo de usuário.
nome text Não - Nome do usuário
cpf text Não - CPF do usuário
email text Sim - Email do usuário
Data de nascimento do
dataNasc datetime Não - usuário
Número da rua
numEndereco text Não - residencial do usuário
CEP do endereço do
CEP text Não - usuário
Tabela 3.2.1 - Usuario
3.2.2. Tabela Sessao

Chave Código identificador da
idSession int Não primária sessão
Chave Código identificador do
codUsuario int Não estrangeira usuário
25
Dia e a hora da sessão

diaHora dateTime Não - do usuário
Duração da sessão do
duracao int Não - usuário
Tabela 3.2.2 - Sessao
3.2.3. Tabela Bicicleta
Tipo de Permitir
idBicicleta int Não primária bicicleta
Chave Código Identificador do
codProduto int Não estrangeira Produto
Identificação do código
Chave referente ao tipo de
codTipoProduto int Não estrangeira produto
modelo text Não - Código série da bicicleta
marca text Não - Fabricante da bicicleta
Em qual estilo a bicicleta
estilo text Sim - se enquadra
O tipo e o tamanho do
quadro
quadro text Sim -
O tipo e o tamanho do
aro
aro text Sim -
Tipo de revestimento,
tamanho e estilo do selim
selim text Sim - (banco)
guidao text Sim - O tipo e o tamanho
O tipo de revestimento
pneu text Sim - e espessura
Se há ou não e
marcha text Sim - descrições
sistema text Sim - O tipo de sistema
Se há ou não e
suspensao text Sim - descrições
Se há ou não e
luz text Sim - descrições
Se há ou não e
retrovisor text Sim - descrições
26
Se há ou não e
paralama text Sim - descrições
carona text Sim - Se há ou não e
A carga máxima que
carga int Sim - suporta a bicicleta
Peso líquido da
peso float Sim - bicicleta
Tabela 3.2.1 - Bicicleta
3.2.4. Tabela Produto

Chave Código Identificador
idProduto int Não primária do Produto
Código Identificador
referente ao tipo de
codTipoProduto int Não - produto
Descrição referente ao
descTipoProduto text Não - tipo de produto
Tabela 3.2.4 - Produto
3.2.5. Tabela Oferta

idOferta int Não primária oferta
Data da criação da
diaHora dateTime Sim - oferta
valor float Sim - Valor (preço) da oferta
codTipoProduto int Não estrangeira produto
codProduto int Não estrangeira Produto
27
Sim (false
valor Indica se a oferta está
ativo boolean default) - válida
Tabela 3.2.5 - Oferta
3.2.6. Tabela Compra
Tipo de Permitir
Nome do Campo dado Nulo Chave Breve descrição
idCompra int Não primária da compra
codOferta int Não estrangeira da oferta
Código identificador
Chave do cliente
codCliente int Não estrangeira comprador
Data da compra
dataCompra dateTime Não - realizada
Valor (preço) da
valorOferta float Não - oferta
valorFinal float Não - Valor final pago
Valor do frete da
valorFrete float Sim - compra
Sim (false Indica se o
valor pagamento foi
confirmacao boolean default) - confirmado
Tabela 3.2.6 - Compra
3.2.7. Tabela SolicitacaoDescricao

idSolicitacao int Não primária da solicitação
codProduto int Não estrangeira produto
28
Descrição da
envioSolicitacao text Não - solicitação
Sim (false
valor Indica se a solicitação
statusSolicitacao boolean default) - foi respondida
Resposta da
retornoSolicitacao text Sim - solicitação
Tabela 3.2.7 - SolicitacaoDescricao
3.2.8. Tabela Carrinho

Chave Código Identificador da
idCarrinho int Não primária compra
codOferta int Não estrangeira oferta
Dia e hora da oferta
-
diaHora dateTime Não adicionada ao carrinho
Sim (false
valor - Se o carrinho está
fechado boolean default) aberto ou fechado
Tabela 3.2.1 - Carrinho
3.2.9. Tabela Distribuicao

idDistribuicao int Não Primária distribuição
codLote int Não Primária lote
codDistribuidor int Não Estrangeira dodistribuidor
Data de transporte do
dataTransporte dateTime Não - lote
Tabela 3.2.2 - Distribuicao
29
3.2.10. Tabela LoteDistribuicao

idLote int Não Primária lote
codProduto int Não estrangeira produto
valor float Não - Valor do lote
Quantidade de
quantidade int Não - produtos
Tabela 3.2.10 - LoteDistribuicao
3.2.11. Tabela Distribuidor

idDistribuidor int Não Primária dodistribuidor.
Nome da empresa
nome text Sim - distribuidora.
Nome do representante
representante text Não - da distribuidora
telefone text Não - Telefone do distribuidor
celular text Sim - Celular do distribuidor
endereco text Não - Endereço do distribuidor
email text Sim - Email do distribuidor
Tabela 3.2.3 - Distribuidor

30
3.3. DESCRIÇÃO JUSTIFICATIVA DOS CAMPOS DAS TABELAS DO BD
A sessão anterior (3.2) mostra todas as tabelas do Sistema do ponto de

vista funcional, deixando claro como estas tabelas serão implementadas na
plataforma (software que contêm os dados lógicos do Sistema) de Banco de Dados.
Deste modo, é possível saber o que cada campo de cada tabelaaceitará como dado
durante a entrada de dados do usuário.
Já esta sessão (3.3) justifica a existência de cada campo de cada tabela
do Banco de dados. É possível também se compreender, nesta sessão, quem são
cada um destes campos e assim conseguir obter uma visão de cada tabela.
3.3.1. Descrição Tabela Usuario
Nome do
Campo Descrição justificativa
Código identificador do usuário. Distingue cada usuário registrado
idUsuario no Sistema.
Login do usuário. Texto a ser inserido pelo usuário no campo Login
login durante a autenticação.
Senha do usuário. Texto criptografado a ser inserido pelo usuário no
senha campo Senha durante a autenticação.
tipoUsuario Tipo de usuário. Os usuários podem ser Administradores ou Clientes.
Nome Completo do usuário. Em caso de necessidade de recuperar a
nome pessoa associada ao usuário pelo nome.
CPF do usuário. Em caso de necessidade de recuperar a pessoa
cpf associada ao usuário pelo CPF do usuário
Email do usuário. Em caso de necessidade de entrar em contato pelo
email usuário por email.
dataNasc Data de nascimento do usuário.
Número da rua residencial do usuário. Número da rua do endereço como
numEndereco padrão utilizado pelas entregas das compras feitas pelo usuário.
CEP do endereço do usuário. CEP como padrão utilizado pela entrega
CEP das compras feitas pelo usuário.
31
Tabela 3.3.1 - Descrição Usuario
3.3.2. Descrição da Tabela Sessao
Nome do
Campo Descrição
Código identificador da sessão. Distingue cada sessão registrada
idSession no Sistema.
Código identificador do usuário. Distingue cada usuário registrado
codUsuario no Sistema.
Dia e a hora da sessão do usuário. Conta-se a partir do Login do
diaHora usuário.
Duração da sessão do usuário. Começa a contar em segundos a
duracao partir do Login do usuário.
Tabela 3.3.2 – Descrição Sessao
3.3.3. Descrição da Tabela Bicicleta
Nome do
Campo Descrição
Código identificador da bicicleta. Distingue cada bicicleta
idBicicleta registrada no Sistema.
Código Identificador do Produto. Distingue cada produto
codProduto registrado no Sistema.
Identificação do código referente ao tipo de produto. Distingue
cada tipo de produto registrado no Sistema. Neste caso, o tipo de
codTipoProduto produto é uma bicicleta.
Código de série da bicicleta. Localiza o código do modelo da
modelo bicicleta de acordo com o fabricante.
marca Fabricante da bicicleta.
Em qual estilo a bicicleta se enquadra. Por exemplo: urbana,
estilo praiana, mountain bike.
O tipo e o tamanho do quadro. O tamanho do quadro é medido
em polegadas. O tipo do quadro normalmente é feito de alumínio,
aço ou fibra de carbono.
quadro
O tipo e o tamanho do aro. O material do aro e o tamanho em
polegadas.
aro
32
selim Tipo de revestimento, tamanho e estilo do selim (banco).

guidao O tipo e o tamanho.
pneu O tipo de revestimento e espessura.
Se há ou nãomarcha e descrições. Se houver marcha
marcha normalmente a bicicleta varia de 21 a 29 marchas.
O tipo de sistema. Se ela é feita de freio a disco, se o sistema de
sistema marcha é interno ou externo, etc...
Se há ou nãosuspensao e descrições. A bicicleta pode ter
suspensao suspensão traseira e/ ou dianteira ou nenhuma suspensão.
luz Se há ou nãoluz e descrições.
retrovisor Se há ou nãoretrovisor e descrições.
paralama Se há ou nãoparalama e descrições.
Se há ou nãocarona e descrições. Se há carga traseira na
carona bicicleta.
A carga máximaque suporta a bicicleta. Peso máximo que a
carga bicicleta suporta Em kg.
peso Peso líquido da bicicleta; Peso total da bicicleta em kg.
Tabela 3.3.3 – Descrição Bicicleta
3.3.4. Descrição da Tabela Produto
Nome do
idProduto registrado no Sistema.
Código Identificador referente ao tipo de produto. Distingue cada
codTipoProduto tipo de produto registrado no Sistema.
descTipoProduto Descrição referente ao tipo de produto.
Tabela 3.3.4 – Descrição Produto

33
3.3.5. Descrição da Tabela Oferta
Nome do
Código identificador da oferta. Distingue cada oferta registrada no
idOferta Sistema.
Data da criação da oferta. Quando o administrador cria uma
diaHora oferta, o Sistema guarda o dia e a hora.
valor Valor (preço) da oferta.
Código Identificador referente ao tipo de produto. Distingue cada
codTipoProduto tipo de produto registrado no Sistema.
Indica se a oferta está válida. A oferta pode estar anunciada ou
ativo não na loja virtual.
Tabela 3.3.5 – Descrição Oferta
3.3.6. Descrição da Tabela Compra
Nome do
Código Identificador da compra. Distingue cada compra registrada
idCompra no Sistema.
codOferta Sistema.
Código identificador do usuário. Distingue cada usuário, neste
codCliente caso cliente, registrado no Sistema.
dataCompra Data da compra realizada.
valorOferta Valor (preço) da oferta.
valorFinal Valor final pago. Este valor é a soma entre o valor da oferta e o
34
valor do frete.
Valor do frete da compra. Este valor é obtido a partir do CEP de
valorFrete entrega do pedido do produto comprado.
Indica se o pagamento foi confirmado. Um produto comprado
confirmacao pode ter ou não o pagamento confirmado.
Tabela 3.3.6 – Descrição Compra
3.3.7. Descrição da Tabela SolicitacaoDescricao
Nome do
Código Identificador da solicitação. Distingue cada solicitação
idSolicitacao registrada no Sistema.
Código Identificador referente ao tipo de produto. Distingue
codProduto cada produto registrado no Sistema.
Descrição da solicitação. Texto enviado pelo cliente para
envioSolicitacao solicitar mais detalhes de um produto
Indica se a solicitação foi respondida. Uma solicitação pode ter
statusSolicitacao sido ou não respondida pelo usuário Administrador.
Resposta da solicitação. Texto retornado pelo Administrador
para fornecendo mais detalhes mais detalhes de um produto ou
retornoSolicitacao somente explicando que os detalhes já foram fornecidos.
Tabela 3.3.7 – Descrição SolicitacaoDescricao
3.3.8. Descrição da Tabela Carrinho
Nome do
Código Identificador docarrinho de compras. Distingue cada
idCarrinho carrinho registrado no Sistema.
codOferta Sistema.
35
Dia e hora da oferta adicionada ao carrinho. Quando o Cliente

adiciona um produto ao carrinho de compras, o Sistema guarda o
diaHora dia e a hora.
Se o carrinho está aberto ou fechado. O carrinho está fechado
quando um cliente já realizou o pagamento dos produtos contidos
fechado no carrinho de compras.
Tabela 3.3.8 – Descrição Carrinho
3.2.9. Descrição da Tabela Distribuicao
Nome do
Código Identificador da distribuição. Distingue cada distribuição
idDistribuicao registrada no Sistema.
Código Identificador do lote. Distingue cada lote de distribuição
codLote registrado no Sistema.
Código Identificador dodistribuidor. Distingue cada distribuidor
codDistribuidor registrado no Sistema.
dataTransporte Data de transporte da distribuição.
Tabela 3.3.9 – Descrição Distribuicao
3.3.10. Descrição da Tabela LoteDistribuicao
Nome do
Código Identificador do lote. Distingue cada lote de distribuição
idLote registrado no Sistema.
Valor do lote. Valor monetário total do lote de distribuição a ser
Valor distribuído para empresa.
Quantidade de produtos. Quantidade de produtos dentro do lote
quantidade distribuído para a empresa.
Tabela 3.3.10 – Descrição LoteDistribuicao

36
3.3.11. Descrição da Tabela Distribuidor
Nome do
Código Identificador dodistribuidor. Distingue cada distribuidor
idDistribuidor registrado no Sistema.
nome Nome da empresa distribuidora.
Nome do representante da distribuidora. Pessoa física que
responde legalmente pela empresa que faz a distribuição de
representante produtos.
telefone Telefone do distribuidor.
celular Celular do distribuidor.
endereco Endereço do distribuidor.
email Email do distribuidor.
Tabela 3.3.11 – Descrição Distribuidor

37
4. SOLUÇÃO PROPOSTA
A partir da proposta, criar um projeto de análise de uma loja virtual online,

surge o problema (como realizar este projeto) a ser resolvido. E para este fim, é
importante identificar o comportamento prático do Sistema através da análise de
Casos de Uso do Sistema.
Este Capítulo apresenta a proposta de solução para o problema
abordado. Diante do exposto, diversas funcionalidades devem ser consideradas no
processo de desenvolvimento do software. Desse modo, este Capítulo detém as
informações fundamentais que envolvem aspectos de documentação do sistema a
ser desenvolvido, bem como diagramas e análises.
Os diagramas de Casos de Uso foram desenvolvidos de acordo com a
demanda significativa do Sistema, pois se tratando de um sistema focado no usuário
(cliente e administrador) os Casos de Uso servem para dimensionar as ações dos
usuários. Estas ações vão suprir necessidades tanto dos usuários, principalmente do
cliente, tanto quanto as necessidades básicas do Sistema.
O Sistema pode ser definido (considerando a atuação dos atores) como
dependente de dois atores: o Usuário e o Administrador. O primeiro ator, o usuário, é
quem visualiza as ofertas, faz os pedidos e realiza as compras na loja virtual. O
Segundo ator, o Administrador, é quem inclui os produtos, as ofertas, faz a
distribuição das mercadorias administra as vendas da loja.
Para cada caso de uso será elaborado o diagrama e a descrição caso a
caso. O diagrama dimensiona as ações do usuário. A descrição traz características
importantes para saber como as funcionalidades de cada ator será executada a nível
de software.
38
4.1. CASO DE USO CADASTRAR CLIENTE
4.1.1. Diagrama do caso de uso Cadastrar Cliente
Diagrama 4.1.1 - Cadastrar Cliente

39
4.1.2. Descrição do caso de uso Cadastrar Cliente
ID: UC01
Objetivo: Permitir ao cliente gerenciar e criar

cadastro no sistema.
Requisitos: [REQ01] O Sistema deverá permitir

qualquer CPF de fazer cadastro.
Atores: Cliente
Pré-condições: Nenhuma a nível de sistema.
Pós-condições: Não se aplica.
Fluxo Principal: Incluir Cadastro
1. O Cliente clica em Cadastrar.
2. O Sistema solicita dados pessoais do

cliente.
3. O Cliente fornece esses dados e uma

senha de sua escolha e confirma.
4. O Sistema valida todos esses dados

do cliente.
5. O Sistema retorna informando

confirmação de cadastro.
Fluxo Alternativo: Visualizar Cadastro
(Cliente com login 1. O Cliente clica em „Visualizar

realizado) Cadastro‟ [UC01].
2. O Sistema Carrega todos os dados

pessoais do cliente
3. O Sistema disponibiliza a
visualização dos dados pessoais do
40
cliente.
Editar Cadastro
1. O Cliente seleciona e o Sistema

executa „Visualizar Cadastro‟ [UC01].
2. O Cliente clica em „Editar Cadastro‟

[UC01].
3. O Sistema disponibiliza a edição dos

campos de cadastro do cliente.
4. O Cliente faz as possíveis alterações

de seus dados e confirma.

confirmação de edição.
Excluir Cadastro
1. O Cliente seleciona e o Sistema

executa „Visualizar Cadastro‟ [UC01].
2. O Cliente clica em „Excluir Cadastro‟

[UC01].
3. O Sistema retorna perguntando se o

cliente tem certeza.
4. O Cliente confirma.

confirmação de exclusão.
Exceções/ Erros: Se algum dado de cadastro, excetuando

CPF, informado pelo cliente estiver
errado exibe mensagem [M2].
Se faltar algum campo durante a

realização de cadastro do cliente, o
Sistema exibe mensagem [M3]
Se o CPF o informado pelo cliente

durante o cadastro estiver errado, o
Sistema exibe mensagem [M4].
Se o CPF o informado pelo cliente

durante o cadastro já estiver cadastro, o
41
Sistema exibe mensagem [M5].
Se algum dado de cadastro informado

pelo cliente durante a edição de dados
estiver errado, o Sistema exibe
mensagem [M2].
Mensagens: 1) Operação realizada com sucesso.
2) Dados inválidos.
3) Campo obrigatório.
4) CPF inválido.
5) CPF já cadastrado.
6) Deseja excluir o registro?
Regras de negócio: [RNG01] O Sistema não vai aceitar que

um CPF faça mais de um cadastro.
Descrição 4.1.2 - Cadastrar Cliente

42
4.2. CASO DE USO AUTENTICAR CLIENTE
4.2.1. Diagrama do caso de uso Autenticar Cliente
Diagrama 4.2.1 - Autenticar Cliente

43
4.2.2. Descrição do caso de uso Autenticar Cliente
ID: UC02
Objetivo: Permitir ao cliente se identificar e

acessar a loja virtual.
Requisitos: [REQ02]O Sistema manterá o usuário

autenticado no sistema até que haja
LogOff.
Atores: Cliente
Pré-condições: Cadastro de cliente no Sistema.
Fluxo Principal: Fazer LogIn
1. O Cliente clica Login.
2. O Sistema disponibiliza a tela de

Login.
3. O Cliente fornece CPF e senha.
4. O Sistema valida esses dados do

cliente.

confirmação de LogIn.
6. Sistema disponibiliza tela de ofertas

da loja virtual.
7. Sistema disponibiliza no canto

superior direito da tela opção de
Visualizar Cadastro [UC01].
Fluxo Alternativo: Fazer LogOff
1. O Cliente clica emfazer LogOff.

44
2. O Sistema retorna confirmando o

LogOff.
3. Sistema disponibiliza tela de ofertas

do sistema.
Exceções/ Erros: Se oCPF é inválido o Sistema exibe

mensagem [M2].
Se a senha é inválida o Sistema exibe

mensagem [M3].
Se o cliente não tiver cadastro, o

Sistema exibe mensagem [M4] e [M5].
Mensagens: 1) Login realizado com sucesso.
2) CPF inválido.
3) Senha inválida.
4) Não há cadastro para este cliente.
5) Por favor, realize o cadastro.
Regras de negócio: [RNG02] O Sistema só permite três

tentativas consecutivas de login, após
isso o usuário só poderá logar depois
de 15 minutos.
[RNG03] Após 30 minutos de

inatividade o Sistema forçará LogOff do
usuário.
Descrição 4.2.2 - Autenticar Cliente

45
4.3. CASO DE USO REALIZAR COMPRA
4.3.1. Diagrama do caso de uso Realizar Compra
Diagrama 4.3.1 - Realizar Compra

46
4.3.2. Descrição do caso de uso Realizar Compra
ID: UC03
Objetivo: Permitir ao cliente realizar um pedido de

um produto desejado.
Requisitos: Não há.
Atores: Cliente
Pré-condições: [UC02] - Realizar LogIn.
Fluxo Principal: Selecionar Produto
1. O Cliente clica em um produto

desejado.

detalhes do produto selecionado.
3. O Sistema disponibiliza „Calcular

Frete‟ [UC04].
4. O Sistema disponibiliza o endereço

de entrega do produto
5. O Sistema disponibiliza a opção

Confirmar Endereço de Entrega [UC03].
Confirmar Endereço de Entrega
6. O Cliente confirma a opção Confirmar

Endereço de Entrega.

Confirmar Compra [UC03].
Confirmar Compra
8. O cliente clica em confirmar Compra.

47
9. O Sistema verifica as informações de

endereço.
10. O Sistema retorna informando que o

pedido foi registrado, exibe mensagem
[M3] e [M4].
11. O Sistema disponibiliza a sessão de

pagamentos [UC05].
Fluxo Alternativo: Editar Endereço de entrega
1. O Cliente clica emEditar Endereço de

Entrega.
2. O Sistema disponibiliza requisição de

endereço de entrega para o produto.
3. O Cliente insere os dados do

endereço.
4. O Sistema valida e retorna

confirmação de alteração.
5. O Sistema retorna para a tela de

confirmação de compra.
Exceções/ Erros: O cliente cancela o pedido antes de

confirmar a compra e Sistema exibe
mensagem [M1].
Se as informações de endereço
estiverem errada(s) O Sistema exibe
mensagem [M2].
Mensagens: 1) Pedido cancelado com sucesso.
2) Informações de endereço inválidas.
3) Pedido realizado com sucesso.
4) Por favor, agora, confirme o

pagamento.
Regras de negócio: [RNG04] O Sistema não permitirá

compra de dois produtos aleatórios.
Descrição 4.3.2 - Realizar Compra

48
4.4. CASO DE USO CALCULAR FRETE
4.4.1 Diagrama do caso de uso Calcular Frete
Diagrama 4.4.1 - Calcular Frete

49
4.4.2 Descrição do caso de uso Calcular Frete
ID: UC04
Objetivo: Permitir ao cliente consultar o valor

referente ao transporte de sua compra.
Requisitos: [REQ03] O Sistema permitirá calculo de

frete de qualquer região no Brasil.
Atores: Cliente.
Pré-condições: Cadastro de cliente no Sistema.
„Selecionar Produto‟ [UC03].
Fluxo Principal: Calcular Frete
1. O Cliente clica em Calcular Frete.
2. O Sistema solicita o CEP de entrega

do Produto.
3. O Cliente fornece o CEP.
4. O Sistema valida o CEP, calcula o

valor do frete, soma no valor final do
produto e retorna o valor do frete para o
produto.
5. O Sistema disponibiliza a página de

confirmação de pedido.
Fluxo Alternativo: 1. O Cliente cancela a opção de

Calcular o Frete.
2. Sistema volta para a página inicial de

vendas.
Exceções/ Erros: Se o CEP disponibilizado pelo cliente é

inválido o Sistema exibe mensagem
50
[M1].
Mensagens: 1) O CEP inserido não é válido.
Regras de negócio: Não há.
Descrição 4.4.2 - Calcular Frete
4.5. CASO DE USO GERENCIAR CARRINHO
4.5.1. Diagrama do caso de uso Gerenciar Carrinho
Diagrama 4.5.1 - Gerenciar Carrinho

51
4.5.2. Descrição do caso de uso Gerenciar Carrinho
ID: UC05
Objetivo: Permitir ao cliente gerar, manejar e

excluir carrinhos de compra.
Atores: Cliente
Pré-condições: [UC01] - Incluir Cadastro.
[UC02] - Realizar LogIn.
Fluxo Principal: Adicionar Produto ao Carrinho
1. O Cliente executa„Selecionar
Produto‟[UC03].

„Adicionar Produto ao Carrinho‟[UC05].
3. O Cliente clica em „Adicionar Produto

ao Carrinho‟ [UC05].
4. O Sistema adiciona o produto

selecionado ao carrinho do cliente.
Fluxo Alternativo: Criar Novo Carrinho
Produto‟[UC03].

„Criar Novo Carrinho‟[UC05].
3. O Cliente clica em „Criar Novo

Carrinho‟[UC05].
4. O Sistema adiciona um novo carrinho

52
ao perfil do Cliente.
Editar Carrinho
Produto‟[UC03].

„Editar Carrinho‟[UC05].
3. O Cliente clica em „Editar

Carrinho‟[UC05].
4. O Sistema disponibiliza todos os

carrinhos criados pelo cliente.
5. O Cliente seleciona um carrinho.

„Excluir Item do Carrinho‟ [UC05].
Excluir Item do Carrinho
1. O Sistema disponibiliza todos os

produtos que estão no carrinho
selecionado em „Editar Carrinho‟
[UC05].
2. O Cliente seleciona o item (produto)

que deseja excluir.
3. O Sistema retorna mensagem [M2].
4. O Cliente confirma.
5. O Sistema deleta o item do carrinho

selecionado pelo cliente.
Exceções/ Erros: Se o Cliente não possuir nenhum

Carrinho, o Sistema retorna a
mensagem [M1] e direciona o Cliente
para „Criar Novo Carrinho‟.
Cliente cancela a tela de edição de

carrinhos que possui.
Cliente cancela a confirmação de

exclusão em „Excluir Item(s) do
Carrinho‟.
53
Mensagens: 1) Você não possui carrinhos, deseja

criar?
2) Confirmação foi cancelada com

sucesso.
3) Carrinho gerado com sucesso.
4) Item adicionado ao carrinho com

sucesso.
Regras de negócio: [RNG05] O produto selecionado sempre

vai para o último carrinho criado.
[RNG06] O Carrinho é criado sempre

quando não há carrinho e ocorre uma
adição de produto.
Descrição 4.5.2 - Gerenciar Carrinho

54
4.6. CASO DE USO CONFIRMAR PAGAMENTO
4.6.1. Diagrama do caso de uso Confirmar Pagamento
Diagrama 4.6.1 - Confirmar Pagamento

55
4.6.2. Descrição do caso de uso Confirmar Pagamento
ID: UC06
Objetivo: Permitir ao cliente finalizar o pagamento

de uma compra desejada.
Requisitos: [REQ04] O Sistema deverá guardar

confirmação de pagamento.
Atores: Cliente
[UC03]-Confirmar Compra.
Fluxo Principal: Selecionar Forma Pagamento
1. O Sistema disponibiliza as opções de

pagamento.
3. O Cliente clica em uma das opções.
4. O Sistema envia mensagem [M1]

pedindo confirmação do Cliente.
5. O Cliente confirma a forma de

pagamento.
6. O Sistema direciona para „Inserir

Pagamento‟ [UC06].
Inserir Pagamento
1. O Sistema disponibiliza formulário de

pagamento para o Cliente preencher
informações do pagamento.
2. O Cliente preenche o formulário e

clica em confirmar.
3. Sistema retorna mensagem [M2]

pedindo confirmação Cliente.
4. Cliente confirma o pagamento.

56
5. Sistema computa as informações do

pagamento e realiza a sua validação.
6. Sistema retorna mensagem [M3]

informando sucesso do pagamento.
Fluxo Alternativo: Gerar Boleto
1. O Sistema disponibiliza as opções de

pagamento.
3. O Cliente clica em boleto bancário.
4. O Sistema envia mensagem [M1]

pedindo confirmação do Cliente.
5. O Cliente confirma a forma de

pagamento.
6. O Sistema retorna o Boleto bancário

do Cliente.
Exceções/ Erros: Se o Cliente cancela a forma de

pagamento, o Sistema redireciona para
‘Confirmar Compra‟ [UC03].
Se o Cliente cancela o pagamento, O

Sistema redirecionado para „Selecionar
Forma Pagamento‟ [UC06].
Se o Sistema não consegue validar as

informações de pagamento, retorna
mensagem [M3] e reenvia o formulário
de pagamento.
Mensagens: 1) Confirma a forma de pagamento?
2) Confirma o pagamento?
3) Pagamento realizado com sucesso.
Regras de negócio: [RNG07] O Administrador deverá

notificar ao cliente caso o pagamento
não seja recebido.
Descrição 4.6.2 - Confirmar Pagamento

57
4.7. CASO DE USO REALIZAR DESCRIÇÃO DETALHADA
4.7.1. Diagrama do caso de uso Realizar Descrição detalhada
Diagrama 4.7.1 - Realizar Descrição detalhada

58
4.7.2. Descrição do caso de uso Realizar Descrição detalhada
ID: UC07
Objetivo: Permitir ao cliente solicitar

especificamente uma descrição mais
detalhada sobre um produto e
acompanhá-la.
Atores: Cliente
[UC03]–Selecionar Produto.
Fluxo Principal: Enviar Solicitação de Descrição
Produto‟[UC03].

„Enviar solicitação de Descrição‟ [UC07]
3. O Cliente clica em „Enviar solicitação

de Descrição ‟ [UC07].
4. O Sistema disponibiliza caixa de texto

para digitar mensagem.
5. O Cliente digita o pedido.
6. O Cliente clica em enviar.
7. O Sistema retorna mensagem [M1]

para que o Cliente confirme a
solicitação escrita.
8. O Cliente Confirma o envio.

59
9. O Sistema registra o pedido do

Cliente.
Verificar Descrição
1. O Cliente executa „Fazer LogIn‟

[UC02].

„Verificar Descrição‟ [UC07].
3. O Cliente clica em „Verificar

Descrição‟ [UC07].
4. O Sistema retorna a lista de

descrições detalhadas respondidas.
5. O Cliente opta por uma.
6. Sistema disponibiliza a descrição

detalhada requerida pelo Cliente.
Fluxo Alternativo: Caso o Cliente cancele o envio


3. O Cliente clica em cancelar envio.
Caso o Cliente cancele a confirmação



5. O Cliente digita o pedido.
6. O Cliente clica em enviar.

para que o Cliente confirme a
60
solicitação escrita.
8. Cliente cancela a confirmação.
Caso o Cliente não possua nenhuma

solicitação de descrição
1. O Cliente executa „Fazer LogIn‟

[UC02].

„Verificar Descrição‟ [UC07].
3. O Cliente clica em „Verificar

Descrição‟ [UC07].
4. Sistema retorna com a mensagem

[M4].
5. Sistema redireciona para „Enviar

Solicitação de Descrição‟ [UC07].
Exceções/ Erros: Se não houver resposta das Mensagens

do cliente, o Sistema retorna mensagem
[M3]. Se o cliente não possuir nenhum
envio de solicitação de descrição,
sistema retorna mensagem [M4].
Mensagens: 1) Confirma o envio da solicitação?
2) Operação realizada com sucesso.
3) O Cliente não possui retorno de

descrição.
4) Cliente não possui nenhuma

solicitação de descrição.
Regras de negócio: [RNG08] O Texto a ser enviado pelo

Cliente deve ter no mínimo 5
caracteres.
[RNG09] O Sistema disponibiliza todas

as descrições detalhadas que já foram
respondidas pelo Administrador.
[RNG10] O Sistema exclui todas as

descrições detalhadas com mais de 6
meses e que já tenham sido
61
visualizadas pelo Cliente.
Descrição 4.7.2 - Realizar Descrição detalhada
4.8. CASO DE USO CADASTRAR ADMINISTRADOR
4.8.1.Diagrama do caso de uso Cadastrar Administrador
Diagrama 4.8.1 - Cadastrar Administrador

62
4.8.2.Descrição do caso de uso Cadastrar Administrador
ID: UC08
Objetivo: Permitir ao Administrador gerenciar e

criar cadastro no sistema.
Atores: Administrador
Pré-condições: Nenhuma a nível de sistema.
Fluxo Principal: Incluir Cadastro
1. O Administrador clica em Cadastrar.
2. O Sistema solicita dados pessoais do

Administrador.
3. O Sistema solicita chave de acesso

de Administrador.
3. O Administrador fornece todos os

dados e uma senha de sua escolha e
confirma.
5. O Sistema valida todos esses dados

do Administrador.

confirmação de cadastro.
Fluxo Alternativo: Visualizar Cadastro
(Administradorcom 1. O Administrador clica em Visualizar

login realizado) Cadastro.
2. O Sistema Carrega todos os dados

pessoais do Administrador.
63
3. O Sistema disponibiliza a
visualização dos dados pessoais do
Administrador.
Editar Cadastro
1. O Administrador seleciona e o
Sistema executa „Visualizar Cadastro‟
[UC10].
2. O Administrador clica em „Editar

Cadastro‟[UC10].
3. O Sistema disponibiliza a edição dos

campos de cadastro do Administrador.
4. O Administrador faz as possíveis

alterações de seus dados e confirma.

confirmação de edição.
Exceções/ Erros: Se algum dado de cadastro, excetuando

CPF, informado pelo Administrador
estiver errado exibe mensagem [M2].
Se faltar algum campo durante a

realização de cadastro do cliente, o
Sistema exibe mensagem [M3]
Se o CPF o informado pelo

Administrador durante o cadastro
estiver errado, o Sistema exibe
mensagem [M4].
Se o CPF o informado pelo

Administrador durante o cadastro já
estiver cadastro, o Sistema exibe
mensagem [M5].
Se algum dado de cadastro informado

pelo Administrador durante a edição de
dados estiver errado, o Sistema exibe
mensagem [M2].
Mensagens: 1) Operação realizada com sucesso.
2) Dados inválidos.
64
3) Campo obrigatório.
4) CPF inválido.
5) CPF já cadastrado.
6) Deseja excluir o registro?
Regras de negócio: [RNG11] A chave de acesso de

Administrador será fornecida
previamente ao Administrador.
[RNG12] O Sistema não vai aceitar que

um CPF faça mais de um cadastro.
Descrição 4.8.2 - Cadastrar Administrador

65
4.9. CASO DE USO AUTENTICAR ADMINISTRADOR
4.9.1. Diagrama do caso de uso Autenticar Administrador
Diagrama 4.9.1 – Autenticar Administrador

66
4.9.2. Descrição do caso de uso Autenticar Administrador
ID: UC09
Objetivo: Permitir ao Administrador se identificar

e acessar a loja virtual.
Requisitos: [REQ05] O Sistema manterá o usuário

LogOff.
Pré-condições: [UC08] - Incluir Cadastro
Fluxo Principal: Fazer LogIn
1. O Administrador clica Login.

Login.
3. O Administrador fornece CPF e

senha.
4. O Sistema valida esses dados do

cliente.

confirmação de LogIn.
Fluxo Alternativo: Fazer Logoff
1. O Administrador clica emfazer

LogOff.
2. O Sistema retorna confirmando o

LogOff.
67
Exceções/ Erros: Se oCPF é inválido o Sistema exibe

mensagem [M2].
Se a senha é inválida o Sistema exibe

mensagem [M3].
Mensagens: 1) Login realizado com sucesso.
2) CPF inválido.
3) Senha inválida.
Regras de negócio: [RNG13] Após 10 minutos de

inatividade o Sistema forçará LogOff do
usuário. (a segurança para o
Administrador deve ser maior).
Descrição 4.9.2 – Autenticar Administrador

68
4.10.CASO DE USO ADMINISTRAR SOLICITAÇÃO DE DESCRIÇÃO
4.10.1. Diagrama do caso de uso Administrar Solicitação de Descrição
Diagrama 4.10.1 – Administrar Solicitação de Descrição
*Este caso de uso tem uma relação de dependência com UC06 - Realizar Descrição detalhada.
69
4.10.2. Descrição do caso de uso Administrar Solicitação de Descrição
ID: UC10
Objetivo: Permitir ao Administrador receber e

retornar solicitações de descrição
realizadas pelos Clientes.
Fluxo Principal: Visualizar Solicitações de Descrição
1. O Sistema disponibiliza „Visualizar

Solicitações de Descrição‟ [UC09].
2. O Administrador clica em„Visualizar

3. O Sistema lista todas as solicitações

enviadas pelos Clientes do Sistema.
4. O Administrador opta por uma

solicitação.
5. O Sistema retorna o texto da

solicitação e a opção „Responder
Solicitação‟ [UC09].
Responder Solicitação
1. O Administrador executa „Visualizar

Solicitações de Descrição’ [UC08].

„Responder Solicitação‟ [UC09].
O Cliente clica em „Responder

70
Solicitação‟ [UC09]
3. O Sistema disponibiliza o texto da

solicitação em uma janela e o formulário
de preenchimento em outra janela.
4. O Administrador preenche o
formulário e clica em enviar.

de confirmação de envio.
6. O Administrador confirma o envio.
7. O Sistema inclui a resposta nas

solicitações efetuadas do Cliente.
Fluxo Alternativo: Caso a solicitação já tenho sido

respondida


3. O Sistema lista todas as solicitações

enviadas pelos Clientes do Sistema.
4. O Administrador opta por uma

solicitação.
5. O Sistema retorna mensagem [M3] e

o texto da solicitação em conjunto com
a resposta.
Exceções/ Erros: Se o Administrador cancelar

confirmação de envio de resposta de
solicitação, Sistema retorna mensagem
[M4].
Se o Administrador retornar texto com

menos de 35 caracteres, o Sistema
retorna mensagem [M5].
Mensagens: 1) Confirma o envio da resposta?

71
2) Solicitação respondida com sucesso.
3) Solicitação já respondida.
4) Cancelamento realizado com

sucesso.
5) Resposta muito curta.
Regras de negócio: [RNG14] O Texto a ser retornado pelo

Administrador deve ter pelo menos 20
caracteres.
[RNG15] As solicitações devem ser

respondidas em até 15 dias após
solicitação realizada.
Descrição 4.10.2 – Administrar Solicitação de Descrição

72
4.11. CASO DE USO ADMINISTRAR PRODUTOS
4.11.1. Descrição do caso de uso Administrar Produtos
Diagrama 4.11.1 – Administrar Produtos

73
4.11.2. Descrição do caso de uso Administrar Produtos
ID: UC11
Objetivo: Permitir ao Administrador incluir,

visualizar, gerenciar e excluir produtos
para o Sistema.
Requisitos: [REQ06] O Sistema não irá permitir a

criação de um produto já existente.
Fluxo Principal: Incluir Novo Produto
1. O Sistema disponibiliza „Incluir Novo

Produto‟ [UC11].
2. O Administrador clica em „Incluir

Novo Produto‟ [UC11].
3. O Sistema disponibiliza tela para

inclusão de descrição e de outras
informações sobre o produto.
4. O Administrador inclui todas as

informações necessárias e envia.
5. O Sistema valida os dados

informados.

8. O Sistema inclui o novo produto na

base de dados e atualiza a sistema com
74
o novo produto.
Fluxo Alternativo: Visualizar Produto

Produtos [UC11].

Produtos [UC11].

produtos do Sistema.
4. O Administrador clica em um produto.

„Editar Produto‟ [UC11] e „Excluir
Produto‟ [UC11].
Editar Produto

Produtos [UC11].

Produto‟ [UC11].

alteração de descrição e de outras
informações sobre o produto.
4. O Administrador altera o que for

necessário e clica e envia.
5. O Sistema valida as alterações.

8. O Sistema altera as mudanças na

base de dados e atualiza a página de
vendas para aquele produto.
Excluir Produto
75

Produtos [UC11].
2. O Administrador clica em „Excluir

Produto‟ [UC11].

de confirmação de exclusão.
4. O Administrador confirma a exclusão.
5. O Sistema exclui o produto na base

de dados e atualiza a página de vendas
sem aquele produto.
Exceções/ Erros: Se o Administrador cancelar qualquer

confirmação de envio, Sistema
redireciona para página inicial de LogIn
de Administrador.
Se o Administrador cancelar a
confirmação de exclusão, Sistema
de Administrador.
Se durante a inclusão, Sistema não

validar os dados de inclusão ou edição,
Sistema retorna mensagem [M5] e
„Visualizar Produtos‟ [UC11].
Mensagens: 1) Confirma o envio?
2) Envio realizado com sucesso.
3) Confirma a exclusão do produto?
4) Produto excluído com sucesso.
5) Dados incorretos para o produto.
Regras de negócio: [RNG16] O Administrador deverá se

basear nas linhas de bicicletas mais
recentes para criar novos produtos.
Descrição 4.11.2 – Administrar Produtos

76
4.12. CASO DE USO ADMINISTRAR OFERTAS
4.12.1. Diagrama do caso de uso Administrar Ofertas
Diagrama 4.12.1 – Administrar Ofertas

77
4.12.2. Descrição do caso de uso Administrar Ofertas
ID: UC12
Objetivo: Permitir ao Administrador incluir,

visualizar, gerenciar e excluir ofertas
para o Sistema.
Requisitos: [REQ07] O sistema deverá verificar se

existe mais de uma oferta sobre o
mesmo produto e com o mesmo preço.
Fluxo Principal: Incluir Nova Oferta
1. O Sistema disponibiliza „Incluir Nova

Oferta‟ [UC12].
2. O Administrador clica em „Incluir

Nova Oferta‟[UC12].

inclusão de preço, de descrição e de
outras informações sobre a oferta.


informados.

8. O Sistema inclui a nova oferta na

78
vendas com o novo produto.
Fluxo Alternativo: Visualizar Oferta
1. O Sistema disponibiliza
„VisualizarOfertas‟ [UC12].

Ofertas‟ [UC12].

ofertas da loja virtual.
4. O Administrador clica em uma oferta.

„Editar Oferta [UC12] e „Excluir Oferta‟
[UC12].
Editar Oferta

Ofertas‟ [UC12].

Ofertas‟ [UC12].

alteração de preço, de descrição e de
outras informações sobre o produto.
4. O Administrador altera o que for

necessário e clica e envia.
5. O Sistema valida as alterações.

8. O Sistema altera as mudanças na

vendas para aquele produto.
Excluir Oferta
79

Ofertas‟ [UC12].

Ofertas‟ [UC12].

5. O Sistema exclui a oferta na base de

dados e atualiza a página de vendas
sem aquele produto da oferta.

de Administrador.
de Administrador.

„Visualizar ofertas [UC12].
3) Confirma a exclusão da oferta?
4) Oferta excluída com sucesso.
5) Dados incorretos para a oferta.
Regras de negócio: Não há.
Descrição 4.12.2 – Administrar Ofertas

80
4.13. CASO DE USO ADMINISTRAR VENDAS
4.13.1. Diagrama do caso de uso Administrar Vendas
Diagrama 4.13.1 – Administrar Vendas

81
4.13.2. Descrição do caso de uso Administrar Vendas
ID: UC13
Objetivo: Permitir ao Administrador visualizar,

gerenciar e excluir vendas (compras
realizadas pelo cliente) para o Sistema.
Requisitos: [REQ08] O Sistema deverá

disponibilizar todas as compras
realizadas por clientes.
Fluxo Principal: Visualizar Venda

Venda [UC13].

Venda [UC13].

clientes cadastrados no Sistema.
4. O Administrador clica em um Cliente.
5. O Sistema disponibiliza a lista de

produtos comprados pelo cliente.
6. O Administrador clica em um produto.
7. O Sistema disponibiliza informações

sobre a venda do produto.
8. Sistema disponibiliza „Gerenciar

Venda‟ [UC13]e „Excluir Venda [UC13].‟
82
Fluxo Alternativo: Gerenciar Venda

Venda‟ [UC13].
2. O Administrador executa „Gerenciar

Venda‟ [UC13].
3. O Sistema disponibiliza janela para

alteração de informações sobre a
venda.
4. O Administrador altera as
informações que desejar.
5.Sistema valida as informações.

de confirmação de alteração.
7. O Administrador confirma.
8. O Sistema realiza as operações para

alterações da venda.
Excluir Venda

Produtos [UC11].

Venda‟ [UC11].

5. O Sistema exclui a venda do produto.

de Administrador.
83

de Administrador.

„Visualizar Produtos‟ [UC11].
3) Confirma a exclusão do produto?
4) Produto excluído com sucesso.
5) Dados incorretos para o produto.
Regras de negócio: [RNG17] As compras (vendas)

visualizadas pelo Administrador
constarão na ordem, por Cliente, das
mais recentes vendas.
[RNG18] O Administrador não poderá

excluir uma Compra com o pagamento
confirmado.
Descrição 4.13.2 – Administrar Vendas

84
4.14. CASO DE USO ADMINISTRAR DISTRIBUIÇÃO
4.14.1. Descrição do caso de uso Administrar Distribuição
Diagrama 4.14.1 – Administrar Distribuição

85
4.14.2. Descrição do caso de uso Administrar Distribuição
ID: UC14
Objetivo: Permitir ao Administrador administrar as

distribuições de produtos.
Requisitos: [REQ09] O sistema deverá armazenar

dado específico sobre o Lote de uma
distribuição.
[REQ10] O Sistema deverá manter

cadastro de Distribuidor para realizar
uma distribuição.
Fluxo Principal: Cadastrar Distribuidor
1. O Administrador clica em „Cadastrar

Distribuidor‟ [UC14].
2. O Sistema solicita dados de contato

daempresa Distribuidora.
3. O Administrador fornece todos

osdados e confirma.
4. O Sistema valida todos os dados.
6. O Sistema retorna [M1] confirmação

de cadastro de Distribuidor.
7. O Administrador clica em confirma.
8. Sistema inclui o novo Distribuidor na

base de dados.
Incluir Novo Lote
1. Após concluir „Cadastrar Distribuidor‟

[UC14].
86
2. O Sistema disponibiliza „Incluir Novo

Lote‟[UC14].
3. O Administrador clica em „Incluir Novo

Lote‟[UC14].
4 O Sistema disponibiliza tela para

inclusão de informações sobre o novo
lote.


informados.
7. O Sistema retorna mensagem [M2] de

confirmação de envio.
8. O Sistema inclui a novo lote na base

com o novo produto.
Incluir Nova Distribuição
1. Após concluir „Incluir Novo Lote‟

[UC14].
2. O Sistema disponibiliza „Incluir Nova

Distribuição‟[UC14].
3. O Administrador clica em „Incluir Nova

Distribuição‟[UC14].
4 O Sistema disponibiliza tela para

inclusão de informações sobre a nova
distribuição.


informados.

87
confirmação de envio.
8. O Sistema inclui a novo lote na base

com o novo produto.
Fluxo Alternativo: Visualizar Distribuição

Distribuição‟ [UC14].


distribuições cadastradas no Sistema.
4. O Administrador clica em uma

Distribuição.
5. O Sistema disponibiliza a lista de lotes

associados à distribuição, „Associar Lote‟
[UC14]e „Excluir Distribuição‟[UC14].
6. O Administrador clica em um lote.
7. O Sistema disponibiliza informações

sobre o lote.
8. Sistema disponibiliza e „Desassociar

Lote‟[UC14].
AssociarLote

2. O Administrador clica em „Associar

Lote‟ [UC14].
3. O Sistema retorna a lista de todos os

lotes cadastrados.
4. O Administrador seleciona um lote.
5. O Sistema retorna [M4] pedindo

88
confirmação do Administrador.


alterações da distribuição.
DesassociarLote

Distribuição‟ [UC14], clicando no lote
desejado.
2. O Administrador clica em
„Desassociar Lote‟ [UC14].

5. O Sistema valida as informações.


alterações da distribuição.
Excluir Distribuição

Distribuição‟ [UC14.


89

confirmação de exclusão.

exclusão da distribuição.

de Administrador.
de Administrador.
Se durante alguma inclusão, Sistema

não validar os dados de inclusão,
„Visualizar Distribuição‟ [UC11].
3) Confirma a inclusão?
4) Operação realizada com sucesso.
5) Dados incorretos para esta inclusão.
Regras de negócio: [RNG19] A distribuição deverá ser

agendada pelo administrador.
Descrição 4.13.2 – Administrar Distribuição

90
4.15. MAPA DOS CASOS DE USOS DO SISTEMA
Figura 2 - Mapa dos Casos de Uso do Sistema

91
5. REGRAS, CLASSES E FUNCIONALIDADES
5.1. FUNCIONALIDADES DO SISTEMA
A Tabela 5.1 abaixo descreve as funcionalidades do Sistema. As FS

(funcionalidade de Sistema) estão paralelas com os casos de uso do Sistema da
solução proposta.
Identificador Descrição
Incluir, visualizar, editar e excluir

FS01 Cadastro de Cliente
FS02 Efetuar Login de Ciente.
FS03 Realizar pedido e confirmar Compra.
FS04 Calcular Frete.

Criar Carrinho de compras; Editar,
Adicionar e Excluir itens do Carrinho
FS05 de compras.
Selecionar forma de pagamento e

FS06 Realizar pagamento.
Verificar e enviar Solicitação de

FS07 Descrição de produtos.
Incluir, visualizar e Editar Cadastro de

FS08 Administrador.
92
FS09 Efetuar Login de Administrador.

Visualizar e responder solicitações de
descrições de descrição enviadas
FS10 pelos clientes.
Incluir, visualizar, editar e excluir

FS11 produtos da loja virtual.
Visualizar, Gerenciar e excluir Vendas

FS12 realizadas pelos clientes.
FS13 Distribuição
Tabela 5.1 – Funcionalidades do Sistema

93
5.2. REGRAS DE NEGÓCIO DO SISTEMA
A Tabela 5.2 abaixo descreve as regras de negócio do Sistema (RNG). As

RNGservem para definir como o Sistema vai se comportar diante de contextos
específicos que espelham as intenções de negócio (Bussiness) do Sistema.
O Sistema não vai aceitar que um

RNG01 CPF faça mais de um cadastro.
O Sistema só permite três tentativas
consecutivas de login, após isso o
usuário só poderá logar depois de 15
RNG02 minutos.
Após 30 minutos de inatividade o

RNG03 Sistema forçará LogOff do usuário.
O Sistema não permitirá
simultaneamente compra de dois
RNG04 produtos aleatórios.
O produto selecionado sempre vai

RNG05 para o último carrinho criado.
O Carrinho é criado sempre quando
não há carrinho e ocorre uma adição
RNG06 de produto.
O Administrador deverá notificar ao
cliente caso o pagamento não seja
RNG07 recebido.
O Texto a ser enviado pelo Cliente

RNG08 deve ter no mínimo 5 caracteres.
O Sistema disponibiliza todas as
descrições detalhadas que já foram
RNG09 respondidas pelo Administrador.
94
O Sistema exclui todas as descrições

detalhadas com mais de 6 meses e
que já tenham sido visualizadas pelo
RNG10 Cliente.
A chave de acesso de Administrador
será fornecida previamente ao
RNG11 Administrador.
O Sistema não vai aceitar que um

RNG12 CPF faça mais de um cadastro.
Após 10 minutos de inatividade o
Sistema forçará LogOff do usuário. (a
segurança para o Administrador deve
RNG13 ser maior).
O Texto a ser retornado pelo
Administrador deve ter pelo menos 20
RNG14 caracteres.
As solicitações devem ser
respondidas em até 15 dias após
RNG15 solicitação realizada.
O Administrador deverá se basear
nas linhas de bicicletas mais recentes
RNG16 para criar novos produtos.
As compras (vendas) visualizadas
pelo Administrador constarão na
ordem, por Cliente, das mais recentes
RNG17 vendas.
O Administrador não poderá excluir
uma Compra com o pagamento
RNG18 confirmado.
A distribuição deverá ser agendada

RNG19 pelo ator Administrador.
Tabela 5.2 – Regras de Negócio

95
5.3. REQUISITOS FUNCIONAIS DO SISTEMA
A Tabela 5.3 abaixo descreve os requisitos funcionais do Sistema (as

REQ). As REQ servem para definir o que o Sistema vai fazer diante de contextos
caracterizados por aquilo que o Sistema deve cumprir para o seu bom
funcionamento.
O Sistema deverá permitir qualquer

REQ01 CPF de fazer cadastro.
O Sistema deverá manter o Cliente
REQ02 LogOff.
O Sistema permitirá calculo de frete

REQ03 de qualquer região no Brasil.
O Sistema deverá guardar

REQ04 confirmação de pagamento.
O Sistema deverá manter o
administrador autenticado no sistema
REQ05 até que haja LogOff.
O Sistema não irá permitir a criação

REQ06 de um produto já existente.
O sistema deverá verificar se existe
mais de uma oferta sobre o mesmo
REQ07 produto e com o mesmo preço.
O Sistema deverá disponibilizar todas

REQ08 as compras realizadas por clientes.
O sistema deverá armazenar dado
específico sobre o Lote de uma
REQ09 distribuição.
96
O Sistema deverá manter cadastro de

Distribuidor para realizar uma
REQ10 distribuição.
Tabela 5.3 – Requisitos Funcionais

97
5.4. DIAGRAMA DE CLASSES DO SISTEMA
O diagrama de classes (Figura3) representa as classes do sistema Loja

virtual de bicicletas. O diagrama contém as relações lógicas entre as classes do
sistema, cada classe possui um conjunto de atributos e métodos. O sistema usará o
OO (orientação a objetos), pois é um padrão de programação que otimiza o uso das
classes e consequentemente evita código redundante. Veja abaixo
pormenorizadamente as descrições de cada classe do sistema.
5.4.1. Descrição das Classes
 Usuario – Responsável pelo login do usuário. Também Gera sessões de

cada acesso do usuário, guardando estas informações no banco de dados.
Gera um carrinho de compras inicialmente vazio, este carrinho se conecta
às ofertas correntes. Através da lista de ofertas presente no objeto da
classe Carrinho, o usuário pode visualizar as ofertas correntes. O usuário
pode realizar uma compra ou simplesmente adicionar a oferta ao carrinho,
ao clicar em uma oferta ele poderá confirmar a compra ou adicionar ao
carrinho.
 Sessao – Esta classe dispara um relógio constando o tempo de sessão do
usuário. Assim que o usuário loga no sistema, imediatamente, após o
objeto sessão ser criado, é disparado o método de geração de tempo de
sessão.
 Carrinho – Como dito anteriormente, a classe usuário é responsável por
gerar um objeto da classe Carrinnho. Esta classe será responsável por
fechar um carrinho, em caso de fechado o atributo statusAtivo recebe valor
false.
 Produto – A classe produto é responsável pela geração de uma oferta,
deste modo é gerado um objeto da classe Oferta no sistema para registrar
as informações da Oferta no Banco de dados. Responsável também por
criar uma nova distribuição com atributos da classe Distribuicao.
98
 Oferta – Esta classe é responsável pelo fechamento de uma oferta, deste

modo o atributo statusAtivo receberá valor false.
 Compra – Após confirmada uma compra pelo usuário, o mesmo pode
cancelar a compra. Através da classe Compra, poderá ser realizado o
cancelamento de uma compra.
 Distribuidor – Esta classe representa os atributos de contato de um
distribuidor.
 Bicicleta – Esta classe representa os atributos de um produto do tipo
Bicicleta.
 Distribuicao – Esta classe representa os atributos de uma distribuição.
99
Figura 3 - Diagrama de Classes

100
CONCLUSÃO
A princípio foi defendido a ideia de se começar um Sistema loja virtual do

zero, em oposição a optar por uma solução pronta no mercado. O que foi sustentado
pela complexidade do que é um Sistema e-commerce, entre muitos aspectos
abordados, sua história e seus exemplos.
Posteriormente, foram descritos e diagramados o Banco de Dados de
uma loja virtual, demonstrando assim o tamanho em termos de dados que um
Sistema teria. Foram também abordadas as ações reais que o Sistema pode tomar
no dia a dia, extraindo-se o papel de cada ator do Sistema, tanto o Cliente (para um
ponto de vista mais comercial), tanto o Administrador (fornecendo um ponto de vista
mais profissional das demandas a serem exercidas no Sistema).
O projeto poderia trazer infindáveis outras características, mas manteve-
se a sobriedade em somente dimensionar a complexidade de um Sistema Loja
Virtual.
Para efeito de ilustração, acerca de outras características que poderiam
constar; pode-se notar que não tivemos uma Entidade para Estoque, com o qual se
poderia prever o comportamento a nível de banco de dados quando uma distribuição
fosse realizada. Obviamente é uma limitação do projeto, pois poder-se-ia
dimensionar ainda mais o montante de dados que o Sistema trabalharia a nível de
Bando de Dados.
Porém, essa característica, nem outras que se poderia citar, não
invalidam o fato de que o projeto consegue dimensionar a complexidade de uma loja
virtual. Todos os elementos descritos nesta análise serviram para aprofundar a ideia
de se trabalhar em um site e-commerce.
101
REFERÊNCIAS BIBLIOGRÁFICAS
1. Qin, Zheng. Introduction to E-commerce. Beijing, China. Springer (Tsinghua

University Texts), 2009.
2. Becker, Annie. Eletronic Commerce: Concepts, Methodologies, Tools,
and Applications (Volume 1). Florida, USA. Florida Institute of Technology,
2007.
3. Weijun, Zheng. Communications of the IIMA. Chicago, USA. School of
Business, University of Wisconsin-Parkside, 2006.
4. Internet Para Empreendedores,
http://www.internetparaempreendedores.com.br/, acessado em 30/10/16.
5. Open Cart Brasil, http://www.opencartbrasil.com.br/ acessado em 30/10/16.
6. Roger Pressman. Engenharia de Software, 6ª ed., McGraw-Hill, 2006.
7. Craig Larman. Utilizando UML e Padrões: Uma Introdução à Análise e ao
Projeto Orientados a Objetos e ao Desenvolvimento Iterativo, 3a. ed.,
Bookman, 2007.
8. GUEDES, Gilleanes T. A. UML: Uma abordagem prática. São Paulo:
NovatecEditora, 2006.
9. BOHNENBERGER, M. C.; SCHMIDT, S. Perfil empreendedor e
desempenho organizacional. RAC, Curitiba, v. 13, n. 3, art. 6, p. 450-467,
jul./ago. 2009.

TCC Alysson Serra Vasconcellos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC Alysson Serra Vasconcellos

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL FLUMINENSE

ALYSSON SERRA VASCONCELLOS

PROJETO DE SISTEMA E-COMMERCE: UMA LOJA VIRTUAL PARA

PROJETO DE SISTEMA E-COMMERCE: UMA LOJA VIRTUAL PARA

Trabalho de Conclusão de Curso

V331 Vasconcellos, Alysson Serra

Projeto Final (Tecnólogo em Sistemas de Computação) –

1. Comércio eletrônico. 2. Desenvolvimento de software. 3.

PROJETO DE SISTEMA E-COMMERCE: UMA LOJA VIRTUAL PARA

Trabalho de Conclusão de Curso

Niterói, 22 de dezembro de 2016.

Prof. Jean de Oliveira Zahn, MSc. – Orientador

UFF – Universidade Federal Fluminense

Profa. Danubia de Araújo Machado, Msc. – Avaliadora

UFF – Universidade Federal Fluminense

Agradeço a todas as pessoas que estiveram

O comércio eletrônico tem sido um importante meio de mediar negociações entre

Palavras-chaves: Comércio Eletrônico, e-commerce, Análise de Sistemas, Projeto

In nowadays the eCommerce have been anexcellent tool to handle business

Key words: eCommerce, System Analysis, Software Project.

Figura 1 - Modelo Entidade-Relacionamento (ER) .................................................... 23

B2B – Business To Business (Negócio para Negócio)

O presente trabalho propõe um Sistema de comércio eletrônico, a partir

Já o Capítulo 3, entrando no projeto, se propõe a exemplificar a

2. O PROJETO LOJA VIRTUAL

O presente Capítulo vai tentar, a partir dos conceitos e exemplos de e-

2.1. UM BREVE HISTÓRICO DO E-COMMERCE

E-commerce ou comércio eletrônico, que também pode ser conhecido

paperless(a diminuição do uso de papel) provocando assim a rotina de escritório

Ressalta-se também o comércio por telefone (o telemarketing), um

2.2. TRABALHOS RELACIONADOS

Pode-se citar uma gama grande de exemplos de atuações do e-

desejados. E o e-mall, uma plataforma onde anunciantes de e-commerce

2.3. MOTIVAÇÕES DO PROJETO

Cada vez mais surgem lojas virtuais no mercado, a maioria utiliza os

O OpenCart é um sistema para comércio eletrônico com código aberto,

 Não poderá evoluir o sistema para criar novas funcionalidades como,

A partir da Análise de Sistemas é possível compreender o tamanho de um

3. MODELODE DADOS DO SISTEMA

Neste Capítulo serão abordadosos aspectos fundamentais relacionados

3.1. MODELO ENTIDADE RELACIONAMENTO (ER)

O modelo Entidade Relacionamento (ER) tem como objetivo descrever os

Figura 1 - Modelo Entidade-Relacionamento (ER)

3.2. TABELAS DO BANCO DE DADOS (BD) DO SISTEMA

3.2.1. Tabela Usuario

Nome do Tipo de Permitir

Tabela 3.2.1 - Usuario

3.2.2. Tabela Sessao

Nome do Tipo de Permitir

Dia e a hora da sessão

Tabela 3.2.2 - Sessao

3.2.3. Tabela Bicicleta

Tabela 3.2.1 - Bicicleta

3.2.4. Tabela Produto

Nome do Tipo de Permitir

Tabela 3.2.4 - Produto

3.2.5. Tabela Oferta

Nome do Tipo de Permitir

Tabela 3.2.5 - Oferta

3.2.6. Tabela Compra

Tabela 3.2.6 - Compra

3.2.7. Tabela SolicitacaoDescricao

Nome do Tipo de Permitir