Iskandar Zulkarnaien - Project Portfolio for ORGANice

About the project

This project portfolio serves to showcase my contributions to the development and documentation of ORGANice. The following sections will introduce the ORGANice project and my role in its development.

ORGANice is a team project done by a group of five developers including myself. We are second year Computer Science students from the National University of Singapore. ORGANice was developed as part of CS2103T, an introductory Software Engineering module. ORGANice is a desktop application created to help hospital administration staff manage organ transplants. ORGANice was developed with the assumption that they prefer typing compared to other forms of usage. As such, ORGANice utilises a Command Line Interface - a text-based system where users type in commands to execute tasks rather than clicking buttons. As part of the module, ORGANice is morphed from an existing project, AddressBook-Level3, an address book management application.

This is what ORGANice looks like:

Figure 1. The graphical user interface for ORGANice

These are the main features of ORGANice:

Managing patients, donors and doctors
Matching patients with potential donors
Sorting matches by priority, compatibility and organ expiry date
Finding persons by attributes
Managing administrative work relating to organ transplants

How did I contribute?

My role was to design and implement the find by attribute feature and handle the automatic generation of dummy data on initial application startup. The following sections illustrate the contributions I have made in implementing said features, including the relevant documentation for both users and developers.

Do note the following symbols and formatting used in this document:

This section contains important information.

This section contains a helpful tip!

find A grey highlight (called a mark-up) indicates that this is a command that can be typed into the command box and executed by the application.

Summary of contributions

This section shows a summary of my coding, documentation and other helpful contributions to the team project.

Major Enhancement: I added the ability to search for persons based on their attributes.

What it does: Allows the user to search for specific persons (i.e. patients, doctors and donors) based on their attributes (e.g. name).
Justification: This feature improves ORGANice significantly as a user can look for specific persons quickly rather than having to scroll through the entire list of persons in ORGANice.
Highlights: This feature performs fuzzy matching on the inputted name, NRIC and phone number to allow for relevant search results to be displayed even if the user makes a typo.
Pull Requests: #143, #174, #184

Minor Enhancement: I added NRIC checksum validation to ensure input NRICs are valid.

What it does: Checks that the NRIC input by the user is a valid NRIC.
Justification: This feature is crucial to the functionality of ORGANice as credential correctness is crucial for hospital administrative workflow.
Pull Request: #255

Minor Enhancement: I added dummy data generation for initial startup of ORGANice.

What it does: Generates dummy data consisting of 10 doctors, 20 patients and 20 donors on inital application startup.
Justification: This feature is beneficial for hospitals transitioning to using ORGANice as it provides users with data to test out and familiarise themselves with the various commands available in ORGANice before using it for daily work.
Pull Request: #172

Code contributed: Click here to view my code contributions.

Other contributions:

Git Workflow Management:
- Helped team members resolve Git related issues such as merge conflicts and taught them how to use more complicated features such as rebasing and stashing.
- Helped the team migrate to a branching Git workflow (Issue #39)
- Set up team’s GitHub repository including branch protection and requiring Travis checks and reviews before merging.
Documentation:
- Updated User Guide and Developer Guide to reflect changes to find (Pull Requests #158, #277)
Community:
- Contributed to forum discussions (Examples: #9, #11, #21)
- Reviewed Pull Requests ( #96, #98, #134, #141)

Contributions to the User Guide

Shown below is an extract from our User Guide detailing the usage of the find command. I wrote this section to specifically target the end users who may not be tech savvy.

Finding persons by attributes: `find`

You can use the find command to search for persons whose attributes match your input keywords. A list of matching persons along with the number of exact and possible matches will be displayed.

Format: find PREFIX/KEYWORD (PREFIX/KEYWORD…)

Optional parameters: Multiple keywords per prefix, multiple prefixes in the same find command.

You may wish to reference [List of Attributes], to view the list of available prefixes to search by.

The find command is case insensitive and performs OR matching within a prefix and AND matching between prefixes. It also matches similar looking words to account for possible typos in your keywords. The following example illustrates these concepts:

Figure 2. Find command with multiple prefixes and multiple keywords per prefix.

In Figure 12, you can see that find n/Duncan n/Loinel n/Helen t/patient t/donor shows a list of 44 matches. The two exact matches are listed at the top; those below are possible matches, sorted according to how closely they match your keywords.

'Duncan Chua' and 'Helen Davidson' are among the matched persons due to the fact that Duncan’s name matches either of 'Duncan' OR 'Loinel' OR 'Helen' AND he is also either a 'patient' OR 'donor'. The same is true for Helen. 'Lionel Lim' also appears in the search results as his name is similar to 'Loinel'. Hey, good thing we picked up on that typo or we’d have missed Lionel!

The only exception to this rule is tissue type matching, which uses AND matching within the prefix.

Lets take a look at some examples and pointers showcasing the use of find:

Use case with multiple keywords per prefix
- find n/Laura n/Marisha Ray b/A b/B b/O
  Displays all persons whose name contains either 'Laura' or 'Marisha Ray' and whose blood type is either 'A', 'B' or 'O'.
Use case demonstrating prefix order insensitivity
- find b/A n/Benson Carter b/O n/Alice b/B
  Displays the same result as the preceding example.
Use case demonstrating tissue type finding
- find tt/4,1,2,3
  Displays all persons whose tissue type contains tissues: 4, 1, 2 and 3; in any order.

Looking for exact matches only? No problem! Just replace find with exactFind!

That’s it for this section. Congratulations, you now know how to use the find command!

Contributions to the Developer Guide

Shown below is an extract from our Developer Guide detailing the architecture and execution of the find command. I wrote this section to specifically target new developers with little Software Engineering experience.

Finding feature

This section explains the implementation of the find persons by attributes feature.

Current Implementation

The find feature is facilitated by PersonContainsPrefixesPredicate and FindCommand.

PersonContainsPrefixesPredicate

PersonContainsPrefixesPredicate implements Predicate and is used to test whether a person’s attributes match exactly with at least one of the input keywords in each attribute category.

FindCommand

FindCommand extends Command with a predicate that is used to determine whether a given person should be displayed. It implements Command#execute(Model model) which replaces the predicate of the current model.filteredPersons with the input predicate of ExactFindCommand. This triggers a change in the displayed persons to the list of filtered persons.

Execution Behaviour

The behaviour of FindCommand is consistent with that of other commands as described in [Design-Logic]. Therefore, this section will gloss over higher-level details and instead zoom-in to the behaviour of FindCommand#execute.

FindCommand Execution

Given below is a step by step description of the behaviour of FindCommand#execute:

Step 1: The full list of all persons in ORGANice is retrieved and stored as allPersons.

Step 2: A list of exact matches is obtained by filtering allPersons using PersonContainsPrefixesPredicate.

Step 3: A list containing all persons except exact matches is obtained and fuzzy matching is performed on it.

Step 4: Fuzzy matching uses StringUtil#calculateLevenshteinDistance to filter out possible matches. The matches are then sorted in ascending order of similarity to input keywords.

Step 5: #setDisplayedPersonList is called.

The following sequence diagram illustrates steps 1 to 5:

The above diagram heavily simplifies the execution of #fuzzyMatch as it is further explained in the section below.

Fuzzy Matching

FindCommand#execute performs fuzzy matching between input keywords and person attributes to detect possible matches. This behaviour is facilitated by FindCommand#fuzzyMatch(ArgumentMultimap argMultimap, List<Person> inputList). The behaviour of #fuzzyMatch is detailed in the below activity diagram:

As seen from the above diagram, #fuzzyMatch traverses the inputList of persons and tags each person with a calculated minimum combinedLevenshteinDistance(LD). In the event that no keywords are present, all persons are tagged with an LD higher than the acceptable threshold. Once all persons have been tagged, those persons whose LD exceeds the threshold are removed from the list. The final list is then sorted in ascending order of LD.

Design Considerations

This section will explain the main aspect considered in designing the find by prefix feature.

Aspect: Method of calculating similarity of keywords

Alternative 1 (current choice): Calculate Levenshtein Distance.
- Pros: Able to detect most typos effectively.
- Cons: Creation of requisite costMatrix is computationally expensive and may affect performance for long keywords.
Alternative 2: Use Natural Language Processing Libraries.
- Pros: Will be able to detect typos more effectively.
- Cons: Will take up more system resources.