PIM_VI

Prévia do material em texto

UNIVERSIDADE PAULISTA - UNIP EAD
PROJETO INTEGRADO MULTIDISCIPLINAR
CURSO SUPERIOR DE TECNOLOGIA
ALESSANDRA LUCIANA BRUGNEROTO LUZ - RA:2067276
HIRAN FERRETI BACCOS - RA: 2059598
MICHAEL PATRICK DA ROSA - RA: 2069517
RAPHAEL DOUGLAS SANTOS IZUINO - RA: 2068630
TACILA NUNES DA CONCEIÇÃO - RA: 2059593
THAIS CORREIA RIBEIRO CARDOSO - RA: 2069541
PROJETO INTEGRADO MULTIDISCIPLINAR VI
SISTEMA DE CONTROLE DE ESTOQUE E VENDAS
SÃO PAULO
2021
ALESSANDRA LUCIANA BRUGNEROTO LUZ - RA:2067276
HIRAN FERRETI BACCOS - RA: 2059598
MICHAEL PATRICK DA ROSA - RA: 2069517
RAPHAEL DOUGLAS SANTOS IZUINO - RA: 2068630
TACILA NUNES DA CONCEIÇÃO - RA: 2059593
THAIS CORREIA RIBEIRO CARDOSO - RA: 2069541
PROJETO INTEGRADO MULTIDISCIPLINAR VI
SISTEMA DE CONTROLE DE ESTOQUE E VENDAS
Projeto Integrado Multidisciplinar para a obten-
ção do título em Análise e Desenvolvimento de
Sistemas, apresentado à Universidade Paulista -
UNIP EaD.
Orientador: Sandra Bozolan
SÃO PAULO
2021
RESUMO
No Projeto Integrado Multidisciplinar VI foi designado a elaboração de um sistema de gestão para
a empresa W-3, ela é uma intuição do ramo de comércio de jogos de eletrônicos e produtos geeks,
com isso ela está buscando obter um melhor controle sobre suas vendas e seu estoque. Assim, a
proposta elaborada aplicou as disciplinas do 3º período do Curso de Graduação Tecnológica em
Análise e Desenvolvimento de Sistemas da Universidade Paulista – UNIP. Essas disciplinas são:
Análise de Sistemas Orientada a Objetos, Gestão Estratégica de Recursos Humanos e Banco
de Dados. Portanto, utilizou desses conteúdos para desenvolver o protótipo de software, que
gerencie o negócio da W-3, além disso empregou a metodologia de pesquisa bibliográfica, para
deste modo ter um suporte e assim auxiliar na solução do problema.
Palavras-chave: Análise de Sistemas Orientada a Objeto; Gestão Estratégica de Recursos
Humanos; Banco de Dados.
ABSTRACT
In the Integrated Multidisciplinary Project Six, the design of a management system for the com-
pany W-3 was designed, it is an intuition of the branch of commerce of electronic games and geek
products, with which it is seeking to obtain better control over its sales and your stock. Thus, the
elaborated proposal applied the disciplines of the 3rd period of the Technological Undergraduate
Course in Analysis and Systems Development at University Paulista - UNIP. These disciplines
are: Object Oriented Systems Analysis, Strategic Human Resource Management and Database.
Therefore, it used these contents to develop the software prototype, which manages the business
of W-3, in addition it used the methodology of bibliographic research, in order to have a support
and thus assist in the solution of the problem.
Keywords: Object Systems Analysis; Strategic Resource Management; Database.
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 SISTEMA DE CONTROLE DE ESTOQUE E VENDAS . . . . . . . . . 6
2.1 UML - LINGUAGEM DE MODELAGEM UNIFICADA . . . . . . . . . . 6
2.2 DIAGRAMA DE CASOS DE USO . . . . . . . . . . . . . . . . . . . . . . 6
2.3 ESPECIFICAÇÕES DOS CASOS DE USO . . . . . . . . . . . . . . . . . 7
2.4 LAYOUT DO SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 PROGRAMAÇÃO ORIENTADO A OBJETO - POO . . . . . . . . . . . . 12
2.6 DIAGRAMA DE CLASSE . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 BANCO DE DADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7.1 Sistema de gerenciamento de banco de dados (SGBD) . . . . . . . . . . 14
2.7.2 Principais Elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7.3 Modelo Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7.4 Modelo Lógico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7.5 Modelo Físico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.7.6 Projeto e Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5
1 INTRODUÇÃO
A Ágil Technology é uma empresa de tecnologia que foi fundada no Brasil, sua matriz
está localizada no estado de São Paulo. Esta contém filiais em alguns países, como: Nova York,
México e possui 10 anos de mercado. Esta empresa investe na inclusão, pensando no ecossistema
diferenciado. Atende todos os tipos de comércios e varejistas, conta com um time inovador e
com uma estrutura ágil. A proposta desse projeto é desenvolver um sistema para a empresa W-3
(seu seguimento são acessórios, jogos e produtos Geek). O objetivo é desenvolver um sistema
que atenda desde a entrada do produto até a venda.
O software contará com o controle de estoque, irá realizar o gerenciamento completo e
análise de informações, desde o cadastro do cliente até as consultas e alterações de produtos
mantendo a segurança dos seus dados. O projeto também contempla inovação e agilidade para
o negocio, entregando para seu cliente um produto de valor, e entrega contínua, assim ele terá
um serviço intuitivo e de fácil acesso, trazendo organização e agilidade na hora de efetuar suas
vendas.
6
2 SISTEMA DE CONTROLE DE ESTOQUE E VENDAS
2.1 UML - LINGUAGEM DE MODELAGEM UNIFICADA
A UML será bastante utilizada neste PIM. Pois com suas ferramentas se pode fazer
a estruturação de um software, assim ela concede aos programadores a visualização de seus
projetos através de diagramas, que são: diagrama de classe, casos de uso, atividade, sequência,
etc. (WIKIPEDIA, 2017).
2.2 DIAGRAMA DE CASOS DE USO
Diagrama de Caso de Uso é um método utilizado para exemplificar o que o sistema pro-
posto deve desempenhar. Assim, por meio de uma coleta de informações obtidas através de uma
conversa entre o usuário e os profissionais responsáveis, esses identificam e especificam quais
funcionalidades o software irá conter. O diagrama tem como finalidade: escolher e explicar "os
requitos funcionais do sistema; "proporcionar uma definição nítida do que o programa realizará;
encontrar "requisitos funcionais das classes e operações do sistema"; registrar e compreender as
particularidades do software; determinar "o contexto de um sistema"(MACORATTI, 2004).
Os elementos desta modelagem são: Ator: descreve uma função dempenhada pelo
cliente ou por "outro sistema que interage". Ele tem de "ser externo ao sistema". Deverá efetuar
vinculações específicas "para casos de uso, componentes ou classes a exceção que um ator possa
herdar o papel de outro". Assim, ele será retrato no diagrama como um bonequinho; Caso de
Uso: é caracterizado por um grupo de processos realizados pelo programa. Ele será retratado
numa forma de elipse (WIKIPÉDIA, 2015).
Um dos modos de comunicação entre os Casos de Uso é o «Include», que insere uma
ligação "entre os casos de uso". Assim, se a função que recebeu o include for executada, sua
inclusão também será aplicada obrigatoriamente. Outro modelo de comunicação é o «Extends»,
nele a função extendida deve ser executada ou não (WIKIPÉDIA, 2015).
Na figura 1 está a criação do Diagrama de Casos de Uso elaborado especificamente
para empresa W-3, nele foi feito um levantamento de requisitos e a partir destes resultou neste
diagrama. O sistema proposto contém 3 atores que são: estoquista, atendente e supervisor. Os
casos de uso são: Estoquista contará com a função de cadastrar produtos; Atendente poderá
consultar produto, cadastrar cliente, buscar cliente e efetuar venda; Supervisor poderá excluir
produto, cancelar venda, acessar vendas e acessar produtos. No fluxograma terá alguns include
e extends, então ao efetuar a venda o atendente necessariamente tem de adicionar produto,
calcular preço e finalizar a venda, que são funções include. No entanto, quando ele estiver
efetuando a venda e o cliente não desejar obter desterminado produto ja adicionado no seu
pedido, somente o supervisor poderá excluir o produto ou cancelar a venda. Excluir produtoe
cancelar venda são funções extends, ou seja, nem sempre essas funções serão implementadas. Se
optar por cancelar a venda obrigatoriamente deverá enviar o código do produto para o sistema
7
financeiro, já que ele é um include.
Figura 1 – Sistema de Gestão da W-3 - Diagrama de Casos de Uso
Fonte: Próprio Autor, 2021
2.3 ESPECIFICAÇÕES DOS CASOS DE USO
Regra de negócio é o que define a forma de fazer o negócio, refletindo a política interna, o
processo definido e/ou as regras básicas de conduta. Ou seja, é um conjunto de instruções que os
usuários já seguem e que o sistema a ser desenvolvido deve contemplar. Restrições, validações,
condições e exceções do processo são exemplos clássicos de regras de negócio. Uma regra de
negócio não necessariamente será refletida no sistema como uma funcionalidade, mas ela com
certeza determinará o comportamento de uma ou mais funcionalidades do sistema (DEXTRA,
2013).
Abaixo, serão descritas as especificações de cada caso de uso do sistema de gestão da
W-3. Serão descritas suas funções, pré-condições, fluxos e regras de negócio especificas.
1. Fazer Login
Neste caso, os três atores terão que fazer uma autenticação no sistema, informando o
usuário e a senha. Assim, após esse processo eles serão redirecionados para suas respectivas
interfaces.
8
2. Cadastrar Produto
Neste caso, o estoquista irá registrar algum produto que não esteja cadastrado ainda. Só
será possível realizar essa operação, caso haja o produto na loja. Caso o estoquista se
engane, e o produto já esteja disponível para acesso, ocorrerá um erro e o estoquista será
comunicado que o produto já está cadastrado. Sendo assim, ele sempre deverá inserir novos
produtos que cheguem na loja, juntamente com a quantidade disponível e o código de
acesso. O caminho de sucesso é quando o produto chega, e o estoquista registra juntamente
com sua quantidade, sem que haja problemas no sistema. Neste caso não há caminhos
alternativos.
3. Adicionar Produto
Quando o atendente efetua uma compra, ela passa pelo processo de calcular o preço para
que o cliente saiba o quanto irá pagar. Em paralelo com este fluxo, ocorre a possibilidade
do atendente adicionar um novo produto ao carrinho do cliente. O atendente não pode
excluir, mas pode adicionar quantos produtos quiser após a efetuação da venda. Este é o
fim de um dos caminhos do processo da venda. O atendente apenas poderá adicionar um
produto se o cadastro do cliente já tiver sido efetuado com seus dados pessoais, caso isto
não aconteça, não será possível efetuar a venda, ou seja, novos produtos não poderão ser
adicionados.
4. Consultar Produto
Para que um produto seja consultado, o atendente da loja deve realizar seu cadastro pessoal
e inserir o código do produto. Caso o código do produto seja digitado de forma equivocada,
aparecerá o produto digitado, ou até mesmo aparecerá uma mensagem dizendo que não
existe produto com aquele código. Sendo assim, o ideal é que o código seja digitado
corretamente, que o produto apareça, sua quantidade, variações, como por exemplo, cor e
tamanho, e por fim apareça produtos similares, caso o cliente opte por não levar aquele
produto, tendo assim outras opções. Não há um fluxo alternativo nesse caminho. Caso um
funcionário tente entrar em algum caminho que não tenha acesso no sistema devido a sua
função, o sistema irá barrar o acesso e informar ao funcionário que não é possível acessar
aquele caminho. É importante que os funcionários saibam quais acessos são liberados no
seu sistema, de acordo com o diagrama de caso de uso.
5. Acessar Produto
Todos os funcionários (estoquistas, atendentes e supervisores) devem ser registrados no
sistema, e o acesso será liberado para cada um de acordo com seu cargo na empresa. O
supervisor é a pessoa responsável por acessar os produtos, e para isso, deve realizar seu
cadastro com login e senha. Para que obtenha sucesso em sua busca, após acessar o sistema,
o supervisor deve identificar qual produto deseja acessar através do código, e dessa forma
9
poderá conferir o status do produto, como disponibilidade e descrição. Para esse caminho,
também não existem fluxos alternativos.
6. Excluir Produto
Caso um cliente desista da compra, ou caso o produto saia de linha, o supervisor é o único
que tem acesso a exclusão de produtos. Sendo assim, após realizar seu acesso ao sistema,
o supervisor deve selecionar o pedido, e cancelar a compra, ou apenas retirar do carrinho
de compras virtual os itens que o cliente não deseja comprar. Após esta etapa, o sistema
entrará no fluxo de cálculo de preço, onde será abatido o valor dos produtos excluídos do
carrinho dos compradores, e por fim, haverá a finalização da venda. No caso de exclusão
de produto fora se linha, o supervisor deverá inserir o código do produto, e retirá-lo
permanentemente do sistema, para que não apareça mais no sistema. Vale ressaltar que
neste caso, o produto irá será removido, e não apenas identificado como fora de estoque.
Concluindo esse processo, o atendente poderá efetuar a venda. O cliente só poderá optar
por excluir o produto, caso a venda ainda não tenha sido finalizada. Caso contrário, o
cliente terá que cancelar toda a compra.
7. Cadastrar Cliente
O responsável por este caminho, é o atendente. Caso um cliente deseje comprar ou acessar
um produto, deverá ter acesso ao sistema, e para isso, necessitará ser cadastrado com
seus dados pessoais, login e senha. O cliente deverá informar nome, data de nascimento,
telefone para contato, endereço de e-mail, endereço residencial e número do cartão de
compras. O sistema irá passar por um processo de confirmação de dados, onde o cliente
poderá confirmar seu e-mail e número para contato. O nome e nascimento do cliente serão
verificados com a entrega de um documento original com foto. O número do cartão a ser
utilizado para efetuar compras, passará por uma breve liberação da operadora. Endereço
de e-mail e CPF não são itens obrigatórios para cadastramento, porém se o cliente desejar
que o produto seja entregue, deverá informar o endereço desejado. O atendente também
deverá tirar uma foto do cliente, que ficará registrada no sistema. Estando tudo ok, o
cadastro será efetuado. Após este passo ser concluído, o cliente ficará registrado para
futuras compras. Para que este processo ocorra sem problemas, o cliente deverá ter em
mãos seus documentos, e um endereço de e-mail válido para que o atendente realize o
cadastro sem problemas. Não há outra alternativa para este caminho.
8. Buscar Cliente
Os clientes que são registrados no sistema através do cadastro, podem ser consultados pelo
sistema. O atendente é o único a ter acesso a esses dados, e deverá utilizar este meio apenas
para fins de venda, ou seja, caso o cliente solicite checar seus status, ou status de suas
compras e pedidos, ou caso o atendente necessite desse dado para realizar alguma cobrança
relacionada a compra de produtos. Em hipótese alguma o atendente poderá checar os
10
dados de um cliente sem que haja necessidade, isso faz parte das regras da empresa. O
acesso dos funcionários é monitorado através de softwares, garantindo assim, que nenhum
funcionário realize operações que não são voltadas aos objetivos e regras da empresa. Não
há fluxos alternativos para esse processo.
9. Efetuar Venda
Quando um cliente deseja realizar uma compra, o atendente deve auxiliá-lo para realizar
o pedido no sistema. O atendente seleciona os produtos desejados e sua quantidade,
juntamente com o cliente. Caso o cliente desista de levar algum item, a presença do
supervisor deverá ser solicitada, pois é o único que poderá realizar a exclusão do produto.
Quando todos os itens que o cliente realmente deseja levar estiverem no carrinho de
compras, o sistema passará para o próximo passo, que é o cálculo de preço. Sendo assim,
o sistema irá mostrar ao cliente o valor final de sua compra, dando início ao último passo,
que é a finalização da venda. O sistema já terá os dados do cliente registrados através do
seu cadastro, inclusive o número docartão de compras. O cliente que optar por realizar o
pagamento via cartão, deverá digitar a senha, e neste momento, o atendente estará junto
para ajudá-lo, porém não irá olhar para que o cliente tenha privacidade e esteja seguro. Há
a opção do cliente pagar via boleto, ou dinheiro, e neste caso, o atendente irá gerar uma
receita para que o cliente pague o boleto, ou se dirija ao caixa da loja para poder efetuar
o pagamento. Após a aprovação do pagamento, o cliente poderá retirar seus produtos no
caixa, ou escolher um endereço para que os produtos sejam entregues.
10. Acessar Vendas
Caso haja necessidade de buscar o histórico de vendas, o supervisor poderá acessar o
sistema com seus dados. O acesso poderá mostrar todo o histórico de vendas da loja, e o
supervisor deve selecionar o período que deseja buscar, ou colocar o código das vendas que
deseja consultar. O histórico deve ser verificado para monitoramento de entrada e saída dos
produtos, resolução de possíveis problemas, como cancelamentos de compra, e até mesmo
para controle financeiro da loja. Sendo assim, o supervisor não poderá acessar as vendas
caso não haja necessidade, e será monitorado pelo software responsável por registrar a
navegação dos funcionários. O acesso a produtos não leva a caminhos alternativos.
11. Cancelar Venda
Caso o cliente tenha necessidade de cancelar toda a compra, e não apenas produtos
específicos, o supervisor deverá cancelar a venda. Neste caso, todos os produtos do
carrinho do cliente serão excluídos. Também a possibilidade do cliente já ter finalizado o
pedido, porém houve desistência. Neste caso a compra poderá ser cancelada, sendo que
a mesma regra se aplica, todos os produtos serão retirados. Após ocorrer um dos dois
processos citados acima, o sistema irá calcular o preço e retirar do histórico do carrinho,
ou do histórico de vendas, finalizando a venda. Paralelo a finalização da venda, o sistema
11
irá enviar o código dos produtos para aparecerem como disponíveis novamente, uma vez
que a venda foi cancelada.
12. Finalizar Venda
As vendas serão finalizadas quando o atendente efetuar uma venda, o preço for calculado
e ela for concluída com sucesso. Também há possiblidade da venda ser cancelada pelo
supervisor, caso seja desejo do cliente. Sendo assim a venda também passará pelo processo
de cálculo de preço e será finalizada, dando fim ao fluxo da venda. Vale lembrar que o
cliente terá os dados de seu cartão de compras registrado no sistema, e também tem a opção
de pagar com dinheiro ou boleto bancário, fornecendo assim, diversas formas seguras de
concretizar o pagamento. Ambos atendente e supervisor, podem ter acesso à finalização de
vendas. O supervisor também pode ter acesso à finalização de vendas.
13. Enviar Código
Os códigos dos produtos serão enviados para concluir o processo de cancelamento da venda.
Quando uma venda for cancelada, o código dos produtos presentes serão encaminhados,
para que o sistema entenda que eles estão novamente disponíveis, dando fim ao fluxo do
cancelamento. Apenas o supervisor pode cancelar vendas, fazendo com que seja o único
que pode acessar o envio dos códigos.
2.4 LAYOUT DO SISTEMA
Figura 2 – Layouts
Fonte: Próprio Autor, 2021
12
2.5 PROGRAMAÇÃO ORIENTADO A OBJETO - POO
Programação Orientada a Objetos - (POO), é um paradigma onde se faz uma abstração
de objetos do mundo em que vivemos e traz esses aspectos para o código, assim se transforma
num objeto do sistema (CARVALHO; TEXEIRA, 2012).
Para a caracterização de um objeto e suas funções que estão dentro das classes, se faz
uso de termos como: atributos = carateríticas do objeto esses possuem tipos, como: int, string,
double, etc; e métodos = funções que devem desempenhar. Também para o acesso das classes
existem tipos de acesso, que são: public - publico, mas para a proteção da estrutura e de seus
dados se faz uso de encapsulamento, utilizando private para que somente a classe tenha acesso
aos metódos e atributos ou protected, assim apenas as classes herdadas e "classes do mesmo
pacote têm acesso"a eles (CARVALHO; TEXEIRA, 2012).
Esse paradigma conta com 4 pilares, alguns já citados acima, como: encapsulamento,
abstração de objeto, herança e polimorfismo. Portanto, a sobrescrita do método é um polimor-
fismo, para que assim a "classe filha"seja capaz de decidir seu procedimento, tomando como
base a "estrutura da classe mãe"(CARVALHO; TEXEIRA, 2012).
2.6 DIAGRAMA DE CLASSE
Diagrama de classe é usado para modelar a estrutura de um sistema, geralmente se usa
nessa modelação conceitos da POO. As caraterísticas da POO são: "classes, atributos, operações
e as relações entre os objetos". Normalmente este diagrama utiliza a UML - (Liguagem de
Modelagem Unificada) para seu desenvolvimento (SIGNIFICADOS, 2018).
No retângulo onde descreve o objeto, primeiro vem o nome do objeto, depois os atri-
butos ou caracteríticas que deve conter, porteriormente os métodos que a classe deve chamar.
Existem interfaces e essas só contem métodos que poderão ser implementados em outras classes
(SIGNIFICADOS, 2018; CARVALHO; TEXEIRA, 2012).
Agora quando se fala em relacionamentos entre as classes, o diagrama detém de 6 tipos,
destes 6 tipos foram usados 3 no projetos. E estes são: implementação é utilizado quando há
interface, assim os métodos da interface serão aplicados em outras classes; agregação é uma
espécie de "associação", onde se tem um objeto que faz parte de outro objeto; generalização ou
herança é onde existe uma classe pai e as classes filhas herdam atributos e métodos da classe
pai (SOUZA, 2021).
Assim para a elaboração do diagrama de classe do sistema da W-3 se utilizou de conceitos
do paradigma da programação orientada a objeto e concepções da UML.
Depois de ter visto estas noções foi desenvolvido o diagrama, este está descrito na figura
3.
13
Figura 3 – Diagrama de Classe W-3
Fonte: Próprio Autor, 2021
Ele conta alguns atributos e métodos private, para que somente a classe possa acessar, nas
demais classes o acesso é protected para que apenas classes do mesmo pacote possam acessar
14
suas variáveis e funções, utilizando assim encapsulamento, que é um dos pilares da POO citada
anteriormente.
Em seguida se criou agregações para as classes Estoquista, Supervior e Atendente.
Portanto, a classe Produto faz parte das classes: Estoquista, Supervisor e Atendente, a classe
Pagamento faz parte da classe Atendente, já a classe Venda faz parte da classe Supervisor e
Atendente, e a classe Cliente faz parte da classe Atendente.
Após a fase de agregação veio a criação de generalização necessária das classes pais, que
são: Produto e Pagamento. Assim as classes filhas Jogos, Acessorios e Geeks herdam atributos e
metódos da classe pai Produto, do mesmo jeito que Cartao, herda da classe Pagamento. Mais
neste último caso há polimorfismo utilizando a sobrescrita do método, tanto na classe pagamento,
como na classe Cartao.
2.7 BANCO DE DADOS
Quando falamos de banco de dados, temos que ter em mente que a todo momento e
em quase todos os lugares, principalmente nos dias atuais, estamos acessando um, direta ou
indiretamente, e isso pode ser feito de várias maneiras. Um grande exemplo que podemos citar
no uso cotidiano das pessoas são as redes sociais, como WhatsApp, Facebook e Instagram, onde
há um volume gigantesco de dados e informações armazenadas na nuvem, como é comum de se
ouvir, ou em um servidor.
Um banco de dados é uma coleção de dados relacionados. Com dados, queremos dizer
fatos conhecidos que podem ser registrados e possuem significado implícito. De forma direta e
simples, podemos dizer que um banco de dados é uma coleção de dados. Já um dado, por sua
vez, é um fato que deve ser armazenado, ou seja, persistido e que tem um significado implícito
(DEVMEDIA, 2006).
Os bancos de dados possuem algumas categorias diferentes, assim como níveis, modelos
e outros. Grande parte do conteúdo obtido na disciplina de Banco de Dados do curso de Análise
e Desenvolvimento de Sistemas será abordado aqui, especificandocoerentemente alguns de seus
principais conceitos.
2.7.1 Sistema de gerenciamento de banco de dados (SGBD)
Com o objetivo de controlar os dados, faz-se necessário a utilização de um SGBD (sistema
de gerenciamento de banco de dados), que é um sistema que utiliza mecanismos de manipulação
das "informações do banco de dados"e se comunica "com o usuário". Exemplos de SGBDs são:
Oracle, SQLserver, Mysql, PostgreSql, Firebase e MongoDB (DEVMEDIA, 2006).
O SGBD utilizado no projeto é o SQLserver, por ser uma plataforma de desenvolvimento
que permite ao desenvolvedor maior rapidez e agilidade com a flexibilização dos dados e introduz
as suas inovações no mercado mais rápido.
15
Assim, deve-se optar por um SGBD quando: informações forem armazenadas de modo
permanente; controle central dos dados; desejar-se controle de redundância; controle da con-
sistência e integridade dos dados; houver múltiplos usuários; controlar o acesso e a segurança;
houver o compartilhamento dos dados entre os usuários; existir a independência dos dados e das
aplicações; houver Backup e recovery.
2.7.2 Principais Elementos
Entidade: são objetos do mundo real que tranforma em base de dados. Ex: em uma
Universidade existe entidade, como: alunos, professores, cursos, etc (MEIRA, 2013).
Relacionamentos: são as interações entre as entidades. Ex: quais alunos estão matricula-
dos em determinados cursos. Chave primária e estrangeira: chave primária é um "identificador
unico", já a estrangeira faz referencia a outra entidade. Cardinalidade 1 pra 1, 1 pra N e N pra
N e esses significam: 1:1 é quando 1 acontecimento se "relaciona"com 1 acontecimento; 1:N:
aponta que 1 acontecimento se "relaciona"com varios acontecimentos; N:N: vários acontecimetos
se "relacionam", com varios acontecimentos (MEIRA, 2013).
O sistema de banco de dados deve garantir uma visão totalmente abstrata do banco de
dados para o usuário. Esta abstração se dá em três níveis: nível de visão do usuário: as partes
do banco de dados que o usuário tem acesso de acordo com a necessidade individual de cada
usuário ou grupo de usuários; nível conceitual e nível físico que será explicado porteriormente
(DEVMEDIA, 2006).
2.7.3 Modelo Conceitual
É a descrição do BD de maneira independente ao SGBD, ou seja, define quais os dados
que aparecerão no BD, mas sem se importar com a implementação que se dará ao BD, desta
forma, há uma abstração em nível SGBD. Uma das técnicas utilizadas dentre os profissionais da
área é a abordagem entidade relacionamento (ER), onde o modelo é representado graficamente
através do modelo entidade relacionamento (MER) (SPACEPROGRAMMER, 2016).
2.7.4 Modelo Lógico
Descreve o BD no nível SGBD, ou seja, depende do tipo particular do SGBD que será
usado. Não podemos confundir o software que será usado. O tipo de SGBD que o modelo lógico
trata é se o mesmo é relacional, orientado a objetos, Hierárquico, etc. Abordaremos o SGBD
relacional, por serem os mais difundidos. Nele, os dados são organizados em tabelas. O modelo
lógico relacional deve definir quais as tabelas e o nome das colunas que compõem estas tabelas
(SPACEPROGRAMMER, 2016).
16
2.7.5 Modelo Físico
O modelo físico descreve por meio de alguma linguagem, como será feita a armazenagem
no BD. Nesse nível se escolhe qual sistema gerenciador de banco de dados (SGBD) será usado,
levando em consideração o modelo lógico adotado (SPACEPROGRAMMER, 2016).
2.7.6 Projeto e Implementação
A seguir, serão abordadas algumas das principais fases do projeto, que são: levantamento
e análise de requisitos; projeto conceitual do banco de dados; escolha do SGBD; projeto lógico;
projeto físico.
Portanto, foram criadas as entidades com seus atributos, chaves primárias e seus rela-
cionamentos na imagem 4. As entidades são: funcionário, autenticação, categoria do produto,
produto, cliente, venda, pagamento, produto venda. Assim, essas entidade tem relacionamentos
entre si, de cardinalidade: 1 : 1, 1 : N, N : N. Na imagem abaixo podemos ver modelo conceitual.
Figura 4 – Modelo Conceitual
Fonte: Próprio Autor, 2021
Assim, utilizou o software BRMODELO para a criação da representação conceitual
e assim se originou a diagramação com as cardinalidades das relações que estão contidas na
imagem 5. Portanto, a partir do conceitual surgiu a modelação lógica, e essa tem princípios da sua
antessora, mais com enfoque na entidade Venda, onde contém chaves primárias de funcionario,
forma de pagamento, cliente e produto-venda, essas são chaves estrangeiras em Venda. E a chave
primaria de autenticacao é chave estrangeira em funcionario e a chave primária de produto é
chave estrangeira em produto-venda.
17
Figura 5 – Modelo Lógico
Fonte: Próprio Autor, 2021
Na imagem 6 contém o modelo físico, onde foi desenvolvido o banco de dados.
Os passos deste desenvolvimento foram: 1º: criou a tabela Cliente, seguindo as determi-
nações dos modelos anteriores, na tabela estabeleceu que o codigo, cpf, rg e numero de cartao
são campos UNIQUE, para que esses dados não se repitam; 2º: elaborou a tabela Autenticação,
essa continha seus atributos e um codigo como chave primária UNIQUE, para esse codigo não
seja repetido, e esse codigo se tornou chave estrangeira na tabela funcionario, que a partir da
chave estrangeira é vinculado com dados usuario e senha de Autenticacao; 3º: o desenvolvimento
da Categoria de Produo e Produto, onde o vínculo ocorre no codigo que é chave primária de
Categoria e chave estrangeira em Produto, na inserção de dados nessas tabelas, primeiro tem de
especificar as categorias para que depois adicione os produto, se não ocorrer desta forma causará
um erro; 4º: criação das tabelas Produto-Venda, onde tem uma chave primária e recebe a chave
estrangeira da tabela Produto, e Forma-Pagamento contém uma chave primária e um atributo; 5º:
elaboração da tabela Venda, que recebe as chaves primárias de Forma-Pagamento, Funcionario,
Cliente e Produto-Venda como chave estrangeira, tendo também alguns atributos.
18
Figura 6 – Modelo Físico
Fonte: Próprio Autor, 2021
19
3 CONCLUSÃO
20
REFERÊNCIAS
CARVALHO, Victorio Albani; TEXEIRA, Giovany Frossard. Programação Orientada a
Objeto. 2012. Disponível em: <http://redeetec.mec.gov.br/images/stories/pdf/eixo_infor_
comun/tec_inf/081112_progr_obj.pdf>. Acesso em: 24 de maio de 2021. Citado na página 12.
DEVMEDIA. Conceitos Fundamentais de Banco de Dados. 2006. Disponível em:
<https://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649>. Acesso em:
5 de junho de 2021. Citado 2 vezes nas páginas 14 e 15.
DEXTRA. Requisito ou Regra de Negócio. 2013. Disponível em: <https://www.dextra.com.
br/blog/requisito-ou-regra-de-negocio>. Acesso em: 19 de maio de 2021. Citado na página 7.
MACORATTI, José Carlos. Modelando Sistemas em UML - Casos de Uso. 2004. Disponível
em: <http://www.macoratti.net/net_uml2.htm>. Acesso em: 4 de maio de 2021. Citado na
página 6.
MEIRA, Regilan. Banco de Dados. IFBA – Campus Ilhéus, 2013. Disponível em:
<http://www.regilan.com.br/wp-content/uploads/2013/10/Apostila-Banco-de-Dados.pdf>.
Acesso em: 5 de junho de 2021. Citado na página 15.
SIGNIFICADOS. Significado de Diagrama de classes. 2018. Disponível em: <https:
//www.significados.com.br/diagrama-de-classes/>. Acesso em: 24 de maio de 2021. Citado na
página 12.
SOUZA, Givanaldo Rocha. Diagrama de Classe. IFRN, 2021. Disponível em: <https://docente.
ifrn.edu.br/givanaldorocha/disciplinas/engenharia-de-software-licenciatura-em-informatica/
diagrama-de-classes>. Acesso em: 24 de maio de 2021. Citado na página 12.
SPACEPROGRAMMER. Introdução ao Modelo de Dados e Seus Ní-
veis de Abstração. 2016. Disponível em: <http://spaceprogrammer.com/bd/
introducao-ao-modelo-de-dados-e-seus-niveis-de-abstracao/>. Acesso em: 5 de ju-
nho de 2021. Citado 2 vezes nas páginas 15 e 16.
WIKIPEDIA. UML. 2017. Disponível em: <https://pt.wikipedia.org/wiki/UML>. Acesso em:
23 de maio de 2021. Citado na página 6.
WIKIPÉDIA. Diagrama de Caso de Uso. 2015. Disponível em: <https://pt.wikipedia.org/wiki/Diagrama_de_caso_de_uso>. Acesso em: 4 de maio de 2021. Citado na página 6.
http://redeetec.mec.gov.br/images/stories/pdf/eixo_infor_comun/tec_inf/081112_progr_obj.pdf
http://redeetec.mec.gov.br/images/stories/pdf/eixo_infor_comun/tec_inf/081112_progr_obj.pdf
https://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649
https://www.dextra.com.br/blog/requisito-ou-regra-de-negocio
https://www.dextra.com.br/blog/requisito-ou-regra-de-negocio
http://www.macoratti.net/net_uml2.htm
http://www.regilan.com.br/wp-content/uploads/2013/10/Apostila-Banco-de-Dados.pdf
https://www.significados.com.br/diagrama-de-classes/
https://www.significados.com.br/diagrama-de-classes/
https://docente.ifrn.edu.br/givanaldorocha/disciplinas/engenharia-de-software-licenciatura-em-informatica/diagrama-de-classes
https://docente.ifrn.edu.br/givanaldorocha/disciplinas/engenharia-de-software-licenciatura-em-informatica/diagrama-de-classes
https://docente.ifrn.edu.br/givanaldorocha/disciplinas/engenharia-de-software-licenciatura-em-informatica/diagrama-de-classes
http://spaceprogrammer.com/bd/introducao-ao-modelo-de-dados-e-seus-niveis-de-abstracao/
http://spaceprogrammer.com/bd/introducao-ao-modelo-de-dados-e-seus-niveis-de-abstracao/
https://pt.wikipedia.org/wiki/UML
https://pt.wikipedia.org/wiki/Diagrama_de_caso_de_uso
https://pt.wikipedia.org/wiki/Diagrama_de_caso_de_uso
	Folha de rosto
	Resumo
	Abstract
	Sumário
	Introdução
	Sistema de Controle de Estoque e Vendas
	UML - Linguagem de Modelagem Unificada
	DIAGRAMA DE CASOS DE USO
	Especificações dos Casos de Uso
	Layout do sistema
	Programação Orientado a objeto - POO
	Diagrama de Classe
	Banco de Dados
	Sistema de gerenciamento de banco de dados (SGBD)
	Principais Elementos
	Modelo Conceitual
	Modelo Lógico
	Modelo Físico
	Projeto e Implementação
	Conclusão
	Referências