Domänenspezifische Sprachen und UML-Profile

Transkript

1 Domänenspezifische Sprachen und UML-Profile Udo Kelter Zusammenfassung dieses Lehrmoduls Eine domänenspezifische Sprache (domain-specific language, DSL) ist eine formale Sprache, die speziell für ein bestimmtes Problemfeld (eine Domäne) entworfen und implementiert wurde. Eine gängige Methode zur Entwicklung von DSL besteht darin, eine vorhandene Sprache zu modifizieren. Die UML unterstützt diese Methode zur Entwicklung von DSL durch Profile. Dieses Lehrmodul gibt eine informelle Einführung in DSLs und Profile. Vorausgesetzte Lehrmodule: obligatorisch: Modellgetriebene Software-Entwicklung Metadaten empfohlen: Die Unified Modelling Language (UML) Version 2 Stoffumfang in Vorlesungsdoppelstunden: 0.7 1

2 Domänenspezifische Sprachen und UML-Profile 2 Inhaltsverzeichnis 1 Domänenspezifische Sprachen Charakterisierung Syntax Semantik DSLs vs. Systemfamilien DSLs vs. Modellierungssprachen UML-Profile Einordnung Exkurs: UML-Pakete Paketimport Paketverschmelzung Anforderungen an Profile Aufbau und Inhalt von Profilen Profile als Pakete Stereotypen Graphische Anzeige von erweiterten Klassen Instanzbildung Literatur Index Dieser Text darf für nichtkommerzielle Nutzungen als Ganzes und unverändert in elektronischer oder gedruckter Form beliebig weitergegeben werden und in WWW-Seiten, CDs und Datenbanken aufgenommen werden. Jede andere Nutzung, insb. die Veränderung und Überführung in andere Formate, bedarf der expliziten Genehmigung. Die jeweils aktuellste Version ist über erreichbar.

3 Domänenspezifische Sprachen und UML-Profile 3 1 Domänenspezifische Sprachen 1.1 Charakterisierung Eine domänenspezifische Sprache (domain-specific language, DSL) ist eine formale Sprache, die speziell für ein bestimmtes Problemfeld (eine Domäne) entworfen und implementiert wurde. Es gibt sehr viele, oft sehr alte DSLs: LaTeX, HTML, Postscript usw. sind Sprachen, mit denen die Inhalte von anzuzeigenden Seiten beschrieben bzw. programmiert werden können. Die Eingabesprachen von Generierungssystemen wie make, ant usw. sind Sprachen, mit denen Softwaresysteme generiert werden können. SQL und andere Datenbankabfragesprachen sind DSLs, mit denen man Inhalte aus Datenbanken extrahieren kann. Die Formeln, mit denen man in Spreadsheets Zelleninhalte berechnen kann, sind eine DSL. Das Format, in den Steuerdaten für Modelltransformatoren spezifiziert werden, ist eine DSL. Viele komplexe Systeme haben umfangreiche Einstellungs- und Konfigurationsoptionen. Die konkreten Einstellungen werden in einer Ressourcen -Datei als Text gespeichert. Die Sprache. in der diese Texte formuliert sind, ist ebenfalls eine DSL. DSLs sind insofern ganz normale (Rechner-) Sprachen als sie eine formale Syntax und eine Semantik haben und daß es Übersetzer oder Interpreter gibt, die Programme in diesen Sprachen ausführen können. Der Unterschied zu allgemeinen Programmiersprachen liegt im Bezug auf die spezielle Domäne: Programmiersprachen können beliebige Algorithmen ausdrücken und beinhalten keine domänenspezifischen Begriffe. Im Gegensatz dazu bezieht sich die Bedeutung von DSLs (also von Programmen, die in einer DSL geschrieben sind) immer auf Konzepte der Applikationsdomäne.

4 Domänenspezifische Sprachen und UML-Profile 4 Beispielsweise ist in dem SQL-Kommando select count(*) from kunden natural join lieferungen implizit klar, daß kunden und lieferungen Tabellen sind, ohne daß diese Konzepte (bzw. Datentypen) explizit definiert worden sind. La- TeX und andere Formatierungssprachen beinhalten dagegen Konzepte wie Fettschrift, Zeilenabstand oder Seitenvorschub. Ein typisches Merkmal von DSLs ist, daß sie außerhalb ihrer Domäne unbrauchbar sind. In vielen DSLs kann man keine allgemeinen Algorithmen und Datentypen implementieren, von daher ist diese Beschränktheit hart. Selbst wenn eine DSL ausnahmsweise algorithmisch vollständig ist, ist es i.d.r. unpraktisch, sie außerhalb ihrer Domäne einzusetzen. Stilistisch sind DSLs i.d.r. deklarativ, d.h. es werden in der jeweiligen Syntax in erster Linie Sachverhalte notiert, keine Algorithmen, Schleifen, temporären Variablen o.ä. Es wird sozusagen das Problem spezifiziert, der Sprachprozessor findet den kompletten zugehörigen Lösungsweg vollautomatisch, was nur aufgrund der eingeschränkten Problemdomäne möglich ist. 1.2 Syntax Die meisten DSLs, vor allem ältere, haben eine textuelle Syntax. Neue DSLs haben oft eine graphische Syntax. Darüber hinaus sind aber auch tabellarische oder sonstige Darstellungen auf beliebigen Ausgabemedien denkbar. Die Art der Syntax ist nicht entscheidend dafür, ob eine Sprache eine DSL ist oder nicht. Nichtsdestotrotz haben graphische Sprachen Vorteile: DSLs sollen häufig von Fachleuten aus der Domäne verstanden und benutzt werden, die mit einer gut gestalteten graphischen Sprache meist besser zurechtkommen. Wesentlich für eine gute Benutzbarkeit einer DSL ist aber nicht nur die Syntax, sondern die Klarheit und Eignung der gewählten Begriffe und Funktionen, die oft als semantisches Modell bezeichnet werden.

5 Domänenspezifische Sprachen und UML-Profile 5 Nutzung von Basissprachen. Die Syntax einer DSL kann natürlich völlig neu und unabhängig definiert werden; dementsprechend sind alle Parser, Übersetzer, Prüfwerkzeuge usw. komplett neu zu implementieren. Um diesen hohen Aufwand zu reduzieren, werden viele DSLs aufbauend auf einer schon existierende Basissprache definiert. Beispiele: 1. XML als Basissprache: Die konkrete DSL entsteht, indem passende Elementtypen definiert werden. Hier spart man die Entwicklung eigener Scanner und Parser und kann viele XML-Werkzeuge gewinnbringend einsetzen. Für manche Nutzer ist allerdings das direkte Editieren von XML- Dateien eine unüberwindliche Hürde. 2. eine gängige Programmiersprache als Basissprache, z.b. Java: hierzu sind passende Datentypen und Operationen (also Bibliotheken), die wiederkehrende Funktionalitäten der Domäne implementieren, geschickt zu definieren, so daß im Endeffekt ein Programm in der DSL zusammen mit den vordefinierten Datentypen und Operationen ein korrektes und ausführbares Programm wird. Im Endeffekt werden 2 Effekte ausgenutzt: (a) durch die Bibliotheken wird der Sprachumfang der Gastsprache erweitert; (b) die Nutzung der Gastsprache wird stark eingeschränkt, nämlich i.w. auf die Nutzung der Bibliotheken. 3. eine vorhandene Modellierungssprache als Basissprache, z.b. die UML: i.w. analog zum Vorstehenden; Beispiele sind mehrere UMLbasierte DSLs, z.b. MARTE oder SysML. 1.3 Semantik Der Semantik-Begriff konventioneller Sprachen unterstellt, daß man Programm ausführen kann und dabei Effekte in Ausgabemedien, Datenbanken usw. entstehen. Bei DSLs ist nicht immer klar, ob man in ihnen geschriebene Texte ( Programme ) überhaupt ausführen will.

6 Domänenspezifische Sprachen und UML-Profile 6 Ein Beispiel ist die BNF (Backus-Naur-Form), die man als DSL zur Spezifikation von Grammatiken auffassen kann. Man kann aus BNF-Texten z.b. Teile von Compilern, Syntaxeditoren u.a. Werkzeugen ableiten. Die so abgeleiteten Programmfragmente haben Effekte, insofern wird die BNF ausführbar. Man kann die BNF-Texte aber auch nur dazu benutzen, Grammatiken zu spezifizieren, und es völlig offen lassen, ob irgendwann daraus irgendwelche Softwarekomponenten generiert werden. Bei ausführbaren DSLs ist die semantische Domäne, auf die sich die DSL bezieht, typischerweise eng umrissen. Daher brauchen sehr viele Eigenschaften der spezifizierten Systeme nicht explizit formuliert zu werden, sie sind implizit vorgegeben. Die Programmtexte können (und sollen) sich auf die noch verbleibende Freiräume konzentrieren. Hieraus folgt die hohe Ausdruckskraft von DSLs; mit DSLs kann ein System daher mit weitaus weniger Programmtext als bei einer Allzwecksprache realisiert werden. Dies ist die Hauptursache dafür, daß Entwickler bei Nutzung von DSLs wesentlich produktiver sind als bei Allzwecksprachen. 1.4 DSLs vs. Systemfamilien DSLs weisen viele Gemeinsamkeiten mit Systemfamilien (bzw. Produktlinien) auf: die entscheidende Gemeinsamkeit ist die Konzentration auf eine abgegrenzte semantische Domäne und eine zugehörige Klasse von Systemen. Dies ist die Basis für eine einheitliche Systemarchitektur und einheitliche Begriffsrahmen. Insofern kann man Programme in einer DSL oft als Steuerdaten eines Generators verstehen, mit dem Mitglieder einer Systemfamilie generiert werden können. Umgekehrt kann man die Sprachen, in denen die Steuerdaten von Generatoren formuliert werden, fast immer als DSL ansehen. Ein Unterschied zwischen DSLs und Systemfamilien liegt darin, daß Systemfamilien ein allgemeineres Konzept von Bindungszeitpunkten und entsprechenden Methoden zu Spezifikation von Varianten haben und Generierungsprozesse wesentlich komplexer sein können.

7 Domänenspezifische Sprachen und UML-Profile 7 So gesehen unterstellt eine DSL eine simple Generierungsstruktur: es gibt nur einen einzigen Variationspunkt - die Erstellung des DSL- Programms - und nur einen einzigen Generierungs- bzw. Interpretationsschritt. 1.5 DSLs vs. Modellierungssprachen Systemspezifikationen in einer DSL und einer Modellierungssprache haben gemeinsam, daß sie ein System in sehr kompakter Form und daher frei von vielen Implementierungsdetails darstellen. Allerdings sind übliche Allzweck-Modellierungssprachen wie die UML kaum in der Lage, die präzise Semantik eines Systems auszudrücken, bzw. wenn man dies versuchen würde, würden sehr große und unübersichtliche Modelle entstehen, die alle gemeinsamen Merkmale der Domäne implementieren; hiervon abstrahiert eine DSL gerade. 2 UML-Profile 2.1 Einordnung Wie schon oben erwähnt liegt es nahe, DSLs unter Nutzung einer Basissprache zu spezifizieren und implementieren. Die UML unterstützt diesen Ansatz, indem sie in der Infrastructure-Spezifikation [UML10I] einen Mechanismus namens Profile definiert 1, durch den beliebige Modellierungssprachen, die auf Basis von [UML10I] definiert sind, als Basissprache einer DSL genutzt werden können. Das Hauptziel ist, spezialisierte (domänenspezifische) Modellierungs-Sprachen auf Basis der UML mit wenig Aufwand realisieren zu können, dafür ist man weniger flexibel als bei einer völlig freien Definition von DSL. Wie schon oben am Beispiel von textuellen Programmiersprachen erläutert wird die Basissprache in zweierlei Weise modifiziert: 1 Dieser Mechanismus wird auch noch einmat identisch in der Superstructure- Spezifikation [UML10S], Kap. 18, definiert.

8 Domänenspezifische Sprachen und UML-Profile 8 (a) Einschränkung der benutzbaren Standardkonstrukte (b) Erweiterung einer vorhandenen Sprache (hier der UML) Die Rolle von Paketen für UML-Profile. Der Kerngedanke, eine DSL durch Wiederverwendung einer Basissprache zu realisieren, wird durch Einsatz des Paketkonzepts wesentlich unterstützt. Pakete sind ein Standardkonzept der UML, das zunächst die Gruppierung von Modellelementen und lokale Namensräume unterstützt. Die Gesamtmenge der Modellelementtypen der UML ist gruppiert in eine Vielzahl von Paketen. Hinsichtlich der Spezifikation von DSLs bietet dies den Vorteil, nicht die komplette UML als Basis übernehmen zu müssen, sondern eine passende Auswahl von Paketen. D.h. man kann eine DSL zunächst grob durch eine Auswahl an vorhandenen Paketen konfigurieren. Für das Verständnis von UML-Profilen spielen UML-Pakete und deren Beziehungstypen daher eine herausragende Rolle, weswegen letztere in folgenden Abschnitt genauer erläutert werden. 2.2 Exkurs: UML-Pakete Pakete können, wie auch in Programmiersprachen üblich, innere Pakete enthalten, d.h. die Namensräume werden geschachtelt. Alle Definitionen in einem äußeren Paket sind in den inneren Paketen mit unqualifizierten Namen nutzbar. Zwischen Paketen bestehen über die Schachtelung hinaus zwei Arten von Beziehungen, die das Zusammenwirken mehrerer Pakete definieren: der Paketimport und die Paketverschmelzung. Vor allem letztere ist für die technische Realisierung von Profilen wesentlich Paketimport Ein Paketimport ist eine gerichtete Beziehung zwischen zwei Paketen (s. [UML10I], PackageImport), die graphisch als gestrichelte Linie mit offenen Pfeilspitze dargestellt wird. Modellelemente des importierten Pakets können im importierenden Paket mit ihrem einfachen

9 Domänenspezifische Sprachen und UML-Profile 9 Namen verwendet werden. Es gibt zwei Varianten des Paketimports: öffentlicher Paketimport: Hier werden die importierten Modellelemente weiterexportiert; an der gestrichelten Linie wird das Schlüsselwort import notiert. privater Paketimport: Hier sind die importierten Modellelemente nur innerhalb des importierenden Pakets nutzbar; an der gestrichelten Linie wird das Schlüsselwort access notiert. Der Effekt besteht in beiden Fällen darin, daß alle Modellelemente des importierten Pakets einzeln importiert werden, sofern nicht für ein Modellelement schon eine explizite einzelne Import-Beziehung spezifiziert ist. Ein importiertes Modellelement überdeckt einen ggf. vorhandene Namen von einem äußeren Paket. Weitere Details s. [UML10I], Paketverschmelzung Eine Paketverschmelzung (PackageMerge) ist ebenfalls eine gerichtete Beziehung zwischen zwei Paketen. Graphisch wird sie wie ein Paketimport als gestrichelte Linie mit offenen Pfeilspitze dargestellt, als Schlüsselwort wird merge an der gestrichelte Linie notiert. Für die beiden involvierten Pakete benutzen wir die folgenden Bezeichnungen: hinzugemischtes Paket (merged package): Ziel des Pfeils zu erweiterndes Paket (receiving package): das Paket, von dem der Pfeil ausgeht. Eine gewisse Ähnlichkeit zu einem Import besteht darin, daß die Inhalte des hinzugemischten Pakets im zu erweiternden Paket verfügbar werden. Im Gegensatz zu einem Import geht man bei einer Verschmelzung davon aus, daß für jedes Element im hinzugemischten Paket ein Element mit gleichem Namen und i.w. gleichen Typ im zu erweiternden Paket vorhanden ist. Der Effekt der Verschmelzung besteht i.w. darin, ein resultierendes Paket (resulting package) zu erzeugen, das sozusagen nur virtuell vorhanden ist. Das resultierende Paket enthält in erster Näherung die

10 Domänenspezifische Sprachen und UML-Profile 10 Vereinigung der Modellelemente der beiden Pakete. Sofern ein Name in beiden Paketen definiert ist, werden die Merkmale dieser beiden Modellelemente vereinigt. Hierbei ist eine Vielzahl von Konsistenzregeln und Restriktionen zu beachten, Details s. [UML10I], PackageMerge. Wenn eine dieser Regeln verletzt ist, ist das Paketdiagramm, in dem die merge-beziehung auftritt, ungültig. Das resultierende Paket wird in Paketdiagrammen (oder anderen Diagrammen, in denen Pakete auftreten) bzw. im Modell durch das gleiche Objekt repräsentiert wie das zu erweiternde Paket, was manchmal verwirrend ist (s. [UML10I], Figure Conceptual view of the package merge semantics). Wenn z.b. Paket P2 zu erweiterndes Paket ist und Paket P1 das hinzugemischte Paket und wenn ferner Paket P3 das Paket P2 importiert, dann importiert P3 das resultierende Paket (und nicht etwa das wörtlich vorhandene zu erweiternde Paket); s. [UML10I], Figure Der komplette Verschmelzungsvorgang ist komplex und auf S in [UML10I], Abschnitt dargestellt. Wesentlich ist hier, daß das resultierende Paket stets kompatibel zu dem zu erweiternden Paket ist, also auch dort verwendet werden kann, wo bisher das zu erweiternde Paket alleine verwendet wurde. 2.3 Anforderungen an Profile Der Spezifikation des Profile-Mechanismus lagen diverse Anforderungen zugrunde 2, die zugleich Hinweise auf die intendierte Verwendung liefern. Besonders relevant für die Handhabung und Nutzung von Profilen sind die folgenden Anforderungen: 1. Es soll möglich sein, ein Referenzmodell durch ein Profil weiter einzuschränken und zu konkretisieren. Typischerweise verschärft das Profil Konsistenzbedingungen des Referenzmodells. 2 s. Kap. 13 Core::Profiles in [UML10I], S

11 Domänenspezifische Sprachen und UML-Profile Die Einschränkungen sollen für einzelne Modellelemente anwendbar sein, aber auch für alle Modellelemente eines Typs. Beispiel: das Profil Java model könnte Typhierarchien auf einfaches Erben einschränken, ohne das Stereotyp Java class bei jeder einzelnen Klasse eines Klassendiagramms notieren zu müssen. 3. Profile sollen nachträglich auf ein Modell anwendbar bzw. wieder rückziehbar sein. 4. Es können mehrere Profile auf ein Modell angewendet werden, d.h. Profile können kombiniert werden. 5. Profile müssen zusammen mit den Referenzmodellen zwischen Werkzeugen austauschbar und in Standard-XMI-Formaten darstellbar sein. D.h. ein Profil muß syntaktisch ein Modell sein. 6. Bereits lokal vorhandene Profile sollen referenziert werden können (und nicht dauernd erneut übertragen werden müssen). 2.4 Aufbau und Inhalt von Profilen Profile als Pakete Profile sind formell gesehen Pakete. Ein Profil bezieht sich auf ein oder mehrere andere Pakete, die als Referenzmodell bezeichnet werden. Die Modellelemente des Referenzmodell werden als Paketimport in das Profil importiert und können dort einzeln erweitert werden. Ein Profil kann auf die Pakete seines Referenzmodells angewandt werden. Durch Anwendung des Profils ändert das Referenzmodell seine Bedeutung. Repräsentiert wird die Anwendung von Profilen durch eine (Meta-) Assoziation profileapplication: Diese geht von einem (M1-) Modell aus und verweist auf ein (M2-) Metamodell 3. 3 Eine Bewertung dieses Sachverhalts geht über die Ziele dieses Skripts hinaus. Eine unmittelbare Konsequenz ist, daß ein Modellierungswerkzeug, das konform zum Infrastructure-Dokument ist, auch Laufzeitrepräsentationen der Metamodelc 2011 Udo Kelter Stand:

12 Domänenspezifische Sprachen und UML-Profile 12 Da Profile Pakete sind, können Profile auch auf Profile angewandt werden Stereotypen Ein Profil besteht i.w. aus Stereotypen. Ein Stereotyp (s. [UML10I], Stereotype) sieht syntaktisch i.w. genauso aus wie eine Metaklasse, also ein Modellelementtyp, kann aber nicht autark instantiiert werden, sondern nur normale Modellelementtypen erweitern. Den Effekt dieser Erweiterung kann man sich für den Anfang durch einen Vergleich mit einer Subtypbildung veranschaulichen: Wenn U eine Unterklasse von der Oberklasse O ist, dann haben die Instanzen von U im Vergleich zu Instanzen von O zusätzliche Attribute, sind also durch die speziellen Attribute von U erweitert. Wenn man also eine Instanz der Metaklasse, die U repräsentiert, bildet, reicht die dort lokal vorhandene Information nicht aus; stattdessen müssen alle direkten und indirekten Oberklassen von U gesucht und bei der Instanzbildung berücksichtigt werden. Bei Erzeugen von Objekten muß man explizit angeben, ob man nur eine Instanz der Oberklasse haben will oder eine erweiterte Instanz, eben eine Instanz der Unterklasse. Ein Stereotyp, das eine vorhandene Metaklasse erweitert, hat einen ähnlichen Effekt wie eine Unterklasse: die vorhandene Metaklasse spielt die Rolle der Oberklasse O, und es werden erweiterte Instanzen angelegt, die die zusätzlichen Attribute haben, die das Stereotyp spezifiziert. Im Unterschied zur individuellen Subtypbildung werden im Kontext einer DSL typischerweise alle Instanzen von O erweitert. Oft darf es nicht möglich sein, eine unerweiterte Instanz der Oberklasse zu bilden. le vorhalten muß, also wesentliche Elemente einer Interpreterarchitektur aufweisen muß.

13 Domänenspezifische Sprachen und UML-Profile 13 Die Verantwortung für diese Kontrollen wird in [UML10I] allerdings auf die Editoren 4 verlagert. Wenn man in einem Editor also eine Instanz derjenigen Metaklasse, die O repräsentiert, erzeugt, müssen die Metamodelle nach Stereotypen, die diese Metaklasse erweitern, durchsucht und bei der Instanzbildung berücksichtigt werden. Der Profilmechanismus stellt nur die Informationen über die Erweiterungen bereit, er ist selber kein Datenverwaltungssystem. In den vorstehenden Erläuterungen war nur von zusätzlichen Attributen die Rede, genauso können aber auch zusätzliche Beziehungstypen und Rolleneigenschaften hinzukommen, ferner OCL-Bedingungen, durch die die zulässigen Instanzen eingeschränkt werden Graphische Anzeige von erweiterten Klassen Bei der klassischen Subtypbildung werden an einer Instanz des Subtyps die geerbten und die speziellen Attribute völlig gleich behandelt und auch - z.b. in Objektdiagrammen - ununterscheidbar dargestellt. Ferner ist der Name des Subtyps explizit dargestellt, also eindeutig erkennbar, daß es sich nicht um eine unerweiterte Instanz des Obertyps handelt. Bei Stereotypen ist dies anders: Hier kann man zunächst nur der Name der erweiterten Klasse angegeben; um die Erweiterungen erkennbar zu machen, werden die angewandten Stereotypen - es können i.a. mehrere sein - in Guillemets zusätzlich angezeigt. Hierzu gibt es viele Präsentationsvarianten 5, u.a. Pictogramme, auf die wir aus Platzgründen nicht eingehen. Die erweiternden Attribute werden anders dargestellt als die normalen Attribute, und zwar i.d.r. in einem Kommentar, der mit dem erweiterten Objekt verbunden ist, darin als Name-Wert-Paare: :namestring: = :valuestring: Beispiel: s. MARTE Tutorial, Part 1, Folie 22 und 24. Auch hier gibt es viele Präsentationsvarianten. 4 bzw. alle Applikationen, die Instanzen erzeugen. 5 s. [UML10I], S.199, Presentation Options.

14 Domänenspezifische Sprachen und UML-Profile Instanzbildung Die Instanzbildung ist bei Stereotypen deutlich komplizierter als bei der Subtypbildung. Gedacht sind Stereotypen natürlich vor allem dazu, Metaklassen zu erweitern. Metaklassen sind Teil von Metamodellen, diese wiederum sind reine Datenmodelle. Eine Metaklasse spezifiziert also zusammen mit andern Teilen des Metamodells einen Modellelementtyp. Die Bildung von Instanzen zu den Typdefinitionen ist eigentlich, wenn man das Geheimnisprinzip anwenden würde, eine Implementierungsentscheidung von Werkzeugen bzw. Repositories, welche die Instanzen erzeugen bzw. verwalten. Indes sind für die Integration parallel laufender Werkzeuge standardisierte Laufzeitrepräsentationen dieser Daten erforderlich, ebenso persistente Darstellungen für den Dokumenttransport und -Austausch. Für die Bildung der Instanzen hat ferner die obige 3. Anforderung, Profile nachträglich auf ein Modell anwenden bzw. wieder entfernen zu können, wesentliche Auswirkungen. Im Endeffekt ist es am sinnvollsten, die Stereotypen - die formell Metaklassen sind - wie eine ganz normale Metaklasse zu instantiieren. M.a.W. würden also ein Modellelement, dessen Typ durch eine normale Metaklasse gegeben ist und das n angewandte Stereotype hat, durch 1 + n geeignet verbundene Laufzeitobjekte repräsentiert werden. Literatur [UML10I] Unified Modeling Language: Infrastructure, Version 2.3; OMG, Doc. formal/ ; 2010 [UML10S] Unified Modeling Language: Superstructure, Version 2.3; OMG, Doc. formal/ ; 2010 [UML06D] Diagram Interchange, Version 1.0; OMG, Doc. formal/ ; 2006 [UML10O] Object Constraint Language, Version 2.2; OMG, Doc. formal/ ; 2010