AY1920S1-CS2103T-W11-1 · jiayushe · Oct 22, 2019 · Oct 15, 2019 · Oct 15, 2019 · Oct 17, 2019
diff --git a/docs/DeveloperGuide.adoc b/docs/DeveloperGuide.adoc
@@ -77,7 +77,7 @@ The sections below give more details of each component.
 .Structure of the UI Component
 image::UiClassDiagram.png[]
 
-*API* : link:{repoURL}/src/main/java/seedu/address/ui/Ui.java[`Ui.java`]
+*API* : link:{repoURL}/src/main/java/seedu/algobase/ui/Ui.java[`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.
 
@@ -126,31 +126,93 @@ The `Model`,
 * stores the AlgoBase data.
 * exposes unmodifiable `ObservableList<Problem>`, `ObservableList<Tag>`, `ObservableList<Plan>`, `ObservableList<Task>` 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.
 * does not depend on any of the other three components.
+//@@author
 
+//@@author jiayushe
 [[Design-Storage]]
 === Storage component
 
 .Structure of the Storage Component
 image::StorageClassDiagram.png[]
 
-*API* : link:{repoURL}/src/main/java/seedu/address/storage/Storage.java[`Storage.java`]
+*API* : link:{repoURL}/src/main/java/seedu/algobase/storage/Storage.java[`Storage.java`]
 
 The `Storage` component,
 
-* can save `UserPref` objects in json format and read it back.
-* can save the Address Book data in json format and read it back.
-
-//@@author le0tan
+* can store `UserPref` objects in json format.
+* can retrieve `UserPref` objects from json format.
+* can store the AlgoBase app data including `Plan`, `Problem`, `Tag`, `Task` objects in relational manner in json format.
+* can retrieve `Plan`, `Problem`, `Tag`, `Task` objects from json format.
 
 [[Design-Commons]]
 === Common classes
 
-Classes used by multiple components are in the `seedu.addressbook.commons` package.
+Classes used by multiple components are in the `seedu.algobase.commons` package.
+
+It contains utility files for configuration `ConfigUtil`, file handling `FileUtil`, ID generation `IdUtil`,
+JSON storage `JsonUtil`, string manipulation `StringUtil` and others.
+//@@author
 
 == Implementation
 
 This section describes some noteworthy details on how certain features are implemented.
 
+//@@author jiayushe
+// tag::task[]
+
+=== Task Management Feature
+
+As a algorithmic problem management tool, one of the most important features will be manage tasks that have been done
+and are to be done.
+
+This section will describe in details the current implementation and design considerations of
+the task management feature.
+
+==== Current Implementation
+
+The task management feature mainly involves four main behaviours:
+
+* `AlgoBase#addTask()` - create a new task for a problem and add it to a specified plan.
+* `AlgoBase#deleteTask()` - delete an existing task from a specified plan.
+* `AlgoBase#doneTask()` - mark a task as done in a specified plan.
+* `AlgoBase#undoneTask()` - mark a task as undone in a specified plan.
+
+Given below is an example usage scenario and how the mechanism for adding tasks behaves at each step.
+
+The following activity diagram summarizes what happens when a user executes the `AddTask` command:
+
+image::task/AddTaskCommandActivityDiagram.png[]
+
+_Figure 1. Activity Diagram for the Execution of `AddTask` Command_
+
+Step 1. The user launches the application.
+
+Step 2. AlgoBase displays a list of existing problems and plans in the UI.
+
+Step 3. The user executes `addtask plan/1 prob/1` to add the problem with index 1 in the list to the plan with index 1.
+The `AddTask` command calls `Plan#updateTasks` to create a new plan from the original plan with this additional task.
+After that, `Model#setPlan()` is called to replace the original plan with the updated plan in the `PlanList`.
+
+The following sequence diagram shows how the `addtask` operation works:
+
+image::task/AddTaskSequenceDiagram.png[]
+
+_Figure 2. Sequence Diagram for the Execution of `AddTask` Command_
+
+==== Design Considerations
+
+===== Aspect: Data structure to support the task commands.
+
+* Alternative 1 (current choice): Use a `HashSet` in current AlgoBase to save all tasks in a plan.
+** Pros: Users can manage the tasks conveniently.
+** Cons: Harder to implement for relational storage.
+* Alternative 2: Simply keep tasks as a part of a plan.
+** Pros: No need to save the task separately in the storage, all tasks are under plans.
+** Cons: Does not keep track of relations between tasks and plans.
+
+// end::task[]
+//@@author
+
 //@@author LuWenQ
 === Tag feature
 
@@ -196,7 +258,7 @@ image::TagActivityDiagram.png[]
 * Alternative 2: Simply keep tags as a part of problems. While execute the tag command will search for all tags in problems for every times it execute.
 ** Pros: No need to save the tag separately in the storage, all tags are under problems.
 ** Cons: Difficult to manage tags in different problems. Waste time for computer to execute.
-//@@author LuWenQ
+//@@author
 
 //@@author le0tan
 // tag::find[]
@@ -218,7 +280,7 @@ _Figure 1. Activity Diagram for the Execution of `find` Command_
 The find problem feature mainly involves three parts:
 
 1. validating and parsing user input
-2.  creating a filtering predicate from user’s search restrictions
+2. creating a filtering predicate from user’s search restrictions
 3. update the displayed problem list with the filtering predicate.
 
 The find problem feature is facilitated by the following classes:
@@ -246,15 +308,15 @@ These are classes that describes whether an instance of `Problem` is considered
 ** `SourceMatchesKeywordPredicate`
 *** It requires an exact match.
 ** `DifficultyIsInRangePredicate`
-*** It matches problems with LOWER_BOUND <= difficulty <= UPPER_BOUND
+*** It matches problems with LOWER_BOUND \<= difficulty \<= UPPER_BOUND
 ** `TagIncludesKeywordsPredicate`
 *** Each keyword will be considered as a tag, and two tags are considered equal only when their names are exactly the same.
 *** It returns true when the provided tags are a subset of the tags of the provided problem.
 * `FindCommandParser`
 It validates and parses user input to an instance of `FindCommand`.
 
 [NOTE]
-If the user provides difficulty range as one of the search restrictions, `FindCommandParser` expects the format `LOWER_BOUND <= difficulty <= UPPER_BOUND` while `LOWER_BOUND` and `UPPER_BOUND` are valid strings for doubles (i.e. parsable by `Double.parseDouble(...)`).
+If the user provides difficulty range as one of the search restrictions, `FindCommandParser` expects the format `LOWER_BOUND \<= difficulty \<= UPPER_BOUND` while `LOWER_BOUND` and `UPPER_BOUND` are valid strings for doubles (i.e. parsable by `Double.parseDouble(...)`).
 
 * `FindCommand`
 +
@@ -316,7 +378,7 @@ _Figure 3. Sequence Diagram for the Execution of `find` Command_
 ** Cons: If we are to add more predicates, it’s more likely that we forget to check `null` value of the new predicate.
 
 // end::find[]
-//@@author le0tan
+//@@author
 
 //@@author tiuweehan
 // tag::switchTab[]
@@ -397,7 +459,7 @@ Aspect: How to update the tab in the UI
 ** Cons: Increases coupling between the `TabManager` class and the UI and reduces testability.
 
 // end::switchTab[]
-//@@author tiuweehan
+//@@author
 
 == Documentation
 

diff --git a/docs/UserGuide.adoc b/docs/UserGuide.adoc
@@ -220,11 +220,11 @@ Format: `listplan`
 ==== Adding a new task to a plan: `addtask`
 
 Adds a task to a specified plan. +
-Format: `addtask plan/PLAN_INDEX prob/PROBLEM_INDEX`
+Format: `addtask plan/PLAN_INDEX prob/PROBLEM_INDEX [due/TARGET_DATE]`
 
 Examples:
 
-* `addtask plan/1 prob/1`
+* `addtask plan/1 prob/1 due/2019-12-12`
 
 ==== Deleting a task from a plan: `deletetask`
 
@@ -247,7 +247,7 @@ Examples:
 ==== Marking a task as undone: `undonetask`
 
 Marks a specified task in a specified plan as undone. +
-Format: `undone plan/PLAN_INDEX prob/TASK_INDEX`
+Format: `undonetask plan/PLAN_INDEX task/TASK_INDEX`
 
 Examples:
 
@@ -367,9 +367,9 @@ e.g. `delete 3`
 * *Sort* : `sort m/METHOD [d/DIRECTION]` +
 e.g. `sort m/alphabetical d/ASC`
 
-* *New Tag* : `newtag n/NAME` +
-e.g. `newtag n/sssp`
-* *List Tags* : `lstag`
+* *New Tag* : `addtag n/NAME` +
+e.g. `addtag n/sssp`
+* *List Tags* : `listtag`
 * *Delete Tag* : `deletetag INDEX` +
 e.g. `deletetag 3`
 
@@ -380,10 +380,14 @@ e.g. `editplan 1 a/1 2 3 d/4 5 6 n/training set 1`
 * *Find Training Plan* : `findplan KEYWORD [MORE_KEYWORDS]` +
 e.g. `find training set`
 * *List Training Plans* : `listplan`
-* *Mark Training Plan as done* : `done PLAN_INDEX PROBLEM_INDEX` +
-e.g. `done 1 2`
-* *Mark Training Plan as undone* : `undone PLAN_INDEX PROBLEM_INDEX` +
-e.g. `undone 1 2`
+* *Add Task to Training Plan* : `addtask plan/PLAN_INDEX prob/PROBLEM_INDEX` +
+e.g. `addtask plan/1 prob/2`
+* *Delete Task from Training Plan* : `deletetask plan/PLAN_INDEX task/TASK_INDEX` +
+e.g. `deletetask plan/1 task/2`
+* *Mark Task as done* : `donetask plan/PLAN_INDEX task/TASK_INDEX` +
+e.g. `donetask plan/1 task/2`
+* *Mark Task as undone* : `undonetask plan/PLAN_INDEX task/TASK_INDEX` +
+e.g. `undonetask plan/1 task/2`
 
 * *Importing data* : `import f/FORMAT p/PATH` +
 e.g. `import t/plan p/./steven_halim_secret.json`

diff --git a/docs/diagrams/ArchitectureSequenceDiagram.puml b/docs/diagrams/ArchitectureSequenceDiagram.puml
@@ -13,13 +13,13 @@ activate ui UI_COLOR
 ui -[UI_COLOR]> logic : execute("delete 1")
 activate logic LOGIC_COLOR
 
-logic -[LOGIC_COLOR]> model : deletePerson(p)
+logic -[LOGIC_COLOR]> model : deleteProblem(p)
 activate model MODEL_COLOR
 
 model -[MODEL_COLOR]-> logic
 deactivate model
 
-logic -[LOGIC_COLOR]> storage : saveAddressBook(addressBook)
+logic -[LOGIC_COLOR]> storage : saveAlgoBase(algoBase)
 activate storage STORAGE_COLOR
 
 storage -[STORAGE_COLOR]> storage : Save to file

diff --git a/docs/diagrams/DeleteSequenceDiagram.puml b/docs/diagrams/DeleteSequenceDiagram.puml
@@ -3,7 +3,7 @@
 
 box Logic LOGIC_COLOR_T1
 participant ":LogicManager" as LogicManager LOGIC_COLOR
-participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
+participant ":AlgoBaseParser" as AlgoBaseParser LOGIC_COLOR
 participant ":DeleteCommandParser" as DeleteCommandParser LOGIC_COLOR
 participant "d:DeleteCommand" as DeleteCommand LOGIC_COLOR
 participant ":CommandResult" as CommandResult LOGIC_COLOR
@@ -16,17 +16,17 @@ end box
 [-> LogicManager : execute("delete 1")
 activate LogicManager
 
-LogicManager -> AddressBookParser : parseCommand("delete 1")
-activate AddressBookParser
+LogicManager -> AlgoBaseParser : parseCommand("delete 1")
+activate AlgoBaseParser
 
 create DeleteCommandParser
-AddressBookParser -> DeleteCommandParser
+AlgoBaseParser -> DeleteCommandParser
 activate DeleteCommandParser
 
-DeleteCommandParser --> AddressBookParser
+DeleteCommandParser --> AlgoBaseParser
 deactivate DeleteCommandParser
 
-AddressBookParser -> DeleteCommandParser : parse("1")
+AlgoBaseParser -> DeleteCommandParser : parse("1")
 activate DeleteCommandParser
 
 create DeleteCommand
@@ -36,19 +36,19 @@ activate DeleteCommand
 DeleteCommand --> DeleteCommandParser : d
 deactivate DeleteCommand
 
-DeleteCommandParser --> AddressBookParser : d
+DeleteCommandParser --> AlgoBaseParser : d
 deactivate DeleteCommandParser
 'Hidden arrow to position the destroy marker below the end of the activation bar.
-DeleteCommandParser -[hidden]-> AddressBookParser
+DeleteCommandParser -[hidden]-> AlgoBaseParser
 destroy DeleteCommandParser
 
-AddressBookParser --> LogicManager : d
-deactivate AddressBookParser
+AlgoBaseParser --> LogicManager : d
+deactivate AlgoBaseParser
 
 LogicManager -> DeleteCommand : execute()
 activate DeleteCommand
 
-DeleteCommand -> Model : deletePerson(1)
+DeleteCommand -> Model : deleteProblem(1)
 activate Model
 
 Model --> DeleteCommand

diff --git a/docs/diagrams/StorageClassDiagram.puml b/docs/diagrams/StorageClassDiagram.puml
@@ -6,19 +6,22 @@ skinparam classBackgroundColor STORAGE_COLOR
 
 Interface Storage <<Interface>>
 Interface UserPrefsStorage <<Interface>>
-Interface AddressBookStorage <<Interface>>
+Interface AlgoBaseStorage <<Interface>>
 
 Class StorageManager
 Class JsonUserPrefsStorage
-Class JsonAddressBookStorage
+Class JsonAlgoBaseStorage
 
 StorageManager .left.|> Storage
 StorageManager o-right-> UserPrefsStorage
-StorageManager o--> AddressBookStorage
+StorageManager o--> AlgoBaseStorage
 
 JsonUserPrefsStorage .left.|> UserPrefsStorage
-JsonAddressBookStorage .left.|> AddressBookStorage
-JsonAddressBookStorage .down.> JsonSerializableAddressBookStorage
-JsonSerializableAddressBookStorage .right.> JsonSerializablePerson
-JsonSerializablePerson .right.> JsonAdaptedTag
+JsonAlgoBaseStorage .left.|> AlgoBaseStorage
+JsonAlgoBaseStorage .down.> JsonSerializableAlgoBaseStorage
+JsonSerializableAlgoBaseStorage .down.> JsonAdaptedPlan
+JsonSerializableAlgoBaseStorage .down.> JsonAdaptedProblem
+JsonSerializableAlgoBaseStorage .down.> JsonAdaptedTag
+JsonAdaptedProblem .right.> JsonAdaptedTag
+JsonAdaptedPlan .right.> JsonAdaptedTask
 @enduml
diff --git a/docs/diagrams/gui/SwitchTabsSequenceDiagram0.puml b/docs/diagrams/gui/SwitchTabsSequenceDiagram0.puml
@@ -1,5 +1,5 @@
 @startuml
-!include style.puml
+!include ../style.puml
 
 box Logic LOGIC_COLOR_T1
 participant ":LogicManager" as LogicManager LOGIC_COLOR

diff --git a/docs/diagrams/gui/SwitchTabsSequenceDiagram1.puml b/docs/diagrams/gui/SwitchTabsSequenceDiagram1.puml
@@ -1,5 +1,5 @@
 @startuml
-!include style.puml
+!include ../style.puml
 
 box Logic LOGIC_COLOR_T1
 participant ":LogicManager" as LogicManager LOGIC_COLOR

diff --git a/docs/diagrams/gui/SwitchTabsSequenceDiagram2.puml b/docs/diagrams/gui/SwitchTabsSequenceDiagram2.puml
@@ -1,5 +1,5 @@
 @startuml
-!include style.puml
+!include ../style.puml
 
 box UI UI_COLOR_T1
 participant ":DetailsTabPane" as DetailsTabPane UI_COLOR