Online Hotel Reservation System MSE Presentation 2 Cem

Online Hotel Reservation System MSE Presentation 2 Cem Oguzhan February 21, 2005

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

Project Overview n Project Statement n n 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. n n n 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.

Project Plan – Cost Estimate n Current Progress n n n n 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

Project Plan – Cost Estimate n Productivity n n n 800 SLOC / 56 hours = 14. 2 SLOC/hour 6 Documents / 78 hours = 0. 07 Docs/hour Remaining Work n n 800 SLOC / 0. 25 = 3200 SLOC (estimated total) 4 -5 Documents

Project Plan – Cost Estimate n Remaining Effort n 2400 SLOC / (14. 2 SLOC/hour) n n = 169 hours or 25 days (7 hours per day) 72 hours for documentation n = 11 days

Project Plan – WBS n High Level n n n Coding/debugging – 25 days Testing – 7 days Documentation – 11 days

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

Project Plan n Development (2/22 – 3/31) Testing (4/1 – 4/11) Documentation (4/12 – 4/29)

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

Architecture Design n The diagram shows 3 -tier type of architecture.

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

Architecture Design – Presentation Tier

Architecture Design – Presentation Tier

Architecture Design – Presentation Tier

Architecture Design – Middle Tier The class diagram above captures middle-tier, business specific layer, of the Hotel Reservation System.

Architecture Design - Login

Architecture Design – Making a Reservation Detail View

Architecture Design – Canceling a Reservation

Architecture Design Requesting an Account

Architecture Design – Generating a Report

Architecture Design – Adding an Hotel

Architecture Design – Data Tier

Architecture Design n 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 n Security The Hotel Reservation System uses ASP. NET Forms Authentication to validate users.

Formal Specification --Custumer and Travel. Agent have unique user name context User inv unique. User. Name: User. all. Instances->for. All(u 1, u 2 | u 1<>u 2 implies u 1. user. Name<>u 2. user. Name) --Each reservation belongs to one hotel Enforce by the multiplicity of association Hotel. Reservation --Each reservation allocates one room Enforce by the multiplicity of association Reservation. Room

Formal Specification --check in date can not be later than check out date context r: Reservation inv check. In. Not. Be. Later. Check. Out: r. check. In<r. check. Out --room can’t be overbook context Reservation inv over. Book. Room: Reservation. all. Instances->for. All(r 1, r 2 | r 1. reservation. Number <> r 2. reservation. Number and r 1. allocation. room. Number = r 2. allocation. room. Number implies r 1. check. Out <= r 2. check. In or r 2. check. Out <= r 1. check. In)

Formal Specification -- A hotel can never have more reservations for a date than rooms context Hotel inv not. Over. Book: Date. all. Instances->for. All(d|Hotel. all. Instances-> for. All(h| h. the. Reservation-> select(h. the. Reservation. dates->includes(d))-> size <= h. the. Room->size ) ) -- each hotel is located at one city and state context Hotel inv one. Location: Hotel. all. Instances->for. All(h 1, h 2 | h 1 = h 2 implies h 1. city = h 2. city and h 1. state = h 2. state) --hotel star rating should be between 1 -5 context Hotel inv star. Rating: Hotel. all. Instances->for. All(h | h. rating >0 and h. rating < 6)

Formal Specification verify. Login(user. Name: String, password: String): Boolean =User. all. Instances-> exists(u: User | u. user. Name = user. Name and u. password = password) -- update the customer account context Customer: : update. Account(user. Name: String, email: String, password: String, first. Name: String, last. Name: String, card. Type: String, card. Number: Integer, experation. Date: Integer, phone: String, address: String, city: String, state: String, zip: String): Boolean --the customer should be exist and login pre: verify. Login(user. Name, password) --the customer's user. Name can not be updated and user. Name of old customers’ record are not changed post: Customer. all. Instances. user. Name = Customer. all. Instances. user. Name@pre post: Customer. all. Instances->select(c: Customer | c. user. Name <>user. Name)->for. All(c: Customer | c. email = c. email@pre and c. password = c. password@pre and c. first. Name = c. first. Name@pre and c. last. Name = c. last. Name@pre and c. card. Type = c. card. Type@pre and c. card. Number = c. card. Number@pre and c. experation. Date = c. experation. Date@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. all. Instances->select(c: Customer |c. user. Name = user. Name)->for. All( c: Customer | c. email = email and c. password = password and c. first. Name = first. Name and c. last. Name = last. Name and c. card. Type = card. Type and c. card. Number = card. Number and c. experation. Date = experation. Date and c. phone = phone and c. address = address and c. city = city and c. state = state and c. zip = zip)

Formal Specification --add new hotel context Hotel: : new. Hotel(hotel. ID: 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. all. Instances->for. All(h: Hotel | h. hotel. ID <> hotel. ID) --existing hotels record are not changed only a new hotel is added post: Hotel. all. Instances. hotel. ID = Hotel. all. Instances. hotel. ID@pre-> including(hotel. ID) post: Hotel. all. Instances. name = Hotel. all. Instances. name@pre->including(name) post: Hotel. all. Instances. address = Hotel. all. Instances. address@pre-> including(address) post: Hotel. all. Instances. city = Hotel. all. Instances. city@pre->including(city) post: Hotel. all. Instances. state = Hotel. all. Instances. name@pre->including(state) post: Hotel. all. Instances. phone = Hotel. all. Instances. name@pre->including(phone) post: Hotel. all. Instances. rating = Hotel. all. Instances. rating@pre->including(rating)

Formal Specification --make a reservation context Reservation: : make. Reservation(r: Reservation) --pre: r. the. User. verify. Login(r. the. User. user. Name, r. the. User. password) --pre: Reservation. all. Instances->excludes(r) --post: Reservation. all. Instances. reservation. Number = Reservation. all. Instances. reservation. Number@pre-> including(r. reservation. Number)

Formal Inspection Check List 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 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.

Test Plan n Unit Testing with Test. Sharp 2004 n Performance Testing with JMeter

Test Plan – test cases n n n n n 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

Questions

Demo