B. Rumpe: Agile Modellierung mit UML

<< zurück

weiter >>

3.1 Klassendiagramme

Klassendiagramme bilden das architekturelle Rückgrat vieler Systemmodellierungen. Dementsprechend haben Klassendiagramme und darin besonders Klassen eine Reihe von Aufgaben zu erfüllen (Abbildung 3.1): Klassendiagramme beschreiben die Struktur beziehungsweise Architektur eines Systems, auf der nahezu alle anderen Beschreibungstechniken basieren. Das Konzept Klasse ist durchgängig in Modellierung und Programmierung eingesetzt und bietet daher ein Rückgrat für Traceability von Anforderungen und Fehlern entlang der verschiedenen Aktivitäten eines Projekts. Klassendiagramme bilden das Skelett für fast alle weiteren Notationen und Diagrammarten, da diese sich jeweils auf die in Klassendiagrammen definierten Klassen und Methoden stützen. So werden in der Analyse Klassendiagramme genutzt, um Konzepte der realen Welt zu strukturieren, während in Entwurf und Implementierung Klassendiagramme vor allem zur Darstellung einer strukturellen Sicht des Softwaresystems genutzt werden.

Die Aufgaben einer Klasse sind:

Kapselung von Attributen und Methoden zu einer konzeptuellen Einheit
Ausprägung von Instanzen als Objekte
Typisierung von Objekten
Implementierungsbeschreibung
Klassencode (die übersetzte, ausführbare Form der Implementierungsbeschreibung)
Extension (Menge aller zu einem Zeitpunkt existierenden Objekte)
Charakterisierung der möglichen Strukturen eines Systems

Abbildung 3.1: Aufgabenvielfalt einer Klasse

3.1.1 Klassen und Vererbung

Die Abbildung 3.2 enthält eine Einordnung der wichtigsten Begriffe für Klassendiagramme.

Klasse: Eine Klasse besteht aus einer Sammlung von Attributen und Methoden, die den Zustand und das Verhalten ihrer Instanzen (Objekte) festlegt. Klassen sind durch Assoziationen und Vererbungsbeziehungen miteinander verknüpft. Ein Klassenname erlaubt es, die Klasse zu identifizieren.
Attribut: Die Zustandskomponenten einer Klasse werden als Attribute bezeichnet. Sie beinhalten grundsätzlich Name und Typ.
Methode: Die Funktionalität einer Klasse ist in Methoden abgelegt. Eine Methode besteht aus einer Signatur und einem Rumpf, der die Implementierung beschreibt. Bei einer abstrakten Methode fehlt der Rumpf.
Modifikator: Zur Festlegung von Sichtbarkeit, Instanziierbarkeit und Veränderbarkeit des modifizierten Elements können die Modifikatoren public, protected, private, readonly, abstract, static und final auf Klassen, Methoden und Attribute angewandt werden. Für die ersten vier genannten Modifikatoren gibt es in UML/P die graphischen Varianten „+“, „#“ und „-“ und „?“.
Konstanten: sind als spezielle Attribute mit den Modifikatoren static und final definiert.
Vererbung: Stehen zwei Klassen in Vererbungsbeziehung, so vererbt die Oberklasse ihre Attribute und Methoden an die Unterklasse. Die Unterklasse kann weitere Attribute und Methoden hinzufügen und Methoden redefinieren – soweit die Modifikatoren dies erlauben. Die Unterklasse bildet einen Subtyp der Oberklasse, der es nach dem Substitutionsprinzip erlaubt, Instanzen der Unterklasse dort einzusetzen, wo Instanzen der Oberklasse erforderlich sind.
Interface: Ein Interface (Schnittstelle) beschreibt die Signaturen einer Sammlung von Methoden. Im Gegensatz zur Klasse werden keine Attribute (nur Konstanten) und keine Methodenrümpfe angegeben. Interfaces sind verwandt zu abstrakten Klassen und können untereinander ebenfalls in einer Vererbungsbeziehung stehen.
Typ: ist ein Grunddatentyp wie int, eine Klasse oder ein Interface.
Interface-Implementierung: ist eine der Vererbung ähnliche Beziehung zwischen einem Interface und einer Klasse. Eine Klasse kann beliebig viele Interfaces implementieren.
Assoziation: ist eine binäre Beziehung zwischen Klassen, die zur Realisierung struktureller Information verwendet wird. Eine Assoziation besitzt einen Assoziationsnamen, für jedes Ende einen Rollennamen, eine Kardinalität und eine Angabe über die Navigationsrichtungen.
Kardinalität: Die Kardinalität (Multiplicity) wird für jedes Assoziationsende angegeben. Sie ist von der Form „0..1“, „1“ oder „⋆“ und beschreibt, ob eine Assoziation in dieser Richtung optional oder eindeutig ist beziehungsweise mehrfache Bindung erlaubt.

Abbildung 3.2: Begriffsdefinition für Klassendiagramme

In Abbildung 3.3 ist ein einfaches Klassendiagramm bestehend aus einer Klasse zu sehen. Je nach Grad der Detaillierung können Attribute und Methoden der Klassen weggelassen oder nur teilweise angegeben werden. Auch Typen von Attributen und Methoden, Sichtbarkeitsangaben und weitere Modifikatoren sind optional.

Abbildung 3.3: Eine Klasse im Klassendiagramm

Zur Strukturierung von Klassen in überschaubare Hierarchien wird die Vererbungsbeziehung eingesetzt. Abbildung 3.4 demonstriert Vererbung und Interface-Implementierung anhand der Gemeinsamkeiten mehrerer Nachrichtenarten des in Kapitel D, Band 1 beschriebenen Auktionssystems. Die Erweiterung von Interfaces ist darin nicht abgebildet. Sie wird wie die Vererbung zwischen Klassen dargestellt.

Abbildung 3.4: Vererbung und Interface-Implementierung

3.1.2 Assoziationen

Eine Assoziation dient dazu, Objekte zweier Klassen in Beziehung zu setzen. Mithilfe von Assoziationen können komplexe Datenstrukturen gebildet werden und Methoden benachbarter Objekte aufgerufen werden. Abbildung 3.5 beschreibt einen Ausschnitt aus dem Auktionssystem mit mehreren Assoziationen in unterschiedlichen Formen.

Abbildung 3.5: Klassendiagramm mit Assoziationen

Eine Assoziation besitzt im Normalfall einen Assoziationsnamen und für jedes der beiden Enden je eine Assoziationsrolle, eine Angabe der Kardinalität und eine Beschreibung der möglichen Navigationsrichtungen. Einzelne Angaben können im Modell auch weggelassen werden, wenn sie zur Darstellung des gewünschten Sachverhalts keine Rolle spielen und die Eindeutigkeit nicht verloren geht.

Assoziationen können grundsätzlich uni- oder bidirektional sein. Ist keine explizite Pfeilrichtung angegeben, so wird von einer bidirektionalen Assoziation ausgegangen. Formal werden die Navigationsmöglichkeiten in dieser Situation als unspezifiziert und damit nicht als eingeschränkt betrachtet.

Eine besondere Form der Assoziation ist die Komposition. Sie wird durch eine ausgefüllte Raute an einem Assoziationsende dargestellt. In einer Komposition sind die Teilobjekte in einer starken auch den Lebenszyklus betreffenden Abhängigkeit vom Ganzen.

Der UML-Standard bietet eine Reihe zusätzlicher Merkmale für Assoziationen an, die Assoziationseigenschaften genauer regeln. Abbildung 3.6 beinhaltet einige häufig eingesetzte Merkmale, wie zum Beispiel {ordered}, das einen geordneten Zugriff mit Index erlaubt. Mit {frozen} wird angezeigt, dass nach der Initialisierung eines Auktionsobjekts die beiden Assoziationen zu den Policy-Objekten nicht mehr verändert werden. Mit {addOnly} wird modelliert, dass in der Assoziation nur Objekte hinzugefügt werden dürfen, das Entfernen jedoch verboten ist.

Abbildung 3.6: Merkmale für Assoziationen

Qualifizierte Assoziation bieten die Möglichkeit, aus einer Menge von zugeordneten Objekten mithilfe des Qualifikators ein einzelnes Objekt zu selektieren. Abbildung 3.7 zeigt mehrere auf unterschiedliche Weise qualifizierte Assoziationen.

Abbildung 3.7: Qualifizierte Assoziationen

Während in explizit qualifizierten Assoziationen die Art des Qualifikators wählbar ist, stehen in geordneten Assoziationen ganzzahlige Intervalle beginnend mit der 0 zur Verfügung.

3.1.3 Repräsentation und Stereotypen

Klassendiagramme haben oft das Ziel, die für eine bestimmte Aufgabe notwendige Datenstruktur einschließlich ihrer Zusammenhänge zu beschreiben. Eine vollständige Liste aller Methoden und Attribute ist für einen Überblick dabei eher hinderlich. Ein Klassendiagramm stellt daher meist eine unvollständige Sicht des Gesamtsystems dar. So können einzelne Klassen oder Assoziationen fehlen. Innerhalb der Klassen können Attribute und Methoden weggelassen oder unvollständig dargestellt werden.

Um einem UML-Diagramm anzusehen, ob die darin enthaltene Information vollständig ist, werden in UML/P die Repräsentationsindikatoren „… “ zur Markierung unvollständiger Information und „©“ zur Darstellung vollständiger Information verwendet (Abbildung 3.8).

Abbildung 3.8: Formen der Darstellung einer Klasse

Die Indikatoren „©“ und „… “ wirken nicht auf die Klasse selbst, sondern auf ihre Darstellung innerhalb des Klassendiagramms. Ein „©“ beim Klassennamen besagt, dass sowohl die Attribut- als auch die Methodenliste vollständig ist. Demgegenüber bedeutet der Unvollständigkeits-Indikator „… “, dass die Darstellung unvollständig sein kann.

Die beiden Repräsentationsindikatoren sind nur eine spezielle From von Merkmalen mit eigener syntaktischer Darstellung. Die UML bietet sehr allgemein die Möglichkeit, Modellelemente mit Stereotypen und Merkmalen zu markieren (Abbildung 3.9), die deren allgemeine Syntax die Formen ≪stereotyp≫, {merkmal} oder {merkmal=wert} hat.

Stereotyp: Ein Stereotyp klassifiziert Modellelemente wie beispielsweise Klassen oder Attribute. Durch einen Stereotyp wird die Bedeutung des Modellelements spezialisiert und kann so beispielsweise bei der Codegenerierung spezifischer behandelt werden. Ein Stereotyp kann eine Menge von Merkmalen besitzen.
Merkmal: Ein Merkmal beschreibt eine Eigenschaft eines Modellelements. Ein Merkmal wird notiert als Paar bestehend aus Schlüsselwort und Wert. Mehrere solche Paare können zu einer Liste zusammengefasst werden.
Modellelemente: sind die (wesentlichen) Bausteine der UML-Diagramme. Beispielsweise hat das Klassendiagramm als Modellelemente Klassen, Interfaces, Attribute, Methoden, Vererbungsbeziehungen und Assoziationen.
Merkmale und Stereotypen können auf Modellelemente angewandt werden, sind aber selbst keine Modellelemente.

Abbildung 3.9: Begriffsdefinition Merkmal und Stereotyp

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>