Skip to content

Commit

Permalink
Merge pull request #136 from AY2324S2-CS2103T-T15-2/documentation_1.3
Browse files Browse the repository at this point in the history 
Add more features to DG
  • Loading branch information
@hjuntan
hjuntan authored Apr 3, 2024
2 parents a2ffce9 + 4895684 commit bac57dd
Show file tree
Hide file tree
Showing 6 changed files with 95 additions and 244 deletions.
194 changes: 59 additions & 135 deletions docs/DeveloperGuide.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
pageNav: 3
---

# AB-3 Developer Guide
# AronaPro Developer Guide

<!-- * Table of Contents -->
<page-nav-print />
Expand Down Expand Up @@ -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`.

<box type="info" seamless>

**Note:** There can be 0 or more optional `group`.

</box>

#### 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.

<box type="info" seamless>

**Note:** If a command fails its execution, it will not call `Model#addPerson()` and the person will not be added to the address book.

</box>

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

<puml src="diagrams/AddSequenceDiagram.puml" alt="AddSequenceDiagram" />

The following activity diagram summarizes what happens when a user inputs a schedule command:

<puml src="diagrams/AddDiagram.puml" width="250" />

#### 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.

<box type="info" seamless>

**Note:** If `remark` is present, `date` has to be present as well.

</box>

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.

<box type="info" seamless>

**Note:** If a command fails its execution, it will not call `Model#setPerson()` and the schedule will not be updated for that person.

</box>

The following sequence diagram shows how a schedule operation goes through the `Logic` component:

<puml src="diagrams/ScheduleSequenceDiagram.puml" alt="ScheduleSequenceDiagram" />

The following activity diagram summarizes what happens when a user inputs a schedule command:

<puml src="diagrams/ScheduleDiagram.puml" width="250" />

#### 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
Expand Down Expand Up @@ -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`.

<box type="info" seamless>

**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`.

</box>

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:

<puml src="diagrams/ScheduleSequenceDiagram.puml" alt="ScheduleSequenceDiagram" />

<box type="info" seamless>

**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.

</box>

The following activity diagram summarizes what happens when a user executes a schedule command:

<puml src="diagrams/ScheduleDiagram.puml" width="250" />

#### 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}_


Expand Down
25 changes: 13 additions & 12 deletions docs/UserGuide.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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.

<!-- * Table of Contents -->
<page-nav-print />
Expand All @@ -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.<br>
Some example commands you can try:

* `list` : Lists all contacts.
* `view` : Lists all contacts.

* `add n/John Doe p/98765432 e/[email protected] a/John street, block 123, #01-01` : Adds a contact named `John Doe` to the Address Book.

Expand Down Expand Up @@ -60,7 +60,7 @@ AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized fo
* Parameters can be in any order.<br>
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.<br>
* Extraneous parameters for commands that do not take in parameters (such as `help`, `view`, `exit` and `clear`) will be ignored.<br>
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.
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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'**

Expand All @@ -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`

Expand Down Expand Up @@ -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`

Expand Down Expand Up @@ -258,6 +258,7 @@ _Details coming soon ..._
| **Find** | `find [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [t/TAG] [g/GROUP]`<br> e.g., `find n/James g/CS2103T` |
| **Group** | `group [id/NUSID] [g/GROUP] [t/TAG] ` |
| **Schedule** | `schedule id/NUSID s/DATE [r/REMARK]` <br> e.g., `schedule id/E1234567 s/12-12-2021 r/Consultation` |
| **Pin** | `pin id/NUSID` |
| **View** | `view` |
| **Help** | `help` |

21 changes: 0 additions & 21 deletions docs/diagrams/AddDiagram.puml
View file

This file was deleted.

Loading

0 comments on commit bac57dd

Please sign in to comment.