diff --git a/.gitignore b/.gitignore
index 284c4ca7cd9..2f4ae79d69a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,11 +10,13 @@ src/main/resources/docs/
# Storage/log files
/data/
+/bin/
/config.json
/preferences.json
/*.log.*
hs_err_pid[0-9]*.log
+
# Test sandbox files
src/test/data/sandbox/
diff --git a/README.md b/README.md
index 13f5c77403f..e4b0a0bfd52 100644
--- a/README.md
+++ b/README.md
@@ -1,14 +1,16 @@
-[](https://github.com/se-edu/addressbook-level3/actions)
+[](https://github.com/AY2324S2-CS2103T-W13-1/tp/actions)
+
+[](https://codecov.io/gh/AY2324S2-CS2103T-W13-1/tp)
-* This is **a sample project for Software Engineering (SE) students**.
+* This is **LoanGuard Pro, an application that helps business owners manage clients and their loan details**.
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.
+ * to keep track of the items you have loaned out
+ * to view your history of loans by client
+* The project builds on an existing Address Book used for managing contact details, **adding in a loan tracker functionality**.
+ * It is **written in OOP fashion**.
* 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.
+* It is named `LoanGuard Pro` because it represents a more powerful version of an address book, that can also manage the loans of your contacts.
+* For the detailed documentation of this project, see the **[LoanGuard Pro Product Website](https://ay2324s2-cs2103t-w13-1.github.io/tp/)**.
+* This project is based on the AddressBook-Level3 project created by the [SE-EDU initiative](https://se-education.org).
diff --git a/build.gradle b/build.gradle
index a2951cc709e..8d5f0dd6d33 100644
--- a/build.gradle
+++ b/build.gradle
@@ -4,6 +4,7 @@ plugins {
id 'com.github.johnrengelman.shadow' version '7.1.2'
id 'application'
id 'jacoco'
+ id 'org.jetbrains.kotlin.jvm' version '1.9.21'
}
mainClassName = 'seedu.address.Main'
@@ -63,10 +64,25 @@ dependencies {
testImplementation group: 'org.junit.jupiter', name: 'junit-jupiter-api', version: jUnitVersion
testRuntimeOnly group: 'org.junit.jupiter', name: 'junit-jupiter-engine', version: jUnitVersion
+ implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
}
shadowJar {
archiveFileName = 'addressbook.jar'
}
+run {
+ enableAssertions = true
+}
+
defaultTasks 'clean', 'test'
+compileKotlin {
+ kotlinOptions {
+ jvmTarget = "11"
+ }
+}
+compileTestKotlin {
+ kotlinOptions {
+ jvmTarget = "11"
+ }
+}
diff --git a/docs/AboutUs.md b/docs/AboutUs.md
index 1c9514e966a..41ed704fe65 100644
--- a/docs/AboutUs.md
+++ b/docs/AboutUs.md
@@ -9,51 +9,57 @@ You can reach us at the email `seer[at]comp.nus.edu.sg`
## Project team
-### John Doe
+### Khor Jun Wei
-
+
-[[homepage](http://www.comp.nus.edu.sg/~damithch)]
-[[github](https://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](https://github.com/kjw142857)]
+[[portfolio](https://github.com/kjw142857)]
-* Role: Project Advisor
+* Role: Developer for basic loan implementation + debugging and testing.
+* Responsibilities: Implementing the `linkloan` and `editloan` commands;
+finding bugs and pushing fixes; writing test code.
-### Jane Doe
+### Kyal Sin Min Thet
-
+
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](http://github.com/marcus-ny)]
+[[portfolio](http://github.com/marcus-ny)]
-* Role: Team Lead
-* Responsibilities: UI
+* Role: Team Lead + Frontend.
+* Responsibilities: setting up repo + CI workflow;
+Implementing view options for different panels - loans, contacts, analytics dashboards.
-### Johnny Doe
+### Teoh Tze Tzun
-
+
-[[github](http://github.com/johndoe)] [[portfolio](team/johndoe.md)]
+[[github](https://github.com/Joseph31416)] [[portfolio](https://github.com/Joseph31416)]
-* Role: Developer
-* Responsibilities: Data
+* Role: Developer for data classes and UG documentation.
+* Responsibilities:
+Implementing the `Loan`, `LoanRecords` (now refactored as `UniqueLoanList`) and `Analytics` classes from scratch;
+writing the user guide.
-### Jean Doe
+### Wang Junwu
-
+
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](http://github.com/narwhalsilent)]
+[[portfolio](http://github.com/narwhalsilent)]
-* Role: Developer
-* Responsibilities: Dev Ops + Threading
+* Role: Developer for loan architecture and UI integration + DG documentation.
+* Responsibilities: Implementing loan architecture as `UniqueLoanList` in the `Model`;
+implementing the `viewloan` command;
+writing the developer guide.
-### James Doe
+### Zhang Xiaorui
-
+
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](https://github.com/xiaorui-ui)]
+[[portfolio](https://github.com/xiaorui-ui)]
-* Role: Developer
-* Responsibilities: UI
+* Role: Developer for basic loan management and DG documentation.
+* Responsibilities: Implementing `deleteloan`, `markloan`, and `unmarkloan` commands; writing the developer guide.
diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md
index 1b56bb5d31b..4c74b50ec53 100644
--- a/docs/DeveloperGuide.md
+++ b/docs/DeveloperGuide.md
@@ -2,14 +2,59 @@
layout: page
title: Developer Guide
---
-* Table of Contents
-{:toc}
+
+[//]: <> (comment, To-do, make working links)
+[//]: <> (more To-dos: Instructions for Manual Testing, Appendix: Effort, Planned Enhancements)
+
+## Table of Contents
+[1. Acknowledgements](#acknowledgements)
+[2. Setting up, getting started](#setting-up-getting-started)
+[3. Design](#design)
+- [3.1 Architecture](#architecture)
+- [3.2 UI component](#ui-component)
+- [3.3 Logic component](#logic-component)
+- [3.4 Model component](#model-component)
+- [3.5 Storage component](#storage-component)
+- [3.6 Common classes](#common-classes)
+
+[4. Enhancements Added](#enhancements-added)
+- [4.1 Loan Analytics - Joseph](#loan-analytics---joseph)
+- [4.2 Delete Loan - Xiaorui](#delete-loan---xiaorui)
+- [4.3 Loan view command - Wang Junwu](#loan-view-command---wang-junwu)
+- [4.4 Loan view GUI - Kyal Sin Min Thet](#loan-view-gui---kyal-sin-min-thet)
+- [4.5 Linking a loan - Khor Jun Wei](#linking-a-loan---khor-jun-wei)
+
+[5. Documentation, logging, testing, configuration, dev-ops](#documentation-logging-testing-configuration-dev-ops)
+[6. Appendix: Requirements](#appendix-requirements)
+
+- [6.1 Product scope](#product-scope)
+- [6.2 User stories](#user-stories)
+- [6.3 Use cases](#use-cases)
+- [6.4 Non-Functional Requirements](#non-functional-requirements)
+
+[7. Appendix: Instructions for manual testing](#appendix-instructions-for-manual-testing)
+- [7.1 Launch and shutdown](#launch-and-shutdown)
+- [7.2 Deleting a person](#deleting-a-person)
+- [7.3 Linking a loan](#linking-a-loan)
+- [7.4 Viewing loans](#viewing-loans)
+- [7.5 Marking and unmarking a loan](#marking-and-unmarking-a-loan)
+- [7.6 Editing a loan](#editing-a-loan)
+- [7.7 Deleting a loan](#deleting-a-loan)
+- [7.8 Analytics Command](#analytics-command)
+- [7.9 Saving data](#saving-data)
+- [7.10 Exiting the app](#exiting-the-app)
+
+[8. Appendix: Effort](#appendix-effort)
+[9. Appendix: Planned Enhancements](#appendix-planned-enhancements)
+[10. Glossary](#glossary)
+
--------------------------------------------------------------------------------------------------------------------
## **Acknowledgements**
-* {list here sources of all reused/adapted ideas, code, documentation, and third-party libraries -- include links to the original source as well}
+This project is modified upon the [AddressBook-Level3 project](https://github.com/se-edu/addressbook-level3) project created by the SE-EDU initiative,
+as well as the [tutorials](https://nus-cs2103-ay2021s1.github.io/tp/tutorials/AddRemark.html) and guides provided.
--------------------------------------------------------------------------------------------------------------------
@@ -23,7 +68,9 @@ Refer to the guide [_Setting up and getting started_](SettingUp.md).
-:bulb: **Tip:** The `.puml` files used to create diagrams in this document `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 `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.
### Architecture
@@ -36,7 +83,11 @@ Given below is a quick overview of main components and how they interact with ea
**Main components of the architecture**
-**`Main`** (consisting of classes [`Main`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/Main.java) and [`MainApp`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/MainApp.java)) is in charge of the app launch and shut down.
+**`Main`** (consisting of
+classes [`Main`](https://github.com/AY2324S2-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/Main.java)
+and [`MainApp`](https://github.com/AY2324S2-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/MainApp.java)) is
+in charge of the app launch and shut down.
+
* At app launch, it initializes the other components in the correct sequence, and connects them up with each other.
* At shut down, it shuts down the other components and invokes cleanup methods where necessary.
@@ -51,16 +102,21 @@ The bulk of the app's work is done by the following four components:
**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 `delete 1`.
Each of the four main components (also shown in the diagram above),
* defines its *API* in an `interface` with the same name as the Component.
-* implements its functionality using a concrete `{Component Name}Manager` class (which follows the corresponding API `interface` mentioned in the previous point.
+* implements its functionality using a concrete `{Component Name}Manager` class (which follows the corresponding
+ API `interface` mentioned in the previous point.
-For example, the `Logic` component defines its API in the `Logic.java` interface and implements its functionality using the `LogicManager.java` class which follows the `Logic` interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent outside component's being coupled to the implementation of a component), as illustrated in the (partial) class diagram below.
+For example, the `Logic` component defines its API in the `Logic.java` interface and implements its functionality using
+the `LogicManager.java` class which follows the `Logic` interface. Other components interact with a given component
+through its interface rather than the concrete class (reason: to prevent outside component's being coupled to the
+implementation of a component), as illustrated in the (partial) class diagram below.
@@ -68,30 +124,45 @@ The sections below give more details of each component.
### UI component
-The **API** of this component is specified in [`Ui.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/Ui.java)
+The **API** of this component is specified
+in [`Ui.java`](https://github.com/AY2324S2-CS2103T-W13-1/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 which captures the commonalities between classes that represent parts of the visible GUI.
-
-The `UI` component uses the JavaFx UI framework. The layout of these UI parts are defined in matching `.fxml` files that are in the `src/main/resources/view` folder. For example, the layout of the [`MainWindow`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/MainWindow.java) is specified in [`MainWindow.fxml`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/resources/view/MainWindow.fxml)
+The UI consists of a `MainWindow` that has three different views. Each view consists of parts which
+inherit from the abstract `UiPart` class which captures the commonalities between classes that represent parts of the
+visible GUI.
+1. The **person tab view** is made up of four parts:
+`CommandBox`, `ResultDisplay`, `PersonListPanel`, `StatusBarFooter`.
+2. The **loan tab view** is made up of four parts:
+`CommandBox`, `ResultDisplay`, `LoanListPanel`, `StatusBarFooter`.
+3. The **analytics tab view** is made up of four parts:
+`CommandBox`, `ResultDisplay`, `AnalyticsPanel`, `StatusBarFooter`.
+
+The `UI` component uses the JavaFx UI framework. The layout of these UI parts are defined in matching `.fxml` files that
+are in the `src/main/resources/view` folder. For example, the layout of
+the [`MainWindow`](https://github.com/AY2324S2-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/ui/MainWindow.java)
+is specified
+in [`MainWindow.fxml`](https://github.com/AY2324S2-CS2103T-W13-1/tp/tree/master/src/main/resources/view/MainWindow.fxml)
The `UI` component,
-* executes user commands using the `Logic` component.
+* executes user commands using the `Logic` component, which could switch between the different views.
* listens for changes to `Model` data so that the UI can be updated with the modified data.
* keeps a reference to the `Logic` component, because the `UI` relies on the `Logic` to execute commands.
-* depends on some classes in the `Model` component, as it displays `Person` object residing in the `Model`.
+* depends on some classes in the `Model` component,
+as it displays `Person`, `Loan` and `Analytics` object residing in the `Model`.
### Logic component
-**API** : [`Logic.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/logic/Logic.java)
+**API** : [`Logic.java`](https://github.com/AY2324S2-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/logic/Logic.java)
Here's a (partial) class diagram of the `Logic` component:
-The sequence diagram below illustrates the interactions within the `Logic` component, taking `execute("delete 1")` API call as an example.
+The sequence diagram below illustrates the interactions within the `Logic` component, taking `execute("delete 1")` API
+call as an example.
@@ -100,10 +171,13 @@ The sequence diagram below illustrates the interactions within the `Logic` compo
How the `Logic` component works:
-1. When `Logic` is called upon to execute a command, it is passed to an `AddressBookParser` object which in turn creates a parser that matches the command (e.g., `DeleteCommandParser`) and uses it to parse the command.
-1. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `DeleteCommand`) which is executed by the `LogicManager`.
+1. When `Logic` is called upon to execute a command, it is passed to an `AddressBookParser` object which in turn creates
+ a parser that matches the command (e.g., `DeleteCommandParser`) and uses it to parse the command.
+1. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `DeleteCommand`) which
+ is executed by the `LogicManager`.
1. The command can communicate with the `Model` when it is executed (e.g. to delete a person).
- Note that although this is shown as a single step in the diagram above (for simplicity), in the code it can take several interactions (between the command object and the `Model`) to achieve.
+ Note that although this is shown as a single step in the diagram above (for simplicity), in the code it can take
+ several interactions (between the command object and the `Model`) to achieve.
1. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`.
Here are the other classes in `Logic` (omitted from the class diagram above) that are used for parsing a user command:
@@ -111,11 +185,17 @@ Here are the other classes in `Logic` (omitted from the class diagram above) tha
How the parsing works:
-* When called upon to parse a user command, the `AddressBookParser` class creates an `XYZCommandParser` (`XYZ` is a placeholder for the specific command name e.g., `AddCommandParser`) which uses the other classes shown above to parse the user command and create a `XYZCommand` object (e.g., `AddCommand`) which the `AddressBookParser` returns back as a `Command` object.
-* All `XYZCommandParser` classes (e.g., `AddCommandParser`, `DeleteCommandParser`, ...) inherit from the `Parser` interface so that they can be treated similarly where possible e.g, during testing.
+
+* When called upon to parse a user command, the `AddressBookParser` class creates an `XYZCommandParser` (`XYZ` is a
+ placeholder for the specific command name e.g., `AddCommandParser`) which uses the other classes shown above to parse
+ the user command and create a `XYZCommand` object (e.g., `AddCommand`) which the `AddressBookParser` returns back as
+ a `Command` object.
+* All `XYZCommandParser` classes (e.g., `AddCommandParser`, `DeleteCommandParser`, ...) inherit from the `Parser`
+ interface so that they can be treated similarly where possible e.g, during testing.
### Model component
-**API** : [`Model.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/model/Model.java)
+
+**API** : [`Model.java`](https://github.com/AY2324S2-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/model/Model.java)
@@ -123,9 +203,18 @@ How the parsing works:
The `Model` component,
* stores the address book data i.e., all `Person` objects (which are contained in a `UniquePersonList` object).
-* stores the currently 'selected' `Person` objects (e.g., results of a search query) as a separate _filtered_ list which is exposed to outsiders as an unmodifiable `ObservableList` that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.
-* stores a `UserPref` object that represents the user’s preferences. This is exposed to the outside as a `ReadOnlyUserPref` objects.
-* does not depend on any of the other three components (as the `Model` represents data entities of the domain, they should make sense on their own without depending on other components)
+* stores the loan records data i.e., all `Loan` objects (which are contained in a `UniqueLoanList` object).
+* stores the currently 'selected' `Person` objects (e.g., results of a search query) as a separate _filtered_ list which
+ is exposed to outsiders as an unmodifiable `ObservableList` that can be 'observed' e.g. the UI can be bound to
+ this list so that the UI automatically updates when the data in the list change.
+* stores the currently 'selected' `Loan` objects (e.g., results of a view loan command) as a separate
+ _filtered_ and _sorted_ list which
+ is exposed to outsiders as an unmodifiable `ObservableList` that can be 'observed' e.g. the UI can be bound to
+ this list so that the UI automatically updates when the data in the list change.
+* stores a `UserPref` object that represents the user’s preferences. This is exposed to the outside as
+ a `ReadOnlyUserPref` objects.
+* does not depend on any of the other three components (as the `Model` represents data entities of the domain, they
+ should make sense on their own without depending on other components)
: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` objects.
@@ -133,116 +222,255 @@ The `Model` component,
-
### 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/AY2324S2-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/storage/Storage.java)
The `Storage` component,
-* can save both address book data and user preference data in JSON format, and read them back into corresponding objects.
-* inherits from both `AddressBookStorage` and `UserPrefStorage`, which means it can be treated as either one (if only the functionality of only one is needed).
-* depends on some classes in the `Model` component (because the `Storage` component's job is to save/retrieve objects that belong to the `Model`)
+
+* can save both address book data and user preference data in JSON format, and read them back into corresponding
+ objects.
+* inherits from both `AddressBookStorage` and `UserPrefStorage`, which means it can be treated as either one (if only
+ the functionality of only one is needed).
+* depends on some classes in the `Model` component (because the `Storage` component's job is to save/retrieve objects
+ that belong to the `Model`)
### Common classes
Classes used by multiple components are in the `seedu.addressbook.commons` package.
---------------------------------------------------------------------------------------------------------------------
+## Enhancements Added
-## **Implementation**
+[//]: <> (change it to the analytics function)
-This section describes some noteworthy details on how certain features are implemented.
+### Loan Analytics - Joseph
-### \[Proposed\] Undo/redo feature
+#### Implementation
-#### Proposed Implementation
+The `Analytics` class handles the analysis of a `ObservableList` object.
+This class can only be instantiated by calling the static method `getAnalytics(ObservableList loanList)`.
-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:
+It contains the following fields that can prove to be useful for the user:
-* `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.
+* `numLoans`: total number of loans
+* `numOverdueLoans`: total number of overdue loans
+* `numActiveLoans`: total number of active loans
+* `propOverdueLoans`: proportion of loans that are overdue over active loans
+* `propActiveLoans`: proportion of loans that are active over total loans
+* `totalValueLoaned`: total value of all loans
+* `totalValueOverdue`: total value of all overdue loans
+* `totalValueActive`: total value of all active loans
+* `averageLoanValue`: average loan value of all loans
+* `averageOverdueValue`: average loan value of all overdue loans
+* `averageActiveValue`: average loan value of all active loans
+* `earliestLoanDate`: earliest loan date of all loans
+* `earliestReturnDate`: earliest return date of active loans
+* `latestLoanDate`: latest loan date of all loans
+* `latestReturnDate`: latest return date of active loans
-These operations are exposed in the `Model` interface as `Model#commitAddressBook()`, `Model#undoAddressBook()` and `Model#redoAddressBook()` respectively.
+The `AnalyticsCommand` class handles the viewing of analytics of any one person within the current contact list in view.
+The following shows how the analytics class is used in the execution of a command to view the analytics of a person:
+
-Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.
+#### Design considerations:
-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.
+##### Aspect: Initialization of the Analytics object:
-
+* **Alternative 1 (current choice):** Initialize the Analytics class using a factory method.
+ * Pros: Hide the constructor from the user, ensure that fields are initialized correctly, more defensive.
+ * Cons: Slightly more complex than a public constructor.
-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.
+* **Alternative 2:** Initialize the Analytics class using a public constructor.
+ * Pros: More straightforward to use.
+ * Cons: User may not initialize the fields correctly, less defensive.
-
+##### Aspect: What fields to include in the analytics:
-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`.
+* **Alternative 1 (current choice):** Include all fields.
+ * Pros: Satisfy 'ask, don't tell' principle.
+ * Cons: Possibly result in redundant information for the GUI developer.
-
+* **Alternative 2:** Include only raw data (e.g. total number of loans, total value of all loans).
+ * Pros: No redundant information.
+ * Cons: GUI developer has to calculate the analytics themselves, violating 'ask, don't tell' principle.
-
: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`.
+### Delete Loan - Xiaorui
-
+#### Implementation
-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.
+The `DeleteLoanCommand` class handles the deletion of a loan from the current contact in view, and executes the command
+after the input is parsed and transformed into an appropriate format.
+The parsing of the command is done by the `DeleteLoanCommandParser` class, which is responsible for parsing the user
+input.
-
+The `DeleteLoanCommand` class is instantiated in the `DeleteLoanCommandParser` class, while the
+`DeleteLoanCommandParser` is instantiated in the `AddressBookParser` class. Both classes are instantiated when the user
+enters a `deleteloan` command, which needs to be of the format `deleteloan INDEX`
+where INDEX is the index of the loan to be deleted (which is a positive whole number).
-
: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 `DeleteLoanCommand` class contains the following fields which can prove to be useful for the user:
-
+* `loanIndex`: the index of the loan to be deleted
+* Several string fields that are displayed to the user under different scenarios.
-The following sequence diagram shows how an undo operation goes through the `Logic` component:
+The `DeleteLoanCommandParser` class does not contain any fields.
-
+Sequence diagram for the deletion of a loan:
-
: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.
+
-
+#### Design considerations:
-Similarly, how an undo operation goes through the `Model` component is shown below:
+##### Aspect: How the command is executed:
-
+* **Alternative 1 (current choice):** The `DeleteLoanCommand` class is responsible for executing the command only.
+ * Pros: Follows the Single Responsibility Principle. Simpler to debug.
+ * Cons: May result in more classes.
+* **Alternative 2:** The `LogicManager` class is responsible for executing the command.
+ * Pros: More centralized command execution.
+ * Cons: May result in the `LogicManager` class becoming too large. This also goes against various SWE principles,
+ and makes the code harder to maintain.
-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.
+##### Aspect: How the command is parsed:
-
: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.
+* **Alternative 1 (current choice):** The `DeleteLoanCommandParser` class is responsible for parsing the command.
+ * Pros: Follows the Single Responsibility Principle. Simpler to debug.
+ * Cons: May result in more classes.
+* **Alternative 2:** The `AddressBookParser` class is responsible for parsing the command.
+ * Pros: More centralized command parsing.
+ * Cons: May result in the `AddressBookParser` class becoming too large. This also goes against various SWE
+ principles, and makes the code harder to maintain.
-
+### Loan view command - Wang Junwu
-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.
+#### Implementation
-
+The `ViewLoanCommand` class handles the viewing of all loans attached to a contact, and executes the command after the
+input is parsed and transformed into an appropriate format.
+The parsing of the command is done by the `ViewLoanCommandParser` class,
+which is responsible for parsing the user input.
-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.
+The `ViewLoanCommand` class is instantiated in the `ViewLoanCommandParser` class, while the
+`ViewLoanCommandParser` is instantiated in the `AddressBookParser` class. Both classes are instantiated when the user
+enters a `viewloan` command, which needs to be of the format `viewloan INDEX`
+where INDEX is the index of the person whose loans are to be viewed, a positive whole number.
-
+The `ViewLoanCommand` class contains the following fields which can prove to be useful for the user:
+* `targetIndex`: the index of the person whose loans are to be viewed
+* Some string fields that are displayed to the user under different scenarios.
-The following activity diagram summarizes what happens when a user executes a new command:
+The `ViewLoanCommandParser` class does not contain any fields.
-
+Sequence diagram for the viewing of loans:
+
#### Design considerations:
-**Aspect: How undo & redo executes:**
+##### Aspect: How the loan list is accessed:
+
+* **Alternative 1 (current choice):** The `ViewLoanCommand.execute()` method sequentially obtains the person list,
+the person, and then the loan list.
+ * Pros: Minimises the layers of methods to follow through.
+ * Cons: May violate the SLAP principle and the Law of Demeter.
+* **Alternative 2:** The `ViewLoanCommand.execute()` method obtains the loan list directly from the `Model`.
+ * Pros: Follows the SLAP principle and the Law of Demeter. Better use of abstraction.
+ * Cons: May result in longer method chains.
+
+##### Aspect: How the command is parsed:
+
+* **Alternative 1 (current choice):** The `ViewLoanCommandParser` class is responsible for parsing the command.
+ * Pros: Follows the Single Responsibility Principle. Simpler to debug.
+ * Cons: May result in more classes.
+* **Alternative 2:** The `AddressBookParser` class is responsible for parsing the command.
+ * Pros: More centralized command parsing.
+ * Cons: May result in the `AddressBookParser` class becoming too large. This also goes against various SWE
+ principles
+ ,and makes the code harder to maintain.
+
+### Loan view GUI - Kyal Sin Min Thet
+
+#### Implementation
+
+The GUI component to display loans attached to a contact is implemented in tandem with the `viewloan` command.
+
+The update behaviour is achieved through the use of `ObservableList` objects in the `Model` component. The `MainWindow`
+component listens for changes in the `ObservableList` objects and updates the GUI accordingly.
+
+The `LoanListPanel` (similar to `PersonListPanel`) is responsible for displaying the list of loans attached to a
+contact. It generates new `LoanCard` objects according to the `loanList` in the `Model` class.
+To accommodate the new GUI component, the `MainWindow.java` file is updated to include the new `LoanListPanel`.
+
+To ensure that only either the loan list or the person list is displayed, an additional `BooleanProperty` is added to
+the `Model`
+component to act as a flag to indicate which list is currently being displayed. This flag is updated by corresponding
+commands.
+For instance, commands such as `list` will toggle the flag to false, while `viewloan` will toggle the flag to true.
+This update switches the display between the two lists inside `MainWindow`.
+
+#### Design Considerations
+
+##### Aspect: How the GUI is updated
-* **Alternative 1 (current choice):** Saves the entire address book.
- * Pros: Easy to implement.
- * Cons: May have performance issues in terms of memory usage.
+* **Alternative 1 (current choice):** The GUI updates are done by the `Model` component's observable properties.
+ * Pros: Follows the observer design pattern, reducing coupling between the `Model` and `MainWindow` components.
+ * Cons: The GUI updates are restricted to the observable properties of the `Model` component.
-* **Alternative 2:** Individual command knows how to undo/redo by
- itself.
- * Pros: Will use less memory (e.g. for `delete`, just save the person being deleted).
- * Cons: We must ensure that the implementation of each individual command are correct.
+* **Alternative 2:** The GUI updates are done by the `MainWindow` component.
+ * Pros: More explicit control over the GUI updates.
+ * Cons: `Model` needs a reference to `MainWindow` to update the GUI directly. This increases coupling between the
+ components.
-_{more aspects and alternatives to be added}_
+### Linking a loan - Khor Jun Wei
-### \[Proposed\] Data archiving
+#### Implementation
-_{Explain here how the data archiving feature will be implemented}_
+Linking a loan is implemented through the `linkloan` command, which adds a loan to the list. This was achieved through
+the addition of a `LinkLoanCommand` class, which handles the retrieval of targets (the target loan and person)
+and the execution of the command.
+The `LinkLoanCommand` class is instantiated in the `LinkLoanCommandParser` class, while the
+`LinkLoanCommandParser` is instantiated in the `AddressBookParser` class. Both classes are instantiated when the user
+enters a `linkloan` command, which needs to be of the format `linkloan INDEX v/VALUE s/START_DATE r/RETURN_DATE`
+where INDEX (a positive whole number) is the index of the person, VALUE (a positive decimal number) is the value of the loan,
+and START_DATE and RETURN_DATE (both dates in the format yyyy-mm-dd) are the start and return dates of the loan respectively.
+
+The `LinkLoanCommand` class contains the following fields which can prove to be useful for the user:
+
+* `toLink`: the description of the loan to be linked as a `LinkLoanDescriptor`, including its value, start date and return date
+* `linkTarget`: the index of the person to link the loan to
+* Several string fields that are displayed to the user under different scenarios.
+
+Sequence diagram for the linking of loans:
+
+
+
+#### Design Considerations
+
+##### Aspect: How the command is executed:
+
+* **Alternative 1 (current choice):** The `LinkLoanCommand` class is responsible for executing the command only.
+ * Pros: Follows the Single Responsibility Principle. Simpler to debug.
+ * Cons: May result in more classes.
+* **Alternative 2:** The `LogicManager` class is responsible for executing the command.
+ * Pros: More centralized command execution.
+ * Cons: May result in the `LogicManager` class becoming too large. This also goes against various SWE principles,
+ and makes the code harder to maintain.
+
+##### Aspect: How the command parameters (i.e. loan details) are stored:
+
+* **Alternative 1 (current choice):** The parameters are stored in a temporary `LinkLoanDescriptor`,
+which is then passed into the `LinkLoanCommand`.
+ * Pros: As it follows the style of the `EditCommand`, it is simpler to debug. In addition, it follows the Single Responsibility Principle
+ as then the `LinkLoanDescriptor` will be in charge of handling the loan details.
+ * Cons: An additional `LinkLoanDescriptor` nested class is needed in `LinkLoanCommand`.
+* **Alternative 2:** Each detail about the loan (e.g. value, start date) is stored
+separately in the `LinkLoanCommand`.
+ * Pros: Eliminates the need for any additional classes.
+ * Cons: Reduces the ease for potentially adding new loan details in the future,
+ as then each time a new field would need to be added to `LinkLoanCommand`. In addition,
+ may be more difficult to debug due to novelty of code.
--------------------------------------------------------------------------------------------------------------------
@@ -262,71 +490,184 @@ _{Explain here how the data archiving feature will be implemented}_
**Target user profile**:
-* has a need to manage a significant number of contacts
-* prefer desktop apps over other types
-* can type fast
-* prefers typing to mouse interactions
-* is reasonably comfortable using CLI apps
+The target user is a business person who satisfies the following criteria:
+
+* has a need to manage a significant number of contacts;
+* prefers desktop apps over other types of apps;
+* can type fast;
+* prefers typing to mouse interactions;
+* is reasonably comfortable using CLI apps;
+* wants to manage contacts faster than a typical mouse/GUI driven app.
-**Value proposition**: manage contacts faster than a typical mouse/GUI driven app
+Typically, they want to answer the following questions quickly:
+* How much cash was loaned?
+* To whom it was loaned to?
+* When the person is due to return the loan?
+* When did the person last loan?
+
+**Value proposition**: Manage contacts faster than a typical mouse/GUI driven app
+
+Our software streamlines loanee management, preventing profit loss and enhancing loanee engagement.
+It simplifies loan categorization and tracks product quality post-return, ensuring efficient
+decision-making. Some boundaries include no detailed client reviews or personal loan management,
+as we focus solely on business loans and contact management for a select client group.
### User stories
Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unlikely to have) - `*`
-| 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 |
-
-*{More to be added}*
+| Priority | As a … | I want to … | So that I can… |
+|----------|---------------------------------------------------|---------------------------------------------------------|-------------------------------------------------------------------------|
+| `* * *` | User who loans cash out regularly | Add loan details (loanee /cash value) to the contact | remember to collect debts at a later time |
+| `* * *` | User who loans cash out regularly | Add a deadline to a loan | chase after people more easily |
+| `* *` | User who loans cash out regularly | View my past loans | know how much cash to expect in the near future |
+| `* * *` | User who loans cash out regularly | View my past loans | decide whether to loan to a client again |
+| `* *` | User who loans cash out regularly | See the overdue loans easily | chase after people more easily |
+| `* * *` | Busy user | Keep track of all my loanees(view) | save time and use it for more meaningful activities |
+| `* * *` | Busy user | Quickly view a summary of all outstanding loans(view) | have an overview without going through each contact individually |
+| `* * *` | User with a dynamic network | Delete loan | my records always reflect the current status of each loan |
+| `* *` | User with a dynamic network | Update loan entries as situations change | my records always reflect the current status of each loan |
+| `* *` | First time user | See the available commands/usage manual | familiarize with the command structure |
+| `*` | Intermediate user | Learn shortcuts to commands | save time in the future |
+| `* *` | Experienced user | Omit certain parts of the CLI commands | perform tasks more efficiently and quickly |
+| `* *` | Forgetful user | Get reminders to collect cash | collect cash promptly |
+| `* *` | Organised user | Have a system to manage my loanees | |
+| `* *` | Detail-oriented user | Add notes to each loan entry | I can record specific details or conditions of the loan |
+| `* ` | User who lends frequently to the same individuals | View aggregated loan statistics per contact | I can understand our loan history at a glance |
+| `* *` | Frequent lender | Track the history of cash loaned to and from a contact | I can reference past transactions during conversations |
+| `* *` | User looking to minimize losses | Flag high-risk loans based on past behavior | I can make more informed lending decisions in the future |
+| `* *` | User concerned with privacy | Mark certain contacts or loan entries as private | they are not visible during casual browsing of the address book |
+| `* *` | Proactive user | Mark certain contacts or loan entries as private | they are not visible during casual browsing of the address book |
+| `*` | User who appreciates convenience | Integrate the application with my calendar | loan due dates and follow-up reminders are automatically added |
+| `*` | User who values clarity | Print or export detailed loan reports | I can have a physical or digital record for personal use or discussions |
+| `*` | Collaborative user | Share loan entries with another user of the application | we can co-manage loans or items owned jointly |
+| `*` | User with international contacts | Store and view currency information for cash loans | I can accurately track and manage international loans |
+| `*` | User who appreciates personalization | Customize the notification settings for loan reminders | I can receive them through my preferred communication channel |
### Use cases
-(For all use cases below, the **System** is the `AddressBook` and the **Actor** is the `user`, unless specified otherwise)
+(For all use cases below, the **System** is the `LoanGuard Pro` and the **Actor** is the `user`, unless specified
+otherwise)
-**Use case: Delete a person**
+#### Use case: UC1 - Delete a contact
-**MSS**
+Precondition: `list` command shows a numbered list of contacts.
-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
+#### MSS
- Use case ends.
+1. User requests to delete a contact, specifying the index.
+2. System deletes the contact from the address book.
+3. System shows the contact that was deleted in the status message.
-**Extensions**
+Use case ends.
-* 2a. The list is empty.
+#### Extensions
+- 1a. Index is invalid (e.g. negative, zero, or larger than the list size).
+ - 1a1. System shows an error message in the status message.
+ - Use case ends.
- Use case ends.
+#### Use case: UC2 - Find a person by name
-* 3a. The given index is invalid.
+#### MSS
- * 3a1. AddressBook shows an error message.
+1. User searches for a contact with desired prompt.
+2. System shows the list of contacts that match the prompt.
- Use case resumes at step 2.
+Use case ends.
-*{More to be added}*
+#### Extensions
-### Non-Functional Requirements
+- 1a. User searches for a contact using an empty prompt.
+ - 1a1. System shows an error message in the status message.
+ - Use case ends.
+
+- 1b. No contact matches the prompt.
+ - 1b1. System shows a message in the status message that no contact matches the prompt.
+ - Use case ends.
+
+#### Use case: UC3 - Link a loan to contact
+
+#### MSS
+
+1. User links a contact with a loan, specifying the contact index and loan details.
+2. System links the loan to the contact.
+3. System shows the contact and the loan that was linked successfully in the status message.
+
+Use case ends.
+
+#### Extensions
+
+- 1a. Person index is invalid (e.g. negative, zero, or larger than the list size).
+ - 1a1. System shows an error message in the status message.
+ - Use case ends.
+
+- 1b. Loan details are invalid (e.g. empty, incomplete, wrong format).
+ - 1b1. System shows an error message that the loan details are invalid.
+ - Use case ends.
+
+#### Use case: UC4 - View all loans linked to particular contact
+
+#### MSS
+
+1. User requests to view all loans linked to a particular contact.
+2. System shows the list of loans linked to the contact.
+ Use case ends.
+
+#### Extensions
-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.
+- 1a. Index is invalid (e.g. negative, zero, or larger than the list size).
+ - 1a1. System shows an error message in the status message.
+ - Use case ends.
-*{More to be added}*
+#### Use case: UC5 - Delete a loan from contact
-### Glossary
+#### MSS
-* **Mainstream OS**: Windows, Linux, Unix, MacOS
-* **Private contact detail**: A contact detail that is not meant to be shared with others
+1. User views all loans linked to the contact (UC4).
+2. User issues `deleteloan` command with the index of loan to be cleared.
+3. System deletes the loan from the contact.
+4. System shows the contact and the loan that was deleted successfully in the status message.
+ Use case ends.
+
+#### Extensions
+
+- 1a. Index is invalid (e.g. negative, zero, or larger than the list size).
+ - 1a1. System shows an error message in the status message.
+ - Use case ends.
+
+#### Use case: UC6 - Mark a loan as returned
+
+#### MSS
+
+1. User views all loans linked to the contact (UC4).
+2. User marks a loan as returned specifying the loan index.
+3. System marks the loan as returned.
+4. System shows the contact and the loan that was marked as returned successfully in the status message.
+ Use case ends.
+
+#### Extensions
+
+- 1a. Index is invalid (e.g. negative, zero, or larger than the list size).
+ - 1a1. System shows an error message that the index is invalid.
+ - Use case ends.
+
+### 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 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.
+4. Should be able to handle up to 100 active (not archived) loans per contact without a noticeable sluggishness in
+ performance for typical
+ usage.
+5. Returned loans should be archived instead of deleted for future reference.
+6. The archived data should be stored for at least 3 years.
+7. Should be able to support multiple user sessions with password authentication on the same device.
+8. Archived data should be encrypted and only accessible by authorized users (admin and the user who created the data).
+9. Loan values should be in a single currency (e.g. USD, SGD, EUR, etc.) and should be formatted as per the currency
+ standards.
+10. Loan deadlines should not be more than 100 years from the date of loan creation.
--------------------------------------------------------------------------------------------------------------------
@@ -343,40 +684,216 @@ testers are expected to do more *exploratory* testing.
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.
+ 1. Double-click the jar file Expected: Shows the GUI with a set of sample contacts. The window size may not be
+ optimum.
1. Saving window preferences
- 1. Resize the window to an optimum size. Move the window to a different location. Close the window.
+ 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.
+ 1. Re-launch the app by double-clicking the jar file.
Expected: The most recent window size and location is retained.
-1. _{ more test cases … }_
### Deleting a person
1. Deleting a person while all persons are being shown
- 1. Prerequisites: List all persons using the `list` command. Multiple persons in the list.
+ 1. Prerequisites: List all persons using the `list` command. Multiple persons in the list.
+
+ 1. Test case: `delete 1`
+ Expected: First contact is deleted from the list. Details of the deleted contact shown in the status message.
+ Timestamp in the status bar is updated.
+
+ 1. Test case: `delete 0`
+ Expected: No person is deleted. Error details shown in the status message. Status bar remains the same.
+
+ 1. Other incorrect delete commands to try: `delete`, `delete x`, `...` (where x is larger than the list size)
+ Expected: Similar to previous.
+
+### Linking a loan
+
+1. Linking a loan to a contact
+
+ 1. Prerequisites: At least one contact in the list.
+
+ 1. Test case: `linkloan 1 v/100 s/2021-10-10 r/2021-10-20`
+ Expected: A loan of value 100 is linked to the first contact in current view. Details of the linked loan shown in the status
+ message. Timestamp in the status bar is updated. Note that if there are no contacts in view this command will not work.
+ Perform `list` command if necessary.
+
+### Viewing loans
+1. Viewing loans of a contact
+
+ 1. Prerequisites: At least one contact in the list.
+
+ 1. Test case: `viewloan 1`
+ Expected: All unreturned loans linked to the first contact in the current view are shown.
+ Note that if there are no contacts in view this command will not work. Perform `list` command if necessary.
+ 1. Test case: `viewloan -a 1`
+ Expected: All loans linked to the first contact in the current view are shown.
+ Here, the `-a` flag means all.
+ Note that if there are no contacts in view this command will not work. Perform `list` command if necessary.
+
+### Marking and unmarking a loan
+
+1. Marking a loan as returned
+
+ 1. Prerequisites: At least one loan linked.
+
+ 1. Test case: `viewloan -a`, followed by `markloan 1`
+ Expected: The first loan is marked as returned. Details of the marked loan shown in the status message.
+
+2. Unmarking a loan (i.e. marking it as not returned)
+ 1. Prerequisites: At least one loan linked.
+
+ 1. Test case: `viewloan -a`, followed by `unmarkloan 1`
+ Expected: The first loan is marked as not returned. Details of the unmarked loan shown in the status message.
- 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.
+### Editing a loan
- 1. Test case: `delete 0`
- Expected: No person is deleted. Error details shown in the status message. Status bar remains the same.
+1. Editing a loan
- 1. Other incorrect delete commands to try: `delete`, `delete x`, `...` (where x is larger than the list size)
- Expected: Similar to previous.
+ 1. Prerequisites: At least one loan linked.
-1. _{ more test cases … }_
+ 1. Test case: `viewloan -a`, followed by `editloan 1 v/200`
+ Expected: The value of the first loan is updated to 200. Details of the edited loan shown in the status message.
+
+### Deleting a loan
+
+1. Deleting a loan
+
+ 1. Prerequisites: At least one loan linked.
+
+ 1. Test case: `viewloan -a`, followed by `deleteloan 1`
+ Expected: The first loan is deleted. Details of the deleted loan shown in the status message.
+
+### Analytics Command
+1. Viewing analytics of a contact
+
+ 1. Prerequisites: At least one contact in the list.
+
+ 1. Test case: `analytics 1`
+ Expected: The analytics of the first contact in the current view are shown.
+ Note that if there are no contacts in view this command will not work. Perform `list` command if necessary.
### Saving data
1. Dealing with missing/corrupted data files
+ 1. Close the app. Choose either to simulate a missing data file or corrupted data file, but not both.
+
+ 1. _To simulate a missing file, go to ./data and delete the JSON file inside, where . refers to
+ th directory containing the jar file._
+ 2. _To simulate a corrupted file, open the JSON file and delete a few characters from the middle of the file._
+
+ 1. Launch the app.
+ Expected: The app should launch successfully. A new JSON file should be created in the
+ ./data folder. For a missing file, the address book should show the sample data.
+ For a corrupted file, a blank address book should be shown.
+ 2. After populating the address book with some data, repeat steps i to iv for the other of missing/corrupted.
+
+2. After performing several operations that changes the data (e.g. linkloan, add a person, etc.),
+ ensure that closing and re-opening the app retains the changed data.
+
+### Exiting the app
+
+You can exit the app in the following ways:
+1. Click the close button on the window title bar.
+
+2. Enter `exit` into the GUI.
- 1. _{explain how to simulate a missing/corrupted file, and the expected behavior}_
+In either case, the app should close.
+
+--------------------------------------------------------------------------------------------------------------------
+
+## **Appendix: Effort**
+
+The main effort for this project was spent on creating the loan management features, which were not present in AB3.
+These include:
+* linking a loan
+* viewing loans
+* marking and unmarking a loan
+* deleting loans
+* editing loans
+* viewing analytics of a contact
+
+Much inspiration was drawn from the existing commands in AB3, as well as the tutorial to add a new command.
+
+While the first five features looked similar, some required more effort than the others.
+The main difficulty we faced include how to implement the deletion and editing of loans.
+We had to ensure deletion can only happen if that loan is currently within view, else there could
+easily be mistakes. Likewise for editing a loan. The solution we came up with was to alter the
+person and loan lists in view, based on the commands given. Based on the lists in view, we decide
+if each operation can be done.
+
+The analytics feature was the most challenging feature to implement. This is because we needed to define
+the analytics that we wanted to show, and then implement the logic to calculate these analytics. The GUI,
+in particular the pie chart, was also challenging to implement.
+
+Nonetheless, we managed to implement all the features we set out to do, and we are proud of the final product.
+In particular, we are proud of the analytics feature, which we believe is a unique feature that sets our app apart.
+
+--------------------------------------------------------------------------------------------------------------------
+
+## **Appendix: Planned Enhancements**
+
+Team size: 5
+
+1. After executing `viewloan`, if we call `viewloan 1`, the error message provided states "The person index is invalid".
+ A better error message would be something like "Please run the list command before running this command again".
+2. When entering an email for a new person in the form of `name@domain`(e.g. `jameshoexample@com`), an error message should be displayed and
+ the new person shouldn't be added, as opposed to the current behaviour. This is because emails are typically
+ in the form of `local-part@mail-server.domain`(`jameshoexample@gmail.com`).
+3. Detect duplicate names, including case-insensitive ones. For example, if we have a person named "John Doe",
+ we should not be able to add another person named "john doe".
+4. Do not allow the `/` character inside any field when adding a new person, since it is a special character for prefixes.
+5. Error message for the `linkloan` command should be more specific to the error, e.g. different error messages for
+incorrect date format and a start date before end date.
+6. All fields should have a minimum length of 1 character and maximum length of 500 characters.
+Otherwise, an error message should be displayed, e.g. for name, "Name cannot be empty" or
+"Name is cannot exceed 500 characters". Similar for other fields.
+7. Error messages related to indices should be more specific to the error.
+For example, if the user enters `viewloan 0`, the error message should be something like "INDEX must be a positive integer".
+If the user enters `viewloan 8` when there are only 7 contacts, the error message should be something like "INDEX must be between 1 and 7".
+8. Reject loans that are > 2 decimal places as invalid.
+For those loans that are < 2 decimal places, change them to 2 decimal places
+format when displaying them instead of showing their exact value.
+
+--------------------------------------------------------------------------------------------------------------------
-1. _{ more test cases … }_
+## Glossary
+
+Order is roughly according to when they first appear in the guide.
+
+* **Architecture Diagram**: A diagram that shows how the different components interact with each
+ other at a high level.
+* **Sequence Diagram**: A diagram that shows how the different components interact with each other
+ when a particular command is executed.
+* **API**: Application Programming Interface, a set of rules that allows different software applications
+ to communicate with each other to form an entire system.
+* **UI**: User Interface.
+* **OOP**: Object-Oriented Programming, a programming paradigm based on the concept of "objects",
+ which can contain data and code: data in the form of fields, and code in the form of procedures.
+ The objects interact with each other.
+* **Class**: Classes are used to create and define objects. A feature of OOP.
+* **JSON**: JavaScript Object Notation, a lightweight data-interchange format. Files of this format
+ are used to store loan data on the hard disk.
+* **Data archiving**: The process of moving data that is no longer actively used to a separate storage.
+* **CLI**: Command Line Interface.
+* **GUI**: Graphical User Interface.
+* **User stories**: A user story is an informal, general explanation of a software feature written from the
+ perspective of the end user.
+* **Cash**: Money in the form of coins or notes, as opposed to cheques or credit. *All loans in this project
+ are in cash, rather than items*. For consistency, we will avoid using the term "money" in this guide.
+* **Currency**: Money of a certain country(e.g. USD, SGD, EUR for United States Dollars, SinGapore Dollars,
+ and EURos respectively).
+* **Use cases**: A specific situation in which a product or service could potentially be used.
+* **Actor**: A person or thing that performs an action.
+* **MSS**: Main Success Scenario, the most common path through a use case.
+* **Extensions**: The alternative paths through a use case.
+* **Non-Functional Requirements**: A requirement that specifies criteria that can be used to judge the operation of
+ a system, rather than specific behaviours.
+* **Mainstream OS**: Windows, Linux, Unix, or MacOS.
+* **Jar file**: A Java Archive file, used to distribute a set of Java classes or applications as a single file.
diff --git a/docs/Documentation.md b/docs/Documentation.md
index 3e68ea364e7..61fc35a7419 100644
--- a/docs/Documentation.md
+++ b/docs/Documentation.md
@@ -10,7 +10,7 @@ title: Documentation guide
* To learn how set it up and maintain the project website, follow the guide [_[se-edu/guides] **Using Jekyll for project documentation**_](https://se-education.org/guides/tutorials/jekyll.html).
* Note these points when adapting the documentation to a different project/product:
* The 'Site-wide settings' section of the page linked above has information on how to update site-wide elements such as the top navigation bar.
- * :bulb: In addition to updating content files, you might have to update the config files `docs\_config.yml` and `docs\_sass\minima\_base.scss` (which contains a reference to `AB-3` that comes into play when converting documentation pages to PDF format).
+ * :bulb: In addition to updating content files, you might have to update the config files `docs\_config.yml` and `docs\_sass\minima\_base.scss` (which contains a reference to `LoanGuard Pro` that comes into play when converting documentation pages to PDF format).
* If you are using Intellij for editing documentation files, you can consider enabling 'soft wrapping' for `*.md` files, as explained in [_[se-edu/guides] **Intellij IDEA: Useful settings**_](https://se-education.org/guides/tutorials/intellijUsefulSettings.html#enabling-soft-wrapping)
diff --git a/docs/UserGuide.md b/docs/UserGuide.md
index 7abd1984218..52ba940a5e1 100644
--- a/docs/UserGuide.md
+++ b/docs/UserGuide.md
@@ -3,10 +3,60 @@ 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.
+## Table of Contents
+
+[1. Introduction](#introduction)
+[2. Quick Start](#quick-start)
+[3. Command Summary](#command-summary)
+[4. Features Description](#features-description)
+
+- [4.1 Contact Management Features](#contact-management-features)
+ - [Adding a person: `add`](#adding-a-person-add)
+ - [Listing all persons: `list`](#listing-all-persons--list)
+ - [Editing a person: `edit`](#editing-a-person--edit)
+ - [Locating persons by name: `find`](#locating-persons-by-name-find)
+ - [Deleting a person: `delete`](#deleting-a-person--delete)
+ - [Clearing all entries: `clear`](#clearing-all-entries--clear)
+- [4.2 Basic Loan Management Features](#basic-loan-management-features)
+ - [Adding a loan: `linkloan`](#adding-a-loan-linkloan)
+ - [Viewing loans of a person: `viewloan`](#viewing-loans-of-a-person-viewloan)
+ - [Mark/Unmark a loan as returned: `markloan/unmarkloan`](#markunmark-a-loan-as-returned-markloanunmarkloan)
+ - [Editing a loan: `editloan`](#editing-a-loan-editloan)
+ - [Deleting a loan: `deleteloan`](#deleting-a-loan-deleteloan)
+- [4.3 Advanced Loan Management Features](#advanced-loan-management-features)
+ - [Analysing a client's loan records: `analytics`](#analysing-a-clients-loan-records-analytics)
+- [4.4 Miscellaneous Features](#miscellaneous-features)
+ - [Viewing help: `help`](#viewing-help--help)
+ - [Exiting the program: `exit`](#exiting-the-program--exit)
+ - [Saving the data](#saving-the-data)
+ - [Editing the data file](#editing-the-data-file)
+
+[5. FAQ](#faq)
+[6. Known Issues](#known-issues)
-* Table of Contents
-{:toc}
+--------------------------------------------------------------------------------------------------------------------
+
+## Introduction
+
+LoanGuardPro 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 are a moneylender looking to **keep track of your clients' contacts and loans**, LoanGuardPro is the right tool for you.
+
+It is in the form of an address book and supports basic contact and loan handling features like adding, editing, deleting, and viewing contacts and loans.
+More advanced features like analysing a client's loaning history are also available.
+
+### How to Use this User Guide
+
+* If you are new to Command Line Interfaces (CLI), go to
+ this [website](https://www.theodinproject.com/lessons/foundations-command-line-basics) to learn the basics.
+* If you are new to LoanGuardPro, go to the [Quick Start](#quick-start) section to download and set up the application.
+* If you are looking for detailed explanations of contact management features, refer to
+ the [Contact Management Features](#contact-management-features) section.
+* If you are looking for detailed explanations of basic loan management features, refer to
+ the [Basic Loan Management Features](#basic-loan-management-features) section.
+* If you are looking for detailed explanations of advanced loan management features, refer to
+ the [Advanced Loan Management Features](#advanced-loan-management-features) section.
+* If you encounter any issues, refer to the [Known issues](#known-issues) section.
--------------------------------------------------------------------------------------------------------------------
@@ -14,32 +64,32 @@ AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized fo
1. Ensure you have Java `11` or above installed in your Computer.
-1. Download the latest `addressbook.jar` from [here](https://github.com/se-edu/addressbook-level3/releases).
+1. Download the latest `loanguardpro.jar` from [here](https://github.com/AY2324S2-CS2103T-W13-1/tp/releases).
-1. Copy the file to the folder you want to use as the _home folder_ for your AddressBook.
+1. Copy the file to the folder you want to use as the _home folder_ for your LoanGuardPro.
-1. Open a command terminal, `cd` into the folder you put the jar file in, and use the `java -jar addressbook.jar` command to run the application.
+1. Open a command terminal, `cd` into the folder you put the jar file in, and use the `java -jar loanguardpro.jar`
+ command to run the application.
A GUI similar to the below should appear in a few seconds. Note how the app contains some sample data.
-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.
+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:
- * `list` : Lists all contacts.
-
- * `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.
-
- * `delete 3` : Deletes the 3rd contact shown in the current list.
+ * `viewloan 1` : View all active loans of the 1st person shown in the current list.
+ * `linkloan 2 v/500.00 s/2024-02-15 r/2025-02-15` : Link a loan of $500.00 to the 2nd person shown in the current
+ list with a start date of 15th Feb 2024 and repayment date of 15th Feb 2025.
- * `clear` : Deletes all contacts.
+ * `viewloan` : View all active loans.
- * `exit` : Exits the app.
+1. Refer to the [Command Summary](#command-summary) section for details of the commands available.
-1. Refer to the [Features](#features) below for details of each command.
+
--------------------------------------------------------------------------------------------------------------------
-## Features
+## Command summary
@@ -57,20 +107,66 @@ AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized fo
* Parameters can be in any order.
e.g. if the command specifies `n/NAME p/PHONE_NUMBER`, `p/PHONE_NUMBER n/NAME` is also acceptable.
-* Extraneous parameters for commands that do not take in parameters (such as `help`, `list`, `exit` and `clear`) will be ignored.
+* Extraneous parameters for commands that do not take in parameters (such as `help`, `list`, `exit` and `clear`) will be
+ ignored.
e.g. if the command specifies `help 123`, it will be interpreted as `help`.
-* If you are using a PDF version of this document, be careful when copying and pasting commands that span multiple lines as space characters surrounding line-breaks may be omitted when copied over to the application.
+* If you are using a PDF version of this document, be careful when copying and pasting commands that span multiple lines
+ as space characters surrounding line-breaks may be omitted when copied over to the application.
+
+
+### Miscellaneous
+
+| Action | Format |
+|----------|--------|
+| **Exit** | `exit` |
+| **Help** | `help` |
+
+--------------------------------------------------------------------------------------------------------------------
+
+## Features Description
+
+This section provides a detailed description of the features available in LoanGuardPro. There are three main categories
+of features:
+
+* [Contact Management](#contact-management-features)
+* [Basic Loan Management](#basic-loan-management-features)
+* [Advanced Loan Management](#advanced-loan-management-features)
+
+## Contact Management Features
### Adding a person: `add`
@@ -78,11 +174,22 @@ Adds a person to the address book.
Format: `add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…`
-
:bulb: **Tip:**
+:bulb: **Tip:**
A person can have any number of tags (including 0)
-
+
+Parameters Restrictions:
+
+* The name must only contain alphanumeric characters and spaces, and it should not be blank. The name is case-sensitive.
+* The phone number must only contain numbers.
+* The email must be in the format `local-part@domain`.
+
+Expected Behaviour:
+
+* A success message in the form of "New person added: [person details]" will be shown.
+* The person will be added to the address book and will be shown in the person list.
Examples:
+
* `add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01`
* `add n/Betsy Crowe t/friend e/betsycrowe@example.com a/Newgate Prison p/1234567 t/criminal`
@@ -92,22 +199,40 @@ Shows a list of all persons in the address book.
Format: `list`
+Expected Behaviour:
+
+* A list of all persons in the address book will be shown.
+
### Editing a person : `edit`
Edits an existing person in the address book.
Format: `edit INDEX [n/NAME] [p/PHONE] [e/EMAIL] [a/ADDRESS] [t/TAG]…`
-* 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, …
+Parameters Restrictions:
+
* At least one of the optional fields must be provided.
+* The index **must be a positive integer** 1, 2, 3, …, and it must not exceed the number of persons shown in the list.
+* The name must only contain alphanumeric characters and spaces, and it should not be blank. The name is case-sensitive.
+* The phone number must only contain numbers.
+* The email must be in the format `local-part@domain`.
+
+Expected Behaviour:
+
* 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.
+ specifying any tags after it.
+* A success message in the form of "Edited Person: [person details]" will be shown.
+* The person will be updated in the address book and will be shown in the person list.
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.
+
+* `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`
@@ -115,14 +240,23 @@ Finds persons whose names contain any of the given keywords.
Format: `find 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`
+Parameters Restrictions:
+
+* At least one keyword must be provided.
+* The keywords are case-insensitive.
+* The order of the keywords does not matter.
+
+Expected Behaviour:
+
* 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`
+* A list of persons whose names contain the given keywords will be shown.
+* See the example below for more concrete details.
Examples:
+
* `find John` returns `john` and `John Doe`
* `find alex david` returns `Alex Yeoh`, `David Li`
@@ -133,11 +267,18 @@ Deletes the specified person from the address book.
Format: `delete INDEX`
-* Deletes the person at the specified `INDEX`.
+Parameters Restrictions:
+
* The index refers to the index number shown in the displayed person list.
* The index **must be a positive integer** 1, 2, 3, …
+Expected Behaviour:
+
+* A success message in the form of "Deleted Person: [person details]" will be shown.
+* The person will be removed from the address book and will no longer be shown in the person list.
+
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.
@@ -147,6 +288,187 @@ Clears all entries from the address book.
Format: `clear`
+Expected Behaviour:
+
+* A success message in the form of "Address book has been cleared!" will be shown.
+* The address book will be empty.
+
+
+
+--------------------------------------------------------------------------------------------------------------------
+
+## Basic Loan Management Features
+
+### Adding a loan: `linkloan`
+
+Links a loan to a person in the address book.
+
+:information_source: The word `linkloan` is used to distinguish between the `add` command for adding a person and
+the `linkloan` command for linking a loan to a person.
+
+Format: `linkloan INDEX v/VALUE s/START_DATE r/RETURN_DATE`
+
+Parameters Restrictions:
+
+* Links a loan to 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, …, and it must not exceed the number of persons shown in the list.
+* The loan value must be a positive float value that is **at most 2 decimal places**, as the app behavior may not be optimal for any higher precision.
+* The start date and return date must be in the format `YYYY-MM-DD`.
+* The return date must be after the start date.
+* Year value has to be below 9999.
+
+:bulb: **Tip:**
+If you are on a view page with no person contacts, such as the "view all loans" page or the "analytics" page, you can use the `list` command to go back to the person list. That will allow you to use the `linkloan` command.
+
+Expected Behaviour:
+
+* A success message in the form of "New loan linked: [person name] [loan description]" will be shown.
+* The loan can then be found in both the overall loan list and the loan list of that person.
+
+Example: `linkloan 1 v/500.00 s/2024-02-15 r/2025-02-15`
+
+* Links a loan of $500.00 to the person at the 1st index with a start date of 15th Feb 2024 and return date of 15th Feb
+ 2025.
+
+### Viewing loans of a person: `viewloan`
+
+Shows loans in the address book.
+
+Format: `viewloan [FLAG] [INDEX]`
+
+Parameters Restrictions:
+
+* The optional index refers to the index number shown in the displayed person list. The index **must be a positive
+ integer** 1, 2, 3, …, and it must not exceed the number of persons shown in the list.
+* If the optional index is not provided, all loans, across all clients in the list will be shown.
+* The only optional flag is `-a` to show all loans including the inactive ones.
+
+:bulb: **Tip:** A loan is considered active if the loan has not been marked as returned. Otherwise, it is considered inactive.
+
+Expected Behaviour:
+
+* A success message of the form "Listed all loans associated with [person details]." will be shown.
+* The list is ordered by the end date of the loan.
+* Only the active loans will be shown if the flag `-a` is not provided. If it is provided, both active and inactive loans will be shown.
+* If the index is not provided, all loans across all clients in the list will be shown.
+* If the index is provided, all loans of the person at the specified `INDEX` will be shown.
+
+Examples: `viewloan 1`, `viewloan -a 1`
+
+* The figure below shows an example of `viewloan 1`(left) and `viewloan -a 1`(right) being executed.
+
+
+
+### Mark/Unmark a loan as returned: `markloan/unmarkloan`
+
+Marks or unmarks a loan as returned.
+
+Format: `markloan INDEX`, `unmarkloan INDEX`
+
+Parameters Restrictions:
+* The index refers to the index number shown in the displayed loan list. The index **must be a positive integer** 1, 2, 3, …, and it must not exceed the number of loans shown in the list.
+
+Expected Behaviour:
+* A success message in the form of "Loan marked: [loan details]" or "Loan unmarked: [loan details]" will be shown.
+* The status of the loan will be updated accordingly and will be reflected in the loan list.
+
+Examples: `markloan 1`, `unmarkloan 1`
+
+* Marks or unmarks the loan at that is in the 1st position in the loan list.
+
+### Editing a loan: `editloan`
+
+Edits an existing loan in the address book.
+
+Format: `editloan INDEX [v/VALUE] [s/START_DATE] [r/RETURN_DATE]`
+
+Parameters Restrictions:
+
+* The index refers to the index number shown in the displayed loan list. The index **must be a positive integer** 1, 2, 3, …, and it must not exceed the number of loans shown in the list.
+* The loan value must be a positive float value that is **at most 2 decimal places**, as the app behavior may not be optimal for any higher precision.
+* The start date and return date must be in the format `YYYY-MM-DD`.
+* The return date must be after the start date.
+* Year value has to be below 9999.
+* The loan value, start date and return date are all optional parameters, but at least one of them must be provided.
+
+Expected Behaviour:
+
+* A success message in the form of "Loan edited: [loan details]" will be shown.
+* The loan will be updated in the loan list.
+
+Examples:
+
+* `editloan 1 v/600.00 s/2024-02-15 r/2025-02-15`
+ * Edits the loan at the 1st position in the loan list to have a value of $600.00, a start date of 15th Feb 2024, and a
+ return date of 15th Feb 2025.
+* `editloan 3 s/2021-01-01`
+ * Edits the loan at the 3rd position in the loan list to have a start date of 1st Jan 2021.
+
+### Deleting a loan: `deleteloan`
+
+Deletes a loan permanently from the address book.
+
+Format: `deleteloan INDEX`
+
+Parameters Restrictions:
+
+* The index refers to the index number shown in the displayed loan list.
+The index **must be a positive integer** 1, 2, 3, …, and it must not exceed the number of loans shown in the list.
+
+Expected Behaviour:
+
+* A success message in the form of "Loan deleted: [loan details]" will be shown.
+* The loan will be removed from the loan list.
+
+Example: `deleteloan 1`
+
+* Deletes the loan at the 1st position in the loan list.
+
+
+
+--------------------------------------------------------------------------------------------------------------------
+
+## Advanced Loan Management Features
+
+### Analysing a client's loan records: `analytics`
+
+Provides visual analytics of a client's loan records based on three indices: Reliability, Impact, and Urgency.
+* The Reliability index is defined as the ratio of overdue loans to the total number of loans.
+* The Impact index is defined as the ratio of the average loan value to the maximum loan value.
+* The Urgency index is defined as follows:
+ * Define URGENCY_ALL as the number of days from the current date to the earliest return date among **all** active loans.
+ * Define URGENCY_CLIENT as the number of days from the current date to the earliest return date among **this particular client's** active loans.
+ * The Urgency index is equal to the ratio of URGENCY_ALL to URGENCY_CLIENT.
+ * The computation will only consider loans that are not overdue.
+* These indexes are then converted in percentage form and visualized in a pie chart.
+
+Format: `analytics INDEX`
+
+Parameters Restrictions:
+
+* The index refers to the index number shown in the displayed person list. The index **must be a positive integer** 1, 2, 3, …, and it must not exceed the number of persons shown in the list.
+
+Expected Behaviour:
+
+* A success message in the form of "Analytics generated for [person name]" will be shown.
+* A visual representation of the client's loan records will be shown.
+
+Example: `analytics 1`
+
+
+
+--------------------------------------------------------------------------------------------------------------------
+
+## Miscellaneous Features
+
+### Viewing help : `help`
+
+Shows a message explaining how to access the help page.
+
+
+
+Format: `help`
+
### Exiting the program : `exit`
Exits the program.
@@ -155,44 +477,38 @@ Format: `exit`
### Saving the data
-AddressBook data are saved in the hard disk automatically after any command that changes the data. There is no need to save manually.
+LoanGuardPro data are saved in the hard disk automatically after any command that changes the data. There is no need to
+save manually.
### Editing the data file
-AddressBook data are saved automatically as a JSON file `[JAR file location]/data/addressbook.json`. Advanced users are welcome to update data directly by editing that data file.
-
-
:exclamation: **Caution:**
-If your changes to the data file makes its format invalid, AddressBook will discard all data and start with an empty data file at the next run. Hence, it is recommended to take a backup of the file before editing it.
-Furthermore, certain edits can cause the AddressBook to behave in unexpected ways (e.g., if a value entered is outside of the acceptable range). Therefore, edit the data file only if you are confident that you can update it correctly.
-
+LoanGuardPro data are saved automatically as a JSON file `[JAR file location]/data/addressbook.json`. Advanced users are
+welcome to update data directly by editing that data file.
-### Archiving data files `[coming in v2.0]`
+:exclamation: **Caution:**
+If your changes to the data file makes its format invalid, LoanGuardPro **will discard all data and start with an empty
+data file at the next run**. Hence, it is recommended to take a backup of the file before editing it.
+Furthermore, certain edits can cause the LoanGuardPro to behave in unexpected ways (e.g., if a value entered is outside
+of the acceptable range). Therefore, edit the data file only if you are confident that you can update it correctly.
-_Details coming soon ..._
+
--------------------------------------------------------------------------------------------------------------------
## FAQ
**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.
+**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 LoanGuardPro home folder.
--------------------------------------------------------------------------------------------------------------------
## Known issues
-1. **When using multiple screens**, if you move the application to a secondary screen, and later switch to using only the primary screen, the GUI will open off-screen. The remedy is to delete the `preferences.json` file created by the application before running the application again.
+1. **When using multiple screens**, if you move the application to a secondary screen, and later switch to using only
+ the primary screen, the GUI will open off-screen. The remedy is to delete the `preferences.json` file created by the
+ application before running the application again.
---------------------------------------------------------------------------------------------------------------------
+
+
-[[homepage](http://www.comp.nus.edu.sg/~damithch)]
-[[github](https://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](https://github.com/kjw142857)]
+[[portfolio](https://github.com/kjw142857)]
-* Role: Project Advisor
+* Role: Developer for basic loan implementation + debugging and testing.
+* Responsibilities: Implementing the `linkloan` and `editloan` commands;
+finding bugs and pushing fixes; writing test code.
-### Jane Doe
+### Kyal Sin Min Thet
-
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](http://github.com/marcus-ny)]
+[[portfolio](http://github.com/marcus-ny)]
-* Role: Team Lead
-* Responsibilities: UI
+* Role: Team Lead + Frontend.
+* Responsibilities: setting up repo + CI workflow;
+Implementing view options for different panels - loans, contacts, analytics dashboards.
-### Johnny Doe
+### Teoh Tze Tzun
-
-[[github](http://github.com/johndoe)] [[portfolio](team/johndoe.md)]
+[[github](https://github.com/Joseph31416)] [[portfolio](https://github.com/Joseph31416)]
-* Role: Developer
-* Responsibilities: Data
+* Role: Developer for data classes and UG documentation.
+* Responsibilities:
+Implementing the `Loan`, `LoanRecords` (now refactored as `UniqueLoanList`) and `Analytics` classes from scratch;
+writing the user guide.
-### Jean Doe
+### Wang Junwu
-
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](http://github.com/narwhalsilent)]
+[[portfolio](http://github.com/narwhalsilent)]
-* Role: Developer
-* Responsibilities: Dev Ops + Threading
+* Role: Developer for loan architecture and UI integration + DG documentation.
+* Responsibilities: Implementing loan architecture as `UniqueLoanList` in the `Model`;
+implementing the `viewloan` command;
+writing the developer guide.
-### James Doe
+### Zhang Xiaorui
-
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](https://github.com/xiaorui-ui)]
+[[portfolio](https://github.com/xiaorui-ui)]
-* Role: Developer
-* Responsibilities: UI
+* Role: Developer for basic loan management and DG documentation.
+* Responsibilities: Implementing `deleteloan`, `markloan`, and `unmarkloan` commands; writing the developer guide.
diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md
index 1b56bb5d31b..4c74b50ec53 100644
--- a/docs/DeveloperGuide.md
+++ b/docs/DeveloperGuide.md
@@ -2,14 +2,59 @@
layout: page
title: Developer Guide
---
-* Table of Contents
-{:toc}
+
+[//]: <> (comment, To-do, make working links)
+[//]: <> (more To-dos: Instructions for Manual Testing, Appendix: Effort, Planned Enhancements)
+
+## Table of Contents
+[1. Acknowledgements](#acknowledgements)
Each of the four main components (also shown in the diagram above),
* defines its *API* in an `interface` with the same name as the Component.
-* implements its functionality using a concrete `{Component Name}Manager` class (which follows the corresponding API `interface` mentioned in the previous point.
+* implements its functionality using a concrete `{Component Name}Manager` class (which follows the corresponding
+ API `interface` mentioned in the previous point.
-For example, the `Logic` component defines its API in the `Logic.java` interface and implements its functionality using the `LogicManager.java` class which follows the `Logic` interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent outside component's being coupled to the implementation of a component), as illustrated in the (partial) class diagram below.
+For example, the `Logic` component defines its API in the `Logic.java` interface and implements its functionality using
+the `LogicManager.java` class which follows the `Logic` interface. Other components interact with a given component
+through its interface rather than the concrete class (reason: to prevent outside component's being coupled to the
+implementation of a component), as illustrated in the (partial) class diagram below.
@@ -68,30 +124,45 @@ The sections below give more details of each component.
### UI component
-The **API** of this component is specified in [`Ui.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/Ui.java)
+The **API** of this component is specified
+in [`Ui.java`](https://github.com/AY2324S2-CS2103T-W13-1/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 which captures the commonalities between classes that represent parts of the visible GUI.
-
-The `UI` component uses the JavaFx UI framework. The layout of these UI parts are defined in matching `.fxml` files that are in the `src/main/resources/view` folder. For example, the layout of the [`MainWindow`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/MainWindow.java) is specified in [`MainWindow.fxml`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/resources/view/MainWindow.fxml)
+The UI consists of a `MainWindow` that has three different views. Each view consists of parts which
+inherit from the abstract `UiPart` class which captures the commonalities between classes that represent parts of the
+visible GUI.
+1. The **person tab view** is made up of four parts:
+`CommandBox`, `ResultDisplay`, `PersonListPanel`, `StatusBarFooter`.
+2. The **loan tab view** is made up of four parts:
+`CommandBox`, `ResultDisplay`, `LoanListPanel`, `StatusBarFooter`.
+3. The **analytics tab view** is made up of four parts:
+`CommandBox`, `ResultDisplay`, `AnalyticsPanel`, `StatusBarFooter`.
+
+The `UI` component uses the JavaFx UI framework. The layout of these UI parts are defined in matching `.fxml` files that
+are in the `src/main/resources/view` folder. For example, the layout of
+the [`MainWindow`](https://github.com/AY2324S2-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/ui/MainWindow.java)
+is specified
+in [`MainWindow.fxml`](https://github.com/AY2324S2-CS2103T-W13-1/tp/tree/master/src/main/resources/view/MainWindow.fxml)
The `UI` component,
-* executes user commands using the `Logic` component.
+* executes user commands using the `Logic` component, which could switch between the different views.
* listens for changes to `Model` data so that the UI can be updated with the modified data.
* keeps a reference to the `Logic` component, because the `UI` relies on the `Logic` to execute commands.
-* depends on some classes in the `Model` component, as it displays `Person` object residing in the `Model`.
+* depends on some classes in the `Model` component,
+as it displays `Person`, `Loan` and `Analytics` object residing in the `Model`.
### Logic component
-**API** : [`Logic.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/logic/Logic.java)
+**API** : [`Logic.java`](https://github.com/AY2324S2-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/logic/Logic.java)
Here's a (partial) class diagram of the `Logic` component:
-The sequence diagram below illustrates the interactions within the `Logic` component, taking `execute("delete 1")` API call as an example.
+The sequence diagram below illustrates the interactions within the `Logic` component, taking `execute("delete 1")` API
+call as an example.
@@ -100,10 +171,13 @@ The sequence diagram below illustrates the interactions within the `Logic` compo
How the `Logic` component works:
-1. When `Logic` is called upon to execute a command, it is passed to an `AddressBookParser` object which in turn creates a parser that matches the command (e.g., `DeleteCommandParser`) and uses it to parse the command.
-1. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `DeleteCommand`) which is executed by the `LogicManager`.
+1. When `Logic` is called upon to execute a command, it is passed to an `AddressBookParser` object which in turn creates
+ a parser that matches the command (e.g., `DeleteCommandParser`) and uses it to parse the command.
+1. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `DeleteCommand`) which
+ is executed by the `LogicManager`.
1. The command can communicate with the `Model` when it is executed (e.g. to delete a person).
How the parsing works:
-* When called upon to parse a user command, the `AddressBookParser` class creates an `XYZCommandParser` (`XYZ` is a placeholder for the specific command name e.g., `AddCommandParser`) which uses the other classes shown above to parse the user command and create a `XYZCommand` object (e.g., `AddCommand`) which the `AddressBookParser` returns back as a `Command` object.
-* All `XYZCommandParser` classes (e.g., `AddCommandParser`, `DeleteCommandParser`, ...) inherit from the `Parser` interface so that they can be treated similarly where possible e.g, during testing.
+
+* When called upon to parse a user command, the `AddressBookParser` class creates an `XYZCommandParser` (`XYZ` is a
+ placeholder for the specific command name e.g., `AddCommandParser`) which uses the other classes shown above to parse
+ the user command and create a `XYZCommand` object (e.g., `AddCommand`) which the `AddressBookParser` returns back as
+ a `Command` object.
+* All `XYZCommandParser` classes (e.g., `AddCommandParser`, `DeleteCommandParser`, ...) inherit from the `Parser`
+ interface so that they can be treated similarly where possible e.g, during testing.
### Model component
-**API** : [`Model.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/model/Model.java)
+
+**API** : [`Model.java`](https://github.com/AY2324S2-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/model/Model.java)
@@ -123,9 +203,18 @@ How the parsing works:
The `Model` component,
* stores the address book data i.e., all `Person` objects (which are contained in a `UniquePersonList` object).
-* stores the currently 'selected' `Person` objects (e.g., results of a search query) as a separate _filtered_ list which is exposed to outsiders as an unmodifiable `ObservableList
The `Storage` component,
-* can save both address book data and user preference data in JSON format, and read them back into corresponding objects.
-* inherits from both `AddressBookStorage` and `UserPrefStorage`, which means it can be treated as either one (if only the functionality of only one is needed).
-* depends on some classes in the `Model` component (because the `Storage` component's job is to save/retrieve objects that belong to the `Model`)
+
+* can save both address book data and user preference data in JSON format, and read them back into corresponding
+ objects.
+* inherits from both `AddressBookStorage` and `UserPrefStorage`, which means it can be treated as either one (if only
+ the functionality of only one is needed).
+* depends on some classes in the `Model` component (because the `Storage` component's job is to save/retrieve objects
+ that belong to the `Model`)
### Common classes
Classes used by multiple components are in the `seedu.addressbook.commons` package.
---------------------------------------------------------------------------------------------------------------------
+## Enhancements Added
-## **Implementation**
+[//]: <> (change it to the analytics function)
-This section describes some noteworthy details on how certain features are implemented.
+### Loan Analytics - Joseph
-### \[Proposed\] Undo/redo feature
+#### Implementation
-#### Proposed Implementation
+The `Analytics` class handles the analysis of a `ObservableList
+Sequence diagram for the viewing of loans:
+
#### Design considerations:
-**Aspect: How undo & redo executes:**
+##### Aspect: How the loan list is accessed:
+
+* **Alternative 1 (current choice):** The `ViewLoanCommand.execute()` method sequentially obtains the person list,
+the person, and then the loan list.
+ * Pros: Minimises the layers of methods to follow through.
+ * Cons: May violate the SLAP principle and the Law of Demeter.
+* **Alternative 2:** The `ViewLoanCommand.execute()` method obtains the loan list directly from the `Model`.
+ * Pros: Follows the SLAP principle and the Law of Demeter. Better use of abstraction.
+ * Cons: May result in longer method chains.
+
+##### Aspect: How the command is parsed:
+
+* **Alternative 1 (current choice):** The `ViewLoanCommandParser` class is responsible for parsing the command.
+ * Pros: Follows the Single Responsibility Principle. Simpler to debug.
+ * Cons: May result in more classes.
+* **Alternative 2:** The `AddressBookParser` class is responsible for parsing the command.
+ * Pros: More centralized command parsing.
+ * Cons: May result in the `AddressBookParser` class becoming too large. This also goes against various SWE
+ principles
+ ,and makes the code harder to maintain.
+
+### Loan view GUI - Kyal Sin Min Thet
+
+#### Implementation
+
+The GUI component to display loans attached to a contact is implemented in tandem with the `viewloan` command.
+
+The update behaviour is achieved through the use of `ObservableList` objects in the `Model` component. The `MainWindow`
+component listens for changes in the `ObservableList` objects and updates the GUI accordingly.
+
+The `LoanListPanel` (similar to `PersonListPanel`) is responsible for displaying the list of loans attached to a
+contact. It generates new `LoanCard` objects according to the `loanList` in the `Model` class.
+To accommodate the new GUI component, the `MainWindow.java` file is updated to include the new `LoanListPanel`.
+
+To ensure that only either the loan list or the person list is displayed, an additional `BooleanProperty` is added to
+the `Model`
+component to act as a flag to indicate which list is currently being displayed. This flag is updated by corresponding
+commands.
+For instance, commands such as `list` will toggle the flag to false, while `viewloan` will toggle the flag to true.
+This update switches the display between the two lists inside `MainWindow`.
+
+#### Design Considerations
+
+##### Aspect: How the GUI is updated
-* **Alternative 1 (current choice):** Saves the entire address book.
- * Pros: Easy to implement.
- * Cons: May have performance issues in terms of memory usage.
+* **Alternative 1 (current choice):** The GUI updates are done by the `Model` component's observable properties.
+ * Pros: Follows the observer design pattern, reducing coupling between the `Model` and `MainWindow` components.
+ * Cons: The GUI updates are restricted to the observable properties of the `Model` component.
-* **Alternative 2:** Individual command knows how to undo/redo by
- itself.
- * Pros: Will use less memory (e.g. for `delete`, just save the person being deleted).
- * Cons: We must ensure that the implementation of each individual command are correct.
+* **Alternative 2:** The GUI updates are done by the `MainWindow` component.
+ * Pros: More explicit control over the GUI updates.
+ * Cons: `Model` needs a reference to `MainWindow` to update the GUI directly. This increases coupling between the
+ components.
-_{more aspects and alternatives to be added}_
+### Linking a loan - Khor Jun Wei
-### \[Proposed\] Data archiving
+#### Implementation
-_{Explain here how the data archiving feature will be implemented}_
+Linking a loan is implemented through the `linkloan` command, which adds a loan to the list. This was achieved through
+the addition of a `LinkLoanCommand` class, which handles the retrieval of targets (the target loan and person)
+and the execution of the command.
+The `LinkLoanCommand` class is instantiated in the `LinkLoanCommandParser` class, while the
+`LinkLoanCommandParser` is instantiated in the `AddressBookParser` class. Both classes are instantiated when the user
+enters a `linkloan` command, which needs to be of the format `linkloan INDEX v/VALUE s/START_DATE r/RETURN_DATE`
+where INDEX (a positive whole number) is the index of the person, VALUE (a positive decimal number) is the value of the loan,
+and START_DATE and RETURN_DATE (both dates in the format yyyy-mm-dd) are the start and return dates of the loan respectively.
+
+The `LinkLoanCommand` class contains the following fields which can prove to be useful for the user:
+
+* `toLink`: the description of the loan to be linked as a `LinkLoanDescriptor`, including its value, start date and return date
+* `linkTarget`: the index of the person to link the loan to
+* Several string fields that are displayed to the user under different scenarios.
+
+Sequence diagram for the linking of loans:
+
+
+
+#### Design Considerations
+
+##### Aspect: How the command is executed:
+
+* **Alternative 1 (current choice):** The `LinkLoanCommand` class is responsible for executing the command only.
+ * Pros: Follows the Single Responsibility Principle. Simpler to debug.
+ * Cons: May result in more classes.
+* **Alternative 2:** The `LogicManager` class is responsible for executing the command.
+ * Pros: More centralized command execution.
+ * Cons: May result in the `LogicManager` class becoming too large. This also goes against various SWE principles,
+ and makes the code harder to maintain.
+
+##### Aspect: How the command parameters (i.e. loan details) are stored:
+
+* **Alternative 1 (current choice):** The parameters are stored in a temporary `LinkLoanDescriptor`,
+which is then passed into the `LinkLoanCommand`.
+ * Pros: As it follows the style of the `EditCommand`, it is simpler to debug. In addition, it follows the Single Responsibility Principle
+ as then the `LinkLoanDescriptor` will be in charge of handling the loan details.
+ * Cons: An additional `LinkLoanDescriptor` nested class is needed in `LinkLoanCommand`.
+* **Alternative 2:** Each detail about the loan (e.g. value, start date) is stored
+separately in the `LinkLoanCommand`.
+ * Pros: Eliminates the need for any additional classes.
+ * Cons: Reduces the ease for potentially adding new loan details in the future,
+ as then each time a new field would need to be added to `LinkLoanCommand`. In addition,
+ may be more difficult to debug due to novelty of code.
--------------------------------------------------------------------------------------------------------------------
@@ -262,71 +490,184 @@ _{Explain here how the data archiving feature will be implemented}_
**Target user profile**:
-* has a need to manage a significant number of contacts
-* prefer desktop apps over other types
-* can type fast
-* prefers typing to mouse interactions
-* is reasonably comfortable using CLI apps
+The target user is a business person who satisfies the following criteria:
+
+* has a need to manage a significant number of contacts;
+* prefers desktop apps over other types of apps;
+* can type fast;
+* prefers typing to mouse interactions;
+* is reasonably comfortable using CLI apps;
+* wants to manage contacts faster than a typical mouse/GUI driven app.
-**Value proposition**: manage contacts faster than a typical mouse/GUI driven app
+Typically, they want to answer the following questions quickly:
+* How much cash was loaned?
+* To whom it was loaned to?
+* When the person is due to return the loan?
+* When did the person last loan?
+
+**Value proposition**: Manage contacts faster than a typical mouse/GUI driven app
+
+Our software streamlines loanee management, preventing profit loss and enhancing loanee engagement.
+It simplifies loan categorization and tracks product quality post-return, ensuring efficient
+decision-making. Some boundaries include no detailed client reviews or personal loan management,
+as we focus solely on business loans and contact management for a select client group.
### User stories
Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unlikely to have) - `*`
-| 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 |
-
-*{More to be added}*
+| Priority | As a … | I want to … | So that I can… |
+|----------|---------------------------------------------------|---------------------------------------------------------|-------------------------------------------------------------------------|
+| `* * *` | User who loans cash out regularly | Add loan details (loanee /cash value) to the contact | remember to collect debts at a later time |
+| `* * *` | User who loans cash out regularly | Add a deadline to a loan | chase after people more easily |
+| `* *` | User who loans cash out regularly | View my past loans | know how much cash to expect in the near future |
+| `* * *` | User who loans cash out regularly | View my past loans | decide whether to loan to a client again |
+| `* *` | User who loans cash out regularly | See the overdue loans easily | chase after people more easily |
+| `* * *` | Busy user | Keep track of all my loanees(view) | save time and use it for more meaningful activities |
+| `* * *` | Busy user | Quickly view a summary of all outstanding loans(view) | have an overview without going through each contact individually |
+| `* * *` | User with a dynamic network | Delete loan | my records always reflect the current status of each loan |
+| `* *` | User with a dynamic network | Update loan entries as situations change | my records always reflect the current status of each loan |
+| `* *` | First time user | See the available commands/usage manual | familiarize with the command structure |
+| `*` | Intermediate user | Learn shortcuts to commands | save time in the future |
+| `* *` | Experienced user | Omit certain parts of the CLI commands | perform tasks more efficiently and quickly |
+| `* *` | Forgetful user | Get reminders to collect cash | collect cash promptly |
+| `* *` | Organised user | Have a system to manage my loanees | |
+| `* *` | Detail-oriented user | Add notes to each loan entry | I can record specific details or conditions of the loan |
+| `* ` | User who lends frequently to the same individuals | View aggregated loan statistics per contact | I can understand our loan history at a glance |
+| `* *` | Frequent lender | Track the history of cash loaned to and from a contact | I can reference past transactions during conversations |
+| `* *` | User looking to minimize losses | Flag high-risk loans based on past behavior | I can make more informed lending decisions in the future |
+| `* *` | User concerned with privacy | Mark certain contacts or loan entries as private | they are not visible during casual browsing of the address book |
+| `* *` | Proactive user | Mark certain contacts or loan entries as private | they are not visible during casual browsing of the address book |
+| `*` | User who appreciates convenience | Integrate the application with my calendar | loan due dates and follow-up reminders are automatically added |
+| `*` | User who values clarity | Print or export detailed loan reports | I can have a physical or digital record for personal use or discussions |
+| `*` | Collaborative user | Share loan entries with another user of the application | we can co-manage loans or items owned jointly |
+| `*` | User with international contacts | Store and view currency information for cash loans | I can accurately track and manage international loans |
+| `*` | User who appreciates personalization | Customize the notification settings for loan reminders | I can receive them through my preferred communication channel |
### Use cases
-(For all use cases below, the **System** is the `AddressBook` and the **Actor** is the `user`, unless specified otherwise)
+(For all use cases below, the **System** is the `LoanGuard Pro` and the **Actor** is the `user`, unless specified
+otherwise)
-**Use case: Delete a person**
+#### Use case: UC1 - Delete a contact
-**MSS**
+Precondition: `list` command shows a numbered list of contacts.
-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
+#### MSS
- Use case ends.
+1. User requests to delete a contact, specifying the index.
+2. System deletes the contact from the address book.
+3. System shows the contact that was deleted in the status message.
-**Extensions**
+Use case ends.
-* 2a. The list is empty.
+#### Extensions
+- 1a. Index is invalid (e.g. negative, zero, or larger than the list size).
+ - 1a1. System shows an error message in the status message.
+ - Use case ends.
- Use case ends.
+#### Use case: UC2 - Find a person by name
-* 3a. The given index is invalid.
+#### MSS
- * 3a1. AddressBook shows an error message.
+1. User searches for a contact with desired prompt.
+2. System shows the list of contacts that match the prompt.
- Use case resumes at step 2.
+Use case ends.
-*{More to be added}*
+#### Extensions
-### Non-Functional Requirements
+- 1a. User searches for a contact using an empty prompt.
+ - 1a1. System shows an error message in the status message.
+ - Use case ends.
+
+- 1b. No contact matches the prompt.
+ - 1b1. System shows a message in the status message that no contact matches the prompt.
+ - Use case ends.
+
+#### Use case: UC3 - Link a loan to contact
+
+#### MSS
+
+1. User links a contact with a loan, specifying the contact index and loan details.
+2. System links the loan to the contact.
+3. System shows the contact and the loan that was linked successfully in the status message.
+
+Use case ends.
+
+#### Extensions
+
+- 1a. Person index is invalid (e.g. negative, zero, or larger than the list size).
+ - 1a1. System shows an error message in the status message.
+ - Use case ends.
+
+- 1b. Loan details are invalid (e.g. empty, incomplete, wrong format).
+ - 1b1. System shows an error message that the loan details are invalid.
+ - Use case ends.
+
+#### Use case: UC4 - View all loans linked to particular contact
+
+#### MSS
+
+1. User requests to view all loans linked to a particular contact.
+2. System shows the list of loans linked to the contact.
+ Use case ends.
+
+#### Extensions
-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.
+- 1a. Index is invalid (e.g. negative, zero, or larger than the list size).
+ - 1a1. System shows an error message in the status message.
+ - Use case ends.
-*{More to be added}*
+#### Use case: UC5 - Delete a loan from contact
-### Glossary
+#### MSS
-* **Mainstream OS**: Windows, Linux, Unix, MacOS
-* **Private contact detail**: A contact detail that is not meant to be shared with others
+1. User views all loans linked to the contact (UC4).
+2. User issues `deleteloan` command with the index of loan to be cleared.
+3. System deletes the loan from the contact.
+4. System shows the contact and the loan that was deleted successfully in the status message.
+ Use case ends.
+
+#### Extensions
+
+- 1a. Index is invalid (e.g. negative, zero, or larger than the list size).
+ - 1a1. System shows an error message in the status message.
+ - Use case ends.
+
+#### Use case: UC6 - Mark a loan as returned
+
+#### MSS
+
+1. User views all loans linked to the contact (UC4).
+2. User marks a loan as returned specifying the loan index.
+3. System marks the loan as returned.
+4. System shows the contact and the loan that was marked as returned successfully in the status message.
+ Use case ends.
+
+#### Extensions
+
+- 1a. Index is invalid (e.g. negative, zero, or larger than the list size).
+ - 1a1. System shows an error message that the index is invalid.
+ - Use case ends.
+
+### 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 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.
+4. Should be able to handle up to 100 active (not archived) loans per contact without a noticeable sluggishness in
+ performance for typical
+ usage.
+5. Returned loans should be archived instead of deleted for future reference.
+6. The archived data should be stored for at least 3 years.
+7. Should be able to support multiple user sessions with password authentication on the same device.
+8. Archived data should be encrypted and only accessible by authorized users (admin and the user who created the data).
+9. Loan values should be in a single currency (e.g. USD, SGD, EUR, etc.) and should be formatted as per the currency
+ standards.
+10. Loan deadlines should not be more than 100 years from the date of loan creation.
--------------------------------------------------------------------------------------------------------------------
@@ -343,40 +684,216 @@ testers are expected to do more *exploratory* testing.
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.
+ 1. Double-click the jar file Expected: Shows the GUI with a set of sample contacts. The window size may not be
+ optimum.
1. Saving window preferences
- 1. Resize the window to an optimum size. Move the window to a different location. Close the window.
+ 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.