diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md
index 616c198d404..da6a8852304 100644
--- a/docs/DeveloperGuide.md
+++ b/docs/DeveloperGuide.md
@@ -58,7 +58,7 @@ The *Sequence Diagram* below shows how the components interact with each other f
Each of the four main components (also shown in the diagram above),
* defines its *API* in an `interface` with the same name as the Component.
-* implements its functionality using a concrete `{Component Name}Manager` class (which follows the corresponding API `interface` mentioned in the previous point.
+* implements its functionality using a concrete `{Component Name}Manager` class (which follows the corresponding API `interface` mentioned in the previous point).
For example, the `Logic` component defines its API in the `Logic.java` interface and implements its functionality using the `LogicManager.java` class which follows the `Logic` interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent outside component's being coupled to the implementation of a component), as illustrated in the (partial) class diagram below.
@@ -159,87 +159,6 @@ 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.
-
-![UndoRedoState0](images/UndoRedoState0.png)
-
-Step 2. The user executes `delete 5` command to delete the 5th student 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.
-
-![UndoRedoState1](images/UndoRedoState1.png)
-
-Step 3. The user executes `add n/David …` to add a new student. The `add` command also calls `Model#commitAddressBook()`, causing another modified address book state to be saved into the `addressBookStateList`.
-
-![UndoRedoState2](images/UndoRedoState2.png)
-
-
: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`.
-
-
-
-Step 4. The user now decides that adding the student 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.
-
-![UndoRedoState3](images/UndoRedoState3.png)
-
-: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:
-
-![UndoSequenceDiagram](images/UndoSequenceDiagram-Logic.png)
-
-: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.
-
-
-
-Similarly, how an undo operation goes through the `Model` component is shown below:
-
-![UndoSequenceDiagram](images/UndoSequenceDiagram-Model.png)
-
-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.
-
-: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.
-
-
-
-Step 5. The user then decides to execute the command `liststudents`. Commands that do not modify the address book, such as `liststudents`, will usually not call `Model#commitAddressBook()`, `Model#undoAddressBook()` or `Model#redoAddressBook()`. Thus, the `addressBookStateList` remains unchanged.
-
-![UndoRedoState4](images/UndoRedoState4.png)
-
-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.
-
-![UndoRedoState5](images/UndoRedoState5.png)
-
-The following activity diagram summarizes what happens when a user executes a new command:
-
-
-
-#### Design considerations:
-
-**Aspect: How undo & redo executes:**
-
-* **Alternative 1 (current choice):** Saves the entire address book.
- * Pros: Easy to implement.
- * Cons: May have performance issues in terms of memory usage.
-
-* **Alternative 2:** Individual command knows how to undo/redo by
- itself.
- * Pros: Will use less memory (e.g. for `delete`, just save the student being deleted).
- * Cons: We must ensure that the implementation of each individual command are correct.
### Consultation Management
@@ -255,9 +174,9 @@ The consultation feature comprises these key components:
* `AddConsultCommand`: Handles adding new consultations
* `AddConsultCommandParser`: Parses user input for consultation commands
-[//]: # (The class diagram below shows the structure of the consultation feature:)
+The class diagram below shows the structure of the consultation feature:
-[//]: # ()
+
#### Implementation
@@ -296,6 +215,13 @@ consult.removeStudent(student);
// Getting immutable student list
List students = consult.getStudents(); // Returns unmodifiable list
```
+The sequence diagram below shows how the `addStudent(student)` method is performed in the `Consultation` class.
+
+
+
+The command first checks if the student is already in the consultation. If the student was already in the consultation, and exception is thrown and the student is not added.
+
+However, if the student was not previously in the consultation, the student is now added to the list of students in the consultation.
**3. Command Processing**
@@ -308,10 +234,22 @@ The system supports these consultation management commands:
Command examples:
```
addconsult d/2024-10-20 t/14:00
-addtoconsult 1 n/John Doe n/Harry Ng
+addtoconsult 1 n/John Doe i/3
deleteconsult 1
removefromconsult 1 n/John Doe
```
+The sequence diagram below shows how the command `addtoconsult 1 n/John Doe i/3` is executed.
+
+
+
+The commands for Consultations are executed using the `Logic` component:
+
+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., `AddToConsultCommandParser`) and uses it to parse the command.
+1. This results in a `Command` object (in this case, the `AddToConsultCommand`) which is executed by the `LogicManager`.
+1. The command can communicate with the `Model` when it is executed (e.g. to add a student to the consultation).
+ 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`.
+
**Aspect 1: Date and Time Representation**
@@ -333,6 +271,134 @@ removefromconsult 1 n/John Doe
* Pros: Simpler thread-safety
* Cons: Higher memory usage for modifications
+### Lesson Management
+
+The lesson management feature enables TAs to schedule and manage lessons with students. This section describes the implementation details of the lesson system.
+
+#### Architecture
+
+The lesson feature comprises these key components:
+
+* `Lesson`: Core class representing a lessons
+* `Date`: Represents and validates lesson dates
+* `Time`: Represents and validates lesson times
+* `StudentLessonInfo`: Represents student info used for lessons. This includes the student's attendance and participation score for a lesson.
+* `AddLessonCommand`: Handles adding new lessons
+* `AddLessonCommandParser`: Parses user input for `AddLessonCommand`
+
+The class diagram below shows the structure of the lesson feature:
+
+
+
+#### Implementation
+
+The lesson management system is implemented through several key mechanisms:
+
+**1. Date and Time Validation**
+
+The system enforces strict validation for lesson scheduling:
+* Dates must be in `YYYY-MM-DD` format and represent valid calendar dates
+* Times must be in 24-hour `HH:mm` format
+* Both use Java's built-in `LocalDate` and `LocalTime` for validation
+
+Example:
+```java
+Date date = new Date("2024-10-20"); // Valid
+Time time = new Time("14:00"); // Valid
+Date invalidDate = new Date("2024-13-45"); // Throws IllegalArgumentException
+```
+
+**2. Lesson Management**
+
+The `Lesson` class manages:
+* Immutable date and time properties
+* Thread-safe student information list management
+* Equality based on date, time, and student information
+
+Core operations:
+```java
+// Creating a lesson
+Lesson lesson = new Lesson(date, time, studentLessonInfoList);
+
+// Adding/removing students
+lesson.addStudent(student);
+lesson.removeStudent(student);
+
+// Setting attendance
+lesson.setAttendance(student, attendance);
+
+// Setting pariticipation score
+lesson.setParticipation(student, participationScore);
+
+// Getting immutable student info list, returns unmodifiable list
+List studentInfoList = lesson.getStudentLessonInfoList();
+```
+
+**3. Command Processing**
+
+The system supports these lesson management commands:
+- `addlesson`: Creates new lesson
+- `addtolesson`: Adds students to existing lesson
+- `deletelesson`: Removes lesson
+- `listlessons`: Lists all lessons
+- `removefromlesson`: Removes students from lesson
+- `marka`: Marks the attendance of students in a lesson (can mark as present or absent)
+- `markp`: Sets the participation score of students in a lesson
+
+Command examples:
+```
+addlesson d/2024-10-20 t/14:00
+addtolesson 1 n/John Doe i/3
+deletelesson 1
+removefromlesson 1 n/John Doe
+markp 1 n/John Doe pt/25
+marka 1 n/John Doe n/Jane Doe a/y
+```
+The sequence diagram below shows how the command `addtolesson 1 n/John Doe i/3` is executed.
+
+
+
+The commands for Lessons are executed using the `Logic` component, making it similar to the sequence diagram in the consultation section above.
+
+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., `AddToLessonCommandParser`) and uses it to parse the command.
+1. This results in a `Command` object (in this case, the `AddToLessonCommand`) which is executed by the `LogicManager`.
+1. The command can communicate with the `Model` when it is executed (e.g. to add a student to the lesson).
+ 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`.
+
+
+The next sequence diagram shows how the `MarkLessonAttendanceCommand` is executed to update the attendance of students in a lesson.
+
+
+
+The flow of the program when `MarkLessonAttendanceCommand.execute` is called is as follows:
+
+1. When the execute method is called, the command first gets the `targetLesson` from the model.
+2. The command then creates a new `Lesson` object (called `newLesson`) from the `targetLesson`. This creates a copy of the current `targetLesson`.
+3. Now, for each student, the command sets the student's attendance using the `setAttendance` method in the `Lesson` class.
+4. Finally, the command replaces the `targetLesson` in the model with the `newLesson`.
+
+
+**Aspect 1: Date and Time Representation**
+
+* **Alternative 1 (current choice)**: Separate `Date` and `Time` classes
+ * Pros: Clear separation of concerns, focused validation
+ * Cons: Two objects to manage instead of one
+
+* **Alternative 2**: Combined `DateTime` class
+ * Pros: Unified handling of temporal data
+ * Cons: More complex validation, reduced modularity
+
+**Aspect 2: StudentInfo List Management**
+
+* **Alternative 1 (current choice)**: Immutable view with mutable internal list
+ * Pros: Thread-safe external access, flexible internal updates
+ * Cons: Complex implementation
+
+* **Alternative 2**: Fully immutable list
+ * Pros: Simpler thread-safety
+ * Cons: Higher memory usage for modifications
+
### Data Import / Export Feature
@@ -400,6 +466,89 @@ Date,Time,Students
--------------------------------------------------------------------------------------------------------------------
+### \[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.
+
+![UndoRedoState0](images/UndoRedoState0.png)
+
+Step 2. The user executes `delete 5` command to delete the 5th student 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.
+
+![UndoRedoState1](images/UndoRedoState1.png)
+
+Step 3. The user executes `add n/David …` to add a new student. The `add` command also calls `Model#commitAddressBook()`, causing another modified address book state to be saved into the `addressBookStateList`.
+
+![UndoRedoState2](images/UndoRedoState2.png)
+
+: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`.
+
+
+
+Step 4. The user now decides that adding the student 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.
+
+![UndoRedoState3](images/UndoRedoState3.png)
+
+: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:
+
+![UndoSequenceDiagram](images/UndoSequenceDiagram-Logic.png)
+
+: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.
+
+
+
+Similarly, how an undo operation goes through the `Model` component is shown below:
+
+![UndoSequenceDiagram](images/UndoSequenceDiagram-Model.png)
+
+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.
+
+: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.
+
+
+
+Step 5. The user then decides to execute the command `liststudents`. Commands that do not modify the address book, such as `liststudents`, will usually not call `Model#commitAddressBook()`, `Model#undoAddressBook()` or `Model#redoAddressBook()`. Thus, the `addressBookStateList` remains unchanged.
+
+![UndoRedoState4](images/UndoRedoState4.png)
+
+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.
+
+![UndoRedoState5](images/UndoRedoState5.png)
+
+The following activity diagram summarizes what happens when a user executes a new command:
+
+
+
+#### Design considerations:
+
+**Aspect: How undo & redo executes:**
+
+* **Alternative 1 (current choice):** Saves the entire address book.
+ * Pros: Easy to implement.
+ * Cons: May have performance issues in terms of memory usage.
+
+* **Alternative 2:** Individual command knows how to undo/redo by
+ itself.
+ * Pros: Will use less memory (e.g. for `delete`, just save the student being deleted).
+ * Cons: We must ensure that the implementation of each individual command are correct.
+
+
## **Documentation, logging, testing, configuration, dev-ops**
* [Documentation guide](Documentation.md)
diff --git a/docs/diagrams/Consults/ConsultCommands.puml b/docs/diagrams/Consults/ConsultCommands.puml
new file mode 100644
index 00000000000..3902b1c63db
--- /dev/null
+++ b/docs/diagrams/Consults/ConsultCommands.puml
@@ -0,0 +1,45 @@
+@startuml
+
+!include ../style.puml
+
+skinparam arrowThickness 1.1
+skinparam arrowColor LOGIC_COLOR_T4
+skinparam classBackgroundColor LOGIC_COLOR
+
+title Add Consult Command and Parser UML Diagram
+package Logic {
+
+ package Commands {
+ Class "{abstract}\nCommand" as Command
+ Class AddConsultCommand
+ Class CommandResult
+ }
+
+ package "Parser Classes" {
+ Class AddConsultCommandParser
+ }
+}
+
+package Model {
+ Class Consultation
+ Class Student
+ Class Date
+ Class Time
+}
+
+' Command relationships
+Command <|-- AddConsultCommand
+Command ..> CommandResult : creates >
+
+' Parser relationships
+AddConsultCommandParser ..> AddConsultCommand : creates >
+
+' Model relationships
+Consultation *-- "*" Student
+Consultation *-- "1" Date
+Consultation *-- "1" Time
+
+' Group visibility for logical structure
+CommandResult ..> Consultation : creates >
+
+@enduml
diff --git a/docs/diagrams/Consults/SequenceDiagramAddToConsultCommand.puml b/docs/diagrams/Consults/SequenceDiagramAddToConsultCommand.puml
new file mode 100644
index 00000000000..f3654f70fbe
--- /dev/null
+++ b/docs/diagrams/Consults/SequenceDiagramAddToConsultCommand.puml
@@ -0,0 +1,84 @@
+
+@startuml
+!include ../style.puml
+skinparam ArrowFontStyle plain
+
+title AddToConsultCommand Sequence Diagram
+
+box Logic
+participant ":LogicManager" as LogicManager LOGIC_COLOR
+participant ":AddressBookParser" as addressBookParser LOGIC_COLOR_T3
+participant ":AddToConsultCommandParser" as AddToConsultCommandParser LOGIC_COLOR_T2
+participant ":AddToConsultCommand" as AddToConsultCommand LOGIC_COLOR_T1
+participant ":CommandResult" as CommandResult LOGIC_COLOR
+end box
+
+box Model MODEL_COLOR_T1
+Participant ":Model" as model MODEL_COLOR
+end box
+
+-[UI_COLOR]> LogicManager : execute("addtoconsult 1 n/John Doe i/3")
+activate LogicManager LOGIC_COLOR
+
+'Logic manager calls AddressBookParser and passes the command
+LogicManager -[LOGIC_COLOR]> addressBookParser : parseCommand("addtoconsult 1 n/John Doe i/3")
+activate addressBookParser LOGIC_COLOR_T3
+
+'AddressBookParser creates an instance of the parser
+create AddToConsultCommandParser
+addressBookParser -[LOGIC_COLOR_T3]> AddToConsultCommandParser :
+activate AddToConsultCommandParser LOGIC_COLOR_T2
+
+AddToConsultCommandParser --[LOGIC_COLOR_T2]> addressBookParser
+deactivate AddToConsultCommandParser
+
+' AddressBookParser calls the parse command
+addressBookParser -[LOGIC_COLOR_T3]> AddToConsultCommandParser : parse("1 n/John Doe i/3")
+activate AddToConsultCommandParser LOGIC_COLOR_T2
+
+'Within the parse command, the parser creates an instance of the command
+create AddToConsultCommand
+AddToConsultCommandParser --[LOGIC_COLOR_T2]> AddToConsultCommand :
+activate AddToConsultCommand LOGIC_COLOR_T1
+
+AddToConsultCommand --[LOGIC_COLOR]> AddToConsultCommandParser
+deactivate AddToConsultCommand LOGIC_COLOR_T1
+
+'parser returns the command to the AddressBookParser
+AddToConsultCommandParser --[LOGIC_COLOR_T2]> addressBookParser : AddToConsultCommand
+deactivate AddToConsultCommandParser
+
+AddToConsultCommandParser --[hidden]> addressBookParser : AddToConsultCommand
+destroy AddToConsultCommandParser
+
+addressBookParser --[LOGIC_COLOR_T3]> LogicManager : AddToConsultCommand
+deactivate addressBookParser
+
+'LogicManager calls command.execute
+LogicManager -[LOGIC_COLOR]> AddToConsultCommand : execute(model)
+activate AddToConsultCommand LOGIC_COLOR_T1
+
+'get filteredConsultationList
+AddToConsultCommand -[LOGIC_COLOR]> model : addStudent(student)
+activate model MODEL_COLOR
+
+
+model -[MODEL_COLOR]-> AddToConsultCommand
+deactivate model
+
+create CommandResult
+AddToConsultCommand --[LOGIC_COLOR_T2]> CommandResult
+activate CommandResult LOGIC_COLOR
+CommandResult --[LOGIC_COLOR]> AddToConsultCommand
+deactivate CommandResult
+
+
+'After adding students, return new consultation
+AddToConsultCommand --[LOGIC_COLOR]> LogicManager : CommandResult
+deactivate AddToConsultCommand LOGIC_COLOR_T1
+AddToConsultCommand --[hidden]> LogicManager : CommandResult
+destroy AddToConsultCommand
+
+[<-[UI_COLOR]-LogicManager : CommandResult
+
+@enduml
diff --git a/docs/diagrams/Consults/addStudent_for_consult.puml b/docs/diagrams/Consults/addStudent_for_consult.puml
new file mode 100644
index 00000000000..f9f7e25caf9
--- /dev/null
+++ b/docs/diagrams/Consults/addStudent_for_consult.puml
@@ -0,0 +1,38 @@
+@startuml
+!include ../style.puml
+skinparam ArrowFontStyle plain
+
+title addStudent Method Sequence Diagram
+
+box Logic
+participant ":AddToConsultCommand" as client LOGIC_COLOR
+end box
+
+box Model
+participant ":Consultation" as consultation MODEL_COLOR
+end box
+
+
+
+client -> consultation : addStudent(student)
+activate consultation
+
+ consultation -> consultation : hasStudent(student)
+ activate consultation
+
+ consultation -> consultation :
+ deactivate consultation
+
+alt student already in consult
+
+ consultation -> client : nothing is added, exception thrown
+
+else student not in consult
+
+ consultation -> client : student added to consult successfully
+
+end alt
+
+deactivate consultation
+
+@enduml
diff --git a/docs/diagrams/Lessons/SequenceDiagramAddToLessonCommand.puml b/docs/diagrams/Lessons/SequenceDiagramAddToLessonCommand.puml
index f3d4577653e..a7ec912c37d 100644
--- a/docs/diagrams/Lessons/SequenceDiagramAddToLessonCommand.puml
+++ b/docs/diagrams/Lessons/SequenceDiagramAddToLessonCommand.puml
@@ -5,10 +5,11 @@ skinparam ArrowFontStyle plain
title AddToLessonCommand Sequence Diagram
box Logic
-Participant ":LogicManager" as LogicManager LOGIC_COLOR
-Participant ":AddressBookParser" as addressBookParser LOGIC_COLOR_T3
-Participant ":AddToLessonCommandParser" as AddToLessonCommandParser LOGIC_COLOR_T2
-Participant ":AddToLessonCommand" as AddToLessonCommand LOGIC_COLOR_T1
+participant ":LogicManager" as LogicManager LOGIC_COLOR
+participant ":AddressBookParser" as addressBookParser LOGIC_COLOR_T3
+participant ":AddToLessonCommandParser" as AddToLessonCommandParser LOGIC_COLOR_T2
+participant ":AddToLessonCommand" as AddToLessonCommand LOGIC_COLOR_T1
+participant ":CommandResult" as CommandResult LOGIC_COLOR
end box
box Model MODEL_COLOR_T1
@@ -24,7 +25,7 @@ activate addressBookParser LOGIC_COLOR_T3
'AddressBookParser creates an instance of the parser
create AddToLessonCommandParser
-addressBookParser -[LOGIC_COLOR_T3]> AddToLessonCommandParser : AddToLessonCommandParser(arguments)
+addressBookParser -[LOGIC_COLOR_T3]> AddToLessonCommandParser
activate AddToLessonCommandParser LOGIC_COLOR_T2
AddToLessonCommandParser --[LOGIC_COLOR_T2]> addressBookParser
@@ -36,7 +37,7 @@ activate AddToLessonCommandParser LOGIC_COLOR_T2
'Within the parse command, the parser creates an instance of the command
create AddToLessonCommand
-AddToLessonCommandParser --[LOGIC_COLOR_T2]> AddToLessonCommand : AddToLessonCommand(index, studentNames, indices)
+AddToLessonCommandParser --[LOGIC_COLOR_T2]> AddToLessonCommand
activate AddToLessonCommand LOGIC_COLOR_T1
AddToLessonCommand --[LOGIC_COLOR]> AddToLessonCommandParser
@@ -56,20 +57,19 @@ deactivate addressBookParser
LogicManager -[LOGIC_COLOR]> AddToLessonCommand : execute(model)
activate AddToLessonCommand LOGIC_COLOR_T1
-'get filteredLessonList
-AddToLessonCommand -[LOGIC_COLOR]> model : getFilteredLessonList()
-activate model MODEL_COLOR
-
-model -[MODEL_COLOR]-> AddToLessonCommand
-deactivate model
-
'get filteredStudentList
-AddToLessonCommand -[LOGIC_COLOR]> model : filteredStudentList()
+AddToLessonCommand -[LOGIC_COLOR]> model : addStudent
activate model MODEL_COLOR
model -[MODEL_COLOR]-> AddToLessonCommand
deactivate model
+create CommandResult
+AddToLessonCommand --[LOGIC_COLOR_T2]> CommandResult
+activate CommandResult LOGIC_COLOR
+CommandResult --[LOGIC_COLOR]> AddToLessonCommand
+deactivate CommandResult
+
'After adding students, return new lesson
AddToLessonCommand --[LOGIC_COLOR]> LogicManager : CommandResult
deactivate AddToLessonCommand LOGIC_COLOR_T1
diff --git a/docs/images/Consultation/ConsultCommands.png b/docs/images/Consultation/ConsultCommands.png
new file mode 100644
index 00000000000..33c2b8aec6e
Binary files /dev/null and b/docs/images/Consultation/ConsultCommands.png differ
diff --git a/docs/images/Consultation/SequenceDiagramAddToConsultCommand.png b/docs/images/Consultation/SequenceDiagramAddToConsultCommand.png
new file mode 100644
index 00000000000..c89e4979205
Binary files /dev/null and b/docs/images/Consultation/SequenceDiagramAddToConsultCommand.png differ
diff --git a/docs/images/Consultation/addStudent_for_consult.png b/docs/images/Consultation/addStudent_for_consult.png
new file mode 100644
index 00000000000..c598980ca38
Binary files /dev/null and b/docs/images/Consultation/addStudent_for_consult.png differ
diff --git a/docs/images/Lessons/LessonsAndRelatedCommands.png b/docs/images/Lessons/LessonsAndRelatedCommands.png
new file mode 100644
index 00000000000..c17d9fe80f1
Binary files /dev/null and b/docs/images/Lessons/LessonsAndRelatedCommands.png differ
diff --git a/docs/images/Lessons/MarkAttendanceCommandSequenceDiagram.png b/docs/images/Lessons/MarkAttendanceCommandSequenceDiagram.png
new file mode 100644
index 00000000000..e39678118ed
Binary files /dev/null and b/docs/images/Lessons/MarkAttendanceCommandSequenceDiagram.png differ
diff --git a/docs/images/Lessons/SequenceDiagramAddToLessonCommand.png b/docs/images/Lessons/SequenceDiagramAddToLessonCommand.png
new file mode 100644
index 00000000000..6e89eb402cb
Binary files /dev/null and b/docs/images/Lessons/SequenceDiagramAddToLessonCommand.png differ
diff --git a/docs/images/helpMessage.png b/docs/images/helpMessage.png
index bff2caf2f02..e605da93992 100644
Binary files a/docs/images/helpMessage.png and b/docs/images/helpMessage.png differ