Online Reservation Management System - PowerPoint by avs16853

VIEWS: 379 PAGES: 35

Online Reservation Management System document sample

More Info
									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
                   architecture.
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




     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
   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

								
To top