Declarative Process Modeling with Business Vocabulary and

Declarative Process Modeling with Business Vocabulary and Business Rules Stijn Goedertier and Jan Vanthienen Department of Decision Sciences & Information Management, Katholieke Universiteit Leuven, Belgium (stijn.goedertier,jan.vanthienen)@econ.kuleuven.be

Abstract. A process modeling language is declarative when it explicitly takes into account the business concerns that govern business processes. In this paper, we show how business concerns can be modeled declaratively using a fact-oriented business vocabulary that allows to express sixteen different business rule types. In particular, we present the EMBrA2 CE Framework, an extension of the SBVR that allows for declarative process modeling. Keywords: fact-oriented modeling, workflow modeling, SBVR.

1

Introduction

In general, one can think of the following business concerns to play a governing role in the organization of work: – – – – – –

Business regulations: external directives: laws and contracts. Business policies: internal directives; strategies and procedures. Costs and benefits: the incurred benefits and costs of an activity. Time: the overall time to process an activity. Information prerequisites: the information required to start an activity. Technical and common-sense constraints

Organizations often only implicitly think about these business concerns when they design business processes but pay little attention to documenting why specific design choices have been made. 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 hard-coded directly in procedural process models. In this paper, we show how the business concerns that govern business processes can be modeled declaratively using a fact-oriented business vocabulary that allows to express business rules. The paper is structured as follows. In section 2 we contrast declarative and procedural process modeling. In section 3 we give a vocabulary for declarative process modeling, called the EM-BrA2 CE Vocabulary. This vocabulary is an extension of the SBVR and allows to declaratively refer to the state of a business process. In section 4 we identify a number R. Meersman, Z. Tari, P. Herrero et al. (Eds.): OTM 2007 Ws, Part I, LNCS 4805, pp. 603–612, 2007. c Springer-Verlag Berlin Heidelberg 2007

604

S. Goedertier and J. Vanthienen

of business rule types that use this vocabulary to describe the state transition constraints of declarative process models. Finally, in section 5 we relate the EMBA2 CE Framework to the relevant literature.

2

Procedural versus Declarative Process Modeling

A business process model is called procedural when it contains explicit information about how processes should proceed, but only implicitly keeps track of why these design choices have been made. Procedural process models are modeled with procedural languages such as the Business Process Execution Language (BPEL) [1], the Business Process Modeling Notation (BPMN) [2] and UML Activity Diagrams [3]. The counterpart of a procedural process model is a declarative one. Process modeling is said to have a declarative nature, when it explicitly takes into account the business concerns that govern business processes and leaves as much freedom as is permissible at execution time for determining a valid and suitable execution scenario. Table 1 summarizes the differences between procedural and declarative process modeling. These differences are discussed in the subsequent paragraphs. Table 1. Procedural versus declarative process modeling Procedural modeling

Declarative modeling

Business concerns implicit explicit Execution scenario explicit implicit Execution mechanism state-driven goal-driven Modality what must what must, ought, can Rule enforcement procedural (what, when, how) declarative (what) Communication explicit (how) implicit (what)

Declarative process modeling makes the governing aspects of business processes explicit in the form of vocabulary and business rules. Business rules are atomic, formal expressions of business policies, business regulations and common-sense constraints. Business rules make business concerns explicit and traceable. Procedural process languages predominantly focus on the control-flow perspective of business processes. In such process languages it might be possible to enforce business rules using a control-flow-based modeling construct. For instance, the enforcement of a derivation or integrity constraint can be directly modeled in BPEL as a calculation or input validation step. The disadvantage of procedural process modeling is that business rules cannot be formulated independently from the process models in which they are to be enforced. Consequently, the same business rule is often duplicated in several procedural process models. When the business rule changes it is likely that all process models must be reexamined. Declarative process modeling separates business rule modeling from business rule enforcement. In particular, it does not make use of control flow to

Declarative Process Modeling with Business

605

indicate when and how business rules are to be enforced [4]. Instead, it is left to the execution semantics of the declarative process models to define an execution model in which different business rule types are automatically enforced. This separation of business rule specification and enforcement facilitates design-time flexibility. Another point of difference is the modality that is attached to the information in process models. Procedural process models inherently have the necessity modality (what must ) attached, whereas declarative process languages allow for other modalities like intention (what ought ), possibility (what can) and certainty (what is). These modalities offer run-time flexibility. In particular, they allow to distinguish between what is strictly required (hard constraint) and what is merely desirable (soft constraint) behavior in a business process. This can help the coordinator of a business process to come up with a suitable yet valid execution plan. Procedural process models are overburdened with communication activities intended to notify an external business partner about the occurrence of a relevant business event or to transmit information. For example, an example in the BPMN specification [2, p. 107] contains communication activities such as ‘receive order’ and ‘send invoice’. Such communication activities depict communication logic in a procedural manner, because they specify how and when business events are communicated and information is transmitted. Declarative process models are only concerned with the ability of business agents to perceive business events and business concepts. When an agent (for instance a business partner) can perceive a particular event, the event becomes non-repudiable to the agent, irrespective of how the agent is notified of the event. The execution semantics of a declarative process model determines how events are communicated. In particular, events can be communicated as messages that are sent by the producer (push model), retrieved by the consumer (pull model) or via a publish-subscribe mechanism. This declarative modeling style enhances designtime flexibility, as it allows to model business processes irrespective of the used communication channels. To make a point, this section has contrasted procedural and declarative modeling. The difference between procedural and declarative process modeling is out there, but no dichotomy is implied. Many of the design-time advantages of declarative process modeling can already be realized by a careful methodology of documenting the underlying business concerns. The run-time advantages of increased flexibility and user-involvement nonetheless require a declarative modeling language. The choice for modeling language then depends on the application domain.

3

A Vocabulary for Declarative Process Modeling

Declarative process models should be on the one hand comprehensible so that they can be understood by business people and on the other hand formal so that they can be enforced by information systems. The Semantics of Business

606


Vocabulary and Business Rules (SBVR) [5,6] provides a number of conceptual vocabularies for modeling a business domain as a vocabulary and a set of rules. Additionally, the SBVR has a vocabulary to describe the semantic structure and meaning of expressions in terms of formal logic that can be used by automated reasoning mechanisms. This combination of linguistics and formal logic provides the fundamentals for developing a natural language parser that allows to express the meaning of rules that have a textual notation [7]. It makes the SBVR suitable as a base language for declarative process modeling. The current SBVR specification [6] does not have a built-in vocabulary for expressing process-related concepts such as agent, activity, event or deontic assignment. In [8] we define an SBVR vocabulary for expressing process-related concepts, called the EM-BrA2 CE Vocabulary. EM-BrA2 CE stands for ‘Enterprise Modeling using Business Rules, Agents, Activities, Concepts and Events’. The vocabulary thinks of a business process instance as a trajectory in a state space that consists of the possible sub-activities, events and business concepts that occur in the business process. Each activity in a process instance can undergo a number of distinct state transitions. The occurrence of a state transition is logged as an activity event. Business rules determine whether or not a particular state transition can occur. Consider, for instance the following state transitions: – create(AId, AT, BId, P Id, CoordinatorId): requests the creation of a new activity AId of type AT with business identifiers BId, parent activity P Id by an agent CoordinatorId. Activity event types: created. – assign(AId, AgentId, CoordinatorId): requests the assignment or revocation of the assignment of activity AId to an agent AgentId by an agent CoordinatorId. Activity event types: assigned. – updateF act(AId, C1 , C2 , W orkerId): requests the update of a business fact C1 by C2 within the context of activity AId by an agent W orkerId. Activity event types: f actU pdated. – complete(AId, W orkerId): requests the completion of activity AId by an agent W orkerId. Activity event types: completed. In [8] a total of twelve generic state transitions have been identified and a generic execution model has been defined in terms of Colored Petri Nets. Figure 1 illustrates a number of state transitions that occur to a given place order activity a1. Each state transition results in a new set of concepts and ground facts, and thus a new state, that are partially represented in the columns of the figure. To make this text self-contained, a number of concepts of the EM-BrA2 CE Vocabulary are discussed in the remainder of this section. The vocabulary defines instance-level concepts that are meant for describing the state of a business process instance. In addition, it defines type-level concepts that are meant for describing the state space of a business process model. Figure 2(a) is a MOF/UML class diagram representation of the instance-level concepts in the vocabulary. Likewise Figure 2(b) represents the type-level concepts. Whereas all instancelevel concepts extend SBVR:individual concept, all type-level concepts extend


607

schedule(a1,duedate1,….) assign(a1,agent1,...) addFact(a1,[...],...) complete(a1,agent1)

time business facts agent activity event has type has performer ...

a1 e1,e2 …,(e2,scheduled)

agent1 a1 e1,e2,e3 …,(e3,assigned) (a1,agent1)

has(order1,line1) agent1 a1 e1,e2,e3,e4,e5 …,(e5,factAdded) (a1,agent1)

has(order1,line1) agent1 a1 e1,e2,e3,e4,e5,e6 …,(e6,completed) (a1,agent1)

Fig. 1. An illustration of the state transitions for a place order activity a1

SBVR:concept type. To each instance-level individual concept a particular typelevel concept type corresponds. In the following paragraphs these type-instance pairs are defined. Activity is a central concept in the vocabulary. An activity can either represent the act of performing an atomic unit of work or the act of coordinating a set of sub-activities. The former is called an atomic activity whereas the latter is called a composite activity. Each activity has an activity type. An activity type is a SBVR:concept type that specializes the individual concept ‘activity’ and that classifies an activity. Example: anActivityX has type coordinate purchase order. An activity is an SBVR:individual concept that represents a unit of (coordination) work to be performed by an agent. Example: the activity ‘anActivityX’. In the context of a business process an agent can fulfill a particular role that represents an authorization to perform a number of activities. This conception of role is consistent with the Role Based Access Control (RBAC) standard [9,10,11]. A role is an SBVR:individual concept that represents a set of authorizations with regard to the performance of activities of given activity types. Example: the roles ‘buyer’, ‘seller’. An agent is an SBVR:individual concept that represents an actor or a group of actors who can perform activities. Example: the agents ‘workerX’, ‘sales department’, ‘banking inc.’. ‘Agent can have role role’ is a SBVR:associative fact type that represents that an agent can assume a particular role. Example: ‘Agent can have role role’ ‘Agent has role role in the context of activity’ is a SBVR:associative fact type that represents that an agent assumes a particular role in the context of an activity. In the vocabulary, the state of an activity (or service instance) includes the history of events related to the activity or its sub-activities. Unlike many ontologies for business modeling, such as for instance the UFO [12], a distinction

608

S. Goedertier and J. Vanthienen is about SBVR:IndividualConcept * *

Event

Individual Business Concept

has business ID * is of 1..* * * State has 1 SBVR:Fact

Activity or Service Instance

*

has coordinator Agent or has performer * Service 1 * Provicer

is parent of *

0..1

pertains to * *

Agent has Role in *context of Activity

Activity Event

Role

Business asserts Fact retracts * *

(a) instance-level is about 1

*

Event Type

Activity Event Type

has 1

SBVR:ConceptType

Business Concept Type

Role * *

Role can subscribe to EventType in context of ActivityType

has business ID type * 1..*

is of Activity Type 1 or Service * * Capability

can coordinate can perform * *

*

StateSpace

can manipulate can make visible * *

SBVR:VerbConcept

Business Fact Type or Business Verb Concept

can consist of *

(b) type-level Fig. 2. A MOF/UML representation of the EM-BrA2 CE Vocabulary

is made between activities and events. Activities are performed by agents and have a particular duration whereas events occur instantaneously and represent a state change in the world. Changes to the life cycle of an activity are reflected by means of activity events. Activity events allow process modelers to distinguish between the activity state transitions that occur when, among others, creating, scheduling, assigning, starting and completing an activity. An event is an SBVR:individual concept that corresponds to an instantaneous, discrete state change of a concept in the world. An event type is a SBVR:concept type that specializes the individual concept ‘event’ and that classifies an event. Agents that have a particular role in the context of a business process have the authorization to perform a particular activity. This authorization is expressed by the can perform fact type. When performing an activity of a particular activity type, an agent can manipulate business facts of particular business fact types. This is expressed by the can manipulate fact type. Additionally, agents can retrieve information about particular business fact types when performing activities. The business fact types that are visible are indicated by the can make visible fact type. The fact type ‘role can subscribe to event type in context of activity type’ expresses the visibility of events to agents in the context of an activity. It does not express how agents are notified of the event, which can generally occur using either a pull, a push or a publish-subscribe mechanism.


609

Furthermore, it is possible that the visibility is constrained by so-called event subscription constraint business rules.

4

Business Rule Types

Each business process can be modeled by describing its state space and the set of business rules that constrain the possible transitions in this state space. For instance, the state space of an order-to-cash process is described by the following concepts: – – – – –

composite activity types: coordinate sales order atomic activity types: place order, accept order, reject order, pay, ship activity event types: created, assigned, started, completed business concepts: order, order line business fact types: order has order line, order is critical ,...

In [8] a total of sixteen business rule types are identified that can constrain specific activity state transitions. They refer to one of the three aspects of business process modeling that are generally considered [13]: control-flow, data and organizational aspects. For reasons of brevity, only a number of these business rule types are included in this text. Control-flow Aspects. Business policy and regulations contain a lot of implicit order and timing information. In a trade community, for instance, different business protocols might exist for engaging in a business interaction. Such business protocols lay down the obligations and permissions of all business partners in an interaction and can be expressed in the form of temporal deontic rules. A temporal deontic rule is a structural business rule that defines when deontic assignments come into existence or cease to exist based on the (non-)occurrence of events. Example: Necessity: initially a buyer has the permission to perform a place order activity. Necessity: when a buyer completes a place order activity, the seller has the obligation to perform a accept order activity or a reject order activity within 2 time units. Assuming that the agents in a business interaction do not intend to violate these deontic assignment rules, the resulting permissions and obligations impose partial order constraints on the activities in a business process [14]. Activity pre- and postconditions are another way of expressing control flow aspects. An activity precondition is a business rule that defines the conditions that are required to start an activity of a given activity type. A precondition can refer to business facts or events in the event history. Example: To start an accept order activity, it is necessary that a place order activity

610


has been completed and that no accept order or reject order activity has been started. A business fact postcondition is a business rule that specifies the abstract state of an activity of a particular activity type upon its completion. A postcondition can refer to business facts or events in the event history. Example: To complete an activity that has type accept order, it is necessary that the order has an acceptation notice. Data aspects. The performer of an activity can perform particular manipulations (addition, removal or update) of business facts. These state transitions can be constrained by integrity constraints and derivation rules. A static integrity constraint is a business rule that constrains the domain over which business facts can range by expressing a logical assertion that can, cannot, must or must not remain true [15]. Example: It is necessary that each order has at least one order line. A derivation rule is a business rule that defines a business fact in terms of existing business facts [15]. Example: necessity: a luxury product has a value-added-tax of 20 percent. Organizational aspects. Organizational aspects related to the visibility of business concepts and events and the authorization to perform particular activities. For instance: An activity authorization constraint is a structural business rule that dynamically constrains the activities that can be assigned to an agent on the basis of the properties of the activity, the business facts in its state space and the properties of the agent. Example: It is necessary that an agent that has function junior sales representative can not perform activities that have type accept order or reject order for an order that has a total amount larger than 2000 euro. In the example, the fact ‘sales representative can perform accept order’ is constrained by the rule that sales orders larger than 2000 euro cannot be reviewed by junior sales representatives. Access control specifications adhering to the rolebased access control (RBAC) model [9,10,11] have a non-monotonic semantics of general rules and exceptions that can be expressed in defeasible logic [16].

5

Evaluation and Related Work

In the literature, languages such as the case handling paradigm [17], OWL-S [18], the constraint specification framework of Sadiq et al. [19], the Web Service Modeling Ontology (WSMO) [20], the ConDec language [21] and the PENELOPE language [14] can be categorized as declarative languages. None of these languages for declarative process modeling are expressive enough to cover the


611

many real-life business concerns that exist in reality. For instance, the ConDec language and the PENELOPE language only allow to express business rules about sequence and timing constraints, i.e. the control-flow perspective [13]. Web Service Orchestration standards such as OWL-S and WSMO, on the other hand, include the organizational and data model aspects, but do not provide a temporal logic to express temporal relationships between concepts such as activities or events. Moreover, these languages make use of very different knowledge representation paradigms. For instance, the ConDec language is expressed in Linear Temporal Logic (LTL) whereas the PENELOPE language is expressed in terms of the Event Calculus. These heterogenous knowledge representation paradigms raise the question how it will be possible to reason about such heterogeneously expressed knowledge. Finally, these languages do not have an explicit execution model or have an execution model that explicitly assumes either human or machine-mediated service enactment. The EM-BrA2 CE Framework has a formal execution model [8] and makes abstraction of the differences between humans and machines. Coordination work such as creating, scheduling, assigning, skipping, aborting or redoing an activity can then be performed by humans, machines or both. The vocabulary and execution model of the EM-BrA2 CE Framework have been validated experimentally using simulation and rule induction techniques. In [22] we have used the vocabulary and execution semantics of the EM-BrA2 CE Framework to generate simulation event logs from process models and to learn the business rules that constrain the state transitions in the process model from these event logs supplemented with noise by applying rule-induction techniques.

6

Conclusion

In this paper we have indicated how business process modeling can benefit form the upcoming SBVR standard. In particular, an SBVR vocabulary for process modeling was defined that allows to declaratively refer to the state of a business process when specifying process-related business rules. The sixteen business rule types identified by the framework allow to consider a broad range of control flow, data and organizational modeling aspects.

References 1. Andrews, T.: et al.: Business process execution language for web services (bpel4ws) version 1.1 (2003), http://www.ibm.com/developerworks/library/ws-bpel/ 2. Object Management Group: Business Process Modeling Notation (BPMN) – final adopted specification. OMG Document – dtc/06-02-01 (2006) 3. Object Management Group: UML 2.0 Superstructure Specification. OMG Document – formal/05-07-04 (2005) 4. Morgan, T.: Business Rules and Information Systems: Aligning IT with Business Goals. In: Addison-Wesley Professional (2002)

612


5. Chapin, D.: Semantics of Business Vocabulary & Business Rules (SBVR). In: Hawke, S., de Sainte Marie, C., Tabet, S. (eds.) Rule Languages for Interoperability, W3C (2005) 6. Object Management Group: Semantics of Business Vocabulary and Business Rules (SBVR) – Interim Specification. OMG Document – dtc/06-03-02 (2006) 7. Unisys: Unisys rules modeler. [10-11-2005] (2005), http://www.unisys.com/ eprise/main/admin/corporate/doc/Unisys Rules Modeler Ins ert.pdf 8. Goedertier, S., Haesen, R., Vanthienen, J.: EM-BrA2 CE v0.1: A Vocabulary and Execution Model for Declarative Process Models. FETEW research report, K.U.Leuven (2007), http://www.econ.kuleuven.ac.be/public/ndbaf38/EM-BrAACE 9. Sandhu, R.S., Coyne, E.J., Feinstein, H.L., Youman, C.E.: Role-based access control models. IEEE Computer 29(2), 38–47 (1996) 10. Ferraiolo, D.F., Sandhu, R.S., Gavrila, S.I., Kuhn, D.R., Chandramouli, R.: Proposed nist standard for role-based access control. ACM Trans. Inf. Syst. Secur. 4(3), 224–274 (2001) 11. InterNational Committee for Information Technology Standards (INCITS): RoleBased Access Control. American National Standard ANSI/INCITS 359-2004 (2004), http://csrc.nist.gov/rbac 12. Guizzardi, G., Wagner, G.: Ontologies and Business Systems Analysis. In: Rosemann, M., Green, P. (eds.) Some Applications of a Unified Foundational Ontology in Business Modeling. IDEA Publisher, pp. 345–367 (2005) 13. Jablonski, S., Bussler, C.: Workflow Management. In: Modeling Concepts, Architecture and Implementation, International Thomson Computer Press, London (1996) 14. Goedertier, S., Vanthienen, J.: Designing compliant business processes with obligations and permissions, [23] 5–14 15. Wagner, G.: The agent-object-relationship metamodel: towards a unified view of state and behavior. Inf. Syst. 28(5), 475–504 (2003) 16. Goedertier, S., Vanthienen, J.: Specifying Process-Aware Access Control Rules in SBVR. In: Paschke, A., Biletskiy, Y. (eds.) RuleML 2007. LNCS, vol. 4824, Springer, Heidelberg (2007) 17. van der Aalst, W.M.P., Weske, M., Gr¨ unbauer, D.: Case handling: a new paradigm for business process support. Data Knowl. Eng. 53(2), 129–162 (2005) 18. The OWL Services Coalition: OWL-S 1.2 Pre-Release. Available from 2006, http://www.ai.sri.com/daml/services/owl-s/1.2/ 19. Sadiq, S.W., Orlowska, M.E., Sadiq, W.: Specification and validation of process constraints for flexible workflows. Inf. Syst. 30(5), 349–378 (2005) 20. Roman, D., Keller, U., Lausen, H., de Bruijn, J., Lara, R., Stollberg, M., Polleres, A., Feier, C., Bussler, C., Fensel, D.: Web service modeling ontology. Applied Ontology 1(1), 77–106 (2005) 21. Pesic, M., van der Aalst, W.M.P.: A declarative approach for flexible business processes management, pp. 169–180 22. Goedertier, S., Martens, D., Baesens, B., Haesen, R., Vanthienen, J.: Process Mining as First-Order Classification Learning on Logs with Negative Events. In: BPI 2007. LNCS, Springer, Heidelberg (2007) 23. Eder, J., Dustdar, S. (eds.): BPM 2006. LNCS, vol. 4103. Springer, Heidelberg (2006)