Spezifikationsmodule - Software and Systems Engineering - TUM

im Wesentlichen makePorts() entspricht.
define copyPorts(
new_comp:Component,
new_copy_port_map:set(orig:Port,copy:Port)
) as (
forall mk_prt:new_copy_port_map . (
result has Ports(new_comp, mk_prt.copy) and
result has Name(mk_prt.copy, mk_prt.orig.Name) and
exists mk_nd:new Direction . (
result has Direction(mk_prt.copy, mk_nd) and
result has IsEntry(mk_nd, mk_prt.orig.Direction.IsEntry)
) and
exists mk_prt_mt:new MIFType . (
result has DefinedType(mk_prt.copy, mk_prt_mt) and
result has Model(mk_prt_mt, mk_prt.orig.DefinedType.Model)
))) .
5.6 Zusammenfassung
In diesem Kapitel haben wir einen möglichen interaktiven Ablauf der Spezifikationvereinigung
illustriert und in ODL umgesetzt. Unser Ziel war die Darstellung
der Fähigkeiten von ODL zur Definition interaktiver Modelltransformationen.
Für solch komplexe Transformationen gibt es meist mehrere alternative
Dialogführungen und Dialogformen, sodass eine genaue Betrachtung im jeweils
konkreten Fall notwendig ist.
Wir haben die Spezifikationsunifikation in zwei wesentliche Teile gegliedert.
Der analytische Teil lieferte interaktiv oder, wie im Falle der Datentypen und der
Termunifikation, automatisch berechnete Datenstrukturen für die Unifikationsrelationen.
Wir haben auf die Darstellung der Berechnung für nicht-unifzierte
Elemente, d.h. Elemente, die in die erzeugte Spezifikation nur einkopiert werden
müssen, verzichtet. Der Leser sei hierfür auf den Programmtext in Anhang A
verwiesen.
Diese vom Nutzer eingegebenen oder berechneten Daten bilden, so sie konsistent
sind, die Grundlage für den konstruktiven Teil. Er erzeugt die vereinigte
Komponente. Wir haben gesehen, dass beide Teile aufeinander abgestimmt sein
müssen, wobei die Forderung der Ein-Eindeutigkeit hier wesentliche Vereinfachungen
gebracht hat. Unsere Darstellungen begrenzten wir auf die Vorführung
der wichtigsten Teile. Das vollständige Programm findet sich in Anhang A.
57