Merge ce1a3ed into d614af8

docs/DeveloperGuide.adoc

@@ -218,8 +218,11 @@ that
 the UI automatically updates when the data in the list change.
 * does not depend on any of the other three components.
 
+// tag::storagecomponent[]
 === Storage component
 
+The following diagram shows how the Storage component is structured.
+
 .Structure of the Storage Component
 image::StorageClassDiagram.png[width="800"]
 
@@ -229,11 +232,36 @@ The `Storage` component,
 
 * can save `UserPref` objects in json format and read it back.
 * can save the FoodZoom data in xml format and read it back.
+** FoodZoom allows deliverymen and users to be stored separately to prevent
+duplication of data while retaining object associations.
 * can save the Users' data in xml format and read it back.
 
+The following diagram depicts the sequence diagram of how `StorageManager` saves changes every time a change is made
+in FoodZoom.
+
 .Interactions inside the Storage component for whenever `ModelManager.saveFoodZoom(orderBook, deliverymenList)` is called.
 image::StorageSequenceDiagram.png[width="800"]
 
+==== Design considerations
+
+===== Aspect: Implementation of file storage structure for FoodZoom
+This concerns the implementation of how application data is stored in a reloadable file.
+
+* **Alternative 1**: Use two separate files for the storage of FoodZoom data
+** Pros:
+*** This solution presents a better separation of concerns between deliverymen and orders. This means that corruption of one
+file would not affect the other.
+** Cons:
+*** It is more difficult to manage JXML marshalling from two separate files.
+
+* **Alternative 2 (current choice):** Use a single file to the storage of `deliverymen` and `orders`
+** Pros:
+*** Coupling of `deliverymen` and `orders` allows more cohesion, as information like `id` for a deliveryman's orders would
+be unusable without knowing the orders.
+** Cons:
+*** Corruption of one file would mean corruption of all application data.
+// end::storagecomponent[]
+
 === Common classes
 
 Classes used by multiple components are in the `seedu.addressbook.commons` package.
@@ -689,6 +717,8 @@ a `ParseException` would be thrown.
 ==== Design Considerations
 
 ===== Implementation of `DeliverymanAddCommandParser`
+This concerns the implementation and organization of a `DeliverymanAddCommand`
+
 * ** Alternative 1 (current choice):** `DeliverymanCommand` is parsed first, then as a `DeliverymanAddCommand`.
 ** Pros: Better modularization for all commands relating to `Deliveryman`
 ** Cons: More complicated file & package organization
@@ -698,6 +728,8 @@ a `ParseException` would be thrown.
 ** Cons: Poor modularization of related `Command` classes.
 
 ===== Implementation of `DeliverymanAddCommand`
+This concerns how deliverymen data is stored with relation to orders.
+
 * **Alternative 1 (current choice):** Deliverymen are stored in separate file
 ** Pros: Allows for greater flexibility in how deliverymen interact with other resources like order/routes - better separation of concerns.
 ** Cons: Harder to implement & maintain

docs/UserGuide.adoc

@@ -337,7 +337,7 @@ Format: `/order clear`
 // tag::deliverymanadd[]
 === Adding a delivery man : `/deliveryman add` `[Since v1.2]`
 
-Adds a delivery man to the list of delivery men +
+Allows you to add a delivery man to the list of delivery men +
 Format: `/deliveryman add n/NAME`
 
 Examples:
@@ -348,7 +348,7 @@ Examples:
 // tag::deliverymanlist[]
 === Listing all delivery men : `/deliveryman list` `[Since v1.2]`
 
-Shows a list of all delivery men in chronological order +
+Lets you see the list of all delivery men in that were added for chronological order +
 Format: `/deliveryman list`
 // end::deliverymanlist[]
 
@@ -391,7 +391,7 @@ Returns all delivery men with the names `John` e.g. `John Smith` and `John Doe`
 // tag::deliverymandelete[]
 === Deleting a delivery man : `/deliveryman delete` `[Since v1.2]`
 
-Deletes the specified delivery man from the list of delivery men +
+Allows you to delete the specified delivery man from the list of delivery men +
 Format: `/deliveryman delete INDEX`
 
 ****
@@ -412,7 +412,7 @@ Deletes the 1st delivery man in the results of the `find` command.
 // tag::deliverymanselect[]
 === Selecting a deliveryman : `/deliveryman select` `[Since v1.4]`
 
-Selects the specified deliveryman from the list of deliverymen. +
+Allows you to select the specified deliveryman from the list of deliverymen. +
 Format: `/deliveryman select INDEX`
 
 ****
@@ -432,13 +432,13 @@ Selects the 1st deliveryman in the results of the `find` command.
 
 === Clearing all delivery men entries : `/deliveryman clear` `[Coming in v2.0]`
 
-Clears all entries from the list of delivery men. +
+Allows you to clear all entries from the list of delivery men. +
 Format: `/deliveryman clear`
 
 // tag::assignfeature[]
 === Assign orders to a delivery man : `/assign` `[Since v1.3]`
 
-Assign multiple orders to a delivery man +
+Lets you assign multiple orders to a delivery man +
 Format: `/assign d/DELIVERYMAN_INDEX o/ORDER_INDEX`
 
 ****

docs/team/juxd.adoc

@@ -20,9 +20,15 @@ their delivery routes and increase their efficiency. FoodZoom is built
 by 5 computer science student namely Rahul Rajesh, Julius Sander, Monika
 Monuela, Koh Chi Hao and Tan Jin Ying.
 
+FoodZoom’s core functionality includes:
+
+* Users being able to track food orders (visualise on a map) they have from customers
+* Managing deliverymen and assigning orders to them
+* Analysis of orders to display relevant statistics (order history, trending food etc.) to users
+
 
 .FoodZoom Home page
-image::Ui.png[width="800"]
+image::Ui.png[width="600"]
 
 == Summary of Contributions
 
@@ -96,4 +102,6 @@ include::../UserGuide.adoc[tag=deliverymanselect]
 technical documentation and the technical depth of my contributions to the project._
 |===
 
+include::../DeveloperGuide.adoc[tag=storagecomponent]
+
 include::../DeveloperGuide.adoc[tag=deliverymanaddfeature]