Update developer guide with add feature

docs/DeveloperGuide.adoc

@@ -1,4 +1,4 @@
-= AddressBook Level 3 - Developer Guide
+= EatMe Developer Guide
 :site-section: DeveloperGuide
 :toc:
 :toc-title:
@@ -12,9 +12,9 @@ ifdef::env-github[]
 :note-caption: :information_source:
 :warning-caption: :warning:
 endif::[]
-:repoURL: https://github.com/AY1920S1-CS2103T-W11-3/main/tree/master
+:repoURL: https://github.com/AY1920S1-CS2103T-W11-3/main
 
-By: `Team SE-EDU`      Since: `Jun 2016`      Licence: `MIT`
+By: `AY1920S1-CS2103T-W11-3`      Since: `Sep 2019`      Licence: `MIT`
 
 == Setting up
 
@@ -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`, `EateryListPanel`, `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`, `PersonListPanel`, `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`]
 
@@ -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<Eatery>` 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<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.
 * 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 `Eatery` can reference. This would allow `Address Book` to only require one `Tag` object per unique `Tag`, instead of each `Eatery` 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 `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. +
  +
 image:BetterModelClassDiagram.png[]
 
@@ -162,6 +162,10 @@ This method of replacing an Eatery with a modified Eatery (isOpen field set to f
 
 Given below is an example usage scenario and how the close mechanism behaves at each step.
 
+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 `AddressBook` will be initialized with the initial Json data stored.
 
 Step 2. The user executes `close `1 command to close the 1st Eatery in the address book.
@@ -209,6 +213,33 @@ image::CloseCommitActivityDiagram.png[]
 ** Cons: Requires proper handling of individual data structures to ensure each list is maintained and updated correctly.
 // end::close[]
 
+// tag::add[]
+=== Add eatery feature
+==== Implementation
+
+The add mechanism is facilitated by `AddressBook`. It implements the following operations:
+
+* `AddressBook#hasEatery(Eatery e)` -- Checks if an Eatery with the same identity as Eatery e exists in the address book.
+* `AddressBook#addEatery(Eatery e)` -- Adds an Eatery to the address book. The eatery must not already exist in the address book.
+
+These operations are exposed in the `Model` interface as `Model#hasEatery()` and `Model#addEatery()` respectively.
+
+Given below is an example usage scenario and how the add eatery mechanism behaves at each step.
+
+Step 1. The user launches the application for the first time. The `AddressBook` will be initialized with the default eateries.
+
+Step 2. The user executes `add \n Two Chefs Eating Place \a 116 Commonwealth Cres, #01-129 \c Chinese` to add a new eatery. The `add` command also calls `Model#addEatery(Eatery e)`.
+
+[NOTE]
+If the command is missing a `Name`, `Address`, or `Category` parameter, the execution of the add command will fail and the application will throw a `ParseException`.
+
+The following sequence diagram shows how the add operation works:
+image:add-sd.PNG[]
+
+The following activity diagram summarizes what happens when a user executes a new command:
+image::add-ad.PNG[]
+// end ::add[]
+
 // tag::dataencryption[]
 === [Proposed] Data Encryption
 
@@ -278,27 +309,11 @@ Priorities: High (must have) - `* * \*`, Medium (nice to have) - `* \*`, Low (un
 
 |`* * *` |person with many food allergies |keep track of dishes I have ordered before |avoid ordering hazardous food
 
-<<<<<<< HEAD
-|`* * *` |foodie |remember places |share this experience with my family and friends
-
-|`* *` |digital nomad |tag places with free power + wifi |sit there for extended periods of time
-
-|`*` |working adult |view the menu beforehand |save time from thinking what to eat
-=======
-<<<<<<< HEAD
-|`* * *` |user |find a person by name |locate details of eateries without having to go through the entire list
-=======
 |`* * *` |foodie |remember places |share this experience with my family and friends
->>>>>>> upstream/master
 
 |`* *` |digital nomad |tag places with free power + wifi |sit there for extended periods of time
 
-<<<<<<< HEAD
-|`*` |user with many eateries in the address book |sort eateries by name |locate a person easily
-=======
 |`*` |working adult |view the menu beforehand |save time from thinking what to eat
->>>>>>> upstream/master
->>>>>>> upstream/master
 |=======================================================================
 
 _{More to be added}_
@@ -313,25 +328,12 @@ _{More to be added}_
 
 *MSS*
 
-<<<<<<< HEAD
-=======
-<<<<<<< HEAD
-1.  User requests to list eateries
-2.  AddressBook shows a list of eateries
-3.  User requests to delete a specific person in the list
-4.  AddressBook deletes the person
-=======
->>>>>>> upstream/master
 1.  User requests to view his todo list
 2.  EatMe toggles to the todo mode
 3.  User requests to mark an eatery as visited in the list
 4.  EatMe shifts the data over
 5.  EatMe toggles to the main mode
 6.  EatMe requests user for whatever information left that is required before saving in the main mode
-<<<<<<< HEAD
-=======
->>>>>>> upstream/master
->>>>>>> upstream/master
 +
 Use case ends.
 
@@ -472,14 +474,14 @@ _{ more test cases ... }_
 
 === Deleting a person
 
-. Deleting a person while all eateries are listed
+. Deleting a person while all persons are listed
 
-.. Prerequisites: List all eateries using the `list` command. Multiple eateries in the list.
-.. Test case: `delete 1` +
+.. Prerequisites: List all persons using the list command. Multiple persons 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` +
+.. Test case: delete 0 +
    Expected: No person 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}_ +
+.. Other incorrect delete commands to try: delete, delete x (where x is larger than the list size) _{give more}_ +
    Expected: Similar to previous.
 
 _{ more test cases ... }_