Hello, I’m YuGin, a Computer Science undergraduate at the National University of Singapore (NUS).

PROJECT: T.A.rence

Overview

T.A.rence is a module and class management system aimed at teaching assistants (TAs) in universities. It helps TAs manage student- and assignment-related data and tasks, and is optimised for users who are proficient in speed-typing.

Summary of contributions

Major Enhancement: Autocorrect and autocomplete systems

  • What it does: Autocorrect picks out minor mistakes in fields like student names and module codes, and suggests similar valid commands. Autocomplete provides suggestions to complete partial inputs by the user.

  • Justification: As a CLI-focused application, the user will likely do a considerable amount of typing. Especially for longer commands, an autocorrect feature can save the user from having to retype lengthy lines of text. Meanwhile, autocomplete helps the user fill in names, a useful feature if the TA has a large number of students or classes.

Details

  • Autocorrect generates alternative commands when the user’s input does not match data within the application. When there are multiple fields that may have been entered incorrectly (e.g. tutorial names and module codes), T.A.rence attempts to generate different combinations of possible valid values. Fuzzy string matching is used to find data strings that are similar to the user’s input. [PR #60], [PR #62], [PR #67]

  • Autocomplete suggests data values to complete the user’s current partial input, based on the last detected prefix. It also provides command keyword prompts when appropriate. [PR #82], [PR #107]

Credits

Minor Enhancements

Command History

  • Past commands accessible using the "up" and "down" arrow keys, helping users save time when inputting multiple similar commands [PR #98]

Basic CRUD Commands

  • Commands for deleting modules and tutorials [PR #36]

  • Command for adding students [PR #28]

  • Multiple input formats for weeks of semester to enhance usability [PR #52]

Confirmation Prompts

  • Safeguard against unintentional deletion of data by displaying a confirmation dialogue when attempting to delete non-empty modules or tutorial [PR #54]

Scrolling through list display using key inputs

  • Lists of students, tutorials, and modules scrollable using "PageUp" and "PageDown" keys, maintaining CLI-only interaction [PR #187]

Other Contributions

  • Tests to sustain codebase integrity, e.g. [PR #105], [PR #196]

  • Milestone management, e.g. [1], [2], [3], [4]

  • Bug reporting for other teams: [1], [2], [3], [4], [5]

All code contributed: [Commits], [Pull Requests], [RepoSense Dashboard].

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.

Enhancements (Autocorrect, Autocomplete, Command History)

Enhancements

T.A.rence contains a few input correction features to enhance usability.

Autocorrect

If invalid parameters are detected in the command input, T.A.rence tries to suggest similar alternatives that can be selected and run without having to retype the entire command.

E.g. given input

addTutorial tn/Tut01 m/GET1000 …​

T.A.rence might respond:

No such module found. Did you mean: 1. GER1000

Entering the number 1 runs the command addTutorial tn/Tut01 m/GER1000 …​.

Autocomplete

T.A.rence generates and displays real-time suggestions for command words and user data from the application (e.g. module codes and tutorial names), depending on the field the user is currently entering. Similar to other CLI programs such as Windows' Command Prompt and MacOS' Terminal, pressing the "TAB" key will autofill the input box with the current suggestion. Pressing "CTRL" cycles through the different available suggestions.

E.g.: with addTutorial m/GE in the input box, pressing "CTRL" changes the displayed suggestion to R1000, Q1000, etc., depending on which modules beginning with "GE" were previously added to the application. Pressing "TAB" then changes the input box value to addTutorial m/GE_1000.

Command History

Every command entered into T.A.rence is saved. Press the "UP" key to bring up older commands and the "DOWN" key to move back to more recent ones.

Features

Adding a Tutorial Slot : addTutorial

Adds a tutorial slot into the specified module.
Pre-condition: Module must already exist inside application.
Explanation: Adds a tutorial called Tutorial-01 which starts at 1PM, lasts for 60 minutes, and occurs every Monday during weeks 1,2, and 3 into module CS1010.

Format: addTutorial tn/[TUTORIAL_NAME] st/[START_TIME] dur/[TUTORIAL_DURATION] d/[TUTORIAL_DAY] w/[TUTORIAL_WEEKS] m/[MODULE_CODE]

Example:

  • addTutorial tn/Tutorial-01 st/1300 dur/60 d/Mon w/1,2,3 m/CS1010S

START_TIME is in the format hhmm.
TUTORIAL_DURATION is in minutes

Other input options for weeks field:

  • w/even - weeks 4, 6, 8, 10, 12

  • w/odd - weeks 3, 5, 7, 9, 11, 13

  • w/x-y - weeks x to y inclusive, where x and y are integers from 1 to 13 inclusive

Omit w/ field for the default tutorial weeks (3-13 inclusive).

Command synonyms: addtut, addtutorial

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.

System Design - Logic Component

Logic component

LogicRegularCommandClassDiagram
Figure 1. Structure of the Logic Component (for regular commands only)

API : Logic.java

  1. Logic uses the ApplicationParser 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 person).

  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("deleteStudent i/1") API call.

DeleteSequenceDiagram
Figure 2. Interactions Inside the Logic Component for the deleteStudent i/1 Command
The lifeline for DeleteCommandParser should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

Besides these main commands, Logic also handles autocorrect and autocomplete functions in response to user input. These are described in sections 3.1 and 3.2 respectively.

Enhancements - Autocomplete & Autocorrect

Autocomplete feature

Autoomplete provides an autofill feature similar to that found in most common CLIs.

LogicAutocompleteClassDiagram
Figure 3. Structure of the Autocomplete portion of the Logic component

Implementation

Autocomplete is implemented at the Parser level. When the user presses the "TAB" key, AutoCompleteHandler handles the processing of the input, as opposed to ApplicationParser when the "ENTER" key is pressed.

PartialInputParser#parse is responsible for the actual parsing of the input string. It calls ArgumentTokenizer#tokenizeLastArgument to find only the last present prefix and its associated value, then uses the appropriate method in Finder to get a list of all values corresponding to the prefix type in the application that begin with the detected partial input. Should this prefix be one not supported by Autocomplete (e.g. i/ for a purely numerical input), an error message is shown to the user.

AutocompleteHandler#handle is responsible for determining the correct autofilled string. If the user presses "TAB" multiple times successively, it cycles through the available autofill options; otherwise, it gets the list of options from PartialInputParser and returns the first one. The activity flow is summarised below:

AutocompleteActivity

Autocorrect feature

Autocorrect lets T.A.rence find similar commands to the user’s input, allowing it to catch minor typing mistakes.

LogicAutocorrectClassDiagram
Figure 4. Structure of the Autocorrect portion of the Logic component

Implementation

Autocorrect is implemented at the Command level: when Command objects are executed, they attempt to find their data values from the application’s storage. If these values are not found, they search for lexically similar alternatives, and construct new `Command`s with these suggested values. The user is then prompted to choose one of these suggestions via a single numerical input.

A new SelectSuggestionCommand is used to represent the user’s selection. Unlike other commands it has no keyword, and can only be triggered when there are existing suggested commands being temporarily cached. Should the user choose not to pick any of the options, the cached commands are deleted and can no longer be triggered subsequently.

Autocorrect is restricted to input fields that are not strictly numerical, since it makes no sense to correct, for example, index or time inputs.

Below is an activity diagram showing the creation of suggested autocorrect commands when a command is executed.

AutocorrectActivityCreate

The suggested commands are presented to the user, each tagged with an index number. The user is prompted to select one option by entering its corresponding number.

AutocorrectActivityExecute

When a valid option is selected, the execute() method in SelectSuggestionCommand retrieves the specified command, then calls its execute() method. The sequence diagram below illustrates a sample run of the program where `AddStudentCommand`s are being autocorrected.

AutocorrectSequence
The lifelines for SelectSuggestionCommand and AddStudentCommand should end at their destroy markers (X) but due to a limitation of PlantUML, the lifelines reach the end of diagram.

Use Cases

Use case: New tutorial entry

Precondition: User selects the command to add a new tutorial.

MSS

  1. User requests to add a new tutorial to a selected module.

  2. System adds the tutorial to the given module.

  3. System displays the newly added tutorial to the tutorial list.

    Use case ends.

Extensions

  • 1a. The given tutorial already exists.

    • 1a1. System shows an error message showing that the given tutorial already exists.

      Use case ends.

  • 1b. The given module does not exist.

    • 1b1. System searches for similar modules in the application to the given module.

      • 1b1a. System finds one or more similar modules.

        • 1b1a1. System suggests alternative values to user.

        • 1b1a2. User selects one of the options.

          Use case resumes from step 2.

      • 1b1b. System finds no similar modules.

        • 1b1b1. System shows an error message showing that the given module does not exist.

          Use case ends.

  • 1c. The given input is in an invalid format

    • 1c1. System shows an error message showing the correct format to add a module.

      User case ends.

Use case: Deleting tutorials

Precondition: User selects the command to delete a tutorial.

MSS

  1. User requests to a delete a tutorial of a given index.

  2. System deletes the tutorial.

  3. System displays a confirmation message of the deletion.

    Use case ends.

Extensions

  • 1a. The entered index is out of range.

    • 1a1. The system displays an error message and alerts the user that their input is out of range.

      Use case ends.

  • 1b. The entered value for the index is negative, or not a parsable integer.

    • 1b1. System displays an error message along with a prompt on the correct command usage.

      Use case ends.

  • 1c. The tutorial to be deleted contains one or more students.

    • 1c1. System displays a message informing the user that the tutorial is not empty, and prompts for confirmation.

    • 1c2. User confirms the delete action.

      Use case resumes from step 2.

Use case: New student entry

Precondition: User selects the command to add a new student.

MSS

  1. User requests to add a new student into the selected tutorial and module.

  2. System adds the new student into the selected tutorial and module.

  3. System displays the student’s particulars under the student list.

    Use case ends.

Extensions

  • 1a. The given student already exists.

    • 1a1. System shows an error message that the given student already exists within the selected tutorial and module.

      Use case ends.

  • 1b. The given module or tutorial does not exist.

    • 1b1. System searches for similar module-tutorial combinations in the application to the given module and tutorial.

      • 1b1a. System finds one or more similar combinations.

        • 1b1a1. System suggests alternative values to user.

        • 1b1a2. User selects one of the options.

          Use case resumes from step 2.

      • 1b1b. System finds no similar combinations.

        • 1b1b1. System shows an error message showing that the given module or tutorial does not exist.

          Use case ends.

  • 1d. The given input is in an invalid format.

    • 1d1. System shows an error message showing the correct format to add a module.

      User case ends.

Use case: Mark class attendance.

Preconditions:

  1. User selects the command to mark a tutorial class' attendance.

  2. The given tutorial-module combination exists in the system.

MSS

  1. User requests to enter attendance for a student in a particular tutorial and module for particular week.

  2. System records attendance for the student.

  3. System displays confirmation message.

    Use case ends.

Extensions

  • 1a. No student name is supplied.

    • 1a1. System displays a student in the tutorial and prompts user to mark attendance for that student.

    • 1a2. User enters attendance for displayed student.

      Steps 1a1 and 1a2 are repeated for each student in the tutorial.

      Use case ends.

  • 1b. The given input is in an invalid format.

    • 1b1. System shows an error message showing the correct format to add a module.

      User case ends.