Die vorliegende Erfindung bezieht sich auf eine Verarbeitungseinrichtung und ein Verfahren zum Testen von Ursprungsbefehlen für eine Telekommunikations-Vermittlungsvorrichtung.

In den vergangenen Jahren wurde erkannt, daß die Modifikationen von Steuerbefehlen in größeren Systemen in keiner Weise eine einfache Angelegenheit ist, und über die Jahre wurden verbesserte Techniken zur Konstruktion großer Sammlungen von Befehlen für den Betrieb in Echtzeit in Umgebungen entwickelt, in denen Fehler zu größeren Systemausfällen führen könnten.

In vielen Fällen wurde ein erheblicher Aufwand an Zeit und Geld bei der Entwicklung von Steuerbefehlen aufgewandt, und obwohl es oft wünschenswert ist, Aktualisierungen durchzuführen, ist es auch wünschenswert, einen maximalen Nutzen aus vorhandenem Code zu ziehen. Obwohl der Umfang vorhandener Befehlesätze groß ist und in vielen Fällen nicht modernen Entwicklungstechniken entspricht, ergibt dies als solches zwei deutliche Vorteile. Erstens existiert der Code und erfordert keine zusätzlichen Investitionen zu seiner Schaffung. Zweitens ist der Code aufgrund der Tatsache, daß er allgemein über mehrere Jahre im Betrieb war, geprüft und getestet.

Für einen Betriebsverwalter, der vorhandene Systeme ausnutzt, werden die zugehörigen Befehle als von großem Wert betrachtet, und dies wird in vielen Fällen als "Erb"-Code bezeichnet. Für den Entwicklungs-Ingenieur ergibt der vorhandene Code jedoch größere Probleme, weil er im allgemeinen modernen Techniken und modernen Verfahren nicht entspricht. Insbesondere wurde in den letzten Jahren festgestellt, daß objektorientierte Umgebungen für die Definition von Telekommunikations-Funktionalitäten besonders geeignet sind, und zwar aufgrund ihrer eigenen Modularität. Entwicklungs-Ingenieure neigen daher dazu, vorhandene frühere Befehlssätze nicht in einem derartigen leuchtenden Licht zu sehen, und sie neigen dazu, sie als "Erbe" zu betrachten, das toleriert werden muß, statt daß dieses Erbe gewürdigt wird.

Wenn man einem überkommenen System dieser Art gegenübersteht, ist es nicht ungewöhnlich, daß es sich hierbei um mehrere Millionen von Zeilen von ausführbaren Anweisungen und Befehlen handelt, und Wartungsingenieure müssen eine von zwei klaren Strategien übernehmen.

Erstens könnten sie weiter in der von ihren Vorgängern erwarteten Weise arbeiten. Somit würden sie weiterhin die früheren Techniken verwenden und Systeme gemäß der erprobten und vertrauten Verfahren entwickeln. Die zweite Option würde darin bestehen, effektiv die gesamten überkommenen Befehle zu verwerfen und neu zu beginnen, wobei jede der Moduleinheiten gemäß moderner objekt-orientierter Techniken definiert würde. Obwohl dies attraktiv zu sein scheint, würde eine derartige Strategie als solche verschiedene Gefahren bergen. Erstens ist es möglich, daß die erforderliche Investition zu groß sein würde, wodurch sich eine nicht annehmbare Belastung hinsichtlich der Entwicklungskosten ergeben würde. Zweitens ist es wahrscheinlich, daß die Systeme in Schnittstellenverbindung mit anderen Systemen treten müssen, so daß es nicht vollständig möglich sein würde, alle überkommenen Systeme außer acht zu lassen, weil sie einer anderen Partei gehören können. Drittens würde ein größeres Neuschreiben aller Befehle und Anweisungen eine erhebliche Zeit erfordern. Es ist daher möglich, daß zu Beginn eines Entwicklungsvorganges übernommene Prozeduren und Verfahren sehr schnell überholt sein können, obwohl sie zu ihrer Zeit modern sind.

Es ist in vielen Fällen möglich, modifizierte und verbesserte Befehlsmodule vorhandenen großen Befehlssätzen hinzuzufügen. Um dies zu tun, ist es jedoch erforderlich, genau die Art und Weise zu spezifizieren, wie das neue Modul mit vorhandenen Modulen in Schnittstellenverbindung treten muß. Weiterhin ist es nach Abschluß der Entwicklung eines neuen Moduls erforderlich, es zu testen, bevor es tatsächlich in Betrieb geht. Das Testen wird vorzugsweise automatisch mit großer Geschwindigkeit ausgeführt, doch ist es erforderlich, geeignete Testroutinen zu entwickeln, die in manchen Fällen als Testfälle bezeichnet werden.

Die Veröffentlichung International Switching Symposium - Paper C10.2, Bd. 2, Oktober 1992, Yokohama (JP), S. 439-443, XP000337756 von Rouger et al mit dem Titel "Test cases generation from formal specifications", insbesondere S. 441, Abs. 4, zeigt Verfahren zur Erzeugung von Testfällen und Probleme, die mit derartigen Verfahren verbunden sind. Bei einer Lösung, die auf SDL beruht, wird ein globales Systemverhalten mehrerer Module bestimmt, es werden Pfade aus dem Systemverhalten abgeleitet, und die Pfade werden zwischen externen Schnittstellen aufgeteilt. Es findet sich jedoch keine Beschreibung der Bestimmung von Schnittstellen-Spezifikationen von einzelnen Modulen oder Moduleinheiten.

Die US-4617613 zeigt ein System zum Prüfen eines Kommunikationssystems mit einer Nachrichten-basierten Architektur. Ein Nachrichten-Dienstprogramm erzeugt, manipuliert und überprüft Anworten auf Folgen von Nachrichten, die zwischen einem Steuersystem und dem gesteuerten Netz weitergeleitet werden. Das Nachrichten-Dienstprogramm erzeugt jedoch Nachrichten auf der Grundlage von Skripten, die von einem Bediener in einer Hochsprache eingegeben werden, so daß eine erhebliche manuelle Eingabe erfolgen muß, und es wird keine Beschreibung der Bestimmung von Schnittstellen-Spezifikationen von Modulen gegeben.

Gemäß einem ersten Gesichtspunkt der vorliegenden Erfindung werden Verarbeitungseinrichtungen geschaffen, wie sie im Anspruch 1 angegeben sind.

Vorzugsweise umfassen die Verarbeitungseinrichtungen Umwandlungseinrichtungen zur Umwandlung der Testprozeduren in Steuerbefehle zum Aufrufen des geprüften Moduls.

Bei einer bevorzugten Ausführungsform schließt die Testprozedur- Generatoreinrichtung Einrichtungen zur Definition von Schnittstellenpfaden und jeweilige Bedingungen ein, die für die Aktivierung der Pfade erforderlich sind.

Gemäß einen zweiten Gesichtspunkt der vorliegenden Erfindung wird ein Verfahren gemäß Anspruch 4 geschaffen.

Die Erfindung wird nunmehr lediglich in Form eines Beispiels unter Bezugnahme auf die beigefügten Figuren beschrieben, in denen:

Fig. 1 ein Telekommunikationsnetz unter Einschluß von Telefonen und Telekommunikationsvermittlungen zeigt,

Fig. 2 Einzelheiten der Konstruktion einer Telekommunikationsvermittlung der in Fig. 1 gezeigten Art unter Einschluß von Steuerungseinrichtungen zeigt,

Fig. 3 weitere Einzelheiten des Telekommunikationsnetzes nach Fig. 1, unter Einschluß eines Steuerungssystems zeigt,

Fig. 4 Einzelheiten von Ebenen einer Multiplex-Funktionalität zeigt, die in dem Steuerungssystem nach Fig. 3 enthalten sind,

Fig. 5 Einzelheiten von Funktionalitäts-Moduleinheiten zeigt, die in dem Steuerungssystem nach Fig. 3 enthalten sind,

Fig. 6 Einzelheiten von Schritten angibt, die ausgeführt werden, um ein Steuerungssystem der in Fig. 3 gezeigten Art auszuführen, unter Einschluß der Spezifizierung einer Modul- Schnittstelle und der Erzeugung von Testfällen,

Fig. 7 Einzelheiten von Schritten zeigt, die durchgeführt werden, um den Prozeß der Spezifizierung einer Modul- Schnittstelle auszuführen, die in Fig. 6 gezeigt ist,

Fig. 8 Einzelheiten von Schritten zeigt, die zur Ausführung des Prozesses der Erzeugung von Testfällen gemäß Fig. 6 erforderlich sind, unter Einschluß eines Verzweigungsüberdeckungs-Prüfverfahrens und einer Grenzwertanalyse,

Fig. 9A Einzelheiten einer Knotenschaubilddarstellung einer Schnittstellen-Spezifikation zeigt, die in dem Prozeß der Spezifizierung einer in Fig. 6 gezeigten Modul-Schnittstelle erzeugt wird,

Fig. 9B Einzelheiten von zwei Schritten zeigt, die zur Ausführung des Prozesses des Verzweigungsüberdeckungs-Prüfverfahrens nach Fig. 8 verwendet werden, unter Einschluß eines ersten Schrittes und eines zweiten Schrittes,

Fig. 9C Einzelheiten der Ausführung des ersten Schrittes nach Fig. 9B zeigt,

Fig. 9D Einzelheiten der Ausführung des zweiten Schrittes nach Fig. 9B zeigt,

Fig. 10A, 10B und 100 das Verfahren der Erzeugung von Werten aus der Grenzwertanalyse nach Fig. 8 zeigen,

Fig. 11 eine Verhaltensmatrix zeigt, die bei der Korrelation der Vorbedingungen und Nachbedingungen verwendet wird, und

Fig. 12 und Fig. 13 ein Verfahren der Interpretation der Verhaltensmatrix nach Fig. 11 zeigen.

Eine klassische Telekommunikationsumgebung ist in Fig. 1 gezeigt, in der eine Vielzahl von Analogtelefonen 101 mit einer örtlichen Vermittlung 102 über jeweilige Kommunikationsverbindungsstrecken 103 in Form eines verdrillten Paares von Kupferleitern verbunden sind. Die Ortsvermittlung oder örtliche Vermittlung 102 ist weiterhin mit anderen ähnlichen Vermittlungen 104, 105 und 106 verbunden, und bei einem tatsächlich verwendeten Netz könnte die Anzahl der örtlichen Vermittlungen, die zu dem Netz zusammengeschaltet sind, tatsächlich sehr groß sein und große geographische Bereiche überdecken.

Die örtlichen Vermittlungen sind über Fernleitungskabel 107 verbunden und traditionell wurden diese Fernleitungen ebenfalls in Form von Kupferleiterkabeln ausgebildet. Entsprechend waren die Kosten zur Herstellung dieser gesamten Verkabelung sehr erheblich und stellten einen erheblichen Anteil der Gesamtkosten des Netzes dar. Die Gesamtkosten der Vermittlungsvorrichtung waren relativ niedrig, so daß höhere Investitionen in dieser Vorrichtung in dem Bestreben vorgenommen werden konnten, den Wirkungsgrad des zur Verfügung stehenden Kabels zu einem Maximum zu machen. Dies führte zu der Frequenzmultiplextechnik, um auf diese Weise die Anzahl von Kommunikationskanälen zu vergrößern, die entlang einer gemeinsamen physikalischen Verbindungsstrecke übertragen werden könnten.

Die Fähigkeit, die Anzahl der durch eine einzige physikalische Verbindungsstrecke gebildeten Übertragungspfade zu vergrößern, wurde in den 1970er Jahren durch die Verwendung digitaler Übertragungstechniken verbessert, die die Kombination vieler pulscodemodulierter Signale durch ein Verfahren der Byte-Multiplexierung ermöglichten. Somit konnte ein 4-kHz-Analog-Telefon signal als ein digitaler Bitstrom mit 64 Kilobit pro Sekunde dargestellt werden, worauf dreißig dieser Kanäle miteinander zusammen mit der Zeichengabe-Information kombiniert werden konnten, um ein Multiplexsignal mit 2,048 Megabit pro Sekunde zu schaffen.

Um die digitale Übertragung dieser Art zu erleichtern, wurden die Charakteristiken der Vermittlungen, wie zum Beispiel der Vermittlungen 102, 104, 105 und 106 in Fig. 1, zunehmend kompliziert und es wurden umfangreiche Schaltungsentwürfe erforderlich, um Plattformen zu schaffen, die ihrerseits den erforderlichen Funktionalitätsgrad zur Verfügung stellen konnten. Somit mußten örtliche Vermittlungen nicht mehr nur den Vermittlungsmechanismus für Analogsignale bilden, sondern sie mußten eine Analog-/Digital-Wandlung, eine Zeitkopplung zusätzlich zur Raumkopplung und eine Multiplexierung, soweit erforderlich, zur Übertragung über im Multiplexbetrieb betriebene Fernkabel ermöglichen.

Es wurde bald erkannt, daß der Grad der Multiplexierung vergrößert werden konnte, und Normen wurden zur Übertragung mit 140 Megabit pro Sekunde und 565 Megabit pro Sekunde festgelegt, wodurch sich effektiv eine tiefe Hierarchie von verfügbaren Bitraten ergab.

Die Übertragung digitaler Daten über erhebliche Bandbreiten ermöglichte die Einfügung anderer Kommunikationsdienste in ein Netz, das ursprünglich ausschließlich für die Übertragung von eine relativ geringe Bandbreite aufweisenden Sprachsignalen vorgesehen war. Sobald festgestellt wurde, daß eine Sondergebühr für die Datenübertragung dieser Art erhoben werden konnte, begann das Rennen nach der Ausbildung von Verbindungspunkten innerhalb vorhandener Netze zu kommerziellen Zwecken. Damit wurde es zusätzlich zu Sprachtelefonen, die über vermittelte Telefonnetze miteinander verbunden wurden, möglich, Datenverarbeitungsgeräte miteinander zu verbinden, die durch große geographische Entfernungen voneinander getrennt waren, wodurch der Gesamtdatenfluß zwischen voneinander entfernten Stellen beträchtlich vergrößert wurde. Dieser Prozeß wurde weiter durch die Einführung synchroner Übertragungssysteme verbessert, was andererseits die Schaffung von Datenanschlüssen mit vielen unterschiedlichen Datenraten erleichterte, ohne daß die Gesamtintegrität der Multiplexier- und Übertragungssysteme unterbrochen wurde. Dies führte andererseits zu einer starken Erweiterung der Anzahl von Diensten, die in dem Netz geschaffen werden konnten, sowie dem Intelligenzgrad, der innerhalb des Netzes eingebettet werden konnte. Die Beibehaltung von festverdrahteten Vermittlungs-Teilsystemen hätte effektiv zu einer Stagnation dieses Erweiterungsvorganges geführt, und es wurde daher unvermeidbar, daß Vermittlungssysteme dieser Art durch anpaßbare programmierbare Systeme ersetzt wurden, in denen Allzweck-Hardware-Vermittlungskoppelvielfache in Abhängigkeit von ausführbaren Befehlen konfiguriert werden konnten. Somit können bezüglich des Vermittlungs-Teilsystems örtlich ausführbare Befehle als die Mittel betrachtet werden, durch die eine Vermittlungsfunktionalität, in Ausdrücken tatsächlicher Hardwarekomponenten, konfiguriert wird, um auf diese Weise einen System-Funktionalitätsgrad innerhalb der Netzumgebung zu schaffen.

Ein typisches Vermittlungs-Teilsystem, das unter diesen Bedingungen arbeitet, ist in Fig. 2 gezeigt. Eine Vermittlungsmatrix oder ein Koppelvielfach 201 empfängt Eingangskanäle 202 von einer Demultiplexierungs-Einrichtung 203. Die Demultiplexierungs-Einrichtung 203 empfängt ihrerseits Signale von Fernkabeln 204, die jeweils zur Übertragung einer Vielzahl von multiplexierten Signalen ausgebildet sind.

Jede dem Koppelvielfach 201 zugeführte Leitung 202 schließt ein Dreißig-Kanal-Zeitmultiplex ein und innerhalb des Koppelvielfachs 201 erfolgt eine Zeitvielfachkopplung, in der die Positionen der Zeitschlitze neu angeordnet werden und der die Raumlagenvielfachkopplung so erfolgt, daß innerhalb eines bestimmten Multiplexsignals übertragene Daten zu einem anderen Multiplexsignal vermittelt werden. Danach werden die vermittelten Zeitvielfach-Multiplexsignale einer Neu-Multiplexierungsschaltung 205 zugeführt, die ihrerseits Ausgänge an Fernleitungen 206 liefert, die digitale Multiplexsignale höherer Ordnung übertragen.

Das Koppelvielfach 201 selbst enthält alle die physikalischen Elemente, die zur Durchführung der Vermittlungsoperationen erforderlich sind. Die tatsächlichen Vermittlungsoperationen werden als solche unter der Steuerung einer zentralen Steuerungsvorrichtung 207 ausgeführt, die ihrerseits so ausgebildet ist, daß sie Steuerbefehle und -anweisungen ausführt und Steuersignale an das Koppelvielfach 201 über Steuerleitungen 208 liefert.

Digitale Vermittlungs-Teilsysteme der in Fig. 1 gezeigten Art ermöglichen den Aufbau von Telekommunikationsnetzen, wie dies in Fig. 3 gezeigt ist. So ist in Fig. 3 eine örtliche Vermittlung 301 der örtlichen Vermittlung 102 nach Fig. 1 ähnlich. In gleicher Weise können Telefone 302 und 303 identisch zu den in Fig. 1 gezeigten Telefonen 101 sein und mit der örtlichen Vermittlung 301 über verdrillte Analog-Aderpaare in Kommunikationsverbindung stehen. An der örtlichen Vermittlung werden die Analogsignale jedoch in Digitalsignale umgewandelt, wodurch die Übertragung über Fernleitungskabel, wie zum Beispiel das Fernleitungskabel 304, in Form eines Zeitmultiplexsignals erleichtert wird.

Sofern die örtliche Vermittlung 301 in einer digitalen Umgebung arbeitet, ist sie weiterhin so konfiguriert, daß sie mit digitalen Telefonen 305 in Kommunikation steht. Diese digitalen Telefone sind über digitale Kommunikationskanäle 306 mit einer Wählsterneinrichtung oder einem Leitungskonzentrator 307 verbunden. So sind in dem in Fig. 3 gezeigten Beispiel fünf digitale Telefone 305 mit dem Leitungskonzentrator 304 verbunden, doch sind lediglich drei digitale Leitungen 308 zur Verbindung des Leitungskonzentrators 307 mit der örtlichen Vermittlung 301 vorgesehen. An der örtlichen Vermittlung 301 werden von den Telefonen 302 und 303 empfangene Analogsignale in Digitalsignale umgewandelt und mit digitalen Signalen von dem Leitungs konzentrator 307 derart kombiniert, daß von dem Standpunkt des übrigen Netzes die Signale effektiv äquivalent sind.

Das Fernleitungskabel 304 ist in dem in Fig. 3 gezeigten Beispiel so angeordnet, daß es ein Dreißigkanal-Multiplexsignal überträgt. Dieses Kabel wird jedoch einer Zwischenvermittlung 309 zugeführt, die so ausgebildet ist, daß sie ähnliche Multiplexsignale, wie zum Beispiel über die Leitung 316 empfängt, und danach diese Multiplexsignale in eine höhere Multiplexierungsstufe zur Übertragung über ein Fernleitungskabel 311 kombiniert. In ähnlicher Weise kann eine weitere Konzentrationsebene an einer zwischengeschalteten Vermittlungsstation 312 vorgesehen sein, die ihrerseits eine noch höhere Multiplexierungsstufe zur Übertragung über ein Fernleitungskabel 313 ergibt. Weiterhin können bis zu diesem Konzentrationsgrad multiplexierte Signale Mikrowellen-Übertragungsstrecken zugeführt werden, die durch eine Mikrowellen-Parabolantenne 314 dargestellt sind.

Die von der in Fig. 3 gezeigten Konfiguration durchgeführte Multiplexierung ist synchron, so daß es möglich ist, eine 2-Megabit-Verbindungsstrecke zu einer Datenverarbeitungseinrichtung 315 über eine direkte digitale Datenkommunikationsverbindung 316 zu schaffen. Somit kann an der zwischengeschalteten Vermittlung 309 das an der Datenverarbeitungsstation 315 empfangene digitale Multiplexsignal in einer im wesentlichen ähnlichen Weise wie die Sprachmultiplexsignale betrachtet werden, die an den Kommunikations-Fernleitungen 314 und 310 empfangen werden.

In ähnlicher Weise kann die zwischengeschaltete Vermittlung 312 eine noch höhere digitale Bandbreite, beispielsweise 64 Megabit pro Sekunde, an ein Hochleistungs-Datenverarbeitungssystem 317 über eine direkte digitale Verbindungsstrecke 318 ergeben. An der digitalen Vermittlung 312 werden wiederum über den Kommunikationspfad 318 empfangene Daten im wesentlichen in der gleichen Weise betrachtet, wie die Multiplexsignale, die von der Vermittlung 309 über die Fernleitung 311 empfangen werden.

Die Fähigkeit zur Rekonfiguration der Funktionalität der einzelnen Betriebs-Teilsystem, in Abhängigkeit von ausführbaren Befehlen, erleichtert die Konstruktion von komplexen Kommunikationsumgebungen, wie sie in Fig. 3 gezeigt sind. Zusätzlich ist leicht zu erkennen, daß eine erste Ebene oder Schicht von Befehlen und Anweisungen vorgesehen sein kann, um die Betriebsweise einzelner Bauteile zu steuern, wobei höhere Funktionalitätsebenen vorgesehen sind, um die Operation der einzelnen Teilsysteme innerhalb des gesamten Netzes zu koordinieren. Daher hat die Entwicklung von Systemen dieser Art zu einer hierarchischen und modularen Lösung geführt.

In üblichen Kommunikationsnetzen waren die Hierarchien im Ergebnis geographisch und die Bereitstellung von Resourcen wurde durch die Zuteilung von Bandbreiten bestimmt. Aufgrund der zunehmenden Stufe oder des Grades der Multiplexierung und der Einführung von relativ wenig aufwendigen Lichtleitfaser- Verbindungsstrecken haben sich die Kosten für die Übertragung von Signalen über große Strecken dramatisch verringert. Daher kann die Hierarchie von verteilten Vermittlungssystemen in Ausdrücken ihrer Funktionalität und nicht mehr aufgrund ihrer geographischen Verteilung betrachtet werden.

Eine Darstellung dieser hierarchischen Lösung ist in Fig. 4 gezeigt. So stellt eine erste Schicht 401 der Kommunikation die höchste Ebene der Bandbreitenkommunikation dar, die zwischen zentralen Vermittlungsstellen vorgesehen ist, die ihrerseits global verteilt sein können. Unter dieser Schicht vereinigt eine zweite Schicht 402 Vermittlungsoperationen, die bei einer niedrigen Konzentration der Multiplexierung durchgeführt werden, wobei ein ähnlich verringerter Grad an multiplexierter Kommunikation an einer dritten Betriebsschicht 403 erfolgt.

Jede Einheit innerhalb der Schicht hat ihren eigenen Satz von Steuerbefehlen, wobei die Steuerbefehle die Operationen innerhalb einer Schicht koordinieren und eine Gesamtbetriebssteuerung in einer Verwaltungssteuerebene 404 bewirkt wird.

Zusätzlich können größere Funktionalitätsgrade für einzelne Telefon-Teilnehmer vorgesehen sein, und Dienste, wie zum Beispiel Rufweiterleitung und automatische Wahlwiederholung usw., ergeben. Vorzugsweise wird eine modulare Lösung hinsichtlich der Schaffung von Befehls- und Anweisungs-Moduleinheiten verwendet, die schließlich auf Vermittlungs-Teilsystemen verwendet werden. Befehle bestehen üblicherweise aus identifizierbaren Zeilen und in vielen Fällen kann die Anzahl von Befehlszeilen bis zu vielen tausend, möglicherweise Millionen, Zeilen reichen.

Somit erfordert die Erzeugung derartig vieler Befehle die Verwendung einer modularen Lösung, so daß die Aufgabe der Erzeugung der Befehle auf mehrere Ingenieur-Teams oder einzelne Ingenieure aufgeteilt werden kann, um die Aufgabe der Erzeugung der Befehle in realistischer Weise erfüllbar zu machen. Durch Definition der gewünschten Funktionalität der Vermittlung in Ausdrücken der Funktionalität einer Vielzahl von Befehlsmoduleinheiten wird die Entwicklung von zunehmend komplexeren Vermittlungs-Teilsystemen bis zu einem Grad erleichtert, der nicht möglich sein würde, wenn weniger als eine modulare Lösung verwendet würde.

Eine graphische Darstellung eines Satzes von Befehlsmoduleinheiten ist in Fig. 5 gezeigt. Es sei bemerkt, daß die Moduleinheiten in Fig. 5 nicht in direkter Beziehung zu der in Fig. 4 gezeigten Bandbreiten-Hierarchie stehen. Unterschiedliche Moduleinheiten können mit der gleichen Bandbreitenebene in Wechselwirkung stehen, und unterschiedliche Bandbreiten können mit der gleichen Moduleinheit in Wechselwirkung stehen. So sind in Fig. 4 die Befehle so dargestellt, als ob sie sich innerhalb jeweiliger Moduleinheiten befinden.

Ein Satz von Befehlen, möglicherweise in Form von mehreren Dateien, die jeweils mehrere tausend Befehlszeilen enthalten, ist in einer Moduleinheit 501 enthalten, wobei ein ähnlicher Satz in der Moduleinheit 502, ein ähnlicher Satz in der Moduleinheit 503 und so weiter für die Moduleinheiten 504, 505, 506 und 507, enthalten ist. Fig. 5 dient lediglich zu Erläuterungszwecken und in einem tatsächlich arbeitenden Befehlssatz kann die Anzahl von vorhandenen Moduleinheiten beträchtlich größer sein.

Die in Fig. 5 gezeigten Pfeile, die die Moduleinheiten verbinden, stellen deren gegenseitige Abhängigkeit dar. Somit werden, wenn in der Moduleinheit 501 enthaltene Befehle ausgeführt werden, diese Befehle ihrerseits einen Aufruf von Befehlen innerhalb der Moduleinheit 502 hervorrufen, was durch den Pfeil 508 angezeigt ist. In ähnlicher Weise kann die Moduleinheit 502 die Moduleinheit 503 aufrufen, die ihrerseits einen Aufruf zurück an die Moduleinheit 502 oder an die Moduleinheit 507 durchführen kann.

Obwohl die Aufgabe der Erzeugung neuer Befehle zur Durchführung komplizierter Funktionen an einem Vermittlungs-Teilsystem durch die Verwendung einer modularen Lösung vereinfacht wird, besteht somit eine komplexere Reihe von Wechselwirkungen zwischen den Moduleinheiten, und dies kann Raum dafür schaffen, daß Fehler in den Befehlen aufgrund der baren Kompliziertheit des manuellen Prüfverfahrens unbemerkt bleiben, das erforderlich sein würde, um die Funktionalität erschöpfend zu prüfen. Somit ist es schwierig, ein Vermittlungs-Teilsystem zu schaffen, das auf der Integrität von mehreren tausend Befehlszeilen beruht.

Ein bekanntes Verfahren zum Definieren und Prüfen der Funktionalität von Befehlen ist "SDL" (Spezifikations-Beschreibungssprache). In SDL wird jede Operation, die einer oder einigen wenigen Befehlszeilen entspricht, unter Verwendung eines graphischen Ablaufdiagramm-Verfahrens definiert, wobei ein Datenverarbeitungssystem verwendet wird, um eine volle Beschreibung des Betriebsvermögens eines gesamten Teilabschnittes oder einer Moduleinheit von Befehlen aufzubauen. Es ist weiterhin möglich, SDL-Beschreibungen von Moduleinheiten miteinander zu verknüpfen, so daß eine logische Gesamtbeschreibung der Funktionalität aller Befehle definiert wird. Die SDL-Beschreibung kann Ingenieuren geliefert werden, um sie auf einer Modul-für-Modul-Grundlage in spezifische Befehle umzusetzen. Alternativ stehen Werkzeuge zur automatischen Übersetzung der SDL-Beschreibung in einen Satz von Befehlen zur Verfügung, die in der Sprache kodiert sind, wie zum Beispiel in C oder C++. Es ist jedoch bekannt, daß auf diese Weise erzeugte Befehle für den Menschen extrem schwierig zu lesen sind, verglichen mit Befehlen, die manuell erzeugt wurden. Somit macht es die automatische Befehlserzeugung aus SDL noch schwieriger, zu verstehen, wo ein Fehler in dem gesamten Satz von Befehlen vorliegen kann.

Ein Vorteil der Verwendung einer Beschreibungssprache, wie zum Beispiel SDL, besteht darin, daß es möglich ist, die Ausführung der Befehle zu simulieren, bevor sie tatsächlich auf einer vorhandenen Telekommunikationsvermittlung verwendet werden. Somit kann es möglich sein, Fehler in der Auslegung des Betriebsverhaltens der Telekommunikationsvermittlung zu entdecken, bevor sie tatsächlich in der realen Welt verwendet wird. Die Permutationen des Betriebsverhaltens sind jedoch praktisch unbegrenzt. Somit ist es nicht möglich, mit irgendeinem Gewißheitsgrad festzustellen, daß keine Fehler irgendwo in der Definition der Operationen des Vermittlungs-Teilsystems vorliegen.

Es sollte aus der wechselseitigen Abhängigkeit der Moduleinheiten nach Fig. 5 ersichtlich sein, daß es nicht möglich ist, Befehle für die Moduleinheit 507 in vollständiger Isolation aufzubauen. Es muß eine sorgfältige Erwägung hinsichtlich der Wechselwirkung der in der Moduleinheit 507 enthaltenen Befehle mit den damit zusammenwirkenden Moduleinheiten erfolgen. Somit muß eine Spezifikation festgelegt werden, die Einzelheiten des erforderlichen Funktionalitätsgrades angibt, der für die Moduleinheit 507 erforderlich ist. Zusätzlich muß die Spezifikation jedoch auch eine ausführliche Beschreibung der Art einschließen, wie die Moduleinheit 507 mit dem restlichen Teil der gesamten Befehlsumgebung in Kommunikation oder in Schnittstellenverbindung tritt. Somit ist in einem speziellen Beispiel zu erkennen, daß die Moduleinheit 507 als solche als Antwort auf einen Aufruf aktiviert wird, der von der Moduleinheit 503 oder der Moduleinheit 504 ausgeht. Somit müssen die in der Moduleinheit 507 enthaltenen Befehle auf diese speziellen Arten von Aufrufen antworten, was entsprechend den Befehlen eingestellt wird, die in den Moduleinheiten 503 und 504 enthalten sind. Die Moduleinheiten 503 und 504 rufen die Moduleinheit 507 in ihrer speziellen Weise auf, so daß diese Definition eine Schnittstellen- Spezifikation einschließen muß. In ähnlicher Weise muß die Moduleinheit 507 ihrerseits die Unterstützung der Moduleinheit 506 aufrufen können, und auch diese spezielle Art dieses Aufrufs wird spezifiziert, so daß die Schnittstellenverbindung zwischen den Moduleinheiten 507 und 506 aufrechterhalten wird.

Schließlich müssen Steuersignale und andere Arten von Signalen durch den Gesamtsatz von Befehlen erzeugt werden, und in ähnlicher Weise sind die Befehle so angeordnet, daß sie Signale empfangen, die von der Hardware ihrer örtlichen Vermittlung ausgehen, und die wahrscheinlich von anderen Einheiten innerhalb der Gesamtstruktur ausgehen. Somit sind, in der in Fig. 5 gezeigten Weise die Moduleinheiten 501, 503 und 506 so ausgebildet, daß sie eine Kommunikation mit externen Geräten ausführen, und die Art dieser Kommunikationen muß ebenfalls für die jeweiligen Modul-Schnittstellen spezifiziert werden. Somit ist es erforderlich, vor Beginn der Arbeit hinsichtlich der Erstellung neuer Befehle für eine spezielle Moduleinheit in genauer Weise deren Schnittstellen mit anderen Moduleinheiten innerhalb des Satzes von Befehlen zu definieren.

Im Hinblick auf die Wichtigkeit der Schnittstelle einer Moduleinheit ist es verständlich, daß die Übereinstimmung mit Modul- Schnittstellen-Spezifikationen für die Sammlung von in Fig. 5 gezeigten, Moduleinheiten wesentlich ist, damit diese zusammenwirken können, um eine erfolgreiche Gesamt-Funktionalität zu erzielen. Eine erfolgreiche Implementierung der Schnittstelle ist ein Schlüsselelement der gesamten Befehlsentwicklung. Durch Prüfen von Modul-Befehlen zur Feststellung, ob sie mit einer jeweiligen Modul-Schnittstellen-Spezifikation übereinstimmen, wird es möglich zu bestimmen, ob eine Moduleinheit wahrscheinlich innerhalb der Umgebung, für die sie ausgelegt ist, erfolgreich in Wechselwirkung tritt.

Ein Verfahren zum Prüfen der Übereinstimmung von Modulbefehlen mit ihrer jeweiligen Schnittstellen-Spezifikation ist in Fig. 6 gezeigt. Ein Vermittlungssystem 601 schließt eine Vermittlung 602 ein, die zum Empfang ankommender Daten an einer Leitung 603 und zur Aussendung abgehender Daten auf einer Leitung 604 ausgebildet ist. Die Betriebsweise und die Konfiguration der Vermittlungsmechanismen innerhalb der Vermittlung 602 wird aktiv in Abhängigkeit von der Ausführung von ausführbaren Befehlen gesteuert, die von einer Speichereinrichtung 605 empfangen werden.

Im Prozeß 606 wird die gewünschte Funktionalität des Vermittlungssystems 601 definiert. Im Prozeß 607 wird die im Prozeß 606 definierte Gesamtfunktionalität in formale Moduldefinitionen zerlegt. Jede Moduleinheit hat eine Definition ihrer Funktion und der Art, wie sie mit anderen Moduleinheiten zusammenwirkt, die in dem Vermittlungssystem 601 arbeiten. Der Prozeß der Umwandlung des Satzes von formalen Moduldefinitionen, die im Prozeß 607 definiert wurden, in ausführbare Befehle, die in der Speichereinrichtung 605 gespeichert werden, ist in den Prozessen 608 bis 615 zusammengefaßt.

Im Prozeß 608 wird eine Moduleinheit für die Betrachtung ausgewählt. Im Prozeß 609 wird die im Prozeß 607 geschaffene formale Modul-Schnittstellen-Definition unter Verwendung einer formalen Beschreibungssprache, wie zum Beispiel SDL, spezifiziert. Im Prozeß 610 werden verschiedenen Parametern Werte gegeben, derart, daß wenn diese Parameter einer sich in Prüfung befindenden Moduleinheit zugeführt werden, das Ergebnis der simulierten Ausführung der Moduleinheit beobachtet werden kann, um zu bestimmen, ob die Modulbefehle mit der formalen Modul- Schnittstellen-Definition übereinstimmen oder nicht. Nach Abschluß des Prozesses 610 wird die Steuerung zum Prozeß 612 übergeben. Parallel zu den Prozessen 609 und 610 werden im Prozeß 611 Modulbefehle, entsprechend der formalen Modul-Funktionsdefinition, erzeugt, die in dem Prozeß 607 festgelegt wurde. Nach dem Abschluß des Prozesses 611 wird die Steuerung an den Prozeß 612 übergeben.

Im Prozeß 612 werden die in dem Prozeß 610 erzeugten Testfälle auf die betrachtete Moduleinheit angewandt, deren Befehle im Prozeß 611 erzeugt wurden. Auf diese Weise kann die Übereinstimmung der Moduleinheiten mit der formalen Modul-Schnittstellen-Definition, die im Prozeß 607 festgelegt wurde, geprüft werden. Wenn eine Moduleinheit nicht mit den Schnittstellen- Spezifikations-Anforderungen übereinstimmt, wird die Steuerung an einen Prozeß 611 übergeben, in dem eine weitere Stufe der Erzeugung von Modulbefehlen vorgesehen ist, um eine Fehlerbeseitigung in den Befehlen durchzuführen, die vorher erzeugt wurden. Der Prozeß 612 wird wiederholt, bis die in dem Prozeß 611 erzeugten Modulbefehle mit den Modul-Schnittstellen-Spezifikationen übereinstimmen.

Im Prozeß 613 wird die Frage gestellt, ob irgendwelche anderen Moduleinheiten verbleiben, die noch betrachtet werden müssen. Wenn noch weitere Moduleinheiten betrachtet werden müssen, so wird die Steuerung zum Prozeß 608 zurück übergeben, und die gerade beschriebenen Prozesse werden erneut wiederholt. Alternativ wird eine Steuerung an den Prozeß 614 übergeben. Im Prozeß 614 werden Modulbefehle in ausführbare Befehle durch einen Compilierungsprozeß umgewandelt. Im Prozeß 615 werden die in dem Prozeß 614 erzeugten ausführbaren Befehle in die Speichereinrichtung 605 in dem Vermittlungssystem 601 heruntergeladen.

Der Prozeß 609 zur Spezifizierung einer Modul-Schnittstelle gemäß Fig. 6 ist ausführlich in Fig. 7 dargestellt. Fig. 7 faßt die Folge von Prozessen zusammen, die erforderlich sind, um eine formale Modul-Schnittstellen-Definition in einer Form zu definieren, die zur automatischen Erzeugung von Testfällen geeignet ist. Die Prozesse 701 bis 706 entsprechen somit den Prozessen, die von einem Menschen ausgeführt werden, wenn er die in einem Schnittstellen-Definitions-Dokument enthaltene Information in eine SDL-Datei überführt, die in einem Gerät enthalten ist, das automatisch Testfälle aus dieser Information erzeugen kann. Man sollte sich an dieser Stelle in der Erläuterung sehr klar machen, daß die SDL-Sprache zur Definition der Schnittstelle einer Moduleinheit und nicht zur Definition ihrer Funktionalität verwendet wird.

Im Prozeß 701 werden die Anforderungen an die Funktionalität der betrachteten Moduleinheit identifiziert. Die Anforderungen an die Funktionalität identifizieren die Funktion, die die Moduleinheit ausführen kann, ohne zu definieren, wie die Moduleinheit diese Funktion tatsächlich ausführt. Im Prozeß 702 erfolgt eine Identifikation der Dienste in der Moduleinheit. Eine Moduleinheit kann einen oder mehrerer Dienste enthalten, die von anderen Moduleinheiten aufrufbar sind. Somit wird jeder dieser Dienste in dem Prozeß 702 identifiziert. Im Prozeß 703 werden alle Eingänge und Ausgänge der Moduleinheit identifiziert. Dies schließt die Datentypen sowie die Namen der Parameter ein, die verwendet werden. Somit wird eine Identifikation von ganzzahligen Variablen, reellen Variablen, Zeichenketten-Variablen usw. durchgeführt, wobei diese Eingänge oder Ausgänge sein können. Somit wird im Prozeß 703 jede Eingangs- und Ausgangs-Variable explizit spezifiziert. Im Prozeß 704 wird eine Identifikation der Vorbedingungen durchgeführt. Ein Beispiel einer Vorbedingung ist eine Spezifikation eines Bereiches von Werten, die eine ganzzahlige Variable annehmen kann, die als ein Eingang in dem Prozeß 703 spezifiziert wurde. Beispielsweise kann eine vorzeichenbehaftete ganze Zahl, die normalerweise einen Bereich von -65536 bis +65535 haben kann, eine Vorbedingung hinsichtlich dieses Bereiches auferlegt bekommen, derart, daß sie lediglich die Werte im Bereich von 0 bis 10 annehmen kann.

Eine Vorbedingung ist eine Entscheidungsanweisung in einer Prozedur, deren Auswertung (wahr oder falsch) zu der Ausführung einer oder mehrerer auf die Bedingung folgender Anweisungen führen kann. Das folgende beispielhafte Protel-Fragment zeigt jede Art von Entscheidungskonstrukt, das in der Protel-Sprache möglich ist.

Für dieses beispielhafte Code-Fragment werden die Vorbedingungen wie folgt spezifiziert:

Die Vorbedingungen für eine Prozedur sind aufeinanderfolgend nummeriert.

Im Prozeß 705 werden beobachtbare Bedingungen identifiziert. Eine beobachtbare Bedingung ist eine Bedingung, die als Ergebnis der vorangegangenen Ausführung der Moduleinheit vorliegt. Beobachtbare Bedingungen können bestimmten Vorbedingungen zugeordnet werden. Wenn beispielsweise eine bestimmte Vorbedingung, wie zum Beispiel ein Bereich von ganzen Zahlen, verletzt ist, so wird eine beobachtbare Bedingung für diese spezielle Verletzung einer Vorbedingung identifiziert. Im Prozeß 706 werden Nachbedingungen identifiziert. Eine Nachbedingung ist eine Bedingung, die sich aus der vorangegangenen Ausführung der Moduleinheit ergibt. In dieser Hinsicht ist eine Nachbedingung ähnlich einer beobachtbaren Bedingung. Nachbedingungen sind jedoch typischerweise Änderungen von Variablen, die nicht explizit von der Moduleinheit zurückgeliefert werden, nachdem diese ausgeführt wurde. So können Änderungen von globalen Variablen als Ergebnis der Ausführung einer Moduleinheit erfolgen. Somit ergeben die in Fig. 7 gezeigten Prozesse eine vollständige Beschreibung der Art und Weise, wie eine bestimmte Moduleinheit mit ihrer Umgebung mit einer Vermittlung zusammenwirkt. Die Funktion, die die Moduleinheit tatsächlich ausführt, wird in dem Prozeß 701 beschrieben. Die Verfahren, durch die die Funktionalität einer Moduleinheit tatsächlich erzielt wird, werden jedoch nicht definiert. Der Prozeß zur Definition eines Verfahrens zur Erzielung der Funktionalität ist ein Teil des Prozesses 611 nach Fig. 6.

Eine Nachbedingung wird als eine der folgenden klassifiziert:

1. Eine explizite Modifikation eines Aktualisierungs- Parameters.

2. Eine implizite Modifikation eines Aktualisierungs- Parameters über eine untergeordnete Prozedur.

3. Eine explizite Modifikation eines externen Datensymbols. Ein externes Datensymbol ist als irgendein Datensymbol definiert, das außerhalb des Bereiches der derzeitigen Prozedur definiert ist.

4. Eine explizite Modifikation eines externen Datensymbols über eine untergeordnete Prozedur.

5. Ein Prozedur-Rückgabewert.

Der Prozeß 610 der Erzeugung von Testfällen, der in Fig. 6 gezeigt ist, ist ausführlich in Fig. 8 wiedergegeben. Im Prozeß 801 wird die formale Definition der Schnittstelle einer Moduleinheit, die nunmehr im SDL-Format definiert wurde, zerlegt und analysiert, um eine Darstellung in Form einer verketteten Liste der in SDL definierten Struktur zu schaffen. Diese Darstellung in Form einer verketteten Liste der Schnittstellen-Definition der Moduleinheit macht es möglich, die verbleibenden Prozesse 802, 803 und 804 auszuführen, die in Fig. 8 gezeigt sind.

Der Verzweigungsüberdeckungs-Testverfahren-Prozeß 802, der in Fig. 8 gezeigt ist, führt die Funktion der Lokalisierung von Testpfaden in der Modul-Schnittstellen-Darstellung aus, die in dem Prozeß 801 erzeugt wird. Für Schnittstellen-Definitionen, die keine Schleifen enthalten, lokalisiert das Verzweigungsüberdeckungs-Testverfahren 802 die kleinste Anzahl von Pfaden durch die Modul-Schnittstellen-Definition, die eine volle Pfadüberdeckung ergeben, d. h. die jeden Pfad zumindest einmal durchlaufen. Für Modul-Schnittstellen, die Schleifen enthalten, lokalisiert das Verzweigungsüberdeckungs-Testverfahren 802 die kleinste Anzahl von Pfaden durch die Modul-Schnittstelle, die eine vollständige Pfadüberdeckung ergeben, plus einem zusätzlichen Pfad für jede Schleife. Wenn ein Pfad eine Schleife enthält, so wird die Schleife nu einmal wiederholt. Das Verzweigungsüberdeckungs-Testverfahren lokalisiert zwei unterschiedliche Arten von Pfaden durch die Modul-Schnittstelle:

Ein "Austrittspfad" ist eine Folge von Knoten, die an den Modulschnittstellen-Eintrittsknoten beginnt und an den Modulschnittstellen-Austrittsknoten endet.

Ein "Schleifenpfad" ist eine Folge von Knoten, die an den Modul-Schnittstellen-Eintrittsknoten beginnt und an einem Knoten endet, der bereits in dem Pfad enthalten ist.

Fig. 9A zeigt eine Darstellung einer fiktiven SDL-Modulschnittstelle. Es sind zwei unterschiedliche Schritte erforderlich, um eine Liste von Pfaden für eine Schnittstellen-Spezifikation dieser Art zu erzeugen. Die zwei Schritte sind in dem Ablaufdiagramm nach Fig. 9b zusammengefaßt. In dem ersten Schritt 911 werden alle Austrittspfade und Schleifenpfade in der Schnittstellenspezifikations-Knotendarstellung identifiziert. In dem zweiten Schritt 912 werden alle in dem Schritt 911 identifizierten Schleifenpfade in Austrittspfade umgewandelt.

Der in Fig. 9b gezeigte erste Schritt 911 ist ausführlich in Fig. 9c gezeigt. Bevor die in Fig. 9c gezeigten Prozesse ausgeführt werden, wird eine Initialisierung des "derzeitigen Pfades" durchgeführt, auf den in der gesamten Fig. 9c Bezug genommen wird. Der derzeitige Pfad wird initialisiert, um eine Bezugnahme auf den ersten Knoten 901 in der graphischen Schnittstellendarstellung nach Fig. 9a zu enthalten. Während des gesamten Ablaufs der in Fig. 9c gezeigten Prozesse wächst und schrumpft der derzeitige Pfad, während Knoten zu seinem Ende hinzugefügt bzw. von seinem Ende entfernt werden.

Im Prozeß 921 wird die Frage gestellt, ob der letzte Knoten in dem derzeitigen Pfad NICHT mit irgendwelchen anderen Knoten verbunden ist. Dies ergibt eine Anzeige dafür, ob der derzeitige Pfad ein Austrittspfad ist. Wenn der derzeitige Pfad ein Austrittspfad ist, wird die Steuerung an den Prozeß 927 übergeben. Andernfalls wird die Steuerung an den Prozeß 922 übergeben.

Im Prozeß 922 wird die Frage gestellt, ob der letzte Knoten in dem derzeitigen Pfad mehr als einmal in dem derzeitigen Pfad auftritt. Dies ergibt eine Anzeige dafür, ob der derzeitige Pfad ein Schleifenpfad ist. Wenn der derzeitige Pfad ein Schleifenpfad ist, so wird die Steuerung an den Prozeß 928 übergeben. Anderenfalls wird die Steuerung an den Prozeß 923 übergeben.

Im Prozeß 923 wird der Knoten, der mit dem letzten Knoten in dem derzeitigen Pfad verbunden ist, mit dem derzeitigen Pfad verbunden, wodurch die Länge des derzeitigen Pfades um einen Knoten vergrößert wird. Im Prozeß 924 werden die Prozesse 921, 922 und 923, die bereits beschrieben wurden, wiederholt, dieses Mal für die neue Version des derzeitigen Pfades. Somit ist der in dem Ablauf-Diagramm nach Fig. 9c zusammengefaßte Prozeß rekursiv, weil er sich selbst mit einer Modifikation des derzeitigen Pfades aufruft.

Im Prozeß 925 ist die rekursiv aufgerufene Version des Prozesses mit einer modifizierten Version des derzeitigen Pfades zurückgekehrt. Der letzte Knoten wird dann aus dem derzeitigen Pfad entfernt. Im Prozeß 926 wird die Frage gestellt, ob der letzte Knoten in dem derzeitigen Pfad mit irgendwelchen weiteren Knoten weiter abwärts in der Verbindungsliste der graphischen Darstellung verbunden ist. Wenn das Ergebnis dieser Frage "JA" ist, so wird die Steuerung zum Prozeß 923 zurück übergeben. Anderenfalls wurde der abschließende Austrittsknoten gefunden, wobei alle Pfade gefunden wurden, und der durch das Ablauf- Diagramm nach Fig. 9c zusammengefaßte Prozeß beendet sich.

Im Prozeß 927 wurde ein Zustand erreicht, in dem ein Austrittspfad gefunden wurde. Somit wird der derzeitige Pfad als ein Austrittspfad gespeichert und der Prozeß wird beendet. Im Prozeß 928 wurde ein Schleifenpfad identifiziert und der Prozeß kann beendet werden. Es sei bemerkt, daß eine Beendigung des Prozesses zu einer Rückkehr zu einer vorhergehenden Iterationsebene des in Fig. 9c gezeigten Ablauf-Diagramms führen kann.

Der Prozeß 912 zur Umwandlung aller Schleifenpfade in Austrittspfade, der in Fig. 9b gezeigt ist, ist ausführlich in Fig. 9d gezeigt. Im Prozeß 931 wird ein Schleifenpfad (der im Prozeß 912 und in Fig. 9c identifiziert wurde) ausgewählt. Im Prozeß 932 wird der letzte Knoten in dem Schleifenpfad identifiziert. Im Prozeß 933 wird eine Suche an allen Austrittspfaden durchgeführt, um einen Austrittspfad zu finden, der den letzten Knoten des Schleifenpfades enthält. Im Prozeß 934 wird das in dem Prozeß 934 identifizierte Austrittspfadfragment an den Schleifenpfad angehängt, so daß der Schleifenpfad nicht mehr eine Schleife ist. Im Prozeß 936 wird die Frage gestellt, ob es noch irgendwelche weiteren verbleibenden Schleifenpfade gibt, die eine Umwandlung erfordern. Wenn weitere Schleifenpfade übrigbleiben, so wird die Steuerung zum Prozeß 931 übergeben, und die Prozesse 931 bis 935 werden für die nächste Schleifenpfad-Umwandlung wiederholt. Anderenfalls wurden alle Schleifenpfade umgewandelt, und der Prozeß zur Umwandlung von Schleifenpfaden auf Austrittspfade ist abgeschlossen.

Ein ausgeführtes Beispiel der Pfad-Identifikation und Umwandlung, unter Bezugnahme auf Fig. 9A, wird nunmehr angegeben.

Ein rekursiver Pfad-Durchgang wird ausgeführt, um alle Austrittspfade und alle Schleifenpfade zu lokalisieren, die in der Modul-Schnittstellen-Definition enthalten sind. Beginnend an dem Schnittstellen-Eintrittsknoten werden alle Verbindungen verfolgt, wobei Knoten für Knoten ein "derzeitiger Pfad" aufgebaut wird. Der Schritt 1 ist abgeschlossen, wenn alle Verbindungen zumindest einmal durchlaufen wurden.

901-902-903

Der Knoten 903 ist mit mehr als einem weiteren Knoten verbunden. Jede Verbindung wird in einer Reihe durchlaufen (gehe beispielsweise zuerst zum Knoten 908).

(901-902-903)-908-909

Das Ende des Dienstes ist erreicht. Speichere den derzeitigen Pfad als einen Austrittspfad. Gehe zurück zum Knoten 903 und durchlaufe die andere Verbindung (zum Knoten 904).

(901-902-903)-904

Der Knoten 904 ist mit mehr als einem weiteren Knoten verbunden. Durchlaufe jede Verbindung in einer Reihe (gehe beispielsweise zuerst zum Knoten 902).

(901-902-903-904)-902

Der Knoten 902 befindet sich bereits im derzeitigen Pfad. Der derzeitige Pfad wird als ein Schleifenpfad gespeichert. Es wird zum Knoten 904 zurückgegangen und die andere Verbindung (zum Knoten 905) wird durchlaufen.

(901-902-903-904)-905-906

Der Knoten 906 steht mit mehr als einem anderen Knoten in Verbindung. Jede Verbindung wird aufeinanderfolgend durchlaufen (gehe, beispielsweise, zunächst zum Knoten 907).

(901-902-903-904-905-906)-907

Das Ende der Moduldefinition ist erreicht. Der derzeitige Pfad wird als ein Austrittspfad gespeichert. Man kehrt zum Knoten 906 zurück und durchläuft die andere Verbindung (zum Knoten 905).

(901-902-903-904-905-906)-905

Der Knoten 905 befindet sich bereits im derzeitigen Pfad. Der derzeitige Pfad wird als ein Schleifenpfad gespeichert. Alle Verbindungen wurden nunmehr durchlaufen.

Bisher hat die Pfadsuchfunktion diese Pfade lokalisiert:

901-902-903-908-909

901-902-903-904-905-906-907

901-902-903-904-902

901-902-903-904-905-906-905

Schleifenpfade können nicht geprüft werden, weil sie keinen vollständigen Pfad durch die Schnittstellen-Definition der Moduleinheit darstellen. Jeder Schleifenpfad wird in einen Austrittspfad umgewandelt.

Es wird der erste Schleifenpfad 901-902-903-904-902 untersucht: Der letzte Knoten in diesem Pfad ist der Knoten 902. Nunmehr wird jeder Austrittspfad untersucht, um einen Pfad zu finden, der den Knoten 902 enthält: Der Austrittspfad 901-902-903-908- 909 enthält den Knoten 902. Es wird die Folge gesucht, die auf den Knoten 902 in diesem Austrittspfad folgt. Die Folge ist

903-908-909

Nunmehr wird diese Folge an den Schleifenpfad angehängt: 901- 902-903-904-902 + 903-908-909 = 901-902-903-904-902-903-908-909, was der neue Austrittspfad ist.

In gleicher Weise werden für den zweiten Schleifenpfad Austrittspfade für eine Folge untersucht, die an den Schleifenpfad angehängt werden kann. Der zweite Schleifenpfad wird zu:

901-903-904-905-906-905 + 906-907 = 901-902-903-904-905-906- 905-906-907.

Nachdem alle Schleifenpfade in Austrittspfade umgewandelt wurden, sind die lokalisierten Pfade wie folgt:

901-902-903-908-909

901-902-903-904-905-906-907

901-902-903-904-902-903-908-909

901-902-903-904-905-906-905-906-907

Schleifenpfade

keine.

Die erzeugten Pfade können nunmehr zur Erzeugung von Testfällen verwendet werden. Für jeden der Pfade, die im vorstehenden identifiziert wurden, können Charakteristiken des Modulverhaltens, wie es von anderen Moduleinheiten über seine Schnittstelle gesehen wird, definiert werden. Einige der in Fig. 9A gezeigten Knoten schließen Vorbedingungen, andere Nachbedingungen ein, und so weiter, entsprechend den in Fig. 7 gezeigten Schritten. Somit kann jedem Pfad, der nunmehr identifiziert wurde, ein Bereich von Parameter-Eintritts- und -Austritts-Werten und beobachtbaren Effekten zugeordnet werden. Diese Information kann als solche als Teil des Prozesses zur Erzeugung von Modulbefehlen 611 brauchbar sein. Nachdem jedoch der Prozeß 802 der Verzweigungsüberdeckungsprüfung abgeschlossen wurde, können spezifische Werte nunmehr aus dem Bereich von Werten ausgewählt werden, die für jeden der Pfade, der gerade identifiziert wurde, als gültig identifiziert wurden.

Im Prozeß 803 wird eine Grenzwertanalyse an den verschiedenen Vorbedingungen durchgeführt, die in Fig. 7 definiert sind, um einen Satz von Testwerten für jeden der Pfade zu erzeugen, der in Verbindung mit Fig. 9a identifiziert wurde. Es werden Werte ausgewählt, um die Gültigkeit der Schnittstelle der Modul einheit unter Verwendung von Parameterwerten über einen breiten Bereich von möglichen Werten zu testen. Es ist jedoch unpraktisch, alle möglichen Permutationen der Werte zu betrachten, die irgendeinem Modul zugeführt werden, weil die Anzahl der Permutationen praktisch unbegrenzt ist.

Ein Beispiel eines Satzes von Vorbedingungen, die für einen bestimmten Pfad durch eine Modul-Schnittstellen-Definition identifiziert sind, ist in Fig. 10a gezeigt. Ein Bereich von möglichen Werten für eine Variable "x" zwischen Null und Zehn ist in Zeile 1001 gezeigt. In Zeile 1002 wird ein Bereich von Werten für eine Variable "y" in ähnlicher Weise definiert. In Zeile 1003 wird eine Boole'sche Variable "z" definiert, die den Wert "WAHR" oder "FALSCH" annehmen kann. In Zeile 1004 ist eine Zeichenketten-Variable "a" so gezeigt, als ob sie irgendeinen von drei möglichen Text-Zeichenketten annehmen kann. Somit werden in den Zeilen 1003 und 1004 Werte explizit definiert, während in den Zeilen 1001 und 1002 ein Bereich von Werten definiert wird.

In Fig. 10b sind diese Variablen in Tabellenform angeordnet. Die explizit definierten Werte für die Variablen "z" und "a" sind zusammen mit fünf unterschiedlichen Werten für die Variablen "x" und "y" gezeigt. Die Werte, die für die Variablen x und y gewählt werden, sind entsprechend bekannter Techniken für eine Grenzwertanalyse ausgewählt.

Testfälle werden aus der in Fig. 10b gezeigten Tabelle erzeugt. Fünf Testfälle sind in Tabellenform in Fig. 10c zusammengefaßt. Es ist zu erkennen, daß nicht alle Permutationen der Testfall- Werte, die in Fig. 10b erzeugt werden, tatsächlich für Testfälle verwendet werden, weil die Anzahl von Permutationen übermäßig groß sein würde. Vorzugsweise werden die Werte derart gewählt, daß jeder der in der Fig. 10b gezeigten Tabelle definierten Werte zumindest einmal verwendet wird. Somit wird jeder der für die Variablen x und y gewählten Werte einmal verwendet, und jeder der Werte für die Variablen z und a kann einmal oder mehrmals verwendet werden. Somit definiert Fig. 10c fünf Testfälle, die an einem der Pfade verwendet werden sollen, die aus der graphischen Darstellung nach Fig. 9a abgeleitet wurden. Durch Definieren eines Satzes von Testfällen für jeden der möglichen Pfade, der aus der graphischen Darstellung in Fig. 9a abgeleitet wurde, wird eine Testfall-Gruppe geschaffen, die automatisch zum Testen der Gültigkeit der Modulwechselwirkungen gemäß den formalen Modul-Schnittstellen-Definitionen verwendet werden kann.

In dem in Fig. 8 gezeigten Prozeß 804 werden die Testfall- Gruppen, die in dem Prozeß 803 erzeugt wurden, in Befehle zum Aufrufen der Moduleinheit umgewandelt, deren Schnittstellen- Spezifikation getestet werden soll. Somit ist das Ergebnis des Prozesses 804 eine Folge von Befehlen, die in dem Prozeß 612 nach Fig. 6 verwendet werden können, um die Vorschriftsmäßigkeit der Moduleinheit zu prüfen. Wenn die Moduleinheit nicht mit der Moduleinheit ihrer Schnittstelle übereinstimmt, ist es erforderlich, modifizierte Modulbefehle in dem Prozeß 611 zu erzeugen, bis der Test im Prozeß 612 erfolgreich ist.

In einer weiteren Ausführungsform werden die Nachbedingungen aufgeführt und mit ihren zugehörigen Vorbedingungen durch die Verwendung einer Vor- und Nachbedingungs-Verhaltensmatrix korreliert. Diese Matrix, die in Fig. 11 gezeigt ist und dem vorstehend beschriebenen Protel-Fragment entspricht, muß von seinem Ende aus gelesen werden. Hierbei ist es möglich, abzuleiten, welche Vorbedingungen erfüllt sein müssen, um eine bestimmte Nachbedingung zu erzielen. Die Vorbedingungen sind in den Spalten 1 bis 5 angezeigt, und die entsprechenden Nachbedingungen sind die Reihen herab aufgeführt. Es ist möglich, Kombinationen von Nachbedingungen zu erzielen, wenn die entsprechenden Vorbedingungen erfüllt sind. Es sei bemerkt, daß die Vorbedingungen, die sich auf eine "Rückkehr"-Nachbedingung beziehen, nicht erfüllt sind, wenn die weiter unten in der Matrix aufgeführten Nachbedingungen erzielt werden sollen.

Die Interpretation der Verhaltensmatrix nach Fig. 11 ist in den Fig. 12 und 13 erläutert. In der Matrix, die als Bei spiel in Fig. 12 gezeigt ist, will der Programmierer wissen, unter welchen Umständen die globale Flagge "link_clear" auf WAHR gesetzt wird, und er führt die folgenden Prozeß-Schritte aus:

1. Lokalisiere die gewünschte "TRUE (WAHR) → link_clear"- Nachbedingung.

2. Leite ab, welche Vorbedingungen diese Nachbedingung hervorrufen, indem die Zeile untersucht wird, die den Nachbedingungs-Text enthält. In dem Beispiel nach Fig. 12 muß sich die Vorbedingung 5 als WAHR erweisen, um die gewünschte Nachbedingung zu ergeben.

3. Untersuche alle Nachbedingungen, die der gewünschten "TRUE → link_clear"-Nachbedingung vorangehen. Alle "Rückkehr"-Nachbedingungen müssen zumindest einmal bei ihren entsprechenden Vorbedingungen fehlschlagen, damit die gewünschte Nachbedingung erzielt wird.

Die Wirkung der vorhergehenden Nachbedingungen ist in Fig. 13 gezeigt. In diesem Beispiel gibt es zwei vorhergehende "Rückkehr"-Vorbedingungen, und die folgenden Prozeßschritte · werden ausgeführt.

4. Die Reihe oberhalb der gewünschten "TRUE → link_clear"- Nachbedingung enthält eine "Rückkehr"-Nachbedingung. Um die gewünschte Nachbedingung zu erzielen, darf diese vorhergehende "Rückkehr"-Nachbedingung nicht auftreten. Daher muß die logische Kombination der Vorbedingungen 5 und 6 sich als falsch erweisen.

5. Wenn die Matrix von der gewünschten Nachbedingung aus weiter nach oben betrachtet wird, so enthält die oberste Zeile eine "Rückkehr"-Nachbedingung. Um die gewünschte gewünschte Nachbedingung zu erzielen, darf diese vorhergehende "Rückkehr"-Nachbedingung nicht auftreten. Daher muß sich die Vorbedingung 1 als falsch erweisen.

Durch Testen der Modul-Schnittstellen auf diese Weise ist es möglich, eine verbesserte Modul-Entwicklungsumgebung zu schaffen. Wenn die Moduleinheiten so geschrieben werden, daß sie erfolgreich mit ihren Modul-Schnittstellen-Spezifikationen übereinstimmen, können Befehle für andere Moduleinheiten zuverlässiger erzeugt werden, vorausgesetzt, daß irgendwelche Fehler, die in ihnen auftreten, mit geringerer Wahrscheinlichkeit aufgrund eines Fehlers in derjenigen der Moduleinheiten aufgetreten sind, deren Schnittstellen-Spezifikationen erfüllt wurden.