Leseprobe
Inhaltsverzeichnis
OCL - Die Object Constraint Language
Steffen Hildebrandt
1 Einführung
1.1 Was UML kann
1.2 Was UML fehlt
1.3 Einführungsbeispiel
1.4 Allgemeines zu OCL
2 Formale Grundlagen
2.1 Objektmodelle
2.2 Systemzustände
3 Ausdrücke in OCL
3.1 OCL-Datentypen
3.2 Operationen auf Basistypen
3.3 Operationen auf Collection-Typen
4 Die Sprache OCL
4.1 Allgemeines
4.2 Invarianten
Syntax
Beispiele
4.3 Preconditions
Syntax
Beispiele
4.4 Postconditions
Syntax
Beispiele
5 Arbeiten mit OCL
5.1 Anwendung von OCL
5.2 Allgemeines
5.3 Dresden OCL
6 Fazit
6.1 Einordnung in das Thema Knowledge Representation and
Reasoning
6.2 Grenzen von OCL
6.3 Bewertung
A Großes Beispiel zu OCL
A.1 Person
A.2 Spieler
A.3 Verein
A.4 Vertrag
A.5 Datum
A.6 Spiel
Die Object Constraint Language
A.7 Beispiel für die ModelInstanceProviderClass in DresdenOCL
1 Einführung
Die Unified Modelling Language (UML) ist eine graphische Modellierungsspra- che zur Spezifikation, Konstruktion und Dokumentation von Teilen von Software und anderen Systemen.[1]Sie wird von der Object Management Group (OMG) entwickelt und ist sowohl von ihr1 als auch von der ISO standardisiert[2]. In diesem ersten Abschnitt soll ein kurzer Überblick darüber gegeben werden, was mit UML möglich ist, aber auch, warum insbesondere in Bezug auf die objekt- orientierte Programmierung eine Erweiterung von Nöten ist.
1.1 Was UML kann
In UML gibt es 13 verschiedene Diagramm-Typen, welche in Verhaltensdiagramme und Strukturdiagramme unterteilt werden. Abbildung 1.1 zeigt eine Übersicht über diese Diagramme.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1. Übersicht über die verschiedenen Diagramm-Typen in UML[5]
Verhaltensdiagramme beschreiben die Arbeitsweise eines Programms oder auch die Abläufe und Prozesse innerhalb eines Systems und sind meistens ein erster Schritt auf dem Weg der Softwareentwicklung. Häufig benutzte Typen sind das Use-Case-Diagramm, das Aktivitätsdiagramm, sowie das Sequenzdiagramm. Dagegen wird bei Strukturdiagrammen die programmiertechnische Struktur von Software betrachtet, was sowohl zu Beginn der Entwicklung stehen, als auch ein finaler Schritt hin zur Implementierung sein kann.
Zu den am häufigsten benutzten Diagrammen gehört das Klassendiagramm (ein Strukturdiagramm), das oft zur Modellierung objektorientierter Software benutzt wird. Mit Hilfe von Klassendiagrammen ist es möglich, Klassen zu- sammen mit ihren Attributen und Operationen abzubilden und darüber hinaus vielfältige Arten von Beziehungen zwischen diesen Klassen darzustellen. Diese Beziehungen können zum Beispiel Generalisierungen, aber auch Assoziationen und Abhängigkeiten sein, bei denen beiden Enden oft sogenannte Rollennamen gegeben werden.[3]
Abschnitt 2.1 gibt einen ausführlicheren Einblick in die formale Beschreibung von Objektmodellen, einer Verallgemeinerung von Klassendiagrammen. Abbildung 2 zeigt ein Beispiel für ein Klassendiagramm, das die Grundlage für ein Softwareprojekt zur Simulation von Profifußball sein könnte.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2. Großes Beispiel zu UML
1.2 Was UML fehlt
Am Beispiel in Abbildung 2 ist zu sehen, dass mit Hilfe von Klassendiagrammen die Idee für eine Software graphisch dargestellt werden kann, sodass die Struktur des Programms für den Programmierer übersichtlicher und klarer wird. Darüber hinaus könnte man mit weiteren UML-Diagrammen Abläufe festhalten, wie zum Beispiel die mögliche Karriere eines Fußballspielers oder den Verlauf von Ver- tragsverhandlungen. Allerdings kann UML nur die Struktur sowie eventuell noch einige Arbeitsabläufe eines Projekts darstellen, was fehlt, sind vor allem logi- sche Eingrenzungen. So kann UML zwar ausdrücken, dass eine Klasse Person die Attribute name : String und alter : Integer besitzt, aber es gibt keine Möglichkeit, ein Objekt vom Typ Person mit negativem Alter zu verbieten. Es handelt sich hierbei also um eine Bedingung, die für den gesamten Programmab- lauf gelten muss, eine sogenannte Invariante: nicht negativ sein.“
Neben solchen Bedingungen könnte es aber auch sein, dass der Ersteller ei- nes UML-Modells bestimmte Methoden genauer spezifizieren möchte. Zum Bei- spiel soll festgelegt werden, dass das Gehalt eines Fußballspielers nach einer Gehaltserhöhung auch tatsächlich um den angegebenen Betrag erhöht ist. Es handelt sich hier um eine sogenannte Postcondition, eine Bedingung, die nach der Ausführung einer Methode gelten muss. Analog zu Postconditions soll es auch Preconditions geben, die zu Beginn einer Methodenausführung gelten.
Genau diese drei Arten von Bedingungen (Invarianten, Pre- und Postconditions) stellen der Kern der Object Constraint Language (OCL) dar, die damit eine mächtige Erweiterung zu UML darstellt.
1.3 Einführungsbeispiel
Das folgende UML-Klassendiagramm ist eine Vereinfachung des Beispiels aus Abbildung 2 und liegt den Beispielen in Abschnitt 2 und 4 zu Grunde.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3. Vereinfachtes Beispiel
Das Beispiel zeigt die drei Klassen Person, Spieler und Verein, wobei Spieler von Person abgeleitet ist. Die meisten Attribute und Operationen der Klassen sind selbsterklärend. Die Operation gesamtvermoegen():Integer der Klasse Verein soll als Ergebnis das Bankguthaben des Vereins addiert mit dem Gesamtwert aller Spieler des Vereins zurückgeben.
1.4 Allgemeines zu OCL
Die Object Constraint Language ist rein formal, wie der Name schon sagt, eine Programmiersprache, die für Objekte (die in der Regel aus einem UML-Modell stammen) Constraints definiert. Für den englischen Begriff ”Constraint“wird im Deutschen oft Zusicherung oder (Rand)Bedingung benutzt, da aber keine ÜbersetzungdasWortinseinervollenBedeutungtrifft,wirdimFolgendenwei- terhin von ”Constraints“gesprochen.
Die erste Version von OCL wurde von IBM entwickelt und im Jahr[1995]erstmals vorgestellt. Bereits zwei Jahre später wurde sie in den UML-Standard (damals UML-Version1.1) aufgenommen und ist heute allgemein anerkannt. Die aktuelle Version2 ist OCL 2.2. Diese Ausarbeitung bezieht sich in erster Linie auf die Version 1.1, die bereits alle grundlegenden Prinzipien enthielt und später, insbesondere mit Version 2.0, nur noch in ihrem Funktionsumfang erweitert wur- de.
Im Folgenden wird in Abschnitt 2 eine kurze Einführung in die formalen Grundlagen gegeben, wobei insbesondere die Begriffe des Objektmodells und des Systemzustands näher erläutert werden. In Abschnitt 3 werden die in OCL vor- definierten Datentypen zusammen mit ihren Operationen vorgestellt, worauf- hin in Abschnitt 4 dann die verschiedenen Constraints beschrieben werden. Ein größeres Beispiel dazu findet sich im Anhang zu dieser Ausarbeitung. Schließlich folgen in Abschnitt 5 einige Worte zu der Arbeit mit OCL, sowie das Fazit in Abschnitt 6.
2 Formale Grundlagen
Dieser Abschnitt soll einen kurzen Überblick über die formalen Definitionen eines Objektmodells (engl. object model) und eines Systemzustands (engl. system state) geben.
2.1 Objektmodelle
Klassendiagramme in UML sind ein Werkzeug zur Darstellung von Objektmodellen, daher wird hier kurz die Definition eines Objektmodells erläutert. Ein Objektmodell M ist ein 8-Tupel[6]
Abbildung in dieser Leseprobe nicht enthalten
CLASS ist eine Menge von Namen, hier also die Menge aller Klassen in unserem Diagramm.
CLASS = { Person , Spieler , Verein }
ATTC ist eine Menge der Signaturen aller Operationen, die die Klasse C auf einen assoziierten Wert abbilden. Diese Operationen entsprechen praktisch den Namen der Attribute der Klasse.
ATTPerson = { name : Person [Abbildung in dieser Leseprobe nicht enthalten] String , alter : Person [Abbildung in dieser Leseprobe nicht enthalten] Integer }
OPC ist eine Menge der Signaturen aller ”benutzerdefinierten“Operationender Klasse C, die keine Seiteneffekte haben.
OPVerein = { gesamtvermoegen(): Integer , equals(verein: Verein): Boolean } ASSOC ist eine Menge von Namen für Assoziationen.
ASSOC = { hatUnterVertrag }
associates ist eine Funktion, die jeder Assoziation eine Liste der betreffenden Klassen zuordnet.
associates : hatUnterVertrag [Abbildung in dieser Leseprobe nicht enthalten] (Verein , Spieler)
roles ist eine Funktion, die jedem Endpunkt einer Assoziation einen Rollenna- men zuweist.
roles : hatUnterVertrag [Abbildung in dieser Leseprobe nicht enthalten] (verein , spieler)
multiplicities ist eine Funktion, die jedem Endpunkt einer Assoziation eine Viel- fachheit zuweist.
multiplicities : hatUnterVertrag [Abbildung in dieser Leseprobe nicht enthalten] (1 , N0)
- ist eine partielle Ordnung, die die hierarchische Beziehung zwischen den Klas- sen des Modells widerspiegelt.
- = { (Spieler , Person) }
[...]
1 http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML
2 http://www.omg.org/spec/OCL/2.2/