Zu diesem Thema gibt es ein Tutorial!

Klassendiagramm: Unterschied zwischen den Versionen

Aus KGS-Wiki
K (→‎Beziehungen: Link korrigiert)
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 1: Zeile 1:
{{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 (Informatik)|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:
Ein [[UML]]-[[Klassendiagramm]] stellt in einem [[Objektorientiertes Programmieren|objektorientierten Programm]] die enthaltenen [[Klasse (Informatik)|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]]en von Attributen
Zeile 33: Zeile 13:
Dennoch sind Klassendiagramme als Dokumentationswerkzeug wertvoll, da man sich durch diese leicht einen Überblick über die Komponenten und den Aufbau eines Softwareprodukts verschaffen kann.
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 ==
== Darstellung ==
 
{{Thumbnailbox
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:
| INHALT = <uml>
 
<syntaxhighlight lang="java" line="1">
@startuml
@startuml


Zeile 55: Zeile 33:


@enduml
@enduml
</syntaxhighlight>
</uml>
| CAPTION = Ein einfaches Klassendiagramm
}}
=== 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 <code>Foo</code>, <code>Bar</code> und <code>Baz</code>.


=== Klassen, Attribute und Methoden ===
Im obersten Abschnitt steht der Name der Klasse. Wenn eine Klasse abstrakt ist, wird dies durch den Hinweis <code><<abstract>></code> dargestellt oder durch einen kursiv geschriebenen Klassennamen. In der Abbildung ist die Klasse <code>Foo</code> abstrakt.
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:
Im mittleren Abschnitt stehen die Attribute in der Form <code>Sichtbarkeit Bezeichner: Datentyp</code>. Die Sichtbarkeit wird dabei durch die folgenden Symbole dargestellt:
{| class="wikitable"
{| class="wikitable"
|+ Sichtbarkeits-Symbole
|+ Sichtbarkeits-Symbole
Zeile 66: Zeile 47:
! Symbol !! Sichtbarkeit
! Symbol !! Sichtbarkeit
|-
|-
| <code>+</code> || <code>public</code>
| <code>+</code>/🟢 || <code>public</code>
|-
|-
| <code>~</code> || <code>package</code>
| <code>~</code>/[[Datei:Triangle blue.svg|16x16px]] || <code>package</code>
|-
|-
| <code>#</code> || <code>protected</code>
| <code>#</code>/🔶 || <code>protected</code>
|-
|-
| <code>-</code> || <code>private</code>
| <code>-</code>/🟥 || <code>private</code>
|}
|}
Statische Attribute sind zusätzlich unterstrichen. In, der Abbildung wäre dies das Attribut <code>attribut1</code> der Klasse <code>Bar</code>.
Im dritten Abschnitt stehen die Methoden, in der Form <code>Sichtbarkeit Name(Parameter1, Parameter2...): Rückgabe-Datenyp</code> notiert. Ebenso wie statische Attribute sind statische Methoden unterstrichen.


=== Beziehungen ===
=== 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.
Die Beziehungen zwischen den Klassen werden mit Pfeilen dargestellt.


{| class="wikitable"
{| class="wikitable"
Zeile 84: Zeile 68:
!Semantik
!Semantik
|-
|-
| A steht in Beziehung zu B (Uni-Direktionale [[Assoziation (Informatik)|Assoziation]]) || <code>A --> B</code>
| A steht in Beziehung zu B (Uni-Direktionale [[Assoziation (Informatik)|Assoziation]])
|A kann B aufrufen (über eine Methode)
| <uml>
@startuml
class A
A --right--> B
@enduml
</uml>
|Instanzen von A können auf Instanzen von B zugreifen
|-
|-
|A und B stehen in Beziehung zueinander ([[Assoziation (Informatik)|Assoziation]])
|A und B stehen in Beziehung zueinander ([[Assoziation (Informatik)|Assoziation]])
|<code>A -- B</code>
| <uml>
|A und B können einander aufrufen (über eine Methode)
@startuml
class A
A --right-- B
@enduml
</uml>
|A und B können aufeinander zugreifen
|-
|-
|A implementiert Interface B
|A implementiert Interface B
|<code><nowiki>A ..|> B</nowiki></code>
| <uml>
@startuml
class A
A ..right..|> B
@enduml
</uml>
|A implementiert B (B ist ein Interface)
|A implementiert B (B ist ein Interface)
|-
|-
|A benutzt Interface B (''Use [[Interface]]'')
|A benutzt Interface B (''Use [[Interface]]'')
|<code>A ..> B</code>
| <uml>
|A benutzt Interface B (welches in C implementiert ist, um C zu verändern)
@startuml
class A
A ..right..> B
@enduml
</uml>
|A benutzt Interface B  
''In BlueJ ist ..> eine  Assoziation!''
''In BlueJ ist ..> eine  Assoziation!''
|-
|-
| [[Vererbung (Informatik)|Vererbung]]|| <code><nowiki>A --|> B</nowiki></code> oder <code>A extends B</code>
| [[Vererbung (Informatik)|Vererbung]]
|A ist B (oder eine Art von B)
| <uml>
@startuml
class A
A --right--|> B
@enduml
</uml>
|jedes A ist ein B
|-
|-
| [[Aggregation und Komposition|Aggregation]]|| <code>A --o B</code>
| [[Aggregation und Komposition|Aggregation]]
| <uml>
@startuml
class A
A --left--o B
@enduml
</uml>
|A ist Teil von B, sodass A alleine existieren kann
|A ist Teil von B, sodass A alleine existieren kann
|-
|-
| [[Aggregation und Komposition|Komposition]]|| <code>A --* B</code>
| [[Aggregation und Komposition|Komposition]]
| <uml>
@startuml
class A
A --left--* B
@enduml
</uml>
|A ist Teil von B, sodass A nur mit B existieren kann
|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.
{{Thumbnailbox|INHALT=<uml>
 
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
@startuml
Kunde "*" -- "*" Konto
Kunde "*" -- "*" Konto
Zeile 126: Zeile 139:
Halter "1" <-- "*" Haustier
Halter "1" <-- "*" Haustier
@enduml
@enduml
</uml>
</uml>|CAPTION=Kardinalitäten}}
|}
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.


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.
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.
Zeile 134: Zeile 149:


{{Benutzer:huh/UML-Klassendiagramm zum Möbelplaner}}
{{Benutzer:huh/UML-Klassendiagramm zum Möbelplaner}}
== Siehe auch ==
* {{Hinweis Tutorial|Klassendiagramme in PlantUML}}


== Weblinks ==
== Weblinks ==


* [https://plantuml.com/de Website von PlantUML {{Flagge|DE}}]
* {{Inf-Schule|7.2.5.2.4|Modellierung eines Klassendiagramms}}
* [https://plantuml.com/de/class-diagram Klassendiagramme mit PlantUML {{Flagge|DE}}]


== Quellen ==
== Quellen ==

Aktuelle Version vom 25. März 2024, 15:56 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.

Darstellung

Ein einfaches Klassendiagramm

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:

Sichtbarkeits-Symbole
Symbol Sichtbarkeit
+/🟢 public
~/Triangle blue.svg 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.

Beziehungen zwischen den Klassen[1]
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

Kardinalitäten

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

  1. ↑ Beziehungen in UML-Klassendiagrammen in Edrawsoft, abgerufen am 26.09.2023
Abgerufen von „https://wiki.kah.gs/index.php?title=Klassendiagramm&oldid=4064“