DE69900810T2

DE69900810T2 - Verfahren und Vorrichtung zum Testen von ereignisgesteuerten Programmen

Info

Publication number: DE69900810T2
Application number: DE69900810T
Authority: DE
Inventors: Gerard Joan Holzmann; Kenneth Lane Thompson; Philip Steven Winterbottom
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 1998-12-15
Filing date: 1999-12-07
Publication date: 2002-08-29
Anticipated expiration: 2019-12-08
Also published as: CA2288378A1; EP1014265A1; JP2000181750A; JP3631647B2; EP1014265B1; US6353896B1; DE69900810D1

Description

Technisches Gebiet

Die vorliegende Erfindung betrifft das Prüfen von Computersoftwareprogrammen und insbesondere ein Verfahren zum Prüfen ereignisgesteuerter Anwendungsprogramme.

Allgemeiner Stand der Technik

In wohlbekannten ereignisgesteuerten Softwaresystemen (die in der Technik auch als "reaktive Systeme" bezeichnet werden) treten bestimmte Funktionen auf, wenn ein Ereignis erzeugt und zu einem ausführenden Prozeß übermittelt wird, der auf der Grundlage des Auftretens des gegebenen Ereignisses bestimmte Aktionen durchführt. Insbesondere wird mit ereignisgesteuerter Software das Verhalten eines Systems, z. B. eines Computers, als Reaktion auf Ereignisse definiert, die von angeschlossenen anderen Systemen, Maschinen oder Peripheriegeräten erzeugt werden. Wohlbekannte ereignisgesteuerte Systeme sind zum Beispiel: Telekommunikationsanwendungen, Verbindungsbearbeitungssoftware, Datenkommunikationssoftware, Gerätetreiber und Computerschnittstellenanwendungen. Es ist ersichtlich, daß diese Arten von ereignisgesteuerten Systemen zustandsorientiert sind. Das heißt, es wird erwartet, daß in jedem Zustand eines Systems ein spezifisches Ereignis aus einer vordefinierten Menge von Ereignissen auftritt, und das System ist so ausgelegt, daß es auf wohldefinierte Weise auf das Ereignis reagiert.
Kurz gefaßt und wohlbekanntlich setzt ein Automat eine Zeitreihe von Ereignisstimuli oder Eingangsdaten durch eine bestimmte Funktion in eine Zeitreihe von Antworten oder Ausgangsdaten um. Zum Beispiel befindet sich in einem ereignisgesteuerten System zu jedem Zeitpunkt jede Maschine in einem bestimmen Sogenanten "Steuerzustand", der die Ereignisse, von denen erwartet wird, daß sie von anderen Maschinen erzeugt werden, und die Art von Reaktionen, die bei der Ankunft jedes solchen Ereignisses erzeugt werden sollen, definiert. Die Reaktion umfaßt in der Regel die Ausführung eines endlichen Programmcodestücks, die Erzeugung neuer Ereignisse und die Identifizierung eines neuen Steuerzustands für die bestimmte Maschine, die auf die ankommenden Ereignisse reagiert. Somit spielt das Automatenmodell des ereignisgesteuerten Systems eine kritische Rolle bei der Entwicklung des Anwendungsprogrammcodes durch den Programmierer für das System.
Ereignisgesteuerte Anwendungssoftware wird in der Regel in höheren Vielzweckprogrammiersprachen, wie zum Beispiel den wohlbekannten Programmiersprachen "C" oder "C++", oder in einer speziellen Sprache, wie zum Beispiel der wohlbekannten Systembeschreibungssprache ("SDL") der ITU, geschrieben. Bei der Entwicklung des eigentlichen Programmcodes für solche Systeme ist es üblich, das Verhalten der relevanten Maschinen in Form von Automaten zu beschreiben. Durch Verwendung einer höheren Programmiersprache wie z. B. C schreiben Softwareprogrammierer Code für ereignisgesteuerte Software für die gegebene Anwendung. Die Softwareprogrammentwicklung beginnt in der Regel mit einer Betrachtung einer sogenannten Systemspezifikation, die eine logische Beschreibung der gewünschten Operationen für die Anwendung liefert. Auf der Grundlage der Spezifikation schreiben ein oder mehrere Programmierer den notwendigen Code zur Implementierung der Operationen.
Dieser herkömmliche Programmierungsprozeß führt zu einem Anwendungsprogramm, das unter und zwischen den verschiedenen Steuerzuständen des ereignisgesteuerten Systems keinen konkreten visuellen Kontext enthält. Das heißt, der Programmcode kann als eine große "flache" Datei mit einer Reihe von Programmbefehlen betrachtet werden. Wenn sich die ursprüngliche Spezifikation während der Programmentwicklung ändert, z. B. zusätzliche Funktionen zu dem System hinzugefügt werden, werden außerdem der erforderliche Programmcode und die zusätzlichen Steuerzustände in der Regel in einer zu gewissem Grade willkürlichen Reihenfolge zu dem Quellprogramm hinzugefügt. Damit ein Programmierer den Logikfluß von Steuerzustand zu Steuerzustand direkt aus dem Programmquellcode verstehen kann, ist es notwendig, den Ausführungs-Thread manuell durch den Quellcode zu verfolgen, wobei z. B. Verzweigungsbefehle oder "goto"-Anweisungen verfolgt werden. Es versteht sich, daß das Verfolgen dieses Logikflusses insbesondere in sehr großen Quellcodeprogrammen eine mühsame und zeitaufwendige Aufgabe ist. Dies führt außerdem zu einer bestimmten Komplexität beim Prüfen der Software auf sogenannte "Bugs" und bei der Bestimmung, ob das Anwendungsprogramm die bestimmten Merkmale implementiert.
Insbesondere besteht ein kritischer Zustand bei der Entwicklung des Anwendungssoftwarecodes für solche Systeme in der Prüfung des Codes, um die Eigenschaften der Software zu validieren und um sicherzustellen, daß das Verhalten des Systems den Entwurfszielen entspricht. Es gibt mehrere wohlbekannte Verfahren zum Prüfen ereignisgesteuerter Software. Zum Beispiel beschreibt Boris Beizer, Black-Box Testing: Techniques for Functional Testing of Software and Systems, John Wiley and Sons, 1984, eine wohlbekannte Prüfanordnung, bei der eine Menge von Prüfzielen definiert wird, aus der eine begrenzte Menge von Prüfsequenzen abgeleitet wird. Die Menge von Testsequenzen wird in der Regel vom Prüftechniker durch einen manuellen Prozeß definiert, indem der Systementwurf untersucht wird. Die Menge von Prüfsequenzen wird an die geprüfte ereignisgesteuerte Software angelegt, und es wird entweder ein "bestanden" oder ein "durchgefallen" als das Prüfergebnis aufgezeichnet. Diese Prüfmethode wird in der Regel auf die allgemeine Softwareprüfung angewandt, und es ist in der Technik bekannt, daß sie anfällig gegenüber menschlichen Fehlern und unvollständig ist. Insbesondere ist die Anzahl möglicher Ausführungen der geprüften ereignisgesteuerten Software unglaublich groß. Im Gegensatz dazu ist die Anzahl von Prüfungen, die an der Software mit Echtzeitausführungen durchgeführt werden können, durch bestimmte praktische Beschränkungen, wie zum Beispiel die minimale Zeit, die erforderlich ist, um eine einzige Prüfung aus der Gesamtzahl von Prüfungen durchzuführen, begrenzt. Folglich ist es typisch, daß gemäß dieser Methode höchstens einige wenige hundert Prüfungen ausgewählt und angewandt werden können. Dies führt zu einem sehr niedrigen Konfidenzwert bei der Prüfabdeckung.
Ein zweites in der Technik bekanntes Verfahren für ereignisgesteuerte Software wird z. B. von D. Lee et al., Principles and Methods of Testing Finite State Machines - A Survey, Proceedings of the IEEE, Band 84, S. 1090-1126, 1996, beschrieben. Gemäß diesem Prüfverfahren wird ein abstraktes Automatenmodell für das ereignisgesteuerte Softwareprogramm konstruiert. Das Automatenmodell erfaßt in der Regel nur eine Beschreibung des Programmcodes auf höherer Ebene und läßt dadurch den größten Teil der Programmeinzelheiten aus. Danach können wohlbekannte Prüfsegenzenerzeugungsalgorithmen (siehe z. B. Lee, supra.) auf das Automatenmodell angewandt werden, woraus eine relativ kleine Menge von Prüfungen abgeleitet und auf die geprüfte Software angewandt wird. Wie bei dem oben beschriebenen Prüfverfahren verläßt sich diese Technik sehr auf die manuelle Konstruktion des abstrakten Modells der ereignisgesteuerten Software. Deshalb ist diese Technik gegenüber bestimmten Fehlern empfindlich, die durch Fehlanpassungen zwischen der formalen Beziehung zwischen der geprüften Software und dem abstrakten Modell, mit dem die anwendbaren Prüfungen abgeleitet werden, verursacht werden. Außerdem erfordern Änderungen der ereignisgesteuerten Software die Entwicklung neuer Prüfungen, was sich als umständlich und zeitaufwendig erweist.
Bei einem dritten häufig verwendeten Prüfverfahren (siehe z. B. C. H. West, "Protocol Validation by Random State Exploration", Proc. 6th IFIPWG 6.1 Int. Workshop on Protocol Specification, Testing, and Verification, North-Holland Publ. S. 233-242, 1986) wird eine zufällige Erkundung des vollständigen Verhaltens der ereignisgesteuerten Software unternommen, um festzustellen, ob die Software den gewünschten Eigenschaften entspricht. Das Ausmaß der Einzelheiten in der vollständigen Softwarebeschreibung schließt im allgemeinen jeden Versuch aus, eine erschöpfende Erkundung der Software für Prüfzwecke durchzuführen. Deshalb werden wohlbekannte statistische Algorithmen verwendet, um Zufallsproben des Verhaltens der Software zu entnehmen und zu analysieren. Wie bei den anderen oben beschriebenen Prüfanordnungen besteht jedoch ein anerkannter Nachteil dieses Prüfansatzes darin, daß die Menge überflüssiger Einzelheiten in der vollständigen Softwarebeschreibung eine effiziente erschöpfende Erkundung des vollständigen Verhaltens der Software für eine Erfüllung von Eigenschaften auf hoher Ebene verhindert.
Deshalb wird ein Verfahren benötigt, das die oben beschriebenen Probleme in der Technik mildert und die Programmierungsentwicklung und -prüfung von ereignisgesteuerter Software verbessert.

Kurze Darstellung der Erfindung

Die vorliegende Erfindung, die durch die Ansprüche definiert wird, liefert ein Verfahren zum Prüfen ereignisgesteuerter Software, das auf die effiziente Prüfung ereignisgesteuerter Software ausgerichtet Äst und ermöglicht, die Validität zukünftiger Änderungen des Programmcodes als Teil des normalen Wartungs-, Erweiterungs- und Revisionsprozesses für den Sourcecode zu verfolgen. Insbesondere wird gemäß der bevorzugten Ausführungsform der Erfindung Code von ereignisgesteuerter Software gemäß den Prinzipien der EP-A-1 018 684 spezifiziert und geschrieben.
Das heißt, das Quellcodeprogramm wird gemäß der bevorzugten Ausführungsform in einem steuerempfindlichen und nicht-steuerempfindlichen Format definiert und strukturiert. Gemäß der vorliegenden Erfindung wird das ereignisgesteuerte Quellcodeprogramm durchlaufen, um die in dem Quellprogramm definierten Steuerzustände zu extrahieren und um den Quellcode in ein Zwischen-Automatenformat umzusetzen. Danach wird das Zwischen-Automatenformat gemäß der Erfindung für Modellierungsüberprüfungszwecke in ein automatengestütztes Format umgesetzt.
Insbesondere wird das Zwischen-Automatenformat gemäß der bevorzugten Ausführungsform in ein kommentiertes Automatenmodell umgesetzt. Das kommentierte Automatenmodell ist beispielsweise ein Verifizierungsprogramm, das in der Eingabesprache eines spezifischen Modellprüfers geschrieben ist. Insbesondere und bedeutsamerweise wird jede Anweisung aus dem Quellcodeprogramm gemäß der Erfindung auf eine Abstraktion in dem Automatenmodell abgebildet. Die Abbildung wird mit einer Übersetzungsabbildung erzielt, die in der Anfangsphase des Verifizierungsprozesses definiert wird. Die Abbildung muß danach nicht revidiert werden, solange keine neuen Arten von Anweisungen, z. B. nachdem Revisionen zum Reparieren von Programmierungsfehlern erfolgen, in das Quellprogramm eingeführt werden. Die Abbildung schreibt u. a. eine feste Übersetzung der gegebenen Anweisung in die Zielsprache des Modellprüfers vor. Somit werden in der Abbildung auftretende Anweisungen systematisch in das Automatenmodell umgesetzt, wo auch immer derartige Anweisungen im Quellcode vorkommen.
Zusätzlich zu der oben beschriebenen Abbildung wird gemäß der Erfindung ein sogenanntes Umgebungsmodell definiert, das eine minimale Menge von Annahmen einkapselt, die über die gegebene Betriebsumgebung, in der die ereignisgesteuerte Anwendung ausgeführt wird, getroffen werden müssen. Genauer gesagt wird, während die Modellprüfereingabesprache dem Modellprüfer zugeführt wird, das Umgebungsmodell angewandt. Als Ergebnis erfolgt die Verifizierung der Eigenschaften des ereignisgesteuerten Systems gemäß der bevorzugten Ausführungsform der Erfindung unter der Bedingung des Umgebungsmodells während des Testens und Prüfens der ereignisgesteuerten Software durch das Verifizierungssystem. Danach werden die Test- und Prüfergebnisse auf wohlbekannte Weise von dem Modellprüfer ausgegeben, um zu bestimmen, ob das ereignisgesteuerte System den gewünschten Ausführungseigenschaften und -verhaltensweisen des Benutzers entspricht.
Vorteilhafterweise erfolgt der Modellextraktionsprozeß und die Anwendung des Modellprüfers gemäß der Erfindung auf direkte und dynamische Weise von dem ereignisgesteuerten Systemprogrammcode aus, ohne daß der Benutzer eingreifen muß.

Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein Blockschaltbild eines beispielhaften ereignisgesteuerten Systems;
Fig. 2, 2A, 3 und 3A zeigen ein Beispiel für ein herkömmliches C-Quellcodeprogramm für eine beispielhafte Telekommunikationsverbindungsbearbeitungsanwendung, die in dem beispielhaften ereignisgesteuerten System von Fig. 1 nützlich ist;
Fig. 4 zeigt ein Flußdiagramm beispielhafter Operationen für die Softwareentwicklung gemäß den Prinzipien der Erfindung;
Fig. 5, 5A, 6 und 6A zeigen ein beispielhaftes C- Quellcodeprogramm, das gemäß den Softwareentwicklungsoperationen von Fig. 4 strukturiert und definiert ist, für die beispielhafte Telekommunikationsverbindungsbearbeitungsanwendung von Fig. 2, 2A, 3 und 3A;
Fig. 7, 7A, 8 und 8A zeigen ein übersetztes Quellcodeprogramm, das gemäß den Prinzipien der Erfindung aus dem beispielhaften C-Quellcodeprogramm von Fig. 5, 5A, 6 und 6A abgeleitet wird;
Fig. 9 zeigt ein Flußdiagramm beispielhafter Operationen zum Testen ereignisgesteuerter Software gemäß der vorliegenden Erfindung;
Fig. 10 und 10A zeigen Zwischenautomatencode, der aus dem beispielhaften C-Quellcodeprogramm von Fig. 5, 5A, 6 und 6A abgeleitet wird;
Fig. 11 zeigt eine beispielhafte Abbildung für das durch das beispielhafte C-Quellcodeprogramm von Fig. 5, 5A, 6 und 6A definierte ereignisgesteuerte System;
Fig. 12, 12A, 13 und 13A zeigen Modellprüfereingabespräche, die durch Anwenden der beispielhaften Abbildung von Fig. 11 abgeleitet wird;
Fig. 14, 14A und 14B zeigen eine beispielhafte Menge von Bibliotheksfunktionen zur Verwendung mit der Modellprüfereingabesprache von Fig. 12, 12A, 13, 13A und 13B;
Fig. 15 zeigt ein beispielhaftes Umgebungsmodell für die in Fig. 5, 5A, 6 und 6A beschriebene Telekommunikationsbearbeitungsanwendung;
Fig. 16 zeigt ein beispielhaftes Automatenmodell für einen bestimmten Steuerzustand, der durch die Telekommunikationsbearbeitungsanwendung von Fig. 5, 5A, 6 und 6A definiert wird;
Fig. 17 zeigt ein beispielhaftes vollständiges Automatenmodell der in Fig. 5, 5A, 6 und 6A beschriebenen vollständigen Telekommunikationsbearbeitungsanwendung;
Fig. 18 zeigt ein beispielhaftes Computersystem 1800, das bei der Ausführung von ereignisgesteuertem Softwarecode, der gemäß der vorliegenden Erfindung spezifiziert und geschrieben wird, nützlich ist;
Fig. 19 zeigt eine beispielhafte Fehlerverfolgung, die gemäß den Prinzipien der vorliegenden Erfindung für die in Fig. 5, 5A, 6 und 6A beschriebene Telekommunikationsbearbeitungsanwendung erzeugt wird.
In der vorliegenden Offenlegung werden durchweg, sofern nicht anders angegeben, gleiche Elemente, Blöcke, Komponenten oder Teile in den Figuren mit denselben Bezugskennzeichnungen bezeichnet.

Ausführliche Beschreibung

Ein Teil der Offenlegung der vorliegenden Patentschrift enthält Material, das urheberrechtlich geschützt ist. Der Urheber hat keine Einwände gegen die Fax- Reproduktion der Patentschrift oder der Patentoffenlegung, so wie sie in den Akten oder Aufzeichnungen des Patentamts erscheinen, durch beliebige Personen. Ansonsten werden jedoch alle anderen Rechte in bezug auf die urheberrechtlich geschützten Arbeiten in jeder Hinsicht vorbehalten.
Die vorliegende. Erfindung liefert ein Verfahren zum prüfen ereignisgesteuerter Software. Gemäß den verschiedenen Aspekten der Erfindung wird der Programmquellcode des ereignisgesteuerten Systems direkt in ein automatengestütztes Modell umgesetzt, das bei der Verifizierung, ob Programmcode den vom Benutzer definierten gewünschten Eigenschaften entspricht, nützlich ist. Genauer gesagt wird gemäß einer bevorzugten Ausführungsform der Erfindung der Programmcode des ereignisgesteuerten Systems in eine Zielsprache für einen bestimmten Modellprüfer übersetzt. Diese Übersetzung führt zu einem Modell, das Anweisungen enthält, die damit in Zusammenhang stehen, ob die Ausführung des Programmcodes das Verhalten des ereignisgesteuerten Systems beeinflussen wird, z. B. die Ausführung des Programmcodes die Erzeugung neuer Ereignisse verursacht. Somit kann dieser Modellextraktionsprozeß der bevorzugten Ausführungsform der Erfindung als Eingabe für einen Logikmodellprüfer verwendet werden, um zu bestimmen, ob das ereignisgesteuerte System den vom Benutzer spezifizierten gewünschten Korrektheitseigenschaften entspricht. Vorteilhafterweise erfolgen gemäß der Erfindung der Modellextraktionsprozeß und die Anwendung des Modellprüfers auf direkte und dynamische Weise von dem Programmcode des ereignisgesteuerten Systems aus ohne Notwendigkeit einer Benutzerintervention.
Die vorliegende Erfindung kann in Form von Verfahren und Vorrichtungen zur Ausübung dieser Verfahren realisiert werden. Die Erfindung kann außerdem in Form von Programmcode realisiert werden, der in greifbaren Medien, wie zum Beispiel Disketten, CD-ROMs, Festplatten oder einem beliebigen anderen maschinenlesbaren Speichermedium, realisiert wird, wobei, wenn der Programmcode in eine Maschine, wie zum Beispiel einen Computer, geladen wird und von dieser ausgeführt wird, die Maschine zu einer Vorrichtung zur Ausübung der Erfindung wird. Die Erfindung kann außerdem in Form von Programmcode, zum Beispiel in einem Speichermedium, realisiert werden, der in eine Maschine geladen und/oder von dieser ausgeführt oder über ein bestimmtes Übertragungsmedium, wie zum Beispiel über elektrische Verdrahtung oder Verkabelung, durch Faseroptik oder über elektromagnetische Strahlung übertragen wird, wobei, wenn der Programmcode in eine Maschine, wie zum Beispiel einen Computer, geladen und von dieser ausgeführt wird, die Maschine zu einer Vorrichtung zur Ausübung der Erfindung wird. Bei Implementierung auf einen Vielzweckprozessor kombinieren sich die Programmcodesegmente mit dem Prozessor, um eine eindeutige Vorrichtung zu liefern, die analog zu spezifischen Logikschaltungen wirkt.
Um einen Kontext zu geben und ein Verständnis der Erfindung zu erleichtern, wird nun eine Übersicht und Besprechung eines beispielhaften ereignisgesteuerten Systems vorgestellt. Insbesondere zeigt Fig. 1 ein Blockschaltbild eines beispielhaften Kommunikationsnetzes, das offensichtlich unzählige ereignisgesteuerte Anwendungen enthält. Das Kommunikationsnetz 100 ist z. B. ein öffentliches Fernsprechwählnetz, wie zum Beispiel das wohlbekannte Amtsverbindungsnetz der AT&T Corp., das seinen Teilnehmern Fernverbindungsfernsprechdienste liefert. Diese Teilnehmer greifen z. B. durch Kommunikationsgeräte 105-1 bis 105-6 auf das Kommunikationsnetz 100 zu, bei denen es sich z. B. um Teilnehmergeräte, verdrahtete Fernsprecher, PCs, Zellularfernsprecher, Pager und Faxmaschinen handelt. Das Kommunikationsnetz 100 enthält u. a. mehrere Fernvermittlungsanlagen, die z. B. in Fig. 1 als Fernvermittlungsanlagen 115, 120, 125 und 130 gezeigt sind. Diese Fernvermittlungsanlagen können beliebige der wohlbekannten Arten von Telekommunikationsvermittlungsgeräte sein, wie z. B. die Nr. 4ESS® (Elektronisches Vermittlungssystem) oder die Nr. 5ESS®, erhältlich von Lucent Technologies Inc., 600 Mountain Ave., Murray Hill, NJ 07974. Wie in Fig. 1 gezeigt, sind alle Fernvermittlungsanlagen 115, 120, 125 und 130 über ein sogenanntes, als Block 150 gezeigtes Ferninterverbindungsnetz mit einer Reihe anderer Vermittlungen verbunden. Jede Fernvermittlungsanlage kann außerdem mit mehreren Vermittlungsstellen ("CO"), z. B. den COs 110 bis 114, verbunden sein. Der Betrieb solcher Telekommunikationsnetze und COs ist wohlbekannt und wird zum Beispiel in "Engineering and Operations in the Bell System", Second Edition, Eighth Printing, International Standard Book Number 0-932764-04-5, 1993, beschrieben, und ihre Einzelheiten werden hier nicht weiter besprochen. Kurz gefaßt ist eine CO so ausgelegt, daß sie eine Fernsprechverbindung, die z. B. durch das Kommunikationsgerät 105-1 eingeleitet wird, von dem aus ein Anrufer eine bestimmte Rufnummer gewählt hat, zu einer entsprechenden Fernvermittlungsanlage des Kommunikationsnetzes 100 verlängert. Die CO, z. B. die CO 110, ist außerdem so ausgelegt, daß sie die Verbindung z. B. zu dem Kommunikationsgerät 105-6 verlängert, das dem angerufenen Teilnehmer zugeordnet ist, und zu der CO, z. B. der CO 114, die die verlängerte Verbindung von der entsprechenden Fernvermittlungsanlage, z. B. der Fernvermittlungsanlage 125, empfängt.
Die Fernvermittlungsanlagen 115, 120, 125 und 130 des Kommunikationsnetzes 100 sind über eine Datenstrecke 135 miteinander verbunden, bei der es sich z. B. um das wohlbekannte SS7-Netz (System Signaling 7) handeln kann. Das Kommunikationsnetz 100 ist so ausgelegt, daß die Fernvermittlungsanlagen Datennachrichten miteinander austauschen können, um über das Kommunikationsnetz 100 eine Verbindung zwischen einem Anrufer (z. B. dem Kommunikationsgerät 105-1) und einem angerufenen Teilnehmer (z. B. dem Kommunikationsgerät 105-6) herzustellen. Das heißt, die Verbindung wird hergestellt, indem eine Verbindung so lange durch das Kommunikationsnetz 100 verlängert wird, bis die Verbindung zwischen dem Anrufer und dem angerufenen Teilnehmer hergestellt ist (z. B. der angerufene Teilnehmer die Verbindung durch "Abheben" entgegennimmt). Das Kommunikationsnetz 100 enthält außerdem mehrere zentrale Datenbasen, die gewöhnlich als Netzsteuerungspunkte ("NCPs") bekannt sind, von denen ein einzelner als NCP 140 gezeigt ist. Es ist wohlbekannt, daß NCPs, wie zum Beispiel der NCP 140, strategisch an verschiedenen Stellen in dem Kommunikationsnetz 100 angeordnet sind, um verschiedene Dienstmerkmale zu unterstützen, auf die durch das Netzwerk zugegriffen wird und die durch das Netzwerk bereitgestellt werden, wie zum Beispiel die wohlbekannten gebührenfreien Rufnummerndienste "800" oder "888".
Es versteht sich, daß das Kommunikationsnetz 100 und die verschiedenen oben beschriebenen Elemente des Netzes unzählige ereignisgesteuerte Anwendungen erfordern. Zum Beispiel müssen Verbindungsbearbeitungsanwendungsprogramme für die Fernvermittlungsanlagen 115, 120, 125 und 130 entwickelt werden, um die Verlängerung einer Verbindung durch das Netz 100 zu erleichtern. Insbesondere kann zum Beispiel ein Anrufer wünschen, das Kommunikationsgerät 105-1 zu verwenden, um eine abgehende Verbindung einzuleiten. Eine solche ereignisgesteuerte Verbindungsbearbeitungsanwendung enthält Operationen, d. h. Steuerzustände, wie zum Beispiel Abheben, Wählen, Frei, Verbinden, Rufen und Belegt, um nur einige wenige zu nennen.
Wie bereits erwähnt wird gemäß der bevorzugten Ausführungsform der Erfindung ereignisgesteuerter Softwarecode gemäß den Prinzipien der EP-A-1 018 684 spezifiziert und geschrieben.
Um ein vollständiges Verständnis der vorliegenden Erfindung weiter zu erleichtern, werden also die verschiedenen Aspekte der Erfindung in der EP-A-1 018 684 nun in einiger Ausführlichkeit besprochen.
Die verschiedenen Aspekte der Erfindung in dieser Anmeldung liefern ein Programmierungsverfahren zum Definieren, Strukturieren und Entwickeln ereignisgesteuerter Software. Genauer gesagt wird ereignisgesteuerte Software in zwei grundlegende Teile strukturiert, die dort und hier spezifisch als steuerempfindlicher Code und nicht-steuerempfindlicher Code bezeichnet werden. Gemäß der Erfindung umfaßt steuerempfindlicher Code die Identifizierung von Steuerzuständen, die Ereignisse, die erzeugt und erkannt werden müssen, und die Reakrionen auf die Ankunft bestimmter Ereignisse in bestimmten Zuständen. Außerdem werden in dem das System definierenden steuerempfindlichen Code Steuerzustände eindeutig mit einem einzigen Symbol in dem gesamten derartigen Programmcode identifiziert. Der nichtsteuerempfindliche Code, der getrennt von dem steuerempfindlichen Code spezifiziert wird, betrifft den notwendigen normalen sequentiellen Code zur Programmierung des ereignisgesteuerten Systems, wie zum Beispiel das Aufrufen von Gerätetreibern, die Steuerung von Peripheriegeräten, die Aktualisierung von Tabellen, Variablendefinition usw. Vorteilhafterweise ermöglicht die Erfindung dem Softwareentwickler, den Anwendungscode der ereignisgesteuerten Software so zu strukturieren, daß eine klare Unterscheidung zwischen Kernsteuermerkmalen, d. h. Zuständen, Ereignissen und Reaktionen, und belanglosen Einzelheiten getroffen wird, die sich nicht direkt auf das Verhalten des ereignisgesteuerten Systems auswirken. Dementsprechend kann der Programmierer den genauen Ausführungsfluß von Steuerzustand zu Steuerzustand direkt aus einer oberflächlichen Untersuchung des Programmcodes selbst bestimmen, da die einzelnen Steuerzustände einen starken visuellen Kontext aufweisen. Das heißt, der Programmquellcode wird gemäß der Erfindung so strukturiert und definiert, daß die Steuerzustände, die die ereignisgesteuerte. Anwendung definieren, eine direkte und logische, d. h. kausale, Beziehung aufweisen, die aus einer Untersuchung des Quellcodes selbst unmittelbar ersichtlich ist.
Genauer gesagt zeigen Fig. 2 und 2A und Fig. 3 und 3A ein Beispiel für ein herkömmliches C-Quellcodeprogramm 200 (das durch einzelne Programmcodezeilennummern 1-268 abgegrenzt wird), das eine solche beispielhafte ereignisgesteuerte Anwendung zur Verarbeitung einer abgehenden Verbindung betrifft. Es ist ersichtlich, daß das Quellcodeprogramm 200 mehrere Steuerzustände für die Anwendung definiert. Siehe zum Beispiel die Codeabschnitte 205 bis 230, die Operationen für die folgenden jeweiligen Steuerzustände definieren: belegt, verbinden, tot, Ziffern, frei und rufen. Signifikanterweise liefert eine Untersuchung des Quellcodeprogramms 200 jedoch keine unmittelbar offensichtliche Ansicht des Ausführungs-Thread zwischen den verschiedenen Steuerzuständen. Vom Standpunkt der höheren Programmierung aus gesehen gibt es keine direkte oder logische, d. h. kausale, Beziehung zwischen den verschiedenen Steuerzuständen, die in dem Quellprogrammcode definiert sind. Das heißt, damit ein Programmierer den Logikfluß von Steuerzustand zu Steuerzustand direkt aus dem Programmguellcode verstehen kann, ist es wie bereits erwähnt notwendig, den Ausführungs-Thread durch den Quellcode zu verfolgen, wobei z. B. Verzweigungsbefehle oder "goto"- Anweisungen verfolgt werden. Das Verfolgen eines solchen Logikflusses ist insbesondere in sehr großen Quellcodeprogrammen offensichtlich eine umständliche, nicht aufschlußreiche, fehleranfällige und zeitaufwendige Aufgabe. Zum Beispiel wird der Quellcode zur Implementierung aller erforderlichen Verbindungsbearbeitungsmerkmale des Kommunikationsnetzes 100 wahrscheinlich zehntausende Codezeilen enthalten. Dies führt außerdem zu einer gewissen Komplexität beim Prüfen der Software auf sogenannte "Bugs" und bei der Bestimmung, ob das Anwendungsprogramm die gewünschten Merkmale implementiert. Signifikanterweise wendet sich das neuartige Programmierungsverfahren an die Definition, Strukturierung und Codierung von ereignisgesteuerter Software, die bestimmte Nachteile des Stands der Technik mildert. Gemäß der Erfindung umfaßt steuerempfindlicher Code die Identifizierung von Steuerzuständen, der Ereignisse, die erzeugt werden und erkannt werden müssen, und der Reaktionen auf die Ankunft bestimmter Ereignisse in bestimmten Zuständen. Außerdem werden innerhalb des das System definierenden steuerempfindlichen Codes Steuerzustände in dem gesamten derartigen Programmcode mit einem einzigen Symbol eindeutig identifiziert. Der nichtsteuerempfindliche Code, der getrennt von dem steuerempfindlichen Code spezifiziert wird, betrifft den notwendigen normalen sequentiellen Code zur Programmierung des ereignisgesteuerten Systems, wie zum Beispiel das Aufrufen von Gerätetreibern, die Steuerung von Peripheriegeräten, das Aktualisieren von Tabellen, Variablendefinitionen usw.
Vorteilhafterweise ermöglicht die Erfindung dem Softwareentwickler, den Anwendungscode der ereignisgesteuerten Software so zu strukturieren, daß eine klare Unterscheidung zwischen Kernsteuermerkmalen, d. h. Zuständen, Ereignissen und Reaktionen, und belanglosen Einzelheiten getroffen wird, die sich nicht direkt auf das Verhalten des ereignisgesteuerten Systems auswirken. Dementsprechend kann der Programmierer den genauen Ausführungsfluß von Steuerzustand zu Steuerzustand direkt aus einer oberflächlichen Untersuchung des Programmcodes selbst bestimmen, da die einzelnen Steuerzustände einen starken visuellen Kontext aufweisen. Das heißt, der Programmquellcode wird gemäß der Erfindung so strukturiert und definiert, daß die Steuerzustände, die die ereignisgesteuerte Anwendung definieren, eine direkte und logische, d. h. kausale, Beziehung aufweisen, die aus einer Untersuchung des Quellcodes selbst unmittelbar ersichtlich ist.
Gemäß der bevorzugten Ausführungsform der Erfindung wird eine Programmierungserweiterung der wohlbekannten Programmiersprache C des ANSI-Standards angenommen, um die Definition, Strukturierung und Codierung von ereignisgesteuerter Software gemäß der Erfindung zu erleichtern. Genauer gesagt besteht gemäß der bevorzugten Ausführungsform der Erfindung die Erweiterung der Programmiersprache C des ANSI-Standards aus einem einzigen Symbol, das beispielsweise als das wohlbekannte ASCII-Symbol "@" gewählt wird und zur Etikettierung aller Steuerzustände in dem steuerempfindlichen Teil des Programmcodes dient. Das heißt, das Symbol "@" wird als das Anfangszeichen aller Etiketten verwendet, die Steuerzuständen in dem Programmquellcode entsprechen. Gemäß der Erfindung identifiziert somit eine Programmanweisung, die das "@"-Etikett als Präfix enthält, einen Steuerzustand in dem Programmcode, wodurch die aktuelle Ausführung des ereignisgesteuerten Systems auf die Ankunft des nächsten Ereignisses wartet. Nach der Ankunft des nächsten Ereignisses folgt die Ausführung des nachfolgenden Programmcodes der Codierung der erforderlichen Reaktion auf dieses Ereignis und endet mit einem Übergang zu dem neuen, eindeutig definierten Steuerzustand. Offensichtlich können die Reaktion und der neue Steuerzustand für jedes verarbeitete Ereignis abhängig von Betriebsfragen, wie zum Beispiel etwaige im internen Tabellenkopf gespeicherte Zustandsinformationen, Variablen, Gerätereaktionen und dergleichen, unterschiedlich sein.
Fig. 4 zeigt ein Flußdiagramm beispielhafter Operationen für die Softwareentwicklung gemäß den Prinzipien der Erfindung. Genauer gesagt wird eine Spezifikation für das zu programmierende ereignisgesteuerte System z. B. von dem Systemtechniker definiert (Block 410). Für Fachleute ist erkennbar, daß eine solche Spezifikation eine Beschreibung der gesamten Anwendung, z. B. des ereignisgesteuerten Systems, liefert, für die ein Softwareprogramm geschrieben und implementiert werden soll. Aus der Systemspezifikation können die Steuerzustände zur Implementierung des entwickelten ereignisgesteuerten Systems identifiziert werden (Block 420), was wiederum zu der Identifizierung der Ereignisse, die erzeugt werden und erkannt werden müssen, und der Reaktionen auf die Ankunft bestimmter Ereignisse in bestimmten Zuständen führt. Dementsprechend wird gemäß der Erfindung die Definition, Strukturierung und Codierung (Block 430) des Quellcodeprogramms, wie bereits besprochen, in zwei Teile aufgeteilt, nämlich den steuerempfindlichen Code und den nichtsteuerempfindlichen Code.
Gemäß der Erfindung werden in dem das System definierenden steuerempfindlichen Code Steuerzustände mit einem einzigen Symbol eindeutig in dem gesamten derartigen Programmcode identifiziert. Wie bereits besprochen, wird gemäß der bevorzugten Ausführungsform der Erfindung das Symbol "@" als das Anfangszeichen aller Etiketten verwendet, die Steuerzuständen in dem steuerempfindlichen Teil des gesamten Programmquellcodes entsprechen. Gemäß der Erfindung identifiziert somit eine Programmanweisung mit dem "@"- Etikett als Präfix einen Wartezustand in dem Programmcode, in dem die aktuelle Ausführung des ereignisgesteuerten Systems auf die Ankunft des nächsten Ereignisses wartet. Außerdem betrifft der nicht-steuerempfindliche Code, der getrennt von dem steuerempfindlichen Code identifiziert wird, den notwendigen normalen sequentiellen Code zur Programmierung des ereignisgesteuerten Systems, wie zum Beispiel des Aufrufs von Gerätetreibern, der Steuerung von Peripheriegeräten, der Aktualisierung von Tabellen, variablen Definitionen usw.
Vorteilhafterweise ermöglicht die Erfindung dem Softwareentwickler, den Anwendungscode der ereignisgesteuerten Software so zu strukturieren, daß eine klare Unterscheidung zwischen Kernsteuermerkmalen, d. h. Zuständen, Ereignissen und Reaktionen, und belanglosen Einzelheiten getroffen wird, die sich nicht direkt auf das Verhalten des ereignisgesteuerten Systems auswirken. Somit besteht ein praktisches Ergebnis der Anwendung der Erfindung darin, daß der Programmierer den genauen Ausführungsfluß von Steuerzustand zu Steuerzustand direkt aus einer oberflächlichen Untersuchung des Programmcodes selbst bestimmen kann, da die einzelnen Steuerzustände einen starken visuellen Kontext aufweisen. Das heißt, der Programmguellcode wird gemäß der Erfindung so strukturiert und definiert, daß Steuerzustände, die die ereignisgesteuerte Anwendung definieren, eine direkte und logische, d. h. kausale Beziehung aufweisen, die unmittelbar aus einer Untersuchung des Quellcodes selbst ersichtlich ist. Signifikanterweise führt die vorliegende Erfindung zu weiteren Vorteilen bei der Prüfung und Verifizierung der ereignisgesteuerten Software (Block 440), um zu bestimmen, ob die Software die vom Benutzer spezifizierten gewünschten Eigenschaften erfüllt. Insbesondere wendet sich die vorliegende Erfindung an die Prüfung solcher ereignisgesteuerter Software, die nachfolgend ausführlicher besprochen wird.
Als Fortsetzung der Besprechung von "The Method and Apparatus For Developing Event Driven Software application" [Methode und Vorrichtung zum Entwickeln von ereignisgesteuerter Softwareanwendung], wie bereits erwähnt, ermöglicht diese Erfindung dem Softwareentwickler jedoch, den Anwendungscode der ereignisgesteuerten Software so zu strukturieren, daß eine klare Unterscheidung zwischen Kernsteuermerkmalen, d. h. Zuständen, Ereignissen und Reaktionen und belanglosen Einzelheiten, die sich nicht direkt auf das Verhalten des ereignisgesteuerten Systems auswirken, getroffen wird. Zum Beispiel zeigen Fig. 5, 5A, 6 und ein beispielhaftes C-Quelhcodeprogramm 500 (das durch die einzelnen Programmcodezeilennummern 1-258 abgegrenzt wird), das gemäß der Erfindung strukturiert und definiert wird, für die beispielhafte Telekommunikationsverbindungsbearbeitungsanwendung von Fig. 2, 2A, 3 und 3A. Insbesondere sind die Steuerzustände 510 bis 555 gemäß der bevorzugten Ausführungsform mit dem Symbol "@" als das Anfangszeichen aller Etiketten abgegrenzt, wodurch die Steuerzustände in dem steuerempfindlichen Teil des gesamten Quellcodeprogramms 500 gekennzeichnet werden. Somit besitzt das Quellcodeprogramm 500 gemäß der Erfindung eine direkte und logische, d. h. kausale, Beziehung zwischen den einzelnen Steuerzuständen, d. h. den Steuerzuständen 510-555. Signifikanterweise kann der Programmierer den genauen Ausführungsfluß von Steuerzustand zu Steuerzustand direkt aus einer oberflächlichen Untersuchung des Programmcodes selbst bestimmen, da die einzelnen Steuerzustände einen starken visuellen Kontext aufweisen.
Zum Beispiel kann man durch eine oberflächliche Untersuchung des Quellcodeprogramms 500 durch Betrachtung des Codes am Steuerzustand 535, d. h. des Steuerzustands "@digits" schnell und genau bestimmen, wie dieser bestimmte Steuerzustand erreicht wird. Das heißt, der Aufruf und die Ausführung dieses bestimmten ereignisgesteuerten Systems, d. h. die Verarbeitung einer abgehenden Verbindung, ein Steuerzustand zur Ermöglichung des Wählens von Ziffern auf einem Fernsprechgerät, wird verarbeitet. Der Steuerzustand 535 ist ein solcher Zustand und ist beginnend mit der Zeile 125 des Codes 500 gemäß der bevorzugten Ausführungsform der Erfindung klar identifizierbar. Bei der Betrachtung des Steuerzustands 535 kann man leicht sehen, daß der Ausführungsfluß bei der Erreichung dieses Steuerzustandes direkt durch die jeweiligen oben codierten Steuerzustände 510 bis 530 verläuft. Wenn das Quellcodeprogramm 500 revidiert werden muß, um einen anderen Steuerzustand hinzuzufügen, z. B. um eine bestimmte weitere anwendungsspezifische Funktionalität hinzuzufügen, kann der neue Steuerzustand außerdem an der exakten Stelle in der bestehenden Steuerzustandhierarchie plaziert werden, ohne den Kontext zwischen allen Steuerzuständen zu verlieren.
Diese logische. d. h. kausale, Beziehung zwischen Steuerzuständen und der klare Ausführungsfluß, der direkt aus der Betrachtung des Quellcodeprogramms 500 wahrnehmbar ist, sind in den Fig. 7, 7A, 8 und 8A, die ein übersetztes Quellcodeprogramm 700 zeigen, das von dem beispielhaften C-Quellcodeprogramm 500 der Fig. 5, 5A, 6 und 6A abgeleitet wurde, weiter ersichtlich. Wie bereits erwähnt, besteht gemäß der bevorzugten Ausführungsform der Erfindung die Erweiterung der Programmiersprache C des ANSI-Standards aus einem einzigen Symbol, das beispielsweise als das Symbol "@" gewählt und zur Etikettierung aller Steuerzustände in dem steuerempfindlichen Teil des Programmcodes verwendet wird. Die Mechanik, d. h. der Übersetzer, der eigentlichen Übersetzung des Codes selbst ist für Fachleute ohne weiteres ersichtlich. Das übersetzte Quellcodeprogramm 700 ist also die eigentliche vollständig übersetzte ANSI-Standard-C-Darstellung des ereignisgesteuerten Anwendungsprogramms gemäß der Erfindung. Zum Beispiel wird der Steuerzustand 515 (d. h. "@idle") von Fig. 5A in Programmcodeabschnitt 710 und der Steuerzustand 545 (d. h. "@ring") in Programmcodeabschnitt 720 übersetzt.
Die oben beschriebenen Vorteile der Erfindung in EP-A- 1 018 684 liefern signifikanten Nutzen in der Technik der Computerprogrammierung, insbesondere für die Definition, Strukturierung und Entwicklung ereignisgesteuerter Softwareanwendungsprogramme. Die effektive Prüfung und Verifizierung des Programmcodes gegen eine definierte Menge erwarteter Eigenschaften ist natürlich kritisch für die erfolgreiche Entwicklung jedes Anwendungsprogramms. Die verschiedenen Aspekte der vorliegenden Erfindung betreffen das Prüfen ereignisgesteuerter Software und werden nun ausführlicher besprochen.
Die verschiedenen Aspekte der vorliegenden Erfindung betreffen das effiziente Prüfen ereignisgesteuerter Software und das Bereitstellen der Möglichkeit, die Validität zukünftiger Änderungen des Programmcodes als Teil des normalen Wartungs-, Erweiterungs- und Revisionsprozesses des Quellcodes zu verfolgen. Fig. 9 zeigt ein Flußdiagramm beispielhafter Operationen zum Prüfen ereignisgesteuerter Software gemäß den Prinzipien der Erfindung. Genauer gesagt wird gemäß der bevorzugten Ausführungsform der Erfindung ereignisgesteuerter Softwarecode gemäß den Prinzipien der Erfindung in EP-A-1 018 684 spezifiziert und geschrieben, wie oben beschrieben.
Das heißt, gemäß der bevorzugten Ausführungsform wird das Quellcodeprogramm in einem steuerempfindlichen und nicht-steuerempfindlichen Format definiert und strukturiert (Block 910). Gemäß der Erfindung wird das ereignisgesteuerte Quellcodeprogramm durchlaufen, um die in dem Quellprogramm definierten Steuerzustände zu extrahieren und den Quellcode in ein Zwischen- Automatenformat umzusetzen (Block 920). Danach wird gemäß der Erfindung das Zwischen-Automatenformat in ein automatengestütztes Format für Modellierungsprüfzwecke umgesetzt.
Insbesondere wird gemäß der bevorzugten Ausführungsform das Zwischen-Automatenformat in ein kommentiertes Automatenmodell in der Eingabesprache eines spezifischen Modellprüfers umgesetzt (Block 940). Gemäß der bevorzugten Ausführungsform ist das Modellprüferwerkzeug der wohlbekannte Modellprüfer "SPIN", der von der Abteilung Bell Laboratories der Lucent Technologies Inc. entwickelt und von dieser verfügbar ist und ausführlicher z. B. in G. J. Holzmann, "The Model Checker SPIN", IEEE Trans. On Software Engineering, Band 23, Nr. 5, S. 279-295, Mai 1997, beschrieben wird. Insbesondere wird gemäß der Erfindung jede Anweisung aus dem Quellcodeprogramm auf eine Abstraktion in dem Automatenmodell abgebildet (Block 930). Die Abbildung, die unten ausführlicher besprochen wird, wird durch eine Übersetzungsabbildung erleichtert, die in der Anfangsphase des Verifizierungsprozesses definiert wird. Die Abbildung muß danach nicht revidiert werden, solange keine neuen Arten von Anweisungen in das Quellprogramm eingeführt werden, z. B. nachdem Revisionen vorgenommen wurden, um Programmierungsfehler zu reparieren. Die Abbildung schreibt u. a. eine feste Übersetzung der gegebenen Anweisung in die Zielsprache des Modellprüfers vor. Anweisungen, die in der Abbildung erscheinen, werden somit systematisch immer dort, wo solche Anweisungen in dem Quellcode erscheinen, in das Automatenmodell umgesetzt.
Zusätzlich zu der oben beschriebenen Abbildung wird gemäß der Erfindung ein sogenanntes Umgebungsmodell beispielsweise von einem Benutzer definiert, das eine minimale Menge von Annahmen einkapselt, die über die konkrete Betriebsumgebung, in der die ereignisgesteuerte Anwendung ausgeführt wird, getroffen werden müssen. Genauer gesagt wird das Umgebungsmodell angewandt (Block 975), während die Modellprüfereingabesprache dem Modellprüfer, z. B. SPIN, zugeführt wird (Block 950). Als Ergebnis erfolgt gemäß der bevorzugten Ausführungsform der Erfindung die Verifizierung der Eigenschaften des ereignisgesteuerten Systems unter Berücksichtigung des Umgebungsmodells während des Testens und Prüfens (Block 960) der ereignisgesteuerten Software durch den Modellprüfer. Danach werden die Test- und Prüfergebnisse auf wohlbekannte Weise von dem Modellprüfer ausgegeben (Block 970), um zu bestimmen, ob das ereignisgesteuerte System den gewünschten Ausführungseigenschaften und -verhaltensweisen des Benutzers entspricht.
Wichtig für das oben beschriebene Testen und Prüfen der ereignisgesteuerten Software ist gemäß der Erfindung das effiziente Durchlaufen des ereignisgesteuerten Quellcodeprogramms, um die in dem Quellprogramm definierten Steuerzustände zu extrahieren, und das Umsetzen des Quellcodes in ein Zwischen-Automatenformat (siehe z. B. Fig. 9, Block 920). Das heißt, um die Modellprüfung effizient durchzuführen, muß man in der Lage sein, die Steuerzustände, Ereignisse- und Aktionen (d. h. Reaktionen) des ereignisgesteuerten Systems zu identifizieren. Ein weiterer Aspekt der Erfindung betrifft somit ein von den Verfassern vorgelegtes Konzept einer formalen. Spezifikation, die die Beschreibung eines ereignisgesteuerten Systems für Modellprüfzwecke erleichtert, wie nun erörtert werden wird.
Gemäß diesem Aspekt der Erfindung wird ein Format definiert, das die Spezifikation eines ereignisgesteuerten Systems erleichtert. Gemäß verschiedenen Ausführungsformen der Erfindung (die später erörtert werden) kann die Spezifikation zum direkten Kompilieren und Ausführen in eine Zielprogrammiersprache, z. B. C, umgesetzt werden. Gemäß weiteren Ausführungsformen der Erfindung wird die Spezifikation unter Verwendung der oben beschriebenen Abbildung in ein logisches Verifizierungsmodell, wie zum Beispiel die Eingabesprache des SPIN- Modellprüfwerkzeugs, umgesetzt. Für Fachleute ist offensichtlich, daß Grammatikspezifikationswerkzeuge wohlbekannt sind. Zum Beispiel ist YACC (yet-anothercompiler-compiler) ein wohlbekanntes UNIX- Softwarehilfswerkzeug (siehe z. B. A. T. Schreiner, "Using C with curses, lex and yacc", Prentice-Hall Inc., Englewood Cliffs, NJ 07632, 1990), das Programmierer bei der Entwicklung von C-Routinen, die einen Eingabestrom analysieren und interpretieren, unterstützt und außerdem die Entwicklung von Compilern und Interpretern erleichtert. Ähnlich wie YACC liefert das vorliegende Spezifikationsformat einen Formalismus zur Beschreibung der Grammatik einer Sprache und zur Automatisierung eines Compilers für diese Sprache. Das vorliegende Spezifikationsformat gemäß der Erfindung betrifft jedoch die Spezifikation des Verhaltens des Systems.
Genauer gesagt lautet eine beispielhafte Grammatikdefinition gemäß der bevorzugten Ausführungsform der Erfindung - folgendermaßen:
event: STRING;
condition: STRING;
action: STRING;
source: STRING;
target: STRING "@" STRING;
Die obige beispielhafte Grammatikdefinition liefert einen Rahmen zum Definieren einer Spezifikation für eine bestimmte Anwendung z. B. eines ereignisgesteuerten Systems, gemäß den Prinzipien der Erfindung. Alle Elemente in der beispielhaften Grammatikdefinition, die in Anführungsstrichen erscheinen, sind Terminal-Symbole (Schlüsselwörter, Literals, Token). Das in Großbuchstaben geschriebene Wort STRING stellt eine alphanumerische Zeichenkette dar, und NUMBER stellt eine Folge von einer oder mehreren Ziffern dar. Alternativen werden durch einen vertikalen Strich " ", d. h. ein Pipe-Symbol, getrennt, und jede Grammatikregel wird mit einem Semikolon abgeschlossen.
Gemäß der bevorzugten Ausführungsform besteht das Spezifikationsformat aus zwei Teilen: einer Deklaration und einer Spezifikation. Der Deklarationsteil der Spezifikation der bevorzugten Ausführungsform enthält u. a. eine Auflistung symbolischer Namen für alle Ereignisse, die in der Spezifikation verwendet werden. Zum Beispiel ist das folgende Codefragment eine beispielhaft Deklaration gemäß der bevorzugten Ausführungsform:
In der obigen beispielhaften Deklaration sind alle Wörter, die mit einem Prozentsymbol "%" beginnen, Schlüsselwörter. Zum Beispiel definiert "%c_template" den Namen einer Datei, die eine Schablone für die letzte Implementierung des Codes in C, d. h. der Zielimplementierungssprache der bevorzugten Ausführungsform, enthält. Außerdem gibt die Anweisung %p_map" den Namen einer Datei an, womit eine Beziehung zwischen dem C-Code aus der Implementierung und den abstrakten Darstellungen des Codes, d. h. der Abbildung, die zur Verifizierung mit dem Modellprüfer verwendet werden, definiert werden kann. Außerdem enthält die obige beispielhafte Deklaration eine Auflistung von symbolischen Namen für alle Ereignisse, z. B. "%event Cranswer", die in der Spezifikation verwendet werden, sowie eine Liste von Zustandsnamen für alle Steuerzustände, z. B. "%state S_idle", in der Spezifikation.
Der Kern des Spezifikationsformats ist gemäß der Erfindung die Spezifikation einer Menge von Übergangsregeln für das ereignisgesteuerte System, wobei die Zustandsspezifikation aus einer Folge von Übergangsregeln besteht, die in der folgenden Notation spezifiziert werden:
Zum Beispiel ist das folgende Codefragment eine beispielhafte Steuerzustandsspezifikation gemäß der bevorzugten Ausführungsform:
Bei der obigen beispielhaften Steuerzustandsspezifikation beginnt die Übergangsregel mit dem Namen des Zustands, z. B. "S_idle", mit einem nachfolgenden Doppelpunkt. Nach dem Doppelpunkt wird eine Reihe möglicher Übergänge aus diesem Zustand aufgelistet. Die einzelnen Übergänge werden durch einen vertikalen Strich " " voneinander getrennt. Jeder abgeschlossene Übergang hat drei Teile: den Namen eines Ereignisses, das die Reaktion auslöst, den Namen eines neuen Zustands, der erreicht wird, nachdem die Reaktion durchgeführt wurde, d. h. "der nächste-Zustand", und die Reaktion selbst. Der nächster-Zustand-Teil der Spezifikation definiert, wohin sich die Steuerung bewegt, nachdem die Reaktion vollständig verarbeitet wurde, und enthält den Namen entweder eines vordefinierten Steuerzustands oder eines sogenannten internen Zustands. Wenn zwei Ereignisse denselben nächsten-Zustand und dieselbe Reaktion aufweisen, dann kann gemäß weiteren Ausführungsformen der Erfindung eine abgekürzte Notation verwendet werden, wie zum Beispiel:
Durch Verwendung der oben angeführten abgekürzten Notation erzeugen die Ereignisse Crflash, Crdis und Croffhook alle dieselbe Reaktion, d. h. die Ausführung des spezifizierten Codefragments und einen Übergang zum Zustand "S_idle".
Es ist erkennbar, daß das ereignisgesteuerte System in jedem Steuerzustand die Ausführung stoppen und auf die Ankunft des nächsten Ereignisses warten soll. Im Gegensatz dazu durchläuft das ereignisgesteuerte System die internen Zustände, ohne zu warten. Zusätzlich kann Zustandsnamen in dem nächster-Zustand-Segment einer Übergangsregel das "@"-Symbol vorangestellt werden (es sollte beachtet werden, daß diese bestimmte Notation nicht dieselbe ist, wie zuvor in Bezug auf die Identifikation von Steuerzuständen gemäß verschiedenen Aspekten der Erfindung in EP-A-1 018 684 beschrieben wurde), um anzuzeigen, daß die Verarbeitung des nächsten Zustands fortgesetzt werden sollte, ohne auf die Ankunft eines nächsten Ereignisses zu warten. In einem solchen Fall bleibt das letzte Ereignis verfügbar, wenn ein Ereignis benötigt wird, um das Verhalten des Systems in einem nächsten Zustand zu bestimmen.
Mit Bezug auf die obenerwähnten internen Zustände codieren solche Ereignisse eine interne, nicht mit dem Ereignis zusammenhängende Entscheidung des ereignisgesteuerten Systems. Gemäß der bevorzugten Ausführungsform der Erfindung ist die Syntax in der Spezifikation für interne Ereignisse dieselbe wie bei Steuerzuständen, mit der Ausnahme, daß anstelle von Ereignisnamen allgemeine Boolesche Bedingungen in der Zielimplementierungssprache verwendet werden. Ein beispielhafter interner Zustand wird zum Beispiel folgendermaßen definiert:
Der obige beispielhafte interne Zustand gibt an, daß der Wert eines spezifischen Felds (wobei in diesem Fall zwei Ebenen in einer C-Datenstruktur mit dem Namen "x" versteckt werden) entscheidet, ob die Steuerung in dem Zustand "S_otrunk" oder dem Zustand "S_idle_E6" läuft. Im ersten Fall wird das nach dem Zustand definierte Stück Aktionscode ausgeführt. Im letzteren Fall wird kein Code ausgeführt.
Wenn der Name eines Ereignisses oder einer Bedingung "else" ist, wird dadurch gemäß der bevorzugten Ausführungsform angezeigt, daß eine Vorgabereaktion unternommen wird, wenn keiner der explizit aufgelisteten Ereignisnamen oder keine der explizit aufgelisteten Booleschen Bedingungen anwendbar sind. Zum Beispiel kann das obige beispielhafte interne Zustandscodefragment auch folgendermaßen geschrieben werden:
Gemäß diesem alternativen internen Zustandscodefragment wird kein Codefragment ausgeführt, wenn die Bedingung "{x→drv→trunk}" als "falsch" ausgewertet wird, wenn dieser Zustand erreicht wird. Stattdessen ergibt sich nur ein Übergang in den Zustand "S_idle_E6".
Außerdem ist es in Bezug auf die Spezifikation des ereignisgesteuerten Systems manchmal nützlich, ein gemeinsames Aktionsfragment zu definieren, das unmittelbar im Anschluß an den Empfang eines Ereignisses in einem Steuerzustand ausgeführt werden muß. Definitionsgemäß muß ein solches Codefragment ausgeführt werden, bevor jedwede der Übergangsregeln angewandt werden. Gemäß der bevorzugten Ausführungsform der Erfindung wird das Schlüsselwort "onreceipt" verwendet, um solche gemeinsamen Aktionsfragmente zu definieren. Ein Beispiel für die Verwendung dieses Schlüsselworts lautet wie folgt:
Bei dem obigen beispielhaften Codefragment ist der Zustand ein interner Zustand, so daß er in einem nächster-Zustand-Segment immer mit dem Präfix "@" referenziert werden kann. Der Code "onreceipt" wird unmittelbar ausgeführt, wenn dieser Zustand bei einem Übergang erreicht wird, und die Bedingung "(y = = nil" wird ausgewertet. Wenn die Bedingung "wahr" ist, bewegt sich das System zu einem anderen internen Zustand mit dem Namen "S_orig_E54", und bei "falsch" bewegt sich das System in den internen Zustand "S_orig_E55", in dem die Verarbeitung fortgesetzt wird, ohne auf ein neues Ereignis zu warten.
Schließlich ist es in Bezug auf die Spezifikation manchmal nützlich, Bedingungsprüfungen völlig zu umgehen und einen Zwischenübergangszustand zu spezifizieren, der bedingungslos zu einem Nachtolgerzustand führt. Gemäß der bevorzugten Ausführungsform der Erfindung wird eine Bedingung, die immer wahr ist, durch das Schlüsselwort "always" dargestellt, wie in dem folgenden beispielhaften Codefragment dargestellt:
Das von den Verfassern vorgelegte Konzept der oben beschriebenen formalen Spezifikation bei der Beschreibung ereignisgesteuerter Systeme für Modellprüfzwecke liefert vorteilhafterweise ein Spezifikationsformat zur Beschreibung des Verhaltens eines ereignisgesteuerten Systems.
Um die verschiedenen Aspekte und Vorteile der Erfindung bei der Prüfung von ereignisgesteuerter Software weiter zu veranschaulichen, zeigen Fig. 10 und 10A Zwischen- Automatencode 1000 (der durch die einzelnen Programmcodezeilennummern 1-124 abgegrenzt wird), der gemäß den Prinzipien der Erfindung und wie oben besprochen aus der Quellcodeauflistung des bespielhaften C-Codeprogramms 500 von Fig. 5, 5A, 6 und 6A abgeleitet wird. Wie bereits besprochen, muß zur effektiven Durchführung der Modellprüfung an ereignisgesteuertem Code eine genaue Bewertung und Identifikation der Steuerzustände, Ereignisse und Aktionen stattfinden. Vorteilhafterweise liefert der Zwischen-Automatencode 1000 gemäß den Prinzipien der Erfindung eine klare Abgrenzung zwischen Steuerzuständen, Ereignissen und Aktionen. Genauer gesagt wird gemäß der bevorzugten Ausführungsform ein Übersetzer auf das O-Quellcodeprogramm 500 angewandt, um direkt Zwischen-Automatencode 1000 zu erzeugen. Die eigentliche Konstruktion des Übersetzers ist für Fachleute auf dem Gebiet der Computerprogrammierung ohne weiteres verständlich und muß hier nicht weiter besprochen werden. Durch Strukturieren des C- Quellcodeprogramms 500 gemäß der vorliegenden Erfindung wird jedoch die automatische Identifizierung der relevanten Steuerzustände, Ereignisse und Aktionen ermöglicht. Somit werden die Vorteile der hier beschriebenen vorliegenden Erfindung realisiert.
Genauer gesagt zeigt eine sorgfältig Untersuchung des Zwischen-Automatencodes 1000 eine klare Abgrenzung von Ereignissen (siehe z. B den Codeabschnitt 1010) und Steuerzuständen (siehe z. B. den Codeabschnitt 1020) des Deklarationsteils des Codes 1000. Außerdem ist die klare Wechselwirkung unter und zwischen solchen Ereignissen, Steuerzuständen und den damit zusammenhängenden Aktionen gemäß der Erfindung durch die verschiedenen Zustandsspezifikationen (siehe z. B. die Zustandsspezifikation 1030 bis 1050) in dem Zwischen-Automatencode 1000 gezeigt. Wie oben mit Bezug auf die Operationen von Fig. 9 beschrieben, wird gemäß der Erfindung der Zwischen-Automatencode 1000 zur Ausführung der Prüfung des betreffenden Programmcodes in die Modellprüfereingabesprache umgesetzt. Diese Umsetzung wird durch eine Übersetzungsabbildung erleichtert, die in der Anfangsphase des Verifizierungsprozesses definiert wird. Die Abbildung schreibt u. a. eine feste Übersetzung der konkreten Anweisung in die Zielsprache des Modellprüfers vor. Anweisungen, die in der Abbildung erscheinen, werden somit immer dort, wo solche Anweisungen in dem ursprünglichen Quellcode erscheinen, systematisch in das Automatenmodell umgesetzt.
Fig. 11 zeigt eine beispielhafte Abb. 1100 für das durch das beispielhafte C-Quellcodeprogramm 500 definierte ereignisgesteuerte System. Die Abb. 1100 besteht aus Programmcode 1110 (durch die einzelnen Programmcodezeilennummern 1-47 abgegrenzt), der definiert, wie die feste Übersetzung bestimmter Anweisungen in dem ursprünglichen Quellcode in die Zielsprache des Modellprüfers erfolgt. Insbesondere enthält der Programmcode 1110 Ereignisdefinitionen 1120 und Codedefinitionen 1130. Zum Beispiel bildet die Zeile 20 des Programmcodes 1110 jedes Mal, wenn die Anweisung in der linken Spalte erscheint, die Anweisung auf die in der rechten Spalte angegebene Abstraktion ab. Gemäß der Erfindung führt die Anwendung der Abb. 1100 zu der Ableitung der Modellprüfereingabesprache 1200 (durch einzelne Programmcodezeilennummern 1-303 abgegrenzt) von Fig. 12, 12A, 13, 13A und 13B. Außerdem wird gemäß der Erfindung eine Menge von in Fig. 14, 14A und 14B beispielhaft als Bibliotheksfunktionen 1400 gezeigte Menge von Bibliotheksfunktionen für die Modellprüfereingabesprache der Fig. 12, 12A, 13, 13A und 13B erzeugt. Es versteht sich, daß die Bibliotheksfunktionen 1400 (die durch die einzelnen Programmcodezeilennummern 1-153 abgegrenzt werden) die notwendige Semantik zur Definition von Begriffen in der Modellprüfereingabesprache 1200 liefern. Gemäß der bevorzugten Ausführungsform betrifft die Modellprüfereingabesprache 1200 das SPIN- Modellprüferwerkzeug und ist mit diesem nützlich.
Signifikanterweise ist ein wichtiges Merkmal der Verwendung von Abbildungen gemäß der Erfindung die Fähigkeit, die dem Benutzer beim genauen Definieren des entsprechenden Grades von Einzelheiten, auf den der Prüfprozeß angewandt wird, auf quellenunabhängige Weise geboten wird. Die Abbildung kann als Übersetzung (d. h. rechte Spalte des oben beschriebenen Programmcodes 1110) einer beliebigen Anweisung "true" oder "skip" enthalten, wodurch angezeigt wird, daß diese Einzelheiten wegabstrahiert werden. Deshalb wirkt, die Abbildung als ein "Filter", um überflüssige Einzelheiten herauszufiltern, neben der Wirkung als ein Umsetzer von der Zielprogrammiersprache (z. B. C) in das Verifizierungsmodell. Die Abbildung dient außerdem als eine vollständige Formalisierung der Verbindungen zwischen Quellcode und dem Verifizierungsmodell.
Wie bereits beschrieben erfolgt gemäß der bevorzugten Ausführungsform der Erfindung die Verifizierung der Eigenschaften des ereignisgesteuerten Systems unter Berücksichtigung eines Umgebungsmodells während des Testens und Prüfens (siehe Fig. 9, Block 975) der ereignisgesteuerten Software durch das Verifizierungssystem. Das Umgebungsmodell formalisiert bestimmte Annahmen des Benutzers über die Umgebung, in der der ereignisgesteuerte Programmcode ausgeführt werden soll. Zum Beispiel könnte im Fall der hier beschriebenen beispielhaften Telekommunikationsverbindungsbearbeitungsanwendung das Umgebungsmodell Formalisierungen enthalten, die das Teilnehmerverhalten, Hardwarereaktionen und die Kommunikationsnetzleistung betreffen. Insbesondere zeigt Fig. 15 ein beispielhaftes Umgebungsmodell 1500 (das durch die einzelnen Programmcodezeilennummern 1-70 abgegrenzt wird) für die in Fig. 5, 5A, 6 und 6A beschriebene Telekommunikationsbearbeitungsanwendung. Zum Beispiel beschreibt das Codefragment 1510 des Umgebungsmodells 1500 eine Formalisierung, d. h. eine Schablone, für ein Telekommunikationsgerät, das in der beispielhaften Telekommunikationsanwendung nützlich ist. Gemäß der bevorzugten Ausführungsform verwendet der Modellprüfer, d. h. SPIN, die Modellprüfereingabesprache 1200 in Verbindung mit dem Umgebungsmodell 1500, um zu bestimmen, ob das ereignisgesteuerte System den gewünschten Ausführungseigenschaften und -verhaltensweisen des Benutzers entspricht.
Vorteilhafterweise wird durch die getrennte Definition der Abbildung und des Umgebungsmodells gemäß der Erfindung sichergestellt, daß wenig oder gar nicht in der Verifizierungsinfrastruktur aktualisiert werden muß, wenn routinemäßige Änderungen an dem ursprünglichen Quellcode vorgenommen werden. Das heißt, solange keine neuen grundlegenden Typen von Anweisungen in den Quellcode eingeführt werden, kann der Verifizierungsprozeß ohne Eingriff des Benutzers wiederholt werden, und der Quellcode kann auf fortgesetzte Entsprechung gegen eine große Bibliothek wesentlicher Korrektheitseigenschaften geprüft werden. Außerdem wird gemäß der Erfindung ein präzises Automatenmodell, das den geprüften ereignisgesteuerten Code darstellt, automatisch direkt aus dem Quellcode erzeugt und mit einem Logikmodellprüfer, z. B. SPIN, verifiziert.
Zum Beispiel zeigt Fig. 16 ein beispielhaftes Automatenmodell 1600 für einen bestimmten Steuerzustand, der durch die in Fig. 5, 5A, 6 und 6A beschriebene Telekommunikationsbearbeitungsanwendung definiert wird. Genauer gesagt ist der in Fig. 16 abgebildete Steuerzustand der sogenannte "ring"- Steuerzustand, der in dem Quellcodeprogramm 500 als Steuerzustand 545 definiert ist (siehe Fig. 5, 5A, 6 und 6A). Die Programmanweisung "@ring" in Zeile 183 des Quellcodeprogramms 500 beginnt die klare Abgrenzung dieses bestimmten Steuerzustandes vom Quellprogrammstandpunkt aus gesehen. Gemäß den Test- und Prüfaspekten der Erfindung wird, wie oben beschrieben, aus diesem Steuerzustand ein genauer Automat, z. B. das Automatenmodell 1600, extrahiert. Das Automatenmodell 1600 zeigt deutlich die Übergänge in den und aus dem "ring"-Steuerzustand 1610 und zwischen anderen Steuerzuständen der Anwendung, d. h. dem Steuerzustand "digits_1" 1620, dem Steuerzustand "idle" 1630, dem Steuerzustand "conn" 1640 und dem Steuerzustand "error" 1650. Das Automatenmodell 1600 zeigt außerdem deutlich die verschiedenen Ereignisse, d. h. die Ereignisse 1660 bis 1695, die in der beispielhaften Anwendung auftreten. Außerdem ist das vollständige Automatenmodell 1700, das in Fig. 17 gezeigt wird, ein beispielhaftes vollständiges Automatenmodell der in Fig. 5, 5A, 6 und 6A beschriebenen und gemäß der Erfindung automatisch erzeugten vollständigen Telekommunikationsbearbeitungsanwendung.
Die oben beschriebenen Ausführungsformen der Erfindung verwenden ein C-Quellprogramm, das (siehe z. B. Fig. 5, 5A, 6 und 6a) gemäß den Prinzipien der EP-A-1 018 684 beschrieben und gemäß den Prinzipien der vorliegenden Erfindung wie oben beschrieben geprüft wird. Die Verfasser haben außerdem festgestellt, daß bestimmte Arten von Benutzern, z. B. Verifizierungssystemprogrammierer oder Softwareprüftechniker, möglicherweise ihren Systementwurfprozeß damit beginnen möchten, daß sie das ereignisgesteuerte System gemäß dem oben beschriebenen Spezifikationsformat definieren. Zum Beispiel könnten solche Benutzer das hier dargelegte Spezifikationsformat verwenden, um das betreffende ereignisgesteuerte System direkt zu codieren. Gemäß weiteren Ausführungsformen der Erfindung wird somit die Spezifikation zur direkten Kompilierung und Ausführung in eine Zielprogrammiersprache, z. B. C, umgesetzt. Gemäß solchen weiteren Ausführungsformen der Erfindung wird eine Schablone verwendet, um eine solche Umsetzung zu erleichtern. Es folgt eine beispielhafte C- Codeschablone zur Verwendung bei der Umsetzung dieses solchen Automatencodes in standardmäßiges C zur Kompilierung und Ausführung:
Die oben beschriebene C-Codeschablone liefert den Rahmen für eine vollständige Umsetzung der Automatenspezifikation in C. Es versteht sich, daß die beispielhafte C-Codeschablone von dem Modellprüferwerkzeug selbst oder auf einer separaten Maschine ausgeführt werden kann. Die Schablone enthält Typendefinitionen für die Argumente, die an eine als "state" bezeichnete Routine abgegeben werden, die als der Kern der Umsetzungsimplementierung verwendet wird. Die Routine muß immer dann aufgerufen werden, wenn ein Ereignis auftritt, das mit dem betreffenden ereignisgesteuerten System zusammenhängt. Der Schablonencode enthält ferner einen Platzhalter "@C" für den Automaten, der aus den gemäß der Erfindung spezifizierten Übergangsregeln erzeugt wird. Der tatsächliche Programmcode, der für die Erzeugung des Aastomaten notwendig ist, ist für Fachleute offensichtlich und muß nicht weiter besprochen werden.
Bei jedem Aufruf wird die Routine "start" ausgeführt und ruft einen Ereignistyp und einen Parameterwert aus der Datenstruktur ab, die von der Umgebung verwendet wird, um einzelne Informationen über das aktuelle Ereignis zu speichern. Der aktuelle Zustand des Prozesses wird in dem ersten Argument für die Routine aus der Datenstruktur abgerufen, und an diesem Zustandswert wird ein sogenannter "C-switch" ausgeführt, um die richtige Position in den Übergangsregeln festzustellen. Das Abkürzungssymbol "@@" der Schablone wird von dem Werkzeug zu einer vollen Liste von Namen aller Steuerzustände mit passenden Sprüngen zu den Stellen in dem erzeugten, d. h. umgesetzten, C-Code, in dem die Codefragmente für die Übergangsregeln jedes Zustands plaziert werden, expandiert. Vorteilhafterweise wird gemäß diesen weiteren Ausführungsformen der Erfindung die Spezifikation zur direkten Kompilierung und Ausführung in eine Zielprogrammiersprache, z. B. C, umgesetzt.
Zum Beispiel zeigt Fig. 18 ein beispielhaftes Computersystem 1800, das beim Ausführen und Prüfen von ereignisgesteuertem Softwarecode gemäß der vorliegenden Erfindung nützlich ist. Insbesondere enthält das Computersystem 1800 einen herkömmlichen PC 1810, der mit einer Anzeige 1820 und einer Tastatur 1830 verbunden ist. Es versteht sich, daß Informationen, die z. B. während der Ausführung von konkretem ereignisgesteuertem Softwarecode von dem PC 1810 erzeugt werden, auf der Anzeige 1820 angezeigt werden können, damit ein Benutzer des Computersystems 1800 auf diese zugreifen kann. Der Benutzer tritt als Ergebnis des Betrachtens der Anzeige 1820 in Dialog mit dem PC 1800 und steuert diesen auf herkömmliche Weise unter Verwendung der Tastatur 1830. Außerdem können eine Maus 1880 oder andere wohlbekannte Zeigegeräte dem Benutzer ermöglichen, zusätzliche Eingaben in den PC 1810 bereitzustellen. Das beispielhafte Computersystem 1800 enthält außerdem einen Prozessor 1840, der beispielsweise ereignisgesteuerten Anwendungssoftwarecode gemäß der vorliegenden Erfindung ausführt und prüft. Zum Beispiel könnte dieser ereignisgesteuerte Anwendungssoftwarecode über eine herkömmliche Diskette 1870 in den PC 1810 geladen und danach in dem internen Plattenspeicher 1860 gespeichert werden. Außerdem kann das Ausführen und Prüfen des Codes Zugang zu dem Direktzugriffsspeicher 1850 ("RAM") bzw. dessen Verwendung auf herkömmliche Weise erfordern. Somit kann der Benutzer des Computersystems 1800 gemäß der vorliegenden Erfindung Software ausführen und prüfen, um vielfältige Anwendungen, z. B. ein ereignisgesteuertes System bereitzustellen. Außerdem versteht es sich, daß das Computersystem 1800 zum Ausführen und Prüfen der gegebenen Anwendungsprogramme auf herkömmliche Weise mit anderen Computersystemen oder Geräten verbunden sein kann.
Zum Beispiel kann das Computersystem 1800 verwendet werden, um gemäß der vorliegenden Erfindung Software auszuführen und zu prüfen, so daß sich die Fehlerverfolgung 1900 (siehe Fig. 19) ergibt. Die Fehlerverfolgung 1900 besteht aus Programmcode 1900 (der durch die einzelnen Programmcodezeilennummern 1-47 begrenzt wird) und ist eine beispielhafte Fehlerverfolgung, die gemäß den Prinzipien der Erfindung für die in Fig. 5, 5A, 6 und 6A beschriebene Telekommunikationsbearbeitungsanwendung erzeugt wird. Genauer gesagt zeigt die beispielhafte Fehlerverfolgung 1900, wie der Prüfprozeß ein Szenario erzeugt, das das Vorliegen von Fehlern in dem ursprünglichen Quellcode des ereignisgesteuerten Systems direkt identifiziert. Außerdem identifiziert die Fehlerverfolgung 1900 durch den Programmcode 1910 solche Fehler im Hinblick auf Anweisungen auf der Programmierungsebene, z. B. Anweisungen der C-Ebene, die ausgeführt werden können, um den Fehler zu reproduzieren. Bei der beispielhaften Fehlerverfolgung 1900 zeigt die Verfolgung in einer direkten Folge von C-Programmcodeanweisungen (siehe Fig. 9, Programmcode 1920) Ausführungen, die das ereignisgesteuerte System in den beispielhaften Zustand "@busy" führt, wobei "Crdigit" das erste zu verarbeitende Ereignis ist. Wie aus der Fehlerverfolgung 1900 in Verbindung mit dem C- Quellprogrammcode 500 (insbesondere dem Steuerzustand 555 auf Zeile 223) ersichtlich und erkennbar ist, bestehen in dem Programmcode keine Vorkehrungen, d. h. ein Codierungsfehler, um das mögliche Auftreten dieses Ereignisses zu antizipieren. Vorteilhafterweise kann ein Benutzer gemäß der Erfindung die Fehlerverfolgung 1900 ausschließlich im Hinblick auf Ausführungsanweisungen der. C-Ebene interpretieren, ohne über jegliches Spezialwissen über das Modell selbst oder signifikante Teile der Zwischendarstellungen, die in dem Prüfprozeß selbst verwendet werden, zu verfügen.
Im obigen wurden lediglich die Prinzipien der vorliegenden Erfindung veranschaulicht. Es versteht sich somit, daß Fachleute in der Lage sein werden, verschiedene Anordnungen zu konzipieren, die hier zwar nicht explizit beschrieben oder gezeigt wurden, aber dennoch die Prinzipien der vorliegenden Erfindung realisieren und in ihrem Schutzumfang eingeschlossen sind. Außerdem sollen alle Beispiele und die Bedingungssprache, die hier angeführt wurden, hauptsächlich nur pädagogischen Zwecken dienen, um dem Leser das Verständnis der Prinzipien der Erfindung und der vom Anmelder bzw. den Anmeldern beigetragenen Konzepte zur Erzielung eines Fortschritts in der Technik zu erleichtern, und sollten nicht als auf solche spezifisch angeführten Beispiele und Bedingungen beschränkt aufgefaßt werden.

Claims

1. Software-Prüfverfahren, das an einem Quellprogramm (910) der Software ausgeführt wird, wobei das Quellprogramm eine Vielzahl von Befehlen enthält,

gekennzeichnet durch die folgenden Schritte:

Durchlaufen des Quellprogramms (920), um eine Vielzahl von Steuerzuständen zu identifizieren, und Umsetzen des Quellprogramms in ein Automatenformat;

Anwenden einer Übersetzungsabbildung (930, 1100) auf die Vielzahl von Befehlen des Quellprogramms zur Umsetzung des Automatenformats (940) des Quellprogramms in ein Verifizierungsprogramm; und

Prüfen der Software (960) in einem Verifizierungswerkzeug unter Verwendung des Verifizierungsprogramms, wobei das Prüfen der Software folgendes umfaßt:

Anwenden eines Umgebungsmodells (975, 1500) in Verbindung mit dem Verifizierungsprogramm; wobei das Umgebungsmodell bestimmte Aspekte einer Betriebsumgebung für die Ausführung der Software darstellt.

2. Software-Prüfverfahren nach Anspruch 1, wobei das Quellprogramm folgendes enthält: ein erstes Quellcodesegment zum Bewirken, daß ein Computer ein ereignisgesteuertes System ausführt; wobei das erste Quellcodesegment eine erste Vielzahl von Befehlen, die die Vielzahl von Steuerzuständen definiert, wobei die Vielzahl von Steuerzuständen dem ereignisgesteuerten System zugeordnet ist, eine zweite Vielzahl von Befehlen, die eine Vielzahl von Ereignissen des ereignisgesteuerten Systems definiert, und eine dritte Vielzahl von Befehlen, die eine Vielzahl von Aktionen des ereignisgesteuerten Systems definiert, enthält, wobei jeder Steuerzustand der Vielzahl von Steuerzuständen eine einzelne Kennung in der ersten Vielzahl von Befehlen des ersten Quellcodesegments aufweist, wobei die einzelne Kennung ein Programmierungssymbol ist, das allen identifizierten Steuerzuständen gemeinsam ist, und ein zweites Quellcodesegment, das mindestens eine Vielzahl von Befehlen enthält, die eine sequentielle Steuerung des Computers definiert, auf dem das ereignisgesteuerte System ausgeführt wird.

3. Software-Prüfverfahren nach Anspruch 1 oder Anspruch 2, wobei die Übersetzungsabbildung eine Vielzahl von Abbildungsbefehlen enthält.

4. Software-Prüfverfahren nach Anspruch 3, wobei das Anwenden der Übersetzungsabbildung die folgenden Schritte umfaßt:

Vergleichen der Vielzahl von Abbildungsbefehlen mit der Vielzahl von Befehlen des Quellprogramms, um eine Übereinstimmung zu erkennen; und

Umsetzen bestimmter der Abbildungsbefehle, die mit bestimmten der Befehle des Quellprogramms übereinstimmen, in die Eingabesprache des Modellprüfers.

5. Software-Prüfverfahren nach einem der vorhergehenden Ansprüche, wobei das Umgebungsmodell eine Vielzahl von Betriebsattributen des ereignisgesteuerten Systems enthält.

6. Software-Prüfverfahren nach einem der vorhergehenden Ansprüche, wobei das Verifizierungswerkzeug ein Modellprüferwerkzeug ist.

7. Software-Prüfverfahren nach Anspruch 6, wobei das Modellprüferwerkzeug ein SPIN-Modellprüferwerkzeug ist.

8. Software-Prüfverfahren nach einem der vorhergehenden Ansprüche, wobei das ereignisgesteuerte System eine Telekommunikationsdienstanwendung ist, wobei die Telekommunikationsdienstanwendung mindestens ein Ereignis aufweist, das dem Weiterleiten einer Fernsprechverbindung durch ein Kommunikationsnetz zugeordnet ist.

9. Software-Prüfverfahren nach einem der vorhergehenden Ansprüche, wobei das Automatenformat mit einer von einem Benutzer definierten Spezifikation umgesetzt wird.

10 Software-Prüfverfahren nach einem der vorhergehenden Ansprüche, weiterhin mit den folgenden Schritten:

Kompilieren des ersten Quellcodesegments und des zweiten Quellcodesegments zu einem Objektprogramm; und

Ausführen des Objektprogramms, um das ereignisgesteuerte System bereitzustellen.

11. Software-Prüfverfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt des Prüfens mindestens eine Menge von Eigenschaften enthält, die von einem Benutzer definiert werden, der der Ausführung des ereignisgesteuerten Systems zugeordnet ist.

12. Software-Prüfverfahren nach Anspruch 11, wobei die Übersetzungsabbildung von dem Benutzer spezifiziert wird.

13. Software-Prüfverfahren nach Anspruch 11, wobei die Übersetzungsabbildung, das Umgebungsmodell und die Reihe von Programmierbefehlen jeweils in der Programmiersprache C geschrieben sind.

14. Software-Prüfverfahren nach einem der vorhergehenden Ansprüche mit dem Schritt des Anzeigens eines Ergebnisses der Prüfung der Software.

15. Software-Prüfverfahren nach Anspruch 14, wobei das angezeigte Ergebnis mindestens eine volle Automatendarstellung des ereignisgesteuerten Systems enthält.

16. Software-Prüfvorrichtung (1800) mit Mitteln (1100, 1500, 1820, 1840, 1850, 1870), die so ausgelegt sind, daß sie jeden Schritt eines Verfahrens nach einem der vorhergehenden Ansprüche ausführen.

17. Vorrichtung nach Anspruch 16, wobei das Mittel zum Ausführen des Verfahrens einen Computer (1800) mit mindestens einem Speicher (1850) umfaßt; wobei die Vorrichtung weiterhin ein Mittel (1870) zum Empfangen eines Quellprogramms von zu prüfender Software aufweist und in dem Speicher eine Reihe von Befehlen einer Programmiersprache umfaßt.

18. Maschinenlesbares Medium, auf dem eine Vielzahl von Befehlen gespeichert ist, wobei die Vielzahl von Befehlen Befehle enthält, die, wenn sie von einer Maschine ausgeführt werden, bewirken, daß die Maschine ein Verfahren nach einem der Ansprüche 1 bis 15 durchführt.