EPC Modelling based on Implicit Arc Types

Transcription

1 EPC Modelling based on Implicit Arc Types Jan Mendling, Markus Nüttgens Universität Trier Wirtschaftsinformatik II, Postfach 3825, D Trier Abstract: Event Driven Process Chains (EPC) are commonly used for the modelling of business processes. As modelling is decentralised to personnel not familiar with the formal aspects of this method, syntax checks are needed to avoid invalid models. This paper presents the concept of implicit element and arc types. It can be used both to support modellers in the process of building models and to check entire models. It is especially helpful to avoid closure calculation for connector type consistency constraints. 1. EPC and Business Process Modelling 1.1. Modelling with EPC between Intuition and Validity Event Driven Process Chains (EPC) have been developed to model business processes on a conceptual level [KNS92]. Both in academics as integral part of the ARIS concept [Sc00] and in practice with SAP AG using them for their SAP reference model [Ke99], they have reached a wide-spread use. A major advantage of EPCs is their ability to express processes in an intuitive way. Thus, they are very often used for the documentation and management of business processes. Despite their popularity and intuition, the syntax of EPCs has to meet a variety of validity rules concerning the sequence of different elements. This turns out to be a problem when organizations decentralize and delegate their business process modelling activities to the departments concerned. On the one hand, the personnel involved might be little experienced in assessing the formal validity of the models they produce. One the other hand, models have to be valid in order to be reused in workflow management systems. As a consequence two questions arise: Firstly, which concepts can be used to guide the modeller during the process of modelling to avoid syntactically invalid modelling. Secondly, how can the validity of a given EPC model checked in an efficient way. This paper addresses these two problems and presents a concept called implicit arc types as a solution. Mendling, Jan; Nüttgens, Markus: EPC Modelling based on Implicit Arc Types. In: Godlevsky, Mikhail; Liddle, Stephen W.; Mayr, Heinrich C. (Eds.): Information Systems Technology and its Applications, International Conference ISTA'2003, June 19-21, 2003, Kharkiv, Ukraine, Proceedings. LNI 30 GI 2003, ISBN , pp

2 1.2. EPC Syntax Related Work Most of the formal contributions on EPCs have been focused on semantics, especially on the semantics of OR connectors. The translation of EPC process models to Petri Nets plays an important role in this context. Examples of this research can be found in Chen/Scheer [CS94], Rodenhagen [Ro97], Langner/Schneider/Wehler [LSW98], van der Aalst [Aa99], Rittgen [Ri00], and Dehnert [De02]. A major point of discussion is the non-locality of join-connectors [ADK02]. This paper will present a syntax related work based on the formal syntax definition of EPCs in [NR02]. Therefore we give a brief survey of syntax related work before presenting definitions in the second section. In Keller/Nüttgens/Scheer the EPC is introduced [KNS92] to represent temporal and logical dependencies in business processes. Elements of EPCs may be of function type (active elements), event type (passive elements), or of one of the three connector types AND, OR, or XOR. These objects are linked via control flow arcs. Connectors may be split or join operators, starting either with function(s) or event(s). These four combinations are discussed for the three connectors resulting in twelve possibilities. Split OR and Split XOR are prohibited after events, due to the latter being unable to decide which following functions to choose. Based on practical experience with the SAP Reference model, process interfaces and hierarchical functions are introduced as additional element types of EPCs [KM94]. These two elements permit to link different EPC models: process interfaces can be used to refer from the end of a process to a following process, hierarchical functions allow to define macro-processes with the help of sub-processes. Keller [Ke99] and Rump [99] provide a formal approach defining the EPC syntax. Based on this, Nüttgens/Rump [NR02] distinguish the concepts of a flat EPC Schema and a hierarchical EPC Schema. A flat EPC Schema is defined as a directed and coherent graph with cardinality and type constraints. A hierarchical EPC Schema is a set of flat or hierarchical EPC Schemata. Hierarchical EPC Schemata consist of flat EPC Schemata and a hierarchy relation linking either a function or a process interface to another EPC Schema. Fig. 1 shows a hierarchical EPC Schema consisting of two processes, which are linked via a hierarchical relation attached to the process interface To Design Process. Type consistency of consecutive connectors poses a major problem for these definitions, because the EPC graph has to be traversed to find and check all non-connector ancestors and descendant elements. In section two we will introduce explicit and implicit element and arc types, and define EPCs with the help of them. The advantages of such a definition are presented in section three, where it is described how formally valid business process modelling with EPCs can be granted.

3 EPC Symbols Requirements Engineering Design Process Event Function Start From Requirements Engineering Process Interface List requirements Can be fulfilled Connectors Control Flow Arc Cannot be fulfilled Can be fulfilled Design Design finished To Design Process Fig. 1. EPC example of a simple requirements engineering process. The connector represents an exclusive or. After Can be fulfilled a process interface links to the design process. 2. EPC Syntax Objects 2.1. Explicit and Implicit Element Types The distinction of explicit and implicit element types is rooted in two different perspectives on business process modelling, the perspective of the modeller and the perspective of verification. The task of the modeller is to compose a structure from a given set of symbols that is able to represent concepts of the domain in a pragmatic and abbreviated way. This set of symbols modelling is provided by a business process modelling tool. Such EPC symbols usually refer to the original definition of Keller/Nüttgens/Scheer [KNS92] distinguishing event type E, function type F, process interface P, connector AND, connector OR, and connector XOR. We refer to them as explicit element types EXPL being mutually disjoint: EXPL = E F P AND OR XOR. (1) Implicit element types relate to the perspective of syntactical verification. They represent disjoint specialisations of corresponding explicit element types. Each implicit element type captures a specific constellation in which an explicit element type may occur. Each of these implicit roles implies different restrictions on the set of allowed ancestors and descendants, and their cardinality. Fig. 2 presents explicit and corresponding implicit element types: Events E may be Start Events E S, Inner Event E Int or End Event E E. For process interfaces P can be used as start and end symbols. Connectors can be either joins

4 or splits. When they have (transitive) event ancestors, their (transitive) descendants have to be functions. When they have (transitive) function ancestors, their (transitive) descendants have to be events. For OR- and XOR-connectors Event-Function-Splits are forbidden [KNS92]. Explicit Element Type Event E Function F Process Interface P Connector AND Connector OR Connector XOR Implicit Element Types Start Event E S Inner Event E Int End Event E E Function F Start ProcessInterface P S End ProcessInterface P E Event-Function-Split AND EFS Event-Function-Join AND EFJ Function-Event-Split AND FES Function-Event-Join AND FEJ Event-Function-Join OR EFJ Function-Event-Split OR FES Function-Event-Join OR FEJ Event-Function-Join XOR EFJ Function-Event-Split XOR FES Function-Event-Join XOR FEJ Fig. 2. Explicit and corresponding implicit element types Explicit and Implicit Arc Types Analogously to the distinction between explicit and implicit element types, we define implicit arc types as a partition of the control flow arc (explicit arc type) [Me03]. Implicit arc types are subsets of the product of implicit element types. Fig. 3 presents which arcs are allowed from and to implicit element types. The 16x16 matrix shows 100 implicit arc types which are permitted. The distribution of them in this matrix suggests the distinction between two different groups of implicit arcs. We will refer to them as Function-Event-Arcs FEA and Event-Function-Arcs EFA. In order to define these two kinds of arcs, a grouping of implicit element types into Event-Types (from), Function-Types (from), Event-Types (to), and Function-Types (to) is needed: Event Types (from) ET from = E S E Int AND EFS AND EFJ OR EFJ XOR EFJ, Function Types (from) FT from = F P S AND FES AND FEJ OR FES OR FEJ XOR FES XOR FEJ, (2) (3) Event Types (to) ET to = E Int E E AND EFS AND EFJ OR EFJ XOR EFJ, (4) Function Types (to) FT to = F P E AND EFS AND EFJ OR EFJ XOR EFJ. (5)

5 We can then define these two different implicit arc type groups as FEA (FT from x ET to ), (6) EFA (ET from x FT to ), (7) (left) TO (above) ES EInt EE FROM E S E Int E E F P S P E AND EFS AND EFJ AND FES AND FEJ OR EFJ OR FES OR FEJ XOR EFJ XOR FES XOR FEJ F PS PE ANDEFS Fig. 3. Implicit arc types are a subset of the product of implicit element types. The arcs in the grey cells are Function-Event-Arcs; those arcs in the white cells are Event-Function-Arcs. In the following, the definition of implicit arc type groups will be used in a redefinition of EPCs. The advantages of such a definition are presented in section four. ANDEFJ ANDFES ANDFEJ OREFJ ORFES ORFEJ XOREFJ XORFES XORFEJ

6 3. EPC Syntax Properties 3.1. Syntactical Constraints of Flat EPCs Before presenting the syntactical properties of flat EPCs we still need some more definitions. Apart from cardinality which is defined in a different way by using implicit arc types, we follow Nüttgens/Rump [NR02]. The antisymmetry constraint is added, just like the constraint of the graph having to be simple which cannot be controlled by cardinality constraints on connectors. Let E S, E Int, E E, F, P S, P E, AND EFS, AND EFJ, AND FES, AND FEJ, OR EFJ, OR FES, OR FEJ, XOR EFJ, XOR FES, XOR FEJ be sets of elements of the respective element types. Then a set of vertices V is V = E S E Int E E F P S P E AND EFS AND EFJ AND FES AND FEJ OR EFJ OR FES OR FEJ XOR EFJ XOR FES XOR FEJ with all the elements of the union being mutually disjoint. Referring to the definitions (6) and (7) a set of arcs A is defined as A = FEA EFA. (9) The precondition of a vertex is made up by the set of ancestor arcs written as v := {(x,v) A} with v,x V. (10) The postcondition of a vertex is defined as the set of descending arcs: v := {(v,x) A} with v,x V. (11) A cycle set C is a set of vertices building a cycle: C V = {v 1,v 2,v 3,..,v n } with v 1 = v 2, v 2 = v 3,, v n = v 1 (12) Then, a flat EPC Schema EPC flat = (V,A) has the following flat EPC properties: 1. EPC flat is a directed graph. 2. EPC flat is a simple graph forbidding reflexive arcs or multiple arcs between two vertices. 3. EPC flat is a coherent graph. 4. EPC flat is an antisymmetric graph. 5. Concerning cycles: C i V: C i (E Int F ). 6. The set of Events E = E S E Int E E. 7. The set of Functions F. Concerning vertices there are the following cardinality constraints: (8)

7 1. Start vertices: v E S P S : v = and v = End vertices: v E S P S : v = 1 and v =. 3. Inner Events: v E Int : v = 1 and v = Functions: v F: v = 1 and v = Splits: v AND EFS AND FES OR FES XOR FES : v = 1 and v > Joins: v AND EFJ AND FEJ OR EFJ OR FEJ XOR EFJ XOR FEJ : v > 1 and v = 1. Concerning vertex types the following type consistency constraints apply: 1. Start Events: v E S : v EFA. 2. Inner Events: v E Int : v FEA and v EFA. 3. End Events: v E E : v FEA. 4. Start ProcessInterface: v P S : v FEA. 5. End ProcessInterface: v P E : v EFA. 6. Function: v F: v EFA and v FEA. 7. Event-Function-Connects: v AND EFS AND EFJ OR EFJ XOR EFJ : v EFA and v EFA. 8. Function-Event-Connects: v AND FES AND FEJ OR FES OR FEJ XOR FES XOR FEJ : v FEA and v FEA Syntactical Constraints of Hierarchical EPCs Let v V be a vertex, x i NC = (E S E Int E E F P S P E ) and c i C = V (E S E Int E E F P S P E ) a connector, then the non-connector ancestor border NCAB v of v is a set of all vertices, which are transitive ancestors of v only via connectors: NCAB v = {x 1,, x n }: x i NC: n i N and c ij C: x i = c i1, c i1 = c i2,, c ini = v (14) and the non-connector descendant border NCDB v of v is defined as: NCDB v = {x 1,, x n }: x i NC: n i N and c ij C: v = c i1, c i1 = c i2,, c ini = x i (15) Let EPC Set be a set of EPC Schemata EPC Set = {S 1,, S n }, (16) then a hierarchical EPC Schema EPC hier is defined as EPC hier = (V,A,H) (17) with H being a hierarchy relation linking a ProcessInterface or a function to another EPC Schema:

8 H (F P E ) x EPC Set with (F P E ) V (18) An EPC Schema Set is an EPC Set for which holds: EPC Schema = {S 1,, S n } (19) fulfilling the condition: S i EPC Schema : S i = (V i,a i,h i ) with H i (F i P Ei ) x EPC Schema. (20) Let HC S EPC Schema then HC S is called the hierarchical closure on S with HC S = {S 1,,S n S i n i : (H i1 S Sch i1 H i1 ) (H i2 Sch i1 Sch i2 H i2 ) (H ini Sch ini-1 Sch in H in ) (Sch i1,,sch ini EPC Schema )} (21) A hierarchical EPC Schema has to meet the following hierarchy requirements: 1. S i EPC Schema : S i meets the conditions for a flat EPC Schema. 2. Cardinality H i : v P Ei : {A EPC Schema (v,a) H i } = Cardinality H i : v F i : {A EPC Schema (v,a) H i } Pre-Event-Consistency: v F i : (v,s i ) H i : NCAB v = {e i e i E S S i } 5. Post-Event-Consistency: v F i : (v,s i ) H i : NCDB v = {e i e i E E S i } 6. Pre-Event-Consistency: v P Ei : (v,s i ) H i : NCAB v = {e e, ps S i ps P S e E Int e = ps }. Due to our restriction on P S NCAB v = Post-Event-Consistency: v P Ei : (v,s i ) H i : NCDB v = {e e, pe S i pe P E e E Int e = pe}. Due to our restriction on P E NCDB v = Recursion prohibited: S i EPC Schema : S i HC Si Syntactical Constraints of Arcs In section four EPC syntax checks are discussed. We will refer to the EPC syntactical constraints as Flat 1-8 for flat EPC Schema properties, Card 1-6 for cardinality constraints, Type 1-8 for type consistency constraints, and Hier 1-8 for hierarchy constraints. Here, we still need to mention constraints on arcs. Relating to our definition (2) - (5) of the different arc types, this seems redundant. But when it comes to model checking, implicit arc type groups will be a label on the respective arc which does not have to be consistent or valid. In that context there is a need to check if the types of the referenced vertices match the implicit arc type. Thus, we add Arc 1-2 to check arc consistency: 1. (x,y) FEA: x FT from and y ET to. 2. (x,y) EFA: x ET from and y FT to.

9 4. Using Implicit Arc Types for Validity Checks 4.1. Problems without Implicit Types Type Consistency of connectors has been a problem of former EPC definitions without implicit elements and arc types. When there is a path of successive connectors as in Fig. 4, transitive non-connector ancestor border NCAB v and descendant border NCDB v have to be determined. This involves costly traversing of the EPC graph. In the following paragraph, we describe how implicit element and arc types can lead to a better performance. In that context we distinguish guided modelling and model checking. Event 1 Event 2 Event 3 Event 4 Event 5 Function 1 Function 2 Function 3 Function 4 Function 5 Fig. 4. In order to check Type Consistency of the grey XOR-connector the transitive nonconnector ancestors and transitive non-connector descendants have to be determined Guided Modelling using Implicit Types Guided Modelling describes strategies to support the modeller in the process of building models in order to grant syntactically valid models. The definitions 6 and 7 concerning the two different implicit arc type groups can be used to determine conflicts when there is a new arc added to the model. It is assumed that the modeller uses symbols corresponding to explicit EPC element types. In order to take advantage of implicit types, we need a set of possible implicit element or arc types, referred to as, attached to every instance of an explicit EPC symbol. Modelling includes four elementary operations: the insertion of an explicit element and the insertion of an explicit control flow arc to the model; and the deletion of an element or an arc. Changes can be interpreted as a sequence of a deletion and an addition. In the following, we concentrate on insertions, because deletions work similar in the opposite way.

10 When there is an element inserted into the model, is instantiated with all of its implicit element types. The insertion of an arc affects the sets of possible implicit types of the start vertex of the arc S ; of the end vertex of the arc E ; and of the arc itself arc. In a first step, arc is determined by comparing E and S with the definitions of the two implicit arc type groups: E ET from S FT to EFA arc. (22) E FT from S ET to FEA arc. If there is Arc = {} after this first steps, the new arc is not valid, because type consistency is no longer granted. This invalid arc should then be deleted and a report be provided for the modeller. If Arc {}, then E and S need to be updated as a second step according to these rules: If Arc = {EFA, FEA}: E = E S = S (23) If Arc = {EFA}: E = E ET from S = S FT to If Arc = {FEA}: E = E FT from S = S ET to If Arc = {}: E = E S = S. As a third step, these recalculations must cascade from the updated vertices, because inconsistencies may appear transitively via connectors. Cycles do not pose a problem for termination, because is a finite set of maximum 16 elements. Each step can only involve a reduction of elements leading at least to a termination in terms of an empty set. This three-step algorithm helps to transform an EPC model from one type consistent state to another type consistent state. The operations from definition 22 and 23 may therefore be considered as an EPC model transaction granting validity Model Checking using Implicit Types The case of guided modelling demands extra features to be added to the business process modelling tool. The model checking approach does not require such capabilities. It takes a model composed of explicit element and arc type symbols as an input and determines the implicit type for each symbol. The use of implicit types avoids the calculation of the non-connector ancestor border NCAB v and descendant border NCDB v for each connector. The algorithm takes a list of symbols as an input, with each symbol being of one of the explicit element or arc types. The order of the symbols is arbitrary. It works in two steps. The first step is the hypothesis step: by checking the cardinality of the ancestors and descendants, the implicit types of Functions, Events and ProcessInterfaces are determined, and join connectors are distinguished from split connectors. If an unexpected constellation appears the implicit type is set to invalid. For arcs and connectors, we do not calculate the non-connector ancestor border, but follow only one path until we reach a non-connector element. If this is an Event, the arc is set to the implicit type EFA and

11 the connector to a EventFunctionJoin or Split. This hypothesis generated by only looking at one (transitive) ancestor can have two consequences: firstly, the hypothesis is correct, or the there is a type inconsistency. It is not possible that another hypothesis is correct. The second step is the confirmation step. The generated list of symbols labelled with implicit types is taken as an input. Now, for all elements and arcs type consistency can be checked only by looking at the ancestor and descendant arc for implicit element types or the start and the end vertex for implicit arc types. An expansion of vertices is no longer needed. 5. Conclusion and Future Work This paper has addressed the validity of EPC business process models. As process modelling becomes more and more decentralised in organisations, non-professional modellers need tools to assist them to produce high quality models in terms of syntactical validity. The concept of implicit element and arc types gives a transparent answer to the question of valid EPC syntax. Validity of connectors can be check only by looking at the implicit arc type group of the ancestor and descendant arcs. Additionally, the implicit complexity of EPCs as a modelling technique is revealed. Nevertheless, pre- and postevent-consistency and the recursion prohibition (Hier 4-8) of hierarchical EPC Schemas still need closures to be calculated in order to check validity. The next step will be an XSLT based syntax check for models stored in EPC Markup Language (EPML) [MN02]. References [ADK02] [Aa99] [CS94] [De02] [Ke99] [KM94] van der Aalst, W.; Desel, J.; Kindler, E.: On the semantics of EPCs: A vicious circle, in: Nüttgens, M.; Rump, F.J. (eds.): Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten - EPK 2002, Proceedings of the GI-Workshop EPK 2002, Trier, 2002, pp van der Aalst, W.M.P.: Formalization and Verification of Event-driven Process Chains, in: Information and Software Technology 41(1999)10, pp Chen, R.; Scheer, A.-W.: Modellierung von Prozessketten mittels Petri-Netz-Theorie, in: Scheer, A.-W. (ed.): Publications of the Institut für Wirtschaftsinformatik, No. 107, Saarbrücken Dehnert, J.: Making EPC s fit for Workflow Management, in: Nüttgens, M.; Rump, F.J. (eds.): Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten - EPK 2002, Proceedings of the GI-Workshop EPK 2002, Trier, 2002, pp Keller, G. & Partner: SAP/ R3 prozeßorientiert anwenden. Iteratives Prozeß- Prototyping mit Ereignisgesteuerten Prozeßketten und Knowledge Maps, Bonn et al Keller, G.; Meinhardt, S.: DV-gestützte Beratung bei der SAP-Softwareeinführung, in: HMD 31(1994)175, pp

12 [KNS92] [LSW98] [Me03] [MN02] [NR02] [Ri00] [Ro97] [Ru99] [Sc00] Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozeßmodellierung auf der Grundlage Ereignisgesteuerter Prozeßketten (EPK). In: Scheer, A.-W. (Hrsg.): Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 89, Saarbrücken, Langner, P.; Schneider, C.; Wehler, J.: Petri Net Based Certification of Event driven Process Chains, in: Desel, J.; Silva, M. (eds.): Application and Theory of Petri Nets 1998, LNCS Vol. 1420, Springer, Berlin et. al. 1998, pp Mendling, J.: Event-Driven-Process-Chain-Markup-Language (EPML): Anforderungen, Konzeption und Anwendung eines XML-Schemas für Ereignisgesteuerte Prozessketten (EPK), in: Höpfner, H.; Saake, G.: Proceedings of the Student Program of the 10th Conference Database Systems for Business, Technology and Web, GI Section Databases and Information Systems, Leipzig, , Madgeburg, 2003, pp Mendling, J.; Nüttgens, N.: Event-Driven-Process-Chain-Markup-Language (EPML): Anforderungen zur Definition eines XML-Schemas für Ereignisgesteuerte Prozessketten (EPK), Proceedings of the GI-Workshop EPK 2002, Trier, 2002, pp Nüttgens, M.; Rump, F.: Syntax und Semantik Ereignisgesteuerter Prozessketten (EPK), in: Prozessorientierte Methoden und Werkzeuge für die Entwicklung von Informationssystemen (Promise 2002), Hasso-Plattner-Institut für Softwaresystemtechnik an der Universität Potsdam, Oktober 2002, Potsdam Rittgen, P.: Paving the Road to Business Process Automation, European Conference on Information Systems (ECIS) 2000, Vienna, Austria, July 3-5, 2000, pp Rodenhagen, J.: Darstellung ereignisgesteuerter Prozeßketten (EPK) mit Hilfe von Petrinetzen, Diplomarbeit Universität Hamburg Fachbereich Informatik (Prof. Valk), Hamburg Rump, F.: Geschäftsprozeßmanagement auf der Basis ereignisgesteuerter Prozeßketten - Formalisierung, Analyse und Ausführung von EPKs, Teubner, Stuttgart et al Scheer, A.-W.: ARIS Business Process Modeling, 3rd edition, Springer, Berlin et. al