UML

Zustandsdiagramme sind eine Form in UML die den Zustand von Objekten darzustellen und gehören zu den Verhaltensdiagrammen.

Der Zustand ist vor allem dadurch gekennzeichnet, welcher Wert in den Attributen gespeichert ist und gilt für alle Objekte einer Klasse. Da ein Objekt während seines Lebens verschiedene Zustände annehmen kann, ist es interessant darzustellen, durch welche Aufruf von Methoden des Objekts sich welche Attribute ändern.

Die Methoden können entweder direkt aufgerufen werden oder das Objekt bekommt Nachrichten, die dazu führen, dass die Methoden aufgerufen werden. Man kann das Zustandsdiagramm sozusagen als Verfeinerung der Darstellung einer Klasse in UML betrachten.

Alle Zustände sollten einen Namen bekommen der den Zustand verbal beschreibt, wie "aktiv" oder "wartend". Diese Namen sollten auch nicht verwechselt werden können, innerhalb einer Klasse sind sie ohnehin einmalig. Wenn in anderen Klassen ähnliche Zustände erreicht werden können, dann sollten Verben und Adjektive mit einem Begriff ergänzt werden, der deutlich macht wozu der Zustand gehört.

Natürlich kann man gar nicht alle möglichen Zustände abbilden, aber die wesentlichen Zustände des Objekts und wie es dazu kommen kann (Zustandsübergänge, sog. Transitionen "feuern") sollten dargestellt werden.

Ereignisse die zu der Transition führen werden neben den Pfeil geschrieben, der die Zustände miteinander verbindet ("nach einer Sekunde", "täglich um 3:00 Uhr", "bei Druck auf Abbruch-Button"), bei Voraussetzung einer Bedingung kommt diese in eckige Klammern.

Unbedingt darzustellen sind der Anfangszustand und ein oder mehrere Endzustände, insbesondere der Fall, wann das Objekt gelöscht wird.

In den 90er Jahren entstand als Reaktion auf zahlreiche Vorschläge für Modellierungssprachen und -methoden UML. Damit sollte die damals hochaktuelle objektorientierte Softwareentwicklung unterstützt werden. Erfinder der UML waren insbesondere Grady Booch, Ivar Jacobson und James Rumbaugh (auch als "die drei Amigos" bekannt, wohl in Anlehnung an den sehr mäßigen Spielfilm).

Bei ihrer Tätigkeit im Unternehmen Rational Software entstand der Ansatz, die vorhandenen Methoden strukturiert zusammenzuführen. Daraus entstand die UML, zur Standardisierung, Pflege und Weiterentwicklung wurde die Sprache wurde an OMG übergeben, die die Sprache am 19. November 1997 als Standard akzeptierte.

Ab August 1999 strebte die OMG dann die Weiterentwicklung an, verschiedene Gruppen und Einzelpersonen reichten Entwürfe ein.und im Oktober 2002 konnten alle Vorschläge für die UML 2.0 Infrastructure und die UML 2.0 Superstructure präsentiert werden. Die Hauptschwierigkeit bestand nun darin, die unterschiedlichen Entwürfe zu einer Spezifikation zu verbinden. Erst im Februar 2007 konnte die OMG die jetzt aktuelle Version UML 2.1.1 veröffentlichen, die aber noch nicht von allen UML-Tools unterstützt wird.

Bei der "Use-Case"-Analyse (auf deutsch auch Anwendungsfall-Analyse) wird genau einen Ablauf oder einen Prozess beschrieben. Dabei definiert man eine Interaktion zwischen Akteuren (dargestellt als Strichmännchen) und dem betrachteten System.

Hintergrund ist dabei immer ein beestimmtes fachliches Ziel (plattdeutsch: "business goal") zu erreichen. Die UML2 vermeidet allerdings den Begriff "System" und verwendet stattdessen den Begriff "Subjekt" um zu betonen, dass ein Anwendungsfall das erforderliche Verhalten einer Vielzahl von Modellelementen der UML2 deklarieren kann.

Definition: Ein Use Case beschreibt eine abgeschlossene, ununterbrochene Abfolge von Aktionen eines Akteurs am System mit Ergebnis von fachlichem Wert.

Schwierig ist die Abgrenzung von Anwendungsfällen, vor allem da sie nicht immer an Geschäftprozessen festzmachen sind. Um festzustellen, ob ein Anwendungsfall schon zu komplex ist, wurde von Cockburn der "Kaffeepausen-Test" vorgeschlagen: Ein Anwendungsfall soll so weit gehen, wie ein Nutzer für diesen Anwendungsfall und die notwendige Interaktion keine Kaffeepause einlegen würde.

Ein CASE-Tool für die Darstellung von Use-Case ist Rational Rose, ein Werkzeuge für die Architektur- und Entwurfsmodellierung, die modellorientierte Entwicklung, die architekturbasierte zeiteffiziente Anwendungsentwicklung (Rapid Application Development, RAD) sowie die Durchführung von Komponententests und Laufzeitanalyse.

(aus einer Use-Case-Modellierung mit Rational Rose)