The Decision-Scope Approach to Specialization of …crpit.com/confpapers/CRPITV143Schrefl.pdfThe Decision-Scope Approach to Specialization of Business Rules: Application in Business

The Decision-Scope Approach to Specialization of Business Rules:Application in Business Process Modeling and Data Warehousing

Michael Schrefl1 Bernd Neumayr1 Markus Stumptner2

1Department of Business InformaticsData & Knowledge Engineering

Johannes Kepler Univ. of Linz - AustriaEmail: [email protected]

2Advanced Computing Research CentreKnowledge & Software Eng. LabUniversity of South AustraliaEmail: [email protected]

Abstract

It is common in organizational contexts and in law toapply a decision-scope approach to decision making.Higher organization levels set a decision scope withinwhich lower organization levels may operate. In caseof conflict the regulations and rules of a higher level(e.g. European Union) take precedence over those of alower level (e.g. a member state). This approach canalso be beneficially applied to the specialization of themost important kind of business rules in informationsystems, action rules. Such rules define under whichconditions certain actions may, must not, or need tobe taken.

Applying the decision scope approach to businessprocess modeling based on BPMN means that busi-ness rules should not be buried in decision tasks butbe made explicit at the flow level. This requires a re-thinking of the current BPMN modeling paradigm inthat several aspects in conditional flow so far modeledjointly are separately captured: (a) potential order-ing of tasks, (b) conditions under which a task may ormay not be invoked, and (c) conditions under whicha particular task needs to be invoked. Rather thanre-defining BPMN as such, an appropriate extensionmay be provided on-top of BPMN and mapped tostandard BPMN primitives.

Applying the decision scope approach to activedata warehousing, where analysis rules express ac-tionable knowledge, requires to consider two alterna-tive hierarchies: (1) hierarchies of sets of points atthe same granularity and (2) the roll-up hierarchy ofpoints in multi-dimensional space.

This paper presents the decision scope approach,outlines how it complements inheritance and spe-cialization approaches typically followed in object-oriented systems, and introduces consistency rules forbusiness rule specialization as well as auto-correctionrules, which rectify an inconsistent lower-level busi-ness rule such that it becomes consistent with higher-level business rules.

Keywords: Specialization, Inheritance, BPMN, Busi-ness Processes, Business Rules, Data Warehousing

This work is supported by the Austrian Ministry of Transport,Innovation, and Technology in program FIT-IT Semantic Sys-tems and Services under grant FFG-829594 Semantic Cockpit:An Ontology-Driven, Interactive Business Intelligence Tool forComparative Data Analysis.Copyright c⃝2013, Australian Computer Society, Inc. Thispaper appeared at the 9th Asia-Pacific Conference on Con-ceptual Modelling (APCCM 2013), Adelaide, South Australia,January-February 2013. Conferences in Research and Practicein Information Technology, Vol. 143. Flavio Ferrarotti andGeorg Grossmann, Eds. Reproduction for academic, not-forprofit purposes permitted provided this text is included.

1 Introduction

Specialization is one of the most prominent tech-niques in conceptual modeling to deal with complex-ity. It assists structuring design artifacts, makingthem more compact and better comprehensible. Ar-tifacts are designed by specifying their features. Withspecialization, more specific artifacts inherit featuresfrom more general artifacts and may specialize in-herited features through extension (i.e., adding or-thogonal features) or refinement (i.e., adding detailsto inherited features); changing inherited features istermed “overriding”. Specialization is used in a num-ber of related areas, such as knowledge representa-tion [11], programming languages [9], data model-ing [36], and business process modeling [12].

While the idea of organizing artifacts (nodes insemantic networks or concepts in ontologies, typesin programming languages, classes of objects in datamodeling, and classes of business cases in businessprocess modeling) in hierarchies is common across re-lated areas, the particular notions and rule governingspecializations differ, sometimes even within the samearea. A “rule-free” (i.e., arbitrary and unconstrained)change of inherited features, which is possible in someprogramming languages by free code overriding, is indisaccord with the very ideas of conceptual modelingand of abstracting common features along specializa-tion hierarchies of design artifacts.

1.1 Contravariance and Covariance

It is generally agreed that propositions that hold formembers of a superclass1 should also hold for mem-bers of a subclass, unless stated otherwise (in caseof non-monotonic inheritance). The key differencesbetween various approaches concern (1) what partic-ular propositions over members of a class are madeby a class specification and (2) the rules that gov-ern specialization hierarchies (e.g., monotonic or non-monotonic inheritance).

In data modeling, classes usually specify con-straints over properties of their members which areinterpreted as invariant conditions that need to besatisfied by members of a class over their life time. Inknowledge representation, classes (frequently calledconcepts) specify necessary and sufficient conditionsfor an object (frequently called individual) to be con-sidered a member of a class; a change of an object’sproperty may lead to a dynamic re-classification.

In programming languages, the notion of type sub-stitutability is predominant [14, 28]: Any member

1Irrespective of the specific artifact, we will speak in the follow-ing of classes and objects, of members of classes, and of super- andsubclasses for specialization relationships between classes.

Proceedings of the Ninth Asia-Pacific Conference on Conceptual Modelling (APCCM 2013), Adelaide, Australia

3

(frequently called instance) of a class should be us-able in every place in which a member of superclassis expected. Regarding the methods specified witha class, type substitutability comes with the follow-ing proposition: “Given any member of the class, ifthe pre-condition of a method is met, the method canbe successfully performed on that member”. Noticethat the member of the class may also be a memberof a subclass whose overridden method is not con-sidered in this proposition. Type substitutability (inthe presence of local2 static type checking) requirescontra-variant inheritance - the redefined type of a pa-rameter of an inherited method needs to be the sameas or a supertype of the inherited type and a rede-fined precondition of a method must be more general(i.e., be implied by the inherited precondition). Thisensures that if the precondition of a method is met ata superclass it is also met at the subclass.

Semantic data and process models have since theirearliest appearance promoted the idea of co-varianceas the more natural approach to specialization [10];the “real world” argument for co-variant specializa-tion [16] has been adopted also by UML 2.0 [13]. Re-garding the methods of a class (or an activity of a pro-cess), co-variant specialization comes with the follow-ing proposition: “Given any member of the class, ifthe pre-condition of a method is not met, the methodcannot be sucessfully performed on that member”.Notice the difference in the propositions implied byclass specifications adhering to contra- or co-variantspecialization, it is seldom expressed ad verbis.3

Both notions, contra- and co-variance, have theirplace; usually for different purposes, substitutabilityand incremental specification. It has been suggestedto combine both notions by selecting at run time amore general method for an instance of a more spe-cific class if dynamic types of input parameters donot match the static types of input parameters of anoverridden method [15]. Such approaches may havetheir merit in special cases, but lead to inconsistenciesif specific constraints of a more specific class need tobe met (which a more general method would not beaware of).

Specialization in business process modeling hasbeen addressed by consistency notions that are akinto co-variance and contra-variance, such as observa-tion vs. invocation consistency of object life cycles(used for modeling business processes in an object-centric manner) [34], or projection vs. protocol inher-itance [5, 40] of process nets. Invocation consistencyand protocol inheritance support the idea of substi-tutability in that a process class may be seamlesslyreplaced by another process class without any effectof the embedding environment. Observation and pro-jection inheritance support the idea of incrementalspecification through extension and refinement.

1.2 Specialization and Business Rules

In re-active systems, such as active databases, theconcept of specialization has been extended to activerules (that initiate an activity based on events andconditions) and studied in depth with respect to typesubstitutability [6].

Constraints, pre- and postconditions of methods,and active rules capture business rules explicitly atthe design level in a declarative form and do not burythem in hidden design artifacts (such as in internals

2i.e., without global program code analysis3The different semantics of pre- and postconditions of methods

has been described from a different angle based on deontic logic,but without explicit reference to co- and contra-variance [41].

of decision activities or in procedural method spec-ifications). At the requirement level, business rules(which are defined as any “rule under business juris-diction” by OMG) should, according to the BusinessRule Manifesto [1], be specified in declarative from asprovided by the SBVR-specification [2] for document-ing the semantics of business vocabularies, businessfacts, and business rules. Scientific work has classi-fied business rules into static business rules expressinginvariant conditions over facts and their relationshipsand into dynamic business rules expressing rules thatconcern state changes [21].

Information system design needs to address thechoice on how to best represent business rules in de-sign artifacts. It is nowadays commonly accepted thatbusiness rules should not be hidden, but be explicitlycaptured in a declarative form[1]. We have argued inthe past [25] that depending on the kind of businessrule, different choices should be made on how to cap-ture business rules in process modeling, such as by us-ing constraints, by pre- or post-conditions of activities(defining enabling conditions and results, resp.), or byusing activation conditions (defining under which con-ditions an activity is triggered). We have also intro-duced an object-centered design approach for jointlymodeling object structure and business processes [24],an approach which currently receives considerable at-tention in conference panel discussions and industrypromotion under the labels “artifact-centered busi-ness process modeling” [22] and “case base manage-ment process modeling” (CMPM). And we have sep-arated several concerns in business process modelingthat are frequently mixed: (1) potential ordering ofactivities, (2) passive pre- and post-conditions of ac-tivities (specified independently of the invocation ofactivities by pre- and post-states in a net represen-tation or by expressions in some form of predicatelogic over business cases and activity parameters, orby both), and (3) activation rules that define un-der which conditions (including events) an activityis invoked [27]. Such a separation is in our opiniona pre-requisite to appropriately handle specializationof business rules in the context of business processesmodeling and data ware housing.

The issue of specialization of business rules hasbeen briefly discussed [8, 26, 37], but to the best ofour knowledge not been extensively addressed so farin a comprehensive, uniform manner. At the require-ment elicitation level, the SBVR-specification of sev-eral hundred pages comes without a comprehensivedescription of criteria for the specialization of busi-ness rules. At the design level, alternative approaches- as described above - have been promoted.

1.3 Business rules and decision scope

To move forward, we look for guidance by consider-ing on how law is “specialized” along law hierarchies(e.g. constitutional law, simple law) or, similarly, onhow rules are specialized along levels of jurisdictions(e.g., regulations at the level of the European Union,regulations at the level of a member state). In thesecontexts it is common to apply a decision-scope ap-proach to decision making. Higher organization levelsdefine what is permitted and what is forbidden. Dif-ferent to deontic logic, permissions and prohibitionsare not complementary but leave a decision-scope inwhich lower organization levels may operate. Reg-ulations and rules of a higher level (e.g. EuropeanUnion) take precedence over those of a lower level(e.g. a member state) in case of conflict. Such anapproach can also be beneficially applied to the spe-cialization of business rules. We describe this in the

CRPIT Volume 143 - Conceptual Modelling 2013

4

paper for the most important kind of dynamic busi-ness rules in information systems, action rules. Suchrules define under which conditions certain actionsmay, must not, or need to be taken.

Applying the decision-scope approach to special-ization reconciles the apparently conflicting special-ization approaches of co- and contra-variance by fol-lowing them separately in parallel. The proposi-tions underpinning contra-variance inheritance rep-resent permissions stating under which conditions amethod may be invoked; the propositions underpin-ning co-variance represent prohibitions stating un-der which conditions (if a precondition is violated),a method cannot be invoked (i.e. the method invoca-tion will fail).

The decision scope approach as described can beextended to activation conditions, which may triggeran activity if is permitted to do so. But not every ac-tivity that is permitted need to be actually invoked.There is a discretion to choose. This discretion is im-portant in the context of conditional flow in businessprocess modeling, where activation conditions may ineffect chose any of several potentially applicable, i.e.,permitted activities. In semi-formal decision makingsuch a choice is deferred to the case officer. OMGpromotes two opposite approaches to business processmodeling, BPMN [35] where all flows and flow condi-tions are pre-defined and CMPM in which flow condi-tions and choices can be identified by a case manageron a case by case basis. The decision scope approachis applicable to both. For CMPM, it is required toconsider different types of guards. For BPMN, multi-ple aspects in conditional flow so far modeled jointlyneed to be separately captured: (a) potential order-ing of tasks, (b) conditions under which a task may ormay not be invoked, and (c) conditions under which aparticular task needs to be invoked. We will presentsuch an extension to BPMN later in the paper andexplain that rather than re-defining BPMN as such,an appropriate extension may be provided as well on-top of BPMN and mapped to standard BPMN prim-itives (based on event-based gateways and deferreddecisions).

Another dimension of choice in inheritance ismonotonicity. Specialization and the decision-scopeapproach are inherently monotonic as any potentialconflict of rules is resolved by precedence of rules ofhigher organizational levels over those of lower or-ganizational levels. To avoid repeated specificationof the same rules at lower organization levels, apartfrom a few exceptions, non-monotonic rules are usedin law systems as well. These are explicitly identi-fied as such by stating that a rule is presumed forlower jurisdictions and may be overridden by them(e.g., world wide sales conditions state that warrantyis for one year, unless local consumer law prescribes alonger warranty period). Approaches in which mono-tonic and non-monotonic rules coexist in a decisionscope setting have been proposed in the context ofauthorization in database systems [7]: Authorizationrules are classified into positive (corresponding to apermission) and negative (corresponding to a pro-hibition) rules and orthogonally thereto into strong(monotonic) and weak (non-monotonic) rules. Vari-ous rules govern the interplay of their combination inthe context of inheritance along hierarchies of autho-rization objects, e.g., a weak positive authorizationof a higher level may be canceled by a strong nega-tive authorization rule at a lower level. This principlecan be beneficially carried over to the specializationof business rules in general.

1.4 Decision Scope and Data Warehousing

The decision-scope approach is also relevant to ac-tive data warehousing [30, 38, 39], in which analy-sis rules express actionable knowledge, and to com-parative data analysis in business intelligence [32],in which comparison results between two groups offacts (group of interest and group of comparison) maytrigger actions providing guidance on how to pro-ceed in analysis (guidance rules) or actions informinganalysts about striking comparison results that mayneed further attention or action (judgment rules). Wehave applied some limited form of decision-scope ap-proach in active data warehousing in the past andencountered the need to study specialization of anal-ysis rules in the SemCockpit[32] project. In additionto business process modeling, two alternative hierar-chies need to be considered: (1) hierarchies of setsof points at the same granularity and (2) the roll-uphierarchy of points in multi-dimensional space.

Specialization along subset relationships betweensets of points at the same granularity is governed bythe same rules as specialization between a superclassand a subclass of objects. Specialization along a roll-up hierarchy of points in multi-dimensional space ac-tually concerns entities of different kinds, yet con-nected by some form of part-of relationship. Thisgives rise to two alternative rule evaluation strate-gies, both meaningful in practice, but with a differentapplication space in mind.

In the prerogative strategy, an action triggered fora higher-level point implicitly implies the same actionfor each lower level point. E.g. if a company decidesto abandon a product line (such as mobile phones)this decision is implied for every product (i.e., everyphone model in our example) of this product line.

In the presumed strategy, an action (typically aninformative one) triggered for a higher level point ispresumed to cover also lower level points and is thusnot carried out again for lower level points (to avoidunnecessary information overload, the basis of per-forming roll-up analysis in data warehousing), unlessit is justified by a negative activation rule. E.g., ifin comparative data analysis a judgment rule triggersan informative action that average treatment costs forpatients with diabetes mellitus of type 2 patients inAustria are twice as high than in Germany last year,it is presumed that this will hold in general for eachprovince in Austria. Minor deviations are generallynot of interest in comparative data analysis, but ma-jor ones are. The knowledge what kind of exceptionsshould be reported (a kind of business rule) can beexpressed by a negative activation rule according tothe notion of negative rules described before. Sucha negative activation rule may trigger an informativeaction reporting a notable exception if the differencein compared costs is less than 20% for comparing pa-tients in a province of Austria with patients in Ger-many but a positive activation rule has led to reportat a higher granularity a striking difference of averagetreatment cost per patient in Austria versus Germany.E.g., based on such deviating observation for compar-ing Tyrol (a province of Austria) with Germany thisrule will report that contrary to Austria as a whole,average treatment costs per patient have been similarwhen comparing Tyrol with Germany.

We discuss the decision scope approach to special-ization of business rules from a general perspective inthe remainder of this paper, which is organized as fol-lows. In Section 2, we quickly revisit co- and contra-variant specialization approaches in object-orientedsystems and describe how the decision scope approachapplied in organizational contexts reconciles both. In


5

Section 3, we show by detailed examples how thedecision-scope approach can be applied in the realmof business process modeling and propose an exten-sion of BPMN to this purpose. We introduce a setof consistency rules that govern the decision scopeapproach and introduce a set of auto-correct-rules tomodify inconsistent rules such that they become con-sistent. Continuing the law analogy, auto-correctionamounts to repealing a simple law by a constitutionalcourt if it contradicts constitutional law. In Section 4,we extend the decision-scope approach to data ware-housing. Section 5 concludes the paper with a sum-mary and outlook.

2 Inheritance: A Quick Review and an Intro-duction to the Decision Scope Approach

We quickly review the notions of co- and contra-variant inheritance in conceptual modeling andobject-oriented systems, introduce the decision scopeapproach to specialization as observed in law and or-ganizational context, and show how co- and contra-variant inheritance can be reconciled in the decision-scope approach by following both notions indepen-dently in parallel.

2.1 Inheritance in Conceptual Modeling andObject-Oriented Programming

The notion of specialization according to co-variancehas been promoted by semantic data and processmodels as a natural approach to reflect how sets andsubsets of objects of the real world relate. It supportsinformation systems design by specializing a moregeneral class through extension, i.e. by adding newproperties (attributes or relationships), and refine-ment, i.e., by providing more detail for inherited prop-erties or by restricting them. Usually, classes spec-ify invariant conditions over properties of its mem-bers. These are treated as constraints that need to besatisfied by its members over their life time. Inher-ited invariant conditions may be strengthened at sub-classes. Any member of a subclass is considered to bealso a member of the superclass such that if inheritedconstraints (invariant conditions) are strengthened atsubclasses a member of a subclass will also satisfythe more general constraints of its superclasses. Incase of relationships between members of classes, asubclass of one side of the relationship may restrictthe inherited relationship to be to a subclass of theoriginal other side of the inherited relationship. Con-sidering relationships does not add to the nature ofthe problem itself, we restrict our discussion to at-tributes of object classes with simple types (such asInteger, String or restrictions of these) from here on.

UML 2.0 [18] has also adopted co-variant special-ization and we will use it to present our examples.

Example 1. We consider a very abbreviated descrip-tion of selected parts of a loan application process inthis paper. Figure 1 depicts a class hierarchy of loanapplications in UML notation. Loans are describedby an amount (a), a credit worthiness (w)4, and amonthly rate (r). Private loan applications are fur-ther described by the attachable income (i) that is ofrelevance for salary seizures should the private loannot be repaid. Mortgage loans are further describedby a mortgage lending limit (l) of the mortgaged prop-erty that is of relevance if the mortgage is to be re-deemed should the loan not be repaid.

4Actually, the credit worthiness relative to the loan applicationis a function of available disposable income and requested loanamount; we abstract from such details here.

Invariants specify that amounts of loans are be-tween 10 and 900k $, amounts of private loans be-tween 10 and 70k $, and amounts of mortgage loansbetween 30 and 900k $.

LOAN

amount: $inv: amount 10 and amount 900

creditWorthiness: Int

monthlyRate: $

setAmount (a: $)setAmount (a: $)precond: a 10 and a 900

safe-setAmount (a: $)precond: a 30 and a 80

PRIVATE LOAN MORTGAGE LOAN

attachableIncome: $

setAmount (a: $)precond: a 10 and a 80

lendingLimit: $

setAmount (a: $)precond: a 30 and a 900

inv: amount 10 and amount 80

inv: amount 30 and amount 900

Figure 1: Class Hierarchy of Loans

Strengthening of constraints over inherited objectproperties, either by restricting their type to a sub-type (subclass) or by strengthening explicitly statedinvariant conditions, require co-variant inheritancefor “mutators”, i.e., methods that update the valuesof attributes. The domain of input parameters of in-herited methods must be accordingly restricted to asubtype of the updated inherited property and pre-conditions of inherited methods must be accordinglystrengthened to reflect to stronger invariant conditionat the subclass. This applies also to types of returnvalues of methods and their postconditions. We re-peat what we already mentioned in the introductionthat a precondition of a method is to be interpretedas a proposition that ”Given a member of the class, ifthe precondition of a method is not met, the methodscannot be performed on that member“.

Example 2. Method setAmount(a:$) of class LOAN,which sets the amount of a loan application to thevalue supplied as parameter, has a precondition coin-ciding with the corresponding invariant. Notice thatin general preconditions of methods may be differ-ent to re-stating relevant invariants. In fact it shouldbe unnecessary to include relevant invariant condi-tions in pre-conditions as these kinds of precondi-tions should ideally be inferred (at least for setter-and getter-methods). The precondition of methodsetAmount is overridden at subclasses PRIVATE LOANand MORTGAGE LOAN to reflect the invariants of theseclasses accordingly. The specialization applied com-plies with co-variance as explained earlier.

Class hierarchies designed according to co-variancein conceptual data modeling match class hierarchiesthat would be built by ontology reasoners based onclass descriptions that contain no reference to super-classes but contain explicit descriptions of otherwiseinherited attributes.5 The main difference is that inconceptual modeling the class hierarchy is the pri-mary design artifact along which attribute descrip-tions are inherited by subclasses from superclasses,

5We assume here that concepts in the ontology refer to a com-mon set of objects and that class descriptions are interpreted asconcept expression stating that the concept comprises all objectsof the given object class that possess the attributes of the class andsatisfy the invariant conditions of the class.


6

whereas in current ontology engineering practice, therelationships of classes (concepts) to their attributes,but without reference to a superclass, are the primarydesign artifact and subclass relationships are inferredthrough subsumption reasoning.

There are - depending on the ontology and con-ceptual model used - other differences between on-tologies and conceptual data modeling, but these arenot relevant for the point we wish to make here thatclass hierarchies and corresponding concept hierar-chies align one-to-one. While originally, ontologieswere envisioned as an explicit formal specification ofa conceptual model [19, 20], especially since the in-ception of Semantic Web research, ontology languagesfrequently take on the open world assumption, whileconceptual modeling mostly adheres to the closedworld assumption. Also, ontology languages treatconditions over attributes as conditions for classify-ing objects whereas data models typically treat con-ditions over attributes as constraints that may not beviolated in updating a member of a class. But thisis not a universal assumption, as since the early daysof conceptual modeling primitive classes have beencomplemented by derived classes whose members aredynamically re-classified if they no longer meet thederivation condition of the derived class. When onetakes into account the full history of conceptual mod-eling, many claimed differences between conceptualmodels and ontology languages become blurred, es-pecially since within ontology research basic distinc-tions of approach such as the ability to infer a sub-sumption (inheritance) hierarchy by reasoning or todefine it by specification depend on the language used(e.g., [4, 3]).

While conceptual modeling and ontology engineer-ing would be expected6 to come up with generally thesame hierarchy, but use different paths to achieve thesame result, this “common” class hierarchy will usu-ally not constitute a class hierarchy that satisfies typesubstitutability as demanded by the contra-variantapproach to inheritance promoted in object-orientedprogramming. Contra-variant inheritance requires togeneralize the types of input parameters of inheritedmethods to super types and to generalize inheritedpreconditions of methods in overriding. This ap-proach ensures that any method that can successfullybe applied on some instance of a class can also be suc-cessfully applied on any instance of subclass of theformer. We repeat what we have already stated inthe introduction: a precondition of a method is to beinterpreted as proposition “Given a member of theclass, if the precondition of the method is met, themethod can be successfully performed on that mem-ber.”

Example 3. The class hierarchy of loans in Fig-ure 1 violates substitutability. However, method safe-SetAmount(a:$) of class LOAN with precondition a ≥ 30

and a ≤ 90 is “type-safe”. It can be applied on anymember of class LOAN, be it a mortgage loan or aprivate loan.

2.2 The Decision-Scope Approach in Law:Constitutional Law before Simple Law

Law hierarchies and organizations use a decision-scope approach for decision making along hierarchiesof law or organizational levels. Regulations and rulescome (among others) in two typical forms, permis-sion that allow actions and prohibitions that forbid

6Notice that we do not claim a one-to-one correspondence butconsider the global picture.

actions. Permissions and prohibitions are not com-plementary. There are actions that are on the onehand not explicitly permitted and on the other handnot explicitly forbidden. This leaves room for maneu-ver in decision making at lower organizational levels.We also observe that legal cases usually are relatedto a most specific jurisdiction and in case of potentialmultiple jurisdictions there are tie-brakers to decideupon in which concrete jurisdiction a legal case is tobe handled. Similarly, we assume the abstract super-class rule, which has been identified as good designpractice, is applied in designing class hierarchies [23]:Each object belongs to a single, most-specific classthat is concrete, i.e., has no subclasses.

The decision scope approach is governed by a sim-ple, intuitive set of consistency rules:

1. Permission and prohibitions are always dis-joint and they are complementary at a concretebottom-level organizational entity / law.

2. What is permitted at a higher level is also per-mitted at lower levels.

3. What is forbidden at a higher level is also forbid-den at lower levels.

If we take this perspective and revisit the notionsof co- and contra-variant inheritance, we can observethat the propositions made by contra-variant special-ization correspond to permissions and the proposi-tions made by co-variant specialization stretch overpermissions and the decision scope, or if negated, cor-respond to prohibitions (i.e., to what is forbidden).

This observation allows us to superimpose bothkinds of propositions into a single, dual-faceted classdescription. Behavior attributed to the permissivepart of the class description is type safe in the tra-ditional sense of type substitutability. Behavior at-tributed to the prohibitive part of the class descrip-tions can be identified as “illegal”, i.e., such actioncannot be performed on any member of the class. Todecide whether behavior attributed to the decisionscope is permitted or forbidden, one needs to con-sult lower level classes along the class hierarchy tothe concrete class of an object. For concrete classes,the decision scope is closed, i.e. what is forbidden isnot permitted and what is permitted is not forbid-den. The dual facets of class descriptions of abstractclasses become a single facet for concrete classes.

Example 4. The class hierarchy of loans in Figure 1with methods setAmount and safe-SetAmount of classLOAN already represents such a dual-faceted class de-scription. However, an integrated description wouldonly represent a single method with a positive (re-flecting permission) and a negative (reflecting prohi-bition) precondition. Similarly, in an integrated de-scription the current invariant shown for class LOANwould be converted into a negative invariant condi-tion a < 10 or a > 900 (which if met when updatinga member will constitute an invalid update, irrespec-tive to which specific class the member belongs to)and complemented by a positive invariant conditiona ≥ 30 and ≤ 90 (which if satisfied when updating amember will constitute a valid update, irrespectiveto which specific class a member belongs to).

Figure 2 illustrates the decision scope approachand its relation to co- and contra-variant inheritance.

3 The Decision Scope Approach in BusinessProcess Modeling

In this section we discuss how the decision scope ap-proach can be applied to business process modeling.


7

Permitted

Decision ScopeContra-Variant

Preconditions

Co-Variant Preconditions

Forbidden

Abstract

Class

Concrete

Class

...

Figure 2: The basic Decision-Scope Approach

In particular we consider the, in our opinion, most im-portant kind of dynamic business rules: action rules.They concern under which conditions certain actions(activities, tasks) may, must not, or need to be takenin the process flow.

3.1 Business Rules in Business Process Mod-eling

Business rules in business process modeling expressconstraints over properties of business cases, the po-tential order of activities, pre- and postconditions ofactivities, and activation conditions (which expressunder which conditions a particular activity is in-voked). At the design level, constraints over prop-erties of business cases are typically captured by themodeling primitives of conceptual data models andassociated constraint language (e.g., by UML cardi-nality constraints or OCL); the potential order of ac-tivities is typically captured by various forms of pro-cess diagrams based on Petri nets, state charts, orsimilar formalisms. Conditions under which activtiesmay, must not, or need to be taken are frequently notconsidered independently from process flow. Apply-ing a decision scope approach to modeling businessrules that govern the execution of business processesrequires to consider these kinds of conditions indepen-dently of each other and of process flow. But beforewe look into the specialization of business rules, werevisit the modeling of business processes from a gen-eral perspective.

The order of activities of a business process is typi-cally expressed by some form of process diagram, e.g.,by BPMN. Of particular interest are decision pointsat which process flow splits into alternatives.

Example 5. Figure 3 depicts a fragment of a loanapplication process. Once the credit worthiness fora loan application has been determined (not shown),the loan application is granted ( g), rejected ( j), orforwarded for decision to the board ( f). Note: Thisis a simplified picture, the loan application processmodeled may have other alterative paths at this deci-sion point such as requesting additional informationfrom the applicant if the case officer is not satisfiedwith the information at hand. Note: The loan appli-cation process modeled in full (in Petri-net notation)can be found in [26].

Activities are governed by business rules that de-fine under which conditions an activity a of a processclass O may be invoked (P a

o ), must not be invoked(F a

o ), or need to be invoked (Oao). To keep the ex-

planation of the decision scope approach simple, weassume herein for simplicity that conditions are ex-pressed over properties of a business case. However,the presented approach can be extended to conditionsover parameters of activities and to events. Note that

Forward to

Board

Reject Loan

Grant Loan

Loan

Figure 3: Fragment of Loan Application Process inBPMN

we use the terms permission (P ), prohibition / forbid-den (F ), and obligation (O) from deontic logic; butdifferent to deontic logic “permitted is not equivalentto not forbidden” and, conversely, “forbidden is notequivalent to not permitted”. Likewise, we will lateruse disobliged (D) as “counterpart” to obliged (O),where both conditions are again not complementary.

Example 6. Figure 4 visualizes the business rulesgoverning activity forward depending on the amountof the loan and the credit worthiness of the appli-cant with respect to the loan application. (Note thatdifferent to Figure 1 we assume here and in the fol-lowing that all kinds of loans are between 0 and 80k$. This is to simplify the presentation and to be ableto focus on key points). A loan application with alow credit rating must not be forwarded to the board(as it should be immediately rejected). A loan appli-cation for a low amount and with a very high creditrating must not be forwarded to the board either (asit should be immediately granted). A loan applica-tion for a high amount and a medium credit ratingmay (dependent on the discretion of the case officer)be forwarded to the board.

The white “open space” in Figure 4 constitutesthe decision scope for activity forward for subclassesof class LOAN, which will be introduced later.

Note that we have used positive (+), negative (−),and activation ( ) conditions to specify permitted,forbidden, and obliged invocation of an activity. Weintentionally use here a different terminology and no-tation (+,−, ), for conditions indicated with activ-ities as we will later auto-complete and auto-correctindicated conditions to permissions (P ), prohibitions(F ), and obligations (O).

Similarly, Figure 5 visualizes the business rulesgoverning activity grant of class LOAN and Figure 6the business rules for activity reject of class LOAN.

The business rules governing a single activity mustbe conflict-free (see: Figure 7), i.e., for the state of abusiness case (given by values of its properties): (1)an activity may not be permitted and forbidden aswell, (2) an activity may not be obliged and disobligedas well, (3) if an activity is obliged it is permitted, and(4) if an activity is forbidden it is disobliged.

The business rules governing the set of alternativeactivities A at a given decision point in a business pro-cess must be decision-consistent (Figure 8), i.e., for astate σ of a business case at the decision point: (1) atleast one activity must be permitted, and (2) at mostone activity is obliged (which means it is permitted).- Note that for simplicity we consider only alterna-tive (i.e., exclusive) choice here. Notice also that itis possible that several activities are permitted at the


8

60

40

30

20

10

50

0 64321 5 7 8 9

amountin k$

creditworthiness

f

f

f

FforwardLOAN

(loan rejected)

PforwardLOAN O

forwardLOAN

FforwardLOAN

(loan granted)

f

Figure 4: Business process LOAN: Business Rules Re-garding forward

60

40

30

20

10

50

0 64321 5 7 8 9

amountin k$

creditworthiness

g

g = +g

g

Figure 5: Business process LOAN: Business Rules Re-garding grant

same time and it is possible that no activity is obligedfor a given state of a particular instance of a businessprocess (as determined by the values of its proper-ties). Then it is at the discretion of a human processagent to decide which one of the permitted alternativeactivities to choose for a given process instance.

Considering the propositions we attached to per-mission and prohibition of an activity, i.e., that anactivity may be executed for a business case if itspermission is met and that an activity cannot be ex-ecuted for a business case if its prohibition is met, weadd two other consistency criteria such that these twopropositions are correctly reflected in case of alterna-tive activities: If an activity is obliged, alternativeactivities are forbidden (criterium no. 3 in Figure 8)and if an activity is permitted, alternative activitiesare disobliged (criterium no. 4 in Figure 8), whichmeans they cannot be obliged at the class or somesubclass. We note that criterium no. 2 is redundant.It follows from no. 4 in Figure 8 and no. 3 in Figure 7.

During business process design, adding an obli-gation to an activity may be restricted by the per-missions defined with alternative activities and mayrequire to extend the prohibitions specified with al-ternative activities such that criteria no. 3 and 4 ofinter-activity consistency are met. To avoid such re-dundant specification, we introduce appropriate auto-completion and auto-correction rule in subsection 3.3.

60

40

30

20

10

50

0 64321 5 7 8 9

amountin k$

creditworthiness

j j

j = +j

Figure 6: Business process LOAN: Business Rules Re-garding reject

1. Permitted is not forbidden, and vice versa:P ao (σ)→ ¬F a

o (σ), Fao (σ)→ ¬P a

o (σ)

2. Obliged is not disobliged, and vice versa:Oa

o (σ)→ ¬Dao (σ), D

ao(σ)→ ¬Oa

o (σ)

3. What is obliged is permitted:Oa

o (σ)→ P ao (σ)

4. What is forbidden is disobliged:F ao (σ)→ Da

o(σ)

Figure 7: Criteria for Intra-Activity Consistency

Example 7. The business rules for activities forward(Figure 4), grant (Figure 5), and reject (Figure 6)of process class LOAN are intra-activity and inter-activity consistent.

Figure 9 shows the business rules for activities for-ward, grant, and reject for loans superimposed. Notethat situations that can be inferred according to theconsistency criteria are not specifically indicated: Ifan activity is obliged (shown) all other activities areforbidden (not shown), and if an activity is obliged(shown) it is permitted as well (not shown).

Business rules governing the permitted, forbidden,and obliged invocation of an activity in a businessprocess should be explicitly represented at the designlevel rather than buried within activities. The latterapproach would contravene the objective of concep-tual design to make business rules explicit. Just ascardinality constraints, an important class of staticbusiness rules, are captured in UML graphically by

1. At least one activity permitted:∃a ∈ A : P a

o (σ)

2. At most one activity is obliged:a ∈ A, b ∈ A, a = b : Oa

o (σ)→ Dbo(σ)

3. If an activity is obliged, alternative activitiesare forbidden:a ∈ A, b ∈ A, a = b : Oa

o (σ)→ F bo (σ)

4. If an activity is permitted, alternative activi-ties are disobliged:a ∈ A, b ∈ A, a = b : P a

o (σ)→ Dbo(σ)

Figure 8: Criteria for Inter-Activity Consistency


9

60

amountin k$

40

30

50

j

g f f

20

10

j

g

j

0 64321 5 7 8 9credit

worthiness

Figure 9: Business process LOAN. Business Rules Re-garding grant, forward, and reject (superimposed)

cardinality indications associated with associations,action rules should likewise be explicitly capturednext to the process flow in business process model-ing notations such as BPMN or captured by differ-ent kinds of guards in case-based management processmodeling (CMPM).

Example 8. Figure 10 indicates, as extension toBPMN, permitted, forbidden, and obliged invocationof an activity in process flow as positive (+), negative(−), and activation ( ) condition.

Forward to

Board

Reject Loan

Grant Loan

w < 2

: w 3 a 40

w < 2 ( w 7 a < 10)

w 7 a < 10

w 7

w < 2 a 40

w 7 a 40

Loan

w < 2

w 7 a < 10

Figure 10: Business process LOAN in BPMN, ex-tended with positive (+), negative (−), and activationconditions ( )

Rather than requiring a change in BPMN, thisproposed extension can be provided on top of BPMNand mapped to standard BPMN modeling primitives.E.g., an exclusive OR-gateway with positive, nega-tive, and activation conditions on its outflow may bemapped to an event-based, deferred decision gateway,with a send-event at its inflow and different catch-events for each activity at its outflow. The decisionprocedure itself may be mapped to a decision process(e.g., following the “decision logic abstraction pat-tern” in rBPMN [29]) that is initiated by catchingthe send event associated with the inflow of the OR-gateway and completed by sending one of the eventscaught in the ouflows of the OR-gateway. For semi-automatic decision making, these events may be ex-plicitly raised in all or some occasions by a humanprocess agent.

3.2 Specialization of Business Rules

Following the decision scope approach, action rules ofa process class o may be specialized at a subclass oin that more specific rules at the subclass must actwithin the decision scope set by the superclass andproviding room for manoeuvre at the subclass (see:Figure 11).

O F

P D

Abstract

Class

Concrete

Class

...

Figure 11: The Decision-Scope Approach

In particular, see Figure 12, (1) an action ruleat the subclass must be more general than the samekind of rule at the superclass (generalization), (2) ac-tion rules at the subclass must not contradict thosegiven at the superclass (super-subclass inter-activityconflict-freeness), and (3) (a) permissions and pro-hibitions for concrete classes are complementary, (b)an activity is obliged if all alternative activities areforbidden, (c) an activity is disobliged if some otheractivity is permitted, and (d) obligations and dis-obligations are complementary (closed decision scopefor concrete classes). Note that for checking overallconsistency it would be sufficient to check first forgeneralization and then for activity-consistency (seeabove); the criterium “super-subclass intra-activityconflict-freeness” additionally captures a core princi-ple of the decision-scope approach that superclassesshould dominate subclasses. This will be of particu-lar relevance when we later introduce auto-correctionrules. We also note that one of the three criteria (3b-3d) is redundant.

We now apply this perspective to our use case.

Example 9. Figures 13 and 14 visually indicatethe business rules governing activities forward, grant,and reject for private loans and mortgage loans re-spectively. As before with Figure 9, if an activity isshown obliged, all other activities are forbidden (notshown), and if an activity is shown obliged it is per-mitted as well (not shown). Two diagrams are shownfor private loans, one covering the case where the at-tachable income i is less than the monthly rate r,the other one where it is higher (in which case itsis much riskier to grant a loan as rates cannot befully recovered by salary seizures). Similarly, two dia-grams are shown for mortgage loans, one covering thecase where the amount a of the loan is at less than70% of the mortgage lending limit l of the property,the other one where it is higher (in which case its isriskier to grant the loan as the loan amount may notbe fully redeemable by sale of the property). Note:The application process for loans and the applicationprocess for private loans specialize the more generalapplication process for loans by adding activities andstates. They have been modeled in a Petri-net no-tation in [26] and are governed by the consistencycriteria for process specialization presented in [34].

One can easily verify by visual inspection that therules for mortgage loans and the rules for private loans


10

1. Generalization

(a) P ao (σ)→ P a

o (σ)

(b) F ao (σ)→ F a

o (σ)

(c) Oao (σ)→ Oa

o (σ)

(d) Dao (σ)→ Da

o (σ)

2. Intra-Activity Conflict-Freeness

(a) P ao (σ)→ ¬F a

o (σ)

(b) F ao (σ)→ ¬P a

o (σ)

(c) Oao (σ)→ ¬Da

o (σ)

(d) Dao (σ)→ ¬Oa

o (σ)

3. Closed decision scope for concrete class o

(a) P ao (σ) = ¬F a

o (σ)

(b) Oao (σ) =

∧b∈A,b =a F

ao (σ)

(c) Dao (σ) =

∨b∈A,b =a P

ao (σ)

(d) Oao (σ) = ¬Da

o (σ)

Figure 12: Criteria for Decision Scope Consistency:Subclass o, superclass o, state of business case σ

are “decision-scope consistent” with those for loans ingeneral (see: Figure 9). Moreover, note that no deci-sion scope is left with mortgage loans and for privateloans as regard to permissions and prohibitions. Itis known for each activity whether it is permitted orforbidden.

Figures 15 and 16 show the representation ofthese business rules at the design level using the pro-posed extended BPMN notation. Notice that thediagrams shown provide a full picture for each ac-tivity, including inherited and redundant conditions(e.g., if an activity is obliged, the activity is permit-ted and alternative activities are forbidden). Auto-completion rules introduced below enable designersto specify much simpler diagrams (e.g., Figure 18).

3.3 Auto-Completion and Auto-Correctionof Business Rules

Decision consistency can be ensured in several ways:(1) a priori by having reasoners checking for subsump-tion or disjointness of rule conditions according to theidentified consistency criteria, (2) a priori by auto-correction and auto-completion of specified rule con-ditions in a way such that the consistency criteria aremet, and (3) a posteriori by checking for conflicts dur-ing process execution. All three options are sensibleand may also be used together, each for a differentkind of consistency criterium.

A priori checking by reasoners can immediatelyidentify decision conflicts but will usually limit theexpressiveness of the language for writing rule condi-tions (a situation encountered frequently with ontol-ogy languages where languages supported efficientlyby reasoners often do not meet the desired expres-siveness). Moreover, it will require repeating ruleconditions at subclasses, while in conceptual model-ing subclasses usually only specify the “delta” (i.e.,additional or changed features with respect to the su-perclass).

Auto-correction and auto-completion of specifiedactivity conditions according to the intent of thedecision-scope approach is more appropriate in gen-

60

50

amountin k$

40

30

50

j f

f j g

20

10

credit

g

i 64321 5 7 8 9credit

worthinessi r

60

amountin k$

40

30

50

j f

30

20

10

j

g

64321 5 7 8 9credit

worthiness

g

i r

Figure 13: Business process PRIVATE LOAN. Businessrules regarding grant, forward, and reject (superim-posed)

eral. Auto-correction and auto-completion rules de-termine based on given (but possibly incomplete andinconsistent) conditions, whether an activity is per-mitted, forbidden, or obliged for a given process stateof a business case. Similar approaches are employedin database systems or programming languages. Indatabase systems, the violation of an integrity con-straint need not lead to a transaction abort but maycorrected in that other data are inserted, deleted, ormodified as well such that all integrity constraintsare finally met (e.g. the SQL-clause, ON DELETE CAS-CADE). In programming languages, pre-conditions ofinherited methods are implicitly “or“-ed such that thecriteria of contra-variant contract specialization aremet (e.g., Eiffel).

Auto-correction and auto-completion take the roleof remedying inconsistencies similar to the way inwhich simple law is repealed by a constitutional courtif it is in conflict with constitutional law. The con-sistency criteria can be enforced as follows by auto-correction and auto-completion.

Generalization: Auto-completion in that an activ-ity condition at the subclass is extended (using logical“or”) by the activity condition of the same kind at thesuperclass.

Super-sub class intra-activity conflict-freeness:Auto-correction in that the activity condition at thesubclass is restricted (using logical “and”) to the de-cision scope set by the superclass.

Closed decision scope for concrete classes: Thereare two choices for auto-completion to close the deci-sion scope for permission and prohibition, either per-mitting everything that is not forbidden or forbiddingeverything that is not permitted. Auto-completionfor obligation is to set obligation of an activity to the


11

60

50

amountin k$

f

40

30

50 f

j

f j g

20

10

credit

g

0 7l 64321 5 7 8 9credit

worthiness0.7l a

60

amountin k$

40

30

50

j

f

30

20

10

j

g

64321 5 7 8 9credit

worthiness0.7l a

Figure 14: Business process MORTGAGE LOAN. Busi-ness rules regarding grant, forward, and reject (super-imposed)

conjunction of prohibitions of all alternative activi-ties. And the decision scope between obligation anddisobligation can be closed by setting disobligation tothe complement of obligation.

Intra-activity consistency: There are two choicesfor auto-correction of conflicts between permissionand prohibition depending on whether prohibitionsshould take dominance over permissions or vice versa.Auto-correction is that the subordinate condition isrestricted to the complement of the dominant con-dition, e.g., permission to negated prohibition. Thesame situation applies for obligation and disobliga-tion. Inconsistencies between obligation and permis-sion and between prohibition and disobligation canbe rectified by auto-completion in that permission isextended by obligation and disobligation by prohibi-

Forward to

Board

Reject Loan

Grant Loan

i < r w 7 a 10)

i r w 2 a 10)

Private Loan

i < r w 7 a < 10)

i r w 2 a < 10)

(i < r ((w 3 w < 7) (w 7 a 10)) (i r w 2 a 10)

(i < r ( w < 3 (w 7 a < 10)) (i r ( w < 2 (w 2 a < 10))

w < 2 (i < r w < 7)

w 7 (i r w 2)

(i < r w 7 a < 10) (i r w 2 a < 10)

(i < r (w < 7 a 10)) (i r (w < 2 a 10))

i < r w < 3)

i r w < 2)

Figure 15: Business process PRIVATE LOAN in ex-tended BPMN

Forward to

Board

Reject Loan

Grant Loan

0.7l < a w < 3)

0.7l a w < 2)

(0.7l < a ((w 3 w < 7) (w 7 a 40))

(0.7l a w 2 a 40)

0.7l < a w 7 a 40)

0.7l a w 2 a 40)

Mortgage Loan

0.7l < a w 7 a < 40)

(0.7l a w 2 a < 40)

w < 2 (0.7l < a w < 7)

(0.7l < a (w < 3 (w 7 a < 40)) (0.7l a ( w < 2 (w 2 a < 40))

w 7 (0.7l a w 2)

(0.7l < a (w < 7 a 40)) (0.7l a (w < 2 a 40))

(0.7l < a w 7 a < 40) (0.7l a w 2 a < 40)

Figure 16: Business process MORTGAGE LOAN in ex-tended BPMN

tion. Alternatively, one could use auto-correction byrestricting obligation to permission and prohibitionto disobligation.

Inter-activity consistency: The criterium that atleast one activity is to be permitted for each possi-ble state of a business case amounts to checking fordeadlock and cannot be covered easily in a meaning-ful way by auto-correction; such a decision needs tobe managed manually a priori (at design time) or atbusiness process execution time. The criterium thatalternative activities are forbidden if an activity isobliged can be enforced by restricting obligations orby extending prohibitions, the criterium that if anactivity is disobliged if an alternative activity is per-mitted can be met by restricting permissions or byextending disobligations.

Missing activity conditions: Missing activity con-ditions are set to “false”.

We note that the presented options for auto-correction and completion cannot be arbitrarily com-bined since also the interplay of the various consis-tency criteria has to be taken into account.

Figure 17 summarizes auto-correction and auto-completion rules for a particular choice of the possi-ble options identified above. They determine underwhich conditions an activity a of an abstract subclasso with superclass o is permitted (P a

o ), forbidden (F ao ),

obliged (Oao), and disobliged (Da

o ) based on positivepreconditions (+ao), negative preconditions (−ao),and activation conditions ( ao) specified for activitya at subclass o and based on the permission (P a

o ),prohibition (F a

o ), obligation (Oao), and disobligation

(Dao ) determined previously for the activity at super-

class (o). For simplicity, the shown auto-correctionand completion rules assume single inheritance: Eachclass has at most one superclass; if a class has a super-class it inherits all activities from the superclass andmay introduce additional activities. The case of mul-tiple inheritance can be handled by considering theunion of the conditions inherited from superclasses.Further, we assume that each activity a belongs to asingle set of alternative activities A.

The first rule in Figure 17 extends the notions ofpermission, prohibition, obligation, and disobligationfor an activity a that is introduced at subclass o, i.e.,does not belong to superclass o, to o such that forevery activity of a class these conditions are definedalso at the superclass, which simplifies the notationof auto-correction and auto-completion rules. F a

o andDa

o are set according to the criteria no. 3 and 4 of


12

inter-activity consistency: Activity a is forbidden forthe case that an alternative activity is obliged andactivity a is disobliged for the case that an alternativeactivity is permitted.

The auto-correction rules fix several kinds of con-flicts in one step: Interactivity conflicts between pro-hibition and permission (criterium no. 1 of Fig-ure 7), whereby prohibition takes dominance; super-subclass intra-activity conflicts (criterium no. 2 ofFigure 12), whereby according to the decision-scopeapproach conditions at the superclass are dominant;and inter-activity conflicts with regard to obligations,whereby obligation is restricted to cases in which noalternative activity is permitted or obliged. Note:The auto-correction rules are defined in a situationin which inter-activity conflicts between obligationsand permissions have not been yet resolved (whichwill be done thereafter by auto-completion) such thatthe rules need to refer to prohibitions and positiveactivation-conditions.

The rationale behind the auto-completion rules isthat designers can specify business rules in the samesimple way as we presented them in Figures 9, 13, and14. Thereby we assumed that (1) an activity is per-mitted if it is obliged, (2) an activity is forbidden if analternative activity is obliged, and (3) an activity isdisobliged if it is forbidden or if an alternative activ-ity is permitted. Further, according to the decision-scope approach activity conditions at the subclass areextended by the corresponding activity conditions atthe superclass (criterium no. 1 of Figure 12).

For classes without super classes, auto-completionand auto-correction is subject to the same ruleswhereby all conditions that refer to the superclass areto be substituted by “false”. For concrete classes, thedecision scope for permissions and prohibition needsto be closed by extending for each activity its permis-sion to the complement of its prohibition, its obliga-tion to the conjunction of the prohibitions of alterna-tive activities, and its disobligations to the comple-ment of its obligation.

1. For activity a ∈ A, a introduced at o:

(a) P ao = false

(b) Oao = false

(c) F ao =

∨b∈A:b=a O

bo

(d) Dao =

∨b∈A:b=a P

bo

2. Auto-Correction

(a) F ao = −ao ∧ ¬P a

o

(b) P ao = (+ao ∧ ¬F a

o ) ∧ ¬F ao

(c) ao = ( ao ∧ ¬F ao ) ∧ ¬Da

o

Oao = ao ∧ ¬∨b∈A:b=a( bo ∨ P b

o )

3. Auto-Completion

(a) Oao = Oa

o ∨Oao

(b) P ao = P a

o ∨ P ao ∨Oa

o

(c) F ao = F a

o ∨ F ao ∨

∨b∈A:b =a O

bo

(d) Dao = F a

o ∨∨

b∈A:b=a Pbo

Figure 17: Auto-Completion and Auto-Correction:Abstract subclass o, superclass o, set of alternativeactivities A of o that includes a

Example 10. Figure 18 shows business processMORTGAGE LOAN, a concrete business process special-izing business process LOAN of Figure 10, but incom-pletely and incorrectly defined. The introduced auto-completion and auto-correction rules produce the per-missions, prohibitions, and obligations as expressedby the the activity conditions +, −, and shown forbusiness process MORTGAGE LOAN in Figure 16. Dis-obligations (not shown) are the complement of obli-gations.

Forward to

Board

Reject Loan

Grant Loan

0.7l < a w < 3)

0.7l a w < 2)

0.7l < a w 7 a 40)

0.7l a w 2 a 40)

Mortgage Loan

0.7l < a w 7)

(0.7l a w 2 a < 40)

0.7l < a w < 7

Figure 18: Business process MORTGAGE LOAN, par-tially specified in extended BPMN

3.4 Discretionary Choice

We have treated activation conditions of an activityas obligations in the previous subsection and reasonedthat if an activity is obliged all alternative activi-ties are forbidden. This is a meaningful assumptionfor modeling under which conditions an activity ofa business process may, must not be, or needs to beinvoked. In the case of service use, the situation is dif-ferent. The user of a service may by discretion chooseto select automatically (i.e., without human agent in-volvement) one of several permitted alternative ac-tivities. Such a discretionary choice trigger, however,does not imply that alternative activities in the usedbusiness process are forbidden in general. For servicecompatibility[17] it is only required that (1) choiceimplies permission, (2) a particular choice at a super-class implies the same choice at a subclass, and (3)choices are exclusive (in case of decision points be-tween exclusive activities, which we consider herein),see: Figure 19. Discretionary choice conditions maybe annotated to sequence flow in BPMN as anotherkind of condition.

1. Choice implies permission:Ca

o → P ao

2. Generalization:o is superclass of o: Ca

o → Cao

3. Exclusive choice:a ∈ A, b ∈ A, a = b : Ca

o → ¬Cbo

Figure 19: Criteria for Discretionary Choice

Example 11. A discretionary choice condition maydefine that a loan application is automatically for-warded to the board if the loan amount is high andthe credit rating is average ((w ≥ 3∧w < 5)∧a ≥ 40),


13

which is permitted (cf. Figure 4). This choice con-dition may be extended for mortgage loan, e.g., to((w ≥ 3 ∧ w < 5) ∧ (a ≥ 40) ∨ (a ≥ 40 ∧ 0.7l < a)),which is permitted for mortgage loans (cf. Figure 14).Note: The annotation of discretionary choice condi-tions is not shown in Figures 10 and 16.

Ways to auto-complete and auto-correct discre-tionary choice conditions are: (1) to restrict choiceto permission, (2) to extend choice by the respectiveconditions of superclasses , and (3) to resolve conflictsin case multiple choice conditions overlap by (a) usingpriorities for activities, (b) by using a default masteractivity, or (c) by restricting each choice condition tonon-overlapping parts.

3.5 Weak and Strong Business Rules

Specialization and the decision-scope approach as in-troduced are inherently monotonic as any potentialconflict of rules is resolved by precedence of rules at asuperclass over those at a subclass. In case the samerules apply for all subclasses apart from a few excep-tions, monotonicity requires to restructure the classhierarchy or to redundantly define the same set ofrules at several subclasses. Non-monotonic defaultrules may be a reasonable design alternative, pro-viding such they are used in limited cases and areidentified as such. In the legal context at which welooked for guidance to the decision-scope approach,lower level provisions may override higher-level pro-visions in identified cases (e.g., general world-widesales conditions may state that warranty is for oneyear only, unless local consumer law prescribes oth-erwise). An approach for supporting monotonic andnon-monotonic rules together has been developed inthe context of authorization rules in database systemsby introducing weak and strong authorization rules.We carry this idea over to the specialization of busi-ness rules in general.

Strong business rules are handled as described sofar. Weak business rules may be overridden or can-celed partially or fully at subclasses. In case of con-flict between a strong and a weak business rule, thestrong business rule takes precedence.

Strong and weak business rules come in positiveand negative from. A weak positive rule of a super-class may be overridden by a different weak positiverule at the subclass or canceled by a negative (strongor weak) rule at the subclass. Whether overridingor cancelation is chosen will depend on the extent ofdifference to the superclass: A major deviation fromthe superclass will usually be handled by indicatinga different weak positive rule at the subclass, a mi-nor deviation by a negative rule. Whether a strongor weak negative rule is used depends on whether therule may again be overridden or canceled at a subclassor not. Complementary, a weak negative rule at thesuperclass may be overridden by another weak nega-tive rule at the subclass or be canceled by a positive(strong or weak) rule at the subclass.

The notions of strong and weak could be conceptu-ally used for preconditions (positive or negative) andactivation conditions (positive or negative) for activ-ities. In practice, we have (so far) only encountereduse cases for strong and weak activation conditions.

Example 12. Figure 20 visualizes the same businessrules as Figure 9 but extended with a weak activationcondition ( f) to forward a loan application to theboard in case the credit worthiness is relatively highand the loan amount is not very low.

60

40

30

20

10

50

0 64321 5 7 8 9

amountin k$

creditworthiness

j

!g f f

g

!j

f~

Figure 20: Business process LOAN: Weak and StrongBusiness Rules

Oao =

{ ao ∧ ¬Da

o if ao is defined

false otherwise

Dao =

{− a

o ∧ ¬Oao if − a

o is definedfalse otherwise

Figure 21: Weak Activation Conditions: Cancelation,class o without superclass

Figures 21 and 22 summarize the interplay be-tween strong and weak activation conditions, nega-tive and positive. The figures show how weak obliga-tions and weak disobligations for invoking an activitya of class o without a superclass or with superclass o,resp., are derived from activation conditions (weak orstrong, positive or negative) and have to be read inconjunction with Figure 17.

Example 13. Figure 23 shows a negative strong ac-tivation condition (− f) for activity forward of classLOAN canceling partially the inherited positive weakactivation condition for a rather low loan amountin case the detachable income i is lower than themonthly rate r and the loan amount is below 30k. Italso visualizes the resulting weak obligation to invokeactivity forward for a private loan (Of).

In semi-automatic decision making, an activity awill be automatically invoked for a business case ofconcrete class o, if it is strongly obliged or if it ispermitted and weakly obliged.

Oao =

{ ao ∧ ¬Da

o if ao is defined

Oao ∧ ¬(Da

o ∨ Dao ) if a

o not defined

Dao =

{− a

o ∧ ¬Oao if − a

o is defined

Dao ∧ ¬(Oa

o ∨ Oao) if − a

o not defined

Figure 22: Weak Activation Conditions: Overridingand Cancelation, subclass o, superclass o


14

60

40

30

20

10

50

64321 5 7 8 9

amountin k$

creditworthiness

j f

g

i r

! f

Of~

!f!j

!g

Figure 23: Business process PRIVATE-LOAN: Weak andStrong Business Rules

4 Analysis Rules in Data Warehousing

In this section we describe how the decision-scope ap-proach can be applied in data warehousing. Businessrules in the context of data warehousing usually rep-resent actionable knowledge on how to react on thepresence or absence of (base or aggregated) facts in adata warehouse. We call such kinds of business rulesanalysis rules. They are used in active data ware-housing for semi-automatic decision making, provid-ing a feedback loop to transactional database systemsin that rule actions are transactions in transactiondatabases. Analysis rules are useful as well in com-parative data analysis where they guide users duringan analysis process, provide judgements or alert man-agers upon detection of interesting comparative situ-ations (which are given through the comparison of afact group of interest vs. a fact group of compari-son). For simplicity, we introduce the decision-scopeapproach for non-comparative situations.

4.1 Data Warehouses and Classes of Facts

A data warehouse consist of a set of facts and a setof dimensions. Each dimension consists of a leveledhierarchy of roll-up nodes. For simplicity we assumea linear hierarchy to explain the decision-scope ap-proach: (1) The roll-up hierarchy of nodes is a tree,(2) Each node belongs to a level, (3) All leaf nodesbelong to the same level, (4) Any two nodes of thesame level roll-up to nodes of a common level. Theset of facts, usually referred to as cube, consists ofmulti-dimensional points, whose coordinates are leafnodes of the dimensions, and a set of measure val-ues. We refer to the levels of the coordinates of amulti-dimensional point as granularity.

Example 14. Figure 24 depicts the schema of a sim-ple data warehouse with dimensions PRODUCT, LOCA-TION, and TIME and cube SALES&LOSSES with mea-sures loss and sold. The figure shows also samplenodes of dimension PRODUCT: nodes milk and creamat level Product, nodes longLife and shortLife at levelProductCategory, and node food at level ProductLine.

Base facts (whose point coordinates are at the bot-tom granularity) roll-up to aggregated facts (or roll-up facts). In this fashion the measure of an aggre-gated fact is derived from the base facts that roll-upto the aggregated fact, i.e, whose coordinates directlyor indirectly roll-up to coordinates of the aggregatedfact. From here on, we simply speak of “a point (or

PRODUCT

allAllProduct

Product

Line

P d t

food

Product

Category

Product

long life short life

milk cream

……

cream

SALES & LOSS

loss

sale

State

AllLoc

City

all

AustriaGermany

Vienna

Month

Year

Day

2012

12/2012

2011

12/12/2012… …

…

AllLoc

LOCATION

all Year

TIME

2012 2011

AllTimeall

Figure 24: Data Warehouse Schema SALES&LOSS

fact) rolls-up to another point (or fact)”, when thepoint (or fact) directly or indirectly rolls-up to theother point (or fact). In top-down analysis, drill-downrefers to the inverse of roll-up.

Example 15. Fact (Milk,Vienna,28-11-2012,5,20) rolls upto fact (shortLife,Austria,2012,8,27).

For applying the decision-scope approach to spe-cialization of analysis rules, we consider a fact as ob-ject and the set of facts of a particular granularity(given by a level for each dimension) as a class. Fur-thermore, we can consider the class of facts of par-ticular granularity G that roll-up to a given multi-dimensional point p, denoted as p[G]. In this nota-tion the class of facts at a particular granularity Gis the set of facts that roll-up to the root point r,consisting of the all-node from each dimension, r[G].For brevity, a coordinate of a point or a level of agranularity is omitted if the coordinate is the rootnode of the dimension or the level is the root level,respectively. If a point p rolls-up to q, then p[G] is asubclass of q[G]. While class hierarchies with multipleinheritance can be constructed this way, we introducethe principles of the decision-scope approach in datawarehousing for single inheritance. An extension tomultiple inheritance requires to check the introducedconsistency criteria for each superclass and it requiresas well to apply the introduced auto-correction andauto-completion rules for each superclass.

Example 16. Class (food,Austria,2012) [ProductCate-gory,City,Year] could for example contain roll-up fact(shortlife,Vienna,2012,7,17).

4.2 Mono-granular Analysis Rules

We can apply the decision-scope approach as intro-duced for action rules defined over classes of businessprocesses in the same way to analysis rules definedover classes of data warehouse facts if we consideronly analysis rules that are defined over classes offacts of the same granularity. We call such analysisrules mono-granular.

Analysis rules are associated with a class of factsand determine, based on conditions over facts of theclass, whether an action should be invoked or not.Thus, analysis rules specify a positive or negative ac-tivation condition, strong or weak. In most data ware-house settings initiated actions are always permitted


15

such that negative and positive preconditions of ac-tions need not to be modeled (but this could be doneas well if needed the same way as introduced for busi-ness processes).

Analysis rules are usually checked for a subset offacts for which they are defined based on external orapplication events. E.g., an informative action maybe initiated at the end of a temporal period (monthor year) after evaluating facts of this period once theyhave been loaded into the data warehouse, or a guid-ance action (suggesting further analysis steps) may beinitiated for facts that are part of a current analysissituation (consisting of a set of facts selected in thecurrent analysis step of an analysis session [31]).

Specialization along subset relationships betweenpoints at the same granularity is governed by the sameset of rules as specialization between superclasses andsubclasses of objects.

Example 17. Figure 25 depicts the conditions underwhich a particular Product is to be de-listed ( ) or notto be de-listed (− ) in a particular State dependenton the percentage of the loss-to-sold ratio (l/s). Theanalysis rules are specified for product line food andspecialized for product categories shortLife and longLife.

class delist − delist

(food) [Product,State] l/s ≥ 40 l/s < 10(longLife) [Product,State] l/s ≥ 15 l/s < 10(shortLife) [Product,State] l/s ≥ 40 l/s < 20

Figure 25: Mono-Granular Analysis Rules: Delist

4.3 Multi-Granular Rules: Prerogative Eval-uation

In addition to the subset relationship between set ofpoints at the same granularity, the roll-up hierarchyof points in multi-dimensional space can be used toevaluate analysis rules for the same action along drill-down relationships (the inverse to roll-up). One pos-sible evaluation strategy is the prerogative evaluationstrategy in which an action triggered for a higher levelpoint implicitly implies the same action for each drill-down point. We have applied this principle in similarform for active data warehousing in the past [38, 39].An alternative evaluation strategy will be presentedin the subsequent subsection.

In the prerogative evaluation strategy, analysisrules for the same action are evaluated top-down. Weassume at first that for one granularity at most oneanalysis rule is defined by a condition pair, consist-ing of a positive and negative activation condition.If one of the two condition applies for a roll-up fact,analysis is completed, whereby the indicated action istriggered if the positive activation condition is satis-fied. Only if both conditions are not satisfied, i.e., forthe situation that a fact falls into the open space ofthe condition scope, the analysis rules for drill-downgranularities and drill-down facts at these granulari-ties are considered in further rule evaluation.

Prerogative evaluation of analysis rules along roll-up hierarchies in top-down manner can be combinedwith evaluation along class hierarchies of points at thesame granularity as described in the previous subsec-tion. At each granularity all analysis rules defined forclasses of points at that granularity are considered,and for each fact the most specific class is chosen.For simplicity we assume here that the class hierar-chy of points has been defined such that each factfalls into a single most-specific class. Once a decision

has been determined for a fact at a given granularity,analysis stops; if no decision could be made due toan open decision scope, analysis continues with drill-down facts at a lower granularity for which an analysisrule is defined. Again, we assume herein for simplicitythat the hierarchy of granularities for which analysisrules for a given action are defined is a tree. Theapproach for message-to-method binding introducedfor multiple inheritance of cooperation contracts [33],which define methods that are polymorphic in multi-ple receivers, can be carried over in order to extendthe presented approach for the case of multiple inher-itance.

Example 18. Figure 26 defines analysis rulesat the granularity of (Product,State) and atthe lower granularity of (Product,City) for actiondelist(PRODUCT,LOCATION). Figure 27 shows samplefacts and for each fact whether action delist is triggedfor the fact in the multi-granular evaluation strategy.

The analysis rule for (shortLife) [Product,State] isthe most specific rule for roll-up fact (milk,Austria,20)but does not apply, neither positively nor negatively.Therefore, the analysis rules for action delist areevaluated for drill-down facts and the analysis rulespecified for (shortLife) [Product,City] triggers for fact(milk,Vienna,48), de-listing milk in Vienna.

Analysis rule (shortLife) [Product,State] applies toroll-up fact (cream,Austria,20) de-listing cream in Austriawhich implicitly implies that cream is no longer soldin every city in Austria. Therefore, analysis is com-pleted and no longer checked for drill-down facts suchas (cream,Vienna,15).

class delist − delist


(food) [Product,City] l/s ≥ 45 l/s < 10(longLife) [Product,City] l/s ≥ 25 l/s < 10(shortLife) [Product,City] l/s ≥ 45 l/s < 20

Figure 26: Multi-Granular Analysis Rules: Delist

point l/s % delist

(milk,Austria) 20(cream,Austria) 50 (milk,Vienna) 48 (cream,Salzburg) 52(cream,Vienna) 15

Figure 27: Multi-Granular Prerogative Evaluation onSample Facts

4.4 Multi-Granular Rules: Presumed Evalu-ation

An alternative evaluation strategy to the prerogativestrategy is the presumed evaluation strategy. In thepresumed strategy an action (typically an informativeone) is not triggered again for drill-down facts to avoidinformation load, unless it is justified by a negativeactivation condition.

Example 19. Figure 28 defines analysis rulesat the granularity of (Product,State) and atthe lower granularity of (Product,City) for actionalertMg(PRODUCT,LOCATION) . Figure 29 shows samplefacts and for each fact lists whether action alertMg istriggered for the fact in the multi-granular evaluationstrategy.


16

The analysis rule for (shortLife) [Product,State] isthe most specific rule for roll-up fact (milk,Austria,20)but does not apply, neither positively nor negatively.Therefore, the analysis rules for action delist areevaluated for drill-down facts and the analysis rulespecified for (shortLife) [Product,City] triggers for fact(milk,Vienna,48) alerting the manager for milk in Vienna.

The analysis rule (shortLife) [Product,State] applies toroll-up fact (cream,Austria,20) alerting the manager forcream in Austria, with the alert presumed to include alldrill-down facts. This avoids raising an alert for everycity in Austria and shields the manager from informa-tion overload, since presumably if the aggregated facthas a strikingly unusual measure value, so will usu-ally the drill-down facts from which the aggregatedmeasure is computed, e.g. fact (cream,Salzburg,52). Butdifferent to prerogative evaluation, an exception is re-ported if the alert should not have been raised due toa negative activation condition for a drill-down fact(e.g., for drill-down fact (cream,Vienna,15)). An excep-tion alert will be raised in such a case.

class alertMg − alertMg


(food) [Product,City] l/s ≥ 45 l/s < 10(longLife) [Product,City] l/s ≥ 25 l/s < 10(shortLife) [Product,City] l/s ≥ 45 l/s < 20

Figure 28: Multi-Granular Analysis Rules: Alert-Manager

point l/s % alertMgr

(milk,Austria) 20(cream,Austria) 50 (milk,Vienna) 48 (cream,Salzburg) 52(cream,Vienna) 15 −

Figure 29: Multi-Granular Presumed Evaluation onSample Facts

5 Conclusion

In this paper we have outlined the general princi-ples of the decision-scope approach to specializationof business rules. We have shown that the decision-scope approach used by law hierarchies and hierar-chical organizations for decision making along hierar-chies of laws or organizational levels can be benefi-cially applied to the specialization of business rules.We have presented a set of consistency criteria thatgovern the decision-scope approach and introducedauto-correction rules to adjust inconsistent businessrules in that conflicts are resolved in favor of the su-perclass, like in the real world a higher-level authorityoverrules a lower-level.

In particular, we have exemplified how thedecision-scope approach can be incorporated intobusiness process modeling and how it can be used incapturing actionable knowledge in data warehousing.We currently work in the SemCockpit [32] project onemploying the decision scope approach for specializa-tion of guidance and judgment rules in the context ofcomparative data analysis in business intelligence.

References

[1] The Business Rules Manifesto– the Business Rules Group,http://www.businessrulesgroup.org/, 2006.

[2] Semantics of Business Vocabularyand Business Rules(SBVR), v1.0,http://www.omg.org/spec/SBVR/1.0/PDF.Technical report, January 2008.

[3] Jurgen Angele, Michael Kifer, and Georg Lausen.Ontologies in F-Logic. In Steffen Staab and RudiStuder, editors, Handbook on Ontologies, In-ternational Handbooks on Information Systems,pages 45–70. Springer Berlin Heidelberg, 2009.

[4] Franz Baader, Ian Horrocks, and Ulrike Sattler.Description logics. In Steffen Staab and RudiStuder, editors, Handbook on Ontologies, In-ternational Handbooks on Information Systems,pages 21–43. Springer Berlin Heidelberg, 2009.

[5] Twan Basten and Wil M. van der Aalst. Inheri-tance of behavior. Journal of Logic and AlgebraicProgramming, 47(2):47–145, 2001.

[6] Elisa Bertino, Giovanna Guerrini, and IsabellaMerlo. Trigger inheritance and overriding inan active object database system. IEEE Trans.Knowl. Data Eng., 12(4):588–608, 2000.

[7] Elisa Bertino, Sushil Jajodia, and PierangelaSamarati. A flexible authorization mechanismfor relational data management systems. ACMTrans. Inf. Syst., 17(2):101–140, 1999.

[8] Peter Bichler and Michael Schrefl. Inheritance ofbusiness rules. In Grundlagen von Datenbanken,pages 20–24, 1995.

[9] Graham M. Birtwistle, Ole-Johan Dahl, BjørnMyrhaug, and Kristen Nygaard. Simula BEGIN.Auerbach/Studentlitteratur, 1974.

[10] Alexander Borgida, John Mylopoulos, and HarryK. T. Wong. Generalization/specialization as abasis for software specification. In M. L. Brodie,J. Mylopoulos, and Schmidt J. W., editors, OnConceptual Modelling, Perspectives from Artifi-cial Intelligence, Databases, and ProgrammingLanguages. Springer, 1984.

[11] Ronald J. Brachman. What is-a is and isn’t: Ananalysis of taxonomic links in semantic networks.IEEE Computer, 16(10):30–36, 1983.

[12] Christoph Bussler. Public process inheritance forbusiness-to-business integration. In Proceedingsof the Third International Workshop on Tech-nologies for E-Services, TES ’02, pages 19–28,London, UK, UK, 2002. Springer-Verlag.

[13] Fabian Buttner and Martin Gogolla. On gen-eralization and overriding in UML 2.0. InUML 2004 Modeling Languages and Applica-tions. UML 2004 Satellite Activities. Springer,2004.

[14] Luca Cardelli. A semantics of multiple inheri-tance. Inf. Comput., 76(2/3):138–164, 1988.

[15] Giuseppe Castagna. Covariance and contravari-ance: Conflict without a cause. ACM Trans.Program. Lang. Syst., 17(3):431–447, 1995.


17

[16] Roland Ducournau. “Real World” as an argu-ment for covariant specialization in programmingand modeling. In OOIS Workshops, pages 3–12,2002.

[17] Georg Grossmann, Michael Schrefl, and MarkusStumptner. Design for service compatibility –behavioural compatibility checking and diagno-sis. Software and Systems Modeling, 2012, DOI10.1007/s10270-012-0229-0.

[18] O. M. G. Group. UML Specification, Version 2.0,2006.

[19] Thomas R. Gruber. A translation approach toportable ontology specifications. Knowledge Ac-quisition, 5(2):199–220, 1993.

[20] Thomas R. Gruber. Toward principles for thedesign of ontologies used for knowledge shar-ing. Int. J. Hum.-Comput. Stud., 43(5-6):907–928, 1995.

[21] Holger Herbst, Gerhard Knolmayer, ThomasMyrach, and Markus Schlesinger. The specifi-cation of business rules: A comparison of se-lected methodologies. In Proceedings of the IFIPWG8.1 Working Conference on Methods and As-sociated Tools for the Information Systems LifeCycle, pages 29–46, New York, NY, USA, 1994.Elsevier Science Inc.

[22] Richard Hull. Artifact-centric business pro-cess models: Brief survey of research resultsand challenges. In OTM Conferences (2),LNCS 5332, pages 1152–1163, Monterrey, Mex-ico, 2008. Springer.

[23] Walter L. Hursch. Should superclasses be ab-stract? In Proceedings of the 8th Euro-pean Conference on Object-Oriented Program-ming, ECOOP ’94, pages 12–31, London, UK,UK, 1994. Springer-Verlag.

[24] Gerti Kappel and Michael Schrefl. Ob-ject/Behavior Diagrams. In ICDE, pages 530–539, 1991.

[25] Gerti Kappel and Michael Schrefl. Modelling ob-ject behavior: To use methods or rules or both?In DEXA, pages 584–602, 1996.

[26] Peter Kueng and Michael Schrefl. Spezialisierungvon Geschaftsprozessen am Beispiel der Bear-beitung von Kreditantragen. HMD - PraxisWirtschaftsinform., 185, 1995.

[27] Peter Lang, Werner Obermair, and MichaelSchrefl. Modeling business rules with situa-tion/activation diagrams. In ICDE, pages 455–464, 1997.

[28] Barbara Liskov and Jeannette M. Wing. A be-havioral notion of subtyping. ACM Trans. Pro-gram. Lang. Syst., 16(6):1811–1841, 1994.

[29] Milan Milanovic, Dragan Gasevic, and LuisRocha. Modeling Flexible Business Processeswith Business Rule Patterns. In EDOC, pages65–74. IEEE Computer Society, 2011.

[30] Mukesh K. Mohania, Ullas Nambiar, MichaelSchrefl, and Millist W. Vincent. Active andreal-time data warehousing. In Encyclopedia ofDatabase Systems, pages 21–26. 2009.

[31] Thomas Neubock, Bernd Neumayr, ThomasRossgatterer, Stefan Anderlik, and MichaelSchrefl. Multi-dimensional navigation model-ing using BI Analysis Graphs. In Silvana Cas-tano, Panos Vassiliadis, Laks V. Lakshmanan,and Mong-Li Lee, editors, ER Workshops, vol-ume 7518 of Lecture Notes in Computer Science,pages 162–171. Springer, 2012.

[32] Bernd Neumayr, Michael Schrefl, and KonradLinner. Semantic Cockpit: An ontology-driven,interactive business intelligence tool for compar-ative data analysis. In ER Workshops, pages 55–64, 2011.

[33] Michael Schrefl, Gerti Kappel, and Peter Lang.Modeling collaborative behavior using coopera-tion contracts. Data Knowl. Eng., 26(2):191–224, 1998.

[34] Michael Schrefl and Markus Stumptner.Behavior-consistent specialization of object lifecycles. ACM Trans. Softw. Eng. Methodol.,11(1):92–148, 2002.

[35] B. Silver. BPMN Method and Style, 2nd Edition,with BPMN Implementer’s Guide: A StructuredApproach for Business Process Modeling and Im-plementation Using BPMN 2.0. Cody-CassidyPress, 2011.

[36] John Miles Smith and Diane C. P. Smith.Database abstractions: Aggregation and gener-alization. ACM Trans. Database Syst., 2(2):105–133, 1977.

[37] Markus Stumptner and Michael Schrefl. Con-figuring loopholes: Interactive consistency main-tenance of business rules. In Configuration –Papers from the Configuration Workshop at the19th International Joint conference on ArtificialIntelligence (IJCAI 2005), pages 37–39, 2005.

[38] Thomas Thalhammer and Michael Schrefl. Re-alizing active data warehouses with off-the-shelfdatabase technology. Softw., Pract. Exper.,32(12):1193–1222, 2002.

[39] Thomas Thalhammer, Michael Schrefl, andMukesh K. Mohania. Active data warehouses:complementing OLAP with analysis rules. DataKnowl. Eng., 39(3):241–269, 2001.

[40] W.M.P. van der Aalst. Inheritance of dynamicbehavior in UML. In Proceedings of the SecondWorkshop on Modelling of Objects, Componentsand Agents (MOCA 2002), pages 105–120, 2002.

[41] R.J. Wieringa, H. Weigand, J.-J.Ch. Meyer, andF.P.M. Dignum. The inheritance of dynamic anddeontic integrity constraints or: Does the bosshave more rights? Annals of Mathematics andArtificial Intelligence, 3(2-4):393–428, 1991.


18

Documents

The Decision-Scope Approach to Specialization of …crpit.com/confpapers/CRPITV143Schrefl.pdfThe Decision-Scope Approach to Specialization of Business Rules: Application in Business