Metamodellbasierte und hierarchieorientierte ... - RosDok

5.1 Einführung 93
der Aufgaben ein integraler Bestandteil der Modelle. Zusätzlich ist an jeder Dekomposition einer Aufgabe
ein sogenannter Plan zu annotieren, der informell beschreibt, in welcher Reihenfolge die Unteraufgaben zu
erledigen sind. Diese informelle Angabe mit umgangssprachlichen Text repräsentiert die Kontrollflusskanten
in flussorientierten Modellierungssprachen. Informelle Texte beinhalten von Natur aus Mehrdeutigkeiten,
womit diese für eine Soundness-Analyse bzw. Workflow-artige, rechnergestützte Ausführung der HTA-
Modelle nicht ausreicht.
Weitere Aufgabenmodellierungsansätze sind mit Goals Operations Methods Structure (GOMS) [Kie03]
und Task Knowledge Structure (TKS) [JJ91] gefolgt. Diese werden ebenfalls nur zur konzeptionellen
Modellierung verwendet und sind nicht dafür vorgesehen, ausgeführt zu werden.
Die Sprache ConcurTaskTree (CTT) [Pat99] hat sich als populärste Aufgabenmodellierungssprache etabliert.
Diese wird vornehmlich im Zusammenhang mit der User Interface-Modellierung eingesetzt. Die
ConcurTaskTrees haben die Angabe des Kontrollflusses für Aufgabenmodelle eher formalisiert (s. Abschnitt
5.2.2), für eine Workflowausführung sind aber auch diese Modelle noch zu informell. Zum einen fehlt eine
Veröffentlichung zur formale Fundierung, nach der eine eindeutige Abarbeitung bei allen Operatoren und
deren Kombinationen definiert ist. Zum anderen liefert das Referenzwerkzeug ConcurTaskTree Environment
(CTTE) [MPS02] zwar eine Umgebung zur Simulation der Modelle, dort entstehen aber schnell Probleme
wie Dead- bzw. Lifelocks, die während der Modellierung nicht immer automatisch erkannt werden. Eine
Formalisierung, die eine Soundness-Überprüfung zur Designtime erlaubt, ist hier notwendig, um Aufgabenmodelle
zur Workflowausführung zu nutzen. Abschnitt 5.3 präsentiert einen präzisen metamodellbasierten
Ansatz für den Zweck, Konsistenzeigenschaften von CTT-Modellen zu überprüfen.
Wendet man Aufgabenmodelle für Geschäftsprozesse an, muss man beachten, dass die Wurzelaufgabe
kein Nutzerziel verfolgt, sondern eher das Ziel des Unternehmens oder der Abteilung. Dieser Sachverhalt
ist im Kontrast zur nutzerzentrierten Aufgabenmodellierung zu sehen. Daraufhin wird das Ziel, wie in
Aufgabenmodellen üblich, in einer baumartigen Form dekomponiert. Hierbei ist eine grafische Integration
der Organisationsmodellierung durch Pools bzw. Swimlanes, so wie sie bei BPMN vorhanden ist, nicht
vorgesehen. Stattdessen können Cooperative ConcurTaskTrees (CCTT) eingesetzt werden, um kooperierende
Tätigkeiten zu modellieren [MPS02]. Dafür wird für jede beim Geschäftsprozess beteiligte Rolle
bzw. Person ein Aufgabenbaum zugeordnet. Die Koordination der unterschiedlichen Aufgaben wird dann
in einem separaten, koordinierenden Aufgabenbaum angegeben. In diesem wird im Wurzelknoten das
gemeinschaftliche Ziel modelliert, das nicht einer Person sondern der Organisationseinheit zuzuordnen ist.
Hierarchische Modelle, die mehrere Abstraktionsebenen in einem Modell darstellen, haben neben der
integrierten Zielmodellierung einen weiteren Vorteil gegenüber imperativen Sprachen. Es kann eine „depthfirst“-Modellierung
verfolgt werden im Gegensatz zu nicht hierarchischen Modellen, die eine „breadthfirst“-Modellierung
erzwingen. Omerod hat festgestellt, dass diese Herangehensweise Vorteile bei der
Modellierung aus folgenden Gründen haben kann [OR99]. Kritische Probleme und wiederum spezielle
Unterprobleme können beispielsweise durch Dekomposition als erstes genauer betrachtet werden. Dadurch
kann man zur Erkenntnis gelangen, dass das Problem so nicht gelöst werden kann und ein anderes Handlungsmodell
erforderlich ist. Es kann somit die Erstellung des Problemlösungsmodells abgeborchen und
ein neues begonnen werden. Hätte man hier eine „breadth-first“-Modellierung verfolgt wäre deutlich mehr
Arbeit zur Modellierung vonnöten gewesen, bis man zu dieser Erkenntnis gekommen wäre.
Strukturiertheit ist des Weiteren ein wichtiger Aspekt sowohl in der Programmierung als auch zunehmend in
der Modellierung. Dijkstra hat Ende der 1960er Jahre erkannt, das goto-Anweisungen in Computerprogrammen
zu komplizierten, nicht nachvollziehbaren Programmen führen [Dij68]. So wie goto-Anweisungen bei
komplexen Programmen nicht nachvollziehbar sind, können flussorientierte Prozessmodellierungssprachen
ebenfalls zu solchen unverständlichen Prozessmodellen führen. In [FL11] wurde die kognitive Komplexität