1. Introduction

1.1. About the Project

Mortago, a desktop application, is a comprehensive mortuary management system. It is a student project from the National University of Singapore (NUS). Mortago is a portmanteau of two Latin words: "mortem" (death) and "curago" (to manage). As its name suggests, Mortago aims to streamline mortuary processes such as updating statuses, keeping track of unclaimed bodies, and generating reports for hospital mortuary managers. The user interacts with MORTAGO using a command line interface (CLI), and it displays a dashboard (Figure 1) that shows bodies, workers and fridges entries.

The interface is responsive to suit different screen sizes. However, due to its detailed interface, it is recommended for larger screen sizes such as desktop monitors. Mortago has a graphical user interface (GUI) created with JavaFX. It is written in Java, and maintains a local storage.

The image below shows where the users can type the commands and where the details are displayed:

Ui
Figure 1. Mortago’s dashboard.

1.2. About the Team

This project was undertaken by a team of five Year 2 computer science undergraduates, including myself, as part of the NUS module CS2103T Software Engineering. For most of us, it was our first time being part of a small-scale software development team. We were tasked to build the application under the contraints that it must be CLI and targets a small user base.

1.3. About My Role

My role was to design the stats, filter, and find features. The following section elaborates on my work in greater detail. Other than engineering these features, I also contributed to the project documentation (user and developer guides). I will be including excerpts of these contributions in the next section.

Before we move there, I would like to highlight the symbols and text formatting that will be used in this document. A grey highlight like stats indicates that this is a command that can be inputted into the command line and executed by the application. Three earlier examples can be seen in this section.

2. Summary of Contributions

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

  • Major enhancement 1: I added the line chart display which shows admissions statistics.

    • What it does: The line chart displays the number of bodies admitted to the mortuary daily over the last ten days. This is the default view. With the stats command, users can toggle between a ten-day, weekly, monthly, or yearly display. Furthermore, any particular week, month, or year can be specified.

    • Justification: It is important for users to know how many bodies are admitted daily as well as the trends for admission. As managers of the mortuary, they can make staffing decisions on various times of the year depending on the trends.

    • Highlights: This feature can be further enhanced by adding more data to the display, for example, another line for bodies claimed daily which can show the average lag time between admission and claim dates.

    • Credits: Support for rendering the line chart was provided by JavaFX.

  • Major enhancement 1: I added the ability to filter entries.

    • What it does: The filter command allows users to filter body or worker entries by any attributes,

    • Justification: This is a necessary feature for a system that intends to manage a lot of data. Sometimes, mortuary managers just need to view entries of a specific kind. They can filter entries by sex, status, cause of death, etc.

    • Highlights: This enhancement affects existing commands and commands to be added in future. It required an in-depth analysis of design alternatives. The implementation too was challenging as it required changes to existing commands.

  • Minor enhancement: I added the ability to find workers or bodies by their name.

    • Justification: Although the previous command can serve the same purpose, the find command is useful for when the user has a specific entry in mind that they want to view as it is a shorter and more efficient command.

  • Code contributed: [via RepoSense]

  • Other contributions:

    • Enhancements to existing features:

      • I wrote additional tests for existing features to increase coverage from % to %. (Pull request: #36)

      • I fixed bugs reported by test users of the application. (Pull requests: #222, #223)

    • Documentation:

      • I contributed to the writing of the User Guide and Developer Guide.(Pull request: #256)

      • I made instructional diagrams for every teammate’s sections that needed such diagrams. (Pull request: #263)

    • Community:

      • I reported bugs and suggestions for other teams in the class (Examples: 1, 2, 3)

3. Contributions to the User Guide

We wrote a User Guide targeted at the users of Mortago. The User Guide containts instructions on how to use the various commands of the application. The following is an excerpt from our Mortago User Guide, showing additions that I have made for the stats and `filter`features.

{start of extract 1: stats command}

View admission statistics: stats

You can view a the statistics of the number of bodies admitted to the morgue over the past 10 days, a specific week, a specific month, or a specific year by entering a stats command with the given format below.

The statistics appear in graphical form as a line-chart on the main page of the application. The line chart is initialised and updated automatically and you do not need to enter a command to see it. By default, the line-chart displayed shows the number of bodies admitted over the past 10 days. You can change the time frame with the stats command.

The following screenshot shows where the stats command should be inputted and where the line chart changes:

)The line chart’s position on the dashboard with respect to the command box. image::statsMonth.png[width="790"]

The following are the correct formats for typing in stats commands, with example usage:

  • To display the last 10 days: stats
    The line chart displays statistics over the last 10 days. The line chart appears as below:

)Line chart displaying the last ten days image::statsTenDays.png[width="790"]

  • To display a specific week: stats /week 25/10/2019
    The line chart displays statistics for the week which contains the specified day. In this case, it is the date 12/10/2019. The line chart appears as below:

)Line chart displaying the week containing the day 25/10/2019 image::statsWeek.png[width="790"]

  • To display a specific month: stats /month 5/2019
    The line chart displays statistics or the month specified. In this case, it is May 2019. The line chart appears as below:

)Line chart displaying the month of October image::statsMonth.png[width="790"]

  • To display a specific year: stats /year 2019
    The line chart displays statistics for the year specified. In this case is it 2019. The line chart appears as below:

)Line chart displaying the year 2019 image::statsYear.png[width="790"]

{end of extract 1}

{start of extract 2: filter command} {end of extract 2}

4. Contributions to the Developer Guide

In addition to a User Guide, we wrote a Developer Guide targeted at developers who are interested in contributing to the project. The Developer Guide showcases my ability to write technical documentation and the technical depth of my contributions to the project. Given below is my contribution to the Developer Guide:

{start of extract 1: implementation of stats command} === Statistics Feature ==== Implementation

The statistics feature appears as a line chart of the number of bodies admitted over the past 10 days (default view) and is facilitated by LineChartPanel. It extends UiPart with an internal storage of the number of bodies admitted per day over the past 10 days. The line chart is part of the user interface and is initialised automatically when Mortago is launched. Users can switch the view to a specified week, month, or view.

In LineChartPanel, four key operations that constructs the line chart and updates it dynamically are implemented, and they are executed in order as described below:

  • LineChartPanel#initialiseTreeMap() — Initialises a tree map that contains the dates as the keys and the number of bodies admitted as the frequency.

  • LineChartPanel#initialiseLineChart() — Creates a Line Chart with Xaxis and Yaxis.

  • LineChartPanel#updateSeries() — Adds data to the series of the line chart based on what is in the tree map.

  • LineChartPanel#updateUponChanged() — If a body is added or removed, the tree map is changed accordingly depending on the date of admission of the body, and the series is updated again.

The above operations are invoked through a wrapper function LineChartPanel#makeLineChart() which is invoked when the user calls LineChartPanel#getLineChart().

The line chart is updated automatically because it takes in an ObservableList<Body> from the AddressBook, so it re-intialises once a change has been detected. The following sequence diagram shows hows adding a body changes the AddressBook, and then how`LineChartPanel` interacts AddressBook to obtain an observable list of bodies, creates a line chart from it, and then passes the line chart to be displayed in MainWindow with dynamic update:

)Sequence diagram showing the dynamic update of the line chart when user adds a new body. image::LineChartAddBodySequenceDiagram.png[]

The user is able to switch the time frame of the line chart between the last ten days or a particular week, month, or year with the stats command (See User Guide). The following sequence diagram shows how the stats command affect the appearance of the line chart:

)Sequence diagram showing the changing view of the line chart when user specifies a different time frame. image::LineChartTimeFrameSequenceDiagram.png[]

Design Considerations

Aspect: How data is stored and updated

The line chart needs data to refer to. Below are two alternatives for how to access the data and update the line chart:

  • Alternative 1 (current choice): Data is not stored. Use a tree map to keep track of bodies and initialise the treemap depending on the given time frame.

The following activity diagram illustrates the current choice for accessing and updating data:

)Activity diagram for how the line chart populate values over the last ten days. image::LineChartActivityDiagram.png[]

  • Pros: Implementation is easy.

  • Cons: Series is regenerated whenever there is a change in time frame. As can be seen from the activity diagram below, the series gets reintialised regardless of whether it will affect a change in the appearance of the line chart.

    • Alternative 2: Store all data in a separate storage class.

  • Pros: No need to reinitialise the treemap everytime a stats command is called.

  • Cons: Implementation requires a lot of storage which may not be tapped on most of the time.

Aspect: The time frame of the line chart

Currently the line chart supports four types of time frames as aforementioned. Below are two alternatives to which users are limited by the time frames:

  • Alternative 1 (current choice): Users can toggle between four types of time frames.

    • Pros: Implementation is easy and simple.

    • Cons: The statistics is limited in meaning if it cannot be compared between other time frames.

  • Alternative 2: Users can print a summary of statistics over a specified period.

    • Pros: The statistics will have more meaning.

    • Cons: Implementation is difficult.

{end of extract 1}

{start of extract 2: manual testing of stats command}

Using the Line Chart and Stats Command

  • Changing the time frame of the line’s chart horizontal axis

    1. Prerequisites: None. The line chart is automatically displayed, with the last ten days as the default time frame.

    2. Test case 1: stats /week 25/10/2019
      Expected: The line chart will show the seven days of the week that contains the day 25/10/2019. 25/20/2019 is a Friday but the line chart will show from Monday to Sunday. The label of the horizontal axis will change to "Day".

    3. Test case 2: stats /month 10/2019
      Expected: The line chart will show the 31 days of month of October, 2019. All dates will be shown on the horizontal axis but will be in a shortened format. The label of the horizontal axis will change to "October 2019".

    4. Test case 3: stats /month 2/2019
      Expected: The line chart will show the 28 days of month of February, 2019. All dates will be shown on the horizontal axis but will be in a shortened format. The label of the horizontal axis will change to "February 2019".

    5. Test case 4: stats /year 2019
      Expected: The line chart will show the 365 days of year 2019. Dates are in a shortened format but not all dates will be shown on the horizontal axis due to space constraint. The label of the horizontal axis will change to be "Year 2019".

    6. Test case 5: stats /year 2016
      Expected: The line chart will show the 366 days of leap year 2016. Not all dates will be shown on the horizontal axis due to space constraint. The label of the horizontal axis will change to be "Year 2016".

    7. Test case 6: stats
      Expected: The line chart will show the last ten days from the current date. The label of the horizontal axis will change to be "Day".

    8. Incorrect stats commands to try: stats 9/2019, stats 2019, stats /week 40/23/2019, stats /month 40/2009 Expected: An error message will appear informing you that the command format is invalid or the date entered is invalid.

  • Testing the dynamism of the line chart by adding and deleting bodies

    1. Prerequisites: The time frame of the line chart should be changed to include the date of admission of the body that is going to be added.

    2. Test case 1: add -b /name Jonathan Bergeson /sex male /dod 14/11/2019 /doa 14/11/2019
      Expected: The y-value for the date 14/11/2019 automatically decreases by 1.

    3. Test case 2: delete -b <ID number of the previously added body>
      Expected: The y-value for the date 14/11/2019 automatically decreases by 1. {end of extract 2}

{start of extract 3: manual testing of filter command}

Filter entries by attributes

  • Filter bodies by a combination of at least on attribute.

    1. Prerequisites: List all bodies for better viewing of the entries.

    2. Test case 1: filter -b /sex female
      Expected: Mortago will list only bodies that are female. The command result will specify how many bodies fit the criteria (0 if none).

    3. Test case 2: filter -b /sex male /status pending police report
      Expected: Mortago will list only bodies that are female and needs a police report written for it. The command result will specify how many bodies fit the criteria (0 if none).

    4. Test case 3: filter -b /sex male /organsForDonation kidney liver /status arrived
      Expected: Mortago will list only bodies that are male, donating kidney and liver, and has the status arrived. The command result will specify how many bodies fit the criteria (0 if none).

    5. Test case 4: filter -b /status hello world
      Expected: Mortago will not list any body and the command result will read "0 bodies listed!" as that status does not exist.

    6. Test case 5: filter /sex male /cod car accident
      Expected: An invalid command error will be thrown and the command result will display it as no flag was given.

    7. Incorrect filter commands to try: filter, filter -b, filter -a Expected: An error message will appear informing you that the command format is invalid.

  • Filter workers by a combination of at least on attribute.

    1. Prerequisites: List all workers for better viewing of the entries.

    2. Test case 1: filter -b /sex female
      Expected: Mortago will list only female workers. The command result will specify how many bodies fit the criteria (0 if none).

    3. Test case 2: filter -w /sex male /designation coroner
      Expected: Mortago will list only male coroners. The command result will specify how many bodies fit the criteria (0 if none).

    4. Test case 3: filter -w /employmentStatus hello world
      Expected: Mortago will not list any body and the command result will read "0 bodies listed!" as that status does not exist.

    5. Test case 4: filter /sex male /employmentStatus full-time
      Expected: An invalid command error will be thrown and the command result will display it as no flag was given.

    6. Incorrect filter commands to try: filter, filter -b, filter -a Expected: An error message will appear informing you that the command format is invalid.

{end of extract 3}