PIM VI - SISTEMA DE CONTROLE DE VENDAS PELA EMPRESA VILO

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP EaD
Projeto Integrado Multidiciplinar
Curso Superior de Tecnologia em
Análise e Desenvolvimento de Sistemas
SISTEMA DE CONTROLE DE VENDAS PELA EMPRESA VILO
Levantamento e análise de requisitos de um sistema de controle de vendas de uma
loja de jogos, acessórios e produtos geek.
UNIP POLO MARÍLIA E TUPÃ
2021
UNIP INTERATIVA
Projeto Integrado Multidiciplinar
Curso Superior de Tecnologia
SISTEMA DE CONTROLE DE VENDAS PELA EMPRESA VILO
Levantamento e análise de requisitos de um sistema de controle de vendas de uma
loja de jogos, acessórios e produtos geek.
Loredana Cardim
RA: 2090167
VICTOR HUGO FOGLIENI LEAL
RA:0557784
Curso: Análise e Desenvolvimento de Sistemas
1º semestre 2021
UNIP POLO MARÍLIA E TUPÃ
2021
LOREDANA CARDIM
RA: 2090167
VICTOR HUGO FOGLIENI LEAL
RA:0557784
SISTEMA DE CONTROLE DE VENDAS PELA EMPRESA VILO
Projeto Integrado Multidisciplinar para a
obtenção do título de graduação em Análise e
Desenvolvimento de Sistemas, apresentado à
Universidade Paulista – UNIP EaD.
Orientador: Profa. Sandra Bozolan
UNIP POLO MARÍLIA E TUPÃ
2021
RESUMO
Com o avanço da tecnologia a cada ano, houve um aumento na demanda de
produtos de software de qualidade e de baixo custo. Com isso, as empresas estão
tentando ao máximo automatizar todos os seus processos, para obter maiores
ganhos, maior produtividade e competitividade no mercado. Tendo em vista esta
necessidade, e com o auxílio das disciplinas de Análise de Sistemas Orientada a
Objetos, Banco de Dados e Gestão Estratégica de Recursos Humanos, foi
desenvolvido um software para vendas, onde é possível gerenciar o estoque e o
caixa de uma loja de jogos, acessórios e produtos geek. Para que todos os dados
fossem armazenados, foi utilizado um banco de dados relacional, definindo os níveis
de acesso para cada setor da loja, restringindo o acesso de dados sigilosos a
usuários não autorizados.
Palavras-chaves: Banco de Dados, Software.
ABSTRACT
As technology advances every year, there has been an increase in demand for
quality, low-cost software products. With this, companies are trying their best to
automate all their processes, to obtain greater gains, greater productivity and
competitiveness in the market. In view of this need, and with the help of
Object-Oriented Systems Analysis, Database and Strategic Human Resources
Management, a software for sales was developed, where it is possible to manage
the stock and cash of a store. games, accessories and geek products. For all data to
be stored, a relational database was used, defining access levels for each sector of
the store, restricting access to sensitive data to unauthorized users.
Keywords: Database, Software.
SUMÁRIO
1 INTRODUÇÃO 8
2 CASOS DE USO 9
2.1 Requisitos 9
2.1.1 Casos de Uso 9
2.2 - Modelagem de Casos de Uso 10
2.2.1 Cadastro cliente 10
2.2.1.1 Fluxo de Trabalho 10
2.2.1.2 Requisitos Relacionados 11
2.2.2 Cadastro de produto 13
2.2.2.1 Fluxo de Trabalho 13
2.2.2.2 Requisitos Relacionados 13
2.2.3 Efetuar vendas 14
2.2.3.1 Fluxo de Trabalho 15
2.2.3.2 Requisitos Relacionados 15
2.3 - Regras de Uso 16
2.3.1 Login 16
2.4 Contexto de Uso 18
2.4.1 Usuários e tarefas 18
2.4.2 Ambiente 18
3- REQUISITOS 19
3.1 Requisitos Funcionais 19
3.2 Requisitos Não Funcionais 20
3.3 Requisitos Não Funcionais de Usabilidade 22
4- DIAGRAMA DE CLASSES DE ANÁLISE 24
4.1 Diagrama de Classes 24
4.2 Diagrama de Objetos 24
4.3 Classes de Análises 24
4.3.1 Elaboração do diagrama de classes de análise 25
4.4 Modelo de Entidade-Relacionamento (MER) 25
4.4.1 Entidades, atributos e relacionamentos 26
5 CONCLUSÃO 29
REFERÊNCIAS 30
1 INTRODUÇÃO
Com a evolução da tecnologia, empresas especializadas em software estão
sendo contratadas para realizar soluções tecnológicas para automatizar os
sistemas, para que haja maior produtividade, segurança, e outros fatores que
colaboram com a melhoria das empresas.
Sendo assim, uma empresa no ramo de vendas de jogos, acessórios e
produtos geek decidiu procurar a empresa ViLo para automatizar o sistema que
controla o seu estoque e vendas. Foi feito o levantamento de dados que seriam
pedidos ao cliente, a identificação dos casos de uso, que seriam cadastro de
clientes e cadastro de produtos, ambos com possibilidade de alterações, exclusão e
consulta, também pode ser visto quais os produtos separados em categorias.
Para efetuar a venda, será necessário que o funcionário entre com seu login
e senha, para ter acesso ao que é permitido no seu cargo na empresa, após
coloca-se os dados do cliente e do produto a ser vendido. Ele também poderá fazer
alterações na compra, visualizar o preço e cancelar a compra. Os estoquistas
poderão cadastrar os produtos no sistema e seus respectivos valores. O supervisor
conseguirá ter acesso a todas as funções do sistema, inclusive à contabilidade da
empresa. O sistema terá um banco de dados elaborado e planejado para suprir
todas as permissões e necessidades do sistema, trazendo segurança e informações
para os funcionários.
2 CASOS DE USO
2.1 Requisitos
Os requisitos desejados pela empresa contratante eram, de modo geral, um
sistema que controlasse o estoque e as vendas. O acesso a esse sistema teria que
ser através de login e senha, com 3 níveis de acesso (estoquista, atendente e
supervisor).
O estoquista terá acesso ao cadastro dos produtos, onde será possível
salvar, alterar, excluir e consultar os dados dos produtos.
O atendente acessa o cadastro dos clientes, podendo também salvar, alterar,
excluir e consultar os dados dos clientes. Ele realizará as vendas da loja, com isso,
tem acesso aos dados da venda, como código de barras, data, valores, formas de
pagamento e status de pagamento e venda. Resumidamente, encontrará os dados
do cliente e os dos produtos.
O supervisor terá acesso a todo 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.
Após analisado todos os requisitos, chegou-se aos seguintes casos de uso:
2.1.1 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 produto;
RF 11- Cancelar venda;
RF 12- Buscar cliente;
RF 13- Consultar preço;
RF 14- Efetuar login com nível de acesso.
2.2 - Modelagem de 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;
● 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;
2.1. Caso o nível de acesso seja incompatível, uma mensagem é exibida.
2.2. 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.
6.1. Caso existam campos em branco, uma mensagem é exibida.
6.2. Extensão para alterar dados do cliente.
6.3. Extensão para excluir um cliente.
6.4. 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.
Figura 1 - Tela Login
Fonte: Autoria Própria
Figura 2 - Tela Cadastro Cliente
Fonte: Autoria Própria2.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;
● 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 produtos.
2. Inclusão para validar nível de acesso.
2.1. Caso o nível de acesso seja incompatível, uma mensagem é exibida.
2.2. 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 produtos 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.
6.1. Caso existam campos em branco, uma mensagem é exibida.
6.2. Extensão para alterar dados do produto.
6.3. Extensão para excluir um produto.
6.4. Extensão para consultar um produto.
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.
Figura 3 - Tela Cadastro Produto
Fonte: Autoria Própria
2.2.3 Efetuar vendas
● Identificação: Efetuar venda;
● Escopo: Sistema de vendas e cadastros com controle de estoque;
● 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;
2.1. Caso nível de acesso seja incompatível, uma mensagem é exibida;
2.2. 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;
5.1. Caso produto não esteja cadastrado, uma mensagem é exibida;
5.2. Caso produto não esteja cadastrado, digitar código manualmente;
5.3. Extensão para buscar dados do cliente;
5.4. Extensão para excluir produto da venda;
5.5. Extensão para cancelar a venda;
5.6. 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;
● RF 12 - Buscar cliente;
● RF 13 - Consultar preço;
● RF 14 - Efetuar login com nível de acesso.
Figura 4 - Tela Venda
Fonte: Autoria Própria
2.3 - Regras de Uso
Foram determinadas as seguintes regras de uso para o sistema:
2.3.1 Login
● Só usuários pré-cadastrados poderão ter acesso ao sistema;
● Somente funcionários terão acesso direto ao sistema;
● Somente usuários com função de Superior poderão cadastrar e excluir
usuários.
Figura 5 - Tela do Supervisor
Fonte: Autoria Própria
2.3.2 Cadastro de usuário
● Deve ser feito o cadastro do clientes para efetuar a compra;
● Somente usuários com função de Atendente/Supervisor poderão cadastrar
clientes.
2.3.3 Cadastro de produto
● Somente usuários com função de Estoquista/Supervisor poderão cadastrar
os produtos;
● Todos os produtos devem ser cadastrados para possibilitar a venda e o
controle de movimento;
● Todos os dados devem ser preenchidos para efetuar o cadastro do produto.
2.3.4 Cancelamento de vendas
● Somente os 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 permitidos a usarem o sistema são separadas por níveis,
classificando e estabelecendo para cada um, uma interação diferente do sistema.
Como cada usuário necessita de funções diferentes, foi desenvolvido cada ambiente
contando com praticidade e desempenho durante o uso do mesmo.
Para os atendentes, o acesso precisa ser fácil e bem detalhado sobre os
produtos, para que ele possa passar para o cliente e no final gerar a compra.
Os estoquistas precisam fazer a verificação, validação e cadastro de todos os
produtos do estoque, de uma forma simples, clara e ágil.
Os supervisores têm acesso a todo sistema, isso garante uma maior
segurança e um melhor gerenciamento.
2.4.2 Ambiente
Dentro do ambiente, há um sistema de banco de dados, que fica em um
servidor separado dos computadores de atendimento, pois utiliza um maior
processamento e tem acesso ao disco rígido.
Ele é instalado em uma sala com acesso restrito e ar condicionado. Todos os
servidores estão diretamente conectados a esse sistema base, onde fica agrupado
e alocado todos os dados do sistema.
Os softwares de cadastro são instalados em computadores desktops, que
servem de base para a comunicação e registro do banco de dados.
Alguns sistemas, tem acesso aberto a usuários com registro no mesmo, é
possível acessar de diferentes máquinas, sem que interfiram nas configurações já
estabelecidas para cada usuário.
3- REQUISITOS
Os requisitos são serviços que um sistema deve prestar e suas restrições de
funcionamento. Devem refletir as necessidades do cliente e são classificadas 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 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, esses requisitos são organizados também
em: requisitos funcionais e requisitos não funcionais.
3.1 Requisitos Funcionais
Esses requisitos descrevem o comportamento que se espera de um sistema
de software, mostra de forma clara, o que o sistema deve fazer e o que não deveria
fazer.
3.2 Requisitos Não Funcionais
Eles descrevem as restrições sobre os serviços oferecidos pelo sistema. Os
requisitos funcionais acabam sendo insuficientes para descrever o sistema, pois há
necessidade de descrever outros aspectos, sendo eles: atributos do sistema e
atributos do ambiente do sistema, receberam o nome de requisitos não funcionais.
Os requisitos não funcionais recebem algumas classificações, como na figura
abaixo.
Figura 6 - Diagrama de requisitos não funcionais
Fonte: Versolatto, 2015
Além dessas classificações, a norma ISO/IEC 25010:2011 também trata da
classificação e da definição de requisitos não funcionais. Ela 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 abaixo mostra a estrutura
hierárquica dos atributos de qualidade, quanto a sua classificação, proposta pela
norma ISO 25010.
Figura 7 - Diagrama de atributos de qualidade
Fonte: Versolatto, 2015
3.3 Requisitos Não Funcionais de Usabilidade
O sistema possui fácil utilização sem muitos recursos gráficos, com adição de
descrições das funções (hints) aos botões e configurações de teclade atalho para
as funções utilizadas.
Segundo a 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).
● 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 estilo 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 de 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: Específica 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
É um diagrama UML, que tem como objetivo apresentar a estrutura estática
das classes de um sistemas de software.
4.2 Diagrama de Objetos
É um diagrama que tem como objetivo representar as instâncias de classes,
ou seja, objetos e suas respectivas ligações ou associações. Assim, pode-se dizer
que a base do diagrama de objetos é o diagrama de classes.
Através desse diagrama, tem-se a 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
existem aspectos 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 de 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.
4.3.1 Elaboração do diagrama de classes de análise
O diagrama de classes de análise do projeto dos sistemas de software é
elaborado com base na identificação dos substantivos do texto e dos casos de uso,
do relacionamento entre eles com seus respectivos nomes e a multiplicidade 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.
4.4 Modelo de Entidade-Relacionamento (MER)
É um modelo conceitual que descreve os objetos (entidades) envolvidos em
um domínio de negócios, com suas características (atributos) e como se relacionam
entre si (relacionamentos). Este modelo representa de forma abstrata a estrutura
que o banco de dados terá da aplicação.
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. Elas representam
categorias de fatos do mundo real, sejam eles concretos ou abstratos, como
empregados, departamentos, despesas, ou seja, podem ser classificadas em
entidade física e entidade lógica.
As entidades Físicas são existentes e visíveis no mundo real, por exemplo,
um atendente de um cliente ou até mesmo um produto. 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.
Sendo assim, pode-se classificar as entidades como: fortes, fracas e
associativas.
● 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 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 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 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.
● 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 8, ilustra a representação gráfica do Modelo Entidade-Relacionamento
(MER) e a figura 9, 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:Autoria Própria.
Figura 9 - Diagrama Entidade-Relacionamento (DER)
Fonte: Autoria Própria.
5 CONCLUSÃO
No presente PIM VI (Projeto Integrado Multidisciplinar), foi-se realizado, com
o auxílio das disciplinas de Análise de Sistemas Orientada a Objetos, Banco de
Dados e Gestão Estratégica de Recursos Humanos, um sistema para uma loja de
vendas de jogos, acessórios e produtos geek. Seu objetivo era poder realizar
cadastro de novos usuários e clientes, salvando seus dados em um banco de dados
relacional, para recuperações posteriores.
Junto ao contratante, foi realizado um levantamento e análise de requisitos,
para saber quais seriam as necessidades do projeto. Assim, foi sabido que era
necessário três níveis diferentes de acesso para cada usuário, restringindo acesso
não autorizado de dados sigilosos.
Utilizando o Modelo de Entidade- Relacional (MER) e o Diagrama
Entidade-Relacional (DER) foi possível definir a estrutura do banco de dados. Feito
também o diagrama de classes de análise, que permite modelar de forma mais
precisa o software do cliente e os dados a serem armazenados.
Por fim, este trabalho acrescentou muito profissionalmente e no âmbito
acadêmico, trazendo maior compreensão sobre os assuntos aprendidos em cada
disciplina e sua aplicabilidade em uma simulação
REFERÊNCIAS
DEVMEDIA. Modelo Entidade Relacionamento (MER) e Diagrama
Entidade-Relacionamento (DER). Disponível em:
https://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-enti
dade-relacionamento-der/14332. Acesso em: 06 jun. 2021.
VENTURA, Plínio. Entendendo o Diagrama de Classes da UML. Disponível em:
https://www.ateomomento.com.br/uml-diagrama-de-classes/. Acesso em: 06 jun.
2021.