update dg

docs/DeveloperGuide.adoc

@@ -17,6 +17,23 @@ endif::[]
 
 By: `CS2113T T08-01`      Since: `Feb 2019`      Licence: `MIT`
 
+== Introduction
+
+=== About VolunCheer
+
+Codeducator is an open source Command Line Interface (CLI) address book and scheduling desktop application.
+We aim to provide a solution for private programming tutors to better manage their student contacts, tutoring schedule and track their students' learning progress.
+
+=== How to Contribute
+
+There are lots of ways to contribute to VolunCheer: coding, testing or improving our build process and tools. This developer's guide provides information that will help you get started as a VolunCheer contributor. Even if you are an experienced VolunCheer developer, you will still find this guide to be useful to refer to. +
+
+If you are ready to contribute, simply create a Pull Request (PR) on our main repository.
+
+If you have found any bugs or have ideas to improve Codeducator, create an issue https://github.com/cs2113-ay1819s2-t08-1/main/issues[here] or https://github.com/cs2113-ay1819s2-t08-1/main/blob/master/docs/AboutUs.adoc[contact us] directly.
+
+=== How to use this Develper Guide
+
 == Setting up
 
 === Prerequisites
@@ -54,7 +71,7 @@ This will generate all resources required by the application and tests.
 
 === Verifying the setup
 
-. Run the `seedu.Voluncheer.MainApp` and try a few commands
+. Run the `seedu.voluncheer.MainApp` and try a few commands
 . <<Testing,Run the tests>> to ensure they all pass.
 
 === Configurations to do before writing code
@@ -194,7 +211,7 @@ Classes used by multiple components are in the `seedu.voluncheerbook.commons` pa
 
 This section describes some noteworthy details on how certain features are implemented.
 
-// tag::Beneficiary Management[]
+// tag::BeneficiaryManagement[]
 === Beneficiary Management Feature
 ==== Implementation
 Beneficiary is implement in order to manage the information a benefited volunteer organization. These organizations interact
@@ -220,27 +237,52 @@ the hard mode, meaning that the respective projects that are attached to this be
 . The `ModelManager` is then called to update the deletion of the respective projects.
 . The `ModelManager` is then called to update the deletion of the beneficiary and update all the changes.
 
-==== Design Considerations
+The summarised statistics information of beneficiary based on their activeness is generated by using the summarised command.
+
+[NOTE]
+The activeness of a beneficiary is measured by the number of projects that beneficiary has collaborated with the user's organization
+
 
-===== Aspect: How often should the `UserClosestInput` refreshs itself
+The sequence diagram below shows how the summarise command works.
 
-* **Alternative 1 (current choice):** Everytime the [space] key is used.
-** Pros: Easy to implement.
-** Cons: Unable to dynamicly support the user.
-* **Alternative 2:** Everytime a new character is type.
-** Pros: Very dynamic in the UI and supporting the user.
-** Cons: Potential to cause lagging, harder to implement.
+.Summarise beneficiary command sequence diagram.
+image::SummaryBeneficiaryCommandSequenceDiagram.png[width=800]
 
-===== Aspect (proposed): Choices for user to quickly choose the recommendation
+. `SummaryBeneficiaryCommand` calls the `Model` to get the beneficiary list.
+. A summary list is generated and passed to `Logic`.
+. The Ui component which is `MainWindow` does handling of summarised list by generate a summary table and show on the screen.
 
-* **Alternative 1 (current choice):** [tab] when only 1 choice left.
-** Pros: Easy to implement.
-** Cons: Unoptimized for this particular purpose.
-* **Alternative 2:** Arrow key.
-** Pros: Good for user experiences.
-** Cons: Might be difficult to implement.
+==== Design Considerations
+
+[width="100%", cols="1, 1, 1 "options="header",]
+|=======================================================================
+| Aspect | Alternatives | Pros (+)/ Cons(-)
+.2+| Implementation of Synchronization
+| *Update the by linear search for designed object*
+| + : It is easier to implement because the code base are list based. Moreover, the use of the application is limited to only local
+use without a large amount of data. Hence, this method gives a good performance in the context. +
+    {empty} +
+ - : Unoptimized in terms of complexity, which requires more work for scaling of the application.
+| Hash Table of the data
+| + : It has a better time complexity and reduce the work in scaling stage since this data structure is more optimized (O(1) can be achieved). +
+  {empty} +
+  - : Take more resources to implement.
+
+.2+| Display and use of attached project list
+| The beneficiary card shows the list
+| + : The synchronization can be observed throughout the execution of commands. +
+    {empty} +
+ - : The beneficiary card is full with information and not reader friendly. Moreover, it is unnecessary to see the projects when operating single operations such as add, and edit
+
+| *Generation of summary table*
+| + : The summary gives a good way to look at the statistics of the beneficiary list. As it allows the dynamic of sorting in ascending or descending order
+of the list based on the beneficiary's activeness +
+  {empty} +
+  - : The adaptation of Ui is required.
 
-// end::recommendationCommandLine[]
+
+|=======================================================================
+// end::BeneficiaryManagement[]
 
 // tag::undoredo[]
 === Undo/Redo feature
@@ -303,23 +345,32 @@ image::UndoRedoActivityDiagram.png[width="650"]
 
 ==== Design Considerations
 
-===== Aspect: How undo & redo executes
-
-* **Alternative 1 (current choice):** Saves the entire Voluncheer 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 `deleteVolunteer`, just save the volunteer being deleted).
-** Cons: We must ensure that the implementation of each individual command are correct.
+[width="100%", cols="1, 1, 1 "options="header",]
+|=======================================================================
+| Aspect | Alternatives | Pros (+)/ Cons(-)
+.2+| How undo & redo executes
+| *Saves the entire Voluncheer book.*
+| + : Easy to implement. +
+    {empty} +
+ - :  May have performance issues in terms of memory usage.
+| Individual command knows how to undo/redo by itself.
+| + : Will use less memory (e.g. for `deleteVolunteer`, just save the volunteer being deleted).
+    {empty} +
+  - : We must ensure that the implementation of each individual command are correct.
+
+.2+| Data structure to support the undo/redo commands
+| *Use a list to store the history of Voluncheer book states.*
+| + : Easy for new Computer Science student undergraduates to understand, who are likely to be the new incoming developers of our project.+
+    {empty} +
+ - : Logic is duplicated twice. For example, when a new command is executed, we must remember to update both `HistoryManager` and `VersionedVoluncheerBook`.
+
+| Use `HistoryManager` for undo/redo
+| + : We do not need to maintain a separate list, and just reuse what is already in the codebase. +
+  {empty} +
+  - : 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.
 
-===== Aspect: Data structure to support the undo/redo commands
 
-* **Alternative 1 (current choice):** Use a list to store the history of Voluncheer 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 `VersionedVoluncheerBook`.
-* **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::projectcalendar[]
@@ -863,7 +914,7 @@ Use case ends.
 Use case ends.
 
 [discrete]
-=== Use case 10: Add beneficiary
+=== Use case 10: Add a beneficiary
 
 *MSS*
 
@@ -875,14 +926,61 @@ Use case ends.
 *Extensions*
 
 [none]
-* 2a. The beneficiary has existed, show edit option
+* 2a. The beneficiary has existed, show error message
 +
 Use case ends.
 
-* 3a. The given command line is invalid.
+* 2b. The given command line is invalid.
 +
 [none]
-** 3a1. VoluncheerBook shows an error message.
+** 2b1. VoluncheerBook shows an error message.
++
+Use case ends.
+
+[discrete]
+=== Use case 11: Edit a beneficiary
+
+*MSS*
+
+1.  Users requests to edit a beneficiary.
+2.  VolunCheer shows the successful edit message.
++
+Use case ends.
+
+*Extensions*
+
+[none]
+* 2a. The beneficiary is not existed.
++
+[none]
+** 2a1. VolunCheer shows an error message.
++
+Use case ends.
+
+=== Use case 12: Delete a beneficiary (soft delete)
+
+*MSS*
+
+1.  Users requests to delete a beneficiary.
+2.  VolunCheer shows the successful delete message.
++
+Use case ends.
+
+*Extensions*
+
+[none]
+* 2a. The beneficiary is not existed.
++
+[none]
+** 2a1. VolunCheer shows an error message.
++
+Use case ends.
+
+[none]
+* 2b. The beneficiary has attached projects.
++
+[none]
+** 2b1. VolunCheer shows an error message.
 +
 Use case ends.