Developer Guide

• Acknowledgements
• Setting up, getting started
• Design
  • Architecture
  • UI component
  • Logic component
  • Model component
  • Storage component
  • Common classes
• Implementation
  • Managing appointments
    • Implementation
  • Notes for students
    • Implementation
  • Duplicate contacts
    • Implementation
  • Listing Students
    • Implementation
  • [Proposed] Undo/redo feature
    • Proposed Implementation
    • Design considerations:
• Documentation, logging, testing, configuration, dev-ops
• Appendix: Requirements
  • Product scope
  • User stories
  • Use cases
  • Non-Functional Requirements
  • Glossary
• Appendix: Instructions for manual testing
  • Launch and shutdown
  • Deleting a person
  • Viewing all appointments / appointments on a specific day
  • Viewing details of a person
  • Saving data
• Appendix: Planned Enhancements

---

Acknowledgements

• Existing AB3 code structure and implementation was referenced for new TutorRec features.

---

Setting up, getting started

Refer to the guide Setting up and getting started.

---

Design

Architecture

The Architecture Diagram given above explains the high-level design of the App.

Given below is a quick overview of main components and how they interact with each other.

Main components of the architecture

Main (consisting of classes Main and MainApp) is in charge of the app launch and shut down.

• At app launch, it initializes the other components in the correct sequence, and connects them up with each other.
• At shut down, it shuts down the other components and invokes cleanup methods where necessary.

The bulk of the app’s work is done by the following four components:

• UI: The UI of the App.
• Logic: The command executor.
• Model: Holds the data of the App in memory.
• Storage: Reads data from, and writes data to, the hard disk.

Commons represents a collection of classes used by multiple other components.

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 issues the command delete 1.

Each of the four main components (also shown in the diagram above),

• defines its API in an interface with the same name as the Component.
• implements its functionality using a concrete {Component Name}Manager class (which follows the corresponding API interface mentioned in the previous point.

For example, the Logic component defines its API in the Logic.java interface and implements its functionality using the LogicManager.java class which follows the Logic interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent outside component’s being coupled to the implementation of a component), as illustrated in the (partial) class diagram below.

The sections below give more details of each component.

UI component

The API of this component is specified in Ui.java

The UI consists of a MainWindow that is made up of parts e.g.CommandBox, ResultDisplay, PersonListPanel, StatusBarFooter etc. All these, including the MainWindow, inherit from the abstract UiPart class which captures the commonalities between classes that represent parts of the visible GUI.

PersonCard strictly represents a UI element depicting a Person object as found in the Model component.

ResultDisplay is used to display any kind of output generated by commands. This includes command execution success/fail messages, command execution results and help messages. Command execution results vary depending on the command executed.

The UI component uses the JavaFx UI framework. The layout of these UI parts are 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.
• keeps a reference to the Logic component, because the UI relies on the Logic to execute commands.
• depends on some classes in the Model component, as it displays Person object residing in the Model.

Logic component

API : Logic.java

Here’s a (partial) class diagram of the Logic component:

The sequence diagram below illustrates the interactions within the Logic component, taking execute("delete 1") API call as an example.

How the Logic component works:

1. When Logic is called upon to execute a command, it is passed to an AddressBookParser object which in turn creates a parser that matches the command (e.g., DeleteCommandParser) and uses it to parse the command.
2. This results in a Command object (more precisely, an object of one of its subclasses e.g., DeleteCommand) which is executed by the LogicManager.
3. The command can communicate with the Model when it is executed (e.g. to delete a person).
   Note that although this is shown as a single step in the diagram above (for simplicity), in the code it can take several interactions (between the command object and the Model) to achieve.
4. The result of the command execution is encapsulated as a CommandResult object which is returned back from Logic.

Here are the other classes in Logic (omitted from the class diagram above) that are used for parsing a user command:

How the parsing works:

• When called upon to parse a user command, the AddressBookParser class creates an XYZCommandParser (XYZ is a placeholder for the specific command name e.g., AddCommandParser) which uses the other classes shown above to parse the user command and create a XYZCommand object (e.g., AddCommand) which the AddressBookParser returns back as a Command object.
• All XYZCommandParser classes (e.g., AddCommandParser, DeleteCommandParser, …) inherit from the Parser interface so that they can be treated similarly where possible e.g, during testing.

Model component

API : Model.java

The Model component,

• stores the address book data i.e., all Person objects (which are contained in a UniquePersonList object) and all associated Appointment objects (which are contained in a DisjointAppointmentList).
• stores the currently ‘selected’ Person objects (e.g., results of a search query) as a separate filtered list which is exposed to outsiders as an unmodifiable ObservableList<Person> that 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.
• stores a UserPref object that represents the user’s preferences. This is exposed to the outside as a ReadOnlyUserPref objects.
• does not depend on any of the other three components (as the Model represents data entities of the domain, they should make sense on their own without depending on other components)

Storage component

API : Storage.java

The Storage component,

• can save both address book data and user preference data in JSON format, and read them back into corresponding objects.
• inherits from both AddressBookStorage and UserPrefStorage, which means it can be treated as either one (if only the functionality of only one is needed).
• depends on some classes in the Model component (because the Storage component’s job is to save/retrieve objects that belong to the Model)

Common classes

Classes used by multiple components are in the seedu.addressbook.commons package.

---

Implementation

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

Managing appointments

Implementation

A core feature of TutorRec is the ability to add appointments to a contact. Appointments are added with the field (/ap) when doing an add or edit command, for instance:

• add n/John Doe /ap 12:00-13:00 MON will add a person with the name “John Doe” and an appointment on Monday from 12:00 to 13:00 to the contact list.

The following diagram describes the process of adding a valid Person appointment with the add command:

The appointments, after being parsed, are stored in a list of appointments within Person. This is implemented as an AppointmentList field. To prevent appointment overlap, we check both

1. Appointment overlap within Person’s AppointmentList and
2. Appointment overlap between the appointments in AppointmentList and the existing appointments in Model.

Note that certain details, such as other fields in a Person have been omitted for brevity.

Design Considerations

All existing appointments are stored in Model in a DisjointAppointmentList. We chose to make this distinction between AppointmentList and DisjointAppointmentList to allow for easy utility of AppointmentList in storing and working with parsed appointments.

Notes for students

Implementation

TutorRec is able to add notes to each student. They are added as a field (/nt) when doing an add or edit command, so something similar to:

edit 1 /nt "This student is very good at math, but struggles with English." will edit the person on index 1 to have the note “This student is very good at math, but struggles with English.”

Duplicate contacts

Implementation

In TutorRec, contacts are uniquely identified by their names. No two contacts can have the exact same name, ensuring that duplicate contacts are not created.

Case Insensitivity: Contact names in TutorRec are not case-sensitive. For example, ‘John Doe’ and ‘JOhn dOE’ are treated as the same name.

Whitespace Sensitivity: Unlike case sensitivity, whitespaces in names do affect differentiation. Thus, ‘Mary Anne’ and ‘Maryanne’ are recognized as distinct names due to the difference in whitespace.

Handling Potential Duplicates: Whenever a user attempts to add or edit a contact, TutorRec checks for names that might be similar by ignoring differences in case or whitespace. If a potential duplicate is detected, the user is warned when the contact is added.

Contact Information Flexibility: Unlike names, a contact’s phone number and email address do not have to be unique in TutorRec. This allows for scenarios where a single contact detail, such as a phone number or email, might be associated with multiple contacts, such as a parent with several children enrolled. This design decision facilitates easier management of family-related records, ensuring that it is permissible for different contacts to share identical contact information.

Listing Students

Implementation

TutorRec is also able to list all current students in the address book. Note that the command list does not modify the address book. Additionally, it does not take in any extra parameters. It can be simply called as follows:

• list will show all current students in the address book in the PersonListPanel

The example shown below will describe the process for listing all students during the list command.

[Proposed] Undo/redo feature

Proposed Implementation

The proposed undo/redo mechanism is facilitated by VersionedAddressBook. It extends AddressBook with an undo/redo history, stored internally as an addressBookStateList and currentStatePointer. Additionally, it implements the following operations:

• VersionedAddressBook#commit() — Saves the current address book state in its history.
• VersionedAddressBook#undo() — Restores the previous address book state from its history.
• VersionedAddressBook#redo() — Restores a previously undone address book state from its history.

These operations are exposed in the Model interface as Model#commitAddressBook(), Model#undoAddressBook() and Model#redoAddressBook() 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 VersionedAddressBook will be initialized with the initial address book state, and the currentStatePointer pointing to that single address book state.

Step 2. The user executes delete 5 command to delete the 5th person in the address book. The delete command calls Model#commitAddressBook(), causing the modified state of the address book after the delete 5 command executes to be saved in the addressBookStateList, and the currentStatePointer is shifted to the newly inserted address book state.

Step 3. The user executes add n/David …​ to add a new person. The add command also calls Model#commitAddressBook(), causing another modified address book state to be saved into the addressBookStateList.

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

The following sequence diagram shows how an undo operation goes through the Logic component:

Similarly, how an undo operation goes through the Model component is shown below:

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

Step 5. The user then decides to execute the command list. Commands that do not modify the address book, such as list, will usually not call Model#commitAddressBook(), Model#undoAddressBook() or Model#redoAddressBook(). Thus, the addressBookStateList remains unchanged.

Step 6. The user executes clear, which calls Model#commitAddressBook(). Since the currentStatePointer is not pointing at the end of the addressBookStateList, all address book states after the currentStatePointer will be purged. Reason: It no longer makes sense to redo the add 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:

Design considerations:

Aspect: How undo & redo executes:

• Alternative 1 (current choice): Saves the entire address book.
  • Pros: Easy to implement.
  • Cons: May have performance issues in terms of memory usage.
• Alternative 2: Individual command knows how to undo/redo by itself.
  • Pros: Will use less memory (e.g. for delete, just save the person being deleted).
  • Cons: We must ensure that the implementation of each individual command are correct.

---

Documentation, logging, testing, configuration, dev-ops

• Documentation guide
• Testing guide
• Logging guide
• Configuration guide
• DevOps guide

---

Appendix: Requirements

Product scope

Target user profile:

• busy home tutor for primary school students
• has a need to manage a large number of students
• prefer desktop apps over other types
• can type fast
• prefers typing to mouse interactions
• is reasonably comfortable using CLI apps

Value proposition: provides easy access to client info and organizes it in an efficient and readable way for day-to-day use, optimized for tutors that prefer CLI.

User stories

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

Priority	As a …​	I want to …​	So that I can…​
* *	new home tutor	have adding information be intuitive and logical	use the app without hassle
* *	new user	have a quick start guide	learn how to use the app
* *	new home tutor	follow a set syllabus for my clients
* *	new home tutor	be able to quickly create a student’s profile with their relevant information
* *	new home tutor	track the performance of my students	prove to their parents that they are improving and my effectiveness as a tutor
* * *	new home tutor	track all my appointments	reduce the chance I forget or double book myself
* *	new home tutor	keep track of my finances–such as which client has paid me for my work over a month	reduce my stress when it comes to keeping track of who has paid me for my work, and so forth.
* *	busy home tutor	seamlessly create new tasks	quickly and efficiently set up my daily routine
* *	busy home tutor	be reminded about my upcoming appointments for the day	not accidentally forget
* *	returning home tutor	re-implementation of more information in a large amount to be easy	add information en masse without stress
* *	home tutor with clients who are nearing exam season	properly ensure that they are improving as planned, and also allow them to set benchmarks that I can remember
* *	busy home tutor	block certain times out for lunch and dinner	not accidentally overwrite those times with an additional client
* * *	experienced home tutor	delete students I am no longer teaching on TutorRec	unclutter my interface
* * *	experienced home tutor	update student information and details	ensure accurate records are maintained
* * *	passionate home tutor	TutorRec to keep notes for each student	tailor my teaching style accordingly
* *	experienced home tutor with many students	ability to categorise students by skill level, subject or group (p1, p2, p3…)	quickly locate their information when needed
* *	experienced home tutor	flexibility to choose what to teach my students (custom lessons)	personalise each lesson for different students
* *	experienced home tutor	easily identify students with weak performance	focus on weaker students
* *	experienced home tutor	view a student’s records for the length of time I have tutored them
* *	experienced home tutor	get some insights and analytics on a student’s performance over time	further refine my teaching methods accordingly
* *	busy home tutor	quickly reschedule my appointments with my clients	fit my ever-changing schedule, preventing a large amount of hassle
* *	tutor who just received a new wave of clients	separate my old and new clients	keep the interface orderly and easy-to-follow
* * *	busy home tutor	make quick notes about my students	keep track of information specific to each client
* *	assignment-ridden home tutor	note cancellations in my schedule due to increased workload from my end	my schedule is accurate to reality
* *	wary home tutor	backup and import data	safeguard myself against potential data corruption and/or physical destruction of my devices
* *	home tutor with a new device	quickly transfer data from one device to another	prevent the pain of having to input previous data manually
* *	online tutor	organize sessions with students in a different country and automatically convert dates and times to my time zone
* *	online home tutor	keep Zoom links with sessions and other information about the student in one place
* *	online home tutor with students who are abroad	convert time at a glance	be on time for my student’s lessons
* * *	home tutor who just moved abroad	remove previous clients I cannot tutor due to the distance gap	keep my schedule clean
* *	home tutor who just moved abroad	ways of tagging my students	keep track of different needs arising due to cultural differences

Use cases

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

Use case: Delete a student

MSS

1. User requests to list students
2. TutorRec shows a list of students
3. User requests to delete a specific student in the list

4. TutorRec deletes the student

   Use case ends.

Extensions

• 2a. The list is empty.

  Use case ends.

• 3a. The given index is invalid.

  • 3a1. TutorRec shows an error message.

    Use case resumes at step 2.

Use case: Viewing appointments

MSS

1. User requests to view current appointments for the day

2. TutorRec shows a list of appointments for the day

   Use case ends.

Extensions

• 1a. The list is empty.

  Use case ends.

• 1b. User inputs an invalid day format as an input.

  • 1b1. TutorRec shows an error message.

  Use case ends.

Use case: Sorting students

MSS

1. User requests to view students of a particular category

2. TutorRec shows a filtered list containing only students with this category

   Use case ends.

Extensions

• 1a. The list is empty.

  Use case ends.

• 1b. The given category does not have any students assigned to it.

  • 1b1. TutorRec shows an empty list.

  Use case ends.

• 1c. User inputs an invalid category.

  • 1c1. TutorRec shows an error message.

  Use case ends.

Use case: Editing a student’s details

MSS

1. User requests to list students
2. TutorRec displays a list of students
3. User requests to edit the details of a specific student in the list
4. TutorRec updates the details of this student

5. TutorRec displays the updated information of this student

   Use case ends.

Extensions

• 2a. The list is empty.

  Use case ends.

• 3a. The given index is invalid.

  • 3a1. TutorRec shows an error message.

    Use case resumes at step 2.

• 3b. User inputs a field that does not exist (e.g. adding a nonexistent /q field).

  • 3b1. TutorRec shows an error message.

    Use case resumes at step 2.

Use case: Finding a student

MSS

1. User requests to list all students with a particular name

2. TutorRec displays a reduced list containing all students that meet the criteria of the name requested

   Use case ends.

Extensions

• 1a. The list is empty.

  Use case ends.

• 1b. No students exist with the given name.

  • 1b1. TutorRec displays an empty list.

    Use case ends.

Use case: Checking improvements of a student

MSS

1. User requests to list students
2. TutorRec displays a list of students
3. User updates a specific student’s grades for a given test
4. TutorRec updates the grades for this student
5. TutorRec displays that the student’s grades has been updated
6. User requests to view a list of a specific student’s grades

7. TutorRec displays a history of this student’s grades

   Use case ends.

Extensions

• 2a. The list is empty.

  Use case ends.

• 3a. The given index is invalid.

  • 3a1. TutorRec shows an error message.

    Use case resumes at step 2.

• 3b. An invalid score is listed as the input.

  • 3b1. TutorRec shows an error message.

    Use case resumes at step 2.

• 6a. The given index is invalid.

  • 6a1. TutorRec shows an error message.

    Use case resumes at step 2.

• 6b. The student has no grades saved.

  • 6b1. TutorRec displays nothing.

    Use case resumes at step 2.

Use case: Updating payment status

MSS

1. User requests to list students
2. TutorRec displays a list of students
3. User chooses to mark a specific student as having made their payment
4. TutorRec updates the payment status of this student to be complete
5. User chooses to mark a specific as not having made their payment

6. TutorRec updates the payment status of this student to be incomplete

   Use case ends.

Extensions

• 2a. The list is empty.

  Use case ends.

• 3a. The given index is invalid.

  • 3a1. TutorRec shows an error message.

    Use case resumes at step 2.

• 3b. The student selected already has had their payment marked as made.

  • 3b1. TutorRec shows an error message.

    Use case resumes at step 2.

• 5a. The given index is invalid.

  • 5a1. TutorRec shows an error message.

    Use case resumes at step 2.

• 5b. The student selected already has had their payment marked as made.

  • 5b1. TutorRec shows an error message.

    Use case resumes at step 2.

Use case: Creating an appointment

MSS

1. User requests to list students
2. TutorRec displays a list of students
3. User sets a specific student to have an appointment at a particular time and date
4. TutorRec updates details about this student

5. TutorRec displays details of appointment to user

   End of use case.

Extensions

• 2a. The list is empty.

  Use case ends.

• 3a. The given index is invalid.

  • 3a1. TutorRec shows an error message.

    Use case resumes at step 2.

• 3b. Insufficient information is given to make an appointment.

  • 3b1. TutorRec shows an error message.

    Use case resumes at step 2.

• 3c. The time and date inputted by the user clashes with an existing appointment previously made by the user.

  • 3c1. TutorRec shows an error message.

  • 3c2. TutorRec displays information of student which has an appointment that resulted in the timing clash, and the date and time of this appointment.

    Use case resumes at step 2.

Non-Functional Requirements

1. TutorRec should work on any mainstream OS as long as it has Java 11 or above installed.
2. TutorRec should be able to hold up to 1000 persons without a noticeable sluggishness in performance for typical usage.
3. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.
4. TutorRec is not required to handle multiple users (i.e. multi-user product); it is a single-user product.
5. TutorRec needs to be developed in a breadth-first incremental manner, with weekly updates.
6. TutorRec’s data should be stored locally and should be in a human editable text file.
7. TutorRec should not use a DBMS to store data.
8. TutorRec should work without requiring an installer.
9. TutorRec should be packaged into a single JAR file for releases.
10. TutorRec’s JAR files should not exceed 100MB.
11. The development of TutorRec should follow the Object-oriented paradigm.
12. TutorRec should be able to respond within three seconds.
13. TutorRec should be designed to function offline.
14. TutorRec should not require additional hardware beyond standard computing devices (e.g., desktops, laptops, tablets) commonly availabe to users.

Glossary

• Mainstream OS: Windows, Linux, Unix, MacOS
• Private contact detail: A contact detail that is not meant to be shared with others

---

Appendix: Instructions for manual testing

Given below are instructions to test the app manually.

Launch and shutdown

1. Initial launch

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

   2. Open a terminal inside the folder containing the jar file and run java -jar tutorrec.jar
      Expected: Shows the GUI with a set of sample persons. The window size may not be optimum.

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 running java -jar tutorrec.jar in the folder containing the jar file.
      Expected: The most recent window size and location is retained.

3. Shutting down

   1. Use the exit command or click on the close window button on the title bar of TutorRec.

Deleting a person

1. Deleting a person while all persons are being shown

   1. Prerequisites: List all persons using the list command. Multiple persons in the list.

   2. Test case: delete 1
      Expected: First contact is deleted from the list. Details of the deleted contact shown in the status message. Timestamp in the status bar is updated.

   3. Test case: delete 0
      Expected: No person is deleted. Error details shown in the status message. Status bar remains the same.

   4. Other incorrect delete commands to try: delete, delete x, ... (where x is larger than the list size)
      Expected: Similar to previous.

Viewing all appointments / appointments on a specific day

1. Viewing all appointments
   1. Prerequisites: TutorRec is running and contains persons with appointments. Each day of the week has at least 1 appointment belonging to any person. The current displayed list of persons is displaying all persons.
   2. Test case: appointments
      Expected: All appointments of the persons currently displayed in the list are displayed.
2. Viewing appointments on a specific day
   1. Prerequisites: TutorRec is running and contains persons with appointments. There is at least one appointment scheduled on Monday belonging to any person in the current displayed list.
   2. Test case: appointments MON
      Expected: Appointments scheduled on Monday of the persons current displayed in the list are displayed.

Viewing details of a person

1. Viewing details of a person currently displayed in the list
   1. Prerequisites: There is at least one person in the current displayed list.
   2. Run view 1.
      Expected: All details of the person are displayed in the window on the right.

Saving data

1. Dealing with missing data file

   1. Open a terminal and run java -jar tutorrec.jar in the folder containing the jar file. This will cause TutorRec to generate a data folder containing addressbook.json which stores all person data.
   2. Exit TutorRec.
   3. Delete the addressbook.json file in the data folder.
   4. Run java -jar tutorrec.jar in the terminal again.
      Expected: TutorRec regenerates the data file containing some sample persons.

---

Appendix: Planned Enhancements

Team Size: 5

1. Standardize display of person’s contact details with other fields when missing information: Currently when a person is missing contact information such as phone number, email and address, the view command shows ‘—’ instead of just ‘-‘ like other fields when there’s no information. This will be changed in a future version to show the same ‘-‘ as other fields when information is missing.
2. Improve UI to handle extremely long tags going out of UI bounds: Currently when a tag contains a string that is extremely long, it will stretch beyond the boundary of the person list. This will be improved in a future version to allow the tag to wrap around to display the full tag.
3. Set a limit to the length of a name: Currently TutorRec is capable of accepting a name of any length. This causes issues when the name entered is excessively long, resulting in it being not displayed properly in the UI. Setting a limit on the length of a name will prevent it from being cut-off in the UI.
4. Fix the find command to be reflective of the current list: Currently, the find command properly filters the user list when the command is typed, but does not respond to delete commands properly. For example, if a person “David” is searched for in the list, and find David is used, then it currently will properly display a filtered list with “David” in it. Suppose David has index 1.
   • If delete 1 is used, the filtered list will incorrectly still list David as still being in the list of contacts.
   • If edit 1 [some edits] is used, the filtered list will incorrectly completely reset to show the entire full list, with or without David.
   • In either case, any command to modify the list should properly interact with the previous find command, so it should remove David as part of the contact list if delete is used, or continue showing the filtered list if edit is used, and so forth.
5. Improve error message handling: Currently, there are certain user-inputted errors which are not properly reflected in TutorRec. For example, typing edit 1 n/ is properly identified as an invalid command (as a person must not have their name removed), but the feedback given by TutorRec is that names should only be alphanumeric, and should not be blank - which is technically correct, but does not communicate sufficiently with the user that the Name field cannot be removed in edit.
6. Improve appointment conflict detection: Currently, TutorRec disallows conflicting appointments, that is to say, appointments that overlap at a particular time on a particular day. This however, does not account for special cases where the timing of an appointment is different for two days but on the same day, (For example, two appointments, one on the current Sunday, and one on the next Sunday, the former from 1400-1700 and the latter at 1500-1800 is marked as a conflict.) and so an improvement to TutorRec’s way of detecting conflicting appointments could improve user experience.
7. Allow special characters as part of names: Currently, TutorRec strictly allows only alphanumeric characters to be part of a name. However, this does not account for people with special characters as part of their legal names, such as the use of s/o and -. This improvement would allow for accurate recording of names.
8. Improve consistency of multiple prefixes: Currently, TutorRec accepts multiple arguments for certain prefixes. For example, users can have multiple prefixes for subject, edit 4 s/ENGLISH s/MATH resulting in the student having both subjects. However, for the note and level prefixes, TutorRec allows multiple prefixes but only takes the last argument. edit 4 l/p1 l/p6 results in the student having only the p6 level assigned. To improve on this, we can enhance the consistency of accepting multiple prefixes across all commands in the project.
9. Enable resizing of TutorRec: Currently, TutorRec is not resizable as a window. This change would improve user experience.
10. Improve duplicate name detection in TutorRec: Presently, TutorRec permits additional white spaces between names, such as ‘John     Doe’, which is distinguished as a separate name from ‘John Doe’. We can refine duplicate name detection by devising a more robust algorithm to address this issue and efficiently identify near matches.