nus-cs2103-AY1819S1 · elroyhaw · Nov 3, 2018 · Nov 5, 2018 · Nov 5, 2018 · Nov 5, 2018
diff --git a/README.adoc b/README.adoc
@@ -1,10 +1,10 @@
-= Address Book (Level 4)
+= Health Book
 ifdef::env-github,env-browser[:relfileprefix: docs/]
 
-https://travis-ci.org/se-edu/addressbook-level4[image:https://travis-ci.org/se-edu/addressbook-level4.svg?branch=master[Build Status]]
-https://ci.appveyor.com/project/damithc/addressbook-level4[image:https://ci.appveyor.com/api/projects/status/3boko2x2vr5cc3w2?svg=true[Build status]]
-https://coveralls.io/github/se-edu/addressbook-level4?branch=master[image:https://coveralls.io/repos/github/se-edu/addressbook-level4/badge.svg?branch=master[Coverage Status]]
-https://www.codacy.com/app/damith/addressbook-level4?utm_source=github.com&utm_medium=referral&utm_content=se-edu/addressbook-level4&utm_campaign=Badge_Grade[image:https://api.codacy.com/project/badge/Grade/fc0b7775cf7f4fdeaf08776f3d8e364a[Codacy Badge]]
+https://travis-ci.org/CS2103-AY1819S1-T10-2/main[image:https://travis-ci.org/CS2103-AY1819S1-T10-2/main.svg?branch=master[Build Status]]
+https://ci.appveyor.com/project/elroyhaw/main/branch/master[image:https://ci.appveyor.com/api/projects/status/o0tls33cceuwbwew/branch/master?svg=true[Build status]]
+https://coveralls.io/github/CS2103-AY1819S1-T10-2/main?branch=master[image:https://coveralls.io/repos/github/CS2103-AY1819S1-T10-2/main/badge.svg?branch=master[Coverage Status]]
+https://www.codacy.com/app/damith/addressbook-level4?utm_source=github.com&utm_medium=referral&utm_content=se-edu/addressbook-level4&utm_campaign=Badge_Grade[image:https://api.codacy.com/project/badge/Grade/fc0b7775cf7f4fdeaf08776f3d8e364a[Codacy badge]]
 https://gitter.im/se-edu/Lobby[image:https://badges.gitter.im/se-edu/Lobby.svg[Gitter chat]]
 
 ifdef::env-github[]
@@ -15,24 +15,22 @@ ifndef::env-github[]
 image::images/Ui.png[width="600"]
 endif::[]
 
-* This is a desktop Address Book application. It has a GUI but most of the user interactions happen using a CLI (Command Line Interface).
+* This is a desktop Health Book application. It has a GUI but most of the user interactions happen using a CLI (Command Line Interface).
 * It is a Java sample application intended for students learning Software Engineering while using Java as the main programming language.
 * It is *written in OOP fashion*. It provides a *reasonably well-written* code example that is *significantly bigger* (around 6 KLoC)than what students usually write in beginner-level SE modules.
-* What's different from https://github.com/se-edu/addressbook-level3[level 3]:
-** A more sophisticated GUI that includes a list  panel and an in-built Browser.
-** More test cases, including automated GUI testing.
-** Support for _Build Automation_ using Gradle and for _Continuous Integration_ using Travis CI.
+* The Health Book application targets clinic receptionists who need to manage a significant number of appointments
+* The Health Book application is most effective when user has preference for CLI and is able to type fast rather than mouse input
+
 
 == Site Map
 
 * <<UserGuide#, User Guide>>
 * <<DeveloperGuide#, Developer Guide>>
-* <<LearningOutcomes#, Learning Outcomes>>
 * <<AboutUs#, About Us>>
 * <<ContactUs#, Contact Us>>
 
 == Acknowledgements
-
+* The original source code was taken from https://github.com/se-edu/addressbook-level4/[AddressBook-Level4] project, created by SE-EDU initiative.
 * Some parts of this sample application were inspired by the excellent http://code.makery.ch/library/javafx-8-tutorial/[Java FX tutorial] by
 _Marco Jakob_.
 * Libraries used: https://github.com/TestFX/TestFX[TextFX], https://bitbucket.org/controlsfx/controlsfx/[ControlsFX], https://github.com/FasterXML/jackson[Jackson], https://github.com/google/guava[Guava], https://github.com/junit-team/junit5[JUnit5]

diff --git a/docs/AboutUs.adoc b/docs/AboutUs.adoc
@@ -11,46 +11,38 @@ We are a team based in the http://www.comp.nus.edu.sg[School of Computing, Natio
 
 == Project Team
 
-=== John Doe
-image::damithc.jpg[width="150", align="left"]
-{empty}[http://www.comp.nus.edu.sg/~damithch[homepage]] [https://github.com/damithc[github]] [<<johndoe#, portfolio>>]
+=== Haw Zhe Hao Elroy
+image::elroyhaw.png[width="150", align="left"]
+{empty} [https://github.com/elroyhaw[github]]
 
-Role: Project Advisor
+Role: Team Lead
 
 '''
 
-=== John Roe
-image::lejolly.jpg[width="150", align="left"]
-{empty}[http://github.com/lejolly[github]] [<<johndoe#, portfolio>>]
+=== Giam Ju Xian
+image::giamjuxian.png[width="150", align="left"]
+{empty}[http://github.com/giamjuxian[github]]
 
-Role: Team Lead +
-Responsibilities: UI
+Role: Developer and Testing +
+Responsibilities: Ensures the testing of the project is done properly and on time.
 
 '''
 
-=== Johnny Doe
-image::yijinl.jpg[width="150", align="left"]
-{empty}[http://github.com/yijinl[github]] [<<johndoe#, portfolio>>]
+=== Fong Mei Yee Flora
+image::florafong97.png[width="150", align="left"]
+{empty}[http://github.com/florafong97[github]]
 
-Role: Developer +
-Responsibilities: Data
+Role: Documentation and Code Quality +
+Responsibilities: Looks after code quality, ensures adherence to coding standards, and the quality of various project documents.
 
 '''
 
-=== Johnny Roe
-image::m133225.jpg[width="150", align="left"]
-{empty}[http://github.com/m133225[github]] [<<johndoe#, portfolio>>]
+=== Yang Yafei
+image::YangYafei1998.png[width="150", align="left"]
+{empty}[http://github.com/YangYafei1998[github]]
 
-Role: Developer +
-Responsibilities: Dev Ops + Threading
+Role: Deliverables and Deadlines +
+Responsibilities: Ensure project deliverables are done on time and in the right format.
 
-'''
-
-=== Benson Meier
-image::yl_coder.jpg[width="150", align="left"]
-{empty}[http://github.com/yl-coder[github]] [<<johndoe#, portfolio>>]
-
-Role: Developer +
-Responsibilities: UI
 
 '''
diff --git a/docs/ContactUs.adoc b/docs/ContactUs.adoc
@@ -4,4 +4,4 @@
 
 * *Bug reports, Suggestions* : Post in our https://github.com/se-edu/addressbook-level4/issues[issue tracker] if you noticed bugs or have suggestions on how to improve.
 * *Contributing* : We welcome pull requests. Follow the process described https://github.com/oss-generic/process[here]
-* *Email us* : You can also reach us at `damith [at] comp.nus.edu.sg`
+* *Email us* : You can also reach us at `elroyhaw [at] u.nus.edu`
diff --git a/docs/DeveloperGuide.adoc b/docs/DeveloperGuide.adoc
@@ -1,4 +1,4 @@
-= AddressBook Level 4 - Developer Guide
+= HealthBook - Developer Guide
 :site-section: DeveloperGuide
 :toc:
 :toc-title:
@@ -239,92 +239,26 @@ Classes used by multiple components are in the `seedu.addressbook.commons` packa
 
 This section describes some noteworthy details on how certain features are implemented.
 
-// tag::undoredo[]
-=== Undo/Redo feature
+=== Delete patient and doctor feature
 ==== Current Implementation
+The delete patient and doctor features are facilitated by `DeletePatientCommand` and `DeleteDoctorCommand`. Both extends
+`DeleteCommand` such that it is able to delete a specific class of `Person` (i.e. `Patient` or `Doctor`) instead. Additionally,
+instead of deletion by index, deletion by name is used in this implementation.
 
-The 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:
+Step 1. The user types in `delete-patient` or `delete-doctor` in the command box followed by the parameters `n/John Doe p/12345678`
 
-* `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.
-
-These operations are exposed in the `Model` interface as `Model#commitAddressBook()`, `Model#undoAddressBook()` and `Model#redoAddressBook()` respectively.
-
-Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.
-
-Step 1. The user launches the application for the first time. The `VersionedAddressBook` will be initialized with the initial address book state, and the `currentStatePointer` pointing to that single address book state.
-
-image::UndoRedoStartingStateListDiagram.png[width="800"]
-
-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.
-
-image::UndoRedoNewCommand1StateListDiagram.png[width="800"]
-
-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`.
-
-image::UndoRedoNewCommand2StateListDiagram.png[width="800"]
-
-[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.
-
-image::UndoRedoExecuteUndoStateListDiagram.png[width="800"]
-
-[NOTE]
-If the `currentStatePointer` is at index 0, pointing to the initial address book state, then there are no previous address book states to restore. The `undo` command uses `Model#canUndoAddressBook()` to check if this is the case. If so, it will return an error to the user rather than attempting to perform the undo.
-
-The following sequence diagram shows how the undo operation works:
-
-image::UndoRedoSequenceDiagram.png[width="800"]
-
-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.
-
-[NOTE]
-If the `currentStatePointer` is at index `addressBookStateList.size() - 1`, pointing to the latest address book state, then there are no undone address book 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.
-
-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.
-
-image::UndoRedoNewCommand3StateListDiagram.png[width="800"]
-
-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. We designed it this way because it no longer makes sense to redo the `add n/David ...` command. This is the behavior that most modern desktop applications follow.
-
-image::UndoRedoNewCommand4StateListDiagram.png[width="800"]
-
-The following activity diagram summarizes what happens when a user executes a new command:
-
-image::UndoRedoActivityDiagram.png[width="650"]
+Step 2. Upon hitting enter, the `Patient` or `Doctor` will be removed from the system
 
 ==== Design Considerations
+===== Aspect: Algorithm to find `Patient` or `Doctor` to delete
+* Alternative 1 (current choice):  Loop through `model.getFilteredPersonList()` to find `Patient` or `Doctor` to delete
+** Pros: Easy to implement
+** Cons: If size of list grows unusually large (unusual because of our target audience), it may take awhile to retrieve the
+`Patient` or `Doctor`
 
-===== Aspect: How undo & redo executes
-
-* **Alternative 1 (current choice):** Saves the entire address book.
-** 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).
-** Cons: We must ensure that the implementation of each individual command are correct.
-
-===== Aspect: Data structure to support the undo/redo commands
-
-* **Alternative 1 (current choice):** Use a list to store the history of address book states.
-** Pros: Easy for new Computer Science student undergraduates to understand, who are likely to be the new incoming developers of our project.
-** Cons: Logic is duplicated twice. For example, when a new command is executed, we must remember to update both `HistoryManager` and `VersionedAddressBook`.
-* **Alternative 2:** Use `HistoryManager` for undo/redo
-** Pros: We do not need to maintain a separate list, and just reuse what is already in the codebase.
-** 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[]
-
-// tag::dataencryption[]
-=== [Proposed] Data Encryption
-
-_{Explain here how the data encryption feature will be implemented}_
-
-// end::dataencryption[]
+* Alternative 2: Use a Map that maps name to `Patient` or `Doctor`
+** Pros: Fast retrieval
+** Cons: Will have to change a lot of lines of code
 
 === Logging
 
@@ -815,13 +749,18 @@ See this https://github.com/se-edu/addressbook-level4/pull/599[PR] for the step-
 
 *Target user profile*:
 
-* has a need to manage a significant number of contacts
+* Clinic Receptionists
+* has a need to manage a significant number of appointments
+* has a need to keep track of history of patients, appointments and prescriptions
 * prefer desktop apps over other types
 * can type fast
 * prefers typing over mouse input
 * is reasonably comfortable using CLI apps
 
-*Value proposition*: manage contacts faster than a typical mouse/GUI driven app
+*Value proposition*:
+Our platform will allow the clinic receptionist to easily manage patient’s medical information
+and appointments with the doctors. This will allow appointments to be efficiently managed and
+information transfer to be more seamless.
 
 [appendix]
 == User Stories
@@ -831,25 +770,41 @@ Priorities: High (must have) - `* * \*`, Medium (nice to have) - `* \*`, Low (un
 [width="59%",cols="22%,<23%,<25%,<30%",options="header",]
 |=======================================================================
 |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
+|`* * *` |receptionist |register accounts for patients or doctors |keep track of their appointments and other information
 
-|`* * *` |user |add a new person |
+|`* * *` |receptionist |delete an account for patients or doctors |remove accounts that are not in use or invalid
 
-|`* * *` |user |delete a person |remove entries that I no longer need
+|`* * *` |receptionist |view patient’s upcoming appointments, recent visits and follow-ups requests on the landing page |easily look through the patients information
 
-|`* * *` |user |find a person by name |locate details of persons without having to go through the entire list
+|`* * *` |receptionist |add prescription to patient after appointment |keep their latest completed appointment updated
 
-|`* *` |user |hide <<private-contact-detail,private contact details>> by default |minimize chance of someone else seeing them by accident
+|`* * *` |receptionist |delete prescription to patient after appointment |remove any discrepancies found
 
-|`*` |user with many persons in the address book |sort persons by name |locate a person easily
-|=======================================================================
+|`* * *` |receptionist |edit prescription to patient after appointment |amend any discrepancies found
 
-_{More to be added}_
+|`* * *` |receptionist |check prescription provided by doctor |follow up with the patients if they wish to check their prescription
+
+|`* * *` |receptionist |add patient details (especially medical history) to patient’s profile |allow the doctors to find the patients records easily
+
+|`* * *` |receptionist |delete patient details (especially medical history) from patient's profile |allow the doctors to find the most updated patients records
+
+|`* * *` |receptionist |view patient’s details prior to appointment |provide information to the doctor, allowing them to know the full extent of patient’s health condition
+
+|`* * *` |receptionist |remind a particular patient of their next appointment |prevent him/her from forgetting their appointments
+
+|`* * *` |receptionist |remind all patients of their next appointment |prevent them from forgetting their appointments
+
+|`* * *` |receptionist |book an doctor’s appointment for patient |reserve an appointment with doctor for the patient
+
+|`* * *` |receptionist |edit an doctor’s appointment for patient |edit a reserve slot for an appointment with doctor for the patient
+
+|`* * *` |receptionist |delete an doctor’s appointment for patient |remove a reserve slot for an appointment with doctor for the patient
+|=======================================================================
 
 [appendix]
 == 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 `HealthBook` and the *Actor* is the `receptionist`, unless specified otherwise)
 
 [discrete]
 === Use case: Delete person