Teacher’s Notebook - Developer Guide

The AutoComplete feature is facilitated by 2 classes: the AutoCompleteTextField, and the class Styles. Both are represented in the class diagram below.

The AutoCompleteTextField adds a ChangeListener to textProperty() that notifies AutoCompleteTextField whenever the user inputs new text, i.e when the text entered changes.

Step 1. User triggers the listener when user enters text.

Step 2. From the text entered, AutoCompleteTextField attempts suggesting existing commands. If input matches any existing commands, it proceeds to step 3. Otherwise, it does nothing and waits for user input.

Step 3. AutoCompleteTextField calls `Styles#buildTextFlow`to highlight the portion of each command suggestion where the user’s input matches the suggestion.

Step 4. AutoCompleteTextField then displays a popup menu using the javafx class ContextMenu.

Step 5. If the user selects a suggestion, the textfield is set to that suggestion, and the popup menu is closed. If the user enters more text, AutoCompleteTextField returns to step 1.

Step 6. Otherwise, the popup menu is closed.

This sequence of steps is illustrated below with an activity diagram.

The uploading of a student’s picture is facilitated by UploadPictureCommandParser, UploadPictureCommand, ModelManager, FileChooser and DisplayPicture, while the displaying of the student’s picture is facilitated by MainWindow and StudentCard.
UploadPictureCommandParser implements Parser. UploadPictureCommand extends Command, and represents the logic that will be executed once the user activates the upload command and chooses a file.
The UploadPictureCommand command communicates with ModelManager to replace the old Student object with a new Student object that has its display picture field changed.

This change is then reflected in the UI when MainWindow loads the StudentCard for the new student, which will load the image and display it in the UI.

The main operation implemented is UploadPictureCommand#execute.

Step 1. The user wants to upload a display picture for their student. User identifies the student’s index number and enters the command upload INDEX.

Step 2. MainWindow detects the upload command word and uses FileChooser to open a window for the user to select a picture from their computer. MainWindow then saves the path of the selected file as a string and adds a prefix "f/" to the input arguments. The path of the file is also appended to the end of the input string before the input arguments are passed to NotebookParser

Step 3. NotebookParser parses the input and detects the upload command word, and calls UploadPictureCommandParser. This in turn checks user’s input for errors before calling UploadPictureCommand, which checks whether the file is a PNG or JPG file.

Step 4. LogicManager executes the UploadPictureCommand, which checks the validity of the index provided, as well as whether the picture selected is different from the picture already displayed. A visual representation of the order of checks for the input arguments are displayed in the diagram below.

Step 5. After these checks, the createEditedStudent method in UploadPictureCommand is called to create a new Student object, editedStudent, which has its display filepath changed to the file the user chose.

Step 6. UploadPictureCommand calls Model to replace the current student with the editedStudent. The command result is then passed back all the way to MainWindow which refreshes the GUI, and displays the new picture for the chosen student.

The following diagram illustrates the process above.

The undo/redo mechanism is facilitated by Caretaker, with each notebook state saved as a Memento. It extends Notebook with an undo/redo history, stored internally as an mementos and statePointer. Additionally, it implements the following operations:

These operations are exposed in the Model interface as Model#saveState(), Model#undo() and Model#redo() respectively.

Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.

Step 1. The user launches the application for the first time. The Caretaker will be initialized with the initial notebook state, and the statePointer pointing to that single notebook state.

Step 2. The user executes deletestudent 5 command to delete the 5th student in the current classroom. The deletestudent command calls Model#saveState(), causing the modified state of the notebook after the deletestudent 5 command executes to be saved in the mementos, and the statePointer is shifted to the newly inserted notebook state.

Step 3. The user executes addstudent n/David …​ to add a new student. The addstudent command also calls Model#saveState(), causing another modified notebook state to be saved into the mementos.

Step 4. The user now decides that adding the student was a mistake, and decides to undo that action by executing the undo command. The undo command will call Model#undo(), which will shift the statePointer once to the left, pointing it to the previous notebook state, and restores the notebook to that state.

The following sequence diagram shows how the undo operation works:

The redo command does the opposite — it calls Model#redo(), which shifts the statePointer once to the right, pointing to the previously undone state, and restores the notebook to that state.

Step 5. The user then decides to execute the command liststudents. Commands that do not modify the classroom, such as liststudents, will usually not call Model#saveState(), Model#undo() or Model#redo(). Thus, the mementos remains unchanged.

Step 6. The user executes clear, which calls Model#saveState(). Since the statePointer is not pointing at the end of the mementos, all notebook states after the statePointer will be purged. We designed it this way because it no longer makes sense to redo the addstudent n/David …​ command. This is the behavior that most modern desktop applications follow.

The following activity diagram summarizes what happens when a user executes a new command:

The Assignment class works with high similarity to the Student Class implemented. A UniqueList of Assignments exist in the Classroom Class alongside the UniqueList of Students, and serve to keep track of assignments for a particular Classroom. The commands that work in similar fashion to Student Class are:
AddAssignment, DeleteAssignment, EditAssignment, ListAssignment

Additionally, it implements the following operations:

The Assignment class keeps track of the grades of all students in the class for a particular assignment. This feature is necessary to users to monitor the progress of every student, and to provide assistance to students who might be failing their tests. Each Assignment contains the following classes: AssignmentName, AssignmentGrade, and AssignmentDeadline.

Upon creation of a new Assignment, Assignment#initialiseGrades() is called, which populates the LinkedHashMap with keys (students' names) and the value "Not Submitted". The user can then update the grades of a student individually or all of the students simultaneously through the UpdateGrades command, which calls the method Assignment#setGrades().

After every command, Assignment#checkCompletion() is called to determine the completion status of the assignment, which will be "Completed" if none of the grades are "Not Submitted". Upon addition of a new student into the classroom, each Assignment present in the classroom will add another entry into the AssignmentGrade. If the Assignment was Not Completed, the value "Not Submitted" will be paired with the key through the method Assignment#addNewStudentGrade. Should the Assignment have been Completed, the value "Late to the party" will be paired instead through the method Assignment#addOneStudentGrade, indicating that the student does not need to submit said assignment any longer, since it has already been graded before he/she joined the classroom.

The current GetStudentGradesCommand will retrieve all the grades of a particular student. This is done through iterating through the FilteredAssignmentList, and pulling all the grades of a specified student. Additionally, it implements the following operations through Commands:

The following sequence diagram shows how the get grades operation works:

After getting the Map from the getGrades() method, if the key of the current key-value pair is equals to the name of the student, the value, which is the grades of the student, will be added to the output that will be shown in the CommandResult.

The implementation for getting unsubmitted assignments is similar to the get submitted feature, except that it will search for values of "Not submitted." instead.

The following activity diagram shows how the get unsubmitted operation works:

The Lesson class works with high similarity to the Student Class implemented. A UniqueList of Lessons exist in the Notebook alongside the UniqueList of Classrooms, and serve to keep track of lessons for the user. Additionally, it implements the following operations through Commands:

When a new Lesson is added to the UniqueLessonList, a listener attached to the list will be triggered and it will create a scheduler to schedule the lesson. Once the timing of lesson is reached, an alert box will be created in the GUI to serve as a reminder.

The following activity and sequence diagram shows how the scheduling operation works: