% ------------------------------------------------------------------ %
%                                                                    %
% Datei: modell.tex                                                  %
% Autor: Oliver Nietsch                                              %
%                                                                    %
% Universitaet Hamburg                                               %
% Fachbereich Informatik                                             %
% Arbeitsbereich DBIS                                                %
%                                                                    %
% Thema: Diplomarbeit: Die Modellierung und Validierung dynamischen  %
%                      Systemverhaltens am Beispiel von StP/OMT      %
%                      und Tycoon                                    %
%                                                                    %
% Inhalt: LaTeX-Dokument: Diplomarbeit,                              %
%                         Kapitel 4: Statecharts zur Modellierung    %
%                                    dynamischen Systemverhaltens    %
%                                                                    %
% Version vom 18. 4.1997                                             %
% ------------------------------------------------------------------ %

\chapter{Tycoon Statecharts zur Modellierung dynamischen Systemverhaltens}
\label{Chap:Harel}

Dynamisches Systemverhalten bezeichnet, wie in Abschnitt~\ref{SubSec:OMTMeta} dargestellt, die Gesamtheit der einnehmbaren Zust"ande und der m"oglichen Zustands"uberg"ange eines Systems unter Ber"ucksichtigung zustands"ubergangsausl"osender Ereignisse. Bei der Erstellung eines Spezifikationsmodells des Systemverhaltens eines zu entwickelnden Anwendungssystems werden in vielen Softwareentwicklungsmethoden, wie z.B. in der Strukturierten Analyse oder der \engl{Structured Systems Analysis and Design Method} (SSADM), endliche Automaten zur Spezifikation des Systemverhaltens verwendet \cite{fricke95}.

Ein endlicher Automat stellt ein mathematisches Modell eines Systems mit diskreten Ein- und Ausgaben dar. Zu jedem Zeitpunkt befindet sich das System in einem Zustand aus einer endlichen Menge von m"oglichen Zust"anden, den Konfigurationen \cite{hopcroft90}. Zum Entwurf des Verhaltens von Systemen mit endlichen Zustandsmengen und diskreten Zustands"uberg"angen bietet die Theorie der endlichen Automaten ein ad"aquates Werkzeug zur Systemspezifikation.

Allerdings zeigt sich, da"s bei gro"sen, komplexen Systemen schnell die Grenzen der Modellierungsm"achtigkeit endlicher Automaten erreicht werden, da sie in ihrem Umfang unhandlich und un"ubersichtlich werden. Eine Erg"anzung um Zustandstabellen oder -matrizen kann zwar ihre Aussagekraft erg"anzen, f"uhrt aber zu einer nicht weniger komplexen Darstellung des aus endlichen Automaten und Zustandstabellen oder -matrizen bestehenden Verhaltensmodells des Systems. Au"serdem wird so der Vorteil einer ausschlie"slich grafischen Repr"asentation des Verhaltens eines Systems mit endlicher Zustandsmenge aufgegeben.

Eine Erweiterung des Modells endlicher Automaten stellt die Spezifikationssprache der Statecharts dar \cite{harel87}. Sie wird in diesem Kapitel dargestellt und im Rahmen dieser Arbeit innerhalb des Tycoon Systems exemplarisch in einer textuellen Repr"asentation implementiert. Schwerpunktm"a"sig werden Statecharts, wie in Abschnitt~\ref{SubSec:Dynam} erl"autert, zur grafischen Modellierung und Spezifikation des Verhaltens ereignisgesteuerter Systeme eingesetzt \cite{huizing91}, die in einer fortw"ahrenden Interaktion mit ihrer Systemumgebung stehen. Solche reaktiven Systeme sind z.B. Steuerungseinrichtungen f"ur Flugzeuge oder Kraftwerke oder das in Abschnitt~\ref{SubSec:Dynam} eingef"uhrte Beispiel der Fernsehersteuerung. F"ur die Modellierung rein statischer Systeme, wie z.B. eines \engl{Repositorys}, sind Statecharts nicht geeignet.

Ausgehend von der Statechart Originalnotation aus \cite{harel87} sind sowohl die Statechart Syntax als auch die Semantik in vielen Forschungsarbeiten verschieden dargestellt und erweitert worden. In \cite{beek94} ist ein Vergleich und eine Bewertung einiger unterschiedlicher Statechartvarianten enthalten.

Grundlage der in diesem Kapitel vorgestellten Tycoon Statechart Syntax innerhalb einer Tycoon Umgebung f"ur eine textuelle statechartbasierte Modellierung dynamischen Systemverhaltens als Basis f"ur die in Abschnitt~\ref{Sec:statechartenv} dargestellte Tycoon Validierungsumgebung sind die Statechartelemente des dynamischen Modells der in Abschnitt~\ref{Sec:OOMod} dargestellten Softwareentwicklungsmethode OMT. Es handelt sich bei den von der OMT Methode im Rahmen des dynamischen Modells verwendeten Statechartelementen um eine Teilmenge der in \cite{beek94} verglichenen Syntaxelemente der zahlreichen Statechartvarianten.

Diese Teilmenge wird im Rahmen des exemplarischen Aufbaus der statechartbasierten Tycoon Modellierungsumgebung zur Spezifikation dynamischen Systemverhaltens auf die in der Abbildung~\ref{Fig:ChartMeta} in der Notation des OMT Objektmodells \cite{rumb91} dargestellten Statechart Syntaxelemente weiter eingeschr"ankt.

\section{Statecharts als strukturierte endliche Automaten}
\label{Sec:ChartStruk}

Zust"ande und Zustands"uberg"ange stellen die Grundelemente endlicher Automaten dar. Zustands"uberg"ange, auch als Transitionen bezeichnet, arbeiten auf einer endlichen Menge von Eingabesymbolen aus einem Eingabealphabet und "uberf"uhren einen Zustand in einen Nachfolgezustand \cite{hopcroft90}. Formal sind Zustands"uberg"ange als eine "Ubergangsfunktion von Quellzustand und Eingabezeichen in einen Zielzustand definiert. "Uberf"uhrt eine Folge von Eingabezeichen den endlichen Automaten von einem Startzustand in einen Endzustand, so wird das Eingabewort vom Automaten akzeptiert. Es geh"ort somit zur Sprache dieses endlichen Automaten. Neben diesen akzeptierenden endlichen Automaten gibt es endliche Automaten, deren Zust"ande (Moore Maschine) oder Zustands"uberg"ange (Mealy Maschine) mit der Ausgabe von Zeichen assoziiert sind.

Bildlich dargestellt entspricht ein endlicher Automat einem gerichteten Graphen, bei dem die Knoten den Zust"anden und die gerichteten Kanten (Pfeile) zwischen den Knoten den Transitionen des endlichen Automaten entsprechen. Die Eingabesymbole werden an die Pfeile notiert. Bei einer Moore Maschine werden zus"atzlich noch die Ausgabezeichen an die entsprechenden Zust"ande geschrieben, mit Zustands"uberg"angen assoziierte Ausgabezeichen werden bei der Mealy Maschine an der entsprechenden Transition vom Eingabezeichen durch einen Schr"agstrich getrennt dargestellt.

Statecharts erweitern das Modell endlicher Automaten um die Konzepte der Dekomposition von Zust"anden und Orthogonalit"at von Zust"anden und Zustands"uberg"angen \cite{glinz95}. Bei Statecharts werden Eingabezeichen als Ereignisse bezeichnet und Ausgabezeichen als Aktionen. Sowohl Ereignisse als auch Aktionen sind mit Transitionen verkn"upft. Allerdings k"onnen auch, wie in Abschnitt~\ref{SubSec:Aktionen} dargestellt, Aktionen mit Zust"anden assoziiert werden. Ereignisse l"osen Zustands"uberg"ange aus, zus"atzlich k"onnen Bedingungen Zustands"uberg"ange einschr"anken.\\

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{figure=chartmta.eps,width=15cm}
  \end{center}
  \caption{\label{Fig:ChartMeta} Statechart Metamodell}
\end{figure}

Wie in der Abbildung~\ref{Fig:ChartMeta} wiedergegeben, werden im Rahmen der exemplarischen Implementierung der Tycoon Umgebung {\sl StatechartEnv} zur Modellierung dynamischen Systemverhaltens in einer Tycoon Statechart Repr"asentation (im folgenden auch als Tycoon Statecharts bezeichnet) die folgenden Statechart Syntaxelemente betrachtet:

\begin{itemize}
  \item Zustand
  \item Zustands"ubergang zwischen Zust"anden
  \item Ereignis, sowohl externes Ereignis als auch internes Ereignis, das Zustands"uberg"ange ausl"ost
  \item Aktion zum Generieren interner Ereignisse als auch zum Ausl"osen externer Ereignisse
  \item Bedingung zur Einschr"ankung von Zustands"uberg"angen
  \item Aktivit"at als zeitandauernde Handlung mit Start und Stop Aktion
\end{itemize}

Eine detaillierte, informelle Darstellung dieser Statechartelemente ist in \cite{harel87} enthalten. Innerhalb dieser Arbeit erfolgt eine Erl"auterung der einzelnen Komponenten in den Abschnitten "uber ihre textuelle Tycoon Repr"asentation weiter unten in diesem Kapitel.

Ein Statechart aggregiert Zust"ande, Zustands"uberg"ange und Ereignisse. Jeder Zustands"ubergang besitzt einen Vorg"anger- und Nachfolgezustand. Ein Ereignis kann einen oder mehrere Zustands"uberg"ange ausl"osen, falls eine f"ur das Stattfinden eines Zustands"ubergangs definierte Bedingung g"ultig ist. Ein Zustands"ubergang kann eine oder mehrere Aktionen umfassen, die in der Form von intern generierten Ereignissen wiederum einen oder mehrere Zustands"uberg"ange ausl"osen k"onnen. Entsprechend der Moore Maschine bei endlichen Automaten kann ein Zustand mit einer oder mehreren Aktionen assoziiert werden. Eine oder mehrere in einem Zustand definierte Eingangsaktionen k"onnen einen oder mehrere Zustands"uberg"ange beim "Ubergang in diesen Zustand ausl"osen, entsprechendes gilt f"ur Ausgangsaktivit"aten beim "Ubergang in den Nachfolgezustand. Laut Synchronit"atshypothese \cite{huizing88} treten Ereignisse und Zustands"uberg"ange zeitverzugslos auf. Eine Aktivit"at hingegen stellt eine zeitandauernde Handlung dar, die durch eine initiierende Startaktion und eine die Aktivit"at terminierende Aktion kontrolliert wird oder solange ausgef"uhrt wird, wie die aktuelle Konfiguration des Systems den mit der Aktivit"at assoziierten Zustand umfa"st (vgl. Abschnitt~\ref{SubSec:Konfig}).

David Harel definiert Statecharts in \cite{harel87} mit der Formel:

\begin{quote}
  {\small \engl{statecharts = state diagrams + depth + orthogonality + broadcast-communication}}
\end{quote}

Tiefe (\engl{depth}) entsteht innerhalb von Zustandsdiagrammen durch Zusammenfassung oder Verfeinerung von Zust"anden. Diese Strukturierung und Hierarchisierung von Zust"anden erlaubt es, selbst komplexe und von der Gr"o"se her umfangreiche Zustandsdiagramme "ubersichtlich und f"ur die Anwender und Entwickler durchschaubar darzustellen. Im Gegensatz zu endlichen Automaten k"onnen somit eine Vielzahl von Zust"anden und Zustands"uberg"angen innerhalb eines von der Aussage her mit einem endlichen Automaten vergleichbaren Statecharts zusammengefa"st werden. Ein modelliertes System kann beliebig verfeinert auf unterschiedlichen Abstraktionsebenen in Teildiagrammen des Gesamtsystems dargestellt werden, was dazu f"uhrt, da"s die Teildiagramme f"ur sich selbst betrachtet "ubersichtlich bleiben. Allerdings kann durch die Verwendung unterschiedlicher Abstraktionsebenen bei der Diagrammverfeinerung in vielen Teildiagrammen der "Uberblick "uber das Gesamtsystem verloren gehen, was auch durch die Verwendung von computerbasierten, grafikorientierten Visualisierungswerkzeugen nur teilweise kompensiert werden kann.

Nebenl"aufigkeit, in \cite{harel87} und in dieser Arbeit als Orthogonalit"at (\engl{orthogonality}) bezeichnet, umfa"st innerhalb von Statecharts die M"oglichkeit, unabh"angige Systemkomponenten durch unabh"angige Statecharts verfeinert darzustellen. Innerhalb der Verfeinerung von orthogonalen Zust"anden k"onnen, wie in Abschnitt~\ref{SubSec:Hierarchie} dargestellt, nebenl"aufige Zustands"uberg"ange stattfinden.

Broadcast Kommunikation (\engl{broadcast-communication}) erm"oglicht eine Synchronisation von Zustands"uberg"angen. Hierzu werden, wie in Abschnitt~\ref{Sec:ZuUeber} dargestellt, externe Ereignisse oder durch Aktionen generierte interne Ereignisse dem Statechart als Trigger seiner Zustands"uberg"ange global zur Verf"ugung gestellt. Das bedeutet, da"s sowohl ein intern generiertes als auch ein externes Ereignis an beliebiger Stelle innerhalb des Statecharts einen Zustands"ubergang ausl"osen kann.

In der Abbildung~\ref{Fig:StChart1Abstrkt} ist exemplarisch das Verhalten eines Fernsehger"ates ({\sl Television}) als Statechart auf oberster Abstraktionsebene in einer von der OMT Notation des dynamischen OMT Modells abweichenden, in der Literatur "ublicherweise verwendeten Darstellung gezeigt.\\

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{figure=chart1ab.eps,width=4cm}
  \end{center}
  \caption{\label{Fig:StChart1Abstrkt} {\sl Television} Statechart}
\end{figure}

In Anlehnung an das in Abschnitt~\ref{SubSec:OMTMeta} dargestellte OMT Metamodell spezifiziert ein Statechart innerhalb des dynamischen OMT Modells das Verhalten einer in einem OMT Objektmodell enthaltenen Klasse (hier: OMT Klasse {\sl Television}).

Auf der in der Abbildung~\ref{Fig:StChart1Abstrkt} wiedergegebenen Ebene der Abstraktion kann ein Objekt der Klasse {\sl Television} die Zust"ande {\sl Power\_Off} und {\sl Power\_On} einnehmen, wobei der Zustand {\sl Power\_On} nach dem Konzept der Tiefe auf einer n"achst tieferen Abstraktionsebene in einem weiteren Zustandsdiagramm verfeinert wird (vgl. Abbildung~\ref{Fig:ChartPowerOn}).

Spezifiziert ist in Abbildung~\ref{Fig:StChart1Abstrkt} das Verhalten eines Fernsehger"ates, welches sich in zwei unterschiedlichen Betriebszust"anden, ausgeschaltet (Zustand {\sl Power\_Off}) oder eingeschaltet (Zustand {\sl Power\_On}), befinden kann. Wird ein standardm"a"sig ausgeschaltetes Fernsehger"at eingeschaltet (Ereignis {\sl power}), so geht die Systemkontrolle vom Zustand {\sl Power\_Off} in den Zustand {\sl Power\_On} "uber, wobei sich die Systemkontrolle innerhalb des verfeinerten Zustands {\sl Power\_On} in weiteren Nachfahrzust"anden befindet. Eine detaillierte Darstellung der Semantik von Ausf"uhrungsschritten in Statecharts ist in Abschnitt~\ref{Sec:Ausfuehrung} enthalten.

Die Konzepte der Tiefe, Orthogonalit"at und Broadcast Kommunikation werden in den Ausf"uhrungen "uber Zust"ande und Zustandsverfeinerungen in Abschnitt~\ref{Sec:Zustand} und "uber die Semantik von Ausf"uhrungsschritten in Statecharts in Abschnitt~\ref{Sec:Ausfuehrung} vertiefend erl"autert und anhand der konkreten Implementierung der Tycoon Umgebung {\sl StatechartEnv} f"ur die statechartbasierte textuelle Tycoon Modellierung von dynamischem Systemverhalten dargestellt. Bei der Erl"auterung der Tycoon Implementierung wird insbesondere auf die Zusicherung der syntaktischen und semantischen Integrit"atsbedingungen eingegangen, die teilweise durch Typisierung und teilweise durch explizit ausprogrammierte Pr"ufungen erreicht wird.

\section{Zust"ande und Zustandsverfeinerungen}
\label{Sec:Zustand}

Nach dem in Abschnitt~\ref{Sec:ChartStruk} eingef"uhrten Konzept der Tiefe kann jeder Zustand eines Statecharts auf beliebig tief verfeinerten Abstraktionsebenen Unterzust"ande besitzen. Dabei sind unterschiedliche Arten der Verfeinerung von Zust"anden m"oglich.

In der Abbildung~\ref{Fig:ZustandsGen} sind mit Hilfe der Notation des OMT Objektmodells die Generalisierungseigenschaften von Statechart Zust"anden dargestellt. Generalisierung steht innerhalb der OMT Objektmodellierung f"ur eine Relation zwischen einer Klasse und einer oder mehrerer spezialisierter Unterklassen dieser Klasse \cite{rumb91}.\\

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{figure=zustgen.eps,width=9cm}
  \end{center}
  \caption{\label{Fig:ZustandsGen} Generalisierungseigenschaften von Zust"anden}
\end{figure}

Im Rahmen der Tycoon Repr"asentation von Statecharts ist ein Zustand als Oberklasse eines Basiszustands oder eines hierarchischen Zustands anzusehen, wobei seine Unterklassen disjunkt sind. Das bedeutet, da"s ein Objekt der Klasse Basiszustand nicht die Auspr"agung eines Objekts der Klasse Hierarchischer Zustand annehmen kann. Ebenso kann ein Objekt der Klasse Hierarchischer Zustand nicht in der Auspr"agung eines Objekts der Klasse Basiszustand auftreten. Ein hierarchischer Zustand stellt f"ur die Klassen UND-Zustand und ODER-Zustand die Oberklasse dar, wobei im Rahmen einer Aggregationsbeziehung ein UND-Zustand mindestens zwei hierarchische Zust"ande umfassen mu"s. Ein ODER-Zustand beinhaltet mindestens zwei Objekte der Klasse Zustand, die ihrerseits wiederum nach den eben erl"auterten Generalisierungseigenschaften von Zust"anden, wie in der Abbildung~\ref{Fig:ZustandsGen} dargestellt, verfeinert werden k"onnen. Ein Zustand eines ODER-Zustands ist als Defaultzustand auszuzeichnen (vgl. Defaultzustand bei der Generierung einer Tycoon Repr"asentation eines ODER-Zustands in Abschnitt~\ref{SubSec:Hierarchie}).

Der in Abbildung~\ref{Fig:StChart1Abstrkt} dargestellte {\sl Television} Statechart auf oberster Abstraktionsebene umfa"st die folgenden Zust"ande:

\begin{itemize}
  \item {\sl Power\_Off} als Basiszustand.
  \item {\sl Power\_On} als hierarchischer Zustand, wobei auf dieser Abstraktionsebene nicht zu erkennen ist, ob es sich um einen UND-Zustand oder einen ODER-Zustand handelt.
  \item {\sl Television} als hierarchischer Zustand (ODER-Zustand) mit dem Defaultzustand {\sl Power\_Off} und dem Zustand {\sl Power\_On}.
\end{itemize}

Eine Darstellung des in der Abbildung~\ref{Fig:StChart1Abstrkt} auf oberster Abstraktionsebene unverfeinert wiedergegebenen Zustands {\sl Power\_On} innerhalb des {\sl Television} Statecharts auf einem niedrigeren Abstraktionsniveau ist in der Abbildung~\ref{Fig:ChartPowerOn} enthalten.\\

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{figure=powon.eps,width=9cm}
  \end{center}
  \caption{\label{Fig:ChartPowerOn} Verfeinerter Zustand {\sl Power\_On}}
\end{figure}

Spezifiziert wird in Abbildung~\ref{Fig:ChartPowerOn} das Verhalten eines eingeschalteten Fernsehger"ates, welches sich standardm"a"sig in einer Betriebsbereitschaft (Zustand {\sl Standby}) befindet. Durch das Ausl"osen eines externen Ereignisses mit einer Fernbedienung (OMT Klasse \engl{Remote-Control}, vgl. Abschnitt~\ref{SubSec:Dynam}), z.B. durch das Dr"ucken einer Programmtaste (Ereignis {\sl progr\_button}), wird der Fernseher eingeschaltet und zeigt ein entsprechendes Bild (Zustand {\sl Image} innerhalb des verfeinerten UND-Zustands {\sl On}). Orthogonal zum Bild wird der Ton (Zustand {\sl Sound}) des betreffenden Programms eingeschaltet. Durch das Ereignis {\sl standby} wird das Fernsehger"at jederzeit, unabh"angig davon, in welchem Nachfahrzustand des Zustands {\sl On} sich die Systemkontrolle befindet, in die Betriebsbereitschaft zur"uckversetzt.

Wie eine ad"aquate Tycoon Repr"asentation dieses grafisch modellierten Statecharts innerhalb des Tycoon Systems vorgenommen werden kann, wird in den folgenden Abschnitten exemplarisch wiedergegeben. Eine detaillierte Darstellung der Tycoon Repr"asentation des in Anhang~\ref{Ann:TVstatecharts} komplett grafisch spezifizierten Anwendungsbeispiels der Fernsehersteuerung ist in Anhang~\ref{Ann:TVschnitt} aufgef"uhrt.

Innerhalb der exemplarisch betrachteten Tycoon Umgebung {\sl StatechartEnv} zur Modellierung dynamischen Systemverhaltens in einer statechartad"aquaten Tycoon Repr"asentation entspricht ein Zustand dem mit dem Datentypen {\sl Transition} wechselseitig rekursiven Datentypen {\sl State}, dessen Definition im folgenden wiedergegeben ist:

\begin{xple}
     \k{Let Rec} State $<:$\k{Ok} =
       \k{Tuple}
         label :String
         \k{var} father :optional.T(State)
         transitions :Transitions
         actionsWhenEntering :Actions
         actionsWhenLeaving :Actions
         throughoutActivities :Activities
         \k{case} basic
         \k{case} compositeAnd \k{with} children :States
         \k{case} compositeOr \k{with}
           children :States  defaultState :State
       \k{end} (* Tuple *)
     \k{and} States $<:$\k{Ok} = set.T(State)
     \k{and} Transition $<:$\k{Ok} =
       \k{Tuple}
         ...
       \k{end} (* Tuple *)
\end{xple}

Neben seiner Bezeichnung (Attribut {\sl label}) beinhaltet ein Tycoon Objekt vom Typ {\sl State} eine Menge von Transitionen zu Nachfolgezust"anden (Attribut {\sl transitions}), die beim Anlegen eines Zustands als leere Menge "ubergeben wird und bei der sp"ateren Verbindung des Zustands mit einem Nachfolgezustand um die entsprechende Transition erweitert wird. Mit dem Zustand assoziierte Eingangs-, Ausgangsaktionen und Aktivit"aten (Attribute {\sl actionsWhenEntering}, {\sl actionsWhenLeaving} und {\sl throughoutActivities}) werden bei seiner Erzeugung als Parameter "ubergeben (vgl. Abschnitt~\ref{Sec:ZuUeber}). Die Hierarchiebeziehungen zwischen einem Zustand und seinem Vorfahr werden durch das Attribut {\sl father} spezifiziert, wenn der entsprechende Vorfahrzustand generiert wird.

Basiszust"ande oder hierarchische Zust"ande stellen Auspr"agungen dieses Datentyps dar. Ein UND-Zustand ({\sl compositeAnd}) umfa"st neben den oben erl"auterten Attributen eines Basiszustands ({\sl basic}) eine Menge von orthogonalen Komponenten ({\sl children}), die ebenfalls vom Typ {\sl State} sind. Ein ODER-Zustand beinhaltet neben seinen sich gegenseitig ausschlie"senden Nachfahren einen davon ausgezeichneten Defaultzustand ({\sl defaultState}), welches derjenige Zustand ist, an den die Systemkontrolle bei einem Zustands"ubergang in diesen, den Defaultzustand umfassenden verfeinerten ODER-Zustand, "ubergeben wird. In der Abbildung~\ref{Fig:ChartPowerOn} ist z.B. dieser ausgezeichnete Defaultzustand innerhalb des ODER-Zustands {\sl Sound} der Basiszustand {\sl Sound\_On}.

Eine Erl"auterung der abstrakten Tycoon Datentypen {\sl Transition} und {\sl Action} erfolgt in Abschnitt~\ref{Sec:ZuUeber}. Aktivit"aten werden im Kontext dieser Arbeit nicht n"aher erl"autert. Die Generierung der Zust"ande in TL erfolgt \engl{bottom-up}, d.h. von den Basiszust"anden "uber hierarchische Zust"ande zum Wurzelzustand des zu spezifizierenden Systems.

\subsection{Basiszustand}
\label{SubSec:Basis}

Basiszust"ande bilden den Zustandsraum von Statecharts \cite{fricke95} und werden nicht weiter verfeinert. In der einfachsten Form besteht ein Statechart aus mindestens zwei Basiszust"anden, die wie in Abschnitt~\ref{SubSec:Hierarchie} beschrieben zu einem ODER-Zustand zusammengefa"st werden. 

Innerhalb der Tycoon Modellierungsumgebung {\sl StatechartEnv} wird ein Basiszustand mit der Funktion {\sl createBasicState} in einer Tycoon Repr"asentation angelegt:

\begin{xple}
     \k{let} createBasicState(stateLabel :String  actionsWhenEntering :Actions
                                actionsWhenLeaving :Actions
                                throughoutActivities :Activities) :State =
       \k{begin}
         \k{let} state = \k{tuple\_case} basic \k{of} State \k{with} stateLabel
           \k{var} optional.nil(:State) newTransitionSet() actionsWhenEntering
           actionsWhenLeaving throughoutActivities \k{end}
         set.insert(:State local.StateSet state)
         state
       \k{end}
\end{xple}

Der Funktion {\sl createBasicState} werden als Parameter die Bezeichnung des Zustands ({\sl stateLabel}), die Mengen von Eingangs- und Ausgangsaktionen ({\sl actionsWhenEntering}, {\sl actionsWhenLeaving}) und die Menge der mit diesem Zustand assoziierten Aktivit"aten ({\sl through\-out\-Ac\-ti\-vi\-ties}) "ubergeben. Als R"uckgabewert dieser Funktion erh"alt der Tycoon Anwendungsentwickler ein Objekt vom Typ {\sl State}, welches an einen TL Bezeichner gebunden werden kann. Desweiteren wird dieser Zustand intern in eine Zustandsmenge ({\sl local.stateSet}) eingef"ugt, um unter anderem auszuschlie"sen, da"s zwei Zust"ande mit der gleichen Bezeichnung innerhalb eines Tycoon Statecharts generiert werden. Vor dem Einf"ugen eines Zustands in diese statechartweite Zustandsmenge mit der Tycoon Funktion {\sl set.insert} wird "uberpr"uft, ob ein identischer Zustand schon in dieser Menge vorhanden ist. Falls ein identischer Zustand in der Menge {\sl local.stateSet} vorliegt, wird eine Ausnahme ausgel"ost.

Ein Beispiel f"ur eine statische Bindung eines mit der Funktion {\sl createBasicState} generierten Basiszustands {\sl Sound\_On} (vgl. Abbildung~\ref{Fig:ChartPowerOn}) an den Tycoon Bezeichner {\sl soundOn} lautet:

\begin{xple}
     \k{let} soundOn = createBasicState("{}Sound\_On"{} emptySet(:Action) emptySet(:Action)
       emptySet(:Activity))
\end{xple}

Eine komplette textuelle Tycoon Repr"asentation des in Anhang~\ref{Ann:TVstatecharts} grafisch spezifizierten {\sl Television} Statecharts ist in Anhang~\ref{Ann:TVschnitt} aufgef"uhrt. Gleiches gilt f"ur die in den folgenden Abschnitten vorgestellten Implementierungsbeispiele, die  Ausz"uge des Gesamtbeispiels in Anhang~\ref{Ann:TV} darstellen.

\subsection{Hierarchischer Zustand}
\label{SubSec:Hierarchie}

Ein hierarchischer Zustand eines Statecharts ist nach dem in Abschnitt~\ref{Sec:ChartStruk} eingef"uhrten Konzept der Tiefe rekursiv eine Dekomposition eines Zustands in einer der folgenden Formen:

\begin{itemize}
  \item UND-Dekomposition eines Zustands innerhalb von zwei oder mehreren orthogonalen Statecharts auf einer h"oheren Abstraktionsebene als UND-Zustand.
  \item ODER-Dekomposition eines Zustands (nachfolgend auch als Nachfahren oder Nachfahrzust"ande bezeichnet) innerhalb eines Statecharts auf einer h"oheren Abstraktionsebene als ODER-Zustand.
\end{itemize}

\subsubsection*{ODER-Zustand}
\label{SubSubSec:ODER}

In der Abbildung~\ref{Fig:ChartVtxt} ist der verfeinerte ODER-Zustand {\sl Videotxt} dargestellt.\\

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{figure=vtxt.eps,width=7.5cm}
  \end{center}
  \caption{\label{Fig:ChartVtxt} ODER-Zustand {\sl Videotxt}}
\end{figure}

Er umfa"st vier sich gegenseitig ausschlie"sende Basiszust"ande, welche, wie in Abschnitt~\ref{SubSec:Basis} dargestellt, nicht weiter verfeinert sind. Der Zustand {\sl Display\_Page} ist der ausgezeichnete Defaultzustand des ODER-Zustands {\sl Videotxt}. Verbunden werden die Zust"ande {\sl Display\_Page}, {\sl Get\_Hundred}, {\sl Get\_Ten}, {\sl Get\_One} und {\sl Display\_Page} durch Transitionen (vgl. Abschnitt~\ref{Sec:ZuUeber}).

Spezifiziert ist in Abbildung~\ref{Fig:ChartVtxt} das Verhalten einer Videotextsteuerung innerhalb eines Fernsehger"ates, wo per Definition beim Betreten des Videotextmodus eine Standardseite angezeigt wird (Zustand {\sl Display\_Page}) und nach dem Eingeben einer dreistelligen Seitennummer (Zust"ande {\sl Get\_Hundred}, {\sl Get\_Ten} und {\sl Get\_One}) durch das Dr"ucken der entsprechenden Programmtasten auf der Fernbedienung (Ereignis {\sl progr\_button}) die gew"ahlte Videotextseite auf dem Bildschirm dargestellt wird (Zustand {\sl Display\_Page}).

Innerhalb der Tycoon Modellierungsumgebung {\sl StatechartEnv} wird ein ODER-Zustand mit der Funktion {\sl createCompositeOrState} in einer Tycoon Repr"asentation angelegt:

\begin{xple}
     \k{let} createCompositeOrState(stateLabel :String  actionsWhenEntering :Actions
                                           actionsWhenLeaving :Actions
                                           throughoutActivities :Activities
                                           children :States  defaultState :State) :State =
       \k{if} set.size(:State children) $>$ 1
         \k{andif} set.member(:State defaultState children) \k{then}
           \k{let} state = \k{tuple\_case} compositeOr \k{of} State \k{with} stateLabel 
             \k{var} optional.nil(:State) newTransitionSet() actionsWhenEntering 
             actionsWhenLeaving throughoutActivities children defaultState \k{end}
           iter.forEach(:State set.elements(children) \k{fun}(st :State) :\k{Ok}
             \k{if} set.member(:State st local.stateSet)
               \k{andif} optional.null(st.father) \k{then}
                 st.father := optional.new(state)
             \k{else}
               \k{raise} childrenError \k{end}
             \k{end})
           set.insert(:State local.stateSet state)               
           state
       \k{else}
         \k{raise} argumentError \k{end}
       \k{end}
\end{xple}

Der Funktion {\sl createCompositeOrState} werden als Parameter die Bezeichnung des Zustands ({\sl stateLabel}), die Mengen von Eingangs- und Ausgangsaktionen ({\sl actionsWhenEntering}, {\sl actionsWhenLeaving}), die Menge der mit diesem Zustand assoziierten Aktivit"aten ({\sl through\-out\-Ac\-ti\-vi\-ties}), die Menge der Nachfahrzust"ande ({\sl children}) und ein ausgezeichneter Defaultzustand ({\sl defaultState}) "ubergeben. Enth"alt die Menge der angegebenen Nachfahrzust"ande mehr als einen Zustand und kommt der angegebene Defaultzustand in der Menge der Nachfahrzust"ande vor, so kann der ODER-Zustand durch die TL Funktion {\sl createCompositeOrState} generiert werden.

Desweiteren wird f"ur jeden angegebenen Nachfahrzustand "uberpr"uft, ob er bereits in der Menge aller Zust"ande dieses Tycoon Statecharts existiert ({\sl \k{if} set.member(:State st local.stateSet)}) und sein Attribut {\sl father} noch nicht gesetzt ist. Ist dort bereits ein Vorfahrzustand eingetragen, so wird ein Fehler ausgel"ost ({\sl \k{raise} childrenError \k{end}}), da ein Zustand im Rahmen dieser TL Implementierung stets nur innerhalb eines Vorfahren vorkommen darf. So werden z.B. "uberlappende Zust"ande \cite{harel87} ausgeschlossen. Ein erfolgreich generierter ODER-Zustand wird in das Attribut {\sl father} jedes Nachfahrzustands eingetragen, um eine feste hierarchische Ordnung zwischen Nachfahr- und Vorfahrzust"anden zu gew"ahrleisten.

Ein Beispiel f"ur eine statische Bindung eines mit der Funktion {\sl createCompositeOrState} generierten ODER-Zustands {\sl Videotxt} (vgl. Abbildung~\ref{Fig:ChartVtxt}) an den Tycoon Bezeichner {\sl videotxt} lautet (vgl. Anhang~\ref{Ann:TVschnitt}):

\begin{xple}
     \k{let} displayPage = createBasicState("{}Display\_Page"{} ...)
     \k{let} getOne = createBasicState("{}Get\_One"{} ...)

     \k{let} stateSet = emptySet(:State)
     set.insert(stateSet displayPage)
     set.insert(stateSet getOne)

     \k{let} videotxt = createCompositeOrState("{}Videotxt"{} emptySet(:Action)
       actionSet emptySet(:Activity) stateSet displayPage)
\end{xple}

\subsubsection*{UND-Zustand}
\label{SubSubSec:UND}

In der Abbildung~\ref{Fig:ChartDisplay} ist der verfeinerte UND-Zustand {\sl Display} dargestellt, welcher die beiden orthogonalen ODER-Komponenten {\sl Show\_Picture} und {\sl Show\_ProgrNr} beinhaltet.

\begin{figure}[hbt]
  \begin{center}
    \ 
    \epsfig{figure=display.eps,width=8.1cm}
  \end{center}
  \caption{\label{Fig:ChartDisplay} UND-Zustand {\sl Display}}
\end{figure}

Beide orthogonalen ODER-Komponenten umfassen jeweils zwei Basiszust"ande, welche, wie in Abschnitt~\ref{SubSec:Basis} dargestellt, nicht weiter verfeinert sind. Die Zust"ande {\sl Display\_Picture} und {\sl Display\_ProgrNr} sind die ausgezeichneten Defaultzust"ande der einzelnen ODER-Zust"ande {\sl Show\_Picture} und {\sl Show\_ProgrNr}. Zustands"uberg"ange zwischen beiden ODER-Komponenten d"urfen nicht existieren.

Spezifiziert ist in Abbildung~\ref{Fig:ChartDisplay} das Verhalten der Bildanzeige innerhalb eines Fernsehger"ates, wo per Definition beim Eintreten in den Anzeigemodus (Zustand {\sl Display}) eines Fernsehbildes sowohl das Programmbild (Zustand {\sl Display\_Picture}) als auch die Programmnummer (Zustand {\sl Display\_ProgrNr}) dargestellt wird. Die Systemkontrolle innerhalb einer ODER-Komponente verh"alt sich dabei unabh"angig von der Systemkontrolle innerhalb des dazu orthogonalen ODER-Zustands. Das bedeutet, da"s sich die Anzeige eines Programmbildes unabh"angig von der Anzeige der entsprechenden Programmnummer innerhalb des Anzeigemodus verh"alt.

Innerhalb der Tycoon Modellierungsumgebung {\sl StatechartEnv} wird ein UND-Zustand mit der Funktion {\sl createCompositeAndState} in einer Tycoon Repr"asentation angelegt, wobei "ahnliche Pr"ufoperationen wie in der TL Funktion {\sl createCompositeOrState} realisiert sind:

\begin{xple}
     \k{let} createCompositeAndState(stateLabel :String  actionsWhenEntering :Actions
                                             actionsWhenLeaving :Actions
                                             throughoutActivities :Activities
                                             children :States) :State =
       \k{if} set.size(:State children) $>$ 1 \k{then}
         \k{let} state = \k{tuple\_case} compositeAnd \k{of} State \k{with} stateLabel
           \k{var} optional.nil(:State) newTransitionSet() actionsWhenEntering
           actionsWhenLeaving throughoutActivities children \k{end}
         iter.forEach(:State set.elements(children) \k{fun}(st :State) :\k{Ok}
           \k{if} set.member(:State st local.stateSet)
             \k{andif} optional.null(st.father) \k{then}
               st.father := optional.new(state)
           \k{else}
             \k{raise} childrenError \k{end}
           \k{end})
         set.insert(:State local.stateSet state)          
         state
       \k{else}
         \k{raise} childrenError \k{end}
       \k{end}
\end{xple}

Ein Beispiel f"ur eine statische Bindung eines mit der Funktion {\sl createCompositeAndState} generierten UND-Zustands {\sl Display} (vgl. Abbildung~\ref{Fig:ChartDisplay}) an den Tycoon Bezeichner {\sl display} lautet (vgl. Anhang~\ref{Ann:TVschnitt}):

\begin{xple}
     \k{let} displayPicture = createBasicState("{}Display\_Picture"{} ...)
     \k{let} hideProgrNr = createBasicState("{}Hide\_ProgrNr"{} ...)
     ...

     \k{let} showPicture = createCompositeOrState("{}Show\_Picture"{} ...)
     \k{let} showProgrNr = createCompositeOrState("{}Show\_ProgrNr"{} ...)

     \k{let} stateSet = emptySet(:State)
     set.insert(stateSet showPicture)
     set.insert(stateSet showProgrNr)

     \k{let} display = createCompositeAndState("{}Display"{} emptySet(:Action)
       emptySet(:Action) emptySet(:Activity) stateSet)
\end{xple}

\subsubsection*{Wurzelzustand}
\label{SubSubSec:Wurzel}

Abgeschlossen wird die Spezifikation eines Statecharts mit einem ausgezeichneten Vorfahrzustand, dem sogenannten Wurzelzustand, der "uber alle Verfeinerungsebenen hinweg der oberste Vorfahr aller in diesem Statechart enthaltenen Zust"ande ist.

Die TL Implementierung zur Generierung eines Wurzelzustandes innerhalb der {\sl State\-chart\-Env} Umgebung zur Modellierung dynamischen Systemverhaltens (hier: Wurzelzustand {\sl Television} aus der Abbildung~\ref{Fig:StChart1Abstrkt}) folgt der Implementierung der oben dargestellten Funktion {\sl createCompositeOrState}, mit dem Unterschied, da"s die Funktion {\sl createRootState} den so erzeugten Zustand als Wurzelzustand des Statecharts intern kennzeichnet.

Ein Beispiel f"ur eine statische Bindung eines mit der Funktion {\sl createRootState} generierten UND-Zustands {\sl Television} an den Tycoon Bezeichner {\sl television} lautet (vgl. Anhang~\ref{Ann:TVschnitt}):

\begin{xple}
     \k{let} powerOff = createBasicState("{}Power\_Off"{} ...)
     \k{let} powerOn = createCompositeOrState("{}Power\_On"{} ...)

     \k{let} stateSet = emptySet(:State)
     set.insert(stateSet powerOff)
     set.insert(stateSet powerOn)

     \k{let} television = createRootState("{}Television"{} emptySet(:Action)
       emptySet(:Action) emptySet(:Activity) stateSet powerOff)
\end{xple}

Die Generierung von mehr als einem Wurzelzustand innerhalb eines Tycoon Statecharts darf nicht erfolgen und wird daher mit dem Ausl"osen einer Ausnahme abgebrochen.

\input{modell2}
