Developer Guide

• Acknowledgements
• Setting up, getting started
• Design
  • Architecture
  • UI component
  • Logic component
  • Model component
  • Storage component
  • Common classes
• Implementation
  • Add Feature
  • Delete Feature
  • List Feature
  • Enrol Feature
    • Implementation
  • Grading Assessment Feature
    • Implementation
    • Design considerations
  • Mark/Unmark feature
    • Implementation
• Documentation, logging, testing, configuration, dev-ops
• Appendix: Requirements
  • Product scope
  • TAssist User Stories
  • Use cases
  • Non-Functional Requirements
  • Glossary
• Appendix: Instructions for manual testing
  • Launch and shutdown
  • Adding an entity
  • Listing and filtering entities
  • Finding students
  • Deleting an entity
  • Enrolling and disenrolling students
  • Taking student attendance
  • Grading student assessment
  • Saving data

---

Acknowledgements

• Our project is based on AB3.

---

Setting up, getting started

Refer to the guide Setting up and getting started.

---

Design

Architecture

The Architecture Diagram given above explains the high-level design of the App.

Given below is a quick overview of main components and how they interact with each other.

Main components of the architecture

Main has two classes called Main and MainApp. It is responsible for,

• At app launch: Initializes the components in the correct sequence, and connects them up with each other.
• At shut down: Shuts down the components and invokes cleanup methods where necessary.

Commons represents a collection of classes used by multiple other components.

The rest of the App consists of four components.

• UI: The UI of the App.
• Logic: The command executor.
• Model: Holds the data of the App in memory.
• Storage: Reads data from, and writes data to, the hard disk.

How the architecture components interact with each other

The Sequence Diagram below shows how the components interact with each other for the scenario where the user issues the command delete class 2.

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.

For example, the Logic component defines its API in the Logic.java interface and implements its functionality using the LogicManager.java class which follows the Logic interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent outside component’s being coupled to the implementation of a component), as illustrated in the (partial) class diagram below.

The sections below give more details of each component.

UI component

The API of this component is specified in Ui.java

The UI consists of a MainWindow that is made up of parts e.g.CommandBox, ResultDisplay, *EntityListPanel, StatusBarFooter etc. All these, including the MainWindow, inherit from the abstract UiPart class which captures the commonalities between classes that represent parts of the visible GUI.

*EntityListPanel and *EntityListCard represent separate list panels and cards tailored for a specific entity (Student, ClassGroup, Module, Assessment).

The UI component uses the JavaFx UI framework. The layout of these UI parts are defined in matching .fxml files that are in the src/main/resources/view folder. For example, the layout of the MainWindow is specified in MainWindow.fxml

The UI component,

• executes user commands using the Logic component.
• listens for changes to Model data so that the UI can be updated with the modified data.
• keeps a reference to the Logic component, because the UI relies on the Logic to execute commands.
• depends on some classes in the Model component, as it displays various Entity objects residing in the Model.

Logic component

API : Logic.java

Here’s a (partial) class diagram of the Logic component:

How the Logic component works:

1. When Logic is called upon to execute a command, it uses the TAssistParser class to parse the user command.
2. This results in a Command object (more precisely, an object of one of its subclasses e.g., AddCommand) which is executed by the LogicManager.
3. The command can communicate with the Model when it is executed (e.g. to add a student).
4. The result of the command execution is encapsulated as a CommandResult object which is returned back from Logic.

The Sequence Diagram below illustrates the interactions within the Logic component for the execute("delete class 2") API call.

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:

• When called upon to parse a user command, the TAssistParser class creates an XYZCommandParser (XYZ is a placeholder for the specific command name e.g., AddCommandParser) which uses the other classes shown above to parse the user command and create a XYZCommand object (e.g., AddCommand) which the TAssistParser returns back as a Command object.
• All TAssistParser classes (e.g., AddCommandParser, DeleteCommandParser, …) inherit from the Parser interface so that they can be treated similarly where possible e.g, during testing.

Model component

API : Model.java

The Model component,

• stores the TAssist data i.e., all Student, TaModule, ClassGroup, Assessment objects (which are contained in UniqueStudentList, UniqueModuleList, UniqueClassGroupList, UniqueAssessmentList objects respectively).
• stores the currently ‘selected’ Student/TaModule/ClassGroup/Assessment objects (e.g., results of a search query) as a separate filtered list which is exposed to outsiders as an unmodifiable ObservableList<Student>/ObservableList<TaModule> /ObservableList<ClassGroup>/ObservableList<Assessment> that can be ‘observed’ e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.
• stores a UserPref object that represents the user’s preferences. This is exposed to the outside as a ReadOnlyUserPref objects.
• does not depend on any of the other three components (as the Model represents data entities of the domain, they should make sense on their own without depending on other components).
• An Entity object is a generic object that can be used to represent instances of Student/TaModule/ClassGroup/Assessment.
• Module are named TaModule due to conflict with Java classes.

Storage component

API : Storage.java

The Storage component,

• can save both TAssist data and user preference data in json format, and read them back into corresponding objects.
• inherits from both TAssistStorage and UserPrefStorage, which means it can be treated as either one (if only the functionality of only one is needed).
• depends on some classes in the Model component (because the Storage component’s job is to save/retrieve objects that belong to the Model)

Common classes

Classes used by multiple components are in the seedu.address.commons package.

---

Implementation

This section describes some noteworthy details on how certain features are implemented.

Add Feature

The add mechanism is facilitated by TAssist. Its functionality, usage and behaviour is the same for all entities. Additionally, it implements the following operations:

• AddCommandParser#parse() — Parses the command arguments.
• AddCommand#execute() — Executes ModelManager#addEntity() with the specified entity.
• ModelManager#addEntity() — Adds the specified entity.

Given below is an example usage scenario for the creation of Student object and how the add mechanism behaves at each step.

Step 1. The user launches the application. The TAssist is already populated with data.

Step 2. The user executes clear command to remove all existing data in TAssist.

Step 3. The user executes add student command to add a student to TAssist. The add command also calls AddCommandParser#parse(), which parses the input and returns the index and entity type.

• An example of the add student command: add student id/E0123456 n/John Doe e/johnd@u.nus.edu t/john_doe

The following sequence diagram shows how the add operation works:

The following activity diagram summarizes what happens when a user executes an add command:

Delete Feature

The delete mechanism is facilitated by TAssist. Its functionality, usage and behaviour is the same for all entities. Additionally, it implements the following operations:

• DeleteCommandParser#parse() — Parses the command arguments.
• DeleteCommand#execute() — Executes ModelManager#deleteEntity() with the specified entity.
• ModelManager#deleteEntity() — Deletes the specified entity.
• ModelManager#deleteEntity() — Deletes the specified entity.

However, when a TaModule object is deleted, its associated ClassGroup and Assessment object(s) are also deleted.

Given below is an example usage scenario using ClassGroup objects and how the delete mechanism behaves at each step.

Step 1. The user launches the application. The TAssist is already populated with data.

Step 2. The user executes list class command to list the class groups in the TAssist. The list command implementation is detailed below in the List Feature section.

Step 3. The user executes delete class 2 to delete the 2nd class group in the list which is c2. The delete command also calls DeleteCommandParser#parse(), which parses the input and return the index and entity type.

The following sequence diagram shows how the delete operation works:

The following activity diagram summarizes what happens when a user executes a delete command:

List Feature

The list mechanism is facilitated by TAssist. Its functionality, usage and behaviour is the same for all entities. Additionally, it implements the following operations:

• ListCommandParser#parse() — Parses the command arguments.
• ListCommand#execute() — Executes ModelManager#updateFiltered<ENTITY_NAME>List() with the predicate that matches the filtering criteria.
• ModelManager#updateFiltered<ENTITY_NAME>List() — Updates the predicate of the entity list so that only filtered entries will be shown in TAssist.

Given below is an example usage scenario using Student objects and how the list mechanism behaves at each step.

Step 1. The user launches the application. The TAssist is already populated with data.

Step 2. The user executes list student c/2 to filter out students from the 2nd class group in the list. The list command also calls ListCommandParser#parse(), which parses the input and return the entity type as well as the class group index or TA module index to filter by.

The following sequence diagram shows how the list operation works:

The following activity diagram summarizes what happens when a user executes a list command:

Enrol Feature

Implementation

The enrol mechanism is facilitated by TAssist. Its functionality, usage and behaviour is only for student entity. Additionally, it implements the following operations:

• EnrolCommandParser#parse() — Parses the command arguments.
• EnrolCommand#execute() — Executes ModelManager#enrolStudent() with given student(s) and class group.
• ModelManager#enrolStudent() — Enrols student(s) to a given class group.

Given below is an example usage scenario for the enrolment of a Student object to a ClassGroup object and how the enrol mechanism behaves at each step.

Step 1. The user launches the application. The TAssist is already populated with data.

Step 2. The user executes enrol command to enrol student(s) to a ClassGroup. The enrol command also calls EnrolCommandParser#parse(), which parses the input and returns a successful/unsuccessful output message.

• An example of the enrol command: enrol c/1 s/1

The following sequence diagram shows how the enrol operation works:

The following activity diagram summarizes what happens when a user executes an enrol command:

Grading Assessment Feature

Implementation

The grading assessment mechanism is facilitated by TAssist. Since there are various gradable components, a new entity Assessment will benefit the application. This entity will allow tutors to customize what are the different gradable components, from assignments to class participations. Tutors can add, delete and list this entity like the other entities. On top of that, they will be able to grade the assessment, using the grade command. The following operations will be implemented for the grade command:

• GradeCommandParser#parse() — Parses the command arguments.
• GradeCommand#execute() — Executes ModelManager#gradeAssessment() with the specified assessment, students and the grade they get.
• ModelManager#gradeAssessment() — Grades the students for the specified assessment.

The Assessment entity will be tied to a specific module. Hence, when a TaModule object is deleted, its associated Assessment objects are also deleted.

Given below is an example usage scenario of how the grading mechanism behaves at each step.

Step 1. The user launches the application. The TAssist is already populated with the necessary data.

Step 2. The user executes grade a/1 s/1,2 g/1 command to grade the 1st assessment (a1) for the 1st and 2nd students (s1 and s2 respectively) enrolled in the module with grade 1 in the TAssist. The grade command would call the GradeCommandParser#parse(), which parses the input and return the assessment to grade, which students to grade and what is the grade the students will get for the assessment.

The following sequence diagram shows how the grade operation works:

The following activity diagram summarizes what happens when a user executes a grade command:

Design considerations

Aspect: How to grade assessments:

• Alternative 1 (current choice): Create Assessment entity and this entity will contain the students attempts.
  • Pros: Easy to implement.
  • Cons: Duplicate data in storage, and need to ensure data is deleted properly if student/module is deleted.
• Alternative 2: Create Assessment entity and the TaModule entity will contain the student attempts.
  • Pros: All module related data are in one class.
  • Cons: Duplicate data in storage, hard to display assessments attempts.

Mark/Unmark feature

Implementation

The mark/unmark mechanism is facilitated by TAssist. Its functionality, usage and behaviour is currently exclusive to StudentAttendance. Additionally, it implements the following operations:

• MarkCommandParser#parse() — Parses the command arguments.
• MarkCommand#execute() — Executes ModelManager#markAttendance() or ModelManager#unmarkAttendance based on a specified class group index and week number.
• ModelManager#markAttendance() — Updates the specified Lesson object with a list of StudentAttendance objects.

Given below is an example usage scenario using mark which illustrates how the mechanism behaves at each step.

Step 1. The user launches the application. The TAssist is already populated with data.

Step 2. The user executes list class command to list the class groups in the TAssist. The list command implementation is detailed below in the List Feature section.

Step 3. The user executes list student c/1 command to list all the students in the class group with index 1.

Step 4. The user executes mark c/1 w/1 s/1,2 to mark attendance for a lesson which belongs to a class group with index 1 and occurs in week 1. Students with indexes 1 and 2 are marked as having attended. The mark command also calls MarkCommandParser#parse(), which parses the input and returns a successful/unsuccessful message.

The following sequence diagram shows how the mark operation works:

The following activity diagram summarizes what happens when a user executes a mark command:

---

Documentation, logging, testing, configuration, dev-ops

• Documentation guide
• Testing guide
• Logging guide
• Configuration guide
• DevOps guide

---

Appendix: Requirements

Product scope

Target user profile:

• TA in charge of teaching NUS modules
• Needs to manage a significant number of student contacts
• Might be instructing multiple modules/classes
• Prefers desktop apps over other types
• Types fast
• Prefers typing to mouse interactions
• Is reasonably comfortable using CLI apps

Value proposition: TAssist creates a more conducive learning environment for educators and students by helping TAs consolidate students’ contacts and monitor their progress for all modules/classes taught by the TAs.

TAssist User Stories

Priorities: High (must have) - * * *, Medium (nice to have) - * *, Low (unlikely to have) - *

No	As a …	I can…	So that I can…	Notes	Priority
1	TA	[EPIC] Manage my students in my contacts add students to my contacts remove students from my contacts view students find students by name	keep in contact with them.		***
2	TA	[EPIC] Manage the modules I am teaching add modules remove modules view modules	monitor the modules I am teaching this semester.		***
3	TA	[EPIC] Manage the class groups I am teaching add class groups remove class groups view class groups	monitor the class groups I have to teach.		***
4	TA	[EPIC] Manage the assessments I assign add assessments remove assessments view assessments	monitor the assessments I assign.		***
5	TA	[EPIC] Manage students in the modules I am teaching add students to a module remove students from a module view students in a module	easily monitor the students I am teaching in a module.		***
6	TA	[EPIC] Manage students in the class groups I am teaching add students to a class group remove students from a class group view students in a class group	easily monitor the students I am teaching in a class group.		***
7	TA	[EPIC] Manage class groups in the modules I am teaching add class groups to a module remove class groups from a module view class groups in a module	easily monitor the class groups I am teaching in a module.		***
8	TA	[EPIC] Manage assessments in the modules I am teaching add assessments to a module remove assessments from a module view assessments in a module	easily monitor the assessments I am assigning in a module.		***
9	TA	Keep track of students’ attendance Conditions: add students to a lesson remove students from a lesson view students in a lesson	focus on students who have not been attending lessons.		***
10	TA	Keep track of students’ assessment attempts Conditions: add students to a module remove students from a module view students in a module add assessments to a module remove assessments from a module view assessments in a module	grade students' assessment attempts.		***
11	TA	edit the attributes of the things I created List of things I should be able to edit: student module class group assessment	modify any attributes that I entered wrongly.		**

Use cases

(For all use cases below, the System is the TAssist and the Actor is the TA, unless specified otherwise)

Use case 01: Add a module

MSS

1. TA requests to add a new module with the specified details.

2. TAssist adds the new module and displays its details.

   Use case ends.

Extensions

• 1a. TAssist detects an error in the entered command.

  • 1a1. TAssist prompts for the correct command.

  • 1a2. TA enters a new command.

    Steps 1a1-1a2 are repeated until the command entered is correct.

    Use case resumes from step 2.

Use case 02: Add a student

MSS

1. TA requests to add a new student with the specified details.

2. TAssist adds the new student and displays their details.

   Use case ends.

Extensions

• 1a. TAssist detects an error in the entered command.

  • 1a1. TAssist prompts for the correct command.

  • 1a2. TA enters a new command.

    Steps 1a1-1a2 are repeated until the command entered is correct.

    Use case resumes from step 2.

Use case 03: Add a class group

Preconditions: The module that the class group will be added to already exists.

MSS

1. TA requests to list modules (UC10).
2. TA requests to add a new class group with the specified details.

3. TAssist adds the new class group and displays its details.

   Use case ends.

Extensions

• 2a. TAssist detects an error in the entered command.

  • 2a1. TAssist prompts for the correct command.

  • 2a2. TA enters a new command.

    Steps 2a1-2a2 are repeated until the command entered is correct.

    Use case resumes from step 3.

Use case 04: Add an assessment

Preconditions: The module that the assessment will be added to already exists.

MSS

1. TA requests to list modules (UC10).
2. TA requests to add a new assessment with the specified details.

3. TAssist adds the new assessment and displays its details.

   Use case ends.

Extensions

• 2a. TAssist detects an error in the entered command.

  • 2a1. TAssist prompts for the correct command.

  • 2a2. TA enters a new command.

    Steps 2a1-2a2 are repeated until the command entered is correct.

    Use case resumes from step 3.

Use case 05: Enrolling student(s)

Preconditions:

1. The student(s) to be enrolled already exist.
2. The class group that the student(s) will be enrolled in already exists.

MSS

1. TA requests to enrol one/more student(s) into a particular class group.

2. TAssist enrols the student(s) and displays their details.

   Use case ends.

Extensions

• 1a. TAssist detects an error in the entered command.

  • 1a1. TAssist prompts for the correct command.

  • 1a2. TA enters a new command.

    Steps 1a1-1a2 are repeated until the command entered is correct.

    Use case resumes from step 2.

Use case 06: Disenrolling student(s)

Preconditions: The student(s) to be disenrolled is already enrolled in the class group.

MSS

1. TA requests to disenrol one/more student(s) from a particular class group.

2. TAssist disenrols the student(s) and displays their details.

   Use case ends.

Extensions

• 1a. TAssist detects an error in the entered command.

  • 1a1. TAssist prompts for the correct command.

  • 1a2. TA enters a new command.

    Steps 1a1-1a2 are repeated until the command entered is correct.

    Use case resumes from step 2.

Use case 07: Marking students’ attendances

Preconditions: The student(s) whose attendance(s) is to be marked is already enrolled in the class group.

MSS

1. TA requests to mark one/more student(s) attendance(s) from a particular class group.

2. TAssist marks the attendance(s) and displays their details.

   Use case ends.

Extensions

• 1a. TAssist detects an error in the entered command.

  • 1a1. TAssist prompts for the correct command.

  • 1a2. TA enters a new command.

    Steps 1a1-1a2 are repeated until the command entered is correct.

    Use case resumes from step 2.

Use case 08: Unmarking students’ attendances

Preconditions: The student(s) whose attendance(s) is to be unmarked is already enrolled in the class group.

MSS

1. TA requests to unmark one/more student(s) attendance(s) from a particular class group.

2. TAssist unmarks the attendance(s) and displays their details.

   Use case ends.

Extensions

• 1a. TAssist detects an error in the entered command.

  • 1a1. TAssist prompts for the correct command.

  • 1a2. TA enters a new command.

    Steps 1a1-1a2 are repeated until the command entered is correct.

    Use case resumes from step 2.

Use case 09: Grading assessments

Preconditions: The student(s) are already enrolled in the module that the assessment is associated with.

MSS

1. TA requests to grade one/more student(s) assessment(s) from a particular module.

2. TAssist grade the assessment(s) and displays their details.

   Use case ends.

Extensions

• 1a. TAssist detects an error in the entered command.

  • 1a1. TAssist prompts for the correct command.

  • 1a2. TA enters a new command.

    Steps 1a1-1a2 are repeated until the command entered is correct.

    Use case resumes from step 2.

Use case 10: List modules

MSS

1. TA requests to list modules.

2. TAssists displays the details of all modules.

   Use case ends.

Extensions

• 1a. TAssist detects an error in the entered command.

  • 1a1. TAssist prompts for the correct command.

  • 1a2. TA enters a new command.

    Steps 1a1-1a2 are repeated until the command entered is correct.

    Use case resumes from step 2.

Use case 11: List/filter students

MSS

1. TA requests to list students.

2. TAssist displays the details of all students.

   Use case ends.

Extensions

• 1a. TA requests to filter students by a specific module.

  • 1a1. TAssist displays the details of students belonging to the specified module.

    Use case ends.

• 1b. TA requests to filter students by a specific class group.

  • 1b1. TAssist displays the details of students belonging to the specified class group.

    Use case ends.

• 1c. TAssist detects an error in the entered command.

  • 1c1. TAssist prompts for the correct command.

  • 1c2. TA enters a new command.

    Steps 1c1-1c2 are repeated until the command entered is correct.

    Use case resumes from step 2.

Use case 12: List/filter class groups

MSS

1. TA requests to list class groups.

2. TAssist displays the details of all class groups.

   Use case ends.

Extensions

• 1a. TA requests to filter class groups by a specific module.

  • 1a1. TAssist displays the details of class groups belonging to the specified module.

    Use case ends.

• 1b. TAssist detects an error in the entered command.

  • 1b1. TAssist prompts for the correct command.

  • 1b2. TA enters a new command.

    Steps 1b1-1b2 are repeated until the command entered is correct.

    Use case resumes from step 2.

Use case 13: List/filter assessments

MSS

1. TA requests to list assessments.

2. TAssist displays the details of all assessments.

   Use case ends.

Extensions

• 1a. TA requests to filter assessments by a specific module.

  • 1a1. TAssist displays the details of assessments belonging to the specified module.

    Use case ends.

• 1b. TAssist detects an error in the entered command.

  • 1b1. TAssist prompts for the correct command.

  • 1b2. TA enters a new command.

    Steps 1b1-1b2 are repeated until the command entered is correct.

    Use case resumes from step 2.

Use case 14: Find students by name

MSS

1. TA requests to find students with specific keyword(s).

2. TAssist displays the details of all students whose name contains one/more of the specified keyword(s).

   Use case ends.

Extensions

• 1a. TAssist detects an error in the entered command.

  • 1a1. TAssist prompts for the correct command.

  • 1a2. TA enters a new command.

    Steps 1a1-1a2 are repeated until the command entered is correct.

    Use case resumes from step 2.

• 2a. The list is empty.

  Use case ends.

Use case 15: Delete a module

MSS

1. TA requests to list modules (UC10).
2. TA requests to delete a specific module in the list.

3. TAssist deletes the module and the class groups and assessments associated with it.

   Use case ends.

Extensions

• 2a. The list is empty.

  Use case ends.

• 2b. TAssist detects an error in the entered command.

  • 2b1. TAssist prompts for the correct command.

  • 2b2. TA enters a new command.

    Steps 2b1-2b2 are repeated until the command entered is correct.

    Use case resumes from step 3.

Use case 16: Delete a student

MSS

1. TA requests to list students (UC11).
2. TA requests to delete a specific student in the list.

3. TAssist deletes the student and their associated assessment attempts.

   Use case ends.

Extensions

• 2a. The list is empty.

  Use case ends.

• 2b. TAssist detects an error in the entered command.

  • 2b1. TAssist prompts for the correct command.

  • 2b2. TA enters a new command.

    Steps 2b1-2b2 are repeated until the command entered is correct.

    Use case resumes from step 3.

Use case 17: Delete a class group

MSS

1. TA requests to list class groups (UC12).
2. TA requests to delete a specific class group in the list.

3. TAssist deletes the class group.

   Use case ends.

Extensions

• 2a. The list is empty.

  Use case ends.

• 2b. TAssist detects an error in the entered command.

  • 2b1. TAssist prompts for the correct command.

  • 2b2. TA enters a new command.

    Steps 2b1-2b2 are repeated until the command entered is correct.

    Use case resumes from step 3.

Use case 18: Delete an assessment

MSS

1. TA requests to list assessments (UC13).
2. TA requests to delete a specific assessment in the list.

3. TAssist deletes the assessment.

   Use case ends.

Extensions

• 2a. The list is empty.

  Use case ends.

• 2b. TAssist detects an error in the entered command.

  • 2b1. TAssist prompts for the correct command.

  • 2b2. TA enters a new command.

    Steps 2b1-2b2 are repeated until the command entered is correct.

    Use case resumes from step 3.

Non-Functional Requirements

1. Should work on any mainstream OS as long as it has Java 11 or above installed.
2. Should be able to hold up to 1000 entities without a noticeable sluggishness in performance for typical usage.
3. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.
4. Should not depend on external/remote servers.
5. Should not depend on a Database Management System (DBMS).

Glossary

• Assessment: Various gradable component that the TA can add into the module. E.g. Class participation, Lab 1, Lab 2 Report
• Class Group: The different types of classes a module has. E.g. T01, T02, B01, B02
• CLI: Command line interface
• Entity: A generic object used in TAssist, which can be an instance of Assessment, ClassGroup, Module, or Student
• GUI: Graphical user interface
• Lesson: The weekly lesson that students turn up for
• Mainstream OS: Windows, Linux, Unix, OS-X
• Module: A NUS SoC module
• MSS: Main Success Scenario
• NUS: The National University of Singapore
• Student: A student in NUS
• TA: A Teaching Assistant in NUS SoC
• TaModule: Represents a Module. Named differently due to conflict with Java class

---

Appendix: Instructions for manual testing

Given below are instructions to test the app manually.

Launch and shutdown

1. Initial launch

   1. Download the jar file and copy into an empty folder

   2. Double-click the jar file Expected: Shows the GUI with a set of sample contacts. The window size may not be optimum.

2. Saving window preferences

   1. Resize the window to an optimum size. Move the window to a different location. Close the window.

   2. Re-launch the app by double-clicking the jar file.
      Expected: The most recent window size and location is retained.

Adding an entity

1. Adding an entity (module/student/class group/assessment).

2. Test case: add student id/E0123456 n/John Doe e/johnd@u.nus.edu, add module n/Software Engineering Project c/CS2103T a/21S1, add class id/T13 t/tutorial m/1, add assessment n/Test m/1
   Expected: Details of the added entity shown in the status message.

3. Test case: add ENTITY where ENTITY can be module/student/class/assessment.
   Expected: No entity is added. Error details shown in the status message.

4. Other incorrect add commands to try: add, add student id/E012345a n/John Doe e/johnd@u.nus.edu, ... (where E012345a is an invalid student ID)
   Expected: Similar to previous.

5. The above test cases can be repeated with the other entities (and their respective parameters) and also by using their shorthand forms.
   Examples: add s id/E0123456 n/John Doe e/johnd@u.nus.edu, add m n/Software Engineering Project c/CS2103T a/21S1, add c id/T13 t/tutorial m/1, add a n/Test m/1.

Listing and filtering entities

1. Listing and filtering entities (module/student/class group/assessment).

2. Test case: List all entities using the list ENTITY command where ENTITY can be module/student/class/assessment.
   Filters may be used in the list command for students, class groups and assessments, e.g. list student m/1, list class m/1, list assessment m/1.
   Expected: Details of the listed entities shown in their respective GUI panels.

3. Test case: list
   Expected: No entity is listed. Error details shown in the status message.

4. Other incorrect add commands to try: list student m/x, ... (where x is out of bounds)
   Expected: Similar to previous.

5. The above test cases can be repeated with the other entities and also by using their shorthand forms.
   Examples: list s m/1, list m, list c, list a.

Finding students

1. Finding students by their name.

2. Test case: find John.
   Expected: Students whose name contains John is listed.

3. Test case: find
   Expected: No student is listed. Error details shown in the status message.

Deleting an entity

1. Deleting an entity (module/student/class group/assessment) while all entities are being shown in their respective list.

2. Prerequisites: List all entities using the list ENTITY command where ENTITY can be module/student/class/assessment.
   Filters may be used in the list command for students, class groups and assessments as well, e.g. list student m/1.

3. Test case: delete module 1, delete m 1
   Expected: First module is deleted from the list. Details of the deleted module shown in the status message.

4. Test case: delete module 0, delete m 0
   Expected: No module is deleted. Error details shown in the status message.

5. Other incorrect delete commands to try: delete, delete module x, ... (where x is out of bounds)
   Expected: Similar to previous.

6. The above test cases can be repeated with the other entities by replacing module with student/class/assessment and also by using their shorthand forms.
   Examples: delete student 1, delete class 1, delete assessment 1, delete s 1, delete c 1, delete a 1.

Enrolling and disenrolling students

1. Enrolling and disenrolling students.

2. Test case: enrol c/1 s/all
   Expected: All students shown will be enrolled in the 1st class group shown in the GUI panel. Details of the students enrolled shown in the status message.

3. Test case: enrol c/1 s/1,2,3,4,5,6
   Expected: The 1st 6 students shown will be enrolled in the 1st class group shown in the GUI panel. Details of the students enrolled shown in the status message.

4. Test case: enrol c/1 s/e0123456,e0234567
   Expected: Students with ID E0123456 and E02345767 will be enrolled in the 1st class group shown in the GUI panel. Details of the students enrolled shown in the status message.

5. Test case: enrol c/1
   Expected: No student is enrolled. Error details shown in the status message.

6. Other incorrect mark commands to try: enrol c/x, ... (where x is out of bounds)
   Expected: Similar to previous.

7. The above test cases can be repeated with the disenrol command by replacing enrol with disenrol.
   

Taking student attendance

1. Taking student attendance.

2. Prerequisites: Student(s) should already be enrolled in the class group.
   

3. Test case: mark c/1 w/3 s/all
   Expected: All students enrolled in the 1st class group shown in the GUI panel will have their attendance marked for week 3. Details of the students with attendance marked shown in the status message.

4. Test case: mark c/1 w/3 s/1,2,3,4,5,6
   Expected: The 1st 6 students enrolled in the 1st class group shown in the GUI panel will have their attendance marked for week 3. Details of the students with attendance marked shown in the status message.

5. Test case: mark c/1 w/3 s/e0123456,e0234567
   Expected: Students with ID E0123456 and E02345767 enrolled in the 1st class group shown in the GUI panel will have their attendance marked for week 3. Details of the students with attendance marked shown in the status message.

6. Test case: mark c/1 w/3
   Expected: No student attendance is marked. Error details shown in the status message.

7. Other incorrect mark commands to try: mark c/x, mark c/1 w/x, ... (where x is out of bounds)
   Expected: Similar to previous.

8. The above test cases can be repeated with the unmark command by replacing mark with unmark.
   

Grading student assessment

1. Grading student assessment.

2. Prerequisites: Student(s) should already be enrolled in the class group and 1/more assessments belonging to the module has been created.
   

3. Test case: grade sn/lab1 m/1 s/all g/1
   Expected: All students enrolled in the 1st module shown in the GUI panel will be assigned a grade of 1 for the assessment with a simple name of lab1. Details of the students with assessment graded in the status message.

4. Test case: grade a/1 s/1,2,3,4,5,6
   Expected: The 1st 6 students shown in the GUI panel will be assigned a grade of 1 for the 1st assessment. Details of the students with assessment graded in the status message.

5. Test case: grade a/1 s/e0123456,e0234567 g/1
   Expected: Students with ID E0123456 and E02345767 enrolled in the module will be assigned a grade of 1 for the 1st assessment. Details of the students with assessment graded in the status message.

6. Test case: grade a/1
   Expected: No student assessment is graded. Error details shown in the status message.

7. Other incorrect grade commands to try: grade a/x, grade sn/lab1 m/x, ... (where x is out of bounds)
   Expected: Similar to previous.

Saving data

1. Dealing with corrupted data file.
2. Prerequisites: There are existing data in the data file.
3. Test case: User changed data in data file.
   Expected: TAssist starts as usual.
   Actual: TAssist starts with no data.
   Solution: Undo the changes made in data file and change with the help of TAssist instead.