Was ist ein UML-Klassendiagramm?

Die Unified Modeling Language (Abk. UML) ist eine grafische Beschreibungssprache. UML wurde Mitte der 1990er-Jahre von Booch, Rumbaugh und Jacobson entwickelt und 1997 in der Version 1.1 bei der Object Management Group zur Standardisierung eingereicht. Seit dem wird UML kontinuierlich weiterentwickelt und liegt aktuell (November 2020) in der Version 2.5.1 vor.

Die UML bietet mehrere verschiedene Diagrammtypen, mit denen jeweils bestimmte Zustände oder Abläufe dargestellt werden können. Jeder Diagrammtyp eignet sich für die Darstellung einer bestimmten Situation oder Fragestellung besonders gut. 

Im Unterschied zum Entity-Relationship-Modell deckt die Unified Modeling Language den gesamten Softwareentwurf ab und geht damit über den konzeptuellen Datenbankentwurf hinaus. Insbesondere wird eine Reihe von Techniken angeboten, um das dynamische Verhalten eines Systems zu definieren, beispielsweise durch Festlegen der zulässigen Abfolgen der einzelnen Anwendungsprozesse. Wir beschränken uns im Wesentlichen hier auf das Klassendiagramm.

Was beschreibt das Grundparadigma der Objektorientierung in der Programmierung?

Das Grundparadigma der Objektorientierung ist, dass ein Programm eine Ansammlung von Objekten ist, die miteinander interagieren. Jedes Objekt gehört zu einer bestimmten Klasse und ist mit Datenfeldern und Methoden ausgerüstet. Der Wert der Datenfelder beschreibt den Zustand des Objektes; die Methoden dienen dazu, diesen Zustand zu verändern und mit anderen Objekten zu kommunizieren.

Was ist eine Abstraktion?

Eine der wichtigsten Ideen der objektorientierten Programmierung ist die Trennung zwischen Konzept und Umsetzung. Hierzu wurden die Begriffe Klasse und Objekt eingeführt.

Ein Objekt ist eine tatsächlich existierende Repräsentation einer „Sache“ aus dem zu entwickelnden Anwendungssystem. Beispiele für Objekte sind das Personenobjekt „Erich Freitag“, das Autoobjekt „VW Golf“ oder das Druckerobjekt „Laserdrucker OG1“. 

Objekte müssen instanziiert – quasi zum Leben erweckt – werden, damit die Eigenschaften und das Verhalten der Objekte in einem Programm genutzt werden können. Anstelle von Objekten spricht man auch gerne von den „Instanzen einer Klasse“.

Eine Klasse ist die Beschreibung eines oder mehrerer ähnlicher Objekte, d.h. Objekte des gleichen Typs. Objekte einer Klasse müssen sich nicht in allen Details gleichen, aber in vielen Eigenschaften übereinstimmen. Beispiel einer Klasse ist „Personenkraftwagen“, das die Beschreibung aller Automarken von verschiedensten Herstellern repräsentieren kann. Die Attribute und Methoden der Klasse „Personenkraftwagen“ müssen so gewählt sein, dass hiermit die unterschiedlichsten Ausprägungen gemäß den Anforderungen umfassend beschrieben werden können.

Die Unterscheidung zwischen Klasse und Objekt kann als Abstraktion angesehen werden. Hiermit wird es möglich, Details einer Problemstellung zu ignorieren und somit die Komplexität des Problems zu reduzieren. Es findet somit eine Abbildung der realen Welt in eine abstrakte logische Ebene (bestehend aus Klassen und Objekten) statt.

Was sind Klassen?

Klassendiagramme (engl.: Class diagrams) geben Antwort auf die Frage „wie sind die Daten und das Verhalten meines Systems im Detail strukturiert?“. Es zeigt dessen wesentliche statischen Eigenschaften sowie die Beziehungen zueinander. 

Klassendiagramme repräsentieren den Kern der gesamten Modellierungssprache. Sie zeigen die Klassen, die Eigenschaften der Klassen (Attribute), das Verhalten (Operationen) der Klassen und die Beziehungen zwischen den Klassen.

Eine Klasse enthält

• Den Namen der Klasse (hier classPerson)
• Die Attribute der Klasse (mVorname, mNachname, …) entsprechend den Daten
• Und die Operationen der Klasse (SetzeName(), …)

Was sind Objekte?

Ein Objekt ist eine in einem Gesamtkontext wahrnehmbare und damit identifizierbare, benennbare, agierende und konkrete Einheit, die eindeutig von seiner Umgebung abgrenzbar ist.

In seinem inneren Aufbau besitzt es einen konkreten Zustand und ein Verhalten. Ein Objekt besitzt einen Zugang von außen, über den andere Objekte ein bestimmtes Verhalten aktivieren können. Dagegen ist der Zustand eines Objekts für andere Objekte verborgen. Ein Objekt ist damit so etwas wie die Repräsentation eines Elements einer Klasse zur Laufzeit.

Was bedeutet es, dass ein Objekt in der Programmierung seine Zustands- und Verhaltensinformationen kapselt?

Ein Objekt kapselt seine Zustands- und Verhaltensinformationen, d.h. die Zustände von Objekten sind von außen nicht ersichtlich, sondern nur über Operationen, die über eine Schnittstelle zur Verfügung gestellt werden.

Auf die Daten „Vorname“ und „Nachname“ kann von außen weder schreibend noch lesend zugegriffen werden – die Daten können nur ausgelesen werden, wenn die Operation LeseName() aufgerufen wird.

Auf Grund der Kapselung können Objekte gegen Varianten ausgetauscht werden, solange das Verhalten an den Schnittstellen identisch ist. Dies ist auch ein wesentlicher Aspekt für Produktfamilien und Systemvarianten. Wichtig ist die Kapselung auch, damit Daten von Objekten nicht von außen her unkontrolliert verändert werden können, sondern lediglich über die entsprechenden Operationen.

Was sind Assoziationen?

Assoziationen sind Beziehungen zwischen Objekten und Klassen. Objekte tauschen über Assoziationen Nachrichten aus. Bei der Suche nach Assoziationen muss daher die Frage gestellt werden: „Welche Objekte kommunizieren miteinander?“.

In einem Projekt sind aber nur die Assoziationen zu modellieren, die zur Lösung des gestellten Problems benötigt werden. Die Verben aus den Anforderungsspezifikationen geben oft Hinweise auf mögliche Assoziationen.

Was sind Kardinalitäten?

Eine Assoziation sagt zunächst nur aus, dass ein Objekt andere Objekte kennen kann. Kardinalitäten – auch Multiplizitäten genannt – geben an, wie viele Objekte der assoziierten Klasse mindestens oder höchstens mit einem Objekt der eigenen Klasse assoziiert sein müssen oder dürfen – anders gesagt, wie viele andere Objekte ein Objekt kennen kann oder muss.

Anders gesagt sind Kardinalitäten (engl.: cardinalities) 

• Beschränkungen der Anzahl der möglichen Beziehungen, die ein Gegenstand zu anderen Gegenständen höchstens haben darf oder mindestens haben muss
• Angaben zur Anzahl der erlaubten Werte zu einem Attribut

Die Maximalkardinalitäten für Beziehungen geben im Wesentlichen an, ob es sich um 1:1, 1:N oder M:N Beziehungen handelt. Die Minimalkardinalitäten spezifizieren zusätzlich, ob die Existenz einer Beziehung zu einem gegebenen Gegenstand optional oder zwingend ist. Die Min-Max-Notation wird auch numerische Notation genannt.

Für Kardinalitäten gibt es verschiedene Notationskonventionen. Die „klassische“ Notation, die z.B. in Entity-Relationship-Modellen angewendet wird, ist spiegelbildlich zu den Mengenverhältnissen:

Jede(r) MitarbeiterIn arbeitet in genau einer Abteilung (Min 1, Max 1). Eine Abteilung beschäftigt 1…n Mitarbeiter (Min 1, Max n). Jede Abteilung sitzt zumindest an einem Ort (Min 1, Max n). Ein Ort kann 0…n Abteilungen umfassen.

Anstelle der Angabe „1..1“ ist auch nur „1“ möglich – dies bedeutet, dass Min- und Max-Wert identisch sind. In gleicher Weise genügt statt „0..*“ die Angabe „*“. Die Kardinalitäten werden an den Enden der Assoziationen angegeben.