diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index c678d95f628..b0a702b6ff0 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -145,6 +145,8 @@ The `Person` component, +
+ #### 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) +
+ 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) +
+ 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) diff --git a/docs/team/kumchaiyin.md b/docs/team/kumchaiyin.md index f5bc2d2aa09..baa45c79a0a 100644 --- a/docs/team/kumchaiyin.md +++ b/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.