Einschränkungen und Abweichungen gegenüber Spezifikationen

Innovator for Software Architects vs. UML 2

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:

• Aus dem Abschnitt "Classes" (Kap. 7) fehlen GeneralizationSet, alle Spezialisierungen von ValueSpecification mit Ausnahme von OpaqueExpression, PackageMerge
• Aus dem Abschnitt "Actions" (Kap. 11) fehlen einige Actions des Compliance Level L3: ReadExtent-Aktion, ReclassifyObject-Aktion, ReadIsClassifiedObject-Aktion, StartClassifierBehavior-Aktion, ReadLinkObjectEndAction, ReadLinkObjectEndQualifier-Aktion, CreateLinkObject-Aktion, Reduce-Aktion, ReadVariable-Aktion, AddVariableValue-Aktion, RemoveVariableValue-Aktion, ClearVariableValue-Aktion
• Aus dem Abschnitt "Activities" (Kap. 12) fehlen Clause und die Strukturierten Aktivitätsknoten (ConditionalNode, LoopNode und SequenceNode)
• Aus dem Abschnitt "Common Behaviors" (Kap. 13) fehlen DurationInterval, DurationObservation, TimeInterval, TimeObservation
• Aus dem Abschnitt "Interactions" (Kap. 14) fehlen die Diagrammtypen Kommunikations-, Interaktionsübersichts- und Zeitdiagramm
• Aus dem Abschnitt "Auxiliary Constructs" (Kap. 17) fehlen die Elemente des Unterkapitels 17.2 (InformationFlows)
• Aus dem Abschnitt "Profiles" (Kap. 18) fehlt das Strukturdiagramm "Profile Diagram"

Folgende Konstrukte der UML-2-Spezifikation werden in Innovator for Software Architects in abweichender Form unterstützt:

• UML 2 erlaubt, einem Modellelement beliebig viele Stereotype zuzuweisen, auch 0 Stereotype ist hier möglich. In Innovator hat ein Modellelement dagegen immer genau ein Stereotyp. Die Konformität zum Standard wird über zwei Mechanismen sichergestellt:

  • 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.

Innovator for Information Architects vs. IMM

Ein Vergleich zwischen IMM und Innovator for Information 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 Information 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 Information Architects daher nicht zur Verfügung:

• Business Nomenclature (IMM, Vol. 2, Kap. 1)
• Information Visualization (IMM, Vol. 2, Kap. 2)
• OLAP Metamodel (IMM, Vol. 2, Kap. 3)
• XML Schema Metamodel (IMM, Vol. 3, Kap. 2)
• Lightweight Directory Access Metamodel (IMM, Vol. 3, Kap. 3)
• Multidimensional Metamodel (IMM, Vol. 3, Kap. 4)
• Record Metamodel (IMM, Vol. 3, Kap. 5)
• Model Management (IMM, Vol. 3, Kap. 6)
• OO Database Metamodel (IMM, Vol. 3, Kap. 7)
• Transformation Metamodel (IMM, Vol. 3, Kap. 8)