a) Contexto do trabalho: PUC MINAS, Curso: Engenharia de Software/Noturno, Disciplina: Laboratório de Programação Modular, Professor: Cleiton Tavares, Alunos: Guilherme H. L. Biagini
b) Desenvolvedores: Guilherme Biagini & Thalles Nascimento Carvalho & XXX
c) Dependências:
Sobre o programa:
XulambGames é uma pequena loja de jogos digitais que está procurando se firmar no mercado. O primeiro passo para isto é uma proposta inovadora em sua maneira simplificada em disponibilizar e vender os jogos. Sua equipe vai desenvolver a primeira versão do sistema de software que automatize o processo da loja. A equipe de produto levantou os requisitos abaixo e seu time de desenvolvimento precisa implementar um sistema que os atenda:
- Os clientes precisam o cadastro de nome, nome de usuário e senha. Eles serão divididos em três tipos: cadastrados, empolgados e fanáticos.
- Os jogos serão divididos em quatro categorias simplificadas: lançamentos, premium, regulares e promoções. Esta categoria afeta o cálculo do preço de venda do jogo, de acordo com a tabela presente no anexo.
- Clientes cadastrados são aqueles que apenas fazem compras ocasionais e eventualmente recebem e-mails comunicando promoções e outras novidades. Os empolgados pagam uma mensalidade de R$10 e com isso obtêm um desconto de 10% em cada compra realizada. Já os fanáticos pagam uma mensalidade mais alta, R$25, mas têm direito a um desconto de 30% em cada compra.
- Uma compra envolve a aquisição de um ou mais jogos. O valor a ser pago pela compra segue uma regra de desconto de acordo com as categorias de jogos comprados. A regra resumida pode ser vista na tabela do anexo.
- Um cliente tem acesso ao seu histórico de compras, podendo filtrar por categoria dos jogos ou data de compra.
- A direção da XulambGames precisa saber o valor mensal vendido, o valor médio das compras e os jogos extremos: o mais vendido e o menos vendido. Tarefas e regras:
- Grupos de até 4 alunos. A composição dos grupos deve constar da planilha compartilhada no ambiente do Canvas. Os grupos devem estar formados até 21 de abril, sem possibilidade de mudança posterior.
- Crie um diagrama de classes para o problema antes de começar a implementação. Uma vez validado, o modelo só pode ser alterado após autorização do analista sênior. Seu diagrama não precisa incluir métodos get/set, assumindo que, quando existirem, serão no padrão “operacaoAtributo”, por exemplo, getPreco() no jogo.
- Implemente o sistema de acordo com seu diagrama e de modo a atender os requisitos descritos, incluindo uma classe “sistema” ou “app”. Esta classe precisa salvar dados de clientes e pedidos ao encerrar sua execução, bem como carregar automaticamente estes dados antes da próxima execução.
- Serão avaliadas tanto a correção do programa e o cumprimento dos requisitos, como o projeto e implementação seguindo as recomendações e técnicas de modularidade e POO.
- Cada projeto precisará implementar pelo menos dois padrões de projetos, a serem debatidos na fase final.
Para compliar:
Caso o usuário digite o comando errado, o programa retorna:
Prazos:
Etapa 1: entrega do diagrama – até 24/04 (0 ponto, mas pré-requisito para a segunda etapa)
Etapa 2: implementação de backlog a definir – até 15/05 (5 pontos)
Etapa 3: implementação do backlog restante – até 15/06 com apresentação em 17/06 (10 pontos)