=Paper=
{{Paper
|id=Vol-247/paper-11
|storemode=property
|title=Fact-Oriented Business Rule Modeling in the Event Perspective
|pdfUrl=https://ceur-ws.org/Vol-247/FORUM_10.pdf
|volume=Vol-247
|dblpUrl=https://dblp.org/rec/conf/caise/Bollen07
}}
==Fact-Oriented Business Rule Modeling in the Event Perspective==
https://ceur-ws.org/Vol-247/FORUM_10.pdf
37
Fact-Oriented Business Rule Modeling in the Event
Perspective
Peter Bollen
Department of Organization & Strategy, University of Maastricht
P.O. Box 616, 6200 MD, the Netherlands
p.bollen@os.unimaas.nl
Abstract. In this article we will focus on the business rule
modeling constructs and methodology in the fact-oriented
approach for the third perspective from the IFIP CRIS
framework: the behaviour-oriented perspective or event
perspective.
1 Introduction
In order to define the fact-oriented modeling constructs for the event perspective, we
will formalize the definition of derivation rules as they are currently used in fact-
oriented modeling languages (e.g ORM [1]). The derivation rules that constitute an
application’s process base can be fully formalized whenever an appropriate references
structure for the (static) information grammar has been put in place. We note how the
pre-condition references the object types that are specified in the process argument
and possibly references the (ingredient) fact types that must be contained in the
application information grammar. We note that the post-condition specifies what the
result will be of the execution of the derivation rule, whenever the pre-condition
evaluates to true. The create operator is defined as follows: a fact instance that will be
‘created’ has subsequently to be inserted to the application’s information base. If the
projected information base after the proposed insert transaction will violate the
application’s conceptual schema or information grammar, a created fact will not be
added to the application’s information base. The rule-body of the derivation rule
contains the explicit derivation logic that ’computes’ the value(s) for the ‘derived’
role for the fact instance(s) that will be created.
Dr1: Derive credibility status <(arg1, customer)>
IF There exists an instance of Ft2 SUCH THAT FT2.R2 = ‘arg1’
AND There exists at least one instance of Ft3 (where ‘ FT3.R1’ is SUCH THAT there
exist an instance of Ft2 SUCH that Ft2.R2 =’ arg1’ ) [pre-condition]
THEN Create an instance of fact type Ft1 SUCH THAT Ft1.R2= ‘arg1’
AND Ft1.R1= DRbody1 [post-condition]
DRbody1:= IF there exists at least one instance of Ft3 SUCH THAT Ft3.R2 = ‘bad’
THEN ‘ not credible’ ELSE ‘credible’ [rule body]
38
2 The extension of ORM with Event-Condition-Action (ECA)
modeling constructs
Although the execution of the derivation rule is constrained by the pre-conditions and
post-conditions, there still remain degrees of freedom with respect to when and in
what sequence these derivation rules or information base update processes (IBUPs)
can be executed. Therefore, an additional modeling construct is needed, to specify
when the instances of derivation rules from the conceptual schema will be executed.
These ‘rule’ executions will be triggered by events. For example the occurrence of an
event instance that an insurance application is created will ‘trigger’ the derivation
rule: derive customer credibility:
ON insurance application is created
THEN derive customer credibility
Definition 1. An event type is a set of events in the application subject area, each of
these events can lead to the execution of one or more derivation rules.
Definition 2. An event type argument set of a given event type specifies all
occurrences of object types, instances of which should be supplied for an event
instance of the event type.
An event can start the execution of a derivation rule or IBUP (in some cases) under
(a) condition(s) on the information base. In the population constraints from the
application information model we have modeled the ‘invariant’ business rules that
must hold for every information base state. For example the business rule that states
that every insurance application must state the insurance type. In the pre-condition of
the derivation rule(s), the business rules are modeled that specify what ingredient fact
instances should be available in order to ‘compose’ or ‘derive’ the resulting fact
instance(s) in the derivation rule [2: p.1519]. In the event perspective we will model
the business rules that contain the knowledge under what condition (on the
application information base) an event of an event type will trigger a specific
derivation rule or IBUP. An example event description for the insurance application
example will look as follows:
ON E1:insurance application is created (arg1:application)
THEN derive customer credibility (arg1:customer)
ON E2: new day(arg1: date, arg2: month)
IF C1: (E2.arg1= ‘1’ AND E2.arg2= ‘january’)
THEN derive customer credibility (arg1:customer)
Definition 3. A guard condition is a proposition on the information base.
The proposition in the guard condition can contain a reference to one or more
instances of the event argument.
39
3 The Impulse Mapper
In many cases the derivation rules are executed by users from different user groups in
the same organization. The external schema for the event perspective for such a user
group might contain compound impulses. This means that an event will trigger two or
more derivation rules at the same time. In order to abstract from externally imposed
"ways of working" we will have to atomize these compound impulse types. Each
atomic impulse containing exactly one (primitive) event [3], exactly one derivation
rule or IBUP and the condition under which the derivation rule or IBUP will be
executed. We will call the effect of an event occurence into the execution of one
derivation rule or IBUP (eventually under a condition on the information base) an
impulse (instance). It is this definition of an impulse that allows us to look at an
impulse as a specific type of ‘business constraint’ (see the discussion in Bollen [4:
p.112-113]) without having to worry about run-time implementation issues like code
generation [5], message sending [3: p.132] and software components (e.g. event
handler [6]).
Algorithm 1:Fact-oriented behavioral modeling procedure
BEGIN Take the first user group in application subject area
WHILE still user groups left in
Take the first derivation rule or IBUP from conceptual schema
WHILE still derivation rules/IBUP’s in conceptual schema.
Ask the users in the Sphere of Influence what event type(s)
invoke such a derivation rule or IBUP
Check whether such an event type is already listed.
IF event type not listed
THEN For each event type determine the event type argument
ELSE For each event type that evokes such a process:
determine the condition on the IB and event
argument under which the der. Rule is instantiated.
IF the condition is different from an existing
condition on the same event type and derivation
rule/IBUP
THEN Make a combined condition which contains the
old condition type and the new condition type
ELSE the impulse is already defined.
ENDIF
For each (relevant) impulse determine the impulse mapper
IF parts of such an impulse mapper can not be determined
THEN redefine the part of the event argument such that an
impulse mapper can be defined
ENDIF
For each impulse define the event-condition
and the condition-process trigger type (if relevant)
ENDIF
take next derivation rule/IBUP
ENDWHILE
take next user group in sphere of influence
ENDWHILE
END
Events that do not have the potential to ‘trigger’ derivation rules from the
application’s conceptual schema or IBUP’s are not relevant for the description of the
40
behavioural perspective in a given application subject area [7 : p.3]. We can now
classify all impulses that have the same event type, the same derivation rule or IBUP
and the same condition type into a set of impulse instances that belong to the same
impulse type.
An impulse type contains an event type, a condition type, and a derivation rule (or
a conceptual process type in general) or IBUP.
Definition 4. An impulse mapper is a construct that transforms values of event type
arguments and fact instances from the application information base into instantiation
values for the argument set(s) for the derivation rule or IBUP.
Example:
Event type Et1: insurance application created (arg1: application).
Derivation rule Dr1: determine customer credibility (arg1:customer).
Guard Condition type C1 : Ft4.R1 =’car’ (where FT4.R2=’E1.arg1’)
Impulse mapper Dr1.arg1:=Ft2.R2 (where Ft2.R1=’E1.arg1’
In algorithm 1 the modeling procedure for deriving the business rule model in the
behaviour-oriented perspective is given.
4 Conclusions
In this article we have generalized the declarability of business rules in the data-
oriented an process-oriented perspectives to the event perspective, by defining the
basic ECA oriented modeling constructs and the concept of impulse mapper that
provides the semantic connection between the model in the event perspective on one
hand and the models in the process- and data-oriented perspectives on the other hand.
In addition an explicit modeling procedure was provided.
References
1. Halpin, T., Information Modeling and Relational Databases; from conceptual analysis to
logical design. 2001, San Francisco, California: Morgan Kaufmann.
2. Bollen, P., Conceptual process configurations in enterprise knowledge management
systems, in Applied computing 2006. 2006, ACM: Dijon, France.
3. Bassiliades, N. and I. Vlahavas, Processing production rules in DEVICE, an active
knowledge base system. Data & Knowlege Engineering, 1997. 24: p. 117-155.
4. Bollen, P., On the applicability of requirements determination methods, in Management
and Organization. 2004, University of Groningen: Groningen. p. 219.
5. Dietrich, S.W., et al., Component adaptation for event-based application integration
using active rules. Journal of Systems and Software, (in press).
6. Pissinou, N., K. Makki, and R. Krishnamurthy, An ECA object service to support active
distributed objects. Information Sciences, 1997. 100: p. 63-104.
7. Paton, W., . ed. Active rules in database systems. Monographs in computer science, ed.
D. Gries. 1999, Springer: New-York.