(NOTA 9) PIM VI LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE CONTROLE DE VENDAS DE UMA LOJA DE JOGOS E PRODUTOS GEEKS - UNIP ANÁLISE E DESENVOLVIMENTO DE SISTEMAS Passei Direto PARTE 3 PIM 6(

Prévia do material em texto

20
 (
Impresso
 
por
 
Josivan
 
Leandro,
 
CPF
 
389.122.488-55
 
para
 
uso
 
pessoal
 
e
 
privado.
 
Este
 
material
 
pode
 
ser
 
protegido
 
por
 
direitos
 
autorais
 
e
 
não
 
pode
 
ser
 
reproduzido
 
ou
 
repassado
 
para
 
terceiros.
 
18/05/2022
 
22:34:42
)
Tabela 6 — UC006 | Logar
Interessados e Interesses:
Ator Principal: Funcionário
*Funcionário: deseja se autenticar no sistema para realizar suas funções.
Pré-Condições: o usuário deve ter seu cadastrado no sistema. Pós-Condições: usuário autenticado
Fluxo Alternativo
1. O Usuário entra com Login e Senha.
2. O Sistema irá autenticar 3 . Sistema liberado.
Fluxo Alternativo;
(A1) Alternativa do Passo 3 Erro ou Bloqueio de acesso.
1.a O usuário deve comunicar o Administrador do sistema. Fonte: O autor (2021)
Tabela 7 — UC007 | Efetuar Pagamento
Ator Principal: Cliente
Interessados e Interesses:
* Cliente: deseja escolher a forma de pagamento.
Pré-Condições: está com o meio de pagamento em "mãos". Pós-Condições: pagamento efetuado.
Fluxo Principal
1. O Cliente escolha a forma de pagamento.
2. O atendente informa ao sistema a forma de pagamento,
3. Sistema valida a forma de pagamento.
4. Pagamento efetuado.
Fluxo Alternativo;
(A1) Alternativa do Passo 3 Erro
1.a É repetido novamente os passos iniciais do fluxo principal. Fonte: O autor (2021)
21
Tabela 8 — UC008 | Registrar Venda
Ator Principal: Sistema Financeiro
Interessados e Interesses:
* Sistema Financeiro: necessita do código de venda para armazenar registrar.
Pré-Condições: a venda deve ter sido efetuada Pós-Condições: o sistema registra a venda
Fluxo Principal
1. Compra efetuada
2. O Sistema registra a venda Fluxo Alternativo
Fonte: O autor (2021)
Figura 2 — Diagrama de Caso de Uso
Fonte: O autor (2021)
22
5.4 Diagrama de Classes
O diagrama de classes está entre os mais utilizados e mais úteis de diagramas UML. O digrama modela a estrutura de um sistema ou produto de software, suas classes, seus atributos, operações e relações entre objetos.
O diagrama de classes é poderosa ferramenta para a documentação de um sistema ou produto de software, sendo uma das técnicas mais utilizadas no desenvolvimento orientado a objetos.
O diagrama de classes não é somente amplamente usado, mas também o receptáculo para o maior escopo de conceitos de modelagem. Embora os elementos básicos sejam necessários para todos, os conceitos avançados são utilizados com menos frequência. Um diagrama de classes descreve os tipos de objetos no sistema e os vários tipos de relacionamentos estáticos que existem entre eles (FOWLER, 2000, p.57).
Na figura 2 é apresentado o diagrama de classes, contendo relação entre
classes. Nesse diagrama UML é tratado o termo tem um(representado pelo
número 1) e o termo tem vários(representado pelo símbolo *) para a relação entre classes.
23
Figura 3 — Diagrama de Classes
Fonte: O autor (2021)
5.4.1 Descrição das Classes
Cliente: Essa classe define os atributos e métodos necessários para
"manipular" o cliente no sistema. Essa classe tem relação
tem um
com a
classe Endereco, que recebe os atributos e métodos para manipular um endereço ao cliente.
Endereco: Essa classe define os atributos e métodos para "manipular" o endereço a um cliente.
Venda: Essa classe define os atributos e métodos para "manipular" o processo de venda no sistema. Essa classe tem relação tem um com a classe Produto, que recebe os atributos e métodos para "manipular" o produto no
processo de venda, e também tem relação
tem um
com a classe
24
FormaDePagamento que recebe atributos e métodos para "manipular" a forma de pagamento no processo de venda.
Produto: Essa classe define os atributos e métodos para "manipular" o produto no sistema. Essa classe tem relação tem um com a classe Categoria, que define os atributos e métodos para definir uma categoria ao produto.
Categoria: Essa classe define os atributos e métodos para definir uma categoria ao produto.
Estoque: Essa classe define os atributos e métodos para "manipular" um
produto no estoque. Essa classe tem relação Produto.
tem vários
com a classe
Financeiro: Essa classe define os atributos e métodos para "manipular" as
vendas no módulo financeiro. Essa classe tem relação classe Venda.
tem vários
com a
Funcionario: Essa classe define os atributos e métodos para "manipular" o acesso de funcionários nas funcionalidades do sistema.
Atendente, Estoquista, Supervisor: Essas classes filhas herdam da classe pai Funcionario.
Observações:
A palavra "manipular" foi tratada nesse contexto para atribuir uma coerência textual para se referir ao processos: incluir, deletar pesquisar, relatório etc.
A partir do contexto ágil, todos os requisitos tratados aqui no levantamento desse projeto, podem sofrer alterações, novas inclusões e deleções no decorrer do ciclo de vida em um cenário real, ou seja, os levantamentos feitos aqui são aqueles que são apresentados em uma fase inicial do projeto, que são amplamente apodados nos princípios da metodologia Ágil Scrum.
25
6 MODELO ENTIDADE RELACIONAMENTO
Nesse projeto, o Banco de Dados utilizado foi o MySQL relacional em sua versão 8.0.25.0. O MySql é um dos SBDA mais utilizadados no mundo, devido a sua facilidade e desempenho, por esse motivo foi adotado nesse projeto.
Abaixo, na figura 3 é representado o modelo de entidade relacionamento do banco de dados .
Figura 4 — MER
Fonte: O autor (2021)
26
7 CONCLUSÃO
Diante da contextualização do caso proposto, foi realizado o levantamento e análise de requisitos de um novo sistema tecnológico que substitui o atual "sistema" de controle de vendas feito no Excel, utilizado tecnologias e metodologias para confecção do projeto.
Com o apoio dos conceitos das disciplinas cursadas no atual bimestre, foi confeccionado a analise e levantamento de requisitos de um novo sistema funcional para loja de produtos geeks. Utilizando os conceitos da disciplina Análise Orientada a Objetos, foi possível definir os requisitos, regras de negócio e caso de uso para o sistema. Com a disciplina Gestão de RH foi possível contextualizar a equipe de RH responsável por procurar novos desenvolvedores para o cenário proposto. A disciplina de Banco de Dados, foi utilizada para definir o modelo de entidade de relacionamento do sistema.
Ao final foi possível a criação de um projeto viável e funcional, obedecendo as metodologias e análises para o desenvolvimento do mesmo.
27
REFERÊNCIAS
CAVALCANTI, ANDERSON. Modelo de Casos de Uso e Diagrama de Casos de Uso. DEPARTAMENTO DE ENGENHARIA DE COMPUTAÇÃO E AUTOMAÇÃO.
Disponível em: https://www.dca.ufrn.br/~anderson/FTP/dca0120/P2_Aula3.pdf. Acesso em: 20 mai. 2021.
PEREIRA, ROBERTO. Casos de Uso. LInterHAD. Disponível em: https://interhad.nied.unicamp.br/courses/roberto-pereira/ci163-projeto-de-software- ufpr-1/agenda/cap02-1-mar2013.pdf. Acesso em: 21 mai. 2021.
VENTURA, Plínio. O que é Requisito Funcional. Disponível em: https://www.ateomomento.com.br/o-que-e-requisito-funcional/. Acesso em: 28 mai. 2021.
VENTURA, Plínio. O que é um Requisito Não-Funcional. Disponível em: https://www.ateomomento.com.br/o-que-e-um-requisito-nao-funcional/. Acesso em: 29 mai. 2021.
VIANA, Davi. Partindo dos processos de negócio e chegando aos requisitos de sistemas. dheka. Disponível em: https://www.dheka.com.br/processos-de-negocio- e-requisitos-de-sistemas/. Acesso em: 27 mai. 2021.