Merge pull request #117 from CheahYan/Update-DevGuide

Update dev guide

docs/DeveloperGuide.md

@@ -154,6 +154,59 @@ Classes used by multiple components are in the `seedu.addressbook.commons` packa
 
 This section describes some noteworthy details on how certain features are implemented.
 
+###  Revenue feature
+
+#### Current Implementation
+{:.no_toc}
+
+A client's revenue is currently represented by the `revenue` field under `Person`,
+which is represented by a `Revenue` object.
+
+The `Revenue` object contains a `Money` field called `value` which represents the amount 
+of money in Singapore Dollars(SGD) that the user earned from the client. This `value` can 
+never be null.
+
+<img src="images/RevenueClassDiagram.png" width="300" />
+
+The processing of a revenue command from the user can be split into 2 general steps:
+1. Parsing the user input into a `RevenueCommand`
+2. Executing the `RevenueCommand`
+
+Each step will be described in the sections below.
+
+**Step 1**: Parsing of user input
+
+Parsing of the user input is primarily handled by the `RevenueCommandParser` which calls other
+helper classes to parse the text into the data classes `Index` and `Revenue`.
+
+<img src="images/RevenueCommandParserSequenceDiagram.png" width="800" />
+
+`RevenueCommandParser` then creates a `RevenueCommand` using the `Index` and `Revenue` objects created.
+
+**Step 2**: Executing the RevenueCommand
+
+<img src="images/RevenueCommandExecuteActivityDiagram.png" width="300" />
+
+There are 2 possible outcomes from the execution of a RevenueCommand.
+
+1. Add a new revenue to the client
+2. No changes to the client's revenue after a RevenueCommand as the total value of
+the new revenue and client's original revenue is negative
+
+#### Design considerations
+{:.no_toc}
+
+*Aspect*: User interface of adding and editing revenue.
+
+* **Alternative 1 (Current Choice):** `revenue` command adds to existing `revenue`
+of client. `edit` command sets the `revenue` of client.
+  * Pros: Easier to implement
+  * Cons: User has to remember a lot of commands and to also understand the differences
+  between each command
+* **Alternative 2:** One `revenue` command adds and edits
+  * Pros: Fewer commands for the user to remember
+  * Cons: It will be difficult to give proper error messages since we are not sure
+  of the user's intentions
 ### Add command
 
 A user can use the add command to add a clients. A sequence diagram of this action is as shown:

docs/diagrams/RevenueClassDiagram.puml

@@ -0,0 +1,26 @@
+@startuml
+!include style.puml
+skinparam arrowThickness 1.1
+skinparam arrowColor MODEL_COLOR
+skinparam classBackgroundColor MODEL_COLOR
+
+package Logic {
+class RevenueCommand
+}
+
+
+package Model {
+class Revenue
+class Index
+class Revenue
+}
+
+package Commons {
+class Money
+}
+
+RevenueCommand --> "1" Index
+RevenueCommand --> "1" Revenue
+Revenue --> "1" Money
+
+@enduml

docs/diagrams/RevenueCommandExecuteActivityDiagram.puml

@@ -0,0 +1,15 @@
+@startuml
+!include style.puml
+start
+:Get client at index;
+:Add input revenue to the client's revenue;
+
+if () then ([total revenue is negative])
+    :Revert client's revenue back to the \nvalue before the addition;
+else ([else])
+    :Create new Revenue with the \nvalue of total revenue;
+endif
+:Return CommandResult;
+stop
+
+@enduml

docs/diagrams/RevenueCommandParserSequenceDiagram.puml

@@ -0,0 +1,74 @@
+@startuml
+!include style.puml
+
+Participant ":AddressBookParser" as addressBookParser LOGIC_COLOR_T2
+Participant ":RevenueCommandParser" as revenueCommandParser LOGIC_COLOR
+Participant "argMultimap:ArgumentMultimap" as argumentMultimap LOGIC_COLOR_T1
+Participant "<<class>>\nParserUtil" as util LOGIC_COLOR_T3
+Participant "revenue:Revenue" as revenue MODEL_COLOR
+Participant ":Money" as money MODEL_COLOR
+Participant ":RevenueCommand" as command LOGIC_COLOR_T4
+
+
+addressBookParser -[LOGIC_COLOR_T2]> revenueCommandParser : parse("1 r/100.21")
+activate addressBookParser LOGIC_COLOR_T2
+activate revenueCommandParser LOGIC_COLOR
+
+create argumentMultimap
+revenueCommandParser -[LOGIC_COLOR]> argumentMultimap : ArgumentTokenizer.tokenize("1 r/100.21", PREFIX_REVENUE)
+activate argumentMultimap LOGIC_COLOR_T1
+
+argumentMultimap -[LOGIC_COLOR]-> revenueCommandParser
+deactivate argumentMultimap
+
+revenueCommandParser -[LOGIC_COLOR]> util :parseIndex(argMultimap.getPreamble())
+activate util LOGIC_COLOR_T3
+
+util -[LOGIC_COLOR]> argumentMultimap:getPreamble()
+activate argumentMultimap LOGIC_COLOR_T1
+
+argumentMultimap -[LOGIC_COLOR]-> util
+deactivate argumentMultimap
+
+util -[LOGIC_COLOR_T3]-> revenueCommandParser :index
+deactivate util
+
+revenueCommandParser -[LOGIC_COLOR]> util :parseRevenue(argMultimap.getValue(PREFIX_REVENUE).get())
+activate util LOGIC_COLOR_T3
+
+util -[LOGIC_COLOR]> argumentMultimap:getValue(PREFIX_REVENUE).get()
+activate argumentMultimap LOGIC_COLOR_T1
+
+argumentMultimap -[LOGIC_COLOR]-> util
+deactivate argumentMultimap
+
+create revenue
+util -[LOGIC_COLOR_T3]-> revenue: Revenue(new Money(number))
+activate revenue MODEL_COLOR
+
+create money
+revenue -[LOGIC_COLOR_T3]> money: Money(number)
+activate money MODEL_COLOR
+
+money -[LOGIC_COLOR_T3]-> revenue
+deactivate money
+
+revenue -[MODEL_COLOR]-> util
+deactivate revenue
+
+util -[LOGIC_COLOR_T3]-> revenueCommandParser
+deactivate util
+
+create command
+revenueCommandParser -[LOGIC_COLOR]> command :RevenueCommand(index, revenue)
+activate command LOGIC_COLOR_T4
+
+command -[LOGIC_COLOR_T4]-> revenueCommandParser : RevenueCommand
+deactivate command
+
+revenueCommandParser -[LOGIC_COLOR]-> addressBookParser: RevenueCommand
+deactivate revenueCommandParser
+
+deactivate addressBookParser
+
+@enduml