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:
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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.
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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.
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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).
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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)
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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.
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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()
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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.
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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()
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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]
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
Page | 15
Fig.7 Design Class diagram
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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.
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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.
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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
CM1033D Advanced Software Development UoB 10035397
SCIM University of Bradford
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