Merge pull request #272 from KumChaiYin/254-DG-pdf

Modify format DG 3

docs/DeveloperGuide.md

@@ -145,6 +145,8 @@ The `Person` component,
 
 </div>
 
+<div style="page-break-after: always;"></div>
+
 #### Design considerations
 **Aspect: Whether `Policy` should be a class of its own**
 * Alternative 1: Add policy fields directly as attributes of `Person`
@@ -282,6 +284,8 @@ The following sequence diagram shows how the `remind` command works:
 
 ![RemindSequenceDiagram2](images/RemindSequenceDiagram2.png)
 
+<div style="page-break-after: always;"></div>
+
 The following activity diagram summarises what happens when a user executes the command `remind 30`:
 
 ![RemindActivityDiagram](images/RemindActivityDiagram.png)
@@ -411,6 +415,8 @@ Step 5. The user then decides to execute the command `list`. Commands that do no
 
 ![UndoRedoState4](images/UndoRedoState4.png)
 
+<div style="page-break-after: always;"></div>
+
 Step 6. The user executes `clear`, which calls `Model#commitAddressBook()`. Since the `currentStatePointer` is not pointing at the end of the `addressBookStateList`, all client list states after the `currentStatePointer` will be purged. Reason: It no longer makes sense to redo the `add n/David …​` command. This is the behavior that most modern desktop applications follow.
 
 ![UndoRedoState5](images/UndoRedoState5.png)

docs/team/kumchaiyin.md

@@ -28,7 +28,7 @@ Given below are my contributions to the project.
   * Did the UI mockup of our intended final product
   * Took the initiative to modify sequence diagram in DG
     * Used ref frame to break complicated sequence diagram into two parts
-  * Prepared pdf files of UG, DG, PPP and ensure their quality.
+  * Prepared pdf files of UG and DG, and ensured their quality.
 
 * **Enhancements to existing features**:
   * Extended the current `add` command to deal with the updated `Person` fields as listed below.