Daniel Tan - Project Portfolio

PROJECT: modsUni

1. Overview

modsUni is a desktop candidature management application created by university students for students. It aims to make the tedious process of planning your entire candidature easier and more effective. It provides students with the ability to view module details and manage their personal candidature plans.

Targeted at individuals who prefer the use of their keyboards over a click-and-point interface, it incorporates an in-built Command Line Interface(CLI) for the majority of its user interactions and a simple Graphical User Interface(GUI) for the displaying of output.

This project is initiated by a team of 5. Tasked to morph an existing open-source project consisting of ~10k lines of base code to a completely distinct application.

2. About this Portfolio

This project portfolio details my individual contributions to the modsUni project. It includes a summary of the enhancements and other contributions I made throughout the duration of the project. Additionally, portions of my contribution to the User Guide and Developer Guide have also been included.

3. Summary of Contributions

Major enhancement: Implemented a User Account Management System
- What it does: Allows users to manage user-specific settings and configurations. Using a traditional account management system, users can expect a familiar and intuitive structure when managing their personal details.
- Justification: This feature allows users to set user specific details and configurations for the application.
- Highlights: This is a full-stack feature incorporating all the components of the application from Storage to UI. This enhancement will give users the necessary control over their personal preferences and configurations in the application.
- Relevant pull requests: #44, #87 and #161
Minor enhancement(s): Standardized the User Interface(UI) of the application.
- What it does: Provides an intuitive and familiar user interface to greatly boost User Experience(UX).
- Justification: UX is an important aspect to a product’s sustainability. By incorporating an easy-to-use and familiar tool, users can avoid the need to ascertain new processes and procedures.
- Highlights: Switching between relevant UI panels is automatic(after each successive command).
- Relevant pull requests: #161 and #189
- Code contributed: [Functional code]
Other Contributions:
- Project Management:
  - Assumed responsibility as Team Lead, making critical decisions regarding the project development and overseeing task allocation and deadlines.
  - Managed Project Dashboard on GitHub. Utilized by the team to better manage individual tasks and visualize the various stages of development throughout the project.
  - Set up Labels, Issue Tracker and Milestone in GitHub.
  - Managed all GitHub releases.
- Enhancements to existing features:
  - Overhaul existing UI to better incorporate UX and sustainability principles. (PRs #161 and #189)
  - Refactored base code to better represent the modsUni application. (PRs #161)
- Documentation:
  - Included User Account Management Documentation to User Guide & Developer Guide (PRs #56, #127 and #280)
  - Updated various Component Structures in DeveloperGuide (PRs #201)
- Community:
  - Reviewed PRs(with non-trivial review comments): #119, #124 and #200
  - Reported bugs and suggestions for other teams in the class (examples: 1 and 2)
- Tools:
  - Set up project’s Travis and AppVeyor Continuous Integration(CI) platforms.
  - Set up project’s Codacy Code Analytics and Review service platform.
  - Set up project’s Coveralls Testing and Coverage Statistics platform.

4. 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.

Register a Student Account : `register`

Register a Student Account with the input parameters.
Format: register `user/<USERNAME> pass/<PASSWORD> n/[NAME] `enroll/<ENROLLMENT_DATE> maj/[MAJOR_CODE] maj/[MAJOR_CODE] min/[MINOR_CODE] min/[MINOR_CODE]

The password must at least 8 characters long, containing at least 4 character categories, namely Uppercase characters(A-Z), Lowercase characters(a-z), Digits (0-9) and Special characters (~!@#$%^&*-+=`|\(){}[]:;"'<>,.?/)_

Example:

register user/max33 pass/#Qwerty4321 n/Max Verstappen enroll/15/03/2015 maj/CS maj/DA min/BA min/MA

The figure below displays the UI updates that you should expect to observed after the successful execution of the aforementioned register command.

Notice how the respective fields related to the newly registered user is automatically updated.

Fig 1c. Expected Command Message after running register command.

A temporary save file path is generated and used to save the details of the newly registered user. Do remember the location of the save file. You may choose to save the file in another location by executing the save command as detailed in [save].

Login to the User Account with the corresponding credentials.
Format: login user/<USERNAME> pass/<PASSWORD> userData/[PATH_TO_DATA_FILE]

Example:

login user/max33 pass/#Qwerty4321 userdata/max33.xml

Specified userdata/ option should specify a relative filepath.

Edit Student Account : `edit`

Edits the Student specific information as specified in the input parameters.
Format: edit n/[NAME] enroll/[ENROLLMENT_DATE] maj/[MAJOR_CODE] min/[MINOR_CODE]

Multiple entries of maj/ and min/ is allowed. Additionally, new details will overwrite existing details.

Example:

edit n/Max Emilian Verstappen maj/CS min/
The above command edits the account details of the current current student account, with the new values for Name, major and minor

5. 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.

User Account Management

User Account Management involves mainly the authentication process of the users. User data will only be loaded into the application after a successful login procedure.

Additionally, it is only by registering/logging in will users be able to access and manipulate their account details.
This section will describe in detail the Current Implementation and the Design Considerations of the User Account Management feature.

Figure 1(shown below) describes the general flow of the user account management in an activity diagram.

Figure 1. Activity Diagram for User Account Management.

Current Implementation

The User Account Management mechanism is facilitated by the following classes:

Credential
It stores Username and Password of the User class.
Additionally, it implements the following operation(s):
- Credential#isSameCredential(…) — Determines if there already exists a Credential with the same username in the CredentialStore
CredentialStore
It stores the credentials and the corresponding username in a HashMap object.
Additionally, it implements the following operations(s):
- CredentialStore#addCredential(…) — Adds the input credential into the credential store
- CredentialStore#removeCredential(…) — Removes the input credential from the credential store.
- CredentialStore#isVerifiedCredential(…) — Checks if there exists the same credential with the matching username and passwords. Returns true if the input credential is verified.

The above operations are exposed in the Model interface as Model#addCredential(), Model#removeCredential() and Model#isVerifiedCredential() respectively.

User
Contains all the necessary data contained within a single user.
Currently, there are two Users, each defined by their Roles; namely Student and Admin as defined in the enum class Role.java
- Student
  Refers to the majority of the users. It stores variables pertaining to a student user.
- Admin
  Refers to the application managers. It stores variables pertaining to an administrator.

Figure 2(shown below) is the Class Diagrams illustrating the inheritance between User, Student and Admin

Figure 2. User, Student and Admin Class Diagrams

Each User types contain different class-variables. Additionally, the sets of commands available for either User types are limited to their respective Role

Implementation of the register feature

The register feature is facilitated by the RegisterCommand class. It allows for students to sign up for a modsUni account, which is required to use the application.

Registering only applies to students. For the creation of Admin Accounts, only existing administrators can create another Admin account

The RegisterCommand extends the Command class. Figure 3(shown below) depicts the UML representation of the RegisterCommand.

Figure 3. UML Diagram of RegisterCommand.

Parsing of command is performed by RegisterCommandParser, which returns a RegisterCommand object after processing the user inputs.

Figure 4 illustrates the interactions between the Logic & Model components when the RegisterCommand is being executed.

Figure 4. Sequence Diagram for the interaction between Logic and Model Components when executing RegisterCommand.

Figure 5 below shows the high-level sequence diagram of the command execution.

Figure 5. High-Level Sequence diagram of registering a new student account.

Given below is an example usage scenario and how the register mechanism behaves at each step:

Step 1. The user launches the application for the first time. Only register and login command is available this is because currentUser in Model is not yet instantiated.

currentUser refers to the user account currently loaded in the modsUni Application.

Step 2. The user executes register user/demo … to register a new Student account.

Step 3. RegisterCommandParser would process the user inputs and create a Student, Credential and Path object, which will be used to construct a register command.

Below is a small code snippet of the aforementioned procedure:

public RegisterCommand parse(String userInput) throws ParseException {
        // initial prefix checks, omitted for brevity

        Username username = ParserUtil.parseUsername(argMultimap.getValue(PREFIX_USERNAME).get());
        Password password = ParserUtil.parsePassword(argMultimap.getValue(PREFIX_PASSWORD).get());
        Name name = ParserUtil.parseName(argMultimap.getValue(PREFIX_NAME).get());
        EnrollmentDate enrollmentDate = ParserUtil.parseEnrollmentDate(
            argMultimap.getValue(PREFIX_STUDENT_ENROLLMENT_DATE).get());
        List<String> majors = argMultimap.getAllValues(PREFIX_STUDENT_MAJOR);
        List<String> minors = argMultimap.getAllValues(PREFIX_STUDENT_MINOR);

        User user = new Student(username, name, Role.STUDENT,
            enrollmentDate, majors, minors);
        Credential credential = new Credential(username, password);

        // constructs and returns RegisterCommand, omitted for brevity
    }

Step 4. The register command will next call Model#addCredential(…) and Model#setCurrentUser(…).

Step 5. At this point, Model will insert a new entry in CredentialStore and indicate to Storage to commit the changes to file. Additionally, the event raised by the register command will be handled by UI, making the necessary changes to all UI elements.

A new Student would be initialized and automatically set as the currentUser, enabling the user to perform additional commands automatically.

The login feature is facilitated by the LoginCommand class. It allows for students to log into their existing modsUni account.

The LoginCommand extends the Command class. Parsing of command is performed by LoginCommandParser, which returns a LoginCommand after parsing the username and password inputs.

Given below is an example usage scenario and how the login mechanism behaves at each step:

The user launches the application. As explained earlier, only register and login command are available.
The user can proceed to execute a login command to log in to their account. The login command will call Model#isVerifiedCredential(…) to determine if the user input matches a credential in CredentialStore.
Should the credential be valid and verified, a User will be loaded from a the userdata file provided. Subsequently, the Model#setCurrentUser(…) will be called to set the loaded user data as the currentUser.
Should the credential not be valid or does not match an existing credential in the CredentialStore, the user will simply be shown a failure message.

Design Considerations

Aspect: How user credentials are stored.

Alternative 1 (current choice): Usage of a separate CredentialStore class to store all user credentials.
- Pros: This allows for better security through abstraction. By having the user credentials stored away from the User, they(users & malicious attackers) will not be able to explicitly manipulate the secured data outside the given parameters.
- Cons: Additional memory resources is used to store the data structures.
Alternative 2: Storing the user credentials within the User class.
- Pros: This alternative is easier to implement.
- Cons: Sacrifices security for ease of implementation.

Aspect: Data structure to support the user account features.

Alternative 1 (current choice): A HashMap is used to store the credentials, using a username-credential(String→Credential) key-value pair.
- Pros: Considering that there is no possibility of duplicate usernames, utilizing a HashMap data structure would improve optimization when verifying a specific credential, with an O(1) search time.
- Cons: Additional memory resources is required for the usage of complex data structures.
Alternative 2: Using a List of Credentials
- Pros: Will require less memory resources. Additionally, it is easier to implement.
- Cons: Should more and more user adopt the application, the increased volume of user credentials would result in an O(n) operation when verifying a user credential.