Paper presented at the IFIP Working Group 8.1 Conference CRIS 94, University of Limburg, Maastricht.
Published in: A.A. Verijn-Stuart, T.-W. Olle (Eds.), Methods and Associated Tools for the Information
System Life Cycle, Amsterdam et al.: Elsevier 1994, pp. 29-46.
THE SPECIFICATION OF BUSINESS RULES:
A COMPARISON OF SELECTED METHODOLOGIES
H. Herbst, G. Knolmayer, T. Myrach and M. Schlesinger
[herbst ¦ knolmayer ¦ myrach ¦ schlesi@iwi.unibe.ch]
Institute for Information Systems, University of Berne, Hallerstrasse 6, CH 3012 Berne, Switzerland*
Abstract
Business rules are an important element of information systems. The notion business rule
encompasses different phenomena; therefore, some classification criteria are presented and
several examples are introduced to demonstrate different types of business rules. Given their
practical importance, the necessity of a consistent treatment in the life-cycle of information
systems is obvious. Therefore, commonly used function- and data-oriented methodologies for
systems analysis are examined with respect to their ability to express business rules. It is
shown that common methods are insufficient or at least inconvenient for a complete and
systematic modeling of business rules. Some relevant enhancements of these methods are
more powerful but still emphasize only certain aspects and types of business rules.
Keyword Codes: D.2.1; H.2.m
Keywords: Requirements/Specifications; Database Management, Miscellaneous
1. BUSINESS RULES IN INFORMATION SYSTEMS
In recent years it has been accentuated that business rules [1] are an important element of
many information systems (IS); even the notion of a paradigm change has been used in emphasizing their importance [2][3]. Many business processes are executed with respect to rules
which either prescribe a certain action or constrain the set of possible actions. Business rules
may be based on ethics, culture, law or organizational commitments. We assume that they can
be structured according to the ECA-mechanism proposed in research on active databases [4],
i.e. as connections between events, conditions and resulting actions. Events are an instantaneous happening of interest to the enterprise and are attached to a time point, conditions
define what has to be checked and actions determine what has to be done.
Only a subset of the enormous number of business rules is enforced by IS; integrity constraints discussed in connection with database management systems (DBMS) form an even
smaller subset. From a business point of view, these integrity constraints will often appear as
trivial and may not even be explicitly formulated in requirements definitions. Nontrivial business rules may be context dependent in space (e.g. different law in different countries) and
time (e.g. law may change). Therefore, the rules have to be maintained during the life-cycles
of rule-based applications.
*
The work presented in this paper has been partly supported by the Swiss National Science Foundation,
Strategic Research Program 'Information Science', Project 5003-034330.
Business rules handled by the IS usually form a main part of application programs and are
thus scattered all over the system. This leads to incompleteness and redundancy of these rules
which may be specified in a different way in several applications and/or may be implemented
differently. Even if they are implemented consistently, this property may get lost by uncoordinated maintenance in redundant pieces of code (cf. [5]). Thus, there are strong arguments for a
non-redundant, (at least logically) centralized implementation of the IS-relevant business rules
in the database. This approach has the additional advantage that the rules cannot be circumvented by ad hoc operations on the DBMS.
Several commercial DBMS-products and research prototypes provide facilities like trigger
mechanisms and stored procedures for rule integration. Some types of integrity constraints are
already defined in SQL2 [6]; the SQL3 standard will presumably also provide constructs for
defining triggers. The appearance of 'more active' DBMS will offer a higher potential for enforcing rules by DBMS as currently available systems.
Independent of the power of existing and forthcoming commercial DBMS products, a
description of business rules at a conceptual level offers several advantages. A conceptual
model should be system- and implementation-independent, user-oriented and uniform with
respect to representation. Furthermore, on basis of such a model it may be possible e.g. to
simulate the behavior of logically dependent event-action-sequences or to automatically
generate rule-preserving implementations.
Several types of conceptual models are commonly used in software engineering. These
models do not provide a systematic treatment of business rules. Nevertheless, the available
constructs offer a certain potential to specify some semantics of business rules. The aim of this
paper is to analyze commonly used methods and some relevant enhancements with respect to
their expressiveness regarding business rules. Finally a comparison of the analyzed methods is
presented.
2. TYPES OF BUSINESS RULES
2.1. Classification of rules
In discussing the potential of different methodologies for modeling business rules it is helpful to introduce some distinctions. Events, processes and objects of the real world should be
distinguished from their IS-internal counterparts (IS-events, IS-processes and IS-entities). One
should also differentiate between consistency and activity rules. Consistency rules define
integrity constraints on valid database states, whereas activity rules prescribe actions or
operation sequences which have to be performed. Consistency rules may be further classified
in active and passive constraints: Passive integrity constraints prevent actions from taking
place in order to secure data integrity whereas active integrity constraints maintain
consistency by data manipulating operations [7].
Another common classification of integrity constraints distinguishes static and dynamic
constraints [8]; this can be expanded to
• static constraints which restrict the states of the database to an allowed subset without
referencing previous database states
• transitional constraints which make reference to two consecutive database states and
• dynamic constraints which take arbitrary database states into account [9].
2.2. Classification of rule components
In the ECA-description, the distinction between the three rule components provides modularity and thus better reusability [10]. But the separation is not always straightforward and may
depend on the view of the modeler, making the decision of how to specify certain components
of business rules sometimes ambiguous. An event like 'phone call of a customer between 8:00
a.m. and 5:00 p.m.' may also be formulated as the event 'phone call of a customer' and the
condition 'if time is between 8:00 a.m. and 5:00 p.m.'. Furthermore, rules may be unconditioned, i.e. only consisting of an event and an action component.
We differentiate two types of events which are further classified in Fig. 1. Elementary
events are primitives which cannot be further decomposed. Database events as a subtype of
elementary events are triggered by an operation (insert, update, retrieval or delete) on a database object. Time events are specified time-points invoking the enforcement of business rules.
User-defined events cover situations which are not due to database or time events and are explicitly raised by the application or the user.
Complex events are a combination of elementary or other complex events with additional
properties. We distinguish
• selection events (e.g. 'any 3 of [event1; event2; ...; eventn]')
• Boolean events (e.g. '[product x ordered] and [customer order for product x received]')
• periodical events (e.g. 'every 10th of a month') and
• delay events (e.g. '10 days after acceptance of a customer order').
Event
Elementary event
Database event
Time event
User-defined event
Complex event
Selection event
Boolean event
Periodical event
Delay event
Figure 1: Classification of events
Analogously to events we differentiate elementary and complex conditions. An elementary
condition is either a predicate or a query over the data in a database [11] as e.g.
• a comparison of an attribute value of an object and a constant (e.g. 'order state = 2')
• a comparison of attribute values of two objects (e.g. 'order total ≤ credit limit') or
• a set-operation on data (e.g. '∃ customer related to order').
Complex conditions consist of several (elementary or complex) conditions which are combined by Boolean operators.
Actions may be classified according to the location where they are performed:
• Action internal to an IS (e.g. the deletion of historical order information)
• Interaction between IS and the environment (e.g. the output of a message to a user about
overdue invoices)
• Action external to an IS (e.g. a phone-call of a sales representative to a customer).
The actions performed by the execution of a certain business rule may appear as events in
logically dependent rules.
2.3. Examples
To illustrate the discussion above we introduce a small subset of business rules which may
be relevant in an order processing system. Of course, the following examples do not cover the
variety of rules and their possible interdependencies. However, they provide an instructive
basis for evaluating specification methods.
We define every person or organization to whom or which we sell products as a customer;
the data of a customer is identified by a unique number and stored in a database. A constraint
securing that sales transactions can only be stored if there exist one and only one of the specified customers related to it is an example for an elementary business rule. Related is the rule
that every customer may have placed one or more orders; however, we allow the existence of
customers who temporarily do not have open orders. Thus, the object class ORDER is existence dependent on the object class CUSTOMER. A precondition for inserting an incoming
order is therefore the existence of the related customer in the database. The corresponding
business rule may be specified e.g. as
[BR1] ON insert-request of order
IF not ∃customer related to order
DO insert of order denied;
issue message "Customer does not exist"
To ensure the existence dependency between orders and customers, delete operations on
ORDER have also to be restricted e.g. as
[BR2A] ON delete-request of customer
IF ∃order related to customer
DO deletion of customer denied;
issue message "Deletion not possible because of existing orders"
Alternatively, one may think of other possible actions as e.g. the deletion of all related
orders:
[BR2B] ON delete-request of customer
IF ∃order related to customer
DO deletion of all orders related to customer;
deletion of customer
Besides ensuring existence dependencies, static rules may also reference certain attribute
values. One rule might be that no order is accepted unless the customer has currently a sufficient credit rating:
[BR3] ON insert-request of order
IF credit rating of customer related to order is insufficient
DO insert of order denied;
issue message "Order not accepted due to insufficient credit rating"
Such a rule makes sense only if a related customer exists; it depends therefore on [BR1].
Applying [BR1] before [BR3] is essential for the logic of the application; thus this sequence
has to be defined in the requirements. In other cases the sequentialization of rules may be left
to design or implementation or even to a rule manager of an active DBMS.
The following rule restricts the delete operation according to a time interval:
[BR4] ON delete-request of order
IF order entry date > (today - 5 years)
DO deletion of order denied
One may wish to delete all customers who have not placed an order within the last five
years. This business rule is an activity rule because it prescribes an action which has to take
place but does not concern database integrity. It is reasonable to assume that the deletion is
performed by a batch job which is triggered by a time event:
[BR5] ON every month
IF not ∃order related to customer with entry date > (today - 5 years)
DO delete-request of customer
This activity rule invokes either [BR2A] or [BR2B].
A business policy may determine that the customer has to be given a confirmation if his order is accepted. For this reason we map the real world event acceptance of order to the
corresponding IS-event and define the unconditional activity rule
[BR6] ON insert of order executed
DO write confirmation letter;
change order state to 'confirmed'
As a final example, we introduce a transitional integrity rule which demands that an order
may only be closed if the products ordered have already been delivered:
[BR7] ON change-request of order state to 'closed'
IF order state is not 'delivered'
DO change of order state denied
The following comparison will make reference to the rules defined above.
3. SPECIFYING BUSINESS RULES IN SELECTED METHODOLOGIES
There exist manifold specification languages for defining constraints and/or rules but these
are of minor practical importance because of their abstractness and formalism. The involvement of end users in the analysis of IS demands, however, a vivid and easy understandable approach. Methods which allow a graphical specification of rules seem particularly suitable. In
the following we concentrate on methods widely used in practice and on some of their enhancements which look promising in the context regarded.
3.1. Function-oriented methodologies
3.1.1. Specification with Data Flow Diagrams
Data flow diagrams (DFD) specify the data flow between processes or between one process
and either an external unit or a data store. They do not specify sequences of actions, i.e. the
arrival of a data flow does not necessarily lead to the execution of a process. The action component of the ECA-structure of business rules corresponds to processes in DFD. Data flows do
sometimes but not always coincide with events: there are data flows that do not directly result
from the occurrence of an event and there are time and control events that cannot be represented as data flows [12].
Common DFD do not allow to express conditions to synchronize data flows with respect to
the execution of a process. Regarding the examples above, only [BR6] can be modeled
because it is an active rule and does not contain a condition; even in this case, the implicit
temporal connection between the triggering event and the action is lost. To circumvent some
of these limitations, several extensions for modeling synchronization and time in DFD have
been proposed [13].
Elementary processes of DFD are usually further described through mini-specifications
which may include business rules. One appropriate way is their specification in decision tables
or trees; these define conditions and actions but do not formally support an event component.
However, such a treatment of business rules has the disadvantages sketched in chapter 1.
3.1.2. Specification in the Merise framework
Besides the common data modeling approach, Merise introduces a conceptual processing
model (CPM) which supports triggering events, (synchronized) operations and resulting
events [14]. The synchronization corresponds to the condition component in the ECA-mechanism. An operation consists of one or more tasks that are based on management rules and are
executed sequentially. Every operation may lead to different events according to issuing rules
which may e.g. be 'operation has been successful' or 'operation has failed'; the abbreviation
NR signifies that no response follows. In CPM an event is seen as the carrier of properties;
these correspond with attributes in the Merise data model. Merise/2 introduces object lifecycles in which the events changing the states of a certain object are modeled [15].
Because CPM provides all necessary components to model ECA-rules, on principle all
business rules mentioned above can be specified. However, CPM concentrates on the
modeling of dynamics and the interdependencies between single rules; it does not intend to
model static rules or the effect of rules on objects. As an example, Fig. 2 describes the
semantics of [BR1], [BR3] and [BR6] and the sequence in which they may be executed.
person puts
order
BR1
check whether
person is
customer
ok
not ok
person is a
customer
BR3
check credit
rating
ok not ok
order is
accepted
order is not
accepted
BR6
Generate
confirmation
NR
Figure 2: Specifying business rules in the Conceptual Processing Model
3.1.3. Specification with State-Transition Models, Transition Graphs and Statecharts
A common technique to describe systems behavior are state transition diagrams (STD). In
these graphs nodes symbolize states (represented as circles containing optional names) and directed arcs visualize transitions [16]. A system represented by a STD can only be in one of a
given number of states at any specific time point. If several arcs leave a node, only one of
these transitions can be executed, depending on their labels. Therefore, modeling of selections
is possible.
STD do not explicitly provide symbols for the components of business rules. However,
transitions are typically labeled with the corresponding conditions and actions. Recently, a distinction between events, conditions and actions in the description of transitions is made [17].
Because the data schema cannot be represented, it is necessary to complement this technique
with a suitable data model.
In [18] a special form of STD called transition graph is used to define transitional and dynamic integrity constraints. A transition graph is constructed from temporal formulas and used
to describe the life-cycle of a specific object with respect to constraints; nodes represent
particular states of the object and arcs express conditions for a transition from one valid object
state to another.
Not order(#)
BR1
order (#) and (∃ Customer related to order)
order (#) and (credit rating is not sufficient)
order(#) and (credit rating is not checked) and (status ≠
BR3
order processable
order (#) and (credit rating is sufficient) and (status = 'accepted')
set t:= TODAY
order(#) and (confirmation letter is not sent) and (status ≠
BR6
order accepted
order(#) and (confirmation letter is sent) and (status = 'confirmed')
order(#) and (status ≠ 'delivered')
......
order confirmed
order(#) and (status = 'delivered')
order(#) and (status ≠ 'closed')
BR7
order delivered
order(#) and (status = 'closed')
order(#) and (t > TODAY - 5 years)
BR4
order closed
not order(#) and (t ≤ TODAY - 5 years)
Figure 3: Specifying business rules in a Transition Graph
Because transition graphs focus on states and feasible state changes, events and actions are
not explicitly defined in the diagrams. It is assumed that formally each time unit a transition
has to take place. The change of time does not necessarily imply a change of state; this is
modeled by conditioned self-loops which may e.g. also express delays. The representable
aspects of some business rules concerning a certain order are modeled as a transition graph in
Fig. 3.
Although graphical symbols for modeling ECA-rules are not available, on principle all
rules regarded may be modeled as STD. These diagrams are suited to symbolize the
interdependencies of rules. Because there is no construct for objects, the effects of rules on
objects have to be expressed verbally which may lead to a rather intransparent representation.
This difficulty is somewhat circumvented in transition graphs due to the restriction to
represent the state changes of only one object. However, in this case, rules which have effects
on the states of several objects cannot be adequately specified in one graph. Regarding our
examples, the possible invocation of [BR4] by [BR2B] is not representable.
A related method are statecharts which are used to describe the behavior and reaction of a
system in terms of system states and corresponding state changing events to be sensed by the
system; Boolean operators are introduced as refinements to specify ECA-rules [19].
3.1.4. Specification with Petri Nets
Petri Nets (PN) employ two types of nodes representing places and transitions which are
connected by directed arcs. These graphs may be used to describe and to simulate the behavior
of systems by tokens which move from place to place due to firing transitions. A transition
fires if its preconditions are satisfied, i.e. the preceding places contain the specified number of
tokens.
To model business rules, places may be used to represent events and/or conditions and
transitions may signify actions. PN also allow the description of elementary or complex events
[20]. To model alternative results depending on the condition clause, the PN may be extended
with labeled arcs as mentioned in [21]. In Fig. 4 we represent the semantics of [BR1], [BR3]
and [BR6] as an accordingly extended PN. With this extension it is possible to model the
structure of all the rules introduced above; however, different semantics are connected to the
place symbol, making the interpretation of this net more difficult.
The transformation of rules expressed in propositional logic into a particular kind of PN for
checking consistency is discussed in [22]. A disadvantage of the common PN is that it cannot
represent exact temporal behavior, e.g. possible delays between the occurrence of an event,
the checking of a condition and the resulting action; such delays may be expressed in a Timed
PN [23]. In the MODYN data modeling formalism, PN are augmented with token values to
specify constraints concerning object state sequences generated by events and object type
dynamics in databases [24].
A disadvantage of PN is that its constructs may represent different semantics (e.g. places
may symbolize object states, events or conditions); applying different extensions, quite
diverse representations of the business rules could be obtained. Furthermore, PN lack the
means for representing data objects; several authors have therefore combined PN with EntityRelationship-Models (cf. chapter 3.2.2.2.).
E1: insert-request of order
C1: (∃ customer related to order)
A1a: insert of order
denied; message:
"customer does not
exist"
no
yes
A1b: raise event 'person is a customer'
no
A3a: insert of order
denied; message: "credit
rating insufficient"
BR1
BR3
E3: 'person is a customer'
C3: (credit rating of customer is sufficient)
yes
A3b: insert order
BR6
E6: order inserted
A6: write confirmation
Figure 4: Specifying business rules in an extended Petri Net
3.2. Data-oriented methodologies
3.2.1. Specification with the Entity-Relationship-Model and NIAM
Many business rules exemplified in the literature are static and expressed in different
variants of Entity-Relationship-Models (ERM). However, business rules have to be modeled
implicitly by using ERM-semantics like cardinalities and existence dependencies. [BR1],
[BR2A] and [BR2B] can be partially expressed as shown in Fig. 5: The entity type ORDER is
existence dependent on CUSTOMER; the condition to manipulate an order is therefore the
existence of the related customer.
CUSTOMER
puts
ORDER
Figure 5: ER diagram for the order entry system
An ERM does not allow an explicit formulation of events, conditions, or actions. Because
every rule expressed within the ERM has the character of an integrity constraint it is implicitly
assumed that every infringement leads to a rejection of the requested operation as in [BR1].
Whereas any insert operation which violates the integrity of the database leads naturally to a
rejection, the response to a deletion is ambiguous because e.g. either [BR2A] or [BR2B] may
be applied; this can be neither expressed in nor implied from the ERM without additional
natural language descriptions like those used in [25]. Some data modifications may be
constrained by domain definitions; however, static rules like [BR3] which concern attribute
values are not representable. Furthermore, transitional rules like [BR4] and [BR7] as well as
activity rules like [BR5] and [BR6] cannot be modeled in the ERM.
A well-known relative of ERM is NIAM [26]; one major difference between them is the
way in which attributes are modeled. To express integrity constraints, NIAM provides the
constructs uniqueness and mandatoriness which can be compared to the cardinality constraints
of the ERM. Furthermore, NIAM supports additional constraints between object types, such as
uniqueness between different roles, equality and exclusion. These additional constraints make
NIAM slightly more powerful with respect to modeling business rules; regarding the rules
defined above, the descriptive power of ERM and NIAM is equal.
As well the ERM as NIAM may be complemented by specification languages
(cf. [27][28][29]); as mentioned above, these are deliberately omitted from our analysis.
3.2.2. Specification with Extended Entity-Relationship-Models
There are manifold extensions to the common ERM. For the purpose of describing
business rules especially those approaches are relevant which incorporate events or behavior
into the model.
3.2.2.1. Entity Relationship-Rules Model
An interesting enhancement of ERM with respect to the concepts of events and rules is the
Entity-Relationship-Rules Model (ER-RM) [30]. In this proposal a new construct is
introduced which represents situation-action rules to control the states of entities, relationships
and their attributes. A situation is defined as a binary tuple of an event and an associated
condition; the rule is said to be true or to happen when the event occurs and the condition is
satisfied.
Rules are expressed in ER-R diagrams as parallelograms. These are labeled with distinctive
names whereas the content of rules is not represented in the diagram. The parallelogram may
be connected through directed arcs with the three relevant constructs of the ERM; furthermore, there exist arcs from rules to the system environment. Arcs going into parallelograms
symbolize input or triggering events; outgoing arcs represent output or resulting events. The
arcs are labeled e.g. with the database operations input (i), update (u), or delete (d). The model
distincts between attemption and successful execution of these operations; the former may be
notified as ia, ua, and da. Dotted arcs are used to express additional data needs of rules.
every
month
confirmation
letter
time
BR5
last
order
da
BR2B
BR6
da
da
i
ua
status
ua
CUSTOMER
credit
rating
puts
ia
BR3
BR1
BR7
ORDER
ia
da
entry
date
BR4
Figure 6: Specifying business rules in the ER-RM
When using this notation, all rules triggered by database operations can be expressed as in
Fig. 6. However, with this rule construct it is possible to show the relationship between rules
and their according objects, whereas the sequence of rule invocation is rather intransparent.
In Fig. 6, the semantics of [BR1] is already expressed by the cardinality of the ER-subset,
thus resulting in redundancy. The dependency of [BR3] on [BR1] is not shown in this
diagram; if one would like to specify a sequence (as e.g. in Fig. 2 and Fig. 4), a directed arc
from [BR1] to [BR3] could be added. Each attempted operation may be accepted or rejected.
In the first case the operation takes place; in the latter case the attempted operation is
cancelled and an error-message is sent to the user instead. Both operations result in events
which are trivial and have therefore been omitted from the diagram.
3.2.2.2. Behavior Integrated Entity Relationship Model
Another relevant approach is the Behavior Integrated ERM (BIER) [31][32] which combines the ERM with PN. In this model the structures of real world objects are modeled by
means of the ERM; in further developments the ER part of this approach has been abandoned
in favor of an object-oriented representation [33]. The behavioral part of BIER allows
modeling real world events and their temporal interdependencies using a modified PN. It is
related with the ER part through directed arcs which connect state types with the corresponding entity types. An example for the entity type ORDER is given in Fig. 7. This diagram concentrates on the dynamic behavior. Best representable are the transitional [BR6] and [BR7]
because they result in a state change; [BR3] and [BR4] may only be implied from the
representation. The possibilities of specifying the static rules [BR1] and [BR2A] or [BR2B] in
the ER part of BIER are identical to those discussed in chapter 3.2.1.
OGPRQS8JMTUNK
$-54"6
879$: #&';&<>=
!.?4*@
87;$A)';<(=
0/B4
%&&'
7A'<=
!1?4C"$)<$ >$
7*$D+*'$*&<(=
32E4'F<G
8&H%*I
7$R'(;<>=
!.
0/
#"
7W K /=
W K\
-)XW K .,Y[Z W
JKMLNDK
$-
W K
"$V
!
^;^_^;^_^;^
!1
32
$!%&'()
%*+
W K]
,'(
7W K 1$=
Figure 7: Specifying rules in a BIER model
Even though BIER allows to model systems structure and systems behavior, it lacks constructs to directly express events and conditions. The unsatisfying representation of the effects
of rules on objects in PN is circumvented in BIER because the states are related to entity
types. Therefore, the behavioral part of BIER is particularly suited to describe transitional
rules.
3.2.2.3. Entity Life History Model
A further approach which concentrates on the expression of state changes of entities is the
concept of entity life histories (ELH); these are e.g. a component of the entity-event modeling
proposed in SSADM. This technique is used to integrate the results of data and data flow
modeling [34]. The basic idea of ELH is simply to describe all events related to state changes
in the life-cycle of an entity, i.e. from its creation over possible changes to its deletion. It is a
tree structure with an entity type at its root and events which affect this entity type at its
leaves. The events are ordered to symbolize sequences which have to be read from left to
right. There may be intermediary nodes between the root and the leaves thus expressing
selection and iteration. The tasks necessary to deal with are gathered in a separate operations
list and are linked to the diagram via operation boxes at the bottom of the hierarchy.
In the example regarded, one may draw ELH for the entity types CUSTOMER and
ORDER. The life history of ORDER is depicted in Fig. 8. An order comes into existence if an
order request from a customer is accepted. Further states of orders are 'confirmed', 'delivered'
and 'closed'. Rules expressing state changes for ORDER are [BR6] and [BR7]. However,
these rules are triggered by internal events like 'insert order' whereas the events in the diagram
are primarily external like 'order is confirmed'; instead of the internal events the diagram
depicts the accompanying operations. Internal events leading to external actions like in [BR6]
can only be specified if the event changes the object state. Other relevant rules as [BR1] and
[BR3] for the acceptance of orders and [BR5] for its deletion cannot be adequately expressed.
1: insert order
2: tie to customer
3: update order state
4: delete order
Order is
accepted
1
ORDER
Order is
confirmed
Order is
delivered
Order is
closed
Order is
removed
2
3
3
3
4
BR1
BR6
......
BR7
BR4
Figure 8: Specifying business rules in the ELH
ELH concentrates on objects and events; conditions cannot be defined, i.e. every event implies an unconditional execution of the attached operation(s). The strength of the ELH is the
description of transitional rules; on principle, it can express a sequence of state transitions of
an object which moves in only one direction from insertion to deletion. ELH enhanced by constructs for specifying divergent sequences [34] becomes less understandable. A further disadvantage of the ELH is its limitation to model only the effects of rules on one entity type. However, an ELH has to be regarded together with a corresponding ER diagram. Furthermore, one
may complement ELH with appropriate techniques for modeling all entity types affected by a
given event; SSADM employs effect correspondence diagrams for this purpose [34].
Because ELH is based on a tree structure whereas BIER uses a net approach, BIER is more
flexible to express complex state sequences, e.g. loops.
3.3. Object-oriented methodologies
Object-oriented methodologies (OOM) aim to circumvent the weakness of separate data
and function modeling. The core of OOM are object models; objects are grouped to classes
and include attributes and also services to manipulate them. Objects communicate via
messages which are sent from one object and invoke the execution of a particular service of
the referenced object.
The semantics and graphical notations of object models resemble quite often an extended
ERM, thus providing similar power and limitations to express static business rules. Furthermore, business rules may be formulated in terms of messages and services. Messages may be
interpreted as events which trigger services; in this case conditions and actions have to be defined in the specification of services.
Several methods of object-oriented analysis and design have been proposed (for a comprehensive comparison c.f. [35]). Most of them as e.g. the Object Modeling Technique (OMT)
provide in addition to object models also behavioral or dynamic models [17] which are
usually expressed by STD. The OMT employs a simple event flow diagram for modeling the
entire system and STD for every class with relevant behavior. A particularity of OMT is that it
also supports a function model which is based on the common DFD technique.
With respect to business rules the Object-Oriented Analysis & Design (OOA&D) approach
[36] is of special interest. This method distinguishes object structure and object behavior
analysis. Object structures are modeled by an ERM; the behavior of objects is described by
STD, event-schemas, object-flow diagrams, and process-dependency diagrams. For represent-
ing business rules the event schemas which encompass the elements operation, event type,
trigger rule, and control condition are particularly suitable.
An operation is defined as a process that can be requested as a unit and is represented as a
box with rounded edges. The successful completion of an operation invokes one or more
events. Every event is an instance of an event type; these types are represented by triangles
which are usually attached to operation boxes. Internal, external, and temporal events are distinguished graphically; e.g. a temporal event is expressed by a clock symbol. The notion
'trigger rule' is very similar to 'business rule' and signifies the invocation of a particular operation due to the occurrance of a specific type of event. Thus, a trigger rule in an event schema
consists of three basic components: an event type (the cause), an operation (the effect), and a
mapping between them; the cause-and-effect link is represented by directed arcs. The notation
also allows for the expression of concurrent and sequential invocations. A control condition is
a mechanism which must be met so that the related operation may be executed; they are
represented by a diamond shape attached to the operation box. Control conditions are trigger
dependent; thus, there may be several control conditions for the execution of a specific
operation.
Using event schemas it is on principle possible to express all business rules regarded. Fig. 9
depicts the semantics of [BR1], [BR3] and [BR6] and the sequence in which the rules may be
executed; this model resembles the CPM in Fig. 2.
BR1
person puts
order
BR3
check whether
person is a
customer
BR6
check credit
rating
person is a customer
person is not a customer
insert of order
confirmation
letter
status:='conf.'
credit rating is sufficient
credit rating is insufficient
message
"Person is no
customer"
message
"Credit rating
insufficient"
Figure 9: Specifying business rules in an Event Schema
4. COMPARISON OF THE SELECTED METHODOLOGIES
The comparison of the presented methodologies and models is based on following two
criteria:
• What constructs do the methodologies provide for modeling business rules ?
• Which types of business rules can be modeled ?
In regarding Fig. 10 one should consider that both criteria are relevant. In modeling the
examples above we sometimes employed constructs of the methodologies discussed in a
rather unusual, unintended way; the entries in Fig. 10 hint at this particular use. Employing
methods in an unintended way have the tendency to result in unclear and cluttered diagrams.
Furthermore, one has to remind that on principle all types of rules could be verbally described.
The characterization of the methods with respect to their ability to represent certain types of
business rules therefore depends on whether additional verbal descriptions are regarded as an
integral part of the methods.
Modeling Constructs
Method
DFD
of SA
CPM of
Merise
STD
Objects
Rules
data store,
external
object
---
---
---
---
---
Types of Business Rules
Events
Conditions
Actions
Consistency Activity
rules
rules
partially by
--processes
only in very limited
data flows
(details in minispecs
minispecs)
external/in- synchroniza- operation
yes
yes
ternal events
tion
(unintended)
(labels of
labels of
labels of
yes
yes
transitions) transitions transitions (unintended)
--labels of
--transitional,
no
transitions
dynamic
Transi--tion
(restricted to
Graph
one object)
Ext. PN
---
---
---
places
places
transitions
ERM,
NIAM
---
---
cardinalities,
keys,
domains
---
ER-RM
BIER
entity type,
relationship
type,
(attributes)
entity type,
relationship
type,
(attributes)
entity type,
relationship
type,
(attributes)
rule type
---
ELH of entity type
--SSADM (restricted to
one entity
type)
Event
--trigger rule
schema (references
of
to object
OOA&D
model)
yes
(unintended)
static
(limited)
yes
yes
very limited
directed arcs covered by directed arcs
rule type
places
---
event
(external)
---
event type
control
condition
no
transitions transitional,
yes
static
(cf. ERM),
dynamic
(unintended)
operation transitional very limited
(limited)
operation
yes
(unintended)
yes
Figure 10: Comparison of the discussed methodologies
5. CONCLUSIONS AND OUTLOOK
In this paper the importance of business rules as an element of IS has been emphasized.
Different types of business rules have been discussed and some examples have been
introduced. Consequently, we have analyzed several methods of software engineering with
respect to their power to model these rules. The most obvious way to support business rules is
the inclusion of an explicit rule construct. However, business rules can also be expressed
through their components, i.e. events, conditions and actions. A suitable method should
support at least either one of these options. Furthermore, it should be possible to specify the
effects of rules on objects as well as the dependencies between business rules.
Many well-known methods for modeling IS generally lack most of the needed constructs to
formulate business rules adequately. Methods like DFD and ERM, which are the core of
structural system analysis, are particularly restricted in this respect. Methods for specifying the
dynamics of IS like STD and (extended) Petri nets are better suited, even though they likewise
do not support the appropriate constructs. They may primarily be used to express the sequence
in which business rules are executed and are less suited to show the effects of business rules
on objects. One may try to avoid this problem by restricting nets to model only the state
changes of one single object. This approach resembles somewhat the idea of ELH. Its
disadvantage is that business rules will often affect several objects of different types which
cannot be displayed in one single diagram.
We have also discussed some enhanced methods which seem better suited for the formulation of business rules. The ER-RM is the only method regarded which provides an explicit
construct for modeling business rules. However, only structural aspects of the rules may be
represented and dynamic interdependencies are neglected. The idea of modeling business
rules through their components is best reflected in event schemas of the OOA&D method
which is a close relative of CPM in Merise. The most powerful combination for modeling
system structure and dynamics is realized in the BIER approach. The underlying business
rules are only indirectly representable. Thus, none of the analyzed methods is capable to
support all relevant aspects of embedding rules into IS.
Generally, the graphical presentations of business rules for IS of realistic size may become
very complex and cumbersome; this will be detrimental to their development and understandability. For this reason, specification languages have to be regarded as a possibly useful alternative or supplement to graphical presentations. They might provide a rigorous definition for
aspects which are not or extremly inconvenient to express in graphical notations. Specification
languages may be especially suitable for a formalization of single rules. However, the relevant
interdependencies between single rules or rules and objects are preferably expressed in a
graphical notation. Well-suited specification languages should be more powerful than the
usual ECA-mechanism in which only one case of a selection can be defined; this deficit may
result in logically redundant descriptions of events and conditions. Therefore, a selection
construct should be supported by an appropriate language.
In a current research project we analyze systematically several IS in practical use with respect to the embedded business rules. By this approach we hope to attain information about
the practical relevance of different rule types. Our aim is to develop a meta model to represent
business rules as a precondition to their systematical representation in a rule-base; this should
serve as a common basis for deriving views which emphasize different aspects of rule systems
in a consistent way. Some of the methods discussed in this paper may be employed for the
graphical representation of these views. A view concept seems to be necessary because of the
deficiencies found in applying singular methods. Furthermore, we are investigating how
trigger descriptions usable in commercially available DBMS can be generated from such a
conceptual rule base.
REFERENCES
[1] Knolmayer, G., Herbst, H., Business Rules, in: Wirtschaftsinformatik 35 (1993) 4,
pp. 386 - 390.
[2] Van Assche, F., Layzell, P., Loucopoulos, P., Speltincx, G., Information systems
development: a rule-base approach, in: Journal of Knowledge Based Systems 1 (1988) 4,
pp. 227 - 234.
[3] Moriarty, T., The Next Paradigm, in: Database Programming & Design 6 (1993) 2,
pp. 66 - 69.
[4] Dayal, U., Buchmann, A.P., McCarthy, D.R., Rules Are Objects Too: A Knowledge Model for an Active, Object-Oriented Database Management System, in: K.R. Dittrich (ed.),
Advances in Object-Oriented Database Systems, Springer, Berlin 1988, pp. 129 - 143.
[5] Nazareth, D.L., Investigating the Applicability of Petri Nets for Rule-Based System
Verification, in: IEEE Transactions on Knowledge and Data Engineering 5 (1993) 3,
pp. 402 - 415.
[6] Melton, J., Simon, A.R., Understanding the New SQL: A Complete Guide, Morgan
Kaufmann, San Mateo 1993.
[7] Urban, S.D., Karadimce, A.P., Nannapaneni, R.B., The Implementation and Evaluation
of Integrity Maintenance Rules in an Object-Oriented Database, in: IEEE Computer
Society (ed.), Proceedings Eighth International Conference on Data Engineering, IEEE
Computer Society Press, Los Alamitos 1992, pp. 565 - 572.
[8] Falquet, G., Guyot, J., Junet, M., Léonard, M., Bursens, R., Crausaz, P., Prince, I.,
Concept Integration as an Approach to Information Systems Design, in: T.W. Olle, A.A.
Verrijn-Stuart and L. Bhabuta (eds.), Computerized Assistance During the Information
Systems Life Cycle, North-Holland, Amsterdam 1988, pp. 19 - 65.
[9] Lipeck, U.W., Dynamische Integrität von Datenbanken, Grundlagen der Spezifikation
und Überwachung, Springer, Berlin 1989.
[10] Gatziu, S., Dittrich, K.R., Eine Ereignissprache für das aktive, objektorientierte Datenbanksystem SAMOS, Working Paper, Institute of Computer Science, University of
Zurich 1993.
[11] Hanson, E.N., Widom, J., An Overview of Production Rules in Database Systems,
Working Paper CIS-TR-92-031, University of Florida, 1992.
[12] Yourdon, E., Modern Structured Analysis, Prentice-Hall, Englewood Cliffs 1989.
[13] Eddins, W.R., Crosslin, R.L., Sutherland, D.E., Using Modelling and Simulation in the
Analysis and Design of Information Systems, in: H.G. Sol and K.M. van Hee (eds.),
Dynamic Modelling of Information Systems, Elsevier, Amsterdam 1991, pp. 89 - 119.
[14] Quang, P.T., Chartier-Kastler, C., MERISE in Practice, Macmillan, Houndmills 1991.
[15] Tardieu, H., Issues for Dynamic Modelling through Recent Development in European
Methods, in: H.G. Sol and R.L. Crosslin (eds.), Dynamic Modelling of Information
Systems, II, North-Holland, Amsterdam 1992, pp. 3 - 23.
[16] Davis, A.M., A Comparison of Techniques for the Specification of External System
Behavior, in: Communications of the ACM 31 (1988) 9, pp. 1098 - 1115.
[17] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W., Object Oriented
Modeling and Design, Prentice-Hall, Englewood Cliffs 1991.
[18] Lipeck, U.W., Integritätszentrierter Datenbank-Entwurf, in: EMISA FORUM (1992) 2,
pp. 41 - 55.
[19] Mück, T.A., Design Support for Initiatives and Policies in Conceptual Models of Information Systems - A Statechart Approach, in: J.F. Nunamaker and R.H. Sprague (eds.),
Proceedings of the 27th Annual Hawaii International Conference on System Sciences,
Vol. IV, IEEE Computer Society Press, Los Alamitos 1994, pp. 743 - 752.
[20] Gatziu, S., Dittrich, K.R., Events in an Active Object-Oriented Database System, in:
N.W. Paton and M.H. Williams (eds.), Rules in Database Systems, Springer, Berlin
1993, pp. 23 - 39.
[21] Bischoff, R., Petri-Netze - Ihr Beitrag zum Entwurf von Systemen, in: Handbuch der
modernen Datenverarbeitung 19 (1982) 104, pp. 45 - 60.
[22] Meseguer, P., A New Method to Checking Rule Bases for Inconsistency: A Petri Net
Approach, in: L.C. Aiello, E. Sandewall, G. Hagert and B. Gustavsson (eds.), Proceedings of the 9th European Conference on Artificial Intelligence, 1990, pp. 437 - 442.
[23] Godbersen, H.P., Funktionsnetze, in: H.C. Mayr and B.E. Meyer (eds.), Formale
Modelle für Informationssysteme, Springer, Berlin 1979, pp. 246 - 265.
[24] Mück, T.A., Vinek, G., Modelling Dynamic Constraints Using Augmented Place
Transition Nets, in: Information Systems 14 (1989) 4, pp. 327 - 340.
[25] Jarke, M., Pohl, K., Information Systems Quality and Quality Information Systems, in:
K.E. Kendall, K. Lyytinen and J.I. DeGross (eds.), The Impact of Computer Supported
Technologies on Information Systems Development, North-Holland, Amsterdam 1992,
pp. 345 - 375.
[26] Nijssen, G.M., Halpin, T.A., Conceptual Schema and Relational Database Design - A
Fact Oriented Approach, Prentice-Hall, Englewood Cliffs 1989.
[27] Loucopoulos, P., McBrien, P., Persson, U., Schumacker, F., Vasey, P., TEMPORA Integrating Database Technology, Rule Based Systems and Temporal Reasoning for
Effective Software, in: Proc. ESPRIT'90 Conf., Brussels 1990, pp. 388 - 411.
[28] Theodoulidis, C., Loucopoulos, P., Wangler, B., A Conceptual Modelling Formalism For
Temporal Database Applications, in: Information Systems 16 (1991) 4, pp. 401 - 416.
[29] De Troyer, O., Meersman, R., Verlinden, P., RIDL* on the CRIS Case: A Workbench
for NIAM, in: T.W. Olle, A.A. Verrijn-Stuart and L. Bhabuta (eds.), Computerized
Assistance During the Information Systems Life Cycle, North-Holland, Amsterdam
1988, pp. 375 - 459.
[30] Tanaka, A.K., Navathe, S.B., Chakravarthy, S., Karlapalem, K., ER-R: An Enhanced ER
Model with Situation-Action Rules to Capture Application Semantics, in: T.J. Teorey
(ed.), Proceedings of the 10th International Conference on the Entity Relationship
Approach, E/R Institute, San Mateo 1991, pp. 59 - 75.
[31] Eder, J., Kappel, G., Tjoa, A.M., Wagner, R.R., BIER - The Behavior Integrated EntityRelationship Approach, in: S. Spaccapietra (ed.), Proceedings of the 5th Intenational
Conference on Entity-Relationship Approach, North-Holland, Amsterdam 1987,
pp. 147 - 166.
[32] Kappel, G., Schrefl, M., A Behavior Integrated Entity-Relationship Approach for the
Design of Object-Oriented Databases, in: C. Batini (ed.), Entity-Relationship Approach:
A Bridge to the User, Proceedings of the 7th International Conference on EntityRelationship Approach, North-Holland, Amsterdam 1989, pp. 101 - 122.
[33] Kappel, G., Schrefl, M., Object/Behavior Diagrams, in: Proceedings Seventh
International Conference on Data Engineering, IEEE Computer Society Press, Los
Alamitos 1991, pp. 530 - 539.
[34] Downs, E., Clare, P., Coe, I., Structured Systems Analysis and Design Method Application and Context, 2nd ed., Prentice-Hall, Englewood Cliffs 1992.
[35] Stein, W., Objektorientierte Analysemethoden: Vergleich, Bewertung, Auswahl, BI
Wissenschaftsverlag, Mannheim 1994.
[36] Martin, J., Odell, J., Object-Oriented Analysis & Design, Prentice-Hall, Englewood
Cliffs 1992.