This portfolio summarizes my contributions to the Event Manager Application, whereby our team of 5 (Xiang Rong, Gerald, James, Long, myself) worked on it as part of our module on software engineering in the National University of Singapore (NUS), over a period of 8 weeks. I was the developer in charge of the Event Status feature and the Event Reminder feature in Event Manager.

Project: Event Manager

Event Manager is a morphed and enhanced version of the Address Book Application. It is a desktop application for students living in Residential Colleges to manage all the activities happening throughout the college. The user interacts with it using a Command Line Interface (CLI), and it has a Graphical User Interface (GUI) created with JavaFX. It is written in Java, and has about 10k lines of code (LoC).

Overview

This section presents the purpose of developing the Event Manager Application and the scope of our project.

Students living in Residential Colleges are presented with a myraid of activities on a daily basis. These activities vary from Interest Group (IG) activities, House events and Master’s Tea (where the college invites a notable guest speaker for a sharing session with the students) among many others. With so many events going on in the colleges while meeting the academic requirements of the university life, many students often find it a struggle to balance the conflicting demands.

Thus, Event Manager offers a pragmatic solution to the students' problem of managing events in colleges, by allowing them to view and register for any event in one setting. Additionally, it is supported by other features to enhance the user’s experience, such as the Comment feature and the Reminder feature.

The following is a list of the main features in Event Manager:

  1. Authentication: Admin accounts to manage events and user accounts to register for events.

  2. Find: A search feature to filter events based on keywords in the events' data fields.

  3. Registration: Users can indicate their attendance for events. Attendance is displayed to all other users.

  4. Reminder:* Automated reminders are sent to users who have registered for events that are happening in the next 24 hours.

  5. Comment: A comment section to facilitate interactions amongst the users for an event.

  6. Status:* Displays the status of an event to users. Statuses can either be 'Completed' or 'Upcoming'.

  7. Export: Allows users to export their registered events as a calendar file, compatible with other calendar applications.

  8. Undo/Redo: Allows users to undo/redo previous commands one at a time.

  9. Basic features: Allows admin users to create, update, edit and delete events.

Summary of contributions

This section outlines the breadth of my contributions in order of magnitude, starting with my biggest contributions.

  • Major enhancement #1:

    • Added a reminder mechanism for user-registered events

    • What it does
      Sends a reminder to users for any upcoming events (those happening in the next 24 hours) that they have registered for.

    • Justification
      This feature significantly increases the capacity of Event Manager, by maximizing its potential to create meaningful interactions with the user, apart from the user’s interactions with the CLI.

    • Highlights
      This enhancement is the first software-driven feature in Event Manager, whereby the feature runs without any user/operator interactions. This feature required a good understanding of the overall system architecture to implement, in particular the event-driven nature of interactions between components in the Event Manager.

  • Major enhancement #2:

    • Added a new self-updating status field for events

    • What it does
      Allows the user to easily discern completed events from upcoming ones. Completed events are events that have taken place while upcoming events are those that have yet to occur.

    • Justification
      This feature enhances the product remarkably because before its implementation, a user would have to strain his/her eyes to look through each event’s details to ascertain which events have occurred and which ones are coming up.

    • Highlights
      This enhancement changes the current model and greatly boosts the productivity of Event Manager’s users. Its implementation was the result of thorough analysis of several design alternatives, based on their efficiency and effectiveness.

  • Minor enhancement:

    • Added new information fields for events

      • A Contact field for the organiser/person-in-charge of the event. (#14)

      • A Comment field for the comment section. (#91)

      • An Attendee field for the event’s attendees. (#58)

  • Code contributed: [Functional code]

  • Other contributions:

    • Project management:

      • Set up milestones and issue labels for the project on GitHub

    • Enhancements to existing features:

      • Morphed the address field into a venue field (#53)

    • Documentation:

      • Tweaked existing contents of the Developer Guide as well as checked for grammatical errors (view changes here)

    • Community:

      • Reported bugs and suggestions for other teams in the class (examples: 1, 2, 3)

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.

Show event reminders : reminder

Admin/User: Shows event reminders for all upcoming events that you have registered for.
Format: reminder

Upcoming events are those that are occurring within the next 24 hours.

  • You will only receive reminders for events that you have registered for.

  • You have to be logged-in to receive reminders.

  • Reminders are automatically sent out every 6 hours, unless you initiate the command.

  • Close the reminder alert dialog using your mouse or by hitting 'enter' on your keyboard.

AlertDialog
Figure 1. Event Reminder Alert Dialog

Updates the statuses of events : update

Admin/User: Updates the statuses of events.
Format: update

  • Events that have already occurred will have the Completed status.

  • Events that have yet to occur will have the Upcoming status.

  • The update command can be used without you having to log in.

  • Event statuses are automatically updated every 5 minutes.

You may experience some disruptions to the UI during the automatic update due to high load, especially if your computer is using an older processor. Give it a few seconds to load and if the problem still persists, use the update 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.

Event Status and Reminders

The Event Status feature displays the status of events based on their DateTime field. Events whose DateTime has passed the DateTime at the time of updating will adopt the COMPLETED status while events whose DateTime has yet to pass will take on the UPCOMING status. The Event Reminders feature sends reminders to the logged-in user for upcoming events which the user has registered for.

Current Implementation

The Event Status and Reminder feature consists of two commands periodically executed by LogicManager. Specifically, the UpdateStatusCommand and the ReminderCommand. The automated process is facilitated by the Timer and TimerTask classes in the java.util package. Both commands initially calls the model#getFilteredEventList() method to obtain the displayed list of events as lastShownList.

The UpdateStatusCommand is periodically called in TimerTask updateEventStatus every 5 minutes and it loops through every event in lastShownList to update the event’s status using Status#setStatus() and model#updateEvent(). It then refreshes the displayed list by calling model#updateFilteredEventList().

The following sequence diagram shows how the UpdateStatusCommand works:

Update sequenceDiagram
Figure 2. Sequence Diagram for UpdateStatusCommand
The Event Status feature is supported by the Status and DateTime field in the Event. Events with DateTime fields before the current Date will assume the COMPLETED Status, whereas those with DateTime fields after the current Date will take on the UPCOMING Status.

The ReminderCommand is periodically called in TimerTask checkEventReminders every 6 hours and it loops through every event in the lastShownList to check for the following:

  1. checkAttendeeKeywordsMatchEventAttendee — checks if the current user is registered as an attendee

  2. checkEventIsUpcoming — checks if the event is upcoming (happening in the next 24 hours)

If the two conditions are satisfied, a sendEventReminder event containing the event’s name and starting time is used to communicate with the UiManager to show an alert dialog using Ui#showAlertDialogAndWait() to display the event’s information.

The following sequence diagram shows how the ReminderCommand works:

Reminder sequenceDiagram
Figure 3. Sequence Diagram for ReminderCommand

Design Considerations

Aspect: Whether to automate the commands or make them user-enabled

  • Alternative 1 (current choice): Status updates and reminders automated using Timer.

    • Pros: Takes the updating and checking tasks off users. Less reliance on users' end also means that updates and reminders are executed more regularly.

    • Cons: Uses up more processing resources.

  • Alternative 2: Users have to run status updates and reminders checking.

    • Pros: Ensures that the updated status or reminders are provided to users when they want it.

    • Cons: Users may be looking at very outdated statuses and will not receive reminders if they forget to check for it.

Aspect: How to automate the updates/checks

  • Alternative 1 (current choice): Status updates and reminder checks called using Timer.

    • Pros: A more reliable way to update the status and check for reminders.

    • Cons: More complexity added to the codes and timers use up more processing resources.

  • Alternative 2: Status updates and reminders called after each command given by the user.

    • Pros: Easier implementation by calling the status update or reminder check after every user command.

    • Cons: Less reliable and less effective method of updating since the statuses will not be updated if the user does not execute any commands.

Aspect: Where to implement the update and reminder command

  • Alternative 1 (current choice): Both features are subclass of the Command superclass.

    • Pros: Easier implementation since there are already methods to execute commands. This implementation also allows users to call the commands if necessary.

    • Cons: Both features are not really commands that should be executed by the user and thus should not be subclasses of Command.

  • Alternative 2: Create a new class in LogicManager which is responsible for the execution.

    • Pros: The TimerTask could be implemented in the command and the UpdateStatusCommand and ReminderCommand need only be called once. This also decreases the coupling with MainApp and EventManagerParser.

    • Cons: A new method for executing the two commands would be required and the user would not be able to call for a status update should the need arise.

Aspect: How to implement the status update

  • Alternative 1 (current choice): Implemented using pre-existing codes such as EditEventDescriptor and model#updateEvent().

    • Pros: No need to add new codes for the implementation and add unnecessary complexities into the project code.

    • Cons: Inefficient method to update only the status since every other field in the event has to be copied over each time the status is updated.

  • Alternative 2: Write a Event#setStatus() method to update the status.

    • Pros: More efficient way of updating the statuses of events thus reducing the consumption of processing resources.

    • Cons: More lines of codes required and also adds to the complexity of the project code.

Aspect: Whether to add implementation to allow users to set reminders

  • Alternative 1 (current choice): Reminders are automatically sent to users who registered for an event.

    • Pros: Saves users the trouble of having to set the reminders themselves.

    • Cons: Users cannot unsubscribe to the reminders for events that they have registered for.

  • Alternative 2: Allow users to set reminders as they wish.

    • Pros: Users who do not want reminders can refuse to set reminders.

    • Cons: Users would have to set their own reminders. Some users may choose to save themselves the trouble of setting reminders and miss the events they have registered for.

Use case: Reminder

MSS

  1. User registers for an event "House Dinner".

  2. (a few days passes) A reminder is sent to the user for the event "House Dinner", 24 hours before the event time.

  3. User is redirected to the event’s Browser Panel.

  4. User hits enter to close the alert dialog.

  5. User reads the information about the event. Use case ends.

Use case: Event Status

MSS

  1. User views list of events.

  2. User requests to update the statuses of events.

  3. Event Manager updates the statuses of events and refreshes the displayed list of events.

  4. User can easily locate "UPCOMING" events. Use case ends

Requesting a reminder

  1. Requesting for reminders as a user registered for an upcoming event

    1. Prerequisites:
      Added an event that is happening in the next 24 hours
      Logged in as user
      Registered to upcoming event

    2. Testcase: reminder
      Expected: An alert dialog shows up for the relevant event, showing the name of the event and the event’s start time. Hitting 'enter' should close the alert dialog.

  2. Requesting for reminders as a user not registered for an upcoming event

    1. Prerequisites:
      Added an event that is happening in the next 24 hours
      Logged in as user

    2. Testcase: reminder
      Expected: Event Manager shows message that there are no upcoming events for you in the logger.

  3. Requesting for reminders as a user not logged in

    1. Prerequisites:
      Not logged in

    2. Testcase: reminder
      Expected: Event Manager shows message that you have to be logged in in the logger.

Updating event statuses

  1. Updating event status for an event that has just passed

    1. Prerequisites:
      Added an event that will happen in 1-2 minutes' time

    2. Testcase: update
      Expected: The event’s status should change from UPCOMING to COMPLETED

  2. Updating event status without any events

    1. Prerequisites:
      Event Manager is empty of events (Use the clear command)

    2. Testcase: update
      Expected: Event Manager shows message that there are no events to be updated in the logger.