diff --git a/.github/codecov.yml b/.github/codecov.yml
new file mode 100644
index 00000000000..08318203ce2
--- /dev/null
+++ b/.github/codecov.yml
@@ -0,0 +1,9 @@
+codecov:
+ require_ci_to_pass: no
+
+coverage:
+ status:
+ patch: off
+
+ignore:
+ - "src/main/java/seedu/address/ui"
diff --git a/.github/workflows/plantuml.yml b/.github/workflows/plantuml.yml
new file mode 100644
index 00000000000..5838800ba47
--- /dev/null
+++ b/.github/workflows/plantuml.yml
@@ -0,0 +1,37 @@
+name: Generate PlantUML Diagrams
+on:
+ push:
+ paths:
+ - 'docs/diagrams/**.puml'
+ - '!docs/diagrams/tracing/**.puml'
+jobs:
+ ci:
+ runs-on: ubuntu-latest
+ env:
+ UML_FILES: ".puml"
+ steps:
+ - name: Checkout Source
+ uses: actions/checkout@v2
+ with:
+ fetch-depth: 0
+ - name: Get current branch
+ id: currentbranch
+ run: |
+ echo "::set-output name=branch::$(git rev-parse --abbrev-ref HEAD)"
+ - name: Get changed UML files
+ id: getfile
+ run: |
+ echo "::set-output name=files::$(git diff master..${{ steps.currentbranch.outputs.branch }} | grep ${{ env.UML_FILES }} | xargs)"
+ - name: UML files considered echo output
+ run: |
+ echo ${{ steps.getfile.outputs.files }}
+ - if: contains(steps.getfile.outputs.files, 'puml')
+ name: Generate PNG Diagrams
+ uses: cloudbees/plantuml-github-action@master
+ with:
+ args: -v -tpng ${{ steps.getfile.outputs.files }} -o "/github/workspace/docs/images"
+ - if: contains(steps.getfile.outputs.files, 'puml')
+ name: Push Local Changes
+ uses: stefanzweifel/git-auto-commit-action@v4.1.2
+ with:
+ commit_message: "Generate PNG images for PlantUML diagrams"
diff --git a/README.md b/README.md
index 13f5c77403f..51085241379 100644
--- a/README.md
+++ b/README.md
@@ -1,14 +1,24 @@
-[](https://github.com/se-edu/addressbook-level3/actions)
+# FitEgo
+
+[](https://github.com/AY2021S1-CS2103T-T13-3/tp/actions)
-* This is **a sample project for Software Engineering (SE) students**.
- Example usages:
- * as a starting point of a course project (as opposed to writing everything from scratch)
- * as a case study
-* The project simulates an ongoing software project for a desktop application (called _AddressBook_) used for managing contact details.
- * It is **written in OOP fashion**. It provides a **reasonably well-written** code base **bigger** (around 6 KLoC) than what students usually write in beginner-level SE modules, without being overwhelmingly big.
- * It comes with a **reasonable level of user and developer documentation**.
-* It is named `AddressBook Level 3` (`AB3` for short) because it was initially created as a part of a series of `AddressBook` projects (`Level 1`, `Level 2`, `Level 3` ...).
-* For the detailed documentation of this project, see the **[Address Book Product Website](https://se-education.org/addressbook-level3)**.
-* This project is a **part of the se-education.org** initiative. If you would like to contribute code to this project, see [se-education.org](https://se-education.org#https://se-education.org/#contributing) for more info.
+## What is this project about?
+* FitEgo helps fitness instructors keep track of his/her customers easily, via CLI as he’s a fast typer so that he can
+spend more time on his clients / his routine rather than manually using alternative software like Excel to track
+administrative matters.
+* For the detailed documentation of this project,
+see the **[FitEgo Product Website](https://ay2021s1-cs2103t-t13-3.github.io/tp/)**.
+
+## Attribution
+* This is **a project for CS2103T Software Engineering (SE) class in NUS**.
+* This project is based on the AddressBook-Level3 project created by the [SE-EDU initiative](https://se-education.org).
+ * The project simulates an ongoing software project for a desktop application for managing user contacts.
+ * It is **written in OOP fashion**. It provides a **reasonably well-written** code base **bigger** (around 6 KLoC)
+ than what students usually write in beginner-level SE modules, without being overwhelmingly big.
+ * It comes with a **reasonable level of user and developer documentation**.
+
+* This project uses libraries from [ControlsFX](https://github.com/controlsfx/controlsfx)
+
+* This project uses an icon made by Freepik from www.flaticon.com
diff --git a/build.gradle b/build.gradle
index be2d2905dde..783f0eb2cb8 100644
--- a/build.gradle
+++ b/build.gradle
@@ -20,6 +20,10 @@ checkstyle {
toolVersion = '8.29'
}
+run {
+ enableAssertions = true
+}
+
test {
useJUnitPlatform()
finalizedBy jacocoTestReport
@@ -42,7 +46,7 @@ task coverage(type: JacocoReport) {
dependencies {
String jUnitVersion = '5.4.0'
- String javaFxVersion = '11'
+ String javaFxVersion = '11.0.2'
implementation group: 'org.openjfx', name: 'javafx-base', version: javaFxVersion, classifier: 'win'
implementation group: 'org.openjfx', name: 'javafx-base', version: javaFxVersion, classifier: 'mac'
@@ -56,6 +60,7 @@ dependencies {
implementation group: 'org.openjfx', name: 'javafx-graphics', version: javaFxVersion, classifier: 'win'
implementation group: 'org.openjfx', name: 'javafx-graphics', version: javaFxVersion, classifier: 'mac'
implementation group: 'org.openjfx', name: 'javafx-graphics', version: javaFxVersion, classifier: 'linux'
+ implementation group: 'org.controlsfx', name: 'controlsfx', version: '11.0.2'
implementation group: 'com.fasterxml.jackson.core', name: 'jackson-databind', version: '2.7.0'
implementation group: 'com.fasterxml.jackson.datatype', name: 'jackson-datatype-jsr310', version: '2.7.4'
@@ -66,7 +71,7 @@ dependencies {
}
shadowJar {
- archiveName = 'addressbook.jar'
+ archiveName = 'FitEgo.jar'
}
defaultTasks 'clean', 'test'
diff --git a/copyright.txt b/copyright.txt
index 93aa2a39ce2..5ae04edce85 100644
--- a/copyright.txt
+++ b/copyright.txt
@@ -1,9 +1,4 @@
Some code adapted from http://code.makery.ch/library/javafx-8-tutorial/ by Marco Jakob
-Copyright by Susumu Yoshida - http://www.mcdodesign.com/
-- address_book_32.png
-- AddressApp.ico
-
-Copyright by Jan Jan Kovařík - http://glyphicons.com/
-- calendar.png
-- edit.png
+Icon made by Freepik from www.flaticon.com
+- muscle.png (Used for Application icon)
diff --git a/docs/AboutUs.md b/docs/AboutUs.md
index 1c9514e966a..3a4e5884b42 100644
--- a/docs/AboutUs.md
+++ b/docs/AboutUs.md
@@ -5,55 +5,65 @@ title: About Us
We are a team based in the [School of Computing, National University of Singapore](http://www.comp.nus.edu.sg).
-You can reach us at the email `seer[at]comp.nus.edu.sg`
+We are looking for a good internships!
+You can reach our supervisor at `damithc[at]comp.nus.edu.sg`
## Project team
-### John Doe
+### Dhafin Razaq Oktoyuzan
-
+
-[[homepage](http://www.comp.nus.edu.sg/~damithch)]
-[[github](https://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](https://github.com/dhafinrazaq)] [[Project Portfolio Page (PPP)](team/dhafinrazaq)]
-* Role: Project Advisor
+#### Developer & Deliverables in-charge
-### Jane Doe
+* Ensure project deliverables are done on time and in the right format.
-
+---
+
+### Bennett Clement
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+
-* Role: Team Lead
-* Responsibilities: UI
+[[github](https://github.com/benclmnt)] [[Project Portfolio Page (PPP)](team/benclmnt)]
-### Johnny Doe
+#### Developer & Code Quality in-charge
-
+* Looks after code quality, ensures adherence to coding standards within the project.
+
+---
-[[github](http://github.com/johndoe)] [[portfolio](team/johndoe.md)]
+### Maguire Ong
-* Role: Developer
-* Responsibilities: Data
+
-### Jean Doe
+[[github](http://github.com/maguireong)] [[Project Portfolio Page (PPP)](team/maguireong)]
-
+#### Developer & Integration in-charge
+
+* In charge of versioning of the code, maintaining the code repository, integrating various parts of the software to create a whole.
+
+---
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+### Kelvin Wong Jian Quan
+
+
+
+[[github](http://github.com/kelvinvin)] [[Project Portfolio Page (PPP)](team/kelvinvin)]
+
+#### Developer & Documentation in-charge
+
+* Responsible for the quality of various project documents.
+
+---
-* Role: Developer
-* Responsibilities: Dev Ops + Threading
+### Tan Wei Jie
-### James Doe
+
-
+[[github](http://github.com/tanweijie123)] [[Project Portfolio Page (PPP)](team/tanweijie123)]
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+#### Developer & UI in-charge
-* Role: Developer
-* Responsibilities: UI
+* Ensures the UI is designed and integrated properly.
diff --git a/docs/DevOps.md b/docs/DevOps.md
index 4414eea3344..5cd35171bb9 100644
--- a/docs/DevOps.md
+++ b/docs/DevOps.md
@@ -44,7 +44,7 @@ As part of CI, this project uses Codecov to generate coverage reports. Here are
1. Sign up with Codecov using your GitHub account [here](https://codecov.io/signup).
1. Once you are inside Codecov web app, add your fork to CodeCov.
-1. Get the Markdown code for the Codecov badge provided in `Settings > Badges` and update the `docs/index.md` of your repo with it so that the badge [](https://codecov.io/gh/se-edu/addressbook-level3) in that page reflects the coverage of your project.
+1. Get the Markdown code for the Codecov badge provided in `Settings > Badges` and update the `docs/index.md` of your repo with it so that the badge [](https://codecov.io/gh/AY2021S1-CS2103T-T13-3/tp) in that page reflects the coverage of your project.
### Repository-wide checks
@@ -73,7 +73,7 @@ Any warnings or errors will be printed out to the console.
Here are the steps to create a new release.
-1. Update the version number in [`MainApp.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/MainApp.java).
+1. Update the version number in [`MainApp.java`](https://github.com/AY2021S1-CS2103T-T13-3/tp/tree/master/src/main/java/seedu/address/MainApp.java).
1. Generate a fat JAR file using Gradle (i.e., `gradlew shadow`).
1. Tag the repo with the version number. e.g. `v0.1`
1. [Create a new release using GitHub](https://help.github.com/articles/creating-releases/). Upload the JAR file you created.
diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md
index 4829fe43011..f1513d8578c 100644
--- a/docs/DeveloperGuide.md
+++ b/docs/DeveloperGuide.md
@@ -2,43 +2,82 @@
layout: page
title: Developer Guide
---
+
+Welcome to FitEgo! This document will serve as a developer guide to the all-in-one scheduling application. This is to encourage and guide interested parties who wish to extend FitEgo and improve its features.
+
+Made with **fitness instructors** in mind, **FitEgo** is a **desktop program** that helps them **manage their clients and schedules**, optimized for use via a Command Line Interface (CLI) while still having the benefits of a Graphical User Interface (GUI). If you can type fast, **FitEgo** can get your client management tasks done faster than traditional GUI apps.
+
+
Table of Contents
+
* Table of Contents
{:toc}
--------------------------------------------------------------------------------------------------------------------
+
-## **Setting up, getting started**
+## 1 **Setting up, getting started**
Refer to the guide [_Setting up and getting started_](SettingUp.md).
--------------------------------------------------------------------------------------------------------------------
-## **Design**
+### 1.1 How to interpret notations
+
+Below are a few examples of the common notations in this document in which the different backgrounds and icons represent different meanings.
+
+[comment]: <> (Copy the blocks below and edit your message)
+
+
+
+:information_source: **Note:**
+
+Important to know.
+
+
+
+
+
+[comment]: <> (This only appears in Github CSS)
+
+:bulb: **Tip:**
+
+Additional information.
+
+ Figure 1 - Architecture Diagram
+
The ***Architecture Diagram*** given above explains the high-level design of the App. Given below is a quick overview of each component.
-:bulb: **Tip:** The `.puml` files used to create diagrams in this document can be found in the [diagrams](https://github.com/se-edu/addressbook-level3/tree/master/docs/diagrams/) folder. Refer to the [_PlantUML Tutorial_ at se-edu/guides](https://se-education.org/guides/tutorials/plantUml.html) to learn how to create and edit diagrams.
+:bulb: **Tip:** The `.puml` files used to create diagrams in this document can be found in the [diagrams](https://github.com/AY2021S1-CS2103T-T13-3/tp/tree/master/docs/diagrams/) folder. Refer to the [_PlantUML Tutorial_ at se-edu/guides](https://se-education.org/guides/tutorials/plantUml.html) to learn how to create and edit diagrams.
-**`Main`** has two classes called [`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). It is responsible for,
+**`Main`** has two classes called [`Main`](https://github.com/AY2021S1-CS2103T-T13-3/tp/tree/master/src/main/java/seedu/address/Main.java) and [`MainApp`](https://github.com/AY2021S1-CS2103T-T13-3/tp/tree/master/src/main/java/seedu/address/MainApp.java). It is responsible for,
* At app launch: Initializes the components in the correct sequence, and connects them up with each other.
* At shut down: Shuts down the components and invokes cleanup methods where necessary.
-[**`Commons`**](#common-classes) represents a collection of classes used by multiple other components.
+[**`Commons`**](#26-common-classes) represents a collection of classes used by multiple other components.
The rest of the App consists of four components.
-* [**`UI`**](#ui-component): The UI of the App.
-* [**`Logic`**](#logic-component): The command executor.
-* [**`Model`**](#model-component): Holds the data of the App in memory.
-* [**`Storage`**](#storage-component): Reads data from, and writes data to, the hard disk.
+* [**`UI`**](#22-ui-component): The UI of the App.
+* [**`Logic`**](#23-logic-component): The command executor.
+* [**`Model`**](#24-model-component): Holds the data of the App in memory.
+* [**`Storage`**](#25-storage-component): Reads data from, and writes data to, the hard disk.
Each of the four components,
@@ -47,180 +86,560 @@ Each of the four components,
For example, the `Logic` component (see the class diagram given below) defines its API in the `Logic.java` interface and exposes its functionality using the `LogicManager.java` class which implements the `Logic` interface.
-
+
+
+
+
+ Figure 2 - Logic Component Class Diagram
+
**How the architecture components interact with each other**
-The *Sequence Diagram* below shows how the components interact with each other for the scenario where the user issues the command `delete 1`.
+The *Sequence Diagram* below shows how the components interact with each other for the scenario where the user issues the command `cdel 1`.
-
+
+
+
+
+ Figure 3 - Architecture Sequence Diagram
+
The sections below give more details of each component.
-### UI component
+### 2.2 UI component
+
+
+
+
+
+ Figure 4a - UI Class Diagram (High Level)
+
-
+The UiComponents package in the above diagram has the following classes.
+
+
+
+
+
+ Figure 4b - UI Class Diagram - UiComponents package
+
**API** :
-[`Ui.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/Ui.java)
+[`Ui.java`](https://github.com/AY2021S1-CS2103T-T13-3/tp/tree/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.
+The UI consists of a `MainWindow` that is made up of several parts e.g.`CommandBox`, `ResultDisplay`, `Homepage` etc, as shown in Figure 4b above.
+All of these subcomponents are part of the UiComponents package, and each part make up the entire GUI.
+Every class within the `UiComponents` package, including the `MainWindow`, inherit from the abstract `UiPart` class.
-The `UI` component uses 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 `UIComponents` uses JavaFx and ControlsFX 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/AY2021S1-CS2103T-T13-3/tp/tree/master/src/main/java/seedu/address/ui/MainWindow.java) is specified in [`MainWindow.fxml`](https://github.com/AY2021S1-CS2103T-T13-3/tp/tree/master/src/main/resources/view/MainWindow.fxml)
-The `UI` component,
+The `UI` component interacts with these external API:
-* Executes user commands using the `Logic` component.
-* Listens for changes to `Model` data so that the UI can be updated with the modified data.
+* `Logic` : Performs the Execution of user's commands.
+* `Model` : Listens for changes to data so that the UI can be updated with the modified data.
-### Logic component
+### 2.3 Logic component
-
+
+
+
+
+ Figure 5 - Logic Component Class Diagram
+
**API** :
-[`Logic.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/logic/Logic.java)
+[`Logic.java`](https://github.com/AY2021S1-CS2103T-T13-3/tp/tree/master/src/main/java/seedu/address/logic/Logic.java)
1. `Logic` uses the `AddressBookParser` class to parse the user command.
1. This results in a `Command` object which is executed by the `LogicManager`.
-1. The command execution can affect the `Model` (e.g. adding a person).
+1. The command execution can affect the `Model` (e.g. deleting a Client).
1. The result of the command execution is encapsulated as a `CommandResult` object which is passed back to the `Ui`.
1. In addition, the `CommandResult` object can also instruct the `Ui` to perform certain actions, such as displaying help to the user.
-Given below is the Sequence Diagram for interactions within the `Logic` component for the `execute("delete 1")` API call.
+Given below is the Sequence Diagram for interactions within the `Logic` component for the `execute("cdel 1")` API call.
-
+
+
:information_source: **Note:** The lifeline for `DeleteCommandParser` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+
:information_source: **Note:** The lifeline for `DeleteClientCommandParser` and `DeleteClientCommand` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
-### Model component
+
+
+### 2.4 Model component
-
+
+
+
+
+ Figure 7 - Model Component Class Diagram
+
-**API** : [`Model.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/model/Model.java)
+The figure above gives the overall architecture of the Model component.
+
+
+
+
+
+ Figure 8 - Model Component Class Diagram - continued
+
+
+The figure above gives a more detailed class diagram for each of the Client, Session and Schedule packages.
+
+**API** : [`Model.java`](https://github.com/AY2021S1-CS2103T-T13-3/tp/tree/master/src/main/java/seedu/address/model/Model.java)
The `Model`,
* stores a `UserPref` object that represents the user’s preferences.
* stores the address book data.
-* exposes 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.
+* exposes 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.
* does not depend on any of the other three components.
-
:information_source: **Note:** 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` object.
-
-
+### 2.5 Storage component
+
+
+
+
+ Figure 9 - Storage Component Class Diagram
+
-### 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/AY2021S1-CS2103T-T13-3/tp/tree/master/src/main/java/seedu/address/storage/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.
-### Common classes
+### 2.6 Common classes
Classes used by multiple components are in the `seedu.addressbook.commons` package.
--------------------------------------------------------------------------------------------------------------------
+
-## **Implementation**
+## 3 **Implementation**
This section describes some noteworthy details on how certain features are implemented.
-### \[Proposed\] Undo/redo feature
+### 3.1 Logging
-#### Proposed Implementation
+We are using `java.util.logging` package for logging. The `LogsCenter` class is used to manage the logging levels
+and logging destinations.
-The proposed undo/redo mechanism is facilitated by `VersionedAddressBook`. It extends `AddressBook` with an undo/redo history, stored internally as an `addressBookStateList` and `currentStatePointer`. Additionally, it implements the following operations:
+- The logging level can be controlled using the `logLevel` setting in the configuration file
+(See [Section 3.2](#32-configuration), “Configuration”)
+- The `Logger` for a class can be obtained using `LogsCenter.getLogger(Class)` which will log messages according
+to the specified logging level
+- Currently log messages are output through both `Console` and to a `.log` file.
-* `VersionedAddressBook#commit()` — Saves the current address book state in its history.
-* `VersionedAddressBook#undo()` — Restores the previous address book state from its history.
-* `VersionedAddressBook#redo()` — Restores a previously undone address book state from its history.
+**Logging Levels**
-These operations are exposed in the `Model` interface as `Model#commitAddressBook()`, `Model#undoAddressBook()` and `Model#redoAddressBook()` respectively.
+- **SEVERE** : Critical problem detected which may possibly cause the termination of the application
+- **WARNING** : Can continue, but with caution
+- **INFO** : Information showing the noteworthy actions by the App
+- **FINE** : Details that is not usually noteworthy but may be useful in debugging
+e.g. print the actual list instead of just its size
-Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.
-Step 1. The user launches the application for the first time. The `VersionedAddressBook` will be initialized with the initial address book state, and the `currentStatePointer` pointing to that single address book state.
+### 3.2 Configuration
-
+Certain properties of the application can be controlled(e.g. user prefs file location, logging level),
+through the configuration file (default: `config.json`)
-Step 2. The user executes `delete 5` command to delete the 5th person in the address book. The `delete` command calls `Model#commitAddressBook()`, causing the modified state of the address book after the `delete 5` command executes to be saved in the `addressBookStateList`, and the `currentStatePointer` is shifted to the newly inserted address book state.
+
-
+### 3.3 Edit Session feature
-Step 3. The user executes `add n/David …` to add a new person. The `add` command also calls `Model#commitAddressBook()`, causing another modified address book state to be saved into the `addressBookStateList`.
+
The Edit Session feature allows user to edit a Session.
:information_source: **Note:** If a command fails its execution, it will not call `Model#commitAddressBook()`, so the address book state will not be saved into the `addressBookStateList`.
+The proposed Edit Session mechanism is facilitated by `Addressbook`.
-
+These operation is exposed in the `Model` interface as `Model#setSession()`.
+
+Given below is an example usage scenario and how the Edit Session mechanism behaves at each step.
-Step 4. The user now decides that adding the person was a mistake, and decides to undo that action by executing the `undo` command. The `undo` command will call `Model#undoAddressBook()`, which will shift the `currentStatePointer` once to the left, pointing it to the previous address book state, and restores the address book to that state.
+Step 1. The user launches the application for the first time.
+The `AddressBook` will be initialized with the initial client, session and schedule list.
-
+Step 2. The user executes `sedit 1 g/coolgym` command to edit the first Session in the address book.
+The `sedit` command calls `Model#setSession()`, causing changes to be made in the Session List after the `sedit 1 g/coolgym` command executes.
-
:information_source: **Note:** If the `currentStatePointer` is at index 0, pointing to the initial AddressBook state, then there are no previous AddressBook states to restore. The `undo` command uses `Model#canUndoAddressBook()` to check if this is the case. If so, it will return an error to the user rather
-than attempting to perform the undo.
+The following sequence diagram shows how the Edit Session operation works:
+
+
+
+
+
+ Figure 10 - Edit Session Sequence Diagram
+
+
+
:information_source: **Note:** The lifeline for `EditSessionCommand` and `EditSessionCommandParser` should both end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
-The following sequence diagram shows how the undo operation works:
+The following activity diagram summarizes what happens when a user executes a new `EditSession` command, with the assumption that the user inputs a valid command:
+
+
+
:information_source: **Note:** The lifeline for `UndoCommand` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+The Delete Session feature allows user to cancel a session, and delete all schedules associated to the session.
+#### 3.4.1 Implementation
+
+The Delete Session mechanism is facilitated by `DeleteSessionCommand` which extends `Command`. The format of the
+command is given by:
+
+```sdel INDEX [f/]```
+
+When using this command, the `INDEX` should refer to the index shown in the Session List on the right panel.
+By default, the command will not delete the session if there are schedules associated to the session.
+However, the user can pass in an optional force (`f/`) parameter to delete all schedules associated to the session.
+
+The following activity diagram summarizes what happens when a user executes a new `DeleteSession` command, with the assumption that the user inputs a valid command.
+
+
+
+
+
+ Figure 12 - Delete Session Activity Diagram
+
+
+The following diagram shows a possible application state in FitEgo, where 2 clients, Andy and John, are scheduled to a same session.
+
+
+
+
+
+ Figure 13 - A possible application state
+
+
+In the following sequence diagram, we trace the execution when the user decides to enter the Delete Session command
+`sdel 1 f/` into FitEgo with the above application state, where the first session in the Session List is the "enduranceTraining" session.
+For simplicity, we will refer to this command input as `commandText`.
+
+
+
:information_source: **Note:** The lifeline for `DeleteSessionCommand` and `DeleteSessionCommandParser`
+should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
-The `redo` command does the opposite — it calls `Model#redoAddressBook()`, which shifts the `currentStatePointer` once to the right, pointing to the previously undone state, and restores the address book to that state.
+The sequence diagram above shows how the `DeleteSessionCommand` is executed in FitEgo. The `LogicManager` receives user
+command as commandText and parses it with `AddressBookParser`. It will parse the command and pass the remaining
+arguments to `DeleteSessionCommandParser` to construct a `DeleteSessionCommand`. This `DeleteSessionCommand` is
+returned to the `LogicManager` which will then executes it with reference to the model argument.
+
+The model will first get the current `FilteredSessionList` instance to get the session to be deleted. It will then check
+whether there exist any schedule associated to the session. As there are currently 2 schedules associated to the "enduranceTraining" session in FitEgo and the boolean `isForced`
+is set to true, the model will remove them from `AddressBook`. It will then create a `CommandResult` to relay feedback
+message back to the UI and return control back to `LogicManager`. It will persist these changes by saving the addressbook to the storage.
+
+#### 3.4.2 Design Considerations
+
+In designing this feature, we had to consider several alternative ways in which we can choose to handle session deletion.
+
+- **Alternative 1 (current choice):** Delete session only after all associated schedules are deleted.
+ - Pros:
+ 1. Easier to maintain data integrity.
+ - Cons:
+ 1. Extra logic inside the method implementation.
+ 2. May have performance issues in terms of response time if there are a lot of schedules or sessions stored in FitEgo.
+
+- **Alternative 2:** Mark session as deleted and treat schedules with deleted session as invalid
+ - Pros:
+ 1. Easier to implement the method.
+ 2. No need to handle additional force flag option.
+ - Cons:
+ 1. We must keep track of deleted sessions, which might bloat up the application over time.
+ 2. Harder to maintain data integrity over time.
+
+- **Alternative 3:** Delete the session without checking for associated schedules
+ - Pros: Easy to implement.
+ - Cons: A schedule might have invalid session, breaking data integrity.
+
+
+
+### 3.5 Add Schedule feature
+
+The Add Schedule feature allows user to create a Schedule associated with a Client and a Session.
+In other words, it allows user to schedule a Client to a Session.
-
:information_source: **Note:** If the `currentStatePointer` is at index `addressBookStateList.size() - 1`, pointing to the latest address book state, then there are no undone AddressBook states to restore. The `redo` command uses `Model#canRedoAddressBook()` to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo.
+#### 3.5.1 Implementation
+The Add Schedule mechanism is facilitated by `AddScheduleCommand` which extends `Command`. The format of the
+command is given by:
+
+```schadd c/CLIENT_INDEX s/SESSION_INDEX```
+
+When using this command, the `CLIENT_INDEX` should refer to the index shown in the Client List on the left panel, and is used to specify the Client. The `SESSION_INDEX` should refer to the index shown in the Session List on the right panel, and is used to specify the Session.
+
+The following activity diagram summarizes the decision making process when a user executes a new `AddSchedule` command.
+
+
+
+
+
+ Figure 16 - Add Schedule Activity Diagram
+
+
+#### 3.5.2 Command Usage Examples
+
+Assume the current state of the displayed Client List, displayed Session List, and Schedules (all Schedules in FitEgo) are as illustrated in the following simplified object diagram:
+
+
+
+
+
+ Figure 17 - Sample current state of Add Schedule
+
+
+Now, consider two cases of Add Schedule command to be invoked.
+
+**Case 1**: `schadd c/2 s/1`
+
+Here is what happens when `schadd c/2 s/1` is invoked.
+
+To some extent, the mechanism (on how it involves `LogicManager`, `AddressBookParser`, and saving the changes to `Storage`) is similar to that of [Delete Session](#34-delete-session-feature), as illustrated in [its sequence diagram](#f14). The main differences are on the method call `parseCommand()` and `DeleteSessionCommand#execute(model)`.
+
+`parseCommand()` method call:
+Instead of using `DeleteSessionCommandParser`, it uses `AddScheduleCommandParser` to parse the argument `c/2 s/1` such that it returns an `AddScheduleCommand` object called `a` with Client index `2` and Session index `1`.
+
+`AddScheduleCommand#execute(model)` will be called instead of `DeleteSessionCommand#execute(model)`. For this particular case, the method call `AddScheduleCommand#execute(model)` can be traced using the following sequence diagram snippet.
+
+
+
:information_source: **Note:** The lifeline for `AddScheduleCommand` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+
+As shown in the figure above, first it gets the Client and Session from the filtered (displayed) lists. Then, it checks for existing identical Schedule (Schedule that consists of the same Client and Session) using `hasAnyScheduleAssociatedWithClientAndSession()`.
+Since for this case no identical Schedule is not found, a new Schedule object is created and added into the Model using `Model#addSchedule()`. Finally, it returns the CommandResult to indicate a success.
+
+Thus, `schadd c/2 s/1` will add a Schedule associated with Andy (the second Client in the Client List) and endurance training from 12/02/2020 1400 - 1600 (the first Session in the Session List). The result can be illustrated by the following object diagram, which shows a new Schedule is created.
+
+
+
+
+
+ Figure 19 - Result of invoking schadd c/2 s/1
+
-Step 5. The user then decides to execute the command `list`. Commands that do not modify the address book, such as `list`, will usually not call `Model#commitAddressBook()`, `Model#undoAddressBook()` or `Model#redoAddressBook()`. Thus, the `addressBookStateList` remains unchanged.
+**Case 2:** `schadd c/1 s/1`
-
+On the other hand, invoking `schadd c/1 s/1` will result in an error shown to the user as an identical Schedule already exists. [Here](#f17), John is already scheduled to the endurance training Session from 12/02/2020 1400 - 1600.
-Step 6. The user executes `clear`, which calls `Model#commitAddressBook()`. Since the `currentStatePointer` is not pointing at the end of the `addressBookStateList`, all address book states after the `currentStatePointer` will be purged. Reason: It no longer makes sense to redo the `add n/David …` command. This is the behavior that most modern desktop applications follow.
+
-
+### 3.6 Edit Schedule feature
-The following activity diagram summarizes what happens when a user executes a new command:
+The Edit Schedule feature allows user to edit a Schedule that is associated with a Client and a Session.
-
+#### 3.6.1 Implementation
-#### Design consideration:
+The proposed Edit Schedule mechanism is facilitated by `Addressbook`, similar to the [Edit Session Command](#33-edit-session-feature).
-##### Aspect: How undo & redo executes
+This operation is exposed in the `Model` interface as `Model#setSchedule()`.
-* **Alternative 1 (current choice):** Saves the entire address book.
- * Pros: Easy to implement.
- * Cons: May have performance issues in terms of memory usage.
+Similar to the Edit Session mechanism, the example usage scenario below shows how Edit Schedule mechanism behaves:
-* **Alternative 2:** Individual command knows how to undo/redo by
+The user executes `schedit c/1 s/1 us/2` command to edit the Schedule with the first Session and first Client in the address book.
+The `schedit` command calls `Model#setSchedule()`, causing changes to be made in the address book after the `schedit c/1 s/1 us/2` command executes, meaning that the Schedule is now associated with the second Session.
+
+The following activity diagram summarizes what happens when a user executes a new `EditSchedule` command, with the assumption that the user inputs a valid command:
+
+
+
+
+
+ Figure 20 - Edit Schedule Activity Diagram
+
+
+#### 3.6.2 Design considerations
+
+* **Alternative 1 (current choice):** Retrieve Schedule using Client and Session Index.
+ * Pros: Clearer to retrieve.
+ * Cons: Require user to know the Client and Session Index separately.
+
+* **Alternative 2:** Retrieve Schedule using Schedule Index
itself.
- * 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.
+ * Pros: Easier to retrieve.
+ * Cons: Implementation is more confusing as User there's a conflict between Index and user-typed String index.
+
+
+
+### 3.7 View Client's Weight feature
+
+The viewing of client's weight feature allows the user to check in on a Client's progress after multiple Sessions.
+This data is important because it allows the user to check the effectiveness of his training schedule and customise the training
+based on the remarks and weight progress.
+
+Viewing of Client's Weight is accessible when the user calls `cview [INDEX]` followed by activating the `Weight` tab pane.
+
+#### 3.7.1 Implementation
+
+The recording of weight is stored in `Schedule` class. This is because we believe that trainer would optionally take a weight measurement
+at the start of every session. Thus, to get the weight change over time, a list of schedules related to the `Client` has to be extracted.
+
+In the following sequence diagram, we trace the execution starting from when the user calls `cview 1` until when the UI is updated with Client View.
+
+
+
+
+:information_source: **Note:**
+
+The steps used to create CommandResult is omitted in the sequence diagram for clarity of diagram. The return object of `logic.execute("cview 1")`
+is a CommandResult object, within which, contains a Supplier which returns a Pane for MainWindow to display when activated.
+
+
+
+As shown in the "alt" frame, the chart is added into the tab pane if there are associated schedule and the weight (if present within the `Schedule` object)
+will be added into the line chart. Otherwise, the `Weight` tab will be removed instead of showing an empty chart.
+
+
+
+#### 3.7.2 Design Considerations
+In designing this weight tracking feature, we had considered several alternative ways in which we can store and retreive the weight.
+
+* **Alternative 1 (current choice):** Stores the `Weight` within the `Schedule` object
+ * Pros: The user can track the weight against each session attended.
+ * Cons: Multiple weight measurement during a session, and weight measurement without a session cannot be entered.
+
+* **Alternative 2:** Stores a list of `Weight` within the `Client` object
+ * Pros: Do not require a schedule in order to track weight.
+ * Cons: Lesser information about the weight (schedule's exercise, remarks, time, etc) is stored.
+
+
+
+### 3.8 View Session by period feature
+
+The View Session by period feature allows users to filter the Session List to show only those within the requested time period.
+
+
:information_source: **Note:** The Ui component RightSideBar comprises a ListView of
+ Session List and a title that reflects the latest filter on Session List resulting from ViewSessionCommand.
+ Session List's list and Ui-related operations are handled by Model and RightSideBar respectively.
+
+
+The View Session mechanism is facilitated by `ViewSessionCommand` which extends `Command`. The format of the
+command is given by:
+
+```sview p/PERIOD```
+
+#### 3.8.1 Implementation
+
+When using this command, `PERIOD` should refer to either a variable period or fixed period
+that returns true after running `ViewSessionCommand#isValidPeriod`. Fixed periods are found in `ViewSessionCommand#PREDICATE_HASH_MAP`, whereas variable periods
+must follow the format `(+/-)#(D/W/M/Y)`.
+
+The following activity diagram summarizes what happens when a user executes a new View Session command.
+
+
+
+
+
+ Figure 22 - View Session Activity Diagram
+
-_{more aspects and alternatives to be added}_
+In the following sequence diagram, we trace the execution when the user decides to enter the View Session command
+`sview p/week` into FitEgo.
-### \[Proposed\] Data archiving
+
+
+
+
+ Figure 23 - View Session Sequence Diagram
+
-_{Explain here how the data archiving feature will be implemented}_
+
+
:information_source: **Note:** The lifeline for `ViewSessionCommandParser` and `ViewSessionCommand`
+should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+
+
+1. After the user enters an input to view session for the week, the input is sent to `LogicManager` to be executed. The `AddressBookParser` identifies the command type and constructs a `ViewSessionCommandParser`.
+
+1. The `ViewSessionCommandParser` then parses for the period and constructs a `ViewSessionCommand` with the period.
+
+1. The `ViewSessionCommand` is returned to the `LogicManager` which will then execute it.
+
+1. During execution of `ViewSessionCommand`, a predicate for sessions within the upcoming week is created (refer to Activity Diagram above for details on flow). The Session List in `Model` is then filtered by this predicate.
+
+1. Command result is passed to `MainWindow` to indicate a successful execution. `MainWindow` will then update the `RightSideBar`.
+
+
+
+
+
+ Figure 25 - View Session Update RightSideBar Ref Sequence Diagram
+
+
+1. The `RightSideBar` retrieves the latest period "WEEK" from the command result and text. `Title` is set to "WEEK". It then retrieves the filtered Session List from `LogicManager` and updates the items in `SessionListView`.
+
+#### 3.8.2 Design Considerations
+
+In designing this feature, we had to consider several alternative ways in which we can choose to handle viewing session by period.
+
+* **Alternative 1 (current choice):** Update title of `RightSideBar` based on command result.
+ * Pros: Does not lower maintainability and requires the least changes to existing implementation and test code.
+ * Cons: Violates Separation of Concerns principle as `RightSideBar` has to check whether command result is from `ViewSessionCommand`.
+
+
+* **Alternative 2:** Using Observer pattern (Observer RightSideBar, Observable Command) to update title of `RightSideBar`.
+ * Pros: Reduces coupling between `Ui` and `Logic`.
+ * Cons:
+ 1. `RightSideBar` would only be updated when `ViewSessionCommand` is run.
+ If we set the default session view to Week when `Logic` is initialised, all sessions in existing test cases will need to start within 7 days of current date, which introduces additional complexity.
+ Hence, we would not customise `RightSideBar`'s default session view.
+ 2. Violates YAGNI principle as making `Command` implement `Observable` interface requires addition of notify and add observer methods for all commands.
+ This also increases chances of errors made in implementation.
--------------------------------------------------------------------------------------------------------------------
+
-## **Documentation, logging, testing, configuration, dev-ops**
+## 4 **Documentation, logging, testing, configuration, dev-ops**
* [Documentation guide](Documentation.md)
* [Testing guide](Testing.md)
@@ -230,50 +649,115 @@ _{Explain here how the data archiving feature will be implemented}_
--------------------------------------------------------------------------------------------------------------------
-## **Appendix: Requirements**
+## 5 **Appendix A: Requirements**
-### Product scope
+### 5.1 Product scope
**Target user profile**:
-
-* has a need to manage a significant number of contacts
-* prefer desktop apps over other types
+* is a fitness instructor who has trouble managing a significant number of clients and sessions
+* prefers desktop apps over other types
+* favours an All-in-One software over multiple apps
* can type fast
* prefers typing to mouse interactions
-* is reasonably comfortable using CLI apps
+* is reasonably comfortable using CLI apps while appreciates a nice GUI that can show his weekly schedule
+* prefers a simple and minimalistic view, as he does not like clutters.
-**Value proposition**: manage contacts faster than a typical mouse/GUI driven app
+**Value proposition**: to help a fitness instructor keeps track of his customers easily, via CLI as he’s a fast typer.
+He can spend more time on his clients/his routine rather than manually using alternative software like Excel to track
+administrative matters.
+
-### User stories
+### 5.2 User stories
Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unlikely to have) - `*`
-| Priority | As a … | I want to … | So that I can… |
+| Priority | As a ... | I want to ... | So that I can ... |
| -------- | ------------------------------------------ | ------------------------------ | ---------------------------------------------------------------------- |
-| `* * *` | new user | see usage instructions | refer to instructions when I forget how to use the App |
-| `* * *` | user | add a new person | |
-| `* * *` | user | delete a person | remove entries that I no longer need |
-| `* * *` | user | find a person by name | locate details of persons without having to go through the entire list |
-| `* *` | user | hide private contact details | minimize chance of someone else seeing them by accident |
-| `*` | user with many persons in the address book | sort persons by name | locate a person easily |
+| `* * *` | new trainer | see usage instructions | refer to instructions when I forget how to use the App |
+| `* * *` | trainer | add a new client | |
+| `* * *` | trainer | edit a client | change the details of a client |
+| `* * *` | trainer | view a client's detail | view at all of the client's details at a glance |
+| `* * *` | trainer | delete a client | remove entries that I no longer need |
+| `* * *` | trainer | find a client by name | locate details of clients without having to go through the entire list |
+| `* * *` | trainer | tag my client | I know their allergy / injury history and can advise them an appropriate training / diet schedule |
+| `* * *` | trainer | add a new session | |
+| `* * *` | trainer | edit a session | change the details of a session |
+| `* * *` | busy fitness trainer | filter sessions by time | view only the upcoming or other important sessions |
+| `* * *` | trainer | delete a session | cancel all schedules if there is an urgent need |
+| `* * *` | trainer | add a new schedule | |
+| `* * *` | trainer | edit a schedule | change the details of a schedule |
+| `* * *` | trainer | view a schedule's detail | view at all of the schedule's details at a glance |
+| `* * *` | trainer | delete a schedule | remove schedule that are cancelled or completed |
+| `* *` | international trainer | input and view weight in either kg or pound| save time on manual conversion |
+| `* *` | fitness trainer | store clients' session feedback and weight| utilise previous sessions and plan exercises for upcoming sessions |
+| `* *` | forgetful fitness trainer | track clients' payments | remind those who have not paid up |
+| `* *` | busy fitness trainer | query if a particular time slot is open | add new clients to that time slot |
+| `* *` | fitness trainer | track clients' weight over time| keep track of my clients progress over time |
+| `*` | trainer with many clients in the address book | sort clients by name | locate a client easily |
+| `*` | user | change software background between light and dark mode | customise my experience |
+| `*` | trainer focused on coaching pre-NS teen | track client's date of birth | adjust the fitness intensity depending on IPPT period |
+
+
+
+### 5.3 Use cases
+
+(For all use cases below, the **System** is the `FitEgo` and the **Actor** is the `user`, unless specified otherwise)
+
+
+Use case: UC01 Add a Client
+
+**MSS**
+
+ 1. User requests to add a specific Client in the list.
+ 2. FitEgo adds the Client. Use case ends.
+
+**Extensions**
-*{More to be added}*
+* 1a. The Client is within the list.
+
+ * 1a1. FitEgo shows an error message.
-### Use cases
+ Use case ends.
+
+* 1b. The Client is missing some required details.
-(For all use cases below, the **System** is the `AddressBook` and the **Actor** is the `user`, unless specified otherwise)
+ * 1b1. FitEgo shows an error message.
+
+ Use case ends.
-**Use case: Delete a person**
+
+
+Use case: UC02 Edit a Client
**MSS**
-1. User requests to list persons
-2. AddressBook shows a list of persons
-3. User requests to delete a specific person in the list
-4. AddressBook deletes the person
+ 1. User requests to list Clients.
+ 2. FitEgo shows a list of Clients.
+ 3. User requests to edit a specific Client in the list.
+ 4. FitEgo edits the Client according to the specified details. Use case ends.
+
+**Extensions**
+
+* 2a. The list is empty.
+
+ Use case ends.
+
+* 3a. The given index is invalid.
- Use case ends.
+ * 3a1. FitEgo shows an error message.
+
+ Use case resumes at step 2.
+
+
+Use case: UC03 Delete a Client
+
+**MSS**
+
+ 1. User requests to list Clients.
+ 2. FitEgo shows a list of Clients.
+ 3. User requests to delete a specific Client in the list.
+ 4. FitEgo deletes the Client. Use case ends.
**Extensions**
@@ -283,41 +767,258 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli
* 3a. The given index is invalid.
- * 3a1. AddressBook shows an error message.
+ * 3a1. FitEgo shows an error message.
+
+ Use case resumes at step 2.
+* 3b. The given index refers to a Client associated with one or more Schedule.
+
+ * 3b1. FitEgo shows an instruction to force delete.
+
Use case resumes at step 2.
+
+* 3c. User requests to force delete a specific Client in the list.
-*{More to be added}*
+ * 3c1. FitEgo force deletes the Client and its associated Schedules if any.
-### Non-Functional Requirements
+ Use case ends.
+
+
-1. Should work on any _mainstream OS_ as long as it has Java `11` or above installed.
-2. Should be able to hold up to 1000 persons without a noticeable sluggishness in performance for typical usage.
-3. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.
+Use case: UC04 Find a Client
-*{More to be added}*
+**MSS**
+
+ 1. User requests to find some Client based on keyword or text.
+ 2. FitEgo displays the Client's whose name matches the keyword or text. Use case ends.
+
+**Extensions**
+
+* 2a. The search result is empty.
+
+ * 2a1. FitEgo displays no clients found.
+
+ Use case ends.
+
+
+
+Use case: UC05 View a Client
+
+**MSS**
+
+ 1. User requests to list Clients.
+ 2. FitEgo shows a list of Clients.
+ 3. User requests to view a specific Client in the list.
+ 4. FitEgo shows the Client's profile. Use case ends.
+
+**Extensions**
+* 2a. The list is empty.
+
+ Use case ends.
+
+* 3a. The given index is invalid.
+
+ * 3a1. FitEgo shows an error message.
+
+ Use case resumes at step 2.
+
+* 4a. Previous Client's profile window is not closed.
+
+ * 4a1. The previous Client's profile will be closed.
+
+ * 4a2. The current Client's profile will be displayed.
+
+ Use case ends.
+
+
+
+**Use case: UC06 Add a Session**
+
+Similar to [UC01 (Add a Client)](#uc01), but replace Client with Session.
+
+
+
+**Use case: UC07 Edit a Session**
+
+Similar to [UC02 (Edit a Client)](#uc02), but replace Client with Session.
+
+
+
+**Use case: UC08 Delete a Session**
+
+Similar to [UC03 (Delete a Client)](#uc03), but replace Client with Session.
+
+
+
+**Use case: UC09 View Session within time period**
+
+**MSS**
+
+ 1. User requests to list Sessions.
+ 1. FitEgo shows a list of Sessions.
+ 2. User requests to filter the Session List by a period.
+ 3. FitEgo filters the Session List according to the specified period and updates the title displayed. Use case ends.
+
+**Extensions**
+
+* 1a. The list is empty.
+
+ Use case ends.
+
+* 2a. The given period is invalid.
+
+ * 2a1. FitEgo shows an error message.
+
+ Use case resumes at step 2.
+
+
+**Use case: UC10 Add a Schedule**
+
+**MSS**
+
+ 1. User requests to list Clients and Sessions.
+ 2. FitEgo shows a list of Clients and list of Sessions.
+ 3. User requests to add a specific Schedule between a specified Client from Client List and Session from Session List.
+ 4. FitEgo adds the Schedule. Use case ends.
+
+**Extensions**
+
+- 3a. The Client index or Session index is invalid.
+
+ - 3a1. FitEgo shows an error message.
+
+ Use case resumes at step 2.
+
+- 3b. The Schedule to be added already exists.
+
+ - 3b1. FitEgo shows an error message.
+
+ Use case resumes at step 2.
+
+
+**Use case: UC11 Edit a Schedule**
+
+**MSS**
+
+ 1. User requests to list Clients and Sessions.
+ 1. FitEgo shows a list of Clients and list of Sessions.
+ 2. User requests to edit a specific Schedule in the list. (i.e. updated Session index, update payment, update weight)
+ 3. FitEgo edits the Schedule according to the specified details. Use case ends.
+
+**Extensions**
+
+* 1a. The list is empty.
+
+ Use case ends.
+
+* 2a. The given index is invalid or request to schedule is absent.
+
+ * 2a1. FitEgo shows an error message.
+
+ Use case resumes at step 2.
+
+
-### Glossary
+**Use case: UC12 Delete a Schedule**
+**MSS**
+
+ 1. User requests to list Clients and Sessions.
+ 2. FitEgo shows a list of Clients and list of Sessions.
+ 3. User requests to delete a Schedule associated with a specified Client from the Client List and Session from the Session List.
+ 4. FitEgo deletes the Schedule. Use case ends.
+
+**Extensions**
+
+- 3a. The Client index or Session index is invalid.
+
+ - 3a1. FitEgo shows an error message.
+
+ Use case resumes at step 2.
+
+- 3b. There is no Schedule associated with the specified Client and Session.
+
+ - 3b1. FitEgo shows an error message.
+
+ Use case resumes at step 2.
+
+
+**Use case: UC13 Open User Guide in Browser**
+
+**MSS**
+ 1. User requests to view Help Window.
+ 2. FitEgo displays Help Window with the User Guide link.
+ 3. User selects the link to access the User Guide.
+ 4. FitEgo opens the User Guide in user's default browser. Use case ends.
+
+**Extensions**
+ - 3a. User closes the Help Window.
+
+ * 3a1. FitEgo closes the Help Window.
+
+ Use case ends.
+
+
+
+**Use case: UC14 Change Unit of Weight Graph**
+
+**MSS**
+1. User requests to view Settings Window.
+2. FitEgo displays Settings Window.
+3. User makes changes to settings.
+4. FitEgo saves changes to settings. Use case ends.
+
+**Extensions**
+* 2a. User closes the Settings Window.
+
+ * 2a1. FitEgo closes the Settings Window.
+
+ Use case ends.
+
+### 5.4 Non-Functional Requirements
+
+1. Should work on any _mainstream OS_ as long as it has Java `11` or above installed.
+2. Should be able to hold up to 1000 clients and sessions without a noticeable sluggishness in performance for typical usage (respond to commands within 2 seconds).
+3. The application should be a single user product.
+4. A fitness instructor with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.
+5. The source code should be open source.
+6. The application should be usable without internet connection
+7. The user interface should be intuitive enough for users who are not IT-savvy
+8. The product can be downloaded freely from Github.
+9. The user should be able to read and modify the data files.
+10. The user should be able to use the application on different machines just by moving the data file
+from your previous machine to your new machine.
+
+### 5.5 Glossary
+
+* **API**: Application Programming Interface
+* **CLI**: Command-Line Interface
+* **FXML**: Extensible Markup Language-based user interface markup language utilised in JavaFX
+* **GUI**: Graphical User Interface
+* **Json**: JavaScript Object Notation, a file format
+* **JavaFX**: The standard GUI library for Java
* **Mainstream OS**: Windows, Linux, Unix, OS-X
-* **Private contact detail**: A contact detail that is not meant to be shared with others
+* **PlantUML**: An open-source tool allowing users to create UML diagrams from a plain text language
+* **YAGNI**: You Aren't Gonna Need It! Principle: Do not add code simply because ‘you might need it in the future’.
+
--------------------------------------------------------------------------------------------------------------------
+
-## **Appendix: Instructions for manual testing**
+## 6 **Appendix B: Instructions for manual testing**
Given below are instructions to test the app manually.
-
:information_source: **Note:** These instructions only provide a starting point for testers to work on;
+
+:information_source: **Note:** These instructions only provide a starting point for testers to work on;
testers are expected to do more *exploratory* testing.
-
-### Launch and shutdown
+### 6.1 Launch and shutdown
1. Initial launch
- 1. Download the jar file and copy into an empty folder
+ 1. Download the jar file and copy into an empty folder.
1. Double-click the jar file Expected: Shows the GUI with a set of sample contacts. The window size may not be optimum.
@@ -326,31 +1027,171 @@ testers are expected to do more *exploratory* testing.
1. Resize the window to an optimum size. Move the window to a different location. Close the window.
1. Re-launch the app by double-clicking the jar file.
- Expected: The most recent window size and location is retained.
+
+ Expected: The most recent window size and location is retained.
-1. _{ more test cases … }_
+
+:information_source: **Note:** All index-based commands mentioned in the test cases below require the index to be greater than zero and smaller than the list size.
-### Deleting a person
+Otherwise, the expected outcome: No changes are made. Error details shown in the status message.
+
-1. Deleting a person while all persons are being shown
+### 6.2 Adding a Client
- 1. Prerequisites: List all persons using the `list` command. Multiple persons in the list.
+1. Adding a Client while all Clients are being shown.
- 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: `cadd n/John Doe p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25 t/injured-thigh t/allergy-dairy`
+ Expected: Client is added to the list.
+ Details of the added Client are shown in the status message.
+
+ 1. Other incorrect Add Client commands to try:
+ * `cadd n/John Doe p/98765432 a/311, Clementi Ave 2, #02-25 t/injured-thigh` (email not added)
+ * `cadd n/John Doe p/98765432 e/example.com a/311, Clementi Ave 2, #02-25 t/injured-thigh t/allergy-dairy` (invalid email address)
+ Expected: Client is not added.
+ Error details are shown in the status message.
- 1. Test case: `delete 0`
- Expected: No person is deleted. Error details shown in the status message. Status bar remains the same.
+### 6.3 Editing a Client
- 1. Other incorrect delete commands to try: `delete`, `delete x`, `...` (where x is larger than the list size)
- Expected: Similar to previous.
+1. Editing a Client while all Clients are being shown.
+
+ 1. Prerequisites: There should be at least 1 Client in the Client List.
+
+ 1. Test case: `cedit 1 p/91234567`
+ Expected: First Client's detail (phone number) is edited.
+ Details of the edited Client are shown is in the status message.
+
+### 6.4 Deleting a Client
+
+1. Deleting a Client while all Clients are being shown.
+
+ 1. Prerequisites: There should be at least 1 Client in the Client List.
+
+ 1. Test case: `cdel 1`
+ Expected: First Client is being deleted from the list.
+ Details of the deleted Client are shown in the status message.
+
+### 6.5 Adding a Session
+
+1. Adding a Session while all Clients are being shown.
+
+ 1. Test case: `sadd g/Machoman Gym ex/Endurance at/29/09/2020 1600 t/120`
+ Expected: Session is added to the list.
+ Details of the added Session are shown in the status message.
+
+ 1. Other incorrect Add Session commands to try:
+ * `sadd g/machoman ex/endurance at/29/09/2020 t/120` (wrong date format)
+ * `sadd g/machoman ex/endurance at/29/09/2020 1600 t/0` (invalid duration)
+ Expected: Session is not added.
+ Error details are shown in the status message.
+
+### 6.6 Editing a Session
-1. _{ more test cases … }_
+1. Editing a Session while all Sessions are being shown.
-### Saving data
+ 1. Prerequisites: There should be at least 1 Session in the Session List.
+
+ 1. Test case: `sedit 1 g/Machoman at/29/09/2020 1600 t/120`
+ Expected: First Session's gym location and timing is edited.
+ Details of the edited Session are shown in the status message.
+
+### 6.7 Deleting a Session
+
+1. Deleting a Session while all Sessions are being shown.
+
+ 1. Prerequisites: There should be at least 1 Session in the Session List.
+
+ 1. Test case: `sdel 1 f/`
+ Expected: The 1st Session in the Session List will be deleted alongside all Schedules associated to the Session.
+ Details of the deleted Session are shown in the status message.
+
+### 6.8 Viewing Sessions within Period
+
+1. Viewing Sessions within Period while the Session List is non-empty.
+
+ 1. Prerequisites: There should be at least 1 Session in the Session List.
+
+ 1. Test case: `sview p/+1d`
+ Expected: The right panel only displays Sessions with start time from 0000hrs today to 2359hrs the next day.
+ Indication that Session List has been successfully updated is shown in the status message.
+
+ 1. Other incorrect View Session commands to try: `sview`, `sview p/+2s` (where unit of time is not d/m/y)
+ Expected: View of Session List is unchanged.
+ Error details shown in the status message.
+
+### 6.9 Adding a Schedule
+
+1. Adding a Schedule while all Clients and Sessions are being shown.
+
+ 1. Prerequisites: There should be at least 1 Client and 1 Session in the Client and Session List respectively.
+
+ 1. Test case: `schadd c/1 s/1`
+ Expected: Add a Schedule associated with the first Client in the Client List and first Session in the Session List.
+ Details of the added Schedule are shown in the status message.
+
+
+### 6.10 Editing a Schedule
+
+1. Editing a Schedule while all Schedules are being shown.
+
+ 1. Prerequisites: There should be at least 1 Schedule with the associated Client and Session.
+
+ 1. Test case: `schedit c/1 s/1 us/2 pd/paid r/text`
+ Expected: Edit Schedule with the first Client and first Session is edited to second Session in the Session List, with payment updated to paid and remarks updated to text.
+ Details of the edited Schedule are shown in the status message.
+
+
+### 6.11 Deleting a Schedule
+
+1. Deleting a Schedule while all Clients and Sessions are being shown.
+
+ 1. Prerequisites: There should be at least 1 Schedule with the associated Client and Session.
+
+ 1. Test case: `schdel c/1 s/1`
+ Expected: Delete the Schedule associated with first Client in the Client List and first Session in the Session List.
+ Details of the deleted Schedule are shown in the status message.
+
+### 6.12 Saving data
1. Dealing with missing/corrupted data files
- 1. _{explain how to simulate a missing/corrupted file, and the expected behavior}_
+ 1. Test case: Open `data/addressbook.json` and change one of the Schedule's `clientEmail` to an email that
+ does not exist inside the `clients` list.
+ Expected: FitEgo notices an invalid storage format and start with an empty addressbook.
+
+ 2. Test case: Open `data/addressbook.json` and change one of the Schedule's `startTime` or `endTime` so that the
+ resulting interval does not exist inside the Session List.
+ Expected: Similar to previous.
+
+
+---
+
+
+## 7 **Appendix C: Efforts**
+### Effort
+We believe that the effort to develop FitEgo is at least twice of that of AB3. Besides new commands, we also enhanced the core of AB3 with the ability to handle modified saved file error gracefully and the ability to upload a customized picture for each Client. Other than the features, we also spent a lot of time proofreading and refining our User Guide and Developer Guide.
+
+### Difficulty
+
+We think that the difficulty level for developing FitEgo was quite high because there are many entities involved (Client, Session, and Schedule) compared to AB3 that only has Person. Schedule is an association class, which needs integration testing and some changes needed to be made when the Schedule-related features were added. New panels and windows such as Client List, Session List, settings window, and Client detail view were also created. Such changes in the UI were very challenging.
+
+Our team spent about 700 hours in total (~20 hours a week) to write around 23k LoC, 30 pages of User Guide and 50 pages of Developer Guide.
+
+### Challenges Faced
+
+The following were challenges encountered since the project began:
+
+#### General
+Due to the ongoing Covid-19 outbreak, we were not able to schedule weekly meet-ups for discussions, and they were replaced by weekly Zoom meetings instead. It is also harder to help other team members without meeting because we are unable to draw the solution and guide them.
+
+##### v1.2
+Midterms were held in the middle of milestone v1.2, resulting in some of the features being integrated nearer to the milestone’s deadline.
+
+##### v1.4
+Iteration v1.4 is short and there were many ongoing projects from other modules, which makes the wrap up of the project challenging. While we did not have many bug reports to fix, our team is constantly looking for bugs and upgrading ourselves so that we can present the best product.
+
+### Achievement
+Excluding the UI, we managed to achieve 81% code coverage, ensuring that our app is well-tested and bug-free. We also ensured that our User Guide and Developer Guide went above and beyond by making it more comprehensive and comprehensible to new developers.
+
+---
-1. _{ more test cases … }_
+
~End of Developer Guide~
diff --git a/docs/SettingUp.md b/docs/SettingUp.md
index b89b691fed9..f5049428880 100644
--- a/docs/SettingUp.md
+++ b/docs/SettingUp.md
@@ -45,7 +45,7 @@ If you plan to use Intellij IDEA (highly recommended):
1. **Learn the design**
- When you are ready to start coding, we recommend that you get some sense of the overall design by reading about [AddressBook’s architecture](DeveloperGuide.md#architecture).
+ When you are ready to start coding, we recommend that you get some sense of the overall design by reading about [FitEgo’s architecture](DeveloperGuide.md#architecture).
1. **Do the tutorials**
These tutorials will help you get acquainted with the codebase.
diff --git a/docs/UserGuide.md b/docs/UserGuide.md
index b91c3bab04d..f8bd0bd0840 100644
--- a/docs/UserGuide.md
+++ b/docs/UserGuide.md
@@ -3,176 +3,865 @@ layout: page
title: User Guide
---
-AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized for use via a Command 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.
+Welcome to FitEgo! This document will serve as a user guide to the all-in-one scheduling application.
+Made with **fitness instructors** in mind, **FitEgo** is a **desktop program** that helps them **manage their clients and schedules**, optimized for use via a Command Line Interface (CLI) while still having the benefits of a Graphical User Interface (GUI). If you can type fast, **FitEgo** can get your client management tasks done faster than traditional GUI apps.
+
+
Table of Contents
* Table of Contents
{:toc}
--------------------------------------------------------------------------------------------------------------------
+
+
+# 1 Quick start
+
+If this is your first time, here are some quick tips to get started.
+
+1. Ensure you have [Java `11`](https://www.oracle.com/java/technologies/javase-jdk11-downloads.html) or above installed in your Computer.
+
+1. Download the latest `FitEgo.jar` from [here](https://github.com/AY2021S1-CS2103T-T13-3/tp/releases).
+
+1. Copy the file to the folder you want to use as the _home folder_ for your **FitEgo** program.
+
+1. Double-click the file to start the app. The GUI similar to the figure below should appear in a few seconds. Note how the app contains some sample data.
+
+
+
+
+ Figure 1 - Sample screenshot of our Ui
+
+
+1. Type the command in the command box and press "Enter" key to execute it. e.g. typing **`help`** and pressing "Enter" key will open the help window.
+ Some example commands you can try:
+
+ * **[`clist`](#321-listing-all-clients--clist)** : Lists all clients stored in **FitEgo**.
+
+ * **[`cadd n/Jane Doe p/91234567 e/jane@gmail.com`](#322-adding-a-client--cadd)** : Adds a client named `Jane Doe` to the Client List.
+
+ * **[`cdel 3`](#325-deleting-a-client--cdel)** : Deletes the third client shown in the Client List.
+
+ * **[`exit`](#315-exiting-the-program--exit)** : Exits the app.
+
+1. Read the [Overview](#12-overview) section for a quick understanding of commands in FitEgo.
+
+1. Refer to the [Keyword](#31-main-keywords) section below for more details of each command.
+
+
+
+### 1.1 How to interpret notations
+
+Below are a few examples of the common notations in this document in which the different backgrounds and icons represent different meanings.
+
+[comment]: <> (Copy the blocks below and edit your message)
+
+
+
+[comment]: <> (This only appears in Github CSS)
+
+:bulb: **Tip:**
+
+Good to learn, but not necessary to know to use FitEgo.
+
+
+
+
-## Quick start
+:star: **Feature:**
-1. Ensure you have Java `11` or above installed in your Computer.
+Important to know.
+
+
+
+
+:heavy_check_mark: **Example:**
+
+An example to follow.
+
+
+
+
+
+:warning: **Warning:**
+
+May have irreversible effect when used. Backup and caution is recommended.
+
+
+
+
+### 1.2 Overview
+
+You are a fitness instructor.
+
+You record your clients' details, training progress, payment status and your own timetable across 3 or 4 different applications.
+
+You struggle to keep all of them updated. You struggle even more to get insights out of them.
-1. Download the latest `addressbook.jar` from [here](https://github.com/se-edu/addressbook-level3/releases).
+FitEgo can help you with that. Here's how:
-1. Copy the file to the folder you want to use as the _home folder_ for your AddressBook.
+FitEgo lets you record crucial information that you want to keep track of using three types of entities as shown in the table below.
-1. Double-click the file to start the app. The GUI similar to the below should appear in a few seconds. Note how the app contains some sample data.
- 
+
Table 1 - Summary of entities
-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.
- Some example commands you can try:
+Item | Prefix | What it represents
+-----|-------| -------------------
+Client | c | Someone who is interested in or has engaged with your services
+Session | s | Timeslot for a fitness session
+Schedule | sch | A client's booking of a session
- * **`list`** : Lists all contacts.
+Here's what you can do:
+1. When you find a client that is interested in your fitness training services, you can add him/her to your list of clients with the
+[`cadd` command](#322-adding-a-client--cadd).
+2. Next, create a fitness session on any free timeslot that you have with the
+[`sadd` command](#331-adding-a-session--sadd).
+3. And, schedule your client to the fitness session with the
+[`schadd` command](#341-adding-a-schedule--schadd).
- * **`add`**`n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01` : Adds a contact named `John Doe` to the Address Book.
+Simple? That's the point of FitEgo.
- * **`delete`**`3` : Deletes the 3rd contact shown in the current list.
+Now, you will probably need to edit, delete and look through your clients and sessions along the way -
+FitEgo supports all those features and more. Ready to begin? Let's start exploring!
- * **`clear`** : Deletes all contacts.
+### 1.3 General Note
- * **`exit`** : Exits the app.
+The program will automatically save after every command execution to guarantee that your data will never be lost.
-1. Refer to the [Features](#features) below for details of each command.
+--------------------------------------------------------------------------------------------------------------------
+
+
+# 2 UI-orientation
+
+You can refer to the figure below to familiarize yourself with the user interface of FitEgo.
+
+[comment]: <> (Why cant you figure out yourself?)
+
+
+
+
+
+ Figure 2 - Callouts of the various UI components
+
+
+
+
+ :bulb: **Tip:**
+
+ You can type into the Command Box and it will display the commands that start with your current input.
+
+
+
+
+ Figure 3 - Sample of autocomplete command
+
+ For example, in the above figure, if you enter `c` and commands that starts with "c" is displayed.
+ For advanced users, you can use the "TAB" key and FitEgo will auto-complete the first suggestion into the command box, thus increasing your typing speed!
+
+
+ The table below describes the function of each UI component.
+
+
Table 2 - Functions of UI Components
+
+| Component | Description |
+| --------------- | ---------------------------------------- |
+| Toolbar | Displays the toolbar for this program. You can access the `exit` and `help` command from here. |
+| Command Box | Displays a text box for your input. You can type your command here. |
+| Result Display | Displays the result of your command. If the execution is successful, it will display a success message. Otherwise, it will prompt an error message |
+| Client List | Displays the list of clients. You can modify this list using [client-related commands](#32-client-related-keywords) |
+| Main Window | Displays the main window of this program. It consists of the statistics of this program, today's schedule and quote of the day |
+| Session List | Displays the list of your sessions. You can modify this list using [session-related commands](#33-session-related-keywords) |
+| Status Bar Footer | Displays the current date and time of the program. If you notice this is incorrect, your PC might be using a different timezone|
--------------------------------------------------------------------------------------------------------------------
+
+
+# 3 Keyword
-## Features
+In this section, you can find all the keywords that will help you fully utilize FitEgo.
**:information_source: Notes about the command format:**
-* Words in `UPPER_CASE` are the parameters to be supplied by the user.
+* Command keywords are case-sensitive.
+
+* If a command format specifies an integer as its constraint, it has an upper bound of 2,147,483,647 by default, unless otherwise specified.
+
+* Items are pairs of prefix and parameter.
+ e.g. `n/NAME` is an item comprising prefix `n/` and parameter `NAME`.
+
+* Words in `UPPER_CASE` are the parameters that you need to provide.
e.g. in `add n/NAME`, `NAME` is a parameter which can be used as `add n/John Doe`.
* Items in square brackets are optional.
- e.g `n/NAME [t/TAG]` can be used as `n/John Doe t/friend` or as `n/John Doe`.
+ e.g `n/NAME [t/TAG]` can be used as `n/John Doe t/injured-thigh` or as `n/John Doe`.
+
+* If a command only expects one item but receives multiple items of the same prefix, FitEgo will accept the last item.
* Items with `…` after them can be used multiple times including zero times.
- e.g. `[t/TAG]…` can be used as ` ` (i.e. 0 times), `t/friend`, `t/friend t/family` etc.
+ e.g. `[t/TAG]…` can be used as ` ` (i.e. 0 times), `t/injured-thigh`, `t/injured-thigh t/allergy-dairy` etc.
-* Parameters can be in any order.
+* Items can be in any order.
e.g. if the command specifies `n/NAME p/PHONE_NUMBER`, `p/PHONE_NUMBER n/NAME` is also acceptable.
-### Viewing help : `help`
+This program has separated the keywords into 4 different categories - [Main](#31-main-keywords),
+[Client](#32-client-related-keywords), [Session](#33-session-related-keywords) and [Schedule](#34-schedule-related-keywords).
+
+
+
+## 3.1 Main Keywords
+All main keywords are described in this section.
+
+### 3.1.1 Viewing home : `home`
+
+You can return to the home page by using this command.
+
+
+
+
+
+ Figure 4 - Homepage View
+
+
+The homepage will display the statistics of your program, today's schedule and quote of the day as shown in the figure above.
+If you do not have any planned schedules for the day, it will display `There are no schedules assigned today!`.
+
+
+
+:star: **Feature:**
+
+If your session spreads over more than 1 day, the schedule will still be displayed if it intersects with today's date.
+
+
+
+
+
+### 3.1.2 Viewing help : `help`
-Shows a message explaning how to access the help page.
+You can ask FitEgo to open a window with a link to the help page as shown in the figure below.
-
+
+
+
+
+ Figure 5 - Help Window
+
Format: `help`
+
+
+:bulb: **Tip:**
+By default, you can press the spacebar key and a browser will open the User Guide. This pop-up window will close after you clicked on the link.
+Alternatively, you may press the "ESC" key to close this window.
+
+
+### 3.1.3 Viewing settings: `settings`
+
+You can ask FitEgo to open a window to change user settings.
+
+
+
+
+:bulb: **Tip:**
+Once the settings window is open, you can use arrow keys to toggle the options.
+You may press "ESC" key to save your changes and close this window. You can press "F2" key anytime in the
+program to open the settings window too.
+
+The current settings available are:
+ * preferred weight unit for graphs
+ *more to come!
+
+
+
+
+### 3.1.4 Clearing all data in the program : `clear`
+
+You can delete all data (client, session, schedule) using the `clear` keyword. All of your existing data will be removed.
+
+
+
+:warning: **Warning:**
+
+By using this command, you will delete all of your data, and by design of the system, it will be automatically saved.
+You will not be able to retrieve your previous data unless you have backed up the data file into an external location.
+
+
+### 3.1.5 Exiting the program : `exit`
+
+You can exit the program using the `exit` command. Your data is saved automatically.
+
+Format: `exit`
+
+
+### 3.1.6 Saving the data
+
+Your data in FitEgo are saved in the hard disk automatically after any command that changes the data. There is no need to save manually.
+
+---
+
+
+## 3.2 Client-related Keywords
+
+In this section, we will describe client-related keywords. Before that, let's define what we mean by client.
+
+
+
+:information_source: **Client:**
+
+A client is someone who is interested in or has engaged with your fitness training services.
+
+Each client must have a unique email.
+
+
+
+Client-related commands will interact with the Client List which is located on the [left of the UI](#2-ui-orientation).
+
+
+
+
+
+ Figure 7 - Sample of Client List
+
+
+
+
+:information_source: **Note:**
+
+The Next Session field below each Client shows you the earliest upcoming session. It is not updated in real-time but after FitEgo executes a command.
+
+
+
+
-### Adding a person: `add`
+### 3.2.1 Listing all Clients : `clist`
-Adds a person to the address book.
+You can view the list of all clients in FitEgo. The list of clients will be shown at the Client List.
-Format: `add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…`
+By default, Client List will display all the clients. If you have used [`cfind`](#324-locating-clients-by-name--cfind) or any other commands to filter the Client List,
+you can use `clist` to view the entire list of clients.
+
+Format: `clist`
+
+### 3.2.2 Adding a Client : `cadd`
+
+You can add a client to the Client List including their details. This allows you to easily refer to their information when needed.
+
+Format: `cadd n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]`
+
+Points to take note when adding a client's information:
+* Email is unique for each client. This means you cannot add a new client if the email specified is already used by another client.
+* Each tag is at least 2 characters long and only include alphanumeric characters or hyphen (`-`). You are not allowed to start or end a tag with a hyphen.
:bulb: **Tip:**
-A person can have any number of tags (including 0)
+A client can have any number of tags (including 0). You can use this tag feature to document client's injury history or allergies.
-### Listing all persons : `list`
+:star: **Feature:**
-Shows a list of all persons in the address book.
+You can add a profile picture to your client by storing their photo in a new folder named `images` within the `data` folder. You should name the photo
+as `profile-.jpg`. For example, if your client's name is Alex Yeoh,
+store his photo as `data/images/profile-alex-yeoh.jpg`
+
-Format: `list`
+Examples:
+* `cadd n/Jane Doe p/91234567 e/jane@gmail.com a/311, Clementi Ave 2, #02-25` adds a client with the specified name, phone number, email and address.
-### Editing a person : `edit`
+* `cadd n/John Doe p/91231367 e/jojo@gmail.com a/311, Clementi Ave 2, #02-25 t/injured-thigh` adds a client with the specified name, phone number, email, address and tag.
-Edits an existing person in the address book.
+### 3.2.3 Editing a Client : `cedit`
-Format: `edit INDEX [n/NAME] [p/PHONE] [e/EMAIL] [a/ADDRESS] [t/TAG]…`
+If your client has any changes made to his details, then you can edit a client in the Client List. This helps you to reflect the latest information.
-* Edits the person at the specified `INDEX`. The index refers to the index number shown in the displayed person list. The index **must be a positive integer** 1, 2, 3, …
+Format: `cedit INDEX [n/NAME] [p/PHONE] [e/EMAIL] [a/ADDRESS] [t/TAG]`
+
+Points to take note when editing a client's information:
+* Edits the client at the specified `INDEX`. The index refers to the index number shown in the displayed Client List. The index **must be a positive integer** 1, 2, 3, …
* At least one of the optional fields must be provided.
+* You cannot have multiple clients with the same email. This means you will get an error message if the email you specified here is already used by another client.
* Existing values will be updated to the input values.
-* When editing tags, the existing tags of the person will be removed i.e adding of tags is not cumulative.
-* You can remove all the person’s tags by typing `t/` without
- specifying any tags after it.
+* When editing tags, the existing tags of the client will be removed, i.e. adding of tags is not cumulative.
+* You can remove all of the client’s tags by typing `t/` without specifying any tags after it.
+* After performing a `cedit` command, you will see the updated client information page.
Examples:
-* `edit 1 p/91234567 e/johndoe@example.com` Edits the phone number and email address of the 1st person to be `91234567` and `johndoe@example.com` respectively.
-* `edit 2 n/Betsy Crower t/` Edits the name of the 2nd person to be `Betsy Crower` and clears all existing tags.
-### Locating persons by name: `find`
+* `cedit 1 t/` removes all of the tags of the first client in the Client List
+* `cedit 2 p/12345678 t/injured-thigh` edits the phone number and tag of the second client in the Client List. As you can see in the figure below, both fields are updated after executing the command.
+
+
+
+
+
+ Figure 8 - Result of executing cedit 2 p/12345678 t/injured-thigh
+
+
+
+
+### 3.2.4 Locating Clients by Name : `cfind`
-Finds persons whose names contain any of the given keywords.
+You can find clients whose name contain any of the given keywords, and see the result in the Client List.
-Format: `find KEYWORD [MORE_KEYWORDS]`
+Format: `cfind KEYWORD [MORE_KEYWORDS]`
-* The search is case-insensitive. e.g `hans` will match `Hans`
-* The order of the keywords does not matter. e.g. `Hans Bo` will match `Bo Hans`
+Points to take note when finding clients by name:
+* The search is case-insensitive, e.g. `hans` will match `Hans`.
+* The order of the keywords does not matter, e.g. `Hans Bo` will match `Bo Hans`.
* Only the name is searched.
-* Only full words will be matched e.g. `Han` will not match `Hans`
-* Persons matching at least one keyword will be returned (i.e. `OR` search).
- e.g. `Hans Bo` will return `Hans Gruber`, `Bo Yang`
+* Partial names will be matched, e.g. `Han` will match `Hans`.
+* Clients matching any substring will be returned (i.e. `OR` search),
+ e.g. `Hans Bo` will return `Hans Gruber`, `Bo Yang`.
Examples:
-* `find John` returns `john` and `John Doe`
-* `find alex david` returns `Alex Yeoh`, `David Li`
- 
+* `cfind John` returns `john` and `John Doe`
+* `cfind alex david` returns `Alex Yeoh`, `David Li` as shown in the figure below
-### Deleting a person : `delete`
+
+
+
+
+ Figure 9 - Result of finding clients by name
+
-Deletes the specified person from the address book.
+
-Format: `delete INDEX`
+### 3.2.5 Deleting a Client : `cdel`
-* Deletes the person at the specified `INDEX`.
-* The index refers to the index number shown in the displayed person list.
+If you are no longer taking up a client, you can delete the client which can be found in the Client List. This helps in reducing obsolete information.
+
+Format: `cdel INDEX [f/]`
+
+Points to take note when deleting a client from the Client List:
+* Deletes the client at the specified `INDEX`.
+* The index refers to the index number shown in the displayed Client List.
* The index **must be a positive integer** 1, 2, 3, …
Examples:
-* `list` followed by `delete 2` deletes the 2nd person in the address book.
-* `find Betsy` followed by `delete 1` deletes the 1st person in the results of the `find` command.
+* `clist` followed by `cdel 2` deletes the second client in the resulting Client List
+* `cfind Bernice` followed by `cdel 1` deletes the first client with the name 'Bernice' in the resulting Client List
+ * If Bernice is not associated with any schedule, Bernice's client information is immediately deleted
+ * If Bernice is associated with one or more schedules, you will see a warning message about the conflict and how to force delete
+
+
+
+:star: **Feature:**
+
+- To force delete a client (and his associated schedules), pass in the optional force flag after the `INDEX`.
+Any string after the force flag (`f/`) will be ignored.
+
+- If you perform [`cdel`](#325-deleting-a-client--cdel), you will be returned to the homepage.
+
+
+* If there are one or more associated schedules associated with Bernice, `cfind Bernice` followed by `cdel 1 f/` will:
+ 1. Delete all schedules associated with Bernice
+ 2. Then, delete Bernice's client information.
+
+### 3.2.6 Viewing a Client : `cview`
+
+You can view the full details of a client from the Client List.
+
+You can easily look up the following information about the client in the Main Window:
+* Your client's name, email, address, phone, tags
+* Your client's weight history in line graph form
+* A list of schedules associated with your client, together with the interval, exercise type, payment status, and remark
+
+Format: `cview INDEX`
+
+Points to take note when viewing clients from the Client List:
+* Views the client at the specified `INDEX`. The selected client will be displayed in the Main Window.
+* The index refers to the index number shown in the displayed Client List.
+* The index **must be a positive integer** 1, 2, 3, ...
+* You can press "F3" key to view your client's list of schedules, and "F4" key to view your client's weight progression.
+* You can sort the list of schedules in the client's profile by the interval's start time, payment status or exercise type.
+
+Examples:
+* `cview 2` opens the second client in FitEgo
+* `cfind Bernice` followed by `cview 1` opens the first client (Bernice) in the resulting Client List
-### Clearing all entries : `clear`
+The result of these commands is shown in the figure below
-Clears all entries from the address book.
+
+
+
+
+ Figure 10 - Client View with Schedules
+
+---
+
-Format: `clear`
+## 3.3 Session-related Keywords
-### Exiting the program : `exit`
+We will describe all session-related keywords in this section. Before that, let's define what we mean by session.
-Exits the program.
+
-Format: `exit`
+:information_source: **Session:**
+
+A session represents a timeslot that is marked for a training session. It contains information about the gym, the main exercise type, the start time and the duration of sessions.
+
+Each session can be scheduled with multiple clients, to model a trainer instructing a group fitness class.
+
+
+
+Session-related commands will interact with the Session List which is located on the [right of the UI](#2-ui-orientation). The figure below shows how it looks like.
+
+
+
+
+
+ Figure 11 - Sample of Session List
+
+
+The `ALL` at the top of this Session List panel represents the current period of session view.
+
+
+
+:bulb: **Tip:**
+The default period of session view is 'WEEK'. You can change the period
+of session view using [sview](#334-viewing-sessions-within-period--sview) command.
+
+
+
+
+
+### 3.3.1 Adding a Session : `sadd`
+
+You can create a session with its relevant details. If the new session is within the [viewing period](#334-viewing-sessions-within-period--sview) of the Session List, the addition will be reflected in the Session List.
+This provides you with an easy reference to the periods in which you have session(s) scheduled and the location of each session.
+
+Format: `sadd g/GYM_NAME ex/EXERCISE_TYPE at/START_TIME t/DURATION`
+
+Points to take note when adding a session to the Session List:
+* Start time should be of format "dd/MM/yyyy HHmm" (date/month/year Hour minutes in 24 hr format).
+* Duration is in minutes.
+* Duration should be a positive integer.
+* If you want to schedule a session with a client, you need to make sure the session exists in FitEgo, then [create a schedule (`schadd`)](#341-adding-a-schedule--schadd) that references the client and the session.
+
+
+
+:information_source: **Info:**
+
+FitEgo will not allow you to create overlapping sessions. We consider two sessions as overlapping if another session starts before the current session ends.
+
+This helps to prevent you from accidentally agreeing to 2 sessions that overlaps with each other but are located on two different gyms.
+
+
+
+
+
+
+
+ Figure 12 - Result of executing sadd g/New Gym ex/Endurance at/06/11/2020 0900 t/65
+
+
+Examples:
+* `sadd g/New Gym ex/Endurance at/06/11/2020 0900 t/65` adds a session at gym `New Gym` with exercise type `Endurance` at `06/11/2020 0900hrs` that lasts for `65` minutes.
+The figure above shows the result of a successful execution of this command. You might need to set the viewing period to all (`sview p/all`) to see the new session show up in the right panel.
+
+
+
+### 3.3.2 Editing a Session : `sedit`
+
+You can edit the details of the session identified by the index number used in the displayed Session List. This ensures that you can always record the latest changes.
+
+Format: `sedit INDEX [g/GYM_NAME] [ex/EXERCISE_TYPE] [at/START_TIME t/DURATION]`
+
+Points to take note when editing a session's details from the Session List:
+* Edits the session at the specified `INDEX`. The index refers to the index number shown in the displayed Session List. The index **must be a positive integer** 1, 2, 3, …
+* `GYM_NAME` and `EXERCISE_TYPE` can be any words.
+* `START_TIME` and `DURATION` convention follows the command `sadd`.
+* At least one of the optional fields must be provided.
+* Existing values will be updated to the input values.
+
+Examples:
+* `sedit 1 g/Machoman at/29/09/2020 1600 t/120` edits the gym of the first session to be `Machoman` and the start time and duration to be `29/09/2020 1600 with a duration of 120 minutes` while keeping all other fields the same
+* `sedit 2 at/29/09/2020 1600 t/120` edits the start time and duration of the second session to be `29/09/2020 1600 with a duration of 120 minutes` while keeping all other fields the same
+
+
+
+
+
+ Figure 13 - Result of executing sedit 1 g/Machoman at/29/09/2020 1600 t/120
+
+
+
+
+### 3.3.3 Deleting a Session : `sdel`
+
+You can delete the session specified by the index number used in the displayed Session List and all schedules associated with
+the specified session. This helps you keep track of only sessions that are still relevant to you.
+
+Format: `sdel INDEX [f/]`
+
+Points to take note when deleting a session from the Session List:
+* Deletes the session at the specified `INDEX`.
+* The index refers to the index number shown in the displayed Session List.
+* The index **must be a positive integer** 1, 2, 3, ...
+
+Examples:
+* If there are no schedules associated with the second session in the Session List, `sview p/all` followed by `sdel 2` deletes the second session
+* If there are one or more associated schedules associated with the second session in the Session List, `sview p/all` followed by `sdel 2`, you will see an error message
+
+
+
+:star: **Feature:**
+
+To force deletion of session (and all associated schedules), pass in the optional force flag after the `INDEX`.
+ Any string after the force flag (`f/`) will be ignored.
+
+
+* If there are one or more schedules associated with the second session,
+ `list` followed by `sdel 2 f/` will delete all schedules associated with the second session, then delete the session itself
+
+
+
+### 3.3.4 Viewing Sessions within Period : `sview`
+You can filter the Session List to view sessions within requested period. This helps you to prioritise your sessions as needed.
+
+Format: `sview p/PERIOD`
+
+Points to take note when viewing session from the Session List:
+ * Filters the Session List to display sessions within the specified period.
+ * On top of the Session List, you can find the type of the period you are viewing.
+ * The recognized periods are as follows:
+
+
Table 3 - List of recognized periods
+
+ | Period | Sessions displayed |
+ | -------- | -------- |
+ | all| All sessions (including past ones)|
+ | future | All sessions that have not started|
+ | past | All sessions that have already ended|
+ | week | All sessions within the next 7 days (inclusive of today)|
+ | `+[x][unit]` | Sessions within next x time units where x is a non-negative integer|
+ | `-[x][unit]` | Sessions within past x time units where x is a non-negative integer|
+
+ * The recognized units are as follows:
+
Table 4 - List of recognized time units
+
+ | Unit | Time unit parsed |
+ | -------- | -------- |
+ | d / D | day |
+ | w / W | week |
+ | m / M | month |
+ | y / Y| year |
+
+
+
+
+
+ Figure 14 - Result of running sview p/+2w
+
+Examples:
+
+* `sview p/all` displays all sessions stored in FitEgo
+* `sview p/+0D` displays all sessions today
+* `sview p/-1d` displays all sessions from the past 1 day to today (yesterday and today)
+* `sview p/+2w` displays all sessions from today to 2 weeks later. (e.g. If today is Friday, display from today to the Friday that falls 2 weeks later)
+
+
+
+:information_source: **Note:**
+
+The effect of `sview` is not updated in real-time but after FitEgo executes a command. For example, if you
+1. run sview p/+0D at 2359hrs on Friday
+2. do not execute any command until 0000 hrs on Saturday
+
+the Session List will still be showing Friday's sessions at that point of time. To update, simply run any command successfully in FitEgo.
+
+
+---
+
+
+## 3.4 Schedule-related Keywords
+
+In this section, we will describe all schedule-related keywords. Before that, let's define what we mean by schedule.
+
+
+
+:information_source: **Schedule:**
+
+A schedule records the interaction between you and your client within a session.
+Each schedule contains information about the client and the attended session.
+
+Listed below are three other types of information that you can add into a schedule:
+1. your client's weight if you have recorded your client's weight during a session
+1. exercises done by your client during the session as remark
+1. your client's payment status on whether your client has or has not paid for the session
+
+
+
+
+The table below shows an example of schedules. The session at Machoman Gym is attended by 2 clients. For each client, we can take note of their weight, activities, and payment status.
+
+
Table 5 - Example of Schedule Tracking
+
+| Client | Session | Weight | Remark | Payment Status |
+| -------- | ------------------------------------------------------------ | ------ | ------------------------------------------------------------ | -------------- |
+| John Doe | Endurance training at Machoman Gym (24/10/2020 1200 - 1400) | 70 kg | Planks (20 x 30 seconds), body weight squats (5 sets of 25 reps) | paid |
+| Alex | Endurance training at Machoman Gym (24/10/2020 1200 - 1400) | 60 kg | Planks (10 x 30 seconds) | unpaid |
+| Bernice | Body building training at Getwell Gym (27/10/2020 1300 - 1500) | 85 kg | Chinup (5 sets of 5 reps), muscle strain after bench press | paid |
+
+To check if you have scheduled a session with a client, you can check if the session in the Session List contains the client's name.
+
+
+
+
+
+ Figure 15 - Alternate sample of Session List
+
+
+The figure above shows the Session List, in which for each session, there is a list of clients attending the session. Clients who have paid for a session will have their name shown in green, while those who have not will have their name shown in red.
+
+### 3.4.1 Adding a Schedule : `schadd`
+
+You can schedule your client for a session. You can use this command to indicate that a client will attend one of your session.
+
+Format: `schadd c/CLIENT_INDEX s/SESSION_INDEX`
+
+Points to take note when adding a schedule:
+* This will create a schedule associated with the specified client and session.
+* The client is specified by `CLIENT_INDEX`, and the session is specified by `SESSION_INDEX`.
+* `CLIENT_INDEX` refers to the index number shown in the Client List, and **must be a positive integer** 1, 2, 3, …
+* `SESSION_INDEX` refers to the index number shown in the Session List, and **must be a positive integer** 1, 2, 3, …
+
+Example:
+
+* `schadd c/1 s/1` schedules the first client in the Client List with the first session in the Session List. As you can see in the figure below, Alex Yeoh (the first client, marked by the red square) is added to the first session in the list (marked by the blue square).
+
+
+
+
+
+ Figure 16 - Result of executing schadd c/1 s/1
+
-### Saving the data
+### 3.4.2 Editing a Schedule : `schedit`
-AddressBook data are saved in the hard disk automatically after any command that changes the data. There is no need to save manually.
+If you want to change your client's session, payment status or remarks, you can edit the details of this schedule identified by the client index and session index.
-### Archiving data files `[coming in v2.0]`
+Format: `schedit c/CLIENT_INDEX s/SESSION_INDEX [us/UPDATED_SESSION_INDEX] [pd/PAYMENT_STATUS] [r/REMARK] [w/WEIGHT]`
-_{explain the feature here}_
+Points to take note when editing a schedule's details:
+* Edits the schedule that consists of the client and session indicated by `CLIENT_INDEX` and `SESSION_INDEX`.
+* `CLIENT_INDEX` refers to the index number shown in the Client List. The index **must be a positive integer** 1, 2, 3, …
+* `SESSION_INDEX` and `UPDATED_SESSION_INDEX` refers to the index number shown in the Session List. The index **must be a positive integer** 1, 2, 3, …
+* `PAYMENT_STATUS` can either be `paid` or `unpaid`.
+* `REMARK` can be any words, phrases or sentences.
+* `WEIGHT` must be **positive numbers** and **less than 1000kg**. By default, units will be set to kilogram. You can also add either `kg` or `lb` to the back to specify the units. It will be displayed in 1 decimal place, but stored accurately.
+* At least one of the optional fields must be provided.
+* Existing values will be updated to the input values.
+
+Examples:
+
+* `schedit c/1 s/1 us/2` reschedules the first session in the Session List to the second session in the Session List while keeping all other fields the same
+* `schedit c/1 s/1 pd/paid` indicates that the first client in the Client List has paid for the first session in the Session List while keeping all other fields the same
+* `schedit c/1 s/1 r/did 5 pushups` edits the schedule containing client index 1 and session index 1 to have remark of doing 5 pushups while keeping all other fields the same
+* `schedit c/1 s/1 w/70` edits the schedule containing client index 1 and session index 1 to a weight of 70kg while keeping all other fields the same
+* `schedit c/1 s/1 r/` clears the schedule containing client index 1 and session index 1 remarks while keeping all other fields the same
+
+
+
+
+
+ Figure 17 - Result of executing schedit c/1 s/2 us/1
+
+
+### 3.4.3 Deleting a Schedule : `schdel`
+
+You can delete a schedule associated with a client and session. You might want to use this command when a client decided to cancel attending a particular session.
+
+Format: `schdel c/CLIENT_INDEX s/SESSION_INDEX`
+
+Some points to take note when deleting a schedule:
+* This will delete the schedule associated with the specified client and session.
+* The client is identified by `CLIENT_INDEX`, and the Session is identified by `SCHEDULE_INDEX`.
+* `CLIENT_INDEX` refers to the index number shown in the Client List. The index **must be a positive integer** 1, 2, 3, …
+* `SESSION_INDEX` refers to the index number shown in the Session List. The index **must be a positive integer** 1, 2, 3, …
+
+Examples:
+
+* `schdel c/1 s/1` deletes the schedule associated with the first client in the Client List and first session in the Session List
--------------------------------------------------------------------------------------------------------------------
+
+
+# 4 FAQ
+
+**Q**: How do I transfer my data to another Computer?
+**A**: Install the app in the other computer and overwrite the empty `data` folder it creates with your previous FitEgo `data` folder.
-## FAQ
+**Q**: I have encountered difficulties with FitEgo. May I know who do I reach out to for assistance?
+**A**: To get in touch with us, you may post an issue [here](https://github.com/AY2021S1-CS2103T-T13-3/tp/issues/new), and we will get back to you as soon as possible.
-**Q**: How do I transfer my data to another Computer?
-**A**: Install the app in the other computer and overwrite the empty data file it creates with the file that contains the data of your previous AddressBook home folder.
+**Q**: Am I able to mark multiple schedules as paid or unpaid with one command?
+**A**: Currently, you are only able to mark only one schedule as paid or unpaid per command. This is a feature we are aiming to implement in the future.
+
+**Q**: Is my data backed up to the internet?
+**A**: No, your data in FitEgo are saved in the hard disk. You will have to transfer the `data` folder, to whichever device you wish to continue using FitEgo on.
--------------------------------------------------------------------------------------------------------------------
-## Command summary
-
-Action | Format, Examples
---------|------------------
-**Add** | `add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…` e.g., `add n/James Ho p/22224444 e/jamesho@example.com a/123, Clementi Rd, 1234665 t/friend t/colleague`
-**Clear** | `clear`
-**Delete** | `delete INDEX` e.g., `delete 3`
-**Edit** | `edit INDEX [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [a/ADDRESS] [t/TAG]…` e.g.,`edit 2 n/James Lee e/jameslee@example.com`
-**Find** | `find KEYWORD [MORE_KEYWORDS]` e.g., `find James Jake`
-**List** | `list`
-**Help** | `help`
+# 5 Command Summary
+
+You can find the comprehensive list of commands in the table below.
+
+
Table 6 - General Commands Summary
+
+| Action | Format |
+| ---------| -------- |
+| Open Home Page | `home` |
+| Open Help Window | `help` |
+| Open Settings Window | `settings` |
+| Clear all data | `clear` |
+| Exit this program | `exit` |
+
+
+
+
Table 7 - Keyword based Commands Summary (grouped by action)
diff --git a/docs/_config.yml b/docs/_config.yml
index 6bd245d8f4e..6c775f3c212 100644
--- a/docs/_config.yml
+++ b/docs/_config.yml
@@ -1,4 +1,4 @@
-title: "AB-3"
+title: "FitEgo"
theme: minima
header_pages:
@@ -8,8 +8,9 @@ header_pages:
markdown: kramdown
-repository: "se-edu/addressbook-level3"
+repository: "AY2021S1-CS2103T-T13-3/tp"
github_icon: "images/github-icon.png"
plugins:
- jemoji
+ - jekyll-seo-tag
diff --git a/docs/_includes/head.html b/docs/_includes/head.html
index 83ac5326933..8ca74a5004b 100644
--- a/docs/_includes/head.html
+++ b/docs/_includes/head.html
@@ -4,6 +4,7 @@
+
{%- include custom-head.html -%}
diff --git a/docs/diagrams/AddScheduleActivityDiagram.puml b/docs/diagrams/AddScheduleActivityDiagram.puml
new file mode 100644
index 00000000000..fdac9cadae8
--- /dev/null
+++ b/docs/diagrams/AddScheduleActivityDiagram.puml
@@ -0,0 +1,19 @@
+@startuml
+start
+:User executes Add Schedule command;
+:Parse input from user;
+:Get the specified Client and Session;
+:Check if a Schedule associated with the Client and Session already exists;
+
+' Since the beta syntax does not support placing the condition outside the
+' diamond we place it as the true branch instead.
+
+if () then ([Existing Schedule is found])
+ :Show error message to user;
+ stop
+else([else])
+endif
+:Add Schedule;
+:Show feedback message to user;
+stop
+@enduml
diff --git a/docs/diagrams/ArchitectureSequenceDiagram.puml b/docs/diagrams/ArchitectureSequenceDiagram.puml
index ef81d18c337..8a195134fc7 100644
--- a/docs/diagrams/ArchitectureSequenceDiagram.puml
+++ b/docs/diagrams/ArchitectureSequenceDiagram.puml
@@ -7,13 +7,13 @@ Participant ":Logic" as logic LOGIC_COLOR
Participant ":Model" as model MODEL_COLOR
Participant ":Storage" as storage STORAGE_COLOR
-user -[USER_COLOR]> ui : "delete 1"
+user -[USER_COLOR]> ui : "cdel 1"
activate ui UI_COLOR
-ui -[UI_COLOR]> logic : execute("delete 1")
+ui -[UI_COLOR]> logic : execute("cdel 1")
activate logic LOGIC_COLOR
-logic -[LOGIC_COLOR]> model : deletePerson(p)
+logic -[LOGIC_COLOR]> model : deleteClient(p)
activate model MODEL_COLOR
model -[MODEL_COLOR]-> logic
diff --git a/docs/diagrams/BetterModelClassDiagram.puml b/docs/diagrams/BetterModelClassDiagram.puml
index 29076104af3..03de1e4d1ca 100644
--- a/docs/diagrams/BetterModelClassDiagram.puml
+++ b/docs/diagrams/BetterModelClassDiagram.puml
@@ -4,18 +4,18 @@ skinparam arrowThickness 1.1
skinparam arrowColor MODEL_COLOR
skinparam classBackgroundColor MODEL_COLOR
-AddressBook *-right-> "1" UniquePersonList
+AddressBook *-right-> "1" UniqueClientList
AddressBook *-right-> "1" UniqueTagList
-UniqueTagList -[hidden]down- UniquePersonList
-UniqueTagList -[hidden]down- UniquePersonList
+UniqueTagList -[hidden]down- UniqueClientList
+UniqueTagList -[hidden]down- UniqueClientList
UniqueTagList *-right-> "*" Tag
-UniquePersonList o-right-> Person
+UniqueClientList o-right-> Client
-Person -up-> "*" Tag
+Client -up-> "*" Tag
-Person *--> Name
-Person *--> Phone
-Person *--> Email
-Person *--> Address
+Client *--> Name
+Client *--> Phone
+Client *--> Email
+Client *--> Address
@enduml
diff --git a/docs/diagrams/ClientViewWeightSequenceDiagram.puml b/docs/diagrams/ClientViewWeightSequenceDiagram.puml
new file mode 100644
index 00000000000..d495cb487ab
--- /dev/null
+++ b/docs/diagrams/ClientViewWeightSequenceDiagram.puml
@@ -0,0 +1,74 @@
+@startuml
+!include style.puml
+
+Actor User as user USER_COLOR
+box Ui UI_COLOR_T1
+participant ":MainWindow" as MainWindow UI_COLOR
+participant "cip:ClientInfoPage" as ClientInfoPage UI_COLOR
+participant "chart:LineChart" as LineChart UI_COLOR
+participant ":TabPane" as TabPane UI_COLOR
+end box
+
+box Logic LOGIC_COLOR_T1
+participant ":Logic" as Logic LOGIC_COLOR
+end box
+
+Participant ":Supplier" as Supplier MODEL_COLOR
+
+user -> MainWindow : executeCommand("cview 1")
+activate MainWindow
+
+MainWindow -> Logic : execute("cview 1")
+activate Logic
+
+Logic --> MainWindow : result
+
+note right
+Logic returns a CommandResult
+with a Supplier to get the
+associated client and schedule list.
+end note
+
+deactivate Logic
+
+MainWindow -> Supplier : result.get()
+activate Supplier
+
+create ClientInfoPage
+Supplier -> ClientInfoPage : ClientInfoPage(client, scheduleList)
+activate ClientInfoPage
+
+ClientInfoPage -> ClientInfoPage : initialiseProfile(client)
+ClientInfoPage -> ClientInfoPage : initialiseSchedule(scheduleList)
+ClientInfoPage -> ClientInfoPage : initialiseChart(client, scheduleList)
+activate ClientInfoPage
+
+alt scheduleList.size() > 0
+ ClientInfoPage -> LineChart : addAll(scheduleList)
+ activate LineChart
+
+ LineChart --> ClientInfoPage : chart
+ deactivate LineChart
+
+ ClientInfoPage -> TabPane : getTabs().add(chart)
+
+else else
+ ClientInfoPage -> TabPane : getTabs().remove(chart)
+
+end alt
+
+ClientInfoPage --> ClientInfoPage
+deactivate ClientInfoPage
+
+ClientInfoPage --> Supplier
+deactivate ClientInfoPage
+
+Supplier --> MainWindow
+deactivate Supplier
+
+MainWindow -> MainWindow : setMainDisplay(cip)
+
+MainWindow --> user
+deactivate MainWindow
+
+@enduml
diff --git a/docs/diagrams/DeleteClientSequenceDiagram.puml b/docs/diagrams/DeleteClientSequenceDiagram.puml
new file mode 100644
index 00000000000..53a1b17138c
--- /dev/null
+++ b/docs/diagrams/DeleteClientSequenceDiagram.puml
@@ -0,0 +1,96 @@
+@startuml
+!include style.puml
+
+box Logic LOGIC_COLOR_T1
+participant ":LogicManager" as LogicManager LOGIC_COLOR
+participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
+participant ":DeleteClientCommandParser" as DeleteClientCommandParser LOGIC_COLOR
+participant "d:DeleteClientCommand" as DeleteClientCommand 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("cdel 1")
+activate LogicManager
+
+LogicManager -> AddressBookParser : parseCommand("cdel 1")
+activate AddressBookParser
+
+create DeleteClientCommandParser
+AddressBookParser -> DeleteClientCommandParser
+activate DeleteClientCommandParser
+
+DeleteClientCommandParser --> AddressBookParser
+deactivate DeleteClientCommandParser
+
+AddressBookParser -> DeleteClientCommandParser : parse("1")
+activate DeleteClientCommandParser
+
+create DeleteClientCommand
+DeleteClientCommandParser -> DeleteClientCommand
+activate DeleteClientCommand
+
+DeleteClientCommand --> DeleteClientCommandParser : d
+deactivate DeleteClientCommand
+
+DeleteClientCommandParser --> AddressBookParser : d
+deactivate DeleteClientCommandParser
+'Hidden arrow to position the destroy marker below the end of the activation bar.
+DeleteClientCommandParser -[hidden]-> AddressBookParser
+destroy DeleteClientCommandParser
+
+AddressBookParser --> LogicManager : d
+deactivate AddressBookParser
+
+LogicManager -> DeleteClientCommand : execute()
+activate DeleteClientCommand
+
+DeleteClientCommand -> Model : hasAnyScheduleAssociatedWithClient(1)
+activate Model
+
+Model --> DeleteClientCommand
+deactivate Model
+
+alt hasAssociatedSchedule and isNotForceDelete
+
+ create CommandResult
+ DeleteClientCommand -> CommandResult
+ activate CommandResult
+
+ CommandResult --> DeleteClientCommand
+ deactivate CommandResult
+
+else else
+ DeleteClientCommand -> Model : deleteClientAssociatedSchedules(1)
+ activate Model
+
+ Model --> DeleteClientCommand
+ deactivate Model
+
+ DeleteClientCommand -> Model : deleteClient(1)
+ activate Model
+
+ Model --> DeleteClientCommand
+ deactivate Model
+
+ create CommandResult
+ DeleteClientCommand -> CommandResult
+ activate CommandResult
+
+ CommandResult --> DeleteClientCommand
+ deactivate CommandResult
+
+ end
+
+DeleteClientCommand --> LogicManager : result
+deactivate DeleteClientCommand
+DeleteClientCommandParser -[hidden]-> AddressBookParser
+destroy DeleteClientCommand
+
+[<--LogicManager
+deactivate LogicManager
+@enduml
+
diff --git a/docs/diagrams/DeleteSequenceDiagram.puml b/docs/diagrams/DeleteSequenceDiagram.puml
deleted file mode 100644
index 1dc2311b245..00000000000
--- a/docs/diagrams/DeleteSequenceDiagram.puml
+++ /dev/null
@@ -1,69 +0,0 @@
-@startuml
-!include style.puml
-
-box Logic LOGIC_COLOR_T1
-participant ":LogicManager" as LogicManager LOGIC_COLOR
-participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
-participant ":DeleteCommandParser" as DeleteCommandParser LOGIC_COLOR
-participant "d:DeleteCommand" as DeleteCommand 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("delete 1")
-activate LogicManager
-
-LogicManager -> AddressBookParser : parseCommand("delete 1")
-activate AddressBookParser
-
-create DeleteCommandParser
-AddressBookParser -> DeleteCommandParser
-activate DeleteCommandParser
-
-DeleteCommandParser --> AddressBookParser
-deactivate DeleteCommandParser
-
-AddressBookParser -> DeleteCommandParser : parse("1")
-activate DeleteCommandParser
-
-create DeleteCommand
-DeleteCommandParser -> DeleteCommand
-activate DeleteCommand
-
-DeleteCommand --> DeleteCommandParser : d
-deactivate DeleteCommand
-
-DeleteCommandParser --> AddressBookParser : d
-deactivate DeleteCommandParser
-'Hidden arrow to position the destroy marker below the end of the activation bar.
-DeleteCommandParser -[hidden]-> AddressBookParser
-destroy DeleteCommandParser
-
-AddressBookParser --> LogicManager : d
-deactivate AddressBookParser
-
-LogicManager -> DeleteCommand : execute()
-activate DeleteCommand
-
-DeleteCommand -> Model : deletePerson(1)
-activate Model
-
-Model --> DeleteCommand
-deactivate Model
-
-create CommandResult
-DeleteCommand -> CommandResult
-activate CommandResult
-
-CommandResult --> DeleteCommand
-deactivate CommandResult
-
-DeleteCommand --> LogicManager : result
-deactivate DeleteCommand
-
-[<--LogicManager
-deactivate LogicManager
-@enduml
diff --git a/docs/diagrams/DeleteSessionActivityDiagram.puml b/docs/diagrams/DeleteSessionActivityDiagram.puml
new file mode 100644
index 00000000000..29c535e9dcf
--- /dev/null
+++ b/docs/diagrams/DeleteSessionActivityDiagram.puml
@@ -0,0 +1,22 @@
+@startuml
+start
+:User executes DeleteSessionCommand;
+:Parse input from user;
+:Check for associated Schedules;
+
+' Since the beta syntax does not support placing the condition outside the
+' diamond we place it as the true branch instead.
+
+if () then ([No associated Schedules found])
+else([else])
+ if () then ([Force flag passed])
+ :Delete Associated Schedules;
+ else ([else])
+ :Show error message to user;
+ stop
+ endif
+endif
+:Delete Session;
+:Show feedback message to user;
+stop
+@enduml
diff --git a/docs/diagrams/EditScheduleActivityDiagram.puml b/docs/diagrams/EditScheduleActivityDiagram.puml
new file mode 100644
index 00000000000..66dcdcf94db
--- /dev/null
+++ b/docs/diagrams/EditScheduleActivityDiagram.puml
@@ -0,0 +1,22 @@
+@startuml
+start
+:Edit Schedule Command;
+
+if () then ([isUpdatingSessionIndex])
+ :Update Session Index;
+ else ([else])
+ endif
+
+ if () then ([isUpdatingPayment])
+ :Update Payment Status;
+ else ([else])
+ endif
+
+ if () then ([isUpdatingRemark])
+ :Update Remark;
+ else ([else])
+
+ endif
+ :Print Successful;
+stop
+@enduml
diff --git a/docs/diagrams/EditScheduleSequenceDiagram.puml b/docs/diagrams/EditScheduleSequenceDiagram.puml
new file mode 100644
index 00000000000..7d502594336
--- /dev/null
+++ b/docs/diagrams/EditScheduleSequenceDiagram.puml
@@ -0,0 +1,69 @@
+@startuml
+!include style.puml
+
+box Logic LOGIC_COLOR_T1
+participant ":LogicManager" as LogicManager LOGIC_COLOR
+participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
+participant ":EditScheduleCommandParser" as EditScheduleCommandParser LOGIC_COLOR
+participant "editedSchedule:EditScheduleCommand" as EditScheduleCommand 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("schedit c/1 s/1 us/2")
+activate LogicManager
+
+LogicManager -> AddressBookParser : parseCommand("schedit c/1 s/1 us/2")
+activate AddressBookParser
+
+create EditScheduleCommandParser
+AddressBookParser -> EditScheduleCommandParser
+activate EditScheduleCommandParser
+
+EditScheduleCommandParser --> AddressBookParser
+deactivate EditScheduleCommandParser
+
+AddressBookParser -> EditScheduleCommandParser : parse("c/1 s/1 us/2")
+activate EditScheduleCommandParser
+
+create EditScheduleCommand
+EditScheduleCommandParser -> EditScheduleCommand
+activate EditScheduleCommand
+
+EditScheduleCommand --> EditScheduleCommandParser : target, editedSchedule
+deactivate EditScheduleCommand
+
+EditScheduleCommandParser --> AddressBookParser : target, editedSchedule
+deactivate EditScheduleCommandParser
+'Hidden arrow to position the destroy marker below the end of the activation bar.
+EditScheduleCommandParser -[hidden]-> AddressBookParser
+destroy EditScheduleCommandParser
+
+AddressBookParser --> LogicManager : target, editedSchedule
+deactivate AddressBookParser
+
+LogicManager -> EditScheduleCommand : execute()
+activate EditScheduleCommand
+
+EditScheduleCommand -> Model : setSchedule(target, editedSchedule)
+activate Model
+
+Model --> EditScheduleCommand
+deactivate Model
+
+create CommandResult
+EditScheduleCommand -> CommandResult
+activate CommandResult
+
+CommandResult --> EditScheduleCommand
+deactivate CommandResult
+
+EditScheduleCommand --> LogicManager : result
+deactivate EditScheduleCommand
+
+[<--LogicManager
+deactivate LogicManager
+@enduml
diff --git a/docs/diagrams/EditSessionActivityDiagram.puml b/docs/diagrams/EditSessionActivityDiagram.puml
new file mode 100644
index 00000000000..85bebc12491
--- /dev/null
+++ b/docs/diagrams/EditSessionActivityDiagram.puml
@@ -0,0 +1,17 @@
+@startuml
+start
+:Edit Session Command;
+
+if () then ([isUpdatingGym])
+ :Update Gym;
+ else ([else])
+ endif
+
+ if () then ([isUpdatingStartTime])
+ :Update Start Time;
+ :Duration;
+ else ([else])
+ endif
+ :Print Successful;
+stop
+@enduml
diff --git a/docs/diagrams/EditSessionSequenceDiagram.puml b/docs/diagrams/EditSessionSequenceDiagram.puml
new file mode 100644
index 00000000000..c3251b8587f
--- /dev/null
+++ b/docs/diagrams/EditSessionSequenceDiagram.puml
@@ -0,0 +1,61 @@
+@startuml
+!include style.puml
+
+box Logic LOGIC_COLOR_T1
+participant ":LogicManager" as LogicManager LOGIC_COLOR
+participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
+participant ":EditSessionCommandParser" as EditSessionCommandParser LOGIC_COLOR
+participant "editedSession:EditSessionCommand" as EditSessionCommand LOGIC_COLOR
+participant ":CommandResult" as CommandResult LOGIC_COLOR
+end box
+
+[-> LogicManager : execute("sedit 1 g/coolgym")
+activate LogicManager
+
+LogicManager -> AddressBookParser : parseCommand("sedit 1 g/coolgym")
+activate AddressBookParser
+
+create EditSessionCommandParser
+AddressBookParser -> EditSessionCommandParser
+activate EditSessionCommandParser
+
+EditSessionCommandParser --> AddressBookParser
+deactivate EditSessionCommandParser
+
+AddressBookParser -> EditSessionCommandParser : parse("1 g/coolgym")
+activate EditSessionCommandParser
+
+create EditSessionCommand
+EditSessionCommandParser -> EditSessionCommand
+activate EditSessionCommand
+
+EditSessionCommand --> EditSessionCommandParser : target, editedSession
+deactivate EditSessionCommand
+
+EditSessionCommandParser --> AddressBookParser : target, editedSession
+deactivate EditSessionCommandParser
+'Hidden arrow to position the destroy marker below the end of the activation bar.
+EditSessionCommandParser -[hidden]-> AddressBookParser
+destroy EditSessionCommandParser
+
+AddressBookParser --> LogicManager : target, editedSession
+deactivate AddressBookParser
+
+LogicManager -> EditSessionCommand : execute(model)
+activate EditSessionCommand
+
+create CommandResult
+EditSessionCommand -> CommandResult : CommandResult(String)
+activate CommandResult
+
+CommandResult --> EditSessionCommand
+deactivate CommandResult
+
+EditSessionCommand --> LogicManager : result
+deactivate EditSessionCommand
+EditSessionCommandParser -[hidden]-> AddressBookParser
+destroy EditSessionCommand
+
+[<--LogicManager
+deactivate LogicManager
+@enduml
diff --git a/docs/diagrams/LogicClassDiagram.puml b/docs/diagrams/LogicClassDiagram.puml
index 016ef33e2e2..b3162299808 100644
--- a/docs/diagrams/LogicClassDiagram.puml
+++ b/docs/diagrams/LogicClassDiagram.puml
@@ -53,7 +53,7 @@ LogicManager .left.> Command : executes >
LogicManager --> Model
Command .right.> Model
-note right of XYZCommand: XYZCommand = AddCommand, \nFindCommand, etc
+note right of XYZCommand: XYZCommand = AddClientCommand, \nFindClientCommand, etc
Logic ..> CommandResult
LogicManager .down.> CommandResult
diff --git a/docs/diagrams/ModelClassDiagram.puml b/docs/diagrams/ModelClassDiagram.puml
index e85a00d4107..718ba633a5d 100644
--- a/docs/diagrams/ModelClassDiagram.puml
+++ b/docs/diagrams/ModelClassDiagram.puml
@@ -1,32 +1,46 @@
@startuml
!include style.puml
+
skinparam arrowThickness 1.1
skinparam arrowColor MODEL_COLOR
skinparam classBackgroundColor MODEL_COLOR
+skinparam Class {
+ FontColor #FFFFFF
+ BorderThickness 1
+ BorderColor #FFFFFF
+ StereotypeFontColor #5F0000
+ FontName Arial
+}
Package Model <>{
Interface ReadOnlyAddressBook <>
Interface Model <>
Interface ObservableList <>
+Interface CheckExisting <>
+Interface ReadOnlyUserPrefs <>
+
Class AddressBook
Class ReadOnlyAddressBook
Class Model
Class ModelManager
Class UserPrefs
-Class ReadOnlyUserPrefs
-
-Package Person {
-Class Person
-Class Address
-Class Email
-Class Name
-Class Phone
-Class UniquePersonList
+
+Class "UniqueList" as UniqueList_client
+Class "UniqueList" as UniqueList_session
+Class "UniqueList" as UniqueList_schedule
+
+Package Client {
+class Client
+}
+
+Package Session {
+Class Session
}
-Package Tag {
-Class Tag
+Package Schedule {
+Class Schedule
}
+
}
Class HiddenOutside #FFFFFF
@@ -36,21 +50,31 @@ AddressBook .up.|> ReadOnlyAddressBook
ModelManager .up.|> Model
Model .right.> ObservableList
-ModelManager o--> "1" AddressBook
-ModelManager o-left-> "1" UserPrefs
+Model .left.> ReadOnlyUserPrefs
+ModelManager -right--> "1" AddressBook
+ModelManager --left-> "1" UserPrefs
UserPrefs .up.|> ReadOnlyUserPrefs
-AddressBook *--> "1" UniquePersonList
-UniquePersonList o--> "*" Person
-Person *--> Name
-Person *--> Phone
-Person *--> Email
-Person *--> Address
-Person *--> "*" Tag
+ObservableList -[hidden]right-> ReadOnlyAddressBook
+
+AddressBook *--> "1" UniqueList_client
+UniqueList_client ---> "*" Client
+
+UniqueList_client -[hidden]right-> UniqueList_schedule
+
+AddressBook *--> "1" UniqueList_session
+UniqueList_session ---> "*" Session
+
+UniqueList_schedule -[hidden]right-> UniqueList_session
+
+AddressBook *--> "1" UniqueList_schedule
+UniqueList_schedule ---> "*" Schedule
+
+Client ..|> CheckExisting
+Schedule ..|> CheckExisting
+Session ..|> CheckExisting
-Name -[hidden]right-> Phone
-Phone -[hidden]right-> Address
-Address -[hidden]right-> Email
+Schedule -left-> "1" Client
+Schedule -right-> "1" Session
-ModelManager -->"1" Person : filtered list
@enduml
diff --git a/docs/diagrams/ModelClassDiagram2.puml b/docs/diagrams/ModelClassDiagram2.puml
new file mode 100644
index 00000000000..8b5f1a91766
--- /dev/null
+++ b/docs/diagrams/ModelClassDiagram2.puml
@@ -0,0 +1,68 @@
+@startuml
+!include style.puml
+
+skinparam arrowThickness 1.1
+skinparam arrowColor MODEL_COLOR
+skinparam classBackgroundColor MODEL_COLOR
+skinparam Class {
+ FontColor #FFFFFF
+ BorderThickness 1
+ BorderColor #FFFFFF
+ StereotypeFontColor #5F0000
+ FontName Arial
+}
+
+Package Client {
+class Client
+Class Address
+Class Email
+Class Name
+Class Phone
+}
+
+Package Session {
+Class Session
+Class Gym
+Class ExerciseType
+Class Interval
+}
+
+Package Schedule {
+Class Schedule
+Class Remark
+Class Weight
+Class PaymentStatus
+}
+
+Package Tag {
+Class Tag
+}
+
+Client *--> "*" Tag
+Client *--> Name
+Client *--> Phone
+Client *--> Email
+Client *--> Address
+
+Name -[hidden]right-> Phone
+Phone -[hidden]right-> Address
+Address -[hidden]right-> Email
+
+Schedule *--> Remark
+Schedule *--> Weight
+Schedule *--> PaymentStatus
+
+Remark -[hidden]right-> Weight
+Weight -[hidden]right-> PaymentStatus
+
+Schedule -left-> "1" Client
+Schedule -right-> "1" Session
+
+Session *--> Gym
+Session *--> ExerciseType
+Session *--> Interval
+
+Gym -[hidden]right-> ExerciseType
+ExerciseType -[hidden]right-> Interval
+
+@enduml
diff --git a/docs/diagrams/StorageClassDiagram.puml b/docs/diagrams/StorageClassDiagram.puml
index 6adb2e156bf..7552a317684 100644
--- a/docs/diagrams/StorageClassDiagram.puml
+++ b/docs/diagrams/StorageClassDiagram.puml
@@ -13,12 +13,18 @@ Class JsonUserPrefsStorage
Class JsonAddressBookStorage
StorageManager .left.|> Storage
-StorageManager o-right-> UserPrefsStorage
-StorageManager o--> AddressBookStorage
+StorageManager --right-> UserPrefsStorage
+StorageManager --> AddressBookStorage
JsonUserPrefsStorage .left.|> UserPrefsStorage
JsonAddressBookStorage .left.|> AddressBookStorage
-JsonAddressBookStorage .down.> JsonSerializableAddressBookStorage
-JsonSerializableAddressBookStorage .right.> JsonSerializablePerson
-JsonSerializablePerson .right.> JsonAdaptedTag
+JsonAddressBookStorage .down.> JsonSerializableAddressBook
+
+JsonSerializableAddressBook *-down-> JsonAdaptedClient
+JsonAdaptedClient *-down-> JsonAdaptedTag
+
+JsonSerializableAddressBook *-down-> JsonAdaptedSession
+
+JsonSerializableAddressBook *-down-> JsonAdaptedSchedule
+
@enduml
diff --git a/docs/diagrams/UiClassDiagram.puml b/docs/diagrams/UiClassDiagram.puml
index 92746f9fcf7..0e7a13e03a8 100644
--- a/docs/diagrams/UiClassDiagram.puml
+++ b/docs/diagrams/UiClassDiagram.puml
@@ -9,12 +9,17 @@ Interface Ui <>
Class "{abstract}\nUiPart" as UiPart
Class UiManager
Class MainWindow
+Class SettingsWindow
Class HelpWindow
Class ResultDisplay
-Class PersonListPanel
-Class PersonCard
+Class ClientListPanel
+Class ClientCard
Class StatusBarFooter
Class CommandBox
+Class Homepage
+class RightSideBar
+class SessionCard
+class ClientInfoPage
}
package Model <> {
@@ -28,33 +33,47 @@ Class HiddenLogic #FFFFFF
Class HiddenOutside #FFFFFF
HiddenOutside ..> Ui
+ClientCard .left.> Model
+SessionCard .left.> Model
+ClientInfoPage -left-> Model
+Homepage -left-> Model
+UiManager --> Logic
+MainWindow --> Logic
+ClientListPanel --> Logic
+RightSideBar --> Logic
+SettingsWindow --> Logic
+
UiManager .left.|> Ui
UiManager -down-> MainWindow
MainWindow --> HelpWindow
-MainWindow *-down-> CommandBox
+MainWindow --> SettingsWindow
+MainWindow <-down-> CommandBox
MainWindow *-down-> ResultDisplay
-MainWindow *-down-> PersonListPanel
+MainWindow <-down-> ClientListPanel
MainWindow *-down-> StatusBarFooter
+MainWindow *-down-> Homepage
+MainWindow <---> RightSideBar
+MainWindow ..> ClientInfoPage
-PersonListPanel -down-> PersonCard
+ClientListPanel -down-> ClientCard
+RightSideBar ---> SessionCard
-MainWindow -left-|> UiPart
+MainWindow -up-|> UiPart
ResultDisplay --|> UiPart
CommandBox --|> UiPart
-PersonListPanel --|> UiPart
-PersonCard --|> UiPart
+ClientListPanel --|> UiPart
+ClientCard --|> UiPart
StatusBarFooter --|> UiPart
+SettingsWindow --|> UiPart
HelpWindow -down-|> UiPart
+Homepage --|> UiPart
+RightSideBar --|> UiPart
+SessionCard --|> UiPart
+ClientInfoPage --|> UiPart
-PersonCard ..> Model
-UiManager -right-> Logic
-MainWindow -left-> Logic
-
-PersonListPanel -[hidden]left- HelpWindow
HelpWindow -[hidden]left- CommandBox
CommandBox -[hidden]left- ResultDisplay
-ResultDisplay -[hidden]left- StatusBarFooter
MainWindow -[hidden]-|> UiPart
@enduml
diff --git a/docs/diagrams/UiClassDiagramP2.puml b/docs/diagrams/UiClassDiagramP2.puml
new file mode 100644
index 00000000000..6cea0a41d0f
--- /dev/null
+++ b/docs/diagrams/UiClassDiagramP2.puml
@@ -0,0 +1,52 @@
+@startuml
+!include style.puml
+skinparam arrowThickness 1.0
+skinparam arrowColor UI_COLOR_T4
+skinparam classBackgroundColor UI_COLOR
+
+package UiComponents <> {
+Class MainWindow
+Class SettingsWindow
+Class HelpWindow
+Class ResultDisplay
+Class ClientListPanel
+Class ClientCard
+Class StatusBarFooter
+Class Homepage
+class RightSideBar
+class SessionCard
+class ClientInfoPage
+Class CommandBox
+}
+
+package Model <> {
+Class HiddenModel #FFFFFF
+}
+
+package Logic <> {
+Class HiddenLogic #FFFFFF
+}
+
+Class HiddenOutside #FFFFFF
+
+MainWindow -up-> Model
+MainWindow -up-> Logic
+
+MainWindow *-right-> HelpWindow
+MainWindow *-down-> SettingsWindow
+MainWindow <-down-> CommandBox
+MainWindow *-down-> ResultDisplay
+MainWindow <-left-> ClientListPanel
+MainWindow *-down-> StatusBarFooter
+MainWindow <-down-> Homepage
+MainWindow <-> RightSideBar
+MainWindow <-down-> ClientInfoPage
+
+ClientListPanel -left-> ClientCard
+RightSideBar -right-> SessionCard
+
+StatusBarFooter -[hidden]down- ResultDisplay
+StatusBarFooter -[hidden]down- SettingsWindow
+HelpWindow -[hidden]left- ResultDisplay
+
+@enduml
diff --git a/docs/diagrams/UiClassDiagramP3.puml b/docs/diagrams/UiClassDiagramP3.puml
new file mode 100644
index 00000000000..9673060f608
--- /dev/null
+++ b/docs/diagrams/UiClassDiagramP3.puml
@@ -0,0 +1,47 @@
+@startuml
+!include style.puml
+skinparam arrowThickness 1.0
+skinparam arrowColor UI_COLOR_T4
+skinparam classBackgroundColor UI_COLOR
+
+package UI <>{
+Interface Ui <>
+Class "{abstract}\nUiPart" as UiPart
+Class UiManager
+
+
+ package UiComponents <> {
+ hide <>
+ Class UiC <>
+ note left
+ UiComponents contains all
+ other classes which
+ makes up the entire GUI
+ end note
+ }
+
+}
+
+package Model <> {
+Class HiddenModel #FFFFFF
+}
+
+package Logic <> {
+Class HiddenLogic #FFFFFF
+}
+
+Class HiddenOutside #FFFFFF
+HiddenOutside ..> Ui
+
+UiComponents -down-> Model
+UiComponents -down-> Logic
+
+UiManager .left.|> Ui
+UiManager -down-> UiComponents
+
+
+UiComponents -up-|> UiPart
+
+Ui -[hidden]down- UiPart
+
+@enduml
diff --git a/docs/diagrams/UndoRedoState0.puml b/docs/diagrams/UndoRedoState0.puml
deleted file mode 100644
index 96e30744d24..00000000000
--- a/docs/diagrams/UndoRedoState0.puml
+++ /dev/null
@@ -1,20 +0,0 @@
-@startuml
-!include style.puml
-skinparam ClassFontColor #000000
-skinparam ClassBorderColor #000000
-
-title Initial state
-
-package States {
- class State1 as "__ab0:AddressBook__"
- class State2 as "__ab1:AddressBook__"
- class State3 as "__ab2:AddressBook__"
-}
-State1 -[hidden]right-> State2
-State2 -[hidden]right-> State3
-hide State2
-hide State3
-
-class Pointer as "Current State" #FFFFF
-Pointer -up-> State1
-@end
diff --git a/docs/diagrams/UndoRedoState1.puml b/docs/diagrams/UndoRedoState1.puml
deleted file mode 100644
index 01fcb9b2b96..00000000000
--- a/docs/diagrams/UndoRedoState1.puml
+++ /dev/null
@@ -1,22 +0,0 @@
-@startuml
-!include style.puml
-skinparam ClassFontColor #000000
-skinparam ClassBorderColor #000000
-
-title After command "delete 5"
-
-package States <> {
- class State1 as "__ab0:AddressBook__"
- class State2 as "__ab1:AddressBook__"
- class State3 as "__ab2:AddressBook__"
-}
-
-State1 -[hidden]right-> State2
-State2 -[hidden]right-> State3
-
-hide State3
-
-class Pointer as "Current State" #FFFFF
-
-Pointer -up-> State2
-@end
diff --git a/docs/diagrams/UndoRedoState2.puml b/docs/diagrams/UndoRedoState2.puml
deleted file mode 100644
index bccc230a5d1..00000000000
--- a/docs/diagrams/UndoRedoState2.puml
+++ /dev/null
@@ -1,20 +0,0 @@
-@startuml
-!include style.puml
-skinparam ClassFontColor #000000
-skinparam ClassBorderColor #000000
-
-title After command "add n/David"
-
-package States <> {
- class State1 as "__ab0:AddressBook__"
- class State2 as "__ab1:AddressBook__"
- class State3 as "__ab2:AddressBook__"
-}
-
-State1 -[hidden]right-> State2
-State2 -[hidden]right-> State3
-
-class Pointer as "Current State" #FFFFF
-
-Pointer -up-> State3
-@end
diff --git a/docs/diagrams/UndoRedoState3.puml b/docs/diagrams/UndoRedoState3.puml
deleted file mode 100644
index ea29c9483e4..00000000000
--- a/docs/diagrams/UndoRedoState3.puml
+++ /dev/null
@@ -1,20 +0,0 @@
-@startuml
-!include style.puml
-skinparam ClassFontColor #000000
-skinparam ClassBorderColor #000000
-
-title After command "undo"
-
-package States <> {
- class State1 as "__ab0:AddressBook__"
- class State2 as "__ab1:AddressBook__"
- class State3 as "__ab2:AddressBook__"
-}
-
-State1 -[hidden]right-> State2
-State2 -[hidden]right-> State3
-
-class Pointer as "Current State" #FFFFF
-
-Pointer -up-> State2
-@end
diff --git a/docs/diagrams/UndoRedoState4.puml b/docs/diagrams/UndoRedoState4.puml
deleted file mode 100644
index 1b784cece80..00000000000
--- a/docs/diagrams/UndoRedoState4.puml
+++ /dev/null
@@ -1,20 +0,0 @@
-@startuml
-!include style.puml
-skinparam ClassFontColor #000000
-skinparam ClassBorderColor #000000
-
-title After command "list"
-
-package States <> {
- class State1 as "__ab0:AddressBook__"
- class State2 as "__ab1:AddressBook__"
- class State3 as "__ab2:AddressBook__"
-}
-
-State1 -[hidden]right-> State2
-State2 -[hidden]right-> State3
-
-class Pointer as "Current State" #FFFFF
-
-Pointer -up-> State2
-@end
diff --git a/docs/diagrams/UndoRedoState5.puml b/docs/diagrams/UndoRedoState5.puml
deleted file mode 100644
index 88927be32bc..00000000000
--- a/docs/diagrams/UndoRedoState5.puml
+++ /dev/null
@@ -1,21 +0,0 @@
-@startuml
-!include style.puml
-skinparam ClassFontColor #000000
-skinparam ClassBorderColor #000000
-
-title After command "clear"
-
-package States <> {
- class State1 as "__ab0:AddressBook__"
- class State2 as "__ab1:AddressBook__"
- class State3 as "__ab3:AddressBook__"
-}
-
-State1 -[hidden]right-> State2
-State2 -[hidden]right-> State3
-
-class Pointer as "Current State" #FFFFF
-
-Pointer -up-> State3
-note right on link: State ab2 deleted.
-@end
diff --git a/docs/diagrams/UndoSequenceDiagram.puml b/docs/diagrams/UndoSequenceDiagram.puml
deleted file mode 100644
index 410aab4e412..00000000000
--- a/docs/diagrams/UndoSequenceDiagram.puml
+++ /dev/null
@@ -1,53 +0,0 @@
-@startuml
-!include style.puml
-
-box Logic LOGIC_COLOR_T1
-participant ":LogicManager" as LogicManager LOGIC_COLOR
-participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
-participant "u:UndoCommand" as UndoCommand LOGIC_COLOR
-end box
-
-box Model MODEL_COLOR_T1
-participant ":Model" as Model MODEL_COLOR
-participant ":VersionedAddressBook" as VersionedAddressBook MODEL_COLOR
-end box
-[-> LogicManager : execute(undo)
-activate LogicManager
-
-LogicManager -> AddressBookParser : parseCommand(undo)
-activate AddressBookParser
-
-create UndoCommand
-AddressBookParser -> UndoCommand
-activate UndoCommand
-
-UndoCommand --> AddressBookParser
-deactivate UndoCommand
-
-AddressBookParser --> LogicManager : u
-deactivate AddressBookParser
-
-LogicManager -> UndoCommand : execute()
-activate UndoCommand
-
-UndoCommand -> Model : undoAddressBook()
-activate Model
-
-Model -> VersionedAddressBook : undo()
-activate VersionedAddressBook
-
-VersionedAddressBook -> VersionedAddressBook :resetData(ReadOnlyAddressBook)
-VersionedAddressBook --> Model :
-deactivate VersionedAddressBook
-
-Model --> UndoCommand
-deactivate Model
-
-UndoCommand --> LogicManager : result
-deactivate UndoCommand
-UndoCommand -[hidden]-> LogicManager : result
-destroy UndoCommand
-
-[<--LogicManager
-deactivate LogicManager
-@enduml
diff --git a/docs/diagrams/ViewSessionActivityDiagram.puml b/docs/diagrams/ViewSessionActivityDiagram.puml
new file mode 100644
index 00000000000..bcad03904e4
--- /dev/null
+++ b/docs/diagrams/ViewSessionActivityDiagram.puml
@@ -0,0 +1,22 @@
+@startuml
+start
+:User executes ViewSessionCommand;
+:Parse input from user;
+if () then ([period is valid])
+if () then ([period is found in view session hashmap])
+ :Get predicate from Hashmap;
+ else ([else])
+ if () then ([isPast])
+ :Create predicate for specified units in the past;
+ else ([else])
+ :Create predicate for specified units in the future;
+ endif
+ endif
+ :Update predicate on Session List;
+ :Show feedback message to user;
+ :Update title of Session List;
+ stop
+ else ([else])
+ :Show error message to user;
+ stop
+@enduml
diff --git a/docs/diagrams/ViewSessionParserRef.puml b/docs/diagrams/ViewSessionParserRef.puml
new file mode 100644
index 00000000000..642d23e32cb
--- /dev/null
+++ b/docs/diagrams/ViewSessionParserRef.puml
@@ -0,0 +1,45 @@
+@startuml
+!include style.puml
+
+box Logic LOGIC_COLOR_T1
+participant ":LogicManager" as LogicManager LOGIC_COLOR
+participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
+participant ":ViewSessionCommandParser" as ViewSessionCommandParser LOGIC_COLOR
+participant "command:ViewSessionCommand" as ViewSessionCommand LOGIC_COLOR
+end box
+
+group sd parse command arguments
+
+|||
+LogicManager -> AddressBookParser: parseCommand("sview p/week")
+activate AddressBookParser
+create ViewSessionCommandParser
+
+AddressBookParser -> ViewSessionCommandParser
+activate ViewSessionCommandParser
+
+ViewSessionCommandParser --> AddressBookParser
+deactivate ViewSessionCommandParser
+
+AddressBookParser -> ViewSessionCommandParser : parse("sview p/week")
+activate ViewSessionCommandParser
+
+create ViewSessionCommand
+ViewSessionCommandParser -> ViewSessionCommand : ViewSessionCommand("week")
+activate ViewSessionCommand
+
+ViewSessionCommand --> ViewSessionCommandParser : command
+deactivate ViewSessionCommand
+
+ViewSessionCommandParser --> AddressBookParser : command
+deactivate ViewSessionCommandParser
+
+ViewSessionCommandParser -[hidden]-> AddressBookParser : command
+destroy ViewSessionCommandParser
+
+AddressBookParser -> LogicManager: command
+deactivate AddressBookParser
+|||
+end
+
+@enduml
diff --git a/docs/diagrams/ViewSessionSequenceDiagram.puml b/docs/diagrams/ViewSessionSequenceDiagram.puml
new file mode 100644
index 00000000000..a241a370ef6
--- /dev/null
+++ b/docs/diagrams/ViewSessionSequenceDiagram.puml
@@ -0,0 +1,64 @@
+@startuml
+!include style.puml
+
+Actor User as user USER_COLOR
+
+box Ui UI_COLOR_T1
+participant ":MainWindow" as MainWindow UI_COLOR
+participant ":RightSideBar" as RightSideBar UI_COLOR
+end box
+
+box Logic LOGIC_COLOR_T1
+participant ":LogicManager" as LogicManager LOGIC_COLOR
+participant "command:ViewSessionCommand" as ViewSessionCommand LOGIC_COLOR
+participant ":CommandResult" as CommandResult LOGIC_COLOR
+end box
+
+box Model MODEL_COLOR_T1
+participant "model:Model" as Model MODEL_COLOR
+end box
+
+user -> MainWindow : executeCommand("sview p/week")
+activate MainWindow
+
+MainWindow-> LogicManager : execute("sview p/week")
+activate LogicManager
+
+ref over LogicManager, ViewSessionCommand : parse command arguments
+
+LogicManager -> ViewSessionCommand : execute(model)
+activate ViewSessionCommand
+
+ViewSessionCommand -> Model : updateFilteredSessionList(pred)
+activate Model
+
+Model --> ViewSessionCommand :
+deactivate Model
+
+create CommandResult
+ViewSessionCommand -> CommandResult:
+activate CommandResult
+
+CommandResult --> ViewSessionCommand : result
+deactivate CommandResult
+
+ViewSessionCommand --> LogicManager : result
+deactivate ViewSessionCommand
+ViewSessionCommand -[hidden]-> LogicManager : result
+destroy ViewSessionCommand
+MainWindow<--LogicManager : result
+deactivate LogicManager
+
+MainWindow-> RightSideBar : update(result, "sview p/week")
+activate RightSideBar
+
+ref over RightSideBar, LogicManager : update RightSideBar
+
+RightSideBar--> MainWindow
+deactivate RightSideBar
+MainWindow --> user
+deactivate MainWindow
+|||
+
+
+@enduml
diff --git a/docs/diagrams/ViewSessionUpdateRightSideBarRef.puml b/docs/diagrams/ViewSessionUpdateRightSideBarRef.puml
new file mode 100644
index 00000000000..63b6a090434
--- /dev/null
+++ b/docs/diagrams/ViewSessionUpdateRightSideBarRef.puml
@@ -0,0 +1,56 @@
+@startuml
+!include style.puml
+
+box Ui UI_COLOR_T1
+participant ":RightSideBar" as RightSideBar UI_COLOR
+participant "title:Label" as Title UI_COLOR
+participant ":SessionListView" as SessionListView UI_COLOR
+
+end box
+
+box Logic LOGIC_COLOR_T1
+participant ":LogicManager" as LogicManager LOGIC_COLOR
+end box
+
+group sd update RightSideBar
+
+|||
+[-> RightSideBar
+activate RightSideBar
+
+RightSideBar -> RightSideBar : updateLatestPeriod(result, "sview p/week")
+activate RightSideBar
+
+note right
+RightSideBar refers to success message
+of ViewSessionCommand for updateLatestPeriod
+end note
+
+RightSideBar --> RightSideBar
+deactivate RightSideBar
+
+RightSideBar -> Title : setText("WEEK")
+activate Title
+
+Title--> RightSideBar
+deactivate Title
+
+RightSideBar -> LogicManager: getFilteredSessionList()
+activate LogicManager
+
+LogicManager --> RightSideBar: fslist
+deactivate LogicManager
+
+RightSideBar -> SessionListView : setItems(fslist)
+activate SessionListView
+
+SessionListView --> RightSideBar
+deactivate SessionListView
+
+[<-- RightSideBar
+deactivate RightSideBar
+
+|||
+end
+
+@enduml
diff --git a/docs/diagrams/style.puml b/docs/diagrams/style.puml
index fad8b0adeaa..0a2faf83539 100644
--- a/docs/diagrams/style.puml
+++ b/docs/diagrams/style.puml
@@ -19,7 +19,7 @@
!define LOGIC_COLOR_T3 #1616B0
!define LOGIC_COLOR_T4 #101086
-!define MODEL_COLOR #9D0012
+!define MODEL_COLOR #d38475
!define MODEL_COLOR_T1 #F97181
!define MODEL_COLOR_T2 #E41F36
!define MODEL_COLOR_T3 #7B000E
diff --git a/docs/diagrams/tracing/AddScheduleExecuteRef.puml b/docs/diagrams/tracing/AddScheduleExecuteRef.puml
new file mode 100644
index 00000000000..ce1aa56ea55
--- /dev/null
+++ b/docs/diagrams/tracing/AddScheduleExecuteRef.puml
@@ -0,0 +1,66 @@
+@startuml
+!include ../style.puml
+
+box Logic LOGIC_COLOR_T1
+participant "a:AddScheduleCommand" as AddScheduleCommand LOGIC_COLOR
+participant "schedule:Schedule" as Schedule LOGIC_COLOR
+participant ":CommandResult" as CommandResult LOGIC_COLOR
+end box
+
+box Model MODEL_COLOR_T1
+participant "model:Model" as Model MODEL_COLOR
+end box
+
+[-> AddScheduleCommand : execute(model)
+
+activate AddScheduleCommand
+
+AddScheduleCommand -> Model: getFilteredClientList()
+activate Model
+
+Model --> AddScheduleCommand : filteredClientList
+deactivate Model
+
+AddScheduleCommand -> Model: getFilteredSessionList()
+activate Model
+
+Model --> AddScheduleCommand : filteredSessionList
+deactivate Model
+
+note over AddScheduleCommand, Model: Get second Client from filteredClientList and first Session from filteredSessionList
+
+AddScheduleCommand -> Model: hasAnyScheduleAssociatedWithClientAndSession(client2, session1)
+
+activate Model
+
+deactivate Model
+
+create Schedule
+AddScheduleCommand -> Schedule : Schedule(client2, session1)
+activate Schedule
+Schedule --> AddScheduleCommand : schedule
+deactivate Schedule
+
+AddScheduleCommand -> Model: addSchedule(schedule)
+activate Model
+
+deactivate Model
+
+create CommandResult
+AddScheduleCommand -> CommandResult: CommandResult(String)
+activate CommandResult
+
+CommandResult --> AddScheduleCommand : result
+deactivate CommandResult
+
+[<--AddScheduleCommand : result
+
+deactivate AddScheduleCommand
+
+AddScheduleCommand -[hidden]-> AddScheduleCommand : command
+
+|||
+
+destroy AddScheduleCommand
+
+@enduml
diff --git a/docs/diagrams/tracing/DeleteSessionExecuteRef.puml b/docs/diagrams/tracing/DeleteSessionExecuteRef.puml
new file mode 100644
index 00000000000..e62014d3024
--- /dev/null
+++ b/docs/diagrams/tracing/DeleteSessionExecuteRef.puml
@@ -0,0 +1,114 @@
+@startuml
+!include ../style.puml
+
+group sd execute command
+
+box Logic LOGIC_COLOR_T1
+participant ":DeleteSessionCommand" as DeleteSessionCommand LOGIC_COLOR
+participant "result:CommandResult" as CommandResult LOGIC_COLOR
+end box
+
+box Model MODEL_COLOR_T1
+participant "model:Model" as Model MODEL_COLOR
+participant ":AddressBook" as AddressBook MODEL_COLOR
+participant ":Schedule" as Schedule MODEL_COLOR
+participant ":Session" as Session MODEL_COLOR
+end box
+
+|||
+[-> DeleteSessionCommand : execute(model)
+activate DeleteSessionCommand
+
+DeleteSessionCommand -> Model : getFilteredSessionList()
+activate Model
+
+Model --> DeleteSessionCommand : filteredSessions
+deactivate Model
+
+DeleteSessionCommand -> Model: hasAnyScheduleAssociatedWithSession(Session)
+activate Model
+
+Model -> AddressBook : getScheduleList()
+activate AddressBook
+
+AddressBook --> Model : scheduleList
+deactivate AddressBook
+
+loop all schedule in scheduleList
+ Model -> Schedule : getSession()
+ activate Schedule
+
+ Schedule -> Session: isIdentical()
+ note left : search for schedule with same session
+ activate Session
+
+ deactivate Session
+ deactivate Schedule
+end
+
+Model --> DeleteSessionCommand
+deactivate Model
+
+DeleteSessionCommand -> Model: deleteSessionAssociatedSchedules(Session)
+activate Model
+
+Model -> AddressBook : getScheduleList()
+activate AddressBook
+
+AddressBook --> Model : scheduleList
+deactivate AddressBook
+
+loop all schedule in scheduleList
+ Model -> Schedule : getSchedule()
+ activate Schedule
+
+ Schedule -> Session : getSession()
+ activate Session
+
+ Session --> Schedule : sessionToTest
+ deactivate Session
+
+ Schedule --> Model : sessionToTest
+ deactivate Schedule
+
+ Model --> Session: isIdentical(sessionToTest)
+ note left : search for schedule with same session
+ activate Session
+
+ deactivate Session
+end
+
+loop all schedule in associatedScheduleList
+ Model -> Model : deleteSchedule()
+ activate Model MODEL_COLOR_T1
+
+ Model -> AddressBook : removeSchedule(schedule)
+ activate AddressBook
+
+ deactivate AddressBook
+ deactivate Model
+end
+
+deactivate Model
+
+DeleteSessionCommand -> Model: deleteSession(Session)
+activate Model
+
+deactivate Model
+
+create CommandResult
+DeleteSessionCommand -> CommandResult: CommandResult(String)
+activate CommandResult
+
+CommandResult --> DeleteSessionCommand : result
+deactivate CommandResult
+
+[<-- DeleteSessionCommand : result
+deactivate DeleteSessionCommand
+
+DeleteSessionCommand -[hidden]->] : result
+destroy DeleteSessionCommand
+
+|||
+end
+@enduml
diff --git a/docs/diagrams/tracing/DeleteSessionObjectDiagram.puml b/docs/diagrams/tracing/DeleteSessionObjectDiagram.puml
new file mode 100644
index 00000000000..00a4d736380
--- /dev/null
+++ b/docs/diagrams/tracing/DeleteSessionObjectDiagram.puml
@@ -0,0 +1,23 @@
+@startuml
+skinparam arrowThickness 1.1
+
+object "__andy:Client__" as secondClient {
+ name = Andy
+}
+
+object "__john:Client__" as firstClient {
+ name = John
+}
+
+object "__enduranceTraining:Session__" as session {
+ interval = 12/02/2020 1400 - 1600
+}
+
+object "__:Schedule__" as firstSchedule
+object "__:Schedule__" as secondSchedule
+
+(firstClient, session) .. firstSchedule
+
+(secondClient, session) .. secondSchedule
+
+@enduml
diff --git a/docs/diagrams/tracing/DeleteSessionParseArgsRef.puml b/docs/diagrams/tracing/DeleteSessionParseArgsRef.puml
new file mode 100644
index 00000000000..928bd8ea896
--- /dev/null
+++ b/docs/diagrams/tracing/DeleteSessionParseArgsRef.puml
@@ -0,0 +1,37 @@
+@startuml
+!include ../style.puml
+
+participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
+participant "parser:DeleteSessionCommandParser" as DeleteSessionCommandParser LOGIC_COLOR
+participant "command:DeleteSessionCommand" as DeleteSessionCommand LOGIC_COLOR
+
+group sd parse command arguments
+
+|||
+create DeleteSessionCommandParser
+AddressBookParser -> DeleteSessionCommandParser
+activate DeleteSessionCommandParser
+
+DeleteSessionCommandParser --> AddressBookParser : parser
+deactivate DeleteSessionCommandParser
+
+AddressBookParser -> DeleteSessionCommandParser : parse(args)
+activate DeleteSessionCommandParser
+
+create DeleteSessionCommand
+DeleteSessionCommandParser -> DeleteSessionCommand : DeleteSessionCommand(index, isForced)
+activate DeleteSessionCommand
+
+DeleteSessionCommand --> DeleteSessionCommandParser : command
+deactivate DeleteSessionCommand
+
+DeleteSessionCommandParser --> AddressBookParser : command
+deactivate DeleteSessionCommandParser
+
+DeleteSessionCommandParser -[hidden]-> AddressBookParser : command
+destroy DeleteSessionCommandParser
+
+|||
+end
+
+@enduml
diff --git a/docs/diagrams/tracing/DeleteSessionSequenceDiagram.puml b/docs/diagrams/tracing/DeleteSessionSequenceDiagram.puml
new file mode 100644
index 00000000000..a6aef053c09
--- /dev/null
+++ b/docs/diagrams/tracing/DeleteSessionSequenceDiagram.puml
@@ -0,0 +1,78 @@
+@startuml
+!include ../style.puml
+
+skinparam defaultFontSize 24
+
+box Logic LOGIC_COLOR_T1
+participant ":LogicManager" as LogicManager LOGIC_COLOR
+participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
+participant "d:DeleteSessionCommand" as DeleteSessionCommand LOGIC_COLOR
+participant ":CommandResult" as CommandResult LOGIC_COLOR
+end box
+
+box Model MODEL_COLOR_T1
+participant "model:Model" as Model MODEL_COLOR
+end box
+[-> LogicManager : execute("sdel 1 f/")
+activate LogicManager
+
+box Storage STORAGE_COLOR_T1
+participant "storage:Storage" as Storage STORAGE_COLOR
+end box
+
+LogicManager -> AddressBookParser : parseCommand("sdel 1 f/")
+activate AddressBookParser
+
+ref over AddressBookParser, DeleteSessionCommand : parse command arguments
+
+AddressBookParser --> LogicManager : d
+deactivate AddressBookParser
+
+LogicManager -> DeleteSessionCommand : execute(model)
+activate DeleteSessionCommand
+
+DeleteSessionCommand -> Model : getFilteredSessionList()
+activate Model
+
+deactivate Model
+
+DeleteSessionCommand -> Model: hasAnyScheduleAssociatedWithSession(Session)
+activate Model
+
+deactivate Model
+
+DeleteSessionCommand -> Model: deleteSessionAssociatedSchedules(Session)
+activate Model
+
+deactivate Model
+
+DeleteSessionCommand -> Model: deleteSession(Session)
+activate Model
+
+deactivate Model
+
+create CommandResult
+DeleteSessionCommand -> CommandResult: CommandResult(String)
+activate CommandResult
+
+CommandResult --> DeleteSessionCommand : result
+deactivate CommandResult
+
+DeleteSessionCommand --> LogicManager : result
+deactivate DeleteSessionCommand
+DeleteSessionCommand -[hidden]-> LogicManager : result
+destroy DeleteSessionCommand
+
+LogicManager --> Model: getAddressBook()
+activate Model
+
+deactivate Model
+
+LogicManager --> Storage : saveAddressBook(addressBook)
+activate Storage
+
+deactivate Storage
+
+[<--LogicManager : result
+deactivate LogicManager
+@enduml
diff --git a/docs/diagrams/tracing/LogicSequenceDiagram.puml b/docs/diagrams/tracing/LogicSequenceDiagram.puml
index fdcbe1c0ccc..718f8a47d13 100644
--- a/docs/diagrams/tracing/LogicSequenceDiagram.puml
+++ b/docs/diagrams/tracing/LogicSequenceDiagram.puml
@@ -13,7 +13,7 @@ create ecp
abp -> ecp
abp -> ecp ++: parse(arguments)
create ec
-ecp -> ec ++: index, editPersonDescriptor
+ecp -> ec ++: index, editClientDescriptor
ec --> ecp --
ecp --> abp --: command
abp --> logic --: command
diff --git a/docs/diagrams/tracing/OverlappingScheduleObjectDiagram0.puml b/docs/diagrams/tracing/OverlappingScheduleObjectDiagram0.puml
new file mode 100644
index 00000000000..cd02eb54f4a
--- /dev/null
+++ b/docs/diagrams/tracing/OverlappingScheduleObjectDiagram0.puml
@@ -0,0 +1,27 @@
+@startuml
+
+
+object "__andy:Client__" as secondClient {
+ name = Andy
+}
+
+object "__john:Client__" as firstClient {
+ name = John
+}
+
+object "__enduranceTraining:Session__" as session {
+ interval = 12/02/2020 1400 - 1600
+}
+
+object "__s1:Schedule__" as firstSchedule
+
+(firstClient, session) .. firstSchedule
+
+note as N1
+Client List:
+1. john
+2. andy
+Session List:
+1. endurance training (12/02/2020 1400 - 1600)
+endnote
+@enduml
diff --git a/docs/diagrams/tracing/OverlappingScheduleObjectDiagram1.puml b/docs/diagrams/tracing/OverlappingScheduleObjectDiagram1.puml
new file mode 100644
index 00000000000..9c84b595973
--- /dev/null
+++ b/docs/diagrams/tracing/OverlappingScheduleObjectDiagram1.puml
@@ -0,0 +1,26 @@
+@startuml
+
+object "__enduranceTraining:Session__" as session {
+ interval = 12/02/2020 1400 - 1600
+}
+
+object "__andy:Client__" as secondClient {
+ name = Andy
+}
+object "__s2:Schedule__" as secondSchedule
+(secondClient, session) .. secondSchedule
+
+object "__john:Client__" as firstClient {
+ name = John
+}
+object "__s1:Schedule__" as firstSchedule
+(firstClient, session) .. firstSchedule
+
+note as N1
+Client List:
+1. john
+2. andy
+Session List:
+1. endurance training (12/02/2020 1400 - 1600)
+endnote
+@enduml
diff --git a/docs/favicon.png b/docs/favicon.png
new file mode 100644
index 00000000000..fbe57aef9db
Binary files /dev/null and b/docs/favicon.png differ
diff --git a/docs/images/AddScheduleActivityDiagram.png b/docs/images/AddScheduleActivityDiagram.png
new file mode 100644
index 00000000000..94e86d9f971
Binary files /dev/null and b/docs/images/AddScheduleActivityDiagram.png differ
diff --git a/docs/images/AddScheduleExecuteRef.png b/docs/images/AddScheduleExecuteRef.png
new file mode 100644
index 00000000000..a075d2a1098
Binary files /dev/null and b/docs/images/AddScheduleExecuteRef.png differ
diff --git a/docs/images/AddScheduleSequenceDiagram.png b/docs/images/AddScheduleSequenceDiagram.png
new file mode 100644
index 00000000000..ce5c08d598d
Binary files /dev/null and b/docs/images/AddScheduleSequenceDiagram.png differ
diff --git a/docs/images/AnnotatedUi.png b/docs/images/AnnotatedUi.png
new file mode 100644
index 00000000000..fd6d87cf5c3
Binary files /dev/null and b/docs/images/AnnotatedUi.png differ
diff --git a/docs/images/ArchitectureSequenceDiagram.png b/docs/images/ArchitectureSequenceDiagram.png
index 2f1346869d0..e7d88e06436 100644
Binary files a/docs/images/ArchitectureSequenceDiagram.png and b/docs/images/ArchitectureSequenceDiagram.png differ
diff --git a/docs/images/ClientPanel.png b/docs/images/ClientPanel.png
new file mode 100644
index 00000000000..f67be69ccb0
Binary files /dev/null and b/docs/images/ClientPanel.png differ
diff --git a/docs/images/ClientViewWeightSequenceDiagram.png b/docs/images/ClientViewWeightSequenceDiagram.png
new file mode 100644
index 00000000000..ff42fdd2e04
Binary files /dev/null and b/docs/images/ClientViewWeightSequenceDiagram.png differ
diff --git a/docs/images/DeleteClientSequenceDiagram.png b/docs/images/DeleteClientSequenceDiagram.png
new file mode 100644
index 00000000000..8e3329d486a
Binary files /dev/null and b/docs/images/DeleteClientSequenceDiagram.png differ
diff --git a/docs/images/DeleteSequenceDiagram.png b/docs/images/DeleteSequenceDiagram.png
deleted file mode 100644
index fa327b39618..00000000000
Binary files a/docs/images/DeleteSequenceDiagram.png and /dev/null differ
diff --git a/docs/images/DeleteSessionActivityDiagram.png b/docs/images/DeleteSessionActivityDiagram.png
new file mode 100644
index 00000000000..6dbbf6c077e
Binary files /dev/null and b/docs/images/DeleteSessionActivityDiagram.png differ
diff --git a/docs/images/DeleteSessionExecuteRef.png b/docs/images/DeleteSessionExecuteRef.png
new file mode 100644
index 00000000000..eb9f3065fe1
Binary files /dev/null and b/docs/images/DeleteSessionExecuteRef.png differ
diff --git a/docs/images/DeleteSessionObjectDiagram.png b/docs/images/DeleteSessionObjectDiagram.png
new file mode 100644
index 00000000000..8740f4db4f9
Binary files /dev/null and b/docs/images/DeleteSessionObjectDiagram.png differ
diff --git a/docs/images/DeleteSessionParseArgsRef.png b/docs/images/DeleteSessionParseArgsRef.png
new file mode 100644
index 00000000000..a75b6fd386f
Binary files /dev/null and b/docs/images/DeleteSessionParseArgsRef.png differ
diff --git a/docs/images/DeleteSessionSequenceDiagram.png b/docs/images/DeleteSessionSequenceDiagram.png
new file mode 100644
index 00000000000..62c0405a27e
Binary files /dev/null and b/docs/images/DeleteSessionSequenceDiagram.png differ
diff --git a/docs/images/EditScheduleActivityDiagram.png b/docs/images/EditScheduleActivityDiagram.png
new file mode 100644
index 00000000000..d04ca530d35
Binary files /dev/null and b/docs/images/EditScheduleActivityDiagram.png differ
diff --git a/docs/images/EditScheduleSequenceDiagram.png b/docs/images/EditScheduleSequenceDiagram.png
new file mode 100644
index 00000000000..430e3c5bec2
Binary files /dev/null and b/docs/images/EditScheduleSequenceDiagram.png differ
diff --git a/docs/images/EditSessionActivityDiagram.png b/docs/images/EditSessionActivityDiagram.png
new file mode 100644
index 00000000000..2552c2525a5
Binary files /dev/null and b/docs/images/EditSessionActivityDiagram.png differ
diff --git a/docs/images/EditSessionSequenceDiagram.png b/docs/images/EditSessionSequenceDiagram.png
new file mode 100644
index 00000000000..870babf6aaf
Binary files /dev/null and b/docs/images/EditSessionSequenceDiagram.png differ
diff --git a/docs/images/LogicClassDiagram.png b/docs/images/LogicClassDiagram.png
index b9e853cef12..526c1aaeb72 100644
Binary files a/docs/images/LogicClassDiagram.png and b/docs/images/LogicClassDiagram.png differ
diff --git a/docs/images/ModelClassDiagram.png b/docs/images/ModelClassDiagram.png
index 280064118cf..4ed7d9bbde3 100644
Binary files a/docs/images/ModelClassDiagram.png and b/docs/images/ModelClassDiagram.png differ
diff --git a/docs/images/ModelClassDiagram2.png b/docs/images/ModelClassDiagram2.png
new file mode 100644
index 00000000000..4b98d64b933
Binary files /dev/null and b/docs/images/ModelClassDiagram2.png differ
diff --git a/docs/images/OverlappingScheduleObjectDiagram0.png b/docs/images/OverlappingScheduleObjectDiagram0.png
new file mode 100644
index 00000000000..6fd15785102
Binary files /dev/null and b/docs/images/OverlappingScheduleObjectDiagram0.png differ
diff --git a/docs/images/OverlappingScheduleObjectDiagram1.png b/docs/images/OverlappingScheduleObjectDiagram1.png
new file mode 100644
index 00000000000..7f0c678f88c
Binary files /dev/null and b/docs/images/OverlappingScheduleObjectDiagram1.png differ
diff --git a/docs/images/SchedulePanel.png b/docs/images/SchedulePanel.png
new file mode 100644
index 00000000000..68464040058
Binary files /dev/null and b/docs/images/SchedulePanel.png differ
diff --git a/docs/images/SessionPanel.png b/docs/images/SessionPanel.png
new file mode 100644
index 00000000000..40065b4c7b8
Binary files /dev/null and b/docs/images/SessionPanel.png differ
diff --git a/docs/images/StorageClassDiagram.png b/docs/images/StorageClassDiagram.png
index d87c1216820..e8ff23155ac 100644
Binary files a/docs/images/StorageClassDiagram.png and b/docs/images/StorageClassDiagram.png differ
diff --git a/docs/images/Ui.png b/docs/images/Ui.png
index 5bd77847aa2..63e924c2e70 100644
Binary files a/docs/images/Ui.png and b/docs/images/Ui.png differ
diff --git a/docs/images/UiClassDiagram.png b/docs/images/UiClassDiagram.png
index 7b4b3dbea45..7d0e3b9f364 100644
Binary files a/docs/images/UiClassDiagram.png and b/docs/images/UiClassDiagram.png differ
diff --git a/docs/images/UiClassDiagramP2.png b/docs/images/UiClassDiagramP2.png
new file mode 100644
index 00000000000..7f50b2cba0c
Binary files /dev/null and b/docs/images/UiClassDiagramP2.png differ
diff --git a/docs/images/UiClassDiagramP3.png b/docs/images/UiClassDiagramP3.png
new file mode 100644
index 00000000000..7b9a3fe5fe4
Binary files /dev/null and b/docs/images/UiClassDiagramP3.png differ
diff --git a/docs/images/UndoRedoState0.png b/docs/images/UndoRedoState0.png
deleted file mode 100644
index 8f7538cd884..00000000000
Binary files a/docs/images/UndoRedoState0.png and /dev/null differ
diff --git a/docs/images/UndoRedoState1.png b/docs/images/UndoRedoState1.png
deleted file mode 100644
index df9908d0948..00000000000
Binary files a/docs/images/UndoRedoState1.png and /dev/null differ
diff --git a/docs/images/UndoRedoState2.png b/docs/images/UndoRedoState2.png
deleted file mode 100644
index 36519c1015b..00000000000
Binary files a/docs/images/UndoRedoState2.png and /dev/null differ
diff --git a/docs/images/UndoRedoState3.png b/docs/images/UndoRedoState3.png
deleted file mode 100644
index 19959d01712..00000000000
Binary files a/docs/images/UndoRedoState3.png and /dev/null differ
diff --git a/docs/images/UndoRedoState4.png b/docs/images/UndoRedoState4.png
deleted file mode 100644
index 4c623e4f2c5..00000000000
Binary files a/docs/images/UndoRedoState4.png and /dev/null differ
diff --git a/docs/images/UndoRedoState5.png b/docs/images/UndoRedoState5.png
deleted file mode 100644
index 84ad2afa6bd..00000000000
Binary files a/docs/images/UndoRedoState5.png and /dev/null differ
diff --git a/docs/images/UndoSequenceDiagram.png b/docs/images/UndoSequenceDiagram.png
deleted file mode 100644
index 6addcd3a8d9..00000000000
Binary files a/docs/images/UndoSequenceDiagram.png and /dev/null differ
diff --git a/docs/images/ViewSessionActivityDiagram.png b/docs/images/ViewSessionActivityDiagram.png
new file mode 100644
index 00000000000..e9378fd76f7
Binary files /dev/null and b/docs/images/ViewSessionActivityDiagram.png differ
diff --git a/docs/images/ViewSessionParserRef.png b/docs/images/ViewSessionParserRef.png
new file mode 100644
index 00000000000..f0e54eb6c53
Binary files /dev/null and b/docs/images/ViewSessionParserRef.png differ
diff --git a/docs/images/ViewSessionSequenceDiagram.png b/docs/images/ViewSessionSequenceDiagram.png
new file mode 100644
index 00000000000..f3c9d1aa989
Binary files /dev/null and b/docs/images/ViewSessionSequenceDiagram.png differ
diff --git a/docs/images/ViewSessionUpdateRightSideBarRef.png b/docs/images/ViewSessionUpdateRightSideBarRef.png
new file mode 100644
index 00000000000..513f1b5d8e8
Binary files /dev/null and b/docs/images/ViewSessionUpdateRightSideBarRef.png differ
diff --git a/docs/images/autocomplete_sample.png b/docs/images/autocomplete_sample.png
new file mode 100644
index 00000000000..cf33d102ac3
Binary files /dev/null and b/docs/images/autocomplete_sample.png differ
diff --git a/docs/images/benclmnt.png b/docs/images/benclmnt.png
new file mode 100644
index 00000000000..43b37509abd
Binary files /dev/null and b/docs/images/benclmnt.png differ
diff --git a/docs/images/cedit_sample.png b/docs/images/cedit_sample.png
new file mode 100644
index 00000000000..7edda4b5dba
Binary files /dev/null and b/docs/images/cedit_sample.png differ
diff --git a/docs/images/cview_sample.png b/docs/images/cview_sample.png
new file mode 100644
index 00000000000..f2e746c7982
Binary files /dev/null and b/docs/images/cview_sample.png differ
diff --git a/docs/images/dhafinrazaq.png b/docs/images/dhafinrazaq.png
new file mode 100644
index 00000000000..f04ebb225a0
Binary files /dev/null and b/docs/images/dhafinrazaq.png differ
diff --git a/docs/images/findAlexDavidResult.png b/docs/images/findAlexDavidResult.png
index 235da1c273e..4ca28e28c7c 100644
Binary files a/docs/images/findAlexDavidResult.png and b/docs/images/findAlexDavidResult.png differ
diff --git a/docs/images/helpMessage.png b/docs/images/helpMessage.png
index b1f70470137..e1f923fe628 100644
Binary files a/docs/images/helpMessage.png and b/docs/images/helpMessage.png differ
diff --git a/docs/images/homepage.png b/docs/images/homepage.png
new file mode 100644
index 00000000000..a1ec5e07922
Binary files /dev/null and b/docs/images/homepage.png differ
diff --git a/docs/images/kelvinvin.png b/docs/images/kelvinvin.png
new file mode 100644
index 00000000000..73927301ed5
Binary files /dev/null and b/docs/images/kelvinvin.png differ
diff --git a/docs/images/maguireong.png b/docs/images/maguireong.png
new file mode 100644
index 00000000000..24236c603f3
Binary files /dev/null and b/docs/images/maguireong.png differ
diff --git a/docs/images/sadd_sample.png b/docs/images/sadd_sample.png
new file mode 100644
index 00000000000..da525fe8292
Binary files /dev/null and b/docs/images/sadd_sample.png differ
diff --git a/docs/images/schadd_sample.png b/docs/images/schadd_sample.png
new file mode 100644
index 00000000000..f07f7842996
Binary files /dev/null and b/docs/images/schadd_sample.png differ
diff --git a/docs/images/schedit_sample.png b/docs/images/schedit_sample.png
new file mode 100644
index 00000000000..47d8b69bcad
Binary files /dev/null and b/docs/images/schedit_sample.png differ
diff --git a/docs/images/sedit_sample.png b/docs/images/sedit_sample.png
new file mode 100644
index 00000000000..5f1ee34d2bf
Binary files /dev/null and b/docs/images/sedit_sample.png differ
diff --git a/docs/images/settingsWindow.png b/docs/images/settingsWindow.png
new file mode 100644
index 00000000000..72b505c75b5
Binary files /dev/null and b/docs/images/settingsWindow.png differ
diff --git a/docs/images/sview_sample.png b/docs/images/sview_sample.png
new file mode 100644
index 00000000000..e2d8c080652
Binary files /dev/null and b/docs/images/sview_sample.png differ
diff --git a/docs/images/tanweijie123.png b/docs/images/tanweijie123.png
new file mode 100644
index 00000000000..3e363e2b94a
Binary files /dev/null and b/docs/images/tanweijie123.png differ
diff --git a/docs/index.md b/docs/index.md
index 7601dbaad0d..cb01b44a702 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1,17 +1,19 @@
---
layout: page
-title: AddressBook Level-3
+title: FitEgo
---
-[](https://github.com/se-edu/addressbook-level3/actions)
-[](https://codecov.io/gh/se-edu/addressbook-level3)
+[](https://github.com/AY2021S1-CS2103T-T13-3/tp/actions)
+[](https://codecov.io/gh/AY2021S1-CS2103T-T13-3/tp/actions)
-**AddressBook is a desktop application for managing your contact details.** While it has a GUI, most of the user interactions happen using a CLI (Command Line Interface).
+**FitEgo is a desktop application for fitness instructors to keep track of his/her customers easily, so that he can
+spend more time on his clients / his routine rather than manually tracking administrative matters using alternative software like Excel.**
+While it has a GUI, most of the user interactions happen using a CLI (Command Line Interface).
-* If you are interested in using AddressBook, head over to the [_Quick Start_ section of the **User Guide**](UserGuide.html#quick-start).
-* If you are interested about developing AddressBook, the [**Developer Guide**](DeveloperGuide.html) is a good place to start.
+* If you are interested in using FitEgo, head over to the [_Quick Start_ section of the **User Guide**](UserGuide.html#quick-start).
+* If you are interested about developing FitEgo, the [**Developer Guide**](DeveloperGuide.html) is a good place to start.
**Acknowledgements**
diff --git a/docs/team/benclmnt.md b/docs/team/benclmnt.md
new file mode 100644
index 00000000000..8af59092394
--- /dev/null
+++ b/docs/team/benclmnt.md
@@ -0,0 +1,66 @@
+---
+layout: page
+title: Bennett Clement's Project Portfolio Page
+---
+
+## Project: FitEgo
+
+FitEgo is a desktop application for fitness instructors to schedule, and keep track of his/her customers' progress and payments in one place.
+It is faster compared to manually tracking administrative matters using alternative software like Excel and Google Calendar. The user interacts with it using a CLI, and it has a GUI created with JavaFX.
+
+It is written in Java, and has about 23 kLoC.
+
+Given below are my contributions to the project.
+
+* **New Feature**: Added the ability to add / delete sessions. (Relevant PR(s): [\#72](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/72), [\#97](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/97))
+ * What it does: This feature allows the user to create and delete fitness sessions.
+ * Justification: This feature is core to the product because the user needs to create a session before they can schedule a client. I also lay the foundation for other team members to work on the session model.
+ * Highlights: This enhancement required an in-depth analysis of design alternatives.
+ The implementation was challenging as it deals with dates, the notion of "overlapping" dates, and handling schedules related to the session.
+
+* **New Feature**: Added table to view a list of client's schedules. (Relevant PR: [\#159](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/159))
+ * What it does: List client's schedules (with remarks, payment status and exercise type)
+ * Justification: This feature makes it easy for the user to keep track of client's progress in one page.
+ * Highlights: The implementation was challenging as it required the table to be resizable and to show updates as soon as user changes any details about the client / schedules.
+
+* **New Feature**: Added the feature to write remarks for a schedule. (PR: [\#140](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/140))
+ * What it does: This feature allows the user to save notes / observation of the client for a given session. The user can view the remarks for each session in a table shown together with other client's details.
+
+* **New Feature**: Added the feature to customize a client's profile picture. (relevant [commit](https://github.com/AY2021S1-CS2103T-T13-3/tp/commit/542d5e26919e01944dc99fd09ec9c3532e1da21f))
+ * What it does: This feature allows the user to add their client's pictures in the `data` folder. If there is no picture provided, FitEgo will fall back to a default picture.
+
+* **Code contributed**: [RepoSense link](https://nus-cs2103-ay2021s1.github.io/tp-dashboard/#breakdown=true&search=&sort=groupTitle&sortWithin=title&since=2020-08-14&timeframe=commit&mergegroup=&groupSelect=groupByRepos&checkedFileTypes=docs~functional-code~test-code~other&tabOpen=true&tabType=authorship&until=2020-11-09&tabAuthor=benclmnt&tabRepo=AY2021S1-CS2103T-T13-3%2Ftp%5Bmaster%5D&authorshipIsMergeGroup=false&authorshipFileTypes=docs~functional-code~test-code~other)
+
+* **Project management**:
+ * Managed all releases `v1.1` - `v1.3` (4 releases) on GitHub
+ * Set up the GitHub team org/repo
+ * Set up tools (Gradle)
+ * Maintained issue tracker by setting up milestones, label and triaging bugs
+
+* **Enhancements to existing features**:
+ * Repurposed tag to keep track of allergies / injury history (PR: [\#46](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/46))
+ * Adapted saving to storage to include session objects (PR: [\#72](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/72))
+ * Wrote most of the tests for session model (PR: [\#140](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/140))
+
+* **Documentation**:
+ * User Guide:
+ * Updated the documentation for the features `sadd` and `sdel` (PR: [\#139](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/139))
+ * Added an overview for FitEgo User Guide (PR: [\#139](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/139), [\#233](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/233))
+ * Simplified the command summary section (PR: [\#233](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/233))
+ * Developer Guide:
+ * Added implementation details of the `sdel` feature. (PR: [\#150](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/150))
+ * Updated the diagram for Model component (PR: [\#150](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/150))
+
+* **Review/mentoring contributions**:
+ * Regularly discussed implementation details in our group's communication channel.
+ * Helped others debug and find solution during team meetings. For example, together with Wei Jie and Kelvin, we integrate the tab pane in client's information page.
+ * Posted issues and discussions on issue tracker. (Some examples:
+ [\#98](https://github.com/AY2021S1-CS2103T-T13-3/tp/issues/98), [\#107](https://github.com/AY2021S1-CS2103T-T13-3/tp/issues/107), [\#223](https://github.com/AY2021S1-CS2103T-T13-3/tp/issues/223))
+ * PRs reviewed (with non-trivial review comments): [\#101](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/101), [\#230](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/230), [\#231](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/231)
+
+* **Tools**:
+ * Integrated new Github plugins (PlantUML and Codecov) to the team repo.
+
+* **Community**:
+ * Reported bugs and suggestions for Group [CS2103T-T15-4](https://ay2021s1-cs2103t-t15-4.github.io/tp/UserGuide.html) on CATcher.
+
diff --git a/docs/team/dhafinrazaq.md b/docs/team/dhafinrazaq.md
new file mode 100644
index 00000000000..eec461c7414
--- /dev/null
+++ b/docs/team/dhafinrazaq.md
@@ -0,0 +1,60 @@
+---
+layout: page
+title: Dhafin Razaq Oktoyuzan's Project Portfolio Page
+---
+
+## Project: FitEgo
+
+FitEgo is a desktop application for fitness instructors to schedule, and keep track of his/her customers' progress and payments in one place.
+It is faster compared to manually tracking administrative matters using alternative software like Excel and Google Calendar. The user interacts with it using a CLI, and it has a GUI created with JavaFX.
+
+It is written in Java, and has about 23 kLoC.
+
+Given below are my contributions to the project.
+
+* **New Feature**: Added the ability to add and delete schedules. (Pull Request [#81](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/81), [#96](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/96))
+ * What it does: Allows the user to add and delete schedules. A schedule contains information about a client and the attended session. Thus, adding a schedule means that the specified client will come to a session.
+ * Justification: This feature is core to the product because the user needs to be able to associate a client to a session. This is necessary for the other enhancements in the project such as the ability of tracking the sessions attended by a client and tracking which clients will attend a session.
+ * Highlights: Before implementing this feature, a `Schedule` model must be implemented first. When implementing the `Schedule` model (which is then implemented as an association class of client and session) and how it should be stored in the storage, in-depth design analysis were needed. Creating the test cases were also challenging since it needs to test the integration with `Client` and `Session` objects.
+
+* **New Feature**: Added the payment tracking feature (PR [#137](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/137))
+ * What it does: Allows the user to track the clients' payment status by looking at either the right side panel or the client's detail view.
+ * What I did: Associate each schedule (which contains a client and session) to a payment status (either paid or unpaid) and modify the right side bar and client detail's table to show the payment status.
+ * Justification: This feature allows the user to easily spot whether a client has paid for a session by just looking at the color of the texts.
+ * Highlights: The implementation requires a good understanding in UI (including JavaFX and CSS coloring) and how it relates to the logic.
+ * Credits: *Credit to Kelvin for creating the right side bar and Bennett for creating client's detail table*
+
+* **Code contributed**: [RepoSense link](https://nus-cs2103-ay2021s1.github.io/tp-dashboard/#breakdown=true&search=&sort=groupTitle&sortWithin=title&since=2020-08-14&timeframe=commit&mergegroup=&groupSelect=groupByRepos&checkedFileTypes=docs~functional-code~test-code~other&tabOpen=true&tabType=authorship&until=2020-11-09&tabAuthor=dhafinrazaq&tabRepo=AY2021S1-CS2103T-T13-3%2Ftp%5Bmaster%5D&authorshipIsMergeGroup=false&authorshipFileTypes=docs~functional-code~test-code~other)
+
+* **Project management or team-based tasks**:
+ * Contributed to `v1.3` and `v1.4` demo and non-feature-specific documentations on UG and DG.
+ * Maintained issue tracker such as labelling and closing finished issues.
+
+* **Enhancements to existing features**:
+ * Modified and enhanced `cedit` from `edit` command. It will automatically show the edited client's detail view after executing a `cedit` command. (PR [#53](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/53), [\#165](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/165))
+ * Modified `cdel` to check for associated Schedules before deleting the Client. (PR [#152](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/152))
+ * Modified `Session` model (and its relation to `Storage`) to use interval as unique identifier. (PR [#95](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/95))
+ * Added test cases for `Schedule` model. (PR [#158](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/158))
+ * Adapted saving to `Storage` to include `Schedule` objects. (PR [#74](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/74))
+ * Refactored `#isUnique()` into `#isIdentical()` so that the naming aligns with the expected output. (PR [#166](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/166))
+
+* **Documentation**:
+ * User Guide:
+ * Added documentation for the features `schadd` and `schdel`. (PR [\#143](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/143))
+ * Added documentation for the feature `cedit`. (PR [\#242](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/242))
+ * Added information on duplicate client. (PR [\#230](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/230))
+ * Updated FAQ's contact us link and other potential query. (PR [#234](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/234))
+ * Proofread and fixed UG (includes fixing broken links and formatting). (PR [#173](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/173), [#163](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/163/files))
+ * Developer Guide:
+ * Added MSS and manual testing instructions for `schadd` and `schdel` feature. (PR [\#149](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/149))
+ * Added implementation details of the `schadd` feature. (PR [\#149](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/149))
+ * Updated the diagram of the `Storage` component. (PR [\#149](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/149))
+
+* **Review or mentoring contributions**:
+ * Regularly discuss design and implementation details with group mates.
+ * Discuss bugs and feature or enhancement proposals during team meeting, via group communication channels, or via issues. (example: [issue \#141](https://github.com/AY2021S1-CS2103T-T13-3/tp/issues/141), [issue \#174](https://github.com/AY2021S1-CS2103T-T13-3/tp/issues/174)).
+ * Review and comment on PRs regarding code quality (PR [#91](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/91)), implementation bug (PR [#226](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/226)), and other improvements.
+
+* **Community**:
+ * Asked questions in Gitter, one of which was about the convention of code integration.
+ * Beyond this team: reported bugs and suggestion for other team via CATcher (examples: PR [#188](https://github.com/AY2021S1-CS2103T-W17-3/tp/issues/188))
diff --git a/docs/team/kelvinvin.md b/docs/team/kelvinvin.md
new file mode 100644
index 00000000000..5d02ccd4b31
--- /dev/null
+++ b/docs/team/kelvinvin.md
@@ -0,0 +1,65 @@
+---
+layout: page
+title: Kelvin Wong's Project Portfolio Page
+---
+
+## Project: FitEgo
+
+FitEgo is a desktop application for fitness instructors to schedule, and keep track of his/her customers' progress and payments in one place.
+It is faster compared to manually tracking administrative matters using alternative software like Excel and Google Calendar. The user interacts with it using a CLI, and it has a GUI created with JavaFX.
+
+It is written in Java, and has about 23 kLoC.
+
+Given below are my contributions to the project.
+
+* **New Feature**: Added the ability to change view of Session List.
+ * What it does: allows the user to filter the Session List to only those that start within the requested period.
+ * Justification: This feature improves the product significantly because a user can now re-prioritise and update their timetable more conveniently.
+ * Highlights: This enhancement affects existing session-related and schedule-related commands. It required an in-depth analysis of design alternatives. The implementation too was challenging as it required changes to the Logic component.
+ * Credits: *Credits to teammates Tan Wei Jie for adding variable range ability and Maguire Ong for assisting with Ui-related matters of the Session List*
+
+* **New Feature**: Add Session List to RightSideBar.
+ * What it does: allows the user to view sessions, sorted by time, in one glance.
+ * Credits: *{Reused code from the Client List to implement Session List}*
+
+* **New Feature**: Added a weight unit utility class to facilitate conversion of units.
+ * What it does: allows the user to both input and output weight in terms of kilogram or pounds.
+ * Justification: This feature improves the product's usability significantly as it widens the user base to include anyone who uses Metric or Imperial systems.
+ * Highlights: This enhancement affects the existing weight-related commands and graph.
+ The implementation was challenging because it was built to reduce coupling with other classes and required usage of Observer pattern to enable dynamic updates.
+
+* **New Feature**: Added a Settings window.
+ * What it does: allows the user to quickly open a window to edit settings using F4 key / CLI. It also saves the changes in UserPrefs for the next time the user starts up.
+ * Justification: Currently used for weight unit but serves as a frame for any other editable settings to be added in future.
+ * Highlights: It necessitated the implementation of an additional user preference field.
+ * Credits: *Reused code from the Help window to implement the Settings window*
+
+* **Code contributed**: [RepoSense link](https://nus-cs2103-ay2021s1.github.io/tp-dashboard/#breakdown=true&search=kelvinvin&sort=groupTitle&sortWithin=title&since=2020-08-14&timeframe=commit&mergegroup=&groupSelect=groupByRepos&checkedFileTypes=docs~functional-code~test-code~other&until=2020-11-09&tabOpen=true&tabType=authorship&tabAuthor=kelvinvin&tabRepo=AY2021S1-CS2103T-T13-3%2Ftp%5Bmaster%5D&authorshipIsMergeGroup=false&authorshipFileTypes=docs~functional-code~test-code)
+
+* **Project management or Team-based tasks**:
+ * Managed timely updates of demo animations for each iteration [v1.2](https://imgur.com/a/loBT8Cb), [v1.3](https://hackmd.io/Eo7Gsii8RTWRlDLykD35LQ)
+ * Maintained [issue tracker](https://github.com/AY2021S1-CS2103T-T13-3/tp/issues)
+
+* **Enhancements to existing features**:
+ * Added wrap text to increase text readability for small resolutions. [\#218](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/218)
+ * Refactored Delete and List commands to equivalent Client commands. [\#56](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/56), [\#55](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/55)
+ * Added "Next Session" field in Client List to allow user to easily identify the earliest upcoming session with each client.
+
+* **Documentation**:
+ * User Guide:
+ * Added documentation for the features `sview`, `cdel` and `settings` [\#229](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/229), [\#171](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/171), [\#159](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/159)
+ * Made cosmetic tweaks to existing documentation of features `clear`, `exit`: [\#157](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/157)
+ * Proof read the document for the team to ensure accurate grammar and consistency of commonly used terms [\#157](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/157), [\#23](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/23)
+ * Created an annotated diagram of Ui components. [\#159](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/159)
+
+ * Developer Guide:
+ * Updated diagrams and description of the Logic component and `cdel` feature. [\#142](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/142)
+ * Added implementation details, UML diagrams and design considerations for the `sview` feature. [\#266](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/266), [\#256](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/256)
+ * Added captions for all figures.
+ * Added View Session's use case and instructions for manual testing [\#142](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/142)
+ * Added [\#249](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/249)
+
+* **Community**:
+ * PRs reviewed (with non-trivial review comments): [\#233](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/233), [\#159](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/159), [\#149](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/149), [\#153](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/153)
+ * Reported bugs and suggestions for Group [CS2103T-W10-1](https://ay2021s1-cs2103t-w10-1.github.io/tp/UserGuide.html) on CATcher.
+ * Integrated the tab pane in Client Info Page with Wei Jie and Bennett.
diff --git a/docs/team/maguireong.md b/docs/team/maguireong.md
new file mode 100644
index 00000000000..f8572781fa9
--- /dev/null
+++ b/docs/team/maguireong.md
@@ -0,0 +1,61 @@
+---
+layout: page
+title: Maguire Ong's Project Portfolio Page
+---
+
+## Project: FitEgo
+
+FitEgo is a desktop application for fitness instructors to schedule, and keep track of his/her customers' progress and payments in one place.
+It is faster compared to manually tracking administrative matters using alternative software like Excel and Google Calendar. The user interacts with it using a CLI, and it has a GUI created with JavaFX.
+
+It is written in Java, and has about 23 kLoC.
+
+Given below are my contributions to the project.
+
+* **New Feature**: Added the ability to edit a session created by the user. (Pull request [\#83](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/83))
+ * What it does: Allows the user to edit a session’s details like a session’s gym name, exercise type, start time and duration.
+ * Justification: This feature improves the product significantly because a client may have changes made to his/her workout session, therefore the app should provide a way to make changes to the session.
+ * Highlights: This enhancement affects existing commands and commands to be added in future. It required an in-depth analysis of design alternatives.
+ It builds the foundation for edit features in FitEgo. The implementation was challenging as it required changes to existing commands.
+
+* **New Feature**: Added the ability to edit a schedule created by the user. (Pull request [\#91](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/91))
+ * What it does: Allows the user to edit a schedule’s details like a schedule’s updated session index, payment status, remark and weight.
+ * Justification: This feature improves the product significantly because a user may have changes made to his schedules, therefore the app should provide a way to make update the changes to the schedule.
+ * Highlights: This enhancement was similar to the edit session feature. However, the implementation was slightly different form the edit session feature and more variations of parameters were added to this feature.
+ Much consideration was put into this implementation's design for ease of usage of this feature from the user's end, therefore more time was required to create this feature.
+ * Credits: Credits to teammates Bennett and Dhafin for adding additional parameters that can be edited in the feature.
+
+
+
+* **New Feature**: Added a dynamic header on the right side panel. (Pull requests [\#134](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/134), [\#138](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/138))
+ * What it does: Allows the user to have a better idea of the time period searched for when using the “Session View” function.
+ * Justification: This feature improves the product significantly because a user can better identify which time period it is referring to.
+ * Highlights: This enhancement affects existing commands and commands to be added in future.
+ It required an good understanding of JavaFX and how it relates to the logic in both Session List panel and the user's input.
+ The implementation too was challenging enough as a new user to JavaFX.
+
+* **Code contributed**: [RepoSense link](https://nus-cs2103-ay2021s1.github.io/tp-dashboard/#breakdown=true&search=maguireong&sort=groupTitle&sortWithin=title&since=2020-08-14&timeframe=commit&mergegroup=&groupSelect=groupByRepos&checkedFileTypes=docs~functional-code~test-code~other&tabOpen=true&tabType=authorship&tabAuthor=maguireong&tabRepo=AY2021S1-CS2103T-T13-3%2Ftp%5Bmaster%5D&authorshipIsMergeGroup=false&authorshipFileTypes=docs~functional-code~test-code&until=2020-11-09)
+
+* **Project management**:
+ * Necessary general code enhancements. e.g. Code Refactoring
+ * Maintain issue tracker.
+
+* **Enhancements to existing features**:
+ * Refactored code from Person to Client. (Pull request [\#45](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/45))
+
+* **Documentation**:
+ * User Guide:
+ * Added documentation for the features Add Client [\#45](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/45), Edit Session and Edit Schedule features. [\#153](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/153)
+ * Reformat User Guide to ensure consistency. [\#231](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/231), [\#267](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/267)
+
+ * Developer Guide:
+ * Added Use Case, UML diagrams, description and implementation details of the Edit Session and Edit Schedule features. [\#153](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/153)
+ * Reformat User Guide to ensure consistency. [\#231](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/231), [\#267](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/267)
+
+* **Review or mentoring contributions**:
+ * Discuss design and implementation details with group mates.
+ * PRs reviewed (with non-trivial review comments): [\#96](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/96), [\#139](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/139),
+ [\#137](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/137), [\#97](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/97)
+
+* **Community**:
+ * Reported bugs and suggestions for Group [CS2103T-W12-2](https://ay2021s1-cs2103t-w12-2.github.io/tp/UserGuide.html) on CATcher.
diff --git a/docs/team/tanweijie123.md b/docs/team/tanweijie123.md
new file mode 100644
index 00000000000..858c7ecd23b
--- /dev/null
+++ b/docs/team/tanweijie123.md
@@ -0,0 +1,67 @@
+---
+layout: page
+title: Tan Wei Jie's Project Portfolio Page
+---
+
+## Project: FitEgo
+
+FitEgo is a desktop application for fitness instructors to schedule, and keep track of his/her customers' progress and payments in one place.
+It is faster compared to manually tracking administrative matters using alternative software like Excel and Google Calendar. The user interacts with it using a CLI, and it has a GUI created with JavaFX.
+
+It is written in Java, and has about 23 kLoC.
+
+Given below are my contributions to the project.
+
+* **New Feature**: Added the ability to auto-complete commands while the user is typing. (Pull requests [\#99](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/99))
+ * What it does: allows the user to view the commands available in FitEgo during mid-typing, so that forgetful users can refer to it. Advanced users can also use the "TAB" key to lessen the typing.
+ * Justification: This feature makes it user-friendly because new users are guided to available commands, and advanced users can type lesser.
+ * Credits: ControlsFX library was used to display the available commands in a table-list format.
+
+* **New Feature**: Added the ability to warn users if their data file is not in the correct format (Pull requests [\#251](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/251))
+ * What it does: warns the user if FitEgo is unable to parse the data from the data file. Allows the user to exit immediately to prevent data file being overwritten.
+ * Justification: This feature protects the user's data file and prevents unrecoverable damages.
+
+* **New Feature**: Added the feature to track weight for every schedule (Pull requests [\#159](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/159))
+ * What it does: allows the user to store weight for every schedule. Then, the user can view the weight over time using a line chart.
+
+* **New Feature**: Added the feature to view client's full information (Pull requests [\#60](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/60), [\#77](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/77), [\#159](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/159))
+ * What it does: allows the user to view the client's profile, schedules, and weight over time.
+ * Justification: This feature allows the user to track the client's progress so that he does not have to utilise another software or perform calculations manually.
+ * Credits: With the help of Kelvin (adding different weight units) and Bennett (displaying all schedule related to the clients in a table), I had managed to integrate both of their work into a tab-pane.
+
+[comments]: <> (Added a history command that allows the user to navigate to previous commands using up/down keys. - PR#99)
+
+* **Enhancements to existing features**:
+ * Updated the Help Window, so that user do not have to manually open the browser (Pull requests [\#99](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/99))
+ * Updated the Mainpage of the GUI (Pull requests [\#77](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/77), [\#94](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/94))
+ * Changed the `AddressBookParser` class to use hashmap and functions (Pull requests [\#84](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/84))
+ * Changed `UniqueClientList` into generics (Pull requests [\#75](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/75))
+ * Modify `find` to include partial substring (Pull requests [\#54](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/54))
+ * Modify saving to storage to include `Session` objects (Pull requests [\#70](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/70), [\#71](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/71), [\#73](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/73))
+ * Modify sample data initialisation to use dynamic dates (Pull requests [\#159](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/159))
+
+* **Code contributed**: [RepoSense link](https://nus-cs2103-ay2021s1.github.io/tp-dashboard/#breakdown=true&search=T13-3&sort=groupTitle&sortWithin=title&since=2020-08-14&timeframe=commit&mergegroup=&groupSelect=groupByRepos&checkedFileTypes=functional-code&tabOpen=true&tabType=authorship&tabAuthor=tanweijie123&tabRepo=AY2021S1-CS2103T-T13-3%2Ftp%5Bmaster%5D&authorshipIsMergeGroup=false&authorshipFileTypes=docs~functional-code~test-code~other)
+
+* **Project management**:
+ * Added user stories into project issue trackers
+ * Changed FitEgo icon
+
+* **Documentation**:
+ * User Guide:
+ * Added documentation for the features `home`, `clist`, `cview` : [\#60](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/60)
+ * Made modifications to existing documentation of features `help`, `clear` and `cfind` : [\#151](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/151)
+ * Added documentation for "How to interpret notations" and "UI-orientation", and preface for client-, session- and schedule-related keywords : [\#151](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/151)
+
+ * Developer Guide:
+ * Updated the UI class diagram
+ * Added "View Client Weight's feature"
+ * Added user stories
+
+* **Community**:
+ * Assisted Kelvin with `sview` to provide flexible view range for users.
+ * With the help of Kelvin and Bennett, we integrated the weight and schedule related to clients into a tab-pane.
+ * Reported bugs and suggestions for other team members during weekly team meetings.
+
+* **Tools**:
+ * Integrated a third party library (ControlsFX) to the project ([\#99](https://github.com/AY2021S1-CS2103T-T13-3/tp/pull/99))
+ * Reported bugs and suggestions for Group [CS2103T-W11-1](https://ay2021s1-cs2103t-w11-1.github.io/tp/UserGuide.html) on CATcher.
diff --git a/docs/tutorials/AddRemark.md b/docs/tutorials/AddRemark.md
index 6907e29456c..e4ca89d7c62 100644
--- a/docs/tutorials/AddRemark.md
+++ b/docs/tutorials/AddRemark.md
@@ -28,7 +28,7 @@ package seedu.address.logic.commands;
import seedu.address.model.Model;
/**
- * Changes the remark of an existing person in the address book.
+ * Changes the remark of an existing Client in the address book.
*/
public class RemarkCommand extends Command {
@@ -64,8 +64,8 @@ Following the convention in other commands, we add relevant messages as constant
**`RemarkCommand.java`:**
``` java
- public static final String MESSAGE_USAGE = COMMAND_WORD + ": Edits the remark of the person identified "
- + "by the index number used in the last person listing. "
+ public static final String MESSAGE_USAGE = COMMAND_WORD + ": Edits the remark of the Client identified "
+ + "by the index number used in the last Client listing. "
+ "Existing remark will be overwritten by the input.\n"
+ "Parameters: INDEX (must be a positive integer) "
+ "r/ [REMARK]\n"
@@ -99,8 +99,8 @@ public class RemarkCommand extends Command {
private final String remark;
/**
- * @param index of the person in the filtered person list to edit the remark
- * @param remark of the person to be updated to
+ * @param index of the Client in the filtered Client list to edit the remark
+ * @param remark of the Client to be updated to
*/
public RemarkCommand(Index index, String remark) {
requireAllNonNull(index, remark);
@@ -222,11 +222,11 @@ If you are stuck, check out the sample
## Add `Remark` to the model
-Now that we have all the information that we need, let’s lay the groundwork for propagating the remarks added into the in-memory storage of person data. We achieve that by working with the `Person` model. Each field in a Person is implemented as a separate class (e.g. a `Name` object represents the person’s name). That means we should add a `Remark` class so that we can use a `Remark` object to represent a remark given to a person.
+Now that we have all the information that we need, let’s lay the groundwork for propagating the remarks added into the in-memory storage of Client data. We achieve that by working with the `Client` model. Each field in a Client is implemented as a separate class (e.g. a `Name` object represents the Client’s name). That means we should add a `Remark` class so that we can use a `Remark` object to represent a remark given to a Client.
### Add a new `Remark` class
-Create a new `Remark` in `seedu.address.model.person`. Since a `Remark` is a field that is similar to `Address`, we can reuse a significant bit of code.
+Create a new `Remark` in `seedu.address.model.Client`. Since a `Remark` is a field that is similar to `Address`, we can reuse a significant bit of code.
A copy-paste and search-replace later, you should have something like [this](https://github.com/se-edu/addressbook-level3/commit/4516e099699baa9e2d51801bd26f016d812dedcc#diff-af2f075d24dfcd333876f0fbce321f25). Note how `Remark` has no constrains and thus does not require input
validation.
@@ -237,11 +237,11 @@ Let’s change `RemarkCommand` and `RemarkCommandParser` to use the new `Remark`
## Add a placeholder element for remark to the UI
-Without getting too deep into `fxml`, let’s go on a 5 minute adventure to get some placeholder text to show up for each person.
+Without getting too deep into `fxml`, let’s go on a 5 minute adventure to get some placeholder text to show up for each Client.
-Simply add the following to [`seedu.address.ui.PersonCard`](https://github.com/se-edu/addressbook-level3/commit/850b78879582f38accb05dd20c245963c65ea599#diff-0c6b6abcfac8c205e075294f25e851fe).
+Simply add the following to [`seedu.address.ui.ClientCard`](https://github.com/se-edu/addressbook-level3/commit/850b78879582f38accb05dd20c245963c65ea599#diff-0c6b6abcfac8c205e075294f25e851fe).
-**`PersonCard.java`:**
+**`ClientCard.java`:**
``` java
@FXML
@@ -251,9 +251,9 @@ private Label remark;
`@FXML` is an annotation that marks a private or protected field and makes it accessible to FXML. It might sound like Greek to you right now, don’t worry — we will get back to it later.
-Then insert the following into [`main/resources/view/PersonListCard.fxml`](https://github.com/se-edu/addressbook-level3/commit/850b78879582f38accb05dd20c245963c65ea599#diff-12580431f55d7880578aa4c16f249e71).
+Then insert the following into [`main/resources/view/ClientListCard.fxml`](https://github.com/se-edu/addressbook-level3/commit/850b78879582f38accb05dd20c245963c65ea599#diff-12580431f55d7880578aa4c16f249e71).
-**`PersonListCard.fxml`:**
+**`ClientListCard.fxml`:**
``` xml
@@ -263,21 +263,21 @@ That’s it! Fire up the application again and you should see something like thi
-## Modify `Person` to support a `Remark` field
+## Modify `Client` to support a `Remark` field
-Since `PersonCard` displays data from a `Person`, we need to update `Person` to get our `Remark` displayed!
+Since `ClientCard` displays data from a `Client`, we need to update `Client` to get our `Remark` displayed!
-### Modify `Person`
+### Modify `Client`
-We change the constructor of `Person` to take a `Remark`. We will also need to define new fields and accessors accordingly to store our new addition.
+We change the constructor of `Client` to take a `Remark`. We will also need to define new fields and accessors accordingly to store our new addition.
-### Update other usages of `Person`
+### Update other usages of `Client`
-Unfortunately, a change to `Person` will cause other commands to break, you will have to modify these commands to use the updated `Person`!
+Unfortunately, a change to `Client` will cause other commands to break, you will have to modify these commands to use the updated `Client`!
-:bulb: Use the `Find Usages` feature in IntelliJ IDEA on the `Person` class to find these commands.
+:bulb: Use the `Find Usages` feature in IntelliJ IDEA on the `Client` class to find these commands.
@@ -286,7 +286,7 @@ Refer to [this commit](https://github.com/se-edu/addressbook-level3/commit/ce998
## Updating Storage
-AddressBook stores data by serializing `JsonAdaptedPerson` into `json` with the help of an external library — Jackson. Let’s update `JsonAdaptedPerson` to work with our new `Person`!
+AddressBook stores data by serializing `JsonAdaptedClient` into `json` with the help of an external library — Jackson. Let’s update `JsonAdaptedClient` to work with our new `Client`!
While the changes to code may be minimal, the test data will have to be updated as well.
@@ -301,16 +301,16 @@ to see what the changes entail.
## Finalizing the UI
-Now that we have finalized the `Person` class and its dependencies, we can now bind the `Remark` field to the UI.
+Now that we have finalized the `Client` class and its dependencies, we can now bind the `Remark` field to the UI.
Just add [this one line of code!](https://github.com/se-edu/addressbook-level3/commit/5b98fee11b6b3f5749b6b943c4f3bd3aa049b692)
-**`PersonCard.java`:**
+**`ClientCard.java`:**
``` java
-public PersonCard(Person person, int displayedIndex) {
+public ClientCard(Client Client, int displayedIndex) {
//...
- remark.setText(person.getRemark().value);
+ remark.setText(Client.getRemark().value);
}
```
@@ -322,41 +322,41 @@ After the previous step, we notice a peculiar regression — we went from di
### Update `RemarkCommand` and `RemarkCommandParser`
-In this last step, we modify `RemarkCommand#execute()` to change the `Remark` of a `Person`. Since all fields in a `Person` are immutable, we create a new instance of a `Person` with the values that we want and
-save it with `Model#setPerson()`.
+In this last step, we modify `RemarkCommand#execute()` to change the `Remark` of a `Client`. Since all fields in a `Client` are immutable, we create a new instance of a `Client` with the values that we want and
+save it with `Model#setClient()`.
**`RemarkCommand.java`:**
``` java
//...
- public static final String MESSAGE_ADD_REMARK_SUCCESS = "Added remark to Person: %1$s";
- public static final String MESSAGE_DELETE_REMARK_SUCCESS = "Removed remark from Person: %1$s";
+ public static final String MESSAGE_ADD_REMARK_SUCCESS = "Added remark to Client: %1$s";
+ public static final String MESSAGE_DELETE_REMARK_SUCCESS = "Removed remark from Client: %1$s";
//...
@Override
public CommandResult execute(Model model) throws CommandException {
- List lastShownList = model.getFilteredPersonList();
+ List lastShownList = model.getFilteredClientList();
if (index.getZeroBased() >= lastShownList.size()) {
- throw new CommandException(Messages.MESSAGE_INVALID_PERSON_DISPLAYED_INDEX);
+ throw new CommandException(Messages.MESSAGE_INVALID_Client_DISPLAYED_INDEX);
}
- Person personToEdit = lastShownList.get(index.getZeroBased());
- Person editedPerson = new Person(personToEdit.getName(), personToEdit.getPhone(), personToEdit.getEmail(),
- personToEdit.getAddress(), remark, personToEdit.getTags());
+ Client ClientToEdit = lastShownList.get(index.getZeroBased());
+ Client editedClient = new Client(ClientToEdit.getName(), ClientToEdit.getPhone(), ClientToEdit.getEmail(),
+ ClientToEdit.getAddress(), remark, ClientToEdit.getTags());
- model.setPerson(personToEdit, editedPerson);
- model.updateFilteredPersonList(PREDICATE_SHOW_ALL_PERSONS);
+ model.setClient(ClientToEdit, editedClient);
+ model.updateFilteredClientList(PREDICATE_SHOW_ALL_ClientS);
- return new CommandResult(generateSuccessMessage(editedPerson));
+ return new CommandResult(generateSuccessMessage(editedClient));
}
/**
* Generates a command execution success message based on whether the remark is added to or removed from
- * {@code personToEdit}.
+ * {@code ClientToEdit}.
*/
- private String generateSuccessMessage(Person personToEdit) {
+ private String generateSuccessMessage(Client ClientToEdit) {
String message = !remark.value.isEmpty() ? MESSAGE_ADD_REMARK_SUCCESS : MESSAGE_DELETE_REMARK_SUCCESS;
- return String.format(message, personToEdit);
+ return String.format(message, ClientToEdit);
}
```
diff --git a/docs/tutorials/RemovingFields.md b/docs/tutorials/RemovingFields.md
index aa8e0baaad9..2062bc9f2ba 100644
--- a/docs/tutorials/RemovingFields.md
+++ b/docs/tutorials/RemovingFields.md
@@ -7,9 +7,9 @@ title: "Tutorial: Removing Fields"
>
> — Antoine de Saint-Exupery
-When working on AddressBook, you will most likely find that some features and fields that are no longer necessary. In scenarios like this, you can consider refactoring the existing `Person` model to suit your use case.
+When working on AddressBook, you will most likely find that some features and fields that are no longer necessary. In scenarios like this, you can consider refactoring the existing `Client` model to suit your use case.
-In this tutorial, we’ll do exactly just that and remove the `address` field from `Person`.
+In this tutorial, we’ll do exactly just that and remove the `address` field from `Client`.
* Table of Contents
{:toc}
@@ -20,7 +20,7 @@ Fortunately, IntelliJ IDEA provides a robust refactoring tool that can identify
### Assisted refactoring
-The `address` field in `Person` is actually an instance of the `seedu.address.model.person.Address` class. Since removing the `Address` class will break the application, we start by identifying `Address`'s usages. This allows us to see code that depends on `Address` to function properly and edit them on a case-by-case basis. Right-click the `Address` class and select `Refactor` \> `Safe Delete` through the menu.
+The `address` field in `Client` is actually an instance of the `seedu.address.model.Client.Address` class. Since removing the `Address` class will break the application, we start by identifying `Address`'s usages. This allows us to see code that depends on `Address` to function properly and edit them on a case-by-case basis. Right-click the `Address` class and select `Refactor` \> `Safe Delete` through the menu.
@@ -28,11 +28,11 @@ Choose to `View Usages` and you should be presented with a list of `Safe Delete
-Remove usages of `Address` by performing `Safe Delete`s on each entry. You will need to exercise discretion when removing usages of `Address`. Functions like `ParserUtil#parseAddress()` can be safely removed but its usages must be removed as well. Other usages like in `EditPersonDescriptor` may require more careful inspection.
+Remove usages of `Address` by performing `Safe Delete`s on each entry. You will need to exercise discretion when removing usages of `Address`. Functions like `ParserUtil#parseAddress()` can be safely removed but its usages must be removed as well. Other usages like in `EditClientDescriptor` may require more careful inspection.
-Let’s try removing references to `Address` in `EditPersonDescriptor`.
+Let’s try removing references to `Address` in `EditClientDescriptor`.
-1. Safe delete the field `address` in `EditPersonDescriptor`.
+1. Safe delete the field `address` in `EditClientDescriptor`.
1. Select `Yes` when prompted to remove getters and setters.
@@ -43,7 +43,7 @@ Let’s try removing references to `Address` in `EditPersonDescriptor`.
- :bulb: **Tip:** Removing usages may result in errors. Exercise discretion and fix them. For example, removing the `address` field from the `Person` class will require you to modify its constructor.
+ :bulb: **Tip:** Removing usages may result in errors. Exercise discretion and fix them. For example, removing the `address` field from the `Client` class will require you to modify its constructor.
1. Repeat the steps for the remaining usages of `Address`
@@ -54,13 +54,13 @@ After you are done, verify that the application still works by compiling and run
Unfortunately, there are usages of `Address` that IntelliJ IDEA cannot identify. You can find them by searching for instances of the word `address` in your code (`Edit` \> `Find` \> `Find in path`).
-Places of interest to look out for would be resources used by the application. `main/resources` contains images and `fxml` files used by the application and `test/resources` contains test data. For example, there is a `$address` in each `PersonCard` that has not been removed nor identified.
+Places of interest to look out for would be resources used by the application. `main/resources` contains images and `fxml` files used by the application and `test/resources` contains test data. For example, there is a `$address` in each `ClientCard` that has not been removed nor identified.
-A quick look at the `PersonCard` class and its `fxml` file quickly reveals why it slipped past the automated refactoring.
+A quick look at the `ClientCard` class and its `fxml` file quickly reveals why it slipped past the automated refactoring.
-**`PersonCard.java`**
+**`ClientCard.java`**
``` java
...
@@ -69,7 +69,7 @@ private Label address;
...
```
-**`PersonCard.fxml`**
+**`ClientCard.fxml`**
``` xml
...
@@ -87,12 +87,12 @@ At this point, your application is working as intended and all your tests are pa
In `src/test/data/`, data meant for testing purposes are stored. While keeping the `address` field in the json files does not cause the tests to fail, it is not good practice to let cruft from old features accumulate.
-**`invalidPersonAddressBook.json`:**
+**`invalidClientAddressBook.json`:**
```json
{
- "persons": [ {
- "name": "Person with invalid name field: Ha!ns Mu@ster",
+ "clients": [ {
+ "name": "client with invalid name field: Ha!ns Mu@ster",
"phone": "9482424",
"email": "hans@example.com",
"address": "4th street"
diff --git a/docs/tutorials/TracingCode.md b/docs/tutorials/TracingCode.md
index bd34ed498cd..0102557efda 100644
--- a/docs/tutorials/TracingCode.md
+++ b/docs/tutorials/TracingCode.md
@@ -136,7 +136,7 @@ Recall from the User Guide that the `edit` command has the format: `edit INDEX [
:bulb: **Tip:** Sometimes you might end up stepping into functions that are not of interest. Simply `step out` of them\!
-1. The rest of the method seems to exhaustively check for the existence of each possible parameter of the `edit` command and store any possible changes in an `EditPersonDescriptor`. Recall that we can verify the contents of `editPersonDesciptor` through the `Variable` tool window.
+1. The rest of the method seems to exhaustively check for the existence of each possible parameter of the `edit` command and store any possible changes in an `EditClientDescriptor`. Recall that we can verify the contents of `editClientDesciptor` through the `Variable` tool window.
1. Let’s continue stepping through until we return to `LogicManager#execute()`.
@@ -152,14 +152,14 @@ Recall from the User Guide that the `edit` command has the format: `edit INDEX [
@Override
public CommandResult execute(Model model) throws CommandException {
...
- Person personToEdit = lastShownList.get(index.getZeroBased());
- Person editedPerson = createEditedPerson(personToEdit, editPersonDescriptor);
- if (!personToEdit.isSamePerson(editedPerson) && model.hasPerson(editedPerson)) {
- throw new CommandException(MESSAGE_DUPLICATE_PERSON);
+ Client ClientToEdit = lastShownList.get(index.getZeroBased());
+ Client editedClient = createEditedClient(ClientToEdit, editClientDescriptor);
+ if (!ClientToEdit.isSameClient(editedClient) && model.hasClient(editedClient)) {
+ throw new CommandException(MESSAGE_DUPLICATE_Client);
}
- model.setPerson(personToEdit, editedPerson);
- model.updateFilteredPersonList(PREDICATE_SHOW_ALL_PERSONS);
- return new CommandResult(String.format(MESSAGE_EDIT_PERSON_SUCCESS, editedPerson));
+ model.setClient(ClientToEdit, editedClient);
+ model.updateFilteredClientList(PREDICATE_SHOW_ALL_ClientS);
+ return new CommandResult(String.format(MESSAGE_EDIT_Client_SUCCESS, editedClient));
}
```
@@ -180,15 +180,15 @@ Recall from the User Guide that the `edit` command has the format: `edit INDEX [
* {@code JsonSerializableAddressBook}.
*/
public JsonSerializableAddressBook(ReadOnlyAddressBook source) {
- persons.addAll(
- source.getPersonList()
+ Clients.addAll(
+ source.getClientList()
.stream()
- .map(JsonAdaptedPerson::new)
+ .map(JsonAdaptedClient::new)
.collect(Collectors.toList()));
}
```
-1. It appears that a `JsonAdaptedPerson` is created for each `Person` and then added to the `JsonSerializableAddressBook`.
+1. It appears that a `JsonAdaptedClient` is created for each `Client` and then added to the `JsonSerializableAddressBook`.
1. We can continue to step through until we return to `MainWindow#executeCommand()`.
@@ -245,6 +245,6 @@ the given commands to find exactly what happens.
4. Add a new command
- 5. Add a new field to `Person`
+ 5. Add a new field to `Client`
6. Add a new entity to the address book
diff --git a/src/main/java/seedu/address/MainApp.java b/src/main/java/seedu/address/MainApp.java
index e5cfb161b73..f3118e12040 100644
--- a/src/main/java/seedu/address/MainApp.java
+++ b/src/main/java/seedu/address/MainApp.java
@@ -6,7 +6,15 @@
import java.util.logging.Logger;
import javafx.application.Application;
+import javafx.application.Platform;
+import javafx.scene.control.Alert;
+import javafx.scene.control.Button;
+import javafx.scene.control.ButtonBar;
+import javafx.scene.control.ButtonType;
+import javafx.scene.control.TextArea;
+import javafx.scene.layout.Region;
import javafx.stage.Stage;
+import javafx.stage.Window;
import seedu.address.commons.core.Config;
import seedu.address.commons.core.LogsCenter;
import seedu.address.commons.core.Version;
@@ -78,15 +86,35 @@ private Model initModelManager(Storage storage, ReadOnlyUserPrefs userPrefs) {
ReadOnlyAddressBook initialData;
try {
addressBookOptional = storage.readAddressBook();
- if (!addressBookOptional.isPresent()) {
+ if (addressBookOptional.isEmpty()) {
logger.info("Data file not found. Will be starting with a sample AddressBook");
}
initialData = addressBookOptional.orElseGet(SampleDataUtil::getSampleAddressBook);
} catch (DataConversionException e) {
logger.warning("Data file not in the correct format. Will be starting with an empty AddressBook");
+
+ //Create a Warning Notification
+ String title = "Data file corrupted";
+ String headerText = "Data file not in correct format. "
+ + "This could be caused by corrupted data from forced shut, or manually data modification. ";
+ String contentText = "To prevent overwriting your data, you are recommended to exit the program. "
+ + "Otherwise, FitEgo will be starting with a blank state";
+
+ Platform.runLater(() -> createAlertWithErrorMessage(title, headerText, contentText, e));
+
initialData = new AddressBook();
} catch (IOException e) {
logger.warning("Problem while reading from the file. Will be starting with an empty AddressBook");
+
+ //Create a Warning Notification
+ String title = "Unable to read from file";
+ String headerText = "Another software could be using the same file, "
+ + "or you do not have the read permission to this file.";
+ String contentText = "To prevent overwriting your data, you are recommended to exit the program. "
+ + "Otherwise, FitEgo will be starting with a blank state";
+
+ Platform.runLater(() -> createAlertWithErrorMessage(title, headerText, contentText, e));
+
initialData = new AddressBook();
}
@@ -169,6 +197,65 @@ protected UserPrefs initPrefs(UserPrefsStorage storage) {
public void start(Stage primaryStage) {
logger.info("Starting AddressBook " + MainApp.VERSION);
ui.start(primaryStage);
+
+ //get the first window and request focus
+ //if there is an error dialog, it will be focused, otherwise, FitEgo app will be focused.
+ Stage.getWindows().stream().filter(Window::isShowing).limit(1).forEach(Window::requestFocus);
+ }
+
+ /**
+ * Creates an alert window with the given title, header text, content text, and exception
+ */
+ private void createAlertWithErrorMessage(String title, String headerText, String contentText, Exception e) {
+ ButtonType exceptionMessage = new ButtonType("Show Technical Error Message", ButtonBar.ButtonData.OTHER);
+ ButtonType cont = new ButtonType("Continue with Empty Data", ButtonBar.ButtonData.OK_DONE);
+ ButtonType exit = new ButtonType("Exit and Review my data file", ButtonBar.ButtonData.CANCEL_CLOSE);
+
+ Alert alert = new Alert(Alert.AlertType.WARNING, "", exceptionMessage, cont, exit);
+ alert.setTitle(title);
+ alert.setHeaderText(headerText);
+ alert.setContentText(contentText);
+
+ //Deactivate focus on OK button
+ Button contButton = (Button) alert.getDialogPane().lookupButton(cont);
+ contButton.setDefaultButton(false);
+
+ //Activate focus on Exit button
+ Button exitButton = (Button) alert.getDialogPane().lookupButton(exit);
+ exitButton.setDefaultButton(true);
+
+ //Prevent alert from truncating
+ alert.getDialogPane().setMinHeight(Region.USE_PREF_SIZE);
+ Stage alertStage = (Stage) alert.getDialogPane().getScene().getWindow();
+
+ //set focus to always be on top
+ alertStage.setAlwaysOnTop(true);
+
+ //Perform user action
+ Optional result = alert.showAndWait();
+ if (result.orElse(exit) == exit) { //default to exit
+ Platform.exit();
+ } else if (result.get() == exceptionMessage) {
+ createExceptionDialog(e);
+ createAlertWithErrorMessage(title, headerText, contentText, e); //re-open dialog. potential stack overflow
+ }
+ }
+
+ /**
+ * Displays an Error Dialog with the given exception.
+ */
+ private void createExceptionDialog(Exception e) {
+ Alert alert = new Alert(Alert.AlertType.ERROR);
+ alert.setTitle("Exception Dialog");
+ alert.setHeaderText(e.getClass().getSimpleName());
+ alert.setContentText("This error might be caused by corrupted data file.");
+
+ TextArea textArea = new TextArea(e.getMessage());
+ textArea.setEditable(false);
+ textArea.setWrapText(true);
+
+ alert.getDialogPane().setExpandableContent(textArea);
+ alert.showAndWait();
}
@Override
diff --git a/src/main/java/seedu/address/commons/core/GuiSettings.java b/src/main/java/seedu/address/commons/core/GuiSettings.java
index ba33653be67..870300d6fe3 100644
--- a/src/main/java/seedu/address/commons/core/GuiSettings.java
+++ b/src/main/java/seedu/address/commons/core/GuiSettings.java
@@ -10,8 +10,8 @@
*/
public class GuiSettings implements Serializable {
- private static final double DEFAULT_HEIGHT = 600;
- private static final double DEFAULT_WIDTH = 740;
+ private static final double DEFAULT_HEIGHT = 768;
+ private static final double DEFAULT_WIDTH = 1280;
private final double windowWidth;
private final double windowHeight;
diff --git a/src/main/java/seedu/address/commons/core/Messages.java b/src/main/java/seedu/address/commons/core/Messages.java
index 1deb3a1e469..8284d5f5436 100644
--- a/src/main/java/seedu/address/commons/core/Messages.java
+++ b/src/main/java/seedu/address/commons/core/Messages.java
@@ -7,7 +7,9 @@ public class Messages {
public static final String MESSAGE_UNKNOWN_COMMAND = "Unknown command";
public static final String MESSAGE_INVALID_COMMAND_FORMAT = "Invalid command format! \n%1$s";
- public static final String MESSAGE_INVALID_PERSON_DISPLAYED_INDEX = "The person index provided is invalid";
- public static final String MESSAGE_PERSONS_LISTED_OVERVIEW = "%1$d persons listed!";
+ public static final String MESSAGE_INVALID_CLIENT_DISPLAYED_INDEX = "The client index provided is invalid";
+ public static final String MESSAGE_INVALID_SESSION_DISPLAYED_INDEX = "The session index provided is invalid";
+ public static final String MESSAGE_INVALID_SCHEDULE_DISPLAYED_INDEX = "The schedule index provided is invalid";
+ public static final String MESSAGE_CLIENTS_LISTED_OVERVIEW = "%1$d clients listed!";
}
diff --git a/src/main/java/seedu/address/commons/util/StringUtil.java b/src/main/java/seedu/address/commons/util/StringUtil.java
index 61cc8c9a1cb..94d90caf36e 100644
--- a/src/main/java/seedu/address/commons/util/StringUtil.java
+++ b/src/main/java/seedu/address/commons/util/StringUtil.java
@@ -38,6 +38,29 @@ public static boolean containsWordIgnoreCase(String sentence, String word) {
.anyMatch(preppedWord::equalsIgnoreCase);
}
+ /**
+ * Returns true if the {@code sentence} contains a part of the {@code word}.
+ * Ignores case, and matching by substring.
+ * An empty string search will return true
+ * examples:
+ 
+
-[[homepage](http://www.comp.nus.edu.sg/~damithch)]
-[[github](https://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](https://github.com/dhafinrazaq)] [[Project Portfolio Page (PPP)](team/dhafinrazaq)]
-* Role: Project Advisor
+#### Developer & Deliverables in-charge
-### Jane Doe
+* Ensure project deliverables are done on time and in the right format.
-
-* Role: Team Lead
-* Responsibilities: UI
+[[github](https://github.com/benclmnt)] [[Project Portfolio Page (PPP)](team/benclmnt)]
-### Johnny Doe
+#### Developer & Code Quality in-charge
-
-### Jean Doe
+[[github](http://github.com/maguireong)] [[Project Portfolio Page (PPP)](team/maguireong)]
-
+
+[[github](http://github.com/kelvinvin)] [[Project Portfolio Page (PPP)](team/kelvinvin)]
+
+#### Developer & Documentation in-charge
+
+* Responsible for the quality of various project documents.
+
+---
-* Role: Developer
-* Responsibilities: Dev Ops + Threading
+### Tan Wei Jie
-### James Doe
+
-
+ 
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+