Update Medical History of DG (#99)

* Update DG for Medical History feature

* Update class diagrams for MedicalHistory

* Update MedicalHistory class diagram into images

* Add MedicalHistory Class Diagram into DG

docs/DeveloperGuide.md

@@ -121,12 +121,12 @@ How the parsing works:
 
 The `Model` component,
 
-* stores the address book data and appointment book data (both upcoming and archived) i.e., all `Person`, `Appointment` objects (which are contained in `UniquePersonList` and `UniqueAppointmentList` objects).
-* 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<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.
+* stores the address book data and appointment book data (both upcoming and archived) i.e., all `Patient`, `Appointment` objects (which are contained in `UniquePersonList` and `UniqueAppointmentList` objects).
+* stores the currently 'selected' `Patient` objects (e.g., results of a search query) as a separate _filtered_ list which is exposed to outsiders as 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.
 * 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)
 
-<div markdown="span" class="alert alert-info">: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.<br>
+<div markdown="span" class="alert alert-info">: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 `Patient` needing their own `Tag` objects.<br>
 
 <img src="images/BetterModelClassDiagram.png" width="450" />
 
@@ -154,9 +154,36 @@ Classes used by multiple components are in the `seedu.addressbook.commons` packa
 
 This section describes some noteworthy details on how certain features are implemented.
 
+### Recording a Patient's Medical History feature
+
+Having relatable medical history entries of a patient can help clinic staff provide more contextual service to patients. Therefore, a patient management record system should have a feature for clinic staff to add, edit, and delete medical history options of the patient. 
+
+#### How Medical History is implemented
+The proposed medical history mechanism was built with a class, ```MedicalHistory```. Within the ```MedicalHistory``` class, each entry of a pateint's medical history is stored under a private variable ```listOfEntries```. An entry of ```MedicalHistory``` is a private inner (nested) class within the ```MedicalHistory``` class, ```MedicalHistoryEntry```.
+
+These are the following methods created for the MedicalHistory feature: 
+* ```MedicalHistory#addEntry(String s)```- adds a new entry of medical history into the patient.
+* ```MedicalHistory#editEntry(int index, String s)```- edits an entry of medical history that has been recorded and saved.
+* ```MedicalHistory#removeEntry(int index, String s)```- removes an entry of medical history, so the entry is no longer recorded.
+
+These operations are exposed via the ```Patient``` class as `Patient#addMedicalHistory(String s)`, `Patient#editMedicalHistory(int i, String s)` and `Patient#removeMedicalHistory(int i)` respectively.
+
+#### Reason for implementation of MedicalHistory
+```Patient``` and ```MedicalHistory``` share a whole-part relationship, that is, when a ```Patient``` object is destroyed, the corresponding ```MedicalHistory``` object is also destroyed. There is a 1...1 multiplicity relationship between a ```Patient``` and a ```MedicalHistory```, as one patient can only have one medical history. Hence, applying the Composition principle, a single ```MedicalHistory``` is composed within ```Patient```. 
+
+Since the whole-part relationship also exists between ```MedicalHistory``` and ```MedicalHistoryEntry```, ```MedicalHistoryEntry``` is composed within ```MedicalHistory``` as well. However, since the multiplicity of the relationship between ```MedicalHistory``` and ```MedicalHistoryEntry``` is 1 to any number, that is, a medical history can have any number of medical history entries, the composition is wrapped by an ArrayList<MedicalHistoryEntry>, which stores an expandable list of medical history entries.
+
+  <img src="images/MedicalHistoryClassDiagram.png" width="150" />
+
+### Alternatives considered
+
+  1. Storing an entry of MedicalHistory as a String
+
+  An alternative implementation to record MedicalHistory would be to not break down ```MedicalHistory``` into a list of ```MedicalHistoryEntries```, and instead store each entry as a String. This alternative results in a simpler build. However, this limits the information that an entry of medical history can store. For example, a clinic staff will not be able to tell from a String that this medical history is from 10 years ago, unless explicitly indicated by the staff. On the other hand, we can better handle more information of each entry and build more features for each entry accordingly, depending on the complexity requirement of a medical history entry from the cliic staff. 
+
 ### Appointment composed of a Valid Patient when added, loaded and stored
 
-#### Implementation
+#### How Appointment is implemented
 
 Each `Appointment` in memory contains a reference to a valid `Patient` object. To ensure this valid reference is maintained while the app is running and between different running instances, modifications were made to how `Appointment` is added, loaded and stored.
 
@@ -226,9 +253,6 @@ After every command that the user makes, appointments are saved. In `LogicManage
   * **Cons:** Takes more computational work when loading compared to finding the `Patient` at an index at O(1) time.
 
 
-
-
-
 ### \[Proposed\] Undo/redo feature
 
 #### Proposed Implementation

docs/diagrams/MedicalHistoryClassDiagram.puml

@@ -0,0 +1,11 @@
+@startuml
+!include style.puml
+skinparam arrowThickness 1.1
+skinparam arrowColor MODEL_COLOR
+skinparam classBackgroundColor MODEL_COLOR
+
+Patient *--> MedicalHistory
+MedicalHistory *--> "*" MedicalHistoryEntry
+
+ModelManager -->"~* filtered" Patient
+@enduml

docs/diagrams/ModelClassDiagram.puml

@@ -29,6 +29,7 @@ Class Name
 Class Phone
 Class Tag
 Class MedicalHistory
+Class MedicalHistoryEntry
 
 Class Appointment
 Class Date
@@ -62,6 +63,7 @@ Patient *--> Email
 Patient *--> Address
 Patient *--> MedicalHistory
 Patient *--> "*" Tag
+MedicalHistory *--> "*" MedicalHistoryEntry
 
 UniqueAppointmentList --> "~* all" Appointment
 Appointment *--> Date