Klassen- und Objektdiagramme

In Anlehnung an das Buch mit dem Titel „UML 2 in 5 Tagen“ von Prof. Dr. Heide Balzert[1] dient für die folgenden Ausführungen das Beispiel der Auftragsabwicklung eines Unternehmens. Als Veranschaulichung der hierfür erforderlichen Daten dient eine Beispielrechnung.
Als Informationsgrundlage dienen eine Rechnung sowie ein Bestellfax an ein fiktives Unternehmen. Beide Dokumente finden Sie auf den folgenden beiden Seiten.

Nachdem mit Hilfe des UCDs die Funktionen festgelegt wurden – was mit der Software erfolgen soll – ist es nun erforderlich, zu bestimmen, wodurch bzw. womit diese Funktionen ermöglicht werden sollen.

Für diesen Schritt sieht die UML das sog. Klassendiagramm vor. Die einzelnen Klassen beschreiben die Objektgruppen, welche von der späteren Software behandelt werden sollen. Aus den Klassen entstehen später in der praktischen Anwendung die Objekte. Ein Beispiel soll dies verdeutlichen: In der Datenbank des Schreibwarenversandhandels soll festgehalten werden, welcher Mitarbeiter einen beliebigen Auftrag angenommen und bearbeitet hat. Da die einzelnen Mitarbeiter uns zum gegenwärtigen Zeitpunkt nicht bekannt sind, müssen wir uns darauf beschränken, diejenigen Eigenschaften festzulegen, mit denen sie später im System erfasst werden sollen: es muss die Klasse „Mitarbeiter“ entworfen werden. Wie ein Klassendiagramm erstellt wird und welche Bestandteile es aufweist, wollen wir in den folgenden Kapiteln kennenlernen.

1 Klassen – Schablonen für Objekte

Eine Klasse definiert für eine Ansammlung von Objekten deren Eigenschaften und Verhalten. Alle Objekte, die zu einer Klasse gehören, haben demnach die selben Eigenschaften (Attribute) und das selbe Verhalten (Operationen). Das soll jedoch nicht heißen, dass diese Objekte auch die selben Attributswerte haben. Im Rahmen einer Klasse legen wir den Rahmen fest, durch den die einzelnen Objekte, welche später dieser Klassen angehören sollen, konkret definiert werden sollen. Eine Klasse könnte man durch diese Festlegungen auch als Objektfabriken bezeichnen.
Eine Klasse kann wie folgt dargestellt werden:

Auf den folgenden Seiten sollen die Operationen noch außen vor sein.

1.1. Der Klassenname

…wird nach den sog. Style Guidelines der UML

• fett gedruckt,
• zentriert dargestellt und
• beginnt mit einem Großbuchstaben.

Er wird im Allgemeinen im Singular gewählt.

1.2 Der Attributname

…beginnt nach den sog. Style Guidelines der UML

• mit einem Kleinbuchstaben,
• wird bei mehreren Wörtern in der Kamelhöcker-Notation geschrieben und kann beliebige Zeichen enthalten.

Nachdem wir nun wissen, das die beiden grundlegenden Bestandteile einer Klasse aus dem Klassennamen sowie aus dem bzw. den Attributnamen der Klasse bestehen, können wir die Klassen Schüler und Lehrer aus unserer Schuldatenbank näher betrachten:

Wie zu erkennen ist, besteht eine Klasse aus dem Klassennamen und den Attributen.

(Um die Darstellung der beiden für die weitere Betrachtung wichtigen Dokumente „Fax-Bestellung“ und „Rechnung“ jeweils auf einer einzelnen Seite gewährleisten zu können, bleibt der folgende Bereich auf dieser Seite leer.)

Um die Möglichkeit der durch Missverständnisse und Übertragungsfehler verursachten Fehlerquellen weiter einzuschränken, können jedem Attribut noch bestimmte Eigenschaften bzw. Typen zugewiesen werden:

1.3 Der Typ eines Attributes kann in der UML der modelliert werden durch:

1.3.1 primitive Datentypen,

die in der UML keine Struktur besitzen. Typische Beispiele sind Zahlen, deren Eigenschaften z.B. hinsichtlich ihrer Behandlung mit Hilfe der vier Grundrechenarten außerhalb der UML bereits festgelegt wurde. Ihre Darstellung erfolgt ebenfalls in der Darstellungsform (Notation) einer Klasse, und zwar durch einen Doppelpunkt von der Bezeichnung des Attributs getrennt. Wir unterscheiden vier primitive Datentypen:

• • String (Zeichenkette)
  • Integer (ganze Zahlen)
  • UnlimitedNatural (natürliche Zahlen)
  • Boolean (kann die Werte true und false annehmen)

1.3.2 strukturierte Datentypen

(ohne Identität) dürfen – wie Klassen – Attribute und Operationen besitzen. Sie beschreiben oft Strukturen. So setzt sich der Name eines Schülers in der Schuldatenbank immer aus dem (Familien-) Namen sowie dem Vornamen zusammen. Hieraus ergibt sich ein Datentyp „Name“, welcher mit dem Stereotyp <<datatype>> als Datatype kenntlich gemacht wird:

Für die Darstellung wird das Klassensymbol verwendet, dieses jedoch mit dem Schlüsselwort <<datatype>> als Datentyp gekennzeichnet. So ist es möglich, statt immer wieder die einzelnen Bestandteile der Adresse zu wiederholen, einfach den Datentyp „Adresse“ anzugeben, in dem der Aufbau der Informationen für die Adresse festlegt wurde. Die Klassen Lehrer und Schüler der Schuldatenbank sehen unter Einbezug der beiden neuen Datatypes dann folgendermaßen aus:

1.3.3 Aufzählungstypen (Enumeration type)

liegen vor, wenn nur die diskreten Werte für ein Attribut in Frage kommen, welche bereits vorformuliert wurden.
Betrachten wir uns das Faxformular, so erkennen wir, dass zu den Kundendaten neben Name, Adresse u.v.m. auch das „Land“ gehört. Hier bietet es sich an, die verschiedenen möglichen Herkunftsländer dem Nutzer als Auswahl anzubieten:

Aufzählungstypen werden mit dem Stereotyp <<enumeration>> als solche gekennzeichnet. Auf sie kann in einem Klassendiagramm immer dann zurück gegriffen werden, wenn die Aufzählung bzw. die Auswahl der derselbigen gebraucht wird.

Die Bildung geeigneter Datentypen bietet den Vorteil, öfters gebrauchte Typen immer wieder verwenden zu können.

Das Konzept des Stereotypen ermöglicht es, einzelnen Modellelementen (Symbolen) eine neue (Semantik) Bedeutung zu geben. Einmal definierte Datentypen können ihrerseits in einem separaten Klassendiagramm dokumentiert und gespeichert werden, und somit in jedem neuen Projekt wieder verwendet werden. Durch die unterschiedliche Schreibweise (Attributnamen beginnen mit einem Kleinbuchstaben, Typnamen hingegen mit einem Großbuchstaben) treten Namenkonflikte hier nicht auf.

Optional kann für Attribute auch ein jeweiliger Anfangs– oder Startwert (initial value) gesetzt werden. In unserem Beispielunternehmen kommen die Kunden für gewöhnlich aus Deutschland. Es wäre sinnvoll, für das Attribut land den Anfangswert Deutschland zu setzen:

Nun können wir bereits unser erstes vollständiges Klassendiagramm für unser Beispielunternehmen erstellen.

1.3.4 abgeleitete Attribute (derive attribute)

sind sinnvoll, wenn sich der konkrete Attributwert nach einem anderen Wert bemisst:
In unserem Unternehmen werden Artikel verkauft, welche dem MwSt-Satz von derzeit 19% unterliegen. Um nun nicht immer wieder den Wert eingeben zu müssen, liegt es nahe, diesen in der Datenbank zu hinterlegen. Bislang sah die Klasse „Artikel“ folgendermaßen aus:

Im gewerblichen Bereich ist es neben der Angabe des MwSt-Satzes durchweg üblich, die enthaltene MwSt anzugeben. Dieser Betrag richtet sich nach dem Preis und dem MwSt-Satz. Mit dem Präfix „/“ kann nun das fehlende Attribut „enthaltene MwSt“ in die Klasse „Artikel“ eingefügt werden. Das hat den Vorteil, dass bei Änderung des ursprünglichen Wertes sich auch das abgeleitete Attribut ändert. Gemäß den Style Guidelines der UML werden abgeleitete Attribute mit dem Präfix „/“ gekennzeichnet.

Aus dem gesagten ergibt sich, dass abgeleitete Attribute später nicht direkt geändert werden dürfen, sondern aus Gründen der Konsistenz immer errechnet werden müssen.

1.4 Die Multiplizität (multiplicity)

…von Attributen legt fest, ob ein oder mehrere Einträge gemacht werden müssen bzw. können. Nach den Style Guidelines der UML werden die Angaben zur Multiplizität in eckigen Klammern gemacht:

• [0..1] bedeutet, dass das Attribut genau (!) einen Wert annehmen kann (aber nicht muss);
• [1..1] = [1] bedeutet, dass in diesem Attribut genau ein Wert eingetragen werden muss;
• [0.. *] bedeutet, dass das Attribut keinen, einen oder mehrere Werte annehmen kann;
  So können beispielsweise folgende Multiplizitäten definiert werden:

1.5 Eigenschaftswerte eines Attributs

Für jedes Attribut muss festgelegt werden, ob der Wert z.B. automatisch erzeugt werden soll, oder ob die Daten nur gelesen, aber nicht verändert werden dürfen. Diese Eigenschaftswerte (property modifier) werden in geschweiften Klammern angegeben. Beispielsweise bietet die UML folgende Eigenschaftswerte an:

• ® das Attribut darf nicht verändert werden, nachdem es einen Wert erhalten hat;
• ® die Attributswerte des Attributs werden sortiert; im Falle nur eines Wertes hat diese Angabe praktisch keine Bedeutung;
• ® das Attribut ist ein Primärschlüssel; der Eigenschaftswert sollte so definiert sein, dass zusätzlich die readOnly-Eigenschaft gilt;

Nun sind wir in der Lage, die Klasse Auftrag um die kennen gelernten Eigenschaftswerte zu ergänzen. Folgenden Angaben sind hierbei zu beachten

• jedes Objekt der Klasse muss eine eindeutige Nummer besitzen;
• das Bestelldatum darf nach der Ersteingabe nicht mehr geändert werden;
• das Rechnungsdatum entspricht dem Systemdatum und ist damit stets aktuell; es kann beim Anlegen eines neuen Auftrages überschrieben werden, ist danach aber nicht mehr änderbar;
• alle Felder sind Pflichtfelder;
  Zur Wiederholung tragen wir auch die Informationen zu den (primitiven) Datentypen ein:

1.5.1 Grenzen der Attributswerte

Um für Attribute Grenzen bei der Eingabe zu setzen, ist es möglich Einschränkungen (constraints) zu definieren. Diese müssen stets eingehalten werden, sind also immer wahr. Hierdurch können vom späteren Programm die Eingaben auch auf Plausibilität geprüft werden. Beispiele hierfür sind:

Zu den genannten Möglichkeiten, die Attribute zu modellieren, kann obendrein die Sichtbarkeit (visibility) festgelegt werden. Zwar ist diese Information in der Analyse noch nicht von Bedeutung – für den Entwurf ist sie jedoch wichtig. Wird über die Sichtbarkeit keine Angabe gemacht, so ist sie unspezifiziert.

• • public (+): Das Attribut ist außerhalb der Klasse sichtbar, d.h. Objekte anderer Klassen können direkt lesend und schreibend darauf zugreifen. ® verstößt gegen das sog. Geheimnisprinzip und darf daher nur in wenigen Fällen verwendet werden.
  • protected (#): Das Attribut ist innerhalb der Generalisierungsstruktur sichtbar, hierzu folgt später die Begriffserklärung.
  • private (-): Das Attribut ist nur innerhalb einer Klasse sichtbar, was bedeutet, dass nur Objekte dieser Klasse darauf zugreifen können. private sollte nach Möglichkeit grundsätzlich gewählt werden, da trotz Zugriffsmöglichkeit das Geheimnisprinzip gewahrt wird.
  • package (~): Das Attribut ist innerhalb des Pakets sichtbar, hierzu folgt ebenfalls später die Begriffsklärung.