Merge branch 'master' into delete-command-tests

* master:
  Further update DG for UI
  Update DG for UI and Architecture
  Update UG based on peer reviews
  Update UG styling
  Add link to jar file
  Refactor exit and help buttons to remove the MenuBar
  Style PersonDetails
  Update LogicComponent and Implementation
  Refactor DG
  Refactor inputs case-insensitive

docs/DeveloperGuide.md

@@ -50,7 +50,7 @@ The bulk of the app's work is done by the following four components:
 
 **How the architecture components interact with each other**
 
-The *Sequence Diagram* below shows how the components interact with each other for the scenario where the user issues the command `delete 1`.
+The *Sequence Diagram* below shows how the components interact with each other for the scenario where the user issues the command `delete 12345678`.
 
 <puml src="diagrams/ArchitectureSequenceDiagram.puml" width="574" />
 
@@ -71,9 +71,31 @@ The **API** of this component is specified in [`Ui.java`](https://github.com/se-
 
 <puml src="diagrams/UiClassDiagram.puml" alt="Structure of the UI Component"/>
 
-The UI consists of a `MainWindow` that is made up of parts e.g.`CommandBox`, `ResultDisplay`, `PersonListPanel`, `StatusBarFooter` etc. All these, including the `MainWindow`, inherit from the abstract `UiPart` class which captures the commonalities between classes that represent parts of the visible GUI.
-
-The `UI` component uses the JavaFx UI framework. The layout of these UI parts are defined in matching `.fxml` files that are in the `src/main/resources/view` folder. For example, the layout of the [`MainWindow`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/MainWindow.java) is specified in [`MainWindow.fxml`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/resources/view/MainWindow.fxml)
+The UI is managed by the `UiManager` class, which serves as the main controller for managing the UI in EduContacts. 
+It serves as the interface layer between the application's backend logic and the JavaFX UI components, ensuring a smooth
+and consistent user experience.
+
+The UI consists of a `MainWindow` that is made up of the following parts: 
+* `CommandBox`
+  * Where the user types in his desired command
+* `ResultDisplay`
+  * Where the resulting confirmation of the latest command sent or any corresponding error messages is shown to the user
+* `PersonListPanel`
+  * The panel which holds the list of persons in EduContacts, each person represented by a `PersonCard`
+* `StatusBarFooter`
+  * Designed to show the save location of EduContacts' data
+* `PersonDetails` 
+  * A section of the UI that renders when a `FindCommand` is run, showing the resulting person's full details
+* `PersonCard`
+  * Shows simple and brief details about a person
+* `HelpWindow`
+  * Displayed by clicking the "Help" button at the top right hand of the screen
+
+All these, including the `MainWindow`, inherit from the abstract `UiPart` class which captures the commonalities between 
+classes that represent parts of the visible GUI.
+
+The `UI` component uses the JavaFx UI framework. The layout of these UI parts are defined in matching `.fxml` files that 
+are in the `src/main/resources/view` folder. For example, the layout of the [`MainWindow`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/MainWindow.java) is specified in [`MainWindow.fxml`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/resources/view/MainWindow.fxml)
 
 The `UI` component,
 
@@ -82,6 +104,7 @@ The `UI` component,
 * keeps a reference to the `Logic` component, because the `UI` relies on the `Logic` to execute commands.
 * depends on some classes in the `Model` component, as it displays `Person` object residing in the `Model`.
 
+The stylesheet used for the UI can be found in `src/main/java/resources/view/LightTheme.css`.
 ### Logic component
 
 **API** : [`Logic.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/logic/Logic.java)
@@ -101,7 +124,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 `AddressBookParser` 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 an `EduContactsParser` 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).<br>
    Note that although this is shown as a single step in the diagram above (for simplicity), in the code it can take several interactions (between the command object and the `Model`) to achieve.
@@ -112,7 +135,7 @@ Here are the other classes in `Logic` (omitted from the class diagram above) tha
 <puml src="diagrams/ParserClasses.puml" width="600"/>
 
 How the parsing works:
-* When called upon to parse a user command, the `AddressBookParser` class creates an `XYZCommandParser` (`XYZ` is a placeholder for the specific command name e.g., `AddCommandParser`) which uses the other classes shown above to parse the user command and create a `XYZCommand` object (e.g., `AddCommand`) which the `AddressBookParser` returns back as a `Command` object.
+* When called upon to parse a user command, the `EduContactsParser` class creates an `XYZCommandParser` (`XYZ` is a placeholder for the specific command name e.g., `AddCommandParser`) which uses the other classes shown above to parse the user command and create a `XYZCommand` object (e.g., `AddCommand`) which the `EduContactsParser` returns back as a `Command` object.
 * All `XYZCommandParser` classes (e.g., `AddCommandParser`, `DeleteCommandParser`, ...) inherit from the `Parser` interface so that they can be treated similarly where possible e.g, during testing.
 
 ### Model component
@@ -123,10 +146,12 @@ How the parsing works:
 
 The `Model` component,
 
-* stores the address book data i.e., all `Person` objects (which are contained in a `UniquePersonList` object).
+* stores the contact data i.e., all `Person` objects (which are contained in a `UniquePersonList` object).
+  * a `Person` object stores `StudentId`, `Name`, `Address`, `Phone`, `Email`, `Tag`, `Course` objects.
+  * contains an ArrayList of `Module` objects which is optional.
 * stores the currently 'selected' `Person` objects (e.g., results of a search query) as a separate _filtered_ list which is exposed to outsiders as an unmodifiable `ObservableList<Person>` that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.
 * stores a `UserPref` object that represents the user’s preferences. This is exposed to the outside as a `ReadOnlyUserPref` objects.
-* does not depend on any of the other three components (as the `Model` represents data entities of the domain, they should make sense on their own without depending on other components)
+* is intentionally designed to be independent of other components (e.g., UI, Logic, Storage) to maintain a clean separation of concerns. This ensures that the Model layer is solely responsible for managing data and that data structures make sense on their own. This independence enables easier maintenance, testing, and adaptability of the data structures, as changes in one component (e.g., UI) do not affect the Model.
 
 <box type="info" seamless>
 
@@ -158,6 +183,56 @@ Classes used by multiple components are in the `seedu.address.commons` package.
 
 This section describes some noteworthy details on how certain features are implemented.
 
+<box type="info" seamless>
+
+**Note:** The execution of commands mentioned in this section follows a similar path to that depicted in the sequence diagram under the [Logic component](#logic-component) section and will not be discussed in this section.
+
+</box>
+
+### Module feature
+
+The module feature allows users to keep track of modules a `Person` in `EduContacts` is taking. Each `Person` object has a `List<Module>` field that encapsulates the list of modules the Person is taking.
+
+<br>
+
+**Adding a `Module`:**
+
+Users are able to add a `Module` to a `Person`'s list of modules using the `ModuleCommand`. Given below is an example usage scenario of the ModuleCommand.
+
+Step 1. The user launches the application, which is populated with a list of their students. One of the students has `StudentId` of 12345678. Let's refer to this `Person` as Alex.
+
+Step 2. The user executes `module 12345678 m/CS2103T` command to add the CS2103T `Module` to Alex's list of modules. Alex now has a CS2103T `Module` in their list of modules.
+
+<br>
+
+**Editing a `Module`:**
+
+The user is able to edit a `Module` in a `Person`'s list of modules using the `EditCommand`. Given below is an example usage scenario of the EditCommand.
+
+Step 1. The user launches the application, which is populated with a list of their students. One of the students has `StudentId` of 87654321 and a CS2103T `Module` in their list of modules. Let's refer to this `Person` as Bernice.
+
+Step 2. The user executes `edit 12345678 m/CS2103T CS2103` command to edit the CS2103T `Module` to CS2103. Bernice now has a CS2103 `Module` in their list of modules instead of a CS2103T `Module`.
+
+<br>
+
+**Deleting a `Module`:**
+
+The user is able to delete a `Module` from a `Person`'s list of modules using the `DeleteCommand`. Given below is an example usage scenario of the DeleteCommand.
+
+Step 1. The user launches the application, which is populated with a list of their students. One of the students has `StudentId` of 87654321 and a CS2103T `Module` in their list of modules. Let's refer to this `Person` as Bernice.
+
+Step 2. The user executes `delete 12345678 m/CS2103T` command to delete the CS2103T `Module` from Bernice's list of modules. Bernice now no longer has a CS2103T `Module` in their list of modules.
+
+### Grade feature
+
+The grade feature allows users to assign a `Grade` to a `Module` of a `Student` in `EduContacts`. Each `Module` object has a `Grade` field.
+
+Users are able to assign a `Grade` to a `Module` using the `GradeCommand`. Given below is an example usage scenario of the GradeCommand.
+
+Step 1. The user launches the application, which is populated with a list of their students. One of the students has `StudentId` of 87654321 and a CS2103T `Module` in their list of modules. Let's refer to this `Student` as Bernice.
+
+Step 2. The user executes `grade 87654321 m/CS2103T g/A` command to assign an A `Grade` to Bernice's CS2103T `Module`. Bernice now has a CS2103T `Module` graded A in their list of modules.
+
 ### \[Proposed\] Undo/redo feature
 
 #### Proposed Implementation
@@ -251,11 +326,6 @@ The following activity diagram summarizes what happens when a user executes a ne
 
 _{more aspects and alternatives to be added}_
 
-### \[Proposed\] Data archiving
-
-_{Explain here how the data archiving feature will be implemented}_
-
-
 --------------------------------------------------------------------------------------------------------------------
 
 ## **Documentation, logging, testing, configuration, dev-ops**
@@ -655,5 +725,31 @@ _{to work on in the future}_
 
 ## **Appendix: Planned Enhancements**
 
-_{to work on in the future}_
+### Data archiving
+
+* Description: Allow users to move inactive or irrelevant entries to an archive.
+* Benefits:
+  * Reduces clutter in the main data set, making it easier to manage and navigate active records without losing historical data.
+  * Lower the load on real-time data processing by isolating inactive records.
+  * Retain archived data for historical records or compliance requirements.
+  * Provide a safe way to store inactive data without risking deletion or loss.
+
+### Importing contact data
+
+* Description: Allow users to import contact data from multiple formats (e.g. CSV, vCard)
+* Benefits:
+    * Saves time and effort by allowing users to easily populate the app with data, eliminating the need for manual data entry.
+    * Maintain consistent contact records across different applications and devices.
+    * Simplify the process for new users by letting them import contacts directly.
+    * Enable users to restore contacts from external files in case of data loss.
+
+### Exporting contact data
+
+* Description: Allow users to export contact data to multiple formats (e.g. CSV, vCard)
+* Benefits:
+    * Allow users to easily transfer their contact information to other applications or storage solutions.
+    * Provide users with the ability to create backups of their contact data.
+    * Enable users to share their contact lists with others.
+    * Allow users to organize and manipulate their contact data externally.
+    * Help users comply with data export regulations or organizational policies.