Merge pull request #307 from buddhavineeth/master

UG DG vet through and merge

docs/DeveloperGuide.adoc

@@ -30,6 +30,8 @@ Welcome on-board the Software Development Team for Calgo! Together, we will insp
 
 Refer to the guide <<SettingUp#, here>>.
 
+<<<
+
 == Design
 
 [[Design-Architecture]]
@@ -295,6 +297,8 @@ if (!model.hasLogWithSameDate(queryDate) || model.getLogByDate(queryDate).getFoo
 }
 ----
 
+<<<
+
 //tag:: Goal[]
 [[Implementation-GoalFeature]]
 === Setting daily calorie goals for motivation
@@ -353,6 +357,8 @@ Step 5: `LogicManager` then executes the `GoalCommand`, which in turn invokes `u
 Step 6: In `Model`, the `updateDailyGoal` method is a static method that generates a new `DailyGoal` object with the corresponding input. This `DailyGoal` object is returned to `Model`
 , which replaces the existing `DailyGoal` attribute of the `ModelManager` with the newly generated `DailyGoal` object.
 
+<<<
+
 ==== Design Considerations
 
 ===== Aspect: Type of user input data that is required for goal command
@@ -383,6 +389,8 @@ Refer to the Activity Diagram below for a visual summary of the logic behind the
 .Activity Diagram for `goal` command.
 image::GoalActivityDiagram.png[]
 
+<<<
+
 // tag::categoricalsubstringfindsearch[]
 [[Implementation-FindList]]
 === Searching for specific `Food` via categories and substrings
@@ -402,6 +410,8 @@ For more information on lexicographical ordering, please refer to its relevant s
 
 The above commands rely on the `FindCommand` and `ListCommand` objects respectively. Objects of both classes use a `Predicate<Food>` object to filter through the current `Food` objects, where `Food` objects will be displayed in the GUI's `Food Record` should they evaluate these predicates to be true.
 
+<<<
+
 ==== Implementation
 To search via a particular `Food` attribute, we use a `FindCommandParser` to create the corresponding `Predicate<Food>` based on which `Food` attribute the `Prefix` entered represents. This predicate is then used to construct a new `FindCommand` object, which changes the GUI display when executed. +
 
@@ -412,6 +422,8 @@ image::FindListCommandPredicateClassDiagram.png[]
 
 As seen in the above class diagram, each `Predicate<Food>` is indeed representative of either `Name`, `Calorie`, `Protein`, `Carbohydrate`, `Fat`, or `Tag`. Moreover, it should be noted that each of these predicates test against a `Food` object, and therefore have a dependency on `Food`.
 
+<<<
+
 The sequence diagram below demonstrates how the `find` command works, for both categorical and substring search:
 
 .Sequence Diagram for `find` command: Categorical Search and Substring Search
@@ -450,6 +462,8 @@ Step 2: `LogicManager` then calls the `execute` method of this `ListCommand`, wh
 
 Step 3:  `LogicManager` then returns a new `CommandResult` object to reflect the status of the execution, in the GUI. The GUI's `Food Record` reflects the above changes to show all `Food` entries once again.
 
+<<<
+
 ==== Design considerations
 
 ===== Aspect: Predicate construction source.
@@ -504,13 +518,18 @@ The `find` command performs a categorical search if a value from a nutritional c
 
 Meanwhile, the `list` command simply uses the predicate already defined in `Model` to display all `Food` objects. +
 
+<<<
+
 The above can be summarised in the activity diagram below:
 
 .Activity Diagram for Searching
 image::FindListCommandActivityDiagram.png[]
 
 // end::categoricalsubstringfindsearch[]
 
+
+<<<
+
 // tag::lexicographicalordering[]
 [[Implementation-LexicographicalOrder]]
 === Lexicographical `Food` order
@@ -626,8 +645,6 @@ model.updateFilteredFoodRecord(Model.PREDICATE_SHOW_ALL_FOODS);
 - More troublesome as we require self-defined methods, abstracted over the existing ones. If not careful, these self-defined methods can possibly contain violations of certain software engineering principles, which may introduce regression in the future.
 - May be inefficient in using resources.
 
-<<<
-
 ==== Summary
 
 The `UniqueFoodList` facilitates the lexicographical ordering of `Food` objects and hence how their respective entries appear in the GUI `Food Record`. This can be summarised in the activity diagram below:
@@ -636,6 +653,8 @@ The `UniqueFoodList` facilitates the lexicographical ordering of `Food` objects
 image::LexicographicalOrderingActivityDiagram.png[]
 // end::lexicographicalordering[]
 
+<<<
+
 // tag::exportfoodrecord[]
 [[Implementation-Export]]
 === Exporting the current `FoodRecord` into a portable file
@@ -681,6 +700,8 @@ Step 3: `ExportCommand` then calls the `generateExport` method of `ExportGenerat
 
 Step 4: A new `CommandResult` object indicating the result of the execution is then constructed and reflected in the GUI.
 
+<<<
+
 [[Design-Export]]
 ==== Design considerations
 
@@ -728,6 +749,8 @@ Step 4: A new `CommandResult` object indicating the result of the execution is t
 ** Cons:
 - Unable to reap benefits of the above alternatives.
 
+<<<
+
 ==== Summary
 
 In short, this section addresses how users are able to obtain an editable copy of the current `FoodRecord` using the `export` command.
@@ -741,6 +764,7 @@ image::ExportActivityDiagram.png[]
 
 // end::exportfoodrecord[]
 
+<<<
 
 [[Implementation-ConsumptionManagement]]
 === `Food` consumption management
@@ -788,6 +812,12 @@ Here is what happens when different classes call `toModelType`: +
 
 Below shows the high level view of the initialization process:
 
+
+[NOTE]
+For the subsequent sequence diagrams in the section,
+the lifelines for objects should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+
+
 .Sequence Diagram for loading of Consumption Record
 image::ConsumptionRecordSequenceDiagram.png[]
 
@@ -806,10 +836,6 @@ It specifically checks if there exists a `DailyFoodLog` with the same `LocalDate
 they are already present. From all these information, a `DailyFoodLog` object representing the result of consuming a `Food` is created, and supplied to create
 `NomCommand`. The diagram below shows how this happens:
 
-[NOTE]
-For the subsequent sequence diagrams in the section,
-the lifelines for objects should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
-
 .Sequence Diagram for parsing of Nom command
 image::NomCommandParserSequenceDiagram.png[]
 
@@ -1147,6 +1173,7 @@ image::RealTimeSuggestionActivityDiagram.png[]
 [[Implementation-HelpGuide]]
 //tag:: helpCommand[]
 === Command guide `help` command
+(by Janice)
 
 This section addresses how the `help` command works.