From 680d6e097f3fd201a0025382daa9ec0b90891926 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Fri, 10 Nov 2023 23:12:54 +0800 Subject: [PATCH 01/31] Add feedback from Zann --- docs/DeveloperGuide.md | 108 +++++++++--------- .../diagrams/ArchitectureSequenceDiagram.puml | 2 +- docs/diagrams/ParserClasses.puml | 9 +- docs/diagrams/ProfBookClassDiagram.puml | 14 +-- 4 files changed, 68 insertions(+), 65 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 0e434622338..8fa0ff9c8bb 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -11,7 +11,7 @@ pageNav: 3 ## **Introduction** -ProfBook is a tool tailored to helping specifically CS2103T professors and Teaching Assistants(TA) in manage +ProfBook is a tool tailored to helping specifically CS2103T professors and Teaching Assistants(TA) in managing their tutorial slots and groups. As our target users are technophile, we designed and optimised a CLI-based application specifically for them. It is currently optimised for CS2103T professors and TA with plans to expand to other Computer Science Modules. Please refer to our [_User Guide_](https://ay2324s1-cs2103t-w15-2.github.io/tp/UserGuide.html) for more @@ -45,7 +45,7 @@ Refer to the guide [_Setting up and getting started_](SettingUp.md). ## **Design** -### Before you read +### Before you begin reading @@ -131,12 +131,11 @@ The `UI` component, ### Logic component -**API -** : [`Logic.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/src/main/java/seedu/address/logic/Logic.java) +**API** : [`Logic.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/src/main/java/seedu/address/logic/Logic.java) Here's a (partial) class diagram of the `Logic` component: - + The sequence diagram below illustrates the interactions within the `Logic` component, taking `execute("rmt 1")` API call as an example. @@ -169,8 +168,7 @@ How the parsing works: ### Model component -**API -** : [`Model.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/src/main/java/seedu/address/model/Model.java) +**API** : [`Model.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/src/main/java/seedu/address/model/Model.java) @@ -199,21 +197,20 @@ The diagram above shows how the folder structure is implemented in ProfBook, * We also created a wrapper class (e.g. `ChildrenAndTaskListManager`) for classes that require both of those aforementioned functionalities (e.g, `Group` and potentially in the future `TutorialSlot`) -**API -** : [`TaskListManager.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/model/profbook/TaskListManager.java) +**API** : [`TaskListManager.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/model/profbook/TaskListManager.java) How the `Task` component work: -* As mentioned earlier, `TaskListManager` encapsulates the logic required to maintain a TaskList, these logic is +* As mentioned earlier, `TaskListManager` encapsulates the logic required to maintain a TaskList, this logic is utilised heavily in the ProfBook component. * All tasks extend from the abstract class `Task`, we did this so for extensibility. So in the future, should we decide - to - implement a new type of task, all we have to do is extend from `Task`. + to implement a new type of task, all we have to do is extend from `Task`. The sequence diagram below illustrates the interactions within the `Model` component, taking an execution of a -`CreateTodoClass` as example. +`CreateTodoCommand` as example. As the behaviour of `CreateTodoCommand` is rather dynamic, in our example, +we shall be narrowing our scope to adding a todo tasks to a specified group, g. @@ -224,22 +221,21 @@ How the `Model` component works: * In this case, a `TaskOperation` object is created. This object would store all the necessary information to make changes directly on the correct state. * The command object calls the required method in the `TaskOperation` object which results in the `TaskOperation` - object adding the Todo task to the group -* Our `TaskOperation` and `ChildOperation` classes follow + object adding the Todo task to the group. +* Our `TaskOperation` and `ChildOperation` classes follow. the [facade pattern](https://nus-cs2103-ay2324s1.github.io/website/se-book-adapted/chapters/designPatterns.html#facade-pattern) **Note:** For ChildrenOperation, ModelManager provides more specific static factory methods (e.g., GroupChildOperation, RootChildOperation) to generate the `ChildOperation` object. It is implemented this way so that ModelManager is able -to check that the Operation required matches with the intended effect of the Command object's Execution +to check that the Operation required matches with the intended effect of the Command object's Execution. ### Storage component -**API -** : [`ProfBookStorageManager.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/storage/ProfBookStorageManager.java) +**API** : [`ProfBookStorageManager.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/storage/ProfBookStorageManager.java) @@ -269,7 +265,7 @@ Due to the nature of the application that we aim to make, designing a robust fol is crucial to our success. We strive to design a structure that is generic enough to be extended while also being able to capture unique functionality of the different parties at play. -In our current hierarchy, `Root` -> `Group` -> `Student`, `Student` and `Group` are required to managed tasks +In our current hierarchy, `Root` -> `Group` -> `Student`, `Student` and `Group` are required to manage tasks whereas `Root` and `Group` are required to manage children. The `Model` component briefly mentioned this implementation, but I will delve into it more comprehensively. @@ -280,12 +276,16 @@ Manager functionality, we could just extend from said Manager thus reducing on r Java, classes are not able to extend from multiple classes. To remedy this, we created a wrapper class, `ChildrenAndTaskListManager`. -It is important to note that `ChildrenManager` is a generic class that accepts classes that implements -the `IChildElement` interface. This was done to reduce repeated code while introducing a degree of polymorphism. - In our implementation, only the parents have reference to the child. This reference is stored by using a `Map` and `Map` instance. + + +**Note:** It is important to note that `ChildrenManager` is a generic class that accepts classes that implements +the `IChildElement` interface. This was done to reduce repeated code while introducing a degree of polymorphism. + + + To further illustrate our folder structure, we have prepared this diagram @@ -324,8 +324,8 @@ The following methods of `ModelManager` and `GroupChildOperation` are used: 1. `ModelManager::groupChildOperation` - To generate a facade class specific to the current group, it also checks for the validity and presence of the specified group. -2. `ModelManager::hasStudentWithId` - To check if the new student id is unique -3. `GroupChildOperation::addChild` - To add the current student into the group +2. `ModelManager::hasStudentWithId` - To check if the new student id is unique. +3. `GroupChildOperation::addChild` - To add the current student into the group. Given below is an example usage scenario on how an existing user can create a student. @@ -337,8 +337,8 @@ Given below is an example usage scenario on how an existing user can create a st 2. Suppose the user is still in the root directory and wants to add a new student to group 1, the user would execute the following command: `touch ~/grp-001/2000Y --name Bob --email bobby@example.com --phone 92929292 --address blk 258 Toa Payoh`. - Do note that the only required fields are `--name` -3. The parser would retrieve all the relevant information from the input and encapsulates it in a `CreateStudentCommand` + Do note that the only required fields are `--name`. +3. The parser would retrieve all the relevant information from the input and encapsulates it in a `CreateStudentCommand`. 4. This command would first do these checks: * checks if the specified path is a valid student path. This is done via the `Path::isStudentDirectory` method * checks if adding the student would result in a duplicate within whole of ProfBook, ie if the student id is @@ -364,7 +364,7 @@ Below is an activity diagram showing the general activity of the add student com #### Design Consideration -**Aspect: Types of fields ** +**Aspect: Types of fields** * **Alternative 1 (current implementation):** Fields can be required or optional. * Pros: Allows the user to create groups and students without complete information. @@ -372,7 +372,7 @@ Below is an activity diagram showing the general activity of the add student com * **Alternative 2**: Fields must be required. * Pros: Easier implementation, there is less need for checking optional field. * Cons: All information about a student/group must be readily present before creating it, which is not always the - case + case. ### Creating a task @@ -384,9 +384,9 @@ extensibility. It is important to note that currently, you can only add tasks to the information for these tasks are encapsulated withing their respective `Task` instance. -As the implementation for creating a Todo and Deadline task is very similar, I would be bringing you through +As the implementation for creating a `Todo` and `Deadline` task is very similar, I would be bringing you through the implementation that we found to be more confusing. I would be going through creating a Deadline task and adding it -to *all students in a group*. Illustration in the form of a sequence diagram for creating a Todo and adding a singular +to **all students in a group**. Illustration in the form of a sequence diagram for creating a Todo and adding a singular tasks can be found at the `Model` component. For more information you could reach out to us, we would be more than happy to help. @@ -412,10 +412,10 @@ Given below is an example usage scenario on how an existing user can add Deadlin 2. Suppose the user is still in the root directory and wants to add a deadline to all students in group1, the user would execute the following - command: `deadline ~/grp-001 --desc Assignment 1 --datetime 2023-12-12 23:59`. More information on the flags could be - fond in the User Guide. + command: `deadline ~/grp-001 --desc Assignment 1 --datetime 2023-12-12 23:59 --all allStu`. More information on the + flags could be fond in the User Guide. 3. The parser would retrieve all the relevant information from the input and encapsulates it in - a `CreateDeadlineCommand` + a `CreateDeadlineCommand`. 4. This command would first * check if the specified path is a valid and present Group path. This is done via `Path::isGroupDirectory` method. * check if all students in the group already has the task. This is done @@ -447,20 +447,20 @@ This is an activity diagram showing the general activity of the add deadline com **Aspect: Should groups have their own task list as well** * **Alternative 1 (current implementation):** Yes. - * Pros: Closely resembles the dynamics in real life - * Cons: Harder to implement, more confusing for users + * Pros: Closely resembles the dynamics in real life. + * Cons: Harder to implement, more confusing for users. * **Alternative 2**: No. - * Pros: Easier to implement - * Cons: Users may not be able to keep track of group related tasks + * Pros: Easier to implement. + * Cons: Users may not be able to keep track of group related tasks. **Aspect: how should we implement adding of bulk tasks** * **Alternative 1:** Add Tasks one by one to each student. - * Pros: Quick and easy to implement - * Cons: keeping track of group tasks is a hassle, any action done for one task must be done for all + * Pros: Quick and easy to implement. + * Cons: keeping track of group tasks is a hassle, any action done for one task must be done for all. * **Alternative 2**: Allow groups to have their own task lists. - * Pros: Quick and easy to implement - * Cons: Adding of student tasks must be done manually + * Pros: Quick and easy to implement. + * Cons: Adding of student tasks must be done manually. * **Alternative 3 (current implementation)**: Implement both of the aforementioned features. * Pros: Best of both worlds. * Cons: Harder to implement, user command is also more complex and bulky. @@ -483,8 +483,8 @@ The following methods of `ModelManager`, `Path` and `RootChildOperation` are use 1. `ModelManager::rootChildOperation` - To generate a facade class with logic specific to the current root. 2. `ModelManager::hasGroupWithId` - To check if editing results in a duplicate. 3. `RootChildOperation::editChild` - To edit the group with the values extracted from parser. -4. `Path::isGroupDirectory` - To check if the path leads to a group directory -5. `Path::isStudentDirectory` - To check if the path leads to a student directory +4. `Path::isGroupDirectory` - To check if the path leads to a group directory. +5. `Path::isStudentDirectory` - To check if the path leads to a student directory. Given below is an example usage scenario on how an existing user can edit the name of a group @@ -539,7 +539,7 @@ student's reference from its current group by removing its key-value pair from t Then to complete the move, the student is added to the target group by adding it into the target group's `Map` field. All of this operation is facilitated by the `GroupChildOperation` facade class. -Given below is an example usage scenario whereby a student is moved from group1 to group2 +Given below is an example usage scenario whereby a student is moved from group1 to group2. 1. When the user launches the application, existing information is read from the data file `profbook.json`. 2. Suppose the user is still in the root directory and wants to move student `1234Y` from `grp-001` to `grp-002`, the @@ -549,7 +549,7 @@ Given below is an example usage scenario whereby a student is moved from group1 5. Command would then add the student to the target group via the `GroupChildOperation::addChild` method. The old reference is removed via the `GroupChildOperation::deleteChild` method. 6. As uniqueness of student is validated before each student is added, there is no need to check for clashes when - executing + executing. // TODO maybe add a sequence diagram -------------------------------------------------------------------------------------------------------------------- @@ -617,12 +617,12 @@ plan to revamp our error message to be more descriptive and user friendly * has a need to manage a significant number of students * has a need to manage various tutorial groups * has to keep track of deadlines and assign tasks to groups as well as individual students -* prefer and is used to using cli and linux commands +* prefer and is used to using CLI and Linux commands * can type fast * prefers typing to mouse interactions -**Value proposition**: Keep track of tutorial groups and students deadlines and tasks efficiently with an interface that -will be faster than a typical mouse/GUI driven app +**Value proposition**: Keep track of tutorial groups and students' deadlines and tasks efficiently with an interface +that will be faster than a typical mouse/GUI driven app ### User stories @@ -980,7 +980,8 @@ otherwise) * 2c. No path specified - * 2c1. ProfBook creates Deadline under current directly, either for groups while at root or for students while in group. + * 2c1. ProfBook creates Deadline under current directly, either for groups while at root or for students while in + group. Use case ends. @@ -1128,7 +1129,7 @@ The project was classified as **challenging** due to: - **Hierarchical Structure:** Our application features a hierarchical structure, with ProfBook serving as the root entity. Under ProfBook, there are groups, and each group contains students. Managing this hierarchical structure added - complexity to the project. + a significant amount of complexity to the project. - **Diverse Classes:** Unlike AB3, our project needed to handle a more extensive range of classes, including Student, Group, and Task. This expansion added complexity as we had to provide functionality for student organization and task @@ -1141,7 +1142,8 @@ project phases: - **Design and Architecture:** This phase focused on designing the terminal-like user interface, defining terminal behavior, and integrating the hierarchical structure. Additionally, it involved accommodating and ensuring the smooth - interaction of multiple entity types within the application. + interaction of multiple entity types within the application. We found it especially difficult to find a class generic + enough to capture all the different behaviour of each directory in ProfBook while also making it extensible. - **Implementation and Coding:** The implementation phase was dedicated to building custom components and functionalities essential for realizing terminal behavior, hierarchical structure navigation, and handling diverse @@ -1159,8 +1161,8 @@ project phases: A notable aspect of our project was the efficient use of custom components, which contributed to a significant reduction in the overall effort. -- **Path Component:** We introduced the `Path` component, which includes subclasses for managing both **absolute** and * - *relative** paths. This component played a crucial role in managing navigation and executing dynamic commands within +- **Path Component:** We introduced the `Path` component, which includes subclasses for managing both **absolute** and +**relative** paths. This component played a crucial role in managing navigation and executing dynamic commands within our application. - **ChildrenManager Component:** The component was instrumental in representing the hierarchical structure in our diff --git a/docs/diagrams/ArchitectureSequenceDiagram.puml b/docs/diagrams/ArchitectureSequenceDiagram.puml index 48b6cc4333c..a9cf3974b50 100644 --- a/docs/diagrams/ArchitectureSequenceDiagram.puml +++ b/docs/diagrams/ArchitectureSequenceDiagram.puml @@ -11,7 +11,7 @@ Participant ":Storage" as storage STORAGE_COLOR user -[USER_COLOR]> ui : "delete 1" activate ui UI_COLOR -ui -[UI_COLOR]> logic : execute("delete 1") +ui -[UI_COLOR]> logic : execute("rm 0001Y") activate logic LOGIC_COLOR logic -[LOGIC_COLOR]> model : deletePerson(p) diff --git a/docs/diagrams/ParserClasses.puml b/docs/diagrams/ParserClasses.puml index 6d37c914038..3bc652d922e 100644 --- a/docs/diagrams/ParserClasses.puml +++ b/docs/diagrams/ParserClasses.puml @@ -9,21 +9,22 @@ Class XYZCommand package "Parser classes"{ Class "<>\nParser" as Parser -Class AddressBookParser +Class ProfBookParser Class XYZCommandParser Class CliSyntax Class ParserUtil Class ArgumentMultimap Class ArgumentTokenizer +class Option } Class HiddenOutside #FFFFFF -HiddenOutside ..> AddressBookParser +HiddenOutside ..> ProfBookParser -AddressBookParser .down.> XYZCommandParser: creates > +ProfBookParser .down.> XYZCommandParser: creates > XYZCommandParser ..> XYZCommand : creates > -AddressBookParser ..> Command : returns > +ProfBookParser ..> Command : returns > XYZCommandParser .up.|> Parser XYZCommandParser ..> ArgumentMultimap XYZCommandParser ..> ArgumentTokenizer diff --git a/docs/diagrams/ProfBookClassDiagram.puml b/docs/diagrams/ProfBookClassDiagram.puml index 024f3bdc190..c7dbda76fc0 100644 --- a/docs/diagrams/ProfBookClassDiagram.puml +++ b/docs/diagrams/ProfBookClassDiagram.puml @@ -49,15 +49,15 @@ ChildrenAndTaskListManager .up.|> IChildElement Student -up-|> TaskListManager Student .up.|> IChildElement -Group *--> Id -Student *--> Id +Group *--> "1" Id +Student *--> "1" Id -Group *--> Name -Student *--> Name +Group *--> "1" Name +Student *--> "1" Name -Student *--> Email -Student *--> Address -Student *--> Phone +Student *--> "0...1" Email +Student *--> "0...1" Address +Student *--> "0...1" Phone ChildrenAndTaskListManager .up.|> ITaskListManager ChildrenAndTaskListManager -right-> TaskListManager From d875a97222d17e8778203e9d68b9b94002d70d9a Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Fri, 10 Nov 2023 23:40:43 +0800 Subject: [PATCH 02/31] Split huge diagram into reference frames --- docs/DeveloperGuide.md | 22 ++++---- ...ml => DeleteTaskSequenceLogicDiagram.puml} | 45 ++-------------- .../DeleteTaskSequenceModelDiagram.puml | 53 +++++++++++++++++++ 3 files changed, 70 insertions(+), 50 deletions(-) rename docs/diagrams/{DeleteTaskSequenceDiagram.puml => DeleteTaskSequenceLogicDiagram.puml} (56%) create mode 100644 docs/diagrams/DeleteTaskSequenceModelDiagram.puml diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 8fa0ff9c8bb..fca9997cdb6 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -142,7 +142,9 @@ as an example. `rmt` is the command word for DeleteTaskCommand class. By executing the command `rmt 1`, tha task with index number 1 will be deleted. - + + + How the `Logic` component works: @@ -332,7 +334,7 @@ Given below is an example usage scenario on how an existing user can create a st 1. When the user launches the application, existing information is read from the data file `profbook.json`. The initial state would look something like this. - + 2. Suppose the user is still in the root directory and wants to add a new student to group 1, the user would execute the following @@ -350,12 +352,12 @@ Given below is an example usage scenario on how an existing user can create a st the path to the group is present and valid. The student is added through the `GroupChildOperation::addChild` method. 7. It should look something like this. - + This sequence diagram shows the general flow of the CreateStudentCommand, for more information on each specific component, do head over to their respective documentation. - + Below is an activity diagram showing the general activity of the add student command. @@ -408,7 +410,7 @@ Given below is an example usage scenario on how an existing user can add Deadlin 1. When the user launches the application, existing information is read from the data file `profbook.json`. In our case, let us narrow our focus to a specific group with 2 students. - + 2. Suppose the user is still in the root directory and wants to add a deadline to all students in group1, the user would execute the following @@ -427,7 +429,7 @@ Given below is an example usage scenario on how an existing user can add Deadlin task is already present, if not it would add the task. 6. It should look something like this. - + 7. In the above diagram, Jerry already has the exact deadline and adding it would result in a duplicate. Therefore, the task is only added to student Ben. @@ -435,7 +437,7 @@ Given below is an example usage scenario on how an existing user can add Deadlin This sequence diagram illustrates the general flow when adding the deadline task to *all* students, the sequence diagram for adding a deadline task to a *single* student can be found in the `Model` component. - + This is an activity diagram showing the general activity of the add deadline command. @@ -501,17 +503,17 @@ Given below is an example usage scenario on how an existing user can edit the na 6. The `RootChildOperation::editChild` then makes a copy of the existing group while updating the values found in the `EditGroupDescriptor`. - + 6. It then deletes the old key-value pair in root's `Map` and adds the new key-value pair. - + This is illustrated by the following sequence diagram. It shows the general flow of the edit through editing a `Group` instance, this example should be general enough for you to understand how the edit command works on other classes such as `Student`. - + This is an activity diagram showing the general activity of the edit command. diff --git a/docs/diagrams/DeleteTaskSequenceDiagram.puml b/docs/diagrams/DeleteTaskSequenceLogicDiagram.puml similarity index 56% rename from docs/diagrams/DeleteTaskSequenceDiagram.puml rename to docs/diagrams/DeleteTaskSequenceLogicDiagram.puml index e90cd7bf484..a37a54fdaf9 100644 --- a/docs/diagrams/DeleteTaskSequenceDiagram.puml +++ b/docs/diagrams/DeleteTaskSequenceLogicDiagram.puml @@ -7,13 +7,8 @@ participant ":LogicManager" as LogicManager LOGIC_COLOR participant ":ProfBookParser" as ProfBookParser LOGIC_COLOR participant ":DeleteTaskCommandParser" as DeleteTaskCommandParser LOGIC_COLOR participant "d:DeleteTaskCommand" as DeleteTaskCommand LOGIC_COLOR -participant ":CommandResult" as CommandResult LOGIC_COLOR end box -box Model MODEL_COLOR_T1 -participant ":ModelManager" as ModelManagerStatic MODEL_COLOR -participant "opr:TaskOperation" as TaskOperation MODEL_COLOR -end box [-> LogicManager : execute("rmt 1") activate LogicManager @@ -47,45 +42,15 @@ destroy DeleteTaskCommandParser ProfBookParser --> LogicManager : d deactivate ProfBookParser -LogicManager -> DeleteTaskCommand : execute(state) -activate DeleteTaskCommand - -DeleteTaskCommand -> ModelManagerStatic : taskOperation(new Path("~/grp-001")) -activate ModelManagerStatic - -create TaskOperation -ModelManagerStatic -> TaskOperation -activate TaskOperation - -TaskOperation --> ModelManagerStatic : opr -deactivate TaskOperation - -ModelManagerStatic --> DeleteTaskCommand :opr -deactivate ModelManagerStatic - -DeleteTaskCommand -> TaskOperation : opr.deleteTask(1) -activate TaskOperation - -TaskOperation --> DeleteTaskCommand - -destroy TaskOperation - -DeleteTaskCommand -> ModelManagerStatic : updateList() -activate ModelManagerStatic - -ModelManagerStatic --> DeleteTaskCommand -deactivate ModelManagerStatic - -create CommandResult -DeleteTaskCommand -> CommandResult -activate CommandResult - -CommandResult --> DeleteTaskCommand : result -deactivate CommandResult +LogicManager -> DeleteTaskCommand : execute("state") +ref over DeleteTaskCommand + Execution of DeleteTaskCommand +end ref DeleteTaskCommand --> LogicManager : result deactivate DeleteTaskCommand [<--LogicManager deactivate LogicManager + @enduml diff --git a/docs/diagrams/DeleteTaskSequenceModelDiagram.puml b/docs/diagrams/DeleteTaskSequenceModelDiagram.puml new file mode 100644 index 00000000000..1e90616b978 --- /dev/null +++ b/docs/diagrams/DeleteTaskSequenceModelDiagram.puml @@ -0,0 +1,53 @@ +@startuml +!include style.puml +skinparam ArrowFontStyle plain + +box Logic LOGIC_COLOR_T1 +participant "d:DeleteTaskCommand" as DeleteTaskCommand LOGIC_COLOR +participant ":CommandResult" as CommandResult LOGIC_COLOR +end box + +box Model MODEL_COLOR_T1 +participant ":ModelManager" as ModelManagerStatic MODEL_COLOR +participant "opr:TaskOperation" as TaskOperation MODEL_COLOR +end box + +mainframe **sd** Execution of DeleteTaskCommand + +activate DeleteTaskCommand + +DeleteTaskCommand -> ModelManagerStatic : taskOperation(new Path("~/grp-001")) +activate ModelManagerStatic + +create TaskOperation +ModelManagerStatic -> TaskOperation +activate TaskOperation + +TaskOperation --> ModelManagerStatic : opr +deactivate TaskOperation + +ModelManagerStatic --> DeleteTaskCommand :opr +deactivate ModelManagerStatic + +DeleteTaskCommand -> TaskOperation : opr.deleteTask(1) +activate TaskOperation + +TaskOperation --> DeleteTaskCommand + +destroy TaskOperation + +DeleteTaskCommand -> ModelManagerStatic : updateList() +activate ModelManagerStatic + +ModelManagerStatic --> DeleteTaskCommand +deactivate ModelManagerStatic + +create CommandResult +DeleteTaskCommand -> CommandResult +activate CommandResult + +CommandResult --> DeleteTaskCommand : result +deactivate CommandResult + + +@enduml \ No newline at end of file From 362c9f705dd4313b448affabe3d9239ed9dfe78d Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Fri, 10 Nov 2023 23:42:06 +0800 Subject: [PATCH 03/31] Fix style issue --- docs/diagrams/DeleteTaskSequenceModelDiagram.puml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/docs/diagrams/DeleteTaskSequenceModelDiagram.puml b/docs/diagrams/DeleteTaskSequenceModelDiagram.puml index 1e90616b978..40eb4319a71 100644 --- a/docs/diagrams/DeleteTaskSequenceModelDiagram.puml +++ b/docs/diagrams/DeleteTaskSequenceModelDiagram.puml @@ -48,6 +48,4 @@ activate CommandResult CommandResult --> DeleteTaskCommand : result deactivate CommandResult - - -@enduml \ No newline at end of file +@enduml From fbe322b0aa932f44638008df20d9a3f148709f80 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Fri, 10 Nov 2023 23:45:05 +0800 Subject: [PATCH 04/31] Fix minor bug --- docs/DeveloperGuide.md | 2 +- docs/diagrams/ArchitectureSequenceDiagram.puml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index fca9997cdb6..c68f2953aad 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -83,7 +83,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 command `rm 0001Y` to delete student with id `0001Y`. diff --git a/docs/diagrams/ArchitectureSequenceDiagram.puml b/docs/diagrams/ArchitectureSequenceDiagram.puml index a9cf3974b50..ab6c49bd054 100644 --- a/docs/diagrams/ArchitectureSequenceDiagram.puml +++ b/docs/diagrams/ArchitectureSequenceDiagram.puml @@ -8,7 +8,7 @@ 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 : "rm 0001Y" activate ui UI_COLOR ui -[UI_COLOR]> logic : execute("rm 0001Y") From 56bc8945ecfc0569b1a341c3ba0b869b74f3a8f9 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Fri, 10 Nov 2023 23:56:18 +0800 Subject: [PATCH 05/31] Add fullstops --- docs/DeveloperGuide.md | 135 ++++++++++++++++++++--------------------- 1 file changed, 66 insertions(+), 69 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index c68f2953aad..d7d007e907f 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -142,7 +142,7 @@ as an example. `rmt` is the command word for DeleteTaskCommand class. By executing the command `rmt 1`, tha task with index number 1 will be deleted. - + @@ -157,7 +157,7 @@ How the `Logic` component works: Here are the other classes in `Logic` (omitted from the class diagram above) that are used for parsing a user command: - + How the parsing works: @@ -186,18 +186,18 @@ The `Model` component, * stores a `UserPref` object that represents the user’s preferences. This is exposed to the outside as a `ReadOnlyUserPref` objects. * does not depend on any of the other three components (as the `Model` represents data entities of the domain, they - should make sense on their own without depending on other components) + should make sense on their own without depending on other components). The diagram above shows how the folder structure is implemented in ProfBook, -* The hierarchy is as such: `Root` -> `Group` -> `Student` +* The hierarchy is as such: `Root` -> `Group` -> `Student`. * As many of the operations are repeated (e.g., tasks operations and children operation), we decided to abstract out these logic into their own classes which is represented by `TaskListManager` and `ChildrenManager` respectively. -* `ChildrenManager` manages the children which is of type `IChildElement` +* `ChildrenManager` manages the children which is of type `IChildElement`. * We also created a wrapper class (e.g. `ChildrenAndTaskListManager`) for classes that require both of those - aforementioned functionalities (e.g, `Group` and potentially in the future `TutorialSlot`) + aforementioned functionalities (e.g, `Group` and potentially in the future `TutorialSlot`). **API** : [`TaskListManager.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/model/profbook/TaskListManager.java) @@ -630,46 +630,43 @@ that will be faster than a typical mouse/GUI driven app Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unlikely to have) - `*` -| Priority level | 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 | -| `* * *` | new user | take advantage of existing linux skills | be more efficient in using the application | -| `* * *` | new user | delete a student | remove students that I no longer need | -| `* * *` | new user | create deadlines for student | keep track of when assignments are due | -| `* * *` | new user | create todo task for student | keep track of which label they are at | -| `* * *` | new user | create deadline for a group | keep track of when group specific assignments are due | -| `* * *` | new user | create todo for a group | keep track of the progress of each group relative to others | -| `* * *` | new user | create deadline for a tutorial group | keep track of when tutorial specific assignments are due | -| `* * *` | new user | create todo tasks for a tutorial group | keep track of the progress of each tutorial group relative to others | -| `* * *` | new user | add time to a task | i can record when a task needs to be done | -| `* * *` | new user | set alerts and notification | I can receive the notifications of the task | -| `* * *` | new user | see the pending task that has the next earliest deadline | i can know what do do next | -| `* * *` | new user | Add the profile picture of students | I can better remember them | -| `* * *` | new user | Add the profile picture of students | I can better remember them | -| `* * *` | new user | Add the matriculation number of students | I can update their grade based on the matriculation number | -| `* * *` | new user | create student profile | manage information of a specific student | -| `* * *` | new user | create group | manage information of a specific group | -| `* * *` | new user | create tutorial slot | manage information fo a specific tutorial slot | -| `* * *` | Experienced user | search for a student/tutorial group by name | pull up students/tutorial groups without having to go through the entire list | -| `* * *` | Experienced user | Mark task done for every student in a group | I do not need to mark each task manually | -| `* * *` | Experienced user | Add tasks for every student in the book | I do not need to add tasks manually | -| `* * *` | Experienced user | Add tasks for every student in a tutorial group | I do not need to add tasks manually | -| `* * *` | Experienced user | Add tasks for every student in a group | I do not need to add tasks manually | -| `* * ` | Experienced user | Be able to see an brief overview of last week | Can see deadlines that have passed etc | -| `* * ` | Experienced user | Easily edit the student/tutorial groups | Information is applicable throughout time | -| `* * ` | Experienced user | Move students around, edit which group they are in | I can be flexible with the groupings | -| `* * ` | Expert user | Check last week's deadline have been met or not | I would not miss any deadline | -| `* * ` | Expert user | Upload text file contains tutorial groups and students | I do not need to manually add students and tutorial groups | -| `*` | Experienced user | Sync with google calendar | To keep information easily accessible | -| `* ` | Experienced user | Sync with nusmods | To make it easier to take note of tutorial venues | -| `*` | Experienced user | Use addressbook to track attendance for each tutorial book | I can easily write down attendance in one area | -| `*` | Expert user | View a dashboard that provides the overview of the progress of each tutorial group and their respecective tasks | I can easily and quickly focus on areas that require my attention | -| `*` | Expert user | Let the program generate a detailed report on the performace of each tutorial group | I can easily identify the areas of strengths and weaknesses of each students | -| `*` | Expert user | Incorporate my own scripts to customise my own experience | I can improve productivity and tailor fit the software for myself | -| `*` | Expert user | make the program support customizable templates for tutorials and student profiles | I can make it more aesthetically pleasing | -| `*` | Expert user | Make use of the feature to archive certain task | I can keep track of the history and not focus on unimportant task. | - -*{More to be added}* +| Priority level | 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 | +| `* * *` | new user | take advantage of existing Linux skills | be more efficient in using the application | +| `* * *` | new user | create deadlines for student | keep track of when assignments are due | +| `* * *` | new user | create todo task for student | keep track of which label they are at | +| `* * *` | new user | create deadline for a group | keep track of when group specific assignments are due | +| `* * *` | new user | create todo for a group | keep track of the progress of each group relative to others | +| `* * *` | new user | create deadline for a tutorial group | keep track of when tutorial specific assignments are due | +| `* * *` | new user | create todo tasks for a tutorial group | keep track of the progress of each tutorial group relative to others | +| `* * *` | new user | add time to a task | i can record when a task needs to be done | +| `* * *` | new user | set alerts and notification | I can receive the notifications of the task | +| `* * *` | new user | see the pending task that has the next earliest deadline | i can know what do do next | +| `* * *` | new user | add the profile picture of students | I can better remember them | +| `* * *` | new user | add the matriculation number of students | I can update their grade based on the matriculation number | +| `* * *` | new user | create student profile | manage information of a specific student | +| `* * *` | new user | create group | manage information of a specific group | +| `* * *` | new user | create tutorial slot | manage information fo a specific tutorial slot | +| `* * *` | new user | delete a student | remove students that I no longer need | +| `* * *` | Experienced user | search for a student/tutorial group by name | pull up students/tutorial groups without having to go through the entire list | +| `* * *` | Experienced user | mark task done for every student in a group | I do not need to mark each task manually | +| `* * *` | Experienced user | add tasks for every student in the book | I do not need to add tasks manually | +| `* * *` | Experienced user | add tasks for every student in a tutorial group | I do not need to add tasks manually | +| `* * *` | Experienced user | add tasks for every student in a group | I do not need to add tasks manually | +| `* * ` | Experienced user | be able to see an brief overview of last week | Can see deadlines that have passed etc | +| `* * ` | Experienced user | easily edit the student/tutorial groups | Information is applicable throughout time | +| `* * ` | Experienced user | move students around, edit which group they are in | I can be flexible with the groupings | +| `* * ` | Expert user | check last week's deadline have been met or not | I would not miss any deadline | +| `* * ` | Expert user | upload text file contains tutorial groups and students | I do not need to manually add students and tutorial groups | +| `*` | Experienced user | sync with Google calendar | To keep information easily accessible | +| `* ` | Experienced user | sync with NUSMods | To make it easier to take note of tutorial venues | +| `*` | Experienced user | use ProfBook to track attendance for each tutorial slot | I can easily write down attendance in one area | +| `*` | Expert user | view a dashboard that provides the overview of the progress of each tutorial group and their respective tasks | I can easily and quickly focus on areas that require my attention | +| `*` | Expert user | let the program generate a detailed report on the performance of each tutorial group | I can easily identify the areas of strengths and weaknesses of each students | +| `*` | Expert user | incorporate my own scripts to customise my own experience | I can improve productivity and tailor fit the software for myself | +| `*` | Expert user | make the program support customizable templates for tutorials and student profiles | I can make it more aesthetically pleasing | +| `*` | Expert user | make use of the feature to archive certain task | I can keep track of the history and not focus on unimportant task. | ### Use cases @@ -690,7 +687,7 @@ otherwise) * 2a. User inputs help with specific command. - * 2a1. ProfBook displays help message specific to input command + * 2a1. ProfBook displays help message specific to input command. Use case ends. @@ -705,21 +702,21 @@ otherwise) **MSS** -1. User requests to cd into a specific group -2. ProfBook moves into the directory, display updates to show students within specified group +1. User requests to cd into a specific group. +2. ProfBook moves into the directory, display updates to show students within specified group. Use case ends. **Extensions** -* 2a. The path of the group is invalid +* 2a. The path of the group is invalid. * 2a1. ProfBook shows an error message. Use case resumes at step 1. -* 2b. The path of the group is empty +* 2b. The path of the group is empty. * 2b1. ProfBook shows an error message. @@ -736,13 +733,13 @@ otherwise) **Extensions** -* 2a. Provided path is invalid +* 2a. Provided path is invalid. * 2a1. ProfBook shows an error message. Use case resumes at step 1. -* 2b. Command has no arguments +* 2b. Command has no arguments. * 2b1. ProfBook shows list of children under current directory. @@ -765,9 +762,9 @@ otherwise) Use case resumes at step 1. -* 2b1. No path specified +* 2b1. No path specified. - * 2b1. Profbook displays task list of current path. + * 2b1. ProfBook displays task list of current path. Use case ends. @@ -784,7 +781,7 @@ otherwise) **MSS** -1. User requests to exit ProfBook +1. User requests to exit ProfBook. 2. ProfBook stores all data and closes application. Use case ends. @@ -851,7 +848,7 @@ otherwise) **MSS** -1. User requests to delete a group or student +1. User requests to delete a group or student. 2. ProfBook removes group or student. Use case ends. @@ -909,8 +906,8 @@ otherwise) **MSS** -1. User requests to create a group with path and name -2. ProfBook creates the group +1. User requests to create a group with path and name. +2. ProfBook creates the group. Use case ends. @@ -951,7 +948,7 @@ otherwise) Use case resumes at step 1. -* 2c. No path specified +* 2c. No path specified. * 2b1. ProfBook creates ToDo under current directly, either for groups while at root or for students while in group. @@ -980,7 +977,7 @@ otherwise) Use case resumes at step 1. -* 2c. No path specified +* 2c. No path specified. * 2c1. ProfBook creates Deadline under current directly, either for groups while at root or for students while in group. @@ -991,30 +988,30 @@ otherwise) **MSS** -1. User requests to mark a specific task +1. User requests to mark a specific task. 2. ProfBook marks task based on given index, display updates to show as marked. Use case ends. **Extensions** -* 2a. The Index provided is invalid +* 2a. The Index provided is invalid. * 2a1. ProfBook shows an error message. Use case resumes at step 1. -**Use case: Unmark task** +**Use case: Un-mark task** **MSS** -1. User requests to unmark a specific task -2. ProfBook unmarks task based on given index, display updates to show as unmarked. +1. User requests to un-mark a specific task. +2. ProfBook un-marks task based on given index, display updates to show as unmarked. Use case ends. **Extensions** -* 2a. The Index provided is invalid +* 2a. The Index provided is invalid. * 2a1. ProfBook shows an error message. Use case resumes at step 1. @@ -1023,14 +1020,14 @@ otherwise) **MSS** -1. User requests to delete a specific task +1. User requests to delete a specific task. 2. ProfBook delete task based on given index. Use case ends. **Extensions** -* 2a. The Index provided is invalid +* 2a. The Index provided is invalid. * 2a1. ProfBook shows an error message. Use case resumes at step 1. From 31bdb4824e9488557a1dcd84d241211d3545f772 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Sat, 11 Nov 2023 00:01:30 +0800 Subject: [PATCH 06/31] Minor changes to use cases --- docs/DeveloperGuide.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index d7d007e907f..c9d56163cbc 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -925,11 +925,11 @@ otherwise) Use case resumes at step 1. -**Use case: Create a ToDo** +**Use case: Create a ToDo task** **MSS** -1. User requests to create a ToDo task. +1. User requests to create a ToDo task either. 2. ProfBook creates the Task under specified path/current path. Use case ends. @@ -942,7 +942,7 @@ otherwise) Use case resumes at step 1. -* 2b. The given description is invalid. +* 2b. The given description is empty/duplicated. * 2b1. ProfBook shows an error message. @@ -950,11 +950,11 @@ otherwise) * 2c. No path specified. - * 2b1. ProfBook creates ToDo under current directly, either for groups while at root or for students while in group. + * 2c1. ProfBook creates ToDo under current directly, either for groups while at root or for students while in group. Use case ends. -**Use case: Create a Deadline** +**Use case: Create a Deadline task** **MSS** @@ -971,7 +971,7 @@ otherwise) Use case resumes at step 1. -* 2b. The given description is invalid. +* 2b. The given description is empty/duplicated. * 2b1. ProfBook shows an error message. From a23a592fcd99bd19c301e8d99f832a0d14047e81 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Sat, 11 Nov 2023 13:34:07 +0800 Subject: [PATCH 07/31] Remove unused diagrams --- docs/diagrams/CommitActivityDiagram.puml | 18 ------------------ 1 file changed, 18 deletions(-) delete mode 100644 docs/diagrams/CommitActivityDiagram.puml diff --git a/docs/diagrams/CommitActivityDiagram.puml b/docs/diagrams/CommitActivityDiagram.puml deleted file mode 100644 index 8c0892d6a70..00000000000 --- a/docs/diagrams/CommitActivityDiagram.puml +++ /dev/null @@ -1,18 +0,0 @@ -@startuml -skin rose -skinparam ActivityFontSize 15 -skinparam ArrowFontSize 12 -start -:User executes command; - -'Since the beta syntax does not support placing the condition outside the -'diamond we place it as the true branch instead. - -if () then ([command commits AddressBook]) - :Purge redundant states; - :Save AddressBook to - addressBookStateList; -else ([else]) -endif -stop -@enduml From c58ac0c29f1d8ba97e2ba0c764a2904bc9d66104 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Sat, 11 Nov 2023 18:13:21 +0800 Subject: [PATCH 08/31] Add API for path --- docs/DeveloperGuide.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index e8955cceccc..518c9f735fa 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -199,7 +199,9 @@ The diagram above shows how the folder structure is implemented in ProfBook, * We also created a wrapper class (e.g. `ChildrenAndTaskListManager`) for classes that require both of those aforementioned functionalities (e.g, `Group` and potentially in the future `TutorialSlot`). -**API** : [`TaskListManager.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/model/profbook/TaskListManager.java) +##### Task component + +**API** : [`TaskListManager.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/model/task/TaskListManager.java) @@ -235,8 +237,13 @@ to check that the Operation required matches with the intended effect of the Com -#### Path package -The `path` package in `model` package serves as a fundamental representation of the hierachical structure within the application. It delineates the navigational paths essential for traversal and dynamic command execution within the system. +#### Path component + +**API** : [`Path.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/model/path/Path.java) + +The `path` package in `model` package serves as a fundamental representation of the hierarchical structure within the +application. It delineates the navigational paths essential for traversal and dynamic command execution within the +system. Here is a class diagram for the path package: @@ -251,7 +258,9 @@ Here is a class diagram for the path package: * `CURRENT`: Corresponds to the `.` notation, indicating the current directory. 3. `AbsolutePath` represents an absolute path within the system and strictly commences with the `~` element. * The `resolve` method is crucial to resolve a `RelativePath` and return the resolved path in `AbsolutePath` type. - * e.g. Consider an `AbsolutePath` represents `~/grp-001/0001A`. If the `resolve` method is called with the `RelativePath` representing `../grp-002`, the resolve method will return the `AbsolutePath` representing the path `~/grp-002`. + * e.g. Consider an `AbsolutePath` represents `~/grp-001/0001A`. If the `resolve` method is called with the + `RelativePath` representing `../grp-002`, the resolve method will return the `AbsolutePath` representing the path + `~/grp-002`. ### Storage component From a7834ba59bfdf5b7506cd008995ff515a612cbc2 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Sat, 11 Nov 2023 18:15:19 +0800 Subject: [PATCH 09/31] Add API for path --- docs/DeveloperGuide.md | 47 +++++++++++++++++++++--------------------- 1 file changed, 23 insertions(+), 24 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 518c9f735fa..fe8204d4461 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -91,7 +91,7 @@ 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. + 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 @@ -150,10 +150,10 @@ How the `Logic` component works: 1. When `Logic` is called upon to execute a command, it is passed to an `ProfBookParser` object which in turn creates a parser that matches the command (e.g., `DeleteTaskCommandParser`) 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., `DeleteTaskCommand`) +2. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `DeleteTaskCommand`) which is executed by the `LogicManager`. -1. The command can communicate with the `Model` when it is executed (e.g. to delete a task). -1. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`. +3. The command can communicate with the `Model` when it is executed (e.g. to delete a task). +4. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`. Here are the other classes in `Logic` (omitted from the class diagram above) that are used for parsing a user command: @@ -252,8 +252,8 @@ Here is a class diagram for the path package: 1. The `PathElement` class forms the building blocks for constructing paths within ProfBook. 2. `PathElementType` enum defines the type of elements within a path: * `ROOT`: Represents the root element in the hierarchy. - * `GROUPID`: Represents the element corresponding to a group in the hierachy. - * `STUDENTID`: Represents the element corresponding to a student in the hierachy. + * `GROUPID`: Represents the element corresponding to a group in the hierarchy. + * `STUDENTID`: Represents the element corresponding to a student in the hierarchy. * `PARENT`: Corresponds to the `..` notation, indicating the parent directory. * `CURRENT`: Corresponds to the `.` notation, indicating the current directory. 3. `AbsolutePath` represents an absolute path within the system and strictly commences with the `~` element. @@ -331,9 +331,8 @@ To further illustrate our folder structure, we have prepared this diagram **Aspect: How store reference to children** * **Alternative 1 (current implementation):** HashMap. - * Pros: Able to check/find if a student/group is present efficiently, mapping objects by their Id also makes - executing - commands in a folder-like structure easier. + * Pros: Able to check/find if a student/group is present efficiently, mapping objects by their ID also makes + executing commands in a folder-like structure easier. * Cons: Not really any. * **Alternative 2**: Array. * Pros: Very easy to implement @@ -451,7 +450,7 @@ Given below is an example usage scenario on how an existing user can add Deadlin via `GroupChildOperation::checkIfAllChildrenHaveTask` method. 5. If all checks out, the command would create a new deadline instance and add the deadline to all student that do not already have the aforementioned task. This is done - through getting a `GroupChildOperation` facade class from the `Model::groupChildOperation` method. The tasks is then + through getting a `GroupChildOperation` facade class from the `Model::groupChildOperation` method. The tasks are then added through the `GroupChildOperation::addTaskToAllStudent` method. For each student, the method would check if the task is already present, if not it would add the task. 6. It should look something like this. @@ -532,7 +531,7 @@ Given below is an example usage scenario on how an existing user can edit the na -6. It then deletes the old key-value pair in root's `Map` and adds the new key-value pair. +7. It then deletes the old key-value pair in root's `Map` and adds the new key-value pair. @@ -550,7 +549,7 @@ This is an activity diagram showing the general activity of the edit command. **Aspect: How to ensure `edit` is able to handle editing students and group** -* **Alternative 1 (current implementation):** Implement an generic `edit` which acts differently depending on the input +* **Alternative 1 (current implementation):** Implement a generic `edit` which acts differently depending on the input path. * Pros: Closely follows OOP principals and makes `edit` more extensible * Cons: Harder to implement, more confusing for users @@ -605,8 +604,8 @@ users to have the peace of mind that the phone number is validated and robust en ### Better marking and un-marking validation (// TODO low priority, remove when needed ) Currently, our application does not check if the tasks is marked or unmarked before any operation. This resulted in -users being able to mark/unmark tasks infinitely, this is not intuitive and may mislead some users. Hence, we plan to -only allow users to unmark tasks that are marked and vice versa. Also, we plan to add a more descriptive error message +users being able to mark/un-mark tasks infinitely, this is not intuitive and may mislead some users. Hence, we plan to +only allow users to un-mark tasks that are marked and vice versa. Also, we plan to add a more descriptive error message to highlight to the user of the current state of the task. ### More robust duplicate checking @@ -623,7 +622,7 @@ that some of our error message could be more descriptive. One such example is tr trying to edit a directory that does not exist. In both cases, the error message given is `Path does not exist in ProfBook.`. In this example, we could have mention that you are unable to edit the root directory for the prior and that the Path does not lead to a student/group for the latter. This is just one example, we -plan to revamp our error message to be more descriptive and user friendly +plan to revamp our error message to be more descriptive and user-friendly -------------------------------------------------------------------------------------------------------------------- @@ -1157,17 +1156,17 @@ testers are expected to do more *exploratory* testing. 1. Download the jar file and copy into an empty folder - 1. Double-click the jar file Expected: Shows the GUI with a set of sample contacts. The window size may not be + 2. 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 +2. Saving window preferences 1. Resize the window to an optimum size. Move the window to a different location. Close the window. - 1. Re-launch the app by double-clicking the jar file.
+ 2. Re-launch the app by double-clicking the jar file.
Expected: The most recent window size and location is retained. -1. _{ more test cases …​ }_ +3. _{ more test cases …​ }_ ### Deleting a person @@ -1175,17 +1174,17 @@ testers are expected to do more *exploratory* testing. 1. Prerequisites: List all persons using the `list` command. Multiple persons in the list. - 1. Test case: `delete 1`
+ 2. 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. - 1. Test case: `delete 0`
+ 3. Test case: `delete 0`
Expected: No person is deleted. Error details shown in the status message. Status bar remains the same. - 1. Other incorrect delete commands to try: `delete`, `delete x`, `...` (where x is larger than the list size)
+ 4. Other incorrect delete commands to try: `delete`, `delete x`, `...` (where x is larger than the list size)
Expected: Similar to previous. -1. _{ more test cases …​ }_ +2. _{ more test cases …​ }_ ### Saving data @@ -1193,7 +1192,7 @@ testers are expected to do more *exploratory* testing. 1. _{explain how to simulate a missing/corrupted file, and the expected behavior}_ -1. _{ more test cases …​ }_ +2. _{ more test cases …​ }_
From 5ff6f29e6868e9d58e0e4d1c190ab3132020636d Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Sun, 12 Nov 2023 02:07:27 +0800 Subject: [PATCH 10/31] Fix error from meeting --- docs/DeveloperGuide.md | 177 +++++++++++------- docs/diagrams/AddFinalState.puml | 18 +- docs/diagrams/AddInitialState.puml | 16 +- .../CreateDeadlineCommandSequenceDiagram.puml | 26 +-- docs/diagrams/DeadlineFinalState.puml | 12 +- docs/diagrams/DeadlineInitialState.puml | 8 +- .../DeleteTaskSequenceLogicDiagram.puml | 3 + docs/diagrams/EditCommandSequenceDiagram.puml | 2 +- docs/diagrams/EditFinalState.puml | 26 +-- docs/diagrams/EditGroupActivityDiagram.puml | 2 +- docs/diagrams/EditIntermediateState.puml | 20 +- docs/diagrams/MoveStudentSequenceDiagram.puml | 24 +-- 12 files changed, 189 insertions(+), 145 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index fe8204d4461..f1d4dc32bb2 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -146,6 +146,12 @@ will be deleted. + + +**Note:** Due to the limitations of PlantUML, the reference frame in the first UML diagram is slightly overlapped. + + + How the `Logic` component works: 1. When `Logic` is called upon to execute a command, it is passed to an `ProfBookParser` object which in turn creates a @@ -193,23 +199,23 @@ The `Model` component, The diagram above shows how the folder structure is implemented in ProfBook, * The hierarchy is as such: `Root` -> `Group` -> `Student`. -* As many of the operations are repeated (e.g., tasks operations and children operation), we decided to abstract out +* As many of the operations are repeated (e.g. tasks operations and children operation), we decided to abstract out these logic into their own classes which is represented by `TaskListManager` and `ChildrenManager` respectively. * `ChildrenManager` manages the children which is of type `IChildElement`. * We also created a wrapper class (e.g. `ChildrenAndTaskListManager`) for classes that require both of those aforementioned functionalities (e.g, `Group` and potentially in the future `TutorialSlot`). -##### Task component +##### Task sub-package **API** : [`TaskListManager.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/model/task/TaskListManager.java) - + How the `Task` component work: * As mentioned earlier, `TaskListManager` encapsulates the logic required to maintain a TaskList, this logic is utilised heavily in the ProfBook component. -* All tasks extend from the abstract class `Task`, we did this so for extensibility. So in the future, should we decide +* All tasks extend from the abstract class `Task`, we did this for extensibility. So in the future, should we decide to implement a new type of task, all we have to do is extend from `Task`. The sequence diagram below illustrates the interactions within the `Model` component, taking an execution of a @@ -221,13 +227,11 @@ we shall be narrowing our scope to adding a todo tasks to a specified group, g. How the `Model` component works: * Depending on the nature of the command, a static method is called to generate a `TaskOperation` or - a `ChildrenOperation` Object that acts as an interface Command object to manipulate the Model + a `ChildrenOperation` Object that acts as an interface manipulate the Model * In this case, a `TaskOperation` object is created. This object would store all the necessary information to make changes directly on the correct state. -* The command object calls the required method in the `TaskOperation` object which results in the `TaskOperation` - object adding the Todo task to the group. -* Our `TaskOperation` and `ChildOperation` classes follow. - the [facade pattern](https://nus-cs2103-ay2324s1.github.io/website/se-book-adapted/chapters/designPatterns.html#facade-pattern) +* The `Command` instance calls the required method in the `TaskOperation` object which results in the `TaskOperation` + object performing the addition of the Todo task to the group. @@ -237,30 +241,30 @@ to check that the Operation required matches with the intended effect of the Com -#### Path component +#### Path sub-package **API** : [`Path.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/model/path/Path.java) The `path` package in `model` package serves as a fundamental representation of the hierarchical structure within the -application. It delineates the navigational paths essential for traversal and dynamic command execution within the +application. It delineates the navigational paths essential for traversal and dynamic command execution within the system. Here is a class diagram for the path package: -1. The `PathElement` class forms the building blocks for constructing paths within ProfBook. -2. `PathElementType` enum defines the type of elements within a path: - * `ROOT`: Represents the root element in the hierarchy. - * `GROUPID`: Represents the element corresponding to a group in the hierarchy. - * `STUDENTID`: Represents the element corresponding to a student in the hierarchy. - * `PARENT`: Corresponds to the `..` notation, indicating the parent directory. - * `CURRENT`: Corresponds to the `.` notation, indicating the current directory. -3. `AbsolutePath` represents an absolute path within the system and strictly commences with the `~` element. - * The `resolve` method is crucial to resolve a `RelativePath` and return the resolved path in `AbsolutePath` type. - * e.g. Consider an `AbsolutePath` represents `~/grp-001/0001A`. If the `resolve` method is called with the - `RelativePath` representing `../grp-002`, the resolve method will return the `AbsolutePath` representing the path - `~/grp-002`. +* The `PathElement` class forms the building blocks for constructing paths within ProfBook. +* `PathElementType` enum defines the type of elements within a path: + * `ROOT`: Represents the root element in the hierarchy. + * `GROUPID`: Represents the element corresponding to a group in the hierarchy. + * `STUDENTID`: Represents the element corresponding to a student in the hierarchy. + * `PARENT`: Corresponds to the `..` notation, indicating the parent directory. + * `CURRENT`: Corresponds to the `.` notation, indicating the current directory. +* `AbsolutePath` represents an absolute path within the system and strictly commences with the `~` element. + * The `resolve` method is crucial to resolve a `RelativePath` and return the resolved path in `AbsolutePath` type. + * e.g. Consider an `AbsolutePath` represents `~/grp-001/0001A`. If the `resolve` method is called with the + `RelativePath` representing `../grp-002`, the resolve method will return the `AbsolutePath` representing the path + `~/grp-002`. ### Storage component @@ -301,7 +305,7 @@ but I will delve into it more comprehensively. We first created interfaces to represent the required logic for each of the manager, namely `IChildrenManager` and `ITaskListManager`. Then we created concrete classes such as `ChildrenManager` and `TaskListManager` to encapsulate the aforementioned logic. The purpose of these classes was so that should a folder type, e.g. `Student`, require a -Manager functionality, we could just extend from said Manager thus reducing on repeated code. Due to the limitation of +manager functionality, we could just extend from said manager thus reducing on repeated code. Due to the limitation of Java, classes are not able to extend from multiple classes. To remedy this, we created a wrapper class, `ChildrenAndTaskListManager`. @@ -326,31 +330,33 @@ To further illustrate our folder structure, we have prepared this diagram * Cons: It results in a more rigid hierarchy, harder to extend upon. * **Alternative 2**: Flat structure. * Pros: Easier to implement relatively to the tree representation. - * Cons: Harder to maintain the hierarchy, search for items and load items from storage + * Cons: + * Harder to maintain the hierarchy, search for items and load items from storage. + * States are more coupled **Aspect: How store reference to children** * **Alternative 1 (current implementation):** HashMap. * Pros: Able to check/find if a student/group is present efficiently, mapping objects by their ID also makes executing commands in a folder-like structure easier. - * Cons: Not really any. -* **Alternative 2**: Array. - * Pros: Very easy to implement + * Cons: Items stored in HashMaps are unordered, meaning addition order is lost. +* **Alternative 2**: List. + * Pros: Very easy to implement. * Cons: Finding a student/group is very inefficient, updating references is also a hassle. ### Adding a student/group #### Implementation -Implementation for Creating a student and a group is very similar, so in this guide, I would go through the +Implementation for creating a `Student` and a `Group` is very similar, so in this guide, I would go through the implementation for the harder one, which is creating a student. Should you have any questions do feel free to contact us. Most of the logic for creating a student is encapsulated in the `CreateStudentCommand` class, this class utilise -the `GroupChildOperation` facade class to add the student to the group and the `Model` class to check for duplicates. +the `GroupChildOperation` class to add the student to the group and the `Model` class to check for duplicates. The following methods of `ModelManager` and `GroupChildOperation` are used: -1. `ModelManager::groupChildOperation` - To generate a facade class specific to the current group, it also checks for +1. `ModelManager::groupChildOperation` - To generate an operation class specific to the current group, it also checks for the validity and presence of the specified group. 2. `ModelManager::hasStudentWithId` - To check if the new student id is unique. 3. `GroupChildOperation::addChild` - To add the current student into the group. @@ -368,19 +374,20 @@ Given below is an example usage scenario on how an existing user can create a st Do note that the only required fields are `--name`. 3. The parser would retrieve all the relevant information from the input and encapsulates it in a `CreateStudentCommand`. 4. This command would first do these checks: - * checks if the specified path is a valid student path. This is done via the `Path::isStudentDirectory` method - * checks if adding the student would result in a duplicate within whole of ProfBook, ie if the student id is - already taken. This is done via the `ModelManager::hasStudentWithId` method. + * checks if the specified path contains the group. This is done via the `ModelManager::hasGroup` method. + * checks if the specified path is a valid student path. This is done via the `Path::isStudentDirectory` method. + * checks if adding the student would result in a duplicate within whole of ProfBook, ie if the student id is + already taken. This is done via the `ModelManager::hasStudentWithId` method. 5. In this case, if the input was `touch ~/grp-001/1234Y ...` or `touch ~/grp-001/9876A ...` a `CommandException` will be thrown. 6. If all checks out, the command would create a new student and add the student to the `Model`. This addition is done - through getting a `GroupChildOperation` facade class from the `Model::groupChildOperation` method. This would ensure + through getting a `GroupChildOperation` class from the `Model::groupChildOperation` method. This would ensure the path to the group is present and valid. The student is added through the `GroupChildOperation::addChild` method. 7. It should look something like this. -This sequence diagram shows the general flow of the CreateStudentCommand, for more information on each specific +This sequence diagram shows the general flow of the `CreateStudentCommand`, for more information on each specific component, do head over to their respective documentation. @@ -407,57 +414,64 @@ Below is an activity diagram showing the general activity of the add student com #### Implementation Creating and adding a task is one of the key feature of ProfBook. Currently, we support two types of tasks, -namely `ToDo` and `Deadline` Tasks. Both this tasks extends from the abstract `Task` class which add to its +namely `ToDo` and `Deadline` tasks. Both this tasks extends from the abstract `Task` class which add to its extensibility. It is important to note that currently, you can only add tasks to Group and Students. Needless to say, the information for these tasks are encapsulated withing their respective `Task` instance. -As the implementation for creating a `Todo` and `Deadline` task is very similar, I would be bringing you through +As the implementation for creating a `ToDo` and `Deadline` task is very similar, I would be bringing you through the implementation that we found to be more confusing. I would be going through creating a Deadline task and adding it -to **all students in a group**. Illustration in the form of a sequence diagram for creating a Todo and adding a singular -tasks can be found at the `Model` component. For more information you could reach out to us, we would be more than happy +to **all students in a group**. For more information you could reach out to us, we would be more than happy to help. -Most of the logic for creating a task is encapsulated in the `CreateDeadlineCommand` class, this class utilise -the `GroupChildOperation` facade class to add the Deadline to the group and check for duplicates. + + +**Note:** Illustration in the form of a sequence diagram for creating a `ToDo` and adding a singular +tasks can be found at the `Model` component. + + + + +Most of the logic for creating a task is encapsulated in the `CreateDeadlineCommand` class, this class utilises +the `GroupChildOperation` class to add the Deadline to the group and check for duplicates. The following methods of `ModelManager` and `GroupChildOperation` are used: -1. `ModelManager::groupChildOperation` - To generate a facade class specific to the current group, it also checks for +1. `ModelManager::groupChildOperation` - To generate an operation class specific to the current group, it also checks for the validity and presence of the specified group. 2. `GroupChildOperation::addAllTasks` - To add the tasks to all student within a group, it also checks if it is a duplicate task before adding. 3. `GroupChildOperation::checkIfAllChildrenHaveTask` - To check if all children within a group already has the task. -It is important to note that for adding a task to a singular group/student, the facade class `TaskOperation` is used -instead, a sequence diagram illustrating this can be found in the model component. +It is important to note that for adding a task to a singular group/student, the operation class `TaskOperation` is used +instead, a sequence diagram illustrating this can be found in the `Model` component. Given below is an example usage scenario on how an existing user can add Deadline to all students 1. When the user launches the application, existing information is read from the data file `profbook.json`. In our case, let us narrow our focus to a specific group with 2 students. - + 2. Suppose the user is still in the root directory and wants to add a deadline to all students in group1, the user would execute the following command: `deadline ~/grp-001 --desc Assignment 1 --datetime 2023-12-12 23:59 --all allStu`. More information on the - flags could be fond in the User Guide. -3. The parser would retrieve all the relevant information from the input and encapsulates it in + flags could be found in the User Guide. +3. The parser would retrieve all the relevant information from the input and encapsulate it in a `CreateDeadlineCommand`. 4. This command would first - * check if the specified path is a valid and present Group path. This is done via `Path::isGroupDirectory` method. + * check if the specified path is a valid and present group path. This is done via `Path::isGroupDirectory` method. * check if all students in the group already has the task. This is done via `GroupChildOperation::checkIfAllChildrenHaveTask` method. -5. If all checks out, the command would create a new deadline instance and add the deadline to all student that do not +5. If all checks out, the command would create a new `Deadline` instance and add the deadline to all student that do not already have the aforementioned task. This is done - through getting a `GroupChildOperation` facade class from the `Model::groupChildOperation` method. The tasks are then + through getting a `GroupChildOperation` class from the `Model::groupChildOperation` method. The tasks are then added through the `GroupChildOperation::addTaskToAllStudent` method. For each student, the method would check if the task is already present, if not it would add the task. 6. It should look something like this. -7. In the above diagram, Jerry already has the exact deadline and adding it would result in a duplicate. Therefore, the +7. In the above diagram, Jerry already has the exact `Deadline` and adding it would result in a duplicate. Therefore, the task is only added to student Ben. This sequence diagram illustrates the general flow when adding the deadline task to *all* students, the sequence @@ -493,22 +507,37 @@ This is an activity diagram showing the general activity of the add deadline com * Pros: Best of both worlds. * Cons: Harder to implement, user command is also more complex and bulky. +**Aspect: Should the same instance of the task be assigned during bulk task** + +* **Alternative 1:** No, each student/group should have their own unique instance. + * Pros: Each task's completion is independent of others. + * Cons: Takes more memory. +* **Alternative 2**: Yes. + * Pros: Able to change all task's state in one short. + * Cons: Unable to uniquely change a specific tasks without affecting other task, aliasing issue. + ### Editing information #### Implementation -Due to dynamic need of our target users, professors and TAs, there is a need for our edit command to be equally dynamic. +Due to the dynamic need of our target users, professors and TAs, there is a need for our edit command to be equally dynamic. Our edit command need to be general enough to allow the users to edit both students and groups. This is done by checking the type of directory that was passed in. This is done through the `Path::isGroupDirectory` -and `Path::isStudentDirectory` method. More information on how this is done can be found in the documentation -for `Path` component. This then allows parser to check for the validity of the given flags. +and `Path::isStudentDirectory` method. + + + +**Note:** More information on how this is done can be found in the documentation +for `path` package. This then allows parser to check for the validity of the given flags. + + As the implementation for editing students and groups is similar, for simplicity, I would be going through implementation of editing a group. The following methods of `ModelManager`, `Path` and `RootChildOperation` are used: -1. `ModelManager::rootChildOperation` - To generate a facade class with logic specific to the current root. +1. `ModelManager::rootChildOperation` - To generate an operation class with logic specific to the current root. 2. `ModelManager::hasGroupWithId` - To check if editing results in a duplicate. 3. `RootChildOperation::editChild` - To edit the group with the values extracted from parser. 4. `Path::isGroupDirectory` - To check if the path leads to a group directory. @@ -565,7 +594,7 @@ Initially, implementing this feature seemed like a daunting task. However, after realised that implementing move was quite straight forward. Moving a student can be easily done by removing the student's reference from its current group by removing its key-value pair from the group's `Map` field. Then to complete the move, the student is added to the target group by adding it into the target -group's `Map` field. All of this operation is facilitated by the `GroupChildOperation` facade class. +group's `Map` field. All of this operation is facilitated by the `GroupChildOperation` class. Given below is an example usage scenario whereby a student is moved from group1 to group2. @@ -579,7 +608,7 @@ Given below is an example usage scenario whereby a student is moved from group1 6. As uniqueness of student is validated before each student is added, there is no need to check for clashes when executing. - + -------------------------------------------------------------------------------------------------------------------- @@ -597,16 +626,17 @@ is just a combination of deleting and creating, but it improves the user's quali Currently, our application only checks if the phone number is more than 3 characters long. Our current validation is lacking as users are able to enter a `123` as a phone number or a phone number that is infinitely long. We plan to -improve this validation by enforcing a tighter validation. This can be achieved by creating a `map` of +improve this validation by enforcing a tighter validation. This can be achieved by creating a `Map` of common phone extensions to their length and then enforcing that the phone number be of that length. This allows our users to have the peace of mind that the phone number is validated and robust enough to handle international numbers. ### Better marking and un-marking validation (// TODO low priority, remove when needed ) -Currently, our application does not check if the tasks is marked or unmarked before any operation. This resulted in +Currently, our application does not check if the tasks are marked or unmarked before any operation. This results in users being able to mark/un-mark tasks infinitely, this is not intuitive and may mislead some users. Hence, we plan to -only allow users to un-mark tasks that are marked and vice versa. Also, we plan to add a more descriptive error message -to highlight to the user of the current state of the task. +only allow users to un-mark tasks that are marked and vice versa. This can be easily done by checking the current state +and throwing an error if the resultant state is same as the current state. Also, we plan to add a more descriptive error +message to highlight to the user of the current state of the task. ### More robust duplicate checking @@ -622,7 +652,14 @@ that some of our error message could be more descriptive. One such example is tr trying to edit a directory that does not exist. In both cases, the error message given is `Path does not exist in ProfBook.`. In this example, we could have mention that you are unable to edit the root directory for the prior and that the Path does not lead to a student/group for the latter. This is just one example, we -plan to revamp our error message to be more descriptive and user-friendly +plan to revamp our error message to be more descriptive and user-friendly. + +### Include tutorial slot + +Currently, our hierarchy only extends to `Group`. To serve our target users better, we plan to add a new level, +`TutorialSlot` to ProfBook. This would allow our target users to juggle not only groups but also tutorial slots. +Implementing this is rather easy as `TutorialSlot` would in theory be almost identical to the implementation of `Group`, +all `TutorialSlot` have to do is just extend from `ChildrenAndTaskListManager`. -------------------------------------------------------------------------------------------------------------------- @@ -1246,18 +1283,18 @@ project phases: ### **Effort Savings through Reuse** -A notable aspect of our project was the efficient use of custom components, which contributed to a significant reduction +A notable aspect of our project was the efficient use of custom logics, which contributed to a significant reduction in the overall effort. -- **Path Component:** We introduced the `Path` component, which includes subclasses for managing both **absolute** and -**relative** paths. This component played a crucial role in managing navigation and executing dynamic commands within +- **Path package:** We introduced the `path` package, which includes subclasses for managing both **absolute** and +**relative** paths. This package played a crucial role in managing navigation and executing dynamic commands within our application. -- **ChildrenManager Component:** The component was instrumental in representing the hierarchical structure in our - application. We successfully leveraged this component to perform operations related to child entities, optimizing the +- **ChildrenManager Class:** The class was instrumental in representing the hierarchical structure in our + application. We successfully leveraged this class to perform operations related to child entities, optimizing the handling of students within groups and groups within the ProfBook. -- **TaskListManager Component:** This component streamlines task management and allocation by providing a consistent and +- **TaskListManager class:** This class streamlines task management and allocation by providing a consistent and unified interface for handling tasks throughout the application. -Reusing these components enhanced project efficiency and maintainability. +Reusing these logics enhanced project efficiency and maintainability. diff --git a/docs/diagrams/AddFinalState.puml b/docs/diagrams/AddFinalState.puml index 57d493467d3..4cf71aefa75 100644 --- a/docs/diagrams/AddFinalState.puml +++ b/docs/diagrams/AddFinalState.puml @@ -1,35 +1,35 @@ @startuml title Final state -object Root +object ":Root" as Root -object group1 { +object ":Group" as group1 { name = "group 1" id = grp-001 } -object group2 { +object ":Group" as group2 { name = "group 2" - id = grp-001 + id = grp-002 } -object student1 { +object ":Student" as student1 { name = "John" id = 1234Y - email = "IloveDrawingDiagrams@gmail.com" + email = "ilovedrawingdiagrams@gmail.com" phone = "09881765" address = "NUS" } -object student2 { +object ":Student" as student2 { name = "Mary" id = 9876A - email = "IloveCoding@gmail.com" + email = "ilovecoding@gmail.com" phone = "12345678" address = "Malaysia" } -object student3 { +object ":Student" as student3 { name = "Bob" id = 2000Y email = "bobby@example.com" diff --git a/docs/diagrams/AddInitialState.puml b/docs/diagrams/AddInitialState.puml index 5affab9fcdf..2ad4c71f062 100644 --- a/docs/diagrams/AddInitialState.puml +++ b/docs/diagrams/AddInitialState.puml @@ -1,30 +1,30 @@ @startuml title Initial state -object Root +object ":Root" as Root -object group1 { +object ":Group" as group1 { name = "group 1" id = grp-001 } -object group2 { +object ":Group" as group2 { name = "group 2" - id = grp-001 + id = grp-002 } -object student1 { +object ":Student" as student1 { name = "John" id = 1234Y - email = "IloveDrawingDiagrams@gmail.com" + email = "ilovedrawingdiagrams@gmail.com" phone = "09881765" address = "NUS" } -object student2 { +object ":Student" as student2 { name = "Mary" id = 9876A - email = "IloveCoding@gmail.com" + email = "ilovecoding@gmail.com" phone = "12345678" address = "Malaysia" } diff --git a/docs/diagrams/CreateDeadlineCommandSequenceDiagram.puml b/docs/diagrams/CreateDeadlineCommandSequenceDiagram.puml index adf929f7a02..768e6887d87 100644 --- a/docs/diagrams/CreateDeadlineCommandSequenceDiagram.puml +++ b/docs/diagrams/CreateDeadlineCommandSequenceDiagram.puml @@ -8,41 +8,41 @@ end box box Model MODEL_COLOR_T1 participant ":ModelManager" as ModelManagerStatic MODEL_COLOR -participant "opr:TaskOperation" as TaskOperation MODEL_COLOR +participant "opr:ChildOperation" as ChildOperation MODEL_COLOR participant ":Student" as Student MODEL_COLOR end box [-> CreateDeadlineCommand : execute() activate CreateDeadlineCommand -CreateDeadlineCommand -> ModelManagerStatic : taskOperation(path) +CreateDeadlineCommand -> ModelManagerStatic : groupChildOperation(path) activate ModelManagerStatic -create TaskOperation -ModelManagerStatic -> TaskOperation -activate TaskOperation +create ChildOperation +ModelManagerStatic -> ChildOperation +activate ChildOperation -TaskOperation --> ModelManagerStatic : opr -deactivate TaskOperation +ChildOperation --> ModelManagerStatic : opr +deactivate ChildOperation ModelManagerStatic --> CreateDeadlineCommand :opr deactivate ModelManagerStatic -CreateDeadlineCommand -> TaskOperation : addAllTask(task) -activate TaskOperation +CreateDeadlineCommand -> ChildOperation : addAllTask(task) +activate ChildOperation loop for each student in group - TaskOperation -> Student : addTask(task) + ChildOperation -> Student : addTask(task) activate Student - Student --> TaskOperation + Student --> ChildOperation deactivate Student end -TaskOperation --> CreateDeadlineCommand +ChildOperation --> CreateDeadlineCommand -destroy TaskOperation +destroy ChildOperation [<--CreateDeadlineCommand destroy CreateDeadlineCommand diff --git a/docs/diagrams/DeadlineFinalState.puml b/docs/diagrams/DeadlineFinalState.puml index 2c14e50637a..93532a4a6ec 100644 --- a/docs/diagrams/DeadlineFinalState.puml +++ b/docs/diagrams/DeadlineFinalState.puml @@ -1,24 +1,24 @@ @startuml -title Group 1's Initial state +title Group 1's Final state -object group1 +object ":Group" as group1 -object student1 { +object ":Student" as student1 { name = "ben" id = 1212A } -object student2 { +object ":Student" as student2 { name = "jerry" id = 2727B } -object deadline1 { +object ":Deadline" as deadline1 { description = "Assignment 1" deadline = 2023-12-12 2359 } -object deadline2 { +object ":Deadline" as deadline2 { description = "Assignment 1" deadline = 2023-12-12 2359 } diff --git a/docs/diagrams/DeadlineInitialState.puml b/docs/diagrams/DeadlineInitialState.puml index a15bb506773..dce526c5b0c 100644 --- a/docs/diagrams/DeadlineInitialState.puml +++ b/docs/diagrams/DeadlineInitialState.puml @@ -1,19 +1,19 @@ @startuml title Group 1's Initial state -object group1 +object ":Group" as group1 -object student1 { +object ":Student" as student1 { name = "ben" id = 1212A } -object student2 { +object ":Student" as student2 { name = "jerry" id = 2727B } -object deadline1 { +object ":Deadline" as deadline1 { description = "Assignment 1" deadline = 2023-12-12 2359 } diff --git a/docs/diagrams/DeleteTaskSequenceLogicDiagram.puml b/docs/diagrams/DeleteTaskSequenceLogicDiagram.puml index a37a54fdaf9..512d27fe9ff 100644 --- a/docs/diagrams/DeleteTaskSequenceLogicDiagram.puml +++ b/docs/diagrams/DeleteTaskSequenceLogicDiagram.puml @@ -35,6 +35,7 @@ deactivate DeleteTaskCommand DeleteTaskCommandParser --> ProfBookParser : d deactivate DeleteTaskCommandParser + 'Hidden arrow to position the destroy marker below the end of the activation bar. DeleteTaskCommandParser -[hidden]-> ProfBookParser destroy DeleteTaskCommandParser @@ -43,6 +44,8 @@ ProfBookParser --> LogicManager : d deactivate ProfBookParser LogicManager -> DeleteTaskCommand : execute("state") +activate DeleteTaskCommand + ref over DeleteTaskCommand Execution of DeleteTaskCommand end ref diff --git a/docs/diagrams/EditCommandSequenceDiagram.puml b/docs/diagrams/EditCommandSequenceDiagram.puml index 330b5fef9da..ab43bb48e10 100644 --- a/docs/diagrams/EditCommandSequenceDiagram.puml +++ b/docs/diagrams/EditCommandSequenceDiagram.puml @@ -29,7 +29,7 @@ deactivate RootChildOperation ModelManagerStatic --> EditCommand :opr deactivate ModelManagerStatic -EditCommand -> RootChildOperation : editChild(groupId, editedField) +EditCommand -> RootChildOperation : editChild(groupId, editDescriptor) activate RootChildOperation RootChildOperation -> oldGroup : getName() diff --git a/docs/diagrams/EditFinalState.puml b/docs/diagrams/EditFinalState.puml index 19e14cebfa5..c32a41c3a05 100644 --- a/docs/diagrams/EditFinalState.puml +++ b/docs/diagrams/EditFinalState.puml @@ -1,36 +1,38 @@ @startuml -title Initial state +title Final state -object Root +object ":Root" as Root -object group2 { - name = "group 2" - id = grp-001 -} - -object group3 { +object ":Group" as group3 { name = "group 1" id = grp-003 } -object student1 { +object ":Group" as group2 { + name = "group 2" + id = grp-002 +} + + +object ":Student" as student1 { name = "John" id = 1234Y - email = "IloveDrawingDiagrams@gmail.com" + email = "ilovedrawingdiagrams@gmail.com" phone = "09881765" address = "NUS" } -object student2 { +object ":Student" as student2 { name = "Mary" id = 9876A - email = "IloveCoding@gmail.com" + email = "ilovecoding@gmail.com" phone = "12345678" address = "Malaysia" } Root -down-> group3 Root -down-> group2 + group3 -down-> student1 group2 -down-> student2 @enduml diff --git a/docs/diagrams/EditGroupActivityDiagram.puml b/docs/diagrams/EditGroupActivityDiagram.puml index 11f8647a231..46e48b7cfc8 100644 --- a/docs/diagrams/EditGroupActivityDiagram.puml +++ b/docs/diagrams/EditGroupActivityDiagram.puml @@ -26,6 +26,6 @@ else ([new id already used]) stop endif :Remove old group; -:Add new Group; +:Add new group; stop @enduml diff --git a/docs/diagrams/EditIntermediateState.puml b/docs/diagrams/EditIntermediateState.puml index 94ebc7a3feb..0e0f6baa460 100644 --- a/docs/diagrams/EditIntermediateState.puml +++ b/docs/diagrams/EditIntermediateState.puml @@ -1,35 +1,35 @@ @startuml -title Initial state +title Intermediate state -object Root +object ":Root" as Root -object group1 { +object ":Group" as group1 { name = "group 1" id = grp-001 } -object group2 { +object ":Group" as group2 { name = "group 2" - id = grp-001 + id = grp-002 } -object group3 { +object ":Group" as group3 { name = "group 1" id = grp-003 } -object student1 { +object ":Student" as student1 { name = "John" id = 1234Y - email = "IloveDrawingDiagrams@gmail.com" + email = "ilovedrawingdiagrams@gmail.com" phone = "09881765" address = "NUS" } -object student2 { +object ":Student" as student2 { name = "Mary" id = 9876A - email = "IloveCoding@gmail.com" + email = "ilovecoding@gmail.com" phone = "12345678" address = "Malaysia" } diff --git a/docs/diagrams/MoveStudentSequenceDiagram.puml b/docs/diagrams/MoveStudentSequenceDiagram.puml index 927bd2c2285..5e63a16df12 100644 --- a/docs/diagrams/MoveStudentSequenceDiagram.puml +++ b/docs/diagrams/MoveStudentSequenceDiagram.puml @@ -43,6 +43,19 @@ deactivate ChildOperation2 ModelManagerStatic --> command : destOpr deactivate ModelManagerStatic +command -> ChildOperation2 : addChild(id, student) +activate ChildOperation2 + +ChildOperation2 -> DestGroup : addChild(id, student) +activate DestGroup + +DestGroup --> ChildOperation2 +deactivate DestGroup + +ChildOperation2 --> command +destroy ChildOperation2 + + command -> ChildOperation : deleteChild(id) activate ChildOperation @@ -55,17 +68,6 @@ deactivate SourceGroup ChildOperation --> command destroy ChildOperation -command -> ChildOperation2 : addChild(id, student) -activate ChildOperation2 - -ChildOperation2 -> DestGroup : addChild(id, student) -activate DestGroup - -DestGroup --> ChildOperation2 -deactivate DestGroup - -ChildOperation2 --> command -destroy ChildOperation2 [<--command deactivate command From f3295a66aa09b041f8ed2f0cb68dc3f0c8fe8f53 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 02:32:37 +0800 Subject: [PATCH 11/31] Add line breaks --- docs/DeveloperGuide.md | 41 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 38 insertions(+), 3 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index b72857fbdb6..a064dccd041 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -9,6 +9,8 @@ pageNav: 3 +
+ ## **Introduction** ProfBook is a tool tailored to helping specifically CS2103T professors and Teaching Assistants(TA) in managing @@ -102,6 +104,8 @@ implementation of a component), as illustrated in the (partial) class diagram be The sections below give more details of each component. +
+ ### UI component The **API** of this component is specified @@ -129,6 +133,8 @@ The `UI` component, displays [`Displayable`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/ui/Displayable.java) object residing in the `Model`. +
+ ### Logic component **API** : [`Logic.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/src/main/java/seedu/address/logic/Logic.java) @@ -174,6 +180,8 @@ How the parsing works: * All `XYZCommandParser` classes (e.g., `EditCommandParser`, `HelpCommandParser`, ...) 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/AY2324S1-CS2103T-W15-2/tp/tree/master/src/main/java/seedu/address/model/Model.java) @@ -205,6 +213,8 @@ The diagram above shows how the folder structure is implemented in ProfBook, * We also created a wrapper class (e.g. `ChildrenAndTaskListManager`) for classes that require both of those aforementioned functionalities (e.g, `Group` and potentially in the future `TutorialSlot`). +
+ ##### Task sub-package **API** : [`TaskListManager.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/model/task/TaskListManager.java) @@ -241,6 +251,8 @@ to check that the Operation required matches with the intended effect of the Com +
+ #### Path sub-package **API** : [`Path.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/model/path/Path.java) @@ -266,6 +278,8 @@ Here is a class diagram for the path package: `RelativePath` representing `../grp-002`, the resolve method will return the `AbsolutePath` representing the path `~/grp-002`. +
+ ### Storage component **API** : [`ProfBookStorageManager.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/storage/ProfBookStorageManager.java) @@ -284,6 +298,8 @@ The `Storage` component, Classes used by multiple components are in the `seedu.addressbook.commons` package. +
+ -------------------------------------------------------------------------------------------------------------------- ## **Implementation** @@ -344,6 +360,8 @@ To further illustrate our folder structure, we have prepared this diagram * Pros: Very easy to implement. * Cons: Finding a student/group is very inefficient, updating references is also a hassle. +
+ ### Adding a student/group #### Implementation @@ -409,6 +427,8 @@ Below is an activity diagram showing the general activity of the add student com * Cons: All information about a student/group must be readily present before creating it, which is not always the case. +
+ ### Creating a task #### Implementation @@ -515,7 +535,9 @@ This is an activity diagram showing the general activity of the add deadline com * **Alternative 2**: Yes. * Pros: Able to change all task's state in one short. * Cons: Unable to uniquely change a specific tasks without affecting other task, aliasing issue. - + +
+ ### Editing information #### Implementation @@ -586,6 +608,8 @@ This is an activity diagram showing the general activity of the edit command. * Pros: Easier to implement, it is also more intuitive for users * Cons: More commands for user to remember, future additions would prove to be a hassle +
+ ### Moving students between groups #### Implementation @@ -610,6 +634,8 @@ Given below is an example usage scenario whereby a student is moved from group1 +
+ -------------------------------------------------------------------------------------------------------------------- ## Proposed future features @@ -661,6 +687,7 @@ Currently, our hierarchy only extends to `Group`. To serve our target users bett Implementing this is rather easy as `TutorialSlot` would in theory be almost identical to the implementation of `Group`, all `TutorialSlot` have to do is just extend from `ChildrenAndTaskListManager`. +
-------------------------------------------------------------------------------------------------------------------- @@ -674,6 +701,8 @@ all `TutorialSlot` have to do is just extend from `ChildrenAndTaskListManager`. -------------------------------------------------------------------------------------------------------------------- +
+ ## **Appendix: Requirements** ### Product scope @@ -732,6 +761,8 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli | `*` | Expert user | make the program support customizable templates for tutorials and student profiles | I can make it more aesthetically pleasing | | `*` | Expert user | make use of the feature to archive certain task | I can keep track of the history and not focus on unimportant task. | +
+ ### Use cases (For all use cases below, the **System** is the `ProfBook` and the **Professor** is the `user`, unless specified @@ -1168,6 +1199,8 @@ otherwise) Use case resumes at step 1. +
+ ### Non-Functional Requirements **Technical requirements:** @@ -1193,6 +1226,8 @@ otherwise) 1. Should work without an internet connection. 2. Should be able to support frequent updating of data. +
+ ### Glossary * **Mainstream OS**: Windows, Linux, Unix, OS-X. @@ -1213,7 +1248,7 @@ otherwise) * **ToDo Task**: A type of task with no specific deadline, representing things to do. * **Task Index**: Index of task shown on display of ProfBook after using `cat` command. - +
-------------------------------------------------------------------------------------------------------------------- ## **Appendix: Instructions for manual testing** @@ -1558,7 +1593,7 @@ need to change according to your current directory. More information can be foun - Test case: `clear` Expected: An empty `profbook.json` file like [here](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/docs/sample/empty.json)). -
+
-------------------------------------------------------------------------------------------------------------------- From 6c43cb1a88872fd9a16c3dd8ddbb2c95548358c2 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 02:36:01 +0800 Subject: [PATCH 12/31] Add line breaks --- docs/DeveloperGuide.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index a064dccd041..3ab667a77d7 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -55,6 +55,8 @@ Refer to the guide [_Setting up and getting started_](SettingUp.md). PlantUML, the lifeline reaches the end of diagram. +
+ ### Architecture From 2575cee8ba71affed4017ca02dd6d0d14a7081c5 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 02:40:57 +0800 Subject: [PATCH 13/31] Add line breaks --- docs/DeveloperGuide.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 3ab667a77d7..686e558b7ae 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -106,8 +106,6 @@ implementation of a component), as illustrated in the (partial) class diagram be The sections below give more details of each component. -
- ### UI component The **API** of this component is specified @@ -337,6 +335,8 @@ the `IChildElement` interface. This was done to reduce repeated code while intro +
+ To further illustrate our folder structure, we have prepared this diagram @@ -407,6 +407,8 @@ Given below is an example usage scenario on how an existing user can create a st +
+ This sequence diagram shows the general flow of the `CreateStudentCommand`, for more information on each specific component, do head over to their respective documentation. @@ -501,6 +503,7 @@ diagram for adding a deadline task to a *single* student can be found in the `Mo +
This is an activity diagram showing the general activity of the add deadline command. From a9a01f17af2732ce01c91c875145d76d6f6627e8 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 02:46:18 +0800 Subject: [PATCH 14/31] Add line breaks --- docs/DeveloperGuide.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 686e558b7ae..b17e0bd544e 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -143,6 +143,8 @@ Here's a (partial) class diagram of the `Logic` component: +
+ The sequence diagram below illustrates the interactions within the `Logic` component, taking `execute("rmt 1")` API call as an example. `rmt` is the command word for DeleteTaskCommand class. By executing the command `rmt 1`, tha task with index number 1 @@ -597,6 +599,8 @@ as `Student`. +
+ This is an activity diagram showing the general activity of the edit command. @@ -1254,7 +1258,7 @@ otherwise) * **Task Index**: Index of task shown on display of ProfBook after using `cat` command.
--------------------------------------------------------------------------------------------------------------------- + ## **Appendix: Instructions for manual testing** From 052ae4d473b6392e77d009db4ae5481bf5a3f230 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 02:52:16 +0800 Subject: [PATCH 15/31] Add line breaks --- docs/DeveloperGuide.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index b17e0bd544e..9b1378ca0c1 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -160,6 +160,8 @@ will be deleted. +
+ How the `Logic` component works: 1. When `Logic` is called upon to execute a command, it is passed to an `ProfBookParser` object which in turn creates a @@ -190,7 +192,6 @@ How the parsing works: - The `Model` component, * stores the ProfBook data i.e., all `Root, Group and Student` objects (which are contained in a @@ -230,6 +231,8 @@ How the `Task` component work: * All tasks extend from the abstract class `Task`, we did this for extensibility. So in the future, should we decide to implement a new type of task, all we have to do is extend from `Task`. +
+ The sequence diagram below illustrates the interactions within the `Model` component, taking an execution of a `CreateTodoCommand` as example. As the behaviour of `CreateTodoCommand` is rather dynamic, in our example, we shall be narrowing our scope to adding a todo tasks to a specified group, g. From 90ede1982b35f830b2d17fa53489410366ec45e9 Mon Sep 17 00:00:00 2001 From: Nereus Ng Wei Bin Date: Mon, 13 Nov 2023 10:42:02 +0800 Subject: [PATCH 16/31] Fix wrong link --- docs/DeveloperGuide.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 9b1378ca0c1..24fbd3d3590 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -68,8 +68,8 @@ 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 +classes [`Main`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/Main.java) +and [`MainApp`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/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. From f5f0f7e3da6fe8ed54361bc530745a47a02850de Mon Sep 17 00:00:00 2001 From: Nereus Ng Wei Bin Date: Mon, 13 Nov 2023 10:48:13 +0800 Subject: [PATCH 17/31] Fix wrong method name --- docs/diagrams/ArchitectureSequenceDiagram.puml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/diagrams/ArchitectureSequenceDiagram.puml b/docs/diagrams/ArchitectureSequenceDiagram.puml index ab6c49bd054..2262ac60e1d 100644 --- a/docs/diagrams/ArchitectureSequenceDiagram.puml +++ b/docs/diagrams/ArchitectureSequenceDiagram.puml @@ -14,13 +14,13 @@ activate ui UI_COLOR ui -[UI_COLOR]> logic : execute("rm 0001Y") activate logic LOGIC_COLOR -logic -[LOGIC_COLOR]> model : deletePerson(p) +logic -[LOGIC_COLOR]> model : remove student with id 0001Y activate model MODEL_COLOR model -[MODEL_COLOR]-> logic deactivate model -logic -[LOGIC_COLOR]> storage : saveAddressBook(addressBook) +logic -[LOGIC_COLOR]> storage : saveProfBook(root) activate storage STORAGE_COLOR storage -[STORAGE_COLOR]> storage : Save to file From 1452ed648aff1398e5e1989e157813427a05dd1d Mon Sep 17 00:00:00 2001 From: Nereus Ng Wei Bin Date: Mon, 13 Nov 2023 10:51:02 +0800 Subject: [PATCH 18/31] Replace exact path with displayPath --- docs/diagrams/DeleteTaskSequenceModelDiagram.puml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/diagrams/DeleteTaskSequenceModelDiagram.puml b/docs/diagrams/DeleteTaskSequenceModelDiagram.puml index 40eb4319a71..201bc7910d4 100644 --- a/docs/diagrams/DeleteTaskSequenceModelDiagram.puml +++ b/docs/diagrams/DeleteTaskSequenceModelDiagram.puml @@ -16,7 +16,7 @@ mainframe **sd** Execution of DeleteTaskCommand activate DeleteTaskCommand -DeleteTaskCommand -> ModelManagerStatic : taskOperation(new Path("~/grp-001")) +DeleteTaskCommand -> ModelManagerStatic : taskOperation(displayPath) activate ModelManagerStatic create TaskOperation From 7635ec9a199127cea6f5e343c364b3ea4d3a4237 Mon Sep 17 00:00:00 2001 From: Nereus Ng Wei Bin Date: Mon, 13 Nov 2023 11:07:48 +0800 Subject: [PATCH 19/31] Fix wrong class name --- docs/DeveloperGuide.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 24fbd3d3590..3308f13afb7 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -241,8 +241,8 @@ we shall be narrowing our scope to adding a todo tasks to a specified group, g. How the `Model` component works: -* Depending on the nature of the command, a static method is called to generate a `TaskOperation` or - a `ChildrenOperation` Object that acts as an interface manipulate the Model +* Depending on the nature of the command, the corresponding method is called to generate a `TaskOperation` or + a `ChildOperation` object that acts as an interface manipulate the model * In this case, a `TaskOperation` object is created. This object would store all the necessary information to make changes directly on the correct state. * The `Command` instance calls the required method in the `TaskOperation` object which results in the `TaskOperation` @@ -250,9 +250,9 @@ How the `Model` component works: -**Note:** For ChildrenOperation, ModelManager provides more specific static factory methods (e.g., GroupChildOperation, -RootChildOperation) to generate the `ChildOperation` object. It is implemented this way so that ModelManager is able -to check that the Operation required matches with the intended effect of the Command object's Execution. +**Note:** For `ChildrenOperation`, `ModelManager` provides more specific factory methods (e.g., `groupChildOperation`, +`rootChildOperation`) to generate the `ChildOperation` object. It is implemented this way so that `ModelManager` is able +to check that the operation required matches with the intended effect of the `Command` object's execution. @@ -280,7 +280,7 @@ Here is a class diagram for the path package: * `AbsolutePath` represents an absolute path within the system and strictly commences with the `~` element. * The `resolve` method is crucial to resolve a `RelativePath` and return the resolved path in `AbsolutePath` type. * e.g. Consider an `AbsolutePath` represents `~/grp-001/0001A`. If the `resolve` method is called with the - `RelativePath` representing `../grp-002`, the resolve method will return the `AbsolutePath` representing the path + `RelativePath` representing `../../grp-002`, the resolve method will return the `AbsolutePath` representing the path `~/grp-002`.
@@ -400,7 +400,7 @@ Given below is an example usage scenario on how an existing user can create a st 3. The parser would retrieve all the relevant information from the input and encapsulates it in a `CreateStudentCommand`. 4. This command would first do these checks: * checks if the specified path contains the group. This is done via the `ModelManager::hasGroup` method. - * checks if the specified path is a valid student path. This is done via the `Path::isStudentDirectory` method. + * checks if the specified path is a valid student path. This is done via the `AbsolutePath::isStudentDirectory` method. * checks if adding the student would result in a duplicate within whole of ProfBook, ie if the student id is already taken. This is done via the `ModelManager::hasStudentWithId` method. 5. In this case, if the input was `touch ~/grp-001/1234Y ...` or `touch ~/grp-001/9876A ...` a `CommandException` will @@ -422,7 +422,7 @@ component, do head over to their respective documentation. Below is an activity diagram showing the general activity of the add student command. - + #### Design Consideration @@ -488,7 +488,7 @@ Given below is an example usage scenario on how an existing user can add Deadlin 3. The parser would retrieve all the relevant information from the input and encapsulate it in a `CreateDeadlineCommand`. 4. This command would first - * check if the specified path is a valid and present group path. This is done via `Path::isGroupDirectory` method. + * check if the specified path is a valid and present group path. This is done via `AbsolutePath::isGroupDirectory` method. * check if all students in the group already has the task. This is done via `GroupChildOperation::checkIfAllChildrenHaveTask` method. 5. If all checks out, the command would create a new `Deadline` instance and add the deadline to all student that do not @@ -512,7 +512,7 @@ diagram for adding a deadline task to a *single* student can be found in the `Mo This is an activity diagram showing the general activity of the add deadline command. - + #### Design Consideration @@ -554,8 +554,8 @@ This is an activity diagram showing the general activity of the add deadline com Due to the dynamic need of our target users, professors and TAs, there is a need for our edit command to be equally dynamic. Our edit command need to be general enough to allow the users to edit both students and groups. This is done by checking -the type of directory that was passed in. This is done through the `Path::isGroupDirectory` -and `Path::isStudentDirectory` method. +the type of directory that was passed in. This is done through the `AbsolutePath::isGroupDirectory` +and `AbsolutePath::isStudentDirectory` method. @@ -567,13 +567,13 @@ for `path` package. This then allows parser to check for the validity of the giv As the implementation for editing students and groups is similar, for simplicity, I would be going through implementation of editing a group. -The following methods of `ModelManager`, `Path` and `RootChildOperation` are used: +The following methods of `ModelManager`, `AbsolutePath` and `RootChildOperation` are used: 1. `ModelManager::rootChildOperation` - To generate an operation class with logic specific to the current root. 2. `ModelManager::hasGroupWithId` - To check if editing results in a duplicate. 3. `RootChildOperation::editChild` - To edit the group with the values extracted from parser. -4. `Path::isGroupDirectory` - To check if the path leads to a group directory. -5. `Path::isStudentDirectory` - To check if the path leads to a student directory. +4. `AbsolutePath::isGroupDirectory` - To check if the path leads to a group directory. +5. `AbsolutePath::isStudentDirectory` - To check if the path leads to a student directory. Given below is an example usage scenario on how an existing user can edit the name of a group @@ -668,7 +668,7 @@ improve this validation by enforcing a tighter validation. This can be achieved common phone extensions to their length and then enforcing that the phone number be of that length. This allows our users to have the peace of mind that the phone number is validated and robust enough to handle international numbers. -### Better marking and un-marking validation (// TODO low priority, remove when needed ) +### Better marking and un-marking validation Currently, our application does not check if the tasks are marked or unmarked before any operation. This results in users being able to mark/un-mark tasks infinitely, this is not intuitive and may mislead some users. Hence, we plan to @@ -683,7 +683,7 @@ and only if their ids are identical. This means that two students with identical considered different in ProfBook, needless to say this does not reflect requirements in the real world. Therefore, we plan to revamp our duplication checking for students by checking for equality between their phone number and email. -### More descriptive error message (// TODO low priority, remove when needed ) +### More descriptive error message Currently, while our application tries to output a descriptive and apt message for each error, we have received feedback that some of our error message could be more descriptive. One such example is trying to edit the root `~/` directory or From 6453d84851b9bfd8c6863d6454cd6b221f0b1dfd Mon Sep 17 00:00:00 2001 From: Nereus Ng Wei Bin Date: Mon, 13 Nov 2023 11:15:25 +0800 Subject: [PATCH 20/31] Fix manual testing error --- docs/DeveloperGuide.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 3308f13afb7..0ddd2f2d98c 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -1303,7 +1303,7 @@ need to change according to your current directory. More information can be foun - Creating a new group, - - Prerequisites: There exist a group with GroupId `grp-001`.
+ - Prerequisites: No existing group with GroupId grp-001.
Test case: `mkdir grp-001 --name Amazing Group1`
Expected: A new group will be added to the list in the bottom output box, with name `Amazing Group1` and GroupId `grp-001`. @@ -1326,7 +1326,7 @@ need to change according to your current directory. More information can be foun Test case: `touch ~/grp-001/0199Y --name Mary --email mary@gmail.com --phone 65412987 --address 4 Loyang Walk Loyang Industrial Estate`
Expected: The student with id `0199Y` will be added to `grp-001`. - - Prerequisites: ProfBook does not contain a student with id`0123Y`. + - Prerequisites: ProfBook does not contain a student with id`0123Y`.
Test case: `touch ~/grp-001/0123Y --name Mary`
Expected: The student with id `0123Y` will be added to `grp-001`. @@ -1592,17 +1592,17 @@ need to change according to your current directory. More information can be foun - Prerequisites: Place ProfBook.jar in an empty home folder. Perform the following step in the root directory. - - Test case: `todo grp-001/0001Y --desc Assignment One` + - Test case: `todo grp-001/0001Y --desc Assignment One`
Expected: `profbook.json` appears in data folder inside home folder. Student with name `Tejas` has a field history in profbook.json whereas the other students do not. Sample output [here](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/docs/sample/addTodo.json). - - Test case: `rm grp-001/0001Y` + - Test case: `rm grp-001/0001Y`
Expected: `profbook.json` is updated with `Tejas removed`. Sample output [here](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/docs/sample/removeTejas.json). - Clearing the save file. - Prerequisites: Have `profbook.json` in the data folder. Perform the previous step if the file isn’t there. - - Test case: `clear` + - Test case: `clear`
Expected: An empty `profbook.json` file like [here](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/docs/sample/empty.json)).
From ee8bfa2969dba16aec751b6c92bbc9dae47fc37b Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 13:49:21 +0800 Subject: [PATCH 21/31] Push to upstream --- docs/DeveloperGuide.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 9b1378ca0c1..125fd39e2a9 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -210,7 +210,7 @@ The `Model` component, The diagram above shows how the folder structure is implemented in ProfBook, * The hierarchy is as such: `Root` -> `Group` -> `Student`. -* As many of the operations are repeated (e.g. tasks operations and children operation), we decided to abstract out +* As many of the operations are repeated (e.g. tasks operations and children operations), we decided to abstract out these logic into their own classes which is represented by `TaskListManager` and `ChildrenManager` respectively. * `ChildrenManager` manages the children which is of type `IChildElement`. * We also created a wrapper class (e.g. `ChildrenAndTaskListManager`) for classes that require both of those @@ -224,7 +224,7 @@ The diagram above shows how the folder structure is implemented in ProfBook, -How the `Task` component work: +How the `Task` component works: * As mentioned earlier, `TaskListManager` encapsulates the logic required to maintain a TaskList, this logic is utilised heavily in the ProfBook component. @@ -242,7 +242,7 @@ we shall be narrowing our scope to adding a todo tasks to a specified group, g. How the `Model` component works: * Depending on the nature of the command, a static method is called to generate a `TaskOperation` or - a `ChildrenOperation` Object that acts as an interface manipulate the Model + a `ChildrenOperation` object that acts as an interface manipulate the Model * In this case, a `TaskOperation` object is created. This object would store all the necessary information to make changes directly on the correct state. * The `Command` instance calls the required method in the `TaskOperation` object which results in the `TaskOperation` @@ -287,7 +287,7 @@ Here is a class diagram for the path package: ### Storage component -**API** : [`ProfBookStorageManager.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/storage/ProfBookStorageManager.java) +**API** : [`Storage.java`](https://github.com/AY2324S1-CS2103T-W15-2/tp/blob/master/src/main/java/seedu/address/storage/Storage.java) @@ -321,7 +321,7 @@ to capture unique functionality of the different parties at play. In our current hierarchy, `Root` -> `Group` -> `Student`, `Student` and `Group` are required to manage tasks whereas `Root` and `Group` are required to manage children. The `Model` component briefly mentioned this implementation, -but I will delve into it more comprehensively. +but I will delve into it more comprehensively in this implementation. We first created interfaces to represent the required logic for each of the manager, namely `IChildrenManager` and `ITaskListManager`. Then we created concrete classes such as `ChildrenManager` and `TaskListManager` to encapsulate @@ -355,7 +355,7 @@ To further illustrate our folder structure, we have prepared this diagram * Pros: Easier to implement relatively to the tree representation. * Cons: * Harder to maintain the hierarchy, search for items and load items from storage. - * States are more coupled + * States are more coupled. **Aspect: How store reference to children** From 2e8aaa036d6036e82e57e32671ac900045310029 Mon Sep 17 00:00:00 2001 From: Nereus Ng Wei Bin Date: Mon, 13 Nov 2023 13:58:33 +0800 Subject: [PATCH 22/31] Fix bug --- docs/DeveloperGuide.md | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 04512660040..8118a4ac2d0 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -378,13 +378,13 @@ implementation for the harder one, which is creating a student. Should you have us. Most of the logic for creating a student is encapsulated in the `CreateStudentCommand` class, this class utilise -the `GroupChildOperation` class to add the student to the group and the `Model` class to check for duplicates. -The following methods of `ModelManager` and `GroupChildOperation` are used: +the `ChildOperation` class to add the student to the group and the `Model` class to check for duplicates. +The following methods of `ModelManager` and `ChildOperation` are used: 1. `ModelManager::groupChildOperation` - To generate an operation class specific to the current group, it also checks for the validity and presence of the specified group. 2. `ModelManager::hasStudentWithId` - To check if the new student id is unique. -3. `GroupChildOperation::addChild` - To add the current student into the group. +3. `ChildOperation::addChild` - To add the current student into the group. Given below is an example usage scenario on how an existing user can create a student. @@ -406,8 +406,8 @@ Given below is an example usage scenario on how an existing user can create a st 5. In this case, if the input was `touch ~/grp-001/1234Y ...` or `touch ~/grp-001/9876A ...` a `CommandException` will be thrown. 6. If all checks out, the command would create a new student and add the student to the `Model`. This addition is done - through getting a `GroupChildOperation` class from the `Model::groupChildOperation` method. This would ensure - the path to the group is present and valid. The student is added through the `GroupChildOperation::addChild` method. + through getting a `ChildOperation` class from the `Model::groupChildOperation` method. This would ensure + the path to the group is present and valid. The student is added through the `ChildOperation::addChild` method. 7. It should look something like this. @@ -462,14 +462,14 @@ tasks can be found at the `Model` component. Most of the logic for creating a task is encapsulated in the `CreateDeadlineCommand` class, this class utilises -the `GroupChildOperation` class to add the Deadline to the group and check for duplicates. -The following methods of `ModelManager` and `GroupChildOperation` are used: +the `ChildOperation` class to add the Deadline to the group and check for duplicates. +The following methods of `ModelManager` and `ChildOperation` are used: 1. `ModelManager::groupChildOperation` - To generate an operation class specific to the current group, it also checks for the validity and presence of the specified group. -2. `GroupChildOperation::addAllTasks` - To add the tasks to all student within a group, it also checks if it is a +2. `ChildOperation::addAllTasks` - To add the tasks to all student within a group, it also checks if it is a duplicate task before adding. -3. `GroupChildOperation::checkIfAllChildrenHaveTask` - To check if all children within a group already has the task. +3. `ChildOperation::checkIfAllChildrenHaveTask` - To check if all children within a group already has the task. It is important to note that for adding a task to a singular group/student, the operation class `TaskOperation` is used instead, a sequence diagram illustrating this can be found in the `Model` component. @@ -490,11 +490,11 @@ Given below is an example usage scenario on how an existing user can add Deadlin 4. This command would first * check if the specified path is a valid and present group path. This is done via `AbsolutePath::isGroupDirectory` method. * check if all students in the group already has the task. This is done - via `GroupChildOperation::checkIfAllChildrenHaveTask` method. + via `ChildOperation::checkIfAllChildrenHaveTask` method. 5. If all checks out, the command would create a new `Deadline` instance and add the deadline to all student that do not already have the aforementioned task. This is done - through getting a `GroupChildOperation` class from the `Model::groupChildOperation` method. The tasks are then - added through the `GroupChildOperation::addTaskToAllStudent` method. For each student, the method would check if the + through getting a `ChildOperation` class from the `Model::groupChildOperation` method. The tasks are then + added through the `ChildOperation::addTaskToAllStudent` method. For each student, the method would check if the task is already present, if not it would add the task. 6. It should look something like this. @@ -567,11 +567,11 @@ for `path` package. This then allows parser to check for the validity of the giv As the implementation for editing students and groups is similar, for simplicity, I would be going through implementation of editing a group. -The following methods of `ModelManager`, `AbsolutePath` and `RootChildOperation` are used: +The following methods of `ModelManager`, `AbsolutePath` and `ChildOperation` are used: 1. `ModelManager::rootChildOperation` - To generate an operation class with logic specific to the current root. 2. `ModelManager::hasGroupWithId` - To check if editing results in a duplicate. -3. `RootChildOperation::editChild` - To edit the group with the values extracted from parser. +3. `ChildOperation::editChild` - To edit the group with the values extracted from parser. 4. `AbsolutePath::isGroupDirectory` - To check if the path leads to a group directory. 5. `AbsolutePath::isStudentDirectory` - To check if the path leads to a student directory. @@ -587,7 +587,7 @@ Given below is an example usage scenario on how an existing user can edit the na 4. The fields to be edited is then stored in an `EditGroupDescriptor` instance. (For student it would be stored in an `EditStudentDescriptor`) 5. If the id is being edited, `ModelManager::hasGroupWithId` is called to ensure it does not result in a duplicate. -6. The `RootChildOperation::editChild` then makes a copy of the existing group while updating the values found in +6. The `ChildOperation::editChild` then makes a copy of the existing group while updating the values found in the `EditGroupDescriptor`. @@ -630,7 +630,7 @@ Initially, implementing this feature seemed like a daunting task. However, after realised that implementing move was quite straight forward. Moving a student can be easily done by removing the student's reference from its current group by removing its key-value pair from the group's `Map` field. Then to complete the move, the student is added to the target group by adding it into the target -group's `Map` field. All of this operation is facilitated by the `GroupChildOperation` class. +group's `Map` field. All of this operation is facilitated by the `ChildOperation` class. Given below is an example usage scenario whereby a student is moved from group1 to group2. @@ -639,8 +639,8 @@ Given below is an example usage scenario whereby a student is moved from group1 user would execute the following command: `mv ~/grp-001/1234Y ~/grp-002`. 3. The parser would extract the relevant information and creates a `MoveStudentCommand` instance. 4. The command would check that path to the student and target group is valid and present. -5. Command would then add the student to the target group via the `GroupChildOperation::addChild` method. The old - reference is removed via the `GroupChildOperation::deleteChild` method. +5. Command would then add the student to the target group via the `ChildOperation::addChild` method. The old + reference is removed via the `ChildOperation::deleteChild` method. 6. As uniqueness of student is validated before each student is added, there is no need to check for clashes when executing. @@ -1320,7 +1320,7 @@ need to change according to your current directory. More information can be foun - Adding a student into the specified directory, - - Prerequisites: There exist a group with GroupId `grp-001` + - Prerequisites for all test cases: There exist a group with GroupId `grp-001` - Prerequisites: ProfBook does not contain a student with id `0199Y`.
Test case: `touch ~/grp-001/0199Y --name Mary --email mary@gmail.com --phone 65412987 --address 4 Loyang Walk Loyang Industrial Estate`
@@ -1379,7 +1379,7 @@ need to change according to your current directory. More information can be foun - Test case: `edit --name Lucy --email lucy@gmail.com --phone 91919191`
Expected: An error message indicating the root directory cannot be edited will be shown. - - Other incorrect `edit` commands to try: `edit ~/grp-001 --name Lucy --email lucy@gmail.com --phone 91919191`, `...` + - Other incorrect `edit` commands to try: `edit ~/grp-001 --name Lucy --email lucy@gmail.com --phone 91919191`, `edit ~/grp-001` (Where one or more required fields are missing)
Expected: An error message indicating the command format is invalid will be displayed. From 25b74cc19654cd86be9dbe5d8409a2c74ab9c7c1 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 14:08:59 +0800 Subject: [PATCH 23/31] Fix issues from pr --- docs/DeveloperGuide.md | 46 +++++++++++++++++++++--------------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 125fd39e2a9..6f9f80adc57 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -377,7 +377,7 @@ Implementation for creating a `Student` and a `Group` is very similar, so in thi implementation for the harder one, which is creating a student. Should you have any questions do feel free to contact us. -Most of the logic for creating a student is encapsulated in the `CreateStudentCommand` class, this class utilise +Most of the logic for creating a student is encapsulated in the `CreateStudentCommand` class, this class utilises the `GroupChildOperation` class to add the student to the group and the `Model` class to check for duplicates. The following methods of `ModelManager` and `GroupChildOperation` are used: @@ -443,9 +443,9 @@ Below is an activity diagram showing the general activity of the add student com #### Implementation Creating and adding a task is one of the key feature of ProfBook. Currently, we support two types of tasks, -namely `ToDo` and `Deadline` tasks. Both this tasks extends from the abstract `Task` class which add to its -extensibility. It is important to note that currently, you can only add tasks to Group and Students. Needless to say, -the information for these tasks are encapsulated withing their respective `Task` +namely `ToDo` and `Deadline` tasks. Both these tasks extends from the abstract `Task` class which add to its +extensibility. It is important to note that currently, you can only add tasks to Groups and Students. Needless to say, +the information for these tasks are encapsulated within their respective `Task` instance. As the implementation for creating a `ToDo` and `Deadline` task is very similar, I would be bringing you through @@ -529,7 +529,7 @@ This is an activity diagram showing the general activity of the add deadline com * **Alternative 1:** Add Tasks one by one to each student. * Pros: Quick and easy to implement. - * Cons: keeping track of group tasks is a hassle, any action done for one task must be done for all. + * Cons: Keeping track of group tasks is a hassle, any action done for one task must be done for all. * **Alternative 2**: Allow groups to have their own task lists. * Pros: Quick and easy to implement. * Cons: Adding of student tasks must be done manually. @@ -575,7 +575,7 @@ The following methods of `ModelManager`, `Path` and `RootChildOperation` are use 4. `Path::isGroupDirectory` - To check if the path leads to a group directory. 5. `Path::isStudentDirectory` - To check if the path leads to a student directory. -Given below is an example usage scenario on how an existing user can edit the name of a group +Given below is an example usage scenario on how an existing user can edit the name of a group. 1. When the user launches the application, existing information is read from the data file `profbook.json`. The initial state should look something like this. @@ -592,7 +592,7 @@ Given below is an example usage scenario on how an existing user can edit the na -7. It then deletes the old key-value pair in root's `Map` and adds the new key-value pair. +7. It then deletes the old key-value pair in root's `Map` and adds the new key-value pair. @@ -1097,7 +1097,7 @@ otherwise) * 1e. User specifies `--all allStu` or `--all allGrp`. - * 1e1. ProfBook creates Deadline for either all students within the group, or all groups within ProfBook. + * 1e1. ProfBook creates ToDo for either all students within the group, or all groups within ProfBook. Use case ends. @@ -1277,9 +1277,9 @@ testers are expected to do more *exploratory* testing. **Important:** For simplicity, all the command given below are based on the assumption that you are currently at the -root directory `~/>`. Should you change your directory to something other thant root do take note that our commands may +root directory `~/>`. Should you change your directory to something other than root do take note that our commands may need to change according to your current directory. More information can be found in our -[user guide](https://ay2324s1-cs2103t-w15-2.github.io/tp/UserGuide.html) +[user guide](https://ay2324s1-cs2103t-w15-2.github.io/tp/UserGuide.html). @@ -1402,7 +1402,7 @@ need to change according to your current directory. More information can be foun - Creates todo task for all groups or all students in a group, - Prerequisites: There exist at least one group in ProfBook and at least one of the groups does not have the todo task, Assignment 1.
- Test case: `todo ~ --desc Assignment 1 --all allGrp`
+ Test case: `todo --desc Assignment 1 --all allGrp`
Expected: The todo task `Assignment 1` will be allocated to all groups that does not already have the todo task. - Prerequisites: There exist a group with GroupId `grp-001` with at least one student.
@@ -1410,7 +1410,7 @@ need to change according to your current directory. More information can be foun Test case: `todo ~/grp-001 --desc Assignment 1 --all allStu`
Expected: The todo task `Assignment 1` will be allocated all students in `grp-001` that does not already have the todo task. - - Prerequisites: There exist at least one student in ProfBook and at least of the students does not have the todo task, Assignment 1.
+ - Prerequisites: There exist at least one student in ProfBook and at least one of the students does not have the todo task, Assignment 1.
Test case: `todo --desc Assignment 1 --all allStu`
Expected: The todo task `Assignment 1` will be allocated to all students under root directory that does not already have the todo task. @@ -1449,7 +1449,7 @@ need to change according to your current directory. More information can be foun - Creates deadline task for all groups or all students in a group, - Prerequisites: There exist at least one group in ProfBook and at least one of the groups does not have the deadline task, Assignment 1.
- Test case: `deadline ~ --desc Assignment 1 --datetime 2023-10-11 23:59 --all allGrp`
+ Test case: `deadline --desc Assignment 1 --datetime 2023-10-11 23:59 --all allGrp`
Expected: The deadline task `Assignment 1` will be allocated to all groups that does not already have the task. - Prerequisites: There exist a group with GroupId `grp-001` with at least one student.
@@ -1457,7 +1457,7 @@ need to change according to your current directory. More information can be foun Test case: `deadline ~/grp-001 --desc Assignment 1 --datetime 2023-10-11 23:59 --all allStu`
Expected: The deadline task `Assignment 1` will be allocated all students in `grp-001` that does not already have the task. - - Prerequisites: There exist at least one student in ProfBook and at least of the students does not have the deadline task, Assignment 1.
+ - Prerequisites: There exist at least one student in ProfBook and at least one of the students does not have the deadline task, Assignment 1.
Test case: `deadline --desc Assignment 1 --datetime 2023-10-11 23:59 --all allStu`
Expected: The deadline task `Assignment 1` will be allocated to all students under root directory that does not already have the task. @@ -1490,12 +1490,12 @@ need to change according to your current directory. More information can be foun - Test case: `mark a`
Expected: No task would be marked, an error will be shown. - - Other incorrect `mark` commands to try: `mark -2`, `mark x` (Where x is positive integer which is less than current task size)
+ - Other incorrect `mark` commands to try: `mark \-2`, `mark x` (Where x is positive integer which is greater than current task size)
Expected: No task would be marked, an error message indicating that the index given is invalid. ### Un-mark a completed task -- Un-marks a specified task as done for a student or group +- Un-marks a specified task for a student or group - Prerequisites: The display panel is showing the task list of the specified student or group.
This can be achieved by using the `cat` command alongside the path to the desired student/group to display their task list. @@ -1510,12 +1510,12 @@ need to change according to your current directory. More information can be foun - Test case: `unmark a`
Expected: No task would be un-marked, an error will be shown. - - Other incorrect `un-mark` commands to try: `unmark -2`, `unmark x` (Where x is positive integer which is less than current task size)
+ - Other incorrect `un-mark` commands to try: `unmark \-2`, `unmark x` (Where x is positive integer which is greater than current task size)
Expected: No task would be marked, an error message indicating that the index given is invalid. ### Delete a task -- Deletes a specified task as done for a student or group, +- Deletes a specified task for a student or group, - Prerequisites: The display panel is showing the task list of the specified student or group.
This can be achieved by using the `cat` command alongside the path to the desired student/group to display their task list. @@ -1530,7 +1530,7 @@ need to change according to your current directory. More information can be foun - Test case: `rmt a`
Expected: No task would be deleted, an error will be shown. - - Other incorrect `rmt` commands to try: `rmt -2`, `rmt x` (Where x is positive integer which is less than current task size)
+ - Other incorrect `rmt` commands to try: `rmt \-2`, `rmt x` (Where x is positive integer which is greater than current task size)
Expected: No task would be deleted, an error message indicating that the index given is invalid. ### UI @@ -1592,18 +1592,18 @@ need to change according to your current directory. More information can be foun - Prerequisites: Place ProfBook.jar in an empty home folder. Perform the following step in the root directory. - - Test case: `todo grp-001/0001Y --desc Assignment One` + - Test case: `todo grp-001/0001Y --desc Assignment One`.
Expected: `profbook.json` appears in data folder inside home folder. Student with name `Tejas` has a field history in profbook.json whereas the other students do not. Sample output [here](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/docs/sample/addTodo.json). - - Test case: `rm grp-001/0001Y` + - Test case: `rm grp-001/0001Y`.
Expected: `profbook.json` is updated with `Tejas removed`. Sample output [here](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/docs/sample/removeTejas.json). - Clearing the save file. - Prerequisites: Have `profbook.json` in the data folder. Perform the previous step if the file isn’t there. - - Test case: `clear` - Expected: An empty `profbook.json` file like [here](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/docs/sample/empty.json)). + - Test case: `clear`
+ Expected: An empty `profbook.json` file like [here](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/docs/sample/empty.json).
From 39db90443094053c27d33a4e18801498a47da89c Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 14:28:25 +0800 Subject: [PATCH 24/31] Fix issues from pr --- docs/DeveloperGuide.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 6f9f80adc57..bdbbffdf7ac 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -688,7 +688,7 @@ plan to revamp our duplication checking for students by checking for equality be Currently, while our application tries to output a descriptive and apt message for each error, we have received feedback that some of our error message could be more descriptive. One such example is trying to edit the root `~/` directory or trying to edit a directory that does not exist. In both cases, the error message given -is `Path does not exist in ProfBook.`. In this example, we could have mention that you are unable to edit the root +is `Path does not exist in ProfBook`. In this example, we could have mention that you are unable to edit the root directory for the prior and that the Path does not lead to a student/group for the latter. This is just one example, we plan to revamp our error message to be more descriptive and user-friendly. @@ -1490,7 +1490,7 @@ need to change according to your current directory. More information can be foun - Test case: `mark a`
Expected: No task would be marked, an error will be shown. - - Other incorrect `mark` commands to try: `mark \-2`, `mark x` (Where x is positive integer which is greater than current task size)
+ - Other incorrect `mark` commands to try: `mark \-2`, `mark x` (Where x is positive integer which is greater than current task list size)
Expected: No task would be marked, an error message indicating that the index given is invalid. ### Un-mark a completed task @@ -1510,7 +1510,7 @@ need to change according to your current directory. More information can be foun - Test case: `unmark a`
Expected: No task would be un-marked, an error will be shown. - - Other incorrect `un-mark` commands to try: `unmark \-2`, `unmark x` (Where x is positive integer which is greater than current task size)
+ - Other incorrect `un-mark` commands to try: `unmark \-2`, `unmark x` (Where x is positive integer which is greater than current task list size)
Expected: No task would be marked, an error message indicating that the index given is invalid. ### Delete a task @@ -1530,7 +1530,7 @@ need to change according to your current directory. More information can be foun - Test case: `rmt a`
Expected: No task would be deleted, an error will be shown. - - Other incorrect `rmt` commands to try: `rmt \-2`, `rmt x` (Where x is positive integer which is greater than current task size)
+ - Other incorrect `rmt` commands to try: `rmt \-2`, `rmt x` (Where x is positive integer which is greater than current task list size)
Expected: No task would be deleted, an error message indicating that the index given is invalid. ### UI From 25eca11bfc29827477df84378b76e31b13708be6 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 14:44:02 +0800 Subject: [PATCH 25/31] Fix minor date error --- docs/DeveloperGuide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index cc7e29e6184..470a9766f3a 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -1452,7 +1452,7 @@ need to change according to your current directory. More information can be foun Expected: An error message indicating the datetime format is invalid will be displayed. - Prerequisites: There exist a group with GroupId `grp-001` with the same deadline task Assignment 1 already assigned to it.
- Test case: `deadline ~/grp-001 --desc Assignment 1 --datetime 11-11-2023 23:59`
+ Test case: `deadline ~/grp-001 --desc Assignment 1 --datetime 2023-10-11 23:59`
Expected: An error message indicating that Assignment 1 has already been allocated to it. - Creates deadline task for all groups or all students in a group, From 42e3b190cec87598888f309cf94125aa9239a5da Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 14:59:04 +0800 Subject: [PATCH 26/31] Fix minor date error --- docs/DeveloperGuide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 470a9766f3a..9c14c823060 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -1519,7 +1519,7 @@ need to change according to your current directory. More information can be foun - Test case: `unmark a`
Expected: No task would be un-marked, an error will be shown. - - Other incorrect `un-mark` commands to try: `unmark \-2`, `unmark x` (Where x is positive integer which is greater than current task list size)
+ - Other incorrect `unmark` commands to try: `unmark \-2`, `unmark x` (Where x is positive integer which is greater than current task list size)
Expected: No task would be marked, an error message indicating that the index given is invalid. ### Delete a task From cf4a1aec7635e653346074175dc69946ffff82b7 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 15:04:04 +0800 Subject: [PATCH 27/31] Fix child operation --- docs/DeveloperGuide.md | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 9c14c823060..0d89615da2c 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -381,13 +381,13 @@ implementation for the harder one, which is creating a student. Should you have us. Most of the logic for creating a student is encapsulated in the `CreateStudentCommand` class, this class utilises -the `GroupChildOperation` class to add the student to the group and the `Model` class to check for duplicates. -The following methods of `ModelManager` and `GroupChildOperation` are used: +the `ChildOperation` class to add the student to the group and the `Model` class to check for duplicates. +The following methods of `ModelManager` and `ChildOperation` are used: 1. `ModelManager::groupChildOperation` - To generate an operation class specific to the current group, it also checks for the validity and presence of the specified group. 2. `ModelManager::hasStudentWithId` - To check if the new student id is unique. -3. `GroupChildOperation::addChild` - To add the current student into the group. +3. `ChildOperation::addChild` - To add the current student into the group. Given below is an example usage scenario on how an existing user can create a student. @@ -409,8 +409,8 @@ Given below is an example usage scenario on how an existing user can create a st 5. In this case, if the input was `touch ~/grp-001/1234Y ...` or `touch ~/grp-001/9876A ...` a `CommandException` will be thrown. 6. If all checks out, the command would create a new student and add the student to the `Model`. This addition is done - through getting a `GroupChildOperation` class from the `Model::groupChildOperation` method. This would ensure - the path to the group is present and valid. The student is added through the `GroupChildOperation::addChild` method. + through getting a `ChildOperation` class from the `Model::groupChildOperation` method. This would ensure + the path to the group is present and valid. The student is added through the `ChildOperation::addChild` method. 7. It should look something like this. @@ -465,14 +465,14 @@ tasks can be found at the `Model` component. Most of the logic for creating a task is encapsulated in the `CreateDeadlineCommand` class, this class utilises -the `GroupChildOperation` class to add the Deadline to the group and check for duplicates. -The following methods of `ModelManager` and `GroupChildOperation` are used: +the `ChildOperation` class to add the Deadline to the group and check for duplicates. +The following methods of `ModelManager` and `ChildOperation` are used: 1. `ModelManager::groupChildOperation` - To generate an operation class specific to the current group, it also checks for the validity and presence of the specified group. -2. `GroupChildOperation::addAllTasks` - To add the tasks to all student within a group, it also checks if it is a +2. `ChildOperation::addAllTasks` - To add the tasks to all student within a group, it also checks if it is a duplicate task before adding. -3. `GroupChildOperation::checkIfAllChildrenHaveTask` - To check if all children within a group already has the task. +3. `ChildOperation::checkIfAllChildrenHaveTask` - To check if all children within a group already has the task. It is important to note that for adding a task to a singular group/student, the operation class `TaskOperation` is used instead, a sequence diagram illustrating this can be found in the `Model` component. @@ -493,11 +493,11 @@ Given below is an example usage scenario on how an existing user can add Deadlin 4. This command would first * check if the specified path is a valid and present group path. This is done via `Path::isGroupDirectory` method. * check if all students in the group already has the task. This is done - via `GroupChildOperation::checkIfAllChildrenHaveTask` method. + via `ChildOperation::checkIfAllChildrenHaveTask` method. 5. If all checks out, the command would create a new `Deadline` instance and add the deadline to all student that do not already have the aforementioned task. This is done - through getting a `GroupChildOperation` class from the `Model::groupChildOperation` method. The tasks are then - added through the `GroupChildOperation::addTaskToAllStudent` method. For each student, the method would check if the + through getting a `ChildOperation` class from the `Model::groupChildOperation` method. The tasks are then + added through the `ChildOperation::addTaskToAllStudent` method. For each student, the method would check if the task is already present, if not it would add the task. 6. It should look something like this. @@ -570,11 +570,11 @@ for `path` package. This then allows parser to check for the validity of the giv As the implementation for editing students and groups is similar, for simplicity, I would be going through implementation of editing a group. -The following methods of `ModelManager`, `Path` and `RootChildOperation` are used: +The following methods of `ModelManager`, `Path` and `ChildOperation` are used: 1. `ModelManager::rootChildOperation` - To generate an operation class with logic specific to the current root. 2. `ModelManager::hasGroupWithId` - To check if editing results in a duplicate. -3. `RootChildOperation::editChild` - To edit the group with the values extracted from parser. +3. `ChildOperation::editChild` - To edit the group with the values extracted from parser. 4. `Path::isGroupDirectory` - To check if the path leads to a group directory. 5. `Path::isStudentDirectory` - To check if the path leads to a student directory. @@ -590,7 +590,7 @@ Given below is an example usage scenario on how an existing user can edit the na 4. The fields to be edited is then stored in an `EditGroupDescriptor` instance. (For student it would be stored in an `EditStudentDescriptor`) 5. If the id is being edited, `ModelManager::hasGroupWithId` is called to ensure it does not result in a duplicate. -6. The `RootChildOperation::editChild` then makes a copy of the existing group while updating the values found in +6. The `ChildOperation::editChild` then makes a copy of the existing group while updating the values found in the `EditGroupDescriptor`. @@ -633,7 +633,7 @@ Initially, implementing this feature seemed like a daunting task. However, after realised that implementing move was quite straight forward. Moving a student can be easily done by removing the student's reference from its current group by removing its key-value pair from the group's `Map` field. Then to complete the move, the student is added to the target group by adding it into the target -group's `Map` field. All of this operation is facilitated by the `GroupChildOperation` class. +group's `Map` field. All of this operation is facilitated by the `ChildOperation` class. Given below is an example usage scenario whereby a student is moved from group1 to group2. @@ -642,8 +642,8 @@ Given below is an example usage scenario whereby a student is moved from group1 user would execute the following command: `mv ~/grp-001/1234Y ~/grp-002`. 3. The parser would extract the relevant information and creates a `MoveStudentCommand` instance. 4. The command would check that path to the student and target group is valid and present. -5. Command would then add the student to the target group via the `GroupChildOperation::addChild` method. The old - reference is removed via the `GroupChildOperation::deleteChild` method. +5. Command would then add the student to the target group via the `ChildOperation::addChild` method. The old + reference is removed via the `ChildOperation::deleteChild` method. 6. As uniqueness of student is validated before each student is added, there is no need to check for clashes when executing. From 641e09ef56c572910c44a5a8809dece05bfbb3c6 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 15:20:46 +0800 Subject: [PATCH 28/31] Remove personal information --- docs/DeveloperGuide.md | 5 +++-- docs/sample/{removeTejas.json => removeStudent.json} | 0 2 files changed, 3 insertions(+), 2 deletions(-) rename docs/sample/{removeTejas.json => removeStudent.json} (100%) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 0d89615da2c..27347415c55 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -1600,12 +1600,13 @@ need to change according to your current directory. More information can be foun - Getting the default save file. - Prerequisites: Place ProfBook.jar in an empty home folder. Perform the following step in the root directory. + - Prerequisites: There should be a group with id `grp-001`, this `grp-001` should contain a student with id `0001Y` - Test case: `todo grp-001/0001Y --desc Assignment One`.
- Expected: `profbook.json` appears in data folder inside home folder. Student with name `Tejas` has a field history in profbook.json whereas the other students do not. Sample output [here](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/docs/sample/addTodo.json). + Expected: `profbook.json` appears in data folder inside home folder. Student with id `0001Y` has a new task added which is reflected in `profbook.json`. Sample output [here](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/docs/sample/addTodo.json). - Test case: `rm grp-001/0001Y`.
- Expected: `profbook.json` is updated with `Tejas removed`. Sample output [here](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/docs/sample/removeTejas.json). + Expected: `profbook.json` is updated with the removal of student `0001Y`. Sample output [here](https://github.com/AY2324S1-CS2103T-W15-2/tp/tree/master/docs/sample/removeStudent.json). - Clearing the save file. diff --git a/docs/sample/removeTejas.json b/docs/sample/removeStudent.json similarity index 100% rename from docs/sample/removeTejas.json rename to docs/sample/removeStudent.json From 58142e660dc27857e583f0cb5503a0bbf18f5eb3 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 15:42:17 +0800 Subject: [PATCH 29/31] Remove todo --- docs/DeveloperGuide.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 27347415c55..32b51d8c7f8 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -671,7 +671,7 @@ improve this validation by enforcing a tighter validation. This can be achieved common phone extensions to their length and then enforcing that the phone number be of that length. This allows our users to have the peace of mind that the phone number is validated and robust enough to handle international numbers. -### Better marking and un-marking validation (// TODO low priority, remove when needed ) +### Better marking and un-marking validation Currently, our application does not check if the tasks are marked or unmarked before any operation. This results in users being able to mark/un-mark tasks infinitely, this is not intuitive and may mislead some users. Hence, we plan to @@ -686,7 +686,7 @@ and only if their ids are identical. This means that two students with identical considered different in ProfBook, needless to say this does not reflect requirements in the real world. Therefore, we plan to revamp our duplication checking for students by checking for equality between their phone number and email. -### More descriptive error message (// TODO low priority, remove when needed ) +### More descriptive error message Currently, while our application tries to output a descriptive and apt message for each error, we have received feedback that some of our error message could be more descriptive. One such example is trying to edit the root `~/` directory or From 9383d98f204aaa34b952d592237f0b0b340d3b11 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 16:11:34 +0800 Subject: [PATCH 30/31] Add more proposed features --- docs/DeveloperGuide.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 32b51d8c7f8..2bf67f2d041 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -671,6 +671,14 @@ improve this validation by enforcing a tighter validation. This can be achieved common phone extensions to their length and then enforcing that the phone number be of that length. This allows our users to have the peace of mind that the phone number is validated and robust enough to handle international numbers. +### Max character length validation + +Currently, our application only checks if the required fields (e.g. `--name`, `--desc`). Our current validation is +lacking as users are able to enter a value that is infinitely long which may hinder the performance and functionality of +our GUI. We plan to counteract this by enforcing a max character length for each of our field. Implementing this is +would be rather simple by adding a length check during parsing. We could limit name length to 46 characters, email to 62 +etc. + ### Better marking and un-marking validation Currently, our application does not check if the tasks are marked or unmarked before any operation. This results in @@ -702,6 +710,21 @@ Currently, our hierarchy only extends to `Group`. To serve our target users bett Implementing this is rather easy as `TutorialSlot` would in theory be almost identical to the implementation of `Group`, all `TutorialSlot` have to do is just extend from `ChildrenAndTaskListManager`. + +### Implement a grade component to our tasks + +Currently, our users can only mark tasks as completed. To serve our target users better, we plan to allow our users to +assign a grade or score to a task. This would allow our target users to better keep track of and monitor their students +and their groups progress. Implementing this would be adding a new `tag` to our display for tasks and creating a new +command similar to that of mark that receives and store the grade or score. + +### Implement a search function + +Currently, our users are unable to filter the current displayed list. We predict that this could be a hassle if the user +is required to manage many groups and students with each having a myriad of tasks. We plan to implement this by creating +a new command where users would be able to pass in the field that they wish to search by. Then, we can filter the +display list with a simple for-loop. +
-------------------------------------------------------------------------------------------------------------------- From 148c607f3537b5835272df52bbe1981cf8ce7191 Mon Sep 17 00:00:00 2001 From: Ming Yuan Date: Mon, 13 Nov 2023 16:53:49 +0800 Subject: [PATCH 31/31] Fix spelling error --- docs/DeveloperGuide.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 0008cc0acd4..253d17e9bec 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -657,7 +657,7 @@ Given below is an example usage scenario whereby a student is moved from group1 ### Editing tasks -Currently, the only way to edit tasks is by manually deleting and then adding it again. This creates extra hassle for +Currently, the only way to edit tasks is by manually deleting and then adding them again. This creates extra hassle for the user and possible more inconveniences as doing so might change the task's index resulting in the user having to `cat` again to figure out its new index. We plan to edit the task manually for the user by creating a new command that deletes and then creates a new task with the edited information while keeping the index the same. Implementing this @@ -673,7 +673,7 @@ users to have the peace of mind that the phone number is validated and robust en ### Max character length validation -Currently, our application only checks if the required fields (e.g. `--name`, `--desc`). Our current validation is +Currently, our application only checks if the required fields (e.g. `--name`, `--desc`) is present. Our current validation is lacking as users are able to enter a value that is infinitely long which may hinder the performance and functionality of our GUI. We plan to counteract this by enforcing a max character length for each of our field. Implementing this is would be rather simple by adding a length check during parsing. We could limit name length to 46 characters, email to 62