Danksagung

An dieser Stelle möchte ich allen danken, die mich bei der Anfertigung dieser Arbeit unterstützt haben. Mein besonderer Dank gilt dabei Herrn Prof. Dr. Wilhelm Rossak und Herrn Dipl. Inf. Christian Erfurth für ihre freundliche Betreuung.

Inhaltsverzeichnis

1  Einleitung  5

2  Einführung in UML 1.4  7

2.1  Anwendungsfalldiagramm  7

2.2  Aktivitätsdiagramm  8

2.3  Klassendiagramm  11

2.4  Sequenzdiagramm  24

2.5  Kollaborationsdiagramm  25

2.6  Zustandsdiagramm  27

3  CASE-Werkzeuge  33

3.1  Definition und Ziele  33

3.2  Allgemeine Anforderungen an CASE-Werkzeuge  34

3.3  Vorgehensweise bei der Auswahl eines CASE-Werkzeugs  35

3.4  Modifizierte Vorgehensweise  35

4  Kriterienkatalog  37

4.1  Ausschlusskriterien  37

4.2  Allgemeine Kriterien für CASE-Werkzeuge  38

4.3  Spezielle Kriterien für CASE-Werkzeuge  41

4.4  Spezielle Kriterien bzgl. der Modellierung mit der UML  43

5  Referenzmodell  47

5.1  Anwendungsfälle  47

5.2  Aktivitätsdiagramme  47

5.3  Beschreibung des Klassenmodells  50

5.4  Beschreibung des Änderungskatalogs  53

5.4.1  Änderungen am Klassendiagramm (Abb. 5.6)  53

5.4.2  Änderungen am Sequenzdiagramm (Abb. 5.7)  53

5.4.3  Änderungen am Kollaborationsdiagramm (Abb. 5.8)  54

5.4.4  Änderungen am Zustandsdiagramm (Abb. 5.9)  54

6  Evaluierung der Werkzeuge  55

6.1  Vorauswahl  55

6.2  Bewertungsnotation  55

6.3  INNOVATOR 8.0  56

6.3.1  Einführung und Beschreibung  56

6.3.2  Bewertung gegenüber dem Kriterienkatalog  57

6.3.3  Bewertung gegenüber dem Änderungskatalog  68

6.4  Together Control Center 6.1  71

6.4.1  Einführung und Beschreibung  71

3

6.4.2  Bewertung gegenüber dem Kriterienkatalog  72

6.4.3  Bewertung gegenüber dem Änderungskatalog  81

6.5  Rational Rose Enterprise Edition  86

6.5.1  Einführung und Beschreibung  86

6.5.2  Bewertung gegenüber dem Kriterienkatalog  86

6.5.3  Bewertung gegenüber dem Änderungskatalog  95

6.6  Poseidon for UML Professional Edition 2.0.2  100

6.6.1  Einführung und Beschreibung  100

6.6.2  Bewertung gegenüber dem Kriterienkatalog  100

6.6.3  Bewertung gegenüber dem Änderungskatalog  108

7  Auswertung  113

7.1  Ausschlusskriterien  113

7.2  Allgemeine Kriterien für CASE-Werkzeuge  113

7.3  Spezielle Kriterien für CASE-Werkzeuge  114

7.4  Spezielle Kriterien bzgl. der Modellierung mit der UML  115

7.5  Modellierung des Referenzmodells  115

7.6  Zusammenfassung  115

8  Zusammenfassung und Ausblick  117

Literaturverzeichnis   118

Abbildungsverzeichnis   119

Anhang 123   

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

¹ Computer Aided Software Engineering

6 KAPITEL 1. EINLEITUNG

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, zeitkritische 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 Begriffe 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 Anwendungsfalldiagramm 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 Anforderungsermittlung und kein Designansatz oder eine Beschreibung des internen Verhaltens eines zu entwickelnden Systems. Primär werden Anwendungsfälle dazu verwendet die Kommunikation mit Anwendern und Auftraggebern zu unterstützen. Sie beschreiben das externe 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 Anwendungsfalldiagramms.

8 KAPITEL 2. EINFÜHRUNG IN UML 1.4

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 mehreren ausgehenden Transitionen (Zustandsübergängen), die automatisch dem Abschluss der internen Aktion folgen. Sie stellt somit einen einzelnen Schritt in einem Verarbeitungsablauf 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 eingehenden und ausgehenden Transitionen der zusammengesetzten Aktivität und des Detailmodells übereinstimmen.

Aktivitätsdiagramme lassen sich in Verantwortungsbereiche unterteilen. Dadurch können 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 Entscheidungslogik 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ätsbeschreibung, 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 Transitionen implizit durch den Abschluss der Aktivität ausgelöst werden.

Bedingungen und Verzweigungen

Ausgehende Transitionen können mit in eckigen Klammern stehenden Bedingungen (boolsche Ausdrücke) versehen werden. Als Alternative können Verzweigungen, dargestellt durch Rauten (Abb. 2.3), verwendet werden. Eine solche Raute stellt ebenfalls eine Entscheidungsaktivität dar.

Und- und Oder-Synchronisation

2.2. AKTIVITÄTSDIAGRAMM 9

Transitionen können synchronisiert, zusammengeführt und aufgeteilt werden (Abb. 2.4). Bei einer Zusammenführung von mehreren Transitionen setzt sich der Aktionsfluss fort, sobald eine Transition eingeht. Die Synchronisation setzt dagegen voraus, dass alle eingehenden Transitionen vorliegen.

Abbildung 2.4: Synchronisation.

Zusammengesetzte Aktivitäten

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

10 KAPITEL 2. EINFÜHRUNG IN UML 1.4

Schleifen

Für eine Schleife ist lediglich eine Abbruchbedingung und eine zurückführende Transition notwendig (Abb. 2.6). Innerhalb der Schleife sind beliebig viele Aktivitäten zulässig.

Optionale Aktivitäten

Vor einer optionalen Aktivität (Abb. 2.7) wird eine bedingte Verzweigung notiert. Die Zweige werden anschließend wieder zusammengeführt.

Signale senden und empfangen

Signale können beim Übergang zwischen zwei Aktivitäten an ein Objekt gesendet werden. 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 11

Objektzustand

Aktivitäten rufen häufig Änderungen am Objektzustand hervor. Ein Objektzustand wird durch ein Rechteck mit dem Objektnamen und dem Objektzustand in eckigen Klammern notiert. Eine gestrichelte Transitionslinie von einem Objektzustand zu einer Aktivität bedeutet, dass die Aktivität einen Ausgangszustand verlangt. Umgekehrt zeigt der Objektzustand den aus einer Aktivität resultierenden Zustand. Die Notation von Objektzuständen (Abb. 2.9) ist optional und dient der Hervorhebung besonderer Sachverhalte.

2.3 Klassendiagramm

Klassendiagramme werden verwendet, um die statische Struktur eines Systems zu dokumentieren. Dazu gehört zu ermitteln, welche Klassen es gibt und in welcher Beziehung sie zueinander stehen. Im Folgenden werden die einzelnen Elemente von Klassendiagrammen 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

12 KAPITEL 2. EINFÜHRUNG IN UML 1.4

stellen die in einer Anwendung zur Programmlaufzeit agierenden Einheiten dar. Operationen 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 Operation.

Eine Klasse wird, wie in Abbildung 2.10 gezeigt, durch ein Rechteck mit einem Klassennamen und ggf. Attributen und Operationen dargestellt. Klassenname, Attribute und Operationen werden dabei jeweils durch eine horizontale Linie getrennt. Ein Klassenname ist ein Substantiv und beginnt mit einem Großbuchstaben.

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 unterstrichen werden, um sie von normalen Operationen und Attributen unterscheiden zu können. Abbildung 2.11 zeigt die Notation einer Metaklasse.

Parametrisierbare Klasse

Eine parametrisierbare Klasse definiert eine Schablone zur Erzeugung von Klassen. In statisch typisierten Sprachen sind parametrisierbare Klassen ein wichtiges Hilfsmittel 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.16).

2.3. KLASSENDIAGRAMM 13

Abstrakte Klasse

Eine abstrakte Klasse ist eine allgemeine Oberklasse für eine Menge von konkreten Unterklassen. Abstrakt bedeutet, dass für mindestens eine ihrer Operationen keine Implementierung existiert. Darum ist es auch nicht möglich eine abstrakte Klasse zu instantiieren. 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.

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.

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

14 KAPITEL 2. EINFÜHRUNG IN UML 1.4

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.

Klassen-Objekt-Beziehungen werden durch einen gestrichelten Pfeil (Abb. 2.16) dargestellt. Dabei zeigt das Objekt auf seine Klasse.

Schnittstelle, Schnittstellenklasse

Mit einer Schnittstelle wird das externe Verhalten von Klassen spezifiziert. Sie beinhaltet eine Menge von Signaturen für Operationen, welche durch eine Klasse implementiert werden muss, die diese bestimmte Schnittstelle bereitstellen will. Schnittstellen werden mit dem Stereotyp «interface» gekennzeichnet (Abb. 2.17). Eine Schnittstellen-Klasse ist abstrakt und definiert ausschließlich abstrakte Operationen. Eine Kennzeichnung der Operationen mit abstrakt ist deshalb nicht erforderlich.

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. Zwischen der implementierenden Klasse und der Schnittstellenklasse besteht eine Realisierungsbeziehung, 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 werden durch das Stereotyp «extend» ausgedrückt. Zu beachten ist dabei, dass nur abstrakte 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 15

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. Vorbedingungen, 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 Eigenschaften zusichern u.v.m.

Zusicherungen können frei formuliert oder als Eigenschaftswert, Stereotyp oder Abhängigkeit notiert werden. Es besteht die Möglichkeit, sie an andere Notationselemente wie Attribute, Operationen, Klassen und jede Form von Klassenbeziehungen anzuhängen.

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ührliche 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.

16 KAPITEL 2. EINFÜHRUNG IN UML 1.4

So wie Attribute die Eigenschaften von Klassen näher bestimmen, können Eigenschaftswerte die Eigenschaften von beliebigen Modellelementen genauer beschreiben. Eigenschaftswerte können beliebig und willkürlich vergeben werden. Es ist jedoch sinnvoll, 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:

Stereotyp

Mit Hilfe von Stereotypen werden die Verwendungsmöglichkeiten von Modellelementen 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 Ausprä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:

Generalisierung, Spezialisierung

Generalisierung und Spezialisierung sind Abstraktionsprinzipien zur hierarchischen Struk- turierung der Semantik eines Modells. Hierbei werden allgemeine Eigenschaften in

2.3. KLASSENDIAGRAMM 17

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 Oberklassen. 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 Unterscheidungsmerkmals, genannt Diskriminator (Abb. 2.20). Dieser stellt den entscheidenden Gesichtspunkt dar, unter dem die Strukturierung erfolgen soll und ist das Ergebnis einer Modellierungsentscheidung. Die Menge der Unterklassen mit gleichem Diskriminator wird Partition genannt.

Abbildung 2.20: Direkte und baumartige Notation von Vererbungsbeziehungen.

Man unterscheidet drei Arten von Vererbung: Spezialisierungsvererbung, Spezifikationsvererbung 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 Wertebereiche 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 überschrieben werden, dass sie keine strengeren Vorbedingungen haben dürfen als die der Oberklasse. Außerdem müssen die Nachbedingungen wenigstens so streng sein wie die der Oberklasse.

Die Implementierungsvererbung dient lediglich der Wiederverwendung von Eigenschaften der Oberklassen und ist durch rein technische Gesichtspunkte begründet. Konzeptionelle Argumente spielen dabei keine Rolle.

Mehrfachvererbung

Wenn eine Klasse mehr als eine Oberklasse besitzt, so spricht man von Mehrfachvererbung. Sie wird nicht von allen Programmiersprachen unterstützt, da durch sie verschiedene Probleme auftreten können. So z.B., wenn verschiedene Oberklassen Eigenschaften mit gleichen Namen haben. In diesem Fall muss die Eigenschaft mit der Oberklassenbezeichnung angesprochen werden. In Abbildung 2.21 werden Mehrfach- vererbungsbeziehungen dargestellt.

18 KAPITEL 2. EINFÜHRUNG IN UML 1.4

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

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 19

Attributierte Assoziation

Eine attributierte Assoziation kann verwendet werden, wenn Attribute und Operationen keiner der beiden beteiligten Klassen zugeordnet werden können, da sie Eigenschaften der Beziehung sind. Die Eigenschaften der Beziehung werden daher als Klasse modelliert, die der Assoziation zugeordnet ist. Dabei haben Assoziation und Assoziationsklasse 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.

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.

20 KAPITEL 2. EINFÜHRUNG IN UML 1.4

Abgeleitete Assoziation

Die Objektbeziehungen einer abgeleiteten Assoziation können aus den Werten anderer Objektbeziehungen und ihrer Objekte bestimmt werden. Sie wird wie eine normale Assoziation notiert, mit dem Unterschied, dass ihr Name mit einem Schrägstrich eingeleitet wird. Außerdem kann die Ableitungsvorschrift als Zusicherung notiert werden (Abb. 2.26).

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.

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 21

Spezialisierte Assoziation

Eine spezialisierte Assoziation (Abb. 2.28) ist eine normale Assoziation, die eine Spezialisierungsbeziehung zu einer anderen Assoziation unterhält. So wie bei Klassen erbt die spezialisierte Assoziation (Unterassoziation) von der allgemeineren Assoziation (Oberassoziation).

Durch Spezialisierungsbeziehungen entstehen keine neuen Objektbeziehungen. Zwischen 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.

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 1 jedes Element nur einmal enthalten sein darf (im Gegensatz zum Bag 2 ). 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

22 KAPITEL 2. EINFÜHRUNG IN UML 1.4

Aggregation

Eine Aggregation ist eine Zusammensetzung eines Objektes aus einer Menge von Einzelteilen. 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 Nachrichten an seine Einzelteile weiterleiten. Dies wird Propagieren von Operationen genannt.

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

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

2.3. KLASSENDIAGRAMM 23

Komposition

Die Komposition ist eine spezielle Variante der Aggregation, bei der die Teile vom Ganzen 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.

Abhängigkeitsbeziehung

Eine Abhängigkeitsbeziehung zwischen zwei Modellelementen zeigt an, dass die Änderung 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.

24 KAPITEL 2. EINFÜHRUNG IN UML 1.4

Verfeinerungsbeziehung / Realisierungsbeziehung

Verfeinerungsbeziehungen werden dazu verwendet den unterschiedlichen Detaillierungsgrad zwischen gleichartigen Elementen darzustellen. Eine Realisierungsbeziehung beschreibt 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.

2.4 Sequenzdiagramm

Ein Sequenzdiagramm (Abb. 2.36) zeigt eine Reihe von Nachrichten, die eine Menge 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 zwischen den Objekt-Linien gezeichnet. Eine Nachricht wird in der Form nachricht(argumente) auf die Pfeile notiert. Die Antwort wird ähnlich wie beim Kollaborationsdiagramm in Textform (antwort:=nachricht) oder als eigener, gestrichelter Pfeil mit offener Pfeilspitze dargestellt.

Um zu verdeutlichen, welches Objekt gerade aktiv ist, werden die gestrichelten Lebenslinien 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 25

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

2.5 Kollaborationsdiagramm

Ein Kollaborationsdiagramm beschreibt eine Menge von Interaktionen zwischen ausgewä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 Objekt an sich selbst schickt ist keine Assoziation notwendig. Neben der zeitlichen Abfolge, den Namen, Antworten und den möglichen Argumenten der Nachrichten, können ebenso Iterationen bzw. Nachrichten-Schleifen in Kollaborationsdiagrammen dargestellt werden. Sie sind ein Hilfsmittel, um spezielle Ablaufsituationen 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-

26 KAPITEL 2. EINFÜHRUNG IN UML 1.4

den ggf. Argumente oder mögliche Antworten. Sequenznummern, beginnend bei eins, verdeutlichen die zeitliche Abfolge der Nachrichten. Die von außen kommende Nachricht (Startnachricht) wird ohne Nummer dargestellt. Sie kann optional auch von einem Akteursymbol ausgehen. Abbildung 2.38 zeigt ein Beispiel eines Kollaborationsdiagramms.

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 Nachrichten, 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 aufsteigende 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 empfangene 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 Argument in anderen Nachrichten verwendet werden kann. Der Name ist, ähnlich wie eine lokale Variable, innerhalb der sendenden Nachricht gültig.