[CS2103-W10-3] ToothTracker

docs/DeveloperGuide.md

@@ -63,7 +63,7 @@ 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.
+  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
@@ -113,11 +113,11 @@ Here's a (partial) class diagram of the `Logic` component:
 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., `DeletePatientCommandParser`) and uses it to parse the command.
-1. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `DeletePatientCommand`) which
-   is executed by the `LogicManager`.
-1. The command can communicate with the `Model` when it is executed (e.g. to delete a person).
-1. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`.
+   a parser that matches the command (e.g., `DeletePatientCommandParser`) 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., `DeletePatientCommand`) which
+   is executed by the `LogicManager`. 
+3. The command can communicate with the `Model` when it is executed (e.g. to delete a person). 
+4. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`.
 
 The sequence diagram below illustrates the interactions within the `Logic` component, taking `execute("delete-patient 1")` API
 call as an example.
@@ -189,10 +189,10 @@ This section describes some noteworthy details on how certain features are imple
 The features implemented are categorized into 4 sections:
 
 1. [Dentist Features](#dentist-features)
-1. [Patient Features](#patient-features)
-1. [Appointment Features](#appointment-features)
-1. [Treatment Features](#treatment-features)
-1. [General Features](#general-features)
+2. [Patient Features](#patient-features)
+3. [Appointment Features](#appointment-features)
+4. [Treatment Features](#treatment-features)
+5. [General Features](#general-features)
 
 ### Dentist Features
 
@@ -432,6 +432,90 @@ keyword is of a valid type for that particular attribute. Users are responsible
 
 ### Appointment Features
 
+#### Adding an Appointment
+
+The `add-appointment` command creates a new appointment record in ToothTracker.
+
+The activity diagram for creating a new appointment is illustrated as follows:
+
+![AddAppointmentActivityDiagram](images/AddAppointmentActivityDiagram.png)
+
+The sequence diagram shows the interactions between the various components during the execution of the `add-appointment` command:
+
+![AddAppointmentSequenceDiagram](images/AddAppointmentSequenceDiagram.png)
+
+##### Feature Details
+
+1. Users provide essential appointment information, such as the dentist ID, patient ID, appointment start time and treatment name.
+2. In case of missing or invalid command arguments, the system prompts users with an error message to enter the command correctly.
+3. The system retrieves information about the treatment cost, duration, dentist and patient from the `Model` using the information provided by the user.
+4. The system checks the new appointment's time slot with existing appointments in the `Model` to prevent clashing appointments.
+If a timing clash is found, an error message informs the user.
+5. If step 4 is completed without any exceptions, the new appointment record is created and stored in the system.
+
+##### Feature Considerations
+
+For the dentist ID, patient ID and treatment field, it is mandatory that the specified dentist, patient and treatment exists in ToothTracker.
+If these conditions are not met, the user will receive an error message.
+
+#### Deleting an Appointment
+
+The `delete-appointment` command deletes an appointment record from ToothTracker.
+
+The activity diagram for deleting an appointment is illustrated as follows:
+
+![DeleteAppointmentActivityDiagram](images/DeleteAppointmentActivityDiagram.png)
+
+The sequence diagram shows the interactions between the various components during the execution of the `delete-appointment` command:
+
+![DeleteAppointmentSequenceDiagram](images/DeleteAppointmentSequenceDiagram.png)
+
+##### Feature Details
+
+1. The user specifies an appointment id that represents an `Appointment` to be deleted.
+2. If an invalid `APPOINTMENT_ID` is provided, an error is thrown and the user is prompted to enter the command correctly via an error message.
+3. The Appointment is cross-referenced in the `Model` to check if it exists. If it does not, then an error is raised to inform the user.
+4. If step 3 completes without any exceptions, then the `Appointment` is successfully deleted.
+
+##### Feature Considerations
+
+In implementing the delete feature, we needed proper error handling and validation to ensure ToothTracker's robustness and provide clear guidance to the user.
+Our approach validates appointment ID and shows an error message if the appointment does not exist.
+This is in comparison to allowing commands to fail silently if appointment does not exist.
+
+- Pros: Prevents invalid operations and provides immediate feedback to the user, helping to correct mistakes.
+- Cons: Additional validation checks add complexity to the code.
+
+
+#### Filtering an Appointment
+
+The `filter-appointment` command filters appointments by DENTIST_ID or PATIENT_ID.
+
+The activity diagram for filtering an appointment is illustrated as follows:
+
+![FilterAppointmentActivityDiagram](images/FilterAppointmentActivityDiagram.png)
+
+The sequence diagram shows the interactions between the various components during the execution of the `filter-appointment` command:
+
+![DeleteAppointmentSequenceDiagram](images/FilterAppointmentSequenceDiagram.png)
+
+##### Feature Details
+
+1. Users initiate a filter for appointments using either a unique `DENTIST_ID` or a unique `PATIENT_ID`.
+2. If an invalid `DENTIST_ID` or `PATIENT_ID` is provided, an error is thrown and the user is prompted to enter the command correctly via an error message. 
+3. If the user opts to filter by `DENTIST_ID`, the system processes the request to return a list of appointments with the specific dentist. 
+4. If the user opts to filter by `PATIENT_ID`, the system processes the request to return a list of appointments with the specific patient. 
+5. If there are no appointments with the specific dentist or patient, the system informs the user that no appointments were found with the specific dentist or patient.
+
+##### Feature Considerations
+
+Validity checks are performed to ensure that the `DENTIST_ID` or `PATIENT_ID` are valid and that they type of ID to filter by is clearly stated.
+Otherwise, user would receive an error message that guides them to input the right command and details.
+
+If no appointments with the specific dentist or patient are found in ToothTracker, it should be clearly
+communicated to the user instead of just displaying an empty list. A message stating that no appointments with the
+specified `DENTIST_ID` or `PATIENT_ID` are found would be displayed to the user.
+
 ### Treatment Features
 
 #### Adding a Treatment
@@ -823,13 +907,13 @@ Use case ends.
 
       Use Case Ends.
 
-**Use case: Add Appointment**
+**Use case: Add an Appointment**
 
 **MSS**
 
 1. User submits a request to add a new future appointment, providing information about the appointment.
- Information includes dentist ID, patient ID, appointment start time and treatment provided during the appointment.
-3. ToothTracker acknowledges the request to add the new appointment.
+ Information includes dentist ID, patient ID, appointment start time and treatment provided during the appointment. 
+2. ToothTracker acknowledges the request to add the new appointment.
 
    Use case ends.
 
@@ -842,23 +926,135 @@ Use case ends.
 
       Use case continues from step 2.
 
+
 - **1b. User inputs a treatment that does not exist in the database**
     - ToothTracker checks the database and finds that the treatment provided does not exist.
     - ToothTracker alerts the user that the treatment is not provided in the clinic.
     - Steps within 1b loop until an existing treatment is provided.
 
+
 - **1c. User inputs a dentist or patient ID that does not exist in the database**
     - ToothTracker checks the database and finds that the dentist or patient ID provided does not exist.
     - ToothTracker alerts the user that the patient or dentist with the provided patient or dentist ID does not exist in this clinic.
     - Steps within 1c loop until valid dentist and patient IDs are provided.
 
+
 - **1d. User inputs an appointment time slot that clashes with an existing one in the database**
     - ToothTracker checks the database and finds that the appointment to be added clashes with an existing one.
     - ToothTracker alerts the user about the clashing appointments.
     - Steps within 1d loop until an appointment time slot that does not clash with an existing appointment is provided.
 
       Use case resumes at step 1.
 
+
+**Use Case: Delete an Appointment**
+
+**MSS**
+
+1. User submits a request to delete an appointment:
+    - User specifies the appointment ID [APPOINTMENT ID] to delete.
+
+2. ToothTracker searches for the appointment entry:
+   - ToothTracker looks for an appointment with the matching ID.
+
+3. ToothTracker shows the appointment entry that matches the request:
+    - If a match is found:
+        - User confirms the deletion of the specified appointment.
+
+4. ToothTracker deletes the appointment:
+    - Appointment entry is removed from the database.
+
+      Use Case Ends.
+
+**Extensions**
+
+* 2a. The list is empty:
+    - ToothTracker displays a message indicating no appointments are saved in its system.
+
+      Use Case Ends.
+
+
+* 3a. No matching appointment found:
+    - ToothTracker displays an error message.
+
+      Use Case resumes at step 2.
+
+
+* 3b. Invalid appointment ID:
+    - ToothTracker displays an error message.
+
+      Use Case ends.
+
+
+* 4a. Deletion is cancelled by the user:
+    - ToothTracker cancels the deletion process.
+    - Use Case ends.
+
+**Use case: List Appointment Data**
+
+**MSS**
+
+1. User submits a request to list all appointment data.
+2. ToothTracker retrieves the list of all appointment data saved in the system.
+3. ToothTracker displays the list of appointments to the user.
+
+   Use case ends.
+
+**Extensions**
+
+- **1a. User inputs an invalid command.**
+    - ToothTracker identifies the command error.
+        - ToothTracker prompts the user to make the necessary adjustments and provide the command in the correct format.
+    - Steps within 1a repeat until a valid `list-appointment` command is provided.
+
+      Use case continues from step 2.
+
+
+- **2a. No appointment data available.**
+    - ToothTracker checks and finds that there are no appointment records in the system.
+    - ToothTracker informs the user that no appointment data is available.
+
+      Use case continues from step 2.
+
+
+**Use Case: Filter Appointments**
+
+**MSS**
+
+1. User submits a request to filter appointments:
+    - User specifies filter criteria, which can be either a dentist ID [DENTIST ID] or a patient ID [PATIENT ID].
+
+2. ToothTracker filters appointment list based on the criteria:
+    - If the request specifies [DENTIST ID]:
+        - ToothTracker filters the appointment list by the specified dentist ID.
+    - If the request specifies [PATIENT ID]:
+        - ToothTracker filters the appointment list by the specified patient ID.
+
+3. ToothTracker displays the filter results:
+   - ToothTracker lists the matching appointments and their details.
+
+   Use Case Ends.
+
+**Extensions**
+
+* 2a. The list of appointment is empty:
+    - ToothTracker displays a message indicating that no appointments are saved in its system.
+
+      Use Case Ends.
+
+
+* 3a. No matching appointments found:
+    - ToothTracker displays a message indicating no matching appointments were found.
+
+      Use Case Ends.
+
+
+* 3b. Invalid appointment ID:
+    - ToothTracker displays an error message.
+
+      Use Case Ends.
+
+
 **Use case: Add Treatment**
 
 **MSS**
@@ -993,8 +1189,7 @@ testers are expected to do more *exploratory* testing.
 1. Resize the window to an optimum size. Move the window to a different location. Close the window.
 2. Re-launch ToothTracker by double-clicking the jar file.<br>
        Expected: The most recent window size and location is retained.
-
-4. _{ more test cases …​ }_
+3. _{ more test cases …​ }_
 
 ## Dentist
 
@@ -1172,7 +1367,7 @@ Expected Output in the Command Output Box: Error message for invalid command for
 
 ### Listing all Appointments
 
-Prerequisite: THere is at least 1 Appointment stored in ToothTracker.
+Prerequisite: There is at least 1 Appointment stored in ToothTracker.
 
 `list-appointment`
 
@@ -1297,4 +1492,4 @@ Expected Output: ToothTracker application closes.
 
     1. _{explain how to simulate a missing/corrupted file, and the expected behavior}_
 
-1. _{ more test cases …​ }_
+   2. _{ more test cases …​ }_

docs/diagrams/AddAppointmentActivityDiagram.puml

@@ -0,0 +1,33 @@
+@startuml
+start
+:User executes "add-appointment" command with required details;
+
+if () then ([valid command])
+  :Check if treatment exists in model;
+
+    if () then ([treatment is valid])
+      :Check if dentist and patient exists in model;
+
+      if () then ([dentist and patient are valid])
+        :Check if appointment clashes with existing appointment in model;
+            if () then ([appointment does not clash])
+                :Add new appointment to model;
+                :Return message to show new appointment added;
+            else ([else])
+                :Throw CommandException for clashing appointments;
+            endif
+
+      else ([else])
+        :Throw CommandException for invalid dentist or patient;
+     endif
+
+    else ([else])
+      :Throw CommandException for invalid treatment;
+    endif
+
+else ([else])
+    :Display error message for invalid command;
+endif
+
+stop
+@enduml