Klassendiagramm: Unterschied zwischen den Versionen
Tit (Diskussion | Beiträge) K (typo) |
Tit (Diskussion | Beiträge) |
||
| Zeile 82: | Zeile 82: | ||
|- | |- | ||
! Beziehung !! Darstellung | ! Beziehung !! Darstellung | ||
!Semantik | |||
|- | |- | ||
| A steht in Beziehung zu B || <code>A --> B</code> | | A steht in Beziehung zu B (Uni-Direktionale [[Assoziation (Informatik)|Assoziation]]) || <code>A --> B</code> | ||
|A kann B aufrufen (über eine Methode) | |||
|- | |- | ||
|A und B stehen in Beziehung zueinander | |A und B stehen in Beziehung zueinander ([[Assoziation (Informatik)|Assoziation]]) | ||
|<code>A -- B</code> | |<code>A -- B</code> | ||
|A und B können einander aufrufen (über eine Methode) | |||
|- | |- | ||
|A hängt von B ab | |A hängt von B ab ([[Generalization (Informatik)|Generalization]]) | ||
|<code>A ..> B</code> | |<code>A ..> B</code> | ||
|A implementiert B (B ist ein Interface); ''In BlueJ ist ..> eine Assoziation!'' | |||
|- | |- | ||
| [[Vererbung (Informatik)|Vererbung]] || <code><nowiki>A --|> B</nowiki></code> oder <code>A extends B</code> | |A benutzt Interface B (Use [[Interface (Informatik)|Interface]]) | ||
|<code>A .. B</code> | |||
|A benutzt Interface B (welches in C implementiert ist, um C zu verändern) | |||
''nicht klausurrelevant'' | |||
|- | |||
| [[Vererbung (Informatik)|Vererbung]]|| <code><nowiki>A --|> B</nowiki></code> oder <code>A extends B</code> | |||
|A ist B (oder eine Art von B) | |||
|- | |- | ||
| [[Aggregation und Komposition|Aggregation]]|| <code>A --o B</code> | | [[Aggregation und Komposition|Aggregation]]|| <code>A --o B</code> | ||
|A ist Teil von B, sodass A alleine existieren kann | |||
|- | |- | ||
| [[Aggregation und Komposition|Komposition]]|| <code>A --* B</code> | | [[Aggregation und Komposition|Komposition]]|| <code>A --* B</code> | ||
|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 <code>Kundy</code> in Beziehung zu seinem <code>Konto</code> stehen – und umgekehrt. | 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 <code>Kundy</code> in Beziehung zu seinem <code>Konto</code> stehen – und umgekehrt. | ||
Version vom 26. September 2023, 18:52 Uhr
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.
Klassendiagramme mit PlantUML
Die Klassendiagramme in diesem Wiki sind mit PlantUML gezeichnet. PlantUML ist ein Werkzeug, das kompakte und gut lesbare Beschreibungen von UML-Diagrammen in Grafiken umsetzt. Das Diagramm oben auf der Seite ist mit folgendem PlantUML-Code erzegt worden:
@startuml
class Bar extends Foo {
-{static} attribut1: int
#attribut2: String
~methode1(parameter: Baz)
+methode2()
}
abstract class Foo {
+{abstract} methode3()
-attribut3: boolean
}
Bar --> Baz
@enduml
Klassen, Attribute und Methoden
Alle Bezeichner, hinter denen Klammern (ggf. mit Parametern) stehen, werden von PlantUML automatisch als Methoden erkannt, alle anderen als Attribute. Mit den Schlüsselwörtern {static} und {abstract} vor den Namen der Attribute und Methoden können diese als statisch bzw. abstrakt gekennzeichnet werden.
Die Zeichen +, #, ~ und - stehen dabei für die Sichtbarkeit der Attribute:
| Symbol | Sichtbarkeit |
|---|---|
+ |
public
|
~ |
package
|
# |
protected
|
- |
private
|
Beziehungen
Die Beziehungen zwischen den Klassen können mit Pfeilen dargestellt werden. Wenn eine Beziehung auf eine nicht ausführlich definierte Klasse verweist, wird eine leere Klassenbox eingefügt.
| Beziehung | Darstellung | Semantik |
|---|---|---|
| A steht in Beziehung zu B (Uni-Direktionale Assoziation) | A --> B
|
A kann B aufrufen (über eine Methode) |
| A und B stehen in Beziehung zueinander (Assoziation) | A -- B
|
A und B können einander aufrufen (über eine Methode) |
| A hängt von B ab (Generalization) | A ..> B
|
A implementiert B (B ist ein Interface); In BlueJ ist ..> eine Assoziation! |
| A benutzt Interface B (Use Interface) | A .. B
|
A benutzt Interface B (welches in C implementiert ist, um C zu verändern)
nicht klausurrelevant |
| Vererbung | A --|> B oder A extends B
|
A ist B (oder eine Art von B) |
| Aggregation | A --o B
|
A ist Teil von B, sodass A alleine existieren kann |
| Komposition | A --* B
|
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.
In PlantUML werden die Kardinalitäten an den Enden des Pfeils notiert. Dahinter kann der Beziehung noch ein Name gegeben werden
Kunde "*" -- "*" Konto
Klasse "1" -- "1" Klassenlehrkraft : leitet
Halter "1" <-- "*" Haustier
|
 |
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
