CS2113-AY1819S1-W12-4 · LIU-TIANHANG · Nov 12, 2018 · Oct 30, 2018 · Oct 30, 2018 · Oct 30, 2018
diff --git a/README.adoc b/README.adoc
@@ -32,9 +32,10 @@ endif::[]
 * <<AboutUs#, About Us>>
 * <<ContactUs#, Contact Us>>
 * https://cs2113-ay1819s1-w12-4.github.io/main/AccountantUserGuide.html[Accountant user guide]
-* https://cs2113-ay1819s1-w12-4.github.io/main/ManagerUserGuide.html [Manager user guide]
-* https://cs2113-ay1819s1-w12-4.github.io/main/StockTakerUserGuide.html [Stock taker user guide]
-* https://cs2113-ay1819s1-w12-4.github.io/main/AdminUserGuide.html [Admin user guide]
+* https://cs2113-ay1819s1-w12-4.github.io/main/ManagerUserGuide.html[Manager user guide]
+* https://cs2113-ay1819s1-w12-4.github.io/main/StockTakerUserGuide.html[Stock taker user guide]
+* https://cs2113-ay1819s1-w12-4.github.io/main/AdminUserGuide.html[Admin user guide]
+
 
 == Acknowledgements
 * Original source of code: Addressbook-Level4 project created by SE-EDU initiative at [https://github.com/se-edu]

diff --git a/docs/DeveloperGuide.adoc b/docs/DeveloperGuide.adoc
@@ -375,6 +375,25 @@ is within the desired time period
 
 // end::analyses[]
 
+//tag::commandPartition[]
+=== Command partition
+
+==== Current Implementation
+
+The command partition is an implementation of the role system.
+
+The `model` contain all the
+API that is common for every user. `StockTakerModel` contains API for for stockTaker. Similar
+idea applied to `AccountantModel` and `ManagerModel`. However, `AdminModel` extends all three models.
+As such, `adminModel` will contains all APIs.
+
+.Class diagram for Login related model
+image::LoginUMLDiagram/Logic-UML-design-Login.png[width="800"]
+
+After login, `logicManager` will assign a particular role to user according to their
+`authenticationLevel`. As such, it will prevent one role from accessing other role's
+command.
+//end::commandPartition[]
 
 //tag::login[]
 === Login/logout feature
@@ -383,28 +402,41 @@ is within the desired time period
 
 The login feature is a standalone feature that enable security check on user. It has a fxml page that name `LoginPage.fxml` at `main\resources\view`
 The controller of the fxml page named `LoginController` at `seedu.address\controller`
+The model of is at `loginInfo` which storage the format in JSON with the help of `JsonUtils`.
+Also, there is a `loginInfoManager` which include all the API for `loginInfo`.
+As such, this is a design that fulfil the Model-View-Controller pattern.
 
-Given below is a class diagram for login function
+Given below is a class diagram for login function. LoginUtils has attributes of `LoginInfoModel`
+ `userName` and `Password`. It also use `passwordUtils` to hashed verify the password with `LoginInfoModel`
 
+.Class diagram for Login related Utils
 image::LoginUMLDiagram/Login_Class_Diagram.png[width="800"]
 
 
 Given below is an example usage scenario and how login mechanism behave at each step.
 
-image::LoginUMLDiagram/Login_sequence_diagram.png[width="800"]
-The `LoginController` will check for username and password will the LoginUtils
-Once the username and password is correct, it will continue to `InventoryListInitializer`.
-It will also start the ui.
+image::LoginUMLDiagram/Login_sequence_diagram.png[width="600" height ="400"]
+The `LoginController` will check for username and password will the `LoginUtils`.
 
 
-image::LoginUMLDiagram/LoginUtils_Sequence_Diagram.png[width="800"]
-Given below is an example of access login information for `loginInfoList.json` during initiation of the application.
+image::LoginUMLDiagram/LoginUtils_Sequence_Diagram.png[width="600" height ="400"]
 
-image::LoginUMLDiagram/LoginList_Read_Sequence_Diagram.png[width="800"]
+=== Save information about user account
+Given below is a structure of `Model` components that is related to login feature.
+The model stores loginInfo of the user.
 
-Given below is an example of relogin under different account. `InventoryListInitializer` will call three event list below.
+image::LoginUMLDiagram/Logic_LoginInfo_Model.png[width="800" height "200"]
+
+The sequence diagram below shows the interactions within the logic components for the execuion of `createAccount` command.
+
+
+image::LoginUMLDiagram/createAccountSequenceDiagram.png[width="800"]
+
+Given below is an sequence diagram of access login information for `loginInfoList.json` during initiation of the application.
+The program also save the the login information to `loginInfoList.json` when `logout` or `exit`.
+
+image::LoginUMLDiagram/Logic-UML-design-ReadLoginInfoList.png[width="800" height ="400"]
 
-image::LoginUMLDiagram/ReLoginEvent_sequence_diagram.png[width="800"]
 
 ==== Design Considerations
 ===== Aspect: How to store the data
@@ -418,101 +450,17 @@ image::LoginUMLDiagram/ReLoginEvent_sequence_diagram.png[width="800"]
 ===== Aspect: Data format for store data
 
 * **Alternative 1 (current choice):** Store in Json file.
-** Pros: Json is popular and have have support online.
+** Pros: Json is popular and have many support online.
 ** Pros :JSON is relatively easier to implement compared to XML
 ** Cons: Have to write serialized method for JSON file.
 * **Alternative 2:** Store in XML file
 ** Pros: Classic and matured product
 ** Pros: Have serialized code in original ab4.
-** Cons: It has many rule to set before implementation.
+** Cons: It has many rules to set before implementation.
 //end::login[]
 
-// tag::undoredo[]
-=== Undo/Redo feature
-==== Current Implementation
-
-The undo/redo mechanism is facilitated by `VersionedAddressBook`.
-It extends `AddressBook` with an undo/redo history, stored internally as an `addressBookStateList` and `currentStatePointer`.
-Additionally, it implements the following operations:
-
-* `VersionedAddressBook#commit()` -- Saves the current address book state in its history.
-* `VersionedAddressBook#undo()` -- Restores the previous address book state from its history.
-* `VersionedAddressBook#redo()` -- Restores a previously undone address book state from its history.
-
-These operations are exposed in the `Model` interface as `Model#commitAddressBook()`, `Model#undoAddressBook()` and `Model#redoAddressBook()` respectively.
-
-Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.
-
-Step 1. The user launches the application for the first time. The `VersionedAddressBook` will be initialized with the initial address book state, and the `currentStatePointer` pointing to that single address book state.
-
-image::UndoRedoStartingStateListDiagram.png[width="800"]
-
-Step 2. The user executes `delete 5` command to delete the 5th person in the address book. The `delete` command calls `Model#commitAddressBook()`, causing the modified state of the address book after the `delete 5` command executes to be saved in the `addressBookStateList`, and the `currentStatePointer` is shifted to the newly inserted address book state.
-
-image::UndoRedoNewCommand1StateListDiagram.png[width="800"]
-
-Step 3. The user executes `add n/David ...` to add a new person. The `add` command also calls `Model#commitAddressBook()`, causing another modified address book state to be saved into the `addressBookStateList`.
-
-image::UndoRedoNewCommand2StateListDiagram.png[width="800"]
-
-[NOTE]
-If a command fails its execution, it will not call `Model#commitAddressBook()`, so the address book state will not be saved into the `addressBookStateList`.
-
-Step 4. The user now decides that adding the person was a mistake, and decides to undo that action by executing the `undo` command. The `undo` command will call `Model#undoAddressBook()`, which will shift the `currentStatePointer` once to the left, pointing it to the previous address book state, and restores the address book to that state.
-
-image::UndoRedoExecuteUndoStateListDiagram.png[width="800"]
-
-[NOTE]
-If the `currentStatePointer` is at index 0, pointing to the initial address book state, then there are no previous address book states to restore. The `undo` command uses `Model#canUndoAddressBook()` to check if this is the case. If so, it will return an error to the user rather than attempting to perform the undo.
-
-The following sequence diagram shows how the undo operation works:
-
-image::UndoRedoSequenceDiagram.png[width="800"]
-
-The `redo` command does the opposite -- it calls `Model#redoAddressBook()`, which shifts the `currentStatePointer` once to the right, pointing to the previously undone state, and restores the address book to that state.
-
-[NOTE]
-If the `currentStatePointer` is at index `addressBookStateList.size() - 1`, pointing to the latest address book state, then there are no undone address book states to restore. The `redo` command uses `Model#canRedoAddressBook()` to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo.
-
-Step 5. The user then decides to execute the command `list`. Commands that do not modify the address book, such as `list`, will usually not call `Model#commitAddressBook()`, `Model#undoAddressBook()` or `Model#redoAddressBook()`. Thus, the `addressBookStateList` remains unchanged.
-
-image::UndoRedoNewCommand3StateListDiagram.png[width="800"]
-
-Step 6. The user executes `clear`, which calls `Model#commitAddressBook()`. Since the `currentStatePointer` is not pointing at the end of the `addressBookStateList`, all address book states after the `currentStatePointer` will be purged. We designed it this way because it no longer makes sense to redo the `add n/David ...` command. This is the behavior that most modern desktop applications follow.
-
-image::UndoRedoNewCommand4StateListDiagram.png[width="800"]
-
-The following activity diagram summarizes what happens when a user executes a new command:
-
-image::UndoRedoActivityDiagram.png[width="650"]
-
-==== Design Considerations
-
-===== Aspect: How undo & redo executes
-
-* **Alternative 1 (current choice):** Saves the entire address 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 `delete`, just save the person being deleted).
-** Cons: We must ensure that the implementation of each individual command are correct.
-
-===== Aspect: Data structure to support the undo/redo commands
-
-* **Alternative 1 (current choice):** Use a list to store the history of address 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 `VersionedAddressBook`.
-* **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::dataencryption[]
-=== [Proposed] Data Encryption
 
-_{Explain here how the data encryption feature will be implemented}_
 
-// end::dataencryption[]
 
 === Logging
 

diff --git a/docs/images/LoginUMLDiagram/Logic-UML-design-Login.png b/docs/images/LoginUMLDiagram/Logic-UML-design-Login.png
diff --git a/docs/images/LoginUMLDiagram/Logic-UML-design-ReadLoginInfoList.png b/docs/images/LoginUMLDiagram/Logic-UML-design-ReadLoginInfoList.png
diff --git a/docs/images/LoginUMLDiagram/Logic_LoginInfo_Model.png b/docs/images/LoginUMLDiagram/Logic_LoginInfo_Model.png
diff --git a/docs/images/LoginUMLDiagram/Login_Sequence_Diagram.png b/docs/images/LoginUMLDiagram/Login_Sequence_Diagram.png
diff --git a/docs/images/LoginUMLDiagram/Login_sequence_diagram.png b/docs/images/LoginUMLDiagram/Login_sequence_diagram.png
diff --git a/docs/images/LoginUMLDiagram/createAccountSequenceDiagram.png b/docs/images/LoginUMLDiagram/createAccountSequenceDiagram.png
diff --git a/docs/team/johndoe.adoc b/docs/team/johndoe.adoc
diff --git a/docs/team/liu-tianhang.adoc b/docs/team/liu-tianhang.adoc
@@ -62,5 +62,6 @@ include::../UserGuide.adoc[tag=account]
 |===
 |_Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project._
 |===
-
+include::../DeveloperGuide.adoc[tag=commandPartition]
 include::../DeveloperGuide.adoc[tag=login]
+
diff --git a/docs/team/lunastryke.adoc b/docs/team/lunastryke.adoc
@@ -78,9 +78,6 @@ include::../UserGuide.adoc[tag=viewDrinkDetails]
 |_Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project._
 |===
 
-include::../DeveloperGuide.adoc[tag=undoredo]
-
-include::../DeveloperGuide.adoc[tag=dataencryption]
 
 
 == PROJECT: PowerPointLabs