PIM VI - LEVANTAMENTO E ANÁLISE DE REQUISITOS PARA UMA LOJA DE EQUIPAMENTOS GEEK - 2076013

Prévia do material em texto

Universidade Paulista EAD 
Projeto Integrado Multidisciplinar PIM VI 
 
 
 
 
 
Fernando Ramos Gabriel 
 
 
 
 
SISTEMA PARA EMPRESA DESTINADA À VENDA DE JOGOS 
ELETRÔNICOS, ACESSÓRIOS E PRODUTOS GEEK 
 
 
 
 
 
 
 
 
 
 
São José dos Campos 
2021
 
 
 
 
 
 
Fernando Ramos Gabriel 
RA: 2076013 
 
 
 
SISTEMA PARA EMPRESA DESTINADA À VENDA DE JOGOS 
ELETRÔNICOS, ACESSÓRIOS E PRODUTOS GEEK 
 
 
 
Projeto Integrado Multidisciplinar VI 
apresentado à Universidade Paulista EAD – 
UNIP, campus de São José dos Campos, 
como parte dos requisitos necessários para a 
obtenção do título de Tecnólogo em Análise e 
Desenvolvimento de Sistemas, sob orientação 
da Profª. Sandra Bozolan; 
 
 
 
São José dos Campos 
2021 
 
 
RESUMO 
 
A revolução tecnológica das últimas décadas tem aumentado a demanda cada 
vez mais de pessoas e empresas por produtos de software de qualidade e de baixo 
custo. Isto tem como objetivo principal a automação de seus processos, o qual resulta 
em ganho de produtividade e competitividade no mercado. Tendo em vista essa 
necessidade de automação, foram desenvolvidos softwares para vendas, onde é 
possível gerenciar o estoque e o caixa. Saber quais itens são mais vendidos, qual o 
faturamento de cada semana, mês e ano. Porém, nada disso adianta se os dados não 
forem armazenados corretamente e que terá acesso a tais dados. Pensando nisso, o 
levantamento e a análise de requisitos se faz necessária, pois assim, são identificados 
os atores que utilizaram o sistema e que terão acesso a certo tipo de dados. 
Para armazenar os dados foi será utilizado um banco de dados relacional, 
definindo os níveis de acesso para cada ator, assim, restringindo acesso de dados 
sigilosos por usuários não autorizados. 
 
 
 
 
 
 
 
 
 
 
 
 
Palavras-chave: Banco de dados. Software. Análise de requisitos. Cadastro. 
Estoque. Controle. 
 
 
 
ABSTRACT 
 
The technological revolution of the last decades has increased the demand of 
people and companies for quality and low-cost software products. This has as main 
objective the automation of its processes, which results in gains in productivity and 
competitiveness in the market. In view of this need for automation, sales software was 
developed, where it is possible to manage inventory and cash. Know which items are 
the most sold, what the sales of each week, month and year are. However, none of 
this is useful if the data is not stored correctly and you will have access to such data. 
Thinking about it, the requirements survey and analysis is necessary, because thus, 
the actors who used the system and who will have access to a certain type of data are 
identified. 
A relational database will be used to store the data, defining the access levels 
for each actor, thus restricting access to sensitive data by unauthorized users. 
 
 
 
 
 
 
 
 
 
 
 
 
Keywords: Database. Software. Requirements Analysis. Cadastre. Stock. 
Control. 
 
 
LISTA DE FIGURAS 
 
Figura 01 - Tela Login ...................................... Erro! Indicador não definido.1 
Figura 02 - Tela Cadastro Cliente .................... Erro! Indicador não definido.1 
Figura 03 - Sistema Cadastro Produto ............. Erro! Indicador não definido.3 
Figura 04 - Tela Cadsatro Produto ................... Erro! Indicador não definido.3 
Figura 05 - Sistema de Vendas ....................... Erro! Indicador não definido.5 
Figura 06 - Tela de Vendas ............................. Erro! Indicador não definido.5 
Figura 07 - Diagrama de Requisitos Não FuncionaisErro! Indicador não 
definido.9 
Figura 08 - Diagrama de Atributos de Qualidade ........................................... 20 
Figura 09 - Modelo de Entidade-Relacionamento (MER) ............................... 25 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
1 - Introdução .................................................................................................. 8 
2 - Casos de Uso ............................................................................................. 8 
2.1 - Requisitos ....................................................................................... 8 
2.2 - Modelagem dos casos de uso ......................................................... 9 
2.2.1 - Cadastro Cliente ................................................................................... 9 
2.2.1 - 1 - Fluxo de Trabalho .......................................................................... 10 
2.2.1 - 2 - Requisitos relacionados ................................................................. 10 
2.2.2 - Cadastro de produto .................................................................. 11 
2.2.2 - 1 - Fluxo de Trabalho .......................................................................... 12 
2.2.2 - 2 - Requisitos relacionados ................................................................. 12 
2.2.3 - Efetuar vendas ........................................................................... 13 
2.2.3 - 1 - Fluxo de Trabalho .......................................................................... 14 
2.2.3 - 2 - Requisitos relacionados ................................................................. 14 
2.3 - Regras de uso ............................................................................... 15 
2.3.1 - Login .................................................................................................. 15 
2.3.2 - Cadastro de usuário ........................................................................... 16 
2.3.3 - Cadastro de produto........................................................................ 16 
2.3.4 - Cancelamento de vendas ................................................................... 16 
2.4 - Contexto de Uso ........................................................................... 16 
2.4.1 - Usuários e tarefas .............................................................................. 16 
2.4.2 Ambiente .............................................................................................. 17 
3 - Requisitos................................................................................................. 17 
3.1 - Requisitos funcionais .................................................................... 18 
3.2 - Requisitos não funcionais ............................................................. 18 
 
 
3.3 - Requisitos não funcionais de usabilidade ...................................... 20 
4 - Diagrama de classes de análise ............................................................... 21 
4.1 - Diagrama de Classes .................................................................... 21 
4.2 - Diagrama de Objetos .................................................................... 22 
4.3 - Classes de análises ...................................................................... 22 
4.3.1 - Elaboração do diagrama de classe de análise .................................... 23 
4.4 - Modelo de entidade-relacionamento (MER) .................................. 23 
4.4.1 - Entidades, atributos e relacionamentos .............................................. 23 
Conclusão ..................................................................................................... 26 
Referência Bibliográfica ................................................................................. 27 
Apêndice A - Diagrama de Classes de Análise .............................................. 28 
Apêndice B - Diagrama Entidade-Relacionamento (DER) ............................. 29 
 
 
 
 
 
 
 
 
 
 8 
 
1 - Introdução 
Cada vez ais as soluções tecnológicas estão sendo procuradas para 
automatização, produtividade, segurança, controle e muitos outros fatores trazendo 
melhorias para empresas, profissionais, processos e pessoas que se beneficiam. 
Uma empresa no ramo de vendade jogos, acessórios e produtos geek sentindo 
a necessidade de obter um sistema que controle seus estoques e vendas procurou a 
empresa júnior para desenvolver um projeto para esse sistema. Foi feito o 
levantamento de requisitos junto ao cliente, a identificação dos casos de uso onde 
temos como principais casos: cadastro de clientes e cadastro de produtos, ambos com 
extensões para alteração, exclusão e consulta de produtos separados por categorias. 
Para efetuar venda teremos dados do cliente, dado do produto, exclusão de produto, 
cancelamento de venda, consulta de preço e os atores (usuários) do serão: estoquista, 
atendente e supervisor, todos com login e senha com níveis de acesso de acordo com 
suas responsabilidades. E no back end o sistema contará com um banco de dados 
elaborado e planejado para suprir todas as permissões e necessidades do sistema, 
trazendo segurança e informação de qualidade conforme os requisitos do cliente. 
 
2 - Casos de Uso 
2.1 - Requisitos 
Em reunião com cliente para produção de um sistema de automatização do 
estoque, o sistema em um âmbito geral irá controlar o estoque dos produtos e as 
vendas. O acesso ao sistema será através de login e senha com 3 níveis de acesso: 
estoquista, atendente e supervisor. 
O estoquista terá acesso ao cadastro de produtos onde será possível salvar, 
alterar, excluir e consultar os dados dos produtos que terão as categorias de jogos, 
acessórios e produtos geek. 
O atendente por sua vez terá acesso ao cadastro de clientes, podendo também 
salvar, alterar, excluir e consultar os dados dos clientes e é o atendente que realiza 
as vendas da loja onde constarão os dados da venda como código da venda, data, 
valores, formas de pagamento e status de pagamento e venda, constará os dados do 
cliente e os dados dos produtos. 
 9 
 
O supervisor tem acesso em todo o sistema, sendo responsável pela exclusão 
de um produto na venda ou o cancelamento de toda a venda utilizando usuário e 
senha válidos, no cancelamento da venda o código da venda é enviado para o sistema 
financeiro. Analisando os requisitos e em vista dos modelos de mercado: 
Casos de Uso: 
• RF 01 – Cadastrar cliente; 
• RF 02 – Alterar cliente; 
• RF 03 – Excluir cliente; 
• RF 04 – Consultar cliente; 
• RF 05 – Cadastrar produto; 
• RF 06 – Alterar produto; 
• RF 07 – Excluir produto; 
• RF 08 – Consultar produto; 
• RF 09 – Efetuar venda; 
• RF 10 – Excluir venda; 
• RF 11 – Cancelar venda; 
• RF 12 – Buscar cliente; 
• RF 13 – Consultar preço; 
• RF14 – Efetuar login (usuário e senha). 
2.2 - Modelagem dos casos de uso 
2.2.1 - Cadastro Cliente 
• Identificação: Cadastrar cliente; 
• Escopo: Sistema de vendas e cadastros com controle de estoque; 
• Descrição do propósito: Esse caso de uso permite ao atendente ou 
supervisor realizar o cadastro de clientes no sistema da loja; 
• Ator primário: atendente e supervisor; 
• Interessados: Loja e cliente; 
• Pré condições: O sistema da loja deve estar operacional; 
 10 
 
• Pós condições: O atendente ou supervisor pegam os dados do cliente e 
salvam no sistema. 
2.2.1 - 1 - Fluxo de Trabalho 
1. O atendente ou supervisor clica em cadastrar cliente; 
2. Inclusão para validar nível de acesso: 
a. Caso nível de acesso seja incompatível, uma mensagem é 
exibida; 
b. Caso login e senha estejam incorretos, uma mensagem é exibida; 
3. Login e senha válidos são informados; 
4. O sistema exibe o formulário de cadastro de cliente com todas as 
opções; 
5. Os dados do cliente são preenchidos; 
6. Opção salvar os dados são armazenados no sistema, uma mensagem é 
exibida: 
a. Caso existam campos em branco, uma mensagem é exibida; 
b. Extensão para alterar dados do cliente; 
c. Extensão para excluir um cliente; 
d. Extensão para consultar um cliente; 
 
2.2.1 - 2 - Requisitos relacionados 
• RF 02 - Alterar cliente; 
• RF 03 - Excluir cliente; 
• RF 04 - Consultar cliente; 
• RF 14 - Efetuar login com nível de acesso. 
 
 
 
 
 
 
 
 
 11 
 
 
 
 
 
 
 
 
 
 
Figura 01 - Tela Login 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 02 - Tela Cadastro Cliente 
 
2.2.2 - Cadastro de produto 
• Identificação: Cadastrar produto; 
• Escopo: Sistema de vendas e cadastros com controle de estoque; 
• Descrição do propósito: Esse caso de uso permite ao estoquista ou 
supervisor realizar o cadastro de produtos no sistema da loja; 
• Ator primário: estoquista e supervisor; 
 12 
 
• Interessados: Loja e cliente; 
• Pré condições: O sistema da loja deve estar operacional; 
• Pós condições: O estoquista ou supervisor pegam os dados do produto 
e salvam no sistema. 
 
2.2.2 - 1 - Fluxo de Trabalho 
1. O estoquista ou supervisor clica em cadastrar cliente; 
2. Inclusão para validar nível de acesso: 
a. Caso nível de acesso seja incompatível, uma mensagem é 
exibida; 
b. Caso login e senha estejam incorretos, uma mensagem é exibida; 
3. Login e senha válidos são informados; 
4. O sistema exibe o formulário de cadastro de cliente com todas as 
opções; 
5. Os dados do produto são preenchidos; 
6. Opção salvar os dados são armazenados no sistema, uma mensagem é 
exibida: 
a. Caso existam campos em branco, uma mensagem é exibida; 
b. Extensão para alterar dados do cliente; 
c. Extensão para excluir um cliente; 
d. Extensão para consultar um cliente; 
 
2.2.2 - 2 - Requisitos relacionados 
• RF 06 - Alterar produto; 
• RF 07 - Excluir produto; 
• RF 08 - Consultar produto; 
• RF 14 - Efetuar login com nível de acesso. 
 
 
 
 13 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 03 - Sistema Cadastro Produto 
 
 
 
 
 
 
 
 
 
Figura 04 - Tela Cadastro Produto 
 
2.2.3 - Efetuar vendas 
• Identificação: Efetuar venda; 
• Escopo: Sistema de vendas e cadastros com controle de estoque; 
 14 
 
• Descrição do propósito: Esse caso de uso permite ao atendente ou 
supervisor efetuar a venda de produtos no sistema da loja; 
• Ator primário: atendente e supervisor; 
• Interessados: Loja e cliente; 
• Pré condições: O sistema da loja deve estar operacional; 
• Pós condições: Os produtos são adicionados a venda é efetuada o 
pagamento realizado e a venda concluída. 
 
2.2.3 - 1 - Fluxo de Trabalho 
1. O atendente ou supervisor seleciona efetuar venda; 
2. Inclusão para validar nível de acesso: 
a. Caso nível de acesso seja incompatível, uma mensagem é 
exibida; 
b. Caso login e senha estejam incorretos, uma mensagem é exibida; 
3. Login e senha válidos são informados; 
4. O sistema exibe a tela de vendas com todas as opções; 
5. Os produtos são adicionados através do código de barras, valor total é 
atualizado; 
a. Caso produto não esteja cadastrado, uma mensagem é exibida; 
b. Caso produto não esteja cadastrado, digitar código manualmente; 
c. Extensão para buscar dados do cliente; 
d. Extensão para cancelar a venda; 
e. Extensão para consultar preço. 
6. A forma de pagamento é selecionada; 
7. Opção efetuar venda, pagamento é realizado; 
8. Inclusão para atualizar o estoque; 
9. Inclusão para finalizar a venda. 
 
2.2.3 - 2 - Requisitos relacionados 
• RF 10 - Excluir produto; 
• RF 11 - Cancelar venda; 
 15 
 
• RF 12 - Busca cliente; 
• RF 13 - Consultar preço; 
• RF 14 - Efetuar login com nível de acesso. 
 
 
 
 
 
 
 
 
 
Figura 05 - Sistema de Vendas 
 
 
 
 
 
 
 
Figura 06 - Tela de Vendas 
 
2.3 - Regras de uso 
Foram determinadas as seguintes regras de uso para o sistema. Dentre elas 
estão: 
2.3.1 - Login 
• Só usuários pré cadastrados poderão ter acesso ao sistema; 
 16 
 
• Somente funcionários terão acesso direto ao sistema; 
• Somente usuários com função de administrador poderão cadastrar e 
excluir usuários; 
2.3.2 - Cadastro de usuário 
• Deve ser feito o cadastro de todos os clientes para efetuar a compra; 
• Somente usuários com função de atendente e/ou administrador poderão 
cadastrar clientes; 
• Somente usuárioscom função administrador poderão alterar e excluir 
cadastro de clientes. 
2.3.3 - Cadastro de produto 
• Somente usuários com função de estoquista e/ou administrador poderão 
cadastrar os produtos; 
• Todos os produtos devem ser cadastrados para possibilitar a venda e o 
controle do movimento; 
• Todos os dados devem ser preenchidos para efetuar o cadastro do 
produto. 
2.3.4 - Cancelamento de vendas 
• Somente usuários com função de administrador poderão cancelar uma 
venda. 
 
2.4 - Contexto de Uso 
2.4.1 - Usuários e tarefas 
Os usuários que utilizam o sistema são separados por funções, classificando e 
estabelecendo para cada um, uma forma separada e organizada de interação perante 
o software. Cada usuário necessita de um tipo específico de ambiente e 
funcionalidades, mas com praticidade e desempenho durante o manuseio. 
Dentre os usuários, temos os atendentes, que necessitam ter um fácil acesso 
e ao mesmo tempo detalhado sobre todos os produtos para que possa ser repassado 
ao cliente e ao final a geração da compra. 
 17 
 
Os estoquistas, que necessitam fazer a verificação, validação e cadastramento 
de todos os produtos do estoque. Tudo de forma clara e ágil. 
Os supervisores/administradores, que por segurança tem acesso a todo o 
sistema, garantindo uma segurança e total gerenciamento sobre o sistema. 
 
2.4.2 Ambiente 
Dentro do ambiente, temos um sistema de banco de dados, que ficam em um 
servidor separado dos computadores de atendimento, utilizando um maior 
processamento e acesso ao disco rígido. 
Propriamente instalado em uma sala com ar condicionado e acesso restrito. Os 
servidores estão diretamente conectados ao sistema base, onde é agrupado e 
alocado todos os dados do sistema, como: dados dos usuários, senhas, produtos, etc. 
Os softwares de cadastro serão instalados em computadores desktops, que 
servirão de base para a comunicação e registro com o banco de dados. 
Com acesso aberto a usuários que tem registro sobre o sistema, é possível 
acessar diferentes máquinas sem interferir nas configurações pré estabelecidas em 
cada usuário. 
 
3 - Requisitos 
Segundo Sommerville (2010), requisitos são serviços que um sistema deve 
prestar e suas restrições de funcionamento. Eles devem necessariamente refletir as 
necessidades do cliente e são classificados em dois níveis: requisitos de usuário e 
requisitos de sistema. 
Os requisitos de usuário são declarações em linguagem natural com diagramas 
de quais serviços o sistema deverá fornecer a seus usuários e as restrições com as 
quais ele deve operar. Eles devem ser direcionados aos clientes, usuários, gerentes 
de projeto e arquitetos de sistema, pois definem em alto nível as necessidades, o que 
define, entre outras coisas, o escopo do projeto. 
Os requisitos de sistema são descrições mais detalhadas das funções, serviços 
e restrições operacionais do sistema de software. Eles devem ser direcionados a 
 18 
 
usuários, arquitetos de sistema e desenvolvedores, pois podem definir uma sequência 
de implementação, o que influencia diretamente na solução dada. 
Além da classificação em níveis, os requisitos também são categorizados em: 
requisitos funcionais e requisitos não funcionais. 
 
3.1 - Requisitos funcionais 
Os requisitos funcionais (RF) descrevem o comportamento esperado de um 
sistema de software, explicita o que o sistema deve fazer e idealmente o que o sistema 
não deve fazer (SOMMERVILLE, 2010). 
 
3.2 - Requisitos não funcionais 
Os requisitos não funcionais (RNF) descreem restrições sobre os serviços 
oferecidos pelo sistema de software (SOMMERVILLE, 2010). 
Os requisitos funcionais são insuficientes pra descrever o sistema de software, 
pois é necessário descrever os outros aspectos: atributos do sistema e atributos do 
ambiente do sistema, normalmente classificados como requisitos não funcionais. Há 
várias propostas para classificação de requisitos não funcionais (SOMMERVILLE, 
2010), por exemplo: classificando-os de acordo com o representado na figura 07. 
 
 
 
 
 
 
 
 
 
 
 19 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 07 - Diagrama de Requisitos Não Funcionais (Fonte: Versollato, 2015) 
 
Além da proposta de Sommerville (2010), a norma ISSO/IEC 25010:2011 
também trata da classificação e definição de requisitos não funcionais. A norma 
descreve seis características que definem a qualidade de software: funcionalidade, 
confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. Essas 
características, também denominadas atributos de qualidade, são comumente usadas 
quando trabalhamos com requisitos não funcionais. A figura 08 mostra a estrutura 
hierárquica dos atributos de qualidade, quanto a sua classificação proposta pela 
norma ISSO 25010. 
 20 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 08 - Diagrama de Atributos de Qualidade (Fonte: Versollatto, 2015) 
 
3.3 - Requisitos não funcionais de usabilidade 
Neste projeto, apresento os requisitos não funcionais de usabilidade do sistema 
de software. Tal sistema possui fácil utilização sem muitos recursos gráficos, com 
adição de descrições das funções aos botões e configurações de teclas de atalho para 
as funções mais utilizadas. 
De acordo com uma definição tradicional, a usabilidade consiste de cinco 
fatores: 
• RNF 01 – Facilidade de Aprendizagem: Um usuário com um nível 
especificado de experiência deve aprender como usar o sistema em um 
determinado prazo especificado. 
• RNF 02 – Eficiência da Tarefa: Um usuário deve poder terminar uma 
determinada tarefa em um prazo especificado (ou em uma quantidade 
de cliques do mouse). 
 21 
 
• RNF 03 – Facilidade de Recordação: Um usuário deve poder recordar 
como se realizam determinadas tarefas, após um prazo especificado de 
não utilização do sistema. 
• RNF 04 – Entendimento: Um usuário deve entender as mensagens e os 
alertas do sistema e o que o sistema faz. 
• RNF 05 – Satisfação Subjetiva: Uma porcentagem especificada da 
comunidade de usuários deve expressar a satisfação de usar o sistema. 
Para identificação e especificação dos requisitos não funcionais de usabilidade, 
utiliza-se o seguinte método: 
1. Identificar as principais questões de usabilidade observando as tarefas 
críticas, perfis de usuário, metas do sistema e problemas prévios de 
usabilidade. 
2. Escolher um estilho apropriado para expressar os requisitos: 
a. Estilo de Desempenho: Especifica a velocidade que os usuários 
podem aprender várias tarefas e a velocidade que eles podem 
executar as tarefas após treinamento. 
b. Estilo Defeito: Melhor do que medir os tempos da tarefa, identifica 
os defeitos de usabilidade e especifica a frequência com que eles 
ocorrem. 
c. Estilo de Diretriz: Especifica a aparência geral e o tempo de 
resposta da interface de usuário pela referência a um padrão 
aceito e bem definido. 
3. Escrever requisitos reais, incluindo critérios de desempenho. 
 
4 - Diagrama de classes de análise 
4.1 - Diagrama de Classes 
Diagrama de classes é um diagrama UML que tem como objetivo representar 
a estrutura estática das classes de um sistema de software (BOOCH, et al., 2006). 
Pode ser definido também como a representação das classes, seus atributos, 
métodos e o relacionamento entre essas classes (VERSOLATTO, 2015). 
 22 
 
4.2 - Diagrama de Objetos 
Diagrama de objetos é um diagrama que tem como objetivo representar 
instâncias de classes, ou seja, objetos e suas respectivas ligações ou associações. 
Logo, podemos dizer que a base do diagrama de objetos é o diagrama de classes. 
Por meio do diagrama de objetos tem-se uma visão dos objetos, suas informações e 
seus relacionamentos em um determinado cenário em determinado momento de 
execução desse cenário. 
Os diagramas de classes e de objetos são os principais diagramas que 
representam a visão estrutural estática de um sistema, todavia, em um sistema 
existemaspectos dinâmicos, reações e respostas que o sistema produz e que não 
são captadas nessas representações. 
4.3 - Classes de análises 
 A partir da visão estrutural estática, representada pelos modelos de classes e 
de objetos, originou-se o modelo estrutural dinâmico, por meio do qual ocorre a 
realização dos casos de uso, ou seja, como efetivamente os objetos se relacionam 
entre si de forma, dinâmica. Para isso, antes da definição de como uma tarefa será 
realizada, determinam-se as responsabilidades de cada objeto. 
Os objetos são divididos e categorizados em três grupos de acordo com seu 
tipo de responsabilidade: classe entidade, classe fronteira e classe de controle, 
também chamadas de classes de análise. 
A classe entidade é o objeto mais próximo do mundo real que o sistema 
representa e tem como objetivo principal manter informações referentes ao domínio 
de problema que queremos resolver. 
A classe de fronteira tem como responsabilidade dividir o ambiente interno do 
sistema e suas interações externas. 
A classe de controle tem como objetivo realizar o sequenciamento da execução 
de um caso de uso na estrutura de objetos do sistema, fazer a coordenação entre 
camadas internas do sistema, representadas pelas classes de entidade, com as 
camadas externas do sistema, representadas pelas camadas de fronteira. 
 23 
 
4.3.1 - Elaboração do diagrama de classe de análise 
O Apêndice A apresenta o diagrama de classes de análise do projeto do 
sistema de software, elaborado com base na identificação dos substantivos do texto 
e dos casos de uso; o relacionamento entre eles com seus respectivos nomes e a 
multiplicidade entre as classes identificadas. O diagrama mostra também os atributos 
e métodos de cada classe e a existência de agregações e heranças. 
4.4 - Modelo de entidade-relacionamento (MER) 
O modelo entidade-relacionamento (MER) é um tipo de modelo conceitual que 
descreve os objetos (entidades), suas características (atributos) e como se relacionam 
(relacionamento). Considerando um modelo de alto nível, tem como objetivo 
representar um arranjo de dados mais perto do mundo real, como salienta Pinto (2020, 
p36), é um modelo abstrato desenvolvido pelo Prof. Peter Chen, a fim de representar 
as estruturas de dados de forma mais natural e mais próxima do mundo real dos 
negócios. Partindo desta afirmativa, podemos entender que o modelo reproduz 
aspectos abstratos que a estrutura possuirá no banco de dados da aplicação. Sendo 
assim, utilizamos os recursos do MER para desenvolver o diagrama entidade-
relacionamento (DER) o qual é a sua representação gráfica. 
4.4.1 - Entidades, atributos e relacionamentos 
O objeto principal da entidade-relacionamento é a entidade, pois é por meio 
dela que são representadas as categorias de fatos do mundo real. Segundo Pinto 
(2020, p.33), representam categorias de fatos do mundo real, sejam eles concretos 
ou abstratos, como empregados, departamentos, despesas, etc, ou seja, podem 
classificadas em entidade física e entidade lógica. 
Conforme o sítio Devmedia, as entidades físicas são existentes e visíveis no 
mundo real, por exemplo, um atendente de um cliente (ex.: uma pessoa) ou até 
mesmo um produto (ex.: um computador). Entidades lógicas existem em decorrência 
da interação entre ou com entidades físicas que fazem sentido dentro de um certo 
domínio de negócios, mas no mundo externo/real não são objetos físicos (ex.: uma 
função de um usuário do sistema). 
Partindo dessa conjectura podemos classificar as entidades como : fortes, 
fracas e associativa. 
 24 
 
• Entidades fortes: são aquelas que existem independentemente de 
outras entidades. Ela possui total sentido para existir. Em nosso sistema 
de vendas por exemplo, a entidade produto existe sem que outra 
entidade exista. 
• Entidades fracas: diferente das entidades fortes, as fracas dependem 
que outras entidades existam, pois ela só não faz sentido, a exemplo, a 
entidade do nosso sistema de vendas depende da entidade produto, 
sendo assim, uma venda sem itens não faz sentido. 
• Entidades associativas: surgem quando há a necessidade de associar 
uma entidade a um relacionamento existente. Na modelagem entidade-
relacionamento não é possível que um relacionamento seja associado a 
uma entidade. Então tomamos esse relacionamento uma entidade 
associativa, que a partir daí poderá se relacionar com outras entidades, 
conforme descrito no sítio Devmedia. 
• Atributos: são a representação de uma propriedade de uma entidade ou 
de um relacionamento, ou seja, são as características usadas para 
descrever cada entidade dentro do domínio, podendo ser descritivo os 
quais representam características particulares (ex.: nome, cor), 
nominativos além de descritos tem a função de identificar e definir o 
objeto (ex.: número, código) e referenciais que é a ligação de uma 
entidade a outra em um relacionamento (ex.: CPF relaciona com a 
entidade vendas). 
• Relacionamento: é a representação das associações entre entidades 
indicadas através das cardinalidades que é o número de ocorrências de 
uma entidade que se relaciona com outra. 
• Relacionamentos um para um (1-1): nesse tipo de relacionamento cada 
uma das entidades se referenciam obrigatoriamente apenas uma 
unidade da outra. 
• Relacionamentos um para muitos (1-n ou 1..*: nesse tipo de 
relacionamento uma das entidades pode referenciar várias unidades da 
outra. 
 25 
 
• Relacionamentos muitos para muitos (n-n ou *.*): neste tipo de 
relacionamento cada entidade, de ambos os lados, podem referenciar 
múltiplas unidades da outra. 
A figura 09, ilustra a representação gráfica do modelo entidade-relacionamento 
(MER) e o diagrama de entidade-relacionamento (DER). A partir do diagrama de 
classes foram identificadas as classes que precisaram ser persistidas com suas 
respectivas tabelas. Assim como, foram criadas as chaves primárias de cada tabela. 
As relações do tipo 1..n também foram especificadas e propagadas a chave 
estrangeira para o lado n. da mesma forma, as relações do tipo n..n foram 
confeccionadas justamente com suas tabelas de relacionamento, contendo as chaves 
primárias das tabelas envolvidas nessa relação. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 09 - Modelo de entidade-relacionamento (MER) 
 
 
 
 26 
 
Conclusão 
Neste Projeto Integrado Multidisciplinar (PIM), apresentou-se um projeto para 
desenvolvimento de um sistema para uma loja. Seu objetivo era poder realizar 
cadastro de novos usuários e clientes, salvado seus dados em um banco de dados 
relacional, para recuperação posterior. 
Para isso foi realizado o levantamento e análise de requisitos junto ao cliente, 
para saber quais suas necessidades para o projeto. 
Um dos pontos a se analisar era o fato de se ter níveis de acesso diferentes 
para cada tipo de usuário, assim restringindo o acesso não autorizado de dados 
sensíveis. 
Para definir a estrutura do banco de dados foi utilizado o Modelo Entidade-
Relacional (MER) e Diagrama Entidade-Relacional (DER). Também foi apresentado o 
diagrama de classes de análise, com este diagrama podemos modelar de forma mais 
precisa o software do cliente e os dados a serem armazenados. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 27 
 
Referência Bibliográfica 
Versolatto, Fábio Rossi. Análise Orientada a Objetos. – São Paulo: Editora Sol, 2015. 
172 p. il. 
PINTO, Gisele Lopes Batista. Administração de banco de dados. São Paulo: Editora 
Sol, 2020. 
DEVMEDIA. Modelo Entidade Relacionamento (MER) e Diagrama Entidade-
Relacionamento (DER). Disponível em: <https://www.devmedia.com.br/modelo-
entidade-relacionamento-mer-e-diagrama-entidade-relacionamento-der/14332&gt>. 
Acesso em: 04 de maio de 2021. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 28 
 
Apêndice A - Diagrama de Classes de Análise 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 29 
 
ApêndiceB - Diagrama Entidade-Relacionamento (DER)