UML 2.5 – Das umfassende Handbuch - ciando.com · Leseprobe Erfahren Sie alles über...

LeseprobeErfahren Sie alles über UML-Diagramme und Notationselemente, und lernen Sie, diese sinnvoll in Projekten einzusetzen. Diese Lese-probe gibt Ihnen einen ersten Einblick, wie Sie UML richtig anwen-den. Außerdem erhalten Sie das vollständige Inhalts- und Stichwort-verzeichnis aus dem Buch.

Christoph Kecher, Alexander Salvanos

UML 2.5 – Das umfassende HandbuchEPUB-Format, 458 Seiten*, in Farbe, 5. Auflage 2015 29,90 Euro, ISBN 978-3-8362-3741-3

*auch erhältlich als gebundenes Buch: 34,90 Euro, ISBN 978-3-8362-2977-7

»Einführung« »Objektdiagramm« »Paketdiagramm«

Inhaltsverzeichnis

Index

Die Autoren

Wissen aus erster Hand.Wissen, wie’s geht.

17

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 Ausbil-

dung nur am Rande mit dem Thema in Berührung gekommen und sehe nicht die

Notwendigkeit, diese »Zusatzaufgabe« während seiner Entwicklungsarbeit durchzu-

führen. Dies koste nur zusätzlich Zeit, und seine Programme liefen auch ohne sie vor-

her modelliert zu haben.

Um die Unumgänglichkeit der Modellierung großer Softwaresysteme zu veran-

schaulichen, 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än-

kungen 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äh-

rend der Bauphase bittere Enttäuschungen, Rückschläge und Verzögerungen der Fer-

tigstellung zu vermeiden.

Nach den Abstimmungsgesprächen zwischen Bauherr und Architekt rückt die Pla-

nung der Realisierung in den Mittelpunkt der Überlegungen:

1 Einführung

18

� Wie muss das Fundament gegossen werden, um das gesamte Haus tragen zu

können?

� Welche Außenverklinkerung soll das Haus erhalten, welche Dachziegel, welche

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 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 Anwen-

derbedü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 Inter-

views, was die gewünschte Software (= das Traumhaus) leisten und mit welchen wei-

1.2 Die Phasen bei der Softwareentwicklung

19

teren Systemen sie interagieren soll (= die Lage des Traumhauses). Ebenfalls muss

klargestellt werden, welche Anforderungen die neue Software nicht erfüllen kann

(= Cheops-Pyramide).

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 Vorha-

ben 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

der Bauarbeiten)?

Das aus dieser Phase entstandene Modell (= Bauplan) dient dem Softwarearchitekten

als Kommunikationsgrundlage mit den Programmierern (= Bauarbeitern) und defi-

niert präzise, welche Programmierarbeiten in welcher Reihenfolge durchzuführen

sind. Erst nach seiner Erstellung kann die Implementierung des eigentlichen Quell-

codes 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 Model-

lierungssprache überproportional steigen.

1.2.3 Implementierung und Dokumentation

In der Implementierungsphase wird der Quelltext der Software erstellt. Die UML-

Modellierung 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.

1 Einführung

20

1.2.4 Test

Bevor die Software bei dem Kunden eingesetzt werden kann, muss überprüft wer-

den, ob die fachlichen Anforderungen des Kunden realisiert worden sind. Auch hier-

bei 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 ein-

zelnen 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 unterschei-

det man zwischen einem Entwicklertest, Validierungstest, Komponententest, Sys-

temtest, Abnahmetest usw.

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 inte-

griert 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

Selbst nachdem eine Software vom Kunden abgenommen wurde, zeigen sich häu-

fig Fehler, die im Nachhinein zu korrigieren sind. Aber nicht nur deshalb ist Soft-

ware Veränderungen ausgesetzt. In den meisten Fällen keimen Erweiterungs- oder

Änderungswünsche bei den Nutzern auf, die ein sorgfältig geplantes Änderungs-

management erforderlich machen. Hierbei zeigt sich erneut, wie vorteilhaft das ge-

wissenhafte 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.

1.3 Was ist die UML?

Die UML (Unified Modeling Language) definiert eine allgemein verwendbare Model-

lierungssprache (auch Notation genannt). Ihr Einsatzgebiet beschränkt sich nicht

auf die Softwareentwicklung. Sie stellt Diagramme und Notationselemente (= ein-

zelne Bestandteile der Diagramme) zur Verfügung, mit deren Hilfe sowohl statische

als auch dynamische Aspekte beliebiger Anwendungsgebiete modelliert werden

können.

1.4 Die Geschichte der UML

21

Die wesentlichen Vorteile der Unified Modeling Language sind:

� Eindeutigkeit

Die Notationselemente besitzen eine präzise Semantik und sind von vielen Exper-

ten 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 Teil-

aspekte. Damit wird die Kommunikation aller an der Softwareentwicklung betei-

ligten Personen erleichtert und auf eine stabile Basis gestellt.

� Ausdrucksstärke

Die Ausschöpfung aller Möglichkeiten der verfügbaren Notationselemente er-

laubt die nahezu vollständige Definition aller wichtigen Details eines Softwaresys-

tems.

� 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 mitt-

lerweile mehr als 800 Unternehmen an.

� Plattform- und Sprachunabhängigkeit

Mit der UML können Sie Softwaresysteme für jede denkbare Plattform und Pro-

grammiersprache modellieren. Sie hat ihre Stärken in der objektorientierten Welt,

kann aber ohne Weiteres auch für prozedurale Sprachen eingesetzt werden.

� Unabhängigkeit von Vorgehensmodellen

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.

1.4 Die Geschichte der UML

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:

1 Einführung

22

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 Nota-

tionen 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-Ori-

ented 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 Engineer-

ing) äußerst aufwendig.

Zusammenführungder MethodenOMT+Booch

Integration der OOSE und weiterer Methoden

Unified Method 0.81995

Unified ModelingLanguage 0.9

1996

Notwendigkeit einervereinheitlichtenModellierungssprache


1997


1997

OMG Unified Modeling

Language 1.21998


Language 1.31999


Language 1.42001


Language 1.52003

WegenRechtsstreitig-keiten bei der Übergabe derCopyrights an dieOMG nie freigegeben


Language 2.02005


Language 2.1.22007


Language 2.22008


Language 2.32010


Language 2.4.12011


Language 2.5Beta2013

1.5 Von der UML 1.x zur UML 2.5

23

Anfang der 90er-Jahre begannen Grady Booch und Jim Rumbaugh die Arbeit an ei-

ner vereinheitlichten Vorgehensmethode und Notation, damals noch unter dem

Namen Unified Method.

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 Modellierungsspra-

che zu konsolidieren.

Schnell erkannten viele namhafte Unternehmen, z. B. Microsoft, Oracle, IBM oder

Rational Software, die Vorteile einer einheitlichen Modellierungssprache und schlos-

sen 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 Zer-

tifizierung 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 Software-

branche als Standard durchgesetzt. Die »drei Amigos« genannten Urväter Booch,

Jacobson und Rumbaugh arbeiten nach wie vor an der Weiterentwicklung. Inzwi-

schen sind jedoch beinahe alle bekannten Unternehmen der Softwarebranche in die

Arbeit an der UML involviert und garantieren den hohen Standard und die Zukunfts-

fä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 Entwick-

lungsschritt 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 Pro-

grammiersprache entworfen (friend).

Durch das iterative Hinzufügen von Details wurde die UML zwar ständig mächti-

ger, 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

1 Einführung

24

für die Modellierung von Architektur, Profilen und Stereotypen (Infrastructure)

und eines für statische und dynamische Modellelemente (Superstructure). Aus die-

sem Grund wurden einige Diagramme vollständig überarbeitet. Das Konzept hin-

ter Aktivitätsdiagrammen (siehe Kapitel 9) wurde beispielsweise komplett

verändert. Vollkommen neue Diagramme, z. B. das Timing-Diagramm (siehe Kapi-

tel 13), wurden aufgenommen. Alte und bewährte Diagrammarten konnten fast

ohne Modifikationen übernommen werden, beispielsweise die Anwendungs-

falldiagramme (siehe Kapitel 8) oder die Klassendiagramme (siehe Kapitel 2). Die

Definition der Object Constraint Language (OCL) und ein spezielles XML-Aus-

tauschformat wurden in weiteren Teilspezifikationen untergebracht. Mit der Ver-

sion 2.2 der UML wurden weitere Profildiagramme (siehe Kapitel 15) in die UML-

Spezifikation aufgenommen. Die UML 2.3 dehnte den Umfang der Spezifikation

noch weiter aus, sodass die Spezifikation erneut aus den Fugen geriet. Viele Stim-

men 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ätsle-

vel. 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 Hin-

weis 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 Dia-

gramme 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.

1.6 Diagramme der UML 2.5

25


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 Klas-

sen, 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 Abbil-

dung 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 Strukturbe-

standteile eines Systems, deren Eigenschaften und Beziehungen. Es fungiert als

eine Art allgemeiner Bauplan für Objekte (siehe Abbildung 1.3). Details zu Klassen-

diagrammen finden Sie in Kapitel 2.

1 Einführung

26

Abbildung 1.2 Übersicht über die UML-Diagramme

Diagramm

Strukturdiagramm

Klassendiagramm

Objektdiagramm

Kompositionsstrukturdiagramm

Komponentendiagramm

Verteilungsdiagramm

Paketdiagramm

Interaktionsübersichtsdiagramm

Timing-Diagramm

Kommunikationsdiagramm

Sequenzdiagramm

Interaktionsdiagramm

Zustandsdiagramm

Aktivitätsdiagramm

Anwendungsfalldiagramm

Verhaltensdiagramm

Profildiagramm


27

Abbildung 1.3 Klassendiagramm

� Objektdiagramm

Ein Objektdiagramm (engl. Object Diagram) stellt eine Momentaufnahme der

Objekte eines Systems dar, die nach dem Bauplan eines Klassendiagramms gebil-

det wurden. Kapitel 3 behandelt alle wichtigen Aspekte von Objektdiagrammen.

Abbildung 1.4 Objektdiagramm

� Kompositionsstrukturdiagramm

Ein Kompositionsstrukturdiagramm (engl. Composite Structure Diagram, siehe

Kapitel 4) beschreibt die interne Struktur einer Komponente und deren Interakti-

onspunkte zu weiteren Komponenten des Systems.

Abbildung 1.5 Kompositionsstrukturdiagramm

1 Einführung

28

� Komponentendiagramm

Dieses Diagramm zeigt die Organisation und Abhängigkeiten der Komponenten.

Komponentendiagramme (engl. Component Diagrams) sind das Thema von Kapi-

tel 5.

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.

Abbildung 1.7 Verteilungsdiagramm

� Paketdiagramm

Das Thema von Kapitel 7 sind Paketdiagramme (engl. Package Diagrams), die

UML-Elemente in Pakete organisieren.

Abbildung 1.8 Paketdiagramm

«artifact»

«realize»

«artifact»

«merge»


29

� Profildiagramm

Profildiagramme (engl. Profile Diagrams) stellen einen leichtgewichtigen Mecha-

nismus dar, mit dem die UML erweitert werden kann. Da sämtliche UML-Meta-

klassen erweitert werden können, werden Profildiagramme erst in Kapitel 15

behandelt, nachdem Sie alle wichtigen UML-Elemente kennengelernt haben.

Abbildung 1.9 Profildiagramm

Verhaltensdiagramme sind:

� 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. Umfangrei-

che Informationen zu Anwendungsfalldiagrammen (engl. Use Case Diagrams) fin-

den Sie in Kapitel 8.

Abbildung 1.10 Anwendungsfalldiagramm

� Aktivitätsdiagramm

Aktivitätsdiagramme (engl. Activity Diagrams, siehe Kapitel 9) beschreiben das

Verhalten einer Klasse oder Komponente. Sie bedienen sich dabei eines Kontroll-

und Datenflussmodells.

Abbildung 1.11 Aktivitätsdiagramm

«profile»

«reference»

«metamodel»

«extend»

«include»

1 Einführung

30

� 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 Kon-

zept der deterministischen endlichen Automaten.

Abbildung 1.12 Zustandsdiagramm

Die folgenden Verhaltensdiagramme werden unter der Bezeichnung Interaktions-

diagramme (engl. Interaction Diagrams) zusammengefasst:

� Sequenzdiagramm

Sequenzdiagramme (engl. Sequence Diagrams, siehe Kapitel 11) definieren Interak-

tionen zwischen Objekten, wobei sie sich auf den Nachrichtenfluss konzentrieren.

Sie zeigen den zeitlichen Ablauf der Nachrichten, beinhalten jedoch keine Infor-

mationen über Beziehungen der Objekte.

Abbildung 1.13 Sequenzdiagramm

alt

[if]

[else]


31

� Kommunikationsdiagramm

Ein Kommunikationsdiagramm (engl. Communication Diagram, siehe Kapitel 12)

beschreibt die Interaktion zwischen Objekten. Im Gegensatz zum Sequenzdia-

gramm setzt es den Fokus auf die Kommunikationsbeziehungen der Objekte wäh-

rend einer Interaktion.

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).

Abbildung 1.15 Timing-Diagramm

� Interaktionsübersichtsdiagramm

Beim Interaktionsübersichtsdiagramm handelt es sich um eine Diagrammart, die

den Kontrollfluss zwischen Interaktionen mithilfe der Notationselemente von

2:b 3:c

1:a

z3z2z1

a b c d e f

0 10 20 30 40 50 60 70sec

1 Einführung

32

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 Over-

view Diagrams).

Abbildung 1.16 Interaktionsübersichtsdiagramm

Nach dieser ersten Übersicht behandeln die folgenden Kapitel die einzelnen Dia-

gramme und deren Notationselemente im Detail. Die gerade vorgestellte Gruppie-

rung 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 »Mate-

rialien zum Buch« von www.rheinwerk-verlag.de/3668 herunterladen.

sd sd

sd

121

Kapitel 3

Objektdiagramm

Das Objektdiagramm zeigt eine Momentaufnahme

der Objekte eines Systems.

3.1 Anwendungsbereiche

Ein Objektdiagramm (engl. Object Diagram) kann als Sonderfall eines Klassendia-

gramms angesehen werden.

Während ein Klassendiagramm die allgemeinen Baupläne und alle möglichen Bezie-

hungen der Objekte untereinander modelliert, stellt das zugehörige Objektdia-

gramm 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 Softwareentwick-

lung 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 Objektdia-

grammen:

3 Objektdiagramm

122

Abbildung 3.1 Notationselemente von Objektdiagrammen

3.3 Notationselemente

3.3.1 Objekt

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.

lieblingsgrieche :Restaurant

kategorie: Sterne = 3name = "Platon"

maren :Gaststatus = "König"geldbetrag: EUR = 300hunger = true

klaudia :Gaststatus = "König"geldbetrag: EUR = 20hunger = true

:KellnerpersAusweisNr = 12345gehalt: EUR = 1500

besucht

+Arbeitnehmer

+Arbeitgeber

bedient

bedient

besucht

Rolle

Objekt

Objektname

zugehörige Klasse

Leserichtung

Linkname

Attributname Attributtyp Attributwert

Link

maren :Gast

status = "König"hunger = truegeldbetrag: EUR = 300

Objekt

Objektname zugehörige Klasse

Attributname Attributtyp Attributwert


123

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 Dar-

stellung von Operationen wird bei Objekten verzichtet.

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.

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 ken-

nenlernen.

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 Attri-

but hunger wird ausgeblendet, da es bei der Erteilung einer Bestellung nicht zwingend

eine Rolle spielen muss.

Abbildung 3.3 Unvollständige, aber zulässige Objektspezifikation

Die Instanziierung einer Klasse durch ein Objekt kann auch mithilfe der <<instan-

tiate>>-Abhängigkeit modelliert werden:

Abbildung 3.4 Instanziierung einer Klasse

maren :Gast

status = "König"geldbetrag: EUR = 300

Zeitpunkt: Erteilung einer Bestellung

Gast

+ status: String = "König"- geldbetrag: EUR# hunger: boolean = true


«instantiate»

Objekt/Instanz

Abhängigkeit

Klasse

3 Objektdiagramm

124

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.

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.

Bei der Darstellung der Objekte können Klassendiagramme auf deren Vollständig-

keit und Korrektheit überprüft werden. Benötigen Sie in einem der Objekt-

diagramme 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.rhein-

werk-verlag.de/3668)

Nun kann die Klasse Gast implementiert werden:

class Gast{public static String status = "König";


125

A private EUR geldbetrag;

protected boolean hunger;

B public Gast(EUR g, boolean h)

{geldbetrag = g;hunger = h;

}

B public Gast(EUR g)

{geldbetrag = g;hunger = true;

}}

Listing 3.2 /beispiele/java/kap3/kap_3_3_1/Gast.java

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: Der geldbetrag erhält den geforderten Typ EUR.

B: Java bietet keine Möglichkeit, Vorgabewerte für Übergabeparameter zu definie-

ren, was für das Attribut hunger notwendig wäre. Daher bedient sich dieses

Beispiel der Überladung von Konstruktoren und emuliert damit eine Art Vor-

gabewert.

A: Das in Abbildung 3.4 gezeigte Objekt maren mit einem geldbetrag von 300 EUR und

hunger = true wird mithilfe des new-Operators instanziiert.

3 Objektdiagramm

126

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 protected bool hunger;

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

static void Main(string[] args){

A Gast maren = new Gast(new EUR(300), true);

}


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.

A: In C# muss statt boolean der Datentyp bool verwendet werden.


127

3.3.2 Link

Abbildung 3.5 Link

Beschreibung

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 mehre-

ren Objekten modelliert werden.

Verwendung

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. Asso-

ziationen aus Klassendiagrammen, die in keinem der Objektdiagramme verwendet

wurden, sind darauf zu überprüfen, ob sie im Klassendiagramm wirklich benötigt

werden.

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.


:KellnermitarbeiterNr = 12gehalt: EUR = 1500

bedient

LeserichtungLinkname

Link

3 Objektdiagramm

128


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.

Abbildung 3.6 Link-Beispiel

Zunächst werden die Klassendefinitionen realisiert:

class Kellner{

A public Gast kunde;

B public void setGast(Gast g){kunde = g;g.bedienung = this;

}}class Gast{

C public Kellner bedienung;public void setKellner(Kellner k){

Gast Kellner

maren :Gast mathias :Kellner

+Kunde

1

+Bedienung

1

+Kunde

1

+Bedienung

«instantiate»«instantiate»


129

bedienung = k;k.kunde = this;

}

}

Listing 3.6 /beispiele/java/kap3/kap_3_3_2/Kellner.java & Gast.java

In einer Hauptoperation werden die Objekte instanziiert und die Links gesetzt:

public static void main(String[] args){

A Gast maren = new Gast();Kellner mathias = new Kellner();

B maren.setKellner(mathias);}

Listing 3.7 /beispiele/java/kap3/kap_3_3_2/Test.java

Realisierung in C#

Objekte werden in C# ebenfalls mit dem new-Operator instanziiert, sodass die Imple-

mentierung gegenüber dem Java-Programmcode keine erwähnenswerten Unter-

schiede aufweist. Sie finden den vollständigen Programmcode im Ordner beispiele/

c#/kap3/kap_3_3_2.

A: Die Assoziation zum Gast wird deklariert.

B: Da die Assoziation in beide Richtungen navigierbar ist, werden beide Assozia-

tionsenden gleichzeitig instanziiert: sowohl auf der Seite des Kellners als auch

auf der Seite des Gastes.

Erst damit ist die Assoziation vollständig und konsistent instanziiert: Ein Link

entsteht.

C: Bei der Klasse Kunde wird auf dieselbe Art verfahren.

A: Objekte werden in Java mithilfe des new-Operators instanziiert.

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.

3 Objektdiagramm

130

3.4 Lesen eines Objektdiagramms

Ein Objektdiagramm wird üblicherweise verwendet, um ein Klassendiagramm zu

illustrieren. Aus diesem Grund wird zunächst ein Klassendiagramm (siehe Abbil-

dung 3.7) entworfen:

Abbildung 3.7 Klassendiagramm als Grundlage für ein Objektdiagramm

Für das Klassendiagramm aus Abbildung 3.7 wird ein Objektdiagramm (siehe Abbil-

dung 3.8) erstellt.

Abbildung 3.8 Beispiel-Objektdiagramm

Restaurant+ kategorie: Sterne+ name: String

Gast+ status: String = "König"- geldbetrag: EUR# hunger: boolean = true

+ bestellen() : Menuepunkt+ zahlen(p :Preis) : EUR

Kellner

+ bedienen(g :Gast)+ servieren(g :Gast, ge :Gericht)+ kassieren(p :Preis)

Mitarbeiter- persAusweisNr: int- gehalt: EUR

1..5

bestellt

1bedient

0..50

besucht

1

persAusweisNr0..1

+Arbeitnehmer

1..*

+Arbeitgeber



maren :Gast

status = "König"geldbetrag: EUR = 300hunger = true

klaudia :Gast

status = "König"geldbetrag: EUR = 20hunger = true

:Kellner

persAusweisNr = 12345gehalt: EUR = 1500

besucht

+Arbeitnehmer

+Arbeitgeber

bedient

bedient

besucht

3.5 Irrungen und Wirrungen

131

Das Objektdiagramm aus Abbildung 3.8 zeigt vier Objekte:

� lieblingsgrieche der Klasse Restaurant

� namenlosen Kellner

� maren der Klasse Gast

� klaudia der Klasse Gast

Zu einem nicht näher spezifizierten Zeitpunkt besitzt der lieblingsgrieche den namen

"Platon" und die kategorie 3 Sterne.

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.

Beachten Sie, dass kein Objekt der Klasse Mitarbeiter im Objektdiagramm aufge-

führt wird. Wie in Abschnitt 2.3.14 erläutert wurde, dienen abstrakte Klassen als Vor-

lagen 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 Attri-

bute 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.

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).


Abbildung 3.9 zeigt ein fehlerhaftes Objektdiagramm, das ein Beispiel des Klassen-

diagramms aus Abbildung 3.7 sein sollte:

3 Objektdiagramm

132

Abbildung 3.9 Mögliche Fehler in Objektdiagrammen

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 Klassendia-

gramms in den Assoziationsnamen, Leserichtungen, Rollen, Navigationsrichtun-

gen und Eigenschaften entsprechen und dürfen sie nicht verändern.

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.



:KellnerpersAusweisNr = 12345gehalt: EUR = 1500

maren :Gastgroesse: cm = 175status = "König"geldbetrag: EUR = 300hunger = "sehr gross"

heiner :Fleischlieferant

:Mitarbeiter+Arbeitgeber +Arbeitnehmer

bedient

besucht

A

B

C

D

E

F

3.6 Zusammenfassung

133

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.10 Objekt

� Links zeigen Beziehungen zwischen Objekten.

Abbildung 3.11 Link

Macht das Objektdiagramm deutlich, dass ein zusätzlicher Link notwendig ist,

muss das Klassendiagramm um die entsprechende Assoziation ergänzt werden.

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.

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.

maren :GastObjekt

Objektname zugehörige Klasse


maren :Gast besucht

LeserichtungLinkname

Link

185

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 UML-

Elemente, die logisch zusammengehören, in Paketen zusammenzufassen und damit

das UML-Modell zu modularisieren.

Pakete können Unterpakete enthalten und erlauben damit eine vertikale Strukturie-

rung. 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 übersichts-

artigen 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 Paketdia-

grammen:

7 Paketdiagramm

186

Abbildung 7.1 Notationselemente von Paketdiagrammen


7.3.1 Paket

Abbildung 7.2 Paket

restaurantsystem

werkzeuge

gaesteverwaltung

Gast

# kundennummer# umsatz: float = 0

vipGaesteverwaltung

Gast

# lieblingswein # leibgericht

datenverwaltung

datenbank

PdfErzeuger

datenpflege

+«access»

«import»

«access» «merge»

Paketname Paket

Import-Beziehung

Access-Beziehung

KlasseMerge-Beziehung

datenverwaltung

datenbankAdministrator

PaketnamePaket

Paket Klasse


187

Beschreibung

Pakete (engl. Packages) gruppieren Elemente und definieren Namensräume (engl.

Namespaces), in denen sich diese Elemente befinden.

Abbildung 7.2 zeigt ein Paket datenverwaltung, das ein Unterpaket datenbank und eine

Klasse Administrator enthält und damit Elemente gruppiert, die mit der Datenver-

waltung im Zusammenhang stehen.

Die UML stellt hierfür eine weitere Notationsmöglichkeit zur Verfügung (siehe Abbil-

dung 7.3):

Abbildung 7.3 Gruppierung von Elementen in einem Paket

Die Diagramme aus Abbildung 7.2 und Abbildung 7.3 sind semantisch gleich.

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):

Abbildung 7.4 Pakete definieren Namensräume.

datenverwaltung

datenbankAdministrator

Paketgruppierung

restaurantsystem gaesteverwaltung

datenbank datenbank

7 Paketdiagramm

188

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 identifi-

ziert. UML definiert hierfür die qualifizierten Namen, in denen zusätzlich die Pa-

ketnamen getrennt durch zwei Doppelpunkte angegeben werden müssen. Für die

in Abbildung 7.4 modellierten Unterpakete lauten sie beispielsweise restaurantsys-

tem::datenbank bzw. gaesteverwaltung::datenbank.

Der Inhalt ist mit seinem Paket untrennbar verbunden. Alle Elemente eines Pakets

werden aus dem Modell entfernt, wenn das Paket gelöscht wird.

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 Paketdia-

gramm ü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) defi-

niert 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).

Abbildung 7.5 Sichtbarkeit eines Paketelements

Verzichtet man auf die Spezifikation einer Sichtbarkeit, wird public (+) angenom-

men, 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 struktu-

rieren die modellierten Klassen und sogar ganze Systeme in logisch und funktionell

zusammengehörende Einheiten, modularisieren sie und gestalten ein Modell damit

einfacher und überschaubarer.

tresor

Goldbarren-

Sichtbarkeit


189

Hierarchieebenen von Paketen erlauben Ihnen eine vertikale Strukturierung des

Modells. Sie gliedern ein Gesamtsystem damit auf abstrakter Ebene bereits in Teil-

systeme und deren Bestandteile auf und schaffen damit eine wichtige Grundlage für

Komponentendiagramme (siehe Kapitel 5).


Als Beispiel soll das Paketdiagramm aus Abbildung 7.6 verwendet werden:

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;

}

datenverwaltung

datenbank

RelationAdministrator

- alter: int

+ setAlter(alter :int) : void+ getAlter() : int

7 Paketdiagramm

190

public int getAlter(){return this.alter;

}

}

Listing 7.1 /beispiele/java/kap7/datenverwaltung/Administrator.java (Download der Bei-

spiele: www.rheinwerk-verlag.de/3668)

A package datenverwaltung.datenbank;public class Relation

{}

Listing 7.2 /beispiele/java/kap7/datenverwaltung/datenbank/Relation.java

Realisierung in C#

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

{

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.

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.


191

B public class Administrator{private int alter;public void setAlter(int alter){this.alter = alter;

}public int getAlter(){return this.alter;

}}

C namespace datenbank

{

D public class 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.

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 datenverwal-

tung erfolgt.

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).

C: Ein Unterpaket kann in C# intuitiv innerhalb des umfassenden Pakets deklariert

werden. Hier wird ein Paket (namespace) datenbank innerhalb des Pakets datenver-

waltung angelegt.

D: Das Unterpaket datenbank enthält eine Klasse Relation.

7 Paketdiagramm

192

namespace datenverwaltung{

A public partial class Administrator

{

B private int alter;

}}

Listing 7.4 /beispiele/c#/kap7/kap_7_3_1/Admin_Attribute.cs

In einer weiteren Datei können dann beispielsweise die Zugriffsoperationen imple-

mentiert werden:

namespace datenverwaltung{

A public partial class Administrator

{

B public void setAlter(int alter){this.alter = alter;

}public int getAlter(){return this.alter;

}

}}

Listing 7.5 /beispiele/c#/kap7/kap_7_3_1/Admin_Operationen.cs

A: Die Aufteilung einer Klasse auf mehrere Quellcodedateien wird mit dem Schlüs-

selwort partial signalisiert.

B: Es wird nur das private Attribut alter deklariert.


193

7.3.2 Paket-Import

Abbildung 7.7 Paket-Import

Beschreibung

Ein Paket-Import (engl. PackageImport) ist eine Beziehung, die alle Namen öffentli-

cher 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 enthal-

ten würde. Wird das importierende Paket aus dem Modell entfernt, bleiben die Ele-

mente 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. Da-

mit 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 ver-

fügbar.

Abbildung 7.8 Mehrfacher Paket-Import

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.

restaurantsystem werkzeuge

PdfErzeuger«import»

Paket-Import

+

importierendes Paket importiertes Paket

restaurantsystem werkzeuge

+ PdfErzeuger

restaurantkette

«import» «import»

7 Paketdiagramm

194

Um dies zu verhindern, bietet die UML den Paket-Accessals eine Einschränkung des

Paket-Imports.

Abbildung 7.9 Paket-Access

Ein Paket-Access (engl. PackageAccess) ist eine Beziehung, die alle Namen öffentli-

cher 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.

Trotz der <<import>>-Beziehung zwischen restaurantkette und restaurantsystem

kann damit in restaurantkette kein Zugriff auf den PdfErzeuger über seinen unquali-

fizierten Namen erfolgen.

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:

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 erken-

nen ist. Das Paket restaurantsystem macht dagegen von der Möglichkeit Gebrauch,

das zu importierende Element genau zu spezifizieren, indem es explizit den PdfEr-

zeuger 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-

restaurantkette restaurantsystem werkzeuge

+ PdfErzeuger«import» «access»

Paket-Import Paket-Access

restaurantsystem

{access werkzeuge::PdfErzeuger}

restaurantkette

{import restaurantsystem::*}

werkzeuge

+PdfErzeuger


195

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.


Java enthält nativ keine Unterstützung des öffentlichen Imports von Paketen, der

mit dem Stereotyp <<import>> gekennzeichnet wird. Alle importierten Elementna-

men sind nur im jeweils importierenden Paket verfügbar, was der <<access>>-Bezie-

hung 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 dar-

gestellte Art durchgeführt werden:

Abbildung 7.11 Umwandlung von <<import>> in <<access>>

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>>-Bezie-

hung modelliert werden (unterer Teil von Abbildung 7.11).

Es muss jedoch darauf hingewiesen werden, dass der obere und untere Teil der Abbil-

dung 7.11 nicht exakt äquivalent sind: Ein weiteres Paket, das restaurantkette impor-

tiert, hätte im oberen Teil der Abbildung direkten Zugriff auf PdfErzeuger, im unteren

Teil nicht.

restaurantkette restaurantsystem werkzeuge

+ PdfErzeuger

werkzeuge

+ PdfErzeuger

restaurantsystemrestaurantkette

«import» «import»

«access» «access»

«access»

7 Paketdiagramm

196

Als Vorlage für die Java-Realisierung soll das folgende Paketdiagramm verwendet

werden:

Abbildung 7.12 Beispiel für einen Paket-Import

A package restaurantsystem;

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

A: Die im Folgenden implementierte Klasse Restaurant befindet sich im Paket

restaurantsystem.

B: Der Klassenname PdfErzeuger aus dem Paket werkzeuge wird in das aktuelle Paket

importiert. Im Unterschied zur UML, in der das Paket externe Elemente impor-

tiert, ist dies in Java die Aufgabe einer jeden Klasse des jeweiligen Pakets.

Obwohl es sich im Sinne der UML streng genommen um eine <<access>>-Bezie-

hung handelt, verwendet Java hierfür das Schlüsselwort import.

Es sollte an dieser Stelle nochmals betont werden, dass nicht die Klasse selbst, son-

dern 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.

restaurantsystem

werkzeuge

+ PdfErzeuger

xml

+ XmlErzeuger+ Restaurant

«access»


197

Realisierung in C#

Auch C# unterstützt die <<import>>-Beziehung nicht. Der folgende Programmcode

realisiert das Diagramm aus Abbildung 7.12:

A namespace restaurantsystem

{

B using werkzeuge;using werkzeuge.xml;

public class Restaurant{PdfErzeuger p = new PdfErzeuger();XmlErzeuger x = new XmlErzeuger();

}}


7.3.3 Paket-Merge

Abbildung 7.13 Paket-Merge

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 Klas-

sennamen des Pakets importiert werden.

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.

Es werden immer alle Klassennamen des Pakets importiert. Der Import eines ein-

zelnen Klassennamens wird von C# nicht unterstützt.

Der Zugriff auf Unterpakete erfolgt wie in Java mithilfe des Punkt-Operators.

gaesteverwaltungvipGaesteverwaltung

«merge»

Paket-Merge

ZielpaketQuellpaket

7 Paketdiagramm

198

Beschreibung

Ein Paket-Merge (engl. PackageMerge) definiert eine Beziehung zwischen zwei Pake-

ten, bei der die nicht privaten Inhalte des Zielpakets mit den Inhalten des Quellpakets

verschmolzen werden.

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 Trans-

formationen dar, die bei der Verschmelzung des Zielpakets mit dem Quellpaket

benötigt werden. Das Beispiel aus Abbildung 7.14 verdeutlicht die prinzipielle Funk-

tionsweise eines Paket-Merge und zeigt die entsprechenden Transformationen:

Abbildung 7.14 Merge zweier Pakete mit unterschiedlichen Elementen

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.

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 Gene-

ralisierung über alle Attribute und Operationen des Elements P2::B verfügt. (Genera-

lisierung wurde in Abschnitt 2.3.12 vorgestellt.)

P2P1

P1

A B

A B

P2::B

«merge»


199

Was passiert aber, wenn beide Pakete bereits Elemente mit denselben Namen ent-

halten?

Abbildung 7.15 Merge von Elementen mit demselben Namen

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 Ele-

ment 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 dieje-

nigen 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.

Betrachten wir noch ein weiteres Beispiel, in dem ein leeres Paket zwei weitere Pakete

mergt, die beide dasselbe Element enthalten (siehe Abbildung 7.16).

In Abbildung 7.16 werden die zwei Pakete P1 und P2, die jeweils ein Element A defi-

nieren, in ein leeres Paket P3 gemergt. Bei der Verschmelzung wird ein neues Ele-

ment 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 ver-

einigt.

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.

P1 P2

P1

AA

A

P2::A

«merge»

7 Paketdiagramm

200

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.

Im oberen Teil der Abbildung 7.17 definiert Paket P1 ein Element B, das von A speziali-

siert 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 verbun-

den sind.

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üng-

lichen Generalisierungen und Assoziationen (hervorgehoben) bleiben jedoch er-

halten.

P1 P2

P3

P3

A A

P1::A P2::A

A

«merge»«merge»


201

Abbildung 7.17 Merge von Elementen mit Generalisierungen und Assoziationen

Es bleibt noch zu klären, was bei einem Merge mit Paketen passiert, die selbst in wei-

teren Paketen enthalten sind. Den einfachsten Fall zeigt Abbildung 7.18.

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.

Wie durch dieses Beispiel angedeutet, folgen die Unterpakete bei Merge denselben

Regeln wie innere Elemente von Paketen. Während die Elemente durch die Verwen-

dung von Generalisierungen verschmolzen werden, geschieht dies bei Paketen

durch Merge-Beziehungen.

P1 P2

P3

P3

B

A

B

C

D

D

E

P1::B P2::B

B

C

P2::C

A

P1::A

D

P2::D

E

«merge»«merge»

7 Paketdiagramm

202

Abbildung 7.18 Merge eines Unterpakets

Weitere Beziehungen zwischen Paketen (<<import>> und <<access>>) bleiben bei

einem Paket-Merge erhalten:

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-

P1 P2

P3

P1

P3

P2::P3

«merge»

«merge»

P1 P2P3

P4

P1

P3

P2::P3 P4

«import»«merge»

«import»«merge»


203

hung zwischen dem Quellpaket P1 und dem Paket P4, wie im unteren Teil von Abbil-

dung 7.19 dargestellt ist.

Verwendung

Merge-Beziehungen werden verwendet, wenn im Modell Pakete vorhanden sind,

deren Inhalte und Konzepte sich ergänzen und daher zu neuer Gesamtheit zusam-

mengesetzt werden können.

Wie eingangs erwähnt, stellt eine Merge-Beziehung lediglich eine abkürzende Nota-

tion 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.

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).

Abbildung 7.20 Gefahr der Merge-Beziehung

P1 P2

P3

A

B

B

A

P3

P1::A P2::A

A

P1::B P2::B

B

«merge» «merge»

FEHLER !!!

7 Paketdiagramm

204

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.

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.

Verwenden Sie die Merge-Beziehung daher nur mit großer Vorsicht.


Java bietet kein Sprachmittel, das einem Paket-Merge entspräche, sodass die entste-

hende Hierarchie der Generalisierungen einzeln realisiert werden muss. Wie man in

Java eine Generalisierung implementiert, wird in Abschnitt 2.3.12 erläutert.

Realisierung in C#

Für C# gilt bei der Merge-Beziehung dasselbe wie für Java.

7.4 Lesen eines Paketdiagramms

Das Paketdiagramm aus Abbildung 7.21 definiert sieben Pakete:

� restaurantsystem

� gaesteverwaltung

� werkzeuge

� 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 Pake-

ten, die restaurantsystem importieren, verboten.

Auch das Paket gaesteverwaltung importiert die datenverwaltung als privat und ver-

bietet 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 vip-

Gaesteverwaltung::Gast alle Attribute der Klasse gaesteverwaltung::Gast erbt.


205

Abbildung 7.21 Beispiel für ein Paketdiagramm


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öglicher-

weise nicht so einfach zu erkennen ist wie in diesem Beispiel.

restaurantsystem

werkzeuge

gaesteverwaltung

Gast

# kundennummer# umsatz: float = 0

vipGaesteverwaltung

Gast


datenverwaltung

datenbank

PdfErzeuger

datenpflege

+«access»

«import»

«access» «merge»

7 Paketdiagramm

206

Abbildung 7.22 Ein fehlerhaftes Paketdiagramm

7.6 Zusammenfassung

Abschließend werden die wichtigsten Notationselemente kurz aufgeführt:

� Pakete gruppieren Elemente wie Klassen oder weitere Pakete und definieren

Namensräume.

D: Ungültige <<merge>>-Beziehung

Die <<merge>>-Beziehung darf nur zwischen Paketen modelliert werden. Ein

Merge einer Klasse mit einem Paket ist nicht definiert.

E: Falsche Hierarchie

Klassen können weitere Klassen, jedoch keine Pakete enthalten. Andersherum ist

es Paketen durchaus gestattet, Klassen in sich zu gruppieren.

gaesteverwaltung

Gast

# kundennummer # umsatz: float = 0

vipGaesteverwaltung

Gast


datenverwaltung

datenbank datenpflege

Werkzeuge

xml«access» «merge» «merge»

«merge»

E

D

A

BC

7.6 Zusammenfassung

207

Abbildung 7.23 Paket

� Ein Paket-Import importiert alle Namen des importierten Pakets als öffentlich,

ein Paket-Access als privat.

Abbildung 7.24 Paket-Import und -Access

� Mithilfe eines Paket-Merge können die Inhalte von Paketen verschmolzen

werden.

Abbildung 7.25 Paket-Merge

restaurantsystem

Paketname

Paket

restaurantsystem

werkzeuge

datenverwaltung«access»«import»

Paket-Import

Paket-Access

importierendes Paket

importiertes Paket

gaesteverwaltungvipGaesteverwaltung

«merge»

Paket-Merge

ZielpaketQuellpaket

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

5

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 Analyse .................................................................................................................... 18

1.2.2 Entwurf .................................................................................................................... 19

1.2.3 Implementierung und Dokumentation ........................................................ 19

1.2.4 Test ........................................................................................................................... 20

1.2.5 Einsatz ...................................................................................................................... 20

1.2.6 Wartung und Pflege ............................................................................................ 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 Strukturdiagramme

2 Klassendiagramm 35

2.1 Anwendungsbereiche ....................................................................................................... 35

2.2 Übersicht ................................................................................................................................. 36

2.3 Notationselemente ............................................................................................................ 37

2.3.1 Klasse ....................................................................................................................... 37

2.3.2 Attribut .................................................................................................................... 39

2.3.3 Operation ................................................................................................................ 45

2.3.4 Binäre Assoziation ............................................................................................... 55

2.3.5 Reflexive Assoziation .......................................................................................... 63

2.3.6 N-äre Assoziation ................................................................................................. 64

2.3.7 Qualifizierte Assoziation ................................................................................... 68

2.3.8 Assoziationsklasse ............................................................................................... 70

Inhalt

6

2.3.9 Aggregation ........................................................................................................... 72

2.3.10 Komposition .......................................................................................................... 76

2.3.11 Abhängigkeit ......................................................................................................... 79

2.3.12 Generalisierung/Spezialisierung .................................................................... 82

2.3.13 Stereotyp ................................................................................................................. 92

2.3.14 Abstrakte Klasse ................................................................................................... 95

2.3.15 Template ................................................................................................................. 98

2.3.16 Schnittstelle ........................................................................................................... 105

2.3.17 Anmerkung ............................................................................................................ 110

2.4 Lesen eines Klassendiagramms .................................................................................... 111

2.5 Irrungen und Wirrungen .................................................................................................. 114

2.6 Zusammenfassung ............................................................................................................. 116

3 Objektdiagramm 121


3.2 Übersicht ................................................................................................................................. 121


3.3.1 Objekt ....................................................................................................................... 122

3.3.2 Link ............................................................................................................................ 127

3.4 Lesen eines Objektdiagramms ...................................................................................... 130



4 Kompositionsstrukturdiagramm 135


4.2 Übersicht ................................................................................................................................. 135


4.3.1 Part ............................................................................................................................ 136

4.3.2 Port und Konnektor ............................................................................................. 139

4.3.3 Kollaboration ......................................................................................................... 147

4.3.4 Kollaborationsanwendung ............................................................................... 149

Inhalt

7

4.4 Lesen eines Kompositionsstrukturdiagramms ...................................................... 151



5 Komponentendiagramm 157


5.2 Überblick ................................................................................................................................. 157


5.3.1 Komponente .......................................................................................................... 159

5.3.2 Konnektor ............................................................................................................... 163

5.3.3 Artefakt .................................................................................................................... 165

5.4 Lesen eines Komponentendiagramms ...................................................................... 167



6 Verteilungsdiagramm 173


6.2 Übersicht ................................................................................................................................. 173


6.3.1 Knoten ..................................................................................................................... 174

6.3.2 Kommunikationspfad ........................................................................................ 179

6.4 Lesen eines Verteilungsdiagramms ............................................................................ 180



7 Paketdiagramm 185


7.2 Übersicht ................................................................................................................................. 185

Inhalt

8


7.3.1 Paket ......................................................................................................................... 186

7.3.2 Paket-Import .......................................................................................................... 193

7.3.3 Paket-Merge ........................................................................................................... 197

7.4 Lesen eines Paketdiagramms ........................................................................................ 204



TEIL II Verhaltensdiagramme

8 Anwendungsfalldiagramm 211


8.2 Übersicht ................................................................................................................................. 212


8.3.1 Systemgrenze ........................................................................................................ 212

8.3.2 Akteur ....................................................................................................................... 213

8.3.3 Anwendungsfall ................................................................................................... 215

8.3.4 Assoziation ............................................................................................................. 216


8.3.6 Include-Beziehung ............................................................................................... 219

8.3.7 Extend-Beziehung ................................................................................................ 220

8.4 Lesen eines Anwendungsfalldiagramms .................................................................. 221



9 Aktivitätsdiagramm 227


9.2 Übersicht ................................................................................................................................. 228


9.3.1 Aktion ....................................................................................................................... 231

9.3.2 Kontrollfluss ........................................................................................................... 232

Inhalt

9

9.3.3 Aktivitätsbereich .................................................................................................. 233

9.3.4 Objektknoten und Objektfluss ........................................................................ 236

9.3.5 Signal-Sendung und Signal-Empfang ........................................................... 249

9.3.6 Aktivität ................................................................................................................... 259

9.3.7 Start- und Endknoten ......................................................................................... 265

9.3.8 Entscheidungs- und Verbindungsknoten .................................................... 267

9.3.9 Gabelung und Vereinigung .............................................................................. 273

9.3.10 Schleifenknoten .................................................................................................... 281

9.3.11 Bedingungsknoten .............................................................................................. 287

9.3.12 Unterbrechungsbereich ..................................................................................... 292

9.3.13 Expansionsbereich ............................................................................................... 297

9.4 Lesen eines Aktivitätsdiagramms ................................................................................ 299



10 Zustandsdiagramm 309


10.2 Übersicht ................................................................................................................................. 310


10.3.1 Zustand ................................................................................................................... 311

10.3.2 Event und Transition ........................................................................................... 312

10.3.3 Startzustand, Endzustand und Terminator ................................................. 319

10.3.4 Entscheidung und Kreuzung ............................................................................ 320

10.3.5 Zusammengesetzter Zustand .......................................................................... 322

10.3.6 Region ...................................................................................................................... 326

10.3.7 Rahmen eines Zustandsautomaten .............................................................. 328


10.3.9 Zustandsdiagramm in Java ............................................................................... 332

10.3.10 Zustandsdiagramm in C# .................................................................................. 340

10.3.11 Protokoll-Zustandsautomat ............................................................................. 348

10.4 Lesen eines Zustandsdiagramms ................................................................................. 350



Inhalt

10

TEIL III Interaktionsdiagramme

11 Sequenzdiagramm 359


11.2 Übersicht ................................................................................................................................. 360


11.3.1 Lebenslinie .............................................................................................................. 361

11.3.2 Nachricht ................................................................................................................ 364

11.3.3 Interaktionsrahmen ............................................................................................ 370

11.3.4 Kombinierte Fragmente .................................................................................... 375

11.4 Lesen eines Sequenzdiagramms .................................................................................. 391



12 Kommunikationsdiagramm 399


12.2 Übersicht ................................................................................................................................. 399



12.3.2 Lebenslinie .............................................................................................................. 401

12.3.3 Nachricht ................................................................................................................ 401

12.4 Lesen eines Kommunikationsdiagramms ................................................................ 405



13 Timing-Diagramm 409


13.2 Übersicht ................................................................................................................................. 409



Inhalt

11

13.3.2 Lebenslinie .............................................................................................................. 411

13.3.3 Zustandsverlaufslinie ......................................................................................... 412

13.3.4 Wertverlaufslinie ................................................................................................. 414

13.3.5 Nachricht ................................................................................................................ 415

13.4 Lesen eines Timing-Diagramms ................................................................................... 418



14 Interaktionsübersichtsdiagramm 423


14.2 Übersicht ................................................................................................................................. 423



14.3.2 Interaktion und Interaktionsreferenz ........................................................... 425

14.3.3 Kontrollfluss ........................................................................................................... 426

14.3.4 Kontrollknoten ...................................................................................................... 427

14.4 Lesen eines Interaktionsübersichtsdiagramms ..................................................... 428



TEIL IV Metamodellierung

15 Profildiagramm 435


15.2 Übersicht ................................................................................................................................. 436


15.3.1 Metamodell, Profil und Metamodell-Referenz .......................................... 437

15.3.2 Metaklasse ............................................................................................................. 439

15.3.3 Stereotyp und Erweiterung .............................................................................. 440

15.3.4 Profilanwendung ................................................................................................. 443

Inhalt

12

15.4 Lesen eines Profildiagramms ......................................................................................... 445



Index ........................................................................................................................................................ 451

Index

451

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

Index

452

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

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

Index

453

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

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

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

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

Index

454

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

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

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

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

Index

455

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

L

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

M

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

N

Nachbedingung .......................................... 259, 349

Nachricht ................. 364, 395, 401, 408, 415, 422

Nachrichten-Label ............................................... 416

Namensraum ............................................... 187, 206

n-äre Assoziation .................................................... 64

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

O

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

P

Package .................................................................... 187

package ....................................................................... 40

Package Diagram .......................................... 28, 185

PackageAccess ....................................................... 194

PackageImport ...................................................... 193

Index

456

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

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

Index

457

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

U

Übergabemodus ...................................................... 46

Überladung ................................................................ 48

Überschreibung ....................................................... 83

Überwachungsbedingung ................................ 268

UML ....................................................................... 20, 23

UML Partners ............................................................ 23

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

Yourdon, Edward .................................................... 22

Z

Zeitbedingung .............................................. 365, 413

Zeitliches Ereignis ............................................... 250

Zeitskala ................................................................... 411

Index

458

Zentraler Puffer ..................................................... 241

Zielzustand ............................................................. 312

Zusammengesetzte Aktivität ....... 281, 287, 297

Zusammengesetzter Zustand ............... 322, 354

Zustand ....................................... 311, 353, 412, 414

Zustandsdiagramm ..................................... 30, 309

Zustandsinvariante ............................................. 362

Zustandsübergang .............................................. 312

Zustandsverlaufslinie ..................... 412, 414, 421

Zustandswechsel .................................................. 412

Wir hoffen sehr, dass Ihnen diese Leseprobe gefallen hat. Sie dürfen sie ger-ne 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!

Christoph Kecher ist als Software-Ingenieur bei der Internationalen Kapitalanlagegesellschaft mbH tätig. Seine Expertise umfasst u. a. Data Warehouse-Techno-logien, Java, .NET, UML und Software-Qualitätssiche-rung.

Christoph Kecher, Alexander Salvanos

UML 2.5 – Das umfassende HandbuchEPUB-Format, 458 Seiten*, in Farbe, 5. Auflage 2015 29,90 Euro, ISBN 978-3-8362-3741-3

*auch erhältlich als gebundenes Buch: 34,90 Euro, ISBN 978-3-8362-2977-7

Alexander Salvanos ist Java Enterprise Software-Archi-tekt und seit vielen Jahren mit Modellierungsprozes-sen 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 Edi-tion. In seinen Schulungen bringt er Klarheit in kom-plexe 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.

Wissen aus erster Hand.Wissen, wie’s geht.

https://www.facebook.com/rheinwerkverlag

https://plus.google.com/118435207805510651040

http://twitter.com/rheinwerkverlag

UML 2.5 – Das umfassende Handbuch - ciando.com · Leseprobe Erfahren Sie alles über...

Documents

Transcript of UML 2.5 – Das umfassende Handbuch - ciando.com · Leseprobe Erfahren Sie alles über...