Task Book - Developer Guide

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,

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

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:

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).

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

When you are ready to start coding,

The select mechanism is facilitated by VersionedTaskBook.

These operations are exposed in the Model interface as Model#selectDeadline(), Model#updateFilteredTaskList() and Model#commitTaskBook() respectively.

Given below is an example usage scenario and how the select mechanism behaves are each step.

Step 1. The user launches the application. If it is the first time he/she is launching it, the VersionedTaskBook will be initialized with a sample task book data. If the user has already launched it previously and made changes to it, the VersionedTaskBook launched will contain the data that he/she has entered in the previous launch.

Step 2. The user executes select 1/1/2018 or select dd/1 mm/1 yyyy/2018 to select the deadline.

Step 3. The select command will call Model#selectDeadline() and select the deadline as 1/1/2018. Model#updateFilteredTaskList() will be called within Model#selectDeadline() to update the list that is being shown to the user with only show tasks with 1/1/2018 as the deadline.

Step 4. Lastly, Model#commitTaskBook() will be called to update the TaskBookStateList and currentStatePointer.

The following sequence diagram illustrates how the select command is implemented.

The edit mechanism is facilitated by VersionedTaskBook.

Additionally, it implements the following operations:

These operations are exposed in the Model interface as Model#updateTask(), Model#updateFilteredTaskList() and Model#commitTaskBook() respectively. Given below is an example usage scenario and how the edit mechanism behaves at each step.

Step 1. The user launches the application. If it is the first time he/she is launching it, the VersionedTaskBook will be initialized with a sample task book data. If the user has already launched it previously and made changes to it, the VersionedTaskBook launched will contain the data that he/she has entered in the previous launch.

Step 2. The user executes edit i/1 t/Complete CS2113 tutorial to edit the title of the existing task at index 1 in the list. The edit command obtains the data of the task that the user wants to change based on the input index.

Step 3. The edit command will retrieve and copy the details of the task at index 1 to a new task editedTask and edit the title to Complete CS2113 tutorial.

Step 4. The edit command will call Model#updateTask() and update the task at index 1 with the details of editedTask. Also, Model#updateFilteredTaskList() will be called to update the list that is being shown to the user with the updated task.

Step 5. Lastly, Model#commitTaskBook() will be called to update the TaskBookStateList and currentStatePointer.

The following sequence diagram illustrates how the edit command is implemented.

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

These operations are exposed in the Model interface as Model#commitTaskBook(), Model#undoTaskBook() and Model#redoTaskBook() 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 VersionedTaskBook will be initialized with the initial task book state, and the currentStatePointer pointing to that single task book state.

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

Step 3. The user executes add t/Do math homework …​ to add a new task. The add command also calls Model#commitTaskBook(), causing another modified task book state to be saved into the taskBookStateList.

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#undoAddressBook(), which will shift the currentStatePointer once to the left, pointing it to the previous task book state, and restores the task book to that state.

The following sequence diagram shows how the undo operation works:

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

Step 5. The user then decides to execute the command list. Commands that do not modify the task book, such as list, will usually not call Model#commitTaskBook(), Model#undoAddressBook() or Model#redoAddressBook(). Thus, the taskBookStateList remains unchanged.

Step 6. The user executes clear, which calls Model#commitTaskBook(). Since the currentStatePointer is not pointing at the end of the taskBookStateList, all task book states after the currentStatePointer will be purged. We designed it this way because it no longer makes sense to redo the add n/Do math homework …​ 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:

Whenever a Task object is created, it will be instantiated with an empty List of Milestone objects.

When the user calls the add_milestone command, he/she will enter an index to select an existing Task and the desired arguments with the appropriate prefixes. (e.g i/ INDEX m/ MILESTONE DESCRIPTION r/ RANK)

The index represents the Task in the list from PersonListPanel displayed in the GUI.

The following sequence diagram illustrates how the add_milestone command is implemented.

The defer deadline mechanism is facilitated by VersionedTaskBook. The defer deadline command takes in the index prefix with index of the task to be deferred, followed by the deadline prefix with its corresponding number of days which will defer the deadline in the task by the number of days.

The index represents the Task in the list from PersonListPanel displayed in the GUI.

The validity of the input by the user is checked through the DeferDeadlineCommandParser and TaskBookParser. A DeferDeadlineCommand object is returned and the execute() method will be performed. The validity of the index will be checked and the task to be deferred is retrieve using the getFilterTaskList() method. A copy of the task will be instantiated as deferredTask. The deadline of deferredTask will be deferred by the number of days inputted by the user. The validity of the deadline and existence of duplicate tasks will be checked. Task to be deferred will be updated with deferredTask through updateTask() and updateFiteredTaskList() method in the Model Component.

Step 1. The user launches the application. If it is the first time he/she is launching it, the VersionedTaskBook will be initialized with a sample task book data. If the user has already launched it previously and made changes to it, the VersionedTaskBook launched will contain the data that he/she has entered in the previous launch.

Step 2. The user executes defer i/1 dd/1 to defer the deadline of the selected task at index 1 in the list. The defer command obtains the data of the task that the user wants to change based on the input index.

Step 3. The defer command will retrieve and copy the details of the task at index 1 and instantiate a new task deferredTask and defer the deadline by 1 day.

Step 4. The defer command will call Model#updateTask() and update the task at index 1 with the details of deferredTask. Also, Model#updateFilteredTaskList() will be called to update the list that is being shown to the user with the updated task.

Step 5. Lastly, Model#commitTaskBook() will be called causing the modified state of the task book after the defer i/1 dd/1 command executes to be saved in the TaskBookStateList, and the currentStatePointer to be updated.

The following sequence diagram illustrates how the defer command is implemented.

To ensure encryption keys are both sufficiently random and hard to brute force, we will use standard password-based encryption (PBE) key derivation methods.

When the student uses Task Book for the first time, he or she will be requested to enter a new password. Since password recovery methods may not be implemented, this password must be easy to remember by the student. Along with the password text provided by the student, a salt is appended to produce a hash (Figure below).

An AES or DES encryption key is thus derived from this process. To unlock the Task Book, the same salt is appended to the password provided to generate the decryption key.

In the Sequence Diagram, these are the interactions within the Logic component for the execute("lock") API call (Figure below):

There are a few ways to implement the password encryption for our product.
However, each method has its strengths and weaknesses. We will be explaining why we chose this particular implementation design.