Die Systemanalyse ist eine der kritischsten Phasen einer Systementwicklung. Für Realzeitsysteme waren Methoden wie "Structured Analysis" nur beschränkt erfolgreich. Die Gründe dafür und eine Lösung beschreibt Peter Hruschka von der GEI, Aachen, in diesem Artikel. Auf der Basis von "Structured Analysis" stellt der Autor eine Methode vor, die adäquate Modellierungshilfsmittel für die Analyse von Realzeitsystemen zur Verfügung stellt.

Die Stärke der "Structured Analysis" liegt vor allem darin, daß sie dem Systemanalytiker dabei hilft, systematisch zu arbeiten, leicht verständliche Modelle zu erstellen, auf Vollständigkeit zu achten, die Konsistenz prüfen zu können und die entstehenden Modelle leicht ändern und pflegen zu können.

Für eine spezielle Gruppe von Anwendungen ergibt sich gegenüber den "normalen" Applikationen ein zusätzlicher Bedarf: Nicht nur Daten und Funktionen sind wesentlich. Oftmals wird die Analyse auch durch weitere Faktoren getrieben, zumindest erheblich beeinflußt oder erleichtert.

Wichtige Zustände im Übergangsdiagramm

In vielen Realzeitsystemen sind die Steuerungs- oder Kontrollaspekte und die Zeitanforderungen mindestens genauso wichtig wie die Anforderungen an die Verarbeitung der Daten.

Von den vielen Charakteristika, die Realzeitsysteme von Nicht-Realzeitsystemen unterscheiden, sollen zwei hervorgehoben werden. Erstens findet man in Realzeitsystemen mindestens zwei Arten von Informationen, die analysiert werden müssen: Daten, wie sie auch in kommerziellen Systemen auftreten und Kontrollsignale, die hauptsächlich dazu benutzt werden, um bestimmte Reaktionen des Systems hervorzurufen. Zweitens sind Realzeitsysteme häufig auch dadurch charakterisiert, daß die Aktionen (Funktionen) nicht nur von den Informationen abhängen sondern auch davon, in welchem Zustand sich das System befindet.

Für diese Art von Problemstellungen gibt es ein in vielen Ingenieurdisziplinen anerkanntes und beliebtes Hilfsmittel: Zustandsübergangsdiagramme.

Zustandsübergangsdiagramme erlauben es, die wichtigsten Zustände eines Systems und ihre Übergänge (beziehungsweise die auslösenden Ereignisse für einen Zustandswechsel) grafisch darzustellen. Als Notation werden häufig Rechtecke für die Zustände und beschriftete Pfeile für die Übergänge benutzt.

Beim Erstellen dieser Zustandsübergangsdiagramme soll man sich bemühen, nur relevante Systemzustände zu modellieren, das heißt im Regelfall solche, die auch nach außen sichtbare Wirkung zeigen. Ansonsten ist die Gefahr groß, in normale Ablaufdiagramme (Flußdiagramme) zu verfallen und zu sehr in programmiersprachennahe Sequentialisierung zu geraten.

Wenn diese Zustandsübergangsdiagramme auch zur Klarheit in einem bestimmten Bereich der Problemdefinition beitragen können, so reichen sie alleine doch nicht aus, um alle Anforderungen eines Realzeitsystems vollständig zu erfassen. Wendet man nun verschiedene Mechanismen wie Datenflußdiagramme und Zustandsübergangsdiagramme zusammen an, so erhebt sich die Frage, wie man dennoch die anfangs angeführten Ziele (vor allem die Konsistenz des Gesamtmodells) erreichen kann.

Eine der Grundideen für die Erweiterung von Structured Analysis ist ein altbekanntes Ingenieursprinzip: Man sollte zuerst den Prozeß kennen, um zu wissen, was man steuert.

Der Prozeß wird durch eine Hierarchie von Datenflußdiagrammen und durch die dazugehörigen Mini-Spezifikationen dargestellt. Die Datenflußdiagramme zeigen, wie das System logisch in Teilsysteme zerlegt ist und wie zwischen diesen Teilsystemen die Datenflüsse ausgetauscht werden. Die Mini-Spezifikationen erläutern, wie die Eingangsdaten eines Teilsystems in die Ausgangsdaten transformiert werden.

Für die Prozeßsteuerung gibt es zwei ähnliche Darstellungsmittel: Kontrollflußdiagramme und Kontrollspezifikationen. Die Kontrollflußdiagramme zeigen wieder die Zerlegung des Systems und die Kontrollflüsse zwischen den einzelnen Teilsystemen. Die Kontrollspezifikationen erläutern, wie die Teilsysteme eines Diagramms durch die Kontrollflüsse gesteuert werden.

Nach dem oben erwähnten Grundprinzip verwendet man identische

Teilsysteme in den Datenfluß- und Kontrollflußdiagrammen, das heißt, die Kreise (die Funktionen, Teilaufgaben) werden in den beiden Diagrammen eingezeichnet. Die ersteren zeigen jedoch den Datenfluß keine formale Unterscheidung zwischen Datenfluß und Kontrollfluß, aber die meisten Systemanalytiker haben eine intuitive Einstellung dazu. Als Faustregel zur Unterscheidung zwischen Kontroll- und Datenfluß kann die Prüfung der Datenverwendung dienen: Wird eine Information verarbeitet (im Sinne einer mathematischen Funktion), so hat sie den Charakter eines Datenflusses. Dient die Information zur Steuerung des Systems, ist sie ein Kontrollfluß. Wird sie zu beidem verwendet, so kann man Flüsse auch in beiden Diagrammen verwenden. Als Beispiel für eine zweifache Verwendung sei ein parametrisiertes Kommando eines Betriebssystems erwähnt: Die Parameter werden als Daten ausgewertet, das Kommando selbst führt zur Auslösung einer Aktion.

Die Kontrollflußdiagramme zeigen auf der Kontextebene, welche Signale von außen in das System fließen und welche Signale vom System abgegeben werden. In den weiteren Verfeinerungen sieht man dann, wohin diese Signale weitergeleitet werden. Aus den Diagrammen kann man nicht entnehmen, wozu diese Signale verwendet werden.

Signalweg wird sichtbar

Die eigentliche Verarbeitung der Signale wird in den Kontrollspezifikationen beschrieben. Darin wird festgelegt, welche Wirkung die Kontrollsignale haben. Üblicherweise lösen sie einen Übergang von einem Zustand in einen anderen aus, oder sie werden zusammen mit anderen Signalen in (manchmal äußerst komplizierten) logischen Ausdrücken ausgewertet, um daraus neue interne Signale zu erzeugen, die in anderen Teilen des Systems oder in der Systemumgebung gebraucht werden.

Zur Darstellung dieser Kontrollspezifikationen kann man nun verschiedene Ausdrucksmittel benutzen, beispielsweise Zustandsübergangsdiagramme, Entscheidungstabellen oder auch einfache informelle Beschreibungen, wie die Steuerung auf dieser Ebene funktioniert.

Wenn die Verarbeitungslogik einer Ebene sehr kompliziert ist, kann man auch Kombinationen von Zustandsübergangsdiagrammen und informellen Beschreibungen benutzen. So kann zum Beispiel zunächst durch logische Verknüpfung von mehreren Signalen ein neues Signal erzeugt werden, das anschließend als Ereignis in einem Zustandsübergangsdiagramm verwendet wird.

Der wesentliche Vorteil in der Erweiterung von Structured Analysis für Realzeitsysteme liegt darin, daß nun das komplette Regelwerk auf die Erweiterungen übernommen werden kann.

Alle Konsistenzregeln, die für Datenflußdiagramme, Mini-Specs und das Data Dictionary gelten, können nun sinngemäß auf Kontrollflußdiagramme und Kontroll-Specs angewendet werden.

Literatur:

Tom DeMarco, Structured Analysis and System Specification, Yourdon Press, New York, 1979;

P. Hruschka, Ein Projektmodell und Werkzeuge zu dessen Unterstützung, Informatik Fachberichte Nr. 50, Seite 433 ff., Springer Verlag, 1981

Derek J, Hatley, The Use of Structured Methods in the Development of Large Software-Based Avionic Systems, Proceedings DASC, Baltimore, Dec. 1984;

Imtiaz Phirbui, Structured Methods Standard, Boeing Inhouse Document, Aug. 1985.