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.