PIM_VI_ABNT_Format_Corrigido

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP EAD
Pedro Oliveira Sana Da Silva –RA 2446911
Projeto integrado multidisciplinar VI
Levantamento e a Análise de Requisitos de um Sistema de controle de vendas de uma loja de jogos, acessórios e produtos geek.
SOROCABA/SP
2025
UNIVERSIDADE PAULISTA – UNIP EAD
Pedro Oliveira Sana Da Silva –RA 2446911
Projeto integrado multidisciplinar VI
Projeto Integrado Multidisciplinar em
Análise e desenvolvimento de sistemas
Projeto Integrado Multidisciplinar
para obtenção do título de tecnólogo em
Análise e desenvolvimento de sistemas,
apresentado à Universidade Paulista – UNIP EAD.
Orientador (a): Angel Antônio
Sorocaba
2025
RESUMO
 
O presente trabalho tem como objetivo o levantamento e a análise de requisitos para o desenvolvimento de um sistema de controle de vendas voltado a uma loja de jogos eletrônicos, acessórios e produtos geek. A proposta visa proporcionar maior controle sobre os estoques, cadastros de clientes, processos de venda, e controle de acesso ao sistema, contemplando funcionalidades como registro de usuários, gerenciamento de produtos por categoria, processamento de vendas com diferentes formas de pagamento e controle de permissões. O desenvolvimento segue as metodologias da engenharia de software orientada a objetos, com base nos conhecimentos adquiridos nas disciplinas de Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégica de Recursos Humanos. O resultado é um modelo de sistema desktop eficiente, acessível e adaptado às necessidades operacionais da empresa.
 
Palavras-chave: Requisitos de Software. Análise de Sistemas. Controle de Vendas. Loja Geek. Engenharia de Software.
 
 
 
ABSTRACT
 
This work aims to identify and analyze the requirements for developing a sales control system for a store that sells electronic games, accessories, and geek products. The proposed system aims to improve the management of inventory, customer records, sales processes, and system access control. It includes user registration, categorization of products, sales processing with multiple payment methods, and user permission management. The development is guided by object-oriented software engineering methodologies, based on knowledge from the courses in Object-Oriented Systems Analysis, Database, and Strategic Human Resource Management. The outcome is an efficient and accessible desktop system model tailored to the store’s operational needs.
Keywords: Software Requirements. Systems Analysis. Sales Control. Geek Store. Software Engineering.
SUMÁRIO
1. Introdução..................................................................................7
2. Contexto e fundamentação Teórica........................................8
 2.1 Cenário do Problema.................................................................................8
 2.2 Justificativa................................................................................................8
 2.3 Objetivos....................................................................................................9
 2.4 Soluções disponíveis no mercado.............................................................9
3. Objetivos do Sistema...............................................................12
 3.1 Requisitos Funcionais...............................................................................12
 3.2 Requisitos Não funcionais........................................................................14
 3.3 Regras de negócio....................................................................................14
 3.4 Casos de uso do sistema..........................................................................15
4. Modelagem do sistema................................................25
5. DIAGRAMA DE CLASSES E MODELO ENTIDADE-RELACIONAMENTO (MER)..........................................................27
 5.1 Considerações Iniciais.............................................................................27
 5.2 Diagrama de Classes...............................................................................28
 5.3 Modelo Entidade-Relacionamento (MER)................................................30
 5.4 Regras de Integridade..............................................................................31
 5.5 Modelo Conceitual................................................................................32
 5.6 Considerações Finais...........................................................................32
 6. DISCUSSÃO SOBRE USABILIDADE E ACESSIBILIDADE..................33
 6.1 Usabilidade...........................................................................................33
 6.2 Acessibilidade.......................................................................................34
 6.3 Inclusão e Responsabilidade Social.....................................................35
7. considerações finais..............................................................36
Referencias.................................................................................37
 
 
 
 
 
 
 
 
 
 
 
1. INTRODUÇÃO
A tecnologia da informação transformou de forma significativa a maneira como empresas gerenciam seus processos internos e interagem com seus clientes. Dentre os diversos segmentos impactados, o mercado de jogos eletrônicos e produtos relacionados à cultura geek tem se destacado por seu crescimento exponencial, exigindo soluções cada vez mais especializadas para a gestão de suas operações. Com base nessa necessidade, o presente Projeto Integrado Multidisciplinar (PIM VI) propõe o desenvolvimento de um sistema de controle de vendas para uma loja especializada em jogos, acessórios e produtos geek.
Atualmente, muitas pequenas e médias lojas desse setor ainda utilizam soluções manuais ou planilhas eletrônicas para administrar seus estoques e efetuar o controle de vendas, o que pode comprometer a eficiência, a segurança das informações e a tomada de decisões estratégicas. Dessa forma, torna-se essencial o uso de um sistema informatizado, capaz de automatizar processos operacionais, reduzir erros humanos e fornecer dados em tempo real aos gestores.
Este trabalho tem como objetivo principal realizar o levantamento e a análise de requisitos para o desenvolvimento de um sistema desktop, destinado ao controle de vendas e gestão de estoque da loja. O projeto será baseado nas disciplinas do curso de Análise e Desenvolvimento de Sistemas, especialmente nas áreas de Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégica de Recursos Humanos.
A metodologia adotada envolve a utilização de técnicas da engenharia de requisitos, modelagem UML, análise de contexto, identificação de regras de negócio e elaboração de modelos conceituais, como o diagrama de casos de uso, diagrama de classes e modelo entidade-relacionamento (MER). Também serão consideradas as boas práticas de usabilidade, acessibilidade e segurança de sistemas.
Ao final do projeto, espera-se apresentar uma proposta de solução tecnológica robusta, capaz de atender às demandas da loja, melhorando significativamente sua operação e a experiência dos usuários — atendentes, estoquistas e supervisores. Este PIM também visa integrar os conhecimentos teóricos adquiridos ao longo do curso com uma aplicação prática e realista, refletindo a importância da interdisciplinaridade e da análise sistêmica no desenvolvimento de softwares.
2. CONTEXTO E FUNDAMENTAÇÃO TEÓRICA
 
2.1 Cenário do Problema
O presente projeto foi idealizado para uma loja especializada em jogos eletrônicos, acessórios e produtos geek. Esta loja, embora popular entre seu público-alvo, enfrenta desafios operacionais decorrentes do uso de métodos manuais de gestão, como planilhas de Excel para controle de vendas e estoque. Essa prática, além de suscetível a erros, não oferece integração entre setores, nem controle de acesso, e muito menos relatórios em tempo real.
Dessa forma, foi estabelecido um contrato com uma empresade desenvolvimento de software (representada aqui pelo grupo do PIM VI), para a construção de um sistema de controle de vendas e estoque, com foco em automação, organização e acessibilidade. O sistema deverá abranger funcionalidades como cadastro de clientes e produtos, processamento de vendas, controle de usuários por níveis de permissão, e relatórios operacionais.
 
2.2 Justificativa
A ausência de um sistema automatizado compromete diretamente a agilidade e a confiabilidade nas operações da loja. Erros de digitação, perdas de dados e ausência de rastreabilidade de vendas são comuns em processos manuais. Com um sistema informatizado, será possível padronizar e proteger as informações, além de gerar dados estratégicos para decisões gerenciais.
A proposta também inclui preocupações com acessibilidade, garantindo que usuários com deficiência possam utilizar o sistema com facilidade, promovendo inclusão digital.
 
2.3 Objetivos
Objetivo Geral:
Realizar o levantamento e análise de requisitos de um sistema desktop para o controle de vendas de uma loja de jogos, acessórios e produtos geek, integrando os conhecimentos adquiridos nas disciplinas de Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégica de Recursos Humanos.
Objetivos Específicos:
Identificar os requisitos funcionais e não funcionais do sistema;
Elaborar o diagrama de casos de uso e suas descrições;
Construir o modelo de classes de análise (Boundary, Control e Entity);
Desenvolver o modelo entidade-relacionamento (MER)
Considerar aspectos de acessibilidade, segurança e usabilidade;
Integrar conceitos de gestão de pessoas no uso e manutenção do sistema.
 
2.4 SOLUÇÕES DISPONÍVEIS NO MERCADO
É essencial para qualquer loja, independentemente do tipo de produto comercializado, contar com uma ferramenta que auxilie na sua gestão.
 Os sistemas de gerenciamento de loja desempenham um papel crucial no funcionamento da empresa, pois são responsáveis por controlar o fluxo financeiro, monitorando entradas e saídas.
 Além disso, permitem o gerenciamento eficiente do estoque, garantindo o controle dos produtos disponíveis.
Existem inúmeros sistemas que facilitam outras empresas a gerenciar suas vendas.
1. Bling ERP
· Descrição: Sistema de gestão empresarial voltado para micro e pequenas empresas.
· Principais recursos:
· Controle de estoque em tempo real.
· Emissão de notas fiscais eletrônicas.
· Integração com marketplaces e e-commerces.
· Gestão financeira com fluxo de caixa e contas a pagar/receber.
· Ideal para: Lojas físicas e virtuais que precisam de um sistema completo e acessível.
· Mensalidade inicial: R$ 50,00/mês
2. Omie
· Descrição: Plataforma de ERP na nuvem com foco em automação e integração.
· Principais recursos:
· Gestão de vendas, compras e estoque.
· Controle financeiro e emissão de boletos.
· Integração com contabilidade e CRM.
· Relatórios gerenciais e dashboards.
· Ideal para: Pequenas e médias empresas que buscam escalabilidade e automação.
· Mensalidade inicial: R$ 49,90/mês
3. Tiny ERP
· Descrição: Sistema de gestão online muito utilizado por e-commerces e lojas físicas.
· Principais recursos:
· Controle de estoque com alertas de reposição.
· Integração com plataformas como Mercado Livre, Shopee e Shopify.
· Gestão de pedidos, notas fiscais e logística.
· Relatórios financeiros e de desempenho.
· Ideal para: Lojas que vendem em múltiplos canais e precisam de integração eficiente.
· Mensalidade inicial: R$ 50,00/mês
3. ANÁLISE E LEVANTAMENTO DE REQUISITOS
3.1 Análise de Requisitos
A análise de requisitos constitui uma etapa essencial no desenvolvimento de sistemas de informação, sendo responsável pela identificação, organização e especificação das necessidades funcionais e não funcionais que a aplicação deverá atender. Esta fase garante que as funcionalidades esperadas estejam alinhadas às demandas da organização e dos usuários finais.
Fonte – Autor 
3.1.1 Requisitos Funcionais
Os requisitos funcionais correspondem às ações e comportamentos que o sistema deverá ser capaz de realizar. Para o sistema proposto, foram identificadas as seguintes funcionalidades essenciais:
RF01 – O sistema deverá permitir o acesso por meio de login e senha, com diferentes níveis de permissão (atendente, estoquista e supervisor).
RF02 – O sistema deverá permitir o cadastro, consulta, alteração e exclusão de clientes.
RF03 – O sistema deverá permitir o cadastro, consulta, alteração e exclusão de produtos, categorizados em jogos, acessórios e produtos geek.
RF04 – O sistema deverá armazenar informações adicionais para produtos das categorias jogos e acessórios, como plataforma e prazo de garantia
RF05 – O sistema deverá permitir o registro de vendas, incluindo os dados do cliente e dos produtos adquiridos.
RF06 – O atendente deverá ter permissão para remover produtos de uma venda em andamento.
RF07 – Somente o supervisor poderá excluir produtos de uma venda finalizada, mediante autenticação adicional.
RF08 – Somente o supervisor poderá cancelar vendas, mediante fornecimento de usuário e senha válidos.
RF09 – O sistema deverá registrar a forma de pagamento (dinheiro ou cartão), bem como o status do pagamento e da venda.
RF10 – Cada venda deverá possuir um código único e conter a data e o valor total da transação.
RF11 – Em caso de cancelamento da venda, o sistema deverá encaminhar os dados para o sistema financeiro da organização
RF12 – O sistema deverá permitir a consulta de preços dos produtos por parte do atendente.
RF13 – O sistema deverá gerar relatórios de vendas e de controle de estoque.
 
3.1.2 Requisitos Não Funcionais
Os requisitos não funcionais referem-se às restrições e qualidades que o sistema deve apresentar, incluindo aspectos de desempenho, segurança, usabilidade e acessibilidade. Para o sistema em questão, foram identificados os seguintes requisitos:
RNF01 – O sistema deverá apresentar uma interface gráfica amigável, intuitiva e padronizada, facilitando a navegação por usuários com diferentes níveis de conhecimento técnico.
RNF02 – O acesso ao sistema deverá ser realizado exclusivamente por meio de autenticação segura (login e senha).
RNF03 – O tempo de resposta para operações de cadastro, consulta e venda deverá ser inferior a três segundo
RNF04 – O sistema deverá estar disponível para uso durante o horário comercial da loja, com mínima ocorrência de falhas.
RNF05 – O sistema deverá ser compatível com tecnologias assistivas, como leitores de tela e navegação por teclado, garantindo a acessibilidade para pessoas com deficiência.
RNF06 – A aplicação deverá ser compatível com o sistema operacional Windows e executada em ambiente desktop.
 
 
3.1.3 Regras de Negócio
As regras de negócio estabelecem diretrizes específicas da organização que devem ser respeitadas no funcionamento do sistema. Elas restringem e definem como um determinado processo deve ser executado, além de demonstrar conhecimentos com relação a um processo. A seguir, apresentam-se as principais regras identificadas:
 
Identificação RGN01 – Acesso ao Sistema Descrição Todo o acesso ao sistema é feito na loja por meio de login e senha Identificação 
RGN02 – O estoquista cadastra os produtos que serão vendidos na loja, os quais deverão ser dividos por categorias: jogos, acessórios e produtos geek Identificação 
RGN03 - Cadastro cliente Descrição Os cadastros dos clientes devem possuir, RG, CPF, nome, data do cadastro, endereço, telefone e e-mail do cliente. Identificação 
RGN04 – Especificação produtos Descrição Todos os produtos devem possuir: código de barras, nome do produto, categoria, fabricante, quantidade e valor do produto. Para os jogos e os acessórios, devem ser informados em qual plataforma serão utilizados e qual prazo de garantia o produto possui. Identificação 
RGN05 – Vendas de produtos Descrição A venda para ser realizada deverá conter dados do cliente e do produto adquiridos. Será gerado um código de venda, contendo data da venda, opção para pagamento, status do pagamento. Identificação 
RGN06 – Excluir produtos Descrição Ofuncionário poderá excluir os produtos do carrinho a qualquer momento quando o cliente não queira mais adquiri-lo o produto. Apenas o supervisor da loja com acesso adm acessando login e senha poderá excluir o produto do carrinho.
3.2 Casos de Uso do Sistema
Fazer Login 
Caso de Uso: Login no Sistema
Ator Principal: Usuário (Atendente, Estoquista ou Supervisor
Descrição: Permite o acesso ao sistema mediante autenticação com login e senha.
Pré-condição: O usuário deve estar previamente cadastrado no sistema.
Fluxo Principal:
1. O usuário insere o login e a senha.
2. O sistema verifica as credenciais.
3. O sistema libera o acesso conforme o perfil do usuário.
Fluxo Alternativo:
3a. Se as credenciais estiverem incorretas, o sistema exibe uma mensagem de erro.
Pós-condição: O usuário seja redirecionado à interface correspondente ao seu perfil.
Cadastrar produto
caso de Uso: Cadastrar Produto
Ator Principal: Estoquista
Descrição: Permite o cadastro de novos produtos no sistema, organizados por categoria.
Pré-condição: O estoquista deve estar autenticado
Fluxo Principal:
 1. O estoquista seleciona a opção "Cadastrar Produto".
 2. Insere os dados do produto (código de barras, nome, categoria, fabricante, quantidade, valor, plataforma – se aplicável – e prazo de garantia).
 3. Confirma a operação.
 4. O sistema armazena os dados no banco.
 Exceção:
 2a. Dados obrigatórios ausentes ou inválidos impedem a finalização do cadastro.
Pós-condição: O produto fica disponível para venda.
Cadastrar cliente
Caso de Uso: Cadastrar Cliente
Ator Principal: Atendente
Descrição: Realiza o cadastro de novos clientes na base de dados da loja.
Pré-condição: O atendente deve estar autenticado no sistema.
Fluxo Principal:
1. O atendente acessa a tela de cadastro.
2. Preenche os dados obrigatórios (código, RG, CPF, nome, data do cadastro, endereço, telefone e e-mail).
3. Confirma a operação.
4. O sistema salva os dados.
Exceção:
2a. Campos obrigatórios não preenchidos geram mensagem de erro.
Pós-condição: O cliente é armazenado no banco de dados.
Consultar produto
Caso de Uso: Consultar Produto
Ator Primário: Atendente, Estoquista
Resumo: Permite ao usuário buscar informações sobre produtos cadastrados.
Pré-condições: Usuário autenticado no sistema com permissão de consulta.
Fluxo Principal:
1. O usuário acessa a funcionalidade de consulta de produtos.
2. O sistema solicita um critério de busca (nome, código, categoria etc.).
 3. O usuário informa os critérios desejados.
 4. O sistema exibe os resultados compatíveis com os critérios.
Fluxos Alternativos:
3A. Critério inválido: o sistema exibe uma mensagem e solicita novo critério.
4A. Nenhum produto encontrado: o sistema informa que não houve correspondência.
Pós-condições: O usuário visualiza os dados dos produtos encontrados
Regras de Negócio:
Atendentes e estoquistas podem consultar preços
A consulta pode ser feita por diferentes critérios.
 
Editar produto
Caso de Uso: Editar Produto
Ator Primário: Estoquista
Resumo: Permite alterar dados de produtos cadastrado
Pré-condições: Usuário autenticado como estoquista.
Fluxo Principal:
1. Estoquista acessa a funcionalidade de edição de produto.
 2. O sistema solicita a identificação do produto (por código, nome etc.).
 3. Estoquista seleciona o produto e edita os campos desejados.
 4. O sistema valida os dados inseridos.
5. O sistema atualiza as informações do produto.
 Fluxos Alternativos:
3A. Produto não encontrado: o sistema informa o erro.
4A. Dados inválidos: o sistema informa e solicita correção.
 Pós-condições: As informações do produto são atualizadas no banco de dados.
Regras de Negócio:
Apenas estoquistas podem editar produtos.
Produtos são classificados em categorias com campos específicos (ex: plataforma e garantia para jogos/acessórios).
Realizar venda
Caso de Uso: Realizar Venda
Ator Principal: Atendente
Descrição: Registra a venda de um ou mais produtos a um cliente.
Pré-condição: O atendente deve estar autenticado.
 Fluxo Principal:
1. O atendente seleciona o cliente.
2. Adiciona os produtos desejados.
3. Escolhe a forma de pagamento (dinheiro ou cartão).
4. Confirma a venda.
5. O sistema gera um código único para a venda e atualiza o estoque.
 
Fluxo Alternativo:
 2a. O atendente pode remover produtos antes da finalização.
Pós-condição: A venda é registrada no sistema com os dados do cliente, produtos e status de pagamento.
Cancelar venda
Caso de Uso: Cancelar Venda
Ator Principal: Supervisor
Descrição: Permite o cancelamento de uma venda registrada.
Pré-condição: O supervisor deve estar autenticado
Fluxo Principal:
1. O supervisor informa o código da venda a ser cancelada.
2. Confirma o cancelamento.
3. O sistema atualiza o status da venda e envia os dados ao sistema financeiro.
Exceção:
1a. Venda inexistente ou já cancelada gera uma mensagem de erro.
Pós-condição: A venda é anulada e seus dados encaminhados ao setor financeiro.
Gerar relatório de vendas
Caso de Uso: Gerar Relatório de Vendas
Ator Primário: Supervisor
Resumo: Permite gerar relatórios com base nas vendas realizadas.
Pré-condições: Supervisor autenticado no sistema.
Fluxo Principal
1. Supervisor acessa a funcionalidade de relatórios.
2. O sistema solicita filtros (data, forma de pagamento, status etc.)
3. Supervisor define os filtros.
4. O sistema gera e exibe o relatório de vendas.
Fluxos Alternativos:
3A. Nenhum dado encontrado: o sistema informa que não há vendas para os filtros selecionados.
Pós-condições: Relatório é gerado e pode ser exportado.
Regras de Negócio:
Apenas supervisores podem acessar relatórios.
Relatórios podem incluir total por período, produtos mais vendidos, formas de pagamento etc.
Excluir produto da venda (restrito ao supervisor)
Caso de Uso: Excluir Produto da Venda
Ator Primário: Atendente, supervisor
Resumo: Permite a remoção de um produto de uma venda em andamento.
Pré-condições: Venda em andamento. Usuário autenticado com permissão.
Pós-condições: Produto é removido da venda.
 Fluxo Principal:
1. Atendente acessa a venda em andamento.
 2. O sistema exibe os produtos incluídos na venda.
3. O atendente seleciona o produto a ser removido.
4. O sistema solicita autenticação do supervisor.
 5. Supervisor autêntica com usuário e senha válidos.
 6. O sistema remove o produto da venda e atualiza os valores.
 Fluxos Alternativos:
5A. Autenticação inválida: o sistema exibe mensagem de erro e não realiza a exclusão.
3A. Produto não encontrado na venda: o sistema exibe uma mensagem de erro.
Regras de Negócio:
Apenas o supervisor pode confirmar a exclusão de um produto da venda
A venda deve estar em andamento para que o produto seja removido.
Os casos de uso representam, de forma estruturada, as funcionalidades que o sistema deverá oferecer, a partir da interação entre os usuários (atores) e o sistema. Cada caso de uso descreve um cenário específico e visa capturar os requisitos funcionais por meio de uma linguagem acessível e padronizada, conforme os princípios da UML (Unified Modeling Language).
4. MODELAGEM DO SISTEMA
A modelagem do sistema foi realizada com base nos requisitos levantados, utilizando a linguagem UML. Foram elaborados dois principais diagramas: o diagrama de casos de uso e o diagrama de classes.
Casos de uso e relações:
· > entre Realizar Venda e Consultar Produto
· > de Excluir Item da Venda para Realizar Venda
· > de Cancelar Venda para Realizar Venda
· > de Realizar Login para todos os usuários
Atores identificados:
· Atendente: realiza vendas, cadastra clientes, consulta produtos
· Estoquista: cadastra e edita produtos
· Supervisor: exclui itens de venda, cancela vendas, gera relatórios
Diagrama de classes (principais classes):
· Produto: código de barras, nome, categoria, fabricante, quantidade, valor, plataforma, garantia
 Métodos: cadastrar (), editar (), consultar ()
· Cliente: código, nome, RG, CPF, endereço, telefone, email, dataCadastro
 Métodos: cadastrar (), editar (), excluir ()
· Venda: codigoVenda, data, valorTotal, statusVenda, statusPagamentoMétodos: adicionarProduto(), removerProduto(), concluirVenda()
· Usuário: login, senha, tipoUsuario
 Métodos: autenticar ()
· ControlVenda: realizarVenda(), cancelarVenda(), gerarRelatorio()
· Boundary (interfaces): TelaLogin, TelaCadastroProduto, TelaVenda
Relacionamentos:
· Cliente 1:N Venda
· Venda 1:N Produto (via ItemVenda)
· Produto pode estar em várias vendas
· Usuário define o acesso às funcionalidades conforme o perfil
5. DIAGRAMA DE CLASSES E MODELO ENTIDADE-RELACIONAMENTO (MER)
5.1 Considerações Iniciais
O Diagrama de Classes e o Modelo Entidade-Relacionamento (MER) são essenciais para a modelagem estrutural do sistema, definindo a organização dos dados e as interações entre os componentes do software. A partir dos requisitos levantados e das regras de negócio identificadas, foi realizada a modelagem conceitual, que orientará o desenvolvimento do sistema.
Enquanto o Diagrama de Classes representa a estrutura interna do sistema, destacando classes, atributos e métodos, o MER foca na organização e persistência dos dados no banco, estabelecendo entidades, relacionamentos e restrições de integridade.
5.2 Diagrama de Classes
O Diagrama de Classes foi elaborado com base na metodologia de Análise Orientada a Objetos, utilizando as categorias clássicas de classes:
· Boundary (Fronteira): responsáveis pela interface com o usuário.
· Control (Controle): responsáveis pela lógica de negócios.
· Entity (Entidade): representam os objetos persistentes do sistema.
Principais Classes do Sistema
1. Produto
a. Atributos: códigodeBarras, nome, categoria, fabricante, quantidade, valor, plataforma, garantia
b. Métodos: cadastrar (), editar (), consultar ()
2. Cliente
a. Atributos: código, nome, RG, CPF, endereço, telefone, e-mail, dataCadastro
b. Métodos: cadastrar (), editar (), excluir ()
3. Venda
a. Atributos: codigoVenda, data, valorTotal, statusVenda, statusPagamento
b. Métodos: adicionarProduto(), removerProduto(), concluirVenda()
4. Usuário
a. Atributos: login, senha, tipoUsuario
b. Métodos: autenticar ()
5. ControlVenda
a. Métodos: realizarVenda(), cancelarVenda(), gerarRelatorio()
6. Boundary (Interfaces de Usuário)
a. Telas: TelaLogin, TelaCadastroProduto, TelaVenda
Relacionamentos entre Classes
· Cliente → possui relacionamento 1:N com Venda: um cliente pode realizar várias vendas.
· Venda → possui relacionamento 1:N com Produto através da associação intermediária ItemVenda.
· Produto → pode ser associado a múltiplas vendas.
· Usuário → determina o nível de acesso e funções no sistema, sendo responsável por autenticar-se para executar as operações.
Além disso, foram identificadas as seguintes relações de dependência:
· >: entre “Realizar Venda” e “Consultar Produto”.
· >: entre “Excluir Item da Venda” e “Realizar Venda”; e entre “Cancelar Venda” e “Realizar Venda”.
5.3 Modelo Entidade-Relacionamento (MER)
O Modelo Entidade-Relacionamento define como os dados serão armazenados no Sistema de Gerenciamento de Banco de Dados (SGBD), garantindo a integridade e a consistência das informações.
Entidades e seus Atributos
1. CLIENTE
a. id_cliente (PK)
b. nome
c. rg
d. cpf
e. data_cadastro
f. endereco
g. telefone
h. email
2. PRODUTO
a. id_produto (PK)
b. codigo_barras
c. nome
d. categoria (jogo, acessório, geek)
e. fabricante
f. quantidade
g. valor
h. plataforma
i. garantia
3. VENDA
a. id_venda (PK)
b. id_cliente (FK)
c. data_venda
d. valor_total
e. forma_pagamento
f. status_pagamento
g. status_venda
4. ITEM_VENDA
a. id_item (PK)
b. id_venda (FK)
c. id_produto (FK)
d. quantidade
e. valor_unitario
5. USUARIO
a. id_usuario (PK)
b. nome_usuario
c. senha
d. perfil (atendente, estoquista, supervisor)
Relacionamentos
· CLIENTE → VENDA: relação 1:N (um cliente pode realizar várias vendas).
· VENDA → ITEM_VENDA: relação 1:N (uma venda contém vários itens).
· PRODUTO → ITEM_VENDA: relação 1:N (um produto pode estar associado a diversos itens de venda).
· USUARIO → não possui relação direta com as entidades de negócio, mas é essencial para o controle de acesso ao sistema.
5.4 Regras de Integridade
Para garantir a consistência dos dados, o sistema deve observar as seguintes regras:
· A exclusão de um cliente com vendas registradas deve ser impedida para manter a integridade referencial.
· A exclusão de um produto só será permitida se ele não estiver associado a vendas registradas.
· Toda venda deve obrigatoriamente possuir ao menos um item e estar vinculada a um cliente.
· A quantidade de produtos vendidos deve ser abatida automaticamente do estoque, evitando inconsistências.
5.5 Modelo Conceitual
O modelo conceitual foi estruturado para atender às necessidades operacionais e gerenciais da loja, permitindo a rastreabilidade completa das operações realizadas no sistema, tais como:
· Consulta detalhada sobre produtos e clientes.
· Registro histórico de vendas.
· Controle de estoque atualizado.
· Gerenciamento de permissões conforme o perfil de usuário.
O MER poderá ser representado graficamente por ferramentas como MySQL Workbench, Lucidchart, DBDesigner, ou Draw.io, facilitando a visualização e implementação das tabelas no SGBD.
5.6 Considerações Finais
A modelagem proposta assegura um sistema coeso, estruturado e alinhado com os princípios da engenharia de software orientada a objetos e com as práticas de desenvolvimento de sistemas de informação. Com isso, o sistema garantirá a eficiência no controle das operações da loja, promovendo confiabilidade, segurança e acessibilidade nas rotinas administrativas e comerciais.
6. DISCUSSÃO SOBRE USABILIDADE E ACESSIBILIDADE
6.1 Usabilidade
A usabilidade é um dos aspectos mais importantes no desenvolvimento de sistemas, pois impacta diretamente na eficiência, eficácia e satisfação dos usuários ao interagir com a aplicação. No sistema de controle de vendas para a loja de jogos, acessórios e produtos geek, o design foi orientado por princípios de design centrado no usuário, com foco na simplicidade, na clareza das funcionalidades e na minimização de erros operacionais.
Os principais aspectos de usabilidade considerados no desenvolvimento deste sistema foram:
· Layout intuitivo: As telas foram organizadas de forma lógica, com menus e botões posicionados conforme o fluxo natural de interação dos usuários. Ícones representativos e textos claros facilitam a navegação.
· Feedback imediato: O sistema proporciona respostas instantâneas às ações do usuário, como confirmações de operações bem-sucedidas e mensagens de erro em casos de falhas ou preenchimento incorreto de dados.
· Minimização de erros: A interface inclui validações de campos obrigatórios e padrões de entrada, como formatação adequada de CPF e e-mail, evitando inconsistências nos dados.
· Consistência: Todos os elementos seguem um padrão visual e funcional, garantindo que os usuários se sintam seguros e familiarizados com o ambiente, independentemente da funcionalidade que estejam utilizando.
· Facilidade de aprendizado: A curva de aprendizagem é reduzida, uma vez que os fluxos de interação foram desenhados para exigir poucos passos, geralmente não ultrapassando três cliques para as operações mais comuns, como o registro de vendas e o cadastro de clientes.
Além disso, o sistema disponibiliza tutoriais integrados e mensagens de ajuda que orientam o usuário durante a execução das tarefas, promovendo maior autonomia no uso da aplicação.
6.2 Acessibilidade
A acessibilidade digital consiste na garantia de que todas as pessoas, incluindo aquelas com deficiência visual, motora ou cognitiva, possam utilizar o sistema de forma plena e eficiente. Este princípio foi adotado como um dos pilares no desenvolvimento do sistema proposto, em conformidade com as boas práticas recomendadas pelas Diretrizes de Acessibilidade para Conteúdo Web (WCAG).
As principais medidas implementadas para assegurar a acessibilidade foram:
· Compatibilidade com tecnologias assistivas: Todos os elementos da interface possuem descrições semânticas e rótulos (labels) adequados, permitindo a interpretação por leitores de tela,como o NVDA e o JAWS.
· Contraste adequado de cores: O design das telas respeita parâmetros mínimos de contraste, assegurando que informações sejam legíveis por pessoas com deficiência visual ou daltonismo.
· Navegação por teclado: Todas as funcionalidades do sistema podem ser acessadas sem o uso do mouse, utilizando atalhos de teclado e navegação por tabulação, ampliando a acessibilidade para usuários com limitações motoras.
· Textos redimensionáveis: A interface foi projetada com elementos flexíveis que permitem o ajuste do tamanho das fontes sem prejuízo à disposição ou à integridade visual das telas.
· Mensagens visuais e sonoras: O sistema inclui alertas visuais para ações críticas, bem como a possibilidade de ativar feedback sonoro, oferecendo múltiplos canais de comunicação ao usuário.
O desenvolvimento acessível demonstra o compromisso com a responsabilidade social e com o cumprimento da Lei Brasileira de Inclusão da Pessoa com Deficiência (Lei nº 13.146/2015), que estabelece a obrigatoriedade de garantir o acesso de pessoas com deficiência a produtos, serviços e ambientes digitais.
6.3 Inclusão e Responsabilidade Social
A adoção de práticas que promovem a usabilidade e a acessibilidade não apenas amplia o público potencial do sistema, mas também fortalece a imagem institucional da empresa, mostrando seu compromisso com a inclusão digital e o respeito à diversidade.
Além do aspecto ético e legal, um sistema acessível melhora a experiência do usuário de maneira geral, pois elimina barreiras desnecessárias e promove uma interação mais fluida e eficiente para todos, independentemente de suas habilidades físicas ou cognitivas.
Por fim, investir em acessibilidade e usabilidade agrega valor ao produto, aumenta sua competitividade no mercado e contribui para o fortalecimento de uma cultura organizacional pautada na equidade e na responsabilidade social.
7. CONSIDERAÇÕES FINAIS
O desenvolvimento do presente Projeto Integrado Multidisciplinar (PIM VI) permitiu a aplicação prática dos conhecimentos adquiridos ao longo do curso de Análise e Desenvolvimento de Sistemas, evidenciando a importância da integração entre teoria e prática na formação profissional.
A proposta apresentada contemplou o levantamento e a análise de requisitos, a modelagem de classes e a definição do modelo entidade-relacionamento (MER) para um sistema de controle de vendas destinado a uma loja especializada em jogos eletrônicos, acessórios e produtos geek. O sistema foi concebido para automatizar processos que, até então, eram realizados de forma manual, promovendo maior eficiência, segurança e confiabilidade nas operações da empresa.
Além da modelagem estrutural e funcional, o projeto enfatizou aspectos fundamentais relacionados à usabilidade e acessibilidade, garantindo que a solução proposta seja inclusiva e atenda a um público diversificado, em conformidade com as legislações vigentes e as boas práticas de desenvolvimento de sistemas.
O desenvolvimento deste trabalho também proporcionou a oportunidade de aprofundar o conhecimento nas metodologias de engenharia de software orientada a objetos, bem como na utilização da UML para a modelagem de sistemas, reforçando a capacidade de análise crítica e de resolução de problemas complexos.
Por fim, destaca-se que o sistema modelado é escalável e flexível, podendo ser aprimorado e adaptado conforme as necessidades futuras da empresa. O trabalho cumpriu com êxito os objetivos propostos, demonstrando a relevância e a aplicabilidade dos conteúdos estudados nas disciplinas de Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégica de Recursos Humanos.
Espera-se que este projeto sirva de base para futuras implementações reais, contribuindo para a melhoria dos processos organizacionais e para o fortalecimento das competências técnicas e analíticas dos envolvidos.
Referências
ABRANTES, M. F.; SILVA, A. R.; COSTA, J. P. Engenharia de Software: Fundamentos e Aplicações. 2. ed. São Paulo: Pearson, 2021.
BÉLANGER, F.; VAN LEEUWEN, T. Sistemas de Informação: Gerenciamento, Análise e Desenvolvimento. São Paulo: Atlas, 2020.
PRESSMAN, R. S. Engenharia de Software: Uma Abordagem Profissional. 8. ed. Porto Alegre: Bookman, 2019.
SOMMERVILLE, I. Engenharia de Software. 10. ed. São Paulo: Pearson, 2018.
VAZQUEZ, P.; SILVA, R. UML Essencial: Modelagem Estruturada de Sistemas. Rio de Janeiro: LTC, 2017.
IEEE Computer Society. IEEE Standard for Software Quality Metrics Methodology. IEEE Std 1061-1998, 1998.
2
image1.png
image2.png
image3.png
image4.png