CM1033D Advanced Software Development

UoB 10035397

CM1033D ADVANCED SOFTWARE ENGINEERING COURSEWORK

Car Rental Design Page | 1 H.isah@bradford.ac.uk (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:

SCIM

University of Bradford

CM1033D Advanced Software Development Rental Operation

UoB 10035397

This is the primary business activity of any car rental company. The fundamental units that made up the rental operations include rentals and reservation Page | 2 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

SCIM

University of Bradford

CM1033D Advanced Software Development

UoB 10035397

branch, the branch staff may ask other branches if they have cars they can transfer. Returns Page | 3 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 customers 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.

SCIM

University of Bradford

CM1033D Advanced Software Development

UoB 10035397

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 Page | 4 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.

SCIM

University of Bradford

CM1033D Advanced Software Development Use Cases:

UoB 10035397

(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 Page | 5 car (9) Cancel reservation (10) Return car Use Case Diagram

<<extend>>

Global Search <<extend>>

System <<extend>> View Car Details

Look for Car Model <<extend>> Browse Index <<extend>> View Results <<extend>>

<<extend>>

Pick-Up Car User View Rentals

Make Reservation

Cancel Reservation <<extend>>

<<include>> Pay Bills

<<extend>> Return Car Early Return

<<extend>> Rental Staff Customer

Late Return

Fig. 1 Use case diagram for car rental operations

SCIM

University of Bradford

CM1033D Advanced Software Development Business Scenario

UoB 10035397

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 companys Page | 6 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 creditworthiness have been validated and who, therefore, has access to special services (such as making Reservations by phone, or over the Internet).

SCIM

University of Bradford

CM1033D Advanced Software Development

UoB 10035397

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. Page | 7 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)

SCIM

University of Bradford

CM1033D Advanced Software Development Objects Relationship diagram

UoB 10035397

Page | 8

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.

SCIM

University of Bradford

CM1033D Advanced Software Development

UoB 10035397

Reservation User
Page | 9

UCController

RentalLocation

Customer

CarInventory

CarModel

CarModelDetails

Reservation

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() 11 : Show Matching CarModels() 12 : Request CarModelDetails()

10 : Match Criteria()

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()

Fig. 3 Analysis level sequence diagram for reservation

SCIM

University of Bradford

CM1033D Advanced Software Development Class Diagram (Analysis Level)

UoB 10035397

The behavioural analysis (sequence protocols/messages) and the relationship between the rental operation and the other functional areas led to the Page | 10 identification of the various attributes of each of the candidate classes.

Fig. 4 Analysis class diagram showing classes and attributes SCIM University of Bradford

CM1033D Advanced Software Development State Diagram

UoB 10035397

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 Page | 11 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 cant 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 Reservations 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.

no car found Pending car returned car found Available customer cancels customer unreachable customer cancels customer no show customer cancels Storable customer unreachable car stored Concluded no car arrives customer renews OnReview

customer cancels

customer notified customer cancels

Collectable customer collects

Fig. 5 State Chart Diagram for Reservation

SCIM

University of Bradford

CM1033D Advanced Software Development Detailed Design

UoB 10035397

At this stage each business abstraction in the analysis level classes is transformed into design classes that are implementable representations, taking Page | 12 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.

SCIM

University of Bradford

CM1033D Advanced Software Development

UoB 10035397

Reservation

User

ShowCollectionJSP

RenterInfoJSP

Reservation

ResvnServlet

Customer

CarInventory

Car

Biling

BilingServlet DataAccess

Page | 13

1 : Select a Vehicle from Collection() 2 : POST vehicleId() 3 : mark vehicleId() 4 : mark empty, update car status() 5 : getCustomerId()

6 : create() 7 : populateCustomerId() 9 : fil dbRecord()

8 : retrieveCustomerId()

10 : ReqDispatcher.forward to RenterInfo Page() 11 : forwards to control()

12 : getCustomer object from session() 13 : obtain data field contents() 14 : getPayment() 15 : getAmount() 17 : shows renter information with a comfirmation prompt() 18 : continue() 19 : update Customer and CustomerProfile() 16 : generateInvoice()

20 : POST RenterInfoDone()

Fig.6 Design level sequence diagram for reservation

SCIM

University of Bradford

CM1033D Advanced Software Development

UoB 10035397

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 Page | 14 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]

SCIM

University of Bradford

CM1033D Advanced Software Development

UoB 10035397

Page | 15

Fig.7 Design Class diagram

SCIM

University of Bradford

CM1033D Advanced Software Development

UoB 10035397

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 Page | 16 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.

SCIM

University of Bradford

CM1033D Advanced Software Development

UoB 10035397

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 Page | 17 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

SCIM

University of Bradford

CM1033D Advanced Software Development

UoB 10035397

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 Page | 18 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. oneto-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.

SCIM

University of Bradford

CM1033D Advanced Software Development

UoB 10035397

Page | 19

Fig: Oscars 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

SCIM

University of Bradford

CM1033D Advanced Software Development

UoB 10035397

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 Page | 20 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

SCIM

University of Bradford