Business Events and Smart Data

Read the Review Questions 1-45 on pages 94-95 of Kendall and upload to D2L. Compare the projects for both Apache and Giant forest that you will find in content. How do the business events discussed in the lecture integrate with the business rule for smart data as outlined on pages 16-21? Could you design a system around the business events described in the IT Capital Budgeting and MWDSScase studies? Write a short summary of your conclusions.
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.

APACHE RENT A CAR CASE – DESIGN

This section contains the design models for the Apache Rent A Car case. The models appear in chapter sequence.
Apache Rent A Car – Chapter 7
Introduction
This chapter discusses the design of the overall system structure. The questions illustrate how to:

1. Allocate Essential Use Cases to Processors
2. Allocate Stored Data to Storage Devices

Note that these steps are not part of the seven steps for program design.
Apache Rent A Car Assignments – Chapter 7
1. Define three alternative system structures for the Apache Rent A Car system. (See Figures 7.13, 7.14, and 7.15 for the university registration system.)
Alternative “A” allocates the use cases to two processors.
Alternative “B” allocates the use cases to a single processor, but adds a second processor for the data storage.
Alternative “C” same as Alternative “A” but also allocates the data storage to a separate processor.

2. Discuss qualitatively the advantages and disadvantages of each alternative.
a. Alternative “A” allocates the use cases two processors
• Advantage: This keeps the car maintenance system used by employees separate from the reservation and rental system used by the customers.
• Disadvantage: The two processors will have to communicate frequently with each other.
b. Alternative “B” allocates the use cases to same processor, but adds a second processor for the data storage.
• Advantage: This will ensure that the data is secure. It will be easier to back up and maintain as well.
• Disadvantage: The two processors will have to communicate frequently with each other.
c. Alternative “C” same as Alternative “A” but allocates all data storage to a separate storage processor.
• Advantage: This allows the processors to be single function and thus can be optimized. It also makes it easy to back up the data storage, as it is separate.
• Disadvantage: The three processors will have to communicate frequently with each other.

Apache Rent A Car – Chapter 8
Introduction
This chapter discusses the first step of the seven-step process for object-oriented program design. This step is:
Step 1. Produce an interaction diagram for each system operation identified during analysis
Apache Rent A Car Assignments – Chapter 8
Apache Rent A Car Interaction Diagram
The textbook shows all the intermediate steps necessary to obtain a collaboration diagram. At the end of the chapter, they are converted to a sequence diagram. Once the individual events have been converted to a collaboration diagram, it is common to convert them to a sequence diagram. Many people feel it is easier to read sequence diagrams because of their sequential nature. The answers to these questions are presented in this format. Also all system operations for each use case are grouped together in a single sequence diagram in the system.
Develop a separate set of interaction diagrams (either collaboration or sequence diagrams) for each of the use cases in the Rent A Car system.
Be sure that the interaction diagram for each use case demonstrates how you verify the preconditions and satisfy the postconditions for each of the system operation contracts prepared for the Chapter 5 assignments. Show an explicit create operation for each new object. Also show an explicit associate operation for each newly established link. Also be sure that each object knows all the arguments for any message that it sends.
Suggestion: Sketch the interaction diagrams following the method described in Chapter 8 before you use any software tool to prepare the diagrams.
Apache Rent A Car – Chapter 9
Introduction
This chapter discusses steps 2 and 3 of the seven-step process for object-oriented program design. These steps are:
Step 2. Produce a design class diagram showing the operations from the interaction diagrams.
Step 3. Specify the signature and the algorithm for each operation.
Apache Rent A Car Assignments – Chapter 9
Apache Rent A Car Class Diagram
Chapter 9 shows the development of the class diagram with a special emphasis on qualified associations.
1. Develop a design class diagram for the Apache Rent A Car system.
Pay particular attention to appropriate use of the aggregation and composition symbols, which are used when an association between classes relates parts to wholes, members to groups, or contents to containers. Show class hierarchies. Also be sure to indicate on the diagram navigability from one class to another.

2. Revise and refine the interaction diagrams developed for the Chapter 8 assignment. Correct any violations of the Law of Demeter, reduce the coupling, and increase the cohesion. Modify the design class diagram to be consistent with these improvements.
We took great care to be sure none of these violations were presented earlier. Most students understand coupling and cohesion. The Law of Demeter is probably the most difficult one to avoid. Note that operations like makeReturn, makeDriver, makeExtraCharge, and makePayment occur in Car and Rental. This is preferable to having the façade object invoke a get operation in each of the above classes to obtain the rental object and then send a message to it. This habit is common among beginners, especially in programming classes.
Apache Rent A Car Signatures
Although not asked for, signatures for all operations will be provided. This makes it possible for the instructor to easily add an assignment to develop them.
3. Develop signatures for all operations. You may omit the “creates” because they are of a standard format. (optional question)
This answer is provided with signatures in a UML format as in Figure 9.22. The data types are compatible with Java.
Complete Specification of Attributes and Operations – Apache Rent A Car
Car Attributes – color : String
– licenseNumber : String
– make : String
– model : String
– modelYear : int
Operations + associateExtraChargeSpecification
(extraChargeSpecification, ExtraChargeSpecification)
+ associateRental (rental : Rental)
+ associateInspection (inspection: Inspection)
+ associateThirdPartyPayer (thirdPartyPayer, ThirdPartyPayer)
+ authorize (amount : double, merchantNumber : int) : boolean
+ makeCreditCard (creditCardNumber : String,
expirationMonth : int, expirationYear : int)
+ makeDriver (name : String, birthDate : Date,
driversLicenseNumber : String, stateOfIssue : String)
+ makeExtraCharge (amountCharged : double)
+ makeInspection (damage : double, gasLevel : double, mileageIn : int,
time : Date)
+ makePayment (amount : double)
+ makeRental (timeOut : Date, mileageOut : int)
+ makeReturn (timeIn : Date)
Credit Card Attributes – creditCardNumber: String
– expirationMonth : int
– expirationYear : int
Operations + authorize (amount : double, merchantNumber : int) : int
Customer Attributes – address: String
– name: String
– phoneNumber : String
Operations None
Complete Specification of Attributes and Operations – Apache Rent A Car (Continued)
Driver Attributes – birthDate : Date
– driversLicense Number: String
– name: String
– stateOfIssue : String
Operations None
Extra Charge Attributes – amountCharged : double
Operations + associateExtraChargeSpecification
(extraChargeSpecification, ExtraChargeSpecification)
Extra Charge Specification Attributes – extraChargeCode : String
– description : String
– price : double
Operations None
Inspection Attributes – damage : double
– gasLevel : double
– mileageIn : int
– time : Date
Operations None
Payment Attributes – amount : double
– authorizationNumber : int
– date : Date
Operations + associateCreditCard (creditCard : CreditCard)
+ authorize (amount : double,
merchantNumber : int) : boolean
+ makeCreditCard (creditCardNumber : String,
expirationMonth : int, expirationYear : int)
Rental System Attributes None
Operations + assignCar ( )
+ enterCarRequest (carType : String, pickUpDate : Date,
returnDate : Date)
+ enterConfirmation (confirmationNumber : int, timeOut : Date)
+ enterCreditCard (creditCardNumber : String,
expirationMonth : int, expirationYear : int)
+ enterCustomer (phoneNumber : String, name : String, address : String)
+ enterDriver (name : String, birthDate : Date,
driversLicenseNumber : String, stateOfIssue : String)
+ enterExtraCharge (extraChargeCode : String, amountCharged : double)
+ enterInspection (licenseNumber: String, damage : double,
gasLevel : double, mileageIn : int)
+ enterMileageOut (mileageOut : int)
+ enterReturn (licenseNumber : String, timeIn : Date)
+ enterThirdPartyCustomer (accountNumber : int)
+ enterPayment (licenseNumber: String, amount : double)
+ verifyCarLicense (licenseNumber: String) : boolean
+ verifyConfirmationNumber (confirmationNumber: int) : boolean
+ verifyExtraChargeCode (extraChargeCode : String) : boolean
+ verifyRateCode (carType : String) : boolean
+ verifyThirdPartyCustomer (accountNumber : int) : boolean

Complete Specification of Attributes and Operations – Apache Rent A Car (Continued)
Rate Class Attributes – carType : String
– dailyRate : double
– mileageRate : double
– numberOfFreeMiles : int
– weekEndRate: double
– weeklyRate : double
Operations None
Rental Attributes – agreementNumber : int
– mileageOut : int
– timeOut : Date
Operations + associateDriver (checkOut : CheckOut)
+ associateExtraCharge (extraCharge, ExtraCharge)
+ associateExtraChargeSpecification
(extraChargeSpecification, ExtraChargeSpecification)
+ associateInspection (inspection, Inspection)
+ associatePayment (payment, Payment)
+ associateReservation (reservation, Reservation)
+ associateReturn (return, Return)
+ associateThirdPartyPayer
(thirdPartyCustomer, ThirdPartyCustomer)
+ authorize (amount : double, merchantNumber : int) : boolean
+ makeCreditCard (creditCardNumber: String,
expirationMonth: int, expirationYear: int )
+ makeDriver (name : String, birthDate : Date,
driversLicenseNumber : String, stateOfIssue, : String)
+ makeExtraCharge (amountCharged : double)
+ makePayment (amount : double)
+ makeReturn (timeIn : Date)
+ requestMileage ( )
Reservation Attributes – confirmationNumber : int
– confirmedPrice : double
– pickUpDate : Date
– reservationTime : Date
– returnDate : Date
Operations + associateCreditCard (creditCard : CreditCard)
+ associateCustomer (customer: Customer)
+ associateRateClass (rateClass, RateClass)
+ authorize (amount : double, merchantNumber : int) : boolean
+ makeCreditCard (creditCardNumber: String,
expirationMonth: int, expirationYear: int )
+ makeCustomer (phoneNumber : String, name : String, address : String)

Complete Specification of Attributes and Operations – Apache Rent A Car (Continued)
Return Attributes – timeIn : Date
Operations + associatePayment (payment, Payment)
+ authorize (amount : double, merchantNumber : int) : boolean
+ makeCreditCard (creditCardNumber : String,
expirationMonth : int, expirationYear : int)
+ makePayment (amount : double)
Third Party Customer Attributes – account Number : int
– address: String (inherited)
– name: String (inherited)
– phoneNumber : String (inherited)
Operations None

Apache Rent A Car – Chapter10
Introduction
This chapter discusses step 6 of the seven-step process for object-oriented program design. This step is:
6. Define the interface to the storage layer.
Apache Rent A Car Interface to the Storage Layer
Chapter 10 shows the enhancement of the class diagram to include the database interface. Also the SQL table definitions are explained as an optional topic in the chapter.
Apache Rent A Car Assignments – Chapter 10
1. Apply the Singleton pattern to the Apache Rent A Car system to provide an interface from the objects in the application layer to the storage layer. Modify the design class diagram accordingly, showing all the operations of the singleton object.
The class diagram with the database interface shows only the database interface class without any operations in order to conserve space and make the diagram more readable. The second diagram shows all the operations of the database interface class.
2. Assume that a relational DBMS is used to implement the persistence of the attributes and associations of the objects. Define the structure of the required tables. (See Figure 10.8.)
The most important part of this assignment is the addition of the foreign keys. Both RESERVATION and RENTAL contain many foreign keys linking them to their necessary information. Also three tables (RETURN_CAR, PAYMENT, and INSPECTION) needed a primary key. The fields RETURN_NUMBER, PAYMENT_NUMBER, and INSPECTION_NUMBER, were chosen.
DBMS Table Definitions – Apache Rent A Car
Table Data
CAR LICENSE_NUMBER (VARCHAR (10)) – Primary Key
COLOR (VARCHAR (20))
MAKE (VARCHAR (20))
MODEL (VARCHAR (20))
MODEL_YEAR (INTEGER)
CREDIT_CARD CREDIT_CARD_NUMBER (VARCHAR (20)) – Primary Key
EXPIRATION_MONTH (INTEGER)
EXPIRATION_YEAR (INTEGER)
CUSTOMER PHONE_NUMBER (VARCHAR (20)) – Primary Key
NAME (VARCHAR (40))
ADDRESS (VARCHAR (60))
DRIVER DRIVERS_LICENSE_NUMBER (VARCHAR (20)) – Primary Key
STATE_OF_ISSUE (VARCHAR (2)) – Primary Key
DATE_OF_BIRTH (DATE)
NAME (VARCHAR (40))
AGREEMENT_NUMBER (INTEGER) – Foreign Key
EXTRA_CHARGE AGREEMENT_NUMBER (INTEGER) – Primary Key, Foreign Key
EXTRA_CHARGE _CODE (VARCHAR (10)) – Primary Key,
Foreign Key
AMOUNT_CHARGED (DECIMAL (10,2))
EXTRA_CHARGE
SPECIFICATION EXTRA_CHARGE _CODE (VARCHAR (10)) – Primary Key
DESCRIPTION (VARCHAR (20))
PRICE (DECIMAL (10,2))
INSPECTION INSPECTION_NUMBER (INTEGER) – Primary Key
DAMAGE (DECIMAL(10,2))
GAS_LEVEL (DECIMAL(3,2))
MILEAGE_IN (INTEGER)
INSPECTION_TIME (DATE)
AGREEMENT_NUMBER (INTEGER) – Foreign Key
LICENSE_NUMBER (VARCHAR (10)) – Foreign Key
PAYMENT PAYMENT_NUMBER (INTEGER) – Primary Key
AMOUNT (DECIMAL(10,2))
AUTHORIZATION_NUMBER (INTEGER)
PAYMENT_TIME (DATE)
AGREEMENT_NUMBER (INTEGER) – Foreign Key
CREDIT_CARD_NUMBER (VARCHAR (20)) – Foreign Key

DBMS Table Definitions – Apache Rent A Car (Continued)
Table Data
RATE_CLASS CAR_TYPE (VARCHAR (10)) – Primary Key
NUMBER_FREE_MILES (INTEGER)
DAILY_RATE (DECIMAL (10,2))
MILEAGE_RATE (DECIMAL (10,2))
WEEK_END_RATE (DECIMAL (10,2))
WEEKLY_RATE (DECIMAL (10,2))
RENTAL AGREEMENT_NUMBER (INTEGER) – Primary Key
TIME_OUT (DATE)
MILEAGE_OUT (INTEGER)
CONFIRMATION_NUMBER (INTEGER) – Foreign Key
ACCOUNT_NUMBER (INTEGER) – Foreign Key
LICENSE_NUMBER (VARCHAR (10)) – Foreign Key
RESERVATION CONFIRMATION_NUMBER (INTEGER) – Primary Key
RESERVATION_TME (DATE)
PICK_UP_DATE (DATE)
RETURN_DATE (DATE)
CONFIRMED_PRICE (DECIMAL(10,2))
PHONE_NUMBER (VARCHAR (20)) – Foreign Key
CAR_TYPE (VARCHAR (10)) – Foreign Key
CREDIT_CARD_NUMBER (VARCHAR (20)) – Foreign Key
RETURN_CAR RETURN_NUMBER (INTEGER) – Primary Key
TIME_IN (DATE)
AGREEMENT_NUMBER (INTEGER) – Foreign Key
THIRD
PARTY
CUSTOMER ACCOUNT_NUMBER (INTEGER) – Primary Key
NAME (VARCHAR (40))
ADDRESS (VARCHAR (60))
PHONE_NUMBER (VARCHAR (20))
Apache Rent A Car – Chapter 11
Introduction
This chapter discusses step 4 of the seven-step process for object-oriented program design. This step is:
Step 4. Design the graphical user interface.
Apache Rent A Car Assignments –Chapter 11
Apache Rent A Car Graphical Interface
This case study asks the student to produce a bill. The other case study “Giant Forest Inn” did not have this assignment because the case study included a bill in its description.
1. Design an itemized bill to be given to the customer when the car is returned to Apache, showing the charges for the rental.
There are many ways to show a design for a bill for users to view. The best way is to use a common tool such as Microsoft Word. In this case that is what we did. A table was used to assist with horizontal and vertical alignment.
Note that the case study did not give values for the additional charges. We chose $9.99 for the damage waiver, $5.99 for liability insurance, and $4.99 for the personal accident insurance. In this example the customer declined the liability insurance, which is for drivers who do not have valid insurance on their own cars. Customers who are from out of the country most often buy liability insurance. You could suggest any reasonable values. Recall these are daily charges.
Apache Rent A Car

Bill for Car Rental

Customer:
July 16, 2005
Leona Fernbee
123 Any Street
Any City, CA 92999
Item Detail Quantity Price Amount
Rental for Ford Focus Out: Thur., July 14, 2005
In: Sat., July 16, 2005
10:00 AM
09:30 AM

2 days

$24.99

$ 48.98
Mileage Charge
Mileage Out:
Mileage In:
(500 free miles)
4835
5012

177 miles

0.20

$ 0.00
Damage Waiver Accepted 2 days $9.99 $ 19.98
Liability Insurance Declined
Personal Accident Ins. Accepted 2 days $4.99 $ 9.98
Damage None
Fuel Returned tank full
Subtotal $ 78.94
Taxes (Airport) 10% $ 7.89
Total Due: $ 86.83

2. Design a portion of a class diagram, which will produce the this bill.
Note that most of the system is included, except for the classes Payment and Credit Card. For simplicity the façade is often omitted in these diagrams to make them more readable.
3. Design a screen or screens for a graphical user interface to be used for entering the information required when a customer picks up a car. Be sure to permit the rental of cars with or without a reservation.
There are many ways to create a screen mock-up for users to view. The best way is to use a tool such as Microsoft Access. We have used a Java Integrated Development Environment (IDE) because of our familiarity with the tool.
The first screen shown assumes a prior reservation. The user (probably the car rental clerk) enters the confirmation number; then the reservation is displayed, and the car type and price are shown. Then the user enters all the data required for a rental. Note that the car is assigned by the system. The screen is full due to the entry of up to three drivers. Note that the first driver must be the renter. Also there is a provision to enter a third party account number. Check boxes are used to select the extra charges. Upon completion a contract is printed and the agreement number is shown on the screen.
What is not shown is the dialog box for the employee to enter the mileage out. As the customer could actually be the user of this screen, a separate screen or dialog box is used to query the employee for the mileage out.
It is assumed if a customer does not have a prior reservation, the user begins with the reservation part of the system.
The second screen begins with the entry of the customer. As customers are never stored, there is no provision for querying an existing customer. The second portion of the screen is used to enter the reservation with credit card. After that, the reservation confirmation number is displayed.

Apache Rent A Car – Chapter 12
Introduction
This chapter continues to discuss step 4 of the process for object-oriented program design. This step is:
Step 5. Design the interface to the presentation layer.
The state transition diagrams clarify the operation of the screens shown in Chapter 11.
Apache Rent A Car Assignments – Chapter 12
Apache Rent A Car Graphical Interface
Develop a coordinated pair of state transition diagrams to model the details of the interaction between an Apache employee and the automated system for picking up a car. Base these diagrams on the screen design you prepared for the assignment in Chapter 11.
The first diagram describes the user, and the second diagram describes the computer. These state transition diagrams were created using Rational Rose software.