PROJECT: CRM Book

Overview

CRM Book is a desktop application targeted for salespeople. The user interacts with it using a CLI, and it has a GUI created with JavaFX. It is written in Java, and has about 10 kLoC. This application allows salespeople to organize their Leads, Contacts, and Accounts that suits their liking, as well as address problems that symptomatic in the sales industry, such as identifying duplicates.

Summary of contributions

  • Major enhancement: Separated out Leads and Contacts from Persons

    • What it does: supports the rest of the CRM Book by having separate classes for commands.

    • Justification: This feature is core for a CRM as Leads and Contacts are the primary types of people in the CRM.

    • Highlights: This enhancement affects all commands and classes that accessed Persons. It required researching which commands would need to be modified to target a specific type, or could be generalized for both. The implementation too was challenging as it required discovering the many existing classes that needed changing.

    • Credits: The original Person class from which Leads and Contacts were extended.

  • Minor enhancement: Added Accounts

    • What it does: gives Contact a special class for companies.

    • Justification: Accounts are important for existing CRMs as they hold contracts and other aspects when connected to Contacts. These other features are not implemented in CRM Book.

    • Credits: The Tag class as it provided inspiration for saving Accounts into the AddressBook and XML save file.

  • Minor enhancement: Created a convert command to change Leads into Contacts

  • Minor enhancement: Created an editdetails command that adds fields that are unique to Leads or Contacts, and created fields in the UI that reflects the changes.

  • Code contributed: [Functional code] [Test code]

  • Other contributions:

    • Community:

      • Reported bugs and suggestions for other teams in the class

    • Tools:

      • Integrated Travis to the team repo

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.

Editing nonessential details of a person : editdetails

Edits an existing person in the CRM Book.
For Leads, format: editdetails INDEX [c/COMPANY] [i/INDUSTRY] [r/RATING (number from 1 to 5)] [t/TITLE] [w/WEBSITE]

For Contacts, format: editdetails INDEX [c/COMPANY] [d/DEPARTMENT] [t/TITLE]

  • Edits the person at the specified INDEX. The index refers to the index number shown in the last person listing. 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.

Examples:

  • editdetails 1 c/Macrosoft r/4
    For the first person, changes the company to Macrosoft and sets the rating to 4. This person must be a Lead.

  • editdetails 2 d/IT t/Mr.
    Edits the department of the 2nd person to be IT and sets the title to Mr.. This person must be a Contact.

Converting a person : con, convert

Converts an existing Lead in the CRM Book to a Contact. For further description of Leads and Contacts, see the Introduction
Format: con INDEX, convert INDEX

  • Converts the person at the specified INDEX. The index refers to the index number shown in the last person listing. The index must be a positive integer 1, 2, 3, …​

  • If the indicated person is a Contact, an error is thrown

  • This command can be undone and redone as necessary

Examples:

  • convert 2
    Converts the 2nd person in the list to a Contact.

  • con 4
    Converts the 4th person in the list to a Contact.

Adding an Account to a Contact : account

Adds an Account to a Contact.
Format: account INDEX an/ACCOUNTNAME

  • Adds an Account ACCOUNTNAME to the Contact at the specified INDEX. The index refers to the index number shown in the last person listing. The index must be a positive integer 1, 2, 3, …​

  • Contacts can only have one Account. If the Contact already has an Account, it will be replaced.

Examples:

  • account 2 an/Macrosoft
    Adds the Account Macrosoft to the 2nd person in the list

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.

Leads and Contacts feature

Current Implementation

People in the CRM Book were stored under a single class with no options for differentiating between two types of classes.

To implement a CRM Book, Leads and Contacts must be differentiated so that they can each hold different fields like a proper CRM Book. To do so, they currently extend the Person class so that all existing functionality associated with Persons will work with both Leads an Contacts. Unique fields will be given their own classes like the original generic fields like Name and Address.

In a CRM Book, users start by adding Leads, who are people they have not sold to yet. As they begin selling, the people who they have sold to become Contacts.

Many existing commands like AddCommand have been modified to fit the new paradigm so that it only adds Leads.

A new conversion command ConvertCommand has been added to convert Leads into Contacts. The Sequence Diagram is shown:

ConvertSequenceDiagram1

The ConvertCommand class calls the convertPerson method in the ModelManager class and the Sequence Diagram for the resulting steps are shown below.

ConvertSequenceDiagram2

When the user has selected a Contact instead of a Lead, an error is thrown with this code:

public class ConvertCommand extends UndoableCommand {
    @Override
    protected void preprocessUndoableCommand() throws CommandException {
        // ... get list of Persons ...
        try {
            oldLead = (Lead) lastShownList.get(index.getZeroBased());
        } catch (ClassCastException cce) {
            throw new CommandException(MESSAGE_NOT_CONVERTED);
        }
        newContact = createContact(oldLead);
    }
}

It keeps the name, phone, email, address, remarks and tags through the conversion. The company is converted if it exists into an Account. The converted date is set in the Contact.

Design Considerations

Aspect: Implementation of Leads and Contacts

  • Alternative 1 (current choice): Extend the existing Person class

    • Pros: We will not lose any functionality associated with the Person class.

    • Cons: Declarations of Person variables may confuse new developers even as a general class for Leads and Contacts.

  • Alternative 2: Create two new classes Leads and Contacts

    • Pros: Clearly differentiates Leads and Contacts throughout the codebase.

    • Cons: We would have to rewrite most objects to take into account the two new classes.

Aspect: How conversion will work

  • Alternative 1: Just convert the basic information. Let user fill in other fields themselves.

    • Pros: Easy to implement.

    • Cons: User must do extra work.

  • Alternative 2: Smartly detect which fields can be converted and then do so.

    • Pros: User will only need to fix some mistakes in the conversion.

    • Cons: Smart detection and conversion needs work to do.