Sreyans Sipani - Project Portfolio

Effect: Adds a reservation for a room associated with certain customers.
Format: {add-reservation/ar} r/ ROOM_TYPE d/ START_DATE-END_DATE $/ PAYER_INDEX [ c/ MORE_CUSTOMER_INDICIES… ] [ com/ COMMENTS ]

Examples:
Assume current date is 10 May, 2019.

Effect: Displays a reservation list, which lists all the reservations.
Format: {list-reservations/lr}

Examples:

Effect: Edits the fields of an existing reservation in the reservation database.
Format: {edit-reservation/er} INDEX [ r/ ROOM_TYPE ] [ d/ START_DATE-END_DATE] ] [ $/ PAYER_INDEX ] [ c/ MORE_CUSTOMER_INDICES ] [ com/ COMMENTS ]

Examples:

Effect: Deletes a reservation from the reservation database.
Format: {delete-reservation/dr} INDEX

Examples:

Effect: Removes all room reservations from the database.
Format: {clear-reservations/cr}

Examples:

Effect: Displays a reservation list based on the filters given by the user.
Format: {find-reservation/fr} [ id/ IDENTIFICATION_NO ] [ r/ ROOM_TYPE ] [ d/ START_DATE - END_DATE ]

Example:

Effect: Adds a service associated with certain customers.
Format: {add-booking/ab} s/ SERVICE_NAME :/ START_TIME-END_TIME $/ PAYER_INDEX [ c/ MORE_CUSTOMER_INDICES ] [ com/ COMMENTS ]

Examples:

Effect: Displays a booking list, which lists all the bookings made till now. Format: {list-bookings/lb}

Example:

Effect: Edits the fields of a booking in the database.
Format: {edit-booking/eb} INDEX [ s/ SERVICE_NAME ] [ :/ START_TIME-END_TIME ] [ p/ PAYER_INDEX ] [ c/ MORE_CUSTOMER_INDICES ] [ com/ COMMENTS ]

Examples:

Effect: Deletes a booking from the database. Format: {delete-booking/db} INDEX

Example: lb, then delete-booking 2
Deletes the 2nd booking of the booking database

Effect: Removes all service bookings from the database.
Format: {clear-bookings/cb}

Example:

Effect: Displays a booking list based on the filters given by the user.
Format: {find-booking/fb} [ id/ IDENTIFICATION_NO ] [ s/ SERVICE_NAME ] [ :/ START_TIME-END_TIME ]

Example:

In general, when adding any new model and its related commands, you need to work on 3 components compulsorily - Logic, Model and Storage. The UI component is modified based on how you want the user to be able to interact with our newly added model.

You will start by working on the model component. You must create a more specific model which implements the existing Model interface and create a manager for this model. This constitutes the API for our new model how the Logic component will execute the commands related to the model. For Booking, there is a BookingModel interface and a BookingManager class which keeps track of a booking list. An 'observable booking list' is bounded to the UI using listeners so that the UI can be updated as the list changes. While the interface is a means of exposing the API, the manager class links with the system and performs the actions. We also create the relevant class files to represent the model we are implementing. For example, for representing our list of reservations, we create relevant classes like ReservationList, Reservation, DateRange, RoomType, etc.\

Then you need to add the command files and parser files so that the application can parse commands related to the model and execute them. The commands have been separated for different models by adding an interface in the middle. This interface makes sure the correct model is used to execute those commands. For example, there is a CustomerCommand and a BookingCommand interface which implements the Command interface. Moreover the CustomerCommand interface specifies that it uses the CustomerModel to execute itself. Then each command (eg. AddBookingCommand, EditBookingCommand, etc.) implements the BookingCommand interface. This makes sure that only the booking manager can be used to execute these commands as well. You also need to add parser classes for each command you implement (eg. AddBookingCommandParser). These classes are invoked in the HotelManagementSystemParser to get back the CommandResult which is used by the UI.

If the new model needs to be stored, then you also need to define JSON adapted classes to represent these models. The JsonSerializableHotelManagementSystem has a list of JsonAdaptedCustomer and a list of JsonAdaptedBooking and these two lists are saved using seedu.hms.commons.util.JsonUtil. For each model class, you need to define a JSON-adapted class with a toModelType function so that the system can read the data back from the file.

The modifications in the UI for a new model depend heavily on the functionality it provides. For booking and reservations, a panel was added to display all the bookings/reservations which can be filtered based on different parameters. You can see the addition, updating and deletion of bookings in real-time in the UI as has been explained before.

In this section a model is considered to be customizable if an instance of it can be:

Every model/manager has access to the HotelManagementSystem inside which resides all the lists (BookingList, UniqueCustomerList, etc.). These lists have methods to add an item, set or replace an item at a particular index and delete an item. Therefore, when you are implementing a model and its list wrapper (Eg. ReservationList), you must include these functions. You must also define equality between instances of a model created so that it is easy to find an instance and replace it. Include an instance of your list inside the HotelManagementSystem and add a listener to it to automatically update the UI every time the function indicateModified is called. Based on the action, you might want to update the shown list using the updateFiltered#{Model Name}List method. A sequence diagram is given below to make the following more clear.