Online Hotel Reservation System

1
Online Hotel Reservation System

• MSE Presentation 2
• Cem Oguzhan
• February 21, 2005

2
Outline

• Project Overview
• Action Items
• Project Plan
• Architecture Design
• Formal Specification
• Formal Inspection Check List
• Test Plan
• Questions
• Demo (Hotel Reservation System)

3
Project Overview

• Project Statement
• To provide a web site that can allow a user to
  search and reserve a hotel room or cancel his/her
  reservation over the internet at any time.
• Action Items from the last presentation.
• Users can reserve up to three rooms with their
  own room preferences at the time.
• Dynamic price search for rooms.
• Travel agents can request an account to be a
  member to the HRS.

4
Project Plan Cost Estimate

• Current Progress
• 232 total hours (Phase 1 Phase 2)
• 77 hours research
• 78 hours documentation
• 21 hours design
• 56 hours coding
• 800 SLOC
• 25 of implemented features
• 6 Documents

5
Project Plan Cost Estimate

• Productivity
• 800 SLOC / 56 hours 14.2 SLOC/hour
• 6 Documents / 78 hours 0.07 Docs/hour
• Remaining Work
• 800 SLOC / 0.25 3200 SLOC (estimated total)
• 4-5 Documents

6
Project Plan Cost Estimate

• Remaining Effort
• 2400 SLOC / (14.2 SLOC/hour)
• 169 hours or 25 days (7 hours per day)
• 72 hours for documentation
• 11 days

7
Project Plan WBS

• High Level
• Coding/debugging 25 days
• Testing 7 days
• Documentation 11 days

8
Project Plan -WBS

• Deliverables for Presentation 3
• Action Items (documentation)
• User Manual (documentation)
• Component Design (documentation)
• Assessment Evaluation (testing)
• Project Evaluation (documentation)
• References (documentation)
• Technical Inspection Letters (documentation)

9
Project Plan

• Development (2/22 3/31)
• Testing (4/1 4/11)
• Documentation (4/12 4/29)

10
Architecture Design

• The architecture of the HRS is based on 3-tier
  architecture. There are three logical tiers
• the presentation tier.
• the middle tier.
• the data tier.

11
Architecture Design

• The diagram shows 3-tier type of architecture.

12
Architecture Design Presentation Tier

• The presentation-tier for the Hotel Reservation
  System is ASP.NET Web Forms with User Controls.
• Detail of the Presentation Tier

13
Architecture Design Presentation Tier
14
Architecture Design Presentation Tier
15
Architecture Design Presentation Tier
16
Architecture Design Middle Tier
The class diagram above captures middle-tier,
business specific layer, of the Hotel Reservation
System.
17
Architecture Design - Login
18
Architecture Design Making a Reservation
Detail View
19
Architecture Design Canceling a Reservation
20
Architecture Design - Requesting an Account
21
Architecture Design Generating a Report
22
Architecture Design Adding an Hotel
23
Architecture Design Data Tier
24
Architecture Design

• Error Handling
• The full stack trace and requested URL that
  generated the error is written to the Application
  Event Log on Internet Information Services (IIS)
  server
• Security
• The Hotel Reservation System uses ASP.NET Forms
  Authentication to validate users.

25
Formal Specification

• --Custumer and TravelAgent have unique user name
• context User
• inv uniqueUserName
• User.allInstances-gtforAll(u1,u2 u1ltgtu2
  implies u1.userNameltgtu2.userName)
• --Each reservation belongs to one hotel
• Enforce by the multiplicity of association
  HotelReservation
• --Each reservation allocates one room
• Enforce by the multiplicity of association
  ReservationRoom

26
Formal Specification

• --check in date can not be later than check out
  date
• context rReservation
• inv checkInNotBeLaterCheckOut
• r.checkInltr.checkOut
• --room cant be overbook
• context Reservation
• inv overBookRoom
• Reservation.allInstances-gtforAll(r1, r2
  r1.reservationNumber ltgt r2.reservationNumber
  and r1.allocation.roomNumber
  r2.allocation.roomNumber implies
• r1.checkOut lt r2.checkIn or r2.checkOut lt
  r1.checkIn)

27
Formal Specification

• -- A hotel can never have more reservations for a
  date than rooms
• context Hotel
• inv notOverBook
• Date.allInstances-gtforAll(dHotel.allInstances-
  gt
• forAll(h h.theReservation-gt
• select(h.theReservation.dates-gtincludes(d))-gt
• size lt h.theRoom-gtsize ) )
• -- each hotel is located at one city and state
• context Hotel
• inv oneLocation
• Hotel.allInstances-gtforAll(h1,h2 h1 h2
  implies h1.city h2.city and h1.state
  h2.state)
• --hotel star rating should be between 1-5
• context Hotel
• inv starRating
• Hotel.allInstances-gtforAll(h h.rating gt0 and
  h.rating lt 6)

28
Formal Specification

• verifyLogin(userNameString,passwordString)Boole
  an User.allInstances-gt
• exists(uUser u.userName userName and
  u.password password)
• -- update the customer account
• context CustomerupdateAccount(userNameString,e
  mailString,passwordString,firstNameString,lastN
  ameString,cardTypeString,cardNumberInteger,expe
  rationDateInteger,phoneString,addressString,cit
  yString,stateString,zipString)Boolean
• --the customer should be exist and login
• preverifyLogin(userName,password)
• --the customer's userName can not be updated and
  userName of old customers record are not changed
• postCustomer.allInstances.userName
  Customer.allInstances.userName_at_pre
• postCustomer.allInstances-gtselect(cCustomer
  c.userName ltgtuserName)-gtforAll(cCustomer
  c.email c.email_at_pre and c.password
  c.password_at_pre and c.firstName c.firstName_at_pre
  and c.lastName c.lastName_at_pre and c.cardType
  c.cardType_at_pre and c.cardNumber
  c.cardNumber_at_pre and c.experationDate
  c.experationDate_at_pre and c.phone c.phone_at_pre
  and c.address c.address_at_pre and c.city
  c.city_at_pre and c.state c.state_at_pre and c.zip
  c.zip_at_pre)
• --only the customer's information is updated
• postCustomer.allInstances-gtselect(cCustomer
  c.userName userName)-gtforAll( cCustomer
  c.email email and c.password password and
  c.firstName firstName and c.lastName lastName
  and c.cardType cardType and c.cardNumber
  cardNumber and c.experationDate experationDate
  and c.phone phone and c.address address and
  c.city city and c.state state and c.zip
  zip)

29
Formal Specification

• --add new hotel
• context HotelnewHotel(hotelIDString,
  nameString,addressString, cityString,
  stateString, phoneString, ratingInteger)Boolea
  n
• --pre the admin is logined
• --the hotel is not exist
• preHotel.allInstances-gtforAll(hHotel
  h.hotelID ltgt hotelID)
• --existing hotels record are not changed only a
  new hotel is added
• postHotel.allInstances.hotelID
  Hotel.allInstances.hotelID_at_pre-gt
• including(hotelID)
• postHotel.allInstances.name
  Hotel.allInstances.name_at_pre-gtincluding(name)
• postHotel.allInstances.address
  Hotel.allInstances.address_at_pre-gt
• including(address)
• postHotel.allInstances.city
  Hotel.allInstances.city_at_pre-gtincluding(city)
• postHotel.allInstances.state
  Hotel.allInstances.name_at_pre-gtincluding(state)
• postHotel.allInstances.phone
  Hotel.allInstances.name_at_pre-gtincluding(phone)
• postHotel.allInstances.rating
  Hotel.allInstances.rating_at_pre-gtincluding(rating)

30
Formal Specification

• --make a reservation
• context ReservationmakeReservation(rReservatio
  n)
• --prer.theUser.verifyLogin(r.theUser.userName,r.
  theUser.password)
• --pre Reservation.allInstances-gtexcludes(r)
• --postReservation.allInstances.reservationNumber
  Reservation.allInstances.reservationNumber_at_pre
  -gt
• including(r.reservationNumber)

31
Formal Inspection Check List

1. The documentation follows MSE portfolio standard
   which is describe at http//www.cis.ksu.edu/sdelo
   ach/mse/portfolio.htm
2. Every requirement has only one clear
   interpretation.
3. The requirements of the system are consistent .
4. The architecture of the system is sufficiently
   clear from the documents and diagrams.
5. The architecture design implements all
   specification and requirements.
6. The symbols used in the class diagrams conform to
   the UML standards.
7. The symbols used in the sequence diagrams conform
   to the UML standards.
8. The class diagrams have a corresponding
   description provide in the architectural design
   document.
9. The descriptions of all class diagrams are clear
   and make sense.
10. All classes in the HRS are found in the USE
    model.
11. The role names and multiplicities in the USE
    model match correctly to UML diagrams of the HRS.
12. The operations in the USE model match with the
    methods of the corresponding class diagrams of
    the HRS.

32
Test Plan

• Unit Testing with TestSharp2004
• Performance Testing with JMeter

33
Test Plan test cases

• Search a room
• Login
• Crate a new customer account
• Apply for an account
• Generate a report
• Cancel a reservation
• Add/Update a Hotel
• Add/Update a Room
• Approve/Disapprove travel agent account

34
Questions
35
Demo