Spezi˝kation von Visual OCL: Eine Visualisierung der Object Constraint Language · 2005. 3. 4. · Sie stellt verschiedene Diagrammarten zur Darstellung bzw. De˝nition von Strukturen

Spezifikation von Visual OCL:

Eine Visualisierung der Object Constraint Language

Jessica Winkelmann

Diplomarbeit am Fachbereich Informatik der Technischen Universität Berlin

Februar 2005

2

Inhaltsverzeichnis

1 Einleitung 7

2 Grundlagen 9

2.1 MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 UML Diagrammarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Kurze Einführung in UML Klassendiagramme . . . . . . . . . . . . . . . . . . . 10

2.3 OCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.1 Kurze Einführung in OCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Visuelle Sprachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5 MOF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.5.1 Klassische Vier-Ebenen-Metadaten-Architektur . . . . . . . . . . . . . . . . . . 242.5.2 MOF Metadaten-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.5.3 Konzepte des MOF Modells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.6 Graphtransformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.6.1 Getypte attributierte Graphtransformation . . . . . . . . . . . . . . . . . . . . 292.6.2 Getypte attributierte Graphtransformation mit Knotentypvererbung . . . . . . 302.6.3 Transformation Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3 Beschreibung der VOCL 39

3.1 Visuelles OCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2 Allgemeine Darstellung eines Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3 Beispiel Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4 Attribute und Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.4.1 Zuweisung von Werten an Variablen . . . . . . . . . . . . . . . . . . . . . . . . 433.4.2 Werte vor der Ausführung einer Operation in der Nachbedingung . . . . . . . . 44

3.5 Navigationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.5.1 Navigation entlang einer Assoziation . . . . . . . . . . . . . . . . . . . . . . . . 453.5.2 Navigation zu Assoziationsklassen . . . . . . . . . . . . . . . . . . . . . . . . . 453.5.3 Navigation von Assoziationsklassen . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.6 Darstellung von Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.7 Vordefinierte Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.7.1 Eigenschaften von Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.7.2 Operationen mit komplexem Rückgabetyp . . . . . . . . . . . . . . . . . . . . . 533.7.3 Vordefinierte Operationen aus der OCL StandardLibrary . . . . . . . . . . . . . 533.7.4 Einfache Operationen auf Collections . . . . . . . . . . . . . . . . . . . . . . . . 53

3.8 Boolesche Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.8.1 Implies, Or und Xor Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.8.2 And Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.8.3 Not Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.9 Let Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.10 If-Then-Else Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.11 Komplexe Operationen auf Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3

4 INHALTSVERZEICHNIS

3.11.1 Mengenoperationen auf Collections . . . . . . . . . . . . . . . . . . . . . . . . . 613.11.2 LoopExpressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.11.3 Select und Reject Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.11.4 Collect Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.11.5 Forall Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.11.6 Exists Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.11.7 Sum Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.11.8 Iterate Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.12 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.13 Tupel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703.14 Komposition von Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4 Spezifikation von VOCL mit dem MOF Ansatz 75

4.1 Metamodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5 Spezifikation von VOCL mit Graphtransformation 93

5.1 Einfache UML Klassendiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.1.1 Typgraph für einfache UML Klassendiagramme . . . . . . . . . . . . . . . . . . 945.1.2 Syntaxgrammatik für einfache UML Klassendiagramme . . . . . . . . . . . . . 95

5.2 Typgraph von VOCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.3 Syntaxgrammatikregeln von VOCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.3.1 Definition des Kontextes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.3.2 Navigationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.3.3 VOCLExpressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

6 Vergleich 219

6.1 Metamodell <-> Typgraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2196.2 Constraints <-> Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

6.2.1 Kardinalitäts-Constraints <-> Regeln . . . . . . . . . . . . . . . . . . . . . . . 2206.2.2 sonstige Constraints <-> Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . 224

7 Schluss 243

7.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2437.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

A The VOCL Standard Library 247

A.1 OclAny and OclVoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247A.1.1 OclAny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247A.1.2 OclMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248A.1.3 OclVoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

A.2 ModelElement Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249A.2.1 OclModelElement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249A.2.2 OclType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249A.2.3 OclState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

A.3 Primitive Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251A.3.1 Real, Integer and String . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251A.3.2 Boolean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

A.4 Collection-Related Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252A.4.1 Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252A.4.2 Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254A.4.3 Bag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258A.4.4 Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

A.5 Predefined OclIterator Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

INHALTSVERZEICHNIS 5

A.5.1 Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266A.5.2 Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270A.5.3 Bag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272A.5.4 Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

6 INHALTSVERZEICHNIS

Kapitel 1

Einleitung

Modelle sind die Basis für Softwareentwicklung. D.h., von der Qualität eines Modells hängt die Qua-lität des modellierten Softwaresystems ab. Deshalb muss die Modellierung konsistent, gut, solide undverständlich sein. Eine Möglichkeit zur Erstellung solcher Modelle ist die Modellierung mit der UnifiedModeling Language (UML) in Verbindung mit der Object Constraint Language (OCL). Diese sindStandards der Object Management Group (OMG), wobei die OCL Spezifikation ein Bestandteil derUML Spezifikation ist.Die UML ist eine Modellierungssprache, mit der Softwaresysteme visualisiert, spezifiziert, dokumentiertund konstruiert werden können. Sie stellt verschiedene Diagrammarten zur Darstellung bzw. Definitionvon Strukturen und Abläufen in objektorientierten Softwaresystemen zu Verfügung.Leider sind UML Modelle allein häufig nicht genau genug, um alle relevanten Teile einer Modell-Spezifikation abzubilden. Es gibt Aspekte, die in UML nur umständlich oder überhaupt nicht ausge-drückt werden können. Eine umgangssprachliche Beschreibung von Einschränkungen und Bedingungen,die für ein Modell erfüllt sein müssen, kann zu Zweideutigkeiten in der Spezifikation führen. Diese wie-derum führen in der Regel zu einer inkorrekten Interpretation und Implementation des modelliertenSystems. Um diese Aspekte ausdrücken zu können, wurde die OCL entwickelt.Die OCL ist eine logische Sprache, die als Erweiterung der UML eingeführt wurde. Sie dient derFormulierung semantischer Restriktionen für UML Modellelemente und ist Teil des UML Standards.Mit OCL können Invarianten für Klassen und Typen im Klassenmodell oder Typinvarianten für Ste-reotypen, Vor- und Nachbedingungen für Operationen, Guards oder Aussagen über ein UML Modellspezifiziert werden. Leider ist die OCL im Gegensatz zur UML eine rein textuelle Sprache und bietetdaher eine vollkommen andere Notation von Modellelementen als die UML an.Obwohl die UML als Modellierungssprache eine sehr weit verbreitete Anwendung findet, wird die OCLwenig genutzt. Dafür gibt es sicherlich unterschiedliche Gründe, aber einer dürfte die Schwierigkeitder Anwendung einer textuellen Sprache innerhalb der visuellen Sprache UML sein. Die vollkommenandere Notation zwingt den Anwender eine weitere Sprache zu erlernen, die die UML Modellelementeanders darstellt.Insgesamt fällt das Verstehen eines Modells bzw. Modellausschnitts anscheinend leichter, wenn es ineiner grafischen anstelle einer textuellen Repräsentation vorliegt. Als empirischer Beleg dieser Annah-me mag gelten, dass Entwickler und Programmierer schon immer Abbildungen benutzt haben, um dieEigenschaften eines Modells darzustellen, auch bevor es dazu unterstützende Software gab. Zweidimen-sionale Abbildungen von Programmen (z.B. in Form von Kontrollflussgraphen) sind schon lange alswichtige Hilfe beim Programmverstehen bekannt.Ein weiterer Vorteil grafischer Darstellungen liegt in der Anzahl verfügbarer Ausdrucksmittel begrün-det. Eine textuelle Repräsentation besteht aus einzelnen Zeichen, die einem relativ kleinen Alphabetentstammen; für visuelle Repräsentationen stehen neben den horizontalen und vertikalen Koordinatenzusätzlich Form, Farbe, Größe, Füllmuster und Helligkeit zur Verfügung.Die visuelle OCL (VOCL) ist eine grafische Repräsentation der zuvor beschriebenen Sprache OCL. DieDefinition der VOCL verfolgt das Ziel, den beschriebenen Nachteil der rein textuellen Darstellung vonOCL Constraints zu beseitigen. Diese visuelle Notation von OCL wurde als Alternative für die textuelleNotation entwickelt. Der Vorteil, den die VOCL gegenüber der OCL hat, ist ihre visuelle Darstellung,

7

8 KAPITEL 1. EINLEITUNG

die viele Notationen der UML übernommen hat. Der Anwender kann zu einem UML Diagramm diezusätzlichen Restriktionen in der VOCL definieren und muss nicht eine völlig neue textuelle Sprache(die OCL) erlernen, um diese Bedingungen zu formulieren. Aus der großen Ähnlichkeit zu den UMLNotationen resultieren Vereinfachungen und ggf. eine direkte Einbindung in UML Diagramme. WieOCL ist die VOCL eine formale, streng typisierte und objektorientierte Sprache.Die Anwendung von UML und OCL soll durch die Definition einer Visualisierung von OCL vereinfachtwerden.Die VOCL ist also eine visuelle Sprache zur Beschreibung von OCL Constraints über UML Diagram-men.Im allgemeinen werden visuelle Modellierungssprachen in den frühen Phasen der Softwareentwicklungeingesetzt, um die Anforderungen an ein System festzulegen. Eine visuelle Sprache ist eine Spracheüber einem visuellen Alphabet, welches aus Symbolen und Relationen besteht. Die Symbole könnendabei sowohl bildliche als auch textuelle Bestandteile beinhalten.Obwohl visuelle Sprachen mittlerweile häufig verwendet werden, gibt es keinen Standard-Formalismusfür die Definition einer visuellen Sprache. Die abstrakte Syntax einer visuellen Sprache kann auf ver-schiedene Arten definiert werden. Die zwei Hauptansätze zur Definition einer visuellen Sprache sindder Metamodellierungs-Ansatz und der Graphgrammatik-Ansatz.Beim MOF Ansatz (einem Metamodellierungsansatz) werden Klassen und Assoziationen zur Definiti-on von Symbolen und Relationen verwendet. Zusätzlich sind bei dieser Definition Kardinalitäten undConstraints notwendig, um erforderliche Spracheigenschaften auszudrücken. Durch diese wird die Men-ge aller möglichen Symbole und Relationen auf die in dieser Sprache zulässigen eingeschränkt. Solcheconstraint-basierten Formalismen stellen einen deklarativen Ansatz zur Definition einer visuellen Spra-che dar. Der MOF Ansatz wird in Kapitel 4 genauer beschrieben.Zum konstruktiven Ansatz zählen Grammatiken, wobei sowohl textuelle als auch visuelle Grammati-kansätze zur Definition einer visuellen Sprache möglich sind. Graphgrammatiken sind visuelle Spezifi-kationsmechanismen zur Definition der abstrakten Syntax einer visuellen Sprache.Eine Graphgrammatik besteht aus einem Typgraphen und Grammatikregeln zur Erzeugnug von Ele-menten der Sprache. Graphen werden durch die Anwendung von Regeln in andere Graphen transfor-miert. Hierbei sind die Ausgangs- und Ergebnisgraphen Elemente einer bestimmten Graphsprache. EinGraph besteht aus Knoten und Kanten. Eine Regel hat eine linke und eine rechte Seite und beschreibt,wie in einem Graphen ein Teilgraph entfernt, durch einen anderen Teilgraphen ersetzt und dieser inden Restgraphen eingebettet wird.

Diese Arbeit besteht aus der Beschreibung der VOCL und der Definition der abstrakten Syntax derVOCL. Diese wird mit den beiden zuvor genannten Ansätzen zur Definition einer visuellen Spracheformal definiert, worauf ein kurzer Vergleich folgt.Die VOCL wird in Kapitel 3 anhand von zahlreichen Beispielen vorgestellt. Dieses Kapitel soll einemleichten Verständnis der grafischen Notationen der VOCL dienen. In Kapitel 4 wird die abstrakteSyntax von VOCL mit dem MOF Ansatz spezifiziert. Die Spezifikaion besteht aus dem Metamodell derVOCL und den Constraints, die in OCL geschrieben wurden. In Kapitel 5 folgt dann die Spezifikationder abstrakten Syntax mit dem Graphgrammatikansatz. Auch diese besteht aus zwei Teilen, demTypgraphen und den Grammatikregeln, mit denen die Sprachelemente erzeigt werden. Die Ausdrückeder VOCL sind allerdings so komplex, dass sie nicht mit einfachen Graphgrammatikregeln erzeugtwerden können. Es ist die Verwendung von Transformation Units nötig, die eine Menge von Regeln zueiner Einheit zusammenschließen, in der die Reihenfolge der Anwendung der Regeln festgelegt wird.Transfomration Units werden in Abschnitt 2.6.3 vorgestellt.

Kapitel 2

Grundlagen

Dieses Kapitel enthält die Grundlagen, die für die folgenden Kapiteln benötigt werden.In Abschnitt 2.3 wird eine kurze Einführung in die Object Constraint Language (OCL) gegeben.Die OCL steht mit anderen Standards (MDA und UML) der OMG (Object Management Group) inBeziehung, welche zu Beginn des Kapitels vorgestellt werden. Da die UML (bzw. die Klassendiagrammeder UML) in den folgenden Kapiteln verwendet werden, werden diese im Abschnitt 2.2.2 ausführlicherbeschrieben. OCL ist eine textuelle Sprache, die Visual OCL (VOCL), die in Kapitel 3 vorgestellt wird,ist eine grafische Repräsentation der OCL. Da sie also zu den visuellen Sprachen gehört, folgt eine kurzeErklärung des Begriffs visuelle Sprache. Dann werden die Grundlagen der verwendeten Ansätze zurDefinition der abstrakten Syntax von VOCL beschrieben. Abschnitt 2.5 beinhaltet einen Überblick überden MOF Standard, Abschnitt 2.6 die Grundlagen von getypter, attributierter Graphtransformationmit Knotentypvererbung sowie Transformation Units.

2.1 MDA

MDA ist ein Framework, das von der OMG zur Verfügung gestellt wird. Es definiert, wie Modelle, diein einer Sprache spezifiziert wurden, in Modelle anderer Sprachen transformiert werden können. EinBeispiel für eine solche Transformation ist die Generierung eines Datenbankschemas aus einem UMLModell, wobei die UML die Quell-Sprache und SQL die Ziel-Sprache ist. Ein anderes Beispiel ist dieCodegenerierung aus einem UML Modell (source code wird auch als Modell betrachtet).Hierbei soll die Beschreibung der Funktionalität eines Systems von der konkreten Umsetzung getrenntwerden.Folgt man der MDA, erstellt man zunächst ein plattformunabhängiges Modell (PIM) des Systems,wobei nur die Entwurfsaspekte betrachtet werden, die sich von Plattform zu Plattform nicht unter-scheiden.Dann wandelt man dieses Modell in ein plattformabhängiges Modell (PSM) um, indem es um dieplattformspezifischen Aspekte erweitert wird.Aus dem plattformspezifischen Modell kann lauffähiger Code erzeugt werden.Durch die Trennung der Entwurfsaspekte soll eine hohe Portabilität, Kompatibilität und gute Wie-derverwendbarkeit des entstandenen Modells erreicht werden. Aus einem PIM können viele PSMs fürverschiedene Plattformen generiert werden.Das Ziel von MDA ist, ein System einmal zu spezifizieren und dann “auf Knopfdruck“ lauffähige Sy-steme für unterschiedliche Plattformen zu erhalten.Um Wiederverwendbarkeit, Kompatibiltät und Portabilität zu erreichen, verwendet man zum Spezifi-zieren eine einheitliche, formale Sprache, die UML (und OCL). Damit soll erreicht werden, dass nichtnur verschiedene Menschen sondern auch verschiedene Werkzeuge das Modell verstehen.

2.2 UML

Die Unified Modeling Language (UML), ist eine von der OMG entwickelte und standardisierte Beschrei-bungssprache zur Darstellung von Strukturen und Abläufen in objektorientierten Programmsystemen.

9

10 KAPITEL 2. GRUNDLAGEN

Sie ist eine grafische Sprache zur Visualisierung, Spezifikation, Konstruktion und Dokumentation vonSoftwaresystemen.Im Sinne einer Sprache definiert die UML dabei Bezeichner für die meisten Begriffe, die im Rahmen derObjektorientierung entstanden sind und legt mögliche Beziehungen zwischen diesen Begriffen fest. DieUML definiert des weiteren grafische Notationsweisen für diese Begriffe und für Modelle von Softwareoder anderen Abläufen, die man in diesen Begriffen formulieren kann. Damit wurde die UML zur de-Facto-Norm für “technische Zeichnungen“ von Programmen und Abläufen. Sie standardisiert jedochnicht nur die technische Zeichnung selbst, sondern auch das Datenformat, in dem diese Zeichnung inEDV-Systemen abgelegt wird (sog. XMI, eine XML-Variante). Dadurch ermöglicht es die UML imPrinzip, Modellierungsdaten zwischen Modellierungswerkzeugen unterschiedlicher Softwareherstellerauszutauschen. Die UML stellt verschiedene Diagrammtypen (Struktur- und Verhaltensdiagramme)zur Verfügung, mit denen verschiedene Sichten auf ein Softwaresystem modelliert werden können. Sieist programmiersprachenunabhängig. Die UML ist durch ein Metamodell definiert, welches auf demOMG-Standard der MOF (Meta Object Facility) basiert.Da die UML in der kommerziellen Softwareentwicklung mittlerweile die wichtigste objektorientierteModellierungssprache ist, gibt es ein großes Angebot an CASE-Tools (Computer Aided Software En-gineering), die beim Erstellen von UML-Modellen helfen. Diese Werkzeuge können einerseits aus denDiagrammen Quelltexte generieren - darin liegt die besondere Leistungsfähigkeit von UML-Tools -, an-dererseits können sie vorhandenen Code einlesen und daraus die entsprechenden Diagramme erzeugen.Diese beiden Funktionalitäten erlauben Roundtrip-Engineering. Der Datenaustausch zwischen Werk-zeugen verschiedener Hersteller erfolgt über das Textformat XMI (XML Metadata Interchange).

2.2.1 UML Diagrammarten

Für die Darstellung verschiedener Sichten auf ein Modell werden in der UML die folgenden Diagram-marten angeboten:

Statische Sicht:

• Klassendiagramm (Class Diagram)

• Anwendungsfalldiagramm (Use Case Diagram)

Dynamische Sicht:

• Interaktiondiagramme (Interaction Diagrams):

– Kollaborationsdiagramm (Collaboration Diagram)

– Sequenzdiagramm (Sequence Diagram)

• Zustandsdiagramm (Statechart Diagram)

• Aktivitätsdiagramm (Activity Diagram)

Implementierungssicht:

• Komponentendiagramm (Component Diagram)

• Verteilungsdiagramm (Deployment Diagram)

Da in dieser Arbeit UML Klassendiagramme verwendet werden, wird diese Diagrammart der UML imfolgenden Abschnitt genauer beschrieben.

2.2.2 Kurze Einführung in UML Klassendiagramme

Mit UML Klassendiagrammen werden statische Beziehungen zwischen Klassen, aber auch zwischenPaketen und Objekten, dargestellt.

2.2. UML 11

Pakete

Pakete dienen der Strukturierung von Modellen. Jedes Modellelement gehört zu genau einem Paket.Pakete können miteinander in Beziehung stehen oder andere Pakete enthalten. Ein Paket wird alsRechteck mit einem kleineren Rechteck am linken oberen Rand notiert. Wenn keine anderen Model-lelemente im Paket eingetragen sind, wird der Paketname im großen, ansonsten im kleinen Rechteckplaziert.

Paketname

Abb. 2.1: UML Paket

Klassen und Objekte

Ein Objekt repräsentiert einen Gegenstand oder ein Konzept aus der Anwendungsdomäne (z.B. Kundeoder Konto etc.) und korespondiert meist mit einem realweltlichen Objekt oder Konzept. GleichartigeObjekte werden in Klassen zusammengefasst, wodurch von den spezifischen Eigenschaften einzelnerObjekte abstrahiert wird. Klassen sind das zentrale Modellierungselement der UML. Die gemeinsamenEigenschaften der Objekte werden als Attribute, Operationen (Methoden), Beziehungen und Semantikder Objekte dargestellt. Ein Objekt ist eine konkrete Ausprägung oder Instanz einer Klasse.Eine Klasse wird als Rechteck dargestellt, das in vier übereinander dargestellte Bereiche aufgeteiltist. Im oberen Bereich wird der Name der Klasse optional mit Stereotypen, Zusicherungen oderName/Werte-Paaren dargestellt. Vor dem Klassennamen kann der Paketname des übergeordneten Pa-kets mit zwei Doppelpunkten getrennt notiert werden. Die nächsten zwei Bereiche sind für die Attributeund Methoden. Den untersten Bereich kann der Modellierer beliebig füllen. Bleibt einer der Bereicheleer, kann er weggelassen werden.Objekte werden analog zu Klassen dargestellt, der Name des Objekts besteht aus dem Objektnamen(kleingeschrieben) und dem Klassennamen, getrennt durch einen Doppelpunkt, der Klassenname wirdunterstrichen.

Attribute und Methoden

Attribute stellen Datenelemente eines bestimmten Typs dar. Es gibt Instanzattribute (instance attri-butes) und Klassenattribute (class attribute). Erstere sind Eigenschaften der konkreten Instanzen einerKlasse, letztere gelten für die Klasse unabhängig von den Instanziierungen. Sie enthalten also Informa-tionen, die für alle Objekte gleich sind. Ein Attribut wird mit einem Namen, seinem Typ und einemoptionalen Initialwert beschrieben. Klassenattribute sind unterstrichen. Ein Attribut kann abgeleitet(derived) sein, dann wird sein Wert aus den Werten anderer Attribute des Objekts berechnet. Dieswird durch ein führendes \ -Zeichen vor dem Attribuntnamen ausgedrückt.Analog gibt es Instanz- oder Klassenmethoden. Methoden bestehen aus Methodenname, Parameterund Rückgabewert. Durch Instanzmethoden kann Nachrichtenaustausch zwischen Objekten stattfin-den, Klassenmethoden können unabhängig von Instanzen genutzt werden.

Klassen, Attribute und Methoden haben eine Sichtbarkeit, durch die die Möglichkeiten des Zugriffs aufsie festgelegt werden. Es wird zwischen private, protected und public unterschieden.Ein führendes – -Zeichen bedeutet private und das so markierte Element ist nur innerhalb seines Na-mensraums oder Containers sichtbar. So definierte Klassen sind nur innerhalb des ihnen zugeordnetenPakets sichtbar und dürfen nach außen nicht in Erscheinung treten. Attribute und Methoden sindinnerhalb des Namensraums sichtbar, der von der umhüllenden Klasse definiert wird. Als protected(#) deklarierte Elemente sind auch für Objekte von Unterklassen sichtbar. Public (+) bedeutet, dass


<<stereotype>> Paketname::BeispielKlasse

{constraints, tagged values}

-instanceAttribute:Integer = 10 +classAttribute \derivedAttribute

#instanceMethod(parameter:int):void +classMethod()

modeler defined section ...

objekt:BeispielKlasse

<<instantiate>>

Abb. 2.2: UML Klasse

die Sichtbarkeit des Elements nicht eingeschränkt wird, es kann auch von außerhalb des Namensraumsdarauf zugegriffen werden.

Schnittstellen

Eine Schnittstelle (interface) ist die Beschreibung des Verhaltens eines Elements durch die Spezifikationseiner Methoden. Sie ähnelt strukturell einer Klasse, besitzt aber keine Attribute, keine Implementie-rung der Methoden und kann nicht instanziiert werden. Die grafische Darstellung ähnelt der Klasse,über dem Namen wird das Schlüsselwort «interface» notiert und der Attributbereich fehlt.

<<interface>> BeispielSchnittstelle

method()

Abb. 2.3: UML Schnittstelle

Notizen

Mit Notizen können formale und informale Anmerkungen zu einem Diagramm gemacht werden. Siewerden als Rechteck mit Eselsohr dargestellt. Eine Notiz ist durch eine gestrichelte Linie mit demDiagrammelement verbunden, für das diese Notiz gelten soll.

Notiz

Abb. 2.4: UML notiz

Beziehungen

Es gibt drei Kategorien von Beziehungen in UML Klassendiagrammen: Abhängigkeiten (dependencies),Assoziationen (associations) und Generalisierung (generalization).

Abhängigkeiten

Wenn ein Element von einem anderen abhängig ist, heisst das, dass es bei einer Zustandsänderungdes anderen Elements benachrichtigt wird, da es semantisch auf eine nicht näher spezifizierte Weisemit ihm verbunden ist. Abhängigkeiten werden durch einen getrichelten Pfeil, der die Richtung der

2.2. UML 13

Abhängigkeit zeigt, dargestellt. Die Art der Abhängigkeit kann optional mit einem Stereotyp genauerdefiniert werden. Es gibt z.B. Instanziierungbeziehungen zwischen einem Objekt und einer Klasse(«instantiate», in Abb. 2.2) oder eine Realisierungsbeziehung («realization»). Diese beschreibt, dassKlassen Schnittstellen realisieren, d.h. implementieren. Dieses Stereotyp wird grafisch notiert, wobeidas Symbol der Darstellung der Generalisierung ähnelt:

<<interface>> BeispielSchnittstelle BeispielKlasse

Abb. 2.5: UML Realisierungsbeziehung

AssoziationenAssoziationen zwischen Modellelementen beschreiben Beziehungen, die Instanzen dieser Elemente un-tereinander haben können. Die Instanzen der Assoziation, die Instanzen der assoziierten Elemente ver-binden, werden als Objektbeziehungen (links) bezeichnet. Binäre Assoziationen werden als durchgezo-gene Linie zwischen den Elementen dargestellt. Mehrstellige Assoziationen verbinden alle teilhabendenElemente mit einer Route. Im folgenden werden binäre Assoziationen beschrieben. Eine Assoziationkann einen Namen (und eine Leserichtung, die vor dem Namen durch einen ausgefüllten dreieckigenPfeil dargestellt wird) haben. Außerdem kann sie eine Assoziationsklasse (mit Namen und Attributensowie Beziehungen zu anderen Klassen) sein. Dann werden Name und Attribute in einem Rechteck miteiner gestrichelten Linie zur Assoziation (der Linie) dargestellt. Durch Pfeilspitzen an den Assoziati-onsenden wird die Navigierbarkeit angezeigt. Die Objekte der Klasse, an der der Pfeil beginnt habenInformationen über die assoziierten Objekte. An den Assoziationsenden können Kardinalitäten (multi-plicities), Qualifizierer (qualifiers) und Rollen (roles) notiert werden. Kardinalitäten beschreiben, mitwie vielen anderen Objekten ein Objekt in Beziehung stehen kann. Sie werden an den Assoziationsen-den notiert. Qualifizierer sind Attribute, die ein über den Link mit einem anderen Objekt verbundenesObjekt identifizieren. Der Qualifizierer wird in einem kleinen Rechteck an der Klasse notiert. Rollenbeschreiben, welche spezielle Bedeutung das an der Assoziation beteiligte Element für das andere hatund stehen auch beim entsprechenden Assoziationsende.Die Aggregation und Komposition sind Spezialfälle der Assoziation. Die assoziierten Elemente stehen ineiner Teile/Ganzes-Beziehung. Das Aggregat bezeichnet das Ganze und an seinem Assoziationsende isteine unausgefüllte Route. Die Komposition ist eine spezielle Aggregation und beschreibt, dass die Teileohne das Ganze nicht existieren können. Sie wird durch eine ausgefüllte Route am Assoziationsendedes Aggregats dargestellt.


Klasse1 Klasse2 -Ende1

0..*

-Ende2

1

-Ende4 *

-Ende3 *

-End

e5

*

Klasse3 Klasse4

Klasse5

Klasse6 Klasse7

Assoziationsklasse1

*

-Ende6

*

-Ende7

Klasse9 -Ende8

*

-Ende9

*

-Attribut1 : Integer

Klasse8 Attribut1

Klasse10 -Ende10

1

-Ende11

*

Klasse11

Klasse12 Klasse13 -Ende12

*

-Ende13

*

zweistellige Assoziation:

mehrstellige Assoziation:

Assoziationsklasse:

qualifizierte Assoziation:

Komposition:

Aggregation:

Abb. 2.6: UML Assoziationen

2.2. UML 15

GeneralisierungenEine Generalisierung beschreibt die Beziehung zwischen einem allgemeineren (generelleren) und einemspezifischeren (spezielleren) Modellelement. Der generellere Typ ist der Supertyp, der speziellere derSubtyp. Bei dieser Beziehung wird auch von Vererbung gesprochen, da der Subtyp alle Eigenschaftendes Supertyps erbt. Bei der Einfachvererbung erbt ein Subtyp von genau einem Supertyp, bei derMehrfachvererbung kann er die Eigenschaften mehrerer Supertypen erben.Die Generalisierung wird als durchgezogener Pfeil vom Subtypen zum Supertypen dargestellt, diePfeilspitze ist ein unausgefülltes Dreieck.

Klasse1

Klasse3 Klasse2

Klasse1

Klasse3 Klasse2

Klasse3

Klasse2 Klasse1

Abb. 2.7: UML Generalisierung

Abstrakte Klassen

Abstrakte Klassen sind spezielle Klassen, die nicht instanziiert werden können. Sie ähneln also Schnitt-stellen, können aber Attribute und Methoden besitzen. Die Eigenschaften, die in einer abstrakten Klas-se beschrieben werden, können erst in tiefer angeordneten Klassen einer Vererbungshierarchie durchkonkrete Objekte verwendet werden. Grafisch unterscheidet sich eine abstrakte Klasse entweder durchdie kursive Schreibweise des Namens der Klasse oder durch das Name/Werte-Paar abstract=true imNamensfeld, welches in der Regel als abstract angegeben wird.

Klassenname {abstract}

Klassenname

Abb. 2.8: abstrakte Klassen in UML


2.3 OCL

Die Object Constraint Language (OCL) [2] ist eine formale Beschreibungssprache und dient der For-mulierung von semantischen Restriktionen für UML Modellelemente. Sie wurde als Erweiterung desUML Standards der OMG (Object Management Group) [3] in diesem definiert. Jeder Ausdruck, der inOCL geschrieben wird, bezieht sich auf Elemente (Klassen, Assoziationen etc.) eines zuvor definiertenUML Modells. Das heisst, die Verwendung der OCL als Modellierungssprache setzt die Verwendungvon UML bzw. Teilen der UML voraus.Da die Modellelemente nur beschrieben werden und ein OCL Ausdruck keine Zustandsänderung imDiagramm bewirken kann, ist die OCL eine Beschreibungssprache. Ausserdem ist sie eine Modellie-rungssprache, da sie keine der wichtigen Eigenschaften (wie Programmlogik, Flusskontrolle oder Pro-zessverwaltung) einer Programmiersprache besitzt. Und die OCL ist eine formale Sprache, denn alleAusdrücke verfügen über eine formal definierte Semantik.OCL ist objektorientiert und streng typisiert: Für jedes Objekt muss der Typ (seine Klasse) explizitangegeben werden. Die Spezifikation enthält die vordefinierten Typen, einfache Datentypen und Men-gen; ausserdem kann der Benutzer eigene Typen definieren und in einem Ausdruck verwenden. Durchdie Typisierung lassen sich die gestellten Bedingungen z.B. durch einen Parser und Constraint Checkereinfacher verifizieren. Die Sprache verfügt außerdem über ein Metamodell, das über die abstrakte Syn-tax von OCL Auskunft gibt; damit verbunden zeigt sich das theoretische Fundament, auf dem OCLbasiert. Das Metamodell ist durch Klassendiagramme formuliert. Darüberhinaus enthält es Wohlge-formtheitsregeln, die die Menge von möglichen Ausdrücken in zulässige und unzulässige Notationentrennen.Mit OCL können Invarianten für Klassen und Typen im Klassenmodell oder Typinvarianten für Ste-reotypen, Vor- und Nachbedingungen für Operationen, Guards oder Aussagen über ein UML Modellspezifiziert werden. Die OCL Ausdrücke erweitern das UML Diagramm um Informationen bzw. Re-striktionen und fügen ihm somit mehr Semantik hinzu. UML selbst besitzt keine Sprachelemente zurFormulierung solcher Bedingungen und kann diese nur unzureichend darstellen, z.B. durch natürlich-sprachliche Randnotizen, die aber nicht zwingend eingehalten werden müssen. Natürlichsprachige Textehaben den Nachteil, dass sie meistens mehrdeutig und daher nicht von einer Maschine interpretierbarsind. OCL behebt diesen Mangel durch eine textuelle Syntax, die die gewünschten Constraints adäquatumsetzt.Die OCL Version 2.0 ist in der Object Constraint Language Specification der OMG formal definiertworden. Dieser Standard der OMG steht mit anderen Standards, der UML Specification und dem MDA(Model Driven Architecture) Standard [5] der OMG, in Beziehung:

- Die OCL ist Bestandteil der UML.

- Der Kern der MDA ist, dass Modelle die Basis für Softwareentwicklung darstellen. Deshalb mussdie Modellierung von Softwaresystemen gut, solide, konsistent und verständlich sein. Die Anwen-dung von UML mit OCL ermöglicht die Erstellung solcher Modelle.

2.3.1 Kurze Einführung in OCL

Wie schon beschrieben, sind UML-Modelle häufig nicht genau genug, um alle relevanten Aspekte einerSpezifikation abzubilden, denn einige Aspekte lassen sich in UML nur sehr umständlich oder überhauptnicht modellieren. Die informale, umgangssprachliche Beschreibung von Einschränkungen zu einemModell führt oft zu Zweideutigkeiten in der Spezifikation. Um dies anhand einführender Beispiele ausOCL zu verdeutlichen, wird in Abb. 2.9 ein UML Modell dargestellt, das in [6] nachzulesen ist. Esbeschreibt ein kleines Hypotheken Klassendiagramm: Personen haben die dargestellten Attribute undMethoden, Häuser und Hypotheken die dargestellten Attribute. Personen können Häuser besitzen,wobei ein Haus genau einen Besitzer hat. Personen können Hypotheken aufnehmen, und zu jederHypothek gehört genau ein Haus und genau eine Person. Zu einem Haus kann es mehrere Hypothekengeben.

2.3. OCL 17

Mortgage principal: Money monthlyPayment: Money startDate: Date enddate: Date

Person socSecNr: Integer salary: Money getMortgage(sum: Money,

security: House)

House value: Money

houses owner

0..* 1

1 1

borrower

security

0..* 0..*

mortgages mortgages

Abb. 2.9: Beispiel Diagramm

Wenn man das Modell betrachtet, wird man leicht erkennen (ein Grundverständnis von Hypothekensei hier vorausgesetzt), dass die folgenden Bedingungen für dieses Modell gelten müssen:

• Eine Person kann nur Hypotheken auf Häuser, deren Besitzer sie ist, aufnehmen. Sie kann keineHypotheken auf Häuser von Freunden oder Nachbarn aufnehmen.

• Das Anfangsdatum eines Hypothekendarlehens ist vor dem Enddatum.

• Die Sozialversicherungsnummern von Personen müssen eindeutig sein.

• Eine Person darf nur dann eine neue Hypothek aufnehmen, wenn ihr Einkommen hoch genug ist.

• Die Aufnahme einer neuen Hypothek ist nur möglich, wenn der Gegenwert des Hauses hoch genugist.

All diese Informationen gehen nicht aus dem Diagramm hervor und es gibt auch keine Mechanis-men, mit denen das Diagramm sie darstellen könnte. Wenn diese Einschränkungen (Constraints) zumDiagramm nicht dokumentiert werden, können verschiedene Personen das Diagramm unterschiedlichinterpretieren. Wenn das Diagramm falsch verstanden wird, führt das zu einer inkorrekten Implementa-tion des spezifizierten Systems. Es würde auch nicht ausreichen, diese Bedingungen umgangssprachlichzu notieren, da jede Sprache zweideutig ist und umgangssprachliche Ausdrücke leicht unterschiedlichinterpretiert werden können.OCL Ausdrücke können diese Bedingungen an das Hypotheken-System vollständig und korrekt be-schreiben. Durch das Erweitern des Modells um OCL Ausdrücke wird die Formulierung der Constraintseindeutig und das Modell kann nicht mehr falsch verstanden und interpretiert werden (zumindest inBezug auf diese Regeln). Die entsprechenden OCL Constraints zu den oben umgangssprachlich be-schriebenen Bedingungen sind:

• context Mortgageinv: security.owner = borrower

• context Mortgageinv: startDate < endDate

• context Personinv: Person::allInstances()->isUnique(socSecNr)

• context Person::getMortgage(sum: Money, security: House)pre: self.mortgages.monthlyPayment->sum() <= self.salary * 0.30

• context Person::getMortgage(sum: Money, security: House)pre: security.value >= security.mortgages.principal->sum()


Ein OCL Constraint ist wie folgt aufgebaut:Er hat einen Kontext, der die Umgebung beschreibt, in der er gilt. Der Kontext wird am Anfangdes Ausdrucks definiert und bezieht sich immer auf ein UML-Modellelement (Klasse oder Methode).context Mortgage leitet also eine Einschränkung auf ein Objekt der Klasse Mortgage ein. Nach demKontext wird die Art des Constraints beschrieben. Diese kann inv für Invarianten, def für definitionConstraints, pre oder post für Vor- bzw. Nachbedingungen von Operationen oder Methoden sein.

Invarianten

Eine Invariante beschreibt eine Eigenschaft eines Objekts, die sich während der Ausführung einerOperation nicht ändern darf und für alle Instanzen eines Typs zu jedem Zeitpunkt gelten muss. DieAuswertung einer Invariante ergibt einen booleschen Wert. Die ersten drei OCL Constraints beschrei-ben Invarianten.

Vor- und Nachbedingungen

Vor- und Nachbedingungen beziehen sich immer auf Operationen oder Methoden. Eine Vorbedingungmuss vor, eine Nachbedingung nach der Ausführung einer Methode gelten. Die letzten beiden OCLAusdrücke beschreiben Vorbedingungen für die Methode getMortgage(sum: Money, security: House)der Klasse Person.

Definition Constraints und Let Ausdrücke

Es gibt zwei Möglichkeiten, OCL Ausdrücke wiederverwendbar zu machen. Mit einem Let Ausdruckkönnen Attribute und Operationen definiert werden, die in einem Constraint mehrfach genutzt werden.Um OCL Ausdrücke in verschiedenen Constraints verwenden zu können, werden sie in einem Constraintder Art definition definiert. Die so definierten Attribute und Operationen können in jedem Constraintim gegebenen Kontext benutzt werden.

Self:Jeder OCL Ausdruck steht im Kontext einer Instanz eines bestimmten Typs. Diese Instanz wird mitself referenziert. Ist der Kontext eine Klasse, so ist self eine Instanz dieser Klasse, ist der Kontext eineMethode, so ist self eine Instanz der Klasse, die diese Methode definiert.

Navigationen entlang von Assoziationen

Um eine Navigation zu einer assoziierten Klasse auszudrücken, wird in OCL der Punkt ’.’ verwendet.Nach dem Punkt wird der Rollenname der Klasse oder (wenn kein Rollenname definiert wurde) derkleingeschriebene Klassenname notiert. Im 1. Constraint wird von einer Instanz der Klasse Mortgageüber den Rollennamen security zu einer Instanz der Klasse House und dann weiter über den Rollenna-men owner zu einer Instanz der Klasse Person navigiert. Dasselbe Ergebnis soll die Navigation überden Rollennamen borrower liefern. Im 4. Constraint wird von einer Instanz der Klasse Person (self )zu den Hypotheken dieser Person navigiert (über den Rollennamen mortgages).

Navigation zu Attributwerten

Auch die Navigation zu Attributwerten oder Methodenaufrufen wird durch einen Punkt ’.’ dargestellt.Im 4. Constraint wird nach der Navigation zu den Hypotheken (self.mortgages) zu den AttributenmonthlyPayment navigiert, im 5. Constraint wird zu einem Haus und dann zum Attributwert valuedes Hauses navigiert.

2.3. OCL 19

allInstances():

allInstances() ist eine Eigenschaft, die auf Klassen definiert ist und zu einer Klasse die Menge allerInstanzen zu diesem Zeitpunkt liefert. Im 3. Constraint liefert Person::allInstances() die Menge allerInstanzen zur Klasse Person.

Operationen auf Collections

Das Ergebnis einer Navigation entlang einer Assoziation kann entweder keine Instanz, eine Instanz,oder viele Instanzen (eine Collection) sein. Collection ist ein abstrakter Typ, von dem drei konkreteerben: Set, Bag und Sequence. Auf Collections gibt es vordefinierte Operationen, von denen in obigenConstraints die folgenden vorkommen:

- isUnique(socSecNr) bedeutet, dass das Attribut socSecNr für alle Elemente der Menge eindeutigist.

- sum() summiert die Attributwerte der Menge auf und gibt die Summe zurück.

Das sind Operationen auf Collections, die über alle Elemente der Collection iterieren. Die Operationenauf Collections werden durch einen Pfeil ’->’ dargestellt, rechts vom Pfeil steht der Operationsname,in den Klammern dahinter kann ein Ausdruck stehen. Es gibt auch Iteratorausdrücke, die über einenbestimmten Wert in einer Collection iterieren und Ergebnisse unterschiedlichen Typs (Boolean, Integer,andere Collections, etc.) haben können. Es könnte aus einer Menge eine Teilmenge selektiert werden,deren Elemente bestimmte Eigenschaften besitzen. Z.B. die Menge aller Hypotheken auf Häuser, derenWert höher als 100000 ist:context Mortgage inv: Mortgage::allInstances()->select(h:House| h.value > 100000)->size()>=10.Dieser Constraint drückt aus, dass es mindestens 10 solcher Hypotheken gibt. Die Operation select ite-riert über alle Elemente und liefert eine Menge der Elemente, die die in den Klammern beschriebenenBedingungen erfüllen.Die Operation forall iteriert über alle Elemente und liefert einen booleschen Wert, der ausdrückt, oballe Elemente die in den Klammern beschriebenen Bedingungen erfüllen.Die Operation exists liefert einen booleschen Wert, der ausdrückt, ob mindestens ein Element die inden Klammern beschriebenen Bedingungen erfüllen.Auf Collections sind auch andere Operationen definiert, z.B. isEmpty oder notEmpty, die true liefern,wenn die Collection keine bzw. mindestens ein Elemente enthält, und sie Operation size(), die dieAnzahl der Elemente in der Collection zurückgibt. Außerdem gibt es Mengenoperationen wie union,intersection etc., die je nach der Art der Collection (Set, Bag, Sequence) unterschiedliche Ergebnis-Collections (Set, Bag, Sequence) liefern. Oder andere Operationen, die nur auf den verschiedenenkonkreten Collection-Typen definiert sind, wie z.B. first, last oder at(index), die nur auf Sequenzendefiniert sind, und die entsprechenden Elemente der Sequenz zurückgeben.

Boolesche Operationen

OCL enthält die booleschen Operation and, or , xor, not und implies, die OCL Ausdrücke miteinanderverknüpfen, and, or, xor und not liefern boolesche Werte, die true sind, wenn alle Ausdrücke erfülltsind (and), mindestens ein Ausdruck erfüllt ist (or), genau ein Ausdruck erfüllt ist (xor) und wennder Ausdruck nicht erfüllt ist (not).Mit Hilfe einer and Operation könnten die ersten beiden Constraints zu einem zusammengefasst wer-den:context Mortgageinv: (security.owner = borrower) and (startDate < endDate)Ein Implies Ausdruck besteht aus zwei Teilen, der Prämisse und der Konklusion. Wenn die Prämisseerfüllt ist, muss auch die Konklusion erfüllt sein.


Der dritte Constraint kann auch durch eine forall -Operation, deren Body eine implies Operation ent-hält, ausgedrückt werden:context Personinv: Person::allInstances()->forall(p1, p2:Person| p1 <> p2 implies p1.socSecNr <> p2.socSecNr)Hier wird über alle Instanzen der Klasse Person mit Hilfe von zwei Iteratoren iteriert. Der Body defi-niert, dass verschiedene Personen auch unterschiedliche Sozialversicherungsnummern haben müssen.

If Then Else

Auch ein If-Then-Else Konstrukt ist in OCL definiert, der if-Teil beschreibt eine Bedingung, die wennsie zu true ausgewertet wird, den then-Teil zur Folge hat, ansonsten den else-Teil.

Vordefinierte Eigenschaften

Es gibt vordefinierte Eigenschaften, die auf allen Objekte definiert sind, wie oclIsUndefined(), was aus-drückt, dass ein Objekt vom Typ OCLUndefined ist, oder oclIsTypeOf(type), was true ergibt, wenndas Objekt vom übergebenen Typ ist. Eine ähnliche Eigenschaft ist oclIsKindOf(type), was true ergibt,wenn das Objekt vom übergebenen Typ oder einem Subtyp ist.Ein einfaches Beispiel für diese Eigenschaften ist:context Houseinv: self.oclIsTypeOf(House) and not(self.oclIsTypeOf(Person))

Die hier beschriebenen OCL Ausdrücke beinhalten nur einen Teil der möglichen Konstrukte, die OCLzur Verfügung stellt. Das sind vor allem die, die im Kapitel 4 im Abschnitt 4.2 verwendet werden. Einegenaue Beschreibung der OCL mit Beispielen ist in [2] nachzulesen. Diese enthält auch das Metamodellund die Wohlgeformtheitsregeln der OCL.

Wenn man die oben dargestellten OCL Constraints in das Modell einfügt, hat das viele Vorteile: Es gibtkeine Missverständnisse, wenn verschiedene Personen die Ausdrücke lesen und interpretieren. Dadurchwerden Fehler zu einem früheren Zeitpunkt der Entwicklung entdeckt und können relativ billig entferntbzw. verbessert werden. Die Implementierer verstehen sofort, was der Modellierer meint. Außerdemkann das Modell von Tools verwendet werden, um damit

- Simulationen und Tests zu generieren

- Konsistenzchecks durchzuführen

- um aus dem Modell neue Modelle in anderen Sprachen mit einer MDA Transformation zu erstellen

- zur Codegenerierung

- etc.

Diese Automatisierung ist nur möglich, wenn das Modell alle benötigten Informationen enthält. EinTool kann keine natürlichsprachlichen Ausdrücke interpretieren. Aber die in OCL geschriebenen Cons-traints beinhalten alle notwendigen Informationen für automatisierte Tools. Dies ermöglicht eine effizi-entere und schnellere Implementation als per Hand und die Konsistenz zwischen dem Modell und dergenerierten Implemenatation (bzw. den generierten Teilen) wird garantiert.

2.4 Visuelle Sprachen

In diesem Abschnitt wird eine kurze Definition der Begriffe visuell, Sprache sowie visuelle Sprachegegeben.

2.4. VISUELLE SPRACHEN 21

• Visuell:

“Die Eigenschaft visuell bezieht sich nicht nur auf graphische Elemente, sondern auch auf ge-wöhnlichen Text, der ebenso sichtbar ist, wie etwa ein Piktogramm. Der Komplementärbegriffzu visuell ist demnach der Begriff verbal und nicht - wie oft unbedacht verwendet - der Begrifftextuell. Die Differenzierung zwischen visuell und verbal deckt sich auch mit der Begriffsweltder Kognitionspsychologie, die zwischen der Verarbeitung verbaler und visueller Informationenunterscheidet. Unter visuell ist jene Eigenschaft von Objekten zu verstehen, die zur Folge hat,dass signifikante Informationen über ein Objekt nur über das visuelle Wahrnehmungssystem desMenschen erfassbar sind. Mit anderen Worten: ein Objekt weist dann die Eigenschaft visuell auf,wenn mindestens eine Information über das Objekt, die für die Durchführung einer bestimmtenAktivität unverzichtbar ist, über andere Sinne nicht gewonnen werden kann. Visuell ist somitals visuell informativ zu verstehen. Rein textuelle Objekte sind zwar sichtbar, aber nicht visuellinformativ, weil man die dargestellten Informationen nicht nur über das Auge, sondern ohneInformationsverlust auch über das Gehör und andere Sinne aufnehmen kann. Farbige Objektehingegen sind visuell informativ (falls die Farben eine Bedeutung haben), weil die Interpretationder Farben nur über das visuelle Wahrnehmungssystem erfolgen kann.“(aus [11])

• Sprache:

Sprache hat zwei eng mitverwandte Bedeutungen, die Sprache (ohne Plural) vs. eine Spra-che/Sprachen.Die Sprache bezeichnet die Kommunikationsformen des Menschen. Die bewusste Kommunikationwird durch Lautsprache, Gebärdensprache und Schriftsprache vollzogen. Die unbewusste Kom-munikation vollzieht sich beispielsweise durch Körpersprache.Definition nach Edward Sapir (1921):

Sprache ist eine ausschließlich dem Menschen eigene, nicht im Instinkt wurzelndeMethode zur Übermittlung von Gedanken, Gefühlen und Wünschen mittels eines Sy-stems von frei geschaffenen Symbolen. (zitiert nach John Lyons, 4. Auflage, 1992, S.13)

Eine Sprache dagegen ist jedes einzelne Zeichensystem, das der Kommunikation dient, alsomenschliche Einzelsprachen (beispielsweise Deutsch), Fachsprachen (beispielsweise Rechtsspra-che), Computersprachen (beispielsweise Prolog) etc.Auch in der Informatik wird von Sprachen gesprochen. Diese Sprachen, Formale Sprachen ge-nannt, sind mathematische Modelle von Sprachen, die besonders in der theoretischen InformatikAnwendung finden.Eine formale Sprache L ist eine Menge von Wörtern über einem Alphabet S. Dabei ist ein Al-phabet einfach eine endliche Menge von Objekten, die man wiederum Symbole oder Zeichennennt. Ein Wort ist eine Folge bzw. Liste von Symbolen. Eine formale Sprache wird durch eineGrammatik erzeugt, die aus Regeln zur Bildung von Wörtern besteht.Menschliche Sprachen basieren auf endlichen Alphabeten, deshalb sind sie als Teilmenge in derMenge aller Wörter über dem betreffenden Alphabet enthalten und somit auch formale Sprachen.(aus [10])

• Visuelle Sprache:

Definition des BegriffsEine präzise und trotzdem zufriedenstellende Definition des Begriffs visuelle Spracheist im Grunde unmöglich. Dies liegt insbesondere daran, dass es keine wirklich sinn-vollen Kriterien für die Abgrenzung visueller von textuellen Sprachen gibt.Es gibt jedoch Eigenschaften, durch die visuelle Darstellungen von textuellen abge-grenzt werden können.Eigenschaften textueller Darstellungen:


– es gibt nur eine Nachfolgebeziehung zwischen den elementaren Bestandteilen derRepräsentation

– zweidimensionale Formatierung (Einrückung etc.) des eindimensionalen Zeichen-stroms ist ohne semantische Bedeutung

Eigenschaften visueller Darstellungen:

– die Darstellung ist mehrdimensional

– räumliche Beziehungen wie innerhalb, hinter, berührt, über,... spielen für die In-terpretation des Dargestellten eine wichtige Rolle

Definition des Begriffs visuelle Sprache aus [Mye90]:“A visual language is a language with at least some constructs which have an eitherinherently or superimposed multidimensional representation.“Visuelle Sprachen besitzen in den verschiedensten Ingenieursdisziplinen eine lange Tra-dition. Herausragende Beispiele sind:

– Schaltpläne in der Elektrotechnik

– Baupläne in der Architektur

– Modellierungssprachen in der Softwaretechnik

(aus [9])

Vorteile bzw. Nachteile von visuellen DarstellungenAnscheinend fällt das Verstehen eines Programms leichter, wenn es in einer grafischenanstelle einer textuellen Repräsentation vorliegt. Als empirischer Beleg dieser Annah-me mag gelten, dass Entwickler und Programmierer schon immer Abbildungen benutzthaben, um die Eigenschaften eines Programms darzustellen, auch bevor es dazu un-terstützende Software gab. Zweidimensionale Abbildungen von Programmen (z.B. inForm von Kontrollflussgraphen) sind schon lange als wichtige Hilfe beim Programm-verstehen bekannt [13].Ein weiterer Vorteil grafischer Darstellungen liegt in der Anzahl verfügbarer Ausdrucks-mittel begründet. Eine textuelle Repräsentation besteht aus einzelnen Zeichen, die ei-nem relativ kleinen Alphabet entstammen; für visuelle Repräsentationen stehen nebenden horizontalen und vertikalen Koordinaten zusätzlich Form, Farbe, Größe, Füllmu-ster und Helligkeit zur Verfügung. Die Zeichen, die in der textuellen Repräsentationverwendet werden, unterscheiden sich demgegenüber zunächst nur in ihrer Form. Ty-pographie erhöht zwar die Auswahl an Ausdrucksmitteln, reicht aber noch nicht anvisuelle Darstellungen im Sinne von Diagrammen heran.Dass Programmierer visuelle Darstellungen benutzen, hängt auch von verschiedenen,nicht objektivierbaren Kriterien ab. Eine von Petre et al. [14] zitierte Befragung ergab,dass den grafischen Repräsentationen folgende Eigenschaften beigemessen werden:

– höherer Informationsgehalt bzw. höhere Informationsdichte

– höherer Abstraktionsgrad und damit bessere Abbildung des Problembereichs

– Bereitstellen eines Überblicks, Strukturen werden leichter sichtbar

– besser zugänglich, leichter zu verstehen, schneller zu begreifen

– angenehmer, weil weniger formal.

Diesen Ergebnissen sollte jedoch nicht vorbehaltlos zugestimmt werden. Andere Ex-perimente stützen zwar einige der Aussagen, widerlegen sie jedoch auch zum Teil.Beispielsweise kann in diesem Zusammenhang ein weiterer, ebenfalls in [14] zitier-ter Versuch angeführt werden, in dem den Versuchspersonen das Erkennen ähnlicherStrukturen anhand textueller Darstellungen leichter fiel als mit Hilfe der grafischenRepräsentation.Ähnliches greift auch Schiffer in [15] auf und formuliert daraus fünf Thesen, die typi-scherweise als Vorteile visueller Techniken angesehen werden (beispielsweise, dass Bil-der leicht verständlich seien und das Lernen vereinfachen)– und für die gezeigt wird,

2.4. VISUELLE SPRACHEN 23

dass sie nicht allgemein gültig sind.Eine Arbeit, die sich gezielt mit den Unterschieden von textuellen und visuellen Dar-stellungen beschäftigt, wurde von Larkin und Simon [16] veröffentlicht. Die Autorenkommen zu dem Schluss, dass das Erkennen von Informationen in visuellen Darstellun-gen nicht grundsätzlich effizienter als in textuellen Darstellungen erfolgt. Das Suchenbei visuellen Repräsentationen profitiert von der Indexierung, die durch die räumlicheAnordnung gegeben ist. Da zusammenhängende Informationen oft an nahegelegenenOrten zu finden sind, lässt sich die gewünschte Information in der Regel schnell fin-den, wenn der ungefähre Bereich festgestellt und danach in dessen Umgebung einedetailliertere Suche durchgeführt wird. Die eindimensionale, sequentielle Suche ermög-licht keine vergleichbar effektive Suche. Das größte Potential visueller Darstellungenliegt nach Einschätzung von Larkin und Simon in der Ableitung bisher nicht explizitdargestellten Wissens: Diagramme können viele Zusammenhänge sichtbar machen, dieaus einer ansonsten äquivalenten, textuellen Darstellung erst noch erschlossen werdenmüssen.(aus : [12]

Ansätze zur Definition einer visuellen SpracheVisuelle Sprachen spielen eine zentrale Rolle in der Modellierung verschiedener Aspektevon (Software)Systemen. Visuelle Modellierungssprachen werden in den frühen Pha-sen der Softwareentwicklung eingesetzt, um Anforderungen an ein System festzulegen.Der momentan bekannteste Vertreter ist die objektorientierte ModellierungsspracheUML, die aus verschiedenen Diagrammtechniken besteht und sowohl Struktur als auchVerhalten von objektorientierten Softwaresystemen beschreibt.Um eine visuelle Sprache formal zu definieren, werden im wesentlichen zwei Ansätzeunterschieden: der deklarative Ansatz und der konstruktive Ansatz.Die UML wird mit dem MOF Ansatz, der Klassen und Assoziationen zur Definitionvon Symbolen und Relationen verwendet, definiert. Zusätzlich sind bei dieser Defini-tion Kardinalitäten und Constraints notwendig, um erforderliche Spracheigenschaftenauszudrücken. Durch diese wird die Menge aller möglichen Symbole und Relationenauf die in dieser Sprache zulässigen eingeschränkt. Solche constraint-basierten Forma-lismen stellen einen deklarativen Ansatz zur Definition einer visuellen Sprache dar.Zum konstruktiven Ansatz zählen Grammatiken, wobei sowohl textuelle als auch visu-elle Grammatikansäte zur Definition einer visuellen Sprache möglich sind. Graphgram-matiken sind visuelle Spezifikationsmechanismen zur Definition der abstrakten Syntaxeiner visuellen Sprache.


2.5 MOF

Die Meta-Object Facility (MOF) [4] ist ein Standard der OMG. Die MOF Spezifikation definiert eineabstrakte Sprache und ein Framework zur Verwaltung, Erzeugung und Spezifikation von plattformun-abhängigen Metamodellen. Mit MOF können verschiedene Arten von Modellen und Modellierungsspra-chen miteinander in Beziehung gesetzt werden. Beispiele solcher Metamodelle sind die UML (UnifiedModeling Language), das Common Warehouse Metamodel (CWM) und die MOF selbst.Zusätzlich definiert die Spezifikation ein Grundgerüst, mit dem ein Repository implementiert werdenkann, das Metadaten speichert, die durch Metamodelle definiert werden. Dieses Framework definiertStandard Technologie Mappings, durch die MOF Modelle in Metadaten APIs (Application Program-ming Interfaces) transformiert werden. Z.B. wurde die MOF IDL (Interface Definition Language) aufdas MOF Metamodell und das UML Metamodell angewandt, um APIs für die CORBA (CommonObject Request Broker Architecture) zu erzeugen, die MOF Metamodelle bzw. UML Metamodellerepräsentieren.Die MOF Spezifikation besteht aus:

- Der formalen Definition des MOF Meta-Metamodells, also der Sprache zur Spezifikation vonMOF Metamodellen

- einem Mapping, das beliebige MOF Metamodelle in die CORBA IDL abbildet, mit dessen HilfeIDL Interfaces zur Verwaltung von Metadaten erzeugt werden

- reflective CORBA IDL Interfaces zur Verwaltung von Metadaten unabhängig vom Metamodell

- CORBA IDL Interfaces zur Repräsentation und Verwaltung von MOF Metamodellen

- dem XMI Format, mit dem MOF Metamodelle ausgetauscht werden können

Die XML (Extensible Markup Language) Metadata Interchange (XMI) Spezifikation definiert Techno-logie Mappings von MOF Modellen in XML DTDs (Document Type Definition) und XML Dokumente.Normalerweise werden UML und MOF im Zusammenhang mit einem konzeptionellen Schichtenmodellbetrachtet. Zusätzlich sind ihre Metamodelle architektonisch miteinander verbunden, indem sie sich dieKernkonstrukte der objektorientierten Modellierung teilen. Dadurch kann die MOF die UML Notationzur Visualisierung ihrer Metamodelle verwenden.Das Schichtenmodell und die Kernkonzepte werden im folgenden näher betrachtet.

2.5.1 Klassische Vier-Ebenen-Metadaten-Architektur

Das klassische Framework zur Metamodellierung basiert auf einer Architektur mit vier Ebenen vonMetadaten, die in Abbildung 2.10 dargestellt ist. Diese Ebenen sind:

Informations-Ebene (Abb. 2.10 information): Die Informations-Ebene besteht aus den Daten,die beschrieben werden sollen.

Modell-Ebene (Abb. 2.10 model): Die Modell-Ebene besteht aus Metadaten, die die Daten derInformation-Ebene beschreiben. Diese Ebene wird auch als Modell bezeichnet.

Metamodell-Ebene (Abb. 2.10 metamodel): besteht aus Beschreibungen (Meta-Metadaten),die die Struktur und Semantik der Metadaten definieren. Diese Ebene wird informell auch alsMetamodell bezeichnet. Dabei ist ein Metamodell eine abstrakte Sprache zur Beschreibung ver-schiedener Arten von Daten, sie hat keine konkrete Syntax oder Notation.

Meta-Metamodell-Ebene (Abb. 2.10 meta-metamodel): definiert die Struktur und Seman-tik der Meta-Metadaten. Sie ist eine abstrakte Sprache zur Definition verschiedener Arten vonMetadaten.

2.5. MOF 25

meta-metamodel

metamodel

model

information

Hard-wired Meta-metamodel

Metamodel("RecordTypes", MetaClass("Record", [MetaAttr("name", String), MetaAttr("fields, List<"Field">] MetaClass("Field", ...

Record("StockQuote", [Field("company", String) Field("price", FixedPoint)])

StockQuote("Sunbeam Harvesters", 98.77) StockQuote("Ace Taxi Cab Ltd", 12.32)

Abb. 2.10: klassische Architektur

Im Beispiel in Abb. 2.10 stellt die Informations-Ebene einfache Datensätze dar (StockQuotes). DieseDatensätze werden in der Modell-Ebene mit einem Modell für Datensätze (Record) beschrieben. DasMetamodell für Datensätze beinhaltet z.B. Meta-Klassen (MetaClass) und Meta-Attribute (MetaAt-tribute). Diese werden durch das Meta-Metamodell (hard-wired Meta-metamodel) beschrieben.

Vorteile der Vier-Ebenen-Metadaten-Architektur sind:

- jede Art von Modellen und Modellierungs-Paradigmen wird unterstützt

- verschiedene Arten von Metadaten können miteinander in Beziehung gesetzt werden.

- eine Erweiterung um neue Metamodelle oder Metadaten ist möglich

- verschiedene Metamodelle und Modelle, die das gleiche Meta-Metamodell haben, sind austausch-bar

2.5.2 MOF Metadaten-Architektur

Die MOF Metadaten-Architektur basiert auf der klassischen Vier-Ebenen-Metadaten-Architektur. Sieist in Abb.2.11 dargestellt und besteht aus vier Ebenen:

M0-Ebene: Die M0-Ebene enthält konkret ausgeprägte Daten; sie beschreibt die Ausprägungeneines bestimmten Modells.

M1-Ebene: Die M1-Ebene besteht aus Modellen, z.B. physikalische oder logische Daten-, Prozess-oder UML bzw. ObjektModelle, die die Daten der M0-Ebene definieren

M2-Ebene: Die M2-Ebene enthält Meta-Modelle. Diese definieren, wie die Modelle aufgebautund strukturiert sind. Die M2-Ebene definiert die Sprache zur Beschreibung der Modelle (z.B.Klasse, Attribut, Operation, etc). Die Konzepte dieser Ebene werden bei der UML Modellierungverwendet (UML Class, UML Association, UML Attribute, ...)

M3-Ebene: Die M3-Ebene ist die MOF-Ebene. Sie ist eine abstrakte Ebene, die zur Definitionder M2-Ebene herangezogen wird. Die M3-Ebene definiert die Sprache zur Beschreibung vonMetamodellen, z.B. die Menge der Konstrukte, die zur Definition von Metamodellen genutztwird (MOF Klassen, MOF Assoziationen, MOF Attribute, usw.). Es gibt keine höhere Ebene.


MOF Model

IDL Metamodel UML Metamodel

UML Models

M3 Ebene Meta-Metamodel

M2 Ebene Metamodelle

M1 Ebene Modelle IDL Interfaces

...

...

M0 Ebene

Abb. 2.11: MOF Architektur

Die MOF Architektur hat einige Vorteile, durch die sie sich von der klassischen Architektur unterschei-det:

- Das MOF Modell ist objektorientiert.

- Die Meta-Ebenen sind nicht festgeschrieben. D.h., es können mehr oder weniger Ebenen sein,abhängig von der jeweiligen Anwendung. Die verschiedenen Ebenen dienen nur dem Verständnisder Beziehungen zwischen den verschiedenen Arten von Daten und Metadaten.

- Ein Modell (im Sinne einer Sammlung von Metadaten) ist nicht unbedingt auf eine Ebene be-schränkt.

- Das MOF Modell ist selbstbeschreibend, d.h. das MOF Modell kann mit seinen eigenen Kon-strukten formal definiert werden.

Die Selbstdefinition hat wichtige Konsequenzen: Sie zeigt, dass das MOF Modell für die praktische Me-tamodellierung ausdrucksstark genug ist. Außerdem können die MOF Interfaces durch das Mappingder eigenen MOF IDL auf das MOF Modell selbst erstellt werden. Die Selbstdefinition stellt eine Basiszur Verfügung, mit der die MOF erweitert und modifiziert werden kann.

2.5.3 Konzepte des MOF Modells

Das MOF Modell basiert auf den Konzepten von Entitäten und Relationen. Es verwendet zur Mo-dellierung ein Framework, das im wesentlichen eine Teilmenge des UML Core Pakets ist. Die vierKern-Modellierungs-Konzepte sind:

1. Klassen, die die MOF Meta-Objekte modellieren

2. Assoziationen, die binäre Beziehungen zwischen den Meta-Objekten beschreiben

3. Datentypen, die andere Daten (primitive Typen, externe Typen, etc.) modellieren

4. Pakete, die Mengen von Objekten enthalten und der besseren Strukturierung der Modelle dienen

2.5. MOF 27

Klassen

MOF Klassen definieren den Typ eines Objekts. Klassen, die in einer Meta-Modellebene erstellt wur-den, können Instanzen in der darunter liegenden Modell-Ebene haben. Die Instanzen auf dieser Ebenebesitzen dann Fähigkeiten, Zustände und Objektidentitä, welche durch deren Meta-Modell-Ebene be-schrieben und eingeschränkt wird.Klassen können drei Eigenschaften haben: Attribute, Operationen und Assoziationsreferenzen. Außer-dem können sie Exceptions, Konstanten, Datentypen und Constraints enthalten.Attribute haben einen Namen (der innerhalb der Klasse eindeutig sein muss), einen Typ (Klasse oderDatentyp) und eine Anzahl von Werten. Ein Attribut kann abgeleitet sein (d.h. sein Wert wird ausanderen Attributen berechnet), und es kann direkt veränderbar sein, was in zwei Flags, isChangeableund isDerived, festgelegt ist.Operationen haben einen Namen, eine Parameterliste, einen Rückgabetyp und eine Liste von Excepti-ons.Assoziationsreferenzen haben einen Namen, ein referenziertes Assoziationsende und die Information,ob die Referenz änderbar ist. Durch Assoziationsreferenzen können Klassen “herausfinden“, an welchenAssoziationen sie beteiligt sind.Eine Klasse kann von einer oder mehreren anderen Klassen erben. Die Subklasse erbt alle Eigenschaftender Superklasse, also ihre Attribute, Operationen und Assoziationsreferenzen, sowie ihre Exceptions,Konstanten, Datentypen und Constraints. Eine Klasse kann nicht von sich selbst erben.Die Vererbung wird über die Parameter leaf und root gesteuert. Eine Klasse, die als leaf deklariertwurde, kann keine Subklassen haben. Eine als root markierte Klasse kann von keiner anderen Klassemehr erben. Eine Klasse kann abstrakt sein; abstrakte Klassen können nur für die Vererbung verwendetwerden und dürfen keine Instanzen haben.

Assoziationen

MOF Assoziationen beschreiben Relationen zwischen Objekten des Metamodells. Diese Relationenheißen Links und können keine Attribute oder Operationen haben. Eine Assoziation enthält genauzwei Assoziationsenden, welche die beiden Enden des Links beschreiben.Ein Assoziationsende hat einen Namen und einen Typ. Der Typ bestimmt, welche Klasse an derAssoziation teilnimmt. Zusätzlich hat ein Assoziationsende eine Kardinalität und eine Information, obes eine Aggregation ist. Außerdem können Assoziationsenden navigierbar und direkt änderbar sein.

Datentypen

MOF Datentypen sind Typen, deren Werte keine Objektidentitäten haben. Datentypen dienen derModellierung anderer Daten (primitive Typen, externe Typen, zusammengesetzte Typen etc.) DieMOF sieht dabei sechs einfache Datentypen (bspw. Boolean, Integer, String) vor, die mit Hilfe vonStandardtypenkonstruktoren (enumeration, structures etc.) verknüpft werden können.

Pakete

Die MOF Pakete dienen der Gruppierung von Elementen innerhalb eines Metamodells.Auf der Metamodellebene ermöglichen Pakete eine Modularisierung und Partitionierung des Modell-raums. Pakete können aus Paketen und allen anderen Metamodellkonstrukten (wie Klassen, Assoza-tionen, Attributen, Exceptions) bestehen.Auf der Modellebene sind Pakete Kontainer für Metadaten.Das MOF Modell stellt zur Komposition und Wiederverwendbarkeit vier weitere Mechanismen zurVerfügung:

• Generalisierung: Analog zu Klassengeneralisierung lassen sich somit Pakete von anderen (Su-perpaketen) ableiten. Die abgeleiteten Pakete besitzen dann alle Elemente des Superpaketes.Analog zu den Klassen können diese zudem Leaf und Root Annotationen besitzen, wobei ab-strakte Pakete nicht unterstützt werden.


• Verschachtelung: Ein Paket kann andere Pakete enthalten. Ein solches verschachteltes Paketist eine Komponente des einschließenden Pakets und besitzt bestimmte Regeln, welche z.B. dieGeneralisierung oder Importierung mit bzw. durch andere Pakete verbieten.

• Importierung: Das importierende Paket kann Elemente des importierten Pakets verwenden. Solassen sich z.B. bestimmte Attribute, Operationen oder Ausnahmen durch importierte Klassenund Datentypen nutzen. Durch den Import können die Pakete wiederverwendet werden, was beieiner Schachtelung nicht möglich ist.

• Clustering: Das Clustering ist eine verstärkte Form des Imports von Paketen hinsichtlich desLebenszyklusses von Instanzen, die analog zur Importierung verwendet werden können.

Die bisher beschriebenen Konstrukte des MOF Modells ermöglichen dem Modellierer die Definitioneiner abstrakten Syntax bestehend aus Metadatenknoten und Verbindungen zwischen diesen Knoten.Diese Syntax muss im Allgemeinen noch um weitere Konsistenzregeln angereichert werden.

2.6. GRAPHTRANSFORMATION 29

2.6 Graphtransformation

Graphtransformation ist eine regel-basierte Modifikation von Graphen. D.h., Graphen werden durchdie Anwendung von Regeln in andere Graphen transformiert. Hierbei sind die Ausgangs- und Ergeb-nisgraphen Elemente einer bestimmten Graphsprache. Ein Graph besteht aus Knoten und Kanten.Eine Regel hat eine linke und eine rechte Seite und beschreibt, wie in einem Graphen ein Teilgraphentfernt, durch einen anderen Teilgraphen ersetzt und in den Restgraphen eingebettet wird. DiesesKapitel besteht aus einer kurzen Beschreibung von getypter, attributierter Graphtransformation, beider die Knoten und Kanten eines Graphen getypt und attributiert sein können. Dann folgt eine rechtausführliche Beschreibung des Konzepts der getypten attributierten Graphtransformation mit Kno-tentypvererbung. Anschließend werden Transformation Units vorgestellt, die die Anwendung mehrererRegeln (und anderen Trannsformation Units) in einer festgelegten Reihenfolge definieren. Dadurchkann die Anwendung dieser Regeln so zusammengefasst werden, dass die Transformation Unit einerRegelanwendung entspricht. Das ist insbesondere dann notwendig, wenn die Sprache Ausdrücke ent-hält, die nicht mit einer einzelnen Regel erzeugt werden können. Dann würde eine Regelanwendung einElement als Ergebnis haben, das nicht in der Graphsprache enthalten ist. Der hier verwendetet Graph-transformationsansatz verlangt jedoch, dass nach jeder Regelanwendung ein Element der Graphspracheerzeugt wurde. Bei der Spezifikation der VOCL in Kapitel 5 wird getypte attributierte Graphtrans-formation mit Knotentypvererbung verwendet, um die Regeln und den Typgraphen zu definieren. Aufdiesem Graphtransformationsansatz werden Transformation Units definiert.

2.6.1 Getypte attributierte Graphtransformation

Knoten und Kanten eines Graphen können getypt und attributiert sein, wobei Attribute durch einenTyp, Namen und Wert spezifiziert sind. Jeder Graphknoten bzw. jede Graphkante kann mehrere At-tribute haben. Graphregeln beschreiben Graphtransformationen und bestehen aus einer linken undeiner rechten Seite (jeweils ein Graph). Die Graphen, die in den Regeln vorkommen sind getypt undattributiert; die linke Seite kann Variablen enthalten, um von konkreten Attributwerten abstrahierenzu können. Zwischen der linken und der rechten Seite einer Regel gibt es einen partiellen Graph-Morphismus L → R. Welche Objekte aufeinander gemappt werden, wird durch die Nummerierungder Objekte in den Regeln dargestellt (gleiche Nummerierung auf der linken und rechten Seite heisstgleiches Objekt). Diese Teile bleiben bei der Graphtransformation erhalten. Sie fungieren als positiveAnwendungsbedingungen und beschreiben den erforderlichen Kontext. Die neu erstellten Objekte derrechten Regelseite werden in diesen Kontext eingebettet. Alle nicht nummerierten (gemappten) Objek-te des Graphen der linken Regelseite werden bei der Regelanwendung gelöscht, die nicht nummeriertenObjekte der rechten Seite werden neu erstellt. Regeln können Parameter enthalten, um die Matchesund Attribute der Graph-Objekte durch den Benutzer definieren zu lassen. Eine Regel kann negativeAnwendungsbedingungen (NACs) haben, die ausdrücken, dass etwas nicht existieren darf, damit dieRegel angewendet werden kann. Eine NAC enthält wie die linke und rechte Seite einen Graphen, diegematchten Objekte (l: L -> NAC) sind wieder nummeriert. Eine Regel wird auf einen Graphen Gangewendet, indem zuerst ein Match m: L → G von der linken Regelseite in den Graphen gesuchtwird. Ein Match ist ein totaler Graph-Morphismus, d.h. jedes Objekt des Graphen in L wird in Geingebettet. Im allgemeinen kann es mehrere oder keine Matches geben. Gibt es keine, dann ist dieRegel auf G nicht anwendbar. Eine Regel ist anwendbar (mit einem bestimmten Match), wenn auchalle NACs und weiteren Attributbedingungen erfüllt sind. Eine NAC ist in Bezug auf ein gegebenesMatch m: L → G erfüllt, wenn es keinen totalen Morphismus n: N → G gibt, so dass irgendein Objektaus L, das von l und n gemappt wurde, durch m auf dasselbe Objekt gemappt wird. Im zweiten Schrittwird der gematchte Teilgraph, der für die linke Seite gefunden wurde, aus dem Graphen entfernt unddurch die rechte Seite der Regel ersetzt. Wenn der Match ein totaler Morphismus ist, hat jedes Ob-jekt o der linken Seite L genau ein Bild-Objekt m(o) in G. Wenn o ein Bild r(o) in R hat, wird daskorrespondierende Objekt in G während der Transformation erhalten, ansonsten gelöscht. Objekte inR, die kein Bild eines Objektes in L sind, wurden während der Transformation erstellt. Die Objektedes Graphen, die durch das Match nicht abgebildet werden, werden durch die Regelanwendung nichtverändert, sie beschreiben den Kontext, der während der Transformation erhalten bleibt. Neben der


Manipulation von Knoten und Kanten eines Graphen kann eine Regel auch Veränderungen der Ob-jektattribute durchführen. Da der verwendete Ansatz dies nicht benutzt, wird hier nicht näher daraufeingegangen.

2.6.2 Getypte attributierte Graphtransformation mit Knotentypvererbung

Im folgenden Abschnitt werden die konzeptionellen Grundlagen von getypter attributierer Graphtrans-formation mit Knotentypvererbung aus [7] beschrieben. Diese bilden die Basis für die Definition derabstrakten Syntax der VOCL mit dem Graphgrammatik-Ansatz im Kapitel 5.Der erste Teil bezieht sich auf Typ- und Instanzgraphen, die um das Konzept der Vererbung erweitertwurden; im zweiten Teil wird die Vererbung in die Graphgrammatik übertragen.

Typ- und Instanzgraphen

Zur Spezifizierung von Knotentyphierarchien wird eine spezielle Art von Kanten, sog. Hierarchiekan-ten, in Typgraphen eingefügt. Eine Hierarchiekante geht vom Subtypen zu seinem Supertypen. DieKnoten des Typgraphen können konkret oder abstrakt sein, während in Hostgraphen (Graphen, aufdie die Regeln angewendet werden) nur konkrete Knoten auftreten dürfen. Die Regeln können sowohlabstrakte als auch konkrete Knoten enthalten.

Typgraph mit Vererbung

Ein Typgraph mit Vererbung besteht aus einem Typgraphen (mit Knoten, Kanten und Quell- undZielfunktionen von Kanten nach Knoten), einem Vererbungsgraphen und einer Menge von abstraktenKnoten. Der Vererbungsgraph hat dieselben Knoten wie der Typgraph und enthält die Hierarchiekan-ten, die die Sub- bzw. Supertypen zuordnen. Für jeden Knoten gibt es einen Vererbungs-Clan. Dieserenthält alle Knoten, zu denen es einen ’Hierarchie-Pfad’ gibt, also alle Knoten, von denen er erbt bzw.Subknoten ist. Die Hierarchiekanten dürfen keine Zykel bilden, d.h. die Knoten können nicht von sichselbst erben.

Abschluss eines Typgraphs mit Vererbung

Typgraphen mit Vererbung können zu gewöhnlichen Typgraphen flachgeklopft werden. Dabei werdenfür jede Kante, die an abstrakten Knoten beginnt bzw. endet, Kanten hinzugefügt, die an den kon-kreten Subknoten beginnen bzw. enden und dieselbe Bezeichnung haben. Also von jedem konkretenSubknoten der Quelle einer Kante (also eines abstrakten Knotens) wird zu jedem Subknoten (und demabstrakten Knoten selbst) des Ziels der Kante eine Kante mit derselben Beziehung eingefügt. Danacherhält man den abstrakten Abschluss des Typgraphen (siehe Abb.2.12, Abb.2.13). Aus diesem kann derkonkrete Abschluss gebildet werden, indem alle abstrakten Knoten sowie die Kanten in oder aus diesenaus dem Graphen entfernt werden (Abb.2.14).

Der Typgraph in Abb.2.12 enthält zwei abstrakte Klassen, Classifier und Feature. Von Classifier erbenzwei konkrete Klassen Class und DataType, von Feature erbt eine Klasse Operation. Classifier habenFeatures, was durch die Kante feature dargestellt wird, und Classifier können die Generalisierunganderer Classifier sein. Operationen haben einen Ergebnis-Parameter, dessen Typ ein Classifier ist.


generalization

Class DataType

feature

Operation

resultParam

type Classifier Feature

Parameter

Abb. 2.12: Beispiel für einen Typgraph mit Vererbung

generalization

Class DataType

feature

Operation

generalization generalization

generalization generalization

generalization

generalization feature

feature feature

feature

resultParam

Classifier Feature

Parameter

Abb. 2.13: abstrakter Abschluss des Beispielgraphen

Class DataType Operation generalization generalization

generalization

generalization feature

feature

resultParam type type

Parameter

Abb. 2.14: konkreter Abschluss des Beispielgraphen

Die linke Seite (L) und rechte Seite (R) von abstrakten Regeln sind über den abstrakten Abschlussdes Typgraphen mit Vererbung getypt, da abstrakte Regeln abstrakte und konkrete Knoten enthal-ten können. Gewöhnliche Hostgraphen und konkrete Regeln enthalten keine abstrakten Knoten undsind somit über den konkreten Abschluss des Typgraphen mit Verebung getypt. Da eine kanonischeInklusion vom konkreten Abschluss in den abstrakten Abschluss eines Typgraphen existiert, sind al-le Graphen, die über den konkreten Abschluss getypt sind, auch über den abstrakten Abschluss getypt.

Instanzgraph eines Typgraphs mit Vererbung

Es gibt abstrakte und konkrete Instanzgraphen. Ein abstrakter Instanzgraph ist ein Instanzgraph desabstrakten Abschlusses, es gibt eine Abblidung type vom abstrakten Instanzgraphen in den abstraktenAbschluss. Analog ist ein konkreter Instanzgraph des Typgraphen über den konkreten Abschluss getypt.Der Instanzgraph kann durch zwei Funktionen über den Typgraph mit Vererbung getypt werden, dieeine weist jedem Knoten einen Knotentyp zu, die andere jeder Kante einen Kantentyp. Es gibt einMapping, das als Clan-Morphismus definiert wird, welches den Typmorphismus in den flachgeklopftenTypgraphen charakterisiert.


G E

G N

TG E

TG N

s G t G s T G t T G

type’ N

type’ E

Abb. 2.15: Clan-Morphismus

Clan-Morphismus

Ein Clan-Morphismus besteht also aus zwei Abbildungen. Die eine muss jedem Knoten aus G einenKnotentyp aus TG zuweisen, die andere jeder Kante aus G einen Kantentyp aus TG. Dann muss zujeder Kante aus G gelten, dass sie auf einen Kantentyp abgebildet wird, dessen Quellknotentyp aus demVererbungs-Clan des Knotentyps stammt, auf den der Quellknoten abgebildet wird. Dasselbe muss fürdie Zielknoten gelten. D.h. die Knoten dürfen nur auf abstrakte Knoten, von denen sie erben, abge-bildet werden. Und es darf in G keine Kante geben, zu der es keine Kante zwischen ihren konkretenTypen oder zwischen den entsprechenden abstrakten Supertypen gibt.

Typverfeinerung

Der Begriff der Typverfeinerung wird eingeführt, um die Beziehung zwischen abstrakten und konkretenRegeln auszudrücken. Er definiert eine Ordnung über den möglichen Typmorphismen eines Instanzgra-phen. Ein Typmorphismus ist feiner als ein anderer, wenn er den Knoten des Instanzgraphen konkretereKnotentypen zuordnet. type′ heisst feiner als type, geschrieben type′ ≤ type

Den vorgestellten Formalismus kann man für Graphen und Graphtransformation mit Knotenattribu-ten, die sich nicht ändern, verwenden. Wenn ein Knotentyp zusätzlich Attribute hat, müsste ein vonihm erbender Knoten auch die Attribute erben. Dafür müsste der Formalismus um Knotenattributeerweitert werden.

Regeln und Produktionen

Transformationen von Graphen werden durch Graphregeln beschrieben. Das im folgenden beschriebeneKonzept verwendet den Doppel-Pushout-Ansatz für Graphtransformation. Es werden abstrakte Regelnerlaubt, welche abstrakte Knoten enthalten. Eine abstrakte Regel repräsentiert eine Menge von konkre-ten Regeln, deren Struktur sehr ähnlich ist. Die konkreten Regeln zu einer abstrakten Regel erhält mandurch die Kombination aller Ersetzungen der abstrakten Knoten auf der linken Seite der Regel durchkonkrete Subtypen. Die Knoten auf der rechten Seite werden dann durch denselben konkreten Subtypersetzt. Die Knoten, die auf der rechten Seite der Regel neu hinzugefügt werden, müssen konkret sein,da die Hostgraphen nur konkrete Knoten enthalten dürfen (sie sind über den konkreten Abschluss ge-typt). Konkrete Regeln haben die gleiche Struktur wie die abstrakte Regel, aber ihre Typ-Morphismensind feiner und konkrete Clan-Morphismen.

Abstrakte und konkrete Regeln

Abstrakte Regeln bestehen aus einer linken Regelseite L, einer rechten Regelseite R und einem Kle-begraphen K, einem Tripel von Clan-Morphismen typeL: L → TG, typeK : K → TG, typeR: R →TG, und einer Menge NAC von Tripeln nac = (N, n, typeN ), wobei N ein Graph ist, n: L → N eininjektiver Graphmorphismus und typeN N → TG ein Clan-Morphismus. Die Knoten bzw. Kanten des


Klebegraphen haben dieselbe Typisierung wie die Knoten der linken bzw. rechten Regelseite, auf diesie durch l bzw. r gematcht werden. Ähnliches gilt für die linke Seite und die Graphen N der NACs,die Knoten der linken Seite haben eine feinere Typisierung als die Knoten aus N, auf die die Knotender linken Seite gematcht werden.Das gleiche gilt für die konkreten Regeln, nur dass deren Typisierung immer feiner oder gleich der Ty-pisierung ihrer abstrakten Regel ist. D.h., die konkreten Regeln zu einer abstrakten haben die gleicheStruktur, aber die Typen ihrer Knoten und Kanten sind immer konkret.

N

TG

type N type L type K

type R t Ni t L

t R t K

L R K r l n

Abb. 2.16: konkrete und abstrakte Regel

Die Grundidee von abstrakten Regeln ist die Anwendung einer ihre konkreten Ausprägungen. DerHostgraph und die konkrete Regel sind durch konkrete Clan-Morphismen getypt, so dass die Anwen-dung einer konkreten Regel definiert werden kann.

Anwendung von konkreten Regeln

Eine konkrete Regel wird auf einen Graphen angewendet, indem zuerst ein Graph-Morphismus m :L → G von der linken Seite in den Graphen und ein konkreter Clan-Morphismus typeG: G → TGgesucht werden, so dass typeG ◦ m = tL ist. Außerdem muss G die NACs erfüllen, d.h. es gibt keinenMorphismus o: N → G vom Graphen einer NAC N in den Graphen G, so dass o ◦ n = m (also keinObjekt der linken Seite wird durch o und n auf dasselbe Objekt wie von m gematcht), wobei gilt, dasstypeG ◦ m feiner ist als typeN (Gibt es eine solche NAC, so ist die Regel nicht anwendbar). Dannwird der gematchte Teilgraph, der für die linke Seite gefunden wurde, aus dem Graphen entfernt unddurch die rechte Seite der Regel ersetzt, wie im ersten Abschnitt beschrieben.Die Anwendung einer konkreten Regel ergibt einen konkreten direkten Produktionsschritt.

N

TG

t Ni t L t R t K

L R K

G

type G

r l n

o m

Abb. 2.17: Anwendung einer konkreten Regel


Anwendung von abstrakten Regeln

Eine abstrakte Regel wird auf einen Graphen angewendet, indem zuerst ein Graph-Morphismus m :L → G von der linken Seite in den Graphen und ein konkreter Clan-Morphismus typeG: G → TGgesucht werden, so dass typeG ◦ m ≤ typeL ist. typeL kann also auf abstraktere Knoten- bzw.Kantentypen abbilden als typeG bzw. typeG ◦ m. Außerdem muss G die NACs erfüllen, d.h. es gibtkeinen Morphismus o: N → G vom Graphen einer NAC N in den Graphen G, so dass o ◦ n = m (d.h.,kein Objekt der linken Seite wird durch m auf dasselbe Objekt wie von o und n gematcht), wobei gilt,dass typeG ◦ m feiner ist als typeN (Gibt es eine solche NAC, so ist die Regel nicht anwendbar). Dannwird der gematchte Teilgraph, der für die linke Seite gefunden wurde, aus dem Graphen entfernt unddurch die rechte Seite der Regel ersetzt, wie im ersten Abschnitt beschrieben. Da die rechte Seite einerabstrakten Regel nur konkrete Knoten hinzufügt, entsteht wieder ein Hostgraph (der nur konkreteKnoten enthält), auf den weitere Regeln angewendet werden können.Die Anwendung einer abstrakten Regel ergibt einen abstrakten direkten Produktionsschritt.

N

TG

L R K

G

type G

r l n

o m

type N type L type K

type R

Abb. 2.18: Anwendung einer abstrakten Regel

In [7] wurde gezeigt, dass die Anwendung von abstrakten und konkreten direkten Produktionsschrittenäquivalent ist. Ein Beweis dieser Aussage ist ebenfalls in [7] nachzulesen.Das ermöglicht die Verwendung von abstrakten Regeln zur Modellmanipulation anstelle der Generie-rung und Speicherung aller konkreten Regeln, d.h. abstrakte Produktionen sind effizienter als konkreteProduktionen. Es können also effizientere Prozeduren verwendet werden und es wird sichergestellt,dass das Ergebnis dasselbe ist wie bei der Anwendung konkreter Regeln in der klassischen Theorie.Zudem sind Graphsprachen, die durch abstrakte Regeln und Mechanismen erstellt wurden äquivalentzu Graphsprachen, die durch eine zugehörige Menge konkreter Regeln erzeugt wurden. Im allgemeinenbilden die Regeln mit einem Startgraphen eine Graphgrammatik, welche eine Graphsprache erzeugt.

Die folgenden Abbildungen stellen eine abstrakte Regel und die konkreten Regeln zu dieser dar. Dieabstrakte Regel definiert das Einfügen einer Operation zu einem Classifier, welcher eine Class oder einDataType sein kann.

L R

InsertOperation(opname: String)

NAC = R

1: Classifier 1: Classifier

feature Operation name=opname

Abb. 2.19: Beispiel für eine abstrakte Regel


L R


NAC = R

1: Class 1: Class


Abb. 2.20: konkrete Regel

L R


NAC = R

1: DataType 1: DataType


Abb. 2.21: konkrete Regel

2.6.3 Transformation Units

Wenn man getypte attributierte Graphtransformation verwendet, muss der Ergebnisgraph nach jederRegel ein Element der Graphsprache sein. Die Navigationsausdrücke der VOCL sind jedoch so komplex,dass sie aus mehreren nacheinander auszuführenden Regeln bestehen, deren Ergebnisse keine Elementeder Graphsprache sind. Deshalb werden Transformation Units zum Erzeugen solcher Navigationsaus-drücke verwendet. Transformation Units strukturieren ein System von Regeln in Teilkomponenten, dieeinander verwenden können. Innerhalb einer Transformation Unit können andere Transformation Unitsaufgerufen werden, wofür der Name der verwendeten Unit benutzt wird.

Eine Transformation Unit besteht aus einem Import-Teil, einer Spezifikation von initialen Graphen,einer Menge von lokalen Regeln, einer Kontrollbedingung und einer Spezifikation von terminalen Gra-phen und wird auf einem Graphtransformationsansatz definiert.Ein Graphtransformationsansatz ist ein System A=(G, R, ⇒, C, E) mit

• einer Klasse G von Graphen

• einer Klasse R von Regeln

• einem Regelanwendungsoperator ⇒, der eine binäre Relation ⇒r G X G für jede Regel r beschreibt

• einer Klasse C von Kontrollbedingungen, so dass jedes C ∈ C eine binäre Relation SEME(C) ⊆G X G für jedes Mapping E: ID →

• einer Klasse E von Graphausdrücken, so dass jedes X ∈ E eine Menge SEM(X) ⊆ G spezifiziert

Formal besteht eine Transformation Unit aus:

• einem Ausdruck I, welcher eine Menge von Graphen SEM(I) als Input der Unit definiert

• einem Ausdruck T, welcher eine Menge von Graphen SEM(T), die als Output von der Unitproduziert werden, definiert

• einer Menge R von Regeln

• einer Kontrollbedingung C, die eine binäre Relation SEM(C) auf Graphen beschreibt und

• einer Menge U von importierten Transformation Units, repräsentiert durch eine Menge vonIdentifikatoren


Semantisch spezifiziert eine Transformation Unit eine binäre Relation von initialen KonfigurationenSEM(I) zu terminalen Konfigurationen SEM(T). Ein Graph G ∈ SEM(I) kann in einen Graphen G’∈ SEM(T) durch Anwendung der Regeln aus R oder Aufrufe von anderen Transformation Units ausU transformiert werden. Diese Anwendungen bzw. Aufrufe werden durch die Kontrollbedingung Cgesteuert. C wird durch Ausdrücke über Regeln, die im folgenden beschrieben werden, spezifiziert.Ein Regelausdruck E wird über einer festen Menge von Operatoren aufgebaut und spezifiziert eineMenge von Sequenzen von Regelnamen, seq(E). Wenn man die Regeln in der durch die Sequenz ge-gebene Reihenfolge anwenden kann, dann heisst die Sequenz anwendbar auf den Graphen G und derGraph wird transformiert. Ein Regelausdruck ist auf einen Graphen anwendbar, wenn alle Sequenzenin seq(E) auf den Graphen anwendbar sind. Sei Names eine Menge von gegebenen Regelnamen, ausdenen Regelausdrücke aufgebaut werden können. Ein Regelausdruck E ist ein Term, der durch diefolgende Syntax aufgebaut werden kann:

- Basisoperatoren:E ::== Names | E1 and E2 | E1 or E2 | E1 ; E2 | a(E ) | na(E ) |null | if E1 then E2 else E3 | while E1 do E2 end

- Abgeleitete Operatoren:E ::== E1 implies E2 | E1 xor E2 | asLongAsPossible E end

Die Menge der Regelausdrücke über Names wird mit Expr(Names) bezeichnet. Die abgeleiteten Ope-ratoren können durch die Basisoperatoren ausgedrückt werden.Kurze Beschreibung der formalen Semantik:Eine Regelmenge E definiert eine Menge seq(E) von Sequenzen, die eine erlaubte Ordnung auf Regelan-wendungen spezifiziert. Bevor beschrieben wird, wie seq(E) aus E generiert wird, wird eine Funktionrule: Seq(Names) → ℘(Rules) definiert, wobei Seq(Names) die Menge aller Sequenzen s= (p1, p2, ..., pn)mit Regelnamen pi ∈ Names und ℘(Rules) die Potenzmenge von Rules ist. Die Funktion mappt ei-ne Sequenz in die Menge der Regeln, welche alle sequentiellen Kompositionen von Regeln aus dengegebenen Regeln enthält. Zwei aufeinander folgende Regeln p1: L1 → R1 und p2: L2 → R2 einerSequenz werden sequentiell komponiert, indem die gemeinsamen Objekte in R1 und L2 miteinanderidentifiziert werden, wobei ein beliebiges Überlappen von R1 und L2 möglich ist. Es wird gefordert,dass die Output-Parameter von R1 mit den Inputparametern von L2 identifiziert werden, wenn sie inp2 verwendet werden. So ergibt eine Sequenz eine Menge von komponierten Regeln. Die Generierungvon Sequenzen für einen Regelausdruck ist eine Sequentialisierung in dem Sinne, dass jede möglicheVerzweigung eines Operators mit einer einzelnen Sequenz assoziiert wird (z.B. eine Sequenz für denthen-Teil, eine Sequenz für den else-Teil beim if-then-else-Operator). Nun wird induktiv eine Funktionseq: Expr(Names) → ℘(Seq(Names)) definiert. Jedem Ausdruck wird eine Menge von Sequenzen zu-geordnet, die die erlaubten Sequenzen von Regelanwendungen repräsentieren.Ein einzelner Name p ∈ Names definiert eine Sequenz seq(p)=(p). Die Sequenzen für E1 and E2

werden durch Amalgamierung von Regeln konstruiert, d.h. seq(E1 and E2) = (p1 + p2 | pi ∈rule(seq(Ei)), i = 1, 2), wobei + die disjunkte Vereinigung von Regeln ist. Die Menge der Sequenzenfür den E1 or E2 Ausdruck ist seq(E1 or E2) = s1 ◦ s2 | s1 ∈ seq(E1), s2 ∈ seq(E2). Der anwendbar-Operator a(E ) wird auf eine identische Regel idL reduziert, bei der die linke Seite mit der rechten Seiteeiner Regel aus rule(seq(E)) übereinstimmt, d.h. seq(a(E)) = (idL) | p : L → R ∈ rule(seq(E)). DasAuswerten dieses Ausdrucks verändert den Graphen nicht, ergibt aber true, wenn ein Match für L imGraphen existiert, ansonsten false. Der nicht-anwendbar-Operator na(E ) wird zu einer leeren Regelmit einer NAC für jede Regel in rule(seq(E)). Die NAC verbietet die linke Seite der Regel. Die leereRegel mit Anwendungsbedingungen für E wird mit ∅E bezeichnet, so dass seq(na(E)) = (∅E). Auchdieser Operator verändert den Graphen nicht und ergibt true, wenn ein Match für die NAC existiert,ansonsten false. Die Sequenz für den null-Operator ist die leere Sequenz λ, seq(null) = λ. Die Mengevon Sequenzen für den Ausdruck if E1 then E2 else E3 ist die Vereinigung von

- allen Sequenzen (p1, p2) mit p1 ∈ rule(seq(a(E1))) und p2 ∈ rule(seq(E2))und

- allen Sequenzen (p1, p3) mit p1 ∈ rule(seq(na(E1))) und p3 ∈ rule(seq(E3))


Die erste Menge beschreibt den Fall, in dem E1 anwendbar ist, die zweite Menge den Fall, in dem E1

nicht anwendbar ist. Die Menge der Sequenzen für while E1 do E2 end enthält alle Sequenzen (p, q,p, q,...,p’) mit p ∈ rule(seq(a(E1))), q ∈ rule(seq(E2)) und p’ ∈ rule(seq(na(E1))). Diese Definitionenstammen aus [8].

Bei dem in dieser Arbeit verwendeten Graphtransformationsansatz sind

• G=E die Menge aller attributierter, getypter Graphen mit Knotentypvererbung

• R die Menge aller attributierter, getypter Regeln mit Knotentypvererbung, d.h., R enthält kon-krete und abstrakte Regeln (wie in Abschnitt 2.6 beschrieben)

• r sind Double-Pushout-Regeln mit NAC (negativen Anwendungsbedingungen), die Regeln könnenauf der linken Seite und in den NACs abstrakte Knoten enthalten (siehe Abschnitt 2.6). DieRegeln werden dann auch entsprechend der Beschreibung in Abschnitt 2.6 angewendet

• Die Kontrollbedingungen, die in der VOCL-Spezifikation in Kapitel 5 verwendet werden, sind:or, xor, asLongAsPossible, ;, * und ?

Es folgt ein Beispiel einer einfachen Transformation Unit. Diese verwendet zwei Regeln InsertOperationund InsertOperationResultParameter, die eine Operation als Eigenschaft eines Classifiers und einenErgebnis-Parameter von einem bestimmten Typ zu einer Operation einfügen.

L R


NAC = R

1: Classifier 1: Classifier


Abb. 2.22: Einfügen einer Operation zu einem Classifier

L R

InsertOperationResultParameter(paramname: String, typeName:String)

NAC = R

1: Classifier name=typeName

resultParameter

2: Operation

2: Operation

: Parameter name=paramname

1: Classifier name=typeName

type

Abb. 2.23: Einfügen des Ergebnisparameters einer Operation

Die beiden Regeln müssen nacheinander angewendet werden, d.h., es darf keine Operation ohne einenErgebnisparameter geben.

InsertOperationWithResultParam

InsertOperation(on) ; InsertOperationParameter(pn, tn) ;

Abb. 2.24: eine einfache Transformation Unit


Kapitel 3

Beschreibung der VOCL

3.1 Visuelles OCL

Die visuelle OCL (VOCL) ist eine grafische Repräsentation der zuvor beschriebenen Sprache OCL.Das Ziel der Definition der VOCL ist, den im Kapitel 2 beschriebenen Nachteil der rein textuellenDarstellung von OCL Constraints zu beseitigen. Die VOCL ist stark an die Notation der UML an-gelehnt und nutzt deren grafische Repräsentation. Daraus resultieren Vereinfachungen und ggf. einedirekte Einbindung in UML Diagramme. Wie OCL ist die VOCL eine formale, streng typisierte undobjektorientierte Sprache und bietet gegenüber OCL den Vorteil, dass der Anwender nicht eine weiteretextuelle Sprache erlernen muss. Die Visualisierung ist soweit wie möglich an die von UML angelehnt,es wurden viele Konstrukte übernommen. Wenn neue Visualisierungen notwendig waren, wurde denEmpfehlungen des UML Standards gefolgt und z.B. neue Farben und spezielle Schriftarten zum Aus-drücken semantischer Bedeutungen vermieden.Die Anwendung von UML und OCL soll durch die Definition einer Visualisierung von OCL vereinfachtwerden.In diesem Kapitel wird die VOCL anhand von Beispielen beschrieben. Anhang A enthält die Standard-bibliothek, in der alle Operationen visualisiert sind. Deshalb beinhaltet dieses Kapitel nicht jede derOperationen, die die VOCL zur Verfügung stellt.

3.2 Allgemeine Darstellung eines Constraints

Ein Constraint besteht aus zwei Teilen, die durch eine Linie voneinander abgetrennt sind.Der obere Teil (Kontext-Teil) beinhaltet die Angaben über den Kontext des Constraints. Der Kon-textteil enthält nur Text, dieser besteht aus dem Schlüsselwort context, der Constraintvariable, demKontext (eine Klasse oder Operation), der Art des Constraints (inv, pre, post oder def ) und einemNamen. Die Definition des Namens und der Constraintvariablen sind optional.Der untere Teil (Body) enthält die Darstellung des Constraints. Dieser kann einen Bedingungsteil ent-halten, welcher dann durch eine gestrichelte Linie abgetrennt wird. Im Bedingungsteil können Aussagenüber Variablen, die im Body definiert wurden, gemacht werden.

Abb. 3.1: prinzipielle Darstellung eines Constraints

39

40 KAPITEL 3. BESCHREIBUNG DER VOCL

3.3 Beispiel Klassendiagramm

Die folgenden VOCL-Ausdrücke beziehen sich auf das UML-Klassendiagramm in Abbildung 3.2.

Bank

accountNumber: Integer

0..1

isMarried: Boolean isUnemployed: Boolean birthDate: Date age: Integer firstName: String lastName: String sex: Sex

Person

income(Date): Integer giveSalary(Integer)

customer

name: String numberOfEmployees: Integer

Company

stockPrice(): Real getMoney(amount)

manager managedCompanies

1 0..*

employee employer

0..* 0..*

title: String startDate: Date salary: Integer

Job wife

husband

0..1

0..1

place: String date: Date

Marriage

<<enumeration>> Sex male

female

Abb. 3.2: UML KLassendiagramm

3.4. ATTRIBUTE UND METHODEN 41

Die Hauptklassen des UML Klassendiagramms sind Personen (Person) und Firmen (Company). Per-sonen arbeiten in Firmen und führen in diesen Jobs (Assoziationsklasse Job) aus. Eine Firma wird voneiner Person, dem Manager, geleitet. Außerdem können Personen andere Personen heiraten (Assozia-tionsklasse Marriage) und Konten bei Banken haben.

Im folgenden wird zu jedem Constraint zunächst die textuelle Definition in OCL und danach seinevisuelle Repräsentation in VOCL dargestellt.

3.4 Attribute und Methoden

Die einfachsten Constraints beinhalten Aussagen über Attributwerte oder Rückgabewerte von Metho-denaufrufen. Diese Attribute bzw. Methoden beziehen sich immer auf Instanzen von Klassen. EineKlasseninstanz wird wie in UML dargestellt.Der Constraint in Abbildung 3.3 ist eine Invariante, die für die Klasse Company gilt. Eine Firma hatmehr als 50 Mitarbeiter.Im Body ist eine Klasseninstanz und ihr Attribut numberOfEmployees dargestellt. Die Instanz hatden Namen self. Dies ist eine Variable, die wie in OCL verwendet wird und immer eine Instanz desKontextes ist. Bei dieser Instanz beginnt der Constraint. Wenn es genau eine Instanz vom Typ desKontextes gibt, kann self auch weggelassen werden. Dann beginnt der Constraint an dieser Instanz.Im Beispiel wird der Attributwert mit einer Konstanten verglichen.

• context Company inv: self.numberOfEmployees > 50

context Company inv:

self: Company

numberOfEmployees > 50

Abb. 3.3: Attributwerte

Die Constraint in Abbildung 3.4 beschreibt dasselbe, hat aber eine Constraintvariable mit Namen cund einen Constraintnamen (enoughEmployees). Wird eine Constraintvariable im Kontextteil definiert,wird diese im Body anstelle von self verwendet; der Constraint beginnt also an dieser Variablen.


• context c:Company inv enoughEmployees : c.numberOfEmployees > 50

context c: Company inv enoughEmployees:

c: Company

numberOfEmployees > 50

Abb. 3.4: Attributwerte

Der Constraint in Abbildung 3.5 beschreibt eine Nachbedingung der Operation income, die auf derKlasse Person definiert ist. Im Body ist eine Klasseninstanz (self ) und der Operationsaufruf dargestellt.Ein Operationsaufruf mit einem primitiven Rückgabetyp wird durch einen Pfeil, der an der Instanzendet, dargestellt, am Pfeil wird der Operationsname und die Argumentliste notiert. Der Rückgabewertwird mit einer Konstanten verglichen. Ist der Kontext eines Constraints eine Operation oder Methode,so ist self eine Instanz der Klasse, auf der die Operation oder Methode definiert ist.Die folgende Nachbedingung sagt aus, dass das Einkommen einer Person gleich 5000 ist.

• context Person::income(d: Date): Integer post: result = 5000

context Person::income(d:Date): Integer post:

self: Person

income(d)=5000

Abb. 3.5: Methodenaufruf

In den bisher dargestellten Constraints wurden die Werte mit Konstanten von primitiven Datentypenverglichen, sie können auch mit Ausprägungen eines Aufzählungstyps verglichen werden:

• context Person inv: sex = Sex::male

3.4. ATTRIBUTE UND METHODEN 43

context Person inv :

self: Person sex = ’male’

Abb. 3.6: Aufzählungstypen

Das obige Beispiel sagt aus, dass jede Person männlich ist.

3.4.1 Zuweisung von Werten an Variablen

Die Attributwerte bzw. Rückgabewerte von Methoden oder Operationen können Variablen zugewiesenwerden, um sie miteinander zu vergleichen.Das Einkommen einer Person ist gleich dem Alter der Person multipliziert mit 1000:

• context Person::income(d: Date):Integer post: income = age * 1000


self:Person

age = x

income(d) = x*1000

Abb. 3.7: Zuweisung an Variablen

Der Vorname und Nachname einer Person sind unterschiedlich:

• context Person inv: firstname 6= lastname


self:Person

lastname = y firstname y =

Abb. 3.8: Zuweisung an Variablen


Die Constraints aus Abbildung 3.7 und Abbildung 3.8 können auch mit Hilfe einer Bedingung darge-stellt werden. Eine Bedingung beinhaltet eine Operation, deren erstes Argument eine Variable ist, diemit einem anderen Wert verglichen wird. Dieser Ausdruck muss erfüllt sein. Dazu werden alle in derBedingung verwendeten Werte zunächst Variablen zugewiesen:


self:Person

age = x

result = income(d)

result = x * 1000

Abb. 3.9: Variablen im Bedingungsteil


self:Person

lastname = y firstname = x

x = y

Abb. 3.10: Bedingungsteil

In Abbildung 3.9 wird die vordefinierte Variable result verwendet, die innerhalb einer Vor- oder Nach-bedingung wie in OCL den Rückgabewert einer Operation oder Methode enthält, wenn es einen gibt.Von daher kann die Zuweisung an die Variable result am Operationspfeil auch weggelassen werden.

3.4.2 Werte vor der Ausführung einer Operation in der Nachbedingung

Auf den Wert eines Attributes eines Objektes vor der Ausführung einer Operation wird mit demAttributnamen gefolgt vom Postfix @pre referiert.Dass sich das Alter einer Person an ihrem Geburtstag um 1 erhöht, wird im folgenden Constraintdargestellt:

• context Person::birthdayHappens() post: age = age@pre + 1

context Person::birthdayHappens() post:

:Person age = age@pre+1

Abb. 3.11: Attributwerte vor der Ausführung einer Operation

3.5. NAVIGATIONEN 45

3.5 Navigationen

3.5.1 Navigation entlang einer Assoziation

Die Navigation entlang einer Assoziation wird (wie in UML) durch einen Link zwischen den Klassenin-stanzen dargestellt. Hierbei werden die Rollennamen der Assoziationsenden verwendet. Wenn eindeutigist, entlang welcher Assoziation navigiert wird, kann der Rollenname weggelassen werden. Abhängigvon den Kardinalitäten der Assoziation kann zu einer Instanz oder zu einer Collection (Set, Bag, Se-quence) navigiert werden. Es können nun Aussagen über die Eigenschaften des Objektes/der Objekte,zu dem/denen navigiert wurde, gemacht werden. Die Navigation beginnt immer beim Objekt self,oder beim Objekt mit dem Namen der Constraintvariablen, oder dem einzigen Objekt vom Typ desKontextes.In Abbildung 3.12 wird entlang der Assoziation manager zu einer Instanz der Klasse Person navigiertund dann ausgesagt, dass der Manager einer Firma nicht arbeitslos ist.

• context Company

inv: self.manager.isUnemployed = false

self: Company


: Person isUnemployeed = false

manager

Abb. 3.12: Navigation zu einer Instanz

Die Navigation entlang der Assoziation employee liefert eine Menge von Instanzen, in diesem Fall einSet von Personen (die Angestellten der Firma).Die Darstellung der verschiedenen konkreten Ausprägungen von Collections werden im Abschnitt 3.6eingeführt. Einfache Operationen auf Collections werden im Abschnitt 3.7.4 behandelt.

self: Company


: Person

employee . . .

Abb. 3.13: Navigation zu einem Set

3.5.2 Navigation zu Assoziationsklassen

Auch die Navigation zu Assoziationsklassen wird wie in UML dargestellt. Wurde im Klassendiagrammkein Rollenname definiert, so kann der kleingeschriebene Klassenname verwendet werden.Der folgende Constraint spezifiziert, dass der Beginn eines Jobs einer Person nach ihrem Geburtsdatumist.

• context Person inv: self.birthDate < self.marriage.date


context Person inv:

:Marriage date = y

: Person self:Person birthDate < y

marriage

Abb. 3.14: Navigation zu Assoziationsklassen

Auch die Navigation zu Assoziationsklassen kann eine Instanz oder eine Collection als Ergebnis haben.

3.5.3 Navigation von Assoziationsklassen

Navigationen können auch an Assoziationsklassen starten. self ist dann eine Instanz einer Assoziati-onsklasse.Der folgende Constraint spezifiziert, dass es zu jedem Job mindestens einen Angestellten gibt, der ihnbearbeitet. Die Navigation startet an der Assoziationsklasse Job.

• context Job inv: self.employer.numberOfEmployees >= 1

context Job inv:

:Person :Company employer

self: Job

numberOfEmployees >= 1

Abb. 3.15: Navigation von Assoziationklassen

3.6. DARSTELLUNG VON COLLECTIONS 47

3.6 Darstellung von Collections

Collection ist ein abstrakter Typ, von dem drei konkrete Typen erben: Set, Bag und Sequence. Diesedrei haben verschiedene grafische Darstellungen, die in der folgenden Tabelle abgebildet sind:

Set:

Bag:

Sequence:

Ein Set enthält eine Menge von Objekten ohne Wiederholungen, ein Bag enthält eine Menge von Ob-jekten mit Wiederholungen, eine Sequence enthält eine Menge von Objekten mit Wiederholungen, diesortiert sind.

Einfache Navigationen resultieren in einem Set,

• context Company inv: self.employee ...

self: Company :Person


employee

...

Abb. 3.16: einfache Navigation

kombinierte Navigationen können ein Bag ergeben,

• context Company inv: self.employee->collect(birthDate) ...


self:Company : Person

collect

employee

x


:Date

:Person birthDate = x

isIn

...

Abb. 3.17: kombinierte Navigation

und Navigationen mit sortedBy ergeben eine Sequence

• context Company inv: self.employee->sortedBy(age) ...

:Person

: Person age = x

x

sortedBy self: Company

employee


...

Abb. 3.18: Navigation mit sortedBy

In Abbildung 3.17 wurde die Operation collect (liefert hier eine Menge von Geburtsdaten), in Abbildung3.18 die Operation sortedBy (sortiert hier die Menge der Personen nach ihrem Alter) verwendet. Diesesind Operationen auf Collections und werden im Abschnitt 3.11 genauer beschrieben.

3.7. VORDEFINIERTE EIGENSCHAFTEN 49

3.7 Vordefinierte Eigenschaften

In OCL gibt es vordefinierte Eigenschaften auf allen Objekten. Diese werden in VOCL wie folgt dar-gestellt:

object: OclAny {New}

Abb. 3.19: Das Objekt wurde neu angelegt

object:OclType

x = oclIsTypeOf(t)

Abb. 3.20: Das Objekt ist vom Typ t

object:OclType

x = oclIsKindOf(t)

Abb. 3.21: Das Objekt ist vom Typ t oder einem von t’s Subtypen

object:OclType OclType

Abb. 3.22: Das Objekt wird in ein Objekt vom Supertyp (der linke Typ) umgewandelt

object: OclState

s

Abb. 3.23: Das Objekt ist im Zustand s

Dass jede Instanz der Klasse Person vom Typ Person ist und nicht vom Typ Company, wird mit dervordefinierten Eigenschaft oclIsTpeOf folgendermaßen spezifiziert:

• context Person inv: self.oclIsTypeOf(Person) = true

and self.oclIsTypeOf(Company) = false


self: Person

oclIsTypeOf(Person)=true

context Person inv:

oclIsTypeOf(Company)=false

self: Person

Abb. 3.24: Vordefinierte Eigenschaft oclIsTypeOf

Im oben dargestellten Constraint wird die Operation and verwendet, die zwei VOCL Ausdrücke durchdie and -Operation miteinander verknüpft. Eine ausführlichere Beschreibung der booleschen Operatio-nen ist im Abschnitt 3.8.

Im folgenden Constraint wird der Zustand eines Objektes dargestellt. Dazu muss es eine entsprechen-de StateMachine geben, die die möglichen Zustände für Objekte einer Klasse definiert. Der Zustandwird unter Namen und Typ des Objekts dargestellt, wo bisher nur Attribute eines Objektes dargestelltwurden. Der Name des Zustands steht innerhalb eines abgerundeten Rechtecks. Wenn es sich um einenUnterzustand handelt, würde dieser innerhalb des übergeordneten Zustands dargestellt, dessen Namedann auch innerhalb eines Rechtecks stehen würde.

• context Person inv: self.oclIsInState(married) implies self.age>=18

and self.married=true

context Person inv:

self: Person age>=18 married=true

self: Person

married

implies

Abb. 3.25: Vordefinierte Eigenschaft oclIsInState


Für das nächste Beispiel wird ein zusätzliches Klassendiagramm benötigt.

ModelElement

*

* source

target

Note value: Uninterprete

d

Dependency

****

Abb. 3.26: Klassendiagramm

Im folgenden Constraint wird die vordefinierte Operation oclAsType verwendet. Diese liefert eine In-stanz des Supertyps, so dass nun die Eigenschaften des Supertyps verwendet werden können. Der Namedes für die weiteren Operationen verwendeten Supertyps wird hinter dem Namen des Instanz (falls sieeinen hat) dargestellt, dann ein Vererbungspfeil und der Name des Subtyps, zu welchen zuerst navigiertwurde.

• context Dependency inv: self.oclAsType(ModelElement).source ...

self: ModelElement Dependency

:ModelElement

source

context Dependency inv:

...

Abb. 3.27: Eigenschaften von Supertypen

In diesem Constraint kann durch das Umwandeln eines Objektes vom Typ Dependency in ein Objektdes Supertyps ModelElement über die Assoziation source des Supertyps navigiert werden.


3.7.1 Eigenschaften von Klassen

Ein Beispiel für eine Eigenschaft, die auf Klassen selbst und nicht auf ihren Instanzen definiert ist, istallInstances. allInstances wird auf die Klasse, die den Kontext des Constraints darstellt, angewendetund liefert das Set aller Instanzen der Klasse zu diesem Zeitpunkt. Der Constraint muss an diesem Setstarten bzw. wenn ein VOCL Constraint an einem Set startet (und nicht bei self oder einer Instanzdes Kontextes), ist dieses das Ergebnis von allInstances.

• context Person inv:

Person.allInstances()->forall(p: Person| p.age >= 10)

A

:Person :Person

context Person inv:

p:Person age > 10

p

isIn

Abb. 3.28: allInstances

Der Constraint in Abbildung 3.28 startet beim Set aller Instanzen der Klasse Person und verwendetdann die Operation forall, welche auf Collections definiert ist und im Abschnitt 3.11.5 beschriebenwird. Für diese Operation gibt es eine Kurzform, die in Abbildung 3.29 dargestellt ist. Der Constraintsagt aus, dass alle Klasseninstanzen ein Alter von mindestens 10 Jahren haben müssen.

A

context Person inv:

:Person age > 10

Abb. 3.29: allInstances mit forall Shortcut


3.7.2 Operationen mit komplexem Rückgabetyp

In Abschnitt 3.4 wurden Methoden bzw. Operationen dargestellt, die einen primitiven Datentyp alsErgebnis liefern. Operationen mit komplexem Rückgabetyp haben folgende allgemeine Darstellung:

obj1: OclAny

opname(a1,...,an)

: OclAny

Abb. 3.30: prinzipielle Darstellung

Auf das Objekt obj1 vom Typ OclAny wird die Operation opname mit den Argumenten a1, ..., anangewendet. Diese liefert eine Instanz vom Typ OclAny. Operationen mit komplexem Rückgabetypkönnen auch Collection als Ergebnis haben.

3.7.3 Vordefinierte Operationen aus der OCL StandardLibrary

Von den zuvor dargestellten Operationen sind die meisten aus der VOCL StandardLibrary. Sie bein-haltet also u.a. Methoden mit einfachen und mit komplexen Rückgabewerten, die vordefinierten Ei-genschaften, die noch folgenden Collectionoperation etc. Die gesamte VOCL StandardLibrary ist imAnhang A dargestellt.Die anderen Operationen sind vom Benutzer im Klassendiagramm definiert worden.

3.7.4 Einfache Operationen auf Collections

Die einfachen Operationen auf Collections sind isEmpty, notEmpty und size. Sie liefern true oder false(je nachdem ob die Collection leer ist oder nicht) bzw. die Anzahl der Elemente, die die Collectionenthält.Die Operation notEmpty (isEmpty) wird durch das Symbol 6= ∅ (= ∅) in Anlehnung an die Überprü-fung einer Menge notiert.Die Operation size wird durch das Zeichen # dargestellt. Zusätzlich kann eine Variable verwendetwerden, die direkt hinter # steht und in der die Anzahl der Elemente steht. Die jeweiligen Zeichenwerden innerhalb einer gestrichelten Box rechts unten am Rand der Darstellung der jeweiligen Collec-tion notiert.Der Constraint in Abbildung 3.31 definiert, dass eine Firma mindestens einen Mitarbeiter hat:

• context Company inv: self.employee->notEmpty()


self: Company


: Person

employee = 0

Abb. 3.31: Die Operation notEmpty

Eine Person hat weniger als 3 Arbeitgeber:

• context Person inv: self.employer->size() < 3

context Person inv:

self: Person

n < 3

:Company employer #n

Abb. 3.32: Die Operation size

Der folgende Constraint spezifiziert, dass eine Person keine Arbeitgeber hat:

• context Person inv: self.employer->isEmpty()

self: Person

context Person inv:

: Company employer

= 0

Abb. 3.33: Die Operation isEmpty

3.8. BOOLESCHE OPERATIONEN 55

3.8 Boolesche Operationen

Zu den vordefinierten booleschen Operationen in OCL zählen and, implies, or, xor und not. Ein VOCLConstraint kann spezifizieren, dass der boolesche Wert, den diese Operationen liefern, true sein muss.

3.8.1 Implies, Or und Xor Ausdrücke

Implies, or und xor Ausdrücke werden durch einen eigenen Rahmen visualisiert, der aus zwei Teilenbesteht. Jeder dieser Teile kann einen eigenen Bedingungsteil haben, in dem Aussagen über Variablen,die in diesem Teil definiert wurden, gemacht werden können.Bei implies beschreibt der obere bzw. linke Teil die Prämisse und der untere bzw. rechte die Konklusion.Die Trennlinie zwischen diesen Teilen ist mit implies beschriftet:

• context Person inv: self.isMarried = true implies self.age >= 18

context Person inv:

self: Person

isMarried = true

implies

self: Person

age >= 18

Abb. 3.34: Ein Implies Constraint

Der Constraint definiert, dass eine Person, die verheiratet ist, mindestens 18 Jahre alt sein muss. Dasses sich in den beiden Teilen des Implies Ausdrucks um dieselbe Person handelt, wird dadurch ausge-drückt, dass die beiden Instanzen denselben Namen haben.

Bei or und xor Ausdrücken stehen die zu “verodernden“ (“verxodernden“) Ausdrücke links und rechtsbzw. oben und unten von der Trennlinie, die mit or bzw. xor beschriftet ist.Der folgende Constraint spezifiziert: Wenn eine Person verheiratet ist, dann ist ihr Ehepartner minde-stens 18.

• context Person inv: self.isMarried = true implies

[(self.wife.age > = 18) or (self.husband.age >= 18)]


context Person inv:

self: Person

isMarried = true

implies

: Person

age >= 18

wife

: Person

husband

or

age >= 18

self: Person self: Person

Abb. 3.35: Ein Or Constraint

3.8.2 And Ausdrücke

Die Operation and wird in VOCL nicht explizit dargestellt. Zwei nebeneinander stehende Ausdrückewerden automatisch durch und miteinander verbunden und müssen beide erfüllt sein.


self.wife->notEmpty() implies self.wife.age >= 18

and self.husband->notEmpty() implies self.husband.age >= 18

3.8. BOOLESCHE OPERATIONEN 57

context Person inv:

self: Person : Person wife

: Person age = x

implies

x >= 18

self: Person : Person husband

implies

y >= 18

= 0

= 0

self: Person wife

: Person age = y

self: Person husband

Abb. 3.36: Verknüpfung durch and

3.8.3 Not Ausdrücke

Dass ein VOCL Ausdruck nicht gilt wird durch einen eigenen Rahmen dargestellt, an dem oben notsteht. Innerhalb des Rahmens wird der Ausdruck visualisiert:

• context Company inv:

not (self.manager.isMarried)


: Person isMarried = true

self: Company manager

not

Abb. 3.37: Ein not Ausdruck


3.9 Let Ausdrücke

Es gibt zwei verschiedene Let Ausdrücke in OCL.Ein Let ohne ein in wird nur innerhalb eines Constraints vom Typ def verwendet und definiert eineVariable, die in allen Constraints zu diesem UML Klassenmodell gültig ist.

• context Person def:

let income : Integer = self.job.salary->sum()

self: Person

context Person def:

x = income

: Company

:Job salary = x

let

income: Integer

Abb. 3.38: Definition Constraint

Der oben dargestellte Let Ausdruck hat einen eigenen Rahmen, der mit let beschriftet ist und in demoben links der Name und der Typ der Variablen stehen, die im folgenden definiert wird. Im Beispiel wirddie Variable income definiert, deren Wert das gesamte Einkommen einer Person ist. Ein Let-Rahmenkann einen eigenen Bedingungsteil enthalten.Ein Let mit einem in definiert eine Hilfsvariable, die nur innerhalb dieses Constraints gültig ist unddann im Ausdruck des in-Teils verwendet wird. Ein Beispiel:


let income : Integer = self.job.salary->sum()

in

if isUnemployed = true

then income < 100

else income >= 100

endif

3.9. LET AUSDRÜCKE 59

self: Person

context Person inv:

income = y

: Company

:Job salary = x

let

if

then else

self: Person isUnemployed = true

income < 100

in

income >= 100

income: Integer

x = y

Abb. 3.39: Let Ausdruck


3.10 If-Then-Else Ausdrücke

Ein If-Then-Else Ausdruck besteht aus drei Teilen. Jeder der Teile kann eine Bedingung enthalten.

if

then else

Abb. 3.40: allgemeiner If-Then-Else Ausdruck

Der folgende Constraint spezifiziert: Wenn eine arbeitende Person verheiratet ist, ist ihr Einkommenmindestens 3000, sonst kleiner als 3000.


if(self.isUnemployed = false and self.isMarried = true)

then income >= 3000

else income < 3000

self: Person isMarried = true isUnemployed = false

if

then else

income >= 3000

context Person inv:

income < 3000

Abb. 3.41: If-Then-Else Constraint

3.11. KOMPLEXE OPERATIONEN AUF COLLECTIONS 61

3.11 Komplexe Operationen auf Collections

Aus Collections gibt es verschiedene Operationen, die eine komplexere Darstellung (im Gegensatz zuden Operationen isEmpty, notEmpty und size) haben. Zum einen die mathematischen Mengenopera-tionen, zum anderen die LoopExpressions.

3.11.1 Mengenoperationen auf Collections

Die Mengenoperationen haben für verschiedene Argumenttypen unterschiedliche Ergebnisse. Im fol-genden Beispiel wird die Vereinigung zweier Sets dargestellt, welche ein Set liefert. Die Typen allerMengenoperationen werden in der VOCL Standard Library (Anhang A auf Seite 247) dargestellt.Die Argumente sind innerhalb des Rahmens und das Symbol der jeweiligen Operation steht in einergestrichelten Box unten rechts am Rahmen. Unten am Rahmen ist ein Pfeil zur Ergebnis-Collection,deren Typ (Set, Bag, Sequence) von der Operation und den Typen der Argument-Collections abhängt.


self.employee.wife->union(self.employee.husband).employer= self


self: Company

employee

: Person

wife

employee

: Person

husband

employer

U

:Person

: Person : Person

Abb. 3.42: Die Vereinigung zweier Sets

Der oben dargestellte Constraint definiert, dass die Ehepartner aller Mitarbeiter einer Firma auch indieser Firma arbeiten.


3.11.2 LoopExpressions

Die folgenden Operationen sind auf Collections definiert und basieren auf einer Iteration über alleElemente, die die Collection enthält. Sie können auf eine Iterate-Operation mit speziellen Iteratorenund Akkumulatoren zurückgeführt werden. Die Darstellungen der verschiedenen Operationen sindsehr ähnlich, es wird ein Iterator und ein Operationsname dargestellt und innerhalb eines gesondertenRahmens die Darstellung des Ausdrucks, der auf die Elemente der Collection angewendet wird.

3.11.3 Select und Reject Operationen

Die Select und Reject Operationen liefern eine Teilmenge der Collection. Die Ergebnis-Collection ent-hält alle Elemente der ursprünglichen Collection, die die Selektionseigenschaften erfüllen bzw. nichterfüllen. Diese Eigenschaften werden innerhalb des Rahmens dargestellt. Aussen rechts unten am Rah-men sind zwei gestrichelte Boxen. Sie enthalten den Operationsnamen (select bzw. reject) und denIterator, wobei der Iterator immer über dem Operationsnamen steht.


self.employee->select(p | p.age > 50)->notEmpty()


self:Company :Person

p:Person age = x

x > 50

employee

p

select

= 0

Abb. 3.43: Eine Select Operation

Im oben dargestellten Constraint werden aus der Menge der Mitarbeiter einer Firma diejenigen selek-tiert, die älter als 50 sind. Der Constraint sagt aus, dass diese Menge nicht leer sein darf, was durcheine Kurzform dargestellt wird. Die Überprüfung auf die leere Menge wird an den Rahmen der SelectOperation notiert. Eine ausführliche Darstellung mit dem Ergebnis der Select Operation wäre:




p:Person age = x

isIn

x > 50

employee

p

select

= 0 :Person

Abb. 3.44: Eine Select Operation


self.employee->reject(isMarried)->isEmpty()



:Person isMarried = x

x = true

employee

= 0

reject

Abb. 3.45: Eine Reject Operation

Diese Reject Operation liefert alle Personen, die nicht verheiratet sind. Der Constraint spezifiziert, dassdie Menge der Angestellten einer Firma, die nicht verheiratet sind, leer ist. Der Iterator ist vom TypPerson, das Attribut isMarried wird überprüft. Wenn der Iterator offensichtlich ist, kann er weggelassenwerden.


3.11.4 Collect Operation

Select und Reject Operationen liefern eine Collection, die den gleichen Typ hat wie die Ursprungs-Collection. Collect liefert eine neue Collection, deren Elemente einen anderen Typ haben.Aus der Menge aller Arbeitnehmer einer Firma wird das Set ihrer Geburtstage gebildet:


self.employee->collect(birthdate)->asSet()

:Date

self:Company :Person birthDate collect

employee


:Date :Date

asSet()

:Date :Date

Abb. 3.46: Eine Collect Operation

In Abbildung 3.46 wird eine Kurzform der Collect-Operation dargestellt. Anstelle eines neuen Rahmenszur Darstellung der Collect-Eigenschaftwerden die beiden gestrichelten Boxen (mit dem Operations-namen collect und dem Iteraor) direkt an der Collection dargestellt. Das ist möglich, wenn sich dieEigenschaften nur auf Attribute beziehen. Im allgemeinen liefert die Collect Operation einen Bag.


3.11.5 Forall Operation

Die Forall Operation definiert einen booleschen Ausdruck, der für alle Elemente einer Collection erfülltsein muss. Sie kann einen oder zwei Iteratoren haben und ihr Ergebnis ist ein boolescher Wert.


self.employee->forall (e1, e2: Person | e1 <> e2 implies

e1.firstname <> e2.firstname)

:Person :Person


e1:Person e2:Person

implies

e1:Person firstname = x

e2:Person firstname = y

A e1 e2

self: Company employee

x = y

<>

Abb. 3.47: Eine Forall Operation

Der Constraint spezifiziert, dass alle Mitarbeiter einer Firma unterschiedliche Vornamen haben.Eine Forall Operation mit zwei Iteratoren ist wie in OCL eine Kurzform für zwei ineinander geschach-telte Forall Operationen.


3.11.6 Exists Operation

Die Exists Operation definiert einen booleschen Ausdruck, der für mindestens ein Element einer Col-lection erfüllt sein muss.


self.employee->exists (p: Person | p.firstname = ´Jack´)

:Person :Person


p:Person firstname = ’Jack’

p


E

Abb. 3.48: Eine Exists Operation

Der Constraint spezifiziert, dass in einer Firma mindestens eine Person mit dem Vornamen Jack ar-beitet.

3.11.7 Sum Operation

Die Sum Operation summiert einen Wert, der innerhalb des Rahmens dargestellt wird und speichertdiesen in einer Variablen, was im folgenden Beispiel durch

∑x=y ausgedrückt wird. Der Wert, der

summiert wird ist x, das Ergebnis der Summation ist y.


self.job.salary->sum() > 50

self:Person

context Person inv:

: Company

y > 50

:Job salary=x x = y

Abb. 3.49: Eine Sum Operation

Dieser Constraint spezifiziert, dass die Summe der Gahälter der Jobs, die eine Person hat, grösser als50 ist.


3.11.8 Iterate Operation

Auch die Iterate Operation hat einen Rahmen, in dem Eigenschaften visualisiert werden, und einenIterator. Hinzu kommt der Akkumulator und die Darstellung seiner Initialisierung. Diese Initialisierungwird in einem eigenen Rahmen dargestellt. Dieser ist links vom Rahmen, in dem die Eigenschaftendefiniert werden. Im folgenden Beispiel ist der Akkumulator eine leere Menge, was durch die OperationisNew() dargestellt wird.


self.employee->iterate (p: Person, acc: Set= Set()|

acc->including(p| p.age > 50))->notEmpty

p

:Person :Person


p:Person age = x


x > 50

acc

iterate

= 0

acc:Person

including(p)

acc:Person {New}

Abb. 3.50: Eine Iterate Operation

Dieser Constraint spezifiziert, dass in einer Firma mindestens ein Mitarbeiter 50 Jahre alt ist. DerselbeConstraint wurde im Abschnitt 3.11.3 mit Hilfe einer Select Operation ausgedrückt.


3.12 Messages

Im folgenden Abschnitt wird die Visualisierung der Message-Operatoren vorgestellt. Der hasSent (ˆ)-Operator drückt aus, dass eine Message zum Objekt gesendet wurde, der ˆˆ-Operator liefert eineSequenz aller Messages, die zum Objekt geschickt wurden.

• context Subject::hasChanged() post: observerˆupdate(12, 14) )

context Subject::hasChanged() post :

: Observer

update(12, 14)

self:Subject

Abb. 3.51: Messages

Während der Ausführung der Operation hasChanged() auf einem Objekt vom Typ Subject, wird eineMessage update zu einem Objekt vom Typ Observer gesendet. Diese Message hat zwei Argumente,12 und 14. Sie ist entweder eine Operation der Klasse Observer oder ein Signal, was im UML Modellspezifiziert wurde. Der dargestellte Ausdruck ist wahr, wenn eine solche Message gesendet wurde.

3.12. MESSAGES 69

• context Subject::hasChanged() post:

let messages : Sequence[OclMessage] = observerˆˆupdate(?:Integer, ?:Integer) in

messages->notEmpty()

context Subject::hasChanged() post :

let

update(?:Integer, ?:Integer)

messages: Sequence[OclMessage]

self: Subject : Observer

messages: OclMessage

in

messages: OclMessage = 0

Abb. 3.52: Messages

Während der Ausführung der Operation hasChanged() liefert der ˆˆ-Operator eine Sequenz aller Mes-sages update mit beliebigen Integern als Parameter, die zum Objekt vom Typ Observer geschicktwurden. Das wird durch mehrere Pfeile, die mit dem Namen der Message und den Argumenten be-schriftet eind, dargestellt. Die Ergebnis-Sequenz wird wie bei einem Methodenaufruf mit komplexemErgebnistyp dargestellt. Die so im Let-Teil definierte Sequenz darf nicht leer sein, was im in-Teil dar-gestellt wird.Angenommen die update ist eine Operation, deren Parameter mit den Namen i und j spezifiziertwurden. Dann kann man diese Parameternamen verwenden, um sie zu referenzieren. So können auchAussagen über die nicht genauer spezifizierten Parameterwerte gemacht werden.


3.13 Tupel

Ein Tupel besteht aus mehreren Elementen verschiedener Typen. Für die Definition eines Tupels gibtes einen eigenen Rahmen, in dem oben links der Name des Tupels und (in eckigen Klammern) dieTypen der einzelnen Tupelelemente stehen. Darunter folgt die Initialisierung der Werte der Tupelele-mente, die pro Element in einem eigenen Rahmen stattfindet. In diesem steht oben links der Name desElements und sein Typ, darunter die Definition.In Abbildung 3.53 wird im Kontext der Klasse Person ein Set von Tupeln mit Namen stats definiert.Ein solches Tupel besteht aus vier Tupelelementen: einer Firma (company), der Anzahl Angestellterin dieser Firma (numEmployees), der Menge der gut bezahlten Angestellten (wellpaidEmployees) unddem Gesamtgehalt (totalSalary), das die Firma zahlt. Zur Initialisierung der Tupelelemente wird zu-nächst von self zur Menge der von der Person gemanageten Firmen navigiert. An dieser Stelle wird dasTupel innerhalb einer collect-Operation definiert. Im collect Rahmen folgt also der Tupel-Rahmen, indem oben links der Name des Tupels steht. Innerhalb dieses Rahmens wird nun für jedes Tupelelementein eigener Rahmen mit der Visualisierung der jeweiligen Initialisierung dargestellt.Das so definierte Set von Tupeln, stats, kann im nächsten Constraint (Abbildung 3.54) verwendetwerden. Dort wird dieses Set aufsteigend nach dem Wert des Tupelelements totalSalary sortiert. DasErgebnis ist eine Sequenz von Tupeln. Auf diese wird die Operation last() angewendet, die das letzteElement der Sequenz liefert, welches im Beispiel ein Tupel ist. Innerhalb dieses Tupels wird nun aufdas Element wellpaidEmployees (ein Set von Personen) die Operation includes mit dem Argument selfaufgerufen. Diese liefert true.Ein Tupel wird in einem Rechteck dargestellt, das oben links einen Namen haben kann. Die ver-schiedenen Tupelelemente können optional innerhalb eines eigenen Rechtecks dargestellt werden. ImNormalfall werden nur die für die Aussagen des Constraints notwendigen Elemente dargestellt.

• context Person def:

attr statistics : Set(TupleType(company:Company, numEmployees: Integer,

wellpaidEmployees: Set(Person), totalSalary: Integer)) =

managedCompanies->collect(c |

Tuple [ company: Company = ,

numEmployees: Integer = c.employee->size(),

wellpaidEmployees: Set(Person) = c.job->select(salary > 10000).employee->asSet(),

totalSalary: Integer = c.job.salary->sum()]

3.13. TUPEL 71

: Person

context Person def:

let

c

stats:{Company, Integer, Set[Person], Integer}

managedCompanies

collect

company: Company = c

numEmployees: Integer = n

c: Company employee #n

wellpaidEmployees: Set[Person] = p

: Job salary = x

x > 10000

p1

isIn

: Person c: Company

: Job salary = x

totalSalary: Integer = x

x

c: Company

isIn

c: Company

employee

select

: Company

: Person

c: Company : Person

: Job

p: Set[Person]

Abb. 3.53: Definition eines Tupels



stats->sortedBy(totalSalary)->last().wellpaidEmployees->includes(self)

sortedBy

totalSalary

context Person inv:

x = true

stats:Tuple

totalSalary

totalSalary

wellpaidEmployees

numEmployees

stats:Tuple

last()

company

x = includes(self)

:Tuple(Company, Integer, Set[Person], Integer)

Abb. 3.54:

Der Constraint spezifiziert, dass der Manager einer Firma in der Firma, die das meiste Gesamtgehaltaller Firmen, die er managt, hat, zu den gutbezahlten Mitarbeitern gehört.

3.14. KOMPOSITION VON CONSTRAINTS 73

3.14 Komposition von Constraints

Ein Constraint kann aus der Komposition von bereits definierten Constraints bestehen. Er spezifi-ziert die Verundung aller Constraints der Komposition. Die innerhalb der Komposition verwendetenConstraints müssen allerdings zuvor mit einem Namen definiert worden sein, über welchen sie in derKomposition referenziert werden. Außerdem müssen sie denselben Kontext haben und von der gleichenArt (z. B. nur Invarianten) sein. Die einzelnen Constraintnamen stehen in eigenen Boxen innerhalb desKompositionsrahmens.Möchte man spezifizieren, dass alle Mitarbeiter einer Firma verschiedene Vornamen haben und einervon ihnen den Vornamen Jack hat, kann das durch die Komposition der folgenden zwei Constraintsausgedrückt werden:

• context Company inv differentFirstnames:

self.employee->forall (e1, e2: Person | e1 <> e2 implies

e1.firstname <> e2.firstname)

:Person :Person

context Company inv differentFirstnames:

e1:Person e2:Person

isIn

implies

e1:Person firstname = x

e2:Person firstname = y

A

e1 e2


isIn

x = y

<>

Abb. 3.55: erster Constraint


• context Company inv oneJack:

self.employee->exists (p: Person | p.firstname = ´Jack´)

:Person :Person

context Company inv oneJack:

isIn

p:Person firstname = ’Jack’

p


E

Abb. 3.56: zweiter Constraint

Der komponierte Constraint:

context Company inv :

differentFirstnames oneJack

Abb. 3.57: komponierter Constraint

Kapitel 4

Spezifikation von VOCL mit dem MOF

Ansatz

In diesem Kapitel wird die VOCL mit dem Metamodellierungsansatz, also einem deklarativen Ansatzzur Definition einer visuellen Sprache, definiert. Die Basis dafür ist das MOF Modell, das in Kapitel 2beschrieben wurde.Mit diesem Ansatz wird die abstrakte Syntax der VOCL durch ein Metamodell (mit Kardinalitäten)und Constraints zu diesem Modell definiert. Das Metamodell wird in UML Notation angegeben, d.h.die Klassen mit Attributen und Methoden, die Assoziationen zwischen zwei Klassen, Assoziationsklas-sen und Kardinalitäten werden wie in einem UML Klassendiagramm dargestellt. Abstrakte Klassenhaben einen kursiv geschriebenen Klassennamen und werden nur für die Vererbung verwendet. Auchdie Vererbung wird wie in UML durch einen Generalisierungspfeil dargestellt.Das Metamodell wurde in vier Teilmodelle unterteilt, was der Übersichtlichkeit und einem schnellerenVerständnis dienen soll.Das erste Teilmodell (Abb. 4.1) beinhaltet Constraints mit Kontext, Bedingungen und Navigationsaus-drücken (die aus Pfaden bestehen). Im zweiten Teil werden die Elemente eines Navigationsausdrucks,also die Knoten (RoleNodes) eines Pfades mit ihren Attributen bzw. Methoden, dargestellt. Das dritteTeilmodell enthält alle anderen Ausdrücke (Let-, If-Then-Else- und Loop-Ausdrücke), die die VOCLerlaubt und die booleschen Operationen (implies, or, xor, not, and). Im vierten Teil sind die Typenund Attribute aller VOCL Modellelemente enthalten. Das gesamte VOCL Metamodell umfasst alsoalle vier Teilmodelle.Es ist ein Metamodell, d.h., es befindet sich auf der M2-Ebene der MOF Architektur.Die Constraints sind in OCL geschrieben.

75

76 KAPITEL 4. SPEZIFIKATION VON VOCL MIT DEM MOF ANSATZ

4.1 Metamodell

NavigationCallExp

Path

Classifier name:String

VariableDeclaration varName:String

SimpleCollectionExp name:SCOEnum

CollectionRole

AssociationRole

constrainedClassifier

constrainedOp

parameter{ordered}

constraintVar

start end node

arnode

participant

variable

resultVar

resultVar

crtmnode

source

return

Parameter name:String kind:PKindEnum

nce

end

sco

Constraint kind:ConstraintKindEnum

Operation

AssociationEndRole

AssociationClassRole

CRTMethod

AllInstancesExp aieStart

resultingSet

classifier

Attribute

attribute

Condition

condition

RoleNode

referredNode

Association

AssociationEnd base

base base

connection

VOCLExp

body

SetRole

ClassifierRole

Classifier

base

0..n

0..1

0..1

1

0..n 0..1

0..1

0..1

1 1

0..n

0..n

0..1

0..1

0..n

1

1

0..1

0..1

0..1

0..1 0..1

0..n 0..n

1

1

0..1

0..n

1

0..n 0..n

1

1

0..n 0..n 1 1

1

AssociationClass

feature 0..n

1

startar endar

start

ConstraintKindEnum inv pre post def

PKindEnum in out inout return

SCOEnum

# = 0 = 0

1

0..n

0..n

0..1

0..n

1

1

0..1

0..n

1

1..n

1

1..n 1

1..n

1..n

1 1

1

2

1 1

0..1

Abb. 4.1: Constraint und NavigationCallExp

4.1. METAMODELL 77

attribute

attribute

attrass

attrop

method

resultVar variable

op

literal

argument

correspondingOp

variable

VOCLOperation

CompOperation name:OpEnum Method CRTMethod

Operation

AttributeOp MethodOp Condition

Argument


AttributeAssignment

Attribute

ArithmExp

LiteralExp

ArithmOp name:ArOpEnum arg{ordered}

RoleNode ClassifierRole

methodop

method

variable

argument{ordered}

1

1

0..n

0..1

0..n

0..n

0..n

0..1

1

0..n

1

0..1

0..n

0..1

0..1

0..1

0..1

0..2

0..2

0..n 0..n

argOp{ordered} argl{ordered}

1

argV{ordered}

0..2

1 arithmexp

1 0..n

0..n

0..n

0..n

0..n

0..1

Classifier feature 0..n

StateMachine

State name:String

SimpleState CompositeState

StateVertex VOCLState name:String

top

context

state referredState

subVertex

0..1

0..1 0..1

0..n 0..n

0..n

0..1

1

1

1..n

Signal

messagearg{ordered}

0..n

0..n

0..1

0..1

0..1

referredOperation

referredSignal

1 target

0..n

0..n

subState 1 0..1

ArOpEnum + - * / and or xor implies not

OpEnum = = >= <= < >

context 1

Classifier

0..n 0..n 1 1

0..n

1

1

0..n 0..n

0..n

0..n

VOCLMessageExp kind:MessageOpKind name:String

MessageOpEnum hasSentOperator messageOperator

resultingMessageNode

0..1

0..1

SequenceRole

Abb. 4.2: RoleNode


VOCLExp

CollectionRole

BooleanExp opname:BOpEnum not:Boolean

arg1

arg2

NavigationCallExp IfExp

LetExp

initExpresion

in

if then

else


letVar


source

body

iterator

resultVar

LoopExp name:LoopEnum

body

IncludesExp opname:IncOpEnum

MathSetExp opname:MSOpEnum

RoleNode

LiteralExp

CollectionExp arg1

arg2

result

result

BodyLoopExp ShortCutLoopExp

0..1 1

1 1

1 0..1

1 0..1 1

1

1 1

resultRole 1

0..1

0..1 0..2

1

0..1 0..n letExp

1

0..n

0..n

0..n

0..n

BOpEnum and or xor implies not

LoopEnum forall exists select reject collect sortedBy sum count any one isUnique

MSOpEnum setunion bagunion setintersection bagintersection setxor setdiff sequenceunion subsequence

initializedVariable

IncOpEnum includes includesAll excludes excludesAll

0..1

0..1

0..1

0..1

0..1

0..1

0..1 0..1

Abb. 4.3: Expressions

4.1. METAMODELL 79



ClassifierRole

CollectionRole


VOCLModelElement name:String

Attribute LiteralExp

Argument

type

SetRole

BagRole

SequenceRole

VOCLExp not:Boolean

type LoopExp

LetExp

IfExp

BooleanExp

NavigationCallExp

CollectionExp

RoleNode

1

1 ArithmExp

Class

Unspecified

Abb. 4.4: ModelElements und type


4.2 Constraints

Im folgenden Kapitel werden die Constraints für die Klassen des Metamodells aufgeführt. Aus Über-sichtsgründen wurde bei diesen die Definition des Contextes weggelasseen. Diese lautet immer contextKlassenname inv:

AllInstancesExp

ArithmExp

1. Die Typen der Argumente der ArithmExp müssen gleich sein:if self.literal->size()=1

then self.type=self.literal.type

else (if self.variable->size()=1

then self.type=self.variable.type

else self.type=self.op.type)

2. Es gibt nur ein Argument:self.literal->size()+self.op->size()+self.variable->size()=1

3. Wenn die ArithmExp eine VariableDeclaration enthält, muss diese zuvor im Constraint definiertworden sein:((self.variable->size()=1 and self.condition->size()=1) implies

self.condition.constraint.variableDeclaration->exists(vd: VariableDeclaration|

vd.varName=self.variable.varName) and

((self.variable->size()=1 and self.methodOp->size()=1) implies

self.methodOp.classifierRole.path.nce.constraint.variableDeclaration->exists(

vd: VariableDeclaration| vd.varName=self.variable.varName) and

((self.variable->size()=1 and self.attributeOp->size()=1) implies

self.attributeOp.classifierRole.path.nce.constraint.variableDeclaration->exists(

vd: VariableDeclaration| vd.varName=self.variable.varName))

ArithmOp

1. Die Typen der Argumente müssen gleich sein und mit den Typen der Parameter der korrespon-dierenden Operation übereinstimmen:(if self.argl->size()=2 then

(self.argl[1].type=self.argl[2].type and

self.argl[1].type=self.correspondingOp.parameter[1].type and

self.argl[2].type=self.correspondingOp.parameter[2].type)) and

(if self.argOp->size()=2 then

(self.argOp[1].type=self.argOp[2].type and

self.argOp[1].type=self.correspondingOp.parameter[1].type and

self.argOp[2].type=self.correspondingOp.parameter[2].type)) and

(if self.argV->size()=2 then

(self.argV[1].type=self.argV[2].type and

self.argV[1].type=self.correspondingOp.parameter[1].type and

self.argV[2].type=self.correspondingOp.parameter[2].type)) and

(if self.argl->size()=self.argV->size()=1 then

(self.argl.type=self.argV.type and

self.argl.type=self.correspondingOp.parameter[1].type and

self.argV.type=self.correspondingOp.parameter[2].type)) and

(if self.argl->size()=self.argOp->size()=1 then

(self.argl.type=self.argOp.type and

self.argl.type=self.correspondingOp.parameter[1].type and

self.argOp.type=self.correspondingOp.parameter[2].type)) and

4.2. CONSTRAINTS 81

(if self.argV->size()=self.argOp->size()=1 then

(self.argV.type=self.argOp.type and

self.argV.type=self.correspondingOp.parameter[1].type and

self.argOp.type=self.correspondingOp.parameter[2].type))

2. Eine ArithmOp hat genau zwei Argumente und zu jedem Parameter genau eins:self.argl->size()+self.argOp->size()+self.argV->size()=2 and

self.correspondingOp.parameter->size()=2

3. Wenn die ArithmOp eine VariableDeclaration enthält, muss diese zuvor im Constraint definiertworden sein:let variables: Set(VariableDeclaration) =

self.arithmexp.condition.constraint.variableDeclaration->union(

self.arithmExp.attributeOp.classifierRole.path.

nce.constraint.variableDeclaration)->union(

self.arithmExp.methodOp.classifierRole.path.nce.constraint.variableDeclaration)

in

self.argV->forall(vd: VariableDeclaration|

variables->exists(vd2: VariableDeclaration|

vd2=vd))


1. Die AssociationEndRole, die mit start referenziert wird, hat keinen Namen:self.start.name.oclIsUndefined()

2. Es gibt eine korrespondierende Assoziationsklasse (aus dem UML Klassendiagramm):self.referredNode.base=self.base

AssociationEndRole

AssociationRole

1. Die AssociationEndRole, die mit start referenziert wird, hat keinen Rollennamen:self.start.name.oclIsUndefined()

2. Die AssociationEndRole, die mit end referenziert wird, muss einen Rollennamen haben:self.end.name.oclIsDefined()

3. Es gibt eine korrespondierende Assoziation (aus dem UML Klassendiagramm):self.base.connection->exists(a:AssociationEndRole|

a=self.start.base) and

self.base.connection->exists(a:AssociationEndRole|

a=self.end.base)

AttributeAssignment

1. Typ des Attributes und der VariableDeclaration sind gleich:self.attribute.type=self.variable.type

Attribute

AttributeOp

1. Die Typen der Argumente der AttributeOp müssen gleich sein:self.attribute.type=self.argument.type


2. Die Typen der Argumente der AttributeOp stimmen mit den Typen der Parameter der korre-spondierenden Operation überein:self.correspondingOp.parameter[1].type=self.attribute.type and

self.correspondingOp.parameter[1].type=self.argument.type

BodyLoopExp

1. Ist der name der BodyLoopExp sum oder count, so ist das Ergebnis eine VariableDeclaration:(self.name=#sum or self.name=#count) implies

self.resultVar->size()=1

2. Der Iterator ist entweder eine ClassifierRole oder ein Attribut(self.name=#sum implies self.iterator.attrass.attribute->size()=1) and

((self.name=#any or self.name=#count or

self.name=#select or self.name=#reject

or self.name=#collect or self.name=#sortedBy or

self.name=#exists or self.name=#one or

self.name=#isUnique) implies

self.iterator.classifierRole->size()=1))

3. Die forall -Operation kann zwei Iteratoren haben:(self.iterator->size()=2 implies self.name=#forall) and

(self.name=#forall implies

self.iterator.classifierRole->size()=self.iterator->size())

4. Die Operation count wird nicht auf Sets angewendet:self.name=#count implies

not (self.source.oclIsKindOf(SetRole)

5. Der Iterator ist eine Variable vom Typ der Elemente der Collection:self.iterator.type=self.source.base

BooleanExp

1. Die Argumente arg1 und arg1 der BooleanExp haben den gleichen Typ:self.arg1.type=self.arg2.type

2. Die Argumente sind VOCLExpressions desselben Constraints:self.arg1.constraint=self.arg2.constraint=self.constraint

Classifier

ClassifierRole

1. Es kann entweder dargestellt werden, dass sich die ClassifierRole in einem bestimmten Zustandbefindet, oder dass ein Methodenaufruf stattfindet bzw. ein Attributwert verwendet wird odereine Message gesendet wurde:(self.state->size()=1 implies

(self.attrass->size()+self.attrop->size()+self.method->size()+

self.methodOp->size()+self.vOCLMessageExp->size()=0)) and

((self.attrass->size()+self.attrop->size()+self.method->size()+

self.methodOp->size()=0) implies self.state->size()=1)

2. Wenn die ClassifierRole in einem Zustand ist, dann muss ihre Basisklasse (aus dem UML Dia-gramm) auch einen solchen Zustand in einer StateMachine definieren:self.state->size()=1 implies

self.state.referredState.getStateMachine()=self.stateMachine

4.2. CONSTRAINTS 83

CollectionExp

1. Die Elementtypen der Argumente der CollectionOpExp (diese sind Collections) stimmen überein:self.arg1.type=self.arg2.type

CollectionRole

1. Eine CollectionRole hat nur eine Variablenbezeichnung, wenn sie die Initialisierung einer Varia-blen innerhalb einer LetExp ist:self.variable->size()=1 implies

self.variable.letExp->size()=1

2. Eine CollectionRole kann nur dann Attribute haben, wenn sie eine ShortCutLoopExp enthält:self.attribute->size()>=1 implies self.scloop->size()=1

3. Eine CollectionRole kann nur dann AttributeAssignments haben, wenn sie eine ShortCutLoopExpenthält:self.attrass->size()>=1 implies self.scloop->size()=1

4. Eine CollectionRole hat nur eine der Operationen isEmpty oder notEmpty :self.sco->select(sco:SimpleCollectionOp| sco.name=#isEmpty)->size()+

self.sco->select(sco:SimpleCollectionOp| sco.name=#notEmpty)->size()<=1

5. Wenn die CollectionRole ein Attribut hat, dann hat die Basisklasse der CollectionRole auch einsolches Attribut:self.attribute->forall(attribute:Attribute|

self.base.feature->exists(a:Attribute| a=attribute))

6. Wenn eine CollectionRole das Argument einer CollectionOp ist, dann hat sie keine SimpleCollOpoder ist bereits das Argument einer anderen CollectionOp:self.collectionOp->size()+self.sco->size()<=1

CompOp

1. Der Typ des Arguments der CompOp stimmt mit dem Typ eines Parameters der korrespondie-renden Operation überein:self.correspondingOp.parameter[2].type=self.argument.type)

Condition

1. Die Typen der Argumente der Condition müssen gleich sein:self.variable.type=self.argument.type

2. Die Typen der Argumente der Condition stimmen mit den Typen der Parameter der korrespon-dierenden Operation überein:self.correspondingOp.parameter[1].type=self.variable.type)

Constraint

1. Ein Constraint bezieht sich nur auf ein constrainedElement, entweder einen Classifier oder eineOperation:self.constrainedClassifier->size()+self.constrainedOp->size()=1

2. Wenn kind des Constraints inv oder def ist, dann bezieht sich der Constraint auf einen Classifier,ansonsten (bei pre oder post) auf eine Operation:if (self.kind=#inv or self.kind=#def)

then self.constrainedClassifier->size()=1

else self.constrainedOp->size()=1


3. Gibt es eine constrainedOp, dann gibt es keine constraintVar :self.constrainedOp->size()=1 implies self.constraintVar->size()=0

4. Der type der constraintVar (wenn es eine gibt) ist gleich dem constrainedClassifier:self.constraintVar->size()=1 implies

self.constraintVar.type=self.constrainedClassifier

5. Hat der Constraint eine constrainedOp, muss es eine ClassifierRole mit Namen self geben:self.constrainedOp->size()=1 implies

self.variableDeclaration->exists(vd:VariableDeclaration|

vd.varName=self and vd.classifierRole->size()>=1)

6. Die Namen der Variablen innerhalb eines Constraints sind eindeutig:self.variable->isUnique(varName)

7. Wenn kind des Constraints def ist, enthält der Constraint nur eine LetExp ohne einen In-Teil:self.kind=#def implies

(self.body.oclIsTypeOf(LetExp) and self.body.in->size()=0)

CRTMethod

1. Die Typen der Argumente der CRTMethod stimmen mit den Typen der Parameter der korre-spondierenden Operation überein und zu jedem Parameter gibt es ein Argument:(self.arg->forall(a:Argument|

a.type=self.correspondingOp.parameter->at(self.arg->indexOf(a)).type)) and

(self.correspondingOp.parameter->size()=self.arg->size() )

2. Der Typ des Ergebnis-Knotens stimmt mit dem Typ des Ergebnisparameters der entsprechendenOperation überein:self.result.type=self.correspondingOp.parameter->select(p:Parameter|

p.kind=#return).type

3. Es gibt einige vordefinierter Methoden der OCL StandardLibrary, die als CRTMethod dargestelltwerden:oclAsType(type):self.name=“oclAsType“ (implies self.arg->size()=1 and

(self.source.oclIsTypeOf(self.arg[1].type) and

self.return.type=self.arg[1].type

flatten():self.name=“flatten“ implies (self.arg->size()=0 and

self.source.oclIsTypeOf(CollectionRole) and

self.return.oclIsTypeOf(CollectionRole) and

self.source.type=self.return.type

asSet():self.name=“asSet“ implies (self.arg->size()=0 and


self.return.oclIsTypeOf(SetRole) and


asBag():self.name=“asBag“ implies (self.arg->size()=0 and


self.return.oclIsTypeOf(BagRole) and


asSequence():self.name=“asSequence“ implies (self.arg->size()=0 and


4.2. CONSTRAINTS 85

self.return.oclIsTypeOf(SequenceRole) and


Expression

IfExp

1. Die Typen der then- und else-Expression sind gleich:self.then.type.name=self.else.type.name=#Boolean

2. Der Typ der if -Expression ist Boolean:self.if.type.name=“Boolean“

IncludesOp

1. Das Ergebnis ist ein boolescher Wert:self.result.name=“Boolean“

2. Abhängig vom Namen der IncludesOp hat diese verschiedene Argumenttypen:((self.arg[1].oclIsTypeOf(CollectionRole) and

self.opname=#includes or self.opname=#excludes) implies

self.arg[2].oclIsTypeOf(ClassifierRole)) and

((self.opname=#includesAll or self.opname=#excludesAll) implies

self.arg[2].oclIsKindOf(CollectionRole))

LetExp

1. Wenn die LetExp kein in hat, dann ist kind des Constraints def:self.in->size()=0 implies self.constraint.kind=#def

2. Die Typen der initExpression und der letVar sind gleich:self.letVar.type=self.letVar.initExpression.type

3. Die Variable, die innerhalb der LetExp definiert wird, ist im gesamten Constraint bekannt, d.h.sie muss eindeutig sein:Constraint.variableDeclaration->isUnique(vd:VariableDeclaration|

vd.letExp->size()=1

LiteralExp

LoopExp

1. Eine LoopExp hat genau ein Ergebnis:self.resultVar->size()+self.resultRole->size()<=1

2. Ist der name der LoopExp any, so ist das Ergebnis eine ClassifierRole:self.name=#any implies

(self.resultRole->size()=1 and self.resultRole.oclIsTypeOf(ClassifierRole))

3. Ist der name der LoopExp select, reject, collect oder sortedBy, so ist das Ergebnis eine Collec-tionRole:(self.name=#select or self.name=#reject

or self.name=#collect or self.name=#sortedBy) implies

(self.resultRole->size()=1 and self.resultRole.oclIsKindOf(CollectionRole))


4. Ist der name der LoopExp forall, exists, one oder isUnique, so ist das Ergebnis ein boolescherWert:(self.name=#forall or self.name=#exists or

self.name=#one or self.name=#isUnique) implies

(self.resultVar->size()+self.resultRole->size()=0 and

self.type.name=“Boolean“)

5. Die Ergebnisrolle der LoopExp (wenn sie eine hat) ist auch ein Knoten des Pfades der source-Rolle:self.resultRole->size()=1 implies

self.resultRole.path=self.source.path

6. Ist der name der LoopExp select, reject oder sortedBy, so ist das Ergebnis eine CollectionRole,deren Elemente denselben Typ haben, wie die Ausgangs-Collection. Ist der name der LoopExpany, so ist das Ergebnis eine ClassifierRole, vom Typ der Elemente der Ausgangs-Collection:(self.name=#select or self.name=#reject

or self.name=#sortedBy or self.name=#any) implies

self.resultRole.base=self.source.base

7. Ist der name der LoopExp sortedBy, so ist das Ergebnis eine Sequenz:self.name=#sortedBy implies self.resultRole.oclIsTypeOf(SequenceRole)

MathSetOp

1. Abhängig vom Namen der MathSetOp hat diese verschiedene Argument- und Ergebnistypen:(self.name=#setunion or self.name=#setdiff or self.name=#setxor) implies

self.arg1.oclIsTypeOf(SetRole) and self.arg2.oclIsTypeOf(SetRole)

and self.result.oclIsTypeOf(SetRole)

(self.name=#setintersection) implies

self.arg1.oclIsTypeOf(SetRole) and (self.arg2.oclIsTypeOf(SetRole) or

self.arg2.oclIsTypeOf(BagRole)) and self.result.oclIsTypeOf(SetRole)

(self.name=#bagunion) implies

(self.arg1.oclIsTypeOf(BagRole) or self.arg1.oclIsTypeOf(SetRole)) and

self.arg2.oclIsTypeOf(BagRole) and self.result.oclIsTypeOf(BagRole)

(self.name=#bagintersection) implies

self.arg1.oclIsTypeOf(BagRole) and

self.arg2.oclIsTypeOf(BagRole) and self.result.oclIsTypeOf(BagRole)

(self.name=#sequenceunion or self.name=#subsequence) implies

self.arg1.oclIsTypeOf(SequenceRole) and self.arg2.oclIsTypeOf(SequenceRole)

and self.result.oclIsTypeOf(SequenceRole)

(self.name=#append or self.name=#prepend) implies

self.arg1.oclIsTypeOf(SequenceRole) and self.arg2.oclIsTypeOf(ClassifierRole)

and self.result.oclIsTypeOf(SequenceRole)

(self.name=#at or self.name=#first or self.name=#last) implies

self.arg1.oclIsTypeOf(SequenceRole) and self.arg2.oclIsTypeOf(ClassifierRole)

and self.result.oclIsTypeOf(ClassifierRole)

((self.name=#including or self.name=#excluding) implies

self.arg2.oclIsTypeOf(ClassifierRole)) and

(self.arg1.oclIsTypeOf(SetRole) implies self.result.oclIsTypeOf(SetRole)) and

(self.arg1.oclIsTypeOf(BagRole) implies self.result.oclIsTypeOf(BagRole)) and

(self.arg1.oclIsTypeOf(SequenceRole) implies self.result.oclIsTypeOf(SequenceRole))

2. Die Ergebnisrolle der MathSetOp ist auch ein Knoten des Pfades der arg1 -Rolle:self.result.path=self.arg1.path

4.2. CONSTRAINTS 87

Method

1. Die Typen der Argumente der Method stimmen mit den Typen der Parameter der korrespondie-renden Operation überein:self.arg->forall(a:Argument|

a.type=self.correspondingOp.parameter->at(self.arg->indexOf(a)).type

2. Zu jedem Parameter der korrespondierenden Operation gibt es genau ein Argument:self.correspondingOp.parameter->forall(p:Parameter|

self.arg->at(self.correspondingOp.parameter->indexOf(p))->size()=1)

3. Der Typ des Rückgabewertes (resultVar) einer Method muss ein primitiver Typ sein:self.resultVar.type.name=“String“ or

self.resultVar.type.name=“Boolean“ or

self.resultVar.type.name=“Integer“ or

self.resultVar.type.name=“Real“)

4. Gibt es keinen Rückgabewert, ist der Typ der Method Boolean:self.resultVar->size()=0 implies self.type.name=“Boolean“

5. Es gibt eine Menge vordefinierter Methoden der OCl StandardLibrary, die als Method dargestelltwerden:oclIsNew():self.name=“oclIsNew“ implies (self.arg->size()=0 and

(self.resultVar->size()=1 implies self.resultVar.type.name=“Boolean“))

oclIsUndefined():self.name=“oclIsUndefined“ implies (self.arg->size()=0 and


isSent():self.name=“isSent“ implies (self.arg->size()=0 and

(self.resultVar->size()=1 implies self.resultVar.type.name=“Boolean“)

and self.roleNode.type.name=“OclMessage“)

hasReturned():self.name=“hasReturned“ implies (self.arg->size()=0 and



result() ?? isSignalSent():self.name=“isSignalSent“ implies (self.arg->size()=0 and



isOperationCall():self.name=“isOperationCall“ implies (self.arg->size()=0 and



oclIsTypeOf(type):self.name=“oclIsTypeOf“ implies (self.arg->size()=1 and


oclIsKindOf(type):self.name=“oclIsKindOf“ implies (self.arg->size()=1 and


oclInState(state):self.name=“oclInState“ implies (self.arg->size()=1 and


and self.roleNode.type.name=“OclState“ and

self.roleNode.oclIsTypeOf(ClassifierRole)))

includes(object):


self.name=“includes“ implies (self.arg->size()=1 and


and self.roleNode.oclIsTypeOf(CollectionRole) and

self.roleNode.type=self.arg[1].type)

excludes(object):self.name=“excludes“ implies (self.arg->size()=1 and




includesAll(collection):self.name=“includesAll“ implies (self.arg->size()=1 and




excludesAll(collection):self.name=“excludesAll“ implies (self.arg->size()=1 and




6. Ist das Argument eine Variable, so muss diese bereits innerhalb des Constraints definiert wordensein:(self.arg->select(a:Argument| a.oclIsTypeOf(VariableDeclaration)->size()=1) implies

(self.classifierRole.path.nce.constraint=

self.arg->select(a:Argument| a.oclIsTypeOf(VariableDeclaration).constraint))

MethodOp

1. Die Typen der Argumente der MethodOp stimmen mit den Typen der Parameter der korrespon-dierenden Operation überein:self.method.correspondingOp.parameter[1].type=self.argument.type)

NavigationCallExp

1. Endet ein Path an einer ClassifierRole, die keine Method, MethodOp, VOCLMessageExp, At-tributeOp, AttributeAssignment oder Zustandsbeschreibung hat, dann gibt es noch mindestenseinen weiteren Path mit demselben start und end oder der Path ist die initExpression einer Let-Exp:let sp: Set[Path] = self.path->select(p:Path|

p.end.oclIsTypeOf(ClassifierRole) and p.end.method->size()=0

and p.end.methodOp->size()=0 and p.end.vOCLMessageExp->size()=0

and p.end.attrass->size()=0 and p.end.attrop->size()=0

and p.end.state->size()=0)

in sp->forall(p1:Path| (p1.nce.path->exists(p2:Path|

p2<>p1 and p2.start=p1.start and p2.end=p1.end)) or

(p1.nce.initializedVariable->size()=1 and

p1.nce.initializedVariable.letExp->size()=1))

2. Endet ein Path an einer CollectionRole, die keine SimpleCollectionOp oder LoopExp mit boole-schem Ergebnis hat, dann gibt es noch mindestens einen weiteren Path mit demselben start undend oder der Path ist die initExpression einer LetExp:let sp: Set[Path] = self.path.select(p:Path|

p.end.oclIsTypeOf(CollectionRole) and p.sco->size()=0 and p.loopExp->select(

l: LoopExp| (l.name=#forall) or (l.name=#exists) or

4.2. CONSTRAINTS 89

(l.name=#one) or (l.name=#isUnique))->size()=0)

in sp->forall(p1:Path| (p1.nce.path->exists(p2:Path|p2<>p1 and

p2.start=p1.start andp2.end=p1.end)) or

(p1.nce.initializedVariable->size()=1 and

p1.nce.initializedVariable.letExp->size()=1))

3. Es gibt einen Path, der bei self oder der constraintVar des Constraints startet:self.path->exists(p:Path|p.start.variable.varName=self or

p.start.variable=p.nce.constraint.constraintVar)

Operation

Path

1. Die innerhalb eines Pfades durch AssociationRoles bzw. AssociationClassRoles referenziertenClassiferRoles bzw. CollectionRoles sind auch Knoten des Pfades:self.arnode->forall(a:AssociationRole|

a.start.participant.path=self and a.end.participant.path=self) and

self.arnode->select(ar:AssociationRole|

ar.oclIsTypeOf(AssociationClassRole))->forall(a:AssociationClassRole|

a.referredClassifierRole.path=self)

2. Die innerhalb eines Pfades durch CRTMethod referenzierten ClassiferRoles sind auch Knoten desPfades:self.crtmnode->forall(c:CRTMethod|c.source.path=self

and c.return.path=self)

3. Beginnt ein Pfad mit einer AllInstancesExp, dann ist das Ergebnis (die resultierende SetRole)der Startknoten des Pfadesself.aieStart.resultingSet=self.start

4. Die Assoziationen entlang eines Pfades gehen immer in eine Richtung:self.node->forall(cn:RoleNode|

cn.associationEndRole->size()<=2 and

cn.associationEndRole.startar->size()<=1 and

cn.associationEndRole.ndear->size()<=1) and

self.start.associationEndRole.endar->size()=0 and

self.start.associationEndRole.startar->size()=0 and

self.crtmnode.source<>self.crtmnode.return and

LoopExp.allInstances()->forall(l:LoopExp| l.source<>l.resultRole) and

MathSetOp.allInstances()->forall(m:MathSetOp| m.arg[1]<>m.result)

Parameter

RoleNode

1. Wenn der RoleNode eine Variablenbezeichnung hat, sind Typ von RoleNode und VariableDecla-ration gleich:self.variable->size()=1 implies

self.type=self.variable.type

2. Wenn ein RoleNode eine MethodOp hat, dann hat die Basisklasse auch eine entsprechende Me-thode:self.methodOp->size()=1 implies

self.base.feature->exists(o:Operation| o=self.methodOp.method.correspondingOp))


3. Wenn ein RoleNode eine Method hat, dann hat die Basisklasse auch eine entsprechende Methode:self.method->size()=1 implies

self.base.feature->exists(o:Operation| o=self.method.correspondingOp))

4. Ein Attribut eines RoleNodes kann höchstens einer Variablen zugewiesen werden:self.attrass->isUnique(a:AttributeAssignment| a.attribute)

5. Der Rückgabewert einer Methode eines RoleNodes kann höchstens einer Variablen zugewiesenwerden:self.method->isUnique(m:Method| m)

6. Wenn der RoleNode eine AttributeOp hat, dann hat die Basisklasse des RoleNodes auch einentsprechendes Attribut (aus dem UML Klassendiagramm):self.attrop.attribute->forall(attribute:Attribute|


7. Wenn der RoleNode ein AttributeAssignment hat, dann hat die Basisklasse des RoleNodes auchein entsprechendes Attribut (aus dem UML Klassendiagramm):self.attrass.attribute->forall(attribute:Attribute|


8. Wenn ein RoleNode source einer CRTMethod ist, dann hat die Basisklasse auch eine entspre-chende Methode mit komplexem Ergebnistyp:CRTMethod.allInstances()->select(c:CRTMethod| c.source=self)->forall(

crtm:CRTMethod| crtm.source.base.feature->exists(o:Operation|

o=crtm.source.correspondingOp)))

ShortCutLoopExp

1. Ist der name der ShortCutLoopExp sum, so ist das Ergebnis eine VariableDeclaration. Es wirdüber einen Attributwert iteriert und die Iteratorvariable wird diesem Attributwert zugewiesen:self.name=#sum implies

(self.resultVar->size()=1 and

self.collectionRole.attribute->size()=1 and

self.iterator=self.collectionRole.attibute.attributeAssignment.variable)

2. Es wird über Attributwerte iteriert:self.collectionRole.attribute->size()>=1

SimpleCollectionOp

1. Die SimpleCollectionOp hat genau dann einen Rückgabewert, wenn ihr name # ist:self.name=“#“ implies self.resultVar->size()=1

self.name<>“#“ implies self.resultVar->size()=0

2. Der Typ des Ergebnisses der size-Operation ist Integer, der Typ des Ergebnisses von isEmptyoder notEmpty ist Boolean:if (self.name=“#“) then (self.resultVar.type.name=#Integer) else

(self.resultVar.type.name=#Boolean)

VariableDeclaration

VOCLMessageExp

1. Eine VOCLMessageExp bezieht sich entweder auf eine Operation oder auf ein Signal:self.referredOperation->size()+self.referredSignal->size()=1

4.2. CONSTRAINTS 91

2. Ist es eine Operation, so müssen die Argumente mit den Argumenttypen der referredOperationübereinstimmen:self.referredOperation->size()=1 implies

self.messagearg->forall(a: Argument| a.type.conformsTo(

self.referredOperation.parameter->at(self.messagearg->indexOf(a)).type))

3. Ist es ein Signal, so müssen die Argumente mit den Attributtypen des referredSignal überein-stimmen:self.referredSignal->size()=1 implies

self.messagearg->forall(a: Argument| a.type.conformsTo(

self.referredSignal.feature.oclAsType(structuralFeature)->at(

self.messagearg->indexOf(a)).type))

4. Ist es eine Operation, so muss die Basisklasse der ClassifierRole, zu der die Message geschicktwird, diese Operation auch als feature haben:self.referredOperation->size()=1 implies

self.target.base.feature->exists(o:Operation| o=self.referredOperation)

5. Ist der Operator der ˆ-Operator, dann gibt es keinen resultingMessageNode und das target isteine ClassifierRole:self.kind=#hasSentOperator implies

(self.resultingMessageNode->size()=0 and self.target.oclIstTypeOf(ClassifierRole)

6. Ist der Operator der ˆˆ-Operator, dann muss es einen resultingMessageNode geben:self.kind=#messageOperator implies

self.resultingMessageNode->size()=1

7. Das Ergebnis des Message-Operators ist auch ein Knoten des Pfades:self.kind=#messageOperator implies

self.resultingMessageNode.path=self.target.path

VOCLModelElement

VOCLOperation

VOCLState


Kapitel 5

Spezifikation von VOCL mit

Graphtransformation

In diesem Kapitel wird die VOCL mit dem Graphgrammatik-Ansatz, also einem konstruktiven Ansatzzur Definition der abstrakten Syntax einer visuellen Sprache, definiert. Hierbei wird das Konzept dergetypten attributierten Graphtransformation mit Knotentypvererbung, das in Kapitel 2 Abschnitt 2.6vorgestellt wurde, verwendet. Die Knotentypen des VOCL Typgraphs enthalten nur Attribute, derenWerte sich während eines Transformationsschrittes nicht ändern. Somit ist der vorgestellte Formalismusanwendbar.Zudem werden Transformation Units für die Erzeugung von Navigationsausdrücken verwendet.Diese wurden im Abschnitt 2.6.3 beschrieben. Die verwendeten Verknüpfungsoperationen sind ’or’,’xor’, ’asLongAsPossible’, ’;’, ’*’ und ’?’.

E1 or E2 bedeutet, dass E1 oder E2 oder beide Regeln angewendet werden.E1 ; E2 drückt die sequentielle Anwendung beider Regeln aus, d.h., es wird zuerst E1 und danach E2

angewendetE1 xor E2 bedeutet, dass entweder E1 oder E2 angewendet wird.asLongAsPossible E definiert, dass solange eine Anwendung von E möglich ist, diese Regel ange-wendet wird.E* drückt aus, dass E beliebig oft ausgeführt wird.E? drückt aus, dass E mindestens einmal ausgeführt wird.

Die abstrakte Syntaxgrammatik der VOCL besteht aus dem Typgraph und den Grammatikregeln.Der Typgraph ist in vier Teilgraphen unterteilt (wie das Metamodell beim MOF Ansatz). Die erstenbeiden beinhalten Constraints mit Kontext, Bedingungen und Navigationsausdrücken. Der dritte Teil-graph enthält alle weiteren Ausdrücke aus VOCL, sowie die booleschen Operationen. Im vierten Teilsind die Typen der VOCL-Elemente dargestellt. Der gesamte Typgraph der abstrakten Syntax vonVOCL besteht aus diesen vier Teilgraphen. Nach dem Typgraphen werden die Syntaxgrammatikre-geln zur Erstellung von VOCL Constraints dargestellt. Da sich jeder VOCL Constraint auf ein UMLDiagramm bezieht, werden zunächst noch einmal der Typgraph und die Syntaxgrammatikregeln zurErstellung einfacher UML Klassendiagramme beschrieben.

5.1 Einfache UML Klassendiagramme

Im folgenden werden der Typgraph und die Grammatikregeln für einfache UML Klassendiagrammedargestellt. Diese enthalten Klassen mit Attributen und Operationen, Assoziationen zwischen Klassen,Assoziationsklassen und Generalisierungen. Diese sind Bestandteil des UML Metamodells, welches all-gemeine Klassendiagramme beschreibt.

93

94 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION

5.1.1 Typgraph für einfache UML Klassendiagramme

Parameter kind:PKindEnum

Classifier isRoot: Boolean isLeaf: Boolean isAbstract: Boolean

ModelElement name:String

Attribute ownerScope:ScopeKind visibility: VisibilityKind multiplicity: Multiplicity changeability: ChangeableKind targetScope: ScopeKind ordering: OrderingKind initialValue: Expression

type

Association

AssociationClass

connection

feature

feature

parameter

AssociationEnd isNavigable: Boolean ordering: OrderingKind aggregation: AggregationKind targetScope: ScopeKind multiplicity:Multiplicity changeability: ChangeableKind visibility: VisibilityKind

type

Operation ownerScope:ScopeKind visibility: VisibilityKind isQuery: Boolean concurrency: ConcurrencyKind isRoot: Boolean isLeaf: Boolean isAbstract: Boolean specification: String

Class isActive:Boolean

participant

Generalization child

parent

DataType

5.1. EINFACHE UML KLASSENDIAGRAMME 95

Signatur der Aufzählungstypen:Enumerations =

sorts: PKindEnumScopeKindVisibilityKindConcurrencyKindMultiplicityChangeableKindOrderingKindAggregationKind

opns: in: → PKindEnumout: → PKindEnuminout: → PKindEnumreturn: → PKindEnumn

instance: → ScopeKindclassifier: → ScopeKind

public: → VisibilityKindprotected: → VisibilityKindprivate: → VisibilityKindpackage: → VisibilityKind

sequential: → ConcurrencyKindguarded: → ConcurrencyKindconcurrent: → ConcurrencyKind

0..*: → Multiplicity1..*: → Multiplicity0..1: → Multiplicity1: → Multiplicity*: → Multiplicity

changeable: → ChangeableKindfrozen: → ChangeableKindaddOnly: → ChangeableKind

ordered: → OrderingKindunordered: → OrderingKind

none: → AggregationKindaggregate: → AggregationKindcomposite: → AggregationKind

5.1.2 Syntaxgrammatik für einfache UML Klassendiagramme


L R

InsertClass(classname: String, root:Boolean, leaf:Boolean, abstract:Boolean, active:Boolean)

:Class name=classname isRoot=root isLeaf=leaf isAbstract=abstract isAcitve=active

NAC

:Class name=classname

L R

InsertDefaultClassAttribute(aname: String)

NAC

1: Class

1: Class feature

type

2: Classifier

2: Classifier

Attribute name=aname ownerScope=#instance visibility=#private multiplicity=#1 changeability=#changeable targetScope=#instance ordering=#unordered initialValue=""

:Attribute name=aname

1: Class

feature

L R

InsertDefaultClassOperation(opname: String)

NAC

1: Class

1: Class feature

Operation name=opname ownerScope=#instance visibility=#public isQuery=#false concurrency=#sequential isRoot=#false isLeaf=#false isAbstract=#false specification=""

:Operation name=opname

1: Class

feature

L R

InsertOperationParameter(paramName: String, pKind: PKindEnum)

NAC

1:Operation

:Parameter name=paramName kind=pKind

1:Operation

type

parameter

2:Classifier

2:Classifier

1:Operation

:Parameter name=paramName

parameter

L R InsertDataType(typename: String, root:Boolean, leaf:Boolean, abstract:Boolean)

:DataType name=typename isRoot=root isLeaf=leaf isAbstract=abstract

NAC

:DataType name=typename


L R

InsertDefaultAssociation(aName: String, nameEnd1: String, mult1:MultiplicityKind, nameEnd2: String, mult2:MultiplicityKind)

NAC

1:Class

2:Class

:Association name=aName

1:Class

2:Class

participant

participant

connection

connection

AssociationEnd name=nameEnd1 isNavigable=#true ordering=#unordered aggregation=#none targetScope=#instance multiplicity=mult1 changeability=#changeable visibility=#private



1:Class

2:Class

participant

participant

connection

connection

:AssociationEnd name=nameEnd1


L R

InsertDefaultAssociationClass(className: String, root:Boolean, leaf:Boolean, absract:Boolean, active:Boolean, nameEnd1: String, mult1:MultiplicityKind, nameEnd2: String, mult2:MultiplicityKind)

NAC

1:Class

2:Class 1:Class

2:Class

participant

participant

connection

connection



:AssociationClass name=className isRoot=root isLeaf=leaf isAbstract=abstract isAcitve=active

:AssociationClass name=className

1:Class

2:Class

participant

participant

connection

connection




L R

InsertDefaultAssociationEnd(nameEnd: String, mult:MultiplicityKind)

NAC

1:Class

2:Association 1:Class

participant

connection

connection

:AssociationEnd name=nameEnd

2:Association

2:Association

1:Class

participant AssociationEnd name=nameEnd isNavigable=#true ordering=#unordered aggregation=#none targetScope=#instance multiplicity=mult changeability=#changeable visibility=#private


L R

InsertGeneralization(gName: String, classname: String, leaf:Boolean, abstract:Boolean, active:Boolean)

NAC

:Generalization name=gName

child

parent

:Class name=classname isRoot=false isLeaf=leaf isAbstract=abstract isAcitve=active

1:Class isLeaf=false


:Generalization

child

parent

:Class name=classname


L R

InsertClassAttribute(aname: String, init:Expression, oscope: ScopeKind, visible: VisibilityKind, change:ChangeabilityKind, mult:Multiplicity, ord:OrderingKind, tscope:ScopeKind)

NAC

1: Class

1: Class feature

type

2: Classifier

2: Classifier

Attribute name=aname ownerScope=oscope visibility=visible multiplicity=mult changeability=change targetScope=tscope ordering=ord initialValue=init

:Attribute name=aname

L R

InsertClassOperation(opname: String, scope: ScopeKind, visible: VisibilityKind, query: Boolean, concurrency: ConcurrencyKind, root: Boolean, leaf: Boolean, abstract: Boolean, spec: String))

NAC = R

1: Class

1: Class feature

Operation name=opname ownerScope=scope visibility=visible isQuery=query concurrency=concurrency isRoot=root isLeaf=leaf isAbstract=abstract specification=spec


L R

InsertAssociation(aName: String, nameEnd1: String, nav1: Boolean, ord1: OrderingKind, agg1: AggregationKind, ts1: ScopeKind, mult1:MultiplicityKind, change1: ChangeableKind, visible1: VisibilityKind, nameEnd2: String, nav2: Boolean, ord2: OrderingKind, agg2: AggregationKind, ts2: ScopeKind, mult2:MultiplicityKind, change2: ChangeableKind, visible2: VisibilityKind)

NAC

1:Class

2:Class


1:Class

2:Class

participant

participant

connection

connection

AssociationEnd name=nameEnd1 isNavigable=nav1 ordering=ord1 aggregation=agg1 targetScope=ts1 multiplicity=mult1 changeability=change1 visibility=visible1



1:Class

2:Class

participant

participant

connection

connection



L R

InsertAssociationClass(className: String, root:Boolean, leaf:Boolean, abstract:Boolean, active:Boolean, nameEnd1: String, nav1: Boolean, ord1: OrderingKind, agg1: AggregationKind, ts1: ScopeKind, mult1:MultiplicityKind, change1: ChangeableKind, visible1: VisibilityKind, nameEnd2: String, nav2: Boolean, ord2: OrderingKind, agg2: AggregationKind, ts2: ScopeKind, mult2:MultiplicityKind, change2: ChangeableKind, visible2: VisibilityKind )

NAC

1:Class

2:Class 1:Class

2:Class

participant

participant

connection

connection

:AssociationClass name=className isRoot=root isLeaf=leaf isAbstract=abstract isAcitve=active

:AssociationClass name=className

1:Class

2:Class

participant

participant

connection

connection






L R

InsertAssociationEnd(nameEnd: String, nav: Boolean, ord1: OrderingKind, agg: AggregationKind, ts: ScopeKind, mult:MultiplicityKind, change: ChangeableKind, visible: VisibilityKind, )

NAC

1:Class

2:Association 1:Class

participant

connection

AssociationEnd name=nameEnd isNavigable=nav ordering=ord aggregation=agg targetScope=ts multiplicity=mult changeability=change visibility=visible

connection

:AssociationEnd name=nameEnd

2:Association

2:Association

1:Class

participant


5.2 Typgraph von VOCL

NavigationCallExp

Path



CollectionRole

AssociationRole


constrainedOp

constraintVar

start end node

arnode

participant

resultVar

resultVar

crtmnode

navSource

return


nce

end


Operation

AssociationEndRole


CRTMethod

AllInstancesExp aieStart

resultingSet

classifier Condition

condition

RoleNode

referredNode

AssociationClass Association

AssociationEnd base

base base

connection

VOCLExp not:Boolean

exp

SetRole

ClassifierRole

Classifier

base

SimpleCollectionExp name:SCOEnum

Attribute

attribute

feature

body

variable

variable

start

parameter order:Integer

NavigationRoleExp

Abb. 5.1: Constraints und Navigationen (1)

5.2. TYPGRAPH VON VOCL 103

attribute

attribute

attrass

attrop

method

resultVar variable

argument

correspondingOp

variable

VOCLOperation

CompOperation name:OpEnum Method CRTMethod

Operation

AttributeOp MethodOp Condition

Argument


AttributeAssignment

Attribute

RoleNode

methodop

method

variable

argV{ordered}

Classifier feature

Signal

VOCLMessageExp kind:MessageOpKind name:String

referredOperation

referredSignal

target

ClassifierRole

StateMachine

State name:String

SimpleState CompositeState

StateVertex VOCLState name:String

top context

state

referredState

subVertex

subState

op

literal

argOp

argl

ArithmExp

LiteralExp

ArithmOp name:ArOpEnum

arg order:Integer arguments

order:Integer

messagearg order:Integer

context

Classifier

resultingMessageNode

SequenceRole

Abb. 5.2: Constraints und Navigationen (2)


VOCLExp

CollectionRole

BooleanExp opname:BOpEnum

arg1 arg2

NavigationCallExp IfExp

LetExp

in

if then

else


letVar


source

body

iterator resultVar

LoopExp name:LoopEnum

exp

IncludesExp opname:IncOpEnum

MathSetExp opname:MSOpEnum

RoleNode LiteralExp CollectionExp

navSource

arg2

result result

BodyLoopExp ShortCutLoopExp

NavigationRoleExp

resultRole

initExpression

loopExp

Abb. 5.3: VOCLExpressions



ClassifierRole

CollectionRole


VOCLModelElement name:String

Attribute LiteralExp

Argument

type

SetRole

BagRole

SequenceRole

VOCLExp not:Boolean

type

LoopExp

LetExp

IfExp

BooleanExp

NavigationCallExp

CollectionOpExp

RoleNode

ArithmExp

Class


Unspecified

Abb. 5.4: Typen


Signatur der Aufzählungstypen:Enumerations =

sorts: PKindEnumConstraintKindEnumSCOEnumArOpEnumOpEnumMSOpEnumLoopEnumBOpEnumIncOpEnumMessageOpKind

opns: in: → PKindEnumout: → PKindEnuminout: → PKindEnumreturn: → PKindEnumn

inv: → ConstraintKindEnumdefinition: → ConstraintKindEnumpre: → ConstraintKindEnumpost: → ConstraintKindEnum

= ∅: → SCOEnum6= ∅: → SCOEnum#: → SCOEnum

+: → ArOpEnum-: → ArOpEnum*: → ArOpEnum\: → ArOpEnumand: → ArOpEnumor: → ArOpEnumxor: → ArOpEnumnot: → ArOpEnumimplies: → ArOpEnum

=: → OpEnum6=: → OpEnum≥: → OpEnum≤: → OpEnum<: → OpEnum>: → OpEnum

setunion: → MSOpEnumbagunion: → MSOpEnumsetintersection: → MSOpEnumbagintersection: → MSOpEnumsetxor: → MSOpEnumsetdiff: → MSOpEnumsequenceunion: → MSOpEnumsubsequence: → MSOpEnum

forall: → LoopEnum


exists: → LoopEnumselect: → LoopEnumreject: → LoopEnumcollect: → LoopEnumsortedBy: → LoopEnumsum: → LoopEnumcount: → LoopEnumany: → LoopEnumone: → LoopEnumisUnique: → LoopEnum

and: → BOpEnumor: → BOpEnumxor: → BOpEnumimplies: → BOpEnumnot: → BOpEnum

includes: → IncOpEnumincludesAll: → IncOpEnumexcludes: → IncOpEnumexcludesAll: → IncOpEnum

hasSentOperator: → MessageOpKindmessageOperator: → MessageOpKind


5.3 Syntaxgrammatikregeln von VOCL

5.3.1 Definition des Kontextes

Die folgenden Regeln dienen der Definition des Kontextes eines VOCL Constraints. Sie erzeugen einenConstraint, der eine Invariante, Definition oder Vor- bzw. Nachbedingung einer Operation ist und sichsomit entweder auf eine Klasse oder Operation bezieht. Ein Constraint kann optional einen Namenoder eine Constraintvariable haben, welche dann im Body wieder verwendet wird.

:Constraint kind=cKind name=""


L R

CreateConstraint1(cKind:ConstraintKindEnum)

cKind=#inv v #def

1:Classifier 1:Classifier

Abb. 5.5: Invariante oder Definition Constraint wird erzeugt

1:Operation name=cOp

constrainedOp

L R

CreateConstraint2(cKind:ConstraintKindEnum, cOp:String)

:Constraint kind=cKind name=""

cKind=#pre v #post

1:Operation name=cOp

Abb. 5.6: Vor- oder Nachbedingungs- Constraint wird erzeugt

1:Constraint name=cName

L R

InsertConstraintName(cName:String)

1:Constraint name=n

Abb. 5.7: Einfügen eines Constraintnamens

L R

InsertConstraintVar(cVarName:String)

1:Constraint

NAC

2:Classifier 3:constrainedClassifier 1:Constraint

3:constrainedClassifier

VariableDeclaration varName=cVarName constraintVar

type

2:Classifier

1:Constraint

constraintVar :VariableDeclaration

Abb. 5.8: Einfügen einer Constraintvariablen

5.3. SYNTAXGRAMMATIKREGELN VON VOCL 109

Die Transformation Unit DefineContext fügt einen Constraint und seinen Context-Teil ein.

DefineContext

(CreateConstraint1(ck1) xor CreateConstraint2(ck2)) ; InsertConstraintName(cn) * ; InsertConstraintVar(vn) ? ;

Abb. 5.9: Einfügen eines Constraint-Kontextes

5.3.2 Navigationen

Die Regeln dieses Abschnitts beziehen sich auf Navigationsausdrücke. Es können äquivalente Navigati-onspfade dargestellt werden oder es wird von einer Startrolle zu einem Attribut oder Methodenaufrufnavigiert.

Navigationspfade

Ein Navigationspfad beginnt an einer Startrolle. Diese ist eine ClassifierRole (kann die vordefinierteVariable self oder die zuvor definierte Constraintvariable sein) oder eine CollectionRole (wenn miteiner AllInstancesExp begonnen wird) sein. Von dieser wird zu einer anderen Instanz navigiert und soweiter. Allerdings kann eine Navigation nur an einer Instanz beginnen, an der keine andere Navigationstartet. Die Navigation findet über Assoziationen, zu Assoziationsklassen und über Methoden, die wie-der Rollen als Ergebnis haben, statt. Bei der Erstellung äquivalenter Navigationspfade muss am Endevon beiden Navigationsenden zu einer Endrolle navigiert werden.

Die Regel InsertNavigationCallExp fügt einen Navigationsausdruck in einen Constraint ein, der nochkeinen Ausdruck enthält (NAC). Diese Regel fügt keinen definition-Constraint ein.

2:Classifier 3:constrainedClassifier

L R InsertNavigationCallExp()


:NavigationCallExp

body

NAC

:VOCLExp

body

k<>definition

1:Constraint kind=k

1:Constraint kind=k

1:Constraint kind=k

Abb. 5.10: Der Constraint beinhaltet einen Navigationsausdruck

Die Regel InsertStartRoleSelf fügt die Startrolle eines Navigationsausdrucks ein, wenn dieser nochkeine Startrolle hat (NAC). Dieser existiert bereits innerhalb eines Constraints, der einen Classifier alsKontext definiert hat (L). Die Startrolle hat den Namen self und den Typ des Kontextes. Die Variablemit dem Namen self hat denselben Typ wie die ClassifierRole (R).



L R InsertStartRoleSelf()

1:Constraint 2:Classifier

3:constrainedClassifier 1:Constraint

4:NavigationCallExp

:Path

:ClassifierRole

:VariableDeclaration varName=self

variable

start

nce

type type

NAC

variable 4:NavigationCallExp 5:body

4:NavigationCallExp

:Path

5:body

nce

Abb. 5.11: Die Navigation beginnt bei self

Die Regel InsertStartRoleCVar fügt die Startrolle eines Navigationsausdrucks ein, wenn dieser nochkeine Startrolle hat (NAC). Dieser existiert bereits innerhalb eines Constraints, der einen Classifier alsKontext und eine Constraintvariable definiert hat (L). Die Startrolle hat den Namen der Constraint-variablen und den Typ des Kontextes. Die Variable mit dem Namen self hat denselben Typ wie dieClassifierRole (R).


L R InsertStartRoleCVar()

1:Constraint 2:Classifier 4:constrainedClassifier

1:Constraint

7:NavigationCallExp

:Path

:ClassifierRole

3:VariableDeclaration varName=vname

variable

start

nce

8:body type

5:type


5:type 6:constraintVar

6:constraintVar

NAC

7:NavigationCallExp 8:body

7:NavigationCallExp

:Path

nce

Abb. 5.12: Die Navigation beginnt bei der Constraintvariablen

Die Regel InsertAllInstancesExp fügt die Startrolle eines Navigationsausdrucks ein, wenn dieser nochkeine Startrolle hat (NAC). Dieser existiert bereits innerhalb eines Constraints, der einen Classifier alsKontext definiert hat (L). Die Startrolle ist eine Menge (SetRole), die die Menge aller Instanzen derKontextklasse enthält, hat keinen Namen und den Typ des Kontextes (R).


L R InsertAllInstancesExp()

1:Constraint 1:Constraint

4:NavigationCallExp

:Path

:AllInstancesExp

resultingSet

aieStart

nce

5:body classifier type


start

:SetRole NAC

4:NavigationCallExp 5:body

4:NavigationCallExp

:Path nce

Abb. 5.13: Die Navigation beginnt bei der Menge aller Instanzen der Constraintklasse

Die Regel InsertStartRoleSelf2 fügt die Startrolle eines Navigationsausdrucks ein, wenn dieser nochkeine Startrolle hat (NAC). Dieser existiert bereits innerhalb eines Constraints, der eine Operation alsKontext definiert hat (L). Die Startrolle hat den Namen self und den Typ der Klasse, die die Operationdes Kontextes definiert. Die Variable mit dem Namen self hat denselben Typ wie die ClassifierRole(R).

2:Operation 5:constrainedOp

L R InsertStartRoleSelf2()

1:Constraint 1:Constraint

8:NavigationCallExp

:Path

:ClassifierRole :VariableDeclaration varName=self

variable

start

nce

9:body

type

type

NAC

4:Classifier

3:Class

6:feature 7:base

2:Operation 5:constrainedOp

4:Classifier 3:Class

6:feature 7:base

variable

8:NavigationCallExp

9:body

8:NavigationCallExp

:Path nce

Abb. 5.14: Die Navigation beginnt bei self, der Constraint bezieht sich auf eine Operation

Die Regel InsertNewPath fügt zu einem Navigationsausdruck, der bereits einen Pfad enthält (L), einenneuen Pfad ein. Der neue Pfad beginnt an derselben Startrolle wie der bereits existierende Pfad (R).

L R InsertNewPath()

4:NavigationCallExp

5:Path

3:ClassifierNode

8:start

9:path 7:type

4:NavigationCallExp

5:Path

3:ClassifierNode 8:start

9:path 7:type

:Path

start

path


Abb. 5.15: Einfügen eines äuivalenten Pfades (bzw. Pfadstartes)


Es gibt sieben Möglichkeiten, die Navigation mit einer Assoziation zu beginnen. Es kann von einerClassifierRole (self oder die ConstraintVariable) oder von einer Menge aller Instanzen einer Klasse(also einer SetRole) zu allen vier Arten von RoleNodes navigiert werden. Dasselbe gilt für den Navi-gationsstart zu einer Assoziationsklasse, wovon hier nur ein Beispiel dargestellt wird.

Die Regel InsertStartAssociation fügt als Start einer Navigation (an die Startrolle eines Pfades) eineAssociationRole ein. Dazu muss es bereits eine ClassifierRole und eine enstprechende Association (ausdem UML Diagramm) mit einem Assoziationsende vom Typ der ClassifierRole und einem Assoziati-onsende mit dem übergebenene Rollennamen geben. Außerdem müssen die Kardinalitäten und andereEigenschaften der Assoziation überprüft werden. Dann kann die AssociationRole, eine neue Classifier-Role vom Typ des anderen Associationsendes und zwei AssociationEndRoles eingefügt werden. DieAssociationRole und die neue ClassifierRole werden auch zu Knoten des Pfades. Die Startrolle hatkeinen Rollennamen, die Zielrolle muss einen haben.Die folgenden sechs Regeln sind ähnlich, die Eigenschaften der entsprechenden Assoziation und deseinzufügenden RoleNodes sind unterschiedlich (die Attribute multiplicity und ordered der Assoziati-onsenden sind für die verschiedenen konkreten Ausprägungen der RoleNodes unterschiedlich.

L R

InsertStartAssociation(rolename:String, classname:String)

1:Path

2:ClassifierRole 4:start

5:base

7:AssociationEnd

6:Association

9:referredAssociationEnd


11:participant

12:Classifier name=classname 13:participant

1:Path


5:base

7:AssociationEnd

6:Association



:AssociationEndRole

:AssociationRole

:AssociationEndRole name=rolename

start

end

:ClassifierRole participant

participant

node base

13:participant

11:participant

base

base

base arnode

12:Classifier name=classname

8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"


x = 1 v 0..1

3:Classifier

3:Classifier

Abb. 5.16: Die Navigation beginnt entlang einer Assoziation


L R

InsertStartAssociationToSet(rolename:String, classname:String)

1:Path


5:base

7:AssociationEnd

6:Association



11:participant

1:Path


5:base

7:AssociationEnd

6:Association



:AssociationEndRole

:AssociationRole


start

end

:SetRole participant

participant

node

base

13:participant

11:participant

base

base

base arnode




x = * v 0..*


3:Classifier

3:Classifier



L R

InsertStartAssociationToBag(rolename:String, classname:String)

1:Path


5:base

7:AssociationEnd

6:Association



11:participant


1:Path


5:base

7:AssociationEnd

6:Association



:AssociationEndRole

:AssociationRole


start

end

:BagRole participant

participant

node

base

13:participant

11:participant

base

base

base arnode



x = * v 0..*


3:Classifier

3:Classifier



L R

InsertStartAssociationToSequence(rolename:String, classname:String)

1:Path

2:SetRole 4:start

5:base

6:Association



11:participant

1:Path

2:SetRole 4:start

5:base

6:Association



:AssociationEndRole

:AssociationRole


start

end

:SequenceRole participant

participant

node

base

13:participant

11:participant

base

base

base arnode


7:AssociationEnd

7:AssociationEnd


8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="ordered"

x = * v 0..* 8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="ordered"

3:Classifier

3:Classifier



L R

InsertStartAssociationSetToSet(rolename:String, classname:String)

1:Path

2:SetRole 4:start

5:base

6:Association



11:participant


1:Path

2:SetRole 4:start

5:base

6:Association



:AssociationEndRole

:AssociationRole


start

end

:SetRole participant

participant

node

base

13:participant

11:participant

base

base

base arnode


8:AssociationEnd name=rolename multiplicity=#* v #0..* isNavigable="true" targetScope=#instance ordering=#unordered

8:AssociationEnd name=rolename multiplicity=#* v #0..* isNavigable="true" targetScope=#instance ordering=#unordered

7:AssociationEnd multiplicity=#* v #0..*

7:AssociationEnd multiplicity=#* v #0..*

NAC

2:ClassifierRole

:AssociationEndRole

participant

3:Classifier

3:Classifier



L R

InsertStartAssociationSetToBag(rolename:String, classname:String)

1:Path

2:SetRole 4:start

5:base

6:Association



11:participant

1:Path

2:SetRole 4:start

5:base

6:Association



:AssociationEndRole

:AssociationRole


start

end

:BagRole participant

participant

node

base

13:participant

11:participant

base

base

base arnode


7:AssociationEnd multiplicity=y





x = * v 0..* y = * v 0..*

3:Classifier

3:Classifier



L R

InsertStartAssociationSetToSequence(rolename:String, classname:String)

1:Path

2:SetRole 4:start

5:base

6:Association



11:participant

1:Path

2:SetRole 4:start

5:base

6:Association



:AssociationEndRole

:AssociationRole


start

end

:SequenceRole participant

participant

node

base

13:participant

11:participant

base

base

base arnode

12:Classifier name=classname isAbstract="false"





x = * v 0..* y = * v 0..*


3:Classifier

3:Classifier



Die Regel InsertStartAssociationClass fügt als Start einer Navigation (an die Startrolle eines Pfades)eine AssociationClassRole ein. Dazu muss es bereits eine ClassifierRole und eine enstprechende Asso-ciationClass (aus dem UML Diagramm) mit einem Assoziationsende vom Typ der ClassifierRole, einemAssoziationsende und einer Assoziationsklasse mit dem übergebenenen Namen geben. Außerdem müs-sen die Kardinalitäten und andere Eigenschaften der Assoziationklasse überprüft werden. Dann kanndie AssociationClassRole, eine neue ClassifierRole vom Typ des anderen Associationsendes und einClassifierRole vom Typ der Assoziationsklasse sowie zwei AssociationEndRoles eingefügt werden. DieStartrolle hat keinen Rollennamen, die Zielrolle kann einen haben.Die AssociationClassRole und die neuen ClassifierRoles werden auch zu Knoten des Pfades.

L R

InsertStartAssociationClassToCR(classname:String)

1:Path


5:base

7:AssociationEnd

6:AssociationClass

9:connection

10:connection

11:tparticipant

13:participant

1:Path

2:ClassifierRole

4:start

5:base

7:AssociationEnd

6:AssociationClass

9:connection

10:connection

:AssociationEndRole

:AssociationClassRole

:AssociationEndRole

start

end

:ClassifierRole

participant

participant

crnode

base

13:participant

11:tparticipant

base

base

base arnode

15:type

:ClassifierRole

base

15:type

referredNode





x = 1 v 0..1

3:Classifier

3:Classifier

12:Classifier

12:Classifier

Abb. 5.23: Die Navigation startet zu einer Assoziationsklasse


Für das Einfügen einer Assoziation zwischen zwei RoleNodes gibt es 13 verschiedene Möglichkeiten.Im folgenden wird eine davon abgebildet, eine Navigation von einer ClassifierRole zu einer anderenClassifierRole. Die anderen Regeln sehen ähnlich aus, sie unterscheiden sich nur in den Attributwertender AssociationEnds und der Art der Knoten (ClassifierRole, SetRole...).Die Regel InsertAssociationCR fügt eine AssociationRole an das momentane Ende eines Pfades (wasdie NAC sicherstellt) ein. Dazu muss es bereits eine ClassifierRole und eine enstprechende Association(aus dem UML Diagramm) mit einem Assoziationsende vom Typ der ClassifierRole und einem Assozia-tionsende mit dem übergebenen Rollennamen geben. Außerdem müssen die Kardinalitäten und andereEigenschaften der Assoziation überprüft werden. Dann kann die AssociationRole, eine neue Classifier-Role vom Typ des anderen Associationsendes und zwei AssociationEndRoles eingefügt werden. DieAssociationRole und die neue ClassifierRole werden auch zu Knoten des Pfades.

L R

InsertAssociationCR(rolename:String, classname:String)

2:ClassifierRole

navSource

:NavigationRoleExp

NAC

1:Path

2:ClassifierRole 4:node 5:base

7:AssociationEnd multiplicity=#1 v #0..1

6:Association



11:participant

1:Path

2:ClassifierRole 4:node

5:base

6:Association



:AssociationEndRole

:AssociationRole


start

end

:ClassifierRole participant

navSource

node

base

13:participant

11:participant

base

base

base arnode



13:participant



x = 1 v 0..1 8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"

3:Classifier

3:Classifier

Abb. 5.24: Einfügen einer Navigation entlang einer Assoziation


Auch für das Einfügen einer Assoziationsklasse zwischen zwei RoleNodes gibt es 13 verschiedene Mög-lichkeiten, von denen nur eine dargestellt ist.

Die Regel InsertAssociationClassToCR fügt eine AssociationClassRole an das momentane Ende einesPfades (was die NAC sicherstellt) ein. Dazu muss es bereits eine ClassifierRole und eine enstprechendeAssociationClass (aus dem UML Diagramm) mit einem Assoziationsende vom Typ der ClassifierRole,einem Assoziationsende und einer Assoziationsklasse mit dem übergebenenen Namen geben. Außerdemmüssen die Kardinalitäten und andere Eigenschaften der Assoziationklasse überprüft werden. Dannkann die AssociationClassRole, eine neue ClassifierRole vom Typ des anderen Associationsendes undein ClassifierRole vom Typ der ASsoziationsklasse sowie zwei AssociationEndRoles eingefügt werden.Die AssociationClassRole und die neuen ClassifierRoles werden auch zu Knoten des Pfades.

L R

InsertAssociationClassToCR(classname:String)

1:Path


5:base

6:AssociationClass

10:connection

11:tparticipant

1:Path

2:ClassifierRole

4:node

5:base

6:AssociationClass

9:connection

10:connection

:AssociationEndRole

:AssociationClassRole

:AssociationEndRole

start

end

:ClassifierRole

participant

navSource

crnode

base

13:participant

11:tparticipant

base

base

base arnode

15:type

:ClassifierRole

base

15:type

referredNode





13:participant


x = 1 v 0..1


3:Classifier

3:Classifier

12:Classifier

12:Classifier

9:connection

2:ClassifierRole

navSource

:NavigationRoleExp

NAC

Abb. 5.25: Einfügen einer Navigation zu einer Assoziationsklasse


Es gibt vier abstrakte Regeln für das Einfügen einer CRTMethod als Startnavigation oder “normale“Navigation, von denen je eine dargestellt ist.Die Regel InsertCRTMethod fügt eine Methode mit einem komplexen Rückgabetyp (eine Rolle) an dasmomentane Ende eines Pfades (was die NAC sicherstellt) ein. Dazu muss es bereits eine ClassifierRoleund eine enstprechende Operation (aus dem UML Diagramm) einer Klasse vom Typ der ClassifierRoleund einem Ergebnis von komplexem Typ geben. Dann kann die CRTMethod und eine neue Classifier-Role vom Typ des Ergebnisses eingefügt werden. Die CRTMethod und die neue ClassifierRole werdenauch zu Knoten des Pfades.Die Regel InsertStartCRTMethod fügt eine Methode mit einem komplexen Rückgabetyp (eine Rolle) anden Anfang eines Pfades (die Startrolle) ein. Von der Ergebnisrolle kann dann weiternavigiert werden.

L R

InsertStartCRTMethodCR(mname:String)

1:Path

2:RoleNode

5:start

1:Path

2:RoleNode

:ClassifierRole

:CRTMethod name=mname

node

source

return

3:Operation name=mname

correspondingOp

5:start

4:Classifier type

6:type

3:Parameter kind=#return

7:parameter 3:Operation name=mname

4:Classifier 6:type


7:parameter

8:Class

9:base 10:feature

8:Class

9:base

10:feature

Abb. 5.26: Einfügen einer Startnavigation über eine Methode

L R

InsertCRTMethodCR(mname:String)

1:Path

2:RoleNode

5:node

1:Path

2:RoleNode

:ClassifierRole


node

navSource

return


correspondingOp

5:node

4:Classifier type

6:type


7:parameter 3:Operation name=mname

4:Classifier 6:type


7:parameter

8:Class

9:base 10:feature

8:Class

9:base

10:feature

2:RoleNode

navSource

:NavigationRoleExp

NAC

Abb. 5.27: Einfügen einer Navigation über eine Methode


Die Regel InsertCRTMethodArgV fügt ein Argument einer CRTMethod ein. Dieses ist eine Variable,die bereits zuvor im Constraint definiert wurde. Außerdem muss die entsprechende Operation auchParameter vom Typ der Variablen haben (L). Zu jedem Parameter darf nur ein Argument eingefügtwerden (NAC).

L

R

InsertCRTMethodArgV(aname:String)

1:CRTMethod

3:Operation

2:correspondingOp

5:Parameter

4:Classifier

6:parameter order=n

7:type 8:VariableDeclaration varName=aname

9:type

1:CRTMethod

3:Operation

2:correspondingOp

5:Parameter 7:type 8:VariableDeclaration

varName=aname 9:type 4:Classifier

6:parameter order=n

arg order=n

1:CRTMethod

arg order=n

NAC

:Argument

Abb. 5.28: Einfügen eines Methodenarguments (eine Variable)

Die Regel InsertCRTMethodArgL fügt ein Argument einer CRTMethod ein. Dieses ist eine Konstante.Die entsprechende Operation muss einen Parameter vom Typ der Konstanten haben (L). Zu jedemParameter darf nur ein Argument eingefügt werden (NAC).

L

InsertCRTMethodArgL(aname:String)

1:CRTMethod

3:Operation

2:correspondingOp

5:Parameter 7:type

R

1:CRTMethod

3:Operation

2:correspondingOp

5:Parameter 7:type :LiteralExp

name=aname type

4:Classifier

4:Classifier

1:CRTMethod

arg order=n

NAC

:Argument

arg order=n

6:parameter order=n

6:parameter order=n

Abb. 5.29: Einfügen eines Methodenarguments (eine Konstante)


Auch für das Einfügen eines Pfadendes zweier äquivalenter Pfade durch eine Assoziation oder eine As-soziationsklasse zwischen zwei RoleNodes gibt es 13 verschiedene Möglichkeiten, von denen nur jeweilseine dargestellt ist.

Die Regel InsertPathEndAssociation1 fügt eine AssociationRole zwischen die momentane Enden zweierPfade (was die NAC sicherstellt) ein. Dazu muss es bereits zwei ClassifierRoles und eine enstprechendeAssociation (aus dem UML Diagramm) mit zwei Assoziationsenden von den Typen der ClassifierRoles,wobei ein Assoziationsende den übergebenen Rollennamen haben muss, geben. Außerdem müssen dieKardinalitäten und andere Eigenschaften der Assoziation überprüft werden. Dann kann die Associa-tionRole und zwei AssociationEndRoles eingefügt werden. Die AssociationRole wird auch ein Knotendes Pfades, beide Pfade enden an der ClassifierRole, deren AssociationEnd den Rollennamen hat. DerTyp der NavigationCallExp, die die Pfade enthält, wird der Typ des Navigationsendes.

L

InsertPathEndAssociation1(rolename:String)

1:Path


5:ClassifierRole

7:ClassifierNode

6:Path

13:start

11:node

12:start 4:Classifier

9:base

10:base

15:Association

17:connection

18:connection

19:participant

20:participant

R

1:Path

2:ClassifierRole end

5:ClassifierRole

7:ClassifierNode

6:Path

13:start

11:node

12:start

4:Classifier

9:base

10:base

15:Association

17:connection

18:connection

19:participant

20:participant

end

:AssociationEndRole

:AssociationRole


start

end

navSource

base

base

base

participant

arnode




x= 1 v 0..1 y= 1 v 0..1


21:NavigationCallExp


22:nce

22:nce

23:nce

23:nce

3:Classifier name=n

3:Classifier name=n

NAC


type

type

:Classifier 2:ClassifierRole

navSource

:NavigationRoleExp

NAC

5:ClassifierRole

navSource

:NavigationRoleExp

NAC

Abb. 5.30: Einfügen des Pfadendes zweier äquivalenter Pfade


Es werden später Regeln definiert, die eine NavigationCallExp einfügen, deren Typ bereits beim Einfü-gen festgelegt ist (zum Beispiel müssen then- und else-Teil eines If-Then-Else-Ausdrucks denselben Typhaben). Deshalb wird eine weitere Regel benötigt, die dasselbe tut wie InsertPathEndAssociation1, beider aber auf der linken Seite eine NavigationCallExp mit einem Typ ist. Dieser Typ muss dann auchmit dem Typ des Pfadendes übereinstimmen. Die Regel ist ansonsten analog zu InsertPathEndAsso-ciation1.

L

InsertPathEndAssociation1_2(rolename:String)

1:Path


5:ClassifierRole

7:ClassifierNode

6:Path

13:start

11:node


9:base

10:base

15:Association

17:connection

18:connection

19:participant

20:participant

R

1:Path

2:ClassifierRole end

5:ClassifierRole

7:ClassifierNode

6:Path

13:start

11:node

12:start

4:Classifier

9:base

10:base

15:Association

17:connection

18:connection

19:participant

20:participant

end

:AssociationEndRole

:AssociationRole


start

end

navSource

base

base

base

participant

arnode




x= 1 v 0..1 y= 1 v 0..1




22:nce

22:nce

23:nce

23:nce

24:type

3:Classifier

3:Classifier

24:type

2:ClassifierRole

navSource

:NavigationRoleExp

NAC

5:ClassifierRole

navSource

:NavigationRoleExp

NAC



Die Regel InsertPathEndAssociationClass1 fügt eine AssociationClassRole zwischen die momentanenEnden zweier Pfade (was die NACs sicherstellen) ein. Dazu muss es eine enstprechende AssociationClass(aus dem UML Diagramm) und zwei ClassifierRoles vom Typ des Associationsendes und der Assoziati-onsklasse geben. Außerdem müssen die Kardinalitäten und andere Eigenschaften der Assoziationklasseüberprüft werden. Dann kann die AssociationClassRole, eine neue ClassifierRole vom Typ des anderenAssociationsendes und zwei AssociationEndRoles eingefügt werden. Die AssociationClassRole und dieneue ClassifierRole werden auch zu Knoten des Pfades, beide Pfade enden an der ClassifierRole vomTyp der Assoziationsklasse. Der Typ der NavigationCallExp, die die Pfade enthält, wird der Typ desNavigationsendes.

L

InsertPathEndAssociationClass1(rolename:String, classname:String)

1:Path


5:ClassifierRole

7:ClassifierNode

6:Path

13:start

11:node

12:start

3:Classifier 4:Classifier 9:base

10:type

15:AssociationClass

17:connection

18:connection

19:participant

20:participant

R

1:Path

end

7:ClassifierNode

6:Path

13:start

12:start

end

21:type



2:ClassifierRole

5:ClassifierRole

3:Classifier

4:Classifier

9:base

10:base

17:connection

18:connection

19:participant

20:participant

21:type



8:node

15:AssociationClass :AssociationClassRole

:AssociationEndRole

:AssociationEndRole

:ClassifierRole

base

base

base

participant

start

end

referredNode type

navSource



x= 1 v 0..1 y= 1 v 0..1


25:nce

23:nce


25:nce

type

type

:Classifier

NAC


23:nce

2:ClassifierRole

navSource

:NavigationRoleExp

NAC

5:ClassifierRole

navSource

:NavigationRoleExp

NAC



Die Regel InsertPathEndAssociationClass1_2 ist analog zur Regel InsertPathEndAssociationClass1,nur dass auf der linken Seite eine NavigationCallExp mit einem Typ ist. Dieser Typ muss dann auchmit dem Typ des Pfadendes übereinstimmen.

L

InsertPathEndAssociationClass1_2(rolename:String, classname:String)

1:Path


5:ClassifierRole

7:ClassifierNode

6:Path

13:start

11:node

12:start

3:Classifier 4:Classifier 9:base

10:base

15:AssociationClass

17:connection

18:connection

19:participant

20:participant

R

1:Path

end

7:ClassifierNode

6:Path

13:start

12:start

end

21:type



2:ClassifierRole

5:ClassifierRole

3:Classifier

4:Classifier

9:base

10:base

17:connection

18:connection

19:participant

20:participant

21:type



8:node

15:AssociationClass :AssociationClassRole

:AssociationEndRole

:AssociationEndRole

:ClassifierRole

base

base

base

participant

start

end

referredNode type

navSource



x= 1 v 0..1 y= 1 v 0..1


25:nce


25:nce

23:nce

26:type

26:type

23:nce

5:ClassifierRole

navSource

:NavigationRoleExp

NAC

2:ClassifierRole

navSource

:NavigationRoleExp

NAC



Es gibt eine abstrakte Regeln für das Einfügen eines Pfadendes zweier äquivalenter Pfade durch eineCRTMethod.

Die Regel InsertPathEndCRTMethod fügt eine Methode mit einem komplexen Rückgabetyp (eine Rol-le) zwischen die momentanen Enden zweier Pfade (was die NACs sicherstellen). Dazu muss es bereitszwei RoleNodes und eine entsprechende Operation (aus dem UML Diagramm) einer Klasse vom Typder einen NodeRole und einem Ergebnis vom Typ der anderen RoleNode geben. Dann kann die CRT-Method eingefügt werden. Die CRTMethod wird auch zu einem Knoten des Pfades, die Ergebnis-Rollewird das Ende beider Pfade. Der Typ der NavigationCallExp, die die Pfade enthält, wird der Typ desNavigationsendes.

L

InsertPathEndCRTMethod(mname:String)

1:Path

2:RoleNode 8:node

5:RoleNode

7:RoleNode

6:Path

13:start

11:node

12:start

9:base

R

1:Path

2:RoleNode end

5:RoleNode

7:RoleNode

6:Path

13:start

11:node

12:start

9:base

end


navSource

return

correspondingOp


3:Classifier 16:type


18:parameter



18:parameter

4:Class

11:base

10:feature

4:Class 11:base

10:feature

3:Classifier


22:nce

23:nce


23:nce

22:nce

16:type

type type

:Classifier

NAC


5:RoleNode

navSource

:NavigationRoleExp

NAC

2:RoleNode

navSource

:NavigationRoleExp

NAC



Die Regel InsertPathEndCRTMethod_2 ist analog zur Regel InsertPathEndCRTMethod, nur dass aufder linken Seite eine NavigationCallExp mit einem Typ ist. Dieser Typ muss dann auch mit dem Typdes Pfadendes übereinstimmen.

L

InsertPathEndCRTMethod_2(mname:String)

1:Path

2:RoleNode 8:node

5:RoleNode

7:RoleNode

6:Path

13:start

11:node

12:start

9:base

R

1:Path

2:RoleNode end

5:RoleNode

7:RoleNode

6:Path

13:start

11:node

12:start

9:base

end


navSource

return

correspondingOp




18:parameter



18:parameter

4:Class

11:base

10:feature

4:Class 11:base

10:feature

3:Classifier


22:nce

23:nce


23:nce

22:nce

16:type

24:type

24:type

2:RoleNode

navSource

:NavigationRoleExp

NAC

5:RoleNode

navSource

:NavigationRoleExp

NAC



Die Regel InsertPathEndIncludes fügt eine Ist-Enthalten-Operation zwischen die momentanen Endenzweier Pfade (was die NACs sicherstellen). Dazu muss es bereits eine CollectionRole und eine Classifier-Role (die beiden momentanen Pfadenden) geben. Dann kann die Includes-Operation eingefügt werden,die ausdrückt, dass die ClassifierRole ein Element der CollectionRole ist. Das Ergebnis einer Includes-Operation ist eine Konstante (true) vom Typ Boolean. Die ClassifierRole wird das Ende beider Pfade.Der Typ der NavigationCallExp, die die Pfade enthält, wird der Typ des Navigationsendes.

L

InsertPathEndIncludes(opname:IncOpEnum)

1:Path

2:CollectionRole 8:node

5:ClassifierRole

7:RoleNode

6:Path

13:start

11:node


9:base

10:base

R

1:Path

2:CollectionRole

end

5:ClassifierRole

7:RoleNode

6:Path

13:start

end 12:start

4:Classifier

9:base

10:base

:IncludesOp name=opname

arg2

navSource

:Classifier name="Boolean"

result

opname = #includes v #excludes

8:node

:LiteralExp name="true"

type


22:nce

23:nce


22:nce

23:nce

type

type

:Classifier

NAC


2:CollectionRole

navSource

:NavigationRoleExp

NAC

5:ClassifierRole

navSource

:NavigationRoleExp

NAC



Die Regel InsertPathEndIncludes_2 ist analog zur Regel InsertPathEndIncludes, nur dass auf derlinken Seite eine NavigationCallExp mit einem Typ ist. Dieser Typ muss dann auch mit dem Typ desPfadendes übereinstimmen.

L

InsertPathEndIncludes_2(opname:IncOpEnum)

1:Path


5:ClassifierRole

7:RoleNode

6:Path

13:start

11:node

12:start

4:Classifier

9:base

10:base

R

1:Path

2:CollectionRole

end

5:ClassifierRole

7:RoleNode

6:Path

13:start

end 12:start

4:Classifier

9:base

10:base


arg2

navSource


result

opname = #includes v #excludes

8:node


type


22:nce

23:nce


22:nce

23:nce

20:type 20:type

2:CollectionRole

navSource

:NavigationRoleExp

NAC

5:ClassifierRole

navSource

:NavigationRoleExp

NAC


Die Regel InsertPathEndIncludesAll fügt eine Ist-Enthalten-Operation zwischen die momentanen En-den zweier Pfade (was die NACs sicherstellen). Dazu muss es bereits zwei CollectionRoles (die beidenmomentanen Pfadenden) geben. Dann kann die Includes-Operation eingefügt werden, die ausdrückt,dass alle Elemente der einen CollectionRole auch Elemente der anderen CollectionRole sind. Das Er-gebnis einer Includes-Operation ist eine Konstante (true) vom Typ Boolean. Eine CollectionRole wirddas Ende beider Pfade. Der Typ der NavigationCallExp, die die Pfade enthält, wird der Typ desNavigationsendes.

Die Regel InsertPathEndIncludesAll_2 ist analog zur Regel InsertPathEndIncludesAll, nur dass aufder linken Seite eine NavigationCallExp mit einem Typ ist. Dieser Typ muss dann auch mit dem Typdes Pfadendes übereinstimmen.


L

InsertPathEndIncludesAll(opname:IncOpEnum)

R

opname = #includesAll v #excludesAll

1:Path


5:CollectionRole

7:RoleNode

6:Path

13:start

11:node


9:base

10:base

1:Path

2:CollectionRole

end

5:CollectionRole

7:RoleNode

6:Path

13:start

end 12:start

4:Classifier

9:base

10:base


arg2

navSource


result

8:node


type


22:nce

23:nce


22:nce

23:nce

type

type

:Classifier

NAC


2:CollectionRole

navSource

:NavigationRoleExp

NAC

5:CollectionRole

navSource

:NavigationRoleExp

NAC


L

InsertPathEndIncludesAll_2(opname:IncOpEnum)

R

opname = #includesAll v #excludesAll

1:Path


5:CollectionRole

7:RoleNode

6:Path

13:start

11:node

12:start

4:Classifier

9:base

10:base

1:Path

2:CollectionRole

end

5:CollectionRole

7:RoleNode

6:Path

13:start

end 12:start

4:Classifier

9:base

10:base


arg2

navSource


result

8:node


type


22:nce

23:nce


22:nce

23:nce

20:type 20:type

2:CollectionRole

navSource

:NavigationRoleExp

NAC

5:CollectionRole

navSource

:NavigationRoleExp

NAC



InsertStartAssociation

InsertStartAssociationToCR(rn, cn) or InsertStartAssociationToSet(rn, cn) or InsertStartAssociationToBag(rn, cn) or InsertStartAssociationToSequence(rn, cn) or InsertStartAssociationSetToSet(rn, cn) or InsertStartAssociationSetToBag(rn, cn) or InsertStartAssociationSetToSequence(rn, cn) ;

InsertStartRole

InsertStartRoleSelf() xor InsertStartRoleCVar() xor InsertAllInstancesExp() xor InsertStartRoleSelf2() ;

InsertStartAssociationClass

analog zu InsertStartAssociation

InsertStartCRTMethod

analog zu InsertStartAssociation ; AsLongAsPossible (InsertCRTMethodArgL(ln) or InsertCRTMethodArgV(vn)) ;

InsertAssociation

InsertAssociationToCR(rn, cn) or InsertAssociationToSet(rn, cn) or InsertAssociationToBag(rn, cn) or InsertAssociationToSequence(rn, cn) or InsertAssociationSetToSet(rn, cn) or InsertAssociationSetToBag(rn, cn) or InsertAssociationSetToSequence(rn, cn) or InsertAssociationBagToSet(rn, cn) or InsertAssociationBagToBag(rn, cn) or InsertAssociationBagToSequence(rn, cn) or InsertAssociationSequenceToSet(rn, cn) or InsertAssociationSequenceToBag(rn, cn) or InsertAssociationSequenceToSequence(rn, cn) ;

InsertAssociationClass

analog zu InsertAssociation

InsertCRTMethod

analog zu InsertAssociation ; AsLongAsPossible (InsertCRTMethodArgL(ln) or InsertCRTMethodArgV(vn)) ;

InsertNavLoop

InsertAnyShortCut or InsertSelectionShortCut or InsertCollectShortCut or InsertSortedByShortCut(vn, an) or InsertAnyLoop or InsertSortedByLoop or InsertCollectLoop or InsertSelectionLoop ;

InsertCollectionOp

InsertMathSetOpSetResult1(on) or InsertMathSetOpSetResult2(on) or InsertMathSetOpSetResult3(on) or InsertMathSetOpBagResult1(on) or InsertMathSetOpBagResult2(on) or InsertMathSetOpBagResult3(on) or InsertMathSetOpSequenceResult1(on) or InsertMathSetOpSequenceResult2(on) or InsertMathSetOpSequenceResult3(on) ;

InsertPathEndAssociation

InsertAssociation1(rn) or InsertAssociation1_2(rn) or InsertAssociation2(rn) or InsertAssociation2_2(rn) or InsertAssociation3(rn) or InsertAssociation3_2(rn) or InsertAssociation4(rn) or InsertAssociation4_2(rn) or InsertAssociation5(rn) or InsertAssociation5_2(rn) or InsertAssociation6(rn) or InsertAssociation6_2(rn) or InsertAssociation7(rn) or InsertAssociation7_2(rn) or InsertAssociation8(rn) or InsertAssociation8_2(rn) or InsertAssociation9(rn) or InsertAssociation9_2(rn) or InsertAssociation10(rn) or InsertAssociation10_2(rn) or InsertAssociation11(rn) or InsertAssociation11_2(rn) or InsertAssociation12(rn) or InsertAssociation12_2(rn) or InsertAssociation13(rn) or InsertAssociation13_2(rn) ;

InsertPathEndAssociationClass

analog zu InsertPathEndAssociation

InsertPathEndCRTMethod

InsertPathEndCRTMethod(mn) or InsertPathEndCRTMethod_2(mn) ; AsLongAsPossible (InsertCRTMethodArgL(ln)

or InsertCRTMethodArgV(vn)) ;

InsertStartNav

InsertStartAssociation xor InsertStartAssociationClass xor InsertStartCRTMethod xor InsertNavLoop ;

InsertMessageNode

InsertOperationMessageOp(mk, mn) or InsertSignalMessageOp(mk, mn ) ; AsLongAsPossible

(InsertMessageArgLiteral(ln) or InsertMethodArgVar(vn) or InsertMessageArgUnspecified() or InsertMessageArgLiteral2(ln) or InsertMethodArgVar2(vn) or InsertMessageArgUnspecified2() ) ;

Die oben dargestellten Transformation Units dienen mehr der Übersichtlichkeit der folgenden Trans-formation Units, sie gruppieren z.B. die 7 verschiedenen Regeln zum Einfügen einer Start-Assoziationzu einer Transformation Unit.


InsertPathStart

InsertStartRole ; InsertStartNav ;

InsertPathEnd

InsertPathEndAssociation xor InsertPathEndAssociationClass xor InsertPathEndCRTMethod(mn) xor InsertPathEndIncludes(mn) xor InsertPathEndIncludesAll(mn) ;

InsertPathNode

InsertAssociation or InsertAssociationClass or InsertCRTMethod or InsertNavLoop or InsertCollectionOp ;

InsertEquivalentPathes

InsertNavigationCallExpression() ; InsertPathStart ; InsertEquivalentNavs ;

InsertEquivalentNavs

(InsertNewPath() ; InsertStartNav ; ) * ; InsertPathNode *; AsLongAsPossible InsertPathEnd ;

Die Transformation Unit InsertPathStart fügt eine Startrolle und einen Navgationsstart, der an dieserRolle beginnt, ein.Die Transformation Unit InsertPathNode fügt einen Pfadknoten, also eine neue RoleNode, in einenPfad ein. Das kann wie bereits beschrieben durch eine Assoziation, Assoziationsklasse, eine Methodemit komplexem Ergebnis (CRTMethod), eine MessageExp, die eine Sequenz von Messages liefert (sieheSeite 158), oder eine Operation auf Collections, die eine Rolle liefert (eine mathematische Mengenope-ration oder eine Iteration, ab S. 182) sein.Die Transformation Unit InsertPathEnd fügt eine der Regeln zum Zusammenführen zweier Pfade zueinem gemeinsamen Pfadende ein.Die Transformation Unit ist InsertEquivalentPathes steuert das Einfügen beliebig vieler äquivalenterPfade. Es wird zunächst eine NavigationCallExp und ein Pfadanfang, dann beliebig viele weitere Pfa-danfänge (eine Classifier- oder SetRole), und danach beliebig viele Knoten eingefügt. Danach werdenalle Navigationsenden mit einer Endrolle verknüpft.


Navigation zu Attributwerten oder Methodenaufrufen

Auch die Navigation zu Attributwerten oder Methodenaufrufen beginnt an einer Startrolle und kanneinen Pfad enthalten. Von jeder ClassifierRole kann zu einem ihrer Attribute oder einem Methoden-aufruf navigiert werden. Mit dem Attribut- bzw. Rückgabewert kann eine arithmetische Operationdurchgeführt werden. Dies kann gleich innerhalb der Navigation geschehen oder der Wert wird zu-nächst einer Variablen zugewiesen und die Aussage über ihren Wert wird mit Hilfe einer Bedingung(Condition) im Bedingungsteil des Constraints dargestellt. Bei solchen arithmetischen Operationenkönnen Variablen als Argumente auftreten, d.h. innerhalb eines Pfades können auch Navigationen zuAttributen oder Methodenaufrufen vorkommen, die lediglich dem Speichern eines Wertes in einer Va-riablen dienen (die Regeln InsertAttributeAssignment(vn, an) oder InsertMethod2(mn, vn)).Die Navigation zu einfachen Operationen auf Collections beginnt auch an einer Startrolle und navigiertzu einer Collection, dann folgt die Operation, welche nur im Falle der Operation size (#, die RegelInsertSimpleCollExp2(on, vn)) eine Zuweisung an eine Variable enthalten kann.

Die Regel InsertAttributeOp fügt an eine ClassifierRole ein Attribut, eine Operation und einen arith-metischen Ausdruck ein. Die Operation ist eine Vergleichsoperation, die den Wert des Attributes derClassifierRole mit dem arithmetischen Ausdruck vergleicht. Dieser muss durch weitere Regeln zu einemkorrekten Ausdruck erweitert werden. Die Regel kann angewendet werden, wenn die ClassifierRole einPfadknoten ist, von dem nicht weiternavigiert wird, an sie keine Message gesendet und sie keine Darstel-lung eines Zustands hat (NACs). Außerdem muss die Basisklasse ein Attribut mit dem übergebenenNamen haben und es muss eine entsprechende Operation mit Argumenten des Typs des Attributesexistieren. Die ClassifierRole wird zum Pfadende und der Typ der NavigationCallExp, die den Pfadeenthält, ist der Typ des Attributs.

L R InsertAttributeOp(opname:OpEnum, attrname:String)

1:ClassifierRole 1:ClassifierRole

attrop

:AttributeOp name=opname

argument

:ArithmExp

attribute 3:Attribute name=attrname

2:Classifier

4:Classifier

5:base

6:feature

7:type

3:Attribute name=attrname

2:Classifier

4:Classifier

5:base

6:feature

7:type

type

8:Operation name=opname

11:type

9:Parameter kind=#in

12:parameter


12:parameter

11:type


13:Path 13:Path

14:node end

1:ClassifierRole

target

:VOCLMessage

NAC

1:ClassifierRole

state

:VOCLState

NAC

15:NavigationCallExp 16:nce


type

type

:Classifier

NAC


1:ClassifierRole

navSource

:NavigationRoleExp

NAC

Abb. 5.40: von einer ClassifierRole wird zu einem Attribut navigiert,dieses ist Argument eines arithmetischen Ausdrucks

Die Regel InsertAttributeOp_2 ist analog zur Regel InsertAttributeOp, nur dass auf der linken Seiteeine NavigationCallExp mit einem Typ ist. Dieser Typ muss dann auch mit dem Typ des Pfadendesübereinstimmen.


L R InsertAttributeOp_2(opname:OpEnum, attrname:String)


attrop


argument

:ArithmExp


2:Classifier

4:Classifier

5:base

6:feature

7:type


2:Classifier

4:Classifier

5:base

6:feature

7:type

type


11:type


12:parameter


12:parameter

11:type


13:Path 13:Path

14:node end

1:ClassifierRole

target

:VOCLMessage

NAC

1:ClassifierRole

state

:VOCLState

NAC



16:type

16:type

1:ClassifierRole

navSource

:NavigationRoleExp

NAC

Abb. 5.41: von einer ClassifierRole wird zu einem Attribut navigiert,dieses ist Argument eines arithmetischen Ausdrucks

Die Regel InsertMethodOp fügt an eine ClassifierRole einen Methodenaufruf, eine Operation und einenarithmetischen Ausdruck ein. Die Operation ist eine Vergleichsoperation, die den Ergebniswert des Me-thodenaufrufs auf die ClassifierRole mit dem arithmetischen Ausdruck vergleicht. Dieser muss durchweitere Regeln zu einem korrekten Ausdruck erweitert werden. Die Regel kann angewendet werden,wenn die ClasifierRole ein Pfadknoten ist, von dem nicht weiternavigiert wird, an sie keine Messa-ge gesendet und sie keine Darstellung eines Zustands hat, es darf nur ein Methodenaufruf auf eineClassifierRole angewandt werden (NACs). Außerdem muss die Basisklasse eine Operation mit demübergebenen Namen haben und es muss eine entsprechende Operation mit Argumenten des Typs desErgebnisses der Operation (der Basisklasse) existieren. Die ClassifierRole wird zum Pfadende und derTyp der NavigationCallExp, die den Pfad enthält, wird der Typ des Ergebnisses des Methodenaufrufs.

Die Regel InsertMethodOp_2 ist analog zur Regel InsertMethodOp, nur dass auf der linken Seiteeine NavigationCallExp mit einem Typ ist. Dieser Typ muss dann auch mit dem Typ des Pfadendesübereinstimmen.


L R InsertMethodOp((methodname:String, opname: OpEnum)

2:Classifier

1:ClassifierRole

3:Operation name=methodname

5:Classifier 6:type


7:parameter

8:base

9:feature 2:Classifier

1:ClassifierRole


5:Classifier

6:type


7:parameter

8:base

9:feature

:Method name=opname methodOp

argument

:ArithmExp

method :MethodOp name=opname

correspondingOp

type

1:ClassifierRole

methodOp

:MethodOp

NAC

10:Path 10:Path

11:node end


13:type


12:parameter

method


15:Parameter kind=#in 12:parameter

13:type correspondingOp

1:ClassifierRole

target

:VOCLMessage

NAC

1:ClassifierRole

state

:VOCLState

NAC


17:nce 16:NavigationCallExp

17:nce

type

type

:Classifier

NAC


1:ClassifierRole

navSource

:NavigationRoleExp

NAC

Abb. 5.42: von einer ClassifierRole wird zu einem Methodenaufruf navigiert,dieses ist Argument eines arithmetischen Ausdrucks

L R InsertMethodOp_2(methodname:String, opname: OpEnum)

2:Classifier

1:ClassifierRole


5:Classifier 6:type


7:parameter

8:base

9:feature 2:Classifier

1:ClassifierRole


5:Classifier

6:type


7:parameter

8:base

9:feature

:Method name=opname methodOp

argument

:ArithmExp

method :MethodOp name=opname

correspondingOp

type

1:ClassifierRole

methodOp

:MethodOp

NAC

10:Path 10:Path

11:node end


13:type


12:parameter

method


15:Parameter kind=#in 12:parameter

13:type correspondingOp

1:ClassifierRole

target

:VOCLMessage

NAC

1:ClassifierRole

state

:VOCLState

NAC


17:nce 16:NavigationCallExp

17:nce

18:type

18:type

1:ClassifierRole

navSource

:NavigationRoleExp

NAC

Abb. 5.43: von einer ClassifierRole wird zu einem Methodenaufruf navigiert,dieses ist Argument eines arithmetischen Ausdrucks


Die folgenden beiden Regeln InsertMethodArgLiteral und InsertMethodArgVar fügen an eine bereitseingefügte Methode, die auf einen RoleNode angewendet wird, die Argumente (eine Konstante oderschon definierte Variable) ein. Dazu muss die korrespondierende Operation jeweils einen Parameter desentsprechenden Typs haben, zu jedem Parameter gibt es nur ein Argument (NAC).

L R

InsertMethodArgLiteral(argname:String)

5:correspondingOp

2:Operation

1:Method

3:Parameter

7:type 5:correspondingOp

2:Operation

1:Method

3:Parameter

7:type

:LiteralExp name=argname

type


6:parameter order=n

6:parameter order=n

argument order=n

1:Method

argument order=n

NAC

:Argument

Abb. 5.44: Einfügen eines Methodenarguments (Konstante)

L R

InsertMethodArgVar(argname:String)

5:correspondingOp

2:Operation

1:Method

3:Parameter

7:type

8:VariableDeclaration varName=argname

9:type

5:correspondingOp

2:Operation

1:Method

3:Parameter

7:type

8:VariableDeclaration varName=argname

9:type


argument order=n

6:parameter order=n

6:parameter order=n 1:Method

argument order=n

NAC

:Argument

Abb. 5.45: Einfügen eines Methodenarguments (Variable)

Ein arithmetischer Ausdruck kann entweder eine Konstante oder eine Variable oder eine weitere Ope-ration mit Argumenten sein. Für jeden dieser drei Fälle gibt es eine Regel. InsertArithmExpLiteralfügt als arithmetischen Ausdruck eine Konstante des entsprechenden Typs ein, InsertArithmExpVaria-ble fügt als arithmetischen Ausdruck eine bereits vorhandene Variable des entsprechenden Typs ein.InsertArithmExpOperation fügt als arithmetischen Ausdruck eine Operation (ArithmOp) ein, zu deres eine korrespondierende Operation mit entsprechendem output-Parameter geben muss.


L R

InsertArithmExpLiteral(literalname:String)

1:ArithmExp 1:ArithmExp

:LiteralExp name=literalname

literal

NAC

type

2:Classifier

3:type

2:Classifier

3:type

1:ArithmExp

:LiteralExp

literal

NAC

1:ArithmExp

:VariableDeclaration

variable

NAC

1:ArithmExp

:ArithmOp

op

Abb. 5.46: das 2. Argument des arithmetischen Ausdrucks ist eine Konstante

L R

InsertArithmExpVariable(vname:String)

variable



1:ArithmExp 1:ArithmExp

2:Classifier

3:type

2:Classifier

3:type

NAC

1:ArithmExp

:LiteralExp

literal

NAC

1:ArithmExp


variable

4:type 4:type NAC

1:ArithmExp

:ArithmOp

op

Abb. 5.47: das 2. Argument des arithmetischen Ausdrucks ist eine Variable

L R

InsertArithmExpOperation(opname:ArOpEnum)


1:ArithmExp

5:type

:ArithmOp name=opname

op

2:Classifier 3:Parameter kind=#out 6:type

7:parameter


1:ArithmExp

5:type

2:Classifier 3:Parameter kind=#out 6:type

correspondingOp

NAC

1:ArithmExp

:LiteralExp

literal

NAC

1:ArithmExp


variable

NAC

1:ArithmExp

:ArithmOp

op

Abb. 5.48: das 2. Argument des arithmetischen Ausdrucks ist eine weitere arithmetische Operation, die zweiArgumente hat

Eine arithmetische Operation hat Argumente, die wiederum Konstanten, Variablen oder weitere arith-metische Operationen sein können. Für jeden dieser drei Fälle gibt es eine Regel. InsertArithmO-pArgLiteral fügt als Argument eine Konstante des entsprechenden Typs ein, InsertArithmpArgVariablefügt als Argument eine bereits vorhandene Variable des entsprechenden Typs ein. InsertArithmpArg-Operation fügt als Argument eine weitere Operation (ArithmOp) ein, zu der es eine korrespondierende


Operation mit entsprechendem output-Parameter geben muss. Zum jeweiligen Argument muss die kor-respondierende Operation einen Parameter des entsprechenden Typs haben und zu jedem Parametergibt es nur ein Argument (NACs).

L R

InsertArithmOpArgLiteral(literalname:String)

NAC NAC NAC

1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp

1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp

7:parameter

:LiteralExp name=literalname

7:parameter

argl

1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp

7:parameter

:LiteralExp argl

1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp

7:parameter

:VariableDeclaration argV

1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp

7:parameter

:ArithmOp argOp

Abb. 5.49: ein Argument der arithmetischen Operation ist eine Konstante, es gibt genau 2 Argumente

InsertArithmOpArgVariable(vname:String)

L R

NAC NAC NAC

1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp

1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp

7:parameter 7:parameter

argV

1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp

7:parameter

:LiteralExp argl

1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp

7:parameter


1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp

7:parameter

:ArithmOp argOp


8:type


8:type

Abb. 5.50: ein Argument der arithmetischen Operation ist eine Variable


InsertArithmOpArgOperation(opname:ArOpEnum)

L R

NAC NAC NAC

1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp

1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp


argOp

1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp

7:parameter

:LiteralExp argl

1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp

7:parameter


1:ArithmOp

2:Operation

3:Parameter

4:Classifier

6:type

5:correspondingOp

7:parameter

:ArithmOp argOp

:ArithmOp name=opname 8:Operation

name=opname


10:parameter

11:type



10:parameter

11:type

:correspondingOp

Abb. 5.51: ein Argument der arithmetischen Operation ist eine weitere arithmetische Operation

Die folgende Transformation Unit beinhaltet das Einfügen eines arithmetischen Ausdrucks, der dasArgument einer AttributeOp oder einer MethodOp ist. Es kann entweder eine Konstante, eine Variableoder eine weitere arithmetische Operation mit ihren Argumenten sein.

InsertArithmExp

InsertArithmExpLiteral(ln) xor InsertArithmExpVariable(vn) xor (InsertArithmExpOperation(on) ; AsLongAsPossible (InsertArithmOpArgLiteral(ln) or

InsertArithmOpArgVariable(vn) or InsertArithmOpArgOperation(on) ) ; ) ;


Die Regel InsertAttributeAssignment fügt eine Variablenzuweisung mit einer Variablen und einemAttribut an eine ClassifierRole an. Der Wert des Attributes wird der Variablen zugewiesen, weshalb siedenselben Typ haben. Um diese Regel anwenden zu können, muss die Basisklasse der ClassifierRole einentsprechendes Attribut haben und von der ClassifierRole darf nicht weiternavigiert werden, da diesenach der Regelanwendung das Ende des Pfades wird. Außerdem darf noch keine Variable mit diesemNamen im Constraint existieren und ein Attributwert immer nur einer Variablen zugewiesen werden.Der Typ der NavigationCallExp, die den Pfad enthält, wird der Typ des Attributs.

InsertAttributeAssignment(vname:String, attrname:String)

L R


attrass attribute


2:Classifier

4:Classifier

5:base

6:feature

7:type


2:Classifier

4:Classifier

5:base

6:feature

7:type :VariableDeclaration varName=vname

variable

:AttributeAssignment

type

NAC

1:ClassifierRole

attrass

attribute



NAC

10:Constraint

:VariableDeclaration varName=vname

variable

8:Path

9:NavigationCallExp

10:Constraint

11:node

12:nce

13:exp

8:Path

9:NavigationCallExp

10:Constraint

end

12:nce

13:exp

variable type

type

:Classifier

NAC

9:NavigationCallExp

1:ClassifierRole

navSource

:NavigationRoleExp

NAC

Abb. 5.52: ein Attributwert wird einer Variablen zugewiesen

Die Regel InsertAttributeAssignment_2 ist analog zur Regel InsertAttributeAssignment, nur dass aufder linken Seite eine NavigationCallExp mit einem Typ ist. Dieser Typ muss dann auch mit dem Typdes Pfadendes übereinstimmen.

Die Regel InsertAttributeAssignment2 fügt eine Variablenzuweisung mit einer Variablen und einemAttribut an eine ClassifierRole an. Diese Variablenzuweisung darf auch mitten im Pfad angewendetwerden, d.h. hier ist nicht die NAC der Regel InsertAttributeAssignment, die eine weitere Navigationverbieten. Ansonsten sind die beiden Regeln analog.


InsertAttributeAssignment_2(vname:String, attrname:String)

L R


attrass attribute


2:Classifier

4:Classifier

5:base

6:feature

7:type


2:Classifier

4:Classifier

5:base

6:feature


variable


type

NAC

1:ClassifierRole

attrass

attribute



NAC

10:Constraint


variable

8:Path

9:NavigationCallExp

10:Constraint

11:node

12:nce

13:exp

8:Path

9:NavigationCallExp

10:Constraint

end

12:nce

13:exp

variable 14:type 14:type

1:ClassifierRole

navSource

:NavigationRoleExp

NAC


InsertAttributeAssignment2(vname:String, attrname:String)

L R


attrass attribute


2:Class

4:Classifier

5:base

6:feature

7:type


2:Class

4:Classifier

5:base

6:feature


variable


type

NAC

1:ClassifierRole

attrass

attribute



NAC

10:Constraint


variable

8:Path

9:NavigationCallExp

10:Constraint

11:node

12:nce

13:exp

8:Path

9:NavigationCallExp

10:Constraint

12:nce

13:exp

variable

11:node



Die Regel InsertMethod1 fügt einen Methodenaufruf auf einen RoleNode ein. Das Ergebnis ist einboolescher Wert, der RoleNode wird nach der Regelanwendung das Ende des Pfades. Der entsprechendeVOCL Constraint sagt aus, dass die Methode true liefern muss. Um diese Regel anwenden zu können,muss die Basisklasse des RoleNodes eine entsprechende Operation haben und von dem RoleNode darfnicht weiternavigiert werden. Außerdem darf an einem RoleNode nur eine Methode oder Messagehängen und er darf keine Darstellung seines Zustands besitzen. Der RoleNode wird zum Pfadende undder Typ der NavigationCallExp, die den Pfad enthält, wird der Typ des Navigationsendes.

L R InsertMethod1(mname:String)

1:RoleNode type

2:Classifier


6:type


7:parameter 8:feature

9:base

1:RoleNode

2:Classifier




9:base :Method name=mname

method

5:Classifier name=Boolean

5:Classifier name=Boolean 6:type

correspondingOp

NAC

1:RoleNode

method

:Method

10:Path

end

10:Path

11:node

1:RoleNode

state

:VOCLState

NAC

1:RoleNode

target

:VOCLMessage

NAC


13:nce


13:nce

type

type

:Classifier

NAC


1:RoleNode

navSource

:NavigationRoleExp

NAC

Abb. 5.55: der Rückgabewert der Methode ist true

Die Regel InsertMethod1_2 ist analog zur Regel InsertMethod1, nur dass auf der linken Seite eineNavigationCallExp mit einem Typ ist. Dieser Typ muss dann auch mit dem Typ des Pfadendes über-einstimmen.

L R InsertMethod1_2(mname:String)

1:RoleNode type

2:Classifier


6:type



9:base

1:RoleNode

2:Classifier





method


5:Classifier name=Boolean 6:type

correspondingOp

NAC

1:RoleNode

method

:Method

10:Path

end

10:Path

11:node

1:RoleNode

state

:VOCLState

NAC

1:RoleNode

target

:VOCLMessage

NAC


13:nce


13:nce

14:type 14:type

1:RoleNode

navSource

:NavigationRoleExp

NAC

Abb. 5.56: der Rückgabewert der Methode ist true


Die Regel InsertMethod2 fügt einen Methodenaufruf auf einen RoleNode ein. Das Ergebnis wird einerVariablen zugewiesen, der RoleNode wird nach der Regelanwendung das Ende des Pfades. Die Va-riable hat den Typ des output-Parameters der entsprechenden Operation. Um diese Regel anwendenzu können, muss die Basisklasse des RoleNodes eine entsprechende Operation haben und von demRoleNode darf nicht weiternavigiert werden. Außerdem darf an einem RoleNode nur eine Methodeoder Message hängen und er darf keine Darstellung seines Zustands besitzen. Es darf auch noch keineVariable mit dem Namen der neu einzufügenden Variablen im Constraint existieren (NACs). Der Ro-leNode wird zum Pfadende und der Typ der NavigationCallExp, die den Pfad enthält, wird der Typdes Navigationsendes.

L

R

InsertMethod2(mname:String,vname:String)

1:RoleNode

type

2:Classifier


6:type



9:base

1:RoleNode

2:Classifier


4:Parameter kind=#return 7:parameter

8:feature


method 6:type

correspondingOp

:VariableDeclaration varame=vname

resultVar

5:Classifier

5:Classifier type

NAC

1:RoleNode

method

:Method

NAC

10:Constraint


variable

8:Path

9:NavigationCallExp

10:Constraint

end

12:nce

13:exp

variable

8:Path

9:NavigationCallExp

10:Constraint

11:node

12:nce

13:exp

1:RoleNode

state

:VOCLState

NAC

1:RoleNode

target

:VOCLMessage

NAC

type

type

:Classifier

NAC

9:NavigationCallExp

1:RoleNode

navSource

:NavigationRoleExp

NAC

Abb. 5.57: der Rückgabewert der Methode wird einer Variablen zugewiesen

Die Regel InsertMethod2WithNavType ist analog zur Regel InsertMethod2, nur dass auf der linken Seiteeine NavigationCallExp mit einem Typ ist. Dieser Typ muss dann auch mit dem Typ des Pfadendesübereinstimmen.

Die Regel InsertMethod2_2 fügt einen Methodenaufruf auf einen RoleNode ein. Das Ergebnis wird einerVariablen zugewiesen, die Variable hat den Typ des output-Parameters der entsprechenden Operation.Um diese Regel anwenden zu können, muss die Basisklasse des RoleNodes eine entsprechende Operationhaben. Außerdem darf an einem RoleNode nur eine Methode oder Message hängen und er darf keineDarstellung seines Zustands besitzen. Es darf auch noch keine Variable mit dem Namen der neueinzufügenden Variablen im Constraint existieren (NACs).


L

R

InsertMethod2WithNavType(mname:String,vname:String)

1:RoleNode

type

2:Classifier


6:type



9:base

1:RoleNode

2:Classifier



8:feature


method 6:type

correspondingOp


resultVar

5:Classifier

5:Classifier type

NAC

1:RoleNode

method

:Method

NAC

10:Constraint


variable

8:Path

9:NavigationCallExp

10:Constraint

end

12:nce

13:exp

variable

8:Path

9:NavigationCallExp

10:Constraint

11:node

12:nce

13:exp

1:RoleNode

state

:VOCLState

NAC

1:RoleNode

target

:VOCLMessage

NAC

14:type

14:type

1:RoleNode

navSource

:NavigationRoleExp

NAC


L

R

InsertMethod2_2(mname:String,vname:String)

1:RoleNode

type

2:Class


6:type



9:base

1:RoleNode

2:Class



8:feature


method 6:type

correspondingOp


resultVar

5:Classifier

5:Classifier type

NAC

1:RoleNode

method

:Method

NAC

10:Constraint


variable

8:Path

9:NavigationCallExp

10:Constraint

12:nce

13:exp

variable

8:Path

9:NavigationCallExp

10:Constraint

11:node

12:nce

13:exp

11:node

1:RoleNode

state

:VOCLState

NAC

1:RoleNode

target

:VOCLMessage

NAC



Die folgenden vier Transformation Units definieren das Einfügen einer Navigation zu einem Attribut-wert oder zu einem Methodenaufruf. Es wird eine NavigationCallExp eingefügt und dann von einerStartrolle entlang eines Pfades navigiert. Dieser Pfad kann Zuweisungen von Werten an Variablenoder Aussagen über Zustände (durch die Regeln InsertAttributeAssignment2(vn, an) or InsertMe-thod2_2(mn, rv) or InsertSimpleCollOp2_2(on, vn) or (InsertState2(sn1); InsertSubState(sn2)*;))enthalten. Diese Variablen sind Argumente der am Schluss eingefügten arithmetischen Operation/en.

InsertAttributeNav

(InsertNewPath() or InsertPathNode or InsertAttributeAssignment2(vn, an) or InsertMethod2_2(mn, rv) or InsertSizeExp2(on, vn) or (InsertState2(sn1) ; InsertSubState(sn2) *; )) ; AsLongAsPossible (InsertMethodArgLiteral(ln) or InsertMethodArgVar(vn))) * ; InsertAttributeOp(on, an) or InsertAttributeOp_2(on, an) ; InsertArithmExp ;

InsertAttributeNavigation

InsertNavigationCallExp ; InsertPathStart ; InsertAttributeNav ;

InsertMethodNav

(InsertNewPath() or InsertPathNode or InsertAttributeAssignment2(vn, an) or InsertMethod2_2(mn, rv) or InsertSizeExp2(on, vn) or (InsertState2(sn1) ; InsertSubState(sn2) *; )) ; AsLongAsPossible (InsertMethodArgLiteral(ln) or InsertMethodArgVar(vn))) *; (InsertMethodOp(on) or InsertMethodOp_2(on) ) xor (InsertMethod1(mn) or InsertMethod1_2(mn)) ; AsLongAsPossible (InsertMethodArgLiteral(ln) or InsertMethodArgVar(vn)) ; InsertArithmExp ;

InsertMethodNavigation

InsertNavigationCallExp ; InsertPathStart ; InsertMethodNav ;


Die Regel InsertEmptyExp fügt eine isEmpty oder notEmpty-Operation auf eine Collection ein, dieausdrücken, dass die CollectionRole entweder leer ist oder nicht. Nach der Regelanwendung ist dieCollectionRole das Ende des Pfades. Deshalb kann die Regel nur angewendet werden, wenn von derCollectionRole nicht weiternavigiert wird. Es kann nur eine Operation auf Collections angewendetwerden (NACs). Der Typ der NavigationCallExp, die den Pfad enthält, wird der Typ des Navigations-endes.

R

InsertEmptyExp(opname:SCOEnum)

1:CollectionRole

:SimpleCollectionExp name=opname

sco


type

L

1:CollectionRole


3:Path 4:node

3:Path

end

1:CollectionRole

method

:Method

NAC

opname = "isEmpty" v "notEmpty"

5:NavigationCallExp

6:nce 7:Classifier

8:base

5:NavigationCallExp

6:nce

7:Classifier 8:base

type

type

:Classifier

NAC

5:NavigationCallExp

1:CollectionRole

navSource

:NavigationRoleExp

NAC

Abb. 5.60: eine einfache Operation auf Collections wird eingefügt (entweder isEmpty oder notEmpty)

Die Regel InsertEmptyExp_2 ist analog zur Regel InsertEmptyExp, nur dass auf der linken Seiteeine NavigationCallExp mit einem Typ ist. Dieser Typ muss dann auch mit dem Typ des Pfadendesübereinstimmen.

R

InsertEmptyExp_2(opname:SCOEnum)

1:CollectionRole

:SimpleCollectionExp name=opname

sco


type

L

1:CollectionRole


3:Path 4:node

3:Path

end

1:CollectionRole

method

:Method

NAC

opname = "isEmpty" v "notEmpty"

5:NavigationCallExp

6:nce 7:Classifier

8:base

5:NavigationCallExp

6:nce

7:Classifier 8:base

9:type 9:type

1:CollectionRole

navSource

:NavigationRoleExp

NAC

Abb. 5.61: eine einfache Operation auf Collections wird eingefügt (entweder isEmpty oder notEmpty)

Die Regel InsertSizeExp1 fügt eine Size-Operation auf eine Collection ein, die zurückgibt, wievieleElemente die CollectionRole enthält (also einen Integer). Das Ergebnis wird einer Variablen zugewie-sen, die dann auch vom Typ Integer ist und noch nicht existierte. Nach der Regelanwendung ist die


CollectionRole das Ende des Pfades. Deshalb kann die Regel nur angewendet werden, wenn von der Col-lectionRole nicht weiternavigiert wird. Es kann nur eine Operation auf Collections angewendet werden(NACs). Der Typ der NavigationCallExp, die den Pfad enthält, wird der Typ des Navigationsendes.

L R

InsertSizeExp1(varname:String)

1:CollectionRole

1:CollectionRole

:SimpleCollectionExp name="size"

sco

:VariableDeclaration varName=varname

resultVar

2:Classifier name=Integer


type

type

8:Path

9:NavigationCallExp

10:Constraint

end

12:nce

13:exp variable

8:Path

9:NavigationCallExp

10:Constraint

11:node

12:nce

13:exp

NAC

10:Constraint


variable

NAC

1:CollectionRole

method

:Method

4:Classifier

4:Classifier

5:base 5:base

type

NAC

type

:Classifier

9:NavigationCallExp

1:CollectionRole

navSource

:NavigationRoleExp

NAC

Abb. 5.62: eine einfache Operation auf Collections wird eingefügt ( size)

Die Regel InsertSizeExp1_2 ist analog zur Regel InsertSizeExp1, nur dass auf der linken Seite ei-ne NavigationCallExp mit einem Typ ist. Dieser Typ muss dann auch mit dem Typ des Pfadendesübereinstimmen.

L R

InsertSizeExp1_2(varname:String)

1:CollectionRole

1:CollectionRole

:SimpleCollectionExp name="size"

sco


resultVar



type

type

8:Path

9:NavigationCallExp

10:Constraint

end

12:nce

13:exp variable

8:Path

9:NavigationCallExp

10:Constraint

11:node

12:nce

13:exp

NAC

10:Constraint


variable

NAC

1:CollectionRole

method

:Method

4:Classifier

4:Classifier

5:base 5:base

14:type

14:type

1:CollectionRole

navSource

:NavigationRoleExp

NAC



Die Regel InsertSizeExp2 fügt eine Size-Operation auf eine Collection ein, die zurückgibt, wievieleElemente die CollectionRole enthält (also einen Integer). Das Ergebnis wird einer Variablen zugewie-sen, die dann auch vom Typ Integer ist und noch nicht existierte. Nach der Regelanwendung kannweiternavigiert werden. Es kann nur eine Operation auf Collections angewendet werden (NACs).

L R

InsertSizeOp2(varname:String)

1:CollectionRole 1:CollectionRole

:SimpleCollectionOp name="size"

sco


resultVar

2:Classifier name=Integer 2:Classifier

name=Integer

type

type

NAC

1:CollectionRole

sco

:SimpleCollectionExp

8:Path

9:NavigationCallExp

10:Constraint

12:nce

13:exp variable

8:Path

9:NavigationCallExp

10:Constraint

11:node

12:nce

13:exp

NAC

10:Constraint


variable

11:node


Die folgenden Transformation Units beinhalten das Einfügen einer Navigation zu einer einfachenCollection-Operation (isEmpty oder notEmpty). Es wird eine NavigationCallExp eingefügt, dann aneiner Rolle gestartet und zu einer CollectionRole navigiert, auf welche die Operation angewendet wird.(Die Size-Operation liefert einen Integer und das Ergebnis muss noch in einem anderen Ausdruckverwendet werden, weshalb diese Operation hier kein Navigationsende sein kann)

InsertSimpleCollOpNav

InsertPathNode *; InsertSimpleEmptyOp(on) ;

InsertSimpleCollOpNavigation

InsertNavigationCallExp ; InsertPathStart ; InsertSimpleCollOpNav ;


Die Regel InsertCondition fügt einen Bedingungsteil an eine NavigationCallExp an. Dieser enthält eineVariable und eine Operation, die den Wert der Variablen mit einem arithmetischen Aasdruck vergleicht.Dazu muss die Variable zuvor im Constraint definiert worden sein und es muss eine entsprechendeVergleichsoperation mit Parametern des Typs der Variablen existieren. Dann wird die Condition undder arithmetische Ausdruck, der dann durch weitere Regeln vervollständigt werden muss, eingefügt.Jede NavigationCallExp hat maximal einen Bedingungsteil (NAC).

L R InsertCondition(opname:OpEnum, varname:String)

:Condition name=opname

condition

NAC

:Condition name=opname

condition

2:VariableDeclaration varName=varname

variable :ArithmExp

argument




6:Classifier

correspondingOp

10:type 7:type 7:type

type


1:NavigationCallExp

2:VariableDeclaration varName=varname




6:Classifier

7:type 7:type


10:type

1:NavigationCallExp

1:NavigationCallExp

Abb. 5.65: im Bedingungsteil des Constraints wird eine Variable mit einem arithmetischen Ausdruckverglichen

Die folgenden fünf TransformationUnits definieren das Einfügen einer Operation im Condition-Teileines Ausdrucks. In den ersten beiden ist der Variablen ein Attributwert, in der 3. und 4. der Rückga-bewert einer Operation zugewiesen worden. Vorher können beliebig viele Pfadknoten und Zuweisungenvon Werten an Variablen gemacht werden.

InsertAttributeNavCond

(InsertNewPath() or InsertPathNode or InsertAttributeAssignment2(vn1, an1) or InsertMethod2_2(mn, rv) or InsertSizeExp2(on, vn2) or (InsertState2(sn1) ; InsertSubState(sn2) *; )) ; AsLongAsPossible (InsertMethodArgLiteral(ln) or InsertMethodArgVar(vn3))) *; InsertAttributeAssignment(vn4, an2) or InsertAttributeAssignment_2(vn4, an2) ; InsertCondition(on, vn4) ; InsertArithmExp ;

InsertAttributeNavCondition

InsertNavigationCallExp ; InsertPathStart ; InsertAttributeNavCond ;


InsertMethodNavCond

(InsertNewPath() or InsertPathNode or InsertAttributeAssignment2(vn1, an1) or InsertMethod2_2(mn1, rv) or InsertSizeExp2(on, vn2) or (InsertState2(sn1) ; InsertSubState(sn2) *; )) ; AsLongAsPossible (InsertMethodArgLiteral(ln) or InsertMethodArgVar(vn3))) *; InsertMethod2(mn2, vn4) or InsertMethod2WIthNavType(mn2, vn4) ; AsLongAsPossible (InsertMethodArgLiteral(ln) or InsertMethodArgVar(vn3)); InsertCondition(on, vn4) ; InsertArithmExp ;

InsertMethodNavCondition

InsertPathStart ; InsertMethodNavCond ;

InsertConditionNavigation

InsertAttributeNavCondition xor InsertMethodNavCondition ;

Aussagen über Zustände

Es können Aussagen über den Zustand, in dem sich eine ClassifierRole befindet, gemacht werden.

Die Regel InsertState1 fügt den obersten Zustand der StateMachine, die für diese Basisklasse derClassifierRole definiert wurde, ein. Die Regel ist anwendbar, wenn von der ClassifierRole nicht weiter-navigiert wurde, nun ist die ClassifierRole das Ende des Pfades. Es kann entweder ein Zustand oder einAttribut oder ein Methodenaufruf oder eine gesendete Message zu einer ClassifierRole dargestellt wer-den (NACs). Der Typ der NavigationCallExp, die den Pfad enthält, wird der Typ des Navigationsendes.

Die Regel InsertState1_2 ist analog zur Regel InsertState1, nur dass auf der linken Seite eine Naviga-tionCallExp mit einem Typ ist. Dieser Typ muss dann auch mit dem Typ des Pfadendes übereinstim-men.


2:Classifier

L R InsertState1(stateName:String)

1:ClassifierRole

4:State name=stateName

5:base

6:context

3:StateMachine 7:top

2:Classifier

1:ClassifierRole


5:base

6:context


:VOCLState name=stateName

state

referredState

8:Path 10:node

8:Path

1:ClassifierRole

target

:VOCLMessage

NAC

1:ClassifierRole

state

:VOCLState

NAC

1:ClassifierRole

method

:Method

NAC

1:ClassifierRole

attrOp

:AttributeOp

NAC

1:ClassifierRole

methodOp

:MethodOp

NAC

1:ClassifierRole

attrass


NAC

end

9:NavigationCallExp

11:nce

9:NavigationCallExp

11:nce type

type

:Classifier

NAC

9:NavigationCallExp

1:ClassifierRole

navSource

:NavigationRoleExp

NAC

Abb. 5.66: Einfügen des obersten Zustands

2:Classifier

L R InsertState1_2(stateName:String)

1:ClassifierRole


5:base

6:context


2:Classifier

1:ClassifierRole


5:base

6:context



state

referredState

8:Path 10:node

8:Path

1:ClassifierRole

target

:VOCLMessage

NAC

1:ClassifierRole

state

:VOCLState

NAC

1:ClassifierRole

method

:Method

NAC

1:ClassifierRole

attrOp

:AttributeOp

NAC

1:ClassifierRole

methodOp

:MethodOp

NAC

1:ClassifierRole

attrass


NAC

end

9:NavigationCallExp

11:nce

9:NavigationCallExp

11:nce 12:type

12:type

1:RoleNode

navSource

:NavigationRoleExp

NAC


Die Regel InsertState2 fügt den obersten Zustand der StateMachine, die für diese Basisklasse derClassifierRole definiert wurde, ein. Die Regel ist auch anwendbar, wenn von der ClassifierRole weiter-navigiert wird. Es kann entweder ein Zustand oder ein Attribut oder ein Methodenaufruf oder eine


gesendete Message zu einer ClassifierRole dargestellt werden (NACs).

2:Class

L R InsertState2(stateName:String)

1:ClassifierRole


5:base

6:context


2:Class

1:ClassifierRole


5:base

6:context



state

referredState

8:Path 9:node

8:Path

1:ClassifierRole

target

:VOCLMessage

NAC

1:ClassifierRole

state

:VOCLState

NAC

1:ClassifierRole

method

:Method

NAC

1:ClassifierRole

attrOp

:AttributeOp

NAC

1:ClassifierRole

methodOp

:MethodOp

NAC

1:ClassifierRole

attrass


NAC

9:node


Mit der Regel InsertSubState können Unterzustände zu einem vorhandenem Zustand eingefügt wer-den. Dafür muss der entsprechende Zustand (aus der StateMachine des UML Diagramms) auch einenUnterzustand mit demselben Namen haben und es darf nur ein Unterzustand eines Zustands eingefügtwerden.

L R InsertSubState(stateName:String)

1:ClassifierRole 5:state

6:referredState 4:State name=stateName 3:State

7:subVertex

1:ClassifierRole 5:state

6:referredState

4:State name=stateName 3:State

7:subVertex


2:VOCLState 2:VOCLState

referredState

subState

NAC

2:VOCLState

subState

:VOCLState

Abb. 5.69: Einfügen eines Unterzustands

Die folgende Transformation Unit beinhaltet das Einfügen einer Navigation zu einer ClassifierRole, diesich in einem bestimmten Zustand befindet. Es wird ein Navigationsausdruck eingefügt, der an einerRolle startet und zu einer ClassifierRole navigiert, danach werden die Zustände eingefügt.


InsertStateNav

InsertPathNode *; InsertState1(sn) or InsertState1_2(sn) ; InsertSubState(sn) *;

InsertStateNavigation

InsertPathStart ; InsertStateNav ;

Messages

Die folgenden Regeln fügen eine Message, die zu einer ClassifierRole gesendet wird, ein. Die Messagereferenziert entweder eine Operation oder ein Signal, die bereits in einem UML Diagramm zu der Ba-sisklasse der ClassifierRole definiert worden sind. Es gibt zwei Arten von Operatoren für Messages. DerhasSent-Operator (ˆ) beschreibt, dass die Message gesendet wurde und es kann nicht weiternavigiertwerden. Der Message-Operator (ˆˆ) liefert die Sequenz aller gesendeten Messages, die dann auch einKnoten des Pfades wird. Es kann entweder ein Zustand oder ein Attribut oder ein Methodenaufrufoder eine gesendete Message zu einer ClassifierRole dargestellt werden (NACs).

2:Class

L R InsertOperationMessageHasSent(mname:String, mkind)

1:ClassifierRole


5:base

4:feature

2:Class

1:ClassifierRole

5:base :VOCLMessageExp name=mname kind=mkind

target

referredOperation 3:Operation name=mname

4:feature

1:ClassifierRole

target

:VOCLMessageExp

NAC

1:ClassifierRole

state

:VOCLState

NAC

1:ClassifierRole

method

:Method

NAC

1:ClassifierRole

attrOp

:AttributeOp

NAC

1:ClassifierRole

methodOp

:MethodOp

NAC

1:ClassifierRole

attrass


NAC

mkind="hasSent"

6:Path 8:node

7:NavigationCallExp

9:nce

6:Path end

7:NavigationCallExp

9:nce type

:Classifier

type

NAC

7:NavigationCallExp 1:ClassifierRole

navSource

:NavigationRoleExp

NAC

Abb. 5.70: Einfügen des ˆ-Operators zu einer Operation

Die Regel InsertOperationMessageHasSent2 macht genau dasselbe, hier hat die NavigationCallExpbereits einen Typ, der mit dem des Navigationsendes übereinstimmen muss.


2:Class

L R InsertOperationMessageHasSent2(mname:String, mkind)

1:ClassifierRole


5:base

4:feature

2:Class

1:ClassifierRole


target

referredOperation 3:Operation name=mname

4:feature

1:ClassifierRole

target

:VOCLMessageExp

NAC

1:ClassifierRole

state

:VOCLState

NAC

1:ClassifierRole

method

:Method

NAC

1:ClassifierRole

attrOp

:AttributeOp

NAC

1:ClassifierRole

methodOp

:MethodOp

NAC

1:ClassifierRole

attrass


NAC

mkind="hasSent"

6:Path 8:node

7:NavigationCallExp

9:nce

6:Path end

7:NavigationCallExp

9:nce 10:type 10:type

1:ClassifierRole

navSource

:NavigationRoleExp

NAC

Abb. 5.71: Einfügen des ˆ-Operators zu einer Operation

2:Class

L R InsertSignalMessageHasSent(mname:String, mkind)

1:ClassifierRole

5:base

4:feature

2:Class

1:ClassifierRole


target

4:feature

1:ClassifierRole

target

:VOCLMessageExp

NAC

1:ClassifierRole

state

:VOCLState

NAC

1:ClassifierRole

method

:Method

NAC

1:ClassifierRole

attrOp

:AttributeOp

NAC

1:ClassifierRole

methodOp

:MethodOp

NAC

1:ClassifierRole

attrass


NAC

mkind="hasSent"

6:Path 8:node

7:NavigationCallExp

9:nce

6:Path end

7:NavigationCallExp

9:nce type

6:Signal name=mname

3:Operation

6:context 6:Signal name=mname

3:Operation 6:context referredSignal

:Classifier

7:NavigationCallExp

NAC

type

1:ClassifierRole

navSource

:NavigationRoleExp

NAC

Abb. 5.72: Einfügen einer Message

Die Regel InsertSignalMessageHasSent2 macht genau dasselbe, hier hat die NavigationCallExp bereits


einen Typ, der mit dem des Navigationsendes übereinstimmen muss.

2:Class

L R InsertSignalMessageHasSent2(mname:String, mkind)

1:ClassifierRole

5:base

4:feature

2:Class

1:ClassifierRole


target

4:feature

1:ClassifierRole

target

:VOCLMessageExp

NAC

1:ClassifierRole

state

:VOCLState

NAC

1:ClassifierRole

method

:Method

NAC

1:ClassifierRole

attrOp

:AttributeOp

NAC

1:ClassifierRole

methodOp

:MethodOp

NAC

1:ClassifierRole

attrass


NAC

mkind="hasSent"

6:Path 8:node

7:NavigationCallExp

9:nce

6:Path end

7:NavigationCallExp

9:nce 10:type 10:type

6:Signal name=mname

3:Operation

6:context 6:Signal name=mname

3:Operation 6:context referredSignal

1:ClassifierRole

navSource

:NavigationRoleExp

NAC



2:Class

L R InsertOperationMessageOp(mname:String, mkind)

1:RoleNode

5:base

4:feature

2:Class

1:RoleNode

5:base

:VOCLMessageExp name=mname kind=mkind

target

4:feature

1:RoleNode

target

:VOCLMessageExp

NAC

1:RoleNode

state

:VOCLState

NAC

1:RoleNode

method

:Method

NAC

1:RoleNode

attrOp

:AttributeOp

NAC

1:RoleNode

methodOp

:MethodOp

NAC

1:RoleNode

attrass


NAC

mkind="messageOperator"

6:Path 8:node

7:NavigationCallExp

9:nce

6:Path

7:NavigationCallExp

9:nce


referredOperation

8:node

:SequenceRole :Classifier name="OCLMessage"

base node resultingMessageNode


1:RoleNode

navSource

:NavigationRoleExp

NAC

Abb. 5.74: Einfügen des ˆˆ-Operators zu einer Operation

2:Class

L R InsertSignalMessageOp(mname:String, mkind)

1:RoleNode

5:base

4:feature

2:Class

1:RoleNode

5:base

:VOCLMessageExp name=mname kind=mkind

target

4:feature

1:RoleNode

target

:VOCLMessageExp

NAC

1:RoleNode

state

:VOCLState

NAC

1:RoleNode

method

:Method

NAC

1:RoleNode

attrOp

:AttributeOp

NAC

1:RoleNode

methodOp

:MethodOp

NAC

1:RoleNode

attrass


NAC

mkind="messageOperator"

6:Path 8:node

7:NavigationCallExp

9:nce

6:Path

7:NavigationCallExp

9:nce 6:Signal name=mname

3:Operation

6:context

6:Signal name=mname

3:Operation 6:context

referredSignal

8:node

:SequenceRole :Classifier name="OCLMessage"

base node resultingMessageNode

1:RoleNode

navSource

:NavigationRoleExp

NAC



Die folgenden Regeln fügen zu einer Message Argumente ein. Es können entweder Konstanten oderbereits definierte Variablen oder unspezifizierte Werte, von denen nur der Typ angegeben wird, sein.Die/das referenzierte Operation/Signal muss einen entsprechenden Parameter des Typs des Argumentshaben und zu jedem Parameter gibt es nur ein Argument.

L R InsertMessageExpArgLiteral(aname:String)

1:VOCLMessageExp name=mname

5:referredOperation

2:Operation

3:Parameter

4:Classifier

6:type

7:parameter


5:referredOperation

2:Operation

3:Parameter

4:Classifier

6:type

7:parameter

:LiteralExp name=aname

type

argument

NAC


5:referredOperation

2:Operation

3:Parameter

4:Classifier

6:type

7:parameter

type

argument :Argument

Abb. 5.76: Einfügen von Argumenten einer Message

L R InsertMessageExpArgVariable(aname:String)


5:referredOperation

2:Operation

3:Parameter

4:Classifier

6:type

7:parameter

9:VariableDeclaration name=aname

8:type

argument 1:VOCLMessageExp name=mname

5:referredOperation

2:Operation

3:Parameter

4:Classifier

6:type

7:parameter


8:type

NAC


5:referredOperation

2:Operation

3:Parameter

4:Classifier

6:type

7:parameter

type

argument :Argument



L R InsertMessageExpArgUnspecified()


5:referredOperation

2:Operation

3:Parameter

4:Classifier

6:type

7:parameter

type


5:referredOperation

2:Operation

3:Parameter

4:Classifier

6:type

7:parameter

:Unspecified

NAC


5:referredOperation

2:Operation

3:Parameter

4:Classifier

6:type

7:parameter

type

argument :Argument


L R InsertMessageExpArgLiteral2(aname:String)


5:referredSignal

2:Signal

3:Attribute

4:Classifier

6:type

7:feature

type


5:referredSignal

2:Signal

3:Attribute

4:Classifier

6:type

7:feature

:LiteralExp name=aname

NAC


5:referredOperation

2:Operation

3:Parameter

4:Classifier

6:type

7:parameter

type

argument :Argument



L R InsertMessageExpArgVariable2(aname:String)


5:referredSignal

2:Signal

3:Attribute

4:Classifier

6:type

7:feature


5:referredSignal

2:Signal

3:Attribute

4:Classifier

6:type

7:feature


8:type


8:type

argument

NAC


5:referredOperation

2:Operation

3:Parameter

4:Classifier

6:type

7:parameter

type

argument :Argument


L R InsertMessageExpArgUnspecified2()


5:referredSignal

2:Signal

3:Attribute

4:Classifier

6:type

7:feature

type


5:referredSignal

2:Signal

3:Attribute

4:Classifier

6:type

7:feature

:Unspecified

NAC


5:referredOperation

2:Operation

3:Parameter

4:Classifier

6:type

7:parameter

type

argument :Argument



Die folgende Transformation Unit definiert das Einfügen einer Navigation zu einer Rolle, auf die derˆ-Operator angewendet wird. Es wird eine NavigationCallExp eingefügt und dann von einer Startrolleentlang eines Pfades navigiert. Dieser Pfad kann Zuweisungen von Werten an Variablen oder Aus-sagen über Zustände (durch die Regeln InsertAttributeAssignment2(vn, an) or InsertMethod2_2(mn,rv) or InsertSimpleCollOp2_2(on, vn) or (InsertState2(sn1); InsertSubState(sn2)*;)) enthalten. DieseVariablen können Argumente der am Schluss eingefügten MessageExp sein.

InsertMessageNav

(InsertNewPath() or InsertPathNode or InsertAttributeAssignment2(vn, an) or InsertMethod2_2(mn, rv) or InsertSizeExp2(on, vn) or (InsertState2(sn1) ; InsertSubState(sn2) *; )) ; AsLongAsPossible (InsertMethodArgLiteral(ln) or InsertMethodArgVar(vn))) *; (InsertOperationMessageHasSent(mk, mn) or InsertOperationMessageHasSent2(mk, mn) InsertSignalMessageHasSent(mk, mn) or InsertSignalMessageHasSent2(mk, mn ) ) ; AsLongAsPossible (InsertMessageArgLiteral(ln) or InsertMethodArgVar(vn) or InsertMessageArgUnspecified() or InsertMessageArgLiteral2(ln) or InsertMethodArgVar2(vn) or InsertMessageArgUnspecified2() ) ;

InsertMessageNavigation

InsertNavigationCallExp ; InsertPathStart ; InsertMessageNav ;


5.3.3 VOCLExpressions

If-Then-Else

Die Regel InsertIfExp fügt einen booleschen Ausdrucks in einen Constraint ein. Die NAC definiert,dass der Constraint noch keinen VOCL Ausdruck enthält.

L R

InsertIfExp()

exp body

NAC

1:Constraint

VOCLExp bodY

:IfExp

1:Constraint kind=k

k<>definition

1:Constraint kind=k

Abb. 5.82: Einfügen eines If-Then-Else Ausdrucks

Die Regel InsertIfExpIfNavigationCallExp fügt als If-Teil eines If-Then-Else-Ausdrucks einen Naviga-tionsausdruck ein. Die NAC definiert, dass es noch keinen If-Teil gibt.

L R

InsertIfExpIfNavigationCallExp()

1:IfExp

2:Constraint

3:exp

1:IfExp

2:Constraint

3:exp

:NavigationCallExp

exp

if 1:IfExp

:VOCLExp

if

NAC

4:Classifier name=#Boolean


type

Abb. 5.83: Der if-Teil ist ein Navigationsausdruck

Die Regel InsertIfExpIfBooleanExp fügt als If-Teil eines If-Then-Else-Ausdrucks einen booleschen Aus-druck ein. Die NAC definiert, dass es noch keinen If-Teil gibt.

L R

InsertIfExpIfBooleanExp(opName:BOpEnum)

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

if

NAC

1:IfExp

2:Constraint 3:Classifier name=#Boolean


4:exp

exp

if

type

:BooleanExp name=opName

Abb. 5.84: Der if-Teil ist eine BooleanExp


Die Regel InsertIfExpIfIfExp fügt als If-Teil eines If-Then-Else-Ausdrucks einen If-Then-Else-Ausdruckein. Die NAC definiert, dass es noch keinen If-Teil gibt.

L R

InsertIfExpIfIfExp()

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

if

NAC

1:IfExp

2:Constraint


:IfExp


4:exp exp

if

type

Abb. 5.85: Der if-Teil ist eine IfExp

Die Regel InsertIfExpIfLetExp fügt als If-Teil eines If-Then-Else-Ausdrucks einen Let Ausdruck ein.Die NAC definiert, dass es noch keinen If-Teil gibt.

L R

InsertIfExpIfLetExp(vName:String)

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

if

NAC

1:IfExp

2:Constraint


:LetExp


4:exp exp

if

type

5:Classifier

5:Classifier :VariableDeclaration varName=vName

variable type 2:Constraint

NAC


variable

variable

Abb. 5.86: Der if-Teil ist eine LetExp

Die Regel InsertIfExpThenNavigationCallExp fügt als Then-Teil eines If-Then-Else-Ausdrucks einenNavigationsausdruck ein. Die NACs definieren, dass es noch keinen Then-Teil gibt und dass der Typder IfExp erst jetzt festgelegt wird, sie also noch keinen hat.Die Regel InsertIfExpThenNavigationCallExp2 fügt als Then-Teil eines If-Then-Else-Ausdrucks einenNavigationsausdruck ein, wobei hier der Typ der IfExp bereits festgelegt ist (es gibt ihn schon auf derlinken Regelseite). Der Typ einer IfExp kann z.B. wenn sie ein Argument einer BooleanExp ist, schonvor dem Einfügen des Then-Teils festgelegt sein.


L R

InsertIfExpThenNavigationCallExp2()

1:IfExp

2:Constraint

3:exp

1:IfExp

2:Constraint

3:exp

:NavigationCallExp

exp

then 1:IfExp

:VOCLExp

then

NAC

type


5:type 5:type

Abb. 5.87: Der Then-Teil ist ein Navigationsausdruck

L R

InsertIfExpThenNavigationCallExp2()

1:IfExp

2:Constraint

3:exp

1:IfExp

2:Constraint

3:exp

:NavigationCallExp

exp

then 1:IfExp

:VOCLExp

then

NAC

type


5:type 5:type

Abb. 5.88: Der Then-Teil ist ein Navigationsausdruck

Die Regel InsertIfExpThenBooleanExp fügt als Then-Teil eines If-Then-Else-Ausdrucks einen boole-schen Ausdruck ein. Die NACs definieren, dass es noch keinen Then-Teil gibt und dass der Typ derIfExp erst jetzt festgelegt wird, sie also noch keinen hat.Die Regel InsertIfExpThenBooleanExp2 fügt als Then-Teil eines If-Then-Else-Ausdrucks einen boole-schen Ausdruck ein, wobei hier der Typ der IfExp bereits festgelegt ist (er muss ein Boolean sein).

L R

InsertIfExpThenBooleanExp(opName:BOpEnum)

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

then

NAC

1:IfExp



4:exp exp

then

type


type 1:IfExp

type

NAC

:Classifier

Abb. 5.89: Der Then-Teil ist eine BooleanExp


L R

InsertIfExpThenBooleanExp2(opName:BOpEnum)

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

then

NAC

1:IfExp



4:exp exp

then

type


4:type

4:type

Abb. 5.90: Der Then-Teil ist eine BooleanExp

Die Regel InsertIfExpThenIfExp fügt als Then-Teil eines If-Then-Else-Ausdrucks einen If-Then-Else-Ausdruck ein. Die NACs definieren, dass es noch keinen Then-Teil gibt und dass der Typ der IfExperst jetzt festgelegt wird, sie also noch keinen hat.Die Regel InsertIfExpThenIfExp2 fügt als Then-Teil eines If-Then-Else-Ausdrucks einen If-Then-Else-Ausdruck ein, wobei hier der Typ der IfExp bereits festgelegt ist.

L R

InsertIfExpThenIfExpInsideABodyLoop()

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

then

NAC

1:IfExp

2:Constraint

:IfExp 4:exp

exp

then

1:IfExp

type

NAC

:Classifier


type type

5:BodyLoopExp

6:loopExp loopExp

5:BodyLoopExp

6:loopExp

Abb. 5.91: Der Then-Teil ist eine IfExp

L R

InsertIfExpThenIfExp2()

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

then

NAC

1:IfExp

2:Constraint

:IfExp 4:exp

exp

then


type 5:type

5:type

Abb. 5.92: Der Then-Teil ist eine IfExp


Die Regel InsertIfExpThenLetExp fügt als Then-Teil eines If-Then-Else-Ausdrucks einen Let-Ausdruckein. Die NACs definieren, dass es noch keinen Then-Teil gibt und dass der Typ der IfExp erst jetztfestgelegt wird, sie also noch keinen hat.Die Regel InsertIfExpThenLetExp2 fügt als Then-Teil eines If-Then-Else-Ausdrucks einen Let-Ausdruckein, wobei hier der Typ der IfExp bereits festgelegt ist.

L R

InsertIfExpThenLetExp(vName:String)

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

then

NAC

1:IfExp

2:Constraint

:LetExp 4:exp

exp

then

type

:VariableDeclaration varName=vName

variable type

2:Constraint

NAC


variable

variable


type

1:IfExp

type

NAC

:Classifier

Abb. 5.93: Der Then-Teil ist eine LetExp

L R

InsertIfExpThenLetExp2(vName:String)

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

then

NAC

1:IfExp

2:Constraint

:LetExp 4:exp

exp

then

type


variable type

2:Constraint

NAC


variable

variable


5:type

5:type

Abb. 5.94: Der Then-Teil ist eine LetExp

Die Regel InsertIfExpElseNavigationCallExp fügt als Else-Teil eines If-Then-Else-Ausdrucks einen Na-vigationsausdruck ein. Die NAC definiert, dass es noch keinen Else-Teil gibt.

Die Regel InsertIfExpElseBooleanExp fügt als Else-Teil eines If-Then-Else-Ausdrucks einen booleschenAusdruck ein. Die NAC definiert, dass es noch keinen Else-Teil gibt.


L R

InsertIfExpElseNavigationCallExp()

1:IfExp

2:Constraint

3:exp

5:VOCLExp

7:exp

6:then 1:IfExp

:VOCLExp

else

NAC

8:type

4:Classifier

1:IfExp

2:Constraint

3:exp

5:VOCLExp

7:exp

6:then

8:type

4:Classifier

:NavigationCallExp

exp else

type

Abb. 5.95: Der Else-Teil ist ein Navigationsausdruck

L R

InsertIfExpElseBooleanExp(opName:BOpEnum)

1:IfExp

:VOCLExp

else

NAC

1:IfExp


4:exp 7:exp

6:then

8:type 7:exp

6:then

8:type

exp else type

1:IfExp


4:exp

5:VOCLExp 5:VOCLExp


Abb. 5.96: Der Else-Teil ist eine BooleanExp

Die Regel InsertIfExpElseIfExp fügt als Else-Teil eines If-Then-Else-Ausdrucks einen If-Then-Else-Ausdruck ein. Die NAC definiert, dass es noch keinen Else-Teil gibt.

L R

InsertIfExpElseIfExp()

1:IfExp

2:Constraint

3:exp

5:VOCLExp

7:exp

6:then 1:IfExp

:VOCLExp

else

NAC

8:type

4:Classifier

1:IfExp

2:Constraint

3:exp

5:VOCLExp

7:exp

6:then

8:type

4:Classifier

:IfExp

exp else

type

Abb. 5.97: Der Else-Teil ist eine IfExp

Die Regel InsertIfExpElseLetExp fügt als Else-Teil eines If-Then-Else-Ausdrucks einen Let-Ausdruckein. Die NAC definiert, dass es noch keinen Else-Teil gibt.


InsertIfExpElseLetExp(vName:String)

2:Constraint

NAC


variable

L R

1:IfExp

2:Constraint

3:exp

5:VOCLExp

7:exp

6:then 1:IfExp

:VOCLExp

else

NAC

8:type

4:Classifier

1:IfExp

2:Constraint

3:exp

5:VOCLExp

7:exp

6:then

8:type

4:Classifier

exp

else

type

9:Classifier

:LetExp


type

variable

9:Classifier

variable

Abb. 5.98: Der Else-Teil ist eine LetExp

Die folgenden Transformation Units fügen eine VOCLExp in eine IfExp ein.

Die Transformation Unit InsertPath fügt einen Navigationsausdruck ein. Dieser beginnt an einer Star-trolle, die mit der TransformationUnit InsertPathStart eingefügt wird und deren Name und Typ vomTyp des Constraints und der Definition einer Constraintvariablen abhängen.Nachdem eine Startrolle und eine Startnavigation eingefügt wurden, können alle Alternativen zumEinfügen eines korrekten Pfades eingefügt werden. Eine der TransformationUnits InsertEquivalentPa-thesNav, InsertAttributeNav, InsertMethodNav, InsertSimpleCollOpNav, InsertConditionNav, Insert-StateNav oder InsertMessageNav kann angewendet werden. Danach wurde ein korrekter Navigations-ausdruck eingefügt.

Die Transformation Unit InsertIfExpIfNavigation fügt als If-Teil eines If-Then-Else Ausdrucks einenNavigationsausdruck ein (mit der Regel InsertIfExpIfNavigationCallExp). Danach wird der Navigati-onsausdruck mit der Transformation Unit InsertPath zu einem korrekten Ausdruck vervollständigt.Die Transformation Units InsertIfExpThenNavigation und InsertIfExpElseNavigation sind ähnlich de-finiert.

Die Transformation Unit InsertBooleanExp fügt die Argumente eines booleschen Ausdrucks (mit denTransformation Units InsertBooleanExpArg(1) und InsertBooleanExpArg(2)) ein.

Die Transformation Unit InsertIfExpIfBooleanExpression fügt als If-Teil eines If-Then-Else Ausdruckseinen booleschen Ausdruck (mit der Regel InsertIfExpIfBooleanExp und der Transformation Unit In-sertBooleanExp). Die Transformation Units InsertIfExpThenBooleanExpression und InsertIfExpElse-BooleanExpression sind ähnlich definiert.

Die Transformation Unit InsertIfExp fügt die drei Teile eines If-Then-Else Ausdrucks (mit den Trans-formation Units InsertIfExpIf, InsertIfExpThen, InsertIfExpElse) ein.

Die Transformation Unit InsertIfExpIThenIfExpression fügt als Then-Teil eines If-Then-Else Ausdruckseinen If-Then-Else Ausdruck (mit einer der Regeln InsertIfExpThenIfExp, InsertIfExpThenIfExp2 undder Transformation Unit InsertIfExp) ein. Die Transformation Unit InsertIfExpElseIfExpression istanalog definiert.

Die Transformation Unit InsertLetExp fügt die zwei Teile eines Let-Ausdrucks (mit den TransformationUnits InsertLetExpInitVariable, InsertLetExpIn) ein.

Die Transformation Unit InsertIfExpIfLetExpression fügt als If-Teil eines If-Then-Else Ausdrucks einen


Let-Ausdruck (mit der Regel InsertIfExpIfLetExp und der Transformation Unit InsertLetExp) ein. DieTransformation Units InsertIfExpThenLetExpression und InsertIfExpElseLetExpression sind ähnlichdefiniert.

Die Transformation Unit InsertIfExpIf fügt den If-Teil eines If-Then-Else Ausdrucks ein. Dieser kanneiner der vier zuvor beschriebenen Fälle sein. Die Transformation Units InsertIfExpThen und InsertI-fExpElse sind analog definiert.

InsertIfExpIfNavigation

InsertIfExpIfNavigationCallExp() ; InsertPath ;

InsertIfExpElseNavigation

(InsertIfExpElseNavigationCallExp() or InsertIfExpElseNavigationCallExp2()) ; InsertPath or (InsertPathStart ; InsertPathNode *; ) ;

InsertIfExpThenNavigation

InsertIfExpThenNavigationCallExp() ; InsertPath or (InsertPathStart ; InsertPathNode *; ) ;

InsertIfExpIfBooleanExpression

InsertIfExpIfBooleanExp() ; InsertBooleanExp ;

InsertIfExpThenBooleanExpression

InsertIfExpThenBooleanExp() or InsertIfExpThenBooleanExp2(); InsertBooleanExp ;

InsertIfExpElseBooleanExpression

InsertIfExpElseBooleanExp() ; InsertBooleanExp ;

InsertIfExpThenIfExpression

(InsertIfExpThenIfExp() or InsertIfExpThenIfExp2()) ; InsertIfExp ;

InsertIfExpElseIfExpression

InsertIfExpElseIfExp() ; InsertIfExp ;

InsertIfExpIfLetExpression

InsertIfExpIfLetExp() ; InsertLetExp ;

InsertIfExpThenLetExpression

(InsertIfExpThenLetExp() or InsertIfExpThenLetExp2()) ; InsertLetExp ;

InsertIfExpElseLetExpression

InsertIfExpElseLetExp() ; InsertLetExp ;

InsertIfExpIf

InsertIfExpIfBooleanExpression or InsertIfExpIfLetExpression or InsertIfExpIfNavigation ;

InsertIfExpThen

InsertIfExpThenBooleanExpression or InsertIfExpThenIfExpression or InsertIfExpThenLetExpression or InsertIfExpThenNavigation ;

InsertIfExpElse

InsertIfExpElseBooleanExpression or InsertIfExpElseIfExpression or InsertIfExpElseLetExpression or InsertIfExpElseNavigation ;

InsertIfExpression

InsertIfExp(); InsertIfExp;

InsertIfExp

InsertIfExpIf ; InsertIfExpThen; InsertIfExpElse;

InsertPath

InsertPathStart ; (InsertEquivalentNav xor InsertAttributeNav xor InsertMethodNav xor InsertSimpleCollOpNav xor InsertConditionNav xor InsertMessageNav xor InsertStateNav) ;

InsertBooleanExp

InsertBooleanExpArg(1) ; InsertBooleanExpArg(2);

InsertLetExp

InsertLetExpInitVariable ; InsertLetExpIn ;


Boolesche Operationen

Die folgenden Regeln fügen eine boolesche Operation (implies, and, or, xor, not) ein. Diese hat zweiArgumente, die VOCLExps sind, d.h. für jede konkrete VOCLExp gibt es eine Regel.

Die Regel InsertBooleanExp fügt einen booleschen Ausdruck in einen Constraint ein. Die NAC definiert,dass der Constraint noch keinen VOCL Ausdruck enthält.

L R

InsertBooleanExp(opName:BOpEnum)

exp



type


body

NAC

1:Constraint

VOCLExp body

k<>definition

1:Constraint kind=k

1:Constraint kind=k

Abb. 5.99: Einfügen einer booleschen Operation

Die Regel InsertBooleanExpArgNavigationCallExp(ord) fügt als Argument (der übergebenen Ordnung)eines booleschen Ausdrucks einen Navigationsausdruck ein. Die NAC definiert, dass es nur ein solchesArgument gibt.

L R

InsertBooleanExpArgNavigationCallExp(ord:Integer)

1:BooleanExp name=n

2:Constraint

3:exp

2:Constraint

:NavigationCallExp

exp

arg order=ord

:VOCLExp

NAC

3:exp arg

order=ord

ord <=2

1:BooleanExp name=n

1:BooleanExp name=n

NAC

1:BooleanExp name=n

ord = 2 n = #not


type


Abb. 5.100: Das Argument ist ein Navigationsausdruck

Die Regel InsertBooleanExpArgBooleanExp(ord) fügt als Argument (der übergebenene Ordnung) ei-nes booleschen Ausdrucks einen booleschen Ausdruck ein. Die NAC definiert, dass es nur ein solchesArgument gibt.


L R

InsertBooleanExpArgBooleanExp(ord:Integer, opName:BOpEnum)

NAC

1:BooleanExp name=n

2:Constraint

3:exp

2:Constraint

exp

arg order=ord

:VOCLExp

3:exp arg

order=ord

ord <=2

1:BooleanExp name=n

1:BooleanExp name=n

1:BooleanExp name=n

ord = 2 n = #not

NAC



type


Abb. 5.101: Das Argument ist eine BooleanExp

Die Regel InsertBooleanExpArgIfExp(ord) fügt als Argument (der übergebenene Ordnung) eines boole-schen Ausdrucks einen If-Then-Else-Ausdruck ein. Die NAC definiert, dass es nur ein solches Argumentgibt.

L R

InsertBooleanExpArgIfExp()

NAC NAC

1:BooleanExp name=n

2:Constraint

3:exp

2:Constraint

:IfExp

exp

arg order=ord

:VOCLExp

3:exp arg

order=ord

ord <=2

1:BooleanExp name=n

1:BooleanExp name=n

1:BooleanExp name=n

ord = 2 n = #not



type

Abb. 5.102: Das Argument ist eine IfExp

Die Regel InsertBooleanExpArgLetExp(ord) fügt als Argument (der übergebenene Ordnung) eines boo-leschen Ausdrucks einen Let-Ausdruck ein. Die NAC definiert, dass es nur ein solches Argument gibt.

L R

InsertBooleanExpArg1LetExp(vName:String)

2:Constraint

4:exp

:VOCLExp

NAC

2:Constraint


:LetExp


4:exp exp

type

5:Classifier


variable

type

variable

2:Constraint

NAC


variable

ord <=2

NAC

1:BooleanExp name=n

ord = 2 n = #not

1:BooleanExp name=n 1:BooleanExp

name=n

1:BooleanExp name=n

arg order=ord

arg order=ord

Abb. 5.103: Das Argument ist eine LetExp


Die Transformation Unit InsertBooleanExpArgNavigationCallExpression(ord) fügt als Argument einesbooleschen Ausdrucks einen Navigationsausdruck (mit der Regel InsertBooleanExpArgNavigationCall-Exp(ord)) und den Ausdrucks (mit der Transformation Unit InsertPath.

Die Transformation Unit InsertBooleanExpArgBooleanExpression(ord) fügt als Argument eines boole-schen Ausdrucks einen booleschen Ausdruck (mit der Regel InsertBooleanExpArgIfExp(ord)) und diebeiden Argumente dieses Ausdrucks (mit der Transformation Unit InsertBooleanExp.

Die Transformation Unit InsertBooleanExpArgIfExpression(ord) fügt als Argument eines booleschenAusdrucks einen If-Then-Else Ausdruck (mit der Regel InsertBooleanExpArgIfExp(ord)) und die dreiTeile dieses Ausdrucks (mit der Transformation Unit InsertIfExp ein.

Die Transformation Unit InsertBooleanExpArg1LetExpression(ord) fügt als Argument eines booleschenAusdrucks einen Let-Ausdruck (mit der Regel InsertBooleanExpArgLetExp(ord)) und die beiden Teiledieses Ausdrucks, die Initialisierung der Letvariablen und den in-Teil (mit de Transformation UnitInsertLetExp).

Die Transformation Unit InsertBooleanExpArg(ord) fügt ein Argument des booleschen Ausdrucks ein.Dies kann einer der vier zuvor beschriebenen Fälle sein.

Die Transformation Unit InsertBooleanExpression fügt einen booleschen Ausdruck mit seinen ARgu-menten ein.

InsertBooleanExpArgNavigation(ord)

InsertBooleanExpArgNavigationCallExp(ord) ; InsertPath ;

InsertIfBooleanExpArgBooleanExpression(ord)

InsertBooleanExpArgBooleanExp(ord) ; InsertBooleanExp ;

InsertBooleanExpArgIfExpression(ord)

InsertBooleanExpArgIfExp(ord) ; InsertIfExp ;

InsertBooleanExpArgLetExpression(ord)

InsertBooleanExpArgLetExp(ord) ; InsertLetExp ;

InsertBooleanExpArg(ord)

InsertBooleanExpArgBooleanExpression(ord) or InsertBooleanExpArgIfExpression(ord) or InsertBooleanExpArgLetExpression(ord) or InsertBooleanExpArgNavigation(ord) ;

InsertBooleanExpression

InsertBooleanExp() ; InsertBooleanExp ;


Let Ausdrücke

Die Regel InsertLetExp fügt einen Let-Ausdruck in einen Constraint ein. Die NAC definiert, dass derConstraint noch keinen VOCL Ausdruck enthält.

L R

InsertLetExp(name:String)

exp body

NAC

1:Constraint

VOCLExp body

:LetExp 2:Classifier 2:Classifier

:VariableDeclaration varName=name

type

letVar

variable

NAC

1:Constraint


variable

1:Constraint kind=k

1:Constraint kind=k

Abb. 5.104: Einfügen eines Let Ausdrucks

Die Regel InsertLetExpInitVarBooleanExp fügt als initialen Wert der Letvariablen einen booleschenAusdruck ein. Die NAC definiert, dass es noch keine Initialisierung gibt.

L R

InsertLetExpInitVarBooleanExp(opname: BOpEnum)

1:LetExp

2:Constraint

5:exp

4:VariableDeclaration

:VOCLExp

initExpression

NAC


7:type

8:letVar 3:Classifier name=#Boolean

1:LetExp

2:Constraint

5:exp


7:type


type

exp

initExpression

:BooleanExp name=opname

Abb. 5.105: Die Let-Variable wird mit einer BooleanExp initialisiert

Die Regel InsertLetExpInitVarIfExp fügt als initialen Wert der Letvariablen einen If-Then-Else-Ausdruckein. Die NAC definiert, dass es noch keine Initialisierung gibt.

L R

InsertLetExpInitVarIfExp()

1:LetExp

2:Constraint

5:exp


:VOCLExp

initExpression

NAC


7:type

8:letVar 3:Classifier

1:LetExp

2:Constraint

5:exp


7:type


type

exp

initExpression

3:IfExp

Abb. 5.106: Die Let-Variable wird mit einer IfExp initialisiert


Die Regel InsertLetExpInitVarLetExp fügt als initialen Wert der Letvariablen einen Let-Ausdruck ein.Die NAC definiert, dass es noch keine Initialisierung gibt.

L R

InsertLetExpInitVarLetExp(vname:String)

1:LetExp

2:Constraint

5:exp


:VOCLExp

initExpression

NAC


7:type

8:letVar 1:LetExp

2:Constraint

5:exp


7:type

8:letVar

exp

initExpression

:LetExp


letVar type

variable

2:Constraint

NAC


variable


3:Classifier

9:Classifier

type

Abb. 5.107: Die Let-Variable wird mit einer LetExp initialisiert

Die Regel InsertLetExpInitVarNavigationCallExp fügt als initialen Wert der Letvariablen einen Navi-gationsausdruck ein. Die NAC definiert, dass es noch keine Initialisierung gibt.

L

InsertLetExpVarInitNavigationCallExp()

:VOCLExp

initExpression

NAC

1:LetExp

2:Constraint

5:exp


7:type

8:letVar

initExpression

3:Classifier

1:LetExp

2:Constraint

5:exp


7:type


:NavigationCallExp

R

initExpression

exp


NAC

2:Constraint


constrainedVar

type

Abb. 5.108: Die Let-Variable wird mit einem Navigationsausdruck initialisiert

Die Regel InsertClassifierRoleName fügt zu einer ClassifierRole einen Namen ein. Dieser ist der Nameeiner Letvariablen. Die Letvariable wird durch diese Regel mit einer ClassifierRole initialisiert, d.h.diese ClassifierRole ist das Pfadende des Navigationsausdrucks, der die initExpression der Letvariablendarstellt. Deshalb darf von dieser ClassifierRole keine weitere Navigation ausgehen (NAC).


L R

InsertClassifierRoleName(name:String)

variable

11:VariableDeclaration varName=name

3:base

1:ClassifierRole


4:Constraint

5:NavigationCallExp

6:Path

end

8:nce

9:exp 14:variable 12:exp

10:LetExp

13:letVar


3:base

1:ClassifierRole


4:Constraint

5:NavigationCallExp

6:Path

5:node

8:nce

9:exp

14:variable

12:exp

10:LetExp

13:letVar

16:initExpression 16:initExpression

1:ClassifierRole

navSource

:NavigationRoleExp

NAC


Die Regel InsertCollectionRoleName fügt zu einer CollectionRole einen Namen ein. Dieser ist der Nameeiner Letvariablen. Die Letvariable wird durch diese Regel mit einer CollectionRole initialisiert, d.h.diese CollectionRole ist das Pfadende des Navigationsausdrucks, der die initExpression der Letvariablendarstellt. Deshalb darf von dieser CollectionRole keine weitere Navigation ausgehen (NAC).

L R

InsertCollectionRoleName(name:String)


4:Constraint

variable

NAC

variable


3:base

1:CollectionRole


4:Constraint

5:NavigationCallExp

6:Path

end

8:nce

9:exp

14:variable

12:exp

10:LetExp

13:letVar


3:base

1:CollectionRole


4:Constraint

5:NavigationCallExp

6:Path

5:node

8:nce

9:exp

14:variable

12:exp

10:LetExp

13:letVar

16:initExpression 16:initExpression

16:type 16:type

1:CollectionRole

navSource

:NavigationRoleExp

NAC



Die RegelnInsertLetExpInNavigationCallExp(), InsertLetExpInNavigationCallExp2(), InsertLetExpInBooleanExp(),InsertLetExpInBooleanExp2(), InsertLetExpInIfExp(), InsertLetExpInIfExp2(), InsertLetExpInLetExp()und InsertLetExpInLetExp2() sind analog zu den Regeln InsertIfExpIfNavigationCallExp(), InsertI-fExpIfNavigationCallExp2(), InsertIfExpIfBooleanExp(), InsertIfExpIfBooleanExp2(), InsertIfExpIfIf-Exp(), InsertIfExpIfIfExp2(), InsertIfExpIfLetExp() und InsertIfExpIfLetExp2() (die IfExp (1) wirddurch eine LetExp ersetzt und die Kante if durch eine Kante in) und werden deshalb nicht genauerbeschrieben. Allerdings haben diese Regeln eine zusätzliche NAC, die ausdrückt, dass in einen Cons-traint der Art definition kein in-Teil eingefügt werden darf.

L R

InsertLetExpInNavigationCallExp()

1:LetExp

2:Constraint kind=k

3:exp

1:LetExp

3:exp

:NavigationCallExp

exp

in 1:IExp

:VOCLExp

in

NAC

2:Constraint kind=k

k<>definition 1LetExp

:Classifier

type

NAC 4:Classifier

4:Classifier

type

type

Abb. 5.111: Der In-Teil ist eine NavigationCallExp

L R

InsertLetExpInNavigationCallExp2()

1:LetExp

2:Constraint kind=k

3:exp

1:LetExp

3:exp

:NavigationCallExp

exp

in 1:IExp

:VOCLExp

in

NAC

2:Constraint kind=k

k<>definition


type

5:type

5:type

Abb. 5.112: Der In-Teil ist eine NavigationCallExp


L R

InsertLetExpInBooleanExp()

1:LetExp

2:Constraint kind=k

3:exp

1:LetExp

3:exp

:BooleanExp

exp

in 1LetExp

:VOCLExp

in

NAC

2:Constraint kind=k

k<>definition

4:Classifier name="Boolean" 4:Classifier

name="Boolean"

type

type 1LetExp

:Classifier

type

NAC

Abb. 5.113: Der In-Teil ist eine BooleanExp

L R

InsertLetExpInBooleanExp2()

1:LetExp

2:Constraint kind=k

3:exp

1:LetExp

3:exp

:BooleanExp

exp

in 1LetExp

:VOCLExp

in

NAC

2:Constraint kind=k

k<>definition

4:Classifier name="Boolean"

4:Classifier name="Boolean"

type

5:type 5:type

Abb. 5.114: Der In-Teil ist eine BooleanExp

L R

InsertLetExpInIfExp()

1:LetExp

2:Constraint kind=k

3:exp

1:LetExp

3:exp

:IfExp

exp

in 1:LetExp

:VOCLExp

in

NAC

2:Constraint kind=k

k<>definition

1LetExp

:Classifier

type

NAC 5:Classifier 5:Classifier

type

type

Abb. 5.115: Der In-Teil ist eine IfExp


L R

InsertLetExpInIfExp2()

1:LetExp

2:Constraint kind=k

3:exp

1:LetExp

3:exp

:IfExp

exp

in 1:LetExp

:VOCLExp

in

NAC

2:Constraint kind=k

k<>definition


type

4:type 4:type

Abb. 5.116: Der In-Teil ist eine IfExp

L R

InsertLetExpInLetExp(vName:String)

1:LetExp

4:exp

1:LetExp

:VOCLExp

in

NAC

1:LetExp

2:Constraint

:LetExp 4:exp

exp

in

type

5:Classifier



NAC


variable

variable

k<>definition

2:Constraint kind=k

1LetExp

:Classifier

type

NAC

3:Classifier

3:Classifier

type

Abb. 5.117: Der In-Teil ist eine LetExp

L R

InsertLetExpInLetExp2(vName:String)

1:LetExp

4:exp

1:LetExp

:VOCLExp

in

NAC

1:LetExp

2:Constraint

:LetExp 4:exp

exp

in

type

5:Classifier



NAC


variable

variable

k<>definition

2:Constraint kind=k

3:Classifier

3:Classifier

6:type

6:type

Abb. 5.118: Der In-Teil ist eine LetExp


Die folgenden Transformation Units steuern das Einfügen eines Let Ausdrucks.

Wenn der Typ der Variablen Boolean ist, kann sie mit dem Ergebnis eines korrekten Pfadausdrucks(also der Gültigkeit dieses Ausdrucks) initialisiert werden, dann wäre die Initialisierung ein Pfad.Die Transformation Unit InsertPathLetInit initialisiert die Letvariable mit einem Navigationsausdruck(mit der Regel InsertLetExpVarInitNavigationCallExp). Dieser beginnt an einer Startrolle, die mit derTransformationUnit InsertPathStart eingefügt wird.Nachdem eine Startrolle und eine Startnavigation eingefügt wurde, können alle Alternativen zum Ein-fügen eines korrekten Pfades eingefügt werden. Eine der TransformationUnits InsertEquivalentPathes-Nav, InsertAttributeNav, InsertMethodNav, InsertSimpleCollOpNav, InsertConditionNav, InsertState-Nav oder InsertMessageNav kann angewendet werden.

Oder die Variable wird mit einem Attributwert initialisiert, zu dem zunächst navigiert wird (Transfor-mation Unit InsertAttributeNavLetInit), oder mit dem Ergebnis eines Methodenaufrufs (Transforma-tion Unit InsertMethodNavLetInit), oder mit einer ClassifierRole bzw. CollectionRole, zu der navigiertwird (Transformation Unit InsertRoleNodeNavLetInit).In diesen drei Transformation Units wird zuerst ein Navigationsausdruck mit Startrolle, an der dieNavigation beginnt, eingefügt (analog zum Einfügen eines Navigationsausdrucks bei einer IfExp).Danach können beliebig viele weitere Pfadknoten eingefügt werden (Transformation Unit InsertPath-Node).Bei der Navigation zu einem Attributwert wird dann eine Variablenzuweisung eingefügt, die der Let-variablen den Wert eines Attributs des letzten Pfadknotens zuweist (InsertAttributeAssignment).Bei der Navigation zum Ergebniswert eines Methodenaufrufs wird mit der Regel InsertMethodOp2 dieMethode eingefügt und ihr Ergebnis der Variablen zugewiesen.Bei der Initialisierung mit einer ClassifierRole/ CollectionRole wird der letzten ClassifierRole/ Collec-tionRole, zu der navigiert wurde, der Name der Variablen mit der Regel InsertClassifierRoleName/InsertCollectionRoleName gegeben. Der Typ der Variablen ist gleich dem der ClassifierRole/ Collec-tionRole.Die restlichen Transformation Units sind analog zu den Transformation Units zum Einfügen eines boo-leschen Ausdrucks oder eines If-Then-Else Ausdrucks.

Definition-Constraints

Die Transformation Unit InsertDefinitionConstraint fügt einen definition-Constraint ein. In diesem istnur ein Let Ausdruck enthalten, der eine Variable definiert, die auch außerhalb des Constraints bekanntist und somit für das gesamte UMLModell verwendet werden kann.Dafür wird zunächst ein Constraint der Art definition mit der Regel CreateConstraint1("def") erzeugt.Danach kann optional eine ConstraintVariable und ein ConstraintName eingefügt werden. Der Bodybesteht aus einer LetExp (Transformation Unit InsertLetExpression). Die Regeln zum Einfügen einerLetExp verhindern, dass eine LetExp innerhalb eines definition-Constraints einen In-Teil hat.


InsertAttributeNavLetInit(varName, aName)

InsertLetExpVarInitNavigationCallExp() ; insertPathStart ; InsertPathNode *; InsertAttributeAssignment(varName, aName) ;

InsertMethodNavLetInit(varName, mName)

InsertLetExpVarInitNavigationCallExp() ; insertPathStart ; InsertPathNode *; InsertMethodOp2(mName, varName) ;

InsertClassifierNodeNavLetInit(varName)

InsertLetExpVarInitNavigationCallExp() ; insertPathStart ; InsertPathNode *; InsertClassifierRoleName(varName) xor InsertCollectionRoleName(varName) ;

InsertLetExpression

InsertLetExp(varName) ; InsertLetInitVar(varName) ; InsertLetExpIn ;

InsertLetVarPathInitialisation(varName)

IInsertPathLetInit or InsertAttributeNavLetInit(varName, aName) or InsertMethodNavLetInit(varName, mName) or InsertClassifierNodeNavLetInit(varName) ;

InsertLetExpInitVarBooleanExpression

InsertLetExpInitVarBooleanExp() ; InsertBooleanExp ;

InsertLetExpInitVarIfExpression

InsertLetExpInitVarIfExp() ; InsertIfExp ;

InsertLetExpInitVarLetExpression

InsertLetExpInitVarLetExp() ; InsertLetExp ;

InsertLetExpInitVar(varName)

InsertLetExpInitVarBooleanExpression or InsertLetExpInitVarIfExpression or InsertLetExpInitVarLetExpression or InsertLetExpInitVarPathInitialisation(varName) ;

InsertPathLetInit

InsertLetExpVarInitNavigationCallExp() ; InsertPath ;

InsertLetExpInNavigation

(InsertLetExpInNavigationCallExp() or InsertLetExpInNavigationCallExp2()) ; InsertPath ;

InsertLetExpInBooleanExpression

(InsertLetExpInBooleanExp() or InsertLetExpInBooleanExp()) ; InsertBooleanExp ;

InsertLetExpInIfExpression

(InsertLetExpInIfExp() or InsertLetExpInIfExp()) ; InsertIfExp ;

InsertLetExpInLetExpression

(InsertLetExpInLetExp() or InsertLetExpInLetExp()) ; InsertLetExp ;

InsertLetExpIn

InsertLetExpInBooleanExpression or InsertLetExpInIfExpression or InsertLetExpInLetExpression or InsertLetExpInNavigation ;

InsertDefinitionConstraint

CreateConstraint1("def") ; InsertConstraintName(cn) *; InsertConstraintVar(cv) ?; InsertLetExpression ;


Collection Operationen

Die Regel InsertSetOpSetResult1 fügt die Vereinigung, Schnittmenge, Differenz oder Xoder zweierSetRoles ein. Das Ergebnis einer dieser Operationen ist wieder eine SetRole, die ein Knoten in einemNavigationspfad sein kann. Die beiden SetRoles müssen Elemente des gleichen Typs haben, damit dieRegel angewendet werden kann. Dann wird die MathSetExp eingefügt, das Ergebnis wird ein Knotendes Pfads, zu dem das erste Argument gehört. Es darf keine andere Operation auf die beiden Setsangewendet werden und auch keine Navigation von ihnen starten (NAC). Die darauf folgenden Regelnzum Einfügen einer MathSetExp sind ähnlich aufgebaut und werden nicht ausführlicher beschrieben.Die Typen der Ergebnisse und Argumente hängen von den verschiedenen Operationen ab.

L R

InsertMathSetOpSetResult1(opName:COpEnum)

1:SetRole

2:SetRole

:MathSetOp name=opName

3:Classifier

4:type

5:type

1:SetRole

2:SetRole

3:Classifier

4:type

5:type

:SetRole

type

navSource

arg2

result opName = #setunion v #setdiff v #setintersection v #etxor

6:Path

7:node

6:Path

7:node

node

1:SetRole

navSource

:NavigationRoleExp

NAC

2:SetRole

navSource

:NavigationRoleExp

NAC

Abb. 5.119: Einfügen von Mengenoperationen, die Sets als Ergebnis haben

L R


1:SetRole


3:Classifier

4:type

5:type

1:SetRole

2:BagRole

3:Classifier

4:type

5:type

:SetRole

type

navSource

arg2

result opName = #setintersection

2:BagRole

6:Path

7:node

node

6:Path

7:node

1:SetRole

navSource

:NavigationRoleExp

NAC

2:BagRole

navSource

:NavigationRoleExp

NAC



L R


1:SetRole


3:Classifier

4:type

5:type

1:SetRole

2:ClassifierRole

3:Classifier

4:type

5:type

:SetRole

type

navSource

arg2

result opName = #including v #excluding

2:ClassifierRole

7:node

6:Path 6:Path

7:node

node

1:SetRole

navSource

:NavigationRoleExp

NAC

2:ClassifierRole

navSource

:NavigationRoleExp

NAC


L R

InsertMathSetOpBagResult1(opName:COpEnum)

1:BagRole


3:Classifier

4:type

5:type

1:BagRole

2:BagRole

3:Classifier

4:type

5:type

:BagRole

type

navSource

arg2

result opName = #bagunion v #bagintersection

2:BagRole

6:Path

7:node

6:Path

7:node

node

1:BagRole

navSource

:NavigationRoleExp

NAC

2:BagRole

navSource

:NavigationRoleExp

NAC

Abb. 5.122: Einfügen von Mengenoperationen, die Bags als Ergebnis haben


L R


1:BagRole


3:Classifier

4:type

5:type

1:BagRole

2:SetRole

3:Classifier

4:type

5:type

:BagRole

type

navSource

arg2

result opName = #bagunion

2:SetRole 6:Path

7:node

6:Path

7:node

node

1:BagRole

navSource

:NavigationRoleExp

NAC

2:SetRole

navSource

:NavigationRoleExp

NAC


L R


1:BagRole


3:Classifier

4:type

5:type

1:BagRole

2:ClassifierRole

3:Classifier

4:type

5:type

:BagRole

type

navSource

arg2

result opName = #including v #excluding

2:ClassifierRole 6:Path

7:node

6:Path

7:node

node

1:BagRole

navSource

:NavigationRoleExp

NAC

2:ClassifierRole

navSource

:NavigationRoleExp

NAC



L R

InsertMathSetOpSequenceResult1(opName:COpEnum)

1:SequenceRole


3:Classifier

4:type

5:type

1:SequenceRole

2:SequenceRole

3:Classifier

4:type

5:type

:SequenceRole

type

navSource

arg2

result opName = #sequenceunion v #subsequence

2:SequenceRole

6:Path

7:node

6:Path

7:node

node

1:SequenceRole

navSource

:NavigationRoleExp

NAC

2:SequenceRole

navSource

:NavigationRoleExp

NAC

Abb. 5.125: Einfügen von Mengenoperationen, die Sequences als Ergebnis haben

L R


1:SequenceRole


3:Classifier

4:type

5:type

1:SequenceRole

2:ClassifierRole

3:Classifier

4:type

5:type

:SequenceRole

type

navSource

arg2

result opName = #append v #prepend v #including v #excluding

2:ClassifierRole

6:Path

7:node

6:Path

7:node

node

1:SequenceRole

navSource

:NavigationRoleExp

NAC

2:ClassifierRole

navSource

:NavigationRoleExp

NAC



L R


1:SequenceRole


3:Classifier

4:type

5:type

1:SequenceRol e

2:ClassifierRole

3:Classifier

4:type

5:type

:ClassifierRole

type

navSource

arg2

result opName = #at v #first v #last

2:ClassifierRole

6:Path

7:node

6:Path

7:node

node

1:SequenceRole

navSource

:NavigationRoleExp

NAC

2:ClassifierRole

navSource

:NavigationRoleExp

NAC


Die in diesem Abschnitt beschriebenen Operationen auf Collections könnten prinzipiell, da sie einenRoleNode als Ergebnis liefern (ähnlich einer CRTMethod), auch verwendet werden, um zwei äquivalentePfade mit einem gemeinsamen Ende zu verbinden (siehe die Regel InsertPathEndCRTMethod). Dannwürde man zwei Pfadanfänge und zwei Pfade einfügen und am Ende zwischen die beiden aktuellenPfadenden die Operation, so dass das eine Ende das Ergebnis der Operation darstellt. Da man dieseSituation genauso durch eine andere Reihenfolge der Anwendung der Regeln ausdrücken kann (dannwird zuerst die Operation angewendet und deren Ergebnisrolle als Pfadende betrachtet und dannzwischen dieser Ergebnisrolle und dem anderen Pfadende eine normale Navigation eingeführt), wirdauf diese Regeln verzichtet. Dasselbe gilt für die im folgenden Abschnitt beschriebenen Loop Ausdrücke.


Loop Ausdrücke

Es gibt verschiedene Loop Ausdrücke, die jeweils über eine Collection iterieren. Die folgenden LoopAusdrücke haben einen Body, der in einem eigenen Rahmen visualisiert wird und eine der konkretenAusprägungen einer VOCLExp (NavigationCallExp, IfExp, BooleanExp, LetExp) sein kann. Entspre-chend gibt es für jeden Loop Ausdruck vier verschiedene Regeln. Diese sind nicht alle dargestellt. DieErgebnisse eines Loop Ausdrucks hängen von seinem Namen, also der ausgeführten Operation auf derCollectionRole, ab und können ein boolescher Wert, eine ClassifierRole oder eine CollectionRole sein.Für die Operationen, die eine CollectionRole liefern, gibt es jeweils (also für jede konkrete Ausprägungdes Bodys) drei Regeln (eine für SetRole, eine für BagRole und eine für SequenceRole). Es ist jeweilseine dargestellt.

Die Regel InsertAnyExpWithNavigationBody fügt an eine CollectionRole, die das bisherige Ende einesPfades ist, eine LoopExp mit dem Namen any und einem Iterator mit dem übergebenen Namen ein.Der Iterator hat den Typ der Elemente der CollectionRole, die Variable darf im Constraint noch nichtdefiniert worden sein. Der Body ist ein Navigationsausdruck, dessen Startrolle durch noch folgendeRegeln eingefügt werden muss. Dieser Navigationsausdruck wird nun auch in den Constraint eingefügt.Zusätzlich wird dieser Ausdruck als loopExp in die BodyLoopExp eingefügt. Dies dient einem späterenEinfügen eines Navigationsausdrucks, der nur innerhalb einer BodyLoopExp an der Iteratorvariablenstartet. Das Ergebnis ist eine ClassifierRole, die nun in den Pfad eingetragen wird und auch den Typder Elemente der Collection hat. Es ist irgendein Element der Collection, das den Body erfüllt.

L R

InsertAnyExpWithNavigationBody(iteratorname:String)

1:CollectionRole

1:CollectionRole

:VariableDeclaration name=iteratorname

:BodyLoopExp name=#any

:ClassifierRole

2:Classifier 3:base

3:base

base

navSource

resultRole

2:Classifier

iterator

body

4:Path

5:NavigationCallExp

6:Constraint

7:node

8:nce 9:exp

4:Path

5:NavigationCallExp 6:Constraint

7:node

8:nce 9:exp

node

variable

variable

NAC

6:Constraint


type

:NavigationCallExp exp

1:CollectionRole

navSource

:NavigationRoleExp

NAC

loopExp

Abb. 5.128: LoopExp mit der Operation any, der Body ist ein Navigationsausdruck


Die Regel InsertAnyExpWithIfBody fügt an eine CollectionRole, die das bisherige Ende eines Pfades ist,eine LoopExp mit dem Namen any und einem Iterator mit dem übergebenen Namen ein. Der Iteratorhat den Typ der Elemente der CollectionRole, die Variable darf im Constraint noch nicht definiertworden sein. Der Body ist ein If-Then-Else-Ausdruck, der nun auch in den Constraint eingefügt wird.

L R

InsertAnyExpWithIfBody(iteratorname:String)

1:CollectionRole

1:CollectionRole



:ClassifierRole

2:Classifier 3:base

3:base

base

navSource

resultRole

2:Classifier

iterator

body

4:Path

5:NavigationCallExp

6:Constraint

7:node

8:nce 9:exp

4:Path


7:node

8:nce 9:exp

node

variable

variable

NAC

6:Constraint


type

:IfExp exp

1:CollectionRole

navSource

:NavigationRoleExp

NAC

loopExp

Abb. 5.129: LoopExp mit der Operation any, der Body ist ein If-Then-Else-Ausdruck

Die Regel InsertAnyExpWithBooleanExpBody fügt an eine CollectionRole, die das bisherige Ende einesPfades ist, eine LoopExp mit dem Namen any und einem Iterator mit dem übergebenen Namen ein.Der Iterator hat den Typ der Elemente der CollectionRole, die Variable darf im Constraint noch nichtdefiniert worden sein. Der Body ist ein boolescher Ausdruck, der nun auch in den Constraint eingefügtwird.


L R

InsertAnyExpWithBooleanExpBody(iteratorname:String)

1:CollectionRole

1:CollectionRole



:ClassifierRole

2:Classifier 3:base

3:base

base

navSource

resultRole

2:Classifier

iterator

body

4:Path

5:NavigationCallExp

6:Constraint

7:node

8:nce 9:exp

4:Path


7:node

8:nce 9:exp

node

variable

variable

NAC

6:Constraint


type

:BooleanExp exp

1:CollectionRole

navSource

:NavigationRoleExp

NAC

loopExp

Abb. 5.130: LoopExp mit der Operation any, der Body ist ein boolescher Ausdruck

Die Regel InsertAnyExpWithLetBody fügt an eine CollectionRole, die das bisherige Ende eines Pfadesist, eine LoopExp mit dem Namen any und einem Iterator mit dem übergebenen Namen ein. DerIterator hat den Typ der Elemente der CollectionRole, die Variable darf im Constraint noch nichtdefiniert worden sein. Der Body ist ein Let-Ausdruck, der nun auch in den Constraint eingefügt wird.Zusätzlich wird die neue Variable, die in dem Let-Ausdruck definiert wird, in den Constraint eingefügt(in dem es noch keine Variable mit einem solchen Namen geben darf).

L R

InsertAnyExpWithLetBody(iteratorname:String, letVarName: String)

1:CollectionRole

1:CollectionRole



:ClassifierRole

2:Classifier 3:base

3:base

base

navSource

resultRole

2:Classifier

iterator

body

4:Path

5:NavigationCallExp

6:Constraint

7:node

8:nce 9:exp

4:Path

5:NavigationCallExp

6:Constraint

7:node

8:nce

9:exp

node

variable

variable

NAC

6:Constraint


type

:LetExp

exp


:VariableDeclaration name=letVarName type

variable

letVar

variable

NAC

6:Constraint

:VariableDeclaration name=letVarName

1:CollectionRole

navSource

:NavigationRoleExp

NAC

loopExp

Abb. 5.131: LoopExp mit der Operation any, der Body ist ein Let-Ausdruck


Die Regel InsertSelectionExpWithNavigationBody1 fügt an eine CollectionRole, die das bisherige Endeeines Pfades ist, eine LoopExp mit dem Namen select und einem Iterator mit dem übergebenen Namenein. Der Iterator hat den Typ der Elemente der CollectionRole, die Variable darf im Constraint nochnicht definiert worden sein. Der Body ist ein Navigationsausdruck, dessen Startrolle durch noch folgendeRegeln eingefügt werden muss. Dieser Navigationsausdruck wird nun auch in den Constraint eingefügt.Das Ergebnis ist eine SetRole, die nun in den Pfad eingetragen wird und auch den Typ der Elementeder Collection hat. Es sind die Elemente der Collection, die den Body erfüllen.

L R

InsertSelectionExpWithNavigationBody1(iteratorname:String, loopexpname: LoopEnum)

1:CollectionRole


:BodyLoopExp name=#loopexpname

:SetRole type

navSource

resultRole

2:Classifier

iterator

:NavigationCallExp

body

loopexpname= #select v #reject

1:CollectionRole

2:Classifier 3:base 4:Path

5:NavigationCallExp

6:Constraint

7:node

8:nce 9:exp

3:base

4:Path

5:NavigationCallExp

6:Constraint

7:node

8:nce 9:exp exp

node

variable

variable

NAC

6:Constraint


type

1:CollectionRole

navSource

:NavigationRoleExp

NAC

loopExp

Abb. 5.132: LoopExp mit der Operation selectoder reject, der Body ist ein Navigationsausdruck

Die Regel InsertSelectionExpWithNavigationBody2 sieht genauso aus wie InsertSelectionExpWithNa-vigationBody1, hat aber eine BagRole als Ergebnis, InsertSelectionExpWithNavigationBody3 eine Se-quenceRole.


Die Regel InsertCollectExpWithNavigationBody2 fügt an eine CollectionRole, die das bisherige Endeeines Pfades ist, eine LoopExp mit dem Namen collect und einem Iterator mit dem übergebenen Na-men ein. Der Iterator hat den Typ der Elemente der CollectionRole, die Variable darf im Constraintnoch nicht definiert worden sein. Der Body ist ein Navigationsausdruck, dessen Startrolle durch nochfolgende Regeln eingefügt werden muss. Dieser Navigationsausdruck wird nun auch in den Constrainteingefügt. Das Ergebnis ist eine BagRole, die nun in den Pfad eingetragen wird.

Die Regel InsertCollectExpWithNavigationBody1 sieht genauso aus, hat aber eine SetRole als Ergebnis,die Regel InsertCollectExpWithNavigationBody3 eine SequenceRole.

L R

InsertCollectExpWithNavigationBody(iteratorname:String)

1:CollectionRole


:BodyLoopExp name=#collect

:BagRole type

navSource

resultRole

2:Classifier

iterator

:NavigationCallExp

body

1:CollectionRole


5:NavigationCallExp

6:Constraint

7:node

8:nce 9:exp

3:base

4:Path

5:NavigationCallExp

6:Constraint

7:node 8:nce

9:exp

exp

variable

NAC

6:Constraint


node

variable

type

1:CollectionRole

navSource

:NavigationRoleExp

NAC

loopExp

Abb. 5.133: LoopExp mit der Operation collect, der Body ist ein Navigationsausdruck

Die Regel InsertSortedByWithNavigationBody fügt an eine CollectionRole, die das bisherige Ende einesPfades ist, eine LoopExp mit dem Namen sortedBy und einem Iterator mit dem übergebenen Namenein. Der Iterator hat den Typ der Elemente der CollectionRole, die Variable darf im Constraint nochnicht definiert worden sein. Der Body ist ein Navigationsausdruck, dessen Startrolle durch noch folgendeRegeln eingefügt werden muss. Dieser Navigationsausdruck wird nun auch in den Constraint eingefügt.Das Ergebnis ist eine SequenceRole, die nun in den Pfad eingetragen wird und dieselben Elemente wiedie CollectionRole enthält, diese sind nach dem Ausdruck im Body sortiert worden.


L R

InsertSortedByExpWithNavigationBody(iteratorname:String)

1:CollectionRole


:BodyLoopExp name=#collect

type

navSource

resultRole

2:Classifier

iterator

:NavigationCallExp

body

1:CollectionRole


5:NavigationCallExp

6:Constraint

7:node

8:nce 9:exp

3:base

4:Path

5:NavigationCallExp

6:Constraint

7:node

8:nce 9:exp

exp

:SequenceRole

variable

NAC

6:Constraint


node

variable

type

1:CollectionRole

navSource

:NavigationRoleExp

NAC

loopExp

Abb. 5.134: LoopExp mit der Operation sortedBy, der Body ist ein Navigationsausdruck

Die Regel InsertBoolLoopWithNavigationBody fügt an eine CollectionRole, die das bisherige Ende einesPfades ist, eine LoopExp mit dem Namen forall oder exists oder one oder isUnique und einem Iteratormit dem übergebenen Namen ein. Der Iterator hat den Typ der Elemente der CollectionRole, dieVariable darf im Constraint noch nicht definiert worden sein. Der Body ist ein Navigationsausdruck,dessen Startrolle durch noch folgende Regeln eingefügt werden muss. Dieser Navigationsausdruck wirdnun auch in den Constraint eingefügt. Das Ergebnis ist ein boolescher Wert. Der Pfad endet an derCollectionRole, auf die die Operation angewendet wird, und die entsprechende NavigationCallExpbekommt den Typ des Navigationsendes.

L R

InsertBoolLoopWithNavigationBody(iteratorname:String, loopexpname: LoopEnum)

1:CollectionRole



navSource

2:Classifier

iterator

:NavigationCallExp

body

1:CollectionRole


5:NavigationCallExp

6:Constraint

7:node

8:nce 9:exp

3:base

4:Path


8:nce 9:exp

exp loopexpname= #forall v #exists v

#one v #isUnique

4:LiteralExp name="true"


type

end

variable

variable

NAC

6:Constraint


type

type

NAC

5:NavigationCallExp

:Classifier

type 1:CollectionRole

navSource

:NavigationRoleExp

NAC

loopExp

Abb. 5.135: LoopExp mit der Operation forall oder exists oder one oder isUnique, der Body ist einNavigationsausdruck


Die Regel InsertBoolLoopWithNavigationBody_2 macht genau dasselbe wie InsertBoolLoopWithNavi-gationBody, nur dass in diesem Fall bereits der Typ der NavigationCallExp festgelegt ist und mit demTyp des Navigationsendes übereinstimmen muss, was auf der linken Regelseite dargestellt ist.

L R

InsertBoolLoopWithNavigationBody_2(iteratorname:String, loopexpname: LoopEnum)

1:CollectionRole



navSource

2:Classifier

iterator

:NavigationCallExp

body

1:CollectionRole


5:NavigationCallExp

6:Constraint

7:node

8:nce

9:exp

3:base

4:Path


8:nce 9:exp

exp loopexpname= #forall v

#exists v #one v

#isUnique



type

end

variable

variable

NAC

6:Constraint


type

10:type 10:type

1:CollectionRole

navSource

:NavigationRoleExp

NAC

loopExp

Abb. 5.136: LoopExp mit der Operation forall oder exists oder one oder isUnique, der Body ist einNavigationsausdruck

Die Regel InsertForallExpWithNavigationBody fügt eine forall Expression mit zwei Iteratoren ein. DerRest ist analog zur Regel InsertBoolLoopWithNavigationBody.

Auch hier gibt es eine entsprechende Regel InsertForallLoopWithNavigationBody_2, bei der der Typder NavigationCallExp festgelegt ist und mit dem Typ des Navigationsendes übereinstimmen muss.Diese wurde nicht explizit dargestellt.


L R

InsertForallExpWithNavigationBody(i1name:String, i2name: String)

1:CollectionRole

:VariableDeclaration name=i1name

:BodyLoopExp name=#forall

navSource 2:Classifier

iterator

:NavigationCallExp body

1:CollectionRole


5:NavigationCallExp

6:Constraint

7:node

8:nce 9:exp

3:base

4:Path


end

8:nce

9:exp i1name<>i2name



type


iterator

variable

variable

variable

NAC

6:Constraint


variable

NAC

6:Constraint


type

type

exp

1:CollectionRole

navSource

:NavigationRoleExp

NAC

loopExp

Abb. 5.137: LoopExp mit der Operation forall und zwei Iteratoren, der Body ist ein Navigationsausdruck

Da der Body einer BodyLoopExp einen Navigationsausdruck enthalten kann, der bei der Iteratorvaria-blen startet und dieser Navigationsausdruck auch beliebig in anderen VOCLExps des Bodys auftretenkann, muss beim Einfügen des Bodys einer BodyLoopExp eine Kante loopExp miteingefügt werden.Wenn also eine solche Kante zwischen einer VOCLExp und einer BodyLoopExp existiert, ist die VOCL-Exp ein AUsdruck innerhalb des Bodys der LoopExp.Nun müssen die Regeln zum Einfügen von VOCLExps als Ausdrücke innerhalb des Bodys einer Loop-Exp erstellt werden. Diese ähneln denen zum Einfügen der VOCLExps in einen Constraint (sieheAbschnitt 5.3.3).Danach werden die Transformation Units zum Einfügen von VOCLExps als Body einer LoopExp de-finiert. Auch diese sind den Transformation Units InsertIfExpression, InsertBooleanExpression, etc.sehr ähnlich und unterscheiden sich nur dadurch, dass die VOCLExp nun eine Kante loopExp zu einerBodyLoopExp hat.Dann können die Transformation Units zum Einfügen der verschiedenen BodyLoopExps definiert wer-den.Anschließend wird die Transformation Unit InsertBodyLoopExp definiert.

Regeln zum Einfügen von VOCLExps als Ausdrücke innerhalb des Bodys einer LoopExp:


L R

InsertIfExpIfNavigationCallExpInsideABodyLoop()

1:IfExp

2:Constraint

3:exp

1:IfExp

2:Constraint

3:exp

:NavigationCallExp

exp

if

1:IfExp

:VOCLExp

if

NAC



type

5:BodyLoopExp 6:loopExp


loopExp

Abb. 5.138: Ein Navigationsausdruck als If-Teil innerhalb einer BodyLoopExp

L R

InsertIfExpIfBooleanExpInsideABodyLoop(opName:BOpEnum)

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

if

NAC

1:IfExp



4:exp

exp

if

type



loopExp

5:BodyLoopExp

6:loopExp

Abb. 5.139: Ein boolescher Ausdruck als If-Teil innerhalb einer BodyLoopExp

L R

InsertIfExpIfIfExpInsideABodyLoop()

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

if

NAC

1:IfExp

2:Constraint


:IfExp


4:exp exp

if

type

5:BodyLoopExp

6:loopExp loopExp

5:BodyLoopExp

6:loopExp

Abb. 5.140: Ein If-Then-Else Ausdruck als If-Teil innerhalb einer BodyLoopExp


L R

InsertIfExpIfLetExpInsideABodyLoop(vName:String)

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

if

NAC

1:IfExp


:LetExp


4:exp exp

if

type 5:Classifier


variable type

2:Constraint

NAC


variable variable

7:BodyLoopExp

6:loopExp loopExp


Abb. 5.141: Ein Let Ausdruck als If-Teil innerhalb einer BodyLoopExp

L R

InsertIfExpThenNavigationCallExpInsideABodyLoop()

1:IfExp

2:Constraint

3:exp

1:IfExp

2:Constraint

3:exp

:NavigationCallExp

exp

then

1:IfExp

:VOCLExp

then

NAC

type


type

1:IfExp

type

NAC

:Classifier


loopExp

5:BodyLoopExp

6:loopExp

Abb. 5.142: Ein Navigationsausdruck als Then-Teil innerhalb einer BodyLoopExp

Die Regel InsertIfExpThenNavigationCallExp2InsideABodyLoop ist analog definiert (siehe auch dieRegel InsertIfExpThenNavigationCallExp2, Abb. 5.88).

L R

InsertIfExpThenBooleanExpInsideABodyLoop(opName:BOpEnum)

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

then

NAC

1:IfExp



4:exp exp

then

type


type

1:IfExp

type

NAC

:Classifier

5:BodyLoopExp

6:loopExp

loopExp 5:BodyLoopExp

6:loopExp

Abb. 5.143: Ein boolescher Ausdruck als Then-Teil innerhalb einer BodyLoopExp

Die Regel InsertIfExpThenBooleanExp2InsideABodyLoop ist analog definiert (siehe auch die Regel


InsertIfExpThenBooleanExp2, Abb. 5.90).

L R

InsertIfExpThenIfExpInsideABodyLoop()

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

then

NAC

1:IfExp



4:exp exp

then

type

type

1:IfExp

type

NAC

:Classifier

5:BodyLoopExp

6:loopExp

loopExp 5:BodyLoopExp

6:loopExp

:IfExp

Abb. 5.144: Ein If-Then-Else als Then-Teil innerhalb einer BodyLoopExp

Die Regel InsertIfExpThenIfExp2InsideABodyLoop ist analog definiert (siehe auch die Regel Inser-tIfExpThenIfExp2, Abb. 5.92).

L R

InsertIfExpThenLetExpInsideABodyLoop(vName:String)

1:IfExp

2:Constraint

4:exp

1:IfExp

:VOCLExp

then

NAC

1:IfExp

2:Constraint

:LetExp 4:exp

exp

then

type


variable type

2:Constraint

NAC


variable

variable


type

1:IfExp

type

NAC

:Classifier

5:BodyLoopExp

6:loopExp loopExp

5:BodyLoopExp

6:loopExp

Abb. 5.145: Ein Let Ausdruck als Then-Teil innerhalb einer BodyLoopExp

Die Regel InsertIfExpThenLetExp2InsideABodyLoop ist analog definiert (siehe auch die Regel In-sertIfExpThenLetExp2, Abb. 5.94)


L R

InsertIfExpElseNavigationCallExpInsideABodyLoop()

1:IfExp

2:Constraint

3:exp

5:VOCLExp

7:exp

6:then

1:IfExp

:VOCLExp

else

NAC

8:type

4:Classifier

1:IfExp

2:Constraint

3:exp

5:VOCLExp

7:exp

6:then

8:type

4:Classifier

:NavigationCallExp

exp else

type

8:BodyLoopExp

9:loopExp loopExp

8:BodyLoopExp

9:loopExp

Abb. 5.146: Ein Navigationsausdruck als Else-Teil innerhalb einer BodyLoopExp

L R

InsertIfExpElseBooleanExpInsideABodyLoop(opName:BOpEnum)

1:IfExp

:VOCLExp

else

NAC

1:IfExp


4:exp 7:exp

6:then

8:type 7:exp

6:then

8:type

exp else type

1:IfExp


4:exp

5:VOCLExp 5:VOCLExp


8:BodyLoopExp

9:loopExp loopExp

8:BodyLoopExp

9:loopExp

Abb. 5.147: Ein boolescher Ausdruck als Else-Teil innerhalb einer BodyLoopExp

L R

InsertIfExpElseIfExpInsideABodyLoop()

1:IfExp

2:Constraint

3:exp

5:VOCLExp

7:exp

6:then

1:IfExp

:VOCLExp

else

NAC

8:type

4:Classifier

1:IfExp

2:Constraint

3:exp

5:VOCLExp

7:exp

6:then

8:type

4:Classifier

:IfExp

exp else

type

8:BodyLoopExp

9:loopExp loopExp

8:BodyLoopExp

9:loopExp

Abb. 5.148: Ein If-Then-Else Ausdruck als Else-Teil innerhalb einer BodyLoopExp


InsertIfExpElseLetExpInsideABodyLoop(vName:String)

2:Constraint

NAC


variable

L R

1:IfExp

2:Constraint

3:exp

5:VOCLExp

7:exp

6:then

1:IfExp

:VOCLExp

else

NAC

8:type

4:Classifier

1:IfExp

2:Constraint

3:exp

5:VOCLExp

7:exp

6:then

8:type

4:Classifier

exp

else

type

9:Classifier

:LetExp


type

variable

9:Classifier

variable

10:BodyLoopExp

11:loopExp loopExp

10:BodyLoopExp

11:loopExp

Abb. 5.149: Ein Let Ausdruck als Else-Teil innerhalb einer BodyLoopExp

Die folgenden Transformation Units fügen eine VOCLExp in eine IfExp, die Teil des Bodys einerBodyLoopExp ist, ein.

InsertIfExpIfNavigationInsideABodyLoop

InsertIfExpIfNavigationCallExpInsideABodyLoop() ; InsertPathInsideABodyLoop ;

InsertIfExpElseNavigationInsideABodyLoop

(InsertIfExpElseNavigationCallExpInsideABodyLoop() or InsertIfExpElseNavigationCallExp2InsideABodyLoop()) ; InsertPath or (InsertNavStartAtIteratorVariable ; InsertNavStart ; InsertPathNode *; ) ;

InsertIfExpThenNavigationInsideABodyLoop

InsertIfExpThenNavigationCallExpInsideABodyLoop() ; InsertPathInsideABodyLoop or (InsertNavStartAtIteratorVariable ; InsertNavStart ; InsertPathNode *; ) ;

InsertIfExpIfBooleanExpressionInsideABodyLoop

InsertIfExpIfBooleanExpInsideABodyLoop() ; InsertBooleanExpInsideABodyLoop ; InsertIfExpThenBooleanExpressionInsideABodyLoop

InsertIfExpThenBooleanExpInsideABodyLoop() or InsertIfExpThenBooleanExp2InsideABodyLoop(); InsertBooleanExpInsideABodyLoop ;

InsertIfExpElseBooleanExpressionInsideABodyLoop

InsertIfExpElseBooleanExpInsideABodyLoop() ; InsertBooleanExpInsideABodyLoop ;

InsertIfExpThenIfExpressionInsideABodyLoop

(InsertIfExpThenIfExpInsideABodyLoop() or InsertIfExpThenIfExp2InsideABodyLoop()) ; InsertIfExpInsideABodyLoop ;

InsertIfExpElseIfExpressionInsideABodyLoop

InsertIfExpElseIfExp()InsideABodyLoop ; InsertIfExpInsideABodyLoop ;

InsertIfExpIfLetExpressionInsideABodyLoop

InsertIfExpIfLetExpInsideABodyLoop() ; InsertLetExpInsideABodyLoop ;

InsertIfExpThenLetExpressionInsideABodyLoop

(InsertIfExpThenLetExpInsideABodyLoop() or InsertIfExpThenLetExp2InsideABodyLoop()) ; InsertLetExpInsideABodyLoop ;

InsertIfExpElseLetExpressionInsideABodyLoop

InsertIfExpElseLetExpInsideABodyLoop() ; InsertLetExpInsideABodyLoop ;

InsertIfExpIfInsideABodyLoop

InsertIfExpIfBooleanExpressionInsideABodyLoop or InsertIfExpIfLetExpressionInsideABodyLoop or InsertIfExpIfNavigationInsideABodyLoop ;

InsertIfExpThenInsideABodyLoop

InsertIfExpThenBooleanExpressionInsideABodyLoop or InsertIfExpThenIfExpressionInsideABodyLoop or InsertIfExpThenLetExpressionInsideABodyLoop or InsertIfExpThenNavigationInsideABodyLoop ;

InsertIfExpElseInsideABodyLoop

InsertIfExpElseBooleanExpressionInsideABodyLoop or InsertIfExpElseIfExpressionInsideABodyLoop or InsertIfExpElseLetExpressionInsideABodyLoop or InsertIfExpElseNavigationInsideABodyLoop ;

InsertIfExpInsideABodyLoop

InsertIfExpIfInsideABodyLoop ; InsertIfExpThenInsideABodyLoop; InsertIfExpElseInsideABodyLoop;

InsertPathInsideABodyLoop

InsertNavStartAtIteratorVariable ; InsertNavStart ; (InsertEquivalentNav xor InsertAttributeNav xor InsertMethodNav xor InsertSimpleCollOpNav xor InsertConditionNav xor InsertMessageNav xor InsertStateNav) ;

InsertBooleanExpInsideABodyLoop

InsertBooleanExpArgInsideABodyLoop(1) ; InsertBooleanExpArgInsideABodyLoop(2);

InsertLetExpInsideABodyLoop

InsertLetExpInitVariableInsideABodyLoop(vn) ; InsertLetExpInInsideABodyLoop ;


L R

InsertBooleanExpArgNavigationCallExpInsideABodyLoop(ord:Integer)

1:BooleanExp name=n

2:Constraint

3:exp

2:Constraint

:NavigationCallExp

exp

arg order=ord :VOCLExp

NAC

3:exp

arg order=ord

ord <=2

1:BooleanExp name=n

1:BooleanExp name=n

NAC

1:BooleanExp name=n

ord = 2 n = #not


type 3:Classifier name=#Boolean

5:BodyLoopExp

6:loopExp loopExp

5:BodyLoopExp

6:loopExp

Abb. 5.150: Das Argument einer BooleanExp innerhalb einer BodyLoopExp ist ein Navigationsausdruck

L R

InsertBooleanExpArgBooleanExpInisdeABodyLoop(ord:Integer, opName:BOpEnum)

NAC

1:BooleanExp name=n

2:Constraint

3:exp

2:Constraint

exp

arg order=ord

:VOCLExp

3:exp

arg order=ord

ord <=2

1:BooleanExp name=n

1:BooleanExp name=n

1:BooleanExp name=n

ord = 2 n = #not

NAC



type



loopExp

5:BodyLoopExp

6:loopExp

Abb. 5.151: Das Argument einer BooleanExp innerhalb einer BodyLoopExp ist eine BooleanExp


L R

InsertBooleanExpArgIfExpInsideABodyLoop()

NAC NAC

1:BooleanExp name=n

2:Constraint

3:exp

2:Constraint

:IfExp

exp

arg order=ord

:VOCLExp

3:exp

arg order=ord

ord <=2

1:BooleanExp name=n

1:BooleanExp name=n

1:BooleanExp name=n

ord = 2 n = #not



type


loopExp

5:BodyLoopExp

6:loopExp

Abb. 5.152: Das Argument einer BooleanExp innerhalb einer BodyLoopExp ist eine IfExp

L R

InsertBooleanExpArg1LetExpInsideABodyLoop(vName:String)

2:Constraint

4:exp

:VOCLExp

NAC

2:Constraint


:LetExp


4:exp exp

type

5:Classifier


variable

type

variable

2:Constraint

NAC


variable

ord <=2

NAC

1:BooleanExp name=n

ord = 2 n = #not

1:BooleanExp name=n

1:BooleanExp name=n

1:BooleanExp name=n

arg order=ord

arg order=ord

7:BodyLoopExp

6:loopExp loopExp

7:BodyLoopExp

6:loopExp

Abb. 5.153: Das Argument einer BooleanExp innerhalb einer BodyLoopExp ist eine LetExp


Die Transformation Unit InsertBooleanExpression fügt einen booleschen Ausdrucks innerhalb einerBodyLoopExp ein.

InsertBooleanExpArgNavigationInsideABodyLoop(ord)

InsertBooleanExpArgNavigationCallExpInsideABodyLoop(ord) ; InsertPathInsideABodyLoop ;

InsertIfBooleanExpArgBooleanExpressionInsideABodyLoop(ord)

InsertBooleanExpArgBooleanExpInsideABodyLoop(ord) ; InsertBooleanExpInsideABodyLoop ;

InsertBooleanExpArgIfExpressionInsideABodyLoop(ord)

InsertBooleanExpArgIfExpInsideABodyLoop(ord) ; InsertIfExpInsideABodyLoop ;

InsertBooleanExpArgLetExpressionInsideABodyLoop(ord)

InsertBooleanExpArgLetExpInsideABodyLoop(ord) ; InsertLetExpInsideABodyLoop ;

InsertBooleanExpArgInsideABodyLoop(ord)

InsertBooleanExpArgBooleanExpressionInsideABodyLoop(ord) or InsertBooleanExpArgIfExpressionInsideABodyLoop(ord) or InsertBooleanExpArgLetExpressionInsideABodyLoop(ord) or InsertBooleanExpArgNavigationInsideABodyLoop(ord) ;

L R

InsertLetExpInitVarBooleanExpInsideABodyLoop(opname: BOpEnum)

1:LetExp

2:Constraint

5:exp


:VOCLExp

initExpression

NAC


7:type


1:LetExp

2:Constraint

5:exp


7:type


type

exp

initExpression

:BooleanExp name=opname

9:BodyLoopExp 10:loopExp loopExp

9:BodyLoopExp

10:loopExp

Abb. 5.154: Die Let-Variable im Body einer LoopExp wird mit einer BooleanExp initialisiert


L R

InsertLetExpInitVarIfExpInsideABodyLoop()

1:LetExp

2:Constraint

5:exp


:VOCLExp

initExpression

NAC


7:type

8:letVar

3:Classifier

1:LetExp

2:Constraint

5:exp


7:type


type

exp

initExpression

3:IfExp

9:BodyLoopExp loopExp

10:loopExp

9:BodyLoopExp

10:loopExp

Abb. 5.155: Die Let-Variable im Body einer LoopExp wird mit einer IfExp initialisiert

L R

InsertLetExpInitVarLetExpInsideABodyLoop(vname:String)

1:LetExp

2:Constraint

5:exp


:VOCLExp

initExpression

NAC


7:type

8:letVar 1:LetExp

2:Constraint

5:exp


7:type

8:letVar

exp

initExpression

:LetExp


letVar type

variable

2:Constraint

NAC


variable


3:Classifier

9:Classifier

type

9:BodyLoopExp

10:loopExp loopExp

9:BodyLoopExp

10:loopExp

Abb. 5.156: Die Let-Variable im Body einer LoopExp wird mit einer LetExp initialisiert


L

InsertLetExpVarInitNavigationCallExpInsideABodyLoop()

:VOCLExp

initExpression

NAC

1:LetExp

2:Constraint

5:exp


7:type

8:letVar

initExpression

3:Classifier 1:LetExp

2:Constraint

5:exp


7:type


:NavigationCallExp

R

initExpression

exp


NAC

2:Constraint


constrainedVar

type

9:BodyLoopExp

10:loopExp

loopExp

9:BodyLoopExp

10:loopExp

Abb. 5.157: Die Let-Variable im Body einer LoopExp wird mit einem Navigationsausdruck initialisiert

L R

InsertLetExpInNavigationCallExpInsideABodyLoop()

1:LetExp

2:Constraint kind=k

3:exp

1:LetExp

3:exp

:NavigationCallExp

exp

in

1:LetExp

:VOCLExp

in

NAC

2:Constraint kind=k

k<>definition

1:LetExp

:Classifier

type

NAC


type

type

9:BodyLoopExp 10:loopExp loopExp 9:BodyLoopExp

10:loopExp

Abb. 5.158: Der In-Teil eines Let Ausdrucks innerhalb einer BodyLoopExp ist eine NavigationCallExp

Die Regel InsertLetExpInNavigationCallExp2InsideABodyLoop ist analog definiert (siehe auch dieRegel InsertLetExpInNavigationCallExp2, Abb. 5.112).


L R

InsertLetExpInBooleanExpInsideABodyLoop()

1:LetExp

2:Constraint kind=k

3:exp

1:LetExp

3:exp

:BooleanExp

exp

in

1LetExp

:VOCLExp

in

NAC

2:Constraint kind=k

k<>definition

4:Classifier name="Boolean" 4:Classifier

name="Boolean"

type

type

1LetExp

:Classifier

type

NAC


9:BodyLoopExp

10:loopExp

Abb. 5.159: Der In-Teil eines Let Ausdrucks innerhalb einer BodyLoopExp ist eine BooleanExp

Die Regel InsertLetExpInBooleanExp2InsideABodyLoop ist analog definiert (siehe auch die RegelInsertLetExpInBooleanExp2, Abb. 5.114).

L R

InsertLetExpInIfExpInsideABodyLoop()

1:LetExp

2:Constraint kind=k

3:exp 1:LetExp

3:exp

:IfExp

exp

in

1:LetExp

:VOCLExp

in

NAC

2:Constraint kind=k

k<>definition

1LetExp

:Classifier

type

NAC

5:Classifier

5:Classifier

type

type


9:BodyLoopExp

10:loopExp

Abb. 5.160: Der In-Teil eines Let Ausdrucks innerhalb einer BodyLoopExp ist eine IfExp

Die Regel InsertLetExpInIfExp2InsideABodyLoop ist analog definiert (siehe auch die Regel Insert-LetExpInIfExp2, Abb. 5.116).


L R

InsertLetExpInLetExpInsideABodyLoop(vName:String)

1:LetExp

4:exp

1:LetExp

:VOCLExp

in

NAC

1:LetExp

2:Constraint

:LetExp 4:exp

exp

in

type 5:Classifier


variable type

2:Constraint

NAC


variable variable

k<>definition

2:Constraint kind=k

1LetExp

:Classifier

type

NAC

3:Classifier

3:Classifier

type


loopExp


Abb. 5.161: Der In-Teil eines Let Ausdrucks innerhalb einer BodyLoopExp ist eine LetExp

Die Regel InsertLetExpInLetExp2InsideABodyLoop ist analog definiert (siehe auch die Regel In-sertLetExpInLetExp2, Abb. 5.118).


Die Transformation Unit InsertLetExpressionInsideABodyLoop fügt als Body einer BodyLoopExp einenLet Ausdruck ein.

InsertAttributeNavLetInitInsideABodyLoop(varName, aName)

InsertLetExpVarInitNavigationCallExpInsideABodyLoop() ; insertNavStartAtIteratorVariable ; InsertNavStart ; InsertPathNode *; InsertAttributeAssignment(varName, aName) ;

InsertMethodNavLetInitInsideABodyLoop(varName, mName)

InsertLetExpVarInitNavigationCallExpInsideABodyLoop() ; insertNavStartAtIteratorVariable ; InsertNavStart ; InsertPathNode *; InsertMethodOp2(mName, varName) ;

InsertClassifierNodeNavLetInitInsideABodyLoop(varName)

InsertLetExpVarInitNavigationCallExpInsideABodyLoop() ; insertNavStartAtIteratorVariable ; InsertNavStart ; InsertPathNode *; InsertClassifierRoleName(varName) xor InsertCollectionRoleName(varName) ;

InsertLetVarPathInitialisationInsideABodyLoop(varName)

IInsertPathLetInitInsideABodyLoop or InsertAttributeNavLetInitInsideABodyLoop(varName, aName) or InsertMethodNavLetInitInsideABodyLoop(varName, mName) or InsertClassifierNodeNavLetInitInsideABodyLoop(varName) ;

InsertLetExpInitVarBooleanExpressionInsideABodyLoop

InsertLetExpInitVarBooleanExpInsideABodyLoop() ; InsertBooleanExpInsideABodyLoop ;

InsertLetExpInitVarIfExpressionInsideABodyLoop

InsertLetExpInitVarIfExpInsideABodyLoop() ; InsertIfExpInsideABodyLoop ;

InsertLetExpInitVarLetExpressionInsideABodyLoop

InsertLetExpInitVarLetExpInsideABodyLoop() ; InsertLetExpInsideABodyLoop ;

InsertLetExpInitVarInsideABodyLoop(varName)

InsertLetExpInitVarBooleanExpressionInsideABodyLoop or InsertLetExpInitVarIfExpressionInsideABodyLoop or InsertLetExpInitVarLetExpressionInsideABodyLoop or InsertLetExpInitVarPathInitialisationInsideABodyLoop(varName) ;

InsertPathLetInitInsideABodyLoop

InsertLetExpVarInitNavigationCallExpInsideABodyLoop() ; InsertPathInsideABodyLoop ;

InsertLetExpInNavigationInsideABodyLoop

(InsertLetExpInNavigationCallExpInsideABodyLoop() or InsertLetExpInNavigationCallExp2InsideABodyLoop()) ; InsertPathInsideABodyLoop ;

InsertLetExpInBooleanExpressionInsideABodyLoop

(InsertLetExpInBooleanExp() or InsertLetExpInBooleanExp2InsideABodyLoop()) ; InsertBooleanExpInsideABodyLoop ;

InsertLetExpInIfExpressionInsideABodyLoop

(InsertLetExpInIfExpInsideABodyLoop() or InsertLetExpInIfExp2InsideABodyLoop()) ; InsertIfExpInsideABodyLoop ;

InsertLetExpInLetExpressionInsideABodyLoop

(InsertLetExpInLetExpInsideABodyLoop() or InsertLetExpInLetExp2InsideABodyLoop()) ; InsertLetExpInsideABodyLoop ;

InsertLetExpInInsideABodyLoop

InsertLetExpInBooleanExpressionInsideABodyLoop or InsertLetExpInIfExpressionInsideABodyLoop or InsertLetExpInLetExpressionInsideABodyLoop or InsertLetExpInNavigationInsideABodyLoop ;

Die Transformation Unit InsertBodyLoopExpression fügt eine Loop Expression ein. Das kann eine derzuvor beschriebenen Operationen auf Collections sein. Der Body kann ein Navigationsausdruck, einIf-Then-Else Ausdruck, ein Let Ausdruck oder ein boolescher Ausdruck sein. Je nachdem, was füreine VOCLExp der Body ist, müssen danach andere Transformation Units, die den Body mit einemkorrekten Ausdruck füllen, angewendet werden.


InsertAnyLoop

(InsertAnyExpWithNavigationBody(in) ; InsertPathInsideABodyLoop ; ) xor (InsertAnyExpWithIfBody(in) ; InsertIfExpInsideABodyLoop ; ) xor (InsertAnyExpWithLetBody(in, vn) ; InsertLetExpInsideABodyLoop(vn) ; ) xor (InsertAnyExpWithBooleanExpBody(in) ; InsertBooleanExpInsideABodyLoop ; ) ;

InsertSelectionLoop

(InsertSelectionExpWithNavigationBody1(n, in) xor InsertSelectionExpWithNavigationBody2(n), in, xor InsertSelectionExpWithNavigationBody3(n, in) ; InsertPathInsideABodyLoop ; ) xor

(InsertSelectionExpWithIfBody(n, in) ; InsertIfExpInsideABodyLoop ; ) xor (InsertSelectionExpWithLetBody(n, in, vn) ; InsertLetExpInsideABodyLoop(vn) ; ) xor (InsertSelectionExpWithBooleanExpBody(n, in, on) ; InsertBooleanExpInsideABodyLoop ; ) ;

InsertCollectLoop

(InsertCollectExpWithNavigationBody1(in) xor InsertCollectExpWithNavigationBody2(in) xor InsertCollectExpWithNavigationBody3(in) ; InsertPathInsideABodyLoop ; ) xor

(InsertCollectExpWithIfBody(in) ; InsertIfExpInsideABodyLoop ; ) xor (InsertCollectExpWithLetBody(in, vn) ; InsertLetExpInsideABodyLoop(vn) ; ) xor (InsertCollectExpWithBooleanExpBody(in, on) ; InsertBooleanExpInsideABodyLoop ; ) ;

InsertSortedByLoop

(InsertSortedByExpWithNavigationBody(in) ; InsertPathInsideABodyLoop; ) xor (InsertSortedByExpWithIfBody(in) ; InsertIfExpInsideABodyLoop ; ) xor (InsertSortedByExpWithLetBody(in, vn) ; InsertLetExpInsideABodyLoop(vn) ; ) xor (InsertSortedByExpWithBooleanExpBody(in, on) ; InsertBooleanExpInsideABodyLoop ; ) ;

InsertBoolLoop

((InsertBoolLoopWithNavigationBody(n, in) or InsertBoolLoopWithNavigationBody_2(n, in) ; InsertPathInsideABodyLoop ; ) xor ((InsertBoolLoopWithIfBody(n, in) or InsertBoolLoopWithIfBody_2(n, in)) ; InsertIfExpInsideABodyLoop ; ) xor ((InsertBoolLoopWithLetBody(n, in, vn) or InsertBoolLoopWithLetBody_2(n, in,vn)) ; InsertLetExpInsideABodyLoop(vn) ; ) xor ((InsertBoolLoopWithBooleanExpBody(n, in, on) or InsertBoolLoopWithBooleanExpBody_2(n, in, on)) ; InsertBooleanExpInsideABodyLoop ; ) ;

InsertBodyLoopExpression

InsertBoolLoop xor InsertAnyLoop xor InsertSortedByLoop xor InsertCollectLoop xor InsertSelectionLoop xor InsertForallLoop xor InsertSumLoop ;

InsertForallLoop

((InsertForallLoopWithNavigationBody(i1, i2) or InsertForallLoopWithNavigationBody_2(i1, i2) ; InsertPathInsideABodyLoop ; ) xor ((InsertForallLoopWithIfBody(i1, i2) or InsertForallLoopWithIfBody_2(i1, i2)) ; InsertIfExpInsideABodyLoop ; ) xor ((InsertForallLoopWithLetBody(i1, i2, vn) or InsertForallLoopWithLetBody_2(i1, i2, vn)) ; InsertLetExpInsideABodyLoop(vn) ; ) xor ((InsertForallLoopWithBooleanExpBody(i1, i2) or InsertForallLoopWithBooleanExpBody_2(i1, i2)); ; InsertBooleanExpInsideABodyLoop ; ) ;

Abb. 5.162: LoopExpression


Shortcuts für Loop Ausdrücke

Die ShortCuts für Loop Ausdrücke sind Kurzschreibweisen für die zuvor beschriebenen Iterator-Operationenauf Collections. Bei diesen wird der Body nicht zusätzlich visualisiert, sondern an der CollectionRo-le dargestellt. Die Ausdrücke des Bodys beziehen sich nur auf einen oder mehrere Attributwerte. Eskann ein Attribut mit einer Konstanten, einer bereits definierten Variablen oder einem komplexeremarithmetischen Ausdruck verglichen werden. Es kann auch mit dem Wert eines anderen Attributs desCollectionelements verglichen werden. Dazu müsste dieses zuvor einer Variablen zugewiesen werdenund dann könnten die beiden Werte durch eine Operation miteinander verglichen werden. Dafür gibtes zwei Regeln (InsertCollectionAttributeOp, InsertCollectionAttributeAssignment). Eine fügt direkteine Operation auf einem Attribut, die andere fügt eine Variablenzuweisung an ein Attribut ein. Nachdieser müsste dann eine Operation auf einem anderen Attribut eingefügt werden (siehe TransformationUnits InsertAnyShortCut, InsertSelectionShortCut, InsertCollectShortCut, InsertBoolResultShortCut).

Die Regel InsertAnyShortCut fügt eine Kurzform einer Any-Operation, die auf eine Collection angewen-det wird, ein. Es darf von der CollectionRole nicht schon weiternavigiert oder eine andere Collection-Operation auf ihr ausgeführt worden sein, was die NAC ausdrückt. Die Ergebnis-Rolle wird auch zueinem Pfadknoten.

L R

InsertAnyShortCut()

1:CollectionRole

1:CollectionRole 2:Classifier

5:base

2:Classifier

5:base

:ShortCutLoopExp name=#any

:ClassifierRole

navSource

resultRole

3:Path 3:Path

4:node

4:node

node

base

1:CollectionRole

navSource

:NavigationRoleExp

NAC

Abb. 5.163: ShortCut für any

Die Regel InsertCollectionAttributeOp fügt an eine CollectionRole mit einer LoopExp-Kurzform eineOperation auf einem Attribut und einen arithmetischen Ausdruck ein. Dazu muss die Basisklasse einentsprechendes Attribut besitzen und es muss eine Vergleichsoperation auf dem Typ des Attributsdefiniert sein. Der arithmetische Ausdruck muss durch die Anwendung weiterer Regeln vervollständigtwerden. Diese Regel kann nach der Anwendung einer der Regeln zum Einfügen eines LoopExpShortCutsangewendet werden.


L R InsertCollectionAttributeOp(opname:OpEnum, attrname:String)

1:CollectionRole 1:ClassifierRole

attrop


argument

:ArithmExp


2:Class

4:Classifier

5:base

6:feature

7:type


2:Class

4:Classifier

5:base

6:feature

7:type

type


11:type


12:parameter


12:parameter

11:type


13:ShortCutLoopExp

14:source

13:ShortCutLoopExp

14:source

correspondingOp

Abb. 5.164: Einfügen einer AttributeOp zu einer Collection

Die Regel InsertCollectionAttributeAssignment fügt an eine CollectionRole mit einer LoopExp-Kurzformeine Variablenzuweisung an einen Attributwert zu. Dazu muss die Basisklasse ein entsprechendes At-tribut besitzen und es darf noch keine Variable mit diesem Namen geben. Nach dieser Regel sollte eineOperation auf einem anderen Attribut eingefügt werden, die die Attributwerte miteinander vergleicht.

InsertCollectionAttributeAssignment(vname:String, attrname:String)

L R

1:CollectionRole 1:CollectionRole

attrass attribute


2:Class

4:Classifier

5:base

6:feature

7:type


2:Class

4:Classifier

5:base

6:feature


variable


type

NAC = R

8:ShortCutLoopExp

9:source

8:ShortCutLoopExp

9:source

14:Path

15:node


12:Constraint

10:nce

13:path

14:Path 15:node


12:Constraint

10:nce

13:path

NAC


12:Constraint

variable

variable

Abb. 5.165: Einfügen eines AttributeAssignments zu einer Collection


Die Regel InsertSumShortCut fügt eine Kurzform einer Sum-Operation, die auf eine Collection ange-wendet wird, ein. Diese Operation summiert die Werte eines Attributs aller Collectionelemente auf undliefert die Summe in einer Variablen als Ergebnis. Die Basisklasse muss ein entsprechendes Attributhaben. Außerdem wird der Attributwert einer Iteratorvariablen vom selben Typ und mit einem ein-deutigen Namen zugewiesen. Die CollectionRole wird zum Ende des Pfades, von ihr kann keine weitereNavigation ausgehen.

L R

InsertSumShortCut(iname:String, attrname:String, vname:String)

1:CollectionRole

1:CollectionRole


2:Class

4:Classifier

5:base

6:feature

7:type


2:Class

4:Classifier

5:base

6:feature

7:type

:ShortCutLoopExp name=#sum

navSource

attrass

variable


:VariableDeclaration varName=iname

9:type

iterator

resultVar


10:Path


12:Constraint

10:Path


12:Constraint

16:exp

16:exp 15:nce

14:node

end 15:nce

variable

NAC

12:Constraint


variable

variable

variable

NAC

12:Constraint

:VariableDeclaration varName=iname

type

1:CollectionRole

navSource

:NavigationRoleExp

NAC

Abb. 5.166: ShortCut für sum

Die Regel InsertSumShortCut_2 macht genau dasselbe wie InsertSumShortCut, nur dass in diesemFall bereits der Typ der NavigationCallExp festgelegt ist und mit dem Typ des Navigationsendesübereinstimmen muss, was auf der linken Regelseite dargestellt ist. Diese Regel wird hier nicht explizitdargestellt, es sind ähnliche Regeln für InsertBoolResultShortCut abgebildet.


Die Regel InsertCountShortCut fügt eine Count-Operation, die auf eine Collection angewendet wird,ein. Diese Operation summiert die Anzahl der Vorkommen eines Objektes mit übergebenem Namen(einer ClassifierRole) in der Collection auf und liefert die Summe in einer Variablen (vom Typ Integer)als Ergebnis. Die CollectionRole wird zum Ende des Pfades, von ihr kann keine weitere Navigationausgehen. Die NavigationCallExp bekommt den Typ des Navigationsendes (und darf vorher nochkeinen haben). Die Variable mit dem Ergebniswert wird in den Constraint eingefügt und sie musseinen eindeutigen Namen haben.Die Regel InsertCountCut_2 macht genau dasselbe wie InsertCountShortCut, nur dass in diesem Fallbereits der Typ der NavigationCallExp festgelegt ist und mit dem Typ des Navigationsendes über-einstimmen muss, was auf der linken Regelseite dargestellt ist. Diese Regel wird hier nicht explizitdargestellt, es sind ähnliche Regeln für InsertBoolResultShortCut abgebildet.

L R

InsertCountShortCut(oname:String, vname:String)

1:CollectionRole

1:CollectionRole

2:Class

4:ClassifierRole

5:base

6:base

2:Class

5:base

:ShortCutLoopExp name=#count

navSource

iterator

resultVar


10:Path


12:Constraint 10:Path


12:Constraint

16:exp

16:exp 15:nce

14:node

end 15:nce

variable

NAC

12:Constraint


variable

9:variable

type

8:Classifier name=#Integer

8:Classifier name=#Integer

4:ClassifierRole

6:base 3:VariableDeclaration varName=oname

7:variable 9:variable

3:VariableDeclaration varName=oname

7:variable

type

type

NAC


:Classifier 1:CollectionRole

navSource

:NavigationRoleExp

NAC

Abb. 5.167: ShortCut für count


Die Regel InsertSelectionShortCut1 fügt eine Kurzform einer Select- oder Reject-Operation, die aufeine Collection angewendet wird, ein. Wieder darf von der CollectionRole nicht schon weiternavigiertoder eine andere Collection-Operation auf ihr ausgeführt worden sein, was die NACs ausdrücken. DieErgebnis-Rolle enthält alle Collectionelemente, die die geforderten Eigenschaften haben bzw. nicht ha-ben und wird auch zu einem Pfadknoten.

Für die ShortCuts von LoopExpressions, die eine Collection liefern, gibt es für jede konkrete Ausprä-gung der Collection (SetRole, BagRole, SequencRole) eine Regel. Es ist hier die Regel, die ein Setliefert, dargestellt.

L R

InsertSelectionShortCut1(loopexpname:LoopEnum)

1:CollectionRole

1:CollectionRole

2:Classifier

5:base

2:Classifier

5:base

:ShortCutLoopExp name=loopexpname

:SetRole

navSource

resultRole

loopexpname= #select v #reject

3:Path

4:node 3:Path

4:node

node

base

1:CollectionRole

navSource

:NavigationRoleExp

NAC

Abb. 5.168: ShortCut für select oder reject

Die Regel InsertCollectShortCut fügt eine Kurzform einer Collect-Operation, die auf eine Collectionangewendet wird, ein. Diese Operation erstellt eine neue CollectionRole, in der alle Attribute (mit demübergebenen Namen) der Elemente gesammelt werden. Die Basisklasse muss ein entsprechendes Attri-but haben. Die Ergebnis-Rolle hat als Basisklasse den Classifier, der den Typ des Attributs beschreibtund wird auch zu einem Pfadknoten.


L R

InsertCollectShortCut1(opname:OpEnum, attrname:String)

1:CollectionRole

1:CollectionRole

attribute


2:Class

4:Classifier

5:base

6:feature

7:type 3:Attribute name=attrname

2:Class

4:Classifier

5:base

6:feature

7:type

:ShortCutLoopExp name=#collect

:SetRole

type

navSource

resultRole

8:Path

9:node

8:Path

9:node

node

1:CollectionRole

navSource

:NavigationRoleExp

NAC

Abb. 5.169: ShortCut für collect

Die Regel InsertSortedByShortCut fügt eine Kurzform einer sortedBy-Operation, die auf eine Collec-tion angewendet wird, ein. Diese Operation sortiert die Elemente der CollectionRole nach dem Werteeines Attributs und liefert eine SequenceRole mit derselben Basisklasse als Ergebnis. Die Basisklassemuss ein entsprechendes Attribut haben. Außerdem wird der Attributwert einer Iteratorvariablen vomselben Typ und mit einem eindeutigen Namen zugewiesen. Die Ergebnis-Rolle wird auch zu einemPfadknoten.


L R

InsertSortedByShortCut(opname:OpEnum, attrname:String)

1:CollectionRole

1:CollectionRole


2:Class

4:Classifier

5:base

6:feature

7:type


2:Class

4:Classifier

5:base

6:feature

7:type

:ShortCutLoopExp name=#sortedBy

:SequenceRole

navSource

resultRole

base

8:Path 9:node

8:Path 9:node

node

1:CollectionRole

navSource

:NavigationRoleExp

NAC

Abb. 5.170: ShortCut für sortedBy

Die Regel InsertBoolResultShortCut1 fügt eine Kurzform einer LoopExpression mit booleschem Ergeb-nis (SCLoopExp mit dem Namen forall, exists, one oder isUnique), die auf eine Collection angewen-det wird, ein. Die Eigenschaften, die alle/genau ein/mindestens ein Elemente der Collection erfüllenmüssen bzw. die für alle Elemente eindeutig sein müssen, beziehen sich nur auf Attributwerte derCollectionelemente. Wieder darf von der CollectionRole nicht schon weiternavigiert oder eine ande-re Collection-Operation auf ihr ausgeführt worden sein, was eine NAC ausdrückt. Die CollectionRolewird zum Ende des Pfades, von ihr kann keine weitere Navigation ausgehen. Die NavigationCallExpbekommt den Typ des Navigationsendes.

Die Regel InsertBoolResultShortCut_2 macht genau dasselbe wie InsertBoolResultShortCut, nur dass indiesem Fall bereits der Typ der NavigationCallExp festgelegt ist und mit dem Typ des Navigationsendesübereinstimmen muss, was auf der linken Regelseite dargestellt ist.


L R

1:CollectionRole

:ShortCutLoopExp name=#loopexpname

type

navSource

InsertBoolResultShortCut(loopexpname:LoopEnum)

loopexpname= #forall v #exists v #one v #isUnique


3:Path

2:node 4:NavigationCallExp

5:Classifier 6:base

7:nce

1:CollectionRole

3:Path

end 4:NavigationCallExp

5:Classifier

7:nce

type

NAC

4:NavigationCallExp

:Classifier

type

1:CollectionRole

navSource

:NavigationRoleExp

NAC

Abb. 5.171: ShortCut für forall, exists, one oder isUnique

L R

1:CollectionRole

:ShortCutLoopExp name=#loopexpname

type

navSource

InsertBoolResultShortCut_2(loopexpname:LoopEnum)

loopexpname= #forall v #exists v #one v #isUnique


3:Path

2:node

4:NavigationCallExp

5:Classifier 6:base

7:nce

1:CollectionRole

3:Path

end 4:NavigationCallExp

5:Classifier

7:nce 8:type

8:type

1:CollectionRole

navSource

:NavigationRoleExp

NAC

Abb. 5.172: ShortCut für forall, exists, one oder isUnique

Die Transformation Unit InsertAnyShortCut fügt eine Any-Operation ein. Danach können beliebigviele Variablenzuweisungen an Attributwerte der Collectionelemente durchgeführt werden. Es mussmindestens eine Operation auf einem Attribut eingefügt werden und danach muss der arithmetischeAusdruck, mit dem dieses Attribut verglichen wird, eingefügt werden. Es können mehrere Attributope-rationen eingefügt werden, deshalb müssen alle möglichen arithmetischen Ausdrücke vervollständigtwerden.Die Transformation Units InsertSelectionShortCut und InsertBoolResultShortCut sind analog definiert.Die Transformation Unit InsertShortCutLoopExp beinhaltet das Einfügen einer der Kurzschreibweisenfür einen Loop Ausdruck.


InsertAnyShortCut

InsertAnyShortCut() ; InsertCollectionAttributeAssignment(vn, an1) * ; InsertCollectionAttributeOp(on, an2) + ; AsLongAsPossible InsertArithmExp ;

InsertShortCutLoopExp

InsertAnyShortCut xor InsertSelectionShortCut xor InsertBoolResultShortCut xor InsertCollectShortCut(an) xor InsertSumShortCut xor InsertCountShortCut xor InsertSortedByShortCut(vn, an) ;

InsertSelectionShortCut

((InsertSelectShortCut1(on) xor InsertSelectShortCut2(on) xor InsertSelectShortCut3(on) ) ; InsertCollectionAttributeAssignment(vn, an1) * ; InsertCollectionAttributeOp(on, an2) + ; AsLongAsPossible InsertArithmExp ;

InsertBoolResultShortCut

InsertBoolResultShortCut(ln) or InsertBoolResultShortCut_2(ln) ; InsertCollectionAttributeAssignment(vn, an1) * ; InsertCollectionAttributeOp(on, an2) + ; AsLongAsPossible InsertArithmExp ;

InsertCollectShortCut

InsertCollectShortCut1(on, an) xor InsertCollectShortCut2(on, an) xor InsertCollectShortCut3(on, an) ;

InsertSumShortCut

InsertSumShortCut(in, an, vn) or InsertSumShortCut_2(in, an, vn) ;

InsertCountShortCut

InsertCountShortCut(on, vn) or InsertCountShortCut_2(on, vn) ;

Die Transformation Unit InsertBoolLoopNav beinhaltet das Einfügen einer Navigation zu einem LoopAusdruck, der ein boolesches Resultat liefert und somit einen korrekten VOCL Navigationsausdruckbeschreibt. Die Navigation beginnt wie bereits beschrieben, dann können beliebig viele Pfadknoteneingefügt werden und als letztes wird ein Loop Ausdruck mit einem booleschen Ergebnis eingefügt.Das kann durch drei Regeln geschehen. InsertBoolResultShortCut fügt eine Kurzform ein, InsertBool-ResultLoopExp einen normalen Iterationsausdruck mit einem Body und einem Iterator und InsertFo-rallLoopExp eine forall-Operation mit zwei Iteratoren.


InsertBoolLoopNav

InsertPathNode *; InsertBoolResultShortCut xor InsertBoolLoop xor InsertForallLoop ;

InsertBoolLoopNavigation

InsertPathStart ; InsertBoolLoopNav ;

Die Transformation Unit InsertConstraintBody fügt den Body eines Constraints ein. Das kann einNavigationsausdruck (die Regel InsertNavigationCallExp gefolgt von der Transformation Unit Insert-Path), ein If-Then-Else Ausdruck (Transformation Unit InsertIfExpression), ein boolescher Ausdruck(Transformation Unit InsertBooleanExpression) oder ein Let Ausdruck (Transformation Unit Insert-LetExpression) sein.

InsertConstraintBody

(InsertNavigationCallExp() ; InsertPath ; ) or InsertBooleanExpression or InsertIfExpression or I nsertLetExpression ;

Die Transformation Unit InsertConstraint fügt einen Constraint ein. Dieser besteht aus zwei Teilen,dem Kontext und dem Body, die mit den Transformation Units DefineContext und InsertConstraint-Body eingefügt werden. Diese fügen Invarianten, Vor- oder Nachbedingungen ein. Um einen definition-Constraint einzufügen, muss die Transformation Unit InsertDefinitionConstraint angewendet werden.

InsertConstraint

(DefineContext ; InsertConstraintBody ; ) or InsertDefinitionConstraint ;

Kapitel 6

Vergleich

In diesem Kapitel wird ein kurzer Vergleich der beiden verwendeten Ansätze zur Definition der abstrak-ten Syntax der VOCL durchgeführt. Die Sprachdefinition mit MOF besteht aus dem Metamodell mitden Kardinalitätsconstraints und den OCL Constraints, die das Metamodell einschränken. D.h. durchdie Constraints werden die Anforderungen an die Sprache zu diesem Metamodell genauer beschrieben.Bei der Spezifikation mit Graphtransformation besteht die Sprachdefinition aus dem Typgraphen undden Grammatikregeln. Durch die Anwendung von Regeln werden Sprachelemente aufgebaut, die danndurch weitere Regelanwendungen zu neuen Sprachelementen erweitert werden können. Somit wird dasgenaue Design der Sprache durch die Graphgrammatik beschrieben. Wenn man diese Ansätze so ver-gleicht, kann man erwarten, dass die MOF-Beschreibung mehr erlaubt, als die Beschreibung mit derGraphgrammatik.Der Vergleich wird in zwei Schritten durchgeführt. Zuerst werden Metamodell (ohne Kardinalitäten)und der Typgraph miteinander verglichen, dann die Constraints mit den Regeln.

6.1 Metamodell <-> Typgraph

Bei der Definition mit MOF beschreibt das Metamodell die grundsätzliche Struktur der Sprache. Esenthält alle Klassen und die Assoziationen zwischen diesen, die in dieser Sprache prinzipiell möglichsind. Klassen können voneinander erben, wodurch eine kompaktere Darstellung der Eigenschaften vonKlassen möglich ist.Bei der Graphtransformation werden die Typen der Knoten und Kanten durch den Typgraphen fest-gelegt. Die Knoten beschreiben Elemente der Sprache, die Kanten die Relationen zwischen diesen.Der verwendete Graphtransformationsansatz erlaubt die Vererbung von Knotentypen im Typgraphen.Das Metamodell (ohne Kardinalitäten) und der Typgraph sind sehr ähnlich, die Knoten können auf dieKlassen und die Assoziationen auf die Kanten abgebildet werden. Die Vererbungskonzepte werden dannauch aufeinander abgebildet. Somit gibt es eine Abbildung vom Metamodell in den Typgraphen undumgekehrt. Die Kanten des Typgraphen sind immer gerichtet, während die Assoziationen nur gerichtetsind, wenn die Navigation entlang dieser Assoziation nur in eine Richtung möglich ist. Der Typgraphenthält einen abstrakten Knotentyp (NavigationRoleExp), zu dem es keine entsprechende Klasse imMetamodell gibt. Dieser Knotentyp wurde eingefügt, um die NACs bei einer großen Anzahl von Regelnzu vereinfachen. Dazu wurde ein Kantentyp (navSource) eingefügt, der an dem abstrakten Knoten-typ startet (im Metamodell gibt es dann für jede entsprechende konkrete Klasse eine Assoziation).Außerdem wurden die Kantentypen exp und loopExp. Auch zu diesen gibt es keine korrespondieren-den Assoziationen im Metamodell. Sie waren im Typgraph nötig, um die Variablen und VOCLExpsinnerhalb eines Constraints bzw. innerhalb einer BodyLoopExp zu “speichern“.

219

220 KAPITEL 6. VERGLEICH

6.2 Constraints <-> Regeln

6.2.1 Kardinalitäts-Constraints <-> Regeln

Die Kardinalitäten des MOF Modells beschreiben Constraints, die sich auf die Anzahl der durch eineAssoziation miteinander in Beziehung stehenden Klasseninstanzen beziehen. Diese lassen sich in denRegeln wiederfinden. Im folgenden werden die verschiedenen Assoziationen mit den Kardinalitätenund die entsprechende Kante im Typgraph dargestellt. Dann folgt eine kurze Beschreibung, wie dieKardinalitäten in den Regeln ausgedrückt werden. Diese werden anhand eines Beispiels aus dem VOCLMetamodell mit den Regeln der VOCL Grammatik verglichen.

• Beliebig viele Instanzen der Klasse K1 können über die Assoziation A1 mit beliebig vielen In-stanzen der Klasse K2 in Beziehung stehen:

K2 K1 A1 0..n 0..n

Es gibt drei Arten von Regeln, eine zum Einfügen von Knoten des Typs K1, eine zum Einfügenvon Knoten des Typs K2 und eine zum Einfügen von Kanten des Typs A1, bei der auf der linkenSeite je ein Knoten des Typs K1 und K2 ist. Alle drei Regeln können beliebig oft ausgeführtwerden.Beispiel aus VOCL Modell:Eine Methode kann beliebig viele Variablen als Argumente haben, diese Variablen können einArgument verschiedener Methoden sein. D.h., sie können unabhängig voneinander eingefügt wer-den und es gibt eine Regel, die die Beziehung zwischen ihnen einfügt.(Regeln zum Einfügen einer VariableDeclaration:InsertConstraintVar , S. 108, InsertStartRoleSelf , S. 110, InsertStartRoleSelf2 , S. 111, InsertAt-tributeAssignment , S. 142, InsertAttributeAssignment_2 , S. 143, InsertAttributeAssignment2 ,S. 143, InsertMethod2 , S. 145, InsertMethod2WithNavType , S. 146, InsertMethod2_2 , S. 146,InsertSizeExp1 , S. 149, InsertSizeExp1_2 , S. 149, InsertSizeExp2 , 150 , InsertIfExpIfLetExp ,S. 164, InsertIfExpThenLetExp , S. 167, InsertIfExpElseLetExp , S. 169, InsertBooleanExpArgLet-Exp , S. 172, InsertLetExp , S. 174, InsertLetExpInitVarLetExp , S. 175, InsertLetExpInLetExp ,S. 179, alle Regeln zum Einfügen von Loop-Ausdrücken mit Iterator ab Seite , S. 187 bis Seite ,S. 194, InsertCollectionAttributeAssignment , S. 210, InsertSumShortCut , S. 211,sie sind alle unabhängig von der Existenz einer Method.Regeln zum Einfügen einer Method:InsertMethod1 , S. 144, InsertMethod1_2 , S. 144, InsertMethod2 , S. 145, InsertMethod2WithNavType, S. 146, InsertMethod2_2 , S. 146, InsertMethod2, InsertMethod2WithNavType, InsertMethod2_2haben zwar eine Variable auf der rechten Seite eingefügt, diese ist aber kein Argument der Me-thode, sondern das Ergebnis.Die Regel zum Einfügen einer Variablen als Argument einer Methode ist: InsertMethodArgVar, S. 138, bei der die VariableDeclaration bereits auf der linken Seite der Regel vorhanden seinmuss. Die NAC bedeutet, dass es zu jedem Parameter ein Argument gibt, aber eine Method kannmehrere Variablen als Argumente (zu verschiedenen Parametern) haben.

• Jede Instanz der Klasse K2 steht mit genau einer Instanz der Klasse K1 über A1 in Beziehung,während eine Instanz der Klasse K1 mit beliebig vielen Instanzen der Klasse K2 in Relationstehen kann.

K2 K1 A1 1 0..n

Es gibt Regeln zum Einfügen von Knoten des Typs K1, die beliebig oft angewendet werden kön-

6.2. CONSTRAINTS <-> REGELN 221

nen. Es gibt Regeln, die einen Knoten des Typs K2 und eine Kante des Typs A1 einfügen, wennein Knoten des Typs K1 vorhanden ist.Beispiel aus dem VOCL Modell:Jede NodeRole hat genau einen Basis-Classifier, den sie instanziiert, es gibt keine NodeRole,dessen Elemente keinen BasisClassifier haben. Es kann Klassen geben, zu denen es keine oderviele NodeRoles gibt. D.h., um eine NodeRole einfügen zu können, muss es einen Classifier aufder linken Seite der Regel geben. Das ist bei allen Regeln zum Einfügen einer Rolle der Fall,dieser Classifier muss im UML Modell definiert worden sein, damit es Rollen dazu geben kann.Die Classifier können beliebig oft (unabhängig von NodeRoles) eingefügt werden.Regeln zum Einfügen einer NodeRole: InsertStartRoleSelf, S. 110, InsertStartRoleSelf2, S. 111,InsertStartRoleCVar, S. 110, InsertAllInstancesExp, S. 111, die Regeln zum Einfügen einer As-sociation : InsertStartAssociation etc. S. 112-118, Regeln zum Einfügen einer Associationsklasse:InsertStartAssociationClassToCR, S. 119,InsertAssociation, S. 120, InsertAssociationClass, S. 121, InsertStartCRTMethod, S. 122, Insert-CRTMethod, S. 122, die Regeln zum Einfügen von Mengenoperationen auf Collections, S. 182-186,InsertAnyExpWithNavigationBody, S. 187, InsertAnyExpWithBooleanExpBody, S. 189, InsertA-nyExpWithIfBody, S. 188, InsertAnyExpWithLetBody, S. 189, die entsprechenden Regeln für Se-lect, Reject, Collect, SortedBy (auf den Seiten 190- 192, sowie die Regeln zum Einfügen derShortCuts dieser Operationen (S. 209-215). Bei all diesen Regeln ist ein Classifier auf der linkenSeite vorhanden. Die Regeln zum Einfügen eines Classifiers sind : InsertClass und InsertDataTypeaus dem Abschnitt 5.1.2.

• Jede Instanz der Klasse K1 steht mit genau einer Instanz der Klasse K2 durch A1 in Relation.

K2 K1 A1 1 1

Es gibt Regeln, die einen Knoten des Typs K1, einen Knoten des Typs K2 und eine Kante desTyps A1 zwischen diesen einfügen.Beispiel aus dem VOCL Modell:Jede Vergleichsoperation (CompOperation) steht mit genau einem arithmetischen Ausdruck(ArithmExp) in Relation. Die Regeln zum Einfügen einer Vergleichsoperation (AttributeOp, Me-thodOp oder Condition) fügen immer auch eine ArithmExp mit ein:InsertAttributeOp , S. 135, InsertAttributeOp_2 , S. 136, InsertMethodOp , S. 137, InsertMetho-dOp_2 , S. 137, InsertCondition , S. 151.Es gibt keine anderen Regeln zum Einfügen einer Vergleichsoperation oder eines arithmetischenAusdrucks.

• Eine Instanz der Klasse K2 steht durch A1 mit maximal einer Instanz der Klasse K1 in Beziehung,eine Instanz der Klasse K1 kann mit beliebig vielen Instanzen der Klasse K2 über A1 in Beziehungstehen:

K2 K1 A1 0..1 0..n

Es gibt drei Arten von Regeln, die Regeln zum Einfügen von Knoten des Typs K1 oder K2 könnenunabhängig voneinander beliebig oft angewendet werden, die Regeln zum Einfügen von Kantendes Typs A1 können nur angewendet werden, wenn es noch keine solche Kante zum Knoten desTyps K1 gibt, was durch eine NAC ausgedrückt wird.

Beispiel aus dem VOCL Modell:Eine ArithmExp referenziert entweder eine Variable, eine Konstante oder eine Operation, d.h.,


sie steht mit maximal einer VariableDeclaration in Relation. Variablen können aber mit vielenverschiedenen Regeln eingefügt werden, die unabhängig von der ArithmExp sind. (Regeln zumEinfügen einer VariableDeclaration:InsertConstraintVar , S. 108, InsertStartRoleSelf , S. 110, InsertStartRoleSelf2 , S. 111, InsertAt-tributeAssignment , S. 142, InsertAttributeAssignment_2 , S. 143, InsertAttributeAssignment2 ,S. 143, InsertMethod2 , S. 145, InsertMethod2WithNavType , S. 146, InsertMethod2_2 , S. 146,InsertSizeExp1 , S. 149, InsertSizeExp1_2 , S. 149, InsertSizeExp2 , 150 , InsertIfExpIfLetExp ,S. 164, InsertIfExpThenLetExp , S. 167, InsertIfExpElseLetExp , S. 169, InsertBooleanExpArgLet-Exp , S. 172, InsertLetExp , S. 174, InsertLetExpInitVarLetExp , S. 175, InsertLetExpInLetExp ,S. 179, alle Regeln zum Einfügen von Loop-Ausdrücken mit Iterator ab Seite , S. 187 bis Seite ,S. 194, InsertCollectionAttributeAssignment , S. 210, InsertSumShortCut , S. 211,sie sind alle unabhängig von der Existenz einer ArithmExp.Die Regeln zum Einfügen einer ArithmExp sind unabhängig von der Variablen:InsertAttributeOp , S. 135, InsertAttributeOp_2 , S. 136, InsertMethodOp , S. 137, InsertMetho-dOp_2 , S. 137, InsertCondition , S. 151.

Die Regel zum Einfügen einer Beziehung zwischen der ArithmExp und der VariableDeclarationhat eine NAC, die definiert, dass es noch keine solche Beziehung gibt. InsertArithmExpArgVa-riable, , S. 139

• Eine Instanz der Klasse K2 steht durch A1 mit maximal einer Instanz der Klasse K1 in Beziehung,eine Instanz der Klasse K1 steht mit genau einer Instanz der Klasse K2 über A1 in Beziehung:

K2 K1 A1 0..1 1

Es gibt zwei Arten von Regeln, die Regeln zum Einfügen von Knoten des Typs K2 können be-liebig oft angewendet werden, die Regeln zum Einfügen eines Knotens vom Typ K1 und einerKante des Typs A1 können nur angewendet werden, wenn es einen Knoten des Typs K2 gibt undzu diesem Knoten noch keine solche Kante existiert (NAC).Beispiel aus dem VOCL Modell:Jede CRTMethod wird auf genau eine Anfangs-Rolle angewendet, und auf eine Rolle darf ma-ximal eine CRTMethod angewandt werden. D.h., die CRTMethod kann erst eingefügt werden,wenn bereits eine NodeRole existiert, die NodeRoles können aber unabhängig von der Existenzeiner CRTMethod eingefügt werden. Außerdem muss beim Einfügen einer CRTMethod über-prüft werden, dass nicht schon eine andere CRTMethod an dieser NodeRole hängt, was durcheine NAC sichergestellt wird. NodeRoles können mit verschiedenen Regeln eingefügt werden. Alldiese Regeln fügen die NodeRole unabhängig von einer CRTMethod ein (auf der linken Seite undder NAC kommt keine CRTMethod vor). Auf der linken Seite der Regeln zum Einfügen einerCRTMethod ist eine NodeRole. Diese stellt den source-Knoten der CRTMethod dar und diesepositive Anwendungsbedingung drückt die Kardinalität 1 auf der Seite der NodeRole aus. Dassdiese Rolle nicht bereits der source-Knoten einer anderen CRTMethod sein darf, wird durch dieNAC festgelegt.

Regeln zum Einfügen einer NodeRole: InsertStartRoleSelf, S. 110, InsertStartRoleSelf2, S. 111,InsertStartRoleCVar, S. 110, InsertAllInstancesExp, S. 111, die Regeln zum Einfügen einer As-sociation : InsertStartAssociation etc. S. 112-118, Regeln zum Einfügen einer Associationsklasse:InsertStartAssociationClassToCR, S. 119,InsertAssociation, S. 120, InsertAssociationClass, S. 121, InsertStartCRTMethod, S. 122, Insert-CRTMethod, S. 122, die Regeln zum Einfügen von Mengenoperationen auf Collections, S. 182-186,InsertAnyExpWithNavigationBody, S. 187, InsertAnyExpWithBooleanExpBody, S. 189, InsertA-nyExpWithIfBody, S. 188, InsertAnyExpWithLetBody, S. 189, die entsprechenden Regeln für Se-lect, Reject, Collect, SortedBy (auf den Seiten 190- 192, sowie die Regeln zum Einfügen derShortCuts dieser Operationen (S. 209-215). All diese Regeln fügen die NodeRole unabhängig von


einer CRTMethod ein (auf der linken Seite und der NAC kommt keine CRTMethod vor).Die Regeln zum Einfügen einer CRTMethod sind: InsertStartCRTMethod, S. 122, InsertCRT-Method, S. 122, InsertPathEndCRTMethod, S. 128, bei diesen Regeln ist auf der linken Seite dieNodeRole, die die source-Rolle der CRTMethod darstellt und zum Einfügen einer CRTMethoderforderlich ist. Eine NAC stellt jeweils sicher, dass es noch keine CRTMethod an der NodeRolegibt.

• Eine Instanz der Klasse K2 steht durch A1 mit mindestens einer Instanz der Klasse K1 inBeziehung, eine Instanz der Klasse K1 steht mit genau einer Instanz der Klasse K2 über A1 inBeziehung:

K2 K1 A1 1..n 1

Es gibt Regeln zum Einfügen eines Knotens vom Typ K1, eines Knotens vom Typ K2 und einerKante vom Typ A1 zwischen diesen Knoten. Und es gibt Regeln, die zu einem existierendenKnoten des Typs K2 einen Knoten des Typs K1 und eine Kante des Typs A1 zwischen diesenKnoten einfügen.Beispiel aus dem VOCL Modell:Jeder NavigationCallExp beinhaltet mindestens einen Path und jeder Path ist in genau einerNavigationCallExp. Es gibt verschiedene Regeln zum Einfügen einer NavigationCallExp (alsConstraint-Body oder als Argument einer Booleschen Operation, als Initialisierung einer LetVa-riablen oder als Teil eines If-Then-Else Ausdrucks). Hierbei ist es allerdings nicht so, dass beidiesen Regeln schon der Path mit eingefügt wird. Aber diese Regeln werden nur in Transfor-mation Units (InsertEquivalentPathes, S. 134, InsertAttributeNavigation, S. 147, InsertMethod-Navigation, S. 147, InsertSimpleCollOpNavigation, S. 150, InsertConditionNavigation, S. 152,InsertStateNavigation, S. 155, InsertIfExpIfNavigation, S. 170, InsertIfExpThenNavigation, S.170, InsertIfExpElseNavigation, S. 170, InsertBooleanExpArgNavigation(ord), S. 173, InsertLet-ExpVarPathInitialisation, S. 181, InsertLoopExpression, S. 208 ) verwendet, die danach eine derRegeln zum Einfügen eines Paths in diese NavigationCallExp ausführen. Somit wird durch dieTransformation Units sichergestellt, dass nie eine NavigationCallExp ohne Pfade existiert unddass die Pfade nur in einen bereits existierenden Navigationsausdruck eingefügt werden.

• Eine Instanz der Klasse K2 steht durch A1 mit mindestens einer Instanz der Klasse K1 inBeziehung, eine Instanz der Klasse K1 kann mit maximal einer Instanz der Klasse K2 über A1in Beziehung stehen:

K2 K1 A1 1..n 0..1

Es gibt zwei Arten von Regeln, die Regeln zum Einfügen von Knoten des Typs K1 können be-liebig oft angewendet werden, die Regeln zum Einfügen eines Knotens vom Typ K2 und einerKante des Typs A1 können nur angewendet werden, wenn es einen Knoten des Typs K1 gibt.

Beispiel aus dem VOCL Modell:Ein Pfad hat maximal eine AllInstancesExp als Pfadanfang. Eine AllInstancesExp ist immer derAnfang mindestens eines Pfades, kann jedoch der Anfang verschiedener Pfade sein. Die Regel zumEinfügen einer AllInstancesExp (InsertAllInstancesExp, S. 111, Abb. 5.13) fügt den Pfad und dieAllInstancesExp gleichzeitig ein. Später (durch Transformation Units zum Einfügen von Pfaden(InsertEquivalentPathes, S. 134, InsertAttributeNavigation, S. 147, InsertMethodNavigation, S.147, InsertSimpleCollOpNavigation, S. 150, InsertConditionNavigation, S. 152, InsertStateNavi-gation, S. 155, InsertIfExpIfNavigation, S. 170, InsertIfExpThenNavigation, S. 170, InsertIfEx-


pElseNavigation, S. 170, InsertBooleanExpArgNavigation(ord), S. 173, InsertLetExpVarPathIni-tialisation, S. 181, InsertLoopExpression, S. 208 ) kann dann durch die Anwendung der RegelInsertNewPath, 111 Abb. 5.15, ein weiterer Pfad, der an der AllInstancesExp beginnt, eingefügtwerden. Pfade können mit den Regeln InsertStartRoleSelf, S. 110, Abb. 5.11, InsertStartRo-leCVar, S. 110, Abb. 5.12, InsertStartRoleSelf2, S. 111, Abb. 5.14 unabhängig von der Existenzeiner AllInstancesExp eingefügt werden.

6.2.2 sonstige Constraints <-> Regeln

In diesem Abschnitt werden alle anderen Constraints des VOCL Metamodells mit den Graphgram-matikregeln der VOCL verglichen. Dazu werden die Regeln bzw. TransformationUnits der Grammatikgenauer betrachtet und dann jeweils die Constraints, die dieselben Bedingungen ausdrücken beschrie-ben.

Definition des Kontextes

Die Transformation Unit DefineContext, S. 109, fügt einen Constraint und seinen Context-Teil ein. DieRegel CreateConstraint1, S. 108 Abb. 5.5, fügt einen Constraint, der sich auf einen Classifier beziehtein, die Regel CreateConstraint2, S. 108 Abb. 5.6, fügt einen Constraint, der sich auf eine Operationbezieht ein. In der linken Seite der Regel wird jeweils überprüft, dass der Constraint von der richtigenArt ist (pre oder post für Operationen, inv oder def für Classifier). Nur eine der beiden Regeln kannangewendet werden. Mit der Regel InsertConstraintName, S. 108 Abb. 5.7, kann dem Constraint einName gegeben werden, die Regel InsertConstraintVar, S. 108 Abb. 5.8, fügt eine Constraintvariableein. Die entsprechenden OCL Constraints sind:

Constraint 1.: drückt aus, dass sich der Constraint entweder auf eine Klasse oder eine OperationbeziehtConstraint 2.: drückt aus, dass sich pre oder post auf Operationen, inv oder def auf Classifier bezie-henConstraint3.: beschreibt die NAC von InsertConstraintVarConstraint 4.: Typ der Constraintvariablen und constrainedClassifer sind gleichConstraint 5.: spezifiziert, dass ein Constraint, der sich auf eine Operation bezieht, eine ClassifierRolemit dem Namen self hat. Dies wird in den obigen Regeln nicht explizit beschrieben, wird aber durchdie Regel InsertStartRoleSelf2 festgelegt. Die beschreibt, dass jede NavigationCallExp innerhalb einespre oder post Constraints bei self startet, und irgendwann hat jeder Constraint eine NavigationCallExpsonst enthält er gar keine Rollen.

Navigationen

Ein Navigationsausdruck ist eine spezielle VOCLExp, die Pfadausdrücke enthält. Es gibt verschiedeneArten von Pfadausdrücken. Ein Pfadausdruck kann aussagen, dass die Navigation entlang verschie-dener Pfade zu derselben Endrolle führt (solche Pfadausdrücke werden mit der TransformationUnitInsertEquivalentPathes, S. 134). Oder es kann zu einem Methodenaufruf navigiert werden und danneine Aussage über dessen Resultat gemacht werden (TransformationUnit InsertMethodNavigation, S.147), analog kann zu einem Attribut navigiert werden und dann eine Aussage über dessen Wert ge-macht werden (TransformationUnit InsertAttributeNavigation, S. 147). Oder es kann zu verschiedenenWerten navigiert werden, um sie Variablen zuzuweisen, über die dann im Bedingungsteil Aussagengemacht werden (TransformationUnit InsertConditionNavigation, S. 152). Es kann auch zu einer Col-lection navigiert werden und dann Operationen auf diese angewendet werden (TransformationUnitInsertSimpleCollOpNavigation, S. 150, und TransformationUnit InsertBoolLoopNavigation, S. 218). Eskann zu einer ClassifierRole navigiert werden und dann beschrieben werden, in welchem Zustand siesich befindet (TransformationUnit InsertStateNavigation, S. 155). Für diese TransformationUnits wur-den Hilfs-TransformationUnits definiert, die in mehreren anderen TransformationUnits vorkommen.


Die Transformation Unit InsertPathStart

InsertPathStart, S. 134, fügt eine Startrolle ein, wofür es vier Möglichkeiten gibt, die in der Transfor-mationUnit InsertStartRole, S. 133, als Alternativen definiert sind.

Die Regel InsertStartRoleSelf, S. 110 Abb. 5.11, fügt die Startrolle eines Navigationsausdrucks ein,wenn dieser noch keine Startrolle hat (NAC). Dieser existiert bereits innerhalb eines Constraints, dereinen Classifier als Kontext definiert hat. Die Startrolle hat den Namen self und den Typ des Kontex-tes. Die Variable mit dem Namen self hat denselben Typ wie die ClassifierRole. Die entsprechendenOCL Constraints sind:Path 4.: Die Navigation geht nur in eine RichtungRoleNode 1.: ClassifierRole und Variable haben denselben TypNavigationCallExp 3.: Der Pfad beginnt bei self oder der Constraintvariablen oder AllInstances

Die Regel InsertStartRoleSelf2, S. 111 Abb. 5.14, fügt eine NavigationCallExp mit einem Pfad ein, derbei einer ClassifierRole mit dem Namen self und dem Typ der Klasse, die die Operation des Cons-traints definiert, startet. Die Variable mit dem Namen self hat denselben Typ wie die ClassifierRoleund die NAC drückt aus, dass die NavigationCallExp noch keinen Pfad enthält. Die entsprechendenOCL Constraints sind:Path 4.: Die Navigation geht nur in eine RichtungRoleNode 1.: ClassifierRole und Variable haben denselben TypNavigationCallExp 3.: Der Pfad beginnt bei self oder der Constraintvariablen oder AllInstancesConstraint 5.: Wenn sich ein Constraint auf eine Operation bezieht, muss es eine Startrolle self geben.

Die Regel InsertStartRoleCVar, S. 110 Abb. 5.12, fügt die Startrolle eines Navigationsausdrucks ein,wenn dieser noch keine Startrolle hat (NAC). Dieser existiert bereits innerhalb eines Constraints, dereinen Classifier als Kontext und eine Constraintvariable definiert hat. Die Startrolle hat den Namender Constraintvariablen und den Typ des Kontextes. Die Variable mit dem Namen self hat denselbenTyp wie die ClassifierRole. Die entsprechenden OCL Constraints:Path 4.: Die Navigation geht nur in eine RichtungRoleNode 1.: ClassifierRole und Variable haben denselben TypNavigationCallExp 3.: Der Pfad beginnt bei self oder der Constraintvariablen oder AllInstances

Die Regel InsertAllInstancesExp, S. 111 Abb. 5.13, fügt die Startrolle eines Navigationsausdrucks ein,wenn dieser noch keine Startrolle hat (NAC). Dieser existiert bereits innerhalb eines Constraints, dereinen Classifier als Kontext definiert hat. Die Startrolle ist eine Menge (SetRole), die die Menge allerInstanzen der Kontextklasse enthält, hat keinen Namen und den Typ des Kontextes. Die entsprechen-den OCL Constraits sind:Path 4.: Die Navigation geht nur in eine RichtungPath 3.: Die SetRole ist der Startknoten des PfadesRoleNode 1.: ClassifierRole und Variable haben denselben TypNavigationCallExp 3.: Der Pfad beginnt bei self oder der Constraintvariablen oder AllInstances

Nach dem Einfügen einer Startrolle wird eine Navigation zu einer anderen Rolle eingefügt. Die Transfor-mation Units hierfür sind InsertStartAssociation, InsertStartAssociationClass, InsertStartCRTMethododer InsertNavLoop.

Die Transformation Unit InsertStartAssociation

Die Regel InsertStartAssociation1, S. 133, fügt als Navigationsstart (an die Startrolle eines Pfades)eine AssociationRole ein. Dazu muss es bereits eine ClassifierRole und eine enstprechende Association(aus dem UML Diagramm) mit einem Assoziationsende vom Typ der ClassifierRole und einem As-soziationsende mit dem übergebenene Rollennamen geben. Außerdem müssen die Kardinalitäten und


andere Eigenschaften der Assoziation überprüft werden. Dann kann die AssociationRole, eine neueClassifierRole vom Typ des anderen Associationsendes und zwei AssociationEndRoles eingefügt wer-den. Die AssociationRole und die neue ClassifierRole werden auch zu Knoten des Pfades. Die Startrollehat keinen Rollennamen, die Zielrolle muss einen haben.Die folgenden sechs Regeln InsertStartAssociationCRSet etc. auf den Seiten ??-118 sind ähnlich, dieEigenschaften der entsprechenden Assoziation und des einzufügenden RoleNodes sind unterschiedlich.Die entsprechenden OCL Constraints sind:Path 4.: Die Assoziationen haben eine RichtungPath 1.: Die mit der Association eingefügten Rollen sind auch PfadknotenAssociationRole 1.: Die Startrolle hat keinen RollennamenAssociationRole 2.: Die Endrolle muss einen Namen habenAssociationRole 3.: eine entsprechende Assoziation existiert

Die Transformation Unit InsertStartAssociationClass

Die Regel InsertStartAssociationClass1, S. 119 Abb. 5.23, fügt als Start einer Navigation (an die Star-trolle eines Pfades) eine AssociationClassRole ein. Dazu muss es bereits eine ClassifierRole und eineenstprechende AssociationClass (aus dem UML Diagramm) mit einem Assoziationsende vom Typ derClassifierRole, einem Assoziationsende und einer Assoziationsklasse mit dem übergebenenen Namengeben. Außerdem müssen die Kardinalitäten und andere Eigenschaften der Assoziationsklasse über-prüft werden. Dann kann die AssociationClassRole, eine neue ClassifierRole vom Typ des anderenAssociationsendes und eine ClassifierRole vom Typ der Assoziationsklasse sowie zwei AssociationEn-dRoles eingefügt werden. Die Startrolle hat keinen Rollennamen, die Zielrolle kann einen haben.Die AssociationClassRole und die neuen ClassifierRoles werden auch zu Knoten des Pfades. Die ent-sprechenden OCL Constraints sind:Path 4.: Die Assoziationen haben eine RichtungPath 1.: Die mit der AssociationClass eingefügten Rollen sind auch PfadknotenAssociationClassRole 1.: Die Startrolle hat keinen Rollennamen, die Endrolle kann einen NamenhabenAssociationClassRole 2.: eine entsprechende AssociationClass existiert

Die Transformation Unit InsertStartCRTMethod

Die Regel InsertStartCRTMethod, S. 122 Abb. 5.26, fügt eine Methode, die auf die Startrolle angewen-det wird und eine neue Rolle liefert, in den Pfad, in dem die Startrolle ist, ein. Eine entsprechendeOperation muss im UML Diagramm definiert worden sein, die Navigation geht von der Startrolle zurneuen Rolle. Danach werden die Argumente der CRTMethod mit den Regeln InsertCRTMethodArgL,S. 123 Abb. 5.29, und InsertCRTMethodArgV, S. 123 Abb. 5.28, eingefügt, bei denen die korrespondie-rende Operation einen entsprechenden Parameter mit entsprechendem Typ und Ordnung haben muss.Außerdem darf zum Parameter der entsprechenden Ordnung nicht schon ein Argument eingefügt wor-den sein (NAC). Die entsprechenden OCL Constraints sind:Path 4.: Die Navigationen haben eine RichtungPath 2.: Die mit der CRTMethod eingefügte Rolle ist auch PfadknotenRoleNode 8.: Die Basisklasse des RoleNodes hat eine entsprechende OperationCRTMethod 1. + 2.: Die entsprechende Operation ist auf denselben Argument- und Ergebnistypendefiniert, zu jedem Parameter gibt es ein Argument

Die Transformation Unit InsertNavLoop

Diese Transformation Unit, S. 133, enthält nur die Unter-Units zum Einfügen von verschiedenen LoopAusdrücken, die jeweils über eine Collection iterieren und eine NodeRole als Ergebnis liefern. Daskönnen die normalen Ausdrücke mit der Visualisierung eines Bodys oder die Kurzformen von LoopAusdrücken sein.


Die normalen Loop Ausdrücke haben einen Body, der in einem eigenen Rahmen visualisiert wird undeine der konkreten Ausprägungen einer VOCLExp (NavigationCallExp, IfExp, BooleanExp, LetExp)sein kann. Entsprechend gibt es für jeden Loop Ausdruck vier verschiedene Regeln. Die Ergebnis-se eines Loop Ausdrucks hängen von seinem Namen, also der ausgeführten Operation auf der Col-lectionRole, ab und können ein boolescher Wert (Regeln InsertBoolLoopWithNavigationBody, S. 192Abb. 5.135, InsertBoolLoopWithIfBody, InsertBoolLoopWithLetBody, InsertBoolLoopWithBooleanBo-dy, InsertForallLoopWithNavigationBody, InsertForallLoopWithIfBody, InsertForallLoopWithLetBody,InsertForallLoopWithBooleanBody und die Regeln für Shortcuts InsertBoolResultShortCut, S. 216 Abb.5.171), eine ClassifierRole oder eine CollectionRole sein. Für die Operationen, die eine CollectionRoleliefern, gibt es jeweils (also für jede konkrete Ausprägung des Bodys) drei Regeln (eine für SetRole, einefür BagRole und eine für SequenceRole). Die Regeln fügen an eine CollectionRole, die das bisherige En-de eines Pfades ist, eine LoopExp mit einem Namen und einem Iterator mit dem übergebenen Namenein. Der Iterator hat den Typ der Elemente der CollectionRole, die Variable darf im Constraint nochnicht definiert worden sein. Der Body muss dann jeweils durch die Anwendung von TransformationUnits zu einem korrekten Ausdruck vervollständigt werden. Die Ergebnisrolle gehört zum gleichen Pfadwie die Startrolle, die Navigation geht von der Startrolle weg. Die entsprechenden OCL Constraints fürdie Transformation Units InsertAnyLoop, InsertSelectionLoop, InsertCollectLoop, InsertSortedByLoop,S. 208 sind:LoopExp 1.: eine LoopExp hat genau ein ErgebnisLoopExp 5.: Die Ergebnisrolle ist auch ein Pfadknoten

Any liefert eine ClassifierRole; SortedBy liefert eine SequenceRole, deren Elemente denselben Typ ha-ben wie die Ausgangs-Collection; Select und Reject liefern CollectionRoles, deren Elemente denselbenTyp haben wie die Ausgangs-Collection; Collect liefert eine CollectionRole. Die entsprechenden OCLConstraints sind:LoopExp 2.: Das Ergebnis einer Any-Operation ist eine ClassifierRoleLoopExp 3.: Das Ergebnis von emphSelect, Reject, SortedBy und Collect ist eine CollectionRoleLoopExp 6.: Die Ergebnis-CollectionRole von select, reject und sortedBy hat Elemente desselben Typwie die der Ausgangs-Collection

Bei der Beschreibung der Transformation Unit InsertBoolLoopNavigation wird das Einfügen eines LoopAusdrucks (der ein boolesches Ergebnis hat) genau beschrieben. Die Regeln sowie die entsprechendenConstraints gelten auch hier, die die sich auf die Navigationspfade bezogen, wurden oben aufgelistet.

Die ShortCuts für Loop Ausdrücke beschreiben Kurzschreibweisen für die Iterator-Operationen aufCollections. Bei diesen wird der Body nicht zusätzlich visualisiert, sondern an der CollectionRole dar-gestellt. Die Ausdrücke des Bodys beziehen sich nur auf einen oder mehrere Attributwerte. Es kann einAttribut mit einer Konstanten, einer bereits definierten Variablen oder einem komplexerem arithmeti-schen Ausdruck verglichen werden. Es kann auch mit dem Wert eines anderen Attributs des jeweiligenCollectionelements verglichen werden. Dazu müsste der Attributwert zuvor einer Variablen zugewie-sen werden und dann könnten die beiden Werte durch eine Operation miteinander verglichen werden.Dafür gibt es zwei Regeln (InsertCollectionAttributeOp, S. 210 Abb. 5.164 und InsertCollectionAttri-buteAssignment, S. 210 Abb. 5.165). Eine fügt direkt eine Operation auf einem Attribut ein, die anderefügt eine Variablenzuweisung an ein Attribut ein. Nach dieser müsste dann eine Operation auf einemanderen Attribut eingefügt werden (siehe Transformation Units InsertAnyShortCut, InsertSelectionS-hortCut, InsertCollectShortCut, InsertBoolResultShortCut auf S. 217).Die entsprechenden OCL Constraints für die Transformation Units InsertAnyShortCut, InsertSelecti-onShortCut, InsertCollectShortCut, InsertSortedByShortCut sind:LoopExp 1.: eine LoopExp hat genau ein ErgebnisLoopExp 5.: Die Ergebnisrolle ist auch ein PfadknotenShortCutLoopExp 2.: Es wird über Attributwerte iteriert


und wie bei den LoopExps mit Body die Typen der Ergebnisse:LoopExp 3.: Das Ergebnis von Select, Reject, SortedBy und Collect ist eine CollectionRoleLoopExp 6.: Die Ergebnis-CollectionRole von select, reject und sortedBy hat Elemente desselben Typwie die der Ausgangs-Collection

Auch für die ShortCuts gibt es bei der Beschreibung der Transformation Unit InsertBoolLoopNav einegenauere Beschreibung. Die Regeln sowie die entsprechenden Constraints gelten analog, die die sichauf die Navigationspfade bezogen, wurden oben aufgelistet.

Die Transformation Unit InsertPathNode

InsertPathNode, S. 134, fügt eine Navigation zu einem weiteren Knoten (eine Rolle) in einen Pfadein. Diese Navigation ist auf verschiedene Arten möglich: Über eine Association, was in der Trans-formationUnit InsertAssociation, S. 133, definiert ist. Diese ist analog zu der TransformationUnitInsertStartAssociation, S. 133, nur dass die Navigation an dem bisherigen Navigationsende des Pfadesund nicht an der Startrolle beginnt, was durch zusätzliche NACs sichergestellt wird. Über eine As-sociationClass, was in der TransformationUnit InsertAssociationClass, S. 133, definiert ist. Diese istanalog zu der TransformationUnit InsertStartAssociationClass, S. 133. Über eine CRTMethod, was inder TransformationUnit InsertCRTMethod, S. 133, definiert ist. Diese ist analog zu der Transforma-tionUnit InsertStartCRTMethod, S. 133. Die entsprechenden OCL Constraints für diese NACs sind:Path 4.: Die Navigationen haben eine RichtungCollectionRole 6.: Auf die CollectionRole wurde noch keine andere Collection-Operation angewendetDie anderen Constraints sind analog zu den vorherigen (Path 1., AssociationRole 1. + 2. + 3.,AssociationClassRole 1. + 2., CRTMethod 1. + 2., RoleNode 8.).

Die Navigation ist auch über eine CollectionOp möglich (TransformationUnit InsertCollectionOp, S.133), die zwei RoleNodes mit Elementen des gleichen Typs durch eine Mengenoperation (Vereinigung,Schnittmenge, Differenz, etc) zu einem neuen Ergebnisknoten verknüpft. An keinem der RoleNodesdarf eine andere Navigation starten oder eine andere Operation auf Collections ausgeführt werden(NACs). Das Ergebnis ist auch ein Pfadknoten. Je nach der Art der RoleNodes (Set, Bag, Sequence)sind verschiedene Operationen möglich. Die entsprechenden OCL Constraints sind:Path 4.: Die Navigationen haben eine RichtungMathSetOp 2.: Das Ergebnis gehört zum PfadMathSetOp1.: Die Argument- und Ergebnistypen sind für jede Operation festgelegtCollectionRole 6.: Auf die CollectionRole wurde noch keine andere Collection-Operation angewendet

Außerdem kann über eine LoopExp navigiert werden, was bereits in der Transformation Unit Insert-NavLoop beschrieben wurde.

Es kann auch über einen Message-Operator zu einer Sequenz gesendeter Messages navigiert werden,was in der Transfomation Unit InsertMessageNode, S. 133, definiert ist. In dieser Transformation Unitwird durch den Message-Operator ein neuer Pfadknoten, der die Sequenz aller Messages mit einemübergebenen Namen, die zu einem RoleNode gesendet wurden, darstellt. Von dieser Sequenz aus kannweiternavigiert werden (ähnlich wie beim Aufruf einer Methode mit komplexem Ergebnistyp). Es wirdzuerst eine der Regeln InsertOperationMessageOp, S. 158 Abb. 5.74, oder InsertSignalMessageOp, S.158 Abb. 5.75, angewendet, je nachdem ob die Message eine Operation oder ein Signal referenziert.Diese/dieses muss in der Basisklasse des RoleNodes definiert sein. Dann kann die VOCLMessageExpund die resultierende SequenceRole eingefügt werden, diese wird dann auch zu einem Pfadknoten.Danach müssen für alle Parameter der entsprechenden Operation die Argumente der VOCLMessage-Exp eingefügt werden. Diese können Variablen (InsertMessageExpArgVariable, S. 159 Abb. 5.77, oderInsertMessageExpArgVariable2, S. 161 Abb. 5.80), Konstanten (InsertMessageExpArgLiteral, S. 159Abb. 5.76, oder InsertMessageExpArgLiteral2, S. 160 Abb. 5.79) oder nicht genauer spezifizierte Werte(Unspecified, bei denen nur der Typ festgelegt ist, InsertMessageExpArgUnspecified, S. 160 Abb. 5.78,


oder InsertMessageExpArgUnspecified2, S. 161 Abb. 5.81) sein. Die entsprechenden OCL Constraintssind:VOCLMessageExp 1.: Eine VOCLMessageExp bezieht sich entweder auf eine Operation oder einSignalVOCLMessageExp 2. + 3.: Die Argumenttypen stimmen mit denen der referenzierten Operati-on/Signal übereinVOCLMessageExp 4.: Die Basisklasse hat eine entsprechende Operation definiertVOCLMessageExp 6.: Das Ergebnis ist eine SequenzVOCLMessageExp 7.: Das Ergebnis ist auch ein Pfadknoten

Die Transformation Unit InsertPathEnd

Die Transformation Unit InsertPathEnd, S. 134, fügt zwischen zwei alternativen Navigationsendeneine Navigation ein, so dass es nun ein gemeinsames Pfadende der beiden Pfade gibt. Also beginnenund enden die beiden Pfade an der selben Start- bzw. Endrolle. Auch hierfür gibt es verschiedeneMöglichkeiten. Wie zuvor kann zwischen zwei Rollen eine Association, eine AssociationClass oder eineCRTMethod eingefügt werden. Außerdem können die beiden Rollen in einer Teilmengenbeziehungstehen.

Die Regel InsertPathEndAssociation1, S. 124, fügt eine AssociationRole zwischen die momentanenEnden zweier Pfade (was die NACs sicherstellen) ein. Dazu muss es bereits zwei ClassifierRoles undeine enstprechende Association (aus dem UML Diagramm) mit zwei Assoziationsenden von den Typender ClassifierRoles, wobei ein Assoziationsende den übergebenenen Rollennamen haben muss, geben.Außerdem müssen die Kardinalitäten und andere Eigenschaften der Assoziation überprüft werden.Dann kann die AssociationRole und zwei AssociationEndRoles eingefügt werden. Die AssociationRo-le wird auch ein Knoten des Pfades, beide Pfade enden an der ClassifierRole, deren AssociationEndden Rollennamen hat. Da der Navigationsausdruck nicht weiter ergänzt werden kann, bekommt dieNavigationCallExp bei der Anwendung dieser Regel den Typ des Navigationsendes zugewiesen. Dieentsprechenden OCL Constraints sind dieselben wie bei InsertAssociation.

Die Regel InsertPathEndAssociation1_2, S. 125, macht dasselbe wie die Regel InsertPathEndAssocia-tion1, allerdings wurde hier bereits durch eine andere Regel der Typ der NavigationCallExp festgelegt,so dass das Pfadende dengleichen Typ wie sie haben muss, was auf der linken Regelseite überprüftwird. Die entsprechenden OCL Constraints sind dieselben wie bei InsertAssociation.

Die anderen Regeln aus InsertPathEndAssociation sind analog definiert und haben auch dieselben ent-sprechenden OCL Constraints.

Dasselbe gilt für die Regeln aus InsertPathEndAssociationClass (die entsprechenden Constraints sinddieselben Constraints wie bei InsertAssociationClass1 ), S. 121, die eine AssociationClassRole zwischendie momentanen Enden zweier Pfade einfügt, und InsertPathEndCRTMethod, S. 128, (dieselben Cons-traints wie bei InsertCRTMethod, S. 122), die eine Methode mit komplexem Rückgabetyp zwischendie momentanen Enden zweier Pfade einfügt. Auch bei diesen Regeln gibt es jeweils eine alternativeRegel, bei der der Typ der NavigationCallExp bereits festgelegt ist und mit dem des Navigationsendesübereinstimmen muss.

Die Regel InsertPathEndIncludes, S. 130 Abb. 5.36, fügt eine Ist-Enthalten bzw. Ist-Nicht-EnthaltenBeziehung zwischen einer CollectionRole und einer ClassifierRole ein, die das momentane Ende zweierPfade eines Navigationsausdrucks sind. Das Ergebnis ist eine Konstante vom Typ Boolean. Die Clas-sifierRole wird zum gemeinsamen Ende der beiden Pfade, der Typ der NavigationCallExp wird derTyp des Navigationsendes. Die NACs verbieten wieder, dass von einem der beiden Knoten bereits wei-ternavigiert wurde oder sie ein Argument einer anderen CollectionOp sind. Die Constraints zu diesenNACs sind also dieselben wie zu InsertPathEndAssociation, S. 133, bzw. InsertAssociation, S. 133. Dieentsprechenden OCL Constraints zum Einfügen einer Includes-Operation sind:


IncludesOp 1. + 2.: Includes hat CollectionRole und ClassifierRole als Argumente, das Ergebnis istein Boolean

Die Regel InsertPathEndIncludesAll, S. 132 Abb. 5.38, fügt analog eine Ist-Enthalten bzw. Ist-Nicht-Enthalten Beziehung zwischen zwei CollectionRoles CollectionRoles, die entsprechenden OCL Cons-traints sind dieselben.

Auch bei diesen Regeln gibt es jeweils eine alternative Regel, bei der der Typ der NavigationCallExpbereits festgelegt ist und mit dem des Navigationsendes übereinstimmen muss (InsertPathEndInclu-des_2, S. 131 Abb. 5.37 und (InsertPathEndIncludesAll_2, S. 132 Abb. 5.39.

Die Regel InsertNewPath, S. 111 Abb. 5.15, fügt einen neuen Pfad zu einer NavigationCallExp ein, deran derselben Startrolle anfängt wie ein bereits existierender Pfad. Zu diesem Zeitpunkt gibt es keinenentsprechenden Constraint, diese sind erst nach der Ausführung der gesamten Transformation Uniterfüllt.

Die Transformation Unit InsertEquivalentPathes

Diese Transformation Unit, S. 134, fügt zu einer Startrolle verschiedene Pfade zur gleichen Endrolleein. Die Hilfs-TransformationUnits wurden zuvor beschrieben. Es wird zunächst ein Navigationsaus-druck und ein Pfadanfang, dann beliebig viele weitere Pfadanfänge (eine Classifier- oder SetRole),und danach beliebig viele Knoten in diese Pfade eingefügt. Danach werden alle Navigationsenden miteiner Endrolle verknüpft. Erst dann wurde sichergestellt, dass nur korrekte Pfadausdrücke eingefügtwurden und kein Pfad existiert, der irgendwo beginnt und inkorrekt endet. Die enstsprechenden OCLConstraints sind:NavigationCallExp 1. + 2.: Alle Pfade haben ein korrektes EndeNavigationCallExp 3.: Die Navigation beginnt bei self oder der Constraintvariablen oder AllInstan-ces

Die Transformation Unit InsertAttributeNavigation

Diese Transformation Unit fügt eine Navigation zu einem Attributwert, mit dem eine Vergleichsope-ration durchgeführt wird, ein. Auch sie enthält andere Hilfs-TransformationUnits zum Einfügen einesPfadanfangs (InsertStartRole, S. 133), zum Einfügen der Knoten im Pfad (InsertPathNode, S. 133) unddie TransformationUnit InsertArithmExp, S. 141, die die Vergleichsoperation einfügt. Außerdem kön-nen neue Pfade eingefügt werden, die der Zuweisung von Werten an Variablen dienen. Diese Variablenkönnen dann als Argumente des arithmetischen Vergleichs-Ausdrucks verwendet werden. Außerdementhält InsertAttributeNavigation, S. 147, Regeln, die im folgenden beschrieben werden. Die bereits fürInsertEquivalentPathes behandelten TransformationUnits werden nicht noch einmal behandelt.

Die Regel InsertAttributeAssignment, S. 142 Abb. 5.52, fügt eine Variablenzuweisung mit einer Varia-blen und einem Attribut an eine ClassifierRole an. Der Variablen wird der Wert eines Attributes derClassifierRole zugewiesen. Die Variable hat denselben Typ wie das Attribut und ein entsprechendesAttribut muss in der Basisklasse der ClassifierRole definiert worden sein. Die ClassifierRole wird zumEnde des Pfades und muss das bisherige Ende des Pfades gewesen sein, d.h. von ihr startet keineandere Navigation (NACs). Die NavigationCallExp bekommt nun den Typ des Navigationsendes. Dierestlichen NACs drücken aus, dass es noch keine Variable mit diesem Namen innerhalb des Constraintsgibt und dass der Wert dieses Attributes nur einer Variablen zugewiesen wird. Die entsprechendenOCL Constraints sind:AttributeAssignment 1.: Die Typen von Attribut und Variable sind gleichRoleNode 4.: Das Attribut wird nur einer Variablen zugewiesenRoleNode 7.: Die Basisklasse hat ein solches AttributConstraint 6.: Die Variablennamen sind eindeutig


Path 4.: Die Navigationen haben eine Richtung

Auch bei dieser Regel gibt es eine alternative Regel, bei der der Typ der NavigationCallExp bereitsfestgelegt ist und mit dem des Navigationsendes übereinstimmen muss (InsertAttributeAssignment_2,S. 143 Abb. 5.53).

Die Regel InsertAttributeAssignment2, S. 143 Abb. 5.54, fügt eine Variablenzuweisung mit einer Varia-blen und einem Attribut an eine ClassifierRole an. Der Variablen wird der Wert eines Attributes derClassifierRole zugewiesen. Die Variable hat denselben Typ wie das Attribut und ein entsprechendesAttribut muss in der Basisklasse der ClassifierRole definiert worden sein. Die ClassifierRole wird nichtzum Ende des Pfades, d.h. diese Variablenzuweisung findet mitten im Pfad statt. Die NACs drückenaus, dass es noch keine Variable mit diesem Namen innerhalb des Constraints gibt und dass der Wertdieses Attributes nur einer Variablen zugewiesen wird. Die entsprechenden OCL Constraints sind:AttributeAssignment 1.: Die Typen von Attribut und Variable sind gleichRoleNode 4.: Das Attribut wird nur einer Variablen zugewiesenRoleNode 7.: Die Basisklasse hat ein solches AttributConstraint 6.: Die Variablennamen sind eindeutig

Die Regel InsertMethod2, S. 145 Abb. 5.57, weist einer Variablen den Rückgabewert eines Methoden-aufrufs auf einen RoleNode zu. Sie fügt die Mehode und die Variable zum RoleNode ein. Die Basisklassedes RoleNodes muss eine entsprechende Operation mit einem entsprechenden Rückgabe-Parameter desentsprechenden Typs definieren. Der Typ der Variablen und des Ergebniswerts sind gleich. Der Role-Node wird zum Ende des Pfades und muss das bisherige Ende des Pfades gewesen sein, d.h. von ihmstartet keine andere Navigation (NACs). Die NavigationCallExp bekommt nun den Typ des Navigati-onsendes. Die restlichen NACs drücken aus, dass es noch keine Variable mit diesem Namen innerhalbdes Constraints gibt und dass der Rückgabewert dieser Methode nur einer Variablen zugewiesen wird.Die entsprechenden OCL Constraints sind:RoleNode 3.: Die Basisklasse definiert eine entsprechende OperationRoleNode 5.: Das Ergebnis wird nur einer Variablen zugewiesenConstraint 6.: Die Variablennamen sind eindeutigPath 4.: Die Navigationen haben eine Richtung

Auch bei dieser Regel gibt es eine alternative Regel, bei der der Typ der NavigationCallExp bereitsfestgelegt ist und mit dem des Navigationsendes übereinstimmen muss (InsertMethod2WithNavType,S. 146 Abb. 5.58).

Die Regel InsertMethod2_2, S. 146 Abb. 5.59, weist einer Variablen den Rückgabewert eines Methoden-aufrufs auf einen RoleNode zu. Sie fügt die Mehode und die Variable zum RoleNode ein. Die Basisklassedes RoleNodes muss eine entsprechende Operation mit einem entsprechenden Rückgabe-Parameter desentsprechenden Typs definieren. Der Typ der Variablen und des Ergebniswerts sind gleich. Der Ro-leNode wird nicht Ende des Pfades. Die NACs drücken aus, dass es noch keine Variable mit diesemNamen innerhalb des Constraints gibt und dass der Rückgabewert dieser Methode nur einer Variablenzugewiesen wird. Die entsprechenden OCL Constraints sind:RoleNode 3.: Die Basisklasse definiert eine entsprechende OperationRoleNode 5.: Das Ergebnis wird nur einer Variablen zugewiesenConstraint 6.: Die Variablennamen sind eindeutig

Die Regel InsertSizeExp1, S. 149 Abb. 5.62, fügt eine Size-Operation, die auf eine CollectionRoleangewendet wird, ein. Das Ergebnis wird einer Variablen vom Typ Integer zugewiesen, deren Nameinnerhalb des Constraints eindeutig ist. Die CollectionRole wird zum Ende des Pfades und muss dasbisherige Ende des Pfades gewesen sein, d.h. von ihr startet keine andere Navigation und es wird auchkeine andere CollectionOp angewendet (NACs). Die NavigationCallExp bekommt nun den Typ desNavigationsendes. Der Rückgabewert dieser Operation wird nur einer Variablen zugewiesen, was durch


NACs sichergestellt wird. Die entsprechenden OCL Constraints sind:SimpleCollectionOp 1.: Das Ergebnis wird nur einer Variablen zugewiesenSimpleCollectionOp 2.: Der Ergebnistyp ist IntegerConstraint 6.: Die Variablennamen sind eindeutigPath 4.

Auch bei dieser Regel gibt es eine alternative Regel, bei der der Typ der NavigationCallExp bereitsfestgelegt ist und mit dem des Navigationsendes übereinstimmen muss (InsertSizeExp1_2, S. 149 Abb.5.63).

Die Regel InsertSizeExp2, S. 148 Abb. 5.61, fügt eine Size-Operation, die auf eine Collection angewen-det wird, ein. Das Ergebnis wird einer Variablen vom Typ Integer zugewiesen, deren Name innerhalbdes Constraints eindeutig ist. Die CollectionRole wird nicht Ende des Pfades. Der Rückgabewert dieserOperation wird nur einer Variablen zugewiesen und es wird auch keine andere CollectionOp angewen-det, was durch NACs sichergestellt wird. Die entsprechenden OCL Constraints sind:SimpleCollecOp 1.: Das Ergebnis wird nur einer Variablen zugewiesenSimpleCollectionOp 2.: Der Ergebnistyp ist IntegerConstraint 6.: Die Variablennamen sind eindeutig

Die Regel InsertState2, S. 154 Abb. 5.68, fügt den obersten Zustand der StateMachine, die für dieseBasisklasse der ClassifierRole definiert wurde, ein. Von der ClassifierRole kann weiternavigiert werden.Es kann entweder ein Zustand oder ein Attribut oder ein Methodenaufruf oder eine gesendete Messagezu einer ClassifierRole dargestellt werden (NACs).Mit der Regel InsertSubState, S. 154 Abb. 5.69, können Unterzustände zu einem vorhandenem Zustandeingefügt werden. Dafür muss der entsprechende Zustand (aus der StateMachine des UML Diagramms)auch einen Unterzustand mit demselben Namen haben und es darf nur ein Unterzustand eines Zustandseingefügt werden. Die entsprechenden OCL Constraints sind:ClassifierRole 1.: es wird entweder der Zustand oder Attribute/Methodenaufrufe dargestelltClassifierRole 2.: es existiert eine entsprechende StateMachine

Die Regel InsertMethodArgLiteral, S. 138 Abb. 5.44, fügt zu einer Methode eine Konstante als Argu-ment ein. Dafür muss die entsprechende Operation einen entsprechenden Parameter vom entsprechen-den Typ haben. Außerdem darf zu jedem Parameter nur ein Argument eingefügt werden, was die NACbeschreibt. Die entsprechenden OCL Constraints sind:Method 1.: Die Typen stimmen übereinMethod 2.: Zu jedem Parameter gibt es ein Argument

Die Regel InsertMethodArgVar, S. 138 Abb. 5.45, fügt zu einer Methode eine bereits definierte Varia-ble als Argument ein. Dafür muss die entsprechende Operation einen entsprechenden Parameter vomentsprechenden Typ haben. Außerdem darf zu jedem Parameter nur ein Argument eingefügt werden,was die NAC beschreibt. Die entsprechenden OCL Constraints sind:Method 1.: Die Typen stimmen übereinMethod 2.: Zu jedem Parameter gibt es ein ArgumentMethod 6.: Die Variable muss bereits definiert worden sein

Die Regel InsertAttributeOp, S. 135 Abb. 5.40, fügt in eine ClassifierRole ein Attribut, eine Operationund einen arithmetischen Ausdruck ein. Der Wert des Attributes wird mit dem arithmetischen Aus-druck verglichen. Dafür muss die Basisklasse der ClassifierRole ein solches Attribut definieren und esmuss eine entsprechende Operation mit einem Inputparameter des Typs des Attributs geben. Dannwird die AttributeOp und die ArithmExp eingefügt, welche dann mit weiteren Regeln bzw. durch dieTransformationUnit InsertArithmExp, S. 141, erweitert wird. Die Typen des arithmetischen Ausdrucksund des Attributes sind gleich. Nun ist die ClassifierRole das Pfadende und die NavigationCallExpbekommt ihren Typ. Die entsprechenden OCL Constraints sind:


AttributeOp 1. + 2.: Die Typen der Argumente sind gleich und stimmen mit denen der Parameterder korrespondierenden Operation übereinRoleNode 6.: Die Basisklasse hat ein entsprechendes Attribut

Auch bei dieser Regel gibt es eine alternative Regel, bei der der Typ der NavigationCallExp bereitsfestgelegt ist und mit dem des Navigationsendes übereinstimmen muss (InsertAttributeOp_2, S. 136Abb. 5.41).

Die TransformationUnit InsertArithmExp

Die TransformationUnit InsertArithmExp, S. 141, fügt einen arithmetischen Ausdruck ein. Dieser kannentweder eine Konstante (InsertAritmExpLiteral) oder eine Variable (InsertAritmExpVariable) odereine weitere arithmetische Operation (InsertAritmExpOperation) mit zwei Argumenten sein.

Die Regel InsertArithmExpLiteral, S. 139 Abb. 5.46, fügt als arithmetischen Ausdruck eine Konstantevom Typ der ArithmExp ein. Die NACs drücken aus, dass es nur einen arithmetischen Ausdruck zueiner ArithmExp gibt. Die entsprechenden OCL Constraints sind:ArithmExp 1.: Die Typen der Argumente sind gleichArithmExp 2.: Es gibt nur ein Argument

Die Regel InsertArithmExpVariable, S. 139 Abb. 5.47, fügt als Argument des arithmetischen Ausdruckseine bereits existierende Variable vom Typ der ArithmExp ein. Die NACs drücken aus, dass es nureinen arithmetischen Ausdruck zu einer ArithmExp gibt. Die entsprechenden OCL Constraints sind:ArithmExp 1.: Die Typen der Argumente sind gleichArithmExp 2.: Es gibt nur ein ArgumentArithmExp 3.: Die Variable muss schon existieren

Die Regel InsertArithmExpOperation, S. 139 Abb. 5.48, fügt als Argument des arithmetischen Aus-drucks eine Operation mit einem Ergebnis vom Typ der ArithmExp ein. Eine entsprechende Operationmuss definiert sein. Die NACs drücken aus, dass es nur einen arithmetischen Ausdruck zu einer Arith-mExp gibt. Die entsprechenden OCL Constraints sind:ArithmExp 1.: Die Typen der Argumente sind gleichArithmExp 2.: Es gibt nur ein Argument

Die Regel InsertArithmOpArgLiteral, S. 140 Abb. 5.49, fügt als Argument einer arithmetischen Operati-on eine Konstante ein. Die korrespondierende Operation muss einen entprechenden Parameter besitzen.Zu jedem Parameter gibt es genau eine Argument (NACs). Die entsprechenden OCL Constraints sind:ArithmOp 1. + 2.: Die Typen der Argumente sind gleich und stimmen mit denen der Parameterder korrespondierenden Operation überein, zu jedem Parameter gibt es ein Argument

Die Regel InsertArithmOpArgVariable, S. 140 Abb. 5.50, fügt als Argument einer arithmetischen Opera-tion eine bereits existierende Variable ein. Die korrespondierende Operation muss einen entprechendenParameter besitzen. Zu jedem Parameter gibt es genau eine Argument (NACs). Die entsprechendenOCL Constraints sind:ArithmOp 1. + 2.: Die Typen der Argumente sind gleich und stimmen mit denen der Parameterder korrespondierenden Operation überein, zu jedem Parameter gibt es ein ArgumentAritmOp 3.: Die Variable wurde bereits definiert

Die Regel InsertArithmOpArgOperation, S. 141 Abb. 5.51, fügt als Argument einer arithmetischenOperation eine Operation ein. Die korrespondierende (zur ersten ArithmOp) Operation muss einenentprechenden Parameter besitzen. Auch die zur neu einzufügenden ArithmOp korrespondierende Ope-ration muss existieren und entprechende Parameter besitzen. Zu jedem Parameter gibt es genau eineArgument (NACs). Die entsprechenden OCL Constraints sind:


ArithmOp 1. + 2.: Die Typen der Argumente sind gleich und stimmen mit denen der Parameterder korrespondierenden Operation überein, zu jedem Parameter gibt es ein Argument

Die Transformation Unit InsertAttributeNavigation, S. 147, fügt einen Navigationsausdruck (RegelInsertNavigationCallExp, S. 109 Abb. 5.10,) und danach beliebig viele

- neue Pfadanfänge (InsertNewPath, S. 111 Abb. 5.15)

- neue Pfadknoten (InsertPathNode, S. 133)

- Variablenzuweisungen (InsertAttributeAssignment, S. 142 Abb. 5.52, InsertMethod2_2, S. 146Abb. 5.59, InsertSizeExp2, S. 149 Abb. ??) oderZustandsbeschreibungen (InsertState2;InsertSubState, ab S. 154)

ein. Danach müssen, falls Operationen eingefügt wurden, deren Argumente eingefügt werden (AsLon-gAsPossible InsertMethodArgLiteral(ln) or InsertMethodArgVar(vn)). Nun wird an einem Pfadendeeine Operation auf einem Attributwert (InsertAttributeOp or InsertAttributeOp_2, ab S. 135) und derarithmetische Ausdruck (InsertArithmExp, S. 141) eingefügt.Nach dieser Transformation Unit ist sichergestellt, dass ein korrekter Pfad, beginnend an einer Startrol-le zu einer Endrolle mit Attributnavigation eingefügt wurde. Die Zwischenknoten dienen der Navigationoder der Definition von Variablen für den arithmetischen Ausdruck, mit dem der Attributwert vergli-chen wird. Die entsprechenden OCL Constraints sind:NavigationCallExp 1. + 2.: Alle Pfade haben ein korrektes EndeNavigationCallExp 3.: Die Navigation beginnt bei self oder der Constraintvariablen

Die TransformationUnit InsertMethodNavigation

Diese TransformationUnit fügt eine Navigation zu einem Methodenaufruf, mit dessen Ergebniswerteine Vergleichsoperation durchgeführt wird, ein. Auch sie enthält andere Hilfs-TransformationUnitszum Einfügen eines Pfadanfangs (InsertStartRole, S. 133), zum Einfügen der Knoten im Pfad (Insert-PathNode, S. 134) und die TransformationUnit InsertArithmExp, S. 141, die die Vergleichsoperationeinfügt. Außerdem können neue Pfade eingefügt werden, die der Zuweisung von Werten an Variablendienen. Diese Variablen können dann als Argumente des arithmetischen Vergleichs-Ausdrucks verwen-det werden. InsertMethodNavigation, S. 147, enthält zwei Regeln, die noch nicht behandelt wurdenund im folgenden beschrieben werden. Die bereits für InsertEquivalentPathes beschriebenen Transfor-mationUnits sowie InsertArithmExp werden nicht noch einmal beschrieben.

Die Regel InsertMethodOp, S. 137 Abb. 5.42, fügt an eine ClassifierRole einen Methodenaufruf an, dasErgebnis der Methode wird mit einem arithmetischen Ausdruck verglichen (wie bei InsertAttributeOp).Dafür muss die Basisklasse der ClassifierRole eine entsprechende Operation mit entsprechendem Ergeb-nistyp haben. Dann wird die MethodOp und eine ArithmExp eingefügt, welche dann wieder erweitertwerden muss. Die ClassifierRole ist nun das Pfadende des Pfades, zu dem er gehörte, und die Navi-gationCallExp bekommt ihren Typ. Zu einer ClassifierRole darf es nur einen solchen Methodenaufrufgeben (NAC). Die entsprechenden OCL Constraints sind:MethodOp 1.: Die Typen der Argumente stimmen überein mit den Typen der Parameter der korre-spondierenden OperationRoleNode 2.: Die Basisklasse definiert eine entsprechende Operation

Auch bei dieser Regel gibt es eine alternative Regel, bei der der Typ der NavigationCallExp bereitsfestgelegt ist und mit dem des Navigationsendes übereinstimmen muss (InsertMethodOp_2, S. 137Abb. 5.43).

Die Regel InsertMethod1, S. 144 Abb. 5.55, fügt an einen RoleNode einen Methodenaufruf, dessenErgebniswert true sein muss, an. Dafür muss die Basisklasse des RoleNodes eine entsprechende Ope-ration mit entsprechendem Ergebnistyp haben. Danach ist der RoleNode das Ende des Pfades und die


NavigationCallExp bekommt ihren Typ, es darf nur einen Methodenaufruf zu einem RoleNode geben(NAC). Außerdem darf der RoleNode nicht der Startknoten einer anderen Navigation sein (NACs).Die entsprechenden OCL Constraints sind:Method 1.: Die Typen der Argumente stimmen überein mit den Typen der Parameter der korrespon-dierenden OperationMethod 2.: Ergebnistyp ist BooleanRoleNode 3.: Die Basisklasse definiert eine entsprechende OperationPath 4.: Die Navigationen haben eine Richtung

Auch bei dieser Regel gibt es eine alternative Regel, bei der der Typ der NavigationCallExp bereitsfestgelegt ist und mit dem des Navigationsendes übereinstimmen muss (InsertMethod1_2, S. 144 Abb.5.56).

Nach Anwendung der Transformation Unit InsertMethodNavigation ist sichergestellt, dass ein korrek-ter Pfad, beginnend an einer Startrolle zu einer Endrolle mit Methodennavigation eingefügt wurde.Die Zwischenknoten dienen der Navigation oder der Definition von Variablen für den arithmetischenAusdruck, mit dem das Ergebnis des Methodenaufrufs verglichen wird. Die entsprechenden OCL Cons-traints sind:NavigationCallExp 1. + 2.: Alle Pfade haben ein korrektes EndeNavigationCallExp 3.: Die Navigation beginnt bei self oder der Constraintvariablen

Die Transformation Unit InsertSimpleCollOpNavigation

Diese Transformation Unit (S. 150) beschreibt die Navigation zu einer Collection, auf die dann eineeinfache Collection-Operation (isEmpty oder notEmpty) angewendet wird. Die Navigation beginnt aneinem Startknoten, hat beliebig viele Zwischenknoten und endet an einer CollectionRole, wonach dieRegel InsertEmptyExp, S. 148 Abb. 5.60, angewendet wird. Diese fügt eine Operation (isEmpty odernotEmpty) mit booleschem Ergebnis an die CollectionRole an. Die NACs definieren, dass nur eine Ope-ration auf eine CollectionRole angewendet wird und dass von der CollectionRole nicht weiternavigiertwird. Die CollectionRole ist nun das Pfadende des Pfades, zu dem er gehörte, und die NavigationCall-Exp bekommt ihren Typ. Die entsprechenden OCL Constraints sind:SimpleCollectionOp 1.: Operation hat keine Ergebnis-VariableSimpleCollectionOp 2.: Das Ergebnis ist ein boolescher WertCollectionRole 4.: Nur eine der Operationen isEmpty oder notEmpty wird angewandtPath 4.: Die Navigationen haben eine Richtung

Alternativ kann die Regel InsertEmptyExp_2 angewendet werden, bei der der Typ der Navigation-CallExp bereits feststeht und mit dem des Pfadendes übereinstimmen muss (S. 148 Abb. 5.61).

Auch nach dieser Transformation Unit ist sichergestellt, dass ein korrekter Pfad mit Navigation zueiner Collection eingefügt wurde. Die entsprechenden OCL Constraints sind:NavigationCallExp 1. + 2.: Alle Pfade haben ein korrektes EndeNavigationCallExp 3.: Die Navigation beginnt bei self oder der Constraintvariablen

Die TransformationUnit InsertConditionNavigation

Diese TransformationUnit (S. 152) definiert das Einfügen eines Bedingungsteils in einen Navigati-onsausdruck. Dieser Bedingungsteil enthält immer eine Operation, die sich auf einen Variablenwertbezieht und diesen mit einem arithmetischen Ausdruck vergleicht. Die Variable kann zuvor entwedereinem Attributwert oder dem Ergebniswert eines Methodenaufrufs zugewiesen worden sein, was in denbeiden TransformationUnits InsertAttributeNavCondition, S. 151, und InsertMethodNavCondition, S.152, definiert ist. Diese enthalten nur bereits beschriebene Regeln.


Die Regel InsertCondition, S. 151 Abb. 5.65, fügt zu einer NavigationCallExp einen Bedingungsteilein. Dafür muss eine Variable und auch eine entsprechende Vergleichsoperation auf Parametern desTyps der Variablen existieren. Dann kann die Condition und der arithmetische Ausdruck (Transforma-tion Unit InsertArithmExp) eingefügt werden. Typ von Variable und arithmetischem Ausdrucks sindgleich. Jede NavigationCallExp hat höchstens einen Bedingungsteil (NAC). Die entsprechenden OCLConstraints sind:Condition 1.: Die Typen der Argumente stimmen überein mit den Typen der Parameter der korre-spondierenden OperationCondition 2.: Eine korrespondierende Operation existiert

Nach dieser TransformationUnit ist sichergestellt, dass ein korrekter Pfad mit einer Bedingung einge-fügt wurde. Die entsprechenden OCL Constraints sind:NavigationCallExp 1. + 2.: Alle Pfade haben ein korrektes EndeNavigationCallExp 3.: Die Navigation beginnt bei self oder der Constraintvariablen

Die Transformation Unit InsertStateNavigation

Diese Transformation Unit definiert das Einfügen einer Navigation zu einem Zustand, in dem sicheine ClassifierRole befindet. Dafür wird zunächst eine Navigation zu einer ClassifierRole durch be-reits beschriebene TransformationUnits eingefügt und dann kann mit der Regel InsertState1 bzw.InsertState1_2 der oberste Zustand einer entsprechenden StateMachine und danach beliebig oft Un-terzustände von vorhandenen Zuständen eingefügt werden.

Die Regel InsertState1, S. 153 Abb. 5.66, kann nur angewendet werden, wenn die Basisklasse derClassifierRole der Kontext einer StateMachine mit dem entsprechenden obersten Zustand ist. Wenndargestellt wird, dass eine ClassifierRole in einem Zustand ist, dann darf sie keine Darstellung ihrerAttribute oder von Methodenaufrufen beinhalten, was die NACs sicherstellen. Die ClassifierRole istnun das Pfadende des Pfades, zu dem er gehörte, und die NavigationCallExp bekommt ihren Typ.Die enstsprechenden OCL Constraints sind:ClassifierRole 1.: es wird entweder der Zustand oder Attribute/Methodenaufrufe dargestelltClassifierRole 2.: es existiert eine entsprechende StateMachine

Auch bei dieser Regel gibt es eine alternative Regel, bei der der Typ der NavigationCallExp bereitsfestgelegt ist und mit dem des Navigationsendes übereinstimmen muss (InsertState1_2, S. 153 Abb.5.67).

Die Regel InsertSubState, S. 154 Abb. 5.69, fügt zu einem Zustand einen Unterzustand ein. Dazu mussder korrespondierende Zustand der StateMachine auch einen entsprechenden Unterzustand haben. Zueinem Zustand darf immer nur ein Unterzustand dargestellt werden, da die ClassifierRole nur in einemder möglichen Unterzustände sein kann, was die NAC festlegt. Die entsprechenden OCL Constraintssind:Kardinalitätsconstraints des MOF Modells.

Auch nach dieser TransformationUnit wurde ein korrekter Pfad eingefügt. Die entsprechenden OCLConstraints sind:NavigationCallExp 1. + 2. + 3.

Die TransformationUnit InsertMessageNavigation

Die Transformation Unit InsertMessageNavigation, S. 162 definiert das Einfügen einer Navigation zueiner Rolle, auf die der ˆ-Operator angewendet wird. Es wird eine NavigationCallExp eingefügt unddann von einer Startrolle entlang eines Pfades navigiert. Dieser Pfad kann Zuweisungen von Wer-ten an Variablen oder Aussagen über Zustände (durch die Regeln InsertAttributeAssignment2(vn,


an) or InsertMethod2_2(mn, rv) or InsertSimpleCollOp2_2(on, vn) or (InsertState2(sn1); InsertSub-State(sn2)*;)) enthalten. Diese Variablen können Argumente der am Schluss eingefügten MessageExpsein.Die Regeln InsertOperationMessageHasSent, S. 155 Abb. 5.70, InsertOperationMessageHasSent2, S.156 Abb. 5.71, InsertSignalMessageHasSent, S. 156 Abb. 5.72, InsertSignalMessageHasSent2, S. 157Abb. 5.73, fügen eine Message, die zu einer ClassifierRole gesendet wird, ein. Die Message referenziertentweder eine Operation oder ein Signal, die bereits in einem UML Diagramm zu der Basisklasse derClassifierRole definiert worden sind. Es gibt zwei Arten von Operatoren für Messages. Der hasSent-Operator (ˆ) beschreibt, dass die Message gesendet wurde und es kann nicht weiternavigiert werden.Es kann entweder ein Zustand oder ein Attribut oder ein Methodenaufruf oder eine gesendete Messagezu einer ClassifierRole dargestellt werden (NACs). Die entsprechenden OCL Constraints sind:VOCLMessageExp 1.: Die Message ist entweder eine Operation oder ein SignalVOCLMessageExp 4.: Die Basisklasse muss eine entsprechende Operation definiert habenVOCLMessageExp 5.: Nach dem hasSent-Operator wird nicht weiternavigiert

Die Regeln InsertMessageExpArgLiteral, InsertMessageExpArgVariable, InsertMessageExpArgUnspeci-fied, InsertMessageExpArgLiteral2, InsertMessageExpArgVariable2, InsertMessageExpArgUnspecified2,S. 159-161 fügen zu einer Message Argumente ein. Es können entweder Konstanten oder bereits de-finierte Variablen oder unspezifizierte Werte, von denen nur der Typ angegeben wird, sein. Die/dasreferenzierte Operation/Signal muss einen entsprechenden Parameter des Typs des Arguments habenund zu jedem Parameter gibt es nur ein Argument. Die entsprechenden OCL Constraints sind:VOCLMessageExp 2. + 3. :Die Argumenttypen stimmen mit den Parametertypen der jeweiligenOperation übereinVOCLMessageExp 5.:der hasSent-Operator (ˆ) wird auf eine ClassifierRole angewendet

Nach dieser Transformation Unit ist sichergestellt, dass ein korrekter Pfad, beginnend an einer Startrol-le zu einer Endrolle mit Attributnavigation eingefügt wurde. Die Zwischenknoten dienen der Navigationoder der Definition von Variablen für den arithmetischen Ausdruck, mit dem der Attributwert vergli-chen wird. Die entsprechenden OCL Constraints sind:NavigationCallExp 1. + 2.: Alle Pfade haben ein korrektes EndeNavigationCallExp 3.: Die Navigation beginnt bei self oder der Constraintvariablen

IfExpressions

Die Regel InsertIfExp, S. 163 Abb. 5.82, fügt als obersten Ausdruck eines Constraints eine IfExp ein(andere Möglichkeiten zum Einfügen einer IfExp sind als Argumente anderer VOCLExps). Die NACdefiniert, dass es noch keinen anderen obersten Ausdruck innerhalb des Constraints gibt. Ein If-Then-Else Ausdruck ist vom Typ Boolean. Die entsprechenden OCL Constraints sind:IfExp 2.: Typ der IfExp ist BooleanKardinalitäten

If-Then-Else Ausdrücke

Die Transformation Unit InsertIfExpIfNavigation, S. 170, fügt als If-Teil eines If-Then-Else Ausdruckseinen Navigationsausdruck ein (mit der Regel InsertIfExpIfNavigationCallExp, S. 163 Abb. 5.83). Dereingefügte Ausdruck gehört zum selben Constraint wie der If-Ausdruck und hat den Typ Boolean.Die NAC definiert, dass es noch keinen If-Teil gibt. Danach wird der Navigationsausdruck mit derTransformation Unit InsertPath zu einem korrekten Ausdruck vervollständigt.Die Transformation Units InsertIfExpThenNavigation und InsertIfExpElseNavigation sind analog de-finiert.

Die Transformation Unit InsertPath, S. 170, fügt einen Navigationsausdruck ein. Dieser beginnt aneiner Startrolle, die mit der TransformationUnit InsertPathStart eingefügt wird und deren Name und


Typ vom Typ des Constraints und der Definition einer Constraintvariablen abhängt.Nachdem eine Startrolle und eine Startnavigation eingefügt wurde, können alle Alternativen zum Ein-fügen eines korrekten Pfades eingefügt werden. Eine der TransformationUnits InsertEquivalentPathes-Nav, S. 134, InsertAttributeNav, S. 147, InsertMethodNav, S. 147, InsertSimpleCollOpNav, S. 150,InsertConditionNav, S. 152, InsertStateNav, S. 155, oder InsertMessageNav, S. 162 kann angewendetwerden. Danach wurde ein korrekter Navigationsausdruck eingefügt als If-Teil eingefügt.Die entsprechenden OCL Constraints sind:Path 1. + 2.NavigationCallExp 1. + 2.

Die Transformation Units InsertIfExpThenNavigation und InsertIfExpElseNavigation tun dasselbe, siefügen einen korrekten Navigationsasudruck in eine IfExp als Then- bzw. Else-Teil ein. Allerdings isthier darauf zu achten, dass die Typen des Then- und Else-Teils gleich sein müssen.

Die Transformation Unit InsertIfExpIfBooleanExp, S. 170, fügt als If-Teil eines If-Then-Else Ausdruckseinen booleschen Ausdruck ein (mit der Regel InsertIfExpIfBooleanExp, S. 163 Abb. 5.84). Danach wirdder boolesche Ausdruck mit der Transformation Unit InsertBooleanExp zu einem korrekten Ausdruckvervollständigt. Der eingefügte Ausdruck gehört zum selben Constraint wie der If-Ausdruck und hatden Typ Boolean. Die NAC definiert, dass es noch keinen If-Teil gibt.Die Transformation Unit InsertBooleanExp fügt die Argumente eines booleschen Ausdrucks (mit denTransformation Units InsertBooleanExpArg(1) und InsertBooleanExpArg(2)) ein.

Die Transformation Units InsertIfExpThenBooleanExp und InsertIfExpElseBooleanExp tun dasselbe,sie fügen einen korrekten booleschen Ausdruck in eine IfExp als Then- bzw. Else-Teil ein. Allerdingsist hier darauf zu achten, dass die Typen des Then- und Else-Teils gleich sein müssen.

Die Transformation Unit InsertIfExpIfIfExpression, S. 170, fügt als If-Teil eines If-Then-Else Ausdruckseinen If-Then-Else Ausdruck (mit der Regel InsertIfExpIfIfExp, S. 164 Abb. 5.85) und der Transfor-mation Unit InsertIfExp) ein.Die Transformation Unit InsertIfExp fügt die drei Teile eines If-Then-Else Ausdrucks (mit den Trans-formation Units InsertIfExp, InsertThenExp, InsertElseExp) ein.

Die Transformation Unit InsertIfExpIfLetExpression, S. 170, fügt als If-Teil eines If-Then-Else Aus-drucks einen Let-Ausdruck (mit der Regel InsertIfExpIfLetExp, S. 164 Abb. 5.86) und der Transforma-tion Unit InsertLetExp) ein. Der eingefügte Ausdruck gehört zum selben Constraint wie der If-Ausdruckund hat den Typ Boolean. Die NAC definiert, dass es noch keinen If-Teil gibt. Die TransformationUnits InsertIfExpThenLetExpression und InsertIfExpElseLetExpression sind analog definiert.

Die Transformation Unit InsertLetExp, S. 170, fügt die zwei Teile eines Let-Ausdrucks (mit den Trans-formation Units InsertLetExpInitVariable, InsertLetExpIn, S. 181,) ein.

Die Transformation Unit InsertIfExpIf, S. 170, fügt den If-Teil eines If-Then-Else Ausdrucks ein. Die-ser kann einer der vier zuvor beschriebenen Fälle sein. Die Transformation Units InsertIfExpThen undInsertIfExpElse sind analog definiert. Die Typen von Then- und Else-Teil müssen gleich sein.Die entspechenden OCL Constraints sind:IfExp 1.: Die Typen der Then und Else Ausdrücke sind gleichIfExp 2.: Typ der IfExp ist BooleanIfExp 3.: Der If-Teil gehört zum gleichen Constraint wie Then- und Else-Teil

Boolesche Ausdrücke

Die Regel InsertBooleanExp, S. 171 Abb. 5.99, fügt einen booleschen Ausdrucks in einen Constraintein.


Die Transformation Unit InsertBooleanExpression, S. 173, fügt einen booleschen Ausdrucks ein. DieTypen der beiden Argumente sind boolesch.

Die Transformation Unit InsertBooleanExpArgNavigationCallExpression(ord) fügt als Argument einesbooleschen Ausdrucks einen Navigationsausdruck (mit der Regel InsertBooleanExpArgNavigationCall-Exp(ord), S. 200 Abb. 5.150) und den Ausdrucks (mit der Transformation Unit InsertPath, S. 170).

Die Transformation Unit InsertBooleanExpArgBooleanExpression(ord) fügt als Argument eines boole-schen Ausdrucks einen booleschen Ausdruck (mit der Regel InsertBooleanExpArgBooleanExp(ord), S.172 Abb. 5.101) und die beiden Argumente dieses Ausdrucks (mit der Transformation Unit InsertBoo-leanExp).

Die Transformation Unit InsertBooleanExpArgIfExpression(ord) fügt als Argument eines booleschenAusdrucks einen If-Then-Else Ausdruck (mit der Regel InsertBooleanExpArgIfExp(ord), S. 172 Abb.5.102) und die drei Teile dieses Ausdrucks (mit der Transformation Unit InsertIfExp, S. 170) ein.

Die Transformation Unit InsertBooleanExpArg1LetExpression(ord) fügt als Argument eines booleschenAusdrucks einen Let-Ausdruck (mit der Regel InsertBooleanExpArgLetExp(ord), S. 172 Abb. 5.103) unddie beiden Teile dieses Ausdrucks, die Initialisierung der Letvariablen und den in-Teil (mit de Trans-formation Unit InsertLetExp, S. 181).

Die Transformation Unit InsertBooleanExpArg(ord) fügt ein Argument des booleschen Ausdrucks ein.Dies kann einer der vier zuvor beschriebenen Fälle sein.

Die entsprechenden OCL Constraints sind:BooleanExp 1.: Die Argumente haben den Typ Boolean BooleanExp 2.: Die Argumente gehörenzum gleichen Constraint

Let-Ausdrücke

Ein Let-Ausdruck definiert eine Variable. Der Wert, mit dem diese initialisiert wird, ist eine VOCLExpmit demselben Typ.

Die Regel InsertLetExp, S. 174 Abb. 5.104, fügt als obersten Ausdruck eines Constraints eine LetExpein (andere Möglichkeiten zum Einfügen einer LetExp sind als Argumente anderer VOCLExps). DieNACs definieren, dass es noch keinen anderen obersten Ausdruck innerhalb des Constraints und nochkeine Variable mit diesem Namen gibt. Die entsprechenden OCL Constraints sind:LetExp 3.: Die Namen der LetVariablen sind eindeutig

Die drei folgenden Regeln (InsertLetExpInitVarBooleanExp, S. 174 Abb. 5.105, InsertLetExpInitVarI-fExp, S. 174 Abb. 5.106, InsertLetExpInitVarLetExp, S. 175 Abb. 5.107) fügen die Initialisierung derLetVariablen ein, diese kann eine BooleanExp, eine IfExp, eine weitere LetExp sein. Bei diesen Regelnsind die Ausdrücke vom gleichen Typ wie die Variable (oder umgekehrt), und zwar Boolean. Die NACsdefinieren, dass es noch keine initExpression für die Variable gibt. Der entsprechende OCL Constraintist:LetExp2.: Die Typen der Variable und initExpression sind gleich

Danach muss jeweils der eingefügt initiale Ausdruck vervollständigt werden (durch die Anwendung derTransformation Units InsertIfExp, InsertBooleanExp bzw. InsertLetExp)

Oder die Variable kann mit einem Navigationsausdruck initialisiert werden. Wenn der Typ der Varia-blen Boolean ist, kann sie mit dem Ergebnis eines korrekten Pfadausdrucks (also der Gültigkeit diesesAusdrucks) initialisiert werden, dann wäre die Initialisierung ein Pfad. Die TransformationUnit Insert-


PathLetInit, S. 181, ist analog zu der TransformationUnit InsertIfExpIfNavigation, S. 170, und wirdnicht weiter beschrieben. Oder die Variable wird mit einem Attributwert initialisiert, zu dem zunächstnavigiert wird (TransformationUnit InsertAttributeNavLetInit, S. 181), oder mit dem Ergebnis einesMethodenaufrufs (TransformationUnit InsertMethodNavLetInit, S. 181), oder mit einer ClassifierRolebzw. CollectionRole, zu der navigiert wird (TransformationUnit InsertRoleNodeNavLetInit, S. 181). Indiesen drei Transformation Units wird zuerst ein Navigationsausdruck mit Startrolle, an der die Navi-gation beginnt, eingefügt (analog zum Einfügen eines Navigationsausdrucks bei einer IfExp). Danachkönnen beliebig viele weitere Pfadknoten eingefügt werden (TransformationUnit InsertPathNode, S.134).Bei der Navigation zu einem Attributwert wird dann eine Variablenzuweisung eingefügt, die der Let-variablen den Wert eines Attributs des letzten Pfadknotens zuweist. Die entsprechenden Regeln undConstraints wurden schon beschrieben (InsertAttributeAssignment, S. 142 Abb.5.52).Bei der Navigation zum Ergebniswert eines Methodenaufrufs wird mit der Regel InsertMethodOp2, S.?? Abb.??, die Methode eingefügt und ihr Ergebnis der Variablen zugewiesen. Auch diese Regel unddie entsprechenden OCL Constraints wurden bereits beschrieben.Bei der Initialisierung mit einer ClassifierRole/CollectionRole wird der letzten ClassifierRole/CollectionRole,zu der navigiert wurde, der Name der Variablen mit der Regel InsertClassifierRoleName, S. 176Abb.5.109/InsertCollectionRoleName, S. 176 Abb.5.110, gegeben. Der Typ der Variablen ist gleichdem der ClassifierRole/CollectionRole, danach endet der Pfad an dieser ClassifierRole/CollectionRole.Die entsprechenden OCL Constraints sind:RoleNode 1.: Typ von RoleNode und Variablen sind gleich

Nach einer dieser Regeln wurde die Variable mit einem korrekten Pfadausdruck initialisiert. Die ent-sprechenden OCL Constraints sind:NavigationCallExp 1. + 2.: es wurde ein korrekter Pfad eingefügt, der die Initialisierung einerLetVariablen ist.

Die Transformation Unit InsertDefinitionConstraint, S. 181 Abb.5.3.3, fügt einen definition-Constraintein. In diesem ist nur ein Let Ausdruck enthalten, der eine Variable definiert, die auch außerhalb desConstraints bekannt ist und somit für das gesamte UMLModell verwendet werden kann.Dafür wird zunächst ein Constraint der Art definition mit der Regel CreateConstraint1("def"), S. 108Abb.5.5, erzeugt. Danach kann optional eine ConstraintVariable, S. 108 Abb.5.8, und ein Constraint-Name, S. 108 Abb.5.7, eingefügt werden. Der Body besteht aus einer LetExp (Transformation UnitInsertLetExpression, S. 181 Abb.5.3.3). Die Regeln zum Einfügen einer LetExp verhindern, dass eineLetExp innerhalb eines definition-Constraints einen In-Teil hat. Die entsprechenden OCL Constraintssind:LetExp 1. + Constraint 7.:LetExp ohne In-Teil gibt es nur in definition-Constraints

Die restlichen Regeln dieser Transformation Unit und die entsprechenden OCL Constraints wurdenbereits beschrieben.

Die Transformation Unit InsertBoolLoopNavigation

Die Transformation Unit (S. 218) definiert das Einfügen einer Navigation zu einer LoopExp, derenErgebnis ein boolescher Wert ist. Dafür wird zunächst eine Navigation zu einer CollectionRole durchbereits beschriebene TransformationUnits eingefügt.Dann wird eine LoopExp eingefügt:

Die TransformationUnit InsertBoolResultShortCut,S. 216 fügt an eine Collection eine LoopExp undOperationen auf Attributwerten und optional Variablenzuweisungen an Attributwerte an.

Die Regel InsertBoolResultShortCut, S. 216 Abb. 5.171, fügt eine Kurzform einer LoopExpression mitbooleschem Ergebnis (ShortCutLoopExp mit dem Namen forall, exists, one oder isUnique), die aufeine Collection angewendet wird, ein. Die Eigenschaften, die alle/genau ein/mindestens ein Elemente


der Collection erfüllen müssen bzw. die für alle Elemente eindeutig sein müssen, beziehen sich nurauf Attributwerte der Collectionelemente. Von der CollectionRole darf nicht schon weiternavigiertoder eine andere Collection-Operation auf ihr ausgeführt worden sein, was eine NAC ausdrückt. DieCollectionRole wird zum Ende des Pfades, von ihr kann keine weitere Navigation ausgehen, und dieNavigationCallExp bekommt den Typ des Navigationsendes (die Regel InsertBoolResultShortCut_2,S. 216 Abb. 5.172, ist genauso definiert, bei ihr hat die NavigationCallExp bereits einen Typ). Dieentsprechenden OCL Constraints sind:LoopExp 4.: Das Ergebnis der LoopExp ist BooleanPath 4.: Die Navigationen haben eine Richtungsowie die Constraints zum Einfügen einer AttributeOp (AttributeOp 1. + 2.)

Danach können beliebig viele AttributeAssignments eingefügt werden, die Variablen die Werte vonAttributen der Elemente der Collection zuweisen.Die Regel InsertCollectionAttributeAssignment, S. 210 Abb. 5.165, kann angewendet werden, wenndie Basisklasse der CollectionRole, zu welcher die ShortCutLoopExp gehört, ein solches Attribut hat.Dann kann die Variable vom Typ des Attributes und die Zuweisung eingefügt werden. Die Variablegehört nun zum Constraint und ihr Name ist eindeutig. Die entsprechenden OCL Constraints sind:AttributeAssignment 1.: Die Typen von Variable und Attribut sind gleichRoleNode 7.: Die Basisklasse hat ein entsprechendes AttributCollectionRole 3.: CollectionRole hat nur ein AttributeAssignment innerhalb einer ShortCutLoop-ExpConstraint 6.: Die Variablennamen sind eindeutig

Nun können die Attributoperationen eingefügt werden, wovon es mindestens eine geben muss.Die Regel InsertCollectionAttributeOp, S. 210 Abb. 5.164, fügt an eine CollectionRole, auf die eineShortCutLoopExp angewendet wird, eine Vergleichsoperation auf einem Attributwert ein. Der Attri-butwert wird mit einem arithmetischen Ausdruck verglichen. Die Basisklasse muss ein entsprechendesAttribut haben und eine entsprechende Operation auf den entsprechenden Typen muss definiert sein.Dann wird die Operation und eine ArithmExp eingefügt. Die entsprechenden OCL Constraints sind:ShortCutLoopExp 2.: es wird über Attributwerte iteriert.CollectionRole 2.: eine CollectionRole hat nur in einer ShortCutLoopExp AttributeCollectionRole 3.: CollectionRole hat nur ein AttributeAssignment innerhalb einer ShortCutLoop-ExpAttributeOp 1. + 2.

Die TransformationUnit InsertArithmExp, S. 141, wurde bereits beschrieben. Durch sie wird der arith-metische Ausdruck vervollständigt. Da es mehrere Operationen auf Attributen geben kann, muss dieseTransformation Unit so oft wie möglich angewendet werden.

Die Transformation Unit InsertBoolLoop, S. 208, fügt an eine CollectionRole, die das bisherige Endeeines Pfades ist, eine LoopExp mit dem Namen forall oder exists oder one oder isUnique und einemIterator ein. Der Iterator hat den Typ der Elemente der CollectionRole, die Variable darf im Constraintnoch nicht definiert worden sein. Der Body ist ein VOCL Ausdruck. Das Ergebnis ist ein boolescherWert. Die entsprechenden OCL Constraints sind:LoopExp 4.,Constraint 6.,BodyLoopExp 2. + 5.: Legen den Typ des Iterators fest undDer Body kann ein Navigationsausdruck (Regel InsertBoolLoopWithNavigationBody, S. 192 Abb. 5.135,oder InsertBoolLoopWithNavigationBody_2, S. 193 Abb. 5.136), danach muss ein korrekter Pfad mitschon beschriebenen Transformation Units eingefügt werden), ein If-Then-Else-Ausdruck (Regel In-sertBoolLoopWithIfBody oder InsertBoolLoopWithIfBody_2, danach müssen die drei Teile dieses Aus-drucks eingefügt werden), ein Let Ausdruck (Regel InsertBoolLoopWithLetBody oder InsertBoolLoop-WithLetBody_2, danach müssen die Initialisiserung und der In Teil dieses Ausdrucks eingefügt werden)


oder ein boolescher Ausdruck (Regel InsertBoolLoopWithBooleanExpBody oder InsertBoolLoopWith-BooleanExpBody_2, danach müssen die zwei Argumente dieses Ausdrucks eingefügt werden) sein. Dieentsprechenden Transformation Units wurden schon beschrieben.

Die Transformation Unit InsertForallLoop, S. 208, fügt (analog zu InsertBoolLoop) eine Forall-Operationmit zwei Iteratoren ein. Die entsprechenden OCL Constraints sind:LoopExp 4.,Constraint 6.,BodyLoopExp 2. + 5.: legen den Typ des Iterators fest undBodyLoopExp 3.: bei einer Forall-Operation kann es zwei Iteratoren geben

Nach dem Einfügen der LoopExp wurde ein korrekter Navigationsausdruck eingefügt. Die entsprechen-den OCL Constraints sind:NavigationCallExp 1. + 2. + 3.

Die Transformation Unit InsertConstraint

Die Transformation Unit InsertConstraintBody, S. 218 Abb.5.3.3, fügt den Body eines Constraints ein.Das kann ein Navigationsausdruck (die Regel InsertNavigationCallExp, S. 109 Abb.5.10, gefolgt vonder Transformation Unit InsertPath, S. 170), ein If-Then-Else Ausdruck (Transformation Unit InsertIf-Expression, S. 170 Abb.5.3.3), ein boolescher Ausdruck (Transformation Unit InsertBooleanExpression,S. 173 Abb.5.3.3) oder ein Let Ausdruck (Transformation Unit InsertLetExpression, S. 181 Abb.5.3.3)sein. Diese Regeln und Transformation Unit wurden bereits beschrieben.Die Transformation Unit InsertConstraint, S. 218 Abb.5.3.3, fügt einen Constraint ein. Dieser bestehtaus zwei Teilen, dem Kontext und dem Body, die mit den Transformation Units DefineContext, S. 109Abb.5.9, und InsertConstraintBody, S. 218 Abb.5.3.3, eingefügt werden. Diese fügen Invarianten, Vor-oder Nachbedingungen ein. Um einen definition-Constraint einzufügen, muss die Transformation UnitInsertDefinitionConstraint, S. 181 Abb.5.3.3, angewendet werden.Die entsprechenden Transformation Units wurden bereits beschrieben.

Zu allen Regeln und Transfomration Units der Graphgrammatik konnten Constraints aus der Spezifi-kation mit dem MOF-Ansatz angegeben werden. Diese Constraints schränken das Metamodell soweitein, dass die MOF-Spezifikation keine Sprachelemente erlaubt, die mit der Graphgrammatik zum Ty-pgraphen nicht gebildet werden können.

Kapitel 7

Schluss

7.1 Zusammenfassung

In dieser Arbeit wurde die VOCL anhand von Beispielen eingeführt. Dabei wurde zu jedem Beispieleine umgangssprachliche Beschreibung der ausgedrückten Bedingung sowie der entsprechende OCLConstraint aufgelistet. Die wesentlichen Konzepte der VOCL wurden bahandelt und anhand einesBeispiels zu einem leicht verständlichen UML Diagramm visualisiert. Zusätzlich ist im Anhang diegesamte VOCL Standard-Bibliothek, die eine Darstellung aller VOCL Ausdrücke und Operationenenthält, angegeben.In den Kapiteln 4 und 5 wurde die VOCL mit den beiden Hauptansätzen zur Definition der abstraktenSyntax einer visuellen Sprache formal definiert. Die Spezifikation mit dem Metamodellierungsansatzbesteht aus dem Metamodell der VOCL und den Constraints, die dieses Metamodell soweit einschrän-ken, dass nur noch Elemente der Sprache Instanzen des VOCL Metamodells sind. Hierbei handelt essich um einen deklarativen Ansatz zur Definition der Sprache, bei dem die Sprachelemente beschrie-ben werden. Das Metamodell wurde mit dem MOF Ansatz definiert, die Constraints sind in der OCLformuliert.Bei der Definition der Sprache mit dem Graphgrammatikansatz wurden der Typgraph und die Gram-matikregeln angegeben. Dies ist eine konstruktive Beschreibung der abstrakten Syntax der VOCL, beider die Sprachelemente mit den angegebenen Regeln aufgebaut werden. Es wurde getypte attributier-te Graphtransformation mit Knotentypvererbung verwendet. Außerdem wurden Transformation Unitsbenötigt, mit denen komplexe VOCL Ausdrücke wie Navigationen entlang von Pfaden eingefügt wer-den können. Diese waren erforderlich, da nach jeder Regelanwendung ein Elemenet der Graphspracheerzeugt werden muss, und die einzelnen Regelanwendungen, die in einer solchen Transformation Unitgekapselt wurden, ergeben Ausdrücke, die nicht in der VOCL enthalten sind.

Im Kapitel 6 wurden die beiden Sprachdefinitionen miteinander verglichen.Hierbei wurden zunächst das Metamodell und der Typgraph miteinander verglichen. Diese sind sichsehr ähnlich, die Kantentypen des Typgraphen können auf die Assoziationen des Metamodells unddie Knotentypen auf die Klassen des Metamodells abgebildet werden. Der Typgraph enthält einenabstrakten Knotentypen und drei Kantentypen, für die es keine Abbildung ins Metamodell gibt. Diesedienen der Vereinfachung der Regeln der Graphgrammatik. Im Metamodell waren keine entsprechen-den Klassen bzw. Assoziationen notwendig. Ansonsten gleichen sich Metamodell und Typgraph derVOCL (wenn man die Kardinalitäten aus dem Metamodell entfernt).Die Kardinalitäts-Constraints werden in den Regeln implizit abgebildet, d.h., abhängig von den Kardi-nalitäten gibt es unterschiedliche NACs bzw. positive Anwendungsbedingungen in den entsprechendenRegeln.Die restlichen OCL Constraints wurden informell mit den Regeln verglichen. D.h., jede Regel bzw.Transformation Unit wurde betrachtet, umgangssprachlich beschrieben und dann mit den entspre-chenden OCL Constraints der Metamodell-Spezifikation verglichen.Wie in der Einleitung von Kapitel 6 beschrieben, konnte man erwarten, dass die MOF-Beschreibungmehr erlaubt, als die Beschreibung mit der Graphgrammatik, da die Graphgrammatik das genaue

243

244 KAPITEL 7. SCHLUSS

Design der VOCL definiert. Das Ergebnis des Vergleichs ist allerdings, dass beide Ansätze dieselbeSprache beschreiben, also die Spezifikation mit dem MOF Ansatz genau so viel erlaubt, wie die Spezi-fikation mit dem Graphgrammatikansatz. Man sieht, dass die Spezifikation mit MOF wesentlich kürzerund kompakter ist als die Graphgrammatik. Daraus könnte man schließen, dass die Beschreibung derConstraints auch schneller durchführbar ist. Abgesehen davon, dass die Constraints nur textuell auf-geschrieben und nicht grafisch dargestellt werden (was automatisch zu einem größeren Zeitaufwandführt), würde ich nicht sagen, dass die MOF Spezifikation einen kleineren Zeitaufwand bedeutet. ImPrinzip müssen für die vollständige Formulierung der OCL Constraints dieselben Gedankengänge (alsodie theoretische Vorstellung, wie und in welcher Reihenfolge die Sprachelemente der VOCL erzeugtwerden können bzw. müssen) ausgeführt werden.Die MOF Definition ist übersichtlicher und schneller verständlich, die einschränkenden Bedingungenfür die Sprachelemente sind aus den Constraints leichter nachvollziehbar als aus den Regeln, bei denenhäufig eine ganze Transformation Unit betrachtet und verstanden werden muss, die aus einer Mengevon Regeln bestehen kann. Es war auch nicht ganz so einfach, die Regeln zu gliedern (häufig verwen-den die Transformation Units Regeln, die viele Seiten zuvor definiert wurden). Die Sprachdefinitionmit einer Graphgrammatik ist allerdings wesentlich näher an einer Implementation der Sprache undvereinfacht dadurch eine nachfolgende Implementierung stark.

7.2 Ausblick

In dieser Arbeit wurde die visuelle Sprache VOCL, die eine grafische Repräsentation der textuellenSprache OCL ist, beschrieben und ihre abstrakte Syntax formal definiert. Folgende weiterführendeArbeiten wären möglich:

• Entwicklung eines Editors zur Erstellung von VOCL ConstraintsHierzu ist zu sagen, dass im Rahmen eines Studentenprojekts an der TU Berlin (PJ VisuelleSprachen im SS 04) ein VOCL Editor entworfen und umgesetzt worden ist. Dieser ermöglicht dieErstellung von VOCL Constraints zu einem UML Klassendiagramm. Diese VOCL Constraintskönnen in textuelle OCL Constraints umgewandelt werden, die dieselbe Bedingung ausdrücken.Mit diesem Editor können allerdings nicht alle Konstrukte, die in der VOCL definiert sind,erstellt werden. Die Implementierung eines Editors, der die gesamte VOCL darstellen kann, wärein diesem Rahmen nicht möglich gewesen. Der vorhandene Editor könnte aber erweitert und zueiner eigenen vollständigen Diagrammart ausgebaut werden.Es ist auch vorstellbar, textuelle OCL Constraints in visuelle VOCL Constraints zu übersetzen,und dieses als Funktion eines Editors zu implementieren.

• Vergleich von OCL und VOCLEs erscheint sinnvoll, die entworfene Sprache VOCL mit OCL zu vergleichen. In den einleitendenKapiteln wurde beschrieben, dass der große Nachteil der OCL ihre textuelle Darstellung ist, dievor allem innerhalb der visuellen UML wenig Anwendung findet. Nun wäre herauszufinden, obdie VOCL diesen Nachteil tatsächlich beseitigt und zu einem “leichteren“ Verständnis und somitzu einer größeren Anwendung innerhalb der Systemspezifikation mit UML führt.

• Vergleich mit anderen VisualisierungenIn England wurde eine andere Visualisierung von OCL Constraints entwickelt. Bei einem Ver-gleich mit dieser Darstellung fiel auf, dass in der VOCL einige OCL Konstrukte nicht besondersintuitiv dargestellt sind. Dies gilt insbesondere für die Darstellung der Mengenoperationen. Au-ßerdem enthält die VOCL insgesamt immernoch relativ viele textuelle Bestandteile. Eine Ver-besserung der Mengenoperationen mit einer intuitiveren Darstellung wäre sinnvoll.

• Formale Spezifikation der konkreten Syntax der VOCLEine visuelle Sprache ist eine Sprache über einem visuellen Alphabet, welches aus Symbolenund Relationen besteht. Das Alphabet besteht aus einer abstrakten und einer konkreten Syntax.Die abstrakte Syntax beschreibt den prinzipiellen Aufbau der Sprache und ist ein Graph ausSymbolen und Relationen. Die konkrete Syntax beschreibt das konkrete Layout einer Sprache.

7.2. AUSBLICK 245

Sie besteht aus grafischen Symbolen und Layout-Constraints, die die Anordnung der Symbolefestlegen. Die konkrete Syntax erweitert die abstrakte um das spezifische Layout. Es gibt eineeindeutige Zuordnung von den Elementen der abstrakten Syntax auf Elemente der konkretenSyntax.Die konkrete Syntax der VOCL wurde in Kapitel 3 informell beschrieben. Es fehlt allerdings dieformale Definition des konkreten Layouts der VOCL.

246 KAPITEL 7. SCHLUSS

Anhang A

The VOCL Standard Library

A.1 OclAny and OclVoid

A.1.1 OclAny

• object = (object2: OclAny): Boolean

object: OclAny object: OclAny

Die Gleichheit zweier Objekte wird in VOCL dadurch ausgedrückt, dass sie denselben Namen haben.

• object <> (object2: OclAny): Boolean

object: OclAny object2: OclAny

Die Ungleichheit zweier Objekte wird in VOCL dadurch ausgedrückt, dass sie verschiedene Namenhaben.

• object.oclIsNew(): Boolean

object: OclAny {New}

oclIsNew() ist eine Operation auf einem Objekt des Typs OclAny. Sie kann nur in einer Nachbedingungverwendet werden und liefert true, wenn das Objekt während der Ausführung der Operation erstelltwurde. Die Operation wird wie in UML durch {New} nach dem Klassennamen visualisiert.

247

248 ANHANG A. THE VOCL STANDARD LIBRARY

• object.oclIsUndefined(): Boolean

object: OclAny

x = oclIsUndefined()

oclIsUndefined() liefert true, wenn das Objekt vom Typ OclUndefined ist. Die Operation wird durcheinen mit oclIsUndefined() beschrifteten Pfeil zum Objekt visualisiert.

A.1.2 OclMessage

• message.isSent(): Boolean

message: OclMessage

x = IsSent()

isSent() wird wie eine Operation auf ein Objekt visualisiert. Der Rückgabewert ist true, wenn eineMessage zum Ziel gesendet wurde.

• message.hasReturned(): Boolean

message: OclMessage

x = hasReturned()

hasReturned() liefert true, wenn die Message ein Operationsaufruf ist und diese Operation einen Wertzurückgegeben hat. Das impliziert, dass die Message gesendet wurde.

• message.result(): <‌<The return type of the called operation>‌>

message: OclMessage

x = result()

result() liefert das Ergebnis der aufgerufenenen Operation zurück.

• message.isSignalSent(): Boolean

message: OclMessage

x = isSignalSent()

isSignalSent() ergibt true, wenn die OclMessage ein gesendetes UML Signal repräsentiert. Das Signalwird wie eine Operation visualisiert.

A.2. MODELELEMENT TYPES 249

• message.isOperationCall(): Boolean

message: OclMessage

x = isOperationCall()

isOperationCall() liefert true, wenn die OclMessage einen gesendeten UML Operationsaufruf repräsen-tiert. Dies wird wie eine Operation visualisiert.

A.1.3 OclVoid

• OclUndefined.oclIsUndefined(): Boolean

object: OclVoid

x = oclIsUndefined()

oclIsUndefined() liefert true, wenn das Objekt vom Typ OclUndefined ist. Die Operation wird durcheinen mit oclIsUndefined() beschrifteten Pfeil zum Objekt visualisiert.

A.2 ModelElement Types

A.2.1 OclModelElement

• object = (object2: OclType): Boolean

object: OclModelElement object: OclType

Die Gleichheit zweier Objekte wird in VOCL dadurch ausgedrückt, dass sie denselben Namen haben.Sind sie unterschiedlichen Typs erfordert das ein Casting mit Hilfe der Operation oclAsType.

• object <> (object2: OclType): Boolean

object: OclModelElement object2: OclType


A.2.2 OclType

• object = (object2: OclType): Boolean

object: OclType object: OclType

Die Gleichheit zweier Objekte wird in VOCL dadurch ausgedrückt, dass sie denselben Namen haben.

• object <> (object2: OclType): Boolean


object: OclType object2: OclType


• oclIsTypeOf(t: OclType): Boolean

object:OclType

x = oclIsTypeOf(t)

Die Operation oclIsTypeOf() liefert true, wenn object vom Typ t ist. Die Operation wird durch einenPfeil zum Objekt visualisiert, der mit oclIsTypeOf(t) beschriftet ist.

• oclIsKindOf(t: OclType): Boolean

object:OclType

x = oclIsKindOf(t)

Die Operation oclIsKindOf(t) liefert true, wenn t der Typ oder ein Supertyp von object ist. Die Ope-ration wird durch einen Pfeil zum Objekt visualisiert, der mit oclIsKindOf(t) beschriftet ist.

• oclAsType(t: OclType): instance of OclType

object:OclType OclType

A.2.3 OclState

• object = (object2: OclState): Boolean

object: OclState object: OclState

Die Gleichheit zweier Objekte vom Typ OclState wird in VOCL dadurch ausgedrückt, dass sie densel-ben Namen haben.

• object <> (object2: OclState): Boolean

object: OclState object2: OclState

Die Ungleichheit zweier Objekte vom Typ OclState wird in VOCL dadurch ausgedrückt, dass sieverschiedene Namen haben.

• oclInState(s: OclState):Boolean

A.3. PRIMITIVE TYPES 251

object: OclState

s

Die Operation oclInState(object) liefert true, wenn das Objekt im Zustand s ist. s ist der Name einesZustandes in einem Zusatandsdiagramm. Dass eine Instanz in einem bestimmten Zustand ist, wirdvisualisiert, indem der Zustand unter Namen und Typ des Objekts dargestellt wird, wo sonst dieAttribute eines Objektes dargestellt werden können. Der Name des Zustands steht innerhalb einesabgerundeten Rechtecks. Wenn es sich um einen Unterzustand handelt, wird dieser innerhalb desübergeordneten Zustands dargestellt, dessen Name dann auch innerhalb eines Rechtecks steht.

A.3 Primitive Types

A.3.1 Real, Integer and String

Die Standarddatentypen Real und Integer repräsentieren die mathematischen Konzepte der reellen undganzen Zahlen und deren Eigenschaften. String repräsentiert Zeichenketten und deren Eigenschaften.Da sie nur textuell innerhalb eines Constraints verwendet werden, werden sie nicht visualisiert.

A.3.2 Boolean

Dieser Typ kann sowohl visualiert, als auch textuell in dem Bedingungsteil eines Constraints verwendetwerden. Im folgenden wird immer die textuelle Darstellung, gefolgt von der visuellen, angegeben.

• b or (b2: Boolean): Boolean

b2: Boolean b: Boolean or b2: Boolean

b: Boolean

or

Eine Verknüpfung zweier Teilausdrücke durch or wird durch einen eigenen Or-Rahmen dargestellt, dieAussagen links und rechts, bzw. ober- und unterhalb vom or werden miteinander ”verodert”.

• b xor (b2: Boolean): Boolean

b2: Boolean b: Boolean xor b2: Boolean

b: Boolean

xor

Eine Verknüpfung zweier Teilausdrücke durch xor wird durch einen eigenen Xor-Rahmen dargestellt,die Aussagen links und rechts, bzw. ober- und unterhalb vom xor werden miteinander ”verxodert”.

• b and (b2: Boolean): Boolean


b2: Boolean b: Boolean b2: Boolean

b: Boolean

Eine Verknüpfung zweier Teilausdrücke durch and wird durch nicht explizit dargestellt, nebeneinanderbzw. untereinander stehende Aussagen werden automatisch durch eine and Operation miteinanderverknüft.

• not b: Boolean

b: Boolean

Die Negation einer Aussage wird durch einen eigenen Not-Rahmen dargestellt, die Aussage inner-halb des Rahmens wird negiert.

• b implies (b2: Boolean): Boolean

b: Boolean

b2: Boolean

implies

Ein Implies-Ausdruck wird in einem Implies-Rahmen visualisiert. Alles über dem implies beschreibtdie Prämisse, die, wenn sie erfüllt ist, den unteren Teil impliziert.

A.4 Collection-Related Types

A.4.1 Collection

Dieser Abschnitt enthält alle Operationen, die auf jeden der Collection-Typen, d.h. Set, Bag undSequence angewendet werden können. In dem jeweiligen Fall muss der Rahmen für Collection durchden Rahmen des jeweiligen Typs ersetzt werden.

• collection->size(): Integer

#n collection:Collection

Der size-Operator wird auf eine Collection angewendet. In der Varablen n steht die Anzahl der Ele-mente, die sich in der Collection befinden. Die Operation wird durch eine gestrichelt Box visualisiert,in der #n steht.

• collection->includes(object: T): Boolean

collection:Collection(T)

object:T

A.4. COLLECTION-RELATED TYPES 253

Dass das Objekt object in der Collection collection enthalten ist, wird durch einen Link zwischen objectund collection dargestellt, an dem ∈ steht.

• collection->excludes(object: T): Boolean


object:T

Dass das Objekt object nicht in der Collection collection enthalten ist, wird durch einen Link zwischenobject und collection dargestellt, an dem /∈ steht.

• collection->count(object: T): Integer

#object = x

object:T


Die Operation count() gibt zurück, wie oft das Objekt object in der Collection colletion enthaltenist. In der Varablen x steht der Ergebniswert. Diese Operation wird durch eine gestrichelte Box mit#object=x unten rechts an der Collectiondarstellung visualisiert.

• collection-> includesAll(c2: Collection(T)): Boolean


c2:Collection(T)

Dass die Collection c2 in der Collection collection enthalten ist, wird durch einen Link zwischen objectund collection dargestellt, an dem ⊆ steht.

• collection->excludesAll(c2: Collection(T)): Boolean


c2:Collection(T)

Dass die Collection c2 nicht in der Collection collection enthalten ist, wird durch einen Link zwischenobject und collection dargestellt, an dem * steht.

• collection->isEmpty(): Boolean

= 0 collection:Collection

Die Operation isEmpty() drückt aus, dass in der Collection colletion kein Element enthalten ist. DieseOperation wird durch eine gestrichelte Box mit = ∅ unten rechts an der Collectiondarstellung visuali-siert.


• collection->notEmpty(): Boolean

= 0 collection:Collection

Die Operation isEmpty() drückt aus, dass in der Collection colletion kein Element enthalten ist. Die-se Operation wird durch eine gestrichelte Box mit =6= ∅ unten rechts an der Collectiondarstellungvisualisiert.

• collection->sum(): T

collection:Collection x = y

Die Operation sum() summiert die Werte aller Elemente in einer Collection auf. Hierzu wird in ei-ner gestrichelten Box unten rechts an der Collection

∑x = y notiert. In der Varablen y steht der

Ergebniswert, x beschreibt das zu summierende Element.

In den folgenden Abschnitten sind die Operationen, die für den jeweiligen Collection-Typ typisch sindbzw. die nicht für alle drei Typen gelten, visualisiert.

A.4.2 Set

• set->union(set2: Set(T)): Set(T)

U

x:T

set2:T set:T

Die Vereinigung zweier Sets wird durch einen Rahmen dargestellt, in dem oben links der Name desresultierenden Sets steht. Die beiden Sets innerhalb des Rahmens werden miteinander vereinigt, wasdurch das mathematische Vereinigungszeichen innerhalb einer gestrichelten Box unten rechts am Rah-men dargestellt wird.

• set->union(bag: Bag(T)): Bag(T)

U bag:T

x:T

set:T

Die Vereinigung eines Sets und eines Bags wird durch einen Rahmen dargestellt, in dem oben links derName des resultierenden Bags steht. Das Set und der Bag innerhalb des Rahmens werden miteinandervereinigt, was durch das mathematische Vereinigungszeichen innerhalb einer gestrichelten Box untenrechts am Rahmen dargestellt wird.


• set = (set2: Set(T)): Boolean

set:T set:T

Die Gleichheit zweier Sets wird in VOCL dadurch ausgedrückt, dass sie denselben Namen haben.

• set->intersection(set2: Set(T)): Set(T)

U

x:T

set2:T set:T

Die Schnittmenge zweier Sets wird durch einen Rahmen dargestellt, in dem oben links der Name desresultierenden Sets steht. Die beiden Sets innerhalb des Rahmens werden miteinander geschnitten,was durch das mathematische Schnittmengenzeichen innerhalb einer gestrichelten Box unten rechtsam Rahmen dargestellt wird.

• set->intersection(bag: Bag(T)): Set(T)

U bag:T

x:T

set:T

Die Schnittmenge eines Sets und eines Bags wird durch einen Rahmen dargestellt, in dem oben links derName des resultierenden Sets steht. Das Set und der Bag innerhalb des Rahmens werden miteinandergeschnitten, was durch das mathematische Schnittmengenzeichen innerhalb einer gestrichelten Boxunten rechts am Rahmen dargestellt wird.

• set-(set2: Set(T)): Set(T)

diff(set2)

set:T set2:T

:T

Die Differenz zweier Sets ergibt ein Set, liefert also einen komplexen Ergebnistyp. Diese Operation wirddurch einen mit diff(set2) beschrifteten Pfeil zum Set set und einen Pfeil vom Set set zum Ergebnis-Setdargestellt.


• set->including(object: T): Set(T)

including(object)

set:T object:T

:T

Die Operation including(object) vereinigt ein Set set mit dem Objekt object und ergibt ein Set. DieseOperation wird durch einen mit including(object) beschrifteten Pfeil zum Set set und einen Pfeil vomSet set zum Ergebnis-Set dargestellt.

• set->excluding(object: T): Set(T)

excluding(object)

set:T object:T

:T

Die Operation excluding(object) entfernt aus einem Set set ein Objekt object und ergibt ein Set. DieseOperation wird durch einen mit excluding(object) beschrifteten Pfeil zum Set set und einen Pfeil vomSet set zum Ergebnis-Set dargestellt.

• set->symmetricDifference(set2: Set(T)): Set(T)

set2:T

x:T

set:T XOR

Die symmetrische Differenz zweier Sets wird durch einen Rahmen dargestellt, in dem oben links derName des resultierenden Sets steht. Die Operation wird durch XOR innerhalb einer gestrichelten Boxunten rechts am Rahmen dargestellt.

• set->count(object: T): Integer


#object = x set:T

object:T

Die Operation count(object) gibt zurück, wie oft das Objekt object im Set set enthalten ist. In derVarablen x steht der Ergebniswert. Diese Operation wird durch eine gestrichelte Box mit #object=xunten rechts am Set visualisiert.

• set->flatten(): Set(T2)

set:T

flatten()

:T2

Die Operation flatten() auf ein Set angewandt ergibt ein Set, das eventuell Elemente eines anderenTyps enthält als das Set selbst und wird durch einen mit flatten() beschrifteten Pfeil zum Set set undeinen Pfeil vom Set set zum resultierenden Set dargestellt

• set->asSet(): Set(T)

Die Operation asSet() auf ein Set angewandt ergibt dasselbe Set und wird in VOCL nicht dargestellt.

• set->asSequence(): Sequence(T)

asSequence()

:T

set:T

Die Operation asSequence() ergibt eine Sequence und wird durch einen Pfeil beschriftet mit asSe-quence() zum Set set und einen Pfeil vom Set set zur resultierenden Sequence dargestellt.

• set->asBag(): Bag(T)


asBag()

:T

set:T

Die Operation asBag() ergibt einen Bag und wird durch einen Pfeil beschriftet mit asBag() zum Setset und einen Pfeil vom Set set zum resultierenden Bag dargestellt.

A.4.3 Bag

• bag = (bag2: Bag(T)): Boolean

bag:T bag:T

Die Gleichheit zweier Bags wird in VOCL dadurch ausgedrückt, dass sie denselben Namen haben.

• bag->union(bag2: Bag(T)): Bag(T)

U

x:T

bag2:T bag:T

Die Vereinigung zweier Bags wird durch einen Rahmen dargestellt, in dem oben links der Name desresultierenden Bags steht. Die beiden Bags innerhalb des Rahmens werden miteinander vereinigt,was durch das mathematische Vereinigungszeichen innerhalb einer gestrichelten Box unten rechts amRahmen dargestellt wird.

• bag->union(set: Set(T)): Bag(T)

U

x:T

set:T bag:T

Die Vereinigung eines Bags und eines Sets wird durch einen Rahmen dargestellt, in dem oben links derName des resultierenden Sets steht. Der Bag und das Set innerhalb des Rahmens werden miteinandervereinigt, was durch das mathematische Vereinigungszeichen innerhalb einer gestrichelten Box untenrechts am Rahmen dargestellt wird.


• bag->intersection(bag2: Bag(T)): Bag(T)

x:T

bag2:T bag:T U

Die Schnittmenge zweier Bags wird durch einen Rahmen dargestellt, in dem oben links der Name desresultierenden Bags steht. Die beiden Bags innerhalb des Rahmens werden miteinander geschnitten,was durch das mathematische Schnittmengenzeichen innerhalb einer gestrichelten Box unten rechts amRahmen dargestellt wird.

• bag->intersection(set: Set(T)): Set(T)

x:T

set:T bag:T U

Die Schnittmenge eines Bags und eines Sets wird durch einen Rahmen dargestellt, in dem oben links derName des resultierenden Sets steht. Der Bag und das Set innerhalb des Rahmens werden miteinandergeschnitten, was durch das mathematische Schnittmengenzeichen innerhalb einer gestrichelten Boxunten rechts am Rahmen dargestellt wird.

• bag->including(object: T): Bag(T)

including(object)

bag:T object:T

:T

Die Operation including(object) vereinigt einen Bag bag mit dem Objekt object und ergibt ein Bag.Diese Operation wird durch einen mit including(object) beschrifteten Pfeil zum Bag bag und einen Pfeilvon bag zum Ergebnis-Bag dargestellt.

• bag->excluding(object: T): Bag(T)


excluding(object)

bag:T object:T

:T

Die Operation excluding(object) entfernt aus einem Bag bag das Objekt object und ergibt ein Bag.Diese Operation wird durch einen mit excluding(object) beschrifteten Pfeil zum Bag bag und einenPfeil von bag zum Ergebnis-Bag dargestellt.

• bag->count(object: T): Integer

#object = x bag:T

object:T

Die Operation count(object) gibt zurück, wie oft das Objekt object im Bag bag enthalten ist. In derVarablen x steht der Ergebniswert. Diese Operation wird durch eine gestrichelte Box mit #object=xunten rechts am Bag visualisiert.

• bag->flatten(): Bag(T2)

bag:T

flatten()

:T2

Die Operation flatten() auf einen Bag angewandt ergibt einen Bag, das eventuell Elemente eines an-deren Typs enthält als der Bag selbst und wird durch einen mit flatten() beschrifteten Pfeil zum Bagbag und einen Pfeil vom Bag bag zum resultierenden Bag dargestellt

• bag->asBag(): Bag(T)

Die Operation asBag() auf einen Bag angewandt ergibt denselben Bag und wird in VOCL nicht dar-gestellt.

• bag->asSequence(): Sequence(T)


bag:T

asSequence()

:T

Die Operation asSequence() ergibt eine Sequence und wird durch einen Pfeil beschriftet mit asSe-quence() zum Bag bag und einen Pfeil vom Bag bag zur resultierenden Sequence dargestellt.

• bag->asSet(): Set()

bag:T

asSet()

:T

Die Operation asSet() ergibt ein Set und wird durch einen Pfeil beschriftet mit asSet() zum Bag bagund einen Pfeil vom Bag bag zum resultierenden Set dargestellt.

A.4.4 Sequence

• sequence->count(object: T): Integer

sequence:T

object:T

#object = x

Die Operation count() gibt zurück, wie oft das Objekt object in der Sequence sequence enthalten ist. Inder Varablen x steht der Ergebniswert. Diese Operation wird durch eine gestrichelte Box mit #object=xunten rechts an der Sequence visualisiert.

• sequence = (sequence2: Sequence(T)): Boolean

sequence:T sequence:T

Die Gleichheit zweier Sequenzen wird in VOCL dadurch ausgedrückt, dass sie denselben Namen haben.

• sequence->union(sequence2: Sequence(T)): Sequence(T)


union(sequence2)

sequence:T sequence2:T

:T

union(sequence2) returns a sequence consisting of all elements in the sequence sequence followed byall elements in the sequence sequence2, represented by an arrow labeled by union(sequence2) from theoriginal sequence sequence to the resulting sequence sequence2.

• sequence->flatten(): Sequence(T2)

sequence:T

flatten()

:T2

Die Operation flatten() auf eine Sequence angewandt ergibt eine Sequence, die eventuell Elemente einesanderen Typs enthält als die Sequence selbst und wird durch einen mit flatten() beschrifteten Pfeil zurSequence sequence und einen Pfeil von sequence zur resultierenden Sequence dargestellt.

• sequence->append(object: T): Sequence(T)

sequence:T object:T

append(object:T)

:T

Die Operation append(object) hängt das Objekt object an das Ende der Sequence sequence an undergibt eine Sequence. Diese Operation wird durch einen mit append(object) beschrifteten Pfeil zurSequence sequence und einen Pfeil von sequence zur resultierenden Sequence dargestellt.

• sequence->prepend(object: T): Sequence(T)


sequence:T object:T

prepend(object:T)

:T

Die Operation prepend(object) hängt das Objekt object an den Anfang der Sequence sequence an undergibt eine Sequence. Diese Operation wird durch einen mit prepend(object) beschrifteten Pfeil zurSequence sequence und einen Pfeil von sequence zur resultierenden Sequence dargestellt.

• sequence->subSequence(lower: Integer, upper: Integer): Sequence(T)

sequence:T

subSequence(x: Integer,y: Integer)

:T

Die Operation subSequence(x, y) ergibt eine Sequence, die alle Objekte zwischen den Indizes x undy aus der Ursprungs-Sequence beinhaltet. Diese Operation wird durch einen mit subSequence(x, y)beschrifteten Pfeil zur Sequence sequence und einen Pfeil von sequence zur resultierenden Sequencedargestellt.

• sequence->at(i: Integer): T

sequence:T

:T

at(i: Integer)

Die Operation at(i) wird auf eine Sequence angewendet und gibt das Element am Index i zurück. DieseOperation wird durch einen mit at(i) beschrifteten Pfeil zur Sequence sequence und einen Pfeil vonsequence zum resultierenden Element dargestellt.

• sequence->first(): T


sequence:T

:T

first()

Die Operation first() gibt das erste Element der Sequence zurück. Diese Operation wird durch einenmit first() beschrifteten Pfeil zur Sequence sequence und einen Pfeil von sequence zum resultierendenElement dargestellt.

• sequence->last(): T

sequence:T

:T

last()

Die Operation last() gibt das letzte Element der Sequence zurück. Diese Operation wird durch einenmit last() beschrifteten Pfeil zur Sequence sequence und einen Pfeil von sequence zum resultierendenElement dargestellt.

• sequence->including(object: T): Sequence(T)

including(object)

sequence:T object:T

:T

Die Operation including(object) vereinigt eine Sequence sequence mit dem Objekt object und ergibteine Sequence. Diese Operation wird durch einen mit including(object) beschrifteten Pfeil zur Sequencesequence und einen Pfeil von sequence zur resultierenden Sequence dargestellt.

• sequence->excluding(object: T): Sequence(T)


excluding(object)

sequence:T object:T

:T

Die Operation excluding(object) entfernt aus einer Sequence sequence ein Objekt object und ergibteine Sequence. Diese Operation wird durch einen mit excluding(object) beschrifteten Pfeil zur Sequencesequence und einen Pfeil von sequence zur resultierenden Sequence dargestellt.

• sequence->asBag(): Bag(T)

sequence:T

asBag()

:T

Die Operation asBag() ergibt einen Bag und wird durch einen Pfeil beschriftet mit asBag() zur Se-quence sequence und einen Pfeil von sequence zum resultierenden Bag dargestellt.

• sequence->asSequence(): Sequence(T)

Die Operation asSequence() auf eine Sequence angewandt ergibt dieselbe Sequence und wird in VOCLnicht dargestellt.

• sequence->asSet(): Set(T)

sequence:T

asSet()

:T

Die Operation asSet() ergibt ein Set und wird durch einen Pfeil beschriftet mit asSet() zur Sequencesequence und einen Pfeil von sequence zum resultierenden Set dargestellt.


A.5 Predefined OclIterator Library

A.5.1 Collection

Die folgenden Operation gelten für alle Collection-Typen. Der Typ der Elemente der jeweiligen Collec-tion ist T. Der Collection-Rahmen muss durch einen Rahmen des jeweiligen konkreten Collectiontypsersetzt werden.

• Collection(T)->iterate(i: T; acc: T2; expression: OclExpression):Boolean

:Collection(T)

iterate

i

i:T acc

acc:T2 {New}

acc:T2

Die Iterate-Operation wird auf eine Collection angewendet und hat einen Iterator, einen Akkumulatorund einen Body. Der Body enthält einen VOCL Ausdruck, der beschreibt welche Werte der Elementeder Collection akkumuliert werden sollen. Die iterate-Operation wird durch einen Rahmen visuali-siert, der aus zwei Teilen besteht, die durch eine Linie voneinander getrennt sind. Links steht dieInitialisierung der Akkumulatorvariable, rechts der Ausdruck des Bodys. Am rechten Rand stehen derAkkumulatorname, der Iteratorname und das Schlüsselwort iterate jeweils innerhalb einer gestricheltenBox. Der Rahmen, in dem der Body dargestellt wird, ist durch eine Linie mit der Collection verbunden.In der oben dargestellten Abbildung wird die Akkumulatorvariable acc mit einer neu erstellten Instanzinitialisiert, ihr initialer Wert kann aber grundsätzlich ein allgemeiner VOCL Ausdruck sein. Das Er-gebnis der Iterate-Operation ist der Akkumulator acc. Die Operationen exists, forall, select, reject undcollect können auch mit einer Iterate-Operation ausgedrückt werden.Wenn der zu akkumulierende Wert nur ein Attributwert der Collectionelemente ist, kann die folgendeKurzform der iterate-Operation verwendet werden. Diese Darstellung impliziert, dass die Akkumula-torvariable mit einer neu erstellten Instanz initialisiert wurde.

• Collection(T)->iterate(i: T; acc: T2; expression: OclExpression):Boolean

iterate

acc

acc:T2

: T

attr=acc

A.5. PREDEFINED OCLITERATOR LIBRARY 267

• Collection(T)->exists(expression: OclExpression):Boolean

:Collection(T)

i

i:T

Die Exists-Operation wird auf eine Collection angewendet und hat einen Iterator und einen Body.Der Ausdruck des Bodys wird in einem Rahmen visualisiert, an dessen rechten Rand der Iteratorund der ∃-Operator in gestrichelten Boxen notiert werden. Dieser Rahmen ist durch eine Linie mitder Collection verbunden. Der Rückgabewert dieser Operation ist vom Typ Boolean, die Bedingungenim Body müssen für mindestens ein Element in der Collection erfüllt sein. Innerhalb des Rahmenskönnen dann weitere Bedingungen für die Objekte der Collection visualisiert werden, er kann einenBedingungsteil enthalten. Bei dieser Iteratoroperation wird das Ergebnis nicht explizit dargestellt, esmuss true sein.Auch diese Operation hat eine Kurzform, wenn sich der Ausdruck im Body nur auf Attributwerte derCollectionelemente bezieht:

:Collection(T) a1= ... a2 > ...

Die Bedingungen, die für die Attributwerte gelten müssen, werden dann im Attributteil mit Hilfe vonAttributoperationen dargestellt. In dieser Darstellung kann der Name der Iteratorvariablen weggelassenwerden. Der Operationsname wird direkt an der Collectiondarstellung notiert.

• Collection(T)->forall(expression: OclExpression):Boolean

i, j

:Collection(T)

i:T j:T

Die Forall -Operation wird auf eine Collection angewendet und hat einen oder zwei Iteratoren und einenBody. Der Ausdruck des Bodys wird in einem Rahmen visualisiert, an dessen rechten Rand der/dieIterator/en und der forall-Operator notiert in gestrichelten Boxen werden. Dieser Rahmen ist durcheine Linie mit der Collection verbunden. Der Rückgabewert dieser Operation ist vom Typ Boolean, dieBedingungen im Body müssen für alle Elemente in der Collection erfüllt sein. Innerhalb des Rahmenskönnen dann weitere Bedingungen für die Objekte der Collection visualisiert werden, er kann einenBedingungsteil enthalten. Bei dieser Iteratoroperation wird das Ergebnis nicht explizit dargestellt, esmuss true sein.Auch diese Operation hat eine Kurzform, wenn sich der Ausdruck im Body nur auf Attributwerte der


Collectionelemente bezieht und nur einen Iterator hat, die Darstellung ist wie bei der Exists-Operation(mit dem forall-Operator).

• Collection(T)->isUnique(expression: OclExpression):Boolean

isUnique

:Collection(T)

i:T

i

Die isUnique-Operation wird auf eine Collection angewendet und hat einen Iterator und einen Body.Der Ausdruck des Bodys wird in einem Rahmen visualisiert, an dessen rechten Rand der Iterator unddas Schlüsselwort isUnique in gestrichelten Boxen notiert werden. Der Rückgabewert dieser Operationist vom Typ Boolean, die Bedingungen im Body müssen für alle Elemente in der Collection eindeutigsein. Auch bei dieser Iteratoroperation wird das Ergebnis nicht explizit dargestellt, es muss true sein,und es gibt eine Kurzform, wenn sich der Ausdruck im Body nur auf Attributwerte der Collectionele-mente bezieht.

• Collection(T)->sortedBy(x:T2):Collection(T)

sortedBy

:Collection(T)

i:T

i

:Collection(T)

Die sortedBy-Operation wird auf eine Collection angewendet und hat einen Iterator und einen Body.Der Ausdruck des Bodys wird in einem Rahmen visualisiert, an dessen rechten Rand der Iterator undsortedBy in gestrichelten Boxen notiert werden. Die Elemente der Collection werden nach dem Iteratorsortiert und die sortierte Collection wird zurückgegeben. Im Allgemeinen ist der Rückgabetyp eineSequence.Die Kurzform:

sortedBy

:Collection(T)

:Collection(T) a1

• Collection(T)->any(expression: OclExpression):T


: T

any

:Collection(T)

i:T

i

Die any-Operation wird auf eine Collection angewendet und hat einen Iterator und einen Body. DerAusdruck des Bodys wird in einem Rahmen visualisiert, an dessen rechten Rand der Iterator und any ingestrichelten Boxen notiert werden. Any liefert irgendein Objekt der Collection, das die Bedingungendes Bodys erfüllt.Auch diese Operation hat eine Kurzform, wenn sich der Ausdruck im Body nur auf Attributwerte derCollectionelemente bezieht, die Darstellung ist in der folgenden Abbildung zu sehen.

: T

any

:Collection(T) a1= ... a2 > ...

• Collection(T)->one(expression: OclExpression):Boolean

= 1

:Collection(T)

i:T

i

Die one-Operation wird auf eine Collection angewendet und hat einen Iterator und einen Body. DerAusdruck des Bodys wird in einem Rahmen visualisiert, an dessen rechten Rand der Iterator und dasSchlüsselwort =1 in gestrichelten Boxen notiert werden. Der Rückgabewert dieser Operation ist vomTyp Boolean, die Bedingungen im Body müssen von genau einem Element der Collection erfüllt sein.Auch bei dieser Iteratoroperation wird das Ergebnis nicht explizit dargestellt, es muss true sein undes gibt eine Kurzform, wenn sich der Ausdruck im Body nur auf Attributwerte der Collectionelementebezieht.

• Collection(T)->collect(expression: OclExpression):Collection(T2)


collect

:Collection(T)

i:T

i

:Collection(T2)

Die collect-Operation wird auf eine Collection angewendet und hat einen Iterator und einen Body. DerAusdruck des Bodys wird in einem Rahmen visualisiert, an dessen rechten Rand der Iterator und collectin gestrichelten Boxen notiert werden. Alle Elemente, die die im Body dargestellten Eigenschaftenerfüllen, werden selektiert und als Collection zurückgegeben. Es gibt eine Kurzform, wenn sich derBody nur auf Attributwerte bezieht:

collect

:Collection(T2)

:Collection(T) a1

Nun folgen die Operationen, die für den jeweiligen Typ gelten, bzw. voneinander abweichende Ergeb-nisse besitzen.Alle diese Operationen visualisieren die Eigenschaften des Bodys in einem eigenen Rahmen und habenKurzformen, wenn sie sich nur auf Attributwerte beziehen.

A.5.2 Set

• Set(T)->select(expression: OclExpression)->Set(T)

select

:T

i:T

i

:T

Die Select-Operation liefert eine Untermenge des Sets, deren Elemente bestimmte Eigenschaften haben.Diese Selektionseigenschaften werden im Select-Rahmen spezifiziert, an dessen Rand stehen der Iteratorund das Schlüsselwort select in gestrichelten Boxen. Die Auswertung des Selektionsausdrucks liefert


eine Menge vom Typ T. In obiger Darstellung wurde auch die Rückgabe-Collection (in diesem Fallein Set) visualisert, worauf in den folgenden Visualisierungen zwecks besserer Übersichtlichkeit undleichterem Verständnis der grafischen Darstellungen verzichtet wird. Auch für die Select-Operationgibt es eine Kurzform, wenn die Selektionseigenschaften sich nur auf Attributwerte der Elemente desSets beziehen:

select

:T a1= ... a2 > ...

:T

• Set(T)->reject(expression: OclExpression)->Set(T)

reject

:T

i:T

i

:T

Die Reject-Operation liefert eine Untermenge des Sets, deren Elemente bestimmte Eigenschaften nichthaben. Diese Selektionseigenschaften werden im Reject-Rahmen spezifiziert, an dessen Rand stehen derIterator und das Schlüsselwort reject in gestrichelten Boxen. Die Auswertung des Selektionsausdrucksliefert eine Menge vom Typ T. Auch für die Select-Operation gibt es eine Kurzform, deren Darstellunganalog zu der der Select-Operation ist.

• Set(T)->collectNested(expression: OclExpression)->Bag(T2)

collect

:T

:T

x

:T2


Die Operation collectNested wird wie die Collect-Operation visualisiert. Der Rückgabewert ist bei derAnwendung auf ein Set ein Bag. Die Darstellung einer Kurzform ist analog zu den vorherigen.

A.5.3 Bag

• Bag(T)->select(expression: OclExpression):Bag(T)

:T

select

i:T

i

:T

Die Select-Operation liefert eine Untermenge des Bags, dessen Elemente bestimmte Eigenschaftenhaben. Diese Selektionseigenschaften werden im Select-Rahmen spezifiziert, an dessen Rand stehen derIterator und das Schlüsselwort select in gestrichelten Boxen. Die Auswertung des Selektionsausdrucksliefert einen Bag vom Typ T. Die Darstellung einer Kurzform ist analog zu den vorherigen.

• Bag(T)->reject(expression: OclExpression):Bag(T)

:T

reject

i:T

i

:T

Die Reject-Operation liefert eine Untermenge des Bags, dessen Elemente bestimmte Eigenschaften nichthaben. Diese Selektionseigenschaften werden im Reject-Rahmen spezifiziert, an dessen Rand stehen derIterator und das Schlüsselwort reject in gestrichelten Boxen. Die Auswertung des Selektionsausdrucksliefert einen Bag vom Typ T. Die Darstellung einer Kurzform ist analog zu den vorherigen.


• Bag(T)->collectNested(expression: OclExpression):Bag(T2)

:T

collect

:T

x

:T2

Die Operation collectNested wird wie die Collect-Operation visualisiert. Der Rückgabewert ist bei derAnwendung auf einen Bag ein Bag. Die Darstellung einer Kurzform ist analog zu den vorherigen.

A.5.4 Sequence

• Sequence(T)->select(expression: OclExpression): Sequence(T)

:T

select

i:T

i

:T

Die Select-Operation liefert eine Untermenge der Sequence, dessen Elemente bestimmte Eigenschaftenhaben. Diese Selektionseigenschaften werden im Select-Rahmen spezifiziert, an dessen Rand stehen derIterator und das Schlüsselwort select in gestrichelten Boxen. Die Auswertung des Selektionsausdrucksliefert eine Sequence vom Typ T. Die Darstellung einer Kurzform ist analog zu den vorherigen.

• Sequence(T)->reject(expression: OclExpression): Sequence(T)


:T

reject

i:T

i

:T

Die Reject-Operation liefert eine Untermenge der Sequence, deren Elemente bestimmte Eigenschaf-ten nicht haben. Diese Selektionseigenschaften werden im Reject-Rahmen spezifiziert, an dessen Randstehen der Iterator und das Schlüsselwort reject in gestrichelten Boxen. Die Auswertung des Selek-tionsausdrucks liefert eine Sequence vom Typ T. Die Darstellung einer Kurzform ist analog zu denvorherigen.

• Sequence(T)->collectNested(expression: OclExpression): Sequence(T2)

:T

collect

:T

x

:T2

Die Operation collectNested wird wie die Collect-Operation visualisiert. Der Rückgabewert ist beider Anwendung auf eine Sequence eine Sequence. Die Darstellung einer Kurzform ist analog zu denvorherigen.


Kurzformen

Nach der Anwendung einer Iterator-Operation, die eine Collection als Ergebnis hat, kann eine weitereCollection-Operation (isEmpty(), notEmpty() oder size()) auf das Ergebnis angewendet werden. Dafürgibt es eine Kurzform, die den Namen des zweiten Operation in einer gestrichelten Box unter die Boxender vorangegangenen Operation darstellt:

select

isIn

:T

i:T i

= 0


Literaturverzeichnis

[1] P. Bottoni, M. Koch, F. Parisi-Presicce, and G. Taentzer. A Visualization of OCL using Collabo-rations. In UML 2001 – The Unified Modeling Language, LNCS 2185, pages 257 – 271. Springer,2001.

[2] OCL 2.0 http: // www. klasse. nl/ ocl , 2002.

[3] Unified Modeling Language – version 1.4, 2002. Available athttp://www.omg.org/technology/documents/formal/uml.htm

[4] Meta Object Facility – version 1.4 , 2002. Available at http://www.omg.org/

[5] Model Driven Architecture , 2000. Available at http://www.omg.org/mda/

[6] Anneke Kleppe and J. Warmer. The Objet Constraint Language – Getting Your Models ReadyFor MDA. Addison-Wesley,

[7] Bardohl,R., Ehrig,H., de Lara,J., Runge,O., Taentzer,G., Weinhold,I. 2003 . Node Type Inheri-tance Concet for Typed Graph Transformation. Technical Report 2003-19, TU Berlin

[8] Kuske, S. Transformation Units – A Structural Principle for Graph Transformation SystemsDissertation, Universität Bremen, 2000.

[9] Definition visuelle Sprache:. VL Visuelle Programmiersprachen von Prof. Dr.Andy Schürr, an der Universität der Bundeswehr, München, Available athttp://ist.unibw-muenchen.de/Lectures/VL/

[10] Definition des Begriffs Sprache: http://de.wikipedia.org/wiki/Sprache

[11] Definition des Begriffs visuell:http://www.swe.uni-linz.ac.at/people/schiffer/se-96-19/se-96-19.htm

[12] Definition des Begriffs visuelle Sprache:. (http://www.software-kompetenz.de/?19701

[13] B. Myers: Taxonomies of Visual Programming and Program Visualization. In Journal of VisualLanguages and Computing, Vol. 1, No. 1, S. 97-123, 1990

[14] M. Petre, A. Blackwell, T. Green: Cognititve Questions in Software Visualization. In J. Stasko, J.Domingue, M. Brown, B. Price (Hrsg.): Software Visualization – Programming as a MultimediaExperience, S. 453-480, MIT Press, Cambridge, MA, 1998

[15] S. Schiffer: Visuelle Programmierung – Potential und Grenzen. In H. Mayr (Hrsg.): Beherrschungvon Informationssystemen, S. 267-286, Oldenbourg Verlag, Wien, 1996

[16] J. Larkin, H. Simon: Why a Diagram is (Sometimes) Worth Ten Thousands Words. In CognitiveScience Journal, Vol. 11, No. 1, S. 65-99, 1987

277

http://www.klasse.nl/ocl

http://www.omg.org/technology/documents/formal/uml.htm

http://www.omg.org/

http://www.omg.org/mda/

http://ist.unibw-muenchen.de/Lectures/VL/

http://de.wikipedia.org/wiki/Sprache

http://www.swe.uni-linz.ac.at/people/schiffer/se-96-19/se-96-19.htm

Spezi˝kation von Visual OCL: Eine Visualisierung der Object Constraint Language · 2005. 3. 4. · Sie stellt verschiedene Diagrammarten zur Darstellung bzw. De˝nition von Strukturen

Documents