Hotel

At A Glance

• Individual, stage 3 project
• Due before class, DATE HERE

Introduction

Our company has been contracted to build a booking system for a small hotel. This system will be used by employees who manage bookings and booking data, and will not be available to the general public.

Learning Goals

Reinforce and practice all of the Ruby and programming concepts we've covered in class so far:

• Design a system using object-oriented principles
• Create and instantiate classes with attributes
• Create class and instance methods within our classes
• Write pseudocode and create tests to drive the creation of our code

Objective

For our hotel booking system, we should make a module full of business logic that tracks which rooms are reserved, and at what dates. This should be organized into appropriate classes and methods.

We should use tests to verify that this system works as intended.

We should not build a CLI for this project.

Project Expectations

This project is both a culmination of our Intro to Ruby unit and our first stage 3 project. This means the requirements are more open-ended and ambiguous than previous projects you have worked on. This is intentional. You will be expected to:

• Make decisions on how to structure your classes and methods
• Ask questions when you need clarification
• Understand that the way you implement something may be different than the way your neighbor implements it

It is expected that you will not be able to complete all requirements. The three waves are organized by difficulty and relevance to the learning goals, and should be tackled in order.

Getting Started

We will use the same project structure we used for the previous project. Library code (such as classes) should be in files in the lib folder, and tests should be in files in the test folder.

1. Fork this repository in GitHub
2. Clone the repository to your computer

Verify Setup With Your First Commit

Follow the steps below first to verify that your setup is working. If you cannot get guard to run, a failing test to run, or a test to pass at the beginning, please ask for help before continuing the project.

1. Open a terminal and run the guard command from within the project's root directory (where the Guardfile is)
2. Create a test to check the instantiation of one of your object types (RED)
3. Create the class for the object tested in the step above (GREEN)
4. Use git add, commit and push commands to push your initial code to GitHub

Process Requirements

You should use the following process as much as possible:

1. Write pseudocode
2. Write test(s)
3. Write code
4. Refactor
5. Commit

Your git commit history should provide a clear description of how your code developed, letting the reader know what changed when and why. Making frequent, small commits is essential!

Wave 0: Design Requirements

Before starting work on the functional requirements, create a first and second draft of your project's design.

First Draft: Instructor-led In-Class Design Activity

Complete your first draft of the hotel design by following the instructor-led in-class design activity.

Second Draft

After completing the in-class design activity, click here for the second draft instructions

We have our own first-draft design for this project. We'd like you all to look at our first-draft, compare it with your own, and adjust your own first draft if you'd like.

• A description of our code exists here
• Our code exists here.

Use the two links above to explore the files and answer these questions:

• What classes exist?
  • Why? What are they named, what do they represent, and what state and behavior do they have?
• What tests exist?
• What parts of this design inspires you, and you want to steal?
• What parts of this design are you unsure about, and need to consider again later?
• What parts of this design do you think you can do without?

Spend no more than 1 hour answering those questions and adjusting your project's first draft design. After one hour, get started; don't forget that a useful skill for the programmer is the ability to get started, and adjust in small ways often. Also, remember that you can always refactor later to improve your design!

Functional Requirements

Wave 1: Tracking Reservations

In this wave, write the functionality for the system to track valid reservations, so that a user of the hotel system can make and find valid bookings for their hotel.

Remember: Your job is to only build the classes that store information and handle business logic, and the tests to verify they're behaving as expected. Building a user interface is not part of this project!

User Stories

• As a user of the hotel system...
  • I can access the list of all of the rooms in the hotel
  • I access the list of reservations for a specified room and a given date range
  • I can access the list of reservations for a specific date, so that I can track reservations by date
  • I can get the total cost for a given reservation
  • I want exception raised when an invalid date range is provided, so that I can't make a reservation for an invalid date range

Details

• The hotel has 20 rooms, and they are numbered 1 through 20
• Every room is identical, and a room always costs $200/night
• The last day of a reservation is the checkout day, so the guest should not be charged for that night
• When reserving a room, the user provides only the start and end dates - the library should determine which room to use for the reservation
• For this wave, any room can be reserved at any time, and you don't need to check whether reservations conflict with each other (this will come in wave 2!)

Hints

• These functionalities do not all need to be implemented in the same class
• You might want to investigate Ruby's Date gem

A Hint on Dates

When programming it's generally helpful to convert or validate your data as soon as possible. If you do this when you first read/receive data that means that the rest of your code can assume that you have data in the desired form.

This is a job for driver code.

In this case we are not writing driver code. That means that your code should deal entirely in Ruby Date objects. Your tests should create Date objects and your library code should assume that it's receiving Date objects to start.

When making tests you will want to use something like Date.new(1993, 2, 24) to create a date representing February 24, 1993 (or Date.today for today) instead of trying to parse a string or storing and re-parsing strings internally.

Wave 2: Room Availability

User Stories

• As a user of the hotel system...
  • I can view a list of rooms that are not reserved for a given date range, so that I can see all available rooms for that day
  • I can make a reservation of a room for a given date range, and that room will not be part of any other reservation overlapping that date range
  • I want an exception raised if I try to reserve a room during a date range when all rooms are reserved, so that I cannot make two reservations for the same room that overlap by date

Details

• A reservation is allowed start on the same day that another reservation for the same room ends

Wave 3: Hotel Blocks

If you are not familiar with what a block of hotel rooms, here is a brief description:

A Hotel Block is a group of rooms set aside for a specific group of customers for a set period of time.

Hotel Blocks are commonly created for large events like weddings or conventions. They contain a number of rooms and a specific set of days. These rooms are set aside, and are made available for reservation by certain customers at a discounted rate. These rooms are not available to be reserved by the general public.

User Stories

• As a user of the hotel system,
  • I can create a Hotel Block if I give a date range, collection of rooms, and a discounted room rate
  • I want an exception raised if I try to create a Hotel Block and at least one of the rooms is unavailable for the given date range
  • Given a specific date, and that a room is set aside in a hotel block for that specific date, I cannot reserve that specific room for that specific date, because it is unavailable
  • Given a specific date, and that a room is set aside in a hotel block for that specific date, I cannot create another hotel block that includes that specific room for that specific date, because it is unavailable
  • I can check whether a given block has any rooms available
  • I can reserve a specific room from a hotel block
    • I can only reserve that room from a hotel block for the full duration of the block
  • I can see a reservation made from a hotel block from the list of reservations for that date (see wave 1 requirements)

Details

• A block can contain a maximum of 5 rooms
• When a room is reserved from a block of rooms, the reservation dates will always match the date range of the block
• All of the availability checking logic from Wave 2 should now respect room blocks as well as individual reservations

Non-Functional Requirements

Testing Requirements

• Utilize the test helper file
• Run tests automatically whenever files are added or changed using the guard command
• The final project submission should have 95% code coverage using simplecov

Optional Enhancements

You should not be working on these (or even thinking about them!) until you have fully completed wave 3.

• Add functionality that allows for setting different rates for different rooms
• Read and write CSV files for each piece of data that your system is storing
• Create a CLI to interact with your booking system. Put all of this code in a file main.rb that is separate from your lib code. Working on this optional enhancement should not break the other requirements of this project

Before Submission: refactors.txt Requirement

Usually by the end of a project, we can look back on what we made with a clearer understanding of what we actually needed. In industry, this is a great time to do a refactor of some sort. For this project however, you're off the hook... for the moment. We will be revisiting our Hotel project submissions later on on the course, and you may want to make some changes at that point.

In order to keep track of your current thoughts about design refactoring, as part of project submission, please log down design thoughts with the following process:

1. Create a new file in the project called refactors.txt
2. In that file, make a short list of the changes that you could make, such as naming conventions, etc.
   • These notes will be used by you in a few weeks, so make sure that they are detailed enough that someone else could understand your thinking and follow your directions
   • Commit and push this file to your project repo
3. Do not make any further changes to your code at this time

What we're looking for

You can find what instructors will be looking for in the feedback markdown document.