PROJECT: Trajectory

Overview

Trajectory is a lightweight learning 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

  • Major enhancement: implemented Student and Course Management

    • What it does: allows a faculty member to manage students, and courses within an institution.

    • Justification: Unlike AB4 which has a generalized target audience, the feature I implemented are written for the context of an LMS. Built specifically for the needs of teachers, and by extension — the needs of an educational institution.

    • Highlights: Cohesiveness with other features as they make use of the student/course APIs for their own use.

  • Minor enhancement: added the ability for the user to lock/unlock the system to prevent unauthorized use.

  • Minor enhancement: wrote a custom implementation of the storage-level layer for the team to use.

  • Minor enhancement: built an utility class for the rendering of data into HTML (Bootstrap).

  • Code contributed: Project Code Dashboard

  • Other contributions:

    • Project management:

      • Initial setup of continuous integration platforms (Travis, AppVeyor), coverage platform (Coveralls) and code quality platform (Codacy).

      • Initial setup of GitHub issue tracker.

      • Setup of somewhat-strict code review system, which requires sign-off by Travis, AppVeyor and Codacy and additionally requires another team member to personally perform peer review before code may be merged into the organization repository.

      • Managed milestones for the project, and ensured that required deliverables are ready.

      • Managed releases v1.2 - v1.3.2 (5 releases) on GitHub

    • Enhancements to existing features:

      • revamped existing AB4’s commands to fit the theme of the product (e.g. add to student add)

    • Documentation:

      • Updated project-wide sections for both the UG and the DG.

    • Community:

      • PRs reviewed and approved.

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.

Add a course : course add

Adds a student to the system.
Format: course_add n/COURSE_NAME c/COURSE_CODE f/FACULTY_NAME

  • Course code must be unique. Capped to 10 letters.

  • Course code may contain letters only.

Examples:

  • course add n/Computer Engineering c/CEG f/School of Computing

  • course add n/Computer Science c/CS f/School of Computing

List all courses : course list

Shows a list of all courses in the system.
Format: course list

List all students by course : course liststudents

Shows a list of all students ordered by course.
Format: course liststudents

Edit a course : course edit

Edits an existing course in the system (by course code).
Format: course edit c/COURSE_CODE [f/FACULTY_NAME] [n/COURSE NAME]

  • Edits the course at the specified course code. A course code must be provided to make changes.

  • At least one of the optional fields must be provided

  • Existing values will be updated to the input values

Examples:

  • course edit c/CEG f/FOE Edits the faculty name for CEG to 'FOE'

  • course edit c/CS n/Computer Science Edits the course name for CS to 'Computer Science'

Remove course : course delete

Deletes the specified course from the system
Format: course delete c/COURSE_CODE

  • Course must exist.

Examples:

  • course delete c/CEG Deletes CEG from the course directory, if it exists.

  • Add course : course add c/COURSE_CODE n/COURSE_NAME f/FACULTY_NAME
    e.g. course add c/CEG n/Computer Engineering f/FoE

  • Delete course : course delete c/COURSE_CODE
    e.g. course delete c/CEG

  • Edit course : course edit c/COURSE_CODE [n/COURSE_NAME] [f/FACULTY_NAME]
    e.g. course edit c/CEG n/Comp Eng

  • List all courses : course list

  • List all students ordered by courses : course liststudents

  • Add student : student add n/NAME i/ADMIN_NUMBER c/COURSE_CODE p/MOBILE_NUMBER e/EMAIL a/ADDRESS
    e.g. student add n/Megan Nicole c/CEG e/E0169113@u.nus.edu a/14 Changi South i/A0177897E p/92667921

  • Update student : student edit INDEX [n/NAME] [i/ADMIN_NUMBER] [c/CLASS] [p/MOBILE_NUMBER] [e/EMAIL a/ADDRESS] `
    e.g. `student edit 1 p/99887890 a/14 Simei Avenue 1

  • Finding a student by name : student find STUDENT_NAME
    e.g. student find Megan Nicole

  • List all students : student list

  • Delete student by INDEX : student delete
    e.g. student delete 2

  • Export students [COMING IN V2.0] : student export
    e.g. student export C:\export

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, PARTIALLY IMPLEMENTED] User Authentication feature

Current Implementation

The bare-bones foundation for user authentication already exists in Trajectory, but it’ll be put in production after V1.4. In the meantime, we have elected to use elements from that foundation to serve us in a limited capacity. Trajectory is capable of locking/unlocking access to the system via the unlock and lock commands. When the app starts up, the user must type in a password to be able to use the system. Should he decide to go on a break, he/she need not worry, as the system can be locked just as easily.

This is a sequence diagram of what happens when the user types in the unlock command. Note that you see "Login", as the lock/unlock feature works on top of the user authentication system that already exists in code.

LockUnlockSequenceDiagram

Proposed Implementation

Trajectory will evolve into a full-fledged LMS, and will come equipped with a user authentication system that supports role-based access control for usage by students, faculty members, administrators and guests.

The implementation will be spread across 2 classes: UserController, AuthenticationController.

When the user starts up the program, he’ll be prompted to input in his email address, followed by his password. The credentials are forwarded to AuthenticationController#authenticate(), whose job is to search for matching credentials in either the 'local storage' or a future DBMS.

The inputted password is hashed, and compared to the saved hash of a matching account, if found. If the password is verified to match, the user is considered to have logged in, and his details are loaded into the UserController, which serves as a reference class for other features to access for the details of the logged-in user, which among other thing includes the user ID, the user personal information and assigned role(s). If the password hash doesn’t match, the user will be shown an error message.

At this point, the user may execute commands. When viewing user-specific data, just as individual modules for students, the relevant controller will access UserController#getLoggedInUserId() so that the module controller can appropriately filter out modules that the user has permission to view or access.

This also applies to actions — only faculty members are allowed to create modules, and UserController#getRole() is queried to check whether the user has that role. An error message will be displayed if the user doesn’t have the required role assigned. Users with the 'administrator' role are allowed to create users, and assign roles to them.

The activity diagram right below is a summary of the login process.

UserLoginActivityDiagram

Design Considerations

Aspect: Roles

  • Alternative 1 (current choice): Pre-defined roles with non-changable 'hardcoded' permissions.

    • Pros: Easy to implement.

    • Cons: Limited in expansion. A user with a role cannot do any action belonging to a more powerful role, without being granted the entire set of powers for the higher role.

  • Alternative 2: Role-Based Management System

    • Pros: Allows for fine-grained permissions control. Can apply the need-to-know, and need-to-use principle to assign required permissions. For example, the module owner may want to see the gradebook but prevent TAs from seeing it, although TAs can assign marks.

    • Cons: Harder to implement.

Use case: Unlock system

Precondition(s) :

  • The system must be locked.

Guarantees :

  • NIL

MSS :

  1. Teacher enters password.

  2. System verifies that the password is correct, and displays a message to that effect.

    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 improperly formatted command.

    • 2b1. System displays the proper format for usage of the command.

      Use case resumes at step 1.

  • 2c. Invalid password.

    • 2c1. System shows 'wrong password' message.

      Use case resumes at step 1.

Use case: Lock system

Precondition(s) :

  • NIL

Guarantees :

  • NIL

MSS :

  1. Teacher enters command.

  2. System locks the system, and displays a message to that effect.

    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 improperly formatted command.

    • 2b1. System displays the proper format for usage of the command.

      Use case resumes at step 1.