Verwandte Themen
An verschiedenen Stellen gibt es Unterschiede zwischen den Vorgaben der in Innovator umgesetzten Standards und deren Implementierung im Innovator-Datenmodell in der Art, dass einige Konstrukte gar nicht, andere in abweichender Form zur Verfügung stehen.
An verschiedenen Stellen gibt es Unterschiede zwischen den Vorgaben des UML-2-Metamodells und deren Implementierung im Innovator-Datenmodell in der Art, dass einige Konstrukte gar nicht, andere in abweichender Form zur Verfügung stehen.
Folgende Konstrukte der "UML 2.2 Superstructure" stehen in Innovator for Software Architects nicht zur Verfügung:
Folgende Konstrukte der UML-2-Spezifikation werden in Innovator for Software Architects in abweichender Form unterstützt:
Auch die Metaklasse selbst bekommt ein Stereotyp, das in diesem Fall identisch mit dem Namen der Metaklasse ist.
Ein Stereotyp kann gleichzeitig von beliebig vielen anderen Stereotypen erben. Dieses Stereotyp wird statt einer Liste von Stereotypen dem Modellelement zugewiesen.
In UML 2 kann jede beliebige Metaklasse stereotypisiert werden, also theoretisch auch abstrakte Metaklassen. Da die abstrakten Metaklassen im Konfigurationseditor nicht sichtbar sind, können in Innovator nur nichtabstrakte Metaklassen stereotypisiert werden.
Zur Formulierung von Einschränkungen (well-formedness rules) benutzt UML 2 die Syntax der Object Constraint Language (OCL). In Innovator können einschränkende Regeln ausschließlich über Einschränkungen für ausgewählte Beziehungsrollen des UML-2-Metamodells formuliert werden, da OCL von Innovator derzeit nicht unterstützt wird.
Ein Profilimport ist in Innovator nur auf den Hierarchieebenen "Systemmodell" und "Modell" möglich und nicht auf jeglicher Art von Paket.
UML 2 definiert "Modell" als Spezialisierung von Paket und "systemModel" als Standardstereotyp für ein Modell. Nach UML 2 wäre es z.B. zulässig, dass Modelle in Modellen geschachtelt werden. In Innovator sind Systemmodell und Modell als die beiden obersten Ebenen einer Modellstruktur fest vorgegeben, ein weiteres Unterteilen eines Modells in Teilmodelle mit individuellen Profilimporten ist nicht möglich.
Während in der UML-2-Spezifikation erst für bestimmte Unterklassen der gerichteten Beziehung die Multiplizität der "source"- und "target"-Rollen von "1..*" auf "1" wechselt, gilt im Innovator die Multiplizität "1" für jegliche Art von gerichteten Beziehungen. An der gleichen Stelle werden in der UML die "source"- und die "ownedElement"-Rolle aufeinander gelegt (über die Einschränkung {subsets source, ownedElement}), während in Innovator diese beiden Rollen für alle Arten von gerichteten Beziehungen identisch sind.
Verschiedene Arten von Pseudozuständen in Zustandsautomaten und Kombinierten Fragmente in Interaktionen haben in der UML 2 jeweils nur eine einzige Metaklasse und werden durch einen aufgezählten Wert ("TypeKind") unterschieden, verschiedene Arten von Kontrollknoten in Aktivitäten haben dagegen eigene Metamodellklassen. In Innovator findet man durchgehend in allen Verhaltensmodellen eigene Metaklassen für die genannten Konstrukte.
Die "ownedElement"-Beziehung zwischen einem verhaltensspezifischen Classifier und seinem Verhalten ist in der UML 2 optional. Da ein Verhalten selbst ein Classifier ist, kann die UML 2 durchaus so interpretiert werden, dass ein Verhalten direkt einem Paket zugeordnet werden kann. Innovator verlangt dagegen immer einen verhaltensspezifischen Classifier als Besitzer eines Verhaltens.
Nach UML sind u.a. verhaltensspezifische Classifier (BehavioredClassifier, also Klasse, Anwendungsfall, Kollaboration, Komponente oder Knoten/Gerät/Ausführungsumgebung) als Besitzer von Triggern möglich. Aus Gründen einer besseren Versionierbarkeit wird in Innovator-Modellen auf diese Möglichkeit verzichtet, so dass Trigger immer den jeweiligen Elementen des Aktivitätsdiagramms bzw. Zustandsautomaten zugeordnet werden müssen.
In der UML-2-Spezifikation gibt es eine komplexe Hierarchie von spezialisierten Metaklassen unterhalb der abstrakten Metaklasse "ValueSpecification", mit denen Ausdrücke bis in atomare Literale zerlegt werden können. Diese Konstrukte werden von Innovator nicht unterstützt – die einzige Metaklasse, die in diesem Bereich zur Verfügung steht, entspricht der UML-2-Metaklasse "OpaqueExpression" und erlaubt das Erfassen einer einzelnen, nicht weiter strukturierbaren Zeichenkette in einer anzugebenden Sprache.
Strukturdiagramme sind in Innovator-Modellen ebenfalls stereotypisierbar, obwohl sie keine Modellelemente im Sinne der UML sind. Der Stereotypmechanismus wird hier verwendet, um die erlaubten Inhalte eines Diagramms definieren zu können.
Ein Vergleich zwischen IMM und Innovator for Database Architects ist nur eingeschränkt möglich, da die OMG-Spezifikation nicht endgültig vorliegt. Der Vergleich muss sich daher auf diejenigen Teile der Spezifikation beschränken, für die bereits eine hinreichend genaue Spezifikation vorgelegt wurde.
Innovator for Database Architects unterstützt aus diesem Grund bislang nur die Bereiche "Entity/Relationship Modeling" (IMM, Vol. 2, Kap. 4) und "Relational Modeling" (IMM, Vol. 3, Kap. 1).
Folgende Konstrukte der IMM-Spezifikation stehen in Innovator for Database Architects daher nicht zur Verfügung:
Verwandte Themen
© 1986-2014 MID GmbH Nürnberg Deutschland. DIN EN 9001 zertifiziert. Alle Rechte vorbehalten.