Aakanksha Rai - Project Portfolio

PROJECT: TA-Tracker

Overview

TA-Tracker is a productivity tool made for NUS Computing Teaching Assistants (TAs) who want to be able to track and manage all of their claimable hours and the students they are teaching in one place. The application is written in Java and spans 20k Lines of Code.

Summary of contributions

Student View refers to the view that allows the user to manage their students. As the main developer that created Student View, my main contributions were in the Student View. They include creating models, writing commands, creating tests and adding documentation for the Student View. In total, I wrote almost 7kLoc.

Create the Models

I created the Module, UniqueModuleList, Group and UniqueGroupList models that were used in Student View from scratch. These models are necessary to ensure the proper functioning of the commands in the Student View. (#88)

I created a lot of supporting methods for the UI, especially the highlighting feature which highlights the currently shown module and group. (#202)

I also added the required support for the filter feature in the models which allows the user to filter the students they’re viewing by module code and group code. (#191).

Sort Commands

What it does: Allows the user to sort the students by rating (in ascending or descending order), by matriculation number or alphabetically. There are three variations of the sort - sort all which is used to sort all students in all groups of all modules, sort module which is used to sort all students in all groups of a particular module and sort group which is used to sort all students in a particular group of a particular module.
Justification: This feature improves the product as TA’s are often required to sort their students in different ways. For example, alphabetically when taking attendance, by matriculation number when grading assessments or by rating when keeping track of strong or weak students.
This feature was difficult to implement as it had several sub-parts. Furthermore, it had initially been implemented in a different way (#195, #200) but later had to be changed in order for it to be compatible with the interactive parser (#205).

Other Commands

The other commands I implemented are:

module add (#102)
module delete (#107)
module edit (#206)
group add (#121)
group delete (#122)
group edit (#196)
- These commands are needed to manipulate data in the Student View.
- Overall, these commands required a fair amount of work, especially due to the possible edge cases they have such as the user changing the group code to that of a pre-existing group.

Testing

I created all the classes required to test the Student View such as GroupBuilder, ModuleBuilder, TypicalGroups, TypicalModules, etc. I also wrote the tests for all my enhancements and have an average coverage over 85% for my sections in the codebase. (#232, #345)

The code I contributed can be found here.

Other contributions:

Managed release v1.4 on GitHub
Refactored the codebase to make it match TA-Tracker (#142)
Documentation:
- Created a User Guide skeleton for everyone to follow and made a few cosmetic tweaks to existing contents (such as adding a table for the common parameters and the glossary) (#215)
- Updated the User Guide and Developer Guide with details for the Student View and the commands used in the Student View.
- Added screenshots of the UI with annotations to the User Guide for all commands (#371)
Community:
- I reviewed PRs to help maintain code and documentation quality. Some examples are: #187, #208, #179, #364,
- I also contributed to forum discussions. Some examples are: 1, 2

Contributions to the User Guide

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

Adding a Module : `module add`

(Contributed by Aakanksha)

You can use this command to add a new module to the TA-Tracker.

When a new module is created, the Student View will show the groups and students of the new module.

You may notice that the group list and the student list are empty. This is because you haven’t added any groups or students to the module yet.

If you were on a different tab, you will automatically be switched to the student tab.

Format: module add m/MOD_CODE n/NAME

You can’t have two modules with the same module code in the TA-Tracker.
MOD_CODE and MOD_NAME can’t be a empty or a sequence of spaces.
You can give a module your own custom MOD_CODE or NAME if you find it easier to remember. However, we recommend you use the official module code and name for it.
If the module name or module code are very long, you can increase the width of the module name list by dragging the edge with your cursor. However, we suggest not giving the modules long codes or long names. The standard official names are usually of a good length.

You can’t edit the MOD_CODE once the module has been created, so do take care to ensure that the code is correct.

Examples:

module add m/CS2100 n/Computer Organisation

This will add a module with the module code CS2100 and name Computer Organisation to the TA-Tracker.

Editing a Group : `group edit`

(Contributed by Aakanksha)

You can use this command to edit a group in the TA-Tracker.

This command can be used to change the group code and the group type of the group. The students inside the group will remain intact.

When a group is edited, the Student View will show the groups in the module that the edited group belongs to, as well as the students that belong to the edited group. If you were on a different tab, you will automatically be switched to the student tab.

Format: group edit g/GROUP_CODE m/MOD_CODE [ng/NEW_GROUP_CODE] [nt/NEW_GROUP_TYPE]

MOD_CODE here refers to the module code of the module that contains the group that you want to edit.
You can’t edit a group inside a module that doesn’t exist.
You can’t edit a group that doesn’t exist.
If you are changing the group code, the module shouldn’t contain a group that has the same group code as the new group code.
While the nt/ and ng/ prefixes are optional, at least one of them must be mentioned.

Examples:

group edit g/G01 m/CS3243 nt/lab

This will change the group type of the group with group code G01, inside the module with module code CS3243, to be a lab.

Sorting a Group : `sort group`

(Contributed by Aakanksha)

You can use this command to sort your students in a specific group. The students will be sorted according to the SORT_TYPE you specify.

The Student View will show you the students inside the group that you have sorted. If you were on a different tab, you will automatically be switched to the student tab.

Format: sort group g/GROUP_CODE m/MOD_CODE t/SORT_TYPE

You can’t sort a group inside a module that doesn’t exist.
You can’t sort a group that doesn’t exist.
To sort alphabetically you can use the following to indicate sort type:
- alphabetically
- alphabetical
- alpha
To sort by matriculation number, SORT_TYPE must be matric.
To sort by rating in ascending order, SORT_TYPE must be rating asc.
To sort by rating in descending order, SORT_TYPE must be rating desc.

Examples:

sort group m/CS2100 g/G06 t/rating asc

Sorts the student inside G06 of module CS2100 by rating in ascending order.

Contributions to the Developer Guide

Given below are some of the 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.

Implementation of the Model Framework

(Contributed by Aakanksha)

The following Class Diagram shows how different classes are related in the functioning of the Student View.

Figure 1. Student View - Class Diagram

In the diagram above, you can see that:

The TaTracker class contains a UniqueModuleList which helps it keep track of the different modules the user is teaching.
Each Module contains a UniqueGroupList.
Each UniqueGroupList contains a list of all the groups of a module that the user is teaching.
Each Group contains a UniqueStudentsList that contains the students in that group.

Design Considerations

The initial idea for the Student View UI was to show the Student View as a list of modules where each module contained a list of groups and each group contained a list of students. Keeping this in mind, we created the current model framework.

The idea for the UI was scrapped as once we realised it would look messy and won’t be user-friendly. We changed the UI to what it is now, but decided to keep the model framework the way it is.

Alternative Implementation

An alternative implementation would be to have a single UniqueModuleList to store all modules, a List to store all groups and a List to store all students.
We would then have to filter by module code and/or group code to show the appropriate groups and students.
This would require students to keep track of which group and which module they’re a part of. Similarly, groups would have to keep a track of the students they contain. This would create a cyclic dependency (which could be solved using an association class).
The List of groups could contain multiple groups with the same group code as group code is only unique within a module. Group codes can be shared across modules.
While this implementation would make it easier to generate a report at the end of the semester (explained later in the guide), it would require more commands and the creation of many association classes which would unnecessarily complicate the model. That is why we decided to stick to our current implementation.

Implementation of the Sort Group, Module and All Command

(Contributed by Aakanksha)

The sort command allows the user to sort the students in the Student View.

The sort command can be used in three ways:

sort group g/GROUP_CODE m/MODULE_CODE t/TYPE : This sorts all the students of the given group in the given module by type TYPE.
sort module g/MODULE_CODE t/TYPE : This sorts all the students of all the groups in the given module by type TYPE.
sort all t/TYPE : This sorts all students of all groups in all modules in the TA-Tracker by the type TYPE

TYPE here could mean any of the following:
- alpha, alphabetical or alphabetically to sort alphabetically.
- rating asc to sort by rating in ascending order.
- rating desc to sort by rating in descending order.
- matric to sort by matriculation number.

Since the Sort commands function differently but use a single parser, the structure shown in the following Class Diagram is used.

Figure 2. Sort Commands - Class Diagram

SortGroupCommand sorts the students in a particular group of a particular module.
SortModuleCommand sorts the students in all groups of all modules.
SortCommand sorts the students in all groups of all modules.

Since the different commands use the same parser, the SortCommandParser needs to check the sub-command word and return the appropriate sort command.

The following Activity Diagram shows the steps the SortCommandParser takes once its parse method is called (assuming that no exception is thrown).

Figure 3. SortCommandParser - Activity Diagram

The sub-command word here refers to all, module or group. If none of the above sub-command words is used, a command exception will be thrown, explaining that it is an invalid command.
If the user enters the sort command with a command word but doesn’t include the appropriate parameters with the correct prefixes, a command exception is thrown.

The following Sequence Diagram illustrates the interactions between the Logic and Model components when the user enters the command sort all t/matric.

Figure 4. Sort - Sequence Diagram

The lifeline for SortCommandParser should end at the destroy marker (X), but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
The SortCommandParser, which creates Sort commands, is different from the other command parsers. While the other commands have another level of parsing (such as the ModuleCommandParser for Module commands), the SortCommandParser creates all the different Sort commands within itself.

LogicManager uses the TaTrackerParser to first parse the user command.
The TaTrackerParser sees that the command is a sort command and passes the command to the SortCommandParser.
The SortCommandParser performs the steps shown in the previous activity diagram and determines that since the sub-command word is all , it must create and return a SortCommand.
LogicManager calls SortCommand#execute().
SortCommand checks the type of sorting that is indicated. Since the sort type is matric , it calls Model#sortModulesByMatricNumber() command.
The SortCommand returns a CommandResult with a success message.

Implementation of the Module Add, Delete and Edit Commands

(Contributed by Aakanksha)

The following Sequence Diagram shows the interactions between the Logic and Model components of the TA-Tracker when the user enters the command module add m/CS2103 n/Software Engineering.

Figure 5. Module Add - Sequence Diagram

This diagram assumes that a module with the module code CS2103 doesn’t exist in the TA-Tracker.
The lifeline for ModuleCommandParser and AddModuleCommandParser should end at the destroy marker (X), but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

LogicManager uses the TaTrackerParser to first parse the user command.
The TaTrackerParser sees that this command is a module command and passes the command to the ModuleCommandParser.
The ModuleCommandParser sees that this command is an add command and passes the arguments to the AddModuleCommandParser.
The AddModuleCommandParser creates a Module with the given module code and name.
The AddModuleCommandParser then creates an AddModuleCommand object with a newly created module. The parser then returns the AddModuleCommand object.
LogicManager calls AddModuleCommand#execute().
The AddModuleCommand object checks whether a module with the given module code already exists in TA-Tracker
1. If it does, a command exception is thrown saying that a module with the given module code already exists in the TA-Tracker.
2. If no such module exists, the module is added to the TA-Tracker.
The AddModuleCommand returns a CommandResult.

The command used to delete a module has been implemented in a similar way. The main difference is that when the DeleteModuleCommand checks whether an object with the given module code exists in the TA-Tracker

If no such module exists, a command exception is thrown saying that a module with the given module code doesn’t exist.
If it does exist, first all the sessions linked to that module are removed , then the module is removed from the TA-Tracker

The module edit command has been implemented in a similar manner.