Developer Guide
- Setting Up, Getting Started
- Design
- Implementation
- Documentation, Logging, Testing, Configuration, Dev-Ops
- Appendix: Requirements
- Appendix: Instructions for Manual Testing
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 application. Given below is a quick overview of each component.
![:bulb: :bulb:](https://github.githubassets.com/images/icons/emoji/unicode/1f4a1.png)
.puml
files used to create diagrams in this document can be found in the diagrams folder. Refer to the PlantUML Tutorial at se-edu/guides to learn how to create and edit diagrams.
Main
has two classes called Main
and MainApp
. It is responsible for,
- At application 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 application consists of four components:
-
UI
: The UI of the application. -
Logic
: The command executor. -
Model
: Holds the data of the application in memory. -
Storage
: Reads and writes data to the hard disk.
Each of the four components
- defines its API in an
interface
with the same name as the component, - exposes its functionality using a concrete
{Component Name}Manager
class (which implements the corresponding APIinterface
mentioned in the previous point).
For example, the Logic
component (see the class diagram given below) defines its API in the Logic.java
interface and exposes its functionality using the LogicManager.java
class which implements the Logic
interface.
How the architecture components interact with each other
The sequence diagram below shows how the components interact with each other when the user issues the command delete-student 1
.
The sections below give more details of each component.
UI Component
API :
Ui.java
The UI consists of a MainWindow
that is made up of parts. For example, CommandBox
, ResultDisplay
, StudentListPanel
, StatusBarFooter
etc. All these, including the MainWindow
, inherit from the abstract UiPart
class.
The UI
component uses 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.
Logic Component
API :
Logic.java
-
Logic
uses theTutorsPetParser
class to parse the user command. - This results in the instantiation of a
Command
object which is then executed by theLogicManager
. - The command execution can affect the
Model
(e.g. adding a student). - The result of the command execution is encapsulated as a
CommandResult
object which is passed back to theUi
. - In addition, the
CommandResult
object can also instruct theUi
to perform certain actions, such as displaying help to the user.
Given below is the Sequence Diagram for interactions within the Logic
component for the execute("delete-student 1")
API call.
![:information_source: :information_source:](https://github.githubassets.com/images/icons/emoji/unicode/2139.png)
DeleteStudentCommandParser
should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
Model Component
This section explains the high level design of the Model
component of the application.
The Model
component manages the data stored in the application during runtime.
The Model
stores:
- a
UserPref
object that represents the user’s preferences. - a
VersionedTutorsPet
object that contains Tutor’s Pet data.
There are four main packages in the component, each representing a corresponding ‘physical’ entity:
- the
Student
package contains classes that represent a student. - the
ModuleClass
package contains classes that represent a class (a group of students that attend the same lessons).
The package nameModuleClass
was chosen asclass
is a reserved keyword in Java. - the
Lesson
package contains classes that represent a series of lessons. - the
Attendance
package contains classes that represent the attendance and participation records of students.
Model
also exposes two unmodifiable ObservableList<>
, one each for Student
and ModuleClass
, that can be ‘observed’.
This allows the UI component to automatically update when the data in these lists change.
The class diagram below gives an overview of the model package.
Details of the Student
, ModuleClass
, Lesson
, and Attendance
packages have be omitted for brevity.
Please refer to the Student & ModuleClass, Lesson and Attendance diagrams for more information.
API :
Model.java
The class diagram below shows the design of the Student
and ModuleClass
packages.
Storage Component
API : Storage.java
The Storage
component
- saves
UserPref
objects in json format and reads it back, - saves the data in json format and reads it back.
Common Classes
Classes used by multiple components are in the tutorspet.commons
package.
Implementation
This section describes some noteworthy details on how certain features are implemented.
Student Model and Student Universally Unique Identifier (UUID)
A UUID
is a unique 128-bit number to identify a unique Student
within Tutor’s Pet.
In Tutor’s Pet, every Student
upon construction, is assigned a randomly generated UUID
. It is used to
uniquely identify a Student
across ModuleClass
es and Lesson
s. This is important because we are dealing with
Student
data not just in the Student
model, but also in the ModuleClass
and Lesson
model. Using a
Student
UUID
will help to ensure referential integrity of Student
data across different models when
Student
data is modified by the user.
Implementation
The class diagram below shows the current implementation of Student
model.
Every Student
contains a UUID
, Name
, Telegram
, Email
, and a set of Tags
.
From the object diagram above, we have designed the Student
model such that every Student
like Alice
has a unique 128-bit UUID
tagged to her. In addition, the Name
, Telegram
, Email
, and Tags
fields are also implemented to define a Student
.
Design Considerations
This section elaborates further on why we chose to adopt a UUID
over other potential
solutions.
Aspect 1: How to uniquely identify Students across models.
-
Alternative 1 (current choice): Assign a
UUID
attribute to eachStudent
- Pros:
- Convenient to generate
UUID
in Java. Java has aUUID
package to supportUUID
s. -
UUID
is non-editable.
- Convenient to generate
- Cons:
- Implementation is slightly more complicated. Caution must be taken when integrating the
UUID
field intoStudent
model, and enforcingStudent
equality checks usingUUID
in Tutor’s Pet. - Although the chances are low, it is possible that generating random
UUID
s present a risk ofUUID
collisions when we deal with large amounts of student data.
- Implementation is slightly more complicated. Caution must be taken when integrating the
- Pros:
-
Alternative 2: Ensure that each
Student
must have a uniqueEmail
- Pros:
- Easier to implement as the original AB3 already has an
Email
field integrated into it.
- Easier to implement as the original AB3 already has an
- Cons:
- The
Email
field is editable while the unique identifier of eachStudent
should not be editable to prevent the need to cascade a change in the identifier of theStudent
.
- The
- Pros:
ModuleClass Model
This section explains the design considerations of the ModuleClass
model.
Implementation
The class diagram below shows the current implementation of ModuleClass
model.
A ModuleClass
contains a Name
, and also a set of studentUuids
that is enrolled in the class.
A ModuleClass
can also contain any number of Lesson
objects.
Design Considerations
Aspect 1: Student storage
-
Alternative 1 (current choice): Store
Student
UUID
object inModuleClass
as aSet
. This implementation ensures that there are no duplicate students in a class.- Pros:
- Ensures that all students within a class are unique.
- Cons:
- There is a possibility of UUID collision, even though the probability is very low.
- Pros:
-
Alternative 2: Store
Student
object inModuleClass
.- Pros:
- Easy to implement.
- Cons:
- Difficult to check for duplicate students when adding or editing students in classes.
- Pros:
Lesson Model
This section explains the design considerations of the Lesson
model.
Implementation
The class diagram below shows the current implementation of Lesson
model.
Every Lesson
contains startTime
, endTime
, Day
, NumberOfOccurrences
, Venue
and AttendanceRecordList
.
The NumberOfOccurrences
represents the number of weeks the lesson takes place and the AttendanceRecordList
stores the
attendance of students. The implementation of Attendance model is explained in the next section.
![:information_source: :information_source:](https://github.githubassets.com/images/icons/emoji/unicode/2139.png)
Lesson
package are designed to be immutable.
A ModuleClass
can contain any number of Lesson
objects, but cannot contain duplicate Lesson
s or Lesson
s
with overlapping time.
Lesson
s are considered duplicate if they have the same start time, end time and day.
The sequence diagram below shows the interaction between Logic
and Model
when a Lesson
is added to ModuleClass
.
The utility methods for modifying Lesson
in ModuleClass
are in ModuleClassUtil
to avoid handling add, edit and
delete operations in the Model
component.
![:information_source: :information_source:](https://github.githubassets.com/images/icons/emoji/unicode/2139.png)
AddLessonCommand
should end at the destroy marker (X) but due to a
limitation of PlantUML, the lifeline reaches the end of diagram.
-
The
AddLessonCommand
execution will call static methods fromModuleClassUtil
. -
ModuleClassUtil
will check whetherlessonToAdd
already exists intargetModuleClass
by callinghasLesson(lessonToAdd)
. For eachLesson
in thetargetModuleClass
, this method will callLesson#isSameLesson(lessonToAdd)
. (This part is omitted from diagram for brevity) -
It will also check whether there is a
Lesson
with overlapping time intargetModuleClass
by callinghasOverlapLesson(lessonToAdd)
, which then callsLesson#isOverlapLesson(lessonToAdd)
. (The latter part is omitted from diagram for brevity) -
If
lessonToAdd
does not exist intargetModuleClass
and the timing does not overlap with any existingLesson
s, a newModuleClass
withlessonToAdd
will be created. Otherwise, aCommandException
will be thrown.
Design Considerations
Aspect 1: Maintaining immutability
A new Lesson
object will be created whenever there is a change to any of the attributes. This is to guarantee
the immutability of Lesson
.
Aspect 2: Uniqueness of Lesson
Two possible implementations were considered.
-
Alternative 1 (current choice): Store
Lesson
object inModuleClass
.
This implementation allows duplicate lessons in different classes.- Pros:
- Easy to implement.
- Cons:
- Difficult to check for duplicate lessons when adding or editing lessons as we will need to iterate through all classes.
- Pros:
-
Alternative 2: Implement UUID field for
Lesson
, whileModuleClass
stores UUID.This is similar to how
Student
is implemented. It would be a better alternative if we want all lessons to be unique as we can have aUniqueLessonList
to store all lessons as shown below.- Pros:
- Easy to check for duplicate lessons in different classes.
- Cons:
- There is a possibility of UUID collision, even though the probability is very low.
- Harder to implement.
- Pros:
Alternative 1 was chosen because it is possible to have the same lesson in different classes if users do not delete the data for previous semesters. Hence, we allowed for duplicate lessons in different classes. Furthermore, since users need to specify the class index when editing or deleting lessons, it makes alternative 1 easier to implement.
Attendance Model
This section explains the design considerations of the Attendance
model.
Implementation
The Attendance
, AttendanceRecord
and AttendanceRecordList
models are implemented as follows:
Attendance
encapsulates the information of a particular student’s attendance in a specific lesson he/she has attended.
AttendanceRecord
refers to the actual attendance roster of a particular lesson event.
It contains the Attendance
s of all Student
s who have attended the particular lesson.
These information are stored as a Map
with Student
UUID
as keys.
AttendanceRecordList
refers to the list of all AttendanceRecord
instances.
The size of this list is fixed and is determined by the NumberOfOccurences
in the Lesson
.
![:information_source: :information_source:](https://github.githubassets.com/images/icons/emoji/unicode/2139.png)
Attendance
package are designed to be immutable.
Design Considerations
Aspect 1: Reducing user input
Users should not have to type in attendance-related commands when the student is absent from a lesson.
Therefore, the Attendance
class does not have, for example, a boolean hasAttended
attribute.
It only has a participationScore
attribute.
Aspect 2: Maintaining immutability and optimising AttendanceRecord
-
Alternative 1 (current choice): Updating
AttendanceRecord
whenever there is a change to attendance.- Pros:
- Guarantees immutability.
- Cons:
- Requires re-instantiation of a
Map
object whenever a user adds/edits/deletes anAttendance
.
- Requires re-instantiation of a
- Pros:
-
Alternative 2: Initialising empty
Attendance
instances for all students on call to constructor method.
This would mean eachAttendance
is set to a particular value, whenever there is a change to anAttendanceRecord
.- Pros:
- Less overhead in modifying
Attendance
.
- Less overhead in modifying
- Cons:
- Violates immutability.
- Incurs greater memory use.
- Pros:
Alternative 1 was chosen as we prioritized immutability.
The main benefit of Alternative 2 is that the entire Map
object need not be copied everytime a user adds/edits/deletes an Attendance
.
However, this would violate immutability of the Attendance
package.
So, we have decided to implement Alternative 1.
Aspect 3: Handling of invalid Week
number
-
Alternative 1 (current choice): Store
AttendanceRecord
s in a fixed sizeList
.- Pros:
- Handles exceptions easily when a user inputs a week number greater than the total number of lessons.
- Provides constant time access as the week number is used as an index to the
List
. - Easier to iterate over for
StatisticsCommand
.
- Cons:
- Requires additional methods to ensure the size of the
List
is fixed.
- Requires additional methods to ensure the size of the
- Pros:
-
Alternative 2: Store a
Map
ofWeek
number toAttendanceRecord
.- Pros:
- Incurs less memory use.
- Cons:
- More difficult to iterate over for
StatisticsCommand
. - More difficult to implement as each
Week
number must be checked to ensure it does not exceedNumberOfOccurrences
inLesson
.
- More difficult to iterate over for
- Pros:
Alternative 1 was chosen as it was easier to check for invalid week numbers.
To check for invalid week numbers in Alternative 2, additional checks have to be performed within the AttendanceRecordList
class to ensure the week numbers do not exceed the NumberOfOccurrences
.
The sequence diagram below shows how an Attendance
instance is retrieved.
To avoid implementing add, edit and delete methods in the Attendance
package, we created utility classes to handle these operations instead.
These utility classes are ModuleClassUtil
, LessonUtil
and AttendanceRecordListUtil
.
Display Statistics Feature
The display statistics feature allows users to view a student’s average class participation score as well as lesson attendances.
This section explains the implementation of the display statistics mechanism and highlights the design considerations taken into account when implementing this feature.
Implementation
The display statistics mechanism is facilitated by StatisticsCommand
. It extends Command
.
The method, DisplayStatisticsCommand#execute()
performs a validity check and returns a specific student’s statistics if all validations pass.
The following class diagram shows the relationship between classes during the execution of a StatisticsCommand
:
The following sequence diagram shows the interactions within the Logic
component during the execution
of a StatisticsCommand
:
- The command execution calls static methods from the
ModuleClassUtil
andLessonUtil
classes. - As seen above,
ModuleClassUtil
then iterates through the list of lessons to calculate the student’s participation score and absent weeks by usingLessonUtil#getParticipationScoreFromLesson(lesson, student)
andLessonUtil#getAbsentWeekFromLesson(lesson, student)
respectively. -
StatisticsCommand
then encapsulates the result into aCommandResult
object which is passed back to theUi
.
Design Considerations
Aspect 1: How statistics feature executes
-
Alternative 1 (current choice): Extract the methods out to another class
(
ModuleClassUtil
andLessonClassUtil
).- Pros:
- Does not violate the law of demeter. Increases cohesion and thus increase maintainability and testability.
- Cons:
- Requires more wrapper methods to carry information.
- More effort to implement.
- Pros:
-
Alternative 2: Obtain all attendance information within
StatisticsCommand#execute()
.- Pros:
- Easy, straightforward to implement.
- Cons:
- Violates the law of demeter to a large extent.
- Pros:
Alternative 1 was chosen to maintain the testability of our code. In addition, abstracting out the
methods helps to increase reusability of the code. This provides StatisticsCommand#execute()
the ability to compute
the relevant results without knowing the low level implementations.
Aspect 2: Responsibility of relevant methods
-
Alternative 1 (current choice): Allow
ModuleClassUtil#getParticipationScore(...)
andModuleClassUtil#getAbsentWeek(...)
to return intermediate values.- Pros:
- Reduce the responsibilities of
ModuleClassUtil#getParticipationScore(...)
andModuleClassUtil#getAbsentWeek(...)
.
- Reduce the responsibilities of
- Cons:
- Additional processing required to process the results of the method calls in
StatisticsCommand#execute()
.
- Additional processing required to process the results of the method calls in
- Pros:
-
Alternative 2: Allow
ModuleClassUtil#getParticipationScore(...)
andModuleClassUtil#getAbsentWeek(...)
to return aString
representation directly.- Pros:
- Easy, straightforward to implement.
- Does not need to iterate through scores and weeks in
StatisticsCommand
.
- Cons:
-
ModuleClassUtil#getParticipationScore(...)
andModuleClassUtil#getAbsentWeek(...)
would have too many responsibilities. Violates the Single Responsibility Principle.
-
- Pros:
Add Attendance Feature
The add attendance feature allows users to record a student’s attendance and participation score for a specific week’s lesson.
This section explains the implementation of the add attendance mechanism and highlights the design considerations taken into account when implementing this feature.
Implementation
The add attendance mechanism is facilitated by AddAttendanceCommand
. It extends Command
.
The method, AddAttendanceCommand#execute()
, performs a validity check and adds a student’s attendance for a particular week’s lesson if all validations pass.
The following sequence diagram shows the interactions between the Model
and Logic
components during the execution
of an AddAttendanceCommand
with user input add-attendance c\1 l\1 s\1
represented by ...
:
-
Logic
uses theTutorsPetParser
class to parse the user command. - A new instance of an
AddAttendanceCommand
object would be created by theAddAttendanceCommandParser
and returned toTutorsPetParser
. -
TutorsPetParser
encapsulates theAddAttendanceCommand
object as aCommand
object which is executed by theLogicManager
. - The command execution calls
getFilteredStudentList()
andgetFilteredModuleClassList()
to get thetargetStudent
andtargetModuleClass
respectively using indexes from the user input. - As seen from the diagram above,
ModuleClassUtil#addAttendanceToModuleClass()
is then called. Execution of that method returns a newModuleClass
object with the new attendance of thetargetStudent
added. - The
targetModuleClass
in themodel
is then updated with the newModuleClass
object. - The change resulting from the command’s execution is saved using the
commit()
method for theundo
/redo
feature. - The result of the command execution is encapsulated as a
CommandResult
object which is passed back to theUi
.
The following activity diagram shows how the AddAttendanceCommand
works.
Design Considerations
Aspect 1: How AddAttendanceCommand
feature executes
-
Alternative 1 (current choice): User can only add one attendance at a time.
- Pros:
- Less complex code reduces the possibility of bugs.
- Cons:
- Less convenient for users as they would have to add attendances for the whole class one at a time.
- Pros:
![:information_source: :information_source:](https://github.githubassets.com/images/icons/emoji/unicode/2139.png)
-
Alternative 2: User can add multiple students’ attendances for a specific week’s lesson at the same time.
- Pros:
- Provides greater convenience for users as they can add attendances for the whole class in a single command.
- Greater flexibility as users can choose whether to key in attendance one at a time or all at once.
- Cons:
- More complex code leading to higher possibility of bugs.
- Pros:
Alternative 1 was chosen because the cons of implementing alternative 2 outweighs the benefits derived from it. It is unlikely for multiple students to have the same participation score and hence the use of this command with multiple students is likely to be low. In addition, users can make use of the recall feature to speed up the process of recording attendances.
Undo/Redo Feature
The undo/redo feature allows users to revert wrongly executed commands.
This section explains the implementation of the undo and redo mechanism and highlights the design considerations taken into account when implementing this feature.
Implementation
The undo/redo mechanism is designed around maintaining a history of Tutor’s Pet states, and restoring a particular state when the user triggers an undo or redo command.
The undo and redo mechanism is facilitated by VersionedTutorsPet
. It extends TutorsPet
with a history of Tutor’s Pet states,
stored internally as a list of TutorsPetState
. It also maintains a statePointer
to keep track of the undo/redo history.
A TutorsPetState
object contains a Tutor’s Pet state, represented as a ReadOnlyTutorsPet
, along with a message that describes the changes relevant to this state.
The class diagram below summarizes the relationships between the key classes used for the undo/redo feature:
Additionally, VersionedTutorsPet
implements the following operations:
-
VersionedTutorsPet#commit(String commitMessage)
– Saves the current Tutor’s Pet state, along with the corresponding commit message, in its history. -
VersionedTutorsPet#undo()
– Restores the previous Tutor’s Pet state from its history. -
VersionedTutorsPet#redo()
– Restores a previously undone Tutor’s Pet state from its history.
These operations are exposed in the Model
interface as Model#commit(String commitMessage)
, Model#undo()
and Model#redo()
respectively.
Given below is an example usage scenario and how the undo/redo mechanism behaves at each step:
-
The user launches the application for the first time. The
VersionedTutorsPet
will be initialized with the initial Tutor’s Pet state. This initial state will be saved into thetutorsPetStateList
, and thestatePointer
will point to this initialTutorsPetState
. -
The user executes
delete-student 5
command to delete the 5th student in Tutor’s Pet. Thedelete-student
command callsModel#commit(String commitMessage)
after it has deleted the student. This causes the modified state of Tutor’s Pet, after thedelete-student 5
command has executed, to be saved in thetutorsPetStateList
. ThestatePointer
will be updated to point to the newly insertedTutorsPetState
. -
The user executes
add-student n/David …
to add a new student. Theadd-student
command also callsModel#commit(String commitMessage)
after it has added the new student. This causes another modified Tutor’s Pet state to be saved into thetutorsPetStateList
.Note: If a command fails its execution, it will not call
Model#commit(String commitMessage)
. This prevents an erroneous duplicate state to be saved intotutorsPetStateList
. -
The user now decides that adding the student was a mistake, and decides to undo that action by executing the
undo
command. Theundo
command will callModel#undo()
, which shifts thestatePointer
once to the left, pointing it to the previous state, and restores Tutor’s Pet to that state.Note: If the
statePointer
is at index 0, pointing to the initial Tutor’s Pet state, then there are no previous Tutor’s Pet states to restore. Theundo
command usesModel#canUndo()
to check if this is the case. If so, it will return an error to the user rather than attempting to perform the undo. -
The user decides to execute the command
list
. Commands that do not modify the contents of Tutor’s Pet, such aslist
, do not callModel#commit(String commitMessage)
,Model#undo()
orModel#redo()
. Thus, thetutorsPetStateList
remains unchanged. -
The user then executes
clear
, which callsModel#commit(String commitMessage)
. Since thestatePointer
is not pointing to the last entry oftutorsPetStateList
, all Tutor’s Pet states after thestatePointer
will be purged. The new Tutor’s Pet state, after theclear
command has executed, will be saved into thetutorsPetStateList
.Future states after the
statePointer
are purged when saving a new state to maintain a linear history of revertible commands. This is the behaviour that most modern desktop applications follow.
The following sequence diagram shows how the undo operation works:
![:information_source: :information_source:](https://github.githubassets.com/images/icons/emoji/unicode/2139.png)
UndoCommand
should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of the diagram.
The redo
command does the opposite — it calls Model#redo()
, which shifts the statePointer
once to the right, pointing to the previously undone state, and restores Tutor’s Pet to that state.
![:information_source: :information_source:](https://github.githubassets.com/images/icons/emoji/unicode/2139.png)
statePointer
is at index tutorsPetStateList.size() - 1
, pointing to the latest Tutor’s Pet state, then there are no undone Tutor’s Pet states to restore.
The redo
command uses Model#canRedo()
to check if this is the case.
If so, it will return an error to the user rather than attempting to perform the redo.
The following activity diagram summarizes what happens when a user executes a new command:
Design Considerations
Aspect 1: How undo & redo executes
Two possible implementations of the undo/redo mechanism were considered.
-
Alternative 1 (current choice): Save all data stored in Tutor’s Pet at a given state.
- Pros:
- Easier to implement.
- Cons:
- Possible performance issues in terms of memory usage.
- Pros:
-
Alternative 2: Commands are designed such that they can reverse the result of their execution.
- Pros:
- Will use less memory (e.g. for
delete-student
, save only the student deleted, so that it can be restored whenundo
is called).
- Will use less memory (e.g. for
- Cons:
- We must ensure that the implementation of each individual command are correct.
- Pros:
Alternative 1 was chosen due to the limited time that was available for this project. The integrity of data was deemed to be more important than the performance of the application since the product was designed for single user scenarios and modern machines should be more than capable of handling the potential performance impact of alternative 1.
In addition, the immutable property of the data within the application made it significantly easier for alternative 1 to be implemented.
Aspect 2: Commands to support for undo/redo
A key purpose of the undo/redo feature is to prevent the accidental loss of data due to wrongly executed commands.
As such, it was decided, only commands that alter the data in Tutor’s Pet would have their state saved, since commands that do not alter the data of Tutor’s Pet would not have any data that would be irrecoverable from an earlier state.
Command Recall Feature
The command recall feature reduces the effort required by users when frequently entering similar commands. It allows users to view and reuse previously entered commands through the ↑ and ↓ keys when the command box is focused.
This section explains the implementation of the command recall feature and highlights the design considerations taken into account when implementing this feature.
Implementation
The command recall mechanism is designed around maintaining a list of previously executed commands, and traversing this list when the user requests to recall a previous command.
The command recall mechanism is facilitated by CommandHistory
, which consists of a list of previously executed commands,
stored internally as a list of String
, and a pointer
to determine the location of the currently recalled command.
In addition, it also consists of a cache, which is used to store the user’s existing input.
![:information_source: :information_source:](https://github.githubassets.com/images/icons/emoji/unicode/2139.png)
CommandHistory
does not persist when the application is exited.
When the application is started, the CommandHistory
is initialized with an empty list, and the pointer
is set to
the size of the list, currently zero. After each successful command has been executed, the user input used to trigger the command
will be appended to the list and the pointer
will be set to the size of the list (henceforth known as the default position).
The cache will also be cleared.
Note: With this implementation of the default position of the pointer,
if the text contained in the command box is a new user input,
then the
pointer
index is one greater than the last stored command.
This makes it easier to identify when the current text should be cached.
When the user presses the ↑ key, a check is performed to determine if there is a next available command to recall.
If there is a previous command available, CommandHistory
next checks if the pointer
is currently pointing to an entry in its list.
If the pointer
is not currently pointing to an entry in the list, i.e. in its default position,
the current text in the command box is stored in the cache.
Otherwise, there is no change to the cached value. Subsequently, CommandHistory
decreases its pointer
by one,
and the respective String
in the list is returned. The text in the command box is then set to the returned String
.
If there are no earlier commands to recall, then there is no change to the text in the command box.
![:information_source: :information_source:](https://github.githubassets.com/images/icons/emoji/unicode/2139.png)
When the user presses the ↓ key, a check is performed to determine if there is a next available command to recall.
If there is a next available command, the pointer
index is increased and the respective String
in the list is returned.
Otherwise, if there is no available next command, i.e. the pointer index is at the last element in the list, then the cached value (if there is one) is returned instead.
The activity diagram below provides a summary of the recall command mechanism.
Design Considerations
Aspect 1: Behaviour when returning from most recent recalled command
Two possible behaviours were considered when designing the recall command feature.
-
Alternative 1 (current choice): Restore any text the user had entered before recalling commands.
- Pros:
- The user does not loose any progress to partially typed commands.
- Cons:
- Difficult to implement as it introduces the need to conditionally store data.
- Pros:
-
Alternative 2: Reset the command box to its blank state.
- Pros:
- Easy to implement.
- Cons:
- The user looses any partially typed commands.
- Pros:
Alternative 1 was chosen as it followed the behaviour of common tools, such as the Unix Shell and Windows Command Prompt, that our target users were familiar with.
Documentation, Logging, Testing, Configuration, Dev-Ops
Appendix: Requirements
Product Scope
Target user profile:
- Has a need to manage students enrolled in one or more classes
- Has a need to record students’ attendance and participation scores
- Prefer desktop apps over other types
- Can type fast
- Prefers typing to mouse interactions
- Is reasonably comfortable using CLI apps
Value proposition: Manage students and classes faster than a typical mouse/GUI driven app
User Stories (Completed)
Priorities: High (must have) - * * *
, Medium (nice to have) - * *
, Low (unlikely to have) - *
Priority | As a … | I want to… | So that I can… |
---|---|---|---|
* * * | Tutor with many students | Store my students’ contact info/emails | Contact them easily |
* * * | Tutor with many classes | Insert my students into the appropriate classes | Organise my students via classes |
* * * | Tutor | Delete student entries | Update my list of students if a student were to drop the class |
* * * | Tutor with many classes | Create classes | Put my students in the appropriate classes |
* * * | New Tutor | View the help menu | Be familiar with application usage |
* * | Tutor with many students | Keep notes on each student’s performance | Track their progress over time |
* * | Tutor | Mark my student’s attendance and participation | Gauge each student’s participation level |
* * | Tutor | Update the information of my students | Update my understanding of the progress of my students |
* * | Tutor | Categorise my students into how well they are doing | Dedicate more time towards the weaker students |
* * | Tutor | View all my lessons | Manage my time more efficiently |
* * | Tutor | Set recurring events (eg. lessons for every week) | Avoid typing the same events |
* * | Busy Tutor | Store zoom links | Retrieve these zoom links for my lessons, consultations, etc. |
* * | Busy Tutor | Store class rooms | Be reminded of my lesson venues |
* * | Careless tutor | Undo my commands | Correct any errors when I input things wrongly |
* * | Careless Tutor | Redo my undone actions | Easily reverse my accidental undos. |
* | Caring tutor | Take note of student’s special needs, if any | Cater my teaching toward them |
User Stories (Not Implemented)
Priorities: High (must have) - * * *
, Medium (nice to have) - * *
, Low (unlikely to have) - *
Priority | As a … | I want to… | So that I can… |
---|---|---|---|
* * | Tutor | View my students’ test scores easily | Gauge my teaching efficiency |
* * | Tutor teaching CS modules | View my students’ GitHub | Gauge my student’s progress in their coding assignment |
* * | Tutor | Record my feedback for my students | Give participation points |
* * | Tutor | Calculate the mean, median, mode of my students’ scores | Gauge the overall performance of my class |
* * | Tutor | Store the questions asked by students | Provide students with answers immediately, for questions that were asked before |
* * | Tutor | Be reminded of my lessons | Attend them |
* * | Forgetful Tutor | Track all my tasks | Know which is of greater urgency |
* | Tutor | Store teaching feedback given by my students | Improve my teaching |
* | Tutor teaching modules that require many written assignments | View my student’s written submissions | Mark/review their homework |
* | Forgetful Tutor | Store picture of my students | Easily match their faces to their names |
* | Tutor | Prioritise my tasks | Work on important tasks first |
* | Forgetful Tutor | Set an alert for task deadlines | Complete my tasks on time |
* | Tutor | Find free time | Provide consultation for students |
* | Tutor | Store teaching feedback given by Professors | Improve my teaching |
* | Tutor | Manage my teaching materials | Find them easily |
* | Tutor | Keep track of the hours I have spent teaching/preparing for class | Be aware of how much time I have spent on teaching |
* | Tutor for many semesters | Archive my past semesters | Avoid cluttering the application |
Use Cases
Use Case ID | Description |
---|---|
UC01 | Add a student |
UC02 | List students |
UC03 | Edit a student |
UC04 | Find a student |
UC05 | Delete a student |
UC06 | Clear all students |
UC07 | Add a class |
UC08 | List classes |
UC09 | List students within a class |
UC10 | Edit a class |
UC11 | Find a class |
UC12 | Delete a class |
UC13 | Clear all classes |
UC14 | List students and classes |
UC15 | Link a student to a class |
UC16 | Unlink a student from a class |
UC17 | Add a lesson |
UC18 | Edit a lesson |
UC19 | Delete a lesson |
UC20 | Add an attendance record of a student |
UC21 | Edit the attendance record of a student |
UC22 | Find the attendance record of a student |
UC23 | Delete the attendance record of a student |
(For all use cases below, the System is Tutor's Pet
and the Actor is the user
, unless specified otherwise)
Use case: UC01 - Add a student
MSS
- User requests to add a student.
- User provides the parameters to be added.
-
Tutor’s Pet adds the student.
Use case ends.
Extensions
-
2a. The parameters provided are invalid.
-
2a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
-
3a. The student already exists.
-
3a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
Use case: UC02 - List students
MSS
- User requests to list students.
-
Tutor’s Pet shows a list of students.
Use case ends.
Use case: UC03 - Edit a student
MSS
- User requests to list students.
- Tutor’s Pet shows a list of students.
- User requests to edit a specific student in the list.
- User provides the parameters that are to be edited.
-
Tutor’s Pet edits the student’s information.
Use case ends.
Extensions
-
2a. The list is empty.
Use case ends.
-
3a. The given index is invalid.
-
3a1. Tutor’s Pet shows an error message.
Use case resumes at step 2.
-
-
4a. The parameters provided are invalid.
-
4a1. Tutor’s Pet shows an error message.
Use case resumes at step 2.
-
Use case: UC04 - Find a student
MSS
- User requests to find a student.
- User provides the parameters to find student.
- Tutor’s Pet finds the student.
-
Tutor’s Pet displays all matching students found.
Use case ends.
Extensions
-
3a. No students found.
-
3a1. Tutor’s Pet displays a message that no students are found.
Use case ends.
-
Use case: UC05 - Delete a student
MSS
- User requests to list students.
- Tutor’s Pet shows a list of students.
- User requests to delete a specific student in the list.
-
Tutor’s Pet deletes the student.
Use case ends.
Extensions
-
2a. The list is empty.
Use case ends.
-
3a. The given index is invalid.
-
3a1. Tutor’s Pet shows an error message.
Use case resumes at step 2.
-
-
3b. The student is associated to class(es).
-
3b1. Tutor’s Pet removes the student from the associated class(es).
Use case resumes at step 4.
-
Use case: UC06 - Clear all students
MSS
- User requests to clear all students.
-
Tutor’s Pet deletes all students.
Use case ends.
Extensions
-
1a. Some or all students are associated to class(es).
-
1a1. Tutor’s Pet removes all student entries in all class(es)
Use case resumes at step 2.
-
Use case: UC07 - Add a class
MSS
- User requests to add a class.
- User provides the parameters of the class.
-
Tutor’s Pet adds the class.
Use case ends.
Extensions
-
2a. The parameters provided are invalid.
-
2a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
-
3a. The class already exists.
-
3a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
Use case: UC08 - List classes
MSS
- User requests to list classes.
-
Tutor’s Pet shows a list of classes.
Use case ends.
Use case: UC09 - List students within a class
MSS
- User requests to list students within a class.
- User specifies the class.
-
Tutor’s Pet shows a list of students in the class.
Use case ends.
Extensions
-
2a. The given class index is invalid.
-
2a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
Use case: UC10 - Edit a class
MSS
- User requests to list classes.
- Tutor’s Pet shows a list of classes.
- User requests to edit a specific class in the list.
- User provides the parameters that are to be edited.
-
Tutor’s Pet edits the class’s information.
Use case ends.
Extensions
-
2a. The list is empty.
Use case ends.
-
3a. The given index is invalid.
-
3a1. Tutor’s Pet shows an error message.
Use case resumes at step 2.
-
-
4a. The parameters provided are invalid.
-
4a1. Tutor’s Pet shows an error message.
Use case resumes at step 2.
-
Use case: UC11 - Find a class
MSS
- User requests to find a class.
- User provides the parameters to find class.
- Tutor’s Pet finds the class.
-
Tutor’s Pet displays all matching classes found.
Use case ends.
Extensions
-
3a. No classes found.
-
3a1. Tutor’s Pet displays a message that no classes are found.
Use case ends.
-
Use case: UC12 - Delete a class
MSS
- User requests to list classes.
- Tutor’s Pet shows a list of classes.
- User requests to delete a specific class in the list.
-
Tutor’s Pet deletes the class.
Use case ends.
Extensions
-
2a. The list is empty.
Use case ends.
-
3a. The given index is invalid.
-
3a1. Tutor’s Pet shows an error message.
Use case resumes at step 2.
-
Use case: UC13 - Clear all classes
MSS
- User requests to clear all classes.
-
Tutor’s Pet clears all classes.
Use case ends.
Use case: UC14 - List students and classes
MSS
- User requests to list students and classes.
-
Tutor’s Pet shows a list of students and a list of classes.
Use case ends.
Use case: UC15 - Link a student to a class
MSS
- User requests to list classes.
- Tutor’s Pet shows a list of classes.
- User requests to list students.
- Tutor’s Pet shows a list of students.
- User requests to link a specific student to a specific class in the list.
-
Tutor’s Pet links the specified student to the specified class.
Use case ends.
Extensions
-
2a. The list is empty.
Use case ends.
-
4a. The list is empty.
Use case ends.
-
5a. At least one of the given indexes is invalid.
-
5a1. Tutor’s Pet shows an error message.
Use case resumes at step 4.
-
Use case: UC16 - Unlink a student from a class
MSS
- User requests to list classes.
- Tutor’s Pet shows a list of classes.
- User requests to list students.
- Tutor’s Pet shows a list of students.
- User requests to unlink a specific student from a specific class in the list.
-
Tutor’s Pet unlinks the specified student from the specified class.
Use case ends.
Extensions
-
2a. The list is empty.
Use case ends.
-
4a. The list is empty.
Use case ends.
-
5a. At least one of the given indexes is invalid.
-
5a1. Tutor’s Pet shows an error message.
Use case resumes at step 4.
-
-
6a. The specified student is not linked to the specified class.
-
6a1. Tutor’s Pet shows an error message.
Use case ends.
-
Use case: UC17 - Add a lesson
MSS
- User requests to add a lesson.
- User provides the parameters of the lesson.
-
Tutor’s Pet adds the lesson.
Use case ends.
Extensions
-
2a. The parameters provided are invalid.
-
2a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
-
3a. The lesson already exists.
-
3a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
Use case: UC18 - Edit a lesson
MSS
- User requests to edit a specific lesson.
- User provides the parameters that are to be edited.
-
Tutor’s Pet edits the lesson’s information.
Use case ends.
Extensions
-
1a. One or more of the given indexes are invalid.
-
1a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
-
2a. The parameters provided are invalid.
-
2a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
Use case: UC19 - Delete a lesson
MSS
- User requests to delete a specific lesson.
-
Tutor’s Pet deletes the lesson.
Use case ends.
Extensions
-
1a. One or more of the given indexes are invalid.
-
1a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
Use case: UC20 - Add an attendance record of a student
MSS
- User requests to add an attendance record of a student.
- User provides the parameters of the attendance record.
-
Tutor’s Pet adds the attendance record.
Use case ends.
Extensions
-
2a. The parameters provided are invalid.
-
2a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
-
3a. The attendance record already exists.
-
3a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
Use case: UC21 - Edit the attendance record of a student
MSS
- User requests to edit a specific attendance record.
- User provides the parameters that are to be edited.
-
Tutor’s Pet edits the attendance record’s information.
Use case ends.
Extensions
-
1a. One or more of the given indexes are invalid.
-
1a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
-
2a. The parameters provided are invalid.
-
2a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
Use case: UC22 - Find the attendance record of a student
MSS
- User requests to find an attendance record.
- User provides the parameters to find attendance record.
- Tutor’s Pet finds the attendance record.
-
Tutor’s Pet displays matching attendance record found.
Use case ends.
Extensions
-
3a. No attendance records found.
-
3a1. Tutor’s Pet displays a message that no attendance records are found.
Use case ends.
-
Use case: UC23 - Delete the attendance record of a student
MSS
- User requests to delete a specific attendance record.
-
Tutor’s Pet deletes the attendance record.
Use case ends.
Extensions
-
1a. One or more of the given indexes are invalid.
-
1a1. Tutor’s Pet shows an error message.
Use case resumes at step 1.
-
Non-Functional Requirements
- Should work on any mainstream OS as long as it has Java
11
or above installed. - Should be able to hold up to 1000 students and classes without a noticeable sluggishness in performance for typical usage.
- 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.
Glossary
- Mainstream OS: Windows, Linux, Unix, OS-X
Appendix: Instructions for Manual Testing
Given below are instructions to test the application manually.
![:information_source: :information_source:](https://github.githubassets.com/images/icons/emoji/unicode/2139.png)
General
Launch and shutdown
-
Initial launch
-
Download the jar file and copy into an empty folder.
-
Double-click the jar file.
Expected: Shows the GUI with a set of sample contacts. The window size may not be optimum.
-
-
Saving window preferences
-
Resize the window to an optimum size. Move the window to a different location. Close the window.
-
Re-launch the application by double-clicking the jar file.
Expected: The most recent window size and location is retained.
-
Undoing a previous change
-
Undoing the most recent change
-
Prerequisites: List all students and classes using the
list
command. There exists at least one class in the displayed class list. -
Test case:
delete-class 1
followed byundo
.
Expected: The first class is deleted after the first command. The deleted class reappears in the displayed class list after the second command. Details of the undonedelete
change shown in the status message.
-
-
Undoing commands that cannot be undone
-
Prerequisites: No commands executed beforehand since application launch.
-
Test case:
list
followed byundo
.
Expected: No change is undone. Error details shown in the status message. -
Test case:
undo
.
Expected: No change is undone. Error details shown in the status message.
-
Redoing an undone change
-
Redoing the most recently undone change
-
Prerequisites: List all students and classes using the
list
command. There exists at least one class in the displayed class list. -
Test case:
delete-class 1
followed byundo
thenredo
.
Expected: The first class is deleted after the first command. The deleted class reappears in the displayed class list after the second command. The first class is deleted again after the third command. Details of the redonedelete
change shown in the status message.
-
-
Redoing when there is no change history
-
Prerequisites: No commands executed beforehand since application launch.
-
Test case:
redo
.
Expected: No change is redone. Error details shown in the status message.
-
Viewing change history
-
Viewing change history
-
Prerequisites: No commands executed beforehand since application launch. There exists at least one class in the displayed class list.
-
Test case:
view-history
.
Expected: A single entry with the description: “Loaded save data.” appears. -
Test case:
delete-class 1
followed byview-history
.
Expected: Two entries are shown in the status message. The first being a brief description of the delete class action with the>
indicator beside it. The second being the “Loaded save data.” entry. -
Test case:
delete-class 1
followed byundo
and thenview-history
.
Expected: Two entries are shown in the status message. The first being a brief description of the delete class action. The second being the “Loaded save data.” entry with the>
indicator beside it.
-
Recalling previously entered commands
-
Recalling previously entered commands
-
Prerequisites: None.
-
Test case:
list
followed by pressing the ↑ key.
Expected:list
appears in the command box. -
Test case:
list
followed bylist-student
followed by pressing the ↑ key twice.
Expected:list-student
appears in the command box after the first ↑ key press.list
appears in the command box after the second ↑ key press. -
Test case:
list
followed by typingdelete-student 1
without execution, then pressing the ↑ and then ↓ key.
Expected:list
appears after the ↑ key press.delete-student 1
restored after the ↓ key press.
-
-
Recalling with no commands previously entered
-
Prerequisites: No commands executed beforehand since application launch.
-
Test case: Press the ↑ key.
Expected: No change to the command box text. No status message shown. -
Test case: Press the ↓ key.
Expected: No change to the command box text. No status message shown. -
Test case: Type
delete-student 1
without executing and press the ↑ key.
Expected: No change to the command box text. No status message shown. -
Test case: Type
delete-student 1
without executing and press the ↓ key.
Expected: No change to the command box text. No status message shown.
-
Saving data
-
Dealing with missing/corrupted data files
-
Prerequisites: There exists a data file.
-
Test case: Delete the data file and launch the application.
Expected: The application launches with sample data. -
Test case: Modify the data file by removing a field in a json object.
Expected: The application launches with no data.
-
Managing Students
Adding a student
-
Adding a student
-
Prerequisites: None.
-
Test case:
add-student n\Nancy Drew t\nancydrew e\nancy@drew.com tag\A star tag\student
Expected: The student with the fields entered should be added into the displayed student list. The tagsA star
andstudent
should be rendered. -
Test case:
add-student n\Eddie Davis t\davis_ed e\eddie@basie.com
Expected: The student with the fields entered should be added into the displayed student list. There should be no tags rendered. -
Other incorrect commands to try:
add-student
,add-student n\Ahmed Jamal
Expected: No student is added. Error details shown in the status message.
-
Editing a student
-
Editing a student
-
Prerequisites: There are at least 2 student currently displayed.
-
Test case:
edit-student 1 n\Jim Hetfield
Expected: The name of the first student is changed toJim Hetfield
. -
Test case:
edit-student 2 tag\
Expected: All tags of the second student are deleted. -
Other incorrect commands to try:
edit-student
,edit-student 0 n\Fiona Orange
Expected: No student is edited. Error details shown in the status message.
-
Deleting a student
-
Deleting a student while all students are being shown
-
Prerequisites: List all students using the
list-student
command. Multiple students in the list. -
Test case:
delete-student 1
Expected: First student is deleted from the list. Details of the deleted student shown in the status message. -
Test case:
delete-student 0
Expected: No student is deleted. Error details shown in the status message. -
Other incorrect delete commands to try:
delete-student
,delete-student x
(where x is larger than the size of student list)
Expected: No student is deleted. Error details shown in the status message.
-
Finding a student
-
Finding a student
-
Prerequisites: Student names that contain
Alex
andYu
. The sample data of Tutor’s Pet contains such names and can be used. -
Test case:
find-student alex
Expected: All students whose name containsalex
(case-insensitive) should be displayed. -
Test case:
find-student alex yu
Expected: All students whose name containsalex
oryu
(case-insensitive) should be displayed. -
Other incorrect commands to try:
find-student
.
Expected: The displayed student list does not get updated. Error details shown in the status message.
-
Managing Classes
Adding a class
-
Adding a new class
-
Prerequisites: A class named ST2334 does not exist in Tutor’s Pet.
-
Test case:
add-class n\ST2334
Expected: ClassST2334
is successfully added into the displayed class list. -
Test case:
add-class 1 n\ST2334
Expected: No class is added. Error details shown in the status message. -
Test case:
add-class n\ST2334 @ 1200
Expected: No class is added. Error details shown in the status message. -
Other incorrect add commands to try:
add-class
,add-class n\
Expected: No class is added. Error details shown in the status message.
-
-
Adding an existing class
-
Prerequisites: At least one class exists in Tutor’s Pet. Let the name of this class be
NAME
. -
Test case:
add-class n\NAME
Expected: No class is added. Error details shown in the status message.
-
Listing all students within a class
-
List all students within a class
-
Prerequisites: List all classes using the
list-class
command. Uses default tutor’s pet data. -
Test case:
list-student c\1
Expected: Displays the students in the first class of the class list. -
Test case:
list-student c\3
Expected: No student is displayed. -
Other incorrect list student commands to try:
list-student c\x
(where x is larger than the size of class list)
Expected: No student is listed. Error details shown in the status message.
-
Editing a class
-
Editing a class
-
Prerequisites: List all classes using the
list-class
command. At least one class in the class list. -
Test case:
edit-class 1 n\Edited Class
Expected: Name of the first class in the class list have been edited toEdited Class
. Details of edited class shown in the status message. -
Test case:
edit-class
Expected: No class is edited. Error details shown in the status message. -
Other incorrect edit commands to try:
edit-class 1 n\!
,edit-class x n\New Name
(where x is larger than the size of class list)
Expected: No class is edited. Error details shown in the status message.
-
Finding a class
-
Find a class
-
Prerequisites: List all classes using the
list-class
command. Has class(es) with the nameCS2103T
but not2103T
. -
Test case:
find-class CS2103T
Expected: All classes with the nameCS2103T Tutorial
is displayed. -
Test case:
find-class 2103T
Expected: No class displayed.
-
Deleting a class
-
Deleting a class while all classes are being shown
-
Prerequisites: List all classes using the
list-class
command. Multiple classes in the list. -
Test case:
delete-class 1
Expected: First class is deleted from the list. Details of the deleted class shown in the status message. -
Test case:
delete-class 0
Expected: No class is deleted. Error details shown in the status message. -
Other incorrect delete commands to try:
delete-class
,delete-class x
(where x is larger than the size of class list)
Expected: No class is deleted. Error details shown in the status message.
-
Clearing all classes
-
Clearing all classes
-
Prerequisites: List all classes using the
list-class
command. At least one class in the class list. -
Test case:
clear-class
Expected: All classes cleared.
-
Adding a student to a class
-
Adding a student to a class
-
Prerequisites: List all students and classes using the
list
command. Uses default tutor’s pet data. -
Test case:
link c\1 s\4
Expected: Student added to class. Details of added student and class shown in status message. Class list filters to show only the involved class. Student list filters to show only students of the class. -
Test case:
link c\1 s\1
Expected: No student is added to any class. Error details shown in status message. -
Other incorrect link commands to try:
link c\1
,link s\1
,link c\0 s\0
Expected: No student is added to any class. Error details shown in status message.
-
Removing a student from a class
-
Removing a student from a class
-
Prerequisites: List all students and classes using the
list
command. Uses default tutor’s pet data. -
Test case:
unlink c\1 s\1
Expected: Student removed from class. Details of removed student and class shown in status message. Class list filters to show only the involved class. Student list filters to show only remaining students of the class. -
Test case:
unlink c\1 s\4
Expected: No student is removed from any class. Error details shown in status message. -
Other incorrect unlink commands to try:
unlink c\1
,unlink s\1
,unlink c\0 s\0
Expected: No student is removed from any class. Error details shown in status message.
-
Managing Lessons
Adding a lesson
-
Adding a lesson while all lessons are displayed
-
Prerequisites: List all classes using the
list-class
command. -
Test case:
add-lesson c\1 d\Tuesday st\08:00 et\10:00 v\COM1-0211 r\13
Expected: Lesson added. Details of the added lesson shown in the status message. -
Test case:
add-lesson c\1 d\Tuesday st\08:00 et\10:00 v\COM1-0211 r\0
Expected: No lesson is added. Error details shown in the status message. -
Other incorrect add commands to try:
add-lesson c\1 d\TUESDAY st\08:00 et\10:00 v\COM1-0211 r\13
,add-lesson c\1 d\Tuesday st\10:00 et\09:00 v\COM1-0211 r\13
Expected: No lesson is added. Error details shown in the status message.
-
Editing a lesson
-
Editing a lesson while all lessons are displayed
-
Prerequisites: List all classes using the
list-class
command. The first class contains at least two lessons. -
Test case:
edit-lesson c\1 l\1 d\sunday et\x
(where x is a time later than the lesson’s start time)
Expected: The day and end time of the first lesson in the first class will be changed to Sunday and x respectively. -
Test case:
edit-lesson c\1 l\2 st\x
(where x is a time earlier than the lesson’s end time)
Expected: The start time of the second lesson in the first class will be changed to x. -
Other incorrect edit commands to try:
edit-lesson c\0 l\3
,edit-lesson c\1 l\1 st\13:00 et\11:00
,edit-lesson c\1 l\x
(where x is larger than the total number of lessons in the class)
Expected: No lesson is edited. Error details shown in the status message.
-
Deleting a lesson
-
Deleting a lesson while all lessons are displayed
-
Prerequisites: List all classes using the
list-class
command. The first class contains at least one lesson. -
Test case:
delete-lesson c\1 l\1
Expected: First lesson in first class has been deleted from the list. Details of the deleted lesson shown in the status message. -
Test case:
delete-lesson c\1 l\0
Expected: No lesson is deleted. Error details shown in the status message. -
Other incorrect delete commands to try:
delete-lesson
,delete-lesson c\x l\1
(where x is larger than the number of lesson in a specific class)
Expected: No lesson is deleted. Error details shown in the status message.
-
Displaying a lesson’s venue
-
Displaying a lesson’s venue
-
Prerequisites: List all classes using the
list-class
command. Uses default tutor’s pet data. -
Test case:
display-venue c\1 l\1
Expected: Venue for the first lesson in the first class of the class list found. Details of the venue shown in the status message. -
Test case:
display-venue c\1 l\2
Expected: Venue not found. Error details shown in the status message. -
Other incorrect display venue commands to try:
display-venue c\1 l\a
Expected: Venue not found. Error details shown in the status message.
-
Managing Attendance Records
Adding an attendance
-
Adding an attendance
-
Prerequisites: List all classes and students using the
list
command. Uses default tutor’s pet data. -
Test case:
add-attendance c\1 l\1 s\1 w\3 p\70
Expected: Attendance added. Details of the attendance shown in the status message. -
Test case:
add-attendance c\1 l\1 s\1 w\2 p\70
Expected: No attendance added. Reason stated in the status message. -
Other incorrect add commands to try:
add-attendance c\1 l\1 s\1 w\3 p\101
,add-attendance c\x l\1 s\1 w\3 p\70
(where x is larger than the size of class list)
Expected: No attendance added. Error details shown in the status message.
-
Editing an attendance
-
Edit an attendance
-
Prerequisites: List all classes and students using the
list
command. Uses default tutor’s pet data. -
Test case:
edit-attendance c\1 l\1 s\1 w\2 p\60
Expected: Attendance edited. Details of the edited attendance shown in the status message. -
Test case:
edit-attendance c\1 l\1 s\1 w\10 p\70
Expected: Attendance not edited. Reason stated in the status message. -
Other incorrect edit commands to try:
edit-attendance c\1 l\1 s\1 w\3 p\101
,edit-attendance c\x l\1 s\1 w\3 p\70
(where x is larger than the size of class list)
Expected: Attendance not edited. Error details shown in the status message.
-
Finding an attendance
-
Find an attendance
-
Prerequisites: List all classes and students using the
list
command. Uses default tutor’s pet data. -
Test case:
find-attendance c\1 l\1 s\1 w\1
Expected: Attendance found. Attendance details of the student shown in the status message. -
Test case:
find-attendance c\1 l\1 s\1 w\3
Expected: Attendance not found. Reason stated in the status message. -
Test case:
find-attendance c\1 l\1 s\4 w\3
Expected: Attendance not found. Reason stated in the status message. -
Other incorrect find commands to try:
find-attendance c\1 l\1 s\4 w\54
,find-attendance c\x l\1 s\4 w\3
(where x is larger than the size of class list)
Expected: Attendance not found. Error details shown in the status message.
-
Deleting an attendance
-
Delete an attendance
-
Prerequisites: List all classes and students using the
list
command. Uses default tutor’s pet data. -
Test case:
delete-attendance c\1 l\1 s\1 w\1
Expected: Attendance deleted. Attendance details of the student shown in the status message. -
Test case:
delete-attendance c\1 l\1 s\1 w\3
Expected: No attendance deleted. Reason stated in the status message. -
Other incorrect add commands to try:
delete-attendance c\1 l\1 s\1 w\54
,delete-attendance c\x l\1 s\1 w\1
(where x is larger than the size of class list)
Expected: No attendance deleted. Error details shown in the status message.
-
Displaying a student’s statistics
-
Displaying a student’s statistics
-
Prerequisites: List all classes and students using the
list
command. Uses default tutor’s pet data. -
Test case:
stats c\1 s\1
Expected: Statistics for the first student in the first class of the student list and class list respectively found. Details of the statistics shown in the status message. -
Test case:
stats c\1 s\4
Expected: Statistics not found. Reason stated in the status message. -
Other incorrect display stats commands to try:
stats c\1 s\a
,stats c\1 s\x
(where x is larger than the size of student list)
Expected: Statistics not found. Error details shown in the status message.
-