From 3071f4870c8af9de67650b43418b659272295f20 Mon Sep 17 00:00:00 2001 From: Atharv Joshi <31906592+atharvjoshi@users.noreply.github.com> Date: Wed, 23 Oct 2019 23:04:47 +0800 Subject: [PATCH 1/2] Update DeveloperGuide.adoc --- docs/DeveloperGuide.adoc | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/DeveloperGuide.adoc b/docs/DeveloperGuide.adoc index 43757dd59d2..505d3fb2c54 100644 --- a/docs/DeveloperGuide.adoc +++ b/docs/DeveloperGuide.adoc @@ -318,8 +318,8 @@ The incident draft creation mechanism is facilitated by the New Command. It crea // end::incidentdraftcreation[] // tag::incidentfill[] -=== [Proposed] Incident Filling and Submission feature -==== Proposed Implementation +=== Incident Filling and Submission feature +==== Implementation The incident filling and submission subroutines are facilitated by the `fill` and `submit` commands respectively. In the IMS, each incident can have one of three statuses - `DRAFT`, `COMPLETE`, and `FINAL`. The `fill` command facilitates a `DRAFT` incident report becoming a `COMPLETE` incident report while the `submit` command facilitates a `COMPLETE` incident report becoming a `FINAL` incident report. ===== Overview of `Fill` and `Submit` @@ -333,9 +333,11 @@ In this mode, the command - `fill` or `submit` - actually fills (i.e. changes in These two commands as well as the two modes they can be used in are summarised in the activity diagrams below: Fill Command + image::fillCommandActivityDiagram.png[] Submit Command + image::submitCommandActivityDiagram.png[] ===== No parameter mode (listing incidents) From 259e2f3457e94155b595dc1a764b49d729804830 Mon Sep 17 00:00:00 2001 From: Atharv Joshi <31906592+atharvjoshi@users.noreply.github.com> Date: Wed, 23 Oct 2019 23:19:14 +0800 Subject: [PATCH 2/2] Update DeveloperGuide.adoc --- docs/DeveloperGuide.adoc | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/DeveloperGuide.adoc b/docs/DeveloperGuide.adoc index 505d3fb2c54..1f768029e04 100644 --- a/docs/DeveloperGuide.adoc +++ b/docs/DeveloperGuide.adoc @@ -342,12 +342,15 @@ image::submitCommandActivityDiagram.png[] ===== No parameter mode (listing incidents) The `IncidentManagerParser` will return a new `FillCommand` which has its fields `targetIndex`, `callerNumber`, and `description` initialised to null (as they won't be required). The `execute()` method in `FillCommand` checks for these null conditions and simply displays the list of incidents filtered according to whether they are `DRAFT` or not. -TODO - SEQUENCE DIAGRAM FOR FILL COMMAND WITHOUT PARAMETERS + +image::fillCommandSequenceDiagramWithParams.png + The `SubmitCommand` functions similarly, this time listing the incidents filtered by whether they are `COMPLETE` or not. ===== Parameter mode (modifying incidents) The `FillCommandParser` will be invoked to parse the fields `targetIndex`, `callerNumber`, and `description` and return a `FillCommand` containing these non-null fields. The `execute()` method in `FillCommand` will now fetch the specified incident from the list of drafts and call the static `updateReport()` method. The `updateReport()` method creates a new Incident object which has all its required attributes filled. The attributes from the incident to be updated are simply copied into this new Incident object. The fill command then inserts this new Incident into the list of incidents at the same index. The `SubmitCommand` functions similarly, with one crucial difference. As no Incident fields are to be updated, the specified incident is simply retrieved, marked as `FINAL` using the static `submitReport()` method, and inserted into the list of incidents at the same index again. The `submitReport` method also creates a new Incident object which is a copy of the Incident to be submitted, with the difference being that the newly created Incident is marked `FINAL`. -TODO - SEQUENCE DIAGRAM FOR FILL COMMAND WITH PARAMETERS + +image::fillCommandSequenceDiagramWithoutParams.png ==== Design Considerations