diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md
index 1f969f45036..565e313845d 100644
--- a/docs/DeveloperGuide.md
+++ b/docs/DeveloperGuide.md
@@ -4,7 +4,7 @@ title: "Developer Guide"
pageNav: 3
---
-# AB-3 Developer Guide
+# D.A.V.E. Developer Guide
@@ -13,7 +13,7 @@ pageNav: 3
## **Acknowledgements**
-_{ list here sources of all reused/adapted ideas, code, documentation, and third-party libraries -- include links to the original source as well }_
+This project is based on [AB-3](https://github.com/se-edu/addressbook-level3).
--------------------------------------------------------------------------------------------------------------------
## **Setting up, getting started**
@@ -26,8 +26,9 @@ Refer to the guide [_Setting up and getting started_](SettingUp.md).
### Architecture
-
-
+
+
+
The ***Architecture Diagram*** given above explains the high-level design of the App.
@@ -36,7 +37,7 @@ Given below is a quick overview of main components and how they interact with ea
**Main components of the architecture**
-**`Main`** (consisting of classes [`Main`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/Main.java) and [`MainApp`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/MainApp.java)) is in charge of the app launch and shut down.
+**`Main`** (consisting of classes [`Main`](https://github.com/AY2324S1-CS2103T-F08-2/tp/blob/master/src/main/java/seedu/address/Main.java) and [`MainApp`](https://github.com/AY2324S1-CS2103T-F08-2/tp/blob/master/src/main/java/seedu/address/MainApp.java)) is in charge of the app launch and shut down.
* At app launch, it initializes the other components in the correct sequence, and connects them up with each other.
* At shut down, it shuts down the other components and invokes cleanup methods where necessary.
@@ -54,8 +55,9 @@ The bulk of the app's work is done by the following four components:
The *Sequence Diagram* below shows how the components interact with each other for the scenario where the user issues the command `delete 1`.
-
-
+
+
+
Each of the four main components (also shown in the diagram above),
@@ -64,20 +66,23 @@ Each of the four main components (also shown in the diagram above),
For example, the `Logic` component defines its API in the `Logic.java` interface and implements its functionality using the `LogicManager.java` class which follows the `Logic` interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent outside component's being coupled to the implementation of a component), as illustrated in the (partial) class diagram below.
-
-
+
+
+
The sections below give more details of each component.
### UI component
-The **API** of this component is specified in [`Ui.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/Ui.java)
+The **API** of this component is specified in [`Ui.java`](https://github.com/AY2324S1-CS2103T-F08-2/tp/blob/master/src/main/java/seedu/address/ui/Ui.java)
-
+
+
+
The UI consists of a `MainWindow` that is made up of parts e.g.`CommandBox`, `ResultDisplay`, `PersonListPanel`, `StatusBarFooter` etc. All these, including the `MainWindow`, inherit from the abstract `UiPart` class which captures the commonalities between classes that represent parts of the visible GUI.
-The `UI` component uses the JavaFx UI framework. The layout of these UI parts are defined in matching `.fxml` files that are in the `src/main/resources/view` folder. For example, the layout of the [`MainWindow`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/MainWindow.java) is specified in [`MainWindow.fxml`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/resources/view/MainWindow.fxml)
+The `UI` component uses the JavaFx UI framework. The layout of these UI parts are defined in matching `.fxml` files that are in the `src/main/resources/view` folder. For example, the layout of the [`MainWindow`](https://github.com/AY2324S1-CS2103T-F08-2/tp/blob/master/src/main/java/seedu/address/ui/MainWindow.java) is specified in [`MainWindow.fxml`](https://github.com/AY2324S1-CS2103T-F08-2/tp/blob/master/src/main/resources/view/MainWindow.fxml)
The `UI` component,
@@ -88,15 +93,19 @@ The `UI` component,
### Logic component
-**API** : [`Logic.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/logic/Logic.java)
+**API** : [`Logic.java`](https://github.com/AY2324S1-CS2103T-F08-2/tp/blob/master/src/main/java/seedu/address/logic/Logic.java)
Here's a (partial) class diagram of the `Logic` component:
-
+
+
+
The sequence diagram below illustrates the interactions within the `Logic` component, taking `execute("delete 1")` API call as an example.
-
+
+
+
@@ -106,40 +115,48 @@ The sequence diagram below illustrates the interactions within the `Logic` compo
How the `Logic` component works:
1. When `Logic` is called upon to execute a command, it is passed to an `AddressBookParser` object which in turn creates a parser that matches the command (e.g., `DeleteCommandParser`) and uses it to parse the command.
-1. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `DeleteCommand`) which is executed by the `LogicManager`.
-1. The command can communicate with the `Model` when it is executed (e.g. to delete a person).
-1. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`.
+2. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `DeleteCommand`) which is executed by the `LogicManager`.
+3. The command can communicate with the `Model` when it is executed (e.g. to delete a person).
+4. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`.
Here are the other classes in `Logic` (omitted from the class diagram above) that are used for parsing a user command:
-
+
+
+
How the parsing works:
* When called upon to parse a user command, the `AddressBookParser` class creates an `XYZCommandParser` (`XYZ` is a placeholder for the specific command name e.g., `AddCommandParser`) which uses the other classes shown above to parse the user command and create a `XYZCommand` object (e.g., `AddCommand`) which the `AddressBookParser` returns back as a `Command` object.
* All `XYZCommandParser` classes (e.g., `AddCommandParser`, `DeleteCommandParser`, ...) inherit from the `Parser` interface so that they can be treated similarly where possible e.g, during testing.
### Model component
-**API** : [`Model.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/model/Model.java)
-
-
+**API** : [`Model.java`](https://github.com/AY2324S1-CS2103T-F08-2/tp/blob/master/src/main/java/seedu/address/model/Model.java)
+
+
+
The `Model` component,
* stores the address book data i.e., all `Person` objects (which are contained in a `UniquePersonList` object).
-* stores the currently 'selected' `Person` objects (e.g., results of a search query) as a separate _filtered_ list which is exposed to outsiders as an unmodifiable `ObservableList` that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.
+* stores the currently 'selected' `Person` objects (e.g., results of a search/sort query) as a separate _filtered and sorted_ list which is exposed to outsiders as an unmodifiable `ObservableList` that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.
* stores a `UserPref` object that represents the user’s preferences. This is exposed to the outside as a `ReadOnlyUserPref` objects.
* does not depend on any of the other three components (as the `Model` represents data entities of the domain, they should make sense on their own without depending on other components)
-
+The following diagram shows the classes that extend the abstract `Person` class.
+
+
+
The abstract `Person` class is extended by two separate classes, `Lead` and `Client`. These instances are distinguished by their `Type` field in `Person`.
-
+`Lead` objects also contain an additional `KeyMilestone` attribute.
### Storage component
-**API** : [`Storage.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/storage/Storage.java)
+**API** : [`Storage.java`](https://github.com/AY2324S1-CS2103T-F08-2/tp/blob/master/src/main/java/seedu/address/storage/Storage.java)
-
+
+
+
The `Storage` component,
* can save both address book data and user preference data in JSON format, and read them back into corresponding objects.
@@ -166,7 +183,9 @@ Step 3: The user executes a `view 1` command to view the 1st person in the addre
**Note:** If the index given is more than the size of the list or when the index given is 0, `ViewCommand` will not call `Model#view(Person personToView)`. Instead, a `MESSAGE_INVALID_PERSON_DISPLAYED_INDEX` exception will be thrown. The Main Window display continue displaying the `PersonListPanel` UI instead of the `ViewWindow` UI
The following sequence diagram shows how the View Command works:
-
+
+
+
### Add client/Add lead feature
@@ -201,7 +220,7 @@ Step 2b - `addlead`. The user executes `addlead n/John Doe...` command add a per
The following sequence diagram shows how the `addclient` operation works (Note that `addlead` works in the same way but calls `Model#addLead()` instead):
-
+
The following activity diagram shows the workflow upon execution of the `addclient` command (`addlead` works the same way):
@@ -221,7 +240,7 @@ The `AddMeetingCommand` class then calls `Model#setPerson()` to update the addre
The following sequence diagram shows how the `addmeeting ...` operation works:
-
+
The following activity diagram shows the workflow of the execution of the `addmeeting ...` command:
@@ -248,7 +267,7 @@ Given below is an example usage scenario and how `listclient` and `listlead` beh
Step 1. The user opens the application to see a list of leads and clients.
-Step 2. The user executes `listclient` command to display a filtered list of persons in the address book. The `listclient` command calls `Model#updateFilteredPersonList()`, causing the modified state of the filtered list to be displayed bsad on the `predicate` passed into the `Model#updateFilteredPersonList()`.
+Step 2. The user executes `listclient` command to display a filtered list of persons in the address book. The `listclient` command calls `Model#updateFilteredPersonList()`, causing the modified state of the filtered list to be displayed based on the `predicate` passed into the `Model#updateFilteredPersonList()`.
The following sequence diagram shows how the `listclient` operation works (Note that `listlead` works in the same way:
@@ -257,7 +276,7 @@ The following sequence diagram shows how the `listclient` operation works (Note
After addlead command
-### Convert lead to client and client to lead
+### Convert lead to client and client to lead feature
#### Implementation
@@ -265,14 +284,14 @@ The user can convert client to leads and vice versa, using the command `conver
The `execute()` command in `ConvertLeadToClientCommand` or `ConvertClientToLeadCommand` is executed.
-The `execute()` command in `ConvertLeadToClientCommand` or `ConvertClientToLeadCommand` takes in an arguement of type `Index`, and is referred to the list of items
+The `execute()` command in `ConvertLeadToClientCommand` or `ConvertClientToLeadCommand` takes in an argument of type `Index`, and is referred to the list of items
If the person is a `Lead` when using `converttoclient`, the application would create a new `Client` object with the information from `Lead` class. Similarly, this also would occur for `converttolead`
Given below is an example usage scenario and how `converttoclient` and `converttolead` behaves at each step
-
+
After converttoclient command
@@ -282,21 +301,22 @@ The following activity diagram shows what happens when a user executes `convertt
After converttoclient command
-### \[Proposed\] Sort Meeting Time feature
+### Sort Meeting Time feature
-#### Proposed Implementation
+#### Implementation
-The user can view the upcoming meetings scheduled with leads and clients sorted in chronological order.
+The user can view the upcoming meetings scheduled with leads and clients sorted in chronological order. The command is implemented as follows.
-This is achieved by entering the `sortmeeting` command, which will filter all the clients and leads with a meeting time, and then sort them chronologically.
+The `execute()` command in `SortMeetingTimeCommand` calls the `sortFilteredPersonList()` in `Model`, which first filters and returns a `FilteredList` containing only persons with a meeting time.
+This list is then sorted using the `PersonMeetingTimeComparator` to obtain the desired `SortedList` output, which is then displayed.
-The following sequence diagram shows how the `sortmeeting` operation works:
+Note that in every other operation that updates the `ObservableList` to be displayed, the `null` comparator is used instead of the `PersonMeetingTimeComparator` so no sorting occurs.
-_{sequence diagram to be added}_
-
-The following activity diagram shows what happens when a user executes the `sortmeeting` operation:
+The following sequence diagram shows how the `sortmeeting` operation works:
-_{activity diagram to be added}_
+
+
+
--------------------------------------------------------------------------------------------------------------------
@@ -374,7 +394,7 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli
| `* *` | student financial advisor | save details automatically while using the app | focus on updating D.A.V.E. with information of my clients and leads without worrying about saving data |
-### Planned Enhancement
+### Planned Enhancements
| Priority | As a student financial advisor, | I want to … | So that I can… |
|----------|---------------------------------|------------------------------------------------|----------------------------------------------------------------------------------------|
| `* *` | student financial advisor | add a policy for my clients | keep track of their policies and access them readily |
@@ -705,7 +725,6 @@ Use case ends.
### Glossary
* **Mainstream OS**: Windows, Linux, Unix, OS-X
-* **Private contact detail**: A contact detail that is not meant to be shared with others
* **Graceful scaling**: Ability for the system to handle increased user loads without significant performance loss
* **Integration**: Combining different software components together to easily incorporate additional modules or features as needed
--------------------------------------------------------------------------------------------------------------------
@@ -736,8 +755,6 @@ testers are expected to do more *exploratory* testing.
1. Re-launch the app by double-clicking the jar file.
Expected: The most recent window size and location is retained.
-1. _{ more test cases … }_
-
### Add a client
1. Add a client with a necessary fields
@@ -754,8 +771,6 @@ testers are expected to do more *exploratory* testing.
addclient: Adds a client to the address book. Parameters: n/NAME p/PHONE e/EMAIL a/ADDRESS [t/TAG]...
Example: addclient n/John Doe p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25 t/classmate
```
-1. _{ more test cases … }_
-
### Add a lead
@@ -773,7 +788,6 @@ testers are expected to do more *exploratory* testing.
addlead: Adds a lead to the address book. Parameters: n/NAME p/PHONE e/EMAIL a/ADDRESS [t/TAG]...
Example: addlead n/John Doe p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25 t/classmate
```
-1. _{ more test cases … }_
### Edit a client/lead
@@ -790,24 +804,20 @@ testers are expected to do more *exploratory* testing.
1. Test case: `edit 0`
Expected: No client/lead is edited. Error details shown in the status message.
-1. _{ more test cases … }_
-
### Deleting a client/lead
1. Deleting a client/lead while all clients/leads are being shown
1. Prerequisites: List all clients/leads using the `list` command. Multiple clients/leads in the list.
- 1. 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.
+ 1. 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.
1. Test case: `delete 0`
- Expected: No client/lead is deleted. Error details shown in the status message. Status bar remains the same.
+ Expected: No client/lead is deleted. Error details shown in the status message. Status bar remains the same.
- 1. Other incorrect delete commands to try: `delete`, `delete x`, `...` (where x is larger than the list size)
- Expected: Similar to previous.
-
-1. _{ more test cases … }_
+ 1. Other incorrect delete commands to try: `delete`, `delete x`, `...` (where x is larger than the list size)
+ Expected: Similar to previous.
### Viewing a person
@@ -835,20 +845,25 @@ testers are expected to do more *exploratory* testing.
Expected: Similar to previous
### Converting a client to lead
-1. Similar to converting a lead to client, but for client to lead
-
+1. Similar to converting a lead to client, but using the `converttolead` command on clients instead.
### Saving data
-1. Dealing with missing/corrupted data files
-
- 1. _{explain how to simulate a missing/corrupted file, and the expected behavior}_
-
-1. _{ more test cases … }_
+1. Dealing with missing data files
+ 1. Delete `data/addressbook.json`.
+ 2. Launch D.A.V.E.
+ Expected: D.A.V.E. should be populated with a sample address book.
+1. Dealing with corrupted data files
+ 1. Modify some fields in `data/addressbook.json` to become invalid. E.g. change a `keyMilestone` field to `null`.
+ 2. Launch D.A.V.E.
+ Expected: D.A.V.E. displays an empty address book with warnings sent in the console. The data file should not be modified or deleted by the application.
--------------------------------------------------------------------------------------------------------------------
## **Appendix: Planned Enhancements**
1. **Client Policy Management:** The current functionality falls short in allowing student financial advisors to monitor clients' policies and follow up as needed, as it lacks the ability to add, edit, and delete client policies. To address this limitation, we intend to develop these features in the future, ensuring student financial advisors can efficiently manage policy-related tasks.
+2. **UI Messages:** The current UI displays messages that could be confusing for users without a technical background, such as `null` when no meeting time is added. To address this limitation, we could filter out the fields containing `null` so the user does not see them.
+3. **Corrupted Data Files:** The current application displays an empty address book when an error parsing the data file occurs. The error messages are sent in the console, which may be confusing for users without a technical background. To address this limitation, we could add a clear message to be displayed when the application is launched, including information like what the error is and where the error occurred.
+4. **Repeated Names:** The current application does not allow users to add persons with identical names. While this is unlikely to happen in normal usage, it is still possible, and thus this behavior unnecessarily restricts users. To address this limitation, we could create a pop-up dialog informing users that such a person already exists, and requiring them to check and confirm before adding the new person.
diff --git a/docs/UserGuide.md b/docs/UserGuide.md
index bb684ee0fbd..dcd7a91358f 100644
--- a/docs/UserGuide.md
+++ b/docs/UserGuide.md
@@ -43,12 +43,15 @@ D.A.V.E. is here to enhance your advisory journey by simplifying information man
Here are some descriptions of the words we use throughout the User Guide:
-| Term | Definition |
-|---------|-------------------------------------------------------------------------------------------------------|
-| Command | An input from the user that tells D.A.V.E. to perform an action (e.g. add a client). |
-| GUI | Graphical User Interface (GUI) refers to the visual display of D.A.V.E that users can see. |
-| CLI | Command Line Interface (CLI) represents a text-based user interface to interact with the application. |
-| Person | A client or a lead. |
+| Term | Definition |
+|---------------|-------------------------------------------------------------------------------------------------------|
+| Command | An input from the user that tells D.A.V.E. to perform an action (e.g. add a client). |
+| GUI | Graphical User Interface (GUI) refers to the visual display of D.A.V.E that users can see. |
+| CLI | Command Line Interface (CLI) represents a text-based user interface to interact with the application. |
+| Client | A customer of the financial advisor. |
+| Lead | A contact who is deemed a potential customer. |
+| Person | A client or a lead. |
+| Key Milestone | A date of significant importance for a lead, e.g. date of graduation. |
# Quick Start
diff --git a/docs/diagrams/AddClientSequenceDiagram.png b/docs/diagrams/AddClientSequenceDiagram.png
index 440c9eb74ec..d87268609af 100644
Binary files a/docs/diagrams/AddClientSequenceDiagram.png and b/docs/diagrams/AddClientSequenceDiagram.png differ
diff --git a/docs/diagrams/AddClientSequenceDiagram.puml b/docs/diagrams/AddClientSequenceDiagram.puml
index 6a0ce507b35..079238c3f5d 100644
--- a/docs/diagrams/AddClientSequenceDiagram.puml
+++ b/docs/diagrams/AddClientSequenceDiagram.puml
@@ -5,27 +5,44 @@ skinparam ArrowFontStyle plain
box Logic LOGIC_COLOR_T1
participant ":LogicManager" as LogicManager LOGIC_COLOR
participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
-participant "u:ListClientCommand" as ListClientCommand LOGIC_COLOR
+participant ":AddClientCommandParser" as AddClientCommandParser LOGIC_COLOR
+participant "a:AddClientCommand" as AddClientCommand LOGIC_COLOR
+participant ":CommandResult" as CommandResult LOGIC_COLOR
end box
box Model MODEL_COLOR_T1
participant ":Model" as Model MODEL_COLOR
participant ":AddressBook" as AddressBook MODEL_COLOR
end box
-[-> LogicManager : execute(listclient n/...)
+[-> LogicManager : execute("addclient n/...")
activate LogicManager
-LogicManager -> AddressBookParser : parseCommand(listclient n/...)
+LogicManager -> AddressBookParser : parseCommand("addclient n/...")
activate AddressBookParser
+create AddClientCommandParser
+AddressBookParser -> AddClientCommandParser
+activate AddClientCommandParser
+
+AddClientCommandParser --> AddressBookParser
+deactivate AddClientCommandParser
+
+AddressBookParser -> AddClientCommandParser : parse("n/...")
+activate AddClientCommandParser
+
create AddClientCommand
-AddressBookParser -> AddClientCommand
+AddClientCommandParser -> AddClientCommand
activate AddClientCommand
-AddClientCommand --> AddressBookParser
+AddClientCommand --> AddClientCommandParser : a
deactivate AddClientCommand
-AddressBookParser --> LogicManager : return something
+AddClientCommandParser --> AddressBookParser : a
+deactivate AddClientCommandParser
+AddClientCommandParser -[hidden]-> AddressBookParser : a
+destroy AddClientCommandParser
+
+AddressBookParser --> LogicManager : a
deactivate AddressBookParser
LogicManager -> AddClientCommand : execute()
@@ -37,13 +54,21 @@ activate Model
Model -> AddressBook : addClient()
activate AddressBook
+AddressBook --> Model
+deactivate AddressBook
+
Model --> AddClientCommand
deactivate Model
+create CommandResult
+AddClientCommand -> CommandResult
+activate CommandResult
+
+CommandResult --> AddClientCommand
+deactivate CommandResult
+
AddClientCommand --> LogicManager : result
deactivate AddClientCommand
-AddClientCommand -[hidden]-> LogicManager : result
-destroy AddClientCommand
[<--LogicManager
deactivate LogicManager
diff --git a/docs/diagrams/AddMeetingTimeSequenceDiagram.png b/docs/diagrams/AddMeetingTimeSequenceDiagram.png
index 3c2f2eededd..c09787ef650 100644
Binary files a/docs/diagrams/AddMeetingTimeSequenceDiagram.png and b/docs/diagrams/AddMeetingTimeSequenceDiagram.png differ
diff --git a/docs/diagrams/AddMeetingTimeSequenceDiagram.puml b/docs/diagrams/AddMeetingTimeSequenceDiagram.puml
index e6dd917e0a6..2d0c51e3494 100644
--- a/docs/diagrams/AddMeetingTimeSequenceDiagram.puml
+++ b/docs/diagrams/AddMeetingTimeSequenceDiagram.puml
@@ -5,7 +5,9 @@ skinparam ArrowFontStyle plain
box Logic LOGIC_COLOR_T1
participant ":LogicManager" as LogicManager LOGIC_COLOR
participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
-participant "u:AddMeetingCommand" as AddMeetingCommand LOGIC_COLOR
+participant ":CommandResult" as CommandResult LOGIC_COLOR
+participant ":AddMeetingCommandParser" as AddMeetingCommandParser LOGIC_COLOR
+participant "a:AddMeetingCommand" as AddMeetingCommand LOGIC_COLOR
end box
box Model MODEL_COLOR_T1
@@ -13,43 +15,74 @@ participant ":Model" as Model MODEL_COLOR
participant "personWithMeetingAdded:Person" as Person MODEL_COLOR
end box
-[-> LogicManager : execute(addmeeting ...)
+[-> LogicManager : execute("addmeeting 1 m/...")
activate LogicManager
-LogicManager -> AddressBookParser : parseCommand(addmeeting ...)
+LogicManager -> AddressBookParser : parseCommand("addmeeting 1 m/...")
activate AddressBookParser
+create AddMeetingCommandParser
+AddressBookParser -> AddMeetingCommandParser
+activate AddMeetingCommandParser
+
+AddMeetingCommandParser --> AddressBookParser
+deactivate AddMeetingCommandParser
+
+AddressBookParser -> AddMeetingCommandParser : parse("1 m/...")
+activate AddMeetingCommandParser
+
create AddMeetingCommand
-AddressBookParser -> AddMeetingCommand
+AddMeetingCommandParser -> AddMeetingCommand
activate AddMeetingCommand
-AddMeetingCommand --> AddressBookParser
+AddMeetingCommand --> AddMeetingCommandParser : a
deactivate AddMeetingCommand
-AddressBookParser --> LogicManager : u
+AddMeetingCommandParser --> AddressBookParser : a
+deactivate AddMeetingCommandParser
+AddMeetingCommandParser -[hidden]-> AddressBookParser : a
+destroy AddMeetingCommandParser
+
+AddressBookParser --> LogicManager : a
deactivate AddressBookParser
LogicManager -> AddMeetingCommand : execute()
activate AddMeetingCommand
+AddMeetingCommand -> Model : getFilteredPersonList()
+activate Model
+
+Model --> AddMeetingCommand
+deactivate Model
+
create Person
AddMeetingCommand -> Person
activate Person
+
Person --> AddMeetingCommand
deactivate Person
AddMeetingCommand -> Model : setPerson(personToAddMeeting, personWithMeetingAdded)
activate Model
+Model --> AddMeetingCommand
+deactivate Model
+
+AddMeetingCommand -> Model : updateFilteredPersonList()
+activate Model
Model --> AddMeetingCommand
deactivate Model
+create CommandResult
+AddMeetingCommand -> CommandResult
+activate CommandResult
+
+CommandResult --> AddMeetingCommand : result
+deactivate CommandResult
AddMeetingCommand --> LogicManager : result
deactivate AddMeetingCommand
-AddMeetingCommand -[hidden]-> LogicManager : result
-destroy AddMeetingCommand
[<--LogicManager
deactivate LogicManager
diff --git a/docs/diagrams/ConvertLeadToClientSequence.png b/docs/diagrams/ConvertLeadToClientSequence.png
index c195540f017..fecfec8c35c 100644
Binary files a/docs/diagrams/ConvertLeadToClientSequence.png and b/docs/diagrams/ConvertLeadToClientSequence.png differ
diff --git a/docs/diagrams/ConvertLeadToClientSequence.puml b/docs/diagrams/ConvertLeadToClientSequence.puml
index 24a100fbbf0..2101938c3e9 100644
--- a/docs/diagrams/ConvertLeadToClientSequence.puml
+++ b/docs/diagrams/ConvertLeadToClientSequence.puml
@@ -6,40 +6,81 @@ box Logic LOGIC_COLOR_T1
participant ":LogicManager" as LogicManager LOGIC_COLOR
participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
participant ":ConvertLeadToClientCommandParser" as ConvertLeadToClientCommandParser LOGIC_COLOR
-participant ":ConvertLeadToClientCommand" as ConvertLeadToClientCommand LOGIC_COLOR
+participant "c:ConvertLeadToClientCommand" as ConvertLeadToClientCommand LOGIC_COLOR
+participant ":CommandResult" as CommandResult LOGIC_COLOR
end box
box Model MODEL_COLOR_T1
participant ":Model" as Model MODEL_COLOR
+participant "convertedLead:Person" as Person MODEL_COLOR
end box
-[-> LogicManager : execute(converttoclient )
+[-> LogicManager : execute("converttoclient 1")
activate LogicManager
-LogicManager -> AddressBookParser : parseCommand(converttoclient )
+LogicManager -> AddressBookParser : parseCommand("converttoclient 1")
activate AddressBookParser
-AddressBookParser --> LogicManager
-deactivate AddressBookParser
+create ConvertLeadToClientCommandParser
+AddressBookParser -> ConvertLeadToClientCommandParser
+activate ConvertLeadToClientCommandParser
+ConvertLeadToClientCommandParser --> AddressBookParser
+deactivate
-AddressBookParser -> ConvertLeadToClientCommandParser : parse(converttoclient )
+AddressBookParser -> ConvertLeadToClientCommandParser : parse("1")
activate ConvertLeadToClientCommandParser
create ConvertLeadToClientCommand
ConvertLeadToClientCommandParser -> ConvertLeadToClientCommand
activate ConvertLeadToClientCommand
+ConvertLeadToClientCommand --> ConvertLeadToClientCommandParser : c
+deactivate ConvertLeadToClientCommand
+
+ConvertLeadToClientCommandParser --> AddressBookParser : c
+deactivate
+ConvertLeadToClientCommandParser -[hidden]-> AddressBookParser : c
+destroy ConvertLeadToClientCommandParser
+
+AddressBookParser --> LogicManager : c
+deactivate AddressBookParser
+
+LogicManager -> ConvertLeadToClientCommand : execute()
+activate ConvertLeadToClientCommand
+
ConvertLeadToClientCommand -> Model : getFilteredPersonList()
activate Model
Model --> ConvertLeadToClientCommand : List of Persons
-ConvertLeadToClientCommand -> Model : setPerson()
-ConvertLeadToClientCommand -> Model : updateFilterPredicate()
deactivate Model
-ConvertLeadToClientCommand --> LogicManager : CommandResult
+create Person
+ConvertLeadToClientCommand -> Person
+activate Person
+
+Person --> ConvertLeadToClientCommand
+deactivate
+
+ConvertLeadToClientCommand -> Model : setPerson(personToConvert, convertedLead)
+activate Model
+Model --> ConvertLeadToClientCommand
+deactivate Model
+
+ConvertLeadToClientCommand -> Model : updateFilteredPersonList()
+activate Model
+Model --> ConvertLeadToClientCommand
+deactivate Model
+
+create CommandResult
+ConvertLeadToClientCommand -> CommandResult
+activate CommandResult
+
+CommandResult --> ConvertLeadToClientCommand : result
+deactivate CommandResult
+
+ConvertLeadToClientCommand --> LogicManager : result
deactivate ConvertLeadToClientCommand
deactivate ConvertLeadToClientCommandParser
deactivate AddressBookParser
diff --git a/docs/diagrams/ListClientCommandSequence.png b/docs/diagrams/ListClientCommandSequence.png
index bb646914644..803b8744301 100644
Binary files a/docs/diagrams/ListClientCommandSequence.png and b/docs/diagrams/ListClientCommandSequence.png differ
diff --git a/docs/diagrams/ListClientCommandSequence.puml b/docs/diagrams/ListClientCommandSequence.puml
index b3d4c2fa5ca..0c919258ff8 100644
--- a/docs/diagrams/ListClientCommandSequence.puml
+++ b/docs/diagrams/ListClientCommandSequence.puml
@@ -6,34 +6,48 @@ box Logic LOGIC_COLOR_T1
participant ":LogicManager" as LogicManager LOGIC_COLOR
participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
participant "u:ListClientCommand" as ListClientCommand 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(listclient)
+[-> LogicManager : execute("listclient")
activate LogicManager
-LogicManager -> AddressBookParser : parseCommand(listclient)
+LogicManager -> AddressBookParser : parseCommand("listclient")
activate AddressBookParser
-AddressBookParser --> LogicManager
-deactivate AddressBookParser
create ListClientCommand
-AddressBookParser -> ListClientCommand : execute()
+AddressBookParser -> ListClientCommand
activate ListClientCommand
-ListClientCommand -> Model : updateFilterPredicate()
+ListClientCommand --> AddressBookParser : u
+deactivate ListClientCommand
+
+AddressBookParser --> LogicManager : u
+deactivate AddressBookParser
+
+LogicManager -> ListClientCommand : execute()
+activate ListClientCommand
+
+ListClientCommand -> Model : updateFilteredPersonList()
activate Model
Model --> ListClientCommand
deactivate Model
+create CommandResult
+ListClientCommand -> CommandResult
+activate CommandResult
+
+CommandResult --> ListClientCommand : result
+deactivate
+
ListClientCommand --> LogicManager : result
deactivate ListClientCommand
-destroy ListClientCommand
[<--LogicManager
deactivate LogicManager
diff --git a/docs/diagrams/ModelClassDiagram.png b/docs/diagrams/ModelClassDiagram.png
index aeccf82bf7a..bf7938ac9f6 100644
Binary files a/docs/diagrams/ModelClassDiagram.png and b/docs/diagrams/ModelClassDiagram.png differ
diff --git a/docs/diagrams/ModelClassDiagram.puml b/docs/diagrams/ModelClassDiagram.puml
index ba4cd8984a7..224e9741d1d 100644
--- a/docs/diagrams/ModelClassDiagram.puml
+++ b/docs/diagrams/ModelClassDiagram.puml
@@ -21,6 +21,9 @@ Class Type
Class Name
Class Phone
Class Tag
+Class MeetingTime
+Class MeetingTimeFormatter
+Class PersonMeetingTimeComparator
Class I #FFFFFF
}
@@ -44,6 +47,7 @@ Person *--> Phone
Person *--> Email
Person *--> Type
Person *--> Address
+Person *--> "0..1" MeetingTime
Person *--> "*" Tag
Person -[hidden]up--> I
@@ -53,5 +57,8 @@ Name -[hidden]right-> Phone
Phone -[hidden]right-> Address
Address -[hidden]right-> Email
-ModelManager --> "~* filtered" Person
+ModelManager --> "~* filtered and sorted" Person
+ModelManager ..> PersonMeetingTimeComparator
+UserPrefs .[hidden].> PersonMeetingTimeComparator
+MeetingTime ..> MeetingTimeFormatter
@enduml
diff --git a/docs/diagrams/PersonClassDiagram.png b/docs/diagrams/PersonClassDiagram.png
index c176fc79e6d..946ad3f3204 100644
Binary files a/docs/diagrams/PersonClassDiagram.png and b/docs/diagrams/PersonClassDiagram.png differ
diff --git a/docs/diagrams/PersonClassDiagram.puml b/docs/diagrams/PersonClassDiagram.puml
index 1572727ee06..cc253a0a644 100644
--- a/docs/diagrams/PersonClassDiagram.puml
+++ b/docs/diagrams/PersonClassDiagram.puml
@@ -8,10 +8,13 @@ Package "Person Classes" as ModelPackage <>{
Class "{abstract}\nPerson" as Person
Class Lead
Class Client
+Class KeyMilestone
}
Class HiddenOutside #FFFFFF
HiddenOutside ..> Person
Lead -up-|> Person
Client -up-|> Person
+
+Lead *--> KeyMilestone
@enduml
diff --git a/docs/diagrams/SortMeetingTimeSequenceDiagram.png b/docs/diagrams/SortMeetingTimeSequenceDiagram.png
new file mode 100644
index 00000000000..9c33ea17162
Binary files /dev/null and b/docs/diagrams/SortMeetingTimeSequenceDiagram.png differ
diff --git a/docs/diagrams/SortMeetingTimeSequenceDiagram.puml b/docs/diagrams/SortMeetingTimeSequenceDiagram.puml
new file mode 100644
index 00000000000..ec764896885
--- /dev/null
+++ b/docs/diagrams/SortMeetingTimeSequenceDiagram.puml
@@ -0,0 +1,54 @@
+@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 "s:SortMeetingTimeCommand" as SortMeetingTimeCommand 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("sortmeeting")
+activate LogicManager
+
+LogicManager -> AddressBookParser : parseCommand("sortmeeting")
+activate AddressBookParser
+
+
+create SortMeetingTimeCommand
+AddressBookParser -> SortMeetingTimeCommand
+activate SortMeetingTimeCommand
+
+SortMeetingTimeCommand --> AddressBookParser : s
+deactivate SortMeetingTimeCommand
+
+AddressBookParser --> LogicManager : s
+deactivate AddressBookParser
+
+LogicManager -> SortMeetingTimeCommand : execute()
+activate SortMeetingTimeCommand
+
+SortMeetingTimeCommand -> Model : sortFilteredPersonList()
+activate Model
+
+Model --> SortMeetingTimeCommand
+deactivate Model
+
+create CommandResult
+SortMeetingTimeCommand -> CommandResult
+activate CommandResult
+
+CommandResult --> SortMeetingTimeCommand : result
+deactivate
+
+SortMeetingTimeCommand --> LogicManager : result
+deactivate SortMeetingTimeCommand
+
+[<--LogicManager
+deactivate LogicManager
+@enduml
diff --git a/docs/diagrams/UiClassDiagram.png b/docs/diagrams/UiClassDiagram.png
index 5051f4e1421..44adf7b2315 100644
Binary files a/docs/diagrams/UiClassDiagram.png and b/docs/diagrams/UiClassDiagram.png differ
diff --git a/docs/diagrams/UiClassDiagram.puml b/docs/diagrams/UiClassDiagram.puml
index 58d2b005320..f3b2685118b 100644
--- a/docs/diagrams/UiClassDiagram.puml
+++ b/docs/diagrams/UiClassDiagram.puml
@@ -32,12 +32,12 @@ HiddenOutside ..> Ui
UiManager .left.|> Ui
UiManager -down-> "1" MainWindow
-MainWindow *-down-> "1" CommandBox
+MainWindow *-down--> "1" CommandBox
MainWindow *-down-> "1" ResultDisplay
MainWindow *-down-> "1" PersonListPanel
MainWindow *-down-> "1" StatusBarFooter
-MainWindow --> "0..1" HelpWindow
-MainWindow --> "0..1" ViewWindow
+MainWindow *--> "0..1" HelpWindow
+MainWindow *--> "0..1" ViewWindow
PersonListPanel -down-> "*" PersonCard
@@ -54,8 +54,11 @@ ViewWindow --|> UiPart
PersonCard ..> Model
UiManager -right-> Logic
MainWindow -left-> Logic
+UiManager --[hidden]down-> PersonListPanel
+Ui --[hidden]down-> CommandBox
-PersonListPanel -[hidden]left- HelpWindow
+PersonListPanel -[hidden]left- ViewWindow
+ViewWindow -[hidden]left- HelpWindow
HelpWindow -[hidden]left- CommandBox
CommandBox -[hidden]left- ResultDisplay
ResultDisplay -[hidden]left- StatusBarFooter
diff --git a/docs/diagrams/ViewSequenceDiagram.png b/docs/diagrams/ViewSequenceDiagram.png
index 9bdec105e86..8a42940e5eb 100644
Binary files a/docs/diagrams/ViewSequenceDiagram.png and b/docs/diagrams/ViewSequenceDiagram.png differ
diff --git a/docs/diagrams/ViewSequenceDiagram.puml b/docs/diagrams/ViewSequenceDiagram.puml
index c4ae341a18b..425a0cb1785 100644
--- a/docs/diagrams/ViewSequenceDiagram.puml
+++ b/docs/diagrams/ViewSequenceDiagram.puml
@@ -6,7 +6,7 @@ box Logic LOGIC_COLOR_T1
participant ":LogicManager" as LogicManager LOGIC_COLOR
participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
participant ":ViewCommandParser" as ViewCommandParser LOGIC_COLOR
-participant "d:ViewCommand" as ViewCommand LOGIC_COLOR
+participant "v:ViewCommand" as ViewCommand LOGIC_COLOR
participant ":CommandResult" as CommandResult LOGIC_COLOR
end box