Exception Handling and Parameterized Polymorphism
Procedure
Consider a use case of the car rental application as follows:
Use Case Name: Release a Vehicle (to a customer)
Description: A customer arrives to acquire the vehicle and depart for desired destination. The vehicle reservation contract is signed and the vehicle is released to the customer.
Actors: Front-Desk Office Executive, Customer
Basic Flow ("Sunny Day Scenario"):
A customer comes to the office to acquire a vehicle.
The Office Executive locates the vehicle reservation contract by means of the reservation number and/or customer name. [Exception: Required vehicle type is not available due to late arrivals.]
The customer signs the contract and the Office Executive gives the keys to the vehicle.
The Office Executive then marks the contract active by entering the vehicle release date (today's date) onto the vehicle reservation contract. The use case terminates at this point.
Exceptions ("Rainy Day Scenario"):
Required vehicle type is not available due to late arrivals:
Raised when the reserved vehicle is not available due to late returns. The customer is informed of the situation and told about the other vehicle types that are available. The customer is offered an incentive to accept another vehicle type. If the customer is not satisfied, the reservation is cancelled without penalty charges. The customer either accepts another vehicle type or cancels the reservation.
Postconditions: The customer departs with the vehicle and the reservation contract is marked active, or the reservation is cancelled.
Stakeholder: Reservation department
Experiment 1 recap: Use case was completed. Noun phrases and conceptual classes were identified, and the domain object model was constructed.
Experiment 2 recap: The verb phrases were identified and the method invocation between the objects were ordered to construct the time sequence model.
Experiment 3 recap: The datatype of attributes and the signature of the methods were identified for every class. The relationship between classes was defined to construct the class diagram.
Experiment 4 recap: The class Customer was implemented in Java following the constraints given on the attributes and its accessor and mutator functions.
Experiment 5 recap: The aggregation and composition relationship of the class Customer and class Vehicle with class Reservation was implemented in java.
Experiment 6 recap: The generalization of the class Customer and class Exec as the class Person was implemented in Java.
Experiment 7 recap: The subtype polymorphism was implemented in class Person and the upcasting and down casting of Person, Customer and Exec object was implemented in Java.
Experiment 8 recap: The creational patterns – Factory, Singleton, and Builder were implemented.
Experiment 9 recap: The structural patterns – Decorator and behavioural pattern – Iterator were implemented.
Steps to complete current experiment:
Now, the steps to implement the as follows:
Step 1: In the TestDriver class, create an ArrayList of Person and insert Customer and Exec objects. Raise Type mismatch error and handle it with class cast exception. Similarly access uninitialized object and handle it with null pointer exception.
Step 2: In the TestDriver.Java, add the following methods with ArrayList of Person as input:
i. countPersonwithEmail-counts any list of customer, person or clerk to provide the number of members with email.
ii. countPersonwithPhone- counts any list of customer, person or clerk to provide the number of members with a valid Phone number.
iii. countCustomers – counts any list of customers or its super classes to provide the number of customers in the list.
iv. countClerk– counts any list of clerks or its super classes to provide the number of clerks in the list.
v. displayall– displays the description of customers and clients.
Hint: some of these methods-- but not all -- should use wildcards in the type declarations.
Output: Execution of the TestDriver code is displayed for steps 1 and 2.
Note: Work on the experiments sequentially.