Pim V
ADS
análise e desenvolvimento de
sistemas
UNIVERSIDADE PAULISTA – UNIP
PROJETO INTEGRADO MULTIDISCIPLINAR V
UNIVERSIDADE PAULISTA – UNIP
GOIÂNIA GOIAS 2025
ITALO DE JESUS BARROS
RE: 2420271
PROJETO INTEGRADO MULTIDISCIPLINAR V
Trabalho apresentado ao
curso de Análise e
Desenvolvimento de Sistemas,
Como Requisito para obtenção de
nota Apresentado à Universidade
Paulista - UNIP.
Orientador: Ma. Gislaine starchissini
Goiânia 2025
Resumo
Este trabalho visa realizar e apresentar o levantamento e análise de
requisitos de um sistema de controle de vendas de uma loja Geek,
contando com games, acessórios e diversos outros produtos na
mesma temática, tendo em base o conhecimento adquirido nas
matérias cursadas nesse bimestre. Levando em consideração um
sistema com funcionalidades de cadastramento, alterações, consultas
e exclusões, dos produtos vendidos na loja, o sistema também terá
cadastro de clientes e controle de acesso dos funcionários validados
por login e senha. Serão abordados os processos de negócio, assim
como as operações que serão automatizadas. O trabalho mostrará os
modelos de casos de uso destas operações e contará com a
descrição de seus comportamentos e fluxos principais. O projeto
conta com o levantamento dos requisitos funcionais/não funcionais e
das regras de negócio.
Palvras-chave: Games, Geek, Sistema, Vendas, Negócio.
Abstract
This work aims to carry out and present the survey of products and
analysis of requirements of a sales control system of a Geek store,
with games, accessories and several other topics, based on the
knowledge acquired in the courses in this bimester. Taking into
account a system with functionality for registering, altering, consulting
and excluding products sold in the store, the system will also have
customer registration and employee access control validated by login
and password. It will be the business processes as well as the
operations that will be performed. The work shows the use case
models of the operations and will have the description of their main
behaviors and flows. The project includes the survey of
functional/non-functional requirements and business rules.
Keywords: Games, Geek, System, Sales, Business.
Lista de Figuras
Introdução
Para qualquer negócio é de extrema importância o controle de
vendas, seja ele como for, administrar o fluxo do que entra e o que sai
é vital para sobrevivência do seu negócio.
Porém, controlar seu fluxo utilizando planilhas como o famoso Excel,
por exemplo, não nos garante a centralização dos dados nem a
consistência nas informações. Por isso é mais que necessário um
sistema que abrange informações integradas, relatórios em tempo
real e, além disso, assegurar a integridade dos dados.
Tendo isso em mente, o objetivo desse trabalho é desenvolver um
sistema do tipo Desktop de controle e gerenciamento de vendas de
produtos e acessórios na ampla área da cultura Geek.
Acompanhando o mercado, se nota que sistemas proporcionam um
sistema completo de gestão. Assim como total controle de estoque,
cadastro de produtos, cadastro de fornecedores, conferência de
estoque, controle de data de validade e entrada de estoque via XML.
Portanto, para que o desenvolvimento deste software, irá ser
implementado junto ao que já foi anteriormente definido como o
cliente, o histórico de movimentação de estoque, notificação de
estoque mínimo e fim de estoque.
Para elaboração deste trabalho, o projeto se baseia nos
conhecimentos obtidos nas disciplinas estudadas durante o bimestre.
Levantamento e análise de requisitos
A primeira etapa do ciclo de desenvolvimento de um software é o
levantamento de requisitos, como ele podemos identificar as
necessidades que o cliente espera que o sistema possa solucionar. É
nessa primeira etapa, inclusive, que as funcionalidades e o escopo do
projeto são definidos. São dois tipos de requisitos que compõem um
sistema: os Requisitos Funcionais (RF) e os Requisitos Não
Funcionais (RNF).
Para realizar o levantamento de requisitos, existem diversas técnicas
que podem ser usadas variando com o perfil do cliente. A escolha foi
pela entrevista desde o primeiro momento para coletar os requisitos e
observar o cenário apresentado. Após isso, para filtrar as
informações, foi finalizado com o uso de um questionário.
Requisitos Funcionais
Requisitos Funcionas são as necessidades que devem ser atendidas
pelo sistema, através de suas funcionalidades. O sistema proposto
pelo cliente deve possuir três níveis de acesso: atendente, estoquista
e supervisor. O atendente deve ser capaz de realizar uma venda,
cadastrar ou editar clientes, consultar produtos e preços, além de
excluir produtos de uma determinada venda, porém, para isso, será
necessário que o seu supervisor autorize através de sua autenticação
no sistema. O estoquista terá permissão apenas para cadastrar ou
editar produtos, respeitando o grau de hierarquia dos mesmos. O
supervisor terá o acesso completo ao sistema.
Identificador Requisito
RF01 Cadastrar Clientes
RF02 Editar Clientes
RF03 Excluir Clientes
RF04 Consultar Clientes
RF05 Cadastrar Produtos
RF06 Editar Produtos
RF07 Excluir Produtos
RF08 Consultar Produtos
RFO9 Inserir Venda
RF10 Cancelar Venda
RF11 Consultar Venda
RF12 Cadastrar Funcionário
RF13 Excluir Funcionário
Tabela 1 – Requisitos Funcionais – Fonte: Autor
Requisitos Não Funcionais
“Requisitos Não Funcionais são premissas ou restrições que o
sistema deverá atender, mas que não são realizados através de
funcionalidades.” (VENTURA, 2016), ou seja, apenas os requisitos
funcionais não são o suficiente para o desenvolvimento do software, é
preciso também ser levado em conta outros aspectos que não estão
ligados diretamente a funcionalidades do sistema, mas que são
essenciais para determinar como serão executadas as ações do
sistema e aspectos de qualidade do projeto.
A figura a seguir é uma adaptação de Sommervile (2007) onde
apresenta os subconjuntos de quesitos que devem ser atendidos em
um software
Figura 1 – Requisitos Não Funcionais – Fonte:
Sommerville,2007 Entretanto, nesse projeto serão abordados
os seguintes tópicos:
• Disponibilidade: Nesse requisito é medido o tempo em que
o sistema está disponível para a utilização, por exemplo, as
necessidades de paradas para manutenção.
• Usabilidade: Especifica o nível de desempenho e satisfação do
usuário ao usar o sistema como por exemplo: facilidade de
aprender e facilidade de uso.
• Desempenho: Categoria voltada a garantir que o software seja
executado sem problemas que possam impactar na qualidade
do uso do sistema, como por exemplo lentidão.
• Segurança: É a categoria onde são definidas as regras de
proteção para criação e armazenamento de dados como, por
exemplo implementação de senhas e a necessidade de
criptografar os dados gerados.
• Usabilidade: Especifica o nível de desempenho e satisfação do
usuário ao usar o sistema como por exemplo: facilidade de
aprender e facilidade de uso.
• Interoperabilidade: Nesse requisito são especificadas as
necessidades de implementação do sistema se comunicar com
outras aplicações, isto é a habilidade do sistema tanto importar
quanto exportar informações de maneira eficiente
• Compatibilidade: Nessa categoria, são levantados os
requisitos referentes a compatibilidade para execução do
software em versões diferentes de navegadores e
sistemas operacionais.
• Confiabilidade: Nessa categoria são definidos como devem
funcionar as rotinas de backup, formas de controle para
garantir a integridade de dados caso ocorra uma
indisponibilidade do sistema.
• Padrões: Por fim os requisitos de padrões definem qual
será a metodologia adotada para o desenvolvimento do
projeto como por exemplo linguagem de programação e
hardware.
Identificador Requisito
RNF01 Sistema Multiplataforma
RNF02 Design Responsivo
RNF03 Informações em tempo real
RNF04 Adoção de boas práticas de
usabilidade
RNF05 Video tutorial e documentação
disponível para acesso no
sistema
RNF06 Apenas usuários cadastrados
conseguem logar no sistema
RNF07 Tempo de resposta e
recuperação mais curtos
possíveis
RNF08 Programação orientada a objeto
RNF09 Rotina de backup diário ou
semanal
Tabela 2 – Requisitos não funcionais – Fonte: Autor.
Casos de Uso
Uma das formas de especificar requisitos é através do diagrama de
Caso de Uso. Neles, nós temos um cenário, onde um ou mais atores
executam uma sequência de eventos. Estes eventos são tarefas
realizadas pelos atore.
Ventura (2016) define "...representar como os casos de uso integram
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".
Modelagem de Casos de Uso
A seguir é possível verificar como será o fluxo de funcionamento dos
casos de uso aplicados neste trabalho e como o sistema funcionará:
Figura 2 Diagrama de cadastro de Produtos- Fonte: Autor
Objetivo Realizar o cadastro de novos
produtos ou editar produtos
existentes
Requisitos Cadastrar produtos, Editar produtos,
Excluir produtos, Consultar produtos
Atores Estoquista, Supervisor
Prioridade Alta
Pré-condições Os usuários devem estar
cadastrados no sistema, tendo
usuário e senha
Frequência de uso Média
Pós condições Os Produtos terão cadastro no
sistema e contagem de estoque
Campos Categoria (jogos, acessórios e
produtos geek), código de barras,
nome do produto, fabricante,
quantidade e valor do produto. Para
os jogos e os acessórios: em qual
plataforma serão utilizados e qual o
prazo de garantia que o produto
possui;
Fluxo Principal 1) Estoquista ou Supervisor clica em
"Cadastrar produto"; 2) Sistema
valida o login através de usuário e
senha; 3) O sistema exibe os campos
obrigatórios para cadastrar o produto;
4) Atendente ou Supervisor preenche
todos os dados e clica em "Salvar
produto"; 5) Sistema efetiva o
cadastro atribuindo um código ao
produto cadastrado.
Fluxo alternativo 1) Estoquista ou Supervisor clicará
em "Editar produto"; 2) Sistema
mostrará os campos para pesquisa;
3) Estoquista ou Supervisor preenche
o campo que deseja pesquisar; 4)
Sistema mostra o cadastro existente
do produto; 5) Estoquista ou
Supervisor pode fazer alterações nas
informações do produto e clicar em
"Salvar produto" ou clicar em "Excluir
produto"; 6) Sistema efetiva a
alteração ou exclusão.
Fluxo de exceção No fluxo principal 2: 2.1) Caso não
tenha validação, aparecerá
mensagem de erro; 2.2) Caso o
usuário ou senha estejam incorretos,
;
aparecerá mensagem de erro; No
fluxo principal 4: 4.1) Mensagem de
erro caso falte informação
obrigatória; No fluxo alternativo 4:
A4.1) Caso não tenha cadastro, o
sistema mostrará uma mensagem de
erro;
Validações Todos os campos serão obrigatórios,
com exceção da garantia e
plataforma para os produtos geek
Tabela 3 – Cadastro de Produtos Fonte: Autor
Figura 3 – Tela de Cadastro de Produtos – Fonte: Autor
Figura 4 – Diagrama cadastro de Clientes Vendas – Fonte: Autor
Objetivo Realizar o cadastro de novos clientes
ou editar clientes existentes
Requisitos Cadastrar clientes, Editar clientes,
Excluir clientes, Consultar clientes
Atores Atendente, Supervisor
Prioridade Alta
Pré-condições Os usuários devem estar
cadastrados no sistema, tendo
usuário e senha
Frequência de Uso Alta
Pós-Condições Os clientes terão cadastro no sistema
e poderão realizar as compras na loja
Campos Código, RG, CPF, nome, data do
cadastro, endereço, telefone e e-mail
do cliente
Fluxo de Principal 1) Atendente ou Supervisor clica em
"Cadastrar cliente"; 2) Sistema valida
o login através de usuário e senha; 3)
O sistema exibe os campos
obrigatórios para cadastrar o cliente;
4) Atendente ou Supervisor preenche
todos os dados e clica em "Salvar
cliente"; 5) Sistema efetiva o cadastro
atribuindo um código ao cliente
cadastrado.
Fluxo Alternativo 1) Atendente ou Supervisor clicará
em "Editar cliente"; 2) Sistema
mostrará os campos para pesquisa;
3) Atendente ou Supervisor preenche
o campo que deseja pesquisar; 4)
Sistema mostra o cadastro existente
do cliente; 5) Atendente ou
Supervisor pode fazer alterações nas
informações do cliente e clicar em
"Salvar cliente" ou o Supervisor pode
clicar em "Excluir cliente"; 6) Sistema
efetiva a alteração ou exclusão.
Fluxo de Exceção No fluxo principal 2: 2.1) Caso não
tenha validação, aparecerá
mensagem de erro; 2.2) Caso o
usuário ou senha estejam incorretos,
aparecerá mensagem de erro; No
fluxo principal 4: 4.1) Mensagem de
erro caso falte informação
obrigatória; No fluxo alternativo 4:
A4.1) Caso não tenha cadastro, o
sistema mostrará uma mensagem de
erro;
Validações Apenas os campos telefone e e-mail
do cliente não serão obrigatórios
Tabela 4 – Cadastro de Clientes – Fonte: Autor
Figura 5 – Cadastro de Clientes – Fonte: Autor
Objetivo Realizar Vendas
Requisitos Cadastrar produtos, Editar produtos,
Excluir produtos, Consultar produtos
Atores Atendente, Supervisor
Prioridade Alta
Pré-Condições Os usuários devem estar
cadastrados no sistema, tendo
usuário e senha; Os produtos e os
clientes devem ter cadastro no
sistema
Frequência de Uso Alta
Pós-Condições O sistema deve atualizar a
quantidade do produto no estoque e
atualizar o sistema financeiro
Campos Dados do cliente, todos os produtos,
código único da venda, data da
venda, valor da venda, opções para
pagamento (dinheiro e/ou cartão),
status de pagamento e status da
venda
Fluxo Principal • Atendente ou Supervisor clica em
"Realizar venda"; 2) Sistema valida o
login através de usuário e senha; 3)
Atendente ou Supervisor preenche
um dos dados do cliente (código, RG
ou CPF) e clica em "Vender"; 5)
Sistema traz o código do cliente e
exibe a tela de vendas; 4) Atendente
ou Supervisor faz a leitura do código
de barras dos produtos que serão
vendidos e seleciona o método de
pagamento; 5) Cliente realiza o
pagamento; 6) Sistema efetiva a
venda, processa o
recibo/comprovante e atualiza o
estoque e o sistema financeiro.
Fluxo Alternativo • Cliente solicita o preço do produto;
• Atendente ou Supervisor clica em
"Consultar produto"; 3) Sistema traz a
tela para scanear o código de barras;
4) Atendente ou Supervisor faz a
leitura do código de barras; 5)
Sistema traz todas as informações do
produto; 6) Atendente ou Supervisor
clica em "Voltar" ou scaneia outro
produto.
Fluxo de exceção No fluxo principal 4: 4.1) Cliente
desiste de comprar um dos produtos;
4.2) Atendente deve excluir o produto
da venda e acionar o Supervisor; 4.3)
Supervisor insere usuário e senha;
4.4) Sistema efetiva e exclusão do(s)
produto(s)
Validações Todos os campos serão obrigatórios
Tabela 5 – Efetuar Vendas – Fonte: Autor
Figura 6 – Tela de Venda – Fonte: Autor
Regras de Negócio
Os Requisitos de Negócios (ou Regras de Negócios) são premissas
e/ou restrições aplicadas a uma operação comercial de uma empresa,
que devem ser atendidas para que o negócio funcione de maneira
esperada. Um software tendo como objetivo automatizar atividades de
uma empresa, através de funcionalidades que atenderão requisitos
funcionais. Já uma regra de negócio definirá a forma que o sistema
fará este atendimento de necessidades definidas. “São regras que
servem para definir ou restringir alguma ação nos processos de sua
empresa. São declarações que irão descrever como determinadas
operações devem ser realizadas e se há algum limite que precisa ser
aplicado.” (OLIVEIRA, 2018).
Identificador Requisito
RN01 Não é possível aplicar descontos
sem cadastro prévio
RN02 A venda só será efetivada se o
pagamento for realizado
RN03 Um produto só poderá ser vendido se
estiver disponível no estoque ou se o
fornecedor trabalhar com pré-vendas
RN04 Não serão aceitas devoluções após a
data de garantia
RN05 Funcionário ao ser demitido terá o
login excluído
Tabela 2 – Regras de Negócios Fonte: Autor
Diagrama de Classes de Análise
O diagrama de classes é considerado por muitos autores o diagrama
mais utilizado da UML. Segundo Versolato (2015), em seu livro
Análise Orientada a Objetos, o diagrama de classes tem como
objetivo modelar a visão estática do sistema, mostrando um conjunto
de classes, interfaces, colaborações e os seus relacionamentos. O
propósito é de facilitar a divisão das classes do sistema, bem como
de demonstrar como as classes do sistema se interagem entre si.
Esse diagrama pode ser visto de três perspectivas:
• Conceitual: O modelo conceitual é um modelo dedicado ao
cliente, nele é abordado os conceitos do domínio em estudo.
• Especificação: Nele são observados as interfaces de arquitetura e
os métodos que serão implementados. Destina-se a quem não
precisa saber dos detalhes do desenvolvimento do software.
• Implementação: É a perspectiva mais usada, visto que aborda
mais detalhes de implementação. Destina-se a desenvolvedores.
Classe, Atributos e Métodos
A classe é representada por um retângulo com até três divisões. Na
primeira divisão, coloca-se o nome da classe. Enquanto a segunda
armazena os atributos e seus tipos de dados. Por fim, a última divisão
fica para os métodos
Diagrama de Objetos
De acordo com Booch (2000, p.193) é: “Um diagrama de objetos é
um diagrama que mostra um conjunto de objetos e seus
relacionamentos em um ponto no tempo. Graficamente, o diagrama
de objetos é uma coleção de vértices e de arcos”. Pode-se concluir
que o Diagrama de Objetos é uma instância do Diagrama de Classes
em um determinado tempo. Ele captura um conjunto de objetos e
seus relacionamentos no tempo, facilitando examinar uma interação
específica de um sistema geral. Ele obtém uma visão geral de alto
nível do sistema que será desenvolvido. Abaixo, os principais
elementos de um diagrama de objetos:
• Objetos: São instâncias de uma classe.
• Títulos de classe: São os atributos específicos de uma
classe. Pode-se lista-los como itens ou propriedades dos
objetos.
• Atributos de classe: Cada atributo permite definir um intervalo
de valores que as instâncias dessa propriedade podem
apresentar.
• Links: Trata-se das ligações ou linhas que conectam duas
formas, uma a outra, de um diagrama de objetos.
A figura a seguir 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 as multiplicidades entre
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.
Elaboração do Diagrama de Classes de Análise
Figura 7 – Diagrama de Classes de Análise Fonte: Autor
Modelo 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). Considerado
um modelo de alto-nível, tem como objetivo representar um
arranjo de dados mais perto do mundo real, como salienta Pinto
(2020, p.36), é 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.
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, departamento,
despesas, etc, ou seja, podem ser
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.
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 ser
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 (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.
• 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
tornamos 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 deum 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 particular (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
uma outra
• Relacionamentos um para um (1-1) - nesse tipo de
relacionamento cada uma das entidades se referencia
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.
• 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 a seguir 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 juntamente com
suas tabelas de relacionamento, contendo as chaves primárias das
tabelas envolvidas nessa relação.
Figura 8 – Modelo de Entidade Relacionamento (MER) Fonte: Autor
Figura 9 – Diagrama Entidade Relacionamento (DER) – Fonte: Autor
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.
