UML 2.5 – Das umfassende Handbuch

Wissen, wie’s geht.
Wissen aus erster Hand.
Leseprobe
Erfahren Sie alles über UML-Diagramme und Notationselemente,
und lernen Sie, diese sinnvoll in Projekten einzusetzen. Diese Leseprobe gibt Ihnen einen ersten Einblick, wie Sie UML richtig anwenden. Außerdem erhalten Sie das vollständige Inhalts- und Stichwortverzeichnis aus dem Buch.
»Einführung«
»Objektdiagramm«
»Paketdiagramm«
Inhaltsverzeichnis
Index
Die Autoren
Leseprobe weiterempfehlen
Christoph Kecher, Alexander Salvanos
UML 2.5 – Das umfassende Handbuch
458 Seiten, gebunden, mit Poster, 5. Auflage 2015
34,90 Euro, ISBN 978-3-8362-2977-7
www.rheinwerk-verlag.de/3668
Kapitel 1
Einführung
»Zeig mir, wie Du baust,
und ich sage Dir, wer Du bist.«
– Christian Morgenstern
1.1 Weshalb muss Software modelliert werden?
Zu Beginn der Arbeit an diesem Buch fragte mich ein befreundeter Programmierer,
weshalb man Software überhaupt modellieren sollte. Er sei im Laufe seiner Ausbildung nur am Rande mit dem Thema in Berührung gekommen und sehe nicht die
Notwendigkeit, diese »Zusatzaufgabe« während seiner Entwicklungsarbeit durchzuführen. Dies koste nur zusätzlich Zeit, und seine Programme liefen auch ohne sie vorher modelliert zu haben.
Um die Unumgänglichkeit der Modellierung großer Softwaresysteme zu veranschaulichen, lassen Sie uns den Softwareentwicklungsprozess mit dem Bau eines
Hauses vergleichen.
Bevor die eigentlichen Bauarbeiten beginnen, setzt sich der Bauherr zunächst mit
einem Architekten in Verbindung. Er erklärt dem Architekten möglichst genau, wie
sein Traumhaus aussehen sollte, wie die Räumlichkeiten aufgeteilt werden sollen
und was für eine Lage er bevorzugen würde. Der Architekt setzt die Vorstellungen des
Bauherrn in einen Bauplan des Hauses um.
In weiteren gemeinsamen Gesprächen klären der Architekt und der Bauherr alle
Details des Bauplans und besprechen mögliche Veränderungen oder auch Einschränkungen am geplanten Haus. Vielleicht fiel dem Bauherrn in der Zwischenzeit ein,
dass seine neue Garage doch für zehn und nicht, wie zunächst angenommen, für vier
Autos ausgelegt sein sollte. Der Architekt stellt andererseits fest, dass ein Gebäude in
der Größe der Cheops-Pyramide den verfügbaren Finanzrahmen sprengt.
Solche Überlegungen müssen zwingend vor dem Bau des Hauses erfolgen, um während der Bauphase bittere Enttäuschungen, Rückschläge und Verzögerungen der Fertigstellung zu vermeiden.
Nach den Abstimmungsgesprächen zwischen Bauherr und Architekt rückt die Planung der Realisierung in den Mittelpunkt der Überlegungen:
17
1
Einführung
왘 Wie muss das Fundament gegossen werden, um das gesamte Haus tragen zu
können?
왘 Welche Außenverklinkerung soll das Haus erhalten, welche Dachziegel, welche
1.2
Die Phasen bei der Softwareentwicklung
teren Systemen sie interagieren soll (= die Lage des Traumhauses). Ebenfalls muss
klargestellt werden, welche Anforderungen die neue Software nicht erfüllen kann
(= Cheops-Pyramide).
Fensterrahmen?
왘 Welche und wie viele Arbeiter, Arbeitsgeräte und Maschinen müssen wann und in
welcher Menge verfügbar sein?
왘 Wie stellt man sicher, dass alle Bauarbeiten korrekt durchgeführt werden?
Solche und viele weitere Fragen sind ebenfalls vor Beginn der Bauphase zu klären.
Erst nachdem der Bauherr die Sicherheit erlangt hat, dass der Architekt alle seine
Wünsche vollständig und korrekt erfasst und deren Umsetzung geplant hat, gibt er
ihm grünes Licht, um mit den eigentlichen Bauarbeiten zu beginnen.
In der darauffolgenden Bauphase definieren die erstellten Baupläne präzise, welche
Arbeiten in welcher Reihenfolge von den Bauarbeitern durchzuführen sind. Die
Pläne dienen als Kommunikationsgrundlage zwischen dem Architekten und den
Bauarbeitern, die bei den Architekturentscheidungen nicht dabei sein konnten.
1.2.2 Entwurf
In der Entwurfsphase nähert sich Ihr Projekt bereits der Implementierung, weshalb
es zu klären gilt, wie das Softwaresystem realisiert werden soll. Dabei werden auch
system- und architekturorientierte Fragen geklärt, wie z. B.:
왘 Welche Softwarearchitektur soll verwendet werden? Ist z. B. eine Datenbank ein-
zusetzen? (= Fundament)
왘 Wie ist die Benutzungsoberfläche des Programms zu gestalten (= Klinker, Dachzie-
gel, Fensterrahmen)?
왘 Welche Programmiersprachen und Entwicklungsumgebungen sollen verwendet
werden? Welches Know-how müssen die Entwickler mitbringen, um das Vorhaben realisieren zu können? Wann und in welchem Umfang sind die Entwickler
verfügbar (= Bauarbeiter, Arbeitsgeräte und Maschinen)?
왘 Welche Software-Qualitätssicherungsmaßnahmen sind einzusetzen (= Kontrolle
1.2 Die Phasen bei der Softwareentwicklung
Eine sehr ähnliche Vorgehensweise ist auch in der Softwareentwicklung notwendig,
um stabile und zuverlässige Softwaresysteme zu realisieren, die nicht an den Anwenderbedürfnissen vorbeizielen.
Die meisten Vorgehensmodelle zur Softwareentwicklung unterscheiden sechs
grundlegende Phasen:
왘 Analyse
왘 Entwurf
왘 Implementierung
왘 Test
왘 Einsatz
왘 Wartung
1.2.1 Analyse
Während der Analyse werden die Wünsche und Vorstellungen des Auftraggebers
(= Bauherr) und (falls verfügbar) der Endanwender (= Familie des Bauherrn) erfasst
und modelliert.
Der Softwarearchitekt erörtert mit den oben angesprochenen Beteiligten in Interviews, was die gewünschte Software (= das Traumhaus) leisten und mit welchen wei-
18
der Bauarbeiten)?
Das aus dieser Phase entstandene Modell (= Bauplan) dient dem Softwarearchitekten
als Kommunikationsgrundlage mit den Programmierern (= Bauarbeitern) und definiert präzise, welche Programmierarbeiten in welcher Reihenfolge durchzuführen
sind. Erst nach seiner Erstellung kann die Implementierung des eigentlichen Quellcodes beginnen.
Insgesamt kann davon ausgegangen werden, dass mit der Größe des Projekts auch
die Vorteile einer Analyse und eines Entwurfs unter Einsatz einer geeigneten Modellierungssprache überproportional steigen.
1.2.3 Implementierung und Dokumentation
In der Implementierungsphase wird der Quelltext der Software erstellt. Die UMLModellierung aus der Analyse und dem Entwurf repräsentiert einen Systembauplan,
der bei der Codegenerierung als Grundlage dient. Darüber hinaus wird UML von
CASE-Werkzeugen (Computer Aided Software Engineering) verwendet, um den
Quelltext der eingesetzten Programmiersprache automatisch per Codeengineering
erzeugen zu lassen. Weil hierbei auch eine ausführliche Dokumentation erarbeitet
werden muss, ist es besonders hilfreich, dass CASE-Werkzeuge Ihnen auch bei dieser
Aufgabe tatkräftig unter die Arme greifen.
19
1
Einführung
1.4
1.2.4 Test
Die wesentlichen Vorteile der Unified Modeling Language sind:
Bevor die Software bei dem Kunden eingesetzt werden kann, muss überprüft werden, ob die fachlichen Anforderungen des Kunden realisiert worden sind. Auch hierbei sind die UML-Modelle, die in den vergangenen Phasen erstellt wurden, sehr
nützlich, denn auf ihrer Grundlage kann durch Vergleich geprüft werden, ob die einzelnen Details der Anwendungsfälle vollständig in der Anwendung enthalten sind.
Darüber hinaus muss die Software in der Testphase ausgiebig auf Bugs untersucht
werden. Im geschäftskritischen Umfeld wird die Testphase in weitere Teststufen
unterteilt, denn ein Test kann vielfältige Ziele verfolgen. Beispielsweise unterscheidet man zwischen einem Entwicklertest, Validierungstest, Komponententest, Systemtest, Abnahmetest usw.
왘 Eindeutigkeit
Die Geschichte der UML
Die Notationselemente besitzen eine präzise Semantik und sind von vielen Experten definiert und geprüft.
왘 Verständlichkeit
Die einfach gehaltenen Notationselemente visualisieren grafisch die Aspekte der
modellierten Systeme und erleichtern damit das Verständnis.
Unterschiedliche Diagramme ermöglichen differenzierte Sichtweisen auf das zu
modellierende System und betonen oder vernachlässigen bewusst seine Teilaspekte. Damit wird die Kommunikation aller an der Softwareentwicklung beteiligten Personen erleichtert und auf eine stabile Basis gestellt.
왘 Ausdrucksstärke
1.2.5 Einsatz
Nach einer erfolgreichen Testphase wird die Software vom Kunden in Betrieb
genommen. In der Regel muss die Software hierbei in eine Systemlandschaft integriert werden. Auch hierbei ist der Einsatz von UML nützlich, um bei der Migration
mit zahlreichen Anwendungen, Datenbanken usw. den Überblick zu behalten.
1.2.6 Wartung und Pflege
Die Ausschöpfung aller Möglichkeiten der verfügbaren Notationselemente erlaubt die nahezu vollständige Definition aller wichtigen Details eines Softwaresystems.
왘 Standardisierung und Akzeptanz
Weltweit ist die UML in der Softwarebranche im Einsatz. Der Object Management
Group (OMG), die für die Spezifikation der UML verantwortlich ist, gehören mittlerweile mehr als 800 Unternehmen an.
왘 Plattform- und Sprachunabhängigkeit
Selbst nachdem eine Software vom Kunden abgenommen wurde, zeigen sich häufig Fehler, die im Nachhinein zu korrigieren sind. Aber nicht nur deshalb ist Software Veränderungen ausgesetzt. In den meisten Fällen keimen Erweiterungs- oder
Änderungswünsche bei den Nutzern auf, die ein sorgfältig geplantes Änderungsmanagement erforderlich machen. Hierbei zeigt sich erneut, wie vorteilhaft das gewissenhafte Dokumentieren mit UML sein kann, denn die in den vergangenen
Phasen eingepflegten Dokumente sorgen nun nicht nur für eine gute Übersicht,
sondern auch für einen Einblick bis in einzelne Details des Systems.
왘 Unabhängigkeit von Vorgehensmodellen
1.3 Was ist die UML?
1.4 Die Geschichte der UML
Die UML (Unified Modeling Language) definiert eine allgemein verwendbare Modellierungssprache (auch Notation genannt). Ihr Einsatzgebiet beschränkt sich nicht
auf die Softwareentwicklung. Sie stellt Diagramme und Notationselemente (= einzelne Bestandteile der Diagramme) zur Verfügung, mit deren Hilfe sowohl statische
als auch dynamische Aspekte beliebiger Anwendungsgebiete modelliert werden
können.
Um Ihnen einen ersten Eindruck von der UML zu vermitteln, stellt Abbildung 1.1 die
Geschichte der UML als ein Zustandsdiagramm dar. Sie werden diese Diagrammart in
Kapitel 10 kennenlernen (in Abbildung 1.1 werden der Einfachheit halber einige
Details ausgeblendet, die das Diagramm erst vollständig machen würden, wie z. B.
die Bezeichnungen der Transitionen zwischen den Zuständen). Mit der folgenden
Darstellung der UML-Geschichte dürfte das Diagramm jedoch selbsterklärend sein
und bereits die Verständlichkeit der UML im Ansatz demonstrieren:
20
Mit der UML können Sie Softwaresysteme für jede denkbare Plattform und Programmiersprache modellieren. Sie hat ihre Stärken in der objektorientierten Welt,
kann aber ohne Weiteres auch für prozedurale Sprachen eingesetzt werden.
Die UML definiert mit ihren Diagrammen und Notationselementen »Werkzeuge«,
um die Spezifizierung, Visualisierung und Dokumentation von Softwaresystemen
zu erleichtern. Sie überlässt den Softwareentwicklern die Entscheidung, wie sie
diese Werkzeuge am effizientesten nutzen.
21
1
Einführung
1.5 Von der UML 1.x zur UML 2.5
Anfang der 90er-Jahre begannen Grady Booch und Jim Rumbaugh die Arbeit an einer vereinheitlichten Vorgehensmethode und Notation, damals noch unter dem
Namen Unified Method.
Notwendigkeit einer
vereinheitlichten
Modellierungssprache
Zusammenführung
der Methoden
OMT+Booch
Integration der
OOSE und
weiterer Methoden
Unified Method 0.8
1995
Unified Modeling
Language 0.9
1996
Wegen
Rechtsstreitigkeiten bei der
Übergabe der
Copyrights an die
OMG nie freigegeben
Unified Modeling
Language 1.0
1997
Unified Modeling
Language 1.1
1997
OMG Unified
Modeling
Language 1.2
1998
OMG Unified
Modeling
Language 1.3
1999
OMG Unified
Modeling
Language 1.4
2001
OMG Unified
Modeling
Language 1.5
2003
OMG Unified
Modeling
Language 2.0
2005
OMG Unified
Modeling
Language 2.1.2
2007
OMG Unified
Modeling
Language 2.2
2008
OMG Unified
Modeling
Language 2.3
2010
OMG Unified
Modeling
Language 2.4.1
2011
OMG Unified
Modeling
Language 2.5Beta
2013
Abbildung 1.1 Die Geschichte der UML
Die Notwendigkeit der Modellierung von Softwaresystemen wurde bereits in der
»Softwarekrise« in den 70er-Jahren erkannt, als die Entwicklung immer größerer und
komplexerer Softwaresysteme zunehmend unbeherrschbar wurde. In den frühen
90er-Jahren standen sich viele inkompatible und teilweise widersprüchliche Notationen mit unterschiedlichen Notationselementen gegenüber. Die Object Modeling
Technique (OMT) von James Rumbaugh, die Booch-Methode von Grady Booch, das
Object-Oriented Software Engineering (OOSE) von Ivar Jacobson oder die Object-Oriented Analysis (OOA) von Peter Coad und Edward Yourdon sind nur einige Beispiele.
Diese Vielfalt erschwerte die Kommunikation zwischen Softwareentwicklern und
machte die Entwicklung von CASE-Werkzeugen (Computer Aided Software Engineering) äußerst aufwendig.
22
1996 steuerte Ivar Jacobson OOSE bei, wonach zum ersten Mal die Bezeichnung UML
(Unified Modeling Language) verwendet wurde. Ziel der Arbeit war es, die Stärken der
vielen Notationen herauszukristallisieren und zu einer einzigen Modellierungssprache zu konsolidieren.
Schnell erkannten viele namhafte Unternehmen, z. B. Microsoft, Oracle, IBM oder
Rational Software, die Vorteile einer einheitlichen Modellierungssprache und schlossen sich zu den UML Partners zusammen. Im Januar 1997 wurde die UML 1.0 als erste
offizielle Version verabschiedet.
Um einen industrieweiten Standard zu schaffen, strebten die UML Partners eine Zertifizierung durch das Standardisierungsgremium OMG (Object Management Group)
an. 1999 wurde die UML 1.3 zum ersten Mal von der OMG freigegeben.
Seitdem hat sich die UML ständig weiterentwickelt und weltweit in der Softwarebranche als Standard durchgesetzt. Die »drei Amigos« genannten Urväter Booch,
Jacobson und Rumbaugh arbeiten nach wie vor an der Weiterentwicklung. Inzwischen sind jedoch beinahe alle bekannten Unternehmen der Softwarebranche in die
Arbeit an der UML involviert und garantieren den hohen Standard und die Zukunftsfähigkeit der Modellierungssprache.
1.5 Von der UML 1.x zur UML 2.5
Bei der Betrachtung der Abbildung 1.1 ist Ihnen wahrscheinlich der Versionssprung
von UML 1.5 auf 2.0 aufgefallen. Was hat die OMG bewogen, diesen großen Entwicklungsschritt durchzuführen?
Seit der Entwicklung von UML 1.0 hatten die nachfolgenden Versionen lediglich
kleine »kosmetische« Änderungen erfahren. In der Zwischenzeit setzten sich neue
Programmiersprachen (z. B. Java oder C#) immer weiter durch und verdrängten alte
(z. B. C oder C++). Neue Anforderungen aufgrund immer weiterer Einsatzfelder der
UML wurden sichtbar, z. B. der Ruf nach exakteren Modellierungsmöglichkeiten
zeitlicher Aspekte. Alte Notationselemente entpuppten sich als zu nah an einer Programmiersprache entworfen (friend).
Durch das iterative Hinzufügen von Details wurde die UML zwar ständig mächtiger, jedoch immer weniger überschaubar und erlernbar. Die OMG hat dies erkannt
und entschied sich, vollständig aufzuräumen und einen großen Schritt auf Version
2.0 zu machen. Man teilte die Definitionen der UML in zwei Dokumente auf, eines
23
1
Einführung
für die Modellierung von Architektur, Profilen und Stereotypen (Infrastructure)
und eines für statische und dynamische Modellelemente (Superstructure). Aus diesem Grund wurden einige Diagramme vollständig überarbeitet. Das Konzept hinter Aktivitätsdiagrammen (siehe Kapitel 9) wurde beispielsweise komplett
verändert. Vollkommen neue Diagramme, z. B. das Timing-Diagramm (siehe Kapitel 13), wurden aufgenommen. Alte und bewährte Diagrammarten konnten fast
ohne Modifikationen übernommen werden, beispielsweise die Anwendungsfalldiagramme (siehe Kapitel 8) oder die Klassendiagramme (siehe Kapitel 2). Die
Definition der Object Constraint Language (OCL) und ein spezielles XML-Austauschformat wurden in weiteren Teilspezifikationen untergebracht. Mit der Version 2.2 der UML wurden weitere Profildiagramme (siehe Kapitel 15) in die UMLSpezifikation aufgenommen. Die UML 2.3 dehnte den Umfang der Spezifikation
noch weiter aus, sodass die Spezifikation erneut aus den Fugen geriet. Viele Stimmen wurden laut, die die Größe und Komplexität der Spezifikation kritisierten.
Deshalb versuchte man die Spezifikation zu vereinfachen. Dies gelang aber kaum.
Stattdessen gelangten weitere Features in die neue Spezifikation. Beispielsweise
führte die UML 2.4.1 URIs ein und ermöglichte ferner, dass Attribute als eindeutige
Identifier gekennzeichnet werden können. Diese Neuerungen waren wichtig und
mussten dringend hinzugefügt werden.
Für Version 2.5 entschied man sich, das Problem der exorbitanten Spezifikation aufs
Neue anzugehen. Mit viel Aufwand wurde aus den zwei Teilen der Spezifikation ein
neues, nur noch halb so umfangreiches und deutlich vereinfachtes Dokument. Dafür
wurde auf vieles verzichtet, was sich im Laufe der Zeit als irrelevant erwiesen hatte.
Beispielsweise definierte die UML vor 2.5 unterschiedliche Konformitätslevel L0, L1,
L2 und L3, die ein CASE-Tool-Hersteller anstreben kann. Weil dies aber in der Praxis
nicht genutzt wurde, besteht seit Version 2.5 nur noch ein einziger Konformitätslevel. Es ist zwar erlaubt, dass ein CASE-Tool nur eine Untermenge der Notationen oder
der Metamodelle einsetzt, aber dies muss der Hersteller mit einem expliziten Hinweis anzeigen. Ansonsten ist ein CASE-Tool von jetzt an entweder UML-konform
oder eben nicht. Darüber hinaus konnte sehr viel Text eingespart werden, indem alle
redundanten Informationen ganz einfach entfernt wurden.
Insgesamt erschuf die OMG eine neue UML, die kürzer und konsistenter als all ihre
Vorgänger geworden ist. Die inhaltlichen Änderungen der UML-Version 2.5 gegenüber der Vorgängerversion 2.4.1 sind hingegen marginal. So haben sich auch die Diagramme nur sehr wenig verändert. Für Sie als Anwender ist es daher von Bedeutung,
dass die UML-Diagramme die auf Basis älterer UML-Versionen modelliert wurden,
nach wie vor valide sind.
24
1.6
Diagramme der UML 2.5
1.6 Diagramme der UML 2.5
Im neu strukturierten Spezifikationsdokument der Version 2.5 fällt auf, dass es die
UML-Elemente nicht UML-Diagrammen, sondern den Modellierungsarten zuordnet.
Dabei werden grundsätzlich folgende Modellierungsarten unterschieden:
왘 Strukturmodellierung
(Structural Modeling)
왘 Verhaltensmodellierung
(Behavioral Modeling)
왘 Ergänzungsmodellierung
(Supplemental Modeling)
Auf diese Weise verdeutlicht die OMG, dass die Benutzung vieler UML-Elemente
nicht auf ein bestimmtes UML-Diagramm beschränkt ist.
Bei den Elementen der Strukturmodellierung handelt es sich beispielsweise um Klassen, Assoziationen, Pakete, Komponenten usw.
Bei der Verhaltensmodellierung werden die Elemente für die Zustandsmaschinen,
die Aktivitäten und die Interaktionen gezeigt.
Zuletzt erfolgt die Ergänzungsmodellierung, die mithilfe von Anwendungsfällen,
Deployments und Informationsflüssen zusätzliche Möglichkeiten bietet, um das
System in den jeweiligen Projektphasen modellieren zu können.
Der Anhang der Spezifikation geht schließlich erneut auf eine Unterteilung von
UML-Diagrammen ein. Allerdings taucht dort eine andere nämlich die in der Praxis
übliche Sortierung auf. Um in diesem Buch eine klare Linie vorzugeben, die auch in
der alltäglichen Arbeit gängig ist, wurden die Kapitel dieses Buches dieser Sortierung
entsprechend strukturiert.
An dieser Stelle finden Sie zunächst eine Übersicht der UML-Diagramme (siehe Abbildung 1.2), bevor deren Einzelheiten in den folgenden Kapiteln behandelt werden.
Zur Gruppe der Strukturdiagramme gehören:
왘 Klassendiagramm
Ein Klassendiagramm (engl. Class Diagram) beinhaltet die statischen Strukturbestandteile eines Systems, deren Eigenschaften und Beziehungen. Es fungiert als
eine Art allgemeiner Bauplan für Objekte (siehe Abbildung 1.3). Details zu Klassendiagrammen finden Sie in Kapitel 2.
25
1
Einführung
1.6
Diagramme der UML 2.5
Klassendiagramm
Objektdiagramm
Kompositionsstrukturdiagramm
Strukturdiagramm
Komponentendiagramm
Abbildung 1.3 Klassendiagramm
Verteilungsdiagramm
왘 Objektdiagramm
Ein Objektdiagramm (engl. Object Diagram) stellt eine Momentaufnahme der
Objekte eines Systems dar, die nach dem Bauplan eines Klassendiagramms gebildet wurden. Kapitel 3 behandelt alle wichtigen Aspekte von Objektdiagrammen.
Paketdiagramm
Diagramm
Profildiagramm
Anwendungsfalldiagramm
Aktivitätsdiagramm
Abbildung 1.4 Objektdiagramm
Zustandsdiagramm
왘 Kompositionsstrukturdiagramm
Verhaltensdiagramm
Sequenzdiagramm
Ein Kompositionsstrukturdiagramm (engl. Composite Structure Diagram, siehe
Kapitel 4) beschreibt die interne Struktur einer Komponente und deren Interaktionspunkte zu weiteren Komponenten des Systems.
Kommunikationsdiagramm
Interaktionsdiagramm
Timing-Diagramm
Interaktionsübersichtsdiagramm
Abbildung 1.2 Übersicht über die UML-Diagramme
Abbildung 1.5 Kompositionsstrukturdiagramm
26
27
1
Einführung
1.6
왘 Komponentendiagramm
Diagramme der UML 2.5
왘 Profildiagramm
Dieses Diagramm zeigt die Organisation und Abhängigkeiten der Komponenten.
Komponentendiagramme (engl. Component Diagrams) sind das Thema von Kapitel 5.
«artifact»
Profildiagramme (engl. Profile Diagrams) stellen einen leichtgewichtigen Mechanismus dar, mit dem die UML erweitert werden kann. Da sämtliche UML-Metaklassen erweitert werden können, werden Profildiagramme erst in Kapitel 15
behandelt, nachdem Sie alle wichtigen UML-Elemente kennengelernt haben.
«metamodel»
«profile»
«reference»
«realize»
Abbildung 1.9 Profildiagramm
Verhaltensdiagramme sind:
Abbildung 1.6 Komponentendiagramm
왘 Verteilungsdiagramm
Ein Verteilungsdiagramm (engl. Deployment Diagram, siehe Kapitel 6) definiert
die Architektur eines verteilten Systems, wie sie zur Laufzeit vorgefunden wird.
Die Definition beschränkt sich nicht auf Software-Umgebungen, sondern umfasst
auch Hardware und Kommunikationswege.
왘 Anwendungsfalldiagramm
Ein Anwendungsfalldiagramm zeigt die Beziehungen zwischen Akteuren und den
Anwendungsfällen. Anwendungsfälle stellen eine Menge von Aktionen dar, die
ein Akteur während der Interaktion mit einem System abrufen kann. Umfangreiche Informationen zu Anwendungsfalldiagrammen (engl. Use Case Diagrams) finden Sie in Kapitel 8.
«include»
«extend»
«artifact»
Abbildung 1.10 Anwendungsfalldiagramm
Abbildung 1.7 Verteilungsdiagramm
왘 Aktivitätsdiagramm
왘 Paketdiagramm
Das Thema von Kapitel 7 sind Paketdiagramme (engl. Package Diagrams), die
UML-Elemente in Pakete organisieren.
Aktivitätsdiagramme (engl. Activity Diagrams, siehe Kapitel 9) beschreiben das
Verhalten einer Klasse oder Komponente. Sie bedienen sich dabei eines Kontrollund Datenflussmodells.
«merge»
Abbildung 1.8 Paketdiagramm
28
Abbildung 1.11 Aktivitätsdiagramm
29
1
Einführung
1.6
왘 Zustandsdiagramm
Die möglichen Zustände, Zustandsübergänge, Ereignisse und Aktionen im
»Leben« eines Systems werden in einem Zustandsdiagramm (engl. State Machine
Diagram, siehe Kapitel 10) modelliert. Zustandsdiagramme basieren auf dem Konzept der deterministischen endlichen Automaten.
Diagramme der UML 2.5
왘 Kommunikationsdiagramm
Ein Kommunikationsdiagramm (engl. Communication Diagram, siehe Kapitel 12)
beschreibt die Interaktion zwischen Objekten. Im Gegensatz zum Sequenzdiagramm setzt es den Fokus auf die Kommunikationsbeziehungen der Objekte während einer Interaktion.
1:a
3:c
2:b
Abbildung 1.12 Zustandsdiagramm
Die folgenden Verhaltensdiagramme werden unter der Bezeichnung Interaktionsdiagramme (engl. Interaction Diagrams) zusammengefasst:
왘 Sequenzdiagramm
Sequenzdiagramme (engl. Sequence Diagrams, siehe Kapitel 11) definieren Interaktionen zwischen Objekten, wobei sie sich auf den Nachrichtenfluss konzentrieren.
Sie zeigen den zeitlichen Ablauf der Nachrichten, beinhalten jedoch keine Informationen über Beziehungen der Objekte.
Abbildung 1.14 Kommunikationsdiagramm
왘 Timing-Diagramm
Timing-Diagramme zeigen die Zustandswechsel von Objekten innerhalb einer
Zeitspanne als Antworten auf eintreffende Ereignisse. Kapitel 13 enthält alle
Details zu Timing-Diagrammen (engl. Timing Diagrams).
z3
z2
z1
a
b
c
d
e
f
alt
[if]
sec
0
10
20
30
40
50
60
70
[else]
Abbildung 1.15 Timing-Diagramm
왘 Interaktionsübersichtsdiagramm
Abbildung 1.13 Sequenzdiagramm
30
Beim Interaktionsübersichtsdiagramm handelt es sich um eine Diagrammart, die
den Kontrollfluss zwischen Interaktionen mithilfe der Notationselemente von
31
1
Einführung
Aktivitätsdiagrammen beschreibt. Die einzelnen Kontrollflussknoten können
vollständige Interaktionsdiagramme repräsentieren. Kapitel 14 befasst sich mit
den Feinheiten von Interaktionsübersichtsdiagrammen (engl. Interaction Overview Diagrams).
sd
sd
sd
Abbildung 1.16 Interaktionsübersichtsdiagramm
Nach dieser ersten Übersicht behandeln die folgenden Kapitel die einzelnen Diagramme und deren Notationselemente im Detail. Die gerade vorgestellte Gruppierung der Diagramme spiegelt sich dabei in der Reihenfolge der Kapitel wider.
Hinweis
Den vollständigen Code der im Buch verwendeten Beispiele können Sie unter »Materialien zum Buch« von www.rheinwerk-verlag.de/3668 herunterladen.
32
Kapitel 3
Objektdiagramm
Das Objektdiagramm zeigt eine Momentaufnahme
der Objekte eines Systems.
3.1 Anwendungsbereiche
Ein Objektdiagramm (engl. Object Diagram) kann als Sonderfall eines Klassendiagramms angesehen werden.
Während ein Klassendiagramm die allgemeinen Baupläne und alle möglichen Beziehungen der Objekte untereinander modelliert, stellt das zugehörige Objektdiagramm die tatsächlich erzeugten Objekte, deren Attributwerte und Beziehungen
innerhalb eines begrenzten Zeitraums zur Laufzeit dar.
Aus diesem Grund werden Objektdiagramme in allen Phasen der Softwareentwicklung parallel zu Klassendiagrammen eingesetzt. Ihre Verwendung wird zumeist
jedoch nur notwendig, wenn komplexe Klassendiagramme anhand von Beispielen
verdeutlicht und überprüft werden sollen.
3.2 Übersicht
Abbildung 3.1 präsentiert die wichtigsten Notationselemente von Objektdiagrammen:
121
3
Objektdiagramm
3.3
Abbildung 3.2 zeigt ein Objekt maren und dessen Attribute mit Attributwerten, die
ihren Zustand festlegen. Im Unterschied zum Notationselement einer Klasse werden
der Objektname und die Klassenzugehörigkeit unterstrichen dargestellt. Auf die Darstellung von Operationen wird bei Objekten verzichtet.
Objektname
Rolle
lieblingsgrieche :
Restaurant
Link
+Arbeitgeber
kategorie: Sterne = 3
name = "Platon"
besucht
besucht
Das Objekt maren der Klasse Gast wird zu einem Zeitpunkt seines Lebens gezeigt, in
dem seine Attribute status den Wert "König", geldbetrag vom Typ EUR den Wert 300
und hunger den Wert true aufweisen. Anschaulich ausgedrückt, besitzt der Gast maren
300 EUR, ist hungrig und wird wie ein König behandelt. Die Attributwerte müssen
erwartungsgemäß zu den Typen der Attribute passen.
zugehörige Klasse
Linkname
maren :Gast
bedient
status = "König"
geldbetrag: EUR = 300
hunger = true
Leserichtung
+Arbeitnehmer
klaudia :Gast
:Kellner
bedient
status = "König"
geldbetrag: EUR = 20
hunger = true
Objekt
Notationselemente
persAusweisNr = 12345
gehalt: EUR = 1500
Attributname Attributtyp
Attributwert
Abbildung 3.1 Notationselemente von Objektdiagrammen
Das Objektdiagramm beschreibt nicht, wie maren in diesen Zustand gekommen ist
oder welches ihr nächster Zustand ist. Die Modellierung aller Zustände und
Zustandsübergänge ist Aufgabe des Zustandsdiagramms, das Sie in Kapitel 10 kennenlernen.
Die Angabe der Attribute und Attributwerte eines Objektes kann unvollständig sein
und nur diejenigen umfassen, die gerade für seinen Zustand bedeutend sind.
Abbildung 3.3 zeigt ein Objekt der Klasse Gast mit dem Namen maren während der
Erteilung einer Bestellung.
Zu diesem Zeitpunkt hatte maren demnach 300 EUR und den status "König". Das Attribut hunger wird ausgeblendet, da es bei der Erteilung einer Bestellung nicht zwingend
eine Rolle spielen muss.
3.3 Notationselemente
3.3.1 Objekt
Zeitpunkt:
Erteilung einer
Bestellung
Objektname
zugehörige Klasse
Abbildung 3.3 Unvollständige, aber zulässige Objektspezifikation
maren :Gast
status = "König"
hunger = true
geldbetrag: EUR = 300
Objekt
Attributname
Attributtyp
Die Instanziierung einer Klasse durch ein Objekt kann auch mithilfe der <<instantiate>>-Abhängigkeit modelliert werden:
Attributwert
Abbildung 3.2 Objekt
Beschreibung
Ein Objekt (engl. Object) entsteht bei der Realisierung eines Bauplans, den eine Klasse
spezifiziert. Es wird auch als Instanz oder Exemplar einer Klasse bezeichnet.
122
maren :Gast
status = "König"
geldbetrag: EUR = 300
Objekt/Instanz
maren :Gast
status = "König"
geldbetrag: EUR = 300
hunger = true
Klasse
Abhängigkeit
«instantiate»
Gast
+
#
status: String = "König"
geldbetrag: EUR
hunger: boolean = true
Abbildung 3.4 Instanziierung einer Klasse
123
3
Objektdiagramm
Abbildung 3.4 zeigt, dass das Objekt maren eine Instanz der Klasse Gast darstellt. Man
erkennt dies zwar auch an der Klassenbezeichnung hinter dem Doppelpunkt im
Objektnamen. Die Darstellung aus Abbildung 3.4 hebt jedoch den Zusammenhang
zwischen Objekt und Klasse hervor und zeigt den »Bauplan« und das »Produkt« in
einem Diagramm.
3.3
A
private EUR geldbetrag;
protected boolean hunger;
B
public Gast(EUR g, boolean h)
Verwendung
Objektdiagramme sind hilfreich, um den konkreten Zustand einzelner Objekte in
einem gegebenen Kontext darzustellen. Sie stellen im Allgemeinen die Werte der
Attribute dar, die diesen Zustand charakterisieren. Alle anderen Attribute werden aus
Gründen der Überschaubarkeit weggelassen.
{
geldbetrag = g;
hunger = h;
}
B
Bei der Darstellung der Objekte können Klassendiagramme auf deren Vollständigkeit und Korrektheit überprüft werden. Benötigen Sie in einem der Objektdiagramme ein Objekt, das keiner der Klassen zugeordnet werden kann, ist Ihr
Klassendiagramm unvollständig. Klassen dagegen, nach deren Bauplan kein Objekt
erzeugt werden musste, können eventuell aus dem Klassendiagramm entfernt
werden.
Realisierung in Java
Zur Implementierung wird das Beispiel aus Abbildung 3.4 herangezogen.
Zunächst wird eine Klasse EUR erstellt, die den Datentyp für geldbetrag realisiert. Sie
kapselt lediglich eine Fließkommazahl (float):
class EUR
{
public float betrag;
public EUR(float b)
{
betrag = b;
}
}
Listing 3.1 /beispiele/java/kap3/kap_3_3_1/EUR.java (Download der Beispiele: www.rheinwerk-verlag.de/3668)
Nun kann die Klasse Gast implementiert werden:
class Gast
{
public static String status = "König";
124
Notationselemente
public Gast(EUR g)
{
geldbetrag = g;
hunger = true;
}
}
Listing 3.2 /beispiele/java/kap3/kap_3_3_1/Gast.java
A: Der geldbetrag erhält den geforderten Typ EUR.
B: Java bietet keine Möglichkeit, Vorgabewerte für Übergabeparameter zu definieren, was für das Attribut hunger notwendig wäre. Daher bedient sich dieses
Beispiel der Überladung von Konstruktoren und emuliert damit eine Art Vorgabewert.
Eine einfache Hauptoperation demonstriert die Instanziierung eines Objekts der
Klasse Gast:
public static void main(String[] args)
{
A
Gast maren = new Gast(new EUR(300), true);
}
Listing 3.3 /beispiele/java/kap3/kap_3_3_1/Test.java
A: Das in Abbildung 3.4 gezeigte Objekt maren mit einem geldbetrag von 300 EUR und
hunger = true wird mithilfe des new-Operators instanziiert.
125
3
Objektdiagramm
Das Attribut status muss nicht gesetzt werden, da es als Klassenattribut für alle
Objekte der Klasse Gast verfügbar ist und bereits bei seiner Deklaration mit
"König" vorbelegt wird.
Realisierung in C#
Die Umsetzung und Instanziierung der Klasse Gast unterscheidet sich in C# nicht
wesentlich von der in Java:
public class Gast
{
public static string status = "König";
private EUR geldbetrag;
A
3.3
Notationselemente
A: Das in Abbildung 3.4 dargestellte Objekt maren der Klasse Gast wird mit einem
geldbetrag von 300 EUR und hunger = true angelegt, was in C# ebenfalls mit dem
new-Operator durchgeführt wird.
3.3.2 Link
Linkname Leserichtung
:Kellner
mitarbeiterNr = 12
gehalt: EUR = 1500
maren :Gast
bedient
Link
status = "König"
geldbetrag: EUR = 300
hunger = true
Abbildung 3.5 Link
protected bool hunger;
Beschreibung
public Gast(EUR g, bool h)
{
geldbetrag = g;
hunger = h;
}
public Gast(EUR g)
{
geldbetrag = g;
hunger = true;
}
}
Listing 3.4 /beispiele/c#/kap3/kap_3_3_1/Kap_3_3_1.cs
Ein Link repräsentiert eine Beziehung zwischen zwei Objekten.
In einem Klassendiagramm werden Beziehungen zwischen Klassen als Assoziationen
bezeichnet. In einem Objektdiagramm ist ein Link die konkrete Ausprägung einer
Assoziation.
Grafisch sind Links und Assoziationen nicht unterscheidbar. Durch ihre Verwendung
zwischen Klassen bzw. Objekten sind sie jedoch nicht zu verwechseln.
Links erhalten alle Aspekte ihrer zugehörigen Assoziation, wie z. B. Rollen, Namen,
Leserichtungen oder Eigenschaften. Allein eine Multiplizität höher als 1 ist nicht
erlaubt, weil Links immer genau zwei Objekte verbinden. Hat eines der instanziierten
Assoziationsenden eine Multiplizität größer als 1, können mehrere Links zu mehreren Objekten modelliert werden.
A: In C# muss statt boolean der Datentyp bool verwendet werden.
Verwendung
static void Main(string[] args)
{
A
Gast maren = new Gast(new EUR(300), true);
}
Listing 3.5 /beispiele/c#/kap3/kap_3_3_1/Kap_3_3_1.cs
126
Genauso wie ein Klassendiagramm ohne Assoziationen nicht viel mehr als eine
Anhäufung von beziehungslosen Klassen ist, stellt ein Objektdiagramm ohne Links
eine Anhäufung von beziehungslosen Objekten dar. Verbinden Sie daher Objekte
mit Links auf dieselbe Art, wie Sie Klassen mit Assoziationen verbinden.
Sollte Ihnen während der Erstellung eines Objektdiagramms auffallen, dass ein Link
benötigt wird, dem keine entsprechende Assoziation im Klassendiagramm gegenübersteht, ist Ihr Klassendiagramm unvollständig und muss erweitert werden. Assoziationen aus Klassendiagrammen, die in keinem der Objektdiagramme verwendet
wurden, sind darauf zu überprüfen, ob sie im Klassendiagramm wirklich benötigt
werden.
127
3
Objektdiagramm
3.3
Realisierung in Java
bedienung = k;
k.kunde = this;
Das Objektdiagramm aus Abbildung 3.6 zeigt im oberen Teil die Klassen Kellner und
Gast, die durch eine Assoziation verbunden sind.
}
Der untere Teil der Abbildung beinhaltet die Objekte und einen Link, die diese beiden
Klassen sowie die Assoziation instanziieren.
Dieses Objektdiagramm soll im Folgenden umgesetzt werden.
Gast
Kellner
+Kunde
+Bedienung
Notationselemente
}
Listing 3.6 /beispiele/java/kap3/kap_3_3_2/Kellner.java & Gast.java
A: Die Assoziation zum Gast wird deklariert.
B: Da die Assoziation in beide Richtungen navigierbar ist, werden beide Assoziationsenden gleichzeitig instanziiert: sowohl auf der Seite des Kellners als auch
auf der Seite des Gastes.
1
Erst damit ist die Assoziation vollständig und konsistent instanziiert: Ein Link
entsteht.
«instantiate»
«instantiate»
maren :Gast
mathias :Kellner
C: Bei der Klasse Kunde wird auf dieselbe Art verfahren.
In einer Hauptoperation werden die Objekte instanziiert und die Links gesetzt:
+Kunde
+Bedienung
1
Abbildung 3.6 Link-Beispiel
public static void main(String[] args)
{
1
A
Gast maren = new Gast();
Kellner mathias = new Kellner();
B
maren.setKellner(mathias);
Zunächst werden die Klassendefinitionen realisiert:
class Kellner
{
}
Listing 3.7 /beispiele/java/kap3/kap_3_3_2/Test.java
A
public Gast kunde;
B
public void setGast(Gast g)
{
kunde = g;
g.bedienung = this;
}
A: Objekte werden in Java mithilfe des new-Operators instanziiert.
}
class Gast
{
C
128
public Kellner bedienung;
public void setKellner(Kellner k)
{
B: Die gegenseitigen Assoziationen werden gesetzt und damit zu Links instanziiert.
Der Aufruf einer der beiden set-Operationen ist ausreichend, da jede von ihnen
beide Assoziationsenden konsistent setzt und somit den gesamten Link instanziiert.
Realisierung in C#
Objekte werden in C# ebenfalls mit dem new-Operator instanziiert, sodass die Implementierung gegenüber dem Java-Programmcode keine erwähnenswerten Unterschiede aufweist. Sie finden den vollständigen Programmcode im Ordner beispiele/
c#/kap3/kap_3_3_2.
129
3
Objektdiagramm
3.5
3.4 Lesen eines Objektdiagramms
Irrungen und Wirrungen
Das Objektdiagramm aus Abbildung 3.8 zeigt vier Objekte:
Ein Objektdiagramm wird üblicherweise verwendet, um ein Klassendiagramm zu
illustrieren. Aus diesem Grund wird zunächst ein Klassendiagramm (siehe Abbildung 3.7) entworfen:
왘 lieblingsgrieche der Klasse Restaurant
왘 namenlosen Kellner
왘 maren der Klasse Gast
왘 klaudia der Klasse Gast
Restaurant
+ kategorie: Sterne
+ name: String
+Arbeitgeber +Arbeitnehmer
persAusweisNr
0..1
-
1..*
Mitarbeiter
persAusweisNr: int
gehalt: EUR
Als Arbeitgeber hat er einen Link zu seinem Arbeitnehmer. Zurzeit handelt es sich
dabei um einen einzigen Kellner, dessen Objektname nicht spezifiziert wurde, weil er
hier als nicht wichtig angesehen wird.
1
besucht
0..50
Gast
+ status: String = "König"
- geldbetrag: EUR
# hunger: boolean = true
Kellner
1..5
bestellt
bedient
+ bedienen(g :Gast)
1 + servieren(g :Gast, ge :Gericht)
+ kassieren(p :Preis)
+ bestellen() : Menuepunkt
+ zahlen(p :Preis) : EUR
Abbildung 3.7 Klassendiagramm als Grundlage für ein Objektdiagramm
Für das Klassendiagramm aus Abbildung 3.7 wird ein Objektdiagramm (siehe Abbildung 3.8) erstellt.
lieblingsgrieche :
Restaurant
Beachten Sie, dass kein Objekt der Klasse Mitarbeiter im Objektdiagramm aufgeführt wird. Wie in Abschnitt 2.3.14 erläutert wurde, dienen abstrakte Klassen als Vorlagen für weitere Klassen und können nicht selbst instanziiert werden. Bei der
Klasse Mitarbeiter handelt es sich um solch eine abstrakte Klasse. Sie wird von der
Klasse Kellner spezialisiert, weshalb das namenlose Kellner-Objekt über alle Attribute eines Mitarbeiters verfügt und sie mit den Werten 12345 (persAusweisNr) und
1500 (gehalt) belegen kann.
Das Klassendiagramm aus Abbildung 3.7 definiert, dass ein Kellner 1 bis 5 Gäste
bedienen kann. Im Objektdiagramm kann daher ein unbekannter Kellner zwei Gäste
(maren und klaudia) bedienen, mit denen er über zwei Links verbunden ist.
maren und klaudia sind zwei Objekte der Klasse Gast und besitzen damit alle Attri-
bute eines Gastes. Beide Objekte besuchen gerade dasselbe Restaurant und sind
daher mit dem lieblingsgriechen über Links verbunden.
+Arbeitgeber
Bei den Gast-Objekten sollte zusätzlich erwähnt werden, dass jedes der Gast-Objekte
das Attribut status mit dem Wert »König« besitzt, da es in der Klasse als statisches
Attribut deklariert und mit eben diesem Wert vorbelegt wird (statische Attribute
wurden bereits in Abschnitt 2.3.2 behandelt).
kategorie: Sterne = 3
name = "Platon"
besucht
Zu einem nicht näher spezifizierten Zeitpunkt besitzt der lieblingsgrieche den namen
"Platon" und die kategorie 3 Sterne.
besucht
maren :Gast
status = "König"
geldbetrag: EUR = 300
hunger = true
3.5 Irrungen und Wirrungen
bedient
+Arbeitnehmer
klaudia :Gast
status = "König"
geldbetrag: EUR = 20
hunger = true
Abbildung 3.9 zeigt ein fehlerhaftes Objektdiagramm, das ein Beispiel des Klassendiagramms aus Abbildung 3.7 sein sollte:
:Kellner
bedient
persAusweisNr = 12345
gehalt: EUR = 1500
Abbildung 3.8 Beispiel-Objektdiagramm
130
131
3
Objektdiagramm
3.6 Zusammenfassung
heiner :
Fleischlieferant
Macht das Objektdiagramm deutlich, dass ein zusätzlicher Link notwendig ist,
muss das Klassendiagramm um die entsprechende Assoziation ergänzt werden.
A
B
lieblingsgrieche :
Restaurant
+Arbeitgeber
+Arbeitnehmer
:Mitarbeiter
kategorie: Sterne = 3
name = "Platon"
besucht
maren :Gast
E
groesse: cm = 175
status = "König"
geldbetrag: EUR = 300
hunger = "sehr gross"
:Kellner
bedient
Neue benötigte Attribute müssen zunächst in der Klasse hinzugefügt werden.
F: Attributwert falsch
Die Attributwerte der Objekte müssen dem Datentyp der Attribute entsprechen.
Attribut hunger ist vom Typ boolean und erlaubt damit nur die Werte true und
false.
D
C
E: Neues Attribut
Objekte dürfen keine Attribute mit Werten belegen, die nicht bereits in der Klasse
deklariert sind. Das Objekt würde andernfalls die Definition der Klasse und damit
seinen eigenen Bauplan verändern.
persAusweisNr = 12345
gehalt: EUR = 1500
F
3.6 Zusammenfassung
Die wichtigsten Notationselemente von Objektdiagrammen und deren Bedeutung
werden im Folgenden noch einmal rekapituliert:
왘 Ein Objekt wird auch als Instanz oder Ausprägung einer Klasse bezeichnet und
entsteht als Produkt der Realisierung eines Klassen-Bauplans.
Abbildung 3.9 Mögliche Fehler in Objektdiagrammen
Objektname
A: Unbekannte Klasse
Es dürfen nur Objekte erstellt werden, die aus Klassen des zugrunde liegenden
Klassendiagramms erzeugt werden können.
Werden Objekte neuer Klassen benötigt, ist das Klassendiagramm unvollständig
und muss erweitert werden.
B: Instanz einer abstrakten Klasse
Aus abstrakten Klassen können keine Instanzen erzeugt werden.
C: Falsche Leserichtung
Die Links eines Objektdiagramms müssen den Assoziationen des Klassendiagramms in den Assoziationsnamen, Leserichtungen, Rollen, Navigationsrichtungen und Eigenschaften entsprechen und dürfen sie nicht verändern.
Objekt
maren :Gast
Abbildung 3.10 Objekt
왘 Links zeigen Beziehungen zwischen Objekten.
Linkname
maren :Gast
Zeichnet sich bei der Erstellung eines Objektdiagramms ab, dass eine andere
Assoziation benötigt wird, muss das Klassendiagramm modifiziert werden.
D: Neue Assoziation
Ein Objektdiagramm darf keine Links beinhalten, die nicht im Klassendiagramm
als Assoziationen vorhanden sind. Andererseits sollten Assoziationen aus dem
zugehörigen Klassendiagramm auch als Links im Objektdiagramm nicht fehlen.
132
zugehörige Klasse
Leserichtung
besucht
lieblingsgrieche :
Restaurant
Link
Abbildung 3.11 Link
133
Kapitel 7
Paketdiagramm
Paketdiagramme organisieren und strukturieren Elemente
in Paketen.
7.1 Anwendungsbereiche
Paketdiagramme (engl. Package Diagrams) werden zumeist in den frühen Phasen der
Softwareentwicklung (wie Analyse/Definition und Entwurf/Design) verwendet, um
das Modell sowohl horizontal als auch vertikal zu strukturieren.
Mit der horizontalen Strukturierung wird die Möglichkeit bezeichnet, beliebige UMLElemente, die logisch zusammengehören, in Paketen zusammenzufassen und damit
das UML-Modell zu modularisieren.
Pakete können Unterpakete enthalten und erlauben damit eine vertikale Strukturierung. Das Paket auf der obersten Ebene kann beispielsweise das gesamte Projekt
repräsentieren, während die Pakete auf den tieferen Ebenen sich den Projektdetails
nähern.
Mithilfe der vertikalen Strukturierung werden unterschiedliche Abstraktionsebenen
eines Modells definiert, und es wird die Möglichkeit geschaffen, aus einer übersichtsartigen Darstellung schrittweise in die Details zu zoomen.
Strukturieren Sie Ihr Modell sowohl horizontal als auch vertikal, um es möglichst
überschaubar und damit verständlich zu gestalten.
7.2 Übersicht
In Abbildung 7.1 sehen Sie die wichtigsten Notationselemente von Paketdiagrammen:
185
7
Paketdiagramm
7.3
Notationselemente
Beschreibung
Paketname
Paket
restaurantsystem
Pakete (engl. Packages) gruppieren Elemente und definieren Namensräume (engl.
Namespaces), in denen sich diese Elemente befinden.
gaesteverwaltung
Gast
#
#
ImportBeziehung
«import»
kundennummer
umsatz: float = 0
Klasse
AccessBeziehung
MergeBeziehung
Abbildung 7.2 zeigt ein Paket datenverwaltung, das ein Unterpaket datenbank und eine
Klasse Administrator enthält und damit Elemente gruppiert, die mit der Datenverwaltung im Zusammenhang stehen.
Die UML stellt hierfür eine weitere Notationsmöglichkeit zur Verfügung (siehe Abbildung 7.3):
werkzeuge
«access»
«access»
datenverwaltung
«merge»
+ PdfErzeuger
datenverwaltung
vipGaesteverwaltung
Paketgruppierung
datenbank
datenpflege
Gast
datenbank
#
#
lieblingswein
leibgericht
Administrator
Abbildung 7.1 Notationselemente von Paketdiagrammen
Abbildung 7.3 Gruppierung von Elementen in einem Paket
Die Diagramme aus Abbildung 7.2 und Abbildung 7.3 sind semantisch gleich.
7.3 Notationselemente
Alle Elemente innerhalb eines durch ein Paket definierten Namensraumes müssen
unterschiedliche Namen besitzen. Innerhalb von unterschiedlichen Paketen ist es
jedoch durchaus möglich, zwei Elemente mit demselben Namen zu definieren (siehe
Abbildung 7.4):
7.3.1 Paket
Paketname
Paket
datenverwaltung
restaurantsystem
gaesteverwaltung
datenbank
Administrator
Paket
datenbank
datenbank
Klasse
Abbildung 7.4 Pakete definieren Namensräume.
Abbildung 7.2 Paket
186
187
7
Paketdiagramm
Die Namen der Unterpakete datenbank in Abbildung 7.4 verursachen trotz ihrer
Gleichheit keinen Namenskonflikt, weil sie in unterschiedlichen Paketen und damit
in unterschiedlichen Namensräumen verwendet werden.
Außerhalb ihrer Pakete können sie jedoch nicht mehr über ihren unqualifizierten
Namen datenbank angesprochen werden, weil dieser sie nicht eindeutig identifiziert. UML definiert hierfür die qualifizierten Namen, in denen zusätzlich die Paketnamen getrennt durch zwei Doppelpunkte angegeben werden müssen. Für die
in Abbildung 7.4 modellierten Unterpakete lauten sie beispielsweise restaurantsystem::datenbank bzw. gaesteverwaltung::datenbank.
7.3
Hierarchieebenen von Paketen erlauben Ihnen eine vertikale Strukturierung des
Modells. Sie gliedern ein Gesamtsystem damit auf abstrakter Ebene bereits in Teilsysteme und deren Bestandteile auf und schaffen damit eine wichtige Grundlage für
Komponentendiagramme (siehe Kapitel 5).
Realisierung in Java
Als Beispiel soll das Paketdiagramm aus Abbildung 7.6 verwendet werden:
datenverwaltung
Der Inhalt ist mit seinem Paket untrennbar verbunden. Alle Elemente eines Pakets
werden aus dem Modell entfernt, wenn das Paket gelöscht wird.
datenbank
Administrator
Wenn ein Paket keine Elemente aufzeigt, heißt dies nicht automatisch, dass es keine
besitzt. Die UML erlaubt, den Inhalt von Paketen auszublenden, um das Paketdiagramm übersichtlicher zu gestalten.
Alle in einem Paket gruppierten Elemente sind innerhalb eines Pakets untereinander
sichtbar. Ihre Sichtbarkeit außerhalb ihres Pakets kann eingeschränkt werden, indem
sie als protected (#), private (-) oder package (~) (siehe auch Abschnitt 2.3.2) definiert wird (siehe Abbildung 7.5).
In Abbildung 7.5 wird ein Goldbarren als nur innerhalb des tresors sichtbar definiert
(private). Von außerhalb darf damit nicht auf den Goldbarren zugegriffen werden
(was manchen Einbrechern durchaus Schwierigkeiten bereiten könnte).
tresor
- Goldbarren
Sichtbarkeit
Abbildung 7.5 Sichtbarkeit eines Paketelements
Verzichtet man auf die Spezifikation einer Sichtbarkeit, wird public (+) angenommen, womit das Element auch außerhalb des Pakets über seinen qualifizierten
Namen referenziert werden kann.
Verwendung
Durch die Verwendung von Paketen teilen Sie das System horizontal auf. Sie strukturieren die modellierten Klassen und sogar ganze Systeme in logisch und funktionell
zusammengehörende Einheiten, modularisieren sie und gestalten ein Modell damit
einfacher und überschaubarer.
188
Notationselemente
-
Relation
alter: int
+ setAlter(alter :int) : void
+ getAlter() : int
Abbildung 7.6 Beispiel eines Paketdiagramms
Java verlangt die Abbildung modellierter Pakete auf Dateisystem-Ordner und die
Implementierung von Klassen in separaten Dateien mit dem Namen der Klasse und
einer Dateiendung .java.
Soll demnach das Paketdiagramm aus Abbildung 7.6 in Java implementiert werden,
muss ein Ordner mit dem Namen datenverwaltung im Dateisystem erstellt werden.
In ihm muss eine Programmcode-Datei mit der Bezeichnung Administrator.java
sowie ein weiterer Ordner datenbank angelegt werden, in dem sich wiederum eine
Datei namens Relation.java befindet.
Die Zugehörigkeit einer Klasse zu einem Paket wird mit dem Schlüsselwort package
deklariert:
A package datenverwaltung;
public class Administrator
{
B
private int alter;
public void setAlter(int alter)
{
this.alter = alter;
}
189
7
Paketdiagramm
public int getAlter()
{
return this.alter;
}
7.3
B
public class Administrator
{
private int alter;
public void setAlter(int alter)
{
this.alter = alter;
}
public int getAlter()
{
return this.alter;
}
}
C
namespace datenbank
}
Listing 7.1 /beispiele/java/kap7/datenverwaltung/Administrator.java (Download der Beispiele: www.rheinwerk-verlag.de/3668)
A: Die Klasse Administrator gehört zum Paket datenverwaltung. Während die UML
die Default-Sichtbarkeit von Elementen mit public definiert, gilt in Java package
als Vorgabewert. Um mit dem Paketdiagramm aus Abbildung 7.6 konform zu
sein, muss daher die Sichtbarkeit der Klasse explizit mit public angegeben
werden.
B: Alle Attribute und Operationen der Klasse müssen in Java in derselben Datei
implementiert werden.
{
D
public class Relation
{
}
A package datenverwaltung.datenbank;
public class Relation
{
}
Notationselemente
}
}
Listing 7.2 /beispiele/java/kap7/datenverwaltung/datenbank/Relation.java
Listing 7.3 /beispiele/c#/kap7/kap_7_3_1/Kap_7_3_1.cs
A: In Java erfolgt die Deklaration von Unterpaketen mithilfe des Punkt-Operators.
Hier wird definiert, dass die Klasse Relation ein Bestandteil des Pakets datenbank
ist, das sich selbst wiederum im Paket datenverwaltung befindet.
A: Pakete definieren Namensräume für Elemente und werden daher in C# mit dem
Schlüsselwort namespace deklariert, was an dieser Stelle für das Paket datenverwaltung erfolgt.
Realisierung in C#
B: Innerhalb des Namensraums wird eine Klasse Administrator implementiert.
Bezüglich der Default-Sichtbarkeit weist C# denselben Unterschied zur UML auf
wie Java (UML: public, C#: package).
Das Paket-Konzept von C# weist einige Unterschiede zum Paket-Konzept von Java
auf. C# verlangt nicht, dass jedes Paket durch einen eigenen Ordner im Dateisystem
abgebildet wird. Ebenso entfällt die Beschränkung, jede Klasse in einer separaten
Datei implementieren zu müssen. C# erlaubt, unterschiedliche Pakete, Unterpakete
und Klassen in derselben Datei zu deklarieren und zu implementieren:
A namespace datenverwaltung
{
190
C: Ein Unterpaket kann in C# intuitiv innerhalb des umfassenden Pakets deklariert
werden. Hier wird ein Paket (namespace) datenbank innerhalb des Pakets datenverwaltung angelegt.
D: Das Unterpaket datenbank enthält eine Klasse Relation.
Seit der Version 2.0 ist es in C# möglich, die Implementierung einzelner Klassen auf
unterschiedliche Dateien zu verteilen. So kann beispielsweise die Deklaration der
Attribute von der Implementierung der Operationen getrennt und auf beliebig viele
Quellcodedateien aufgeteilt werden.
191
7
Paketdiagramm
namespace datenverwaltung
{
7.3
Notationselemente
A: Auch in dieser Quellcodedatei muss die partielle Implementierung mit dem
Schlüsselwort partial signalisiert werden.
B: Es werden nur die Operationen der Klasse implementiert.
A
public partial class Administrator
7.3.2 Paket-Import
{
B
private int alter;
importierendes Paket
restaurantsystem
importiertes Paket
Paket-Import
werkzeuge
}
}
+ PdfErzeuger
«import»
Listing 7.4 /beispiele/c#/kap7/kap_7_3_1/Admin_Attribute.cs
Abbildung 7.7 Paket-Import
A: Die Aufteilung einer Klasse auf mehrere Quellcodedateien wird mit dem Schlüsselwort partial signalisiert.
B: Es wird nur das private Attribut alter deklariert.
In einer weiteren Datei können dann beispielsweise die Zugriffsoperationen implementiert werden:
namespace datenverwaltung
{
A
public partial class Administrator
{
B
public void setAlter(int alter)
{
this.alter = alter;
}
public int getAlter()
{
return this.alter;
}
}
Beschreibung
Ein Paket-Import (engl. PackageImport) ist eine Beziehung, die alle Namen öffentlicher Elemente eines Pakets dem importierenden Paket als öffentlich hinzufügt.
Damit wird die Referenzierung von Elementen eines Pakets über unqualifizierte
Namen möglich, so als wenn das importierende Paket diese Elemente selbst enthalten würde. Wird das importierende Paket aus dem Modell entfernt, bleiben die Elemente im importierten Paket erhalten.
Laut Paketdiagramm aus Abbildung 7.7 kann PdfErzeuger im Paket restaurantsystem
direkt über seinen unqualifizierten Namen angesprochen werden. In allen anderen
Paketen, die werkzeuge nicht importieren, kann seine Referenzierung nur über den
qualifizierten Namen werkzeuge::PdfErzeuger erfolgen.
Die importierten Elemente sind im importierenden Paket als öffentlich sichtbar. Damit kann ein weiteres Paket die Elemente erneut importieren (siehe Abbildung 7.8).
Im Paket restaurantkette aus Abbildung 7.8 kann PdfErzeuger direkt über seinen
unqualifizierten Namen angesprochen werden. Er ist sowohl in werkzeuge als auch im
restaurantsystem als öffentlich zugänglich und damit auch in restaurantkette verfügbar.
restaurantkette
restaurantsystem
werkzeuge
}
«import»
«import»
+ PdfErzeuger
Listing 7.5 /beispiele/c#/kap7/kap_7_3_1/Admin_Operationen.cs
Abbildung 7.8 Mehrfacher Paket-Import
192
193
7
Paketdiagramm
7.3
Um dies zu verhindern, bietet die UML den Paket-Accessals eine Einschränkung des
Paket-Imports.
restaurantkette
Paket-Import restaurantsystem
«import»
Paket-Access werkzeuge
renzierung über unqualifizierte Namen. Sie verdeutlichen auch die Struktur des
Modells und die Beziehungen der Pakete untereinander.
Soll der Zugriff auf die importierten Elemente in weiteren Paketen eingeschränkt
werden, ist die Access-Beziehung vorzuziehen.
+ PdfErzeuger
«access»
Realisierung in Java
Abbildung 7.9 Paket-Access
Ein Paket-Access (engl. PackageAccess) ist eine Beziehung, die alle Namen öffentlicher Elemente eines Pakets dem importierenden Paket als privat hinzufügt.
In Abbildung 7.9 importiert das Paket restaurantsystem alle Elementnamen des
Pakets werkzeuge über eine <<access>>-Beziehung, wodurch sie als privat (private)
deklariert werden.
Java enthält nativ keine Unterstützung des öffentlichen Imports von Paketen, der
mit dem Stereotyp <<import>> gekennzeichnet wird. Alle importierten Elementnamen sind nur im jeweils importierenden Paket verfügbar, was der <<access>>-Beziehung in der UML entspricht. Eine <<import>>-Beziehung muss daher in Java durch
<<access>>-Beziehungen ersetzt werden. Dies kann z. B. auf die in Abbildung 7.11 dargestellte Art durchgeführt werden:
restaurantkette
Etwas kompakter kann die <<import>>- und <<access>>-Beziehung auch innerhalb
von Paketen notiert werden (siehe Abbildung 7.10). Die Elemente müssen dabei über
ihre qualifizierten Namen eindeutig identifiziert werden:
restaurantsystem
restaurantsystem
«import»
Trotz der <<import>>-Beziehung zwischen restaurantkette und restaurantsystem
kann damit in restaurantkette kein Zugriff auf den PdfErzeuger über seinen unqualifizierten Namen erfolgen.
restaurantkette
Notationselemente
restaurantkette
werkzeuge
«import»
restaurantsystem
«access»
+ PdfErzeuger
werkzeuge
«access»
+ PdfErzeuger
werkzeuge
«access»
{import restaurantsystem::*}
{access werkzeuge::PdfErzeuger}
+PdfErzeuger
Abbildung 7.11 Umwandlung von <<import>> in <<access>>
Abbildung 7.10 Alternative Notation für Paket-Import und -Access
Das Paket restaurantkette aus Abbildung 7.10 importiert alle Elemente des Pakets
restaurantsystem, was an dem notierten * (Stern) hinter restaurantsystem zu erkennen ist. Das Paket restaurantsystem macht dagegen von der Möglichkeit Gebrauch,
das zu importierende Element genau zu spezifizieren, indem es explizit den PdfErzeuger aus dem Paket werkzeuge benennt. Eventuelle weitere Elemente von werkzeuge
werden nicht importiert.
Verwendung
Verwenden Sie Paket-Importe, wenn Sie Elemente eines Pakets häufig in weiteren
Paketen wiederverwenden möchten. Paket-Importe ermöglichen nicht nur die Refe-
194
Im oberen Teil der Abbildung 7.11 kann vom Paket restaurantkette sowohl auf die
(nicht gezeigten) Bestandteile von restaurantsystem als auch auf die von werkzeuge
über deren unqualifizierte Namen zugegriffen werden.
Um vergleichbare Zugriffsmöglichkeiten mithilfe von <<access>>-Beziehungen zu
modellieren, muss von jedem einzelnen Paket zu allen zuvor direkt oder indirekt
über <<import>>-Beziehungen erreichbaren Paketen eine eigene <<access>>-Beziehung modelliert werden (unterer Teil von Abbildung 7.11).
Es muss jedoch darauf hingewiesen werden, dass der obere und untere Teil der Abbildung 7.11 nicht exakt äquivalent sind: Ein weiteres Paket, das restaurantkette importiert, hätte im oberen Teil der Abbildung direkten Zugriff auf PdfErzeuger, im unteren
Teil nicht.
195
7
Paketdiagramm
7.3
Als Vorlage für die Java-Realisierung soll das folgende Paketdiagramm verwendet
werden:
Notationselemente
C: Unterpakete werden in Java mit dem Punkt-Operator referenziert. Das an dieser
Stelle verwendete *-Zeichen stellt in Java eine Art Joker dar, durch den alle Klassennamen des Pakets importiert werden.
werkzeuge
restaurantsystem
Realisierung in C#
xml
+ Restaurant
«access»
+ PdfErzeuger
+ XmlErzeuger
Auch C# unterstützt die <<import>>-Beziehung nicht. Der folgende Programmcode
realisiert das Diagramm aus Abbildung 7.12:
A namespace restaurantsystem
{
Abbildung 7.12 Beispiel für einen Paket-Import
B
using werkzeuge;
using werkzeuge.xml;
A package restaurantsystem;
public class Restaurant
{
PdfErzeuger p = new PdfErzeuger();
XmlErzeuger x = new XmlErzeuger();
}
B import werkzeuge.PdfErzeuger;
C import werkzeuge.xml.*;
public class Restaurant
{
PdfErzeuger p = new PdfErzeuger();
XmlErzeuger x = new XmlErzeuger();
}
Listing 7.6 /beispiele/java/kap7/restaurantsystem/Restaurant.java
}
Listing 7.7 /beispiele/c#/kap7/kap_7_3_2/Kap_7_3_2.cs
A: Die im Folgenden implementierten Klassen und Pakete befinden sich im Paket
(namespace) restaurantsystem.
B: C# verwendet das Schlüsselwort using, um einen Paket-Access zu deklarieren.
A: Die im Folgenden implementierte Klasse Restaurant befindet sich im Paket
restaurantsystem.
Es werden immer alle Klassennamen des Pakets importiert. Der Import eines einzelnen Klassennamens wird von C# nicht unterstützt.
B: Der Klassenname PdfErzeuger aus dem Paket werkzeuge wird in das aktuelle Paket
importiert. Im Unterschied zur UML, in der das Paket externe Elemente importiert, ist dies in Java die Aufgabe einer jeden Klasse des jeweiligen Pakets.
Der Zugriff auf Unterpakete erfolgt wie in Java mithilfe des Punkt-Operators.
Obwohl es sich im Sinne der UML streng genommen um eine <<access>>-Beziehung handelt, verwendet Java hierfür das Schlüsselwort import.
Es sollte an dieser Stelle nochmals betont werden, dass nicht die Klasse selbst, sondern nur deren Name importiert wird. Es wird also lediglich die Referenzierung
der Klasse über ihren unqualifizierten Namen PdfErzeuger ermöglicht. Wie von
der UML definiert, ist die Klasse auch ohne den Import über ihren qualifizierten
Namen werkzeuge.PdfErzeuger erreichbar.
7.3.3 Paket-Merge
Quellpaket
vipGaesteverwaltung
Zielpaket
Paket-Merge
gaesteverwaltung
«merge»
Abbildung 7.13 Paket-Merge
196
197
7
Paketdiagramm
7.3
Notationselemente
Was passiert aber, wenn beide Pakete bereits Elemente mit denselben Namen enthalten?
Beschreibung
Ein Paket-Merge (engl. PackageMerge) definiert eine Beziehung zwischen zwei Paketen, bei der die nicht privaten Inhalte des Zielpakets mit den Inhalten des Quellpakets
verschmolzen werden.
P1
Im Beispiel aus Abbildung 7.13 wird der Inhalt des Pakets gaesteverwaltung mit dem
Inhalt des Pakets vipGaesteverwaltung verschmolzen.
Im Prinzip stellt eine Merge-Beziehung eine verkürzende Notation für alle Transformationen dar, die bei der Verschmelzung des Zielpakets mit dem Quellpaket
benötigt werden. Das Beispiel aus Abbildung 7.14 verdeutlicht die prinzipielle Funktionsweise eines Paket-Merge und zeigt die entsprechenden Transformationen:
P2
A
«merge»
A
P1
P2::A
P1
P2
«merge»
A
A
B
Abbildung 7.15 Merge von Elementen mit demselben Namen
P1
P2::B
A
B
Die Pakete P1 und P2 enthalten im oberen Teil der Abbildung 7.15 beide ein Element A.
Bei einem Paket-Merge wird zwischen dem Element aus Paket P2 (P2::A) und dem Element aus Paket P1 (A) eine Generalisierungsbeziehung hinzugefügt, wie im unteren
Teil der Abbildung dargestellt ist.
Damit erweitert das Element A seine eigenen Attribute und Operationen durch diejenigen des Elements P2::A. Es entsteht somit ein neues Element, das nach den Regeln
der Generalisierung alle Attribute und Operationen der Elemente P1::A und P2::A
besitzt.
Abbildung 7.14 Merge zweier Pakete mit unterschiedlichen Elementen
Betrachten wir noch ein weiteres Beispiel, in dem ein leeres Paket zwei weitere Pakete
mergt, die beide dasselbe Element enthalten (siehe Abbildung 7.16).
Im oberen Teil der Abbildung 7.14 wird ein Paket-Merge des Pakets P2 in das Paket P1
modelliert. Paket P1 definiert ein Element A, Paket P2 ein Element B.
In Abbildung 7.16 werden die zwei Pakete P1 und P2, die jeweils ein Element A definieren, in ein leeres Paket P3 gemergt. Bei der Verschmelzung wird ein neues Element A definiert, das von P1::A und P2::A erbt und damit alle Attribute und
Operationen beider Elemente nach den Regeln der Generalisierung in sich vereinigt.
Der untere Teil der Abbildung zeigt die Auswirkungen des Merge auf das Paket P1.
Das ursprünglich bereits vorhandene Element A bleibt erwartungsgemäß erhalten.
Da das Element B zuvor nicht in P1 existierte, wird ein neues Element B definiert, das
das Element B des Pakets P2 (P2::B) spezialisiert und damit nach den Regeln der Generalisierung über alle Attribute und Operationen des Elements P2::B verfügt. (Generalisierung wurde in Abschnitt 2.3.12 vorgestellt.)
198
Es ist durchaus üblich, dass in den einzelnen Paketen bereits Generalisierungen und
Assoziationen definiert sind. Eine Merge-Beziehung verändert die Generalisierungen
und Assoziationen nicht.
199
7
Paketdiagramm
7.3
P1
P1
P2
A
Notationselemente
P2
B
B
A
C
A
P3
D
P3
«merge»
D
«merge»
«merge»
E
«merge»
P3
P3
P1::B
P1::A
P2::B
P2::A
B
A
P1::A
P2::C
P2::D
A
C
D
E
Abbildung 7.16 Ein leeres Paket mergt Elemente mit demselben Namen.
Sie verändert lediglich die Elemente, die an ihnen teilnehmen, was am Beispiel der
Abbildung 7.17 verdeutlicht wird.
Abbildung 7.17 Merge von Elementen mit Generalisierungen und Assoziationen
Im oberen Teil der Abbildung 7.17 definiert Paket P1 ein Element B, das von A spezialisiert wird. Im Paket P2 wird dagegen B vom Element C spezialisiert, das wiederum eine
Assoziation zu D besitzt. Paket P3 mergt die beiden Pakete P1 und P2 und definiert
gleichzeitig zwei Elemente D und E, die miteinander durch eine Assoziation verbunden sind.
Im oberen Teil der Abbildung 7.18 beinhaltet das Paket P1 das Paket P3 nicht. Daher
wird beim Merge (unterer Teil der Abbildung) in P1 ein neues Paket P3 definiert, das
mit dem Unterpaket P3 aus P2 (P2::P3) eine Merge-Beziehung eingeht.
Der untere Teil der Abbildung 7.17 zeigt die fünf durch den Merge entstandenen
Elemente A, B, C, D und E. Deren Struktur hat sich durchaus verändert, die ursprünglichen Generalisierungen und Assoziationen (hervorgehoben) bleiben jedoch erhalten.
Wie durch dieses Beispiel angedeutet, folgen die Unterpakete bei Merge denselben
Regeln wie innere Elemente von Paketen. Während die Elemente durch die Verwendung von Generalisierungen verschmolzen werden, geschieht dies bei Paketen
durch Merge-Beziehungen.
200
Es bleibt noch zu klären, was bei einem Merge mit Paketen passiert, die selbst in weiteren Paketen enthalten sind. Den einfachsten Fall zeigt Abbildung 7.18.
201
7
Paketdiagramm
7.3
P1
Notationselemente
hung zwischen dem Quellpaket P1 und dem Paket P4, wie im unteren Teil von Abbildung 7.19 dargestellt ist.
P2
P3
Verwendung
«merge»
Merge-Beziehungen werden verwendet, wenn im Modell Pakete vorhanden sind,
deren Inhalte und Konzepte sich ergänzen und daher zu neuer Gesamtheit zusammengesetzt werden können.
Wie eingangs erwähnt, stellt eine Merge-Beziehung lediglich eine abkürzende Notation für Transformationen der einzelnen Elemente aus Paketen unter Zuhilfenahme
von Generalisierungen dar. Erkennen Sie, dass Bedarf an der Spezialisierung vieler
Objekte aus unterschiedlichen Paketen besteht, um ein ähnlich arbeitendes Paket zu
erhalten, können Sie die Merge-Beziehung einsetzen.
P1
P2::P3
Sie sollten die entstehende Vererbungshierarchie jedoch genau überprüfen, da mit
der Verwendung der Merge-Beziehung auch unerwünschte Effekte auftreten können
(Beispiel in Abbildung 7.20).
«merge»
P3
P1
P2
Abbildung 7.18 Merge eines Unterpakets
A
B
Weitere Beziehungen zwischen Paketen (<<import>> und <<access>>) bleiben bei
einem Paket-Merge erhalten:
B
A
P1
P2
P3
P4
P3
«merge»
«import»
«merge»
«merge»
P1
P2::P3
P4
P3
«merge»
«import»
P3
Abbildung 7.19 Import-Beziehungen bleiben beim Merge erhalten.
Der obere Teil der Abbildung 7.19 modelliert ein Merge zwischen dem Paket P1 und
dem Paket P2, das seinerseits P4 importiert.
Trotz des Merge muss die Import-Beziehung erhalten bleiben, da das Paket P2::P3
andernfalls nicht mehr funktionsfähig wäre. Daher entsteht eine <<import>>-Bezie-
202
P1::A
P2::A
P1::B
A
P2::B
B
FEHLER !!!
Abbildung 7.20 Gefahr der Merge-Beziehung
203
7
Paketdiagramm
7.5
Abbildung 7.20 zeigt zwei Pakete P1 und P2. Im Paket P1 spezialisiert das Element B ein
Element A, in Paket P2 ist es genau umgekehrt: A spezialisiert B.
restaurantsystem
Irrungen und Wirrungen
gaesteverwaltung
Werden die beiden Pakete mithilfe der Merge-Beziehung in Paket P3 verschmolzen,
entsteht eine fehlerhafte Generalisierungshierarchie, in der sowohl A von B als auch
B von A erbt, wovor bereits in Abschnitt 2.5, »Irrungen und Wirrungen«, gewarnt
wurde.
Gast
#
#
kundennummer
umsatz: float = 0
Verwenden Sie die Merge-Beziehung daher nur mit großer Vorsicht.
«import»
Realisierung in Java
Java bietet kein Sprachmittel, das einem Paket-Merge entspräche, sodass die entstehende Hierarchie der Generalisierungen einzeln realisiert werden muss. Wie man in
Java eine Generalisierung implementiert, wird in Abschnitt 2.3.12 erläutert.
werkzeuge
«access»
«access»
«merge»
+ PdfErzeuger
Realisierung in C#
Für C# gilt bei der Merge-Beziehung dasselbe wie für Java.
datenverwaltung
datenbank
vipGaesteverwaltung
datenpflege
Gast
7.4 Lesen eines Paketdiagramms
#
#
Das Paketdiagramm aus Abbildung 7.21 definiert sieben Pakete:
lieblingswein
leibgericht
왘 restaurantsystem
왘 gaesteverwaltung
왘 werkzeuge
Abbildung 7.21 Beispiel für ein Paketdiagramm
왘 datenverwaltung mit zwei Unterpaketen datenbank und datenpflege
왘 vipGaesteverwaltung
Das Paket restaurantsystem importiert den Klassennamen PdfErzeuger aus dem
Paket werkzeuge als öffentlich, die Bestandteile der datenverwaltung als privat. Damit
wird der direkte Zugriff auf Elemente der datenverwaltung von allen weiteren Paketen, die restaurantsystem importieren, verboten.
Auch das Paket gaesteverwaltung importiert die datenverwaltung als privat und verbietet damit allen weiteren Paketen den direkten Zugriff.
Die Klasse Gast ist sowohl im Paket gaesteverwaltung als auch in vipGaesteverwaltung
enthalten. Da beide Pakete unterschiedliche Namensräume definieren, entsteht
dadurch kein Namenskonflikt.
Das Paket vipGaesteverwaltung mergt jedoch die gaesteverwaltung, wodurch eine
Generalisierung zwischen den beiden Gast-Klassen definiert wird und die Klasse vipGaesteverwaltung::Gast alle Attribute der Klasse gaesteverwaltung::Gast erbt.
204
7.5 Irrungen und Wirrungen
Abbildung 7.22 zeigt eine Auswahl der häufigsten Fehler bei der Modellierung mit
Paketdiagrammen:
A: Paketname fehlt
Pakete müssen mit Namen eindeutig definiert werden.
B: Bezeichnung der Beziehung fehlt
Definieren Sie die Art der modellierten Beziehung. Handelt es sich um eine
<<import>>-, <<access>>- oder eine <<merge>>-Beziehung?
C: Zirkulare <<merge>>-Beziehung
Zwei Pakete dürfen sich nicht gegenseitig mergen. Achten Sie auch darauf, dass
keine zirkulare Beziehung zwischen mehreren Paketen entsteht, die möglicherweise nicht so einfach zu erkennen ist wie in diesem Beispiel.
205
7
Paketdiagramm
7.6
D: Ungültige <<merge>>-Beziehung
Die <<merge>>-Beziehung darf nur zwischen Paketen modelliert werden. Ein
Merge einer Klasse mit einem Paket ist nicht definiert.
Zusammenfassung
Paketname
restaurantsystem
E: Falsche Hierarchie
Klassen können weitere Klassen, jedoch keine Pakete enthalten. Andersherum ist
es Paketen durchaus gestattet, Klassen in sich zu gruppieren.
Paket
A
Abbildung 7.23 Paket
gaesteverwaltung
Gast
#
#
kundennummer
umsatz: float = 0
왘 Ein Paket-Import importiert alle Namen des importierten Pakets als öffentlich,
ein Paket-Access als privat.
importiertes Paket
D
importierendes Paket
werkzeuge
«merge»
B
Werkzeuge
«access»
xml
restaurantsystem
C
Paket-Import
«import»
«merge»
«access»
«merge»
E
datenverwaltung
Paket-Access
Abbildung 7.24 Paket-Import und -Access
datenverwaltung
datenbank
vipGaesteverwaltung
왘 Mithilfe eines Paket-Merge können die Inhalte von Paketen verschmolzen
datenpflege
Gast
#
#
lieblingswein
leibgericht
werden.
Quellpaket
vipGaesteverwaltung
Paket-Merge
gaesteverwaltung
«merge»
Abbildung 7.22 Ein fehlerhaftes Paketdiagramm
7.6 Zusammenfassung
Zielpaket
Abbildung 7.25 Paket-Merge
Abschließend werden die wichtigsten Notationselemente kurz aufgeführt:
왘 Pakete gruppieren Elemente wie Klassen oder weitere Pakete und definieren
Namensräume.
206
207
Auf einen Blick
Auf einen Blick
1
Einführung ...............................................................................................................
17
TEIL I Strukturdiagramme ............................................................................................
33
2
Klassendiagramm ..................................................................................................
35
3
Objektdiagramm .................................................................................................... 121
4
Kompositionsstrukturdiagramm ..................................................................... 135
5
Komponentendiagramm .................................................................................... 157
6
Verteilungsdiagramm .......................................................................................... 173
7
Paketdiagramm ...................................................................................................... 185
TEIL II Verhaltensdiagramme ..................................................................................... 209
8
Anwendungsfalldiagramm ................................................................................ 211
9
Aktivitätsdiagramm .............................................................................................. 227
10
Zustandsdiagramm ............................................................................................... 309
TEIL III Interaktionsdiagramme .................................................................................. 357
11
Sequenzdiagramm ................................................................................................ 359
12
Kommunikationsdiagramm ............................................................................... 399
13
Timing-Diagramm ................................................................................................. 409
14
Interaktionsübersichtsdiagramm .................................................................... 423
TEIL IV Metamodellierung ........................................................................................... 433
15
Profildiagramm ...................................................................................................... 435
Inhalt
Inhalt
Vorwort ..................................................................................................................................................
13
1
Einführung
17
1.1
Weshalb muss Software modelliert werden? ........................................................
17
1.2
Die Phasen bei der Softwareentwicklung ................................................................
18
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
Analyse ....................................................................................................................
Entwurf ....................................................................................................................
Implementierung und Dokumentation ........................................................
Test ...........................................................................................................................
Einsatz ......................................................................................................................
Wartung und Pflege ............................................................................................
18
19
19
20
20
20
1.3
Was ist die UML? .................................................................................................................
20
1.4
Die Geschichte der UML ...................................................................................................
21
1.5
Von der UML 1.x zur UML 2.5 ..........................................................................................
23
1.6
Diagramme der UML 2.5 ...................................................................................................
25
TEIL I
2
Strukturdiagramme
Klassendiagramm
35
2.1
Anwendungsbereiche .......................................................................................................
35
2.2
Übersicht .................................................................................................................................
36
2.3
Notationselemente ............................................................................................................
37
2.3.1
2.3.2
Klasse .......................................................................................................................
Attribut ....................................................................................................................
37
39
2.3.3
2.3.4
2.3.5
2.3.6
2.3.7
2.3.8
Operation ................................................................................................................
Binäre Assoziation ...............................................................................................
Reflexive Assoziation ..........................................................................................
N-äre Assoziation .................................................................................................
Qualifizierte Assoziation ...................................................................................
Assoziationsklasse ...............................................................................................
45
55
63
64
68
70
5
Inhalt
Inhalt
4.4
Lesen eines Kompositionsstrukturdiagramms ......................................................
151
4.5
Irrungen und Wirrungen ..................................................................................................
153
4.6
Zusammenfassung .............................................................................................................
154
5
Komponentendiagramm
157
5.1
Anwendungsbereiche .......................................................................................................
157
111
5.2
Überblick .................................................................................................................................
157
Irrungen und Wirrungen ..................................................................................................
114
5.3
Notationselemente ............................................................................................................
159
Zusammenfassung .............................................................................................................
116
5.3.1
5.3.2
Komponente ..........................................................................................................
Konnektor ...............................................................................................................
159
163
5.3.3
Artefakt ....................................................................................................................
165
5.4
Lesen eines Komponentendiagramms ......................................................................
167
5.5
Irrungen und Wirrungen ..................................................................................................
169
5.6
Zusammenfassung .............................................................................................................
170
2.3.9
2.3.10
2.3.11
2.3.12
2.3.13
2.3.14
2.3.15
2.3.16
2.3.17
Aggregation ...........................................................................................................
Komposition ..........................................................................................................
Abhängigkeit .........................................................................................................
Generalisierung/Spezialisierung ....................................................................
Stereotyp .................................................................................................................
Abstrakte Klasse ...................................................................................................
Template .................................................................................................................
Schnittstelle ...........................................................................................................
Anmerkung ............................................................................................................
72
76
79
82
92
95
98
105
110
2.4
Lesen eines Klassendiagramms ....................................................................................
2.5
2.6
3
Objektdiagramm
121
3.1
Anwendungsbereiche .......................................................................................................
121
3.2
Übersicht .................................................................................................................................
121
3.3
Notationselemente ............................................................................................................
122
3.3.1
3.3.2
Objekt .......................................................................................................................
Link ............................................................................................................................
122
127
6
Verteilungsdiagramm
173
3.4
Lesen eines Objektdiagramms ......................................................................................
130
6.1
Anwendungsbereiche .......................................................................................................
173
3.5
Irrungen und Wirrungen ..................................................................................................
131
6.2
Übersicht .................................................................................................................................
173
3.6
Zusammenfassung .............................................................................................................
133
6.3
4
Kompositionsstrukturdiagramm
135
4.1
Anwendungsbereiche .......................................................................................................
135
4.2
Übersicht .................................................................................................................................
135
Notationselemente ............................................................................................................
136
4.3.1
4.3.2
4.3.3
4.3.4
136
139
147
149
4.3
6
Part ............................................................................................................................
Port und Konnektor .............................................................................................
Kollaboration .........................................................................................................
Kollaborationsanwendung ...............................................................................
Notationselemente ............................................................................................................
174
6.3.1
6.3.2
Knoten .....................................................................................................................
Kommunikationspfad ........................................................................................
174
179
6.4
Lesen eines Verteilungsdiagramms ............................................................................
180
6.5
Irrungen und Wirrungen ..................................................................................................
181
6.6
Zusammenfassung .............................................................................................................
183
7
Paketdiagramm
185
7.1
Anwendungsbereiche .......................................................................................................
185
7.2
Übersicht .................................................................................................................................
185
7
Inhalt
Inhalt
7.3
Notationselemente ............................................................................................................
186
7.3.1
7.3.2
7.3.3
Paket .........................................................................................................................
Paket-Import ..........................................................................................................
Paket-Merge ...........................................................................................................
186
193
197
7.4
Lesen eines Paketdiagramms ........................................................................................
204
7.5
Irrungen und Wirrungen ..................................................................................................
205
7.6
Zusammenfassung .............................................................................................................
206
TEIL II
8
Verhaltensdiagramme
Anwendungsfalldiagramm
211
9.3.3
9.3.4
9.3.5
9.3.6
9.3.7
9.3.8
9.3.9
9.3.10
9.3.11
9.3.12
9.3.13
Aktivitätsbereich ..................................................................................................
Objektknoten und Objektfluss ........................................................................
Signal-Sendung und Signal-Empfang ...........................................................
Aktivität ...................................................................................................................
Start- und Endknoten .........................................................................................
Entscheidungs- und Verbindungsknoten ....................................................
Gabelung und Vereinigung ..............................................................................
Schleifenknoten ....................................................................................................
Bedingungsknoten ..............................................................................................
Unterbrechungsbereich .....................................................................................
Expansionsbereich ...............................................................................................
233
236
249
259
265
267
273
281
287
292
297
9.4
Lesen eines Aktivitätsdiagramms ................................................................................
299
9.5
Irrungen und Wirrungen ..................................................................................................
301
9.6
Zusammenfassung .............................................................................................................
304
8.1
Anwendungsbereiche .......................................................................................................
211
8.2
Übersicht .................................................................................................................................
212
8.3
Notationselemente ............................................................................................................
212
10 Zustandsdiagramm
309
8.3.1
8.3.2
Systemgrenze ........................................................................................................
Akteur .......................................................................................................................
212
213
10.1 Anwendungsbereiche .......................................................................................................
309
8.3.3
8.3.4
8.3.5
8.3.6
8.3.7
Anwendungsfall ...................................................................................................
Assoziation .............................................................................................................
Generalisierung/Spezialisierung ....................................................................
Include-Beziehung ...............................................................................................
Extend-Beziehung ................................................................................................
215
216
217
219
220
10.2 Übersicht .................................................................................................................................
310
10.3 Notationselemente ............................................................................................................
311
8.4
Lesen eines Anwendungsfalldiagramms ..................................................................
221
8.5
Irrungen und Wirrungen ..................................................................................................
223
8.6
Zusammenfassung .............................................................................................................
224
9
Aktivitätsdiagramm
227
9.1
Anwendungsbereiche .......................................................................................................
227
9.2
Übersicht .................................................................................................................................
228
9.3
Notationselemente ............................................................................................................
230
9.3.1
9.3.2
231
232
8
Aktion .......................................................................................................................
Kontrollfluss ...........................................................................................................
10.3.1
10.3.2
10.3.3
10.3.4
10.3.5
10.3.6
10.3.7
10.3.8
10.3.9
10.3.10
10.3.11
Zustand ...................................................................................................................
Event und Transition ...........................................................................................
Startzustand, Endzustand und Terminator .................................................
Entscheidung und Kreuzung ............................................................................
Zusammengesetzter Zustand ..........................................................................
Region ......................................................................................................................
Rahmen eines Zustandsautomaten ..............................................................
Generalisierung/Spezialisierung ....................................................................
Zustandsdiagramm in Java ...............................................................................
Zustandsdiagramm in C# ..................................................................................
Protokoll-Zustandsautomat .............................................................................
311
312
319
320
322
326
328
330
332
340
348
10.4 Lesen eines Zustandsdiagramms .................................................................................
350
10.5 Irrungen und Wirrungen ..................................................................................................
351
10.6 Zusammenfassung .............................................................................................................
353
9
Inhalt
Inhalt
TEIL III
Interaktionsdiagramme
13.3.2
13.3.3
13.3.4
13.3.5
Lebenslinie ..............................................................................................................
Zustandsverlaufslinie .........................................................................................
Wertverlaufslinie .................................................................................................
Nachricht ................................................................................................................
411
412
414
415
11 Sequenzdiagramm
359
11.1 Anwendungsbereiche .......................................................................................................
359
13.4 Lesen eines Timing-Diagramms ...................................................................................
418
11.2 Übersicht .................................................................................................................................
360
13.5 Irrungen und Wirrungen ..................................................................................................
419
11.3 Notationselemente ............................................................................................................
361
13.6 Zusammenfassung .............................................................................................................
420
14 Interaktionsübersichtsdiagramm
423
11.3.1
11.3.2
11.3.3
11.3.4
Lebenslinie ..............................................................................................................
Nachricht ................................................................................................................
Interaktionsrahmen ............................................................................................
Kombinierte Fragmente ....................................................................................
361
364
370
375
11.4 Lesen eines Sequenzdiagramms ..................................................................................
391
14.1 Anwendungsbereiche .......................................................................................................
423
11.5 Irrungen und Wirrungen ..................................................................................................
393
14.2 Übersicht .................................................................................................................................
423
11.6 Zusammenfassung .............................................................................................................
395
14.3 Notationselemente ............................................................................................................
14.3.1
14.3.2
14.3.3
14.3.4
425
Interaktionsrahmen ............................................................................................
Interaktion und Interaktionsreferenz ...........................................................
Kontrollfluss ...........................................................................................................
Kontrollknoten ......................................................................................................
425
425
426
427
12 Kommunikationsdiagramm
399
12.1 Anwendungsbereiche .......................................................................................................
399
14.4 Lesen eines Interaktionsübersichtsdiagramms .....................................................
428
12.2 Übersicht .................................................................................................................................
399
14.5 Irrungen und Wirrungen ..................................................................................................
429
12.3 Notationselemente ............................................................................................................
400
14.6 Zusammenfassung .............................................................................................................
430
12.3.1
12.3.2
Interaktionsrahmen ............................................................................................
Lebenslinie ..............................................................................................................
400
401
12.3.3
Nachricht ................................................................................................................
401
12.4 Lesen eines Kommunikationsdiagramms ................................................................
405
12.5 Irrungen und Wirrungen ..................................................................................................
405
12.6 Zusammenfassung .............................................................................................................
407
13 Timing-Diagramm
409
13.1 Anwendungsbereiche .......................................................................................................
409
13.2 Übersicht .................................................................................................................................
409
13.3 Notationselemente ............................................................................................................
410
13.3.1
10
Interaktionsrahmen ............................................................................................
TEIL IV
Metamodellierung
15 Profildiagramm
435
15.1 Anwendungsbereiche .......................................................................................................
435
15.2 Übersicht .................................................................................................................................
436
15.3 Notationselemente ............................................................................................................
15.3.1
15.3.2
15.3.3
15.3.4
Metamodell, Profil und Metamodell-Referenz ..........................................
Metaklasse .............................................................................................................
Stereotyp und Erweiterung ..............................................................................
Profilanwendung .................................................................................................
437
437
439
440
443
410
11
Inhalt
15.4 Lesen eines Profildiagramms .........................................................................................
445
15.5 Irrungen und Wirrungen ..................................................................................................
447
15.6 Zusammenfassung .............................................................................................................
448
Index ........................................................................................................................................................
451
12
Index
Index
{complete} .................................................................. 85
{composite} ............................................................... 43
{disjoint} ..................................................................... 85
{extended} ............................................................... 331
{final} ......................................................................... 331
{incomplete} .............................................................. 85
{nonunique} ....................................................... 43, 58
{ordered} .............................................................. 42, 57
{overlapping} ............................................................ 85
{protocol} ................................................................. 349
{readOnly} ........................................................... 41, 42
{redefines} ........................................................... 42, 57
{required} ................................................................ 441
{seq} ....................................................................... 42, 58
{sequence} ........................................................... 42, 58
{subsets} ............................................................... 42, 57
{union} .................................................................. 42, 57
<<abstract>> .............................................................. 95
<<access>> ........................................... 194, 202, 207
<<application server>> ...................................... 175
<<artifacts>> .......................................................... 162
<<auxilliary>> .......................................................... 93
<<bind>> .................................................................. 100
<<call>> ....................................................................... 80
<<centralBuffer>> ...................................... 241, 242
<<client workstation>> ..................................... 176
<<create>> .................................................................. 80
<<custom code>> ................................................. 167
<<datastore>> ........................................................ 242
<<dataType>> ........................................................... 94
<<delegate>> .......................................................... 164
<<deploy>> ............................................................. 177
<<deployment spec>> ........................................ 178
<<derive>> ................................................................. 80
<<device>> .............................................................. 175
<<document>> ...................................................... 166
<<embedded device>> ....................................... 176
<<entity>> ............................................................... 161
<<enumeration>> ................................................... 94
<<executable>> ..................................................... 166
<<execution environment>> .......................... 175
<<extend>> ................................................... 220, 226
<<external>> .......................................................... 235
<<file>> ..................................................................... 166
<<focus>> ................................................................... 93
<<implement>> .................................................... 161
<<implementation class>> ................................. 93
<<import>> ......................................... 193, 202, 207
<<include>> .................................................. 219, 226
<<instantiate>> ............................................. 80, 123
<<interface>> ................................................. 93, 105
<<library>> ............................................................. 166
<<manifest>> ........................................................ 166
<<merge>> .................................................... 197, 207
<<metaclass>> ...................................................... 439
<<metamodel>> ................................................... 437
<<mobile device>> .............................................. 176
<<permit>> ................................................................ 80
<<postcondition>> ............................................. 259
<<precondition>> ................................................ 259
<<process>> ........................................................... 161
<<profile>> ............................................................. 437
<<provided interfaces>> ................................... 160
<<realization>> ..................................................... 162
<<refine>> ................................................................. 80
<<required interfaces>> .................................... 160
<<script>> ............................................................... 166
<<selection>> ........................................................ 241
<<service>> ............................................................ 162
<<source>> ............................................................. 166
<<specification>> ................................................ 161
<<substitute>> ......................................................... 80
<<subsystem>> .................................................... 162
<<tool-generated>> ............................................ 167
<<trace>> ................................................................... 80
<<type>> ..................................................................... 93
<<use>> .................................................... 81, 106, 159
<<utility>> ................................................................. 93
A
Abbruch .......................................................... 375, 389
Abgeleitete Klasse .................................................. 82
Abhängigkeit ............................................................ 79
Abstract Class ........................................................... 95
Abstrakte Klasse ............................................ 95, 117
AcceptEventAction ............................................. 249
Access-Beziehung ....................................... 194, 207
ACID-Prinzip .......................................................... 161
Action ....................................................................... 231
Activity ..................................................................... 259
Activity Diagram ........................................... 29, 227
ActivityEdge ........................................................... 230
ActivityFinalNode ............................................... 266
451
Index
Index
ActivityNode .......................................................... 230
ActivityPartition ................................................... 234
Actor .......................................................................... 213
Aggregation .............................................. 72, 78, 118
Akteur ............................................................. 213, 225
Aktion ............................................................. 231, 304
Aktionssequenz .................................................... 315
Aktiver Zustand .................................................... 311
Aktivität ......................................................... 259, 304
Aktivitätsaufruf .................................................... 259
Aktivitätsbereich ........................................ 233, 305
Aktivitätsdiagramm .................. 29, 227, 359, 423
Aktivitätsende .................................... 265, 266, 305
Aktivitätskante ...................................................... 230
Aktivitätsknoten ........... 230, 232, 234, 236, 259,
261, 292, 304, 305
All (AnyEvent) ........................................................ 314
Allgemeine Klasse ................................................... 82
Alternative .................................................... 375, 376
alt-Fragment .......................................................... 376
Analyse/Definition .................... 18, 227, 359, 360
Analyse-Phase ............................................. 227, 359
Anmerkung .................................................. 110, 119
Antwort-Nachricht .............................................. 367
Anwendungsfall ......................................... 215, 225
Anwendungsfalldiagramm ....................... 29, 211
AnyReceiveEvent ................................................. 314
Architekturdiagramm ........................................ 135
Artefakt ....................................... 165, 171, 177, 183
Artifact ...................................................................... 165
Assembly Connector .......................................... 163
assert-Fragment .................................................... 385
Assertion ................................................................. 385
Association ............................................................. 217
AssociationClass ...................................................... 70
Assoziation ................ 55, 117, 127, 179, 216, 225
Assoziationsklasse .................................................. 70
Assoziationsname .................................................. 56
Asynchrone Nachricht ....................................... 365
Attribut ........................................... 37, 116, 123, 176
Attributwert ........................................................... 123
Attributzuweisung .............................................. 368
Ausführbarer Knoten ......................................... 230
Ausführungsbalken ............................................ 361
Ausführungsumgebung .................................... 175
Ausgabeparameter .................................... 236, 260
Ausgangskollektion ............................................ 298
Ausnahme ............................................................... 386
Ausprägung ............................................................... 38
Austritt über Endzustand ................................. 325
452
Austritt über Terminator ................................. 325
Austrittspunkt ................................... 326, 328, 329
B
Ball-and-Socket-Symbol ........................... 106, 163
Ball-Symbol ................................................... 106, 160
Basisklasse ................................................................. 82
Bauteilkonnektor ................................................. 163
Bedingungsknoten ..................................... 287, 307
Behavior Port ........................................................ 141
Benötigte Schnittstelle ...................................... 106
Besitzanzeige ............................................................ 60
Binäre Assoziation ................................................. 55
Binary Association ................................................. 55
Binden ...................................................................... 100
Black-Box-Sicht ..................................................... 160
Booch, Grady ..................................................... 22, 23
Booch-Methode ....................................................... 22
break-Fragment .................................................... 389
C
CallEvent ................................................................. 312
CASE-Werkzeuge .................................... 19, 22, 114
CentralBuffer ......................................................... 241
ChangeEvent ................................................. 313, 314
Choice ....................................................................... 320
Class Diagram .................................................... 25, 35
Client-Supplier-Beziehung ................................. 79
Coad, Peter ................................................................. 22
Collaboration ......................................................... 147
CollaborationUse ................................................. 149
CombinedFragment ........................................... 375
Communication Diagram ......................... 31, 399
CommunicationPath ......................................... 179
Complex Port ........................................................ 141
Component ............................................................ 159
Component Diagram .................................. 28, 157
Composite State ................................................... 323
Composite Structure Diagram ................ 27, 135
Computer Aided Software Engineering ........ 19
ConditionalNode ................................................. 287
Connector ...................................................... 139, 232
consider-Fragment ............................................. 387
content ..................................................................... 442
Continuation ......................................................... 377
ControlFlow ........................................................... 232
ControlNode .......................................................... 230
Coregion .................................................................. 381
Coregion Area ........................................................ 381
Critical Region ....................................................... 384
critical-Fragment .................................................. 384
D
Datenspeicher ....................................................... 242
Datenstrom ............................................................ 238
DecisionNode ........................................................ 267
Deep History .......................................................... 324
Deep History Entry .............................................. 324
Default Entry .......................................................... 324
Default-Zustand .................................................... 319
Defer .......................................................................... 317
Definition-Phase .................................................. 227
Dekomposition ..................................................... 362
Delegate ................................................................... 257
Delegation Connector ........................................ 164
Delegationskonnektor .......... 163, 164, 171, 257
Dependency .............................................................. 79
Deployment Diagram ................................. 28, 173
DeploymentSpecification ................................ 178
Design Pattern ............................................. 148, 251
Design-Phase ...................................... 157, 228, 359
Destruktionsnachricht ...................................... 368
Do-Aktion ................................................................ 317
Do-Bereich .............................................................. 281
Drei Amigos ............................................................... 23
Drei-Schichten-Architektur ............................. 157
Dynamische Verzweigung ..................... 320, 355
Dynamisches Binden ............................................ 83
Entscheidung ............................................... 320, 355
Entscheidungsgrundlage ................................. 268
Entscheidungsknoten ............ 267, 306, 427, 431
Entwurf/Design ................... 18, 35, 228, 359, 360
Entwurf-Phase .............................................. 157, 228
Entwurfsmuster .......................................... 148, 251
Entwurfsphase ......................................................... 36
Ereignis .................................................................... 312
Erweiterung ........................................... 83, 440, 449
Erweiterungspunkt ............................................. 220
Erzeugungsnachricht ......................................... 368
Event ................................... 256, 312, 318, 349, 354
Exception ................ 242, 260, 267, 295, 296, 386
Exception-Handler .............................................. 242
Exception-Knoten ............................................... 260
Exception-Konzept .................................... 295, 296
Exception-Objekt ................................................. 242
Exception-Objektknoten .................................. 242
ExecutableNode ................................................... 230
ExecutionSpecification ..................................... 361
Exemplar ................................................................. 122
Exit Point ................................................................ 328
Exit Point Exit ....................................................... 326
Exit-Aktion ............................................................. 317
ExpansionRegion ................................................ 297
Expansionsbereich ..................................... 297, 308
Explicit Entry ......................................................... 324
Expliziter Eintritt ................................................. 324
Extend Relationship ........................................... 220
Extend-Beziehung ...................................... 220, 226
Extension ................................................................ 440
Extension Point .................................................... 220
E
Effekt ...................................................... 312, 315, 354
Eigenschaft ...... 41, 46, 47, 54, 57, 435, 440, 449
Eigenschaftswert ........................................... 40, 444
Eingabeparameter ..................................... 236, 260
Eingangskollektion ............................................. 298
Einsatzphase ............................................................. 36
Einsatzspezifikation ............................................ 178
Einschränkung ......................................................... 58
Eintrittspunkt ..................................... 325, 328, 329
Else-Guard ............................................................... 270
Elternklasse ............................................................... 82
Endknoten ........................ 265, 266, 305, 427, 431
Endzustand ....................... 319, 323, 327, 328, 354
Entry Point .............................................................. 328
Entry Point Entry ................................................. 325
Entry-Aktion .......................................................... 317
F
FIFO ........................................................................... 240
FinalState ................................................................ 319
First In First Out ................................................... 240
Flache Historie ...................................................... 324
FlowFinalNode ...................................................... 266
Flussende ............................................. 265, 266, 305
For-Bereich ............................................................. 281
Foreign Key ............................................................... 68
Fork ............................................................................ 327
ForkNode ................................................................. 274
format ...................................................................... 442
Fortsetzung ............................................................ 377
Found Message ..................................................... 369
Frame ........................................................................ 328
Fremdschlüssel ........................................................ 68
453
Index
Index
G
Gabel-Symbol ........................................................ 259
Gabelung ........................... 273, 306, 327, 427, 432
Gamma, Erich .............................................. 148, 251
Gang of Four ........................................................... 148
Ganzes-Teile-Beziehung ............................. 72, 118
Gate ............................................................................ 372
Gefundene Nachricht ......................................... 369
Generalisierung ................ 82, 118, 217, 225, 330
Generalisierungsgruppen ................................... 83
Generalization ................................................ 82, 217
GeneralizationSet ................................................... 83
GeneralOrdering ........................................ 380, 417
Generische Klasse ................................................... 99
Gerichtete Assoziation ......................................... 58
getter-Operation ..................................................... 48
Guard ....................... 268, 312, 314, 354, 376, 379,
388, 389, 403
InteractionUse ...................................................... 372
Interaktion .................................................... 425, 430
Interaktionsdiagramm ..................... 30, 357, 399,
409, 423
Interaktions-Operand ........................................ 375
Interaktions-Operator ....................................... 375
Interaktionspunkt ............................................... 139
Interaktionsrahmen .... 370, 372, 396, 400, 407,
410, 421, 425, 430
Interaktionsreferenz ....................... 372, 425, 430
Interaktionsübersichtsdiagramm 31, 370, 423
Interface .................................................................. 105
Interne Aktion ...................................................... 317
InterruptibleActivityRegion ........................... 292
in-Übergabemodus ................................................ 46
Invariante ............................................................... 349
Irrelevante Nachrichten ........................... 375, 387
Ist-Ein-Beziehung ................................................... 83
Iterative ................................................................... 299
Iteratives Versenden .......................................... 404
H
H (Flache Historie) ............................................... 324
H* (Tiefe Historie) ................................................ 324
Helm, Richard .............................................. 148, 251
Horizontale Strukturierung ............................ 185
I
Icon ............................................................................ 441
If-Bereich ................................................................. 287
If-then-else Konstrukt ........................................ 292
ignore-Fragment .................................................. 387
Implementierungsphase .......... 18, 36, 228, 360
Import-Beziehung ..................................... 193, 207
Include Relationship ........................................... 219
Include-Beziehung .................................... 219, 226
Initial ......................................................................... 319
Initialisierung ........................................................ 281
InitialNode .............................................................. 265
inout-Übergabemodus ......................................... 47
InputParameters .................................................. 260
Instanz ............................................................... 38, 122
Instanzattribut ......................................................... 39
Instanziierung ................................................ 38, 123
Instanzoperation ..................................................... 46
Interaction Diagram .............................................. 30
Interaction Frame ................................................ 370
Interaction Overview Diagram ............... 32, 423
InteractionOperand ............................................ 375
InteractionOperator ........................................... 375
454
J
Jacobson, Ivar .................................................... 22, 23
Johnson, Ralph ............................................. 148, 251
Join ............................................................................. 327
JoinNode .................................................................. 274
JoinSpec ................................................................... 274
Junction ................................................................... 320
K
Kindklasse .................................................................. 82
Klasse ................................................................. 37, 116
Klassenattribut ........................................................ 39
Klassendiagramm ................................. 25, 35, 121
Klassenoperation .................................................... 46
Knoten ............................................................ 174, 183
Kollaboration ............................................... 147, 155
Kollaborationsanwendung .............................. 155
Kollaborationsausprägung .............................. 149
Kombinierte Fragmente .......................... 375, 396
Kommunikationsdiagramm .......... 31, 370, 399,
409, 423
Kommunikationskanal ..................................... 180
Kommunikationspfad .............................. 179, 183
Kommunikationsprotokoll ............................. 350
Komplexer Port .................................................... 141
Komponente ................................................ 159, 170
Komponentendiagramm .......................... 28, 157
Komponentenkonnektor ................................. 163
Komposition ............................................ 76, 78, 118
Kompositionskonnektor .................................. 163
Kompositionsstrukturdiagramm .......... 27, 135
Konnektor ......................... 139, 147, 154, 163, 232
Konstruktor ............................................................... 44
Kontrollfluss ............................. 232, 304, 426, 431
Kontrollknoten ........................................... 230, 427
Körper ....................................................................... 287
Kreuzung ....................................................... 320, 355
Kritischer Bereich ...................................... 375, 384
Kunde-Dienstleister-Beziehung ....................... 79
n-ary Association .................................................... 64
Navigierbarkeit ........................................................ 58
Negation ......................................................... 375, 383
Negative ................................................................... 383
neg-Fragment ........................................................ 383
new-Operator ..................................... 125, 127, 129
Node .......................................................................... 174
Notation ..................................................................... 20
Notationselemente ................................................ 20
Note ........................................................................... 110
n-zu-m-Assoziation ............................................... 68
L
O
Last In First Out ..................................................... 240
Lebenslinie .............. 361, 395, 401, 407, 411, 421
Leserichtung ............................................................. 56
Lifeline ...................................................................... 361
LIFO ............................................................................ 240
Link .................................................................. 127, 133
LocalPostcondition ............................................. 231
LocalPrecondition ............................................... 231
location .................................................................... 442
Lokale Nachbedingung ...................................... 231
Lokale Vorbedingung ......................................... 231
loop-Fragment ...................................................... 388
LoopNode ................................................................ 281
Lost Message .......................................................... 369
Manifestation ........................................................ 167
many-to-many Association ................................ 68
Mehrfachvererbung ............................................... 86
Merge-Beziehung ....................................... 197, 207
MergeNode ............................................................. 268
Message .................................................................... 364
Message Label ........................................................ 416
Metaklasse ........................................... 435, 439, 449
Metaklassen-Referenz ........................................ 438
Metamodell .................................................. 437, 448
Metamodell-Referenz .............................. 437, 448
Multiplizität .............. 40, 41, 46, 47, 56, 137, 180
Oberklasse ................................................................. 82
Object Diagram .............................................. 27, 121
Object Management Group ......................... 21, 23
Object Modeling Technique ............................... 22
ObjectFlow .............................................................. 236
ObjectNode ................................................... 230, 236
Object-Oriented Analysis .................................... 22
Object-Oriented Software Engineering ......... 22
Objekt .............................................................. 122, 133
Objektdiagramm ........................................... 27, 121
Objektfluss ..................................................... 236, 305
Objektknoten ..................................... 230, 236, 305
Observable .............................................................. 251
Observer ......................................................... 251, 252
Observerable .......................................................... 252
OMG ................................................................... 23, 435
OMT .............................................................................. 22
OOA .............................................................................. 22
OOSE ............................................................................ 22
Operation ......................................... 37, 45, 116, 312
opt-Fragment ........................................................ 378
Option ............................................................. 375, 378
Ordered .................................................................... 240
Ordering .................................................................. 240
Ordnungsangabe ................................................. 240
Ordnungsbeziehung ................................. 380, 417
out-Parameter ....................................................... 368
OutputParameters .............................................. 260
out-Übergabemodus ............................................. 46
N
P
Nachbedingung .......................................... 259, 349
Nachricht ................. 364, 395, 401, 408, 415, 422
Nachrichten-Label ............................................... 416
Namensraum ............................................... 187, 206
n-äre Assoziation .................................................... 64
Package .................................................................... 187
package ....................................................................... 40
Package Diagram .......................................... 28, 185
PackageAccess ....................................................... 194
PackageImport ...................................................... 193
M
455
Index
Index
PackageMerge ........................................................ 198
Paket ................................................................ 186, 206
Paket-Access ................................................. 194, 207
Paketdiagramm ............................................. 28, 185
Paket-Import ....................................... 193, 207, 438
Paket-Merge ................................................. 197, 207
Parallel ...................................................................... 299
Parallele Abläufe ................................................... 274
Parallelität ..................................................... 375, 379
Parameter-Liste ....................................................... 46
Parametersatz ....................................................... 238
ParameterSet ......................................................... 238
Parametrisierbare Klasse ..................................... 99
par-Fragment ......................................................... 380
Part ................................................................... 136, 154
PartDecomposition ............................................. 362
Partition ...................................................................... 84
Pin-Notation ....................................... 236, 237, 238
Polymorphismus .................................................... 83
Pop-Operation ............................................. 247, 248
Port ............................................... 139, 154, 159, 171
Postcondition .............................................. 259, 349
Precondition ................................................ 259, 349
Primitiver Datentyp ............................................... 51
private .......................................................................... 40
Profil ................................................................ 437, 448
Profilanwendung ....................................... 443, 449
Profildiagramm ............................................. 29, 435
Profile Diagram ........................................................ 29
ProfileApplication ............................................... 443
Properties ................................................................... 54
protected .................................................................... 40
ProtocolStateMachine ....................................... 348
Protokoll-Transition ........................................... 349
Protokoll-Zustandsautomat ............................ 348
Protokoll-Zustandsdiagramm .............. 309, 350
Provided Interface ............................................... 106
public ........................................................................... 40
Punkt-Notation ........................................................ 55
Push-Operation .......................................... 246, 248
Q
Qualified Association ............................................ 68
Qualifier ...................................................................... 68
Qualifizierer .............................................................. 68
Qualifizierte Assoziation ..................................... 68
Qualifizierter Name ............................................ 188
Quellzustand .......................................................... 312
456
R
Rahmen ................................................................... 328
Realisierte Schnittstelle .................................... 106
Realisierung .............................................................. 81
Realization ................................................................. 81
ref ............................................................................... 372
Referenz-Datentyp .......................................... 51, 54
Reflexive Assoziation ............................................ 63
Region ............................................................. 326, 355
Relevante Nachrichten ............................. 375, 387
Required Interface ............................................... 106
Rolle ................................................................... 56, 147
Rückgabetyp ............................................................. 46
Rückgabewert ........................................................ 368
Rumbaugh, James ................................................... 22
S
Schleife .................................................. 269, 375, 388
Schleifenknoten .......................................... 281, 306
Schleifenkörper .................................................... 281
Schnittstelle ..................... 105, 119, 140, 159, 171
Schwache Sequenz ..................................... 375, 381
sd ................................................................................ 370
Selbst-Transition .................................................. 318
Selektionsangabe ................................................. 241
self .............................................................................. 361
Sende-Nachricht .................................................. 366
Senderichtung ...................................................... 401
SendSignalAction ................................................ 249
seq-Fragment ........................................................ 381
Sequence Diagram ....................................... 30, 359
Sequence Expression ......................................... 401
Sequenz-Ausdruck .............................................. 401
Sequenzdiagramm ........... 30, 359, 399, 409, 423
setter-Operation ..................................................... 48
Shallow History .................................................... 324
Shallow History Entry ........................................ 324
Sicherstellung .............................................. 375, 385
Sichtbarkeit .............................................. 40, 46, 188
Signal-Empfang ................................. 249, 305, 315
SignalEvent ............................................................ 313
Signal-Sendung ................................. 249, 305, 315
SimpleState ............................................................ 311
sm (State Machine) ............................................. 328
Socket-Symbol ............................................. 106, 160
Spezialisierung ..................................... 82, 217, 330
Spezifische Klasse ................................................... 82
Stack ................................................................. 245, 248
Standard-Eintritt .................................................. 324
Startknoten ................................ 265, 305, 427, 431
Startzustand ..................... 319, 323, 327, 328, 354
State ........................................................................... 311
State Machine Diagram .............................. 30, 309
State Timeline ....................................................... 412
StateInvariant ........................................................ 362
Statische Verzweigung ............................. 320, 355
Stereotyp ................... 92, 119, 161, 166, 167, 175,
180, 435, 440, 449
Stopp-Symbol .............................................. 362, 413
Stream ................................................... 238, 260, 299
Strict Sequencing ................................................. 382
strict-Fragment ..................................................... 382
Strikte Sequenz ........................................... 375, 382
Strukturdiagramm ................................................. 33
Subject ...................................................................... 251
Subklasse .................................................................... 82
Submachine State ................................................ 329
Superklasse ................................................................ 82
Switch ....................................................................... 292
Synchrone Nachricht .......................................... 365
Synchronisation ................................................... 274
System Boundary ................................................. 212
Systemgrenze ........................................................ 212
T
Tagged Value .......................................................... 444
Tanenbaum, Andrew .......................................... 385
Teilnehmer ............. 361, 395, 401, 407, 411, 421
Template ........................................................... 98, 117
Terminator .......................................... 319, 323, 354
Test-Bereich .................................................. 281, 287
Test-Phase ............................................ 157, 228, 360
Testphase .................................................................... 36
Then-Bereich .......................................................... 287
Thread ............................................................. 276, 279
Tiefe Historie ......................................................... 324
TimeEvent ............................................................... 313
Timing-Diagramm ..................... 31, 370, 409, 423
Transition ................................... 312, 316, 318, 354
Typ ................................................... 40, 41, 46, 47, 99
Unified Method ....................................................... 23
Unified Modeling Language ........................ 20, 23
Unordered .............................................................. 240
Unqualifizierter Name ...................................... 188
Unterbrechungsbereich ........................... 292, 307
Unterklasse ............................................................... 82
Unterzustandsautomatenzustand ............... 329
UpperBound .......................................................... 239
Use Case ................................................................... 215
Use Case Diagram ......................................... 29, 211
V
Value Lifeline ......................................................... 414
Verantwortungsbereich .................................... 234
Verbindungsknoten ..... 267, 268, 306, 427, 431
Vereinigung ..................... 273, 306, 327, 427, 432
Vereinigungsspezifikation .............................. 274
Vererbung .................................................................. 83
Verhaltensdiagramm ................................ 209, 357
Verhaltensport ...................................................... 141
Verhaltens-Zustandsdiagramm .................... 309
Verlorene Nachricht ........................................... 369
Verteilungsdiagramm ................................ 28, 173
Vertikale Strukturierung .................................. 185
Verzweigung .......................................................... 267
Viele-zu-viele-Assoziation .................................. 68
Vlissides, John .............................................. 148, 251
Vorbedingung .............................................. 259, 349
Vorgabewert ................................. 40, 41, 46, 47, 99
W
Wartungsphase ........................................................ 36
Weak Sequencing ................................................. 381
Weight ...................................................................... 240
Wert-Datentyp ......................................................... 54
Wertverlaufslinie ........................................ 414, 422
While-Bereich ........................................................ 281
White-Box-Darstellung ..................................... 135
White-Box-Sicht ................................................... 162
Y
U
Übergabemodus ...................................................... 46
Überladung ................................................................ 48
Überschreibung ....................................................... 83
Überwachungsbedingung ................................ 268
UML ....................................................................... 20, 23
UML Partners ............................................................ 23
Yourdon, Edward .................................................... 22
Z
Zeitbedingung .............................................. 365, 413
Zeitliches Ereignis ............................................... 250
Zeitskala ................................................................... 411
457
Index
Zentraler Puffer ..................................................... 241
Zielzustand ............................................................. 312
Zusammengesetzte Aktivität ....... 281, 287, 297
Zusammengesetzter Zustand ............... 322, 354
Zustand ....................................... 311, 353, 412, 414
458
Zustandsdiagramm ..................................... 30, 309
Zustandsinvariante ............................................. 362
Zustandsübergang .............................................. 312
Zustandsverlaufslinie ..................... 412, 414, 421
Zustandswechsel .................................................. 412
Wissen, wie’s geht.
Wissen aus erster Hand.
Christoph Kecher ist als Software-Ingenieur bei der
Internationalen Kapitalanlagegesellschaft mbH tätig.
Seine Expertise umfasst u. a. Data Warehouse-Technologien, Java, .NET, UML und Software-Qualitätssicherung.
Alexander Salvanos ist Java Enterprise Software-Architekt und seit vielen Jahren mit Modellierungsprozessen befasst. Ihm gelingt es, in großen Projekten agile
Prozesse und bewährte Standards zum Nutzen aller in
Einklang zu bringen, meist mit der Java Enterprise Edition. In seinen Schulungen bringt er Klarheit in komplexe Technologien. Als Mitglied des Java Community
Process beteiligt er sich an der Weiterentwicklung von Java und berät
Unternehmen beim professionellen Einsatz moderner Java-Technologien.
Christoph Kecher, Alexander Salvanos
UML 2.5 – Das umfassende Handbuch
458 Seiten, gebunden, mit Poster, 5. Auflage 2015
34,90 Euro, ISBN 978-3-8362-2977-7
www.rheinwerk-verlag.de/3668
Wir hoffen sehr, dass Ihnen diese Leseprobe gefallen hat. Sie dürfen sie gerne empfehlen und weitergeben, allerdings nur vollständig mit allen Seiten.
Bitte beachten Sie, dass der Funktionsumfang dieser Leseprobe sowie ihre
Darstellung von der E-Book-Fassung des vorgestellten Buches abweichen
können. Diese Leseprobe ist in all ihren Teilen urheberrechtlich geschützt.
Alle Nutzungs- und Verwertungsrechte liegen beim Autor und beim Verlag.
Teilen Sie Ihre Leseerfahrung mit uns!