KAJI - Developer Guide

By: Team CS2113T-F11-3 Since: August 2020

Table of Contents

  1. Introduction
    1.1. Overview
    1.2. Purpose
    1.3. Scope
  2. Setting Up
    2.1. Prerequisites
    2.2. Setting Up the Project in your Computer
    2.3. Verifying the Setup
  3. Design (Architecture)
    3.1. Ui Component
    3.2. Logic Component
    3.3. Model Component
    3.4. Storage Component
    3.5. Common Component
  4. Implementation
    4.1. Admin Features
           4.1.1. Add Module Feature
           4.1.2. List Modules Feature
           4.1.3. Edit Module Name Feature
           4.1.4. Remove Module Feature
           4.1.5. Access Module Level Feature
    4.2. Module Features
           4.2.1. Add Chapter Feature
           4.2.2. List Chapters Feature
           4.2.3. Edit Chapter Name Feature
           4.2.4. Remove Chapter Feature
           4.2.5. Access Chapter Level Feature
           4.2.6. Return to Admin Level Feature
    4.3. Chapter Features
           4.3.1. Add Flashcard Feature
           4.3.2. List Flashcards Feature
           4.3.3. Edit Flashcard Content Feature
           4.3.4. Remove Flashcard Feature
           4.3.5. Return to Module Level Feature
           4.3.6. Check Overall Performance for a Chapter Feature
    4.4. Revise with Scheduling Feature
           4.4.1. Revise Feature
           4.4.2. Scheduling The Chapters Feature
    4.5. Viewing and Customising the Schedule Feature
           4.5.1. View Due Chapters Feature
           4.5.2. Preview Upcoming Dues Feature
           4.5.3. Exclusion Feature
           4.5.4. Reschedule Chapter Feature
           4.5.5. View Revision History Feature
  5. Appendices
    5.1. Appendix A: Product Scope
           5.1.1. Target User Profile
           5.1.2. Value Proposition
    5.2. Appendix B: User Stories
    5.3. Appendix C: Use Cases
    5.4. Appendix D: Non-Functional Requirements
    5.5. Appendix E: Glossary
    5.6. Appendix F: Instructions for Manual Testing
           5.6.1. Launch and Shutdown
           5.6.2. Showing a list of commands
           5.6.3. Adding a module/chapter/flashcard
           5.6.4. Listing modules/chapters/flashcards
           5.6.5. Editing a module/chapter/flashcard
           5.6.6. Removing a module/chapter/flashcard
           5.6.7. Accessing the next level
           5.6.8. Going back to the previous level
           5.6.9. Rescheduling a chapter
           5.6.10. Starting a revision session
           5.6.11. Checking percentage of rating for the cards in a chapter
           5.6.12. Listing all chapters that are due on current date
           5.6.13. Previewing list of chapters due in a week
           5.6.14. Viewing history of revision completed in a day
           5.6.15. Excluding a module/chapter
           5.6.16. Including a module/chapter

1. Introduction

1.1. Overview

KAJI is a schedule manager that implements Spaced Repetition for students, optimised for use via a Command Line Interface (CLI).

1.2. Purpose

This document describes the architecture and system design for the application, KAJI.

1.3. Scope

This documentation describes the software architecture and software design decisions for the implementation of KAJI. The intended audience of this document is the developers, designers, and software testers of Kaji.

Back to Top ^

2. Setting Up

2.1. Prerequisites

  1. JDK 11
  2. IntelliJ IDEA

2.2. Setting up the Project in your Computer

  1. Fork this repository, and clone the fork into your computer.
  2. Open IntelliJ (if you are not in the welcome screen, click File → Close Project to close the existing project dialog first).
  3. Set up the correct JDK version for Gradle.
    1. Click Configure → Project Defaults → Project Structure.
    2. Click New… and set it to the directory of the JDK.
  4. Click Import Project (or Open or Import in newer version of Intellij).
  5. Locate the build.gradle file (not the root folder as you would do in a normal importing) and select it. Click OK. If asked, choose to Open as Project (not Open as File).
  6. Click OK to accept the default settings.

2.3. Verifying the Setup

  1. In an IntelliJ terminal, run gradlew build.
  2. Navigate to the folder build > libs by executing cd build/libs/ and then run: java -jar kaji.jar.
    1. To use KAJI, type a valid command into the terminal and press the enter key to run the command.
      e.g. Typing help and pressing the enter key will show the list of commands available.
    2. Some example commands you can try to get familiar with KAJI:
      • help: Lists the commands that KAJI supports.
      • add CS2113T: Adds a module CS2113T.
      • list: Shows a list of modules available.
      • exit: Exits KAJI.
Back to Top ^

3. Design (Architecture)

Architecture Diagram
Figure 1. Architecture diagram of KAJI

The Architecture Diagram given above explains the high-level design of the App. Given below is a quick overview of each component.

The main class is Kaji.java. It is responsible for:

The rest of the App consists of 8 components:

The sections below give more details of each component.

3.1. Ui Component

Class Diagram of Ui Component
Figure 2. Class diagram of Ui component

The Ui component consists of a main class — Ui.java. While KAJI has Ui as its class variable so that it can instantiate a Ui object at each run of the program, the Model, Logic and Storage components have a dependency on the Ui component due to the need to take in user input and show the results of execution.

The Ui component is responsible for:

3.2. Logic Component

The Logic component consists of the Parser, Command and Scheduler classes as shown in the class diagram below:

Logic Class Diagram
Figure 3. Class diagram of Logic component

  1. KAJI uses the Parser class to parse the user command.
  2. This results in a Command object which is executed by KAJI.
  3. The command execution can affect the Model and Storage (e.g. adding a module).
  4. The Scheduler is used in some command execution to schedule the due date of a chapter.
  5. The result of the command execution is passed to the Ui.

Given below is the Sequence Diagram for interactions within the Logic component for the parse("edit 1 CS2113T") API call:

Logic Sequence Diagram
Figure 4. Sequence diagram of Logic component

:information_source: Note: The lifeline for Parser and EditCommandParser should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

3.3. Model Component

The Model component consists of the Access, History, DueChapter, ModuleList, ChapterList and CardList classes as shown in the class diagram below:

Architecture Diagram of Model
Figure 5. Class diagram of Model component

The Model component

3.4. Storage Component

The Storage component consists of the Storage, StorageWrite, StorageParser and StorageLoad classes.

Storage Class Diagram
Figure 6. Class diagram of Storage component

The Storage component

3.5. Common Component

The Common component consists of KajiLog and Messages as shown in the class diagram below:

Common Class Diagram
Figure 7. Class diagram of Common component

The Common component

Back to Top ^

4. Implementation

This section will describe the significant details of how the features in KAJI are being implemented.

4.1. Admin Features

This section will elaborate the available features to users at Admin Level.
At Admin Level, users are able to:

4.1.1. Add Module Feature

Implementation

The add modules feature allows the user to create new modules at Admin level.

AddModuleCommand facilitates the proposed add module feature. It extends AddCommand with an AddCommand#prepareResult() method. This method formates message about the result of the action to user in Ui.

Shown as the class diagram below, because of the inheritance of AddCommand, Command and AddModuleCommand, Kaji is able to execute the operation AddModuleCommand#excute().

Class Diagram of add module command
Figure 8. Class diagram of add module command

Given below is an example usage scenario at Admin level and how the add module feature behaves at each step:

The following diagram shows how the add module command feature works:

Sequence Diagram of add module command
Figure 9. Sequence diagram of add module command

4.1.2. List Modules Feature

Implementation

The list modules feature allows the user to list all modules in admin level

The list modules mechanism is facilitated by ListModulesCommand. It extends from the abstract class ListCommand.

In addition, it implements the following operations:

The following diagram shows the class diagram of the list modules feature:

List Modules Class Diagram
Figure 10. Class diagram of list modules feature

For instance, the user wants to list all modules available in admin, a detailed description of what happens is shown below:

The following sequence diagram shows how the list modules feature works:

Sequence Diagram of List Modules
Figure 11. Sequence diagram of list modules

4.1.3. Edit Module Name Feature

Implementation

The edit module name feature allows the user to edit the name of any existing module.

The user can edit the name of an existing module with the edit command, which follows the following format: edit MODULE_INDEX MODULE_NAME.

The edit module name feature is facilitated by ModuleList and Module. The list of user’s modules are stored internally as ModuleList. In addition, it implements the following operations:

The following diagram shows the class diagram of the edit module name feature:

Edit Module Class Diagram
Figure 12. Class diagram of edit module name feature

For instance, the user wants to edit the module CS2113, a detailed description of what happens is shown below:

The following sequence diagram shows how the edit module name feature works:

Edit Module Sequence Diagram
Figure 13. Sequence diagram of edit module name feature

:information_source: Note: The lifeline for Admin should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

4.1.4. Remove Module Feature

Implementation

The remove module feature allows the user to remove a module by specifying the index of the module in the list.

The remove module mechanism is facilitated by RemoveModuleCommand. It extends from the abstract class RemoveCommand.

In addition, it implements the following operations:

The following diagram shows the class diagram of the remove module feature:

Class Diagram of Remove Module
Figure 14. Class diagram of remove module

For instance, the user wants to start a remove the module CS2113T, a detailed description of what happens is shown below:

The following sequence diagram shows how the remove module feature works:

Sequence Diagram of Remove Module
Figure 15. Sequence diagram of remove module

4.1.5. Access Module Level Feature

Implementation

The go modules feature allows the user to access the existing module from Admin level.

GoModuleCommand class facilitates the proposed access module level feature. It extends GoCommand class.

It implements the following operations:

Shown as the class diagram below, with the inheritance of GoCommand and Command, Kaji is able to execute the operation GoModuleCommand#execute() directly.

Class Diagram of go module command
Figure 16. Class diagram of go module command

Given below is an example usage scenario at Admin level and how the access module level feature behaves at each step:

The following diagram shows how the add chapter command feature works:

Sequence Diagram of add chapter command
Figure 17. Sequence diagram of add chapter command

Back to Top ^

4.2. Module Features

This section will elaborate the available features to users at Module Level.
At Module Level, users are able to:

4.2.1. Add Chapter Feature

Implementation

The add chapter feature allows the user to create new chapters at Module level.

AddChapterCommand facilitates the proposed add chapter feature. It extends AddCommand with an AddCommand#prepareResult() method. This method formats message about the result of the action to user in Ui.

Shown as the class diagram below, because of the inheritance of AddCommand, Command and AddChapterCommand, Kaji is able to execute the operation AddChapterCommand#excute().

Class Diagram of add chapter command
Figure 18. Class diagram of add chapter command

Given below is an example usage scenario at Module level and how the add chapter feature behaves at each step:

The following diagram shows how the add chapter command feature works:

Sequence Diagram of add chapter command
Figure 19. Sequence diagram of add chapter command

4.2.2. List Chapters Feature

Implementation

The list chapters feature allows the user to list all chapters in module level

The list chapters mechanism is facilitated by ListChaptersCommand. It extends from the abstract class ListCommand.

In addition, it implements the following operations:

The following diagram shows the class diagram of the list chapters feature:

List Chapters Class Diagram
Figure 20. Class diagram of list chapters feature

For instance, the user wants to list all chapters available in CS2113T (module name), a detailed description of what happens is shown below:

The following sequence diagram shows how the list chapters feature works:

Sequence Diagram of List Chapters
Figure 21. Sequence diagram of list chapters

4.2.3. Edit Chapter Name Feature

Implementation

The edit chapter name feature allows the user to edit the name of any existing chapter.

The user can edit the name of an existing chapter with the edit command, which follows the following format: edit CHAPTER_INDEX CHAPTER_NAME.

The edit module name feature is facilitated by ChapterList and Chapter. The list of user’s chapters are stored internally as ChapterList. In addition, it implements the following operations:

The following diagram shows the class diagram of the edit chapter name feature:

Edit Chapter Class Diagram
Figure 22. Class diagram of edit chapter name feature

For instance, the user wants to edit the chapter chap 1 from the module CS2113T, a detailed description of what happens is shown below:

The following sequence diagram shows how the edit chapter name feature works:

Edit Chapter Sequence Diagram
Figure 23. Sequence diagram of edit chapter name feature

:information_source: Note: The lifeline for Module should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

4.2.4. Remove Chapter Feature

Implementation

The remove chapter feature allows the user to remove a chapter by specifying the index of the chapter in the list. The remove chapter mechanism is facilitated by RemoveChapterCommand. It extends from the abstract class RemoveCommand.

In addition, it implements the following operations:

The following diagram shows the class diagram of the remove chapter feature:

Class Diagram of Remove Chapter
Figure 24. Class diagram of remove chapter

For instance, the user wants to start a remove the chapter Chapter 1 from the module CS2113T, a detailed description of what happens is shown below:

The following sequence diagram shows how the remove chapter feature works:

Sequence Diagram of Remove Chapter
Figure 25. Sequence diagram of remove chapter

4.2.5. Access Chapter Level Feature

Implementation

If a user wishes to go to the Chapter Level from the Module Level by accessing a Chapter within the Module he is currently in, he can do so with the Access Chapter Level Feature.

To execute this feature, the following class was created:

To support the Access Chapter Level Feature, GoChapterCommand implements the following operations:

The following diagram shows the class diagram of the Access Chapter feature:

Class Diagram of Access Chapter
Figure 26. Class diagram of access chapter

Example

For instance, the user is currently in the Module CS2113T and would like to go to the Chapter ‘Chapter 1’ on the Chapter level. A detailed description of what happens is shown below:

Step 1: The user enters go 1 as CS2113T is the first Module in list.

Step 2: The user input is parsed by Parser, and Parser creates a GoCommandParser object, which in turn creates a GoChapterCommand object, with 1 as the command argument.

Step 3: GoChapterCommand is executed, and GoChapterCommand#goChapter() is called.

Step 4: GoChapterCommand#goChapter() calls Access#getModule(), Access#getChapters() and ChapterList#getAllChapters() to obtain an ArrayList of Chapters.

Step 5: Using the command argument as the chapterIndex, and all the Cards within the Chapter are loaded with Storage#loadCard() into an ArrayList of Cards.

Step 6: Lastly, to finish the transition into the Chapter level, Access#setChapterLevel(), Chapter#setCards() and Access#setChapter are called.

The following sequence Diagrams illustrates how the Access Chapter Level Feature is executed:

Go Chapter Sequence Diagram
Figure 27. Sequence diagram of access chapter level feature

4.2.6. Return to Admin Level Feature

Implementation

If a user has completed the tasks he has on the Module Level and wish to edit Modules from the Admin level, he can do so with the return to Admin Level Feature.

To execute this feature, the following class was created:

To support the Return to Admin Level Feature, BackAdminCommand implements the following operation:

The following diagram shows the class diagram of the Return to Admin Level feature:

Class Diagram of Access Chapter
Figure 28. Class diagram of access chapter

Example

For instance, the user is currently in the Module CS2113T and would like to return to the Admin Level. A detailed description of what happens is shown below:

Step 1: The user enters back.

Step 2: The user input is parsed by Parser, and Parser creates a BackCommandParser object, which in turn creates a BackAdminCommand object

Step 3: BackAdminCommand is executed, and Access#setModuleLevel() is called.

Step 4: Access#setModuleLevel() verifies that the user is not on the Admin level at the moment, and calls Access#setBackAdminLevel(), which sets the user back into the Admin Level.

The following sequence Diagrams illustrates how the Return to Admin Level Feature is executed:

Back Admin Sequence Diagram
Figure 29. Sequence diagram of return to admin level feature

Back to Top ^

4.3. Chapter Features

This section will elaborate the available features to users at Chapter Level.
At Chapter Level, users are able to:

4.3.1. Add Flashcard Feature

Implementation

The add flashcard feature allows the user to add a flashcard to a chapter.

The user can add a flashcard with the add command, which follows the following format: add q:QUESTION | a: ANSWER.

The add flashcard feature is facilitated by CardList. The list of user’s flashcards are stored internally as CardList. In addition, it implements the following operation:

The following diagram shows the class diagram of the add flashcard feature:

Add Card Class Diagram
Figure 30. Class diagram of add flashcard feature

For instance, the user wants to add a flashcard [Q] 1+1 | [A] 2 to the chapter Chapter 1 for module CS2113T, a detailed description of what happens is shown below:

The following sequence diagram shows how the add flashcard feature works:

Add Card Sequence Diagram
Figure 31. Sequence diagram of add flashcard feature

:information_source: Note: The lifeline for Chapter should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

4.3.2. List Flashcards Feature

Implementation

The list flashcards feature allows the user to list all flashcards in chapter level

The list flashcards mechanism is facilitated by ListCardsCommand. It extends from the abstract class ListCommand.

In addition, it implements the following operations:

The following diagram shows the class diagram of the list flashcards feature:

List Flashcards Class Diagram
Figure 32. Class diagram of list flashcards feature

For instance, the user wants to list all flashcards available in Chapter 1 (chapter name), a detailed description of what happens is shown below:

The following sequence diagram shows how the list flashcards feature works:

Sequence Diagram of List Cards
Figure 33. Sequence diagram of list cards

4.3.3. Edit Flashcard Content Feature

Implementation

The edit flashcard content feature allows the user to edit the content of any existing flashcard.

The user can edit the content of an existing flashcard with the edit command, which follows the following format: edit FLASHCARD_INDEX q:QUESTION | a: ANSWER.

The edit flashcard content feature is facilitated by CardList and Card. The list of user’s flashcards are stored internally as CardList. In addition, it implements the following operations:

The following diagram shows the class diagram of the edit flashcard content feature:

Edit Flashcard Class Diagram
Figure 34. Class diagram of edit flashcard content feature

For instance, the user wants to edit the flashcard [Q] 2*1 | [A] 2 from the chapter Chapter 1 for module CS2113T, a detailed description of what happens is shown below:

The following sequence diagram shows how the edit flashcard content feature works:

Edit Card Sequence Diagram
Figure 35. Sequence diagram of edit flashcard content feature

:information_source: Note: The lifeline for Chapter should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

4.3.4. Remove Flashcard Feature

Implementation

The remove flashcard feature allows the user to remove a flashcard by specifying the index of the flashcard in the list. The remove flashcard mechanism is facilitated by RemoveFlashcardCommand. It extends from the abstract class RemoveCommand.

In addition, it implements the following operations:

The following diagram shows the class diagram of the remove flashcard feature:

Class Diagram of Remove Flashcard
Figure 36. Class diagram of remove flashcard

For instance, the user wants to start a remove the flashcard [Q] 1+1 | [A] 2 from the chapter Chapter 1, a detailed description of what happens is shown below:

The following sequence diagram shows how the remove flashcard feature works:

Sequence Diagram of Remove Flashcard
Figure 37. Sequence diagram of remove flashcard

4.3.5. Return to Module Level Feature

Implementation

The return to module level feature allows the user to return to the module level from the chapter level. The return to module level mechanism is facilitated by BackModuleCommand. It extends from the abstract class BackCommand.

In addition, it implements the following operation:

The following diagram shows the class diagram of the return to module feature:

Class Diagram of Return to Module
Figure 38. Class diagram of return to module

For instance, the user wants to return to the module level from the chapter he is currently at in the module CS2113T, a detailed description of what happens is shown below:

The following sequence diagram shows how the return to module feature works:

Sequence Diagram of Return to Module
Figure 39. Sequence diagram of return to module

4.3.6. Check Overall Performance for a Chapter Feature

Implementation

The show rate feature allows the user to check their overall performance of revision with the chapter they are currently accessing.

ShowRateCommand facilitates the proposed check overall performance feature. It extends an abstract Command class with the abstract Command#execute() and Command#isExit().

It implements the following operations:

Shown as the class diagram below, with the inheritance of Command, Kaji is able to execute the operation ShowRateCommand#execute() directly.

Class Diagram of show overall performance command
Figure 40. Class diagram of show overall performance command

Given below is an example usage scenario at Chapter level and how the show overall performance feature behaves at each step:

The following diagram shows how the show overall performance feature works:

Sequence Diagram of show overall performance command
Figure 41. Sequence diagram of show overall performance command

Back to Top ^

4.4. Revise with Scheduling Feature

The revise feature allows the user to start a revision on a chapter and can only be done when the user is in the module level.

4.4.1. Revise Feature

Implementation

The revise mechanism is facilitated by ReviseCommand. It extends from the abstract class Command.

In addition, it implements the following operations:

The following diagram shows the class diagram of the revise feature:

Class Diagram of Revise
Figure 42. Class diagram of revise

For instance, the user wants to start a revision for Chapter 1 in the module CS2113T, a detailed description of what happens is shown below:

The following sequence diagram shows how the revise feature works:

Sequence Diagram of Revise
Figure 43. Sequence diagram of revise

Sequence Diagram of Revise Get Chapter
Figure 44. Sequence diagram of get chapter for revision

Sequence Diagram of Revise Not Due
Figure 45. Sequence diagram of revise for chapter that is not due

Sequence Diagram of Revise Get Chapter
Figure 46. Sequence diagram of get cards for revision

4.4.2. Scheduling The Chapters Feature

Implementation

In KAJI, each Chapter stores a CardList of Cards, each with their own int attribute previousInterval. Each Chapter also has a LocalDate attribute named dueBy that determines when the Chapter is due for revision. At the end of a revision session, the Scheduler class implements Spaced Repetition by computing the deckInterval, the mean (rounded off to the nearest integer) of the previousIntervals of every Card within the Chapter, and updates the dueBy attribute of the Chapter to deckInterval days after the day of revision.

To support this feature, Scheduler implements the following operations:

Scheduler#computeEasyInterval(), Scheduler#computeMediumInterval() and Scheduler#computeHardInterval() are exposed in the ReviseCommand class as ReviseCommand#rateCard() while Scheduler#computeDeckDeadline() is exposed as ReviseCommand#execute().

Back to Top ^

4.5. Viewing and Customising the Schedule Feature

KAJI schedules the user’s database automatically for them based on their revision sessions, chapter by chapter, using Spaced Repetition. Users should be able to view their schedule for the current day to know which tasks they need to complete on the day itself and to view their schedule for the upcoming week so that they can plan ahead. However, to effectively use the scheduling feature, users should also be able to customise their scheduling system to include or exclude chapters from their schedule with ease.

To utilise this feature, the following commands and their corresponding features are introduced:

4.5.1. View Due Chapters Feature

Implementation

Each Chapter has a deadline assigned to it from the point of creation, which forms the core of the Scheduling process. The View Due Chapters Feature builds on that by allowing users to view every chapter in the database that is due on the current day with a single command.

To support this feature, the following command was added to KAJI:

This feature takes the Exclusions of the database into account and will not display Chapters from the Exclusion List when the user calls them even if their deadlines are due.

As this Feature can be activated at any point, the following class is created to identify Chapters easily.

To support the View Due feature, ListDueCommand implements the following operations:

On top of that, Storage implements the following operations:

Class Diagram of ListDue
Figure 47. Class diagram of ListDue

Example

For instance, the user wants to check what Chapters are due at the moment. A detailed description of what happens is shown below:

Step 1: The user enters due.

Step 2: The user input is parsed by Parser, and Parser creates a ListDueCommand object.

Step 3: ListDueCommand is executed and calls the method ListDueCommand#loadAllDueChapters(), which will call Storage#loadAllDueChapters(), which will then call StorageLoad#loadAllChaptersAsDueChapters(). The name of every Chapter, their deadlines, and the name of the Module that they belong to, will be stored as a DueChapter and be returned to ListDueCommand.

Step 4: ListDueCommand will then call ListDueCommand#setDueDueChapters() to parse each DueChapter for those that are already due by the current date, and add them to its dueDueChapters attribute.

Step 5: ListDueCommand will then call Ui#printDueByTodayMessage() to print the prompt, and then call Ui#printDueChapters(), to print out the contents of dueDueChapters

The following sequence Diagrams illustrates how the View Due Chapters Process is executed:

Sequence Diagram of the View Due Feature
Figure 48. Sequence Diagram of the view due Feature

4.5.2. Preview Upcoming Dues Feature

Implementation

Similar to the View Due Chapters Feature, the Preview Upcoming Dues Feature builds on the Scheduling process by allowing users to view every chapter in the database that is due in the upcoming week with a single command.

To support this feature, the following command was added to KAJI:

This feature also takes the Exclusions of the database into account and will not display Chapters from the Exclusion List when the user calls them even if they are due in the upcoming week.

As this Feature can be activated at any point, the following class is also (similar to View Due Chapters) used to identify Chapters easily.

To support the Preview Upcoming Dues feature, PreviewCommand implements the following operations:

On top of that, the following operations from Storage are used:

Class Diagram of Preview
Figure 49. Class diagram of preview

Example

For instance, the user wants to check what Chapters are due on in the upcoming week. A detailed description of what happens is shown below:

Step 1: The user enters preview.

Step 2: The user input is parsed by Parser, and Parser creates a PreviewCommand object.

Step 3: PreviewCommand is executed and calls the method PreviewCommand#loadAllDueChapters(), which will call Storage#loadAllDueChapters(), which will then call StorageLoad#loadAllChaptersAsDueChapters(). The name of every Chapter, their deadlines, and the name of the Module that they belong to, will be stored as a DueChapter and be returned back to PreviewCommand.

Step 4: To check for each day in the upcoming week, PreviewCommand runs a for loop with to carry out the following steps for increment of value from 0 to 6

Step 5: PreviewCommand will then call PreviewCommand#setDueDueChapters() to parse each DueChapter for those that are already due on the current date + increment days, and add them to its dueDueChapters attribute.

Step 5: PreviewCommand will then call Ui#printDueByTodayMessage() to print the prompt if the value of increment is 0, and Ui#printDueByIncrementMessage() to print the prompt if the value of increment is from 1 to 6.

Step 6: PreviewCommand will then finally call Ui#printDueChapters(), to print out the contents of dueDueChapters for the current iteration.

Step 7: Increment the value of increment by 1, and go back to Step 4 if the value of increment is smaller than 7.

The following sequence Diagrams illustrates how the Preview Upcoming Dues Process is executed:

Sequence Diagram of the Preview Upcoming Dues Feature
Figure 50. Sequence diagram of the preview upcoming dues feature

4.5.3. Exclusion Feature

Implementation

KAJI allows users to customise which Chapters are to be excluded from their scheduling by maintaining an Exclusion List: a list of Chapters that KAJI will ignore as it parses for Chapters that are due in the due and preview commands.

This is to allow users to exclude and include Chapters from and to their schedules without having to remove and add the Chapters from their database, which can be tedious.

To support this feature, the following commands were added to KAJI:

To load and store the Exclusion List, a Exclusion File is created and maintained using these two methods from the Storage Class:

4.5.3.1 Excluding Chapters from the Schedule Feature

The exclude command can be called with either exclude chapter or exclude module, which adds a Chapter or every Chapter from a Module to the Exclusion List respectively.

To determine if a single chapter or an entire module is to be added to the Exclusion List, excludecommand implements the operation excludecommand#attemptToExclude().

Items are added into the ArrayList<String> Exclusion List using two pairs of commands in both ExcludeCommand and Storage:

Class Diagram of Exclude
Figure 51. Class diagram of exclude

Example

For instance, the user wants to exclude the Module CS2113T from his schedule. A detailed description of what happens is shown below:

Step 1: The user enters exclude module

Step 2: The user input is parsed by Parser, and Parser creates a ExcludeCommand object.

Step 3: ExcludeCommand is executed and calls the method ExcludeCommand#attemptToExclude().

Step 4: ExcludeCommand#attemptToExclude() checks the command argument, module for the exclude command and calls ExcludeCommand#addModuleToExclusion()

Step 5: ExcludeCommand calls Ui#getExcludedModuleName() to obtain the name of the module that is to be excluded from the scheduling process, so the user will enter CS2113T here

Step 6: ExcludeCommand will then call Storage#appendModuleToExclusionFile(), which will in turn call StorageWrite#appendModuleToExclusionFile() to begin the process of Updating the Exclusion File.

Step 7: StorageWrite will load the contents of the Exclusion File into excludedChapters using StorageLoad#loadExclusionFile() and load the Chapters of the CS2113T by calling StorageLoad#loadChaptersFromSpecifiedModule().

Step 8: StorageWrite will then check through the contents of the Exclusion file for each of the Chapters in CS2113T, and add them into excludedChapters if it is not already in it.

Step 9: After the inclusion of every Chapter in the CS2113T into excludedChapters, the contents of it are written back by StorageWrite into the Exclusion File by calling StorageWrite#updateExclusionFile().

The following sequence Diagrams illustrates how the “exclude” command is executed:

Sequence Diagram of the exclude command
Figure 52. Sequence diagram using the exclusion feature to exclude content from the schedule


4.5.3.2 Including Chapters back into the Schedule Feature

On the other hand, the include command can be called with include chapter or include module which removes a Chapter or every Chapter from a Module from the Exclusion List.

Similarly, to determine if a single chapter or an entire module is to be removed from the Exclusion List, includecommand implements the operation includecommand#attemptToInclude().

Items are removed from the ArrayList<String> Exclusion List using two pairs of commands in both IncludeCommand and Storage:

Class Diagram of Include
Figure 53. Class diagram of include

Example

For instance, the user wants to include the Module CS2113T back into his schedule. A detailed description of what happens is shown below:

Step 1: The user enters include module

Step 2: The user input is parsed by Parser, and Parser creates a IncludeCommand object.

Step 3: IncludeCommand is executed and calls the method IncludeCommand#attemptToInclude().

Step 4: IncludeCommand#attemptToInclude() checks the command argument, module for the include command and calls IncludeCommand#removeModuleFromExclusion()

Step 5: IncludeCommand calls Ui#getIncludedModuleName() to obtain the name of the module that is to be included back into the scheduling process, so the user will enter CS2113T here

Step 6: IncludeCommand will then call Storage#removeModuleFromExclusionFile(), which will in turn call StorageWrite#removeModuleFromExclusionFile() to begin the process of Updating the Exclusion File.

Step 7: StorageWrite will load the contents of the Exclusion File into excludedChapters using StorageLoad#loadExclusionFile() and load the Chapters of the CS2113T by calling StorageLoad#loadChaptersFromSpecifiedModule().

Step 8: StorageWrite will then check through the contents of the Exclusion file for each of the Chapters in CS2113T, and remove them from excludedChapters if found.

Step 9: After the removal of every Chapter in the CS2113T from excludedChapters, the contents of it are written back by StorageWrite into the Exclusion File by calling StorageWrite#updateExclusionFile().

The following sequence Diagrams illustrates how the “include” command is executed:

Sequence Diagram of the include command
Figure 54. Sequence diagram using the exclusion feature to include content into the schedule


4.5.4. Reschedule Chapter Feature

Implementation

The reschedule chapter feature allows the user to reschedule the due date of any existing chapter.

The user can reschedule the due date of an existing chapter with the reschedule command, which follows the following format: reschedule CHAPTER_INDEX DATE(yyyy-MM-dd).

The reschedule chapter feature is facilitated by ChapterList and Chapter. The list of user’s chapters are stored internally as ChapterList. In addition, it implements the following operations:

The following diagram shows the class diagram of the reschedule chapter feature:

Reschedule Chapter Class Diagram
Figure 55. Class diagram of reschedule chapter feature

For instance, the user wants to reschedule the due date 2020-12-12 of the chapter Chapter 1 from the module CS2113T, a detailed description of what happens is shown below:

The following sequence diagram shows how the reschedule chapter feature works:

Reschedule Chapter Sequence Diagram
Figure 56. Sequence diagram of reschedule chapter feature

:information_source: Note: The lifeline for Module should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

4.5.5. View Revision History Feature

Implementation

The view revision history feature allows the user to list the revision completed in the session/in a day. In case the user enters history follow by a date(example: 2020-10-10), Kaji will list the revision completed in October 10, 2020. Otherwise, Kaji will list the revision completed in the day the user uses HelpCommand. This feature can be accessed at any level.

The history mechanism is facilitated by HistoryCommand. It extends from the abstract class Command.

In addition, it implements the following operations:

The following diagram shows the class diagram of the list revision history feature:

List Revision History Class Diagram
Figure 57. Class diagram of list revision history feature

Given below is an example usage scenario and how the history mechanism behaves at each step:

Step 1: The user launches the application and is currently in the admin level.

Step 2: The user executes history command to load and list the revision completed in current day.

Step 3: The user can also execute history 2020-11-09 command to load and list the revision completed in 2020-11-09.

The following sequence diagram shows how the list revision history feature works:

Sequence Diagram of List Revision History
Figure 58. Sequence Diagram of List Revision History

Back to Top ^

5. Appendices

5.1. Appendix A: Product Scope

5.1.1 Target User Profile

5.1.2. Value Proposition

The application aims to provide students with an effective studying technique. In order to make studying easier for students, the application implements a technique known as spaced repetition, which help with memory retention. Content are scheduled automatically, and information is organised in the form of flashcards which makes it convenient to revise.

Back to Top ^

5.2. Appendix B: User Stories

Version As a … I want to … So that I can …
v1.0 student add modules study based on modules
v1.0 student add chapters for each module study based on chapters for a certain module
v1.0 student add flashcards inside each chapter for the content of each chapter study the content of each chapter
v1.0 student list my modules have an overview of what modules I have
v1.0 student list my chapters in each module have an overview of what chapters I have for a module
v1.0 student list my flashcards in each chapter have an overview of the content I have for a chapter
v1.0 student modify the module name correct the module name if it is incorrect
v1.0 student modify the chapter name correct the chapter name if it is incorrect
v1.0 student modify the content of the flashcards correct the content if it is incorrect
v1.0 student remove modules/chapters/flashcard remove modules/chapters/flashcards that I no longer need
v1.0 student access my module revise based on module
v1.0 student access my chapters for a module revise based on chapter for a certain module
v1.0 student revise the flashcards by chapter do my revision
v1.0 student set a rating for a newly created chapter rate a chapter without going through a revision session
v1.0 student state whether a flashcard is easy, medium or hard revise the flashcards based of the difficulty of it
v1.0 student check the scheduled tasks daily plan my schedule accordingly
v1.0 student rely entirely on the application to implement spaced repetition for me enjoy the benefits of spaced repetition without having to implement it myself
v1.0 student have a help command have an overview of how the application works
v1.0 student terminate the program exit the application when I am done using it
v2.0 student see a forecast of the my revision schedule plan ahead and make time to accommodate the revision of the corresponding number of chapters
v2.0 student reschedule a chapter change the schedule according to my situation
v2.0 student view the module and chapters I have completed in a session/in a day track my progress
v2.0 student get a sense of how well I have mastered each chapter have an idea of how well I am doing for a module
v2.0 student include or exclude certain modules/chapters from the scheduler revise only the modules/chapters that I need to
Back to Top ^

5.3. Appendix C: Use Cases

This section will describe the use cases of KAJI.

(For all use cases below, the System is the KAJI application and the Actor is the user, unless specified otherwise.)

Use Case: add a new module

MSS

  1. User requests to add a new module.

  2. KAJI creates and saves the new module with the module name specified by the user.

    Use case ends.

Use Case: list all current modules

MSS

  1. User requests to list all current modules.

  2. KAJI shows a list of modules available.

    Use case ends.

Use Case: edit a module

MSS

  1. User requests to edit a module.

  2. KAJI makes the changes and saves the module with the new module name specified by the user.

    Use case ends.

Use Case: remove a module from the current list of modules

MSS

  1. User requests to remove an existing module.

  2. KAJI deletes the module from the list of modules.

    Use case ends.

Use Case: access a module level

MSS

  1. User requests to access a module level.

  2. KAJI changes the current admin level of the user to the module level specified by the user.

    Use case ends.

Use Case: revise a chapter from the current list of chapters in a particular module

MSS

  1. User requests to revise a chapter from the current list of chapters in a particular module.

  2. KAJI starts a revision session for the user.

    Use case ends.

Extensions

User will be prompted to acknowledge that he wants to start a revision session for a chapter that is not due.
There will be no revision for an empty chapter.

Use Case: view a list of chapters which are due

MSS

  1. User requests to view a list of chapters which are due.

  2. KAJI shows a list of chapters that are due to the user.

    Use case ends.

Use Case: preview a list of chapters that are due in the week

MSS

  1. User requests to preview a list of chapters that are due in the week.

  2. KAJI shows a list of chapters that are due in the week to the user.

    Use case ends.

Use Case: exclude an existing module or chapter

MSS

  1. User requests to exclude a module or chapter.

  2. KAJI excludes the module or chapter specified by the user so that it will no longer be scheduled for revision.

    Use case ends.

Use Case: include an existing module or chapter

MSS

  1. User requests to include a module or chapter.

  2. KAJI includes the module or chapter specified by the user so that it will be scheduled for revision once again.

    Use case ends.

Use Case: reschedule the due date of an existing chapter

MSS

  1. User requests to reschedule the due date of an existing chapter.

  2. KAJI reschedules the due date of the chapter specified by the user.

    Use case ends.

Use Case: view the history of revision completed in a day

MSS

  1. User requests to view the history of revision completed in a day.

  2. KAJI shows the history of revision completed by the user in a day.

    Use case ends.

Use Case: check overall performance for an existing chapter using showrate

MSS

  1. User requests to check overall performance for an existing chapter using showrate.

  2. KAJI shows the list of number of cards that were rated easy/medium/hard in the chapter to the user.

    Use case ends.

Extensions

There will only be changes to the rating after a revision session.

Use Case: view the list of commands available using help

MSS

  1. User requests to view the list of commands available using help.

  2. KAJI shows the list of commands available to the user.

    Use case ends.

Back to Top ^

5.4. Appendix D: Non-Functional Requirements

  1. Should work on any mainstream OS as long as it has Java 11 installed.
  2. Should be able to hold up to 1000 flashcards 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. Data saved in a session should be persistent and carry forward to the next session of use.
  5. The file containing the saved data should be portable so that the user can transfer to the other machine with any mainstream OS and continuing using the app without any additional configuration.
  6. Application should not crash, application should always recover from error gracefully with an error message.
  7. Should work mostly without the need for the Internet.
  8. Should be designed for a single user.
  9. Should work on both 32-bit and 64-bit environments.
Back to Top ^

5.5. Appendix E: Glossary

Back to Top ^

5.6. Appendix F: Instructions for Manual Testing

5.6.1. Launch and Shutdown

  1. Initial launch
    1. Download the jar file from the release page and copy into an empty folder.
    2. Launch a terminal and navigate to the folder containing the jar file.
    3. Run the jar file by entering command java -jar kaji.jar and press enter (replace kaji.jar by the actual file name you downloaded from the release page). Expected output: Welcome message of Kaji is displayed.
  2. Shutdown of application
    1. Test case: exit
      Expected output: KAJI program terminates.

5.6.2. Showing a list of commands

  1. Prerequisites: Launch KAJI successfully.
  2. Test case: help
    Expected output: A message listing how to use each command will be shown.
  3. Other incorrect commands to try: help abcd (where there are extra arguments)
    Expected output: An error message stating that there should not be any arguments will be shown.

5.6.3. Adding a module/chapter/flashcard

  1. Adding a module
    1. Prerequisites: Ensure that you are at the admin level.
    2. Test case: add CS2113T
      Expected output: A success message stating that there is a new module added will be shown.
    3. Test case: add cs2113t after running the add command as stated above
      Expected output: An error message stating that the module already exist will be shown.
    4. Other incorrect commands to try: add ../CS2113T (where non-alphanumeric characters are present)
      Expected output: An error message stating that only alphanumeric characters and spaces will be shown.
  2. Adding a chapter
    1. Prerequisites: At least one module in the module list. Ensure that you are at the module level.
    2. Test case: add Chapter 1
      Expected output: A success message stating that there is a new chapter added will be shown.
    3. Test case: add chapter 1 after running the add command as stated above
      Expected output: An error message stating that the chapter already exist will be shown.
    4. Other incorrect commands to try: add ../Chapter 1 (where non-alphanumeric characters are present)
      Expected output: An error message stating that only alphanumeric characters and spaces will be shown.
  3. Adding a flashcard
    1. Prerequisites: At least one module and chapter in the module and chapter list respectively. Ensure that you are at the chapter level.
    2. Test case: add q:1+1 | a:2
      Expected output: A success message stating that there is a new flashcard added will be shown.
    3. Test case: add q:1+1 | a:2 after running the add command as stated above
      Expected output: An error message stating that the flashcard already exist will be shown.
    4. Other incorrect commands to try: add q:1+1 | a: (where parameter is missing)
      Expected output: An error message stating that the question or answer is missing will be shown.

5.6.4. Listing modules/chapters/flashcards

  1. Listing all modules
    1. Prerequisites: At least one module in the list. No chapters in the module list. Ensure that you are at the module level.
    2. Test case: list
      Expected output: A message stating that there are no chapters will be shown.
    3. Prerequisites: At least one module in the list. Chapter list contains some chapters. Ensure that you are at the module level.
    4. Test case: list
      Expected output: A message listing all the chapters will be shown.
    5. Other incorrect commands to try: list abcd (where there are extra arguments)
      Expected output: An error message stating that there should not be any arguments will be shown.
  2. Listing all chapters
    1. Prerequisites: No modules in the module list. Ensure that you are at the admin level.
    2. Test case: list
      Expected output: A message stating that there are no modules will be shown.
    3. Prerequisites: Module list contains some modules. Ensure that you are at the admin level.
    4. Test case: list
      Expected output: A message listing all the modules will be shown.
    5. Other incorrect commands to try: list abcd (where there are extra arguments)
      Expected output: An error message stating that there should not be any arguments will be shown.
  3. Listing all flashcards
    1. Prerequisites: At least one module and chapter in the module and chapter list respectively. No flashcards in the flashcard list. Ensure that you are at the chapter level.
    2. Test case: list
      Expected output: A message stating that there are no flashcards will be shown.
    3. Prerequisites: At least one module and chapter in the module and chapter list respectively. Flashcard list contains some flashcards. Ensure that you are at the chapter level.
    4. Test case: list
      Expected output: A message listing all the flashcards will be shown.
    5. Other incorrect commands to try: list abcd (where there are extra arguments)
      Expected output: An error message stating that there should not be any arguments will be shown.

5.6.5. Editing a module/chapter/flashcard

  1. Editing a module
    1. Prerequisites: At least one module in the module list. Ensure that you are at the admin level.
    2. Test case: edit 1 CS2113
      Expected output: A message stating the module name before and after the edit will be shown.
    3. Test case: edit 0 CS2113
      Expected output: No module is edited. An error message will be shown.
    4. Other incorrect commands to try: edit, edit x CS2113 (where x is larger than the list size)
      Expected output: Similar to previous or a message stating how to use the command will be shown.
  2. Editing a chapter
    1. Prerequisites: At least one module and chapter in the module and chapter list respectively. Ensure that you are at the module level.
    2. Test case: edit 1 Chapter 2
      Expected output: A message stating the chapter name before and after the edit will be shown.
    3. Test case: edit 0 Chapter 2
      Expected output: No chapter is edited. An error message will be shown.
    4. Other incorrect commands to try: edit, edit x Chapter 2 (where x is larger than the list size)
      Expected output: Similar to previous or a message stating how to use the command will be shown.
  3. Editing a flashcard
    1. Prerequisites: At least one module, chapter and flashcard in the module, chapter and flashcard list respectively. Ensure that you are at the chapter level.
    2. Test case: edit 1 q:1+1 | a:
      Expected output: A message stating the flashcard content before and after the edit will be shown.
    3. Test case: edit 0 q:1+1 | a:
      Expected output: No flashcard is edited. An error message will be shown.
    4. Other incorrect commands to try: edit, edit x q:1+1 | a: (where x is larger than the list size)
      Expected output: Similar to previous or a message stating how to use the command will be shown.

5.6.6. Removing a module/chapter/flashcard

  1. Removing a module
    1. Prerequisites: At least one module in the module list. Ensure that you are at the admin level. List all modules using the list command.
    2. Test case: remove 1
      Expected output: First module is removed from the module list. A message stating the details of the removed module will be shown.
    3. Test case: remove 0
      Expected output: No module is removed. An error message will be shown.
    4. Other incorrect commands to try: remove, remove x (where x is larger than the list size)
      Expected output: Similar to previous or a message stating how to use the command will be shown.
  2. Removing a chapter
    1. Prerequisites: At least one module and chapter in the module and chapter list respectively. Ensure that you are at the module level. List all modules using the list command.
    2. Test case: remove 1
      Expected output: First chapter is removed from the chapter list. A message stating the details of the removed chapter will be shown.
    3. Test case: remove 0
      Expected output: No chapter is removed. An error message will be shown.
    4. Other incorrect commands to try: remove, remove x (where x is larger than the list size)
      Expected output: Similar to previous or a message stating how to use the command will be shown.
  3. Removing a flashcard
    1. Prerequisites: At least one module, chapter and flashcard in the module, chapter and flashcard list respectively. Ensure that you are at the chapter level. List all flashcards using the list command.
    2. Test case: remove 1
      Expected output: First flashcard is removed from the chapter list. A message stating the details of the removed flashcard will be shown.
    3. Test case: remove 0
      Expected output: No flashcard is removed. An error message will be shown.
    4. Other incorrect commands to try: remove, remove x (where x is larger than the list size)
      Expected output: Similar to previous or a message stating how to use the command will be shown.

5.6.7. Accessing the next level

  1. Accessing module level
    1. Prerequisites: At least one module in the module list. Ensure that you are at the admin level.
    2. Test case: go 1
      Expected output: Accessed the first module in the module list. Access level message will be changed.
    3. Test case: go 0
      Expected output: Still at admin level. An error message will be shown.
    4. Other incorrect commands to try: go, go x (where x is larger than the list size)
      Expected output: Similar to previous or a message stating how to use the command will be shown.
  2. Accessing chapter level
    1. Prerequisites: At least one module and chapter in the module and chapter list respectively. Ensure that you are at the module level.
    2. Test case: go 1
      Expected output: Accessed the first chapter in the chapter list. Access level message will be changed.
    3. Test case: go 0
      Expected output: Still at module level. An error message will be shown.
    4. Other incorrect commands to try: go, go x (where x is larger than the list size)
      Expected output: Similar to previous or a message stating how to use the command will be shown.

5.6.8. Going back to the previous level

  1. Going back to admin level
    1. Prerequisites: Ensure that you are at module level.
    2. Test case: back
      Expected output: Back to admin level. Access level message will be changed.
    3. Other incorrect commands to try: back abcd (where there are extra arguments)
      Expected output: An error message stating that there should not be any arguments will be shown.
  2. Going back to module level
    1. Prerequisites: Ensure that you are at chapter level.
    2. Test case: back
      Expected output: Back to module level. Access level message will be changed.
    3. Other incorrect commands to try: back abcd (where there are extra arguments)
      Expected output: An error message stating that there should not be any arguments will be shown.

5.6.9. Rescheduling a chapter

  1. Prerequisites: At least one module and chapter in the module and chapter list respectively. Ensure that you are at the module level.
  2. Test case: Substitute DATE with the current date
    reschedule 1 DATE
    Expected output: A message stating the due date of the chapter before and after the rescheduling will be shown.
  3. Test case: Substitute DATE with the date before the current date
    reschedule 1 DATE
    Expected output: Chapter will not be rescheduled. A message stating that the due date cannot be before the current date will be shown.
  4. Test case: Substitute DATE with the current date
    reschedule 0 DATE
    Expected output: No chapter will be rescheduled. An error message will be shown.
  5. Other incorrect commands to try: reschedule, reschedule x DATE (where x is larger than the list size)
    Expected output: Similar to previous or a message stating how to use the command will be shown.

5.6.10. Starting a revision session

  1. Prerequisites: At least one flashcard is in the chapter to be revised. Ensure that you are at the module level.
  2. Test case: revise 1
    Expected output: A revision session will start on the first chapter in the module.
  3. Other incorrect commands to try: revise Chapter 1 (where chapter name instead of its index integer is provided)
    Expected output: An error message stating to specify chapter index in integer will be shown.

5.6.11. Checking percentage of rating for the cards in a chapter

  1. Prerequisites: At least one flashcard is in the chapter. Ensure that you are at the chapter level.
  2. Test case: showrate
    Expected output: A list of the percentage for easy/medium/hard based on the number of cards will be shown.
  3. Other incorrect commands to try: showrate blah (where extra arguments are added)
    Expected output: An error message stating that there should be no extra arguments will be shown.

5.6.12. Listing all chapters that are due on current date

  1. Prerequisites: Launch KAJI successfully.
  2. Test case: due
    Expected output: A list of chapters that are due on the current date will be shown. If no chapters are due, a message stating that no chapters are due for the day will be shown.
  3. Other incorrect commands to try: due blah (where extra arguments are added)
    Expected output: An error message stating that there should be no extra arguments will be shown.

5.6.13. Previewing list of chapters due in a week

  1. Prerequisites: Launch KAJI successfully.
  2. Test case: preview
    Expected output: A list of chapters that are due in a week will be shown. If no chapters are due, every date will be accompanied by a message that no chapters are due.
  3. Other incorrect commands to try: preview blah (where extra arguments are added)
    Expected output: An error message stating that there should be no extra arguments will be shown.

5.6.14. Viewing history of revision completed in a day

  1. Prerequisites: Launch KAJI successfully.
  2. Test case: history
    Expected output: Lists the module and chapter which you have completed revision for. If no revision was done on the day, a message stating that no revision for that session will be shown.
  3. Test case: history 2020-11-09 Expected output: List the module and chapter which you have completed revision for on 2020-11-09. If no revision was done on the day, a message stating that no revision for that session will be shown.
  4. Other incorrect commands to try: history blah (where the argument is not in the correct date format)
    Expected output: An error message stating that the date should be in yyyy-MM-dd format will be shown.

5.6.15. Excluding a module/chapter

  1. Excluding a module
    1. Prerequisites: Launch KAJI successfully. The module you want to exclude should exist.
    2. Test case: exclude module
      Expected output: A prompt for which module to be excluded will be shown and you can enter an existing module which you want to exclude.
    3. Other incorrect commands to try: exclude blah (where the argument is not module/chapter) Expected output: An error message stating that only module/chapter should be specified will be shown.
  2. Excluding a chapter
    1. Prerequisites: Launch KAJI successfully. The chapter you want to exclude should exist.
    2. Test case: exclude chapter
      Expected output: A prompt for which chapter to be excluded will be shown and you can enter an existing chapter which you want to exclude.
    3. Other incorrect commands to try: exclude blah (where the argument is not module/chapter) Expected output: An error message stating that only module/chapter should be specified will be shown.

5.6.16. Including a module/chapter

  1. Including a module
    1. Prerequisites: Launch KAJI successfully. The module you want to include should exist.
    2. Test case: include module
      Expected output: A prompt for which module to be included will be shown and you can enter an existing module which you want to include.
    3. Other incorrect commands to try: include blah (where the argument is not module/chapter) Expected output: An error message stating that only module/chapter should be specified will be shown.
  2. Including a chapter
    1. Prerequisites: Launch KAJI successfully. The chapter you want to include should exist.
    2. Test case: include chapter
      Expected output: A prompt for which chapter to be included will be shown and you can enter an existing chapter which you want to include.
    3. Other incorrect commands to try: include blah (where the argument is not module/chapter) Expected output: An error message stating that only module/chapter should be specified will be shown.
Back to Top ^