Spezifikationsmodule - Software and Systems Engineering - TUM
Spezifikationsmodule - Software and Systems Engineering - TUM
Spezifikationsmodule - Software and Systems Engineering - TUM
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
es mindestens einen Term geben, der die Vereinigung der beiden Selektoren erzwingt.<br />
Wir müssen nur noch die Selektorindizes innerhalb ihres definierenden<br />
Konstruktors und die Vereinigung ihrer Ergebnistypen in der DataDef-Relation<br />
prüfen, falls die Typen nicht identisch sind.<br />
5.3 Alternative Interaktionsabläufe<br />
Die Auswahl der einzelnen Schritte der Dialogführung ist so getroffen worden,<br />
dass sie eine möglichst breite Palette von Entscheidungsvarianten und ODL<br />
Techniken präsentiert. Der vorgestellte Ablauf stellt keinesfalls den einzig möglichen<br />
oder gar den passendsten dar. Welche Variante zum Einsatz kommt, muss<br />
im Kontext des konkreten Anwendungsszenarios und des Entwicklungsprozesses<br />
festgelegt werden.<br />
Abhängig von den Anforderungen des Einsatzgebietes und den Entwicklern<br />
muss jeweils im konkreten Fall die passende Variante der Spezifikationsunifikation<br />
ermittelt werden. Wir geben hier nur eine Übersicht, welche Aspekte einer<br />
Prüfung unterzogen werden müssen.<br />
Die ersten beiden Fragen, die abgewogen werden müssen, sind der Grad der<br />
Interaktion, d.h. welche Elemente interaktiv und welche automatisch nach bestimmten<br />
Regeln und Verfahren unifziert werden, und die Reihenfolge, in der die<br />
Einzeldialoge zur Bearbeitung angeboten werden. Wir können zum Beispiel die<br />
Entscheidungen in Bezug auf die Datensicht nach vorne ziehen und diese nach<br />
der Schnittstellenunifikation interaktiv durch den Nutzer durchführen lassen.<br />
Als Folge würden die Entscheidungen über die Unifikation von Zuständen und<br />
Transitionen durch die dann bereits festgelegte Datensicht beschränkt werden.<br />
Zu Demonstrationszwecken wählten wir hier jedoch die automatisierte Variante<br />
für die Datentypdefinitionen.<br />
Wie bereits angesprochen, gibt es im Bereich der Datentypdefinitionen unterschiedliche<br />
Varianten die Konstruktoren und Selektoren zu vereinigen, insbesondere<br />
wenn wir die entsprechenden Unifikationsrelationen automatisch berechnen<br />
wollen. Neben dieser Betrachtung ist auch Einbeziehung der Frage, inwieweit<br />
Selektoren in den Termen auftreten, wichtig, da bei einfachen Komponenten<br />
häufig auch nur einfache Datentypen (also nur parameterlose Konstruktoren)<br />
auftreten. Dies hat zur Folge, dass die Selektorunifikation nicht mehr notwendig<br />
ist und der Gesamtablauf somit beschleunigt werden kann. Die Beantwortung<br />
dieser Frage kann aber nur im konkreten Entwicklungsumfeld erfolgen.<br />
Neben der Reihenfolge der Einzelschritte der Dialogführung können auch<br />
<strong>and</strong>ere Definitionen der Unifikationsrelation zum Einsatz kommen, wie wir in<br />
Abschnitt 4.2 gesehen haben. Entsprechende Anpassungen in der Dialogführung<br />
und den Einzeldialogen, sowie dem Konstruktionsteil, sind hierfür notwendig,<br />
was wir hier nur anmerken wollen.<br />
Es sei noch einmal hervorgehoben, dass ein konkreter Interaktionsablauf an<br />
einen Entwicklungsprozess angepasst werden muss. Wir konzentrieren uns hier<br />
auf die Darstellung der derzeitigen Fähigkeiten und Möglichkeiten von ODL,<br />
noch nicht jedoch mit der Evaluierung in einem spezifischen Entwicklungsprozess.<br />
47