PIM VI - 6 - Projeto Final

UNIP EAD
Projeto Integrado Multidisciplinar

Cursos Superiores de Tecnologia
PROJETO DE SISTEMA DE CONTROLE DE VENDAS DE LOJAS DE JOGOS,

ACESSÓRIOS E PRODUTOS GEEKS
AMERICANA
2020
UNIP EAD
Projeto Integrado Multidisciplinar
Cursos Superiores de Tecnologia
PROJETO DE SISTEMA DE CONTROLE DE VENDAS DE LOJAS DE JOGOS,

ACESSÓRIOS E PRODUTOS GEEKS
Nome(s) completo(s) do(s) aluno(s): Viviane Gonçalves de

Paiva
RA(s): 1932120
Curso: Análise e Desenvolvimento de Sistemas
Semestre: 3º Semestre
AMERICANA
2020
RESUMO
Este projeto teve como objetivo realizar levantamentos, análise de requisitos e modelagem
para desenvolvimento de um sistema que auxilie na venda e controle de estoque de uma loja
de varejo. A utilização de tecnologias no mundo atual tornou-se um fator imprescindível para
o sucesso das empresas, pois o cliente está sempre com pressa, seu desejo é ser atendido
rapidamente e com qualidade, e torna-se incômodo quando algum estabelecimento não
possuem um sistema de automação eficiente.
PALAVRAS-CHAVE: Software; Controle; Compra; Venda; Estoque; Produto.

ABSTRACT
This project aimed to carry out surveys, requirements analysis and modeling for the
development of a system that helps in the sale and inventory control of a retail store. The use
of technologies in today's world has become an essential factor for the success of companies,
as the customer is always in a hurry, his desire is to be reached quickly and with quality, and
it becomes an incident when an item is not available in the efficient automation system.
Keywords: Software; Control; Purchase; Sale; Stock; Product.

SUMÁRIO
RESUMO...................................................................................................................................3
ABSTRACT...............................................................................................................................4
1 INTRODUÇÃO......................................................................................................................7
2 DESENVOLVIMENTO........................................................................................................8
2.1 Contextualização do Caso..............................................................................................8
2.2 Mercado de Games no Brasil.........................................................................................8
2.3 Mercado Geek.................................................................................................................8
2.4 Pesquisa Soluções Disponíveis no Mercado..................................................................9
3 GESTÃO ESTRATÉGICA DE RECURSOS HUMANOS................................................9
3.1 Importância do Gerenciamento de Recursos Humanos em Projetos........................9
4 ANÁLISE DE SISTEMAS ORIENTADA A OBJETOS.................................................10
4.1 Engenharia de Requisitos.............................................................................................10
4.2 Requisitos e Classificação dos Requisitos...................................................................11
4.3 Regras de Negócios (RN)..............................................................................................11
4.4 Método de Modelagem de Processos de Negócios......................................................12
4.4 Modelagem de Casos de Uso........................................................................................13
4.5 Paradigma da Programação Orientada a Objetos....................................................14
4.6 Diagrama de Classes.....................................................................................................15
4.6.1 Técnicas para Identificação de Classes................................................................16
5 BANCO DE DADOS............................................................................................................16
5.1 Modelo de Diagrama de Entidade de Relacionamento.............................................17
6 PROJETO ANÁLISE DO SISTEMA GERENCIADOR DE ESTOQUE E VENDAS.18
6.1 Introdução.....................................................................................................................18
6.2 Escopo do Produto........................................................................................................18
6.2.1 Nome do Produto...................................................................................................18
6.2.2 Objetivo...................................................................................................................18
6.2.3 Limites do Produto................................................................................................18
6.2.4 Benefícios Esperados do Produto.........................................................................19
6.2.5 Especificação de Ambiente....................................................................................19
6.2.6 Especificação de Equipamentos............................................................................19
6.3 Detalhamento dos Requisitos.......................................................................................20
6.3.1 Requisitos Funcionais (RF)...................................................................................20
6.3.2 Requisitos Não funcionais (RFN).........................................................................22
6.3.3 Regras de Negócios................................................................................................22
6.4 Mapa Mental.................................................................................................................23
6.5 Lista de Eventos............................................................................................................24
6.6 Diagrama de Caso de Uso.............................................................................................25
6.6.1 Caso de Uso Geral do Sistema..............................................................................25
6.6.2 Caso de Uso – UC1 - Manter Funcionário...........................................................26
6.6.3 Caso de Uso – UC2 – Efetuar Login.....................................................................26
6.6.4 Caso de Uso – UC3 – Gerenciar Relatórios.........................................................27
6.6.5 Caso de Uso – UC4 – Manter Cliente...................................................................28
6.6.6 Caso de Uso – UC5 – Manter Fornecedor...........................................................28
6.6.7 Caso de Uso – UC6 – Manter Produto.................................................................29
6.6.8 Caso de Uso – UC7 – Manter Compra.................................................................30
6.6.9 Caso de Uso – UC8 – Manter Venda....................................................................30
6.6.10 Caso de Uso – UC9 – Consultar Preços.............................................................31
6.6.11 Caso de Uso – UC10 – Manter Categorias de Produtos...................................32
6.6.12 Atores do Caso de Uso.........................................................................................32
6.7 Diagrama de Classes.....................................................................................................33
6.8 Modelo Entidade de Relacionamento (MER).............................................................34
6.8.1 Modelo Conceitual.................................................................................................34
6.8.2 Modelo Lógico........................................................................................................35
7 CONCLUSÃO......................................................................................................................36
8 REFERÊNCIAS...................................................................................................................37
7
1 INTRODUÇÃO
Esse Projeto Integrado Multidisciplinar trata-se de criação de um sistema de gestão

de estoque e vendas para uma loja de varejo voltada para jogos eletrônicos, acessórios e
produtos Geeks. O presente trabalho visa descrever toda prática que envolve os processos de
análise e desenvolvimento de sistemas dentro do projeto.
A ideia do desenvolvimento desse sistema surgiu a partir da necessidade da empresa
de atender melhor seus clientes e fazer um controle mais adequado de toda a movimentação.
Foi possível verificar que todo o procedimento de vendas e controles realizado na empresa era
feito manualmente por meio de planilhas, dificultando manter uma organização interna do
estoque e das vendas efetuadas, sendo que esses controles são fundamentais e mínimos para
uma empresa desse ramo.
O sistema será implementado, buscando atender todas as necessidades dos clientes
cadastrados na empresa, inclusive possibilitando eventuais atualizações, ou seja, fornece
compatibilidade para a inclusão de novas funções, emissão de novos relatórios e até mesmo
algumas modificações referente a atualizações de mercado.
Com a automatização dos processos das rotinas da empresa, acarretará a diminuição
de divergências que ocorrem nos estoques e facilitam a localização dos itens e de consultas de
saldo de produtos que serão atualizados diariamente. Possibilitando que os gestores possam
criar planejamentos estratégicos com mais precisão, vendo que os dados extraídos do sistema por
meio de relatórios apresentaram dados reais.
Para o desenvolvimento deste projeto foi necessário um estudo mais aprofundado
sobre a construção de software, análise de sistemas orientada objetos, análise de negócios,
definição de requisitos, modelagem de dados e administração de banco de dados.
Logo, o objetivo deste projeto é realizar uma análise do negócio, identificar quais são
as regras de negócios, os requisitos funcionais e não funcionais, criar os cenários através de
ferramentas de modelagens de dados, para o sistema que foi solicitado a ser desenvolvido,
O método de pesquisa utilizado para elaboração do projeto foi baseado nas
disciplinas de Gestão Estratégica de Recursos Humanos, Análise de Sistemas Orientada a
Objetos, e Administração de Banco de Dados, foram também realizadas pesquisas de
conteúdos bibliográficos, e leitura na internet de artigos relacionados. Com base nas
disciplinas estudadas é apresentado um projeto estruturado, abordaremos com a conceituação
teórica das disciplinas e no final o desenvolvimento do projeto.
8
2 DESENVOLVIMENTO
2.1 Contextualização do Caso
Uma loja de venda de jogos eletrônicos, acessórios e produtos geek fechou um

contrato com uma empresa para o desenvolvimento de um software de controle e
gerenciamento de vendas de produtos e acessórios na área de jogos e cultura geek.
Atualmente, as pequenas tarefas gerenciadas para controlar vendas são manipuladas
utilizando planilhas em Excel.
Para atender o cliente será desenvolvido um sistema desktop e, por isso, contratou-se
uma fábrica de software para o desenvolvimento. Pede-se que: o sistema deve ser
desenvolvido para a plataforma desktop, deve possuir módulos de acessibilidade para que
eventuais usuários portadores de deficiência consigam utilizá-lo.
A empresa possui alguns produtos em estoque que, eventualmente por grau de
raridade e disponibilidade da plataforma de desenvolvimento dos jogos, não podem ser mais
adquiridos pelo cliente, tornando seu controle de venda um pouco mais rigoroso, pois alguns
produtos, após serem baixados do estoque, dificilmente poderão ser adquiridos por
encomenda devido ao seu grau de raridade (item exclusivo/colecionador). No entanto, o foco
é gerenciar as vendas efetuadas ao cliente.
2.2 Mercado de Games no Brasil
Conforme a publicação da revista exame (2019), no ano de 2018 o mercado de

games movimentou um faturamento de 1,5 bilhões de dólares. Com esse resultado o Brasil
mantém a 13º Classificação Global, e posição de liberação latino-americana.
Segundo resultados apresentados da 19º Pesquisa Global de Entretenimento e
Mídias, realizado pela “PwC” (PricewaterhouseCoopers Brasil Ltda), existe a expectativa do
mercado de games no Brasil crescer em torno de 5,3% até 2022.
2.3 Mercado Geek
Os Nerds de antigamente assumiram um estilo de vida, hoje influenciam uma grande

parcela de jovens. Hoje passaram a ser conhecidos como Geeks.
9
Foi Mark Zuckerberg, criador do Facebook, um dos grandes responsáveis por romper
com antigo estereótipo de “Nerd”. Ele é considerado um ícone da Cultura Geek.
Os consumidores Geeks, são fiéis e exigentes, que gostam de tecnologias,
quadrinhos, filmes e jogos, e movimentam um setor bem lucrativo.
2.4 Pesquisa Soluções Disponíveis no Mercado
Atualmente no mercado existem várias opções de Sistemas ERP para lojas, mais
nenhum direcionado especificamente para ramo de jogos e games.
3 GESTÃO ESTRATÉGICA DE RECURSOS HUMANOS
O capital humano é um dos responsáveis pelo sucesso de qualquer empreendimento,

para desenvolver seus negócios e alcançar seus objetivos. Os recursos humanos sempre foram
e continuarão sendo o maior e mais valioso patrimônio das organizações.
Segundo Maximiano (2006), “uma organização é uma combinação de esforços
individuais que tem por finalidade realizar propósitos coletivos. Por meio de uma
organização, torna-se possível perseguir e alcançar objetivos que seriam inatingíveis por uma
pessoa. Uma grande empresa ou uma pequena oficina, um laboratório ou o corpo de
bombeiros, um hospital ou uma escola são todos exemplos de organizações”.
3.1 Importância do Gerenciamento de Recursos Humanos em Projetos
O sucesso de qualquer projeto está diretamente relacionado à capacitação e

motivação das pessoas que estão envolvidas nas suas atividades. Por isso, o gerenciamento
dos recursos humanos do projeto é imprescindível para atingir os resultados técnicos e de
qualidade desejados.
Ao gerenciar a equipe do projeto e observar o desempenho de cada participante, o
gerente da tarefa tem mais controle sobre os processos em desenvolvimento. Assim, é
possível dar feedbacks, identificar e solucionar eventuais problemas, além de implantar
mudanças a fim de otimizar o projeto como um todo e valorizar os seus colaboradores.
Administrar a equipe exige uma combinação de competências, com foco na
comunicação, gerenciamento de conflitos, negociação e liderança. É essencial que os gerentes
10
de projetos determinem atividades desafiadoras para os membros do grupo e reconheçam o

bom desempenho.
4 ANÁLISE DE SISTEMAS ORIENTADA A OBJETOS
Podemos definir que a Análise Orientada a Objetos (AOO) possui foco no

mapeamento de uma solução sistêmica para algum processo de negócio.
O Modelo de Análise deve conter os detalhes necessários para servir da base para o
desenho do produto, no início são elaborados os casos de uso. Estes juntamente com as
descrições dos casos de uso formam uma espécie de ponte funcional entre o processo de
negócio e a solução de software a ser produzida. Também outros dois documentos podem ser
usados como fontes complementares aos casos de uso na análise OO: Glossário e documento
de arquitetura.
Trata-se de analisar o sistema e desenvolver um conjunto de modelos gráficos de

sistema, como modelos de casos de uso, que, então, servem como uma especificação
do sistema. O conjunto de modelos descreve o comportamento do sistema e é
anotado com informações adicionais, descrevendo, por exemplo, o desempenho ou a
confiabilidade requerida do sistema. (SOMMERVILLE, Pag. 69, 2011).
Análise de Negócios e o conjunto de atividades e técnicas utilizadas para servir

como ligação entre as partes interessadas, no intuito de compreender a estrutura,
políticas e operações de uma organização e para recomendar soluções que permitam
que a organização alcance suas metas. Análise de Negócios envolve compreender
como as organizações funcionam e alcançam seus propósitos, e definir as
capacidades que uma organização deve possuir para prover produtos e serviços para
as partes interessadas externas. (Guia Babok - INTERNATIONAL INSTITUTE OF
BUSINESS ANALYSIS (IIBA), Pág. 5, 2011)
4.1 Engenharia de Requisitos
A engenharia de requisitos é um processo que engloba todas as atividades que

contribuem para a produção de um documento de requisitos, pelo qual os requisitos de um
produto de software são coletados, analisados, documentados e gerenciados ao longo de todo
o ciclo de vida do software.
Antes de iniciar qualquer trabalho técnico, é uma boa ideia aplicar um conjunto de
tarefas de engenharia de requisitos. Estas levam a um entendimento de qual será o
impacto do software sobre o negócio, o que o cliente quer e como os usuários finais
irão interagir com o software. (PRESSMAN, 2011, Pág. 126)
11
Também de acordo com Pressman (2011, p. 127), os requisitos são na verdade uma
ponte entre o projeto e a construção do sistema, é um processo que identifica as necessidades
do negócio e as restrições do projeto, ou seja, com os requisitos é possível que o
desenvolvimento do sistema tenha um ponto de partida.
4.2 Requisitos e Classificação dos Requisitos
De acordo com Paula Filho (2000, P.13) - Os requisitos são as características que
definem os critérios de aceitação de um produto. A engenharia tem por objetivo colocar nos
produtos as características que são requisitos. Os Requisitos são além de funções, objetivos,
propriedades, restrições que o sistema deve possuir para satisfazer contratos, padrões ou
especificações de acordo com o(s) usuário(s). De forma mais geral um requisito é uma
condição necessária para satisfazer um objetivo.
Existem dois tipos de classificação de requisitos: Requisitos Funcionais (RF) e
Requisitos Não-Funcionais (RNF).
1. Requisitos Funcionais (RF): Preocupam-se com a funcionalidade e os
serviços do sistema, ou seja, as funções que o sistema deve fornecer para o
cliente e como o sistema se comportará em determinadas situações
2. Requisitos Não-Funcionais (RNF): Definem propriedades e restrições do
sistema como tempo, espaço, linguagens de programação, versões do
compilador, SGBD, Sistema Operacional, método de desenvolvimento etc .
Estão divididos em três categorias:
 Requisitos de Processo: Os requisitos de processo são restrições que
estão relacionadas com o processo de desenvolvimento do sistema;
 Requisitos de Produto: Os requisitos de produto são restrições que
especificam as características desejadas que o sistema deve fornecer;
 Requisitos Externos: Os requisitos externos são restrições derivadas
do local que o sistema está sendo desenvolvido.
4.3 Regras de Negócios (RN)

12
As regras de negócio (RN) são premissas e restrições aplicadas a uma operação

comercial de uma empresa, que precisam ser atendidas para que o negócio funcione da
maneira esperada. As regras de negócio definem como o sistema fará o atendimento às
necessidades/exigências definidas. As restrições, validações, condições e exceções do
processo são exemplos clássicos de regras de negócio.
As regras de negócio (RN) definem a forma de fazer o negócio baseado nas seis
perspectivas de um processo de negócio , conhecido como 5W1H : O QUE, ONDE,
QUANDO, POR QUE e COMO será feito, refletindo a política interna, o processo definido
e/ou as regras básicas de comportamento de conduta, ou seja, é um conjunto de instruções que
os usuários já seguem e que o sistema a ser desenvolvido deve contemplar.
4.4 Método de Modelagem de Processos de Negócios
A modelagem de sistema auxilia o analista a entender a funcionalidade do sistema e

os modelos são usados para se comunicar com os clientes.
Modelagem de sistema é o processo de desenvolvimento de modelos abstratos de

um sistema, em que cada modelo apresenta uma visão ou perspectiva, diferente do
sistema. A modelagem de sistema geralmente representa o sistema com algum tipo
de notação gráfica, que, atualmente, quase sempre é baseada em notações de UML
(linguagem de modelagem unificada, do inglês Unified Modeling Language).
(SOMMERVILLE, 2011, pag.96)
UML (Unified Modeling Language – linguagem de modelagem unificada) é “uma

linguagem-padrão para descrever/documentar projeto de software. A UML pode ser
usada para visualizar, especificar, construir e documentar os artefatos de um sistema
de software-intensivo” (BOOCH; RUMBAUGH; JACOBSON, 2005).
Ela surgiu em 1994 da fusão de três grandes métodos de modelagem: o método de

Booch, o método OMT (Object Modeling Technique) de Jacobson, e o método OOSE
(Object-Oriented Software Engineering) de Rumbaugh.
A UML permite que você "desenhe" uma "planta" do seu sistema. Não é um método
de desenvolvimento, é uma linguagem de modelagem única, comum e amplamente utilizável,
que possui como objetivos:
 Auxiliar na análise e desenvolvimento de sistemas orientados a objetos,
computacionais ou não;
 Aumentar a produtividade;
13
 Otimizar as etapas que envolvem o desenvolvimento de um sistema,

aumentando assim a qualidade do produto a ser implementado.
Ela independe da ferramenta em que o aplicativo será desenvolvido. A ideia e prover

uma visão lógica de todo o processo de forma a facilitar a implementação física do mesmo. O
objetivo então é descrever "o que fazer", "como fazer", "quando fazer" e "porque deve ser
feito". É necessária a elaboração completa de um dicionário de dados, para descrever todas as
entidades envolvidas, refinando, com isso, os requisitos funcionais de um aplicativo ou
projeto de software.
A UML é composta de vários tipos de diagramas que são usados para demonstrar,
graficamente, o funcionamento do sistema e apoia a criação de muitos tipos de diferentes
modelos de sistema. Segundo uma pesquisa em 2007 (ERICKSON e SIAU, 2007), citado por
Sommerville (2011, p. 83), mostrou que a maioria dos usuários de UML acredita que cinco
tipos de diagramas podem representar a essência de um sistema:
1. Diagramas de atividades, que mostram as atividades envolvidas em um
processo ou no processamento de dados.
2. Diagramas de casos de uso, que mostram as interações entre um sistema e seu
ambiente.
3. Diagramas de sequência, que mostram as interações entre os atores e o
sistema, e entre os componentes do sistema.
4. Diagramas de classe, que mostram as classes de objeto no sistema e as
associações entre elas.
5. Diagramas de estado, que mostram como o sistema reage aos eventos
internos e externos.
4.4 Modelagem de Casos de Uso
O Diagrama de Caso de Uso na UML é um diagrama comportamental que tem como

objetivo descrever como será o uso de uma funcionalidade de um sistema, representando
como os casos de uso interagem entre si no sistema e com os usuários (atores), ou seja, como
as funcionalidades se relacionarão umas com as outras e como serão utilizadas pelo
usuário, durante o uso do sistema.
14
No diagrama de caso de uso, basicamente temos três principais elementos:

1. Ator (o bonequinho) - Um ator é quem fará a execução do caso de uso (quem
executará a funcionalidade que está especificada no caso de uso). Atores
podem ser de dois tipos: humano e sistêmico.
2. Casos de uso - Um caso de uso, como elemento num diagrama, é a elipse (ou
bolinha). O que tem “dentro da bolinha” são fluxos (ou cenários). Os
fluxos compõem a especificação do caso de uso, “o que tem dentro da
bolinha”.
3. Relacionamentos (as setas que ligam os casos de uso entre si e ligam os
usuários aos casos de uso). Casos de uso relacionam entre si (isso não é
obrigatório, podemos ter casos de uso que não são chamados por outros, nem
chamam outros casos de uso). Na especificação da UML são definidos alguns
tipos de relacionamento para casos de uso, mas os três principais
relacionamentos são: Inclusão (Include), Extensão (Extends) e Herança
(Generalization).
4.5 Paradigma da Programação Orientada a Objetos
O desenvolvimento de software é extremamente amplo. No mercado atual, existem

diversas linguagens de programação, que seguem diferentes paradigmas. Um desses
paradigmas é a Orientação a Objetos, que consiste na construção de módulos independentes
ou objetos que podem ser facilmente substituídos, modificados e reutilizados. O Principal
diferencial desse paradigma está na tentativa de aproximar o software do mundo real.
Um sistema orientado a objetos é composto de objetos interativos que mantêm seu

próprio estado local e oferecem operações nesse estado. A representação do estado é
privada e não pode ser acessada diretamente, de fora do objeto. Processos de projeto
orientado a objetos envolvem projetar as classes de objetos e os relacionamentos
entre essas classes. Essas classes definem os objetos no sistema e suas interações.
Quando o projeto é concebido como um programa em execução, os objetos são
criados dinamicamente a partir dessas definições de classe. Sistemas orientados a
objetos são mais fáceis de mudar do que os sistemas desenvolvidos com abordagens
funcionais. (SOMMERVILLE, 2011, pag.139)
Os pilares da Programação Orientada a Objetos (POO):

 Classe: Representação de um conjunto de objetos com características afins.
Definição do comportamento dos objetos (métodos) e seus atributos.
15
 Objeto é uma instancia de uma classe. Armazenamento de estados através de

seus atributos e reação a mensagens enviadas por outros objetos.
 Abstração: consiste em um dos pontos mais importantes dentro de qualquer
linguagem Orientada a Objetos. Como estamos lidando com uma
representação de um objeto real (o que dá nome ao paradigma), temos que
imaginar o que esse objeto irá realizar dentro de nosso sistema. São três
pontos que devem ser levados em consideração nessa abstração: identidade,
propriedades e métodos;
 Encapsulamento: Proibição do acesso direto ao estado de um objeto,
disponibilizando apenas métodos que alterem esses estados na interface
pública.
 Herança: Mecanismo pela qual uma classe (sub-classe) pode estender outra
classe (superclasse), estendendo seus comportamentos e atributos.
 Polimorfismo: Princípio pelo qual as instancias de duas classes ou mais
classes derivadas de uma mesma superclasse podem invocar métodos com a
mesma assinatura, mas com comportamentos distintos.
4.6 Diagrama de Classes
O diagrama de classes ilustra graficamente como será a estrutura do software (em

nível micro ou macro e como cada um dos componentes da sua estrutura estarão interligados.
Um diagrama de classe é composto por entidades e seus relacionamentos. Suas
entidades podem ser divididas entre classes e interfaces. A forma de classe em si consiste em
um retângulo com três linhas. A linha superior contém o nome da classe, a linha do meio, os
atributos da classe e a linha inferior expressa os métodos ou operações que a classe pode
utilizar. Classes e subclasses são agrupadas juntas para mostrar a relação estática entre cada
objeto.
Elementos do diagrama de classes:
 Associação: Representa possíveis ligações entre os objetos das classes
envolvidas.
 Multiplicidade: Especifica o número de objetos aos quais outro objeto pode
se associar.
16
 Agregação: É uma forma especial de associação que indica que dois objetos
estão ligados por um relacionamento parte-todo.
 Composição: É uma forma de agregação com duas restrições adicionais: Um
objeto constituinte (parte) pode pertencer a no máximo um objeto composto
(todo). O objeto constituinte (parte) tem um tempo de vida coincidente com o
objeto composto (todo).
 Generalização/Especialização: É o relacionamento entre uma classe (a
superclasse) e uma ou mais variações da classe (as subclasses). Também
chamado de Herança
4.6.1 Técnicas para Identificação de Classes
De acordo com técnica de identificação a Análise de Robustez, os objetos que

compõem um SSOO podem ser divididos em três categorias (categorização de BCE): objetos
de fronteira (boundary), objetos de controle (control) e objetos de entidade (entity). Essa
categorização fornece uma espécie de “arcabouço” que podemos tomar como ponto de partida
para a identificação de classes em cada caso de uso de um sistema. A categorização BCE
implica que cada objeto é especialista em realizar um dos três tipos de tarefas: Comunica-se
com os atores (fronteira), manter as informações (entidade) e coordenar a realização de um
caso de uso (controle).
5 BANCO DE DADOS
Para entender melhor o que é um banco de dados, antes precisamos compreender a

diferença entre as palavras “dados” e “informações”. Dado é um conteúdo de fatos em forma
bruta, em sua forma primária, e que podem não fazer nenhum sentido quando estão isolados.
As informações são o agrupamento de dados organizados, é o processamento de dados de
forma que façam sentido e gerem algum conhecimento. A informação sempre é gerada com
base nos dados.
Segundo Korth et al. (1999), um banco de dados “é uma coleção de dados inter-
relacionados, representando informações sobre um domínio específico”, ou seja, sempre que
for possível agrupar informações que se relacionam e tratam de um mesmo assunto, podemos
dizer que temos um banco de dados.
17
O Bancos de dados existe normalmente para serem utilizados por aplicações, são elas
que realizam consultas e fazem alterações nos dados. O termo “banco de dados” também é
usado para definir uma base de dados, que é um grupo de dados agrupados por um SGBD.
O Sistema Gerenciador de Banco de Dados (SGDB) é um software responsável por
manter os bancos de dados que estão sob sua responsabilidade. Possui recursos capazes de
manipular as informações do banco de dados e interagir com o usuário. O SGBD usa uma
linguagem para criar a base de dados, sendo que, atualmente, a mais usada é a SQL
(Structured Query Language). São vários os SGBDs disponíveis no mercado; alguns são
pagos e outros gratuitos. Exemplos Alguns dos tipos de SGBD existentes no mercado
são: Oracle, SQL Server, DB2, PostgreSQL, MySQL, Casandra, entre outros.
A estrutura de um banco de dados é formando por uma ou mais tabelas. As tabelas
são locais onde os dados ficam logicamente armazenados. As colunas são campos que
armazenam um determinado tipo de dado e os registros são linhas, que de uma forma mais
resumida, pode-se dizer que são conjuntos de campos preenchidos.
No mercado existem alguns tipos de banco de dados: Relacionais, Não Relacionais e
Orientados a Objetos.
Os objetivos de um sistema de banco de dados são o de isolar o usuário dos detalhes
internos do banco de dados (promover a abstração de dados) e promover a independência dos
dados em relação às aplicações, ou seja, tornar independente da aplicação, a estratégia de
acesso e a forma de armazenamento.
5.1 Modelo de Diagrama de Entidade de Relacionamento
O Modelo Entidade Relacionamento (MER) é um modelo conceitual de alto-nível,

ou seja, é projetado para ser compreensível aos usuários comuns. O MER é o que você quer
fazer efetivamente, é a ferramenta para criar modelos de dados e seus relacionamentos.
Utilizado na Engenharia de Software para descrever os objetos (entidades) envolvidos em um
domínio de negócios, com suas características (atributos) e como elas se relacionam entre si
(relacionamentos). O MER é abstrato, é só um conceito, podemos dizer que ele só existe no
pensamento, embora você possa colocá-lo no papel de forma desorganizada. Dentro do MER
utilizamos algumas formas geométricas para expressar graficamente a lógica estrutural de um
banco de dados:
 Retângulo: representa as entidades;
18
 Elipse: atributos das entidades;

 Losangos: identifica os relacionamentos entre as entidades;
 Linhas: utilizado para ligar atributos à entidades e relacionamentos com
as entidades.
6 PROJETO ANÁLISE DO SISTEMA GERENCIADOR DE ESTOQUE E VENDAS
6.1 Introdução
Em um sistema desktop, a documentação garante um melhor desempenho do

desenvolvimento e na manutenção, possibilitando que seja proposto para conduzir sua
implementação. O presente documento tem como objetivo detalhar as funcionalidades do
sistema
6.2 Escopo do Produto

6.2.1 Nome do Produto
O Sistema de Controle e Gerenciamento de Loja de Jogos e Produtos Geeks será um

sistema personalizado.
6.2.2 Objetivo
O objetivo do Sistema de Controle e Gerenciamento de Loja de Jogos e Produtos

Geeks, é sistematizar o gerenciamento do estabelecimento, informatizando os processos de
atendimento e manutenção; de forma que o usuário interaja facilmente com um sistema
confiável adaptado ao ambiente em questão. O sistema será executado diretamente nos
computadores da empresa. E permitirá o gerenciamento das vendas realizadas pelo
estabelecimento, cadastros dos funcionários, fornecedores e clientes, gerenciamento de
produtos e estoque. Dessa forma facilitando o gerenciamento da empresa.
19
6.2.3 Limites do Produto
A tabela abaixo representa as limitações do software.
Tabela 1- Limites do Produto

Número Limite
1 Não fará vendas parceladas e só receberá dinheiro ou cheque.
2 Só fará a Emissão de Nota Fiscal durante a Operação de Venda.
3 O backup e a recuperação das bases de dados do sistema ficam a cargo da
administração de dados do cliente, e não serão providas pela empresa de
desenvolvimento do sistema.
4 Não terá ajuda on-line, mas apenas um manual de uso.
5 Será utilizada uma impressora específica para a emissão dos tickets de venda,
configurável como impressora suportada pelo ambiente operacional.
Fonte: Elaborado pelo Autor (2020).
6.2.4 Benefícios Esperados do Produto
A tabela abaixo representa os benefícios que são esperados do software.
Tabela 2- Benefícios Esperados do Produto

Número Benefício Valor para o
cliente
1 Diminuição de erros na venda de mercadorias Essencial
2 Qualidade na emissão da nota fiscal e ticket de venda, em Essencial
relação à emissão manual.
3 Identificação de distorções entre o vendido e o estoque. Desejável
4 Agilidade na compra de mercadorias. Desejável
5 Economia de mão-de-obra. Desejável
6 Diminuição do custo de estocagem. Desejável
7 Identificação de produtos mais e menos vendidos. Desejável
6.2.5 Especificação de Ambiente
De modo a atender os objetivos de usabilidade, o sistema deve ser usado em um

ambiente que esteja em conformidade com os padrões relevantes de ergonomia, em particular:
 ISO 9241 -5, layout do posto de trabalho e requisitos de postura.
 ISO 9241 -6, requisitos de ambiente.
20
6.2.6 Especificação de Equipamentos
As configurações descritas são válidas para ambientes com até 10 terminais, acima
disto, as configurações do servidor devem aumentar de maneira proporcional a quantidade de
terminais.
Para modalidade de instalação e utilização Local Desktop, são necessários os
requisitos de hardware e redes abaixo:
Tabela 3 – Especificação de Requisitos de Equipamentos

Requisitos Servidores Terminais (Estações)
Processador: Quad-Core ou superior Dual Core (mínimo)
Espaço em disco: 80GB 30GB
(recomendado HD SSD – 240GB
somente para os sistemas)
Memória RAM: 8GB 4GB
(recomendado 16GB)
Sistema Operacional: Windows 10 Pro Windows 10 ou superior (as
(recomendado Windows Server 2012 edições Starter e Home não estão
ou superior) - Obrigatoriamente 64 homologadas)
bits.
Rede: 100/1000 100/1000
6.3 Detalhamento dos Requisitos
Diferente de um software de base (prateleira) será um software feito com

levantamento de requisitos afim de que se comporte apenas para as necessidades e funções da
empresa, e reforçando a ideia de ter um melhor planejamento e controle dos produtos e das
vendas quando se utiliza um sistema de informação.
6.3.1 Requisitos Funcionais (RF)
Especificaremos aqui as ações que o Sistema de Gerenciamento Estoque e Vendas de

Lojas de Jogos Eletrônicos, Acessórios e Produtos Geeks, será capaz de executar, sem levar
em considerações restrições físicas, especificando o comportamento de entrada e saída do
sistema
21
Tabela 4– Especificação de Requisitos Funcionais (RF)

Cód. Nome Descrição Categoria
Os produtos são qualquer jogos ou acessórios disponíveis na loja.

Para cadastrar um novo produto, o usuário deverá informar o nome
e o tipo do produto;
Gerenciamento dos
RF01 Para consultar ou alterar as informações de um produto, o usuário Evidente
produtos
deverá informar o nome ou código do produto e em caso de
atualização dos dados, preencher os campos do formulário
relacionados às alterações desejadas;
Os produtos cadastrados no sistema serão classificados em

Gerenciamento das categorias as quais serão utilizadas para a distinção entre os
RF02 Evidente
categorias de produtos mesmos; para adicionar uma nova categoria de produto, o usuário
deverá informar o nome e a descrição da nova categoria;
Os clientes serão todas as pessoas que adquirirem algum produto

oferecido pela loja.
Gerenciamento dos
RF03 O sistema permitirá o cadastro e a manutenção dos dados dos Evidente
dados dos clientes
clientes a fim de manter informações acerca das características e
principais modalidades de compras do mesmo.
O sistema gerenciará a quantidade de itens existentes no estoque

RF04 Controle do estoque para indicar a necessidade de complemento do mesmo e disposição Oculto
de itens à venda.
Controle do movimento Ao início e fim de cada expediente, o sistema calculará os valores

RF05 Evidente
de caixa de entrada e saída para cálculo do movimento diário do caixa.
O sistema permitirá o cadastro dos funcionários da loja a fim de

controlar os dados dos mesmos.
Para inserir um novo funcionário no sistema, o usuário deverá
Gerenciamento dos preencher o formulário de cadastro, informando os devidos
RF06 Evidente
dados dos funcionários campos.
Para realizar a atualização dos dados, o usuário deverá localizar o
funcionário através de sua matrícula e preencher os campos dos
dados a serem alterados.
Os fornecedores dos produtos da loja poderão ser cadastrados no

sistema para controle de entrada dos produtos, formas de contato e
Gerenciamento dos
RF07 possíveis acarretamentos de responsabilidades. Evidente
dados dos fornecedores
Para cadastrar um fornecedor, o estoquista deverá preencher
corretamente o formulário e confirmar a operação.
22
Os Vendedores ( Operadores de Caixas) cadastrados têm

permissão para efetuar vendas de produtos oferecidos pela loja e
disponíveis em estoque.
Gerenciamento e
RF08 Para efetuar uma venda, o operador deverá informar o(s) Evidente
controle das vendas
produto(s), confirmar o pagamento e efetuar o registro da venda.
Toda venda realizada com sucesso será registrada na base de
dados.
6.3.2 Requisitos Não funcionais (RFN)
Apresentaremos aqui os requisitos que descrevem os atributos do sistema e do

ambiente do sistema.
Tabela 5– Especificação de Requisitos Não Funcionais (RFN)

Cód. Nome Descrição Categoria
RFN01 Plataforma Windows Desejável
RFN02 SGBD SQL Server Desejável
O acesso ao sistema só poderá acontecer mediante a

autenticação do usuário. O sistema deverá conter
RFN03 Segurança Obrigatório
conteúdos restritos que só poderão estar acessíveis
aos usuários detentores de permissão.
O sistema garantirá que somente pessoas

Autenticação de
RFN04 previamente cadastradas pelo gerente acessem ao Evidente
usuários
sistema.
O sistema garantirá que o seu conteúdo seja

Gerenciamento de acessado de acordo com o nível de permissão do
RFN05 Evidente
níveis de acesso usuário, evitando que usuários comuns acessem
conteúdo restrito.
Performance - O sistema deverá suportar a carga de até 50 acessos

RFN06 Desejável
Concorrência simultâneos.
Usabilidade - Interface O sistema deverá prover uma interface com o

RFN07 Evidente
com o Usuário usuário que seja intuitiva, prática e fácil de usar.
Requisitos de
RFN08 desempenho tempo de O tempo máximo de qualquer transação não deve Desejável
resposta ultrapassar 5 segundos.
23
6.3.3 Regras de Negócios
A tabela abaixa descreve as regras de negócios da empresa.
Tabela 6– Especificação de Requisitos Não Funcionais (RFN)

Cód. Nome Descrição
Login de Usuário: Todo acesso ao sistema deverá ser realizado por
RN01 Acesso ao Sistema
meio de Login e senha de Usuário.
Os cadastros devem possuir campos de preenchimento
obrigatórios. E o usuário deverá preencher todos os campos para
conseguir concluir os cadastros.
Todos os produtos devem possuir: código de barras, nome do
RN02 Cadastros de Produtos
produto, categoria, fabricante,
quantidade e valor do produto. Para os jogos e os acessórios,
devem ser informados em qual plataforma serão utilizados e qual o
prazo de garantia que o produto possui.

RN03 Cadastros de Clientes conseguir concluir os cadastros.
Os cadastros dos clientes devem possuir: código, RG, CPF, nome,
data do cadastro, endereço, telefone e e-mail do cliente.

RN04 Cadastros de Categorias
conseguir concluir os cadastros.
Tipos - divididos por categorias: jogos, acessórios e produtos geek.
No processo de vendas: A venda deverá possuir os dados do

cliente e todos os produtos adquiridos. Deverá ser gerado um
RN05 Operação de Vendas código único da venda, com a data da venda, o valor da venda,
opções para pagamento (dinheiro/cartão), o status de pagamento e
o status da venda.
O atendente poderá consultar os preços dos produtos caso o cliente

RN06 Consulta de Preços
solicite
No processo de vendas, caso seja necessário o cancelamento da

RN07 Cancelamento de Vendas venda, a mesma somente poderá ser realizada pelo supervisor da
loja, que deve informar usuário e senha válidos.
No processo de vendas, caso seja necessário a exclusão de

RN08 Exclusão de itens na Venda produtos, a mesma somente poderá ser realizada pelo supervisor da
loja, que deve informar usuário e senha válidos.
24
6.4 Mapa Mental
A figura 1 ilustra o mapa mental com as funcionalidades do sistema Gerenciador de

Estoque e Vendas.
Figura 1 - Mapa mental de visão geral do sistema.
6.5 Lista de Eventos
Para modelagem do sistema foi determinado uma lista de eventos. A seguir são
descritos os eventos relacionados as necessidades encontradas:
Tabela 7- Lista de Eventos
Lista de Eventos
Nº Nome do Evento
1 Efetuar Login
2 Cadastrar Produto
3 Cadastrar Categoria
4 Cadastrar Funcionário
5 Cadastrar Cliente
6 Efetuar Compra
7 Efetuar Venda
8 Alimentar Quantidade de Produto
9 Relatório de Clientes
10 Relatório de Produtos
11 Consultar Clientes
12 Consultar Funcionário
25
13 Consultar Produto
14 Alterar Cliente
15 Alterar Produto
16 Alterar Funcionário
17 Excluir Cliente
18 Excluir Funcionário
19 Excluir Fornecedor
20 Desabilitar Funcionário
6.6 Diagrama de Caso de Uso
6.6.1 Caso de Uso Geral do Sistema
A figura 2 ilustra o caso de uso geral do sistema Gerenciador de Estoque e Vendas.
Figura 2 - Caso de Uso Geral do Sistema

26
6.6.2 Caso de Uso – UC1 - Manter Funcionário
Figura 3 - Caso de uso manter funcionário.

27
Tabela 8 - Caso de uso manter funcionário.

Código Caso de Uso UC1
Nome do Caso de Uso Manter funcionário.
Funcionalidade/Objetivo Permitir o Supervisor/Gerente cadastrar, consulta, alterar e excluir os funcionários
no sistema
Ator(es) Supervisor/Gerente
Pré-Condição O Supervisor/Gerente deverá estar autenticado no sistema
Fluxo Principal 1 – O sistema solicita os dados necessários para o cadastro do funcionário.
2 – O Supervisor/Gerente informa os dados de acordo com os campos a serem
preenchidos.
3 – O sistema solicita os dados para o cadastro da função. [A1]
4 – O Supervisor/Gerente informa os dados necessário. [A2]
5 – O Supervisor/Gerente seleciona a opção “Cadastrar”.
6 – O sistema emite a mensagem “Funcionário Cadastrado com Sucesso”.
7 – O sistema cadastra o funcionário.
Fluxo Alternativo A1 - O Supervisor/Gerente não informar os dados para o cadastro da função, o
sistema informa que o funcionário não está cadastrado.
A2 - O Supervisor/Gerente poderá cancelar o processo durante o cadastro.
A3. Se o funcionário existir o usuário pode alterar os seus dados.
A4. O funcionário pode ser removido.
A5 o usuário pode consultar os dados do funcionário.
6.6.3 Caso de Uso – UC2 – Efetuar Login
Figura 4 - Caso de uso efetuar login.
Tabela 9 - caso de uso efetuar login.

28
Nome do Caso de Uso Efetuar Login

Funcionalidade/Objetivo Permitir o Supervisor/Gerente e funcionário se autenticar no sistema com suas
credenciais.
Ator(es) Supervisor/Gerente e Funcionário
Pré-Condição 1. O usuário precisa de um usuário e uma senha cadastrado.
2. O usuário se autentica no sistema.
Fluxo Principal 3. O ator preenche os dados de login e o sistema carrega todo o menu.
Fluxo Alternativo 4. O usuário pode cancelar.
5. Se os dados não confirmarem o sistema exibe uma mensagem “usuário ou
senha inválidos”
Caso o usuário não se lembre de sua senha, ele poderá recuperá-la.
6.6.4 Caso de Uso – UC3 – Gerenciar Relatórios
Figura 7 - Caso de uso Gerenciar Relatórios.
Tabela 10 - Caso de uso gerenciar relatórios.

Nome do Caso de Uso Gerenciar Relatórios
Funcionalidade/Objetivo Permitir o Supervisor/Gerente gerar relatórios dos produtos, vendas e compras
Ator(es) Supervisor/Gerente
Pré-Condição 1. O usuário se autentica no sistema.
2. O usuário seleciona relatórios.
3. O usuário escolhe o tipo de relatórios.
Fluxo Principal 4. O ator preenche escolhe a opção e os campos.
5. O sistema carrega os dados do relatório.
Fluxo Alternativo 6. O usuário pode cancelar o relatório.
6.6.5 Caso de Uso – UC4 – Manter Cliente
Figura 8 - Caso de uso manter cliente.

29
Tabela 11 - Caso de uso manter cliente.

Nome do Caso de Uso Manter Cliente
Funcionalidade/Objetivo Inserir, alterar, excluir e pesquisar cliente
Ator(es) Funcionário
Pré-Condição O funcionário deverá estar autenticado no sistema.
Fluxo Principal 1 – O sistema solicita os dados necessários para o cadastro do cliente.
2 – O funcionário informa os dados de acordo com os campos a serem
preenchidos (
código, RG, CPF, nome, data do cadastro, endereço, telefone e e-mail do cliente)
4 – O funcionário informa os dados necessário. [A2]
5 – O Funcionário seleciona a opção “Cadastrar”.
6 – O sistema emite a mensagem “Cliente Cadastrado com Sucesso”.
7 – O sistema cadastra o cliente.
Fluxo Alternativo A1 – O funcionário não informar os dados para o cadastro da função, o sistema
informa que o cliente não está cadastrado.
A2 – O funcionário poderá cancelar o processo durante o cadastro.
6.6.6 Caso de Uso – UC5 – Manter Fornecedor
Figura 9 - Caso de uso manter fornecedor.
Tabela 12 - Caso de uso manter fornecedor.

Nome do Caso de Uso Manter fornecedor.
30
Funcionalidade/Objetivo Permitir o Supervisor/Gerente e funcionário cadastro, consulta, alteração e

exclusão dos fornecedores do sistema.
Ator(es) Supervisor/Gerente e Funcionário
Pré-Condição 1. O usuário se autentica no sistema.
Fluxo Principal 2. O usuário seleciona fornecedor.
3. O ator preenche os dados específicos dos materiais e confirma para consultar.
Fluxo Alternativo. 4. O fornecedor pode ser cadastrado.
5. O pode haver alteração no fornecedor.
6. O fornecedor pode ser excluído
6.6.7 Caso de Uso – UC6 – Manter Produto
Figura 10 - Caso de uso manter produto.
Tabela 13 - Caso de uso manter produto.

Nome do Caso de Uso Manter produto.
Funcionalidade/Objetivo Inserir, alterar, excluir e pesquisar produtos
Ator Funcionário
Pré-Condição O funcionário deverá estar autenticado no sistema
Fluxo Principal 1 – O sistema solicita os dados necessários para o cadastro do produto.
2 – O funcionário informa os dados de acordo com os campos a serem preenchidos
(todos os produtos devem possuir: código de barras, nome do produto, categoria,
fabricante, quantidade e valor do produto. Para os jogos e os acessórios, devem ser
informados em qual plataforma serão utilizados e qual o prazo de garantia que o
produto possui
5 – O funcionário seleciona a opção “Cadastrar”.
6 – O sistema emite a mensagem “Produto Cadastrado com Sucesso”.
7 – O sistema cadastra o produto.
Fluxo Alternativo A1 – Se o funcionário não informar os dados para o cadastro da função, o sistema
informa que o produto não está cadastrado.
6.6.8 Caso de Uso – UC7 – Manter Compra
Figura 11: Caso de uso manter compra.

31
Tabela 14 - Caso de uso manter compra.

Nome do Caso de Uso Manter de Compra
Funcionalidade/Objetivo Permitir o funcionário registrar notas de entrada de produtos no sistema.
Ator(es) Funcionário
Pré-Condição 1. O usuário precisa se autentificar.
2. O usuário seleciona compras.
3. O usuário precisa de produtos e fornecedores cadastrados
Fluxo Principal 4. O ator preenche os dados específicos dos materiais que foram comprados e
confirma.
Fluxo Alternativo 5. O usuário pode cancelar.
6.6.9 Caso de Uso – UC8 – Manter Venda
Figura 12: Caso de uso manter venda.
Tabela 15 - Caso de uso manter venda.

Nome do Caso de Uso Manter de Venda
Funcionalidade/Objetivo Permite ao funcionário fornecer informações para a movimentação de
vendas.
Ator Funcionário
Fluxo Principal 1 – O sistema solicita os dados necessários para movimentar vendas.
2 – O funcionário informa os dados de acordo com os campos a serem
preenchidos.
32

4 – O funcionário informa os dados necessários.
5 – O funcionário seleciona a opção “Salvar”.
6 – O sistema emite a mensagem “Operação Realizada com Sucesso”.
Fluxo Alternativo A1 – O funcionário poderá cancelar o processo durante a
movimentação.
A2 - o funcionário poderá excluir produtos da venda caso o cliente não
queira mais adquiri-los. Apenas o supervisor da loja poderá excluir o
produto da venda, devendo informar
um usuário e senha válidos
A3 - A venda pode ser cancelada apenas pelo supervisor da loja, que
deve informar usuário e senha válidos. No momento do cancelamento,
o código da venda deve ser enviado para o sistema financeiro.
6.6.10 Caso de Uso – UC9 – Consultar Preços
Figura 13: Caso de uso Consultar Preços
Tabela 16 - Caso de uso Consultar Preços

Nome do Caso de Uso Consultar Preços
Funcionalidade/Objetivo Permite ao funcionário consultar preços dos produtos
Ator Funcionário
Pós-Condição O funcionário tem o resultado da consulta
Fluxo Principal 1 - O funcionário para pesquisar deve preencher no campo de filtro algum dado
do produto cadastrado como: Código, descrição ou código de barras, e apertar o
botão pesquisar.
2 - O sistema utiliza do dado fornecido para consultar no
sistema de controle de estoque: quantidade disponível, valor e prazo de garantia.
3- O sistema mostra em tela o resultado da consulta.
Fluxo Alternativo 1 - Caso o cliente pressione o botão e não forneça nenhum dos campos Código,
descrição ou código de barras, exibir mensagem que é obrigatório
preenchimento de 1 dos campos.
2. Caso não localize nenhum produto, exibir uma mensagem “Produto não
cadastrado”.
33
6.6.11 Caso de Uso – UC10 – Manter Categorias de Produtos
Figura 14: Caso de uso Manter Categorias de Produtos
Tabela 17 - Caso de uso Manter Categorias de Produtos

Nome do Caso de Uso Manter Categorias de Produtos
Funcionalidade/Objetivo Inserir, alterar, excluir e pesquisar produtos
Ator Funcionário
Fluxo Principal 1 – O sistema solicita os dados necessários para o cadastro da categoria.
2 – O funcionário informa os dados de acordo com os campos a serem preenchidos.
Deverão ser divididos por categorias: jogos, acessórios e produtos geek
5 – O funcionário seleciona a opção “Cadastrar”.
6 – O sistema emite a mensagem “Categoria Cadastrada com Sucesso”.
7 – O sistema cadastra o produto.
Fluxo Alternativo A1 – Se o funcionário não informar os dados para o cadastro da função, o sistema
informa que o produto não está cadastrado.
6.6.12 Atores do Caso de Uso
Tabela 18 – Atores Caso de uso

Ator Descrição
Supervisor/Gerente O ator é responsável pelas atividades de nível administrativo, tais como:
controle de funcionários, cadastramento de funcionários, Emissão de
relatórios gerenciais e controles, e autorização de cancelamento de vendas
por isso possui nível de acesso alto.
Vendedor/Operador de Caixa O ator é responsável pelas atividades de nível mais baixo na organização e
por isso possui nível de acesso baixo. Ele é responsável pelas práticas de
vendas, cadastramento clientes.
Estoquista/Compras O ator é responsável pelas atividades de nível mais baixo na organização e
por isso possui nível de acesso baixo. Ele é responsável pelo gerenciamento
de estoque, compras, cadastros dos produtos.
34
6.7 Diagrama de Classes
Na etapa de elaboração do diagrama de Classe, foram a plicadas a s técnicas

aprendidas de análise do cenário proposto, a fim de identificar todos os insumos necessários
para a construção do diagrama: identificação de classes, lista de classes Candidatas para
eleger as classes finais, identificação de relacionamentos e construção do diagrama de classes.
Na sequência foram identificado s os atributos com base nas características vinculadas às
classes eleitas e por fim, identificação do s método s baseados nas ações a serem realizadas
pela classe e seus atributos. A figura abaixo apresenta a construção do diagrama, com a
ferramenta Astah Professional UML com licença para estudante, considerando o cenário
proposto. Esta representação deve subsidiar o desenvolvimento no que tange a estrutura e
relações das classes que os objetos de vem desempenhar no sistema.
Figura 15: Diagrama de Classes

35
A classe Funcionário é a base de operação no sistema que se relaciona com todo o

software, cadastrando produtos, clientes, fornecedores e realizando as operações de compras e
vendas. E conforme o caso apresentado, ao realizar o cancelamento de uma venda a classe
financeiro recebe os dados do código da venda cancelada, sendo essa identificada com
estereótipo <<interface> > por justamente ser uma classe “externa” que se comunica ao
sistema proposto. As classes foram marcadas com estereótipo <<CRUD > >, acrônimo da
expressão do idioma inglês, Create (Criação), Read (Consulta), Update (Atualização) e delete
(Deletar), as quatro operações básicas usadas em Banco de Dados Relacionais.
6.8 Modelo Entidade de Relacionamento (MER)
Os Modelos Conceitual e Lógico MER foram criados na ferramenta online Draw.io1.
6.8.1 Modelo Conceitual
Figura 16: Modelo Conceitual MER
1
Disponível em < https://www.draw.io/>.
36
6.8.2 Modelo Lógico
Figura 17: Modelo Lógico MER

37
7 CONCLUSÃO
Essa Projeto Integrado Multidisciplinar teve como objetivo realizar o

desenvolvimento de um sistema a partir de métodos, técnicas e ferramentas de engenharia de
software. As abordagens de engenharia de requisitos permitiram identificar e entender como
deveria funcionar o futuro sistema de modo a atender às exigências do cliente e automatizar
sob medida as rotinas da empresa analisada no projeto.
Foram utilizadas técnicas de modelagem orientada a objetos, especialmente, a
linguagem de modelagem UML para elaborar diferentes tipos de diagramas que permitiram
compreensão mais aprofundada dos eventos do sistema. Com o referencial teórico foi possível
aprofundar o conhecimento para o estudo de caso permitindo assim, que os objetivos
propostos fossem realmente alcançados.
O sistema desenvolvido nesse projeto atende todos os requisitos propostos, visto que
ele engloba os setores de vendas, compras e estoque, tornando o sistema funcional e prático
para gerar informações necessárias para tomadas de decisões.
A partir de pesquisas realizadas conclui-se que um bom controle sobre os processos
de estoque e compras de uma empresa são fundamentais, pois obtém melhores resultados de
qualidade e de organização. Não menos importante também pode contribuir para redução de
custos extras ou mesmo desnecessários.
A demanda por um sistema que possa incorporar grade parte, senão todos os
departamentos e necessidades de uma empresa vêm crescendo gradativamente ao decorrer dos
anos. E com o avanço das tecnologias a informatização e acessibilidade dos processos vêm
crescendo, pois os deixa mais ágeis e práticos.
Ao desenvolver este trabalho, permitiu uma grande contribuição para o crescimento
pessoal e profissional, uma vez que ampliou as fronteiras de novas oportunidades e
proporcionou conhecimentos específicos tanto para área de tecnologia quanto para questão
administrativa.
38
8 REFERÊNCIAS
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The Unified Modeling Language

User Guide. 2. ed.: Addison-wesley, 2005.
IEEE 1028. IEEE standard for software reviews and audits. EUA: Institute of Electrical
Electronic Engineers Standards, 2008.
INSTITUTE, Project Management. Um Guia do Conhecimento em Gerenciamento de

Projetos (Guia PMBOK® – 6ª. Edição.). Brasil: Project Management Institute - Pmi, 2018.
756 p.
INTERNATIONAL INSTITUTE OF BUSINESS ANALYSIS (IIBA) (Canadá). Guia

Babok . Um guia para o Corpo de Conhecimento de Análise de Negócio (Guia Business
Analysis Body of Knowledge): 2. ed. Brasil: International Institute Of Business Analysis
(IIBA), 2011.
MAXIMIANO, A. C. A. Introdução a administração. São Paulo: Atlas, 2006.
PETERS, JAMES F. et al. Engenharia de Software, Rio de Janeiro, Ed. Campus,2002.
PRESSMAN, Roger S.. Engenharia de Software: Uma Abordagem Profissional. 7. ed. Porto

Alegre: Amgh, 2011.
PMI. PMBOK - Um Guia do Conhecimento em Gerenciamento de Projetos (Guia

PMBoK®) / Project Management Institute - PMI. 5.ed. São Paulo: Saraiva, 2014.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S.. SISTEMA DE BANCO

DE DADOS. 3. ed. São Paulo: Makron Books, 1999.
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall,

2011.

PIM VI - 6 - Projeto Final

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PIM VI - 6 - Projeto Final

Enviado por

Direitos autorais:

Formatos disponíveis

UNIP EAD

Projeto Integrado Multidisciplinar

PROJETO DE SISTEMA DE CONTROLE DE VENDAS DE LOJAS DE JOGOS,

PROJETO DE SISTEMA DE CONTROLE DE VENDAS DE LOJAS DE JOGOS,

Nome(s) completo(s) do(s) aluno(s): Viviane Gonçalves de

PALAVRAS-CHAVE: Software; Controle; Compra; Venda; Estoque; Produto.

Keywords: Software; Control; Purchase; Sale; Stock; Product.

Esse Projeto Integrado Multidisciplinar trata-se de criação de um sistema de gestão

2.1 Contextualização do Caso

Uma loja de venda de jogos eletrônicos, acessórios e produtos geek fechou um

2.2 Mercado de Games no Brasil

Conforme a publicação da revista exame (2019), no ano de 2018 o mercado de

2.3 Mercado Geek

Os Nerds de antigamente assumiram um estilo de vida, hoje influenciam uma grande

2.4 Pesquisa Soluções Disponíveis no Mercado

3 GESTÃO ESTRATÉGICA DE RECURSOS HUMANOS

O capital humano é um dos responsáveis pelo sucesso de qualquer empreendimento,

3.1 Importância do Gerenciamento de Recursos Humanos em Projetos

O sucesso de qualquer projeto está diretamente relacionado à capacitação e

de projetos determinem atividades desafiadoras para os membros do grupo e reconheçam o

4 ANÁLISE DE SISTEMAS ORIENTADA A OBJETOS

Podemos definir que a Análise Orientada a Objetos (AOO) possui foco no

Trata-se de analisar o sistema e desenvolver um conjunto de modelos gráficos de

Análise de Negócios e o conjunto de atividades e técnicas utilizadas para servir

4.1 Engenharia de Requisitos

A engenharia de requisitos é um processo que engloba todas as atividades que

4.2 Requisitos e Classificação dos Requisitos

4.3 Regras de Negócios (RN)

As regras de negócio (RN) são premissas e restrições aplicadas a uma operação

4.4 Método de Modelagem de Processos de Negócios

A modelagem de sistema auxilia o analista a entender a funcionalidade do sistema e

Modelagem de sistema é o processo de desenvolvimento de modelos abstratos de

UML (Unified Modeling Language – linguagem de modelagem unificada) é “uma

Ela surgiu em 1994 da fusão de três grandes métodos de modelagem: o método de

 Otimizar as etapas que envolvem o desenvolvimento de um sistema,

Ela independe da ferramenta em que o aplicativo será desenvolvido. A ideia e prover

4.4 Modelagem de Casos de Uso

O Diagrama de Caso de Uso na UML é um diagrama comportamental que tem como

No diagrama de caso de uso, basicamente temos três principais elementos:

4.5 Paradigma da Programação Orientada a Objetos

O desenvolvimento de software é extremamente amplo. No mercado atual, existem

Um sistema orientado a objetos é composto de objetos interativos que mantêm seu

Os pilares da Programação Orientada a Objetos (POO):

 Objeto é uma instancia de uma classe. Armazenamento de estados através de

4.6 Diagrama de Classes

O diagrama de classes ilustra graficamente como será a estrutura do software (em

4.6.1 Técnicas para Identificação de Classes

De acordo com técnica de identificação a Análise de Robustez, os objetos que

Para entender melhor o que é um banco de dados, antes precisamos compreender a

5.1 Modelo de Diagrama de Entidade de Relacionamento

O Modelo Entidade Relacionamento (MER) é um modelo conceitual de alto-nível,

 Elipse: atributos das entidades;

6 PROJETO ANÁLISE DO SISTEMA GERENCIADOR DE ESTOQUE E VENDAS

Em um sistema desktop, a documentação garante um melhor desempenho do

6.2 Escopo do Produto

O Sistema de Controle e Gerenciamento de Loja de Jogos e Produtos Geeks será um

O objetivo do Sistema de Controle e Gerenciamento de Loja de Jogos e Produtos

6.2.3 Limites do Produto

A tabela abaixo representa as limitações do software.

Tabela 1- Limites do Produto

6.2.4 Benefícios Esperados do Produto

A tabela abaixo representa os benefícios que são esperados do software.

Tabela 2- Benefícios Esperados do Produto

6.2.5 Especificação de Ambiente