+
-[[homepage](http://www.comp.nus.edu.sg/~damithch)]
-[[github](https://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](https://github.com/nickt121)]
-* Role: Project Advisor
+* Role: Developer
+* Responsibilities: Documentation, Testing
-### Jane Doe
+### Roy Tay
-
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](https://github.com/themintchoco)]
* Role: Team Lead
-* Responsibilities: UI
+* Responsibilities: Git expert, Integration
-### Johnny Doe
+### Chen Jiahao
-
-[[github](http://github.com/johndoe)] [[portfolio](team/johndoe.md)]
+[[github](https://github.com/Neilchen863)]
-* Role: Developer
-* Responsibilities: Data
+* Role: developer
+* Responsibilities: Testing, Documentation
-### Jean Doe
+### Lam Yu Han Bryan
-
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](http://github.com/sociallyineptweeb)]
* Role: Developer
-* Responsibilities: Dev Ops + Threading
+* Responsibilities: Deliverables and deadlines, Scheduling and tracking
-### James Doe
+### Lee Zhan Hong
-
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](https://github.com/Zhannyhong)]
* Role: Developer
-* Responsibilities: UI
+* Responsibilities: IntelliJ expert, Code quality
+
diff --git a/docs/DevOps.md b/docs/DevOps.md
index d2fd91a6001..636092c9e46 100644
--- a/docs/DevOps.md
+++ b/docs/DevOps.md
@@ -73,7 +73,7 @@ Any warnings or errors will be printed out to the console.
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/AY2425S2-CS2103T-T17-3/tp/tree/master/src/main/java/tutorly/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 743c65a49d2..7d23fe15de8 100644
--- a/docs/DeveloperGuide.md
+++ b/docs/DeveloperGuide.md
@@ -9,7 +9,8 @@ title: Developer Guide
## **Acknowledgements**
-* {list here sources of all reused/adapted ideas, code, documentation, and third-party libraries -- include links to the original source as well}
+* This project is based on the [AddressBook-Level3](https://github.com/se-edu/addressbook-level3) project created by the SE-EDU initiative.
+* Libraries used: [JavaFX](https://openjfx.io/), [Jackson](https://github.com/FasterXML/jackson), [JUnit5](https://github.com/junit-team/junit5)
--------------------------------------------------------------------------------------------------------------------
@@ -36,7 +37,7 @@ Given below is a quick overview of main components and how they interact with ea
**Main components of the architecture**
-**`Main`** (consisting of classes [`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)) is in charge of the app launch and shut down.
+**`Main`** (consisting of classes [`Main`](https://github.com/AY2425S2-CS2103T-T17-3/tp/tree/master/src/main/java/tutorly/Main.java) and [`MainApp`](https://github.com/AY2425S2-CS2103T-T17-3/tp/tree/master/src/main/java/tutorly/MainApp.java)) is in charge of the app launch and shut down.
* At app launch, it initializes the other components in the correct sequence, and connects them up with each other.
* At shut down, it shuts down the other components and invokes cleanup methods where necessary.
@@ -51,7 +52,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 `student delete 1`.
@@ -68,24 +69,24 @@ 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/AY2425S2-CS2103T-T17-3/tp/tree/master/src/main/java/tutorly/ui/Ui.java)
-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`, `PersonListPanel`, `StatusBarFooter` etc. The classes `PersonListPanel`, `SessionListPanel`, and `AttendanceRecordListPanel` inherit from the abstract `ListPanel` class which captures the commonalities of a panel in the GUI that displays a list of items. Each item in the list is represented as a card (e.g. `SessionCard`). All these, including the `MainWindow` and `ListPanel`, 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/AY2425S2-CS2103T-T17-3/tp/tree/master/src/main/java/tutorly/ui/MainWindow.java) is specified in [`MainWindow.fxml`](https://github.com/AY2425S2-CS2103T-T17-3/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`.
+* depends on some classes in the `Model` component, as it displays `Person`, `Session`, and `AttendanceRecord` 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/AY2425S2-CS2103T-T17-3/tp/tree/master/src/main/java/tutorly/logic/Logic.java)
Here's a (partial) class diagram of the `Logic` component:
@@ -95,13 +96,13 @@ The sequence diagram below illustrates the interactions within the `Logic` compo
-:information_source: **Note:** The lifeline for `StudentCommandParser` and `DeleteStudentCommandParser` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline continues till the end of diagram.
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. 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. 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., `DeleteStudentCommandParser`) 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., `DeleteStudentCommand`) which is executed by the `LogicManager`.
1. The command can communicate with the `Model` when it is executed (e.g. to delete a person).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. 1. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`. @@ -111,32 +112,25 @@ 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.
+* 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., `StudentCommandParser`) which can then create more parsers as required (e.g., `AddStudentCommandParser`) and use the other classes shown above to parse the user command and create a `XYZCommand` object (e.g., `AddStudentCommand`) which the `AddressBookParser` returns back as a `Command` object.
+* All `XYZCommandParser` classes (e.g., `StudentCommandParser`, `AddStudentCommandParser`, `DeleteStudentCommandParser`, ...) 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)
+**API** : [`Model.java`](https://github.com/AY2425S2-CS2103T-T17-3/tp/tree/master/src/main/java/tutorly/model/Model.java)
The `Model` 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: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.
- -
-
-
-
-
### Storage component
-**API** : [`Storage.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/storage/Storage.java)
+**API** : [`Storage.java`](https://github.com/AY2425S2-CS2103T-T17-3/tp/tree/master/src/main/java/tutorly/storage/Storage.java)
- -
-
-
@@ -147,7 +141,7 @@ The `Storage` component,
### Common classes
-Classes used by multiple components are in the `seedu.address.commons` package.
+Classes used by multiple components are in the `tutorly.commons` package.
--------------------------------------------------------------------------------------------------------------------
@@ -155,228 +149,398 @@ Classes used by multiple components are in the `seedu.address.commons` package.
This section describes some noteworthy details on how certain features are implemented.
-### \[Proposed\] Undo/redo feature
-
-#### Proposed Implementation
-
-The proposed 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.
+### Undo feature
-
+There are several ways to build an undo feature. One way is to keep a stack of `AddressBook`s in memory. Each time a change is made to the `AddressBook`, push a copy of the current `AddressBook` onto the stack. When the user requests an undo, pop the top `AddressBook` from the stack and set it as the current `AddressBook`. This is a straightforward and relatively less error-prone way to implement undo. However, it has the following drawbacks:
+* It requires a lot of memory to store multiple copies of the `AddressBook` object.
+* It is not efficient to copy the entire `AddressBook` object every time a change is made.
-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.
+#### Our implementation
-
+We build upon this idea, but instead of keeping a stack of `AddressBook`s, we keep a stack of `Command`s. Each time a change is made to the `AddressBook`, we push the reverse of the command that made the change onto the stack. When the user requests an undo, we pop the top `Command` from the stack and execute it. This way, we do not need to keep multiple copies of the `AddressBook` object in memory. This is more efficient in terms of memory usage and performance.
-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`.
+Each `Command` defines its reverse operation during execution. When building the `CommandResult`, the `Command` also specifies the reverse command to be executed when the user requests an undo. This is kept track of by `LogicManager`, which maintains a stack of `Command`s. When the undo command is executed, `LogicManager` pops the top `Command` from the stack and executes it. The `Command` then executes its reverse operation on the `Model` to revert the changes made by the original command.
-
+The following sequence diagram shows how an undo operation goes through the `Logic` component, when used to undo a student addition.
-:information_source: **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`.
+
+
+**Use case: Add a student record**
-#### Design considerations:
+**MSS**
-**Aspect: How undo & redo executes:**
+1. Tutor requests to add a new student with the required details (Name, Phone, Email, Address, Tag, Memo).
+2. Tutorly validates the input.
+3. Tutorly adds the student profile to the database and confirms success.
-* **Alternative 1 (current choice):** Saves the entire address book.
- * Pros: Easy to implement.
- * Cons: May have performance issues in terms of memory usage.
+ Use case ends.
-* **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.
+**Extensions**
-_{more aspects and alternatives to be added}_
+- 1a. Tutor does not provide all compulsory fields.
+ - 1a1. Tutorly prompts for the missing information.
+ - 1a2. Tutor enters the all the required details
+ - Use case resumes at step 2.
-### \[Proposed\] Data archiving
+- 2a. Tutor provides invalid input for any field.
+ - 2a1. Tutorly displays an appropriate error message.
+ - 2a2. Tutor corrects the input.
+ - Use case resumes at step 2.
-_{Explain here how the data archiving feature will be implemented}_
+- 2b. The student already exists (Same Name).
+ - 2b1. Tutorly displays an error message indicating the student already exists.
+ - Use case ends.
+---
---------------------------------------------------------------------------------------------------------------------
+**Use case: Search for a student record**
-## **Documentation, logging, testing, configuration, dev-ops**
+**MSS**
-* [Documentation guide](Documentation.md)
-* [Testing guide](Testing.md)
-* [Logging guide](Logging.md)
-* [Configuration guide](Configuration.md)
-* [DevOps guide](DevOps.md)
+1. Tutor requests to search for a student by entering a query.
+2. Tutorly validates the search query.
+3. Tutorly retrieves and displays matching student profiles.
---------------------------------------------------------------------------------------------------------------------
+ Use case ends.
-## **Appendix: Requirements**
+**Extensions**
-### Product scope
+- 3a. No students match the search query.
+ - 3a1. Tutorly responds that no students match the search query.
+ - Use case ends.
-**Target user profile**:
+---
-* has a need to manage a significant number of contacts
-* prefer desktop apps over other types
-* can type fast
-* prefers typing to mouse interactions
-* is reasonably comfortable using CLI apps
+**Use case: Update a student record**
-**Value proposition**: manage contacts faster than a typical mouse/GUI driven app
+**MSS**
+1. Tutor requests to update a student record by providing the student’s Identifier and updated details. (e.g., Name, Phone, Email, Address, Tag, Memo).
+2. Tutorly validates the input.
+3. Tutorly updates the student profile and confirms success.
-### User stories
+ Use case ends.
-Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unlikely to have) - `*`
+**Extensions**
-| Priority | As a … | I want to … | So that I can… |
-| -------- | ------------------------------------------ | ------------------------------ | ---------------------------------------------------------------------- |
-| `* * *` | new user | see usage instructions | refer to instructions when I forget how to use the App |
-| `* * *` | user | add a new person | |
-| `* * *` | user | delete a person | remove entries that I no longer need |
-| `* * *` | user | find a person by name | locate details of persons without having to go through the entire list |
-| `* *` | user | hide private contact details | minimize chance of someone else seeing them by accident |
-| `*` | user with many persons in the address book | sort persons by name | locate a person easily |
+- 1a. Tutor does not provide any update parameters.
+ - 1a1. Tutorly displays an error message indicating that there must be at least one update parameter.
+ - Use case ends.
-*{More to be added}*
+- 2a. The student Identifier does not exist.
+ - 2a1. Tutorly responds that the student does not exist.
+ - Use case ends.
-### Use cases
+- 2c. Tutor provides invalid input for any field.
+ - 2c1. Tutorly displays an appropriate error message.
+ - 2c2. Tutor corrects the input.
+ - Use case resumes at step 2.
-(For all use cases below, the **System** is the `AddressBook` and the **Actor** is the `user`, unless specified otherwise)
+---
-**Use case: Delete a person**
+**Use case: Delete a student record**
**MSS**
-1. User requests to list persons
-2. AddressBook shows a list of persons
-3. User requests to delete a specific person in the list
-4. AddressBook deletes the person
+1. Tutor requests to delete a student record by providing the student’s Identifier.
+2. Tutorly validates the request and performs the action.
+3. Tutorly confirms the success of the operation.
- Use case ends.
+ Use case ends.
**Extensions**
-* 2a. The list is empty.
+- 2a. The student Identifier does not exist.
+ - 2a1. Tutorly displays an error message indicating the student does not exist.
+ - Use case ends.
- Use case ends.
+---
-* 3a. The given index is invalid.
+**Use case: Add a Session**
- * 3a1. AddressBook shows an error message.
+**MSS**
- Use case resumes at step 2.
+1. Tutor requests to add a new session with the required details (Timeslot, Subject).
+2. Tutorly validates the input.
+3. Tutorly adds the session to the database and confirms success.
-*{More to be added}*
+ Use case ends.
-### Non-Functional Requirements
-
-1. Should work on any _mainstream OS_ as long as it has Java `17` or above installed.
-2. Should be able to hold up to 1000 persons without a noticeable sluggishness in performance for typical usage.
-3. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.
+**Extensions**
-*{More to be added}*
+- 1a. Tutor does not provide all required fields.
+ - 1a1. Tutorly prompts for the missing information.
+ - Use case resumes at step 2.
-### Glossary
+- 2a. Tutor provides invalid input for any field.
+ - 2a1. Tutorly displays an appropriate error message.
+ - 2a2. Tutor corrects the input.
+ - Use case resumes at step 2.
-* **Mainstream OS**: Windows, Linux, Unix, MacOS
-* **Private contact detail**: A contact detail that is not meant to be shared with others
+- 2b. The timeslot overlaps with another existing session.
+ - 2b1. Tutorly displays an error message indicating the timeslot overlaps with an existing session.
+ - Use case ends.
---------------------------------------------------------------------------------------------------------------------
+---
-## **Appendix: Instructions for manual testing**
+**Use case: Enrol a student to a session**
-Given below are instructions to test the app manually.
+**MSS**
-
- Expected: The most recent window size and location is retained. +1. Tutor requests to mark a session as attended by providing the student’s identifier, Session ID, and attendance status. +2. Tutorly validates the input. +3. Tutorly logs the attendance. +4. Tutorly confirms success. -1. _{ more test cases … }_ + Use case ends. -### Deleting a person +**Extensions** +- 2a. The student identifier does not exist. + - 2a1. Tutorly displays an error message showing the student identifier does not exist. + - Use case ends. -1. Deleting a person while all persons are being shown +- 2b. The Session ID does not exist. + - 2b1. Tutorly displays an error message showing the session ID does not exist. + - Use case ends. - 1. Prerequisites: List all persons using the `list` command. Multiple persons in the list. +- 2c. The student is not enrolled in the session. + - 2c1. Tutorly displays an error message indicating the student is not enrolled in the session. + - Use case ends. - 1. Test case: `delete 1`
- Expected: First contact is deleted from the list. Details of the deleted contact shown in the status message. Timestamp in the status bar is updated. +### Non-Functional Requirements - 1. Test case: `delete 0`
- Expected: No person is deleted. Error details shown in the status message. Status bar remains the same. +1. Should work on any _mainstream OS_ as long as it has Java `17` or above installed. +2. Should be able to hold up to 1000 persons without a noticeable sluggishness in performance for typical usage, ensuring that typical operations (such as loading, searching, and editing records) complete within 3 seconds. +3. The graphical user interface shall be easy to use such that a new user can complete primary workflows (e.g., adding a record or searching for a student) within 5 minutes of first use. +4. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse. +5. The codebase should be modular and well-documented, allowing for easier updates or the integration of future features. At least 90% of the codebase shall have inline or external documentation, and modules must have well-defined interfaces. +6. The source code should be open source and shall be released under an approved open source license (e.g., MIT, Apache 2.0) and published in a publicly accessible repository with minimal entry barriers. - 1. Other incorrect delete commands to try: `delete`, `delete x`, `...` (where x is larger than the list size)
- Expected: Similar to previous. +### Glossary -1. _{ more test cases … }_ +* **Tutor**: An educator who uses Tutorly to manage student details, schedule sessions, log lesson notes, and track attendance. +* **Student Record / Student Profile**: The digital record for each student stored in Tutorly. +* **Session**: A scheduled tutoring meeting or lesson. +* **Lesson**: The content delivered during a session. -### Saving data +-------------------------------------------------------------------------------------------------------------------- -1. Dealing with missing/corrupted data files +## **Appendix: Instructions for manual testing** - 1. _{explain how to simulate a missing/corrupted file, and the expected behavior}_ +### Launch and Shutdown + +1. **Initial Launch** + 1. Download the jar file and copy it into an empty folder. + 2. Double-click the jar file. + - Expected: Shows the GUI with a set of sample students. The window size may not be optimal. + +2. **Saving Window Preferences** + 1. Resize the window to an optimal size. Move the window to a different location. Close the window. + 2. Re-launch the app by double-clicking the jar file. + - Expected: The most recent window size and location are retained. + +### Saving Data + +1. **Dealing with Missing Data Files** + 1. Simulate a missing file by renaming or deleting the data file. + 2. Launch the application. + - Expected: Application should handle the error gracefully, by creating a new data file containing the sample data once any command is successfully executed. (For student/session add commands, it will also include the added student/session.) + +2. **Dealing with Corrupted Data Files** + 1. Simulate a corrupted file by modifying the data file to be unreadable. + 2. Launch the application. + - Expected: Application should clear the corrupted data file and create a empty data file once any command is successfully executed. + +### Adding a Student + +1. **Adding a New Student** + 1. Test case: Add a new student with valid details. `student add n/John Doe` + - Expected: Student is added successfully, and a confirmation message is shown. + 2. Test case: Add a new student with invalid details (e.g., missing required fields `student add p/12345678`). + - Expected: Error message is shown, prompting for correct input. + +### Deleting a Student + +1. **Deleting a Student** + Prerequisite: The student must exist in the list. + 1. Test case: `student delete 1` + - Expected: Student with id 1 is deleted from the list. Details of the deleted students are shown. + 2. Test case: `student delete 0` + - Expected: No student is deleted. Error details are shown in the status message. + 3. Other incorrect delete commands to try: `student delete`, `student delete x`(where x is a number that is larger than the list size) + - Expected: Similar to previous. + +### Searching for a Student + +1. **Search for a Student** + 1. Test case: Search for a student by name. `student search n/John` + - Expected: A message "x students listed!" is shown. Matching student profiles are displayed. (x is the number of students matching the search query. If no matches are found, x = 0. If multiple matches are found, x > 1. If only one match is found, x = 1. The list of students is filtered to show only those matching the search query.) + 2. Test case: Search with a query that has no matches. `student search n/NonExistent` + - Expected: "0 students listed!" message is shown. + +### Editing a Student + +1. **Editing a Student** + 1. Test case: Edit a student’s details with valid input. `student edit 1 n/John Smith` + - Expected: Student details are updated successfully, and a confirmation message is shown. + 2. Test case: Edit a student’s details with invalid input. `student edit x n/John Smith`(x is a number larger than the list size) + - Expected: Error message "Student not found!" is shown. + 3. Test case: Edit a student’s details with missing required fields. `student edit 1 n/` + - Expected: Error message is shown, prompting for correct input. + +### Adding a Session + +1. **Adding a Session** + 1. Test case: Add a new session with valid details. `session add t/30 Mar 2025 11:30-13:30 sub/Math` + - Expected: Session is added successfully, and a confirmation message is shown. + 2. Test case: Add a new session with invalid details (e.g., missing required fields). `session add` + - Expected: Error message is shown, prompting for correct input. + 3. Test case: Add a new session with overlapping timeslots. `session add t/30 Mar 2025 11:30-13:30 sub/Science` + (Suppose there is a session whose time slot has overlapped with the new session's time slot.) + - Expected: Error message is shown, indicating the timeslot overlaps with an existing session. + +### Marking Attendance for a Session + +1. **Marking attendance for a session** + Prerequisite: The session and student must exist and the student must be enrolled in the session. + 1. Test case: Mark a session with valid input. `session mark 1 ses/1` + - Expected: Attendance is marked successfully, and a confirmation message is shown. + 2. Test case: Mark a session as completed with invalid input (e.g., invalid session id). `session mark 1 ses/x`(x is a number larger than the list size) + - Expected: Error message is shown, prompting for correct input. + 3. Test case: Mark a session which the student is not enrolled in. `session mark 1 ses/2` + - Expected: Error message is shown, indicating the student is not enrolled in the session. + +### Adding Feedback + +1. **Adding feedback for a session** + Prerequisite: The session and student must exist and the student must be enrolled in the session. + 1. Test case: Add feedback with valid input. `session feedback 1 ses/1 f/Great session!` + - Expected: Feedback is added successfully, and a confirmation message is shown. + 2. Test case: Add feedback with invalid input (e.g., missing required fields). `session feedback` + - Expected: Error message is shown, prompting for correct input. + 3. Test case: Add feedback for a session which the student is not enrolled in. `session feedback 1 ses/2 f/Great session!` + (Suppose student 1 is not enrolled in session 2) + - Expected: Error message is shown, indicating the student is not enrolled in the session. + +### Undo Feature + +1. **Undo Operations** + 1. Test case: Perform an action (e.g., add a student), then undo the action. + - Expected: The action is undone, and the previous state is restored. There is also a confirmation message shown. + +### Error Handling + +1. **Invalid Commands** + 1. Test case: Enter an invalid command. + - Expected: Error message is shown, indicating the command is not recognized/unknown. + +2. **System Errors** + 1. Test case: Simulate a system error (e.g., by corrupting a data file). + - Expected: Application handles the error gracefully, removing or replacing the corrupted data file + +These instructions provide a starting point for testers to work on; testers are expected to do more exploratory testing. + +## **Appendix: Planned Enhancements** + +1. Enhance undo functionality for the add command to allow for rollback of assigned IDs. +2. Improve the output display to seamlessly present long messages without requiring scrolling. +3. Refine cell selection behavior in the UI to reduce flickering and improve responsiveness. +4. Optimize the list view so it dynamically adjusts its height in response to changes in the filtered item count. +5. Enhance the UI focus management to ensure that the correct item is consistently highlighted. +6. Add support for multiple students of the same name. +7. A `redo` command to undo an `undo` command. +8. Improved `search` command for `student` and `session` with other fields including **tags** and **date/time range** with control over matching **any** or **all** fields. +9. `class` management commands that handle adding of **multiple** sessions and **mass** enrolling/marking of attendance for students. +10. Viewing sessions each student is enrolled in via the `students` tab. -1. _{ more test cases … }_ diff --git a/docs/SettingUp.md b/docs/SettingUp.md index aef33ec72fd..9c0b1d912a2 100644 --- a/docs/SettingUp.md +++ b/docs/SettingUp.md @@ -23,7 +23,7 @@ If you plan to use Intellij IDEA (highly recommended): 1. **Import the project as a Gradle project**: Follow the guide [_[se-edu/guides] IDEA: Importing a Gradle project_](https://se-education.org/guides/tutorials/intellijImportGradleProject.html) to import the project into IDEA.
:exclamation: Note: Importing a Gradle project is slightly different from importing a normal Java project. 1. **Verify the setup**: - 1. Run the `seedu.address.Main` and try a few commands. + 1. Run the `tutorly.Main` and try a few commands. 1. [Run the tests](Testing.md) to ensure they all pass. -------------------------------------------------------------------------------------------------------------------- diff --git a/docs/Testing.md b/docs/Testing.md index 8a99e82438a..d99c8e9a8ad 100644 --- a/docs/Testing.md +++ b/docs/Testing.md @@ -29,8 +29,8 @@ There are two ways to run tests. This project has three types of tests: 1. *Unit tests* targeting the lowest level methods/classes.
- e.g. `seedu.address.commons.StringUtilTest` + e.g. `tutorly.commons.StringUtilTest` 1. *Integration tests* that are checking the integration of multiple code units (those code units are assumed to be working).
- e.g. `seedu.address.storage.StorageManagerTest` -1. Hybrids of unit and integration tests. These test are checking multiple code units as well as how the are connected together.
- e.g. `seedu.address.logic.LogicManagerTest` + e.g. `tutorly.storage.StorageManagerTest` +1. Hybrids of unit and integration tests. These test are checking multiple code units as well as how they are connected together.
+ e.g. `tutorly.logic.LogicManagerTest` diff --git a/docs/UserGuide.md b/docs/UserGuide.md index 27c2d1cf16c..733a0238fdf 100644 --- a/docs/UserGuide.md +++ b/docs/UserGuide.md @@ -3,8 +3,11 @@ layout: page title: User Guide --- -AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized for use via a Command Line Interface** (CLI) while still having the benefits of a Graphical User Interface (GUI). If you can type fast, AB3 can get your contact management tasks done faster than traditional GUI apps. +Tutorly is a desktop app designed for private tutors to **manage their student and lesson records efficiently**. +It combines the speed and precision of typing commands with the convenience of a visual interface. +If you prefer using your keyboard over clicking through menus, Tutorly allows you to complete student management tasks more quickly than traditional apps. +## Table of Contents * Table of Contents {:toc} @@ -12,31 +15,56 @@ AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized fo ## Quick start -1. Ensure you have Java `17` or above installed in your Computer.
- **Mac users:** Ensure you have the precise JDK version prescribed [here](https://se-education.org/guides/tutorials/javaInstallationMac.html). +1. **Install Java**: Ensure you have Java `17` or above installed in your Computer. You can download the correct [JDK](#glossary) for your [operating system](#glossary) using this [link](https://www.oracle.com/sg/java/technologies/downloads/).
+ **Mac users**: Ensure you have the precise JDK version prescribed [here](https://se-education.org/guides/tutorials/javaInstallationMac.html). -1. Download the latest `.jar` file from [here](https://github.com/se-edu/addressbook-level3/releases). +2. **Download Tutorly**: Get the latest [JAR](#glossary) file from [here](https://github.com/AY2425S2-CS2103T-T17-3/tp/releases/latest/download/tutorly.jar). -1. Copy the file to the folder you want to use as the _home folder_ for your AddressBook. +3. **Move the file**: Locate the downloaded `tutorly.jar` file and place it in a folder where you want to keep the app's data. This will be the app's _home folder_. -1. Open a command terminal, `cd` into the folder you put the jar file in, and use the `java -jar addressbook.jar` command to run the application.
- A GUI similar to the below should appear in a few seconds. Note how the app contains some sample data.
+4. **Open a [command terminal](#glossary)** - This is a tool that lets you run commands on your computer: + - On **Windows**: Press `Win + R`, type `cmd`, and press **Enter**. + - On **Mac**: Open **Terminal** from the Applications > Utilities folder. + - On **Linux**: Open **Terminal** from your applications menu. + +5. **Navigate to the folder**: In the terminal, type `cd ` (with a space after). Then, **click and hold** the _home folder_, **drag** it into the terminal window and **release** it. Doing this will automatically insert the full path of the folder. Press **Enter**. + +6. **Run Tutorly**: Type `java -jar tutorly.jar` and press **Enter**. This will start the application. A GUI similar to the below should appear in a few seconds, containing some sample data.
 +7. **UI Layout**: Feel free to take a look at the following images for a better understanding of the layout! + +### Students Tab + + + +### Student Card + + + +### Sessions Tab -1. Type the command in the command box and press Enter to execute it. e.g. typing **`help`** and pressing Enter will open the help window.
- Some example commands you can try: + - * `list` : Lists all contacts. +### Execute a command - * `add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01` : Adds a contact named `John Doe` to the Address Book. +Type the command in the command box and press Enter to execute it. e.g. typing **`help`** and pressing Enter will open the help window.
+Some example commands you can try: - * `delete 3` : Deletes the 3rd contact shown in the current list. +* `student list` : Lists all students. - * `clear` : Deletes all contacts. +* `student add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01` : Adds a student named `John Doe` to the app. - * `exit` : Exits the app. +* `student delete 3` : Deletes the student with the ID 3. -1. Refer to the [Features](#features) below for details of each command. +* `session list` : List all sessions. + +* `clear` : Deletes all students and sessions. + +* `exit` : Exits the app. + +Refer to the [Features](#features) below for details of each command. + +[Back to top :arrow_up:](#table-of-contents) -------------------------------------------------------------------------------------------------------------------- @@ -46,137 +74,489 @@ AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized fo **:information_source: Notes about the command format:**
-* Words in `UPPER_CASE` are the parameters to be supplied by the user.
- e.g. in `add n/NAME`, `NAME` is a parameter which can be used as `add n/John Doe`. +* Words in `UPPER_CASE` are the [parameters](#parameter-summary) to be supplied by the user.
+ e.g. in `student add n/NAME`, `NAME` is a parameter which can be used as `student add n/John Doe`. -* Items in square brackets are optional.
+* [STUDENT_IDENTIFIER](#glossary) can either be the target student's ID, or their full name. Examples: `John Doe` or `2`. + +* Parameters in square brackets are optional.
e.g `n/NAME [t/TAG]` can be used as `n/John Doe t/friend` or as `n/John Doe`. * Items with `…` after them can be used multiple times including zero times.
e.g. `[t/TAG]…` can be used as ` ` (i.e. 0 times), `t/friend`, `t/friend t/family` etc. * Parameters can be in any order.
- e.g. if the command specifies `n/NAME p/PHONE_NUMBER`, `p/PHONE_NUMBER n/NAME` is also acceptable. + e.g. if the command specifies `n/NAME p/PHONE`, `p/PHONE n/NAME` is also acceptable. -* Extraneous parameters for commands that do not take in parameters (such as `help`, `list`, `exit` and `clear`) will be ignored.
- e.g. if the command specifies `help 123`, it will be interpreted as `help`. +* Extra parameters for commands that do not take in parameters ([general](#general-commands) commands, `student list` and `session list`) will be ignored.
+ e.g. if the command specifies `help 123` or `session list blah`, it will be interpreted as `help` and `session list`. * If you are using a PDF version of this document, be careful when copying and pasting commands that span multiple lines as space characters surrounding line-breaks may be omitted when copied over to the application.
-### Viewing help : `help`
+### Parameter Summary
-Shows a message explaning how to access the help page.
+| Parameter | Format | Constraint | Length | Example |
+|-----------|------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------|--------------------|----------------------------------|
+| ADDRESS | - | - | Max: 255 | Blk 30 Geylang Street 29, #06-40 |
+| DATE | `dd MMM yyyy` | - | - | 11 Apr 2025 |
+| EMAIL | `local-part@domain` | - | Max: 254 | hello@tutorly.com |
+| FEEDBACK | - | - | Max: 200 | Did not complete homework |
+| MEMO | - | - | Max: 255 | Adept at calculus |
+| NAME | - | Start with a letter, and only contain letters, numbers, spaces, and these special characters: `()@*-+=:;'<>,?/.` | Max: 255 | John Doe |
+| PHONE | - | Only contain numbers, spaces, hyphens, and an optional country code prefix | Min: 3:information_source: **Note:** The lifeline for `AddStudentCommand`, `UndoCommand`, and `DeleteStudentCommand` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline continues till the end of diagram.
-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.
-
-
-
-:information_source: **Note:** If the `currentStatePointer` is at index 0, pointing to the initial AddressBook state, then there are no previous AddressBook 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 an undo operation goes through the `Logic` component:
+--------------------------------------------------------------------------------------------------------------------
-
+## **Documentation, logging, testing, configuration, dev-ops**
-:information_source: **Note:** The lifeline for `UndoCommand` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+* [Documentation guide](Documentation.md)
+* [Testing guide](Testing.md)
+* [Logging guide](Logging.md)
+* [Configuration guide](Configuration.md)
+* [DevOps guide](DevOps.md)
-
+--------------------------------------------------------------------------------------------------------------------
-Similarly, how an undo operation goes through the `Model` component is shown below:
+## **Appendix: Requirements**
-
+### Product scope
-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.
+**Target user profile**:
-:information_source: **Note:** If the `currentStatePointer` is at index `addressBookStateList.size() - 1`, pointing to the latest address book state, then there are no undone AddressBook 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.
+* private tutor
+* need to track large number of students' details and sessions
+* prefer desktop apps over other types
+* can type fast
+* prefers typing to mouse interactions
+* is reasonably comfortable using CLI apps
-
+**Value proposition**: tracks and manages students’ details faster than a typical mouse/GUI driven app,
+reducing manual effort and ensuring better organization.
-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.
-
+### User stories
-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. Reason: It no longer makes sense to redo the `add n/David …` command. This is the behavior that most modern desktop applications follow.
+Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unlikely to have) - `*`
-
+| Priority | As a … | I want to … | So that I can… |
+|----------|-----------------------------------|--------------------------------------------------|-----------------------------------------------------------------------------------|
+| `* * *` | new user | see usage instructions | refer to instructions when I forget how to use the app |
+| `* * *` | user | add a new student with basic details | begin tracking their progress |
+| `* * *` | user | record additional student details | recall other information about the student |
+| `* * *` | user with many students | search a student by name or phone number | quickly find their details before a session without going through the entire list |
+| `* * *` | user | edit student records | update student details when they change |
+| `* * *` | long-time user | delete old student records | stop tracking students that I no longer teach |
+| `* * *` | user | record student attendance | track my student's participation |
+| `* *` | potential user | see the app populated with sample data initially | easily visualise how it will look like in real use |
+| `* *` | user ready to start using the app | delete all sample data | start fresh with my actual students |
+| `* *` | user | log lesson feedback | keep track of progress of a student in the session |
+| `* *` | user | create custom tags for students | categorise them based on needs |
+| `*` | user with many students | sort students by any field | locate a student easily |
+| `*` | user | filter students by custom tags | see all students with particular needs |
+| `*` | expert user | bulk-edit lesson notes or assignments | save time by updating multiple records at once |
+| `*` | user teaching multiple subjects | customise tracking fields for different subjects | tailor my records to different teaching needs |
+| `*` | user teaching group classes | create group sessions with multiple students | track their progress collectively as a class |
+| `*` | user | generate a progress report for a student | share updates with parents |
+| `*` | user | receive a weekly summary of my sessions | review my workload |
+| `*` | user | set reminder for upcoming sessions | remember upcoming lessons |
+| `*` | user | view reminders for upcoming sessions | plan my schedule |
+| `*` | user | hide private contact details | minimise chance of someone else seeing them by accident |
+
+
+### Use Cases
+
+(For all use cases below, the **System** is `Tutorly`, and the **Actor** is the `tutor`, unless specified otherwise.)
-The following activity diagram summarizes what happens when a user executes a new command:
+---
-
+**Use case: Add a student record**
-#### Design considerations:
+**MSS**
-**Aspect: How undo & redo executes:**
+1. Tutor requests to add a new student with the required details (Name, Phone, Email, Address, Tag, Memo).
+2. Tutorly validates the input.
+3. Tutorly adds the student profile to the database and confirms success.
-* **Alternative 1 (current choice):** Saves the entire address book.
- * Pros: Easy to implement.
- * Cons: May have performance issues in terms of memory usage.
+ Use case ends.
-* **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.
+**Extensions**
-_{more aspects and alternatives to be added}_
+- 1a. Tutor does not provide all compulsory fields.
+ - 1a1. Tutorly prompts for the missing information.
+ - 1a2. Tutor enters the all the required details
+ - Use case resumes at step 2.
-### \[Proposed\] Data archiving
+- 2a. Tutor provides invalid input for any field.
+ - 2a1. Tutorly displays an appropriate error message.
+ - 2a2. Tutor corrects the input.
+ - Use case resumes at step 2.
-_{Explain here how the data archiving feature will be implemented}_
+- 2b. The student already exists (Same Name).
+ - 2b1. Tutorly displays an error message indicating the student already exists.
+ - Use case ends.
+---
---------------------------------------------------------------------------------------------------------------------
+**Use case: Search for a student record**
-## **Documentation, logging, testing, configuration, dev-ops**
+**MSS**
-* [Documentation guide](Documentation.md)
-* [Testing guide](Testing.md)
-* [Logging guide](Logging.md)
-* [Configuration guide](Configuration.md)
-* [DevOps guide](DevOps.md)
+1. Tutor requests to search for a student by entering a query.
+2. Tutorly validates the search query.
+3. Tutorly retrieves and displays matching student profiles.
---------------------------------------------------------------------------------------------------------------------
+ Use case ends.
-## **Appendix: Requirements**
+**Extensions**
-### Product scope
+- 3a. No students match the search query.
+ - 3a1. Tutorly responds that no students match the search query.
+ - Use case ends.
-**Target user profile**:
+---
-* has a need to manage a significant number of contacts
-* prefer desktop apps over other types
-* can type fast
-* prefers typing to mouse interactions
-* is reasonably comfortable using CLI apps
+**Use case: Update a student record**
-**Value proposition**: manage contacts faster than a typical mouse/GUI driven app
+**MSS**
+1. Tutor requests to update a student record by providing the student’s Identifier and updated details. (e.g., Name, Phone, Email, Address, Tag, Memo).
+2. Tutorly validates the input.
+3. Tutorly updates the student profile and confirms success.
-### User stories
+ Use case ends.
-Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unlikely to have) - `*`
+**Extensions**
-| Priority | As a … | I want to … | So that I can… |
-| -------- | ------------------------------------------ | ------------------------------ | ---------------------------------------------------------------------- |
-| `* * *` | new user | see usage instructions | refer to instructions when I forget how to use the App |
-| `* * *` | user | add a new person | |
-| `* * *` | user | delete a person | remove entries that I no longer need |
-| `* * *` | user | find a person by name | locate details of persons without having to go through the entire list |
-| `* *` | user | hide private contact details | minimize chance of someone else seeing them by accident |
-| `*` | user with many persons in the address book | sort persons by name | locate a person easily |
+- 1a. Tutor does not provide any update parameters.
+ - 1a1. Tutorly displays an error message indicating that there must be at least one update parameter.
+ - Use case ends.
-*{More to be added}*
+- 2a. The student Identifier does not exist.
+ - 2a1. Tutorly responds that the student does not exist.
+ - Use case ends.
-### Use cases
+- 2c. Tutor provides invalid input for any field.
+ - 2c1. Tutorly displays an appropriate error message.
+ - 2c2. Tutor corrects the input.
+ - Use case resumes at step 2.
-(For all use cases below, the **System** is the `AddressBook` and the **Actor** is the `user`, unless specified otherwise)
+---
-**Use case: Delete a person**
+**Use case: Delete a student record**
**MSS**
-1. User requests to list persons
-2. AddressBook shows a list of persons
-3. User requests to delete a specific person in the list
-4. AddressBook deletes the person
+1. Tutor requests to delete a student record by providing the student’s Identifier.
+2. Tutorly validates the request and performs the action.
+3. Tutorly confirms the success of the operation.
- Use case ends.
+ Use case ends.
**Extensions**
-* 2a. The list is empty.
+- 2a. The student Identifier does not exist.
+ - 2a1. Tutorly displays an error message indicating the student does not exist.
+ - Use case ends.
- Use case ends.
+---
-* 3a. The given index is invalid.
+**Use case: Add a Session**
- * 3a1. AddressBook shows an error message.
+**MSS**
- Use case resumes at step 2.
+1. Tutor requests to add a new session with the required details (Timeslot, Subject).
+2. Tutorly validates the input.
+3. Tutorly adds the session to the database and confirms success.
-*{More to be added}*
+ Use case ends.
-### Non-Functional Requirements
-
-1. Should work on any _mainstream OS_ as long as it has Java `17` or above installed.
-2. Should be able to hold up to 1000 persons without a noticeable sluggishness in performance for typical usage.
-3. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.
+**Extensions**
-*{More to be added}*
+- 1a. Tutor does not provide all required fields.
+ - 1a1. Tutorly prompts for the missing information.
+ - Use case resumes at step 2.
-### Glossary
+- 2a. Tutor provides invalid input for any field.
+ - 2a1. Tutorly displays an appropriate error message.
+ - 2a2. Tutor corrects the input.
+ - Use case resumes at step 2.
-* **Mainstream OS**: Windows, Linux, Unix, MacOS
-* **Private contact detail**: A contact detail that is not meant to be shared with others
+- 2b. The timeslot overlaps with another existing session.
+ - 2b1. Tutorly displays an error message indicating the timeslot overlaps with an existing session.
+ - Use case ends.
---------------------------------------------------------------------------------------------------------------------
+---
-## **Appendix: Instructions for manual testing**
+**Use case: Enrol a student to a session**
-Given below are instructions to test the app manually.
+**MSS**
-:information_source: **Note:** These instructions only provide a starting point for testers to work on;
-testers are expected to do more *exploratory* testing.
+1. Tutor requests to enrol a new student to an existing session by providing the student’s identifier and Session ID.
+2. Tutorly validates the input.
+3. Tutorly adds the student profile to the session and confirms success.
-
+ Use case ends.
-### Launch and shutdown
+**Extensions**
-1. Initial launch
+- 1a. Tutor does not provide all required fields.
+ - 1a1. Tutorly prompts for the missing information.
+ - 1a2. Tutor corrects the input.
+ - Use case resumes at step 2.
- 1. Download the jar file and copy into an empty folder
+- 2a. Tutor provides invalid input for any field.
+ - 2a1. Tutorly displays an appropriate error message.
+ - 2a2. Tutor corrects the input.
+ - Use case resumes at step 2.
- 1. Double-click the jar file Expected: Shows the GUI with a set of sample contacts. The window size may not be optimum.
+--
-1. Saving window preferences
+**Use case: Mark attendance for a tutoring session**
- 1. Resize the window to an optimum size. Move the window to a different location. Close the window.
+**MSS**
- 1. Re-launch the app by double-clicking the jar file.- Expected: The most recent window size and location is retained. +1. Tutor requests to mark a session as attended by providing the student’s identifier, Session ID, and attendance status. +2. Tutorly validates the input. +3. Tutorly logs the attendance. +4. Tutorly confirms success. -1. _{ more test cases … }_ + Use case ends. -### Deleting a person +**Extensions** +- 2a. The student identifier does not exist. + - 2a1. Tutorly displays an error message showing the student identifier does not exist. + - Use case ends. -1. Deleting a person while all persons are being shown +- 2b. The Session ID does not exist. + - 2b1. Tutorly displays an error message showing the session ID does not exist. + - Use case ends. - 1. Prerequisites: List all persons using the `list` command. Multiple persons in the list. +- 2c. The student is not enrolled in the session. + - 2c1. Tutorly displays an error message indicating the student is not enrolled in the session. + - Use case ends. - 1. Test case: `delete 1`
- Expected: First contact is deleted from the list. Details of the deleted contact shown in the status message. Timestamp in the status bar is updated. +### Non-Functional Requirements - 1. Test case: `delete 0`
- Expected: No person is deleted. Error details shown in the status message. Status bar remains the same. +1. Should work on any _mainstream OS_ as long as it has Java `17` or above installed. +2. Should be able to hold up to 1000 persons without a noticeable sluggishness in performance for typical usage, ensuring that typical operations (such as loading, searching, and editing records) complete within 3 seconds. +3. The graphical user interface shall be easy to use such that a new user can complete primary workflows (e.g., adding a record or searching for a student) within 5 minutes of first use. +4. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse. +5. The codebase should be modular and well-documented, allowing for easier updates or the integration of future features. At least 90% of the codebase shall have inline or external documentation, and modules must have well-defined interfaces. +6. The source code should be open source and shall be released under an approved open source license (e.g., MIT, Apache 2.0) and published in a publicly accessible repository with minimal entry barriers. - 1. Other incorrect delete commands to try: `delete`, `delete x`, `...` (where x is larger than the list size)
- Expected: Similar to previous. +### Glossary -1. _{ more test cases … }_ +* **Tutor**: An educator who uses Tutorly to manage student details, schedule sessions, log lesson notes, and track attendance. +* **Student Record / Student Profile**: The digital record for each student stored in Tutorly. +* **Session**: A scheduled tutoring meeting or lesson. +* **Lesson**: The content delivered during a session. -### Saving data +-------------------------------------------------------------------------------------------------------------------- -1. Dealing with missing/corrupted data files +## **Appendix: Instructions for manual testing** - 1. _{explain how to simulate a missing/corrupted file, and the expected behavior}_ +### Launch and Shutdown + +1. **Initial Launch** + 1. Download the jar file and copy it into an empty folder. + 2. Double-click the jar file. + - Expected: Shows the GUI with a set of sample students. The window size may not be optimal. + +2. **Saving Window Preferences** + 1. Resize the window to an optimal size. Move the window to a different location. Close the window. + 2. Re-launch the app by double-clicking the jar file. + - Expected: The most recent window size and location are retained. + +### Saving Data + +1. **Dealing with Missing Data Files** + 1. Simulate a missing file by renaming or deleting the data file. + 2. Launch the application. + - Expected: Application should handle the error gracefully, by creating a new data file containing the sample data once any command is successfully executed. (For student/session add commands, it will also include the added student/session.) + +2. **Dealing with Corrupted Data Files** + 1. Simulate a corrupted file by modifying the data file to be unreadable. + 2. Launch the application. + - Expected: Application should clear the corrupted data file and create a empty data file once any command is successfully executed. + +### Adding a Student + +1. **Adding a New Student** + 1. Test case: Add a new student with valid details. `student add n/John Doe` + - Expected: Student is added successfully, and a confirmation message is shown. + 2. Test case: Add a new student with invalid details (e.g., missing required fields `student add p/12345678`). + - Expected: Error message is shown, prompting for correct input. + +### Deleting a Student + +1. **Deleting a Student** + Prerequisite: The student must exist in the list. + 1. Test case: `student delete 1` + - Expected: Student with id 1 is deleted from the list. Details of the deleted students are shown. + 2. Test case: `student delete 0` + - Expected: No student is deleted. Error details are shown in the status message. + 3. Other incorrect delete commands to try: `student delete`, `student delete x`(where x is a number that is larger than the list size) + - Expected: Similar to previous. + +### Searching for a Student + +1. **Search for a Student** + 1. Test case: Search for a student by name. `student search n/John` + - Expected: A message "x students listed!" is shown. Matching student profiles are displayed. (x is the number of students matching the search query. If no matches are found, x = 0. If multiple matches are found, x > 1. If only one match is found, x = 1. The list of students is filtered to show only those matching the search query.) + 2. Test case: Search with a query that has no matches. `student search n/NonExistent` + - Expected: "0 students listed!" message is shown. + +### Editing a Student + +1. **Editing a Student** + 1. Test case: Edit a student’s details with valid input. `student edit 1 n/John Smith` + - Expected: Student details are updated successfully, and a confirmation message is shown. + 2. Test case: Edit a student’s details with invalid input. `student edit x n/John Smith`(x is a number larger than the list size) + - Expected: Error message "Student not found!" is shown. + 3. Test case: Edit a student’s details with missing required fields. `student edit 1 n/` + - Expected: Error message is shown, prompting for correct input. + +### Adding a Session + +1. **Adding a Session** + 1. Test case: Add a new session with valid details. `session add t/30 Mar 2025 11:30-13:30 sub/Math` + - Expected: Session is added successfully, and a confirmation message is shown. + 2. Test case: Add a new session with invalid details (e.g., missing required fields). `session add` + - Expected: Error message is shown, prompting for correct input. + 3. Test case: Add a new session with overlapping timeslots. `session add t/30 Mar 2025 11:30-13:30 sub/Science` + (Suppose there is a session whose time slot has overlapped with the new session's time slot.) + - Expected: Error message is shown, indicating the timeslot overlaps with an existing session. + +### Marking Attendance for a Session + +1. **Marking attendance for a session** + Prerequisite: The session and student must exist and the student must be enrolled in the session. + 1. Test case: Mark a session with valid input. `session mark 1 ses/1` + - Expected: Attendance is marked successfully, and a confirmation message is shown. + 2. Test case: Mark a session as completed with invalid input (e.g., invalid session id). `session mark 1 ses/x`(x is a number larger than the list size) + - Expected: Error message is shown, prompting for correct input. + 3. Test case: Mark a session which the student is not enrolled in. `session mark 1 ses/2` + - Expected: Error message is shown, indicating the student is not enrolled in the session. + +### Adding Feedback + +1. **Adding feedback for a session** + Prerequisite: The session and student must exist and the student must be enrolled in the session. + 1. Test case: Add feedback with valid input. `session feedback 1 ses/1 f/Great session!` + - Expected: Feedback is added successfully, and a confirmation message is shown. + 2. Test case: Add feedback with invalid input (e.g., missing required fields). `session feedback` + - Expected: Error message is shown, prompting for correct input. + 3. Test case: Add feedback for a session which the student is not enrolled in. `session feedback 1 ses/2 f/Great session!` + (Suppose student 1 is not enrolled in session 2) + - Expected: Error message is shown, indicating the student is not enrolled in the session. + +### Undo Feature + +1. **Undo Operations** + 1. Test case: Perform an action (e.g., add a student), then undo the action. + - Expected: The action is undone, and the previous state is restored. There is also a confirmation message shown. + +### Error Handling + +1. **Invalid Commands** + 1. Test case: Enter an invalid command. + - Expected: Error message is shown, indicating the command is not recognized/unknown. + +2. **System Errors** + 1. Test case: Simulate a system error (e.g., by corrupting a data file). + - Expected: Application handles the error gracefully, removing or replacing the corrupted data file + +These instructions provide a starting point for testers to work on; testers are expected to do more exploratory testing. + +## **Appendix: Planned Enhancements** + +1. Enhance undo functionality for the add command to allow for rollback of assigned IDs. +2. Improve the output display to seamlessly present long messages without requiring scrolling. +3. Refine cell selection behavior in the UI to reduce flickering and improve responsiveness. +4. Optimize the list view so it dynamically adjusts its height in response to changes in the filtered item count. +5. Enhance the UI focus management to ensure that the correct item is consistently highlighted. +6. Add support for multiple students of the same name. +7. A `redo` command to undo an `undo` command. +8. Improved `search` command for `student` and `session` with other fields including **tags** and **date/time range** with control over matching **any** or **all** fields. +9. `class` management commands that handle adding of **multiple** sessions and **mass** enrolling/marking of attendance for students. +10. Viewing sessions each student is enrolled in via the `students` tab. -1. _{ more test cases … }_ diff --git a/docs/SettingUp.md b/docs/SettingUp.md index aef33ec72fd..9c0b1d912a2 100644 --- a/docs/SettingUp.md +++ b/docs/SettingUp.md @@ -23,7 +23,7 @@ If you plan to use Intellij IDEA (highly recommended): 1. **Import the project as a Gradle project**: Follow the guide [_[se-edu/guides] IDEA: Importing a Gradle project_](https://se-education.org/guides/tutorials/intellijImportGradleProject.html) to import the project into IDEA.
:exclamation: Note: Importing a Gradle project is slightly different from importing a normal Java project. 1. **Verify the setup**: - 1. Run the `seedu.address.Main` and try a few commands. + 1. Run the `tutorly.Main` and try a few commands. 1. [Run the tests](Testing.md) to ensure they all pass. -------------------------------------------------------------------------------------------------------------------- diff --git a/docs/Testing.md b/docs/Testing.md index 8a99e82438a..d99c8e9a8ad 100644 --- a/docs/Testing.md +++ b/docs/Testing.md @@ -29,8 +29,8 @@ There are two ways to run tests. This project has three types of tests: 1. *Unit tests* targeting the lowest level methods/classes.
- e.g. `seedu.address.commons.StringUtilTest` + e.g. `tutorly.commons.StringUtilTest` 1. *Integration tests* that are checking the integration of multiple code units (those code units are assumed to be working).
- e.g. `seedu.address.storage.StorageManagerTest` -1. Hybrids of unit and integration tests. These test are checking multiple code units as well as how the are connected together.
- e.g. `seedu.address.logic.LogicManagerTest` + e.g. `tutorly.storage.StorageManagerTest` +1. Hybrids of unit and integration tests. These test are checking multiple code units as well as how they are connected together.
+ e.g. `tutorly.logic.LogicManagerTest` diff --git a/docs/UserGuide.md b/docs/UserGuide.md index 27c2d1cf16c..733a0238fdf 100644 --- a/docs/UserGuide.md +++ b/docs/UserGuide.md @@ -3,8 +3,11 @@ layout: page title: User Guide --- -AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized for use via a Command Line Interface** (CLI) while still having the benefits of a Graphical User Interface (GUI). If you can type fast, AB3 can get your contact management tasks done faster than traditional GUI apps. +Tutorly is a desktop app designed for private tutors to **manage their student and lesson records efficiently**. +It combines the speed and precision of typing commands with the convenience of a visual interface. +If you prefer using your keyboard over clicking through menus, Tutorly allows you to complete student management tasks more quickly than traditional apps. +## Table of Contents * Table of Contents {:toc} @@ -12,31 +15,56 @@ AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized fo ## Quick start -1. Ensure you have Java `17` or above installed in your Computer.
- **Mac users:** Ensure you have the precise JDK version prescribed [here](https://se-education.org/guides/tutorials/javaInstallationMac.html). +1. **Install Java**: Ensure you have Java `17` or above installed in your Computer. You can download the correct [JDK](#glossary) for your [operating system](#glossary) using this [link](https://www.oracle.com/sg/java/technologies/downloads/).
+ **Mac users**: Ensure you have the precise JDK version prescribed [here](https://se-education.org/guides/tutorials/javaInstallationMac.html). -1. Download the latest `.jar` file from [here](https://github.com/se-edu/addressbook-level3/releases). +2. **Download Tutorly**: Get the latest [JAR](#glossary) file from [here](https://github.com/AY2425S2-CS2103T-T17-3/tp/releases/latest/download/tutorly.jar). -1. Copy the file to the folder you want to use as the _home folder_ for your AddressBook. +3. **Move the file**: Locate the downloaded `tutorly.jar` file and place it in a folder where you want to keep the app's data. This will be the app's _home folder_. -1. Open a command terminal, `cd` into the folder you put the jar file in, and use the `java -jar addressbook.jar` command to run the application.
- A GUI similar to the below should appear in a few seconds. Note how the app contains some sample data.
+4. **Open a [command terminal](#glossary)** - This is a tool that lets you run commands on your computer: + - On **Windows**: Press `Win + R`, type `cmd`, and press **Enter**. + - On **Mac**: Open **Terminal** from the Applications > Utilities folder. + - On **Linux**: Open **Terminal** from your applications menu. + +5. **Navigate to the folder**: In the terminal, type `cd ` (with a space after). Then, **click and hold** the _home folder_, **drag** it into the terminal window and **release** it. Doing this will automatically insert the full path of the folder. Press **Enter**. + +6. **Run Tutorly**: Type `java -jar tutorly.jar` and press **Enter**. This will start the application. A GUI similar to the below should appear in a few seconds, containing some sample data.
 +7. **UI Layout**: Feel free to take a look at the following images for a better understanding of the layout! + +### Students Tab + + + +### Student Card + + + +### Sessions Tab -1. Type the command in the command box and press Enter to execute it. e.g. typing **`help`** and pressing Enter will open the help window.
- Some example commands you can try: + - * `list` : Lists all contacts. +### Execute a command - * `add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01` : Adds a contact named `John Doe` to the Address Book. +Type the command in the command box and press Enter to execute it. e.g. typing **`help`** and pressing Enter will open the help window.
+Some example commands you can try: - * `delete 3` : Deletes the 3rd contact shown in the current list. +* `student list` : Lists all students. - * `clear` : Deletes all contacts. +* `student add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01` : Adds a student named `John Doe` to the app. - * `exit` : Exits the app. +* `student delete 3` : Deletes the student with the ID 3. -1. Refer to the [Features](#features) below for details of each command. +* `session list` : List all sessions. + +* `clear` : Deletes all students and sessions. + +* `exit` : Exits the app. + +Refer to the [Features](#features) below for details of each command. + +[Back to top :arrow_up:](#table-of-contents) -------------------------------------------------------------------------------------------------------------------- @@ -46,137 +74,489 @@ AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized fo **:information_source: Notes about the command format:**
-* Words in `UPPER_CASE` are the parameters to be supplied by the user.
- e.g. in `add n/NAME`, `NAME` is a parameter which can be used as `add n/John Doe`. +* Words in `UPPER_CASE` are the [parameters](#parameter-summary) to be supplied by the user.
+ e.g. in `student add n/NAME`, `NAME` is a parameter which can be used as `student add n/John Doe`. -* Items in square brackets are optional.
+* [STUDENT_IDENTIFIER](#glossary) can either be the target student's ID, or their full name. Examples: `John Doe` or `2`. + +* Parameters in square brackets are optional.
e.g `n/NAME [t/TAG]` can be used as `n/John Doe t/friend` or as `n/John Doe`. * Items with `…` after them can be used multiple times including zero times.
e.g. `[t/TAG]…` can be used as ` ` (i.e. 0 times), `t/friend`, `t/friend t/family` etc. * Parameters can be in any order.
- e.g. if the command specifies `n/NAME p/PHONE_NUMBER`, `p/PHONE_NUMBER n/NAME` is also acceptable. + e.g. if the command specifies `n/NAME p/PHONE`, `p/PHONE n/NAME` is also acceptable. -* Extraneous parameters for commands that do not take in parameters (such as `help`, `list`, `exit` and `clear`) will be ignored.
- e.g. if the command specifies `help 123`, it will be interpreted as `help`. +* Extra parameters for commands that do not take in parameters ([general](#general-commands) commands, `student list` and `session list`) will be ignored.
+ e.g. if the command specifies `help 123` or `session list blah`, it will be interpreted as `help` and `session list`. * If you are using a PDF version of this document, be careful when copying and pasting commands that span multiple lines as space characters surrounding line-breaks may be omitted when copied over to the application.
Max: 20 | +65 98765432 | +| SUBJECT | - | - | Max: 20 | Mathematics | +| TAG | - | - | Max: 20 | A-Levels | +| TIMESLOT | `dd MMM yyyy HH:mm-HH:mm` for sessions within a day,
`dd MMM yyyy HH:mm-dd MMM yyyy HH:mm` for sessions spanning multiple days | - | - | 11 Apr 2025 16:00-18:00 | - +[Back to top :arrow_up:](#table-of-contents) + +-------------------------------------------------------------------------------------------------------------------- + +### General Commands + +#### Viewing help: `help` + +Shows a window containing the command summary with a link to this user guide. Format: `help` +Help window: -### Adding a person: `add` + + +#### Clearing all data: `clear` -Adds a person to the address book. +Clears all students and sessions from the app. -Format: `add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…` +Format: `clear` + +Example output: + + + +Running the [undo](#undoing-a-command-undo) command after `clear` restores all students and sessions to before the command was run. + +#### Exiting the program: `exit` + +Closes the Tutorly app. + +Format: `exit` + +#### Undoing a command: `undo` + +Undoes the last successfully executed command that has updated the data. + +Commands that update data and are thus undoable: +* The `clear` command. +* The `add`, `delete` and `edit` commands for [student](#student-management-student-action) and [session](#session-management-session-action). +* The `enrol`, `unenrol`, `mark`, `unmark` and `feedback` commands for [session](#session-management-session-action). + +Format: `undo` + +Examples: +* `session delete` followed by `undo` will undo the delete command by adding the session back. +* If the following commands were ran in order: `student edit`, `student add`, `student search`, `help`, running `undo` will undo the `student add` command. + +
:exclamation: **Caution:**
+Commands that are not successfully executed due to errors will not be undone.
+
+After closing and re-opening the app, all previous commands will be forgotten and running `undo` will not undo any previous commands before the app was closed.
+
+
+[Back to top :arrow_up:](#table-of-contents)
+
+--------------------------------------------------------------------------------------------------------------------
+
+### Viewing tabs
:bulb: **Tip:**
-A person can have any number of tags (including 0)
+The main window will automatically switch to the tab which shows the results of the command that has been executed.
+
+Commands other than `search` will also clear any filters from previous `search` commands.
+#### Viewing students tab: `student`
+
+Shows the student tab in the main window.
+
+Format: `student`
+
+[Back to top :arrow_up:](#table-of-contents)
+
+#### Viewing sessions tab: `session`
+
+Shows the session tab in the main window.
+
+Format: `session`
+
+[Back to top :arrow_up:](#table-of-contents)
+
+--------------------------------------------------------------------------------------------------------------------
+
+### Student Management: `student ACTION`
+
+The following commands all begin with `student` followed by an action word.
+
+#### Adding a student: `add`
+
+Adds a student to the app.
+
+Format: `student add n/NAME [p/PHONE] [e/EMAIL] [a/ADDRESS] [m/MEMO] [t/TAG]…`
+
+* Refer to the [parameter summary](#parameter-summary) for the expected formats of the parameters.
+
+:bulb: **Tip:**
+A student can have any number of tags (including 0).
+
+
+Examples:
+* `student add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01 m/loves Math`
+* `student add n/Mary Jane t/olevels e/maryjane@example.com p/81234567 t/priority`
+
+:exclamation: **Caution:**
+Besides IDs, names are also used to uniquely identify students. Thus, duplicate students with the same name are not allowed.
+
+Running `student add n/Mary Jane` when a student with the name `Mary Jane` already exists will show an error as it is considered a duplicate student.
+
+
+Example output:
+
+
+
+Running the [undo](#undoing-a-command-undo) command after `student add` removes the newly added student.
+
+[Back to top :arrow_up:](#table-of-contents)
+
+#### Listing all students: `list`
+
+Shows a list of all students.
+
+Format: `student list`
+
+[Back to top :arrow_up:](#table-of-contents)
+
+#### Viewing student card: `view`
+
+Scrolls to the details of the student with the specified [STUDENT_IDENTIFIER](#glossary) in the window of the student tab.
+
+Format: `student view STUDENT_IDENTIFIER`
+
Examples:
-* `add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01`
-* `add n/Betsy Crowe t/friend e/betsycrowe@example.com a/Newgate Prison p/1234567 t/criminal`
+* `student view 1`
+* `student view John Doe`
-### Listing all persons : `list`
+Example output:
-Shows a list of all persons in the address book.
+
-Format: `list`
+[Back to top :arrow_up:](#table-of-contents)
-### Editing a person : `edit`
+#### Editing a student: `edit`
-Edits an existing person in the address book.
+Edits an existing student with the specified [STUDENT_IDENTIFIER](#glossary).
-Format: `edit INDEX [n/NAME] [p/PHONE] [e/EMAIL] [a/ADDRESS] [t/TAG]…`
+Format: `student edit STUDENT_IDENTIFIER [n/NAME] [p/PHONE] [e/EMAIL] [a/ADDRESS] [m/MEMO] [t/TAG]…`
-* Edits the person at the specified `INDEX`. The index refers to the index number shown in the displayed person list. The index **must be a positive integer** 1, 2, 3, …
-* At least one of the optional fields must be provided.
+* At least one of the optional [parameters](#parameter-summary) must be provided.
* Existing values will be updated to the input values.
-* When editing tags, the existing tags of the person will be removed i.e adding of tags is not cumulative.
-* You can remove all the person’s tags by typing `t/` without
- specifying any tags after it.
+* When editing tags, the existing tags of the student will be removed i.e adding of tags is not cumulative.
+* You can remove all the student’s tags by typing `t/` without specifying any tags after it.
Examples:
-* `edit 1 p/91234567 e/johndoe@example.com` Edits the phone number and email address of the 1st person to be `91234567` and `johndoe@example.com` respectively.
-* `edit 2 n/Betsy Crower t/` Edits the name of the 2nd person to be `Betsy Crower` and clears all existing tags.
+* `student edit John Doe p/91234567 e/johndoe@example.com` Edits the phone number and email address of John Doe to be `91234567` and `johndoe@example.com` respectively.
+* `student edit 2 n/Betsy Crower t/` Edits the name of the student with an ID of 2 to be `Betsy Crower` and clears all existing tags.
-### Locating persons by name: `find`
+:exclamation: **Caution:**
+Besides IDs, names are also used to uniquely identify students. Thus, duplicate students with the same name are not allowed.
+
+Running `student edit 3 n/Betsy Crower` when another student named `Betsy Crower` already exists will show an error as it is considered a duplicate student.
+
+
+Example output:
+
+
+
+Running the [undo](#undoing-a-command-undo) command after `student edit` reverts the student's details back to before the edit was made.
+
+[Back to top :arrow_up:](#table-of-contents)
-Finds persons whose names contain any of the given keywords.
+#### Searching for students: `search`
-Format: `find KEYWORD [MORE_KEYWORDS]`
+Finds students whose names or phone numbers contain any of the given keywords, or is enrolled to a specific session.
-* The search is case-insensitive. e.g `hans` will match `Hans`
-* The order of the keywords does not matter. e.g. `Hans Bo` will match `Bo Hans`
-* Only the name is searched.
-* Only full words will be matched e.g. `Han` will not match `Hans`
-* Persons matching at least one keyword will be returned (i.e. `OR` search).
- e.g. `Hans Bo` will return `Hans Gruber`, `Bo Yang`
+Format: `student search [ses/SESSION_ID] [n/NAME_KEYWORDS] [p/PHONE_KEYWORDS]`
+
+* The keywords are case-insensitive and order does not matter. e.g. `hans bo` will match `Bo Hans`
+* Incomplete words will still be matched e.g. `Han` will match `Hans` or `8765` will match `91238765`
+* Students matching at least one keyword **or** are enrolled to the session will be returned.
+
+:exclamation: **Caution:**
+`SESSION_ID` only accepts one valid positive number that corresponds with an existing session's ID.
+
+This will be updated in future versions to allow the searching of multiple IDs.
+
Examples:
-* `find John` returns `john` and `John Doe`
-* `find alex david` returns `Alex Yeoh`, `David Li`-  +* `student search n/John p/9123 8765` returns `johnathan`, `John Doe` and other students with a phone number that contains `9123` or `8765`. +* `student search ses/3 n/alex david` returns `Alex Yeoh`, `David Li` and other students who attended session with the id 3. +* `student search` will simply return all students. + +Example output (with matching keywords highlighted): -### Deleting a person : `delete` + -Deletes the specified person from the address book. +[Back to top :arrow_up:](#table-of-contents) -Format: `delete INDEX` +#### Deleting a student: `delete` -* Deletes the person at the specified `INDEX`. -* The index refers to the index number shown in the displayed person list. -* The index **must be a positive integer** 1, 2, 3, … +Deletes the student with the specified [STUDENT_IDENTIFIER](#glossary). + +Format: `student delete STUDENT_IDENTIFIER` Examples: -* `list` followed by `delete 2` deletes the 2nd person in the address book. -* `find Betsy` followed by `delete 1` deletes the 1st person in the results of the `find` command. +* `student delete 2` deletes the student with the ID of 2. +* `student delete John Doe` deletes the student with the name `John Doe`. -### Clearing all entries : `clear` +Running the [undo](#undoing-a-command-undo) command after `student delete` adds the deleted student back. -Clears all entries from the address book. +[Back to top :arrow_up:](#table-of-contents) -Format: `clear` +-------------------------------------------------------------------------------------------------------------------- -### Exiting the program : `exit` +### Session Management: `session ACTION` -Exits the program. +The following commands all begin with `session` followed by an action word. -Format: `exit` +#### Adding a session: `add` + +Adds a session to the app. + +Format: `session add t/TIMESLOT sub/SUBJECT` + +* Refer to the [parameter summary](#parameter-summary) for the expected format of `TIMESLOT` and `SUBJECT`. + +Examples: +* `session add t/30 Mar 2025 11:30-13:30 sub/Math` adds a session with the subject `Math` on 30 March 2025 from 11.30am to 13.30pm. +* `session add t/30 Mar 2025 23:00-31 Mar 2025 01:00 sub/Eng` adds a session with the subject `Eng` which lasts 2 hours from 30 March 2025 11pm to 31 March 2025 1am. + +Running the [undo](#undoing-a-command-undo) command after `session add` removes the newly added session. + +Example output: + + + +[Back to top :arrow_up:](#table-of-contents) + +#### Listing all sessions: `list` + +Shows a list of all sessions. + +Format: `session list` + +[Back to top :arrow_up:](#table-of-contents) + +#### Viewing attendance for a session: `view` + +Shows the attendance of students for a given session. + +Format: `session view SESSION_ID` + +Examples: +* `session view 1` +* `session view 5` + +Example Output: + + + +[Back to top :arrow_up:](#table-of-contents) + +#### Editing a session: `edit` + +Edits an existing session with the specified `SESSION_ID`. + +Format: `session edit SESSION_ID [t/TIMESLOT] [sub/SUBJECT]` + +* At least one of the optional [parameters](#parameter-summary) must be provided. +* Existing values will be updated to the input values. + +Examples: +* `session edit 3 t/11 Apr 2025 11:30-13:30` Edits the date of the session with the ID 3 to be on 11 April 2025 from 11.30am to 1.30pm. +* `session edit 2 t/20 June 2025 23:00-21 June 2025 01:00 sub/Math` Edits the date and subject of the session with the ID 2 to last from 20 June 2025 11pm to 21 June 2025 1am with the subject `Math`. + +Running the [undo](#undoing-a-command-undo) command after `session edit` reverts the session's details back to before the edit was made. + +[Back to top :arrow_up:](#table-of-contents) + +#### Searching for sessions: `search` + +Finds sessions on a particular date or on a subject which matches any of the given keywords. + +Format: `session search [d/DATE] [sub/SUBJECT_KEYWORDS]` + +* Refer to the [parameter summary](#parameter-summary) for the expected format of `DATE`. +* The keywords are case-insensitive and order does not matter. e.g. `math eng` will match `Eng Math` +* Incomplete words will still be matched e.g. `Mat` will match `Math` +* Sessions whose timeslots contain the given date or have a subject that match at least one keyword will be returned. + +Examples: +* `session search d/22 May 2025` returns sessions with timeslots that include 22 May 2025. +* `session search sub/Math d/11 Jun 2025` returns sessions with subjects `Math`, `Mathematics` and sessions with timeslots that include 11 June 2025. +* `session search` will simply return all sessions. + +Example output (with matching keywords and date highlighted): + + + +[Back to top :arrow_up:](#table-of-contents) + +#### Deleting a session: `delete` + +Deletes the session with the specified `SESSION_ID`. + +Format: `session delete SESSION_ID` + +Examples: +* `session delete 2` deletes the session with the ID of 2. + +Running the [undo](#undoing-a-command-undo) command after `session delete` adds the deleted session back. + +[Back to top :arrow_up:](#table-of-contents) + +#### Enrolling a student to a session: `enrol` + +Enrols a student with the specified [STUDENT_IDENTIFIER](#glossary) to a specific session. + +Format: `session enrol STUDENT_IDENTIFIER ses/SESSION_ID` + +* The attendance for the student to the session upon enrolment is marked as absent by default. + +Examples: +* `session enrol 2 ses/3` enrols a student with an ID of 2 to attend a session with an ID of 3. +* `session enrol John Doe ses/4` enrols a student with the name `John Doe` to attend a session with an ID of 4. + +Example output: + + + +Running the [undo](#undoing-a-command-undo) command after `session enrol` will unenrol the student from the session. + +[Back to top :arrow_up:](#table-of-contents) + +#### Unenrolling a student from a session: `unenrol` + +Unenrols a student with the specified [STUDENT_IDENTIFIER](#glossary) from a session. + +Format: `session unenrol STUDENT_IDENTIFIER ses/SESSION_ID` + +Examples: +* `session unenrol 2 ses/3` unenrols a student with an ID of 2 from a session with an ID of 3. +* `session unenrol John Doe ses/4` unenrols a student with the name `John Doe` from a session with an ID of 4. + +Running the [undo](#undoing-a-command-undo) command after `session unenrol` will enrol the student back into the session. + +[Back to top :arrow_up:](#table-of-contents) + +#### Marking attendance: `mark` + +Marks the attendance of a student with the specified [STUDENT_IDENTIFIER](#glossary) for a session. + +Format: `session mark STUDENT_IDENTIFIER ses/SESSION_ID` + +* Note that only students who are enrolled in the session can be marked as present. + +Examples: +* `session mark 2 ses/3` marks the attendance for the student with an ID of 2 for a session with an ID of 3 as present. +* `session mark John Doe ses/4` marks the attendance for a student with the name `John Doe` for a session with an ID of 4 as present. + +Running the [undo](#undoing-a-command-undo) command after `session mark` will unmark the student's attendance in the session. + +
:bulb: **Tip:**
+You can also click on the checkbox next to a student's name in a session's attendance list to toggle the marking of attendance.
+
+
+[Back to top :arrow_up:](#table-of-contents)
+
+#### Unmarking attendance: `unmark`
+
+Unmarks the attendance of a student with the specified [STUDENT_IDENTIFIER](#glossary) for a session.
+
+Format: `session unmark STUDENT_IDENTIFIER ses/SESSION_ID`
+
+* Note that only students who are enrolled in the session can be unmarked.
+
+Examples:
+* `session unmark 2 ses/3` unmarks the attendance for the student with an ID of 2 for a session with an ID of 3.
+* `session unmark John Doe ses/4` unmarks the attendance for a student with the name `John Doe` for a session with an ID of 4.
+
+Running the [undo](#undoing-a-command-undo) command after `session unmark` will mark the student's attendance in the session.
+
+:bulb: **Tip:**
+You can also click on the checkbox next to a student's name in a session's attendance list to toggle the marking of attendance.
+
+
+[Back to top :arrow_up:](#table-of-contents)
+
+#### Adding or updating feedback: `feedback`
+
+Adds or updates the feedback for a student with the specified [STUDENT_IDENTIFIER](#glossary) in a session.
+
+Format: `session feedback STUDENT_IDENTIFIER ses/SESSION_ID f/FEEDBACK`
+
+* Refer to the [parameter summary](#parameter-summary) for the expected format of `FEEDBACK`.
+* If no feedback exists, a new feedback will be added for the student in the session.
+* If a feedback already exists, the old feedback will be overwritten, i.e. Only one feedback is allowed per student per session.
+* You can remove a previously set feedback by typing f/ without specifying any feedback after it.
+* Feedback for a student is viewable in the attendance list of a session.
+
+Examples:
+* `session feedback 2 ses/3 f/Good Job!` updates the feedback `Good Job!` for the student with an ID of 2 for a session with an ID of 3.
+* `session feedback John Doe ses/4 f/Sick leave` updates the feedback `Sick leave` for a student with the name `John Doe` for a session with an ID of 4.
+* `session feedback Betsy Crower ses/4 f/` clears the feedback for a student with the name `Betsy Crower` for a session with an ID of 4.
+
+Example output:
+
+
+
+Running the [undo](#undoing-a-command-undo) command after `session feedback` reverts the feedback back to before the command was run.
+
+[Back to top :arrow_up:](#table-of-contents)
+
+--------------------------------------------------------------------------------------------------------------------
### Saving the data
-AddressBook data are saved in the hard disk automatically after any command that changes the data. There is no need to save manually.
+Tutorly data are saved in the hard disk automatically after any command that changes the data. There is no need to save manually.
### Editing the data file
-AddressBook data are saved automatically as a JSON file `[JAR file location]/data/addressbook.json`. Advanced users are welcome to update data directly by editing that data file.
+Tutorly data are saved automatically as a JSON file `[home_folder]/data/tutorly.json`. Advanced users are welcome to update data directly by editing that data file.
:exclamation: **Caution:**
-If your changes to the data file makes its format invalid, AddressBook will discard all data and start with an empty data file at the next run. Hence, it is recommended to take a backup of the file before editing it.
-Furthermore, certain edits can cause the AddressBook to behave in unexpected ways (e.g., if a value entered is outside of the acceptable range). Therefore, edit the data file only if you are confident that you can update it correctly. +If your changes to the data file makes its format invalid, Tutorly will discard all data and start with an empty data file at the next run. Hence, it is recommended to take a backup of the file before editing it.
+Furthermore, certain edits can cause the Tutorly to behave in unexpected ways (e.g., if a value entered is outside of the acceptable range). Therefore, edit the data file only if you are confident that you can update it correctly.
-### Archiving data files `[coming in v2.0]`
-
-_Details coming soon ..._
+[Back to top :arrow_up:](#table-of-contents)
--------------------------------------------------------------------------------------------------------------------
## FAQ
**Q**: How do I transfer my data to another Computer?-Furthermore, certain edits can cause the AddressBook to behave in unexpected ways (e.g., if a value entered is outside of the acceptable range). Therefore, edit the data file only if you are confident that you can update it correctly. +If your changes to the data file makes its format invalid, Tutorly will discard all data and start with an empty data file at the next run. Hence, it is recommended to take a backup of the file before editing it.
+Furthermore, certain edits can cause the Tutorly to behave in unexpected ways (e.g., if a value entered is outside of the acceptable range). Therefore, edit the data file only if you are confident that you can update it correctly.
-**A**: Install the app in the other computer and overwrite the empty data file it creates with the file that contains the data of your previous AddressBook home folder. +**A**: Install the app in the other computer and overwrite the empty data file it creates with the file that contains the data of your previous Tutorly _home folder_. + +**Q**: What is the difference between the `student list` and `student` commands?
+**A**: The `student list` command will list all students in Tutorly. The `student` command simply switches the active tab to students and preserves results from any previous `student search` commands. The same applies to `session` and `session list`. + +**Q**: What is the difference between the `memo` and `feedback`?
+**A**: `Memo` is a short note you can add on to a student's details, while `feedback` is specifically for a student's performance in a particular session. + +**Q**: How should I fill in the `STUDENT_IDENTIFIER` parameter?
+**A**: The [`STUDENT_IDENTIFIER`](#glossary) can either be the student's ID or their full name, both of which are viewable from the student tab in the app. + +[Back to top :arrow_up:](#table-of-contents) -------------------------------------------------------------------------------------------------------------------- @@ -184,17 +564,70 @@ _Details coming soon ..._ 1. **When using multiple screens**, if you move the application to a secondary screen, and later switch to using only the primary screen, the GUI will open off-screen. The remedy is to delete the `preferences.json` file created by the application before running the application again. 2. **If you minimize the Help Window** and then run the `help` command (or use the `Help` menu, or the keyboard shortcut `F1`) again, the original Help Window will remain minimized, and no new Help Window will appear. The remedy is to manually restore the minimized Help Window. +3. **For commands that should focus on a specific item in the window**, like after a `student add` or `session enrol`, the window may sometimes not scroll to the target item due to UI loading behaviour. The remedy is to run the `view` command again for the window to scroll to the target item, or use the scrollbar in the tab. + +[Back to top :arrow_up:](#table-of-contents) -------------------------------------------------------------------------------------------------------------------- ## Command summary -Action | Format, Examples ---------|------------------ -**Add** | `add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…`
e.g., `add n/James Ho p/22224444 e/jamesho@example.com a/123, Clementi Rd, 1234665 t/friend t/colleague` -**Clear** | `clear` -**Delete** | `delete INDEX`
e.g., `delete 3` -**Edit** | `edit INDEX [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [a/ADDRESS] [t/TAG]…`
e.g.,`edit 2 n/James Lee e/jameslee@example.com` -**Find** | `find KEYWORD [MORE_KEYWORDS]`
e.g., `find James Jake` -**List** | `list` -**Help** | `help` +| Context | Action | Format | Examples | +|---------|------------------------------------------------------------------|-----------------------------------------------------------------------------------------------|--------------------------------------------------------| +| General | [Help](#viewing-help-help) | `help` | - | +| | [Clear data](#clearing-all-data-clear) | `clear` | - | +| | [Exit](#exiting-the-program-exit) | `exit` | - | +| | [Undo command](#undoing-a-command-undo) | `undo` | - | +| Tab | [Show students tab](#viewing-students-tab-student) | `student` | - | +| | [Show session tab](#viewing-sessions-tab-session) | `session` | - | +| Student | [Add](#adding-a-student-add) | `student add n/NAME [p/PHONE] [e/EMAIL] [a/ADDRESS] [m/MEMO] [t/TAG]…` | `student add n/John Doe p/98765432` | +| | [List](#listing-all-students-list) | `student list` | - | +| | [View card](#viewing-student-card-view) | `student view STUDENT_IDENTIFIER` | `student view 1` or `student view John Doe` | +| | [Edit](#editing-a-student-edit) | `student edit STUDENT_IDENTIFIER [n/NAME] [p/PHONE] [e/EMAIL] [a/ADDRESS] [m/MEMO] [t/TAG]…` | `student edit 2 n/James Lee p/91234567` | +| | [Search](#searching-for-students-search) | `student search [ses/SESSION_ID] [n/NAME_KEYWORDS] [p/PHONE_KEYWORDS]` | `student search n/alex dav p/9123 8765` | +| | [Delete](#deleting-a-student-delete) | `student delete STUDENT_IDENTIFIER` | `student delete 3` | +| Session | [Add](#adding-a-session-add) | `session add t/TIMESLOT sub/SUBJECT` | `session add t/30 Mar 2025 11:30-13:30 sub/Math` | +| | [List](#listing-all-sessions-list) | `session list` | - | +| | [View attendance](#viewing-attendance-for-a-session-view) | `session view SESSION_ID` | `session view 4` | +| | [Edit](#editing-a-session-edit) | `session edit SESSION_ID [t/TIMESLOT] [sub/SUBJECT]` | `session edit 2 t/11 Jun 2025 11:30-13:30 sub/English` | +| | [Search](#searching-for-sessions-search) | `session search [d/DATE] [sub/SUBJECT_KEYWORDS]` | `session search d/2025-04-15 sub/Math Eng` | +| | [Delete](#deleting-a-session-delete) | `session delete SESSION_ID` | `session delete 1` | +| | [Enrol student](#enrolling-a-student-to-a-session-enrol) | `session enrol STUDENT_IDENTIFIER ses/SESSION_ID` | `session enrol 4 ses/3` | +| | [Unenrol student](#unenrolling-a-student-from-a-session-unenrol) | `session unenrol STUDENT_IDENTIFIER ses/SESSION_ID` | `session unenrol 4 ses/3` | +| | [Mark attendance](#marking-attendance-mark) | `session mark STUDENT_IDENTIFIER ses/SESSION_ID` | `session mark John Doe ses/2` | +| | [Unmark attendance](#unmarking-attendance-unmark) | `session unmark STUDENT_IDENTIFIER ses/SESSION_ID` | `session unmark 3 ses/2` | +| | [Add or Update feedback](#adding-or-updating-feedback-feedback) | `session feedback STUDENT_IDENTIFIER ses/SESSION_ID f/FEEDBACK` | `session feedback 3 ses/2 f/Good Job!` | + +[Back to top :arrow_up:](#table-of-contents) + +-------------------------------------------------------------------------------------------------------------------- + +## Glossary + +| Term | Definition | +|--------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Command Terminal | A tool on a computer where you type instructions to make the computer perform tasks. | +| Home folder | The folder which contains the `tutorly.jar` file and data folder. | +| JAR | Java Archive file: A package that bundles a Java program and all its necessary parts into a single file, making it easier to share and run. | +| JDK | Java Development Kit: A software package that provides everything needed to create and run Java programs. | +| Operating System | An operating system is the main software that manages a computer’s hardware and allows you to run applications. Some examples include `Windows`, `Mac` and `Linux`. | +| Parameters | These are placeholders in a command that users replace with specific information to customize the command's action. They are usually prefixed with letters like `n/` or `p/`. | +| STUDENT_IDENTIFIER | A parameter used to identify a student. It can either be the student's ID (a positive number), or their full name. | + +[Back to top :arrow_up:](#table-of-contents) + +## Coming soon + +Planned features that will be added in the coming versions. + +1. A `redo` command in case you want to undo your `undo`. +2. Improved `search` command for `student` and `session` with other fields including **tags** and **date/time range** with control over matching **any** or **all** fields. +3. `class` management commands that handles adding of **multiple** sessions and **mass** enrolling/marking of attendance for students. +4. Viewing sessions each student is enrolled in via the `students` tab. +5. Add support for multiple students of the same name. +6. Better auto scroll and focus on target item being updated in window. +7. Seamlessly present long messages without requiring scrolling. + +[Back to top :arrow_up:](#table-of-contents) + +-------------------------------------------------------------------------------------------------------------------- diff --git a/docs/_config.yml b/docs/_config.yml index 6bd245d8f4e..3e80bc4c079 100644 --- a/docs/_config.yml +++ b/docs/_config.yml @@ -1,4 +1,4 @@ -title: "AB-3" +title: "Tutorly" theme: minima header_pages: @@ -8,7 +8,7 @@ header_pages: markdown: kramdown -repository: "se-edu/addressbook-level3" +repository: "AY2425S2-CS2103T-T17-3/tp" github_icon: "images/github-icon.png" plugins: diff --git a/docs/_sass/minima/_base.scss b/docs/_sass/minima/_base.scss index 0d3f6e80ced..69244d37219 100644 --- a/docs/_sass/minima/_base.scss +++ b/docs/_sass/minima/_base.scss @@ -288,7 +288,7 @@ table { text-align: center; } .site-header:before { - content: "AB-3"; + content: "Tutorly"; font-size: 32px; } } diff --git a/docs/diagrams/ArchitectureSequenceDiagram.puml b/docs/diagrams/ArchitectureSequenceDiagram.puml index 48b6cc4333c..9ce63455b0e 100644 --- a/docs/diagrams/ArchitectureSequenceDiagram.puml +++ b/docs/diagrams/ArchitectureSequenceDiagram.puml @@ -8,12 +8,18 @@ Participant ":Logic" as logic LOGIC_COLOR Participant ":Model" as model MODEL_COLOR Participant ":Storage" as storage STORAGE_COLOR -user -[USER_COLOR]> ui : "delete 1" +user -[USER_COLOR]> ui : "student delete 1" activate ui UI_COLOR -ui -[UI_COLOR]> logic : execute("delete 1") +ui -[UI_COLOR]> logic : execute("student delete 1") activate logic LOGIC_COLOR +logic -[LOGIC_COLOR]> model : getPersonByIdentity(...) +activate model MODEL_COLOR + +model -[MODEL_COLOR]-> logic : p +deactivate model + logic -[LOGIC_COLOR]> model : deletePerson(p) activate model MODEL_COLOR diff --git a/docs/diagrams/BetterModelClassDiagram.puml b/docs/diagrams/BetterModelClassDiagram.puml index 598474a5c82..93b04fa806a 100644 --- a/docs/diagrams/BetterModelClassDiagram.puml +++ b/docs/diagrams/BetterModelClassDiagram.puml @@ -6,16 +6,20 @@ skinparam classBackgroundColor MODEL_COLOR AddressBook *-right-> "1" UniquePersonList AddressBook *-right-> "1" UniqueTagList +AddressBook *-left-> "1" UniqueSessionList +AddressBook *-down-> "1" UniqueAttendanceRecordList + UniqueTagList -[hidden]down- UniquePersonList UniqueTagList -[hidden]down- UniquePersonList -UniqueTagList -right-> "*" Tag -UniquePersonList -right-> Person +UniqueTagList o-right-> "*" Tag +UniquePersonList o-right-> "*" Person +UniqueSessionList o-left-> "*" Session +UniqueAttendanceRecordList o-down-> "*" AttendanceRecord Person -up-> "*" Tag -Person *--> Name -Person *--> Phone -Person *--> Email -Person *--> Address +Person "1" --o "*" AttendanceRecord +Session "1" --o "*" AttendanceRecord + @enduml diff --git a/docs/diagrams/DeleteSequenceDiagram.puml b/docs/diagrams/DeleteSequenceDiagram.puml index 5241e79d7da..beab4aaa57a 100644 --- a/docs/diagrams/DeleteSequenceDiagram.puml +++ b/docs/diagrams/DeleteSequenceDiagram.puml @@ -5,8 +5,10 @@ skinparam ArrowFontStyle plain box Logic LOGIC_COLOR_T1 participant ":LogicManager" as LogicManager LOGIC_COLOR participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR -participant ":DeleteCommandParser" as DeleteCommandParser LOGIC_COLOR -participant "d:DeleteCommand" as DeleteCommand LOGIC_COLOR +participant ":StudentCommandParser" as StudentCommandParser LOGIC_COLOR +participant ":DeleteStudentCommandParser" as DeleteStudentCommandParser LOGIC_COLOR +participant "i:Identity" as Identity LOGIC_COLOR +participant "d:DeleteStudentCommand" as DeleteStudentCommand LOGIC_COLOR participant "r:CommandResult" as CommandResult LOGIC_COLOR end box @@ -14,56 +16,85 @@ box Model MODEL_COLOR_T1 participant "m:Model" as Model MODEL_COLOR end box -[-> LogicManager : execute("delete 1") +[-> LogicManager : execute("student delete 1") activate LogicManager -LogicManager -> AddressBookParser : parseCommand("delete 1") +LogicManager -> AddressBookParser : parse("student delete 1") activate AddressBookParser -create DeleteCommandParser -AddressBookParser -> DeleteCommandParser -activate DeleteCommandParser +create StudentCommandParser +AddressBookParser -> StudentCommandParser +activate StudentCommandParser -DeleteCommandParser --> AddressBookParser -deactivate DeleteCommandParser +StudentCommandParser --> AddressBookParser +deactivate StudentCommandParser -AddressBookParser -> DeleteCommandParser : parse("1") -activate DeleteCommandParser +AddressBookParser -> StudentCommandParser : parse("delete 1") +activate StudentCommandParser -create DeleteCommand -DeleteCommandParser -> DeleteCommand -activate DeleteCommand +create DeleteStudentCommandParser +StudentCommandParser -> DeleteStudentCommandParser +activate DeleteStudentCommandParser -DeleteCommand --> DeleteCommandParser : -deactivate DeleteCommand +DeleteStudentCommandParser --> StudentCommandParser +deactivate DeleteStudentCommandParser -DeleteCommandParser --> AddressBookParser : d -deactivate DeleteCommandParser +StudentCommandParser -> DeleteStudentCommandParser : parse("1") +activate DeleteStudentCommandParser + +create Identity +DeleteStudentCommandParser -> Identity +activate Identity + +Identity --> DeleteStudentCommandParser +deactivate Identity + +create DeleteStudentCommand +DeleteStudentCommandParser -> DeleteStudentCommand : DeleteStudentCommand(i) +activate DeleteStudentCommand + +DeleteStudentCommand --> DeleteStudentCommandParser : +deactivate DeleteStudentCommand + +DeleteStudentCommandParser --> StudentCommandParser : d +deactivate DeleteStudentCommandParser 'Hidden arrow to position the destroy marker below the end of the activation bar. -DeleteCommandParser -[hidden]-> AddressBookParser -destroy DeleteCommandParser +DeleteStudentCommandParser -[hidden]-> StudentCommandParser +destroy DeleteStudentCommandParser + +StudentCommandParser --> AddressBookParser : d +deactivate StudentCommandParser +'Hidden arrow to position the destroy marker below the end of the activation bar. +StudentCommandParser -[hidden]-> AddressBookParser +destroy StudentCommandParser AddressBookParser --> LogicManager : d deactivate AddressBookParser -LogicManager -> DeleteCommand : execute(m) -activate DeleteCommand +LogicManager -> DeleteStudentCommand : execute(m) +activate DeleteStudentCommand + +DeleteStudentCommand -> Model : getPersonByIdentity(i) +activate Model + +Model --> DeleteStudentCommand : p +deactivate Model -DeleteCommand -> Model : deletePerson(1) +DeleteStudentCommand -> Model : deletePerson(p) activate Model -Model --> DeleteCommand +Model --> DeleteStudentCommand deactivate Model create CommandResult -DeleteCommand -> CommandResult +DeleteStudentCommand -> CommandResult activate CommandResult -CommandResult --> DeleteCommand +CommandResult --> DeleteStudentCommand deactivate CommandResult -DeleteCommand --> LogicManager : r -deactivate DeleteCommand +DeleteStudentCommand --> LogicManager : r +deactivate DeleteStudentCommand [<--LogicManager deactivate LogicManager diff --git a/docs/diagrams/LogicClassDiagram.puml b/docs/diagrams/LogicClassDiagram.puml index 58b4f602ce6..be6cd1e9ace 100644 --- a/docs/diagrams/LogicClassDiagram.puml +++ b/docs/diagrams/LogicClassDiagram.puml @@ -39,7 +39,7 @@ LogicManager --> Storage Storage --[hidden] Model Command .[hidden]up.> Storage Command .right.> Model -note right of XYZCommand: XYZCommand = AddCommand, \nFindCommand, etc +note right of XYZCommand: XYZCommand = AddStudentCommand, \nSearchSessionCommand, etc Logic ..> CommandResult LogicManager .down.> CommandResult diff --git a/docs/diagrams/ModelClassDiagram.puml b/docs/diagrams/ModelClassDiagram.puml index 0de5673070d..5bf387096a8 100644 --- a/docs/diagrams/ModelClassDiagram.puml +++ b/docs/diagrams/ModelClassDiagram.puml @@ -1,54 +1,71 @@ @startuml !include style.puml + skinparam arrowThickness 1.1 skinparam arrowColor MODEL_COLOR skinparam classBackgroundColor MODEL_COLOR +skinparam Padding 4 + +Package Model as ModelPackage <
examples:
* containsWordIgnoreCase("ABc def", "abc") == true
- * containsWordIgnoreCase("ABc def", "DEF") == true
- * containsWordIgnoreCase("ABc def", "AB") == false //not a full word match
+ * containsWordIgnoreCase("ABc def", "DE") == true // partial match allowed
+ * containsWordIgnoreCase("ABc def", "ABcd") == false
*
* @param sentence cannot be null
- * @param word cannot be null, cannot be empty, must be a single word
+ * @param keyword cannot be null, cannot be empty, must be a single word
*/
- public static boolean containsWordIgnoreCase(String sentence, String word) {
+ public static boolean containsWordIgnoreCase(String sentence, String keyword) {
requireNonNull(sentence);
- requireNonNull(word);
+ requireNonNull(keyword);
- String preppedWord = word.trim();
- checkArgument(!preppedWord.isEmpty(), "Word parameter cannot be empty");
- checkArgument(preppedWord.split("\\s+").length == 1, "Word parameter should be a single word");
+ String preppedKeyword = keyword.trim();
+ checkArgument(!preppedKeyword.isEmpty(), "Keyword parameter cannot be empty");
+ checkArgument(
+ preppedKeyword.split("\\s+").length == 1,
+ "Keyword parameter should be a single word");
- String preppedSentence = sentence;
- String[] wordsInPreppedSentence = preppedSentence.split("\\s+");
+ String[] wordsInSentence = sentence.split("\\s+");
- return Arrays.stream(wordsInPreppedSentence)
- .anyMatch(preppedWord::equalsIgnoreCase);
+ return Arrays.stream(wordsInSentence)
+ .anyMatch(w -> w.toLowerCase().contains(preppedKeyword.toLowerCase()));
}
/**
@@ -49,13 +50,13 @@ public static String getDetails(Throwable t) {
}
/**
- * Returns true if {@code s} represents a non-zero unsigned integer
+ * Returns true if {@code s} represents a non-zero unsigned integer, that can be parsed into an integer.
* e.g. 1, 2, 3, ..., {@code Integer.MAX_VALUE} * Will return false for any other non-null string input * e.g. empty string, "-1", "0", "+1", and " 2 " (untrimmed), "3 0" (contains whitespace), "1 a" (contains letters) * @throws NullPointerException if {@code s} is null. */ - public static boolean isNonZeroUnsignedInteger(String s) { + public static boolean isParsableNonZeroUnsignedInteger(String s) { requireNonNull(s); try { @@ -65,4 +66,13 @@ public static boolean isNonZeroUnsignedInteger(String s) { return false; } } + + /** + * Returns true if {@code s} represents a non-zero unsigned integer. + */ + public static boolean isNonZeroUnsignedInteger(String s) { + requireNonNull(s); + return s.matches("[1-9]\\d*"); + } + } diff --git a/src/main/java/seedu/address/commons/util/ToStringBuilder.java b/src/main/java/tutorly/commons/util/ToStringBuilder.java similarity index 97% rename from src/main/java/seedu/address/commons/util/ToStringBuilder.java rename to src/main/java/tutorly/commons/util/ToStringBuilder.java index d979b926734..f6745b78d9e 100644 --- a/src/main/java/seedu/address/commons/util/ToStringBuilder.java +++ b/src/main/java/tutorly/commons/util/ToStringBuilder.java @@ -1,4 +1,4 @@ -package seedu.address.commons.util; +package tutorly.commons.util; /** * Builds a string representation of an object that is suitable as the return value of {@link Object#toString()}. diff --git a/src/main/java/tutorly/logic/Logic.java b/src/main/java/tutorly/logic/Logic.java new file mode 100644 index 00000000000..cc6806e42e7 --- /dev/null +++ b/src/main/java/tutorly/logic/Logic.java @@ -0,0 +1,74 @@ +package tutorly.logic; + +import java.nio.file.Path; + +import javafx.collections.ObservableList; +import tutorly.commons.core.GuiSettings; +import tutorly.logic.commands.Command; +import tutorly.logic.commands.CommandResult; +import tutorly.logic.commands.exceptions.CommandException; +import tutorly.logic.parser.exceptions.ParseException; +import tutorly.model.Model; +import tutorly.model.ReadOnlyAddressBook; +import tutorly.model.attendancerecord.AttendanceRecord; +import tutorly.model.person.Person; +import tutorly.model.session.Session; + +/** + * API of the Logic component + */ +public interface Logic { + /** + * Executes the command and returns the result. + * @param commandText The command as entered by the user. + * @return the result of the command execution. + * @throws CommandException If an error occurs during command execution. + * @throws ParseException If an error occurs during parsing. + */ + CommandResult execute(String commandText) throws CommandException, ParseException; + + /** + * Executes the command and returns the result. + * @param command The command to be executed. + * @return the result of the command execution. + * @throws CommandException If an error occurs during command execution. + */ + CommandResult execute(Command command) throws CommandException; + + /** + * Returns the AddressBook. + * + * @see Model#getAddressBook() + */ + ReadOnlyAddressBook getAddressBook(); + + /** Returns an unmodifiable view of the list of persons */ + ObservableList
+ * Supports a minimal set of list operations.
+ */
+public class UniqueList