Untersuchung von Komplexitätsmetriken graphischer Geschäftsprozessmodelle

Transkript

1 Universität Leipzig Institut für Informatik Lehrstuhl für Angewandte Telematik / e-business Prof. Dr. Volker Gruhn Diplomarbeit Untersuchung von Komplexitätsmetriken graphischer Geschäftsprozessmodelle Autor: Frank Meyer Matrikelnummer: Studiengang: Informatik (Diplom) Betreuer: Erstgutachter: Dipl.-Math. Ralf Laue Prof. Dr. Volker Gruhn Eingereicht am: 22. November 2006

2

3 Zusammenfassung Geschäftsprozessmodelle werden häufig als Kommunikationsmittel über Geschäftsprozesse eingesetzt. Verständnisfehler durch Modelle können dabei zu Folgefehlern bei der Umsetzung der Geschäftsprozesse führen. Diese Arbeit beschäftigt sich mit Metriken zur Beurteilung der Verständlichkeit von Geschäftsprozessmodellen. Dabei wird sich auf Modellierungselemente zum Kontrollfluss beschränkt. Es werden sowohl bereits veröffentlichte Metriken als auch einige neue vorgestellt. Die Arbeit orientiert sich an der Syntax von Ereignisgesteuerten Prozessketten (EPK) und geht auf einige Besonderheiten von UML 2-Aktivitätsdiagrammen ein. Die Metriken sind aber weitestgehend auch auf andere Modellierungssprachen übertragbar. Einige der Metriken werden mit Hilfe von Axiomen für Softwarekomplexitätsmetriken theoretisch validiert. Ebenfalls wird eine Implementation der Metriken für EPK-Modelle vorgestellt, die im Rahmen der Arbeit entstanden ist. Anhand von EPK-Modellen aus der Praxis erfolgt eine praktische Validierung der Metriken. Diese umfasst zum einen eine Korrelationsanalyse zwischen den Metriken. Zum anderen erfolgt mit Hilfe von logistischen Regressionen eine Analyse des Zusammenhangs zwischen der Komplexität der Modelle und semantischen Modellfehlern.

4 Inhaltsverzeichnis 1 Einführung Motivation Zielsetzung Einordnung in der Literatur Aufbau der Arbeit Geschäftsprozesse und Geschäftsprozessmodellierung Begriffserklärung Ereignisgesteuerte Prozesskette (EPK) UML 2 Aktivitätsdiagramm Komplexität Was ist Komplexität? Gründe zum Messen von Komplexität Kriterien für Komplexitätsmetriken Validierung von Komplexitätsmetriken Komplexitätsmetriken Umfangsmetriken Verhältnismetriken Umfangsmetriken für UML 2-Aktivitätsdiagramme Metriken zu Zyklen Metriken zum Kontrollfluss Verschachtelungstiefe Metrik zur Unstrukturiertheit Metriken zum Informationsfluss Informationsfluss innerhalb eines Modells Informationsfluss bei hierarchischen Modellen Frank Meyer

5 4.7 Metriken zum graphischen Layout Weitere Metriken Zusammenfassung Theoretische Validierung 64 6 Implementierung der Metriken Integration in den EPK-Editor EPCTools Batchprogramm Datenmodell Implementation der Metriken Schnittstellen Praktische Validierung Auswahl der EPK-Modelle Logistische Regression Korrelationsanalyse zwischen den Metriken Logistische Regressionsanalyse Probleme und Bewertung der Validierung Bewertung 97 A Semantische Eigenschaften von EPK-Modellen 98 B Konfigurationsdatei für Batchversion von EPCMetrics 100 C Konfigurationsdatei für Metriken in EPCTools 102 D Ausgabeformat der Metrikresultate 104 E Spearman-Korrelationskoeffizienten der Metriken 105 F Inhalt CD 107 Frank Meyer 3

6 Abbildungsverzeichnis 108 Tabellenverzeichnis 110 Literaturverzeichnis 111 Index 115 Erklärung Frank Meyer

7 1 Einführung 1.1 Motivation Zur Dokumentation von Geschäftsprozessen werden häufig graphische Modelle eingesetzt. Dafür wurden eine Reihe von Modellierungssprachen entwickelt, die unterschiedliche Aspekte eines Geschäftsprozesses wie Kontrollfluss, Datenfluss und Prozessbeteiligte abbilden. Im deutschsprachigen Raum hat sich insbesondere die Ereignisgesteuerte Prozesskette (EPK)[KNS92] als graphische Modellierungssprache etabliert. Weitere etablierte Modellierungssprachen sind u.a. Business Process Modeling Notation (BPMN)[BPM06] und UML-Aktivitätsdiagramme[OMG05]. Geschäftsprozessmodelle dienen dabei vor allem als Kommunikationsmittel über Geschäftsprozesse. Insbesondere werden sie auch in einer frühen Phase bei der Neuimplementierung und Reorganisation von Geschäftsprozessen verwendet. Verständnisfehler, die aus den Modellen von Geschäftsprozessen entstehen, können zu Folgefehlern in den nächsten Stufen des Prozessdesigns und bei der Implementierung der Prozesse führen. Deshalb sollten Geschäftsprozessmodelle möglichst leicht verständlich sein. Um den Grad der Verständlichkeit messen zu können, sind Metriken notwendig, die sich automatisiert berechnen lassen. Den Grad der Verständlichkeit eines Modells bezeichnen wir als Komplexität. Für die Softwareentwicklung sind seit den 1970er Jahren eine Vielzahl an Komplexitätsmetriken vorgestellt worden, die die Verständlichkeit von Programmcode messen[kan02, FP97]. Einige dieser Metriken werden in der Praxis erfolgreich eingesetzt. Viele der Komplexitätsmetriken für Programmcode basieren auf dem Kontrollflussgraphen eines Programms. Zwischen Kontrollflussgraphen und Graphen von Geschäftsprozessmodellen gibt es Parallelen. Deshalb ist es sinnvoll zu betrachten, welche Komplexitätsmetriken für Programme sich auf Geschäftsprozessmodelle übertragen lassen. Einige Komplexitätsmetriken für Geschäftsprozessmodelle sind bereits vorgeschlagen worden. Wir werden auf die einzelnen Veröffentlichungen in Kapitel 1.3 eingehen. Die meisten Metriken nehmen dabei Bezug auf Komplexitätsmetriken aus der Softwareentwicklung. 1.2 Zielsetzung Ziel der Arbeit ist die Definition, Implementierung und Validierung von Komplexitätsmetriken für Geschäftsprozessmodelle. Bei der Betrachtung der Komplexität eines graphischen Geschäftsprozessmodells kann unterschieden werden zwischen der syntaktischen Struktur, dem graphischen Layout und der inhaltlichen Struktur. Im Rahmen dieser Arbeit beschränken wir uns auf die Definition von Komplexitätsmetriken zur syntaktischen Struktur und zum graphischen Layout eines Modells. Dabei betrachten wir nur diejenigen Modellelemente, die zur Darstellung des Kontrollflusses eines Geschäftsprozesses dienen. Andere Modellierungsaspekte wie Daten- Frank Meyer 5

8 fluss und die Nutzung von Ressourcen werden in dieser Arbeit nicht berücksichtigt. Zwar gibt es zwischen den unterschiedlichen Modellierungssprachen für Geschäftsprozesse viele Gemeinsamkeiten bezüglich der Syntax, aber auch Unterschiede im Detail. In dieser Arbeit werden die Metriken in erster Linie für EPK-Modelle definiert. Zusätzlich wird auf einige Besonderheiten von UML 2- Aktivitätsdiagrammen eingegangen. Die meisten der Metriken lassen sich auch auf andere Modellierungssprachen übertragen, dies ist aber jeweils im Einzelfall zu prüfen. Die Implementierung der Metriken erfolgt für EPK-Modelle. Dabei wird zum einen ein Batchprogramm implementiert, das die Metriken für EPK-Modelle im XML-basierten Austauschformat EPML[MN05] berechnen kann. Ebenfalls wird eine Integration der Metriken in das Modellierungstool für EPK-Modelle EPCTools[CK] erfolgen. Zur Zeit existieren unserem Wissen nach keine Tools zur Berechnung von Metriken für EPK- Modelle. Auch bei anderen Modellierungssprachen von Geschäftsprozessen existieren bislang nur für UML-Aktivitätsdiagramme Tools, die einige Größenmetriken sowie Stilmetriken berechnen[gro04, SDM]. Einige der Metriken werden wir theoretisch validieren mit Hilfe von Eigenschaften, die für Software-Komplexitätsmetriken verwendet werden[wey88]. Neben der theoretischen Validierung erfolgt für den Großteil der in der Arbeit vorgestellten Metriken eine praktische Validierung. Die praktische Validierung erfolgt anhand semantischer Fehlern von EPK-Modellen aus Unternehmen und Veröffentlichungen. Die EPK-Modelle werden dafür mit Hilfe des Modellierungstools EPCTools digitalisiert und im EPML-Format gespeichert. Bislang existieren nur wenige praktische Validierungen der bereits veröffentlichten Komplexitätsmetriken. 1.3 Einordnung in der Literatur Durch Latva-Koivisto[LK01] erfolgte die erste uns bekannte Veröffentlichung, die sich mit Komplexitätsmetriken für Geschäftsprozessmodelle beschäftigt. Dabei werden einige auf der Graphentheorie basierte Metriken vorgeschlagen, die allerdings noch nicht auf die Besonderheiten der Modellierungssprachen von Geschäftsprozessen eingehen. Aufgrund dieses Mankos werden wir sie in dieser Arbeit nicht berücksichtigen. Cardoso[Car05b] überträgt die aus der Softwareentwicklung bekannte zyklomatische Komplexität[McC76] auf Geschäftsprozessmodelle. Eine theoretische Validierung der Metrik mit Hilfe der in [Wey88] definierten Eigenschaften erfolgte in [Car05a]. Eine praktische Validierung, in der Studenten die Verständlichkeit von Modellen bewerten sollten, wurde in [Car06] veröffentlicht. Die Resultate legen einen Zusammenhang zwischen der Komplexität eines Modells und der Metrik nahe. Ebenfalls validiert wurde die Metrik durch Mendling et al.[mmn + 06] anhand semantischer Fehler von EPK-Modellen aus dem SAP-Referenzmodell. Diese Validierung sieht keinen Zusammenhang zwischen der Fehlerhaftigket der Modelle und der gemessenen Komplexität. 6 Frank Meyer

9 Mendling et al.[mmn + 06] definierten auch einige weitere Metriken für Geschäftsprozessmodelle und dabei speziell für EPK-Modelle. Die meisten der vorgestellten Metriken sind dabei Größenmetriken. Gruhn und Laue[GL06] stellten eine Reihe von Möglichkeiten vor, wie sich Komplexitätsmetriken für Software auf Geschäftsprozessmodelle übertragen lassen. Ein Großteil der in dieser Arbeit definierten Metriken basiert auf diesen Ideen. Cardoso et al.[cmnr06] stellten ebenfalls Möglichkeiten zur Übertragung von Software- Komplexitätsmetriken vor. Rolón Aguilar et al.[argp06b, ARGP06a] stellten einige Größen- und Verhältnismetriken für Modelle in der Modellierungssprache BPMN vor. Mit dem Layout von Modellen beschäftigt sich in allgemeiner Form[AF06, Ama05]. Die Erkennung einiger Layoutprobleme bei UML-Aktivitätsdiagrammen ist in [SDM] implementiert. Dieses Werkzeug ist auch eines der wenigen, das bereits Komplexitätsmetriken implementiert hat, hier in Form von Größenmetriken für Aktivitätsdiagramme. Auch Gronback[Gro04] definierte einige Komplexitätsmetriken für UML- Aktivitätsdiagramme. Neben einfachen Größenmetriken wird hier ebenfalls eine Adaption der zyklomatischen Komplexität aus der Softwareentwicklung[McC76] vorgeschlagen, wobei eine genauere Definition wie auch eine praktische Validierung fehlt. Ein Großteil der vorgeschlagenen Metriken wurde während der Entstehung dieser Diplomarbeit veröffentlicht, was zeigt, dass dies ein aktiver Forschungsbereich ist. Zur Zeit existieren nur wenige praktische Validierungen der vorgeschlagenen Metriken. Auch an öffentlich verfügbaren Implementierungen mangelt es bislang. 1.4 Aufbau der Arbeit In Kapitel 2 wird zuerst darauf eingegangen, was Geschäftsprozesse und graphische Geschäftsprozessmodelle sind sowie die EPK-Notation und UML 2- Aktivitätsdiagramme vorgestellt. In Kapitel 3 definieren wir, was wir unter Komplexität von Geschäftsprozessmodellen verstehen. Ebenso gehen wir genauer darauf ein, weshalb es sinnvoll ist, die Komplexität von Modellen zu messen und stellen Kriterien für Komplexitätsmetriken sowie Möglichkeiten ihrer Validierung vor. Kapitel 4 umfasst mit den Hauptteil der Arbeit. Hier werden die Komplexitätsmetriken vorgestellt. In Kapitel 5 erfolgt eine theoretische Validierung einiger der im vorherigen Kapitel vorgestellten Metriken. Kapitel 6 stellt die Implementierung der Metriken für EPK-Modelle vor. In Kapitel 7 wird auf die praktische Validierung der Metriken eingegangen. In Kapitel 8 erfolgt eine Zusammenfassung und Bewertung der Ergebnisse. Frank Meyer 7

10 2 Geschäftsprozesse und Geschäftsprozessmodellierung 2.1 Begriffserklärung Die unterschiedlichen Definitionen für Geschäftsprozesse lassen sich in solche mit einer eher betriebswirtschaftlich orientierten Sicht und solche mit einer eher technisch orientierten Sicht einteilen. Wir beschränken uns hier auf zwei Definitionen, die eher technisch orientiert sind. Staud[Sta99] definiert einen Geschäftsprozess folgendermaßen: Ein Geschäftsprozess besteht aus einer zusammenhängenden abgeschlossenen Folge von Tätigkeiten, die zur Erfüllung einer betrieblichen Aufgabe notwendig sind. Die Tätigkeiten werden von Aufgabenträgern in organisatorischen Einheiten unter Nutzung der benötigten Produktionsfaktoren geleistet. Teufel et al.[trw99] beschreiben einen Prozess wie folgt: Spricht man von einem Prozess, so stellt man sich einen Ablauf von Teilelementen vor. Die Teilelemente eines Prozesses können Funktionen oder ihrerseits erneut Prozesse sein. Sie sind in einer logischen zeitlichen Reihenfolge angeordnet und geben somit die Bearbeitungsfolge wieder. Ziel eines Geschäftsprozesses ist also die Erfüllung einer Aufgabe für ein Unternehmen. Diese kann sowohl direkt einen Nutzen für einen Kunden haben (hier spricht man von Kernprozessen), als auch eine unternehmensinternen Unterstützung der Kernprozesse zum Ziel haben (hier spricht man von Unterstützungsprozessen). Zusammengesetzt ist ein Prozess aus einer Menge von einzelnen Tätigkeiten. Die Tätigkeiten stehen in einem logischen zeitlichen Zusammenhang. Teufel spricht hier von Teilelementen, die entweder Funktionen oder selbst Prozesse sind. Funktionen stellen in dieser Bedeutung also Tätigkeiten dar, die sich nicht weiter sinnvoll untergliedern lassen. Geschäftsprozesse können auf unterschiedlichen Abstraktionsniveaus dargestellt werden. Auf dem höchsten Abstraktionsniveau stehen die Hauptprozesse eines Unternehmens wie Vertriebsprozess, Entwicklungsprozess und Beschaffungsprozess. Nach [Bal98] besitzt ein Unternehmen ca. 15 Kern- Geschäftsprozesse. Die Hauptprozesse setzen sich aus Unterprozessen bzw. Teilprozessen zusammen. Eine solche Aufgliederung kann über mehreren Stufen erfolgen. Das unterste Abstraktionslevel besteht dann nur noch aus den von Teufel als Funktionen bezeichneten nicht weiter aufteilbaren Tätigkeiten, wobei auch in den Zwischenstufen einzelne Tätigkeiten nicht weiter sinnvoll aufteilbar sein können. Ein Modell eines Geschäftsprozesses stellt eine Abbildung des Prozesses dar. Es existiert also eine Funktion, die einen Prozess auf eine Repräsentation des Prozesses abbildet. Bei Geschäftsprozessmodellen ist dies üblicherweise eine graphische Repräsentation. Generell stellt ein Modell dabei immer eine Vereinfachung des abgebildeten Prozesses dar. Welche Aspekte eines Prozesses in einem Modell dargestellt werden, hängt vom Zweck des Modells ab. Aspekte sind dabei die einzelnen 8 Frank Meyer

11 Funktionen des Prozesses, die logischen Zusammenhänge zwischen den Funktionen, die beteiligten Organisationseinheiten und Personen des Unternehmens sowie die Daten- und Ressourcenflüsse innerhalb des Prozesses. Das Hauptziel der Modellierung ist die Vereinfachung und Veranschaulichung komplexer Prozessstrukturen. Im Einzelnen lassen sich als Ziele für die Modellierung nennen[ows + 03]: 1. Verständnis: Das Verständnis für einen Geschäftsprozess kann durch ein Modell gefördert werden. 2. Dokumentation: Durch die Dokumentation in einem Modell werden Verantwortlichkeiten festgeschrieben. Auch dient sie für neue Mitarbeiter zur Einarbeitung. Die Dokumentation ist ebenfalls Voraussetzung für Zertifizierungen im Rahmen des Qualitätmanagements wie bspw. durch die ISO 9000:2000ff. 3. Analyse: Mit Hilfe eines Modells können Prozesse analysiert werden. So können z.b. bestimmte Abläufe simuliert werden. 4. Verbesserung: Durch die Analyse eines Modells können Schwachstellen im Geschäftsprozess identifiziert und ggf. verbessert werden. 5. Neuentwurf: In einer frühen Phase bei der Neuimplementierung eines Geschäftsprozesses dient ein Modell zur Kommunikation und Planung. Es existieren zahlreiche Modellierungsmethoden für Geschäftsprozessen. Für die Darstellung des Kontrollflusses sind die bekanntesten Vertreter Petrinetze, die Ereignisgesteuerte Prozesskette (EPK)[KNS92], UML-Aktivitätsdiagramme[OMG05] sowie die Business Process Modeling Notation (BPMN)[BPM06]. Einige dieser Modellierungssprachen bieten die Möglichkeit, weitere Aspekte neben dem Kontrollfluss abzubilden, z.b. den Datenfluss. Häufig wird unterschieden zwischen Geschäftsprozessen und Workflows (Arbeitsabläufe) bzw. zwischen Modellen von Geschäftsprozessen und Modellen von Workflows. Während Geschäftsprozessmodelle die grundsätzliche Struktur des Prozesses veranschaulichen, dienen Modelle von Workflows zur Modellierung auf operativer Ebene, d.h. einer konkreten Darstellung der einzelnen Arbeitsschritte. Ziel ist dabei, zumindest teilweise eine rechnergestützte Automatisierung der Arbeitsschritte zu erreichen[vb96]. Deshalb sind Workflow-Modellierungssprachen wie YAWL[AH05] Bestandteil von Workflow-Systemen, welche für die automatisierte Ausführung der Workflows zuständig sind. Solche Modellierungssprachen haben eine ähnliche Syntax wie Modellierungssprachen von Geschäftsprozessen, einige Modellierungsmethoden wie UML-Aktivitätsdiagramme lassen sich auch für beides verwenden. Aufgrund der ähnlichen Syntax dieser Sprachen kann man Komplexitätsmetriken auch für beide Bereiche verwenden. Frank Meyer 9

12 Abbildung 1: EPK-Symbole 2.2 Ereignisgesteuerte Prozesskette (EPK) Die Ereignisgesteuerte Prozesskette (EPK) wurde 1992 am Institut für Wirtschaftsinformatik der Universität des Saarlands in Zusammenarbeit mit der SAP AG entwickelt[kns92]. Im deutschsprachigen Raum hat sie sich zur Modellierung von Geschäftsprozessen etabliert, und zwar in erster Linie zur Modellierung des Kontrollflusses eines Geschäftsprozesses. Sie ist Bestandteil des ARIS-Toolsets (Architektur integrierter Informationssysteme), einem Werkzeug für das Geschäftsprozessmanagement in einem Unternehmen[IDS]. Ebenfalls ist sie Bestandteil der SAP- Referenzmodelle. Eine EPK bzw. ein EPK-Modell lässt sich als ein gerichteter Graph G = (K, A) beschreiben. Die Knotenmenge einer EPK unterteilt sich in Knoten unterschiedlicher Typen, namentlich in Ereignisse, Funktionen, Prozesswegweiser und Verknüpfungsoperatoren. Verknüpfungsoperatoren sind wiederum untergliedert in XOR- Operatoren, OR-Operatoren und AND-Operatoren. Die Kanten des Graphen werden als Kontrollflusskanten bezeichnet. Die graphische Darstellung der einzelnen Knoten und der Kanten ist in Abb. 1 dargestellt. Ereignisse stellen passive Elemente einer EPK dar. Sie beschreiben Zustände, die durch die Ausführung vorhergehender Funktionen erreicht werden bzw. die Vorbedingung zur Ausführung nachfolgender Funktionen sind. Funktionen beschreiben aktive Elemente einer EPK, sie beschreiben ein zeitverbrauchendes Geschehen. Verknüpfungsoperatoren dienen zur Steuerung des Kontrollflusses. Sie drücken bspw. aus, welche Ereignisse eine Funktion als Ergebnis erreichen bzw. erzeugen kann und welche Ereignisse eine Funktion auslösen können. Sie werden in folgende Typen unterschieden: 1. XOR-Operator: Ein XOR-Operator kennzeichnet eine disjunkte Verknüpfung, die Semantik entspricht einem logischen exklusiven OR. 10 Frank Meyer

13 Abbildung 2: Ein einfaches EPK-Modell 2. OR-Operator: Ein OR-Operator kennzeichnet eine adjunkte Verknüpfung, die Semantik entspricht einem logischen OR. 3. AND-Operator: Ein AND-Operator kennzeichnet eine konjunkte Verknüpfung, die Semantik entspricht einem logischen AND. Prozesswegweiser dienen zur Aufteilung eines EPK-Modells in mehrere Teilmodelle in horizontaler Sicht. Sie stellen einen Verweis auf ein anderes Teilmodell dar. Ein einfaches Beispiel einer EPK ist in Abb. 2 dargestellt. Neben diesen Grundelementen der ursprünglichen Definition einer EPK gibt es eine Reihe von Erweiterungen, die vor allem zur Darstellung zusätzlicher Prozessaspekte neben dem Kontrollfluss dienen. Diese werden häufig in der Literatur unter dem allerdings nicht einheitlich verwendeten Begriff eepk (erweiterte EPK) beschrieben. Solche Erweiterungen, die teils auch aus anderen Modellierungssprachen für Geschäftsprozesse bekannt sind, betreffen z.b. Informationsflüsse, Organisationseinheiten und einen Sequenz-Verknüpfungsoperator. Zwar ist es offensichtlich, dass diese Erweiterungen die Komplexität von EPK-Modellen erhöhen können, aber sie können im Rahmen dieser Arbeit nicht berücksichtigt werden, zumal nur ein Teil der EPK-Modelle in der Praxis Erweiterungen überhaupt verwendet. Bevor wir zur Syntaxdefinition von EPKs kommen, wollen wir einige Schreibweisen und Begriffe zu Graphen einführen, die wir in dieser Arbeit verwenden: 1. Falls zwischen zwei Knoten k 1 und k 2 eine Kante existiert, so schreiben wir dies wie folgt: k 1 k Eine Folge von Knoten k 1,..., k n heißt Pfad oder Weg, falls für alle i, 1 i < n Frank Meyer 11

14 eine Kante k i k i+1 existiert Ein Knoten k 1 heißt Vorgänger eines Knoten k 2, falls ein Pfad von k 1 zu k 2 existiert. 4. Ein Knoten k 1 heißt direkter Vorgänger eines Knoten k 2, falls es eine Kante k 1 k 2 gibt. 5. Ein Knoten k 1 heißt Nachfolger eines Knoten k 2, falls ein Pfad von k 2 zu k 1 existiert. 6. Ein Knoten k 1 heißt direkter Nachfolger eines Knoten k 2, falls es eine Kante k 2 k 1 gibt. 7. Ein Zyklus ist ein Pfad, bei dem erster und letzter Knoten gleich sind. Da wir zwei Zyklen, die die gleichen Knoten besitzen, auch unabhängig von einem Start- und Endknoten der jeweiligen Pfade als gleich ansehen wollen, definieren wir einen Zyklus K cycle anhand seiner Knotenmenge: K cycle = {k 1,..., k n K k 1 k n k 1 } 8. Ein elementarer Zyklus (oder einfacher Zyklus) ist ein Zyklus, bei dem jeder Knoten außer dem Start- und Endknoten nur einmal vorkommt. Da wir wiederum zwei elementare Zyklen als gleich betrachten, wenn sie die gleichen Knoten besitzen, definieren wir einen elementaren Zyklus K cycle wie folgt: K cycle = {k 1,..., k n K k 1 k n k 1 k i, k j, 1 i, j n, i j : k i k j } Die Syntax von EPKs ist nicht einheitlich formalisiert, deshalb finden sich teils leicht unterschiedliche Syntaxdefinitionen. Die hier verwendete Definition einer EPK orientiert sich weitestgehend an der Definition von Nüttgens und Rump[NR02]. Allerdings verzichten wir auf einige Anforderungen an eine syntaktisch korrekte EPK, wie der Forderung, dass direkt nach Ereignissen keine XOR-/OR-Splitoperatoren folgen dürfen. Definition 2.1 (Ereignisgesteuerte Prozesskette (EPK)) Ein EPK-Modell M ist ein Graph G = (K, A) mit der Knotenmenge K und der Kantenmenge A K K und wird durch ein Tupel M = (E, F, P, V, A) beschrieben, für das gilt: E K ist eine Menge von Ereignissen F K ist eine Menge von Funktionen P K ist eine Menge von Prozesswegweisern 1 In der Graphentheorie wird manchmal zwischen Weg und Pfad unterschieden. Ein Pfad (oder ein Weg) wird teilweise als zyklenfreier Weg (oder Pfad) definiert. Wir verzichten hier auf eine solche Unterscheidung. Falls ein Weg bzw. Pfad zyklenfrei sein soll, schreiben wir dies explizit. 12 Frank Meyer

15 V K ist eine Menge von Verknüpfungsoperatoren mit den paarweise disjunkten Teilmengen V AND, V OR und V XOR E, F, P und V sind paarweise disjunkt Damit eine EPK syntaktisch korrekt ist, müssen zusätzlich folgende Eigenschaften erfüllt sein: 1. G ist ein gerichteter und zusammenhängender Graph. 2. Zwischen zwei Knoten aus G existiert maximal eine Kante. 3. G ist endlich. 4. E ist keine leere Menge. 5. F ist keine leere Menge. 6. Alle Funktionen besitzen genau eine eingehende und eine ausgehende Kante. 7. Alle Ereignisse besitzen maximal eine eingehende und eine ausgehende, insgesamt jedoch mindestens eine Kontrollflusskante. Falls ein Ereignis keine eingehende Kante hat oder nur Prozesswegweiser und Verknüpfungsoperatoren als Vorgänger, wird es Startereignis genannt. Falls ein Ereignis keine ausgehende Kante hat oder nur Prozesswegweiser und Verknüpfungsoperatoren als Nachfolger, wird es Endereignis genannt. Falls ein Ereignis weder Startereignis noch Endereignis ist, wird es auch als internes Ereignis bezeichnet. 8. Alle Prozesswegweiser haben entweder eine eingehende oder eine ausgehende Kontrollflusskante, aber nicht beides zugleich. 9. Alle Verknüpfungsoperatoren besitzen entweder eine eingehende und mehrere ausgehende Kontrollflusskanten, dann werden sie als Split-Operatoren bezeichnet, oder mehrere eingehende und eine ausgehende Kontrollflusskante, dann werden sie als Join-Operatoren bezeichnet. 10. G enthält keine Zyklen, die nur aus Verknüpfungsoperatoren bestehen. 11. Ereignisse sind nur mit Funktionen und Prozesswegweisern verbunden, ggf. über Verknüpfungsoperatoren. 12. Funktionen und Prozesswegweiser sind nur mit Ereignissen verbunden, ggf. über Verknüpfungsoperatoren. 13. Es gibt mindestens ein Startereignis und ein Endereignis. 14. Jeder Knoten hat ein Startereignis oder einen Prozesswegweiser als Vorgänger oder ist selbst Startereignis oder Prozesswegweiser. 15. Jeder Knoten hat ein Endereignis oder einen Prozesswegweiser als Nachfolger oder ist selbst Endereignis oder Prozesswegweiser. Frank Meyer 13

16 Abbildung 3: EPK-Modell mit totem Bereich Zur hier verwendeten Definition sei anzumerken, dass in einem EPK-Modell Startereignisse nicht zwangsläufig Ereignisse ohne eine eingehende Kante sein müssen, wenn das Modell durch Prozesswegweiser aufgeteilt ist. Zu den Startereignissen zählen dann ebenso solche Ereignisse, die von Prozesswegweisern ohne eingehende Kante erreicht werden können, ohne dabei andere Knoten als Verknüpfungsoperatoren zu durchlaufen. Wir bezeichnen die Menge der Startereignisse ohne eingehende Kante und der Prozesswegweiser ohne eingehende Kante als Startknoten. Gleiches gilt für Endereignisse, zu denen ebenfalls solche Ereignisse zählen, die mit Prozesswegweisern ohne ausgehende Kontrollflusskante verbunden sind, ohne andere Knoten als Verknüpfungsoperatoren zu durchlaufen. Die Menge der Endereignisse ohne ausgehende Kante und der Prozesswegweiser ohne ausgehende Kante bezeichnen wir auch als Endknoten. Die Eigenschaften 14 und 15 sind in [NR02] nicht erwähnt. Ein Modell, das diese Eigenschaften verletzt, ist in Abb. 3 dargestellt. Durch Verletzung dieser Eigenschaften entstehen sogenannte tote Bereiche ( dead parts ). Dies sind Bereiche im Modell, die nie von einem Startereignis aus erreicht werden können oder von denen aus nie ein Endereignis erreichen kann. Wir verbieten solche Bereiche hier explizit, da sie für einige der Komplexitätsmetriken Schwierigkeiten bereiten. Auch ist davon auszugehen, dass Modelle mit solchen Bereichen in der Praxis keine Rolle spielen, da sie wenig sinnvoll sind. Die Definition von [NR02] berücksichtigt zusätzlich noch die Menge der gültigen Startbelegungen, die ein EPK-Modell besitzt. Eine Startbelegung ist eine Menge von Startereignissen, die bei Ausführung einer Instanz der zugehörigen EPK mit Token belegt werden. Nicht alle möglichen Mengen von Startereignissen sind zwangsläufig gültige Startbelegungen. Zwar kann in der Anzahl und Zusammensetzung an gültigen (und möglichen) Startbelegungen auch ein Aspekt der Komplexität eines Modells gesehen werden. Allerdings sind die gültigen Startbelegungen üblicherweise nicht formal aus einem EPK-Modell ersichtlich, sondern nur informell über eine 14 Frank Meyer

17 Interpretation der Startereignisse. Deshalb verzichten wir auf die Berücksichtigung dieses Aspekts, da eine mögliche Metrikberechnung nicht automatisiert erfolgen kann. EPK-Modelle können aus Gründen der Übersichtlichkeit in mehrere Teilmodelle zerlegt werden. Dies kann zum einen durch eine horizontale Aufteilung mit Hilfe von Prozesswegweisern erfolgen, wie sie in der Syntaxdefinition bereits berücksichtigt sind. Eine vertikale Aufteilung der Modelle kann durch eine Hierarchisierung erfolgen. Die Hierarchisierung erfolgt bei EPK-Modellen durch eine sogenannte Funktionsverfeinerung. Eine Funktion kann dabei durch ein Detailmodell genauer beschrieben werden. Die direkt der Funktion vorhergehenden Ereignisse dienen im Detailmodell als Startereignisse, die direkt folgenden Ereignisse dienen im Detailmodell als Endereignisse. Eine hierarchische Funktion ist also eine Funktion, die auf ein anderes Teilmodell verweist. [NR02] definieren zusätzlich einige Eigenschaften, die hierarchische Funktionen erfüllen müssen, wie Zyklenfreiheit zwischen den damit verbundenen Teilmodellen. Wir verzichten hier darauf, da hierarchische Funktionen für unsere Metriken keine große Bedeutung haben. 2.3 UML 2 Aktivitätsdiagramm Die Unified Modeling Language (UML) ist eine standardisierte Familie graphischer Notationen, die auf einem gemeinsamen Metamodell beruhen. Die graphischen Notationen dienen in erster Linie zur Beschreibung von Softwaresystemen, insbesondere von objektorientierten Softwaresystemen. Es gibt unterschiedliche Sprachversionen von UML, zur Zeit ist Version 2 (UML 2) die aktuelle, die sich teilweise stark von der Vorgängerversion UML 1.X unterscheidet. Auf Grundlage der graphischen Notation sind diverse Diagrammtypen definiert, im UML 2-Standard insgesamt 13[OMG05]. Diese Diagrammtypen lassen sich in Strukturdiagramme und Verhaltensdiagramme unterscheiden, auch wenn es eine solche Einteilung offiziell nicht existiert und die Grenzen teilweise nicht eindeutig sind. Aktivitätsdiagramme sind ein Diagrammtyp von UML und können zur Modellierung von Geschäftsprozessen eingesetzt werden. Zwar waren Aktivitätsdiagramme bereits in der UML-Version 1.X Bestandteil des Standards, aber sowohl Notation als auch Semantik und Begriffe unterlagen in UML 2 starken Veränderungen. Wir werden uns im Rahmen dieser Arbeit an die Semantik und Begrifflichkeit der UML 2- Aktivitätsdiagramme halten. Das Aktivitätsdiagramm ist eines der komplexesten Diagrammtypen von UML und wesentlich umfangreicher als die EPK-Notation. Wir beschränken uns in diesem Abschnitt auf die Beschreibung der wichtigsten Notationselemente für den Kontrollfluss in einem Aktivitätsdiagramm. Da wir in den späteren Abschnitten für Beispielmodelle generell auf die EPK-Notation zurückgreifen, sei hier auf die graphische Repräsentation der Notation von Aktivitätsdiagrammen verzichtet. Ein Modell bzw. ein Teilmodell, falls es zusammengesetzt ist, wird als Aktivität bezeichnet. Zentrales Notationselement sind die Aktionen, die den Funktionen einer Frank Meyer 15

18 EPK entsprechen (in UML 1.X wurden diese Knoten selbst als Aktivitäten bezeichnet). An Verknüpfungsoperatoren stehen XOR-Splits (decision nodes), AND-Splits (fork nodes), XOR-Joins (branch nodes) und AND-Joins (join nodes) zur Verfügung. OR-Operatoren, wie sie bei EPKs bekannt sind, stehen bei Aktivitätsdiagrammen nicht direkt zur Verfügung. Bei XOR-Splitoperatoren können Bedingungen (guards) zur Auswahl des ausgehenden Kontrollflusses angegeben werden, diese sollten sich aber gegenseitig ausschliessen und entsprechen damit nicht einem OR-Split. Eine ähnliche Bedingungsangabe (Join Spezifikation) ist auch bei AND-Joinoperatoren möglich, die u.a. die Konstruktion von OR-Joins ermöglicht. Während bei UML 1.X-Aktivitätsdiagrammen zu einem Split-Operator noch ein entsprechendes Gegenstück in Form eines Join-Operators existieren musste, ist dies bei Aktivitätsdiagrammen in UML 2 nicht mehr der Fall. Dies entspricht den Regeln von EPKs, ist aber sicherlich nicht für die Verständlichkeit eines Modells förderlich. Eine Aktion kann auch selbst mehrere eingehende Kontrollflusskanten oder mehrere ausgehende Kontrollflusskanten besitzen, was semantisch einem AND-Join bzw. einem AND- Split entspricht. Auch hier unterscheidet sich die Semantik bei UML 2 von der bei UML 1.X. Ein Aktivitätsdiagramm kann mehrere Startknoten besitzen. Bei Ausführung einer Aktivität sind alle Startknoten mit Tokens belegt. Die Semantik entspricht also nicht der von EPKs, wo dies durch Startbelegungen festgelegt wird. Bei Endknoten wird unterschieden zwischen Endknoten von Kontrollflüssen, die nicht die Aktivität selber beenden, und Endknoten der Aktivität. Falls ein Token einen Aktivitätsendknoten erreicht, wird die gesamte Aktivität beendet, auch wenn noch andere Token vorhanden sind. Dies ist wiederum ein Unterschied zu EPKs. Eine Möglichkeit der Aufteilung eines Aktivitätsdiagramms in mehrere Teilmodelle bzw. Aktivitäten besteht durch die Verknüpfung von Aktionen mit Aktivitäten. Bei Erreichen einer Aktion wird also die verwiesene Aktivität ausgeführt. Dies entspricht den hierarchisierten Funktionen bei EPKs. Weiterhin erlauben Aktivitätsdiagramme die Modellierung von Ausnahmen (Exceptions). Ausnahmen werden an ausgehenden Kanten von Aktionen dargestellt. Bei Ausführung einer Ausnahme geht der Kontrollfluss nur über die entsprechende Kante weiter, andere ausgehende Kanten werden nicht berücksichtigt. Zusätzlich können zusammenhängende Teile von Aktivitäten zu Bereichen zusammengefasst werden. Dadurch können sogenannte unterbrechbare Bereiche modelliert werden. Deren Ausführung kann durch Ausnahmen unterbrochen werden, d.h. bei Auslösung einer Ausnahme werden alle Token innerhalb des unterbrechbaren Bereichs zerstört und der Kontrollfluss geht beim Ziel der Ausnahme, das außerhalb des unterbrechbaren Bereichs liegt, weiter. 16 Frank Meyer

19 3 Komplexität 3.1 Was ist Komplexität? In diesem Abschnitt soll vorgestellt werden, was im Rahmen dieser Arbeit unter Komplexität von Geschäftsprozessmodellen verstanden wird. Da für eine Reihe der später definierten Metriken Anleihen bei Komplexitätsmetriken für Softwareprogramme gemacht werden, wird im Folgenden betrachtet, was unter Komplexität bzw. Komplexitätsmetriken dort verstanden wird. Generell ist das Ziel, die Qualität von Software anhand des Programmcodes zu bewerten, und zwar durch statische Methoden, d.h. ohne das Programm ausführen zu müssen. Gemessen wird dabei der Grad der Schwierigkeit, um den betrachteten Programmcode zu testen, zu verstehen oder zu warten. Aufgabe einer Komplexitätsmetrik ist es also, den Aufwand zur Beherrschung eines Programmcodes aus Sicht eines menschlichen Benutzers zu messen. Dies unterscheidet Komplexitätsmetriken von der klassischen Komplexitätstheorie und der algorithmischen Komplexität, die für ein Programm den Ressourcenverbrauch des zugrundeliegenden Problems bzw. des implementierten Algorithmus berechnen. Unterschiede gibt es in der Einordnung, was genau als Komplexitätsmetrik gesehen wird. So unterscheiden Fenton und Pfleeger[FP97] zwischen Umfangsmetriken wie lines of code (LOC) und Komplexitätsmetriken, hingegen [Kan02] Umfangsmetriken als Teil der Komplexitätsmetriken sieht. Der Unterschied zwischen Umfangsmetriken und anderen Komplexitätsmetriken liegt darin, dass eine Umfangsmetrik nur die Anzahl der betrachteten Elemente (bei der LOC-Metrik also die Anzahl an Codezeilen) zählt, hingegen andere Komplexitätsmetriken den Zusammenhang zwischen Elementen bewerten. In dieser Arbeit sollen Umfangsmetriken von Geschäftsprozessmodellen zu den Komplexitätsmetriken gezählt werden. Wenn wir nun die Eigenschaften eines Geschäftsprozessmodells betrachten, und zwar nur die statischen und nicht die dynamischen, sind drei Bereiche zu unterscheiden: 1. Syntaktische Struktur: Als syntaktische Struktur wird die Syntax eines Modells bezeichnet, d.h. die Elemente des Modells und die Verbindungen zwischen ihnen. Nicht dabei berücksichtigt wird, welche inhaltliche Bedeutung die Elemente im modellierten Geschäftsprozess haben. 2. Layout: Als Layout wird die graphische Repräsentation eines Modells bezeichnet. 3. Inhaltliche Struktur: Als inhaltliche Struktur wird die inhaltliche Bedeutung der Elemente eines Modells im modellierten Geschäftsprozess bezeichnet. Dies könnte auch als Semantik eines Modells bezeichnet werden, ist aber nicht mit den dynamischen Eigenschaften eines Modells wie Deadlocks zu verwechseln. Frank Meyer 17

20 Ein Kriterium für Komplexitätsmetriken ist die automatisierbare Berechnung (siehe Abschnitt 3.3). Dies ist bei Geschäftsprozessmodellen aber nur für die syntaktische Struktur und das Layout möglich. Für eine Bewertung der inhaltlichen Struktur liegen im Allgemeinen keine Informationen vor. Denkbar sind hier nur einfache Aussagen, wie oft z.b. ein bestimmte Funktion in einem Modell vorkommt, ohne die Bedeutung der Funktion zu kennen. Selbst in diesem Fall ist es nicht zwangsläufig klar, ob zwei Funktionen in einem Modell mit gleichem Namen tatsächlich die gleiche Funktion im abgebildeten Prozess darstellen. Im Rahmen dieser Arbeit beschränken wir uns auf Metriken zur syntaktischen Struktur und zum Layout. Komplexität von Geschäftsprozessmodellen definieren wir aus den vorherigen Überlegungen und in Anlehnung an die Definition im IEEE Standard Glossary of Software Engineering Terminology[IEE90] wie folgt: Definition 3.1 (Komplexität von Geschäftsprozessmodellen) Als Komplexität eines Geschäftsprozessmodells wird der Grad der Schwierigkeit zum Verstehen und zur Analyse des Modells bezeichnet. Eine Metrik ist in [IEE90] folgendermaßen definiert: Definition 3.2 (Metrik) Eine Metrik ist eine quantitative Messung des Grads, zu dem ein System, eine Komponente oder ein Prozess ein gegebenes Attribut erfüllt. Darauf aufbauend definieren wir Komplexitätsmetriken: Definition 3.3 (Komplexitätsmetrik für Geschäftsprozessmodelle) Eine Komplexitätsmetrik für Geschäftsprozessmodelle ist ein quantitatives Maß zur Messung der Verständlichkeit eines Geschäftsprozessmodells. 3.2 Gründe zum Messen von Komplexität Auch wenn wir bereits Komplexität von Geschäftsprozessprozessmodelle definiert haben, bedarf es einer weiteren Ausführung, warum sie überhaupt gemessen werden sollte. Dafür gehen wir zuerst auf Argumente ein, die in den bisherigen Publikationen zu Komplexitätsmetriken für Geschäftsprozessmodelle genannt sind. 18 Frank Meyer

21 Latva-Koivisto[LK01] sieht Messungen der Komplexität von Prozessmodellen als die beste Möglichkeit, um daraus die Komplexität des modellierten Prozesses zu bewerten. Dabei verweist er auf eine allgemeinere Argumentation von Edmonds[Edm00], nach der die Komplexität von physikalischen Prozessen nicht direkt gemessen werden kann, sondern nur über Modelle der Prozesse in einer Repräsentationssprache. Gründe für die Messung der Komplexität eines Geschäftsprozesses sieht er darin, dass mit steigender Komplexität die Fehlerwahrscheinlichkeit steigt (Verlust der Kontrollierbarkeit des Prozesses, erhöhter Stress für Mitarbeiter,... ). Ähnlich argumentiert auch Cardoso[Car05b]. Eine Analyse der Komplexität von Modellen kann danach zur Identifikation von komplexen Prozessen bzw. Prozessbereichen dienen und dafür verwendet werden, diese Prozesse/Prozessbereiche zu vereinfachen. Gruhn und Laue[GL06] sehen als Motivation für die Komplexitätsmessung von Geschäftsprozessmodellen, dass Modelle hauptsächlich zur Kommunikation zwischen Prozessbeteiligten eingesetzt werden und deshalb leicht verständlich sein sollten. Ebenso führt eine leichtere Verständlichkeit zur besseren Wartbarkeit und Wiederverwendbarkeit der Modelle. Mendling et al.[cmnr06] gehen ebenso davon aus, dass die Komplexität eines Geschäftsprozessmodells Einfluss auf Wartbarkeit, Korrektheit und Verständlichkeit des Modells hat. Zusätzlich gehen sie davon aus, dass die Komplexität eines Modells relativ zur Komplexität des Prozesses ist. Rolón Aguilar et al.[argp06b] sehen ebenfalls die Hauptmotivation für Komplexitätsmetriken darin, dass sich damit die Wartbarkeit der Modelle bewerten lässt. Als Folge können bei mehreren Alternativmodellen diejenigen ausgewählt werden, die eine leichtere Wartbarkeit besitzen. Leichter wartbare Modelle führen wiederum zu einem besseren Verständnis des Prozesses. Die genannten Gründe für Komplexitätsmetriken lassen sich in Rückschlüsse auf das Modell selbst und auf den modellierten Prozess aufteilen: 1. Aus der Komplexität eines Modells lassen sich Rückschlüsse auf Verständlichkeit, Korrektheit, Wartbarkeit und Wiederverwendbarkeit des Modells ziehen. 2. Aus der Komplexität eines Modells lassen sich direkt Rückschlüsse auf die Komplexität des modellierten Prozesses ziehen (Metriken zum Layout des Modells sind hier auszuschliessen). Ob tatsächlich direkt aus der Komplexität eines Prozessmodells auf die Komplexität eines Prozesses geschlossen werden kann, ist zu hinterfragen. So sagt ein Prozessmodell nichts darüber aus, welche Komplexität die einzelnen Elemente wie bspw. Funktionen im eigentlichen Prozess besitzen. Ebenfalls können Modelle einen unterschiedlichen Detailgrad besitzen. Als Folge daraus kann nur schwer beurteilt werden, welche Werte einer Komplexitätsmetrik eine niedrige und welche eine hohe Komplexität der Prozesse kennzeichnen, da eine Vergleichbarkeit der Werte zwischen verschiedenen Prozessen bzw. den zugehörigen Modelle aufgrund der genannten Probleme im Allgemeinen nicht möglich ist. Rückschlüsse aus der gemessenen Komplexität auf die Prozesse lassen sich dann sinnvoll ziehen, falls mehrere Frank Meyer 19

22 alternative Prozessmodelle verglichen werden sollen und damit Detailgrad sowie voraussichtlich auch ein Großteil der einzelnen Elemente in den Modellen übereinstimmen. Ebenfalls kann die Komplexitätsmessung eines Modells dabei helfen, den Beitrag von Teilbereichen eines Prozesses zu seiner Gesamtkomplexität zu beurteilen. Sowohl bei der Beurteilung von Alternativprozessen bzw. ihrer Modelle als auch bei der Beurteilung der Komplexität von Teilprozessen ist allerdings ein starkes Hintergrundwissen über die Prozesse erforderlich, um tatsächlich Rückschlüsse ziehen zu können. Dass die Komplexität eines Modells Rückschlüsse zur Verständlichkeit des Modells liefert, ergibt sich bereits aus unserer Definition von Komplexität. Dies gilt auch für daraus abgeleitete Attribute wie Korrektheit, Wiederverwendbarkeit und Wartbarkeit. Welche konkreten Maßnahmen (Hilfestellung bei der Zeit- und Ressourcenplanung, Entwicklung alternativer Prozessmodellen,... ) daraus ergriffen werden, falls für ein Modell eine hohe Komplexität gemessen wird, ist abhängig von der Umständen. Im Folgenden soll darauf eingegangen werden, in welchen Situationen bei der Verwendung eines Prozessmodells Wissen über den Grad der Verständlichkeit hilfreich sein kann: 1. Modellierung: Für den Modellierer eines Prozessmodells ist Wissen über die Komplexität des Modells sinnvoll, um den Aufwand zur Prüfung der Korrektheit des Modells abzuschätzen und Teilbereiche/Teilmodelle zu identifizieren, die besonders komplex sind. Ebenso kann er auf Grundlage der Komplexität ggf. alternative Modelle entwerfen oder das Modell in sinnvolle Teilmodelle aufteilen. 2. Kommunikation/Lesen: Bei der Verwendung eines Prozessmodells zur Kommunikation ist Wissen über die Komplexität des Modells sinnvoll, um Zeitaufwand planen zu können oder Teilbereiche/Teilmodelle identifizieren zu können, die schwer verständlich sind und damit besondere Berücksichtigung benötigen. 3. Implementation/Umsetzung: Die Verwendung eines Prozessmodells bei der nächsten Stufe des Designs (bspw. bei der Softwareentwicklung) oder direkt bei der Implementation des Prozesses kann zur vorherigen Situation Kommunikation/Lesen gezählt werden. Aufgrund der besonderen Relevanz wird es aber extra aufgeführt. Eine hohe Komplexität eines Modells kann mit höherer Wahrscheinlichkeit durch falsches Verständnis zu menschlichen Fehlern beim Design bzw. der Implementation führen. Dadurch kann es im Prozess zu Fehlverhalten kommen, d.h. zu einem Verhalten, das nicht dem erwarteten Verhalten entspricht. Wissen über die Komplexität eines Modells kann dabei helfen, besonders kritische Bereiche zu identifizieren und als Maßnahme bspw. die Überprüfung dieser Bereiche beim Design oder der Implementation durch mehrere Personen zu veranlassen. 20 Frank Meyer

23 3.3 Kriterien für Komplexitätsmetriken Für Komplexitätsmetriken existieren eine Reihe von Kriterien, die sie erfüllen müssen oder zumindest sollten. Als die beiden wichtigsten sind hier zu nennen[kan02]: 1. Wiederholbarkeit: Messungen müssen wiederholbar sein. Alle Messungen der Metrik müssen für dasselbe Modell unabhängig von der ausführenden Person und vom ausführenden Programm zum gleichen Ergebnis führen. 2. Validität: Die Metrik muss das messen, was beabsichtigt ist zu messen. Zusätzlich sollte eine Komplexitätsmetrik noch einige weitere Kriterien erfüllen: 1. Automatisierbarkeit: Die Metrik muss automatisiert ausführbar sein. 2. Leichte Implementierbarkeit: Die Metrik sollte mit vertretbarem Aufwand implementierbar sein. 3. Berechenbarkeit: Die Ausführung der Metrik sollte in jedem Fall zu einem Ergebnis in endlicher Zeit führen. Nach Möglichkeit sollte die Berechnung dabei in kurzer Zeit erfolgen. 4. Verständlichkeit: Die Metrik sollte leicht verständlich sein. Insbesondere sollte sie auch für die Anwender der Metrik verständlich sein. Richtig ist auch die Forderung von Cardoso[Car05b], dass eine Komplexitätsmetrik für verschiedene Spezifikationssprachen von Geschäftsprozessen anwendbar sein soll. Dadurch wird zum einen eine Vergleichbarkeit der Komplexitäten von Modellen in unterschiedlichen Modellierungssprachen möglich, zum anderen reduziert sich der Lernaufwand für den Anwender. Diese Forderung wird nicht immer zu erfüllen sein, dafür unterscheiden sich die Spezifikationen teilweise zu stark. Neben diesen eher allgemeineren Anforderungen gibt es theoretische Eigenschaften, die eine Komplexitätsmetrik erfüllen sollte. Im Softwarebereich werden hier vor allem 9 Eigenschaften verwendet, die von Weyuker[Wey88] aufgestellt worden. Cardoso hat diese Eigenschaften auch bereits für eine Komplexitätsmetrik für Geschäftsprozess überprüft[car05a]. Die wichtigste Forderung ist sicherlich, dass die Metrik additiv sein sollte. Dies bedeutet, dass die Komplexität eines Modells, das aus zwei Teilmodelle besteht, nicht kleiner sein darf als die Summe der Komplexitäten der beiden Teilmodelle. Einige von uns später vorgestellte Metriken, die Verhältnisse zwischen 2 Attributen messen, erfüllen diese Anforderung nicht. Dies ist sicherlich ein Kriterium, welches diese Metriken in Frage stellt. Die von Weyuker aufgestellten Eigenschaften werden im Einzelnen in Kapitel 5 vorgestellt, wo auch einige der von uns definierten Metriken auf Erfüllung dieser Eigenschaften überprüft werden. Frank Meyer 21

24 3.4 Validierung von Komplexitätsmetriken Die Validierung von Komplexitätsmetriken hat zum einen in theoretischer, zum anderen in praktischer Hinsicht zu erfolgen. Für die theoretische Validierung sind zum einen die im vorherigen Abschnitt aufgezählten allgemeinen Anforderungen auf Erfüllung zu prüfen. Weiterhin ist wie ebenfalls im vorherigen Abschnitt erwähnt die Überprüfung theoretischer Eigenschaften vorzunehmen. Häufig unterbleibt eine Überprüfung theoretische Eigenschaften aber weitestgehend. Für die praktische Validierung von Komplexitätsmetriken für graphische Modelle im Allgemeinen und Geschäftsprozessmodelle im Besonderen bieten sich zwei Möglichkeiten an: 1. Die am häufigsten angewandte Form ist eine empirische Validierung anhand von Experimenten mit Testpersonen. Dabei werden ausgewählte Modelle einer Gruppe von Personen vorgelegt, die meistens den gleichen Hintergrund haben (Studenten, Entwickler,... ). Als unabhängige Variablen dienen die Messwerte der zu validierenden Metriken für die Modelle. Als abhängige Variablen werden Verständlichkeit, Modifizierbarkeit und ähnliche Eigenschaften verwendet. Die Testpersonen bekommen für die Modelle eine Reihe von Aufgaben zugewiesen (Fragen zum Modellinhalt, Modifizierungen des Modells, subjektive Einschätzung der Verständlichkeit,... ). Die abhängigen Variablen werden nun anhand der Zeit, die jede Testperson zur Erfüllung der Aufgaben braucht, der Korrektheit der Aufgabenlösungen oder einer subjektiven Bewertung der Modelle gemessen. Für Geschäftsprozessmodelle liegt mit [Car06] eine erste Validierung einer Komplexitätsmetrik vor, die diese Methode verwendet. 2. Eine zweite Methode für die praktische Validierung besteht darin, Prozessmodelle aus der Praxis zu verwenden. Als unabhängige Variablen dienen hier wiederum die Messwerte der zu validierenden Metriken für die Modelle. Als abhängige Variable wird die Fehlerhaftigkeit der Modelle verwendet. [MMN + 06] haben eine solche Validierungsmethode für einige Komplexitätsmetriken für EPK-Modelle verwendet. Eine Variante dieser Methode könnte im Messen der Anzahl an Fehlern liegen, die aufgrund eines Prozessmodells bei der Implementation des Prozesses bzw. beim weiteren Design entstehen. Dies wäre allerdings nur mit einem hohen Ressourcenaufwand zu bewerkstelligen. Die erste Methode erlaubt eine gute Kontrolle der Testpersonen. Diese besitzen üblicherweise ein ähnliches Vorwissen in Bezug auf den Gegenstand der Studie. Damit kann ein unterschiedlicher Wissensstand als Störfaktor weitestgehend ausgeschlossen werden. Auch können bei den Testmodelle einzelne Faktoren, bei denen man sich einen besonderen Einfluss auf die abhängigen Variablen verspricht, gezielt berücksichtigt werden. Wenn wir bspw. davon ausgehen, dass Zyklen (Iterationen) einen starken Einfluss auf die Verständlichkeit haben, können andere mögliche Einflussfaktoren (Größe, Layout,... ) gering gehalten werden. Ein Nachteil dieser Methode liegt in der Gruppe der Testpersonen. Hier dienen Studenten als Testpersonen, da Personen aus der Praxis Ressourcen des Arbeitgebers in Form 22 Frank Meyer

25 von Arbeitszeit kosten. Studenten haben aber meistens nur ein geringes Vorwissen über den Gegenstand der Studie. Die Aussagen der Studie sollen aber auf die Praxis übertragen werden, also auf eine Personengruppe, die bei der Studie nicht direkt berücksichtigt wird. Ein weiterer Nachteil liegt in der Auswahl der Testmodelle. Aufgrund des Arbeitsaufwands für die Testpersonen ist die Anzahl an Testmodellen gering. Auch ist die Modellgröße üblicherweise nicht besonders hoch. Ebenso ist zu gewährleisten, dass bestimmte bei den Testmodellen verwendete Faktoren tatsächlich in der Praxis eine Rolle spielen. Wenn wir davon ausgehen, dass Zyklen einen besonderen Einfluss auf die Verständlichkeit von Geschäftsprozessmodellen haben, so kann dies möglicherweise anhand einer Studie belegt werden. Es sagt aber nichts darüber aus, ob die Verwendung von Zyklen in der Praxis überhaupt eine Rolle spielt (vgl. zur fehlenden praktischen Relevanz vieler akademisch definierter Metriken im Bereich von Software die Kritik in [FN99]). Die zweite Methode zur praktischen Validierung kann einige der Probleme der ersten Methode beheben (Praxisrelevanz, Größe und Anzahl der Modelle), wobei dies von der Auswahl der Modelle abhängig ist. Nachteil dieser Methode ist vor allem, dass nur geringes Wissen über die Entstehung der Modelle vorhanden ist. So kann üblicherweise keine Aussage über die Fähigkeiten der Modellierer und den benötigten Zeitaufwand für die Modellierung getroffen werden. Falls ein Modell fehlerhaft ist, kann dies nicht nur an der Komplexität des Modells liegen, sondern auch an mangelhaften Qualifikationen der Modellierer oder an einem geringen investierten Zeitaufwand. Bei einigen Metriken, insbesondere solchen zum Layout eines Modells, sollte gänzlich auf diese Validierungsmethode verzichtet werden. Dies hat den Grund, dass die Form des Layouts, in der ein Prozessmodell nach Fertigstellung vorliegt, häufig nicht der Entstehungsform entspricht, sondern für Präsentationsund Dokumentationszwecke angepasst ist. Im Rahmen dieser Arbeit werden wir die zweite Methode verwenden, d.h. die Validierung anhand von Modellen aus der Praxis. Der Grund liegt hauptsächlich darin, dass bereits eine größere Anzahl an Modellen verfügbar ist. Die erste Methode wäre schwierig durchzuführen, da wir eine ganze Reihe von Metriken vorstellen werden, so dass der Aufwand bei der ersten Methode recht hoch wäre. Ein weiterer Vorteil der zweiten Methode liegt darin, dass Korrelationen zwischen den Metriken anhand von Modellen aus der Praxis festgestellt werden können. Bei zukünftigen Validierungen kann die Anzahl an Metriken dadurch ggf. reduziert werden. Frank Meyer 23

26 4 Komplexitätsmetriken 4.1 Umfangsmetriken Als Umfangsmetriken werden Metriken bezeichnet, die die physikalische Größe eines Produkts messen. Unter dem Aspekt der Komplexität ist die Hypothese bei diesen Metriken, dass mit der Größe des Produkts die Komplexität steigt. Für Programmcode zählt die lines of Code -Metrik (LOC) zu dieser Gruppe. Bei der LOC- Metrik wird die Anzahl der Programmzeilen gezählt, wobei es unterschiedliche Ansätze gibt, was als Codezeile gezählt wird (Leerzeilen, Kommentare, Deklarationen, ausführbare Anweisungen; Umgang mit automatisch generiertem Code; Umgang mit kopiertem oder modifiziertem Code etc.)[fp97]. Vergleichbar zu Größenmessungen eines Programms ist es möglich, die Größe von graphischen Modellen zu messen. Dafür kann in einem Modell zwischen den verschiedenen Elementtypen des Diagramms unterschieden werden, wie analog bei Programmcode zwischen verschiedenen Typen von Codezeilen unterschieden wird. Die grundsätzliche Annahme ist dabei, je größer ein graphisches Modell, desto höher ist seine Komplexität und damit die Fehlerwahrscheinlichkeit bzw. der Zeitaufwand zum Verstehen des Modells. Für verschiedene graphische Modellierungssprachen, die im frühen Stadium der Softwareentwicklung eingesetzt werden können, sind bereits Metriken zu Modellgröße definiert und validiert worden, so für UML-Statechartdiagramme[GMP03] und für SPEM-Modelle (Software Process Engineering Metamodel)[CGP + 05]. Auch für Modellierungssprachen von Geschäftsprozessen sind bereits Umfangsmetriken vorgeschlagen worden[gl06, CMNR06, ARGP06b]. Für EPKs liegt von Mendling et al.[mmn + 06] bereits eine Studie vor, die diverse Messungen der Modellgröße anhand der Fehler von EPK-Modellen aus dem SAP-Referenzmodell validiert. Von 604 analyisierten Modellen wurden 34 als fehlerhaft klassifiziert, was 5,6% entspricht. Als Fehlerkriterium wurde dabei getestet, ob ein Modell relaxed sound ist[dr01]. Allen Ansätzen ist gemeinsam, dass sie nicht eine einzige Größenmetrik definieren, sondern eine Menge von Metriken, die die jeweilige Anzahl der Elementtypen (Knotentyp, Kanten) eines Modells einzeln oder ähnliche Elementtypen zusammenfassend zählen. Damit wird zumindest teilweise der Kritik an der LOC-Metrik begegnet, dass Codezeilen - und hier analog unterschiedliche Knotentypen in einem Modell - unterschiedlich komplex sein können. So kann davon ausgegangen werden, dass ein Verknüpfungsoperator in der Regel eine höhere zusätzliche Komplexität in ein EPK-Modell bringt als ein Ereignis. Eine einzelne Metrik, die alle Knotentypen gleich bewerten würde, würde diesem Aspekt nicht gerecht. Generell sind für Geschäftsprozessmodelle die Anzahl an Funktionen (Aktivitäten), Verknüpfungsoperatoren und Kontrollflusskanten interessant. Allerdings unterscheiden sich die Modellierungssprachen in diversen Fragen wie der Anzahl an Startknoten und Endknoten, der Forderung nach Wohlgeformtheit von Modellen oder auch durch die Verwendung weiterer elementarer Knotentypen wie Ereignisknoten bei EPKs, so dass einige Umfangsmetriken nicht für alle Modellierungssprachen sinn- 24 Frank Meyer

27 voll sind. Die Grundelemente von EPK-Modellen sind Funktionen, Ereignisse, Verknüpfungsoperatoren und Kontrollflusskanten. Nach der Studie von Mendling et al.[mmn + 06] hat die Anzahl an internen Ereignissen und an Kanten einen, wenn auch nur geringen, positiven Einfluss auf die Fehlerwahrscheinlichkeit 2. Die Anzahl an Funktionen hat hingegen einen geringen negativen Einfluss, was insofern erstaunt, als dass zwischen Funktionen und internen Ereignissen eine starke Korrelation vermutet werden kann. Generell kann davon ausgegangen werden, dass die Komplexität von EPK-Modellen entscheidend durch Verknüpfungsoperatoren beeinflusst wird. Nach den Ergebnissen von Mendling et al.[mmn + 06] haben OR-Joins und XOR-Joins einen großen, AND-Joins einen geringen positiven Einfluss auf die Fehlerwahrscheinlichkeit (OR- Joins haben demnach den größten Einfluss von allen gemessenen Variablen). Die Anzahl an Split-Operatoren hatte hingegen unabhängig vom Splittyp einen negativen Einfluss. Von Interesse bei EPK-Modellen ist ebenfalls die Anzahl an Startereignissen und Endereignissen. Im Gegensatz zu anderen Modellierungssprachen ist es bei EPKs erlaubt, dass diese mehr als ein Startereignis oder Endereignis haben. Zusätzlich können noch unterschiedliche Startbelegungen festgelegt werden. Es kann vermutet werden, dass dies eine häufige Fehlerursache ist, weil der Modellierer nicht alle Startbelegungen testet. Allerdings ist der Einfluss schwer zu validieren, da die Menge der gültigen Startbelegungen üblicherweise nicht im Modell verzeichnet ist. Bei der Studie von Mendling et al.[mmn + 06] wurde ein relativ kleiner positiver Einfluss von Endereignissen auf die Fehlerwahrscheinlichkeit festgestellt. Für Startereignisse wurde erstaunlicherweise sogar ein negativer Einfluss festgestellt. Diesen führen sie darauf zurück, dass in den Modellen zwar häufig mehrere Startereignisse verwendet werden, diese aber sogleich durch Konnektoren zusammengeführt werden. Als Umfangsmetriken für EPK-Modelle definieren wir: Definition 4.1 (Umfangsmetriken) Sei M ein Modell. Die Umfangsmetriken von M werden wie folgt berechnet: N_EV ENT S(M) = Anzahl interne Ereignisse (4.1) N_F UNCT IONS(M) = Anzahl Funktionen (4.2) N_ST ART EV ENT S(M) = Anzahl Startereignisse (4.3) N_ENDEV ENT S(M) = Anzahl Endereignisse (4.4) 2 Auf ein mögliches Problem dieser Studie durch die fehlende Berücksichtigung der Korrelationen zwischen den Metriken gehen wir in Kapitel 7 ein. Frank Meyer 25

28 N_ARCS = Anzahl Kontrollflusskanten (4.5) N_CON N ECT ORS(M) = Anzahl Verknüpfungsperatoren (4.6) N_JOIN CON N ECT ORS(M) = Anzahl Join-Operatoren (4.7) N_SP LIT CON N ECT ORS(M) = Anzahl Split-Operatoren (4.8) N_SP LIT XOR(M) = Anzahl XOR-Splitoperatoren (4.9) N_SP LIT OR(M) = Anzahl OR-Splitoperatoren (4.10) N_SP LIT AN D(M) = Anzahl AND-Splitoperatoren (4.11) N_JOIN XOR(M) = Anzahl XOR-Joinoperatoren (4.12) N_JOIN AN D(M) = Anzahl AND-Joinoperatoren (4.13) N_JOIN OR(M) = Anzahl OR-Joinoperatoren (4.14) N_F UNCT IONS_CONNECT ORS(M) = Anzahl Verknüpfungsperatoren und Funktionen (4.15) Generell vernachlässigen reine Größenmetriken sowohl bei Programmen als auch bei graphischen Modellen viele Aspekte, die die Komplexität beeinflussen können. Insbesondere sagen die hier für EPK-Modelle definierten Umfangsmetriken wenig über die Struktur eines Modells aus. Zwar kann aus der Anzahl an Verknüpfungsoperatoren bereits vermutet werden, wie stark ein Modell verzweigt ist. Wie verständlich diese Verzweigungen sind, bspw. durch die Verschachtelungstiefe der Verknüpfungsoperatoren oder durch Ein- und Aussprünge, kann aber nicht ermittelt werden. Deshalb ist es interessant, weitere Metriken zu definieren, die insbesondere die Struktur der Modelle berücksichtigen. Da Struktur bei Geschäftsprozessmodellen in erster Linie durch Verknüpfungsoperatoren gebildet wird, werden sich die Metriken hauptsächlich mit Eigenschaften der Verknüpfungsoperatoren beschäftigen. Keine Umfangsmetriken wurden für Prozesswegweiser und hierarchische Funktionen definiert. Hierarchische Funktionen werden in der hier verwendeten Syntaxdefinition als Funktionen gezählt und damit auch in den Umfangsmetriken zu Funktionen berücksichtigt. Bei Prozesswegweisern folgen diesen direkt Startereignisse bzw. es gehen ihnen Endereignisse voran. Deshalb kann davon ausgegangen werden, dass ihre Komplexität mit den Umfangsmetriken zu Start- und Endereignissen genügend berücksichtigt ist. 26 Frank Meyer

29 Generell lassen sich alle Umfangsmetriken und auch die meisten der weiteren Metriken, die wir noch vorstellen werden, sowohl auf Teilmodelle anwenden als auch auf zusammengeführte Modelle, bei denen die vertikale und/oder horizontale Aufsplittung zur Metrikberechnung teilweise oder vollständig aufgehoben wird. Zu beachten ist hier, dass insbesondere bei einer Zusammenführung von mehreren Teilmodellen zur Metrikberechnung bestimmte Modellteile wiederholt vorkommen können. Ebenfalls ist es denkbar, dass auch ohne Zusammenführung mehrerer Teilmodelle in einem Teilmodell bestimmte Modellstrukturen wie bspw. gleiche Funktionen oder auch komplexere Kontrollstrukturen wiederholt vorkommen. Eine Berücksichtigung dieses Aspekts bei der Metrikdefinition ist aber nur schwer möglich. Ebenso wäre eine Implementierung zur Erkennung gleicher Modellteile recht aufwendig Verhältnismetriken Direkt aus den Umfangsmetriken lassen sich Metriken ableiten, die die Anzahl verschiedener Elemente ins Verhältnis setzen. Solche Metriken sind trotz ihrer relativ hohen Beliebtheit mit Vorsicht zu verwenden, da sie nicht additiv sind. Sie sind also im Zusammenhang mit der Gesamtanzahl der ins Verhältnis gesetzten Elemente zu betrachten. Deutlich wird dies auch bei der Studie von Canfora et al. [CGP + 05], die für SPEM-Modelle verschiedene solcher Verhältnismetriken definieren. Bei keiner dieser Metriken wurde bei der praktischen Validierung eine Relevanz auf die Komplexität festgestellt, hingegen sich fast alle Umfangsmetriken als relevant herausstellten. Auch Mendling et al.[mmn + 06] haben bereits das Verhältnis zwischen Joinoperatoren und Splitoperatoren validiert, dabei aber nur einen sehr kleinen positiven Einfluss auf die Fehlerwahrscheinlichkeit von EPK-Modellen festgestellt. Formal lässt sich die Metrik wie folgt definieren: Definition 4.2 (Verhältnis Joinoperatoren - Splitoperatoren) Sei M ein Modell. Das Join-/Splitverhältnis von M wird wie folgt berechnet: RAT IO_JS(M) = Anzahl Joinoperatoren Anzahl Splitoperatoren (4.16) Nach ihren Angaben haben die validierten EPK-Modelle aus dem SAP- Referenzmodell häufig eine größere Anzahl von Startereignisse, deren Kontrollpfade durch Joinoperatoren zusammengeführt werden. Dies mag ein Grund sein, weshalb sich das Join-/Splitverhältnis in ihrer Studie als wenig erfolgsversprechend herausgestellt hat. Allerdings ist der Ansatz generell wenig schlüssig. Eine Teilstruktur in einem Modell, die einen Splitoperator und mehrere Joinoperatoren besitzt, kann durch eine zweite Teilstruktur, die mehrere Splitoperatoren und einen Joinoperator besitzt, ausgeglichen werden. Beispielhaft ist das in Abb. 4 dargestellt. Während das Modell auf der linken Seite beim Join-/Splitverhältnis eine Komplexität von 2.0 hat, besitzt das rechte Modell eine Komplexität von 1.0, obwohl hier eine Kontrollfllusskante des linken Modells durch eine zusätzliche Verzweigungsstruktur ersetzt wurde. Frank Meyer 27

30 Abbildung 4: Verhältnis Joinoperatoren/Splitoperatoren Ein weiteres interessantes Größenverhältnis ist das von Verknüpfungsoperatoren zu Funktionen und internen Ereignissen bei EPK-Modellen. Für die Verwendung sowohl von Funktionen als auch von internen Ereignissen im Divisor spricht, dass zwar für die meisten Modelle davon ausgegangen werden kann, dass die Anzahl an Funktionen und internen Ereignissen ähnlich ist, dies aber nicht zwingend notwendig ist. Bei anderen Modellierungssprachen von Geschäftsprozessen wie UML- Aktivitätsdiagramme, die keine Ereignisse verwenden, kann stattdessen die Anzahl von Aktivitäten bzw. Funktionen verwenden werden. Problematisch an der Metrik ist, dass es durchaus üblich ist, Verknüpfungsoperatoren direkt nach Startereignissen bzw. vor Endereignissen einzusetzen, was vermutlich die Komplexität eines Modells nicht wesentlich erhöht. Nun wäre es denkbar, diese Verknüpfungsoperatoren nicht mitzuzählen. Allerdings ist auch dies nicht unproblematisch, da vor die eigentliche Startereignisse eine Struktur neues Startereignis - Funktion - Verzweigungen zu eigentlichen Startereignissen hinzugefügt werden kann (analog bei Endereignisse). Dies entspricht auch einem sauberem Modellierungsstil. YAWL[AH05] erlaubt bspw. explizit nur einen Startknoten. Ein weiterer Kritikpunkt ist, dass die Metrik wiederum nicht additiv ist. Ein Erhöhung des Divisors, was einer Erweiterung des Modells entspricht und damit eine ansteigende oder zumindest gleichbleibende Komplexität des Modells vermuten lässt, bewirkt eine niedriger gemessene Komplexität. Wir definieren zuerst eine Metrik zum Verhältnis zwischen Verknüpfungsoperatoren und Funktionen sowie internen Ereignissen, danach die allgemeinere Form davon durch das Verhältnis Verknüpfungsoperatoren und Funktionen. Definition 4.3 (Verhältnis Verknüpfungsoperatoren - Funktionen/Ereignisse) Sei M ein Modell. Das Verhältnis Verknüpfungsoperatoren - Funktionen und Ereignisse von M wird wie folgt berechnet: RAT IO_CF E(M) = Anzahl Verknüpfungsoperatoren Anzahl Funktionen und interne Ereignisse (4.17) 28 Frank Meyer

31 Definition 4.4 (Verhältnis Verknüpfungsoperatoren - Funktionen) Sei M ein Modell. Das Verhältnis Verknüpfungsoperatoren - Funktionen von M wird wie folgt berechnet: RAT IO_CF (M) = Anzahl Verknüpfungsoperatoren Anzahl Funktionen (4.18) Umfangsmetriken für UML 2-Aktivitätsdiagramme Analog wie für EPK-Modelle können für UML 2-Aktivitätsdiagrammen Umfangsmetriken aufgestellt werden, wobei aufgrund der unterschiedlichen Syntax- und Semantikdefinition nicht alle Umfangsmetriken für beide Modellierungssprachen gleichermaßen interessant sind. Mit [SDM, Gro04] stehen bereits Softwaretools zur Verfügung, die diverse Umfangsmetriken messen können. Allerdings sind keine praktischen Validierungen zu den Metriken bekannt. Folgende Umfangsmetriken für Aktivitätsdiagramme sind im Rahmen des Syntaxbereichs, auf den sich diese Arbeit beschränkt, interessant: Definition 4.5 (Umfangsmetriken für Aktivitätsdiagramme) N_ACT ION S = Anzahl Aktionsknoten N_F IN ALN ODES = Anzahl Kontrollflussabschluss- und Aktivitätsabschlussknoten N_ARCS = Anzahl Kontrollflusskanten N_CON N ECT ORS = Anzahl Split- und Join-Operatoren N_SP LIT XOR = Anzahl XOR-Splitoperatoren N_JOIN XOR = Anzahl XOR-Joinoperatoren N_SP LIT AN D = Anzahl AND-Splitoperatoren N_JOIN AN D = Anzahl AND-Joinoperatoren N_EXCEP T IONS = Anzahl Ausnahmen N_IN T ERRU P T IBLE_REGION S = Anzahl unterbrechbare Bereiche Zur Metrik N_ACT ION S sei anzumerken, dass unter Aktionsknoten auch CallBehaviorActions und CallOperationActions fallen, die Unteraktivitäten aufrufen und damit eine Form der Hierarchisierung von Aktivitätsdiagrammen erlauben, ähnlich wie es hierarchisierte Funktionen bei EPKs erlauben. Auf eine Metrik zur Anzahl der Startknoten wurde verzichtet, da Aktivitätsdiagramme keine Startbelegungen wie EPKs verwenden, sondern bei Aktivitätsbeginn alle Startknoten mit Token belegt sind. Unter N_F INALNODES sind sowohl die Endknoten der Aktivität als auch die Endknoten eines Kontrollflusses zusammengefasst. Frank Meyer 29

32 Neben Aktionen und Verknüpfungsoperatoren wurden auch Umfangsmetriken für Ausnahmen (Exceptions) und unterbrechbare Aktivitätsbereiche (interruptible activity regions) definiert. Ausnahmen können neben einer eigenen Umfangsmetriken ebenfalls in anderen Metriken, die später definiert werden, berücksichtigt werden. Neben der Anzahl der Ausnahmen spielt für die Komplexität dieser Modellierungseigenschaft die Anzahl an unterschiedlichen Zielknoten bzw. Ausnahmebehandlungen, die die Kontrollflusskanten der Ausnahmen im Modell haben, eine Rolle. Als Metrik lässt sich dies wie folgt kombinieren: Definition 4.6 (Komplexität von Ausnahmen) EXCEP T ION_COMP = Anzahl Ausnahmen Anzahl Ausnahmebehandlungen Neben der Anzahl an unterbrechbaren Bereichen spielt für die Komplexität von unterbrechbaren Bereichen die Anzahl an Aktionen innerhalb der unterbrechbaren Bereiche eine Rolle. Beide Einflussgrößen lassen sich in einer Metrik kombinieren: Definition 4.7 (Komplexität unterbrechbarer Bereiche) IN T ER_REGION_COM P = Anzahl unterbrechbare Bereiche Anzahl Aktionsknoten in unterbrechbaren Bereichen Sowohl bei Ausnahmen als auch bei unterbrechbaren Bereichen stellt sich allerdings die Frage, inwieweit sie genügend Relevanz als Modellierungsmerkmal von Aktivitätsdiagrammen haben, so dass eigene Metriken gerechtfertigt sind. 30 Frank Meyer

33 4.2 Metriken zu Zyklen Sowohl EPK-Modelle als auch Aktivitätsdiagramme erlauben Zyklen. Für EPK- Modelle wurde in [ADK02] gezeigt, dass durch Zyklen Modelle möglich sind, die über keine klare Semantik verfügen. Neben der steigenden Wahrscheinlichkeit, dass Modelle durch Zyklen semantisch fehlerhaft sein können, lässt sich ebenfalls vermuten, dass der Aufwand zum Verstehen eines Modells für den Leser steigt. Zyklen sind ein Aspekt für die Unstrukturierheit von Modellen. Naheliegend ist deshalb die Forderung, die Komplexität der Zyklen in eine Gesamtmetrik zur Unstrukturiertheit von Modellen zu integrieren, wie es bspw. in [FLK00] bei einer Metrik bezüglich der Unstrukturiertheit von Petrinetzen vorgeschlagen wird. Hier wird die Anzahl an Zyklen in einem Petrinetz als ein Bestandteil einer Summe über mehrere Faktoren verwendet. Allerdings erfolgt keine Gewichtung der einzelnen Faktoren, ebenso wie eine Begründung fehlt, weshalb die verschiedenen Faktoren gleich gewichtet sind. Eine solche Gewichtung scheint auch nicht möglich zu sein, zumindest nicht ohne den Einfluss der einzelnen Faktoren bei praktischen Validierungen geprüft zu haben. Der Aspekt der Zyklen soll hier mit eigenen Metriken betrachtet werden. Auf weitere Aspekte zur Unstrukturiertheit wird in einem späteren Abschnitt eingegangen werden, wobei auch hierbei Zyklen eine Rolle spielen werden. Als einfache Metrik lässt sich die Anzahl elementarer Zyklen in einem Modell zählen (zur Definition eines elementaren Zyklus siehe Kapitel 2.2). Definition 4.8 (Metrik zur Anzahl elementarer Zyklen) Sei M ein Modell. Die Gesamtkomplexität des Modells wird berechnet durch: N_CY CLES(M) = Anzahl elementare Zyklen in M (4.19) Anzumerken sei, dass Zyklen, die nur aus Verknüpfungsoperatoren bestehen, in der Syntaxdefinition für EPK-Modelle bereits ausgeschlossen wurden. Sie werden also auch nicht in der Metrik gezählt. Mendling et al.[mmn + 06] haben in der bereits erwähnten Studie analysiert, ob Zyklen in einem Modell eine Auswirkung auf die Fehlerwahrscheinlichkeit von EPK- Modellen hat, hierbei aber keine Signifikanz festgestellt. Allerdings haben sie nur getestet, ob ein Modell einen Zyklus besitzt oder nicht, die Anzahl an Zyklen fand keine Berücksichtigung. Die einfache Anzahl an elementaren Zyklen in einem Modell als Metrik berücksichtigt einige Faktoren nicht, die möglicherweise eine Rolle bei der Komplexität von Zyklen spielen: Anzahl an Knoten: Ein möglicher Einflussfaktor kann in der Anzahl der Knoten, die ein Zyklus beinhaltet, gesehen werden. Grundthese ist dabei, dass mit Frank Meyer 31

34 einer höheren Anzahl an Knoten in einem Zyklus auch der Aufwand zum Verstehen desselben steigt. Insgesamt scheint dieser Ansatz aber wenig schlüssig. Bei vielen Modellen können die Zyklen unabhängig von der Knotenmenge recht schnell erkannt werden, da sie Kontrollflusskanten entgegen der allgemeinen Schreibrichtung des Modells beinhalten. Überlappende Zyklen: Bislang werden nur elementare Zyklen betrachtet. Es ist aber möglich, dass mehrere elementare Zyklen gemeinsame Knoten besitzen, d.h. dass mindestens ein Knoten in den Knotenmengen mehrerer elementarer Zyklen vorkommt. Im linken Modell in Abb. 5 ( Modell 1 ) sind bspw. die Verknüpfungsoperatoren A, B, C, D sowie die Funktion F in der Knotenmenge aller elementarer Zyklen des Modells. Solche sich überlappende elementare Zyklen erlauben es, zusammengesetzte Zyklen zu bilden. Es ist davon auszugehen, dass dies die Komplexität beeinflussen kann. Anzahl an Verknüpfungsoperatoren: Joinoperatoren dienen als Einstiegsknoten in einen Zyklus, Splitoperatoren dienen als Ausstiegsknoten aus einem Zyklus. Eine Vermutung ist deshalb, dass mit einer höheren Anzahl an Joinund Splitoperatoren in einem Zyklus - und damit einer höheren Anzahl an Einstiegs- und Ausstiegsknoten - die Komplexität steigt. Typen von Verknüpfungsoperatoren: Einen weiteren Aspekt in der Komplexität spielen die Typen der Verknüpfungsoperatoren, die ein Zyklus beinhaltet. Die Verwendung unterschiedlicher Typen bei Split- und zugehörigen Joinoperatoren kann zu semantischen Fehlern im Modell führen. Dieser Faktor wird später bei der Metrik zur Unstrukturiertheit von Modellen weiter betrachtet werden. Im Folgenden soll von den möglichen zusätzlichen Einflussfaktoren nur der Aspekt überlappender Zyklen und der Aspekt der Verknüpfungsoperatoren in einem Zyklus weiter berücksichtigt werden. Eine naheliegende Metrik wäre, für jeden elementaren Zyklus die Anzahl an Überlappungen mit anderen elementaren Zyklen und die Anzahl an Verknüpfungsoperatoren im Zyklus zu zählen und aus der Summe der Einzelkomplexitäten die Gesamtkomplexität des Modells zu berechnen. Neben dem ungewichteten Summieren zweier Faktoren, die nicht direkt vergleichbar sind, hätte eine solche Metrik einige weitere Schwächen, wie anhand des linken EPK-Modellausschnitts in Abb. 5 ( Modell 1 ) verdeutlicht werden soll. Dabei soll wie auch bei den anderen Teilmodellen davon ausgegangen werden, dass keine weiteren Zyklen im Modell vorhanden sind. Es besitzt demzufolge, bei n Wegen zwischen den Verknüpfungsoperatoren B und C, n elementare Zyklen. Für jeden der n Wege zwischen B und C sei zusätzlich angenommen, dass er keine weiteren Verknüpfungsoperatoren enthält. Damit würde sich für jeden dieser Zyklen mit dem genannten Metrikansatz eine gemessene Komplexität von 4 + (n 1) ergeben, das Gesamtmodell hätte eine Komplexität von n (4 + (n 1). Der zusätzliche Aufwand für das Verständnis des Modells, der sich aus der letztendlich für die Entstehung der n Zyklen verantwortlichen Kante zwischen Knoten D und Funktion F ergibt, wird dadurch deutlich zu stark bewertet. Auch die N_CYCLES-Metrik, die für dieses Modell eine Komplexität von n berechnet, ist in diesem Fall zumindest für größere n unangemessen, denn die Entschei- 32 Frank Meyer

35 Abbildung 5: Beispielmodelle zu Zyklen (1) dung, ob ein Token erneut die Knoten A bis D durchläuft, wird für alle elementaren Zyklen beim Verknüpfungsoperator D getroffen. Noch deutlicher wird das Problem, wenn in allgemeinerer Form statt von einem Konstrukt aus Split- und Joinoperator, wie es durch die Knoten B und C eingeführt wird, von m Konstrukten dieser Art ausgegangen wird, die sich zwischen Knoten A und Knoten D befinden. Bei sonst gleichem Aufbau wie im Beispielmodell ergibt sich dann mit der N_CYCLES-Metrik eine Komplexität von m n. Für die Definition einer alternativen Metrik sollen die Verknüpfungsoperatoren näher betrachtet werden. Alle Knoten in einem Zyklus bilden eine stark zusammenhängende Komponente (sz-komponente) oder sind zumindest Teil einer solchen, falls sich der Zyklus mit weiteren Zyklen überschneidet. Als stark zusammenhängende Komponente werden bei Graphen solche Teilgraphen bezeichnet, in denen jeder Knoten jeden Knoten erreichen kann. Bei überlappenden Zyklen wird also durch die Knotenmenge aller betroffener Zyklen eine sz-komponente gebildet. Interessant sind in diesem Zusammenhang solche Verknüpfungsoperatoren, die für einen elementaren Zyklus einen Einstieg in die zugehörige sz-komponente oder einen Ausstieg aus der sz-komponente ermöglichen, ohne dabei andere Knoten aus der Knotenmenge des elementaren Zyklus zu durchlaufen. Da wir in unserer Syntaxdefinition einer EPK sogenannte tote Bereiche ausgeschlossen haben, können wir Verknüpfungsoperatoren, die als Einstieg oder Ausstieg für einen elementaren Zyklus dienen, auch dadurch identifizieren, dass sie einen Weg zu einem Endknoten bzw. von einem Startknoten besitzen, der keinen anderen Knoten aus der Knotenmenge des elementaren Zyklus durchläuft. Im linken Beispielmodell in Abb. 5 dient Frank Meyer 33

36 Abbildung 6: Beispielmodelle zu Zyklen (2) der A als Einstiegsknoten und der Splitoperator D als Ausstiegsknoten, und zwar übereinstimmend für alle elementaren Zyklen des Modells. In Abb. 6 werden zwei Modelle gezeigt ( Modell 4 und Modell 5 ), in denen sich überlappende Zyklen unterschiedliche Mengen an Einstiegs- und Ausstiegsknoten besitzen. Eine genauere Beschreibung der Zyklen der Modelle und ihrer Einstiegs- und Ausstiegsknoten ist in Tabelle 1 ersichtlich. Einen ähnlichen Aufbau wie das erste Modell in Abb. 5 hat das zweite Beispielmodell auf der rechten Seite. Die Entscheidung, ob ein Token erneut die Knoten A bis D durchläuft, wird wiederum nur am Splitoperator D getroffen. Im Gegensatz zum ersten Modell gibt es allerdings zwei Wege, die dafür verwendet werden können, entweder über die Funktion F1 oder über die Funktion F2. Für die Definition der Metrik werden die elementaren Zyklen in Äquivalenzklassen eingeteilt. Zwei elementare Zyklen gehören zur gleichen Äquivalenzklasse, wenn sie die gleichen Einstiegsknoten und die gleichen Ausstiegsknoten haben. Zusätzlich müssen die gleichen direkten Nachfolgeknoten von allen Ausstiegsknoten (d.h. diejenigen Knoten, die durch eine vom Ausstiegsknoten ausgehende Kante mit ihm verbunden sind) in den Knotenmengen der beiden Zyklen vorkommen. Das erste Beispielmodell in Abb. 5 hat mit dieser Definition nur eine Äquivalenzklasse elementarer Zyklen, da alle Zyklen die gleichen Einstiegsknoten und Ausstiegsknoten sowie F1 als direkten Nachfolger des Ausstiegsknoten haben. Das rechte Modell hat hingegen zwei Äquivalenzklassen von Zyklen, eine mit F1 als direkten Nachfolger des Ausstiegsknoten, eine mit F2 als direkten Nachfolger. 34 Frank Meyer

37 Modell Klasse Zyklen der Klasse Einstieg Ausstieg Überlappungen Modell 1 1 (A,B,E1,C,D,F),..., A (1) B (1) (A,B,En,C,D,F) Modell 2 1 (A,B,E1,C,D,F1),..., A (1) B (1) 2 (0.5) (A,B,En,C,D,F1) 2 (A,B,E1,C,D,F2),..., A (1) B (1) 1 (0.5) (A,B,En,C,D,F2) Modell 3 1 (A,B,E1,C,D,F1),..., A (1) B (1) (A,B,En,C,D,F1) Modell 4 1 (A,B,E1,C,D,F2) A (1) D (1) 2 (0.5) 2 (B,E1,C,F1) B (1) C (1) 1 (0.5) Modell 5 1 (A,B,E1,C,F1) A (1) C (1) 2 (0.5) 2 (B,E1,C,D,F2) B (1) D (1) 1 (0.5) Tabelle 1: Äquivalenzklassen der Beispielmodelle für Zyklen. Eine ähnliche Überlegung wie für die Nachfolgeknoten von Ausstiegsknoten kann für die Vorgängerknoten von Einstiegsknoten erfolgen. Ein Modellbeispiel ist in Abb. 6 auf der linken Seite gezeigt ( Modell 3 ). Der Einstiegsknoten A hat hierbei zwei eingehende Kanten, die jeweils Bestandteil von elementaren Zyklen sind und dient damit neben der Aufgabe als Einsteigsknoten für die Zyklen als zugehöriger Joinoperator für den Splitoperator E, an dem alle von E ausgehenden Token spätestens eingesammelt sind. Allerdings ist es wenig begründbar, hier für die Metrik eine zusätzliche Unterscheidung bei der Einteilung der Zyklen in verschiedene Zyklenmengen zu machen. Die vom Splitoperator E und vom Joinoperator A gebildete Struktur ist vergleichbar mit dem Konstrukt der Verknüpfungsoperatoren B und C. Ebenso ist es denkbar, dass ein zusätzlicher Joinoperator zwischen E und A eingeführt wird, der die Aufgabe von A als zugehöriger Joinoperator zu E übernimmt. Aus den bisherigen Überlegungen fassen wir die Begriffe zusammen: 1. Ein Knoten k heißt Ausstiegsknoten aus einem elementaren Zyklus K cycle, falls k zur Knotenmenge von K cycle gehört und es einen Weg von k zu einem Endknoten gibt, der keinen anderen Knoten von K cycle durchläuft. Ein solcher Knoten muss ein Splitoperator sein. 2. Ein Knoten k heißt Einstiegsknoten in einen elementaren Zyklus K cycle, falls k zur Knotenmenge von K cycle gehört und es einen Weg von einem Startknoten zu k gibt, der keinen anderen Knoten von K cycle durchläuft. Ein solcher Knoten muss ein Joinoperator sein. 3. Die Menge EXN(c) stellt die Menge aller Ausstiegsknoten für einen elementaren Zyklus c dar. 4. Die Menge EN(c) stellt die Menge aller Einstiegsknoten für einen elementaren Zyklus c dar. 5. Die Menge EXNS(c) stellt die Menge aller direkten Nachfolger der Ausstiegsknoten eines elementaren Zyklus c dar, die selbst in der Knotenmenge des Frank Meyer 35

38 elementaren Zyklus enthalten sind. 6. Zwei elementare Zyklen c 1, c 2 gehören zur gleichen Äquivalenzklasse von Zyklen CSET, falls gilt: EXN(c 1 ) = EXN(c 2 ), EN(c 1 ) = EN(c 2 ), EXNS(c 1 ) = EXNS(c 2 ). 7. Zwei Äquivalenzklassen von Zyklen werden als sich überlappend bezeichnet, falls ein Knoten in Zyklen beider Äquivalenzklassen vorkommt. Aus den vorherigen Überlegungen zur Einteilung von Zyklen in Klassen werden zwei Metriken ableitet. Zum einen wird eine Metrik zur Anzahl an Äquivalenzklassen von Zyklen definiert. Als zweites wird eine Metrik definiert, die die Anzahl an Einstiegs- und Ausstiegsknoten sowie die Überlappungen von Zyklen unterschiedlicher Äquivalenzklassen berücksichtigt. Die Komplexität einer Äquivalenzklasse wird dabei aus der Summe der Anzahl an Einstiegs- und Ausstiegsknoten und der Anzahl an Äquivalenzklassen, mit denen es Überlappungen gibt, berechnet. Die Anzahl an Überlappungen mit anderen Äquivalenzklassen wird hierbei durch 2 dividiert, da Überlappungen ebenso bei der Komplexitätsberechnung der anderen betroffenen Äquivalenzklassen berücksichtigt werden. Die Gesamtkomplexität eines Modells ergibt sich aus der Summe der Einzelkomplexitäten aller Äquivalenzklassen. Definition 4.9 (Metrik zur Anzahl an Äquivalenzklassen von Zyklen) Sei M ein Modell. Die Gesamtkomplexität des Modells wird berechnet durch: N_CSET S(M) = Anzahl an Äquivalenzklassen elementarer Zyklen in M (4.20) Definition 4.10 (Metrik zur Komplexität der Äquivalenzklassen von Zyklen) Sei M ein Modell und CSET eine Äquivalenzklasse elementarer Zyklen. Die Komplexität von CSET wird berechnet durch: C(CSET ) = Anzahl unterschiedlicher Ausstiegsknoten der Zyklen von CSET + Anzahl unterschiedlicher Einstiegsknoten der Zyklen von CSET Anzahl an Überlappungen von CSET mit anderen Äquivalenzklassen (4.21) Die Gesamtkomplexität von M ergibt sich aus den Komplexitäten aller Äquivalenzklassen elementarer Zyklen (Cycle Sets Complexity): CSC(M) = C(CSET ) (4.22) CSET ist Äquivalenzklasse 36 Frank Meyer

39 Ein Kritikpunkt an der CSC-Metrik ist sicherlich, dass hier für die Berechnung der Komplexität einer Äquivalenzklasse von Zyklen zwei unterschiedliche Faktoren (Anzahl an Ein-/Ausgängen und Überlappungen mit Zyklen anderer Äquivalenzklassen) verwendet werden, die nicht direkt vergleichbar sind. Eine Begründung, warum die Komplexität einer bestimmten Anzahl von Ein-/Ausgängen gleich einer bestimmten Anzahl an Überlappungen entspricht, kann nicht erfolgen. Alle vorgeschlagenen Metriken lassen sich mit vertretbarem Aufwand implementieren, zumal die Graphen von Geschäftsprozessen in der Regel relativ klein sind. Die elementaren Zyklen in direkten Graphen, wie es Geschäftsprozessmodelle sind, lassen sich in linearer Zeit berechnen[joh75]. Die N_CYCLES-Metrik lässt sich direkt aus den Knotenmengen der elementaren Zyklen berechnen. Für die beiden anderen Metriken ist es notwendig, zusätzlich die Wege zu Start- und Endknoten bzw. zu Knoten außerhalb der sz-komponente zu berechnen. Für die Beispielmodelle sind die Komplexitäten für alle vorgeschlagenen Metriken in der Tabelle 2 zusammengefasst. Eine genauere Aufschlüsselung der Äquivalenzklassen der einzelnen Modelle sowie die Zusammensetzung der Komplexität dieser Klassen in der CSC-Metrik ist in Tabelle 1 ersichtlich. Modellname N_CYCLES N_CSETS CSC Modell 1 n 1 2 Modell 2 2n 2 5 Modell 3 2n 1 2 Modell Modell Tabelle 2: Komplexitäten der Beispielmodelle für Zyklen Frank Meyer 37

40 4.3 Metriken zum Kontrollfluss Eine der bekanntesten Komplexitätsmetriken für Programmcode ist die von McCabe vorgeschlagene zyklomatische Zahl[McC76]. Ausgehend vom Kontrollflussgraphen eines Programms wird sie wie folgt berechnet: F e n p v(f ) = e n + 2p Kontrollflussgraph Anzahl an Kanten im Kontrollflussgraph Anzahl an Knoten im Kontrollflussgraph Anzahl unverbundener Komponenten im Graph Zyklomatische Komplexität von F Tatsächlich misst die zyklomatische Zahl die Anzahl der linear unabhängigen Wege durch den Kontrollflussgraphen. Anschaulich gesehen entspricht sie der Zahl der binären Entscheidungen im Programm + 1 (v(f ) = b + 1 für p = 1). Strukturen mit mehr als zwei Entscheidungen (bspw. case-anweisungen) werden dabei durch binäre Entscheidungen ersetzt, wobei eine Entscheidungsstruktur mit n Wegen durch n-1 binäre Entscheidungsstrukturen ersetzt werden kann. Je mehr binäre Entscheidungen ein Programm hat (e.g. je größer die zyklomatische Zahl ist), desto komplexer ist das Programm. Die Metrik war und ist Gegenstand vielfältiger Studien und blieb nicht kritiklos. Kritisiert wurde u.a., dass sie generell alle Entscheidungsstrukturen gleich behandelt, unabhängig vom Typ und der Anzahl an Wegen. Weiterhin wurde kritisiert, dass sie andere Aspekte wie Programmlänge, Verschachtelungstiefe der Entscheidungsstrukturen und die Anzahl möglicher (nicht nur linear unabhängiger) Wege nicht berücksichtigt. Unabhängig von den Kritiken findet die Metrik in der Praxis häufig Verwendung als Indikator, wie aufwändig das Testen und die Wartung eines Programms bzw. eines Programmmoduls ist[fp97]. Cardoso[Car05b] hat für Geschäftsprozessmodelle eine Metrik CFC (control-flow complexity) vorgeschlagen, deren Ansatz er auf die McCabe-Metrik zurückführt. Die Metrik ist wie folgt definiert: Definition 4.11 (Kontrollflusskomplexität der Splitoperatoren) Sei s ein Splitoperator und n die Anzahl der ausgehenden Kanten von s. Seine Komplexität wird je nach Typ von s wie folgt berechnet: CF C AND (s) = 1 (s ist AND-Splitoperator) (4.23) CF C XOR (s) = n (s ist XOR-Splitoperator) (4.24) CF C OR (s) = 2 n 1 (s ist OR-Splitoperator) (4.25) 38 Frank Meyer

41 Die Gesamtkomplexität des Kontrollflusses aller Splitoperatoren eines Prozessmodells M ergibt sich aus der Summe der einzelnen Komplexitäten: CF C(M) = CF C AND (s) + CF C XOR (s) s ist AND-Split s ist XOR-Split (4.26) + CF C OR (s) s ist OR-Split Die CFC-Metrik zählt also die Anzahl möglicher Kontrollflüsse jedes Split-Operators und addiert diese zu einer Gesamtkomplexität des Modells. Die Überlegung des Ansatzes ist, dass ein Modellierer, der einen Splitoperator in ein Modell einführt, die Auswirkungen aller möglichen ausgehenden Kontrollflüsse des Split-Operators auf das Modell analysieren muss. Mit der Anzahl der zu analysierenden Zustände steigt also die Komplexität des Modells. Von Cardoso selber wurde eine empirische Studie durchgeführt, um die CFC-Metrik zu evaluieren. Dabei sollten Studenten die Verständlichkeit vorgegebenener Modelle bewerten. Die Ergebnisse wurden während der Entstehung dieser Diplomarbeit in [Car06] veröffentlicht und bestätigen einen Zusammenhang zwischen der Komplexität eines Prozessmodells und der CFC-Metrik. Ebenfalls wurde eine theoretische Validierung vorgenommen, auf die später noch eingegangen wird[car05a]. Die Metrik wurde ebenfalls von Mendling et al.[mmn + 06] im Rahmen der bereits erwähnten Studie anhand der Fehler im SAP-Referenzmodell praktisch validiert. Dabei konnten sie keinen Zusammenhang mit der Fehlerwahrscheinlichkeit von EPK- Modellen feststellen. Als mögliche Erklärung dafür sehen sie die Messung der Komplexität von OR- Splits, die exponential mit der Anzahl ausgehender Kontrollflusskanten steigt (dieser Aspekt wurde ebenfalls in [GL06] bereits angesprochen). Im Gegensatz dazu bleibt die gemessene Komplexität eines AND-Splits immer 1, unabhängig von der Anzahl ausgehender Kontrollflusskanten. Diese Kritik ist durchaus nachvollziehbar, allerdings ist es nicht der einzige Kritikpunkt an der Metrik. Zumindest bei Anwendung der CFC-Metrik auf EPK-Modelle ist zu kritisieren, dass Startereignisse und Startbelegungen, bei denen der Modellierer ebenfalls alle möglichen ausgehenden Kontrollflüsse analysiert muss, nicht berücksichtigt werden. Ein explizites modellieren mit nur einem Startereignis (und einer Startbelegung), welches vor den eigentlichen Startereignissen eingeführt wird, wird bei der Metrik damit bestraft. Entscheidender bei der CFC-Metrik ist aber, dass die Struktur des Modells kaum berücksichtigt wird. So wird weder die Verschachtelungstiefe von Splitoperatoren berücksichtigt noch der Aspekt, ob die Kontrollstrukturen strukturiert oder unstrukturiert sind. Tatsächlich ist dieses Problem bereits von McCabe bei seiner Metrik der zyklomatischen Zahl aufgegriffen wurden. Er definierte eine zweite Metrik für Kontrollflussgraphen als essential complexity wie folgt: v(f ) ist die zyklomatische Komplexität vom Kontrollflussgraphen F. m ist die Anzahl an D-structures von F. Frank Meyer 39

42 ev(f ) = v(f ) m ist die tatsächliche Komplexität von F. Dabei ist m die Anzahl an Teilgraphen von F, die übliche Kontrollstrukturen der strukturierten Programmierung darstellen (if... then, if... then... else, while... do, do... while). Sie werden auch unter dem Begriff D-structures (Dijkstra-structures) zusammengefasst, für eine detalliertere Beschreibung sei hier auf [McC76, FP97] verwiesen. Ziel der Metrik ist also, die Unstrukturiertheit von Programmen zu messen, d.h. Einsprünge/Aussprünge bei Programmblöcken von Entscheidungen oder Schleifen, wie sie durch GOTO-Statements oder Ausnahmen (Exceptions) möglich sind. Es wird in einem späteren Abschnitt darauf eingegangen, wie sich die Unstrukturiertheit von Geschäftsprozessmodellen messen lässt. Der Ansatz der CFC-Metrik ist von Mendling et al.[mmn + 06] ebenfalls auf Join- Operatoren übertragen worden. Statt der ausgehenden Kontrollflusskanten von Split-Operatoren werden dabei analog die eingehenden Kontrollflusskanten von Join-Operatoren betrachtet. Formal lässt sich der Ansatz wie folgt definieren: Definition 4.12 (Kontrollflusskomplexität der Joinoperatoren) Sei j ein Joinoperator und n die Anzahl der ausgehenden Kanten von j. Seine Komplexität wird je nach Typ von j wie folgt berechnet: JC AND (j) = 1 (j ist AND-Joinoperator) (4.27) JC XOR (j) = n (j ist XOR-Joinoperator) (4.28) JC OR (j) = 2 n 1 (j ist OR-Joinoperator) (4.29) Die Gesamtkomplexität des Kontrollflusses aller Joinoperatoren eines Prozessmodells M wird durch die Summe der einzelnen Komplexitäten berechnet: JC(M) = JC AND (j) + JC XOR (j) j ist AND-Join j ist XOR-Join (4.30) + JC OR (j) j ist OR-Join Mendling et al. konnten keinen Zusammenhang zwischen der Metrik und der Fehlerwahrscheinlichkeit von EPK-Modellen feststellen. Die für die CFC-Metrik genannten Kritikpunkte lassen sich mit Ausnahme der fehlenden Berücksichtigung von Startereignissen bei EPK-Modellen auch bei der JC-Metrik nennen. Als zusätzlicher Kritikpunkt ist hier die fehlende Berücksichtigung von Endereignissen bei EPK-Modellen zu nennen, analog wie Startereignisse bei der CFC-Metrik. Sowohl die CFC-Metrik als auch die JC-Metrik lassen sich auch auf UML 2- Aktivitätsdiagramme anwenden. Eine Übertragung der zyklomatischen Komplexität ist auch bereits für ein UML-Modellierungstool geplant (Borland Together-Tool, 40 Frank Meyer

43 siehe [Gro04]), eine genauere Definition und eine praktische Validierung liegt allerdings nicht vor. Die Kritik an der fehlenden Berücksichtigung von Startereignissen/ bei der CFC-Metrik ist für Aktivitätsdiagramme aufgrund der unterschiedlichen Semantik nicht von Bedeutung. Frank Meyer 41

44 4.4 Verschachtelungstiefe Wie bereits erwähnt, ist ein Kritikpunkt an der zyklomatischen Zahl die fehlende Berücksichtigung der Verschachtelung von Entscheidungsstrukturen. Deshalb sind im Softwarebereich verschiedene Metriken für die Verschachtelungstiefe vorgeschlagen worden, die wie die zyklomatische Metrik auf dem Kontrollflussgraphen eines Programms beruhen. Der intuitiv am nächsten liegende Ansatz geht von den Strukturprimitiven (D-structures) der strukturierten Programmierung aus und zählt deren Verschachtelung ineinander. Dieser Ansatz lässt sich aber nicht für unstrukturierte Programmteile verwenden, was ein entscheidender Nachteil ist, da davon ausgegangen werden kann, dass insbesondere Unstrukturiertheit die Komplexität eines Programms erhöht. Anfang der 1980er Jahre wurde von Harrison und Magel[HM81] eine Metrik für die Verschachtelungstiefe von Entscheidungsstrukturen vorgestellt, die auch die unstrukturierten Programmteile berücksichtigt. Zentraler Punkt der Metrik ist, dass in einem Kontrollflussgraphen - zumindest falls er nur einen Endknoten besitzt - für jeden Entscheidungsknoten m nachfolgende Knoten existieren, die auf jedem Weg von m zum Endknoten des Kontrollflussgraphen durchlaufen werden müssen. Diese Knoten werden untere Schranken von m genannt. Einer dieser nachfolgenden Knoten, als größte untere Schranke von m bezeichnet, liegt dabei auf allen Wegen zwischen m und dem Endknoten vor allen anderen nachfolgenden Knoten. Der von m einerseits und seiner größten unteren Schranke anderseits begrenzte Teilgraph des Kontrollflussgraphen wird Einflussbereich von m genannt, wobei die größte untere Schranke selbst nicht zum Einflussbereich gezählt wird. Das Prinzip lässt sich unter Berücksichtigung mehrerer Endknoten auch für Modellgraphen von Geschäftsprozessen anwenden: 1. Ein Knoten lb heißt untere Schranke eines Knoten k, wenn er auf allen Wegen von k zu einem Endknoten liegt. 2. Ein Knoten glb heißt größte untere Schranke eines Knoten k, wenn er untere Schranke von k ist und auf allen Wegen zwischen k und einem Endknoten vor allen anderen unteren Schranken von k liegt. 3. Der Einflussbereich SCOP E(k) eines Knoten k wird gebildet durch den Teilgraphen, der von k einerseits und von der größten unteren Schranke glb von k andererseits begrenzt wird. Die Knoten aller Wege zwischen k und glb sowie alle Kanten zwischen diesen Knoten gehören zum Teilgraphen, glb selbst sowie die entsprechenden Kanten mit glb als Zielknoten gehören nicht zum Teilgraphen. Falls keine untere Schranke für k existiert, gehören alle Nachfolger von k zum Teilgraphen, der den Einflussbereich SCOP E(k) bildet. Beim Einflussbereich eines Splitoperators wird eine Fallunterscheidung vorgenommen, ob eine (größte) untere Schranke existiert. Nicht für alle Splitoperatoren muss eine untere Schranke existieren. Als Gründe dafür sind zwei Faktoren zu nennen: 42 Frank Meyer

45 Abbildung 7: Beispielmodelle zur Verschachtelungstiefe: EPK-Modell mit mehreren Endereignissen 1. Mehrere Endknoten: Sowohl EPK-Modelle als auch UML-Aktivitätsdiagramme können mehrere Endknoten besitzen. Abb. 7 zeigt ein Ausschnitt eines EPK- Modells, das mehrere Endereignisse besitzt. Für beide Splitoperatoren im Modell kann keine untere Schranke gebildet werden. Dieser Aspekt wurde bei der Definition des Einflussbereichs von Entscheidungsknoten in Kontrollflussgraphen bei [HM81] nicht berücksichtigt. Tatsächlich ist es aber auch bei Programmmodulen denkbar, dass ihre Kontrollflussgraphen mehrere Endknoten besitzen, bspw. durch mehrere Rückgabeanweisungen in Methoden oder bei Ausnahmen. 2. Tote Bereiche : Eine zweite Möglichkeit besteht durch die in unserer Syntaxdefinition bereits ausgeschlossenen toten Bereiche, aus denen nie ein Endknoten erreicht werden kann und deren Knoten damit keine untere Schranke besitzen. Ausgehend von ihrer Definition des Einflussbereichs eines Entscheidungsknoten in einem Kontrollflussgraph haben Harrison und Magel folgende Metrik vorgeschlagen: F ist ein Kontrollflussgraph. Jeder Knoten k F hat eine Grundkomplexität von 1. Für jeden Entscheidungsknoten m F wird eine zusammengesetzte Komplexität berechnet, die sich aus der Summe der Grundkomplexitäten aller Knoten im Einflussbereich von m bildet. Für alle anderen Knoten ist die zusammengesetzte Komplexität gleich der Grundkomplexität. Frank Meyer 43

46 Die Gesamtkomplexität von F wird aus der Summe der zusammengesetzen Komplexitäten aller Knoten berechnet. Die Metrik berücksichtigt also sowohl die Größe des Kontrollflussgraphen als auch die Verschachtelungstiefe. Piwowarski[Piw82] zeigte, dass die vorgeschlagene Metrik ebenso wie einige andere Metriken verschachtelte (strukturierte) Kontrollstrukturen mit einer höheren Komplexität bewertet als unstrukturierte Kontrollstrukturen. Er schlug deshalb eine alternative Metrik vor, die ebenfalls das Prinzip des Einflussbereichs eines Entscheidungsknotens verwendet. Die Metrik ist wie folgt definiert: F ist ein Kontrollflussgraph. Für jeden Entscheidungsknoten m F wird eine Komplexität berechnet aus der Anzahl an Entscheidungsknoten m F, m m, deren Einflussbereich sich mit dem Einflussbereich von m teilweise oder vollständig überschneidet. Die Gesamtkomplexität von F wird aus der Summe der Komplexitäten aller Entscheidungsknoten von F berechnet. Zusätzlich wird noch die zyklomatischen Komplexität von F hinzuaddiert. Die Metrik von Harrison und Magel berücksichtigt den Aspekt der allgemeinen Größe des Modells zusammen mit der Verschachtelungstiefe, indem sie alle Knoten in verschachtelten Strukturen mehrmals zählt. Piwowarski hingegen berücksichtigt sowohl die Verschachtelungstiefe als auch Teilaspekte von Unstrukturiertheit. Bei unserer Metrik wollen wir uns auf die Anzahl an Splitoperatoren beschränken, die sich im Einflussbereich eines Splitoperators befinden. Zum Einflussbereich zählt auch der betrachtete Splitoperator selbst. Jeder Splitoperator hat also mindestens eine Komplexität von 1 bzgl. der Verschachtelungstiefe. Definition 4.13 (Metrik zur Verschachtelungstiefe) Sei s ein Splitoperator und SCOP E(s) sein Einflussbereich. Die Komplexität seiner Verschachtelungstiefe wird berechnet durch: N L(s) = Anzahl Splitoperatoren in SCOP E(s) (4.31) Die Gesamtkomplexität der Verschachtelungstiefe eines Prozessmodells M ergibt sich aus den Komplexitäten aller Splitoperatoren: N estinglevel(m) = NL(s) (4.32) s ist Splitoperator 44 Frank Meyer

47 4.5 Metrik zur Unstrukturiertheit Bei einigen der vorherigen Metriken spielte Unstrukturiertheit von Modellen als Faktor für Komplexität eine Rolle. So haben wir für Zyklen als einen möglichen Aspekt von Unstrukturiertheit eigene Metriken definiert. In der Metrik zur Verschachtelungstiefe in Kapitel 4.4 haben wir eine Metrik zu Kontrollflussgraphen von Programmen erwähnt, die u.a. auch Unstrukturiertheit in Form sich nur teilweise überschneidender Einflussbereiche von Splitoperatoren berücksichtigt. Auch die in [MMN + 06] definierte und in Kapitel vorgestellte Metrik RATIO_JS, die das Verhältnis zwischen Joinoperatoren und Splitoperatoren misst, basiert auf einem Aspekt von Unstrukturiertheit. Alle Ansätze messen aber nur Einzelfaktoren von Unstrukturiertheit und dies teilweise auch nur als Nebeneffekt der eigentlichen Metrik. Dass Modelle, die nicht wohlstrukturiert sind, zu semantischen Fehlern wie Deadlocks führen können, wurde in [CS94, Aal99] gezeigt. Ziel in diesem Abschnitt ist es, eine Metrik zu definieren, die den Grad von Unstrukturiertheit in einem Modell misst. Ausgangspunkt der Überlegungen ist es also, Teilstrukturen in einem Modell, die als unstrukturiert gewertet werden, zu identifizieren. Da für Unstrukturiertheit in ein Modell generell Verknüpfungsoperatoren verantwortlich sind, stehen diese im Blickpunkt unserer Betrachtungen. Ziel ist es dabei insbesondere, zu jedem Splitoperator einen passenden Joinoperator und umgekehrt zu jedem Joinoperator einen passenden Splitoperator zu identifizieren. Als Faktoren für Unstrukturiertheit lassen sich vier Bereiche nennen: Zyklen: Falls ein Modell Zyklen enthält, kann dies zu semantischen Fehlern führen. Der Aspekt von Zyklen in einem Modell wurde bereits in Kapitel 4.2 besprochen und Metriken zur Messung ihrer Komplexität vorgestellt. In diesem Kapitel werden wir unterscheiden, wann ein Zyklus als unstrukturiert und wann als wohlstrukturiert angesehen werden kann. Typen von Split- und Joinoperatoren: Wenn von einem Splitoperator aus ein Joinoperator erreicht werden kann und die Typen der beiden Operatoren unterschiedlich sind (d.h. keine Kombination AND - AND, OR - OR, XOR - XOR vorliegt), kann es zumindest bei einigen Kombinationen von Typen zu semantischen Fehlern kommen. Falls von einem Splitoperator mindestens zwei zyklenfreie Wege zu einem Joinoperator existieren, die sich nicht überschneiden, und die Typen der beiden Operatoren unterschiedlich sind, ist dies als Unstrukturiertheit anzusehen. Einsprünge und Aussprünge: Eine Unstrukturiertheit im Modell liegt ebenfalls vor, falls es einen Weg von einem Startknoten zu einen Knoten im Einflussbereich eines Splitoperators gibt, der den Splitoperator selbst nicht enthält. In der bereits vorgestellten Metrik zur Verschachtelungstiefe von Kontrollflussgraphen von Piwowarski[Piw82] wurde dieser Aspekt berücksichtigt. Passender Joinoperator zu einem Splitoperator: Zu jedem Splitoperator gehört idealerweise ein passender Joinoperator und umgekehrt. Daraus folgt, Frank Meyer 45

48 dass von einem Splitoperator nur ein Joinoperator auf zwei sich nicht überschneidenden Wegen (außer im Splitoperator und im Joinoperator selbst) erreicht werden sollte, ansonsten liegt eine Unstrukturiertheit vor. Im Folgenden gehen wir davon aus, dass ein EPK-Modell keine toten Bereiche enthält, wie wir es bereits bei unserer Syntaxdefinition ausgeschlossen haben. Ebenfalls gehen wir davon aus, dass nur ein Startknoten und ein Endknoten existiert. [Aal99] bezeichnet ein solches Modell als reguläres Modell. Nun sind Modelle, die nur ein Startknoten und einen Endknoten haben, in der Praxis nicht die Regel. Aber jede EPK kann so erweitert werden, dass es nur ein Startknoten und Endknoten besitzt. Wichtig dabei ist bei unseren Betrachtungen, dass eine solche Erweiterung keine zusätzlichen Aspekte von Unstrukturiertheit in das Modell bringt. Für jeden Splitoperator, der noch keinen passenden Joinoperator besitzt, wird ein passender Joinoperator vom gleichen Typ hinzugefügt. Gleiches gilt für Joinoperatoren, die noch keinen passenden Splitoperator besitzen. Da wir für jeden Splitoperator bewerten wollen, ob dieser unstrukturiert ist, ist zu betonen, dass diese Konstruktion uns nur als Hilfskonstruktion zur Bewertung von Unstrukturiertheit dient. Für die zusätzlich eingefügten Split- und Joinoperatoren selbst werden wir nicht bewerten, ob diese als unstrukturiert anzusehen sind. Wir wiederholen einige Begriffe, die wir bereits in Kapitel 4.2 eingeführt hatten, und führen einige neue ein: 1. Ein Knoten k heißt Ausstiegsknoten aus einem elementaren Zyklus K cycle, falls k zur Knotenmenge von K cycle gehört und es einen Weg von k zu einem Endknoten gibt, der keinen anderen Knoten von K cycle durchläuft (Ein solcher Knoten muss demzufolge ein Splitoperator sein). 2. Ein Knoten k heißt Einstiegsknoten in einen elementaren Zyklus K cycle, falls k zur Knotenmenge von K cycle gehört und es einen Weg von einem Startknoten zu k gibt, der keinen anderen Knoten von K cycle durchläuft (Ein solcher Knoten muss demzufolge ein Joinoperator sein). 3. Eine Kontrollflusskante e von einem Splitoperator s zu einem Knoten k heißt Rückwärtsschritt für s, wenn s und k zu einem elementaren Zyklus gehören, aus dem s ein Ausstiegsknoten ist. 4. Eine Kontrollflusskante e von einem Splitoperator s zu einem Knoten k heißt Vorwärtsschritt für s, wenn sie kein Rückwärtsschritt für s ist. 5. Ein Joinoperator j steht zu einem Splitoperator s in einer Beziehung corr_vorwaerts(s, j), falls gilt: Es existieren mindestens zwei Wege von s zu j, die mit einem Vorwärtsschritt für s beginnen und die sich außer in s und j selbst nicht überschneiden. 6. Ein Joinoperator j steht zu einem Splitoperator s in einer Beziehung corr_rueckwaerts(s, j), falls gilt: Es existieren mindestens zwei Wege von s zu j, die mit einem Rückwärtsschritt für s beginnen und die sich außer in s und j selbst nicht überschneiden. 46 Frank Meyer

49 Abbildung 8: Beispielmodelle zur Unstrukturiertheit (1): Aufteilung der ausgehenden Kanten eines Splitoperators in Vorwärtsschritte und Rückwärtsschritte Abb. 8 zeigt ein Modellausschnitt, an dem wir die Begriffe Rückwärtsschritt und Vorwärtsschritt erläutern wollen. Der Splitoperator S1 besitzt die ausgehenden Kanten Kante 1, Kante 2 und Kante 3. Kante 1 ist ein Rückwärtsschritt für S1, da sie zum Zyklus S1-J1-S1 gehört, aus dem S1 ein Ausstiegsknoten ist. Ebenso ist Kante 3 ein Rückwärtsschritt für S1. Sie gehört zum Zyklus S1-S2-J1-S1. Kante 2 hingegen ist ein Vorwärtsschritt für S1, da kein Zyklus existiert, bei dem sie Bestandteil ist und S1 ein Ausstiegsknoten ist. Für den Splitoperator S2 ist die Kante Kante 5 ein Rückwärtsschritt, da sie zum Zyklus S2-J1-S1-S2 gehört. Kante 4 ist hingegen für S2 ein Vorwärtsschritt. Basierend auf der Trennung der ausgehenden Kanten eines Splitoperators in Vorwärts- und Rückwärtsschritte stellen wir folgende Forderungen an einen Splitoperator, die er zu erfüllen hat, um wohlstrukturiert zu sein: Definition 4.14 (Unstrukturiertheit eines Splitoperators) Sei s ein Splitoperator. Folgende Forderungen muss s erfüllen, damit er wohlstrukturiert ist: 1. Falls es mehr als einen Vorwärtsschritt für s gibt, so existiert genau ein Joinoperator j, der mit s in einer Beziehung corr_vorwaerts(s, j) steht. 2. Falls es mehr als einen Vorwärtsschritt für s gibt und der Joinoperator j mit einer Beziehung corr_vorwaerts(s, j) eindeutig bestimmt ist, so muss zusätzlich gelten: Frank Meyer 47

50 (a) j besitzt den gleichen Typ wie s. (b) Es gibt keinen Weg von einem Startknoten zu j, der nicht s durchläuft. (c) Es gibt keinen Weg von j zu j, der nicht s durchläuft. 3. Falls ein Rückwärtsschritt für s existiert, muss s vom Typ XOR sein. 4. Falls es mehr als einen Rückwärtsschritt für s gibt, so existiert genau ein Joinoperator j, der mit s in einer Beziehung corr_rueckwaerts(s, j) steht. 5. Falls es mehr als einen Rückwärtsschritt für s gibt und der Joinoperator j mit einer Beziehung corr_rueckwaerts(s, j) eindeutig bestimmt ist, so muss j XOR als Typ haben. 6. Alle elementaren Zyklen, bei denen s ein Ausstiegsknoten ist, haben keinen weiteren Ausstiegsknoten. 7. Alle elementaren Zyklen, bei denen s ein Ausstiegsknoten ist, haben nur einen Einstiegsknoten. 8. Alle elementaren Zyklen, bei denen s ein Ausstiegsknoten ist, haben den gleichen Einstiegsknoten. 9. Alle Einstiegsknoten der elementaren Zyklen, bei denen s ein Ausstiegsknoten ist, besitzen XOR als Typ. Falls s eine oder mehrere der Bedingungen 1, 2a-2c sowie 3-9 nicht erfüllt, so ist s unstrukturiert. Wir wollen nun auf die einzelnen Forderungen an einen Splitoperator in Def näher eingehen. In den Bedingungen 1 sowie 2a-2c bzgl. der Vorwärtsschritte betrachten wir nur solche Splitoperatoren, die mindestens zwei Vorwärtsschritte besitzen. Splitoperatoren, die nur einen Vorwärtsschritt besitzen, werden also generell - zumindest in Hinblick auf die Vorwärtsschritte - als wohlstrukturiert angesehen. Das linke Modell in Abb. 9 zeigt ein Beispiel dafür. Falls der Splitoperator mindestens zwei Vorwärtsschritte besitzt, so existiert in jedem Fall ein Joinoperator, der die Beziehung corr_vorwaerts(s, j) erfüllt. Dies folgt daraus, dass wir nur reguläre EPKs betrachten. Falls mehrere Joinoperatoren die Beziehung corr_vorwaerts(s, j) erfüllen, so sehen wir den Splitoperator als unstrukturiert an. Ein Beispiel für einen Splitoperator, der in diesem Sinne unstrukturiert ist, ist im rechten Modell in Abb. 9 zu sehen. Die Forderungen 2a-2c sind relevant, falls ein Joinoperator j mit corr_vorwaerts(s, j) eindeutig existiert. Dabei fordern wir in 2a, dass die Typen von s und j gleich sein müssen. Ein Beispiel, das dies nicht erfüllt, ist in Abb. 10 im linken Modell zu sehen. In den beiden weiteren Bedingungen fordern wir, dass es keine Einsprünge gibt. Beispiele, die diese Bedingungen nicht erfüllen, sind in Abb. 10 im mittleren und im rechten Modell zu sehen. Zusätzlich sei hier festgestellt, dass alle Wege von s zum Endknoten durch j gehen, falls j mit 48 Frank Meyer

51 Abbildung 9: Beispielmodelle zur Unstrukturiertheit (2): Unstrukturiertheiten der Vorwärtsschritte Abbildung 10: Beispielmodelle zur Unstrukturiertheit (3): Unstrukturiertheiten der Vorwärtsschritte Frank Meyer 49

52 Abbildung 11: Beispielmodelle zur Unstrukturiertheit (4): Unstrukturiertheiten der Rückwärtsschritte corr_vorwaerts(s, j) eindeutig ist. Ansonsten müsste es mehrere Joinoperatoren geben, die corr_vorwaerts(s, j) erfüllen. Bei den Rückwärtsschritten fordern wir, dass ein Splitoperator vom Typ XOR ist, falls mindestens ein Rückwärtsschritt für ihn existiert (Forderung 3). Falls es mehr als einen Rückwärtsschritt gibt, so existiert mindestens ein Joinoperator j, der die Beziehung corr_rueckwaerts(s, j) erfüllt. Wir fordern in Bedingung 4, dass dieser eindeutig ist und in Bedingung 5, dass er vom Typ XOR ist, d.h. vom selben Typ, wie wir es vom Splitoperator erwarten. In Abb. 11 zeigen wir Beispielmodelle, die diese Bedingungen nicht erfüllen. Die Forderungen 6-9 beziehen sich auf die elementaren Zyklen, aus denen der Splitoperator ein Ausstiegsknoten ist. Zusammengefasst fordern wir hier, dass es für diese elementaren Zyklen nur einen Ausstiegsknoten gibt (nämlich den Splitoperator selbst) und einen Einstiegsknoten, der für alle elementaren Zyklen der gleiche sein muss und der vom Typ XOR sein muss. Beispiele, die dies nicht erfüllen, sind in Abb. 12 gezeigt. Im linken Modell ist sowohl S1 als auch S2 Ausstiegsknoten für den Zyklus S1-S2-J1-S1. Im mittleren Modell hat der Zyklus S1-J2-S1 den Einstiegsknoten J2 und der Zyklus S1-J1-J2-S1 den Einstiegsknoten J2. Dass der Einstiegsknoten nicht der gleiche Joinoperator wie der Joinoperator mit der Beziehung corr_rueckwaerts(s, j) sein muss, wird aus dem rechten Beispielmodell in Abb. 12 deutlich. Der Joinoperator J1 ist hier Einstiegsknoten, der Joinoperator J2 erfüllt hingegen die Beziehung corr_rueckwaerts(s, j). Bislang entscheiden wir nur für Splitoperatoren, ob sie als unstrukturiert anzusehen sind oder nicht. Dass dies nicht ausreicht, sei an Abb. 13 und Abb. 14 verdeutlicht. Mit dem bisherigen Ansatz, jeweils nur die Splitoperatoren zu betrachten, würde eine Metrik, die die Anzahl der unstrukturierten Splitoperatoren zählt, folgendes Verhältnis zwischen den Modellen ergeben: 50 Frank Meyer

53 Abbildung 12: Beispielmodelle zur Unstrukturiertheit (5): Unstrukturiertheiten der Rückwärtsschritte C(Modell_1) = C(Modell_2) = C(Modell_3) = C(Modell_4) Intuitiv sind aber die Modelle 2 und 3 unstrukturierter als die Modelle 1 und 4. Eine ideale Metrik zur Unstrukturiertheit würde gewährleisten, dass gilt: C(Modell_1) = C(Modell_4) C(Modell_3) C(Modell_2) Wir bewerten deshalb nicht nur für einen Splitoperator, ob er unstrukturiert ist, sondern auch für einen Joinoperator. Dafür machen wir uns zunutze, dass wir die Richtung aller Kontrollflusskanten ändern können und dadurch ein gleichfalls gültiges EPK-Modell erhalten. Wir nennen ein solches Modell M das inverse Modell zu einem ursprünglichen Modell M. Die Splitoperatoren von M werden durch die Umkehrung der Kanten zu Joinoperatoren in M, die Joinoperatoren von M werden zu Splitoperatoren in M. Ebenso wird ein Startereignis in M zu einem Endereignis M und ein Endereignis in M zu einem Startereignis in M. Danach beurteilen wir auf die gleiche Weise wie für das ursprüngliche Modell M für die Splitoperatoren von M, ob sie unstrukturiert sind. Eine Metrik, die die Anzahl der unstrukturierten Splitoperatoren im Ursprungsmodell und die Anzahl der unstrukturierten Splitoperatoren im inversen Modell zählt, hat für unsere Beispielmodelle aus den Abbildungen 13 und 14 dann folgendes Verhältnis: Frank Meyer 51

54 Abbildung 13: Beispielmodelle zur Unstrukturiertheit (7) Abbildung 14: Beispielmodelle zur Unstrukturiertheit (8) 52 Frank Meyer

55 Modell Komplexität Unstrukturierte Splitoperatoren und Joinoperatoren (unstrukturiert im inversen Modell) Modell 1 4 S1, S2, J1, J2 Modell 2 6 S1, S2, J1-J4 Modell 3 6 S1, S2, J1-J4 Modell 4 4 S1, S2, J1, J2 Tabelle 3: Beispielmodelle zur Unstrukturiertheit: Komplexitäten der Beispielmodelle. C(Modell_1) = C(Modell_4) < C(Modell_3) = C(Modell_2) Zusammenfassend definieren wir die Metrik zur Unstrukturiertheit wie folgt: Definition 4.15 (Metrik zur Unstrukturiertheit) Sei M ein Modell und M das inverse Modell von M. Die Unstrukturiertheit von M wird berechnet durch: U nstructured(m) = Anzahl unstrukturierter Splitoperatoren in M + Anzahl unstrukturierter Splitoperatoren in M (4.33) Modelle, die nicht regulär sind, können wir wie bereits geschrieben zur Berechnung der Unstrukturiertheit einfach zu regulären Modellen erweitern. Wir zählen bei der Metrik dann nur die Anzahl der unstrukturierten Splitoperatoren des ursprünglichen Modells sowie des inversen Modells vom ursprünglichen Modell. Die Komplexitäten für die Beispielmodelle in Abb. 13 und Abb. 14 sind in Tabelle 3 aufgeführt. Eine Schwäche der Metrik ist sicherlich, dass sie recht umfangreich ist. Dies ist zwar kein großes Problem bei der Implementierung und Berechnung, da Geschäftsprozessmodelle in der Regel relativ klein sind. Es kann aber ein Problem bei der Akzeptanz in der Praxis sein, auch wenn sie sich als geeignet für die Komplexitätsmessung herausstellt. Fenton und Neil[FN99] weisen darauf hin, dass im Bereich von Komplexitätsmetriken für Software vor allem einfache Metriken in der Praxis bevorzugt werden. Ähnliches kann für Metriken für Geschäftsprozessmodelle vermutet werden. Frank Meyer 53

56 4.6 Metriken zum Informationsfluss Eine der bekanntesten Komplexitätsmetriken für Programme ist die Fan-in/Fan-out- Metrik von Henry und Kafura[HK81]. Diese misst den zwischen Programmmodulen. Als Fan-in eines Programmmoduls wird dabei die Anzahl der Aufrufe des Moduls durch andere Module bezeichnet. Als Fan-out eines Programmmoduls wird bezeichnet, wie oft das betrachtete Modul andere Module aufruft. Ein Modul, das einen hohen Fan-out besitzt, kennzeichnet üblicherweise ein allgemeines Modul, welches nicht für Detailaufgaben des Programms zuständig ist. Ein Modul mit einem hohen Fan-in kennzeichnet ein Modul, das eine spezielle Detailaufgabe im Programm übernimmt, die häufig verwendet wird. Wenn nun ein Modul sowohl einen hohen Fan-in-Wert als auch einen hohen Fan-out-Wert besitzt, so weist dies auf eine schlechte Aufteilung des Programms hin. Die Komplexität des Informationsflusses eines Programmmoduls wird mit der Metrik wie folgt berechnet: IF (M) = Length(M) (F an_in(m) F an_out(m)) 2 Length(M) ist hierbei die interne Komplexität des Programmmoduls, wie sie bspw. durch die LOC-Metrik oder durch die zyklomatische Zahl berechnet werden kann. Ein Problem bei der Metrik ist sicherlich, dass die Komplexität eines Programmmoduls 0 beträgt, sobald ein Teilaspekt (Länge, Fan-in, Fan-out) einen Wert von 0 besitzt. Für Geschäftsprozessmodelle wurden bereits zwei Komplexitätsmetriken vorgeschlagen, die auf der Metrik von Henry und Kafura beruhen. Der erste Ansatz[CMNR06] bezieht sich auf den Informationsfluss innerhalb eines Modells bzw. Teilmodells. Der zweite Ansatz[GL06] misst den Informationsfluss zwischen Teilmodellen, die durch hierarchische Funktionen verbunden sind Informationsfluss innerhalb eines Modells In [CMNR06] wurde eine Übertragung der Fan-in/Fan-out-Metrik auf die Aktivitäten eines Geschäftsprozessmodells vorgeschlagen. Die Komplexität einer Aktivität wird dabei wie folgt berechnet: IC = Länge (Anzahl Eingänge Anzahl Ausgänge) 2 Als Eingänge (Fan-in) werden die eingehenden Verbindungen, als Ausgänge (Fanout) die ausgehenden Verbindungen zu anderen Aktivitäten bezeichnet. Eine genauere Spezifizierung des Faktors Länge unterbleibt, hier ist aber eine Kombination mit den Kontrollflussmetriken von Split- und Joinoperatoren denkbar, wie sie auch bei Henry und Kafura erwähnt wird. 54 Frank Meyer

57 Etwas unklar ist, welche Knotentypen in diesem Ansatz als Aktivitäten gewertet werden, insbesondere bei EPK-Modellen, wie mit Ereignissen umgegangen wird. Wir definieren die Metrik deshalb allgemeiner für alle Knoten in einem Modell wie folgt: Definition 4.16 (Metrik zum Informationsfluss innerhalb eines Modells) Sei M ein Modell und k ein Knoten in M. Die Komplexität des Informationsflusses von k wird wie folgt berechnet: IC(k) = (Anzahl eingehende Kanten zu k Anzahl ausgehende Kanten von k) 2 (4.34) Die Gesamtkomplexität von M ergibt sich aus der Summe der Komplexitäten aller Knoten: IC(M) = IC(k) (4.35) k Knoten in M Auf die Berücksichtigung einer internen Komplexität jedes Knoten wird verzichtet, auch wenn sie z.b. durch den jeweiligen Knotentypen bestimmt werden könnte. Dafür fehlt aber eine Begründung, welcher Knotentyp welche interne Komplexität besitzen soll bzw. als wie komplex er im Vergleich zu anderen Knotentypen gewertet werden soll. Bei dieser Metrik sollte beachtet werden, dass sie dem ursprünglichen Gedanken der Metrik von Henry und Kafura nur sehr begrenzt entspricht. So ist es ohne weiteres denkbar, dass eine Aktivität bzw. eine Funktion oder eine Ereignis an unterschiedlichen Stellen des Modells wiederholt verwendet wird. Mit der vorgestellten Metrik wird dieser Aspekt nicht beachtet, da kein Zusammenhang zwischen verschiedenen Vorkommen der gleichen Aktivität in einem Modell hergestellt wird Informationsfluss bei hierarchischen Modellen Eine andere Verwendung der Metrik von Henry und Kafura für Geschäftsprozessmodelle ist in [GL06] vorgeschlagen worden. Häufig sind Modelle aufgeteilt in Teilmodelle, um größere Prozessmodelle besser verwalten und Teilmodelle ggf. wiederverwenden zu können. Bei EPK-Modellen erfolgt dies in vertikaler Form durch hierarchische Funktionen. Die vorgeschlagene Metrik misst den Informationsfluss zwischen den Teilmodellen. Als Fan-in eines Teilmodells wird dabei die Anzahl an Aufrufen durch andere Teilmodelle bezeichnet, bei EPK-Modellen also die Anzahl an hierarchischen Funktionen, die auf das betrachtete Teilmodell verweisen. Als Fanout eines Teilmodells wird die Anzahl an Aufrufen anderer Teilmodelle bezeichnet, d.h. die Anzahl an hierarchischen Funktionen im betrachteten Teilmodell. Wenn ein Teilmodell nun sowohl einen hohen Fan-in als auch einen hohen Fan-out besitzt, deutet dies auf eine schlechte Modularisierung des Modells hin. Frank Meyer 55

58 Definition 4.17 (Metrik zum Informationsfluss zwischen Teilmodellen) Die Komplexität des Informationsflusses eines Teilmodells M wird wie folgt berechnet: IF (M ) = (Anzahl M aufrufende hierarchische Funktionen Anzahl hierarchische Funktionen in M ) 2 (4.36) Die Komplexität eines Gesamtmodells M ergibt sich aus der Summe der Komplexitäten aller Teilmodelle: IF (M) = IF (M ) (4.37) M Teilmodell von M 56 Frank Meyer

59 4.7 Metriken zum graphischen Layout Alle bisher vorgestellten Metriken verwenden die logische Struktur der Modelle. Für das Verständnis eines Modells ist aber ebenso die graphische Repräsentation von Bedeutung. Vergleichbar ist in der Softwareentwicklung das Layout des Quellcodes eines Programms entscheidend für das Verständnis des Quellcodes durch Entwickler. Hier werden deshalb häufig Vorgaben zum Layout eingesetzt, die Entwickler für ihren Programmcode einzuhalten haben. Dadurch soll es anderen Entwicklern erleichtert werden, den Programmcode verstehen zu können. Solche Vorgaben ( code conventions ) betreffen die Verwendung von Tabulatoren oder Leerzeichen bei Einrückungen, Namenskonventionen für Variablen und Methoden oder die maximale Zeilenlänge. Viele dieser Vorgaben lassen sich automatisiert überprüfen. So kann z.b. verhindert werden, dass Code, der gegen die Vorgaben verstösst, von einem Versionsverwaltungsystem akzeptiert wird. Ähnliche Vorgaben, wie sie für Programmcode üblich sind, lassen sich auch für graphische Modelle aufstellen. Deshalb scheint es interessant, praktisch zu evaluieren, inwieweit bestimmte stilistische Eigenschaften von graphischen Modellen das Verständnis der Modelle beeinflussen. Generell lassen sich dafür drei Bereiche unterscheiden: Eigenschaften der Modellierungssprache Eigenschaften des Modellierungstool Eigenschaften des Aufbaus eines Modells In den Bereich der Modellierungssprache fällt, welche und wieviele unterschiedliche Elementtypen diese besitzt, wie gut sich die Elementtypen graphisch unterscheiden lassen und welche Möglichkeiten einer Hierarchisierung und Aufteilung in Teilmodelle die Modellierungssprache bietet. Verwiesen sei hier auf eine empirische Studie von Sarshar und Loos[SL05], die das Verständnis der Notation von Verknüpfungsoperatoren zwischen EPKs und Petrinetzen vergleicht. Sie kommen dabei zu dem Ergebnis, dass die Notation von EPKs einfacher zu verstehen ist. Durch die Wahl des Modellierungstools erfährt der Modellierer weitere Einschränkungen, wie er sein Modell gestalten kann. Dies betrifft, inwieweit er die farbliche Gestaltung beeinflussen kann (Hintergrund, Färbung von Elemente, Kantenfärbung,... ), welche Schriftformen er wählen kann und ob er Kanten nur als Strecke oder auch verwinkelt einzeichnen kann. Eigenschaften des Modellaufbaus sind u.a. Größe des Modells, Lage von und Abstand zwischen Elementen und Kantenüberschneidungen. Diese können ebenfalls durch ein Modellierungstool beschränkt werden, so z.b. durch eine maximale Größe des Modells. Eine vollständige Trennung der Bereiche ist also nicht möglich. Im Gegensatz zum zweiten Bereich sind dies aber Eigenschaften, die weitgehend unabhängig vom Modellierungstool betrachtet werden können. Eine Arbeit, die sich mit allen drei Bereichen beschäftigt hat und in der auch bereits Frank Meyer 57

60 einige der Aspekten betrachtet wurden, auf die im Folgenden eingegangen wird, ist [Ama05]. Nur für den Bereich des Modellaufbaus lassen sich Komplexitätsmetriken aufstellen, weshalb sich im Rahmen dieser Arbeit auf diesen Bereich beschränkt wird. Dabei ist zu berücksichtigen, dass sich die meisten Komplexitätsmetriken für das graphische Layout natürlich auch als Konventionen in Modellierungstools implementieren lassen, der Modellierer also bereits beim Verstoß dagegen darauf hingewiesen werden kann. [Amb02] hat eine Reihe solcher Konventionen aufgestellt, die für UML-Diagramme gelten sollten und die automatisch vom Modellierungstool geprüft werden können. Geschäftsprozessmodellen verfügen über einen (oder mehrere) Modelleinstiegspunkte, modelliert durch Startknoten, und über einen oder mehrere Modellendpunkte, modelliert durch Endknoten. Üblicherweise werden Geschäftsprozessmodelle ausgehend von einem Startknoten zu einem Endknoten gelesen. Die Vermutung liegt nahe, dass eine einheitliche Schreibrichtung des Modells das Lesen erleichtert, wobei hier unter Schreibrichtung die Ausrichtung der Kanten gemeint ist. Bei Geschäftsprozessmodellen ist der übliche Gebrauch, diese entweder von links nach rechts oder von oben nach unten zu zeichnen. Für EPK-Modelle wird dabei meistens eine Modellierung von oben nach unten verwendet, hingegen bei UML-Aktivitätsdiagramme eine Modellierung von links nach rechts häufiger verwendet wird. Es kann darüber spekuliert werden, inwieweit die Schreibrichtung vom jeweiligen Kulturkreis und der dort üblichen Schreibrichtung von Texten abhängig ist. Die bei der praktischen Validierung der Metriken verwendeten EPK-Modelle lassen allerdings den Schluß zu, dass es wie bei der Programmierung auch bei der Modellierung von Geschäftsprozessmodellen international Usus ist, den Kontrollfluss von links nach rechts bzw. von oben nach unten zu modellieren. Folgende Vermutungen lassen sich bezüglich der Komplexität der Schreibrichtung aufstellen: Ein Geschäftsprozessmodell, das keine erkennbare Schreibrichtung besitzt, ist schwieriger verständlich als ein Geschäftsprozessmodell, das eine erkennbare Schreibrichtung besitzt. Eine Geschäftsprozessmodell mit einer Schreibrichtung von links nach rechts oder von oben nach unten ist leichter verständlich als ein Geschäftsprozessmodell mit einer Schreibrichtung von rechts nach links oder von unten nach oben. Je mehr Kanten eines Geschäftsprozessmodells gegen die Schreibrichtung des Modells gerichtet sind, desto schwieriger verständlich ist es. Modelle, die über keine erkennbare Schreibrichtung verfügen, indem z.b. die Startund Endknoten im Zentrum des Modells eingezeichnet sind, scheinen in der Praxis nur in Ausnahmefällen vorzukommen. Gleiches gilt für eine Schreibrichtung von rechts nach links oder von unten nach oben. Deshalb werden diese beiden Aspekte bei der Definition der Metrik nicht weiter berücksichtigt. Stattdessen wird die Schreibrichtung wie folgt festgelegt: In einem zweidimensionalen Modellgraphen besitzt jede gerichtete Kante ein oder zwei von insgesamt vier möglichen Richtungen, mit Hilfe des kartesischen Koordinatensystem beschreibbar als +/- x-richtung und +/- y-richtung. Diejenige der vier Richtungen, die von den meisten Kanten verwendet 58 Frank Meyer

61 wird, wird als Schreibrichtung bestimmt. Als Metrik wird nun die Anzahl der Kanten definiert, die als Richtung die Gegenrichtung zur Schreibrichtung besitzen: Definition 4.18 (Schreibrichtung) Sei M ein Modell, n {+x, x, +y, y} diejenige Richtung, die von den Kanten von M am meisten verwendet wird und n die Gegenrichtung von n. Die Komplexität von M bezüglich der Schreibrichtung wird berechnet durch: ST Y LE_W D(M) = Anzahl an Kanten, die n als Schreibrichtung besitzen (4.38) Diese Metrik ist wie bereits oben beschrieben eine Vereinfachung derjenigen Eigenschaften, die für die Schreibrichtung eine Rolle spielen. So könnten Start- und Endknoten bei dieser Metrik durchaus graphisch benachbart sein, die Metrik dennoch eine geringe Komplexität messen. Neben den bereits genannten und nicht berücksichtigten Aspekten spielt es weiterhin eine Rolle, ob eine Kante als Strecke oder verwinkelt gezeichnet ist. Einige Modellierungstools erlauben es, Kanten verwinkelt einzuzeichnen. Die in der praktischen Validierung verwendeten EPK-Modelle lassen den Rückschluß zu, dass verwinkelte Kanten häufig zur Vermeidung von Kantenüberkreuzungen verwendet werden. Diese sind ein weiterer Aspekt der Komplexität des Modelllayouts. Sie erschweren es dem Leser, dem Verlauf einer Kante zu folgen. Als Metrik lässt sich deshalb aufstellen: Definition 4.19 (Überkreuzungen von Kantenlinien) Sei M ein Modell. Die Komplexität von M bezüglich der Überkreuzungen von Kantenlinien wird berechnet durch: ST Y LE_AC(M) = Anzahl an Überkreuzungen der Kanten von M (4.39) Eine Alternative zu Überschneidungen stellen in manchen Fällen verlängerte und ggf. verwinkelte Kantenlinien dar. Aber ebenso, wie es Überkreuzungen von Kanten erschweren, dem Kantenverlauf zu folgen, kann dies bei langen Kantenlinien passieren, insbesondere wenn mehrere Kantenlinien parallel zueinander verlaufen. Ein Modell mit sehr langen Linien wird also schwerer zu verstehen sein, als ein Modell mit kurzen Linien. Definition 4.20 (Durchschnittliche Länge der Kantenlinien) Sei M ein Modell. Die Komplexität von M bezüglich der durchschnittlichen Kantenlänge wird berechnet durch: ST Y LE_AL(M) = Gesamtlänge aller Kanten in M Anzahl Kanten in M (4.40) Die Metrik bezieht sich also auf den Durchschnittswert, womit eine daraus abgeleitete Messung das Problem der fehlenden Additivität hat. Eine Vergleichbarkeit der Messungen ist deshalb nur zwischen Modellen mit einer ähnlichen Anzahl an Kanten sinnvoll. Frank Meyer 59

62 Einige Modellierungssprachen erlauben es, Kanten zu unterbrechen und stattdessen durch sogenannte Konnektoren zu verbinden. Dies kann sinnvoll sein, falls Kanten zu lang werden oder es zu vielen Kantenüberschneidungen kommt. Tatsächlich stellt sich hier die Frage, ob sie dafür eine Erleichterung darstellen, denn der Leser muss im Modell den passenden Gegenkonnektor suchen, der die Kantenlinie weiter fortsetzt. Je mehr Konnektoren ein Modell enthält, desto schwieriger wird sich die Suche danach gestalten. Definition 4.21 (Anzahl an Konnektoren) Sei M ein Modell. Die Komplexität von M bezüglich der Anzahl an Konnektoren wird berechnet durch: ST Y LE_CN(M) = Anzahl an Konnektoren in M (4.41) Die Metrik könnte auch als Umfangsmetrik einordnet werden. Da es sich bei Konnektoren aber nicht um Modellelemente im eigentlichen Sinn handelt, sondern um eine Möglichkeit der graphischen Gestaltung des Modells, wird es in diesem Abschnitt behandelt. In der EPK-Syntax sind keine Konnektoren vorgesehen, wenngleich eine Einführung keine weiteren Schwierigkeiten bereiten würde. Im UML 2- Standard sind sie für Aktivitätsdiagramme bereits definiert. 60 Frank Meyer

63 4.8 Weitere Metriken Neben den vorgestellten sind einige weitere Komplexitätsmetriken für den Kontrollfluss von Geschäftsprozessmodellen vorgeschlagen worden. Diese sollen hier kurz vorgestellt werden. Bei der Implementierung der Metriken können sie nicht weiter berücksichtigt werden, teils weil sie erst im Laufe der Arbeit veröffentlicht worden sind, teils weil für eine genauere Definition und Implementierung weitere Vorarbeiten in Form empirischer Studien notwendig sind. 1. Designpatterns: In [GL06] wurde vorgeschlagen, Designpatterns für Metriken zu verwenden. So können sich als zuverlässig bekannte Muster, die dem Modellierer und dem Leser eines Modells leicht verständlich sind, positiv auf die Komplexität eines Modells auswirken. Als schlecht bekannte Muster (Antipatterns) können sich hingegen negativ auf die Verständlichkeit eines Modells auswirken. Ziel einer Metrik für Designpatterns und Antipatterns wäre es also, solche Muster zu erkennen und zu bewerten. 2. Kognitive Gewichte: Ebenfalls in [GL06] sowie in [CMNR06] wurde vorgeschlagen, Kontrollstrukturen in einem Modell (bspw. Sequenzen, Iterationen, Entscheidungen) jeweils mit einem spezifischen kognitiven Gewicht zu bewerten, welches den Schwierigkeitsgrad repräsentiert, den ein Mensch zur Erfassung der Kontrollstruktur aufwenden muss. Die Gesamtkomplexität eines Modells ergibt sich dann aus den kognitiven Gewichten seiner Kontrollstrukturen. 3. Halstead Metrik: In [CMNR06] wurde die Adaption der Halstead-Metrik[Hal77] auf Prozessmodelle vorgeschlagen. Ausgehend von der Anzahl voneinander unabhängiger Kontrollflusselemente (Aktivitäten, Splits, Joins,... ) und der Anzahl unabhängiger Datenflusselemente und ihrer jeweiligen Vorkommen in einem Modell werden analog Variablen zur Prozesslänge, zum Prozessvolumen und zur Schwierigkeit eines Prozesses abgeleitet. Frank Meyer 61

64 Metrikname Metrik Kapitel Literatur CFC Kontrollfluss-Komplexität der 4.3 [Car05b] Splitkonnektoren JC Kontrollfluss-Komplexität der 4.3 [MMN + 06] Joinkonnektoren CSC Komplexität der Äquivalenzklassen 4.2 von Zyklen N_CYCLES Anzahl elementarer Zyklen 4.2 N_CSETS Anzahl Äquivalenzklassen von 4.2 Zyklen IC Informationsfluss zwischen Knoten 4.6 [CMNR06] IF Informationsfluss zwischen Modellen 4.6 [GL06] STYLE_AL durchschnittliche Kantenlänge 4.7 [Ama05] STYLE_AC Kantenüberschneidungen 4.7 [Ama05] STYLE_WD Schreibrichtung 4.7 [GL06] STYLE_CN Anzahl Konnektoren 4.7 NestingLevel Verschachtelungstiefe 4.4 RATIO_CFE Verhältnis Verknüpfungsoperatoren Ereignisse und Funktio- nen RATIO_CF Verhältnis Verknüpfungsoperatoren Funktionen RATIO_JS Verhältnis Joins - Splits [MMN + 06] Unstructured Unstrukturiertheit 4.5 Tabelle 4: Übersicht über Komplexitätsmetriken für Geschäftsprozessmodelle 4.9 Zusammenfassung Alle Metriken, die wir in den vorherigen Kapiteln definiert und vorgestellt haben, werden mit Ausnahme der nur kurz angesprochenen in Kapitel 4.8 in diesem Abschnitt noch einmal in drei Tabellen zusammengefasst. In Tabelle 5 sind die Umfangsmetriken für EPK-Modelle zusammengefasst. Tabelle 6 fasst die Metriken zusammen, die sich speziell auf UML 2-Aktivitätsdiagramme beziehen. Tabelle 4 zeigt einen Überblick aller übrigen Komplexitätsmetriken. 62 Frank Meyer

65 N_EVENTS Anzahl interne Ereignisse 4.1 [MMN + 06] N_CONNECTORS Anzahl Verknüpfungsoperatoren 4.1 N_ARCS Anzahl Kanten 4.1 [MMN + 06] N_ENDEVENTS Anzahl Endereignisse 4.1 [MMN + 06, ARGP06b] N_FUNCTIONS Anzahl Funktionen 4.1 [GL06, MMN + 06, CMNR06] N_FUNCTIONS Anzahl Funktionen und Verknüpfungsoperatoren 4.1 [CMNR06] CONNECTORS N_JOINAND Anzahl AND-Joins 4.1 [MMN + 06] N_JOINOR Anzahl OR-Joins 4.1 [MMN + 06] N_JOIN Anzahl Joins 4.1 CONNECTORS N_JOINXOR Anzahl XOR-Joins 4.1 [MMN + 06] N_SPLITAND Anzahl AND-Splits 4.1 [MMN + 06] N_SPLITOR Anzahl OR-Splits 4.1 [MMN + 06] N_SPLIT Anzahl Splits 4.1 CONNECTORS N_SPLITXOR Anzahl XOR-Splits 4.1 [MMN + 06] N_STARTEVENTS Anzahl Startereignisse 4.1 [MMN + 06, ARGP06b] Tabelle 5: Übersicht über Umfangsmetriken für EPK-Modelle Metrikname Metrik Kapitel Literatur N_ACTIONS Anzahl Aktionsknoten [GL06, CMNR06] N_FINALNODES Anzahl Endknoten [MMN + 06, ARGP06b] N_ARCS Anzahl Kontrollflusskanten N_CONNECTORS Anzahl Verknüpfungsoperaten N_SPLITXOR Anzahl XOR-Splits N_JOINXOR Anzahl XOR-Joins N_SPLITAND Anzahl AND-Splits N_JOINAND Anzahl AND-Joins N_EXCEPTIONS Anzahl Ausnahmen N_INTERRUPTIBLE Anzahl unterbrechbare Bereiche REGIONS EXCEPTION_COMP Komplexität von Ausnahmen INTER_REGION COMP Komplexität unterbrechbarer Bereiche Tabelle 6: Spezifische Metriken für UML 2-Aktivitätsdiagramme Frank Meyer 63

66 5 Theoretische Validierung Bei der theoretischen Validierung von Software-Komplexitätsmetriken wird häufig geprüft, ob sie bestimmte von Weyuker definierte Eigenschaften[Wey88] erfüllen. Diese neun Eigenschaften werden im Folgenden vorgestellt. P, Q, R bedeuten in diesem Zusammenhang beliebige Programmblocks, P ; Q kennzeichnet die Zusammensetzung eines Programms aus den Programmblöcken P und Q. M kennzeichnet die zu validierende Metrik und M(P ) das Ergebnis der Metrik für den Programmblock P. 1. Es gibt Programme P und Q, für die M(P ) M(Q) ist. 2. Falls c eine nicht-negative Zahl ist, so gibt es nur endlich viele Programme P mit M(P ) = c. 3. Es gibt unterschiedliche Programme P und Q, für die M(P ) = M(Q) ist. 4. Es gibt funktional äquivalente Programme P und Q, für die M(P ) M(Q) ist. 5. Für alle Programmblöcke P und Q ist M(P ) M(P ; Q) und M(Q) M(P, Q). 6. Es existieren Programmblöcke P, Q, R, so dass M(P ) = M(Q) und M(P ; R) M(Q; R). 7. Es existieren Programmblöcke P und Q, so dass Q aus einer Vertauschung der Reihenfolge der Anweisungen (Permutation) von P besteht und es gilt: M(P ) M(Q). 8. Falls P eine Umbenennung von Q ist, so ist M(P ) = M(Q). 9. Es existieren Programmblöcke P und Q, so dass M(P ) + M(Q) < M(P ; Q). An der Verwendung der Eigenschaften zur Validierung gab es einige Kritik (vgl. dazu den Überblick in [FP97]). So wurde eine Metrik definiert, die zwar alle Eigenschaften erfüllt, aber dennoch keine sinnvolle Metrik zur Komplexitätsmessung von Programmcode ergibt. Für die CFC-Metrik liegt bereits eine Validierung anhand der Eigenschaften von Weyuker vor[car05a]. Dabei geht diese Validierung von wohlstrukturierten Modellen aus, d.h. zu jedem Split-Operator existiert ein passender Join-Operator. Im Rahmen dieser Arbeit erfolgt für die drei Metriken N_FUNCTIONS, NestingLevel und N_CYCLES die Prüfung der von Weyuker definierten Eigenschaften. Wir verwenden dafür wiederum die Ereignisgesteuerte Prozesskette. Im Folgenden bezeichnen P, Q und R Prozessmodelle und M(P ) das Ergebnis einer Metrik M für das Prozessmodell P. Bevor wir zur Prüfung der Eigenschaften kommen, sind einige Begriffe für unsere Zwecke anzupassen: 1. Funktionale Äquivalenz: Weyuker definiert zwei Programme als äquivalent, wenn sie für die gleichen Werte der Eingabevariablen die gleichen Ausgaben 64 Frank Meyer

67 erzeugen. Eine direkte Übertragung auf Prozessmodelle in der Form, als dass zwei Modelle funktional äquivalent sind, wenn bei den gleichen Startbelegungen die gleichen Endbelegungen erreicht werden können, ist nicht möglich. So können zwei Prozessmodelle zu Bestellprozessen die gleichen Startereignisse und Endereignisse haben, aber unterschiedliche Bestellmethoden repräsentieren. Ein einfacher Austausch wäre also nicht möglich. Dennoch kann es natürlich funktional äquivalente Modelle geben. Es ist auch gerade ein Ziel von Komplexitätsmetriken, dabei zu helfen, zwischen mehreren funktional äquivalenten Modelle dasjenige mit der geringsten Komplexität identifizieren zu können. Cardoso[Car05a] führt als ein Beispiel für funktional äquivalente Modelle an, dass in bestimmten Fällen sequentielle Ablauffolgen durch parallele Ablauffolgen mit Hilfe von AND-Operatoren ersetzt werden können. 2. Zusammensetzung von Prozessmodellen (P;Q): Zwei Prozessmodelle P und Q können sequentiell zusammengesetzt werden, indem eine Kante existiert, die einen Knoten von P als Quelle und einen Knoten von Q als Ziel hat. Wir schreiben eine solche Zusammensetzung als P ; Q. Möglicherweise notwendiges weglassen von Start- oder Endereignissen oder hinzufügen von weiteren Knoten soll bei unseren Betrachtungen aber keine weitere Rolle spielen. 3. Vertauschung der Anweisungsreihenfolge: Eine Vertauschung der Anweisungsreihenfolge kann bei Prozessmodellen in der Form erfolgen, indem die Positionen von Modellknoten oder auch von Teilstrukturen eines Modells verändert werden, aber keine neuen Knoten oder Kanten hinzugefügt werden. Die Eigenschaften von Weyuker sind wie folgt für Prozessmodelle zusammengefasst: 1. Es gibt Prozessmodelle P und Q, für die M(P ) M(Q) ist. 2. Falls c eine nicht-negative Zahl ist, so gibt es nur endlich viele Prozessmodelle P mit M(P ) = c. 3. Es gibt unterschiedliche Prozessmodelle P und Q, für die M(P ) = M(Q) ist. 4. Es gibt funktional äquivalente Prozessmodelle P und Q, für die M(P ) M(Q) ist. 5. Für alle Prozessmodelle P und Q ist M(P ) M(P ; Q) und M(Q) M(P, Q). 6. Es existieren Prozessmodelle P, Q, R, so dass M(P ) = M(Q) und M(P ; R) M(Q; R). 7. Es existieren Prozessmodelle P und Q, so dass Q aus einer Vertauschung der Reihenfolge der Anweisungen (Permutation) von P besteht und es gilt: M(P ) M(Q). 8. Falls P eine Umbenennung von Q ist, so ist M(P ) = M(Q). 9. Es existieren Prozessmodelle P und Q, so dass M(P ) + M(Q) < M(P ; Q). Frank Meyer 65

68 Die Metrik N_FUNCTIONS hat folgende Ergebnisse für die neun Eigenschaften: Eigenschaft 1: Die Metrik erfüllt die Eigenschaft, da zwei Prozessmodelle mit unterschiedlicher Komplexität existieren. Eigenschaft 2: Die Eigenschaft, dass es nur endlich viele Prozessmodelle mit derselben Komplexität gibt, wird nicht erfüllt. Dies zeigt ein Beispiel in Abb. 15. Die Anzahl der Splitoperatoren S1,..., SN und die Anzahl der Joinoperatoren J1,..., JN kann beliebig erweitert werden. Eigenschaft 3: Zwei unterschiedliche Prozesse können die gleiche Anzahl an Funktionen besitzen, womit diese Eigenschaft erfüllt ist. Eigenschaft 4: Es ist davon auszugehen, dass zwei Prozessmodelle existieren können, die funktional äquivalent sind, die aber eine unterschiedliche Anzahl an Funktionen besitzen. Ohne Wissen über die inhaltliche Bedeutung der Modelle ist dies aber nicht direkt festzustellen. Etwas konstruiert können zwei funktional äquivalente Modelle P und Q gebildet werden, indem Q zusätzlich eine Dummyfunktion do_nothing (und die entsprechenden zusätzlichen Ereignisse) besitzt, ansonsten aber strukturell gleich wie P ist. Eigenschaft 5: Diese Eigenschaft wird von der Metrik erfüllt. Ein Prozessmodell muss mindestens eine Funktion besitzen, um syntaktisch korrekt zu sein. Damit hat jedes Prozessmodell mindestens eine Komplexität von 1. Die Komplexität der Zusammensetzung von zwei Prozessmodellen P und Q ist deshalb in jedem Fall um mindestens 1 höher als die jeweilige Komplexität der einzelnen Prozessmodelle. Eigenschaft 6: Diese Eigenschaft wird von der Metrik N_FUNCTIONS nicht erfüllt. Bei der Zusammensetzung von zwei Prozessmodellen P und Q ergibt sich die Komplexität des zusammengesetzten Modells aus der Summe der Komplexitäten der einzelnen Prozessmodelle, e.g. M(P ; Q) = M(P ) + M(Q). Daraus folgt, dass für drei Prozessmodelle P, Q, R mit M(P ) = M(Q) immer gilt: M(P ; R) = M(P ; Q). Eigenschaft 7: Diese Eigenschaft wird von der Metrik nicht erfüllt, da die Anzahl an Funktionen im Prozessmodell auch bei einer Vertauschung der Anweisungen gleich bleibt. Eigenschaft 8: Diese Eigenschaft wird von der Metrik erfüllt, da weder der Name des Prozessmodells noch die Funktionsnamen bei der Metrik eine Rolle spielen. Eigenschaft 9: Diese Eigenschaft wird nicht erfüllt, da wie bereits bei Eigenschaft 6 festgestellt wurde für zwei Prozessmodelle P und Q immer gilt: M(P ; Q) = M(P ) + M(Q). Folgende Ausführung zeigt die Ergebnisse der Eigenschaften für die Metrik NestingLevel: 66 Frank Meyer

69 Abbildung 15: N_FUNCTIONS-Metrik: Beispielmodell für theoretische Validierung Eigenschaft 1: Diese Eigenschaft wird von der Metrik erfüllt. Eigenschaft 2: Diese Eigenschaft wird nicht erfüllt. Dafür können wir von Funktionen F 1,..., F n ausgehen, die alle den gleichen Splitoperator als direkten Vorgänger und den gleichen Joinoperator als direkten Nachfolger haben. Die Metrik liefert unabhängig von n bei sonst gleichem Modellaufbau immer den gleichen Wert. Eigenschaft 3: Diese Eigenschaft wird von der Metrik erfüllt. Dafür kann einfacherweise von zwei Modellen mit nur einem Splitoperator, aber einer unterschiedlichen Anzahl an Funktions- oder Ereignisknoten ausgegangen werden. Eigenschaft 4: Cardoso[Car05a] hat für die CFC-Metrik als Beispiel gegeben, dass eine sequentielle Reihenfolge von Funktionen zumindest in bestimmten Fällen durch einen parallele Kontrollstruktur mit Hilfe zusätzlicher AND- Operatoren ersetzt werden kann, wobei die beiden Modelle funktional äquivalent sind. Dies bedeutet für die NestlingLevel-Metrik, dass die zusätzliche Einführung eines AND-Splitoperators den Metrikwert erhöht. Damit gibt es also zwei funktional äquivalente Modelle, für die gilt: M(P ) M(Q). Die Eigenschaft ist damit erfüllt. Eigenschaft 5: Diese Eigenschaft wird erfüllt. Alle Splitoperatoren zweier Prozessmodelle P und Q haben mindestens die gleiche Komplexität in der Zusammensetzung P ; Q wie in den Einzelmodellen. Damit gilt in jedem Fall M(P ) M(P ; Q) und M(Q) M(P ; Q). Dies ist auch der Fall, falls ein Prozessmodell keine Splitoperatoren besitzen. In diesem Fall gilt M(P ) = M(P ; Q), falls Q Frank Meyer 67

70 keinen Splitoperator besitzt. Falls beide Prozessmodelle keinen besitzen gilt M(P ) = M(Q) = M(P ; Q) = 0. Eigenschaft 6: Diese Eigenschaft wird von der Metrik erfüllt. Abb. 16 zeigt dafür vereinfachte Modelle als Beispiel. Die beiden Modelle P und Q besitzen jeweils einen Splitoperator S1 und damit eine Komplexität von 1. Sie werden beide mit einem Modell R zusammengesetzt, der einen Splitoperator S2 besitzt. Das zusammengesetzte Modell P ; R hat dadurch eine Komplexität von 3, da die Komplexität vom Splitoperator S1 2 beträgt und die von S2 1. Das zusammengesetzte Modell Q; R hat hingegen eine Komplexität von 2, da beide Splitoperatoren eine Komplexität von 1 haben. Eigenschaft 7: Diese Eigenschaft wird von der Metrik erfüllt. Abb. 17 zeigt zwei Modellstrukturen als Beispiel. Im linken Modell ist die Komplexität der abgebildeten Struktur für die NestingLevel-Metrik für beide Splitoperatoren zusammen 2. Das rechte Modell stellt eine Vertauschung der Abarbeitungsreihenfolge in der Form da, als dass die Teilstruktur vom Splitoperator S2 in den Einflussbereich von S1 einbezogen wurde. Die Anzahl an Kanten und Knoten bleibt in beiden Modellen gleich. Die Komplexität beim rechten Modell beträgt 2 für den Splitoperator S1 und 1 für den Splitoperator S2 und ist damit höher als die des linken Modells. Eigenschaft 8: Diese Eigenschaft wird von der Metrik erfüllt, da weder der Modellname noch die Knotennamen eine Rolle für die Metrik spielen. Eigenschaft 9: Diese Eigenschaft wird erfüllt. Dafür können wir von zwei Prozessmodellen P und Q ausgehen, die beide Splitoperatoren besitzen. Nun setzen wir P ; Q so zusammen, dass ein Splitoperator von Q im Einflussbereich eines Splitoperators s von P liegt. Die Komplexität von s ist damit im zusammengesetzten Modell P ; Q um eins höher als in P, womit M(P )+M(Q) < M(P ; Q) gilt. Folgende Ausführung zeigt die Ergebnisse der Eigenschaften für die Metrik N_CYCLES: Eigenschaft 1: Diese Eigenschaft wird von der Metrik erfüllt, da es Modelle mit einer unterschiedlichen Anzahl an Zyklen gibt. Eigenschaft 2: Diese Eigenschaft wird nicht erfüllt, da zyklenfreie Modellen mit einer beliebigen Anzahl an Funktionen und Ereignissen existieren. Eigenschaft 3: Diese Eigenschaft wird von der Metrik erfüllt. Als Beispiel kann von zwei Modellen mit jeweils einem einfachen Zyklus, aber einer unterschiedlichen Anzahl an Funktions- oder Ereignisknoten ausgegangen werden. Eigenschaft 4: Diese Eigenschaft wird von der Metrik erfüllt. Dafür kann das Beispiel für die NestingLevel-Metrik verwendet werden, bei dem eine sequentieller Reihenfolge von Funktionen durch eine parallelen Kontrollstruktur mit 68 Frank Meyer

71 Abbildung 16: Metrik zur Verschachtelungstiefe: Beispielmodell für theoretische Validierung Abbildung 17: Metrik zur Verschachtelungstiefe: Beispielmodell für theoretische Validierung Frank Meyer 69

72 Hilfe zusätzlicher AND-Operatoren ersetzt wurde. Wenn der sequentielle Ablauf Bestandteil eines einfachen Zyklus ist, so sind die AND-Operatoren der parallelen Kontrollstruktur Bestandteil mehrerer einfacher Zyklen. Die Anzahl der einfachen Zyklen hängt von der Anzahl der ausgehenden und eingehenden Kanten der AND-Operatoren ab, beträgt aber in jedem Fall eins mehr als beim sequentiellen Ablauf. Eigenschaft 5: Diese Eigenschaft wird erfüllt. Alle einfachen Zyklen zweier Prozessmodellen P und Q sind auch einfache Zyklen bei einer Zusammensetzung P ; Q. Damit gilt in jedem Fall M(P ) M(P ; Q) und M(Q) M(P ; Q). Dies ist auch der Fall, falls ein Prozessmodell keinen Zyklus besitzen. In diesem Fall gilt M(P ) = M(P ; Q), falls Q keinen Zyklus besitzt. Falls beide Prozessmodelle keinen besitzen gilt M(P ) = M(Q) = M(P ; Q) = 0. Eigenschaft 6: Diese Eigenschaft wird von der Metrik nicht erfüllt. Falls zwei Prozessmodelle zusammengesetzt werden, so entstehen keine neuen Zyklen. Deshalb gilt für zwei Prozessmodelle P und Q: M(P ; Q) = M(P ) + M(Q). Falls M(P ) = M(Q) gilt, so folgt daraus für die Zusammensetzungen dieser beiden Modelle mit einem dritten Prozessmodell R: M(Q; R) = M(P ; R) = M(P ) + M(R) = M(Q) + M(R). Eigenschaft 7: Diese Eigenschaft wird von der Metrik erfüllt. Dies kann an den Modellausschnitten in Abb. 18 verdeutlicht werden. Das linke Modell besitzt einen Zyklus und damit eine Komplexität von 1. Im rechten Modell ist die vom Splitoperator S2 und Joinoperator J2 gebildete Kontrollstruktur verschoben worden. Dadurch existieren jetzt zwei Zyklen, d.h. die Komplexität ist 2. Eigenschaft 8: Diese Eigenschaft wird von der Metrik erfüllt, da weder der Modellname noch die Knotennamen eine Rolle für die Metrik spielen. Eigenschaft 9: Diese Eigenschaft wird nicht erfüllt. Wie bereits bei Eigenschaft 6 beschrieben, entstehen bei der Zusammensetzung zweier Prozessmodelle P und Q keine neuen Zyklen und es gilt: M(P ; Q) = M(P ) + M(Q). Die Ergebnisse der drei Metriken sind in Tabelle 7 zusammengefasst. Die N_FUNCTIONS-Metrik schneidet bezüglich des Axiomensystems von Weyuker am schlechtesten ab. Dies ist darauf zurückzuführen, dass sie nicht die Struktur eines Prozessmodells berücksichtigt. Eine Veränderung der Struktur bei gleichbleibender Anzahl an Funktionen hat demzufolge keine Änderung der Komplexität. Ebenso wird auch eine Zusammenführung mehrerer Prozessmodelle nicht als zusätzliche Komplexität durch die Metrik bewertet. Ähnliche Ergebnisse sind auch für andere Umfangsmetriken zu erwarten. Keine der Metriken erfüllt Eigenschaft 2. Dies ist auch für die meisten anderen vorgestellten Metriken mit Ausnahme der N_ARCS-Metrik (und der InterfaceComplexity-Metrik für reguläre EPKs) zu erwarten. Für zukünftige theoretische Validierungen ist es sicherlich wünschenswert zu prüfen, inwieweit weitere Axiome für Komplexitätsmetriken für Geschäftsprozessmodelle eine Rolle spielen. Dies konnte im Rahmen dieser Arbeit leider nicht erfolgen. 70 Frank Meyer

73 Abbildung 18: N_CYCLES-Metrik: Beispielmodell für theoretische Validierung N_FUNCTIONS NestingLevel N_CYCLES Eigenschaft 1 ja ja ja Eigenschaft 2 nein nein nein Eigenschaft 3 ja ja ja Eigenschaft 4 ja ja ja Eigenschaft 5 ja ja ja Eigenschaft 6 nein ja nein Eigenschaft 7 nein ja ja Eigenschaft 8 ja ja ja Eigenschaft 9 nein ja nein Tabelle 7: Weyuker-Eigenschaften für die Metriken N_FUNCTIONS, NestingLevel, N_CYCLES Frank Meyer 71

74 6 Implementierung der Metriken Bei der Implementierung der Metriken spielten vor allem folgende Aspekte eine Rolle: 1. Die Metriken sollen in den EPK-Editor EPCTools integriert werden, aber nicht abhängig davon sein. 2. Es soll auf einfache Weise möglich sein, weitere Metriken zu implementieren. 3. Die individuelle Konfiguration und Auswahl der verwendeten Metriken soll möglich sein. 4. Es soll ein Batchprogramm entwickelt werden, das automatisiert die Metriken für eine Menge von EPK-Modelle berechnet, die im XML-basierten Dateiformat EPML gespeichert sind. Entstanden ist aus diesen Anforderungen das in Java entwickelte Werkzeug EPC- Metrics, das Metriken für EPKs sowohl innerhalb der graphischen Oberfläche des EPK-Editors EPCTools[Cun04] als auch im Batchmodus berechnen kann. Als Batchprogramm kann es zur Zeit Dateien im EPML-Format[MN05] verarbeiten, ist aber leicht für andere Formate wie bspw. das von ARIS Toolset verwendete Format AML erweiterbar. Im Folgenden wird zuerst auf die Integration in EPCTools eingegangen sowie auf die Verwendung als Batchprogramm. Danach wird das grundsätzliche Datenmodell vorgestellt und die Implementierung und Architektur der Metriken. Im Anschluss wird auf Möglichkeiten zur Erweiterung eingegangen Integration in den EPK-Editor EPCTools EPCTools ist ein Programm zur Modellierung und Simulation von EPK-Modellen, welches innerhalb der Entwicklungsumgebung Elipse verwendet werden kann. Eclipse ist eine unter einer Open-Source-Lizenz veröffentlichte Entwicklungsumgebung, die als Javaprogramm weitestgehend plattformunabhängig ist. Sie bietet die Möglichkeit, die Funktionalität durch Plugins zu erweitern, die durch den Benutzer zusätzlich installiert werden können. EPCTools ist als ein solches Plugin für Eclipse konzipiert. Folgende Funktionen stellt es zur Verfügung: 1. Editor: Das Tool besitzt einen graphischen Editor für EPK-Modelle. Als Knotentypen stehen Ereignisse, Funktionen sowie die üblichen Typen von Verknüpfungsoperatoren zur Verfügung. Abb. 19 zeigt einen Screenshot des Programms, hier bereits in einer im Rahmen dieser Arbeit modifizierten Version. Als Speicherformat für die Modelle verwendet das Programm EPML. 3 Eine ausführlichere Beschreibung des Tools und seiner Verwendung befindet sich auf der zur Diplomarbeit zugehörigen CD. 72 Frank Meyer

75 Abbildung 19: Das Modellierungstool EPCTools als Plugin in Eclipse (hier bereits mit eigenen Erweiterungen) Frank Meyer 73

76 2. Simulation: Hauptbestandteil des Tools ist die Simulation der EPKs. Als Simulation ist hier die visuelle Darstellung des Ablaufs eines modellierten Geschäftsprozesses gemeint. Dafür kann der Benutzer Token auf beliebige Knoten im Modell verteilen und dann schrittweise den Prozess entweder in zufälliger Ausführungsfolge oder mit eigener Steuerung simulieren. 3. Berechnung semantischer Eigenschaften: Auf Grundlage des Algorithmus vom Simulator kann das Programm einige semantische Eigenschaften von EPK-Modellen berechnen. Eine kurze Erklärung der semantischen Eigenschaften erfolgt in Anhang A. Diese Möglichkeit ist für uns wichtig, da wir semantische Eigenschaften der Modelle für die Validierung der Komplexitätsmetriken verwenden. Im Rahmen der Arbeit wurde EPCTools um einige kleinere Funktionen erweitert, die vor allem im Hinblick auf die Eingabe der Modelle für die praktische Validierung der Metriken notwendig waren. Im Einzelnen wurden folgende Änderungen vorgenommen: 1. Dokumentation: Das Programm wurde so erweitert, dass zusätzliche Informationen über ein Modell angegeben und in der EPML-Datei gespeichert werden können (Modellname, Autoren, Eingabedatum, Quelle des Modells). 2. Prozesswegweiser: EPCTools kann in der ursprünglichen Version weder mit Prozesswegweisern noch mit hierarchischen Funktionen umgehen. Zwar spielen beide Möglichkeiten zur Aufteilung von Modellen für die meisten von uns definierten Metriken keine Rolle. Da aber viele der von uns bei der praktischen Validierung verwendeten Modelle diese Modellierungselemente benutzen, hätte zumindest der Wegfall von Prozesswegweisern weitreichendere Folgen gehabt, da als Folge auch Kanten sowie Verknüpfungsoperatoren weggefallen wären. Diese spielen für einige Metriken durchaus eine größere Rolle. Deshalb wurden Prozesswegweiser in das Tool integriert. 3. Startbelegungen: Ebenso wurde die Möglichkeit implementiert, gültige Startbelegungen für ein Modell anzugeben und in der EPML-Datei zu speichern. Dies kann verwendet werden, um semantische Eigenschaften des Modells automatisiert nur für diese Startbelegungen zu prüfen. Abb. 20 zeigt einen Screenshot der Integration der Metriken in die graphischen Oberfläche von EPCTools. Die Metriken werden für das im Editor dargestellte EPK- Modell berechnet. Wie aus der Abbildung ersichtlich, sind die Werte von zwei Metriken farblich unterlegt. Diese Unterlegungen stellen das Komplexitätslevel für das Resultat der jeweiligen Metrik dar, wobei ein roter Hintergrund eine hohe Komplexität, ein gelber Hintergrund eine mittlere Komplexität des Modells bedeutet (die Werte sind hier nur zur Anschauung gesetzt, Richtlinien für Komplexitätslevel fehlen bislang aufgrund fehlender Evaluierungen der Metriken). Die Komplexitätslevel werden, wie auch die Auswahl der Metriken selbst, über eine Datei konfiguriert, die sich im Wurzelverzeichnis des Plugins befindet. Der Aufbau einer solchen Datei ist in Anhang C dargestellt. 74 Frank Meyer

77 Abbildung 20: Screenshot der Metrikintegration in EPCTools Frank Meyer 75

78 Die Ergebnisse der Metrikberechnungen für ein Modell können optional in einer XML-Datei gespeichert werden. Ein Beispiel dafür ist in Anhang D zu finden. 6.2 Batchprogramm Die Metriken können ebenso mit einem Batchprogramm für EPK-Modellen, die in Dateien gespeichert vorliegen, berechnet werden. Je nach Format der Dateien und der gewünschten Konstruktionsweise der Modelle wird dafür eine zu verwendende Konstruktionsklasse in einer Konfigurationsdatei angegeben. Dabei kann das Batchprogramm sowohl für eine einzelne Datei als auch für alle Dateien aus einem Verzeichnis - optional inklusive der Unterverzeichnisse - die Metriken berechnen, wobei die akzeptierten Dateiendungen in einer Konfigurationsdatei festgelegt werden. Die Ergebnisse werden in Dateien gespeichert, die das gleiche Format besitzen wie im vorherigen Beispiel für die graphische Oberfläche. Neben den Resultaten der Metriken werden ebenfalls statistische Angaben über das Modell mit gespeichert. Optional können je nach verwendeter Konstruktionsklasse der Modelle auch Informationen über semantische Eigenschaften berechnet und gespeichert werden. Zur Zeit sind zwei Konstruktionsklassen implementiert. Diese werden wie auch die Möglichkeit der Entwicklung eigener Konstruktionsklassen im Abschnitt 6.5 vorgestellt. Das Batchprogramm wird teils über Programmparameter, teils über eine Konfigurationsdatei gesteuert. Die Aufgabe der Konfigurationsdatei besteht neben der Auswahl und Konfiguration der Metriken in der Angabe akzeptierter Dateiendungen sowie der zu verwendenden Konstruktorklasse der Datenmodelle. Der Aufbau der Konfigurationsdatei ist in Anhang B ersichtlich. 6.3 Datenmodell Die Struktur des internen Datenmodells von EPCMetrics ist in Abb. 21 dargestellt. Wie aus der Abbildung ersichtlich, werden als Knotentypen Ereignisse, Funktionen, Verknüfungsoperatoren, Prozesswegweiser sowie hierarchische Funktionen unterstützt. EPCModel ist die zentrale Klasse des Datenmodells. Sie stellt u.a. eine Reihe von Methoden zur Verfügung, um auf bestimmte Knotenmengen des Modells wie Startknoten und Verknüpfungsoperatoren unterteilt nach ihren Typen zuzugreifen, die bei der Initialisierung der Datenstruktur berechnet werden. An Informationen zum graphischen Layout eines EPK-Modells werden vom Datenmodell zur Zeit nur Angaben zum Verlauf der Kantenlinien unterstützt. Das Datenmodell eines EPK-Modells wird in einer Containerklasse verwaltet. Diese verwaltet neben dem Datenmodell ein Objekt mit syntaktischen Eigenschaften des Modells, die Resultate der Metriken für das Modell sowie optional ein Objekt mit Informationen über semantische Eigenschaften des Modells. Dargestellt ist die Architektur in Abb Frank Meyer

79 Abbildung 21: Klassenstruktur des Datenmodells Abbildung 22: Klassenstruktur der internen Verwaltung eines Modells Frank Meyer 77

80 Abbildung 23: Architektur der Metrikimplementation (Die Abbildung zeigt aus Übersichtsgründen nur einen Ausschnitt der implementierten Metriken) 6.4 Implementation der Metriken Damit das Tool leicht erweiterbar für weitere Metriken ist, wurde ein Interface definiert, das von jeder Metrik implementiert werden muss. Die Architektur der Implementation ist in Abb. 23 dargestellt. Die abstrakte Klasse AbstMetric implementiert diverse get- und set-methoden und wird zur Zeit von allen instanziierbaren Metrikklassen geerbt. Hauptmethode des Interfaces ist calculatemetric(epcmodel): MetricResult. Diese berechnet für ein gegebenes EPK-Modell die Metrik und liefert das Ergebnis in einer Containerklasse zurück. Die Auswahl der Metriken, die verwendet werden sollen, erfolgt wie bereits vorher beschrieben über eine Konfigurationsdatei im XML-Format. In dieser Datei sind neben den Metrikklassen noch weitere Attribute für die Metriken gespeichert: 1. Gruppe: Jede Metrik ist einer Gruppe zugeordnet. Diese kann bspw. bei der graphischen Darstellung verwendet werden. 2. Grenzwerte für die Komplexitätslevel der Metrik: Längerfristiges Ziel von Metriken ist es, dem Benutzer mitzuteilen, welche Komplexitätswerte eine niedrige und welche eine hohe Komplexität für ein Modell bedeuten, ggf. noch mit Zwischenstufen. In der Konfigurationsdatei können die unteren Schwellwerte für die einzelnen Stufen gespeichert werden. 3. zusätzliche Attribute der Metrik: Es ist denkbar, dass Metriken variable Parameter beinhalten, bspw. für Gewichtsfaktoren. Deshalb können in der Konfiguration der Metrik zusätzliche Attribute angegeben werden. Da es möglich ist, mehrmals die gleiche Metrikklasse in der Konfiguration anzugeben, kann eine 78 Frank Meyer

81 Abbildung 24: Architektur der Konstruktion der Datenmodelle Metrik mehrfach mit unterschiedlichen Parameterwerten instanziiert werden, um z.b. die Auswirkungen der Parameterwerte zu prüfen. Eine Übersicht über alle implementierten Metriken ist in Tabelle 8 dargestellt. 6.5 Schnittstellen Für die Konstruktion der Datenmodelle spielt nicht nur die Quellstruktur der EPK- Modelle eine Rolle, sondern auch, wie diese Struktur interpretiert wird. So können in einer EPML-Struktur mehrere EPK-Modelle gespeichert sein, die entweder vollkommen unabhängig sind oder die Teilmodelle darstellen, die über Prozesswegweiser und/oder hierarchische Funktionen miteinander in Verbindung stehen. Im zweiten Fall ist es zum einen denkbar, dass die Metriken für das Gesamtmodell berechnet werden, indem die Prozesswegweiser und hierarchischen Funktionen aufgelöst werden und die Teilmodelle zusammengeführt werden. Zum anderen ist es denkbar, dass die Metriken für jedes einzelne Teilmodell berechnet werden. Ebenso ist es wünschenswert, dass das Metriktool einfach für weitere Dateiformate von EPK- Modellen neben EPML erweitert werden kann. Deshalb wurde die Architektur für die Konstruktion der Datenmodelle so implementiert, dass das Tool um weitere Konstruktionsklassen je nach Quellstruktur der Modelle erweitert werden kann. Die Architektur der Modellkonstruktion ist in Abb. 24 dargestellt. Alle Konstruktionsklassen implementieren das Interface IModelConstructor. Dieses definiert die Methode constructfiles(file): Vector. Die implementierenden Klassen bilden bei Aufruf dieser Methode für die EPK-Modelle aus dem Fileobjekt der Datenquelle die Datenmodellen sowie die zugehörigen Container. Die Rückgabe der Methode besteht aus den Containern der konstruierten EPK-Modelle. Zur Zeit sind zwei Konstruktionsklassen implementiert, die hier kurz vorgestellt werden. 1. de.ulpz.ebus.epc.metrics.util.modelutils.epmlmodelconstructor: Frank Meyer 79

82 Diese Konstruktionsklasse ist für Dateien im EPML-Format geeignet. Für jedes definierte EPK-Modell in einer EPML-Datei wird ein eigenes Datenmodell konstruiert. Dies wird auch angewandt, falls die EPK-Modelle durch Prozesswegweiser und hierarchische Funktionen verbunden sind. In diesem Fall werden die Objekte der Prozesswegweiser und hierarchischen Funktionen so konstruiert, dass auf die Datenmodelle der verbundenen Teilmodelle zugegriffen werden kann. Mit dieser Konstruktionsklasse werden also die Metriken für Teilmodelle berechnet, nicht für ein Gesamtmodell, das aus mehreren Teilmodelle besteht. Eine Prüfung semantischer Eigenschaften eines Modells ist nicht möglich. 2. de.ulpz.ebus.epc.metrics.util.modelutils.epctoolsmodelconstructor: Diese Konstruktionsklasse ist ebenfalls für Dateien im EPML-Format geeignet. Als Parser wird hier der Parser von EPCTools verwendet. Dieser erzeugt generell nur ein EPK-Modell in der von EPCTools verwendeten internen Datenstruktur, auch wenn mehrere EPK-Modelle in einer Datei gespeichert sind. Bei mehreren gespeicherten Modellen bzw. Teilmodellen entsteht dadurch ein syntaktisch nicht korrektes Modell. Daraus folgt, dass mit diesem Konstruktor nur EPML-Dateien verwendet werden können, die lediglich ein EPK-Modell beinhalten. Optional können mit dieser Konstruktionsklasse die semantischen Eigenschaften eines Modells mit Hilfe des Simulators von EPCTools berechnet werden. 80 Frank Meyer

83 Klassenname Metrik Beschreibung Kapitel CFC CFC Kontrollfluss-Komplexität 4.3 der Splits JC JC Kontrollfluss-Komplexität 4.3 der Joins CycleSetsComplexity CSC Komplexität der Äquivalenzklassen 4.2 von Zyklen NCycles N_CYCLES Anzahl elementarer Zyklen 4.2 NCycleSets N_CSETS Anzahl Äquivalenzklassen 4.2 von Zyklen Unstructured Unstructured Unstrukturiertheit 4.5 InterfaceComplexity IC Informationsfluss zwischen 4.6 Knoten NestingLevel NestingLevel Verschachtelungstiefe 4.4 NConnectors N_CONNECTORS Anzahl Konnektoren 4.1 NEvents N_EVENTS Anzahl interne Ereignisse 4.1 NEdges N_ARCS Anzahl Kanten 4.1 NEndEvents N_ENDEVENTS Anzahl Endereignisse 4.1 NFunctions N_FUNCTIONS Anzahl Funktionen 4.1 NFunctions Connectors N_FUNCTIONS Anzahl Funktionen und 4.1 CONNECTORS Konnektoren NJoinAnd N_JOINAND Anzahl AND-Joins 4.1 NJoinOr N_JOINOR Anzahl OR-Joins 4.1 NJoins N_JOIN CONNEC- Anzahl Joins 4.1 TORS NJoinXor N_JOINXOR Anzahl XOR-Joins 4.1 NSplitAnd N_SPLITAND Anzahl AND-Splits 4.1 NSplitOr N_SPLITOR Anzahl OR-Splits 4.1 NSplits N_SPLIT CONNEC- Anzahl Splits 4.1 TORS NSplitXor N_SPLITXOR Anzahl XOR-Splits 4.1 NStartEvents N_STARTEVENTS Anzahl Startereignisse 4.1 RConnectorsEvents RATIO_CFE Verhältnis Konnektoren Functions Ereignisse und Funktionen RConnectors Functions RATIO_CF Verhältnis Konnektoren Funktionen RJoinsSplits RATIO_JS Verhältnis Joins - Splits AverageEdgeLength STYLE_AL durchschnittliche Kantenlänge 4.7 EdgesIntersections STYLE_AC Überschneidungen von 4.7 Kanten WritingDirection STYLE_WD Schreibrichtung 4.7 Tabelle 8: Implementierte Komplexitätsmetriken Frank Meyer 81

84 7 Praktische Validierung Die praktische Validierung erfolgte anhand von EPK-Modellen aus unterschiedlichen Publikationen und bestand aus zwei Bereichen. Als erstes wurden die Korrelationen zwischen den einzelnen Metriken berechnet. Eine solche Korrelationsanalyse ist zum einen interessant, um die Anzahl an Metriken ggf. zukünftig reduzieren zu können, falls sie redundante Informationen enthalten. Zum anderen war sie für den zweiten Bereich der praktischen Validierung notwendig. Dieser bestand darin, Zusammenhänge zwischen den Metriken und semantischen Fehler in den EPK-Modellen zu prüfen. Die Grundthese ist dabei, je höher die Komplexität eines Modells ist, desto wahrscheinlicher ist es, dass das Modell semantisch fehlerhaft ist. Für die Berechnung der semantischen Eigenschaften wurde das Programm EPC- Tools verwendet. Dieses kann nur eine Aussage darüber treffen, ob ein Modell eine semantische Eigenschaft erfüllt oder nicht. Es kann aber nicht berechnen, wie oft eine semantische Eigenschaft nicht erfüllt ist. Deshalb wurde für die Validierung die logistische Regression verwendet. Die abhängige Variable ist dabei binär kodiert, d.h. sie hat nur zwei Ausprägungen, in unserem Fall Modell ist semantisch fehlerhaft und Modell ist semantisch fehlerfrei. Zuerst wurden univariate Regressionsmodelle mit jeweils einer Metrik als unahbhängiger Variablen berechnet. Danach wurden insgesamt drei multivariate Regressionsmodelle für einen Teil der Metriken aufgestellt. Die Auswahl der Metriken erfolgte dabei aufgrund der Korrelationen zwischen den Metriken und den Ergebnissen der univariaten Modelle. Für die statistischen Berechnungen wurde SPSS Version 14 verwendet. Nicht alle vorgestellten Metriken wurden bei der praktischen Validierung berücksichtigt. Dies betrifft die Layoutmetriken, für die eine solche Validierungsmethode wenig sinnvoll ist. Zum einen kann nicht gewährleistet werden, dass die Form der vorliegenden Modelle auch der Form entspricht, in der sie dem Modellierer vorlag. Zum anderen kann bei der Digitalisierung der Modelle nicht gewährleistet werden, dass sie genau dem ursprünglichen Layout entsprechen, auch wenn versucht wurde, es weitestgehend beizubehalten. Da mit dem verwendeten Modellierungstool keine hierarchischen Funktionen eingegeben werden konnten, wurde die Fan-in/Fan-out- Metrik zu hierarchischen Funktionen ebenfalls nicht berücksichtigt. 7.1 Auswahl der EPK-Modelle Die verwendeten EPK-Modelle stammen aus Dokumenten, die Herr Laue freundlicherweise zur Verfügung gestellt hat. Als Quellformen lassen sie sich untergliedern in Modelle aus Unternehmen, wissenschaftlichen Veröffentlichungen, Diplomarbeiten, Promotionen und anderen Publikationsformen. Da bis auf eine Ausnahme, die bereits im EPML-Format vorlag, alle Modelle als Grafiken vorlagen, wurden sie zuerst mit Hilfe des Modellierungstools EPCTools in das EPML-Format übertragen. Hierarchische Funktionen wurden dabei als normale Funktionen modelliert. Prozesswegweiser hingegen konnten in der modifizierten Version von EPCTools mit eingegeben werden. Bei der Auswahl der Modelle wurde darauf geachtet, dass diese 82 Frank Meyer

85 Quellform Gesamt Semantik Fehlerhaft Fehlerhaft berechenbar (ohne stark (mit stark (verwendet) sound) sound) Unternehmen Syntax korrekt Syntax nicht korrekt Diplomarbeiten Syntax korrekt Syntax nicht korrekt Veröffentlichungen Syntax korrekt Syntax nicht korrekt Promotionen Syntax korrekt Syntax nicht korrekt Sonstige Syntax korrekt Syntax nicht korrekt Insgesamt Syntax korrekt Syntax nicht korrekt Tabelle 9: Übersicht über verwendete EPK-Modelle praxisrelevant sind. Einfache Beispielmodelle und Modelle aus Vorlesungsskripten wurden nicht verwendet. Insgesamt ergab sich eine Anzahl von 186 Modellen, die als praxisrelevant angesehen werden können und die in das EPML-Format übertragen wurden. Eine Aufschlüsselung nach Publikationsform ist in Tabelle 9 ersichtlich. Allerdings ist eine klare Trennung bei der Publikationsform nicht immer möglich, einige Modelle aus wissenschaftlichen Veröffentlichungen stammen von Unternehmen. In Tabelle 9 sind die Modelle zusätzlich nach syntaktischer Korrektheit untergliedert. Leider hatte ein großer Teil der Modelle syntaktische Fehler. Von den insgesamt 186 verwendeten Modellen waren 56 (30%) fehlerhaft bzgl. der Syntax. Die meisten Fehler bestanden in der direkten Verbindung zwischen mehreren Ereignissen oder mehreren Funktionen. Weitere Fehler waren u.a. die Verwendung von Verknüpfungsoperatoren als Join- und Splitoperatoren zugleich sowie Funktionen und Ereignisse mit mehr als einer eingehenden oder ausgehenden Kante (Fehlen von Verknüpfungsoperatoren). Die Modelle konnten also leicht korrigiert werden, wobei darauf geachtet wurde, dass keine zusätzlichen semantischen Fehler entstanden sind 4. In einigen Fällen waren die Konstrukte, in denen syntaktische Fehler auftragen, allerdings gleichzeitig semantisch fehlerhaft. Nach der Eingabe wurden die Modelle auf semantische Eigenschaften mit Hilfe des Programms EPCTools geprüft. Als semantische Eigenschaften wurden dabei 4 Die Modelle im EPML-Format (bei Syntaxfehlern in der unkorrigierten sowie korrigierten Version) sowie eine Liste mit einer genauen Aufschlüsselung der Fehler und die Auswirkungen der Korrekturen auf die Modelle befinden sich auf der CD zur Diplomarbeit. Frank Meyer 83

86 schwache und starke Soundness, Kontaktfreiheit sowie Sauberkeit verwendet. Eine kurze Erklärung dieser Eigenschaften ist in Anhang A ersichtlich. Dabei wurde jeweils geprüft, ob diese Eigenschaften unter einer gegebenen Startbelegung erfüllt werden. Da EPK-Modelle mehrere Startbelegungen besitzen können, diese aber nicht formal im Modell verzeichnet sind, wurden die semantischen Eigenschaften im ersten Schritt für alle möglichen Startbelegungen geprüft. Danach wurde für diejenigen Modelle, die einen semantischen Fehler bei mindestens einer Startbelegung aufwiesen, die Menge der gültigen Startbelegungen festgelegt und in der EPML- Datei gespeichert. Im zweiten Schritt wurden die semantischen Eigenschaften dann nur noch für die festgelegten gültigen Startbelegungen geprüft. Für einige Modelle konnten die semantischen Eigenschaften nicht berechnet werden, diese wurden bei der weiteren Auswertung nicht berücksichtigt. Die Aufschlüsselung nach Publikationsform und nach syntaktischer Korrektheit ist in der Spalte Semantik berechenbar der Tabelle 9 dargestellt. Bei der Fehlerauswertung der Modelle wurde einmal mit und einmal ohne Berücksichtigung von starker Soundness als Fehlerkriterium ausgewertet. Dies ist auch aus Tabelle 9 dargestellt. In der Spalte Fehlerhaft (ohne stark sound) ist die Anzahl an Modellen ersichtlich, die entweder nicht schwach sound oder nicht kontaktfrei für mindestens eine der als gültig festgelegten Startbelegungen waren (Sauberkeit als Fehlerkriterium spielte bei keinem der verwendeten Modelle eine Rolle). Insgesamt waren dies 12 Modelle (6,7%). In der Spalte Fehlerhaft (mit stark sound) die Anzahl an Modellen dargestellt, die entweder nicht stark sound, nicht schwach sound oder nicht kontaktfrei für mindestens eine gültige Startbelegung waren. Insgesamt sind dies 29 Modelle (16,2%). Daraus folgt, dass 17 der Modelle nicht stark sound sind, aber schwach sound sowie kontaktfrei für alle gültigen Startbelegungen. Auffällig ist, dass ein großer Teil der Modelle mit semantischen Fehlern auch syntaktische Fehler beinhaltete. Es kann darüber diskutiert werden, ob die Forderung von starker Soundness ein zu hartes Kriterium für die semantische Korrektheit von Modellen ist. Tatsächlich war ursprünglich nicht geplant, dies mit zu berücksichtigen. Leider waren aber ansonsten nur 12 Modelle fehlerhaft, was für eine sinnvolle Auswertung recht wenige Modelle sind. [BEPW05] empfiehlt für die von uns verwendete logistische Regression mindestens 25 Datensätze mit jeder Ausprägung der abhängigen Variablen, die in unserem Fall entweder Modell fehlerhaft oder Modell nicht fehlerhaft ist. Da wir für die Modelle die gültigen Startbelegungen festgelegt haben und damit offensichtlich ungültige mögliche Startbelegungen wie die Zusammenführung mehrerer Startereignisse direkt durch einen XOR-Splitkonnektor ausgeschlossen haben, ist es auch vertretbar, starke Soundness als Fehlerkriterium zu verwenden. Tabelle 10 zeigt die bei der Validierung verwendeten Metriken. Ebenfalls sind in der Tabelle die Mittelwerte der Metrikwerte angegeben sowie der Anteil der EPK- Modelle, bei denen die jeweilige Metrik einen Wert von 0 hatte 5. 5 Auf eine Angabe der Wertebereiche für die Metriken wurde hier verzichtet, da die Werte im oberen Wertebereich meistens nur wenige Modelle betreffen. Bei fast allen Metriken häufen sich die Werte im unteren Wertebereich. Die vollständigen Häufigkeitsverteilungen befinden sich auf der CD zur Diplomarbeit. 84 Frank Meyer

87 Metrik Mittelwert Häufigkeit Metrikwert 0 CFC 8,955 7,3% JC 8,559 11,2% CycleSetsComplexity (CSC) 2,888 61,5% N_CYCLES 1,933 61,5% N_CSETS 0,73 61,5% Unstructured 2,497 46,9% InterfaceComplexity (IC) 59,083 0% NestingLevel 8,9497 7,3% N_CONNECTORS 6,363 5,0% N_EVENTS 8,927 3,9% N_ARCS 31,553 0% N_ENDEVENTS 1,989 0% N_FUNCTIONS 9,430 0% N_FUNCTIONS CONNECTORS 15,793 0% N_JOINAND 1,02 54,2% N_JOINOR 0,458 74,9% N_JOINXOR 1,436 35,2% N_JOIN CONNECTORS 2,916 11,2% N_SPLITAND 1,05 51,4% N_SPLITOR 0,23 82,7% N_SPLITXOR 2,162 22,9% N_SPLIT CONNECTORS 3,447 7,3% N_STARTEVENTS 1,53 0% RATIO_CFE 0,415 5,0% RATIO_CF 0,736 5,0% RATIO_JS 0,871 11,2% Tabelle 10: Mittelwerte und Prozentsatz Nullwerte für der Metriken Logistische Regression Die logistische Regression ist ein Verfahren, um über einen Regressionsansatz zu ermitteln, mit welcher Wahrscheinlichkeit ein Ereignis in Abhängigkeit von Einflussfaktoren erwartet werden kann[bepw05]. Das Ereignis wird dabei durch die binäre abhängige Variable y dargestellt, die die Werte 1 ( Ereignis tritt ein ) und 0 ( Ereignis tritt nicht ein ) annimmt. In unserem Fall ist das Ereignis die Fehlerhaftigkeit eines EPK-Modells mit den möglichen Werten Modell ist fehlerhaft (1) und Modell ist nicht fehlerhaft (0). Die Einflussfaktoren werden durch die unabhängigen Variablen x 1,..., x n dargestellt. In unserem Fall sind die Einflussfaktoren die Metriken. Dabei kann entweder nur ein möglicher Einflussfaktor verwendet werden (univariate Regression) oder mehrere Einflussfaktoren zusammen (multivariate Regression). Die Grundidee geht von den sogenannten Odds aus, dem Chancenverhältnis der Wahrscheinlichkeiten von P (y = 1) und P (y = 0): Odds(y = 1) = P (y=1) 1 P (y=1) Frank Meyer 85

88 Da Odds nur Werte im Bereich [0, ] annehmen kann, werden die Odds logarithmiert zu sogenannten Logits: Logit(y = 1) = ln P (y=1) 1 P (y=1) Die Regressionsgleichung für die logistische Regression wird gebildet durch: Logit(y = 1) = ln( P (y=1) 1 P (y=1) ) = β 0 + β 1 x β n x n Die Regressionskoeffizienten β 0, β 1,..., β n werden mit dem Maximum-Likelihood- Verfahren geschätzt. Für die Interpretation der Regressionskoeffizienten werden meistens die sogenannten Effekt-Koeffizienten (odds ratio) e β j (exp(β j )) verwendet. Diese geben an, wie sich das Chancenverhältnis der abhängige Variable ändert, wenn sich die betrachtete unabhängige Variable x j um eine Einheit ändert. Ein Effekt-Koeffizient größer als 1 bedeutet dabei, dass bei einer Änderung von x j um eine Einheit (bei konstanten Werten der anderen unabhängigen Variablen) die Chance für den Eintritt des Ereignisses (d.h. ein Wert von 1 der abhängigen Variablen) erhöht. Ein Effekt-Koeffizient von 1 bedeutet, dass eine Änderung von x j keinen Einfluss auf die abhängige Variable hat. Ein Effekt-Koeffizient kleiner als 1 bedeutet entsprechend, dass eine Änderung von x j die Chance für den Eintritt des Ereignisses sinkt. Falls wir also bei unserem Beispiel einen Effekt-Koeffizienten von 1,56 für eine Metrik haben, so steigt bei Erhöhung des Metrikwertes um eine Einheit die Chance, dass ein Modell fehlerhaft ist, um das 1,56-fache. Für die Prüfung der Signifikanz der einzelnen unahbängigen Variablen bei den Regressionsmodellen wurde der sogenannte Wald-Test verwendet[bepw05]. Dieser wird berechnet durch: W = ( b j s bj ) 2 Dabei ist b j der Regressionskoeffizient der zu testenden unabhängigen Variablen x j und s bj der geschätzte Standardfehler von b j. Das Ergebnis des Wald-Tests wird zur Signifikanzprüfung mit dem tabellierten χ 2 -Wert mit einem Freiheitsgrad verglichen. Um eine Variable als signifikant einzuordnen, muss W größer als der χ 2 -Wert sein, was bei der üblichen Signifikanzgrenze von 5% einem Wert von 3,84 entspricht. Für die Prüfung der Regressionsmodelle wurde das Pseudo-Bestimmtheitsmaß von Nagelkerke verwendet[bepw05]. Dieses dient dazu, Aussagen zur Güte der Anpassung des geschätzten Modells an die beobachteten Werte zu treffen. Dafür wird das Ergebnis der Likelihood-Funktion eines Modells, welches nicht die unabhängigen Variablen enthält (Nullmodell), mit dem Wert der Likelihood-Funktion für das zu prüfende Modell verglichen: Nagelkerke R 2 = 1 [ L 0 L ] 2/n 1 L 2/n 0 86 Frank Meyer

89 L 0 ist hierbei das Nullmodell ohne die unabhängigen Variablen, L ist das zu prüfende Modell mit den unabhängigen Variablen und n ist der Stichprobenumfang. Nach [BEPW05] weisen Werte größer 0,2 auf ein akzeptables Modell hin, d.h. mehr als 20% der Variation können durch das Modell erklärt werden Korrelationsanalyse zwischen den Metriken Bei der Korrelationsanalyse wurden die Korrelationen zwischen den Metriken paarweise berechnet. Da die Werte der Metriken in der Regel nicht normalverteilt sind, wurde der Rangkorrelations-Koeffizient von Spearman verwendet[sac92]. Dabei werden alle Werte einer Messung aufsteigend sortiert, d.h. der kleinste Wert der Messung bekommt den niedrigsten Rang, der größte Wert der Messung den höchsten Rang. Falls mehrere Werte gleich sind, wird ihnen der Mittelwert der Ränge zugewiesen. Für zwei Variablen X und Y wird der Rangkorrelationskoeffizient dann berechnet durch: r S = 1 6P d 2 i n(n 2 1) Hierbei ist n die Anzahl an Wertepaaren und d i die Differenz der Ränge eines Wertepaares (x i, y i ) für die Variablen X und Y. Tabelle 11 führt alle Paare von Metriken auf, bei denen der Rangkorrelationskoeffizient größer als 0,7 war, d.h. zwischen denen eine sehr hohe Korrelation besteht. Ausgenommen sind hier diejenigen Metriken, die Linearkombinationen von anderen Metriken sind (N_CONNECTORS, N_FUNCTIONS_CONNECTORS, N_JOIN_CONNECTORS, N_SPLIT_CONNECTORS). Diese besitzen ebenfalls jeweils eine hohe Korrelation untereinander bzw. mit den entsprechenden Metriken, aus deren Attribute sie sich zusammensetzen (N_FUNCTIONS, N_JOINAND,... ). Die gesamte Korrelationstabelle findet sich im Anhang E 6. Ein weiteres Mittel zur Feststellung, inwieweit sich unabhängige Variablen durch Linearkombinationen anderer unabhängiger Variablen beschreiben lassen, ist die Prüfung der Toleranz bzw. vom Variance Inflation Factor (VIF)[BEPW05]. Im Gegensatz zu den Korrelationskoeffizienten, bei denen die Korrelation zwischen jeweils zwei Variablen geprüft wird, wird dabei geprüft, wie gut sich eine unabhängige Variable durch die anderen Variablen bestimmen lässt. Dafür wird eine Regression einer zu prüfenden unabhängigen Variablen auf die anderen unabhängigen Variablen durchgeführt. Die Toleranz für eine unabhängige Variable X j wird berechnet durch: T j = 1 R 2 j Dabei ist Rj 2 das Bestimmtheitsmaß (Maß für die Güte der Anpassung der Regressionsfunktion an die verwendeten empirischen Daten) für die Regression von X j auf die übrigen unabhängigen Variablen in der Regressionsfunktion 6 Die Ausgabe von SPSS zu den Korrelationen befindet sich auf der CD zur Diplomarbeit. Dies gilt ebenfalls für alle Ausgaben bei den logistischen Regressionen. Frank Meyer 87

90 Metrik 1 Metrik 2 Korrelationskoeffizient N_CSETS CycleSetsComplexity 0,991 N_CSETS N_CYCLES 0,979 NestingLevel N_FUNCTIONS 0,709 NestingLevel N_EVENTS 0,708 NestingLevel N_ARCS 0,840 NestingLevel N_SPLITXOR 0,802 NestingLevel CFC 0,887 NestingLevel InterfaceComplexity 0,810 InterfaceComplexity N_FUNCTIONS 0,840 InterfaceComplexity N_EVENTS InterfaceComplexity JC 0,769 InterfaceComplexity N_ARCS 0,949 InterfaceComplexity CFC 0,796 CFC JC 0,795 CFC N_ARCS 0,784 CFC N_SPLITXOR 0,808 N_SPLITAND N_JOINAND 0,853 N_SPLITXOR N_JOINXOR 0,774 N_FUNCTIONS N_EVENTS 0,910 N_FUNCTIONS N_ARCS 0,930 N_ARCS N_EVENTS 0,897 RATIO_CFE RATIO_CF 0,951 Tabelle 11: Spearman-Rangkorrelationen zwischen den Metriken mit Werten über 0,7 f(x 1,..., X j 1, X j+1,..., X J ). Ein Wert fürrj 2 von 1 (und damit eine Toleranz von 0) bedeutet perfekte Anpassung, d.h die Variable X j kann durch eine Linearkombination der anderen unabhängigen Variablen erzeugt werden. Der Variance Inflation Factor stellt den Kehrwert der Toleranz dar: V IF j = 1 1 R 2 j In Tabelle 12 sind die Toleranz- und VIF-Werte der Metriken aufgeführt. Ausgenommen sind hier wiederum diejenigen Metriken, die Linearkombinationen von anderen Metriken sind und damit eine Toleranz von 0 besitzen. Wenig überraschend nach den Ergebnissen der Korrelationsanalyse sind die Toleranzwerte vieler Metriken nahe 0 bzw. umgekehrt die VIF-Werte entsprechend hoch. Nach [All99] kann ab einem VIF-Wert über 2,5 Multikollinearität vorliegen. Aus der Tabelle geht nicht hervor, welche Metriken im Einzelnen für die hohen VIF-Werte verantwortlich sind. Aus den Korrelationskoeffizienten können wir aber Annahmen darüber treffen. Folgende hohe Korrelationen lassen sich zwischen den Metriken feststellen: 1. Metriken zu Zyklen: Zwischen den drei Metriken zu Zyklen CycleSetsComplexity, N_CYCLES und N_CSETS besteht jeweils eine hohe Korrelation. 88 Frank Meyer

91 Metrik Toleranz VIF CFC 0, ,993 JC 0, ,820 CycleSetsComplexity (CSC) 0,134 7,435 N_CYCLES 0,437 2,288 N_CSETS 0,095 10,573 Unstructured 0,230 4,348 InterfaceComplexity (IC) 0,016 61,776 NestingLevel 0,092 10,850 N_EVENTS 0, ,199 N_ARCS 0, ,056 N_ENDEVENTS 0,141 7,069 N_FUNCTIONS 0,010 97,353 N_JOINAND 0,062 16,245 N_JOINOR 0,061 16,387 N_JOINXOR 0,035 28,837 N_SPLITAND 0,042 24,047 N_SPLITOR 0,187 5,345 N_SPLITXOR 0,035 28,837 N_STARTEVENTS 0,255 3,918 RATIO_CFE 0,127 7,892 RATIO_CF 0,083 12,041 RATIO_JS 0,344 2,904 Tabelle 12: Kollinearitätsstatistik der Metriken 2. N_FUNCTIONS, N_EVENTS, N_ARCS: Zwischen allen drei Metriken bestehen hohe Korrelationen. 3. RATIO_CFE, RATIO_CF: Wenig überraschend angesichts der hohen Korrelation zwischen N_FUNCTIONS und N_EVENTS ist die ebenfalls hohe Korrelation zwischen den beiden Verhältnismetriken RATIO_CFE und RATIO_CF. 4. CFC, JC: Die beiden Kontrollflussmetriken weisen ebenfalls eine hohe Korrelation auf. Als Grund dafür kann vermutet werden, dass viele Splitoperatoren einen zugehörigen Joinoperator vom gleichen Typ besitzen. 5. Split- und Joinoperatoren: Zwischen den Umfangsmetriken zu Split- und Joinoperatoren bestehen je nach Typ hohe Korrelationen 7. Auch die Korrelation zwischen OR-Splits und OR-Joins ist nur geringfügig unterhalb der 0,7-Grenze für Tabelle Dies ist vermutlich auch der Grund, weshalb Mendling et al.[mmn + 06] bei ihrer Studie zu Fehlern im SAP-Referenzmodell für die Joinoperatoren einen positiven Einfluss, für die Splitoperatoren hingegen einen negativen Einfluss auf die Fehlerwahrscheinlichkeit festgestellt haben (siehe Kapitel 4.1). Eine Betrachtung der Korrelation fand hier nicht statt. Stattdessen wurden in das Gesamtmodell alle Metriken aufgenommen, womit das Gesamtmodell möglicherweise fehlerhaft war. Für diese Vermutung spricht auch, dass die Splitoperatoren bei den univariaten Modellen einen positiven Einfluss auf die Fehlerwahrscheinlichkeit hatten. Frank Meyer 89

92 6. InterfaceComplexity: Die InterfaceComplexity-Metrik weist hohe Korrelationen mit den Umfangsmetriken N_FUNCTIONS, N_EVENTS und N_ARCS auf. 7. CFC, NestingLevel, N_SPLITXOR: Die NestingLevel-Metrik weist hohe Korrelationen mit den Umfangsmetriken N_FUNCTIONS, N_EVENTS und N_ARCS wie auch mit den Metriken InterfaceComplexity, CFC sowie N_SPLITXOR auf. Die hohen Korrelationen mit den Umfangsmetriken lassen sich daraus erklären, dass eine hohe Korrelation zwischen der Anzahl an Splitoperatoren und der Anzahl an Funktionen (sowie Ereignissen und Kanten) besteht, gleichzeitig aber auch eine hohe Korrelation der Verschachtelungstiefe zur Anzahl an Splitoperatoren. Tatsächlich besitzen die meisten EPK-Modelle nur wenige Splitoperatoren, 77,7% besitzen vier oder weniger. Entsprechend ist auch die Verschachtelungstiefe meistens gering, hier besitzen 78,2% der Modelle eine Verschachtelungstiefe von 9 oder weniger. Die hohe Korrelation zwischen CFC-Metrik, N_SPLITXOR-Metrik und Verschachtelungstiefe lässt sich daraus erklären, dass XOR-Splits bei weitem am häufigsten verwendet werden. So haben nur 22,9% der Modelle keine XOR-Splitoperatoren, während 82,7% keinen OR-Split und 51,4% keinen AND-Split besitzen (vgl. dazu Tabelle 10). Dabei haben 78,8% nur drei oder weniger XOR-Splitoperatoren. Entsprechend gibt es eine Häufung an Modellen mit generell wenigen Splitoperatoren, die demzufolge eine niedrige Verschachtelungstiefe besitzen Logistische Regressionsanalyse Im ersten Schritt wurden die univariaten Regressionsmodelle berechnet. Tabelle 13 führt die Ergebnisse auf. Folgende Beobachtungen lassen sich dabei machen: 1. Fast alle Umfangsmetriken weisen eine gute Signifikanz auf, d.h. die Signifikanz ist jeweils unterhalb der üblichen 5%-Grenze. Ausnahme sind nur die Umfangsmetriken zu OR-Operatoren (sowohl Splits als auch Joins), zu Startereignissen sowie zu AND-Joinoperatoren. Die schlechten Signifikanzen für die OR- und AND-Operatoren sind möglicherweise auf die große Anzahl an Modellen ohne diese Operatoren zurückzuführen (siehe dazu Tabelle 10). Alle Effekt-Koeffizienten sind größer als 1, d.h. bei allen Umfangsmetriken wirkt sich eine Erhöhung der Werte positiv auf die Wahrscheinlichkeit semantischer Modellfehler aus. Bei Funktionen sowie den damit stark korrelierenden Metriken zu Ereignissen und Kanten ist dieser Wert allerdings nahe bei Alle Verhältnismetriken weisen eine gute Signifikanz auf. Ebenso ist der Effekt- Koeffizient bei allen deutlich höher als Bei den Zyklenmetriken weist nur N_CYCLES eine Signifikanz unterhalb des 5%-Signifikanzniveaus auf. Alle Metriken haben einen Effekt-Koeffizienten, der geringfügig über 1 liegt. 4. Die Metrik zur Unstrukturiertheit (Unstructured) besitzt eine sehr gute Signifikanz und hat auch einen Effekt-Koeffizienten deutlich höher als Frank Meyer

93 Metrik Signifikanz Exp(B) CFC 0,703 1,003 JC 0,890 1,001 CycleSetsComplexity 0,621 1,006 N_CSETS 0,160 1,157 N_CYCLES 0,031 1,065 Unstructured 0,000 1,376 InterfaceComplexity 0,182 1,003 NestingLevel 0,000 1,056 N_CONNECTORS 0,001 1,123 N_EVENTS 0,026 1,042 N_ARCS 0,010 1,017 N_ENDEVENTS 0,020 1,279 N_FUNCTIONS 0,029 1,047 N_FUNCTIONS_CONNECTORS 0,006 1,039 N_JOINAND 0,077 1,220 N_JOINOR 0,512 1,106 N_JOINXOR 0,002 1,386 N_JOIN_CONNECTORS 0,001 1,254 N_SPLITAND 0,029 1,258 N_SPLITOR 0,334 1,287 N_SPLITXOR 0,002 1,276 N_SPLIT_CONNECTORS 0,001 1,228 N_STARTEVENTS 0,218 1,224 RATIO_CFE 0,012 4,570 RATIO_CF 0,001 5,231 RATIO_JS 0,039 1,911 Tabelle 13: Univariate logistische Regressionen 5. Die Metrik zur Verschachtelungstiefe (NestingLevel) weist ebenso eine sehr gute Signifikanz auf. Der Effekt-Koeffizient ist allerdings nur geringfügig höher als Alle weiteren Komplexitätsmetriken (CFC, JC sowie InterfaceComplexity) besitzen sowohl eine schlechte Signifikanz als auch einen Effekt-Koeffizienten nahe 1. Zusammenfassend lässt sich aus den Ergebnissen der univariaten Modelle vermuten, dass die Metrik zur Unstrukturiertheit, die Metriken zu Verknüpfungsoperatoren (insbesondere zu XOR-Operatoren), die Metrik zur Anzahl an Endereignissen sowie die Verhältnismetriken einen positiven Einfluss auf die Fehlerwahrscheinlichkeit haben. Auf Grundlage der Korrelationen und den Ergebnissen der univariaten Modelle wurden folgenden Metriken nicht in ein multivariates Modell aufgenommen: 1. Umfangsmetriken: N_FUNCTIONS, N_EVENTS sowie N_ARCS wurden auf- Frank Meyer 91

94 grund von Effekt-Koeffizienten nahe 1 und Korrelationen im Bereich von 0,5 mit den Umfangsmetriken zu Verknüpfungsoperatoren sowie mit der Metrik zur Unstrukturiertheit nicht aufgenommen. Ebenso wurden alle zusammengesetzten Umfangsmetriken zu Verknüpfungsoperatoren aufgrund der perfekten Multikollinearität mit den Einzelmetriken zu Verknüpfungsoperatoren nicht weiter berücksichtigt. 2. Verhältnismetriken: Von den drei Verhältnismetriken wurde RATIO_CFE aufgrund der hohen Korrelation mit RATIO_CF nicht in eine multivariates Modell mit aufgenommen. RATIO_CF ist die allgemeinere Metrik von beiden, die auch auf andere Modellierungssprachen übertragbar ist, und damit für die Validierung interessanter. 3. Metriken zu Zyklen: Zwischen allen drei Metriken zu Zyklen besteht eine hohe Korrelation. N_CYCLES hat dabei bei den univariaten Modellen die beste Signifikanz dieser drei Metriken und wurde deshalb als einzige bei den multivariaten Modellen berücksichtigt. 4. Metriken zum Kontrollfluss: Die beiden Metriken zum Kontrollfluss CFC und JC weisen bei den univariaten Modellen eine sehr schlechte Signifikanz auf. Ebenso bestehen hohe Korrelationen mit Umfangsmetriken, insbesondere zu N_SPLITXOR. Aus diesen Gründen wurden beide Metriken nicht weiter berücksichtigt. 5. Metrik zur Verschachtelungstiefe: Die Metrik zur Verschachtelungstiefe weist eine sehr gute Signifikanz beim univariaten Modell auf, wobei der Effekt- Koeffizient nahe bei 1 ist. Aufgrund hoher Korrelationen mit den Umfangsmetriken zu Verknüpfungsoperatoren, insbesondere zu N_SPLITXOR, wurde sie allerdings nicht weiter berücksichtigt. 6. InterfaceComplexity: Die InterfaceComplexity-Metrik wurde ebenfalls nicht weiter berücksichtigt, da sie Korrelationen > 0,5 mit einigen Umfangsmetriken zu Verknüpfungsoperatoren aufweist, gleichzeitig der Effekt-Koeffizient beim univariaten Modell aber nahe 1 ist. Nach den univariaten Modellen waren insbesondere die Einzelmetriken zu Verknüpfungsoperatoren sowie die Metrik zu Unstrukturiertheit interessant. Allerdings konnten nicht alle in ein gemeinsames Modell aufgenommen werden, da sowohl zwischen den Split- und Joinoperatoren nach jeweiligem Typ als auch zwischen der Unstrukturiertheitsmetrik und den Split- und Joinoperatoren (hierbei insbesondere zu den jeweiligen XOR-Operatoren) hohe Korrelationen bestehen. Deshalb wurden insgesamt drei multivariate Modelle aufgestellt, bei denen jeweils nur eine der drei Metriken bzw. Metrikgruppen (Splits, Joins, Unstrukturiertheit) berücksichtigt wurde. Zusätzlich wurden jeweils die N_CYCLES-Metrik, die Umfangsmetriken zu Startund Endereignissen sowie die beiden Verhältnismetriken RATIO_CF und RATIO_JS mit aufgenommen. Tabelle 14 führt die Ergebnisse der logistischen Regression für die drei Modelle auf. Erstaunlich bei den drei multivariaten Modellen ist auf den ersten Blick die schlechte Signifikanz wie auch die im Vergleich zu den univariaten Modellen unterschied- 92 Frank Meyer

95 Unstructured Splits Joins Metrik Sig. Exp(B) Sig. Exp(B) Sig. Exp(B) Unstructured 0,000 1,379 N_SPLITAND 0,142 1,203 N_SPLITOR 0,911 1,033 N_SPLITXOR 0,170 1,178 N_JOINAND 0,275 1,149 N_JOINOR 0,691 0,922 N_JOINXOR 0,138 1,251 N_CYCLES 0,595 1,018 0,405 1,030 0,540 1,023 N_ENDEVENTS 0,906 1,022 0,251 1,204 0,015 1,390 N_STARTEVENTS 0,921 0,976 0,514 0,856 0,364 0,808 RATIO_CF 0,042 3,153 0,009 4,151 0,005 4,754 RATIO_JS 0,071 2,558 0,043 2,797 0,075 2,428 Nagelkerke-R 2 0,388 0,258 0,258 Richtig klassifizierte Modelle 86,0% 86,0% 86,0% Richtig klassifizierte fehlerhafte 34,5% 27,6% 24,1% Modelle Tabelle 14: Multivariate logistische Regressionen lichen Effekt-Koeffizienten der Metriken N_STARTEVENTS, N_ENDEVENTS und N_CYCLES. Zurückzuführen ist dies auf weitere relativ hohe Korrelationen dieser Metriken mit einigen anderen Metriken in den Regressionsmodellen: 1. Zwischen der N_STARTEVENTS-Metrik und der RATIO_JS-Metrik besteht eine recht hohe Korrelation von 0,491. Diese lässt sich daraus erklären, dass Modelle mit mehreren Startknoten diese mit Joinoperatoren zusammenführen, aber umgekehrt nicht unbedingt auch mehrere Endknoten besitzen, für die entsprechende Splitoperatoren erforderlich wären. Bei den multivariaten Regressionsmodellen resultiert daraus ein Effekt-Koeffizient kleiner 1 für die N_STARTEVENTS-Metrik sowie eine schlechte Signifikanz. 2. Die N_ENDEVENTS-Metrik hat relativ hohe Korrelationen mit der Metrik zur Unstrukturiertheit und der N_SPLITXOR-Metrik. Deutlich wird dies bei den multivariaten Modellen in der Form, als dass die N_ENDEVENTS-Metrik beim Modell mit den Joinoperatoren eine sehr gute Signifikanz wie auch einen deutlich über 1 liegenden Effekt-Koeffizienten besitzt, bei den anderen beiden Modellen aber eine schlechte Signifikanz hat. 3. Die N_CYCLES-Metrik besitzt sowohl mit der Metrik zur Unstrukturiertheit als auch mit den XOR-Metriken für Join- und Splitoperatoren eine relativ hohe Korrelation. Die Güte der drei Gesamtmodelle ist nach den Werten der Nagelkerke-R 2 - Statistiken jeweils im akzeptablen Bereich (nach [BEPW05] weisen Werte größer Frank Meyer 93

96 0,2 auf eine akzeptable Modellgüte hin, Werte ab 0,4 auf ein gute Modellgüte). Alle multivariaten Regressionsmodelle konnten 86% der EPK-Modelle richtig klassifizieren, wobei es Unterschiede im Prozentsatz der richtig klassifizierten fehlerhaften und der richtig klassifizierten fehlerfreien Modelle gibt. Hierbei ist hinzuzufügen, dass die Klassifizierung auf denselben Daten wie für die Modellerstellungen erfolgte. Wünschenswerter wäre es gewesen, einen Teildatensatz für die Erstellung der Modelle zu verwenden und ein zweiten Datensatz für die Prüfung der Modelle. Aufgrund der geringen Anzahl an fehlerhaften EPK-Modellen konnte dies aber leider nicht erfolgen. Nach den Ergebnissen der univariaten wie auch der multivariaten Modelle weist insbesondere die Metrik zur Unstrukturiertheit eine hohe Signifikanz als auch eine positive Auswirkung auf die Fehlerwahrscheinlichkeit von EPK-Modellen auf. Bei den Umfangsmetriken zu Verknüpfungsoperatoren weisen diejenigen zu XOR- Operatoren, mit Abstrichen auch die zu AND-Operatoren eine relativ gute Signifikanz und eine positive Auswirkung auf die Fehlerwahrscheinlichkeit auf. Diese Ergebnisse entsprechen den Resultaten zumindest der univariaten Regressionsmodelle in [MMN + 06]. Dass die Metriken zu OR-Operatoren keine guten Signifikanzen aufweisen ist vermutlich auf die geringe Anzahl an EPK-Modellen mit OR- Operatoren zurückzuführen, die zur Verfügung standen. Ebenfalls eine sehr gute Signifikanz wie auch einen deutlich über 1 liegenden Effekt- Koeffizienten weist die RATIO_CF-Metrik auf. Auch die Metriken N_ENDEVENTS und RATIO_JS sowie mit Abstrichen N_STARTEVENTS weisen bei den univariaten Modellen eine gute Signifikanz und einen positiven Einfluss auf die Fehlerwahrscheinlichkeit auf. Allerdings sind die Ergebnisse der multivariaten Regressionsmodelle aufgrund der Korrelationen nur bedingt aussagekräftig. Die Metrik N_CYCLES weist bei den multivariaten Modellen keine hohe Signifikanz auf, was wie bereits beschrieben auf die Korrelationen mit anderen Metriken zurückzuführen ist. Allerdings war auch der Effekt-Koeffizient der Metrik beim univariaten Modell nur geringfügig höher als 1. Bei einer logistischen Regression dieser Metrik für die EPK-Modelle unter Ausschluss von stark sound als Fehlerkriterium wies die Metrik allerdings einen höheren Effekt-Koeffizienten auf. Tatsächlich hatten dabei auch alle fehlerhaften Modelle Zyklen. 7.2 Probleme und Bewertung der Validierung Es stellt sich natürlich die Frage, inwieweit die Ergebnisse repräsentativ sind. Die Validierung leidet unter einigen tatsächlichen und einigen möglichen Probleme, die teilweise schon benannt wurden und die hier noch einmal aufgeführt werden sollen: 1. Praxisrelevanz: Bei der Auswahl der Modelle wurde darauf geachtet, dass diese praxisrelevant sind. Ein großer Anteil der Modelle stammt aber aus Diplomarbeiten, wissenschaftlichen Veröffentlichungen und anderen Publikationsformen, sind also nicht direkt aus Unternehmen. Die Frage, ob die verwendeten 94 Frank Meyer

97 Modelle auch tatsächlich repräsentativ für Unternehmensmodelle sind, lässt sich deshalb nicht beantworten. 2. Modellanzahl: Insgesamt wurden 179 Modelle für die Validierung verwendet. Davon hatten nur 29 Modelle semantische Fehler, was die Repräsentativität der Regressionsergebnisse einschränkt. Aufgrund der geringen Anzahl an fehlerhaften Modellen konnte für die logistischen Regressionen auch keine Aufteilung der Datensätze in einen Datensatz zur Modellbildung und einen Datensatz zur Modellprüfung erfolgen. 3. Mögliche Fehlerquellen: Es gibt eine Reihe weiterer möglicher Fehlerquellen für die Validierung. Dies betrifft zum einen den Kontext, in dem die EPK- Modelle entstanden sind. Hier können keine Aussagen über die Erfahrung der Modellierer und den möglichen Zeitdruck bei der Modellierung getroffen werden. Dies kann durchaus Einfluss auf die Fehlerhaftigkeit der Modelle haben. Weitere mögliche Fehlerquellen entstehen aus den Schritten vom vorliegenden Modell in einer Publikation bis zur Validierung. Dies betrifft die Digitalisierung der Modelle in das EPML-Format, die Korrektur syntaktischer Fehler, die Festlegung von Startbelegungen bei einigen Modellen als auch ggf. Fehler von EPCTools für die Berechnung der semantischen Eigenschaften sowie des Metriktools für die Berechnung der Metriken. Auch wenn darauf geachtet wurde, diese Aufgaben korrekt durchzuführen, bestehen hier aufgrund der Anzahl an Zwischenschritten Fehlermöglichkeiten. Ebenfalls ist zu beachten, dass Syntaxfehler und inhaltliche Fehler der Modelle bei der Validierung nicht beachtet wurden. Bei der Bewertung der Ergebnisse ist zu unterscheiden zwischen den Ergebnissen der Korrelationsanalyse und denen der logistischen Regressionen. Die Ergebnisse der Korrelationsanalyse beruhen auf allen 179 EPK-Modellen und können deshalb als repräsentativ angesehen werden. Aus den Ergebnissen lässt sich ableiten, dass eine große Anzahl an Metriken redundante Informationen enthält. Aufgrund dieser Ergebnisse kann bei zukünftigen Validierungen und Implementierungen die Anzahl der Metriken reduziert werden. Die Ergebnisse der logistische Regressionen sind sicherlich aufgrund der genannten Probleme als weniger repräsentativ einzustufen. Dennoch bestätigen die Ergebnisse zu großen Teilen diejenigen von Mendling et al.[mmn + 06]. Noch einmal zusammengefasst lieferten die logistischen Regressionen folgende Erkenntnisse: 1. Die Anzahl an Funktionen, Ereignissen und Kanten hat nur einen recht geringen Einfluss auf die Fehlerwahrscheinlichkeit von EPK-Modellen. 2. Die Anzahl an Verknüpfungsoperatoren hat offensichtlich einen recht hohen positiven Einfluss auf die Fehlerhaftigkeit von Modellen. Dies konnte zumindest für AND- und XOR-Operatoren bestätigt werden, für OR-Operatoren lagen vermutlich nicht genügend Modelle vor, um eine genügende Signifikanz festzustellen. 3. Eine besonders gute Signifikanz wie auch ein positiver Einfluss auf die Fehlerwahrscheinlichkeit konnte für die Metrik zur Unstrukturiertheit festgestellt werden. Frank Meyer 95

98 4. Die Kontrollflussmetriken CFC und JC liefern keine Erklärung für die Fehlerhaftigkeit von EPK-Modellen. 5. Bei den Metriken zu Zyklen hatten nur N_CYCLES und NumberCyclesSets eine akzeptable Signifikanz bei den univariaten Modellen, der Einfluss auf die Fehlerwahrscheinlichkeit war jeweils im niedrigen positiven Bereich. 6. Die Metriken zur Anzahl an Start- und Endereignissen haben nach den Ergebnissen der univariaten Modelle einen positiven Einfluss auf die Fehlerwahrscheinlichkeit. Allerdings war für die Anzahl an Startereignissen die Signifikanz überhalb der 5%-Grenze. Die RATIO_JS-Metrik wies eine hohe Korrelation mit diesen Metriken auf und besaß ebenfalls einen positiven Einfluss auf die Fehlerwahrscheinlichkeit. 7. Die Verhältnismetrik RATIO_CF hatte sowohl eine sehr gute Signifikanz wie auch einen hohen positiven Einfluss auf die Fehlerwahrscheinlichkeit der Modelle. 8. Für die Metrik zur Verschachtelungstiefe und die InterfaceComplexity-Metrik wurden nur geringe Einflüsse auf die Fehlerwahrscheinlichkeit der EPK- Modelle festgestellt. Auf Grundlage der Korrelationen und unter dem Aspekt, möglichst Metriken zu verwenden, die sich auch auf andere Modellierungssprachen von Geschäftsprozessen übertragen lassen, sind für zukünftige Betrachtungen folgende besonders interessant: 1. Metrik zur Unstrukturiertheit (Unstructured) 2. Umfangsmetriken zur Verknüpfungsoperatoren (N_SPLITXOR, N_SPLITOR, N_SPLITAND, N_JOINXOR, N_JOINOR, N_JOINAND) 3. Umfangsmetrik zur Anzahl an Funktionen bzw. in allgemeiner Form zur Anzahl an Aktivitäten (N_FUNCTIONS) 4. Metrik zur Anzahl an Zyklen (N_CYCLES) 5. Verhältnismetrik Verknüpfungsoperatoren - Funktionen bzw. in allgemeiner Form Verknüpfungsoperatoren - Aktivitäten (RATIO_CF) 6. Metrik zur Verschachtelungstiefe (NestingLevel) 7. Metrik zur Kontrollflusskomplexität von Splitoperatoren (CFC) 8. Metriken zur Anzahl an Start- und Endereignissen (N_STARTEVENTS, N_ENDEVENTS); diese sind vor allem für EPK-Modelle interessant, während die anderen Metriken auch für andere Modellierungssprachen interessant sind. 96 Frank Meyer

99 8 Bewertung In der Arbeit wurden verschiedene Metriken für die Komplexität des Kontrollflusses in Geschäftsprozessmodellen vorgestellt. Neben einigen bereits in der Literatur erwähnten Metriken vor allem im Bereich der Umfangsmetriken wurden weitere Metriken vorgeschlagen, die sich größtenteils auf die syntaktische Struktur von Prozessmodellen beziehen. Die Metriken wurden bis auf wenige Ausnahmen für UML- Aktivitätsdiagramme anhand der EPK-Syntax definiert. Die meisten lassen sich dabei auch auf Prozessmodelle in anderen Modellierungssprachen für Geschäftsprozesse übertragen. Ebenfalls wurde im Rahmen der Arbeit das Tool EPCMetrics entwickelt, mit dem sich sowohl in einem Batchmodus als auch integriert in ein Modellierungstool die vorgestellten Metriken für EPK-Modelle berechnen lassen. Die Auswahl der Metriken lässt sich dabei frei konfigurieren. Ebenfalls ist das Tool leicht um weitere Metriken erweiterbar. Im Moment kann es nur Dateien im EPML-Format verarbeiten, es lässt sich aber auch um andere Dateiformate erweitern. Das Datenmodell des Programms berücksichtigt zur Zeit nur Elemente des Kontrollflusses von EPK- Modellen. Interessant wäre sicherlich eine Erweitung um Elemente zum Datenfluss und anderen Modellierungsmöglichkeiten im Rahmen erweiterter EPKs, damit auch entsprechende Metriken für diese Aspekte implementiert werden können. Das Tool wird auf einem Workshop über Ereignisgesteuerte Prozessketten vorgestellt werden und soll anderen Benutzern zur Verfügung gestellt werden. Eine praktische Validierung der Metriken zeigte, dass zwischen einer großen Anzahl verschiedener Metriken hohe Korrelationen bestehen. Als Konsequenz daraus kann bei zukünftigen Validierungen und Implementierungen auf einen Teil der Metriken verzichtet werden. Weiterhin lassen die Ergebnisse der logistischen Regressionen die Vermutung zu, dass insbesondere die Metrik zur Unstrukturiertheit und die Umfangsmetriken zu Verknüpfungsoperatoren einen positiven Einfluss auf die Wahrscheinlichkeit semantischer Modellfehler haben. Eingeschränkt werden diese Ergebnisse durch die geringe Anzahl an fehlerhaften Modellen. Für eine Bestätigung dieser Ergebnisse sind deshalb sicherlich weitere Validierungen notwendig. Insbesondere ist wünschenswert, dass mehr Modelle aus Unternehmen zur Validierung herangezogen werden. Diese waren bei der im Rahmen dieser Arbeit erfolgten Validierung deutlich unterrepräsentiert. Frank Meyer 97

100 A Semantische Eigenschaften von EPK-Modellen 1. Soundness: Ein Modell ist stark sound im momentanen Zustand (d.h. mit der momentanen Verteilung von Token), wenn von allen erreichbaren Zuständen ein Endzustand erreicht werden kann. Ein Endzustand ist hierbei ein Zustand, wo nur noch Endereignisse Token besitzen. Ein Modell ist schwach sound im momentanten Zustand, wenn für einige der erreichbaren Zustände ein Endzustand erreicht werden kann. Mit der Soundness-Eigenschaft kann also u.a. geprüft werden, ob Verklemmungen mit dem momentanen Zustand möglich sind oder ob tote Bereiche aus dem momentanen Zustand erreichbar sind. Für eine genauere Definition von Soundness und schwacher Soundness sei auf [Aal99, Mar03] verwiesen. 2. Sauberkeit (clean): Bei XOR- und OR-Joinoperatoren kann es zu Situationen kommen, für die nicht entschieden werden kann, ob ein Token an einer eingehenden Kante weitergeleitet werden kann, da möglicherweise auch an anderen eingehenden Kanten noch Token ankommen. [CK04] stellen hier zwei unterschiedliche Transitionsregeln für vor, eine optimistische, die einen Token in einen solchen Fall weiterleitet und eine pessimistische, die in solchen Situationen stoppt. Falls die optimistische Regel und die pessimistische Regel nicht gleich sind, wird dies als unsauber bezeichnet. Ein Modell, welches mit der momentanten Verteilung von Token keine solche Situation erreichen kann, wird als sauber (clean) im momentanten Zustand bezeichnet. 3. Kontaktfreiheit: Ein Knoten ist in einer Kontaktsituation, wenn er einen Token nicht weitergeben kann, weil auf einer ausgehenden Kante bereits ein Token vorhanden ist. Falls ein Modell mit der momentanten Verteilung von Token keine solche Situation erreichen kann, ist es kontaktfrei im momentanen Zustand. Abb. 25 zeigt ein Modell, welches nicht kontaktfrei ist. Falls S1 Token über die beiden ausgehenden Kanten weitergibt, so kann über S2-E2-J1 wieder ein Token zu S1 gelangen. S1 kann aber nun nicht schalten, da bei F1 noch ein Token anliegt, der noch nicht über J2 weitergegeben werden konnte. Für eine genauere Definition sei auf [CK04] verwiesen. 98 Frank Meyer

101 Abbildung 25: Nicht kontaktfreies EPK-Modell Frank Meyer 99