Online Hotel Reservation

System

MSE Presentation 2
Cem Oguzhan
February 21, 2005
Outline
 Project Overview
 Action Items
 Project Plan
 Architecture Design
 Formal Specification
 Formal Inspection Check List
 Test Plan
 Questions
 Demo (Hotel Reservation System)
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.
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
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
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
Project Plan – WBS
 High Level
 Coding/debugging – 25 days
 Testing – 7 days
 Documentation – 11 days
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)
Project Plan
 Development (2/22 – 3/31)
 Testing (4/1 – 4/11)
 Documentation (4/12 – 4/29)
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.
Architecture Design
 The diagram shows
3-tier type of
Clients
IIS 5.0 Server

ASP.NET
architecture.
Middle-Tier

CLR
Business Logic
Components
(C# Class
Library)

Data Access via

ADO.NET

HRS
Database

MsSQL
Server
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
Architecture Design –
Presentation Tier
Architecture Design –
Presentation Tier
Architecture Design –
Presentation Tier
Architecture Design – Middle Tier
User Hotel Chain
userName : String
Administrator
email : String
userName : Stri ng 1 +theHotel Chain
password : String
phone : String password : String
address : String 1
verifyLogin() 1..* +theHotel
city : String +theAdmin
+approveAccount
state : String logout() Hotel
zip : String approveAccount() 1 hotelID : String
disApproveAccount() name : String
verifyLogin() generateReport() +theHotel address : String
logout() 1 city : String
getUser() 0..* state : String
phone : String
1 +theUser
0..* rating : Integer
+theHotel
Mail
1 findHotel()
newHotel()
sendMail(e_address : String) : Boolean
updateHotel()
1+theHotel
Customer
0..* 0..*
firstNam e : String
+requestAccount
lastNam e : String
cardType : String TravelAgent
cardNum ber : Integer companyName : String
status : String 1
experationDate : Date
requestAccount() +theReservation
createAccount() generateReport()
+theRoom 1..*
updateAccount() Reservation
0..* Room
reservationNum ber : Integer
roomNumber : Integer
checkIn : Date price : Double
checkOut : Date bedT ype : String
resvDate : Date
+theReservation +theReservation +allocation smoking : String
price : Double roomLock : Date
totalCost : Double 0..* 1
0..*
getRoomRate()
makeReservation() getRoomAvl()
getReservation()
newRoom()
cancelReservation() updateRoom()
calculateT otalCost()

The class diagram above captures middle-tier, business specific

layer, of the Hotel Reservation System.
 Architecture Design - Login
: SignIn.aspx : EditAccount.aspx
: User

1: user provides requested information

2: new : User

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

4: Verify

5: [IsVerify]

Sequence diagram shows that user successfully login for editing

his/her account
Architecture Design – Making
a Reservation
: FindHotel.aspx : Hotel Chain : HotelResult.aspx : RoomPref erences.aspx :Conf irmReserv ation.aspx
: User

1: prov ide requested inf ormation

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

3: new : Hotel

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

5: v erif y
6: [IsVerif y ]

7: selectHotel()

8: room pref erences

9: select room pref erences

10: new : Room

11: getRoomAv l()

12: v erif y

13: reserv e

14: [IsVerif y ] new : Reserv ation

15: makeReserv ation(r:Reserv ation)

16: Verif y

17: [IsVerif y ] conf irmation

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

Detail View
 Architecture Design –
Canceling a Reservation
: CancelReservation.aspx : ConfirmCancelReservation.aspx
: User

1: provides requested information

2: new : Reservation

3: getReservation(reservationNumber:Integer)

4: cancel()

5: cancelReservation(reservationNumber:Integer)

6: verify

7: [IsVerify]
 Architecture Design -
Requesting an Account

: RequestAccount.aspx : Mail
: Agent

1: provide requested information

2: new : TravelAgent

3: requestAccount()

4: verify

5: [verify] sendMail(e_address:String)

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
 Architecture Design –
Generating a Report

: Report.aspx : TravelAgent
: Agent

1: provides requested information

2: generateReport(startingDate:Date, endingDate:Date)

3: Report
Architecture Design – Adding
an Hotel
: AddHotel.aspx : ConfirmAddHotel.aspx
: Admin

1: provides requested information

2: new : Hotel

3: newHotel()

4: verify

5: [IsVerify]

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
Architecture Design – Data
Tier
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.
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
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)
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)
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)
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)
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)
Formal Inspection Check List
1. 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.
Test Plan
 Unit Testing with TestSharp2004

 Performance Testing with JMeter

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
Questions
Demo