PROJECT: Insurelytics

InsurelyticsLogo

Overview

Insurelytics is a desktop client management application for insurance agents. Insurelytics facilitates the tracking of client and policies, and also generates statistical analytics to provide insights for the insurance agent. The user interacts with it using a CLI and has a GUI created with JavaFX. It is written in Java, and has about 85kLoC.

Summary of contributions

  • Major enhancement: added features to complement input validation to ease the correction of invalid commands

    • What it does:

      • Allows merging of duplicate profiles and policies

      • Gives suggestions for incorrectly entered command words.

      • Checks for valid NRICs, phone numbers and email address and returns any valid contact details

    • Justification:

      • Merging: improves the product significantly because a user can add new profiles/policies without needing to check for duplicates. Specifically, the user does not have re-enter the data that has already been keyed in and also does not have to compare the different fields between the original profile/policy and the new profile/policy and craft another edit command to update the profile/policy from scratch.

      • Command suggestions: makes it easier and faster to rectify typing errors. The program automatically updates the incorrect command word with a suggested valid command word without requiring users to do so on their own, which would make it more convenient especially for those who do not remember the correct command word.

      • Information verification: helps the user obtain the contact details of the person with invalid details quickly so that he/she can contact the person to verify the information

    • Highlights: this enhancement affects existing commands and commands to be added in the future. The list of command words and prefixes has to be updated when new commands are added for the suggestion of commands. Moreover, the information used to create a duplicate profile/policy has to be stored to carry out a merge process and hence made the design process challenging.

  • Minor enhancement: added a command to turn suggestions on and off.

  • Code contributed: [function and test code]

  • Other contributions:

    • Project management

      • In charge of testing and scheduling

      • Set milestones and deadlines for the team

    • Enhancements to existing features:

      • Added right panel to GUI (Pull requests [#109])

      • Added classes for Policy and for new Person Fields (Pull requests [#75])

      • Implemented command to add policy and wrote tests for the command (Pull requests [#75], [#93])

      • Implemented command to expand profiles and policies onto right panel (Pull requests [#109])

    • Documentation:

      • Added the new basic commands to User Guide: [#75]

    • Community:

      • PRs reviewed (with non-trivial review comments): [#95], [#70]

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.

Incorrect NRIC Alert

Returns an error message to inform the user of an invalid NRIC. The contact number and/or email address is returned if present.

Examples:

add n/John Doe ic/Q9999999J p/98765432 e/johnd@example.com a/John street, block 123, #01-01 dob/12.09.1980 g/Male

Expected Output:

This is not a valid Singapore Identification number.
NRICs should only contain alphanumeric characters. It should start with S, T, F or G followed by 7 numerical numbers and a checksum letter.
You might want to contact John Doe
PHONE: 98765432
EMAIL: johnd@example.com

Incorrect Contact Number Alert

Returns an error message to inform the user of an invalid contact number. The email address is returned if present.

Examples:

add n/John Doe ic/S9999999J p/48765432 e/johnd@example.com a/John street, block 123, #01-01 dob/12.09.1980 g/Male

Expected Output:

Only Singapore phone numbers are allowed. (e.g. 88887541, +65 98753573, +6565241234
You might want to contact John Doe
EMAIL: johnd@example.com

Incorrect Email Address Alert

Returns an error message to inform the user of an invalid email address. The phone number is returned if present.

Examples:

add n/John Doe ic/S9999999J p/98765432 e/@example.com a/John street, block 123, #01-01 dob/12.09.1980 g/Male

Expected Output:

Emails should be of the format local-part@domain and adhere to the following constraints:
1. The local-part should only contain alphanumeric characters and these special characters, excluding the parentheses, (!#$%&'*+/=?`{|}~^.-) .
2. This is followed by a '@' and then a domain name. The domain name must:
    - be at least 2 characters long
    - start and end with alphanumeric characters
    - consist of alphanumeric characters, a period or a hyphen for the characters in between, if any.
You might want to contact John Doe
PHONE: 98765432

Incorrect Command Suggestions

Returns an error message and a suggestion of a correct command when a command is typed incorrectly.

Examples:

dlete 2

Expected Output:

dlete is not recognised. Did you mean: delete 2?
Suggestions may be slow for longer commands. Efficiency will be improved in v2.0.

The input will automatically be updated to the suggested command.

Turning Command Suggestions On and off : suggestion

Switches suggestions for invalid commands on or off.

Format: suggestion [ON/] [OFF/]

Examples:

suggestion ON/

Expected Output:

Suggestions have been switched on.

Duplicate profile alert

Returns an error message of an existing person and will attempt to merge the profiles. For each different attribute, there will be a prompt to suggest a change from the original attribute to the new one.

Examples:

add n/John Doe ic/S9999999J p/98765432 e/johndoe@example.com a/John street, block 123, #01-01 dob/12.12.1992 g/Male

add n/John Doe ic/S9999999J p/91234567 e/johndoe@example.com a/John street, block 123, #01-01 dob/12.12.1992 g/Male

Expected Output:

This person already exists in the address book
John Doe
NRIC: S9999999J; Phone: 98765432; Email: johndoe@example.com; Address: John street, block 123, #01-01; Date of Birth: 12 December 1992; Gender: Male
Policies: [Health Insurance][Fire Insurance]
Tags: [diabetic][high blood pressure]
Your input:
John Doe
NRIC: S9999999J; Phone: 91234567; Email: johndoe@example.com; Address: John street, block 123, #01-01; Date of Birth: 12 December 1992; Gender: Male
Do you wish to edit this person's profile?
Please press enter or 'yes' to proceed or 'no' to skip.

User may input yes or press enter to proceed with the merge and no to skip the merge. Further prompts will be provided if user inputs yes or presses enter.

Do you wish to edit this person's PHONE?
Original: 98765432
Input: 91234567
Please press enter or 'yes' to proceed or 'no' to skip.

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.

Merging Feature

Implementation

The merging mechanism is facilitated by abstract classes MergeCommand, DoNotMergeCommand, MergeConfirmedCommand and MergeRejectedCommand and their child classes, which implement the merging of profiles and policies respectively. These classes extend Command. The child classes of MergeCommand are MergePersonCommand and MergePolicyCommand. A MergePersonCommand object will store the Person created by the input and the corresponding Person that is stored in the model. Additionally, the main crucial operations implemented by this class are:

  • MergeCommand#getDifferences() — Finds all the different fields between the input person and the original person.

  • MergeCommand#removeFirstDifferentField() — Removes the first different field in the list of differences. This method is called after a merge decision has been input by the user and executed.

  • MergeCommand#getNextMergeFieldType() — Returns the type of the field for the next merge.

  • MergeCommand#onlyOneMergeLeft() — Checks whether there is only one merge left.

The implementation of MergePolicyCommand is similar.

The child classes of MergeConfirmedCommand are MergePersonConfirmedCommand and MergePolicyConfirmedCommand, while the child classes of MergeRejectedCommand are MergePersonRejectedCommand and MergePolicyRejectedCommand. They all implement #execute(Model). Additionally, these classes implement an #isLastMerge() command to indicate if this is the last possible merge for the entity being merged.

AddressBookParser stores a boolean flag to indicate whether a merge is currently taking place. When it is set as true, all other commands will not be parsed and will be treated as invalid commands. The AddressBookParser object also stores the MergeCommand object during a merge process. This object is then used by MergeConfirmedCommand objects and MergeRejectedCommand objects in their execution.

MergeClassDiagram

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

Step 1. The user adds a duplicate profile. The AddCommand will throw a DuplicatePersonWithMergeException during its execution. This exception is thrown if there is at least one different field between the input person and the original person stored in the model. Else, a DuplicatePersonWithoutMergeException will be thrown. The DuplicatePersonWithMergeException will finally be caught in the CommandBox. UI outputs the error message and a prompt to start a merge. CommandBox then constructs two command strings: one to proceed with the merge and one to reject the merge. This is done via #standByForMerge(String, String). This string is then stored.

Step 2. The user inputs yes or presses enter to proceed with the merge. CommandBox then calls CommandExecutor#execute() to execute the merge command it constructed previously. When the command is being parsed in the AddressBookParser object, a new MergeCommand object is created and stored. The isMerging flag is also set to true. The execution of this command then returns a CommandResult that prompts the next merge.

Step 3. The user inputs yes or presses enter to update the field that was displayed in the prompt. The AddressBookParser parses the input and creates a new MergePersonConfirmedCommand object. The MergePersonConfirmedCommand object obtains information for the merge from the MergeCommand object that was passed in as a parameter in the constructor. In the execution, a new EditCommand is created and EditCommand#executeForMerge() is used to update the person in the model. If the MergePersonConfirmedCommand#isLastMerge returns false, MergeCommand#removeFirstDifferentField is called and the command result then shows a success message and the next prompt.

This process is shown in the sequence diagram below.

MergeSequenceDiagram
If the user inputs an invalid command, the prompt will be displayed again along with an error message.

Step 4. The user inputs no to reject the update of the field that was displayed in the prompt. The input gets parsed in the AddressBookParser object and creates a new MergePersonRejectedCommand. If it is not the last merge, MergeCommand#removeFirstDifferentField is called. The command result then shows the next prompt. Else, it will show a success message of successfully updating the profile.

This is repeated until all merges have been prompted.

MergeActivityDiagram

Design Considerations

Aspect: How merge command executes

  • Alternative 1 (current choice): Stores the MergeCommand object in the AddressBookParser to be accessed by MergeConfirmedCommand and MergeRejectedCommand objects.

    • Pros: Finding of different fields is only executed once and can be used by future commands.

    • Cons: More coupling between MergeCommand and other classes.

  • Alternative 2: Update the field in the command string and pass it on in the command result.

    • Pros: Less coupling between MergeCommand and other classes.

    • Cons:

      • User has to see the updated command (information that user does not need to see is displayed).

      • Command still has to be stored somewhere to be accessed by other future merge commands.

Use case: Merging a duplicate person with different fields

MSS

  1. User requests to add a person.

  2. Insurelytics indicates that this person already exists and prompts a merge.

  3. User indicates whether or not to edit this profile.

  4. A different field is displayed and asks the user whether or not to update this field.

  5. Steps 3 and 4 repeat until decisions whether or not to merge different fields have been completed.

    Use case ends.

Extensions

  • *a. User indicates to stop the merging process.

    • 3a1. The user inputs an invalid command.

    • 3a2. The Insurelytics indicates an error and prompts the merge again.

      Use case resumes at 4.