PROJECT: Easy Travel

This portfolio aims to document the contributions that I have made to the E.T. project. The Github Link to E.T. can be found here : https://github.com/AY1920S2-CS2103T-W17-3/main

Overview

E.T. is a desktop travel planning application to provide a simple an easy way for users to prepare for their trip. The user interacts with it using a CLI, and it has a GUI created with JavaFX. It is written in Java, and has about 10 kLoC.

Summary of contributions

This section shows a summary of my coding, documentation, and other helpful contributions to the team project. It takes care of the name, quantity and categories of all the packing list items.

  • Major enhancement: Implemented Packing List Tab along with its User Interface and commands (CRUD/Sort)

    • What it does: The packing list feature allows the user to keep track of their packing list, to see which items they have and haven’t packed for their trip.

    • Justification: When planning for a trip, it is important to have a packing list to keep track of what is packed and what needs to be packed, so that the traveller will not forget to bring anything they wanted to bring. This gives the traveller a peace of mind, convenience and preventing disasters, such as forgetting to bring one’s passport or wallet.

    • Highlights: This enhancement works well with the status feature (mentioned below) as it helps users keep track of their packing list. Careful considerations have to be made so that this feature can be expanded upon by future developers, including myself. The implementation of this feature was challenging because certain restrictions must be enforced to ensure that the users' packing list is appropriate.

    • Credits: Credits to the app called Packr for the packing list preset idea.
      {Authors or Address Book 3 and Jeffry Lum for his guidance, time and support. }

  • Major enhancement: I contributed to the most important feature of our product, the status feature. I added in the progress of the packing of the items, as well as the UI of this feature.

    • What it does: It checks the progress of planning that the user has done. It checks if firstly, there are no overlapping activities in the schedule, then it checks the number of packed items, then it checks if the total amount of the fixed expenses is under the budget, and lastly, it checks if there is an accommodation booking for every night of the trip.

    • Justification: The status feature ensures the user has planned for their trip fully before they embark on their trip. It prevents any slip-ups from the lack of planning, such as forgetting to pack something, to ensuring that they have a place to stay every night of their trip. This ensures that the trip is a smooth sailing one, with little slip-ups.

    • Highlights: This enhancement works well with the existing accommodation booking, schedule feature, fixed expense feature and the packing list feature (mentioned above), as it helps users keep track of the planning progress of their trip. Careful considerations have to be made so that this feature can be expanded upon by future developers, including myself. The implementation of this feature was challenging because certain restrictions must be enforced to ensure that the users' plans are appropriate.

The implementation was challenging and time consuming as it required understanding of all the other features, such as the Accommodation Booking, the Schedule and the Budget.

  • Code contributed: [All commits] [Project Code Dashboard]

  • Other contributions:

    • Project management:

      • There were a total of 4 major releases, from version 1.1 to 1.4. I contributed to all the versions on GitHub.

    • Enhancements to existing features:

      • Made the UI nicer by adding icons for all the features. (Pull requests #232 #235, #239, #330)

      • Wrote additional tests for existing features to improve coverage(Pull requests #143 #359 #366)

      • Morph Address Book to Packing List (Pull request #122)

      • Fix Bugs present within our code (Pull requests #245, #257, #349, #385)

    • Documentation:

      • Used more 'you' language in the UserGuide so that it will be more reader-friendly. In addition, I added in pictures so that the reader can have visual cues on how the output should look like for each command.

    • Community:

      • Reviewed Pull Requests with non-trivial comments (Pull Requests #363 #397)

      • Reported bugs and offered suggestions for StudyBuddy, another AddressBook3-based application.

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.

Add a new packing list item: additem

This command allows you to add a new item into your packing list.

Format:

additem name/NAME quantity/QUANTITY category/CATEGORY

  • If there is already an item in the packing list with the same name, then it will notify you of it.

  • Refer to [packing-param] for detail about each parameter.

Example:

additem name/underwear quantity/5 category/clothes

Suppose you want to add a new item with the following information and wish to record it in E.T..

NAME

underwear

QUANTITY

5

CATEGORY

clothes

You can follow these instructions:

Adding your packing list item:

  1. Type additem name/underwear quantity/5 category/clothes into the Command Box.

  2. Press Enter to execute.

Outcome:

  1. The Result Display will show a success message.

  2. E.T. will switch to the Packing List Tab.

  3. You can now see your newly added item.

AddItem
Figure 1. After additem command

Edit an existing packing list item: edititem

This command allows you to edit any mistake made in the details of an existing item.

Format: edititem INDEX [name/NAME] [quantity/QUANTITY] [category/CATEGORY]

  • Existing values will be updated to the input values.

  • This command can only be used if an item has been added.

  • Refer to [packing-param] for detail about each parameter.

Examples:

edititem 5 name/boxer quantity/3 category/essentials

Let’s say you want to edit the item at index 5 to the following information:

Current Edited

NAME

Underwear

Boxer

QUANTITY

5

3

CATEGORY

clothes

essentials

You can follow these instructions:

Editing the packing list item:

  1. Type edititem 5 name/boxer quantity/3 category/essentials into the Command Box.

  2. Press Enter to execute.

Outcome:

  1. The Result Display will show a success message.

  2. E.T. will switch to the Packing List Tab.

  3. You can now see your edited item.

EditItem
Figure 2. After edititem command

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.

List Managers

(Contributed by Catherine)

E.T. allows the user to manage different essential lists for their trip.

These list include:
* Activities * Transport Bookings * Fix Expenses * Accommodation Bookings * Packing List

All these lists are managed by `ListManager`s which support basic CRUD operations and some additional operations for users to manage their list efficiently. The term item will be used to refer to the elements stored in a list.

Common commands for all `ListManager`s:

  • add — Creates a new item

  • delete — Deletes an existing item

  • edit — Edits an existing item

  • sort — Sorts the list by the given specification

  • list — List all items in the list.

Rationale

When planning for a trip, there are many things that the user may want to keep track of. This is our reason for creating the 5 lists stated above. The `ListManager`s are thus created to help the user manage the 5 lists so that they can plan their trip conveniently and efficiently.

Current Implementation

In this section, we will first explain the structure of a typical ListManager also known as an XYZListManager. As mentioned earlier in the overview of this section, the term item will be used to refer to the elements stored in a list.

The XYZListManager contains a UniqueList which is a data structure that stores all the items of a list. The UniqueList makes use of Java’s generics and can only contain items that implement the UniqueListElement interface. This is because the uniqueness of an element in the UniqueList is determined by the returned value of the isSame() method of the UniqueListElement interface.

In addition, the XYZListManager implements the ReadOnlyXYZManager interface. This interface has the getXYZList() method which returns an ObservableList of items. For example, ActivityManager implements ReadOnlyActivityManager. The ObservableList of items allows the Ui model to use the Observer Pattern to update the GUI.

The following Class Diagram describes the aforementioned structure of the ActivityManager.

ListManagerClassDiagram
Figure 3. Structure of ActivityManager

The following paragraphs will describe what happens when the user performs an operation on a ListManager through commands. XYZCommand here will refer to a command described above for the 5 ListManager s. (e.g. AddActivityCommand, EditTransportBookingCommand).

As described in [Design-Logic], after the user enters a command, the EasyTravelParser will generate an XYZCommandParser which parses the user input parameters and generate an executable XYZCommand that performs an operation on the list.

We will describe the execution of an XYZCommand, using AddActivityCommand as an example. All other XYZCommand will be executed in similar ways.

When AddActivityCommand is executed, an Activity will be added to the list of activities managed by the ActivityManager in the Model component.

The Sequence Diagram below shows the execution of the AddActivityCommand:

Schedule Activity Command Execution
Figure 4. Execution of the AddActivityCommand

The lifeline for the AddActivityCommand should end at the destroy marker (X). However, due to a limitation of PlantUML, the lifeline reaches the end of the diagram.

This sequence diagram does not take into consideration the possible exceptions which might occur during the AddActivityCommand execution.

Design Consideration

Aspect: Separation between scheduling and activity management
Pros Cons

Option 1 (Current)
Use 5 different list managers to manage the 5 main features

Keeps everything separate which abide by the Separation of Concerns Principle (SoC) principle.

Achieves better modularity by separating the code into distinct sections, such that each section addresses a separate concern.

Allows for different behaviours of each list manager

Tedious to implement as we have many lists to manage.

Option 2
Use a single manager to handle all the 5 lists

Easy to implement as we only need to write one ListManager class.

Violates SoC.

Reason for choosing option 1:

Applying SoC limits the ripple effect when changes are introduced to a specific part of the system. Since we are constantly changing our system during development, abiding by SoC will save us time in the long-run as less code is affected when changes to the system are made.

Aspect: Implementation behind a list manager
Pros Cons

Option 1 (Current)
Extract the common operations and functionality of the 5 ListManagers into one UniqueList class. All 5 ListManagers will make use of the UniqueList as their internal data structure and build their operations on top of it.

Abide by the Don’t Repeat Yourself (DRY) principle. Minimize repeated code as all ListManagers use the basic functionality of UniqueList.

All ListManagers have dependencies on UniqueList. Thus, UniqueList has to be implemented before starting on any ListManager. This slows down the implementation of all ListManagers.

Option 2
Do not extract any common operations and functionalities

Each ListManager can be worked on by different people as there is no dependency on a common data structure that has to be implemented beforehand. Allows each feature to be worked on separately by different developers.

Violates the DRY principle as there will be common operations between ListManagers.

Reason for choosing option 1:

  • It is a good coding practice to follow the DRY principle.

  • The implementations of the ListManagers are done quite early on, where our team has more flexibility in terms of deadline. Thus, we can afford to spend more time developing the UniqueList data structure before starting on the implementation of any ListManager