1. PROJECT: One Life

1.1. Overview

This project portfolio details my key contributions to Project One Life.

One Life is a desktop medical management application designed as part a project for a software engineering module that I took in National University of Singapore (NUS). Originally an addressbook application with simple functions such as adding, editing, deleting and searching for contacts, my team and I have expanded and almost doubled its functionality, morphing it into an application that can support and improves the efficiency of performing administrative task in the medical sector (i.e. hospitals or medical centres).

Some of the features that we have added includes, but are not limited to:

  • Able to schedule appointments between patients and doctors

  • Able to update medical records of patients

  • Able to be retrieve the availability status of all doctors at any point in time, base on their schedule

  • Able to enter commands using the Intuitive Command Prompt feature that is more user-friendly as compared to the default Command Line Interface (CLI)

  • Able to effectively search for a group of/specific person in view of the many different attributes a patient or a doctor has (e.g. medical department, medical records, appointments, nric, etc)

1.2. Summary of Contributions

  • Major enhancement: added the ability to be retrieve all doctor’s availability status.

    • What it does: This allows the user to view the the availability status of each doctor at the moment. Alternatively, the user can choose to retrieve a list of doctors who are free/available at a given date and time, base on their schedule.

    • Justification: This feature improves the product significantly because a user can easily retrieve the data of each doctor, and more importantly the current availability status of each doctor. Since this is a hospital management application that will be used by nurses or medical administrative staff, in cases of a medical emergency or when a doctor is required, the user can easily know which doctors are available at the moment to help/address the medical situation. Alternatively, this feature also allows the user to know which doctors are available to be activated for stand-by or other medical needs, at a specific date and time.

    • Highlights: This enhancement improves this application’s ability to serve as a hospital management application as it provides real time update of the availability status of each doctor. The implementation too was challenging as it required addition of new event handlers to facilitate propagation of information stored in the backend, to the frontend i.e. Graphical User Interface(GUI) where the information is processed and displayed to the user.

  • Minor enhancement:

    1. Changed the existing add command such that it facilitates adding of doctors and patients separately.

    2. Added a switch command to facilitate switching between the doctor’s and patient’s database.

    3. Added a profile page to the GUI that displays all the information belonging to the selected patient/doctor.

    4. Updated the existing clear command and added a new clearall command in view of having different database for different people (i.e. patients and doctors).

  • Code contributed: [Functional code] [Reposense]

  • Other contributions:

    • Project management:

      • Managed releases v1.1 - v1.4 (4 releases) on GitHub

    • Enhancements to existing features:

      • Updated the GUI layout (Pull requests #54, #116, #124, #204)

      • Wrote additional tests for existing features to increase coverage (Pull requests #116, #129)

    • Documentation:

      • Did cosmetic tweaks to existing contents of the User Guide: #14 #221

    • Community:

      • Reviewed Pull Requests (PRs) of other team members (with non-trivial review comments): #53, #71, #119

      • Reported bugs and suggestions for other members in the team (Pull Requests: #119)

      • Updated team member’s code to remove errors/bugs detected when running test codes against the program (Pull requests #34, #76)

1.3. 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.

1.4. Retrieving a list of available doctors : avail

Retrieves a list of all the doctors available at that moment or base on the date and time period indicated by the user.

Format: avail [d/DATE] [st/START TIME] [et/END TIME]

  • Date is formatted as DD.MM.YYYY and is dot separated. e.g. 7.11.1996 is the 7th of November 1996

  • Both start and end time uses the 24-hour clock time. e.g. 1300 is 1pm

  • End Time should be the same if not a later time than the start time

  • Date and Time (start and end time) are optional parameters

If no date is specified by the user, the system would use the current date by default. Similarly, if neither start nor end time is specified by the user, the system would use the current time as an input for both start and end time.
There is a 1 minute buffer time allocated for doctors after the end of their appointments. This means that if a doctor has an appointment from 1100 to 1200, the doctor will be considered unavailable even at the time 1201.
Inputs for both start and end time should either be both present or both absent. There should not be an end time without there being a start time specified, and vice versa.

Examples:

avail
List all doctors available at the moment (i.e. the date and time when the command is executed), as shown in the figure below:

avail
Figure 1. Display available doctors at current datetime

avail d/24.11.2018 List all doctors available on the 24th November 2018, at the time when this command is executed, as seen in the figure below:

avail2
Figure 2. Display available doctors on 24th November

avail d/24.11.2018 st/1200 et/1300 Lists all doctors available from 12pm to 1pm, on the 24th November 2018, shown in the diagram below:

avail3
Figure 3. Display available doctors base on the given date and time
This command will not work should the user be viewing the patient’s database, since this command applies only for doctors. In this case, executing this command will throw a message to prompt the user to switch the current active database to either the doctor’s database or the combined database containing both patients' and doctors' data.

1.5. Switching between different database : switch

Switches between the three different database available i.e. 1. doctor, 2. patient, 3. doctor and patient.
Format: switch r/ROLE

  • The active database displayed is switched to that of the specified ROLE.

  • ROLE is the role of the person (patient or doctor).

ROLE is case-insensitive and it accepts only three different parameters as follows:
1. Doctor
2. Patient
3. All
Adding a person belonging to a different database is allowed but you would not be able to view it.
E.g. Adding a new patient while viewing the doctor’s database.

Examples:

  • switch r/Doctor
    Switches over to display the doctor’s database as shown in the figure below:

switchDoc
Figure 4. Upon switching to doctor’s database

  • switch r/Patient
    Switches over to display the patient’s database as shown in the figure below:

switchPatient
Figure 5. Upon switching to patient’s database

  • switch r/All
    Switches over to display a combined view of both patient’s and doctor’s database, shown in figure below:

switchAll
Figure 6. Upon switching to the combined database of both patient and doctor

1.6. 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.

1.7. Display doctor’s current availability feature

1.7.1. Current implementation

The display of each doctor’s current availability is facilitated by PersonProfilePage, Doctor, AppointmentManager. Given below is an example usage scenario of how the information is generated and propagated to be displayed in the PersonProfilePage at the final stage.

Step 1. The user launches the application for the first time. The MainWindow will be initialized.

Step 2. The user then selects one of the doctors to view his/her profile via the PersonProfilePage.

Step 3. This then loads the PersonProfilePage that displays all of the person’s particulars, be it a doctor or patient. In the event that this PersonProfilePage belongs to a doctor, it calls the method Doctor#currentAvailStatus to retrieve information on the doctor’s current availability.

Step 4. Next, upon calling the method Doctor#currentAvailStatus, a helper method in AppointmentManager, called AppointmentManager#isAnyAppointmentOngoing executes.

Step 5. AppointmentManager retrieves the current locale date and time from our Date and Time class and compare the current time with all the scheduled appointments that the doctor has, and determines if the doctor is currently available.

Step 6. The status information generated in AppointmentManager is propagated back up to the PersonProfilePage which then sets a badge (available/busy) to reflect the availability status of that doctor.

Step 7. As long as the user remains on the same PersonProfilePage, this method continues to run in the background, providing real time update of the doctor’s availability at that point in time.

The following sequence diagram summarizes what happens when a user launches the application:

DisplayDoctorAvailabilitySequenceDiagram
Figure 7. Sequence diagram for displaying of doctor’s availability status feature

1.7.2. Design considerations

This section describes the pros and cons of the current and other alternate implementations of the doctor’s availability feature.

Aspect: How to display each doctor’s availability

  • Alternative 1 (current choice): A badge in each doctor’s PersonProfilePage display that shows his/her current availability.

    • Pros: Provides convenience for the user to refer to since the badge is always on the display.

    • Cons: Limits to only checking and viewing the availability status of one doctor at a time, thus will not be able to get a consolidated list/view of all doctors who are available or busy at the moment.

  • Alternative 2: A separate command that the user can call upon to look up the current availability of all doctors.

    • Pros: Allows the user to call this method repeatedly/when needed and the user will be provided with the latest information.

    • Cons: Raises a need to have a separate command dedicated to this feature which may not be necessary and not as convenient as compared to having a badge that is on the display at all times and will auto-update itself. Also, this adds on to the list of commands that the user has to get familiar with.

Aspect: How to update the status of each doctor’s availability

  • Alternative 1 (current choice): A function that will refresh the badge every few seconds.

    • Pros: Provides accurate information and real time update on the doctor’s availability and it is easy to implement. Given below is a code snippet of how this feature is implemented:

       if (person instanceof Doctor) {
     setAvailabilityOfDoctor();
     animationTimer.start(); // Updates availability badge of doctor every second
                             // to reflect real time status.
 } else {
     assert person instanceof Patient;
     animationTimer.stop();
     hideDoctorFields();
 }

    • Cons: Affects the performance of the application due to this function continuously running in the background.

  • Alternative 2: Updates the status/badge only on launch of application and only when there is a change in information stored in the database.

    • Pros: Offers an easier implementation method.

    • Cons: Does not auto-update the information and thus the information will be outdated and unreliable.