diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md
index cb038e6ca0b..be23572da27 100644
--- a/docs/DeveloperGuide.md
+++ b/docs/DeveloperGuide.md
@@ -10,6 +10,7 @@
--------------------------------------------------------------------------------------------------------------------
+
## 1. Introduction
@@ -120,6 +121,9 @@ The sequence diagram below illustrates the interactions within the `Logic` compo
**Note:** The lifeline for `DeleteCommandParser` and `DeleteCommand` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline continues till the end of diagram.
+--------------------------------------------------------------------------------------------------------------------
+
+
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.
@@ -159,6 +163,8 @@ The `Model` component,
+--------------------------------------------------------------------------------------------------------------------
+
### 2.5 Storage component
@@ -173,6 +179,8 @@ The `Storage` component,
* 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`)
+--------------------------------------------------------------------------------------------------------------------
+
### 2.6 Common classes
Classes used by multiple components are in the `seedu.address.commons` package.
@@ -335,6 +343,9 @@ The following sequence diagram shows how the Add Tags operation works:
* Pros: Simplifies data handling, avoids tag duplication.
* Cons: Risk of losing previously assigned tags, less flexibility in tag management.
+--------------------------------------------------------------------------------------------------------------------
+
+
**Aspect: Logic handling for pre-existing tags**
* **Alternative 1 (current choice)**: Do not add tags already present for the patient.
@@ -402,12 +413,15 @@ The following sequence diagram shows how the Delete Tags operation works:
* Pros: Simplifies command execution, faster performance for small tag sets.
* Cons: Requires multiple commands for each tag deletion, less flexible in bulk operations.
+--------------------------------------------------------------------------------------------------------------------
+
+
**Aspect: Handling Missing Tags**
* **Alternative 1 (current choice)**: Log output for non-existent tags to inform user, proceed with deleting the valid tags.
* Pros: Simplifies user interaction, allows bulk deletion without worrying about non-existent tags, users are informed about the tags that are not present, Users do not need to correct the command.
* Cons: Adds complexity to the command execution, requiring additional logic to differentiate between existing and non-existing tags.
-
+
* **Alternative 2**: Return an error message for non-existent tags, ask users to correct the command.
* Pros: Ensures user awareness of non-existent tags, avoids accidental deletions, prompts users to provide valid tag inputs.
* Cons: Requires users to fix the command before proceeding, potential interruption to workflow, may increase user frustration if multiple tags are missing.
@@ -490,6 +504,9 @@ due to a limitation of PlantUML, the lifeline reaches the end of diagram.
* Pros: Simplifies data handling, avoids events duplication.
* Cons: Risk of losing previously assigned events, less flexibility in event management.
+--------------------------------------------------------------------------------------------------------------------
+
+
**Aspect: Error Handling for Duplicate Events**
* **Alternative 1 (current choice)**: Do not add events already present for the patient.
@@ -800,6 +817,9 @@ using keyword(s).
The activity diagram below outlines the steps involved when a user initiates a Find command.
+--------------------------------------------------------------------------------------------------------------------
+
+
#### Example Usage Scenario
Given below is an example usage scenario and how the group creation mechanism behaves at each step.
@@ -819,8 +839,6 @@ due to a limitation of PlantUML, the lifeline reaches the end of diagram.
-
-
#### Design Considerations
**Aspect: Choice of keyword**
@@ -851,6 +869,9 @@ using keyword(s).
The activity diagram below outlines the steps involved when a user initiates a Find Tags command.
+--------------------------------------------------------------------------------------------------------------------
+
+
#### Example Usage Scenario
Given below is an example usage scenario and how the group creation mechanism behaves at each step.
@@ -870,8 +891,6 @@ The following UML sequence diagram illustrates how the Find Tags operations work
-
-
#### Design Considerations
**Aspect: Choice of Command Structure**
@@ -938,6 +957,9 @@ The following UML sequence diagram illustrates how the Sort operations works.
* Pros: Command structure is similar to other commands that uses prefix.
* Cons: Command structure is weird and counter-intuitive.
+--------------------------------------------------------------------------------------------------------------------
+
+
**Aspect: ATTRIBUTE specification**
* **Alternative 1 (current choice)**: Can be empty.
@@ -977,7 +999,7 @@ sorted order.
#### Introduction
-The `ClearCommand` class is responsible for clearing all data in PatientSync
+The `ClearCommand` class is responsible for clearing all data in PatientSync.
#### Specifications
@@ -999,7 +1021,7 @@ Step 2: The user executes `clear` to clear all data in PatientSync.
#### Introduction
-The `ExitCommand` class is responsible for exiting and closing PatientSync
+The `ExitCommand` class is responsible for exiting and closing PatientSync.
#### Specifications
@@ -1131,7 +1153,6 @@ Specifically, we intend to perform the following validations:
Upon identification of such invalid `PATIENT_HOSPITAL_ID` field values, PatientSync should then output a custom error message, i.e.,`Invalid PATIENT_HOSPITAL_ID!`
---------------------------------------------------------------------------------------------------------------------
### 4.8 Displaying PatientHospitalId in UI
@@ -1261,6 +1282,7 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli
Use case ends.
--------------------------------------------------------------------------------------------------------------------
+
**Use case: UC02 - Delete a patient**
@@ -1359,6 +1381,8 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli
Use case ends.
+--------------------------------------------------------------------------------------------------------------------
+
**Use case: UC05 - Add event for a patient**
**MSS**
@@ -1708,6 +1732,8 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli
7. User Documentation: Should offer comprehensive, well-organized user documentation that guides users on how to effectively use PatientSync.
8. Developer Documentation: Should provide detailed developer documentation for those looking to enhance, customize, or develop extensions.
+--------------------------------------------------------------------------------------------------------------------
+
### 6.5 Glossary
* **Mainstream OS**: Windows, Linux, Unix, MacOS
@@ -1744,10 +1770,7 @@ testers are expected to do more *exploratory* testing.
1. Re-launch the app by double-clicking the jar file.
Expected: The most recent window size and location is retained.
-
-
--------------------------------------------------------------------------------------------------------------------
-
### 7.2 Adding a patient
@@ -1762,6 +1785,7 @@ testers are expected to do more *exploratory* testing.
Expected: Error message displayed.
--------------------------------------------------------------------------------------------------------------------
+
### 7.3 Deleting a patient