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 verlieren. 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 korrigieren, 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 Erscheinung 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 grafisch darzustellen, ohne diese gleich in einer Programmiersprache zu kodieren. 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 Methode gehören immer die Modellierungssprache selbst und ein Prozess. Dieser umfasst nur die Anleitung für einen Programm- bzw. Datenbankentwurf, 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 Corporation, 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 entstand 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 Inhalt 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 Vorstellung 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 Objekt: Klasse Attribut1 = Wert 1 Attribut2 = Wert 2 Objekt :Klasse 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]
2.1 OBJEKT 4 Im oberen Feld wir das Objekt wie folgt bezeichnet: :Klasse Objekt: Klasse Objekt bei einem anonymen Objekt wird nur der Klassenname angegeben. wenn das Objekt über einen Namen angesprochen werden soll. wenn der Objektname ausreicht, um das Objekt zu identifizieren und der Name der Klasse aus dem Kontext ersichtlich ist. Im unteren Feld werden optional die im jeweiligen Kontext relevanten 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 Objektname Klassenname Attributnamen Violine: Musikinstrument artikelnummer = 587-392 preis_in_ = 2580 Attributwerte
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 (Assoziationen und Vererbungsstrukturen). 8 Notation 9 Klasse Attribut1 Attribut2... Operation1() Operation2()... Namensfeld Klasse Attribut1 Attribut2... Klasse Attributsliste Klasse Operationsliste Operation1() Operation2()... Klassen werden wie Objekte durch Rechtecke dargestellt. Diese bestehen 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 Operationsliste 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]
2.2 KLASSE 6 Attribute müssen auf jeden Fall mit ihrem jeweiligen Namen angeführt werden. Ansonsten bestehen die gleichen Notationsmöglichkeiten wie bei den Objekten für die Attribute. Für Operationen gelten analog die gleichen Regeln wie für die Attribute. Das Namensfeld einer Klasse kann in der UML um einen Stereotypen und eine Liste von Merkmalen erweitert werden. Ein Stereotyp (stereotype) klassifiziert Element (z. B. Klassen, Operationen) des Modells. (...) Stereotypen werden in französischen Anführungszeichen (...) angegeben, z. B. Stammdaten. Ein Merkmal (property) beschreibt Eigenschaften eines bestimmten Elements des Modells. Merkmale können in einer Liste zusammengefasst werden. Sie werden in folgender Form beschrieben: {Schlüsselwort = Wert,...} oder nur {Schlüsselwort}. 12 Stammdaten Mitarbeiter {Autor = Balzert, Version = 1.0} Beispiel Attributnamen und Attributwerte Klassenname Musikinstrument artikelnummer = 587-392 preis_in_ : Integer = 2580 preis_lesen() preis_aendern() liste_erstellen() Operationen Attributtyp 12 [Balzert 2001: 5f]
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 Notation 15 Klasse Attribut: Typ = Anfangswert {Merkmal1, Merkmal2,...} Klassenattribut /abgeleitetes Attribut Klasse Attribut Klassenattribut /abgeleitetes Attribut Attribute müssen auf jeden Fall mit ihrem jeweiligen Namen angefü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üngliche englische Notation klein geschrieben wird. Inzwischen hat es sich bei den deutschen Entwicklern zwar auch durchgesetzt, die deutsche Rechtsschreibung zu wahren doch habe ich mich für die Kleinschreibung in meinen Beispielen entschieden, da sie häufiger zu finden ist. 13 vgl. [Booch/Rumbaugh/Jacobson 2001: 458] 14 vgl. [Balzert: 2001: 7] 15 nach [Balzert 2001: 7f]
2.3 ATTRIBUT 8 Man spricht von einem Klassenattribut (class scope attribute), wenn nur ein einziger Attributwert für alle Objekte einer Klasse vorliegt. 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 werden. Somit kann sein Wert aus den anderen Attributwerten berechnet bzw. ersehen werden. Um es von den anderen Attributen zu unterscheiden, wird es durch den Slash / vor dem Namen kenntlich gemacht. 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. Class + publicattribute # protectedattribute - privateattribute ~ packageattribute Beispiel Attributnamen und Attributwerte Klassenname Musikinstrument artikelnummer = 587-392 preis_in_ : Integer = 2580 Attributtyp 16 [Balzert 2001: 8]
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 bezeichnet. 18 Notation 19 Klasse Operation(){Merkmal1, Merkmal2,...} Klassenoperation() abstrakte Operation() Klasse Operation() Klassenoperation() abstrakte Operation() 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 einem 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 gemacht werden. 17 vgl. [Booch/Rumbaugh/Jacobson 2001: 464] 18 [Balzert: 2001: 9] 19 nach [Balzert 2001: 9]
2.4 OPERATION 10 Unter einer abstrakten Operation versteht man eine Operation, die nur durch ihre Signatur dargestellt wird. Die Signatur besteht wiederum aus dem Operationsnamen, einem Parameter und dem Rückgabetyp (bzw. Ergebnistyp), der jedoch optional ist. 20 Operation (Parameterliste) : Ergebnistyp 21 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 Operationen Klassenname Musikinstrument preis_lesen() preis_aendern() liste_erstellen() Klassenoperation Operationsname 20 vgl. [Oestereich 2002: 27] 21 [Balzert 2001: 9]
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 mehrerer Klassen beschrieben. Bei binären Assoziationen handelt es sich um eine Beziehung zwischen genau zwei Objekten. Als reflexiv bezeichnet 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. Notation 24 Hier steht es dem Entwickler selbst frei, beim Entwurf einen Assoziationsnamen, 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 Objekte der beteiligten Klassen kennen, spezifiziert die Kardinalität wie viele Objekte ein bestimmtes Objekt kennen kann. 26 1 genau 1 0...1 0 bis 1 * 0 bis viele 1...* 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 Klasse 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]
2.5 ASSOZIATION 13 Beispiel für eine gerichtete Assoziation Solist Spielt 1 1...* Musiker Musikinstrument Beispiel für eine Aggregation Klangkörper 1 1 Besteht aus 1 Saite Besteht aus etc. 3...* Beispiel für eine Komposition Saiteninstrument Saiteninstrument 1 1 Bauliche_Beschaffenheit 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 Objekten im System und die verschiedenen Arten von statischen Beziehungen [Assoziationen] zwischen... [ihnen]. (...) Klassendiagramme zeigen auch die Attribute 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 Beziehungen zwischen Schülern, den Kursen, den Lehrenden, sowie den Departments 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 Darstellungsmöglichkeiten der UML beschränken musste, um den Rahmen dieser Hausarbeit nicht zu sprengen, möchte ich nun noch kurz auf die vollständige Notationsübersicht hinweisen, wie sie von der oose.de GmbH herausgegeben wurde. 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 untereinander. - Verhaltensdiagramme o [Das] Aktivitätsdiagramm zeigt Aktivitäten, Objektzustände, Zustände, Zustandsübergänge und Ergebnisse. o [Das] Kollaborationsdiagramm zeigt Objekte und ihre Beziehungen inklusive ihres räumlich geordneten Nachrichtenaustausches. o [Das] Sequenzdiagramm zeigt Objekte und ihre Beziehungen o inklusive ihres zeitlich geordneten Nachrichtenaustausches. [Das] Zustandsdiagramm zeigt Zustände, Zustandsübergänge und Ereignisse. - Implementierungsdiagramme o [Das] Komponentendiagramm zeigt Komponenten und ihre Beziehungen. 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 Glossar 32 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 Language User Guide, acm press & Addison Wesley, 2001. [Fowler/Scott 2000] Martin Fowler, Kendall Scott: UML konzentriert: Eine strukturierte Einführung in die Standard-Objektmodellierungssprache; 2. Auflage, Addison Wesley, München, 2000. [Oestereich 2002] Bernd Oestereich: Die UML-Kurzreferenz für die Praxis: kurz, bündig, ballastfrei; 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=