Merge branch 'master' of https://github.com/CS2103-AY1819S1-F10-2/main …

…into add-status-to-tag

.gitignore

@@ -4,6 +4,7 @@ build/
 .settings/
 .idea/
 lib/*
+!lib/*jar
 *.iml
 *.log
 *.log.*

build.gradle

@@ -58,6 +58,8 @@ dependencies {
     String testFxVersion = '4.0.12-alpha'
     String jUnitVersion = '5.1.0'
 
+    compile fileTree(dir:'lib',includes:['*jar'])
+
     implementation group: 'org.controlsfx', name: 'controlsfx', version: '8.40.11'
     implementation group: 'com.fasterxml.jackson.core', name: 'jackson-databind', version: '2.7.0'
     implementation group: 'com.fasterxml.jackson.datatype', name: 'jackson-datatype-jsr310', version: '2.7.4'

copyright.txt

@@ -1,7 +1,6 @@
 Some code adapted from http://code.makery.ch/library/javafx-8-tutorial/ by Marco Jakob
 
 Copyright by Susumu Yoshida - http://www.mcdodesign.com/
-- address_book_32.png
 - AddressApp.ico
 
 Copyright by Jan Jan Kovařík - http://glyphicons.com/

docs/DeveloperGuide.adoc

@@ -206,17 +206,69 @@ image::DeleteLoanSdForLogic.png[width="800"]
 [[Design-Model]]
 === Model component
 
+The model component:
+
+* Stores the LoanBook data.
+* Exposes an unmodifiable `ObservableList<Loan>` that can be 'observed' by the UI, so that the UI automatically updates when the data in the model changes.
+* Stores the user's preferences.
+* Does not depend on any of the other three components.
+
+It allows the following operations:
+
+* Viewing, adding, modifying and deleting `Bike` s and `Loan` s from the LoanBook.
+* Retrieving lists of `Bike` s and `Loan` s that are registered in the LoanBook, filtered by a `Predicate`.
+* Undo/redo operations.
+
+The component's class diagram is given below:
+
 .Structure of the Model Component
 image::ModelClassDiagram.png[width="800"]
 
 *API* : link:{repoURL}/src/main/java/loanbook/model/Model.java[`Model.java`]
 
-The `Model`,
+The API is backed by a `ModelManager` which contains:
+
+* A `VersionedLoanBook` object which tracks the main data (i.e. `Bike` s and `Loan` s) within the LoanBook.
+* A filtered list each for `Bike` s and `Loan` s to expose to the UI.
+* A `UserPrefs` object to track the user's preferences.
+
+Most operations passed to the `Model` component deals with its `VersionedLoanBook`. A `VersionedLoanBook` is simply a regular `LoanBook` that keeps track of its own history, for the undo/redo operation. The `LoanBook` itself contains:
+
+* A `LoanIdManager` that helps to assign a unique `LoanId` to every `Loan`, so that `Loan` s may be easily identified.
+* A list of unique `Bike` s.
+* A list of unique `Loan` s.
+
+[NOTE]
+====
+A unique list in the sense above is a list where no two elements are the "same":
+
+* A `Bike` is considered to be the same as another `Bike` if their `Name` s match.
+* A `Loan` is considered to be the same as another `Loan` if their `LoanId` s match.
+
+We want to exclude duplicate items from these lists to make sure that identifying any given `Bike` or `Loan` is simple and without ambiguity. +
+
+To facilitate this structure, both the `Bike` and `Loan` class implement a `UniqueListItem` interface, and the `Bike` and `Loan` lists inherit from a `UniqueList` class.
+====
+
+Most of the commands passed into the `Model` are forwarded to its `LoanBook`, who then executes these commands on the `Bike` and `Loan` lists that it has.
+
+A `Loan` contains:
+
+* The customer's particulars: Their `Name`, `Nric`, `Phone` and `Email`.
+* The `Bike` that the customer is renting.
+* A `LoanStatus` used signal whether this `Loan` is `Ongoing`, `Returned` or `Deleted`.
+* A `LoanId` used for identifying this `Loan`.
+* A `LoanRate` specifying the rate which the bicycle is being loaned at, in $/hr.
+* A `loanStartTime` and `loanEndTime`, specifying the scheduled start and end times of the loan. `loanEndTime` might be `null` if the loan has no scheduled return time.
+* Any number of `Tag` s to provide additional details for the `Loan`.
+
+A `Bike` contains:
+
+* A `Name` used for identifying this Bike.
+
+[NOTE]
+The `DataField` class is used to unify the common idea that the above details for `Loan` s and `Bike` s are specifiable by a user-inputted string. The only exception is the `Bike` field in the `Loan` class, which is specified using the `Bike` 's `Name` instead.
 
-* stores a `UserPref` object that represents the user's preferences.
-* stores the Loan Book data.
-* exposes an unmodifiable `ObservableList<Loan>` that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.
-* does not depend on any of the other three components.
 
 [[Design-Storage]]
 === Storage component
@@ -320,6 +372,44 @@ image::UndoRedoActivityDiagram.png[width="650"]
 ** Cons: Requires dealing with commands that have already been undone: We must remember to skip these commands. Violates Single Responsibility Principle and Separation of Concerns as `HistoryManager` now needs to do two different things.
 // end::undoredo[]
 
+=== Unique Loan ID
+To keep individual loan transactions identifiable, we have a Loan ID for every loan. This will be automatically assigned when the user creates a Loan using the `add` command, and will be unique among all Loans in the Loanbook.
+
+==== Current Implementation
+In the current implementation, the Loan IDs are represented using integers. The added loans will be assigned IDs in increasing order starting from 0 (i.e. the first loan will be assigned ID 0, the second loan will be assigned ID 1, the third loan, ID 2, and so on).
+
+[NOTE]
+Since this value will be a represented by a Java `int`, the maximum possible ID has been set to be 999,999,999 to prevent any integer overflow. The user will not be allowed to add a Loan using the `add` command after that maximum ID has been assigned.
+
+The running ID mechanism is facilitated by the `LoanIdManager` class, which is a component within the `LoanBook` class. After initialization using the last used Loan ID value, it stores a running integer value which increments whenever the next Loan ID is generated using `getNextAvailableLoanId()`.
+
+Since the `LoanIdManager` is a component within the `LoanBook` class, this makes it possible to capture the internal state of the `LoanIdManager` at any point for future use. It allows for simple integration with the existing undo/redo mechanism, and can be stored within the same XML file that contains all other Loanbook details.
+
+The following steps are taken when the user adds a new Loan using the `add` command:
+
+**Step 1**: After typing an `add` command, the `AddCommandParser` will parse the user input and construct a new `Loan` instance with a placeholder Loan ID, which is then used to construct a new `AddCommand` instance.
+
+**Step 2**: When `AddCommand` gets executed, the next available Loan ID will be generated via the `Model` interface. This will increment the internal running ID within the `LoanIdManager` of the `VersionedLoanBook`.
+
+**Step 3**: A new `Loan` instance will be generated using the generated Loan ID value. This new `Loan` instance gets inserted into the `VersionedLoanBook` and gets committed.
+
+The following sequence diagram shows how the updated `add` command works:
+
+==== Design Considerations
+===== Aspect: Using an Integer for the Loan ID
+* **Alternative 1**: Use a `String` to represent the Loan ID
+** Pros:
+*** More Loan ID values can be created given the same number of characters.
+*** There would be no technical limit to the number of Loan IDs possible. If all Loan IDs of a certain length get exhausted, the next generated Loan ID can be one character longer.
+** Cons:
+*** Generating the next available Loan ID may be more complicated for a string as compared to an integer (though not by a significant amount).
+
+* **Alternative 2**: Have a static integer variable in the `Loan` or the `VersionedLoanBook` class
+** Pros:
+*** The process of incrementing the running value is simpler and has lesser steps than with a `LoanIdManager` class.
+** Cons:
+*** It is more complicated to capture the state of the running value. The undo/redo mechanism will not work with a static variable.
+
 // tag::adminauthentication[]
 === Admin Authentication
 Before critical actions such as deleting a loan can be performed, admin authentication
@@ -371,7 +461,7 @@ This is currently done by appending `-encrypt` to the password, and removing it
 decrypting. For version 2.0, we plan to utilise existing libraries to encrypt and
 decrypt our stored password.
 
-// end::userconfirmation[]
+// end::adminauthentication[]
 
 === Return a Loan feature
 
@@ -938,15 +1028,7 @@ b. Require developers to download those libraries manually (this creates extra w
 [appendix]
 == Product Scope
 
-*Target user profile*:
-
-* rents bicycles as a business in Singapore
-* prefer desktop apps over other types
-* can type fast
-* prefers typing over mouse input
-* is reasonably comfortable using CLI apps
-
-*Value proposition*: manage bicycle loans faster than a typical mouse/GUI driven app
+LoanBook targets users who run a bicycle rental business in Singapore. Users who will find this product especially useful are those who are familiar with desktop applications, and who prefer using a command-line interface (CLI) over a graphic user interface (GUI) for input. A reason for this preference is that using a mouse to access app features may be slower and more accident-prone than typing on a keyboard.
 
 [appendix]
 == User Stories
@@ -1026,11 +1108,6 @@ Priorities: High (must have) - `* * \*`, Medium (nice to have) - `* \*`, Low (un
 |tag loans that loan additional items (e.g. helmets, attachable headlights)
 |keep track of which transactions concern them
 
-|`* *`
-|bicycle rental shop owner who wants to manage my loans
-|tag loans that loan additional items (e.g. helmets, attachable headlights)
-|keep track of which transactions concern my paraphernalia
-
 |`* * *`
 |bicycle rental shop owner who wants to accommodate customer demands
 |register rentals in advance and reserve bicycles
@@ -1197,7 +1274,33 @@ Use case resumes at step 2.
 Use case resumes at step 2.
 
 [discrete]
-=== Use case: Add loan into loan book
+=== Use case: Add a bike into loan book
+
+*MSS*
+
+1.  User requests to add a bike with the specific parameters into the LoanBook.
+2.  LoanBook adds the bike.
+3.	LoanBook displays a prompt to the user indicating success.
++
+Use case ends.
+
+*Extensions*
+
+[none]
+* 1a. The user input is not of the correct format.
++
+[none]
+** 1a1. LoanBook shows an error message giving the user an example command, as well as correct format of the command.
++
+* 1b. Any one of the inputs fails their respective validation checks.
++
+[none]
+** 1b1. LoanBook shows an error message telling the user how to rectify their command.
++
+Use case ends.
+
+[discrete]
+=== Use case: Add a loan into loan book
 
 *MSS*
 
@@ -1328,6 +1431,20 @@ These instructions only provide a starting point for testers to work on; testers
 
 _{ more test cases ... }_
 
+=== Adding a bike
+
+. Adding a bike whose name contains alphanumeric characters, spaces, and hyphens
+
+.. Prerequisites: List all bikes using the `listbikes` command.
+.. Test case: `addbike B i-k e 0 01-` +
+   Expected: Bike B i-k e 0 01- is added to the bike list. Details of the updated bike is shown in the status message. Timestamp in the status bar is updated.
+
+. Adding a bike that already exists in the bike list
+
+.. Prerequisites: List all bikes using the `listbikes` command. `Bike1` exists in the list.
+.. Test case: `addbike Bike1` +
+   Expected: No bike is added as a bike with the same name already exists within the LoanBook. Error details shown in the status message. Status bar remains the same.
+
 === Adding a loan
 
 . Adding a loan while all loans are listed
@@ -1336,6 +1453,34 @@ _{ more test cases ... }_
 .. Test case: `PLACEHOLDER` +
    Expected: PLACEHOLDER
 
+=== Edit a bike
+
+. Editing a bike while all bikes are listed
+
+.. Prerequisites: List all bikes using the `listbikes` command. `BikeToRename`, `Bike001` and `Bike002` are in the list.
+.. Test case: `editbike BikeToRename n/New Bike` +
+   Expected: The bike `BikeToRename` will be renamed to "New Bike". Details of the updated bike is shown in the status message. Timestamp in the status bar is updated.
+.. Test case: `editbike Bike002 n/Bike001` +
+   Expected: No bike is edited due to the specified name matching that of an existing bike, thus creating a duplicate bike if the command proceeds. Error details shown in the status message. Status bar remains the same.
+.. Test case: `editbike ThisBikeDoesNotExist n/New Bike` +
+   Expected: No bike is edited due to the specified name not matching that of any existing bike. Error details shown in the status message. Status bar remains the same.
+.. Other incorrect delete commands to try: `editbike` +
+   Expected: Similar to previous.
+
+=== Deleting a bike
+
+. Deleting a bike while all bikes are listed
+
+.. Prerequisites: List all bikes using the `listbikes` command. `Bike001` and `B i-k e 0 01-` are in the list.
+.. Test case: `deletebike B i-k e 0 01- x/a12345` +
+   Expected: The bike `B i-k e 0 01-` is deleted from the list. Details of the deleted bike is shown in the status message. Timestamp in the status bar is updated.
+.. Test case: `deletebike NotAnExistingBike x/a12345` +
+   Expected: No bike is deleted due to the supplied name not referring to an existing bike. Error details shown in the status message. Status bar remains the same.
+.. Test case: `deletebike Bike001 x/wr0ngP4sS` +
+   Expected: No bike is deleted due to invalid password supplied. Error details shown in the status message. Status bar remains the same.
+.. Other incorrect delete commands to try: `deletebike` +
+   Expected: Similar to previous.
+
 === Deleting a loan
 
 . Deleting a loan while all loans are listed