FORMAL DEFINITION OF BUSINESS RULES USING
REA BUSINESS MODELING LANGUAGE
Frederik Gailly1 and Guido Geerts2
1
Faculty of Economics and Business Administration, Ghent University
[email protected]
2
University of Delaware
[email protected]
Abstract: In this short paper the REA Business modeling language is extended with an REA Business Rule modeling language. Developing a graphical
rule modeling language must make it easier for business people to specify rules
without ignoring the actual application of the rules in practice. This application
is supported by adding a set of transformation rules to the REA metamodel and
REA Business Rule metamodel which support the transformation of the REA
model and accompanying rules into a UML class diagram with accompanying
OCL constraints.
1
Introduction
A business rule is defined by Von Halle [1] as a statement that aims to influence or
guide behavior and information in an organization. Business rules have mostly been
determined ad hoc during the software modeling process and they have been hardwired into code without proper documentation at the conceptual level [2]. Recently
the explicit specification of Business Rules has gained more attention. For instance
the Object Management Group (OMG) has adopted the SBVR specification which
defines a language that can be used for creating business vocabularies and rules of all
kinds of business activities of all kind of businesses [3].
In this paper a domain-specific modeling language instead of a general-purpose
language like SBVR is used for specifying business models and business rules. The
last 10 years different business modeling languages have been proposed which define
enterprise domain specific constructs that can be used to develop business models and
possibly also business rules.
A well-known business modeling languages which indirectly support business
rules specification is the Resource Event Agent (REA) business modeling language
[4]. Although the REA language could be defined independently, it is most used as an
extension of general purpose modeling language like UML Class diagrams or Entity
Relationship (ER) modeling. Consequently the REA modeling language inherits the
features of these general-purpose languages, of which some can be used to specify
business rules. For instance if REA is defined as an extension of the ER metamodel,
adfa, p. 1, 2011.
© Springer-Verlag Berlin Heidelberg 2011
the multiplicities of ER modeling can be used to specify business rules or if REA is
defined as an extension of UML class diagram, the Object Constraint Language
(OCL) can be used to incorporate more complex business rules. The problem with
this approach is that successful integration of business rules into the REA-model requires knowledge about these general purpose modeling languages. Knowledge that is
in most cases not present.
In this paper we take a different approach and define the REA modeling language
independently. This language can be used to create business models but does not support the creation of business rules. Instead the specification of the business rules is
supported by another related modeling language, the REA Business Rules Language
(REA-BR). We believe that making a clear distinction between the business modeling
language and the business rule modeling language with both their own syntax, will
make it easier for business experts to create both type of models.
However this improved ease of use may not effect the actual implementation of the
rules. In the context of model-driven engineering this means that it must be possible
to transform the business models and business rules (i.e. Computation Independent
Models) into software design models (i.e. platform independent models) and later into
actual code (i.e. platform-specific models).
In the next section the meta-models of the REA and REA-BR language are represented and explained using an example. In section three Model-to-text and Model-toModel approaches are used to demonstrate how the business model and accompanying rules are transformed into a class diagram with OCL constraints. Section 5 concludes this research.
2
REA Business Modeling Language and REA Business Rule
Modeling Language
The meta-model that defines the REA Business Modeling language is represented in
figure 1. This meta-model specifies the REA Business Modeling language like it was
originally introduced by McCarthy [4] and extended by Geerts and McCarthy [5] in
2006. This recent extension introduced the grouping and typification abstraction
mechanism in REA which allows to add a policy layer to the REA operational level
which is absolutely necessary in order add different type of business rules to the REA
models.
The grouping and typification abstraction mechanism are not specific for REA but are
abstraction mechanisms that have been described by other authors. Typification present archetypal essence and are timeliness in nature. They are used for capturing concept descriptions that apply to a set of objects (e.g Plane is a kind of PlaneType).
Grouping is a considered as a special kind of aggregation and it groups objects into
collections based on one or more characteristics (e.g. Plane is member of Fleet). In
our metamodel the introduction of these policy relations results in the addition of
REAPolicyRelationship Element which connects a REAOperationalEntity to a RE-
APolicyEntity. The distinction between grouping and typification is made by adding a
the policyRelationshiptype attribute to the REAPolicyRelationship.
Figure 2 demonstrates the instantiation of this metamodel and represents an REA
business model for a consulting firm. The firm promises to deliver Consulting Services that are grouped in a Consulting Service Task that needs to be executed by a
specific set of employees that have some expertise. The actual execution of the service is also included by means of the Deliver Consulting Services Economic Event
which specifies by which employee the Consulting Service is delivered.
Figure 1: REA metamodel
Figure 2: REA Business Model Consulting Firm
The metamodel in figure 3 represents our main contributions and allows a business
user to graphically represent Business Rules. The figure also shows that the REA
Business Rule metamodel incorporates some of the concepts defined in the REA
Business metamodel. Following the paper of Geerts and McCarthy 2 different kind of
Business Rules are identified: Participation Policies, and Attribute Validation Policies. This set will be extended in future versions of the paper.
─ Participation Policy are used to put a constraint on the number of operational entities that can be member of (grouping) or can be a-kind-of (typification) a Policy
Entity. For instance the Participation Policy can be used to specify the following
BR: “The number of consulting services delivered by a ConsultingFirm is larger or
equal than the minimal number of consulting services required for that task.” Table
1 shows how this BR can be specified by instantiating the REA BR metamodel. In
the future we plan to extend the metamodel with a graphical notation which is
more intuitive to use.
─ The AttributeValidationPolicy validates an attribute value of a REA Operational
Entity against a value of attribute of a PolicyEntity. For instance the AttributeValidationPolicy can be use to specify that: “the salary of an employee must be equal
or greater than the minimum salary of the department she works for”
Figure 3: REA Business Rule metamodel
Table 1: Participation Policy for Min Number Of Consulting Services Required
Name
Operator
policyEntity
policyAttribute
policyRelationship
minNumberOfConsultingServicesRequired
greaterOrEqualsThan
Consulting Service Task
Min#OfConsultingServices
ConsultingServices_ConsultingServicesTask
Table 2: Attribute Validation Policy for Minimum Salary
Name
operator
policyEntity
policyAttribute
operationalAttribute
policyRelationship
minimumSalary
lessOrEqualsThan
EmployeeType
minSalary
minSalary
Employee_EmployeeType
3
Transformation REA models into UML class diagram
For the transformation of the business model and accompanying rules we use ATL
and MTL. Both ATL and MTL are supported by Eclipse plug-ins that use the Eclipse
EMF framework. The two projects that contain our mapping rules and also apply
these rules on the REA Consulting Firm business model and rules can be downloaded
from http://code.google.com/p/reamodeller/. The output of both the ATL and MTL
transformations is represented in figure 4.
ATL is a model-to-model transformation language that is used to create a UML class
diagram from the REA business model. This transformation is in most cases straightforward: 1) REA Entities and their attributes are transformed in UML classes with
accompanying attributes, 2) REA relationships with no attributes are transformed in
bidirectional associations and 3) REA relationships with attributes are transformed
into association classes with accompanying attributes.
Less straightforward is the inclusion of the multiplicities. Generally the ATL transformation rule for relations adds a participation of zero and a cardinality of many to
the roles of every association. However in some cases theses multiplicities are more
specific based on the definition of the REA concepts, relations and axioms. For instance following one of the REA axioms “every Economic Event must have at least
one participating Economic Agent and at least one Economic Resource” which can be
transformed into an ATL rule.
The policies that are represented using the REA BR metamodel are transformed into
OCL using MTL. MTL is a model-to-text transformation language and allows to
specify a template for every type of REA policy. These templates transform the policy
in a corresponding OCL constraint. The result of the transformation of the examples
in table 1 and table 2 are represented in the comments in figure 4.
Figure 4: UML class diagram Consulting Firm
4
Conclusion
The main contribution of this paper is the development of a REA business modeling language that is extended with an REA Business Rule meta-model which allows a
business expert to specify business rules. The paper also demonstrates how the developed REA Business Model and accompanying rules can be transformed into a UML
class diagram with OCL constraints. Currently the set of business rules that is supported by the REA Business Rule meta-model is limited and in future research we
plan to further extend this. Additionally we also need to provide an easy to use graphical notation for the business rules meta-model.
References
1. Von Halle, B.: Business rules applied : business better systems using the business rules
approach. Wiley Computer Publishing, New York (2002)
2. Steinke, G., Nickolette, C.: Business rules as the basis of an organization's information
systems. Industrial Management & Data Systems 103, (2003)
3. OMG: Semantics of Business Vocabulary and Business Rules (SBVR), v1.0. (2008)
4. McCarthy, W.E.: The REA Accounting Model: A Generalized Framework for Accounting
Systems in A Shared Data Environment. The Accounting Review 57, 554-578 (1982)
5. Geerts, G., McCarthy, W.E.: Policy-Level Specification in REA Enterprise Information
Systems. Journal of Information Systems 20, 37-63 (2006)