TAble - Developer Guide

A Student class stores all relevant information of students. The main components are the students’ name, matric number, email address. Student can also store the user’s remarks about the student through the tag parameter, which will sort the tags, if there are more than 1 tag, in alphabetical order. The class diagram below shows how all the different components interact to allow the student feature to function.

Referencing the above class diagram, a Student contains 4 key attributes, the student’s name, matricNumber, email, and a set<Tag> of Tag, which could be empty. The unique identifier of each student is the matricNumber, i.e. no two students in TAble can have the same matric number.

The following sequence diagram illustrates the findStudentMatricNumber command, where a student which has the same matric number as the given matric number is found. The user must key in a correctly formatted matric number.

Referencing the above sequence diagram, LogicManager executes the user’s input and calls parseCommand(input) of TAbleParser. TAbleParser then returns a new FindStudentMatricNumberCommandParser(). Via FindStudentMatricNumberCommandParser, the provided matric number is parsed into a MatricNumberContainsKeywordsPredicate predicate and a FindStudentMatricNumberCommand object with the MatricNumberContainsKeywordsPredicate predicate is created. Calling updateFilteredStudentList(predicate), the provided matric number is compared against the matric number of students currently in TAble and the student list is then updated with the list of students whose matric number matches the provided matric number. The command returns a formatted string which shows how many students match the given matric number, which indicate that the command is called successfully

The following activity diagram illustrates what happens when the addStudent command is called to add a student into TAble. There is a need to check that the given matric number and email address does not already exist in TAble

Referencing the above activity diagram, TAble will first check that all prefixes are present and formatted correctly, and that no multiple of the same prefix exists. It will then proceed to check if the name, matric number, email address, and tags (if any) are formatted correctly. It will then create a Student object using the provided name, matric number, email address, and tags (if any) and then check if there is a duplicate student inside TAble. If there are no duplicate student inside TAble, it will check across every student in TAble to see if the provided matric number or email address already exists inside TAble. If the provided matric number or email address does not belong to any student inside TAble already, the created student is then added into TAble and a message is returned indicating success. The new student will appear in the TAble.

A module can be stored as a Mod object in TAble (renamed due to naming restrictions on Java keywords). The main components are the module code, which is used to identify unique modules, and module name. Mod can also store the user’s notes of the module through its description parameter, as well as a list of module links which are relevant to the course.

The following sequence diagram shows how notes of a module can be updated with the noteMod command. Each command is parsed into a ModCode object and the note stored as string. The ModCode is then used to retrieve the appropriate Mod object in model. Next, this is used in the Mod constructor to come up with a new Mod with the given note. This new Mod replaces the original Mod in model and the command returns a string indicating success.

Module links are stored as ModLink objects in TAble. The collection of ModLinks are stored as List<ModLinkPair> (where a ModLinkPair is actually a class wrapper for a Pair<String, ModLink> object) since each module link can be described differently. This allows for more flexibility in naming the module links, rather than solely using an index based notation, and ensures that the order of addition into the collection is maintained. The activity diagram of adding module links is shown below.

Users can then view the information associated with a Mod object by using the viewModInfo command, and copy module links with the copyModLink command. Discussion on the copyModLink command is shown below.

Since a Tutorial in TAble has to manage many parameters and attributes, different components of TAble were distinctly separated in order to ensure maintainability and adhere to good coding practices. The following illustrates the sequence diagram for AddTutorialCommand, in which a tutorial is added to TAble.

The LogicManager is responsible for handling the execution of the user’s input command to add a tutorial, calling parseCommand(), which returns an AddTutorialCommand object and subsequently calls for the AddTutorialCommand object to perform execute(). This leads to the Model being updated accordingly, and feedback in the form of a formatted String is finally shown to the user after being returned from AddTutorialCommand.

As can be observed, each step of the process is clearly separated, with each component only responsible for single task (eg. parsing user input, executing the actual command etc.) This enables bugs to be easily caught, and for the process to be structured and comprehensible.

As a Tutorial in TAble should be able to keep track of enrolled students and mark their attendance, the Tutorial object will have to contain a list of Student objects (ie. the enrolled students). However, a Student object, as we are implementing it, does not contain the attribute of whether they are present or not for a particular tutorial.

Reason for choosing Alternative 2: From a user design perspective, it is more likely that a teaching assistant will want to mark his attendance by tutorial and week rather than by student, hence it is more practical and efficient to choose Alternative 2. From a software engineering perspective, it is the responsibility of the Tutorial to keep track of the attendance, not the Student 's. This allows attendance of a Student to be easily referenced and marked in a Tutorial without requiring the Student to be privy to that information, and allows for convenient retrieval of attendance by week or by student.

As such, the following activity diagram of the system illustrates what occurs when the user calls the markPresent command to mark a student in a tutorial as present, for a specified week in the school semester.

When executing the markPresent command, the system will first ensure that all prefixes are present and formatted correctly, before subsequently checking if the specified tutorial exists in the TAble database. If the tutorial does exist, then the system attempts to retrieve and update the attendance of the respective student in the tutorial. If the student does not exist, an error message is shown, informing the user. If successful, the updated information is then saved.

A Consult class stores all of the relevant information of consults. The class diagram below shows how all the different components interact to allow the consult feature to function. Note that the XYZConsultCommand and XYZConsultCommandParser refers to all Consult related commands like add, edit, delete etc.

A consultation slot is represented by the Consult class which contains 5 key attributes, the beginDateTime, endDateTime, location, studentMatricNumber and studentName. The beginDateTime and endDateTime attributes are represented using Java’s LocalDateTime class. The studentMatricNumber and studentName attributes are classes that belong to a certain Student. The studentMatricNumber is used to uniquely identify the Student involved in the consultation, while the studentName is used in the front end of the application, displayed to the TA.

The XYZConsultCommand class represent classes that extend the abstract class Command and allows the TA to add, edit, delete, view and clear consultations added to TAble. These XYZConsultCommandS are created by the respective XYZConsultCommandParserS.

A ConsultTAble that has a UniqueConsultList stores and manages all ConsultS. When a Consult is added to the ConsultTAble, there will first be a check that the Consult does not already exist in the UniqueConsultList.

Given the class diagram and the understanding of how the Consult class interacts with other classes, let us examine how an addConsult command behaves, by using the following activity diagram of the system.

The workflow above shows how a Consult is added and the various checks that occurs at the different points throughout the workflow.

To summarize the above activity diagram, there are 5 key checks which TAble checks for when the user is adding a consult. Firstly, TAble checks if all 4 prefixes are present in the command. Then, TAble checks if all prefixes present are formatted correctly. Following which, TAble will check if each of the data passed for the prefixes are in the right format. Firstly, it checks if the Student index provided is within the range of the Student list. Then, it checks if the timing and Location provided are in the correct format. Lastly, and most importantly, it checks if the Consult timing provided clashes with other existing Consult timings.

A reminder is made up of a description, date and time which uniquely identify each reminder. Each reminder has a boolean attribute to indicate if the task is done.

To find a reminder in the reminder list, user must key in at least one of the optional predicates, DescriptionContainsKeywordsPredicate or DatePredicate. DescriptionContainsKeywordsPredicate contains a list of strings entered by the user while DatePredicate contains the input LocalDate.

The list of strings are matched against the description of the reminders in the reminder list while the LocalDate is matched against the date field. The reminder list is then updated with the list of matching reminders via updatedFilteredReminderList in Model. Below shows a sequence diagram of the execution.

A snooze reminder feature is also implemented for the users to easily postpone a reminder. It’s implementation is similar to the editReminderCommand where it creates a new reminder to replace the specified reminder instead of editing the current reminder directly. This is to ensure the reminders are immutable which improves the stability of the application.

User can choose to snooze the reminder in any/all of the following time units: days, hours and/or minutes. Only positive integer are allowed as the user are not supposed to snooze the reminders backwards or snooze it by zero duration. Reminders that are done are also not allowed to be snoozed. Following is an activity diagram for the command.

The key command which users can call is the viewCalendar command.

Most functions to display the calendar window are called within the CalendarWindow class, as it is the main class that drives the calendar view. The CalendarWindow class extends UiPart<Stage>, and represents the calendar using a GridPane as the skeleton of the calendar, with individual dates being populated by a CalendarDay class which extends UiPart<Region>. The CalendarDay has a StackPane that displays the number of ConsultS, TutorialS and ReminderS each day.

The following sequence diagram demonstrates how the Calendar is initialised, each time the TAble app is set up.

The above sequence diagram illustrates how the Calendar is initialised when the TAble app is start up. Thus, whenever the user inputs the viewCalendar command, this calendar window is brought up, similar to how the Help window is brought up as well. The calendar window brought up will show the calendar view of the current month and year.

The calendar window also stores the UniqueConsultList, UniqueTutorialList and the UniqueReminderList. As seen in the sequence diagram above, the calendar window checks for the consults, tutorials and reminders in the 3 lists, to see if they are on a particular date. If they occur on that date, the StackPane in CalendarDay will be updated to reflect the corresponding number of consults, tutorials and reminders. As seen in the screenshot below, the number of reminders, tutorials and consults will not clash, as they take up the top, middle and bottom rows respectively.

Reason for choosing Alternative 1: We believe that the user experience will be better when using more descriptive command prefixes, as the user will not be required to constantly check on the user guide since the command prefixes are intuitive. Furthermore, TAble comes with the autocomplete feature which removes the hassle of typing out long prefixes.