PROJECT: Morpheus

Overview

Morpheus is a desktop application used for hotel management. The user interacts with it using a CLI, and it has a GUI created with JavaFX. It is written in Java, and has about 15 kLoC.

Summary of contributions

  • Major enhancement: added the ability to show and switch between tabs

    • What it does: allows the user to quickly navigate between tabs.

    • Justification: This feature improves the product significantly because a user need to work with multiple type of data and the app should provide a convenient way to traverse between them.

    • Highlights: This enhancement affects existing commands and commands to be added in future. It required an in-depth analysis of design alternatives. The implementation was challenging as existed implementation only accounted for 1 tab.

  • Minor enhancement: modify old search command to accommodate new needs.

  • Code contributed: [Functional code]

  • Other contributions:

    • Project management:

      • Managed releases v1.2 - v1.4 (3 releases) on GitHub

    • Enhancements to existing features:

      • Updated the GUI (Pull requests #69)

      • Wrote additional tests for existing features(Pull requests #181)

    • Documentation:

      • Document for implementation: #92, #232

    • Community:

      • PRs reviewed (with non-trivial review comments): #71, #85

      • Reported bugs and suggestions for other teams in the class (examples: 1, 2, 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.

Switching between tabs : switch(Johnny)

If you want to switch to a new tab and view all the data on the specified tab, use the command switch .

Format:: switch TAB_NAME

TAB_NAME must be one of welcome, guest, room, booking, service, bill

Examples:

  • switch guest

Result: Switches to and shows all entries on guest tab.

Finding guests: findguest (Johnny)

If you want to find guests using their names or id, use the commmand findguest.

Format: findguest [n/NAME] …​ [n/NAME] [i/ID] …​ [i/ID]

- Name must be an exact match.
- The order of the keywords does not matter. e.g. n/Alice i/A10 is same as i/A10 n/Alice.
- Persons matching at least one keyword will be returned.

Examples:

  • findguest i/A0000000 n/Alice

Result: Shows persons with name: Alice or ID: A1000000

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.

UI component (Johnny)

UIDiagram
Figure 1. Structure of the UI Component

API : Ui.java

The UI consists of a MainWindow that is made up of parts e.g.CommandBox, RoomListPanel, PersonListPanel, WelcomePanel etc. All these, including the MainWindow, inherit from the abstract UiPart class.

The UI component uses JavaFx UI framework. The layout of these UI parts are defined in matching .fxml files that are in the src/main/resources/view folder. For example, the layout of the MainWindow is specified in MainWindow.fxml

The UI component,

  • Executes user commands using the Logic component.

  • Listens for changes to Model data so that the UI can be updated with the modified data.

  • Receive command result and change user view accordingly.

Below is diagram for how UI extract command result for changing view.

commandSwitchUi
Figure 2. Command work flow for MainWindow

FindGuestCommand

Implementation

Currently this command only support searching for full name or/and id number.

The following steps show how the search guest feature works:

  1. The search command from the user is parsed into a list of pattern contained in the search command.

  2. The command then executes and filters the guest list based on the patterns.

The diagram below show how the search command store its pattern.

FindGuestCommand
Figure 3. Class diagram for FindGuestCommand

The diagram below shows the execution of the command:

SearchWorkflow
Figure 4. Activity Diagram of Search Feature
Design Considerations

  • Alternative 1 (current choice): Store pattern as list of name and id.

    • Pros: Simpler to test and understand.

    • Cons: Difficult to extend the implementation.

  • Alternative 2: Store pattern as a combination of Predicate.

    • Pros: Easy to implement and add more complicated pattern.

    • Cons: Harder to test, more prone to error.