Merge pull request #238 from rocketninja7/dg-draft

Update DG

docs/DeveloperGuide.md

@@ -31,7 +31,7 @@ Refer to the guide [_Setting up and getting started_](SettingUp.md).
 
 ### Architecture
 
-<puml src="diagrams/ArchitectureDiagram.puml" width="280" />
+<puml src="diagrams/ArchitectureDiagram.puml" width="400" />
 
 The ***Architecture Diagram*** given above explains the high-level design of the App.
 
@@ -51,8 +51,8 @@ The bulk of the app's work is done by the following four components:
 * [**`Logic`**](#logic-component): The command executor.
 * [**`Model`**](#model-component): Holds the data of the App in memory.
 * [**`Storage`**](#storage-component): Reads data from, and writes data to, the hard disk.
-* [**`Database`**](#database-component) : Parses data from within the App.
 
+[**`Database`**](#database-component) parses data from within the App on startup. This data is used to support user input validation according to the business logic.<br>
 [**`Commons`**](#common-classes) represents a collection of classes used by multiple other components.
 
 <br>
@@ -63,7 +63,7 @@ The *Sequence Diagram* below shows how the components interact with each other f
 
 <puml src="diagrams/ArchitectureSequenceDiagram.puml" width="574" />
 
-Each of the four main components (also shown in the diagram above),
+Each of the four main components (also shown in the diagram above), as well as the [**`Database`**](#database-component) component,
 
 * defines its *API* in an `interface` with the same name as the Component.
 * implements its functionality using a concrete `{Component Name}Manager` class (which follows the corresponding API `interface` mentioned in the previous point.
@@ -116,7 +116,7 @@ The sequence diagram below illustrates the interactions within the `Logic` compo
 
 How the `Logic` component works:
 
-1. When `Logic` is called upon to execute a command, it is passed to an `ModulePlanParser` object which in turn creates a parser that matches the command (e.g., `DeleteCommandParser`) and uses it to parse the command.
+1. When `Logic` is called upon to execute a command, it is passed to a `ModulePlanParser` object which in turn creates a parser that matches the command (e.g., `DeleteCommandParser`) and uses it to parse the command.
 1. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `DeleteCommand`) which is executed by the `LogicManager`.
 1. The command can communicate with the `Model` when it is executed (e.g. to delete a person).
 1. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`.
@@ -151,7 +151,7 @@ The `Model` component,
 
 <box type="info" seamless>
 
-**Note:** The module plan data is split into different semesters (e.g. Year 1 S1, Year 1 S2, Year 2 S1, etc). Instead of one `UniqueModuleList` storing all of the User's modules across multiple semesters, each semester's modules are stored in their own `UniqueModuleList` object. Nevertheless, modules are required to be unique across semesters, meaning that the same module will be prevented from being added to multiple semesters.
+**Note:** The module plan data is split into different semesters (e.g. Year 1 S1, Year 1 S2, Year 2 S1, etc). Instead of one `UniqueModuleList` storing all of the user's modules across multiple semesters, each semester's modules are stored in their own `UniqueModuleList` object. Nevertheless, modules are required to be unique across semesters, meaning that the same module will be prevented from being added to multiple semesters. The implementation of this check can be found in `ModulePlanSemesterList`.
 
 </box>
 
@@ -168,7 +168,7 @@ The `Model` component,
 The `Storage` component,
 * can save both address book data and user preference data in JSON format, and read them back into corresponding objects.
 * inherits from both `AddressBookStorage` and `UserPrefStorage`, which means it can be treated as either one (if only the functionality of only one is needed).
-* depends on some classes in the `Model` component (because the `Storage` component's job is to save/retrieve objects that belong to the `Model`)
+* depends on some classes in the `Model` component (because the `Storage` component's job is to save/retrieve modifiable objects that belong to the `Model`)
 
 <br>
 
@@ -182,7 +182,7 @@ The `Storage` component,
 
 The `Database` component,
 * reads the module information from JSON format to the corresponding `ModuleData` object.
-* depends on some classes in the `Model` component (because the `Database` component's job is to retrieve objects that belong to the `Model`)
+* depends on some classes in the `Model` component (because the `Database` component's job is to retrieve read-only objects that belong to the `Model`)
 
 <box type="info" seamless>
 
@@ -589,7 +589,7 @@ testers are expected to do more *exploratory* testing.
     4. Test case: `add CS1010 y/1 s/ST1 g/a`.<br>
        Expected: No module is added. Error details of wrong format of grade shown in the status message. Status bar remains the same.
 
-    3. Other incorrect delete commands to try: `add`, `add 1234`, `add CS1010 y/1`, `...` (when the format of the module code to be added is incorrect)<br>
+    3. Other incorrect add commands to try: `add`, `add 1234`, `add CS1010 y/1`, `...` (when the format of the module code to be added is incorrect)<br>
        Expected: Similar to previous.
 
 <br>

docs/diagrams/ArchitectureDiagram.puml

@@ -16,6 +16,7 @@ Package " "<<Rectangle>>{
 
 Class "<$user>" as User MODEL_COLOR_T2
 Class "<$documents>" as File UI_COLOR_T1
+Class "<$documents>" as File2 UI_COLOR_T2
 
 
 UI -[#green]> Logic
@@ -32,5 +33,7 @@ Storage -down[hidden]-> Commons
 
 Storage -up[STORAGE_COLOR].> Model
 Storage .right[STORAGE_COLOR].>File
+Database -up[STORAGE_COLOR].> Model
+Database .left[STORAGE_COLOR].>File2
 User ..> UI
 @enduml

docs/diagrams/ParserClasses.puml

@@ -32,7 +32,6 @@ ArgumentTokenizer .left.> ArgumentMultimap
 XYZCommandParser ..> CliSyntax
 CliSyntax ..> Prefix
 XYZCommandParser ..> ParserUtil
-ParserUtil .down.> Prefix
 ArgumentTokenizer .down.> Prefix
 XYZCommand -up-|> Command
 @enduml

docs/diagrams/StorageClassDiagram.puml

@@ -14,10 +14,10 @@ Class JsonUserPrefsStorage
 Class "<<interface>>\nStorage" as Storage
 Class StorageManager
 
-package "AddressBook Storage" #F4F6F6{
-Class "<<interface>>\nAddressBookStorage" as AddressBookStorage
-Class JsonAddressBookStorage
-Class JsonSerializableAddressBook
+package "ModulePlan Storage" #F4F6F6{
+Class "<<interface>>\nModulePlanStorage" as ModulePlanStorage
+Class JsonModulePlanStorage
+Class JsonSerializableModulePlan
 Class JsonAdaptedModule
 }
 
@@ -28,15 +28,15 @@ HiddenOutside ..> Storage
 
 StorageManager .up.|> Storage
 StorageManager -up-> "1" UserPrefsStorage
-StorageManager -up-> "1" AddressBookStorage
+StorageManager -up-> "1" ModulePlanStorage
 
 Storage -left-|> UserPrefsStorage
-Storage -right-|> AddressBookStorage
+Storage -right-|> ModulePlanStorage
 
 JsonUserPrefsStorage .up.|> UserPrefsStorage
-JsonAddressBookStorage .up.|> AddressBookStorage
-JsonAddressBookStorage ..> JsonSerializableAddressBook
-JsonSerializableAddressBook --> "*" JsonAdaptedModule
+JsonModulePlanStorage .up.|> ModulePlanStorage
+JsonModulePlanStorage ..> JsonSerializableModulePlan
+JsonSerializableModulePlan --> "*" JsonAdaptedModule
 
 
 @enduml

src/main/java/seedu/address/logic/commands/AddCommand.java

@@ -61,7 +61,7 @@ public AddCommand(ModuleCode moduleCode, Year year, Semester semester, Grade gra
     @Override
     public CommandResult execute(Model model) throws CommandException {
         requireNonNull(model);
-        // Retieve module from database
+        // Retrieve module from database
         Module newModule;
         try {
             newModule = model.getModuleFromDb(moduleCode);