By: Team W17-4      Since: Jan 2020      Licence: MIT

1. Introduction

(Contributed by Aakanksha)

TA-Tracker is a productivity tool made for NUS School of Computing (SoC) Teaching Assistants (TAs) who want to be able to track and manage their students and claimable hours in one place.

Teaching Assistants at SoC have to keep a track of:

  • claimable hours so that they can fill up the TSS Claims form at the end of each semester.

  • teaching-related sessions with claimable hours

  • students and their contact information

  • students' participation marks

  • notes for certain students (such as recommendations)

Rather than managing this through several excel spreadsheets and notes, TA-Tracker allows TAs to track everything in a single, convenient-to-use platform.

In particular, TA-Tracker is a Command Line Interface (CLI) application packaged with a Graphical User Interface (GUI). This means that users are expected to interact with the TA-Tracker mainly through the command line, and each command executed will evoke a visual response in the TA-Tracker.

Any help on the development of the TA-Tracker would be greatly appreciated, and there are a couple of ways that you can do so:

  • contribute to TA-Tracker’s code base by expanding its features

  • help us improve test coverage

  • propose and implement improvements on current features

This guide aims to kick-start your journey as a contributor to the TA-Tracker by getting you up to speed with how TA-Tracker’s codebase and inner workings function. It also hopes to serve as a useful reference to current contributors in times of confusion or when faced with difficulties.

2. Setting up

You can refer to the guide here.

3. Design

TA-Tracker has been designed with Object-Oriented Programming principles in mind. We also attempted to use Defensive Programming wherever possible. This section serves to give a description of the major components in the architecture of TA-Tracker. Subsequent sections provide more information on the inner workings of individual components.

3.1. Architecture

ArchitectureDiagram
Figure 1. Architecture Diagram

The Architecture Diagram given above explains the high-level design of the TA-Tracker. Given below is a quick overview of each component.

The .puml files used to create diagrams in this document can be found in the diagrams folder. Refer to the Using PlantUML guide to learn how to create and edit diagrams.

Main has two classes called Main and MainApp. It is responsible for,

  • At app launch: Initializing the components in the correct sequence, and connects them up with each other.

  • At shut down: Shutting down the components and invoking clean-up methods where necessary.

Commons represents a collection of classes used by the other components. The following class plays an important role at the architecture level:

  • LogsCenter: Used by many classes to write log messages to the TA-Tracker 's log file.

The rest of the App consists of four components.

  • UI: The UI of the TA-Tracker.

  • Logic: Handles execution of TA-Tracker commands.

  • Model: Organises the data of the TA-Tracker into different sections.

  • Storage: Reads data from, and writes data to, the hard disk.

Each of the four components

  • Defines its API in an interface with the same name as the Component.

  • Exposes its functionality using a {Component Name} Manager class.

For example, the Logic component (see the Class Diagram given below) defines its API in the Logic interface and exposes its functionality using the LogicManager class.

LogicClassDiagram1
Figure 2. Simplified Class Diagram of the Logic Component

How the architecture components interact with each other

The Sequence Diagram below shows how the components interact with each other for the scenario where the user enters the command session delete 1.

ArchitectureSequenceDiagram
Figure 3. Component interactions for session delete 1 command

The sections below give more details of each component.

3.2. UI component

(Contributed by Fatin)

The Class Diagram below shows how the UI components interact with each other.

UiClassDiagram
Figure 4. Structure of the UI Component

API: Ui.java

The UI consists of a MainWindow that is made up of parts e.g. CommandBox, ResultDisplay, StudentTab, StatusBarFooter etc. The UI also contains 2 more windows, namely:

  1. the HelpWindow and

  2. the StatisticsWindow

The UI component uses JavaFx UI framework. The layout of these UI parts is defined in matching .fxml files that are in the src/main/resources/view folder. For example, the layout of the MainWindow is specified in MainWindow.fxml

The UI component,

  • Executes user commands using the Logic component.

  • Listens for changes to Model data so that the UI can be updated with the modified data.

3.2.1. Tabs

The Class Diagram below shows how the components in the Student Tab interact with each other.

StudentTabClassDiagram
Figure 5. Structure of the Student Tab Component

All the ListPanels and Cards inherit from the abstract UiPart class.

The UI contains 3 tabs:

  1. The Student Tab

  2. The Session Tab

  3. The Claims Tab

Each of these tabs consist of one or more List Panels (e.g. StudentListPanel) and its respective Card (e.g. StudentCard). In each List Panel, the Graphics component of each of the List Cells is defined by the respective Card.

The other 2 Tabs follow the same structure as the Class Diagram above.

3.3. Logic component

(Contributed by Gabriel)

The Logic component of TA-Tracker:

  • Processes user inputs into different Command objects.

  • Executes Command objects to interact with the Model component.

  • Saves data by interacting with the Storage component.

3.3.1. Logic Structure

The following Class Diagram shows a simplified view of the structure of the Logic component.

LogicClassDiagram1
Figure 6. Structure of the Logic Component

API: Logic.java

In the Logic component,

  • Logic behaves as a façade class between the different TA-Tracker components

  • LogicManager is the main driver class behind the logic of TA-Tracker

  • LogicManager interacts with classes in the Model and Storage components

  • The logic of TA-Tracker is organised into commands and parsers

  • TaTrackerParser is the main parser

  • A Command can interact with classes in the Model component

3.3.2. Logic Organization

The following diagram shows how the commands and parsers are organized.

LogicClassDiagram2
Figure 7. Logic Component - Organization of commands and parsers

  • The letter X represents the category name for a group of commands
    (e.g. Student, Session, Module)

  • The letters XY represent the names of actions specific to a command category
    (e.g. AddStudent, EditSession, DeleteModule)

  • CommandPackageX and ParserPackageX are placeholders for the actual package names

In the Logic package,

  • There is a hierarchy of parsers, starting from TaTrackerParser

  • Within the Parser package, all parsers have been grouped into smaller packages

  • Every Command is created by a Parser object with a matching name

  • Within the Commands package, all commands have been grouped into smaller packages

  • Every Command produces a CommandResult when executed by LogicManager. This will modify the Model internally (e.g. adding a student).

  • The produced CommandResult sends feedback to the UI component. This feedback includes:

    • Showing messages in the UI

    • Instructing the UI to perform certain actions (e.g. displaying the help window).

In most cases, there are two levels of parsing before a Command is created
(e.g. SessionCommandParser passes the remaining user input to the AddSessionCommandParser for further parsing).

However, there are some cases where only one level of parsing is needed
(e.g. for the HelpCommand, ListCommand, and ExitCommand).

LogicClassDiagram3
Figure 8. Skipping the second layer of parsers

These command parsers will immediately create the respective Command, skipping the second layer of parsers.

3.3.3. Overview of Commands

Within the Commands package, all commands have been grouped into smaller packages.

The following Class Diagram shows the names of the smaller packages:

CommandsPackageDiagram1
Figure 9. Structure of smaller packages within the Commands package

These smaller packages group the commands into different categories. Furthermore, these packages depend on the Command class since they contain classes that inherit from it.

For example, the Module package contains the following classes that inherit from the Command class:

  • AddModuleCommand

  • DeleteModuleCommand

  • EditModuleCommand

3.3.4. Overview of Parsers

Within the Parser package, all parsers have been grouped into smaller packages.

These packages have been organised in the same way as the Commands package.

ParserPackageDiagram1
Figure 10. Structure of smaller packages within the Parser package

These smaller packages group the parsers into different categories. Furthermore, these packages depend on the Parser interface since they contain classes that implement it.

For example, the Module package contains the following classes that implement the Parser interface:

  • AddModuleCommandParser

  • DeleteModuleCommandParser

  • EditModuleCommandParser

3.3.5. Example Logic Sequence

(Contributed by Aakanksha)

The following Sequence Diagram shows all the interactions inside the Logic component when executing the group add m/CS2103 g/G03 t/lab command.

AddGroupSequenceDiagram
Figure 11. Interactions inside the Logic Component during the group add m/CS2103 g/G03 t/lab command

  • The lifeline for GroupCommandParser and AddGroupCommandParser should end at the destroy marker (X), but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

  • Since the purpose of this diagram is to show the interactions within the Logic component, irrelevant interactions with the Model component have been omitted.

3.4. Model component

(Contributed by Fatin)

The following Class Diagram shows how the different Model components interact with each other.

ModelClassDiagram
Figure 12. Structure of the Model Component

API: Model.java

The Model,

  • Stores a UserPref object that represents the user’s preferences

  • Stores the TA-Tracker data

  • Exposes 5 unmodifiable ObservableList<> objects:

    1. filteredStudentList, which contains all the Students in the TA-Tracker

    2. filteredSessionList, which contains all the Sessions in the TA-Tracker that have not been marked as done

    3. filteredDoneSessionList, which contains all the Sessions in the TA-Tracker that have been marked as done

    4. filteredModuleList, which contains all the Modules in the TA-Tracker

    5. filteredGroupList, which contains all the Groups in the TA-Tracker

  • These lists can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change

  • Does not depend on any of the other three components

The following Class Diagram shows the relationship between the different classes in the Model component.

ModelComponentsClassDiagram
Figure 13. Model Components - Class Diagram

3.4.1. Example of Model Usage

The following Object Diagram shows an example of the relationship between the different Model objects. This example is based on the state of TA-Tracker when it is first run (without any user data).

ModelObjectDiagram
Figure 14. Model Components - Object Diagram

3.5. Storage component

(Contributed by Gabriel)

The following Class Diagram shows a simplified view of the Storage component.

StorageClassDiagram1
Figure 15. Simplified structure of the Storage Component

API: Storage.java

The Storage component,

  • Can save UserPref objects in Json format, and read it back

  • Can save all TA-Tracker data in Json format, and read it back.

3.5.1. Saved Data

The following Class Diagram shows a breakdown of the data managed by the Storage component.

StorageClassDiagram2
Figure 16. Structure of the data stored by TA-Tracker

TA-Tracker saves the following data in Json format:

  • A list of Module objects representing the modules that the user is teaching

  • A list of Session objects representing the sessions that the user has not completed (not marked as done)

Within each Module, there is:

  • A list of Session objects, representing the sessions that the user has completed (marked as done) for that module

  • A list of Group objects, representing the groups for that module that the user is in charge of, such as a tutorial or lab

Within each Group, there is:

  • A list of Student objects, representing the students enrolled in the group

3.6. Common classes

Classes used by multiple components are in the tatracker.commons package.

4. Implementation

This section describes some noteworthy details on how certain features are implemented.

4.1. Logic

(Contributed by Gabriel)

The Logic of TA-Tracker ensures that all the user’s commands are parsed and executed correctly. In order to ensure that all the commands contain the correct information, two utility classes have been created:

  • A CommandDetails class to encapsulate details, such as the usage message, inside each Command in TA-Tracker.

    This is used to:

    • Fetch messages for CommandResult objects

    • List commands in the HelpWindow

    • Simplify the number of imports used in test cases

  • A PrefixDetails class to encapsulate details, such as the usage message, of each Prefix used in TA-Tracker.

Both utility classes support the Syntax Highlighting feature.

The CommandDetails of every Command are stored in a CommandDictionary, The PrefixDetails of every Prefix are stored in a PrefixDictionary.

The following sections will describe the implementation of these two dictionaries.

4.1.1. Implementation of the CommandDictionary

The following Class Diagram shows how a CommandDictionary stores all the details of every Command in TA-Tracker.

CommandsPackageDiagram2
Figure 17. Structure of the CommandDictionary

  1. The CommandDictionary, stores a list of CommandDetails for all the commands in TA-Tracker.

  2. All commands should have their own CommandDetails.

  3. A CommandDetails object stores all the information that a command should have
    (e.g. their commandWord and usage message).

  4. For their commandWord and sub word, commands may use constants in CommandWords to avoid repetition
    (e.g. "add", "delete", "edit").

4.1.2. Implementation of the PrefixDictionary

The following Class Diagram shows how a PrefixDictionary stores all the details of every Prefix in TA-Tracker.

ParserPackageDiagram2
Figure 18. Structure of the PrefixDictionary

  1. A PrefixDictionary stores two lists of Prefix objects:

    • parameters - a list of compulsory parameters for a command

    • optionals - a list of optional parameters for a command

  2. A PrefixDictionary contains a list of PrefixDetails. These PrefixDetails are the details of all the Prefix objects stored in parameters and optionals

  3. A PrefixDetails object adds more information to a Prefix
    (e.g. their constraint message and a list of examples).

  4. A PrefixDetail has a Predicate to validate the user input arguments.

  5. All parsers use some Prefix constants defined in Prefixes. These constants are kept in PrefixDictionary in a lookup table.

The difference between the commands and parsers is that the commands store their own CommandDetails, while the parsers do not store any PrefixDetails.

This is because the parsers do not need the extra information stored in PrefixDetails. They only need to use different Prefix objects in order to parse user inputs.

PrefixDetails adds more information to a Prefix object instead of extending it. Therefore, it can be detached from the parsers without changing the Prefix constants in Prefixes.

4.2. Goto Command

(Contributed by Fatin)

4.2.1. Description

The goto command has been implemented to allow users to programmatically switch through the tabs using the command line, rather than clicking on the tab headers.

The command can be utilised by entering goto TAB_NAME. TAB_NAME is a compulsory parameter for the user.

4.2.2. Implementation

This section describes the implementation of the goto command.

The following Sequence Diagram shows the interactions between the Logic and UI components of the TA-Tracker when the user enters the command goto claims.

GotoSequenceDiagram
Figure 19. Sequence Diagram for Goto Claims Command

Given below is an example scenario where the user enters a command to switch to the Claims Tab.

  1. The user command is passed through the LogicManager to TaTrackerParser. TaTrackerParser checks the input arguments and identify the String keywords.

  2. The TaTrackerParser sees that the command is a GotoCommand and passes the command to the GotoCommandParser.

  3. The GotoCommandParser creates a GotoCommand object with the relevant keywords.

  4. LogicManager calls GotoCommand#execute().

  5. The GotoCommand object checks whether any of the keywords given by the user matches the existing tab headers.

    1. If it does, the GotoCommand returns a CommandResult with a success message and an enum specifying how MainWindow should handle the next action.

    2. If it doesn’t, an exception is thrown.

  6. MainWindow calls the handleGoto() method to select the ClaimsTab in the TabPane, completing the tab-switching process.

4.3. Student View

Student View is used to display all modules, groups and students in the TA-Tracker.

Students are a part of groups and groups are a part of modules.

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

ModuleModelClassDiagram
Figure 20. 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.

(Contributed by Fatin)

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

StudentClassDiagram
Figure 21. Structure of the Student Component

API: Student.java

The other models (Module, Group and Session) have been implemented in a similar manner. The main difference is that the other models do not have any Tags.

As a more OOP model, we can store a Tag list in TaTracker, which Student can reference. This would allow TaTracker to only require one Tag object per unique Tag, instead of each Student needing their own Tag object. An example of what such a model may look like is given below.

BetterModelClassDiagram

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

AddModuleSequenceDiagram
Figure 22. 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.

  1. LogicManager uses the TaTrackerParser to first parse the user command.

  2. The TaTrackerParser sees that this command is a module command and passes the command to the ModuleCommandParser.

  3. The ModuleCommandParser sees that this command is an add command and passes the arguments to the AddModuleCommandParser.

  4. The AddModuleCommandParser creates a Module with the given module code and name.

  5. The AddModuleCommandParser then creates an AddModuleCommand object with a newly created module. The parser then returns the AddModuleCommand object.

  6. LogicManager calls AddModuleCommand#execute().

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

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

  1. If no such module exists, a command exception is thrown saying that a module with the given module code doesn’t exist.

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

4.3.3. Implementation of the Group Add, Delete and Edit Commands

(Contributed by Aakanksha)

A group is added to the TA-Tracker in a similar manner to how a module is added to the TA-Tracker.

The following steps are taken once the execute method of an AddGroupCommand object is called:

  1. The AddGroupCommand object checks whether the module is present in the model of the TA-Tracker .

    1. If it exists, the module is retrieved.

    2. If it doesn’t exist, an exception is thrown explaining that the module doesn’t exist.

  2. The AddGroupCommand object checks whether a group with the same group code as the new group exists in the module retrieved beforehand.

    1. If it doesn’t exist, the group is added to the module and a CommandResult object with the success message is returned.

    2. If it does exist, an exception is thrown explaining that you can’t have two groups with the same group code in a module.

The interactions between the Logic and Model components when adding a group are similar to the interactions when deleting a group as shown below.

The following Sequence Diagram shows the interactions between the Logic and Model components when the user inputs the command group delete m/CS2103 g/G03.

DeleteGroupSequenceDiagram
Figure 23. Group Delete - Sequence Diagram

  • This diagram is under the case where a group with the group code G03 does exist in the module with module code CS2103 inside the TA-Tracker.

  • The lifeline for GroupCommandParser and DeleteGroupCommandParser should end at the destroy marker (X), but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

  • The main difference between the Module and Group commands is that the Group commands require extra checks to check whether a group with the given group code exists inside the module with the given module code.

  1. LogicManager uses the TaTrackerParser to first parse the user command.

  2. The TaTrackerParser sees that the command is a group command and passes the command to the GroupCommandParser.

  3. The GroupCommandParser sees that the command is a delete command and passes the arguments to the DeleteGroupCommandParser.

  4. The DeleteGroupCommandParser then creates a DeleteGroupCommand object and passes it the module code, group code and group type. The parser then returns the DeleteGroupCommand object.

  5. LogicManager calls DeleteGroupCommand#execute(). The DeleteGroupCommand object checks whether a module with the given module code already exists in TA-Tracker If it doesn’t, a command exception is thrown saying that a module with the given module code doesn’t exist in the TA-Tracker

  6. If the module exists, the DeleteGroupCommand then checks whether a group with the given group code exists within that module.

    1. If the group doesn’t exist, a command exception is thrown saying that no such group exists.

    2. If the group does exist, it is removed from the module.

  7. The DeleteGroupCommand returns a CommandResult.

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

4.3.4. Implementation of the Student Add, Delete and Edit Commands

(Contributed by Gabriel)

A student can be added to the TA-Tracker after a module and group is added.

The commands for students are similar to the commands for modules and groups. The main difference is that there are a few additional conditions in order to ensure that a student is inside the TA-Tracker.

The following Sequence Diagram shows the interactions that take place between the Logic and Model components of the TA-Tracker when the user enters the command student delete m/CS2103 g/G03 id/A0181234G.

DeleteStudentSequenceDiagram
Figure 24. Student Delete - Sequence Diagram

  • This diagram assumes that the following data are inside the TA-Tracker:

    • A student with the matric number A0181234G
      (shown as id in the diagram)

    • The same student inside the group G03
      (shown as g in the diagram)

    • The same group inside the module CS2103
      (shown as m in the diagram)

  • The lifeline for StudentCommandParser and DeleteStudentCommandParser should end at the destroy marker (X), but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

  1. LogicManager uses the TaTrackerParser to first parse the user command.

  2. The TaTrackerParser sees that the command is a student command and passes the command to the StudentCommandParser.

  3. The StudentCommandParser sees that the command is a delete command and passes the arguments to the DeleteStudentCommandParser.

  4. The DeleteStudentCommandParser then creates a DeleteStudentCommand object with the matric number, module code and group code from the arguments. The parser then returns the DeleteStudentCommand.

  5. LogicManager calls DeleteStudentCommand#execute() to begin removing a student from the TA-Tracker.

  6. The DeleteStudentCommand checks the following three conditions:

    1. A module with the given module code is inside the TA-Tracker.

    2. A group with the given group code is inside the same module.

    3. A student with the given matric number is inside the same group.

  7. For each condition, there are two outcomes:

    1. If the condition is false, then a command exception is thrown saying that the object does not exist.

    2. If it is true, then the student with the given matric number is removed from the expected group inside the expected module.

  8. Finally, the DeleteStudentCommand returns a CommandResult.

    1. If the command successfully removed a student, the CommandResult will contain a success message.

    2. If not, the CommandResult will have a message explaining why the student could not be removed.

The student add and student edit command has been implemented in a similar manner. However, the student add command has a slight difference.

When the student add command is executed, there is an extra condition that must be true: there cannot be a student with the given matric number already inside the expected group inside the expected module.

4.3.5. 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:

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

  2. sort module g/MODULE_CODE t/TYPE : This sorts all the students of all the groups in the given module by type TYPE.

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

SortCommandsClassDiagram
Figure 25. 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).

SortParserActivityDiagram
Figure 26. 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.

SortAllSequenceDiagram
Figure 27. 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.

  1. LogicManager uses the TaTrackerParser to first parse the user command.

  2. The TaTrackerParser sees that the command is a sort command and passes the command to the SortCommandParser.

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

  4. LogicManager calls SortCommand#execute().

  5. SortCommand checks the type of sorting that is indicated. Since the sort type is matric , it calls Model#sortModulesByMatricNumber() command.

  6. The SortCommand returns a CommandResult with a success message.

4.4. Session View

(Contributed by Chua Yi Jing)

Session View is the term used to refer to the view that contains a list of all sessions that haven’t been completed yet.

4.4.1. Model Framework

(Contributed by Haoyi)

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

SessionModelClassDiagram
Figure 28. Class Diagram of Session View

The TA-Tracker model class contains a UniqueSessionList which helps keep track of all the sessions in TA-Tracker that have not been marked as done.

4.4.2. Implementation of the Session Done Command

(Contributed by Chua Yi Jing)

The following Sequence Diagram shows the sequence of commands that take place between the Logic and Model components of the TA-Tracker when the user enters the command session done 1.

DoneSessionSequenceDiagram
Figure 29. Sequence Diagram for Done Session

  • The lifeline for SessionCommandParser and DoneSessionCommandParser should end at the destroy marker (X), but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

  1. The LogicManager uses the TaTrackerParser to first parse the user command.

  2. The TaTrackerParser sees that the command is a Session command and passes the command to the SessionCommandParser.

  3. The SessionCommandParser sees that the command is a DoneSessionCommand and passes the arguments to the DoneSessionCommandParser.

  4. The DoneSessionCommandParser creates a DoneSessionCommand with the given index.

  5. LogicManager calls DoneSessionCommand#execute() method.

  6. The DoneSessionCommand checks whether the current session called by the user has a recurring period.

    1. If it does, a new session with the updated date will be added to Model#UniqueSessionList().

    2. If it does not have a recurring period, it will move on to Step 6.

  7. The current session is marked as done and will be removed from Model#UniqueSessionList.

  8. The updated session list will be displayed to the user.

(Contributed by Fatin)

The following Activity Diagram describes how TaTracker is updated when a SessionDone command is entered.

DoneSessionActivityDiagram
Figure 30. Session Done Activity Diagram

The above diagram assumes that a valid index has been input into the TA-Tracker during the done session command.

4.4.3. Implementation of Session Add, Edit and Delete

(Contributed by Chua Yi Jing)

The session edit and session delete commands have been implemented in a similar manner to DoneSessionCommand.

The session add command has been implemented in a similar way. The main difference is that the SessionAddCommand checks whether an object with the given module code exists in the TA-Tracker.

  • If no such module code exists, the session is created successfully.

  • If it doesn’t exist, an exception is thrown saying that the given module code doesn’t exist.

4.5. Claims View

(Contributed by Fatin)

Claims View refers to the view that contains a list of all the sessions that have been done.

4.5.1. Model Framework

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

TssModelClassDiagram
Figure 31. Claims View - Class Diagram

The TaTracker model class contains a UniqueDoneSessionList which keeps track of all the sessions that have been marked as done. Each of the sessions must belong to a Module in the UniqueModuleList.

4.5.2. Set Rate Command

Given below is an example scenario where the user enters the command setrate 50.

  1. The user command is passed through the LogicManager to TaTrackerParser.

  2. TaTrackerParser checks the input arguments and identify the String keywords.

  3. The TaTrackerParser sees that the command is a type of SetRate and passes the command to the SetRateCommandParser.

  4. The SetRateCommandParser object checks that the given RATE input by the user is a valid integer. If it is, the SetRateCommandParser creates a SetRateCommand object with the relevant integer.

  5. LogicManager calls SetRateCommand 's execute method.

  6. MainWindow updates the TotalEarnings label in the ClaimsTab and the StatisticsWindow

4.6. Filter Command

(Contributed by Chua Yi Jing)

4.6.1. Description

Different view has its own designated filter command.

  • Student View, has the student filter

  • Session View, has the session filter

  • Claims View, has the claims filter

4.6.2. Implementation

This section describes the implementation of the filter command.

The Activity Diagram below summarises what happens when the user executes a filter command:

FilterCommandActivityDiagram
Figure 32. Activity Diagram of the Filter Command

The filter feature consists of three main steps:

  1. Validating and parsing user input

  2. Creating a filtering predicate from user’s input

  3. Updating the filtered list with the filtering predicate

4.6.2.1. Filter under Student View

Students are filtered based on the module code and/or group code given by the user.

Module code is a compulsory parameter for the user.

The following Sequence Diagram shows the sequence of commands that take place between the Logic and Model components of the Ta-Tracker when the user enters the command student filter m\CS2103T g\G06. This command will return students from module code CS2103T, under group G06.

FilterStudentSequenceDiagram
Figure 33. Sequence Diagram for Filter Student Command

  • The lifeline for StudentCommandParser and FilterStudentCommandParser should end at the destroy marker (X), but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

Given below is an example scenario where the user enters a command to filter students.

  1. The user command is passed through the LogicManager to TaTrackerParser. TaTrackerParser checks the input arguments and identify the String keywords.

  2. The TaTrackerParser sees that the command is a type of Student and passes the command to the StudentCommandParser.

  3. The StudentCommandParser sees that the command is a type of filter and passes the arguments to the FilterStudentCommandParser.

  4. The FilterStudentCommandParser creates a FilterStudentCommand object with the relevant keywords.

  5. LogicManager calls FilterStudentCommand#execute().

  6. The FilterStudentCommand object checks whether any of the keywords given by the user matches the existing module and/or group.

    1. If it doesn’t, a CommandException is thrown saying that no such students exists.

    2. If it does, the FilterStudentCommand returns a CommandResult with a success message.

4.6.2.2. Filter under Session View

Sessions can be filtered with the following parameters:

  • d/DATE

  • m/MODULE CODE

  • t/SESSION_TYPE

These parameters can be used alone or together.

The command used to filter sessions has been implemented in a similar way. The main difference is that the FilterSessionCommandParser creates a SessionPredicate object. The SessionPredicate object updates the filtered session list by keywords in Model. The filtered list will then be displayed.

When the user specifies a keyword, sessions that contain the keywords will be filtered and shown to the user. If none of the keywords supplied by the user appears in any sessions, a CommandException will be shown.

The following Class Diagram shows how different classes are related in the functioning of the SessionFilter Command.

FindCommandClassDiagram
Figure 34. Class Diagram for Filter Session Command
4.6.2.3. Filter under Claims View

The user can only filter the Claims View by module code. When the user enters the command claims filter m/MODULE_CODE, claims that contain the module code will be filtered.

The command used to filter claims is implemented the same way as SessionFilterCommand.

4.7. Syntax Highlighting

(Contributed by Gabriel)

When a user types a command, their inputs will be highlighted in different colours as a form of input validation.

In addition, different messages will be displayed based on the result of the syntax highlighting.

The following screenshot shows how the CommandBox and ResultDisplay appear in the TA-Tracker.

ui
Figure 35. The CommandBox and the ResultDisplay in TA-Tracker

In the screenshot above:

  • There is a user input highlighted in green in the CommandBox

  • There is a message in white showing in the ResultDisplay

  • The command being entered is session edit

  • The user has entered three arguments: date, start time, and end time.

4.7.1. Overview

The following Class Diagram shows how the Logic and UI components interact with each other to produce the highlighting.

SyntaxHighlightingClassDiagram
Figure 36. Syntax Highlighting - Class Diagram

The CommandBox:

  • Uses a CommandDictionary to search for valid commands

  • Stores a CommandDetail for processing the current command in the user input

  • Stores a PrefixDictionary containing the PrefixDetails for the current command.

  • Uses PrefixDetails to process each argument in the current command

  • Uses a CommandBoxUtil to validate user inputs

  • Returns feedback to the ResultDisplay

The ResultDisplay displays the given feedback as a message in the TA-Tracker.

4.7.2. Identifying the parts of a User Input

Here is an example of a user input in the CommandBox:

commandbox
Figure 37. An example of a user input in the CommandBox

User inputs can be divided into the following parts:

Keyword Meaning Example

full command word

The part of the user input that identifies a command.
full command word
Figure 38. A full command word (coloured in blue in this screenshot)

argument

The part of the user input that identifies a command parameter.

It contains a prefix and a value.
argument 1
argument 2
argument 3
Figure 39. The arguments in the user input (coloured in blue in these screenshots)

prefix

The part of an argument up to and including the / forward slash delimiter.
prefix 1
prefix 2
prefix 3
Figure 40. The prefixes of each argument in the user input (coloured in blue in these screenshots)

value

Everything after the prefix of an argument.
value 1
value 2
value 3
Figure 41. The values of each argument in the user input (coloured in blue in these screenshots)

preamble

The part of the user input (including whitespaces) between the end of the full command word, and the beginning of the first argument.
preamble
Figure 42. The preamble in the user input (coloured in blue in these screenshots)

4.7.3. Implementation of the Syntax Highlighting

The following diagrams show the steps that take place when applying syntax highlighting to the user’s input.

Due to the limitations of PlantUML, the following Activity Diagrams may not follow UML notation.

In particular, there are issues with representing alternate branches.

For example, alternate branches:

  • Split into multiple branch nodes, instead of all originating from the same node

  • Do not converge at a single merge node before the end node

There is a way for the diagrams to be arranged vertically. However, this dilates the diagrams, making them difficult to fit in this guide.
4.7.3.1. Step 1 - Highlighting a new input

Syntax highlighting is applied when the user changes their input in the CommandBox.

The following Activity Diagram shows how the full command word is highlighted, up until the beginning of the preamble.

SyntaxHighlightingActivityDiagram1
Figure 43. Step 1 - Highlighting a new input
There should be a rake symbol next to the bolded activity - Highlight arguments.

Here is the purpose of each alternate path in the above diagram:

Path Action Example

[empty input]

When there is no input, no action occurs.
empty input
Figure 44. An empty CommandBox

[invalid command word]

When there is no matching full command word, the ResultDisplay will indicate that a wrong command is entered.
invalid command word
Figure 45. Invalid full command word

[no arguments]

When a full command word has just been entered, the ResultDisplay will show that a correct command has been entered.
no arguments
Figure 46. CommandBox has no arguments

[has arguments]

After processing the full command word, proceed to Step 2.
has arguments
Figure 47. CommandBox has arguments
4.7.3.2. Step 2 - Highlighting the preamble

If the new input has a full command word, the next step is to apply syntax highlighting on the preamble and arguments.

The following Activity Diagram shows how the preamble is highlighted, up until the beginning of the first argument.

SyntaxHighlightingActivityDiagram2
Figure 48. Step 2 - Highlighting the preamble
There should be a rake symbol next to the bolded activities - Highlight invalid arguments.

Here is the purpose of each alternate path in the above diagram:

Path Action Example * whitespaces

[trailing whitespace]

When there are trailing whitespaces, the syntax highlighting is removed.
trailing whitespace
Figure 49. A trailing whitespace (coloured in blue in this screenshot)

[many whitespaces]

When there are two or more trailing whitespaces, the ResultDisplay will show how to use the command.
many whitespaces
Figure 50. Many trailing whitespaces (coloured in blue in this screenshot)

[invalid preamble]

When the input has a preamble that the command does not need, the ResultDisplay will indicate that a wrong command is entered.
invalid preamble
Figure 51. An invalid preamble

[blank preamble], and
[needs preamble]

After processing the preamble, proceed to Step 3.
blank preamble
Figure 52. A command that requires a blank preamble
needs preamble
Figure 53. A command that needs a valid preamble
4.7.3.3. Step 3 - Highlighting the remaining arguments

After the preamble has been verified, the syntax highlighting is applied on each argument in the remaining user input. An invalid or wrong argument will stop the highlighting.

The following Activity Diagram explains how each argument is highlighted, up until end of the user input.

SyntaxHighlightingActivityDiagram3
Figure 54. Step 3 - Highlighting the remaining arguments

Here is the purpose of each alternate path in the above diagram:

Path Action Example

[wrong]

When the command does not recognise the given argument, the ResultDisplay will show how to use the command.
wrong
Figure 55. Wrong argument in input

[invalid]

When the argument cannot have the given value, the ResultDisplay will show how to use the argument.
invalid
Figure 56. Invalid argument in input

[valid]

After processing the current argument, the ResultDisplay will still show how to use it in case the argument can have spaces.
valid
Figure 57. Valid argument in input

4.7.4. Design Considerations

4.7.4.1. Showing the command usage after every two white spaces

When a user enters two white spaces, the usage for the current command wil reappear in the ResultDisplay. The purpose of this is to provide the user with a quick example of how to use the command, since a command may have a lot of parameters.

The following are reasons why the usage appears after every two spaces:

  • The user will have to enter whitespaces frequently. This should allow our target users (whom are fast typers) to quickly verify how to use the different commands.

  • A user input will usually have words separated with a single white space

  • It gives a use for user inputs to have arguments separated with more than one whitespace

Alternative Implementation

An alternative would be to assign a keyboard shortcut, such as the Tab key, to give the user the option to display the command usage only when they need it.

Currently, the ResultDisplay shows the command usage whenever the user inputs something new. This could be annoying for the user when they are familiar with the commands.

However, the user may have assigned actions to these keyboard shortcuts on their computer, Therefore, TA-Tracker would need to allow the user to assign their own keyboard settings.

As TA-Tracker is meant to be used primarily on the CLI, assigning keyboard shortcuts does not seem like a suitable feature for our target users. However, implementing this is an option in future versions of TA-Tracker.

4.7.4.2. Always showing the syntax highlighting

Similar to the previous design consideration, the syntax highlighting could instead be toggled on and off using a keyboard shortcut.

Alternative Implementation

Alternatively, there could be a command to toggle the syntax highlighting on and off.

Here is an example of how the command could be made:

  • syntax on - enables the syntax highlighting

  • syntax off - disables the syntax highlighting

  • syntax cmd - enables the syntax highlighting for full command words only

  • syntax args - enables the syntax highlighting for arguments only

Then, the CommandBox will have boolean flags to toggle the syntax highlighting before the each of the three steps explained in the Implementation of the Syntax Highlighting.

4.8. Statistic Report Generation

(Contributed by Haoyi)

4.8.1. Description

The Statistics Window can be generated and displayed using the report command. The command is used to generate a report to display information such as:

  • A breakdown and summary of completed sessions

  • The number of hours of each type of completed sessions

  • A breakdown of your student’s ratings

A module code can be specified such that the generated report will only include data from a specific module.

4.8.2. Implementation

This section describes the implementation of the report command.

The following Sequence Diagram shows the interactions between the UI and the Logic components of TA-Tracker, when the user enters the command report CS3247.

ReportSequenceDiagram
Figure 58. Sequence Diagram for Statistic Report Generation

The following is an example scenario when the user requests for a report of a particular module, with the command report CS3247.

  1. The user command is first read by MainWindow, through JavaFX. MainWindow passes the command as a String to the LogicManager to be processed.

  2. LogicManager sends the command to TaTrackerParser for the command to be parsed.

  3. The TaTrackerParser processes the first word in the command, and identifies it as a ShowStatisticCommand.

  4. TaTrackerParser creates a ShowStatisticCommandParser object and passes the command argument CS3247 to the ShowStatisticCommandParser object.

  5. The ShowStatisticCommandParser stores the target module, CS3247, in a ShowStatisticCommand object and this command object is returned all the way back to the LogicManager.

  6. LogicManager executes the ShowStatisticCommand, which creates and return a StatiscCommandResult. This command result is returned by LogicManager to MainWindow

  7. MainWindow detects that the command result is of type StatisticCommandResult, and prepares the StatisticWindow by creating a Statistic object that retrieves data necessary for generating the report, from ReadOnlyTaTracker.

  8. The data is then processed further by Statistic. This includes computing the total number of sessions per session type and sorting the students by rating.

  9. A StatisticWindow object is now created by MainWindow. The Statistic object is passed into the constructor of StatisticWindow.

  10. Finally, StatisticWindow updates its FXML elements and is shown to the user.

4.9. System Notification - Ready for Use

(Contributed by Haoyi)

4.9.1. Overview

TA-Tracker supports a cross-platform OS-level notification system. Notifications can be triggered from anywhere within TA-Tracker’s code base. This feature can be used to implement time-based features in V2.0.

4.9.2. Usage

Notifications can be triggered via the Notification class. For example:

Notification.sendNotification("TA Tracker", "You have a consultation scheduled in 15 minutes!", TrayIcon.MessageType.INFO);

On MacOS, the following notification will be triggered.

MacOSNotification
Figure 59. An Example TA-Tracker Notification on MacOS

4.9.3. Implementation

Notifications are implemented with Java’s SystemTray. A SystemTray object will be created when Notification.sendNotification is invoked for the first time. In order to guarantee that only one instance of SystemTray is ever created, Notifications are implemented using the defensive Singleton pattern.

The following Activity Diagram shows an example of how a notification can be triggered.

NotificationSingletonActivityDiagram
Figure 60. Activity Diagram for Notification Singleton

The following is an example scenario when a seperate system requests for two seperate notifications from within TA-Tracker.

NotificationSingletonSequenceDiagram
Figure 61. Sequence Diagram for Notification Singleton

  1. The static Notification.sendNotification(…​) method is invoked for the very first time.

  2. The Notification class calls its own getInstance() function to try to locate an existing instance of the notification singleton object.

  3. Since this is the first time a notification has been requested, getInstance() constructs the first notification singleton object.

  4. A notification in then requested from the singleton.

  5. The singleton creates and triggers an OS-level notification.

  6. Some time later, Notification.sendNotification(…​) is invoked again.

  7. The Notification class calls its own getInstance() function to try to locate an existing instance of the notification singleton object.

  8. Since the singleton already exists, a notification is requested directly from the existing singleton.

  9. The singleton creates and triggers the second OS-level notification.

4.10. Logging

We are using java.util.logging package for logging. The LogsCenter class is used to manage the logging levels and logging destinations.

  • The logging level can be controlled using the logLevel setting in the configuration file (See Section 4.11, “Configuration”)

  • The Logger for a class can be obtained using LogsCenter.getLogger(Class) which will log messages according to the specified logging level

  • Currently log messages are output through: Console and to a .log file.

Logging Levels

  • SEVERE: Critical problem detected which may possibly cause the termination of the application

  • WARNING: Can continue, but with caution

  • INFO: Information showing the noteworthy actions by the App

  • FINE: Details that is not usually noteworthy but may be useful in debugging e.g. print the actual list instead of just its size

4.11. Configuration

Certain properties of the application can be controlled (e.. user prefs file location, logging level) through the configuration file (default: config.json).

5. Documentation

Refer to the guide here.

6. Testing

Refer to the guide here.

7. Dev Ops

Refer to the guide here.

Appendix A: Product Scope

Target user profile:

  • Targets NUS Computing Teaching Assistants

  • Has a need to track and manage all their claimable hours of teaching

  • Has a need to track all their students in multiple groups and/or modules

  • Has a need to keep track of their tasks (TA-related)

  • Prefer apps on desktop over other platforms

  • Types quickly and prefers it over mouse

  • Experiences no discomfort with CLI navigation

Value proposition:

  • Collates all information regarding claimable teaching hours and student information in a single location

  • Displays forms (such as the TSS Claims Form) in a format that is convenient for users to view

Appendix B: User Stories

(Contributed by Aakanksha)

Priorities: High (must have) - * * *, Medium (nice to have) - * *, Low (unlikely to have) - *

Priority As a …​ I want to …​ So that I can…​

* * *

new user

be able to use a help command

refer to instructions on what commands are available when I forget about them

* * *

TA

state that a task is recurring

prevent the need to put a recurring task in my schedule each week

* * *

TA

set my hourly rate

get the value of my estimated pay according to the latest rate of the semester

* * *

TA

store contact details of my students

I can contact them with ease whenever necessary

* * *

TA

see an overview of the upcoming tasks I have

plan my schedule accordingly

* * *

TA

see all my claimable hours in one place

type my claims easily at the end of the semester

* * *

user

switch between the different views using command line

view the information in the different views

* * *

TA

add students to a group in a particular module

So that I know which group which student belongs to

* * *

TA

add multiple modules

keep track of the different modules I am a TA for

* * *

TA

add a tutorial/lab group

keep track of the different tutorial and lab groups I conduct

* * *

careless TA

edit student details

rectify mistakes I make

* * *

TA

remove students from a tutorial or lab group

no longer have details of students that are no longer in my tutorial/lab group

* * *

TA

mark a session as done

keep a track of things I have completed in my claims

* * *

TA

schedule consultation sessions with my students

keep track of claimable hours spent in consultations

* *

TA

get information on how many hours I’ve worked so far

keep track of how much work I’ve done

* *

TA

get information on how much money I’ve earned so far

keep track of how much money I have earned and stay motivated

* *

TA

give students ratings

keep a track of student participation in class

* *

TA

delete tasks and events

remove cancelled tasks and events from my session tracker

* *

TA

be able to get tasks on a particular date

plan events accordingly

* *

TA

filter by a module

see events relating to a particular module clearly

* *

TA

delete a tutorial group

remove tasks relating to a tutorial group I am no longer the TA of

* *

TA

delete a module

remove tasks relating to a module I am no longer the TA of

*

TA

receive a warning message when a new task clashes with an old one

prevent clashes in my schedule (coming in V2.0)

*

TA

be able to mark student’s attendance

keep track of my students' attendance (coming in V2.0)

*

TA

enter my students' assignment grades

keep track of my students' progress (coming in V2.0)

*

TA

add my students' to consultation sessions

keep track of how frequently each student has consulted me (coming in V2.0)

Appendix C: Use Cases

(For all use cases below, the System is the TA-Tracker and the Actor is the user, unless specified otherwise)

Use case: UC01 - Viewing the help menu

MSS (Contributed by Fatin)

  1. User requests to view the help window.

  2. TA-Tracker opens a new window showing the list of commands.

    Use case ends.

Use case: UC02 - Going to a different tab

MSS (Contributed by Fatin)

  1. User requests to go to a different tab.

  2. TA-Tracker switches to the requested tab.

    Use case ends.

Extensions

  • 1a. The requested tab is invalid.

    • 1a1. TA-Tracker shows an error message.

      Use case resumes at step 1.

Use case: UC03 - Exiting the app

MSS (Contributed by Fatin)

  1. User requests to exit the app.

  2. TA-Tracker closes the App window.

    Use case ends.

Student View

Use case: UC04 - Adding a module

MSS (Contributed by Fatin)

  1. User requests to add a new module.

  2. TA-Tracker adds a new module.

  3. TA-Tracker switches to the Student Tab.

    Use case ends.

Extensions (Contributed by Aakanksha)

  • 1a. The given module code already exists in the TA-Tracker.

    • 1a1. TA-Tracker shows an error message.

      Use case resumes at step 1.

  • 1b. The give module code is invalid.

    • 1b1. TA-Tracker shows an error message.

      Use case resumes at step 1.

  • 1c. The given module name is invalid.

    • 1c1. TA-Tracker shows an error message.

      Use case resumes at step 1.

Use case: UC05 - Editing a module

MSS (Contributed by Fatin)

  1. User requests to go to the Student Tab (UC02) to view the list of existing modules in the Student View.

  2. TA-Tracker switches to the Student Tab.

  3. User requests to edit an existing module.

  4. TA-Tracker edits the module.

    Use case ends.

Extensions (Contributed by Aakanksha)

  • 3a. The given module code doesn’t exist in the TA-Tracker.

    • 3a1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3b. The given module name is invalid.

    • 3b1. TA-Tracker shows an error message.

      Use case resumes at step 3.

Use case: UC06 - Deleting module

MSS (Contributed by Fatin)

  1. User requests to go to the Student Tab (UC02) to view the list of existing modules in the Student View.

  2. TA-Tracker switches to the Student Tab.

  3. User requests to delete an existing module.

  4. TA-Tracker deletes the module and all of the sessions, groups, and students in it.

    Use case ends.

Extensions (Contributed by Aakanksha)

  • 2a. The list is empty.

    Use case ends.

  • 3a. The given module code doesn’t exist in the TA-Tracker.

    • 3a1. TA-Tracker shows an error message.

      Use case resumes at step 3.

Use case: UC07 - Adding a group

MSS (Contributed by Fatin)

  1. User requests to go to the Student Tab (UC02) to view the list of existing modules in the Student View.

  2. TA-Tracker switches to the Student Tab.

  3. User requests to add a group to a module

  4. TA-Tracker adds the new group

    Use case ends.

Extensions (Contributed by Aakanksha)

  • 3a. The given module code doesn’t exist in the TA-Tracker.

    • 3a1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3b. The given group code is invalid.

    • 3b1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3c. The given group code already exists in the module.

    • 3c1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3d. The given group code is invalid.

    • 3d1. TA-Tracker shows an error message.

      Use case resumes at step 3.

Use case: UC08 - Editing a group

MSS (Contributed by Fatin)

  1. User requests to go to the Student Tab (UC02) to view the list of existing groups in the Student View.

  2. TA-Tracker switches to the Student Tab.

  3. User requests to edit a group

  4. TA-Tracker edits the group

Extensions (Contributed by Aakanksha)

  • 3a. The given module code doesn’t exist in the TA-Tracker.

    • 3a1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3b. The given group doesn’t exist in the module.

    • 3b1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3c. The new group code already exists in the module.

    • 3c1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3d. The new group code is invalid.

    • 3d1. TA-Tracker shows an error message.

      Use case resumes at step 3.

Use case: UC09 - Deleting group

MSS (Contributed by Fatin)

  1. User requests to go to the Student Tab (UC02) to view the list of existing groups in the Student View.

  2. TA-Tracker switches to the Student Tab.

  3. User requests to delete a group

  4. TA-Tracker deletes the group and all of the students in it

    Use case ends.

Extensions (Contributed by Aakanksha)

  • 2a. The list is empty.

    Use case ends.

  • 3a. The given module doesn’t exist in the TA-Tracker.

    • 3a1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3b. The given group doesn’t exist in the module.

    • 3b1. TA-Tracker shows an error message.

      Use case resumes at step 3.

Use case: UC10 - Adding a student

MSS (Contributed by Fatin)

  1. User requests to go to the Student Tab (UC02) to view the list of existing groups in the Student View.

  2. TA-Tracker switches to the Student Tab.

  3. User requests to add a new student to a group

  4. TA-Tracker adds the new student

    Use case ends.

Extensions (Contributed by Gabriel)

  • 3a. User provides invalid student details (for example, an invalid matric number).

    • 3a1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3b. The given module doesn’t exist.

    • 3b1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3c. The given group doesn’t exist in the module.

    • 3c1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3d. A student with the same matric number already exists inside the group.

    • 3d1. TA-Tracker shows an error message.

      Use case resumes at step 3.

Use case: UC11 - Editing a Student

MSS (Contributed by Fatin)

  1. User requests to go to the Student Tab (UC02) to view the list of existing students in the Student View.

  2. TA-Tracker switches to the Student Tab.

  3. User requests to edit a student

  4. TA-Tracker edits the student

    Use case ends.

Extensions (Contributed by Gabriel)

  • 2a. The list is empty.

    Use case ends.

  • 3a. User provides an invalid matric number.

    • 3a1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3b. User edits the student with invalid details (for example, an invalid phone number).

    • 3b1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3c. The given module doesn’t exist.

    • 3c1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3d. The given group doesn’t exist in the module.

    • 3d1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3e. The given student doesn’t exist in the group.

    • 3e1. TA-Tracker shows an error message.

      Use case resumes at step 3.

Use case: UC12 - Deleting a student

MSS (Contributed by Fatin)

  1. User requests to go to the Student Tab (UC02) to view the list of existing students in the Student View.

  2. TA-Tracker switches to the Student Tab.

  3. User requests to delete a student

  4. TA-Tracker deletes the student

    Use case ends.

Extensions (Contributed by Gabriel)

  • 2a. The list is empty.

    Use case ends.

  • 3a. User provides an invalid matric number.

    • 3a1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3b. The given module doesn’t exist.

    • 3b1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3c. The given group doesn’t exist in the module.

    • 3c1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3d. The given student doesn’t exist in the group.

    • 3d1. TA-Tracker shows an error message.

      Use case resumes at step 3.

Use case: UC13 - Sorting a group

(Contributed by Aakanksha)

MSS

  1. User requests to go to the Student Tab (UC02) to view the list of existing groups in the Student View.

  2. TA-Tracker switches to the Student Tab.

  3. User requests to sort all students in a group.

  4. TA-Tracker sorts the students in the group.

    Use case ends.

Extensions

  • 3a. The given sort type is invalid.

    • 3a1. TA-Tracker shows an error message.

      Use case resumes at step 1.

  • 3b. The given module doesn’t exist.

    • 3b1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3c. The given group doesn’t exist in the module.

    • 3c1. TA-Tracker shows an error message.

      Use case resumes at step 3.

Use case: UC14 - Sorting a module

(Contributed by Aakanksha)

MSS

  1. User requests to go to the Student Tab (UC02) to view the list of existing groups in the Student View.

  2. TA-Tracker switches to the Student Tab.

  3. User requests to sort all students in all groups of a module.

  4. TA-Tracker sorts the students in the group.

    Use case ends.

Extensions

  • 3a. The given sort type is invalid.

    • 3a1. TA-Tracker shows an error message.

      Use case resumes at step 1.

  • 3b. The given module doesn’t exist.

    • 3b1. TA-Tracker shows an error message.

      Use case resumes at step 3.

  • 3c. The given group doesn’t exist in the module.

    • 3c1. TA-Tracker shows an error message.

      Use case resumes at step 3.

Use case: UC15 - Sorting all modules

(Contributed by Aakanksha)

MSS

  1. User requests to sort all students in all groups of a module.

  2. TA-Tracker sorts the students in the group.

  3. TA-Tracker switches to the Student Tab.

    Use case ends.

Extensions

  • 1a. The given sort type is invalid.

    • 1a1. TA-Tracker shows an error message.

Use case: UC16 - Filtering the Student View

MSS (Contributed by Chua Yi Jing)

  1. User requests to go to the Student Tab (UC02) to view the list of existing students in the Student View.

  2. TA-Tracker switches to the Student Tab.

  3. User requests to filter students from a specific module and/or group.

  4. TA-Tracker shows the filtered students.

    Use case ends.

Extensions

  • 3a. The module and/or group does not exist.

    • 3a1. TA-Tracker shows an error message.

      Use case resumes at step 3.

Session View

Use case: UC17 - Adding a session

MSS (Contributed by Chua Yi Jing and Fatin)

  1. User requests to add a session.

  2. TA-Tracker adds the session.

  3. TA-Tracker switches to the Session Tab.

    Use case ends.

Extensions

  • 1a. The user requests to add a recurring session.

    • 1a1. TA-Tracker creates a new session, and labels it as recurring.

      Use case resumes at step 2.

  • 1a. The user adds a session with a module code that does not exists.

    • 1a1. TA-Tracker shows an error message.

      Use case resumes at step 1.

Use case: UC18 - Deleting a session

MSS (Contributed by Chua Yi Jing and Fatin)

  1. User requests to go to the Session Tab (UC02) to view the list of existing sessions in the Session View.

  2. TA-Tracker switches to the Session Tab.

  3. User requests to delete a session.

  4. TA-Tracker deletes the session.

    Use case ends.

Extensions

  • 3a. The index is invalid

    • 3a1. TA-Tracker shows an error message.

      Use case resumes at step 3.

Use case: UC19 - Editing a session

MSS (Contributed by Chua Yi Jing and Fatin)

  1. User requests to go to the Session Tab (UC02) to view the list of existing sessions in the Session View.

  2. TA-Tracker switches to the Session Tab.

  3. User requests to edit a session.

  4. TA-Tracker edits the session.

    Use case ends.

Extensions

  • 3a. The given session list index is invalid.

    • 3a1. TA-Tracker shows an error message.

      Use case resumes at step 3.

Use case: UC20 - Marking a session as done

MSS (Contributed by Chua Yi Jing and Fatin)

  1. User requests to go to the Session Tab (UC02) to view the list of existing sessions in the Session View.

  2. TA-Tracker switches to the Session Tab.

  3. User requests to mark a session as done.

  4. TA-Tracker marks the session as done and removes the session from the Session View.

  5. TA-Tracker adds the session to the Claims View and switches to the Claims Tab.

    Use case ends.

Extensions

  • 3a. The given session list index is invalid.

    • 3a1. TA-Tracker shows an error message.

      Use case resumes at step 3.

Use case: UC21 - Filtering under Session View

MSS (Contributed by Chua Yi Jing)

  1. User requests to go to the Session Tab (UC02) to view the list of existing sessions in the Session View.

  2. TA-Tracker switches to the Session Tab.

  3. User requests to filter sessions specific to date/module code/session type.

  4. TA-Tracker retrieves a list of sessions containing the keyword in any of their fields.

  5. TA-Tracker shows the list of sessions.

    Use case ends.

Extensions

  • 3a. The search did find any matches.

    • 3a1. TA-Tracker shows an error.

      Use case resumes at step 3.

Claims View

Use case: UC22 - Changing the hourly pay rate

MSS (Contributed by Fatin)

  1. User requests to change the hourly pay rate to a specified amount.

  2. TA-Tracker changes the pay rate and adjusted the total earnings to reflect the new pay rate.

  3. TA-Tracker switches to the Claims Tab.

    Use case ends.

Extensions

  • 1a. The given rate is invalid.

    • 1a1. TA-Tracker shows an error message.

      Use case resumes at step 1.

Use case: UC23 - Filtering under Claims View

MSS (Contributed by Chua Yi Jing)

  1. User requests to go to the Claims Tab (UC02) to view the list of existing claims in the Claims View.

  2. TA-Tracker switches to the Claims Tab.

  3. User requests to filter claims specific to module code.

  4. TA-Tracker retrieves a list of claims containing the keyword.

  5. TA-Tracker shows the list of claims.

    Use case ends.

Extensions

  • 3a. The search did find any matches.

    • 3a1. TA-Tracker shows an error.

      Use case resumes at step 3.

Statistic Report Window

Use case: UC24 - Displaying a statistic report

MSS (Contributed by Haoyi)

  1. User requests to generate and display a statistic report.

  2. TA-Tracker retrieves the list of sessions and students from all modules and processes the data.

  3. TA-Tracker opens a Statistic window and displays the processed data to the user.

    Use case ends.

Extensions

  • 1a. User specifies a valid module code.

    • 1a1. TA-Tracker retrieves the list of sessions and students from the specified module and processes the data.

    • Use case resumes at step 3.

  • 1b. User specifies a module code that does not exist.

    • 1b1. TA-Tracker shows an error message.

      Use case resumes at step 1.

Appendix D: Non-Functional Requirements

(Contributed by Haoyi)

  1. TAT should be able to run on any mainstream OS as long as it has Java 11 installed.

  2. A user with above average typing speed should be able to accomplish most of the tasks using keyboard inputs faster than by using the mouse.

  3. A user should be able to easily see the commands that they have wrongly typed.

  4. TAT should be able to run with or without internet connection.

  5. TAT should work for a single user only.

  6. TAT should not require user to install.

  7. Features implemented should be testable using manual testing and automated testing.

  8. TAT should support screen resolution of 1920 x 1080 or higher.

  9. TAT should be able to save data locally.

  10. TAT should be able to save data in a human-editable file to allow advanced users to manipulate the dat by editing the file.

Appendix E: Glossary

(Contributed by Haoyi)

Term Explanation

TSS

This is the short form for Teaching Support Student.

TSS Claims Form

This refers the claims form that Teaching Assistants at NUS School of Computing have to fill up at the end of each semester to claim money for the tasks they have completed.

TA

This is the short form for `Teaching Assistant.

SOC or SoC

This is the short form for School of Computing.

Index

This refers to the position of an item on a list. For example: Index of 1 refers to the first item in a list.

Matric Number

This refers to a student’s matriculation number. For example: A0123456X

Group

The is the general term given to a group of students a TA teaches. For example: lab, tutorial

TAT

This is the short form of TA-Tracker.

NUS

This is the short form of National University of Singapore.

Module

Refers to one of the academic courses in NUS.

Tutorial

A tutorial is a regular meeting between a tutor and one or several students, for discussion of a subject that is being studied.

API

Stands for "Application Programming Interface" which simplifies programming by abstracting the underlying implementation and only exposing objects or actions the developer needs.

PlantUML

Stands for a software tool that we use to render the diagrams used in this document.

NFR

Stands for "Non-functional Requirement"

Mainstream OS

Stands for commonly used Operating Systems (OS) such as Windows, Linux, Unix, OS-X.

MSS

Stands for Main Success Scenario that describes the interaction for a given use case, which assumes that nothing goes wrong.

Appendix F: Instructions for Manual Testing

(Contributed by Aakanksha and Fatin)

Given below are instructions to test the app manually. These instructions will help you navigate through the app and get an idea of what to test. We suggest you use this in conjunction with our User Guide to test the product thoroughly.

These instructions only provide a starting point for testers to work on; testers are expected to do more exploratory testing.

All of these test cases assume that you have launched TA-Tracker for the first time and have not changed the sample data provided for you. We also assume that you are doing the tests in this order. Therefore modules added in previous steps can be used, etc.

Launch and Shutdown

  1. Initial launch

    1. Download the jar file and copy into an empty folder

    2. Open the folder containing the jar and enter the command java -jar TaTracker.jar in the terminal
      Expected: TA-Tracker should start in a few seconds.

  2. Saving window preferences

    1. Resize the window to an optimum size. Move the window to a different location. Close the window.

    2. Re-launch the app by following the steps you did in the previous test
      Expected: The most recent window size and location is retained.

  3. Default view

    1. Switch to a tab different from the student tab. Close the window.

    2. Relaunch the app
      Expected: The student view under the student app is shown.

Viewing help

  1. Opens the help window.

    1. Test Case: help
      Expected: Opens the help window.

Changing Tabs

  1. Changes the tab.

    1. Test Case: goto session
      Expected: Opens the session tab.

    2. Test Case: goto claims
      Expected: Opens the claims tab.

    3. Test Case: goto student
      Expected: Opens the student tab.

Adding a module

  1. Adding a module from any view.

    1. Test Case: module add m/CS1101S n/Programming Methodology I
      Expected: A module with the module code CS1101S and name Programming Methodology I is added to the module list in the Student View. If you were on a different tab, you are automatically switched to the Student View.

    2. Test Case: module add m/CS1101S n/PE2
      Expected: You will see an error message that this module already exists. (Assuming you have added a module with module code CS1101S)

Adding a group to a module

  1. Adding a group to a module.

    1. Test Case: group add g/G07 m/CS1101S t/tutorial
      Expected: A group with group code G07 of type tutorial will be added to the module CS1101S. If you were on a different tab, you are automatically switched to Student View.

    2. Test Case: group add g/G08 m/CS1101S t/lab
      Expected: A group with group code G08 of type lab will be added to the module CS1101S. If you were on a different tab, you are automatically switched to Student View.

    3. Test Case: group add g/G07 m/CS3243 t/lab
      Expected: A group with group code G07 of type lab will be added to the module CS3243. If you were on a different tab, you are automatically switched to Student View.

    4. Test Case: group add t/tutorial m/CS3243 g/G08
      Expected: A group with group code G08 of type lab will be added to the module CS3243. If you were on a different tab, you are automatically switched to Student View.

    5. Test Case: group add g/G07 m/CS3243 t/tutorial
      Expected: You will see an error message saying that this group already exists in the module. (Assuming you added a group with group code G07 to the module CS3243)

    6. Test Case: group add g/G07 m/CS2030 t/lab
      Expected: You will see an error message saying that this module does not exists in the module. (Assuming that you have not added a module with module code CS2030)

    7. Test Case: group add g/G07 m/CS3243 t/lunch
      Expected: You will see an error message saying that provided group type was not valid.

Adding students to a group

  1. Adding a student to a group.

    1. Test Case: student add id/A0184721X g/G06 m/CS3243 n/Jane Doe
      Expected: A student named Jane Doe with matriculation number 0184721X is added to the group G06 of the module CS3243 with a default rating of 3.

    2. Test Case: student add id/A0184121E g/G06 m/CS3243 n/John Doe r/5
      Expected: A student named John Doe with matriculation number A0184121E is added to the group G06 of the module CS3243 with a rating of 5.

    3. Test Case: student add id/A0184121E g/G06 m/CS3243 n/Donald Trump r/5
      Expected: You will see an error message saying that this student already exists in the group. (Assuming you added a student with matriculation number A0184121E into the group G06, which in turn is inside the module CS3243)

Editing a module’s name

  1. Edits the name of a module.

    1. Test Case: module edit m/CS3243 n/New Name Expected: The name of the module with module code CS3243 will change to New Name but the groups and students inside it will remain intact.

Editing a group

  1. Editing a group in a module.

    1. Test Case: group edit g/G06 m/CS3243 nt/tutorial
      Expected: The group with group code G06 will be changed to type tutorial inside the module CS3243. The students inside the group will be unchanged. If you were on a different tab, you are automatically switched to Student View.

Editing a student

  1. Editing a student in a group.

    1. Test Case: student edit g/G06 m/CS3243 id/A0187613T r/5
      Expected: Changes the rating of the student with matric number A123456X to 5.

Viewing a specific module

  1. Allows you to view groups in a particular module.

    1. Test Case: student filter m/CS2103T Expected: You can now view the groups of the module CS2103T. You will see the students of the group at index 1 of the module’s group list.

Viewing a specific group

  1. Allows you to view students in a particular group of a particular module.

    1. Test Case: student filter g/G03 m/CS2103T Expected: You can now view the groups of the module CS2103T. You will see the students of the group G03.

Sorting a group

  1. Sorting students in a group.

    1. Test Case: sort group g/G03 m/CS2103T t/alpha
      Expected: Sorts all the students in the group G03 of the module CS2103T alphabetically.

Sorting a module

  1. Sorting students in a module.

    1. Test Case: sort module m/CS2103T t/alpha
      Expected: Sorts all the students in all the groups of the module CS2103T alphabetically. You will see the students in the group at index 1 of the group list of the module CS2103T.

Sorting all modules

  1. Sorting students in all modules.

    1. Test Case: sort all t/alpha
      Expected: Sorts all the students in all the groups of all modules alphabetically. You will see the students in the group at index 1 of the group list of the module at index 1 of the module list.

Adding a session

  1. Adding a session to the session list.

    1. Test Case: session add m/CS2103T s/14:00 e/16:00 d/2020-06-20 w/2 t/consultation n/with Alice and Bob
      Expected: A session starting at 14:00 and ending at 16:00 on 2020-06-20, which has also been set to recur every two weeks, will be added to the sessions list. It will be associated with the module CS2103T and be a consultation with Alice and Bob.

    2. Test Case: session add m/CS2103T s/14:00 e/16:00 d/2020-06-20 w/2 t/consultation n/with Alice and Bob
      Expected: A duplicate session will be added to the session list (Assuming you have entered the same command previously)

Marking a session as done

  1. Marking a session as done.

    1. Test Case: session done 1
      Expected: Marks the session at index 1 of the session list as done. If it is a recurring session, a new session will be added in its place, dated after the recurring period. The session marked as done will be added to the claims list.

Deleting a session

  1. Deleting a session.

    1. Test Case: session delete 1
      Expected: Deletes the session at index 1 of the session list.

Editing a session

  1. Editing a session

    1. Test Case: session edit 1 t/lab
      Expected: Edits the session at index 1 of the session list to be of type lab.

Filtering sessions

  1. Filtering sessions based on keywords.

    1. Test Case: session filter m/CS3243
      Expected: Shows all sessions associated with the module CS3243.

    2. Test Case: session filter t/tutorial
      Expected: Shows all sessions that are of type tutorial.

    3. Test Case: session filter d/2020-03-20
      Expected: Shows all sessions on the date 2020-03-20.

    4. Test Case: session filter d/2020-03-20 t/tutorial m/CS1101S
      Expected: Shows all sessions that contains date 2020-03-20, session type tutorial or module code CS1101S.

Filtering claims

  1. Filtering claims by module code.

    1. Test Case: claims filter m/CS3243
      Expected: Shows all sessions that have been marked as done (aka claims) associated with the module CS3243.

Listing sessions and claims

  1. Lists all sessions and claims again (removes all filters that have been previously applied).

    1. Test Case: list
      Expected: Shows all sessions and claims that have previously been filtered.

Changing rate

  1. Setting the hourly rate.

    1. Test Case: setrate 25
      Expected: Sets the rate of the claims to be 25$ per hour. Money computation is changed accordingly.

Viewing statistics

  1. Displays the statistics window.

    1. Test Case: report
      Expected: Displays the statistics report showing statistics of all modules.

    2. Test Case: report CS2103T
      Expected: Displays the statistics report of the module CS2103T.

Applying syntax highlighting on the user input

(Contributed by Gabriel)

  1. Highlighting the full command word.

    1. Test Case: module delete
      Expected: The input is highlighted in green, and the command usage is displayed.

    2. Test Case: module d
      Expected: The input is highlighted in red, and an unknown command message is displayed.

  2. Showing the command usage after every two whitespaces.

    1. Test Case: `module delete m/CS3243 `
      Expected: The input is not highlighted, and the command usage is displayed.

  3. Showing the usage of each argument.

    1. Test Case: student add id/A1234J
      Expected: The input is highlighted in red, and the constraint for matric numbers is displayed.

    2. Test Case: student add id/A1234567J
      Expected: The input is highlighted in green, and the constraint for matric numbers is displayed.

    3. Test Case: student add id/A123J m/CS3243 id/A1234567J
      Expected: The input is highlighted in red, and the constraint for matric numbers is displayed. This is because the syntax highlighting detects invalid parameters in the user input, even though the command can be executed.

    4. Test Case: student add w/5
      Expected: The input is highlighted in red, and the command usage is displayed.

  4. Showing the usage of preambles.

    1. Test Case: session edit m/CS3243
      Expected: The input is highlighted in red, and the constraint for index numbers is displayed.

Deleting a module

  1. Deleting a module.

    1. Test Case: module delete m/CS3243
      Expected: Assuming you already had a module with module code m/CS3243 in your TA-Tracker, this would delete the module with module code m/CS3243. This would also delete all groups, students and sessions related to this module.

    2. Test Case: module delete m/CS3243
      Expected: Assuming you already deleted the module with module code m/CS3243 from your TA-Tracker, this would show you an error message.

Deleting a student

  1. Deleting a student from a group

    1. Test Case: student delete g/G02 m/CS2103T id/A0181137L
      Expected: Deletes the student with matric number A0181137L from the group G02 of the module CS2103T.

Deleting a group

  1. Deleting a group from a module.

    1. Test Case: group delete g/G02 m/CS2103T
      Expected: The group with group code G02 will be deleted from the module CS2103T. The students inside the group will be deleted.

Exiting the program

  1. Exiting the program.

    1. Test Case: exit
      Expected: Exits the program.

Appendix G: Effort

(Contributed by Fatin and Aakanksha)

Creating this application was fairly difficult and required much blood, toil, tears and sweat. Cumulatively, the project amasses a great 20,000 lines of code combined. This meant that it required a great deal of communication and discussion amongst all parties, which was especially difficult due to the quarantine measures that resulted from the on-going COVID-19 situation. However, the 5 of us persevered and remedied the situation by holding regular video conferences to replace our weekly group meetings.

While AB3 deals with only one entity, this application deals with multiple entities.

  • AB3 contains only Person. While we were able to refactor some aspects of Person into Student, we had to create Session, Group and Module from scratch.

  • The UI of AB3 only contains one ListPanel. On the other hand, TA-Tracker has 5 ListPanels spread out in 3 views - the StudentView, SessionView and ClaimsView. This is a big change from AB3’s UI.

  • We also have a StatisticsWindow in addition to our `HelpWindow, which is significantly more appealing than the AB3 HelpWindow.

Furthermore, TA-Tracker’s additional features such as automated tab switching, filtering, sorting and syntax highlighting meant that our app varies greatly from what AB3 has to offer in terms of user experience. These carefully thought out features were designed primarily with the user’s needs in mind, to provide the user with a platform that would greatly improve the efficiency of tracking duties as a TA.

Due to our inexperience with UI work, we had initially planned the StudentView to look very different. Therefore, the way it was initially implemented differed significantly from the current one. Once we became more familiar with JavaFX, we realised that our initial plan was no longer feasible within our given timeframe. As a result, we had to change the implementation of StudentView. Furthermore, a lot of supporting methods were required to allow the UI to work the way it does.

Another challenge we faced was that we were unaware of restrictions regarding temporal-based features. Two of our features relied heavily on timing, and as a result, they had to be scrapped from the project. This also resulted in our group having to do a lot of last-minute brainstorming to come up with ideas for new features as replacements. Fortunately, we managed to pull through by designing a highly useful StatisticsWindow to improve upon our current application.

During this whole process, we took great pains to ensure that the code quality of our code-base was upheld by verifying every pull request that we make with thorough peer reviews from at least one other party. Nonetheless, our actions paid off as we managed to maintain a Codacy rating of A throughout the project.