PIM VI - PROJETO DE SISTEMA DE CONTROLE DE VENDAS DE LOJAS DE JOGOS, ACESSÓRIOS E PRODUTOS GEEKS

Prévia do material em texto

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): 
RA(s): 
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) ................................................................................................. 12 
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 .................................................................................................... 19 
6.2.4 Benefícios Esperados do Produto ............................................................................ 19 
6.2.5 Especificação de Ambiente ....................................................................................... 19 
6.2.6 Especificação de Equipamentos .............................................................................. 20 
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 .................................................................................................... 23 
6.4 Mapa Mental...................................................................................................................... 24 
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 ....................................................................... 27 
6.6.4 Caso de Uso – UC3 – Gerenciar Relatórios ........................................................... 28 
6.6.5 Caso de Uso – UC4 – Manter Cliente ..................................................................... 28 
6.6.6 Caso de Uso – UC5 – Manter Fornecedor ............................................................. 29 
6.6.7 Caso de Uso – UC6 – Manter Produto ................................................................... 30 
6.6.8 Caso de Uso – UC7 – Manter Compra ................................................................... 30 
6.6.9 Caso de Uso – UC8 – Manter Venda ...................................................................... 31 
6.6.10 Caso de Uso – UC9 – Consultar Preços ............................................................... 32 
6.6.11 Caso de Uso – UC10 – Manter Categorias de Produtos .................................... 33 
6.6.12 Atores do Caso de Uso ............................................................................................ 33 
6.7 Diagrama de Classes .........................................................................................................34 
6.8 Modelo Entidade de Relacionamento (MER)............................................................... 35 
6.8.1 Modelo Conceitual ..................................................................................................... 35 
6.8.2 Modelo Lógico ............................................................................................................ 36 
7 CONCLUSÃO .......................................................................................................................... 37 
8 REFERÊNCIAS ....................................................................................................................... 38 
 
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 
 
9 
 
Os Nerds de antigamente assumiram um estilo de vida, hoje influenciam uma grande 
parcela de jovens. Hoje passaram a ser conhecidos como Geeks. 
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. 
10 
 
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 
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árioe 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. 
 
11 
 
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) 
 
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. 
 
12 
 
4.3 Regras de Negócios (RN) 
 
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: 
13 
 
• Auxiliar na análise e desenvolvimento de sistemas orientados a objetos, 
computacionais ou não; 
• Aumentar a produtividade; 
• 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 
14 
 
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. 
No diagrama de caso de uso, basicamente temos três principais elementos: 
1. Ator (o bonequinho) - Um ator é quem fará a execução docaso 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): 
15 
 
• Classe: Representação de um conjunto de objetos com características afins. 
Definição do comportamento dos objetos (métodos) e seus atributos. 
• 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. 
16 
 
• Multiplicidade: Especifica o número de objetos aos quais outro objeto pode 
se associar. 
• 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 
17 
 
for possível agrupar informações que se relacionam e tratam de um mesmo assunto, podemos 
dizer que temos um banco de dados. 
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 
https://www.devmedia.com.br/curso/curso-de-oracle/1456
https://www.devmedia.com.br/curso/curso-sql-server/406
https://www.devmedia.com.br/curso/curso-de-postgresql/1904
https://www.devmedia.com.br/curso/curso-completo-de-mysql/281
https://www.devmedia.com.br/principios-da-engenharia-de-software/29630
18 
 
utilizamos algumas formas geométricas para expressar graficamente a lógica estrutural de um 
banco de dados: 
• Retângulo: representa as entidades; 
• 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 
relação à emissão manual. 
Essencial 
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 
Fonte: Elaborado pelo Autor (2020). 
 
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 
(recomendado HD SSD – 240GB 
somente para os sistemas) 
30GB 
Memória RAM: 8GB 
(recomendado 16GB) 
4GB 
Sistema Operacional: Windows 10 Pro 
(recomendado Windows Server 2012 
ou superior) - Obrigatoriamente 64 
bits. 
Windows 10 ou superior (as 
edições Starter e Home não estão 
homologadas) 
Rede: 100/1000 100/1000 
Fonte: Elaborado pelo Autor (2020). 
 
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 
RF01 
Gerenciamento dos 
produtos 
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; 
Para consultar ou alterar as informações de um produto, o usuário 
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; 
Evidente 
RF02 
Gerenciamento das 
categorias de produtos 
Os produtos cadastrados no sistema serão classificados em 
categorias as quais serão utilizadas para a distinção entre os 
mesmos; para adicionar uma nova categoria de produto, o usuário 
deverá informar o nome e a descrição da nova categoria; 
Evidente 
RF03 
Gerenciamento dos 
dados dos clientes 
Os clientes serão todas as pessoas que adquirirem algum produto 
oferecido pela loja. 
O sistema permitirá o cadastro e a manutenção dos dados dos 
clientes a fim de manter informações acerca das características e 
principais modalidades de compras do mesmo. 
Evidente 
RF04 Controle do estoque 
O sistema gerenciará a quantidade de itens existentes no estoque 
para indicar a necessidade de complemento do mesmo e disposição 
de itens à venda. 
Oculto 
RF05 
Controle do movimento 
de caixa 
Ao início e fim de cada expediente, o sistema calculará os valores 
de entrada e saída para cálculo do movimento diário do caixa. 
Evidente 
RF06 
Gerenciamento dos 
dados dos funcionários 
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á 
preencher o formulário de cadastro, informando os devidos 
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. 
Evidente 
RF07 
Gerenciamento dos 
dados dos fornecedores 
Os fornecedores dos produtos da loja poderão ser cadastrados no 
sistema para controle de entrada dos produtos, formas de contato e 
possíveis acarretamentos de responsabilidades. 
Para cadastrar um fornecedor, o estoquista deverá preencher 
corretamente o formulário e confirmar a operação. 
Evidente 
22 
 
RF08 
Gerenciamento e 
controle das vendas 
Os Vendedores ( Operadores de Caixas) cadastrados têm 
permissãopara efetuar vendas de produtos oferecidos pela loja e 
disponíveis em estoque. 
Para efetuar uma venda, o operador deverá informar o(s) 
produto(s), confirmar o pagamento e efetuar o registro da venda. 
Toda venda realizada com sucesso será registrada na base de 
dados. 
Evidente 
Fonte: Elaborado pelo Autor (2020). 
 
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 
RFN03 Segurança 
O acesso ao sistema só poderá acontecer mediante a 
autenticação do usuário. O sistema deverá conter 
conteúdos restritos que só poderão estar acessíveis 
aos usuários detentores de permissão. 
Obrigatório 
RFN04 
Autenticação de 
usuários 
O sistema garantirá que somente pessoas 
previamente cadastradas pelo gerente acessem ao 
sistema. 
Evidente 
RFN05 
Gerenciamento de 
níveis de acesso 
O sistema garantirá que o seu conteúdo seja 
acessado de acordo com o nível de permissão do 
usuário, evitando que usuários comuns acessem 
conteúdo restrito. 
Evidente 
RFN06 
Performance - 
Concorrência 
O sistema deverá suportar a carga de até 50 acessos 
simultâneos. 
Desejável 
RFN07 
Usabilidade - Interface 
com o Usuário 
O sistema deverá prover uma interface com o 
usuário que seja intuitiva, prática e fácil de usar. 
Evidente 
RFN08 
Requisitos de 
desempenho tempo de 
resposta 
O tempo máximo de qualquer transação não deve 
ultrapassar 5 segundos. 
Desejável 
Fonte: Elaborado pelo Autor (2020). 
 
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 
RN01 Acesso ao Sistema 
Login de Usuário: Todo acesso ao sistema deverá ser realizado por 
meio de Login e senha de Usuário. 
RN02 Cadastros de Produtos 
 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 
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 
 Os cadastros devem possuir campos de preenchimento 
obrigatórios. E o usuário deverá preencher todos os campos para 
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 
Os cadastros devem possuir campos de preenchimento 
obrigatórios. E o usuário deverá preencher todos os campos para 
conseguir concluir os cadastros. 
Tipos - divididos por categorias: jogos, acessórios e produtos geek. 
RN05 Operação de Vendas 
No processo de vendas: A venda deverá possuir os dados do 
cliente e todos os produtos adquiridos. Deverá ser gerado um 
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. 
RN06 Consulta de Preços 
O atendente poderá consultar os preços dos produtos caso o cliente 
solicite 
RN07 Cancelamento de Vendas 
No processo de vendas, caso seja necessário o cancelamento da 
venda, a mesma somente poderá ser realizada pelo supervisor da 
loja, que deve informar usuário e senha válidos. 
RN08 Exclusão de itens na Venda 
No processo de vendas, caso seja necessário a exclusão de 
produtos, a mesma somente poderá ser realizada pelo supervisor da 
loja, que deve informar usuário e senha válidos. 
24 
 
Fonte: Elaborado pelo Autor (2020). 
 
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. 
 
Fonte: Elaborado pelo Autor (2020). 
 
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 
Fonte: Elaborado pelo Autor (2020). 
 
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 
 
 
Fonte: Elaborado pelo Autor (2020). 
6.6.2 Caso de Uso – UC1 - Manter Funcionário 
Figura 3 - Caso de uso manter funcionário. 
27 
 
 
Fonte: Elaborado pelo Autor (2020). 
 
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. 
Fonte: Elaborado pelo Autor (2020). 
 
6.6.3 Caso de Uso – UC2 – Efetuar Login 
Figura 4 - Caso de uso efetuar login. 
 
Fonte: Elaborado pelo Autor (2020). 
 
Tabela 9 - caso de uso efetuar login. 
Código Caso de Uso UC2 
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. 
Fonte: Elaborado pelo Autor (2020). 
 
6.6.4 Caso de Uso – UC3 – Gerenciar Relatórios 
Figura 7 - Caso de uso Gerenciar Relatórios. 
 
Fonte: Elaborado pelo Autor (2020). 
 
Tabela 10 - Caso de uso gerenciar relatórios. 
Código Caso de Uso UC3 
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 Principal4. 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. 
Fonte: Elaborado pelo Autor (2020). 
 
 
 
 
 
6.6.5 Caso de Uso – UC4 – Manter Cliente 
Figura 8 - Caso de uso manter cliente. 
29 
 
 
Fonte: Elaborado pelo Autor (2020). 
 
Tabela 11 - Caso de uso manter cliente. 
Código Caso de Uso UC4 
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) 
3 – O sistema solicita os dados para o cadastro da função. [A1] 
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. 
Fonte: Elaborado pelo Autor (2020). 
 
6.6.6 Caso de Uso – UC5 – Manter Fornecedor 
Figura 9 - Caso de uso manter fornecedor. 
 
Fonte: Elaborado pelo Autor (2020). 
 
 
 
 
Tabela 12 - Caso de uso manter fornecedor. 
Código Caso de Uso UC5 
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 
Fonte: Elaborado pelo Autor (2020). 
 
6.6.7 Caso de Uso – UC6 – Manter Produto 
Figura 10 - Caso de uso manter produto. 
 
Fonte: Elaborado pelo Autor (2020). 
 
Tabela 13 - Caso de uso manter produto. 
Código Caso de Uso UC6 
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 
 3 – O sistema solicita os dados para o cadastro da função. [A1] 
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 “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. 
A2 – O funcionário poderá cancelar o processo durante o cadastro. 
Fonte: Elaborado pelo Autor (2020). 
 
6.6.8 Caso de Uso – UC7 – Manter Compra 
Figura 11: Caso de uso manter compra. 
31 
 
 
Fonte: Elaborado pelo Autor (2020). 
 
Tabela 14 - Caso de uso manter compra. 
Código Caso de Uso UC7 
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. 
Fonte: Elaborado pelo Autor (2020). 
 
6.6.9 Caso de Uso – UC8 – Manter Venda 
Figura 12: Caso de uso manter venda. 
 
Fonte: Elaborado pelo Autor (2020). 
 
Tabela 15 - Caso de uso manter venda. 
Código Caso de Uso UC8 
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 
Pré-Condição O funcionário deverá estar autenticado no sistema 
32 
 
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. 
3 – O sistema solicita os dados para o cadastro da função. [A1] 
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. 
Fonte: Elaborado pelo Autor (2020). 
 
6.6.10 Caso de Uso – UC9 – Consultar Preços 
Figura 13: Caso de uso Consultar Preços 
 
Fonte: Elaborado pelo Autor (2020). 
 
Tabela 16 - Caso de uso Consultar Preços 
Código Caso de Uso UC9 
Nome do Caso de Uso Consultar Preços 
Funcionalidade/Objetivo Permite ao funcionário consultar preços dos produtos 
Ator Funcionário 
Pré-Condição O funcionário deverá estar autenticado no sistema 
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”. 
Fonte: Elaborado pelo Autor (2020). 
 
33 
 
6.6.11 Caso de Uso – UC10 – Manter Categorias de Produtos 
Figura 14: Caso de uso Manter Categorias de Produtos 
 
Fonte: Elaborado pelo Autor (2020). 
 
Tabela 17 - Caso de uso Manter Categorias de Produtos 
Código Caso de Uso UC10 
Nome do Caso de Uso Manter Categorias de Produtos 
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 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 
 3 – O sistema solicita os dados para o cadastro da função. [A1] 
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 “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.A2 – O funcionário poderá cancelar o processo durante o cadastro. 
Fonte: Elaborado pelo Autor (2020). 
 
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. 
Fonte: Elaborado pelo Autor (2020). 
 
 
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 
 
Fonte: Elaborado pelo Autor (2020). 
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 
 
Fonte: Elaborado pelo Autor (2020). 
 
1 Disponível em < https://www.draw.io/>. 
36 
 
6.8.2 Modelo Lógico 
 
Figura 17: Modelo Lógico MER 
 
 
Fonte: Elaborado pelo Autor (2020). 
 
 
 
 
 
 
 
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.