PROJECT: Trajectory

Overview

Trajectory is a lightweight management system for those who need a no-frills solution for managing students, modules, grades, classes and notes. It is built for users who prefer typing (CLI) over GUI interaction and has a GUI created with JavaFX.

Summary of contributions

  • Code contributed: https://nuscs2113-ay1819s1.github.io/dashboard/#=undefined&search=harriuscai

  • Main feature implemented: added the ability to manage modules-related matters in Trajectory

    • What it does: allows the user to create and manage modules in Trajectory. The user is also able to enrol students into the modules to keep track of the students taking the module.

    • Justification: This feature is a key component in any learning management system such as Trajectory because the users need to keep track of their various modules.

    • Highlights: High cohesiveness with the other features in Trajectory because Module is an integral part of any learning management system.

  • Minor enhancement: updated the main parser to allow multi-word commands without breaking existing commands.

  • Minor enhancement: implemented a MVC-like pattern for interaction between classes in the Model and Storage layers for the team to adopt.

  • Other contributions:

    • Documentation:

      • Did cosmetic tweaks to enable 3 levels of depth in the User Guide: #36

      • Rearranged the Gradebook and Class sections of the use cases in the Developer Guide to be consistent with the user stories. #36

      • Updated some project-specific sections in the Developer Guide and User Guide. #36

    • Community:

      • Reviewed the majority of the PRs opened by my team members

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.

Module Management

Add Module : module add

Adds a module to the system.
Format: module add mc/MODULE_CODE mn/MODULE_NAME

  • Module code must be unique.

Examples:

  • module add mc/CG1111 mn/EPP1

  • module add mc/CS2113 mn/Software Engineering

Update module : module edit

Edits an existing module in the system.
Format: module edit mc/MODULE_CODE mn/MODULE_NAME

  • Edits a module with the specified module code. The module code must exist in the system.

  • Existing values will be updated to the input values.

Example:

  • module edit mc/CG1111 mn/Engineering Principles and Practices 1
    Edits the module name to Engineering Principles and Practices 1.

Remove module : module delete

Deletes a module from the system.
Format: module delete mc/MODULE_CODE

  • The module must already exist in the system.

Example:

  • module delete mc/CS2113
    Deletes the module with module code CS2113

View module details: module view

Displays the details of a module in the system.
Format: module view mc/MODULE_CODE

  • The list of students enrolled in the module will also be displayed. This is useful for checking if a student has been enrolled in the module.

Example:

  • module view mc/CS2113
    Displays the details of CS2113 including the list of enrolled students.

Find module : module find

Finds modules whose module code or module name contain any of the given keywords. This is useful for checking if certain module exists in the system.
Format: module find KEYWORD [MORE_KEYWORDS]

  • At least one keyword must be provided.

  • The search is case-insensitive.

  • The search will only match whole words i.e. engin will not return Engineering.

Examples:

  • module find cs2113
    Returns CS2113.

  • module find cs2113 CS2040c
    Returns CS2113 and CS2040C.

List modules : module list

Shows a list of all modules in the system.
Format: module list

Enrol Student : module enrol

Enrols students into the specified module using their matriculation numbers or email addresses.
Format: module enrol mc/MODULE_CODE i/MATRIC_NUMBER…​

  • At least one student matriculation number must be provided.

  • Multiple student matriculation numbers may be provided.

  • The student(s) must already exist in the system.

Examples:

  • module enrol mc/CS2113 i/A0161234B
    Enrols a student with matric no. A0161234B in CS2113.

  • module enrol mc/CS2040C i/A0167263X i/A0179821B
    Enrols two students with matric no. A0167263X and A0179821B in CS2040C.

  • Add module : module add mc/MODULE_CODE mn/MODULE_NAME
    e.g. module add mc/CS2113 mn/Software Engineering

  • Update module : module edit mc/MODULE_CODE​ mn/MODULE_NAME
    e.g. module edit mc/CS2113 mn/Software

  • Remove module : module delete mc/MODULE_CODE​
    e.g. module delete mc/CS2113

  • View module details : module view mc/MODULE_CODE
    e.g. module view mc/CS2113

  • Find module by module code : module find KEYWORD [MORE_KEYWORDS]​
    e.g. module find cs2113 structures

  • List modules : module list​

  • Enrol student in module : module enrol mc/MODULE_CODE i/MATRIC_NUMBER…​
    e.g. module enrol mc/CS2113 i/A0167263X i/A0179821B

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.

[Proposed] Module bidding feature

Proposed Implementation

The module bidding feature is an enhancement that will make it easier to assign students to modules in Trajectory. It is designed with the module enrolment limits in mind, and the aim to give students a certain degree of flexibility in choosing the modules they want. At the moment, it is planned to store the feature in ModuleManager, but it may be abstracted into its own class if it proves to be necessary.

The module bidding feature will implement the following features:

  • ModuleManager#startBiddingRound() — Starts a bidding round for a module.

  • ModuleManager#closeBiddingRound() — Closes the bidding round for a module.

  • ModuleManager#placeBid() — Places a student’s bid on the module they desire.

  • ModuleManager#retractBid() — Retracts a student’s bid from a module for which they previously bid.

  • `ModuleManager#assignSuccessfulStudents() — Assigns the students with successful bids to the module.

These operations will be exposed in the ModuleManager class until there is a need for abstraction.

Given below is an example usage scenario and how the module bidding mechanism will behave at each step.

Step 1. The teacher can start a bidding round for one of his/her modules using the CLI. The command will be routed to ModuleManager#startBiddingRound() with the module code to indicate that bidding has opened for that module. This will also update the status of the module to inform students that they may now start placing bids.

Step 2. A student can place his/her bid for a module with an active bidding round. He/she will need to enter the number of points they wish to use in their bid. The input will be parsed to ModuleManager#placeBid() with the module code and the student’s ID.

Step 3. Should the student decide that he/she is no longer interested in the module, he/she may retract his/her bid by using the CLI and entering the module’s code. This will invoke ModuleManager#retractBid() and the bid will be retracted.

Step 4. When the time is past the intended duration of the bidding round, the bidding round can be closed automatically via a call to ModuleManager#closeBiddingRound(). When the bidding round has closed, the status will be updated to reflect it, and students will no longer be able to place bids for the module.

The teacher may close the bidding round earlier by entering the command in the CLI.

Step 5. After the bidding round has closed, Trajectory will decide which students are successful in their bid by invoking ModuleManager#assignSuccessfulStudents(). This will also assign the successful students to the module and deduct their bid points. The students who were unsuccessful in their bid will have their bid points refunded to their account.

The following activity diagram summarizes the whole module bidding process:

moduleBiddingActivityDiagram

Design Considerations

Aspect: How the module bidding will work

  • Alternative 1 (current choice): Teacher has to manually open a bidding round.

    • Pros: Easy to implement

    • Cons: May result in inconsistencies between the planned start time and the actual start time, thus causing frustration to the students.

  • Alternative 2: Teacher can input the start time for a module’s bidding round

    • Pros: The actual start time will be consistent and reliable, leading to user (student) satisfaction.

    • Cons: More difficult to implement; Handling date objects is tricky because there are many popular date formats.

Use case: View module details

Precondition(s) :

  • The module should already exist in Trajectory.

Guarantees :

  • NIL

MSS :

  1. Teacher wants to see the details of a particular module in the system.

  2. System displays all the information about that module.

    Use case ends.

Extensions :

  • 2a. Teacher enters an invalid command.

    • 2a1. System displays the command’s correct usage.

      Use case resumes at step 1.

Use case: Find module

Precondition(s) :

  • At least one module should exist in Trajectory.

Guarantees :

  • NIL

MSS :

  1. Teacher searches for a module with some module codes as keywords.

  2. System lists all the active modules that match any of the keywords.

    Use case ends.

Extensions :

  • 2a. Teacher enters an invalid command.

    • 2a1. System displays the list of valid commands.

      Use case resumes at step 1.

  • 2b. Teacher enters keywords that do not match any modules.

    • 2b1. System informs the user that no active modules were found.

      Use case resumes at step 1.

Module Management

  1. Adding a module

    1. Prerequisites: The module must not already exist.

    2. Test case: module add mc/NM2212 mn/Visual Design
      Expected: This module will be added into the system.

    3. Test case: module add mc/NNNNNN mn/Visual Design
      Expected: The module code is not valid. You will not be able to add the module.

    4. Test case: module add mc/NM2212 mn/Visual!@@$%#
      Expected: The module name contains special characters that are not allowed. You will not be able to add the module.

  2. Editing a module

    1. Prerequisites: There must be a module with code NM2212.

    2. Test case: module edit mc/NM2212 mn/VD
      Expected: The module name will be changed to VD.

  3. Deleting a module

    1. Prerequisites: There must be a module with code NM2212.

    2. Test case: module delete mc/NM2212
      Expected: The module name will be changed to VD.

    3. Test case: module delete mc/NE1000 mn/Non-existent module
      Expected: The module with code NE1000 cannot be found. You won’t be able to delete it.

  4. Listing modules

    1. Prerequisites: NONE.

    2. Test case: module list
      Expected: The list of modules in the system will be displayed. If there are no modules, the output should be blank.

  5. Finding a module

    1. Prerequisites: There should be a module with the word Design, either in the module code or module name.

    2. Test case: module find design
      Expected: The list of modules with the word Design in the name will be displayed.

  6. Enrolling a student into a module

    1. Prerequisites: There should be a student with matric no. A0168000B, and a module with module code NM2212.

    2. Test case: module enrol mc/NM2212 i/A0168000B
      Expected: The student with matric no. A0168000B will be enrolled in the module. The module details will be displayed.

  7. Viewing a module’s details

    1. Prerequisites: There should be a module with module code NM2212.

    2. Test case: module view mc/NM2212
      Expected: The module details for NM2212 will be displayed, including the list of students enrolled in the module.