yyoshda/pi_1_semestre

1. System type and runtime

- This is a Java desktop application built with Maven and a Swing-based UI.

- The project is a monolithic client that runs locally, boots from br.maua.Main, and uses AppConfig for application wiring/configuration.

2. Overall purpose

- The app implements “Jornada Mauá”, a gamified academic platform for classroom activities.

- It supports two main roles: professor and aluno.

- The gameplay/learning model appears to revolve around classes, tasks, questions, answers, submissions, and a board/progression layer.

3. Presentation layer

- All user interaction lives under br.maua.presentation.

- The UI is organized into many Swing screens and modal dialogs such as login, cadastro, professor home, student questions, task creation, grading/correction, class management, and profile views.

- The .form files show these are GUI-builder-backed screens, not a web frontend.

4. Role-based navigation

- TelaLogin, TelaCadastro, and ControladorCredenciais form the entry path and authentication/identity flow.

- After login, the application branches into different navigation paths for professor and aluno.

- TelaNavegacao and the various “home”, “painel”, and “modal” screens indicate the app is organized around screen-to-screen transitions rather than a single-page flow.

5. Core academic/game domain

- The domain package contains the business model:

- People and identity: Usuario, Aluno, Professor

- Organization: Casa, Curso, Ano, Turma, Subturma, Secao

- Game/progression: Tabuleiro, Tarefa, Tentativa

- Assessment: Questao, Resposta, and variants for different question/answer types

- This suggests the platform models both course structure and game mechanics together.

6. Question and response polymorphism

- The codebase distinguishes several task/question types:

- QuestaoAlternativa, QuestaoDissertativa, QuestaoUpload

- RespostaAlternativa, RespostaDissertativa, RespostaUpload

- Alternativa as the choice option entity

- The UI mirrors this split: the task creation and student question screens include dedicated components for each question format.

- This is a key architectural boundary because task handling is type-specific throughout the app.

7. Service layer

- JornadaService and ArquivoService sit between UI and persistence.

- JornadaService likely orchestrates domain operations such as creating tasks, submitting responses, grading, and progress updates.

- ArquivoService handles file-related behavior, which is important because the app supports upload-based tasks and stored student submissions.

8. Persistence layer

- The infrastructure.DAO package contains one DAO per main entity or relationship.

- Examples include AlunoDAO, ProfessorDAO, QuestaoDAO, RespostaDAO, TurmaDAO, TarefaDAO, TentativaDAO, and specialized DAOs for each question/answer subtype.

- ConnectionFactory centralizes database connections, and jornadamauadbmodel.sql provides the database schema/model.

- This is a classic DAO + relational database architecture, with the domain model mapped manually rather than through a heavy ORM layer.

9. File storage and uploads

- The repository includes both data/uploads/... and src/main/resources/... with student and professor files.

- This indicates the application persists uploaded artifacts on the local filesystem, not only in the database.

- The presence of assets/baixados and upload directories suggests two file flows: stored submission files and downloadable/template assets.

10. Corretions and submission lifecycle

- There are explicit screens for student submission and professor review:

- TelaQuestionarioAluno, TelaUploadAluno, TelaTarefaAluno

- TelaCorrecaoTarefa, TelaNotaAluno, TelasNotasProfessor

- This points to a lifecycle where professors create tasks, students respond through different formats, and professors later correct or score submissions.

- Tentativa likely represents repeated attempts or submission instances.

11. Class management and roster operations

- The app includes multiple screens for managing institutional structure:

- creating classes and sections, adding students, viewing students in a class, and class dashboards.

- TurmaSubturmaDAO suggests many-to-many or association logic between class groupings.

- This is the administrative backbone that ties users to tasks and game progression.

12. Board/game mechanics

- Tabuleiro and the dedicated board screen (TelaTabuleiro) imply a game board or progress map is part of the experience.

- Casa is likely a board tile or position concept used to represent advancement.

- Combined with tasks and attempts, the architecture supports a gamified loop: participate → answer → score → advance on board.

13. UI composition and reusable widgets

- Several screens have internal Components packages, such as quest panels and buttons.

- These reusable Swing components are used to render different task/question types and class/action rows consistently.

- That separation keeps the larger screens from owning all rendering logic directly.

14. Repository and build tooling

- The project is built with Maven (pom.xml) and has NetBeans metadata (nbactions.xml).

- target/ contains compiled outputs, confirming a standard Java build pipeline.

- .env.example suggests some configuration values may be externalized, even though the main architecture is still local desktop + DB + filesystem.

15. Key architectural boundaries to diagram

- UI boundary: screens/forms in presentation

- Application logic boundary: service and credential control

- Domain boundary: entities and enums in domain / enums

- Persistence boundary: DAOs + ConnectionFactory

- File boundary: upload/download storage under data/uploads and resources/assets

- The most important data flow is: user action in Swing UI → service/controller logic → DAO/database and file storage → updated screen state.