Nuke Developer Guide v2.1

By: CS2113T-T13-2 Since: Feb 2020
Go to Webpage

Table of Contents

Introduction ➥
        • Purpose ➥
        • Scope ➥
        • Design Goals ➥


Setting Up ➥
        1. Architecture ➥
        2. UI Component ➥
        3. Logic Component ➥
        4. Model Component ➥
        5. Storage Component ➥


Design ➥


Structure Implementation ➥
        1. Directory ➥
        2. Directory Manager ➥
        3. Directory Traverser ➥


Command Implementation ➥
        1. Add Command ➥
        2. List Command ➥
        3. Delete Command ➥
        4. Edit Command ➥
        5. Change Directory Command ➥
        6. Open File Command ➥
        7. Info Command ➥
        8. Undo and Redo Commands ➥


Storage Implementation ➥


Appendix ➥
        • Product Scope ➥
        • User Stories ➥
        • Non-Functional Requirements ➥
        • Glossary ➥
        • Manual Testing ➥

Contact Us ➥

Introduction

Purpose

This document describes the structure and software design decisions for the Nuke application. The Nuke application is a simple yet powerful task management application that is dedicated to providing NUS students a more efficient way to organise their modules and tasks.

Scope

This document will cover the structure and software design decisions for the implementation of Nuke. The intended audience for this document are developers, designers and software testers of Nuke or other similar task management application.

Design Goals

Develop a structure that facilitates a more efficient organisation of the user’s tasks

Enhance speed to perform operations

Back To Top

Setting Up

1.1. Prerequisites

1. JDK 11
2. IntelliJ IDE

1.2. Setting up the project

1. Fork this repository, and clone the fork to your computer

2. Open the IntelliJ IDE. If you are not in the welcome screen, click File > Close Project to close the existing project.

3. Set up the correct JDK version for Gradle

   1. Click Configure > Project Defaults > Project Structure

   2. Click New... and find the directory of the JDK

4. Click on Import Project

5. Locate and select the build.gradle file, then click OK

6. Click Open as Project

7. Click OK to use the default settings provided

1.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 nuke-2.0.jar

   1. To use Nuke, 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 available commands and their respective command usage help messages.

   2. Some example commands you can try to get familiar with Nuke:

      • help: Lists the commands that Nuke supports.
        • addm cs2113t: Adds a module with module code cs2113t, Nuke will recognize it as the module Software Engineering & Object-Oriented Programming and add it to your Module List.
      • addt assignment2 -m cs2113t -c Assignment -d tmr 23:59 -p 20 : Adds a task named assignment2 which belongs to module cs2113t and category Assignment with a deadline tomorrow 23:59 and priority of 20
        • bye: Exits Nuke.

Back To Top

Design

1. Architecture

Figure Nuke Architecture

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

Main has only one class called Nuke. It is responsible for,

• At launch: Initialises the components in the correct sequences, and connects them up with each other.

• At running: Invoke UI to Show welcome messages, continuously invokes UI, Logic component to execute commands entered by user. Also invokes storage component to save data after execution of user’s commands

• At shut down: Invokes UI component to show exit message.

There are four other components in the Nuke application.

• UI: The UI of the application which complete interactions between User and Nuke.

• Logic: The command executor.

• Model: Holds different data types in the application.

• Storage: Loads data from, and writes data to, a file in the user’s hard disk.

Each of the four components

• defines its API in several classes

• exposes its functionalitiy by invoking different methods in these classes.

For example, the Storage component defines it’s API in several classes including Encoder and Decoder, and exposes its functionality by invoking different method in these classes by StorageManager class.

How the architecture components interact with each other The Sequence Diagram below shows how the components interact with each other for the scenario where the user issues the command addm CS2113T. (As the Storage component will only be used when launching and exiting the applicatio, here the storage component is omitted.)

Figure Components interactions

Back To Top

2. UI Component

Classes used by UI component are in the seedu.nuke.ui package.

3. Logic Component

Classes used by Logic component are in the seedu.nuke.data package, seedu.nuke.parser package, DirectoryTraverse.java in seedu.nuke.directory package and Executor.java in seedu.nuke package.

The diagram below shows the Logic Component of the Nuke application in our current implementation:

Figure Logic Component

4. Model Component

More information about the Model Component can be found here.

5. Storage Component

More information about the Storage Component can be found here.

Back To Top

Structure Implementation

1. Directory

Overview

Implementation

Figure Directory Class Diagram (Basic)

Figure Directory Class Diagram

Root

Module

Category

Task

File

Back To Top

2. Directory Manager

Overview

Implementation

Back To Top

Design Considerations

Structure Decision

• Alternative 1: No Directory Tree structure; have one Task List</b> which stores all the user’s tasks
  • Pros: Implementation-wise will be trivial. Any operations relating to the task can be done directly from the Task List
  • Cons: The Task List can become too large overtime. It can become messy and unorganised since categorisation of tasks is not explicitly implemented. Also, it will prevent having duplicated common names. For example, many tasks may have the same task description Tutorial 3.
• Alternative 2: Have a Directory Tree structure (current implementation)
  • Pros: The structure is more layered and well-organised. A folder and sub-folder structure is intuitive to the user since it tends to follow how he would normally store and organise their tasks. Duplicated Directory names are also supported 😊 provided they come from different parent Directories.
  • Cons: Can be challenging to implement 😩. There are many other structures and methods that we need to implement to facilitate the Tree structure. For example, methods to traverse the Tree, and how Directories have knowledge of their parent Directory. For the users, this would mean more commands and features for them to know.
    
    

Directory Operations

• Alternative 1: Merge Directory classes with Directory Manager classes
  • Pros: We will be able to implement one less class for each Directory. Also it may be intuitive at first to combine them since they perform “similar” functions. For example Module and ModuleManager classes both have operations that largely involve Module objects.
  • Cons: The operations of Directory classes with Directory Manager classes are not exactly similar. Directory classes form the basic structure of the Directories, while the Directory Manager classes manage storing and operating Directories. Merging the two will thus violate Single Responsibility Principle and Separation of Concerns as the merged class will have two different roles.
• Alternative 2: Have separated Directory classes and Directory Manager classes (current implementation)
  • Pros: The classes are more specialised and perform more distinct roles, which is an ideal coding practice.
  • Cons: A separate class needs to be implemented for each of the Directories. Both Directory classes and Directory Manager classes also tend to be very closely associated to each other and increases coupling.

Back To Top

3. Directory Traverser

Overview

Implementation

Figure Directory Traverser Class Diagram

Figure Directory Traverser Traverse Down

Figure Directory Traverser Traverse Up

Back To Top

Design Considerations

Attributes Matching

• Alternative 1: Do not have any attribute matching, i.e. missing path attributes are not allowed
  • Pros: Simple to implement. We only need to check if every path attribute is provided by the user, and that the Directory from the given path exists.
  • Cons: The user needs to consistently enter the full path to the Directory he is targeting. This can become rather time-consuming and very inconvenient to the user.

• Alternative 2: Have attribute matching (current implementation)
  • Pros: User can omit certain path attributes, or the entire path altogether if he is at the correct Directory. Commands would be shorter and can be entered faster, which meets the expectation stated in the user stories.
  • Cons: A lot harder to implement 😧. There are many considerations to be made for the correct implementation of this feature such as how missing attributes can be derived and the correct matching of attributes.

Back To Top

Command Implementation

This section will describe the significant details of how the commands in Nuke are being implemented.


Below is a diagram which summarises the commands in the current Nuke application.


Figure Nuke Commands

1. Add Command

Overview

The add feature adds modules, categories, tasks and tags into the Module, Category and Task List respectively.

Figure Add Command Classes Diagram

1.1. Add Module Command

The add module feature enable the user to add modules into the Module List.

When the user first requests to execute the addm command(assuming the command format given is valid) to add a module by providing its name, the application will parse the input after addm command word as the module code. From here, there are three possible outcomes:

1. The module specified by the user is not provided by NUS – No module will added.
2. The module specified by the user is already added – No module will be added.
3. The module specified by the user is provided by NUS and have not been added – Module will be added.

Implementation

This feature is facilitated by the AddModuleCommand class which add the modules specified by the user. It overrides the execute() method which extends from the abstract AddCommand class which extends from the abstract Command class. The execute() method’s role is to execute the adding module operation and do necessary checks .

The AddCommand will first try to call the static method add in ModuleManager class, which will try to add the module specified by the user, exception will thrown according the following rules:

1. DuplicateModuleException will be thrown if the module specified by the user is contained in the ArrayList named moduleList in ModuleManager class.
2. ModuleNotProvidedException will be thrown if the module code specified by the user is not contained in the HashMap named modulesMap in ModuleManager class.

Back To Top

Example Usage

The addition of modules will be illustrated as follows.

James is a user and wants to add the module with the module code of “CS3235”. Assume that he has the current modules:

+--------------------------------------------------------------------------------------------------+
 NO |  MODULE CODE   |                                 MODULE TITLE
+--------------------------------------------------------------------------------------------------+
 1  |     CS1231     |                             Discrete Structures
 2  |     CS2100     |                            Computer Organisation
 3  |     CS2113     |              Software Engineering & Object-Oriented Programming
+--------------------------------------------------------------------------------------------------+
Total modules: 3
+--------------------------------------------------------------------------------------------------+

❶ James will simply enter the command addm cs3235

After the input is parsed as an add module task and executed, the AddModuleCommand#execute() will call ModuleManager#add() to add the module cs3235. In the ModuleManager#add() method, it will call ModuleManager#contains() to check if the module cs3235 exists in the ArrayList named moduleList , then it will check if the module code “cs3235” is a key in the HashMap named modulesMap, after all, it will instantiate an Module object with the module code “CS3235” and respective title “Computer Security”, then add the object into the moduleList.

❷ James receive the following feedback:

 root :
 addm cs3235
 SUCCESS!! Module CS3235 Computer Security has been added.
   
 root :
 lsm
 Here are what you are looking for...
   
 +--------------------------------------------------------------------------------------------------+
  NO |  MODULE CODE   |                                 MODULE TITLE
 +--------------------------------------------------------------------------------------------------+
  1  |     CS1231     |                             Discrete Structures
  2  |     CS2100     |                            Computer Organisation
  3  |     CS2113     |              Software Engineering & Object-Oriented Programming
  4  |     CS3235     |                              Computer Security
 +--------------------------------------------------------------------------------------------------+
 Total modules: 4
 +--------------------------------------------------------------------------------------------------+

Below is a sequence diagram to illustrate the above example scenario.

Figure Add Module Command Class Diagram

Back To Top

1.2. Add Category and Task Commands

Since add category and add task feature are implemented in a similar pattern, they can be explained together.

The add category/task enable the user to add category/task/tag into Category/Task/Tag List.(One to one correspondence, which means the user can only add category to Category List, task to Task List).

When the user first request to execute the add command(assuming the command format given is valid) to add a category/task by providing its name, the application will parse the input after addm /addc command word as the name for category/task. From here, there are three possible outcomes:

1. The specified upper parent directory does not exist. – No category/task will be added.
2. The name of the specified category/task already exist. – No category/task will be added.
3. The specified upper parent directory exist and the name of the specified category/task does not exist. – The specified category/task will be added.

Implementation

This feature is facilitated by the AddCategoryCommand and AddTaskCommand class which add the corresponding category or task respectively.

The above-stated two classes overrides the execute() method which extends from the abstract AddCommand class which extends from the abstract Command class. The execute() method’s role is to execute the adding category/task operation and do necessary checks.

The AddCategoryCommand and AddTaskCommand will first call the getParentDirectory() method to get the parent directory, then it will instantiate a Category/Task object and try to call add method in their respective parent directory class to add the new object, exception will be thrown according to the following rules:

1. ModuleNotFoundException will be thrown if the specified module code does not exists in the ArrayList of Module when adding a new category or task.
2. CategoryNotFoundException will be thrown if the specified category name does not exists in the ArrayList of Category in CategoryManager in Module when adding a new task.
3. IncorrectDirectoryLevelException will be thrown if the user is performing theaddc/addt command in the wrong directory without specifying their full parent directories.(For example, when user trying to execute addc in a Root/Task directory, or trying to execute addt in a Root/Module directory)
4. DuplicateTaskException/DuplicateCategoryException will be thrown if the name of the category/task already exist in the current directory.

Below are the class-diagram for the involved classes:

to-do: add the class-diagram

Example Usage

The addition process for category and task are similar. In this example, the addition process for category will be illustrated as a series of steps.

James is a user and wants to add a category named “misc” under the module cs3235. Assume that he has the current Module List and current Category List in the module cs3235:

+--------------------------------------------------------------------------------------------------+
 NO |  MODULE CODE   |                                 MODULE TITLE                       
+--------------------------------------------------------------------------------------------------+
 1  |     CS1231     |                             Discrete Structures                    
 2  |     CS2100     |                            Computer Organisation                   
 3  |     CS2113     |              Software Engineering & Object-Oriented Programming    
 4  |     CS3235     |                              Computer Security                     
+--------------------------------------------------------------------------------------------------+
Total modules: 4
+--------------------------------------------------------------------------------------------------+

+--------------------------------------------------------------------------------------------------+
 NO |     MODULE     |                                CATEGORY                                | PTY
+--------------------------------------------------------------------------------------------------+
 1  |     CS3235     |                               Assignment                               |  4
 2  |     CS3235     |                                  Lab                                   |  3
 3  |     CS3235     |                                Lecture                                 |  1
 4  |     CS3235     |                                Tutorial                                |  2
+--------------------------------------------------------------------------------------------------+
Total categories: 5
+--------------------------------------------------------------------------------------------------+

1. James has two choices:

   1. enter cd cs3235 to enter the module directory then enter addc misc to add the category.
   2. enter addc misc -m cs3235 to add the category at the root directory.

   Suppose James use the first method, after the second input, the input is parsed as an add task command and executed, the AddCategoryCommand#execute() will call AddCategoryCommand#getParentDirectory() to get the current parent directory, then it will instantiate an Category object with the name “misc”. After which CategoryManager#add() will be called to add the new object. In the CategoryManager#add() method, it will call CategoryManager#contains() method to check if the current parent directory contains the category with name “misc”, finally add the object into the ArrayList of categoryList.

2. James receive the following feedback:

   root :
   addc misc
   SUCCESS!! Category misc is created.
   

Below is a sequence diagram to illustrate the above example scenario.

Figure Add Module Command Sequence Diagram

Design Considerations

Character Limit

• Alternative 1: Have no character limit to the names of the Directory being added
  • Pros: Simple to implement. No need to do any checking and create error messages aside from duplicated names.
  • Cons: If the name is too long, it would affect the formatting of the list to be printed in the list command.
• Alternative 2: Have a character limit (current implementation)
  • Pros: The list to be shown to the user in the list command will not run into formatting issues.
  • Cons:At times, user may want to have a particularly long name for the Directory. However, they are unable to do so anymore if a word limit is imposed.

2. List Command

Overview

The List feature lists out modules, categories and tasks from the Module, Category and Task List respectively.
When the user first requests to execute the list command to list out directory by providing its name, the application will first filter for directories with matching names. From here, there are three possible outcomes:

1. There are no matches – Nothing is listed out.
2. There are matches – The list of matches will be shown to the user.

Implementation

Figure List Command Class Diagram

The ListModuleCommand, ListCategoryCommand, ListTaskCommand, ListFileCommand, DueCommand, ListModuleTaskCommand, ListTaskSortedCommand classes in the application facilitates this list feature. They are in charge of listing out modules, categories, tasks, files, all tasks at the specified time period, tasks of module in ascending order of deadline and all undone tasks sorted by deadline or priority respectively.

As shown in the figure above, those seven classes each extends from the abstract ListCommand class. They also override the ancestor Command class’s execute() method, which role is to list out desired entries to the user.

The ListCommand class in turn extends the FilterCommand abstract class. The FilterCommandClass contains the following vital methods for filtering:

• createFilteredModuleList() – Creates an ArrayList of the filtered modules.
• createFilteredCategoryist() – Creates an ArrayList of the filtered categories.
• createFilteredTaskList() – Creates an ArrayListof the filtered tasks.

Lastly, the FilterCommand class extends the abstract Command class that contains the execute() method to execute the actual list command.

Example Usage

The listing process for modules, categories, tasks, files, all tasks at the specified time period, tasks of module in ascending order of deadline and all undone tasks sorted by deadline or priority are similar. In this example, the listing process for modules will be illustrated as a series of steps.
James is a user and wants to list out all of his modules with moduleCode begin with “CS”. Assume that he has the current Module List:

+--------------------------------------------------------------------------------------------------+
 NO |  MODULE CODE   |                                 MODULE TITLE                                 
+--------------------------------------------------------------------------------------------------+
 1  |     CS2101     |             Effective Communication for Computing Professionals              
 2  |    CS2113T     |              Software Engineering & Object-Oriented Programming              
 3  |     CS3230     |                      Design and Analysis of Algorithms                       
 4  |     CS3235     |                              Computer Security                               
 5  |    GEH1036     |                           Living with Mathematics                            
 6  |    IFS4103     |                         Penetration Testing Practice                         
+--------------------------------------------------------------------------------------------------+
Total modules: 6
+--------------------------------------------------------------------------------------------------+

James will first enter the command to list out modules with moduleCode begin with “CS”:
lsm CS
After the input is parsed as a list module command and executed, the ListModuleCommand#execute() will call FilterCommand#createFilteredModuleList() to create the filtered list of modules containing the Modules with moduleCode begin with “CS”. ListModuleCommand#execute() will then call its parent class’s method FilterCommand#sortModuleList(filteredModuleList) to sort the modules by their respective moduleCode. And finally the sorted Arraylist of Modules is used to instantiate a CommandResult object and returned, and ui#showResult(commandResult) will be called to show the result to the user. And Listing process ends.

Below is a sequence diagram to illustrate the above example scenario.

Figure List Module Command Sequence Diagram

3. Delete Command

Overview

Implementation

Figure Delete Command Class Diagram

+--------------------------------------------------------------------------------------------------+
 NO |  MODULE CODE   |                                 MODULE TITLE                                 
+--------------------------------------------------------------------------------------------------+
 1  |     CS1231     |                             Discrete Structures                              
 2  |     CS2101     |             Effective Communication for Computing Professionals              
 3  |     CS2102     |                               Database Systems                               
 4  |    CS2113T     |              Software Engineering & Object-Oriented Programming              
 5  |     CS3235     |                              Computer Security                               
 6  |    GEH1036     |                           Living with Mathematics                            
 7  |    IFS4103     |                         Penetration Testing Practice                         
+--------------------------------------------------------------------------------------------------+
Total modules: 7
+--------------------------------------------------------------------------------------------------+

The sequence diagram for stage ❶:

Figure Delete Command Sequence Diagram 1

Multiple matching modules were found.
+--------------------------------------------------------------------------------------------------+
 NO |  MODULE CODE   |                                 MODULE TITLE                                 
+--------------------------------------------------------------------------------------------------+
 1  |     CS1231     |                             Discrete Structures                              
 2  |     CS2101     |             Effective Communication for Computing Professionals              
 3  |     CS2102     |                               Database Systems                               
 4  |    CS2113T     |              Software Engineering & Object-Oriented Programming              
 5  |     CS3235     |                              Computer Security                               
+--------------------------------------------------------------------------------------------------+
Total modules: 5
+--------------------------------------------------------------------------------------------------+

Enter the list number(s) of the modules to delete.

This is the sequence diagram for stage ❷:

Figure Delete Command Sequence Diagram 2

Confirm delete these modules?
CS1231 Discrete Structures
CS2102 Database Systems

Below is the sequence diagram for stage ❸:

Figure Delete Command Sequence Diagram 3

SUCCESS!! Module(s) have been deleted.

​

Back To Top

Design Considerations

Filtering for Deletion

• Alternative 1: Do not allow filtering for deleting directories
  • Pros: Easy to implement. We would only have to check if the directory exists, and then delete it from its respective list.
  • Cons: Multiple deletions would not be supported. User has to delete one directory at a time, and can be tedious, especially if the user wants to delete several directories with the similar names.
• Alternative 2: Allow filtering for deleting directories (current implementation)
  • Pros: User can delete multiple directories at the same time with ease. This is especially useful when deleting directories with similar names, such as deleting a set of tasks with descriptions starting with “tutorial”.
  • Cons: Relatively harder to implement. 😧
    
    

Prompts for Deletion

• Alternative 1: No prompts for deletion
  • Pros: Easy to implement. Deletion process will be fast! 😁 Simply search for the directories and then delete them.
  • Cons: The user may accidentally delete the wrong directory! 😱 (although may still be undone with the undo command) This is made worse if a wrong deletion is made during multiple deletions.
• Alternative 2: Prompts are enabled (current implementation)
  • Pros: User has another chance to choose to confirm the deletion. 😅 This reduce the chance of accidental deletions happening.
  • Cons: Deletion process is now longer. The user has to go through another layer of confirmation despite being sure that he he deleting the correct directories (but who knows?). Moreover, we will have a harder time to implement the delete command, since it has now become multi-staged. Considerations have to be made to counter scenarios with zero, one or more matches after filtering. We will also have to consider how the Parser will be able to recognise if the user’s input is a regular command, or an input corresponding to a prompt for list number, or a prompt for delete confirmation.

Back To Top

4. Edit Command

Overview

Implementation

Figure Edit Commands Class Diagram

An example sequence diagram is shown below when a user requests to edit a category:


Figure Edit Command Sequence Diagram

Back To Top

Design Considerations

Editing Task

• Alternative 1: Merge EditTaskCommand class with MarkAsDoneCommand class
  • Pros: There is one less class to implement. Also, the user does not need to remember another command word.
  • Cons: While there may be one less command word, there may be one more prefix for the user to remember as well. Also, marking a task as done seems to be more specific compared to changing the attributes of the task such as its description and deadline.
• Alternative 2: Have separate EditTaskCommand and MarkAsDoneCommand classes (current implementation)
  • Pros: Have a more specialised class just to mark user’s tasks as done. Easier to implement and differentiates from the standard EditTaskCommand.
  • Cons: There is one more command word for the user to remember.
    
    

Edit Multiple Attributes

• Alternative 1: User can only edit one attribute of a directory at a time
  • Pros: May be easier to implement. Checking that the user has provided an attribute to edit is also simple (just check if the attribute is empty).
  • Cons: The user may want to edit more than one attributes at the same time. For example, the user may want to change both the name and priority of a category. This means that the user will have to execute the edit category command twice, which is not efficient.
• Alternative 2: User can edit any number for attributes of a directory at a time (current implementation)
  • Pros: The user does not need to keep executing the edit command when editing more than one attribute.
  • Cons: Possibly slightly harder to implement. We now have to check if the user has provided at least one attribute to be edited. Also, we need to be able to efficiently extract the individual attributes from the user’s input. However, this could be made easier by grouping and matching the attributes using Java’s RegEx patterns.

Back To Top

5. Change Directory Command

Overview

Implementation

Shown below is the sequence diagram when a user executes the change directory command to traverse down to another directory.


Figure Change Directory Command Sequence Diagram

Back To Top

Design Considerations

Traversal Method

• Alternative 1: User can only traverse one level at a time (current implementation)
  • Pros: Simple to implement. Only need to consider getting the direct parent or child directory.
  • Cons: User may have to keep executing the change directory command just to reach their desired directory, especially if the user’s current directory is “far” from the destination directory.
• Alternative 2: User can traverse more than one level at a time, similar to Linux Shell.
  • Pros: Saves user time from having to possibly execute the change directory command multiple times. User can simply enter cd directory1/directory2/directory3 and move four directory levels down.
  • Cons: Much harder to implement as we need to consider how the split the String into individual directory names. Furthermore, we have to consider the case if the provided directory name contains /, and how we will implement a method to differentiate the / in the name from a / in the directory path.

Back To Top

6. Open File Command

Overview

Implementation

Below is a sequence diagram of how the open file command operates:

Figure Open File Command Sequence Diagram

Back To Top

Design Considerations

Allow opening of multiple files

• Alternative 1: User can open only one file at a time
  • Pros: Simple to implement. Just search for the corresponding File Directory, get the file path, then open the real file in that path.
  • Cons: User would usually want to open all or most of the files attached to the task. Opening each file one by one will reduce the ease of using the application.
• Alternative 2: User can choose which files they want to open from a list of files shown to them
  • Pros: User can open exactly the files that they require at the moment.
  • Cons: Much harder to implement as we need to consider how the process to prompt the user to choose the files would be enforced. Thereafter, we need to check if the selection exists in the list of files.
• Alternative 3: User can choose to open a specified file, or all the files of the task (current implementation)
  • Pros: User now has a choice, and can choose the best between two options.
  • Cons: User now has to close the unwanted files that was opened in the process, which may inconvenience the user.

Back To Top

7. Info Command

Overview

Implementation

The sequence diagram of what happens when a user executes the info command is as illustrated:


Figure Info Command Sequence Diagram

Back To Top

8. Undo and Redo Commands

Overview

Implementation

Below is a sequence diagram of the undo command in action:


Figure Undo Command Sequence Diagram

Back To Top

Design Considerations

Number of undos allowed

• Alternative 1: User can undo only once
  • Pros: Easy to implement, only need to keep track of the state before the change. As such, it also requires less memory to save.
  • Cons: May not be feasible as there may be instances when the user may want to undo more than once.
• Alternative 2: User can undo only a fixed number of times
  • Pros: Allows user to undo more than once. Also, does not incur much memory either as a fixed number of states is saved only.
  • Cons: Need to implement measures and checks for the stacks to ensure they do not exceed the limit, and what to do when it does. User may still request to undo more than the fixed number of times.
• Alternative 3: User can undo any number of times (current implementation)
  • Pros: Allows user the freedom to undo any number of times (until the initial state, of course).
  • Cons: May require more memory to save the many number of states, although it may not be very significant considering the data size of each state tend to be very small (states are saved as a String).
    
    

How undo and redo executes

• Alternative 1: Saves the state of the entire directory list (current implementation)
  • Pros: Easy to implement, can reuse the saveList() and loadList() methods in the StorageManager class.
  • Cons: Uses unnecessary memory as the state of the entire list is saved each time, even though only a small change is made.
• Alternative 2: Individual commands has an undo method, which is able to undo the changes they made.
  • Pros: Uses less memory since the command will only have to record the specific change.
  • Cons: Need to ensure correct implementation of the undo method, and consider scenarios if the command fails to execute.

Back To Top

Storage Implementation

Overview

Implementation

Encoding and Decoding

Figure Storage Manager Class Diagram

Saving

@Override  
public CommandResult execute() {
	... ...
	
	ModuleManager.add(toAdd);
	StorageManager.setIsSave();  
	return new CommandResult(... ...);
	... ...
}

private void runCommandLoopUntilExitCommand() {
	... ...

	if (StorageManager.isToSave()) {  
	    ... ... 
        storageManager.saveList();  
		... ...
	    ScreenShotManager.saveScreenShot();  
	}
	... ...
}

Here is a sequence diagram of what happens during saving after a successful add command:


Figure Storage Manager Sequence Diagram

Back To Top

Design Considerations

When to Save

• Alternative 1: Save after every command execution
  • Pros: Easy to implement since no checking for changes in the Directory Tree involved.
  • Cons: Wasted performance to save when there is no change. Also, it will affect undo and redo operations. For instance, undoing a list command does not do anything to the Directory Tree, and this may confuse the user.
• Alternative 2: Save after every change (current implementation)
  • Pros: This should be the preferred case since the application should save only when a change is made.
  • Cons: We have to think of a way that can allow the application to know what is defined as a change and when it occurs.
    
    

Storage Security

• Alternative 1: Saves the Directory Tree as a String and directly into a .txt file (current implementation)
  • Pros: Easier to implement. Encoding and decoding the data is simpler.
  • Cons: Security may be an issue since the saved file is readable, i.e. not encrypted, and can be accesses by anyone. Also, there is little way to notice if the saved file has been tampered externally.
• Alternative 2: Encrypt the data and saved file
  • Pros: Security is enhanced, and warning can be shown to the user if the file has been tampered.
  • Cons: We have to devise a way to encrypt and decrypt the data. We could possibly look into current encryption schemes like SHA and RSA for this, but it would require some work.

Back To Top

Appendix

Product Scope

Target User Profile

• is an NUS student
• has a need to manage a significant number of academic tasks efficiently and tidily
• willing to keep track of their academic tasks by recording them using an application program
• prefer Desktop apps over other types, and reasonably comfortable with the command line interface
• able to type fast and prefers typing over mouse input

Value proposition

Manage tasks faster and with greater efficiency due to greater organisation of tasks. The application is specifically designed for NUS students to manage academic tasks. Files can be attached to tasks, and opened directly through the application.

Back To Top

User Stories

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

Back To Top

Non-Functional Requirements

1. Should work on any mainstream OS as long as it has Java 11 or above installed.
2. User with above average typing speed for English text (not coding) should be able to utilize the product to manage tasks more efficiently compared to using a mouse.
3. Data entered by the user should be able to saved and carried forward for the next time usage.
4. 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.
5. The product should be able to run without any noticeable sluggishness in performance for typical usage when dealing with up to 100 academic tasks.
6. The product should never crash and able to handle any input from the user.
7. Should work on both 32-bit and 64-bit environments.
8. Should not exceed 30MB in size given normal usage.

Back To Top

Glossary

Mainstream OS

​ Windows, Linux, Unix, OS-X

Average typing speed

​ 40 words per minute

Depth First

To go recursively downwards until the bottom before back-tracking

Back To Top

Instructions for Manual Testing

Given below are instructions to test the application manually.

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 the to folder containing the jar file
   3. Run the jar file by entering command java -jar Nuke.jar and hit enter(replace Nuke.jar by the actual file name you downloaded from the release page)
   4. Expected output: Nuke startup screen and welcome message is displayed
2. Shut down of application
   1. Enter command bye and hit enter
   2. Expected output: Nuke program terminates with farewell message displayed.

2. Add Command

1. Add module
   1. Correct usage:
      1. Test case: addm cs2113t
      2. Expected: the program will prompt the user with message: SUCCESS!! Module CS2113T Software Engineering & Object-Oriented Programming is added.
   2. Wrong usage:
      1. Test case: addm cs1111
      2. Expected: the program will prompt the user with message: Sorry, the module is not provided by NUS currently.
      3. Test case: addm cs2113t after executing addm cs2113t
      4. Expected: the program will prompt the user with message: Sorry, the module already exists.
2. Add category
   1. Correct usage:
      1. Test case: addc Project -m cs2113t after adding cs2113t as module
      2. Expected: the program will prompt the user with message: SUCCESS!! Category Project is created.
   2. Wrong usage:
      1. Test case: addc Tutorial -m cs2113t after adding cs2113t as module
      2. Expected: the program will prompt the user with message: Sorry, the category already exists.
      3. Test case: addc Project -m cs3235 without adding cs3235 as module
      4. Expected: the program will prompt the user with message Sorry, the module is not found.
3. Add task
   1. Correct usage:
      1. Test case: addt assignment2 -m cs2113t -c Assignment -d tmr 23:59 -p 15 after adding cs2113t as module
      2. Expected: the program will prompt the user with message: SUCCESS!! Task assignment2 is created.
   2. Wrong usage:
      1. Test case: addt assignment2
      2. Expected: the program will prompt the use with message: Sorry, unable to execute the command at the current directory level. Either move to the appropriate directory level, or enter the full directory path.
      3. Test case: addt testingaveryveryveryveryverylongstring -m cs2113t -c Assignment -d tmr 23:59 -p 15 after adding cs2113t as module
      4. Expected: the program will prompt the user with message: Sorry, the task description cannot exceed 25 characters.
4. Add file
   1. Correct usage:
      1. Test case: addf test.pdf -m cs2113t -c Assignment -t assignment2 -f c:\users\null\downloads\assignment2.pdf after adding an assignment2 task under Assignment category and cs2113t module, assuming c:\users\null\downloads\assignment2.pdf exists.
      2. Expected: the program will prompt the user with message: SUCCESS!! File test.pdf is added.
   2. Wrong usage:
      1. Test case: addf test.pdf -m cs2113t -c Assignment -t non-exist-task -f c:\users\null\downloads\assignment2.pdf without adding the respective task
      2. Expected: the program will prompt the user with message: Sorry, the task is not found.

5. Add tag

   1. Correct usage:
      1. Test case: addg urgent -m cs2113t -c Assignment -t assignment2 after adding an assignment2 task under Assignment category and cs2113t module
      2. Expected: the program will prompt the user with message: SUCCESS!! Tag urgent is added.

   2. Wrong usage:

      1. Test case: addg urgent -m cs2113t -c Assignment -t non-exist-task
      2. Expected: the program will prompt the user with message: Sorry, the task is not found.
      3. Test case: addg urgent -t assignment2
      4. Expected: the program will promit the user with message: Sorry, unable to execute the command at the current directory. Either move to the appropriate directory level, or enter the full directory path.

3. Delete Command

1. Delete modules
   1. Correct usage:
      1. Test case: delm cs2113t
      2. Expected: the program will prompt the user with message: Confirm delete CS2113T Software Engineering & Object-Oriented Programming? and user enter y and hit enter, the program will prompt the user with message: SUCCESS!! Module(s) have been deleted.
   2. Wrong usage:
      1. Test case: delm cs1111
      2. Expected: the program will prompt the user with message: Sorry. No modules found.
2. Delete category
   1. Correct usage:
      1. Test case: delc Assignment -m cs2113t
      2. Expected: the program will prompt the user with message: Confirm delete Assignment? and user enter y and hit enter, the program will prompt the user with message: SUCCESS!! Category(s) have been deleted.
   2. Wrong usage:
      1. Test case: delc Project -m cs2113t
      2. Expected: the program will prompt the user with message: Sorry. No categories found.
3. Delete task
   1. Correct usage:
      1. Test case: delt assignment2 -m cs2113t -c Assignment
      2. Expected: the program will prompt the user with message: Confirm delete assignment2? and user enter y and hit enter, the program will prompt the user with message: SUCCESS!! Task(s) have been deleted.
   2. Wrong usage:
      1. Test case: delt non-exist-task
      2. Expected: the program will prompt the use with message: Sorry. No tasks found.
4. Delete file
   1. Correct usage:
      1. Test case: delf test.pdf -m cs2113t -c Assignment -t assignment2
      2. Expected: Expected: the program will prompt the user with message: Confirm delete test.pdf? and user enter y and hit enter, the program will prompt the user with message: SUCCESS!! Files(s) have been deleted.
   2. Wrong usage:
      1. Test case: delf non-exist.pdf -m cs2113t -c Assignment -t assignment2
      2. Expected: the program will prompt the user with message: Sorry. No files found.
5. Delete tag
   1. Correct usage:
      1. Test case: delg urgent -m cs2113t -c Assignment -t assignment2
      2. Expected: the program will prompt the user with message: Confirm delete tag urgent of the task assignment2? and user enter y or yes, the program will prompt the user with message: SUCCESS!! Tag(s) have been deleted.
      3. Test case: delg
      4. Expected: the program will prompt the user with message: Confirm delete tag urgent of the task assignment2? and user enter n or no, the program will prompt the user with message: The deletion is aborted
   2. Wrong usage:
      1. Test case: delg non-exist-tag -m cs2113t -c Assignment -t assignment2
      2. Expected: the program will prompt the user with message: Sorry. No tasks with the tag found.

4. List Command

1. List modules

   1. Test case: lsm

   2. Expected: the program display a table containing all the modules added by the user as shown below:

Back To Top

1. List tags

   1. Test case: lsg -m cs2113t -c Assignment -t assignment2

   2. Expected: the program display a table containing all the tags of the task assignment2 under module cs2113t and category Assignment added by the user as shown below:

1. Correct Usage:
   1. Test case: enter cd cs2113t
   2. Expected: the program prompt will be changed to root / CS2113T : from root :
2. Wrong Usage:
   1. Test case: enter cd ..
   2. Expected: the program prompt the user with message: Unable to traverse further.

5. Info Command

1. Test case: enter info

2. Expected: the program will display the information about the current directory to the user as shown below:

6. Open File Command

1. Test case: enter open test.pdf -m cs2113t -c Assignment -t assignment2
2. Expected: test.pdf will be opened automatically using the default pdf application.

Back To Top

Contact Us

Back To Top