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. 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 factoriented 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: IF AND THEN
Derive credibility status <(arg1, customer)> There exists an instance of Ft2 SUCH THAT FT2.R2 = ‘arg1’ 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] 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]
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 THEN insurance application is created 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.
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 the impulse is already defined.
ELSE 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 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.
Event type Derivation rule Guard Condition type Impulse mapper
In algorithm 1 the modeling procedure for deriving the business rule model in the behaviour-oriented perspective is given. 4
In this article we have generalized the declarability of business rules in the dataoriented 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.