PROJECT: UniLA

Overview

  • UniLA is a desktop utilities application designed for NUS students who are typing oriented.

  • UniLA provides an efficient and convenient solution for managing contact list and event list, contact interactions, planning meetings, setting up reminders, etc.

  • The application is primarily concerned with CLI (Command Line Interface) Interaction, with a simple and intuitive GUI provided.

Summary of contributions

  • Major enhancement: build event list component and enable add, delete, list, edit events and the connection between persons and events

    • What it does: allows the NUS student to store and manage events and add participants from their contact list to events

    • Justification: This feature improves the product significantly because it can help NUS students to better manage upcoming events

    • Highlights: This enhancement complements the exist functionality of AddressBook4 and greatly increase the capacity of product. It required significant effort to build a new event model and various logic commands

  • Code contributed: [RepoSense Project Code Dashboard]

  • Other contributions:

    • Project management:

      • Set up team repo and integrate Travis, Coveralls, Appveyor to team repo.

      • Set team repo to be RepoSense-compatible

      • Managed releases v1.2 - v1.4 (3 releases) on GitHub

    • Community:

      • PRs reviewed (with non-trivial review comments): #31, #80, #95

      • Reported bugs and suggestions for other teams in the class (examples: #126, #113, #119, #122, #135)

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.

Connecting a person to an event : connect

Connects one contact from Contact List to Event List by contact index and event index
Format: connect ci/CONTACT_LIST_INDEX ei/EVENT_LIST_INDEX

  • CONTACT_LIST_INDEX refers to the index number shown in the displayed Contact List.

  • EVENT_LIST_INDEX refers to the index number shown in the displayed Event List.

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

Examples:

  • list
    Find the participant index from Contact List.
    listE
    Find the event index from Event List.
    connect ci/1 ei/2
    Add the 1st person from Contact List into the 2nd event in the Event List.

Disconnecting a person with an event : disconnect

Disconnects one contact from Contact List to Event List by contact index and event index
Format: disconnect ci/CONTACT_LIST_INDEX ei/EVENT_LIST_INDEX

  • CONTACT_LIST_INDEX refers to the index number shown in the displayed Contact List.

  • EVENT_LIST_INDEX refers to the index number shown in the displayed Event List.

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

Examples:

  • list
    Find the participant index from Contact List.
    listE
    Find the event index from Event List.
    disconnect ci/1 ei/2
    Disconnect the 1st person from Contact List with 2nd event in the Event List.

Adding an event: addE

Adds an event to event list+ Format: addE n/NAME d/DESCRIPTION v/VENUE s/STARTING_TIME e/ENDING_TIME l/LABEL

  • Only valid date and time will be allowed and must be in the format of yyyy-MM-dd HH:mm:ss

  • User need to make sure start time is equal or before end time.

Examples:

  • addE n/career talk d/Google company info session v/com1 level2 s/2019-01-31 14:00:00 e/2019-01-31 14:00:00 l/important

  • addE n/CS2103 project meeting d/quick meeting v/central library s/2019-12-31 16:00:00 e/2019-12-31 16:00:00 l/urgent

Deleting an event : deleteE

Deletes the specified event from the event list.
Format: deleteE INDEX

  • Deletes 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 needs to first delete reminders related the event using deleteR.(please refer to [deleteR] for deleting reminders)

Examples:

  • listE
    deleteR e/2
    deleteE 2
    Deletes the 2nd event in the event list.

Listing all events : listE

Shows a list of all events in the event list.
Format: listE

Editing an event : editE

Edits an existing event in the UniLA.
Format: editE INDEX [n/NAME] [d/DESCRIPTION] [v/VENUE] [s/STARTING_TIME] [e/ENDING_TIME] [l/LABEL]

  • Edits 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, …​

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

  • Existing values will be updated to the input values.

  • Only valid date and time will be allowed and must be in the format of yyyy-MM-dd HH:mm:ss

  • User need to make sure start time is equal or before end time.

Examples:

  • editE 1 d/short meeting l/top priority
    Edits the description and label of the 1st event to be short meeting and top priority respectively.

  • editE 2 v/com2 level4
    Edits the venue of the 2nd event to be com2 level4.

  • AddE addE n/NAME d/DESCRIPTION v/VENUE s/STARTING_TIME e/ENDING_TIME l/LABEL
    e.g. addE n/career talk d/Google company info session v/com1 level2 s/2019-01-31 14:00:00 e/2019-01-31 14:00:00 l/important

  • DeleteE : delete INDEX
    e.g. deleteE 3

  • EditE : editE INDEX [n/NAME] [d/DESCRIPTION] [v/VENUE] [s/STARTING_TIME] [e/ENDING_TIME] [l/LABEL]
    e.g. editE 1 d/short meeting l/top priority

  • FindE : findE KEYWORD [MORE_KEYWORDS]
    or 'findE [n/NAME] [d/DESCRIPTION] [v/VENUE] [s/STARTING_TIME] [e/ENDING_TIME] [l/LABEL]
    or findE time/operatorDATE
    or findE time/alias(ytd, today or tmr)
    or findE duration/operatorHOURS
    e.g. findE talk
    e.g. findE s/2019-04-07 10:00:00
    e.g. findE time/<2019-04-09
    e.g. findE duration/<3

  • ListE : listE

  • Connect : connect ci/CONTACT_LIST_INDEX ei/EVENT_LIST_INDEX

  • Disconnect : disconnect ci/CONTACT_LIST_INDEX ei/EVENT_LIST_INDEX

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 list component

Current Implementation

The Event list component complements Person list(the original addressbook4) to provide user with better manage events and their participants. To achieve this, a new Event model is created to according to the below class diagram.

EventClassDiagram

All the Events object will be stored inside UniqueEventList, which becomes another data collection inside AddressBook class. When ModelManager create VersionedAddressBook(implements AddressBook), there will be two data collections, one for event and the other for contact. From the below Model class diagram, it will be easier to see the illustrate how this Event model integrate the original data structures

BeforeAfterClassDiagram

Several use cases are implemented for this event components, the use case diagram is shown below:

EventListUseCases

Design Considerations

Aspect: How to implement Event list component

  • Alternative 1 (current choice): Add UniqueEventList into AddressBook.

    • Pros: Easy to implement and current redo, undo, clear command can work for this Event model commands

    • Cons: AddressBook need to manage both contacts and events, thus have to implement more functions, like add, delete, set for both event and person.

  • Alternative 2: Build another class outside AddressBook to maintain UniqueEventList

    • Pros: Functionality will be separated to different classes.

    • Cons: This will need much more implementation to build the event list component, including VersionedAddressBook, redo,undo

Connect feature

Current Implementation

The connect feature will provide two commands, Connect and Disconnect, which is used to add/remove a person to an event as participants. The connect/disconnect mechanism is facilitated by the persons list attribute defined in Event class. All the participants for an event is stored inside the persons list. The connect/disconnect functions are achieved by adding/removing person from the list in a specific event. To achieve this function and other person-event related functions, a unidirectional reference is maintained from Event to Person, as shown below.

EventContactReference

Design Considerations

Aspect: How to implement Connection between contact and event

  • Alternative 1 (current choice): Maintain unidirectional relationship between events and contacts.

    • Pros: Easier to implement, sufficient for all the operations provided in the current product and less memory/storage required

    • Cons: meet function need to loop through all events to plan a meeting

  • Alternative 2: Maintain bidirectional relationship between events and contacts.

    • Pros: Still easy to implement, easier to get the events that each person has.

    • Cons: This bidirectional relationship is relatively harder to manage than unidirectional, because delete person/event and connect/disconnect need to change both two referencing lists. Also, more storage will be used in this implementation because Person class also maintain all the Events it is participating, although when the number of events and persons is small, the difference in storage is not significant.

Use case: Add person / event

MSS

  1. User inputs text to console to add person/event.

  2. UniLA acknowledges and adds person/event to the list.

  3. UniLA is updated with a latest list of persons/events.

    Use case ends.

Extensions

  • 1a. The format of parameters entered are invalid.

    • 1a1. UniLA shows an error message.

      Use case resumes at step 1.

Use case: Delete person/event

MSS

  1. User requests to list persons/events

  2. UniLA shows a list of persons/events

  3. User requests to delete a specific person/event in the list

  4. UniLA deletes the person/event

    Use case ends.

Extensions

  • 2a. The list is empty.

    Use case ends.

  • 3a. The given index is invalid.

    • 3a1. UniLA shows an error message.

      Use case resumes at step 2.

Use case: Edit person/event

MSS

  1. User requests to edit a specific person/event in the list.

  2. UniLA updates itself.

    Use case ends.

Extensions

  • 1a. The list is empty.

    • 1a1. UniLA shows an error message.

      Use case ends.

  • 1b. The arguments for edit command are invalid.

    • 1b1. UniLA shows an error message.

      Use case resumes at step 1.

Use case: List persons/events

MSS

  1. User request to list all the persons/events.

  2. UniLA displays list of persons.

    Use case ends.

Extensions

  • 1a. There is no event/person in UniLA.

    • UniLA shows a successful message.

      Use case ends.

PROJECT: PowerPointLabs

{Optionally, you may include other projects in your portfolio.}