Teil I Erste Schritte Stunde 1: Einführung in die UML

25

Stunde 2: Objektorientierung verstehen

41

Stunde 3: Objektorientiert arbeiten

57

Stunde 4: Beziehungen spielen lassen

71

Stunde 5: Aggregationen, Komposita, Schnittstellen und Realisierungen verstehen

85

Stunde 6: Einführung in Anwendungsfälle

95

Stunde 7: Mit Anwendungsfalldiagrammen arbeiten

105

Stunde 8: Mit Zustandsdiagrammen arbeiten

123

Stunde 9: Mit Sequenzdiagrammen arbeiten

137

Stunde 10: Mit Kollaborationsdiagrammen arbeiten

153

Stunde 11: Mit Aktivitätsdiagrammen arbeiten

167

Stunde 12: Mit Komponentendiagrammen arbeiten

183

Stunde 13: Mit Einsatzdiagrammen arbeiten

199

Stunde 14: Die UML-Grundlagen besser verstehen

211

Stunde 15: Die UML im Entwicklungsprozess

227

Stunde 1 1

Einführung in die UML

Die Unified Modeling Language (UML) gehört zu den faszinierendsten Tools, die die moderne Welt der Systementwicklung zu bieten hat. Warum? Mit der UML können Systementwickler Pläne erstellen, die ihre Visionen in einer standardisierten, leicht verständlichen Form aufnehmen und anderen vermitteln. In dieser Stunde lernen Sie Folgendes:

✘ Warum die UML notwendig ist ✘ Wie die UML entstand ✘ Diagramme der UML ✘ Wichtigkeit der Verwendung unterschiedlicher Diagrammtypen Einige Begriffe In dem gesamten Buch ist mit System eine Kombination aus Hard- und Software gemeint, die ein Problem im Geschäftsleben löst. Systementwicklung meint die Erstellung eines Systems für einen Kunden, also die Person, die das Problem gelöst haben möchte. Ein Analytiker dokumentiert das Problem des Kunden und übergibt es an die Entwickler, d.h. die Programmierer, die die Software zum Lösen des Problems erstellen und diese Software auf der Computer-Hardware installieren und einsetzen. Das Kommunizieren der Vision ist von allerhöchster Wichtigkeit. Bevor die UML aufkam, gipfelte Systementwicklung oft in einem Vorschlag, der das Ziel entweder erreichte oder verfehlte. Systemanalytiker versuchten, die Bedürfnisse ihrer Kunden abzuwägen, eine Bedarfsanalyse in einer ihnen

TIPP

NEUERF BEGRIF

25

Stunde

1

Einführung in die UML

(aber nicht unbedingt dem Kunden) geläufigen Notation zu erstellen, diese dem Programmierer oder dem Programmierteam zu übergeben und zu hoffen, dass das Endprodukt auch wirklich das System war, das der Kunde gewollt hatte. Da das Entwickeln von Systemen eine menschliche Aktivität ist, konnten in jedem Stadium des Prozesses Fehler unterlaufen. Der Analytiker konnte den Kunden missverstehen. Er konnte ein Dokument produzieren, das der Kunde nicht verstand. Die Ergebnisse der Analyse waren möglicherweise den Programmierern nicht klar, woraufhin diese eventuell ein benutzerunfreundliches Programm schrieben, welches das ursprüngliche Problem des Kunden überhaupt nicht löste. Wen wundert es da noch, dass heute viele Systeme, die schon lange in Gebrauch sind, schwerfällig, sperrig und benutzerunfreundlich sind?

1.1

Wahnsinn mit Methode

In der Frühzeit der Computer stützten sich Programmierer normalerweise nicht auf tiefschürfende Analysen ihres Problems. Falls sie überhaupt irgendetwas analysierten, dann taten sie dies in der Regel auf der Rückseite einer Papierserviette. Oft schrieben sie Programme von Grund auf und entwickelten währenddessen ihren Code. Dies umgab zwar den ganzen Prozess mit einer Aura von Romantik und Wagemut, wäre aber der heutigen hoch entwickelten Geschäftswelt nicht mehr angemessen. Heute ist ein wohl durchdachter Plan von größter Bedeutung. Der Kunde muss verstehen, was ein Entwicklungsteam zu tun gedenkt und er muss Änderungen anzeigen können, wenn das Team die Kundenwünsche nicht vollständig verstanden hat (oder der Kunde zwischendurch seine Meinung geändert hat). Zudem wird die Entwicklung fast immer in Teamarbeit geleistet, so dass jedes Teammitglied wissen muss, welchen Anteil seine Arbeit am Gesamtbild hat (und was dieses Gesamtbild eigentlich ist). In dem Maße, wie unsere Welt immer komplizierter wird, müssen auch die Computersysteme dieser Welt komplizierter werden. Oft umfassen sie mehrere Hardware- und Softwarekomponenten, die über weite Entfernungen vernetzt und mit Datenbanken verbunden sind, welche Berge von Informationen enthalten. Wie erfassen Sie diese Komplexität, wenn Sie die Systeme des neuen Jahrtausends erstellen möchten?

26

Entstehung der UML

Die Lösung ist, den Entwurfsprozess in einer Weise zu organisieren, die Analytiker, Kunden, Programmierer und andere an der Systementwicklung Beteiligte verstehen und auf die sie sich einigen können. Die UML liefert diese Organisation. Ebenso wie Sie auch keine komplexe Struktur wie ein Bürogebäude bauen würden, ohne zuvor einen detaillierten Plan zu machen, würden Sie auch kein komplexes System bauen, das in diesem Bürogebäude wirkt, ohne vorher einen detaillierten Entwurfsplan zu erstellen. Dieser Plan sollte so sein, dass man ihn dem Kunden ebenso vorlegen kann, wie der Architekt seinen Plan dem Bauherrn zeigt. Er sollte das Ergebnis einer sorgfältigen Analyse der Kundenbedürfnisse sein. Ein weiteres Merkmal der zeitgenössischen Systementwicklung ist der enge Zeitrahmen für die Entwicklung. Wenn die Termine Schlag auf Schlag kommen, wird ein solider Entwurf zur absoluten Notwendigkeit. Und es gibt noch einen weiteren Aspekt des modernen Lebens, für den ein solider Entwurf notwendig ist: Unternehmensübernahmen. Wenn ein Unternehmen ein anderes kauft, wird die neue Organisation möglicherweise wichtige Aspekte des laufenden Entwicklungsprojekts ändern wollen (das Implementierungstool, die Programmiersprache und noch mehr). Ein hiebund stichfester Projektplan erleichtert diese Änderungen. Ist der Entwurf tragfähig, lässt sich eine Änderung in der Implementierung reibungslos durchführen. Der Bedarf an tragfähigen Entwürfen bedingte auch einen Bedarf an einer Entwurfsnotation, die Analytiker, Entwickler und Kunden als Standard akzeptieren – ebenso wie die Notation in schematischen Stromkreis-Diagrammen der Standard für Elektrotechniker ist. Die UML ist diese Notation.

1.2

Entstehung der UML

Die UML ist das geistige Kind von Grady Booch, James Rumbaugh und Ivar Jacobson. Diese neuerdings als »die drei Amigos« bezeichneten Herren arbeiteten in den 1980er und 1990er Jahren für unterschiedliche Organisationen und entwickelten jeder seine eigene Methodik für objektorientierte Analyse und Design. Ihre Darstellungsmethoden setzten sich gegen die vieler Mitbewerber durch. Mitte der 1990er Jahre begannen sie, Ideen voneinander zu übernehmen und beschlossen daher, ihre Arbeit gemeinsam weiter zu führen.

27

Stunde

1

Einführung in die UML

Die Stunden 2 (Objektorientierung verstehen) und 4 (Beziehungen spielen lassen) behandeln die Objektorientierung, deren Konzepte im gesamten Buch eine wichtige Rolle spielen. Im Jahre 1994 kam Rumbaugh zur Firma Rational Software, in der Booch bereits arbeitete. Ein Jahr später trat auch Jacobson in diese Firma ein. Der Rest ist, wie man sagt, Geschichte. Vorab-Versionen der UML machten in der Softwareindustrie die Runde und riefen ein Echo hervor, das zu grundlegenden Änderungen führte. Da viele Unternehmen der Meinung waren, die UML würde ihren strategischen Zielen dienen, gründete sich ein UML-Konsortium. Mitglieder waren unter anderem DEC, Hewlett Packard, Intellicorp, Microsoft, Oracle, Texas Instruments und Rational. Im Jahre 1997 produzierte dieses Konsortium die Version 1.0 der UML und stellte es der Object Management Group (OMG) auf Grund deren Anfrage nach einem Vorschlag für eine Standardmodellierungssprache zur Verfügung. Das Konsortium expandierte, stellte die Version 1.1 her und übergab diese der OMG, die diese Version Ende 1997 übernahm. Sie übernahm auch die Pflege der UML und produzierte 1998 zwei weitere, verbesserte Versionen. So wurde die UML ein de-facto-Standard in der Softwareindustrie und entwickelt sich immer noch weiter.

1.3

Komponenten der UML

Die UML besteht aus einigen grafischen Elementen, die man so kombinieren kann, dass sie Diagramme bilden. Da sie eine Sprache ist, hat sie Regeln, nach denen diese Elemente zu kombinieren sind. Anstatt Ihnen jedoch diese Elemente und Regeln nun aufzuzählen, wollen wir gleich zu den Diagrammen kommen, denn diese sind es, die Sie zur Systemanalyse eigentlich benötigen werden. Dieser Ansatz ist analog zu jenem, bei dem man eine Fremdsprache lernt, indem man sie nutzt, anstatt ihre Grammatik und Verbkonjugationen zu pauken. Die Grammatikregeln und Konjugationen sind ohnehin leichter zu verstehen, wenn man die Sprache bereits einige Zeit angewendet hat.

28

Komponenten der UML

Die Diagramme haben den Zweck, mehrere Sichten eines Systems darzustellen. Diese Menge verschiedener Sichten bezeichnet man als Modell. Ein UML-Systemmodell ist so etwas wie ein Gebäudemodell zusammen mit einer von einem Künstler gefertigten Darstellung dieses Bauwerks. Wichtig ist festzuhalten, dass ein UML-Modell beschreibt, was ein System eigentlich tun soll. Es sagt jedoch nichts darüber aus, wie das System zu implementieren ist.

NEUERF BEGRIF

Die folgenden Abschnitte beschreiben kurz die gebräuchlichsten Diagramme der UML sowie die in ihnen dargestellten Konzepte. Später im Teil I werden Sie die einzelnen Diagramme genauer kennen lernen. Bitte denken Sie daran, dass auch Mischformen dieser Diagramme auftreten können und dass die UML Organisations- und Erweiterungsmöglichkeiten für ihre Diagramme bietet.

1.3.1

Klassendiagramm

Überlegen Sie einmal, von welchen Dingen Sie umgeben sind. (Zugegeben, das ist ein ziemlich umfangreicher Auftrag, aber versuchen Sie es trotzdem!) Vermutlich ist es so, dass die meisten dieser Dinge Attribute (Eigenschaften) besitzen und irgendeine Form von Verhalten an den Tag legen. Diese Verhaltensweisen können wir als eine Menge von Operationen betrachten. Sie werden außerdem feststellen, dass sich Gegenstände von Natur aus in Kategorien einteilen lassen (Autos, Möbel, Waschmaschinen...). Diese Kategorien nennen wir Klassen. Eine Klasse ist eine Kategorie oder eine Gruppe von Dingen mit ähnlichen Attributen und gemeinsamen Verhaltensweisen. Ein Beispiel: Jeder Gegenstand aus der WaschmaschinenKlasse hat Attribute wie Herstellernamen, Modellbezeichnung, Seriennummer und Kapazität. Verhaltensweisen von Gegenständen aus dieser Klasse sind unter anderem die Operationen: »Wäsche einladen«, »Waschmittel einfüllen«, »Maschine einschalten« und »Wäsche ausladen«.

NEUERF BEGRIF

Abbildung 1.1 zeigt ein Beispiel der UML-Notation, in dem diese Attribute und Verhaltensweisen einer Waschmaschine festgehalten sind. Ein Rechteck ist das Symbol, das die Klasse repräsentiert. Es teilt sich in drei Teile: Der obere Bereich enthält den Namen, der mittlere die Attribute und der untere die Operationen. Ein Klassendiagramm besteht aus einigen solchen Rechtecken, die durch Linien miteinander verbunden sind. Die Linien zeigen, wie die Klassen miteinander zusammenhängen.

29

Stunde

Abb. 1.1: Das UMLKlassensymbol

1

Einführung in die UML

Waschmaschine Herstellername Modellbezeichnung Seriennummer Kapazität Wäsche einfüllen() Waschmittel einfüllen() Wäsche ausladen()

Warum sollte man sich mit Klassen von Dingen und deren Attributen und Verhaltensweisen überhaupt abgeben? Um mit unserer komplizierten Welt zu interagieren, simuliert die meiste zeitgenössische Software einen bestimmten Aspekt dieser Welt. Jahrzehntelange Erfahrung hat zu der Erkenntnis geführt, dass es am einfachsten ist, Software, die dies tut, zu entwickeln, wenn diese Software Klassen real existierender Gegenstände darstellen soll. Klassendiagramme bieten die Darstellungsform, auf der Entwickler aufbauen. Auch auf der Analyseseite sind Klassendiagramme hilfreich. Sie ermöglichen Analytikern, mit den Kunden in deren Terminologie zu reden und regen die Kunden dadurch an, wichtige Einzelheiten über die Probleme, deren Lösung sie anstreben, zu erzählen.

1.3.2 NEUERF BEGRIF

Objektdiagramm

Ein Objekt ist die Instanz einer Klasse – ein spezifisches Ding, dessen Attribute und Verhaltensweisen spezifische Werte haben. So hat möglicherweise Ihre Waschmaschine z.B. den Hersteller Laundatorium, die Modellbezeichnung Washmeister, die Seriennummer GL57774 und eine Ladekapazität von acht Kilogramm. Abbildung 1.2 zeigt, wie die UML ein Objekt darstellt. Beachten Sie, dass das Symbol genau wie das Klassensymbol ein Rechteck ist, aber der Name unterstrichen wird. Der Name dieser speziellen Instanz der Klasse steht links vom Doppelpunkt, der Klassenname rechts davon.

Abb. 1.2: Das Objektsymbol der UML

30

Mein Wäscher : Waschmaschine

Komponenten der UML

1.3.3

Anwendungsfalldiagramm

Ein Anwendungsfall (use case) ist die Beschreibung des Verhaltens eines Systems vom Standpunkt des Anwenders aus. Für Systementwickler ist dies ein wertvolles Werkzeug: Es ist ein »ausprobiert und genehmigt«-Verfahren, mit dem man die Anforderungen an ein System aus der Sicht des Anwenders sammeln kann. Dies ist besonders wichtig, wenn man das Ziel hat, ein System zu erstellen, das normale Menschen (und nicht nur Computerfreaks) benutzen können.

NEUERF BEGRIF

Anwendungsfälle werden wir später noch eingehender behandeln. Fürs Erste ist hier ein kurzes Beispiel: Eine Waschmaschine benutzen Sie natürlich, um Ihre Wäsche zu waschen. Abbildung 1.3 zeigt, wie man dies in einem UML-Anwendungsfalldiagramm darstellen würde.

Wäsche waschen

Abb. 1.3: Das Anwendungsfalldiagramm der UML

Waschmaschinen-Benutzer

Das kleine Strichmännchen, das den Waschmaschinen-Benutzer darstellt, nennt man Akteur. Die Ellipse repräsentiert den Anwendungsfall. Beachten Sie, dass der Akteur – d. h. die Entität, die den Anwendungsfall anstößt – sowohl eine Person als auch ein anderes System sein kann.

1.3.4

NEUERF BEGRIF

Zustandsdiagramm

Zu jedem gegebenen Zeitpunkt befindet sich das Objekt in einem bestimmten Zustand. Ein Mensch kann ein Neugeborenes sein, ein Säugling, ein Kind, ein Heranwachsender, Teenager oder Erwachsener. Ein Aufzug fährt nach oben, hält an oder fährt nach unten. Eine Waschmaschine kann in einem Zustand sein, in dem sie einweicht, wäscht, spült, schleudert oder ausgeschaltet ist. Das UML-Zustandsdiagramm in Abbildung 1.4 hält diesen Ausschnitt der Realität fest. Die Abbildung zeigt, dass die Waschmaschine von einem Zustand zum nächsten übergeht. Das Symbol oben im Bild repräsentiert den Anfangszustand und das Symbol unten den Endzustand.

31

Stunde

Abb. 1.4: Das UMLZustandsdiagramm

1

Einführung in die UML

Einweichen

Waschen

Spülen

Schleudern

1.3.5

Sequenzdiagramm

Klassen- und Objektdiagramme zeigen statische Informationen. In einem funktionierenden System interagieren jedoch die Objekte miteinander und diese Interaktionen ziehen sich über einen Zeitraum hin. Das UML-Sequenzdiagramm zeigt die zeitliche Dynamik der Interaktion. Fahren wir fort mit dem Waschmaschinen-Beispiel: Zu der Maschine gehört unter anderem ein Wasserrohr (für die Frischwasserzufuhr), eine Trommel (der Teil, in den die Wäsche hineinkommt) und ein Abfluss. Dies sind natürlich auch Objekte. (Wie Sie sehen, kann ein Objekt aus anderen Objekten bestehen). Was passiert, wenn Sie den Anwendungsfall »Wäsche waschen« aufrufen? Wenn wir davon ausgehen, dass Sie die Operationen »Wäsche einfüllen«, »Waschmittel einfüllen« und »Einschalten« bereits ausgeführt haben, dürfte die Sequenz der weiteren Schritte etwa so aussehen: 1. Wasser fließt durch das Wasserrohr in die Trommel. 2. Die Trommel steht fünf Minuten lang still. 3. Die Wasserzufuhr stoppt. 4. Die Trommel dreht sich 15 Minuten lang hin und her. 5. Das Seifenwasser fließt durch den Abfluss ab. 6. Erneut wird Wasser zugeführt.

32

Komponenten der UML

7. Die Trommel dreht sich weiter hin und her. 8. Die Wasserzufuhr stoppt. 9. Das Wasser zum Ausspülen fließt durch den Abfluss. 10. Die Trommel dreht sich nur noch in eine Richtung und rotiert fünf Minuten lang mit erhöhter Geschwindigkeit. 11. Die Rotation der Trommel stoppt und der Waschgang ist erledigt. Das Sequenzdiagramm in Abbildung 1.5 zeigt, wie Wasserzufuhr, Trommel und Abfluss (dargestellt als Rechtecke oben in Diagramm) über einen Zeitraum interagieren. In diesem Diagramm verläuft die Zeitachse von oben nach unten. Wasserrohr

Trommel

Abfluss

Frisches Wasser schicken

Abb. 1.5: Das UMLSequenzdiagramm

Anhalten Stop Hin und her rotieren Seifenwasser schicken Frisches Wasser schicken Hin und her rotieren Spülwasser schicken Stop In eine Richtung rotieren

Stop

Im Hinblick auf die Überlegungen im Zusammenhang mit Zuständen können wir übrigens die Schritte 1 und 2 als Einweichzustand, die Schritte 3 und 4 als den Waschzustand, die Schritte 5 bis 7 als den Spülzustand und die Schritte 8 bis 10 als den Schleuderzustand charakterisieren.

33

Stunde

Einführung in die UML

1 1.3.6

Aktivitätsdiagramm

Die in einem Anwendungsfall oder im Verhalten eines Objekts ablaufenden Aktivitäten treten generell eine nach der anderen auf, wie es bei den elf Schritten im vorigen Abschnitt der Fall war. Abbildung 1.6 zeigt, wie das UML-Aktivitätsdiagramm die Schritte 4 bis 6 dieser Abfolge darstellt. Abb. 1.6: Das UMLAktivitätsdiagramm

Trommel 15 Min. hin und her rotieren lassen

Seifenwasser ablaufen lassen

Erneut Wasser zuführen

1.3.7

Kollaborationsdiagramm

Die Elemente eines Systems arbeiten zusammen, um die Ziele des Systems zu erreichen. Eine Modellierungssprache muss über eine Möglichkeit verfügen, dies darzustellen. Abbildung 1.7 zeigt das für diesen Zweck entwickelte UML-Kollaborationsdiagramm. Dieses Beispiel fügt der Klassenmenge, die für die Waschmaschine steht, einen internen Timer hinzu. Nach einer gewissen Zeit stoppt der Timer die Wasserzufuhr und beginnt, die Trommel hin und her rotieren zu lassen. Abb. 1.7: Das UMLKollaborationsdiagramm

Interner Timer

1: Stop

2: Hin und her rotieren

Wasserrohr

Trommel

1.3.8

Komponentendiagramm

Mit diesem und dem darauf folgenden Diagramm verlassen wir die Welt der Waschmaschinen, da das Komponenten- und das Einsatzdiagramm ausdrücklich auf Computersysteme ausgerichtet sind.

34

Weitere Features

Moderne Softwareentwicklung wird mit Komponenten vorangetrieben. Besonders wichtig ist dies bei Entwicklungsanstrengungen von Teams. Ohne dies hier zunächst weiter zu vertiefen, zeigen wir in Abbildung 1.8, wie die UML eine Softwarekomponente darstellt. Eine Komponente

1.3.9

Abb. 1.8: Das UMLKomponentendiagramm

Einsatzdiagramm

Das UML-Einsatzdiagramm (deployment diagram) zeigt die physische Architektur eines computergestützten Systems. Es kann die Computer und Geräte, deren Verbindungen untereinander sowie die Software auf den einzelnen Maschinen darstellen. Ein Computer wird durch einen Würfel repräsentiert und die Verbindungen zwischen den Computern durch Linien, die diese Würfel verbinden. Abbildung 1.9 gibt dafür ein Beispiel.

«Prozessor» Cobalt Networks Qube Microserver 2700WG

«Prozessor» Vectra VL Series 7

1.4

Abb. 1.9: Das UML-Einsatzdiagramm

«Prozessor» Dell Dimension XPS R450

Weitere Features

Wie bereits erwähnt bietet die UML auch Features zum Organisieren und Erweitern der Diagramme.

35

Stunde

1.4.1 NEUERF BEGRIF

Abb. 1.10: Das Paket in der UML ermöglicht, die Elemente eines Diagramms zu gruppieren.

Pakete

Manchmal werden Sie feststellen, dass es notwendig ist, die Elemente eines Diagramms in einer Gruppe zu organisieren. Vielleicht möchten Sie zeigen, dass einige Klassen oder Komponenten zu einem bestimmten Teilsystem gehören. Dazu fassen Sie sie in einem Paket zusammen, das wie in Abbildung 1.10 als Akte mit Reiter dargestellt wird.

Paket 1 Klasse 1

Klasse 2

1.4.2 NEUERF BEGRIF

Abb. 1.11: Jedem Diagramm können Sie mit einer Notiz erklärende Kommentare hinzufügen.

36

Klasse 3

Notizen

Es kommt oft vor, dass ein Teil eines Diagramms keine eindeutige Erklärung liefert, wozu er da ist und wie man mit ihm umgeht. In diesem Fall hilft die UML-Notiz. Eine Notiz können Sie sich wie die grafische Entsprechung einer gelben Haftnotiz vorstellen. Ihr Symbol ist ein Rechteck mit einem Eselsohr. In dem Rechteck steht ein erklärender Text. Abbildung 1.11 zeigt ein Beispiel dafür. Die Notiz verbinden Sie mit einem Diagrammelement, indem Sie beides mit einer gestrichelten Linie verbinden. Erklärender Text zu Klasse 1

Klasse 1

1.4.3 NEUERF BEGRIF

Einführung in die UML

1

Stereotypen

Zwar bietet die UML etliche nützliche Elemente, aber diese sind nicht allumfassend. Es kommt immer wieder vor, dass man ein System entwirft, für das maßgeschneiderte Elemente nötig sind. Mit Stereotypen können Sie aus bestehenden UML-Elementen neue machen. Es ist so ähnlich, als würde

Wozu die ganzen Diagramme?

man einen Anzug von der Stange kaufen und dann auf die eigenen Maße umarbeiten lassen (anstatt aus einer Rolle Tuch einen neuen zu schneidern). Ein Stereotyp können Sie sich als eine solche Änderung vergegenwärtigen. Sie stellen ihn als Namen in doppelten, spitzen Klammern (Guillemets genannt) dar und wenden diesen Namen dann entsprechend an. Das Konzept einer Schnittstelle ist ein gutes Beispiel. Eine Schnittstelle (Interface) ist eine Klasse, die nur Operationen und keine Attribute enthält. Sie stellt eine Menge von Verhaltensweisen dar, die Sie möglicherweise in Ihrem Modell immer wieder einsetzen möchten. Anstatt für die Darstellung der Schnittstelle ein neues Element zu erfinden, können Sie das Klassensymbol verwenden und direkt über den Klassennamen «Interface» schreiben. Wie das geht, zeigt Abbildung 1.12.

«Interface» Klasse 1

1.5

NEUERF BEGRIF

Abb. 1.12: Mit einem Stereotyp kann man aus bestehenden Elementen neue machen.

Wozu die ganzen Diagramme?

Wie Sie sehen, machen es die UML-Diagramme möglich, ein System aus mehreren Blickwinkeln zu untersuchen. Man muss sagen, dass nicht alle Diagramme in jedem UML-Modell auftauchen. Die meisten UML-Modelle enthalten eine Teilmenge der aufgeführten Diagramme. Wozu ist es nötig, viele Ansichten eines Systems zu haben? Normalerweise hat ein System mehrere unterschiedliche Beteiligte (stakeholders) – Personen, die an verschiedenen Aspekten des Systems interessiert sind. Wenden wir uns noch einmal dem Waschmaschinen-Beispiel zu. Wenn Sie einen Waschmaschinen-Motor entwerfen, betrachten Sie das System aus dem einen Blickwinkel, wenn Sie die Bedienungsanleitung schreiben aus einem anderen. Wenn Sie das Design der Maschine herstellen, betrachten Sie sie völlig anders, als wenn Sie bloß ihre Wäsche damit waschen möchten.

NEUERF BEGRIF

Eine gewissenhafte Systementwicklung bezieht alle möglichen Perspektiven mit ein und jedes UML-Diagramm gibt Ihnen die Möglichkeit, eine bestimmte Sichtweise zu verkörpern. Das Ziel dabei ist, alle Arten von Beteiligten zufrieden zu stellen.

37

Stunde

1 1.6

Einführung in die UML

Zusammenfassung

Systementwicklung ist eine menschliche Aktivität. Ohne eine leicht verständliche Notation ist der Entwicklungsprozess sehr fehleranfällig. Die UML ist ein Notationssystem, das in der Welt der Systementwicklung inzwischen zum Standard geworden ist. Sie ist das Ergebnis der Arbeit von Grady Booch, James Rumbaugh und Ivar Jacobson. Die UML, die in einer Menge von Diagrammen besteht, stellt einen Standard zur Verfügung, mit dem der Systemanalytiker einen facettenreichen Plan erarbeiten kann, der für Kunden, Programmierer und sonstige am Entwicklungsprozess Beteiligte verständlich ist. Alle diese Diagramme sind notwendig, da jedes einen anderen am System Beteiligten anspricht. Ein UML-Modell sagt aus, was ein System tun soll, aber nicht, wie.

1.7

Fragen und Antworten

F: Die Unified Modeling Language wird als »UML« und als »die UML« bezeichnet. Was ist richtig? A: Die Schöpfer der Sprache bevorzugen »die UML«. F: Sie haben behauptet, die UML sei ein fantastisches Tool für Analytiker. Das Einsatzdiagramm sieht aber nicht so aus, als ob es im Analysestadium der Systementwicklung in irgendeiner Weise hilfreich wäre. Eignet es sich nicht besser für ein späteres Stadium? A: Eigentlich ist es nie zu früh, sich über den Einsatz Gedanken zu machen (oder über andere Fragen, die man traditionell auf ein späteres Entwicklungsstadium verschiebt). Es ist zwar richtig, dass der Analytiker mit Kunden und Anwendern redet, aber er kann sich auch bereits frühzeitig im Prozess über die Computer und Komponenten Gedanken machen, die die Hardware des Systems bilden werden. Manchmal schreibt der Kunde dies vor und bisweilen möchte er vom Entwicklungsteam eine Empfehlung bekommen. Auch ein Systemarchitekt kann aus einem Einsatzdiagramm gewiss Nutzen ziehen.

38

Workshop F: Sie haben erwähnt, dass Mischdiagramme möglich sind. Gibt es in UML, Verzeihung, in der UML Einschränkungen, welche Elemente man in einem Diagramm mit welchen anderen Elementen kombinieren kann? A. Nein, die UML setzt da keine Grenzen. Normalerweise ist es allerdings so, dass ein Diagramm nur eine Art von Element enthält. Man kann zwar auch in ein Einsatzdiagramm Klassensymbole setzen, aber nützlich wäre das nicht.

1.8

Workshop

Sie haben sich auf die UML gestürzt. Jetzt ist es an der Zeit, Ihr Wissen über dieses schöne Tool zu festigen, indem Sie einige Fragen beantworten und Übungen machen. Die Antworten finden Sie im Anhang A unter »Antworten«.

1.8.1

Fragen

1. Warum ist es notwendig, in einem Modell eines Systems mehrere Diagramme zu haben? 2. Welche Diagramme geben eine statische Sicht auf das System? 3. Welche Diagramme bieten eine dynamische Sicht des Systems (d.h. zeigen Änderungen im Zeitverlauf)?

1.8.2

Übungen

1. Angenommen, Sie bauen ein computergestütztes System, das mit einem Anwender Schach spielt. Welche UML-Diagramme wären beim Entwurf dieses Systems von Nutzen? Warum? 2. Führen Sie für das in der vorigen Übung erstellte System auf, welche Fragen Sie einem potenziellen Anwender stellen würden und warum.

39

Stunde 2

Objektorientierung verstehen 2

Objektorientierung verstehen

In dieser Stunde lernen Sie etwas über Objektorientierung, die Grundlage eines Großteils Ihrer zukünftigen Modellierungsarbeit. Insbesondere lernen Sie die folgenden Konzepte der Objektorientierung kennen:

✘ Abstraktion ✘ Vererbung ✘ Polymorphismus ✘ Kapselung ✘ Versenden von Nachrichten ✘ Assoziationen ✘ Aggregation Objektorientierung hat die Softwareszene im Sturm erobert und dies zu Recht. Als Programmierverfahren bietet sie eine Reihe von Vorteilen. Sie fördert einen auf Komponenten ausgerichteten Ansatz der Softwareentwicklung, bei dem man ein System zuerst als Objektmenge erschafft. Danach kann man das System erweitern, indem man den bereits erstellten Elementen neue Fähigkeiten gibt oder weitere Elemente hinzufügt. Und schließlich kann man die für dieses System geschaffenen Objekte beim Bauen eines neuen Systems wiederverwenden und dadurch eine Menge Entwicklungszeit sparen. Die Objektorientierung hat für die Softwareentwicklung eine derartige Bedeutung erlangt, dass die Object Management Group (OMG), eine gemeinnützige Organisation, die Standards für objektorientierte Entwicklung fest-

TIPP

NEUERF BEGRIF

41

Stunde

2

Objektorientierung verstehen

legt, davon ausgeht, dass sich die Einkünfte aus dem Verkauf objektorientierter Software in den nächsten drei bis fünf Jahren auf drei Milliarden Dollar belaufen werden. Hier kommt die UML ins Spiel, die es ermöglicht, anwenderfreundliche und leicht verständliche Objektmodelle zu erstellen, sodass Programmierer Software daraus entwickeln können. Objektorientierung ist eine Idee – eine Idee, die von einigen wenigen Grundprinzipien abhängt. In dieser Kursstunde werden Sie diese Prinzipien kennen lernen. Sie werden feststellen, was die Objekte zum Laufen bringt und wie man sie in Analyse und Entwurf einsetzt. In der darauf folgenden Stunde werden Sie anfangen, die UML auf diese Prinzipien anzuwenden.

2.1

Objekte überall

Objekte, feste und andere, umgeben uns überall. Aus ihnen setzt sich unsere Welt zusammen. Wie bereits in der letzten Stunde gesagt, simuliert zeitgenössische Software die Welt – oder einen kleinen Ausschnitt daraus – in der Weise, dass Programme die Objekte dieser Welt nachahmen. Wenn Sie einige Wesenszüge von Objekten verstehen, werden Sie erfassen können, was dazu gehört, diese als Software darzustellen. NEUERF BEGRIF

Zuallererst ist ein Objekt eine Instanz einer Klasse (oder Kategorie). Sie und ich, wir sind z.B. Instanzen der Klasse Mensch. Ein Objekt hat eine Struktur. Das heißt, es hat Attribute (Eigenschaften) und ein Verhalten. Das Verhalten eines Objekts besteht aus den Operationen, die es ausführt. Attribute und Operationen zusammengenommen bezeichnet man als Merkmale (features). Als Objekte der Klasse Mensch haben Sie und ich folgende Attribute: Größe, Gewicht und Alter. (Man kann sich noch ein paar mehr ausdenken.) Außerdem führen wir folgende Operationen aus: Essen, Schlafen, Lesen, Schreiben, Sprechen, Arbeiten gehen und andere mehr. Wollten wir ein System kreieren, das mit Informationen über Menschen umgeht – etwa ein Gehaltsbuchhaltungssystem oder ein System für die Personalabteilung – so würden wir wahrscheinlich einige dieser Attribute und einige dieser Operationen in unsere Software mit einbeziehen. In der Welt der Objektorientierung dient eine Klasse noch einem anderen Zweck als bloß der Kategorisierung. Eine Klasse ist ein Muster, nach dem Objekte erstellt werden. Sie können sie sich als Plätzchenform vorstellen, mit der man neue Objekte ausstanzen kann. (Man könnte zwar entgegensetzen, dies sei dasselbe wie Kategorisieren, aber diese Debatte wollen wir hier nicht führen.)

42

Objekte überall

Kehren wir zu dem Waschmaschinen-Beispiel zurück. Wenn die Waschmaschinen-Klasse so spezifiziert wurde, dass sie die Attribute Herstellername, Modellbezeichnung, Seriennummer und Kapazität sowie die Operationen »Wäsche einfüllen«, »Waschmittel einfüllen« und »Wäsche herausnehmen« hat, dann verfügen Sie über einen Mechanismus, neue Instanzen der Waschmaschinen-Klasse herzustellen. Das heißt, Sie können neue Objekte erzeugen (siehe Abbildung 2.1). In der Stunde 3, »Objektorientiert arbeiten«, werden Sie sehen, dass Klassennamen wie Waschmaschine als WaschMaschine und Merkmalsnamen wie Seriennummer als serienNummer geschrieben werden. Doch in dieser Stunde behandeln wir die Objektorientierung auf Deutsch und nicht in der UML, also bleiben wir bei der Art, wie Namen normalerweise gedruckt werden. Dies ist in der Welt der objektorientierten Softwareentwicklung besonders wichtig. Zwar legt dieses Buch den Schwerpunkt nicht auf die Programmierung, aber für Ihr Verständnis der Objektorientierung ist es hilfreich zu wissen, dass Klassen in objektorientierten Programmen neue Instanzen erzeugen können. Abb. 2.1: Die WaschmaHerstellerName schinen-Klasse ModellBezeichnung – das OriginalSerienNummer modell einer Kapazität WaschmaschiwäscheEinfüllen( ) ne – ist ein waschMittelEinfüllen( ) Muster zur ErwäscheAusladen( ) stellung neuer WaschmaschiEs gibt noch etwas Anderes, worauf man achten muss. Denken Sie daran, nen-Instanzen. WaschMaschine

dass der Zweck der Objektorientierung darin besteht, Software zu entwickeln, die einen bestimmten Ausschnitt aus der Welt widerspiegelt (d.h. modelliert). Je mehr Attribute und Verhaltensweisen Sie berücksichtigen, desto näher kommt Ihr Modell der Realität. Im Waschmaschinen-Beispiel erhalten Sie vermutlich ein präziseres Modell, wenn Sie die Attribute Trommelvolumen, interner Timer, Wasserverschluss, Motor und Motorgeschwindigkeit einbeziehen. Auch können Sie das Modell präziser machen, indem Sie die Operationen »Fleckensalz einfüllen«, »Einweichdauer bestimmen«, »Waschdauer bestimmen«, »Spüldauer bestimmen« und »Schleuderzeit bestimmen« hinzufügen (siehe Abbildung 2.2).

43

Stunde

Abb. 2.2: Das Modell wird durch Hinzufügen von Attributen und Operationen realitätsnäher.

2

Objektorientierung verstehen

Waschmaschine herstellerName modellBezeichnung serienNummer kapazität trommelVolumen internerTimer wasserVerschluss motor motorGeschwindigkeit wäscheEinfüllen( ) waschMittelEinfüllen( ) wäscheAusladen( ) fleckensalzEinfüllen( ) einweichDauerBestimmen( ) waschDauerBestimmen( ) spülDauerBestimmen( ) schleuderZeitBestimmen( )

2.2

Konzepte

Objektorientierung befasst sich nicht nur mit Attributen und Verhaltensweisen, sondern betrachtet auch andere Aspekte von Objekten. Diese Aspekte nennt man Abstraktion, Vererbung, Polymorphismus und Kapselung. Drei weitere wichtige Bestandteile der Objektorientierung sind das Versenden von Nachrichten, Assoziationen und Aggregation. Wir wollen jedes dieser Konzepte untersuchen.

2.2.1 NEUERF BEGRIF

Abstraktion

Abstraktion bedeutet einfach, die Eigenschaften und Operationen eines Objekts zu filtern, bis nur die, die man braucht, übrig sind. Was heißt dieses »die, die man braucht«? Verschiedene Arten von Aufgaben erfordern unterschiedliche Informationsmengen, selbst wenn die Aufgaben aus demselben Gebiet stammen. Beim zweiten Anlauf, eine Waschmaschine zu bauen, traten mehr Attribute und Operationen zu Tage, als beim ersten Anlauf. Lohnt das die Mühe? Wenn Sie ein Mitglied eines Entwicklungsteams sind, das letztlich ein Computerprogramm schreiben möchte, welches exakt simuliert, wie eine Waschmaschine ihre Aufgabe erledigt, dann lohnt es ganz sicher die Mühe. Ein derartiges Programm (das eventuell von Ingenieuren benötigt wird, die

44

Konzepte

tatsächlich eine Waschmaschine bauen) muss genug enthalten, um präzise voraussagen zu können, was geschieht, wenn die Maschine fertig gestellt ist, vollständig funktioniert und Wäsche wäscht. Für Programme dieser Art können Sie das Seriennummer-Attribut herausfiltern, da es hier wohl nichts zur Sache tut. Schreiben Sie jedoch Software, die die Vorgänge in einer Wäscherei mit einer Reihe von Waschmaschinen nachvollzieht, dann lohnt es wahrscheinlich nicht die Mühe. In diesem Programm benötigen Sie vermutlich nicht all die detaillierten Attribute und Operationen aus dem vorigen Abschnitt. Allerdings sollten Sie wohl die Seriennummer jedes Waschmaschinen-Objekts verwenden. In jedem Fall haben Sie zum Schluss, wenn Sie entschieden haben, was einbezogen wird und was nicht, eine Abstraktion einer Waschmaschine.

2.2.2

Vererbung

Wie bereits erwähnt ist eine Klasse eine Kategorie von Objekten (und in der Welt der Software ein Muster zum Erzeugen neuer Objekte). Ein Objekt ist eine Instanz einer Klasse. Daraus ergibt sich eine wichtige Folge: Als Instanz einer Klasse weist ein Objekt auch sämtliche Charakteristika seiner Klasse auf. Dies nennt man Vererbung. Egal für welche Attribute und Operationen Sie sich für Ihre Waschmaschinen-Klasse entschlossen haben, jedes Objekt dieser Klasse wird diese Attribute und Operationen erben.

NEUERF BEGRIF

Es kann nicht nur ein Objekt aus einer Klasse erben, eine Klasse kann auch aus einer anderen Klasse erben. Waschmaschinen, Kühlschränke, Mikrowellenherde, Toaster, Spülmaschinen, Radios, Waffeleisen, Mixer und Bügeleisen sind alles Klassen. Darüber hinaus sind sie Mitglieder einer übergeordneten Klasse: Haushaltsgeräte. Ein Haushaltsgerät hat die Attribute Ein-/Aus-Schalter und Stromkabel sowie die Operationen Einschalten und Ausschalten. Jede einzelne Klasse von Haushaltsgeräten erbt auch diese Eigenschaften. Sobald Sie also wissen, dass etwas ein Haushaltsgerät ist, wissen Sie sofort auch, dass es über die Attribute und Operationen der Haushaltsgeräte-Klasse verfügt. Anders ausgedrückt: Waschmaschine, Kühlschrank, Mikrowellenherd etc. sind Unterklassen der Haushaltsgeräte-Klasse. Diese wiederum ist die Oberklasse der anderen. Abbildung 2.3 zeigt die Beziehung von Ober- und Unterklasse.

NEUERF BEGRIF

45

Stunde

2

Objektorientierung verstehen

Abb. 2.3: Haushaltsgeräte erben die Attribute und Operationen der Haushaltsgeräte-Klasse. Jedes Gerät ist eine Unterklasse der Haushaltsgeräte-Klasse. Diese wiederum ist die Oberklasse jeder der Unterklassen.

Haushaltsgerät

Hier muss die Vererbung noch nicht zu Ende sein. So ist z.B. das Haushaltsgerät, wie Abbildung 2.4 zeigt, eine Unterklasse der Haushaltsgegenstände. Ein weiterer Haushaltsgegenstand, die Möblierung, besitzt wieder eigene Unterklassen. Abb. 2.4: Oberklassen können zugleich auch Unterklassen sein und von anderen Oberklassen erben.

Haushaltsgegenstand

Haushaltsgerät

2.2.3 NEUERF BEGRIF

46

Möblierung

Polymorphismus

Manchmal hat eine Operation in unterschiedlichen Klassen denselben Namen. Sie können z.B. eine Tür öffnen, ein Fenster öffnen, eine Zeitung öffnen, ein Geschenk öffnen, ein Bankkonto eröffnen oder auch ein Gespräch. In jedem dieser Fälle führen Sie eine andere Operation aus. In der Objektorientierung »weiß« jede Klasse, in welcher Weise diese Operation stattfinden soll. Das ist Polymorphismus (siehe Abbildung 2.5).

Konzepte

Abb. 2.5: Polymorphismus bedeutet, dass eine Operation in verschiedenen Klassen denselben Namen haben kann und immer Auf den ersten Blick scheint es so, als ob dieses Konzept für Softwareentanders auswickler wichtiger ist als für Modellierer. Schließlich müssen Softwareentwickgeführt wird.

ler die Software schreiben, die diese Methoden in Computerprogrammen implementiert und müssen sich über wichtige Unterschiede zwischen möglicherweise gleichnamigen Operationen im Klaren sein. Und sie können Software-Klassen bauen, die »wissen«, was sie zu tun haben.

Aber Polymorphismus ist auch für Modellierer wichtig. Er ermöglicht dem Modellierer, den Kunden (dem der zu modellierende Ausschnitt der Realität vertraut ist) in dessen eigener Sprache und Terminologie anzusprechen. Manchmal führt diese Terminologie ganz natürlich zu Operationsbegriffen (wie »öffnen«), die mehr als eine Bedeutung haben können. Polymorphismus versetzt den Modellierer in die Lage, diese Terminologie beizubehalten, ohne Kunstwörter erfinden zu müssen, um die Begriffe unnötigerweise eindeutig zu erhalten.

2.2.4

Kapselung

Kürzlich unterhielten sich in der Fernsehwerbung zwei Leute darüber, wie viel Geld sie sparen würden, wenn sie vor einem Ferngespräch eine besondere Vorwahl wählten. Der eine fragt ungläubig: »Wie funktioniert das überhaupt?« Darauf der andere: »Warum ist die Banane krumm? Ist doch egal!« Das ist das Wesen der Kapselung: Wenn ein Objekt seine Operationen ausführt, sind diese Operationen verborgen (siehe Abbildung 2.6). Die meisten Menschen machen sich beim Fernsehen keine Gedanken über die komplizierte Elektronik, die sich hinter dem Bildschirm befindet und über all die Operationen, die erforderlich sind, um ein Bild auf den Schirm zu projizieren. Der Fernseher macht eben das, was er macht und verbirgt diesen Prozess vor uns. Auch die meisten anderen Haushaltsgeräte funktionieren so. (Glücklicherweise!)

NEUERF BEGRIF

47

Stunde

Abb. 2.6: Objekte kapseln das, was sie tun. Das heißt, sie verbergen die innerste Funktionsweise ihrer Operationen vor der Außenwelt und vor anderen Objekten.

2

Objektorientierung verstehen

Der Fernseher verbirgt seine Operationen vor dem Fernsehzuschauer.

Warum ist das wichtig? In der Welt der Software hilft die Kapselung die Gefahr zu minimieren, dass etwas schief geht. In einem aus Objekten bestehenden System hängen diese Objekte in unterschiedlicher Weise voneinander ab. Wenn eines von ihnen nicht richtig funktioniert und die Softwareingenieure es austauschen müssen, so führt das Verbergen seiner Operationen vor anderen Objekten dazu, dass sich ein Austausch dieser anderen Objekte wahrscheinlich erübrigt. Auch wenn Sie sich von der Software ab- und der Realität zuwenden, erkennen Sie in den Objekten, mit denen Sie arbeiten, die Wichtigkeit der Kapselung. In gewissem Sinne verbirgt Ihr Computermonitor seine Operationen vor dem Prozessor Ihres Computers. Wenn mit Ihrem Monitor etwas nicht stimmt, können Sie den Monitor entweder reparieren oder ersetzen, brauchen dies aber vermutlich nicht gleichzeitig mit dem Prozessor zu machen. NEUERF BEGRIF

48

Da wir gerade dabei sind, stellen wir hier gleich noch ein verwandtes Konzept vor. Ein Objekt verbirgt das, was es macht, vor anderen Objekten und vor der Außenwelt. (Daher bezeichnet man das Kapseln auch als »Verbergen von Informationen«.) Doch ein Objekt muss der Außenwelt auch ein »Gesicht« zeigen, damit man diese Operationen initialisieren kann. So verfügt z.B. ein Fernseher über Knöpfe, entweder am Gerät selbst oder auf der Fernbedienung. Eine Waschmaschine besitzt Drehschalter, mit denen Sie die Temperatur und den Wasserverbrauch einstellen können. Die Knöpfe des Fernsehers und die Schalter der Waschmaschine nennt man Schnittstellen.

Konzepte

2.2.5

Nachrichten versenden

Wie bereits erwähnt, arbeiten Objekte in einem System zusammen. Dies tun sie, indem sie einander Nachrichten senden. Ein Objekt sendet dem anderen die Nachricht, dass es eine Operation ausführen soll und das empfangende Objekt führt diese Operation dann aus. Ein Fernseher und eine Fernbedienung sind ein schönes, intuitives Beispiel aus unserer Umwelt. Wenn Sie eine Fernsehsendung anschauen möchten, gehen Sie erst einmal auf die Jagd nach der Fernbedienung, setzen sich dann in Ihren Lieblingssessel und drücken auf den Einschaltknopf. Was geschieht dann? Das Fernbedienungs-Objekt sendet dem Fernseher-Objekt (buchstäblich!) die Nachricht, sich einzuschalten. Das Fernseher-Objekt erhält diese Nachricht, weiß, wie es die Einschalt-Operation auszuführen hat und schaltet sich ein. Wenn Sie einen anderen Kanal sehen möchten, drücken Sie auf der Fernbedienung den entsprechenden Knopf und das Fernbedienungs-Objekt sendet dem Fernseher-Objekt eine andere Nachricht: »Kanal wechseln«. Darüber hinaus kann die Fernbedienung noch über andere Nachrichten mit dem Fernsehgerät kommunizieren, um die Lautstärke zu ändern, den Ton abzustellen oder die Untertitel auszublenden. Kommen wir noch einmal kurz auf die Schnittstellen zurück. Das Meiste, was man von der Fernbedienung aus machen kann, kann man ebenso machen, indem man von seinem Sessel aufsteht, zum Fernseher geht und am Gerät selbst Knöpfe drückt. (Manchmal tun Sie dies vielleicht sogar wirklich!) Die Schnittstelle, die der Fernseher Ihnen präsentiert (die Knöpfe) ist natürlich nicht dieselbe, die er der Fernbedienung präsentiert (ein InfrarotEmpfänger). Dies verdeutlicht Abbildung 2.7.

2.2.6

Assoziationen

Auch kommt es im Allgemeinen vor, dass Objekte normalerweise irgendwie miteinander zusammenhängen. Wenn Sie z.B. Ihren Fernseher einschalten, so sind Sie – objektorientiert ausgedrückt – mit Ihrem Fernseher assoziiert. Die Assoziation »Einschalten« funktioniert beispielsweise unidirektional (in nur eine Richtung), wie in Abbildung 2.8. Das heißt, Sie schalten Ihren Fernseher ein. So weit Sie das Fernsehen nicht übertreiben, tut Ihnen das Gerät diesen Gefallen jedoch nicht. Andere Assoziationen wie z.B. »ist verheiratet mit« sind bidirektional.

49

Stunde

Objektorientierung verstehen

2

t:

ch

hri

c Na

en

alt

ch

s ein

Abb. 2.7: Ein Beispiel für den Versand von Nachrichten von einem Objekt zum anderen. Das Fernbedienungs-Objekt sendet dem FernseherObjekt die Nachricht, sich einzuschalten. Das Fernseher-Objekt erhält diese Nachricht über seine Schnittstelle, einen InfrarotEmpfänger. Abb. 2.8: Objekte sind oft miteinander in irgendeiner Weise einschalten assoziiert. Wenn Sie Ihren Fernseher einschalten, befinden Sie sich mit diesem in einer Manchmal kann ein Objekt in mehr als nur einer Weise mit einem anderen unidirektionalen zusammenhängen. Ein Beispiel wäre, wenn Sie und Ihr Kollege Freunde Assoziation. sind. Sie befinden sich dann sowohl in einer »ist ein Freund von«- als auch in

einer »ist ein Kollege von«-Assoziation, wie Abbildung 2.9 zeigt.

50

Konzepte

Abb. 2.9: Objekte sind manchmal in mehr als einer einzigen Weise miteinander assoziiert.

ist ein Kollege von ist ein Freund von

Tom

Bill

Eine Klasse kann mit mehr als einer Klasse assoziiert sein. Eine Person kann Auto fahren, sie kann aber auch Bus fahren (siehe Abbildung 2.10).

r fäh

fäh r

t

Abb. 2.10: Eine Klasse kann mit mehr als einer anderen Klasse assoziiert sein.

t

Ein wichtiger Aspekt von Assoziationen zwischen Objekten ist die Multiplizität. Diese besagt, wie viele Objekte einer einzelnen Klasse mit einem einzelnen Objekt der assoziierten Klasse zusammenhängen. So wird z.B. eine typische Lehrveranstaltung von einem einzelnen Dozenten abgehalten. Der Kurs und der Dozent befinden sich in einer eins-zu-eins-Assoziation. In einem Proseminar jedoch ist es möglich, dass der Kurs im Laufe des Semesters von mehreren Personen unterrichtet wird. In diesem Fall befinden sich Kurs und Dozenten in einer eins-zu-viele-Assoziation.

NEUERF BEGRIF

Sie können alle möglichen Multiplizitätstypen finden, wenn Sie nur danach suchen. Ein Fahrrad fährt auf zwei Reifen (eine eins-zu-zwei-Multiplizität), ein Dreirad auf drei Reifen und ein 18-rädriges Fahrzeug auf 18 Reifen.

51

Stunde

2 2.2.7

Objektorientierung verstehen

Aggregation

Denken Sie an Ihr Computersystem. Es besteht aus einem Tower, einer Tastatur, einer Maus, einem Monitor, einem CD-ROM-Laufwerk, einer oder mehreren Festplatten, einem Modem, einem Diskettenlaufwerk, einem Drucker und eventuell noch einem Paar Lautsprecher. Innerhalb des Towers haben Sie neben den vorerwähnten Laufwerken einen Prozessor, eine Grafikkarte, eine Soundkarte und noch ein paar andere Sachen, ohne die Sie bestimmt schwerlich auskommen würden. NEUERF BEGRIF

Ihr Computer ist eine Aggregation, eine andere Art der Assoziation zwischen Objekten. Wie auch andere Gegenstände, die man gerne besitzt, besteht ein Computer aus verschiedenen Arten von Komponenten (siehe Abbildung 2.11). Sicher fallen Ihnen noch viele Beispiele für Aggregationen ein.

Abb. 2.11: Ein typisches Computersystem ist ein Beispiel für eine Aggregation: ein Objekt, das aus einer Kombination mehrerer unterschiedlicher Arten von Objekten besteht.

NEUERF BEGRIF

52

Es gibt eine Form der Aggregation, die einen starken Zusammenhang zwischen einem zusammengesetzten Objekt und seinen Objekt-Elementen bedingt. Diese nennt man Komposition. Das Wesentliche bei einer Komposition ist, dass das Element als solches nur innerhalb des zusammengesetzten Objekts existiert. So ist z.B. ein Hemd eine Komposition aus Rumpfbekleidung, einem Kragen, Ärmeln, Knöpfen, Knopflöchern und Manschetten. Lässt man das Hemd weg, wird der Kragen nutzlos.

Der Clou

Manchmal hält ein Element in einer Gesamtheit nicht so lange, wie die Gesamtheit. Die Blätter eines Baumes können absterben, bevor der Baum stirbt. Wenn man hingegen den Baum zerstört, sterben auch die Blätter (siehe Abbildung 2.12). Aggregation und Komposition sind wichtig, weil sie extrem häufige Fälle widerspiegeln und Ihnen dadurch helfen, sehr realitätsnahe Modelle zu erstellen. Abb. 2.12: In einer Komposition kann manchmal ein Element eher sterben als die Gesamtheit. Wenn Sie die Gesamtheit zerstören, zerstören Sie auch das Element.

2.3

Der Clou

Objekte und Assoziationen von Objekten bilden das Rückgrat funktionierender Systeme. Um diese Systeme zu modellieren, müssen Sie verstehen, was dies für Assoziationen sind. Wenn Ihnen die möglichen Assoziationsarten bekannt sind, dann können Sie tief in die Trickkiste greifen, wenn Sie mit den Kunden Bedürfnisse erörtern, Anforderungen sammeln und die Systeme modellieren, die diesen Kunden helfen, die Herausforderungen an ihr Unternehmen zu bewältigen. Besonders wichtig ist es, die Konzepte der Objektorientierung zum besseren Verständnis des Wissensgebietes des Kunden (seiner Domäne) zu nutzen und dieses Verständnis ihm gegenüber zu demonstrieren, indem Sie eine ihm verständliche Sprache sprechen.

53

Stunde

2

Objektorientierung verstehen

Hier kommt die UML ins Spiel. In den nächsten drei Stunden werden Sie lernen, wie man die UML für die Darstellung der in der vergangenen Stunde gelernten Konzepte anwendet.

2.4

Zusammenfassung

Objektorientierung ist ein Gedankengebäude, das auf wenigen Grundprinzipien beruht. Ein Objekt ist eine Instanz einer Klasse. Eine Klasse ist eine allgemeine Kategorie von Objekten, die dieselben Attribute und Operationen haben. Beim Erzeugen eines Objekts entscheidet der Problembereich, in dem man arbeitet, darüber, wie viele der Attribute und Operationen zu berücksichtigen sind. Ein wichtiger Aspekt der Objektorientierung ist die Vererbung: Ein Objekt erbt die Attribute und Operationen seiner Klasse. Auch eine Klasse kann Attribute und Operationen von einer anderen Klasse erben. Auch Polymorphismus ist von Bedeutung. Dieser spezifiziert, dass eine Operation in verschiedenen Klassen denselben Namen haben kann und dass jede dieser Klassen die betreffende Operation anders ausführen wird. Objekte verbergen vor anderen Objekten und vor der Außenwelt, was ihre Operationen leisten. Jedes Objekt stellt eine Schnittstelle zur Verfügung, damit andere Objekte (und auch Menschen) es zum Ausführen seiner Operationen veranlassen können. Objekte arbeiten zusammen, indem sie einander Nachrichten senden. Dabei handelt es sich um Aufforderungen zum Ausführen von Operationen. Normalerweise sind Objekte miteinander assoziiert. Die Assoziation kann mehrere Formen haben. Ein Objekt in der einen Klasse kann sich mit beliebig vielen Objekten einer anderen Klasse assoziieren. Die Aggregation ist eine Art Assoziation. Ein aggregiertes Objekt besteht aus einer Menge von Objekt-Elementen. Die Komposition ist eine Sonderform der Aggregation: In einem zusammengesetzten Objekt bestehen die einzelnen Elemente nur als Teil der Gesamtheit.

54

Workshop

2.5

Fragen und Antworten

F: Sie sagten, die Objektorientierung habe die Softwareszene im Sturm erobert. Gibt es nicht auch wichtige Anwendungen, die nicht objektorientiert sind? A: Ja. Die nicht objektorientierten nennt man oft »System-Hinterlassenschaften«: Programme, denen man ihr Alter in vielen Fällen bereits anmerkt. Die Objektorientierung bietet viele Vorteile, wie z.B. Wiederverwendbarkeit und kurze Entwicklungszeit. Aus diesen Gründen werden Sie feststellen, dass neue Anwendungen (und auch neu geschriebene Versionen vieler Hinterlassenschaften) objektorientiert geschrieben sind.

2.6

Workshop

Um zu wiederholen, was Sie über Objektorientierung gelernt haben, sollten Sie sich an den folgenden Fragen versuchen. Die Antworten finden Sie in Anhang A unter »Antworten«.

2.6.1

Fragen

1. Was ist ein Objekt? 2. Wie arbeiten Objekte zusammen? 3. Was gibt die Multiplizität an? 4. Können zwei Objekte in mehr als einer Weise miteinander zusammenhängen?

2.6.2

Übungen

Da dies eine Theoriestunde war, gibt es hier keine Übungen. In den nächsten Stunden werden Sie jedoch etliche Übungen finden!

55

Stunde 3

Objektorientiert arbeiten 3

Objektorientiert arbeiten

Nun ist es an der Zeit, die UML mit den Konzepten der Objektorientierung, die Sie in der letzten Stunde gelernt haben, zusammenzubringen. In dieser Stunde werden Sie Ihr Wissen über Objektorientierung festigen und zugleich mehr über die UML lernen. Folgende Themen werden behandelt:

✘ Visualisieren einer Klasse ✘ Attribute ✘ Operationen ✘ Verantwortlichkeiten und Einschränkungen ✘ Entdecken von Klassen

3.1

Visualisieren einer Klasse

Wie bereits in der ersten Stunde dargestellt, ist das Rechteck das Symbol, das in der UML eine Klasse repräsentiert. Der Klassenname wird nach Konvention ein mit einem Großbuchstaben beginnendes Wort. Er steht oben im Rechteck. Besteht der Name Ihrer Klasse aus zwei Wörtern, so fügen Sie diese zusammen und schreiben auch den Anfangsbuchstaben des zweiten Wortes groß (wie bei der WaschMaschine in Abbildung 3.1).

WaschMaschine

Abb. 3.1: Klassensymbol der UML.

TIPP

NEUERF BEGRIF

57

Stunde

3

Objektorientiert arbeiten

Ein anderes UML-Konstrukt, das Paket, kann auch im Namen einer Klasse eine Rolle spielen. Wie bereits in der ersten Stunde »Einführung in die UML« gesagt, verwendet die UML Pakete, um die Elemente eines Programms zu organisieren. Sie erinnern sich vielleicht, dass die UML Pakete als Registerkarte mit Reiter und einem Textstring als Namen darstellt (siehe Abbildung 3.2). Abb. 3.2: Ein Paket in der UML.

NEUERF BEGRIF

Abb. 3.3: Klasse mit Pfadnamen.

Haushaltsgeräte

Wenn die WaschMaschine zu einem Paket namens Haushaltsgeräte gehört, so kann man ihr den Namen Haushaltsgeräte::WaschMaschine geben. Die Doppelpunkte trennen den links stehenden Paketnamen von dem rechts stehenden Klassennamen. Diese Art von Klassenbezeichnung nennt man einen Pfadnamen (siehe Abbildung 3.3).

Haushaltsgeräte::WaschMaschine

3.2

Attribute

Ein Attribut ist eine Eigenschaft einer Klasse. Es beschreibt einen Wertebereich, den die betreffende Eigenschaft in Objekten (d.h. Instanzen) haben kann. Nach Konvention wird ein aus nur einem Wort bestehendes Attribut klein geschrieben. Besteht der Name aus mehr als einem Wort, so fügt man die Wörter zusammen und lässt jedes außer dem ersten Wort mit einem Großbuchstaben beginnen. Wie Abbildung 3.4 zeigt, beginnt die Liste der Attributnamen unterhalb einer Linie, die sie von dem Klassennamen abtrennt.

58

Attribute

WaschMaschine herstellerName modellBezeichnung serienNummer kapazität

Jedes Objekt der Klasse hat für jedes Attribut bildung 3.5 zeigt ein Beispiel. Beachten Sie, nem Kleinbuchstaben beginnt und vor einem derum vor dem Klassennamen steht und dass chen wird.

Abb. 3.4: Eine Klasse und ihre Attribute.

einen spezifischen Wert. Abdass ein Objektname mit eiDoppelpunkt steht, der wieder gesamte Name unterstri-

Der Name meinWäscher:WaschMaschine ist ein benanntes Objekt. Es gibt auch anonyme Objekte wie z.B. :WaschMaschine.

meinWäscher: WaschMaschine herstellerName = "Laundatorium" modellBezeichnung = "Washmeister" serienNummer = "GL57774" kapazität = 16

Abb. 3.5: Ein Objekt hat für jedes Attribut seiner Klasse einen spezifischen Wert.

Die UML gibt Ihnen die Möglichkeit, für Attribute noch weitere Informationen anzugeben. Im Klassensymbol können Sie für den Wert jedes Attributs einen Typ spezifizieren. Mögliche Typen wären string (Zeichenkette), float (Fließkommazahl), integer (ganze Zahl) und boolean (und andere aufgezählte Typen). Um einen Typ anzugeben, trennen Sie den Attributnamen mit einem Doppelpunkt vom Typ ab. Sie können auch einen Standardwert für ein Attribut spezifizieren. Abbildung 3.6 zeigt diese verschiedenen Möglichkeiten, Attribute anzugeben.

59

Stunde

Abb. 3.6: Ein Attribut kann sowohl seinen Typ als auch einen Standardwert zeigen.

WaschMaschine herstellerName: String = "Laundatorium" modellBezeichnung: String serienNummer: String kapazität: Integer

3.3 NEUERF BEGRIF

Abb. 3.7: Die Liste der Operationen einer Klasse beginnt unter einer Linie, die sie von den Klassenattributen trennt.

NEUERF BEGRIF

60

Objektorientiert arbeiten

3

Operationen

Eine Operation ist etwas, was eine Klasse tun kann oder was Sie (oder eine andere Klasse) mit dieser Klasse tun können. Wie ein Attributname wird auch ein Operationsname vollständig klein geschrieben, wenn es sich um ein einziges Wort handelt. Besteht der Name aus mehreren Wörtern, so fügt man diese zusammen und lässt jedes außer dem ersten mit einem Großbuchstaben beginnen. Wie Abbildung 3.7 zeigt, beginnt die Liste der Operationen unterhalb einer Linie, die Operationen und Attribute trennt. WaschMaschine herstellerName modellBezeichnung serienNummer kapazität wäscheEinfüllen( ) wäscheAusladen( ) waschMittelEinfüllen( ) einschalten( )

Genauso wie man Zusatzinformationen für Attribute anzeigen kann, kann man auch Zusatzinformationen für Operationen anzeigen. In den Klammern, die auf einen Operationsnamen folgen, kann man den Parameter zeigen, auf den die Operation angewendet wird, sowie den Typ dieses Parameters. Eine bestimmte Art von Operation, die Funktion, gibt nach getaner Arbeit einen Wert zurück. Für eine Funktion kann man den Rückgabewert und dessen Typ anzeigen.

Attribute, Operationen und Visualisierung

Diese einzelnen Informationen über eine Operation nennt man die Operations-Signatur. Abbildung 3.8 zeigt, wie Sie die Signatur darstellen. WaschMaschine herstellerName modellBezeichnung serienNummer kapazität

NEUERF BEGRIF

Abb. 3.8: Die Signatur für eine Operation.

wäscheEinfüllen(C:String) wäscheAusladen(C:String) waschMittelEinfüllen(D:Integer) einschalten( ):Boolean

3.4

Attribute, Operationen und Visualisierung

Bisher haben wir Klassen isoliert behandelt und alle Attribute und Operationen einer Klasse gezeigt. In der Praxis werden Sie allerdings mehr als immer nur eine einzige Klasse zeigen wollen. Dabei ist es normalerweise nicht nützlich, jedes Mal alle Attribute und Operationen anzuzeigen. Dies würde das Diagramm überladen. Stattdessen können Sie einfach den Klassennamen angeben und entweder Attribut- oder Operationsbereich oder auch beides leer lassen wie in Abbildung 3.9. WaschMaschine

Manchmal ist es hilfreich, zwar nicht alle, aber doch immerhin einige der Attribute oder Operationen zu zeigen. Als Hinweis, dass Sie nur einen Ausschnitt davon angegeben haben, ergänzen Sie die Angegebenen mit drei Punkten »...«. Dies nennt man eine Ellipse und die Auslassung einiger oder aller Attribute oder Operationen bezeichnet man als Elidieren einer Klasse. Abbildung 3.10 zeigt, wie man eine Ellipse anwendet.

Abb. 3.9: In der Praxis zeigt man nicht immer alle Attribute und Operationen einer Klasse.

NEUERF BEGRIF

61

Stunde

Abb. 3.10: Eine Ellipse weist darauf hin, dass nicht die gesamte Operationsmenge angegeben wurde.

3

Objektorientiert arbeiten

WaschMaschine herstellerName •••

wäscheEinfüllen( ) •••

Ist die Liste der Attribute oder Operationen lang, können Sie einen Stereotyp verwenden, um sie so zu organisieren, dass man sie erfassen kann. Ein Stereotyp ist das Verfahren, das die UML zur Verfügung stellt, um eine Erweiterung ihrer Notation zu ermöglichen: Sie können damit neue Elemente erstellen, die für die spezielle, zu lösende Aufgabe spezifisch sind. Wie in der ersten Stunde bereits erwähnt, zeigen Sie einen Stereotyp wie in Abbildung 3.11 als einen Namen in zwei kleinen, eckigen Klammern, die als Guillemets bezeichnet werden. Wie in Abbildung 3.11 können Sie einen Stereotyp als Oberbegriff für eine Teilmenge der Attribute einsetzen. Abb. 3.11: Mit einem Stereotyp kann man eine Liste von Attributen oder Operationen organisieren.

WaschMaschine «ID-Info» herstellerName modellBezeichnung serienNummer «Maschinen-Info» kapazität «zur Wäsche» wäscheEinfüllen( ) wäscheAusladen( ) waschMittelEinfüllen( ) «zur Maschine» einschalten( )

Der Stereotyp ist ein flexibles, sehr vielseitig einsetzbares Konstrukt. Sie können ihn z.B. oberhalb des Namens in einem Klassensymbol verwenden, um etwas darüber auszusagen, welche Rolle die betreffende Klasse spielt.

62

Verantwortlichkeiten und Einschränkungen

3.5

Verantwortlichkeiten und Einschränkungen

Das Klassensymbol ermöglicht Ihnen, noch einen weiteren Informationstypus über eine Klasse zu spezifizieren. In dem Bereich unterhalb der Operationsliste können Sie die Verantwortlichkeiten einer Klasse zeigen. Die Verantwortlichkeit (engl. responsibility) ist eine Beschreibung, was die Klasse zu tun hat, d.h. was ihre Attribute und Operationen erreichen sollen. So hat z.B. eine Waschmaschine die Verantwortlichkeit, schmutzige Wäsche als Eingabe zu nehmen und saubere auszugeben. Im Symbol zeigen Sie Verantwortlichkeiten in dem Bereich unterhalb der Region an, die die Operationen enthält (siehe Abbildung 3.12). WaschMaschine «ID-Info» herstellerName modellBezeichnung serienNummer «Maschinen-Info» kapazität «zur Wäsche» wäscheEinfüllen( ) wäscheAusladen( ) waschMittelEinfüllen( )

NEUERF BEGRIF

Abb. 3.12: In einem Klassensymbol schreibt man die Verantwortlichkeiten der Klasse in die Region unterhalb des Bereichs mit der Operationsliste.

«zur Maschine» einschalten( )

Der Grundgedanke dabei ist, genug Informationen zu geben, um eine Klasse eindeutig zu beschreiben. Die Verantwortlichkeiten einer Klasse anzugeben ist eine informelle Möglichkeit, Mehrdeutigkeit zu vermeiden. Eine etwas formalere Möglichkeit ist, eine Einschränkung (constraint) hinzuzufügen: einen formlosen Text in geschweiften Klammern. Der geklammerte Text gibt eine oder mehrere Regeln an, die die Klasse befolgt. Angenommen, Sie möchten z.B. in der WaschMaschine-Klasse spezifizieren, dass die Kapazität eines Gerätes nur entweder acht, neun oder zehn Kilogramm betragen darf (und dadurch das Kapazitätsattribut der WaschMaschine-Klasse »einschränken«). Dann würden Sie {Kapazität = 8 oder 9 oder 10 kg} neben das Klassensymbol von WaschMaschine schreiben. Abbildung 3.13 zeigt, wie das gemacht wird.

NEUERF BEGRIF

63

Stunde

Abb. 3.13: Die Regel in geschweiften Klammern schränkt das Kapazitätsattribut auf einen von drei möglichen Werten ein.

3

Objektorientiert arbeiten

WaschMaschine herstellerName modellBezeichnung serienNummer kapazität

{kapazität = 8 oder 9 oder 10 kg}

wäscheEinfüllen( ) wäscheAusladen( ) waschMittelEinfüllen( ) einschalten( )

Die UML arbeitet noch mit einem weiteren, sehr viel formaleren Mittel, Einschränkungen hinzuzufügen, die Definitionen klarer machen. Es handelt sich dabei um eine komplette Sprache namens Object Constraint Language (OCL). Dieses ausgefeilte und manchmal nützliche Werkzeug hat seine eigenen Regeln, Termini und Operatoren.

3.6

Beigefügte Notizen

Zusätzlich zu Attributen, Operationen, Verantwortlichkeiten und Einschränkungen können Sie einer Klasse in Form von daran angehängten Notizen noch mehr Informationen beigeben. Normalerweise machen Sie eine Notiz zu einem Attribut oder einer Operation. Abbildung 3.14 zeigt eine Notiz, die sich auf eine amtliche Norm bezieht, nach der Seriennummern für Objekte der WaschMaschine-Klasse erstellt werden. Abb. 3.14: Eine beigefügte Notiz gibt weitergehende Informationen über die Klasse.

WaschMaschine herstellerName modellName serienNummer kapazität wäscheEinfüllen( ) wäscheAusladen( ) waschMittelEinfüllen( ) einschalten( )

Vgl. amtliche Norm DIN 4711 für die Vergabe von Seriennummern.

Eine Notiz kann Grafik und Text enthalten.

64

Klassen – was sie tun und wie man sie findet

3.7

Klassen – was sie tun und wie man sie findet

Klassen enthalten das Vokabular und die Terminologie eines Wissensgebietes. Während Sie mit den Kunden reden, ihr Fachgebiet analysieren und Computersysteme entwerfen, die Aufgaben aus diesem Gebiet lösen, lernen Sie die entsprechende Terminologie kennen und modellieren die einzelnen Termini als Klassen in der UML. Achten Sie bei Ihren Kundengesprächen auf die Substantive, mit denen die Kunden die Gegenstände ihres Geschäfts beschreiben. Diese Substantive werden zu den Klassen Ihres Modells. Achten Sie ebenso auf die Verben, da diese die Operationen der Klassen bilden werden. Die Attribute sind Substantive, von denen sich herausstellt, dass sie sich auf die klassenbildenden Substantive beziehen. Wenn Sie die Liste der zentralen Klassen besitzen, fragen Sie die Kunden, was die einzelnen Klassen im Unternehmen zu tun haben. Die Antworten der Kunden zeigen Ihnen die Verantwortlichkeiten der Klassen. Angenommen, Sie sind ein Analytiker, der ein Modell eines Basketballspiels baut und interviewen den Trainer, um das Spiel zu verstehen. Das Gespräch könnte ungefähr folgendermaßen verlaufen: Analytiker: »Worum geht es beim Basketball?« Trainer: »Das Ziel ist, den Ball in den Korb zu werfen und mehr Punkte als die gegnerische Mannschaft zu erringen. Jede Mannschaft besteht aus fünf Spieler: zwei Verteidiger, zwei Angriffsspieler und ein Center. Jede Mannschaft spielt den Ball nach vorne mit dem Ziel, ihn letztlich in den Korb zu werfen.« Analytiker: »Wie spielt sie den Ball?« Trainer: »Durch Dribbeln und durch Pässe. Aber die Mannschaft muss auf den Korb werfen, bevor die 30-Sekunden-Anlage abläuft.« Analytiker: »30-Sekunden-Anlage?« Trainer: »Ja. Wenn eine Mannschaft in den Ballbesitz gekommen ist, muss sie in der Profiliga der amerikanischen NBA innerhalb von 24 Sekunden, in internationalen Wettbewerben innerhalb von 30 Sekunden und in der Amateurliga innerhalb von 35 Sekunden versuchen, einen Korb zu werfen.« Analytiker: »Wie werden die Punkte vergeben?« Trainer: »Ein Korb bringt zwei Punkte, es sei denn, er wurde von einer Stelle hinter der Drei-Punkte-Linie geworfen. In diesem Fall zählt er drei

65

Stunde

3

Objektorientiert arbeiten

Punkte. Ein Freiwurf ist übrigens die Strafe, die einer Mannschaft für ein Foulspiel auferlegt wird. Foult ein Spieler einen Gegner, wird das Spiel gestoppt und der Gegner darf von der Freiwurflinie aus auf den Korb werfen.« Analytiker: »Erklären Sie mir bitte noch mehr darüber, was die Spieler tun.« Trainer: »Die Verteidiger dribbeln und passen am meisten. Sie sind normalerweise kleiner als die Angreifer und diese wiederum sind kleiner als die Center. Alle Spieler sollten in der Lage sein, zu dribbeln, Pässe und Körbe zu werfen und Rebounds zu holen. Die Angreifer holen die meisten Rebounds und werfen die meisten Pässe über mittlere Distanz, während der Center in der Nähe des Korbs steht und auf kurze Distanz wirft.« Analytiker: »Wie groß ist das Spielfeld? Und wie lange dauert überhaupt so ein Spiel?« Trainer: »In internationalen Wettbewerben ist das Spielfeld 28 Meter lang und 15 Meter breit. Der Korb hängt in drei Meter Höhe. In der NBA dauert ein Spiel 48 Minuten, die in vier jeweils zwölf Minuten lange Viertelzeiten unterteilt sind. In internationalen Wettbewerben und bei den Amateuren dauert ein Spiel 40 Minuten, die sich in zwei Halbzeiten zu je 20 Minuten aufteilen. Eine Spieluhr zeigt an, wie lange noch zu spielen ist.« Das könnte noch lange so weitergehen, aber wir möchten hier einen Schnitt machen und festhalten, wo wir sind. Folgende Substantive haben Sie entdeckt: Ball, Korb, Mannschaft, Spieler, Verteidiger, Angreifer, Center, Wurf, 30-Sekunden-Anlage, Drei-Punkte-Linie, Freiwurf, Foul, Freiwurflinie, Spielfeld, Spieluhr. Die Verben sind: werfen, nach vorn spielen, dribbeln, passen, foulen, rebound. Es gibt auch Zusatzinformationen über einige der Substantive – z.B. die relative Größe der Spieler auf den verschiedenen Positionen, die Abmessungen des Spielfelds, die Gesamtzeit, die eine 30-Sekunden-Anlage anzeigt und die Spieldauer. Schließlich können Sie auch noch Ihren gesunden Menschenverstand benutzen und selbst einige Attribute erstellen. So wissen Sie z.B., dass ein Ball ein Volumen und einen Umfang hat. Mit diesen Informationen können Sie ein Diagramm wie das in Abbildung 3.15 erstellen. Es zeigt die Klassen und stellt einige Attribute, Operationen und Einschränkungen sowie auch Verantwortlichkeiten dar. Dieses Diagramm könnten Sie als Grundlage für weitere Gespräche mit dem Trainer nehmen, um noch mehr Informationen offen zu legen.

66

Zusammenfassung

Ball

Player

durchmesser volumen

name größe gewicht

dribbeln( ) werfen( ) passen( ) nachVornSpielen( )

ballDribbeln( ) ballPassen( ) ballWerfen( ) reboundHolen( ) gegnerFoulen( )

Angreifer

Center

vorwiegend Würfe über mittlere Distanz und Rebounds

bleibt neben dem Korb, wirft auf kurze Distanz

Verteidiger

vorwiegend dribbeln und passen

Wurf

Mannschaft

Korb

Abb. 3.15: Ein erstes Klassendiagramm zum Modellieren eines Basketballspiels.

Foul

DreiPunkteLinie

FreiWurf WurfUhr

{Profis = 24 Sek. Amateure = 35 Sek. Intl. = 30 Sek.}

SpielUhr

{Profis = 4 mal 12 Min. Amateure und Intl. = 2 mal 20 Min.}

Dauer

3.8

{Profis = 48 Min. Amateure und Intl. = 40 Min.}

FreiWurfLinie

SpielFeld

Zusammenfassung

Das Rechteck ist in der UML das Symbol für eine Klasse. Ihr Name sowie ihre Attribute, Operationen und Verantwortlichkeiten kommen in bestimmte Bereiche innerhalb des Rechtecks. Einen Stereotyp können Sie verwenden, um Listen von Attributen und Operationen zu organisieren. Elidieren können Sie eine Klasse, indem Sie nur eine Teilmenge ihrer Attribute und Operationen offenlegen. Dadurch wird ein Klassendiagramm weniger unruhig. Zeigen können Sie den Typ und Anfangswert eines Attributs sowie die Werte, auf denen eine Operation arbeitet, mit den dazugehörigen Typen. Bei einer Operation nennt man diese Zusatzinformation eine Signatur. Um die Mehrdeutigkeit in einer Klassenbeschreibung zu mindern, können Sie Einschränkungen hinzufügen. Zudem gestattet Ihnen die UML, durch Beifügen von Notizen zu dem rechteckigen Klassensymbol mehr über die betreffende Klasse auszusagen.

67

Stunde

3

Objektorientiert arbeiten

Klassen repräsentieren das Vokabular eines Wissensgebiets. In Gesprächen mit einem Kunden oder einem Fachmann auf diesem Gebiet treten Substantive zu Tage, die die Klassen eines Modells werden können und Verben, die Operationen werden können. Sie können den Kunden mit Hilfe eines Klassendiagramms auch anregen, mehr über sein Fachgebiet zu reden und weiteres Wissen preiszugeben.

3.9

Fragen und Antworten

F: Sie haben gesagt, man soll den »gesunden Menschenverstand« benutzen, um das Klassendiagramm für Basketball abzurunden. Schön und gut, aber was ist, wenn ich ein Gebiet analysieren muss, das mir ganz neu ist und wo der gesunde Menschenverstand mich nicht unbedingt weiterbringt? A: Sie werden sich fast immer auf ein Gebiet einlassen müssen, das Ihnen neu ist. Ehe Sie einen Kunden oder einen Experten dieses Fachs treffen, sollten Sie versuchen, ein »Teilexperte« zu werden. Bereiten Sie sich auf das Treffen vor, indem Sie möglichst viele Dokumentationen aus diesem Wissensgebiet lesen. Fragen Sie Ihre Interviewpartner nach Aufsätzen oder Handbüchern, die sie eventuell bereits geschrieben haben. Wenn Sie diese gelesen haben, kennen Sie die Grundlagen und sind in der Lage, zielsichere Fragen zu stellen. F: Wann muss ich die Signatur einer Operation zeigen? A: Voraussichtlich nach der Analysephase eines Entwicklungsprozesses, bevor die eigentliche Entwurfsarbeit beginnt. Die Signatur ist für Programmierer eine nützliche Information.

3.10 Workshop Um zu wiederholen, was Sie über Objektorientierung gelernt haben, sollten Sie sich an diesen Fragen versuchen. Die Antworten finden Sie in Anhang A unter »Antworten«.

68

Workshop

3.10.1 Fragen 1. Wie stellen Sie in der UML eine Klasse dar? 2. Welche Informationen können Sie in einem Klassensymbol zeigen? 3. Was ist eine Einschränkung? 4. Aus welchem Grund würden Sie eine Notiz an ein Klassensymbol hängen?

3.10.2 Übungen 1. Hier ist eine kurze (und unvollständige) Beschreibung eines Hockeyspiels: Eine Hockeymannschaft besteht aus einem Mittelstürmer, einem Torwart, zwei Flügelspielern und zwei Verteidigern. Jeder Spieler hat einen Hockeyschläger, mit dem er den Puck auf dem Eis vorantreibt. Das Ziel ist, den Puck mit dem Schläger ins Tor zu befördern. Hockey spielt man auf einer Eisfläche, die maximal ca. 30 Meter breit und 60 Meter lang ist. Der Mittelstürmer hat die Aufgabe, den Puck auf die Flügelspieler zu passen, die in der Regel die besten Torschützen der Mannschaft sind. Die Verteidiger versuchen, die Spieler der gegnerischen Mannschaft daran zu hindern, sich so aufzustellen, dass sie den Puck ins Tor schießen können. Der Torwart ist die letzte Verteidigungslinie; er wehrt die Schüsse des Gegners ab. Jedes Mal, wenn er einen Torschuss verhindern konnte, bekommt er einen »save«. Jedes Tor zählt einen Punkt. Das Spiel dauert 60 Minuten, aufgeteilt in drei Drittelzeiten von jeweils 20 Minuten Dauer. Benutzen Sie diese Informationen, um ein Diagramm wie das in Abbildung 3.15 zu zeichnen. Wenn Sie mehr als in der obigen Beschreibung über Hockey wissen, fügen Sie diese Informationen bitte Ihrem Diagramm hinzu. 2. Wenn Sie über Basketball mehr wissen, als ich in Abbildung 3.15 dargestellt habe, fügen Sie bitte diesem Diagramm Informationen hinzu.

69

Stunde 4

Beziehungen spielen lassen 4

Beziehungen spielen lassen

In dieser Stunde werden Sie lernen, wie Klassen miteinander zusammenhängen. Behandelt werden:

✘ Assoziationen ✘ Multiplizität ✘ Qualifizierte Assoziationen ✘ Reflexive Assoziationen ✘ Vererbung und Generalisierung ✘ Abhängigkeiten In dem Modell, mit dem wir die letzte Stunde beendet haben, erhielten Sie eine Menge von Klassen, die das Basketball-Vokabular repräsentierten. Zwar ist damit bereits eine Grundlage gelegt, um herauszufinden, worum es beim Basketball eigentlich geht, aber es müsste Ihnen aufgefallen sein, dass noch etwas fehlt. Dieses »Etwas« ist ein Gefühl dafür, wie die Klassen miteinander zusammenhängen. Wenn Sie das Modell (Abbildung 3.15) betrachten, werden Sie sehen, dass es nicht zeigt, was ein Spieler mit dem Ball zu tun hat, wie die Spieler zusammen eine Mannschaft bilden oder wie ein Spiel überhaupt verläuft. Es ist, als hätten Sie nur eine Liste von Begriffen und kein Bild eines Wissensgebiets. In dieser Stunde werden Sie die Verbindungen zwischen den Klassen herstellen und das Bild ausfüllen.

TIPP

NEUERF BEGRIF

71

Stunde

4 4.1

NEUERF BEGRIF

Beziehungen spielen lassen

Assoziationen

Wenn Klassen konzeptuell zusammenhängen, nennt man diesen Zusammenhang Assoziation. Das Basketball-Modell vom Anfang bietet dafür einige Beispiele. Eines davon wollen wir untersuchen: den Zusammenhang zwischen einem Spieler und der Mannschaft. Diese Assoziation können Sie mit der Phrase »ein Spieler spielt in der Mannschaft« umschreiben. Sie visualisieren die Assoziation als eine die beiden Klassen verbindende Linie. Der Name der Assoziation (»spielt für«) steht direkt oberhalb der Linie. Es ist hilfreich, die Richtung der Beziehung anzugeben. Dies tun Sie, indem Sie die Spitze eines ausgefüllten Dreiecks in die entsprechende Richtung zeigen lassen.

Abb. 4.1: Spieler Mannschaft spielt in Assoziation zwischen einem Spieler und einer Wenn eine Klasse mit einer anderen zusammenhängt, spielt normalerweise Mannschaft. jede dieser Klassen in der Assoziation auch eine Rolle. Diese Rollen können

Sie im Diagramm zeigen, indem Sie sie neben der Klasse, die die Rolle spielt, an der Assoziationslinie vermerken. Bei einer Profimannschaft ist in der Assoziation zwischen Spieler und Mannschaft letztere der Arbeitgeber und erstere der Arbeitnehmer. Abbildung 4.2 zeigt, wie diese Rollen dargeAbb. 4.2: stellt werden. In der Regel spielt in einer Spieler Mannschaft spielt in Assoziation Arbeitnehmer Arbeitgeber jede Klasse eine Rolle. Diese Rollen Diese Assoziation kann auch in umgekehrter Richtung funktionieren: Eine kann man im Mannschaft stellt Spieler ein. Sie können beide Assoziationen in demselben Diagram darDiagramm zeigen, wobei ein ausgemaltes Dreieck wie in Abbildung 4.3 die stellen.

Richtung der jeweiligen Assoziation angibt.

Abb. 4.3: In ein und demselben Diagramm können zwei Assoziationen zwischen Klassen erscheinen.

72

Spieler

spielt in

Mannschaft

stellt ein

Assoziationen können komplexer sein und nicht bloß eine Klasse in Verbindung mit einer anderen zeigen. Mit einer Klasse können auch mehrere Klassen zusammenhängen. Wenn Sie an die Verteidiger, Angreifer und Center und ihre Assoziationen mit der Mannschaft-Klasse denken, kommen Sie zu dem in Abbildung 4.4 gezeigten Diagramm.

Assoziationen

Verteidiger

sp

iel

Angreifer

t in

ielt

Center

4.1.1

Mannschaft

spielt in

Abb. 4.4: Mit einer bestimmten Klasse können mehrere Klassen assoziiert sein.

in

sp

Einschränkungen für Assoziationen

Manchmal muss sich eine Assoziation zwischen zwei Klassen nach einer Regel richten. Diese Regel zeigen Sie an, indem Sie in der Nähe der Assoziationslinie eine Einschränkung anbringen. So bedient z.B. ein BankKassierer einen Kunden, aber jeder Kunde wird in der Reihenfolge bedient, wie er sich in die Schlange einreiht. Dies können Sie im Modell festhalten, indem Sie wie in Abbildung 4.5 in die Nähe der Kunden-Klasse in geschweiften Klammern (die auf eine Einschränkung hinweisen) das Wort {nacheinander} schreiben. BankKassierer

{nacheinander} bedient

Kunde

Ein anderer Einschränkungstyp ist die Oder-Beziehung, dargestellt durch {Or} auf einer gestrichelten Linie, die zwei Assoziationslinien miteinander verbindet. Abbildung 4.6 modelliert einen Oberstufenschüler, der sich zwischen einem wissenschaftlichen und einem kaufmännischen Kurs entscheidet. wählt

Akademisch

wählt

Kaufmännisch

OberStufenSchüler {oder}

Abb. 4.5: Eine Assoziation können Sie einer Einschränkung unterwerfen. In diesem Beispiel wird die Bedient-Assoziation derart eingeschränkt, dass der BankKassierer die Kunden der Reihe nach bedient.

Abb. 4.6: Die Oder-Beziehung zwischen zwei Assoziationen ist eine Einschränkung.

73

Stunde

4 4.1.2

NEUERF BEGRIF

Abb. 4.7: Eine Assoziationsklasse modelliert die Attribute und Operationen einer Assoziation. Sie ist durch eine gestrichelte Linie mit der Assoziation verbunden und kann wiederum mit einer anderen Klasse assoziiert werden.

Abb. 4.8: Eine Verknüpfung ist eine Instanz einer Assoziation. Statt Klassen verbindet sie Objekte. Bei einer Verknüpfung unterstreichen Sie den Verknüpfungsnamen ebenso wie den Namen eines Objekts.

74

Beziehungen spielen lassen

Assoziationsklassen

Genauso wie eine Klasse kann eine Assoziation Attribute und Operationen besitzen. Eigentlich handelt es sich in solchen Fällen um eine Assoziationsklasse. Diese visualisieren Sie ebenso wie eine reguläre Klasse und verbinden sie durch eine gestrichelte Linie mit der Assoziationslinie. Eine Assoziationsklasse kann mit anderen Klassen assoziiert sein. Abbildung 4.7 zeigt eine Assoziationsklasse für die Spielt-für-Assoziation zwischen einem Spieler und einer Mannschaft. Die Assoziationsklasse, Vertrag, ist mit der ManagerKlasse assoziiert. Spieler

spielt in

Mannschaft

Vertrag Ausgehandelt von

4.1.3

Manager

Verknüpfungen

Wie ein Objekt die Instanz einer Klasse ist, so hat auch eine Assoziation Instanzen. Wenn wir uns einen bestimmten Spieler vorstellen, der für eine bestimmte Mannschaft spielt, dann nennt man die Spielt-Für-Beziehung eine Verknüpfung (link). Dargestellt wird sie als Linie, die zwei Objekte verbindet. So, wie Sie den Namen des Objekts unterstreichen, unterstreichen Sie auch den Namen der Verknüpfung, wie Abbildung 4.8 zeigt. spielt in john doe : Spieler

tyrannosaurs : Mannschaft

Multiplizität

4.2

Multiplizität

Die bisher zwischen Spieler und Mannschaft hergestellte Verbindung suggeriert, dass sich die beiden Klassen in einer eins-zu-eins-Beziehung befinden. Doch unser Verstand sagt uns, dass dies nicht der Fall ist. Eine Basketballmannschaft hat fünf Spieler (Reservespieler nicht mitgerechnet). Die hatAssoziation muss dies berücksichtigen. Umgekehrt kann ein Spieler immer nur für eine Mannschaft spielen und auf dies muss die spielt-für-Assoziation wiederum Rücksicht nehmen. Diese Spezifikationen sind Beispiele für Multiplizität, d.h. die Anzahl der Objekte einer Klasse, die mit einem Einzelobjekt einer assoziierten Klasse zusammenhängen. Um diese Anzahlen in einem Diagramm darzustellen, schreibt man sie wie in Abbildung 4.9 neben die entsprechende Klasse über die Assoziationslinie. Spieler

5

spielt in

1

Mannschaft

Die in diesem Beispiel dargestellte ist nicht die einzige Art von Multiplizität. Es sind durchaus mehrere Multiplizitäten möglich (sozusagen multiple Multiplizitäten). Eine Klasse kann mit einer anderen in den folgenden Weisen zusammenhängen: eins-zu-eins, eins-zu-viele, eins-zu-begrenztes Intervall (z.B. eins-zu-fünf bis zehn), eins-zu-genau n (wie im vorliegenden Beispiel) oder eins-zu-mehrere Auswahlmöglichkeiten (z.B. eins-zu-neun oder zehn). Die UML verwendet ein Sternchen (*), um die Begriffe mehr und viele darzustellen. In einem Kontext wird »Oder«durch zwei Punkte repräsentiert, wie in »1..*« (»eins Oder mehr«) und in einem anderen Kontext durch ein Komma, wie in »5,10« (»5 oder 10«). Abbildung 4.10 zeigt, wie die möglichen Multiplizitäten visualisiert werden.

NEUERF BEGRIF

Abb. 4.9: Die Multiplizität gibt an, wie viele Objekte einer Klasse mit einem Einzelobjekt einer assoziierten Klasse zusammenhängen können.

Ist die Klasse A in einer eins-zu-null- oder eins-Multiplizität mit Klasse B, so sagt man, dass Klasse B für Klasse A optional ist.

75

Stunde

Abb. 4.10: Mögliche Multiplizitäten und ihre Darstellung in der UML.

Beziehungen spielen lassen

4 Ehemann 1

Lehrer

1

hat

Vollzeitstudent

Eierkarton 1

4.3

1

nimmt

Kunde eins - zu - eins oder mehr

Kamin eins - zu - null oder eins

Semesterwochenstunden

hat

enthält

eins - zu - mehr

0,1

12..18

3

6, 12

eins - zu - eins

Schüler

1..*

bedient

1

Dreirad 1

*

unterrichtet

Bankkassierer 1

Haus

1 Ehefrau

ist verheiratet mit

eins - zu - 12 bis 18

Rad eins - zu - drei

Ei eins - zu - 6 oder 12

Qualifizierte Assoziationen

Wenn eine Assoziation eine eins-zu-viele-Multiplizität aufweist, so ist dies oft mit einer speziellen Herausforderung verbunden: dem Nachschlagen (engl. lookup). Muss ein Objekt einer Klasse, um seine Rolle in einer Assoziation auszufüllen, ein bestimmtes Objekt einer anderen Klasse herausgreifen, so muss sich die erste Klasse eines bestimmten Attributs bedienen, um das richtige Objekt zu finden. Dieses Attribut ist in der Regel ein Bezeichner, z.B. eine Identifikationsnummer. Wenn Sie z.B. ein Hotelzimmer reservieren, erhalten Sie vom Hotel eine Reservierungsnummer. Wenn Sie nun anrufen, weil Sie Rückfragen zur Reservierung haben, müssen Sie diese Reservierungsnummer nennen.

76

Vererbung und Generalisierung

In der UML nennt man die Identifikationsdaten eine Qualifizierung. Ihr Symbol ist ein kleines Rechteck an der nachschlagenden Klasse. Wie dies dargestellt wird, zeigt Abbildung 4.11. Der Grundgedanke ist, eine eins-zuviele-Multiplizität wirksam auf eine eins-zu-eins-Multiplizität zurechtzustutzen. Angestellter Reservierungsnummer

4.4

1

findet

*

Reservierung

Reflexive Assoziationen

NEUERF BEGRIF

Abb. 4.11: Die Qualifizierung in einer Assoziation löst das Problem des Nachschlagens.

Manchmal ist eine Klasse auch mit sich selbst assoziiert. Dies kann z.B. der Fall sein, wenn eine Klasse Objekte hat, die mehrere Rollen spielen können. Ein FahrzeugInsasse kann entweder ein Fahrer oder ein Beifahrer sein. In der Rolle eines Fahrers fährt ein FahrzeugInsasse null oder mehr FahrzeugInsassen, die die Rolle von Beifahrern spielen. Dies stellen Sie dar, indem Sie eine Assoziationslinie von dem Klassenrechteck zu demselben Klassenrechteck zurück zeichnen und an dieser Linie wie schon bisher den Namen, die Richtung und die Multiplizität der Assoziation notieren. Abbildung 4.12 zeigt dieses Beispiel. Abb. 4.12: Bei einer reflexiven Asso1 fahrer ziation ziehen Sie die Linie fährt 0..4 beifahrer von der Klasse aus zu dieser zurück. Sie können die Rollen sowie den Namen, die Richtung und Eine der Stärken der Objektorientierung ist, dass sie einen wichtigen Aspekt die Multiplizität unseres Alltagswissens aufgreift: Wenn Sie über eine Kategorie von Dingen der Assoziation etwas wissen, so wissen Sie damit automatisch auch etwas, was sich auf an- angeben. Fahrzeuginsasse

4.5

Vererbung und Generalisierung

dere Kategorien übertragen lässt. Wenn Sie wissen, dass etwas ein Haushaltsgerät ist, wissen Sie auch bereits, dass es über einen Ein-/Aus-Schalter,

77

Stunde

4

Beziehungen spielen lassen

eine Herstellerbezeichnung und eine Seriennummer verfügt. Wenn Sie wissen, dass etwas ein Tier ist, dann können Sie voraussetzen, dass es isst, schläft, auf irgendeine Art und Weise geboren wird und sich von der Stelle bewegen kann. Wahrscheinlich könnten Sie noch einige weitere Attribute (und Operationen) aufzählen, wenn Sie ein paar Minuten darüber nachdenken. NEUERF BEGRIF

Die Objektorientierung bezeichnet dies als Vererbung; die UML auch als Generalisierung. Eine Klasse (die Kindklasse oder Unterklasse) kann Attribute und Operationen einer anderen (der Elternklasse oder Oberklasse) erben. Die Oberklasse ist allgemein gültiger als die Unterklasse. In einer Generalisierung kann man das Elternelement durch das Kindelement ersetzen. Also kann überall, wo das Elternelement auftaucht, auch das Kindelement auftauchen. Umgekehrt gilt dies jedoch nicht. Die Vererbungshierarchie muss allerdings nicht bei zwei Ebenen stehen bleiben: Eine Unterklasse kann Oberklasse einer weiteren Unterklasse sein. Säugetier ist eine Unterklasse von Tier und Pferd ist eine Unterklasse von Säugetier. In der UML lässt sich Vererbung durch eine Linie darstellen, die die Oberklasse mit der Unterklasse verbindet. An dem Ende der Linie, das an die Oberklasse angrenzt, zeichnen Sie ein unausgefülltes Dreieck, das auf die Oberklasse zeigt. Dieser Verbindungstypus steht für die Phrase ist eine Art von. Ein Säugetier ist eine Art von Tier und ein Pferd ist eine Art von Säugetier. Abbildung 4.13 zeigt diese spezielle Vererbungshierarchie mit einigen zusätzlichen Klassen. Beachten Sie, wo in dieser Abbildung das Dreieck auftaucht und wie die Linien aussehen, wenn mehr als eine Unterklasse von einer Oberklasse erbt. Ein so gestaltetes Diagramm ist nicht so unruhig wie eines, das sämtliche Linien und Dreiecke zeigt. Die UML verbietet es jedoch nicht, diese alle abzubilden. Achten Sie auch darauf, nicht die geerbten Attribute und Operationen in die Unterklassen-Rechtecke zu schreiben, denn diese haben Sie bereits in den Oberklassen dargestellt.

78

Vererbung und Generalisierung

Abb. 4.13: Vererbungshierarchie in der Tierwelt.

Tier

Amphibie

Säugetier

Reptil

Pferd

Wenn Sie Vererbung modellieren, müssen Sie sicherstellen, dass die Unterklasse die eine Art von-Beziehung zur Oberklasse auch wirklich erfüllt. Ist dies nicht die Beziehung zwischen den beiden Klassen, so wäre eventuell eine andere Art von Assoziation besser geeignet. Oft fügen Unterklassen ihren ererbten Attributen und Operationen etwas hinzu. Ein Säugetier z.B. hat Haare und gibt Milch, zwei Attribute, die die Tier-Klasse nicht aufweist. Wenn eine Klasse keine Oberklasse hat, ist sie eine Basisklasse oder Wurzelklasse. Wenn sie keine Unterklassen hat, ist sie eine Blattklasse. Hat sie genau eine Oberklasse, handelt es sich um Einfachvererbung, hat sie mehr als eine Oberklasse, um Mehrfachvererbung.

4.5.1

NEUERF BEGRIF

Vererbung entdecken

Im Kundengespräch stößt ein Analytiker in unterschiedlicher Weise auf Vererbung. Es ist möglich, dass sich Klassenkandidaten ergeben, die sowohl Ober- als auch Unterklassen umfassen. Der Analytiker muss merken, dass die Attribute und Operationen einer Klasse allgemeingültig sind und möglicherweise für mehrere andere Klassen gelten, die ihrerseits eigene Attribute und Operationen hinzufügen können.

79

Stunde

4

Beziehungen spielen lassen

In dem Basketballbeispiel aus der dritten Stunde »Objektorientiert arbeiten« gibt es Spieler-, Verteidiger-, Angreifer- und Center-Klassen. Der Spieler hat Attribute wie z.B. größe, gewicht, laufTempo und sprungHöhe. Er hat Operationen wie dribbeln(), passen(), rebound() und werfen(). Verteidiger, Angreifer und Center erben diese Attribute und Operationen und fügen eigene hinzu. Der Verteidiger könnte die Operationen angriffStoppen() und ballNachVornSpielen() haben. Der Center könnte die Operation dunking() haben. Auf Grund der Angaben des Trainers über die relative Körpergröße der Spieler könnte der Analytiker die Größenattribute der jeweiligen Spielpositionen mit Einschränkungen belegen. Eine weitere Möglichkeit ist, dass der Analytiker feststellt, dass zwei oder mehr Klassen einige gemeinsame Attribute und Operationen haben. Das Basketballmodell hat eine SpielUhr (die festhält, wie viel von der laufenden Spielzeit noch übrig ist) und eine WurfUhr (die die Zeit zwischen dem Moment, wo eine Mannschaft in den Ballbesitz kommt und dem Zeitpunkt, bis zu dem sie auf den Korb geworfen haben muss, misst). Wenn der Analytiker feststellt, dass beide Uhren eine Zeitspanne messen, könnte er eine UhrKlasse mit einer Operation zeitMessen() formulieren, die die beiden Klassen SpielUhr und WurfUhr erben. Da die WurfUhr 24 Sekunden (Profis) oder 35 Sekunden (Amateure) und die SpielUhr 12 Minuten (Profis) oder 20 Minuten (Amateure) misst, ist zeitMessen() polymorph.

4.5.2

Abstrakte Klassen

Um das Modell zu entwickeln benötigen Sie Objekte der Klassen Verteidiger, Angreifer, Center, SpielUhr und WurfUhr. Die Klassen Spieler und Uhr werden jedoch keine Objekte zum Modell beisteuern. Ein Objekt der Klasse Spieler hätte ebenso wenig Zweck wie eines der Klasse Uhr. NEUERF BEGRIF

80

Klassen wie Spieler und Uhr, die keine Objekte haben, nennt man abstrakt. Eine abstrakte Klasse zeigen Sie an, indem Sie ihren Namen kursiv schreiben. Abbildung 4.14 zeigt die beiden abstrakten Klassen und ihre Kinder.

Abhängigkeiten

Abb. 4.14: Zwei Vererbungshierarchien mit abstrakten Klassen in dem Basketballmodell.

Spieler name höhe gewicht laufTempo sprungHöhe ballDribbeln() ballPassen() reboundHolen() werfen()

Verteidiger

Angreifer

Center

angriff() ballNachVornSpielen()

dunking()

Uhr zeitMessen()

SpielUhr

4.6

WurfUhr

Abhängigkeiten

In einer anderen Art von Beziehung nutzt eine Klasse eine andere. Dies nennt man eine Abhängigkeit (dependency). Am häufigsten verwendet man eine Abhängigkeit, um anzuzeigen, dass für die Signatur der Operation einer Klasse eine andere Klasse genutzt wird.

NEUERF BEGRIF

Angenommen, Sie entwerfen ein System, das Geschäftsformulare als Bildschirmmasken darstellt, damit die Angestellten sie ausfüllen können. Der Angestellte wählt die auszufüllende Maske in einem Menü aus. In unserem Entwurf gibt es eine System-Klasse und eine Maske-Klasse. Unter den vielen Operationen der System-Klasse gibt es auch maskeZeigen(m:Maske). Welche Maske das System anzeigt, hängt natürlich davon ab, welche der Benutzer auswählt. Die UML-Notation dafür ist eine gestrichelte Linie mit einem Pfeil, der wie in Abbildung 4.15 auf die Klasse zeigt, von der Abhängigkeit besteht.

81

Stunde

Abb. 4.15: Eine gestrichelte Linie mit Pfeil stellt eine Abhängigkeit dar.

4

Beziehungen spielen lassen

System zeigeMaske()

4.7

Maske

Zusammenfassung

Ohne Beziehungen wäre ein Klassenmodell kaum mehr als eine bloße Auflistung von Rechtecken, die ein Vokabular darstellen. Beziehungen zeigen, wie die einzelnen Begriffe im Vokabular miteinander zusammenhängen, damit man ein Bild von dem zu modellierenden Ausschnitt der Welt erhält. Die Assoziation ist die wichtigste konzeptuelle Verbindung zwischen Klassen. Jede Klasse in einer Assoziation spielt eine Rolle und die Multiplizität gibt an, wie viele Objekte der einen Klasse mit einem Objekt der anderen Klasse zusammenhängen. Viele Multiplizitätstypen sind möglich. Eine Assoziation wird dargestellt durch eine Linie zwischen den Klassenrechtecken mit Rollen und Multiplizitäten an jedem Ende. Wie eine Klasse, so kann auch eine Assoziation Attribute und Operationen haben. Eine Klasse kann von einer anderen Klasse Attribute und Operationen erben. Die erbende Klasse ist die Unterklasse der Oberklasse, von der sie erbt. Sie erkennen Vererbung, wenn Sie in Ihrem Ausgangsmodell Klassen mit gemeinsamen Attributen und Operationen entdecken. Abstrakte Klassen sind nur als Basis für Vererbung gedacht und stellen selbst keine Objekte zur Verfügung. Vererbung wird durch eine Linie zwischen Ober- und Unterklasse mit einem auf die Oberklasse zeigenden und an diese grenzenden, unausgefüllten Dreieck dargestellt. Bei einer Abhängigkeit wird eine Klasse von einer anderen genutzt. Am häufigsten verwendet man eine Abhängigkeit, um zu zeigen, dass die Signatur einer Operationen der einen Klasse eine andere Klasse nutzt. Eine Abhängigkeit zeichnet man als gestrichelte Verbindungslinie zwischen den beiden betroffenen Klassen mit einer Pfeilspitze, die an die Klasse grenzt (und auf sie zeigt), von der die Abhängigkeit besteht.

4.8

Fragen und Antworten

F: Gibt man für eine Vererbungsbeziehung eigentlich jemals einen Namen an, wie für eine Assoziation? A: Die UML hindert Sie zwar nicht daran, eine Vererbungsbeziehung zu benennen, aber nötig ist das normalerweise nicht.

82

Workshop

4.9

Workshop

Die Fragen und Übungen wurden entwickelt, um Ihr UML-Wissen auf dem Gebiet der Beziehungen zu festigen. Bei jeder Frage und Übung müssen Sie über die soeben gelernten Modellierungssymbole nachdenken und sie auf einen Fall anwenden. Die Antworten finden Sie in Anhang A unter »Antworten«.

4.9.1

Fragen

1. Wie stellt man Multiplizität dar? 2. Wie entdeckt man Vererbung? 3. Was ist eine abstrakte Klasse? 4. Wie wirkt sich eine Qualifizierung aus?

4.9.2

Übungen

1. Nehmen Sie das anfängliche Basketballmodell aus Stunde 3 und versehen Sie es mit Verknüpfungen, die die in dieser Stunde behandelten Beziehungen ausdrücken. Wenn Sie Basketball kennen, stellen Sie ihr Wissen ruhig durch weitere Verknüpfungen dar. 2. Eine alte Spruchweisheit sagt: »Ein Anwalt, der sich selbst verteidigt, hat einen Idioten als Mandant.« Erstellen Sie ein Modell, das sie wiedergibt.

83

Stunde 5

Aggregationen, Komposita, Schnittstellen und Realisierungen verstehen 5

Aggregationen, Komposita, Schnittstellen und Realisierungen verstehen

In dieser Stunde erfahren Sie mehr über Beziehungen zwischen Klassen und lernen neue Konzepte über Klassen und Diagramme. Folgende Themen werden behandelt:

✘ Aggregationen ✘ Komposita ✘ Kontexte ✘ Schnittstellen ✘ Realisierungen ✘ Sichtbarkeit Über Assoziationen, Multiplizitäten und Vererbung wissen Sie bereits Bescheid. Sie sind schon fast in der Lage, aussagekräftige Diagramme zu zeichnen. In dieser Stunde lernen Sie die letzten Teile des Puzzles kennen, indem Sie sich in weitere Beziehungstypen und noch andere klassenbezogene Themen vertiefen. Ziel ist dabei die Fähigkeit, eine statische Sicht eines Systems vollständig mit allen Verbindungen zwischen den Klassen des Systems erstellen zu können. TIPP

NEUERF BEGRIF

85

Stunde

5.1 NEUERF BEGRIF

Aggregationen, Komposita, Schnittstellen, Realisierungen

5

Aggregationen

Manchmal hat eine Klasse mehrere andere Klassen als Bestandteile. Diesen speziellen Beziehungstyp nennt man Aggregation. Die Komponenten und die Klasse, die sie bilden, stehen in einer Teil-Ganzes-Beziehung. In der zweiten Stunde, »Objektorientierung verstehen«, erwähnte ich bereits, dass ein Computersystem eine Aggregation ist, die aus einem Tower, einer Tastatur, einer Maus, einem Monitor, einem CD-ROM-Laufwerk, einer oder mehr Festplatten, einem Modem, einem Diskettenlaufwerk, einem Drucker und eventuell noch einem Paar Lautsprecher besteht. Im Tower sind neben dem Prozessor und den Laufwerken noch ein Arbeitsspeicher, eine Grafikund eine Soundkarte (und wahrscheinlich noch andere Sachen) untergebracht. Eine Aggregation stellen Sie als Hierarchie dar, indem Sie die »Ganzes«Klasse (z.B. das Computersystem) oben und die Bestandteile darunter zeichnen. Das Ganze wird mit einem Teil durch eine Linie mit einer unausgefüllten Raute auf der Seite des Ganzen verbunden. Abbildung 5.1 zeigt das Computersystem als Aggregation. Computer 1

2 2

1 Tower

Lautsprecher

1 Tastatur

1 Monitor

1 Maus

1

1

1 DiskettenLaufwerk

1..* FestPlatte

* ArbeitsSpeicher

1 CD-ROM

1 GrafikKarte

1 SoundKarte

1..3 MausTaste

1 MausKugel

1 ist verbunden mit

Abb. 5.1: Eine Aggregations- (Teil-Ganzes-) Beziehung stellt man durch eine Linie zwischen dem Teil und dem Ganzen dar, die auf der Seite des Ganzen eine unausgefüllte Raute aufweist.

Zwar zeigt dieses Beispiel jedes Teil als zu dem Ganzen gehörig, doch muss dies bei einer Aggregation nicht unbedingt so sein. So könnte z.B. bei einer Unterhaltungselektronik-Anlage eine Fernbedienung Teil des Fernsehers, aber auch Teil des Videorekorders sein.

86

Kontexte

5.1.1

Einschränkungen für Aggregationen

Manchmal gilt für eine Menge möglicher Bestandteile eine Oder-Beziehung. In manchen Restaurants besteht eine Mahlzeit aus Suppe oder Salat, einem Hauptgericht und einem Dessert. Um dies zu modellieren, würden Sie eine Einschränkung verwenden: das Wort Oder in geschweiften Klammern auf einer gestrichelten Linie, die, wie in Abbildung 5.2 gezeigt, die beiden TeilGanzes-Linien verbindet.

Mahlzeit

1 1

{oder}

Suppe

5.2

1

1

Salat

1

HauptGericht

Dessert

Komposita

Abb. 5.2: Sie können eine Aggregation mit einer Einschränkung versehen, die zeigt, dass entweder der eine oder der andere Bestandteil Teil des Ganzen ist.

Ein Kompositum ist eine strenge Form der Aggregation. Jeder Bestandteil eines Kompositums kann nur zu genau einem einzigen Ganzen gehören. Die Bestandteile eines Kaffeetischs – Tischplatte und Tischbeine – bilden ein Kompositum. Das Symbol für ein Kompositum ist dasselbe wie für eine Aggregation, nur ist hier die Raute ausgefüllt (siehe Abbildung 5.3).

KaffeeTisch

1 1 TischPlatte

5.3

4 TischBein

Kontexte

Abb. 5.3: In einem Kompositum gehört jeder Bestandteil zu genau einem einzigen Ganzen. Auf diese Beziehung weist eine ausgefüllte Raute hin.

Beim Modellieren eines Systems treten Gruppen von Klassen – oft als Aggregationen oder Komposita – auf. Wenn sie Ihre Aufmerksamkeit auf die eine oder andere dieser Gruppen konzentrieren müssen, steht in Form des Kontextdiagramms das Modellierungsmittel zur Verfügung, das dies für Sie

87

Stunde

Aggregationen, Komposita, Schnittstellen, Realisierungen

5

erledigt. Komposita spielen in Kontextdiagrammen eine wichtige Rolle. Ein Kontextdiagramm ist wie ein Detailausschnitt einer größeren Landkarte. Unter Umständen sind mehrere Ausschnitte notwendig, um alle Einzelheiten der Daten aufzunehmen. Ein Beispiel: Angenommen, Sie erstellen ein Modell eines Hemds in der Art und Weise, wie dieses zum Outfit und in den Kleiderschrank passt. Ein bestimmter Typ des Kontextdiagramms (siehe Abbildung 5.4) zeigt das Hemd als großes Klassenrechteck, das ein Diagramm birgt. Das eingebettete Diagramm zeigt, wie die Bestandteile eines Hemds miteinander zusammenhängen. Dies ist ein Kompositions-Kontextdiagramm: Komposition deswegen, weil dem Hemd jeder einzelne Bestandteil »gehört«. Abb. 5.4: Ein Kompositions-Kontextdiagramm zeigt die Bestandteile einer Klasse als in ein großes Klassenrechteck eingebettetes Diagramm.

Hemd Ärmel

2 angenäht an

1

Rumpf

1

angenäht an 1

1

Kragen

1 1 angenäht an

angenäht an

1

5,6

angenäht an

0,2,3

Knöpfung

1 1 Knopf

1 KnopfLoch 1

hinein in das

1

Das Kompositions-Kontextdiagramm zieht die Aufmerksamkeit auf das Hemd und seine inhärenten Bestandteile. Um das Hemd im Kontext des Kleiderschranks und des Outfits zu zeigen, müssen Sie Ihren Blickwinkel erweitern. Dabei hilft Ihnen ein System-Kontextdiagramm. Wie in Abbildung 5.5 können Sie zeigen, wie die Hemd-Klasse mit den Klassen Kleiderschrank und Outfit zusammenhängt. Danach können Sie auch von anderen Klassen eine Detailaufnahme machen und die Einzelheiten in einem Kontextdiagramm darstellen.

88

Schnittstellen und Realisierungen

KleiderSchrank

1

*

* FreizeitKleidung

Hemd Ärmel

2 angenäht an

1

Rumpf

1

angenäht an 1

1

Kragen

1 1 angenäht an

angenäht an

1

1

5,6

angenäht an

0,2,3

Knöpfung

1 1 Knopf

Abb. 5.5: Ein SystemKontextdiagramm zeigt, die Bestandteile einer Klasse und wie diese Klasse mit anderen Klassen des betreffenden Systems zusammenhängt.

1 KnopfLoch 1

hinein in das

1

1 1

Outfit

5.4

Schnittstellen und Realisierungen

Nachdem Sie einige Klassen erzeugt haben, stellen Sie vielleicht fest, dass diese zwar nicht mit einer speziellen Oberklasse verwandt sind, aber ihre Verhaltensweisen zum Teil dieselben Operationen mit denselben Signaturen aufweisen. Sie können diese Operationen für eine der Klassen kodieren und sie in den anderen Klassen wiederverwenden. Eine andere Möglichkeit besteht darin, in einem System eine Menge von Klassenoperationen zu entwickeln und sie in den Klassen eines anderen Systems wiederzuverwenden. In beiden Fällen müssen Sie die Menge der wiederverwendbaren Operationen in irgendeiner Weise festhalten. Das UML-Konstrukt, das dies möglich macht, ist die Schnittstelle (interface). Eine Schnittstelle ist eine Operationsmenge, die einen Aspekt im Verhalten einer Klasse spezifiziert und zugleich eine Operationsmenge, die die betreffende Klasse anderen Klassen gegenüber präsentiert.

NEUERF BEGRIF

89

Stunde

5

Aggregationen, Komposita, Schnittstellen, Realisierungen

Ein Beispiel wird dabei helfen, das Schnittstellen-Konzept zu erklären. Die Tastatur, die Sie für die Kommunikation mit dem Computer einsetzen, ist eine wiederverwendbare Schnittstelle. Ihre Tastendruck-Operationen wurden von der Schreibmaschine übernommen. Die Anordnung der Tastatur ist dieselbe wie bei einer Schreibmaschine, doch der wesentliche Punkt ist, dass die Tastendruck-Operation von einem System auf ein anderes übertragen worden ist. Andere Operationen – Umschalttaste, Feststelltaste und Tabulator – wurden ebenfalls von der Schreibmaschine übernommen. Natürlich bietet die Computertastatur auch einige Operationen, die eine Schreibmaschine nicht zu bieten hat: Strg, Alt, Bild auf, Bild ab etc. Folglich kann die Schnittstelle auch eine Teilmenge der Klassenoperationen spezifizieren und nicht unbedingt alle. Eine Schnittstelle modellieren Sie ebenso wie eine Klasse mit einem rechteckigen Symbol. Der Unterschied besteht darin, dass die Schnittstelle – eine Operationsmenge – keine Attribute hat. Sie werden sich erinnern, dass man die Attribute bei der Klassendarstellung auslassen kann. Wie also unterscheidet man zwischen einer Schnittstelle und einer Klasse, die lediglich ihre Attribute nicht zeigt? Eine Möglichkeit ist, das Stereotyp-Konstrukt einzusetzen und «interface» über den Namen der Schnittstelle im Rechteck zu schreiben. Eine andere Möglichkeit ist, den Namen jeder Schnittstelle mit »I« für »Interface« beginnen zu lassen. NEUERF BEGRIF

Es ist gewissermaßen so, als garantierte die Computertastatur dafür, dass ein Teil ihres Verhaltens das Verhalten einer Schreibmaschine »realisiert«. Dem entsprechend nennt man die Beziehung zwischen einer Klasse und einer Schnittstelle Realisierung. Diese Beziehung modelliert man in Form einer gestrichelten Linie mit einem großen, unausgefüllten Dreieck, das neben der Schnittstelle steht und auf diese zeigt. Abbildung 5.6 zeigt, wie man das macht. Tastatur herstellerName tastenAnzahl Ctrl() Alt() Bild () Bild () …

«interface» SchreibMaschine Tastendruck()

Abb. 5.6: Eine Schnittstelle ist eine Sammlung von Operationen, die eine Klasse ausführt. Eine Klasse hängt mit einer Schnittstelle per Realisierung zusammen. Dies zeigt eine gestrichelte Linie mit einem unausgefüllten, auf die Schnittstelle zeigenden Dreieck an.

90

Sichtbarkeit

Eine andere (verkürzte) Möglichkeit zur Darstellung einer Klasse und einer Schnittstelle besteht aus einem kleinen Kreis, der, wie in Abbildung 5.7 gezeigt, durch eine Linie mit der Klasse verbunden ist. Abb. 5.7: Verkürzte Darstellung einer Klasse, die eine SchnittEine Klasse kann mehr als eine Schnittstelle realisieren und eine Schnittstelle realistelle kann von mehr als einer Klasse realisiert werden. siert. Tastatur

5.5

Schreibmaschine

Sichtbarkeit

Das Konzept der Sichtbarkeit ist eng mit Schnittstellen und Realisierungen verbunden. Sichtbarkeit (visibility) betrifft Attribute oder Operationen und gibt an, bis zu welchem Grade andere Klassen die Attribute oder Operationen einer gegebenen Klasse (oder die Operationen einer Schnittstelle) nutzen können. Möglich sind drei Ebenen der Sichtbarkeit: Auf öffentlicher Ebene (public) erstreckt sich die Sichtbarkeit bis hin zu anderen Klassen. Auf der geschützten Ebene (protected) steht nur solchen Klassen, die von der Ursprungsklasse Erben, die Verwendung frei. Auf der privaten Ebene (private) darf nur die Ursprungsklasse das Attribut oder die Operation nutzen. Bei einem Fernseher sind lautstärkeRegeln() und programmWechseln() öffentliche Operationen, bildAufBildschirmDarstellen() hingegen eine private. Bei einem Auto sind gasGeben() und bremsen() öffentliche Operationen und kilometerZählerAktualisieren() ist geschützt.

NEUERF BEGRIF

Sie können sich vorstellen, dass eine Realisierung für jede Operation einer Schnittstelle öffentlichen Zugriff voraussetzt. Die Operationen mit einem der anderen Sichtbarkeitsgrade abzuschirmen wäre sinnlos, da eine Schnittstelle dazu da ist, von mehreren Klassen realisiert zu werden. Um öffentlichen Zugriff zu kennzeichnen, stellen Sie dem Attribut oder der Operation ein »+« voranstellen, bei geschütztem Zugriff ein »#« und bei privatem Zugriff ein »-«. Abbildung 5.8 zeigt die vorerwähnten öffentlichen, geschützten und privaten Operationen eines Fernsehers und eines Autos.

91

Stunde

Abb. 5.8: Öffentliche und private Operationen bei einem Fernseher sowie öffentliche und geschützte Operationen bei einem Auto.

NEUERF BEGRIF

5

Aggregationen, Komposita, Schnittstellen, Realisierungen

Fernseher

Automobil

+ herstellerName + modellBezeichnung …

+ fabrikat + modellBezeichnung …

+ lautstärkeRegeln() + programmWechseln() - bildAufBildschirmProjizieren() …

+ gasGeben() + bremsen() # kilometerZählerAktualisieren() …

5.6

Gültigkeitsbereich

Ein weiteres, für Attribute und Operationen und ihre Zusammenhänge in einem System relevantes Konzept ist der Gültigkeitsbereich (scope). Davon sind zwei Varianten möglich: Bezieht sich der Gültigkeitsbereich auf die jeweilige Instanz, besitzt jedes Objekt für das betreffende Attribut oder die Operation seinen eigenen Wert. Bezieht er sich auf die Klassifizierung (classifier), so existiert für alle Instanzen der Klasse nur ein einziger Wert des Attributs oder der Operation. Hat ein Attribut oder eine Operation die Klassifizierung als Gültigkeitsbereich, so erscheint es mit unterstrichenem Namen. Diesen Gültigkeitsbereich verwendet man in der Regel dann, wenn eine klar definierte Gruppe von Objekten (und sonst keines) die genauen Werte eines privaten Attributs teilen soll. Instanzweite Gültigkeit ist bei weitem der häufigere Gültigkeitsbereich.

5.7

Zusammenfassung

Um Ihr Wissen über Klassen und deren Zusammenhänge abzurunden müssen sie noch einige weitere Beziehungen verstehen. Eine Aggregation spezifiziert eine Teil-Ganzes-Assoziation: Eine »ganze« Klasse besteht wiederum aus Klassen. Ein Bestandteil einer Aggregation kann Teil von mehr als einem einzigen Ganzen sein. Ein Kompositum ist insofern eine starke Form der Aggregation, als ein Bestandteil eines Kompositums nur Teil eines einzigen Ganzen sein kann. Die UML stellt Aggregationen ganz ähnlich wie Komposita dar. Die Linie, die einen Teil mit dem Ganzen verbindet, endet in einer an das Ganze grenzenden Raute. Diese ist bei einer Aggregation unausgefüllt und bei einem Kompositum ausgefüllt. Ein Kontextdiagramm zieht die Aufmerksamkeit auf eine spezifische Klasse innerhalb des Systems. Ein Kompositions-Kontextdiagramm ist wie ein Detailausschnitt aus einer größeren Landkarte. Es zeigt ein in ein großes, rechteckiges Klassensymbol eingebettetes Klassendiagramm. Ein SystemKontextdiagramm zeigt, wie das Kompositions-Kontextdiagramm mit anderen Objekten im System zusammenhängt.

92

Fragen und Antworten

Eine Realisierung ist eine Assoziation zwischen einer Klasse und einer Schnittstelle, d.h. einer Sammlung von Operationen, die von vielen Klassen genutzt werden dürfen. Eine Schnittstelle wird als Klasse ohne Attribute dargestellt. Zur Unterscheidung von einer Klasse, deren Attribute fortgelassen wurden, erscheint der Stereotyp «interface» über dem Namen der Schnittstelle. Eine andere Möglichkeit wäre, den Namen der Schnittstelle mit einem großen »I« für »Interface« beginnen zu lassen. Realisierung stellt die UML mit einer gestrichelten Verbindungslinie zwischen Klasse und Schnittstelle dar, mit einem unausgefüllten Dreieck, das an die Schnittstelle grenzt und auf diese zeigt. Man kann eine Realisierung auch mit einer durchgezogenen Linie darstellen, die eine Klasse mit einem kleinen Kreis verbindet, der für die Schnittstelle steht. Hinsichtlich ihrer Sichtbarkeit sind alle Operationen in einer Schnittstelle öffentlich, damit sie von jeder Klasse genutzt werden können. Zwei andere Ebenen der Sichtbarkeit sind die geschützte (Zugriff für Unterklassen der Klasse, die die betreffenden Attribute und Operationen besitzt) und die private (Zugriff auf die Attribute und Operationen nur innerhalb der Klasse, die sie besitzt). Öffentliche Sichtbarkeit stellt man mit »+«, geschützte mit »#« und private mit »-« dar. Ein anderer Aspekt von Attributen und Operationen ist ihr Gültigkeitsbereich. Bei instanzweiter Gültigkeit hat jedes Objekt in einer Klasse für Attribut oder Operation seinen eigenen Wert. Bei klassifizierungsweiter Gültigkeit existiert in einer Menge von Objekten einer Klasse nur ein einziger Wert für ein bestimmtes Attribut oder eine Operation. Objekte, die nicht Elemente dieser Menge sind, haben keinen Zugriff auf den Wert mit klassifizierungsweiter Gültigkeit.

5.8

Fragen und Antworten

F: Betrachtet man eine Aggregation als transitiv? Anders gesagt, wenn Klasse 3 Bestandteil von Klasse 2 ist und Klasse 2 Bestandteil von Klasse 1, ist dann auch Klasse 3 Bestandteil von Klasse 1? A: Ja, die Aggregation ist transitiv. In unserem Beispiel sind die Maustasten und die Mauskugel Teil der Maus und auch Teil des Computersystems. F: Ist mit »Schnittstelle« auch die »Benutzerschnittstelle« oder GUI gemeint? A: Nein, der Ausdruck ist generischer. Eine Schnittstelle ist bloß eine Menge von Operationen, die eine Klasse anderen Klassen zeigt, von denen eine der Benutzer sein kann (aber nicht unbedingt sein muss).

93

Stunde

5 5.9

Aggregationen, Komposita, Schnittstellen, Realisierungen

Workshop

Die Fragen und Übungen werden Ihr Wissen über Aggregationen, Komposita, Kontexte und Schnittstellen festigen. Die Antworten finden Sie in Anhang A unter »Antworten«.

5.9.1

Fragen

1. Welcher Unterschied besteht zwischen einer Aggregation und einem Kompositum? 2. Was ist Realisierung? 3. Benennen Sie die drei Ebenen der Sichtbarkeit und beschreiben Sie die jeweilige Bedeutung.

5.9.2

Übungen

1. Erstellen Sie ein Kompositions-Kontextdiagramm einer Zeitschrift. Berücksichtigen Sie dabei Inhaltsverzeichnis, Editorial, Artikel und Kolumnen. Erstellen Sie dann ein System-Kontextdiagramm, das die Zeitschrift-Klasse zusammen mit den Klassen Abonnent und ZeitungsKäufer zeigt. 2. Die verbreitetste grafische Benutzeroberfläche (GUI) ist heutzutage die WIMP- (Windows, Icons, Menus, Pointer)-Schnittstelle. Zeichnen Sie ein Klassendiagramm der WIMP-Schnittstelle und verwenden Sie dafür, so weit geeignet, alles, was Sie bisher über die UML gelernt haben. Neben den Klassen, die bereits im Akronym benannt sind, sollten Sie verwandte Gegenstände wie Scrollbar und Cursor sowie andere erforderliche Klassen mit einbeziehen.

94

Stunde 6

Einführung in Anwendungsfälle 6

Einführung in Anwendungsfälle

Nachdem Sie nun Klassen und Beziehungen kennen gelernt haben, ist es an der Zeit, unsere Aufmerksamkeit auf ein anderes großes Gebiet der UML zu richten: auf Anwendungsfälle. In dieser Stunde werden folgende Themen behandelt:

✘ Was Anwendungsfälle sind ✘ Wie man Anwendungsfälle erstellt ✘ Enthält-Beziehung von Anwendungsfällen ✘ Erweitern von Anwendungsfällen ✘ Beginn einer Anwendungsfallanalyse In den letzten drei Stunden hatten wir mit Diagrammen zu tun, die eine statische Sicht auf die Klassen in einem System bieten. Nun kommen wir endlich zu Diagrammen, die eine dynamische Sicht ermöglichen und zeigen, wie sich das System und seine Klassen mit der Zeit verändern. Die statische Sicht hilft einem Analytiker bei der Kommunikation mit dem Kunden. Die dynamische Sicht hilft ihm, wie Sie noch sehen werden, bei der Kommunikation mit einem Entwicklungsteam und unterstützt die Entwickler beim Schreiben der Programme. Der Kunde und das Entwicklungsteam bilden zusammen eine sehr wichtige Gruppe von Beteiligten an einem System. Doch ein ebenso wichtiger Teil des Bildes fehlt noch: der Anwender. Weder die statische noch die dynamische Sicht zeigt das Systemverhalten aus der Anwenderperspektive. Diese Perspektive zu verstehen ist jedoch der Schlüssel zur Erstellung von Syste-

TIPP

NEUERF BEGRIF

95

Stunde

6

Einführung in Anwendungsfälle

men, die sowohl nutzbringend als auch nutzbar sind, d.h., die nicht nur die Anforderungen erfüllen, sondern sich auch leicht (und mit Spaß) bedienen lassen. Ein System aus der Anwenderperspektive zu modellieren ist Aufgabe des Anwendungsfalls. In dieser Stunde werden Sie alles darüber erfahren, was Anwendungsfälle sind und wozu sie dienen. In der nächsten Stunde lernen Sie, wie Sie das UML-Anwendungsfalldiagramm einsetzen, um einen Anwendungsfall zu veranschaulichen.

6.1

Anwendungsfälle: was sie sind

Kürzlich habe ich mich dazu durchgerungen, ein neues Faxgerät zu kaufen. Als ich im Bürofachhandel danach suchte, fand ich eine große Auswahl an Geräten. Wie traf ich meine Kaufentscheidung? Ich fragte mich, wofür ich das Faxgerät eigentlich genau brauchte. Welche Eigenschaften benötigte ich? Welche Funktionen waren absolut unerlässlich? Wollte ich Normaloder Thermopapier verwenden? Muss ich Kopien damit machen? Eine Verbindung zum Computer herstellen? Das Fax als Scanner nutzen? Muss ich Faxe so schnell versenden, dass ich eine Schnellwahlfunktion brauche? Möchte ich mit dem Gerät den Unterschied feststellen können, ob gerade ein Anruf oder ein Fax eingeht? Wenn wir nicht gerade einen Spontankauf machen, durchlaufen wir alle einen solchen Prozess. Was wir dabei tun, ist eine Art von Anwendungsfallanalyse: Wir fragen uns, wie wir das Produkt oder System, für das wir teures Geld bezahlen, nutzen werden. So können wir uns für etwas entscheiden, das unsere Anforderungen erfüllt. Wichtig dabei ist zu wissen, was diese Anforderungen sind. Diese Art von Prozess ist besonders wichtig für die Analysephase der Systementwicklung. Die Art, wie Anwender das System nutzen, entscheidet über die Art, wie Sie das System entwerfen und aufbauen. Der Anwendungsfall ist ein Konstrukt, das dem Analytiker hilft, in Zusammenarbeit mit den Anwendern den Einsatz des Systems zu bestimmen. Eine Sammlung von Anwendungsfällen stellt das System hinsichtlich seines vom Anwender beabsichtigten Nutzens dar. NEUERF BEGRIF

96

Anwendungsfälle kann man sich als eine Sammlung von Szenarios über den Systemeinsatz vorstellen. Jedes Szenario beschreibt eine Sequenz von Schritten. Jede dieser Sequenzen wird von einem Menschen, einem anderen System, einem Teil der Hardware oder durch Zeitablauf in Gang gesetzt.

Beispiel: Getränkeautomat

Entitäten, die solche Sequenzen anstoßen, nennt man Akteure. Das Ergebnis der Sequenz muss etwas sein, was entweder dem Akteur, der sie initiierte oder einem anderen Akteur nutzt.

6.2

Anwendungsfälle: warum sie wichtig sind

So, wie man einen Kunden mit dem Klassendiagramm wunderbar anregen kann, das System aus seiner Sicht zu schildern, ist der Anwendungsfall ein hervorragendes Mittel, um potenzielle Anwender anzuregen, aus ihrer jeweils eigenen Sicht über ein System zu reden. Für Anwender ist es nicht immer leicht, auszudrücken, wie sie ein System einsetzen möchten. Da Systementwicklung traditionell oft ein willkürlicher Prozess war, dem die vorherige Analyse abging, staunen Anwender manchmal, wenn jemand sie nach ihrer Meinung fragt. Der Grundgedanke dabei ist, die Anwender bereits in der Frühphase von Systementwicklung und -entwurf einzubeziehen. Dadurch steigt die Wahrscheinlichkeit, dass das System letztlich für die Leute, denen es helfen soll, tatsächlich ein Segen wird und kein Monument für pfiffige, elegante Programmierkonzepte, die für die Anwender im Büro unverständlich und unbenutzbar sind.

6.3

Beispiel: Getränkeautomat

Angenommen, Sie möchten einen Getränkeautomaten entwerfen. Um die Perspektive der Benutzer zu erhalten, befragen Sie einige potenzielle Benutzer, wie sie mit dem Automaten umgehen würden. Da die Hauptfunktion eines Getränkeautomats darin besteht, dass sich der Kunde ein Getränk ziehen kann, werden Ihnen die Benutzer wahrscheinlich rasch sagen, dass Sie es mit einer Menge von Szenarios – mit anderen Worten einem Anwendungsfall – zu tun haben, den man mit »Getränk ziehen« überschreiben kann. Wir wollen jedes mögliche Szenario in diesem Anwendungsfall untersuchen. Bedenken Sie, dass diese Szenarios durch Gespräche mit den Benutzern zu Tage treten würden.

97

Stunde

Abb. 6.1: Ein Anwendungsfall spezifiziert eine Menge von Szenarios mit dem Ziel, etwas Nützliches für einen Akteur zu erreichen. In diesem Beispiel ist ein Anwendungsfall »Getränk ziehen«.

6

6.3.1

Einführung in Anwendungsfälle

Der Anwendungsfall »Getränk ziehen«

Der Akteur ist in diesem Anwendungsfall ein Kunde, der ein Getränk kaufen möchte. Er setzt das Szenario in Gang, indem er in den Automaten Geld einwirft. Dann wählt er ein Getränk. Wenn alles gut geht, hat der Automat mindestens eine Dose des gewählten Getränks auf Lager und gibt dem Kunden dieses in gekühlter Form aus. Zusätzlich zu dieser Folge von Schritten verdienen noch andere Aspekte des Szenarios Berücksichtigung. Welche Vorbedingungen veranlassen den Kunden, dieses Szenario im Anwendungsfall »Getränk ziehen« anzustoßen? Natürlich zunächst einmal Durst. Welche nachträglichen Folgen ergeben sich als Konsequenz aus dem Ablauf des Szenarios? Natürlich die, dass der Kunde ein Getränk hat. Ist das beschriebene Szenario das einzig Mögliche für »Getränk ziehen«? Sofort fallen einem noch andere ein. Es ist möglich, dass der Automat das vom Kunden gewählte Getränk nicht mehr vorrätig hat. Es ist möglich, dass der Kunde das Geld für das Getränk nicht passend hat. Wie sollten Sie den Getränkeautomaten entwerfen, damit er mit diesen Szenarios umgehen kann? Wenden wir uns dem Ausverkauft-Szenario zu, einer anderen Sequenz von Schritten im Anwendungsfall »Getränk ziehen«. Stellen Sie sich dies wie einen Alternativpfad durch den Anwendungsfall vor. Der Kunde setzt den Anwendungsfall in Gang, indem er Geld in den Automaten wirft. Dann wählt er ein Getränk. Da der Automat nicht mindestens eine Dose des gewählten Getränks auf Lager hat, gibt er dem Kunden die Nachricht aus, dass dieses Getränk nicht mehr vorrätig ist. Idealerweise sollte die Nachricht den Kunden auffordern, eine andere Wahl zu treffen. Der Automat sollte dem Kunden auch die Gelegenheit bieten, sein Geld zurückzuerhalten. An

98

Beispiel: Getränkeautomat

diesem Punkt wählt der Kunde entweder ein anderes Getränk, das ihm der Automat liefert (wenn nicht auch dieses ausverkauft ist) oder er wählt die Möglichkeit, sein Geld zurückzuerhalten. Die Vorbedingung ist ein durstiger Kunde. Die Folge ist entweder ein geliefertes Getränk oder das zurückgegebene Geld. Natürlich ist auch ein weiteres Ausverkauft-Szenario möglich: Die Nachricht »Getränk nicht vorrätig« könnte erscheinen, sobald der Vorrat im Automaten erschöpft ist und so lange bleiben, bis er wieder aufgefüllt wurde. In diesem Fall wirft der Benutzer vielleicht gar nicht erst Geld ein. Eventuell bevorzugt der Kunde, für den Sie den Automaten entwerfen, das erste Szenario: Hat der Kunde bereits Geld eingeworfen, so ist er möglicherweise eher bereit, eine andere Wahl zu treffen, als sein Geld zurückzuverlangen. Schauen wir uns nun das kein-passendes-Geld-Szenario an. Wieder startet der Benutzer den Anwendungsfall in der üblichen Weise und wählt ein Getränk. Nehmen wir an, der Automat hat dieses Getränk vorrätig. Wenn er passendes Wechselgeld auf Lager hat, gibt er den Differenzbetrag zurück und liefert das Getränk. Hat der Automat kein Wechselgeld, gibt er das eingeworfene Geld zurück und zeigt dem Benutzer eine Nachricht mit der Aufforderung, passendes Geld einzuwerfen. Die Vorbedingung ist die übliche. Die Folge ist entweder ein Getränk plus Wechselgeld oder die Rückgabe des eingeworfenen Geldes. Eine andere Möglichkeit ist, dass, sobald die Wechselgeldreserve des Automaten erschöpft ist, eine Nachricht erscheint, die die potenziellen Kunden informiert, dass sie das Geld passend einwerfen müssen. Die Nachricht würde so lange zu sehen sein, bis die Geldreserve des Automaten wieder aufgefüllt worden ist.

6.3.2

Weitere Anwendungsfälle

Sie haben den Getränkeautomaten aus der Perspektive eines einzelnen Benutzers untersucht: des Kunden. Aber es kommen auch noch andere Benutzer ins Spiel. Ein Lieferant muss den Vorrat des Automaten wieder auffüllen und jemand (möglicherweise dieselbe Person) muss das Geld holen, das sich im Automaten angesammelt hat. Daraus entnehmen wir, dass wir noch mindestens zwei weitere Anwendungsfälle, »Auffüllen« und »Geld holen« erstellen müssen, dessen Einzelheiten sich aus Interviews mit den Lieferanten und Geldeinsammlern ergeben.

99

Stunde

6

Einführung in Anwendungsfälle

Betrachten Sie den Anwendungsfall »Auffüllen«. Der Lieferant initiiert diesen Anwendungsfall, weil eine Zeitspanne (z.B. zwei Wochen) abgelaufen ist. Der Vertreter des Lieferanten entsichert die Maschine (wahrscheinlich, indem er ein Schloss aufschließt, aber das gehört zur Implementierung), öffnet die Front des Automaten und lädt jeden Getränkeschacht bis obenhin voll. Darüber hinaus füllt er die Wechselgeldreserve auf. Dann schließt er die Front des Automaten und sichert sie erneut. Die Vorbedingung ist der Zeitablauf, die Folge, dass der Lieferant potenziell neue Verkäufe tätigen kann. Auch den Anwendungsfall »Geld holen« setzt der Einsammler in Gang, weil eine Zeitspanne vergangen ist. Er befolgt dieselbe Sequenz von Schritten wie beim »Auffüllen«, nämlich den Automaten zu entsichern und die Front zu öffnen. Dann nimmt er das Geld aus der Maschine und befolgt wieder die »Auffüllen«-Schritte, die Front des Geräts zu schließen und zu sichern. Die Vorbedingung ist der Zeitablauf und die Folge, dass der Einsammler das Geld in Händen hält. Beachten Sie, dass wir uns beim Ableiten eines Anwendungsfalls nicht darum kümmern, wie man ihn implementiert. In unserem Beispiel interessiert uns das Innenleben des Getränkeautomaten nicht. Uns ist egal, wie der Kühlmechanismus funktioniert oder wie der Automat sein Geld zählt. Wir versuchen lediglich zu verstehen, wie sich der Getränkeautomat jemandem darbietet, der ihn benutzen muss. Das Ziel ist, eine Sammlung von Anwendungsfällen abzuleiten, die wir letztlich denen, die den Getränkeautomaten entwerfen und denen, die ihn bauen, zeigen können. In dem Maße, wie unsere Anwendungsfälle die Wünsche von Kunden, Geldeinsammlern und Lieferanten widerspiegeln, ist das Ergebnis ein Gerät, das alle diese Gruppen leicht bedienen können.

6.4

Enthält-Beziehung des Anwendungsfalls

In den Anwendungsfällen »Auffüllen« und »Geld holen« werden Sie einige gleiche Schritte bemerken. Beide beginnen mit dem Entsichern und Öffnen und beide enden mit dem Schließen und Sichern des Geräts. Können wir von Anwendungsfall zu Anwendungsfall doppelte Schritte eliminieren? Ja. Dies macht man, indem man jede gemeinsame Schrittsequenz nimmt und einen zusätzlichen Anwendungsfall daraus bildet. Wir kombinieren die Schritte »entsichern« und »öffnen« zu einem Anwendungsfall namens »Automateninneres freilegen« und die Schritte »schließen« und »sichern« zu einem Anwendungsfall namens »Automateninneres verbergen«.

100