Building a heavy business rules application

5 Building a heavy business rules application

5.1 Introduction

EU-Rent is a case study developed by the Business Rules Team. It was designed with the purpose of bringing together all kinds of business rules (BR) in a comprehensive example. For more details on EU-Rent see www.eurobizrules.org/eurentcs/eurentoview.htm [Broken Link]. The case study offered a good opportunity to verify whether CommunSENS could deal with such a complicated process.

Overview of EU-Rent
EU-Rent is a (fictitious) car rental company with branches in several countries. It provides typical car rental services:

Different types of car are offered, organized into groups. All cars in a group are charged at the same rate
Cars may be rented by reservations made in advance, or by “walk-in” customers on the day of rental
Cars are picked up from EU-Rent branches at the start of a rental, and may be returned to different branches.
Customers may join the EU-Rent loyalty club, and accumulate points that they can use to pay for rentals
EU-Rent from time to time offers discounts and free upgrades, subject to conditions
EU-Rent records “bad experiences” with customers (such as speeding fines or damage to car during rental) and may refuse subsequent rental reservations from such customers

This case study deals with only a part of EU-Rent’s behaviour, triggered by the following kinds of event:

Accept new reservations for new and existing customers
Assign cars to the day’s rental agreements
Select the best discount that the rental agreement qualifies for
Handle reservations where the requesting customer has had “bad experiences”
Transfer the ownership of a car when a car is returned to a branch different from the pick-up branch.

To get EU-Rent running (version 5, 10/11/2004) we used:

53 Subjects (Cars, renters, etc.);
80 sentences (ex ante and ex post)
51 small procedures (defining default actions, enforcing procedural BR’s).

The purpose of this section is to show how such an application can be embedded in the knowledge engine.

5.2 Taxonomy

Most application that focus on commercial activities deal with people, organizations, means, etc. In order to avoid defining such entities over and over again, a taxonomy has been developed. The idea is that once you have a suitable taxonomy it should be easy to add new specializations to it. In the lower part, figure 5.1 gives an example for the subject Person. The first sentence (PPersonXA1) says that a person is a specialization of a relation. The second sentence says that such a person can become an employee or a contact person (of an organization). Moreover, any person must have personalia (first name, family name, gender, etc.).
To add the relevant entities of the EU-Rent case to the taxonomy additional sentences can be added like

Utterance 1: A Driver Always Is 1 Of The Persons.
Utterance 2: A Car Always is A Means.

Figure 5.1: Taxonomy

The taxonomy is embedded in a form called PProcess. This form contains general functionality like an agenda, mail boxes, internet etc. This functionality is positioned at the lower side of the form.

5.3 Specific functionality

At the top side of the form there is room for specific functionality. In this case the structure of the EU-Rent organization is given together with a part of the rental process. As can be seen in figure 5.2, this organizational structure is also hooked to the taxonomy.

Figure 5.2: Organixation of EU-Rent

5.4 Defining the process

The next step is defining the rental process by formulating relevant ex post sentences. Figure 5.3 shows some sentences that must be true for rentals. The first sentence prescribes that for every rental that is not ended there should be a travel schedule. The second sentence dictates that for every rental with a travel schedule there must be an assignment of a car and driver(s). The third sentence says that after these assignments are made, there must be a rental contract and a provisional charge on the credit card. Moreover, it should be checked that the car is fully fuelled. When all this is done the car can leave.

Figure 5.3: Rent process

The state of the rental process is mirrored in the dossier by adding a node to the tree. If the node has a red cross associated with it then there is at least one sentence that is not true for that node (or for any of its children). Basically, for any process, the user must follow the crosses and perform appropriate actions to make the sentences true. Consequently, if all nodes have a green check mark the dossier is ready.

Sometimes it is useful to present a process as a list of consecutive actions. In this example such a view is presented at the top right part of the illustration. By clicking a cell the necessary action will be executed.

5.5 Towards solid ontology's

In the form PProcess a first attempt has been made to incorporate several kinds of knowledge. As mentioned before the form is equipped with some general knowledge of the world (taxonomy, agenda, mail, etc.) Besides these aspects, the basic principles of bookkeeping, ordering, delivering, etc. have been formulated. The main goal of the future development will be to verify, validate and extend this general knowledge. If it is possible to create solid ontology's, developing new applications can really become modulair.

2 Elements