DE19837871A1

DE19837871A1 - Verfahren zum automatischen Erzeugen eines Programms

Info

Publication number: DE19837871A1
Application number: DE19837871A
Authority: DE
Inventors: Manfred Broy; Radu Grosu; Ingolf Krueger
Original assignee: Individual
Current assignee: Individual
Priority date: 1998-08-20
Filing date: 1998-08-20
Publication date: 2000-03-02
Anticipated expiration: 2018-08-21
Also published as: US6405361B1; DE19837871C2

Abstract

Ein Verfahren zum automatischen Erzeugen eines zustandsbasierten Programms (14A, 14B, 14C) für eine Komponente (A, B, C) eines aus mehreren miteinander kommunizierenden Komponenten (A, B, C) bestehenden Systems (S) weist die Schritte auf, alle durch die Spezifikation (10) des Systems (S) definierten Ablaufbeschreibungen der Komponente (A, B, C) zu bestimmen, die Ablaufbeschreibungen zu normalisieren, eine zustandsbasierten Spezifikation der Komponente (A, B, C) zu bestimmen, und das zustandsbasierte Programm (14A, 14B, 14C) zu bestimmen. Durch die Erfindung wird der Programmentwicklungsprozeß verkürzt, der erforderliche Aufwand verringert, und mögliche Fehlerquellen werden vermieden.

Description

Die Erfindung betrifft ein Verfahren zum automatischen Er zeugen eines zustandsbasierten Programms. Das Programm ist für eine Komponente eines aus mehreren miteinander kommuni zierenden Komponenten bestehenden Systems vorgesehen. Eine interaktionsbasierte Spezifikation des Systems bildet die Grundlage für die automatische Programmerzeugung. Die Erfin dung dient zum automatischen Erzeugen aller Arten von Pro grammen. Insbesondere ist ein Einsatz der Erfindung bei kom plexen, interagierenden Programmen, zum Beispiel für Tele kommunikationsanwendungen, vorgesehen.

Die Programmentwicklung erfolgt heute im allgemeinen in ei nem mehrphasigen Prozeß. Zunächst werden die Anforderungen an das zu entwickelnde System gesammelt und erste Lösungsan sätze erstellt. Später werden diese Lösungsansätze schritt weise ausgearbeitet, bis schließlich eine ausführbare Imple mentierung in Form eines Programms vorliegt.

Zur Spezifikation eines Systems kommunizierender Komponenten in den frühen Entwurfsphasen sind insbesondere interaktions basierte Formalismen bekannt. Eine Spezifikation in einem solchen Formalismus enthält Beschreibungen von möglichen Ab läufen des Systems, wobei die Kommunikation (Interaktion) zwischen den Systemkomponenten im Vordergrund steht. Bei spiele für interaktionsbasierte Ablaufbeschreibungen sind Message Sequence Charts (MSCs) nach der Empfehlung Z.120 der ITU (International Telecommunication Union) sowie Sequenz diagramme in der UML (Unified Modeling Language) der OMG (Object Management Group).

Wenn aus einer derartigen interaktionsbasierten Spezifika tion des Systems ohne maschinelle Unterstützung ein lauffä higes Programm entwickelt werden soll, ist ein sehr hoher Einsatz an menschlicher Arbeitszeit erforderlich. Problema tisch sind hierbei sowohl die entstehenden Kosten als auch die lange Entwicklungsdauer, die sich auch durch eine Erhö hung der Mitarbeiterzahl nicht beliebig verkürzen läßt. Ins besondere bei komplexen, interagierenden Anwendungen, wie sie beispielsweise auf dem Telekommunikationssektor üblich sind, ist der Entwicklungsprozeß ferner sehr fehleranfällig. Ein Großteil der Gesamtkosten entfällt in der Regel auf die Fehlersuche und -beseitigung.

Die Erfindung hat demgemäß die Aufgabe, den Programmentwick lungsprozeß zu verkürzen, den erforderlichen Aufwand zu ver ringern und mögliche Fehlerquellen zu vermeiden. Insbesonde re sollen durch die Erfindung die Phasen der Programment wicklung von der interaktionsbasierten Systemspezifikation zum ausführbaren Programm ganz oder zum Teil automatisiert werden.

Erfindungsgemäß wird diese Aufgabe durch ein Verfahren mit den Merkmalen des Anspruchs 1 gelöst. Die abhängigen An sprüche betreffen bevorzugte Ausgestaltungen der Erfindung. Durch die Aufzählung der Verfahrensschritte in Anspruch 1 soll keine festgelegte Reihenfolge definiert werden; viel mehr können die einzelnen Schritte auch in anderer Reihen folge oder (quasi-)parallel oder ineinander oder mit Schrit ten anderer Verfahren verzahnt ausgeführt werden. Die Ver wendung des unbestimmten Artikels im Ausdruck "Verfahren zum automatischen Erzeugen eines zustandsbasierten Programms" soll den Ball einschließen, daß in einem einzigen Verfah rensablauf gemeinsam mehrere zustandsbasierte Programme für je eine Komponente des Systems erzeugt werden.

Die Erfindung geht von der Grundidee aus, durch eine Reihe geeigneter Umsetzungsschritte automatisch ein zustandsba siertes Programm aus der Spezifikation des Systems zu erzeu gen. Damit erleichtert die Erfindung den Entwurfsprozeß ganz wesentlich, weil die aufwendige, manuelle Umsetzung ent fällt. Die Programmierarbeit wird auf das Erstellen der Spe zifikation des Systems verlagert. Mit anderen Worten erwei tert die Erfindung die Funktionalität bekannter Compiler, weil die automatische Programmgenerierung nicht mehr einen Sourcecode in einer Programmiersprache erfordert, sondern eine bloße Systemspezifikation ausreicht.

Die Erfindung geht von einer Spezifikation eines aus mehre ren miteinander kommunizierenden Komponenten bestehenden Sy stems aus. Die Komponenten können insbesondere räumlich von einander getrennte Datenverarbeitungseinrichtungen sein, wie dies zum Beispiel bei Telekommunikationsanwendungen häufig der Fall ist. Die Komponenten können jedoch auch lediglich logisch voneinander getrennt sein, um beispielsweise das Sy stem zu gliedern oder die Komponenten untereinander abzu schotten. Die Komponenten können in diesem Fall nebenläufige Prozesse in einer Datenverarbeitungsanlage oder sogar ein zelne Module eines größeren Programms sein. Auch Mischformen zwischen den beiden Extremen einer räumlichen und logischen Trennung sind vorgesehen.

Die Kommunikation zwischen den Komponenten ist auf alle Ar ten möglich, zum Beispiel über uni- oder bidirektionale Kom munikationskanäle oder synchronisierende Kommunikationsme chanismen. Die Kommunikation kann über beliebige Protokolle abgewickelt werden. Insbesondere können die Komponenten durch Netzwerke oder geeignete Betriebssystemdienste mitein ander verbunden sein. Auch eine Kommunikation über gemeinsa me Register oder Speicherbereiche ist möglich.

Die Spezifikation des Systems enthält erfindungsgemäß inter aktionsbasierte Ablaufbeschreibungen. Solche Ablaufbeschrei bungen sind zum Beispiel die eingangs bereits erwähnten Message Sequence Charts (MSCs) oder UML-Sequenzdiagramme. Für das erfindungsgemäße Verfahren ist nur der Informations gehalt dieser Beschreibungen hinsichtlich möglicher System abläufe von Bedeutung; die konkrete textuelle und/oder gra fische Repräsentation ist unerheblich. Daher können als Sy stemspezifikationen alle Beschreibungstechniken eingesetzt werden, in denen Systemkomponenten und deren Interaktion darstellbar sind.

Als Ergebnis des erfindungsgemäßen Verfahrens wird ein zu standsbasiertes Programm für je eine Komponente des Systems generiert. Dieses Programm kann ebenfalls eine beliebige textuelle und/oder grafische Repräsentation aufweisen. We sentlich ist nur, daß durch das Programm Zustände und Zu standsübergänge sowie Kommunikationsaktionen beschrieben werden.

In bevorzugten Ausführungsformen wird das zustandsbasierte Programm durch einen endlichen Automaten (gerichteter Graph mit Anfangszustand und akzeptierenden Endzuständen) oder einen Büchi-Automaten (gerichteter Graph mit Anfangszustand und Akzeptanzkriterium) oder eine SDL-Darstellung (SDL = Specification and Description Language der ITU) oder einen Statechart-Automaten oder einen ROOM-Automaten (ROOM = Real- Time Object-Orientated-Modeling) repräsentiert.

Hinsichtlich endlicher Automaten wird allgemein auf das Buch "Einführung in die Automatentheorie, Formale Sprachen und Komplexitätstheorie" von J. E. Hopcroft und J. D. Ullman, Addison Wesley, 2. korrigierter Nachdruck, 1993, verwiesen. Insbesondere sind auf den Seiten 47ff dieses Buches Verfah ren zur Ableitung ausführbarer Programme aus Automatenbe schreibungen gezeigt. Das Buch "Real-Time Object-Orientated Modeling" von B. Selic, G. Gullekson und P. T. Ward, Wiley, 1994, enthält eine Beschreibung von ROOM-Automaten sowie von Werkzeugen wie z. B. ObjecTime (http://www.objectime.com), die Automatenbeschreibungen auszuführen und in andere Pro gramme umzuformen vermögen. Die an diesen Fundstellen ent haltenen Erläuterungen werden hiermit in die vorliegende Be schreibung aufgenommen.

In anderen bevorzugten Ausführungsformen sind beliebige an dere zustandsorientierte Formalismen und Sprachen für das zustandsbasierte Programm möglich. Das zustandsbasierte Pro gramm ist vorzugsweise ein ausführbares Programm. Es kann unmittelbar auf einem Rechner lauffähig sein, oder es kann mittels eines geeigneten Interpreters ausführbar oder mit tels eines geeigneten Compilers in einen ausführbaren Kode übersetzbar sein. In Ausführungsalternativen können zusätz liche manuelle Verfeinerungsschritte erforderlich sein, um ein ausführbares Programm zu erhalten.

Bevorzugte Anwendungsgebiete der Erfindung finden sich auf den Gebieten der Telekommunikation und der Computernetzwer ke, insbesondere bei der Implementierung komplexer Protokol le für alle Arten von Vermittlungsanlagen, Zwischenstationen und Endgeräten, um einen flexiblen und gegen Fehlfunktionen abgesicherten Daten- und Nachrichtenaustausch bereitzustel len. Ferner ist die Erfindung zum Erzeugen von Programmen für reaktive Systeme, insbesondere Regelungs- und Steue rungssysteme als Bestandteile technischer Geräte (etwa im Anlagenbau, in der Automatisierungstechnik, in der Avionik, im KFZ-Bereich, in der Telematik und/oder in der Konsumelek tronik) einsetzbar. Weitere Anwendungsgebiete sind die Gene rierung von Benutzerschnittstellen, insbesondere für Geräte der genannten technischen Bereiche, sowie die Erzeugung von Datenbankabfrageschemata.

Mehrere Ausführungsbeispiele und -alternativen der Erfindung werden nun unter Hinweis auf die Zeichnungen genauer be schrieben. Es stellen dar:

Fig. 1 eine schematische Darstellung der automatischen Pro grammerzeugung durch das erfindungsgemäße Verfahren,

Fig. 2a bis Fig. 2d Beispiele für interaktionsbasierte Ab laufbeschreibungen,

Fig. 3 ein Beispiel für eine Spezifikation eines Systems,

Fig. 4 ein Flußdiagramm eines Ausführungsbeispiels der Er findung,

Fig. 5 eine Ablaufbeschreibung einer Komponente A,

Fig. 6 eine Ablaufbeschreibung der Komponente A mit einge fügter Start- und Endbedingung,

Fig. 7a und Fig. 7b je eine normalisierte Ablaufbeschreibung der Komponente A,

Fig. 8 eine zustandsbasierte Spezifikation der Komponente A,

Fig. 9 ein nichtdeterministisches, zustandsbasiertes Pro gramm für die Komponente A,

Fig. 10 ein deterministisches, zustandsbasiertes Programm für die Komponente A, und

Fig. 11a und Fig. 11b Darstellungen von optimierbaren bzw. optimierten Zustandsübergängen.

Das in Fig. 1 veranschaulichte Verfahren betrifft ein System S, das drei als eigenständige Computer ausgestaltete Kompo nenten A, B, C aufweist. Die Komponenten A, B, C kommunizie ren miteinander über unidirektionale Kanäle (in Fig. 1 als durchgezogene Pfeile gezeigt), die durch geeignete Netzwerk dienste bereitgestellt werden. Eine Spezifikation 10 des Sy stems S beschreibt die möglichen Kommunikationsabläufe (In teraktionen) zwischen den Komponenten A, B, C.

Die Spezifikation 10 dient als Eingabe (gepunkteter Pfeil in Fig. 1) für einen Rechner 12, beispielsweise einen üblichen Arbeitsplatzrechner, der das hier beschriebene Verfahren automatisch ausführt. Als Ausgaben (gestrichelte Pfeile in Fig. 1) erzeugt der Rechner 12 je ein zustandsbasiertes Pro gramm 14A, 14B, 14C für die drei Komponenten A, B, C. Die Programme 14A, 14B, 14C sind auf den mit einem geeigneten Interpreter ausgestatteten Komponenten A, B, C unmittelbar ablauffähig. Je nach einer Auswahl des Benutzers können in jedem Durchlauf Programme 14A, 14B, 14C für alle Komponenten A, B, C des Systems S oder für nur eine oder einige dieser Komponenten A, B, C erzeugt werden.

Die Spezifikation 10 des Systems S weist mehrere inter aktionsbasierte Ablaufbeschreibungen auf, die in dem hier gezeigten Ausführungsbeispiel als Message Sequence Charts (MSCs) nach der Empfehlung Z.120 der ITU ausgestaltet sind. Der Inhalt dieser Empfehlung wird hiermit in die vorliegende Beschreibung aufgenommen. Vier MSCs für die Komponenten A und B sind beispielhaft in Fig. 2a bis Fig. 2d gezeigt und dort mit den Namen ISS, A_ISF, A_TC bzw. A_TE bezeichnet. Bei den MSCs A_ISF, A_TC bzw. A_TE sind die jeweiligen Kom munikationspartner der Komponente A der Einfachheit halber weggelassen worden.

Jede Komponente in einer Ablaufbeschreibung ist durch eine senkrechte Achse repräsentiert, die von einem offenen Balken als Startpunkt zu einem geschlossenen Balken als Endpunkt verläuft. Kommunikationsaktionen zwischen den Komponenten sind durch beschriftete Pfeile vom Sender zum Empfänger dar gestellt. Die Beschriftung kennzeichnet die Art der Nach richt. Beispielsweise sendet in Fig. 2a die Komponente A die Nachricht SREQ an die Komponente B, die nach dem Empfang ih rerseits die Nachricht SACK an die Komponente A schickt.

Ferner können mit den Komponenten Bedingungen assoziiert sein. Eine Bedingung kennzeichnet den Zustand der entspre chenden Komponente zu dem durch die Position der Bedingung auf der Komponentenachse angegebenen Zeitpunkt vor oder nach dem Senden bzw. Empfangen einer Nachricht. So gilt in Fig. 2a für die Komponente A vor dem Senden der Nachricht SREQ die Bedingung IDLE als Anfangsbedingung und nach dem Empfang der Nachricht SACK die Bedingung SENDING als End bedingung.

In Fig. 3 ist die Spezifikation 10 des Systems S veranschau licht. Im hier beschriebenen Ausführungsbeispiel enthält die Spezifikation 10 insgesamt vier Ablaufbeschreibungen 16 des Systems S, nämlich die MSCs ISS, A_ISF, A_TC und A_TE (wie in Fig. 2a bis Fig. 2d gezeigt). Ferner sind in der Spezifi kation 10 Daten 18 über den Anfangszustand und Daten 20 über die möglichen Endzustände jeder Komponente enthalten, die in mindestens einer der Ablaufbeschreibungen 16 auftritt. Die Daten 18 legen den Startzustand des zu erzeugenden zustands basierten Programms für die Komponente fest, und die Daten 20 bestimmen die zulässigen (akzeptierenden) Endzustände. In Ausführungsalternativen kann die Spezifikation 10 weitere Daten aufweisen, die für die Programmgenerierung herangezo gen werden.

Anhand des im Flußdiagramm von Fig. 4 gezeigten Verfahrens wird nun die Erzeugung eines zustandsbasierten Programms für die Komponente A erläutert. In einem ersten Schritt 22 wird für jede Ablaufbeschreibung 16 des Systems S, in der die Komponente A enthalten ist, eine auf diese Komponente be schränkte Ablaufbeschreibung erzeugt. Mit anderen Worten stellt die erzeugte Komponenten-Ablaufbeschreibung die Pro jektion der System-Ablaufbeschreibung 16 auf die Komponente A dar. Diese Projektion entsteht durch Entfernen aller von A verschiedenen Komponentenachsen zusammen mit den daran be findlichen Bedingungen, soweit diese Bedingungen nicht auch Bedingungen der Komponente A sind. Ferner werden alle Pfeile (Kommunikationsvorgänge) entfernt, die weder ihren Ursprung noch ihr Ziel bei der Komponente A haben.

Fig. 5 zeigt als Beispiel für den Verfahrensschritt 22 das MSC A_ISS, das eine aus der System-Ablaufbeschreibung ISS (Fig. 2a) gewonnene Ablaufbeschreibung der Komponente A dar stellt. Das MSC A_ISS wurde durch Projektion des MSC ISS auf die Komponente A gewonnen, indem die Komponentenachse B ent fernt wurde. Die MSCs von Fig. 2b bis Fig. 2d haben bereits die Form einer Ablaufbeschreibung der Komponente A, so daß insoweit keine Umwandlungsschritte mehr erforderlich sind.

In einem zweiten Schritt 24 (Fig. 4) wird jede nun vorlie gende Ablaufbeschreibung der Komponente A normalisiert. Eine normalisierte Ablaufbeschreibung weist genau eine Anfangs- und genau eine Endbedingung auf und enthält zwischen diesen beiden Bedingungen ausschließlich Kommunikationsaktionen. Als Anfangsbedingung wird hierbei eine unmittelbar auf den Startpunkt (offener Balken) einer Komponentenachse folgende Bedingung verstanden, und als Endbedingung eine dem Endpunkt (geschlossener Balken) unmittelbar vorhergehende Bedingung.

Der Normalisierungsschritt 24 wird in drei Teilschritten ausgeführt. In einem ersten Teilschritt 26 wird in jede Ab laufbeschreibung der Komponente A, die nicht mit einer Be dingung beginnt, eine Startbedingung eingefügt. Die Start bedingung entspricht dem durch die Daten 18 vorgegebenen Anfangszustand für die Komponente A.

Daraufhin wird in einem zweiten Teilschritt 28 in jede Ab laufbeschreibung, die nicht mit einer Bedingung endet, eine geeignete Endbedingung eingefügt. Im hier beschriebenen Aus führungsbeispiel ist die eingefügte Endbedingung identisch mit der (bereits ursprünglich vorhandenen oder in Teil schritt 26 eingefügten) Startbedingung der Ablaufbeschrei bung. In Ausführungsalternativen sind andere Endbedingungen möglich. In weiteren Ausführungsalternativen können in den Teilschritten 26 und 28 aus einer einzigen Ablaufbeschrei bung mehrere Ablaufbeschreibungen generiert werden, die sich nur durch die eingefügten Anfangs- und/oder Endbedingung(en) unterscheiden.

Fig. 6 zeigt als Beispiel ein aus dem MSC A_ISF (Fig. 2b) durch Ausführen der ersten beiden Teilschritte 26, 28 er haltenes MSC A_ISF1. Die durch die Daten 18 (Fig. 3) für die Komponente A definierte Bedingung IDLE wurde als Start- und als Endbedingung eingefügt. Die MSCs A_ISS (Fig. 5) und A_TC (Fig. 2c) und A_TE (Fig. 2d) weisen bereits je eine Start- und Endbedingung auf, so daß insoweit keine Umformung erfor derlich ist.

Als dritter Teilschritt 30 des Normalisierungsschritts 24 werden Ablaufbeschreibungen aufgespalten- die außer der Start- und der Endbedingung weitere Bedingungen aufweisen. Jeder Ausschnitt einer solchen Ablaufbeschreibung, der von je zwei Bedingungen begrenzt wird, bildet eine neue Ablauf beschreibung mit diesen beiden Bedingungen als Start- bzw. Endbedingung. In den so erhaltenen normalisierten Ablaufbe schreibungen tritt somit jede ursprünglich interne Bedingung je einmal als Start- und einmal als Endbedingung auf.

Das Ergebnis der im dritten Teilschritt 30 vorgenommenen Aufspaltung am Beispiel des MSC A_ISF1 (Fig. 6) ist in Fig. 7a und Fig. 7b gezeigt. Das MSC A_ISF2 entspricht dem Ausschnitt des MSC A_ISF1 von der Startbedingung IDLE zur internen Bedingung (und neuen Endbedingung) CONFL. Der Aus schnitt des MSC A_ISF1 von CONFL zur Endbedingung IDLE bil det das MSC A_ISF3. Die MSCs A_ISF2 und A_ISF3 sind somit aus dem MSC A_ISF durch Normalisierung entstanden. Die MSCs A_ISS, A_TC und A_TE liegen bereits in Normalform vor, so daß in Teilschritt 30 keine Aufspaltung erfolgt.

Als dritter Verfahrensschritt 32 wird aus den normalisierten Ablaufbeschreibungen der Komponente A eine zustandsbasierte Spezifikation bestimmt. Eine solche Spezifikation ist eine Mischform aus Ablaufbeschreibungen und zustandsbasierten Programmen. Das heißt, daß bereits ein Zustandsbegriff exi stiert, während Zustandsübergänge noch durch Ablaufbeschrei bungen repräsentiert werden.

Um die Zustandsmenge der zustandsbasierten Spezifikation der Komponente A zu erhalten, wird im hier beschriebenen Ausfüh rungsbeispiel die Menge der normalisierten Ablaufbeschrei bungen von A so partitioniert, daß alle Ablaufbeschreibungen einer Partition dieselbe Anfangsbedingung aufweisen. Jede solche Partition, die im folgenden einfach mit der entspre chenden Anfangsbedingung identifiziert wird, stellt einen Zustand der zustandsbasierten Spezifikation dar. Ferner bil det jede in einer normalisierten Ablaufbeschreibung von A auftretende Endbedingung einen Zustand, sofern nicht bereits ein entsprechender Zustand vorhanden ist. Mit anderen Worten kann somit die Zustandsmenge als Menge aller Anfangs- und Endbedingungen in den normalisierten Ablaufbeschreibungen von A angesehen werden, wobei gleiche Bedingungen je einen gemeinsamen Zustand bilden.

Als Zustandsübergänge (Transitionen) in der zustandsbasier ten Spezifikation dienen alle normalisierten Ablaufbeschrei bungen von A. Jede solche Ablaufbeschreibung definiert eine mögliche Transition von dem der Startbedingung entsprechen den Zustand zu demjenigen Zustand, der der Endbedingung zu geordnet ist. Der Anfangszustand der zustandsbasierten Spe zifikation der Komponente A ist der durch die Daten 18 (Fig. 3) angegebene Anfangszustand, und die durch die Daten 20 definierten Endzustände entsprechen den Endzuständen der zustandsbasierten Spezifikation.

Eine aus den MSCs A_ISS, A_ISF2, A_ISF3, A_TC und A_TE in Schritt 32 abgeleitete zustandsbasierte Spezifikation ist beispielhaft in Fig. 8 gezeigt. Die Partition für die An fangsbedingung IDLE enthält die MSCs A_ISS und A_ISF2, die Partition für die Anfangsbedingung SENDING enthält die MSCs A_TC und A_TE, und die Partition für die Anfangsbedingung CONFL enthält das MSC A_ISF3. Entsprechend werden drei Zu stände gebildet, die mit den Anfangsbedingungen IDLE, SENDING und CONFL identifiziert werden. Die in Fig. 8 durch Pfeile dargestellten Transitionen sind mit den entsprechen den MSCs beschriftet. Als Anfangszustand ist der Zustand IDLE durch einen von einem ausgefüllten Kreis ausgehenden Pfeil angegeben. Der (einzige) Endzustand ist ebenfalls der Zustand IDLE, was in Fig. 8 durch eine doppelte Umrahmung angezeigt ist. Der Endzustand zeigt akzeptierende (erfolg reich abgeschlossene) Berechnungen an.

In einem vierten Schritt 34 des in Fig. 4 gezeigten Verfah rens wird schließlich ein zustandsbasiertes Programm für die Komponente A bestimmt. Dieses Programm wird im hier be schriebenen Ausführungsbeispiel in Form eines endlichen Au tomaten erzeugt. Die Zustandsmenge des Automaten sowie der Anfangszustand und die Endzustände stimmen mit denen der zu standsbasierten Spezifikation überein. Die Zustandsübergänge des Automaten werden aus den Transitionen der zustandsba sierten Spezifikation abgeleitet, indem jede eine Transition bildende Ablaufbeschreibung durch eine entsprechende Folge von (neuen) Zuständen und Übergängen ersetzt wird.

Genauer gesagt, werden zunächst alle Ablaufbeschreibungen, in denen kein Nachrichtenaustausch stattfindet, durch ε- Transitionen ersetzt, um die Möglichkeit eines spontanen Zustandsübergangs anzugeben. Jede andere Ablaufbeschreibung definiert insgesamt k (k < 0) Kommunikationsaktionen, die mit (d₁, n₁, c₁), . . ., (d_k, n_k, c_k) bezeichnet werden sollen. Hierbei geben, für 1 ≦ i ≦ k, jeweils d_i die Richtung des Nachrichtenaustauschs, n_i die Nachricht und c_i den Namen der jeweiligen Quell- bzw. Zielkomponente an. Für eine empfange ne Nachricht gilt d_i = "?", und für eine gesendete Nachricht gilt d_i = "!".

Für k = 1 wird im Automaten die Ablaufbeschreibung durch eine Transition ersetzt, die mit der Kommunikationsaktion (d₁, n₁, c₁) gekennzeichnet ist.

Für k < 1 werden dem Automaten k-1 neue Zustände s₁, . . ., s_k-1 sowie k Transitionen hinzugefügt. Die erste Transition verläuft vom Startzustand der zugrundeliegenden Ablaufbe schreibung zum neuen Zustand s₁ und ist mit der Kommunika tionsaktion (d₁, n₁, c₁) gekennzeichnet. Die k-te Transition verläuft vom neuen Zustand s_k-1 zum Endzustand der zugrunde liegenden Ablaufbeschreibung und ist mit (d_k, n_k, c_k) gekenn zeichnet. Alle anderen Transitionen verlaufen vom Zustand s_i-1 zum Zustand s_i (für 1 < i < k) und sind mit (d_i, n_i, c_i) gekennzeichnet.

Nachdem alle Ablaufbeschreibungen der zustandsbasierten Spe zifikation auf diese Weise umgewandelt wurden, liegt das zustandsbasierte Programm in Form eines nichtdeterministi schen Automaten mit Ein- und Ausgabeaktionen vor. Für die Spezifikation von Fig. 8 ist dieser Automat beispielhaft in Fig. 9 gezeigt. Der Automat ist in Form eines gerichteten Graphen angegeben, bei dem die Knoten Zustände und die Kan ten des Graphen erlaubte Zustandswechsel anzeigen. Anfangs- und Endzustände sind ebenso wie in Fig. 8 gekennzeichnet. Die Kanten des Automaten von Fig. 9 sind mit Kommunikations aktionen beschriftet, wobei der Einfachheit halber die Quell- bzw. Zielkomponenten weggelassen sind. Dies bedeutet, daß beliebige Quell- und Zielkomponenten zulässig sind.

Beispielsweise wurde beim Übergang von der zustandsorien tierten Spezifikation zum zustandsorientierten Programm die mit dem MSC A_ISF2 beschriftete Transition (Fig. 8) in zwei Transitionen umgewandelt, die vom Zustand IDLE über einen neuen Zwischenzustand IC0 und von dort zum Zustand CONFL verlaufen (Fig. 9). Die erste dieser beiden Transitionen ist mit der (vereinfachten) Kommunikationsaktion (!,SREQ) be schriftet. Dies zeigt an, daß der Automat seinen Zustand von IDLE nach IC0 verändern kann, wenn er dabei die Nachricht SREQ an eine beliebige Komponente schickt. Entsprechend kann der Automat beim Empfang einer Nachricht SREQ seinen Zustand von IC0 nach CONFL verändern.

Der in Fig. 9 dargestellte, nichtdeterministische Automat kann bereits das Ergebnis des automatischen Programmerzeu gungsverfahrens darstellen. In Ausführungsalternativen werden jedoch weitere Transformationsschritte durchgeführt. So kann vorgesehen sein, eventuell in dem Automaten ent haltene ε-Transitionen durch ein Verfahren zu entfernen, das beispielsweise aus dem Buch "Einführung in die Automaten theorie, Formale Sprachen und Komplexitätstheorie" von J. E. Hopcroft und J. D. Ullman, Addison Wesley, 2. korrigierter Nachdruck, 1993, an sich bekannt ist.

Ferner kann der (ε-freie) Automat in einen deterministischen Automaten umgewandelt werden. Ein geeignetes Teilmengen-Kon struktionsverfahren ist auf den Seiten 22 bis 24 des gerade genannten Buches beschrieben. Schließlich ist eine Minimali sierung des Zustandsraumes des deterministischen Automaten sinnvoll. Auch dies kann mittels eines an sich bekannten Verfahrens, etwa der Myhill-Nerode-Konstruktion gemäß Seiten 72 bis 76 des gerade genannten Buches, geschehen.

Fig. 10 zeigt beispielhaft einen deterministischen Automa ten, der durch die genannte Teilmengen-Konstruktion aus dem in Fig. 9 dargestellten Automaten abgeleitet ist. Dieser Automat ist bereits in Minimalform, so daß ein weiterer Mi nimalisierungsschritt nicht mehr erforderlich ist.

Insgesamt wird durch die Verfahrensschritte 32 und 34 (Fig. 4) und die oben angegebenen weiteren Schritte für eine Komponente, zu der mindestens eine Ablaufbeschreibung in Normalform vorliegt, ein minimaler, bezüglich der Eingabe nachrichten deterministischer Automat mit Ein- und Ausgabe erzeugt.

In manchen Fällen beschränkt in Schritt 22 (Fig. 4) die Projektion nichtlokaler Bedingungen (das sind Bedingungen, deren Geltungsbereich mehr als eine Komponente umfaßt) auf eine einzelne Komponente den entstehenden Automaten dahin gehend, daß er stark von Zuständen der Umgebung abhängt. So kann beispielsweise die Funktion einer Vermittlungskomponen te, die Nachrichten von mehreren Sendern weiterleiten soll, von der Verzahnung der Nachrichten der Sender abhängen. In Ausführungsalternativen wird diese Einschränkung dadurch ge lockert, daß die Spezifikation 10 ferner je eine surjektive Abbildung von nichtlokalen auf lokale Bedingungen für alle Komponenten aufweist, die in wenigstens einer Ablaufbe schreibung vorkommen. Bei der Projektion in Schritt 22 wird die für die jeweilige Komponente vorgesehene Abbildung ver wendet, um nicht lokale Bedingungen durch lokale Bedingungen zu ersetzen.

In weiteren Ausführungsalternativen können andere Formalis men für das zustandsbasierte Programm verwendet werden. So können die Knoten und/oder die Kanten des Transitionsgraphen mit Ein- und/oder Ausgabeereignissen beschriftet sein.

In anderen Ausführungsalternativen wird das zustandsbasierte Programm durch weitere Umformungsschritte in den Formalismen SDL oder Statecharts oder ROOM ausgedrückt. Diese Umfor mungsschritte können von einem Automaten wie in Fig. 10 aus gehen. Als mögliche Optimierung werden Zustandsübergänge nach dem in Fig. 11a gezeigten Schema gesucht und durch Übergänge gemäß Fig. 11b ersetzt. Genauer gesagt, werden Zu stände T des Automaten identifiziert, deren eingehende Kan ten höchstens mit Nachrichten der Form (?,A), ausgehend bei spielsweise von einem Zustand S, beschriftet sind. Ferner sollen von dem Zustand T genau N (für N < 0) Transitionen (!,B_i) mit Zielzustand U_i (für 1 ≦ i ≦ N) ihren Ursprung ha ben. Hier läßt sich der Zustand T entfernen, indem jede von T ausgehende Transition (!,B_i) mit Zielzustand U_i durch eine Transition von S nach U_i ersetzt wird, die mit (?,A)/(!,B_i) beschriftet ist.

In Ausführungsvarianten können die durch das bisher be schriebene Verfahren erzeugten Automaten weiter vereinfacht werden, wenn der Zustandsraum einen Kontroll- und einen Datenzustand aufweist und erweiterte Zustandsmaschinen mit bewachten Zustandsübergängen und Aktionen zur Änderung des Datenzustands verwendet werden. Die Bedingungen der Ablauf beschreibungen sind dann Paare aus Kontroll- und Datenzu stand. Geeignete Konzepte für solche erweiterte Zustands maschinen sind beispielsweise aus den Statecharts- und ROOM- Formalismen an sich bekannt.

In den bisher beschriebenen Ausführungsbeispielen bestanden - die Ablaufbeschreibungen lediglich aus Kommunikationsaktio nen und Bedingungen. In Ausführungsalternativen ist das Ver fahren jedoch auf mächtigere Formalismen zur Ablauf- und Interaktionsbeschreibung erweitert. Beispielsweise lassen sich Ablaufbeschreibungen, die Auswahl- oder Wiederholungs operatoren enthalten, durch schematische Umformungen in die einfacheren Ablaufbeschreibungen umwandeln, für die das Ver fahren bisher beschrieben wurde.

Nach den bisher beschriebenen Ausführungsbeispielen wurden in den Teilschritten 26 und 28 (Fig. 4) bei der Normalisie rung einer Komponenten-Ablaufbeschreibung fehlende Anfangs- und Endbedingungen jeweils durch die in der Spezifikation 10 (Daten 18) angegebenen Anfangszustände der Komponenten er setzt. In Ausführungsvarianten wird jede solche Komponenten- Ablaufbeschreibung durch eine Menge von Ablaufbeschreibungen ersetzt, in denen je eine beliebige in der Komponente vor kommende Bedingung an Stelle der fehlenden Bedingung einge setzt wird.

Claims

1. Verfahren zum automatischen Erzeugen eines zustands basierten Programms (14A, 14B, 14C) für eine Komponente (A, B, C) eines aus mehreren miteinander kommunizierenden Kompo nenten (A, B, C) bestehenden Systems (S), wobei das Programm (14A, 14B, 14C) aus einer Spezifikation (10) des Systems (S) erzeugt wird, die interaktionsbasierte Ablaufbeschreibungen (16; SS, A_ISF, A_TC, A_TE) des Systems (S) enthält, mit den Schritten:

a) Bestimmen (22) aller durch die Spezifikation (10) des Systems (S) definierten Ablaufbeschreibungen (A_ISS, A_ISF, A_TC, A_TE) der Komponente (A, B, C),
b) Normalisieren (24) der Ablaufbeschreibungen der Kompo nente (A, B, C), so daß eine normalisierte Ablaufbeschrei bung (A_ISS, A_ISF2, A_ISF3, A_TC, A_TE) genau eine Anfangs- und genau eine Endbedingung aufweist und zwischen der An fangs- und der Endbedingung ausschließlich Kommunikations aktionen enthält,
c) Bestimmen (32) einer zustandsbasierten Spezifikation (Fig. 8) der Komponente (A, B, C), indem alle gleichen An fangs- und Endbedingungen der normalisierten Ablaufbeschrei bungen (A_ISS, A_ISF2, A_ISF3, A_TC, A_TE) der Komponente (A, B, C) in je einem einzigen Zustand identifiziert werden, und
d) Bestimmen (34) des zustandsbasierten Programms (14A, 14B, 14C) für die Komponente (A, B, C), wobei jede in der zustandsbasierten Spezifikation (Fig. 8) der Komponente (A, B, C) enthaltene Ablaufbeschreibung (A_ISS, A_ISF2, A_ISF3, A_TC, A_TE) durch eine Folge der Kommunikationsaktionen die ser Ablaufbeschreibung, getrennt durch zusätzlich eingefügte Zustände (CI0, IC0, IS0, SI0, SS0), ersetzt wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß in Schritt a) jede die Kompo nente (A, B, C) betreffende Ablaufbeschreibung (16; ISS, A_ISF, A_TC, A_TE) des Systems (S) auf eine entsprechende Ablaufbeschreibung (A_ISS, A_ISF, A_TC, A_TE) der Komponente (A, B, C) beschränkt wird.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß in Schritt b) die folgenden Teilschritte ausgeführt werden:

b1) Einfügen (26) einer in der Spezifikation (10) des Sy stems (S) vorgegebenen Bedingung als Anfangsbedingung in je de mit einer Kommunikationsaktion beginnende Ablaufbeschrei bung (A_ISF) der Komponente (A, B, C),

b2) Einfügen (28) einer in der Spezifikation (10) des Sy stems (S) vorgegebenen Bedingung als Endbedingung in jede mit einer Kommunikationsaktion endende Ablaufbeschreibung (A_ISF) der Komponente (A, B, C), und

b3) Aufspalten (30) aller Ablaufbeschreibungen (A_ISF1) der Komponente (A, B, C), die mehr als zwei Bedingungen aufwei sen, in mehrere Ablaufbeschreibungen (A_ISF2, A_ISF3) der Komponente (A, B, C) mit jeweils genau zwei Bedingungen.

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß Teilschritt b1) und/oder Teil schritt b2) für jede von mehreren einzufügenden Bedingung/en wiederholt werden/wird, um entsprechend viele Ablaufbe schreibungen (A_ISF1) der Komponente (A, B, C) zu erhalten.

5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß die interaktionsbasierten Ab laufbeschreibungen (16; ISS, A_ISF, A_TC, A_TE) des Systems (S) durch Message Sequence Charts oder UML-Sequenzdiagramme repräsentierbar sind.

6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß das zustandsbasierte Programm (14A, 14B, 14C) für die Komponente (A, B, C) als Automat, insbesondere als SDL- oder Statechart- oder ROOM-Automat repräsentierbar ist.

7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß das zustandsbasierte Programm (14A, 14B, 14C) auf einem erweiterten Zustandsautomaten be ruht, dessen Zustandsraum einen Kontroll- und einen Datenzu stand aufweist, und daß Zustandsübergänge in Abhängigkeit von dem jeweils aktuellen Datenzustand ausgeführt werden und diesen Datenzustand zu ändern vermögen.

8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, daß in Schritt d) ferner ε-Transi tionen aus dem zustandsbasierten Programm (14A, 14B, 14C) entfernt werden.

9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, daß in Schritt d) ein deterministi sches zustandsbasiertes Programm (14A, 14B, 14C) erzeugt wird.

10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß das in Schritt d) erzeugte zu standsbasierte Programm (14A, 14B, 14C) insbesondere hin sichtlich der Anzahl der Zustände optimiert wird.

11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, daß in Schritt a) nichtlokale Bedin gungen in den Ablaufbeschreibungen (16; ISS, A_ISF, A_TC, A_TE) des Systems (S) gemäß einer vorgegebenen surjektiven Abbildung durch lokale Bedingungen ersetzt werden.

12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, daß das Verfahren zum Erzeugen eines zustandsbasierten Programms für Telekommunikationsanwendun gen, insbesondere zum Bereitstellen eines fehlertoleranten Daten- und Nachrichtenaustauschs, und/oder zum Erzeugen eines Programms für ein reaktives System, insbesondere ein Regelungs- und Steuerungssystem, und/oder zum Erzeugen eines Benutzerschnittstellen-Programms und/oder zum Erzeugen eines Datenbankabfrageschema-Programms dient.