PROJECT: NUS Module Planner

Overview

The NUS Module Planner (NUSModPlnr) is for Computer Science (CS) students at the National University of Singapore (NUS) to manage their enrollments in NUS modules over their school life. With NUSModPlnr, module planning has never been easier!

The user interacts with it using a CLI, and it has a GUI created with JavaFX. It is written in Java, and has about 250+ kLoC.

My main contributions are the implementation of the Graduation Requirements interpretation and checking, as well as, managing the Issue Tracker and Releases.

Summary of Contributions

  • Major Feature: Co-Developed Graduation Requirements implementations with associated commands.

    • What it does: This feature allows students to ensure their Graduation Requirements are correct as of the NUS Website, or in this case, for the requirements of NUS Computing’s Computer Science and Information Systems Majors for Undergraduate Students.

    • Justification: This is a core feature, as the ability to ensure that modules are added and fulfil the criteria of a student’s graduation requirements is monumental to their module planning.

    • Highlights: This feature is the core feature of the entire application, which is to allow students to better plan their modules better across semesters. This feature will also greatly affect existing commands and commands to be added in future.

    • Credits: This feature was co-developed with @Capeguy.

  • Major Feature: Implemented Major and Major Set Command, for Users who wish to change their Student’s Major retroactively.

    • What it does: This feature allows students to change their Major, with Computer Science (CS) and Information Systems (IS) Majors currently supported.

    • Justification: This feature allows students to ensure that their Graduation Requirements match the Major that they are taking for their course.

    • Highlights: This feature was interesting to implement because of how the different majors were listed on the NUS Website (particularly for NUS Computing).

  • Major Feature: Co-Developed the foundational code for Planner and associated classes for all other advanced features to be built upon.

    • What it does: allows the other developers to work around a baseline formed around the framework provided by AddressBook-Level3.

    • Justification: This initial refactoring of AddressBook to Planner is important and needs to be done synchronously and before other portions of code can be developed as this forms the basis of which other features rely on.

    • Highlights: This feature blocks the entire application development and needed to be completed fast so as not to impede progress of other team members. As this was a lot to do at once, I have had the help of @Capeguy and @gruntultra in order to push this foundational code out.

    • Credits: The original code from AddressBook-Level3, @Capeguy and @gruntultra.

  • Major Enhancement: Worked with @Capeguy to ensure all Module entities loaded from all JSON files contained the right information to be used in the application.

    • What it does: Ensures that the Module entities are properly populated with the right data from the JSON files created and retrieved from NUSMods.

    • Justification: This aspect was important as aside from allowing the application to work offline, the data needed to be properly parsed in order to be able to populate the Module entities in the application.

    • Highlights: This was an interesting enhancement to complete because of the complexity in the amount of data that can be retrieved from the NUSMods API via JSON.

    • Credits: This feature was co-developed with @Capeguy.

  • Minor Enhancement: Added and modified a significant amount of the Test Cases and Unit Tests for the NUS Module Planner.

  • Minor Enhancement: Created helper classes to facilitate easier testing of models such as TypicalModule and ModuleBuilder

  • Code Contributed: Please see the RepoSense Report here!

  • Other Contributions

    • Project Management

      • Managed Milestones, Project Boards and Issue Tracker for all v1.0 - v1.4 (5 Versions) on GitHub.

      • Managed releases for v1.3 and v1.4 (2 Releases) on GitHub.

    • Enhancements to Existing Features:

      • Refactoring of AddressBook-Level3 to accommodate application use case

      • Wrote additional tests for existing features to increase coverage from 88% to 92% (#1, #2)

    • Documentation:

      • Generated diagrams to enhance readability of Developer Guide

      • Contributed to Features and Module Management sections of User Guide

    • Community:

      • PRs reviewed: Approved & Reviewed PRs.

      • Reported bugs and suggestions for other teams in the class: CS2103T Forum and CS2103T PED.

      • Worked with @Capeguy and @gruntultra to perform initial codebase refactoring to allow for the easier building of features into the application (#1, #2, #3, #4).

      • Worked with @Capeguy on GraduationRequirements which the core functionality of the application, modelling complex real life graduation requirements and implemented different types of GraduationRequirements, each with their own fulfilment logic (#1, #2, #3, #4, #5, #6).

      • Implemented MajorCommand, MajorStatusCommand and MajorSetCommand to allow a Student to have his/her Major set, followed by a listing of graduation requirements and their fulfilments (#1, #2).

      • Implemented both ComputerScienceProgramme and InformationSystemsProgramme which contains 13 specialisations, each with a different list of primary and elective modules (#1, #2).

      • Written JavaDocs and Test Cases for relevant classes (#1, #2).

      • Fixed CheckStyle issues caused by refactoring (#1, #2, #3, #4).

      • Fixed bugs discovered by PE Dry Run (#1, #2, #3, #4, #5, #6, #7, #8, #9).

    • Tools:

      • Integrated continuous integration to the project (#1).

Contributions to the User Guide

Given below are sections I contributed to the User Guide. They showcase my ability to write documentation targeting end-users.

How To Use This User Guide

(Danish wrote this section on "How To Use This User Guide" below.)

NUSModPlnr is a timetable and enrollment management application, which help you add plans which consist of your degree programme and timetables for different semesters.

This User Guide is designed to bring you through the following features:

  1. Viewing Help

  2. Creating a New Student

  3. Declaring a Specialisations and Focus Areas

  4. Viewing and Adding Modules

  5. Viewing, Adding and Selecting Timetables

  6. Managing and Viewing Grades

  7. Viewing your Graduation Requirements

  8. Exiting the Application

Please note the following which may serve as points of interests throughout this User Guide:

  1. keyword : This grey highlight indicates commands that you can type with more info in Features.

  2. Enter : This grey highlight with white outline indicates a keyboard’s key to use.

  3. underlined : This underline indicates clickable links referring to other sections of this User Guide. When used in conjunction with a grey highlight (e.g. student active), this indicates a clickable reference to another command.

  4. bold : This bold font indicates sections of this User Guide.

This symbol and corresponding box has information that you may wish to take note of.
This symbol and corresponding box has tips from the team, which we think might be useful for you.
This symbol and corresponding box has warnings on possibly destructive commands or actions that cannot be undone.

Quick Start

(Danish adapted this section on "Quick Start" below.)

If you are looking to jump right into the application, you can follow the below quick steps to get the application up and running:

  1. Ensure you have Java 11 or above installed in your Computer.

  2. Download the latest nusmodplnr.jar here.

  3. Copy the file to the folder you want to use as the home folder for your NUS Module Planner.

  4. Double-click the file to start the app. The GUI should appear in a few seconds.

  5. Type the command in the command box and press Enter to execute it.
    e.g. typing help and pressing Enter will open the help window.

  6. Refer to Section 3, “Features” for details of each command.

These steps are recommended only if you have experience in setting up the application for first time use, or already have a saved file you would like to continue working with.

Degree Management

(Danish wrote this section on "Degree Management" below.)

The following commands below are part of the application’s Degree Management, which allow you to declare important details of your academic plan, such as your majors and specialisations.

All the following commands require a student to be selected (using the student active command).

Declaring your major: major set

You can use this command to declare the major of your studies, which is also required for the module planning.

Format: major set MAJOR

Examples:

  • major set CS

Declaring your specialisation: specialisation set

You can use this command to declare any specialisations in your studies, should you require them in module planning.

Format: specalisation set [SPEC]

Examples:

  • specialisation set algo

Viewing your degree progression: major status

You can use this command view your degree progression.

Format: major status

Examples:

  • major status

Contributions to the Developer Guide

Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project.

Architecture

ArchitectureDiagram
Figure 1. Architecture Diagram

The Architecture Diagram given above explains the high-level design of the App. Given below is a quick overview of each component.

The .puml files used to create diagrams in this document can be found in the diagrams folder. Refer to the Using PlantUML guide to learn how to create and edit diagrams.

Main has two classes called Main and MainApp. It is responsible for,

  • At app launch: Initializes the components in the correct sequence, and connects them up with each other.

  • At shut down: Shuts down the components and invokes cleanup method where necessary.

Commons represents a collection of classes used by multiple other components. The following class plays an important role at the architecture level:

  • LogsCenter : Used by many classes to write log messages to the App’s log file.

The rest of the App consists of four components.

  • UI: The UI of the App.

  • Logic: The command executor.

  • Model: Holds the data of the App in-memory.

  • Storage: Reads data from, and writes data to, the hard disk.

Each of the four components

  • Defines its API in an interface with the same name as the Component.

  • Exposes its functionality using a {Component Name}Manager class.

For example, the Logic component (see the class diagram given below) defines it’s API in the Logic.java interface and exposes its functionality using the LogicManager.java class.

LogicClassDiagram
Figure 2. Class Diagram of the Logic Component

How the architecture components interact with each other

The Sequence Diagram below shows how the components interact with each other for the scenario where the user issues the command student remove 1.

ArchitectureSequenceDiagram
Figure 3. Component interactions for student remove 1 command

The sections below give more details of each component.

Logic Component

LogicClassDiagram
Figure 4. Structure of the Logic Component

API : Logic.java

  1. Logic uses the PlannerParser class to parse the user command.

  2. This results in a Command object which is executed by the LogicManager.

  3. The command execution can affect the Model (e.g. adding a Student).

  4. The result of the command execution is encapsulated as a CommandResult object which is passed back to the Ui.

  5. In addition, the CommandResult object can also instruct the Ui to perform certain actions, such as displaying help to the user.

Given below is the Sequence Diagram for interactions within the Logic component for the execute("student remove 1") API call.

DeleteSequenceDiagram
Figure 5. Interactions Inside the Logic Component for the student remove 1 Command
The lifeline for StudentRemoveCommandParser should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

Graduation Requirements Features

The Graduation Requirements feature is what allows students to ensure that their academic plan and corresponding modules are assisting them towards fulfilling their own criteria to graduate.

Degree Management

The Graduation Requirements are made up of 2 implemented components:

  • Declaration of Major: major set

  • Declaration of Specialisation: specialisation set

The Major and Specialisation entities are automatically created and populated through the JSON data received from NUSMods. Furthermore, Student entities can only be associated in a 1-0..1 relationship with a Specialisation entity.

The following high-level sequence diagrams illustrates the interactions between the Ui, Logic & Model components when either a Major or Specialisation is being set:

sequenceDiagramMajorSetLogicModelStorage
Figure 6. Sequence Diagram for Major being set, with respect to MainWindow from Ui, Logic & Model
sequenceDiagramMajorSet
Figure 7. Sequence Diagram for Major being set with respect to the MajorSetCommand
sequenceDiagramSpecialisationSet
Figure 8. Sequence Diagram for Specialisation being set (e.g. AlgorithmsAndTheorySpecialisation) with regards to SpecialisationSetCommand

Verification of Graduation Requirement Fulfilment

Once the Major and Specialisation (if any), or a Student is set, the following logic is used to verify if the Student 's GraduationRequirements are being met, based on the list of Module which which the Student has enrolled in:

  1. Retrieval of the main base of the GraduationRequirement based on the Major and ultimately DegreeProgram of the Student.

  2. Retrieval of the list of Module which the Student has enrolled in.

  3. Passing in of the list of enrolled Module into each GraduationRequirement and determining if the GraduationRequirement has been met.

    1. The modelling of the actual Graduation Requirements of NUS CS and IS undergraduate students are accomplished by making use of the various implementations of GraduationRequirement such as

      1. CompoundGraduationRequirement for groups of Module s which a Student is allowed to choose from, with certain conditions for fulfilment such as:

        1. Minimum number of Modules

        2. Minimum number of Module Credits

        3. Minimum number of Modules that must be 4000-level or above

      2. SpecialisationGraduationRequirement for "Specialisations" or "Tracks" depending on the terminology of the respective faculty that the Major belongs to).

      3. WildcardGraduationRequirement for Requirements that need to be fulfilled from a fixed pool of Module s which have ModuleCode s starting with certain characters (e.g. GEH, GES, GET)

  4. Thereafter, the corresponding Module entities that have been added will be verified against the compiled Graduation Requirements.

  5. Finally, requirements that are met, are checked or crossed accordingly - which is displayed in the left-panel of the GUI.

The flow of how the Graduation Requirements is put together with information from Major and Specialisation can be found in the below class diagram:

GraduationRequirementsCD expanded
Figure 9. Extended Class Diagram of Graduation Requirements Implementation

Design Considerations

  • Alternative 1 (Current Implementation): Model real life graduation requirements in an OOP-manner with a different class for different types of requirements containing different logic determining the fulfilment of the graduation requirement, each inheriting from a base class to allow for polymorphism.

    • Pros: Well Structured and separates actual requirements from the model by creating classes that provide the logic needed for fulfilment calculation.

    • Cons: Each Programme will have to construct it’s own combination of the various implementations GraduationRequirement to model actual graduation requirements.

  • Alternative 2: Implement each DegreeProgram 's graduation requirement as a class on it’s own.

    • Pros: Each DegreeProgram can have the flexibility of customising fulfilment logic.

    • Cons: Duplicate codes due to many classes may have the same fulfilment logic, but different data.

Logging

We are using java.util.logging package for logging. The LogsCenter class is used to manage the logging levels and logging destinations.

  • The logging level can be controlled using the logLevel setting in the configuration file (See [Backend-Configuration])

  • The Logger for a class can be obtained using LogsCenter.getLogger(Class) which will log messages according to the specified logging level

  • Currently log messages are output through: Console and to a .log file.

Logging Levels

  • SEVERE : Critical problem detected which may possibly cause the termination of the application

  • WARNING : Can continue, but with caution

  • INFO : Information showing the noteworthy actions by the App

  • FINE : Details that is not usually noteworthy but may be useful in debugging e.g. print the actual list instead of just its size

User Stories

Priorities: High (must have) - * * *, Medium (nice to have) - * *, Low (unlikely to have) - *

Priority As a …​ I want to …​ So that I …​

* * *

freshman

declare what my major is

get the right graduation requirements to follow

* * *

freshman

declare what I am exempted from (e.g. Polytechnic Exemptions)

am not recommended modules that I am exempted from

* * *

freshman

declare what tracks/specializations (Focus Areas) I am interested/am taking

am given recommendations that will fulfill the requirements of that track/specialization

* * *

current undergraduate student

view the list of modules which I have taken

can remember what modules I have taken

* * *

current undergraduate student

view the list of modules which I have declared exempted from

can remember what modules I am exempted from

* * *

freshman

see a list of all available modules in NUS

can see what modules is available for me to take

* * *

current undergraduate student

enter the grades I got for each module

can view my Cumulative Average Point (CAP) for each and all semesters

* * *

current undergraduate student

can see if a module is being offered in a semester that I want

can plan my academic plan correctly

* * *

current undergraduate student

see the list of grades I obtained for each module

can have a better understanding of my academic performance

* *

current undergraduate student in-residence

declare that I am part of a Residential College program

am given recommendations that take into account UTCP modules

* *

current undergraduate student

declare my intention of overloading modules

am given recommendations to graduate faster

* *

current undergraduate student

declare my intention of underloading modules

am given recommendations to graduate faster

* *

freshman

verify if I can graduate on time given currently selected modules

am given recommendations of feasible modules to take

* *

current undergraduate student

check which lecturer is teaching the module

can decide if I should take that module in that semester

* *

current undergraduate student with NOC acceptance

declare that I am part of NOC programme

can count NOC modules towards my graduation requirements

* *

current undergraduate student with USP acceptance

declare that I am part of the university scholar programme

can replace my requirements for graduation with USP modules

* *

current undergraduate student

can check the venue of the class

can plan my traveling route during module planning

* *

current undergraduate student

change the colours of the module planner for customizable

can enjoy dark theme

* *

current undergraduate student on internship

declare when I would like to undergo an internship

can plan the timing of my modules

* *

current undergraduate student

view changes in Grade Point Average (GPA) according to projected grades

can have a better understanding of my academic performance

* *

freshman

automatically select non-conflicting lecture and tutorial slots based on preferences

can create usable timetables based on my preferences

*

current undergraduate student on exchange

set the module to be non graded to pass or fail

can set the overseas module to be pass or fail without affecting my CAP

*

freshman

declare what my minor(s) is/are

get the right graduation requirements to follow

*

current undergraduate student

see which pathways would be more challenging (i.e. Level 3K, 4K, 5K modules)

can choose a better course pathway in terms of maximising GPA/fulfilling course requirements

*

freshman

set preferences (e.g. ‘free’ days/only after 12 PM) in order to automatically organise the timetable

have an efficient and personalised timetable

== PROJECT: Granado-Espada-For-SEA

---

Worked on the Korean to English (SEA) locationisation of the MMORPG, Granado Espada.

A link to the repo can be found here!