PROJECT: Event Manager

1. Overview

This document provides a summary of my contributions as a developer of the Event Manager project. It showcases both my proficiency in software engineering and clarity in technical writing.

Event Manager is a cross-platform desktop application that manages events, targeted at the Halls and Residential Colleges of NUS. These residences tend to host many events for their students, and it can be difficult to keep track of events amidst the students' daily lives. Our application aims to consolidate these events and present them in a clear manner, allowing the residents to easily sieve through upcoming events that they are interested in.

Other main features include:

  • Authentication

  • Registration

  • Reminders

  • Comments

  • Searching & Sorting

  • Export of calendar file

The user interacts with the application using a Command Line Interface (CLI), and it has a Graphical User Interface (GUI) created with JavaFX. All features can be used by typing commands in the CLI, but the GUI provides important information as well as some ease of use to the user. It is written in Java, and has about 10 kLoC.

This project was developed as part of CS2113T (Software Engineering & Object-Oriented Programming) by a team of 5 students, over a period of 8 weeks.

2. Summary of contributions

My contributions to the project are described below.

  • Major enhancement: Added the ability to register/unregister for events and view attending events

    • What it does:

      Users can indicate their attendance for events, and view the usernames of other attendees. Events that the user are attending can be filtered out and displayed.

    • Justification:

      This feature encourages users to attend events and connect with other users they know who are attending the same event, promoting social engagement in the community. It also provides event coordinators with a rough estimate of the turnout, allowing them to make suitable preparations for the event, e.g. ensuring ample logistics and manpower.

    • Highlights:

      This enhancement required an in-depth analysis of design alternatives. The implementation too was moderately difficult as it required modification to the existing storage format.

  • Minor enhancement:

    • Formatting and display of event details in event page, with proper URL encoding (#182)

    • Assisted morphing of product to fit context of project

  • Code contributed: [RepoSense link]

  • Other contributions:

    • Project management:

      • Ensure milestones are met and assist teammates in debugging

      • Wrote additional tests for registration features to increase coverage (Pull request #109, #182)

    • Documentation:

      • Updated User and Developer Guides to describe new features: #103, #186, #188

    • Community:

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.

3.1. Registering for an event : register

User: Registers for an event by adding the current user’s username to the attendance list.
Format: register INDEX

  • Registers for the event at the specified INDEX.

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

  • The index must be a positive integer 1, 2, 3, …​

  • User must not be registered for event.

Examples:

  • list
    register 3
    Registers user for the 3rd event of the Event Manager.

  • find Sports
    register 1
    Registers User for the 1st event in the results of the find command.

registerUG
Figure 1. Expected outcome after user Peter Parker registers for the event at index 5 (annotations in red).

3.2. Unregistering from an event : unregister

User: Unregisters for an event by removing the current user’s username from the attendance list.
Format: unregister INDEX

  • Unegisters for the event at the specified INDEX.

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

  • The index must be a positive integer 1, 2, 3, …​

  • User must be already registered for event.

Examples:

  • list
    unregister 1
    Unregisters user from the 1st event of the Event Manager.

  • find Sports
    unregister 2
    Unregisters user from the 2nd event in the results of the find command.

3.3. Listing all registered events : attending

User: Lists all events that the user has registered for.
Format: attending

attendingUG
Figure 2. Events that user Peter Parker is registered to are displayed, similar to find operation (annotations in red).

3.4. Removing user from event : removeAttendee

Admin: Removes a user registered for an event.
Format: removeAttendee INDEX u/USERNAME

  • Removes USERNAME from the event at the specified INDEX.

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

  • The index must be a positive integer 1, 2, 3, …​

  • User with the specified username must be registered for the event.

Examples:

  • list
    removeAttendee 1 u/Peter Parker
    Removes the user with username Peter Parker from the attendance of the 1st event of the Event Manager.

  • find Party
    removeAttendee 2 u/Alice
    Removes the user with username Alice from the attendance of the 2nd event in the results of the find command.

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

4.1. RSVP

4.1.1. Current Implementation

The RSVP feature consists of the register, unregister, and attending command. A removeAttendee command is included for admin use to remove users forcibly if required. The implementations of the commands use the EditEventDescriptor class and createEditedEvent method from EditCommand to aid in updating event attendance. The AttendanceContainsUserPredicate class is used to filter events that the user has registered for. Attendees of an event are stored in the eventmanager.xml file, in a similar fashion to the storage of tags.

Below is an example usage scenario and how the RSVP mechanism behaves during a register operation:

Step 1: The user launches the application, and logs in.

Step 2: The user clicks on an event or types select 2 into the CLI. Details of the 2nd event including event attendance are displayed.

Step 3: The user executes register 2 to register for the 2nd event. With the Model, the RegisterCommand#execute method gets the event at index 2, the username of the current user, and the current attendance of the event as a HashSet with Event#getAttendance.

Step 4: The register command tries to add the username into the current attendance with HashSet#add. If the username already exists in the attendance, a CommandException is thrown. Else, EditCommand#EditEventDescriptor is used with the new attendance to create an edited event.

Step 5: The model is updated with the edited event and committed. The event page is reloaded to display the new event attendance.

Below is another example usage scenario illustrating how the RSVP mechanism behaves during an unregister operation, with the use of attending.

Step 1: The user launches the application, and logs in.

Step 2: The user types attending into the CLI. AttendingCommand#execute retrieves the current user’s username from Model and creates a AttendanceContainsUsernamePredicate predicate. The predicate is used with Model#updateFilteredEventList to filter out events without the user’s username in their attendance. Events that the user has registered for are displayed.

Step 3: The user executes unregister 2 to unregister from the 2nd event. With the Model, the UnregisterCommand#execute method gets the event at index 2, the username of the current user, and the current attendance of the event as a HashSet with Event#getAttendance.

Step 4: The unregister command command tries to remove the username from the current attendance with HashSet#remove. If the username does not exist in the attendance, a CommandException is thrown. Else, EditCommand#EditEventDescriptor is used with the new attendance to create an edited event.

Step 5: The model is updated with the edited event and committed. The event page is reloaded to display the new event attendance..
removeAttendee works in similar manner to unregister, except the username of the target attendee is used when calling HashSet#remove.
Sorting of attendance
TreeSet is used when retrieving the attendance for display as it allows for easy sorting of attendee usernames. Usernames are sorted in case-insensitive lexicographical order.

The following sequence diagrams show how the register and removeAttendee operations work:

registerSD
Figure 3. Sequence diagram for register operation
removeAttendeeSD
Figure 4. Sequence diagram for removeAttendee operation

4.1.2. Design Considerations

Aspect: How to display attendance

  • Alternative 1 (current choice): Display event attendance list

    • Pros: Can see which other users are attending the event

    • Cons: Attendees might have privacy concerns regarding how other users can see whether they are attending an event.

  • Alternative 2: Display whether current user is registered for an event

    • Pros: Easier to implement, user can easily see whether they are registered

    • Cons: Cannot see other attendees.

Aspect: Where to store attendance

  • Alternative 1 (current choice): Attendance stored in eventmanager.xml in similar fashion to tags.

    • Pros: Methods for parsing tags can be applied to parse attendance

    • Cons: Inefficient to retrieve list of events which a user has registered for

  • Alternative 2: Store in user profile

    • Pros: Can easily check which events a user has registered for.

    • Cons: Inefficient to check which users are attending an event.

  • Alternative 3: Store in both eventmanager.xml and user profile.

    • Pros: Allows for efficient retrieval of both event attendance and events that user has registered for.

    • Cons: Additional complexity to implement storage in user profile, data redundancy.

Aspect: How to store attendance

  • Alternative 1 (current choice): Attendance stored in unsorted order.

    • Pros: Easy to add new attendee to attendance.

    • Cons: Requires sorting whenever attendance is displayed.

  • Alternative 2: Attendance stored in sorted order.

    • Pros: No need to sort each time an event is reloaded.

    • Cons: More complexity for inserting in correct location.

4.2. Use Cases

Use case: Registration

MSS

  1. User requests to list events.

  2. EventManager displays list of events.

  3. User selects event with status [UPCOMNG].

  4. EventManager displays details of selected event, including current attendance list.

  5. User requests to register for the event.

  6. EventManager adds user to attendance list and displays confirmation message.

Extensions:

  • 5a. User is already registered for event.

    • 5a1. EventManager displays error message. Use case resumes at step 2.

  • 6a. User unregisters from event.

    • 6a1. User requests to unregister for the event.

    • 6a2. EventManager removes user from attendance list and displays confirmation message. Use case ends.

  • 6b. User is banned from event.

    • 6c1. Admin requests to remove user from event.

    • 6c2. EventManager removes user from attendance list and displays confirmation message. Use case ends.

4.3. Displaying event details

  1. Viewing event details with special characters

    1. Prerequisites:
      First event in list contains special characters in details, e.g. ?, #, &, =, /, @, :.

    2. Test case: select 1
      Expected: Event page displays all special characters. Status bar remains the same.

4.4. Registering for an event

  1. Registering for an event while all events are listed/filtered

    1. Prerequisites:
      Username is not in attendance of first event.
      Username is in attendance of second event.

    2. Test case: register 1
      Expected: Username is added to attendance of first event. Index of the event is shown in the status message. Timestamp in the status bar is updated.

    3. Test case: register 2
      Expected: No duplicate username in attendance of second event. Error details shown in the status message. Status bar remains the same.

    4. Test case: register x (where x is non-positive, larger than the list size or not an integer)+ Expected: Username is not added to attendance of any event. Error details shown in the status message. Status bar remains the same.

4.5. Unregistering for an event

  1. Unregistering for an event while all events are listed/filtered

    1. Prerequisites:
      Username is in attendance of first event.
      Username is not in attendance of second event.

    2. Test case: unregister 1
      Expected: Username is removed from attendance of first event. Index of the event is shown in the status message. Timestamp in the status bar is updated.

    3. Test case: unregister 2
      Expected: Error details shown in the status message. Status bar remains the same.

    4. Test case: unregister x (where x is non-positive, larger than the list size or not an integer)+ Expected: Username is not removed from attendance of any event. Error details shown in the status message. Status bar remains the same.

4.6. Viewing all attending events

  1. Viewing attending events while all events are listed

    1. Prerequisites:
      List all events using the list command. Multiple events in the list.
      User has registered for some events using the register command.

    2. Test case: attending
      Expected: Only events which the user has registered for are shown. Number of events the user has registered for are shown in the status message. Timestamp in the status bar remains the same.

  2. Viewing attending events while events are filtered

    1. Prerequisites:
      Filter events with the find command.
      User has registered for some events using the register command.

    2. Test case: attending
      Expected: Only events which the user has registered for are shown, including events not in the filtered list. Number of events the user has registered for are shown in the status message. Timestamp in the status bar remains the same.

4.7. Removing an attendee from event

  1. Removing an attendee by username from an event while all events are listed/filtered

    1. Prerequisites:
      Logged in as admin.
      Username of target attendee Charlotte Oliveiro is in the attendance of the first event. Username of target attendee Charlotte Oliveiro is not in the attendance of the second event.

    2. Test case: removeAttendee 1 u/Charlotte Oliveiro
      Expected: Target attendee is removed from attendance of first event. Username of target attendee and index of the event is shown in the status message. Timestamp in the status bar is updated.

    3. Test case: removeAttendee 1 u/charlotte oliveiro
      Expected: Target attendee username is case-sensitive. Error details shown in the status message. Status bar remains the same.

    4. Test case: removeAttendee 2 u/Charlotte Oliveiro
      Expected: Target attendee does not exist in second event. Error details shown in the status message. Status bar remains the same.

    5. Test case: removeAttendee x u/Charlotte Oliveiro (where x is non-positive, larger than the list size or not an integer)
      Expected: Target user is not removed from attendance of any event. Error details shown in the status message. Status bar remains the same.