Spezifikationsmodule - Software and Systems Engineering - TUM

stateMap ∈ P( State × State )
transitionMap ∈ P( T ransitionSegment × T ransitionSegment )
inputMap ∈ P( Input × Input )
outputMap ∈ P( Output × Output )
datadefMap ∈ P( DataDef × DataDef )
constructorMap ∈ P( Constructor × Constructor )
selectorMap ∈ P( Selector × Selector )
Wählen wir für jede Unifikationsrelation eine konkrete Instanz, so bildet
das Tupel dieser Instanzen einen Unifikator, wenn es die in Abschnitt 4.3 beschriebenen
Abhängigkeiten erfüllt. Der Unifikator bildet die Grundlage für den
zweiten Schritt der Spezifikationsvereinigung, die Konstruktion, die wir in Kapitel
5 weiter ausführen. Die Relationen geben dabei an, aus welchen bestehenden
Modellelementen die neu erzeugten Modellelemente entstehen.
Ein einfacher Unifikator ist das Tupel der Identitätsrelationen. Jedes Modellelement
würde hierbei mit sich selbst vereinigt, was bei der konstrutiven
Durchführung eine Kopie des Produktmodells erzeugt. Wählten wir für jede Unifikationsrelation
hingegen jeweils die leere Relation, so würde das AutoFocus 2-
Produktmodell überhaupt nicht verändert. In beiden Fällen handelt es sich also
um in der Theorie korrekte Lösungen bzw. Unifikatoren, welche mit ODL auch
technisch umsetzbar sind, aber keine praktische Relevanz haben.
4.2 Unifikationsrelationen
Die im letzten Abschnitt eingeführten Unifikationsrelationen können im Hinblick
auf die Konstruktion einer Vereinigungsspezifikation unterschiedlich interpretiert
werden. Im Einzelfall bieten sich alternative Definitionen für die Unifikation
der betrachteten Modellelemente an. Wir werden beides hier anhand
von Beispielen sehen und am Ende dieses Abschnitts eine Festlegung für die
konstruktive Durchführung der Spezifikationsvereinigung in Kapitel 5 treffen.
4.2.1 Alternative Relationsdefinition
Am Beispiel der Automatenbeschreibungen wollen wir aufzeigen, dass es auch
möglich ist andere Definitionen für die Unifikationsrelationen zu verwenden.
Abbildung 4.1 zeigt eine andere Vereinigung der Spezifikationen des Verhaltens
unserer Beispielkomponenten. Wir vereinigen jetzt zwei Zustände der Komponente
ErrorTreatment mit einem Zustand der Komponente Press, nämlich
Init und Stop mit Off.
Hierfür definieren wir die Unifikationsrelation, wie folgt, über den Potenzmengen
der Modellelementmengen:
stateMap ∈ P ( P(State) × P(State) )
Die dem Beispiel entsprechende konkrete Unifikationsrelation hat dann folgende
Form:
{ ({Initial, ) }
stateMap = Stop}, {Off}
33