Quelltext der Seite Klassendiagramm

{{Thumbnailbox|INHALT=<uml>
@startuml

class Bar extends Foo {
 -{static} attribut1: int
 #attribut2: String
 ~methode1(parameter: Baz)
 +methode2()
}

abstract class Foo {
  +{abstract} methode3()
  -attribut3: boolean
}

Bar --> Baz

@enduml
</uml>
|CAPTION=Ein einfaches Klassendiagramm}}
Ein [[UML]]-[[Klassendiagramm]] stellt in einem [[Objektorientiertes Programmieren|objektorientierten Programm]] die enthaltenen [[Klasse]]n 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, [[Attribut (Informatik)|Attribut]]e und [[Unterprogramm#Methoden|Methoden]] sowie einige weitere Informationen enthalten. Folgende Informationen kann ein Klassendiagramm enthalten:
* [[Datentyp]]en von Attributen
* Datentyp der Rückgabewerte der Methoden
* Namen und Datentypen der Parameter der Methoden
* Sichtbarkeit von Attributen und Methoden
* ob Attribute und Methoden [[static|statisch]] sind
* ob Klassen und Methoden [[Abstrakte Klasse|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:

<syntaxhighlight lang="java" line="1">
@startuml

class Bar extends Foo {
 -{static} attribut1: int
 #attribut2: String
 ~methode1(parameter: Baz)
 +methode2()
}

abstract class Foo {
  +{abstract} methode3()
  -attribut3: boolean
}

Bar --> Baz

@enduml
</syntaxhighlight>

=== 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 <code>{static}</code> und <code>{abstract}</code> vor den Namen der Attribute und Methoden können diese als statisch bzw. abstrakt gekennzeichnet werden.

Die Zeichen <code>+</code>, <code>#</code>, <code>~</code> und <code>-</code> stehen dabei für die Sichtbarkeit der Attribute:
{| class="wikitable"
|+ Sichtbarkeits-Symbole
|-
! Symbol !! Sichtbarkeit
|-
| <code>+</code> || <code>public</code>
|-
| <code>~</code> || <code>package</code>
|-
| <code>#</code> || <code>protected</code>
|-
| <code>-</code> || <code>private</code>
|}

=== 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.

{| class="wikitable"
|+ Beziehungen zwischen den Klassen<ref>[https://www.edrawsoft.com/de/article/class-diagram-relationships.html Beziehungen in UML-Klassendiagrammen] in Edrawsoft, abgerufen am 26.09.2023</ref>
|-
! Beziehung !! Darstellung
!Semantik
|-
| 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 ([[Assoziation (Informatik)|Assoziation]])
|<code>A -- B</code>
|A und B können einander aufrufen (über eine Methode)
|-
|A implementiert Interface B
|<code><nowiki>A ..|> B</nowiki></code>
|A implementiert B (B ist ein Interface)
''Nicht klausurrelevant!''
|-
|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; In BlueJ ist ..> eine  Assoziation!''
|-
| [[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>
|A ist Teil von B, sodass A alleine existieren kann
|-
| [[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.

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 <code>Kundy</code> und <code>Konto</code> 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
{|
|<syntaxhighlight lang="java">
Kunde "*" -- "*" Konto
Klasse "1" -- "1" Klassenlehrkraft : leitet
Halter "1" <-- "*" Haustier
</syntaxhighlight>
|<uml>
@startuml
Kunde "*" -- "*" Konto
Klasse "1" -- "1" Klassenlehrkraft : leitet
Halter "1" <-- "*" Haustier
@enduml
</uml>
|}

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 ==

{{Benutzer:huh/UML-Klassendiagramm zum Möbelplaner}}

== Weblinks ==

* [https://plantuml.com/de Website von PlantUML {{Flagge|DE}}]
* [https://plantuml.com/de/class-diagram Klassendiagramme mit PlantUML {{Flagge|DE}}]

== Quellen ==
[[Kategorie:Objektorientierte Programmierung]]