Академический Документы
Профессиональный Документы
Культура Документы
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. 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.
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
Productivity
800 SLOC / 56 hours = 14.2 SLOC/hour 6 Documents / 78 hours = 0.07 Docs/hour 800 SLOC / 0.25 = 3200 SLOC (estimated total) 4-5 Documents
Remaining Work
Remaining Effort
High Level
Action Items (documentation) User Manual (documentation) Component Design (documentation) Assessment Evaluation (testing) Project Evaluation (documentation) References (documentation) Technical Inspection Letters (documentation)
Project Plan
Architecture Design
The architecture of the HRS is based on 3-tier architecture. There are three logical tiers:
Architecture Design
Clients
IIS 5.0 Server
HRS Database
MsSQL Server
The presentation-tier for the Hotel Reservation System is ASP.NET Web Forms with User Controls. Detail of the Presentation Tier
Hotel Chain
1..*
Hotel hotelID : String name : String address : String city : String state : String phone : String rating : Integer findHotel() newHotel() updateHotel() 1+theHotel
+theHotel 0..*
+theHotel 1
Customer firstNam e : String lastNam e : String cardType : String cardNumber : Integer experationDate : Date createAccount() updateAccount()
0..*
+theRoom
1..*
+theReservation 0..*
reservationNum ber : Integer checkIn : Date checkOut : Date resvDate : Date +theReservation price : Double 0..* totalCost : Double makeReservation() getReservation() cancelReservation() calculateT otalCost()
Room roomNumber : Integer price : Double bedType : String smoking : String roomLock : Date getRoomRate() getRoomAvl() newRoom() updateRoom()
+allocation 1
The class diagram above captures middle-tier, business specific layer, of the Hotel Reservation System.
3: verifyLogin(userName:String,password:String)
4: Verify
5: [IsVerify]
Sequence diagram shows that user successfully login for editing his/her account
5: v erif y
6: [ IsVerif y ]
12: v erif y 13: res erv e 14: [IsVerif y ] new : Reserv ation
16: Verif y
This s equenc e diagram shows successf ull reserv ation and user already logged in. Operation Signature: getRoomAv l(hotelI D : String, bedTy pe : String, sm oking : String, checkIn : Date, c heckOut : Date) : Room
Detail View
3: getReservation(reservationNumber:Integer) 4: cancel()
5: cancelReservation(reservationNumber:Integer)
6: verify 7: [IsVerify]
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
2: generateReport(startingDate:Date, endingDate:Date)
3: Report
: Hotel
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
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 cant 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,c ardType:String,cardNumber:Integer,experationDate:Integer,phone:String,address:String,city:String,state:Str ing,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)
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
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