PROJECT: Plan²travel

Overview

Plan²travel is a desktop travel planning application. The application is targeted at fellow university students who travel infrequently and would greatly benefit from an application that helps organize their travelling information when they plan their own itinerary. Plan²travel has the ability to store and display information such as activities, accommodations, contacts and an itinerary which comprises of a list of day. Each day is displayed with a list of activities that is scheduled.

The user interacts with the application using a Command Line Interface (CLI), and it has Graphical User Interface GUI created with JavaFX.

It is cross-platform and can be compiled for both Windows and Mac OS.

Below is a screenshot of our application:

Plan2TravelSS

Summary of contributions

This section is a summary of the contributions I have made to the team project.

Major enhancement:

  • Added the ability to manage Accommodations and Activities in the itinerary

    • What it does: allows the user to compile information important to planning an itinerary.

    • Justification: This feature improves the product significantly because it allows the user to enter data in a standardised format, making itineraries more readable and manageable.

    • Highlights: This enhancement affects existing commands and commands to be added in future. It required an in-depth analysis of design alternatives. The implementation too was challenging as it required changes to existing commands.

    • Credits: The commands were adapted and built upon commands from Address Book 3

Minor enhancement:

  • Added the ability to optimise a day’s schedule

    • What it does: allows the user to optimise a day’s schedule by looking for the best way to schedule activities such that there are no conflicts and that the schedule is at the lowest cost. If there are multiple possibilities, the one with the most number of activities would be chosen.

    • Justification: This feature improves the product because it allows users to rid the schedule of conflicts with a single command.

    • Highlights: This enhancement can be extended to allow the user to optimise the schedule besides cost and number of activities.

  • Link different model components to update one another

    • What it does: allows the user to update the contact in an Activity/Accommodation from the contact list, vice versa.

    • Justification: This feature improves the product as it incorporates different models into the product and polishes the product.

    • Highlights: This enhancement makes the product a more cohesive ecosystem.

Other contributions:

  • Enhancements to existing features:

    • Wrote additional tests for existing features to increase coverage #221, #268

  • Documentation:

    • Did tweaks to existing contents of the User Guide: #248

  • PRs reviewed: Reviews

Contributions to the User Guide

Given below are sections I contributed to the User Guide. They showcase my ability to write documentation targeting end-users.

Adding an accommodation: add accommodation

Creates an accommodation and adds it to the accommodation list
Format: add accommodation n/NAME a/ADDRESS [p/PHONE_NUMBER] [t/TAGS]

  • Name must only contain alphanumeric characters and spaces (names with only white space would be treated as blank).

  • Address can take up any values (likewise, addresses with only white space would be treated as blank).

Examples:

  • add accommodation n/Hotel 81 a/Orchard p/67555312

Adds "Hotel 81" with an address, "Orchard", and phone number, "67555312", into the accommodation list.

  • add accommodation n/Mandarin Oriental a/Ang Mo Kio

Adds "Mandarin Oriental" with an address, "Ang Mo Kio" into the accommodation list.

Editing an accommodation: edit accommodation

Edits an accommodation
Format: edit accommodation INDEX [n/NAME] [a/ADDRESS] [p/PHONE_NUMBER] [t/TAGS]

  • Edits the accommodation with the specified INDEX.

    • The index provided refers to the index number shown in the displayed accommodation list.

    • The index provided must be a positive integer.

    • The index provided must not exceed the number of accommodations in the accommodation list.

  • At least one of the optional fields must be provided.

  • Existing fields will be updated by the input fields.

Examples:

  • edit accommodation 1 n/MBS a/Marina Bay t/Atas

Edits the 1st accommodation in the accommodation list to have a name, "MBS", address, "Marina Bay", and tag, "Atas".

Deleting an accommodation: delete accommodation

Delete one or more accommodation from the accommodation list
Format: delete accommodation INDEX…​

  • Deletes the accommodation at the specified INDEX.

    • The index provided refers to the index number shown in the displayed accommodation list.

    • The index provided must be a positive integer.

    • The index provided must not exceed the number of accommodations in the accommodation list.

Examples:

  • delete accommodation 2

Deletes the 2nd accommodation in the accommodation list.

Adding an activity: add activity

Creates an activity and adds it to the activity list
Format: add activity n/NAME a/ADDRESS du/DURATION [p/PHONE_NUMBER] [c/COST] [pr/PRIORITY] [t/TAGS]

  • Name must only contain alphanumeric characters and spaces (names with only white space would be treated as blank).

  • Address can take up any values (likewise, addresses with only white space would be treated as blank).

  • Duration is in minutes and must be less than or equal to 1440 minutes.

  • Phone number should only contain numbers and must be at least 3 digits long.

  • Cost should only contain numbers and have at most 2 decimal places. (Maximum cost is 10^25)

  • Priority should only contain numbers and range from 1 to 7 inclusive. (1 being the highest priority, 7 being the lowest).

Examples:

  • add activity n/Visit Gundam Museum a/Tokyo du/90 p/67521312

Adds "Visit Gundam Museum" with an address, "Tokyo", duration, 90 minutes, and phone number, "67521312", to the activity list.

  • add activity n/Ski a/Mount Sinai du/120

Adds "Ski" with an address, "Mount Sinai", and duration, 120 minutes, to the activity list.

Editing an activity: edit activity

Edits an activity
Format: edit activity INDEX [n/NAME] [a/ADDRESS] [p/PHONE_NUMBER] [c/COST] [pr/PRIORITY] [t/TAGS]

  • Edits the activity with the specified INDEX.

    • The index provided refers to the index number shown in the displayed activity list.

    • The index provided must be a positive integer.

    • The index provided must not exceed the number of activities in the activity list.

  • At least one of the optional fields must be provided.

  • Existing fields will be updated by the input fields.

Examples:

  • edit activity 1 n/Dinner a/Hotel t/Western

Edits the 1st activity in the activity list to have a name, "Dinner", address, "Hotel", and tag, "Western".

Deleting an activity: delete activity

Delete one or more activities from the activity list
Format: delete activity INDEX…​

  • Deletes the activity at the specified INDEX.

    • The index provided refers to the index number shown in the displayed activity list.

    • The index provided must be a positive integer.

    • The index provided must not exceed the number of activities in the activity list.

Examples:

  • delete activity 2

Deletes the 2nd activity in the activity list.

Optimising by budget: optimise

Optimises a day’s schedule by finding all possible combinations of activities. The resulting combination would have the lowest total cost. If there are multiple combinations with the same cost, the combination with the most activities would be chosen.

Format: optimise DAY_INDEX

  • Optimises the day at the specified DAY_INDEX.

    • The index provided refers to the index of a day in the itinerary.

    • The index provided must be positive integer.

    • The index provided must not exceed the number of days in the itinerary.

Examples:

BeforeOptimise
Figure 1. Day 2 has Overlapping Activities

  • optimise 2

AfterOptimise
Figure 2. Day 2 has been optimised.
The day to be optimised must not be empty.

Contributions to the Developer Guide

Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project.

Logic component

LogicClassDiagram
Figure 3. Structure of the Logic Component

API : Logic.java

  1. Logic uses the PlannerParser 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 contact).

  4. The result of the command execution is encapsulated as a CommandResult object which is passed back to the Ui.

  5. 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("add activity n/Climb Fuji a/Mount Fuji") API call.

AddSequenceDiagram
Figure 4. Interactions Inside the Logic Component for the add activity n/Climb Fuji a/Mount Fuji Command
The lifeline for AddCommandParser should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

Schedule optimisation

Implementation

Scheduled activities in a day can be modeled as a Directed Acyclic Graph (DAG) where the vertices are the activities and an edge from 1 vertex to another means that the activities are not overlapping. Just like DAGs, there are no cycles within the schedule due to the linearity of time. When the command is executed, an adjacency list is formed from the existing activities within the schedule. The paths are then traced, with the help of a utility method, from the adjacency list to find all possible combinations of activities such that there are no overlaps between activities. The list of paths are then sorted by their total cost. If there are multiple paths with the same total cost, the one with the most number of activities is selected. The existing day is then replaced with a day that contains the new schedule made from the path.

  • optimise INDEX_OF_DAY — optimises and de-conflicts the schedule. This operation supports activities with or without a cost. Activities without a cost have a default cost of $0.00.

Given below is a sample usage of the feature:

The user calls optimise command on an existing day with overlapping activities within its schedule. This results in a schedule without overlaps such that the lowest overall cost and the most number of activities if there are multiple combinations with the same total cost, such that the user’s time is maximised.

Shown below is a summary of the execution of the command.

OptimiseSequenceDiagram

Design considerations

Aspect: Algorithm to de-conflict

  • Alternative 1 (current): Find all combinations, if the total cost is the same, combination with more activities is selected.

    • Pros:

      • Allow users to maximise time by squeezing more activities into the schedule.

      • Allow optimisation to cover more criteria such as cost, number of activities, etc.

    • Cons:

      • Costly runtime.

  • Alternative 2: Use Single Shortest Path (SSSP) algorithms to find a combination without conflicts.

    • Pros:

      • Fast runtime.

    • Cons:

      • Use of SSSP algorithms like Djikstra or Bellman Ford restricts the criteria of optimisation due to the limits of edge weight (i.e. cost).

Aspect: De-conflict process

  • Alternative 1 (current): Model as a DAG and find combination with the lowest overall cost.

    • Pros:

      • Easy for users to use, less hassle for indecisive users.

    • Cons:

      • Less control for the user to choose activity.

  • Alternative 2: Allow users to manually de-conflict by selecting individual activities they wish to keep.

    • Pros:

      • Users have more control over activities.

    • Cons:

      • Users have to enter multiple inputs to de-conflict.

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…​

* * *

traveller

refer to a list of attractions

I can decide on what activities to do for the day

* * *

traveller

add activities that I want to do

I can plan my trip

* * *

traveller

save my contact list

I can review/access them again

* * *

traveller

access a list of accommodations

I can better plan for where to stay at

* * *

organised traveller

plan my daily planner

I can make better use of my travel time

* * *

lightweight traveller

save the planner to my phone

I can pack light

* * *

infrequent traveller

add contacts

I can get in touch with the hotel concierge

* * *

new user

view a help guide

I can familiarise myself with the application

* *

traveller

categorise activities by interest

I can prioritise certain activities

* *

solo traveller

keep a list of emergency contacts

I know who to contact in times of emergency

* *

eager traveller

follow an accommodation checklist

I will not miss out on anything

* *

indecisive traveller

plan for multiple trips

I can decide on a later date

* *

messy planner

quickly organise my travel research

I can streamline my planning processes

* *

fast typist

be auto-corrected for my typos

I won’t break my train of thought while planning

* *

advanced user

use command shortcuts

I can improve my planning efficiency

* *

advanced user

set where to save my itineraries

I can organise my itineraries

* *

careless user

undo my mistakes

I don’t have to retype if I make one

*

traveller

rate activities that I have done

I can make a better recommendation to my friends

*

traveller on a tight budget

estimate my budget for a trip

I can minimise my spendings

*

traveller

organise and record my travel experiences

I can share them online

*

inexperienced planner

receive planning recommendations

I can improve my planner