(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

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
Ator Principal: Funcionário
Interessados e Interesses:
*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)
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 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)
21
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
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 epresentado pelotem um(r
número e o termo representado pelo símbolo1) tem vários( *) para a relação entre
classes.
22
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
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 com atem um
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 com a classetem um
Produto, que recebe os atributos e métodos para "manipular" o produto no
processo de venda, e também tem relação com a classetem um
23
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
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 com a classe Categoria,tem um 
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 com a classetem vários
Produto.
Financeiro: Essa classe define os atributos e métodos para "manipular" as
vendas no módulo financeiro. Essa classe tem relação com atem vários
classe Venda.
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.
24
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
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)
25
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
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 . Utilizando os conceitos da disciplina Análise Orientadageeks
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.
26
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
REFERÊNCIAS
CAVALCANTI, ANDERSON. Modelo de Casos de Uso e Diagrama de Casos de
Uso. DEPARTAMENTO DE ENGENHARIA DE COMPUTAÇÃO EAUTOMAÇÃO.
Disponível em: https://www.dca.ufrn.br/~anderson/FTP/dca0120/P2_Aula3.pdf.
Acesso em: 20 mai. 2021.
PEREIRA, ROBERTO. . . Disponível em:Casos de Uso LInterHAD
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. . Disponível em:O que é Requisito Funcional
https://www.ateomomento.com.br/o-que-e-requisito-funcional/. Acesso em: 28 mai.
2021.
VENTURA, Plínio. . Disponível em:O que é um Requisito Não-Funcional
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.
27