Das Transaktionsprinzip hat sich im Datenbankbereich bew"ahrt,da nur wenige Daten angefa"st werden und die kontrollierten Arbeitseinheiten klein sind, also die Verweilzeit im System kurz ist. Jedoch lassen sich langlebige Abl"aufe (Workflows) auf einem Computersystem mit dem klassischen Transaktionsmodell nicht verwirklichen. Beispielsweise ist eine strikte alles-oder-nichts Semantik bei Vorg"angen, die Tage, Monate oder Jahre dauern, nicht akzeptabel. Bei einem Fehlerfall sollten nicht alle bisher ausgef"uhrten Aktivitäten zur"uckgenommen werden, vielmehr sollte eine anwendungsspezifische Fehlerbehandlung durchgef"uhrt werden (Kompensation), die den bisherigen Arbeitsfortschritt ber"ucksichtigt und nach der die Ausf"uhrung fortgesetzt werden kann. Das ConTract Modell ist ein "erweitertes" Transaktionsmodell zur zuverlässigen Abarbeitung von langlebigen, verteilten Abl"aufen. Die Konzepte des ConTract Modells werden in einer prototypischen Implementierung (APRICOTS) an der Universit"at Stuttgart umgesetzt. Die Programmierung solcher Abl"aufe kann nur durch eine grafische Programmierumgebung sinnvoll unterst"utzt werden. Neben der eigentlichen Definition des Kontroll- und Datenflusses eines Ablaufs spielen spezifische Eigenschaften der Elemente eines ConTracts eine tragende Rolle. Beispielsweise besitzen Steps (die auszuf"uhrenden Aktivit"aten innerhalb eines Ablaufs) unterschiedliche Parameter, die Variablen des Ablaufs zugeordnet werden m"ussen. Dies trifft ebenso f"ur Transaktionen und Kontrollflu"skonstrukte zu. Ziel dieser Arbeit ist es, Dialoge f"ur die Zuordnung von Eigenschaften zu Elementen eines ConTracts zu entwerfen und in den graphischen Editor zu integrieren. Dazu m"ussen die einzelnen Elemente eines ConTracts analysiert werden, d.h. die Eigenschaften (Struktur) der einzelnen ConTract-Elemente, die ein Skriptprogrammierer zuweisen kann, und die Relationen zwischen einzelnen Elementen m"ussen festgelegt werden. Nach der Analyse eines ConTracts folgt der Entwurf von Dialogen zur Eingabe von Eigenschaften der einzelnen ConTract-Elemente. F"ur jede Eigenschaft bzw. Eigenschaftsklasse m"ussen passende Interaktionsformen er"ortert und ausgew"ahlt werden. Dabei sollen allgemeine Richtlinien zur Dialoggestaltung auf einem Computersystem ber"ucksichtigt werden. Ebenso wie im Falle der Definition des Kontrollflusses mu"s daf"ur Sorge getragen werden, da"s die Korrektheit der Eigenschaften bereits durch die Dialoge selbst "uberpr"uft wird. Beispielsweise mu"s "uberpr"uft werden, ob ein Step, der in den Ablauf aufgenommen wird, auch definiert ist. Weiterhin soll darauf geachtet werden, da"s die Kommunikation mit weiteren Werkzeugen m"oglich ist (Schnittstellen zu weiteren Komponenten) und Erweiterungen der Eigenschaften von Elementen einfach aufgenommen werden k"onnen. Neben der Korrektheit bei der Eingabe der Eigenschaften soll die Konsistenz der Daten ebenfalls durch die Dialogkomponete gesichert werden. Beispielsweise sollten alle ung"ultigen Referenzen auf Elemente, die aus einem Skript gel"oscht wurden, invalidiert werden.