Previous Next Methods Allocation  
4.46 Elementarmethode "Zustandsmodellierung im objektorientierten Bereich" (ZUSTO)  

  4.46 Elementary Method "State Modeling in the OO Field" (STMO)

Inhalt  
  • 1 Identifikation/Definition der Methode
  • 2 Kurzcharakteristik der Methode
  • 3 Grenzen des Methodeneinsatzes
  • 4 Detaillierung der Methodenzuordnung
  • 5 Schnittstellen
  • 6 Weiterführende Literatur
  • 7 Funktionale Werkzeuganforderungen
  • Verknüpfungen mit der V-Modell Mailingliste
  • 1 Identifikation/Definition der Methode

    /Booch, 1997/ Unified Modeling Language, Version 1.0

    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, 1997/. Der Ursprung dieser Darstellungsarten findet sich in den Arbeiten von Harel /Harel, 1987/.

    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, 1992/). 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

    Nr. Aktivität Beschreibung
    4.1 SE1.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 SE1.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 SE1.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 SE1.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 SE2.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 SE3.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 SE3.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 SE4.2 - 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 SE5.1 - 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

    Nr. Schnittstellen Bemerkung Information (Anhang 1)
    5.1 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 ZUSTO-UCM Die mittels der Methode UCMdefinierten Anwendungsfälle können als Informationsbasis für die Modellierung von Zustandsmodellen in der Methode ZUSTO verwendet werden.  
    5.3 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, 1987/ Statecharts: A Visual Formalism for Complex Systems
    /Schader, Rundshagen, 1996/ Objektorientierte Systemanalyse
    /Shlaer, Mellor, 1992/ Object Lifecycles - Modeling the World in States

    7 Funktionale Werkzeuganforderungen

    SSD27 - Supporting State Modeling in the Object-Oriented Field

    Verknüpfungen mit der V-Modell Mailingliste

    Mail 0200 - Re: Methodenzuordnung fuer UML (200)

    Previous Next This page online  •  GDPA Online  •  Last Updated 08.Oct.2002 by C. Freericks