A Slice of MDE with AOP: Transforming

High-Level Business Rules to Aspects

Marı́a Agustina Cibrán1 and Maja D’Hondt2

1
System and Software Engineering Lab
Vrije Universiteit Brussel
Pleinlaan 2, 1050 Brussel, Belgium
mcibran@vub.ac.be
2
INRIA Jacquard - Laboratoire d’Informatique Fondamentale de Lille
Université des Sciences et Technologies de Lille
59655 Villeneuve d’Ascq, Cédex, France
dhondt@lifl.fr

Abstract. We propose an approach that combines MDE and AOSD

to automatically translate high-level business rules to aspects and in-
tegrate them with existing object-oriented applications. The separation
of rule-based knowledge from the core application as explicit business
rules has been the focus of existing approaches. However, they fail at
supporting rules that are both high-level, i.e. defined in domain terms,
and operational, i.e. automatically executable from the core application.
In this paper we propose high-level languages for expressing business
rules at the domain level as well as their connections to the core ap-
plication. We provide support for automatically translating high-level
rules to object-oriented programs and their connections to aspects, since
these crosscut the core application. Separation of concerns is preserved at
the domain and implementation levels, facilitating traceability, reusabil-
ity and adaptability. A prototype implementation and a discussion on
trade-offs are presented.

1 Introduction

Explicit business rules are a widely accepted approach to decoupling implicit

rule-based knowledge, such as regulations, policies, recommendations and pref-
erences, from a software application in a certain domain or business. This de-
coupling is pursued in all phases of the software development process [11, 17].
Ultimately, business rules are implemented either using standard software engi-
neering approaches, such as object-oriented programming languages or XML, or
dedicated approaches, such as rule-based languages.
We have observed in different industrial applications, in domains as diverse
as finance and healthcare, that once the initial application is developed, unan-
ticipated business rules need to be incorporated to accommodate the change of
regulations, policies, etc. As such, we consider as the context of this paper ex-
isting applications that are developed and maintained with traditional software

O. Nierstrasz et al. (Eds.): MoDELS 2006, LNCS 4199, pp. 170–184, 2006.

c Springer-Verlag Berlin Heidelberg 2006
 A Slice of MDE with AOP 171

engineering techniques, in which possibly unanticipated business rules have to

be integrated.
Although existing approaches support the separation of business rules from
the core application, they fail to satisfy two requirements. First of all, as busi-
ness rules are driven by the domain, they need to be defined and understood
by domain experts, who are typically not adept at programming. Therefore, it
is required that business rules are expressed in high-level domain terms, hiding
technical concerns, but are also executable. Moreover, it is more likely that busi-
ness rules expressed in terms of the domain can be more easily reused among
a variety of similar applications in the same domain. Secondly, the connection
of the business rules — i.e. applying the rules at certain events and gathering
the necessary information for their application — crosscuts the core applica-
tion. We have used Aspect-Oriented Programming (AOP) for encapsulating the
connection code in earlier work [2, 4, 5, 8]. At the same time, we identified that
the connection code consists of several recurring issues, which we abstracted in
aspect patterns. However, these patterns are again entirely expressed at the pro-
gramming level and are hence not understandable by domain experts. Therefore,
we also want to express the aspect patterns in terms of the domain, as we do
the business rules.
Our approach consists of defining business rules and their connections to the
existing application in dedicated, high-level languages and expressing them in
terms of the domain. In order to make these rules executable and integrate them
with the existing application according to the connections, we follow a Model-
Driven Engineering (MDE) approach: the rules and connections are automat-
ically translated to object-oriented and aspect-oriented programs, respectively.
The transformations use a mapping from the domain entities, used in the high-
level rules and connections, to implementation elements in the existing applica-
tion. Our approach maintains separation of concerns from the domain level to the
implementation level, thus facilitating traceability of the business rules and their
connections. Moreover, the automatically generated code pertaining to rules and
connections remains separated from the existing application code and therefore
does not interfere with the development and maintenance of the application.
This paper is organized as follows: section 2 presents the high-level rule and
connection languages, expressed in terms of the domain entities of a domain
model. The transformations from high-level specifications in those languages to
implementation are described in section 3. A prototype implementation of our
approach is described in section 4. Related work is presented in section 5. Finally,
section 6 discusses several issues as well as the advantages and limitations of our
approach and conclusions are presented in section 7.

2 A Domain Model for Business Rules

We propose a high-level domain model consisting of: domain entities, business

rules about domain entities, and connections of business rules to the core ap-
plication in terms of domain entities. The domain entities represent the domain
172 M.A. Cibrán and M. D’Hondt

vocabulary of interest and are based on the typical modeling elements that all
data modeling approaches have in common: class, attribute, method and associ-
ation. In this paper we present examples in the domain of e-commerce in which
we identify some typical domain entities used in the rest of this paper: Shop,
ShoppingBasket, Customer and ShopAccount are domain classes; ShopAccount
defines the amountSpent domain attribute, ShoppingBasket defines the applyDis-
count(discount) domain method and associations exist relating Customer with
ShopAccount and ShoppingBasket.

2.1 High-Level Business Rules

Our aim is to explicitly represent business rules at the domain level. Thus, a
high-level business rule language that allows defining rules in terms of domain
entities is proposed. Below we present the features of our high-level rule language
and argue their need:

High-level rules: As proposed by other current high-level rule languages [13,

16, 19, 10], we define a high-level rule as an IF condition THEN action state-
ment, meaning that the action of the rule is only triggered when its condition
is met. The condition and action parts only involve domain entities of a domain
model. Therefore, the business rule metamodel is related to the domain entities
metamodel.
Generic rules: A rule typically defines a comparison between some domain
entity and a hardcoded value, or analogously, a certain action involving a hard-
coded value. In order to avoid the repetition of the same logic in many rules
that only vary these hard-coded values, rules are parameterized with rule prop-
erties. In our language this is done using the PROPS domainClassName AS
propertyName clause.
Connection-aware rules: Rules are parameterized with values from the con-
text in which they are going to be executed. In our language, this is done by
means of the USING domainClassName AS domainObjectName clause. The
details on how a rule is connected to the core application are presented in section
2.2.

An example high-level rule, BRDiscount, is shown below. It applies a discount

on a customer’s shopping basket if the customer has already spent more than a
certain amount of money. This rule involves the identified domain entities of the
e-commerce domain.
BR BRDiscount
PROPS int amount, float discount
USING ShoppingBasket AS basket
IF basket.customer.account.amountSpent >= amount
THEN basket.applyDiscount(discount)

2.2 High-Level Business Rule Connections

When looking at current approaches that advocate the separation of business
rules, we observe that they fail at decoupling the connection of the business rules,
 A Slice of MDE with AOP 173

i.e. applying the rules at certain events and gathering the necessary information
for their application. At the implementation level, rule connections crosscut the
core application and therefore AOP is a good technique for encapsulating it,
as identified and addressed in previous work [2, 4, 5, 8]. This work has shown
that the aspects that encapsulate the rule connections are built up of the same
elements, that vary with certain situations: rule application time, contextual
information and activation time. As such, we identified several aspect patterns for
implementing different kinds of business rule connections. Although these aspect
patterns achieve the decoupling of rule connections, they are entirely expressed
at the programming level, and thus cannot be understood by the domain expert.
Moreover, as many different issues need to be taken into account as part of the
connection aspects, it becomes hard for the application engineer to write these
aspects. Thus, as the same issues recur in every connection aspect, we propose
abstracting them in high-level features of a high-level rule connection language.
This language allows expressing rule connections as separate and explicit entities
at the domain level. Separating rules from their connections (also at the domain
level) allows reusing both parts independently. Moreover, we do not only propose
new high-level abstractions but also provide a set of variations for each different
issue involved in the definition of the rule connections:

Dynamic rule application time: A rule typically needs to be applied at a

well-defined point in the execution of the core application. In our domain model
this well-defined point corresponds to the execution of a domain method and is
expressed by an event. Applying a rule at an event implies the following steps:
1) the core application is interrupted at that point, 2) the rule’s condition is
checked, 3) when the condition is met, the rule’s action is triggered, 4) the core
application’s execution is resumed, taking into account the eventual changes
introduced by the rule. Steps 1) and 2) occur as an atomic unit. In what follows
we refer to the execution of the domain method captured by the event as event
execution. We identify three ways in which a rule can be connected at an event:
a) before an event, meaning that the rule’s condition is checked just before
the execution of the event, which is then immediately followed by (in case
the condition is met) the execution of the rule’s action. For example, a rule
can be connected before a customer is checking out, meaning the point in
time just before the domain method checkout(shoppingBasket) defined in the
domain class Shop is executed.
b) after an event, meaning that the rule’s condition is checked just after the
execution of the event, which is then immediately followed by (in case the
condition is met) the execution of the rule’s action. For example, a rule can
be connected after a customer logs in, which maps to the point in time just
after the domain method logIn() is executed on a customer.
A rule that is applied before or after an event and whose condition is
satisfied executes the new behavior (defined in its action part) in addition
to the original functionality of the core application, possibly modifying it in
two ways: 1) by invoking domain methods that modify the state of the core
application (e.g. the domain method increaseStock(product1, 100) on a shop
174 M.A. Cibrán and M. D’Hondt

domain object, having as a result an increase on the amount of product1

in stock), 2) by using the IS operator to assign new values to information
passed to the rule in the USING clause. As an example of the latter, imag-
ine a product price being provided to a rule at connection time and it being
assigned a new value (e.g., the rule specifies ’price IS price - 10’). The con-
nection language ensures that the new value is considered (instead of the old
one) in the connection context where the rule was applied.
c) instead of an event, meaning that the core application is interrupted just
before the execution of the event, the rule’s condition is checked and if met,
its action is triggered, completely replacing the original behavior captured by
the event. For instance, a payment rule encapsulating a new payment policy
can be connected instead of the payment process, which means in replacement
of the execution of the domain method proceedPayment() in Shop.

In our proposed high-level connection language, a rule connection is specified as

follows: CONNECT brname [BEFORE|AFTER|INSTEAD OF] eventname,
where brname is the name of the rule to be connected and eventname is the
name of the event at which to connect the rule. If brname corresponds to a rule
template, then the PROPS value1, ..., valueN clause is used to instantiate
the rule template to an actual rule.

Contextual rule activation: The application of a given rule can be restricted

to certain contexts. For instance, a discount rule — which would typically be
applied when the product price is retrieved — can be restricted only to those
price retrievals that occur while the customer is checking out, or within the
period of time between the moment the customer logs in and the moment he/she
adds a product to the shopping cart, or not while the customer is browsing the
products. In our connection language, the applicability context of a rule is referred
to as activation time. The activation time is defined in terms of one or more
events in one of the following ways: a) ACTIVATE WHILE event, meaning
that the rule is active during the period of time denoted by the execution of
event, b) ACTIVATE NOT WHILE event meaning that the rule is active
not while event is executing, and c) ACTIVATE BETWEEN event1 AND
event2 meaning that the rule is active during the period of time initiated by the
execution of event1 and terminated by the execution of event2. The specification
of the activation time is optional and when not specified it is assumed that the
rule is always active.
Connection-specific information: A rule expects to receive the information
declared in the USING clause at rule connection time. At the moment the rule
is connected at an event, two situations can occur: 1) the required information
is available in the context of the connection event and thus it can be directly
passed to the rule. The kind of information that can be passed to the rule
depends on whether the rule is connected before, after or instead of an event:
in case of a connection before or instead of an event, the parameters and the
receiver of the domain method are exposed by the event and thus can be passed
to the rule, whereas if the rule is connected after an event, the parameters,
 A Slice of MDE with AOP 175

the receiver and the result of invoking the domain method are available. 2) the
rule requires information that is not available in the context of the connection
event: in order to capture this unavailable information, capture points are defined
as an extra component of the connection specification, as follows: CAPTURE
AT event1, ..., eventN, where event1, ..., eventN are names of events that
capture the moment when the required information is reachable, and expose
it. Moreover, the rule connection language allows specifying how the available
or captured information needs to be mapped to the information required by
the rule by linking the two in mapping specifications of the form: MAPPING
event.infoExposed TO infoRequired.

The example below specifies that the BRDiscount rule should only be con-
sidered in the context of an express checkout (a special kind of checkout which
uses payment information already stored in the shop and that does not require
validation by the client). CheckoutExpress is a high-level event capturing the in-
vocation of a domain method mapped to the checkoutExpress(Customer) method
defined in the class Shop.
CONNECT BRDiscount PROPS 100
BEFORE Checkout
MAPPING Checkout.basket TO basket
ACTIVATE WHILE CheckoutExpress

3 Transforming the High-Level Domain Model

We propose the automatic translation of high-level rules and their connections

to executable implementations in OOP and AOP, as explained in sections 3.2
and 3.3 respectively. As a required initial step, a mapping must exist which
links the domain entities involved in the high-level definitions to a concrete
implementation, as explained in the following section.

3.1 Initial Step: Mapping Domain Entities

In the previous section we described how high-level rules are defined in terms of
high-level domain entities of a domain model. Our approach aims at generating
executable rules from those high-level specifications. Thus, in order to generate
an implementation for the rules which is ready to be integrated with an existing
core application, the high-level entities involved in the rule definition, need to be
mapped to the implementation. We briefly describe this mapping, although it is
not the focus of this paper. Given a domain entity, defining this mapping requires
pointing out which entity or entities in the existing application implement that
domain concept. If this is the case, a one-to-one mapping exists between the
domain entity and the concrete implementation entities. These one-to-one map-
pings are the only ones supported in current high-level languages [13, 16, 19, 10].
However, the definition of the mapping can become more sophisticated when it
is not possible to identify existing implementation entities realizing the desired
domain concept. In this case we say that the mapping is unanticipated or that
176 M.A. Cibrán and M. D’Hondt

we are in the presence of an unanticipated domain entity. In our approach, so-

phisticated unanticipated mappings are supported using AOP. More details on
these mappings can be found in [3].

3.2 Transforming High-Level Business Rules

Following the rule object pattern [1], a high-level rule is transformed into a
class which defines methods implementing its condition and action, with return
types boolean and void respectively. For each property — defined in the PROPS
clause — a local variable is created which is assigned to a concrete object in the
constructor of the class. For each object expected at connection time — defined in
the USING clause — a local variable and a getter and setter are generated. The
bodies of the condition and action methods include the concrete implementations
that result from obtaining the mappings of the domain entities referred to in the
IF and THEN clauses respectively. This translation is done fully automatically.
The code below illustrates the transformation from the BRDiscount business
rule to a Java class.
public class BRDiscount {
int amount; float discount; ShoppingBasket basket;

public BRDiscount(int amount, float discount) {

this.amount = amount;
this.discount = discount;
}
...//getter and setter for basket variable

public boolean condition() {

return basket.getCustomer().getShopAccount().getTotalSpent() >= amount;
}
public void action() {
basket.setDiscountRate(this.discount);
}
}

3.3 Transforming High-Level Business Rule Connections

The connection of business rules crosscuts the core application, as observed
in [2, 4, 5]. In this work we identified the suitability of AOP for implementing
the connection of rules and propose aspect patterns for implementing rule con-
nections. The goal of AOP is to achieve the separation of crosscutting concerns,
not possible when using standard object-oriented software engineering method-
ologies. AOP claims that some concerns of an application cannot be cleanly
modularized as they are scattered amongst or tangled with different modules of
the system [14]: the code implementing a concern is either repeated in differ-
ent modules or split amongst different parts of the system. As a consequence,
it becomes difficult to add, edit or remove such a crosscutting concern in the
system. AOP proposes to capture such a crosscutting concern in a new kind of
module construct, called an aspect. An aspect typically consists of a set of points
in the base program where the aspect is applicable (called joinpoints) and the
concrete behaviour that needs to be executed at those points (called advice).
 A Slice of MDE with AOP 177

A DomainClass2 class BRConnectionAspect {

BRClass rule = newBRClass(x, y, z, ...);
DomainClass1
hook ConnectionHook {
DomainClassN ConnectionHook(connectionMethod(..args)) {
<<domain method M>> execution(connectionMethod);}
captures <<advice kind>> {
execution of
if (rule.condition())rule.action();}}
CONNECT rule PROPS x, y, z, ... static connector BRConnector {
BRConnectionAspect.ConnectionHook hook0 =
[BEFORE | AFTER | INSTEAD OF] event new BRConnectionAspect.ConnectionHook(
<<signature of method mapped to M>>);}

B around() {
rule:
rule.setX(thisJoinPointObject);
X IS 'new value'
BEFORE event if (rule.condition()) {
1 rule.action(); //X assigned by action
MAPPING event.targetObject TO X return proceed(rule.getX(), args0); //new target
} else return proceed(); //proceed normally
}
rule:
before() {
X IS 'new
w val
value'
rule.setX(thisJoinPointObject);
2 if (rule.condition())
rule.action();
}
around() {
rule.setX(args0[j]);
rule: //param i in event's domain method maps to param j of connectionMethod
BEFORE event X IS 'new value' if (rule.condition()) {
1 rule.action(); //X assigned by action
MAPPING event.param_i TO X args0[j] = rule.getX());//replace original param at j
}
return proceed(thisJoinPointObject, args0);
}
rule: before() {
X IS 'new
ew value
vvalue' rule.setX(args0[j]);
2 if (rule.condition())
rule.action();
}

around() {
C
Object result = proceed();
rule: i rule.setX(result);
AFTER event X IS 'new
ew va
value' if (rule.condition()){
1 rule.action();
MAPPING event.returnValue TO X rule: ii return result; i
X IS 'new value' return rule.getX(); ii
} else return proceed();
}
after() {
if (rule.condition()){
AFTER event 2
rule.action();
}
D around() {
if (rule.condition()){
INSTEAD OF event
rule.action();
return rule.getX();
MAPPING event.returnValue TO X } else return proceed();
}

Fig. 1. A: Transformations (1) and (2); B, C and D: Transformations (2) and (3)

Aspect weaving consists of merging the aspects with the base implementation of
the system.
In this section we present the automatic transformation from high-level rule
connections to aspects (based on the patterns identified in previous work). The
use of AOP in this transformation is completely transparent for the domain
expert, as the AOP peculiarities are not exposed in the high-level rule connection
language (as described in Section 2.2). We illustrate this transformation using
JAsCo [18], a dynamic AOP language that introduces two concepts: an aspect
bean which is able to specify crosscutting behavior in a reusable way by means
178 M.A. Cibrán and M. D’Hondt

of one or more logically related hooks, and a connector responsible for deploying
the reusable crosscutting behavior in a specific context and declaring how several
of these aspects collaborate.
Table 1 gives an overview of the proposed transformations in our approach:
each high-level feature is translated into an AOP implementation. However, we
observe and show that these transformations cannot be analyzed independently
of each other, as dependences exist between them. Due to the lack of space, we
illustrate this situation only describing transformations (1), (2) and (3) in detail.
Note however that all of the listed transformations have been implemented.

Table 1. Transformations from high-level rule connection constructs to AOP

High-level rule connection construct transformation output

(1) CONNECT - aspect bean defining connection hook
(2) BEFORE/AFTER/INSTEAD OF - advice in charge of applying the rule
- checks on whether the mapped information
is assigned in the rule
(3) MAPPING - code managing in/out information
to and from the rule respectively
- code injecting the information assigned by
the rule back into the application (if any)
(4) CAPTURE AT - hook capturing the required information
- variables keeping the captured information
(5) ACTIVATE WHILE/NOT WHILE - cflow and !cflow joinpoint respectively
(6) ACTIVATE BETWEEN AND - stateful hook intercepting the application
at two defined events that mark the
start and end of the activation period

Transformation (1) takes as input a CONNECT specification and produces

an aspect bean in charge of creating a new instance of the class implementing
the rule that is being connected and, if the instantiated rule is a template, it
assigns concrete values to the rule properties by means of the PROPS clause.
The aspect bean defines a hook capturing the execution of the connection method
(in JAsCo, aspect beans are reusable and thus the hooks are defined in terms
of abstract methods, which are deployed on concrete methods in connectors).
Transformation (2) takes as input a BEFORE/AFTER/INSTEAD OF event
specification and translates it into an advice in charge of first checking the rule’s
condition — by invoking the corresponding method on the rule — and then
triggering the rule’s action (if the rule’s condition is satisfied).
Any connection specification must include at least elements (1) and (2) and
optionally elements (3) and (4) and either (5) or (6). Although the translation
of each feature is rather straightforward, it is their combination that becomes
complex: the advice (result of transformation (2)) is defined on the connection
hook (output of transformation (1)). Moreover, as a result of this combination,
a JAsCo connector is generated in charge of deploying the connection hook on a
concrete method. This concrete method is only known when a concrete event is
 A Slice of MDE with AOP 179

specified and thus when the construct (2) comes into place. Part A of Figure 1
depicts the combination of transformations (1) and (2).
As mentioned before, transformation (2) generates an advice in charge of
applying the rule. However, depending on the case of a BEFORE, AFTER or
INSTEAD OF connection, a different kind of advice has to be generated. More-
over, determining the kind of advice also depends on whether the contextual
information — passed to the rule using the MAPPING clause — is assigned
to a new value in the rule. This implies the existence of dependencies between
transformations (2) and (3) as their outputs cannot be analyzed independently
of each other. The following three cases are considered, as depicted in parts B,
C and D of Figure 1 (underlined lines correspond to transformation (3) whereas
the rest corresponds to transformation (2)):

B) If the rule is connected before the connection event, then two cases are pos-
sible:
1) the information available in the context of the connection event is passed
to the rule where it is assigned to a new value: we need to be able to access
the contextual domain objects and make them available for the rule, trigger
the rule’s action where the domain objects are assigned to new values, and
retrieve the modified information from the rule to be taken into account
in the invocation of the original behavior captured by the connection event.
Thus, an around advice is created for this purpose, since it allows intercepting
the application at a certain point, adding some extra business logic and
proceeding with the original execution, eventually considering a different
target object and parameters.
2) the contextual information is passed to the rule and not assigned by the
rule: in this case, a before advice suffices to trigger the rule’s action, as the
original event execution does not need to be modified.
C) If the rule is connected after an event, then two cases are possible:
1) the result of invoking the event is passed to the rule: in this case, an around
advice is created which first invokes the original behavior captured by the
event and passes the result of that execution to the rule. Two cases are
possible regarding the return value of the around advice: i) if in the rule the
passed value is assigned to a new value, then the around advice returns that
new value; ii) otherwise, the original result is returned.
2) no result is passed to the rule: an after advice suffices to trigger the rule’s
action, after the execution of the connection event.
D) If a rule is connected instead of the execution of the connection event: the
original execution has to be replaced by the rule’s action. This is achieved in
an around advice which invokes the rule’s action and does not proceed with the
original execution.

Figure 2 illustrates the translation of the high-level connection of BRDiscount

introduced in Section 2.2.
180 M.A. Cibrán and M. D’Hondt

class BRDiscountConnection { aspect bean

BRDiscount rule = new BRDiscount(100);
hook ConnectionHook {
ConnectionHook(connectionMethod(..args0), contextMethod(..args1)) {
execution(connectionMethod) && cflow(contextMethod); }
before() {
global.rule.setBasket(args0[0]); static connector BRDiscountConnector { connector
if(global.rule.condition()) BRDiscountConnection.ConnectionHook hook0 =
global.rule.action(); } new BRDiscountConnection.ConnectionHook(
} float Customer.checkoutBasket(ShoppingBasket),
} float Shop.checkoutExpress(Customer)); }

Fig. 2. Transformation from the high-level connection of BRDiscount to JAsCo

4 Implementation

The entire domain model has been implemented supporting the definition of
domain entities, high-level rules and their connections, as explained in section
2. Parsers for the presented rule and connection languages have been imple-
mented using JavaCC. Following the transformations described in 3.2 and 3.3,
high-level rules are automatically translated into Java classes and high-level rule
connections are automatically translated into JAsCo aspect beans and connec-
tors. During this implementation, the following challenges were tackled:

– dependencies between transformations to AOP: The transformation of a

high-level specification that combines many high-level rule connection fea-
tures is not as simple as concatenating the outputs of the individual trans-
formations for the involved features. On the contrary, the different outputs
have to be combined in a non-trivial way in order to obtain a running as-
pect. This makes the transformation process more complex as dependences
between the individual transformations need to be taken into account.
– consistency checking: At transformation time, the models involved in the
high-level definitions need to be consulted in order to ensure consistency.
Dependences between the models exist as the rule and connection models
refer to elements in the domain entities model. Thus, the domain entities
model needs to be consulted to check for the existence of the domain entities
referred to in the rules and connections.
– nested mappings: During the transformations, the mappings of the involved
domain entities are obtained in order to get an expression only in terms of
implementation entities which is included in the generated code. This process
can become very complex in the case of nested mappings.
– optimized implementations: The generated AOP implementations only in-
volve the AOP constructs that are most adequate for each connection case.

5 Related Work

High-level rule languages are proposed in some existing approaches [13, 16, 19,
10]. However, in these approaches rules are expressed in terms of high-level
domain concepts that are simply aliases for implementation entities and thus
 A Slice of MDE with AOP 181

anticipated one-to-one mappings are required. This is a problem since a high-

level specification of business rules can be discrepant from the implementation of
the core application as they are not always anticipated in the original application.
Thus, one-to-one mappings are not enough to realize unanticipated business
rules. Moreover, connections are crosscutting in the core application and cannot
be expressed at the high level. Some of these approaches translate the high-
level rules to an intermediate language which is understood by a rule engine.
For instance, in [13] high-level rules are mapped to low-level executable rules
expressed in IRL (ILOG Rule Language). However, there is a certain kind of
business rules that do not require the power of a full-fledge rule engine [7]. As
our approach focusses on this last kind of business rules, high-level rules are
directly translated into OOP and AOP implementations, without relying on a
rule engine.
Most of the work that attempts at combining ideas from MDE and AOSD,
focuses on extending a general purpose modeling language (e.g. UML) with ex-
plicit support for aspects. Within this research area, approaches can be classified
as (1) model-to-code (our approach clearly fits in this category) and (2) model-
to-model: (1) Clarke et. al. extend UML to specify composition patterns [6]
that explicitly capture crosscutting concerns, which are translated into aspect
code. Similarly to our anticipated mappings, bindings are used to point to the
concrete implementation elements used to instantiate the patterns. The typical
AOP constructs are not directly exposed at the design level. (2) In [12] standard
UML stereotypes are used to model aspects whereas in [15] extensions of UML
are proposed. They both differ from our approach in that they do not raise the
level of abstraction of AOP constructs and that transformations occur at the
model level. Also in category (2), Gray et al. propose the ECL transformation
language to model aspects that quantify the modeling elements that need to
be transformed and apply the desired changes upon them [9]. Besides the fact
that transformations occur at the model level, this approach differs from ours in
that the modeler is in charge of specifying the desired modeling aspects, writing
and varying the set of rules considered by the transformation engine. In our ap-
proach the modeler is unaware of the use of aspects. The set of transformations
is part of the proposed framework, encapsulating expert knowledge on how rule
connections are translated into aspect code.

6 Discussion

A first issue in our approach is the importance of maintained modularity in

generated code and, related to that, the overhead of using AO technology in
order to achieve this modularity. One could argue that in MDE, the generated
code does not have to be modular since it is typically not regarded by humans.
However, in our particular context, the generated code is integrated with existing
code, which is most likely regarded by developers. Therefore, it is of utmost
importance that the generated code that pertains to rules and their connections
does not affect the existing source code in numerous places. However, we all
182 M.A. Cibrán and M. D’Hondt

know that aspects ultimately affect the existing application at run time even if
this is not visible in the source code. The more mature AO approaches provide
excellent tool support for showing the impact of aspects in a base application.
The same mature AO approaches have an acceptable performance overhead,
especially if one knows which are the costly features to avoid.
A second important issue is the scalability of our approach, in particular when
the number of rules grows. As always, scalability depends largely on the quality
of the tool support. Since this paper identifies, argues and presents the funda-
mental concepts of our approach, we feel that tool support and a quantitative
evaluation is outside its scope. Note, however, such an evaluation of our approach
is currently undertaken using an industrial application in the healthcare domain,
where a huge amount of business rules on healthcare regulations, medications
and so on is present. One of the concerns with respect to scalability is the size of
the domain model in terms of the number of rules. We have found that a set of
business rules typically considers the same domain entities, even if the reference
to some attributes or methods on these entities may vary between the rules.
Therefore, an initial effort is required for building the domain model, whereas a
much smaller effort is required for adapting the domain model as new rules are
added. In [3], a paper that focusses on the domain model and how it is mapped
to the implementation, we discuss possible tools that automate the construction
of the initial domain model.
Another issue related to the scalability of our approach with numerous rules,
is rule interference. In previous work we investigated current AO approaches and
their support for combining rule connection aspects at the implementation level
[4,2,5]. As such, we could extend our high-level languages with explicit constructs
for specifying rule precedence and so on. However, with large amounts of rules,
manually detecting and resolving dependencies is not scalable. Therefore, we
are currently investigating alternative techniques such as critical pair analysis
for automatically, exhaustively and statically determining dependencies between
rules. Since our high-level languages have a limited number of constructs and
use elements from the domain model, such an analysis technique is feasible.
Although in this paper we opted for illustrating the proposed transformations
using JAsCo, their implementation is not bound to the specific features of this
particular technology. We build on the common AOP concepts (i.e. aspect, ad-
vice and joinpoint) and therefore, any other AOP approach that supports the
pointcut-advice model can be used as well. As with JAsCo, in case the chosen
AOP technology is dynamic (i.e. aspects can be added or removed at run-time),
the hot deployment of rules is achieved. Otherwise, in the case of a static AOP
technology, explicit support must exist in the high-level connection language to
be able to dynamically deploy and undeploy rules.
The choice of constructs of our high-level languages is the result of extensive
previous work [2, 4, 5]. As such we are able to express the business rules that we
find in the applications of our industrial partners as well as the ones presented
in books on business rules [11, 17]. However, special business rules, for example
that have time-dependent conditions, cannot be expressed and this is subject
 A Slice of MDE with AOP 183

of future work. Moreover, some applications have knowledge-intensive subtasks,

such as (semi-)automatic scheduling, intelligent help desks and advanced support
for configuring products and services, which require not only the specification
of rule-based knowledge in an if...then... format, but also a rule engine that
supports chaining of rules. This category of rule-based knowledge is considered
in [7], but not at the domain level.

7 Conclusion
In this paper we proposed an approach that combines MDE and AOSD in order
to automatically translate high-level business rules to OOP programs and their
connections to aspects in charge of integrating them with existing object-oriented
applications. Moving to a higher level of abstraction improves understandability
as it becomes possible to easily reason about the rule and connection concerns in
terms of the domain. Moreover, it is possible for the domain expert to add, mod-
ify and remove rules. Furthermore, the use of AOP in the transformations allows
us to keep the implementation of the rules and their connections well modularized
and localized, without invasively changing the existing core application. More-
over, as the mapping from high-level entities to their implementation is made
explicit, rule traceability becomes possible. This work also contributes to raising
the level of abstraction of common AOP constructs, at the same time keeping
domain experts oblivious to the use of AOP. Finally, the use of a dynamic AOP
approach enhances run-time adaptability and variability, as it becomes possible
to dynamically adapt the behavior of the core application by simply plugging in
different sets of business rules, creating different versions of the same applica-
tion. A prototype implementation of our approach as well as a discussion on its
advantages and limitations were presented.
Acknowledgements. This work was carried out during the tenure of Maja
D’Hondt’s ERCIM fellowship.

References
1. A. Arsanjani. Rule object 2001: A Pattern Language for Adaptive and Scalable
Business Rule Construction. 2001.
2. M. A. Cibrán, M. D’Hondt, and V. Jonckers. Aspect-Oriented Programming for
Connecting Business Rules. In Proceedings of BIS International Conference, Col-
orado Springs, USA, June 2003.
3. M. A. Cibrán, M. D’Hondt, and V. Jonckers. Mapping high-level business rules to
and through aspects. L’Objet, 12(2-3), Sept. 2006 (to appear).
4. M. A. Cibrán, M. D’Hondt, D. Suvée, W. Vanderperren, and V. Jonckers. JAsCo
for Linking Business Rules to Object-Oriented Software. In Proceedings of CSITeA
International Conference, Rio de Janeiro, Brazil, June 2003.
5. M. A. Cibrán, D. Suvée, M. D’Hondt, W. Vanderperren, and V. Jonckers. Inte-
grating Rules with Object-Oriented Software Applications using Aspect-Oriented
Programming. In Proceedings of ASSE’04, Argentine Conference on Computer
Science and Operational Research, Córdoba, Argentina, 2004.
184 M.A. Cibrán and M. D’Hondt

6. S. Clarke and R. J. Walker. Composition patterns: An approach to designing

reusable aspects. In International Conference on Software Engineering, pages 5–
14, 2001.
7. M. D’Hondt. Hybrid Aspects for Integrating Rule-Based Knowledge and Object-
Oriented Functionality. PhD thesis, Vrije Universiteit Brussel, Belgium, 2004.
8. M. D’Hondt and V. Jonckers. Hybrid Aspects for Weaving Object-Oriented Func-
tionality and Rule-Based Knowledge. In Proceedings of the 3th International Con-
ference on AOSD, Lancaster, UK, 2004.
9. J. Gray, Y. Lin, and J. Zhang. Automating change evolution in model-driven
engineering. Computer, 39(2):51, 2006.
10. HaleyRules. http://www.haley.com/products/HaleyRules.html.
11. B. V. Halle. Business Rules Applied: Building Better Systems Using the Business
Rules Approach. John Wiley & Sons, Inc., New York, NY, USA, 2001.
12. W.-M. Ho, J.-M. Jézéquel, F. Pennaneac’h, and N. Plouzeau. A toolkit for weaving
aspect oriented UML designs. In Proceedings of the 1st International Conference
on AOSD, pages 99–105, New York, NY, USA, 2002. ACM Press.
13. JRules. http://www.ilog.com/products/jrules/.
14. G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. V. Lopes, J.-M. Loingtier,
and J. Irwin. Aspect-oriented programming. In ECOOP, pages 220–242, 1997.
15. R. Pawlak, L. Seinturier, L. Duchien, G. Florin, L. Martelli, and F. Legond-Aubry.
A uml notation for aspect-oriented software design. First AOSD Workshop on
Aspect-Oriented Modelling with UML, April 2002.
16. QuickRules. http://www.yasutech.com/.
17. R. G. Ross. Principles of the Business Rule Approach. Addison-Wesley Publishing
Company, 2003.
18. D. Suvée, W. Vanderperren, and V. Jonckers. JAsCo: an Aspect-Oriented approach
tailored for Component Based Software Development. In Proceedings of the 2nd
International Conference on AOSD, Boston, USA, 2003.
19. Visual Rules. http://www.visual-rules.de.