UML-Klassendiagramm-Beispiele
Zwei Domänen ordentlich modelliert, mit einer Begründung für jede Linie darauf - eine Bibliothek, die Vererbung braucht, und ein Warenkorb, der Komposition braucht.
6 Min. LesezeitUML 2.5.15 von 35
Die kurze Antwort
- Zwei Domänen decken jede Beziehungsart ab, die Sie zeichnen werden: eine Bibliothek, die Vererbung braucht, und ein Warenkorb, der Komposition braucht.
- Ein Diagramm ist eine Sicht auf ein Modell, nicht das Modell. Eine Sicht, die jede Klasse enthält, beantwortet nichts.
- Fünf bis zwölf Klassen. Über zwölf kreuzen sich die Beziehungen, und die Aufmerksamkeit geht ins Linienverfolgen statt in die Domäne.
- Zeichnen Sie die Klassen, um die es gerade geht, und lassen Sie die anderen zweihundert im Modell, wo ein Werkzeug sie findet.
01Eine Bibliothek, in der Vererbung ihren Platz verdient#
Das Diagramm oben lohnt sich Beziehung für Beziehung zu lesen. Book und DVD generalisieren LibraryItem, gezeichnet als hohles Dreieck, das auf den Elternteil zeigt - und der Grund, es so zu zeichnen statt als zwei unverbundene Klassen mit doppelten Attributen, ist die Assoziation darunter. Loan zeigt auf genau ein LibraryItem, und weil es auf den abstrakten Elternteil zeigt, kann es jeden Untertyp verleihen, ohne zu wissen, welchen.
Das ist der ganze Test für Vererbung in einem Domänenmodell: nicht "fühlen sich diese beiden Dinge ähnlich an", sondern gibt es irgendwo im Modell etwas, das entweder das eine oder das andere halten will, ohne sich um welches zu kümmern. Wenn nicht, sind zwei getrennte Klassen die kleinere und ehrlichere Antwort.
Beachten Sie die Multiplizitäten an der Assoziation Member zu Loan: 1 zu 0..*. Ein Mitglied ohne Ausleihen ist ein Mitglied; eine Ausleihe ohne Mitglied ist ein Bug. Diese Asymmetrie ist eine echte Tatsache über die Domäne und steht an der Linie, statt einem Kommentar überlassen zu werden. Der Artikel zum Klassendiagramm behandelt, wie jedes dieser Symbole gezeichnet wird.
02Ein Warenkorb, in dem Komposition ihren Platz verdient#
Dieses enthält gar keine Vererbung, und genau darum steht es neben der Bibliothek. Es hat stattdessen eine Komposition und eine Schnittstelle, und beide sind aus einem Grund da, für den das andere Diagramm keine Verwendung hatte.
Die gefüllte Raute zwischen Basket und BasketLine ist eine Behauptung: löschen Sie den Korb, und die Positionen gehen mit, denn eine Korbposition ist für sich bedeutungslos. Vergleichen Sie das mit der schlichten Assoziation von BasketLine zu Product, wo das Produkt die Position offensichtlich überlebt - dieselbe Beziehungsform, zwei verschiedene Lebensdauern, und die Notation unterscheidet sie.
PricingRule ist der Erweiterungspunkt. Zwei Realisierungen sind gezeichnet, weil eine Realisierung keine Abstraktion ist, sondern eine Klasse mit einem Zwischenschritt - und sobald es zwei gibt, ist eine dritte Aktion eine neue Klasse statt eines neuen Zweigs in einer bestehenden Methode.
03Wie man beide in dreißig Sekunden liest#
Beide Diagramme belohnen dieselbe Lesereihenfolge, und sie verläuft nicht von links nach rechts. Beginnen Sie mit den Multiplizitäten, denn sie sind die Entscheidungen: sie sagen, was das System zulässt, und sind später am schwersten zu ändern. Dann lesen Sie die Rauten, die sagen, was mit was gelöscht wird. Dann die Dreiecke, die sagen, was für was einstehen kann. Attribute zuletzt, und nur die, an denen Sie zweifeln.
Ein Diagramm, das diese Lesung übersteht, ist es wert, behalten zu werden. Eines, dessen Multiplizitäten leer sind, ist nicht fertig, wie viele Attribute es auch auflistet - und das ist bei weitem der häufigste Zustand, in dem man ein Klassendiagramm antrifft.
In je einer Zeile
- 01Zeichnen Sie Vererbung, wenn etwas im Modell den Elterntyp hält, ohne sich um den Untertyp zu kümmern.
- 02Nehmen Sie Komposition, wenn der Teil mit dem Ganzen gelöscht wird, sonst eine schlichte Assoziation.
- 03Eine Schnittstelle mit einer Realisierung ist eine Klasse mit Zwischenschritten; zwei machen sie zum Erweiterungspunkt.
- 04Multiplizitäten sind die Entscheidungen auf dem Diagramm. Leere heißen, es ist unfertig.
- 05Fünf bis zwölf Klassen je Diagramm. Eine Sicht, die alles enthält, beantwortet nichts.
Weiter: wie man eines von Grund auf zeichnet, und die Symbolreferenz zum Nachschlagen einer Marke, bei der Sie unsicher sind.
04Häufige Fragen#
Was ist ein gutes Beispiel für ein UML-Klassendiagramm?
Eines, das sich mit einem Blick lesen lässt und vollständig genug ist, um darüber zu streiten. Eine Bibliothek mit abstraktem LibraryItem und zwei Subtypen zeigt Vererbung, ein aus seinen Positionen komponierter Warenkorb zeigt Komposition. Zusammen decken sie jede Beziehungsart ab, die Sie zeichnen werden.
Muss ein Klassendiagramm jede Klasse des Systems zeigen?
Nein. Ein Diagramm ist eine Sicht auf ein Modell, nicht das Modell selbst, und eine Sicht, die alles enthält, beantwortet nichts. Zeichnen Sie die Klassen, um die es gerade geht, und lassen Sie die anderen zweihundert im Modell, wo ein Werkzeug sie weiterhin findet.
Wie viele Klassen gehören auf ein Klassendiagramm?
Fünf bis etwa zwölf. Unter fünf ist meist noch nicht genug gesagt, als dass sich das Zeichnen lohnte; über zwölf beginnen die Beziehungen sich zu kreuzen, und der Leser verbraucht seine Aufmerksamkeit darauf, Linien zu verfolgen, statt die Domäne zu verstehen.
In dieser Reihe
- 01Was ist UML?
- 02UML-Symbole
- 03Diagramm auswählen
- 04Klassendiagramme
- 05Klassendiagramm-Beispiele
- 06Klassendiagramm zeichnen
- 07Klassendiagramm-Symbole
- 08Sequenzdiagramme
- 09Sequenzdiagramm-Beispiele
- 10Sequenzdiagramm zeichnen
- 11Anwendungsfalldiagramme
- 12Anwendungsfall-Beispiele
- 13Aktivitätsdiagramme
- 14Aktivitätsbeispiele
- 15Zustandsdiagramme
- 16Zustandsdiagramm-Beispiele
- 17Komponentendiagramme
- 18Komponenten-Beispiele
- 19Komponentendiagramm zeichnen
- 20Komponenten-Symbole
- 21Verteilungsdiagramme
- 22Verteilungsbeispiele
- 23Objektdiagramme
- 24Paketdiagramme
- 25Kompositionsstrukturdiagramme
- 26Kommunikationsdiagramme
- 27Sequenz vs Kommunikation
- 28Zeitverlaufsdiagramme
- 29Interaktionsübersichtsdiagramme
- 30Profildiagramme
- 31UML mit KI
- 32E-Commerce-Beispiel
- 33Banken-Beispiel
- 34Microservices-Beispiel
- 35AWS-Beispiel
Passend dazu
Strukturdiagramme
Strukturdiagramme
Notationsreferenz
Grundlagen
Grundlagen
Verhaltensdiagramme