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
12 KAPITEL 2. GRUNDLAGEN
<<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.
14 KAPITEL 2. GRUNDLAGEN
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
16 KAPITEL 2. GRUNDLAGEN
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()
18 KAPITEL 2. GRUNDLAGEN
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.
20 KAPITEL 2. GRUNDLAGEN
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:
22 KAPITEL 2. GRUNDLAGEN
– 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.
24 KAPITEL 2. GRUNDLAGEN
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.
26 KAPITEL 2. GRUNDLAGEN
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.
28 KAPITEL 2. GRUNDLAGEN
• 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
30 KAPITEL 2. GRUNDLAGEN
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.
2.6. GRAPHTRANSFORMATION 31
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.
32 KAPITEL 2. GRUNDLAGEN
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
2.6. GRAPHTRANSFORMATION 33
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
34 KAPITEL 2. GRUNDLAGEN
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
2.6. GRAPHTRANSFORMATION 35
L R
InsertOperation(opname: String)
NAC = R
1: Class 1: Class
feature Operation name=opname
Abb. 2.20: konkrete Regel
L R
InsertOperation(opname: String)
NAC = R
1: DataType 1: DataType
feature Operation name=opname
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
36 KAPITEL 2. GRUNDLAGEN
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))
2.6. GRAPHTRANSFORMATION 37
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
InsertOperation(opname: String)
NAC = R
1: Classifier 1: Classifier
feature Operation name=opname
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
38 KAPITEL 2. GRUNDLAGEN
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.
42 KAPITEL 3. BESCHREIBUNG DER VOCL
• 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
context Person inv :
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
context Person inv :
self:Person
lastname = y firstname y =
Abb. 3.8: Zuweisung an Variablen
44 KAPITEL 3. BESCHREIBUNG DER VOCL
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:
context Person inv :
self:Person
age = x
result = income(d)
result = x * 1000
Abb. 3.9: Variablen im Bedingungsteil
context Person inv :
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
context Company inv:
: 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
context Company inv:
: 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
46 KAPITEL 3. BESCHREIBUNG DER VOCL
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
context Company inv:
employee
...
Abb. 3.16: einfache Navigation
kombinierte Navigationen können ein Bag ergeben,
• context Company inv: self.employee->collect(birthDate) ...
48 KAPITEL 3. BESCHREIBUNG DER VOCL
self:Company : Person
collect
employee
x
context Company inv:
: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
context Company inv:
...
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
50 KAPITEL 3. BESCHREIBUNG DER VOCL
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
3.7. VORDEFINIERTE EIGENSCHAFTEN 51
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.
52 KAPITEL 3. BESCHREIBUNG DER VOCL
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. VORDEFINIERTE EIGENSCHAFTEN 53
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()
54 KAPITEL 3. BESCHREIBUNG DER VOCL
self: Company
context Company inv:
: 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)]
56 KAPITEL 3. BESCHREIBUNG DER VOCL
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.
• context Person inv:
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)
context Company inv:
: Person isMarried = true
self: Company manager
not
Abb. 3.37: Ein not Ausdruck
58 KAPITEL 3. BESCHREIBUNG DER VOCL
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:
• context Person inv:
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
60 KAPITEL 3. BESCHREIBUNG DER VOCL
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.
• context Person inv:
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.
• context Company inv:
self.employee.wife->union(self.employee.husband).employer= self
context Company inv:
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.
62 KAPITEL 3. BESCHREIBUNG DER VOCL
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.
• context Company inv:
self.employee->select(p | p.age > 50)->notEmpty()
context Company inv:
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:
3.11. KOMPLEXE OPERATIONEN AUF COLLECTIONS 63
context Company inv:
self:Company :Person
p:Person age = x
isIn
x > 50
employee
p
select
= 0 :Person
Abb. 3.44: Eine Select Operation
• context Company inv:
self.employee->reject(isMarried)->isEmpty()
context Company inv:
self:Company :Person
: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.
64 KAPITEL 3. BESCHREIBUNG DER VOCL
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:
• context Company inv:
self.employee->collect(birthdate)->asSet()
:Date
self:Company :Person birthDate collect
employee
context Company inv:
: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. KOMPLEXE OPERATIONEN AUF COLLECTIONS 65
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.
• context Company inv:
self.employee->forall (e1, e2: Person | e1 <> e2 implies
e1.firstname <> e2.firstname)
:Person :Person
context Company inv:
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.
66 KAPITEL 3. BESCHREIBUNG DER VOCL
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.
• context Company inv:
self.employee->exists (p: Person | p.firstname = ´Jack´)
:Person :Person
context Company inv:
p:Person firstname = ’Jack’
p
self: Company employee
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.
• context Person inv:
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. KOMPLEXE OPERATIONEN AUF COLLECTIONS 67
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.
• context Company inv:
self.employee->iterate (p: Person, acc: Set= Set()|
acc->including(p| p.age > 50))->notEmpty
p
:Person :Person
context Company inv:
p:Person age = x
self: Company employee
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.
68 KAPITEL 3. BESCHREIBUNG DER VOCL
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.
70 KAPITEL 3. BESCHREIBUNG DER VOCL
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
72 KAPITEL 3. BESCHREIBUNG DER VOCL
• context Person inv:
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
self: Company employee
isIn
x = y
<>
Abb. 3.55: erster Constraint
74 KAPITEL 3. BESCHREIBUNG DER VOCL
• context Company inv oneJack:
self.employee->exists (p: Person | p.firstname = ´Jack´)
:Person :Person
context Company inv oneJack:
isIn
p:Person firstname = ’Jack’
p
self: Company employee
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
VariableDeclaration varName:String
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
78 KAPITEL 4. SPEZIFIKATION VON VOCL MIT DEM MOF ANSATZ
VOCLExp
CollectionRole
BooleanExp opname:BOpEnum not:Boolean
arg1
arg2
NavigationCallExp IfExp
LetExp
initExpresion
in
if then
else
VariableDeclaration varName:String
letVar
Constraint kind:ConstraintKindEnum
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
Classifier name:String
VariableDeclaration varName:String
ClassifierRole
CollectionRole
Parameter name:String kind:PKindEnum
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
80 KAPITEL 4. SPEZIFIKATION VON VOCL MIT DEM MOF ANSATZ
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))
AssociationClassRole
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
82 KAPITEL 4. SPEZIFIKATION VON VOCL MIT DEM MOF ANSATZ
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
84 KAPITEL 4. SPEZIFIKATION VON VOCL MIT DEM MOF ANSATZ
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.source.oclIsTypeOf(CollectionRole) and
self.return.oclIsTypeOf(SetRole) and
self.source.type=self.return.type
asBag():self.name=“asBag“ implies (self.arg->size()=0 and
self.source.oclIsTypeOf(CollectionRole) and
self.return.oclIsTypeOf(BagRole) and
self.source.type=self.return.type
asSequence():self.name=“asSequence“ implies (self.arg->size()=0 and
self.source.oclIsTypeOf(CollectionRole) and
4.2. CONSTRAINTS 85
self.return.oclIsTypeOf(SequenceRole) and
self.source.type=self.return.type
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))
86 KAPITEL 4. SPEZIFIKATION VON VOCL MIT DEM MOF ANSATZ
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
(self.resultVar->size()=1 implies self.resultVar.type.name=“Boolean“))
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
(self.resultVar->size()=1 implies self.resultVar.type.name=“Boolean“)
and self.roleNode.type.name=“OclMessage“)
result() ?? isSignalSent():self.name=“isSignalSent“ implies (self.arg->size()=0 and
(self.resultVar->size()=1 implies self.resultVar.type.name=“Boolean“)
and self.roleNode.type.name=“OclMessage“)
isOperationCall():self.name=“isOperationCall“ implies (self.arg->size()=0 and
(self.resultVar->size()=1 implies self.resultVar.type.name=“Boolean“)
and self.roleNode.type.name=“OclMessage“)
oclIsTypeOf(type):self.name=“oclIsTypeOf“ implies (self.arg->size()=1 and
(self.resultVar->size()=1 implies self.resultVar.type.name=“Boolean“))
oclIsKindOf(type):self.name=“oclIsKindOf“ implies (self.arg->size()=1 and
(self.resultVar->size()=1 implies self.resultVar.type.name=“Boolean“))
oclInState(state):self.name=“oclInState“ implies (self.arg->size()=1 and
(self.resultVar->size()=1 implies self.resultVar.type.name=“Boolean“)
and self.roleNode.type.name=“OclState“ and
self.roleNode.oclIsTypeOf(ClassifierRole)))
includes(object):
88 KAPITEL 4. SPEZIFIKATION VON VOCL MIT DEM MOF ANSATZ
self.name=“includes“ implies (self.arg->size()=1 and
(self.resultVar->size()=1 implies self.resultVar.type.name=“Boolean“)
and self.roleNode.oclIsTypeOf(CollectionRole) and
self.roleNode.type=self.arg[1].type)
excludes(object):self.name=“excludes“ implies (self.arg->size()=1 and
(self.resultVar->size()=1 implies self.resultVar.type.name=“Boolean“)
and self.roleNode.oclIsTypeOf(CollectionRole) and
self.roleNode.type=self.arg[1].type)
includesAll(collection):self.name=“includesAll“ implies (self.arg->size()=1 and
(self.resultVar->size()=1 implies self.resultVar.type.name=“Boolean“)
and self.roleNode.oclIsTypeOf(CollectionRole) and
self.roleNode.type=self.arg[1].type)
excludesAll(collection):self.name=“excludesAll“ implies (self.arg->size()=1 and
(self.resultVar->size()=1 implies self.resultVar.type.name=“Boolean“)
and self.roleNode.oclIsTypeOf(CollectionRole) and
self.roleNode.type=self.arg[1].type)
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))
90 KAPITEL 4. SPEZIFIKATION VON VOCL MIT DEM MOF ANSATZ
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|
self.base.feature->exists(a:Attribute| a=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|
self.base.feature->exists(a:Attribute| a=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
92 KAPITEL 4. SPEZIFIKATION VON VOCL MIT DEM MOF ANSATZ
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
96 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
5.1. EINFACHE UML KLASSENDIAGRAMME 97
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
AssociationEnd name=nameEnd2 isNavigable=#true ordering=#unordered aggregation=#none targetScope=#instance multiplicity=mult2 changeability=#changeable visibility=#private
:Association name=aName
1:Class
2:Class
participant
participant
connection
connection
:AssociationEnd name=nameEnd1
:AssociationEnd name=nameEnd2
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
AssociationEnd name=nameEnd1 isNavigable=#true ordering=#unordered aggregation=#none targetScope=#instance multiplicity=mult1 changeability=#changeable visibility=#private
AssociationEnd name=nameEnd2 isNavigable=#true ordering=#unordered aggregation=#none targetScope=#instance multiplicity=mult2 changeability=#changeable visibility=#private
:AssociationClass name=className isRoot=root isLeaf=leaf isAbstract=abstract isAcitve=active
:AssociationClass name=className
1:Class
2:Class
participant
participant
connection
connection
:AssociationEnd name=nameEnd1
:AssociationEnd name=nameEnd2
98 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
5.1. EINFACHE UML KLASSENDIAGRAMME 99
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
1:Class isLeaf=false
:Generalization
child
parent
:Class name=classname
1:Class isLeaf=false
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
100 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
:Association name=aName
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
AssociationEnd name=nameEnd2 isNavigable=nav2 ordering=ord2 aggregation=agg2 targetScope=ts2 multiplicity=mult2 changeability=change2 visibility=visible2
:Association name=aName
1:Class
2:Class
participant
participant
connection
connection
:AssociationEnd name=nameEnd1
:AssociationEnd name=nameEnd2
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
:AssociationEnd name=nameEnd1
:AssociationEnd name=nameEnd2
AssociationEnd name=nameEnd1 isNavigable=nav1 ordering=ord1 aggregation=agg1 targetScope=ts1 multiplicity=mult1 changeability=change1 visibility=visible1
AssociationEnd name=nameEnd2 isNavigable=nav2 ordering=ord2 aggregation=agg2 targetScope=ts2 multiplicity=mult2 changeability=change2 visibility=visible2
5.1. EINFACHE UML KLASSENDIAGRAMME 101
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
102 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
5.2 Typgraph von VOCL
NavigationCallExp
Path
Classifier name:String
VariableDeclaration varName:String
CollectionRole
AssociationRole
constrainedClassifier
constrainedOp
constraintVar
start end node
arnode
participant
resultVar
resultVar
crtmnode
navSource
return
Parameter name:String kind:PKindEnum
nce
end
Constraint kind:ConstraintKindEnum
Operation
AssociationEndRole
AssociationClassRole
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
VariableDeclaration varName:String
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)
104 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
VOCLExp
CollectionRole
BooleanExp opname:BOpEnum
arg1 arg2
NavigationCallExp IfExp
LetExp
in
if then
else
VariableDeclaration varName:String
letVar
Constraint kind:ConstraintKindEnum
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
5.2. TYPGRAPH VON VOCL 105
Classifier name:String
ClassifierRole
CollectionRole
Parameter name:String kind:PKindEnum
VOCLModelElement name:String
Attribute LiteralExp
Argument
type
SetRole
BagRole
SequenceRole
VOCLExp not:Boolean
type
LoopExp
LetExp
IfExp
BooleanExp
NavigationCallExp
CollectionOpExp
RoleNode
ArithmExp
Class
VariableDeclaration varName:String
Unspecified
Abb. 5.4: Typen
106 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
5.2. TYPGRAPH VON VOCL 107
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
108 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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=""
constrainedClassifier
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()
2:Classifier 3:constrainedClassifier
: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).
110 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
2:Classifier 3:constrainedClassifier
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).
2:Classifier 4:constrainedClassifier
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
3:VariableDeclaration varName=vname
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).
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 111
L R InsertAllInstancesExp()
1:Constraint 1:Constraint
4:NavigationCallExp
:Path
:AllInstancesExp
resultingSet
aieStart
nce
5:body classifier type
2:Classifier 2:Classifier
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
2:Classifier 2:Classifier
Abb. 5.15: Einfügen eines äuivalenten Pfades (bzw. Pfadstartes)
112 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
10:referredAssociationEnd
11:participant
12:Classifier name=classname 13:participant
1:Path
2:ClassifierRole 4:start
5:base
7:AssociationEnd
6:Association
9:referredAssociationEnd
10:referredAssociationEnd
: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"
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
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 113
L R
InsertStartAssociationToSet(rolename:String, classname:String)
1:Path
2:ClassifierRole 4:start
5:base
7:AssociationEnd
6:Association
9:referredAssociationEnd
10:referredAssociationEnd
11:participant
1:Path
2:ClassifierRole 4:start
5:base
7:AssociationEnd
6:Association
9:referredAssociationEnd
10:referredAssociationEnd
:AssociationEndRole
:AssociationRole
:AssociationEndRole name=rolename
start
end
:SetRole participant
participant
node
base
13:participant
11:participant
base
base
base arnode
12:Classifier name=classname
12:Classifier name=classname 13:participant
8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
x = * v 0..*
8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
3:Classifier
3:Classifier
Abb. 5.17: Die Navigation beginnt entlang einer Assoziation
114 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R
InsertStartAssociationToBag(rolename:String, classname:String)
1:Path
2:ClassifierRole 4:start
5:base
7:AssociationEnd
6:Association
9:referredAssociationEnd
10:referredAssociationEnd
11:participant
12:Classifier name=classname 13:participant
1:Path
2:ClassifierRole 4:start
5:base
7:AssociationEnd
6:Association
9:referredAssociationEnd
10:referredAssociationEnd
:AssociationEndRole
:AssociationRole
:AssociationEndRole name=rolename
start
end
:BagRole 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 = * v 0..*
8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
3:Classifier
3:Classifier
Abb. 5.18: Die Navigation beginnt entlang einer Assoziation
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 115
L R
InsertStartAssociationToSequence(rolename:String, classname:String)
1:Path
2:SetRole 4:start
5:base
6:Association
9:referredAssociationEnd
10:referredAssociationEnd
11:participant
1:Path
2:SetRole 4:start
5:base
6:Association
9:referredAssociationEnd
10:referredAssociationEnd
:AssociationEndRole
:AssociationRole
:AssociationEndRole name=rolename
start
end
:SequenceRole participant
participant
node
base
13:participant
11:participant
base
base
base arnode
12:Classifier name=classname
7:AssociationEnd
7:AssociationEnd
12:Classifier name=classname 13:participant
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
Abb. 5.19: Die Navigation beginnt entlang einer Assoziation
116 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R
InsertStartAssociationSetToSet(rolename:String, classname:String)
1:Path
2:SetRole 4:start
5:base
6:Association
9:referredAssociationEnd
10:referredAssociationEnd
11:participant
12:Classifier name=classname 13:participant
1:Path
2:SetRole 4:start
5:base
6:Association
9:referredAssociationEnd
10:referredAssociationEnd
:AssociationEndRole
:AssociationRole
:AssociationEndRole name=rolename
start
end
:SetRole participant
participant
node
base
13:participant
11:participant
base
base
base arnode
12:Classifier name=classname
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
Abb. 5.20: Die Navigation beginnt entlang einer Assoziation
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 117
L R
InsertStartAssociationSetToBag(rolename:String, classname:String)
1:Path
2:SetRole 4:start
5:base
6:Association
9:referredAssociationEnd
10:referredAssociationEnd
11:participant
1:Path
2:SetRole 4:start
5:base
6:Association
9:referredAssociationEnd
10:referredAssociationEnd
:AssociationEndRole
:AssociationRole
:AssociationEndRole name=rolename
start
end
:BagRole participant
participant
node
base
13:participant
11:participant
base
base
base arnode
12:Classifier name=classname
7:AssociationEnd multiplicity=y
7:AssociationEnd multiplicity=y
12:Classifier name=classname 13:participant
8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
x = * v 0..* y = * v 0..*
3:Classifier
3:Classifier
Abb. 5.21: Die Navigation beginnt entlang einer Assoziation
118 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R
InsertStartAssociationSetToSequence(rolename:String, classname:String)
1:Path
2:SetRole 4:start
5:base
6:Association
9:referredAssociationEnd
10:referredAssociationEnd
11:participant
1:Path
2:SetRole 4:start
5:base
6:Association
9:referredAssociationEnd
10:referredAssociationEnd
:AssociationEndRole
:AssociationRole
:AssociationEndRole name=rolename
start
end
:SequenceRole participant
participant
node
base
13:participant
11:participant
base
base
base arnode
12:Classifier name=classname isAbstract="false"
7:AssociationEnd multiplicity=y
7:AssociationEnd multiplicity=y
12:Classifier name=classname 13:participant
8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="ordered"
x = * v 0..* y = * v 0..*
8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="ordered"
3:Classifier
3:Classifier
Abb. 5.22: Die Navigation beginnt entlang einer Assoziation
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 119
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
2:ClassifierRole 4:start
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
14:Classifier name=classname
14:Classifier name=classname
8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
x = 1 v 0..1
3:Classifier
3:Classifier
12:Classifier
12:Classifier
Abb. 5.23: Die Navigation startet zu einer Assoziationsklasse
120 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
9:referredAssociationEnd
10:referredAssociationEnd
11:participant
1:Path
2:ClassifierRole 4:node
5:base
6:Association
9:referredAssociationEnd
10:referredAssociationEnd
:AssociationEndRole
:AssociationRole
:AssociationEndRole name=rolename
start
end
:ClassifierRole participant
navSource
node
base
13:participant
11:participant
base
base
base arnode
12:Classifier name=classname
7:AssociationEnd multiplicity=#1 v #0..1
13:participant
12:Classifier name=classname
8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
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
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 121
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
2:ClassifierRole 4:node
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
14:Classifier name=classname
14:Classifier name=classname
7:AssociationEnd multiplicity=#1 v #0..1
7:AssociationEnd multiplicity=#1 v #0..1
13:participant
8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
x = 1 v 0..1
8:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
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
122 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
3:Parameter kind=#return
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
:CRTMethod name=mname
node
navSource
return
3:Operation name=mname
correspondingOp
5:node
4:Classifier type
6:type
3:Parameter kind=#return
7:parameter 3:Operation name=mname
4:Classifier 6:type
3:Parameter kind=#return
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
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 123
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)
124 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
2:ClassifierRole 8:node
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
:AssociationEndRole name=rolename
start
end
navSource
base
base
base
participant
arnode
16:AssociationEnd multiplicity=y
14:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
16:AssociationEnd multiplicity=y
x= 1 v 0..1 y= 1 v 0..1
14:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
21:NavigationCallExp
21:NavigationCallExp
22:nce
22:nce
23:nce
23:nce
3:Classifier name=n
3:Classifier name=n
NAC
21:NavigationCallExp
type
type
:Classifier 2:ClassifierRole
navSource
:NavigationRoleExp
NAC
5:ClassifierRole
navSource
:NavigationRoleExp
NAC
Abb. 5.30: Einfügen des Pfadendes zweier äquivalenter Pfade
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 125
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
2:ClassifierRole 8:node
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
:AssociationEndRole name=rolename
start
end
navSource
base
base
base
participant
arnode
16:AssociationEnd multiplicity=y
14:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
16:AssociationEnd multiplicity=y
x= 1 v 0..1 y= 1 v 0..1
14:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
21:NavigationCallExp
21:NavigationCallExp
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
Abb. 5.31: Einfügen des Pfadendes zweier äquivalenter Pfade
126 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
2:ClassifierRole 8:node
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
22:Classifier name=classname isAbstract="false"
16:AssociationEnd multiplicity=y
2:ClassifierRole
5:ClassifierRole
3:Classifier
4:Classifier
9:base
10:base
17:connection
18:connection
19:participant
20:participant
21:type
22:Classifier name=classname isAbstract="false"
16:AssociationEnd multiplicity=y
8:node
15:AssociationClass :AssociationClassRole
:AssociationEndRole
:AssociationEndRole
:ClassifierRole
base
base
base
participant
start
end
referredNode type
navSource
14:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
14:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
x= 1 v 0..1 y= 1 v 0..1
24:NavigationCallExp
25:nce
23:nce
24:NavigationCallExp
25:nce
type
type
:Classifier
NAC
24:NavigationCallExp
23:nce
2:ClassifierRole
navSource
:NavigationRoleExp
NAC
5:ClassifierRole
navSource
:NavigationRoleExp
NAC
Abb. 5.32: Einfügen des Pfadendes zweier äquivalenter Pfade
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 127
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
2:ClassifierRole 8:node
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
22:Classifier name=classname
16:AssociationEnd multiplicity=y
2:ClassifierRole
5:ClassifierRole
3:Classifier
4:Classifier
9:base
10:base
17:connection
18:connection
19:participant
20:participant
21:type
22:Classifier name=classname
16:AssociationEnd multiplicity=y
8:node
15:AssociationClass :AssociationClassRole
:AssociationEndRole
:AssociationEndRole
:ClassifierRole
base
base
base
participant
start
end
referredNode type
navSource
14:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
14:AssociationEnd name=rolename multiplicity=x isNavigable="true" targetScope="instance" ordered="unordered"
x= 1 v 0..1 y= 1 v 0..1
24:NavigationCallExp
25:nce
24:NavigationCallExp
25:nce
23:nce
26:type
26:type
23:nce
5:ClassifierRole
navSource
:NavigationRoleExp
NAC
2:ClassifierRole
navSource
:NavigationRoleExp
NAC
Abb. 5.33: Einfügen des Pfadendes zweier äquivalenter Pfade
128 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
:CRTMethod name=mname
navSource
return
correspondingOp
14:Operation name=mname
3:Classifier 16:type
17:Parameter kind=#return
18:parameter
14:Operation name=mname
17:Parameter kind=#return
18:parameter
4:Class
11:base
10:feature
4:Class 11:base
10:feature
3:Classifier
21:NavigationCallExp
22:nce
23:nce
21:NavigationCallExp
23:nce
22:nce
16:type
type type
:Classifier
NAC
21:NavigationCallExp
5:RoleNode
navSource
:NavigationRoleExp
NAC
2:RoleNode
navSource
:NavigationRoleExp
NAC
Abb. 5.34: Einfügen des Pfadendes zweier äquivalenter Pfade
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 129
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
:CRTMethod name=mname
navSource
return
correspondingOp
14:Operation name=mname
3:Classifier 16:type
17:Parameter kind=#return
18:parameter
14:Operation name=mname
17:Parameter kind=#return
18:parameter
4:Class
11:base
10:feature
4:Class 11:base
10:feature
3:Classifier
21:NavigationCallExp
22:nce
23:nce
21:NavigationCallExp
23:nce
22:nce
16:type
24:type
24:type
2:RoleNode
navSource
:NavigationRoleExp
NAC
5:RoleNode
navSource
:NavigationRoleExp
NAC
Abb. 5.35: Einfügen des Pfadendes zweier äquivalenter Pfade
130 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
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
:IncludesOp name=opname
arg2
navSource
:Classifier name="Boolean"
result
opname = #includes v #excludes
8:node
:LiteralExp name="true"
type
21:NavigationCallExp
22:nce
23:nce
21:NavigationCallExp
22:nce
23:nce
type
type
:Classifier
NAC
21:NavigationCallExp
2:CollectionRole
navSource
:NavigationRoleExp
NAC
5:ClassifierRole
navSource
:NavigationRoleExp
NAC
Abb. 5.36: Einfügen des Pfadendes zweier äquivalenter Pfade
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 131
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
2:CollectionRole 8:node
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
:IncludesOp name=opname
arg2
navSource
:Classifier name="Boolean"
result
opname = #includes v #excludes
8:node
:LiteralExp name="true"
type
21:NavigationCallExp
22:nce
23:nce
21:NavigationCallExp
22:nce
23:nce
20:type 20:type
2:CollectionRole
navSource
:NavigationRoleExp
NAC
5:ClassifierRole
navSource
:NavigationRoleExp
NAC
Abb. 5.37: Einfügen des Pfadendes zweier äquivalenter Pfade
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.
132 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L
InsertPathEndIncludesAll(opname:IncOpEnum)
R
opname = #includesAll v #excludesAll
1:Path
2:CollectionRole 8:node
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
:IncludesOp name=opname
arg2
navSource
:Classifier name="Boolean"
result
8:node
:LiteralExp name="true"
type
21:NavigationCallExp
22:nce
23:nce
21:NavigationCallExp
22:nce
23:nce
type
type
:Classifier
NAC
21:NavigationCallExp
2:CollectionRole
navSource
:NavigationRoleExp
NAC
5:CollectionRole
navSource
:NavigationRoleExp
NAC
Abb. 5.38: Einfügen des Pfadendes zweier äquivalenter Pfade
L
InsertPathEndIncludesAll_2(opname:IncOpEnum)
R
opname = #includesAll v #excludesAll
1:Path
2:CollectionRole 8:node
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
:IncludesOp name=opname
arg2
navSource
:Classifier name="Boolean"
result
8:node
:LiteralExp name="true"
type
21:NavigationCallExp
22:nce
23:nce
21:NavigationCallExp
22:nce
23:nce
20:type 20:type
2:CollectionRole
navSource
:NavigationRoleExp
NAC
5:CollectionRole
navSource
:NavigationRoleExp
NAC
Abb. 5.39: Einfügen des Pfadendes zweier äquivalenter Pfade
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 133
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.
134 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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.
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 135
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
8:Operation name=opname
12:parameter
11:type
9:Parameter kind=#in
13:Path 13:Path
14:node end
1:ClassifierRole
target
:VOCLMessage
NAC
1:ClassifierRole
state
:VOCLState
NAC
15:NavigationCallExp 16:nce
15:NavigationCallExp 16:nce
type
type
:Classifier
NAC
15:NavigationCallExp
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.
136 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R InsertAttributeOp_2(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
8:Operation name=opname
12:parameter
11:type
9:Parameter kind=#in
13:Path 13:Path
14:node end
1:ClassifierRole
target
:VOCLMessage
NAC
1:ClassifierRole
state
:VOCLState
NAC
15:NavigationCallExp 16:nce
15:NavigationCallExp 16:nce
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.
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 137
L R InsertMethodOp((methodname:String, opname: OpEnum)
2:Classifier
1:ClassifierRole
3:Operation name=methodname
5:Classifier 6:type
4:Parameter kind=#return
7:parameter
8:base
9:feature 2:Classifier
1:ClassifierRole
3:Operation name=methodname
5:Classifier
6:type
4:Parameter kind=#return
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
14:Operation name=opname
13:type
15:Parameter kind=#in
12:parameter
method
14:Operation name=opname
15:Parameter kind=#in 12:parameter
13:type correspondingOp
1:ClassifierRole
target
:VOCLMessage
NAC
1:ClassifierRole
state
:VOCLState
NAC
16:NavigationCallExp
17:nce 16:NavigationCallExp
17:nce
type
type
:Classifier
NAC
16:NavigationCallExp
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
3:Operation name=methodname
5:Classifier 6:type
4:Parameter kind=#return
7:parameter
8:base
9:feature 2:Classifier
1:ClassifierRole
3:Operation name=methodname
5:Classifier
6:type
4:Parameter kind=#return
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
14:Operation name=opname
13:type
15:Parameter kind=#in
12:parameter
method
14:Operation name=opname
15:Parameter kind=#in 12:parameter
13:type correspondingOp
1:ClassifierRole
target
:VOCLMessage
NAC
1:ClassifierRole
state
:VOCLState
NAC
16:NavigationCallExp
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
138 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
4:Classifier 4:Classifier
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
4:Classifier 4:Classifier
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.
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 139
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
3:VariableDeclaration varName=vname
3:VariableDeclaration varName=vname
1:ArithmExp 1:ArithmExp
2:Classifier
3:type
2:Classifier
3:type
NAC
1:ArithmExp
:LiteralExp
literal
NAC
1:ArithmExp
:VariableDeclaration
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)
4:Operation name=opname
1:ArithmExp
5:type
:ArithmOp name=opname
op
2:Classifier 3:Parameter kind=#out 6:type
7:parameter
4:Operation name=opname
1:ArithmExp
5:type
2:Classifier 3:Parameter kind=#out 6:type
correspondingOp
NAC
1:ArithmExp
:LiteralExp
literal
NAC
1:ArithmExp
:VariableDeclaration
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
140 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
:VariableDeclaration argV
1:ArithmOp
2:Operation
3:Parameter
4:Classifier
6:type
5:correspondingOp
7:parameter
:ArithmOp argOp
8:VariableDeclaration varName=vname
8:type
8:VariableDeclaration varName=vname
8:type
Abb. 5.50: ein Argument der arithmetischen Operation ist eine Variable
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 141
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
7:parameter 7:parameter
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
:VariableDeclaration argV
1:ArithmOp
2:Operation
3:Parameter
4:Classifier
6:type
5:correspondingOp
7:parameter
:ArithmOp argOp
:ArithmOp name=opname 8:Operation
name=opname
9:Parameter kind=#in
10:parameter
11:type
8:Operation name=opname
9:Parameter kind=#in
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) ) ; ) ;
142 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
1:ClassifierRole 1:ClassifierRole
attrass 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 :VariableDeclaration varName=vname
variable
:AttributeAssignment
type
NAC
1:ClassifierRole
attrass
attribute
3:Attribute name=attrname
:AttributeAssignment
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.
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 143
InsertAttributeAssignment_2(vname:String, attrname:String)
L R
1:ClassifierRole 1:ClassifierRole
attrass 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 :VariableDeclaration varName=vname
variable
:AttributeAssignment
type
NAC
1:ClassifierRole
attrass
attribute
3:Attribute name=attrname
:AttributeAssignment
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 14:type 14:type
1:ClassifierRole
navSource
:NavigationRoleExp
NAC
Abb. 5.53: ein Attributwert wird einer Variablen zugewiesen
InsertAttributeAssignment2(vname:String, attrname:String)
L R
1:ClassifierRole 1:ClassifierRole
attrass attribute
3:Attribute name=attrname
2:Class
4:Classifier
5:base
6:feature
7:type
3:Attribute name=attrname
2:Class
4:Classifier
5:base
6:feature
7:type :VariableDeclaration varName=vname
variable
:AttributeAssignment
type
NAC
1:ClassifierRole
attrass
attribute
3:Attribute name=attrname
:AttributeAssignment
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
12:nce
13:exp
variable
11:node
Abb. 5.54: ein Attributwert wird einer Variablen zugewiesen
144 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
3:Operation name=mname
6:type
4:Parameter kind=#return
7:parameter 8:feature
9:base
1:RoleNode
2:Classifier
3:Operation name=mname
4:Parameter kind=#return
7:parameter 8:feature
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
12:NavigationCallExp
13:nce
12:NavigationCallExp
13:nce
type
type
:Classifier
NAC
12:NavigationCallExp
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
3:Operation name=mname
6:type
4:Parameter kind=#return
7:parameter 8:feature
9:base
1:RoleNode
2:Classifier
3:Operation name=mname
4:Parameter kind=#return
7:parameter 8:feature
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
12:NavigationCallExp
13:nce
12:NavigationCallExp
13:nce
14:type 14:type
1:RoleNode
navSource
:NavigationRoleExp
NAC
Abb. 5.56: der Rückgabewert der Methode ist true
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 145
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
3:Operation name=mname
6:type
4:Parameter kind=#return
7:parameter 8:feature
9:base
1:RoleNode
2:Classifier
3:Operation name=mname
4:Parameter kind=#return 7:parameter
8:feature
9:base :Method name=mname
method 6:type
correspondingOp
:VariableDeclaration varame=vname
resultVar
5:Classifier
5:Classifier type
NAC
1:RoleNode
method
:Method
NAC
10:Constraint
:VariableDeclaration varName=vname
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).
146 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L
R
InsertMethod2WithNavType(mname:String,vname:String)
1:RoleNode
type
2:Classifier
3:Operation name=mname
6:type
4:Parameter kind=#return
7:parameter 8:feature
9:base
1:RoleNode
2:Classifier
3:Operation name=mname
4:Parameter kind=#return 7:parameter
8:feature
9:base :Method name=mname
method 6:type
correspondingOp
:VariableDeclaration varame=vname
resultVar
5:Classifier
5:Classifier type
NAC
1:RoleNode
method
:Method
NAC
10:Constraint
:VariableDeclaration varName=vname
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
Abb. 5.58: der Rückgabewert der Methode wird einer Variablen zugewiesen
L
R
InsertMethod2_2(mname:String,vname:String)
1:RoleNode
type
2:Class
3:Operation name=mname
6:type
4:Parameter kind=#return
7:parameter 8:feature
9:base
1:RoleNode
2:Class
3:Operation name=mname
4:Parameter kind=#return 7:parameter
8:feature
9:base :Method name=mname
method 6:type
correspondingOp
:VariableDeclaration varame=vname
resultVar
5:Classifier
5:Classifier type
NAC
1:RoleNode
method
:Method
NAC
10:Constraint
:VariableDeclaration varName=vname
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
Abb. 5.59: der Rückgabewert der Methode wird einer Variablen zugewiesen
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 147
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 ;
148 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
2:Classifier name=Boolean
type
L
1:CollectionRole
2:Classifier name=Boolean
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
2:Classifier name=Boolean
type
L
1:CollectionRole
2:Classifier name=Boolean
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
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 149
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
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
:VariableDeclaration varName=vname
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
:VariableDeclaration varName=varname
resultVar
2:Classifier name=Integer
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
:VariableDeclaration varName=vname
variable
NAC
1:CollectionRole
method
:Method
4:Classifier
4:Classifier
5:base 5:base
14:type
14:type
1:CollectionRole
navSource
:NavigationRoleExp
NAC
Abb. 5.63: eine einfache Operation auf Collections wird eingefügt ( size)
150 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
:VariableDeclaration varName=varname
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
:VariableDeclaration varName=vname
variable
11:node
Abb. 5.64: eine einfache Operation auf Collections wird eingefügt ( size)
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 ;
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 151
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
3:Operation name=opname
4:Parameter kind=#in
5:Parameter kind=#in
6:Classifier
correspondingOp
10:type 7:type 7:type
type
8:parameter 9:parameter
1:NavigationCallExp
2:VariableDeclaration varName=varname
3:Operation name=opname
4:Parameter kind=#in
5:Parameter kind=#in
6:Classifier
7:type 7:type
8:parameter 9:parameter
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 ;
152 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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.
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 153
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
4:State name=stateName
5:base
6:context
3:StateMachine 7:top
: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
:AttributeAssignment
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
4:State name=stateName
5:base
6:context
3:StateMachine 7:top
2:Classifier
1:ClassifierRole
4:State name=stateName
5:base
6:context
3:StateMachine 7:top
: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
:AttributeAssignment
NAC
end
9:NavigationCallExp
11:nce
9:NavigationCallExp
11:nce 12:type
12:type
1:RoleNode
navSource
:NavigationRoleExp
NAC
Abb. 5.67: Einfügen des obersten Zustands
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
154 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
gesendete Message zu einer ClassifierRole dargestellt werden (NACs).
2:Class
L R InsertState2(stateName:String)
1:ClassifierRole
4:State name=stateName
5:base
6:context
3:StateMachine 7:top
2:Class
1:ClassifierRole
4:State name=stateName
5:base
6:context
3:StateMachine 7:top
:VOCLState name=stateName
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
:AttributeAssignment
NAC
9:node
Abb. 5.68: Einfügen des obersten Zustands
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
:VOCLState name=stateName
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.
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 155
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
3:Operation name=mname
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
:AttributeAssignment
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.
156 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
2:Class
L R InsertOperationMessageHasSent2(mname:String, mkind)
1:ClassifierRole
3:Operation name=mname
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
:AttributeAssignment
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
5:base :VOCLMessageExp name=mname kind=mkind
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
:AttributeAssignment
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
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 157
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
5:base :VOCLMessageExp name=mname kind=mkind
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
:AttributeAssignment
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
Abb. 5.73: Einfügen einer Message
158 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
:AttributeAssignment
NAC
mkind="messageOperator"
6:Path 8:node
7:NavigationCallExp
9:nce
6:Path
7:NavigationCallExp
9:nce
3:Operation name=mname
referredOperation
8:node
:SequenceRole :Classifier name="OCLMessage"
base node resultingMessageNode
3:Operation name=mname
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
:AttributeAssignment
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
Abb. 5.75: Einfügen einer Message
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 159
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
1:VOCLMessageExp name=mname
5:referredOperation
2:Operation
3:Parameter
4:Classifier
6:type
7:parameter
:LiteralExp name=aname
type
argument
NAC
1:VOCLMessageExp name=mname
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)
1:VOCLMessageExp name=mname
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
9:VariableDeclaration name=aname
8:type
NAC
1:VOCLMessageExp name=mname
5:referredOperation
2:Operation
3:Parameter
4:Classifier
6:type
7:parameter
type
argument :Argument
Abb. 5.77: Einfügen von Argumenten einer Message
160 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R InsertMessageExpArgUnspecified()
1:VOCLMessageExp name=mname
5:referredOperation
2:Operation
3:Parameter
4:Classifier
6:type
7:parameter
type
argument 1:VOCLMessageExp name=mname
5:referredOperation
2:Operation
3:Parameter
4:Classifier
6:type
7:parameter
:Unspecified
NAC
1:VOCLMessageExp name=mname
5:referredOperation
2:Operation
3:Parameter
4:Classifier
6:type
7:parameter
type
argument :Argument
Abb. 5.78: Einfügen von Argumenten einer Message
L R InsertMessageExpArgLiteral2(aname:String)
1:VOCLMessageExp name=mname
5:referredSignal
2:Signal
3:Attribute
4:Classifier
6:type
7:feature
type
argument 1:VOCLMessageExp name=mname
5:referredSignal
2:Signal
3:Attribute
4:Classifier
6:type
7:feature
:LiteralExp name=aname
NAC
1:VOCLMessageExp name=mname
5:referredOperation
2:Operation
3:Parameter
4:Classifier
6:type
7:parameter
type
argument :Argument
Abb. 5.79: Einfügen von Argumenten einer Message
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 161
L R InsertMessageExpArgVariable2(aname:String)
1:VOCLMessageExp name=mname
5:referredSignal
2:Signal
3:Attribute
4:Classifier
6:type
7:feature
1:VOCLMessageExp name=mname
5:referredSignal
2:Signal
3:Attribute
4:Classifier
6:type
7:feature
9:VariableDeclaration name=aname
8:type
9:VariableDeclaration name=aname
8:type
argument
NAC
1:VOCLMessageExp name=mname
5:referredOperation
2:Operation
3:Parameter
4:Classifier
6:type
7:parameter
type
argument :Argument
Abb. 5.80: Einfügen von Argumenten einer Message
L R InsertMessageExpArgUnspecified2()
1:VOCLMessageExp name=mname
5:referredSignal
2:Signal
3:Attribute
4:Classifier
6:type
7:feature
type
argument 1:VOCLMessageExp name=mname
5:referredSignal
2:Signal
3:Attribute
4:Classifier
6:type
7:feature
:Unspecified
NAC
1:VOCLMessageExp name=mname
5:referredOperation
2:Operation
3:Parameter
4:Classifier
6:type
7:parameter
type
argument :Argument
Abb. 5.81: Einfügen von Argumenten einer Message
162 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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. SYNTAXGRAMMATIKREGELN VON VOCL 163
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
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
3:Classifier name=#Boolean
4:exp
exp
if
type
:BooleanExp name=opName
Abb. 5.84: Der if-Teil ist eine BooleanExp
164 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
3:Classifier name=#Boolean
:IfExp
3:Classifier name=#Boolean
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
3:Classifier name=#Boolean
:LetExp
3:Classifier name=#Boolean
4:exp exp
if
type
5:Classifier
5:Classifier :VariableDeclaration varName=vName
variable type 2:Constraint
NAC
:VariableDeclaration varName=vname
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.
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 165
L R
InsertIfExpThenNavigationCallExp2()
1:IfExp
2:Constraint
3:exp
1:IfExp
2:Constraint
3:exp
:NavigationCallExp
exp
then 1:IfExp
:VOCLExp
then
NAC
type
4:Classifier 4:Classifier
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
4:Classifier 4:Classifier
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
2:Constraint 3:Classifier name=#Boolean
3:Classifier name=#Boolean
4:exp exp
then
type
:BooleanExp name=opName
type 1:IfExp
type
NAC
:Classifier
Abb. 5.89: Der Then-Teil ist eine BooleanExp
166 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R
InsertIfExpThenBooleanExp2(opName:BOpEnum)
1:IfExp
2:Constraint
4:exp
1:IfExp
:VOCLExp
then
NAC
1:IfExp
2:Constraint 3:Classifier name=#Boolean
3:Classifier name=#Boolean
4:exp exp
then
type
:BooleanExp name=opName
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
3:Classifier 3: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
3:Classifier 3:Classifier
type 5:type
5:type
Abb. 5.92: Der Then-Teil ist eine IfExp
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 167
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
:VariableDeclaration varName=vname
variable
variable
3:Classifier 3:Classifier
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
:VariableDeclaration varName=vName
variable type
2:Constraint
NAC
:VariableDeclaration varName=vname
variable
variable
3:Classifier 3:Classifier
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.
168 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
2:Constraint 3:Classifier name=#Boolean
4:exp 7:exp
6:then
8:type 7:exp
6:then
8:type
exp else type
1:IfExp
2:Constraint 3:Classifier name=#Boolean
4:exp
5:VOCLExp 5:VOCLExp
:BooleanExp name=opName
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.
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 169
InsertIfExpElseLetExp(vName:String)
2:Constraint
NAC
:VariableDeclaration varName=vname
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
:VariableDeclaration varName=vName
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
170 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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 ;
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 171
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
:BooleanExp name=opName
2:Classifier name=#Boolean
type
2:Classifier name=#Boolean
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
3:Classifier name=#Boolean
type
3:Classifier name=#Boolean
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.
172 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
3:Classifier name=#Boolean
3:Classifier name=#Boolean
type
:BooleanExp name=opName
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
3:Classifier name=#Boolean
3:Classifier name=#Boolean
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
3:Classifier name=#Boolean
:LetExp
3:Classifier name=#Boolean
4:exp exp
type
5:Classifier
5:Classifier :VariableDeclaration varName=vName
variable
type
variable
2:Constraint
NAC
:VariableDeclaration varName=vname
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
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 173
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 ;
174 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
:VariableDeclaration varName=name
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
4:VariableDeclaration
7:type
8:letVar 3:Classifier name=#Boolean
1:LetExp
2:Constraint
5:exp
4:VariableDeclaration
7:type
8:letVar 3:Classifier name=#Boolean
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
4:VariableDeclaration
:VOCLExp
initExpression
NAC
4:VariableDeclaration
7:type
8:letVar 3:Classifier
1:LetExp
2:Constraint
5:exp
4:VariableDeclaration
7:type
8:letVar 3:Classifier
type
exp
initExpression
3:IfExp
Abb. 5.106: Die Let-Variable wird mit einer IfExp initialisiert
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 175
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
4:VariableDeclaration
:VOCLExp
initExpression
NAC
4:VariableDeclaration
7:type
8:letVar 1:LetExp
2:Constraint
5:exp
4:VariableDeclaration
7:type
8:letVar
exp
initExpression
:LetExp
:VariableDeclaration varName=vname
letVar type
variable
2:Constraint
NAC
:VariableDeclaration varName=vname
variable
9:Classifier 3:Classifier
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
4:VariableDeclaration
7:type
8:letVar
initExpression
3:Classifier
1:LetExp
2:Constraint
5:exp
4:VariableDeclaration
7:type
8:letVar 3:Classifier
:NavigationCallExp
R
initExpression
exp
4:VariableDeclaration
NAC
2:Constraint
:VariableDeclaration
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).
176 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R
InsertClassifierRoleName(name:String)
variable
11:VariableDeclaration varName=name
3:base
1:ClassifierRole
2:Classifier 15:type
4:Constraint
5:NavigationCallExp
6:Path
end
8:nce
9:exp 14:variable 12:exp
10:LetExp
13:letVar
11:VariableDeclaration varName=name
3:base
1:ClassifierRole
2:Classifier 15:type
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
Abb. 5.109: Einfügen eines Let Ausdrucks
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)
:VariableDeclaration varName=name
4:Constraint
variable
NAC
variable
11:VariableDeclaration varName=name
3:base
1:CollectionRole
2:Classifier 15:type
4:Constraint
5:NavigationCallExp
6:Path
end
8:nce
9:exp
14:variable
12:exp
10:LetExp
13:letVar
11:VariableDeclaration varName=name
3:base
1:CollectionRole
2:Classifier 15:type
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
Abb. 5.110: Einfügen eines Let Ausdrucks
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 177
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
4:Classifier 4:Classifier
type
5:type
5:type
Abb. 5.112: Der In-Teil ist eine NavigationCallExp
178 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 179
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
5:Classifier 5:Classifier
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
5:Classifier :VariableDeclaration varName=vName
variable type 2:Constraint
NAC
:VariableDeclaration varName=vname
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
5:Classifier :VariableDeclaration varName=vName
variable type 2:Constraint
NAC
:VariableDeclaration varName=vname
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
180 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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.
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 181
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 ;
182 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
InsertMathSetOpSetResult2(opName:COpEnum)
1:SetRole
:MathSetOp name=opName
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
Abb. 5.120: Einfügen von Mengenoperationen, die Sets als Ergebnis haben
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 183
L R
InsertMathSetOpSetResult3(opName:COpEnum)
1:SetRole
:MathSetOp name=opName
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
Abb. 5.121: Einfügen von Mengenoperationen, die Sets als Ergebnis haben
L R
InsertMathSetOpBagResult1(opName:COpEnum)
1:BagRole
:MathSetOp name=opName
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
184 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R
InsertMathSetOpBagResult2(opName:COpEnum)
1:BagRole
:MathSetOp name=opName
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
Abb. 5.123: Einfügen von Mengenoperationen, die Bags als Ergebnis haben
L R
InsertMathSetOpBagResult3(opName:COpEnum)
1:BagRole
:MathSetOp name=opName
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
Abb. 5.124: Einfügen von Mengenoperationen, die Bags als Ergebnis haben
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 185
L R
InsertMathSetOpSequenceResult1(opName:COpEnum)
1:SequenceRole
:MathSetOp name=opName
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
InsertMathSetOpSequenceResult2(opName:COpEnum)
1:SequenceRole
:MathSetOp name=opName
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
Abb. 5.126: Einfügen von Mengenoperationen, die Sequences als Ergebnis haben
186 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R
InsertMathSetOpSequenceResult3(opName:COpEnum)
1:SequenceRole
:MathSetOp name=opName
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
Abb. 5.127: Einfügen von Mengenoperationen, die Sequences als Ergebnis haben
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.
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 187
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
:VariableDeclaration name=iteratorname
type
:NavigationCallExp exp
1:CollectionRole
navSource
:NavigationRoleExp
NAC
loopExp
Abb. 5.128: LoopExp mit der Operation any, der Body ist ein Navigationsausdruck
188 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
: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
:VariableDeclaration name=iteratorname
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.
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 189
L R
InsertAnyExpWithBooleanExpBody(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
:VariableDeclaration name=iteratorname
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
: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
:VariableDeclaration name=iteratorname
type
:LetExp
exp
10:Classifier 10:Classifier
: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
190 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
:VariableDeclaration name=iteratorname
: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
:VariableDeclaration name=iteratorname
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.
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 191
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
:VariableDeclaration name=iteratorname
:BodyLoopExp name=#collect
:BagRole type
navSource
resultRole
2:Classifier
iterator
:NavigationCallExp
body
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
variable
NAC
6:Constraint
:VariableDeclaration name=iteratorname
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.
192 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R
InsertSortedByExpWithNavigationBody(iteratorname:String)
1:CollectionRole
:VariableDeclaration name=iteratorname
:BodyLoopExp name=#collect
type
navSource
resultRole
2:Classifier
iterator
:NavigationCallExp
body
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
:SequenceRole
variable
NAC
6:Constraint
:VariableDeclaration name=iteratorname
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
:VariableDeclaration name=iteratorname
:BodyLoopExp name=#loopexpname
navSource
2:Classifier
iterator
:NavigationCallExp
body
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
8:nce 9:exp
exp loopexpname= #forall v #exists v
#one v #isUnique
4:LiteralExp name="true"
4:LiteralExp name="true"
type
end
variable
variable
NAC
6:Constraint
:VariableDeclaration name=iteratorname
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
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 193
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
:VariableDeclaration name=iteratorname
:BodyLoopExp name=#loopexpname
navSource
2:Classifier
iterator
:NavigationCallExp
body
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
8:nce 9:exp
exp loopexpname= #forall v
#exists v #one v
#isUnique
4:LiteralExp name="true"
4:LiteralExp name="true"
type
end
variable
variable
NAC
6:Constraint
:VariableDeclaration name=iteratorname
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.
194 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R
InsertForallExpWithNavigationBody(i1name:String, i2name: String)
1:CollectionRole
:VariableDeclaration name=i1name
:BodyLoopExp name=#forall
navSource 2:Classifier
iterator
:NavigationCallExp body
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
end
8:nce
9:exp i1name<>i2name
4:LiteralExp name="true"
4:LiteralExp name="true"
type
:VariableDeclaration name=i2name
iterator
variable
variable
variable
NAC
6:Constraint
:VariableDeclaration name=i1name
variable
NAC
6:Constraint
:VariableDeclaration name=i2name
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:
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 195
L R
InsertIfExpIfNavigationCallExpInsideABodyLoop()
1:IfExp
2:Constraint
3:exp
1:IfExp
2:Constraint
3:exp
:NavigationCallExp
exp
if
1:IfExp
:VOCLExp
if
NAC
4:Classifier name=#Boolean
4:Classifier name=#Boolean
type
5:BodyLoopExp 6:loopExp
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
2:Constraint 3:Classifier name=#Boolean
3:Classifier name=#Boolean
4:exp
exp
if
type
:BooleanExp name=opName
5:BodyLoopExp 6:loopExp
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
3:Classifier name=#Boolean
:IfExp
3:Classifier name=#Boolean
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
196 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R
InsertIfExpIfLetExpInsideABodyLoop(vName:String)
1:IfExp
2:Constraint
4:exp
1:IfExp
:VOCLExp
if
NAC
1:IfExp
2:Constraint 3:Classifier name=#Boolean
:LetExp
3:Classifier name=#Boolean
4:exp exp
if
type 5:Classifier
5:Classifier :VariableDeclaration varName=vName
variable type
2:Constraint
NAC
:VariableDeclaration varName=vname
variable variable
7:BodyLoopExp
6:loopExp loopExp
7:BodyLoopExp 6: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
4:Classifier 4:Classifier
type
1:IfExp
type
NAC
:Classifier
5:BodyLoopExp 6:loopExp
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
2:Constraint 3:Classifier name=#Boolean
3:Classifier name=#Boolean
4:exp exp
then
type
:BooleanExp name=opName
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
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 197
InsertIfExpThenBooleanExp2, Abb. 5.90).
L R
InsertIfExpThenIfExpInsideABodyLoop()
1:IfExp
2:Constraint
4:exp
1:IfExp
:VOCLExp
then
NAC
1:IfExp
2:Constraint 3:Classifier name=#Boolean
3:Classifier name=#Boolean
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
:VariableDeclaration varName=vName
variable type
2:Constraint
NAC
:VariableDeclaration varName=vname
variable
variable
3:Classifier 3:Classifier
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)
198 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
2:Constraint 3:Classifier name=#Boolean
4:exp 7:exp
6:then
8:type 7:exp
6:then
8:type
exp else type
1:IfExp
2:Constraint 3:Classifier name=#Boolean
4:exp
5:VOCLExp 5:VOCLExp
:BooleanExp name=opName
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
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 199
InsertIfExpElseLetExpInsideABodyLoop(vName:String)
2:Constraint
NAC
:VariableDeclaration varName=vname
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
:VariableDeclaration varName=vName
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 ;
200 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
3:Classifier name=#Boolean
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
3:Classifier name=#Boolean
3:Classifier name=#Boolean
type
:BooleanExp name=opName
5:BodyLoopExp 6:loopExp
loopExp
5:BodyLoopExp
6:loopExp
Abb. 5.151: Das Argument einer BooleanExp innerhalb einer BodyLoopExp ist eine BooleanExp
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 201
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
3:Classifier name=#Boolean
3:Classifier name=#Boolean
type
5:BodyLoopExp 6:loopExp
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
3:Classifier name=#Boolean
:LetExp
3:Classifier name=#Boolean
4:exp exp
type
5:Classifier
5:Classifier :VariableDeclaration varName=vName
variable
type
variable
2:Constraint
NAC
:VariableDeclaration varName=vname
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
202 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
4:VariableDeclaration
:VOCLExp
initExpression
NAC
4:VariableDeclaration
7:type
8:letVar 3:Classifier name=#Boolean
1:LetExp
2:Constraint
5:exp
4:VariableDeclaration
7:type
8:letVar 3:Classifier name=#Boolean
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
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 203
L R
InsertLetExpInitVarIfExpInsideABodyLoop()
1:LetExp
2:Constraint
5:exp
4:VariableDeclaration
:VOCLExp
initExpression
NAC
4:VariableDeclaration
7:type
8:letVar
3:Classifier
1:LetExp
2:Constraint
5:exp
4:VariableDeclaration
7:type
8:letVar 3:Classifier
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
4:VariableDeclaration
:VOCLExp
initExpression
NAC
4:VariableDeclaration
7:type
8:letVar 1:LetExp
2:Constraint
5:exp
4:VariableDeclaration
7:type
8:letVar
exp
initExpression
:LetExp
:VariableDeclaration varName=vname
letVar type
variable
2:Constraint
NAC
:VariableDeclaration varName=vname
variable
9:Classifier 3:Classifier
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
204 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L
InsertLetExpVarInitNavigationCallExpInsideABodyLoop()
:VOCLExp
initExpression
NAC
1:LetExp
2:Constraint
5:exp
4:VariableDeclaration
7:type
8:letVar
initExpression
3:Classifier 1:LetExp
2:Constraint
5:exp
4:VariableDeclaration
7:type
8:letVar 3:Classifier
:NavigationCallExp
R
initExpression
exp
4:VariableDeclaration
NAC
2:Constraint
:VariableDeclaration
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
4:Classifier 4:Classifier
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).
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 205
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 loopExp
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 loopExp
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).
206 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
5:Classifier :VariableDeclaration varName=vName
variable type
2:Constraint
NAC
:VariableDeclaration varName=vname
variable variable
k<>definition
2:Constraint kind=k
1LetExp
:Classifier
type
NAC
3:Classifier
3:Classifier
type
9:BodyLoopExp 10:loopExp
loopExp
9:BodyLoopExp 10: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).
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 207
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.
208 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 209
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.
210 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R InsertCollectionAttributeOp(opname:OpEnum, attrname:String)
1:CollectionRole 1:ClassifierRole
attrop
:AttributeOp name=opname
argument
:ArithmExp
attribute 3:Attribute name=attrname
2:Class
4:Classifier
5:base
6:feature
7:type
3:Attribute name=attrname
2:Class
4:Classifier
5:base
6:feature
7:type
type
8:Operation name=opname
11:type
9:Parameter kind=#in
12:parameter
8:Operation name=opname
12:parameter
11:type
9:Parameter kind=#in
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
3:Attribute name=attrname
2:Class
4:Classifier
5:base
6:feature
7:type
3:Attribute name=attrname
2:Class
4:Classifier
5:base
6:feature
7:type :VariableDeclaration varName=vname
variable
:AttributeAssignment
type
NAC = R
8:ShortCutLoopExp
9:source
8:ShortCutLoopExp
9:source
14:Path
15:node
11:NavigationCallExp
12:Constraint
10:nce
13:path
14:Path 15:node
11:NavigationCallExp
12:Constraint
10:nce
13:path
NAC
:VariableDeclaration varName=vname
12:Constraint
variable
variable
Abb. 5.165: Einfügen eines AttributeAssignments zu einer Collection
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 211
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
attribute 3:Attribute name=attrname
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=#sum
navSource
attrass
variable
:AttributeAssignment
:VariableDeclaration varName=iname
9:type
iterator
resultVar
:VariableDeclaration varName=vname
10:Path
11:NavigationCallExp
12:Constraint
10:Path
11:NavigationCallExp
12:Constraint
16:exp
16:exp 15:nce
14:node
end 15:nce
variable
NAC
12:Constraint
:VariableDeclaration varName=vname
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.
212 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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
:VariableDeclaration varName=vname
10:Path
11:NavigationCallExp
12:Constraint 10:Path
11:NavigationCallExp
12:Constraint
16:exp
16:exp 15:nce
14:node
end 15:nce
variable
NAC
12:Constraint
:VariableDeclaration varName=vname
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
11:NavigationCallExp
:Classifier 1:CollectionRole
navSource
:NavigationRoleExp
NAC
Abb. 5.167: ShortCut für count
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 213
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.
214 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R
InsertCollectShortCut1(opname:OpEnum, attrname:String)
1:CollectionRole
1:CollectionRole
attribute
3:Attribute name=attrname
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.
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 215
L R
InsertSortedByShortCut(opname:OpEnum, attrname:String)
1:CollectionRole
1:CollectionRole
attribute 3:Attribute name=attrname
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=#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.
216 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
L R
1:CollectionRole
:ShortCutLoopExp name=#loopexpname
type
navSource
InsertBoolResultShortCut(loopexpname:LoopEnum)
loopexpname= #forall v #exists v #one v #isUnique
:Classifier name="Boolean"
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
:Classifier name="Boolean"
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.
5.3. SYNTAXGRAMMATIKREGELN VON VOCL 217
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.
218 KAPITEL 5. SPEZIFIKATION VON VOCL MIT GRAPHTRANSFORMATION
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.,
222 KAPITEL 6. VERGLEICH
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
6.2. CONSTRAINTS <-> REGELN 223
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-
224 KAPITEL 6. VERGLEICH
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.
6.2. CONSTRAINTS <-> REGELN 225
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
226 KAPITEL 6. VERGLEICH
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.
6.2. CONSTRAINTS <-> REGELN 227
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
228 KAPITEL 6. VERGLEICH
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,
6.2. CONSTRAINTS <-> REGELN 229
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:
230 KAPITEL 6. VERGLEICH
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
6.2. CONSTRAINTS <-> REGELN 231
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
232 KAPITEL 6. VERGLEICH
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:
6.2. CONSTRAINTS <-> REGELN 233
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:
234 KAPITEL 6. VERGLEICH
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
6.2. CONSTRAINTS <-> REGELN 235
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.
236 KAPITEL 6. VERGLEICH
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,
6.2. CONSTRAINTS <-> REGELN 237
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
238 KAPITEL 6. VERGLEICH
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.
6.2. CONSTRAINTS <-> REGELN 239
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-
240 KAPITEL 6. VERGLEICH
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
6.2. CONSTRAINTS <-> REGELN 241
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)
242 KAPITEL 6. VERGLEICH
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
Die Ungleichheit zweier Objekte wird in VOCL dadurch ausgedrückt, dass sie verschiedene Namenhaben.
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
250 ANHANG A. THE VOCL STANDARD LIBRARY
object: OclType object2: OclType
Die Ungleichheit zweier Objekte wird in VOCL dadurch ausgedrückt, dass sie verschiedene Namenhaben.
• 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
252 ANHANG A. THE VOCL STANDARD LIBRARY
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
collection:Collection(T)
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
collection:Collection(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
collection:Collection(T)
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
collection:Collection(T)
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.
254 ANHANG A. THE VOCL STANDARD LIBRARY
• 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.
A.4. COLLECTION-RELATED TYPES 255
• 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.
256 ANHANG A. THE VOCL STANDARD LIBRARY
• 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
A.4. COLLECTION-RELATED TYPES 257
#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)
258 ANHANG A. THE VOCL STANDARD LIBRARY
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.
A.4. COLLECTION-RELATED TYPES 259
• 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)
260 ANHANG A. THE VOCL STANDARD LIBRARY
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)
A.4. COLLECTION-RELATED TYPES 261
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)
262 ANHANG A. THE VOCL STANDARD LIBRARY
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)
A.4. COLLECTION-RELATED TYPES 263
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
264 ANHANG A. THE VOCL STANDARD LIBRARY
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)
A.4. COLLECTION-RELATED TYPES 265
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.
266 ANHANG A. THE VOCL STANDARD LIBRARY
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
268 ANHANG A. THE VOCL STANDARD LIBRARY
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
A.5. PREDEFINED OCLITERATOR LIBRARY 269
: 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)
270 ANHANG A. THE VOCL STANDARD LIBRARY
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
A.5. PREDEFINED OCLITERATOR LIBRARY 271
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
272 ANHANG A. THE VOCL STANDARD LIBRARY
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.
A.5. PREDEFINED OCLITERATOR LIBRARY 273
• 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)
274 ANHANG A. THE VOCL STANDARD LIBRARY
: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.
A.5. PREDEFINED OCLITERATOR LIBRARY 275
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
276 ANHANG A. THE VOCL STANDARD LIBRARY
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
Top Related