car rental design

CM1033D Advanced Software Development UoB 10035397

SCIM University of Bradford

Page | 1

CM1033D ADVANCED SOFTWARE ENGINEERING COURSEWORK

Car Rental Design

[email protected] (UoB 10035397)

Abstract

Object oriented software development principles entail “storing data and related

operations together within objects and sharing commonalities between classes of

objects.” [1] Presented in this report is an object oriented software design of the

inherent component of a typical car rental company. Much emphasis was laid on

the essence of the car rental operation and how to adapt the product to a more

specific or changed environment. It was assumed that all objects are persistent.

Introduction:

Object-oriented methodologies tend not to follow a particular custom or order.

One among the necessary ingredients involved is the need to model the system

static structure (deciding what the logical or physical parts of the system should

be and how they should be connected together) and dynamic behaviour

(deciding how the static parts should collaborate).

The initial phase of the design involves the description of the functional units of

the car rental system; this is followed by a detailed requirement specification.

The business scenarios and rules mined from the requirement specification will

then be presented with use case diagram and subsequently analysed

dynamically with sequence diagram as well as with events protocols between the

operational unit and other system interfaces in order to realise attributes and

operations (methods) for each candidate class. The outcome of the analysis will

then be applied to a specific programming environment, there by yielding an

implementable code. The life history of objects that are central to the car rental

company will be examined using state chart diagram.

Functional Areas of a Typical Car Rental Company

The functional areas of a typical car rental company include the following:

mailto:[email protected]



Page | 2

Rental Operation

This is the primary business activity of any car rental company. The fundamental

units that made up the rental operations include rentals and reservation

management (billing inclusive) strategy.

Accounting

The accounting otherwise called finance ensures that all payments accruing from

reservation and other sources are properly accounted for. This department

coordinates and keeps record of all revenue generated from the companies

operations as well as expenditures.

Asset Management:

The asset management and control is responsible for products management and

services, the functions include providing fleet availability, vehicle scheduling

(such as pick up and return) services and maintenance. The Asset Management

unit ensures the availability of cars for rental contracts to users at their

designated branches in various locations.

Planning

The planning unit co-ordinates the activities between the various units involved

in the car rental company. The planning decides branch locations, tariff plans,

sales, advertising and marketing roles.

System Description

The car rental company under design is assumed to have branches in various

towns and in several countries. At each branch, cars (classified by car category)

are available for rental. Each branch has staffs who handle rentals.

Rentals

Most rentals are by advance reservation. The rental period and the car group

are specified at the time of reservation. The company also accepts immediate

('walk-in') rentals, if cars are available.

At the end of each day, cars are assigned to reservations for the following day.

If more cars have been requested than are available in a car category at a



Page | 3

branch, the branch staff may ask other branches if they have cars they can

transfer.

Returns

Cars rented from one branch of the company may be returned to a different

branch. The renting branch must ensure that the car has been returned to some

branch at the end of the rental period. If a car is returned to a branch other

than the one that rented it, ownership of the car is assigned to the new branch.

Servicing

The company also has service depots, each serving several branches. Cars may

be booked for maintenance at any time, provided that the service depot has

capacity on the day in question.

For simplicity, only one booking per car per day is allowed. A rental or service

may cover several days.

Customers

A customer can have several reservations but only one car rented at a time. The

company keeps records of customers, their rentals, and bad experiences (such

as late return, problems with payment, and damage to cars). This information is

used to decide whether to approve a rental.

Business Rules

The application must deploy rules that can manage these activities:

Accepting new reservations for new and existing customers

Determining eligibility for car rental based on the customer’s age

Providing cars to customers when they come for pick-up

Handling car upgrades when there is a shortage of cars

Cars are rented for a specific number of days, after which they should be

returned.

A car can be rented only if it is available.

No credit is allowed; customers must pay cash or by card.



Page | 4

Customers must make a deposit at pick-up time of the estimated rental charges.

Rental charges depend on the car class.

When a rented car is returned, the deposit is used to pay the rental charges.

If a car is returned before the due date, the customer is charged only for the

number of days the car has been used. The rest of the deposit is reimbursed to

the customer.

Customers who return a rented car after its due date are charged for all the days

the car has been used, with an additional percentage charge for each day after

the due date.

Failure to return the car on time or to pay a debt may result in the suspension of

renting privileges (Adapted from Model Systems Ltd).

Use Case Analysis

The intended purpose of the system is here by conceptualised with use case

analysis and diagram.

Any user (customer or rental staff) can look for car models in the catalogue, by

(1) browsing the car model index, (2) global search or (3) specific searching of

the categories, makes etc that the user is interested in. The user is shown the

result as a collection of matching car models, along with basic information such

as car model name. The user can then choose to view extra information about

particular car model objects such as a description. The user (who has been

validated) can make reservation (by phone or through website), make payment

(in this case with a debit/credit card), and an invoice will be generated. The user

may decide to cancel the reservation, or if previously has rented a car can check

his rental history, or view outstanding reservations and rentals. After a

successful contractual agreement, the user can then pickup the car and after the

expiration of the hired period return the car to and from their desired rental

location.

Actors:

User: user in this context refers to the person using the software system for

rental activities. The user can be a receptionist or car rental staff as well as the

customer for a highly automated system.



Page | 5

Use Cases:

(1) Look for car model (2) Global search (3) Browse index (4) View search

results (5) View car details (6) Make reservation (7) Make payment (8) Pick up

car (9) Cancel reservation (10) Return car

Use Case Diagram

Fig. 1 Use case diagram for car rental operations

System

User

Look for Car Model Browse Index

Pay Bills

Return Car

Pick-Up Car

Early Return

Late Return

View Car Details

<<extend>>

<<extend>>

<<extend>><<extend>>

<<include>>

<<extend>>

Global Search<<extend>> <<extend>>

View Results

Make Reservation

<<extend>>

<<extend>>

Cancel Reservation <<extend>>

View Rentals

Customer

Rental Staff



Page | 6

Business Scenario

This use case begins when a customer indicates he wishes to make a

reservation for a rental car. Either by visiting a branch or the company’s

site.

The system prompts the user (anyone that has legal/valid access to the

system) for the pick-up and return locations of the reservation, as well as

the pickup and return dates and times. The customer indicates the desired

locations and dates within his price level.

The system prompts for the car model, category or make the customer

desires. The customer indicates his choices.

The system presents all the collection of all matching cars available at the

pickup location for the selected price per mileage, date and time etc.

If the customer requests detail information on a particular car model, the

system presents this information to the customer.

If the customer selects a car model for rental, the system prompts for

information identifying the customer (full name, telephone number, email

address for confirmation, credit/debit card details etc.). The customer

provides the required information.

If the customer indicates "accept reservation," the system informs the

customer that the reservation has been completed, and presents the

customer a reservation confirmation.

Candidate Class Identification

We use the above scenarios to identify the business objects of our intended

system. The Class Responsibilities and Collaborators (CRC) method was adopted

due to its greater flexibility over the other methods and the following objects

were identified:

Customer: someone who checks on the availability of car models, makes

contractual arrangement for reservation of his chosen car model, takes cars out,

returns cars, and is billed for this service and who in return makes payment.

Customer in this context can also refer to someone whose identity and credit-

worthiness have been validated and who, therefore, has access to special

services (such as making Reservations by phone, or over the Internet).



Page | 7

Car: an instance of a CarModel in a car Inventory for Rental purposes.

CarModel: A model in the catalogue, available for Reservation.

CarMakes: a particular car model based on its make.

CarCategory: a particular grouping of a car model.

Car Details: detailed description of a particular car.

Car Inventory: Collection of cars at different branches or locations. This serves

as the companies main car deport. The car rental agency has various branches.

The stock inventory of the branch is updated at each pick-up and return

Rental Location: the various branches and rental points where cars can be

picked and returned.

Reservation: an agreement between a customer and the rental company for

provision of car rental services for a specified period of time. A rental agreement

contains:

Billing: the sums charged on customers for car rental services provided (this

may include charges for renting per period of time or mileage, insurance or extra

charges due incurred due to default in agreement). These sums go to the

accounting department. Pricing must be evaluated at each customer touch point

(making a reservation, picking up the car, returning the car, and changing the

terms of the rental agreement).

Payment: the amount paid by the customer for the services.

Rentals: Cars currently on rental. At the end of each working day, the car rental

agency assigns cars to customers who made a reservation for pick-up the

following working day.

Only cars that are physically present and available in the car rental agency

branches may be assigned to a customer.

If there are not enough cars in a group to meet the demand, and if there is

capacity, a free upgrade is given (that is, a car of the next higher group may be

assigned at the same rental rate)



Page | 8

Objects Relationship diagram

Fig. 2 Static Model of a car rental company

Behavioural Analysis of the System

The analysis sequence diagram below depicts the behaviour of the system. As at

this level, it is assumed that payment is processed during car return.

The Sequence diagram in fig. 3 is a dynamic representation of the reservation

use case.

It explains how the system will be used for reservation purposes. From when the

user decides to rent a car until when he is issued with confirmation document

that his reservation is successful.

At this stage the messages are represented by generic object oriented terms

since there is not yet a decision on what programming environment will be

adopted. The use case controller object was introduced as a generic object

rather than the traditional use of graphical user interface object.



Page | 9

Fig. 3 Analysis level sequence diagram for reservation

Reservation

User UCController RentalLocation Customer CarInventory CarModel ReservationCarModelDetails

1 : Make Reservation()

2 : Prompt for ID()

3 : Enter Profile ID() 4 : Obtain Profile()

5 : Obtain Customer()6 : Prompt for Location e.t.c()

7 : Provide Location etc.()

8 : Retrieve CarModels for dates and times()9 : Retrieve CarModels()

10 : Match Criteria()

11 : Show Matching CarModels()

12 : Request CarModelDetails()

13 : Retrieve CarModelDetails()

14 : Show CarModelDetails()

15 : Select CarModel() 16 : Prepopulate Profile Information()

17 : Get Customer Information()

18 : Prompt for Complete Information()

19 : User Indicates Choices()

20 : Populate with Reservation Information()

21 : Get Email Address()22 : Send Reservation Confirmation()

23 : Get Confirmation number()

24 : Show Reservation Confirmation()



Page | 10

Class Diagram (Analysis Level)

The behavioural analysis (sequence protocols/messages) and the relationship

between the rental operation and the other functional areas led to the

identification of the various attributes of each of the candidate classes.

Fig. 4 Analysis class diagram showing classes and attributes



Page | 11

State Diagram

The basic idea behind the state chart is to explain the life history of an object.

When a Member reserves a car model, the reservation is initially Pending to be

processed. The Reservation becomes Available if, some time later, a suitable

unreserved car is found in the display area of the car park, or if one is returned

by a customer. In this case, the car is moved to the reserved area. If no car

becomes available for a particular reservation within a week, the reservation

becomes OnReview: the customer must be contacted, so that they can cancel

the reservation, or ask for it to be renewed for another week. If the customer

cancels or can’t be contacted within few days, the reservation is Concluded.

Once a reservation is Available, the customer must be notified within few days;

if the customer can be reached, the reservation is Collectable otherwise it

becomes Displayable (a Car that was moved to the reserved area must be

returned to the display area).Once a reservation is Collectable, the customer

must collect the car within three days: if they do collect, the reservation is

Concluded; otherwise, the reservation becomes Displayable. Once a Displayable

Reservation’s Car has been put back in the display area, the Reservation is

concluded. At any time, the customer may cancel the Reservation. The system

will keep its user informed as to the state of current (not yet concluded)

reservations, so that they can take appropriate action.

Fig. 5 State Chart Diagram for Reservation

Available

Concluded

Pending

Storable

OnReview

Collectable

no car found

car found

car returned

customer notified

customer collects

car stored

no car arrives

customer renews

customer cancels

customer unreachable

customer cancels

customer cancelscustomer no show

customer cancels

customer unreachable

customer cancels



Page | 12

Detailed Design

At this stage each business abstraction in the analysis level classes is

transformed into design classes that are implementable representations, taking

into account the properties of the target execution environment. The chosen

environment in this case is the J2EE platform due to its strength relative to the

design problem.

J2EE application servers provide services such as threading, pooling,

transaction management, security and persistence support hence all effort

can thus be focused on implementing business logic.

A subsystem, DataAccess Object has now been added to the analysis class in

order to abstract and encapsulate all access to the data source. The Data Access

Object acts as an intermediary between the application and the database. It

moves data back and forth between Java objects and database records. It also

allows ripple effects from possible changes to the persistence mechanism to be

confined to a specific area.

The protocols between the rental operation unit and the other interfaces and the

chosen programming environment (Java) had led to the mining of operations

(methods) for the classes. Notice that there is addition of two more classes

(Data Access and Billing). The behaviour of the system with the new classes will

now be examined using a sequence design level diagram.

Design level sequence diagram for reservation

The built in libraries in the J2EE architecture adapted has a reservation servlet,

which is a controller that knows the steps that have to be carried out to allow a

customer to reserve a vehicle. The customer indicates that he wishes to reserve

a specific CarModel. This request is posted to the servlet, which asks the

CarInventory to mark the Car, denoted by a CarId, as Unavailable temporarily.

This marking will prevent other rental customers from trying to reserve the same

Car. The CarInventory forwards this request to the Car object for the Car

selected by the customer. The CarInventory does this with

the mark(expiry) operation, in which the expiry parameter is a timeout period in

case the customer leaves the page without completing the reservation.



Page | 13

Fig.6 Design level sequence diagram for reservation

Reservation

User ShowCollectionJSP RenterInfoJSP Reservation ResvnServlet DataAccessCarInventoryCustomer Car BillingServletBilling

1 : Select a Vehicle from Collection()

2 : POST vehicleId()

3 : mark vehicleId()

4 : mark empty, update car status()

5 : getCustomerId()

6 : create()

7 : populateCustomerId()8 : retrieveCustomerId()

9 : fill dbRecord()

10 : ReqDispatcher.forward to RenterInfo Page()

11 : forwards to control()

12 : getCustomer object from session()

13 : obtain data field contents()

14 : getPayment()

15 : getAmount()

16 : generateInvoice()17 : shows renter information with a comfirmation prompt()

18 : continue()

19 : update Customer and CustomerProfile()

20 : POST RenterInfoDone()



Page | 14

After marking the vehicle, the servlet needs to prepare for displaying the Renter

Information page, in which the customer verifies the information. The servlet

obtains the CustomerId. With this ID, the servlet creates a Customer object,

directing it to populate( ) its instance variables using the customer ID. The

Customer object now follows the pattern of requesting its content as a

dbRecord from the DataAccess object. With this processing complete, the servlet

is ready to display the RenterInformation page, which it does with a

RequestDispatcher.forward( ) operation. The RenterInfo JSP page is now active

and ready to obtain information from the Customer object and corresponding

data will display for confirmation. After that the RenterInfo page is displayed to

the customer's browser for confirmation and completion. The customer affirmed,

changed, or entered data onto the RenterInfo page, and then ready to continue

with billing process which follow similar process (now with Billingservlet that

interact with a payment gateway or interface) as shown on the sequence

diagram of fig.3 the reservation. The underlying JavaBeans will now update the

information on the screen data. Finally the RenterInfo page posts to the servlet,

indicating the renter information is complete. The system then presents the

summary information on the reservation as Invoice.

Design level Class Diagram

The analysis class diagram will now be fully developed with the additional

attributes and methods mined from the J2EE library and sequence protocols.

The system design was carefully partitioned into parts and their interconnections

to aid maintenance.

Design Decisions

One of the major design decisions worth mentioning is the choice of the

programming environment. J2EE architecture was chosen because of its built in

libraries which include Java beans that perform most of the business

transactions and other back end functions. “The J2EE application servers also

provide services such as threading, pooling, transaction management; security

and persistence support hence all the developers effort can thus be focused on

implementing the business logic.” [2]



Page | 15

Fig.7 Design Class diagram



Page | 16

Again the Data Access Object adapted acts as an intermediary between the

application and the database. “It is used in order to abstract and encapsulate all

access to the data source as well as to move data back and forth between Java

objects and database records. It also allows ripple effects from possible changes

to the persistence mechanism to be confined to a specific area.” [3]

Other feasible alternatives to the design methodology could be the Unified

Process or other traditional methodologies where the system development is

standardized to custom phases of inception, elaboration, construction and

transition. The major challenge is that of maintenance and reuse.

Maintenance Issue

The car rental system was designed and developed with maintainability in mind.

The ease with which the car rental software can be corrected when deficiencies

occur; how it can be expanded to satisfy new requirements could be seen on the

simplicity of the system which was considered more important to ‘extra’ details

or completeness. Global variables were used in order to eliminate the effect of

changes to a module whenever a local variable used changes. It is obvious that

changes in car price per mileage, car category etc will only effect a change in its

immediate class but not other classes, and this is a clear demonstration of a

system with high cohesion within classes and low coupling between different

classes performing different roles and interfaces. This allows for extensibility in

software design; a new class implementing an interface can be written to replace

a current dependency in some or all situations, without requiring a change to the

dependent class.

Critique

Strengths

Design with maintainability in mind hence:

Easy to understand the code; to find attributes or methods that is related to a

specific problem or change.



Page | 17

Easy to make detect and verify a change with low risk of breaking the existing

features i.e. easy to adapt a new perspective to the software.

Weakness

The inclusion of DataAccessObject despite its stated advantages may compound

the system especially when there is a simple change in the database involving a

primary key. The anomaly can be overcome by the logical isolation of the

datasources with a factory, DB objects and persistence interface (subsystem that

specializes in getting information in and out of a datastore).

Oscar Car Rental Case Study

The next task is that of adapting the design to a specific car rental company

Oscar (in France) which currently has seven classes (categories) of cars and one

price list for all branches. The issues of concern are that of promoting the

business and Oscar sees only three ways (as listed below) in which the business

might grow while maintaining the same planning and operating system. Thus by:

1. Creating more branches, both in France and other countries,

2. Buying other car rental companies,

3. Enfranchising other car rental companies.

Where a customer hires a car from one branch and returns it to a different

branch there is an additional charge, which depends upon the two branches.

Where one of the companies "borrows" a car from another company in order to

rent it to a customer, the company that owns the car should have some

compensation, possibly a share of the rental income. Oscar believes that might

also be appropriate between branches, and that leads him to think that it would

be no bad thing if each branch were to have its own management accounts

provided.

Adaptation

Consider the issue of growing as listed above, one of the event trigger is the fact

that there will be more additional rental locations hence more cars in the car

inventory. Changes in rental location will only require few additional attributes in



Page | 18

that same class e.g. the locationId. More additional cars will be dealt with by

adding new carOwnerId. The issue of branches in other countries had been

included in the original design hence no resultant effect on the system. The

event that a customer can hire a car from one branch and returns it to a

different branch will have no effect on the system since all cars have carOwnerId

that matches the owners account. Each branch having different account can be

fixed by creating separate accountId for each branch in the Billing class. The fact

that the car status keeps changing as detailed with state chart diagram in fig. 5

above necessitates that each carStatus should be updated automatically through

a mechanism that will always notify and update the system at real time while

maintaining consistency between related objects without making classes tightly

coupled.

This can be resolved by implementing observer pattern in the design, i.e. one-

to-many dependency between objects so that when one object changes state, all

its dependents are notified and updated automatically.

Only the affected components in the class diagram in fig.7 will be referenced,

the subject keeps track of its observers and provides an interface for attaching

and detaching Observer objects. The observers in turn define an interface for

update notification. ConcreteSubject (Rentals, Car class etc.) i.e. the object

being observed stores state of interest to ConcreteObserver (CarModel,

Reservation etc.) i.e. the observing objects, it sends notifications to its observers

when its state changes. Whereas the ConcreteObserver stores the states that

should stay consistent with the subject's at the same time implementing the

Observer update interface to keep its state consistent with the subject's.

In this case as the status of car in both Rentals and Car class changes (Pending,

Collectable, Available, Lost etc.) it automatically notifies the CarModel which is

displayed on the view aspect of the software as well as the reservation hence

billing class to be refreshed/updated.



Page | 19

Fig: Oscar’s observer design pattern

At the moment the observers need to know the states of most of the attributes

in the concrete subjects (such includes rentalId, carOwnerId, carStatus etc)

hence the push model was considered best suited for the design; however in

case of network traffic and application challenges the pull model (where the

observers select only the crucial attributes and register to observe) is

implemented.

Conclusion

Indeed CM1033D research coursework have exposed many of the various “forces

that must be resolved and balanced in design of software together with

techniques and established solution strategies” for advanced software

development.

The knowledge of essential and accidental features of software design was

explored; the ability to design and develop software with maintainability in mind



Page | 20

was carefully studied; and the concept of adaptability, high cohesion and low

coupling in software design was studied and applied.

However the popular clause “there is no silver bullet” still applies here! The

assumption made about persistence should be developed further.

References

[1] C. F. Kermerer, Software Project Management, Reading and Cases.

[2] Erich Gamma et al (The Gang of Four), Design Patterns, Element of

Reusable Object-Oriented Software, Copyright ©1995

[3] Frank Buschmann et al, Pattern-Oriented Software Architecture; A

system of Patterns, Volume 1, Copyright ©1996

[4] S. Perdita, R. Pooley; USING UML, Software Engineering with Objects

and Components, Second Edition.

[5]http://www.ibm.com/developerworks/rational/library/content/RationalEdge/a

ug04/5670.html

car rental design

Documents