EM-BrA2CE v0.1: A vocabulary and execution model
for declarative business process modeling
Stijn Goedertier, Raf Haesen and Jan Vanthienen
DEPARTMENT OF DECISION SCIENCES AND INFORMATION MANAGEMENT (KBI)
Faculty of Economics and Applied Economics
KBI 0728
EM-BrA
2
CE v0.1: A Vocabulary and Execution Model for
Declarative Business Process Modeling
Stijn Goedertier
1
, Raf Haesen
1,2
and Jan Vanthienen
1
1
Katholieke Universiteit Leuven,
Department of Decision Sciences & Information Management,
Naamsestraat 69, B-3000 Leuven, Belgium
{stijn.goedertier;raf.haesen;jan.vanthienen}@econ.kuleuven.be
2
Vlekho Business School Brussels, Belgium
Koningsstraat 336, 1000 Brussels, Belgium
raf.haesen@vlekho.wenk.be
Abstract
In management theory of the last decades, much importance has been attached to
a process-oriented perspective on organizational (re)structuring. Yet to date, organi-
zations still experience difficulties in applying this process-oriented perspective to the
design and maintenance information systems. The root of the problem lies with a pro-
cedural representation of business processes that contains inadequate information for
computer systems to provide flexible automated business pro c ess supp ort. The counter-
part of a procedural representation is a declarative one that explicitly takes into account
the business concerns that govern business processes. Recently, a number of process
modeling languages have appeared that could be identified as declarative languages.
These modeling languages have very distinct knowledge representation backgrounds,
often lack a formal execution mo del and often only model one aspect of the many
business concerns that exist in reality. What is needed are meaningful ways to com-
bine several kinds of expressions, called business rule types, independently of the used
methods for knowledge representation and reasoning. In this paper, we present the
EM-BrA
2
CE (Enterprise Modeling using Business Rules, Agents, Activities, Concepts
and Events) Framework, a unifying vocabulary and execution model for declarative
process modeling. The vocabulary is described in terms of the Semantics for Business
Vocabulary and Rules (SBVR) standard and the execution model is presented as a
Colored Petri Net (CP-Net). In addition, we show how declarative process models can
contribute to the model-driven design of Service-Oriented Architectures.
keywords: Business Proce ss Management, Business Modeling, Service Modeling, SBVR,
Service-Oriented Architecture
1
CONTENTS 2
Contents
1 Introduction 3
2 Related work 5
3 Procedural versus Declarative Process Modeling 6
3.1 Business Concerns Made Explicit . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Declarative Business Rule Enforcement . . . . . . . . . . . . . . . . . . . . . 8
3.3 Declarative Communication Logic . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Dynamic Execution Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5 Activity-level Granularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6 Model Differentiation by Modality . . . . . . . . . . . . . . . . . . . . . . . 10
3.7 Assumption bias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.8 Runtime Alteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.9 No Human-Machine Distinction . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.10 Coordination Work is Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.11 Multi-state Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.12 Third-person perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.13 Meaning is Separate from Expression . . . . . . . . . . . . . . . . . . . . . . 12
4 An Introduction to Declarative Process Modeling 13
4.1 Process Model = State Space + Transition Constraints . . . . . . . . . . . . 13
4.2 History-dependent behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Running example: payment-after-shipment . . . . . . . . . . . . . . . . . . 15
5 A Vocabulary for Declarative Process Modeling 16
5.1 Candidate Ontology Language . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2 An Introduction to SBVR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3 The EM-BrA
2
CE Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.1 Business concept – business concept type . . . . . . . . . . . . . . . 22
5.3.2 Activity – activity type . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3.3 State – state space . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.4 Agent – Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.5 Event – event type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3.6 Deontic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3.7 Non-functional, quality-of-service concerns . . . . . . . . . . . . . . . 32
5.3.8 Cost and time concerns . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4 Business Rules in the EM-BrA
2
CE Framework . . . . . . . . . . . . . . . . 34
5.4.1 Providing Logical Foundations for Temporal Rules . . . . . . . . . . 35
5.4.2 Semantic Formulation of Temporal Rules . . . . . . . . . . . . . . . 37
5.4.3 Control-flow: temporal deontic rule . . . . . . . . . . . . . . . . . . . 37
5.4.4 Control-flow: activity precondition . . . . . . . . . . . . . . . . . . . 38
5.4.5 Control-flow: activity p os tcondition . . . . . . . . . . . . . . . . . . 39
5.4.6 Control-flow: reaction rule . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4.7 Control-flow aspect: dynamic integrity constraint . . . . . . . . . . . 40
5.4.8 Control-flow aspect: activity cardinality constraint . . . . . . . . . . 40
5.4.9 Control-flow aspect: serial activity constraint . . . . . . . . . . . . . 41
5.4.10 Control-flow aspect: activity order constraint . . . . . . . . . . . . . 41
5.4.11 Control-flow aspect: activity exclusion constraint . . . . . . . . . . . 41
5.4.12 Control-flow aspect: activity inclusion constraint . . . . . . . . . . . 42
Declarative Process Modeling: A Vocabulary and Execution Model 3
5.4.13 Data aspect: Static integrity constraint . . . . . . . . . . . . . . . . 42
5.4.14 Data aspect: derivation rule . . . . . . . . . . . . . . . . . . . . . . . 42
5.4.15 Organization aspect: activity authorization constraint . . . . . . . . 43
5.4.16 Organization aspect: activity allocation rule . . . . . . . . . . . . . . 43
5.4.17 Organization aspect: visibility constraint . . . . . . . . . . . . . . . 44
5.4.18 Organization aspect: event subscription constraint . . . . . . . . . . 44
6 An Execution Model for Declarative Process Mo del ing 44
6.1 Business Rules in the Activity Life Cycle . . . . . . . . . . . . . . . . . . . 44
6.2 A CP-Net-based Execution Model . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.1 Places and Color Sets . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.2 The Create transition . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.3 The Schedule transition . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.4 The Assign and Revoke transition . . . . . . . . . . . . . . . . . . . 54
6.2.5 The Start transition . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.6 The fact manipulation transitions . . . . . . . . . . . . . . . . . . . . 55
6.2.7 The Complete transition . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.8 The Abort, Skip and Redo transitions . . . . . . . . . . . . . . . . . 59
6.3 Unspecified semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.3.1 Reactive Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.3.2 Transaction Handling . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.3.3 Composite State Transitions . . . . . . . . . . . . . . . . . . . . . . 63
7 Towards a Declarative Service-Oriented Architecture 63
8 Evaluation of the EM-BrA
2
CE Framework 66
9 Conclusion 67
1 Introduction
In management theory of the last decades, much importance has been attached to a process-
oriented perspective on organizational (re)structuring. Porter (1985), for instance, intro-
duced the idea of the value chain to better understand the activities through which com-
panies gain a competitive advantage. Kaplan (1998) drew attention to the technique of
Activity-Based Costing. Davenport (1993) and Hammer and Champy (1993) coined the
terms process innovation and business (process) reengineering (BPR). Processes also have
a prominent place within the movement of continuous quality improvement. Six Sigma,
for instance, has a measurement-driven methodology both to reduce variability in existing
process designs and to create new process designs (Motorola Inc., 1986; Ehrlich, 2002).
Yet to date, organizations still experience difficulties in applying this process-oriented
perspective to the design and maintenance information systems. Process-aware informa-
tion systems (PAIS) (Dumas et al., 2005) provide automated support for the business
processes of an organization by partially automating the (coordination) work. According
to zur Muehlen (2004), the first process-aware information systems s tarted to appear in
the 1980s out of document management systems, e-mail systems and database management
systems. Nonetheless, data management, not process management, demanded most of the
attention in the 1980s. Real interest for automated business process support arose in the
1990s with the advent of new communication standards and new IT infrastructures. In
an attempt to integrate disparate modules, ERP vendors started to adopt capabilities for
Declarative Process Modeling: A Vocabulary and Execution Model 4
automated process support. At the same time a comparable effort was undertaken by Enter-
prise Application Integration (EAI) tool vendors, developing process-oriented mechanisms
for application interoperability. In spite of these evolutions, process-aware information sys-
tems are sometimes far from the business requirements of efficiency, effectiveness, flexibility
and compliance. For instance, information systems have at first sight made the business
processes of organizations more compliant. By automating the coordination of work, or-
ganizations have better control over the actions of involved actors. Moreover, automated
processes can help organizations in demonstrating business process compliance to all stake-
holders. However, the downside is that automated business processes are often inflexible.
In particular, automated processes have proved to be difficult to adapt at design time where
each changed requirement triggers a lengthy development cycle in which it is impossible to
identify and include all control and correction steps a priori (Heinl et al., 1999). Moreover,
at run time, automated processes are often found too rigid to deal with the contingencies
of real-life situations (Sadiq et al., 2005).
The root of the problem lies with a procedural representation of business processes that
provides computer systems with inadequate information to deal with the idiosyncracies of
every-day situations. In general, one can think of, among other, the following business
concerns to play a governing role in the organization of work:
• Business regulations: externally imp ose d directives such as among others legal
requirements, standards and contracts.
• Business policies: internally defined directives involving among others business
strategies, tactics and operational procedures.
• Costs and benefits: the incurred benefits and costs of an activity.
• Lead time: the overall time to enact a process.
• Information prerequisites: the information required to enact a process.
• Technical and common-sense constraints
Organizations often only implicitly think about these business c oncerns when they design
business processes but pay little attention to documenting why specific design choices have
been m ade. Instead of making these business concerns explicit, they are implicitly used to
determine task control flows, information flows and work allocation schemes. In other words
these aspects remain implicit but their effects are – so to speak – hard-coded directly in
procedural process models.
The counterpart of a procedural representation is a declarative one. A process model
is declarative when it explicitly takes into account the business concerns that govern a
business process leaving as much freedom as is permissible at execution time for determining
a valid and suitable execution plan. Recently, a number of process modeling languages have
appeared that could be identified as declarative languages. These modeling languages have
very distinct knowledge representation backgrounds, often lack a formal execution model
and often only model one aspect of the many business concerns that exist in reality. What
is needed are meaningful ways to combine several kinds of expressions, called business
rule types, independently of the used methods for knowledge representation and reasoning.
In this paper, we show how the business concerns that govern business processes can be
modeled declaratively.
The paper is structured as follows. In section 2 we introduce some languages for declar-
ative proce ss modeling that exist in the literature. In section 3 we contrast declarative and
