diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md
index 35d9ffc44bd..8949ba9c508 100644
--- a/docs/DeveloperGuide.md
+++ b/docs/DeveloperGuide.md
@@ -7,18 +7,24 @@ title: Developer Guide
* Table of Contents
{:toc}
+
+
--------------------------------------------------------------------------------------------------------------------
## **Acknowledgements**
* {list here sources of all reused/adapted ideas, code, documentation, and third-party libraries -- include links to the original source as well}
+
+
--------------------------------------------------------------------------------------------------------------------
## **Setting up, getting started**
Refer to the guide [_Setting up and getting started_](SettingUp.md).
+
+
--------------------------------------------------------------------------------------------------------------------
## **Design**
@@ -71,6 +77,8 @@ For example, the `Logic` component defines its API in the `Logic.java` interface
The sections below give more details of each component.
+
+
### UI component
The **API** of this component is specified in [`Ui.java`](https://github.com/AY2324S1-CS2103T-T10-2/tp/tree/master/src/main/java/seedu/address/ui/Ui.java)
@@ -88,6 +96,8 @@ The `UI` component,
* keeps a reference to the `Logic` component, because the `UI` relies on the `Logic` to execute commands.
* depends on some classes in the `Model` component, as it displays `Person` object residing in the `Model`.
+
+
### Logic component
**API** : [`Logic.java`](https://github.com/AY2324S1-CS2103T-T10-2/tp/tree/master/src/main/java/seedu/address/logic/Logic.java)
@@ -121,6 +131,8 @@ 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/AY2324S1-CS2103T-T10-2/tp/tree/master/src/main/java/seedu/address/model/Model.java)
@@ -136,12 +148,14 @@ The `Model` component,
{% include admonition.html type="note" title="Note" body="
-An alternative (arguably, a more OOP) model is given below. It has a Tag list in the AddressBook, which Person references. This allows AddressBook to only require one Tag object per unique tag, instead of each Person needing their own Tag objects.
+An alternative (arguably, a more OOP) model is given below. It has a Tag list in the AddressBook, which Person references. This allows AddressBook to only require one Tag object per unique tag, instead of each Person needing their own Tag objects.
" %}
+
+
### Storage component
**API** : [`Storage.java`](https://github.com/AY2324S1-CS2103T-T10-2/tp/tree/master/src/main/java/seedu/address/storage/Storage.java)
@@ -153,16 +167,194 @@ The `Storage` component,
* inherits from both `AddressBookStorage` and `UserPrefStorage`, which means it can be treated as either one (if only the functionality of only one is needed).
* depends on some classes in the `Model` component (because the `Storage` component's job is to save/retrieve objects that belong to the `Model`)
+
+
### Common classes
Classes used by multiple components are in the `seedu.addressbook.commons` package.
+
+
--------------------------------------------------------------------------------------------------------------------
## **Implementation**
This section describes some noteworthy details on how certain features are implemented.
+### List Task feature
+
+#### Implementation
+
+The `listTask` command is designed to exhibit all tasks currently stored within CoordiMate to the user. It takes in no arguments and provides a straightforward view of all tasks in their current state.
+
+To get a visual representation of how the `listTask` command operates, the sequence diagram below provides a detailed overview:
+
+
+
+{% include admonition.html type="note" title="Note" body="
+
+The lifeline for ListTaskCommand should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+
+" %}
+
+#### Design considerations
+
+**Aspect: Design and format of task display:**
+
+* **Alternative 1:** Simply present tasks using basic string output.
+ * Pros: Direct approach and simple to design and implement.
+ * Cons: Can seem too plain and might not capture users' attention effectively.
+
+* **Alternative 2 (current choice):** Offer a more structured and visually enhanced display format for tasks.
+ * Pros: Ensures better user engagement due to organized and eye-catching content presentation.
+ * Cons: Can be challenging to implement given the added layers of design and subsequent testing.
+
+
+
+### Edit Task feature
+
+#### Implementation
+
+The `editTask` command accepts an index, title, note, and tags, and edits the task at that index with the new fields. The index should be numeric. The title, note, and tags can be any string. At least one of the title, note, or tag must be provided for the command to be valid.
+
+The sequence diagram below illustrates how the `editTask` command works for the example input `editTask 1 T/title n/note t/tag`.
+
+
+
+{% include admonition.html type="note" title="Note" body="
+
+The lifeline for EditTaskCommandParser and EditTaskCommand should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+
+" %}
+
+#### Design considerations
+
+**Aspect: How to encapsulate edited fields:**
+
+* **Alternative 1:** Store each edited field in a separate variable directly into `EditTaskCommand` after parsing.
+ * Pros: Simple to implement.
+ * Cons: Low level of abstraction. Difficult to test, maintain, and extend if more fields are to be added. It is also difficult to pass each field around to classes that need access to the edited fields.
+
+* **Alternative 2 (current choice):** Encapsulate edited fields in a `EditTaskDescriptor` class.
+ * Pros: High level of abstraction. Encapsulation allows the details of an `editTask` command to be passed around as a single object to be used by other classes.
+ * Cons: More complex to implement due to boilerplate code.
+
+
+
+### Find Task feature
+
+#### Implementation
+
+The `findTask` command accepts a String of space-separated keywords, and returns a list of tasks that contain any of their keywords in their title or note. The search is case-insensitive.
+
+The sequence diagram below illustrates how the `findTask` command works.
+
+
+
+{% include admonition.html type="note" title="Note" body="
+
+The lifeline for FindTaskCommandParser, TaskContainsKeywordsPredicate and FindTaskCommand should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+
+" %}
+
+This feature is accomplished by a `TaskContainsKeywordPredicate` class which is used to filter the list of tasks in the `Model` component.
+
+The `TaskContainsKeywordPredicate` class creates two more `Predicate` objects using the provided search terms, namely, `TitleContainsKeywordPredicate` and `NoteContainsKeywordPredicate`, which are omitted from the diagram above for brevity.
+
+The `TitleContainsKeywordPredicate` object checks if a given task's `Title` contains any of the keywords in the search term.
+
+The `NoteContainsKeywordPredicate` object checks if a given task's `Note` contains any of the keywords in the search term.
+
+These two predicates are used to filter the list of tasks in the `Model` component, by using a short-circuiting OR operation to combine the two predicates.
+
+#### Design considerations
+
+**Aspect: How to implement the `Predicate` class:**
+
+ * **Alternative 1:** Use a single `TaskContainsKeywordPredicate` class that implements `Predicate` to search both the task's `Title` and `Note`.
+ * Pros: Simple to implement.
+ * Cons: Not extensible. If we want to search other fields in the future, we will have to modify the `TaskContainsKeywordPredicate` class.
+
+
+ * **Alternative 2 (current choice):** Use two `Predicate` classes, namely, `TitleContainsKeywordPredicate` and `NoteContainsKeywordPredicate`, to search the task's `Title` and `Note` respectively.
+ * Pros: Extensible. We can easily add more `Predicate` classes to search other fields in the future. These classes also allow us to search the task's `Title` and `Note` separately, if needed.
+ * Cons: More complex to implement.
+
+
+
+### Mark Task feature
+
+#### Implementation
+
+The `markTask` command accepts an index and marks the task at that index with task status of **done**. The index should be numeric.
+
+The sequence diagram below illustrates how the `markTask` command works for the example input `markTask 1`.
+
+
+
+{% include admonition.html type="note" title="Note" body="
+
+The lifeline for MarkTaskCommandParser, ParserUtil and MarkTaskCommand should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+
+" %}
+
+#### Design considerations
+
+**Aspect: How to create status of a Task:**
+
+* **Alternative 1:** Using String input to create a status.
+ * Pros: Simple to implement. Provides flexibility, allowing for dynamic input without changing code.
+ * Cons: Can lead to potential issues related to typos or inconsistent naming conventions.
+ Any string can be passed as a status, potentially resulting in invalid or unexpected states.
+
+* **Alternative 2 (current choice):** Using an enum input to create a status.
+ * Pros: Provides a type-safe way to represent task statuses, ensuring that only valid status values can be used. If new status types are introduced, developers can easily update the TaskStatus enum, ensuring all usages are consistent
+ * Cons: More complex to implement. Require modifying the enum itself to add new status types, potentially leading to more extensive code changes
+
+**Aspect: How to update the task status of a Task:**
+
+* **Alternative 1:** Directly change the status attribute of each task every time it is marked.
+ * Pros: More memory-efficient
+ * Cons: Not immutable. Can lead to challenges in testing and tracking task state changes over time
+
+* **Alternative 2 (current choice):** Create a new task with same details and a done status every time it is marked.
+ * Pros: Ensures immutability and preserves the history of task states, allowing for easy tracking of changes and maintaining a clear historical record of task statuses.
+ * Cons: Incur a slight performance overhead, especially if the tasks contain a large amount of data, impacting the overall execution speed of the program.
+
+
+
+### Delete Task feature
+
+#### Implementation
+
+The `deleteTask` command accepts a numeric Index, and removes the task at that index from the task list.
+
+The sequence diagram below illustrates how the `deleteTask` command works for the example input `deleteTask 1`.
+
+
+
+{% include admonition.html type="note" title="Note" body="
+
+The lifeline for DeleteTaskCommandParser should end at the destroy marker (X) but due to a limitation of
+PlantUML, the lifeline reaches the end of diagram.
+
+" %}
+
+#### Design considerations
+
+**Aspect: How delete executes:**
+
+* **Alternative 1 (current choice):** Deletes task based on the filtered list shown to the user.
+ * Pros: Users do not have to use the `listTask` command everytime before they delete a task.
+ * Cons: Users cannot delete a task that is not shown in the filtered list.
+
+* **Alternative 2:** Deletes task based on the full list of tasks.
+ * Pros: Users can delete a task that is not shown in the filtered list.
+ * Cons: Users have to use the `listTask` command everytime to confirm the index of the task before they delete the
+ task.
+
+
+
### \[Proposed\] Undo/redo feature
#### Proposed Implementation
@@ -251,10 +443,13 @@ The following activity diagram summarizes what happens when a user executes a ne
_{more aspects and alternatives to be added}_
+
+
### \[Proposed\] Data archiving
_{Explain here how the data archiving feature will be implemented}_
+
--------------------------------------------------------------------------------------------------------------------
@@ -268,6 +463,8 @@ _{Explain here how the data archiving feature will be implemented}_
--------------------------------------------------------------------------------------------------------------------
+
+
## **Appendix: Requirements**
### Product scope
@@ -279,13 +476,15 @@ _{Explain here how the data archiving feature will be implemented}_
* Is comfortable with CLI apps
* Is able to type fast
-**Value proposition**:
+**Value proposition**:
CoordiMate helps event planners to easily keep track of contact details as well as the tasks to be done for various events, in a more efficient way compared to a typical mouse/GUI driven app.
+
+
### User stories
-Priorities:
+Priorities:
* `* * *` - High (must have)
* `* *` - Medium (nice to have)
@@ -316,6 +515,8 @@ Priorities:
*{More to be added}*
+
+
### Use cases
For all use cases below, the **System** is `CoordiMate` and the **Actor** is the `user`, unless specified otherwise.
@@ -469,7 +670,7 @@ For all use cases below, the **System** is `CoordiMate` and the **Actor** is the
Use case resumes from step 1.
---
-
+
**Use case: UC09 - List all tasks in the task list**
**MSS**
@@ -694,6 +895,31 @@ For all use cases below, the **System** is `CoordiMate` and the **Actor** is the
---
+**Use case: UC19 - Find persons and tasks by tag**
+
+**MSS**
+
+1. User requests to find persons tasks by specific tag(s).
+2. CoordiMate shows two separate lists of persons and tasks associated with the given tag(s).
+
+ Use case ends.
+
+**Extensions**
+
+* 1a. The given tag does not exist or no tasks are associated with it.
+
+ * 1a1. CoordiMate informs the user that there are no tasks associated with the given tag(s).
+
+ Use case ends.
+
+* 1b. The provided input for the tag search is invalid.
+
+ * 1b1. CoordiMate shows an error message and prompts the user to provide a valid input for the tag.
+
+ Use case resumes at step 1.
+
+
+
### Non-Functional Requirements
1. Should work on any _mainstream OS_ as long as it has Java `11` or above installed.
@@ -716,6 +942,7 @@ For all use cases below, the **System** is `CoordiMate` and the **Actor** is the
* **MSS**: Main Success Scenario, which is the most straightforward interaction for a given use case assuming that nothing goes wrong.
* **Private contact detail**: A contact detail that is not meant to be shared with others
+
--------------------------------------------------------------------------------------------------------------------
diff --git a/docs/assets/svg/dg/EditTaskSequenceDiagram.svg b/docs/assets/svg/dg/EditTaskSequenceDiagram.svg
new file mode 100644
index 00000000000..e4ce45a5df3
--- /dev/null
+++ b/docs/assets/svg/dg/EditTaskSequenceDiagram.svg
@@ -0,0 +1,297 @@
+
diff --git a/docs/assets/svg/dg/FindTaskSequenceDiagram.svg b/docs/assets/svg/dg/FindTaskSequenceDiagram.svg
new file mode 100644
index 00000000000..2c0fb878c12
--- /dev/null
+++ b/docs/assets/svg/dg/FindTaskSequenceDiagram.svg
@@ -0,0 +1,236 @@
+
diff --git a/docs/assets/svg/dg/ListTaskSequenceDiagram.svg b/docs/assets/svg/dg/ListTaskSequenceDiagram.svg
new file mode 100644
index 00000000000..9503860eea5
--- /dev/null
+++ b/docs/assets/svg/dg/ListTaskSequenceDiagram.svg
@@ -0,0 +1 @@
+
diff --git a/docs/assets/svg/dg/MarkTaskSequenceDiagram.svg b/docs/assets/svg/dg/MarkTaskSequenceDiagram.svg
new file mode 100644
index 00000000000..52e783004e1
--- /dev/null
+++ b/docs/assets/svg/dg/MarkTaskSequenceDiagram.svg
@@ -0,0 +1 @@
+
diff --git a/docs/diagrams/DeleteTaskSequenceDiagram.puml b/docs/diagrams/DeleteTaskSequenceDiagram.puml
new file mode 100644
index 00000000000..38325e36759
--- /dev/null
+++ b/docs/diagrams/DeleteTaskSequenceDiagram.puml
@@ -0,0 +1,90 @@
+@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 ":DeleteTaskCommandParser" as DeleteTaskCommandParser LOGIC_COLOR
+participant "c:DeleteTaskCommand" as DeleteTaskCommand LOGIC_COLOR
+participant "r:CommandResult" as CommandResult LOGIC_COLOR
+end box
+
+box Model MODEL_COLOR_T1
+participant "m:ModelManager" as ModelManager MODEL_COLOR
+participant ":AddressBook" as AddressBook MODEL_COLOR
+participant ":UniqueTaskList" as UniqueTaskList MODEL_COLOR
+end box
+
+[-> LogicManager : execute("deleteTask 1")
+activate LogicManager
+
+LogicManager -> AddressBookParser : parseCommand("deleteTask 1")
+activate AddressBookParser
+
+create DeleteTaskCommandParser
+AddressBookParser -> DeleteTaskCommandParser
+activate DeleteTaskCommandParser
+
+DeleteTaskCommandParser --> AddressBookParser
+deactivate DeleteTaskCommandParser
+
+AddressBookParser -> DeleteTaskCommandParser : parse("1")
+activate DeleteTaskCommandParser
+
+create DeleteTaskCommand
+DeleteTaskCommandParser -> DeleteTaskCommand
+activate DeleteTaskCommand
+
+DeleteTaskCommand --> DeleteTaskCommandParser : c
+deactivate DeleteTaskCommand
+
+DeleteTaskCommandParser --> AddressBookParser : c
+deactivate DeleteTaskCommandParser
+'Hidden arrow to position the destroy marker below the end of the activation bar.
+DeleteTaskCommandParser -[hidden]-> AddressBookParser
+destroy DeleteTaskCommandParser
+
+AddressBookParser --> LogicManager : c
+deactivate AddressBookParser
+
+LogicManager -> DeleteTaskCommand : execute(m)
+activate DeleteTaskCommand
+
+DeleteTaskCommand -> ModelManager : getFilteredTaskList()
+activate ModelManager
+
+ModelManager --> DeleteTaskCommand : lastShownList
+deactivate ModelManager
+
+DeleteTaskCommand -> ModelManager : deleteTask(task)
+activate ModelManager
+
+ModelManager -> AddressBook : deleteTask(task)
+activate AddressBook
+
+AddressBook -> UniqueTaskList : delete(task)
+activate UniqueTaskList
+
+UniqueTaskList --> AddressBook
+deactivate UniqueTaskList
+
+AddressBook --> ModelManager
+deactivate AddressBook
+
+ModelManager --> DeleteTaskCommand
+deactivate ModelManager
+
+create CommandResult
+DeleteTaskCommand -> CommandResult
+activate CommandResult
+
+CommandResult --> DeleteTaskCommand
+deactivate CommandResult
+
+DeleteTaskCommand --> LogicManager : r
+deactivate DeleteTaskCommand
+
+[<--LogicManager
+deactivate LogicManager
+@enduml
diff --git a/docs/diagrams/EditTaskSequenceDiagram.puml b/docs/diagrams/EditTaskSequenceDiagram.puml
new file mode 100644
index 00000000000..60c83362c7e
--- /dev/null
+++ b/docs/diagrams/EditTaskSequenceDiagram.puml
@@ -0,0 +1,120 @@
+@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 ":EditTaskCommandParser" as EditTaskCommandParser LOGIC_COLOR
+participant "desc:EditTaskDescriptor" as EditTaskDescriptor LOGIC_COLOR
+participant "cmd:EditTaskCommand" as EditTaskCommand LOGIC_COLOR
+participant "res:CommandResult" as CommandResult LOGIC_COLOR
+end box
+
+box Model MODEL_COLOR_T1
+participant ":Model" as Model MODEL_COLOR
+end box
+
+[-> LogicManager : execute("editTask...")
+activate LogicManager
+
+LogicManager -> AddressBookParser : parseCommand("editTask...")
+activate AddressBookParser
+
+create EditTaskCommandParser
+AddressBookParser -> EditTaskCommandParser : EditTaskCommandParser()
+activate EditTaskCommandParser
+
+EditTaskCommandParser --> AddressBookParser
+deactivate EditTaskCommandParser
+
+AddressBookParser -> EditTaskCommandParser : parse(args)
+activate EditTaskCommandParser
+
+'Constructor for EditTaskDescriptor
+create EditTaskDescriptor
+EditTaskCommandParser -> EditTaskDescriptor : EditTaskDescriptor()
+activate EditTaskDescriptor
+EditTaskDescriptor --> EditTaskCommandParser : desc
+deactivate EditTaskDescriptor
+
+opt has title
+EditTaskCommandParser -> EditTaskDescriptor : setTitle(title)
+activate EditTaskDescriptor
+EditTaskDescriptor --> EditTaskCommandParser
+deactivate EditTaskDescriptor
+end opt
+
+opt has note
+EditTaskCommandParser -> EditTaskDescriptor : setNote(note)
+activate EditTaskDescriptor
+EditTaskDescriptor --> EditTaskCommandParser
+deactivate EditTaskDescriptor
+end opt
+
+opt has tags
+EditTaskCommandParser -> EditTaskDescriptor : setTags(tags)
+activate EditTaskDescriptor
+EditTaskDescriptor --> EditTaskCommandParser
+deactivate EditTaskDescriptor
+end opt
+
+'Constructor for EditTaskCommand
+create EditTaskCommand
+EditTaskCommandParser -> EditTaskCommand : EditTaskCommand(index, desc)
+activate EditTaskCommand
+EditTaskCommand --> EditTaskCommandParser : cmd
+deactivate EditTaskCommand
+
+EditTaskCommandParser --> AddressBookParser : cmd
+deactivate EditTaskCommandParser
+
+'Hidden arrow to position the destroy marker below the end of the activation bar.
+EditTaskCommandParser -[hidden]-> AddressBookParser
+destroy EditTaskCommandParser
+
+AddressBookParser --> LogicManager : cmd
+deactivate AddressBookParser
+
+LogicManager -> EditTaskCommand : execute()
+activate EditTaskCommand
+
+EditTaskCommand -> Model : getFilteredTaskList()
+activate Model
+
+Model --> EditTaskCommand : filteredTaskList
+deactivate Model
+
+'Create edited task
+EditTaskCommand -> EditTaskCommand : createEditedTask(taskToEdit, editTaskDescriptor)
+activate EditTaskCommand
+EditTaskCommand --> EditTaskCommand : editedTask
+deactivate EditTaskCommand
+
+EditTaskCommand -> Model : setTask(taskToEdit, editedTask)
+activate Model
+Model --> EditTaskCommand
+deactivate Model
+
+EditTaskCommand -> Model : updateFilteredTaskList(SHOW_ALL_TASKS)
+activate Model
+Model --> EditTaskCommand
+deactivate Model
+
+create CommandResult
+EditTaskCommand -> CommandResult : CommandResult(MESSAGE_EDIT_TASK_SUCCESS)
+activate CommandResult
+
+CommandResult --> EditTaskCommand : res
+deactivate CommandResult
+
+EditTaskCommand --> LogicManager : res
+deactivate EditTaskCommand
+
+'Hidden arrow to position the destroy marker below the end of the activation bar.
+EditTaskCommand -[hidden]-> LogicManager
+destroy EditTaskCommand
+
+[<--LogicManager
+deactivate LogicManager
+@enduml
diff --git a/docs/diagrams/FindTaskSequenceDiagram.puml b/docs/diagrams/FindTaskSequenceDiagram.puml
new file mode 100644
index 00000000000..7117ea9c7db
--- /dev/null
+++ b/docs/diagrams/FindTaskSequenceDiagram.puml
@@ -0,0 +1,84 @@
+@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 ":FindTaskCommandParser" as FindTaskCommandParser LOGIC_COLOR
+participant "pred:TaskContainsKeywordsPredicate" as TaskContainsKeywordsPredicate LOGIC_COLOR
+participant "cmd:FindTaskCommand" as FindTaskCommand LOGIC_COLOR
+participant "res:CommandResult" as CommandResult LOGIC_COLOR
+end box
+
+box Model MODEL_COLOR_T1
+participant ":Model" as Model MODEL_COLOR
+end box
+
+[-> LogicManager : execute("findTask agenda")
+activate LogicManager
+
+LogicManager -> AddressBookParser : parseCommand("findTask agenda")
+activate AddressBookParser
+
+create FindTaskCommandParser
+AddressBookParser -> FindTaskCommandParser : FindTaskCommandParser()
+activate FindTaskCommandParser
+
+FindTaskCommandParser --> AddressBookParser
+deactivate FindTaskCommandParser
+
+AddressBookParser -> FindTaskCommandParser : parse("agenda")
+activate FindTaskCommandParser
+
+create TaskContainsKeywordsPredicate
+FindTaskCommandParser -> TaskContainsKeywordsPredicate : TaskContainsKeywordsPredicate(["agenda"])
+activate TaskContainsKeywordsPredicate
+
+TaskContainsKeywordsPredicate --> FindTaskCommandParser : pred
+deactivate TaskContainsKeywordsPredicate
+
+create FindTaskCommand
+FindTaskCommandParser -> FindTaskCommand : FindTaskCommand(pred)
+activate FindTaskCommand
+
+FindTaskCommand --> FindTaskCommandParser : cmd
+deactivate FindTaskCommand
+
+FindTaskCommandParser --> AddressBookParser : cmd
+deactivate FindTaskCommandParser
+
+'Hidden arrow to position the destroy marker below the end of the activation bar.
+FindTaskCommandParser -[hidden]-> AddressBookParser
+destroy FindTaskCommandParser
+
+AddressBookParser --> LogicManager : cmd
+deactivate AddressBookParser
+
+LogicManager -> FindTaskCommand : execute()
+activate FindTaskCommand
+
+FindTaskCommand -> Model : updateFilteredTaskList(pred)
+activate Model
+
+Model --> FindTaskCommand
+deactivate Model
+
+create CommandResult
+FindTaskCommand -> CommandResult : CommandResult(MESSAGE_TASKS_LISTED_OVERVIEW)
+activate CommandResult
+
+CommandResult --> FindTaskCommand : res
+deactivate CommandResult
+
+FindTaskCommand --> LogicManager : res
+deactivate FindTaskCommand
+
+[<--LogicManager : res
+deactivate LogicManager
+
+'Hidden arrow to position the destroy marker below the end of the activation bar.
+TaskContainsKeywordsPredicate -[hidden]-> LogicManager
+destroy TaskContainsKeywordsPredicate
+destroy FindTaskCommand
+@enduml
diff --git a/docs/diagrams/ListTaskSequenceDiagram.puml b/docs/diagrams/ListTaskSequenceDiagram.puml
new file mode 100644
index 00000000000..981a8a0964a
--- /dev/null
+++ b/docs/diagrams/ListTaskSequenceDiagram.puml
@@ -0,0 +1,55 @@
+@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 "c:ListTaskCommand" as ListTaskCommand LOGIC_COLOR
+participant "r:CommandResult" as CommandResult LOGIC_COLOR
+end box
+
+box Model MODEL_COLOR_T1
+participant ":Model" as Model MODEL_COLOR
+end box
+
+[-> LogicManager : execute("listTask")
+activate LogicManager
+
+LogicManager -> AddressBookParser : parseCommand("listTask")
+activate AddressBookParser
+
+create ListTaskCommand
+AddressBookParser -> ListTaskCommand
+activate ListTaskCommand
+
+ListTaskCommand --> AddressBookParser : c
+deactivate ListTaskCommand
+
+AddressBookParser --> LogicManager : c
+deactivate AddressBookParser
+
+LogicManager -> ListTaskCommand : execute()
+activate ListTaskCommand
+
+ListTaskCommand -> Model : updateFilteredTaskList(PREDICATE_SHOW_ALL_TASKS)
+activate Model
+
+Model --> ListTaskCommand
+deactivate Model
+
+create CommandResult
+ListTaskCommand -> CommandResult
+activate CommandResult
+
+CommandResult --> ListTaskCommand
+deactivate CommandResult
+
+ListTaskCommand --> LogicManager : r
+deactivate ListTaskCommand
+
+[<--LogicManager
+deactivate LogicManager
+
+destroy ListTaskCommand
+@enduml
diff --git a/docs/diagrams/MarkTaskSequenceDiagram.puml b/docs/diagrams/MarkTaskSequenceDiagram.puml
new file mode 100644
index 00000000000..0f09bbfacdf
--- /dev/null
+++ b/docs/diagrams/MarkTaskSequenceDiagram.puml
@@ -0,0 +1,122 @@
+@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 ":MarkTaskCommandParser" as MarkTaskCommandParser LOGIC_COLOR
+participant "idx:ParserUtil" as ParserUtil LOGIC_COLOR
+participant "cmd:MarkTaskCommand" as MarkTaskCommand LOGIC_COLOR
+participant "res:CommandResult" as CommandResult LOGIC_COLOR
+end box
+
+box Model MODEL_COLOR_T1
+participant ":Model" as Model MODEL_COLOR
+participant "editedTask:Task" as Task MODEL_COLOR
+participant ":AddressBook" as AddressBook MODEL_COLOR
+participant ":UniqueTaskList" as UniqueTaskList MODEL_COLOR
+end box
+
+[-> LogicManager : execute("markTask 1")
+activate LogicManager
+
+LogicManager -> AddressBookParser : parseCommand("markTask 1")
+activate AddressBookParser
+
+create MarkTaskCommandParser
+AddressBookParser -> MarkTaskCommandParser : MarkTaskCommandParser()
+activate MarkTaskCommandParser
+
+MarkTaskCommandParser --> AddressBookParser
+deactivate MarkTaskCommandParser
+
+AddressBookParser -> MarkTaskCommandParser : parse("1")
+activate MarkTaskCommandParser
+
+create ParserUtil
+MarkTaskCommandParser -> ParserUtil : parseIndex("1")
+activate ParserUtil
+
+ParserUtil --> MarkTaskCommandParser : idx
+deactivate ParserUtil
+
+create MarkTaskCommand
+MarkTaskCommandParser -> MarkTaskCommand : MarkTaskCommand(idx)
+activate MarkTaskCommand
+
+MarkTaskCommand --> MarkTaskCommandParser : cmd
+deactivate MarkTaskCommand
+
+MarkTaskCommandParser --> AddressBookParser : cmd
+deactivate MarkTaskCommandParser
+
+'Hidden arrow to position the destroy marker below the end of the activation bar.
+MarkTaskCommandParser -[hidden]-> AddressBookParser
+destroy MarkTaskCommandParser
+
+AddressBookParser --> LogicManager : cmd
+deactivate AddressBookParser
+
+LogicManager -> MarkTaskCommand : execute()
+activate MarkTaskCommand
+
+MarkTaskCommand -> Model : getFilteredTaskList()
+activate Model
+
+Model --> MarkTaskCommand : lastShownList
+deactivate Model
+
+'Get task to mark
+MarkTaskCommand -> MarkTaskCommand : lastShownList.get(idx)
+activate MarkTaskCommand
+MarkTaskCommand --> MarkTaskCommand : taskToMark
+deactivate MarkTaskCommand
+
+MarkTaskCommand -> Model : markTask(taskToMark)
+activate Model
+
+Model -> Task: markDone()
+activate Task
+Task --> Model: editedTask
+deactivate Task
+
+Model -> Model: setTask(taskToMark, editedTask)
+activate Model
+
+Model -> AddressBook : setTask(taskToMark, editedTask)
+activate AddressBook
+
+AddressBook -> UniqueTaskList : setTask(taskToMark, editedTask)
+activate UniqueTaskList
+
+UniqueTaskList --> AddressBook
+deactivate UniqueTaskList
+
+AddressBook --> Model
+deactivate AddressBook
+
+Model --> Model :
+deactivate Model
+
+Model --> MarkTaskCommand : editedTask
+deactivate Model
+
+create CommandResult
+MarkTaskCommand -> CommandResult : CommandResult(MESSAGE_MARK_TASK_SUCCESS)
+activate CommandResult
+
+CommandResult --> MarkTaskCommand : res
+deactivate CommandResult
+
+MarkTaskCommand --> LogicManager : res
+deactivate MarkTaskCommand
+
+[<--LogicManager : res
+deactivate LogicManager
+
+'Hidden arrow to position the destroy marker below the end of the activation bar.
+ParserUtil -[hidden]-> LogicManager
+destroy ParserUtil
+destroy MarkTaskCommand
+@enduml
diff --git a/docs/images/DeleteTaskSequenceDiagram.png b/docs/images/DeleteTaskSequenceDiagram.png
new file mode 100644
index 00000000000..d115d72d5d7
Binary files /dev/null and b/docs/images/DeleteTaskSequenceDiagram.png differ
diff --git a/docs/images/ListTaskSequenceDiagram.png b/docs/images/ListTaskSequenceDiagram.png
new file mode 100644
index 00000000000..013ee160bd4
Binary files /dev/null and b/docs/images/ListTaskSequenceDiagram.png differ
" %}
+
+
### Storage component
**API** : [`Storage.java`](https://github.com/AY2324S1-CS2103T-T10-2/tp/tree/master/src/main/java/seedu/address/storage/Storage.java)
@@ -153,16 +167,194 @@ The `Storage` component,
* inherits from both `AddressBookStorage` and `UserPrefStorage`, which means it can be treated as either one (if only the functionality of only one is needed).
* depends on some classes in the `Model` component (because the `Storage` component's job is to save/retrieve objects that belong to the `Model`)
+
+
### Common classes
Classes used by multiple components are in the `seedu.addressbook.commons` package.
+
+
--------------------------------------------------------------------------------------------------------------------
## **Implementation**
This section describes some noteworthy details on how certain features are implemented.
+### List Task feature
+
+#### Implementation
+
+The `listTask` command is designed to exhibit all tasks currently stored within CoordiMate to the user. It takes in no arguments and provides a straightforward view of all tasks in their current state.
+
+To get a visual representation of how the `listTask` command operates, the sequence diagram below provides a detailed overview:
+
+
+
+{% include admonition.html type="note" title="Note" body="
+
+The lifeline for