Merge pull request #34 from AY1920S2-CS2103T-F11-2/rename-Person-to-C…

…lient

-changed Person to Client

LICENSE

@@ -2,11 +2,11 @@ MIT License
 
 Copyright (c) 2016 Software Engineering Education - FOSS Resources
 
-Permission is hereby granted, free of charge, to any person obtaining a copy
+Permission is hereby granted, free of charge, to any client obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
+copies of the Software, and to permit clients to whom the Software is
 furnished to do so, subject to the following conditions:
 
 The above copyright notice and this permission notice shall be included in all

docs/DeveloperGuide.adoc

@@ -79,7 +79,7 @@ image::UiClassDiagram.png[]
 
 *API* : link:{repoURL}/src/main/java/seedu/address/ui/Ui.java[`Ui.java`]
 
-The UI consists of a `MainWindow` that is made up of parts e.g.`CommandBox`, `ResultDisplay`, `PersonListPanel`, `StatusBarFooter` etc. All these, including the `MainWindow`, inherit from the abstract `UiPart` class.
+The UI consists of a `MainWindow` that is made up of parts e.g.`CommandBox`, `ResultDisplay`, `ClientListPanel`, `StatusBarFooter` etc. All these, including the `MainWindow`, inherit from the abstract `UiPart` class.
 
 The `UI` component uses JavaFx UI framework. The layout of these UI parts are defined in matching `.fxml` files that are in the `src/main/resources/view` folder. For example, the layout of the link:{repoURL}/src/main/java/seedu/address/ui/MainWindow.java[`MainWindow`] is specified in link:{repoURL}/src/main/resources/view/MainWindow.fxml[`MainWindow.fxml`]
 
@@ -100,7 +100,7 @@ link:{repoURL}/src/main/java/seedu/address/logic/Logic.java[`Logic.java`]
 
 .  `Logic` uses the `AddressBookParser` class to parse the user command.
 .  This results in a `Command` object which is executed by the `LogicManager`.
-.  The command execution can affect the `Model` (e.g. adding a person).
+.  The command execution can affect the `Model` (e.g. adding a client).
 .  The result of the command execution is encapsulated as a `CommandResult` object which is passed back to the `Ui`.
 .  In addition, the `CommandResult` object can also instruct the `Ui` to perform certain actions, such as displaying help to the user.
 
@@ -123,11 +123,11 @@ The `Model`,
 
 * stores a `UserPref` object that represents the user's preferences.
 * stores the Address Book data.
-* exposes an unmodifiable `ObservableList<Person>` that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.
+* exposes an unmodifiable `ObservableList<Client>` 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.
 
 [NOTE]
-As a more OOP model, we can store a `Tag` list in `Address Book`, which `Person` can reference. This would allow `Address Book` to only require one `Tag` object per unique `Tag`, instead of each `Person` needing their own `Tag` object. An example of how such a model may look like is given below. +
+As a more OOP model, we can store a `Tag` list in `Address Book`, which `Client` can reference. This would allow `Address Book` to only require one `Tag` object per unique `Tag`, instead of each `Client` needing their own `Tag` object. An example of how such a model may look like is given below. +
  +
 image:BetterModelClassDiagram.png[]
 
@@ -173,18 +173,18 @@ Step 1. The user launches the application for the first time. The `VersionedAddr
 
 image::UndoRedoState0.png[]
 
-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.
+Step 2. The user executes `delete 5` command to delete the 5th client 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.
 
 image::UndoRedoState1.png[]
 
-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`.
+Step 3. The user executes `add n/David ...` to add a new client. The `add` command also calls `Model#commitAddressBook()`, causing another modified address book state to be saved into the `addressBookStateList`.
 
 image::UndoRedoState2.png[]
 
 [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`.
 
-Step 4. The user now decides that adding the person was a mistake, and decides to undo that action by executing the `undo` command. The `undo` command will call `Model#undoAddressBook()`, which will shift the `currentStatePointer` once to the left, pointing it to the previous address book state, and restores the address book to that state.
+Step 4. The user now decides that adding the client 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.
 
 image::UndoRedoState3.png[]
 
@@ -222,7 +222,7 @@ image::CommitActivityDiagram.png[]
 ** Pros: Easy to implement.
 ** Cons: May have performance issues in terms of memory usage.
 * **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).
+** Pros: Will use less memory (e.g. for `delete`, just save the client being deleted).
 ** Cons: We must ensure that the implementation of each individual command are correct.
 
 ===== Aspect: Data structure to support the undo/redo commands
@@ -296,7 +296,7 @@ Priorities: High (must have) - `* * \*`, Medium (nice to have) - `* \*`, Low (un
 [width="59%",cols="22%,<30%,<35%,<50%",options="header",]
 |=======================================================================
 |Priority |As a ... |I want to ... |So that I can...
-|`* * *` |coach for fitness competitors |record the personal bests of my clients |monitor their progress
+|`* * *` |coach for fitness competitors |record the cliental bests of my clients |monitor their progress
 |`* * *` |coach for fitness competitors |record the exercise type and intensity my clients have done for the day |know if they are on track for their competitions
 |`* * *` |coach for fitness competitors|record the date and time of my clients’ training sessions and keep track of which day they work out|
 |`* * *` |coach with many fitness competitors |view my overall schedule for the day/week|
@@ -311,7 +311,7 @@ Priorities: High (must have) - `* * \*`, Medium (nice to have) - `* \*`, Low (un
 |`* *` |coach with many clients |be reminded of my daily schedule at the start of the day |track my appointments
 |`* *` |forgetful coach with many clients |look at my records on clients |know what exercises they are weak in or require more assistance
 |`* *` |coach with a tight schedule |display my open slots |plan for training more effectively
-|`* *` |coach with many clients |set personalised goals for my clients |plan a workout routine that is achievable
+|`* *` |coach with many clients |set clientalised goals for my clients |plan a workout routine that is achievable
 |`* *` |coach with many different clients |easily export the data of a client (to a CSV file) |backup and store that data in another format
 |`* *` |coach |track my clients by using a tag |easily view the clients I want to
 |`*` |coach with clients all over SG |find the nearest gym based on where my client stays|
@@ -387,7 +387,7 @@ Use case resumes at step 2.
 
 *MSS*
 
-1.  User requests to edit a client's personal details
+1.  User requests to edit a client's cliental details
 2.  FitBiz shows a list of clients
 3.  User requests to edit a specific client in the list and inputs the attributes and values
 4.  FitBiz edits client's details
@@ -521,14 +521,14 @@ Use case ends.
 Use case resumes at step 1.
 
 [discrete]
-=== Use case 9: View personal best
+=== Use case 9: View cliental best
 
 *MSS*
 
-1.  User requests to view a client's personal best
+1.  User requests to view a client's cliental best
 2.  FitBiz lists all clients
-3.  User requests to view the personal best of a specific client on the list
-3.  FitBiz displays the personal best
+3.  User requests to view the cliental best of a specific client on the list
+3.  FitBiz displays the cliental best
 +
 Use case ends.
 
@@ -624,7 +624,7 @@ _{More to be added}_
 == Non Functional Requirements
 
 .  Should work on any <<mainstream-os,mainstream OS>> as long as it has Java `11` or above installed.
-.  Should be able to hold up to 1000 persons without a noticeable sluggishness in performance for typical usage.
+.  Should be able to hold up to 1000 clients without a noticeable sluggishness in performance for typical usage.
 .  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.
 .  Should work without the need for Internet in the program.
 .  Should work reliably.
@@ -648,7 +648,7 @@ A contact detail that is not meant to be shared with others.
 [[exercise]] Exercise::
 A workout activity done by a client that is to be recorded.
 
-[[personal-best]] Personal Best::
+[[cliental-best]] Cliental Best::
 The best/highest weight that the client has reached for an exercise.
 
 [appendix]
@@ -692,15 +692,15 @@ These instructions only provide a starting point for testers to work on; testers
 
 _{ more test cases ... }_
 
-=== Deleting a person
+=== Deleting a client
 
-. Deleting a person while all persons are listed
+. Deleting a client while all clients are listed
 
-.. Prerequisites: List all persons using the `list` command. Multiple persons in the list.
+.. Prerequisites: List all clients using the `list` command. Multiple clients in the list.
 .. 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.
 .. Test case: `delete 0` +
-   Expected: No person is deleted. Error details shown in the status message. Status bar remains the same.
+   Expected: No client is deleted. Error details shown in the status message. Status bar remains the same.
 .. Other incorrect delete commands to try: `delete`, `delete x` (where x is larger than the list size) _{give more}_ +
    Expected: Similar to previous.
 

docs/LearningOutcomes.adoc

@@ -33,7 +33,7 @@ What other user stories do you think AddressBook should support? Add those user
 === Exercise: Add a 'Rename tag' use case
 
 * Add a use case to the `DeveloperGuide.adoc` to cover the case of _renaming of an existing tag_.
-e.g. rename the tag `friends` to `buddies` (i.e. all persons who had the `friends` tag will now have
+e.g. rename the tag `friends` to `buddies` (i.e. all clients who had the `friends` tag will now have
 a `buddies` tag instead)
 Assume that AddressBook confirms the change with the user before carrying out the operation.
 
@@ -108,12 +108,12 @@ image::PrintableInterface.png[width=400]
 String getPrintableString(Printable... printables) {
 ----
 +
-The above method can be used to get a printable string representing a bunch of person details.
+The above method can be used to get a printable string representing a bunch of client details.
 For example, you should be able to call that method like this:
 +
 [source,java]
 ----
-// p is a Person object
+// p is a Client object
 return getPrintableString(p.getPhone(), p.getEmail(), p.getAddress());
 ----
 

docs/SettingUp.adoc

@@ -72,7 +72,7 @@ Set up Travis to perform Continuous Integration (CI) for your fork. See <<UsingT
 After setting up Travis, you can optionally set up coverage reporting for your team fork (see <<UsingCoveralls#, UsingCoveralls.adoc>>).
 
 [NOTE]
-Coverage reporting could be useful for a team repository that hosts the final version but it is not that useful for your personal fork.
+Coverage reporting could be useful for a team repository that hosts the final version but it is not that useful for your cliental fork.
 
 Optionally, you can set up AppVeyor as a second CI (see <<UsingAppVeyor#, UsingAppVeyor.adoc>>).
 

docs/UserGuide.adoc

@@ -68,7 +68,7 @@ Format: `add-c n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…`
 * `n/NAME` is case insensitive. e.g `hans` will match `Hans`
 * The order of words will matter. e.g `Hans Ong` will not match `Ong Hans`
 * Only exact match will be shown. e.g. `Hans` will not match `Hans Ong`
-* A person can have any number of tags (including 0)
+* A client can have any number of tags (including 0)
 
 Examples:
 
@@ -95,15 +95,15 @@ Examples:
 
 === Edit a client’s profile: `edit-c`
 
-Edits the client’s personal details by specifying the attribute and the new value.
+Edits the client’s cliental details by specifying the attribute and the new value.
 
 Format: `edit-c INDEX [n/NAME] [p/PHONE] [e/EMAIL] [a/ADDRESS] [t/TAG]...`
 
 * `INDEX` refers to the index number shown in the displayed client list
 * `INDEX` must be a positive integer (ie. 1, 2, 3, ...)
 * At least one of the optional fields must be provided
-* When editing tags, the existing tags of the person will be removed i.e adding of tags is not cumulative
-* You can remove all the person’s tags by typing `t/`` without specifying any tags after it
+* When editing tags, the existing tags of the client will be removed i.e adding of tags is not cumulative
+* You can remove all the client’s tags by typing `t/`` without specifying any tags after it
 
 Examples:
 
@@ -177,9 +177,9 @@ Examples:
 * `filter-c Johnny`
 ** Returns a client list of `Johnny Tim` and `johnny`
 
-=== View personal best: `view-pb`
+=== View cliental best: `view-pb`
 
-Displays the personal best of all exercises of the client at the specified index.
+Displays the cliental best of all exercises of the client at the specified index.
 
 Format: `view-pb INDEX`
 
@@ -189,7 +189,7 @@ Format: `view-pb INDEX`
 Example:
 
 * `view-pb 6`
-** Shows the personal best for all exercises done by the 6th client
+** Shows the cliental best for all exercises done by the 6th client
 
 === View schedule for the day/week: `view-s`
 

docs/UsingTravis.adoc

@@ -67,10 +67,10 @@ image:travis_build.png[Travis build]
 
 .  Ensure that you have followed the steps above to set up Travis CI.
 .  On GitHub, create a new user account and give this account collaborator and admin access to the repo. +
-   Using this account, generate a personal access token https://github.com/settings/tokens/new[here].
+   Using this account, generate a cliental access token https://github.com/settings/tokens/new[here].
 +
 [NOTE]
-Personal access tokens are like passwords so make sure you keep them secret! If the personal access token is leaked, please delete it and generate a new one.
+Cliental access tokens are like passwords so make sure you keep them secret! If the cliental access token is leaked, please delete it and generate a new one.
 +
 [NOTE]
 We use a new user account to generate the token for team projects to prevent team members from gaining access to other team members' repos. +
@@ -79,7 +79,7 @@ If you are the only one with write access to the repo, you can use your own acco
 --
 * Add a description for the token. (e.g. `Travis CI - deploy docs to gh-pages`)
 * Check the `public_repo` checkbox.
-* Click `Generate Token` and copy your new personal access token.
+* Click `Generate Token` and copy your new cliental access token.
 --
 We will use this token to grant Travis access to the repo.
 +
@@ -93,14 +93,14 @@ image:flick_repository_switch.png[Activate the switch]
 +
 --
 * name: `GITHUB_TOKEN`
-* value: personal access token copied in step 1
+* value: cliental access token copied in step 1
 * Display value in build log: `OFF`
 --
 image:travis_add_token.png[Travis add token]
 +
 [NOTE]
 *Make sure you set `Display value in build log` to `OFF`.* +
-Otherwise, other people will be able to see the personal access token and thus have access this repo. +
+Otherwise, other people will be able to see the cliental access token and thus have access this repo. +
 Similarly, make sure you *do not print `$GITHUB_TOKEN` to the logs* in Travis scripts as the logs are viewable by the public.
 
 .  Now, whenever there's a new commit to master branch, Travis will push the latest documentation to gh-pages branch.

docs/diagrams/ArchitectureSequenceDiagram.puml

@@ -13,7 +13,7 @@ activate ui UI_COLOR
 ui -[UI_COLOR]> logic : execute("delete 1")
 activate logic LOGIC_COLOR
 
-logic -[LOGIC_COLOR]> model : deletePerson(p)
+logic -[LOGIC_COLOR]> model : deleteClient(p)
 activate model MODEL_COLOR
 
 model -[MODEL_COLOR]-> logic

docs/diagrams/BetterModelClassDiagram.puml

@@ -4,18 +4,18 @@ skinparam arrowThickness 1.1
 skinparam arrowColor MODEL_COLOR
 skinparam classBackgroundColor MODEL_COLOR
 
-AddressBook *-right-> "1" UniquePersonList
+AddressBook *-right-> "1" UniqueClientList
 AddressBook *-right-> "1" UniqueTagList
-UniqueTagList -[hidden]down- UniquePersonList
-UniqueTagList -[hidden]down- UniquePersonList
+UniqueTagList -[hidden]down- UniqueClientList
+UniqueTagList -[hidden]down- UniqueClientList
 
 UniqueTagList *-right-> "*" Tag
-UniquePersonList o-right-> Person
+UniqueClientList o-right-> Client
 
-Person o-up-> "*" Tag
+Client o-up-> "*" Tag
 
-Person *--> Name
-Person *--> Phone
-Person *--> Email
-Person *--> Address
+Client *--> Name
+Client *--> Phone
+Client *--> Email
+Client *--> Address
 @enduml

docs/diagrams/DeleteSequenceDiagram.puml

@@ -48,7 +48,7 @@ deactivate AddressBookParser
 LogicManager -> DeleteCommand : execute()
 activate DeleteCommand
 
-DeleteCommand -> Model : deletePerson(1)
+DeleteCommand -> Model : deleteClient(1)
 activate Model
 
 Model --> DeleteCommand

docs/diagrams/ModelClassDiagram.puml

@@ -15,13 +15,13 @@ Class ModelManager
 Class UserPrefs
 Class ReadOnlyUserPrefs
 
-Package Person {
-Class Person
+Package Client {
+Class Client
 Class Address
 Class Email
 Class Name
 Class Phone
-Class UniquePersonList
+Class UniqueClientList
 }
 
 Package Tag {
@@ -40,17 +40,17 @@ ModelManager o--> "1" AddressBook
 ModelManager o-left-> "1" UserPrefs
 UserPrefs .up.|> ReadOnlyUserPrefs
 
-AddressBook *--> "1" UniquePersonList
-UniquePersonList o--> "*" Person
-Person *--> Name
-Person *--> Phone
-Person *--> Email
-Person *--> Address
-Person *--> "*" Tag
+AddressBook *--> "1" UniqueClientList
+UniqueClientList o--> "*" Client
+Client *--> Name
+Client *--> Phone
+Client *--> Email
+Client *--> Address
+Client *--> "*" Tag
 
 Name -[hidden]right-> Phone
 Phone -[hidden]right-> Address
 Address -[hidden]right-> Email
 
-ModelManager -->"1" Person : filtered list
+ModelManager -->"1" Client : filtered list
 @enduml

docs/diagrams/StorageClassDiagram.puml

@@ -19,6 +19,6 @@ StorageManager o--> AddressBookStorage
 JsonUserPrefsStorage .left.|> UserPrefsStorage
 JsonAddressBookStorage .left.|> AddressBookStorage
 JsonAddressBookStorage .down.> JsonSerializableAddressBookStorage
-JsonSerializableAddressBookStorage .right.> JsonSerializablePerson
-JsonSerializablePerson .right.> JsonAdaptedTag
+JsonSerializableAddressBookStorage .right.> JsonSerializableClient
+JsonSerializableClient .right.> JsonAdaptedTag
 @enduml