Yong Han Ching - Project Portfolio

Add a consultation slot at the given time, date and place.
Format: addConsult student/STUDENT_INDEX beginDateTime/BEGIN_DATE_TIME endDateTime/END_DATE_TIME place/PLACE

Example:

Edit the time, date or place of an existing consultation slot.
Format: editConsult INDEX [beginDateTime/BEGINDATETIME] [endDateTime/ENDDATETIME] [place/PLACE]

Example:

Shows a list of all consultations in TAble.
Format: listConsult

Removes an existing consultation slot.
Format: deleteConsult INDEX

Example:

Clears all consultations slots in TAble.
Format: clearConsults

Finds consultations whose date or place match any of the given keywords.
Format: findConsult [DATE] [PLACE]

Examples:

Brings up the calendar window. Format: viewCalendar

Closes the calendar window. Format: closeCalendar

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.

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.