Vergleich von CASE-Werkzeugen zur Modellierung von Softwaresystemen mittels UML für KMU

Krause, Stefan

Vergleich von CASE-Werkzeugen zur Modellierung von Softwaresystemen mittels UML für KMU

Zusammenfassung

Inhaltsangabe:Einleitung:
Die stetig zunehmende Komplexität von Softwareprojekten hat zur Entwicklung von Werkzeugen geführt, die den Software-Entwicklungsprozess unterstützen. Sogenannte CASE1-Werkzeuge helfen dabei, die Arbeit in sämtlichen Phasen des Entwicklungsprozesses zu erleichtern. Als CASE-Werkzeuge bezeichnet man alle Software-Produkte, die Funktionen zur Entwicklung von Software bereitstellen. Durch sie können Routineabläufe automatisiert und das Software-Management erleichtert werden. Außerdem tragen CASE-Werkzeuge dazu bei, die Software-Produktivität zu erhöhen und die Software-Qualität zu verbessern.
Um aus der Vielzahl der am Markt verfügbaren CASE-Werkzeuge dasjenige auswählen zu können, das den gestellten Anforderungen am nächsten kommt, ist eine genaue Betrachtung der Leistungsmerkmale eines Werkzeuges erforderlich. Dabei können Vergleichsstudien von CASE-Werkzeugen den Entscheidungsprozess vereinfachen und beschleunigen. Aus Aufwandsgründen können Vergleichsstudien meistens nur eine geringe Anzahl aus der Vielzahl von Werkzeugen einbeziehen.
In der vorliegenden Arbeit werden vier CASE-Werkzeuge unter dem Gesichtspunkt des Einsatzes in Klein- und mittelständischen Unternehmen (KMU) verglichen. Besonderer Wert wird außerdem auf die Modellierungsmöglichkeiten mit der UML gelegt. Dazu wird im zweiten Kapitel zunächst eine Einführung in UML 1.4 gegeben. In Kapitel drei werden Anforderungen beschrieben, die an CASE-Werkzeuge gestellt werden und es wird eine Vorgehensweise zur Bewertung von CASE-Werkzeugen entwickelt. Die Bewertung wird anhand eines Kriterienkatalogs durchgeführt, der in Kapitel vier aufgeführt ist. Im fünften Kapitel erfolgt die Beschreibung eines Referenzmodells und eines zugehörigen Kataloges von Änderungen, welche mit jedem der untersuchten Werkzeuge in Kapitel sechs modelliert werden. Hier erfolgt außerdem die Evaluierung der Werkzeuge anhand des in Kapitel vier aufgestellten Kriterienkatalogs. Schließlich werden im siebten Kapitel die Bewertungsergebnisse gegenübergestellt. Kapitel acht fasst die Arbeit zusammen und gibt einen Ausblick.

Inhaltsverzeichnis:Inhaltsverzeichnis:
1.Einleitung5
2.Einführung in UML 1.46
2.1Anwendungsfalldiagramm6
2.2Aktivitätsdiagramm7
2.3Klassendiagramm10
2.4Sequenzdiagramm23
2.5Kollaborationsdiagramm24
2.6Zustandsdiagramm26
3.CASE-Werkzeuge31
3.1Definition und Ziele31
3.2Allgemeine Anforderungen an CASE-Werkzeuge32
3.3Vorgehensweise bei der Auswahl eines […]

Leseprobe

Inhaltsverzeichnis

ID 7637

Krause, Stefan: Vergleich von CASE-Werkzeugen zur Modellierung von Softwaresystemen

mittels UML für KMU

Hamburg: Diplomica GmbH, 2004

Zugl.: Friedrich-Schiller-Universität Jena, Universität, Diplomarbeit, 2003

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,

insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der

Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,

bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung

dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen

der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik

Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in

diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,

dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können

Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die

Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine

Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.

Diplomica GmbH

http://www.diplom.de, Hamburg 2004

Printed in Germany

Inhaltsverzeichnis

Einleitung

Einführung in UML 1.4

2.1 Anwendungsfalldiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Aktivitätsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4 Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5 Kollaborationsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6 Zustandsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CASE-Werkzeuge

3.1 Definition und Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Allgemeine Anforderungen an CASE-Werkzeuge . . . . . . . . . . . . . .

3.3 Vorgehensweise bei der Auswahl eines CASE-Werkzeugs . . . . . . . . .

3.4 Modifizierte Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . .

Kriterienkatalog

4.1 Ausschlusskriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 Allgemeine Kriterien für CASE-Werkzeuge

. . . . . . . . . . . . . . . . .

4.3 Spezielle Kriterien für CASE-Werkzeuge . . . . . . . . . . . . . . . . . . .

4.4 Spezielle Kriterien bzgl. der Modellierung mit der UML . . . . . . . . . . .

Referenzmodell

5.1 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 Aktivitätsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3 Beschreibung des Klassenmodells . . . . . . . . . . . . . . . . . . . . . .

5.4 Beschreibung des Änderungskatalogs . . . . . . . . . . . . . . . . . . . .

5.4.1

Änderungen am Klassendiagramm (Abb. 5.6) . . . . . . . . . . . .

5.4.2

Änderungen am Sequenzdiagramm (Abb. 5.7) . . . . . . . . . . .

5.4.3

Änderungen am Kollaborationsdiagramm (Abb. 5.8) . . . . . . . .

5.4.4

Änderungen am Zustandsdiagramm (Abb. 5.9) . . . . . . . . . . .

Evaluierung der Werkzeuge

6.1 Vorauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2 Bewertungsnotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.3 INNOVATOR 8.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.3.1

Einführung und Beschreibung . . . . . . . . . . . . . . . . . . . . .

6.3.2

Bewertung gegenüber dem Kriterienkatalog . . . . . . . . . . . . .

6.3.3

Bewertung gegenüber dem Änderungskatalog . . . . . . . . . . .

6.4 Together Control Center 6.1 . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4.1

Einführung und Beschreibung . . . . . . . . . . . . . . . . . . . . .

6.4.2

Bewertung gegenüber dem Kriterienkatalog . . . . . . . . . . . . .

6.4.3

Bewertung gegenüber dem Änderungskatalog . . . . . . . . . . .

6.5 Rational Rose Enterprise Edition . . . . . . . . . . . . . . . . . . . . . . .

6.5.1

Einführung und Beschreibung . . . . . . . . . . . . . . . . . . . . .

6.5.2

Bewertung gegenüber dem Kriterienkatalog . . . . . . . . . . . . .

6.5.3

Bewertung gegenüber dem Änderungskatalog . . . . . . . . . . .

6.6 Poseidon for UML Professional Edition 2.0.2 . . . . . . . . . . . . . . . . .

6.6.1

Einführung und Beschreibung . . . . . . . . . . . . . . . . . . . . .

6.6.2

Bewertung gegenüber dem Kriterienkatalog . . . . . . . . . . . . .

6.6.3

Bewertung gegenüber dem Änderungskatalog . . . . . . . . . . .

105

Auswertung

110

7.1 Ausschlusskriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

110

7.2 Allgemeine Kriterien für CASE-Werkzeuge

. . . . . . . . . . . . . . . . .

110

7.3 Spezielle Kriterien für CASE-Werkzeuge . . . . . . . . . . . . . . . . . . .

111

7.4 Spezielle Kriterien bzgl. der Modellierung mit der UML . . . . . . . . . . .

112

7.5 Modellierung des Referenzmodells . . . . . . . . . . . . . . . . . . . . . .

112

7.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

112

Zusammenfassung und Ausblick

113

Literaturverzeichnis

114

Abbildungsverzeichnis

114

Anhang

117

1 Einleitung

Die stetig zunehmende Komplexität von Softwareprojekten hat zur Entwicklung von

Werkzeugen geführt, die den Software-Entwicklungsprozess unterstützen. Sogenannte

CASE

-Werkzeuge helfen dabei, die Arbeit in sämtlichen Phasen des Entwicklungspro-

zesses zu erleichtern. Als CASE-Werkzeuge bezeichnet man alle Software-Produkte,

die Funktionen zur Entwicklung von Software bereitstellen. Durch sie können Rou-

tineabläufe automatisiert und das Software-Management erleichtert werden. Außer-

dem tragen CASE-Werkzeuge dazu bei, die Software-Produktivität zu erhöhen und die

Software-Qualität zu verbessern.

Um aus der Vielzahl der am Markt verfügbaren CASE-Werkzeuge dasjenige auswäh-

len zu können, das den gestellten Anforderungen am nächsten kommt, ist eine genaue

Betrachtung der Leistungsmerkmale eines Werkzeuges erforderlich. Dabei können Ver-

gleichsstudien von CASE-Werkzeugen den Entscheidungsprozess vereinfachen und

beschleunigen. Aus Aufwandsgründen können Vergleichsstudien meistens nur eine ge-

ringe Anzahl aus der Vielzahl von Werkzeugen einbeziehen.

In der vorliegenden Arbeit werden vier CASE-Werkzeuge unter dem Gesichtspunkt

des Einsatzes in Klein- und mittelständischen Unternehmen (KMU) verglichen. Beson-

derer Wert wird außerdem auf die Modellierungsmöglichkeiten mit der UML gelegt.

Dazu wird im zweiten Kapitel zunächst eine Einführung in UML 1.4 gegeben. In Kapitel

drei werden Anforderungen beschrieben, die an CASE-Werkzeuge gestellt werden und

es wird eine Vorgehensweise zur Bewertung von CASE-Werkzeugen entwickelt. Die

Bewertung wird anhand eines Kriterienkatalogs durchgeführt, der in Kapitel vier aufge-

führt ist. Im fünften Kapitel erfolgt die Beschreibung eines Referenzmodells und eines

zugehörigen Kataloges von Änderungen, welche mit jedem der untersuchten Werk-

zeuge in Kapitel sechs modelliert werden. Hier erfolgt außerdem die Evaluierung der

Werkzeuge anhand des in Kapitel vier aufgestellten Kriterienkatalogs. Schließlich wer-

den im siebten Kapitel die Bewertungsergebnisse gegenübergestellt. Kapitel acht fasst

die Arbeit zusammen und gibt einen Ausblick.

Computer Aided Software Engineering

2 Einführung in UML 1.4

Die UML ist eine Sprache und Notation zur Spezifikation, Konstruktion, Visualisierung

und Dokumentation von Modellen für Softwaresysteme. Sie deckt ein breites Spektrum

von Anwendungsgebieten ab und eignet sich u.a. für konkurrierende, verteilte, zeitkriti-

sche und sozial eingebettete Systeme.

Im Folgenden werden die wichtigsten Modellierungselemente der UML vorgestellt.

Dabei wird von der Version 1.4 ausgegangen. Eine ausführliche Beschreibung der UML

findet man in [Oestereich01], [Stevens00], [Rumbaugh99] sowie unter [OMG]. Für Be-

griffe aus der Objektorientierung sei auf die einschlägige Literatur verwiesen.

2.1 Anwendungsfalldiagramm

In einem Anwendungsfalldiagramm werden die Beziehungen zwischen einer Menge

von Anwendungsfällen und den daran beteiligten Akteuren gezeigt. Ein Anwendungs-

falldiagramm bildet somit einen Kontext und eine Gliederung für die Beschreibung von

Geschäftsvorfällen.

Ein Beispiel für einen Geschäftsvorfall ist die schriftliche Schadensmeldung eines

Hausratversicherten. Der gesamte Ablauf für die Verarbeitung dieses Ereignisses wird

durch einen Geschäftsprozess (z.B. 'Hausratschaden melden') beschrieben. Dabei ist

zu beachten, dass auch Aktivitäten dargestellt werden können, die nicht durch die zu

entwickelnde Anwendung unterstützt werden.

Anwendungsfalldiagramme sind in erster Linie ein Hilfsmittel zur Anforderungsermitt-

lung und kein Designansatz oder eine Beschreibung des internen Verhaltens eines zu

entwickelnden Systems. Primär werden Anwendungsfälle dazu verwendet die Kommu-

nikation mit Anwendern und Auftraggebern zu unterstützen. Sie beschreiben das exter-

ne Systemverhalten, also die Leistungsmerkmale eines Systems. Darüber wie dieses

Systemverhalten realisiert wird, treffen Anwendungsfälle keine Aussage.

Abbildung 2.1 zeigt die verschiedenen Notationselemente eines Anwendungsfalldia-

gramms.

Systemgrenze

fall 1

Anwendungs-

Anwendungsfall 3

fall 2

Diagrammname

Akteur 1

Akteur 2

Akteur 3

Abbildung 2.1: Notationselemente des Anwendungsfalldiagramms.

2.2. AKTIVITÄTSDIAGRAMM

2.2 Aktivitätsdiagramm

Aktivitätsdiagramme beschreiben die Ablaufmöglichkeiten eines Systems mit Hilfe von

Aktivitäten. Eine Aktivität ist ein Zustand mit einer internen Aktion und einer oder mehre-

ren ausgehenden Transitionen (Zustandsübergängen), die automatisch dem Abschluss

der internen Aktion folgen. Sie stellt somit einen einzelnen Schritt in einem Verarbei-

tungsablauf dar. Im Falle von mehreren ausgehenden Transitionen müssen diese durch

Bedingungen unterscheidbar sein.

Aktivitätsdiagramme unterstützen die Beschreibung nebenläufiger Aktivitäten. Dabei

ist die Reihenfolge von parallel laufenden Aktivitätspfaden irrelevant, d.h. sie können

nacheinander, gleichzeitig oder abwechselnd laufen.

Aktivitäten und Aktivitätsdiagramme sind entweder einer Klasse, einer Operation oder

einem Anwendungsfall zugeordnet und beschreiben die internen Ablaufmöglichkeiten

dieser Modellelemente.

In einem Aktivitätsdiagramm kann man Aktivitäten hierarchisch schachteln, so dass

eine einzelne Aktivität aus mehreren Detailaktivitäten besteht. Dabei müssen die ein-

gehenden und ausgehenden Transitionen der zusammengesetzten Aktivität und des

Detailmodells übereinstimmen.

Aktivitätsdiagramme lassen sich in Verantwortungsbereiche unterteilen. Dadurch kön-

nen die Aktivitäten anderen Elementen oder Strukturen zugeordnet werden. Man kann

damit z.B. ausdrücken, zu welcher Klasse oder Komponente die Aktivitäten gehören.

Multiple Transitionen bzw. Auslöser bieten eine weitere Möglichkeit parallele Abläufe

darzustellen.

Aufgrund der genannten Darstellungselemente sind Aktivitätsdiagramme geeignet

die unterschiedlichsten Arten von Abläufen darzustellen. Fachliche Zusammenhänge

und Abhängigkeiten, die sich hinter einem Anwendungsfall verbergen, lassen sich mit

ihnen vollständig beschreiben. Ein Aktivitätsdiagramm kann außerdem Sachverhalte

aus mehreren Anwendungsfällen beschreiben sowie Geschäftsregeln und Entschei-

dungslogik abbilden.

Die Darstellung einer Aktivität (Abb. 2.2) erfolgt durch ein benanntes Rechteck mit

gerader Ober- und Unterseite und runden Seitenlinien. Es enthält eine Aktivitätsbe-

schreibung, die aus einem Namen, einer frei formulierten Beschreibung, Pseudocode

oder Programmiersprachencode bestehen kann. Transitionen werden wie in einem Zu-

standsdiagramm als Pfeile dargestellt. Eine Ereignisbeschriftung entfällt, da die Transi-

tionen implizit durch den Abschluss der Aktivität ausgelöst werden.

Aktivität 1

Aktivität 2

Abbildung 2.2: Aktivitäten und Transition.

Bedingungen und Verzweigungen

Ausgehende Transitionen können mit in eckigen Klammern stehenden Bedingungen

(boolsche Ausdrücke) versehen werden. Als Alternative können Verzweigungen, dar-

gestellt durch Rauten (Abb. 2.3), verwendet werden. Eine solche Raute stellt ebenfalls

eine Entscheidungsaktivität dar.

Und- und Oder-Synchronisation

2.2. AKTIVITÄTSDIAGRAMM

Aktivität

[x=0]

[x<0]

[x>0]

[x<0]

Abbildung 2.3: Entscheidung/Verzweigung.

Transitionen können synchronisiert, zusammengeführt und aufgeteilt werden

(Abb. 2.4). Bei einer Zusammenführung von mehreren Transitionen setzt sich der Akti-

onsfluss fort, sobald eine Transition eingeht. Die Synchronisation setzt dagegen voraus,

dass alle eingehenden Transitionen vorliegen.

Splitting

Synchronisation

(AND)

Zusammenführung

(XOR)

Abbildung 2.4: Synchronisation.

Zusammengesetzte Aktivitäten

Zusammengesetzte Aktivitäten werden in folgender Form dargestellt (Abb. 2.5).

Zusammenges.

Aktivität

Abbildung 2.5: Zusammengesetzte Aktivität.

2.2. AKTIVITÄTSDIAGRAMM

Schleifen

Für eine Schleife ist lediglich eine Abbruchbedingung und eine zurückführende Transiti-

on notwendig (Abb. 2.6). Innerhalb der Schleife sind beliebig viele Aktivitäten zulässig.

[sonst]

Aktivität

[Abbruchbedingung]

Abbildung 2.6: Wiederholung/Schleife.

Optionale Aktivitäten

Vor einer optionalen Aktivität (Abb. 2.7) wird eine bedingte Verzweigung notiert. Die

Zweige werden anschließend wieder zusammengeführt.

[sonst]

[Bedingung]

Abbildung 2.7: Optionale Aktivität.

Signale senden und empfangen

Signale können beim Übergang zwischen zwei Aktivitäten an ein Objekt gesendet wer-

den. Ebenso kann der Start einer Aktivität das Eintreffen eines Signals voraussetzen.

Abbildung 2.8 zeigt die zugehörigen Notationselemente. Mit ihrer Hilfe lassen sich z.B.

nebenläufige Prozesse synchronisieren.

2.3. KLASSENDIAGRAMM

Signal senden

Signal empf.

Aktivität 2

Aktivität 3

Aktivität 1

Objekt

Objektfluss

Abbildung 2.8: Interprozesskommunikation.

Objektzustand

Aktivitäten rufen häufig Änderungen am Objektzustand hervor. Ein Objektzustand wird

durch ein Rechteck mit dem Objektnamen und dem Objektzustand in eckigen Klam-

mern notiert. Eine gestrichelte Transitionslinie von einem Objektzustand zu einer Akti-

vität bedeutet, dass die Aktivität einen Ausgangszustand verlangt. Umgekehrt zeigt der

Objektzustand den aus einer Aktivität resultierenden Zustand. Die Notation von Objekt-

zuständen (Abb. 2.9) ist optional und dient der Hervorhebung besonderer Sachverhalte.

Aktivität 2

Aktivität 1

[Zustand]

Objekt

Abbildung 2.9: Resultierende bzw. vorausgesetzte Objektzustände.

2.3 Klassendiagramm

Klassendiagramme werden verwendet, um die statische Struktur eines Systems zu do-

kumentieren. Dazu gehört zu ermitteln, welche Klassen es gibt und in welcher Bezie-

hung sie zueinander stehen. Im Folgenden werden die einzelnen Elemente von Klas-

sendiagrammen erläutert.

Klasse

Eine Klasse beschreibt die Struktur und das Verhalten von Objekten, die aus ihr erzeugt

werden können. Sie beinhaltet die Definition von Attributen und Operationen sowie der

Semantik für eine Menge von Objekten. Die Objekte werden aus Klassen erzeugt und

2.3. KLASSENDIAGRAMM

stellen die in einer Anwendung zur Programmlaufzeit agierenden Einheiten dar. Opera-

tionen werden in der Objektorientierung sehr häufig auch als Methoden bezeichnet.

Das Verhalten eines Objektes wird durch die möglichen Nachrichten, die es versteht,

beschrieben. Ein Objekt benötigt dabei zu jeder Nachricht eine entsprechende Opera-

tion.

Eine Klasse wird, wie in Abbildung 2.10 gezeigt, durch ein Rechteck mit einem Klas-

sennamen und ggf. Attributen und Operationen dargestellt. Klassenname, Attribute und

Operationen werden dabei jeweils durch eine horizontale Linie getrennt. Ein Klassen-

name ist ein Substantiv und beginnt mit einem Großbuchstaben.

Klasse

attribut1

operation2()

operation(parameter) {Zusicherung}

attribut2

Klasse

operation1()

attribut:Typ=Initialwert {Zusicherung}

<<Stereotyp>>

Paket::Klasse

{Eigenschaftswerte}

Abbildung 2.10: Notationsmöglichkeiten für Klassen.

Metaklasse

In der UML können Klassenoperationen und Klassenattribute in einer Metaklasse oder

in der Klasse selbst notiert werden. Innerhalb der Klasse müssen sie allerdings unter-

strichen werden, um sie von normalen Operationen und Attributen unterscheiden zu

können. Abbildung 2.11 zeigt die Notation einer Metaklasse.

KundenKlasse

<<metaclass>>

Abbildung 2.11: Metaklasse.

Parametrisierbare Klasse

Eine parametrisierbare Klasse definiert eine Schablone zur Erzeugung von Klassen.

In statisch typisierten Sprachen sind parametrisierbare Klassen ein wichtiges Hilfsmit-

tel um wiederverwendbaren Code zu erzeugen. Die graphische Notation (Abb. 2.12)

ist ähnlich der von Klassen. Zusätzlich können noch Parameter in einem gestrichelten

Rechteck notiert werden. Zu den Klassen, die aus parametrisierbaren Klassen entste-

hen, existiert eine Verfeinerungsbeziehung mit dem Stereotyp «bind» (s. S.15).

2.3. KLASSENDIAGRAMM

ParametrisierbareKlasse

attribut:Typ=Initialwert

operation()

Parameter

<<bind>> (Elementtyp)

Klasse1

Klasse2

Abbildung 2.12: Schablonenklasse mit Verfeinerungsbeziehung.

Abstrakte Klasse

Eine abstrakte Klasse ist eine allgemeine Oberklasse für eine Menge von konkreten Un-

terklassen. Abstrakt bedeutet, dass für mindestens eine ihrer Operationen keine Imple-

mentierung existiert. Darum ist es auch nicht möglich eine abstrakte Klasse zu instanti-

ieren. Die Darstellung (Abb. 2.13) ist gleich der von normalen Klassen mit dem Zusatz

abstrakt in geschweiften Klammern unter dem Klassennamen. Eine andere Möglichkeit

ist den Klassennamen kursiv zu schreiben. Für die Operationen gilt das gleiche.

Klasse

attribute

Klasse

{abstrakt}

Klasse

operationen()

Abbildung 2.13: Verschiedene Notationsmöglichkeiten für abstrakte Klassen.

Hilfsmittelklasse

In Hilfsmittelklassen werden globale Variablen und Funktionen zusammengefasst, die

als Klassenattribute und Klassenoperationen definiert werden. Sie werden mit dem

Stereotyp «utility» gekennzeichnet. Abbildung 2.14 zeigt die graphische Notation einer

Hilfsmittelklasse.

operation3()

<<utility>>

Hilfsmittelklasse

operation1()

operation2()

Abbildung 2.14: Hilfsmittelklasse.

Objekt

Ein Objekt ist eine Instanz einer Klasse. Es besitzt Attribute und kann die in seiner

Klasse definierten Nachrichten mit Hilfe von entsprechenden Operationen empfangen.

Die Nachrichten definieren das Verhalten eines Objektes. Dieses Verhalten ist für alle

Objekte einer Klasse gleich, ebenso die Struktur der Attribute.

Dargestellt werden Objekte (Abb. 2.15) durch Rechtecke. Diese beinhalten entweder

2.3. KLASSENDIAGRAMM

nur den Objektnamen, zusätzlich auch den Klassennamen oder auch die Attributwerte.

Die Attributwerte werden durch eine horizontale Linie vom Objektnamen getrennt. Der

Objektname wird zusätzlich unterstrichen und beginnt mit einem Kleinbuchstaben.

:Klasse

attribute

operationen

objekt : Klasse

objekt

Abbildung 2.15: Notationsmöglichkeiten für Objekte.

Klassen-Objekt-Beziehungen werden durch einen gestrichelten Pfeil (Abb. 2.16) darge-

stellt. Dabei zeigt das Objekt auf seine Klasse.

objekt

<<instance of>>

Klasse

Abbildung 2.16: Instantiierungsbeziehung.

Schnittstelle, Schnittstellenklasse

Mit einer Schnittstelle wird das externe Verhalten von Klassen spezifiziert. Sie beinhal-

tet eine Menge von Signaturen für Operationen, welche durch eine Klasse implemen-

tiert werden muss, die diese bestimmte Schnittstelle bereitstellen will.

Schnittstellen werden mit dem Stereotyp «interface» gekennzeichnet (Abb. 2.17). Ei-

ne Schnittstellen-Klasse ist abstrakt und definiert ausschließlich abstrakte Operationen.

Eine Kennzeichnung der Operationen mit abstrakt ist deshalb nicht erforderlich.

String

isEqual(String):Boolean

isGreater(String):Boolean

length(): Integer

<<interface>>

Sortierbar

isGreater(Object): Boolean

isEqual(Object): Boolean

<<realize>>

Abbildung 2.17: String realisiert die Schnittstelle Sortierbar.

Von einer Klasse können mehrere Schnittstellen implementiert werden. Des weiteren

kann die Klasse natürlich noch zusätzliche Eigenschaften enthalten. Eine Schnittstelle

beschreibt somit in der Regel eine Untermenge der Operationen einer Klasse. Zwi-

schen der implementierenden Klasse und der Schnittstellenklasse besteht eine Rea-

lisierungsbeziehung, die durch einen gestrichelten Pfeil mit dem Stereotyp «realize»

dargestellt wird.

Alternativ kann eine Schnittstelle auch durch das 'Lolli'-Symbol (Abb. 2.18) oder als

einzelner Kreis dargestellt werden.

Zwischen Schnittstellenklassen können Vererbungsbeziehungen bestehen. Diese wer-

den durch das Stereotyp «extend» ausgedrückt. Zu beachten ist dabei, dass nur ab-

strakte Operationen hinzugefügt werden können.

Eine Schnittstellenklasse kann mehrere verschiedene Schnittstellen erweitern und

somit mehrere Oberklassen haben. In bezug auf Mehrfachvererbung bei normalen

2.3. KLASSENDIAGRAMM

Schnittstelle

Komponente

Schnittstelle1

Schnittstelle2

Abbildung 2.18: Schnittstellen als Lolli-Symbol und alleinstehend.

Klassen stellt dies jedoch kein Problem dar, da hier lediglich Mengen von Signaturen

zusammengefasst werden.

Man kann dem Schnittstellenkonzept eine größere Mächtigkeit verleihen, indem man

für die in den Schnittstellen definierten Signaturen Zusicherungen, wie z.B. Vorbedin-

gungen, Nachbedingungen, Invarianten oder Ausnahmen, spezifiziert.

Zusicherung, Object Constraint Language (OCL)

Eine Zusicherung ist ein Ausdruck, der eine Bedingung oder Integritätsregel beschreibt.

mit ihr lassen sich die zulässigen Wertemengen von Attributen beschreiben, Vor- oder

Nachbedingungen für Nachrichten bzw. Operationen angeben, strukturelle Eigenschaf-

ten zusichern u.v.m.

Zusicherungen können frei formuliert oder als Eigenschaftswert, Stereotyp oder Ab-

hängigkeit notiert werden. Es besteht die Möglichkeit, sie an andere Notationselemente

wie Attribute, Operationen, Klassen und jede Form von Klassenbeziehungen anzuhän-

gen.

Die Notation von Zusicherungen erfolgt innerhalb geschweifter Klammern, wenn sie

mit einem Modellelement verbunden sind oder mit Hilfe der Object Constraint Language

über das Schlüsselwort context.

Beispiel:

{ Zusicherung }

context VerantwortlichesModellelement inv:

Zusicherung

Die Object Constraint Language ist eine formale Sprache. Mit ihrer Hilfe kann UML-

Modellen zusätzliche Semantik angefügt werden, die mit gewöhnlichen UML-Elementen

nicht oder nur unzureichend ausgedrückt werden kann.

Eingeleitet werden OCL-Ausdrücke durch einen Kontext für eine spezifische Instanz:

context Gegenstand inv:

self.eigenschaft

Self ist eine spezifische Instanz von Kontext und inv: steht für Invariante. Eine ausführ-

liche Beschreibung der OCL findet man in [Warmer99].

Eigenschaftswert

Eigenschaftswerte sind benutzerdefinierte, sprach- und werkzeugspezifische Schlüssel-

wort-Wert-Paare, die der Semantik einzelner Modellelemente spezielle charakteristi-

sche Eigenschaften hinzufügen können.

2.3. KLASSENDIAGRAMM

So wie Attribute die Eigenschaften von Klassen näher bestimmen, können Eigen-

schaftswerte die Eigenschaften von beliebigen Modellelementen genauer beschreiben.

Eigenschaftswerte können beliebig und willkürlich vergeben werden. Es ist jedoch sinn-

voll, sie innerhalb eines Projektes auf eine wohldefinierte Menge zu beschränken.

Eigenschaftswerte bestehen aus einem Schlüsselwort und einem Wert. Sie werden

einzeln oder als Aufzählung in geschweiften Klammern notiert.

Beispiele:

{abstract}

{nurLesen}

{privat}

{Version=2.1}

{transient}

{Author=Karl Meier}

{persistent}

Stereotyp

Mit Hilfe von Stereotypen werden die Verwendungsmöglichkeiten von Modellelemen-

ten klassifiziert. Dabei werden einer oder mehreren Klassen bestimmte, gemeinsame

Eigenschaften zugeordnet.

Stereotypen haben keine Typsemantik, wie Typen oder Klassen. Sie ermöglichen

eine semantisch-konzeptionelle und visuelle Unterscheidung und geben Hinweise auf

die Verwendung von Modellelementen.

Im Gegensatz zu Eigenschaftswerten wird durch Stereotypen das Metamodell um

neue Modellelemente erweitert. Dagegen werden mit Eigenschaftswerten einzelne Aus-

prägungen bestehender Modellelemente um bestimmte Eigenschaften erweitert.

Ein Stereotyp wird vor bzw. über dem Elementnamen in doppelte spitze Klammern

notiert oder durch spezielle Symbole dargestellt.

Beispiele:

Textuelle Stereotypisierung

<<actor>>

<<entity>>

<<boundary>>

<<control>>

Kunde

<<actor>>

Kunde

Visuelle Stereotypisierung

Abbildung 2.19: Stereotypen.

Generalisierung, Spezialisierung

Generalisierung und Spezialisierung sind Abstraktionsprinzipien zur hierarchischen Struk-

turierung der Semantik eines Modells. Hierbei werden allgemeine Eigenschaften in

2.3. KLASSENDIAGRAMM

Oberklassen und speziellere Eigenschaften in Unterklassen zusammengefasst. Die

Oberklassen vererben ihre Eigenschaften an die entsprechenden Unterklassen. Diese

verfügen somit über die in ihnen spezifizierten Eigenschaften sowie denen ihrer Ober-

klassen. Die geerbten Eigenschaften können überschrieben und erweitert, jedoch nicht

eliminiert bzw. unterdrückt werden.

Die Einteilung in Ober- und Unterklassen geschieht mit Hilfe eines Unterscheidungs-

merkmals, genannt Diskriminator (Abb. 2.20). Dieser stellt den entscheidenden Ge-

sichtspunkt dar, unter dem die Strukturierung erfolgen soll und ist das Ergebnis einer

Modellierungsentscheidung. Die Menge der Unterklassen mit gleichem Diskriminator

wird Partition genannt.

Diskriminator1

Diskriminator2

Diskriminator1

Oberklasse

Unterklasse3

Unterklasse4

Unterklasse2

Unterklasse1

Unterklasse2

Unterklasse3

Unterklasse4

Unterklasse5

Diskriminator2

Oberklasse

Unterklasse1

Unterklasse5

Abbildung 2.20: Direkte und baumartige Notation von Vererbungsbeziehungen.

Man unterscheidet drei Arten von Vererbung: Spezialisierungsvererbung, Spezifikati-

onsvererbung und Implementierungsvererbung.

Die Spezialisierungsvererbung, auch ist-ein-Vererbung oder is-a-Inheritance genannt,

ist die häufigste Form der Vererbung. Hierbei werden die Definitions- und Werteberei-

che sowie die Vor- und Nachbedingungen von Operationen in der Regel eingeschränkt

bzw. verschärft.

Bei der Spezifikationsvererbung gilt für Operationen, die in Unterklassen überschrie-

ben werden, dass sie keine strengeren Vorbedingungen haben dürfen als die der Ober-

klasse. Außerdem müssen die Nachbedingungen wenigstens so streng sein wie die der

Oberklasse.

Die Implementierungsvererbung dient lediglich der Wiederverwendung von Eigenschaf-

ten der Oberklassen und ist durch rein technische Gesichtspunkte begründet. Konzep-

tionelle Argumente spielen dabei keine Rolle.

Mehrfachvererbung

Wenn eine Klasse mehr als eine Oberklasse besitzt, so spricht man von Mehrfachver-

erbung. Sie wird nicht von allen Programmiersprachen unterstützt, da durch sie ver-

schiedene Probleme auftreten können. So z.B., wenn verschiedene Oberklassen Ei-

genschaften mit gleichen Namen haben. In diesem Fall muss die Eigenschaft mit der

Oberklassenbezeichnung angesprochen werden. In Abbildung 2.21 werden Mehrfach-

vererbungsbeziehungen dargestellt.

2.3. KLASSENDIAGRAMM

Auto

Schiff

Fahrzeug

Landfahrzeug

Straßenfahrzeug

Schienenfahrzeug

Wasserfahrzeug

Amphibienfahrzeug

Zug

Abbildung 2.21: Mehrfachvererbung.

Assoziation

Assoziationen ermöglichen die Kommunikation zwischen Objekten und beschreiben

Verbindungen zwischen Klassen. Eine konkrete Beziehung zwischen zwei Objekten,

also die Instanz einer Assoziation, wird Objektverbindung genannt.

In der Regel besteht eine Assoziation zwischen zwei verschiedenen Klassen. Je-

doch sind auch rekursive Assoziationen zwischen mehreren Klassen möglich. Mit Hilfe

des Stereotyps «temporär» kann angezeigt werden, dass die Assoziation nur zeitweilig

gültig ist. Dies ist der Fall, wenn ein Objekt als Argument in einer Nachricht nur lokal

innerhalb der entsprechenden Operation bekannt ist.

Durch die Angabe von Kardinalitäten wird ausgedrückt mit wie vielen Objekten ein

Objekt assoziiert sein kann. Eine Assoziation kann mit einem Namen gekennzeichnet

werden, der diese näher beschreibt. Durch Rollennamen auf jeder Seite der Beziehung

kann die Rolle, die die jeweiligen Objekte einnehmen, erläutert werden. Zusicherungen

dienen dazu die Beziehung speziell einzuschränken.

Neben den Rollennamen können auch Sichtbarkeitsangaben auf beiden Seiten der

Assoziation notiert werden. Die Assoziation selbst wird durch eine Linie zwischen den

beteiligten Klassen dargestellt (Abb. 2.22).

Mitarbeiter

anschrift

personalNr

name

beschäftigt

Firma

name

anschrift

arbeitgeber

arbeitnehmer

arbeitet für

Abbildung 2.22: Beispiel einer Assoziation.

Gerichtete Assoziation

Eine gerichtete Assoziation erlaubt es, von der einen Assoziationsrolle zur anderen

zu navigieren, nicht jedoch umgekehrt. Sie wird wie eine normale Assoziation notiert

und hat eine geöffnete Pfeilspitze (Abb. 2.23) an der Seite der Klasse, zu der navigiert

werden kann.

Die Notation einer normalen Assoziation stellt eine vereinfachte Schreibweise zweier

gerichteter Assoziationen dar. Diese sind voneinander unabhängig und werden jeweils

von einer Klasse verantwortet.

2.3. KLASSENDIAGRAMM

Rechnung

Anschrift

enthält

Abbildung 2.23: Gerichtete Assoziation.

Attributierte Assoziation

Eine attributierte Assoziation kann verwendet werden, wenn Attribute und Operationen

keiner der beiden beteiligten Klassen zugeordnet werden können, da sie Eigenschaf-

ten der Beziehung sind. Die Eigenschaften der Beziehung werden daher als Klasse

modelliert, die der Assoziation zugeordnet ist. Dabei haben Assoziation und Assoziati-

onsklasse die gleiche Bedeutung.

Eine Besonderheit der attributierten Assoziation ist die Einschränkung, dass zwei

beteiligte Objekte höchstens eine Beziehung zueinander haben dürfen. Notiert werden

attributierte Assoziationen (Abb. 2.24) wie gewöhnliche Assoziationen, denen über eine

gestrichelte Linie die Assoziationsklasse zugeordnet ist.

Mitarbeiter

Fähigkeit

Kompetenzgrad

stufe

Abbildung 2.24: Attributierte Assoziation.

Von der Verwendung der attributierten Assoziation wird abgeraten, da sie nicht objekt-

orientiert ist.

Qualifizierte Assoziation

Bei einer qualifizierten Assoziation wird eine referenzierte Menge von Objekten durch

qualifizierte Attribute in Partitionen unterteilt. Das qualifizierende Attribut wird in einem

Rechteck (Abb. 2.25) an der Seite der Klasse notiert, die über diesen Qualifizierer auf

das Zielobjekt zugreift. Die Angabe von mehreren Attributen ist möglich.

Mitarbeiter

Fähigkeit

Kompetenzgrad

Abbildung 2.25: Beispiel einer qualifizierten Assoziation.

2.3. KLASSENDIAGRAMM

Abgeleitete Assoziation

Die Objektbeziehungen einer abgeleiteten Assoziation können aus den Werten ande-

rer Objektbeziehungen und ihrer Objekte bestimmt werden. Sie wird wie eine normale

Assoziation notiert, mit dem Unterschied, dass ihr Name mit einem Schrägstrich ein-

geleitet wird. Außerdem kann die Ableitungsvorschrift als Zusicherung notiert werden

(Abb. 2.26).

Abteilung

Unternehmen

Mitarbeiter

arbeitgeber

gehört zu

/arbeitet für

abteilung

arbeitet in

result = self.abteilung.arbeitgeber

context Mitarbeiter:: arbeitgeber():Unternehmen

/arbeitgeber

Abbildung 2.26: Abgeleitete Assoziation als Untermengen-Spezifikation.

Mehrgliedrige Assoziation

Eine Assoziation, an der mehr als zwei Assoziationsrollen beteiligt sind, nennt man

mehrgliedrige Assoziation. Eine Assoziationsrolle wird durch eine Klasse repräsentiert.

Dabei kann die Klasse auch mehrfach an der mehrgliedrigen Assoziation beteiligt sein.

In Abbildung 2.27 ist eine solche mehrgliedrige Assoziation dargestellt.

self.teamA <> self.teamB and

self.hz1 <> self.hz2

Assoziationsrolle

Fußballspiel

Mannschaft

name

hz1

hz2

ergebnis

Halbzeit

teamA

teamB

Fussballspiel

Abbildung 2.27: Mehrgliedrige Assoziation.

Da mehrgliedrige Assoziationen nicht von Programmiersprachen unterstützt werden,

sollte man sie nicht verwenden und die entsprechenden Sachverhalte stattdessen durch

normale Assoziationen beschreiben.

2.3. KLASSENDIAGRAMM

Spezialisierte Assoziation

Eine spezialisierte Assoziation (Abb. 2.28) ist eine normale Assoziation, die eine Spe-

zialisierungsbeziehung zu einer anderen Assoziation unterhält. So wie bei Klassen

erbt die spezialisierte Assoziation (Unterassoziation) von der allgemeineren Assozia-

tion (Oberassoziation).

Durch Spezialisierungsbeziehungen entstehen keine neuen Objektbeziehungen. Zwi-

schen Instanzen von Klassen mit Ober- und Unterassoziationen besteht daher jeweils

eine einzige Objektverbindung. Dabei besteht die Unterassoziation meistens zwischen

zwei Klassen, die von den Klassen abgeleitet sind zwischen denen die Oberassoziation

besteht.

Es empfiehlt sich jedoch auf spezialisierte Assoziationen bei der Modellierung zu

verzichten, da sie problematisch in Hinsicht auf andere Modellierungselemente sind.

Stattdessen kann man auch OCL-Zusicherungen verwenden, die die beabsichtigten

Einschränkungen ebenfalls ausdrücken können.

geber

nimmt ein

Person

Rolle

Juristische

Person

Natürliche

Mitarbeiter

Versicherungs-

Abbildung 2.28: Spezialisierte Assoziation.

Assoziationszusicherung

Bedingungen, die eine Assoziation erfüllen muss, werden in geschweiften Klammern

neben der Assoziationslinie notiert. Diese Zusicherungen können frei, formelhaft oder

als OCL-Ausdruck formuliert werden und beliebigen Inhalt haben. Die in Abbildung 2.29

angegebene Zusicherung soll ausdrücken, dass jedem Mitarbeiter eine Fähigkeit nur

einmal zugeordnet werden darf. Dabei wird ausgenutzt, dass in einem Set

jedes Ele-

ment nur einmal enthalten sein darf (im Gegensatz zum Bag

). Falls die beiden Mengen

dennoch gleich sind, ist keine Fähigkeit mehrfach vorhanden.

Ein anderes Beispiel für eine Zusicherung ist {geordnet}. Es gibt an, dass die Objekte

innerhalb der Beziehung geordnet sind.

Kollektion, die das mehrfache Aufreten ein und desselben Elementes nicht gestattet

Kollektion, die das mehrfache Aufreten ein und desselben Elementes gestattet

2.3. KLASSENDIAGRAMM

Mitarbeiter

Fähigkeit

Kompetenzgrad

Mitarbeiter

stufe

self.kompetenzgrad->collect(fähigkeit)->asBag =

self.kompetenzgrad->collect(fähigkeit)->asSet

Abbildung 2.29: Zusicherung über die Eindeutigkeit von Kompetenzgraden.

Aggregation

Eine Aggregation ist eine Zusammensetzung eines Objektes aus einer Menge von Ein-

zelteilen. Sie ist eine Assoziation mit der zusätzlichen Information, dass die beteiligten

Klassen eine Ganzes-Teile-Hierarchie darstellen und keine gleichwertige Beziehung

führen.

Ein Merkmal der Aggregation ist, dass die Aggregatklasse Aufgaben stellvertretend

für seine Teile übernimmt. So kann die Aggregatklasse bspw. Operationen enthalten,

die keine unmittelbare Veränderung im Aggregat selbst zur Folge haben, sondern Nach-

richten an seine Einzelteile weiterleiten. Dies wird Propagieren von Operationen ge-

nannt.

Bei einer Aggregationsbeziehung muss genau festgelegt sein, welche Klasse das

Aggregat ist und welche die Rolle der Einzelteile übernimmt. Das Aggregat übernimmt

somit stellvertretend die Verantwortung und Führung.

Der Unterschied zu einer Assoziation besteht ausschließlich aus der Information,

welche Rollen die beteiligten Klassen einnehmen. Streng genommen gibt es keinen

Unterschied. Jedoch ist die Verwendung der Aggregation sinnvoll, da sie einen wich-

tigen Hinweis auf die höhere Bindung zwischen den beteiligten Klassen liefert und so

zum besseren Verständnis von Klassenmodellen beiträgt.

Eine Aggregation (Abb. 2.30) wird wie eine Assoziation dargestellt und hat auf der

Seite der Aggregatklasse eine Raute.

Ganzes

0..1

Teil

besteht aus

Abbildung 2.30: Aggregation.

Aggregationen können wie Vererbungsbeziehungen auch baumartig (Abb. 2.31) notiert

werden.

2.3. KLASSENDIAGRAMM

Anschrift

Ganzes

Bank-

verbindung

munikation

Telekom-

1..*

0..*

Abbildung 2.31: Baumartige Aggregationen.

Komposition

Die Komposition ist eine spezielle Variante der Aggregation, bei der die Teile vom Gan-

zen existenzabhängig sind. Beschrieben wird, wie sich etwas Ganzes aus Einzelteilen

zusammensetzt und diese kapselt.

Im Unterschied zur Aggregation muss die Kardinalität auf der Seite des Aggregats

immer 1 sein. Dabei ist jedes Teil genau einem Kompositionsobjekt zugeordnet. Die

Existenz der Teile ist abhängig von der Existenz des Ganzen.

Eine Komposition (Abb. 2.32) wird dargestellt wie eine Aggregation, wobei die Raute

ausgefüllt gezeichnet wird.

Ganzes

Teil

hängiges Teil

Existenzab-

Aggregation

Komposition

Abbildung 2.32: Aggregation und Komposition.

Abhängigkeitsbeziehung

Eine Abhängigkeitsbeziehung zwischen zwei Modellelementen zeigt an, dass die Än-

derung in dem unabhängigen Element eine Änderung in dem abhängigen Element zur

Folge hat.

Dargestellt wird eine Abhängigkeitsbeziehung (Abb. 2.33) durch einen gestrichelten

Pfeil vom abhängigen Element auf das unabhängige Element.

abhängig

unabhängig

Abbildung 2.33: Abhängigkeitsbeziehung.

2.4. SEQUENZDIAGRAMM

Verfeinerungsbeziehung / Realisierungsbeziehung

Verfeinerungsbeziehungen werden dazu verwendet den unterschiedlichen Detaillierungs-

grad zwischen gleichartigen Elementen darzustellen. Eine Realisierungsbeziehung be-

schreibt die Beziehung zwischen einer Schnittstelle und ihrer Implementierung.

Verfeinerungsbeziehungen helfen dabei wichtige Entwurfsentscheidungen besser zu

dokumentieren. Die beiden genannten Beziehungen werden in den Abbildungen 2.34

und 2.35 dargestellt.

<<interface>>

Sortierbar

String

isGreater(String):Boolean

length():Integer

isEqual(String):Boolean

isGreater(Object):Boolean

isEqual(Object):Boolean

<<realize>>

Abbildung 2.34: Realisierungsbeziehung.

Tarifierung

Tarifierung1

<<refine>>

Performance optimiert,

Berechnung läuft jetzt auf

lokal replizierten Daten

Abbildung 2.35: Verfeinerungsbeziehung.

2.4 Sequenzdiagramm

Ein Sequenzdiagramm (Abb. 2.36) zeigt eine Reihe von Nachrichten, die eine Men-

ge von Objekten in einer zeitlich begrenzten Situation austauschen. Hierbei steht der

zeitliche Verlauf der Nachrichten im Vordergrund.

Die Objekte werden lediglich durch senkrechte Lebenslinien dargestellt. Dadurch

wird der zeitliche Verlauf der Nachrichten hervorgehoben. Oberhalb dieser Linien steht

der Name bzw. das Objektsymbol. Nachrichten werden als waagerechte Pfeile zwi-

schen den Objekt-Linien gezeichnet. Eine Nachricht wird in der Form

nachricht(argumente) auf die Pfeile notiert. Die Antwort wird ähnlich wie beim Kollabo-

rationsdiagramm in Textform (antwort:=nachricht) oder als eigener, gestrichelter Pfeil

mit offener Pfeilspitze dargestellt.

Um zu verdeutlichen, welches Objekt gerade aktiv ist, werden die gestrichelten Le-

benslinien durch breite, nicht ausgefüllte oder graue, senkrechte Balken überlagert. Ein

solcher Balken wird als Steuerungsfokus bezeichnet. Links bzw. rechts davon können

frei formulierte Erläuterungen und Zeitanforderungen notiert werden.

2.5. KOLLABORATIONSDIAGRAMM

objekt1

objekt2

new()

nachricht()

antwort

delete()

und -destruktion

Objektkonstruktion

objekt1

objekt2

nachricht()

antwort

Lebenslinie

Steuerungsfokus

{b-a < 2 sec.}

Zusicherung

Selbstdelegation

Abbildung 2.36: Standard-Notationselemente des Sequenzdiagramms.

Das Erzeugen eines neuen Objektes wird dargestellt durch eine Nachricht, die auf ein

Objektsymbol trifft. Ein Kreuz am Ende des Steuerungsfokus zeigt die Zerstörung des

Objektes an. Iterationen (Abb. 2.37) werden durch einen Stern vor der Nachricht mar-

kiert.

antwort

*nachricht()

Iteration

objekt1

objekt2

Abbildung 2.37: Iteration in UML.

2.5 Kollaborationsdiagramm

Ein Kollaborationsdiagramm beschreibt eine Menge von Interaktionen zwischen ausge-

wählten Objekten in einer bestimmten Situation. Dabei steht die Zusammenarbeit der

Objekte im Vordergrund. Im Kollaborationsdiagramm werden ausgewählte Nachrichten

zwischen den Objekten gezeigt, wobei der zeitliche Verlauf der Kommunikation durch

Nummerierung der Nachrichten verdeutlicht wird.

Voraussetzung für die Kommunikation zweier Objekte ist das Vorhandensein einer

Assoziation zwischen ihnen. Die Objektverbindung kann permanent bestehen oder

temporär bzw. lokal, z.B. als Argument einer Nachricht. Für Nachrichten, die ein Ob-

jekt an sich selbst schickt ist keine Assoziation notwendig.

Neben der zeitlichen Abfolge, den Namen, Antworten und den möglichen Argumen-

ten der Nachrichten, können ebenso Iterationen bzw. Nachrichten-Schleifen in Kollabo-

rationsdiagrammen dargestellt werden. Sie sind ein Hilfsmittel, um spezielle Ablaufsi-

tuationen zu erläutern oder zu dokumentieren.

Objekte werden durch Assoziationslinien miteinander verbunden. Pfeile markieren

dabei die Richtung der Nachricht vom Sender zum Empfänger. Ebenso aufgeführt wer-

2.5. KOLLABORATIONSDIAGRAMM

den ggf. Argumente oder mögliche Antworten. Sequenznummern, beginnend bei eins,

verdeutlichen die zeitliche Abfolge der Nachrichten. Die von außen kommende Nach-

richt (Startnachricht) wird ohne Nummer dargestellt. Sie kann optional auch von ei-

nem Akteursymbol ausgehen. Abbildung 2.38 zeigt ein Beispiel eines Kollaborations-

diagramms.

startNachricht()

1.1.*: nachricht(argumente)

[Bedingung] 1.2: antwort:=nachricht(arg.)

objekt:Klasse

Abbildung 2.38: Notation des Nachrichtenaustausches als Kollaborationsdiagramm.

Die Syntax der Nachrichtenbezeichnung lautet wie folgt:

Vorgänger-Bedingung Sequenzausdruck Antwort :=

Nachrichtenname(Parameterliste)

Die Vorgänger-Bedingung ist eine Aufzählung der Sequenznummern anderer Nachrich-

ten, die bereits gesendet sein müssen, bevor diese Nachricht gesendet werden darf. Sie

dient also zum Synchronisieren und ist optional. Die Sequenznummern werden durch

Komma getrennt aufgelistet und mit einem Schrägstrich abgeschlossen. Beispiel:

1.1, 2.3/

Der Sequenzausdruck zeigt die Reihenfolge der Nachrichten durch eine aufsteigen-

de Nummerierung. Die Schachtelung einer Nachricht innerhalb anderer Nachrichten

erfolgt durch die Angabe von, durch einen Punkt getrennten, Unter-Sequenznummern.

Solche Schachtelungen treten auf, wenn innerhalb einer Operation, die eine empfan-

gene Nachricht interpretiert, wiederum neue Nachrichten gesendet werden.

Das wiederholte Senden einer Nachricht wird durch einen Stern gekennzeichnet.

Dabei kann die Anzahl der Iterationen in eckigen Klammern durch Pseudocode oder in

der verwendeten Programmiersprache angegeben werden. Beispiel:

1.2.*[i := 1..n]:

Falls die Nachrichten parallel gesendet werden sollen, so wird das durch zwei vertikale

Linien hinter dem Stern angezeigt. Beispiel:

1.2.*||[i := 1..n]:

Außerdem kann eine Bedingung notiert sein, die erfüllt sein muss, damit die Nachricht

ausgeführt werden darf. Beispiel:

1.2.*[x > 5]:

Die Antwort auf eine Nachricht kann mit einem Namen versehen werden, der als Argu-

ment in anderen Nachrichten verwendet werden kann. Der Name ist, ähnlich wie eine

lokale Variable, innerhalb der sendenden Nachricht gültig.

2.6. ZUSTANDSDIAGRAMM

Der Zustand eines Objektes innerhalb des dargestellten Szenarios wird mit «new»,

«destroyed» oder «transient» gekennzeichnet.

Die Beziehung zwischen zwei Objekten kann in einem Kollaborationsdiagramm speziell

gekennzeichnet werden. Dabei kann einer der folgenden Stereotypen vor das nachrich-

tenempfangende Objekt auf die Verbindungslinie notiert werden.

- «association»

Die Grundlage der Objektbeziehung ist eine Assoziation, Aggregation oder Kompositi-

on. Diese Angabe kann entfallen, da sie der Standardfall ist.

- «global»

Das empfangende Objekt ist global.

- «local»

Das empfangende Objekt ist lokal in der sendenden Operation.

- «parameter»

Das empfangende Objekt ist ein Parameter in der sendenden Operation.

- «self»

Das empfangende Objekt ist das sendende Objekt.

Es existieren spezielle Synchronisationsmerkmale, die in folgender Form ausgedrückt

werden:

unspezifisch

Die sequentielle Nachricht wird vom Empfänger angenommen und vollständig verarbei-

tet. Erst dann darf der Absender weitermachen.

synchron

Bei der synchronen Nachricht wartet der Sender, bis der Empfänger die Nachricht an-

genommen hat.

asynchron

Die asynchrone Nachricht fügt sich in die Warteschlange des Empfängers ein. Der

Absender muss nicht wissen, wann der Empfänger die Nachricht annimmt.

2.6 Zustandsdiagramm

In einem Zustandsdiagramm (Abb. 2.39) wird eine Folge von Zuständen dargestellt, die

ein Objekt im Laufe seiner Existenz einnehmen kann. Außerdem zeigt es die Aktionen,

die zu Zustandsübergängen führen.

Ein Zustandsdiagramm stellt eine hypothetische Maschine dar, die sich zu jedem

Zeitpunkt in einer Menge endlicher Zustände befindet.

Diese besteht aus:

- einer endlichen, nicht-leeren Menge von Zuständen

- einer endlichen, nicht-leeren Menge von Ereignissen

- einem Anfangszustand

- einer Menge von Endzuständen

2.6. ZUSTANDSDIAGRAMM

reservieren()

flugEinrichten()

OhneReservierung

entry / rücksetzen()

Teilweise-

Reserviert

[freiePlätze>1]

reservieren()

[freiePlätze>1]

Ausgebucht

Geschlossen

schließen()

stornieren()

[reserviertePlätze=1]

stornieren()

reservieren()

[freiePlätze=1]

flugStreichen()

Abbildung 2.39: Zustandsdiagramm.

Zustand

Ein Zustand ist genau einer Klasse zugeordnet. Er stellt eine Abstraktion einer Menge

von möglichen Attributwerten dar, die die Objekte dieser Klasse einnehmen können. Bei

der Abstraktion werden nur solche Ereignisse berücksichtigt, die das Verhalten eines

Objektes entscheidend beeinflussen. Ein Zeitraum zwischen zwei Ereignissen kann

somit ebenfalls als Zustand betrachtet werden.

Start und Endzustände (Abb. 2.40) sind spezielle Zustände, wobei zu einem Startzu-

stand kein Übergang stattfinden und von einem Endzustand kein Ereignis wegführen

kann.

Endzustand

Startzustand

Abbildung 2.40: Start- und Endzustand.

Zustände haben entweder einen eindeutigen Namen oder sind anonyme Zustände

(Abb 2.41). In einem Zustandsdiagramm sind namenlose Zustände grundsätzlich von-

einander verschieden. Dagegen handelt es sich bei gleichnamigen Zuständen jeweils

um denselben Zustand.

Ein Zustand kann eine Menge von Zustandsvariablen haben. Diese sind Attribute der

zugehörigen Klasse. Dabei werden nur die Attribute ausgewählt, die für die Beschrei-

bung bzw. Identifikation des Zustandes von Bedeutung sind.

Eine Klasse muss nicht zwingend über Zustände verfügen, jedoch über ein entspre-

chendes signifikantes Verhalten.

Aktionsbeschreibung

zustandsvariablen

ereignis /

Abbildung 2.41: Anonyme Zustände.

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2003
ISBN (eBook): 9783832476373
ISBN (Paperback): 9783838676371
DOI: 10.3239/9783832476373
Dateigröße: 1.4 MB
Sprache: Deutsch
Institution / Hochschule: Friedrich-Schiller-Universität Jena – Mathematik und Informatik
Erscheinungsdatum: 2004 (Januar)
Note: 1,0
Schlagworte: kriterienkatalog together diagramm rational rose poseidon

Autor

Stefan Krause (Autor:in)

Vergleich von CASE-Werkzeugen zur Modellierung von Softwaresystemen mittels UML für KMU

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Stefan Krause (Autor:in)