From 541a23d8b9c2e22ece3692a50ec211212bbfff0f Mon Sep 17 00:00:00 2001 From: rocketninja7 Date: Thu, 9 Nov 2023 17:41:20 +0800 Subject: [PATCH 1/4] Update DG from start to right before Model --- docs/DeveloperGuide.md | 8 ++++---- docs/diagrams/ArchitectureDiagram.puml | 3 +++ docs/diagrams/ParserClasses.puml | 9 ++++----- 3 files changed, 11 insertions(+), 9 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 30822572829..329ffedae2a 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -27,7 +27,7 @@ Refer to the guide [_Setting up and getting started_](SettingUp.md). ### Architecture - + The ***Architecture Diagram*** given above explains the high-level design of the App. @@ -45,8 +45,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. [**`Commons`**](#common-classes) represents a collection of classes used by multiple other components. **How the architecture components interact with each other** @@ -55,7 +55,7 @@ The *Sequence Diagram* below shows how the components interact with each other f -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. @@ -102,7 +102,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`. diff --git a/docs/diagrams/ArchitectureDiagram.puml b/docs/diagrams/ArchitectureDiagram.puml index 5e7e65fe7d2..95577217804 100644 --- a/docs/diagrams/ArchitectureDiagram.puml +++ b/docs/diagrams/ArchitectureDiagram.puml @@ -16,6 +16,7 @@ Package " "<>{ 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 diff --git a/docs/diagrams/ParserClasses.puml b/docs/diagrams/ParserClasses.puml index 0c7424de6e0..fb3f3a93d6d 100644 --- a/docs/diagrams/ParserClasses.puml +++ b/docs/diagrams/ParserClasses.puml @@ -9,7 +9,7 @@ Class XYZCommand package "Parser classes"{ Class "<>\nParser" as Parser -Class AddressBookParser +Class ModulePlanParser Class XYZCommandParser Class CliSyntax Class ParserUtil @@ -19,12 +19,12 @@ Class Prefix } Class HiddenOutside #FFFFFF -HiddenOutside ..> AddressBookParser +HiddenOutside ..> ModulePlanParser -AddressBookParser .down.> XYZCommandParser: creates > +ModulePlanParser .down.> XYZCommandParser: creates > XYZCommandParser ..> XYZCommand : creates > -AddressBookParser ..> Command : returns > +ModulePlanParser ..> Command : returns > XYZCommandParser .up.|> Parser XYZCommandParser ..> ArgumentMultimap XYZCommandParser ..> ArgumentTokenizer @@ -32,7 +32,6 @@ ArgumentTokenizer .left.> ArgumentMultimap XYZCommandParser ..> CliSyntax CliSyntax ..> Prefix XYZCommandParser ..> ParserUtil -ParserUtil .down.> Prefix ArgumentTokenizer .down.> Prefix XYZCommand -up-|> Command @enduml From b4e6cf44e44f1df9a9de5353b00aa83838ae4d95 Mon Sep 17 00:00:00 2001 From: rocketninja7 Date: Mon, 13 Nov 2023 00:13:46 +0800 Subject: [PATCH 2/4] Update Developer Guide up to Common classes --- docs/DeveloperGuide.md | 6 +++--- docs/diagrams/StorageClassDiagram.puml | 18 +++++++++--------- .../address/logic/commands/AddCommand.java | 2 +- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 329ffedae2a..61e71ad7a05 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -129,7 +129,7 @@ The `Model` component, -**Note:** The module plan data is split into different semesters (e.g. Y1S1, Y1S2, Y2S1, 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. Y1S1, Y1S2, Y2S1, 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 checked can be found in `ModelManager`. @@ -143,7 +143,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 objects that belong to the `Model` that can be changed) ### Database component @@ -153,7 +153,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 objects that belong to the `Model` that can only be read) diff --git a/docs/diagrams/StorageClassDiagram.puml b/docs/diagrams/StorageClassDiagram.puml index 03f8e79593f..5368a0e11b0 100644 --- a/docs/diagrams/StorageClassDiagram.puml +++ b/docs/diagrams/StorageClassDiagram.puml @@ -14,10 +14,10 @@ Class JsonUserPrefsStorage Class "<>\nStorage" as Storage Class StorageManager -package "AddressBook Storage" #F4F6F6{ -Class "<>\nAddressBookStorage" as AddressBookStorage -Class JsonAddressBookStorage -Class JsonSerializableAddressBook +package "ModulePlan Storage" #F4F6F6{ +Class "<>\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 diff --git a/src/main/java/seedu/address/logic/commands/AddCommand.java b/src/main/java/seedu/address/logic/commands/AddCommand.java index 8b54e3a1586..7485c27a87a 100644 --- a/src/main/java/seedu/address/logic/commands/AddCommand.java +++ b/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); From 97029a96af782c50470c5d61e603a91097058852 Mon Sep 17 00:00:00 2001 From: rocketninja7 Date: Mon, 13 Nov 2023 00:16:07 +0800 Subject: [PATCH 3/4] Fix typo --- docs/DeveloperGuide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 89f57a9185f..49fc3f77758 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -535,7 +535,7 @@ testers are expected to do more *exploratory* testing. 4. Test case: `add CS1010 y/1 s/ST1 g/a`.
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)
+ 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)
Expected: Similar to previous.
From 763a33f22df40fdc3e0185afb482f79ad5e65027 Mon Sep 17 00:00:00 2001 From: rocketninja7 Date: Mon, 13 Nov 2023 14:07:20 +0800 Subject: [PATCH 4/4] Update DG according to review --- docs/DeveloperGuide.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 49fc3f77758..9031f214ffd 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -52,7 +52,7 @@ The bulk of the app's work is done by the following four components: * [**`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 on startup. This data is used to support user input validation according to the business logic. +[**`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.
[**`Commons`**](#common-classes) represents a collection of classes used by multiple other components.
@@ -151,7 +151,7 @@ The `Model` component, -**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 checked can be found in `ModelManager`. +**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`. @@ -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` that can be changed) +* 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`)
@@ -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` that can only be read) +* 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`)