Das Klassendiagramm

Das Klassendiagramm. Kann man ein anderes Diagramm begegnen so häufig, wie das Klassendiagramm? Das liegt wahrscheinlich zum einen daran, dass es sich wunderbar nachträglich aus Quellcode generieren lässt, was es den Entwicklern einfach macht, Dokumentationen zu liefern. Zum Anderen ist es aber eben auch so, dass es genau das beschreibt, womit Entwickler sehr häufig zu tun haben. Eben nicht Klassen. Ganz wichtig ist mir an dieser Stelle, dass wir zwar Bezeichnungen und Darstellungen aus der UML nutzen, das heißt aber nicht, dass Sie danach auch gleich die UML beherrschen, wenn Sie fertig sind mit diesem Video. Da gibt es noch eine ganze Menge mehr zu wissen, wir nähern uns der Diagrammdarstellung an dieser Stelle vor allem pragmatisch. Das Klassendiagramm gehört zu den Strukturdiagrammen. Es beschreibt also statische Strukturen, keine dynamischen Strukturen. Es zeigt nur über Beziehungen, wie Elemente zueinander stehen, aber nicht, wie sie sich in Kombination verhalten. Im Zentrum von Klassendiagramm stehen eben Klassen. Diese Klassen werden meist als Rechtecke dargestellt, die dann in 3 Bereiche aufgeteilt werden. Teilweise werden aber auch einzelne Bereiche weggelassen. Einen Bereich, den Sie definitiv nicht weglassen sollten, das ist die Bezeichnung. Diese Bezeichnung, das ist der Name der Klasse. An zweiter Stelle kommen die Eigenschaften. Das ist auch der Bereich, der gerne mal weggelassen wird. Je nach dem, welche Programmiersprache Sie nutzen, sind diese Eigenschaften meist Membervariablen, die also den Status einer Klasse oder eines Objekts speichern, und dann öffentlich bzw. privat sein können. An dritter Stelle kommen die Methoden. Das ist das Verhalten der Klasse. Auch diese Elemente können entweder sichtbar oder unsichtbar von außen sein. Dazu kommen wir gleich aber noch mehr. Viel interessanter ist bei Klassendiagrammen, wie die Beziehungen zwischen verschiedenen Klassen sind. Diese Beziehungen können als durchgezogener Strich zum Beispiel gezeichnet werden. Es gibt aber auch die Möglichkeit, Abhängigkeiten mit Pfeilenden und gestrichelt darzustellen. Interessant ist hierbei, dass man auch die Mengenverhältnis oder auch Kardinalität zwischen den Elementen darstellen kann. Es gibt dabei verschiedene Varianten, entweder, dass nur einzelne Zahlen eingetragen werden, wie 1 0 1 . Das heißt, dass die linke Klasse eine oder keine Beziehung zu rechten hat. Diese Kardinalität wiederum wird in aller Regel nicht bei den gestrichelten Linien eingezeichnet. Warum das so ist, kann ich Ihnen nicht genau sagen. Macht wahrscheinlich auch jeder etwas anderes. Eine andere Darstellung bei den Mengenverhältnissen ist außerdem noch der Stern, der einfach nur angibt, dass es viele sind. Dann haben wir noch die Vererbung. Die wird so ähnlich gezeichnet, wie die Abhängigkeit. Also entweder als durchgezogene Linie mit einem Pfeilende, oder als gestrichelte Linie mit einem Pfeilende + mit dem Unterschied, dass das Pfeilende hier in aller Regel geschlossen ist. Während bei anderen Dingen ab und zu etwas unterschiedlich vorgegangen wird, haben sich die meisten Entwickler tatsächlich mittlerweile überzeugen lassen, dass man Vererbungen, Generalisierungen und Ähnliches über geschlossene Pfeilenden kennzeichnet und reine Abhängigkeiten über offene Pfeile enden. Außerdem haben wir noch die Möglichkeit, Schlüsselwörter zu verwenden, wie hier das Interface, damit können wir Spezialfälle angeben. Im Klassendiagramm begegnet uns es in aller Regel nicht, dass wir ein Schlüsselwort für die Klassen vergeben. Also da wird in aller Regel kein Class darüber gezeichnet, sondern man geht automatisch davon aus, dass ein Bestandteil, der kein Schlüsselwort hat, auch eine Klasse ist. Andere Schlüsselworte als Interface wären zum Beispiel noch Abstrakt, wenn es sich um eine abstrakte Klasse handelt. Aber das ist auch je nach Programmiersprache unterschiedlich. Im Speziellen kann das Ganze dann zum Beispiel so aussehen, wie hier. Sie haben also oben den Bezeichner Setting, der wird meistens auch dann dick hervorgehoben. Danach kommen die Eigenschaften, und dann kommen die Methoden. Wie jetzt die Methoden dann dargestellt werden, das kann wieder unterschiedlich sein. Häufig wird mit einem Plus oder Minus gezeigt, dass es öffentlich ist also public, das wäre das Plus, oder das ist private, also von außen nichts sichtbar ist, über ein Minus. Router wird dann gegebenenfalls für so etwas wie "protected" verwendet, oder wie das auch immer in Ihrer Sprache heißt. Das sind also Eigenschaften, die nur bei einer Vererbung für andere Klassen sichtbar sind. Wenn wir dann Typen angeben wollen, werden diese häufig mit einem Doppelpunkt getrennt. Also man gibt erst den Namen an, und dann per Doppelpunkt den Typ. Das Gleiche ist bei den Rückgabetypen so. Häufig werden aber solche Parameterlisten, solche Eigenschaften, und auch solche Rückgabewerte bei Architekturdiagramm überhaupt nicht eingezeichnet. Der Grund dafür ist, dass das Details sind, die sich häufig ändern können. Man muss da also ständig die Dokumentation anpassen. Aus diesem Grund werden dann eher Darstellungen wir hier verwendet, wo man nur den Bezeichner einträgt und dann über ein Schlüsselwort die Ganze Sache eventuell verfeinert. Anders sieht das dann aus, wenn Sie Klassendiagramme z.B. nutzen, um Datenmodelle zu modellieren, dann hätten Sie beispielsweise keine Methoden, sondern nur die Eigenschaften und den Bezeichner in Ihrer Klasse. Fassen wir das Ganze noch einmal zusammen. In aller Regel sind Klassendiagramme in einer Architekturbeschreibung bzw. einer Architekturdokumentation nicht ganz so praktisch, da sie viel zu detailliert sind. Gerade Parameterlisten und Rückgabetypen, auch Methodennamen, das sind Sachen, die sich häufig ändern. Und wenn sich Dinge häufig ändern, bedeutet das, dass die Dokumentation recht schnell altert. Sie eignen sich aber hervorragend, um z.B. Schnittstellen zu spezifizieren. Hier müssen ja Daten ausgetauscht werden, und wir schreiben vor, dass es bestimmte Methoden gibt. Außerdem können sie super verwendet werden, um Datenmodelle damit zu modellieren und zu zeigen, welche Objekte in unserem Datenmodell welche anderen Objekte verwenden.