Heutige Unternehmen verwenden Workflow-Management-Systeme in zunehmendem Maße zur Modellierung und Abwicklung ihrer Geschäftsprozesse. Durch ihren Einsatz soll die Abwicklung der Geschäftsprozesse als Workflows effizienter und effektiver gestaltet werden. Mit der Verwendung eines Workflow-Management- Systems entsteht für das Unternehmen gleichzeitig auch eine weitreichende Abhängigkeit. Es ist darauf angewiesen, daß die Ausführung der Workflows durch das Workflow-Management-System stets zuverlässig und korrekt abgewickelt wird. Es muß gewährleistet sein, daß im Falle eines Fehlers während der Workflow- Ausführung keine Unternehmensdaten verfälscht oder verloren gehen. Das Workflow-Management-System muß somit in der Lage sein, auf Fehlersituationen angemessen zu reagieren und die Ausführung der unterbrochenen Workflows fortzusetzen. Die Fähigkeit, auf Fehler zu reagieren und sie zu beheben, um die Workflow-Ausführung fortzusetzen, besitzen auf dem Markt befindliche Workflow- Management-Systeme nicht oder nur unzureichend. Doch gerade bei lange andauernden Vorgängen wie beispielsweise Geschäftsprozessen, muß die Zuverlässigkeit der Ausführung sichergestellt sein. Im Bereich der Datenbanken hat sich das klassische Transaktionskonzept zur Modellierung von Abläufen bewährt. Es handelt sich dabei um sehr kurze Vorgänge, die im Fehlerfall vollständig zurückgesetzt werden. Zur Modellierung von lange andauernden Vorgängen wie beispielsweise Geschäftsprozessen eignet sich das Transaktionsmodell jedoch nur bedingt. Dies liegt an der strikten Einhaltung der Atomaritäts- und Isolationseigenschaft einer Transaktion. Die Atomarität einer Transaktion besagt, daß die Transaktion entweder vollständig oder gar nicht ausgeführt wird. Dies bedeutet, daß im Fehlerfall die gesamte Ausführung zurückgesetzt wird und alle bereits ermittelten Zwischenergebnisse verloren gehen. Für die Ausführung lange andauernder Vorgänge ist dieses nicht akzeptabel. Die Isolationseigenschaft einer Transaktion stellt sicher, daß die Ausführung einer Transaktion im logischen Einbenutzerbetrieb erfolgt. Bei lange andauernden Vorgängen hat dies zur Folge, daß sich durch konkurrierende Zugriffe auf gemeinsam genutzte Datenbestände Wartezeiten und Deadlocks ergeben, da die Daten für die gesamte Dauer der zugreifenden Transaktion gesperrt bleiben. Zur Ausführung von lange andauernden Vorgängen, wie beispielsweise Workflows, wird deshalb ein flexibleres Ausführungsmodell als das klassische Transaktionsmodell benötigt. Ein Beispiel hierfür ist das an der Universität Stuttgart entwickelte ConTract-Modell. Es handelt sich hierbei nicht um eine Erweiterung des klassischen Transaktionsmodells, sondern um ein zweistufiges Programmiermodell, das auf der Verwendung von ACID-Transaktionen aufbaut. Es ermöglicht die konsistente und fehlertolerante Ausführung einer Reihe von elementaren Bearbeitungsschritten (Steps) gemäß einer davon getrennt festgelegten Kontrollflußbeschreibung (Skript). Sofern die in einem Step ausgeführte Aktivität es ermöglicht, wird ein Step als ACID-Transaktion ausgeführt. Im Gegensatz zum klassischen Transaktionsmodell werden im ConTract-Modell auf Skript-Ebene die Atomarität und die Isoliertheit abgeschwächt. Dies ermöglicht einerseits das vorzeitige Externalisieren von Zwischenergebnissen, jedoch resultiert daraus, daß im Fall einer Ausnahme oder eines Fehlers das System nicht mehr in den exakten Zustand vor der Step-Ausführung zurückversetzt werden kann. Statt dessen kann das System durch die Ausführung weiterer Steps in einen Zustand überführt werden, der aus der Sicht der Anwendung semantisch äquivalent ist, oder die Ausführung des ConTract-Skriptes wird im Fall eines Fehlers nach geeigneter Fehlerbehandlung nach vorne fortgesetzt. Das Stornieren einer ConTract-Ausführung geschieht nur auf Anweisung einer Benutzerin oder eines Benutzers, beziehungsweise einer Anwendung. Besonders die Möglichkeit einer Fehlerbehandlung liefert einen wesentlichen Beitrag zur Sicherstellung der Fortsetzbarkeit eines ConTract. Die Fehlerbehandlung kann jedoch nicht jeden beliebigen Fehlerfall abdecken. Sollte auf Grund eines Fehlers die weitere Ausführung eines ConTract trotz durchgeführter Fehlerbehandlung nicht mehr möglich sein, so wird der Systemadministrator benachrichtigt. Er muß geeignete Maßnahmen ergreifen, um die Fehlerursache zu beseitigen und die Fortsetzung der ConTract-Ausführung ermöglichen. Liegt die Fehlerursache nicht am technischen Umfeld der ConTract-Ausführung, sondern an der ConTract-Definition, so muß das ConTract-Skript zur Laufzeit korrigiert werden können, um die Fortsetzbarkeit der ConTract-Ausführung zu ermöglichen. Diese Diplomarbeit untersucht die Voraussetzungen unter denen das ConTract-Skript geändert werden kann und welche Modifikationen zulässig sind, ohne die Konsistenz der ConTract-Ausführung zu gefährden. Am Institut für Parallele und Verteilte Höchstleistungsrechner (IPVR) der Universität Stuttgart wird mit APRICOTS eine prototypische Implementierung eines ConTract-verarbeitenden Systems durchgeführt, die speziell auf die Ausführung von Workflows ausgerichtet ist. Zur Unterstützung der Fortsetzbarkeit einer Workflow- Ausführung soll im Rahmen dieser Diplomarbeit - als ein Teil des APRICOT- Systems - ein Werkzeug mit graphischer Benutzungsoberfläche entwickelt werden, das die Modifikation von Workflows zur Laufzeit ermöglicht. Es soll die Benutzerin oder den Benutzer bei der Modifikation einer Workflow-Instanz unterstützen und gleichzeitig die Konsistenz der modifizierten Workflow-Instanz sicherstellen.