Chattoraj Ayush - Project Portfolio

PROJECT: InsuRen

Overview

'Ren' in Mandarin translates to 'person' or 'people', and true to our name, this app is all about managing one’s network of clients in an organized, efficient and intuitive manner. InsuRen is geared to the needs of the modern Insurance salesman, but anyone whose business is their strong rapport with their clients will find this to be an indispensable tool.

Summary of contributions

Major enhancement: added the ability to schedule meetings with clients
- What it does: allows the user to schedule a meeting with a client. Schedule meetings can be searched using the meetings command.
- Justification: This feature allows insurance agents to keep track of their schedules by enabling them to have a record of all their meetings. It also allows them to quickly search through all their meetings, and prevents them from accidentally scheduling clashing meetings.
- Highlights: This enhancement added a new command. It required the use of multiple Java API classes for the validation of dates and times, as well the implementation of a new global data structure to store all meeting timings to prevent meetings from being scheduled at the same time.
Minor enhancement: added shorthand commands for all existing commands for faster access.
Code contributed: [RepoSense]
Other contributions:
- Project management:
  - Managed releases v1.1 - v1.2 (2 releases) on GitHub
- Documentation:
  - Did general changes to existing contents of the User Guide and Developer Guide: #57, #91, #100, #116,
- Community:
  - PRs reviewed (with non-trivial review comments): #102, #60
  - Reported bugs and suggestions for other teams in the class (examples: 1, 2)

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 meeting time: `schedule`

Add a meeting at the input date and time with a specified person.
Format: schedule INDEX m/DD/MM/YY HHMM

Shorthand: sch

InsuRen will add the meeting to your list of meetings, as well as mark the person with the meeting.
You may use any special characters such as '/' and '-', or whitespace to seperate the entries. As long as the relative order of the numbers is DDMMYYHHMM, InsuRen will save it.
Meetings can be scheduled on any valid date in the past (to keep a record) or in the future (as a reminder).
If the date is invalid (i.e. it is not a real date), an error will be thrown.
If there are any meetings scheduled at the same time, it will be flagged out.

Example:

schedule 1 m/12/03/19 0930
InsuRen will record that a meeting is scheduled on 12 March 2019, 0930 with the first entry.

View meeting timings: `meetings`

Displays the details of the meeting at the input date and time.
Format: meetings [DD/MM/YY]

shorthand: m

If there are meetings scheduled on the queried date, the details of the clients the meetings are scheduled with are displayed.
If the query has no date, then all meetings scheduled in InsuRen are displayed.
If there is no meeting scheduled on the day, an empty list is displayed.

Example:

meetings 23/02/18
InsuRen displays meetings scheduled on 23rd February, 2018.

Notifications for expiring plans `[coming in v2.0]`

InsuRen entries have an optional field for date of plan expiry. You will automatically be notified of clients with plans expiring within a month from the day when InsuRen is initialized.
No additional search queries are needed.

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.

Schedule feature

Current Implementation

The schedule mechanism is facilitated by the new Command, Schedule. It extends AddressBook with a list of meetings, stored internally as a UniqueMeetingList. It also allows meetings to be associated to InsuRen entries, since each Person can have up to one Meeting. The complete list of meetings, as well as the meetings scheduled on a single day, can subsequently be accessed using the Meetings command. Additionally, the Schedule Command implements the following operations:

ScheduleCommand#createScheduledPerson(Person personToSchedule, Meeting meeting) - Returns a Person object that has a meeting scheduled according to meeting.
ScheduleCommand#execute() - Executes the command encapsulated by ScheduleCommand.

Given below is an example usage scenario and how the Schedule mechanism behaves at each step.

Step 1. The user launches the application and already has at least one client’s contact in InsuRen.

Step 2. The user executes schedule 1 m/16/10/18 1800 to schedule a meeting with the person in the first index at 1800 hours on 16th October, 2018. However, there is already a meeting scheduled at this time, so it is flagged out to the user.

No meetings are scheduled if there is a clash

Step 3. The user executes schedule 1 m/32/10/18 1830 but since this is not a valid date, InsuRen flags it out to the user.

Step 4. The user executes schedule 1 m/16/10/18 1830. The meeting is schedule and the person card is changed to reflect the same accordingly.

The following activity diagram summarises what happens when a user executes the ScheduleCommand:

The following sequence diagram shows how the operation itself works.

Design Considerations

Aspect: Where meetings are stored

Alternative 1 (Current choice): The meetings are stored in both the Person model and in the global meeting list UniqueMeetingList.
- Pros: Easy to ensure no clashes occur between meetings.
- Cons: Significant changes need to be made to the model to accomodate this.
Alternative 2: The meetings are stored in only the Person model.
- Pros: Minimal changes to the model required; prevents duplication of data.
- Cons: Difficult to ensure uniqueness of meeting times.
Alternative 3: The meetings are stored in only the UniqueMeetingList.
- Pros: Prevents the duplication of data; easy to ensure no clashes.
- Cons: Would need additional data structures to pair the meeting to the entry.

Aspect: Date storage format

Alternative 1 (Current choice): The date and time is stored as a 10-character string.
- Pros: Allows the setting of a none value, and offers flexibility.
- Cons: Does not utilize the Java API libraries for dates and times.
Alternative 2: The date and time is stored as a DateAndTime object.
- Pros: Ability to use Java API functions for dates.
- Cons: Less flexible as all dates entered must be valid.

Adding a Meeting

Adding a meeting to a person while all persons all listed.
1. Prerequisites: List all persons using the list command. Multiple persons in the list.
2. Test case: schedule 1 m/21/02/18 1430
  Expected: First client is scheduled for a meeting on 21st February 2018, at 1430. Timestamp in the status bar is updated.
3. Test case: schedule 0 m/21/02/18 1430
  Expected: Nothing is updated. Error details shown in the status message. Status bar remains the same.
4. Test case: schedule 1 m/31/02/18 1430
  Expected: Nothing is updated. Error details shown in the status message. Status bar remains the same.
5. Test case: schedule 1 m/21/02/18 2630
  Expected: Nothing is updated. Error details shown in the status message. Status bar remains the same.

Searching by Meetings

Searching for people by meetings.
1. Prerequisites: Two persons in the list. One must have a meeting scheduled on 21st February 2018, and the other must have a meeting scheduled on 23rd February 2018.
2. Test case: meetings 21/02/18
  Expected: The client with the meeting on 21st February 2018 is listed.
3. Test case: meetings 23/02/18
  Expected: The client with the meeting on 23rd February 2018 is listed.
4. Test case: meetings
  Expected: Both clients are listed.
5. Test case: meetings 24/02/18
  Expected: No clients are listed.
6. Test case: meetings 31/02/18
  Expected: Nothing is updated. Error details shown in the status message. Status bar remains the same.