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 Security
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->forAll(u1,u2 | u1<>u2 implies u1.userName<>u2.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 r:Reservation
inv checkInNotBeLaterCheckOut:
r.checkIn<r.checkOut
--room can’t be overbook
context Reservation
inv overBookRoom:
Reservation.allInstances->forAll(r1, r2 | r1.reservationNumber <> r2.reservationNumber and r1.allocation.roomNumber = r2.allocation.roomNumber implies
r1.checkOut <= r2.checkIn or r2.checkOut <= r1.checkIn)

27. Formal Specification
-- A hotel can never have more reservations for a date than rooms
context Hotel
inv notOverBook:
Date.allInstances->forAll(d|Hotel.allInstances->
forAll(h| h.theReservation->
select(h.theReservation.dates->includes(d))->
size <= h.theRoom->size ) )
-- each hotel is located at one city and state
inv oneLocation:
Hotel.allInstances->forAll(h1,h2 | h1 = h2 implies h1.city = h2.city and h1.state = h2.state)
--hotel star rating should be between 1-5
inv starRating:
Hotel.allInstances->forAll(h | h.rating >0 and h.rating < 6)

28. Formal Specification
verifyLogin(userName:String,password:String):Boolean =User.allInstances->
exists(u:User | u.userName = userName and u.password = password)
-- update the customer account
context Customer::updateAccount(userName:String, String,password:String,firstName:String,lastName:String,cardType:String,cardNumber:Integer,experationDate:Integer,phone:String,address:String,city:String,state:String,zip:String):Boolean
--the customer should be exist and login
pre:verifyLogin(userName,password)
--the customer's userName can not be updated and userName of old customers’ record are not changed
post:Customer.allInstances.userName =
post:Customer.allInstances->select(c:Customer | c.userName <>userName)->forAll(c:Customer | c. = and c.password = and c.firstName = and c.lastName = and c.cardType = and c.cardNumber = and c.experationDate = and c.phone = and c.address = and c.city = and c.state = and c.zip =
--only the customer's information is updated
post:Customer.allInstances->select(c:Customer |c.userName = userName)->forAll( c:Customer | c. = 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 Hotel::newHotel(hotelID:String, name:String,address:String, city:String, state:String, phone:String, rating:Integer):Boolean
--pre: the admin is logined
--the hotel is not exist
pre:Hotel.allInstances->forAll(h:Hotel | h.hotelID <> hotelID)
--existing hotels record are not changed only a new hotel is added
post:Hotel.allInstances.hotelID =
including(hotelID)
post:Hotel.allInstances.name =
post:Hotel.allInstances.address =
including(address)
post:Hotel.allInstances.city =
post:Hotel.allInstances.state =
post:Hotel.allInstances.phone =
post:Hotel.allInstances.rating =

30. Formal Specification --make a reservation
context Reservation::makeReservation(r:Reservation)
--pre:r.theUser.verifyLogin(r.theUser.userName,r.theUser.password)
--pre: Reservation.allInstances->excludes(r)
--post:Reservation.allInstances.reservationNumber =
including(r.reservationNumber)

31. Formal Inspection Check List
The documentation follows MSE portfolio standard which is describe at
Every requirement has only one clear interpretation.
The requirements of the system are consistent .
The architecture of the system is sufficiently clear from the documents and diagrams.
The architecture design implements all specification and requirements.
The symbols used in the class diagrams conform to the UML standards.
The symbols used in the sequence diagrams conform to the UML standards.
The class diagrams have a corresponding description provide in the architectural design document.
The descriptions of all class diagrams are clear and make sense.
All classes in the HRS are found in the USE model.
The role names and multiplicities in the USE model match correctly to UML diagrams of the HRS.
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