diff --git a/.github/ISSUE_TEMPLATE/documentation-bug-report.md b/.github/ISSUE_TEMPLATE/documentation-bug-report.md new file mode 100644 index 00000000000..398a617b322 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/documentation-bug-report.md @@ -0,0 +1,15 @@ +--- +name: Documentation Bug report +about: A template for documentation bugs +title: '' +labels: type.Bug +assignees: '' + +--- + +### Documentation of Interest +User guide / Documentation guide / ... + +### Section Affected + +### Description diff --git a/.github/ISSUE_TEMPLATE/functional-bug-report.md b/.github/ISSUE_TEMPLATE/functional-bug-report.md new file mode 100644 index 00000000000..2832510a744 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/functional-bug-report.md @@ -0,0 +1,20 @@ +--- +name: Functional Bug report +about: A template for functionality bugs +title: '' +labels: type.Bug +assignees: '' + +--- + +### Description + +### Steps for reproducing + +### Expected output + +### Actual output + +### Other details + +### Error output diff --git a/.gitignore b/.gitignore index 71c9194e8bd..7163efd6033 100644 --- a/.gitignore +++ b/.gitignore @@ -3,8 +3,13 @@ /build/ src/main/resources/docs/ +# VSCode files +/.vscode/ +/bin/ + # IDEA files /.idea/ +*/.idea/ /out/ /*.iml diff --git a/README.md b/README.md index 13f5c77403f..f985e57ba21 100644 --- a/README.md +++ b/README.md @@ -1,14 +1,12 @@ -[![CI Status](https://github.com/se-edu/addressbook-level3/workflows/Java%20CI/badge.svg)](https://github.com/se-edu/addressbook-level3/actions) +[![CI Status](https://github.com/AY2223S2-CS2103-F10-2/tp/actions/workflows/gradle.yml/badge.svg)](https://github.com/AY2223S2-CS2103-F10-2/tp/actions/workflows/gradle.yml) ![Ui](docs/images/Ui.png) -* This is **a sample project for Software Engineering (SE) students**.
+Welcome to the Le Tracker project! +* Our goal is to help create a stress-free learning environment for all students!
+* Le Tracker enables students to **easily log their lecture progress**.
Example usages: - * as a starting point of a course project (as opposed to writing everything from scratch) - * as a case study -* The project simulates an ongoing software project for a desktop application (called _AddressBook_) used for managing contact details. - * It is **written in OOP fashion**. It provides a **reasonably well-written** code base **bigger** (around 6 KLoC) than what students usually write in beginner-level SE modules, without being overwhelmingly big. - * It comes with a **reasonable level of user and developer documentation**. -* It is named `AddressBook Level 3` (`AB3` for short) because it was initially created as a part of a series of `AddressBook` projects (`Level 1`, `Level 2`, `Level 3` ...). -* For the detailed documentation of this project, see the **[Address Book Product Website](https://se-education.org/addressbook-level3)**. -* This project is a **part of the se-education.org** initiative. If you would like to contribute code to this project, see [se-education.org](https://se-education.org#https://se-education.org/#contributing) for more info. + * add-module /code CS2040 /name Data Structures & Algorithms + * mark /module CS2040 /lecture 1 /video lecture_01-part-1 + +This project is based on the AddressBook-Level3 project created by the [SE-EDU initiative](https://se-education.org). diff --git a/build.gradle b/build.gradle index 108397716bd..1e6a0ab1f8c 100644 --- a/build.gradle +++ b/build.gradle @@ -63,10 +63,15 @@ dependencies { testImplementation group: 'org.junit.jupiter', name: 'junit-jupiter-api', version: jUnitVersion testRuntimeOnly group: 'org.junit.jupiter', name: 'junit-jupiter-engine', version: jUnitVersion + testImplementation('org.junit.platform:junit-platform-launcher:1.5.2') +} + +run { + enableAssertions = true } shadowJar { - archiveFileName = 'addressbook.jar' + archiveFileName = 'letracker.jar' } defaultTasks 'clean', 'test' diff --git a/config/checkstyle/checkstyle.xml b/config/checkstyle/checkstyle.xml index d618671b832..8b0bdfea210 100644 --- a/config/checkstyle/checkstyle.xml +++ b/config/checkstyle/checkstyle.xml @@ -344,6 +344,7 @@ + diff --git a/copyright.txt b/copyright.txt index 93aa2a39ce2..88be05d5b95 100644 --- a/copyright.txt +++ b/copyright.txt @@ -1,8 +1,7 @@ Some code adapted from http://code.makery.ch/library/javafx-8-tutorial/ by Marco Jakob -Copyright by Susumu Yoshida - http://www.mcdodesign.com/ -- address_book_32.png -- AddressApp.ico +Copyright by Juicy Fish - https://www.flaticon.com/authors/juicy-fish +- time_tracker.png Copyright by Jan Jan Kovařík - http://glyphicons.com/ - calendar.png diff --git a/docs/AboutUs.md b/docs/AboutUs.md index 1c9514e966a..a6d261e00d4 100644 --- a/docs/AboutUs.md +++ b/docs/AboutUs.md @@ -5,55 +5,57 @@ title: About Us We are a team based in the [School of Computing, National University of Singapore](http://www.comp.nus.edu.sg). -You can reach us at the email `seer[at]comp.nus.edu.sg` +You can reach us at the email `ay2223s2-cs2103-f10-2.zhzgv@aleeas.com` ## Project team -### John Doe +### Lee Shao Wee - + -[[homepage](http://www.comp.nus.edu.sg/~damithch)] -[[github](https://github.com/johndoe)] -[[portfolio](team/johndoe.md)] +[[homepage](https://leeshaowee.netlify.app/)] +[[github](https://github.com/shaowi)] +[[portfolio](team/shaowi.md)] -* Role: Project Advisor +- Role: Developer +- Responsibilities: Deliverables, deadlines, scheduling and tracking -### Jane Doe +### Hing Zi Yang Benedict - + -[[github](http://github.com/johndoe)] -[[portfolio](team/johndoe.md)] +[[github](http://github.com/hingen)] +[[portfolio](team/hingen.md)] -* Role: Team Lead -* Responsibilities: UI +- Role: Developer +- Responsibilities: Code Quality + Integration -### Johnny Doe +### Khang Tran - + -[[github](http://github.com/johndoe)] [[portfolio](team/johndoe.md)] +[[github](http://github.com/lennoxtr)] +[[portfolio](team/lennoxtr.md)] -* Role: Developer -* Responsibilities: Data +- Role: Developer +- Responsibilities: File I/O -### Jean Doe +### Joy Tan QiaoTong - + -[[github](http://github.com/johndoe)] -[[portfolio](team/johndoe.md)] +[[github](http://github.com/joytqt-1202)] +[[portfolio](team/joytqt-1202.md)] -* Role: Developer -* Responsibilities: Dev Ops + Threading +- Role: Developer +- Responsibilities: Documentation + Testing -### James Doe +### Jedidiah Cheng - + -[[github](http://github.com/johndoe)] -[[portfolio](team/johndoe.md)] +[[github](https://github.com/jedidiahC)] +[[portfolio](team/jedidiahc.md)] -* Role: Developer -* Responsibilities: UI +- Role: Developer +- Responsibilities: UI diff --git a/docs/DevOps.md b/docs/DevOps.md index d2fd91a6001..e7b10dfc934 100644 --- a/docs/DevOps.md +++ b/docs/DevOps.md @@ -3,38 +3,41 @@ layout: page title: DevOps guide --- -* Table of Contents -{:toc} +## Table of Contents --------------------------------------------------------------------------------------------------------------------- +- [Build automation](#build-automation) +- [Continuous Integration](#continuous-integration) + - [Code coverage](#code-coverage) + - [Repository-wide checks](#repository-wide-checks) +- [Making a release](#making-a-release) + +--- ## Build automation This project uses Gradle for **build automation and dependency management**. **You are recommended to read [this Gradle Tutorial from the se-edu/guides](https://se-education.org/guides/tutorials/gradle.html)**. - Given below are how to use Gradle for some important project tasks. - -* **`clean`**: Deletes the files created during the previous build tasks (e.g. files in the `build` folder).
+- **`clean`**: Deletes the files created during the previous build tasks (e.g. files in the `build` folder).\ e.g. `./gradlew clean` -* **`shadowJar`**: Uses the ShadowJar plugin to creat a fat JAR file in the `build/lib` folder, *if the current file is outdated*.
+- **`shadowJar`**: Uses the ShadowJar plugin to create a fat JAR file in the `build/lib` folder, _if the current file is outdated_.\ e.g. `./gradlew shadowJar`. -* **`run`**: Builds and runs the application.
+- **`run`**: Builds and runs the application.\ **`runShadow`**: Builds the application as a fat JAR, and then runs it. -* **`checkstyleMain`**: Runs the code style check for the main code base.
+- **`checkstyleMain`**: Runs the code style check for the main code base.\ **`checkstyleTest`**: Runs the code style check for the test code base. -* **`test`**: Runs all tests. - * `./gradlew test` — Runs all tests - * `./gradlew clean test` — Cleans the project and runs tests +- **`test`**: Runs all tests. + - `./gradlew test` — Runs all tests + - `./gradlew clean test` — Cleans the project and runs tests --------------------------------------------------------------------------------------------------------------------- +--- -## Continuous integration (CI) +## Continuous Integration This project uses GitHub Actions for CI. The project comes with the necessary GitHub Actions configurations files (in the `.github/workflows` folder). No further setting up required. @@ -58,22 +61,23 @@ Any warnings or errors will be printed out to the console. **If adding new checks:** -* Checks are implemented as executable `check-*` scripts within the `.github` directory. The `run-checks.sh` script will automatically pick up and run files named as such. That is, you can add more such files if you need and the CI will do the rest. +- Checks are implemented as executable `check-*` scripts within the `.github` directory. The `run-checks.sh` script will automatically pick up and run files named as such. That is, you can add more such files if you need and the CI will do the rest. + +- Check scripts should print out errors in the format `SEVERITY:FILENAME:LINE: MESSAGE` -* Check scripts should print out errors in the format `SEVERITY:FILENAME:LINE: MESSAGE` - * SEVERITY is either ERROR or WARN. - * FILENAME is the path to the file relative to the current directory. - * LINE is the line of the file where the error occurred and MESSAGE is the message explaining the error. + - SEVERITY is either ERROR or WARN. + - FILENAME is the path to the file relative to the current directory. + - LINE is the line of the file where the error occurred and MESSAGE is the message explaining the error. -* Check scripts must exit with a non-zero exit code if any errors occur. +- Check scripts must exit with a non-zero exit code if any errors occur. --------------------------------------------------------------------------------------------------------------------- +--- ## Making a release Here are the steps to create a new release. -1. Update the version number in [`MainApp.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/MainApp.java). +1. Update the version number in [`MainApp.java`](https://github.com/AY2223S2-CS2103-F10-2/tp/tree/master/src/main/java/seedu/address/MainApp.java). 1. Generate a fat JAR file using Gradle (i.e., `gradlew shadowJar`). 1. Tag the repo with the version number. e.g. `v0.1` 1. [Create a new release using GitHub](https://help.github.com/articles/creating-releases/). Upload the JAR file you created. diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 46eae8ee565..4158766b716 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -2,28 +2,81 @@ layout: page title: Developer Guide --- -* Table of Contents -{:toc} --------------------------------------------------------------------------------------------------------------------- +![Logo](images/LogoWordmark.png) -## **Acknowledgements** +## **Le Tracker** Development ~ -* {list here sources of all reused/adapted ideas, code, documentation, and third-party libraries -- include links to the original source as well} +Welcome to the Developer Guide for **Le Tracker**! --------------------------------------------------------------------------------------------------------------------- +This guide is intended to provide developers with an overview of the **Le Tracker** codebase, such as the [design](#design) of the codebase and the [implementation](#implementation) details of each feature as needed. -## **Setting up, getting started** +This guide also contains the [requirements](#appendix-requirements) of **Le Tracker** to provide insights on the decision making process of the team and the goals of the application. -Refer to the guide [_Setting up and getting started_](SettingUp.md). +Before reading, it is recommended that developers read the [User Guide](https://ay2223s2-cs2103-f10-2.github.io/tp/UserGuide.html) first to gain an understanding of the features provided by **Le Tracker**. --------------------------------------------------------------------------------------------------------------------- +:information_source: **Le Tracker** was developed with [**Java 11**](https://www.oracle.com/java/technologies/javase/jdk11-archive-downloads.html) and thus, it is recommended that developers use this version of Java. -## **Design** +--- + +## Table of Contents + +- [Acknowledgements](#acknowledgements) +- [Setting up, getting started](#setting-up-getting-started) +- [Design](#design) + - [Architecture](#architecture) + - [UI component](#ui-component) + - [Logic component](#logic-component) + - [Navigation component](#navigation-component) + - [Model component](#model-component) + - [Storage component](#storage-component) + - [Common classes](#common-classes) +- [Implementation](#implementation) + - [Navigation feature](#navigation-feature) + - [List module, lecture and video feature](#list-module-lecture-and-video-feature) + - [Find module, lecture and video feature](#find-module-lecture-and-video-feature) + - [Add module, lecture, and video feature](#add-module-lecture-and-video-feature) + - [Edit module, lecture, and video feature](#edit-module-lecture-and-video-feature) + - [Delete module, lecture, and video feature](#delete-module-lecture-and-video-feature) + - [Mark / UnMark video feature](#mark--unmark-video-feature) + - [Tag module, lecture, and video feature](#tag-module-lecture-and-video-feature) + - [Untag module, lecture, and video feature](#untag-module-lecture-and-video-feature) + - [Exporting data feature](#exporting-data-feature) + - [Import archived data feature](#import-archived-data-feature) + - [Clear feature](#clear-feature) +- [Documentation, logging, testing, configuration, dev-ops](#documentation-logging-testing-configuration-dev-ops) +- [Appendix: Requirements](#appendix-requirements) + - [Product scope](#product-scope) + - [User stories](#user-stories) + - [Use cases](#use-cases) + - [Non-Functional Requirements](#non-functional-requirements) + - [Glossary](#glossary) +- [Appendix: Instructions for manual testing](#appendix-instructions-for-manual-testing) +- [Appendix: Effort](#appendix-effort) +- [Appendix: Planned enhancements](#appendix-planned-enhancements) + +--- + +## Acknowledgements + +- Forked from: [AddressBook Level-3](https://github.com/nus-cs2103-AY2223S2/tp) +- Libraries utilised: [Jackson](https://github.com/FasterXML/jackson), [JavaFX](https://openjfx.io/), [JUnit 5](https://junit.org/junit5/) +- Tools utilised: [Gradle](https://gradle.org/) + +--- + +## Setting up, getting started + +Refer to the guide [*Setting up and getting started*](SettingUp.md). + +--- + +## Design
-:bulb: **Tip:** The `.puml` files used to create diagrams in this document can be found in the [diagrams](https://github.com/se-edu/addressbook-level3/tree/master/docs/diagrams/) folder. Refer to the [_PlantUML Tutorial_ at se-edu/guides](https://se-education.org/guides/tutorials/plantUml.html) to learn how to create and edit diagrams. +:bulb: **Tip:** The `.puml` files used to create diagrams in this document can be found in the [diagrams](https://github.com/AY2223S2-CS2103-F10-2/tp/tree/master/docs/diagrams) folder. Refer to the [*PlantUML Tutorial* at se-edu/guides](https://se-education.org/guides/tutorials/plantUml.html) to learn how to create and edit diagrams. +
### Architecture @@ -36,73 +89,78 @@ Given below is a quick overview of main components and how they interact with ea **Main components of the architecture** -**`Main`** has two classes called [`Main`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/Main.java) and [`MainApp`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/MainApp.java). It is responsible for, -* At app launch: Initializes the components in the correct sequence, and connects them up with each other. -* At shut down: Shuts down the components and invokes cleanup methods where necessary. +**`Main`** has two classes called [`Main`](https://github.com/AY2223S2-CS2103-F10-2/tp/tree/master/src/main/java/seedu/address/Main.java) and [`MainApp`](https://github.com/AY2223S2-CS2103-F10-2/tp/tree/master/src/main/java/seedu/address/MainApp.java). It is responsible for, + +- At app launch: Initializes the components in the correct sequence, and connects them up with each other. +- At shut down: Shuts down the components and invokes cleanup methods where necessary. [**`Commons`**](#common-classes) represents a collection of classes used by multiple other components. The rest of the App consists of four components. -* [**`UI`**](#ui-component): The UI of the App. -* [**`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. - +- [**`UI`**](#ui-component): The UI of the App. +- [**`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. **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 CS2040S`. - + Each of the four main components (also shown in the diagram above), -* 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. +- 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. For example, the `Logic` component defines its API in the `Logic.java` interface and implements its functionality using the `LogicManager.java` class which follows the `Logic` interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent outside component's being coupled to the implementation of a component), as illustrated in the (partial) class diagram below. - + The sections below give more details of each component. ### UI component -The **API** of this component is specified in [`Ui.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/Ui.java) +The **API** of this component is specified in [`Ui.java`](https://github.com/AY2223S2-CS2103-F10-2/tp/tree/master/src/main/java/seedu/address/ui/Ui.java) ![Structure of the UI Component](images/UiClassDiagram.png) -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 consists of a `MainWindow` that is made up of parts e.g.`CommandBox`, `ResultDisplay`, `ModuleListPanel`, `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` 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/AY2223S2-CS2103-F10-2/tp/tree/master/src/main/java/seedu/address/ui/MainWindow.java) is specified in [`MainWindow.fxml`](https://github.com/AY2223S2-CS2103-F10-2/tp/tree/master/src/main/resources/view/MainWindow.fxml) The `UI` component, -* executes user commands using the `Logic` component. -* listens for changes to `Model` data so that the UI can be updated with the modified data. -* 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`. +- executes user commands using the `Logic` component. +- listens for changes to `Model` data so that the UI can be updated with the modified data. +- 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 `Module`, `Lecture`, `Video` objects residing in the `Model`. ### Logic component -**API** : [`Logic.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/logic/Logic.java) +**API** : [`Logic.java`](https://github.com/AY2223S2-CS2103-F10-2/tp/tree/master/src/main/java/seedu/address/logic/Logic.java) Here's a (partial) class diagram of the `Logic` component: How the `Logic` component works: -1. When `Logic` is called upon to execute a command, it uses the `AddressBookParser` class to parse the user command. + +1. When `Logic` is called upon to execute a command, several observers subscribe to the `TrackerEventSystem.` +1. The command text is first pre-processed (e.g. `NavigationInjector` could modify the command text by inserting `/mod CS2040S /lec Week 1`). +1. `Logic` then uses the `TrackerParser` class to parse the user command. 1. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `AddCommand`) which is executed by the `LogicManager`. -1. The command can communicate with the `Model` when it is executed (e.g. to add a person). -1. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`. +1. The command can communicate with the `Model` when it is executed (e.g. to add a module). +1. The result of the command execution is encapsulated as a `CommandResult`. +1. Based on the `CommandResult`, several systems such as `Navigation` are notified through the `TrackerEventSystem`. +1. The `CommandResult` object is then returned back from `Logic`. -The Sequence Diagram below illustrates the interactions within the `Logic` component for the `execute("delete 1")` API call. +The Sequence Diagram below illustrates the interactions within the `Logic` component for the `execute("add CS2040S")` API call. -![Interactions Inside the Logic Component for the `delete 1` Command](images/DeleteSequenceDiagram.png) +![Interactions Inside the Logic Component for the `add CS2040S` Command](images/AddSequenceDiagram.png) -
:information_source: **Note:** The lifeline for `DeleteCommandParser` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram. +
:information_source: **Note:** The lifeline for `AddCommandParser` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
Here are the other classes in `Logic` (omitted from the class diagram above) that are used for parsing a user command: @@ -110,268 +168,2848 @@ Here are the other classes in `Logic` (omitted from the class diagram above) tha 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. -* 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 -**API** : [`Model.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/model/Model.java) +- When called upon to parse a user command, the `TrackerParser` 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., `AddVideoCommand`) which the `TrackerParser` returns back as a `Command` object. +- All `XYZCommandParser` classes (e.g., `AddCommandParser`, `NavCommandParser`, ...) inherit from the `Parser` interface so that they can be treated similarly where possible e.g, during testing. - +### Navigation component +**API**: [`Navigation.java`](https://github.com/AY2223S2-CS2103-F10-2/tp/tree/master/src/main/java/seedu/address/model/Navigation.java) -The `Model` component, +Here's a (partial) class diagram of the `Navigation` component: -* stores the address book data i.e., all `Person` objects (which are contained in a `UniquePersonList` object). -* 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` 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) + -
:information_source: **Note:** An alternative (arguably, a more OOP) model is given below. It has a `Tag` list in the `AddressBook`, which `Person` references. This allows `AddressBook` to only require one `Tag` object per unique tag, instead of each `Person` needing their own `Tag` objects.
+\*\* This class diagram omits some classes and dependencies in the `Navigation` component for the purpose of simplicity. - +What the `Navigation` component does: -
+- Tracking the current working context. +- Tracking navigation through the hierarchy. +- Enforcing valid navigation between adjacent layers in the module-lecture-video hierarchy. + +What the `Navigation` component is **NOT RESPONSIBLE** for: + +- Ensuring that modules or lectures exist in the `Model` component. + - This avoids circular dependency as the `Model` component already depends on the `Navigation` component. + - This enforces the single responsibility principle as the `Navigation` component does not need to verify the existence of actual module or lecture data in the Tracker system. + +For more information on the Navigation system and how to develop **context-sensitive** commands that work with the Navigation system, please refer the [navigation feature](#navigation-feature). + +### Model component + +**API** : [`Model.java`](https://github.com/AY2223S2-CS2103-F10-2/tp/tree/master/src/main/java/seedu/address/model/Model.java) + + + +\*\* This class diagram omits some classes and dependencies in the `Model` component for the purpose of simplicity (classes excluded include `ModuleCode`, `ModuleName`, `LectureName`, `VideoName`, `Tag` and other classes) +The `Model` component, + +- stores the tracker data i.e., all `Module` objects which are contained in a `UniqueModuleList` object, along with the `Lecture` objects contained in the `UniqueLectureList` objects of said `Module` objects, as well as the `Video` objects contained in the `UniqueVideoList` objects of said `Lecture` objects. +- stores the currently 'selected' `Module` objects (e.g., results of a search query) as a separate *filteredModules* list which is exposed to outsiders as an unmodifiable `ObservableList` 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 the currently 'selected' `Lecture` objects (e.g., results of a search query) as a separate *filteredLectures* list which is exposed to outsiders as an unmodifiable `ObservableList` 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 the currently 'selected' `Video` objects (e.g., results of a search query) as a separate *filteredVideos* list which is exposed to outsiders as an unmodifiable `ObservableList