Einführung in die

Unified Modeling Language (UML)

Hausarbeit zum Proseminar „Datenbanken“

Wintersemester 2002/03

Seminarleitung: Dr. Christoph Draxler

Verfasserin: Michaela Geierhos

Centrum für Informations- und Sprachverarbeitung

LMU München

27. Januar 2003

INHALTSVERZEICHNIS ii Inhaltverzeichnis Vorwort ........................................................................................................... iii

1. Einleitung ............................................................................................... 1

1.1 Was ist die UML eigentlich? ....................................................... 1

1.2 Einblick in die Entstehung von UML ......................................... 2

2. Ein Auszug aus der UML-Terminologie ............................................... 3

2.1 Objekt .......................................................................................... 3

2.2 Klasse ........................................................................................... 5

2.3 Attribut ......................................................................................... 7

2.4 Operation ..................................................................................... 9

2.5 Assoziation .................................................................................. 11

3. Darstellung am Beispiel des Klassendiagramms ................................... 14

4. UML 1.4 – Notationstechniken im Überblick ....................................... 15

Anhang

Notationsübersicht der UML 1.4 ............................................................ 16

Glossar .................................................................................................... 20

Literaturverzeichnis ................................................................................. 22

VORWORT iii Vorwort Das Ziel dieser Hausarbeit ist es einen knappen und übersichtlichen Einblick in die Objektmodellierungssprache UML (Unified Modeling Language) zu geben. Da aber eine Fülle an begleitendem Informationsmaterial dazu existiert, habe ich mich in meinen Ausführungen auf das Wesentliche beschränkt – die graphische Notation der UML, welche laut Martin Fowler unverzichtbar ist, wenn man in kurzer Zeit vernünftige Aussagen über ein Projekt machen soll. Er selbst sieht die UML als ein Mittel der sinnvollen Kommunikation zwischen dem Auftraggeber und dem Softwareentwickler [Fowler/Scott 2000: 6].

Ich [Martin Fowler] benutze die UML, weil sie mir ermöglicht, bestimmte Konzepte klarer darzustellen, als es mit den Alternativen möglich wäre. Die natürliche Sprache ist zu unpräzise und wird bei komplexeren Konzepten schnell verwirrend. Code ist präzise, aber zu detailliert. So benutze ich die UML für einen bestimmten Grad an Präzision, ohne mich in Details zu ver-lieren. Das heißt nicht, ich vermeide Details. Statt dessen hebe ich mit der UML wichtige Details hervor.

Ähnlich wie bei den Relationalen Datenbanken das ER-Diagramm zum Einsatz kommt, um eine ersten Datenbankentwurf auf dem Papier zu machen und die im Kopf entstandenen Ideen zu visualisieren, ermöglicht die UML diesen Zweck für die Objektorientierten Datenbanken, so dass der Auftraggeber – eventuell ein Laie – verstehen kann, wie die zu entwickelnde Software funktionieren wird und kann schließlich ersehen, ob sie die an sie gestellten Anforderungen auch wirklich erfüllt. Außerdem lassen sie mögliche Änderungen oder zusätzlich Wünsche des Kunden viel einfacher bei einem Programmentwurf in UML-Diagrammnotation verwirklichen als bei einem vollständig kodiertem Programm in Java oder C++. Denn der Entwurf auf dem Papier lässt sich jeder Zeit problemlos wieder korrigie-ren, ohne die Kosten für das jeweilige Projekt in die Höhe zu treiben. Somit ist es auf jeden Fall sinnvoll, die UML-Notation zu erlernen, wenn man mit objektorientierten Datenbanksystemen arbeiten muss bzw. will.

1.1 WAS IST DIE UML EIGENTLICH? 1 1. Einleitung

1.1 Was ist die UML eigentlich?1

Der Name UML (Unified Modeling Language) tritt erstmals 1996 in Er-scheinung und ist im Grunde eine Kreation von drei Herren – Grady Booch, James Rumbaugh und Ivar Jacobson. Sie ist eine Modellierungssprache, die ihre Anwendung im objektorientierten Softwareentwicklungsbereich findet und gleichzeitig ein beliebtes Hilfsmittel, Datenbankentwürfe gra-fisch darzustellen, ohne diese gleich in einer Programmiersprache zu kodie-ren.

Tom Hadfield bringt es auf den Punkt: OO [objektorientierte] -Sprachen haben zwar keine Vorteile, ermöglichen sie aber ...2

Nicht zu verwechseln ist die UML mit einer Methode; denn zu einer Me-thode gehören immer die Modellierungssprache selbst und ein Prozess. Dieser umfasst nur die Anleitung für einen Programm- bzw. Datenbankent-wurf, d.h. was zu tun ist, bis der Entwurf endgültig steht. Die Schöpfer der UML haben auch einen einheitlichen Prozess entwickelt – den Rational Unified Process (RUP). Generell gilt aber, dass Modellierungssprache und Prozess getrennt voneinander benutzt werden können, und deshalb lasse ich den Prozess an sich bei der Erläuterung der UML außer Acht.

1 Frei nach [Fowler/Scott 2000: 1] 2 [Fowler/Scott 2000: 7]

1.2 EINBLICK IN DIE ENTSTEHUNG VON UML 2

1.2 Einblick in die Entstehung von UML

Anfang der neunziger Jahre gab es viele kleine Gruppen von Entwicklern, die jeweils ihre eigenen Techniken bei der Analyse und beim Entwurf von Software verfochten und sich nicht dazu überreden ließen, diese Methoden zu vereinheitlichen, obwohl sie alle einander ziemlich ähnlich waren. Doch wer wollte sie überhaupt von solch einem Standard überzeugen? Dieser Mann war Grady Booch, Entwickler bei der Rational Software Cor-poration, der es bereits 1994 seinen ersten Erfolg bei dieser selbstgestellten Aufgabe zu verbuchen konnte, als James Rumbaugh von General Electric zu Rational wechselte, um ihre beiden Methoden zu vereinen. Zunächst ent-stand 1995 die Unified Method 0.8, der Vorläufer der UML, welche erst 1996 unter der Mitwirkung von Ivar Jacobson als UML 0.9 veröffentlich wurde.3 In den folgenden Jahren wurde die UML ständig weiterentwickelt: 1997 erschienen sogar zwei Versionen – die UML 1.0 und im Herbst die UML 1.1. Beide wurden der OMG (Object Management Group) zur Standardisierung vorgelegt, wobei die UML 1.1 als Standard akzeptiert wurde. „Seitdem gab es einige inkrementelle Änderungen durch die von Cris Kobryn (...) [geleitete] Revision Task Force (RTF). Die Version 1.2 war kosmetischer Natur; die Anfang 1999 veröffentlichte Version 1.3 hatte dagegen größere Bedeutung.“4 Denn es wurden einige Korrekturen am In-halt und an der Genauigkeit der Definitionen vorgenommen. „Im November 2000 wurde von der OMG RTF die UML 1.4 als Betaversion auf der OMG-Website publiziert (...) [und] enthält kleinere Überarbeitungen gegenüber der UML 1.3 ...“5 Momentan arbeitet die RTF an der Weiterentwicklung zur UML 2.0.

3 vgl. [Balzert 2001: 1] 4 [Fowler/Scott 2000: 4] 5 [Balzert 2001: 2]

2.1 OBJEKT 3 2. Ein Auszug aus der UML-Terminologie

2.1 Objekt (engl. object, instance)

Definition

Unter einem Objekt versteht man einen abstrakten Begriff aus der Vor-stellung oder einen gut abzugrenzenden Gegenstand aus der realen Welt (eine Entität).6 Jedes Objekt wird durch datenspezifische Eigenschaften (Attribute) und durch sein funktionsspezifisches Verhalten (Operation) charakterisiert. Ebenfalls ist ein Objekt „... ein Exemplar einer Klasse. Ein Objekt enthält durch Attribute repräsentierte Information, deren Struktur in der Klasse definiert ist.“7

Notation

In der UML wird das Objekt als Rechteck graphisch dargestellt, welches horizontal in zwei Felder geteilt werden kann. Heide Balzert beschreibt die Objektnotation wie folgt (nach [Balzert 2001: 3f]):

6 vgl. [Booch/Rumbaugh/Jacobson 2001: 464] 7 [Oestereich 2002: 22]

Objekt: Klasse

Attribut1 = Wert 1Attribut2 = Wert 2

Objekt :Klasse

2.1 OBJEKT 4

Im oberen Feld wir das Objekt wie folgt bezeichnet:

:Klasse

bei einem anonymen Objekt wird nur der Klassenname angegeben.

Objekt: Klasse

wenn das Objekt über einen Namen ange-sprochen werden soll.

Objekt

wenn der Objektname ausreicht, um das Ob-jekt zu identifizieren und der Name der Klas-se aus dem Kontext ersichtlich ist.

Im unteren Feld werden – optional – die im jeweiligen Kontext rele-vanten Attribute des Objekts eingetragen: Attribut : Typ = Wert Attribut = Wert Attribut

Die Operationen, die ein Objekt ausführen kann, werden in der UML nicht angegeben.

Beispiel

Klassenname Objektname

Attributnamen Attributwerte

Violine: Musikinstrument

artikelnummer = 587-392

preis_in_€ = 2580

2.2 KLASSE 5

2.2 Klasse (engl. class)

Definition

Eine Klasse beschreibt eine Menge von Objekten mit den gleichen Attributen, Operationen, Beziehungen und Bedeutungen (Assozia-tionen und Vererbungsstrukturen).8

Notation9

Namensfeld Attributsliste

Operationsliste

Klassen werden wie Objekte durch Rechtecke dargestellt. Diese be-stehen entweder nur aus dem Klassennamen, der dann fettgedruckt wird oder sie enthalten zusätzlich noch Attribute und Operationen. Der Klassenname wird von der Attributsliste, sowie von der Operati-onsliste durch eine horizontale Linie abgetrennt.10 „Der Klassenname ist stets ein Substantiv im Singular, das durch ein Adjektiv ergänzt werden kann. Er beschreibt also ein einzelnes Objekt der Klasse.“11 Der Klassenname kann auch einem Paket zugeordnet werden, was dann, wie folgt, notiert wird: Paket :: Klasse.

8 vgl. [Booch/Rumbaugh/Jacobson 2001: 459] 9 nach [Balzert 2001: 5] 10 vgl. [Oestereich 2002: 16] 11 [Balzert 2001: 5]

Klasse

Attribut1 Attribut2 ... Operation1() Operation2() ...

Klasse

Attribut1 Attribut2 ...

Klasse

Operation1() Operation2() ...

Klasse

2.2 KLASSE 6 Attribute müssen auf jeden Fall mit ihrem jeweiligen Namen ange-führt werden. Ansonsten bestehen die gleichen Notationsmöglichkei-ten wie bei den Objekten für die Attribute. Für Operationen gelten analog die gleichen Regeln wie für die Attri-bute.

Das Namensfeld einer Klasse kann in der UML um einen Ste-reotypen und eine Liste von Merkmalen erweitert werden. Ein Stereotyp (stereotype) klassifiziert Element (z. B. Klassen, Ope-rationen) des Modells. (...) Stereotypen werden in französischen Anführungszeichen (...) angegeben, z. B. ‹‹Stammdaten››. Ein Merkmal (property) beschreibt Eigenschaften eines be-stimmten Elements des Modells. Merkmale können in einer Liste zusammengefasst werden. Sie werden in folgender Form be-schrieben: {Schlüsselwort = Wert, ...} oder nur {Schlüs-selwort}. 12

‹‹Stammdaten›› Mitarbeiter

{Autor = Balzert, Version = 1.0}

Beispiel

Klassenname

Attributnamen und Attributwerte

Operationen Attributtyp

12 [Balzert 2001: 5f]

Musikinstrument

artikelnummer = 587-392

preis_in_€: Integer = 2580

preis_lesen() preis_aendern() liste_erstellen()

2.3 ATTRIBUT 7

2.3 Attribut (engl. attribute, member)

Definition

Attribute beschreiben eine Reihe von Werten, die die Objekte einer Klasse annehmen können.13 Attribute müssen mindestens mit ihrem Namen dargestellt werden, können aber auch noch durch die Angabe ihres Typs, des Anfangswertes oder von Merkmalen spezifiziert werden.14

Notation15

Attribute müssen auf jeden Fall mit ihrem jeweiligen Namen ange-führt werden. Dieser muss eindeutig gewählt werden, so dass keine Missverständnisse mit anderen Attributen in einer Klasse auftreten. Dabei gilt, dass der Name in der Regel in Anlehnung an die ursprüng-liche englische Notation klein geschrieben wird. Inzwischen hat es sich bei den deutschen Entwicklern zwar auch durchgesetzt, die deut-sche Rechtsschreibung zu wahren – doch habe ich mich für die Klein-schreibung in meinen Beispielen entschieden, da sie häufiger zu fin-den ist.

13 vgl. [Booch/Rumbaugh/Jacobson 2001: 458] 14 vgl. [Balzert: 2001: 7] 15 nach [Balzert 2001: 7f]

Klasse

Attribut: Typ = Anfangswert {Merkmal1, Merkmal2, ...} Klassenattribut /abgeleitetes Attribut

Klasse

Attribut Klassenattribut /abgeleitetes Attribut

2.3 ATTRIBUT 8 Man spricht von einem Klassenattribut (class scope attribute), wenn nur ein einziger Attributwert für alle Objekte einer Klasse vor-liegt. Dieses muss in der UML stets unterstrichen werden. Ein abgeleitetes Attribut (derived attribute) kann, wie sein Name schon verrät, aus den bereits vorhandenen Attributen erschlossen wer-den. Somit kann sein Wert aus den anderen Attributwerten berechnet bzw. ersehen werden. Um es von den anderen Attributen zu unter-scheiden, wird es durch den Slash „/“ vor dem Namen kenntlich ge-macht.

Für jedes Attribut wird im Entwurf die Sichtbarkeit (visibility) angegeben. Die UML unterscheidet folgende Arten:16 - public: sichtbar für alle Klassen, - protected: sichtbar für alle Unterklassen und innerhalb der

Klasse, - private: sichtbar nur innerhalb der Klasse, - package: sichtbar innerhalb der Pakets.

Beispiel

Klassenname

Attributnamen und Attributwerte

Attributtyp

16 [Balzert 2001: 8]

Class

+ publicAttribute # protectedAttribute - privateAttribute ~ packageAttribute

Musikinstrument

artikelnummer = 587-392

preis_in_€: Integer = 2580

2.4 OPERATION 9

2.4 Operation (engl. operation)

Definition

Operationen sind Dienstleistungen, die von allen Objekten einer Klasse angefordert werden können, um ihr momentanes Verhalten zu beeinflussen.17 „Jede Operation kann auf alle Attribute eines Objekts dieser Klasse direkt zugreifen. Die Menge aller Operationen wird als das Verhalten der Klasse oder als die Schnittstelle der Klasse be-zeichnet.“18

Notation19

Operationen müssen einen Namen bekommen, der Aufschluss dar-über gibt, welchen Prozess die jeweilige Operation ausführt. Da es sich bei Operationen um Tätigkeiten handelt, besteht der Name nicht aus einem Substantiv, wie bei einem Klassennamen, sondern aus ei-nem Verb. Auch hier muss auf jeden Fall eine eindeutige Bezeichnung gewählt werden. Eine Klassenoperation (class scope operation) bezieht sich auf die gesamte Klasse und kann nicht auf ein einzelnes Objekt der Klasse angewandt werden. Sie muss stets durch Unterstreichen kenntlich ge-macht werden.

17 vgl. [Booch/Rumbaugh/Jacobson 2001: 464] 18 [Balzert: 2001: 9] 19 nach [Balzert 2001: 9]

Klasse

Operation(){Merkmal1, Merkmal2, ...} Klassenoperation() abstrakte Operation()

Klasse

Operation() Klassenoperation() abstrakte Operation()

2.4 OPERATION 10

Unter einer abstrakten Operation versteht man eine Operation, die nur durch ihre Signatur dargestellt wird. Die Signatur besteht wieder-um aus dem Operationsnamen, einem Parameter und dem Rückgabe-typ (bzw. Ergebnistyp), der jedoch optional ist.20

Operation (Parameterliste) : Ergebnistyp21

Für jeden Parameter der Parameterliste gilt: [in | out | inout] Name: Typ = Anfangswert Analog zu den Attributen wird auch für Operationen im Entwurf die Sichtbarkeit angegeben.

Beispiel

Klassenname

Operationen

Operationsname

Klassenoperation

20 vgl. [Oestereich 2002: 27] 21 [Balzert 2001: 9]

Musikinstrument

preis_lesen() preis_aendern() liste_erstellen()

2.5 ASSOZIATION 11

2.5 Assoziation (engl. association)

Definition

Assoziationen repräsentieren Beziehungen (relationships).22 Hierbei werden Verbindungen zwischen den Objekten einer Klasse oder meh-rerer Klassen beschrieben. Bei binären Assoziationen handelt es sich um eine Beziehung zwischen genau zwei Objekten. Als reflexiv be-zeichnet man eine Assoziation, wenn eine Verbindung zwischen den Objekten einer Klasse besteht.23 In der UML gibt es im Grund drei Typen von Assoziationen – die Assoziation selbst, die Aggregation und die Komposition.

Notation24

Hier steht es dem Entwickler selbst frei, beim Entwurf einen Assozia-tionsnamen, einen Rollennamen, oder Kardinalitäts-restriktionen (multiplicity) festzulegen.25

Assoziationsname

Klasse 1

Rolle 1 Rolle 2

Klasse 2

22 vgl. [Rahm 1999: 3/7] 23 vgl. [Balzert: 2001: 9] 24 [Oestereich 2002: 61] 25 vgl. [Rahm 1999: 3/7]

2.5 ASSOZIATION 12 Während die Assoziationslinie zunächst nur aussagt, dass sich Objek-te der beteiligten Klassen kennen, spezifiziert die Kardinalität wie vie-le Objekte ein bestimmtes Objekt kennen kann.26

„genau 1“

„0 bis 1“

„0 bis viele“

„1 bis viele“

Bei der gerichteten Assoziation (uni-directional association) wird die Navigierbarkeit der „einfachen“ Assoziation eingeschränkt, d.h. sie gibt an, in welcher Richtung die Beziehung zwischen den Objekten zu lesen ist.27 Überdies gilt für gerichtete Assoziationen speziell, dass auch hier die Sichtbarkeit der Rolle festgelegt werden kann. Und der Name der Rolle sollte Informationen über die Bedeutung einer Klasse und ihrer Objekte in der Assoziation erteilen.28 Unter einer Aggregation versteht man eine besondere Assoziation zwischen zwei „...Klassen, in der eine Klasse eine andere enthält.“29 Hingegen ist eine Komposition eine „Aggregation, bei der eine Klas-se ein Attribut einer anderen ist“.30

26 [Balzert: 2001: 10] 27 vgl. [Rahm 1999: 3/8] 28 vgl. [Balzert 2001: 11] 29 [Rahm 1999: 3/11] 30 [Rahm 1999: 3/11]

1

0...1

*

1...*

2.5 ASSOZIATION 13

Beispiel für eine gerichtete Assoziation

Spielt ►

1 1...* Solist

Musiker

Musikinstrument

Beispiel für eine Aggregation

1 1

Klangkörper

◄ Besteht aus

Saiten-

instrument

1

Saite ◄ Besteht aus

3...*

etc.

Beispiel für eine Komposition

1 1

Bauliche_Beschaffenheit

Saiten-instrument

Hat ► Material_des_Klangkörpers Maße_des_Klangkörpers Material_der_Saiten Anzahl_der_Saiten Länge_der_Saiten

3. DARSTELLUNG AM BEISPIEL DES KLASSENDIAGRAMMS 14 3. Darstellung am Beispiel des Klassendiagramms Mit der uns nun bekannten UML-Terminologie ist uns möglich ein nicht all zu komplexes Klassendiagramm zu erstellen. Dieses „beschreibt die Typen von Ob-jekten im System und die verschiedenen Arten von statischen Beziehungen [As-soziationen] zwischen ... [ihnen]. (...) Klassendiagramme zeigen auch die Attribu-te und Operationen einer Klasse sowie die Einschränkungen bei der Verbindung ihrer Objekte.“31 Ein sehr übersichtliches Beispiel für ein Klassendiagramm gibt Grady Booch in seinem User Guide [Booch/Rumbaugh/Jacobson 2001: 112] an, welches die Be-ziehungen zwischen Schülern, den Kursen, den Lehrenden, sowie den Depart-ments und der Schule selbst wiedergibt.

31 [Fowler/Scott 2000: 44]

4. UML 1.4 – NOTATIONSTECHNIKEN IM ÜBERBLICK 15 4. UML 1.4 – Notationstechniken im Überblick Da ich mich bei meinen Ausführungen auf wenige ausgewählte graphische Dar-stellungsmöglichkeiten der UML beschränken musste, um den Rahmen dieser Hausarbeit nicht zu sprengen, möchte ich nun noch kurz auf die vollständige No-tationsübersicht hinweisen, wie sie von der oose.de GmbH herausgegeben wur-de. Diese bezieht sich auf die aktuelle Fassung – auf die Notation der UML 1.4, wie sie von Rational veröffentlicht wurde, allerdings handelt es sich hierbei um die deutsche Übersetzung. Bernd Oestereich, Mitarbeiter von oose.de, macht in seiner UML-Kurzreferenz [Oestereich 2002: x] eine Auflistung aller möglichen Diagrammtypen der UML 1.4 und erläutert diese folgendermaßen:

- [Das] Anwendungsfalldiagramm zeigt Akteure, Anwendungsfälle und ihre Beziehungen.

- [Das] Klassendiagramm zeigt Klassen und ihre Beziehungen unterein-ander.

- Verhaltensdiagramme o [Das] Aktivitätsdiagramm zeigt Aktivitäten, Objektzustände, Zu-

stände, Zustandsübergänge und Ergebnisse. o [Das] Kollaborationsdiagramm zeigt Objekte und ihre Bezie-

hungen inklusive ihres räumlich geordneten Nachrichtenaustau-sches.

o [Das] Sequenzdiagramm zeigt Objekte und ihre Beziehungen inklusive ihres zeitlich geordneten Nachrichtenaustausches.

o [Das] Zustandsdiagramm zeigt Zustände, Zustandsübergänge und Ereignisse.

- Implementierungsdiagramme o [Das] Komponentendiagramm zeigt Komponenten und ihre Be-

ziehungen. o [Das] Verteilungsdiagramm zeigt Komponenten, Knoten und ihre

Beziehungen.

Darüber hinaus gibt es noch die Objektdiagramme und Paketdiagramme, auf die Martin Fowler [Fowler/Scott 2000], Prof. Dr. Heide Balzert [Balzert 2001], Prof. Dr. E. Rahm [Rahm 1999] und Grady Booch [Booch/Rumbaugh/Jacobson 2001] hinweisen.

Die Notationsübersicht ist aus den Umschlagsseiten der UML-Kurzreferenz von Bernd Oestereich [Oestereich 2002] entnommen und im Anhang abgebildet.

ANHANG – NOTATIONSÜBERSICHT DER UML 1.4 16 Anhang – Notationsübersicht der UML 1.4

ANHANG – NOTATIONSÜBERSICHT DER UML 1.4 17

ANHANG – NOTATIONSÜBERSICHT DER UML 1.4 18

ANHANG – NOTATIONSÜBERSICHT DER UML 1.4 19

ANHANG – GLOSSAR 20 Glossar32

32 Auszug aus dem Glossar von [Oestereich 2002: 123ff]

ANHANG – GLOSSAR 21

LITERATURVERZEICHNIS 22 Literaturverzeichnis [Balzert 2001]

Heide Balzert: UML kompakt: mit Checklisten, Spektrum Akademischer Verlag, Heidelberg, 2001.

[Booch/Rumbaugh/Jacobson 2001] Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Lan-guage User Guide, acm press & Addison Wesley, 2001.

[Fowler/Scott 2000] Martin Fowler, Kendall Scott: UML konzentriert: Eine strukturierte Ein-führung in die Standard-Objektmodellierungssprache; 2. Auflage, Addi-son Wesley, München, 2000.

[Oestereich 2002] Bernd Oestereich: Die UML-Kurzreferenz für die Praxis: kurz, bündig, bal-lastfrei; Oldenbourg, München, 2002.

[Rahm 1999] Prof. Dr. E. Rahm: Datenbanksysteme II, Institut für Informatik, Universität Leipzig, pp. 3/3 – 3/16. http://dol.uni-leipzig.de/pub/showDoc.Fulltext?lang=de&doc=1999-29&format=pdf&compression=