From c25c42eb038056e081e41665e2abcb5adc07a6fa Mon Sep 17 00:00:00 2001 From: yorklim Date: Sun, 14 Apr 2024 16:54:23 +0800 Subject: [PATCH 01/14] Fix DevGuide manual testing bugs --- docs/DeveloperGuide.md | 61 +++++++++++++++++++++--------------------- 1 file changed, 30 insertions(+), 31 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 25bb90c6f27..b31e1799cad 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -855,15 +855,14 @@ testers are expected to do more *exploratory* testing. 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. + Expected: First client is deleted from the list. Details of the deleted contact shown in the status message. - 3. Test case: `delete 0`
- Expected: No person is deleted. Error details shown in the status message. Status bar remains the same. + 3. Test case (Missing Index): `delete`
+ Expected: No client is deleted. Error details shown in the status message. - 4. Other incorrect delete commands to try: `delete`, `delete x`, `...` (where x is larger than the list size)
- Expected: Similar to previous. + 4. Test case (Invalid Index): `delete x`(where x is smaller or larger than the list size)
+ Expected: similar to previous. -2. _{ more test cases …​ }_ ### Editing a client @@ -874,10 +873,10 @@ testers are expected to do more *exploratory* testing. 1. Prerequisites: Multiple clients in the client list. 2. Test case: `list`
- Expected: All clients are shown in the list view. Success message shown in the status message. + Expected: All clients are shown in the list view. Success message shown in the status message. 3. Test case: `list 1`, `list asdsad`, `list n/Jones` or any command with extra characters supplied
- Expected: Similar to previous. + Expected: Similar to previous. ### Viewing a client @@ -887,16 +886,16 @@ testers are expected to do more *exploratory* testing. 1. Prerequisites: List all clients using the `list` command. Multiple clients in the client list. 2. Test case: `view 1`
- Expected: First client's details are shown in the client details view and policy details view. Success message shown in the status message. + Expected: First client's details are shown in the client details view and policy details view. Success message shown in the status message. 3. Test case (Missing Index): `view`
- Expected: Client details view and Policy details view not updated. Error message shown in the status message. + Expected: Client details view and Policy details view not updated. Error details shown in the status message. 4. Test case (Invalid Index): `view x` (where x is smaller or larger than the list size)
- Expected: Similar to previous. + Expected: Similar to previous. 6. Test case (Extra Characters): `view 1 asd`, `view 1 n/Jones` or any command with extra characters supplied
- Expected: Similar to previous. + Expected: Similar to previous. ### Finding a client @@ -905,13 +904,13 @@ testers are expected to do more *exploratory* testing. 1. Prerequisites: List all client using the `list` command. Multiple clients in the client list. Ensure there is a client with the name "Jones". 2. Test case: `find Jones`
- Expected: Client list update to show all clients with the name "Jones". Success message shown in the status message. + Expected: Client list update to show all clients with the name "Jones". Success message shown in the status message. 3. Test case (Multiple keywords): `find Jones Brown`
- Expected: Client list update to show all clients with the name "Jones" or the name "Brown" (if any). Success message shown in the status message. + Expected: Client list update to show all clients with the name "Jones" or the name "Brown" (if any). Success message shown in the status message. 4. Test case (Missing keyword): `find`
- Expected: No client is found. Error message shown in the status message. + Expected: No client is found. Error details shown in the status message. ### Adding notes to a client @@ -922,10 +921,10 @@ testers are expected to do more *exploratory* testing. 1. Prerequisites: Multiple clients in the client list. 2. Test case: `clear`
- Expected: All clients are removed from the list. Success message shown in the status message. + Expected: All clients are removed from the list. Success message shown in the status message. 3. Test case: `clear 1`, `clear asdsad`, `clear n/Jones` or any command with extra characters supplied
- Expected: Similar to previous. + Expected: Similar to previous. ### Sorting clients @@ -962,34 +961,34 @@ Desired Outcome: Setting the duration to 45 days.
### Adding a policy -1. Adding a policy to a patient while all clients are being shown +1. Adding a policy to a client while all clients are being shown 1. Prerequisites: List all clients using the `list` command. Multiple clients in the client list. Ensure the first client does not have the policy number "123".
2. Test case: `addpolicy 1 n/Health i/123`
- Expected: Policy successfully added to first client. Success message shown in the status message. + Expected: Policy successfully added to first client. Success message shown in the status message. 3. Test case (Missing Index): `addpolicy n/Health i/123`
- Expected: Policy not added to any client. Error message shown in the status message. + Expected: Policy not added to any client. Error details shown in the status message. 4. Test case (Missing Parameters): `addpolicy 1 n/Health`, `addpolicy 1 i/123` or any command with missing parameters
- Expected: Similar to previous + Expected: Similar to previous 5. Test case (Invalid Index): `addpolicy x n/Health i/123` (where x is smaller or larger than the list size)
- Expected: Similar to previous. + Expected: Similar to previous. 6. Test case (Invalid Policy Name): `addpolicy 1 n/#Health i/123`
- Expected: Similar to previous. + Expected: Similar to previous. 7. Test case (Invalid Policy Number): `addpolicy 1 n/Health i/abc`
- Expected: Similar to previous. + Expected: Similar to previous. 8. Test case (Repeated Parameters): `addpolicy 1 n/Health i/123 n/Health` or any command with repeated parameter
- Expected: Similar to previous. + Expected: Similar to previous. ### Deleting a policy -1. Deleting a policy from a patient while all clients are being shown +1. Deleting a policy from a client while all clients are being shown 1. Prerequisites: List all clients using the `list` command. Multiple clients in the client list. Ensure the first client has the policy number "123".
@@ -997,19 +996,19 @@ Desired Outcome: Setting the duration to 45 days.
Expected: Policy successfully added to first client. Success message shown in the status message. 3. Test case (Missing Index): `deletepolicy i/123`
- Expected: Policy not added to any client. Error message shown in the status message. + Expected: Policy not added to any client. Error details shown in the status message. 4. Test case (Missing Parameters): `deletepolicy 1 `
- Expected: Similar to previous + Expected: Similar to previous 5. Test case (Invalid Index): `deletepolicy x i/123` (where x is smaller or larger than the list size)
- Expected: Similar to previous. + Expected: Similar to previous. 6. Test case (Invalid Policy Number): `deletepolicy 1 i/abc`
- Expected: Similar to previous. + Expected: Similar to previous. 7. Test case (Repeated Parameters): `deletepolicy 1 i/123 i/123`
- Expected: Similar to previous. + Expected: Similar to previous. ### Saving data From 2bf32b25905f30988571168a0c47d91fad46bb9a Mon Sep 17 00:00:00 2001 From: ReganChoy Date: Sun, 14 Apr 2024 17:57:55 +0800 Subject: [PATCH 02/14] Update DG format --- docs/DeveloperGuide.md | 112 ++++++++++++++++++++++++++++++++--------- 1 file changed, 88 insertions(+), 24 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 25bb90c6f27..570714e62ae 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -930,36 +930,91 @@ testers are expected to do more *exploratory* testing. ### Sorting clients ### Updating last met -Command Format: `met index d/YYYY-MM-DD`
-Assumptions: Today is 13 April 2024, date chosen must not be in the future.
-Desired Outcome: Updating the last met date of the 3rd client to 11 April 2024.
-1. Correct Test Case: `met 3 d/2024-04-11` -2. Invalid Test Case: `met 3 d/11-04-2024` wrong date format +1. Updating the last met of a client while all clients are being shown + 1. Prerequisites: List all clients using the `list` command. Multiple clients in the client list. Ensure the date chosen is not in the future. + For the test cases, we assume that today is 13 April 2024. + + 2. Test case: `met 1 d/2024-04-11`
+ Expected: Last met successfully updated for first client. Success message shown in the status message. + + 3. Test case (Invalid Date Format): `met 3 d/11-04-2024`
+ Expected: Last met not updated for any client. Error details in status message. + + 4. Test case (Missing Parameters): `met d/2024-04-11`, `met 3` or any command with missing parameters
+ Expected: Similar to previous + + 5. Test case (Repeated Parameters): `met 3 d/2024-04-11 d/2024-04-11` or any command with repeated parameter
+ Expected: Similar to previous. + + 6. Test case (Invalid Index): `met x d/2024-04-11` (where x is smaller or larger than the list size)
+ Expected: Similar to previous + + 7. Test Case (Future Date, Invalid Date): `met 3 d/2024-04-20` + Expected: Similar to previous + ### Scheduling an appointment -Command Format: `schedule index d/YYYY-MM-DD HH:mm`
-Assumptions: Today is 13 April 2024, date chosen must not be in the past.
-Desired Outcome: Creating an appointment with the 3rd client on 18 April 2024 2pm.
-1. Correct Test Case: `schedule 3 d/2024-04-18 14:00` -2. Invalid Test Case: `schedule 3 d/18-04-2024 14:00` wrong dateTime format -3. Invalid Test Case: `schedule 3 d/2024-04-18` missing time + +1. Scheduling an appointment with a client while all clients are being shown + 1. Prerequisites: List all clients using the `list` command. Multiple clients in the client list. Ensure the date chosen is in the future. + For the test cases, we assume that today is 13 April 2024 and the time is 2pm. + + 2. Test case: `schedule 1 d/2024-04-18 18:00`
+ Expected: Schedule successfully updated for first client. Success message shown in the status message. + + 3. Test case (Invalid DateTime Format): `schedule 3 d/18-04-2024`
+ Expected: Schedule not updated for any client. Error details in status message. + + 4. Test case (Missing Parameters): `schedule d/2024-04-18 18:00`, `schedule 3` or any command with missing parameters
+ Expected: Similar to previous + + 5. Test case (Repeated Parameters): `schedule 3 d/2024-04-18 18:00 d/2024-05-17 13:15` or any command with repeated parameter
+ Expected: Similar to previous. + + 6. Test case (Invalid Index): `schedule x d/18-04-2024 13:00` (where x is smaller or larger than the list size)
+ Expected: Similar to previous + + 7. Test Case (Past DateTime, Invalid DateTime): `schedule 3 d/2024-04-10 12:00`, `schedule 3 d/2024-04-13 14:00` + Expected: Similar to previous ### Marking an appointment as complete -Command Format: `mark index`
-Assumptions: An open appointment is present with an existing client.
-Desired Outcome: Marking an appointment with the 3rd client.
-1. Correct Test Case: `mark 3` -2. Invalid Test Case: `mark 3` if client does not exist or appointment is done -3. Invalid Test Case: `mark three` index should be a positive integer +1. Updating an appointment with a client as completed while all clients are being shown + 1. Prerequisites: List all clients using the `list` command. Multiple clients in the client list. Ensure there is an open appointment with an existing client. + + 2. Test case: `mark 1`
+ Expected: Appointment with the first client is successfully updated as completed. Success message shown in the status message. + + 3. Test case (No Open Appointment with existing client): `mark 2`
+ Expected: Appointment not updated for any client. Error details in status message. + + 4. Test case (Missing Parameters): `mark`
+ Expected: Similar to previous + + 5. Test case (Repeated Parameters): `schedule 3 3`
+ Expected: Similar to previous. + + 6. Test case (Invalid Index): `mark x` (where x is smaller or larger than the list size)
+ Expected: Similar to previous ### Set the last met overdue duration -Command Format: `set integer`
-Assumptions: Nil
-Desired Outcome: Setting the duration to 45 days.
-1. Correct Test Case: `set 45` -2. Invalid Test Case: `set 45.3` value must be non-negative integer -3. Invalid Test Case: `set forty five` value must be a non-negative integer +1. Setting a new last met overdue duration + 1. Prerequisites: Nil + 2. Test case: `set 45`
+ Expected: Sets the new last met overdue duration to 45 days. Success message shown in the status message. + + 3. Test case (Missing Parameters): `set`
+ Expected: Last met overdue duration remains unchanged. Error details in status message. + + 4. Test Case (Non-numerical, Invalid Parameter): `set abc`
+ Expected: Similar to previous + + 5. Test Case (Decimal, Invalid Parameter): `set 64.6`
+ Expected: Similar to previous + + 6. Test Case (Negative Integer, Invalid Parameter): `set -6`
+ Expected: Similar to previous + ### Adding a policy 1. Adding a policy to a patient while all clients are being shown @@ -1046,7 +1101,13 @@ Desired Outcome: Setting the duration to 45 days.
3. Test case: Empty setvalue.txt file.
Expected: Similar to previous. - 4. Test case: Add non-digit characters to json file.
+ 4. Test case: Add non-digit characters to setvalue.txt file.
+ Expected: Similar to previous. + + 5. Test case: Add non-integer values to setvalue.txt file.
+ Expected: Similar to previous. + + 6. Test Case: Add negative integer values to setvalue.txt file.
Expected: Similar to previous. 4. Dealing with wrongly edit setvalue.txt @@ -1061,6 +1122,9 @@ Desired Outcome: Setting the duration to 45 days.
4. Test case: Edit value to be negative.
Expected: Similar to previous. + + 5. Test case: Edit value to be non-integer.
+ Expected: Similar to previous. ## **Appendix: Planned Enhancements** From 8b462c8e32ddebb252534bb6c2da6ed5486cf480 Mon Sep 17 00:00:00 2001 From: ReganChoy Date: Sun, 14 Apr 2024 18:02:23 +0800 Subject: [PATCH 03/14] Update DG --- docs/DeveloperGuide.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 570714e62ae..cc4e31191ec 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -974,7 +974,7 @@ testers are expected to do more *exploratory* testing. 6. Test case (Invalid Index): `schedule x d/18-04-2024 13:00` (where x is smaller or larger than the list size)
Expected: Similar to previous - 7. Test Case (Past DateTime, Invalid DateTime): `schedule 3 d/2024-04-10 12:00`, `schedule 3 d/2024-04-13 14:00` + 7. Test Case (Non-Future DateTime, Invalid DateTime): `schedule 3 d/2024-04-10 12:00`, `schedule 3 d/2024-04-13 14:00` Expected: Similar to previous ### Marking an appointment as complete @@ -1009,7 +1009,7 @@ testers are expected to do more *exploratory* testing. 4. Test Case (Non-numerical, Invalid Parameter): `set abc`
Expected: Similar to previous - 5. Test Case (Decimal, Invalid Parameter): `set 64.6`
+ 5. Test Case (Non-Integer, Invalid Parameter): `set 64.6`
Expected: Similar to previous 6. Test Case (Negative Integer, Invalid Parameter): `set -6`
From 27a4a10b9e630c07f3573dd30ada33490d670b5d Mon Sep 17 00:00:00 2001 From: ReganChoy Date: Sun, 14 Apr 2024 18:07:29 +0800 Subject: [PATCH 04/14] Add fake dates --- docs/DeveloperGuide.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index cc4e31191ec..6923565a000 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -953,6 +953,9 @@ testers are expected to do more *exploratory* testing. 7. Test Case (Future Date, Invalid Date): `met 3 d/2024-04-20` Expected: Similar to previous + 8. Test Case (Invalid Date): `schedule 3 d/2024-02-31` + Expected: Similar to previous + ### Scheduling an appointment 1. Scheduling an appointment with a client while all clients are being shown @@ -976,6 +979,9 @@ testers are expected to do more *exploratory* testing. 7. Test Case (Non-Future DateTime, Invalid DateTime): `schedule 3 d/2024-04-10 12:00`, `schedule 3 d/2024-04-13 14:00` Expected: Similar to previous + + 8. Test Case (Invalid DateTime): `schedule 3 d/2024-02-31 12:00` + Expected: Similar to previous ### Marking an appointment as complete 1. Updating an appointment with a client as completed while all clients are being shown @@ -1015,6 +1021,9 @@ testers are expected to do more *exploratory* testing. 6. Test Case (Negative Integer, Invalid Parameter): `set -6`
Expected: Similar to previous + 7. Test Case (Value Above Integer Limit): `set 1234567890098765432112345564354345324343124134211232132131231` + Expected: Similar to previous + ### Adding a policy 1. Adding a policy to a patient while all clients are being shown From baf31ed58d8f663073b9686f707eb1dff6570660 Mon Sep 17 00:00:00 2001 From: solomonng2001 Date: Sun, 14 Apr 2024 18:37:33 +0800 Subject: [PATCH 05/14] Add DG implementation details for sorting, birthday and priority Let's * Add implementation, UML diagrams and design considerations for sort. * Add implementation and UML for birthday and priority extensions to add and edit commands --- docs/DeveloperGuide.md | 74 +++++++++++++++++++ docs/diagrams/AddPersonObjectDiagram.puml | 23 ++++++ docs/diagrams/AddPersonSequenceDiagram.puml | 60 +++++++++++++++ docs/diagrams/SortPersonsObjectDiagram.puml | 29 ++++++++ docs/diagrams/SortPersonsSequenceDiagram.puml | 68 +++++++++++++++++ 5 files changed, 254 insertions(+) create mode 100644 docs/diagrams/AddPersonObjectDiagram.puml create mode 100644 docs/diagrams/AddPersonSequenceDiagram.puml create mode 100644 docs/diagrams/SortPersonsObjectDiagram.puml create mode 100644 docs/diagrams/SortPersonsSequenceDiagram.puml diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index f2b41a7e187..63f653158b0 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -189,6 +189,7 @@ The sequence diagram below shows the execution of `view 1` to view the details o * In this implementation, `DisplayClient` would simply be a `Person` set by `CommandResult`, similar to the current `feedbackToUser` implementation. * However, this means `DisplayClient` can only be set after a command, which does not allow us to set `DisplayClient` on application startup. + ### Adding notes to client feature The `remark` command allows users to add an optional note to a client. @@ -212,8 +213,38 @@ The `remark` command was implemented according to [Tutorial: Adding a command](h * While this might make it easier to type, it will also make fixing typos slower, like mentioned in the current behaviour. * It also means that a separate way of parsing has to be used, instead of `ArgumentMultimap`, deviating from other commands. + ### Sorting clients feature +The `sort` command allows users to sort the client list by a specified `sort criteria` that can be `name`, `priority` or `birthday`, and a `sort order` that can be `asc` or `desc`. + +#### Implementation + +The functionality to `sort` clients is implemented in the `SortCommand` class. The `SortCommandParser` class is responsible for parsing the user input and creating a `SortCommand` object. + +The `SortCommandParser` class parses the input arguments by storing the prefixes of their respective values in a `ArgumentMultimap` object, and create a new `SortCommand` object with the parsed `SortCriteria` and `SortOrder`. + +The `SortCommand` object then creates a `Comparator` object using `SortCriteria` and `SortOrder` objects, and communicates with the `Model` component to update the `Comparator` used to sort the list of persons. + +The `SortCommand` object does the following: +- `PersonComparator#getComparator(SortCriteria, SortOrder)` is used to get the `Comparator` object using the `SortCriteria` and `SortOrder`. +- `Model#updateSortPersonComparator(Comparator)` - Updates the `Comparator` object used to sort the list of persons in the `Model` component. +- `Model#setDisplayClientAsFirstInSortedFilteredPersonList()` - Updates the displayed client in the UI to the first client in the sorted list of persons. + +The following object diagram illustrates the above: + + +The following sequence diagram shows the `sort` operation: + + +#### Design Considerations + +In order to keep `ModelManager#filteredPersons` as an immutable `final` field, we have decided not to modify the `filteredPersons` directly. Instead, we do the following: +- we store the `Comparator` object in `ModelManager#personComparator`, which can be updated by `ModelManager#updateSortPersonComparator(Comparator)`. +- When a sorted list of persons is needed, we call `ModelManager#getSortedFilteredPersonList()` which returns a new sorted list of persons sorted using the `ModelManager#personComparator`. + +This way, the original order of `ModelManager#filteredPersons` is preserved, and we can get a sorted list of persons when needed. + ### Updating last met feature The last met feature allows users to keep track and update their last interaction with their clients. @@ -331,6 +362,49 @@ The following sequence diagram shows the addpolicy operation: ### Deleting policy feature +### Extensions to add command and edit command: Add birthday, edit birthday, add priority, edit priority features + +The add birthday and edit birthday features allow users to add and edit the birthday of a client. Birthdays support the birthday reminders feature. The birthday is stored in the `Birthday` class, which contains the birthday details such as day, month, and year. The `Birthday` class is part of the `Person` object in the `Model` component. + +The add priority and edit priority features allow users to add and edit the priority of a client. Priority supports the sort by priority feature, and helps optimise client management. The priority is stored in the `Priority` class, which contains the priority details such as priority value. The priority value are enumerated, and can be one of the following: LOW, MEDIUM, HIGH, VIP. The `Priority` class is part of the `Person` object in the `Model` component. + +#### Implementation + +The functionality to add and edit birthday and priority is implemented in the `AddCommand` and `EditCommand` classes. The `AddCommandParser` and `EditCommandParser` classes are responsible for parsing the user input and creating an `AddCommand` or `EditCommand` object respectively. + +The `AddCommandParser` and `EditCommandParser` classes parse the input arguments by storing the prefixes of their respective values in a `ArgumentMultimap` object, and create a new `AddCommand` or `EditCommand` object with the parsed birthday or priority, amongst other fields. + +The `AddCommand` and `EditCommand` objects then communicate with the `Model` component to add or edit the birthday or priority of the client. The `Model` component then updates the `Person` object with the new birthday or priority, amongst other fields. + +The `AddCommand` object then communicates with the `Model` component to add a person. +- `Model#addPerson(Person)` - Adds the new client to the existing client list. +- `Model#setDisplayClient(Person)` - Updates the displayed client in the UI to the client that has been added. + +The following object diagram illustrates the above: + + +The following sequence diagram shows the `add` operation: + + +More on birthday class +* Birthday is immutable and stores the day, month and year as a `LocalDate` object, as time is not relevant for birthday. +* The message constraints for birthday utilise the `DateUtil` common class to ensure that the date is valid and in the correct format. +* `DateUtil` class is used to validate (conforms to `DateUtil` date format and is parsable) and parse the string to a `LocalDate` object. `DateUtil` is also used to ensure that the date is not in the future. +* Refer to the `DateUtil` class for more information on the date format and parsing. + +More on priority class +* Priority is immutable and stores the priority value as a `PriorityValue` object, which is an enumerated type, to ensure that priority value is a valid type. +* The message constraints for priority utilise the `PriorityValue` enum class which should be responsible for the `toString()` logic for display. +* `PriorityValue` enum class is used to validate the priority value, which is responsible for the possible valid priority values. +* Refer to the `PriorityValue` enum class for more information on the priority values. + +More on priority value enum class +* `PriorityValue` is an enumerated type that contains the possible valid priority values: LOW, MEDIUM, HIGH, VIP. +* When parsing from a string and displaying as a string, the `PriorityValue` allows full form values (`low`, `medium`, `high`, `vip`) and short form values (`l`, `m`, `h`, `v`) to be used interchangeably. +* Parsing from a string to a `PriorityValue` object is case-insensitive, and is handled by `getPriority`. +* Obtaining the all available full form and short form of the `PriorityValue` object is handled by `getFullPriorities()` and `getShortPriorities()` respectively. +* The mapping of the full form strings and short form strings to the enum values is handled through `HashMap FULL_PRIORITY_MAP` and `HashMap SHORT_PRIORITY_MAP`, which has a constant time complexity. + ### \[Proposed\] Undo/redo feature #### Proposed Implementation diff --git a/docs/diagrams/AddPersonObjectDiagram.puml b/docs/diagrams/AddPersonObjectDiagram.puml new file mode 100644 index 00000000000..6c625282a3e --- /dev/null +++ b/docs/diagrams/AddPersonObjectDiagram.puml @@ -0,0 +1,23 @@ +@startuml +!include style.puml +skinparam objectFontColor white + +object ":AddCommand" as AddCommand LOGIC_COLOR +object ":AddCommandParser" as AddCommandParser LOGIC_COLOR +object ":AddressBookParser" as AddressBookParser LOGIC_COLOR +object ":Model" as Model MODEL_COLOR +object ":CommandResult" as CommandResult LOGIC_COLOR +object "toAdd:Person" as Person LOGIC_COLOR +object ":ArgumentMultimap" as ArgumentMultimap LOGIC_COLOR +object ":ParserUtil" as ParserUtil LOGIC_COLOR + +AddressBookParser --> AddCommandParser : calls +AddressBookParser --> AddCommand +AddCommandParser -> AddCommand +AddCommandParser --> ArgumentMultimap : instantiates +ParserUtil --> ArgumentMultimap : parses +AddCommand --> Person +AddCommand --> Model +AddCommand -right-> CommandResult : outputs +Model -right-> Person : Adds +@enduml diff --git a/docs/diagrams/AddPersonSequenceDiagram.puml b/docs/diagrams/AddPersonSequenceDiagram.puml new file mode 100644 index 00000000000..66d50ca8db2 --- /dev/null +++ b/docs/diagrams/AddPersonSequenceDiagram.puml @@ -0,0 +1,60 @@ +@startuml +!include style.puml +skinparam ArrowFontStyle plain + +box Logic LOGIC_COLOR_T1 +participant ":LogicManager" as LogicManager LOGIC_COLOR +participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR +participant "a:AddCommand" as AddCommand LOGIC_COLOR +participant ":CommandResult" as CommandResult LOGIC_COLOR +end box + +box Model MODEL_COLOR_T1 +participant ":Model" as Model MODEL_COLOR +end box +[-> LogicManager : execute(...) +activate LogicManager + +LogicManager -> AddressBookParser : parseCommand(...) +activate AddressBookParser + +create AddCommand +AddressBookParser -> AddCommand : AddCommand(...) +activate AddCommand + +AddCommand --> AddressBookParser +deactivate AddCommand + +AddressBookParser --> LogicManager : a +deactivate AddressBookParser + +LogicManager -> AddCommand : execute() +activate AddCommand + +AddCommand -> Model : addPerson(toAdd) +activate Model + +Model --> AddCommand +deactivate Model + +AddCommand -> Model : setDisplayClient(toAdd) +activate Model + +Model --> AddCommand +deactivate Model + +create CommandResult +AddCommand --> CommandResult +activate CommandResult + +CommandResult --> AddCommand +deactivate CommandResult + +AddCommand --> LogicManager : result +deactivate AddCommand +AddCommand -[hidden]-> LogicManager : result +destroy AddCommand + +[<--LogicManager +deactivate LogicManager +@enduml diff --git a/docs/diagrams/SortPersonsObjectDiagram.puml b/docs/diagrams/SortPersonsObjectDiagram.puml new file mode 100644 index 00000000000..73b92570331 --- /dev/null +++ b/docs/diagrams/SortPersonsObjectDiagram.puml @@ -0,0 +1,29 @@ +@startuml +!include style.puml +skinparam objectFontColor white + +object ":SortCommand" as SortCommand LOGIC_COLOR +object ":SortCommandParser" as SortCommandParser LOGIC_COLOR +object ":AddressBookParser" as AddressBookParser LOGIC_COLOR +object ":Model" as Model MODEL_COLOR +object ":CommandResult" as CommandResult LOGIC_COLOR +object "sortCriteria:SortCriteria" as SortCriteria LOGIC_COLOR +object "sortOrder:SortOrder" as SortOrder LOGIC_COLOR +object ":Comparator" as Comparator LOGIC_COLOR +object ":ArgumentMultimap" as ArgumentMultimap LOGIC_COLOR +object ":ParserUtil" as ParserUtil LOGIC_COLOR + +AddressBookParser --> SortCommandParser : calls +AddressBookParser --> SortCommand +SortCommandParser -> SortCommand +SortCommandParser --> ArgumentMultimap : instantiates +ParserUtil --> ArgumentMultimap : parses +SortCommand --> Model +SortCommand ---> SortCriteria : contains +SortCommand ---> SortOrder : contains +SortCommand --> Comparator : creates +SortCommand -right-> CommandResult : outputs +Comparator --> SortCriteria : uses +Comparator --> SortOrder : uses +Model --> Comparator : updates comparator to sort persons +@enduml diff --git a/docs/diagrams/SortPersonsSequenceDiagram.puml b/docs/diagrams/SortPersonsSequenceDiagram.puml new file mode 100644 index 00000000000..492b7678767 --- /dev/null +++ b/docs/diagrams/SortPersonsSequenceDiagram.puml @@ -0,0 +1,68 @@ +@startuml +!include style.puml +skinparam ArrowFontStyle plain + +box Logic LOGIC_COLOR_T1 +participant ":LogicManager" as LogicManager LOGIC_COLOR +participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR +participant "a:AddCommand" as AddCommand LOGIC_COLOR +participant ":CommandResult" as CommandResult LOGIC_COLOR +end box + +box Model MODEL_COLOR_T1 +participant ":Model" as Model MODEL_COLOR +participant "<>\nPersonComparator" as PersonComparator MODEL_COLOR +end box + +[-> LogicManager : execute(...) +activate LogicManager + +LogicManager -> AddressBookParser : parseCommand(...) +activate AddressBookParser + +create AddCommand +AddressBookParser -> AddCommand : AddCommand(...) +activate AddCommand + +AddCommand --> AddressBookParser +deactivate AddCommand + +AddressBookParser --> LogicManager : a +deactivate AddressBookParser + +LogicManager -> AddCommand : execute() +activate AddCommand + +AddCommand -> PersonComparator : getComparator(sortCriteria, sortOrder) +activate PersonComparator + +PersonComparator --> AddCommand : comparator +deactivate PersonComparator + +AddCommand -> Model : updateSortPersonComparator(comparator) +activate Model + +Model --> AddCommand +deactivate Model + +AddCommand -> Model : setDisplayClientAsFirstInSortedFilteredPersonList() +activate Model + +Model --> AddCommand +deactivate Model + +create CommandResult +AddCommand --> CommandResult +activate CommandResult + +CommandResult --> AddCommand +deactivate CommandResult + +AddCommand --> LogicManager : result +deactivate AddCommand +AddCommand -[hidden]-> LogicManager : result +destroy AddCommand + +[<--LogicManager +deactivate LogicManager +@enduml From 03ca6a47abb3df20a0cc006560da524687b91be5 Mon Sep 17 00:00:00 2001 From: ReganChoy Date: Sun, 14 Apr 2024 18:53:50 +0800 Subject: [PATCH 06/14] Update future dates to be 2025 --- docs/DeveloperGuide.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 6923565a000..4910205ad7a 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -950,7 +950,7 @@ testers are expected to do more *exploratory* testing. 6. Test case (Invalid Index): `met x d/2024-04-11` (where x is smaller or larger than the list size)
Expected: Similar to previous - 7. Test Case (Future Date, Invalid Date): `met 3 d/2024-04-20` + 7. Test Case (Future Date, Invalid Date): `met 3 d/2025-04-20` Expected: Similar to previous 8. Test Case (Invalid Date): `schedule 3 d/2024-02-31` @@ -962,25 +962,25 @@ testers are expected to do more *exploratory* testing. 1. Prerequisites: List all clients using the `list` command. Multiple clients in the client list. Ensure the date chosen is in the future. For the test cases, we assume that today is 13 April 2024 and the time is 2pm. - 2. Test case: `schedule 1 d/2024-04-18 18:00`
+ 2. Test case: `schedule 1 d/2025-04-18 18:00`
Expected: Schedule successfully updated for first client. Success message shown in the status message. - 3. Test case (Invalid DateTime Format): `schedule 3 d/18-04-2024`
+ 3. Test case (Invalid DateTime Format): `schedule 3 d/18-04-2025`
Expected: Schedule not updated for any client. Error details in status message. - 4. Test case (Missing Parameters): `schedule d/2024-04-18 18:00`, `schedule 3` or any command with missing parameters
+ 4. Test case (Missing Parameters): `schedule d/2025-04-18 18:00`, `schedule 3` or any command with missing parameters
Expected: Similar to previous - 5. Test case (Repeated Parameters): `schedule 3 d/2024-04-18 18:00 d/2024-05-17 13:15` or any command with repeated parameter
+ 5. Test case (Repeated Parameters): `schedule 3 d/2025-04-18 18:00 d/2025-05-17 13:15` or any command with repeated parameter
Expected: Similar to previous. - 6. Test case (Invalid Index): `schedule x d/18-04-2024 13:00` (where x is smaller or larger than the list size)
+ 6. Test case (Invalid Index): `schedule x d/2025-04-18 13:00` (where x is smaller or larger than the list size)
Expected: Similar to previous 7. Test Case (Non-Future DateTime, Invalid DateTime): `schedule 3 d/2024-04-10 12:00`, `schedule 3 d/2024-04-13 14:00` Expected: Similar to previous - 8. Test Case (Invalid DateTime): `schedule 3 d/2024-02-31 12:00` + 8. Test Case (Invalid DateTime): `schedule 3 d/2025-02-31 12:00` Expected: Similar to previous ### Marking an appointment as complete From fab318905e51f02268209c5010831d388b3359fe Mon Sep 17 00:00:00 2001 From: getsquared Date: Sun, 14 Apr 2024 19:06:09 +0800 Subject: [PATCH 07/14] Update manual testing --- docs/DeveloperGuide.md | 107 +++++++++++++++++++++++++++++++++++------ 1 file changed, 92 insertions(+), 15 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 25bb90c6f27..8c3366eed8e 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -160,7 +160,7 @@ Classes used by multiple components are in the `seedu.address.commons` package. This section describes some noteworthy details on how certain features are implemented. -### View Client feature +### Viewing client feature The `view` command allows users to view the details of a client on the GUI using their `INDEX`. Other commands will also affect the client display in the GUI. This includes information not included in the client list cards, such as their last met and policy list. @@ -844,29 +844,67 @@ testers are expected to do more *exploratory* testing. 2. Re-launch the app by double-clicking the jar file.
Expected: The most recent window size and location is retained. -3. _{ more test cases …​ }_ ### Adding a client +1. Adding a client while all clients are being shown + + 1. Prerequisites: List all clients using the `list` command. Multiple clients in the list. + + 2. Test case: `add n/John Doe c/12345678 e/john-doe@example.com a/123 Tampines Street 42 t/friends p/high d/1987-02-02`
+ Expected: John Doe is added to the end of the list. Details of the added person are shown in the status message. Timestamp in the status bar is updated. + + 3. Test case (Missing Compulsory Parameter): `add n/John Doe e/john-doe@example.com a/123 Tampines Street 42 t/friends p/high d/1987-02-02`
+ Expected: No client is added to the list. Error details shown in the status message. Timestamp in the status bar is updated. Status bar remains the same. + + 4. Test case (Invalid Parameter): `add n/John Doe c/12345678 e/john-doe.example a/123 Tampines Street 42 t/friends p/high d/1987-02-02`
+ Expected: Similar to previous. + +2. Adding a client that is already in list + + 1. Prerequisites: List all clients using the `list` command. Multiple clients in the list. There is a client with name `John Doe` already in the list. + + 2. Test case: `add n/John Doe c/12345678 e/john-doe@example.com a/123 Tampines Street 42 t/friends p/high d/1987-02-02`
+ Expected: Error details shown in the status message. Timestamp in the status bar is updated. Status bar remains the same. + ### Deleting a client 1. Deleting a client while all clients are being shown - 1. Prerequisites: List all persons using the `list` command. Multiple persons in the list. + 1. Prerequisites: List all clients using the `list` command. Multiple clients 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. + 3. Test case (Missing Index): `delete`
+ Expected: No client 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)
+ 4. Test case (Invalid Index): `delete x` (where x is smaller or larger than the list size)
Expected: Similar to previous. -2. _{ more test cases …​ }_ ### Editing a client +1. Editing a client while all clients are being shown + + 1. Prerequisites: List all clients using the `list` command. Multiple clients in the list. + + 2. Test case: `edit 1 n/John Doe`
+ Expected: First client's name is edited to John Doe. Details of the added person are shown in the status message. Timestamp in the status bar is updated. + + 3. Test case (Missing Index): `edit n/John Doe`
+ Expected: No client is edited. Error details shown in the status message. Status bar remains the same. + + 4. Test case (Invalid Index): `edit x n/John Doe` (where x is smaller or larger than the list size)
+ Expected: Similar to previous. + + 5. Test case (Missing Parameters): `edit 2`
+ Expected: Similar to previous. + + 6. Test case (Invalid Parameter): `edit e/john-doe.example`
+ Expected: Similar to previous. + + ### Listing client 1. Listing all clients @@ -886,18 +924,32 @@ testers are expected to do more *exploratory* testing. 1. Prerequisites: List all clients using the `list` command. Multiple clients in the client list. - 2. Test case: `view 1`
- Expected: First client's details are shown in the client details view and policy details view. Success message shown in the status message. + 2. Test case: `view 2`
+ Expected: Second client's details are shown in the client details view and policy details view. Success message shown in the status message. 3. Test case (Missing Index): `view`
- Expected: Client details view and Policy details view not updated. Error message shown in the status message. + Expected: Client details view and Policy details view not updated. Error details shown in the status message. 4. Test case (Invalid Index): `view x` (where x is smaller or larger than the list size)
Expected: Similar to previous. - 6. Test case (Extra Characters): `view 1 asd`, `view 1 n/Jones` or any command with extra characters supplied
+ 6. Test case (Extra Characters): `view 2 asd`, `view 2 n/Jones` or any command with extra characters supplied
Expected: Similar to previous. +2. Viewing a client while clients are filtered by name `John` + + 1. Prerequisites: Multiple clients with similar name (e.g. `John Doe`, `John Yu`) in client list. Filter the clients using the `find john` command. + + 2. Test case: `view 2`
+ Expected: Second client's details are show in the client details view and policy details view. Success message shown in the status message. + +3. Viewing a client while clients are sorted by priority in ascending order + + 1. Prerequisites: Multiple clients with different priorities in client list. Sort the clients using the `sort priority o/asc`. + + 2. Test case: `view 2`
+ Expected: Second client's details are shown in the client details view and policy details view. Success message shown in the status message. + ### Finding a client 1. Finding a client with a given name `Jones` @@ -915,6 +967,28 @@ testers are expected to do more *exploratory* testing. ### Adding notes to a client +1. Adding a note to a client while client does not have existing note + + 1. Prerequisites: List all clients using the `list` command. Multiple clients in the client list. Ensure the first client does not have a note.
+ + 2. Test case: `remark 1 r/Prefers emails`
+ Expected: Note successfully added to first client. Success message shown in the status message. + + 3. Test case (Empty Parameter): `remark 1 r/`
+ Expected: Note successfully removed from first client. Success message show in the status message. + + 4. Test case (Repeated Parameters): `remark 1 r/Preeeffers emaiis r/Prefers emails`
+ Expected: Note from last parameter successfully added to first client. Success message shown in the status message. + + 5. Test case (No Parameter): `remark 1`
+ Expected: Note successfully removed from first client. Success message show in the status message. + + 6. Test case (Missing Index): `remark r/Prefers emails`
+ Expected: Note not added to any client. Error details shown in the status message. + + 7. Test case (Invalid Index): `remark x r/Prefers emails` (where x is smaller or larger than the list size)
+ Expected: Similar to previous. + ### Clearing the client list 1. Clearing the client list @@ -1079,7 +1153,7 @@ Team Size: 4 ## **Appendix: Effort** -1. Scheduling Features +**1. Scheduling Features**
`met`, `schedule`, `mark` and `set` commands help the user manage his scheduling matters. As these 4 commands directly affect each other, the difficulty comes in thinking what and how their respective class methods should interact with each other, especially with what date format to choose as this directly affects our auto-sort implemented for scheduling. It is also difficult to test for extreme cases that may cause these commands to misbehave. We decided to simplify the process by restricting the user to 1 appointment per client as our initial beta version faced multiple bugs due to higher number of classes and functions when supporting multiple appointments per client. @@ -1087,10 +1161,13 @@ We decided to simplify the process by restricting the user to 1 appointment per `set` is also saved in a separate txt file as it is not related to client traits. Hence, additional testing is needed to ensure the value that `set` updates is saved correctly and is able to handle invalid values if the txt file is edited wrongly. -2. Policies Features +**2. Policies Features**
+ +**3. Additional Client Traits and Features**
-3. Additional Client Traits and Features +**4. GUI**
+Some challenges arose in the designing of changes to the GUI to present all the details we wanted. This included the placement of the various panels so that they fit together well without feeling cluttered. There was also considerable time spent on the Reminders panel on the right in particular, as we were not sure at first how we wanted to show all three types of reminders (last met, birthdays, schedules) without overcrowding. Originally, all three were to be shown together in one "Reminders This Week", but we felt that it would be hard to read for the user. -4. GUI +There was also some consideration on how we wanted to handle refreshing the various panels, e.g. viewing the client details as explained in [Viewing client feature](#viewing-client-feature). -------------------------------------------------------------------------------------------------------------------- From 321c70eecd2711a7871d763ee6f958c83d4d2012 Mon Sep 17 00:00:00 2001 From: solomonng2001 Date: Sun, 14 Apr 2024 19:14:37 +0800 Subject: [PATCH 08/14] Add minor fixes --- docs/DeveloperGuide.md | 14 ++++++-------- docs/diagrams/AddPersonObjectDiagram.puml | 9 +++++---- 2 files changed, 11 insertions(+), 12 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 431d78ad389..dccf5781783 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -224,8 +224,6 @@ The functionality to `sort` clients is implemented in the `SortCommand` class. T The `SortCommandParser` class parses the input arguments by storing the prefixes of their respective values in a `ArgumentMultimap` object, and create a new `SortCommand` object with the parsed `SortCriteria` and `SortOrder`. -The `SortCommand` object then creates a `Comparator` object using `SortCriteria` and `SortOrder` objects, and communicates with the `Model` component to update the `Comparator` used to sort the list of persons. - The `SortCommand` object does the following: - `PersonComparator#getComparator(SortCriteria, SortOrder)` is used to get the `Comparator` object using the `SortCriteria` and `SortOrder`. - `Model#updateSortPersonComparator(Comparator)` - Updates the `Comparator` object used to sort the list of persons in the `Model` component. @@ -366,7 +364,7 @@ The following sequence diagram shows the addpolicy operation: The add birthday and edit birthday features allow users to add and edit the birthday of a client. Birthdays support the birthday reminders feature. The birthday is stored in the `Birthday` class, which contains the birthday details such as day, month, and year. The `Birthday` class is part of the `Person` object in the `Model` component. -The add priority and edit priority features allow users to add and edit the priority of a client. Priority supports the sort by priority feature, and helps optimise client management. The priority is stored in the `Priority` class, which contains the priority details such as priority value. The priority value are enumerated, and can be one of the following: LOW, MEDIUM, HIGH, VIP. The `Priority` class is part of the `Person` object in the `Model` component. +The add priority and edit priority features allow users to add and edit the priority of a client. Priority supports the sort by priority feature, and helps optimise client management. The priority is stored in the `Priority` class, which contains the priority details such as priority value. The priority value are enumerated, and can be one of the following: `LOW`, `MEDIUM`, `HIGH`, `VIP`. The `Priority` class is part of the `Person` object in the `Model` component. #### Implementation @@ -374,7 +372,7 @@ The functionality to add and edit birthday and priority is implemented in the `A The `AddCommandParser` and `EditCommandParser` classes parse the input arguments by storing the prefixes of their respective values in a `ArgumentMultimap` object, and create a new `AddCommand` or `EditCommand` object with the parsed birthday or priority, amongst other fields. -The `AddCommand` and `EditCommand` objects then communicate with the `Model` component to add or edit the birthday or priority of the client. The `Model` component then updates the `Person` object with the new birthday or priority, amongst other fields. +The `AddCommand` and `EditCommand` objects then communicate with the `Model` component to add or edit the birthday or priority of the client. The `Model` component then adds or edits the `Person` object with the new birthday or priority, amongst other fields. The `AddCommand` object then communicates with the `Model` component to add a person. - `Model#addPerson(Person)` - Adds the new client to the existing client list. @@ -386,20 +384,20 @@ The following object diagram illustrates the above: The following sequence diagram shows the `add` operation: -More on birthday class +More on `Birthday` class * Birthday is immutable and stores the day, month and year as a `LocalDate` object, as time is not relevant for birthday. * The message constraints for birthday utilise the `DateUtil` common class to ensure that the date is valid and in the correct format. * `DateUtil` class is used to validate (conforms to `DateUtil` date format and is parsable) and parse the string to a `LocalDate` object. `DateUtil` is also used to ensure that the date is not in the future. * Refer to the `DateUtil` class for more information on the date format and parsing. -More on priority class +More on `Priority` class * Priority is immutable and stores the priority value as a `PriorityValue` object, which is an enumerated type, to ensure that priority value is a valid type. * The message constraints for priority utilise the `PriorityValue` enum class which should be responsible for the `toString()` logic for display. * `PriorityValue` enum class is used to validate the priority value, which is responsible for the possible valid priority values. * Refer to the `PriorityValue` enum class for more information on the priority values. -More on priority value enum class -* `PriorityValue` is an enumerated type that contains the possible valid priority values: LOW, MEDIUM, HIGH, VIP. +More on `PriorityValue` enum class +* `PriorityValue` is an enumerated type that contains the possible valid priority values: `LOW`, `MEDIUM`, `HIGH`, `VIP`. * When parsing from a string and displaying as a string, the `PriorityValue` allows full form values (`low`, `medium`, `high`, `vip`) and short form values (`l`, `m`, `h`, `v`) to be used interchangeably. * Parsing from a string to a `PriorityValue` object is case-insensitive, and is handled by `getPriority`. * Obtaining the all available full form and short form of the `PriorityValue` object is handled by `getFullPriorities()` and `getShortPriorities()` respectively. diff --git a/docs/diagrams/AddPersonObjectDiagram.puml b/docs/diagrams/AddPersonObjectDiagram.puml index 6c625282a3e..ca0b3c8c8f4 100644 --- a/docs/diagrams/AddPersonObjectDiagram.puml +++ b/docs/diagrams/AddPersonObjectDiagram.puml @@ -7,9 +7,9 @@ object ":AddCommandParser" as AddCommandParser LOGIC_COLOR object ":AddressBookParser" as AddressBookParser LOGIC_COLOR object ":Model" as Model MODEL_COLOR object ":CommandResult" as CommandResult LOGIC_COLOR -object "toAdd:Person" as Person LOGIC_COLOR -object ":ArgumentMultimap" as ArgumentMultimap LOGIC_COLOR -object ":ParserUtil" as ParserUtil LOGIC_COLOR +object "toAdd:Person" as Person LOGIC_COLOR +object ":ArgumentMultimap" as ArgumentMultimap LOGIC_COLOR +object ":ParserUtil" as ParserUtil LOGIC_COLOR AddressBookParser --> AddCommandParser : calls AddressBookParser --> AddCommand @@ -19,5 +19,6 @@ ParserUtil --> ArgumentMultimap : parses AddCommand --> Person AddCommand --> Model AddCommand -right-> CommandResult : outputs -Model -right-> Person : Adds +Model -right-> Person : adds +Model --> Person : set client to display as @enduml From 699352da9206ecbaa878e0d616969dfa37ad27cf Mon Sep 17 00:00:00 2001 From: getsquared Date: Sun, 14 Apr 2024 19:19:02 +0800 Subject: [PATCH 09/14] Update manual testing timestamp --- docs/DeveloperGuide.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 8c3366eed8e..8a98b084507 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -852,10 +852,10 @@ testers are expected to do more *exploratory* testing. 1. Prerequisites: List all clients using the `list` command. Multiple clients in the list. 2. Test case: `add n/John Doe c/12345678 e/john-doe@example.com a/123 Tampines Street 42 t/friends p/high d/1987-02-02`
- Expected: John Doe is added to the end of the list. Details of the added person are shown in the status message. Timestamp in the status bar is updated. + Expected: John Doe is added to the end of the list. Details of the added person are shown in the status message. 3. Test case (Missing Compulsory Parameter): `add n/John Doe e/john-doe@example.com a/123 Tampines Street 42 t/friends p/high d/1987-02-02`
- Expected: No client is added to the list. Error details shown in the status message. Timestamp in the status bar is updated. Status bar remains the same. + Expected: No client is added to the list. Error details shown in the status message. 4. Test case (Invalid Parameter): `add n/John Doe c/12345678 e/john-doe.example a/123 Tampines Street 42 t/friends p/high d/1987-02-02`
Expected: Similar to previous. @@ -865,7 +865,7 @@ testers are expected to do more *exploratory* testing. 1. Prerequisites: List all clients using the `list` command. Multiple clients in the list. There is a client with name `John Doe` already in the list. 2. Test case: `add n/John Doe c/12345678 e/john-doe@example.com a/123 Tampines Street 42 t/friends p/high d/1987-02-02`
- Expected: Error details shown in the status message. Timestamp in the status bar is updated. Status bar remains the same. + Expected: No client is added to the list. Error details shown in the status message. ### Deleting a client @@ -874,10 +874,10 @@ testers are expected to do more *exploratory* testing. 1. Prerequisites: List all clients using the `list` command. Multiple clients 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. + Expected: First contact is deleted from the list. Details of the deleted contact shown in the status message. 3. Test case (Missing Index): `delete`
- Expected: No client is deleted. Error details shown in the status message. Status bar remains the same. + Expected: No client is deleted. Error details shown in the status message. 4. Test case (Invalid Index): `delete x` (where x is smaller or larger than the list size)
Expected: Similar to previous. @@ -890,10 +890,10 @@ testers are expected to do more *exploratory* testing. 1. Prerequisites: List all clients using the `list` command. Multiple clients in the list. 2. Test case: `edit 1 n/John Doe`
- Expected: First client's name is edited to John Doe. Details of the added person are shown in the status message. Timestamp in the status bar is updated. + Expected: First client's name is edited to John Doe. Details of the added person are shown in the status message. 3. Test case (Missing Index): `edit n/John Doe`
- Expected: No client is edited. Error details shown in the status message. Status bar remains the same. + Expected: No client is edited. Error details shown in the status message. 4. Test case (Invalid Index): `edit x n/John Doe` (where x is smaller or larger than the list size)
Expected: Similar to previous. From 96fbcee2ad32ef4d9ba0b57d286394cb18593351 Mon Sep 17 00:00:00 2001 From: ReganChoy Date: Sun, 14 Apr 2024 19:24:00 +0800 Subject: [PATCH 10/14] Fix period formatting --- docs/DeveloperGuide.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index f2df25ea934..cd3afa62354 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -1014,19 +1014,19 @@ testers are expected to do more *exploratory* testing. Expected: Last met not updated for any client. Error details in status message. 4. Test case (Missing Parameters): `met d/2024-04-11`, `met 3` or any command with missing parameters
- Expected: Similar to previous + Expected: Similar to previous. 5. Test case (Repeated Parameters): `met 3 d/2024-04-11 d/2024-04-11` or any command with repeated parameter
Expected: Similar to previous. 6. Test case (Invalid Index): `met x d/2024-04-11` (where x is smaller or larger than the list size)
- Expected: Similar to previous + Expected: Similar to previous. 7. Test Case (Future Date, Invalid Date): `met 3 d/2025-04-20` - Expected: Similar to previous + Expected: Similar to previous. 8. Test Case (Invalid Date): `schedule 3 d/2024-02-31` - Expected: Similar to previous + Expected: Similar to previous. ### Scheduling an appointment @@ -1041,19 +1041,19 @@ testers are expected to do more *exploratory* testing. Expected: Schedule not updated for any client. Error details in status message. 4. Test case (Missing Parameters): `schedule d/2025-04-18 18:00`, `schedule 3` or any command with missing parameters
- Expected: Similar to previous + Expected: Similar to previous. 5. Test case (Repeated Parameters): `schedule 3 d/2025-04-18 18:00 d/2025-05-17 13:15` or any command with repeated parameter
Expected: Similar to previous. 6. Test case (Invalid Index): `schedule x d/2025-04-18 13:00` (where x is smaller or larger than the list size)
- Expected: Similar to previous + Expected: Similar to previous. 7. Test Case (Non-Future DateTime, Invalid DateTime): `schedule 3 d/2024-04-10 12:00`, `schedule 3 d/2024-04-13 14:00` - Expected: Similar to previous + Expected: Similar to previous. 8. Test Case (Invalid DateTime): `schedule 3 d/2025-02-31 12:00` - Expected: Similar to previous + Expected: Similar to previous. ### Marking an appointment as complete 1. Updating an appointment with a client as completed while all clients are being shown @@ -1066,13 +1066,13 @@ testers are expected to do more *exploratory* testing. Expected: Appointment not updated for any client. Error details in status message. 4. Test case (Missing Parameters): `mark`
- Expected: Similar to previous + Expected: Similar to previous. 5. Test case (Repeated Parameters): `schedule 3 3`
Expected: Similar to previous. 6. Test case (Invalid Index): `mark x` (where x is smaller or larger than the list size)
- Expected: Similar to previous + Expected: Similar to previous. ### Set the last met overdue duration 1. Setting a new last met overdue duration @@ -1085,16 +1085,16 @@ testers are expected to do more *exploratory* testing. Expected: Last met overdue duration remains unchanged. Error details in status message. 4. Test Case (Non-numerical, Invalid Parameter): `set abc`
- Expected: Similar to previous + Expected: Similar to previous. 5. Test Case (Non-Integer, Invalid Parameter): `set 64.6`
- Expected: Similar to previous + Expected: Similar to previous. 6. Test Case (Negative Integer, Invalid Parameter): `set -6`
- Expected: Similar to previous + Expected: Similar to previous. 7. Test Case (Value Above Integer Limit): `set 1234567890098765432112345564354345324343124134211232132131231` - Expected: Similar to previous + Expected: Similar to previous. ### Adding a policy @@ -1109,7 +1109,7 @@ testers are expected to do more *exploratory* testing. Expected: Policy not added to any client. Error message shown in the status message. 4. Test case (Missing Parameters): `addpolicy 1 n/Health`, `addpolicy 1 i/123` or any command with missing parameters
- Expected: Similar to previous + Expected: Similar to previous. 5. Test case (Invalid Index): `addpolicy x n/Health i/123` (where x is smaller or larger than the list size)
Expected: Similar to previous. @@ -1136,7 +1136,7 @@ testers are expected to do more *exploratory* testing. Expected: Policy not added to any client. Error message shown in the status message. 4. Test case (Missing Parameters): `deletepolicy 1 `
- Expected: Similar to previous + Expected: Similar to previous. 5. Test case (Invalid Index): `deletepolicy x i/123` (where x is smaller or larger than the list size)
Expected: Similar to previous. From 8592f8884c8a67c84c5e0a2afa27db9de7111b69 Mon Sep 17 00:00:00 2001 From: yorklim Date: Sun, 14 Apr 2024 21:38:56 +0800 Subject: [PATCH 11/14] Fix DevGuide spelling errors --- docs/DeveloperGuide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 387fba4e740..9de80be45f7 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -1088,7 +1088,7 @@ testers are expected to do more *exploratory* testing. ### Marking an appointment as complete 1. Updating an appointment with a client as completed while all clients are being shown - 1. Prerequisites: List all clients using the `list` command. Multiple clients in the client list. Ensure there is an open appointment with the first client and no open appoint with the second client. + 1. Prerequisites: List all clients using the `list` command. Multiple clients in the client list. Ensure there is an open appointment with the first client and no open appointment with the second client. 2. Test case: `mark 1`
Expected: Appointment with the first client is successfully updated as completed. Success message shown in the status message. From 19c10c8f70610dd0a0e4a206f1122e54160a11cd Mon Sep 17 00:00:00 2001 From: yorklim Date: Sun, 14 Apr 2024 21:48:02 +0800 Subject: [PATCH 12/14] Update Effort ratings in DevGuide --- docs/DeveloperGuide.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 9de80be45f7..4854130de0e 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -1253,7 +1253,9 @@ Team Size: 4 ## **Appendix: Effort** **1. Scheduling Features**
-`met`, `schedule`, `mark` and `set` commands help the user manage his scheduling matters. As these 4 commands directly affect each other, the difficulty comes in thinking what and how +Difficulty Level: 3/5
+Effort Required: 3/5
+Challenges faced: `met`, `schedule`, `mark` and `set` commands help the user manage his scheduling matters. As these 4 commands directly affect each other, the difficulty comes in thinking what and how their respective class methods should interact with each other, especially with what date format to choose as this directly affects our auto-sort implemented for scheduling. It is also difficult to test for extreme cases that may cause these commands to misbehave. We decided to simplify the process by restricting the user to 1 appointment per client as our initial beta version faced multiple bugs due to higher number of classes and functions when supporting multiple appointments per client. @@ -1265,7 +1267,9 @@ Thus, we had to create methods within the `UniquePersonList` class to get the li invalid values if the txt file is edited wrongly. **2. Policies Features**
-`addpolicy` and `deletepolicy` commands help the user manage his client's policies. The difficulty comes thinking of how to save the policies into storage and how to retrieve them. +Difficulty Level: 3.5/5
+Effort Required: 3.5/5
+Challenged faced: `addpolicy` and `deletepolicy` commands help the user manage his client's policies. The difficulty comes thinking of how to save the policies into storage and how to retrieve them. Although `Tag` which was already implemented in AB3 was similar and could be used as a reference, the `Policy` feature was more complex as it required the saving of 2 different values (`policyName` and `policy ID`), instead of just 1 in the case of tags, and thus policies cannot be just saved in the same way and have to be parsed differently Additional testing was needed to ensure that the policies are saved correctly and are able to handle invalid values if the json file is edited wrongly. @@ -1274,7 +1278,9 @@ As to keep the `Person` object immutable, we had to create a new `Person` object **3. Additional Client Traits and Features**
**4. GUI**
-Some challenges arose in the designing of changes to the GUI to present all the details we wanted. This included the placement of the various panels so that they fit together well without feeling cluttered. There was also considerable time spent on the Reminders panel on the right in particular, as we were not sure at first how we wanted to show all three types of reminders (last met, birthdays, schedules) without overcrowding. Originally, all three were to be shown together in one "Reminders This Week", but we felt that it would be hard to read for the user. +Difficulty Level: 3/5
+Effort Required: 3/5
+Challenges faced: Some challenges arose in the designing of changes to the GUI to present all the details we wanted. This included the placement of the various panels so that they fit together well without feeling cluttered. There was also considerable time spent on the Reminders panel on the right in particular, as we were not sure at first how we wanted to show all three types of reminders (last met, birthdays, schedules) without overcrowding. Originally, all three were to be shown together in one "Reminders This Week", but we felt that it would be hard to read for the user. There was also some consideration on how we wanted to handle refreshing the various panels, e.g. viewing the client details as explained in [Viewing client feature](#viewing-client-feature). From 45cf958e6634f06e4d4c8b12d78188da5c4a6043 Mon Sep 17 00:00:00 2001 From: yorklim Date: Sun, 14 Apr 2024 22:12:04 +0800 Subject: [PATCH 13/14] Fix checkstyle issues in AddPolicyActivityDiagram --- docs/diagrams/AddPolicyActivityDiagram.puml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/diagrams/AddPolicyActivityDiagram.puml b/docs/diagrams/AddPolicyActivityDiagram.puml index c18ff58bc26..190fe1416fa 100644 --- a/docs/diagrams/AddPolicyActivityDiagram.puml +++ b/docs/diagrams/AddPolicyActivityDiagram.puml @@ -24,4 +24,4 @@ else ([error thrown]) endif stop -@enduml \ No newline at end of file +@enduml From 544b40d9ebc7b2175a1e90e97949527cf95de2ef Mon Sep 17 00:00:00 2001 From: getsquared Date: Sun, 14 Apr 2024 22:42:21 +0800 Subject: [PATCH 14/14] Add Remark Use Case --- docs/DeveloperGuide.md | 38 +++++++++++++++++++++++++++----------- 1 file changed, 27 insertions(+), 11 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 1357e135efb..36e52c078c0 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -566,7 +566,6 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli | `*` | manager | view all my subordinates' clients | be aware of their progress and client base | | `*` | insurance agent | get reminders of client birthday | send birthday message | -*{More to be added}* ### Use cases @@ -699,12 +698,29 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli * 1b1. ClientCare lets user know that the list is empty.
Use case ends. -**Use case: UC07 - Adding remark to client** +**Use case: UC07 - Adding notes to a client** **MSS** -1. PLACEHOLDER +1. User requests to list all clients (UC04) or find client by name (UC06). +2. ClientCare shows a list of clients. +3. User requests to add a note to a specific client in the list by index. +4. ClientCare adds a note to the client.
+5. ClientCare shows the client's details and success message to the user.
+ Use case ends. **Extensions** +* 2a. User sees that the list is empty. + * 2a1. User stops as there is no client to add a note to. + Use case ends. +* 3a. ClientCare detects that the given command is invalid. + * 3a1. ClientCare shows an error message. + * 3a2. ClientCare requests for the correct input. + * 3a3. User enters new data.
+ Steps 3a1-3a3 are repeated until the data entered are correct.
+ Use case resumes at step 4. +* 3b. ClientCare detects that the client does not exist. + * 3b1. ClientCare shows an error message.
+ Use case ends. **Use case: UC08 - Clear all client** @@ -1285,14 +1301,14 @@ testers are expected to do more *exploratory* testing. Team Size: 4 -1. **Feature Flaw** - Currently, users can only schedule one appointment per client. In future versions, we will support multiple appointments per client. -2. **Feature Flaw** - Currently, names are case-sensitive. `John` and `john` are regarded as different clients. In future versions, names will be case-insensitive. -3. **Feature Flaw** - Currently, tags only allow alphanumeric values. Spaces and special characters are not allowed. In future versions, we will support the use of spaces and special characters for tags. -4. **Feature Flaw** - Currently, users are not allowed to use special characters like `/` when adding or editing the client name. In future versions, we will support the use of special characters like `/` for names. -5. **Feature Flaw** - Currently, users must fulfill all compulsory parameters to add a client. In future versions, we will make more parameters optional. -6. **Feature Flaw** - Currently, users must re-sort the client list after adding, editing or updating clients. Client List does not auto update or re-sort itself upon adding/editing or updating. In future versions, we will support the auto sorting when clients are updated. -7. **UI Bug** - Currently, the policy name and policy id may get truncated if there are too many characters. In future versions, we will support the wrapping of fields in the Policy Display. -8. **UI Bug** - Currently, the phone number and remark may get truncated if they are too long. In future versions, we will support the wrapping of all fields in the Client View Display. +1. **Add Scheduling Multiple Appointments Per Client** - Currently, users can only schedule one appointment per client. In future versions, we will support multiple appointments per client. +2. **Make Names Case-insensitive** - Currently, names are case-sensitive. `John` and `john` are regarded as different clients. In future versions, names will be case-insensitive. +3. **Allow Special Characters For Tags** - Currently, tags only allow alphanumeric values. Spaces and special characters are not allowed. In future versions, we will support the use of spaces and special characters for tags. +4. **Allow Special Characters For Names** - Currently, users are not allowed to use special characters like `/` when adding or editing the client name. In future versions, we will support the use of special characters like `/` for names. +5. **Make Parameters For Adding Clients Optional** - Currently, users must fulfill all compulsory parameters to add a client. In future versions, we will make more parameters optional. +6. **Retain Sorting Order After Commands** - Currently, users must re-sort the client list after adding, editing or updating clients. Client List does not auto update or re-sort itself upon adding/editing or updating. In future versions, we will support the auto sorting when clients are updated. +7. **Fix Text Truncation In Policy Table** - Currently, the policy name and policy id may get truncated if there are too many characters. In future versions, we will support the wrapping of fields in the Policy Display. +8. **Fix Text Truncation In Client Details** - Currently, the name, tags, phone number, address, email and remark may get truncated if they are too long. In future versions, we will support the wrapping of all fields in the Client View Display. --------------------------------------------------------------------------------------------------------------------