Project Level 4 - Developer Guide

By: T09-3 Since: 22 Feb 2019 Licence: MIT

1. Introduction
2. How to use this guide
- 2.1. Icons Meaning
3. Setting up
4. Design
5. Implementation
6. Documentation
7. Testing
8. Dev Ops
9. Product Scope
Appendix A: User Stories
Appendix B: Use Cases
Appendix C: Non Functional Requirements
Appendix D: Glossary
Appendix E: Instructions for Manual Testing

1. Introduction

Welcome to NoteNote (NN)!

If you’re looking for an application to organize your projects you’ve come to the right place! But that’s not all NoteNote can do! NoteNote can also keep track of individual tasks, analyze your productivity and share your To-Do list with your friends!

We designed the application ground up for computing students, so you can say that NoteNote is designed for computing students, by computing students, so you can be sure that it will fulfil all your project management needs!

Built for computing students, NoteNote uses minimal (GUI) elements, instead opting for a faster Command Line Interface (CLI) while maintaining the benefits of the GUI. So if you can type fast and are used to command line, NoteNote is sure to help manage your task faster than other traditional GUI based task managers.

2. How to use this guide

There are several terms which we use throughout our guide. To make your life easier, please do read the following section to ensure that you are able to use our Developer Guide to the fullest extent!

2.1. Icons Meaning

Various icons are also used throughout this user guide with the following context:

💡	This is a tip. Follow these suggested tips to make your life much simpler when using NoteNote!

ℹ️	This is a note. These are things for you to take note of when using NoteNote.

3. Setting up

3.1. Prerequisites

JDK 9

⚠️
JDK 10 on Windows will fail to run tests in headless mode due to a JavaFX bug. Windows developers are highly recommended to use JDK 9.
IntelliJ IDE

ℹ️
IntelliJ by default has Gradle and JavaFx plugins installed.
Do not disable them. If you have disabled them, go to File > Settings > Plugins to re-enable them.

3.2. Setting up the project in your computer

Fork this repo, and clone the fork to your computer
Open IntelliJ (if you are not in the welcome screen, click File > Close Project to close the existing project dialog first)
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
Click Import Project
Locate the build.gradle file and select it. Click OK
Click Open as Project
Click OK to accept the default settings
Open a console and run the command gradlew processResources (Mac/Linux: ./gradlew processResources). It should finish with the BUILD SUCCESSFUL message.
This will generate all resources required by the application and tests.
Open MainWindow.java and check for any code errors
1. Due to an ongoing issue with some of the newer versions of IntelliJ, code errors may be detected even if the project can be built and run successfully
2. To resolve this, place your cursor over any of the code section highlighted in red. Press ALT+ENTER, and select Add '--add-modules=…' to module compiler options for each error
Repeat this for the test folder as well (e.g. check HelpWindowTest.java for code errors, and if so, resolve it the same way)

3.3. Verifying the setup

Run the seedu.project.MainApp and try a few commands
Run the tests to ensure they all pass.

3.4. Configurations to do before writing code

3.4.1. Configuring the coding style

This project follows oss-generic coding standards. IntelliJ’s default style is mostly compliant with ours but it uses a different import order from ours. To rectify,

Go to File > Settings… (Windows/Linux), or IntelliJ IDEA > Preferences… (macOS)
Select Editor > Code Style > Java
Click on the Imports tab to set the order
- For Class count to use import with '*' and Names count to use static import with '*': Set to 999 to prevent IntelliJ from contracting the import statements
- For Import Layout: The order is import static all other imports, import java.*, import javax.*, import org.*, import com.*, import all other imports. Add a <blank line> between each import

Optionally, you can follow the UsingCheckstyle.adoc document to configure Intellij to check style-compliance as you write code.

3.4.2. Updating documentation to match your fork

After forking the repo, the documentation will still have the SE-EDU branding and refer to the se-edu/addressbook-level4 repo.

If you plan to develop this fork as a separate product (i.e. instead of contributing to se-edu/addressbook-level4), you should do the following:

Configure the site-wide documentation settings in build.gradle, such as the site-name, to suit your own project.
Replace the URL in the attribute repoURL in DeveloperGuide.adoc and UserGuide.adoc with the URL of your fork.

3.4.3. Setting up CI

Set up Travis to perform Continuous Integration (CI) for your fork. See UsingTravis.adoc to learn how to set it up.

After setting up Travis, you can optionally set up coverage reporting for your team fork (see UsingCoveralls.adoc).

ℹ️	Coverage reporting could be useful for a team repository that hosts the final version but it is not that useful for your personal fork.

Optionally, you can set up AppVeyor as a second CI (see UsingAppVeyor.adoc).

ℹ️	Having both Travis and AppVeyor ensures your App works on both Unix-based platforms and Windows-based platforms (Travis is Unix-based and AppVeyor is Windows-based)

3.4.4. Getting started with coding

When you are ready to start coding,

Get some sense of the overall design by reading Section 4.1, “Architecture”.
Take a look at [GetStartedProgramming].

4. Design

4.1. Architecture

Figure 1. Architecture Diagram

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

💡	The `.pptx` files used to create diagrams in this document can be found in the diagrams folder. To update a diagram, modify the diagram in the pptx file, select the objects of the diagram, and choose `Save as picture`.

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

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

Commons represents a collection of classes used by multiple other components. The following class plays an important role at the architecture level:

LogsCenter : Used by many classes to write log messages to the App’s log file.

The rest of the App consists of four components.

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

Each of the four components

Defines its API in an interface with the same name as the Component.
Exposes its functionality using a {Component Name}Manager class.

For example, the Logic component (see the class diagram given below) defines it’s API in the Logic.java interface and exposes its functionality using the LogicManager.java class.

Figure 2. Class Diagram of the Logic Component

How the architecture components interact with each other

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

Figure 3. Component interactions for delete 1 command

The sections below give more details of each component.

4.2. UI component

Figure 4. Structure of the UI Component

API : Ui.java

The UI consists of a MainWindow that is made up of parts e.g.CommandBox, ResultDisplay, TaskListPanel, StatusBarFooter, BrowserPanel etc. All these, including the MainWindow, inherit from the abstract UiPart class.

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

The UI component,

Executes user commands using the Logic component.
Listens for changes to Model data so that the UI can be updated with the modified data.

4.3. Logic component

Figure 5. Structure of the Logic Component

API : Logic.java

Logic uses the ProjectParser class to parse the user command.
This results in a Command object which is executed by the LogicManager.
The command execution can affect the Model (e.g. adding a task).
The result of the command execution is encapsulated as a CommandResult object which is passed back to the Ui.
In addition, the CommandResult object can also instruct the Ui to perform certain actions, such as displaying help to the user.

Given below is the Sequence Diagram for interactions within the Logic component for the execute("delete 1") API call.

Figure 6. Interactions Inside the Logic Component for the delete 1 Command

4.4. Model component

Figure 7. Structure of the Model Component

API : Model.java

The Model,

stores a UserPref object that represents the user’s preferences.
stores the Project List Data and Project Data.
exposes an unmodifiable ObservableList<Task> that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.
does not depend on any of the other three components.

The Storage component,

can save UserPref objects in json format and read it back.
can save the Address Book data in json format and read it back.

4.5. Common classes

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

5. Implementation

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

5.1. Undo/Redo feature

5.1.1. Current Implementation

The undo/redo mechanism is facilitated by VersionedProject. It extends Project with an undo/redo history, stored internally as an projectStateList and currentStatePointer. Additionally, it implements the following operations:

VersionedProject#commit() — Saves the current project state in its history.
VersionedProject#undo() — Restores the previous project state from its history.
VersionedProject#redo() — Restores a previously undone project state from its history.

These operations are exposed in the Model interface as Model#commitProject(), Model#undoProject() and Model#redoProject() respectively.

Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.

Step 1. The user launches the application for the first time. The VersionedProject will be initialized with the initial project state, and the currentStatePointer pointing to that single project state.

Step 2. The user executes delete 5 command to delete the 5th task in the project. The delete command calls Model#commitProject(), causing the modified state of the project after the delete 5 command executes to be saved in the projectStateList, and the currentStatePointer is shifted to the newly inserted project state.

Step 3. The user executes add n/David … to add a new task. The add command also calls Model#commitProject(), causing another modified project state to be saved into the projectStateList.

ℹ️	If a command fails its execution, it will not call `Model#commitProject()`, so the project state will not be saved into the `projectStateList`.

Step 4. The user now decides that adding the task was a mistake, and decides to undo that action by executing the undo command. The undo command will call Model#undoProject(), which will shift the currentStatePointer once to the left, pointing it to the previous project state, and restores the project to that state.

ℹ️

If the currentStatePointer is at index 0, pointing to the initial project state, then there are no previous project states to restore. The undo command uses Model#canUndoProject() to check if this is the case. If so, it will return an error to the user rather than attempting to perform the undo.

The following sequence diagram shows how the undo operation works:

The redo command does the opposite — it calls Model#redoProject(), which shifts the currentStatePointer once to the right, pointing to the previously undone state, and restores the project to that state.

ℹ️

If the currentStatePointer is at index projectStateList.size() - 1, pointing to the latest project state, then there are no undone project states to restore. The redo command uses Model#canRedoProject() to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo.

Step 5. The user then decides to execute the command list. Commands that do not modify the project, such as list, will usually not call Model#commitProject(), Model#undoProject() or Model#redoProject(). Thus, the projectStateList remains unchanged.

Step 6. The user executes clear, which calls Model#commitProject(). Since the currentStatePointer is not pointing at the end of the projectStateList, all project states after the currentStatePointer will be purged. We designed it this way because it no longer makes sense to redo the add n/David … command. This is the behavior that most modern desktop applications follow.

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

5.1.2. Design Considerations

Aspect: How undo & redo executes

Alternative 1 (current choice): Saves the entire project.
- Pros: Easy to implement.
- Cons: May have performance issues in terms of memory usage.
Alternative 2: Individual command knows how to undo/redo by itself.
- Pros: Will use less memory (e.g. for delete, just save the task being deleted).
- Cons: We must ensure that the implementation of each individual command are correct.

Aspect: Data structure to support the undo/redo commands

Alternative 1 (current choice): Use a list to store the history of project states.
- Pros: Easy for new Computer Science student undergraduates to understand, who are likely to be the new incoming developers of our project.
- Cons: Logic is duplicated twice. For example, when a new command is executed, we must remember to update both HistoryManager and VersionedProject.
Alternative 2: Use HistoryManager for undo/redo
- Pros: We do not need to maintain a separate list, and just reuse what is already in the codebase.
- Cons: Requires dealing with commands that have already been undone: We must remember to skip these commands. Violates Single Responsibility Principle and Separation of Concerns as HistoryManager now needs to do two different things.

5.2. Import/Export feature

The import and export feature was implemented in order to facilitate easy transfer of projects and tasks between two NoteNote users.

5.2.1. Current Implementation

The import feature reads projects from a JSON file provided as input and adds these projects on top of the current list of projects. The mechanism is facilitated by JsonUtil and is achieved using the following functions:

JsonUtil#readJsonFile() — Read projects from JSON file
VersionedProjectList#addProject() — Adds projects from JSON file to project list.

The export feature exports the current selected project (after select 1) or projects specified by their index to a JSON file. The mechanism is facilitated by FileUtil and JsonUtil and is achieved using the following functions:

FileUtil#createIfMissing() — Creates JSON file to write to if it does not exist
JsonUtil#saveJsonFile() — Writes projects to JSON file

Given below is an example usage scenario and how the import/export mechanism behaves at each step.

Step 1. The user launches the application, projectList will be populated by invoking StorageManager#readProjectList.

ℹ️	If user launches the application for the first time, `projectList` will be populated with sample project list as *./data/projectlist.json* does not exist.

Step 2. The user executes import ./data/import.json to add projects from JSON file to versionedProjectList.

Path to JSON file is passed to JsonUtil#readJsonFile() which would read projects to a temporary project list.
Application will then loop through all projects and add them to versionedProjectList using VersionedProjectList#addProject().
updateFilteredProjectList is then executed to refresh ProjectListPanel with all projects, including recently imported projects.

The following sequence diagram shows how the import operation works:

Figure 8. Sequence Diagram for import Command

Step 3. The user executes export i/1,2,3 o/./data/export.json to export projects with index 1, 2 and 3.

Application will get the projects from filteredProjectList and add them to a new ProjectList projectsToExport.
projectsToExport is then passed to JsonUtil#saveJsonFile() which would write to output file specified by user.

ℹ️	The entire project list could be found in *./data/projectlist.json*

The following sequence diagram shows how the export operation works:

Figure 9. Sequence Diagram for export Command

5.2.2. Design Considerations

We considered two designs for the format to import and export multiple projects and tasks within the project list.

	Alternative one	Alternative two
Consideration	Each project will have its own *<Project File>.json* which contains only that project’s tasks.	All projects and all tasks to be contained in a single *project.json* file.
Pros	Easy to implement.	Will not clutter data folder.
Cons	May clutter data folder with too many project files. Application will have to read a new project file whenever user switches project.	Storage model has to be modified to support new storage structure.
Current Choice		This option was chosen as users need not handle multiple files when importing and exporting projects.

5.3. Compare Task feature

The Compare Task feature allows the user to compare the past iteration of a task before it was edited.

5.3.1. Current Implementation

Building on top of the Undo/Redo feature, it is facilitated by VersionedProject and implements the following operations:

VersionedProject#compareTask() — Compares the chosen task with its previous version if it exist.

Figure 10. Sequence Diagram for compare Command

Given above (Figure 10) is the sequence diagram when compare is called.

These operations are exposed in the Model interface as Model#compareTask().

Figure 11. Example of VersionedProject when edit on Task B

Given above (Figure 11.) is an example usage scenario and how the Compare Task mechanism behaves.

Step 1. The user selects the task to compare by entering the index of the task that is shown. CompareCommandParser#CompareCommand() will then get the index of the task within projectStateList and passed into CompareCommand#CommandResult().

Step 2. The index will then be used by CompareCommand#CommandResult() to retrieved the Task object within projectStateList and passed into VersionedProject#compareTask().

Step 3. VersionedProject#compareTask() will retrieve the unique taskId of the chosen task.

Figure 12. Process of how compare command will flow

Step 4. VersionedProject#compareTask() will iterate through all the the tasks within each project state. The taskId will be used to determine if the task encountered during the iteration is the same as the chosen task (Figure 12, A).

ℹ️	If no same tasks are found after iterating through all the project states, or if there is no difference in all the task that is encountered, "Nothing to compare" will be showed to the user.

Step 5. If the task encountered is the same as the chosen task, the 2 task will be compared against their name, description & deadline (Figure 12, B).

Figure 13. A successful compare where name is different

Step 6. If there is a difference in any of the fields in the comparison (Figure 13), the difference will be showed to the user. Else Step 4. will continue to run to look for another version of the chosen task to compare (Figure 12, C).

5.3.2. Design Considerations

Two designs was considered for the implementation of compare. The pros and cons of the designs are listed in the table below and our chosen option is Alternative 1

	Alternative 1	Alternative 2
Design	Utilise existing versionedProject to look for the specific task in previous versions.	All tasks will have their own "versionedTask", keeping track of its own history per task.
Pros	Easy to implement.	System performance will be better as you will iterate through lesser data.
Cons	A large versionedProject might result in a slow system performance.	Harder to implement, can be considered for future version in v2.0
Implementation Choice	Implemented

5.4. List Feature

5.4.1. Current Implementation

Step 1: User uses list feature in task level to list all tasks and in project level to list all projects

Step 2: List checks if the program is in the task level or project level by LogicManager#getState()

Step 3:

If the program is in the project level, it updates the Model#filteredProjectList using Model#updateFilteredProjectList and the predicate Model#PREDICATE_SHOW_ALL_PROJECTS.
If the program is in the task level, it updates the Model#filteredTaskList using the Model#updateFilteredTaskList and the predicate Model#PREDICATE_SHOW_ALL_TASKS.

This results in the relavent panels updating to show all tasks (if entered in the task level) or all projects (if entered in the project level)

Figure 14. Sequence Diagram for list Command

5.4.2. Design Considerations

	Alternative 1
Design	Command which check which level it is currently on and lists projects or tasks based on it.
Pros	No need for two separate functions for listing tasks or listing projects
Cons	Implementation is more prone to bugs and harder to debug

5.5. List Projects Feature

5.5.1. Current Implementation

Step 1: User uses listproject to navigate from the task level to the project level

Step 2: Uses LogicManager#setState() to set display the project level

Step 3: Syncs versionedProject with versionedProjectList using

This results in the relavent panels updating to show all projects and hiding the task panel

5.5.2. Design Considerations

	Alternative 1
Design	Changes `LogicManager` state and hides the task panel
Pros	Easy to implement
Cons	Simple command with no cons

5.6. SortDeadline Feature

5.6.1. Current Implementation

Step 1: Sort command should be done in the task level to ensure this, LogicManager.getState() is executed and user is asked to move to task level if command was entered in the project level.

Step 2: The list of tasks is obtained via Model#getFilteredTaskLIst() and stored in a observable list `filteredTasks

Step 3: filteredTasks is sorted via the provided comparator and stored as a sorted list sortedList

Step 4: The list of tasks in Model is cleared using Model#clearTasks()

Step 5: The list of tasks are entered individually into model from the sortedList by using a loop and the Model#addTask()

Figure 15. Sequence Diagram for sortDeadline Command

5.6.2. Design Considerations

Two designs was considered for the implementation of sortDeadline. The pros and cons of the designs are listed in the table below and our chosen option is Alternative 1

	Alternative 1	Alternative 2
Design	Sort would be permanent	Sort would be temporary
Pros	User would have to use sort function less often	Would impact other functions lesser
Cons	Harder to implement as it would affect other functions	Less user friendly

5.7. List Tag feature

The listtag feature allows users to list all unique tags and associated tasks within a project. It requires users to navigate to a project first with select command before executing the listtag command. Failure to do so would trigger an error message prompting users to do so.

5.7.1. Current Implementation

Step 1. The user launches the application. projectList will be populated by invoking StorageManager#readProjectList.

Step 2. The user selects a project. setProject() is invoked based on Model#filteredProjectList, and the tasks for that project are displayed via invoking Model#filteredTaskList.

Step 3: User displays all tags and their associated tasks in the project by entering listtag and the following operations are carried out:

ListTagCommand calls Model#getTagWithTaskList() who in turns calls Model#getUniqueTagList()
Model#getUniqueTagList() makes use of the list of tasks obtained from filteredTask to iterate through all tasks and returns a list of unique tags within each project state
Model#getTagWithTaskList() uses a nested loop to iterate through this list of unique tags and the list of tasks to concatenate all tasks with the same tags into a string
This string is returned to ListTagCommand and displayed to CommandResult

The following sequence diagram shows how the List Tag operation works:

Figure 16. Sequence Diagram for listtag Command

5.7.2. Design Considerations

Two designs was considered for the implementation of listtag. The pros and cons of the designs are listed in the table below and our chosen option is Alternative 1

	Alternative 1	Alternative 2
Design	Seperate parsing and cleaning of `filteredTask` to obtain the string of tags with their associated task to be done at `Model`	Parsing and cleaning of `filteredTask` to obtain the string of tags with their associated task to be done directly at `ListTagCommand`
Pros	Functions are reusable since they are located `Model`	Easy to implement.
Cons	A large `Model` might result in a slow system performance.	`ListTagCommand` will be cluttered and many of its functions will not be reusable.

5.8. Define Tag feature

The definetag feature allows users to create a group tag and add multiple child tags into it. It should be used in conjunction with addtag feature.

5.8.1. Current Implementation

definetag feature can be used on both project and task level. Duplicated group tags created from definetag command are not allowed.

Step 1. The user launches the application. projectList will be populated by invoking StorageManager#readProjectList.

Step 2: User creates a new group tag and its associated child tags with definetag.

Step 3: DefineTagCommandParser create a new GroupTag object from the user’s input. The object contains the group tag’s name and its associated tags and are return to DefineTagCommand.

Step 4: DefineTagCommand checks if the returned GroupTag is unique via Model#hasGroupTag() and adds the object to the model with Model#addGroupTag() and Model#commitProjectList if it is.

The following sequence diagram shows how the Define Tag operation works:

Figure 17. Sequence Diagram for definetag Command

5.8.2. Design Considerations

Two designs was considered for the implementation of definetag. The pros and cons of the designs are listed in the table below and our chosen option is Alternative 1

	Alternative 1	Alternative 2
Design	Redefine group tag and its associated child tags every instances of `NoteNote`.	Saves the group tags and its associated child tags created via `DefineTagCommand` into storage
Pros	Easy to implement	Better user experience since group tags established in previous instances of `NoteNote` can still be reused.
Cons	All group tags created in `DefineTagCommand` will be lost once the instance of `NoteNote` is closed.	Harder to implement, can be considered for future version in v2.0

5.9. Add Tag feature

The addtag feature allows users to apply existing group tag to multiple tasks. It should be used in conjunction with definetag feature. It requires users to do the following:

Navigate to a project first with select command before executing the addtag command
Add only an existing group tag defined previously at definetag

Failure to do any of the above would trigger an error message prompting users to do so.

5.9.1. Current Implementation

The addTag feature obtains the target task from FilteredTaskList based on the task index given by the user. It then adds the child tags associated to the group tag defined previously at definetag into the task.

Additionally, it implements the following operations:

VersionedProject#commit() — Saves the current project state in its history
VersionedProjectList#commit() — Saves the current project list state in its history

These operations are exposed in the Model interface as Model#commitProject() and Model#commitProjectList() respectively.

Step 1. The user launches the application. projectList will be populated by invoking StorageManager#readProjectList.

Step 2. The user selects a project. setProject() is invoked based on Model#filteredProjectList, and the tasks for that project are displayed via invoking Model#filteredTaskList.

Step 3: User applies the group tag and its associated child tags in the selected task by entering addtag. The following operations are carried out:

AddTagCommandParser parses the arguments and return them AddTagCommand#AddTagCommand()
lastShownList of all tasks in the current project is obtained from Model using getFilteredTaskList()
Two identical tasks, targetTask and taskToAdd are created based on lastShownList using the index from user’s input.
AddTagCommand will then call Model#getGroupTagList which returns a list of all group tags. Names from the list of group tags will be iterated and checked if it matches the name given by user’s input.
Tags in the group tag will be added taskToAdd if the checks passes.

The following sequence diagram shows how the Add Tag operation works:

Figure 18. Sequence Diagram for addtag Command

5.9.2. Design Considerations

Two designs was considered for the implementation of definetag. The pros and cons of the designs are listed in the table below and our chosen option is Alternative 1

	Alternative 1	Alternative 2
Design	Tags in group tag are added to the task by a separate command and remain visible in Task List	Users can add a group tag into a task via the existing `add` and `edit` command with `gt/GROUPTAG` as a parameter
Pros	Easy to implement	Better user experience by utilizing existing command that users are already familiar with.
Cons	Might be confusing to users since tags are usually added via `add` or `edit` commands	Harder to implement, can be considered for future version in v2.0

5.10. View Task Command History Feature

Allows the user to view a list of all the command history of a chosen task.

5.10.1. Current Implementation

Stores a parallel list userInputHistoryTaskId along userInputHistory, containing the taskId of edit/completed/addtag/delete commands. The list will store 0 for all other commands.

Figure 19. Sequence Diagram for taskhistory Command

Given above (Figure 19) is the sequence diagram when taskhistory is called.

It is facilitated by CommandHistory and implements the following operations:

CommandHistory#addHistoryTaskId() — Adds taskId to the index that is the same as the edit/completed/addtag/delete command. Pads 0 for all other commands.

Step 1. When taskhistory is executed, CommandHistory#getHistory(), CommandHistory#getHistoryTaskId() and Task#getTaskId() is called. Retrieving a list of userInputHistory, a list of userInputHistoryTaskId and the taskID of a task, taskId

Step 2. userInputHistoryTaskId will be iterated through.

Step 2a. If taskId of the selected task appears within userInputHistoryTaskId, the index at that position will be used to retrieve the command string within userInputHistory. The string will then be appended to a ArrayList<string>, commandlist.

Step 3. If commandList is not empty, it will be printed in reverse order(newest command first, oldest command last) to the user.

5.10.2. Behaviour when commands are executed

Figure 20. Behaviour of userTaskHistoryTaskId during add commands

Note the behaviour of useTaskHistoryTaskId when all other commands (not edit/completed/addtag/delete) is called (Figure 20). CommandHistory#addHistoryTaskId() will not be called thus userInputHistoryTaskId will not be updated. However userInputHistory will still be updated as usual.

Figure 21. Behaviour of userTaskHistoryTaskId during edit commands

Note the behaviour when a edit command is called (Figure 21). CommandHistory#addHistoryTaskId() will be called thus userInputHistoryTaskId will be updated with the taskId of the task where the edit command is called on. Observe that positions of previous non-edit command will be filled with 0. userInputHistory will still be updated as usual.

5.10.3. Design Considerations

Two designs was considered for the implementation of taskhistory. The pros and cons of the designs are listed in the table below and our chosen option is Alternative 1

	Alternative 1	Alternative 2
Design	Implement a separate list `userInputHistoryTaskId` alongside `userInputHistory` to contain taskId of task where `edit` is called on.	All tasks will have their own `userInputHistoryTaskId`, keeping track of its own edit history.
Pros	Easy to implement.	System performance will be better as you will iterate through lesser data, will have less wastage of space.
Cons	A large `userInputHistoryTaskId` might result in a slower system performance during search and contains wasted space as well.	Harder to implement, can be considered for future version in v2.0.
Implementation Choice	Implemented

5.11. Completed/Analyse feature

The completed feature allows for tasks to be marked as completed.
The analyse feature allows for viewing of statistics for each project, including:

Number of tasks completed for each project
Percentage of each project completed

5.11.1. Current Implementation

The completed feature obtains the target task from FilteredTaskList based on the task index given by the user, and adds a completed tag to it.
Additionally, it implements the following operations:

VersionedProject#commit() — Saves the current project state in its history
VersionedProjectList#commit() — Saves the current project list state in its history

These operations are exposed in the Model interface as Model#commitProject() and Model#commitProjectList() respectively.

Given below is an example usage scenario and how the completed/analyse mechanism behaves at each step.

Step 1. The user launches the application. projectList will be populated by invoking StorageManager#readProjectList.

Step 2. The user selects a project. setProject() is invoked based on filteredProjectList, and the tasks for that project are displayed via invoking filteredTaskList.

Step 3. The user marks a task as completed by entering completed followed by the index of the task.

lastShownList of all tasks in the current project is obtained from Model using getFilteredTaskList().
Two identical tasks, targetTask and taskToComplete, are created based on lastShownList using the index from user input.
Tags of taskToComplete are obtained using getTags() and checked if they contain a completed tag. If it does not, this indicates that the task has not been completed yet, and a completed tag will be added.

The following sequence diagram shows how the completed operation works:

Figure 22. Sequence Diagram for completed Command

Step 4. The user goes back to project level using listproject. setProject is invoked to sync VersionedProject with VersionedProjectList.

Step 5. The user enters analyse to view statistics of all the projects.

filteredProjects is obtained from getFilteredProjectList().
For each project in filteredProjects, filteredTasks is obtained from getTaskList().
For each task in filteredTasks, getTags() is invoked to check if the task has a completed tag.
The result returned is the number of tasks completed in each project, and the percentage of each project completed.

The following sequence diagram shows how the analyse operation works:

Figure 23. Sequence Diagram for analyse Command

5.11.2. Design Considerations

Aspect: Implementation of `completed` feature

Two designs were considered for the implementation of completed. The pros and cons of the designs are listed in the table below and our chosen option is Alternative 1.

	Alternative 1	Alternative 2
Design	`completed` tag added to task, which remains visible in Task List.	Task saved to Storage and removed from display in Task List.
Pros	Adding a specific tag to the existing task can be done using existing `addTag()`.	`DeleteCommand` can be used to delete task from Task List.
Cons	Completed task needed to be updated in Task List and Project List.	Storage needs to keep track of all the completed tasks and be able to separate them based on the projects they were under.
Implementation Choice	Implemented This option allows for the user to still be able to view which tasks have been completed, which helps to gauge their own progress.

Two designs were considered for the implementation of analyse. The pros and cons of the designs are listed in the table below and our chosen option is Alternative 2.

	Alternative 1	Alternative 2
Design	`analyse` can only display statistics for one project at a time.	`analyse` can display statistics for all project at one go.
Pros	Easier as only need to iterate through one project’s tasks.	User can easily view progress on all projects with one command.
Cons	User will need to select each project and call `analyse` separately.	More complicated as need to iterate through all tasks in all projects.
Implementation Choice		Implemented User will experience greater convenience and ease of use if one command can display statistics across all projects.

5.12. Logging

We are using java.util.logging package for logging. The LogsCenter class is used to manage the logging levels and logging destinations.

The logging level can be controlled using the logLevel setting in the configuration file (See Section 5.13, “Configuration”)
The Logger for a class can be obtained using LogsCenter.getLogger(Class) which will log messages according to the specified logging level
Currently log messages are output through: Console and to a .log file.

Logging Levels

SEVERE : Critical problem detected which may possibly cause the termination of the application
WARNING : Can continue, but with caution
INFO : Information showing the noteworthy actions by the App
FINE : Details that is not usually noteworthy but may be useful in debugging e.g. print the actual list instead of just its size

5.13. Configuration

Certain properties of the application can be controlled (e.g user prefs file location, logging level) through the configuration file (default: config.json).

6. Documentation

We use asciidoc for writing documentation.

ℹ️	We chose asciidoc over Markdown because asciidoc, although a bit more complex than Markdown, provides more flexibility in formatting.

6.1. Editing Documentation

See UsingGradle.adoc to learn how to render .adoc files locally to preview the end result of your edits. Alternatively, you can download the AsciiDoc plugin for IntelliJ, which allows you to preview the changes you have made to your .adoc files in real-time.

6.2. Publishing Documentation

See UsingTravis.adoc to learn how to deploy GitHub Pages using Travis.

6.3. Converting Documentation to PDF format

We use Google Chrome for converting documentation to PDF format, as Chrome’s PDF engine preserves hyperlinks used in webpages.

Here are the steps to convert the project documentation files to PDF format.

Follow the instructions in UsingGradle.adoc to convert the AsciiDoc files in the docs/ directory to HTML format.
Go to your generated HTML files in the build/docs folder, right click on them and select Open with → Google Chrome.
Within Chrome, click on the Print option in Chrome’s menu.
Set the destination to Save as PDF, then click Save to save a copy of the file in PDF format. For best results, use the settings indicated in the screenshot below.

Figure 24. Saving documentation as PDF files in Chrome

6.4. Site-wide Documentation Settings

The build.gradle file specifies some project-specific asciidoc attributes which affects how all documentation files within this project are rendered.

💡	Attributes left unset in the `build.gradle` file will use their default value, if any.

Table 1. List of site-wide attributes

Attribute name	Description	Default value
`site-name`	The name of the website. If set, the name will be displayed near the top of the page.	not set
`site-githuburl`	URL to the site’s repository on GitHub. Setting this will add a "View on GitHub" link in the navigation bar.	not set
`site-seedu`	Define this attribute if the project is an official SE-EDU project. This will render the SE-EDU navigation bar at the top of the page, and add some SE-EDU-specific navigation items.	not set

6.5. Per-file Documentation Settings

Each .adoc file may also specify some file-specific asciidoc attributes which affects how the file is rendered.

Asciidoctor’s built-in attributes may be specified and used as well.

💡	Attributes left unset in `.adoc` files will use their default value, if any.

Table 2. List of per-file attributes, excluding Asciidoctor’s built-in attributes

Attribute name	Description	Default value
`site-section`	Site section that the document belongs to. This will cause the associated item in the navigation bar to be highlighted. One of: `UserGuide`, `DeveloperGuide`, `LearningOutcomes`, `AboutUs`, `ContactUs` Official SE-EDU projects only	not set
`no-site-header`	Set this attribute to remove the site navigation bar.	not set

6.6. Site Template

The files in docs/stylesheets are the CSS stylesheets of the site. You can modify them to change some properties of the site’s design.

The files in docs/templates controls the rendering of .adoc files into HTML5. These template files are written in a mixture of Ruby and Slim.

⚠️

Modifying the template files in docs/templates requires some knowledge and experience with Ruby and Asciidoctor’s API. You should only modify them if you need greater control over the site’s layout than what stylesheets can provide. The SE-EDU team does not provide support for modified template files.

7. Testing

7.1. Running Tests

There are three ways to run tests.

💡	The most reliable way to run tests is the 3rd one. The first two methods might fail some GUI tests due to platform/resolution-specific idiosyncrasies.

Method 1: Using IntelliJ JUnit test runner

To run all tests, right-click on the src/test/java folder and choose Run 'All Tests'
To run a subset of tests, you can right-click on a test package, test class, or a test and choose Run 'ABC'

Method 2: Using Gradle

Open a console and run the command gradlew clean allTests (Mac/Linux: ./gradlew clean allTests)

ℹ️	See UsingGradle.adoc for more info on how to run tests using Gradle.

Method 3: Using Gradle (headless)

Thanks to the TestFX library we use, our GUI tests can be run in the headless mode. In the headless mode, GUI tests do not show up on the screen. That means the developer can do other things on the Computer while the tests are running.

To run tests in headless mode, open a console and run the command gradlew clean headless allTests (Mac/Linux: ./gradlew clean headless allTests)

7.2. Types of tests

We have two types of tests:

GUI Tests - These are tests involving the GUI. They include,
1. System Tests that test the entire App by simulating user actions on the GUI. These are in the systemtests package.
2. Unit tests that test the individual components. These are in seedu.project.ui package.
Non-GUI Tests - These are tests not involving the GUI. They include,
1. Unit tests targeting the lowest level methods/classes.
  e.g. seedu.project.commons.StringUtilTest
2. Integration tests that are checking the integration of multiple code units (those code units are assumed to be working).
  e.g. seedu.project.storage.StorageManagerTest
3. Hybrids of unit and integration tests. These test are checking multiple code units as well as how the are connected together.
  e.g. seedu.project.logic.LogicManagerTest

7.3. Troubleshooting Testing

Problem: HelpWindowTest fails with a NullPointerException.

Reason: One of its dependencies, HelpWindow.html in src/main/resources/docs is missing.
Solution: Execute Gradle task processResources.

8. Dev Ops

8.1. Build Automation

See UsingGradle.adoc to learn how to use Gradle for build automation.

8.2. Continuous Integration

We use Travis CI and AppVeyor to perform Continuous Integration on our projects. See UsingTravis.adoc and UsingAppVeyor.adoc for more details.

8.3. Coverage Reporting

We use Coveralls to track the code coverage of our projects. See UsingCoveralls.adoc for more details.

8.4. Documentation Previews

When a pull request has changes to asciidoc files, you can use Netlify to see a preview of how the HTML version of those asciidoc files will look like when the pull request is merged. See UsingNetlify.adoc for more details.

8.5. Making a Release

Here are the steps to create a new release.

Update the version number in MainApp.java.
Generate a JAR file using Gradle.
Tag the repo with the version number. e.g. v0.1
Create a new release using GitHub and upload the JAR file you created.

8.6. Managing Dependencies

A project often depends on third-party libraries. For example, Address Book depends on the Jackson library for JSON parsing. Managing these dependencies can be automated using Gradle. For example, Gradle can download the dependencies automatically, which is better than these alternatives:

Include those libraries in the repo (this bloats the repo size)
Require developers to download those libraries manually (this creates extra work for developers)

9. Product Scope

Target user profile:

COM Students who need to manage multiple projects simultaneously
Prefers typing over mouse input
Is reasonably comfortable using CLI apps

Value proposition: Manage multiple projects and to manage the individual tasks within a project

Appendix A: User Stories

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

Priority	As a …	I want to …	So that I can…
`* * *`	user	add project	manage multiple projects
`* * *`	user	insert task	record tasks that need to be done
`* * *`	user	delele task	get rid of tasks that are completed or no longer need to be done
`* * *`	user	update task	change details of a particular task when changes are necessary
`* * *`	user	read task	look through and be reminded of the details of a specific task
`*`	user	break down tasks into subtasks	easily view and complete them step-by-step
`*`	user	insert subtask	record smaller tasks or more specific action items to be done
`*`	user	delete subtask	get rid of subtasks that are completed or no longer needs to be done
`*`	user	update subtask	change details of a particular subtask when changes are necessary
`*`	user	read subtask	look through and be reminded of the details of a specific subtask
`*`	user	set recurring subtask	spare myself from the need to manually add the same task to future dates
`*`	user	delete recurring subtask	get rid of tasks that I no longer want to have repeated reminders of
`*`	user	update recurring subtask	change details of a particular recurring task when changes are necessary and have such changes be reflected across all its future recurring subtasks
`*`	user	read recurring subtask	look through and be reminded of the details of a specific recurring subtask
`* *`	user	have a calendar view of tasks	find upcoming tasks via a calendar overview
`* *`	user	have a table view	have an overall view to store and view any kind of structured data
`* * *`	user	insert tags to tasks	categorize tasks based on projects/priority/etc
`* * *`	user	delete tags	remove tags that is unnecessary
`* * *`	user	update tags	change how I want a particular task to be categorised
`* * *`	user	have coloured tags	easily view the categories of tasks at one glance
`* * *`	user	prioritize tasks	complete them in order of importance, especially if they have roughly the same deadlines
`*`	user	share / sync task	make sure that my collaborators are aware of what needs to be done
`* * *`	user	set task deadlines	be reminded when the task is due soon
`* *`	user	show task by creation date	be reminded not to neglect low priority tasks
`* *`	user	have a progress overview	keep track of my productivity based on how much of a project has been completed
`* * *`	user	have a ‘help’ manual	learn how to use various commands to operate this product
`* * *`	advance user	have command shortcuts	type a command faster
`* * *`	user	have export and import function	share task format easily with another user using the same format structure
`*`	user	attach files to task	easily find the corresponding files to work on
`* * *`	user	find task by keywords	easily navigate to the specific task
`* * *`	user	view tasks by alphabetical order	easily find a specific task
`* * *`	user	view task by priority	know what will be due first
`* * *`	user	undo/redo a command	remove/redo a command that I entered/removed by mistake
`* *`	user	view a analysis of my current progress	have a overview of how much I have completed / not completed
`* * *`	user	view the previous version of my task	see what changes I have made previously
`* * *`	user	view the edit history of my task	see all the changes I have made to the task

Appendix B: Use Cases

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

Use case: Creating a project listing

MSS

User requests to create a project listing *1a. User submits the following information. Project ID || Project Name || Project description || Project end date || Module
ProjectManager creates the project listing

Use case ends.

Use case: Adding a task within a project

MSS

User request to view all project listings
ProjectManager shows all project listings
User request to view all task within a chosen project
ProjectManager shows all tasks within the chosen project
User request to create task within selected project
- 5a. User submits the following information: Task ID| Task Name | Deadline | Description | Tags (Priority Level, collaborators, etc…)
ProjectManager creates task

Use case ends.

Extensions

5a1 Missing information
- 5a1a ProjectManager displays error message
  
  Use case resumes at step 5

Use case: Manage existing task (managing tags)

MSS

User request to view all project listings
ProjectManager shows all project listings
User request to view all task within a chosen project
ProjectManager shows all tasks within the chosen project
User request to edit tags of chosen tag
- 5a. User submits the following information: Task ID| Current Tag Name | New Tag Name
ProjectManager updates tag

Use case ends.

Extensions

5a1 Task ID not found / Current Tag Name not found
- 5a1a ProjectManager displays error message
  
  Use case resumes at step 5

Use case: Delete existing task

MSS

User request to view all project listings
ProjectManager shows all project listings
User request to view all task within a chosen project
ProjectManager shows all tasks within the chosen project
User request to delete a specific task
ProjectManager deletes task

Use case ends.

{More to be added}

Appendix C: Non Functional Requirements

Should work on any mainstream OS as long as it has Java 9 installed.
Should be able to hold up to 1000 tasks without a noticeable sluggishness in performance for typical usage.
A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.

Appendix D: Glossary

Mainstream OS: Windows, Linux, Unix, OS-X
Private contact detail: A contact detail that is not meant to be shared with others

Appendix E: Instructions for Manual Testing

Given below are instructions to test the app manually.

ℹ️	These instructions only provide a starting point for testers to work on; testers are expected to do more exploratory testing.

E.1. Launch and Shutdown

Initial launch
1. Download the jar file and copy into an empty folder
2. Double-click the jar file
  Expected: Shows the GUI with a set of sample projects and task. The window size may not be optimum.
Saving window preferences
1. Resize the window to an optimum size. Move the window to a different location. Close the window.
2. Re-launch the app by double-clicking the jar file.
  Expected: The most recent window size and location is retained.

E.2. Deleting a task

Deleting a task while all task of a chosen project are listed
1. Prerequisites: List all task using the list x command from the project listing page (where x is the project ID). Multiple tasks in the list.
2. Test case: delete 1
  Expected: First task is deleted from the list. Details of the deleted contact shown in the status message. Timestamp in the status bar is updated.
3. Test case: delete 0
  Expected: No task is deleted. Error details shown in the status message. Status bar remains the same.
4. Other incorrect delete commands to try: delete, delete x (where x is larger than the list size) {give more}
  Expected: Similar to previous.

E.3. Importing projects

Import new projects from an external JSON file
1. Prerequisites: JSON file to import should exist and should not contain any duplicate projects.
2. Test case: import ./data/import.json
  Expected: New projects will be added to the list and displayed at Project List panel.
3. Test case: import ./data/filethatdoesnotexist.json
  Expected: No new projects are added to the list as JSON file does not exists.
4. Other incorrect import commands to try: import

E.4. Exporting projects

Export multiple projects to an external JSON file
1. Prerequisites: At least one project should exist in project list.
2. Test case: export i/1 o/./data/export.json
  Expected: Project at index 1 and its tasks will be exported to specified JSON file.
3. Test case: export i/1,2 o/./data/export.json
  Expected: Projects at index 1 and 2 and its tasks will be exported to specified JSON file.
4. Other incorrect export commands to try: export, export i/x o/./data/export.json (where x is larger than the list size)
Export selected project to an external JSON file
1. Prerequisites: At least one project should exist in project list. Select a project to export using the select x command from project level (where x is the project ID).
2. Test case: export o/./data/export.json
  Expected: Selected project and its tasks will be exported to specified JSON file.
3. Other incorrect export commands to try: export

E.5. Compare Task

Compare a task which was previously edited
1. Prerequisites: The task must exist. edit command should be executed on the selected task before and there must be a change in one or more of the following: name, deadline or description.
2. Test case: compare 1
  Expected: Task at index 1 will be being compared against the version before it was edited on. Showing you the differences of what was edited.
3. Other incorrect export commands to try: compare x where x is an index out of bounds or not a number but a string.
Compare a task which was previously not edited
1. Prerequisites: The task must exist. The selected task should not be edited before.
2. Test case: compare 1
  Expected: Task at index 1 will be being compared against the version before it was edited on. Since there is no previous version of it.
3. Other incorrect export commands to try: compare x where x is an index out of bounds or not a number but a string.

E.6. Task History

View the command history for a specific task where edit/completed/addtag/delete has been executed before.
1. Prerequisites: The task must exist. edit/completed/addtag/delete command should be executed on the selected task before.
2. Test case: taskhistory 1
  Expected: A list of commands (edit/completed/addtag/delete) previously entered for the select task will be shown. Latest command will be on top while oldest command will be at the bottom.
3. Other incorrect export commands to try: taskhistory x where x is an index out of bounds or not a number but a string.
View the command history for a specific task where edit/completed/addtag/delete has not been executed before.
1. Prerequisites: The task must exist. edit/completed/addtag/delete command should not have executed on the selected task before.
2. Test case: compare 1 Expected: Since edit/completed/addtag/delete has not been executed on the task before, "You have not yet entered any commands for this task." will be shown.
3. Other incorrect export commands to try: taskhistory x where x is an index out of bounds or not a number but a string.

E.7. List tags

List all tags and their associated tasks.
1. Prerequisites:
  - At least one task should exist in project list
  - Users should have already nagivated to task level
2. Test case: listtag
  Expected: All tags and their associated tasks are displayed at the Result box. Users may need to scroll down to see the full list
3. Test case: listtag x (where x is anything after listtag)
  Expected: X is ignored and all tags and their associated tasks are displayed at the Result box. Users may need to scroll down to see the full list.

E.8. Define tags

Create new group tag
1. Prerequisites: At least one project should exist in project list
2. Test case: definetag gt/Close Milestone t/ReleaseJar t/SubmitReport
  Expected: "Group tag created: Close Milestone" will be displayed at the Result box.
3. Test case: definetag gt/Consultation t/PrepareDemo t/PrepareQuestions
  Expected: "Group tag created: Consultation" will be displayed at the Result box.
4. Test case: definetag gt/Consultation gt/name2 t/PrepareDemo t/PrepareQuestions
  Expected: "Group tag created: name2" will be displayed at the Result box.
5. Test case: definetag gt/duplicatename t/differenttag
  Expected: No group tag will be created and the Result box will display "Group tag Consultation already exists in the group tag list" error.
6. Other incorrect define tag commands to try: definetag

E.9. Add tags

Add group tag to task
1. Prerequisites:
  - At least one task should exist in project list
  - Users should have already nagivated to task level
2. Test case: addtag 1 gt/Consultation
  Expected: Task box will show the updated task with newly added tags from the Consultation group tag.
3. Test case: addtag 1 gt/Consultation gt/ExtraGroup
  Expected: Task box will show the updated task with newly added tags from the ExtraGroup group tag.
4. Test case: addtag 1 gt/NonExistentTag
  Expected: No group tag will be applied to task and the Result box will display "Group tag NonExistentTag not found, please use definetag to add them first." error.
5. Other incorrect add tag commands to try: addtag, addtag x gt/Consultation (where x is not a valid index)

E.10. Completing a task

Adds completed tag to task
1. Prerequisites:
  - At least one task should exist in selected project
  - Users should have already navigated to task level
2. Test case: completed 1
  Expected: Task Box displays the updated task with a newly added completed tag.
3. Test case: completed
  Expected: No completed tag is added to any task in Task Box. Results Box displays error message "The task index provided is invalid".
4. Other incorrect completed commands to try: completed 1 2, completed, completed x (where x is not a valid index)

E.11. Analysing projects

Displays number of completed tasks for each project, and percentage of each project completed
1. Test case: analyse
  Expected: Results Box displays "<Name of project>: x tasks completed. (Percentage of project completed: yy.y%)", with the fields matching the details and statistics for each project.
2. Note that the addition of parameters (e.g. analyse 1, analyse -5 etc.) will automatically be ignored and still result in the correct execution of analyse.

Files

DeveloperGuide.adoc

Latest commit

History

DeveloperGuide.adoc

File metadata and controls

Project Level 4 - Developer Guide

1. Introduction

2. How to use this guide

2.1. Icons Meaning

3. Setting up

3.1. Prerequisites

3.2. Setting up the project in your computer

3.3. Verifying the setup

3.4. Configurations to do before writing code

3.4.1. Configuring the coding style

3.4.2. Updating documentation to match your fork

3.4.3. Setting up CI

3.4.4. Getting started with coding

4. Design

4.1. Architecture

How the architecture components interact with each other

4.2. UI component

4.3. Logic component

4.4. Model component

4.5. Common classes

5. Implementation

5.1. Undo/Redo feature

5.1.1. Current Implementation

5.1.2. Design Considerations

Aspect: How undo & redo executes

Aspect: Data structure to support the undo/redo commands

5.2. Import/Export feature

5.2.1. Current Implementation

5.2.2. Design Considerations

5.3. Compare Task feature

5.3.1. Current Implementation

5.3.2. Design Considerations

5.4. List Feature

5.4.1. Current Implementation

5.4.2. Design Considerations

5.5. List Projects Feature

5.5.1. Current Implementation

5.5.2. Design Considerations

5.6. SortDeadline Feature

5.6.1. Current Implementation

5.6.2. Design Considerations

5.7. List Tag feature

5.7.1. Current Implementation

5.7.2. Design Considerations

5.8. Define Tag feature

5.8.1. Current Implementation

5.8.2. Design Considerations

5.9. Add Tag feature

5.9.1. Current Implementation

5.9.2. Design Considerations

5.10. View Task Command History Feature

5.10.1. Current Implementation

5.10.2. Behaviour when commands are executed

5.10.3. Design Considerations

5.11. Completed/Analyse feature

5.11.1. Current Implementation

5.11.2. Design Considerations

Aspect: Implementation of completed feature

5.12. Logging

5.13. Configuration

6. Documentation

6.1. Editing Documentation

6.2. Publishing Documentation

6.3. Converting Documentation to PDF format

6.4. Site-wide Documentation Settings

6.5. Per-file Documentation Settings

6.6. Site Template

7. Testing

7.1. Running Tests

7.2. Types of tests

7.3. Troubleshooting Testing

8. Dev Ops

8.1. Build Automation

8.2. Continuous Integration

Aspect: Implementation of `completed` feature