Hotel Reservation

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

Transcript of Hotel Reservation

Page 1: Hotel Reservation

Online Hotel Reservation System

MSE Presentation 2Cem Oguzhan

February 21, 2005

Page 2: Hotel Reservation

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

Page 3: Hotel Reservation

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.

Page 4: Hotel Reservation

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

Page 5: Hotel Reservation

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

Page 6: Hotel Reservation

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

Page 7: Hotel Reservation

Project Plan – WBS High Level

Coding/debugging – 25 days Testing – 7 days Documentation – 11 days

Page 8: Hotel Reservation

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)

Page 9: Hotel Reservation

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

Page 10: Hotel Reservation

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.

Page 11: Hotel Reservation

Architecture Design

IIS 5.0 Server

Business LogicComponents

(C# ClassLibrary)

Data Access viaADO.NET

Middle-Tier

CLR

HRSDatabase

MsSQLServer

ASP.NET

Clients

The diagram shows 3-tier type of architecture.

Page 12: Hotel Reservation

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

Page 13: Hotel Reservation

Architecture Design – Presentation Tier

Page 14: Hotel Reservation

Architecture Design – Presentation Tier

Page 15: Hotel Reservation

Architecture Design – Presentation Tier

Page 16: Hotel Reservation

Architecture Design – Middle Tier

CustomerfirstName : StringlastName : StringcardType : StringcardNumber : IntegerexperationDate : Date

createAccount()updateAccount()

Mail

sendMail(e_address : String) : Boolean

UseruserName : Stringemail : Stringpassword : Stringphone : Stringaddress : Stringcity : Stringstate : Stringzip : String

veri fyLogin()logout()getUser()

TravelAgentcompanyName : Stringstatus : String

requestAccount()generateReport()

RoomroomNumber : Integerprice : DoublebedType : Stringsmoking : StringroomLock : Date

getRoomRate()getRoomAvl()newRoom()updateRoom()

ReservationreservationNumber : IntegercheckIn : DatecheckOut : DateresvDate : Dateprice : DoubletotalCost : Double

makeReservation()getReservation()cancelReservation()calculateTotalCost()

10..*

+allocation

1

+theReservation

0..*0..*

1

+theReservation

0..*

+theUser1

AdministratoruserName : Stringpassword : String

verifyLogin()logout()approveAccount()disApproveAccount()generateReport()

0..*

1

+requestAccount0..*

+approveAccount1

1

0..*

HotelhotelID : Stringname : Stringaddress : Stringci ty : Stringstate : Stringphone : Stringrating : Integer

findHotel()newHotel()updateHotel()

1..*

1

+theRoom 1..*

+theHotel1

0..*

1

+theReservation

0..*

+theHotel

1

0..*

1

+theHotel

0..*

+theAdmin

1

Hotel Chain

1..*

1

1..*

1

1

0..*

+theHotel Chain

+theHotel

The class diagram above captures middle-tier, business specific layer, of the Hotel Reservation System.

Page 17: Hotel Reservation

Architecture Design - Login

: User : SignIn.aspx

: User

: EditAccount.aspx

1: user provides requested information

3: verifyLogin(userName:String,password:String)

Sequence diagram shows that user successfully login for editing his/her account

2: new

5: [IsVerify]

4: Verify

Page 18: Hotel Reservation

Architecture Design – Making a Reservation

Detail View

: User : FindHotel.aspx

: Reserv ation

: Hotel

: HotelResult.aspx

: Room

: RoomPref erences.aspx :Conf irmReserv ation.aspx : Hotel Chain

7: selectHotel()

This sequence diagram shows successf ull reserv ation and user already logged in.Operation Signature:getRoomAv l(hotelID : String, bedTy pe : String, smoking : String, checkIn : Date, checkOut : Date) : Room

1: prov ide requested inf ormation

2: f indHotel(city :String, state:String)

4: f indHotel(city :String, state:String)

3: new

5: v erif y6: [ IsVerif y ]

8: room pref erences

9: select room pref erences

10: new

11: getRoomAv l()

13: reserv e

14: [IsVerif y ] new

15: makeReserv ation(r:Reserv ation)

12: v erif y

17: [IsVerif y ] conf irmation

16: Verif y

Page 19: Hotel Reservation

Architecture Design – Canceling a Reservation

: User : CancelReservation.aspx

: Reservation

: ConfirmCancelReservation.aspx

1: provides requested information

3: getReservation(reservationNumber:Integer)

4: cancel()

5: cancelReservation(reservationNumber:Integer)

2: new

6: verify

7: [IsVerify]

Page 20: Hotel Reservation

Architecture Design - Requesting an Account

: Agent : RequestAccount.aspx

: TravelAgent

: Mail

1: provide requested information

2: new

3: requestAccount()

The sequence diagram shows that the travel agent successfully applies to an account. Operation Signature:requestAccount(userName : String, email : String, password : String, companyName : String, status : String, phone : String, address : String, city : String, state : String, zip : String) : Boolean

4: verify

5: [verify] sendMail(e_address:String)

Page 21: Hotel Reservation

Architecture Design –Generating a Report

: Agent : Report.aspx : TravelAgent

1: provides requested information2: generateReport(startingDate:Date, endingDate:Date)

3: Report

Page 22: Hotel Reservation

Architecture Design – Adding an Hotel

: Admin : AddHotel.aspx

: Hotel

: ConfirmAddHotel.aspx

1: provides requested information

3: newHotel()

2: new

The sequence diagram shows successfuly adding a hotel. The admin is already login.Operation Signuture:newHotel(hotelID : String, name : String, address : String, city : String, state : String, phone : String, rating : Integer) : Boolean

4: verify

5: [IsVerify]

Page 23: Hotel Reservation

Architecture Design – Data Tier

Page 24: Hotel Reservation

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

SecurityThe Hotel Reservation System uses ASP.NET Forms Authentication to validate users.

Page 25: Hotel Reservation

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

Page 26: Hotel Reservation

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)

Page 27: Hotel Reservation

Formal Specification-- A hotel can never have more reservations for a date than rooms

context Hotelinv 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 statecontext 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-5context Hotel

inv starRating:Hotel.allInstances->forAll(h | h.rating >0 and h.rating < 6)

Page 28: Hotel Reservation

Formal SpecificationverifyLogin(userName:String,password:String):Boolean =User.allInstances->

exists(u:User | u.userName = userName and u.password = password)

-- update the customer accountcontext 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 loginpre:verifyLogin(userName,password)

--the customer's userName can not be updated and userName of old customers’ record are not changedpost: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 updatedpost: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)

Page 29: Hotel Reservation

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 existpre:Hotel.allInstances->forAll(h:Hotel | h.hotelID <> hotelID)

--existing hotels record are not changed only a new hotel is addedpost: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)

Page 30: Hotel Reservation

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)

Page 31: Hotel Reservation

Formal Inspection Check List1. The documentation follows MSE portfolio standard which is describe at

http://www.cis.ksu.edu/~sdeloach/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.

Page 32: Hotel Reservation

Test Plan Unit Testing with TestSharp2004

Performance Testing with JMeter

Page 33: Hotel Reservation

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

Page 34: Hotel Reservation

Questions

Page 35: Hotel Reservation

Demo