Für funktionale Systemtests großer, komponenten- und serviceorientierter betrieblicher Anwendungssoftware sind durchgängige Testszenarien sinnvoll, die für die wichtigsten, geschäftskritischen betrieblichen Abläufe des Anwenders vorzubereiten und durchzuführen sind. Zur Unterstützung der Ermittlung solcher „higher order“ Testfälle wird eine systematische Methode der Extraktion verzweigungsfreier Wege durch EPK-Schemata vorgeschlagen. Um die vorgestellte Methode praktikabel zu machen werden optionale Annahmen zur kombinatorischen Relaxation getroffen. Die Methode ist als Erweiterung der Open-Source Initiative „EPC-Tools“ implementiert.
verzweigungsfreie Wege als Grundlage für die Ausarbeitung von Testszenarien durch dieses Ablaufschema extrahiert werden können.
Der weitere Beitrag ist folgendermaßen aufgebaut: in Kapitel 2 werden weitere Arbeiten diskutiert, die mit dem hier vorgestellten Lösungsansatz verwandt sind oder für den Hintergrund und die verwendeten Begriffe eine Rolle spielen; in Kapitel 3 wird die Methode im Detail vorgestellt; Kapitel 4 stellt die dazu entwickelte Werkzeugerweiterung vor; Kapitel 5 schließt den Beitrag mit einer Zusammenfassung und einem Ausblick.
Für die Modellierung von Geschäftsprozessen gibt es heute viele kommerzielle Werkzeuge („workflow management systems“), die verschiedenen methodischen Ansätzen und Notationsgrammatiken folgen (z.B. [AH02; Mu02]). Dieser Beitrag geht von der Ereignisgesteuerten Prozesskette (EPK) [KNS92] aus, weil sie eine besonders intuitive und speziell im deutschsprachigen Raum weit verbreitete, semiformale Notation für die Modellierung betriebliche Abläufe ist, die schon seit einiger Zeit ergiebig erforscht und auch erfolgreich in der Praxis eingesetzt wird (z.B. [Sc02], [DJ05]). Szenarien können als (Teil-)Modelle betrachtet werden und sind wichtige Bausteine der Softwareentwicklung, sie helfen bei der Erfassung von funktionalen Anforderungen und beeinflussen Design, Implementierung und funktionalen Test [Br00; Su03; CR05]. Bei der funktionalen Prüfung von Software auf Anwenderseite (d.h. Black-Box Systemtest [Be95]) sind szenario-orientierte Vorgehensweisen gut bekannt und werden z.B. bei der Testfallermittlung auf Grundlage von UML Anwendungsfällen („use cases“) eingesetzt [OA99; BL02; SZ04].
Prüfprozesse in der Softwareentwicklung werden allgemein etwa in [My79; Ri97; ISO01] diskutiert, für Test und Qualitätssicherung im komponentenorientierten Paradigma etwa in [We98; GTW03; Me03; Vi+03]. Für die Entwicklung – und dabei besonders für den funktionalen Systemtest – von flexiblen, komponenten- und serviceorientierten Anwendungssystemen werden wichtige Vorteile durch die SzenarioOrientierung diskutiert, cf. etwa [EDF96; SZ04].
Mit vollständig formalen Spezifikationen und „kleinen“ betrachteten Domänen sind szenario-orientierte Prüfmethoden gut bekannt, z.B. in der technischen Informatik als Spuren („traces“) im Rahmen des „model checking“, vgl. etwa [CH03; Br+05] oder vertiefend [Ku+05]. Diese Ansätze lassen sich aber nur eingeschränkt auf semiformal und i.a. unvollständig beschriebene, funktional im Vergleich wesentlich größere Modelle betrieblicher Abläufe übertragen. Solche Modelle haben, wie z.B. in [DJ05] gezeigt wurde, eigene Besonderheiten, zumal es letztlich um „higher order“ Prüfschritte [My79, S. 103ff] geht, die über rein syntaktische Kriterien hinaus reichen.
Um trotzdem klar abgegrenzte Szenarien als Ausgangspunkt für die Definition weiterer konkreter Prüfschritte in großen und semiformalen EPK-Modellen zu finden, erweist sich die Idee der „Workflow Patterns“ [Aa+03] (Ablauf- oder Kontrollfluss-Muster) als nützlich. Betrachtet man das Schema der betrieblichen Abläufe analog zum Kontrollfluss eines deterministischen Programms, dann kann man den gerichteten Graph des Ablaufschemas mittels weniger grundlegender Ablaufmuster aus [Aa+03] auf enthaltene verzweigungsfreie Szenarien analysieren. Ein lineares Szenario hat (in Anlehnung an die Spuren der linearen temporalen Logik) von jedem Knoten maximal eine ausgehende Kante in einen Folgeknoten, und das komplexe betriebliche Ablaufschema wird über die Ablaufmuster an den „Verzweigungsstellen“ in einzelne solche linearen Durchläufe zerlegt.
In [Sc00] wird ein Ansatz vorgeschlagen, der eine ähnliche Linearisierungsidee, die dort an Konzepte aus der Netzplantechnik angelehnt wird, nicht erst für die Gewinnung von Testszenarien sondern schon für die Konstruktion der Ablaufmodelle selbst verfolgt. In [MNN05] wird eine (hier nicht erforderliche) Erweiterung der EPK zur Unterstützung aller „Workflow Patterns“ aus [Aa+03] diskutiert.
Für die automatische Ermittlung dieser Szenarien aus den als EPK modellierten Ablaufschemata ist eine vollständig formale Syntax und Semantik für EPK notwendig, wobei es wesentlich um die Formalisierung der logischen Konnektoren (der „Verzweigungsstellen“ im Schema) geht. Dieser Beitrag baut dabei auf den Vorschlägen [Aa99; NR02; GL06] auf, und zusätzlich auf [Ri99] für die Wohlgeformtheit von SplitJoin-Paaren im Ablaufschema, sowie auf [Kin06] für die Minimierung der sog. nichtlokalen EPK-Semantik.
Zur graphischen Darstellung der EPK gibt es als Notationssymbole einen gerichteten Kantentyp und fünf unterschiedliche Knotentypen (Abbildung 1). Kantentyp ist der Kontrollfluss. Die fünf Knotentypen sind Ereignis, Funktion, und logischer Konnektor vom konjunktiven Typ („a und b“, AND), disjunktiven Typ („entweder a oder b“, XOR), und adjunktiven Typ („a oder auch b“, OR).
Kontrollfluss
Ereignis
Funktion Ein syntaktisch korrektes EPK-Schema A sei ein Tupel A = (E,F,C,T,S0 ) mit den folgenden Eigenschaften: – E ist eine nichtleere Menge von Ereignisknoten. – F ist eine nichtleere Menge von Funktionsknoten. – C ist eine Menge von logischen Konnektoren, bestehend aus paarweise disjunkten
Teilmengen C AND ,C XOR ,COR . – E, F, C sind paarweise disjunkt. – Der Kontrollfluss T : (N × N) ist eine Übergangsfunktion mit N = E ∪ F ∪ C . – S0 ist eine Menge von Startereignissen.
Ein syntaktisch korrektes EPK-Schema sei mit den folgenden Eigenschaften auch sematisch korrekt: 1) G = (N,T) ist ein gerichteter, zusammenhängender und endlicher Graph. 2) Zwischen zwei Knoten existiert maximal eine Kontrollflusskante. 3) Funktionsknoten haben genau eine eingehende und genau eine ausgehende
Kontrollflusskante. 4) Ereignisknoten haben maximal eine eingehende und maximal eine ausgehende
Kontrollflusskante. 5) Konnektoren haben entweder genau eine eingehende und mehrere ausgehende Kontrollflusskanten (und heißen dann Split), oder mehrere eingehende und genau eine ausgehende Kontrollflusskante (und heißen dann Join). 6) Ereignisknoten sind nur mit Funktionsknoten verbunden, möglicherweise über
Konnektoren. 7) Funktionsknoten sind nur mit Ereignisknoten verbunden, möglicherweise über
Konnektoren. 8) Es gibt keinen Kreis, der nur aus Konnektoren besteht. 9) Es gibt mindestens ein Startereignis (ohne eingehende Kontrollflusskante) und mindestens ein Endereignis (ohne ausgehende Kontrollflusskante). 10) Nach Ereignisknoten folgt kein XOR-Split und kein OR-Split im Kontrollfluss (vgl. [KNS92, S. 15]). 11) Jeder Knoten ist von einem Startereignis erreichbar. 12) Von jedem Knoten ist ein Endereignis erreichbar.
Zusätzlich seien semantisch wohlstrukturierte Split-Join-Paare gefordert, so dass der öffnende Split und der schließende Join eines Paares jeweils vom gleichen Typ sind (vgl. vertiefend [Ri99, S. 2]).
Die musterbasierte Analyse der EPK-Schemata zur Ermittlung verzweigungsfreier Wege erfolgt anhand der drei fundamentalen Modellierungsprimitive Sequenz, Selektion und Iteration, die auch den „Workflow Patterns“ aus [Aa+03] zugrunde liegen.
Die Sequenz ist die fundamentale Idee des Ablaufs von diskreten Einzelschritten nach einander (Abbildung 2). Die gängige semantische Interpretation ist Implikation bzw. Kausalität.
E1
F1
E2
F2
E3 Abbildung 2: Lineare Sequenz Lineare Sequenzen sind eben die verzweigungsfreie Wege, die das angestrebte Ergebnis der Linearisierung darstellen. Die Linearisierung eines EPK-Schema erzeugt alle möglichen solchen Wege vom Startereignis zum Endereignis. Ein EPK-Schema, das wie in Abbildung 2 nur aus einem verzweigungsfreien Weg besteht, ist bereits linear.
Split-Konnektoren besitzen genau eine eingehende und mehr als eine ausgehende Kante (vgl. 3.1, Nr. 9). Die Selektion mit Splits stellt die fundamentale Idee eines sich in der Zukunft verzweigenden Ablaufs dar. Abbildung 3 zeigt die zwei Muster, wobei der Split nach einem Ereignis (linke Seite der Abbildung 3) nur vom Typ AND, nicht aber vom Typ OR und auch nicht vom Typ XOR sein kann (vgl. 3.1, Nr. 10).
F1
F2 E1
F1
C
E1 E2
Abbildung 3: Selektion mit Split-Konnektor Tabelle 1 zeigt die Ergebnisse der Linearisierung dieser Muster aus Abbildung 3, abhängig vom Konnektortyp. Die Muster werden in alle möglichen Abläufe expandiert. Typ AND XOR OR
Linearisierung nach Ereignis (E1, F1, F2), (E1, F2, F1) nicht definiert nicht definiert
Linearisierung nach Funktion (F1, E1, E2), (F1, E2, E1) (F1, E1), (F1, E2) (F1, E1), (F1, E2), (F1, E1, E2), (F1, E2, E1)
Tabelle 1: Linearisierung für Split-Konnektor Gängige semantische Interpretationen für den AND-Split ist die Parallelbearbeitung, für den XOR-Split die Entscheidung. Der OR-Split ist nur schwierig intuitiv zu interpretieren. Er kann als Kombination aus AND- und XOR-Split behandelt werden, da die logische Semantik eine Kombination von AND und XOR darstellt.
Join-Konnektoren besitzen mehr als eine eingehende und genau eine ausgehende Kante (vgl. 3.1, Nr. 9). Die Selektion mit Joins stellt die fundamentale Idee sich vereinigender Abläufe dar. Daraus folgt, dass durch das jeweilige Schema in der Vergangenheit vor dem Konnektor mehr als ein Weg möglich ist. Abbildung 4 zeigt die zwei Muster.
F1 F2
C
E1
C
F1 Abbildung 4: Selektion mit Join-Konnektor
E1 E2 Tabelle 2 zeigt die Ergebnisse der Linearisierung dieser Muster aus Abbildung 4, abhängig vom Konnektortyp. Die Muster werden in alle möglichen Abläufe expandiert. Gängige semantische Interpretationen für den AND-Join ist die Synchronisierung, für den XOR-Join der Auslöser („trigger“). Der OR-Join ist ähnlich wie sein Split-Pendant nur schwierig intuitiv zu interpretieren, er kann aber ebenfalls als Kombination aus AND- und XOR-Join behandelt werden, da seine logische Semantik eine Kombination von AND und XOR darstellt.
Typ AND XOR OR
Linearisierung vor Ereignis (F1, F2, E1), (F2, F1, E1) (F1, E1), (F2, E1) (F1, E1), (F2, E1), (F1, F2, E1), (F2, F1, E1)
Linearisierung vor Funktion (E1, E2, F1), (E2, E1, F1) (E1, F1), (E2, F1) (E1, F1), (E1, F2), (E1, E2, F1), (E2, E1, F1)
Tabelle 2: Linearisierung für Join-Konnektor Es geht bei der Linearisierung der Join-Muster darum, den nach dem vereinigenden Join nächsten Schritt zu finden. Zwar ist, unabhängig von Typ des Join, der Folgeschritt nach dem Join immer eindeutig (vgl. 3.1, Nr. 5). Das Schema hat vor dem Join aber Verzweigungen, diese sind bis zum Join schon in die möglichen verzweigungsfreien Wege aufgespalten. Betrachtet man also einen einzelnen verzweigungsfreien Weg, dann wird jeder Join auf diesem Weg verzweigungsfrei erreicht. Die Behandlung der JoinMuster zur Linearisierung wäre soweit trivial. Es stellt sich aber die Frage, wie die miteinander zu kombinierenden Split-Join-Sequenzen bestimmt werden, da sie nicht unbedingt eindeutig sind.
Bestimmt werden muss zu jedem Join der entsprechend passende Split, und damit der genaue Nachbereich aller im Schema vorhandenen Splits. Die Forderung nach semantisch wohlstrukturierten Split-Join-Paaren (vgl. 3.1) verlangt, dass im Schema jedem Split ein Join vom gleichen Typ entspricht. Der Nachbereich beginnt mit dem Split-Konnektor selbst und wird entweder auf einem entsprechenden Join-Konnektor geschlossen oder endet mit einem Endereignis. Für einen Split ist der entsprechend passende Join: der unter allen Kindknoten (d.h. allen von Split aus erreichbaren Knoten), mittels Breitensuche (breadth first search), erste erreichbare Join vom gleichen Typ nach mindestens einem Ereignis- oder Funktionsknoten.
Die Linearisierung benötigt hier zur praktischen Handhabbarkeit zusätzlich noch sinnvolle Annahmen zur Einschränkung der zu prüfenden Kombinationen. Es kann für die Bildung von funktionalen Testszenarien von einer ausdrücklichen Betrachtung der unterschiedlichen Ausführungsreihenfolgen abgesehen werden, da angenommen werden kann, dass diese auch nicht modelliert sind. Zusätzlich können, in Anlehnung an die gängige Vorgehensweise des Testens an Randbereichen („boundary value“), bei OR mit ⎛ n ⎞ ⎛ n ⎞ n > 2 Alternativen nur die „Randfälle“ ⎜⎜ ⎟⎟ und ⎜⎜ ⎟⎟ betrachtet werden. ⎝ 1 ⎠ ⎝ n ⎠
F1 Die Iteration ist die fundamentale Idee eines sich gleichartig wiederholenden Ablaufs (Abbildung 5). Die gängige semantische Interpretation ist die Scheife.
Iterationen verwenden nur XOR-Konnektoren: die Joins der Iteration müssen offensichtlich disjunktiv sein, und für die entsprechenden Splits ist semantisch der gleiche Typ gefordert (vgl. 3.1).
E1
F2 Abbildung 5: Iteration E2 Tabelle 3 zeigt die Ergebnisse der Linearisierung des Iterationsmusters aus Abbildung 5. Die Iteration wird in alle möglichen Abläufe expandiert. Die Linearisierung der Iteration ist also einfach, benötigt aber zur praktischen Handhabbarkeit zusätzlich sinnvolle Annahmen zur Einschränkung der Anzahl der zu prüfenden Durchläufe. In Anlehnung z.B. an [Ri97] erfolgt die funktionale Prüfung mit keinem („oben geprüfte Schleife“), einem, oder n > 1 Durchläufen, wobei n = 2 gesetzt werden kann.
Zur Bestimmung aller verzweigungsfreien Wege wird eine Erweiterung des BFS Standardalgorithmus („Breadth First Search“, Breitensuche) aus der Graphentheorie verwendet. Dabei ist BFS für die Auffindung aller Wege erweitert (Standard-BFS findet kürzeste Wege), und für die Behandlung der EPK-Konnektoren sowie der Iterationen angepasst.
Für die Zeitkomplexität des Algorithmus gilt Ο(N + T) , da alle möglichen Wege betrachtet werden, wofür jede Kante und jeder Knoten besucht wird und jeder Schritt eine konstante Zeit benötigt (mit Standard-BFS ist das der ungünstigste Fall, hier gilt es immer). Für die Platzkomplexität gilt ebenfalls Ο(N + T) , da alle bisher besuchten Knoten gespeichert werden bis die nächsttiefere Ebene des Graphen erreicht ist. Die Methode ist damit für größere Probleme nur geeignet, wenn in den betrachteten EPK-Schemata die Anzahl der Knoten N (Ereignisse, Funktionen und Konnektoren) plus die Anzahl der Kanten T (Kontrollflüsse) mit zunehmender Tiefe des Schemas nicht exponentiell wächst. Allgemein graphentheoretisch ist natürlich von exponentiellem Wachstum auszugehen. Wie aber aus den „No Free Lunch“ Theoremen [WM95; WM97] gefolgert werden kann, ist ein algorithmisches Such- oder Optimierungsverfahren möglichst gut an die untersuchte Problemklasse anzupassen, indem sinnvolle Annahmen zur Problemstellung getroffen werden.
Betrachtet man EPK-Schemata echter betrieblicher Abläufe in der Praxis, sind Splits (einschließlich Iterationen) oft nicht tief verschachtelt, sondern werden häufig ohne viele weitere Verschachtelungen durch entsprechende Joins geschlossen bzw. treffen auf Endereignisse. Stellt man die rein praktische Überlegung an, dass die hier betrachteten betriebliche Abläufe letztlich von Menschen verstanden, geplant, (zumindest teilweise) umgesetzt, verwaltet und verantwortet werden müssen, so ist diese Eigenart nachvollziehbar, und es ist daher auch anzunehmen, dass reale betriebliche Abläufe nicht beliebig komplex werden. Aus dieser Überlegung kann man auf eine nicht exponentielle Zunahme von N+T bei grossen betrieblichen EPK-Schemata ausgehen. Weiterhin kann auch durch die mehrfach vorgeschlagene hierarchische Modellierung betrieblicher Abläufe (z.B. [KM94; Sc00]), bzw. durch die nachträgliche hierarchische Interpretation der Abläufe (z.B. mittels „blocking“ [ST07]), dem Problem der tief verschachtelten Modellteile und damit des exponentiell wachsenden Prüfaufwands begegnet werden. Unter diesen Annahmen für reale EPK-Schemata wäre die Standard-BFS als Grundlage der vorgeschlagenen Methode praktikabel.
Zusätzlich muss die Komplexität der vorgeschlagenen Methode noch hinsichtlich ihrer BFS Erweiterungen, der Behandlung von Iterationen und (nicht-disjunktiven) Konnektoren, eingeschränkt werden – soweit das ihrem letztlichen Ziel, der Erzeugung von Testszenarien für funktionale Systemtests auf Anwenderseite, nicht schädlich ist. Die folgende Analyse hinsichtlich der szenario-orientierten Prüfungsmöglichkeiten in EPK-Schemata führt zu solchen begründeten Relaxationsannahmen.
Sei n > 1 die Anzahl der ausgehenden Kontrollflusskanten eines Split, dann vermehrt (nur) ein Split die Anzahl der möglichen verzweigungsfreien Abläufe auf einem Weg im Schema. Bei einem Join wird zunächst der entsprechende Split bestimmt (wobei u.a. gefordert ist, dass Split und Join vom selben Konnektortyp sind), dann werden alle linearen Szenarien für das Split-Join-Paar gebildet. Deren Anzahl hängt vom Konnektortyp ab, wie Tabellen 4 und 5 zeigen.
Split-Join-Typ Die linke Spalte in Tabelle 4 nennt den Typ des Split-Join-Paares, die linke Seite der rechten Spalte die Anzahl der Abläufe bei vollständiger linearer Expansion, und die rechte Seite der rechten Spalte die Anzahl der Abläufe bei relaxierter linearer Expansion. Für AND bedeutet die Relaxation die Nichtberücksichtigung der unterschiedlichen Ausführungsreihenfolgen (Permutationen). Für XOR erscheint eine Relaxation für die spätere Bildung von Testszenarien nicht sinnvoll.
Für OR wird zunächst festgestellt, dass es gleichbedeutend mittels XOR gefolgt von AND modelliert werden kann. Damit ergibt sich eine Abhängigkeit der OR Relaxation von der Behandlung des AND. Die Anzahl der Szenarien ist in Tabelle 5 dargestellt. Bei vollständig expandiertem AND ergeben sich mit ebenso vollständig expandiertem OR alle Variationen der hypergeometrischen Verteilung; mit relaxiertem OR werden in ⎛ n ⎞ ⎛ n ⎞ der vorgeschlagenen Methode nur die beiden „Randfälle“ ⎜⎜ ⎟⎟ und ⎜⎜ ⎟⎟ behandelt. Bei ⎝ 1 ⎠ ⎝ n ⎠ ergeben sich mit vollständig expandiertem OR relaxiertem AND ⎛ n ⎞ ⎛ n ⎞ ⎛ n ⎞ ⎝⎜⎜ 1 ⎟⎠⎟ + ⎜⎜⎝ 2 ⎟⎟⎠ + K + ⎝⎜⎜ n ⎠⎟⎟ = 2 n −1 Szenarien, und mit ebenfalls relaxiertem OR entsprechend ⎛ n ⎞ ⎛ n ⎞ der vorgeschlagenen Methode nur ⎜⎜⎝ 1 ⎟⎠⎟ + ⎝⎜⎜ n ⎠⎟⎟ = n +1 Szenarien.
Split-Join OR AND vollständig
Anzahl der Abläufe im Split-Join-Paar OR vollständig OR relaxiert
n ⎛ n ⎞ #L(n, OR) = ∑ k!⎜⎜ ⎟
⎟ k =1 ⎝ k ⎠ AND relaxiert #L(n, OR) = 2n-1 #LR(n, OR) = n! + 1 #LR(n, OR) = n + 1
Tabelle 5: Anzahl der Szenarien in Split-Join-Paaren OR Für Iterationen wird davon ausgegangen, dass die funktionale Prüfung mit keinem, einem oder n > 1 Durchläufen erfolgt, wobei n = 2 gesetzt werden kann (in Anlehnung z.B. an [Ri97]). Die Iteration wird also bei „oben geprüfter Schleife“ nicht berücksichtigt und expandiert ansonsten in zwei verzweigungsfreie Szenarien.
Bei gleichzeitiger Relaxation von AND und OR und bei der Relaxation von Iterationen scheint also, unter den getroffenen Annahmen zur Ermittlung von Testszenarien, die Komplexität der vorgeschlagenen Methode für reale EPK-Schemata praktikabel.
Die hier vorgeschlagene Methode ist als Erweiterung der Open-Source Initiative „EPC Tools“ [CK05] auf der Eclipse Java IDE implementiert. Der Algorithmus liest in seiner ersten Phase eine EPK ein und konvertiert sie in eine Datenstruktur für Graphen; es wird dabei das EPK Austauschformat EPML [MN06] („EPC Markup Language“) unterstützt. In seiner zweiten Phase durchläuft der Algorithmus diese Datenstruktur und expandiert alle Verzweigungen und Iterationen entsprechend der beschriebenen Methode in einzelne verzweigungsfreie Wege. Die Implementierung ist in der Lage, zwischen gewähltem Start- und Endknoten korrekte EPKs zu linearisieren. Die implementierten Relaxations-Parameter für die Behandlung von Schleifen, AND und OR Konnektoren erlauben es, das Verhalten des Algorithmus einzustellen. Die folgenden drei Parameter sind implementiert: Iterativer Relaxations-Parameter: über diesen Parameter kann die Anzahl der zu testenden Iterationen in den Zyklen des EPK-Schemas eingestellt werden. Sinnvolle Werte sind 0 (nur bei „oben geprüften Schleifen“), 1 und 2.
Konjunktiver Relaxations-Parameter: ist dieser Parameter gesetzt, so werden Split-JoinPaare vom Typ AND zu einem einzigen Szenario, mit einer beliebigen Ablaufreihenfolge (Permutation) der parallel zu bearbeitenden Abläufe, expandiert; andernfalls werden n! Szenarien expandiert, jeweils ein Szenario für jede mögliche Reihenfolge. Adjunktiver Relaxations-Parameter: ist dieser Parameter gesetzt, so werden für n > 2 nur wie beschrieben die beiden „Randsituationen“ expandiert, andernfalls werden alle 2n-1 möglichen Kombinationen expandiert. Dabei hängt die Behandlung der konjunktiven Teilkombinationen jeweils vom konjunktiven Relaxations-Parameter ab, es wird also je nachdem entweder nur ein Szenario mit beliebiger Reihenfolge gebildet, oder faktoriell alle kombinatorisch möglichen Szenarien.
Abbildung 6: Erweiterung der Open-Source Initiative „EPC-Tools“ [CK05] Die Implementierung ist weder instrumentiert noch auf Laufzeit oder Speicherbedarf optimiert. Unter Verwendung der Relaxations-Parameter wurden mit dieser Implementierung – neben kleineren funktionsprüfenden Beispielen – verschiedene EPKSchemata aus betrieblichen Referenzmodellen auf einem Standard-PC ohne wahrnehmbare Laufzeit linearisiert.
Da Start- und Endknoten eines Linearisierungslaufs im Schema frei gewählt werden können, können auch verzweigungsfreie Szenarien unterschiedlicher Auflösung in unterschiedlichen Teilen des Schemas durch entsprechende Anpassung der ParameterEinstellungen für den jeweiligen Lauf erzeugt werden. Beispielsweise kann ein kleiner Teilprozess, in dem die Ausführungsreihenfolge der parallel modellierten Schritte als kritisch für den späteren Test angesehen wird, mit einem Linearisierungslauf unter eingeschalteter AND Kombinatorik analysiert werden.
In diesem Beitrag wurde eine Methode vorgeschlagen, mit der unter bestimmten Annahmen zur praktischen Handhabbarkeit alle verzweigungsfreien Wege durch ein korrektes EPK-Schema betrieblicher Abläufe extrahiert werden können. Zur Methode wurde ein entsprechendes Werkzeug als Eclipse-Plugin Erweiterung der Open-Source Initiative „EPC-Tools“ implementiert.
Diese verzweigungsfreien Wege können nach bestimmten Kriterien priorisiert werden um so die wichtigsten, geschäftskritischen Abläufe zu identifizieren. Diese können dann – mit unabhängigen Orakeln versehen – als Grundlage für lineare Positivtest-Szenarien („sunshine paths“) zum funktionalen Black-Box Systemtest im komponenten- und serviceorientierten Entwicklungsparadigma verwendet werden.
Vorteile ergeben sich erstens durch die Möglichkeit, alle zu testenden Abläufe zu kennen und sie damit bewusst priorisieren zu können, sowie zweitens durch die Möglichkeit, Testorakel aufzustellen, die vom Entwicklungsprozess auf Herstellerseite unabhängig sind. Dadurch wird die Definition aussagefähiger Testmetriken auch bei „higher order“ Tests auf Domänenebene möglich.
Literaturverzeichnis [Aa99] [Aa+03] [AH02] [Be95] [BL02] [Bo81] [Br00] [Br+05]