diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index cd5cf2256ae..97481466538 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -38,9 +38,13 @@ 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. +- The diagrams are merely to showcase the general idea of how our codebase work. They do not serve as exact replicas of our code.
+ + ### 3.1 Architecture [Back to top](#table-of-contents) @@ -946,10 +950,10 @@ testers are expected to do more *exploratory* testing. ### C.1 Improved GUI -#### C.1.1 Motivation: +#### C.1.1 Motivation Our current GUI is not as user-friendly as we would like it to be. A well-designed and aesthetic GUI provides a more intuitive and user-friendly interface, making it easier for users to navigate, access features, and perform tasks within the app. It can also lead to higher user satisfaction. -#### C.1.2 Implementation: +#### C.1.2 Implementation 1. Update the color scheme to make the GUI more visually appealing. Use colors that resonate with our brand or that create a pleasant atmosphere. 2. Integrate relevant icons and imagery to represent different features and functions within the app, providing visual cues for users. 3. Add whitespace effectively to create a clean and organized layout and reduce visual clutter. @@ -957,19 +961,19 @@ Our current GUI is not as user-friendly as we would like it to be. A well-design ### C.2 Improved Error Messages -#### C.2.1 Motivation: +#### C.2.1 Motivation Some of our current error messages can be quite vague. As a user, this can be hard for them to decipher what is wrong. Upon receiving the error message, they may not know what is wrong. Knowing what they entered wrongly can lead to higher user satisfaction. -#### C.2.2 Implementation: +#### C.2.2 Implementation 1. Update the error messages to be more specific. For example, if the user enters an invalid command, the error message should tell the user which part of the command is invalid, instead of just saying that the command is invalid. 2. Allow the `INDEX` for commands to accept very large numbers. Currently, the computer is unable to parse the number because it is too large, and PropertyMatch will mention that the command is invalid instead of mentioning that the number is too large. ### C.3 Importing client data -#### C.3.1 Motivation: +#### C.3.1 Motivation We realise that many property agents already have existing customers and properties. They may not want to manually enter all the data into the application. This feature will allow them to import their existing data into the application, saving them time and resources. -#### C.3.2 Implementation: +#### C.3.2 Implementation 1. Add an `Import` button to the menu bar. 2. Create a file selection mechanism in which the user can import data from CSV files. 3. Parse and process the data in the file. @@ -980,10 +984,10 @@ We realise that many property agents already have existing customers and propert ### C.4 Exporting client data -#### C.4.1 Motivation: +#### C.4.1 Motivation We realise that many property agents may want to export their existing data in PropertyMatch to other platforms. This feature will allow them to easily export their data into other platforms to perform other functions (such as data analysis) not supported on PropertyMatch. -#### C.4.2 Implementation: +#### C.4.2 Implementation 1. Add an `Export` button to the menu bar. 2. Create a file selection mechanism in which the user can import data from CSV files. 3. Convert the data in the json files to CSV file. @@ -993,20 +997,20 @@ We realise that many property agents may want to export their existing data in P ### C.5 Ability to filter data less strictly -#### C.5.1 Motivation: +#### C.5.1 Motivation Right now, the `filter` commands require all characteristics to match the customer's or property's characteristics. This is too strict, and may not be useful for the property agent. This feature will allow the property agent to filter customers or properties based on a subset of characteristics. -#### C.5.2 Implementation: +#### C.5.2 Implementation 1. Allow `filter` commands to take in an extra parameter called `loose`. 2. Add code to filter customers/properties that only match one of the criteria. 3. Implement error handling and logging. ### C.6 Budget for customer should be a range -#### C.6.1 Motivation: +#### C.6.1 Motivation Customers should be able to indicate their budget as a range instead of a set number. This is because customers may not have a fixed budget, and may be willing to pay more or less for a property. -#### C.6.2 Implementation: +#### C.6.2 Implementation 1. Add code in `Budget` to have a range of values. 2. Add test cases to verify that `find`, `filter`, `match` still works with a budget range. 3. Implement error handling and logging. diff --git a/docs/UserGuide.md b/docs/UserGuide.md index 190ea4a57c8..c43d9f148c7 100644 --- a/docs/UserGuide.md +++ b/docs/UserGuide.md @@ -243,7 +243,10 @@ Format: `addcust n/NAME p/PHONE_NUMBER e/EMAIL b/BUDGET [c/CHARACTERISTIC]…​ * `NAME` can be written with alphabets, numbers and spaces. * If `NAME` starts with spaces, the starting spaces will not be registered. -* Duplicate `CHARACTERISTICS` will be omitted, e.g. entering `c/bright c/BRIGHT` will only record 1 `bright` characteristic. +* `CHARACTERISTIC` can be written with alphabets, numbers, but not spaces. +* Duplicate `CHARACTERISTIC` will be omitted, e.g. entering `c/bright c/BRIGHT` will only record 1 `bright` characteristic. +* To ensure that your customer list remains neat, PropertyMatch will not allow you to add duplicate customers with the same **phone number**. +* Only the phone number is used to differentiate between customers. i.e. Other parameters can be duplicated for different customers. @@ -259,15 +262,6 @@ Examples: * The characteristics are optional. If it is not set, no characteristic will be recorded for that particular customer. -
- -**:information_source: Note:**
- -* To ensure that your customer list remains neat, PropertyMatch will not allow you to add duplicate customers with the same **phone number**. -* Only the phone number is used to differentiate between customers. i.e. Other parameters can be duplicated for different customers. - -
- You should see the message in the [output box](#2-command-input-and-output-boxes) as below when a customer is successfully added. The new customer will be added to the bottom of your list for easy reference!

![addcustUi](images/user-guide/addcustUi.png) @@ -292,7 +286,10 @@ Format: `addprop n/NAME a/ADDRESS p/PHONE_NUMBER pr/PRICE [c/CHARACTERISTIC]… * `NAME` and `ADDRESS` can be any character, except a slash * If `NAME` or `ADDRESS`starts with spaces, the starting spaces will not be registered. * Additional spaces in `ADDRESS` will be considered as unique properties, e.g. `J'den` and `J' den` will be considered as 2 distinct properties. -* Duplicate `CHARACTERISTICS` will be omitted, e.g. entering `c/bright c/BRIGHT` will only record 1 `bright` characteristic. +* `CHARACTERISTIC` can be written with alphabets, numbers, but not spaces. +* Duplicate `CHARACTERISTIC` will be omitted, e.g. entering `c/bright c/BRIGHT` will only record 1 `bright` characteristic. +* To ensure that your property list remains neat, PropertyMatch will not allow you to add duplicate properties with the same **address**. +* Only the address is used to differentiate between properties. i.e. Other parameters can be duplicated for different properties. Examples: @@ -309,8 +306,6 @@ Examples: **:information_source: Note:**
-* To ensure that your property list remains neat, PropertyMatch will not allow you to add duplicate properties with the same **address**. -* Only the address is used to differentiate between properties. i.e. Other parameters can be duplicated for different properties. @@ -443,7 +438,7 @@ Examples: * To ensure that your customer list remains neat, PropertyMatch will not allow you to edit your customer to have the same **phone number** as an existing customer. * Only the phone number is used to differentiate between customers. i.e. Other [parameters](#glossary) can be edited to be the same as other customers. -* Duplicate `CHARACTERISTICS` will be omitted, e.g. entering`c/bright c/BRIGHT` will only record 1 `bright` characteristic. +* Duplicate `CHARACTERISTIC` will be omitted, e.g. entering`c/bright c/BRIGHT` will only record 1 `bright` characteristic. @@ -482,7 +477,7 @@ Examples: * To ensure that your property list remains neat, PropertyMatch will not allow you to edit your property to have the same **address** as an existing property. * Only the address is used to differentiate between properties. i.e. Other [parameters](#glossary) can be edited to be the same as other properties. * Additional spaces in `ADDRESS` will be considered as unique properties, e.g. `J'den` and `J' den` will be considered as 2 distinct properties. -* Duplicate `CHARACTERISTICS` will be omitted, e.g. entering`c/bright c/BRIGHT` wil only record 1 `bright`characteristic. +* Duplicate `CHARACTERISTIC` will be omitted, e.g. entering`c/bright c/BRIGHT` wil only record 1 `bright`characteristic. diff --git a/docs/diagrams/CustomerObjectDiagram.puml b/docs/diagrams/CustomerObjectDiagram.puml index 1beb0be6c6c..d15c33557db 100644 --- a/docs/diagrams/CustomerObjectDiagram.puml +++ b/docs/diagrams/CustomerObjectDiagram.puml @@ -14,7 +14,7 @@ package CustomerObjectDiagram { } Object ":Budget" as Budget { } - Object ":Tags" as Tags { + Object ":Tag" as Tag { } } @@ -22,6 +22,6 @@ Name <-- Customer : has < Phone <-- Customer : has < Email <-- Customer : has < Budget <-- Customer : has < -Tags <-- Customer : has < +Tag <-- Customer : has < @enduml diff --git a/docs/diagrams/PropertyObjectDiagram.puml b/docs/diagrams/PropertyObjectDiagram.puml index 7b84779fd6b..f38c15d2505 100644 --- a/docs/diagrams/PropertyObjectDiagram.puml +++ b/docs/diagrams/PropertyObjectDiagram.puml @@ -14,7 +14,7 @@ package PropertyObjectDiagram { } Object ":Price" as Price { } - Object ":Tags" as Tags { + Object ":Tag" as Tag { } } @@ -22,6 +22,6 @@ PropName <-- Property : has < PropAddress <-- Property : has < PropPhone <-- Property : has < Price <-- Property : has < -Tags <-- Property : has < +Tag <-- Property : has < @enduml diff --git a/docs/images/CustomerObjectDiagram.png b/docs/images/CustomerObjectDiagram.png index 456d16e8d19..fba30e7edd7 100644 Binary files a/docs/images/CustomerObjectDiagram.png and b/docs/images/CustomerObjectDiagram.png differ diff --git a/docs/images/PropertyObjectDiagram.png b/docs/images/PropertyObjectDiagram.png index 10de8002ee9..1862214cb43 100644 Binary files a/docs/images/PropertyObjectDiagram.png and b/docs/images/PropertyObjectDiagram.png differ