diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index c0128da810e..edc3b370c6b 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -4,7 +4,7 @@ pageNav: 3 --- -# AB-3 Developer Guide +# AronaPro Developer Guide @@ -158,136 +158,6 @@ Classes used by multiple components are in the `seedu.addressbook.commons` packa This section describes some noteworthy details on how certain features are implemented. -### `Add` feature - -`Add` for a person can be added using the `add` command. The `AddCommand` class is responsible for handling the addition of a person. This command is implemented through `AddCommand` which extend the `Command` class. - -A new `Person` can be added by specifying `nusId`, `name`, `phone`, `email`, `tags` and optional `group`. - - - -**Note:** There can be 0 or more optional `group`. - - - -#### Proposed Implementation - -Given below is an example usage scenario and how the `AddCommand` mechanism behaves at each step. - -Step 1. The user executes `add` command. - -Step 2. The `AddressBookParser` will call `parseCommand` on the user's input string and return an instance of `AddCommandParser`. - -Step 3. `AddCommandParser` will call `parse` which create instances of objects for each of the fields and return an instance of `AddCommand`. - -Step 4. The `LogicManager` calls the `execute` method in `AddCommand`. - -Step 5. The `execute` method in `AddCommand` executes and calls `Model#addPerson()` to add the person to the address book. - -Step 6. Success message is printed onto the results display to notify user. - - - -**Note:** If a command fails its execution, it will not call `Model#addPerson()` and the person will not be added to the address book. - - - -The following sequence diagram shows how an add operation goes through the `Logic` component: - - - -The following activity diagram summarizes what happens when a user inputs a schedule command: - - - -#### Design considerations: - -**How add executes** - -* User inputs an `add` command with `nusId`, `name`, `phone`, `email`, `tags` and optional `group` fields. The inputs are parsed and a `AddCommand` is created. -* The instances of the relevant fields are created and the person is added to the model. - -**Alternative considerations** - -* **Alternative 1 (current choice):** Create instances of objects for each of the fields and add the person to the model. - * Pros: Allow for each field to be validated before adding the person. - * Cons: Additional checks are required - - - -### `Schedule` feature - -#### Proposed Implementation - -`Schedule` for a person can be added or removed using the `schedule` command. The `ScheduleCommand` class is responsible for handling the scheduling of events for a person. This command is implemented through `ScheduleCommand` which extend the `Command` class. - -A new `Schedule` can be added by specifying `nusId`, `date` and an optional `remark`. If the `date` is not specified, the schedule will be removed instead. - - - -**Note:** If `remark` is present, `date` has to be present as well. - - - -Given below is an example usage scenario and how the `ScheduleCommand` mechanism behaves at each step. - -Step 1. The user executes `schedule` command. - -Step 2. The `AddressBookParser` will call `parseCommand` on the user's input string and return an instance of `ScheduleCommandParser`. - -Step 3. `ScheduleCommandParser` will call `parse` which create instances of objects for each of the fields and return an instance of `ScheduleCommand`. - -Step 4. The `LogicManager` calls the `execute` method in `ScheduleCommand`. - -Step 5. The `execute` method in `ScheduleCommand` executes and calls `Model#getFilteredPersonList()` to get a list of person in the address book and filter to find the relevant person with the given `nusId`. - -Step 6. `Model#setPerson()` is called to update the schedule for that person. - -Step 7. Success message is printed onto the results display to notify user. - - - -**Note:** If a command fails its execution, it will not call `Model#setPerson()` and the schedule will not be updated for that person. - - - -The following sequence diagram shows how a schedule operation goes through the `Logic` component: - - - -The following activity diagram summarizes what happens when a user inputs a schedule command: - - - -#### Design considerations: - -**How schedule executes** - -* User inputs a `schedule` command with `nusId`, `date` and an optional `remark`. The inputs are parsed and a `ScheduleCommand` is created. -* A list of persons is retrieved from `model` and the relevant person is found by matching `nusId`. -* The relevant fields are updated for the person and the person is set back into the model. - -**Why is it implemented this way?** - -* The functionality of adding and removing schedule is similar to the `EditCommand`. Both require changes in the `Person` object. -* Hence, the approach is similar to how `edit` command works. - -**Alternative considerations** - -* **Alternative 1 (current choice):** Set the schedule for the person by indicating `date`, otherwise remove schedule. - * Pros: Easy to implement. - * Cons: Additional checks are required to check if it is an add or remove schedule command. - -* **Alternative 2:** Introduce add schedule and remove schedule command as separate commands. - * Pros: There is usage of Single Responsibility Principle. - * Cons: We must ensure that the implementation of each individual command are correct. - -* **Alternative 3:** Since schedule and edit commands are similar, we could consider adding a generic class which both extend from. - * Pros: It follows the DRY principle. - * Cons: We must ensure that the implementation of each individual command are correct. - - - ### \[Proposed\] Undo/redo feature #### Proposed Implementation @@ -371,14 +241,68 @@ The following activity diagram summarizes what happens when a user executes a ne **Aspect: How undo & redo executes:** * **Alternative 1 (current choice):** Saves the entire address book. - * Pros: Easy to implement. - * Cons: May have performance issues in terms of memory usage. + * Pros: Easy to implement. + * Cons: May have performance issues in terms of memory usage. * **Alternative 2:** Individual command knows how to undo/redo by itself. - * Pros: Will use less memory (e.g. for `delete`, just save the person being deleted). + * Pros: Will use less memory (e.g. for `delete`, just save the person being deleted). + * Cons: We must ensure that the implementation of each individual command are correct. + +_{more aspects and alternatives to be added}_ + + +### Schedule feature + +#### Proposed Implementation + +The schedule mechanism is facilitated by `ScheduleCommand` and it extends `Command`. A schedule is added if s/ and/or r/ parameter is present. Otherwise if s/ parameter is absent, the schedule is removed. Additionally, it implements the following operations: + +* `ScheduleCommand#execute()` — Execute the schedule command for the given person. +* `ScheduleCommand#generateSuccessMessage()` — Generate message for either add schedule or remove schedule. + +`ScheduleCommand#execute()` is exposed in the `Logic` interface as `Logic#execute()`. + +Given below is an example usage scenario and how the `ScheduleCommand` mechanism behaves at each step. + +Step 1. The user launches the application. The `AddressBook` will be initialized with the initial address book state. + +Step 2. The user executes `schedule id/E1234567 s/20-12-2022 r/Consultation at 3pm` command to schedule a consultation session with person nusId E1234567 at date 20-12-2022 in the address book. The `schedule` command calls `Model#getFilteredPersonList()` to get a list of person in the `addressbook` and filter to find the relevant person with the given nusId. `Model#setPerson()` is called to update the schedule for that person in `addressbook`. + + + +**Note:** If a command fails its execution, it will not call `Model#setPerson()`, so the schedule will not be updated for that person in `addressbook`. + + + +Step 3. Now the user decides to remove the schedule with that person. The user executes `schedule id/E1234567` to remove the schedule.`schedule` again calls `Model#getFilteredPersonList()` and filter to find the relevant person. `Model#setPerson()` is called to remove the schedule for that person in `addressbook`. + +The following sequence diagram shows how a schedule operation goes through the `Logic` component: + + + + + +**Note:** The lifeline for `ScheduleCommand` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram. + + + +The following activity diagram summarizes what happens when a user executes a schedule command: + + + +#### Design considerations: + +**Aspect: How schedule executes:** + +* **Alternative 1 (current choice):** Set the schedule for the person by using s/ parameter. Remove schedule by removing s/ parameter. + * Pros: Easy to implement. + * Cons: Additional checks are required to check if it is an add or remove schedule command. + +* **Alternative 2:** Introduce add schedule and remove schedule command as separate commands. + * Pros: There is usage of Single Responsibility Principle. * Cons: We must ensure that the implementation of each individual command are correct. - + _{more aspects and alternatives to be added}_ diff --git a/docs/UserGuide.md b/docs/UserGuide.md index 372755423e6..76e88884cf4 100644 --- a/docs/UserGuide.md +++ b/docs/UserGuide.md @@ -4,9 +4,9 @@ pageNav: 3 --- -# AB-3 User Guide +# AronaPro User Guide -AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized for use via a Line Interface** (CLI) while still having the benefits of a Graphical User Interface (GUI). If you can type fast, AB3 can get your contact management tasks done faster than traditional GUI apps. +AronaPro is a **desktop app for managing contacts, optimized for use via a Line Interface** (CLI) while still having the benefits of a Graphical User Interface (GUI). If you can type fast, AB3 can get your contact management tasks done faster than traditional GUI apps. @@ -28,7 +28,7 @@ AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized fo 1. Type the command in the command box and press Enter to execute it. e.g. typing **`help`** and pressing Enter will open the help window.
Some example commands you can try: - * `list` : Lists all contacts. + * `view` : Lists all contacts. * `add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01` : Adds a contact named `John Doe` to the Address Book. @@ -60,7 +60,7 @@ AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized fo * Parameters can be in any order.
e.g. if the command specifies `n/NAME p/PHONE_NUMBER`, `p/PHONE_NUMBER n/NAME` is also acceptable. -* Extraneous parameters for commands that do not take in parameters (such as `help`, `list`, `exit` and `clear`) will be ignored.
+* Extraneous parameters for commands that do not take in parameters (such as `help`, `view`, `exit` and `clear`) will be ignored.
e.g. if the command specifies `help 123`, it will be interpreted as `help`. * If you are using a PDF version of this document, be careful when copying and pasting commands that span multiple lines as space characters surrounding line-breaks may be omitted when copied over to the application. @@ -100,9 +100,9 @@ Format: `view` Edits an existing person in the address book. -Format: `edit nusId [n/NAME] [p/PHONE] [e/EMAIL] [t/TAG] [g/GROUP]` +Format: `edit NUSID [n/NAME] [p/PHONE] [e/EMAIL] [t/TAG] [g/GROUP]` -* Edits the person with a specified `nusId`. The nusId refers to the nusId shown in the displayed person list. The nusId **must be a 7-digit number following an 'E'** +* Edits the person with a specified `NUSID`. The nusId refers to the nusId shown in the displayed person list. The nusId **must be a 7-digit number following an 'E'** * At least one of the optional fields must be provided. * Existing values will be updated to the input values. * When editing tags, the valid forms have to be either 1 of these: Professor, TA, Student, None @@ -138,9 +138,9 @@ Examples: Deletes the specified person from the address book. -Format 1: `delete id/nusId` +Format 1: `delete id/NUSID` -* Deletes the person of a specified `nusId`. +* Deletes the person of a specified `NUSID`. * The nusId refers to the nusId shown in the displayed person list. * The nusId **must be a 7-digit number following an 'E'** @@ -162,13 +162,13 @@ Assigns the specified person either a group or a tag from the address book. Format: `group [id/NUSID] [g/GROUP] [t/TAG]` -* Edits the person with a specified `nusId`. The nusId refers to the nusId shown in the displayed person list. The nusId **must be a 7-digit number following an 'E'** +* Edits the person with a specified `NUSID`. The nusId refers to the nusId shown in the displayed person list. The nusId **must be a 7-digit number following an 'E'** * At least one of the optional fields must be provided. * When editing tags, the valid forms have to be either 1 of these: Group, Tag Examples: * `group id/E0123456 g/CS2101-T15` will assign the person with nusid E0123456 to the group CS2101-T15 -* `group id/E0123456 t/STUDENT` will assign the person with nusid E0123456 to the student tag +* `group id/E0123456 t/Student` will assign the person with nusid E0123456 to the student tag ### Schedule a meeting with a person: `schedule` @@ -196,10 +196,10 @@ Examples: Pins a person to the address book. -Format: `pin id/nusId` +Format: `pin id/NUSID` Examples: -* `pin id/E0123456` will pin an existing person with `nusId` of "E0123456". +* `pin id/E0123456` will pin an existing person with `NUSID` of "E0123456". ### Clearing all entries : `clear` @@ -258,6 +258,7 @@ _Details coming soon ..._ | **Find** | `find [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [t/TAG] [g/GROUP]`
e.g., `find n/James g/CS2103T` | | **Group** | `group [id/NUSID] [g/GROUP] [t/TAG] ` | | **Schedule** | `schedule id/NUSID s/DATE [r/REMARK]`
e.g., `schedule id/E1234567 s/12-12-2021 r/Consultation` | +| **Pin** | `pin id/NUSID` | | **View** | `view` | | **Help** | `help` | diff --git a/docs/diagrams/AddDiagram.puml b/docs/diagrams/AddDiagram.puml deleted file mode 100644 index 0a93d7926e5..00000000000 --- a/docs/diagrams/AddDiagram.puml +++ /dev/null @@ -1,21 +0,0 @@ -@startuml -skin rose -skinparam ActivityFontSize 15 -skinparam ArrowFontSize 12 -start -:User inputs add command; -:Parse add command; - -'Since the beta syntax does not support placing the condition outside the -'diamond we place it as the true branch instead. - -if () then ([valid command]) - :Execute add command; - :Edit person's details; - :Save modified person in AddressBook; - :Display success message; -else ([else]) - :Display error message; -endif -stop -@enduml diff --git a/docs/diagrams/AddSequenceDiagram.puml b/docs/diagrams/AddSequenceDiagram.puml deleted file mode 100644 index e973183b880..00000000000 --- a/docs/diagrams/AddSequenceDiagram.puml +++ /dev/null @@ -1,70 +0,0 @@ -@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 ":AddCommandParser" as AddCommandParser LOGIC_COLOR -participant "a:AddCommand" as AddCommand LOGIC_COLOR -participant "r:CommandResult" as CommandResult LOGIC_COLOR -end box - -box Model MODEL_COLOR_T1 -participant "m:Model" as Model MODEL_COLOR -end box - -[-> LogicManager : execute("add...") -activate LogicManager - -LogicManager -> AddressBookParser : parseCommand("add...") -activate AddressBookParser - -create AddCommandParser -AddressBookParser -> AddCommandParser -activate AddCommandParser - -AddCommandParser --> AddressBookParser -deactivate AddCommandParser - -AddressBookParser -> AddCommandParser : parse("nusId, ...") -activate AddCommandParser - -create AddCommand -AddCommandParser -> AddCommand : AddCommand(nusId, ...) -activate AddCommand - -AddCommand --> AddCommandParser : a -deactivate AddCommand - -AddCommandParser --> AddressBookParser : a -deactivate AddCommandParser -'Hidden arrow to position the destroy marker below the end of the activation bar. -AddCommandParser -[hidden]-> AddressBookParser -destroy AddCommandParser - -AddressBookParser --> LogicManager : a -deactivate AddressBookParser - -LogicManager -> AddCommand : execute(m) -activate AddCommand - -AddCommand -> Model : addPerson(personToAdd) -activate Model - -Model --> AddCommand -deactivate Model - -create CommandResult -AddCommand -> CommandResult -activate CommandResult - -CommandResult --> AddCommand -deactivate CommandResult - -AddCommand --> LogicManager : r -deactivate AddCommand - -[<--LogicManager -deactivate LogicManager -@enduml diff --git a/docs/diagrams/ScheduleDiagram.puml b/docs/diagrams/ScheduleDiagram.puml index 78082712c38..5206397945b 100644 --- a/docs/diagrams/ScheduleDiagram.puml +++ b/docs/diagrams/ScheduleDiagram.puml @@ -4,13 +4,13 @@ skinparam ActivityFontSize 15 skinparam ArrowFontSize 12 start + :User inputs schedule command; :Parse schedule command; 'Since the beta syntax does not support placing the condition outside the 'diamond we place it as the true branch instead. - if () then ([valid command]) :Parse schedule command; :Execute schedule command; @@ -18,7 +18,6 @@ if () then ([valid command]) AddressBook; :Display success message; else ([else]) - :Display error message; endif stop @enduml diff --git a/docs/diagrams/ScheduleSequenceDiagram.puml b/docs/diagrams/ScheduleSequenceDiagram.puml index ef1ae64b367..79149cf36f6 100644 --- a/docs/diagrams/ScheduleSequenceDiagram.puml +++ b/docs/diagrams/ScheduleSequenceDiagram.puml @@ -6,6 +6,7 @@ box Logic LOGIC_COLOR_T1 participant ":LogicManager" as LogicManager LOGIC_COLOR participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR participant ":ScheduleCommandParser" as ScheduleCommandParser LOGIC_COLOR +participant ":ParserUtil" as ParserUtil LOGIC_COLOR participant "s:ScheduleCommand" as ScheduleCommand LOGIC_COLOR participant "r:CommandResult" as CommandResult LOGIC_COLOR end box @@ -14,10 +15,10 @@ box Model MODEL_COLOR_T1 participant "m:Model" as Model MODEL_COLOR end box -[-> LogicManager : execute("schedule...") +[-> LogicManager : execute("schedule id/E1234567 s/15-10-2024") activate LogicManager -LogicManager -> AddressBookParser : parseCommand("schedule...") +LogicManager -> AddressBookParser : parseCommand("schedule id/E1234567 s/15-10-2024") activate AddressBookParser create ScheduleCommandParser @@ -27,14 +28,31 @@ activate ScheduleCommandParser ScheduleCommandParser --> AddressBookParser deactivate ScheduleCommandParser -AddressBookParser -> ScheduleCommandParser : parse("nusId, ...") +AddressBookParser -> ScheduleCommandParser : parse("id/E1234567 s/15-10-2024") activate ScheduleCommandParser +create ParserUtil +ScheduleCommandParser -> ParserUtil + +activate ParserUtil +ParserUtil ---> ScheduleCommandParser +deactivate ParserUtil + +ScheduleCommandParser -> ParserUtil : parseNusId("E01234567") +activate ParserUtil +ParserUtil ---> ScheduleCommandParser +deactivate ParserUtil + +ScheduleCommandParser -> ParserUtil : parseSchedule("15-10-2024") +activate ParserUtil +ParserUtil ---> ScheduleCommandParser +deactivate ParserUtil + create ScheduleCommand ScheduleCommandParser -> ScheduleCommand : ScheduleCommand(nusId, schedule, remark) activate ScheduleCommand -ScheduleCommand --> ScheduleCommandParser : s +ScheduleCommand --> ScheduleCommandParser : deactivate ScheduleCommand ScheduleCommandParser --> AddressBookParser : s