Inhaltsverzeichnis

OCL  - Die Object Constraint Language  

   1

Ste  ffen Hildebrandt  

1  Einf uhrung  4

1.1  Was UML kann  4

1.2  Was UML fehlt  5

1.3  Einf uhrungsbeispiel  6

1.4  Allgemeines zu OCL  7

2  Formale Grundlagen  7

2.1  Objektmodelle  7

2.2  Systemzust ande  8

3  Ausdr ucke in OCL  9

3.1  OCL-Datentypen  9

3.2  Operationen auf Basistypen.  10

3.3  Operationen auf Collection-Typen  11

4  Die Sprache OCL  12

4.1  Allgemeines  12

4.2  Invarianten  13

Syntax   13

Beispiele   13

4.3  Preconditions  14

Syntax   14

Beispiele   14

4.4  Postconditions  15

Syntax   15

Beispiele   15

5  Arbeiten mit OCL  15

5.1  Anwendung von OCL  15

5.2  Allgemeines  16

5.3  Dresden OCL  16

6  Fazit  17

6.1  Einordnung in das Thema Knowledge Representation and  

Reasoning   17

6.2  Grenzen von OCL  17

6.3  Bewertung  17

A  Großes Beispiel zu OCL  19

A.1  Person  19

A.2  Spieler  19

A.3  Verein  22

A.4  Vertrag  25

A.5  Datum  26

A  6 Spiel  27

Die Object Constraint Language 3

A.7 Beispiel f¨ ur die ModelInstanceProviderClass in DresdenOCL . . . . 28

4 Steffen Hildebrandt 1 Einf¨ uhrung

Die Unified Modelling Language (UML) ist eine graphische Modellierungssprache 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 ihr ¹ als auch von der ISO standardisiert[2]. In diesem ersten Abschnitt soll ein kurzer ¨ Uberblick dar¨ uber gegeben werden, was

mit UML m¨ oglich ist, aber auch, warum insbesondere in Bezug auf die objekt-orientierte Programmierung eine Erweiterung von N¨ oten 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 ¨ Ubersicht uber diese Diagramme. ¨

Abbildung 1. ¨ Ubersicht ¨ uber die verschiedenen Diagramm-Typen in UML[5]

Verhaltensdiagramme beschreiben die Arbeitsweise eines Programms oder auch die Abl¨ aufe und Prozesse innerhalb eines Systems und sind meistens ein erster Schritt auf dem Weg der Softwareentwicklung. H¨ aufig benutzte Typen sind das Use-Case-Diagramm, das Aktivit¨ atsdiagramm, 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¨ aufigsten benutzten Diagrammen geh¨ ort das Klassendiagramm (ein Strukturdiagramm), das oft zur Modellierung objektorientierter Software

¹ http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML

Die Object Constraint Language 5

benutzt wird. Mit Hilfe von Klassendiagrammen ist es m¨ oglich, Klassen zusammen mit ihren Attributen und Operationen abzubilden und dar¨ uber hinaus vielf¨ altige Arten von Beziehungen zwischen diesen Klassen darzustellen. Diese Beziehungen k¨ onnen zum Beispiel Generalisierungen, aber auch Assoziationen und Abh¨ angigkeiten sein, bei denen beiden Enden oft sogenannte Rollennamen gegeben werden.[3]

Abschnitt 2.1 gibt einen ausf¨ uhrlicheren Einblick in die formale Beschreibung von Objektmodellen, einer Verallgemeinerung von Klassendiagrammen. Abbildung 2 zeigt ein Beispiel f¨ ur ein Klassendiagramm, das die Grundlage f¨ ur ein Softwareprojekt zur Simulation von Profifußball sein k¨ onnte.

1.2 Was UML fehlt

Am Beispiel in Abbildung 2 ist zu sehen, dass mit Hilfe von Klassendiagrammen die Idee f¨ ur eine Software graphisch dargestellt werden kann, sodass die Struktur des Programms f¨ ur den Programmierer ¨ ubersichtlicher und klarer wird. Dar¨ uber

hinaus k¨ onnte man mit weiteren UML-Diagrammen Abl¨ aufe festhalten, wie zum Beispiel die m¨ ogliche Karriere eines Fußballspielers oder den Verlauf von Ver- tragsverhandlungen. Allerdings kann UML nur die Struktur sowie eventuell noch

6 Steffen Hildebrandt

einige Arbeitsabl¨ aufe eines Projekts darstellen, was fehlt, sind vor allem logische Eingrenzungen. So kann UML zwar ausdr¨ ucken, dass eine Klasse Person die Attribute name : String und alter : Integer besitzt, aber es gibt keine M¨ oglichkeit, ein Objekt vom Typ Person mit negativem Alter zu verbieten. Es handelt sich hierbei also um eine Bedingung, die f¨ ur den gesamten Programmablauf gelten muss, eine sogenannte Invariante: ” Das Alter einer Person darf nicht negativ sein.“

Neben solchen Bedingungen k¨ onnte es aber auch sein, dass der Ersteller eines UML-Modells bestimmte Methoden genauer spezifizieren m¨ ochte. Zum Beispiel soll festgelegt werden, dass das Gehalt eines Fußballspielers nach einer Gehaltserh¨ ohung auch tats¨ achlich um den angegebenen Betrag erh¨ oht ist. Es handelt sich hier um eine sogenannte Postcondition, eine Bedingung, die nach der Ausf¨ uhrung einer Methode gelten muss. Analog zu Postconditions soll es auch Preconditions geben, die zu Beginn einer Methodenausf¨ uhrung gelten. Genau diese drei Arten von Bedingungen (Invarianten, Pre- und Postconditions) stellen der Kern der Object Constraint Language (OCL) dar, die damit eine m¨ achtige Erweiterung zu UML darstellt.

1.3 Einf¨ uhrungsbeispiel

Das folgende UML-Klassendiagramm ist eine Vereinfachung des Beispiels aus Abbildung 2 und liegt den Beispielen in Abschnitt 2 und 4 zu Grunde.

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¨ arend. Die Operation gesamtvermoegen():Integer der

Die Object Constraint Language 7

Klasse Verein soll als Ergebnis das Bankguthaben des Vereins addiert mit dem Gesamtwert aller Spieler des Vereins zur¨ uckgeben.

1.4 Allgemeines zu OCL

Die Object Constraint Language ist rein formal, wie der Name schon sagt, eine Programmiersprache, die f¨ ur Objekte (die in der Regel aus einem UML-Modell stammen) Constraints definiert. F¨ ur den englischen Begriff ” Constraint“ wird

im Deutschen oft Zusicherung oder (Rand)Bedingung benutzt, da aber keine ¨ Ubersetzung das Wort in seiner vollen Bedeutung trifft, wird im Folgenden weiterhin von ” Constraints“ gesprochen.

Die erste Version von OCL wurde von IBM entwickelt und im Jahr 1995 erstmals vorgestellt. Bereits zwei Jahre sp¨ ater wurde sie in den UML-Standard (damals UML-Version 1.1) aufgenommen und ist heute allgemein anerkannt. Die

aktuelle Version ² ist OCL 2.2. Diese Ausarbeitung bezieht sich in erster Linie auf die Version 1.1, die bereits alle grundlegenden Prinzipien enthielt und sp¨ ater, insbesondere mit Version 2.0, nur noch in ihrem Funktionsumfang erweitert wurde.

Im Folgenden wird in Abschnitt 2 eine kurze Einf¨ uhrung in die formalen Grundlagen gegeben, wobei insbesondere die Begriffe des Objektmodells und des Systemzustands n¨ aher erl¨ autert werden. In Abschnitt 3 werden die in OCL vordefinierten Datentypen zusammen mit ihren Operationen vorgestellt, woraufhin in Abschnitt 4 dann die verschiedenen Constraints beschrieben werden. Ein gr¨ oß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 ¨ Uberblick ¨ uber 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¨ autert. Ein Objektmodell M ist ein 8-Tupel[6]

M = (CLASS, ATT C , OP C , ASSOC, associates, roles, multiplicities, ≺) wobei gilt:

CLASS ist eine Menge von Namen, hier also die Menge aller Klassen in unserem Diagramm.

² http://www.omg.org/spec/OCL/2.2/

8 Steffen Hildebrandt CLASS = {Person, Spieler, Verein}

ATT C 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.

ATT Person = {name : Person → String, alter : Person → Integer}

OP C ist eine Menge der Signaturen aller ” benutzerdefinierten“ Operationen der Klasse C, die keine Seiteneffekte haben.

OP Verein = {gesamtvermoegen(): Integer, equals(verein: Verein): Boolean}

ASSOC ist eine Menge von Namen f¨ ur Assoziationen. ASSOC = {hatUnterVertrag}

associates ist eine Funktion, die jeder Assoziation eine Liste der betreffenden Klassen zuordnet.

associates : hatUnterVertrag → (Verein, Spieler)

roles ist eine Funktion, die jedem Endpunkt einer Assoziation einen Rollennamen zuweist.

roles : hatUnterVertrag → (verein, spieler)

multiplicities ist eine Funktion, die jedem Endpunkt einer Assoziation eine Vielfachheit zuweist.

multiplicities : hatUnterVertrag → (1, N 0 )

≺ ist eine partielle Ordnung, die die hierarchische Beziehung zwischen den Klassen des Modells widerspiegelt. ≺= {(Spieler, Person)}

2.2 Systemzust¨ ande

Ein Objektmodell beschreibt die Struktur eines Programms und ver¨ andert sich auch nicht im Verlauf der Programmausf¨ uhrung. Unter Betrachtung dieser Programmausf¨ uhrung kann aber ein sogenannter Systemzustand definiert werden, der auf dem zugrunde liegenden Objektmodell basiert: Ein Systemzustand σ f¨ ur ein Objektmodell M ist ein 3-Tupel[6]

σ(M) = (σ CLASS , σ AT T , σ ASSOC )

wobei

σ CLASS (c) alle Objekte der Klasse c ∈ CLASS enth¨ alt, die in dem aktuellen Systemzustand existieren,

σ ATT eine Funktion darstellt, die jedem existierenden Objekt seine aktuellen Attributswerte zuordnet,

σ ASSOC (as) f¨ ur jede Assoziation as ∈ ASSOC alle durch sie verbundenen Objekte enth¨ alt.

Die Programmausf¨ uhrung besteht dann aus einer Folge verschiedener Systemzust¨ ande. Aus umgekehrter Sicht betrachtet ist ein Systemzustand also ein Schnappschuss“ des Speichers, der alle zu diesem Zeitpunkt bestehenden Ob-”

jekte sowie die zwischen ihnen bestehenden Assoziationen enth¨ alt.