1 Identifikation/Definition der Methode
/ Booch, Rumbaugh, Jacobson, 97 /
2 Kurzcharakteristik der Methode
Ziel und Zweck
Die Methode dient zur objektorientierten Systementwicklung. Zielsetzung der Zustandsmodellierung im objektorientierten Bereich ist die Modellierung des dynamischen Verhaltens eines Systems bei der Anwendung objektorientierter Software-Entwicklungskonzepte. Wichtigstes Anwendungsgebiet ist die Modellierung des dynamischen Verhaltens von Objekten signifikanter ereignisgesteuerter Klassen. Solche Klassen spezifizieren im allgemeinen "aktive" Objekte.
Das Verhalten von Objekten einer Klasse ist als Lebenszyklus zu abstrahieren und wird in einem Zustandsmodell modelliert. Das Zustandsmodell soll alle Zustände, die ein Objekt annehmen kann, die möglichen Zustandsübergänge, die Ereignisse, die Zustandsübergänge bewirken können, die Bedingungen, die neben den Ereignissen für einen Zustandswechsel erfüllt sein müssen, und die Aktionen, die infolge von Zustandsübergängen auszuführen sind, definieren.
Mit den Zuständen werden Datenwerte, die die Attribute eines Objektes einer Klasse annehmen können, und mögliche Verknüpfungen mit anderen Objekten festgelegt. Der Zustandsübergang, der für ein Objekt einer Klasse in einer konkreten Situation eintritt, ist eindeutig durch den Zustand, in dem sich das Objekt aktuell befindet, das eingetroffene Ereignis sowie spezifizierte Bedingungen bestimmt.
Ein Pfad in einem Zustandsmodell repräsentiert eine Folge von Ereignissen. Szenarien, die häufig während der Analyse zur Formulierung gewünschter Ereignisfolgen verwendet werden, müssen auf die Pfade der spezifizierten Zustandsmodelle abbildbar sein.
Darstellungsmittel
Als Darstellungsmittel der Zustandsmodellierung im objektorientierten Bereich kommen Zustandsdiagramme und textliche Beschreibungen in zusätzlichen Spezifikationen (auch in Tabellen- oder Matrizenform) und "Data Dictionaries" zum Einsatz. Ein Zustandsmodell einer Klasse wird durch ein Zustandsdiagramm dargestellt. Ein Zustandsdiagramm stellt damit das dynamische Verhalten einer Klasse dar.
Zustände werden in Zustandsdiagrammen in Form eines graphischen Symbols dargestellt. Zustandsübergänge werden in Form von Pfeilen zwischen Zustandssymbolen repräsentiert. Ereignisse, Bedingungen und Aktionen werden in textlicher Form den Symbolen zugeordnet. Eine ausführliche Beschreibung der Darstellungsmittel findet sich in / Booch, Rumbaugh, Jacobson, 97 /. Der Ursprung dieser Darstellungsarten findet sich in den Arbeiten von Harel / Harel, 87 /.
Zustandsdiagramme können geschachtelt werden, wodurch Zustände und Ereignisse in Generalisierungshierarchien angeordnet werden können. Dies ermöglicht die übersichtliche Beschreibung des dynamischen Verhaltens komplexer Systeme. Neben sequentiellen Ereignisfolgen können auch Nebenläufigkeiten dargestellt werden.
Zustandsübergänge können durch Ereignisse, Bedingungen und nicht unterbrechbare Aktionen näher spezifiziert werden, müssen es aber nicht. Ereignisse sind zu benennen und können mit Attributen versehen werden, die die Übergabe von Daten beim Übergang in einen neuen Zustand spezifizieren. Mit Bedingungen kann der Zustandsübergang "überwacht" werden. Er findet nur statt, wenn das Ereignis eintritt und zusätzlich die Bedingungen erfüllt sind. Die Aktionen werden ausgeführt, wenn die Zustandsübergänge stattfinden. Zustände können durch einfache Eintritts- bzw. Austrittsaktionen und komplexere und daher unterbrechbare Aktivitäten spezifiziert werden.
Eine andere Form der Zustandsdiagramme, die eine Zustandsmodellierung in einer flachen Struktur erlaubt, ist die von Moore. Sie wird von Shlaer/Mellor in der Methode "Object Oriented Analysis" angewendet (/ Shlaer, Mellor, 92 /). Sie bietet jedoch gegenüber der Darstellungsform von Harel nicht so detaillierte Modellierungsmöglichkeiten.
Funktioneller Ablauf
Die Zustandsmodellierung im objektorientierten Bereich ist für jede Klasse durchzuführen, deren Objekte ein signifikantes, nicht-triviales dynamisches Verhalten haben. Sie wird iterativ eingesetzt, wobei bei jedem Durchlauf detailliertere, verfeinerte oder auch neue bzw. geänderte Zustandsdiagramme entstehen. Die Iterationen sind in die Vorgehensweisen der jeweils verwendeten komplexen objektorientierten Entwicklungsmethode eingebettet. Grundsätzlich können folgende Schritte unterschieden werden:
Bei zu umfangreichen Zustandsdiagrammen empfiehlt sich eine Dekomposition nach Harel.
3 Grenzen des Methodeneinsatzes
Die Methode sollte nur für Klassen angewendet werden, deren Objekte ein signifikantes, nicht-triviales dynamisches Verhalten aufweisen.
4 Detaillierung der Methodenzuordnung
4.1 ZUSTO in Aktivität SE 1.1 "Ist-Aufnahme/-Analyse durchführen"
Mit Hilfe der Methode kann der Ist-Zustand des dynamischen Verhaltens des Altsystems erfaßt werden. Die Detaillierung ist dabei einzugrenzen, da nur das wesentliche dynamische Verhalten darzustellen ist.
Die Methode deckt im Produkt "Anwenderforderungen" das Teilprodukt "Ist-Aufnahme und Ist-Analyse" aus Sicht des dynamischen Verhaltens ab.
4.2 ZUSTO in Aktivität SE 1.2 "Anwendungssystem beschreiben"
Mit Hilfe der Methode können im Rahmen der groben Systembeschreibung Anforderungen an das dynamische Verhalten des Systems definiert werden.
Die Methode deckt im Produkt "Anwenderforderungen" für das Teilprodukt "Grobe Systembeschreibung" die Darstellung des dynamischen Verhaltens des Systems ab.
4.3 ZUSTO in Aktivität SE 1.4 "Randbedingungen definieren"
Mit Hilfe der Methode können die sich durch technische, organisatorische und weitere Randbedingungen ergebenden Anforderungen an das dynamische Verhalten des Systems spezifiziert werden.
Die Methode deckt im Produkt "Anwenderforderungen" das Teilprodukt "Randbedingungen" aus Sicht des dynamischen Systemverhaltens ab.
4.4 ZUSTO in Aktivität SE 1.5 "System fachlich strukturieren"
Mit Hilfe der Methode kann aus fachlicher Sicht das dynamische Verhalten des Systems bis auf Segmentebene definiert bzw. verfeinert werden.
Die Methode deckt im Produkt "Anwenderforderungen" das Teilprodukt "Beschreibung der Funktionalität" aus Sicht des dynamischen Verhaltens ab.
4.5 ZUSTO in Aktivität SE 2.5 "Schnittstellen beschreiben"
Durch die Definition von Systemfunktionen als Zustände können mit Hilfe der Methode Anforderungen an zulässige Reihenfolgen in der Anwendung von Systemfunktionen in Zustandsmodellen spezifiziert werden.
Die Methode deckt im Produkt "Schnittstellenbeschreibung" das Teilprodukt "Beschreibung der Schnittstellen" aus Sicht zulässiger Aufrufreihenfolgen ab.
4.6 ZUSTO in Aktivität SE 3.2 "Anforderungen an die externen Schnittstellen der SW-/HW-Einheit präzisieren"
Durch die Definition von Funktionen als Zustände können mit Hilfe der Methode Anforderungen an die zulässige Aufrufreihenfolge von Softwarefunktionen in Zustandsmodellen spezifiziert werden.
Die Methode deckt im Produkt "Technische Anforderungen" das Teilprodukt "Technische Anforderungen an die Schnittstellen" aus Sicht zulässiger Aufrufreihenfolgen ab.
4.7 ZUSTO in Aktivität SE 3.3 "Anforderungen an die Funktionalität definieren"
Mit Hilfe der Methode kann das dynamische Verhalten der SW-Einheit definiert bzw. verfeinert werden, um Anforderungen an die technische Funktionalität zu spezifizieren.
Die Methode deckt im Produkt "Technische Anforderungen" bezogen auf die SW-Einheit das Teilprodukt "Gesamtfunktion des Elements" aus Sicht des dynamischen Verhaltens ab.
4.8 ZUSTO in Aktivität SE 4.2-SW "SW-interne und -externe Schnittstellen entwerfen"
Durch die Definition von Funktionen als Zustände können mit Hilfe der Methode zulässige Aufrufreihenfolgen von SW-Funktionen in Zustandsmodellen spezifiziert werden.
Die Methode deckt im Produkt "Schnittstellenbeschreibung" das Teilprodukt "Beschreibung der Schnittstellen" aus Sicht zulässiger Aufrufreihenfolgen ab.
4.9 ZUSTO in Aktivität SE 5.1-SW "SW-Komponente/-Modul/Datenbank beschreiben"
Mit Hilfe der Methode kann das dynamische Verhalten von SW-Komponenten/SW-Modulen in detaillierten Zustandsmodellen modelliert werden. Es ist eine Verfeinerung bzw. Erweiterung der in den vorangegangenen Aktivitäten erarbeiteten Strukturen vorzunehmen.
Die Methode deckt im Produkt "SW-Entwurf" das Teilprodukt "Realisierung der SW-Komponente/des SW-Moduls" aus Sicht des dynamischen Verhaltens ab.
5 Schnittstellen
5.1 Schnittstelle ZUSTO - KOM
In Ergänzung zu der in der Methode KOM definierten statischen Struktur von Klassen wird in der Methode ZUSTO das signifikante dynamische Verhalten von Klassen aktiver Objekte modelliert. Die Modellierung von Zuständen ist mit der Modellierung von Klassenattributen, die Modellierung von Ereignissen und Aktionen mit der Modellierung von Klassenoperationen abzustimmen.
Während mit der Methode KOM der statische Aufbau von Schnittstellen spezifiziert werden kann, sind mit der Methode ZUSTO zulässige Aufruffolgen von Funktionen der Schnittstelle darstellbar.
5.2 Schnittstelle ZUSTO - UCM
Die mittels der Methode UCM definierten Anwendungsfälle können als Informationsbasis für die Modellierung von Zustandsmodellen in der Methode ZUSTO verwendet werden.
5.3 Schnittstelle ZUSTO - IAM
Als Ausgangspunkt für die Definition von Zustandsmodellen in der Methode ZUSTO können mittels der Methode IAM definierte Szenarien verwendet werden.
6 Weiterführende Literatur
/
Harel,
87 /,
/
Schader,
Rundshagen, 96 /,
/
Shlaer,
Mellor, 92 /