Klassendiagramm (UML)
Ein UML-Klassendiagramm zeigt die Struktur einer Domäne als Klassen, die Kategorien von Objekten, über die eine Organisation Informationen führt. Jede Klasse trägt die Attribute, die sie beschreiben, die Operationen, die sagen, was man mit ihr tun kann, und die Assoziationen, die sie mit anderen verbinden, wobei jede Assoziation mit einer Multiplizität versehen ist, die festlegt, wie viele Vorkommen an jedem ihrer Enden zulässig sind. Es ist die Datenmodellierungsnotation der objektorientierten Gestaltung: wo das Entity-Relationship-Diagramm dem Schema einer relationalen Datenbank dient, dient das Klassendiagramm der Struktur einer Software, und es ist das einzige der beiden, das neben der Struktur auch das Verhalten trägt. Die Notation ist durch die UML-Spezifikation der OMG definiert. Die Notation liest sich auf konzeptioneller und analytischer Ebene, derjenigen, die dem Business Analyst zufällt.
Ziel
Das Klassendiagramm gibt eine geteilte, eindeutige Darstellung der Struktur einer Domäne, die für eine objektorientierte Software bestimmt ist: welche Klassen es gibt, was sie an Attributen und Operationen tragen und wie sie sich verbinden. Es schreibt dies in einer Sprache, die der Fachbereich bestätigen und die der Entwickler umsetzen kann. Die Entscheidung, die es stützt, ist die Struktur des Codes, die Klassen der Domäne und ihre Assoziationen, zu dem Zeitpunkt, an dem diese Wahl noch verhandelbar und günstig rückgängig zu machen ist, vor der Implementierung.
Das Ergebnis ist ein Diagramm samt einem Text, der es dokumentiert. Auf der Ebene, die den Business Analyst betrifft, ist es ein konzeptionelles und analytisches Modell: die Klassen der Domäne, ihre wesentlichen Attribute, die bedeutsamen fachlichen Operationen, die in der Sprache des Fachbereichs benannten Assoziationen und die an ihren Enden gesetzten Multiplizitäten. BABOK ordnet das Klassendiagramm als eine der beiden Notationen des Datenmodells ein, diejenige, die eine objektorientierte Entwicklung stützt, und stellt es dem Entity-Relationship-Diagramm gegenüber, das dem Schema einer relationalen Datenbank dient. Der Hub der Datenmodellierung legt diese Aufteilung dar und weist auf die passende Notation hin.
Einsatz
Wann einsetzen
- Gestaltung objektorientierter Software: das gestaltete Artefakt ist die Struktur des Codes, die Klassen und ihre Assoziationen rahmen sie ein.
- Das Verhalten zählt so viel wie die Struktur: die Klasse trägt Operationen, die das Entity-Relationship-Diagramm nicht ausdrücken kann.
- Der Entwickler als nachgelagerter Leser: das Klassendiagramm ist die Notation, die das Entwicklungsteam geläufig liest.
- Ein bestehendes objektorientiertes System zu dokumentieren: die realen Klassen und ihre Verbindungen rekonstruieren, bevor eine Weiterentwicklung oder eine Übernahme ansteht.
Wann nicht einsetzen
- Gestaltetes Artefakt = Schema einer relationalen Datenbank: es ist das persistente Schema, das gestaltet wird, nicht der Code, also das Entity-Relationship-Diagramm nehmen.
- Das Vokabular der Domäne ist noch strittig: die Bedeutung zuerst mit einem Begriffsmodell festlegen, dann die Struktur.
- Streng fachliches Publikum ohne IT-Hintergrund: der Formalismus schreckt ab, für dieses Publikum ein Glossar führen.
Beschreibung
Ein Business Analyst muss nicht ganz UML zeichnen, um ein Klassendiagramm zu nutzen. Er muss eine Handvoll Elemente lesen und kombinieren können. Der Rest der Notation gehört auf die Ebene der detaillierten Gestaltung und liegt ausserhalb des Aufgabenbereichs des Business Analyst.
Die Klasse und ihre drei Abschnitte
Eine Klasse ist ein Rechteck mit drei übereinandergestapelten Abschnitten. Der Name der Klasse steht im oberen Abschnitt, im Singular und in der Sprache des Fachbereichs. Die Attribute belegen den mittleren Abschnitt, die Operationen den unteren. Der Name allein genügt, solange der Rest noch nicht gesetzt ist, und die beiden unteren Abschnitte füllen sich nach und nach.
Ein Attribut ist eine über die Klasse gehaltene Information, geschrieben in der Form name: Typ, zum Beispiel preisCHF: Dezimal oder startdatum: Datum. Der Typ ist auf konzeptioneller Ebene optional und wird zur logischen Ebene hin präzisiert. Das Attribut sagt, welche Information gehalten wird, ihre zulässigen Werte und ihr Format, doch die ausführlichen Definitionen gehören zum Datenwörterbuch. Eine Operation sagt, was man mit der Klasse tun kann, geschrieben am unteren Rand des Rechtecks, zum Beispiel validieren() oder erneuern(enddatum). Sie ist es, die die Klasse von der Entität eines Entity-Relationship-Diagramms trennt: die Entität trägt Attribute und Beziehungen, sie trägt kein Verhalten.
Assoziation, Multiplizität, Generalisierung
Eine Assoziation ist eine Linie zwischen zwei Klassen, die sagt, dass sie sich verbinden und wie. Man benennt sie gern mit einem Verb, hält oder deckt. In einem Klassenmodell spricht man von einer Assoziation, wo ein Datenmodell von einer Beziehung spricht.
Die Multiplizität ist die Annotation, die an jedem Ende der Assoziation getragen wird. Sie legt die minimale und maximale Zahl zulässiger Vorkommen auf der Seite fest, auf der sie geschrieben steht. Die üblichen Werte sind 1 für genau eins, 0..1 für null oder eins und somit optional, * oder 0..* für eine beliebige Zahl und 1..* für mindestens eins. Man spricht von Multiplizität, wo ein Datenmodell von Kardinalität spricht, für dieselbe Idee der Schranken. Am häufigsten führt die Leserichtung in die Irre: die an einem Ende geschriebene Schranke liest sich an diesem Ende. In « ein Kunde hält 0..* Abonnemente » steht das 0..* auf der Seite des Abonnements und beschreibt die Zahl der Abonnemente, nicht die Zahl der Kunden. 0..* als « obligatorisch » zu lesen ist der andere häufige Fehler, wo die 0 sagt, dass die Verbindung optional ist.
Die Generalisierung ist die « ist-ein »-Verbindung. Man zeichnet sie als eine Linie, die in einem leeren Dreieck endet, das auf die allgemeine Klasse zeigt, die Superklasse. Die Unterklassen erben die Attribute, Operationen und Assoziationen der Superklasse und fügen ihre eigenen hinzu. Das leere Dreieck unterscheidet sie von der Assoziation: das Dreieck kennzeichnet eine Vererbung, die einfache Linie eine strukturelle Verbindung. Die eine für die andere zu nehmen verfälscht die Lesung des Modells. Um ein Diagramm zu bauen, setzt man die Klassen der Domäne, füllt ihre Attribute und ihre bedeutsamen fachlichen Operationen, verbindet sie durch mit Multiplizitäten annotierte Assoziationen und zieht das, was mehreren Klassen gemeinsam ist, in eine durch Generalisierung verbundene Superklasse zusammen.
Die Ebene, die dem Business Analyst zufällt
Ein Klassendiagramm existiert auf mehreren Ebenen, wie jedes Datenmodell. Die konzeptionelle und analytische Ebene ist die des Business Analyst: Klassen der Domäne, benannt in der Sprache des Fachbereichs, wesentliche Attribute, fachliche Operationen, Assoziationen und Multiplizitäten. Sie ist von der Technologie unabhängig und der Fachbereich kann sie bestätigen oder widerlegen. Die logische und die physische Ebene, die Sichtbarkeit der Mitglieder, die technischen Typen, die Signaturen der Methoden, die Schnittstellen und die Infrastrukturklassen gehören den Fachleuten der Implementierung. BABOK behält diese Ebenen denjenigen vor, die die objektorientierte Lösung umsetzen.
Daher kommt die zentrale Falle für einen Business Analyst: zu stark in Richtung Implementierung zu modellieren. Sichtbarkeitsmarker +/-, getX- und setX-Zugriffsmethoden, technische Typen oder Entwurfsmuster hinzuzufügen greift in ein anderes Fachgebiet ein und belastet das Modell zu einem Detailgrad, den der Fachbereich nicht mehr validieren kann. Die zweite Falle ist, das Klassendiagramm mit dem Entity-Relationship-Diagramm zu verwechseln. Beide modellieren denselben konzeptionellen Inhalt der Domäne, doch sie dienen unterschiedlichen Artefakten und sprechen zwei Vokabulare: die Klasse trägt Operationen und spricht von Assoziation und Multiplizität, die Entität trägt kein Verhalten und spricht von Beziehung und Kardinalität. Das Kriterium, das sie trennt, ist somit das gestaltete Artefakt, objektorientierter Code oder relationales Schema. Eine objektorientierte Anwendung auf einer relationalen Datenbank, in der Schweiz ein gewöhnlicher Fall, bringt beide Modelle hervor.
KI-Überlegungen
Ein Sprachmodell leistet zwei Dienste bei dieser Technik. Der erste ist das Ableiten eines Kandidatenmodells: es liest einen Bestand an Anforderungen, Gesprächsnotizen oder bestehendem Code und schlägt Klassen, Attribute, Operationen und Assoziationen vor. Bei einem Altsystem ohne Dokumentation ist der Gewinn real, und der so gewonnene Entwurf lässt sich schneller korrigieren, als sich ein leeres Blatt füllt. Der zweite ist das Aufspüren von Lücken: eine verwaiste Klasse ohne Assoziation, eine plausible Assoziation, die nicht gezeichnet wurde oder ein über mehrere Klassen wiederholtes Attribut, das eine herauszuziehende Generalisierung nahelegt.
Die Grenze ist fest und fachlicher Natur. Die richtige Multiplizität, ob ein Kunde mehrere Abonnemente halten kann oder eine Police nur einen Versicherten deckt, ist eine fachliche Tatsache, die der Text nicht zuverlässig liefert, und eine falsche Schranke lässt das Modell lügen. Die Semantik der Domäne, was eine Klasse für die Organisation bedeutet und die Tatsache, dass eine Assoziation in ihrer Tätigkeit wirklich besteht, wird bei den Fachleuten bestätigt. Und ein Sprachmodell neigt dazu, zu stark in Richtung Implementierung zu modellieren. Jeder Vorschlag der KI ist ein Entwurf, der den Fachleuten der Domäne und dem Business Analyst vorgelegt wird, der die Analyseebene hält.
Beispiele
Der Begriff, den das Beispiel sichtbar macht, ist das Zusammensetzen dreier Elemente auf einem einzigen kleinen Diagramm: die Klasse mit drei Abschnitten, die mit Multiplizitäten annotierte Assoziation und die Generalisierung. Der gewählte Fall sind die Abonnemente des Schweizer öffentlichen Verkehrs, wo das Generalabonnement und das Halbtax zwei Arten desselben Abonnements sind.
Zwei Punkte sind leicht zu übersehen. Die Multiplizität 0..* steht auf der Seite von Abonnement und liest sich dort: ein Kunde hält null, ein oder mehrere Abonnemente, während die 1 auf der Seite von Kunde sagt, dass ein Abonnement genau einem Kunden gehört. Das leere Dreieck, das auf Abonnement zeigt, kennzeichnet eine Vererbung: Generalabonnement und Halbtax erben nummer, startdatum, enddatum und preisCHF sowie die Operationen validieren() und erneuern(), und jede fügt nur ihr eigenes Attribut hinzu, die Reiseklasse für das Generalabonnement, den Rabattsatz für das Halbtax. Vier Klassen, eine Assoziation und eine Generalisierung genügen, um die ganze Notation zu tragen, die ein Business Analyst lesen können muss.
Visualisierungen
Die Form trägt den Sinn. Das Rechteck mit drei Abschnitten sagt, dass ein Objekt einen Namen, Attribute und Operationen hat. Die Linie sagt eine Assoziation, und die an ihrem Ende geschriebene Schranke liest sich an diesem Ende. Das leere Dreieck sagt eine Generalisierung und zeigt auf die allgemeine Klasse. Ein Leser, der diese drei Zeichen kennt, liest ein vollständiges Klassendiagramm ohne Legende, etwa das der Abonnemente.
Aufwand
| Phase | Stufe | Begründung |
|---|---|---|
| Vorbereitung | Mittel | Die Quellen zusammentragen, Anforderungen, Gesprächsnotizen, bestehenden Code oder ein bestehendes Schema, dann die Fachleute bestimmen, die die Klassen, die Assoziationen und ihre Multiplizitäten mit Autorität bestätigen. |
| Durchführung | Gering bis mittel | Die Analyseebene wird in wenigen Sitzungen mit den Fachleuten der Domäne gesetzt. Der Aufwand wächst mit der Zahl der Klassen und Assoziationen. Das Implementierungsdetail bleibt ausserhalb des Umfangs des Business Analyst. |
| Dokumentation | Mittel | Das Analysemodell lebt mit der Domäne und wird bei jeder Änderung der Klassen oder der Verbindungen aktualisiert. Es bleibt leichter als das logische und das physische Modell, die von der Implementierung gehalten werden. |
Werkzeuge
Ein Whiteboard genügt für einen ersten Entwurf: einige Klassen und ihre Verbindungen passen auf eine Fläche und werden im Stehen korrigiert, was oft der richtige Massstab für die Analyseebene ist. Allgemeine Diagrammwerkzeuge, diagrams.net, Lucidchart oder Visio, tragen UML-Schablonen und geben eine saubere, teilbare Zeichnung, gut geeignet, solange das Diagramm eine Diskussionsgrundlage bleibt. Spezialisierte UML-Modellierungswerkzeuge, Enterprise Architect, Visual Paradigm, StarUML oder Modelio, halten das Klassendiagramm als eine Sicht eines zusammenhängenden Modells: sie prüfen das Modell, verbinden es mit den anderen UML-Diagrammen und erzeugen, auf der Implementierungsseite, Code aus den Klassen oder gewinnen die Klassen durch Reverse Engineering aus bestehendem Code. Dieses Reverse Engineering ist nützlich, um ein objektorientiertes Altsystem zu dokumentieren, sofern man das Ergebnis danach auf die Analyseebene zurückführt, statt das technische Detail das Modell sättigen zu lassen. Werkzeuge mit Textgenerierung, wie PlantUML, beschreiben das Diagramm in wenigen Zeilen versionierbaren Textes, was einem neben dem Code geführten Modell entspricht.
Quellen
- OMG (Object Management Group), Unified Modeling Language (UML) Specification, version 2.5.1: die Spezifikation, die das Klassendiagramm und seine Notation definiert, Klassen mit drei Abschnitten, Attribute, Operationen, Assoziationen, Multiplizität und Generalisierung. Sie ist der normative Anker der Notation.
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.15 Data Modelling: das Klassendiagramm unter den zwei Notationen des Datenmodells, die Definition von Klasse, Attribut, Operation und Assoziation und die Routing-Regel, die es für eine objektorientierte Entwicklung einsetzt.