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 Authenticationto 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 context Hotel 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 context Hotel 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,email: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 = Customer.allInstances.userName@pre post:Customer.allInstances->select(c:Customer | c.userName <>userName)->forAll(c:Customer | c.email = c.email@pre and c.password = c.password@pre and c.firstName = c.firstName@pre and c.lastName = c.lastName@pre and c.cardType = c.cardType@pre and c.cardNumber = c.cardNumber@pre and c.experationDate = c.experationDate@pre and c.phone = c.phone@pre and c.address = c.address@pre and c.city = c.city@pre and c.state = c.state@pre and c.zip = c.zip@pre) --only the customer's information is updated post:Customer.allInstances->select(c:Customer |c.userName = userName)->forAll( c:Customer | 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 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 = Hotel.allInstances.hotelID@pre-> including(hotelID) post:Hotel.allInstances.name = Hotel.allInstances.name@pre->including(name) post:Hotel.allInstances.address = Hotel.allInstances.address@pre-> including(address) post:Hotel.allInstances.city = Hotel.allInstances.city@pre->including(city) post:Hotel.allInstances.state = Hotel.allInstances.name@pre->including(state) post:Hotel.allInstances.phone = Hotel.allInstances.name@pre->including(phone) post:Hotel.allInstances.rating = Hotel.allInstances.rating@pre->including(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 = Reservation.allInstances.reservationNumber@pre-> including(r.reservationNumber)

31. Formal Inspection Check List • The documentation follows MSE portfolio standard which is describe at http://www.cis.ksu.edu/~sdeloach/mse/portfolio.htm • 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