Klassendiagramm

Klassendiagramm

Zweck

Klassendiagramme stellen die statische Struktur eines Systems dar. Sie zeigen die Klassen, die Eigenschaften der Klassen (Attribute), das Verhalten (Operationen) der Klassen und die Beziehungen zwischen den Klassen.

Sie sind der zentrale Diagrammtyp der UML und werden in allen Phasen der Soft­wareentwicklung eingesetzt.

Notation

Symbol Bedeutung
Klasse
Ein Klasse kann als Rechteck dargestellt werden, das den Klassennamen enthält. Üblicherweise bestehen Klassen aus drei Bereichen; der obere Bereich enthält den Stereotyp, das Paket zu dem die Klasse gehört und den Namen. Im mittleren Bereich werden die Attribute angegeben und im unteren Bereich stehen die Opera­tionen der Klasse. Laut UML-Spezifikation kann die Darstellung einer Klasse zusätzliche Bereiche enthal­ten.
Abstrakte Klasse Der Name einer abstrakten Klasse wird kursiv ge­schrieben. Alternativ kann die Eigenschaft {abstract} angegeben werden. Abstrakte Klassen dienen der Strukturierung eines Modells. Sie sind nicht instanziierbar.
Parametrisierte Klasse auch Template oder Schablone genannt. Die parame¬≠trisierte Klasse hat in der rechten, oberen Ecke ein das Klassensymbol √ľberlappendes Rechteck, das die Scha¬≠blonen-Parameter der Klasse enth√§lt. Die Funktion, die den Parameter verwendet wird angegeben. Die Klasse, die den Parameter bindet, wird √ľber eine gestrichelte Linie mit Pfeil an dem Template verbunden. Diese tr√§gt die Bezeichnung <<bind>>.
Assoziation Eine Linie zwischen den Klassen stellt eine Assoziati¬≠on dar. Eine Assoziation ist eine Beziehung zwischen Klassen. Die Objekte der Klassen kommunizieren √ľber die Assoziationen miteinander. Die Assoziation kann einen Namen haben. Ein Pfeil an dem Assoziations¬≠namen gibt die Leserichtung des Namens an. An den Assoziationsenden k√∂nnen die Rollen der beteiligten Klassen und die Multiplizit√§t angegeben werden. Die zweigliedrige Assoziation kann, wie die mehrgliedrige Assoziation, durch eine Raute markiert werden.
Gerichtete Assoziation
Mit einem Pfeil an der Assoziation kann die Naviga¬≠tionsrichtung angegeben werden. Der Pfeil dr√ľckt die Zugriffsrichtung der Objekte aus. Objekt A greift auf B zu, B greift nie auf A zu.
Vererbung auch Generalisierung/Spezialisierung genannt. Verer­bungsbeziehungen werden mit einem Pfeil dargestellt. Die Pfeilspitze zeigt auf die Oberklasse. Die Ober­klasse vererbt ihre Eigenschaften an die Unterklassen.
Aggregation
Eine Aggregation dr√ľckt eine Teile-Ganzes-Beziehung aus. Das Ganze-Objekt besteht aus Teil-Objekten. Die Raute befindet sich an dem Ende des Ganzen. Die Aggregation ist eine spezielle Art der Assoziation. Da das Ganze die Teile enth√§lt, sollten am Assoziations¬≠ende der Teile ein Navigationspfeil stehen.
Komposition
Die Komposition ist auch eine Beziehung, die Teile zu einem Ganzen in Beziehung setzt. Die Teile und das Ganze sind bei dieser Beziehung existenzabhängig; die Teile können nicht ohne das Ganze existieren. Wird das Ganze gelöscht, so beenden auch die Teile ihre Existenz.
Assoziationsklasse
Ist eine Klasse von dem Vorhandensein einer Assozia¬≠tion zwischen zwei Klassen abh√§ngig, so kann dies durch eine Assoziationsklasse ausgedr√ľckt werden. Die Assoziationsklasse beschreibt Eigenschaften, die keiner der an der Assoziation beteiligten Klassen sinn¬≠voll zuordenbar sind. Die Assoziationsklasse wird √ľber eine gestrichelte Linie mit der Assoziation, von der sie abh√§ngt, verbunden. Hat die Assoziation einen Namen, dann muss die Assoziationsklasse den selben Namen erhalten. Die Assoziationsklasse ist ein Analy¬≠sekonzept.
Mehrgliedrige Assoziation Eine mehrgliedrige Assoziation dr√ľckt eine Beziehung zwischen mehr als 2 gleichwertigen Klassen aus. Die Beziehung wird mit einer Raute markiert.



Klassen

Objekte und Klassen sind die zentralen Elemente objektorientierter Modelle. Die gemeinsamen Eigenschaften konkreter Objekte werden zu Klassen abstrahiert. Die Klasse definiert die Struktur ihrer Objekte. Die UML 2.0 versteht unter einer Klasse ein Element, das eine Menge Objekte beschreibt, die die selbe Spezifikati­on der Merkmale, Einschränkungen und Semantik teilen [Omg 03b]. Eine Klasse hat Attribute und Operationen. Attribute und Operationen können in UML spezifiziert werden.

Die Syntax f√ľr die Deklaration von Attributen lautet: [Sichtbarkeit] [/] Name [:Typ] [=Wert]

Die Syntax f√ľr die Deklaration von Operationen lautet: [Sichtbarkeit] Name [(Parameterliste)] [: Returntyp]

Die Parameterliste ist definiert als:[√úbergaberichtung] Name [: Typ] [ =Wert]

Die Syntaxelemente

  • Sichtbarkeit: gibt an, wie die Sichtbarkeit eines Elementes relativ zu seiner Umgebung ist. Die Sichtbarkeit gibt also an, welche Elemente auf ein Attribut, bzw. auf eine Operation zugreifen k√∂nnen. Der Zugriff auf ein Attribut definiert den lesenden und schreibenden Zugriff auf das Attribut; die Sichtbarkeit von Operationen gibt an, welche Elemente die Operation aufrufen k√∂nnen. Folgende Sicht¬≠barkeitsmodi sind definiert.

    • public: Jedes andere Element hat Zugriff.

    • privat: Der Zugriff ist auf die Objekte der Klasse selbst beschr√§nkt.

    • protected: Zugriff besteht nur f√ľr die definierende Klasse und die Verer¬≠bungslinien, die von ihr ausgehen.

    • package: Das Element ist sichtbar f√ľr alle Klassen, die sich im selben Paket befinden.

  • Der Slash [/] kennzeichnet ein abgeleitetes Element. Ein abgeleitetes Element kann aus einem anderen Modellelement berechnet werden.

  • Name: gibt den Namen des Attributs oder der Operation an.

  • Typ, Returntyp: gibt den Datentyp eines Attributs, eines Parameters oder Returns an. Die UML definiert einige Typen, wie Integer, String, u. a. Macht aber keine Ein¬≠schr√§nkungen zur Verwendung selbstdefinierter Typen. Es k√∂nnen alle Typen verwendet werden, die zur L√∂sung eines Problems ben√∂tigt werden.

  • Wert: Attribute und Parameter k√∂nnen mit einem Wert belegt werden.

  • √úbergaberichtung: definiert die Richtung in die ein Parameter √ľbergeben wird.

    • IN- Parameter wird an die Operation √ľbergeben. Die Operation liest den Pa¬≠rameter nur.

    • OUT - der Parameter wird von der Operation geschrieben, ohne dass sie sei¬≠nen Inhalt vorher verarbeitet.

    • INOUT - die Operation liest einen Parameter, verarbeitet ihn und schreibt ihn erneut.

 

Anwendungsbereich

Klassendiagramme sind der zentrale Diagrammtyp der UML. Sie beschreiben die Klassen eines Systems, ihre Eigenschaften, Operationen und die Beziehungen zwischen den Klassen. Klassendiagramme werden in allen Phasen der Software¬≠entwicklung eingesetzt. Die modellierten Inhalte und das verwendete Vokabular m√ľssen sich an dem Know-how der beteiligten Personengruppen orientieren. Ein Klassendiagramm modelliert einen Teilausschnitt der realen Welt. Es werden nur die Klassen und Eigenschaften ber√ľcksichtigt, die zur Beschreibung des Problem¬≠bereichs ben√∂tigt werden. Bei der Modellierung von Klassendiagrammen wird zwischen dem Analysemodell und dem Designmodell unterschieden.

Diese verschiedenen Sichten auf ein Klassenmodell können durch den Einsatz von Entwicklungswerkzeugen, wie z. B. Case-Tools verwaltet und konsistent gehalten werden.

 

Klassendiagramm Analyse

Klassendiagramme in der Sichtweise der Analyse stellen dar, was das System aus Anwendersicht leisten soll. Sie bilden die Klassen, Attribute, Operationen und ihre Beziehungen ab, die das spätere Softwaresystems aus der Sicht des fachlichen Be­reiches, den es abdecken soll, enthalten muss.

Das Analysemodell beschreibt was die zuk√ľnftige Software aus fachlicher Sicht leisten soll.

F√ľr die Informatikabteilung, die das geplante Produkt entwickeln soll, stellt das Analysemodell die Basis der zuk√ľnftigen Entwicklungsarbeit dar. Da Fehler in der Analyse sehr teuer sind, muss das Analysemodell sehr sorgf√§ltig modelliert werden.

In der Analyse sollten sprechende Namen verwendet werden, die auch die betei­ligte Fachabteilung versteht. Die Deklaration von Attributen und Operationen wird in UML, nicht in der späteren Programmiersprache vorgenommen. Bei Ein­satz eines CASE-Tools können daraus die Deklarationen in der gewählten Pro­grammiersprache generiert werden.

 

Klassendiagramm Design

Im Designmodell wird das Analysemodell auf die Implementierungstechnologie abgebildet. Klassendiagramme in der Sichtweise Design stellen dar, wie das Sys­tem technisch aufgebaut sein muss, damit es die in der Analyse geforderten Eigen­schaften realisieren kann. Die in der Systemanalyse erkannten und dokumentierten Strukturen werden um die Informationen, die nötig sind um das fachliche Modell zu implementieren, erweitert.

Im Design wird die Implementierungssprache festgelegt. Es wird definiert wie Assoziationen zu implementieren sind; die Art und Weise wie die Instanzen der Klassen verwaltet werden, wird festgelegt. Die Persistenzschicht wird modelliert, d. h. es wird definiert, wie die Klassen auf eine Datenbank abgebildet werden; die Datenbank wird ausgew√§hlt. In der Regel werden bei der Implementierung eines Modells Klassenbibliotheken verwendet, deren Verwendung im Klassenmodell dokumentiert werden muss. Die Benutzeroberfl√§che muss eingef√ľhrt werden.

Zusammenhang

Klassen werden in fast allen UML-Diagrammen verwendet. Die Klassen des Klassendiagramms wirken sich deshalb auf alle anderen Diagramme aus und sind mit den anderen Diagrammen eines Modells konsistent zu halten.


Hinweise f√ľr die Praxis

Klassen identifizieren

Die UML definiert eine umfangreiche Notation zur Modellierung von Software¬≠systemen. Vor der Modellierung der Struktur von Softwaresystemen m√ľssen je¬≠doch aus nat√ľrlichsprachigen Dokumentationen der Anforderungen an Systeme die enthaltenen fachlichen Objekte identifiziert werden. Alle Klassen, die den Pro¬≠blembereich f√ľr eine geplant Anwendung beschreiben, sind fachliche Klassen. Diese Klassen beschreiben die wichtigsten Merkmale der Anwendung.

Wie findet man die in einem Text die enthaltenen Klassen? Es gibt zwei Techniken, die hier kurz skizziert werden.

 

Substantivmethode

Rumbaugh empfiehlt in [Rumbaugh, 1991] die Substantiv-Methode zur Identifikation von Klassen. Aus den Anforderungsdefinitionen an ein geplantes System werden alle Substantive markiert. Diese Begriffe sind potenzielle Klassenkandidaten. Da­nach werden redundante Begriffe eliminiert. Alle Begriffe, die auf die technische Realisierung der Begriffe hindeuten werden beseitigt. Durch diese kritische Analyse der Texte erhält man eine Menge Begriffe, die als Klassen im geplanten System verwendet werden können.

 

CRC-Methode

CRC bedeutet Class, Responsibility, Collaboration und bezeichnet eine Technik bei der f√ľr jede potenzielle Klasse eine Karteikarte angelegt wird, die drei Ab¬≠schnitte enth√§lt:

  • class ‚Äď Klassennamen

  • resposibility ‚Äď Zust√§ndigkeit

  • collaboration - Zusammenarbeit

 

F√ľr jede Klasse wird der Klassenname notiert. Im Abschnitt Zust√§ndigkeit wird beschrieben f√ľr welchen Zweck die Klasse eingef√ľhrt wurde, und unter Zu¬≠sammenarbeit wird angegeben mit welchen anderen Klassen sie zusammenarbei¬≠tet.

Die Substantivmethode und die CRC-Methode können auch kombiniert verwendet werden, indem man die Substantivmethode zum Auffinden der Klassen verwendet und die Klasseneigenschaften danach mit CRC-Karten (oder einem Texteditor) beschreibt.

 

Attribute identifizieren

Attribute sind die Eigenschaften der Klassen. Attribute sollten nur von der Klasse zu der sie geh√∂ren abh√§ngig sein. Bei der Suche nach Attributen muss die Frage beantwortet werden: Was muss die Klasse √ľber sich selbst wissen, damit sie arbei¬≠ten kann? Die Adjektive in der Anforderungsdefinition sind Kandidaten f√ľr At¬≠tribute.

 

Operationen identifizieren

Operationen sind die √∂ffentlich aufrufbaren Funktionen einer Klasse. Operationen sind die Schnittstellen einer Klasse, √ľber die sie die Dienste, die sie implementiert, allen anderen Klassen des Systems anbietet.

 

Assoziationen identifizieren

Objekte kommunizieren √ľber Assoziationen miteinander. Bei der Suche nach Assoziationen muss die Frage gestellt werden: Welche Objekte kommunizieren miteinander? In einem Projekt sind aber nur die Assoziationen zu modellieren, die zur L√∂sung des gestellten Problems ben√∂tigt werden. Die Verben in der An¬≠forderungsdefinition geben Hinweise auf m√∂gliche Assoziationen.

 

Vererbungsstrukturen identifizieren

Bei der Suche nach Vererbungsstrukturen sucht man gemeinsame Eigenschaften von Klassen, die in einer Oberklasse zusammengefasst werden können. Die Unter­klasse muss alle geerbten Eigenschaften verwenden. Vererbung liegt dann vor, wenn eine Klasse eine Speziallfall einer anderen Klasse ist. Zwischen Oberklasse und Unterklasse besteht immer eine "ist-ein" Beziehung.

 

Style Guide

  • Vererbungshierarchien sollten von oben nach unten angeordnet werden. Unter¬≠klassen sollten unterhalb ihrer Oberklasse stehen.

  • Kreuzungen zwischen Beziehung sollten minimiert werden.

  • Wird ein Klassendiagramm zu gro√ü f√ľr eine Seite (einen Bildschirm), sollte es √ľber mehrere Seiten in Teildiagramme verteilt werden. F√ľr die Aufteilung der Klassen in Teildiagramme sollten fachliche Kriterien herangezogen werden.

Beispiel

Die nachfolgende Abbildung zeigt das Klassendiagramm zu dem Mensa-Beispiel. Die "MensaKarte" wird von einer abstrakten "H_Da_Karte" abgeleitet. Das Attribut "ID" der "H_Da_Karte" hat die Sichtbarkeit protected und wird an die "MensaKarte" vererbt. "MensaAutomat" und "Kasse" stehen jeweils √ľber Aggregationen in Be¬≠ziehung zu den angegebenen Klassen. "Display" und "Kartenleser" sind Teil von zwei Klassen. Da das Beispiel ein Analysemodell darstellt, sind nur Analyseeigenschaften dargestellt. Es sind keine Elemente modelliert, die sich auf die Implementierung beziehen.