PIM-VI

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP EAD 
 
DIEGO SOUZA DA ROCHA - 0580280 
FELIPE PINHEIRO DA COSTA - 0597089 
LUCIANO AMARAL POMA JUNIOR - 0575141 
RAFAEL HENRIQUE DE ANDRADE - 0595695 
 
 
 
 
 
S.O.S – VENDAS E ESTOQUE 
PARA LOJA DE JOGOS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
BOITUVA 
2021 
DIEGO SOUZA DA ROCHA - 0580280 
FELIPE PINHEIRO DA COSTA - 0597089 
LUCIANO AMARAL POMA JUNIOR - 0575141 
RAFAEL HENRIQUE DE ANDRADE - 0595695 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
S.O.S – VENDAS E ESTOQUE 
PARA LOJA DE JOGOS 
 
 
 
 
 
Projeto Integrado Multidisciplinar para obtenção do título de 
tecnólogo em Análise e Desenvolvimento de Sistemas, 
apresentado à Universidade Paulista – UNIP EaD. 
 
 
Orientador(a): 
 
 
 
 
 
 
 
 
 
 
 
 
BOITUVA – SP 
2021 
 RESUMO 
Trabalho acadêmico proposto pela Universidade Paulista para a conclusão do 
bimestre sendo este o projeto integrado multidisciplinar VI. Os métodos de pesquisa 
utilizados foram as técnicas de pesquisa teórica e pesquisa bibliográfica. Tem por 
objetivo desenvolver a habilidade do aluno e explorar as partes do desenvolvimento 
do trabalho em sua estrutura. Com a proposta de desenvolver um software de vendas 
e organização para uma loja de jogos, acessórios e produtos geek, tendo o intuito de 
melhorar uma atividade realizado através de planilhas de Excel. Nossa empresa 
contratada junto com as pessoas interessadas, detalharam todos os requisitos que 
seria necessário para o sistema possuir e assim realizar um excelente trabalho, entre 
eles um sistema de acesso por login e senha na qual cada usuário possuirá diferentes 
permissões dentro do sistema, essas informações são utilizadas em toda a parte da 
documentação que será desenvolvida no decorrer do processo de engenharia de 
software, são elas, as descrições de casos de uso e diagramas de diversos modelos 
visando construir uma documentação mais detalhada possível com informações de 
qualidade. Cada diagrama é utilizado para uma finalidade, o de caso de uso é 
demostrar as diversas maneiras que os atores podem interagir com o sistema; o 
diagrama de atividade é mostrar um fluxo de atividades em um mesmo processo; o 
de classes estando entre os mais uteis dentro da UML, descreve de maneira clara a 
estrutura a ser criada no sistema; por fim o Modelo Entidade-Relacionamento que por 
objetivo descreve modelos conceituais de bancos de dados. Lembrando que todas 
essas documentações precisam ser realizadas com muita atenção e 
comprometimento, com as informações detalhadas e de qualidade, assim 
aumentando a porcentagem de conclusão de um software que atinge os requisitos do 
cliente e que exerça suas atividades com qualidade. 
 
 
 
 
 
CHAVE: Software. UML. Loja de jogos. produtos Geek. Diagrama. 
ABSTRACT 
Academic work proposed by Universidade Paulista for the conclusion of the two-
month period, this being the integrated multidisciplinary project VI. The research 
methods used were the techniques of theoretical research and bibliographic research. 
It aims to develop the student's skill and explore the parts of the development of work 
in its structure. With the proposal to develop a sales and organization software for a 
game store, accessories and geek products, with the aim of improving an activity 
carried out through Excel spreadsheets. Our company hired together with the 
interested people, detailed all the requirements that would be necessary for the system 
to have and thus perform an excellent job, among them a system of access by login 
and password in which each user will have different permissions within the system, 
this information they are used in all the documentation that will be developed during 
the software engineering process, they are the descriptions of use cases and diagrams 
of different models in order to build the most detailed documentation possible with 
quality information. Each diagram is used for a purpose, the use case is to demonstrate 
the different ways that the actors can interact with the system; the activity diagram is 
to show a flow of activities in the same process; the class being among the most useful 
within the UML, clearly describes the structure to be created in the system; finally, the 
Entity-Relationship Model, which by objective describes conceptual models of 
databases. Bearing in mind that all these documentation needs to be carried out with 
great attention and commitment, with detailed and quality information, thus increasing 
the percentage of completion of a software that meets the client's requirements and 
that carries out its activities with quality. 
 
 
 
 
 
 
KEY: Software. UML. Game store. Geek products. Diagram. 
SUMÁRIO 
1 INTRODUÇÃO ........................................................................................................................................... 5 
2 EXIGENCIAS INICIAIS .............................................................................................................................. 6 
2.1 REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS ....................................................................................... 6 
2.2 REGRAS DE NEGÓCIO ................................................................................................................................... 8 
3 DEFINIÇÕES DOS CASOS DE USO ....................................................................................................... 8 
3.1 MODELAGEM DE CASOS DE USO .................................................................................................................. 9 
3.2 MODELO DE DESCRIÇÃO DE CASOS DE USO ................................................................................................ 9 
3.3 DIAGRAMA DE CASOS DE USO ................................................................................................................... 10 
3.4 DIAGRAMA DE ATIVIDADES ......................................................................................................................... 11 
4 DIAGRAMAS DE CLASSE ......................................................................................................................14 
4.1 DIAGRAMA DE CLASSES DE ANÁLISE ......................................................................................................... 16 
5 MODELO DE ENTIDADE DE RELACIONAMENTO – MER .................................................................17 
6 CONCLUSÃO ............................................................................................................................................19 
REFERÊNCIAS ............................................................................................................................................20 
 
 
5 
 
1 INTRODUÇÃO 
 
Não podemos negar que a área da tecnologia vem aumentando no mundo todo, 
a tecnologia de desenvolvimento de software vem acompanhando esse crescimento 
consideravelmente. Nos dias de hoje pequenas empresas estão investindo nessa área 
para estar tendo mais eficiência, eficácia e qualidade em seus serviços. 
Neste projeto apresentado a seguir terá a documentação, diagramas e alguns 
processos do desenvolvimento de software, requeridos por uma Loja de Games. 
Nossa empresa foi contratada para estar desenvolvendo um sistema de estoque e 
vendas dos seus produtos, com o objetivo final de ter um controle eficaz e seguro das 
informações de sua loja, já que o sistema atual é feito através de planilhas de Excel. 
Com a engenharia de requisitos, obtivemos as informações necessárias 
através de reuniões, levantamento de dados e análise para determinarmos nossos 
requisitos funcionais e não funcionais na qual será a base para toda a documentação. 
Foi apresentado uma visão do projeto mais voltada ao usuário, foi demonstrado 
os diagramas de Caso de Uso e de Atividade, na qual realiza uma abordagem mais 
simples. 
A parte mais técnica é os diagramas de Classe e o Modelode Entidade de 
Relacionamento (MER) que são utilizados como modelo para a criação dos códigos 
do sistema e o desenvolvimento do banco de dados. 
Com toda documentação e com informações de qualidade temos a base 
necessária para dar início a codificação desse nosso produto, denominado Sales 
Organization System (SOS). Vamos descobrir essa documentação juntos. 
Os métodos utilizados foram as técnicas de pesquisa teórica (consiste nas 
análises de informações presentes em artigos e fóruns) e pesquisa bibliográfica 
(análise de pesquisas anteriores). 
 
 
6 
 
2 EXIGENCIAS INICIAIS 
 
As exigências/requisitos solicitadas pelo cliente, observadas após algumas 
reuniões vão servir de base para o início da documentação, na qual servirão para o 
modelo de casos de uso. Abaixo estão todos os requisitos solicitados: 
• O sistema deverá conter um controle de acesso baseado em 
Login e senha; 
• São três tipos de usuários, sendo eles: atendente, estoquista e 
para o supervisor da loja; 
• Para os cadastros dos clientes haverá os campos para 
preenchimento obrigatório do RG, CPF, nome, data do cadastro, endereço, 
telefone, e-mail do cliente e assim gerado um código para cada cliente; 
• Nos produtos deve conter o código de barras, nome do produto, 
categoria, fabricante, quantidade, valor do produto e para os jogos e acessórios 
deve ser informado em qual plataforma serão utilizados e qual o prazo de 
garantia do produto; 
• Para a realização da venda é necessário ter os dados do cliente 
e dos produtos a serem comprados, no ato da venda será gerado um código 
com data, valor, forma de pagamento e o status da venda. 
• Para o usuário de atendente, ele poderá excluir produtos da 
venda, se for necessário, quando o cliente não quiser mais comprá-los. Sendo 
necessário a confirmação por login e senha do supervisor. Além disso, o 
atendente poderá consultar os preços de cada produto, caso o cliente solicite 
a informação; 
• Em caso de cancelamento da compra apenas o supervisor pode 
realizar esta operação, desta forma, o código da venda é enviado para o 
sistema financeiro da loja. 
 
2.1 Requisitos funcionais e não funcionais 
 
7 
 
Os requisitos funcionais são aquelas necessidades pela qual a 
programação deverá atender, é a forma pela qual funciona o programa, o 
requisito não funcional refere-se à forma em que o programa tornará realidade 
as exigências do cliente. 
 
Abaixo demonstra os Requisitos Funcionais: 
 
Atendente: 
− RF01: Cadastrar novos clientes 
− RF02: Consultar produtos e preços 
− RF03: Realizar a venda 
− RF04: Remoção de produtos, mediante autorização do 
supervisor 
 
 
Estoquista: 
‘ 
− RF05: Cadastrar produtos 
− RF06: Separação do produto através dos pedidos 
finalizados pela atendente 
 
 
Supervisor: 
 
− RF07: Todos os requisitos anteriores 
− RF08: Cancelamento de compras 
 
Abaixo demonstra os Requisitos não Funcionais: 
 
− RNF 01: O sistema funcionará apenas dentro do horário de trabalho, 
encerrando a Jornada o sistema para de funcionar impossibilitando 
qualquer ação do empregado, cumprindo todas as exigências da 
Consolidação das Leis Trabalhistas. 
8 
 
− RNF 02: O sistema funcionará apenas nas dependências da loja. 
− RNF 03: Para cada usuário terá acessos e permissões diferentes entre 
eles, de acordo com a hierarquia de cada função. 
− RNF 04: A finalização da venda será efetivo mediante a confirmação do 
pagamento ao sistema financeiro. 
 
2.2 Regras de negócio 
 
Uma regra de negócio é uma declaração explícita estipulando uma 
condição que deve existir no ambiente de informação de negócios, para a 
informação extraída do ambiente ser consciente com a política da empresa 
(APPLETON,1984.) 
 
As regras de negócio é tudo aquilo que o cliente impõe para realizar um 
sistema com sucesso, segurança, confidencialidade e agilidade. 
Abaixo estão as regras exigidas: 
 
• O sistema deve ser seguro, pois será tratado transações financeiras; 
• No ato de venda, terá as opções como pagamento cartão de débito ou crédito 
(parcelado em até 5x) e dinheiro (a vista) sem desconto; 
• Por tratar de loja física, a troca somente ocorrerá se houver defeito de 
fabricação no prazo de 5 (cinco dias) a contar da data de emissão da Nota 
Fiscal, ultrapassados os cinco dias o sistema não permitirá a troca. Não sendo 
possível realizar devoluções; 
• A estoquista deverá manter a lista de produtos atualizados, descrevendo a 
quantidade correta que possuí no estoque. Ainda, deverá cadastrar os produtos 
conforme sua categoria (jogos, acessórios e produtos GEEK). 
 
3 DEFINIÇÕES DOS CASOS DE USO 
 
De acordo com Melo (2010, p. 57) “um caso de uso descreve uma sequência 
de ações que representam um cenário principal (perfeito) e cenários alternativos, com 
9 
 
o objetivo de demonstrar o comportamento de um sistema (ou parte dele), através de 
interações com autores.” 
Os casos de usos auxiliarão na criação do programa através de diagramas, 
evitando falhas do que foi solicitado pelo cliente trazendo uma segurança e 
confiabilidade. 
 
3.1 Modelagem de casos de uso 
 
Bezerra conceitua (2006, p. 45), “modelo de casos de uso é uma representação 
das funcionalidades externamente observáveis do sistema e dos elementos externos 
ao sistema que interagem com ele” 
A modelagem dos casos de uso é o “rascunho” que ajudará na programação 
do sistema, sendo necessário observar os elementos que deve conter no “rascunho” 
conhecido por sua termologia técnica de diagrama. 
Primeiramente, é necessário descrever os atores dos casos de uso, sendo 
estes agentes que conduzem este sistema e de alguma forma esperam um resultado, 
estes agentes são externos ao programa. 
Os atores do nosso sistema são: atendentes, estoquistas e o supervisor, cada 
um tem atividades especificas referente a cada cargo. Além disso, o Recursos 
Humanos também necessita de um sistema externo, pois, nele será observado a 
jornada de trabalho dos empregados bem como feriados, DSR, férias, intervalos 
intrajornada e interjornada. 
Por fim, também considerados como agentes os hardware e leitores de códigos 
de barras. 
 
3.2 Modelo de descrição de casos de uso 
 
O Modelo usado por nosso sistema é o Modelo de Descrição de Casos de Uso, 
vide exemplo abaixo: 
10 
 
Imagem 1: Modelo de descrição de Caso de Uso – cadastro de produto 
 
 Fonte: Autoria Própria, Excel 
 
 Imagem 2: Modelo de descrição de Caso de Uso – Venda 
 
Fonte: Autoria Própria, Excel 
 
 
3.3 Diagrama de casos de uso 
 
Identificação Cadastro de novo produto
Escopo Sistema SOS implantado 
Descrição do propósito O cadastro de novos produtos
Ator primário Estoquista
Interessados Loja
O sistema SOS funcionando, com o acesso de 
 estoquista e as informações dos novos produtos 
Pós-Condições Cadastro do produto
Com o produto novo em mãos. O estoquista entrará
 com seu login e senha no sistema. Preencherar todas
as informações nescessarias para realizar o cadastros e
inclui-los no estoque.
Login e senha invalidos exibir erro.
Informações insuficientes do produto exibir erro.
Produto já cadastrado exibir erro.
Requisitos Relacionados RF05 - Cadastrar produto; RNF03 - Permissões
Modelo de descrição de Caso de uso
Pré-Condições
Fluxo Normal
Fluxo Alternativo
Identificação Venda
Escopo Sistema SOS implantado 
Descrição do propósito Realizar uma venda completa
Ator primário Atendente e/ou Supervisor
Interessados Cliente
O sistema SOS funcionando, com o acesso de atendente
e o cliente com seus devidos dados.
Pós-Condições Compra finalizada e produtos entregue
O atendente inicia um novo cadastro, insere os dados
informados pelo cliente e finaliza. Segue para a aba de 
pedidos onde selecionara os produtos que seram 
comprados pelo cliente. Onde tera a possibilidade de
escolher a forma de pagamento.
Se o cliente já possuir cadastro, ir direto para a aba de 
pedidos. Em caso dedesistencia de algum produto ou 
da compra inteira o supervisor será acionado.
RF01 - Cadastrar novos clientes; RF02 - Consultar produ-
tos e preços; RF03 - Realizar a venda; RF04 - Remoção de
 produtos, mediante autorização do supervisor; RNF08 -
Cancelamento de compras; RNF03 - Permissões; RNF04 -
Finalização da venda.
Modelo de descrição de Caso de uso
Pré-Condições
Fluxo Normal
Fluxo Alternativo
Requisitos Relacionados
11 
 
Um diagrama de casos de uso descreve a funcionalidade proposta para ser 
desenvolvida no programa. 
Diagrama de casos de uso é um diagrama da UML que tem por objetivo 
mostrar, a partir de um ponto de vista estático, o conjunto de casos de uso, 
atores e seus relacionamentos (BOOCH; JACOBSON; RUMBAUGH, 2006). 
 
Imagem 3: Diagrama de caso de uso 
 
Fonte: Autoria própria, StarUML (2021) 
 
Podemos observar no diagrama acima as seguintes relações: 
 
• Os três usuários entrarão no sistema com Login e senha; 
• Será verificada pelo sistema de segurança (<<include>>); 
• Liberando as permissões necessárias (<<extend>>); 
• Além da verificação de segurança, também será analisado pelo RH se o 
empregado se encontra dentro da jornada de trabalho (<<include>>). 
 
3.4 Diagrama de atividades 
 
Completando a visão de caso de uso, elaboramos dois diagramas de atividades 
para demostrar uma das principais atividades a ser realizada no sistema pelos 
usuários “Atendente” e “Estoquista”. 
12 
 
Segundo Booch, Jacobson e Rumbaugh (2006), os diagramas de atividades 
são utilizados para representação de aspectos dinâmicos do sistema e comumente 
são utilizados em duas situações: 
• Modelagem de fluxo de trabalho: dá ênfase no processo de negócio sob o ponto de 
vista dos atores que interagem com o sistema. 
 • Modelagem de operação: expõe a visão computacional da implementação de um 
caso de uso. 
 
13 
 
Imagem 4:Diagrama de Atividades – Atendente. 
 
Fonte: autoria própria, StarUML (2021) 
 
 
 
 
14 
 
 Imagem5: Diagrama de Atividade – Estoquista 
 
 Fonte: autoria própria, StarUML (2021) 
 
Ambos os diagramas acima demonstram as atividades que os atores 
relacionados com o sistema precisarão relacionar durante o processo de venda, 
ajudando o desenvolvimento do Software. 
 
4 DIAGRAMAS DE CLASSE 
 
15 
 
As classes são representações de ideias transferidas a um paradigma, 
tornando este como um molde. Tendo o molde, serão realizados os objetos, que tem 
por objetivo incluir as ideias no programa. 
De acordo com Booch, Rumbaugh e Jacobson (2005, p. 51) “classe é uma 
descrição de um conjunto de objetos que compartilham os mesmos atributos, 
operações, relacionamentos e semântica.” 
Abaixo está um diagrama de classe para nosso projeto, logo após está todo o 
detalhamento e descrição. 
 
 Imagem 6: Diagrama de classes 
 
Fonte: Autoria própria, StarUML (2021) 
 
16 
 
No diagrama acima, foi demonstrado o molde que será utilizado em nosso 
sistema. Identificamos várias ações que o programa realizará, sendo estas: os 
estoquistas recebendo e cadastrando os novos produtos, o atendente realizando o 
cadastro do cliente e finalizando a venda e o supervisor que tem acesso a todas as 
funções e incluindo algumas novas atribuições. 
A herança foi utilizada em nosso programa visando a facilitação na correção de 
algum erro dentro do programa, podendo corrigir um dado e este automaticamente 
corrigir os demais, conhecido como as “classe filha” e “classe pai”. 
Foi usado também a agregação e composição, sendo a primeira usada para 
demonstrar a relação do atendente com o cliente, podendo existir com a ausência do 
outro. Na composição foi demonstrado entre o cliente e a venda, desta forma a venda 
não existe sem o cliente. 
 
4.1 Diagrama de classes de análise 
 
Em alguns casos, é necessário a colaboração de outros objetos distintos dos 
quais estão dentro do software, pois, o sistema não consegue realizar tudo de forma 
autônoma. 
Os diagramas de classes de análise, é usado justamente para mostrar essas 
limitações, conforme demonstra o diagrama abaixo: 
 
Imagem 7: Diagrama de classes de análise 
 
Fonte: Autoria própria, StarUML (2021) 
17 
 
Nas classes de análises, para uma melhor organização dos objetos eles são 
divididos em Entidade, Fronteira e Controle. 
Na entidade (entity), tem por objetivo demonstrar o objeto de forma aproximada 
do mundo real. Para a Fronteira (boundary), como a própria nomenclatura diz é a 
fronteira/divisão do interno com o externo do sistema. Por sim, o Controle (control), 
ela faz o controle da execução do caso de uso, tendo ligação com a classe de 
entidade. 
 
5 MODELO DE ENTIDADE DE RELACIONAMENTO – MER 
 
O Modelo de Entidade de Relacionamento foi criado com o intuito de facilitação 
no banco de dados. Neste modelo deverá ser usado muita simbologia na qual não 
podem ser desrespeitados. 
 
18 
 
Imagem 8: Diagrama MER 
 
Fonte: Autoria própria, brModelo (2021) 
 
O modelo acima servirá como base para a criação da estrutura do banco de 
dados, nele utilizamos duas figuras. 
O retângulo é uma entity onde será representado pelas classes que teremos 
dentro do nosso banco de dados, sendo esta uma relação de cardinalidade. 
 O losango representa a relação entre as entidades. Por fim, o círculo 
representa os atributos e o círculo preenchido é um atributo que será uma chave 
primária. 
 
19 
 
6 CONCLUSÃO 
 
Com as informações apresentadas no desenvolvimento desse trabalho, 
notasse que para um desenvolvimento de software são necessárias diversas etapas 
de documentação. 
Começando com o levantamento dos requisitos através das reuniões, 
levantamento de dados e análise. Passando pelo processo de negócio e a visão de 
caso de uso, elaborando os diagramas de atividade e caso de uso. 
Além da documentação referente ao diagrama de classes que vamos utilizar 
para a codificação do sistema e o Modelo de Entidade de Relacionamento (MER) que 
é a base para o sistema de banco de dados. 
Conclui-se que possuindo esses conhecimentos a disposição, é possível 
realizar o desenvolvimento completo do software. 
 
20 
 
REFERÊNCIAS 
 
APPLETON, Daniel S. Datamation. Business Rules: The Missing Link. p. 145-150, 
outubro 1984. 
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML: um 
guia prático para modelagem de sistemas orientados a objetos através da linguagem 
de modelagem unificada. Rio de Janeiro: Campus, 2006. 
BOOCH, Grady; JACOBSON, Ivair; RUMBAUGH, James. UML: guia do usuário. 2. 
ed. Rio de Janeiro: Campus, 2006. 
BOOCH, Grady; JACOBSON, Ivair; RUMBAUGH, James. UML: guia do usuário. 6° 
Reimpressão. Rio de Janeiro: Elsevier, 2005. 
MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.2 do conceito à 
implementação. 3° edição. Rio de Janeiro: Brasport, 2010 
TONSING, Sérgio Luiz, Engenharia de Software-Análise e Projeto de Sistemas. 2° 
edição. Rio de janeiro: Ciência Moderna Ltda, 2008 
WAZLAWICK, Raul Sidnei. Metodologia de Pesquisa para Ciência da Comutação. 
Rio de Janeiro: Elsevier, 2008.