Im dritten Teil der Artikelserie zu UML geht es heute um etwas ganz wichtiges: das Klassendiagramm. Wie es sich für eine Einführung in UML gehört, nenne ich zunächst die Existenzgründe von Klassendiagrammen und wofür sie eingesetzt werden. Dann stelle ich ein einfaches Beispiel vor und erkläre anhand des Beispiels die Elemente eines Klassendiagramms.

Nachdem es im zweiten Teil der UML-Artikelserie um die Anwendungsfälle ging, die dem Programmierer die Anforderungen an ein Programm darlegen, wird es diesmal mit den Klassendiagrammen etwas technischer.

Was ist ein Klassendiagramm und wofür brauche ich es?

Die Aussage, dass das Klassendiagramm das liebste Kind des Programmierer ist, fällt mir nicht schwer, obwohl ich dafür keinen stichhaltigen Beweis habe. Betrachtet man jedoch die Struktur, den Aufbau und die Funktion eines Klassendiagramms, worauf ich noch eingehen werden, so merkt man, dass dieser Diagrammtyp dem Code objektorientierter Programmiersprachen sehr ähnlich ist. Daher wird jeder, der objektorientiertes Programmieren beherrscht, auch mit dem Klassendiagramm auf Anhieb zurechtkommen.

Gehen wir davon aus, dass die oben getroffene Aussage wahr ist, so ist das Klassendiagramm das wichtigste Diagramm der UML. Es gehört zu den Strukturdiagrammen, zu welchen auch das Anwendungsfalldiagramm gezählt wird. Was Klassendiagramme können lässt sich grob im folgenden Satz zusammenfassen:

Das Klassendiagramm zeigt, welche Klassen existieren, wie sie aufgebaut sind und in welchen Beziehungen sie zu einander stehen.

Somit ist die Struktur der einzelnen Klassen, die gemeinsame Struktur und das daraus resultierende gemeinsame Verhalten aus einem Klassendiagramm erkennbar. Die Betrachtung auf dieser abstrakten Ebene ermöglicht es, sich den Aufbau des Modells klarer zu machen.

Das wohl bekanntest Anwendungsfeld für Klassendiagramme ist wahrscheinlich die objektorientierte Modellierung als Vorarbeit für die Programmierung. Jedoch ist auch der umgekehrte Weg möglich: Liegt eine objektorientierter Code vor, so kann daraus ein UML-Klassendiagramm erstellt werden. Für beide Wege existieren automatische Generatoren, die entweder aus einem Klassendiagramm die Code-Struktur einer objektorientierter Programmiersprache erzeugen oder aus dem Code das Diagramm generieren.

Im folgenden Bild habe ich versucht, ein einfaches Klassendiagramm für den Inhalt eines Weblogs zu erstellen:

Es ist mir bewusst, dass das Diagramm keinesfalls vollständig ist. Aber ich denke, es erfüllt seinen Zweck, nämlich das erläutern der Elemente eines Klassendiagramms.

In dem Beispiel sind bereits folgende Elemente zu sehen:

• abstrakte Klasse: Content
• diverse Klassen: Datum, Autor, Artikel…
• Vererbungsbeziehung
• Assoziationsbeziehung
• Aggregationsbeziehung

Das ist nur eine kleine Auswahl der möglichen Elemente eines Klassendiagramms, welche ich unter anderem im nächsten Abschnitt näher erläutere.

Elemente eines Klassendiagramms

Das wichtigste Element des Klassendiagramms steht schon im Namen drin: die Klasse. Manchmal wird statt Klasse auch einfach Typ gesagt, was das gleiche meint. Eine Klasse bzw. ein Typ ist im Grunde eine Zusammenfassung der Eigenschaften (Attribute) und des Verhaltens (Operationen) der Objekte dieser Klasse. Symbolisiert wird eine Klasse mit einem Rechteck, welches im oberen Feld den Namen der Klasse enthält. Werden Attribute und Operationen angegeben, so stehen sie jeweils durch ein horizontalen Strich getrennt unter dem Namen. Jedoch ist es keine Pflicht, Attribute und Operatoren anzugeben. In dem Beispiel hat lediglich die Klasse “Content” ein Attribut und eine Operation.

Möchte man Attribute aufführen, dann kann man dies unterschiedliche Arten tun:

• nur Name
• Name und Typ
• Name, Typ und Anfangswert

Attribute, häufig auch Member genannt, werden an jedes Objekt einer Klasse weitergegeben. Jedoch hat wiederum jedes Objekt seine eigene Identität, was gleichbedeutend ist mit der Aussage, dass jedes Objekt zwar gleich Attribute hat, die Werte der Attribute aber durchaus verschieden sein können. In c++ können mit “static” sogenannte Klassenattribute definiert werden, welche in jedem Objekt verfügbar sind und den gleichen Wert besitzen.

Desweiteren ist es möglich für jedes Attribut die Sichtbarkeit von außen zu beschränken, was oft sehr sinnvoll ist. Dafür stehen grundsätzlich drei Varianten zur Verfügung:

• +: public: für alle sichtbar und benutzbar
• #: protected: sichtbar und benutzbar für die Klasse selbst und ihre Unterklassen
• -: private: nur für die Klasse selbst

In dem Klassen-Rechteck wird entsprechend der Sichtbarkeit eines Attributs das passende Zeichen (+,#,-) angegeben. Generell ist es ein guter Tipp, so zu programmieren, dass nur die Klassen selbst Zugriff auf ihre Attribute hat.

Die Operatoren, auch Memberfunktionen genannt, sind Dienstleistungen des Objekts und werden durch ihre Parameter charakterisiert. Die Parameterliste wird auch Signatur genannt.

Operatoren können wie Attribute auf unterschiedliche Weisen angegeben werden:

• nur Name
• Name und Parameter
• Name, Parameter mit Typ
• Name, Parameter mit Typ und Anfangswert

Außerdem können Operationen als abstrakt bzw. virtuell definiert werden, was bedeutet, dass keine Implementierung vorliegt, sondern nur die Deklaration der Operation. Dadurch wird die Klasse, welche die abstrakte Operation enthält, sofort zur abstrakten Klasse, aber dazu in wenigen Sätzen mehr.

Was nun letztendlich in der Attributen- und Operationenliste aufgeführt ist, ist stets problemspezifisch und hängt stark davon ab, was für das ordentliche Modellieren wichtig ist und was nur störend wirkt.

Der Name der Klasse wird generell in fetter Schrift geschrieben. Ist er fett und kursiv, so handelt es sich um eine abstrakte Klasse. Dieses weitere Element eines Klassendiagramms wird auch als virtuelle Klasse bezeichnet und kann keine eigenen Objekte erzeugen, da sie unvollständig ist. Zum Beispiel enthält sie eine abstrakte Funktion, die wir bereits kennen gelernt haben.
Eine abstrakte Klasse dient oft dazu, zu zeigen, dass es bestimmte Operationen und Attribute gibt, diese werden aber nicht konkret implementiert. Die abstrakte Klasse stellt daher eine Basis für weitere Klassen dar, welche dann die Implementierung beinhalten.

Ein weiteres Element ist die parametrisierbare Klasse. In c++ wird sie Template-Klasse genannt und stellt eine Schablone dar, welche einen formalen Parameter enthält, der bei der Erzeugung weiterer Klassen ersetzt wird. Mit dieser Technik kann leicht wiederverwendbarer Code erzeugt werden. Dargestellt wird die parametrisierbare Klasse durch ein zusätzliches rechteckiges Feld an der rechten oberen Ecke des Klassen-Feldes, welches den Namen des formalen Parameters enthält.

Klassen sind im Klassendiagramm nicht die handelnden Elemente, es sind ihre Objekte oder Instanzen. Die Eigenschaften und das Verhalten der Objekte wird durch die Klasse definiert (Attribute und Operationen). In der UML-Darstellung unterscheiden sich Objekte von ihren Klassen dadurch, dass dem Namen des Objekts im obersten Feld nach einem Doppelpunkt der Name der Klasse folgt. Das ganze wird auch noch unterstrichen. Das Objekt-Rechteck stellt nur Attribute mit den aktuellen oder Beispielwerten dar, Operationen sind nicht objektspezifisch und werden daher nicht angegeben.

Soweit zu den Klassen und ihren Objekten. Was noch fehlt sind die Verbindungen zwischen den Klassen, welche sehr vielfältig sind. Ich möchte an dieser Stelle lediglich vier vorstellen:

Die Assoziation beschreibt die Relation zwischen Klassen bzw. ihrer Objekte und wird entweder durch einen einfache Strich oder durch einen Pfeil dargestellt. Im Falle des Pfeils handelt es sich um eine gerichtete Assoziation und die Kommunikation kann nur in eine Richtung stattfinden. Im oberen Beispiel habe ich die Klasse “Artikel” und die Klasse “Kommentar” auf diese Weise verbunden. Berücksichtigt man die Multiplizität, so heißt es gesprochen: “Ein Artikel kann beliebig viele Kommentare enthalten.”

Artikel, Kommentare und Seiten sind in einem Weblog Inhalte und sie besitzen die abstrakten Eigenschaften von Inhalten, hier sind es das Datum und den Autor. Eine derartige Beziehung wird Vererbung genannt. Die Eltern-Klasse (“Content”) wird Oberklasse und die Kind-Klasse (“Artikel”) Unterklasse genannt.

Eine weitere Beziehung ist in dem Beispiel zwischen den Klassen “Datum” und “Content” zu sehen. Das ist ein Sonderfall einer Assoziation und wird Aggregation genannt. Die Aggregation besagt, dass die Beziehung zwischen den Klassen nicht gleichwertig ist. In diesem Fall ist “Datum” ein Teil der Klasse “Content”. Die leere Raute zeigt dabei immer auf das ganze Element, also auf “Content”.

Ist die Raute nicht leer, sondern ausgefüllt, dann handelt es sich um eine Komposition. Die Komposition ist auch ein Sonderfall der Assoziation und eine strengere Form der Aggregation. Wenn das ganze Element, welches die Komposition einnimmt, aus irgendwelchen Gründen verschwindet, dann kann das komposierte Element auch nicht mehr weiter existieren. Das ist bei der Aggregation nicht der Fall. Der Autor lebt immer noch, auch wenn sein Artikel gelöscht wird. Das Gegenteil gibt es nur in Büchern und Filmen .

Das ist ein Klasse-Diagramm

Klassendiagramme sind ein sehr wichtiges und nützliches Werkzeug bei der Programmierung. Und da die Terminologie auch zufällig die gleiche ist, fällt es den Programmierern nicht sehr schwer, sich an die Klassendiagramme zu gewöhnen.

Hast schon Erfahrungen mit Klassendiagrammen gemacht? Und wo wendest du sie an?

Ein weiteres Element ist die parametrisierbare Klasse. In c++ wird sie Template-Klasse genannt und stellt eine Schablone dar, welche einen formalen Parameter enthält, der bei der Erzeugung weiterer Klassen ersetzt wird. Mit dieser Technik kann leicht wiederverwendbarer Code erzeugt werden. Dargestellt wird die parametrisierbare Klasse durch ein zusätzliches rechteckiges Feld an der rechten oberen Ecke des Klassen-Feldes, welches den Namen des formalen Parameters enthält.

Klassen sind im Klassendiagramm nicht die handelnden Elemente, es sind ihre Objekte oder Instanzen. Die Eigenschaften und das Verhalten der Objekte wird durch die Klasse definiert (Attribute und Operationen). In der UML-Darstellung unterscheiden sich Objekte von ihren Klassen dadurch, dass dem Namen des Objekts im obersten Feld nach einem Doppelpunkt der Name der Klasse folgt. Das ganze wird auch noch unterstrichen. Das Objekt-Rechteck stellt nur Attribute mit den aktuellen oder Beispielwerten dar, Operationen sind nicht objektspezifisch und werden daher nicht angegeben.

Soweit zu den Klassen und ihren Objekten. Was noch fehlt sind die Verbindungen zwischen den Klassen, welche sehr vielfältig sind. Ich möchte an dieser Stelle lediglich vier vorstellen:

Die Assoziation beschreibt die Relation zwischen Klassen bzw. ihrer Objekte und wird entweder durch einen einfache Strich oder durch einen Pfeil dargestellt. Im Falle des Pfeils handelt es sich um eine gerichtete Assoziation und die Kommunikation kann nur in eine Richtung stattfinden. Im oberen Beispiel habe ich die Klasse “Artikel” und die Klasse “Kommentar” auf diese Weise verbunden. Berücksichtigt man die Multiplizität, so heißt es gesprochen: “Ein Artikel kann beliebig viele Kommentare enthalten.”

Artikel, Kommentare und Seiten sind in einem Weblog Inhalte und sie besitzen die abstrakten Eigenschaften von Inhalten, hier sind es das Datum und den Autor. Eine derartige Beziehung wird Vererbung genannt. Die Eltern-Klasse (“Content”) wird Oberklasse und die Kind-Klasse (“Artikel”) Unterklasse genannt.

Eine weitere Beziehung ist in dem Beispiel zwischen den Klassen “Datum” und “Content” zu sehen. Das ist ein Sonderfall einer Assoziation und wird Aggregation genannt. Die Aggregation besagt, dass die Beziehung zwischen den Klassen nicht gleichwertig ist. In diesem Fall ist “Datum” ein Teil der Klasse “Content”. Die leere Raute zeigt dabei immer auf das ganze Element, also auf “Content”.

Ist die Raute nicht leer, sondern ausgefüllt, dann handelt es sich um eine Komposition. Die Komposition ist auch ein Sonderfall der Assoziation und eine strengere Form der Aggregation. Wenn das ganze Element, welches die Komposition einnimmt, aus irgendwelchen Gründen verschwindet, dann kann das komposierte Element auch nicht mehr weiter existieren. Das ist bei der Aggregation nicht der Fall. Der Autor lebt immer noch, auch wenn sein Artikel gelöscht wird. Das Gegenteil gibt es nur in Büchern und Filmen .

Das ist ein Klasse-Diagramm

Klassendiagramme sind ein sehr wichtiges und nützliches Werkzeug bei der Programmierung. Und da die Terminologie auch zufällig die gleiche ist, fällt es den Programmierern nicht sehr schwer, sich an die Klassendiagramme zu gewöhnen.

Hast schon Erfahrungen mit Klassendiagrammen gemacht? Und wo wendest du sie an?

-->

Artikel aus der selben Kategorie:

• » Python Tutorial: Lesen von csv-Daten
• » UML: Aktivitätsdiagramm (Teil 4)
• » Emacs Macro definieren, benennen, speichern
• » Python Tutorial: Lesen von csv-Daten 2
• » Python Dokumentation mit DocString