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.
1. Es werden zwei neue Komponenten erzeugt, wobei die erste durch Vereinigung<br />
von CompA und CompB, die zweite durch Vereinigung von CompB<br />
und CompC entsteht.<br />
2. Vom Konstruktionsverfahren könnte genauso erwartet werden, dass die<br />
angegebene Relation unvollständig ist und zunächst mittels der Bildung<br />
der transitiven Hülle vervollständigt werden muss. Somit könnte obige<br />
Relation also auch dafür stehen, dass nur eine neue Komponente erzeugt<br />
wird, die aus der Vereinigung von CompA, CompB und CompC entsteht.<br />
Dieser Fall entspricht der vorher erläuterten alternativen Möglichkeit mit<br />
Potenzmengen zu arbeiten.<br />
In Kapitel 5 verwenden wir die zusätzliche Bedingung, dass Unifikationsrelationen<br />
partielle, ein-eindeutige Funktionen sein müssen. Auch wenn dadurch die<br />
in Abbildung 4.1 gezeigte Spezifikationsvereinigung nicht mehr möglich ist, denn<br />
jeder Zust<strong>and</strong> der ersten Komponente kann nur mit höchstens einem Zust<strong>and</strong><br />
der zweiten Komponente unifiziert werden und vice versa. Diese Vereinfachung<br />
ist aus Gründen der Verständlichkeit der ODL-Ausdrücke zur Definition der<br />
Unifikationsrelationen und der Generierungsausdrücke notwendig.<br />
4.3 Abhängigkeiten der Modellelemente<br />
Die Assoziationen und Beziehungen der Modellelemente, wie sie durch das Metamodell<br />
festgelegt werden, haben auch eine Bedeutung in Bezug auf das Vereinigungsproblem.<br />
Sie stellen genau die Abhängigkeiten der Modellelemente dar, die<br />
bei der Unifikation beachtet werden müssen. Abbildung 4.2 zeigt den Abhängigkeitsgraphen,<br />
der sich aus dem Metamodell ergibt. Die gerichteten Kanten lassen<br />
sich hierbei nach ihrem Verlauf in interne Abhängigkeiten (Kanten mit gleichem<br />
Start- und Zielknoten) und externe Abhängigkeiten (Kanten mit verschiedenen<br />
Start- und Zielknoten) einteilen.<br />
4.3.1 Interne Abhängigkeiten<br />
Wir sprechen von einer (unifikationsrelations-)internen Abhängigkeit, wenn die<br />
zwei zu unifizierenden Modellelemente bezüglich eines Attributwerts gleich sein<br />
müssen, damit die Unifikation aus semantischer Sicht sinnvoll ist. Solche Abhängigkeiten<br />
beziehen sich auf eine einzelne Modellelementklasse. In Abbildung<br />
4.2 sind sie als gestrichelte Kanten eingezeichnet.<br />
Eine interne Abhängigkeit ist ein Prädikat, dass von allen Tupeln einer Unifikationsrelation<br />
erfüllt werden muss und insbesondere nicht von <strong>and</strong>eren Unifikationsrelationen<br />
abhängt. Im Abhängigkeitsgraph sind dies reflexive Kanten.<br />
Solche Prädikate haben folgende Grundstruktur (one ist das erste, two das zweite<br />
Element der Tupel in u):<br />
∀u ∈ UnifRel : u.one.SomeAttribute = u.two.SomeAttribute<br />
Im Beispiel ist dies bei der Unifikationsrelation von Port der Fall. Es können<br />
nur solche Ports mitein<strong>and</strong>er unifiziert werden, die die gleiche Richtung aufweisen,<br />
d.h. in Bezug auf das Direction-Attribut äquivalent sind. Die Unifikation<br />
eines Eingabeports mit einem Ausgabeport ist syntaktisch möglich, denn beide<br />
35