Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more features to DG #136

Merged
merged 7 commits into from
Apr 3, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
194 changes: 59 additions & 135 deletions docs/DeveloperGuide.md
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
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

This file was deleted.

Loading
Loading