Yesterday’s Tomorrow - Developer Guide

By : Team CS2103JAN2017-F11-B3      Since: Jan 2017      Licence: MIT


  1. Setting Up
  2. Design
  3. Implementation
  4. Testing
  5. Dev Ops

1. Setting up

1.1. Prerequisites

  1. JDK 1.8.0_60 or later

    Having any Java 8 version is not enough.
    This app will not work with earlier versions of Java 8.

  2. Eclipse IDE
  3. e(fx)clipse plugin for Eclipse (Do the steps 2 onwards given in this page)
  4. Buildship Gradle Integration plugin from the Eclipse Marketplace
  5. Checkstyle Plug-in plugin from the Eclipse Marketplace

1.2. Importing the project into Eclipse

  1. Fork this repo, and clone the fork to your computer
  2. Open Eclipse (Note: Ensure you have installed the e(fx)clipse and buildship plugins as given in the prerequisites above)
  3. Click File > Import
  4. Click Gradle > Gradle Project > Next > Next
  5. Click Browse, then locate the project’s directory
  6. Click Finish

1.3. Configuring Checkstyle

  1. Click Project -> Properties -> Checkstyle -> Local Check Configurations -> New...
  2. Choose External Configuration File under Type
  3. Enter an arbitrary configuration name e.g. taskmanager
  4. Import checkstyle configuration file found at config/checkstyle/checkstyle.xml
  5. Click OK once, go to the Main tab, use the newly imported check configuration.
  6. Tick and select files from packages, click Change..., and select the resources package
  7. Click OK twice. Rebuild project if prompted

Note to click on the files from packages text after ticking in order to enable the Change... button

1.4. Troubleshooting project setup

Problem: Eclipse reports compile errors after new commits are pulled from Git

Problem: Eclipse reports some required libraries missing

2. Design

2.1. Architecture


Figure 2.1.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.

Tip: 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,

Commons represents a collection of classes used by multiple other components. Two of those classes play important roles at the architecture level.

The rest of the App consists of four components.

Each of the four components

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.1.2 : Class Diagram of the Logic Component

Events-Driven nature of the design

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

<img src=”images\SDforDelete

.png” width=”800”>
Figure 2.1.3a : Component interactions for delete 1 command (part 1)

Note how the Model simply raises a TaskManagerChangedEvent when the Task Manager data are changed, instead of asking the Storage to save the updates to the hard disk.

The diagram below shows how the EventsCenter reacts to that event, which eventually results in the updates being saved to the hard disk and the status bar of the UI being updated to reflect the ‘Last Updated’ time.

Figure 2.1.3b : Component interactions for delete 1 command (part 2)

Note how the event is propagated through the EventsCenter to the Storage and UI without Model having to be coupled to either of them. This is an example of how this Event Driven approach helps us reduce direct coupling between components.

The sections below give more details of each component.

2.2. UI component

Author: LEUNG Cheuk Ting


Figure 2.2.1 : 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,

2.3. Logic component

Author: Hsieh Hsin Han


Figure 2.3.1 : Structure of the Logic Component

API : Logic.java

  1. Logic uses the Parser class to parse the user command.
  2. This results in a Command object which is executed by the LogicManager.
  3. The command execution can affect the Model (e.g. adding a task) and/or raise events.
  4. The result of the command execution is encapsulated as a CommandResult object which is passed back to the Ui.

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

Figure 2.3.1 : Interactions Inside the Logic Component for the delete 1 Command

2.4. Model component

Author: Malik Jabati


Figure 2.4.1 : Structure of the Model Component

API : Model.java

The Model,

2.5. Storage component

Author: Muhammad Ali Rizvi


Figure 2.5.1 : Structure of the Storage Component

API : Storage.java

The Storage component,

2.6. Common classes

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

3. Implementation

3.1. Logging

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

Logging Levels

3.2. Configuration

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

4. Testing

Tests can be found in the ./src/test/java folder.

In Eclipse:

Using Gradle:

We have two types of tests:

  1. GUI Tests - These are System Tests that test the entire App by simulating user actions on the GUI. These are in the guitests package.

  2. Non-GUI Tests - These are tests not involving the GUI. They include,

    1. Unit tests targeting the lowest level methods/classes.
      e.g. seedu.task.commons.UrlUtilTest
    2. Integration tests that are checking the integration of multiple code units (those code units are assumed to be working).
      e.g. seedu.task.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.task.logic.LogicManagerTest

Headless GUI Testing

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.
See UsingGradle.md to learn how to run tests in headless mode.

4.1. Troubleshooting tests

Problem: Tests fail because NullPointException when AssertionError is expected

5. Dev Ops

5.1. Build Automation

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

5.2. Continuous Integration

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

5.3. Publishing Documentation

See UsingGithubPages.md to learn how to use GitHub Pages to publish documentation to the project site.

5.4. Making a Release

Here are the steps to create a new release.

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

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

  1. Make sure you have set up GitHub Pages as described in UsingGithubPages.md.
  2. Using Chrome, go to the GitHub Pages version of the documentation file.
    e.g. For UserGuide.md, the URL will be https://<your-username-or-organization-name>.github.io/main/docs/UserGuide.html.
  3. Click on the Print option in Chrome’s menu.
  4. 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 5.4.1 : Saving documentation as PDF files in Chrome

5.6. Managing Dependencies

A project often depends on third-party libraries. For example, Task Manager depends on the Jackson library for XML parsing. Managing these dependencies can be automated using Gradle. For example, Gradle can download the dependencies automatically, which is better than these alternatives.
a. Include those libraries in the repo (this bloats the repo size)
b. Require developers to download those libraries manually (this creates extra work for developers)

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…
* * * new user see usage instructions refer to instructions when I forget how to use the App
* * * user add a new task keep track of tasks I need to complete
* * * user delete a task remove tasks that are no longer relevant
* * * user find a task by name locate details of task without having to go through the entire list
* * * user edit a parameter of a task update a task without needing to delete and re-add it
* * * user mark tasks as complete see what I’ve already completed (and still have left to do)
* * * user undo my last action easily fix typos and mistakes I make
* * * user specify a duration of the task plan when I will complete the task
* * * user list completed tasks see a list of all completed tasks
* * * user list incomplete tasks see a list of all incomplete tasks
* * * user specify a duration of the task plan when I will complete the task
* * user list tasks in order of due date prioritize what to do next
* * user mark tasks as important prioritize what to do next
* * user have a calendar view of all tasks see how busy I am
* * user have my emails converted to tasks or events automatically save time on manually entering tasks and events
* * user add custom tags to tasks organize my tasks by category
* * user be able to migrate my data to another computer change computers without losing my tasks
* * user get a reminder about a task don’t miss a task due date
* user print out all tasks keep a paper copy when there is no computer access
* user have an automatically prioritized list have more time to do the items instead of planning
* user have an customizable GUI feel good looking at my tasks and be motivated
* user attach files to tasks keep track of supplimentary information for the task
* user email updates on tasks to people alert individuals when a task is done
* user see percentage of time I spend doing certain types of tasks have a better understanding of how my time is allocated
* user easily share tasks with other people collaborate on a project with them
* new user import task data from other TODO products easily migrate to Yesterday’s Tomorrow
* user add subtasks to tasks break down larger tasks
* user have a history of task edits keep track of when tasks change (or when I make mistakes)
** user edit tag labels update tag labels (or when I make mistakes)
** user create folders for my tasks organize related tasks together
* user save my tasks on the cloud have a backup of my data or view my tasks accross different devices
* user print out all tasks for a specific tag view all tasks of a specific tag
* user add subtasks to my tasks break down major tasks into smaller steps
* user add hyperlinks to my task descriptions click to useful links without having to copy and paste into my browser

{More to be added}

Appendix B : Use Cases

(For all use cases below, the System is Yesterday's Tomorrow and the Actor is the user, unless specified otherwise)

Use case: Delete task

MSS

  1. User requests to list all tasks
  2. Yesterday’s Tomorrow shows a list of tasks
  3. User requests to delete a specific task in the list
  4. Yesterday’s Tomorrow deletes the task
    Use case ends.

Extensions

2a. The list is empty

Use case ends

3a. The given index is invalid

3a1. Yesterday’s Tomorrow shows an error message
Use case resumes at step 2

Use case: Edit task

MSS

  1. User requests a list of all tasks
  2. Yesterday’s Tomorrow shows a list of all tasks
  3. User requests changes to a certain parameter of a specific task
  4. Yesterday’s Tomorrow changes the requested parameter of the task and displays the updated item to the user Use case ends.

Extensions

3a. The given index is invalid

3a1. Yesterday’s Tomorrow shows an error message
Use case resumes at step 2

Use case: Add task or event

MSS

  1. User enters the task with optional parameters such as due date, start and end time
  2. Yesterday’s Tomorrow parses task and stores it to memory, then displays the task with formatted parameters back to user Use case ends.

Extensions

2a. Parameters are entered in the wrong format

2a1. Yesterday’s Tomorrow shows an error message and an example of correct formatting Use case resumes at step 1

Use case: Undo last action

MSS

  1. User enters undo command
  2. Yesterday’s Tomorrow display command to be undone, and undoes the command Use case ends.

Extensions

2a. There is no previous action

Use case ends.

Use case: Search tasks

MSS

  1. User enters the search command with given parameters to search for
  2. Yesterday’s Tomorrow interprets the search command and displays a list of matching tasks Use case ends.

Extensions

2a. No search terms are given

2a1. Yesterday’s Tomorrow shows an error message indicating the user’s error Use case resumes at step 1

{More to be added}

Appendix C : Non Functional Requirements

  1. Should work on any mainstream OS as long as it has Java 1.8.0_60 or higher installed.
  2. Should be able to hold up to 1000 tasks without a noticeable sluggishness in performance for typical usage.
  3. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.
  4. All classes and public methods should have documentation.
  5. All commands should be completed within 200ms.
  6. 80% test coverage.

Appendix D : Glossary

Mainstream OS

Windows, Linux, Unix, OS-X

Usage Instructions

list of commands with instructions on how to use them appropriately

System Admin Commands

shell commands used to perform system level tasks

Appendix E : Product Survey

Product Name

Author: 6 Wunderkinder GmbH

Pros:

Cons:

Trello

Author: Fog Creek Software

Pros:

Cons:

Reminder

Author: Apple Inc

Pros:

Cons:

To Do Reminder

Author: App Innovation

Pros:

Cons:

Just Reminder

Author: AppHouze Co.

Pros:

Cons:

Remind Me - Task Reminder App

Author: Lucidify Labs

Pros:

Cons: