C.3 OCL

C.3.1 Syntax der OCL

Da die OCL eine textuelle Sprache ist, wird für ihre Definition die Erweiterte Backus-Naur-Form (EBNF) verwendet. Die in diesem Kapitel vorgestellte OCL/P besitzt einige signifikante syntaktische Unterschiede zur OCL in der Standarddefinition [OMG10b], die sich vor allem durch die syntaktische Annäherung an die Zielprogrammiersprache Java und konzeptuellen Verbesserungen erklären. Diese Unterschiede werden in Abschnitt C.3.2 im Detail erklärt.

Die OCL ist eine auf dem ASCII-Alphabet basierende Sprache. Zwar werden zur besseren Lesbarkeit Schlüsselwörter wie forall in einem anderem Layout dargestellt, jedoch werden keine mathematischen Sonderzeichen wie ∀ genutzt. Die Praxis der Softwareentwicklung zeigt, dass die Verwendung einer Spezifikationssprache, die ähnlich einer Programmmiersprache aussieht und damit einem in Programmiersprachen geübten Modellierer bekannt vorkommt, eine deutlich niedrigere Hürde zu ihrer Verwendung darstellt.

Diese Hürde wurde für OCL/P weiter verringert, indem die in Java und OCL gemeinsamen Modellierungskonzepte in dieselbe syntaktische Form gebracht wurden. Deshalb kann die nachfolgende OCL-Grammatik an mehreren Stellen durch Verweise in die in Anhang B gegebene Java-Grammatik erklärt werden.

OCL-Bedingungen können in OCL-Dokumenten gesammelt werden oder als Bedingungen innerhalb von anderen Diagrammen und in Java als Invarianten auftreten. Deshalb existiert in UML/P eine Dokumentart ⟨OCL⟩ für OCL-Bedingungen.

Der UML-Standard sieht auch vor, dass OCL-Bedingungen als Annotationen für Klassen und Methoden innerhalb von Klassendiagrammen verwendet werden können. Die Praxis und auch der UML-Standard selbst zeigen jedoch, dass dies leicht zu einer Überladung der Diagramme führt. Eine Separation der OCL-Bedingungen in eigenständige Dokumente oder Dokumentabschnitte ist daher oft ratsam. Das Aussehen solcher Dokumente wurde mit den Abbildungen 3.30 und 3.17 bereits illustriert. Die parallele Bearbeitung dieser Dokumente kann durch geeignete Werkzeuge, wie etwa dem in [HRR99] beschriebenen Editor-Framework, gut unterstützt werden.

In Abbildung C.7 ist die oberste Ebene der OCL-Grammatik beschrieben. Ein OCL-Dokument besteht aus einer Sammlung von Invarianten und Methodenspezifikationen. Methoden können in einem OCL-Dokument mit Merkmalen und Stereotypen attributiert werden. Dadurch ist es möglich, Hilfsfunktionen, die zur Beschreibung von Bedingungen verwendet werden können, direkt in OCL-Dokumenten zu definieren, ohne dass diese in der Implementierung oder in Klassendiagrammen erscheinen müssen.

Die Bedingungssprache OCL besteht im Wesentlichen aus einer Sammlung von Sprachkonzepten für die Definition von Ausdrücken mit booleschen Werten. Deshalb sind die Nichtterminale ⟨OCLExpr⟩ und ⟨OCLPrimeExpr⟩ entsprechend komplex aufgebaut.²

Im Prinzip ist es möglich als Bedingungen direkt Java-Ausdrücke einzusetzen, die um einige OCL-spezifische Konstrukte erweitert werden. Jedoch gibt es bei den Java-Ausdrücken neben den Operatoren ++ und -- sowie der Zuweisung, die jeweils Seiteneffekte haben, auch Konstrukte zur Erzeugung neuer Objekte und Arrays, die in OCL-Bedingungen nicht verwendet werden. Dies könnte durch geeignete Kontextbedingungen ausgedrückt werden. Es ist jedoch sinnvoller, diese Unterschiede entsprechend Abbildung C.9 direkt in der Grammatik zu verankern, in der ein eigenes Nichtterminal ⟨OCLPrimary⟩ verwendet wird, das analog zu ⟨PrimaryB.6⟩ aufgebaut ist. Die letzte Alternative des Nichtterminals ⟨OCLPrimary⟩ dient zur Integration der OCL mit Objektdiagrammen und wird in Kapitel 4 diskutiert.

In der OCL spielen Container eine wesentliche Rolle. Deshalb sind die Möglichkeiten, Ausdrücke mit Containern zu definieren, in Abbildung C.10 zusammengefasst. Mit dem Nichtterminal ⟨CollectionExpr⟩ werden Quantoren und andere Spezialoperationen für Container beschrieben. Das Nichtterminal ⟨Comprehension⟩ beschreibt die Varianten zur Aufzählung von Containerelementen und zu deren eigenschaftsorientierter Beschreibung in Form einer Komprehension. Neben dem bereits bekannten ⟨OCLVarDeclarator⟩ zur Einführung einer Variablen im let-Konstrukt können neue Variablen mit dem Nichtterminal ⟨SetVarDeclaration⟩ eingeführt werden. Diese Form der Variablendeklaration wird genutzt, um eine Variable über die Elemente eines Containers variieren zu lassen.

Wie bereits erwähnt, haben die Grammatiken der Sprachen Java und OCL viele strukturelle und inhaltliche Übereinstimmungen. Die gemeinsam genutzten und die strukturell ähnlichen Nichtterminale sind in Tabelle C.11 zusammengefasst.

C.3.2 Unterschiede zu dem OCL-Standard

Um die Lesbarkeit und damit die Benutzbarkeit der OCL zu erhöhen, sowie die Integration mit der Zielsprache Java zu verbessern, wurden eine Reihe konzeptueller und syntaktischer Änderungen an der OCL gegenüber dem in [OMG10b] definierten Standard vorgenommen. Die wichtigsten Änderungen sind in Tabelle C.12 zusammengefasst.

Anmerkungen zu den Unterschieden in Tabelle C.12:

1. Der Datentyp String wird in der OCL/P nicht als Grunddatentyp betrachtet, sondern als normale Klasse. Neben der Änderung der restlichen Typnamen wurden auch die zur Verfügung stehenden Konstanten und Operationen an Java angepasst.
2. OLC/P besitzt generische Typen analog zu Java.
3. Aufzählungen werden in Java durch Konstanten und deren definierenden Klassen simuliert. OCL/P bietet ebenfalls nur simulierte Aufzählungstypen. Die Zusammenfassung aller Werte von Aufzählungstypen in Enumeration im OCL-Standard hatte demgegenüber den Nachteil, dass weitere Typisierungsinformation fehlt.
4. Der Datentyp Bag für Multimengen wurde aus pragmatischen Gründen weggelassen. Häufig werden diese Multimengen nicht benötigt und die dann explizit notwendige Konversion in Mengen fällt so weg. Die Signaturen der Container-Typen wurden außerdem mit den aus Java bekannten Klassen integriert. Tabelle C.13 zeigt einen Vergleich für Mengenoperatoren. In der OCL/P wurden vor allem solche Operatoren aus Standard-Java weggelassen, die durch einfaches Voranstellen der Negation nachgebildet werden können.
5. Die Anwendung von OCL-eigenen Operatoren auf Container-Strukturen wird im OCL-Standard grundsätzlich durch -> eingeleitet. Dies wurde mit syntaktischer Erkennbarkeit der OCL-Operatoren begründet, ist aber prinzipiell unnötig, da diese bereits am Namen erkannt werden.
6. Der Operator instanceof wird in Kombination mit typeif angeboten, um damit eine implizite und damit sichere vorzunehmen, wenn das Argument den beschriebenen Typ besitzt.
7. Die Möglichkeiten der Mengen- und Listenkomprehension wurden wesentlich ausgeweitet. Sie erlauben Generatoren, Filter und Zwischenvariablen zu definieren.
8. Der flatten-Operator wird nicht rekursiv angewandt, sondern verflacht nur die oberste Ebene.
9. OCL/P ist in Bezug auf angebotene Operatoren schlanker als der OCL-Standard, da einige der Operatoren in eine Bibliothek ausgelagert wurden. Dies erhöht gleichzeitig die Flexibilität der OCL/P, da so auch benutzerspezifische Operatoren definiert werden können.

Über die in der Tabelle C.12 angegebenen Unterschiede hinaus wurden folgende Veränderungen vorgenommen:

• Die Verwendung des let-Konstrukts wurde konsolidiert und die in der UML 1.4 eingeführte definierende Bedingung (Stereotyp ≪definition≫) zugunsten des Stereotyps ≪OCL≫ weggelassen.
• Assoziationsklassen werden bereits in UML/P-Klassendiagrammen nicht verwendet. Daher existiert auch keine Navigation zu solchen Klassen.
• Die Einbettung von OCL-Bedingungen in einen Package-Kontext kann bereits durch explizite Angabe des Package-Namens bei einem Klassenkontext vorgenommen werden und ist daher in UML/P unnötig.
• Die Typisierungsregeln wurden an einigen Stellen präzisiert. So war im OCL-Standard nicht festgelegt, wie heterogene Aufzählungen der Form Set{"text",person} zu typisieren sind.
• Die OCL-Logik wurde an die Möglichkeiten von Java angepasst, indem die Interpretation mit einem undefinierten Wert als Ergebnis wie ein false behandelt wird. Dazu wurde der Liftingoperator eingeführt, der eine zweiwertige Logik erlaubt.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012