Complete the Problems assignments on page 125-126 of Kendall
please answer as the following:
1- ……. etc
a-
b-
c-
d-…………………etc
Compare the domain models for the Inn and Car cases you can find in content. Use the Sikorsky case on pages 213-224 to develop a domain model and make a business case for the PLCS standard as an enabling technology for a smart data strategy. Do the same for VAMTA. Examine figure 4.7 an explain the integration of the business domain with the model domain to make a complete and integrated domain. Remember, at this point you should have event tables, use cases, narratives, sequence diagrams and domain models for both Sikorski AND VAMTA as well as Inn and Car.
When answering these essay questions, please follow the scientific method format of Title, Abstract, Keywords, Introduction, Analysis, Results, Conclusions, Recommendations, Future issues and references. Writing the requisite one paragraph will get you the minimum grade. Please expand beyond this minimal effort and in addition, please provide rigorous references.
GIANT FOREST INN CASE – ANALYSIS
This section contains the analysis models for the Giant Forest Inn case. The models appear in chapter sequence.
Giant Forest Inn – Chapter 3
Introduction
The Giant Forest Inn case study follows the six-step process for object-oriented systems analysis and the seven-step process for object-oriented design. This step is:
Step 1. Identify the business events and make an event table.
Giant Forest Inn Assignments – Chapter 3
Giant Forest Inn Events
As most real-life cases have many facts that are of little value to the analysis and design of systems, this case study intentionally contains many extraneous facts.
We also have made the cases rich enough to allow the instructor some flexibility in defining the scope of the system. For example, for all students except the most advanced, it is best to omit the part of the system pertaining to the cottages and their leases. Most students will have experienced checking into a hotel, however few will be familiar with leases. The solution here, like the assignments in the book, limits the scope of the system.
The use of room names should not be of a major concern. If students are uncomfortable with using a room identifier that refers to the “George Washington Room,” it is a simple matter to change the case study to use a room number.
The decision to reserve specific rooms (by room identifier) actually simplifies the reservation system. When implemented, there is absolute certainty that the room is available. This may not be true when a simple count of available rooms is made. Several systems on the Web do it this way. For example, Choice Hotels Incorporated, shows in the list of available rooms the location of each room (by the elevator, etc.).
Another area of simplification is that of the payment method. For reservations, we use a credit card only; that is pretty much the norm today. For check-in, we ignore the possibility of cash payment. In most hotels, a credit card is swiped, but the credit card is already in the system. We assume that it is the same credit card. The inclusion of a check payment in the case study is conceivable, even though it adds complexity. Even though the case study does not mention it, it should be obvious that cash is always an acceptable method of payment. During checkout, we allowed a check or cash payment as well as a credit card. Note that this presents an easy example to illustrate inheritance in a concept hierarchy.
The way a tip for services is added can be interpreted many different ways. The case study describes that the addition of tips is later in the evening. The process is really not any different ?just the time involved. Although a separate concept could be used for the tip amount, we just added an attribute called “tip” to the Service Charge concept.
The use of a person’s name is not a problem during analysis and design as the employee will enter the room identifier instead of the guest name when services are rendered.
Maintenance of rooms (cleaning, repairing etc.) has been omitted from the solution as it adds considerable complexity.
1. Draw up a list of all external, internal, and temporal events that are encountered in making a reservation, checking in, charging for services, billing, and checking out of the Inn.
The events are:
• Guest reserves room – external event
• Guest registers – external event
• Guest incurs charge for service – external event
• Guest adds tip to bill for service charge – external event
• Hotel produces final bill – temporal event
• Guest pays bill – external event
• Guest checks out – external event
The above sequence reflects the likely order of the events; however, it is not certain if checkout or pay bill is last. The case is designed so this does not matter.
Note that this answer is at the end of Chapter 4.
2. Once the list of events is complete, create an event table, as in Figure 3.6.
Event Table for the Giant Forest Inn Guest System
Event
Number
Event Description
System Input Actor Providing Input
System Output Actor
Receiving
Output
1. Guest reserves room Reservation
Request Guest Confirmation
Authorization
Request Guest
Credit Authorization
System
2. Guest registers Registration
Request Guest Room
Assignment Guest
3. Guest incurs charge for service Service
Request Employee Service
Charge
Receipt Guest
4. Guest adds tip to bill for service charge Tip Guest
5. Time to produce final bill Bill Guest
6. Guest pays bill Payment Guest Authorization
Request
Receipt Credit Authorization
System
Guest
7. Guest checks out Check Out
Request Guest
Giant Forest Inn – Chapter 4
Introduction
This chapter discusses steps 2 – 4 of the six-step process for object-oriented systems analysis. These steps are:
Step 2. Identify the use cases and produce a use case diagram for the system.
Step 3. Write a use case narrative describing the system’s response to each business event.
Step 4. Draw a system sequence diagram for each use case scenario.
Giant Forest Inn Assignments – Chapter 4
Giant Forest Inn Use Case Diagrams
We have avoided the use of «includes», «extends», and «generalizes» relationships because these features of UML often confuse beginning students.
The only component in the use case diagram for the Inn that may be surprising is the actor representing the credit authorization system. Recall that an actor may represent an external system as well as an organization or a person playing a role.
The diagrams in these answers were created in Rational Rose, a tool commonly used in industry today. Rose is not fully compliant with the UML standard; we have worked within its limitations.
1. Draw a use case diagram showing the use cases in the hotel system for each of the following events:
a. Guest reserves room
b. Guest registers
c. Guest incurs charge for service
d. Guest adds tip to bill for service charge
e. Time to produce final bill
f. Guest checks out
g. Guest pays bill
Giant Forest Inn Use Case Narratives
Use case narratives are often the most difficult deliverable to produce. If not the most difficult, they can be tedious to produce. One technique is to provide a template to the student in Microsoft Word. A two-column format template is provided in the Templates for Analysis.
The reservation system assumes that the guest is already in the system. A simple way to solve the problem for new guests is to obtain the phone number; then if there is a new guest, submit the name and address at that time. This is not an error condition so it is included in the body of the use case narrative.
Another problem is how to handle guests who do not know the room identifier of the room they desire. To keep the use case simple, two separate use case system events are provided. One for guests using room identifier and the other for requests using room type and view desired. Note the use of the [guard] in the expanded use case description.
2. Write an expanded essential use case narrative for each use case associated with an external event.
See question 3.
3. Add the alternative flow of events to the above expanded use case narratives.
Use case: Reserve Room
Actors: Guest
Purpose: To make a room reservation.
Overview: Guest submits a reservation request. As the guest may select a specific room, this is included in the request. If the guest has no preference, the system selects a room based on the type and price of accommodation required. If a room is available, guest is then asked for a credit card to reserve the room. The system then sends an authorization request to the credit card authorization system. When approved, a confirmation is sent to the guest and the room is reserved.
Type: Essential
Preconditions: Room availability must be known to the system.
Guest must have a valid credit card.
Postconditions: Reservation was recorded in the system.
Special Requirements: Guest must get a system response within five seconds.
Flow of Events
Actor Action System Response
1. This use case begins when a guest submits a reservation.
2. Guest enters a phone number. 3. Looks up the guest record.
4. [new guest] Guest enters name and address. 5. Saves the guest.
6. [room preference known] Guest enters room identifier followed by arrival date, number of nights, and number of occupants. 7. Informs the guest the room is available.
8. [room preference not known] Guest enters type of room and view desired followed by arrival date, number of nights, and number of occupants. 9. Informs the guest a room is available.
10. Guest enters credit card number, expiration month, and expiration year. 11. Sends the credit card number, information and merchant number to the credit authorization system. When an authorization number is received, it produces a confirmation and reserves the room.
12. Guest receives their confirmation.
Alternative Flow of Events
Line 3: If guest already in the system, go to step 6.
Line 7. If room not available, system informs guest and goes to step 8.
Line 9. If room not available, system informs guest and returns to step 8.
Line 11: If credit card is not authorized, system informs guest and terminates.
Use case: Register Guest
Actors: Guest
Purpose: To check into inn.
Overview: Guest submits a confirmation number. If the guest has no confirmation number, the guest reserves a room first. The guest is then given a room assignment.
Type: Essential
Preconditions: Reservation confirmation must be known to the system.
Postconditions: Registration was recorded in the system.
Special Requirements: Guest must get a system response within 15 seconds.
Flow of Events
Actor Action System Response
1. This use case begins when guest arrives at front desk.
2. Guest enters confirmation number. 3. Looks up the guest reservation and records the arrival time. The guest is given a room assignment.
4. Guest receives a room assignment.
Alternative Flow of Events
Line 2: If guest does not have a reservation, execute the Reserve Room use case first.
Use case: Charge Service
Actors: Employee
Purpose: To record charges incurred by guests.
Overview: When a guest has received a service from the inn, the employee submits a record of the service for later billing.
Type: Essential
Preconditions: Guest must be checked into inn.
Postconditions: Service charge was recorded in the system.
Special Requirements: None
Flow of Events
Actor Action System Response
1. This use case begins when a guest incurs a service charge.
2. Employee enters room identifier, service time, service description, and service price. 3. Records the service charge and produces a service charge receipt.
4. The guest receives a service charge receipt.
Alternative Flow of Events
None
Use case: Add Tip to Service Charge
Actors: Guest
Purpose: To allow guest to tip employees for good service.
Overview: After the guest incurs a service charge, they are presented with a service charge receipt. When convenient the guest writes in a tip amount. This tip amount is added to the service charge.
Type: Essential
Preconditions: Guest must have a service charge receipt.
Postconditions: Updated service charge was recorded in the system.
Special Requirements: None
Flow of Events
Actor Action System Response
1. This use case begins when a guest wishes to add a tip to a service charge.
2. Guest enters room identifier, service time, service number, and tip amount. 3. Adds the tip to the service charge.
Alternative Flow of Events
None.
Use case: Pay Bill
Actors: Guest
Purpose: To accept three different kinds of payment.
Overview: Guest may pay by cash, check, or credit card. If payment is cash or check, a receipt is sent to the guest. If payment is a credit card, the system then sends an authorization request to the credit card authorization system. When approved, a receipt is sent to the guest.
Type: Essential
Preconditions: Final bill must have delivered to the guest.
Postconditions: Payment was recorded in the system.
Special Requirements: None
Flow of Events
Actor Action System Response
1. This use case begins when a guest is ready to pay bill.
Choose one:
2. [cash payment] Room identifier and amount is entered. 3. Records the payment and produces a receipt.
4. [check payment] Room identifier, amount, and check number is entered. 5. Records the payment and produces a receipt.
6. [credit card payment] Room identifier, amount, credit card number, expiration month, and expiration year is entered. 7. Sends the credit card number, expiration month, expiration year, amount, and merchant number to the credit card authorization system. When an authorization number is received, records the payment and produces a receipt.
8. Guest receives their receipt.
Alternative Flow of Events
Line 7: If credit card is not authorized, system informs guest and another method of payment is used.
Use case: Check Out Guest
Actors: Guest
Purpose: To check out from inn.
Overview: After guest has paid their bill, they inform the inn when they actually check out. The also return their room key at this time.
Type: Essential
Preconditions: Bill must have been paid.
Postconditions: Time of check out was saved in the system.
Special Requirements: None
Flow of Events
Actor Action System Response
1. This use case begins when guest arrives at front desk to check out.
2. Guest enters room identifier. 3. Looks up the guest records and records the departure time.
6. Guest departs.
Alternative Flow of Events
Line 3: If guest has not paid their bill, execute the Pay Bill use case first.
Giant Forest Inn System Sequence Diagrams
Note that the messages show the names of the parameters rather than their types. This is not the normal output from Rational Rose, but the parameter names are critical to understanding the system.
4. Draw a system sequence diagram for each of the use cases in the hotel system.
Giant Forest Inn – Chapter 5
Introduction
This chapter discusses steps 5 and 6 of the six-step process for object-oriented systems analysis. These steps are:
Step 5. Produce a domain model showing the concepts, attributes, and associations in the problem domain of the system.
Step 6. Write a contract for each system operation.
Giant Forest Inn Assignments – Chapter 5
Giant Forest Inn Domain Model
There are many ways to model the reservation of a room for a particular date. We have chosen to create a concept called an Accommodation. This is an association concept between reservation and room. To check if a room is available, one needs only to look for instances of Accommodations for the dates requested. If the instances do not exist, the rooms are available.
This domain model contains a generalization-specialization hierarchy of Payment concepts, which will be familiar to most all students. We have also included specification concepts for Service Charge and Room.
The identification of attributes is usually not difficult. A problem is the use of dates and times. Since most programming languages do not distinguish between them, it is not a critical issue.
The association names are never used in design; they are used to make the requirements easier to understand.
No aggregation and composition associations are necessary in this model. If students are having difficulty with this assignment because they falsely believe that every model requires whole-to-part associations, a hint about this might be helpful.
The multiplicities are also not critical at this time but also make the domain model easier to understand. However, they will be necessary for design and must eventually be determined.
1. List all the concepts involved in the Giant Forest Inn system.
• Roles – Guest
• Events – Reservation, Registration, Check Out, Service Charge, Payment, Accommodation
• Tangibles – Room, Credit Card
• Specifications – Room Specification, Service Specification
• Aggregates or Composites – none
• Specializations – Credit Card Payment, Check Payment, Cash Payment
2. Draw a domain model for the Inn using the above concepts.
The domain model was produced in Rational Rose (as a class diagram).
Giant Forest Inn Contracts for System Operations
Like use case narratives, system operation contracts are often difficult to produce. Anytime there is a lot of textual detail, students (and instructors) become alarmed at the level of detail and the amount of work. However, these contracts are the main basis for computer program design. One technique is to provide the student a template in Microsoft Word. This ensures uniformity across solutions and makes it easier to detect errors.
3. Write a contract for each system operation.
The contracts are:
Use Case: Reserve Room
Contract Name: enterPhoneNumber (phoneNumber)
Responsibilities: Check if guest in system.
Type: System
Exceptions: None
Output: None
Preconditions: None
Postconditions: None
Use Case: Reserve Room
Contract Name: enterGuest (name, address)
Responsibilities: Record a new guest.
Type: System
Exceptions: None
Output: None
Preconditions: enterPhoneNumber has been completed.
Postconditions: A new instance of guest was created.
Use Case: Reserve Room
Contract Name: enterRoomRequest (roomIdentifier, arrivalDate, numberOfNights, numberOfOccupants)
Responsibilities: Check to see if accommodation is available.
Type: System
Exceptions: Room not available.
Output: None
Preconditions: Room and its accommodations are known to the system.
Postconditions: None
Use Case: Reserve Room
Contract Name: enterRoomRequest (roomType, view, arrivalDate, numberOfNights, numberOfOccupants)
Responsibilities: Check to see if accommodation type is available.
Type: System
Exceptions: Room type not available.
Output: None
Preconditions: Room specifications, rooms and their accommodations are known to the system.
Postconditions: None
Use Case: Reserve Room
Contract Name: enterCreditCard (creditCardNumber, expirationMonth, expirationYear)
Responsibilities: Record a reservation after verifying credit card is authorized.
Type: System
Exceptions: Credit card not authorized.
Output: Credit card authorization request
Preconditions: enterRoomRequest has been completed.
Postconditions: A new instance of reservation and its accommodations was created.
A new instance of Makes association was created linking Guest and Reservation.
A new instance of Accommodation was created for each night of the stay.
A new instance of For association was created linking each new Accommodation and Reservation.
A new instance of Holds association was created linking Accommodation and Room.
A confirmation was produced.
Use Case: Register Guest
Contract Name: enterArrival (confirmationNumber)
Responsibilities: Record registration.
Type: System
Exceptions: Guest does not have a reservation.
Output: None
Preconditions: Reservation is known to the system.
Postconditions: An instance of Registration was created.
A new instance of Checks In association was created linking Registration and Reservation.
A room assignment was produced.
Use Case: Charge Service
Contract Name: enterService (roomIdentifier, serviceTime, serviceCode, and amount)
Responsibilities: Record service charge.
Type: System
Exceptions: Accommodation does not exist.
Output: None
Preconditions: Accommodation is known to the system.
Postconditions: An instance of Service Charge was created.
A new instance of Incurs association was created linking Accommodation and Service Charge.
A new instance of Specified By association was created linking Service Charge and Service Charge Specification.
A service charge receipt was produced.
Use Case: Add Tip to Service Charge
Contract Name: enterTip (roomIdentifier, serviceDate, serviceNumber, tipAmount)
Responsibilities: Record tip for service.
Type: System
Exceptions: Service Charge does not exist.
Output: None
Preconditions: enterService has been completed.
Postconditions: The attribute tipAmount in the Service Charge was updated .
Use Case: Pay Bill
Contract Name: enterCashPayment (roomIdentifier, amount)
Responsibilities: Record a cash payment.
Type: System
Exceptions: Registration does not exist.
Output: None
Preconditions: Registration in the specific room is known to the system.
Postconditions: An instance of Cash Payment was created.
A new instance of Paid By association was created linking Registration and Cash Payment.
A receipt was produced.
Use Case: Pay Bill
Contract Name: enterCheckPayment (roomIdentifier, checkNumber, amount)
Responsibilities: Record a check payment.
Type: System
Exceptions: Registration does not exist.
Output: None
Preconditions: Registration is known to the system.
Postconditions: An instance of Check Payment was created.
A new instance of Paid By association was created linking Registration and Check Payment.
A receipt was produced.
Use Case: Pay Bill
Contract Name: enterCreditCardPayment (roomIdentifier, amount creditCardNumber, expirationMonth, expirationYear)
Responsibilities: Record a credit card payment after it has been authorized.
Type: System
Exceptions: Registration does not exist.
Credit card not authorized.
Output: Credit card authorization request.
Preconditions: Registration is known to the system.
Postconditions: An instance of Credit Card Payment was created.
A new instance of Paid By association was created linking Registration and Credit Card Payment.
A new instance of Used For association was created linking Credit Card and Credit Card Payment.
A receipt was produced.
Use Case: Check Out Guest
Contract Name: enterDeparture (roomIdentifier)
Responsibilities: Record time out.
Type: System
Exceptions: Registration does not exist.
Payment does not exist.
Output: None
Preconditions: Registration is known to the system.
Payment is known to the system.
Postconditions: An new instance of Check Out was created.
