GroGames

Aplicação web Java para gerenciamento de loja e inventário de jogos.

Sumário

• Apresentação do sistema
• Autores
• Diagramas
• Estrutura do Projeto
• Fluxos e Uso
• Funcionalidades
• Tecnologias
• Testes

Apresentação do sistema

Grogames é uma plataforma responsável por venda de jogos, oferecendo uma variedade de títulos de sucesso. Oferece um imenso catálogo para que o usuário possa desfrutar das mais novas novidades do mundo dos games. A plataforma oferece diversas opções de DLC’s, para serem compradas junto com o jogo e o jogador ter uma experiência completa como um verdadeiro gamer!

Autores

Feito pelos alunos Bruna Quignoli e Pedro Henrique Marcondes do curso de engenharia de software.

Diagramas

Diagrama de classe (recomendado abrir a imagem em outra aba para conseguir dar zoom!)

Descrição: Este diagrama apresenta a arquitetura de classes do sistema em três camadas principais. Na camada de modelo, temos as entidades fundamentais: User (usuário), Game (jogo), Cart (carrinho), Purchase (compra) e suas entidades de ligação (CartItem, PurchaseItem, UserGame). Cada entidade possui seus atributos e comportamentos específicos. Na camada de persistência, os DAOs (GameDAO, UserDAO, CartDAO, PurchaseDAO, UserGameDAO) implementam o padrão Data Access Object, isolando a lógica de acesso ao banco de dados. Na camada de controladora, os controllers (GameController, UserController, CartController, PurchaseController) orquestram as ações e coordenam o fluxo entre a interface (JSPs) e a lógica de negócio. Observe as multiplicidades (1, *, 0..1) que definem os relacionamentos: um User pode ter múltiplos Cart e Purchase, um Cart contém múltiplos CartItem, cada um referenciando um Game, e assim por diante. Este diagrama é essencial para entender o modelo de dados e como as diferentes camadas se relacionam.

Diagrama de classe decorator

Descrição: Este diagrama ilustra a implementação do padrão Decorator (Decorador), um padrão estrutural que permite estender a funcionalidade de um objeto de forma dinâmica, sem alterar sua classe original. Em cima, tem uma interface ou classe abstrata Component que define o contrato comum. O ConcreteComponent (onde, Game ou uma variante de jogo) é o objeto base que será decorado. A classe abstrata Decorator implementa a mesma interface do Component e mantém uma referência a um objeto Component, permitindo o "encadeamento" de decorators. Os decorators (como DLCDecorator, DiscountDecorator, etc.) estendem Decorator e adicionam comportamentos ou responsabilidades extras — por exemplo, aumentar o preço com DLCs adicionais, aplicar descontos, adicionar informações promocionais ou modificar a exibição do jogo na loja sem tocar na classe Game. A grande vantagem é que múltiplos decorators podem ser empilhados: um mesmo Game pode ter DLC + Desconto + Badge Promocional aplicados em sequência. Este padrão é especialmente útil para o GroGames, onde a mesma entidade de jogo pode ter diferentes combinações de extras e ofertas.

Diagrama de sequência

Descrição: Este diagrama descreve a ordem cronológica das interações entre componentes do sistema em um cenário específico (típicamente um caso de uso crítico, como o checkout de uma compra). O diagrama mostra "lifelines" verticais para cada ator ou objeto participante (Usuário, JSP/View, Controller, DAO, Banco de Dados, etc.) e setas numeradas que representam mensagens (chamadas de método, requisições, respostas). A leitura é de cima para baixo. Um exemplo típico no GroGames:
(1) o usuário clica em "Finalizar compra" na página JSP;
(2) a view dispara um evento para CheckoutPurchaseAction;
(3) a ação valida dados e chama PurchaseController;
(4) o controller chama PurchaseDAO para persistir a compra no banco;
(5) o DAO executa a query SQL via ConnectionSql;
(6) o banco retorna confirmação;
(7) a DAO atualiza também a entidade UserGame (biblioteca do usuário);
(8) o resultado é propagado de volta até a view, que exibe mensagem de sucesso.

Este diagrama é fundamental para identificar pontos críticos (transações, validações), possíveis falhas (timeout, erro de conexão) e onde adicionar logs ou tratamento de exceções.

Estrutura do Projeto

• src/java/ — código-fonte Java
  • command/ — implementações de ações (ex.: AddGameAction.java, CheckoutPurchaseAction.java)
  • controller/ — controllers (ex.: GameController.java, UserController.java)
  • dao/ — acesso a dados (ex.: GameDAO.java, UserDAO.java)
  • model/ — modelos/entidades (ex.: Game.java, User.java)
  • utils/ConnectionSql.java — utilitário de conexão com o banco (src/java/utils/ConnectionSql.java)
• web/ — arquivos web (JSPs, assets, CSS)
  • Páginas principais: web/index.jsp, web/loja.jsp, web/inventario.jsp
  • Páginas de Admin: web/cadastrojogo.jsp, web/lojadmin.jsp
  • Assets e CSS: web/assets/css/style.css, web/script/script.js

Fluxos e Uso

• Pesquisar jogos: uso da interface em web/loja.jsp (os filtros são implementados por GetByNameGameAction, GetByGenreGameAction, etc.).
• Adicionar ao carrinho: ações em command/AddGameCartAction.java.
• Finalizar compra: PreparePurchaseAction.java → CheckoutPurchaseAction.java.
• Ver histórico: GetHistoryPurchaseAction.java exibe compras do usuário.

Funcionalidades

• Autenticação: registro, login e logout.
• Catálogo: pesquisa por nome, gênero, faixa etária e preço.
• Carrinho: adicionar, remover e listar itens.
• Compras: preparar compra, finalizar compra e histórico de pedidos.
• Administração: CRUD de jogos via interface administrativa próprio.

Tecnologias

• Java (Servlets / JSP)
• Banco de dados: MySQL (configurar conforme web/META-INF/context.xml)
• Front-end: JSP, CSS e JavaScript (pastas em web/assets/)
• Design Patters: Builder, Command, Factory, Decorate em implementação.

Testes

 a serem implementados.