Klassendiagramm
Ein UML-Klassendiagramm stellt in einem objektorientierten Programm die enthaltenen Klassen und ihre Beziehungen untereinander dar. Klassendiagramme sind ein Werkzeug, um zu Beginn des Software-Entwicklungsprozesses den Aufbau des fertigen Produktes grob zu umreißen. In einem Klassendiagramm sind die Namen aller Klassen, Attribute und Methoden sowie einige weitere Informationen enthalten. Folgende Informationen kann ein Klassendiagramm enthalten:
- Datentypen von Attributen
- Datentyp der Rückgabewerte der Methoden
- Namen und Datentypen der Parameter der Methoden
- Sichtbarkeit von Attributen und Methoden
- ob Attribute und Methoden statisch sind
- ob Klassen und Methoden abstrakt sind
UML-Klassendiagramme enthalten nur die oberflächliche Information, welche Klassen, Attribute und Methoden es geben, wie sie heißen sollen und in welcher Beziehung die Klassen zueinander stehen, aber keinerlei ausführbare Programmlogik.
In einer idealen Welt modelliert man nach dem Projektstart und bevor man auch nur ein einziges Mal die Tastatur berührt das komplette Projekt vollständig als Klassendiagramm und hat dadurch einen vollständigen Überblick über alle zu implementierenden Methoden und alle zu erledigenden Aufgaben, die dann umso leichter zu verteilen sind. Soweit die Theorie. In der Praxis ändern sich vor, während und nach einem Projekt fortwährend die Anforderungen, sodass anfangs gezeichnete Diagramme oft wertlos sind.
Dennoch sind Klassendiagramme als Dokumentationswerkzeug wertvoll, da man sich durch diese leicht einen Überblick über die Komponenten und den Aufbau eines Softwareprodukts verschaffen kann.
Darstellung
Klassen, Attribute und Methoden
Klassen werden dargestellt durch rechteckige Kästen, die in drei untereinander liegende Abschnitte unterteilt sind. In der Abbildung wären das die Klassen Foo, Bar und Baz.
Im obersten Abschnitt steht der Name der Klasse. Wenn eine Klasse abstrakt ist, wird dies durch den Hinweis <<abstract>> dargestellt oder durch einen kursiv geschriebenen Klassennamen. In der Abbildung ist die Klasse Foo abstrakt.
Im mittleren Abschnitt stehen die Attribute in der Form Sichtbarkeit Bezeichner: Datentyp. Die Sichtbarkeit wird dabei durch die folgenden Symbole dargestellt:
| Symbol | Sichtbarkeit |
|---|---|
+/🟢 |
public
|
~/ |
package
|
#/🔶 |
protected
|
-/🟥 |
private
|
Statische Attribute sind zusätzlich unterstrichen. In, der Abbildung wäre dies das Attribut attribut1 der Klasse Bar.
Im dritten Abschnitt stehen die Methoden, in der Form Sichtbarkeit Name(Parameter1, Parameter2...): Rückgabe-Datenyp notiert. Ebenso wie statische Attribute sind statische Methoden unterstrichen.
Beziehungen
Die Beziehungen zwischen den Klassen werden mit Pfeilen dargestellt.
| Beziehung | Darstellung | Semantik |
|---|---|---|
| A steht in Beziehung zu B (Uni-Direktionale Assoziation) |  |
Instanzen von A können auf Instanzen von B zugreifen |
| A und B stehen in Beziehung zueinander (Assoziation) |  |
A und B können aufeinander zugreifen |
| A implementiert Interface B |  |
A implementiert B (B ist ein Interface) |
| A benutzt Interface B (Use Interface) |  |
A benutzt Interface B
In BlueJ ist ..> eine Assoziation! |
| Vererbung |  |
jedes A ist ein B |
| Aggregation |  |
A ist Teil von B, sodass A alleine existieren kann |
| Komposition |  |
A ist Teil von B, sodass A nur mit B existieren kann |
Eine Klasse A steht in Beziehung zu einer Klasse B, wenn Objekte von A Objekte von B als Attribute haben. In einer fiktiven Banking-Anwendung würde zum Beispiel jedes Kundy in Beziehung zu seinem Konto stehen – und umgekehrt.
Bei solchen Beziehungen können auch Kardinalitäten angegeben werden, d.h. wie viele Objekte aus Klasse A mit wie vielen Objekten aus Klasse B in Beziehung stehen können. Im Falle von Kundy und Konto wäre es z.B. eine m:n-Beziehung – ein Kundy kann beliebig viele Konten unterhalten, ein Konto aber auch, z.B. als Gemeinschaftskonto von Eheleuten, von mehreren Kundys genutzt werden.
Eine Klasse A hängt von einer Klasse B ab, wenn sie diese wenigstens teilweise nutzt, sodass alle Änderungen an Klasse B sich auch auf Klasse A auswirken könnten – insbesondere Änderungen in den Methoden-Schnittstellen von B. Entwicklys, die an B arbeiten, sollten dies immer berücksichtigen.
Größeres Beispiel
Siehe auch
Weblinks
Quellen
- ↑ Beziehungen in UML-Klassendiagrammen in Edrawsoft, abgerufen am 26.09.2023
UML-Diagramme: Klassendiagramm | Sequenzdiagramm | Aktivitätsdiagramm
Weitere Diagrammtypen: ER-Diagramm | Programmablaufplan
