Zustandsdiagramme zeigen die durch Ereignisse (Events) beeinflussten Zustände, die ein Objekt annehmen kann, sowie die Ereignisse oder Nachrichten, die im kausalen Zusammenhang mit einem Zustandswechsel stehen. In einem Geschäftssystem wird die Zustandsänderung der Objekte (Verhalten) durch Geschäftsprozesse nach Geschäftsregeln ausgelöst.

Am leichtesten sind Zustandsdiagramme zu verstehen, wenn die objektorientierte Programmierung verstanden wurde. Für Objekte gelten folgende Grundsätze:

• jedes Objekt gehört jeweils zu genau einer Klasse
• die Klasse beschreibt den Anfangszustand sowie Startparameter (welche den Zustand jedoch sofort ändern können)
• ein Objekt wird aus einer Klasse erzeugt und irgendwann wieder zerstört (gelöscht), der Zeitraum zwischen Erzeugung und Zerstörung ist der Lebenszeitraum des Objekts
• während des Lebenszeitraums kann ein Objekt von Ereignissen oder Nachrichten beeinflusst werden und dadurch seinen Zustand wechseln.

Zustandsdiagramme haben ihre größte Bedeutung in der Software-Entwicklung, Geschäftsprozessmodellierung oder allgemeiner in der Wirtschaftsinformatik.

Elemente eines Zustandsdiagramms

1. Zustand

Eine Aktivität bildet eine Funktion/Methode bzw. einen Prozess ab. Aktivitäten werden in abgerundeten Rechtecken dargestellt.

2. Übergänge (Ereignisse)

Übergänge stehen für Ereignisse.

2.1 Einfacher Übergang

Ein Übergang verursacht einen Zustandswechsel. Übergänge symbolisieren Ereignisse und werden mit Pfeilen dargestellt. Ereignisse können eingeteilt werden in:

• objekterzeugende Ereignisse
• Ereignisse zur Lebenszeit des Objekts
• objektzerstörende Ereignisse

Ein Ereignis kann statt einer Entscheidung auch eine einfache Bedingung haben. Bedingungen (als boolesche Ausdrücke) für Übergänge werden in eckigen Klammern an den jeweiligen Übergang geschrieben.

2.2 Aufspaltung

Die Aufspaltung führt von einem Ereignis zu mehreren Ereignisse. Eine horizontale oder vertikale Linie dient als Synchronisationsbalken, der für die Parallelisierung der nachfolgenden Ereignisse steht.

2.3 Zusammenführung

Die Zusammenführung ist die Umkehrung der Aufspaltung: Mehrere Ereignisse lösen ein Ereignis aus.

3. Entscheidung (Verzweigung)

Eine Verzweigung hat einen Eingang und mindestens zwei Ausgänge.

4. Startzustand

Tritt ein objekterzeugendes Ereignis ein, so beginnt der Übergang dem Symbol für den Startzustand.

Der Startzustand symbolisiert die Entstehung (in der Software-Entwicklung: Instanziierung) eines Objekts.

5. Endzustand

Tritt ein objektzerstörendes Ereignis ein, so endet ein Übergang beim Symbol für den Endzustand.

Endzustand bedeutet das Lebensende bzw. die Löschung des Objekts.

Beispiel eines Zustandsdiagramm

Das nachfolgende Zustandsdiagramm zeigt das Verhalten einer verteilten Anwendung (Client-Server-Programm). Diese Anwendung besteht im Grunde aus zwei verschiedenen Programmen, einem Client- und einem Server-Programm.

Aktivitätsdiagramme sind vergleichbar mit Programmablaufplänen oder Struktogrammen und nicht nur in der Software-Entwicklung nützlich, sondern auch in der Prozessabbildung, beispielsweise zur Abbildung von Geschäftsprozessen. Aktivitätsdiagramme ermöglichen die Abbildung von Verantwortungsbereichen über Prozesse sowie die Parallelisierung von Prozessen, was Aktivitätsdiagramme besonders für die Darstellung und Analyse von Geschäftsprozessen in der Wirtschaftsinformatik und Aktivitäten bei verteilten Anwendungen in der Software-Entwicklung qualifiziert.

Elemente eines Aktivitätsdiagramms

1. Aktivität

Eine Aktivität bildet eine Funktion/Methode bzw. einen Prozess ab. Aktivitäten werden in abgerundeten Rechtecken dargestellt.

2. Zustand

Zustände von Objekten werden in Rechtecken dargestellt und sind in Aktivitätsdiagrammen als Eingangs- und Ausgangsinformation von Bedeutung. Viele Aktivitätsdiagramme kommen jedoch auch ganz ohne Zustände aus.

3. Kontrollfluss (Übergang)

Mit einem Kontrollfluss werden ein oder mehrere Aktivitäten ausgelöst. Diese Übergänge von Startpunkt zu Prozessen, Prozessen untereinander bis zu einem Endpunkt werden mit Pfeilen dargestellt. Jede Aktivität (Prozess) beginnt und endet mit einem Übergang, wenn nicht mit einer Verzweigung.

3.1 Einfacher Kontrollfluss

Ein einzelner Pfeil zeigt einen einfachen Übergang zwischen Startpunkt und Prozess, Prozess und Prozess oder Prozess und Endpunkt.

3.2 Aufspaltung

Die Aufspaltung führt von einem Prozess zu mehreren Prozessen. Eine horizontale oder vertikale Linie dient als Synchronisationsbalken, der für die Parallelisierung der nachfolgenden Prozesse steht.

3.3 Zusammenführung

Die Zusammenführung ist die Umkehrung der Aufspaltung: Mehrere Prozesse führen zu einem Prozess.

4. Entscheidung (Verzweigung)

Eine Verzweigung hat einen Eingang und mindestens zwei Ausgänge.

5. Startzustand

6. Endzustand

7. Verantwortlichkeitsbereiche

Jede Aktivität liegt in einem Verantwortlichkeitsbereich, beispielsweise in einer Client- oder Server-Software oder in verschiedenen Unternehmensbereichen.

Aktivitätsdiagramm – Beispiel

Nachfolgend ein vereinfachtes Beispiel eines Aktivitätsdiagramms, welches den Zahlungsprozess zwischen Kunden, Kassierer und Kassensystem abbildet. Aus Gründen der Einfachheit wird nur die Möglichkeit der EC-Karten-Zahlung eingeräumt.

Das Klassendiagramm ist wahrscheinlich eines der Diagramme, welches zum großen Erfolg von UML beigetragen haben.

Mit dem Klassendiagramm lassen sich die für ein Programm entworfenen Klassen mit Atrributen und Methoden sowie den Beziehungen der Klassen zueinander visualisieren.
Ein Klassendiagramm ist daher nur auf die objektorientierte Software-Entwicklung anwendbar.

Ein Klassendiagramm muss nicht den vollständigen Klassenentwurf wiedergeben, sondern kann sich auch nur auf einen Ausschnitt relevanter Klassen beziehen.

Beispiel:

Obiges Klassendiagramm zeigt die Beziehung zweier Klassen. Die linke Klasse Eurofighter steht in Beziehung mit einer anderen Klasse Rakete.

Die Klasse Eurofighter hat Attribute (obere, rote Liste), welche die Eigenschaften der Klasse beschreiben. Außerdem hat die Klasse Operationen (untere, grüne Liste), welche die möglichen Funktionen (Methoden) der Klasse zeigen.

Dass in die Klasse Rakete keine Attribute und Operationen eingetragen wurden ist nicht weiter tragisch. Oft wird der Fokus auf die relevanten Klassen gelegt und nur bedingt relevante Klassen vereinfacht dargestellt; das Abstraktionslevel wird nicht selten bewusst gebrochen.

Ein UML-Klassendiagramm dient primär der Planung und Konzeption, als Hilfestellung für Software-Entwickler.
Es gibt zudem Programme, welche ein, nach den Programmrichtlinien erstelltes, Klassendiagramm in Quellcode umsetzt.

Beziehungen der objektorientierten Programmierung

Assoziation

Die Assoziation ist die einfachste Beziehung zwischen Klassen. Die Assoziation ist i.d.R. mit einem einfachen Strich symbolisiert. Die Objekte der Klassen bleiben trotz der Beziehung voneinander unabhängig und sind gleichberechtigt. Wird ein Objekt einer Klasse zerstört, existiert die andere Klasse unabhängig weiter.

Aggregation und Komposition

Das nachfolgende Schaubild eines Klassendiagramms zeigt drei Klassen Bücherregal, Buch und Seite.

Wie sind die Beziehungen dieser drei Objekte? Eine Seite ist fester Bestandteil eines Buches, sie kann nicht einfach ausgetauscht oder umgeheftet werden; Die Seiten werden mit dem Buch gekauft, verbrennt das Buch, verbrennen die Seiten des Buches unbedingt mit.
Ein Buch hingegen kann in dieses oder jenes Regal gestellt werden. Seiten sind also fest mit Büchern verbunden, Bücher aber nicht mit Regalen.

Die Aggregation ist eine häufig verwendete Beziehungsform in der Objektorientiertheit.
Die beschreibt eine Klassenbeziehung, bei welcher eine Klasse n Klassen übergeordnet ist und einbindet. Die Bindung ist fest, allerdings können die Objekte der untergeordneten Klassen auch ohne die der übergeordneten Klasse existieren.

Die Aggregation wird i.d.R. mit einer weißen oder transparenten Raute symbolisiert (obige Skizze: linke Beziehung).

Die Komposition beschreibt ebenfalls eine feste Bindung einer übergeordneten Klasse zu n untergeordneten Klassen. Allerdings können die Objekte der untergeordneten Klassen bei der Komposition nicht ohne die der übergeordneten Klassen existieren. Wird das Objekt der übergeordneten Klasse zerstört, sind auch die untergeordneten Objekte zerstört.

Eine Komposition wird i.d.R. mit einer schwarzen Raute dargestellt (obige Skizze: rechte Beziehung).

Die Raute liegt immer auf der Seite der übergeordneten Klasse.

Aggregation vs Komposition – Interpretationssache

Ob Aggregation oder Komposition anzuwenden ist, hängt von den Umständen und Zielen ab. Es kann z.B. für ein Software-Projekt notwendig sein, dass z.B. die virtuelle Buchseite doch auch unabhängig vom Buch existieren kann.

Beispiel: Klassengebilde Auto

In diesem Klassendiagramm hat die Klasse Auto auch die Klassen Motor und Getriebe. Die Objekte der untergeordneten Klassen Motor und Getriebe können auch ohne das (Objekt) Auto existieren! Außerdem können Motor und Getriebe von Auto zu Auto getauscht werden.
Daher werden die Beziehungen als Aggregation vereinbart.

Genauso gut kann die Klasse Auto die Klassen Motor und Getriebe aber auch über eine Komposition verwenden. Bedingt durch die Komposition können die beiden Objekte der Klassen Motor und Getriebe nicht ohne das Objekt Auto existieren. Das Getriebe und der Motor kann somit auch nicht von Auto zu Auto getauscht werden.

Vererbung

Die Vererbung ist die wohl interessanteste, obwohl sehr indirekte, Beziehung der Klassen bzw. der Klassenobjekte untereinander.
In der objektorientierten Programmierung können Datentypen Klassen so “Eltern” bzw. “Kinder” haben. Die “Eltern”-Klassen können ihre Eigenschaften (Attribute) und Methoden an ihre Kinder vererben. Da, im Gegensatz zur Schnittstellenvererbung, nicht nur Signaturen von Operationen, sondern die gesamten Operationen vererbt werden, ist hier speziell die Implementierungsvererbung gemeint.

Eine Vererbung wird mit Pfeilen dargestellt, der Pfeil zeigt vom Erben zum Vererber. Man spricht von Mehrfachvererbung, wenn eine Klasse von mehr als einer Klasse erbt.

Beispiel an Hand der Mehrfachvererbung: Mechatronik enthält die Eigenschaften der Elektronik und Mechanik

Ein weiteres, typisches Beispiel zur Erläuterung des Vererbungsprinzips ist das Beispiel der Vererbungsbeziehung zwischen Fahrzeug-Klassen.

Die oberste Klasse ist die abstrakte Klasse Fahrzeug. Eine abstrakte Klasse ist nicht instanziierbar (also praktisch nicht direkt verwendbar). Die Klasse Fahrzeug stellt zwar alle Grundfunktionen und Eigenschaften zur Verfügung, welche ein Fahrzeug bieten muss (jedes Fahrzeug sollte u.a. einen Geschwindigkeitstacho haben, fahren und anhalten können), die allgemeine Definition Fahrzeug als abstrakte Klasse kann jedoch noch nicht verwendet werden.

Fahrzeuge können PKW und LKW sein (oder bei entsprechendem Klassenentwurf auch ein Motorrad oder Motorboot). Ein PKW sowie auch ein LKW haben alle Eigenschaften eines Fahrzeugs, bringen jedoch auch ganz eigene Eigenschaften mit, wie z.B. eine eigene Sitzplatzgestaltung.
In diesem Beispiel sind des weiteren bestimmte Typen eines PKW definiert. Ein PKW kann die Gestaltung eines Vans, einer Limousine oder eines Sportwagens mit entsprechenden Spezifikationen haben.

Interface (Schnittstelle)

Eine Schnittstellenvererbung funktioniert ähnlich wie die Implementierungsvererbung. Anders als bei der Implementierungsvererbung werden jedoch keine vollständigen Operationen, sondern nur die Signaturen (i.d.R.: Rückgabewert, Methodenname, Parameternamen und – datentypen), vererbt.
Das Interface (Vererber), welches von einer anderen Klasse implementiert wird, sichert damit nur zu, dass die implementierende Klasse eine bestimmte Funktionalität bereitstellt.

Erklärungsbeispiel: Ein Interface Fahrstuhl hat die Signaturen der Methoden “hochfahren()”, “herunterfahren()” und “anhalten()”.
Damit sagt das Interface Fahrstuhl aus: “Wer mich implementiert, der muss die Funktionen hochfahren(), herunterfahren() und anhalten() haben und mit Funktionalität versorgen, ansonsten kann er mich nicht implementieren“.

Häufig werden Interfaces mit einem vorangestellten “I” namentlich gekennzeichnet, ein Interface “Fahrstuhl” hieße so “IFahrstuhl”, ein Interface “Verbindung” mit dieser Kennzeichnung “IVerbindung”.

Im UML-Klassendiagramm werden Schnittstellen zur Verdeutlichung meistens mit dem Zusatz “<<interface>>” versehen.

Dargestellt wird eine Schnittstellenvererbung bzw. -implementierung mit Hilfe von gestrichelten Pfeilen.

Die Darstellung mit Pfeilen ist die sinngemäße Anlehnung an die Implementierungsvererbung (welche mit durchgezogenen Pfeilen dargestellt wird).

Die Schnittstellenvererbung kann auch mit Hilfer einer anderen Darstellungsweise skizziert werden. Beispielsweise verwendet Microsoft für die Schnittstellenimplementierung keine Pfeile, sondern eine Art “Anker”.

Diese Darstellungsweise hat die Vorteile, dass keine Linien zwischen dem Interface und den implementierenden Klassen gezogen werden müssen (platzsparend) und dass die äußerst indirekte Beziehung der Schnittstellenvererbung betont wird.

Hinweise:
Mit UML-Klassendiagrammen können eine Obermenge an Modellen und Strukturen dargestellt werden, allerdings können nicht alle objektorientierten Programmiersprachen all diesen Konzepten gerecht werden. Während beispielsweise C++ Mehrfachvererbung unterstützt, erlaubt C# nur eine einfache Vererbung.

Bei der Entwicklung z.B. eine Office-Anwendung oder einer Shop-Software können sich die Entwickler schnell in einem “Wirrwar” aus Benutzer-Rechten verlieren, “Wer darf was und was eigentlich nicht?”.

Im sogenannten Anwendungsfall-Diagramm (engl. Use-Case-Diagram) werden Benutzer (engl. User) als kleine Strichmännchen dargestellt und so im Diagramm als Akteur, der auf das Programm Einfluss nehmen kann, symbolisiert. Aktionen, wie z.B. Anzeigen, Drucken oder Suchen, werden i.d.R. als Ovale dargestellt.

Um ein Anwendungsfall-Diagramm besser zu gliedern, kann es mehrere Anwender-Bereiche haben, z.B. Administrator-Bereich und Gäste-Bereich.

Include-Beziehung im Anwendungsfall-Diagramm

Die Aktionen können sich gegenseitig einschließen. Beispielsweise kann ein Administrator (= ein Akteur) eines Webportals einem Benutzer-Profil ein Passwort zuweisen (= eine Aktion) oder ein neues Profil anlegen. Letztere Aktion schließt jedoch auch erstere Aktion mit ein (ein neues Profil benötigt einen Passwortschutz). Da letztere Aktion zwangsweise erstere Aktion einschließt, zeigt ein gestrichelter Pfeil mit der Aufschrift “include” von der einbeziehenden Aktion auf die einbezogene Aktion.

Das Beziehungsverhältnis “include” drückt aus, dass eine Aktion die andere Aktion zwangsweise einschließt.

Extend-Beziehung im Anwendungsfall-Diagramm

Aktionen können sich auch nur eventuell einschließen und nicht gezwungener Maßen. Beispielweise hat die Aktion Bezahlen nicht unbedingt auch die Aktion Geld zählen zur Folge, denn bezahlt werden kann (systemabhängig) auch mit Kreditkarte oder noch anderen bargeldlosen Zahlungsmitteln (die möglicherweise wiederum andere Aktionen eventuell oder zwangsweise einschließen).

Kann eine Aktion eine Andere eventuell einschließen, wird statt der Include-Beziehung eine Extend-Beziehung verwendet. Diese eventuelle Einbeziehung einer Aktion kann zusätzlich eine Bedingung haben (z.B. ob Bargeld als Zahlungsmittel erlaubt ist), welche meistens als quadratisches Kästchen visualisiert wird.

Beispiel eines Anwendungsfall-Diagramms

Das folgende Anwendungsfall-Diagramm zeigt Anwendungsfälle in einem Shop-System.

Unterschieden werden drei Akteure:

• Verkäufer
• Kunde
• VIP-Kunde

Der VIP-Kunde ist eine erweiterte Form des Kunden, er kann zusätzlich Warenbewertungen abgeben.
Was einen Kunden zum VIP-Kunden macht, ist aus einem Anwendungsfalldiagramm nicht ersichtlich.

Hinweis: Anwendungsfall-Diagramme können je nach Stil oder UML-Version in der Erscheinung etwas variieren.
Häufig werden beispielsweise Aktionen, die andere Aktionen via Extend einbinden, mit einem anderen Symbol dargestellt. Die generelle Visualisierungsprinzip eines Anwendungsfall-Diagramms bleibt jedoch immer erhalten.

UML ist jedoch genau genommen nicht eine Sprache oder ein Verfahren, sondern eine Sammlung an verschiedenen Verfahren, welche unterschiedliche Views (zu Deutsch: Ansichten, Perspektiven) auf eine Software-Architektur bieten.

UML ist keine technisch definierte Sprache, sondern eine standarisierte abstrakte Konzeption. UML hat mehrere Versionen durchlaufen, von der Version 1.0 bis (aktuell) zur Version 2.0.

UML-Diagramme sind ein wichtiges Hilfsmittel bei der Konzeptionierung und Dokumentation von komplexer Software. Nicht selten sind UML-Diagramme Teil des Lasten-/Pflichtenhefts. Mit UML-Diagrammen lassen sich schon vor der Umsetzung Konzeptionierungsfehler entdecken und beheben. Zusätzlich kann die Software-Architektur mittels UML auch Laien näher gebracht werden.

Hier soll auf die wichtigsten UML 2.0 Diagramme eingegangen werden:

Strukturdiagramme

• Klassendiagramm
• Objektdiagramm
• Kompositionsstrukturdiagramm
• Verteilungsdiagramm

Verhaltensdiagramme

• Aktivitätsdiagramm
• Anwendungsfalldiagramm
• Zustandsdiagramm
• Sequenzdiagramm
• Kommunikationsdiagramm