Desenvolvimento de Games

Projeto:
PoliFlashes

Nome dos Alunos:

Eduardo Girotto De Oliveira - RA: 25.00738-6
Gabriel Gildin - RA:21.01291-0
Gabriel Lippi da Costa - RA: 25.01686-6
Rafael Palumbo - RA: 25.00888-9
Rodrigo Carneiro Silveira - RA: 25.01316-0
Zion Di Tizio - RA: 25.00352-6

• Descrição/Resumo do Projeto

O PoliFlashes é um game educacional de flashcards interativos voltado para alunos do

Colégio Poliedro. A plataforma busca facilitar a revisão de conteúdos escolares de
forma dinâmica, personalizada e acessível, unindo elementos de gamificação com
autonomia de criação por parte dos estudantes.

Público-alvo: Alunos do Colégio Poliedro.

Escopo do projeto: Plataforma de Flashcards para criação, visualização e teste de

conteúdo.
 • Extração de Requisitos

Métodos utilizados: Entrevistas, questionários e observações.

Entrevista:
Será elaborada com base nas duvidas que permaneceram após o questionário, além
de novas perguntas que surgirem no processo de desenvolvimento

Roteiro:
Perguntas sobre preferência de funcionalidade e de estética do game, de modo a
alinhar as ideias do grupo com a do cliente.

Participantes:
Entrevistados: Clientes (representantes do Colégio Poliedro)

Entrevistadores: Integrantes do grupo

Análise:
Identificação das funcionalidades mais relevantes e das preferências do cliente a partir
dos dados coletados, dando uma noção para a inicialização e direcionamento do
projeto.

2.1. Análise da Coleta de Requisitos

A seguir, estão listados os requisitos levantados durante a reunião com os

responsáveis do Colégio Poliedro, organizados em formato de perguntas e respostas
para facilitar a compreensão das necessidades do projeto.

Funcionalidades Gerais

• O jogo deve possuir música de fundo?

Sim, a presença de música de fundo é permitida, desde que haja uma opção
 clara e acessível para desativá-la a qualquer momento.
• O aluno poderá criar seus próprios flashcards?
Sim. Essa funcionalidade é considerada essencial, sendo um dos principais
objetivos do projeto.
• O jogo deve conter baralhos prontos para uso imediato?
Sim. O sistema deve conter ao menos um baralho por disciplina, para que o
aluno consiga começar a jogar logo após a instalação, mesmo que a maioria dos
flashcards seja criada pelo próprio aluno. Os baralhos prontos servirão
principalmente como exemplo.
• Os flashcards devem ser organizados por categorias?
Sim. Os flashcards devem possuir uma estrutura de categorização. Os cards
criados pelos usuários devem permitir a escolha de categorias personalizadas,
enquanto os implementados previamente devem ser divididos conforme as
matérias escolares.
• Haverá algum tipo de sistema de pontuação ou ranking?
Sim. Haverá um sistema de ranking pessoal, onde o aluno poderá acompanhar
seu próprio desempenho com base em acertos, erros e tempo de resposta. O
sistema não terá caráter competitivo entre alunos.
• Professores poderão criar flashcards?
Sim, essa possibilidade é válida. Porém, o foco principal continuará sendo a
autonomia do aluno na criação dos seus próprios materiais de estudo. A
contribuição dos professores poderá ocorrer como apoio opcional.
• Os flashcards devem suportar apenas texto ou também imagens, sons e
vídeos?
Os flashcards devem, prioritariamente, suportar texto e imagens. Não há
necessidade de incluir sons ou vídeos neste momento.
• O jogo deve ser projetado para uso individual ou em grupo?
Individual. O foco da aplicação é no uso autônomo por parte dos alunos.

Interface e Design

• Qual a combinação de cores planejada para os flashcards?

Deve ser utilizada a paleta de cores institucional do Colégio Poliedro.
• Existe alguma referência visual a ser seguida?
Não há referências específicas, mas a interface deve ser simples, limpa e
 minimalista, para evitar distrações durante o uso.

Plataforma e Acesso

• Quais dispositivos devem ser compatíveis com o jogo?

O sistema deve ser desenvolvido como um site responsivo ou um aplicativo
mobile.
• Será necessário realizar login para utilizar o jogo?
Sim. A autenticação será necessária, podendo ser vinculada a um padrão de e-
mail institucional (ex: *@colegiopoliedro).
• Qual(is) sistema(s) operacional(is) o sistema Flashcards deverá suportar
(Windows, Linux, macOS, Android, iOS, etc.)?
Windows
• Quais informações deverão ser solicitadas ao usuário no momento do
cadastro (ex.: nome completo, e-mail institucional, matrícula, cargo, etc.)?
Nome, e-mail e RA
• Como o sistema deverá identificar e diferenciar usuários com perfil de
aluno e funcionário durante o cadastro e o login?
Aluno - @[Link]
Professor - @[Link]

Outras Considerações

• Os resultados dos alunos devem ser armazenados para análises futuras?

Não. Não há necessidade de armazenar ou exibir estatísticas de desempenho.
• Qual a faixa etária do público-alvo?
Alunos do Ensino Médio, com idades entre 15 e 18 anos.
• Observações adicionais:
Todas as questões relevantes foram consideradas nas respostas acima. Não há
observações extras no momento.
• Quais recursos de acessibilidade deverão ser implementados para garantir
o uso do sistema por usuários com deficiência visual, auditiva ou motora?
Não é necessário esse tipo de implementação.
• Requisitos Funcionais
ID Descrição do Prioridad RNF(s)
Requisito e
RF01 O sistema deverá Alta RNF02,
permitir que o aluno RNF04
crie seus próprios
flashcards.
RF02 O sistema deverá Alta
organizar baralhos por RNF02
disciplina.
RF03 O sistema deverá Média RNF02
categorizar flashcards
como personalizáveis
(usuário) ou por
matéria (baralhos
prontos).
RF04 O sistema deverá Média RNF02
exibir um ranking
pessoal, sem
competição entre
alunos.
RF05 O sistema deverá Baixa RNF02
permitir que
professores também
criem flashcards.
RF06 O sistema deverá Baixa RNF05
reproduzir música de
fundo padrão, com
opção de desativá-la.
RF07 O sistema deverá Alta RNF06,
exigir login via e-mail RNF04
institucional e validar
esse e-mail no
momento do cadastro.
RF08 O sistema deverá ser Alta RNF02,
projetado para uso RNF03
individual por usuário.
RF09 O sistema deverá Média RNF02
organizar flashcards
por categorias
temáticas definidas
pelo administrador.
RF10 O sistema deverá Alta RNF06
registrar o
desempenho do
usuário (acertos, erros,
média de acertos).
RF11 O sistema deverá Alta RNF06
apresentar mensagens
de erro claras em caso
de dados de login
incorretos.
RF12 O sistema deverá Média RNF02
 permitir que o usuário
edite baralhos.
RF13 O sistema deverá Alta RNF02,
permitir que o usuário RNF04
remova baralhos
criados.
RF14 O sistema deverá Alta RNF02
permitir que o aluno
selecione temas
específicos para
revisar.
RF15 O sistema deverá Média RNF04
exibir a porcentagem
de acerto em ao
finalizar a partida.
RF16 O sistema deverá Alta RNF04,
salvar o progresso RNF06
automaticamente a
cada resposta.
RF17 O sistema deverá Média RNF04,
permitir finalizar a RNF02
partida a qualquer
momento.

3.1. Requisitos Não-Funcionais

ID Descrição do Prioridad
Requisito e
RNF01 O sistema deverá Média
seguir a paleta de
cores definida pelo
projeto.
RNF02 O sistema deverá ter Média
uma interface intuitiva,
limpa e minimalista.
RNF03 O sistema deverá Alta
funcionar em qualquer
sistema operacional do
Windows.
RNF04 O tempo de resposta Alta
nas principais ações do
usuário deverá ser
inferior a 2 segundos.
RNF05 O sistema deverá Alta
consumir menos de
1GB de RAM e 5% de
CPU em computadores
 escolares básicos
RNF06 O sistema deverá gerar Média
logs de erro simples e
mensagens claras para
facilitar manutenção e
testes.

• Especificação dos Casos de Uso

• Diagrama de Casos de Uso

4.1 Diagrama de Classes

4.2 Diagrama de Sequência

4.3 Modelo de Banco de Dados

Script do Banco de Dados:

create database flashcards;

use flashcards;
create Table tb_usuarios(
id_usuario int not null auto_increment primary key,
email varchar(45) not null unique,
nome varchar(40) not null unique,
senha varchar(25) not null,
tipo_usuario ENUM('professor', 'coordenador', 'aluno') not null
);

create table tb_grupo_alunos(

id_grupo_alunos int not null auto_increment primary key,
nome varchar(30) not null,
id_usuario int not null,
foreign key (id_usuario) references tb_usuarios(id_usuario) on delete cascade
);

create table tb_associacao_alunos_grupos(

id_grupo_alunos int not null,
id_usuario int not null,
primary key(id_usuario, id_grupo_alunos),
foreign key (id_usuario) references tb_usuarios(id_usuario) on delete cascade,
foreign key (id_grupo_alunos) references tb_grupo_alunos(id_grupo_alunos) on delete cascade
);

create Table tb_baralhos(

id_baralho int not null auto_increment primary key,
nome varchar(45) not null,
tema varchar(45),
id_usuario int not null,
total_de_acertos int,
total_de_erros int,
media_de_acertos float,
foreign key (id_usuario) references tb_usuarios(id_usuario) on delete cascade
);

create Table tb_cards(

id_card int not null auto_increment primary key,
pergunta varchar(255) not null,
resposta varchar(255) not null,
id_baralho int not null,
total_de_acertos int,
total_de_erros int,
media_de_acertos float,
foreign key (id_baralho) references tb_baralhos (id_baralho) on delete cascade
);

create table tb_assossiacao_baralhos_grupos(

id_grupo_alunos int not null,
id_baralho int not null,
primary key(id_baralho, id_grupo_alunos)
);

Diagrama do Banco de Dados:

• Implementação
• Repositório: [Link]

• Tecnologias utilizadas: MySQL, VSCode, NetBeans, AIVEN.

 • Testes
• Testes unitários, de integração e funcionais.
Ao longo do desenvolvimento do projeto, cada funcionalidade implementada foi
devidamente testada em todos seus casos e possíveis exceções, em situações de mau
funcionamento, as adaptações necessárias foram feitas.
• Evidências como prints ou links para os testes.

• Resultados e Considerações
• Prints das telas do sistema.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
• Comparação entre requisitos e entrega final.
Todos os requisitos estabelecidos no início do projeto foram cumpridos.
• Dificuldades enfrentadas e sugestões de melhorias.
Sentimos que a criação de grupos é uma função sem muita utilidade, deveria ser mais
trabalhada para incluir mais funções e possibilidades. A principal dificuldade enfrentada
foi seguir a modelagem do projeto e trabalhar com JTables.

• Registro da Apresentação ao Parceiro

• Data da apresentação.
Conversas dos dias 28/03, 25/04 e 16/05, em que foram apresentadas as ideias e início
do projeto.
• Feedback recebido.
O representante deu ideias de possíveis implementações ao aplicativo, como os grupos
de alunos.
• Ajustes solicitados.
Nenhum ajuste foi explicitamente solicitado.

• Referências
• OPENAI. ChatGPT (modelo GPT-4). São Francisco, 2025. Disponível
em: [Link] Acesso em: 28 maio 2025.

• CENTRO UNIVERSITÁRIO DO INSTITUTO MAUÁ DE

TECNOLOGIA (IMT). Conteúdo da disciplina Modelagem Orientada
a Objetos (POO). São Caetano do Sul: IMT, 2025.
• YOUTUBE. Como colocar botões em uma JTable(POO).
[Link]

• 10. Apêndice I

• Link Questionário 1° Reunião: [Link]

• Link Questionário 2° Reunião: [Link]