Back to OrgaNice!’s main page

Developer Guide

Table of content

  1. Introduction
    1.1. Purpose
    1.2. Target Reader
    1.3. Brief Description
    1.4. Main Features
  2. Design
    2.1. Architecture
    2.2. Task Component
    2.3. Study Area Component
    2.4. Notes Component
  3. Implementation
    3.1. Scheduling Tasks
    3.2. Listing Study Areas
    3.3. Operation of Notes
  4. Testing

Appendix A: Product Scope
Appendix B: User Stories
Appendix C: Non-Functional Requirements
Appendix D: Glossary
Appendix E: Instruction for Manual Testing

1. Introduction

1.1. Purpose

The document is meant to guide you on how OrgaNice! was developed and the design and implementations behind the software. With this document, you should have a better understanding of the framework of the application.

1.2. Target Reader

The target reader of this developer guide are:

1.3. Brief Description

OrgaNice! is a task manager integrated with a Study Area search function. You can use it to manage your tasks, be it events or deadlines. On top of that, it is capable of assisting students in finding Study Areas that meet their desired criteria.

1.4. Main Features

  1. Scheduling Tasks
    • You can manage tasks based on priority for events and countdown for deadlines. For more information on the design and implementation for this feature, click here
  2. Study Area.
    • You can find a Study Area that meets your criteria. The software, however, have a limited number of supported criteria. For more information on the design and implementation for this feature, click here
  3. Notes
    • You can enter notes based on school modules. Notes support undo and redo operations. For more information on the design and implementation for this feature, click here

2. Design

2.1. Architecture

Architecture

Figure 1. Overall Architecture of OrgaNice!


  1. Duke - The Main component which controls the flow of execution.

  2. Ui - Component used to get input from the user and display results on the monitor.

  3. Parser - Component used to abstract out the command based on the user’s input, so that the command can be executed later.

  4. Command - Component contains information and implementation on how to execute various types of commands.

  5. Task - Component contains details about handling the task list and related operations.

  6. StudyArea - Component contains details about handling queries for study area search.

  7. Notes - Component contains details about Notes related operations.

  8. Exception - Component contains the various types of exceptions encountered when OrgaNice! is run.

  9. ResourceLoader - Component handles loading and saving of the task list and study area details to local storage.

2.2. Task Component

The Task component depends on 3 other components,

  1. Command Component - The Command component issues instructions for the Task component to execute based on the user’s input.

  2. UI Component - The UI component is used to display the results (and related exceptions) of the commands issued to the Task Component.

  3. ResourceLoader Component - The ResourceLoader component is used to load the list of tasks stored previously when the application is started and is also used to store the current list of tasks to the local storage upon exit.

Task Component

Figure 2. Class Diagram for Task Component


The task component contains 8 separate classes. They are as follows:

  1. Task: Abstract class used to model a generic task.

  2. Event: Specialized task class used to model events.

  3. Deadline: Specialized task class used to model a deadline.

  4. TaskType: Enumeration class used to denote the various task types.

  5. TaskList: Container class used to store the list of tasks and handle related operations.

  6. SchedulableTask: Class used to model a task that is scheduled based on user’s requirements.

  7. TaskComparator: Contains a custom comparator used to compare two schedulable tasks based on their numberOfDaysLeft attribute.

  8. TaskScheduler: Class used to check for feasibility and schedule a list of tasks based on the user’s requirements.

2.3. Study Area Component

The Study Area component depends on 3 other components,

  1. Command Component - The Command component issues instructions for the Study Area component to execute based on the user’s input.

  2. UI Component - The UI component is used to display the results (and related exceptions) of the commands issued to the Study Area Component.

  3. ResourceLoader Component - The ResourceLoader component is used to load data of all existing Study Areas in NUS into text files when the User first run the software. Eventually, data will be referred from the created text file.

Study Area Component

Figure 3. Class diagram for Study Area Component


The Study Area component contains 3 separate classes. They are as follows:

  1. Dictionary: Class to map user input to specific terms used in StudyAreaList.

  2. StudyArea: Class that is used to model Study Areas.

  3. StudyAreaList: Class that handles the list of available Study Areas based on User input.

Details on the methods are listed in the glossary

2.4. Notes Component

Notes Component

Figure 4. Class diagram for Notes Component


The Notes component is self-contained apart from calling UI class for Strings output.
Inside Notes component, there exist these classes:

  1. NotesInvoker: Class to start the Notes

  2. Notes: Class to support operations for the modules in the Notes, acts as an interface.

  3. ModuleList: Class to implement actual modules operations and store modules list.

  4. Command: Package containing Command interface, Add command, Command Stack classes.

  5. Parser: Class to parse commands for command-based operations.

3. Implementation

3.1. Scheduling Tasks

3.1.1 Implementation

In order to schedule tasks based on the user’s requirement a separate SchedulableTask class was created.

  1. The user’s requirements (Name, Time to complete it, Deadline) are captured for each of the tasks to be scheduled.
  2. The requirements captured are stored in the SchedulableTask object.
  3. Then, the TaskScheduler object finds the optimum schedule based on the user’s requirements using the EDF (Early Deadline First) algorithm.
  4. If a feasible schedule is found it is displayed, else a message stating that a schedule based on the user’s requirements can’t be made is displayed.

The following sequence diagrams explain how tasks are scheduled.

Overall Sequence Diagram

Figure 5. Overall Sequence Diagram


The three reference frames used are as follows:

Sub Diagram 1

Figure 6. Sub Diagram 1


Sub Diagram 2

Figure 7. Sub Diagram 2


Sub Diagram 3

Figure 8. Sub Diagram 3


3.1.2 Alternatives

Aspect: How to capture the user’s requirements and handle them.

3.1.3 Future Enhancements

The current version of the application doesn’t take into account the other tasks present, however, the priority values can still be used to decide the more important task.
In v3.0 our application will support

  1. scheduling tasks while avoiding tasks present previously
  2. add support for tasks to be scheduled preemptively (i.e, tasks can be scheduled over non-contiguous days)
  3. Change the default priority value assigned to scheduled tasks

3.2. Listing Study Areas

3.2.1 Implementation

The Study Area search is facilitated by StudyAreaList. In this class, it has the list of all existing Study Areas, stored internally as an ArrayList. This ArrayList is called studyAreaList.

To list the Study Area, we iterate through the entire list of all existing Study Area and conduct a check. The check is as follows :

If in each Study Area, the Study Area meets all the flags stated by the User, the Study Area is then added to the list of available Study Area. If not, the iteration is skipped and move on to the subsequent Study Area.

To do as mentioned above, the StudyAreaList class implements the following main methods :

Below would be a sequence diagram to demonstrate how the search algorithm is operated.

Study Area Sequence_Diagram_Main

Figure 9. Interaction between User and Study Area Search Interface


Study_Area_Sequence_Diagram_subModules

Figure 10. Interaction within Study Area Search Interface


Study_Area_Sequence_Diagram_subModules2

Figure 11. Interaction when isAvailStudyArea is invoked


You can refer here for a detailed explanation on the terms used in this diagram

3.2.2 Alternative

Aspect: How to search based on User input.

There exist four flags: port availability, indoor, outdoor, capacity. Create adjacency lists that map the flag to the Study Area itself. If the Study Area contains that attribute, the Study Area is added in that specific attribute list. Depending on the type of attribute, the adjacency list can be implemented using different data structures.

For example, let’s take only the two study areas below as the entire data set.

study_area_det

Figure 12. Sample Data


This will result in the following adjacency lists :

Environment:

Indoor -> {Starbucks}
Outdoor -> {Opposite Town Green (Outside Starbucks)}

Data Structure : 2D Array, with only two rows (For indoors and outdoors)

Ports:

Yes -> {Opposite Town Green (Outside Starbucks), Starbucks}
No -> null

Data Structure: 2D Array, with only two rows (For Yes and No)

Capacity:

4 -> {Opposite Town Green (Outside Starbucks)}
5 -> {Starbucks}

Data Structure: HashMap<Integer, ArrayList>

The creation and initialisation of the lists are done when the software is setting up. Therefore, each flag has its designated list. Based on user criteria, concatenate an output list with the Study Areas that are found in all of the relevant flag lists stated by the user. If more than one requirement is entered by the user, only the Study Areas appears in all the related attributes specified by the User will be added to the output list.

Therefore, the first alternative is chosen, as it is much easier to implement and lesser memory is used while searching

3.3. Operation of Notes

3.3.1 Implementation

The NotesInvoker class will create a Notes object. Notes acts as an Interface for the ModulesList class. Each module is mapped to an ArrayList of notes. This map is stored in the ModuleList class. The ModuleList class contains operations to add, remove, enter and list modules.

A ModuleManager class is used to hold operations for a module. These operations are achieved by working together with the Parser class and Command class. Operations supported are: add, list, undo, redo.

Add operations are fairly simple, primarily using the add method of the HashMap library. The implementation of undo and redo is stated here below.

Each time an AddCommand object is called, CommandStack will determine if the operation is add, undo or redo.

If the operation is to add notes, the notes will be added to the value in the module key. At the same time, this note that is added is also added to a CommandStack list in the CommandStack class. The redoStack list in the CommandStack class is then cleared.

If the operation is to undo added notes, the CommandStack will remove the last added note from the CommandStack and pass it to the Command class to execute the undo action by removing it from the module contained in the HashMap. Also, this note will be added to the redoStack list.

If the operation is to redo removed notes, the CommandStack will remove the last added note in redoStack list and pass it to the Command class to execute the redo action by adding this note into the module contained in the HashMap.

The reason why we chose two linked lists to support these operations is that it reduces the SLOC needed to write the logic. An alternative is to actually remember the state of the HashMap before an operation and save it to another HashMap. However, this approach will take up more memory and reduces the performance of the application.

4. Testing

Currently, we have two runners to execute the tests, JUnit and Gradle.
Note: It is advisable to run tests with coverage, to ensure that 90% of the paths are covered.

Using IntelliJ JUnit

Firstly check if the configuration, “All in ‘tp.test’” exist. You need to edit a configuration if there isn’t any to run all tests.

To edit a configuration, click Run then click on Edit Configurations. Proceed to click the + icon, followed by JUnit

Afterward, ensure that the configurations are as such:

Junit_config

Figure 13. Configuring JUnit Tests


To run all tests, right-click on the src/test/java folder and choose Run ‘All in ‘tp.tests’’ with coverage This allows for you to see which path has the test covered so that you can ensure at least 90% of the paths are covered when testing.

Alternatively, you can click on this icon to run with coverage :

JUnit_test

Figure 14. Running JUnit Tests


To run a subset of tests, you can right-click on a test package, test class, or a test and choose Run with coverage.

Using Gradle

Firstly ensure that the Gradle build has the following details:

Gradle_build

Figure 15. Expected Gradle Build


Next, to run using Gradle, you can click on the Gradle plugin icon at the left-hand side

Then click on the elephant icon (as seen below) and search for Gradle test then proceed to click on it.

elephant_icon

Figure 16. Gradle Icon


Now the configuration is set to Gradle. Proceed to click the icon:

Gradle_run_test

Figure 17. Running Gradle Test


Appendix A: Product Scope

Target User Profile

Mainly NUS students and professors who :

Value proposition

You can efficiently manage tasks, in terms of priority. You can also efficiently find a study area that meets your needs and is conducive, should you urgently need one.

Appendix B: User Stories

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

Priority Version As a … I want to … So that I can …
* * * v1.0 new user see list of commands supported refer to them when I forget how to use the application
* * * v1.0 user add a new task keep track of it
* * v1.0 user edit a task change it’s details if required
* * * v1.0 user delete a task remove tasks that are cancelled
* * v1.0 user view my list of tasks sorted based on their date be aware of all the tasks that are due/happening soon
* * v1.0 user view my list of tasks sorted based on their priority be aware of the more important tasks
* * v1.0 user find a task by name locate a task without having to go through the entire list
* * * v1.0 student find a Study Area based on location and environment have a conducive space to study
* * * v1.0 professor locate a Study Area that is outdoors conduct consultations without worrying of making noise
* * v2.0 user mark deadline as done check to see if I have pending deadlines
* * * v2.0 user to delete a Module clean up my finished notes
* * * v2.0 user create a Module add notes inside
* * v2.0 user undo an added note increase my efficiency
* * v2.0 user redo a removed notes increase my efficiency
* * * v2.0 user create a schedule based on requirements customise my tasks accordingly
* * * v2.1 user look at the list of tasks in calendar view see the list of tasks in one glance with relation to its schedule
* * * v3.0 user check the availability of a study area use it at that specific timing
* * * v3.0 user schedule tasks while avoiding present task prevent clashes between tasks
* * * v3.0 user schedule tasks preemptively stagger the timeline of the tasks depending on the availability of free time in my schedule
* * * v3.0 user edit priority value assigned to scheduled tasks have more flexibility with the priority values used in my list

Appendix C: Non-Functional Requirements

Appendix D: Glossary

Appendix E: Instructions for Manual Testing

NOTE: These tests are not exhaustive and testers have to do more exploratory testing to ensure the accuracy of the software’s features.

Initial launch

Adding a deadline task

Adding an event task

Scheduling tasks

Marking a deadline task as done

Editing a task

Searching for tasks

Deleting a task

Prerequisites: Enter Study Area Search Interface by entering study.

Search by location, name, address

Search by flags only

Search with both, (1) location,name or address, and , (2) flags

Testing for Calendar

Prerequisites: Enter Calendar View by entering calendar.

Testing for Notes

Module Interface

Prerequisites: Enter Notes taking feature by entering notes.

Inside a Module