Syntax und Semantik Ereignisgesteuerter Prozessketten (EPK)MarkusNüttgensmarkus@nuettgens.deFrankJRumpUniversität Trier Wirtschaftsinformatik IIPostfach 3825D-54286TrierFachbereich TechnikFachhochschule OL/OstfrieslandWHVConstantiaplatz 4D-26723EmdenInstitut für SoftwaresystemtechnikUniversität Potsdam9.-11. Oktober 20022002PotsdamSyntax und Semantik Ereignisgesteuerter Prozessketten (EPK)F8EF70DFDFDDE299232C5FDE1F16F5AEGROBID - A machine learning software for extracting information from scholarly documents
Die Ereignisgesteuerte Prozesskette (EPK) wurde zur Dokumentation von Geschäftsprozessen entwickelt und hat in der Praxis eine weite Verbreitung gefunden. Aufgrund der hohen Akzeptanz und der wachsenden Bedeutung prozessorientierter Organisationsstrukturen dient sie zunehmend als Grundlage für ein integriertes Geschäftsprozessmanagement. Ein durchgängiges Managementkonzept zur werkzeuggestützten Planung, Steuerung, Ausführung und Kontrolle von Geschäftsprozessen erfordert eine korrekte Formalisierung und Implementierung der EPK-Syntax und -Semantik. Die in der Theorie und Praxis dokumentierten Beiträge zur EPK-Formalisierung leisten dies nur mit wesentlichen Einschränkungen. In diesem Beitrag erfolgt eine Formalisierung des Kontrollflusskonzeptes auf der Grundlage der ursprünglichen EPK-Syntax und -Semantik. Der vorliegende Ansatz kann um ein Ressourcen-, Mengen-und Zeitkonzept erweitert werden und bietet Anwendern und Werkzeugherstellern einen stabilen Bezugsrahmen zur korrekten Modellierung und Anwendung von EPK-Geschäftsprozessmodellen. 1 Einführung Die Ereignisgesteuerte Prozesskette (EPK) wurde am Institut für Wirtschaftsinformatik (IWi) der Universität des Saarlandes in Zusammenarbeit mit der SAP AG zur Dokumentation von Geschäftsprozessen entwickelt [KNS92]. Sie ist zentraler Bestandteil der SAP-Referenzmodelle [Ke99] und der ARIS-Konzepte [Sc99, Sc01] und somit Grundlage modellgetriebener Ansätze für ein durchgängiges und werkzeuggestütztes Geschäftsprozessmanagement. Ein Managementkonzept zur werkzeuggestützten Planung, Steuerung, Ausführung und Kontrolle von Geschäftsprozessen erfordert eine hinreichende Spezifikation des EPK-Konzeptes. Die Formalisierung vermeidet unterschiedliche Interpretationen und ist Basis für korrekte Anwendungen und Implementierungen von Geschäftsprozessmodellen. In der Literatur sind bislang nur einige wenige Ansätze zur formalen Spezifikation der EPK-Syntax und -Semantik vorgeschlagen worden. Nüttgens, M.; Rump, F.: Syntax und Semantik Ereignisgesteuerter Prozessketten (EPK), in: Prozessorientierte Methoden und Werkzeuge für die Entwicklung von Informationssystemen (Promise'2002), Gemeinsames Fachgruppentreffen der GI-Fachgruppen "Petrinetze und verwandte Systemmodelle" und "Entwicklungsmethoden für Informationssysteme und ihre Anwendung" (EMISA), Hasso-Plattner-
Im Regelfall wird eine "Übersetzersemantik" in Zustandsdiagramme (Petrinetze, Statecharts etc.) zugrunde gelegt, um die vorhandenen formalen Analysetechniken zur Verifikation von (Geschäfts-)Prozessmodellen nutzen zu können. Exemplarische Forschungsansätze finden sich bei Chen/Scheer und Hoffmann/Scheer [CS94,HSH95], Langner/Schneider/Wehler [LSW97a, LSW97b, LSW97c, LSW97d, LSW98], Rodenhagen/Modt [Ro97, MR00], v. Uthmann [Ut97, Ut98], Weikum/Wodtke [We97,Wo97], Volkmer [Vo97], v. d. Aalst [Aa98,Aa99] und Rittgen/Dehnert [Ri99a, Ri99b, Ri99c, Ri99d, Ri00a, Ri00b, Ri00c, De01, DR01]. Weitere eigenständige formale Ansätze zur Syntax-und Semantikdefinition finden sich bei Rump [Ru95, ZR96, Ru97a, Ru97b, Ru97c, Ru99], Moll [Mo96] und Heimig [He01]. Einen konzeptionellen Ansatz im Rahmen der "Grundsätze ordungsgemäßer Modellierung" verfolgen Becker/ Rosemann/Schütte [BRS95,Ro96].
Keiner dieser Ansätze spezifiziert das EPK-Konzept vollständig auf der Grundlage der ursprünglichen Syntax und Semantik. Vielmehr werden entweder wesentliche Bestandteile der EPK-Syntax und -Semantik nicht oder mit mehr oder weniger starken Einschränkungen formalisiert. Insbesondere die Übersetzersemantiken in Petrinetze führen bei der Formalisierung des Synchronisationsverhaltens bei (X)OR-Verknüpfungsoperatoren zu Problemen, da deren Semantik nicht lokal beschränkt ist. Eine unreflektierte Übernahme der Verifikationskonzepte für Petrinetze führt ebenfalls zu Differenzen bei der Beurteilung ausgewählter, besonders kritischer EPK-Eigenschaften (z.B. Verklemmungsfreiheit von EPKs).
In Abb. 1 ist exemplarisch ein EPK-Schema zur Beschreibung des Geschäftsprozesses "Kreditantrag bearbeiten" aufgeführt. Das Kontrollflusskonzept wird als eine Abfolge von Ereignissen, Funktionen, Verknüpfungsoperatoren und Prozesswegweisern beschrieben und kann um den Ressourcenaspekt (Organisationseinheiten, Informationsund Sachobjekte) ergänzt werden. Funktionen und Prozesswegweiser können aus pragmatischen Gründen horizontal und vertikal (de-)komponiert werden. Dies wird logisch über die Verwendung gemeinsamer Ereignisse (E8, E9, E10) ausgedrückt. Prozesswegweiser zeigen explizit Schnittstellen zwischen vor-und nachgelagerten (Teil-) Prozessketten an und dienen insbesondere bei großen EPK-Schemata als wichtige Navigationshilfe. Die relevanten Ressourcenaspekte können ebenfalls direkt im Kernmodell oder in hierarchisierten Teilmodellen abgebildet werden.
Die aus dem EPK-Schema resultierenden Prozessszenarien sind weitgehend selbsterklärend: Innerhalb des Kernprozesses "Kreditantrag bearbeiten" wird der Kreditantrag erfasst (F1) und einer standardisierten Risikoprüfung unterzogen (F2). Im Falle des negativen Ausgangs der (Erst-)Prüfung erfolgt eine weitere fallspezifische Abschätzung (F3). Diese endet entweder mit der Ablehung (F4) oder einer Wiedervorlage zur Risikoprüfung (F2). Im Falle einer positiven Risikoprüfung ist es von Relevanz, ob es sich um einen Neukunden handelt. In diesem Fall erfolgt nebenläufig zur Erstellung des Kreditvertrages (F5) eine Bedarfsanalyse (F6). Sobald der Kreditvertrag vorbereitet ist, kann dieser von den Vertragspartnern unterschrieben werden (F7). Bei Neukunden kann eine Nachberatung (F8) frühestens dann erfolgen, wenn der Kreditvertrag vorbereitet ist und die Bedarfsanalyse abgeschlossen ist.
∑ ∈ = A a a a m ) ( M . Seien , ) , ( 1 1 m A M = MS A m A M ∈ = ) , ( )) ( ) ( ( 2 1 2 1 + = + ∑ ∈ (Addition) a a m a m M M A a ) 0 max )) ( ) ( ( ( 2 1 2 1 − = − ∑ ∈ (Subtraktion) ) ( | | 1 1 a m M A a ∑ ∈ = (Kardinalität)
Syntaxdefinition
Dieser Abschnitt beschreibt die Syntax einer EPK, bei der zunächst nur der Kontrollfluss betrachtet wird und somit als Knoten nur Ereignisse, Funktionen, Verknüpfungsoperatoren und Prozesswegweiser zugelassen werden. Weiterhin beschränkt sich die folgende Definition zunächst auf nicht-hierarchische EPKs.
Definition 2.2 (flaches EPK-Schema) Ein flaches EPK-Schema A ist ein Tupel , für welches gilt: ) , , , , , (
0 S C V P F E A = • E ist eine Menge von Ereignissen mit ∅ ≠ E , • F ist eine Menge von Funktionen mit ∅ ≠ F , • P ist eine Menge von Prozesswegweisern und • ist eine Menge von Verknüpfungsoperatoren, die sich in paarweise disjunkte Teilmengen V , V und V aufteilt, so dass V V OR XOR AND AND XOR OR V V V ∪ ∪ = . • E , F , P und V sind paarweise disjunkt. • Sei V P F E K ∪ ∪ ∪ = . Die Multimenge ) , ( C m K K C × =
beschreibt den Kontrollfluss.
• ist eine Menge von Startbelegungen.
S C V F E A = darstellen.
Zur Vereinfachung werden folgende Schreibweisen eingeführt:
1. C k j k j C ∈ ⇔ → ) , ( : 2. , wobei m ) , ( k V m K k = • )) , (( ) ( k j m j C k V = ist, sei die Multimenge der direkten Vorgänger von k , und 3. , wobei m ) , ( k N m K k = • )) , (( ) ( j k m j C k N = ist, enthält die direkten Nachfolger von . k 4. ; die Relation beschreibt, welche Elemente von k a a a j n K a a k j n C C C n C = → → → = > ∈ ∃ ⇔ → ... : 1 , ,..., : * 2 1 1 * C →
K durch den Kontrollfluss miteinander verbunden sind. 5.
; die Relation beschreibt, welche Elemente von
k v v j n V v v k j C n C C C n V C → → → → ≥ ∈ ∃ ⇔ → ... : 0 , ,..., : 1 1 V C →
K im Kontrollfluss nur über Verknüpfungsoperatoren miteinander verbunden sind.
Zusätzlich werden folgende Mengen definiert:
} * : | { e g E g E e E C S → ∈ ¬∃ ∈ = Menge der Startereignisse, } * : | { g e E g E e E C E → ∈ ¬∃ ∈ = Menge der Endereignisse, } 1 | || { = • ∈ = v V v S
AND AND
Menge der AND-Split-Operatoren, } 1 | || { = • ∈ = v V v S XOR XOR Menge der XOR-Split-Operatoren, } 1 | || { = • ∈ = v V v S OR OR Menge der OR-Split-Operatoren, } 1 | || { > • ∈ = v V v J AND AND
Menge der AND-Join-Operatoren, } 1 | || { > • ∈ = v V v J XOR XOR Menge der XOR-Join-Operatoren, } 1 | || { > • ∈ = v V v J OR OR Menge der OR-Join-Operatoren. Ein syntaktisch korrektes, flaches EPK-Schema ) , , , , , ( 0 S C V P F E A =
muss weiterhin die folgenden Eigenschaften erfüllen:
1. Sei C } ) , ( | ) , {( C k j k j S ∈ = . ) , ( S C K G =
ist ein gerichteter und zusammenhängender Graph.
2.
Alle Kontrollflusskanten haben die Multiplizität 1: 1 1 )) , (( :
) , ( = ∈ ∀ k j m C k j C 3.
Funktionen besitzen genau eine eingehende und genau eine ausgehende Kontrollflusskante:
1 | | | :| = • = • ∈ ∀ f f F f 4.
Ereignisse haben genau eine eingehende und/oder genau eine ausgehende Kontrollflusskante:
1 | | 1 | :| ≤ • ∧ ≤ • ∈ ∀ e e E e
(Falls ein Ereignis nur eine Kontrollflusskante aufweist, handelt es sich um ein Start-oder Endereignis:
E S E E e e e E e ∪ ∈ ⇒ = • + • ∈ ∀ 1 | | | :| ) 5.
Prozesswegweiser haben genau eine eingehende oder eine ausgehende Kontrollflusskante:
1 | | | :| = • + • ∈ ∀ p p P p 6.
Verknüpfungsoperatoren haben entweder eine eingehende und mehrere ausgehende (Split-Operator) oder mehrere eingehende und eine ausgehende Kontrollflusskante (Join-Operator):
) 1 | | 1 | (| ) 1 | | 1 | (| : = • ∧ > • ∨ > • ∧ = • ∈ ∀ v v v v V v 7.
Es gibt keinen gerichteten Kreis im EPK-Schema, der nur aus Verknüpfungsoperatoren besteht:
v u v u V v u V C ≠ ⇒ → ∈ ∀ : , 8.
Ereignisse sind nur mit Funktionen und Prozesswegweisern (möglicherweise über Verknüpfungsoperatoren) verbunden:
P F f f e V K f E e V C ∪ ∈ ⇒ → − ∈ ∈ ∀ : , 9.
Funktionen und Prozesswegweiser sind nur mit Ereignissen (möglicherweise über Verknüpfungsoperatoren) verbunden:
E e e f V K e P F f V C ∈ ⇒ → − ∈ ∪E P F H ′ × ∪ ⊆ ) (
Die Relation H ordnet somit einer Funktion oder einem Prozesswegweiser ein anderes EPK-Schema zu. Eine Funktion, die derart durch ein anderes EPK-Schema verfeinert wird, wird im folgenden hierarchisierte Funktion genannt. In einer EPK-Schemamenge werden nun EPK-Schemata zusammengefasst, bei denen die über Prozesswegweiser oder Funktionen referenzierten EPK-Schemata auch wieder selbst Elemente der EPK-Schemamenge sind.
Definition 2.5 (EPK-Schemamenge) Eine EPK-Schemamenge
ist eine Menge von (flachen oder hierarchischen) EPK-Schemata, bei der für alle hierarchischen EPK-Schemata gilt: .
} ,..., { 1 * n A A E = * ) E P i × ) , , , , , ,0 i i i i i i i H S C V P F E A i = (F H i i ∪ ⊆
Durch die nachfolgende Definition eines syntaktisch korrekten, hierarchischen EPK-Schemas wird festgelegt, wie die Verknüpfung von EPK-Schemata einer EPK-Schemamenge zu erfolgen hat: Definition 2.6 (syntaktisch korrektes, hierarchisches EPK-Schema) Sei eine EPK-Schemamenge.
ist ein syntaktisch korrektes, hierarchisches EPK-Schema, wenn folgende Forderungen erfüllt sind:
} ,..., { 1 * n A A E = * 0 ) , , , , , , ( E H S C V P F E A i i i i i i i i ∈ = 1.
ist ein syntaktisch korrektes, flaches EPK-Schema. ) , , , , , (
0 i S C V P F E A i i i i i = ′ 2.
Jedem Prozesswegweiser ist über die Hierarchierelation genau ein EPK-Schema zugeordnet:
1 | } ) , ( | { :| * = ∈ ∈ ∈ ∀ i i H A p E A P p 3.
Jeder Funktion wird maximal ein EPK-Schema zugewiesen:
1 | } ) , ( | { :| * ≤ ∈ ∈ ∈ ∀ i i H A f E A F f 4.
Die Menge der vorangehenden Ereignisse einer hierarchisierten Funktion entspricht der Menge der Startereignisse des referenzierten EPK-Schemas:
j S V C i i j i E f e E e H A f F f = → ∈ ⇒ ∈ ∈ ∀ } | { ) , ( :
5.
Die Menge der nachfolgenden Ereignisse einer hierarchisierten Funktion entspricht der Menge der Endereignisse des referenzierten Schemas:
j E V C i i j i E e f E e H A f F f = → ∈ ⇒ ∈ ∈ ∀ } | { ) , (
Die Menge der vorangehenden Ereignisse eines Prozesswegweisers ist eine Teilmenge der Startereignisse des referenzierten EPK-Schemas:
j S V C i i j i E p e E e H A p P p ⊆ → ∈ ⇒ ∈ ∈ ∀ } | { ) , (
Die Menge der nachfolgenden Ereignisse eines Prozesswegweisers ist eine Teilmenge der Endereignisse des referenzierten Schemas:
j E V C i i j i E e p E e H A p P p ⊆ → ∈ ⇒ ∈ ∈ ∀ } | { ) , (
Das hierarchische EPK-Schema ist nicht über die Hierarchierelation mit sich selbst verbunden (Verbot der Rekursion):
i A f j∃ i i i i i i i i i A A A H A f P F k k E A A j k k k k j = = ∧ ∈ ∪ ∈ < ≤ ∀ ∈ ¬∃ + 1
*
Diese Forderungen bieten die Möglichkeit, aus einem syntaktisch korrekten, hierarchischen EPK-Schema ein flaches EPK-Schema zu erzeugen ("Flachklopfen"), indem hierarchisierte Funktionen bzw. Prozesswegweiser durch die in der Hierarchierelation referenzierten EPK-Schemata sukzessive verfeinert werden, wobei die Verknüpfung durch die in beiden Schemata enthaltenen, benachbarten Ereignisse spezifiziert ist. Aufgrund dieser Möglichkeit werden zur Semantikdefinition nur flache Schemata ohne Prozesswegweiser betrachtet, was entsprechend dieser Ausführungen keine Einschränkung darstellt.
Semantikdefinition
Zur Definition der Semantik wird zunächst das flache EPK-Schema in ein Vorverknüpfer-ergänztes, flaches EPK-Schema umgewandelt.
C V F E A = W V F ∪ ∪ = ′ und ) , ( C m K K C ′ ′ × ′ = ′ 3 : • ∑ ∪ ∪ ∈ ∈ ∈ = AND XOR OR J J J v C v x K x W | } ) , ( | { | | | • C w x C v w W w J J J v C v x AND XOR OR ′ ∈ ∧ ′ ∈ ∈ ∃ ∪ ∪ ∈ ∈ ∀ ) ,∈ ∪ ∪ ∪ ∪ ∈ ∈ ∀ • 1 )) , (( : ) , ( = ′ ∈ ∀ ′ k j m C k j C • 1 | | | :| = • = • ∈ ∀ w w Wa} { a ) , ( m K ′ a TR b = ⇒ a n ∈ } { n a m = ) ( ⇔ ′ → : S S TR 1-3. S , falls • + − = ′ a a S ) } { ( 1 AND E S F E E a ∪ ∪ − ∈ ) ( 4. , 1 1 } { ) } { ( b a S S + − = ′ • ∈ a b , falls XOR S a ∈ 5. , B a S S + − = ′ ) } { ( 1 0 | | > ∧ • ≤ B a B , falls OR S a ∈ 6. • + • − = ′ v v S S ) ( , falls W a ∈ , • ∈ a v , AND J v ∈ und S w v w ∈ • ∈ ∀ : 7. , falls • + − = ′ v a S S ) } { ( 1 W a ∈ , • ∈ a v , XOR J v ∈ , | 1 | } | { = ∈ • ∈ S w v w und v w S w S S a S S S S n n TR TR n • ∈ ∧ ∈ ∧ → → ∧ − = ¬∃ ... } { : ,..., 1 1 1 1 8. • + • − = ′ v v S S ) ( , falls W a ∈ , • ∈ a v , OR J v ∈ und v w S v n TR • ∈ ∧ w S n S S S S S n TR ∈ ∧ → → ∧ • − = ¬∃ : ,..., 1 1 ... 1
Der aktuelle Zustand eines EPK-Schemas kann durch "wandernde" Prozessmappen veranschaulicht werden. Liegt eine Prozessmappe auf einem Kontrollflussobjekt, so ist dieses im Zustand "aktiv", andernfalls "inaktiv". Die Transitionsrelation beschreibt somit folgende Eigenschaften für die Kontrollflussobjekte: TR → 1. Ereignisse leiten im Zustand "aktiv" eine Prozessmappe (sofort) an das nachfolgende Kontrollflussobjekt weiter. 2. Funktionen leiten im Zustand "aktiv" eine Prozessmappe (nach Beendigung des Bearbeitungsvorganges und der Freigabe) an das nachfolgende Kontrollflussobjekt weiter. 3. AND-Split-Operatoren leiten im Zustand "aktiv" (sofort) genau eine Prozessmappe an jedes nachfolgende Kontrollflussobjekt weiter. 4. XOR-Split-Operatoren leiten im Zustand "aktiv" (sofort) genau eine Prozessmappe an genau ein nachfolgendes Kontrollflussobjekt weiter. 5. OR-Split-Operatoren leiten im Zustand "aktiv" (sofort) genau eine Prozessmappe an jedes Kontrollflussobjekt einer Teilmenge der nachfolgenden Kontrollflussobjekte weiter. 6. AND-Join-Operatoren leiten im Zustand "aktiv" eine Prozessmappe (sofort) an das nachfolgende Kontrollflussobjekt weiter, wenn von allen vorgelagerten Kontrollflussobjekten (Vorverknüpfern) eine Prozessmappe eingetroffen ist. 7. XOR-Join-Operatoren leiten im Zustand "aktiv" eine Prozessmappe (sofort) an das nachfolgende Kontrollflussobjekt weiter, wenn von genau einem direkt vorgelagerten Kontrollflussobjekt (Vorverknüpfer) eine Prozessmappe eingetroffen ist und keine weiteren Prozessmappen mehr die verbleibenden vorgelagerten Kontrollflussobjekte erreichen können. 8. OR-Join-Operatoren leiten im Zustand "aktiv" eine Prozessmappe (sofort) an das nachfolgende Kontrollflussobjekt weiter, wenn von jedem Kontrollflussobjekt einer Teilmenge der direkt vorgelagerten Kontrollflussobjekte (Vorverknüpfer) eine Prozessmappe eingetroffen ist und keine weiteren Prozessmappen mehr die verbleibenden vorgelagerten Kontrollflussobjekte erreichen können.
Regel eine Teilmenge der Startereignisse dar und legt fest, welche Kombinationen von eingetretenen Startereignissen eine initiale EPK-Instanz aufweisen kann. Falls keine Prozesswegweiser im EPK-Schema verwendet werden ( ), lässt sich das flache EPK-Schema auch kurz durch 0
Bedarfsanalyse durchführen Kreditantrag bearbeiten Zusatzprodukte anbietenMenge aller Multimengen über A dar. Eine Multimenge kann durch ihre formale Summe dargestellt werden:
E1 2 Syntax-und SemantikdefinitionE1 Kreditantrag erfassenKredit istbeantragtKredit istbeantragt Nachfolgend wird eine Formalisierung des EPK-Kontrollflusskonzeptes durch eine F1 Kreditantrag erfassen F1 Kreditantrag erfassen Kreditantrag umfassende Syntax-und Semantikdefinition vorgestellt. Hierbei wird ein operationaler Kunde Kunden-Ansatz zur Semantikdefinition verfolgt, da dieser unmittelbar die schrittweiseE2 Berechnung sämtlicher erreichbaren Zustände und darauf aufbauende Analysen E2 bertreuerAntragsdaten sind erfasst V1 ermöglicht [Ru99]. Für die Beschreibung der Syntax und Semantik von EPKs werden Antragsdaten sind erfasst die Definitionen der Multimenge und der darauf möglichen Operationen benötigt.F2 Definition 2.1 (Multimenge) Eine Multimenge M über einer Menge A ist ein Paar Risiko-prüfung durchführen , wobei die Abbildung ist. m heißt Multiplizität von ) , ( m A M = m 0 N : A m → ) (aa ∈A.MS Astellt dieV3V5E3V6V7AntragstellerE8Risikoprüfungist Neukundeist negativE7E8Kunden-überprüfen bewertungF3Risikoprüfung ist positivF5Antragsteller ist NeukundeF6Kundentyp ermittelnF6.1V4Kreditvertrag erstellenBedarfs-analyse durchführenKundentyp istE8.1ermitteltE4E5E9E10Kunden-bewertung ist positivKunden-bewertung ist negativKreditvertrag ist vorbereitetBedarfs-analyse ist durchgeführtBedarfsstruktur ermittelnF6.2F4V8V9Kreditantrag ablehnenF7P1Bedarfs-analyse ist durchgeführtE10E6KreditvertragZusatzprodukteKreditantragunterschreibenanbietenist abgelehntE11KreditvertragistabgeschlossenEPK-SymboleEreignisP2P2FunktionKreditantrag bearbeitenKreditantrag bearbeitenProzesswegweiserE9E10OrganisationseinheitKreditvertrag ist vorbereitetV9Bedarfs-analyse ist durchgeführtInformations-undSachobjektF8VerknüpfungsoperatorNachberatungdurchführenK ontrollflussE12RessourcenflussZusatzprodukteInformationsflusssind angebotenAbb. 1: Ereignisgesteuerte Prozesskette: Fallbeispiel "Kreditantrag"
Geschäftsprozesse werden in der Praxis aufgrund der besseren Übersichtlichkeit und der Möglichkeit der Wiederverwendung von Prozessteilen nicht durch ein einzelnes EPK-Schema, sondern durch eine Menge von EPK-Schemata beschrieben, die über Prozesswegweiser oder Funktionen miteinander verbunden sind. Diese hierarchischen EPK-Schemata werden im folgenden eingeführt.
Definition 2.3 (syntaktisch korrektes, flaches EPK-Schema) Ein flaches EPK-SchemaA =(E,F,P,V,C,S0)heißt syntaktisch korrekt, wenn das Schema die Eigenschaften 1-13 erfüllt.Definition 2.4 (hierarchisches EPK-Schema) SeiE = ′{ 1 A,...,n A}eine Menge vonEPK-Schemata.EinhierarchischesEPK-SchemaAisteinTupelA =(E,F,P,V,C,S, 0 H), für welches•A = ′(E,F,P,V,C,S0)ein flaches EPK-Schema ist und•die Verknüpfung zu einem anderen EPK-Schema herstellt(Hierarchierelation)∀∈,:10. Nach Ereignissen folgt kein XOR-oder OR-Split-Operator im Kontrollfluss: 2e ∀∈E:e→V Cv∧v∈V⇒v∈SAND∪JOR∪JXOR∪JAND11. Es gibt mindestens ein Start-und mindestens ein Endereignis:|ES| >0∧|EE| >012. In einer Startbelegung dürfen nur Startereignisse und diese nur mit derMultiplizität 1 enthalten sein:∀ S∈S0∀ e∈S:e∈ES∧mS(e)=113. Jedes Startereignis ist in einer Startbelegung enthalten:e ∀∈ESS ∃∈S0:e∈S1 Anschaulich gesprochen wird hierdurch die Einfachheit des Graphen gefordert. Die dadurch möglicheDarstellung der Kanten als Teilmenge von K x K wird allerdings nicht gewählt, da die Einfachheit bei den in[Ru99] eingeführten Junktornetzen nicht mehr gegeben ist, aber trotzdem dieselbe Semantikdefinitionanwendbar sein soll.2 Somit werden nur die in [KN92] dargestellten Verknüpfungsarten erlaubt. Diese Einschränkung entsprichtauch der Interpretation des Ereignisbegriffes im Kontext deterministischer endlicher Zustandsautomaten.
Dazu wird vor jedem Join-Operator für jede Kante ein Vorverknüpfer in den Kontrollfluss eingefügt, um feststellen zu können, welche eingehenden Pfade aktiviert sind.
Definition 2.7 (Vorverknüpfer-ergänztes, flaches EPK-Schema) Ein Vorverknüpfer-ergänztes EPK-Schema ) , , , , , ( 0 S C W V F E A ′ = ′ zu einem syntaktisch korrekten EPK-Schema(,,,, 0 S)ergibt sich durch folgende Ergänzung einer Menge vonVorverknüpfern W im Graphen, wobeiKE∪
wWeiterhin sind einige einführende Definitionen erforderlich: Seien ein Vorverknüpfer-ergänztes EPK-Schema A′ und die Menge K ′ als Menge aller Knoten dieses EPK-Schemas gegeben.ist ein Zustand des EPK-Schemas Zur Beschreibung der Dynamik einer EPK wird weiterhin zunächst die EPK-Instanz eingeführt, die eine Instanz zu einem gegebenen Schema darstellt und der daher ein konkreter Zustand zugeordnet ist.
Definition 2.8 (Zustand eines EPK-Schemas) MS K S ′ ∈ A′ .Falls ein Elemente∈K′des EPK-Schemas in einem ZustandSenthalten und somite ∈Sist, wird e als aktiviert inSbezeichnet. Für Ereignisse bedeutet dies anschau-lich, dass sie eingetreten sind, und für Funktionen, dass sie sich gerade in Ausführungbefinden.Definition 2.9 (EPK-Instanz) SeiSein Zustand des EPK-SchemasA′ . Eine EPK-Instanz I ist ein TupelI=, ( S A ′).Zur Definition der Semantik muss exakt festgelegt werden, welche Zustände von einer gegebenen EPK-Instanz ) , ( S A I ′ = im nächsten Schritt erreicht werden können.Gesucht ist somit eine Transitionsrelation TR⊆KMS K × ′MS ′für ein EPK-Schema A′ ,die einem ZustandSeinen FolgezustandS ′ zuordnet, so dass (S,S′)∈TRgilt.Anschaulich wird dafür im folgendenS S TR ′ →geschrieben. Anhand dieserTransitionsrelation kann der Übergang einer EPK-InstanzI=, ( S A ′)in einenFolgezustand S ′ ermittelt werden.Zur Einführung der Transitionsrelation→TRwird ein Vorverknüpfer-ergänztes EPK-Schema vorausgesetzt. SeiS=(K, ′mS)ein Zustand und a S ∈ .sei dieMultimenge, die nur das Elemententhält ( b) und für dieist. Die Transitionsrelation → wird folgendermaßen definiert:
n
Im folgenden beziehen sich die Multimengen der direkten Vorgänger und Nachfolger auf die Mengen K' und C'.
beabsichtigt sein. Derartige Überlegungen sind Gegenstand von Validierungs-und Verifikationskonzepten und erfordern Formalismen zur Definition und zum Nachweis allgemeiner Eigenschaften eines EPK-SchemasAufgrund der Semantikdefinition der Verknüpfungsoperatoren kann man leicht eine Kontrollflusslogik beschreiben, die innerhalb einer EPK-Instanz zu einer Unter-bzwDiese kann als Grundlage zur Formalisierung des Zeit-, Mengen-und Ressourcenkonzeptes dienen. Alle Konzepte gemeinsam bieten dann eine valide Grundlage für eine integrierte Geschäftsprozessarchitektur zur Konzeption und Implementierung betriebswirtschaftlicher und (informations-)technischer EPK-Anwendungen (Geschäftsprozesssimulation, Prozesskostenrechnung, Workflowmanagement etcEin weiterer wichtiger Nutzen liegt in der Bereitstellung adäquater Modellierungskonventionen und Verifikations-und TransformationsverfahrenZur Bündelung der Forschungsaktivitäten haben die Autoren des Beitrages die Gründung des Arbeitskreis "Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten (WI-EPKim Fachbereich Wirtschaftsinformatik der Gesellschaft für InformatikFormalization and Verification of Event-driven Process ChainsWM PVan Der AalstComputing Science Reports 98/01RCBackhouseJC MBaetenEindhoven1998Eindhoven University of TechnologyFormalization and Verification of Event-driven Process ChainsWM PVan Der AalstInformation and Software Technology411999. 2002-08-15JBeckerRosemannMSchütteGGrundsätze ordnungsmäßiger Modellierung199537Modellierung von Prozeßketten mittels Petri-Netz-TheorieRChenA.-WScheerVeröffentlichungen des Instituts für WirtschaftsinformatikScheer, A.-W.1071994Four Systematic Steps Towards Sound Business Process ModelsJDehnertProceedings of the 2nd International Colloquium on Petri Net Technologies for Modelling Communication Based Systemsthe 2nd International Colloquium on Petri Net Technologies for Modelling Communication Based SystemsBerlinFraunhofer Gesellschaft ISST2001. 2002-08-15Relaxed Soundness of Business ProcessesJDehnertPRittgenProceedings of the 13th Conference on Advanced Information Systems Engineering (CAISE'01KLDittrichAGeppertMCNorriethe 13th Conference on Advanced Information Systems Engineering (CAISE'01Interlaken, SwitzerlandSpringer2001. 2002-08-15LNCS 2068Grammatikbasierte Beschreibung von Geschäftsprozessen -Methodik für das strukturierte Verarbeiten von ModellenIHeimig2002Deutscher UniversitätsverlagWiesbadenÜberführung strukturierter Modellierungsmethoden in die Object Modelling Technique (OMT)WHoffmannA.-WScheerMHoffmannVeröffentlichungen des Instituts für WirtschaftsinformatikScheer, A.-W.1141995GKellerPartnerSAP/ R3 prozeßorientiert anwenden. Iteratives Prozeß-Prototyping mit Ereignisgesteuerten Prozeßketten und Knowledge MapsBonn et al1999Semantische Prozeßmodellierung auf der Grundlage "Ereignisgesteuerter Prozeßketten (EPK)GKellerMNüttgensA.-WScheerVeröffentlichungen des Instituts für WirtschaftsinformatikScheer, A.-W.891992. 2002-08-15Ereignisgesteuerte Prozeßketten und Petri-NetzePLangnerCSchneiderJWehlerBericht Nr. 196RValkMJantzenHamburg1997. 2002-08-15Fachbereich Informatik der Universität HamburgProzeßmodellierung mit ereignisgesteuerten Prozeßketten (EPKs) und Petri-NetzenPLangnerCSchneiderJWehlerWirtschaftsinformatik3951997Ereignisgesteuerte Prozeßketten (EPKs) und Petri-NetzePLangnerCSchneiderJWehlerGrundlagen der Parallelität, Workshop der GI-Fachgruppen 0JDeselHReichelDresden1997Technische Berichte der TU Dresden, Fakultät Informatik0.1 und 0.1.7 im Rahmen der INFORMATIK`97Relating Event-Driven Process Chains to Boolean NetsPLangnerCSchneiderJWehler9707. 1997. 2002-08-15Ludwig-MaximiliansMünchenUniversität München ; Institut für Informatik, Technischer BerichtPetri Net Based Certification of Event driven Process ChainsPLangnerCSchneiderJWehlerApplication and Theory of Petri Nets 1998Lecture notes in Computer Scienceet alBerlinSpringer19981420Ereignisgesteuerte Prozeßketten und Petrinetze zur Modellierung von WorkflowsDMoldtJRodenhagenVisuelle Verhaltensmodellierung verteilter und nebenläufiger Software-Systeme, ProceedingsHGieseSPhilippiMünster; Münster13. November 2000. 2000. 2002-08-15Objektorientierte Softwareentwicklung. Bericht Nr. 24/00-IMMollFormalisierung und Konsistenzprüfung des R/3-ReferenzmodellsClausthal1996TU Clausthal (Prof. Möller)Diplomarbeit im Studiengang Informatik an derVom Prozessmodell zum Elektronischen GeschäftsprozessPRittgenArbeitsberichte des Instituts für WirtschaftsinformatikFrank, U.Hampe, F.171999. 2002-08-15Modified EPCs and Their Formal SemanticsPRittgenArbeitsberichte des Instituts für WirtschaftsinformatikFrank, U.Hampe, F.191999. 2002-08-15Objektorientierte Analyse mit EMKPRittgenModellierung betrieblicher Informationssysteme, Proceedings der MobIS-Fachtagung 1999EJSinzBamberg10. 1999. 1999. 2002-08-1514From Process Model to Electronic Business ProcessPRittgenEuropean Conference on Information Systems ECIS 1999Copenhagen, DenmarkJune 23 -25. 1999. 2002-08-15II616Copenhagen Business SchoolPaving the Road to Business Process AutomationPRittgenEuropean Conference on Information Systems (ECIS) 2000Vienna, AustriaJuly 3 -5, 2000. 2002-08-15EMC -A Modeling Method for Developing Web-based ApplicationsPRittgenInternational Conference of the International Resources Management Association (IRMA) 2000Anchorage, Alaska, USAMay 21 -24, 2000. 2002-08-15Quo vadis EPK in ARIS? Ansätze zu syntaktischen Erweiterungen und einer formalen SemantikPRittgenWIRTSCHAFTSINFORMATIK422000. 2002-08-15JRodenhagenDarstellung ereignisgesteuerter Prozeßketten (EPK) mit Hilfe von PetrinetzenHamburg1997Diplomarbeit Universität Hamburg Fachbereich Informatik (Prof. Valk)Komplexitätsmanagement in Prozeßmodellen -Methodenspezifische Gestaltungsempfehlungen für die InformationsmodellierungMRosemannSchriften zur EDV-orientierten BetriebswirtschaftslehreA.-WScheerWiesbadenGabler1996Dissertation Universität MünsterEreignisgesteuerte Prozeßketten zur formal fundierten GeschäftsprozeßmodellierungFJRumpInformationssystem-Achitekturen19955F JRumpErreichbarkeitsgraphbasierte Analyse ereignisgesteuerter ProzeßkettenOldenburg1997Technischer Bericht Fachbereich Informatik Universität OldenburgAnalysis of business process descriptionsFJRumpProceedings of the 17 th Annual Database Conference DATASEM´97JPokornythe 17 th Annual Database Conference DATASEM´97Brno, Czech republicOctober 1997Analyse ereignisgesteuerter Prozeßketten (EPK)FJRumpGrundlagen der Parallelität, Workshop der GI-Fachgruppen 0.0JDeselHReichelDresden1997Technische Berichte der TU Dresden, Fakultät Informatik.1 und 0.1.7 im Rahmen der INFORMATIK´97FRumpGeschäftsprozeßmanagement auf der Basis ereignisgesteuerter Prozeßketten -FormalisierungStuttgart et alTeubner1999Analyse und Ausführung von EPKsA.-WScheerARIS -Vom Geschäftsprozeß zum AnwendungssystemBerlin et alSpringer1998Aufl.A.-WScheerARIS -Modellierungsmethoden, Metamodelle, AnwendungenBerlin et alSpringer20014. AuflChrUthmannNutzenpotentiale der Petrinetztheorie für die Erweiterung der Anwendbarkeit Ereignisgesteuerter Prozeßketten, Workshop der Arbeitsgruppe "Formalisierung und Analyse Ereignisgesteuerter Prozeßketten (EPK)Oldenburg1997. 2002-08-15Universität OldenburgMachen Ereignisgesteuerte Prozeßketten (EPK) Petrinetze für die Geschäftsprozeßmodellierung obsolet?ChrUthmannMitteilungen der GI-Fachgruppe "Entwicklungsmethoden für Informationssysteme und deren AnwendungEmisa Forum19981Entwicklung objektorientierter Analysemodelle für Informationssysteme auf Grundlage von ProzessmodellenMVolkmer1997Shaker; AachenGWeikumDWodtkeAKotz DittrichPMuthJWeißenfelsSpezifikation, Verifikation und verteilte Ausführung von Workflows in MENTORInformatik Forschung und EntwicklungBerlin et alSpringer1997. 1997112Modellbildung und Architektur von verteilten Workflow-Management-SystemenDWodtke1997InfixSankt AugustinFrom Business Modelling to Workflow Management: An Integrated ApproachOZukunftFRumpBusiness Process ModellingBScholz-ReiterEStickelBerlin et alSpringer1996