DE69425894T2

DE69425894T2 - Anordnung und Verfahren zum Erstellen von Software

Info

Publication number: DE69425894T2
Application number: DE69425894T
Authority: DE
Inventors: Brian Hanes; Ian Popay; Ann Salter
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1993-07-01
Filing date: 1994-07-01
Publication date: 2001-04-12
Anticipated expiration: 2014-07-02
Also published as: FI956321A; GB9523912D0; EP0706683A1; KR960703478A; ES2151928T3; NO955287D0; EP0706683B1; FI956321A0; AU692775B2; CN1126523A; SG54179A1; DE69425894D1; JPH08512155A; NO955287L; NZ267700A; CA2164335C; GB2294567A; GB2294567B; ATE196374T1; AU7007494A

Description

GEBIET DER ERFINDUNG

Die vorliegende Erfindung bezieht sich auf die Erzeugung von Befehlssequenzen für eine Anwendungsplattform, wie zum Beispiel für eine Sprachanwendungsplattform.

HINTERGRUND DER ERFINDUNG

Sprachanwendungsplattformen werden in Telephonvermittlungen verwendet, um automatisierte Kundendienste zu schaffen, wie zum Beispiel die Anrufbedienung, die Anrufübertragung, die Telephonbeantwortung oder die Nachrichtenaufzeichnung und dergleichen.
Die Computerhardware, die in einer modernen Telephonvermittlung verwendet wird, kann einen sehr viel größeren Bereich an Kundendiensten unterstützen als derzeit implementiert ist. Der Grund für diese Diskrepanz besteht darin, daß die Erzeugung der Software für einen Kundendienst ein langwieriger Prozeß ist. Ferner muß ein neuer Kundendienst eine umfangreiche simulierte Operation durchlaufen, bevor er freigeschaltet wird, um sicherzustellen, daß Kunden positiv auf den Dienst reagieren und ihn häufiger zu verwenden wünschen.
Bisher wurden Sprachanwendungen manuell erzeugt. Anfangs definiert ein Dienstentwickler einen Dienst auf Papier unter Verwendung eines Flußdiagramms und anderer schematischer Werkzeuge. Sobald ein Dienst in seiner Form entworfen ist, wird er als ein "Skript" ausgeschrieben, ähnlich dem Skript für ein Theaterspiel, wobei jedoch ein interaktiver Dialog zwischen der Anwendungsplattform und einem anrufenden Kunden definiert wird. Das Skript kann Verzweigungen für Kundenoptionen und Plattformentscheidungen enthalten. Das Skript, das in einer bekannten Skriptsprache geschrieben ist, definiert somit alle möglichen Operationen für den Dienst. Das Skript wird anschließend einem erfahrenen Programmierer übergeben, der ein Programm zur Implementierung des Dienstes schreibt. Das Programm kann in einer Hochsprache wie zum Beispiel C oder C++ geschrieben werden, um die Anzahl der Modifikationen zu minimieren, die erforderlich sind, um es auf einer Vielzahl unterschiedlicher Typen von Sprachanwendungsplattformen laufen zu lassen.
Eine Schwierigkeit bei diesem Lösungsansatz besteht darin, daß die Modifikation der Dienstdefinition auf der Flußdiagrammebene eine Modifikation des entsprechenden Skripts und des entsprechenden C/C++-Programms erfordert. Solche geringen Modifikationen an der Dienstdefinition erfordern ein überproportionales Maß an Arbeitsaufwand, um einen modifizierten Kundendienst zu erzeugen.
Ein weiteres Problem ist, daß bei der Übersetzung der Dienstdefinition in ein Skript und insbesondere bei der Übersetzung des Skripts in ein Programm leicht Fehler gemacht werden können, so daß üblicherweise ein erheblicher Zeitaufwand für die Fehlerbeseitigung des Programms aufgewendet wird. Bei einer großen Menge an Computersoftware wird angenommen, daß kleinere Fehler im fertiggestellten Produkt verbleiben, welche nur erkannt werden können, nachdem die Software eine bestimmte Zeitspanne in Gebrauch war. Eine Sprachanwendungsplattform weist jedoch aus zwei Gründen nicht den gleichen Grad an Toleranz auf. Erstens, die Kunden werden durch irgendwelche Fehler schnell abgeschreckt, die während des Betriebs eines Dienstes auftreten können - der Verlust einer auf einem Beantwortungsdienst zurückgelassenen Nachricht kann den Verlust eines lukrativen Vertrages bedeuten. Zweitens, ein Softwarecodierungsfehler kann auf bestimmten Computern, die als Sprachanwendungsplattformen verwendet werden, andere Operationen der Plattform stören. Im ungünstigsten Fall kann dies zu einem vollständigen Absturz der Telephonvermittlung führen.
Eine Lösung für diese Probleme ist, den Prozeß der Übersetzung der Dienstdefinition in ein Computerprogramm zu automatisieren. Ein solches System wird als Diensterzeugungswerkzeug bezeichnet. In einem bekannten Diensterzeugungswerkzeug wird ein Dienst als ein Flußdiagramm auf einem Computer unter Verwendung einer graphischen Benutzerschnittstelle definiert. Unter Verwendung der graphischen Benutzerschnittstelle werden individuelle Funktionsblöcke positioniert und miteinander verbunden, um eine Gesamtdefnition des Dienstes zu bilden. Jeder Block kann für eine Parametereinstellung ausgewählt werden, die die Art beeinflussen kann, in der der bestimmte Block arbeitet, und wie dieser Block mit den anderen Blöcken innerhalb des Flußdiagramms verbunden ist. "SDL-oriented graphical environment", J.P. Hong u. a., SDL'87, State of the art and future trends, Nord Holland, Niederlande, S. 117-124, beschreibt ein solches System. In diesem bekannten System prüft ein Syntaxprüfer sowohl das Layout des Diagramms als auch die Syntax des innerhalb der Blöcke geschriebenen Textes. Daher muß der Benutzer die zeitaufwendige Aufgabe des Eingebens der Parameter durchführen, die die Blockfunktionen spezifizieren, bevor die Gültigkeit des Hochebene-Entwurfs überprüft wird.

ZUSAMMENFASSUNG DER ERFINDUNG

Gemäß einem ersten Aspekt der vorliegenden Erfindung wird eine Vorrichtung geschaffen zum Erzeugen einer Sequenz von Befehlen für die Ausführung durch eine Anwendungsplattform, mit
einer Eingabeeinrichtung zum Empfangen einer Anwendereingabe;
einer graphischen Anzeigeeinrichtung; und
einer Verarbeitungseinrichtung, die
a) als Antwort auf eine Anwendereingabe erster Daten, die gewünschte Funktionen mehrerer diskreter Funktionen spezifizieren, die durch die Anwendungsplattform ausgeführt werden können, mittels der graphischen Anzeigeeinrichtung eine graphische Darstellung der funktionalen Blöcke, die den spezifizierten Funktionen entsprechen, anzeigt;
b) als Antwort auf eine Anwendereingabe zweiter Daten, die gewünschte Verknüpfungen zwischen den spezifizierten Funktionen spezifizieren, wobei die Verknüpfungen gemeinsam eine logische Sequenz zur Ausführung der Funktionen definieren, mittels der graphischen Anzeigeeinrichtung eine graphische Darstellung von Verbindungen zwischen den den spezifizierten Verknüpfungen entsprechenden Blöcken anzeigt;
c) so betreibbar ist, daß sie die Gültigkeit der logischen Sequenz, die durch die Verknüpfungen definiert ist, prüft, um Fehler in der logischen Sequenz zu erkennen; und dadurch gekennzeichnet, daß
die Verarbeitungseinrichtung ferner nur dann, wenn keine solchen Fehler erkannt werden, so betreibbar ist, daß sie eine Anwendereingabe dritter Daten empfängt, die für eine oder mehrere der spezifizierten Funktionen Parameter spezifizieren, die die Funktion, die ausgeführt werden soll, partikularisieren, und so, daß als Antwort auf die hiermit spezifizierten Parameter eine Befehlssequenz für die Ausführung der spezifizierten Funktionen in der definierten Sequenz erzeugt wird.
Außerdem kann die Verarbeitungseinrichtung so beschaffen sein, daß sie eine Textdatei für jeden der Blöcke erzeugt; aus den Textdateien eine Skriptdatei erzeugt; und aus der Skriptdatei die Befehlssequenz erzeugt.
Entsprechende Verfahren werden ebenfalls geschaffen.

KURZBESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 zeigt ein Telekommunikationsnetz mit Vermittlungen, die mit der Kundenanlage verbunden sind, wobei die Vermittlungen Sprachanwendungsplattformen enthalten;
Fig. 2 zeigt eine Sprachanwendungsplattform des in Fig. 1 gezeigten Typs genauer, der Speichervorrichtungen enthält zum Speichern von Befehlen zum Steuern der On-Line-Operation der Plattform;
Fig. 3 zeigt ein System zum Erzeugen von Befehlen für die Verwendung auf der in Fig. 2 gezeigten Plattform, daß eine Verarbeitungseinheit, Speichervorrichtungen und eine Sprachkarte zum Erzeugen und Erkennen von Sprachsignalen enthält;
Fig. 4 zeigt die in Fig. 3 gezeigte Sprachkarte genauer;
Fig. 5A zeigt eine Übersicht über die Operationen, die auf dem in Fig. 3 gezeigten System während der Dienstdefinition ausgeführt werden, einschließlich des Definierens einer Dienststruktur innerhalb einer graphischen Benutzerschnittstelle, des Überprüfens der Struktur, des Eingebens der Parameter für einen Block und des Aktualisierens der Parameter für einen Block innerhalb einer Blocktextdatei;
Fig. 5B zeigt eine Übersicht über die Operation, die auf dem in Fig. 3 gezeigten System während der Dienstsimulation und der Erzeugung des herunterladbaren Codes ausgeführt werden;
Fig. 6 zeigt eine Hardwareinitialisierungsprozedur, die von der Software automatisch ausgeführt wird, bevor die in Fig. 5A gezeigten Dienstdefinitionsprozeduren beginnen;
Fig. 7 zeigt die in Fig. 5A angegebene Prozedur zum Definieren einer Dienststruktur innerhalb einer graphischen Benutzerschnittstelle genauer;
Fig. 8 zeigt die Flußdiagrammüberprüfungsprozedur genauer, die in Fig. 5A angegeben ist;
Fig. 9 zeigt die graphische Benutzerschnittstelle, die als eine Einrichtung zum Definieren einer Dienststruktur in Fig. 7 gezeigt ist;
Fig. 10 zeigt die Prozedur genauer, die in Fig. 5A angegeben ist, zum Aktualisieren der Parameter innerhalb einer Blocktextdatei;
Die folgenden Zeichnungen zeigen Einzelheiten einer Blockvorlage, die zum Definieren einer Dienststruktur verwendet wird, sowie entsprechende Skriptdefinitionen, die definieren, wie die in der in Fig. 5A gezeigten Prozedur eingegebenen Parameter in eine entsprechende Textdatei abgebildet werden;
Fig. 11A zeigt eine Antwortblockvorlage, die einen "OK"-Knopf enthält;
Fig. 11B zeigt die Spezifikation des Skripts, das verwendet wird, wenn eine Textdatei aus Parametern erzeugt wird, die in das in Fig. 11A gezeigte Antwortblockformular eingegeben werden;
Fig. 12A und 12B zeigen ein Auflegeblockformular und seine entsprechende Skriptdefinition;
Fig. 13A und 13B zeigen ein Anwählblockformular und seine entsprechende Skriptdefinition;
Fig. 14A und 14B zeigen ein Übertragungsblockformular und seine entsprechende Skriptdefinition;
Fig. 15A und 15B zeigen ein Infoblockformular und seine entsprechende Skriptdefinition;
Fig. 16A und 16B zeigen ein DTMF-blockformular und seine entsprechende Skriptdefinition;
Fig. 17A, 17B und 17C zeigen ein Anfrageblockformular und seine entsprechende Skriptdefinition;
Fig. 18A und 18B zeigen ein Ja/Nein-blockformular und seine entsprechende Skriptdefinition;
Fig. 19A und 19B zeigen ein Aufzeichnungsblockformular und seine entsprechende Skriptdefinition;
Fig. 20A und 20B zeigen ein Abspielblockformular und seine entsprechende Skriptdefinition;
Fig. 21A und 21B zeigen ein Externblockformular und seine entsprechende Skriptdefinition;
Fig. 22A und 22B zeigen ein Stummelblockformular und seine entsprechende Skriptdefinition;
Fig. 23A und 23B zeigen ein Schaltblockformular und seine entsprechende Skriptdefinition;
Fig. 24A und 24B zeigen ein Testblockformular und seine entsprechende Skriptdefinition;
Fig. 25 bis 38 zeigen ein spezifisch ausgearbeitetes Beispiel eines Dienstes, der unter Verwendung der Werkzeuge implementiert worden ist, die in den vorangehenden Zeichnungen gezeigt worden sind;
Fig. 25 zeigt eine graphische Benutzerschnittstelle, die einen Antwortblock, einen DTMF-Block, einen ersten Infoblock, einen zweiten Infoblock und einen Auflegeblock enthält;
Fig. 26A und 26B zeigen den in Fig. 25 gezeigten Antwortblock und die resultierende Textdatei;
Fig. 27A und 27B zeigen den in Fig. 25 gezeigten DTMF-Block und die resultierende Textdatei;
Fig. 28A und 28B zeigen den in Fig. 25 gezeigten ersten Infoblock und die resultierende Textdatei;
Fig. 29A und 29B zeigen den in Fig. 25 gezeigten externen Block und die resultierende Textdatei;
Fig. 30A und 30B zeigen den in Fig. 25 gezeigten zweiten Infoblock und die resultierende Textdatei;
Fig. 31A und 31B zeigen den in Fig. 25 gezeigten Auflegeblock und die resultierende Textdatei;
Fig. 32 zeigt die Prozedur zum Erzeugen einer Seitendatei und einer Formulardatei unter Verwendung der in den Fig. 26 bis 31 gezeigten Textdateien;
Fig. 33 zeigt die Seitendatei, die gemäß der in Fig. 32 gezeigten Prozedur erzeugt worden ist;
Fig. 34 zeigt die Formulardatei, die gemäß der in Fig. 32 gezeigten Prozedur erzeugt worden ist;
Fig. 35 zeigt eine alternative Struktur zum Implementieren des in Fig. 25 gezeigten Dienstes, die einen Stummelblock enthält;
Fig. 36A und 36B zeigen den in Fig. 35 gezeigten Stummelblock und die resultierende Textdatei;
Fig. 37 zeigt eine weitere alternative Struktur zum Implementieren des in Fig. 25 gezeigten Dienstes, die einen modifizierten Infoblock enthält;
Fig. 38A und 38B zeigen das Formular für den in Fig. 37 gezeigten modifizierten Stummelblock und die resultierende Textdatei;
Fig. 39 zeigt die in Fig. 5B angegebenen Prozeduren zum Erzeugen der herunterladbaren Dienstanweisungen, die die Extraktion der Variablen und die Verarbeitung der Skriptdateien enthalten;
Fig. 40 zeigt die Extraktion der Variablen, die in Fig. 39 angegeben sind; und
Fig. 41 zeigt die Verarbeitung der Skriptdateien, die in Fig. 39 angegeben sind.

GENAUE BESCHREIBUNG EINER BEVORZUGTEN AUSFÜHRUNGSFORM

Die bevorzugte Ausführungsform bezieht sich auf die Erzeugung von Befehlen, die auf eine Sprachanwendungsplattform des Typs heruntergeladen werden können, der in einer Telephonvermittlung oder einer privaten Nebenstellenanlage verwendet wird. Die beschriebenen Techniken sind jedoch auch auf andere Situationen anwendbar, in denen mehrere parametergesteuerte Operationen verknüpft sind, um eine logisch gesteuerte Anwendung zudefinieren.

DIE ANWENDUNGSUMGEBUNG

Ein Telekommunikationsnetz ist in Fig. 1 gezeigt und besitzt mehrere Hauptvermittlungen 15, die jeweils mit mehreren lokalen Vermittlungen 16 verbunden sind. Jede lokale Vermittlung ist mit mehreren lokalen Leitungen 17 verbunden, die ihrerseits mit einer Endanlage 18 eines Kunden verbunden sind, wie zum Beispiel einem herkömmlichen Sprachtelephon.
Jede lokale Vermittlung 16 empfängt und sendet analoge Signale von und zu den Kundenendgeräten 18. Bei den lokalen Vermittlungen werden analoge Signale für die Digitalübertragung zu den Hauptvermittlungen 15 codiert, wobei die digitalen Signale, die von den Hauptleitungen empfangen werden, decodiert werden für die analoge Übertragung im lokalen Netz. Digitale Signale werden zwischen den Vermittlungen über Hauptleitungen 19 übertragen in Form eines Zeitbereich-Multiplex mit 2 Megabit pro Sekunde von 30 digitalisierten Sprachkanälen plus 2 digitalisierten Signalisierungskanälen.
Eine Hauptvermittlung 15 enthält Sprachanwendungsplattformen 20, die mit der Vermittlung über einen 2-Megabit-Multiplex kommunizieren. Somit kann die für jede Sprachanwendungsplattform vorgesehene Hardware 30 Telephonkanäle handhaben.
Eine Sprachanwendungsplattform ist in Fig. 2 gezeigt und weist eine Leitungsschnittstellenschaltung 21, einen Sprachprozessor 22 und programmierbare Verarbeitungsvorrichtungen 23 auf. Ein 32-Kanal-Multiplex (30 Sprachkanäle plus 2 Signalisierungskanäle) wird der Leitungsschnittstellenschaltung 21 über eine digitale Übertragungsleitung 24 zugeführt. Die Leitungsschnittstellenschaltung antwortet auf Signalisierungsbefehle und identifiziert jeden der Sprachkanäle für die anschließende Verarbeitung.
Eine Sprachanwendung wird üblicherweise durch einen ankommenden Ruf eingeleitet. Genauer identifizieren die auf einem Signalisierungskanal enthaltenen Informationen das Vorhandensein eines ankommenden Rufes für die Leitungsschnittstellenschaltung 21. Die Leitungsschnittstellenschaltung kommuniziert ihrerseits mit den Prozessoren 23 über einen Datenbus 25, identifiziert anfangs, daß ein bestimmter Kanal die Verwendung eines Sprachdienstes wünscht, und identifiziert anschließend den bestimmten erforderlichen Dienst.
Die Sprachanwendungsplattform kann viele unterschiedliche Operationen ausführen in Reaktion auf Anfragen, die von Kunden durchgeführt werden. Diese Dienste werden in Reaktion auf Befehle ausgeführt, die in einer Speichervorrichtung 26 wie zum Beispiel einem Festplattenlaufwerk gespeichert sind, wobei die bestimmten Befehle für einen angefragten Dienst nur dann in den programmierbaren Prozessor geladen werden, wenn ihr bestimmter Dienst angefordert worden ist.
Die Anfragen von einem Kunden können in Form von Tönen oder in Form von Schleifenunterbrechungen übertragen werden, die dazu führen, daß die Daten über den Datenbus 25 zu den programmierbaren Prozessoren 23 übertragen werden. Nachdem die Befehle für eine bestimmte Sprachanwendung in den programmierbaren Prozessor 23 aus der Speichervorrichtung 26 geladen worden sind, geben die programmierbaren Prozessoren 23 bei Bedarf Befehle an die Leitungsschnittstellenschaltung 21 und an den Sprachprozessor 22 über den Datenbus 22 aus. Somit können komprimierte Sprachaufzeichnungen zum Sprachprozessor 22 übertragen werden, der dazu dient, die Sprache zu dekomprimieren und die dekomprimierte Sprache zur Leitungsschnittstellenschaltung zuzuführen über einen Sprachbus 27, der seinerseits die Sprache zum Kommunikationskanal 24 weiterleitet, woraufhin sie im wesentlichen in derselben Weise wie jedes andere Sprachsignal verarbeitet wird.
Die von der Leitungsschnittstellenschaltung 21 empfangene Sprache wird ferner zum Sprachprozessor über den Sprachbus 27 übertragen. Wenn es für den Sprachprozessor erforderlich ist, Sprachmuster zu erkennen, werden Sprachschablonen (oder üblicherweise verdeckte Markov-Modelle) aus der Speichervorrichtung 26 heruntergeladen und dem Sprachprozessor 22 über den Datenbus 25 unter der Steuerung des programmierbaren Prozessors 23 zuge führt.
Üblicherweise ist die Entwicklung von Diensten, die für die Plattform zur Verfügung stehen, ein andauernder Prozeß, so daß neue Befehle über die Plattform erzeugt und in die Speichervorrichtung 26 geladen werden müssen. Gewöhnlich ist eine erhebliche Menge an Zeit und Fachwissen erforderlich, um neue Befehle für eine Sprachanwendungsplattform zu entwickeln.
Die Sprachanwendungsplattform arbeitet unter der Steuerung eines Betriebssystems, wie zum Beispiel demjenigen, das unter dem Handelsnamen UNIX geliefert wird. Ein Anwendungsprogramm, das in einer Hochsprache erzeugt worden ist, wie zum Beispiel C oder C++, kann kompiliert werden, um Be fehle zu erzeugen, die mit dem UNIX-Betriebssystem und der Hardware kompatibel sind, die die Sprachanwendungsplattform enthält. Diese Befehle werden anschließend in der Speichervorrichtung 26 gespeichert, die ein Festplattenlaufwerk sein kann, für die Verwendung bei Anforderung, wenn ein Anrufer einen bestimmten Dienst anfordert.
Irgendwelche Fehler, die in den Befehlen vorhanden sind, können dazu führen, daß die Plattform in einer Weise arbeitet, die für Kunden unannehmbar ist, was zu einer Enttäuschung des Kunden führt. Das Einschließen einer Sprachanwendungsplattform in eine Vermittlung erhöht die Kosten dieser Vermittlung, wobei diese Kosten nur dann gerechtfertigt sind, wenn von der Plattform ausreichend Gebrauch gemacht wird, sobald sie installiert worden ist. Die Kundenzufriedenheit ist eine wichtige Anforderung. Ferner können die Fehler dazu führen, daß die Plattform außer Dienst gestellt wird, was in Extremsituationen dazu führen kann, daß die gesamte Vermittlung betriebsunfähig wird.
Fehler werden üblicherweise in der Stufe des Schreibens eines Programms für einen Dienst in einer Hochsprache eingeführt, welches anschließend auf eine Anwendungsplattform heruntergeladen wird und zu Befehlen für die Plattform kompiliert wird. Das Schreiben eines Programms für einen Kundendienst ist ein zeitaufwendiger Prozeß, insbesondere wenn das resultierende Programm frei von Fehlern sein soll. Es besteht somit das Dilemma, daß es erwünscht ist, Kundendienste zu erzeugen oder so schnell wie möglich zu modifizieren, um vollen Nutzen aus den Markbedingungen zu ziehen, während gleichzeitig sichergestellt wird, daß keine Fehler vorhanden sind.
Es ist ferner möglich, daß eine bestimmte Anwendung, die an einem geographischen Ort perfekt arbeitet, Modifikationen erfordert, so daß sie in einer annehmbaren Weise an einem anderen Ort arbeitet, insbesondere wenn Spracherkennung verwendet wird, wobei die Verwendung der lokalen Sprache, Ideome und Dialekte berücksichtigt werden muß. Es ist somit möglich, Dienstbefehle zu konstruieren, die vollständig annehmbar sind, ohne daß Fehler vorhanden sind, die jedoch Modifikationen erfordern, um in einer bestimmten Umgebung zu arbeiten. Zum Beispiel kann eine Anwendung vorgesehen sein zum Erkennen der Wörter "yes" und "no", jedoch können in vielen Regionen, in denen die englische Sprache verwendet wird, unterschied liche Wörter verwendet werden, um dieselben Bedeutungen darzustellen.
Die vorliegende Ausführungsform ist auf ein verbessertes System zum Erzeugen von Dienstbefehlen für eine Sprachanwendungsplattform gerichtet. Die vorliegende Ausführungsform schafft ferner ein System zum Testen solcher Befehle, bevor sie auf die wirkliche Betriebsplattform heruntergeladen werden.

SYSTEMÜBERSICHT

Ein System zum Erzeugen und Testen von Befehlen zum Definieren von Diensten, die von einer Sprachanwendungsplattform ausgeführt werden, wird als eine Entwicklungsplattform bezeichnet. Eine Entwicklungsplattform ist in Fig. 3 gezeigt und basiert auf der Architektur, die gewöhnlich in Personalcomputern verwendet wird, und enthält eine Verarbeitungsvorrichtung 31, wie zum Beispiel einen 80386-Mikroprozessor, der von der Firma Intel geliefert wird, mit Zugriff auf typischerweise 4 Megabyte an Schreib/Lese-Speicher (RAM) 32 und 40 Megabyte an Permanentspeicher in Form eines Festplattenlaufwerks 33. Die Hardware kann unter Verwendung von PC-Mutterplatinen mit zusätzlich hinzugefügten Karten konstruiert sein.
Ein Datenbus 34 erlaubt die Übertragung von Daten zwischen dem Prozessor 34 und dem Speicher 32 und ist ebenfalls mit einer Schnittstellenkarte 35 und einer Sprachkarte 36 verbunden. Die Schnittstellenkarte 35 ist ihrerseits mit einem Monitor 37, einer Tastatur 38 und einer Maus 39 verbunden, um die Kommunikation mit einem Operator zu ermöglichen. Die Sprachkarte 36 ist ihrerseits mit einem Telephon 40 verbunden, so daß ein Operator mit dem System mittels Sprache und mittels Telephonsignalisierung kommunizieren kann.
Die Sprachkarte 36 ist in Fig. 4 genauer gezeigt und enthält eine Telephonleitungsschnittstellenschaltung 41, einen Prozessor 42, einen Codierer-Decodierer 43, einen Bitratenumsetzer 44 und eine Sprachextraktions- und Erkennungsschaltung 45. Die von einem Telephon 40 empfangene Sprache wird der Telephonleitungsschnittstelle 41 zugeführt und anschließend in eine digitale Form umgesetzt bei 64 Kilobit pro Sekunde mittels des Codierer-Decodierers 43. Der Ausgang des Codierer-Decodierers 43 wird der Spracherkennungsschaltung 45 zugeführt, die in Reaktion auf die vom Hauptprozessor 31 zugeführten Musterdaten die bestimmten Wörter und Phrasen identifiziert. Die Daten, die das Auftreten eines bestimmten Sprachelements, das von der Erkennungsschaltung 45 erfaßt wird, darstellen, werden dem Steuerprozessor 42 zugeführt.
Die Sprache vom Codierer-Decodierer 43 wird ferner dem Bitratenumsetzer 44 zugeführt, der das Sprachsignal komprimiert, wodurch es effizient auf dem Festplattenlaufwerk 33 gespeichert werden kann. In ähnlicher Weise werden Sprachnachrichten auf der Festplatte 33 in komprimierter Form gespeichert und vom Umsetzer 44 für die Übertragung zum Telephon 40 über den Codierer-Decodierer 43 und die Schnittstelle 41 dekomprimiert. Die Signalisierung vom Telephon 40 wird als solche interpretiert von der Schnittstelle 41, wobei die Daten, die die Signalisierung definieren, direkt dem Steuerprozessor 42 zugeführt werden.
Die auf der Anwendungsentwicklungsplattform laufende Software enthält ein Betriebssystem, wie zum Beispiel MS-DOS, das von der Firma Microsoft geliefert wird, ein graphisches Betriebssystem, wie zum Beispiel WINDOWS, das ebenfalls von Microsoft geliefert wird, sowie ein Diensterzeugungswerkzeug, das in einer Hochsprache wie zum Beispiel Visual Basic geschrieben sein kann; obwohl diese Tatsache für den Dienstentwickler, der es verwendet, nicht von Bedeutung ist.
Die Prozedur zum Entwerfen eines Dienstes für eine Sprachanwendungsplattform des in Fig. 2 gezeigten Typs ist in den Fig. 5A und 5B gezeigt.
Im Schritt 51 wird die Dienststruktur definiert durch Verbinden der funktionalen Blöcke miteinander in einem Flußdiagramm. Eine graphische Benutzerschnittstelle wird verwendet, um die Operationen des Auswählens, Positionierens und Verbindens der Blöcke durchzuführen. Im Schritt 52 wird die im Schritt 51 definierte Struktur überprüft, d. h. die Topologie der Verbindungen zwischen den Blöcken wird analysiert, um zu ermitteln, ob die Struktur gültig ist.
Wenn die Struktur nicht gültig ist, kehrt die Steuerung vom Schritt 53 zum Schritt 51 zurück. Somit kann die Dienststruktur umdefiniert werden und erneut geprüft werden, bis eine gültige Struktur erzeugt wird, woraufhin die Steuerung zum Schritt 54 vorrückt. Im Schritt 54 wird gefragt, ob irgendeiner der Steuerblöcke für die Parametereingabe zur Verfügung steht, wobei dann, wenn dies zutrifft, eine Auswahl eines solchen Blocks durchgeführt wird. Die Blockparameter erlauben die Definition der Daten, die für die Operation eines Blocks erforderlich sind, wie zum Beispiel den Text einer Nachricht, die einem Anrufer vorgespielt wird, wenn ein Anruf für den Dienst empfangen wird.
Im Schritt 55 werden Parameter für den ausgewählten Block eingegeben, wobei im Schritt 56 Parameterwerte in einer zugehörigen Textdatei für den Block aktualisiert werden. Diese Blockparameter werden entsprechend den Regeln einer Skriptsprache geschrieben, weshalb die Textdateien von einem menschlichen Operator verstanden werden können. Die Blockparameter können optional oder obligatorisch sein, wobei das System nicht zur nächsten Stufe vorrückt, bis alle obligatorischen Parameter in allen im Dienst verwendeten Blöcke eingegeben worden sind. Die Parametereingabe wird wiederholt, bis Schritt 54 feststellt, daß kein Block für eine Parametereingabe ausgewählt ist, woraufhin die Steuerung zum Schritt 57 der Fig. 5B geleitet wird.
Sobald die Blockparameter eingegeben worden sind, wurde der Dienst definiert. Schritt 57 der Fig. 5B markiert den Beginn der nächsten Stufe der Diensterzeugung, welche die Dienstsimulation ist. Im Schritt 57 wird die Dienstsimulation auf der Diensterzeugungsplattform durchgeführt, welche dieselbe Hardware ist, auf der die Schritte 51 bis 56 ausgeführt worden sind.
Im Schritt 58 wird geprüft, ob die im Schritt 57 durchgeführte Dienstsimulation erfolgreich war, wobei bei einem negativen Ergebnis die Steuerung zum Schritt 51 zurückkehrt, so daß die Dienstdefinitionsschritte 51 bis 56 erneut implementiert werden können, um einen erfolgreichen Dienst zu definieren.
Wenn die im Schritt 57 ausgeführte Dienstsimulation erfolgreich ist, was dazu führt, daß die im Schritt 58 gestellte Frage positiv beantwortet wird, werden die Textdateien, die ein Skript für jeden der individuellen Blöcke enthalten, auf eine Sprachanwendungsplattform geladen, wodurch eine Dienstsimulation von der Plattform im Schritt 59 ausgeführt werden kann. Erneut wird im Schritt 60 geprüft, ob die im Schritt 59 ausgeführte Simulation auf der Sprachanwendungsplattform erfolgreich war, wobei dann, wenn die Antwort negativ ausfällt, die Steuerung erneut zum Schritt 5 1 zurückkehrt, so daß der Dienst neu definiert werden kann auf der Diensterzeugungsplattform.
Somit gibt es zwei Stufen der Simulation - die erste wird auf dem Entwicklungssystem durchgeführt, auf dem der Dienst erzeugt wird, während die zweite auf einer separaten Plattform durchgeführt wird, die eine Sprachanwendungsplattform sein kann wie zum Beispiel diejenige, für die der Dienst entwickelt wird. Sobald beide Stufen der Simulation erfolgreich abgeschlossen sind, verzweigt bei Schritt 60 die Steuerung zur nächsten Stufe der Diensterzeugung, welche die Codeerzeugung ist.
Im Schritt 61 werden die Skriptdateien, die den Dienst definieren, in einen herunterladbaren C++-Code auf der Diensterzeugungsplattform übersetzt. C++ ist eine höchst transportable Sprache, weshalb der im Schritt 61 erzeugte Code dazu geeignet ist, auf eine Vielzahl von Sprachanwendungsplattformen heruntergeladen zu werden, die möglicherweise unterschiedliche Konfigurationen an Hardware, Software und Betriebssystem aufweisen.
Im Schritt 62 wird der im Schritt 61 erzeugte herunterladbare C++-Code in eine Sprachanwendungsplattform geladen, wobei im Schritt 63 bei Bedarf zugehörige C++-Programme ebenfalls in die Plattform geladen werden. Somit ist es möglich, daß die vom Diensterzeugungswerkzeug erzeugten Befehle Aufrufe für andere zugehörige Programme enthalten, die auf der Sprachanwendungsplattform selbst ausgeführt werden.
Somit werden im Schritt 64 geladene C++-Programme in ausführbaren plattformspezifischen Code kompiliert, wobei im Schritt 65 diese Programme so angeordnet werden, daß sie auf der Sprachanwendungsplattform laufen, wodurch die Sprachanwendung in einen Live-Zustand versetzt wird.

DIENSTERZEUGUNG UND ÜBERPRÜFUNG

Vor dem Schritt 51 wird die Diensterzeugungsplattform initialisiert, um einen Startpunkt für die Erzeugung eines Dienstes zu schaffen. Die Initialisierungsschritte werden automatisch durchgeführt von der Systemerzeugungssoftware und sind in Fig. 6 genauer gezeigt.
Im Schritt 66 wird ein rollbarer Flußdiagrammentwurf erzeugt unter Verwendung von Unterroutinen, die als Teil des Betriebssystems zur Verfügung gestellt werden, das unter dem Handelsnamen "WINDOWS" geliefert wird, wobei ein rollbares Fenster erzeugt wird durch Plazieren eines Fensters, das größer ist als die Bildschirmgröße, hinter einem zweiten Fenster, das den gesamten Bildschirm belegt. Somit kann das größere Fenster relativ zum kleineren Fenster bewegt werden, wodurch der Eindruck eines Entwurfes entsteht, der größer ist als derjenige auf dem Bildschirmbereich, der relativ zum Bildschirm gerollt wird.
Im Schritt 67 wird ein Menü der funktionalen Erstellungsblöcke erzeugt, aus dem einzelne Erstellungsblöcke ausgewählt werden können für die Plazierung auf dem rollbaren Entwurf. Im Schritt 68 werden zusätzliche Pull-down- Menüs definiert, die die verschiedenen Befehle bereitstellen, die für die Parametereingabe und für die Navigation durch den Prozeß der Diensterzeugung auf der Diensterzeugungsplattform erforderlich sind. Im Sehritt 69 wird ein Dienstname von der Diensterzeugungsplattform angefordert, der anschließend, nachdem er vom Benutzer eingegeben worden ist, von der Diensterzeugungssoftware gelesen wird und auf dem Bildschirm angezeigt wird. Anschließend sind nach dem Schritt 69 alle Befehle, die zum Erzeugen einer Umgebung zum Definieren eines Dienstes erforderlich sind, ausgeführt worden, wobei ein Operator anschließend mit der Dienstdefinition fortfahren kann.
Prozeduren zum Definieren eines Dienstes (Schritte 51-56) sind in Fig. 7 genauer gezeigt. Beim Schritt 65 wird ein Erstellungsblock ausgewählt durch die Operation der Maus 39. Dies umfaßt das Ausrichten der Maus so, daß der angezeigte Cursor über einen bestimmten Block im Blockmenü erscheint. Ein Mausknopf wird gedrückt und niedergehalten, so daß der Block sich selbst als ausgewählt identifiziert durch Ändern der Farbe. Weitere Bewegungen der Maus bei niedergehaltenem Mausknopf führen dazu, daß der Block über den Entwurf "gezogen" wird. Nach der Positionierung wird der Mausknopf losgelassen, wodurch der Erstellungsblock losgelassen wird und eine funktionale Kopie des Blocks auf dem Entwurf zurückgelassen werden kann, woraufhin er seine ursprüngliche Farbe annimmt.
Im Schritt 77 wird geprüft, ob ein weiterer Erstellungsblock erforderlich ist, wobei dann, wenn dies positiv beantwortet wird, die Steuerung zum Schritt 75 zurückkehrt. Es wird angenommen, daß jeder der verfügbaren Erstellungsblöcke auf dem Entwurf beliebig oft kopiert werden kann, sofern Platz verfügbar ist. Wenn ein Flußdiagramm sehr groß ist und nicht genügend Raum auf dem Entwurf verfügbar ist, können Unterentwürfe erzeugt werden, die auch als Seiten bezeichnet werden.
Nachdem die erforderlichen Erstellungsblöcke auf dem Entwurf plaziert worden sind und im Schritt 77 die Frage negativ beantwortet worden ist, werden logische Verbindungen definiert, um den logischen Fluß zwischen den Erstellungsblöcken zu spezifizieren.
Im Schritt 78 wird ein Quellenerstellungsblock ausgewählt durch Positionieren des Cursors über einen Block mittels der Maus, woraufhin der ausgewählte Block seine Farbe ändert, um zu zeigen, daß er ausgewählt worden ist.
Nachdem der Quellenerstellungsblock ausgewählt worden ist, wird ein Zielerstellungsblock ausgewählt durch weiteres Betätigen der Maus im Schritt 79. Nach der Auswahl des Zielerstellungsblocks wird eine Verbindung im Schritt 80 vom Quellenblock zum Zielblock gezeichnet, wobei die Farbe des Quellenblocks zu seiner ursprünglichen Farbe zurückkehrt. Die Richtung des Ablaufs wird ferner dargestellt im Diagramm mittels eines Pfeilkopfes, der vom Quellenerstellungsblock zum Zielerstellungsblock zeigt.
Im Schritt 81 wird ein Name für die Verbindung spezifiziert, der aus einem Pull-down-Menü mögliche Verbindungsnamen abgeleitet wird, die für den ursprünglichen Quellenerstellungsblock geeignet sind. Ein Vorgabename kann "OK" sein, was spezifiziert, daß der Ablauf richtig arbeitet und zur nächsten Stufe vorrücken kann. Alternativ können mehrere Verbindungen von einem einzelnen Erstellungsblock ausgehen, zum Beispiel können zwei Verbindungen vom Erstellungsblock ausgehen, wobei eine erste eine Antwort "ja" darstellt und eine zweite eine Antwort "nein" darstellt. Andere Optionen können möglich sein, wie zum Beispiel ein Bereich von Zahlen oder logischen Bedingungen, wie zum Beispiel "wahr" (true) und "falsch" (false).
Überprüfungsprozeduren, die im Schritt 52 angegeben sind, sind in Fig. 8 genauer gezeigt. Im Schritt 84 wird geprüft, ob die Erstellungsblöcke eine korrekte Anzahl von Ausgangsverbindungen aufweisen. Die Anzahl der Ausgangsverbindungen, die von einem Erstellungsblock ausgehen, bezieht sich direkt auf die von diesem Erstellungsblock ausgeführten Funktionen, wodurch es möglich ist für die Software, eine Diskrepanz zwischen der Anzahl der definierten Ausgangsverbindungen und der durch die logische Funktion des Blocks angenommenen Anzahl zu erfassen. Es ist jedoch zu beachten, daß die Anzahl der Eingangsverbindungen auf diese Weise nicht vorhergesagt werden kann.
Beim Schritt 85 wird geprüft, ob irgendeine der Erstellungsblockverbindungen dupliziert worden ist. Somit kann ein Erstellungsblock zwei Ausgänge erfordern, wobei zwei Ausgänge in der Gesamtstruktur vorhanden sein können, wodurch die Struktur den im Schritt 84 durchgeführten Test besteht. Wenn jedoch zum Beispiel zwei Ausgänge vorgesehen sind, kann es erforderlich sein, Ausgangsverbindungen zu besitzen, die zum Beispiel "ja" und "nein" spezifizieren, wobei es möglich ist, daß beide Verbindungen als "ja" identifiziert worden sind, wobei dieser Zustand, eine Duplizierung, im Schritt 85 erkannt wird.
Im Schritt 86 wird geprüft, ob irgendeiner der Erstellungsblöcke keine Eingangsverbindung aufweist, da dann, wenn keine Eingangsverbindung vorhanden ist, es nicht möglich ist für die Steuerung, in diesen Block vorzurücken, wobei ein Fehler vorhanden sein muß.
Es können Verbinderblöcke vorhanden sein, die das ästhetische Erscheinungsbild der Verbindungen verbessern. Außerdem können Verbinderblöcke verwendet werden, um zwei oder mehr Ausgangsverbindungen zu einer einzelnen Eingangsverbindung zu kombinieren. Alle Verbinder sollten jedoch einen Ausgang und wenigstens einen Eingang aufweisen. Im Schritt 87 wird geprüft, um sicherzustellen, daß alle Verbinder wenigstens einen Eingang und wenigstens einen Ausgang aufweisen.
Im Schritt 88 wird geprüft, um sicherzustellen, daß keine der Verbinder mehr als einen Ausgang aufweist. Es ist zu beachten, daß ein Verbinder nur einen Ausgang aufweisen kann, unter der Voraussetzung, daß der Ausgang von einem Verbinder nur in einer Richtung laufen kann. Wie in Schritt 53 in Fig. 5A gezeigt können dann, wenn die Überprüfung erfolgreich ist, Parameter in die Blöcke eingegeben werden.
Die Initialisierungsprozeduren, die in Fig. 6 genauer gezeigt sind, führen zu einem angezeigten Bildschirm des Typs, der in Fig. 9 gezeigt ist. Der Bildschirm zeigt ein Menü 91 der verfügbaren Blöcke zusammen mit einem rollbaren Entwurf 93. Der Entwurf wird gerollt durch Plazieren des Mauszeigers über einem angezeigten Pfeil 93, 94, 95 oder 96. Das Aktivieren des Pfeils 93 führt dazu, daß der Entwurf nach unten gerollt wird, so daß die oberen Bereiche des Entwurfes über das Betrachtungsfenster angezeigt werden. In ähnlicher Weise führt die Betätigung des angezeigten Pfeils 94 dazu, daß der Entwurf nach oben gerollt wird, so daß seine unteren Bereiche durch das Fenster angezeigt werden. Eine ähnliche Betätigung der Pfeile 95 und 96 führt dazu, daß der Entwurf nach links bzw. nach rechts gerollt wird. Somit ist es durch Betätigung dieser Pfeile möglich, den Entwurf so zu rollen, daß ein beliebiger Bereich des Entwurfes durch das Betrachtungsfenster angezeigt wird.
Die Erstellungsblöcke, die aus dem Blockmenü 91 ausgewählt werden können, umfassen die Blöcke für "Antwort" (Answer), "Auflegen" (Hangup), "Anwählen" (Dialout), "Transfer" (Übertragen), "Info", "DTMF", "Anfrage" (Query), "Ja/Nein" (Yes/No), "Aufzeichnen" (Record), "Abspielen" (Play), "Extern" (External), "Stummel" (Stub), "Schalten" (Switch), "Test", "Verbinder" (Connector) und "Seite" (Page).
Nachdem ein Flußdiagramm mit Blöcken definiert und überprüft worden ist, ist es möglich, Blöcke auf einer weiteren Seite zu erzeugen durch Auswählen des Seitenblocks. Wenn ein Seitenblock ausgewählt wird, wird er auf dem Entwurf in ähnlicher Weise angezeigt wie die anderen Blöcke, die auf dem Entwurf angezeigt werden können. Bei dem Auswählen des Seitenblocks jedoch durch Klicken eines Mausknopfes während des Zeigens auf den Seitenblock, wird eine weitere Entwurfseite angezeigt, auf die weitere Blöcke kopiert werden können. Somit stellt ein Seitenblock einen gesamten Entwurf auf einer niedrigeren Ebene dar, wobei er selbst einen Entwurf für Operationsblöcke bietet, die darauf beschrieben werden sollen.
Die Erstellungsblockparameter werden eingegeben durch Auswählen eines spezifischen Blocks über eine geeignete Betätigung der Maus, was zu einem Blockbeispiel führt, das geöffnet wird für diesen spezifischen Block. Eine Blockvorlage bietet den Mechanismus, mit dem der Block einen Namen erhält, woraufhin die Blockparameter in eine entsprechend bezeichnete Blocktextdatei geschrieben werden.
Jeder Block zeigt einen Soft-Knopf an, der mit "OK" markiert ist. Die Betätigung dieses Knopfes mittels der Maus führt dazu, daß ein Programm ausgeführt wird, das die innerhalb des Blocks eingesetzten Parameter in die entsprechende Textdatei in Form eines Skripts schreibt.
Ein Beispiel des Schreibens von Daten, die für einen Block definiert sind, in eine Textdatei ist in Fig. 10 gezeigt. Im Schritt 101 wird die Routine eingeleitet in Reaktion darauf, daß ein Operator den "OK"-Knopf auf dem entsprechenden Block auswählt. Im Schritt 102 wird geprüft, um sicherzustellen, daß die obligatorischen Parameter vorhanden sind. Somit prüft der Schritt 102, ob der Block einen Namen erhalten hat, und ob die für die Operation dieses Blocks erforderlichen Parameter vom Operator angegeben worden sind. Selbstverständlich sind diese Parameter blockspezifisch und werden anschließend für jeden der Blöcke genauer beschrieben. Wenn irgendeiner der obligatorischen Parameter fehlt, wird die in Fig. 10 gezeigte Prozedur beendet und ein Operator wird aufgefordert, die Parameter über die geeignete Blockvorlage zu definieren.
Im Schritt 103 wird geprüft, um sicherzustellen, daß die in den Block eingegebenen Parameter gültig sind. Somit muß der Blockname durch Zeichen spezifziert sein, die als ein Dateiname innerhalb einer geeigneten Betriebsumgebung verwendet werden können. In ähnlicher Weise müssen definierte Zeitspannen innerhalb zulässiger sinnvoller Einschränkungen liegen.
Im Schritt 104 wird eine Textdatei geöffnet und durch den Namen des Blocks in Kombination mit der Erweiterung ".TXT" identifiziert. Anschließend wird im Schritt 105 Text in die im Schritt 104 geöffnete Datei geschrieben durch Schreiben des Namens eines Parameters gefolgt vom Parameterwert. Im Schritt 106 wird geprüft, ob ein weiterer Parameter vorhanden ist, wobei dann, wenn dies positiv beantwortet wird, die Steuerung zum Schritt 105 zurückkehrt.
Schließlich sind alle Parameter berücksichtigt worden und im Schritt 105 in die geeignete Textdatei geschrieben worden, was dazu führt, daß die Frage im Schritt 106 negativ beantwortet wird, wodurch die Steuerung zum Schritt 107 vorrückt. Im Schritt 107 wird die Blocktextdatei geschlossen und die Steuerung kehrt zu den Prozeduren zurück, die die interaktive graphische Benutzerschnittstelle implementieren, wie in Fig. 9 gezeigt ist.

EINZELHEITEN DER BLOCKVORLAGE

Die spezifische Blockvorlage wird im folgenden genauer beschrieben, zusammen mit einer Angabe der Textdateien, die bei Ausführung der in Fig. 10 genauer gezeigten Routine erzeugt werden. Es wird auf die in Schritt 105 ausgeführten Prozeduren Bezug genommen, wenn die Parameternamen und Werte in eine zugehörige Textdatei geschrieben werden. Es ist zu beachten, daß eine Textdatei, die eine Skriptdefinition der Parameter enthält, für jede Kopie eines auf dem Entwurf plazierten Blocks erzeugt wird. Ein eindeutiger Blockname wird definiert vom Dienstentwickler für jeden spezifischen Block, der innerhalb des Dienstes verwendet wird.
Die Zeilennummern, die in Fig. 11B und in den nachfolgenden Figuren gezeigt sind, werden zum Zweck der Erläuterung angegeben, und sind im wirklichen Skript, das erzeugt wird, nicht vorhanden. Ein Protokoll wurde angepaßt für die Beschreibung der Zeilen des Skripts, welches demjenigen ähnlich ist, das verwendet wird, wenn Computersprachen definiert werden. Der Text in gesperrter Schrift gibt einen Namen oder Parameter an, der vom Zusammenhang abhängt und somit innerhalb der formalen Spezifikation des Skripts nicht angegeben werden muß. Der Text zwischen eckigen Klammern ist optional und kann in einer bestimmten Instanz des Skripts für einen Block enthalten sein.
Eine Vorlage für einen Antwortblock ist in Fig. 11A gezeigt. Ein Antwortblock weist einen Dienst an, auf einen ankommenden Ruf zu warten. Eine vollständige Auflistung des Textes, die aus den Parametern abgeleitet werden kann, die innerhalb einer Antwortblockvorlage definiert sind, ist in Fig. 11B gezeigt.
Während Informationen in die in Fig. 11A gezeigte Vorlage eingegeben werden, kann ein Hilfeknopf 111 ausgewählt werden, was dazu führt, daß Text angezeigt wird, um Hilfe für einen unerfahrenen Operator zu bieten. In ähnlicher Weise kann nach dem Eingeben der Parameter in ein spezifisches Feld ein Löschknopf 112 ausgewählt werden, der die eben in diesem Feld vorgenommenen Modifikationen löscht. Wie in den nachfolgenden Figuren gezeigt ist, sind ein Hilfeknopf und ein Löschknopf für jede Blockvorlage vorgesehen.
Nachdem die Daten in den Antwortblock eingegeben worden sind, zeigt die Ausführung eines "OK"-Knopfes 113 eine Aktualisierung der Skriptdatei unter Verwendung der Daten in einem solchen Format an, wie in Fig. 11B gezeigt ist. Ein "OK"-Knopf dieses Typs ist in jeder Blockvorlage vorgesehen und führt, wie oben erwähnt, zur Ausführung einer Prozedur des in Fig. 10 gezeigten Typs.
Dem Antwortblock ist ein eindeutiger Name im Feld 114 verliehen, wobei dann, wenn mehr als ein Antwortblock innerhalb des Dienstes vorhanden ist, die Blöcke unterschiedliche Namen erhalten müssen, so daß sie anschließend unterschieden werden können. Der Blockname wird eingesetzt nach dem Blocknamenidentifizierer in der Zeile 1 der in Fig. 11B gezeigten Textdatei. Der erste Teil der Zeile identifiziert die Textdatei als zu einem Antwortblock gehörend durch den Text "tel_answer_block:", wobei wie oben erwähnt nach Ausführung des "OK"-Knopfes die erste Zeile in die Textdatei geschrieben wird, wie in Zeile 1 der Fig. 11B gezeigt ist, wobei der spezifische Blockname im Feld 114 identifiziert ist.
Eine Blockzeitüberschreitungsperiode ist im Feld 115 spezifiziert und kann inkrementiert oder dekrementiert werden unter Verwendung der Knöpfe 116 bzw. 117. Alternativ, wenn ein Soft-Kippelement 118 ungeprüft bleibt, wartet das System effektiv unbegrenzt am Antwortblock, bis ein Anruf empfangen wird. Somit spezifiziert die Blockzeitüberschreitungsperiode die Zeitspanne, während der das System auf einen ankommenden Anruf wartet, was in die Zeile 2 der Textdatei in der Form arg:"time to wait" gefolgt von der im Feld 115 eingegebenen Zahl geschrieben wird. Wenn jedoch das Soft-Kippelement 118 ungeprüft bleibt, wird Zeile 2 aus der Textdatei weggelassen, was angezeigt wird durch die Verwendung eckiger Klammern, die den Text der Zeile 2 umschließen.
In ähnlicher Weise wird eine Ruf-Antwort-Zeit im Feld 119 spezifiziert, die dazu führt, daß Daten in die Zeile 3 der Textdatei in der Form arg: "ring to ans time" gefolgt von einer Zahl, die die Zeitspanne darstellt, während der das System einen ankommenden Ruf rufen läßt, bevor er wirklich beantwortet wird, geschrieben werden. Das Soft-Kippelement 120 ist wiederum vorgesehen und führt dazu, daß Daten in die Zeile 3 nur dann geschrieben werden, wenn sie geprüft werden, während andernfalls Vorgabewerte verwendet werden.
Es ist für einen Kunden möglich, für den Dienst belastet zu werden, wobei die berechnete Zeit beginnen kann, wenn der Dienst einen Kundenanruf beantwortet, d. h. wenn ein Antwortblock auf einen ankommenden Ruf antwortet. Ein Soft-Kippelement 121 ist vorgesehen, daß dann, wenn es geprüft wird, dazu führt, daß der Anruf dem Konto des Kunden belastet wird. Dieses Feld führt dazu, daß die in Zeile 4 der Fig. 11B spezifizierten Daten in die Textdatei geschrieben werden in der Form arg:"start billing". Alternativ wird das Wort "true" durch das Wort "false" ersetzt, wenn das Soft-Kippelement 121 nicht geprüft wurde.
Der Bereich 122 enthält die Felder 123, 124, 125 und 126 für die Vorstummelprozeduren, die Vorarithmetikprozeduren, die Nacharithmetikprozeduren bzw. die Nachstummelprozeduren. Dies führt dazu, daß Zeilen des Textes von Zeile 6 bis Zeile 14 definiert werden und ähnliche Vorkehrungen in allen Blöcken innerhalb des Dienstes getroffen werden. Die Verwendung des Bereiches 122 wird im folgenden beschrieben.
Nachdem die aus dem Bereich 122 hergeleiteten Ausdrücke in die Textdatei geschrieben worden sind, werden die Bedingungen für die Fortsetzung zum nächsten Block spezifiziert. Somit identifiziert die Zeile 16 der Textdatei den nächsten auszuführenden Block, wenn die Ausführung des Antwortblocks erfolgreich ist. In ähnlicher Weise identifiziert die Zeile 17 den nächsten auszuführenden Block, wenn der Antwortblock abgebrochen wird. Es ist jedoch wichtig, zu beachten, daß diese spezifischen Blocknamen nicht innerhalb der Antwortblockvorlage definiert sind, sondern aus der auf dem Entwurf erzeugten Topologie hergeleitet werden.
Die Textdatei wird schließlich durch die Zeile 18 begrenzt, die "endblock" spezifiziert.
Eine Vorlage für einen Auflegeblock ist in Fig. 12A gezeigt. Ein Auflegeblock weist den Dienst an, einen anrufenden Kunden zu trennen, und wird daher eher am Ende eines Dienstes verwendet, nachdem die Kommunikation zwischen einem anrufenden Kunden und dem Dienst selbst beendet worden ist. Eine vollständige Auflistung des Textes, die aus dem innerhalb einer Auflegeblockvorlage definierten Parameter hergeleitet werden kann, ist in Fig. 12B gezeigt. Wie oben erwähnt worden ist, sind die Zeilennummern lediglich zum Zweck der Identifizierung spezifischer Zeilen innerhalb des Beispiels angegeben und stellen keine absoluten Zeilenpositionen des Codes in der Datei dar. Ein eindeutiges Namensfeld 131 ist zusammen mit einem Stummel- und Arithmetikbereich 132, einem OK-Knopf 133, einem Löschknopf 134 und einem Hilfeknopf 135 vorgesehen, die im wesentlichen den ähnlichen Bereichen äquivalent sind, die mit Bezug auf Fig. 11A beschrieben worden sind. Diese Bereiche sind ferner in allen nachfolgenden Blöcken vorhanden, wobei klar ist, daß ihre Operation im wesentlichen derjenigen ähnlich ist, die mit Bezug auf Fig. 11A beschrieben worden ist.
Unter bestimmten Betriebsbedingungen ist es möglich, einen Grund zum Auflegen im Feld 136 anzugeben, der anschließend in Zeile 2 der Textdatei spezifiziert wird. Ein Rollbalken 137 ist vorgesehen, dessen Aktivierung das System veranlaßt, durch die verfügbaren Auflege-Gründe zu rollen, die bestehen aus Normal, Unerreichbar, Besetzt, Vorübergehend außer Dienst, Überlastet oder Netzausfall.
In der Zeile 16 wird der nächste Block im Dienst spezifiziert, der erneut aus der Netztopologie hergeleitet wird, wobei der Blockbegrenzer "end block" in die Textdatei der Zeile 18 geschrieben wird.
Eine Vorlage für einen Anwählblock ist in Fig. 13A gezeigt. Ein Anwählblock erlaubt einem System, eine weitere Telephonnummer anzuwählen, und kann daher verwendet werden, wenn Informationen von einem weiteren System erhalten werden oder wenn ein Anruf weitergeleitet wird und dergleichen.
Eine anzuwählende Nummer oder eine Variable, die einen Ort identifiziert, an dem eine anzuwählende Nummer erhalten werden kann, ist im Bereich 141 spezifiziert, was dazu führt, daß ein Befehl in die Zeile 2 in der Form arg: "number to dial" gefolgt von der anzuwählenden Nummer oder einer Identifikation einer Variablen geschrieben wird.
Der Block kann in einem Dualton-Multifrequenzmodus oder in einem Schleifentrennmodus anwählen. Ein Soft-Kippelement ist im Formular vorgesehen, in welchem der Bereich 142 mittels der Maus ausgewählt werden kann, oder es kann exklusiv der Bereich 143 durch Betätigung der Maus ausgewählt werden. Wie in Fig. 13A gezeigt, wurde der Bereich 142 ausgewählt, wobei die Auswahl des Bereiches 143 durch eine geeignete Operation der Maus dazu führt, daß im Bereich 143 geprüft wird und im Bereich 142 nicht geprüft wird. Die Wählmodusauswahl führt dazu, daß ein Befehl in Zeile 3 in der Form in arg: "dialing mode" gefolgt von einer Angabe "M" für Multifrequenz oder "L" für Leitungsunterbrechung geschrieben wird.
Eine Zeitperiode kann im Bereich 144 gesetzt sein, die die Zeitperiode spezifiziert, während der das System auf einen zu beantwortenden Anruf wartet. Wenn das Feld 145 ungeprüft bleibt, ist es nicht erforderlich, eine Figur im Feld 144 einzugeben, wobei ein Rufzeitvorgabewert verwendet wird.
Das Prüfen des Feldes 145 führt dazu, daß der im Feld 144 eingegebene Wert in den optionalen Befehlen in Zeile 4 eingeschlossen wird, in der Form arg:"ring tone cl time" gefolgt von der ausgewählten Nummer. Die Rufzeitauswahl wird durchgeführt durch Betätigen der Rollbalken 146, so daß die Periode nur aus einem geschlossenen Satz verfügbarer Optionen definiert werden kann.
Die nächsten Blockoptionen werden in die Textdatei zwischen die Zeilen 16 und 21 geschrieben, wobei sie aus der Netztopologie hergeleitet werden, und wobei der Begrenzer end block in die Zeile 22 geschrieben wird.
Eine Vorlage für einen Übertragungsblock ist in Fig. 14A gezeigt. Ein Übertragungsblock kontaktiert eine weitere Telephonleitung und, falls erfolgreich, überträgt den anrufenden Kunden auf diese Leitung. Ein Feld 151 für eine zu wählende Nummer ist im wesentlichen dem Feld 141 der Fig. 13A ähnlich und führt dazu, das ähnliche Befehle in die Zeile 2 der Textdatei geschrieben werden. In ähnlicher Weise kann eine Antwortperiode im Feld 152 spezifiziert werden, was dazu führt, daß ähnliche Befehle in die Zeile 3 der Textdatei geschrieben werden. Die nächsten Blockbedingungen werden wiederum in die Zeilen 15 und 19 der Textdatei geschrieben, wobei der Begrenzer end block in die Zeile 20 geschrieben wird.
Eine Vorlage für einen Infoblock ist in Fig. 15A gezeigt. Ein Infoblock liefert Informationen an einen Kunden, was häufig in Reaktion auf eine getroffene Auswahl erleichtert wird. Eine vollständige Auflistung des Textes, die aus den innerhalb einer Infoblockvorlage definierten Parametern hergeleitet werden kann, ist in Fig. 15B gezeigt. Ein eindeutiger Blockname ist im Feld 153 spezifiziert, was dazu führt, daß ein Befehl in die Zeile 1 der Textdatei in der Form infoblock: gefolgt vom Namen geschrieben wird. Ein Soft-Kippelement 154 ist vorgesehen, daß dann, wenn es geprüft wird, einen Tastenkopfpuffer löscht, der Angaben über Auswahlen enthalten kann, die vorher von einem anrufenden Kunden durch Betätigen der Kundentastatur vorgenommen worden sind. Dies führt dazu, daß Befehle in die Zeile 2 der Textdatei in der Form arg:"flush buffer" gefolgt von einer Anzeige wahr oder falsch geschrieben werden, abhängig davon, ob das Soft-Kippelement 154 geprüft worden ist.
Ein Bereich 155 ist vorgesehen zum Halten von Einzelheiten der Nachrichten. Zwei Typen von Nachrichten können definiert sein. Normale Nachrichten werden definiert, wenn der Soft-Knopf 156 ausgewählt wird, wobei in ähnlicher Weise Schnellspur-Nachrichten definiert werden, wenn der Knopf 157 gewählt wird. Schnellspur-Nachrichten sind derjenige Typ, der eine Beschleunigung der Systemoperation für Kunden erlaubt, die mit dem Dienst vertraut sind oder mit Diensten dieses Typs vertraut sind.
Textdateien, die Nachrichtendaten oder Spracherkennungsdaten enthalten, werden in zwei Teile getrennt, unter der Voraussetzung, daß schließlich das vollständige Skript durch zwei Dateien pro Dienstseite spezifiziert wird, bestehend aus einer Seitendatei, die die logischen Operationen definiert, und einer Formulardatei, die die Nachricht und die Erkennungsdaten enthält.
Somit werden die nächsten Blockbefehle zwischen den Zeilen 14 und 20 spezifiziert, woraufhin in Zeile 21 der Begrenzer end block spezifiziert wird. Die Forminformationen werden ab Zeile 23 folgend spezifiziert. Somit zeigt die Zeile 23 den Start der Forminformationen mittels des Befehls info-form: gefolgt vom Blocknamen an.
Eine Sprachnachricht, die einem anrufenden Kunden im Normalbetrieb mitgeteilt wird, ist im Feld 158 spezifiziert, wobei eine Systemfehlernachricht im Feld 159 spezifiziert sein kann. Die innerhalb des Feldes 158 spezifizierte Nachricht führt dazu, daß Befehle in die Zeile 24 in der Formnachricht geschrieben werden, gefolgt von bestimmten Nachrichtendaten, die in Hochkommas enthalten sind, in einer vordefinierten Reihenfolge für jede der spezifizierten Nachrichten. Wenn in ähnlicher Weise eine Systemfehlernachricht innerhalb des Feldes 159 spezifiziert ist, werden Befehle in die Zeile 25 in den Formsystemfehler geschrieben, gefolgt von einem Systemfehlertext innerhalb von Hochkommas. Dies bildet das Ende der Nachrichteninformationen für den Block, wodurch die Textdatei durch einen Befehlendform in der Zeile 26 begrenzt wird.
Ein Beispiel für einen DTMF-Block ist in Fig. 16A gezeigt. Ein DTMF-Block ist so beschaffen, daß er eine DTMF-Signalisierung, d. h. eine Touch-Ton- Signalisierung, von einem anrufenden Kunden empfängt und anschließend in Reaktion auf die empfangenen Informationen Entscheidungen trifft. In den meisten Anwendungen ist daher der nächste zu verarbeitende Block abhängig von den aktuell empfangenen Informationen vom anrufenden Kunden in Form eines Tastendrucks. Eine vollständige Auflistung des Textes, die aus den innerhalb eines DTMF-Blockbeispiels definierten Parametern abgeleitet werden kann, ist in Fig. 16B gezeigt.
Ein Blockname ist im Feld 161 spezifiziert, was zu einem Befehl DTMF- block: führt, gefolgt vom Blocknamen, der in Zeile 1 geschrieben ist, und DTMF-form: gefolgt vom Blocknamen, der in Zeile 37 geschrieben ist. Somit werden die Befehle, die sich auf die logische Operation beziehen, nach Zeile 1 geschrieben, woraufhin die Nachrichteninformationen nach Zeile 37 spezifiziert werden.
Ein Soft-Kippelement 162 innerhalb eines Parameterbereiches 163 erlaubt einem Operator, auszuwählen, ob der Schlüsselkopfpuffer gelöscht werden soll, was dazu führt, daß ein Befehl in Zeile 2 in der Form arg: "flush buffer" geschrieben wird, gefolgt von einer Anzeige wahr oder falsch.
Ein DTMF-Block kann auf eine feste Anzahl von Ziffern oder auf eine veränderliche Anzahl von Ziffern antworten. Somit wird der Soft-Knopf 164 gewählt, wenn der bestimmte Block auf eine veränderliche Anzahl von Ziffern antworten soll, oder der Soft-Knopf 165 wird gewählt, wenn der Block auf eine feste Anzahl von Ziffern antworten soll. Wenn der Knopf 165 gewählt wird, wird die Anzahl der Ziffern, auf die das System antworten soll, innerhalb des Feldes 166 spezifiziert.
Dies führt dazu, daß ein Befehl in die Zeile 3 in der Form arg:"max digits" geschrieben wird, gefolgt von einer Zahl, die die maximale Anzahl der erwartenden Ziffern angibt.
Das Prüfen eines Soft-Kippelements 167 erlaubt eine Stumm-Zeitüberschreitungsperiode, die im Feld 168 spezifiziert wird, was wiederum dazu führt, daß ein Befehl in die Zeile 5 in der Form arg:"pre time out" geschrieben wird, gefolgt von einer Anzeige der Zeitüberschreitungsperiode.
Somit wartet der Block auf ankommende Töne für eine Periode, die durch die Stumm-Zeitüberschreitung spezifiziert wird. Alternativ, wenn das Soft- Kippelement 167 nicht geprüft wird, wird die Stumm-Zeitüberschreitungs- Vorgabeperiode verwendet.
Ein wichtiger Aspekt von DTMF-Blöcken ist die Definition, was geschieht, nachdem ein bestimmten DTMF-Ton empfangen worden ist. Diese Information ist definiert innerhalb der Topologie des Systems, wobei eine Analyse dieser Topologie dazu führt, daß Befehle zwischen die Zeilen 18 und 34 geschrieben werden, gefolgt vom Endblockbegrenzer in der Zeile 35.
Wie vorher erwähnt worden ist, spezifiziert die Zeile 37 den Start der Formularinformation. Eine erste Aufforderung muß im Feld 169 spezifiziert werden, was dazu führt, daß ein Befehl in die Textdatei bei Zeile 38 in der Form P1: geschrieben wird, gefolgt von der ersten Aufforderungsnachricht. Nachfolgende Aufforderungen, Hilfenachrichten, Gemurmel, Stille und Fehlernachrichten können ebenfalls spezifiziert werden, was dazu führt, daß Befehle in die nachfolgenden Zeilen bis zur Zeile 47 geschrieben werden. Schließlich wird das Ende der Datei spezifiziert durch den Begrenzer end form in der Zeile 50.
Ein Beispiel eines Anfrageblocks ist in Fig. 17A gezeigt. Dieser Block wird verwendet, um die gesprochene Antwort eines Anrufers auf eine Nachrichtenaufforderung zu erhalten. Er ermöglicht, daß ein Anrufer verbal mit dem Dienst kommuniziert, z. B. durch Vorlesen der Nummer auf einer Kreditkarte. Ein Soft-Kippelement 171 wird verwendet, um einen Piepton einzuschalten oder auszuschalten, der dem Anrufer anzeigt, wann er sprechen soll. Wenn dieses Soft-Kippelement geprüft wird, wird die Zeile 45 der Fig. 17 in die Formulardatei eingeschlossen, die erzeugt wird. Soft-Kippelemente, die die Optimierung des Spracherkennungsprozesses beeinflussen, sind vorgesehen für die Ziffernoptimierung 172 und die ZSML-Optimierung 173 (ZSML = zero space medium length). Die Ziffernoptimierung zeigt an, daß erwartete Antworten einzeln gesprochene Ziffern "0" bis "9" enthalten sollen, während die ZSML-Optimierung anzeigt, daß der Benutzer zwischen den gesprochenen Ziffern nicht pausieren darf. Die Ziffern- und ZSML-Optimie rung wird durch die in den Zeilen 3 bzw. 4 der Fig. 17B gezeigten Befehle ausgewählt.
Eine Spracherkennungsschablone ist im Feld 174 spezifiziert, so daß der mögliche Bereich von Antworten eine Schablone aufweist, mit der ankommende Sprachmuster verglichen werden. Die Spracherkennungssoftware muß daher z. B. nur zwischen zehn unterschiedlichen Wörtern (im Fall von "0" bis "9") unterscheiden. Die Spracherkennungsschablone führt zu einer Serie von gültigen Antwortzeilen, wie z. B. denjenigen, die in den Zeilen 29 bis 38 der Fig. 17C spezifiziert sind. Wenn ein Wort erkannt worden ist, wird es in die Kettenvariable eingesetzt, die durch einen im Feld 175 eingegebenen Namen spezifiziert ist und in Zeile 5 der Fig. 17B spezifiziert ist.
Die Sprecherabhängigkeit kann ausgewählt werden unter Verwendung von weichen Kippelementknöpfen im Feld 176, so daß von einem bestimmten Individuum komplexere Äußerungen erkannt werden können, als dies bei dem großen Bereich von Sprecherstilen möglich wäre, die gehandhabt werden müssen, wenn der Erkennungsprozeß sprecherunabhängig ist. Genaue Parameter können für die Sprecherabhängigkeit spezifiziert werden durch Auswählen des Parameterknopfes 177, was dazu führt, daß der Benutzer mit einem zusätzlichen Fenster konfrontiert wird, in den Parameter spezifiziert werden können. Diese zusätzlichen Parameter werden in den Zeilen 6 bis 14 der Fig. 17B spezifiziert.
Das Aufzeichnungsäußerungsfeld 178 erlaubt, daß die aktuelle Sprache digitalisiert und in einer Datei gespeichert wird, worauf anschließend von anderen Blöcken oder Programmen auf der Anwendungsplattform zugegriffen werden kann. Zum Beispiel kann dies verwendet werden als Teil eines automatisierten Telephonbeantwortungssystems, bei dem jede Nachricht für ein späteres Wiedergeben aufgezeichnet wird, wenn ein Kunde anfordert, daß seine Nachrichten abgespielt werden sollen. Aufzeichnungsäußerungsdaten sind spezifiziert in den Zeilen 15 bis 18 der Fig. 17B. Die Nachrichtenfelder "Gemurmel" (Mumble) und "Stille" (Silence) sind im Anfrageblock vorgesehen, um eine geeignete Antwort auf undeutliche Sprache bzw. Stille zu definieren.
Der in Fig. 18A gezeigte Ja/Nein-Block bietet eine ähnliche Funktion wie der obenbeschriebene Anfrageblock. In diesem Block werden nur zwei Wörter erkannt - ja und nein - wodurch die Spracherkennung vereinfacht wird, indem die Notwendigkeit für einen sprecherabhängigen Modus der Erkennung sowie der ZSML-Optimierung beseitigt werden. In allen anderen Aspekten ist die Operation dieses Blocks identisch mit dem Anfrageblock. Die Skriptspezifikation für den Ja/Nein-Block ist in Fig. 18B gezeigt.
Der in Fig. 19A gezeigte Aufzeichnungsblock wird verwendet, um eine Anrufernachricht aufzuzeichnen, wobei zuerst eine spezifische Nachrichtenaufforderung abgespielt wird. Der Dateiname, indem die digitalisierte Sprache gespeichert wird, ist im Fehl 179 spezifiziert. Die Bitrate der digitalisierten Sprache, oder die PCM-Rate, ist im Feld 180 spezifiziert. Ein Deskriptorfeld ist vorgesehen zum Beschreiben der Inhalte der Sprachdatei, z. B. "Kreditkartenadresse", oder kann eine Variable spezifizieren, die eine vorher spezifizierte Deskriptorkette enthält, wie z. B. "your second call taday was".
Die Aufzeichnungszeit und die endgültige Zeitüberschreitung können spezifiziert sein, um die maximale Länge einer Nachricht in Sekunden und die maximale Länge einer tolerierten Stille zu definieren, bevor der Block abbricht. Ein Kippelement "Akzeptiere lange Nachrichten" ist vorgesehen, das dann, wenn es geprüft wird, die Erzeugung einer Blockabbruchbedingung verhindert, wenn der Anrufer länger als die maximale Länge der aufgezeichneten Nachricht spricht (die Sprache jenseits der Zeitgrenze wird anschließend verworfen). Das vom Aufzeichnungsblock erzeugte Skript ist in Fig. 19B spezifiziert.
Ein Block ist in Fig. 20A genauer gezeigt. Dieser spielt eine oder mehrere vorher aufgezeichnete Nachrichten ab, die in spezifizierten Dateien gehalten werden, wie z. B. diejenigen, die durch Ausführung eines Aufzeichnungsblocks erzeugt worden sind. Mehrere der Dateinamen können im Dateinamenfeld 182 spezifiziert sein. Das vom Abspielblock erzeugte Skript ist in Fig. 20B spezifiziert.
Ein externer Block ist in Fig. 21A gezeigt. Dieser Block bietet eine Einrichtung einer Zweiwegekommunikation mit externen ausführbaren Programmen (z. B. einen EXE-Programm). Zum Beispiel kann ein externer Block einen Anruf zu einem Datenbankprogramm einer Firma durchführen, welches Argumente enthält, die den Namen des Anrufers und die Kundenkontonummer enthalten können. Die Datenbank kann anschließend die Einzelheiten des Kunden nachschlagen, und Informationen zurückgeben, die spezifische Daten enthalten, wie z. B. das aktuelle Schuldenniveau des Handelskontos des Kunden bei der Firma. Das von einem externen Block erzeugte Skript ist in Fig. 21B spezifiziert.
Ein Stummelblock ist in Fig. 22A gezeigt. Dieser Block ermöglicht, daß ANSI-C- oder C++-Quellcode in die Anwendung auf der Ebene der Graphikbenutzerschnittstelle eingesetzt wird. Der C- oder C++-Quellcode kann Variablen manipulieren und Routinen aufrufen, auf die von anderen Teilen des Blockdiagramms zugegriffen wird. Die Operation auf dieser Ebene kann jedoch ein genaues Wissen der C- oder C++-Betriebsumgebung erfordern, die von der Anwendungsentwicklungsplattform erzeugt wird. Kopfdateien, Bibliotheksdateien und vorkompilierte Objektdateien können für die Referenz durch den C- oder C++-Code spezifiziert werden, der im Stummelblock angegeben wird. Somit kann der C- oder C++-Code verwendet werden, um auf eine umfassende Hilfsmittelsoftware zuzugreifen, wie z. B. das für den externen Block angegebene Datenbankbeispiel.
Durch Schaffen eines Zugriffs auf diese Typen von Funktionen auf der C- oder C++-Ebene können der benutzerdefinierte C- oder C++-Code, die Hilfsmittelsoftware und die Systemsoftware effizient aufeinander zugreifen und gleichzeitig kompiliert werden. Dies ermöglicht die manuelle und automatisierte Optimierung, die am C- oder C++-Code vorgenommen wird, bevor er kompiliert wird, was zu einer schnelleren, effizienteren Laufzeitsoftware führt.
Ferner wird eine beträchtliche Flexibilität gewonnen für die Dienstanbieter, die Modifikationen am Dienst vornehmen möchten durch Modifizieren des C- oder C++-Codes, da das gesamte System in C oder C++ spezifiziert sein kann und somit auf der C- oder C++-Ebene modifiziert wird. Das von einem Stummelblock erzeugte Skript ist in Fig. 22B spezifiziert.
Ein Schaltblock ist in Fig. 23A gezeigt. Dieser Block bietet einen bedingten Test zum Auswählen, welcher der möglichen nachfolgenden Blöcke im Dienst der nächste ist. Ein Ausdruck im Feld 183 wird entsprechend der C-ähnlichen Ausdrucksterminologie ausgewertet. Wenn das Ergebnis hiervon gleich 0 ist, erhält der Boole'sche-Indikator den Wert "wahr", oder erhält den Wert "falsch", wenn dies ungleich 0 ist. Der Steuerungsablauf kann entsprechend den spezifischen Werten eines benutzerdefinierten Verbindungsetiketts umgeschaltet werden, wobei in diesem Fall ein benutzerdefiniertes Verbindungsetikett erforderlich ist für jeden Wert, den eine Variable annehmen kann. Das vom Schaltblock erzeugte Skript ist in Fig. 23B spezifiziert.
Ein Testblock ist in Fig. 24A gezeigt. Dieser Block ist ähnlich dem obenbeschriebenen Schaltblock, mit der Ausnahme, daß das Ergebnis nur den Wert "ja" (gleich 0) oder "nein" (ungleich 0) annehmen kann. Der Steuerungsablauf wird längs der Verbindungen verzweigt, die jeweils mit "ja" oder "nein" bezeichnet sind. Das für einen Testblock erzeugte Skript ist in Fig. 24B spezifiziert.

AUSGEARBEITETES BEISPIEL FÜR EINEN SPEZIFISCHEN DIENST

Die Diensterzeugungsprozeduren, die in Fig. 5A angegeben sind, werden im folgenden mit Bezug auf ein Beispiel eines derzeit arbeitenden Dienstes beschrieben. Der Dienst, der beschrieben wird, erlaubt einem anrufenden Kunden, eine spezifische Nummer anzurufen, um Informationen bezüglich einer Vorstellung wie z. B. einem Musikkonzert und dergleichen zu erhalten. Der Dienst identifiziert sich selbst und fordert einen anrufenden Kunden auf, den Knopf 1 zu drücken, um Informationen zu erhalten, die die Art der Vorstellung identifizieren, oder den Knopf 2 zu drücken, um Informationen zu erhalten, die die Verfügbarkeit von Sitzplätzen identifizieren. Nachdem die Informationen eines Typs geliefert worden sind, legt das System auf. Es ist somit klar, daß dieser Dienst hier lediglich als ein Beispiel angegeben wird, um zu zeigen, wie Dienste erzeugt werden können. In einem aktuell arbeitenden Dienst dieses Typs können Schleifen enthalten sein, so daß beide Typen von Informationen mit einem einzigen Anruf erhältlich sind, wobei höherwertige Aspekte enthalten sein können, die einem anrufenden Kunden erlauben, Sitzplätze zu buchen oder Informationen über Vorstellungen in der Zukunft zu erhalten.
Wie im Schritt 51 der Fig. 5A angegeben, umfaßt der erste Schritt das Definieren der Dienststruktur innerhalb der graphischen Benutzerschnittstelle. Nachdem die Initialisierungsprozedur, wie in Fig. 6 gezeigt, einen rollbaren Entwurf erzeugt hat mit einem Erstellungsblockmenü und Pull-Down-Menüs, wird ein Dienstname definiert und der Entwurf des Typs in der Fig. 9 angezeigt.
Um den oben identifizierten Dienst zu erzeugen, ist es erforderlich, einen Antwortblock aus den Menü 91 auszuwählen, der den ankommenden Anruf beantwortet. Anschließend ist es erforderlich, einen DTMF-Block auszuwählen, der den Kunden auffordert, eine Tastaturauswahl durchzuführen, und anschließend auf ein ankommendes Signal antwortet, das eine Ziffer 1 darstellt, und auf ein ankommendes Signal, das eine Ziffer 2 darstellt. Ein Infoblock ist erforderlich, um auf eine ankommende Ziffer 1 zu antworten, welcher seinerseits Informationen zum anrufenden Kunden überträgt, die den Typ der an einem bestimmten Tag verfügbaren Vorstellung identifizieren. Anschließend legt das System auf, so daß es erforderlich ist, einen Auflegeblock einzuschließen. Um auf ein ankommendes Signal zu antworten, das eine Ziffer 2 darstellt, ist es erforderlich, Informationen bezüglich der verfügbaren Sitzplätze zu erhalten. Diese Daten müssen selbstverständlich auf einer regelmäßigen Basis aktualisiert werden, weshalb das System offensichtlich mit einer Datenbank kommuniziert, die die Sitzplatzbuchungen verfolgt. Der Anruf zur externen Datenbank erfordert, daß ein zusätzlicher Code entwickelt wird, wobei dieser Code im Gesamtsystem mittels eines externen Blocks, eines unabhängigen Stummelblocks oder mittels eines Vorstummel- oder Nachstummel-Blocks, der innerhalb eines der anderen Blöcke enthalten ist, eingeschlossen werden kann. Nachdem die Informationen empfangen worden sind, ist ein zweiter Infoblock erforderlich, um diese Informationen dem anrufenden Kunden mitzuteilen, woraufhin das System erneut auflegt. Ein Auflegeblock kann viele Eingangsverbindungen aufnehmen, weshalb es nur erforderlich ist, einen Auflegeblock zu spezifizieren.
Eine Topologie, die den oben angegebenen Dienst spezifiziert, ist in Fig. 25 genauer gezeigt. Der Dienst wird durch einen Startblock 191 eingeleitet, der vom System automatisch vorgestellt wird, und der eine OK-Verbindung zu einem Antwortblock 192 aufweist, der den eindeutigen Namen ans1 erhalten hat. Eine OK-Verbindung verbindet den Antwortblock 192 mit dem DTMF- Block 193, der den eindeutigen Namen dtmf1 erhalten hat.
Im DTMF-Block wird in Reaktion auf eine vom Kunden gewählte Ziffer "1" die Steuerung vom DTMF-Block 193 zu einem ersten Infoblock 195 geleitet, dem der eindeutige Name info1 gegeben ist. Somit erhält die Verbindung zwischen dem DTMF-Block 193 und dem Infoblock 195 einen Verbindungsnamen "1".
In ähnlicher Weise wird der Verbindung zwischen dem DTMF-Block 193 und einem externen Block 194 der Verbindungsname "2" gegeben, wobei der externe Block 194 den eindeutigen Namen extn1 enthält. Eine OK-Verbindung vom Block 194 verbindet diesen mit einem zweiten Infoblock, der als "info2" identifiziert ist, was sich auf Informationen für den anrufenden Kunden bezieht, die vom externen Anruf erhalten werden, der im externen Block 194 durchgeführt wird. Nachdem diese Informationen zum Kunden weitergeleitet worden sind, legt das System auf, was durch die "OK"-Verbindung dargestellt wird, die den Infoblock 196 mit dem Auflegeblock 197 verbindet.
Der DTMF-Block 193 ist ferner mit dem Auflegeblock 197 mittels einer "Fehler"-Verbindung verbunden. Wenn somit ein Kunde keine Ziffer "1" oder Ziffer "2" eingibt, wird vom DTMF-Block 193 eine Fehlerbedingung identifiziert und das System legt unter der Steuerung des Auflegeblocks 197 auf. Der Auflegeblock 197 erhält den eindeutigen Namen hang1, woraufhin die Steuerung zum Endblock 198 weitergeleitet wird.
Nachdem die Übersicht der Diensttopologie spezifiziert worden ist, wie in Fig. 25 gezeigt, wird die Struktur überprüft, wie im Schritt 52 der Fig. 5A gezeigt ist, um sicherzustellen, daß sie intern konsistent ist und erlaubt, daß hieraus ein vollständig ausgearbeiteter Dienst entwickelt wird. Die in Fig. 25 gezeigte Struktur sollte dazu führen, daß die im Schritt 53 gestellte Frage positiv beantwortet wird, woraufhin die Blöcke für die Parametereingabe im Schritt 55 ausgewählt werden können und die Textdateien im Schritt 56 aktualisiert werden.
Blöcke können für die Parametereingabe in beliebiger Reihenfolge ausgewählt werden. Wenn ferner eine Blockvorlage aufgerufen worden ist, können Parameter in diesen Block in beliebiger Reihenfolge eingegeben werden. Die Ausführung des relevanten "OK"-Knopfes, wie z. B. des Knopfes 113 in Fig. 11A, führt dazu, daß die Parameter in eine Textdatei geschrieben werden, die die skriptcodierten Parameter enthält, wie z. B. diejenigen, die in Fig. 11B spezifiziert sind. Die Blockparameter können jedoch modifiziert werden, wobei die zugehörige Textdatei in ähnlicher Weise modifiziert werden kann durch eine weitere Betätigung des OK-Knopfes. In diesem Beispiel wird jedoch die Parameterisierung der Blöcke in einer bestimmten Sequenz beschrieben, wie sie derzeit von einem Operator beim Vervollständigen des Dienstes durchgeführt werden kann.
Der Antwortblock 192 wird ausgewählt, was dazu führt, daß eine Antwortblockvorlage des in Fig. 11A gezeigten Typs angezeigt wird. Eine Antwortblockvorlage für dieses bestimmte Beispiel ist in Fig. 26A gezeigt. Der Blockname ams1 wurde in das Blocknamenfeld eingegeben, was zu einem Befehl tel_answer_block: ans1 führt, der in die erste Zeile der in Fig. 26B gezeigten Textdatei geschrieben wird. Das Blockzeitüberschreitungs-Soft- Kippelement wurde nicht geprüft, weshalb der Dienst weiter auf den Antwortblock wartet, bis ein Anruf durchgeführt wird. Folglich ist es für einen zugehörigen Code nicht erforderlich, daß er in die Textdatei geschrieben wird.
In der Blockvorlage wurde eine Ruf-Antwort-Zeit spezifiziert, die dazu führt, daß in der nächsten Zeile der Textdatei der Befehl arg:"ring to ans time" enthalten ist. In ähnlicher Weise wurde das Starte-Berechnung-Soft-Kippelement geprüft, was dazu führt, daß die nächste Zeile der Textdatei den Befehl arg:"start billing" enthält.
Es wurden keine Arithmetik- oder Stummelfunktionen definiert, weshalb die nächste Zeile die nächsten Blockrichtungen enthält, schließlich gefolgt vom begrenzer end block.
Nach der Auswahl des OK-Knopfes für den Antwortblock, was zu einem Modifizieren der Textdatei führt, wird der DTMF-Block 193 ausgewählt und es werden Parameter hinzugefügt, wie in Fig. 27A gezeigt ist. Der Blockname dtmf1 wird spezifiziert, was zu einem ersten Befehl für die zugehörige Textdatei von dtmfblock:dtmf1 führt.
Das Soft-Kippelement für den Löschtasten-Kopfpuffer wird gesetzt, weshalb die nächste Zeile der Textdatei arg:"flush buffer" true spezifiziert. In ähnlicher Weise wurde die Ziffernkette auf die feste Option gesetzt und die maximale Anzahl der Ziffern wurde mit 1 spezifiziert. Somit enthält die nächste Zeile der in Fig. 27B gezeigten Textdatei den Befehl arg:"max digits" 1.
Das Stille-Zeitüberschreitung-Kippelement wurde gesetzt und die Stille- Zeitüberschreitungsperiode wurde mit 8 Sekunden spezifiziert. Somit enthält die nächste Zeile der Textdatei den Befehl arg:"pre-time out" 8.
Der DTMF-Block verzweigt den Steuerungsablauf längs einer von mehreren numerierten Flußlinien. Wenn somit der Anrufer die "1" auf der Tastatur drückt, wird der Ablauf längs der Flußlinie mit der Bezeichnung "1" weitergeleitet. In ähnlicher Weise kann der Ablauf längs der Ablauflinie mit der Bezeichnung "2" weitergeleitet werden. Das Skript für diese beiden Möglichkeiten ist gezeigt.
Der Start der Aufforderungsinformation wird spezifiziert durch eine Befehlszeile dtmf-form:dtmf1, wobei die nächste Zeile der Textdatei die Aufforderungsnachricht enthält, die im ersten Aufforderungsnachrichtenfeld eingegeben worden ist. Nach dem Auswählen des ersten Aufforderungsnachrichtenfeldes wird eine geeignete Nachricht eingesetzt, wie z. B. "Bitte drücken Sie Knopf 1 für Einzelheiten des Konzerts heute Abend oder drücken Sie Knopf 2 für die Sitzplatzverfügbarkeit". Dies führt zum folgenden Befehl in der nächsten Zeile p1:dtmf-form:dtmf1. Eine Systemfehlernachricht ist ebenfalls im Systemfehlerfeld in der Form "Entschuldigen Sie, es liegt ein technischer Fehler vor" enthalten. Dies führt zu einer Zeile an Text in der Form "Systemfehler: Entschuldigung, es liegt ein technischer Fehler vor". Das Ende der Textdatei und insbesondere das Ende der Formularinformationen wird anschließend durch den Befehl "end form" identifiziert.
Der Infoblock 195 kann anschließend ausgewählt werden, was dazu führt, daß eine Infoblockvorlage angezeigt wird, zu der Daten wie in Fig. 28A gezeigt hinzugefügt werden. Dies führt dazu, daß eine spezifische Textdatei erzeugt wird, wie in Fig. 28B gezeigt ist.
Der externe Block 194 kann ausgewählt werden, was dazu führt, daß eine externe Blockvorlage angezeigt wird, in die spezifische Befehle eingegeben werden, wie in Fig. 29A gezeigt, was dazu führt, daß eine Textdatei des in Fig. 29B gezeigten Typs erzeugt wird.
Der Infoblock 196 kann ausgewählt werden, was dazu führt, daß eine Vorlage für einen Infoblock angezeigt wird, in die Parameter wie in Fig. 30A gezeigt eingegeben werden, was dazu führt, daß die Textdatei wie in Fig. 30B gezeigt erzeugt wird.
Der Auflegeblock 197 kann ausgewählt werden, was dazu führt, daß eine Vorlage für einen Auflegeblock angezeigt wird. Parameter werden in den Auflageblockvorlage wie in Fig. 31A gezeigt eingegeben, was dazu führt, daß eine Textdatei wie in Fig. 31B gezeigt, erzeugt wird.
Herkömmlicherweise wurden spezifische Sprachanwendungen ausgedrückt durch ein geschriebenes Skript definiert, aus dem operative Sprachen manuell von einem Programmierer geschrieben werden. Somit würde ein Programmierer in Reaktion auf ein Skript Code in einer direkt auf einer Sprachanwendungsplattform ausführbaren Form erzeugen, oder es würde alternativ Code in einer Zwischensprache wie z. B. C oder C++ erzeugt, was ermöglicht, daß der Code auf unterschiedliche Typen von Anwendungsplattformen heruntergeladen wird. Seitendateien, die vom vorliegenden System erzeugt worden sind, liegen in einer Form vor, die für einen menschlichen Operator sinnvoll sind und an bekannte Skriptsprachen erinnern. Ein Hauptaspekt der ersten Stufe des vorliegenden Systems kann daher als die Umsetzung der innerhalb einer graphischen Benutzerschnittstelle definierten Befehle in Skriptdateien betrachtet werden, die hier als Seitendateien und Formulardateien bezeichnet werden und für Menschen und Maschinen lesbar sind.
Sobald der Dienst vollständig als Flußdiagramm definiert worden ist und Parameter in alle Blockvorlagen eingegeben worden sind, wie oben beschrieben worden ist, ist der nächste Schritt in der Diensterzeugung die Übersetzung der mehreren Textdateien, die jeweils für einen bestimmten Block während der Parametereingabe erzeugt worden sind, in Seitendateien und Formulardateien. Im vorliegenden Beispiel werden nur eine Seitendatei und eine Formulardatei erzeugt, um den gesamten Dienst zu definieren. Es ist jedoch klar, daß in komplexeren Flußdiagrammen, in denen Seitenblöcke definiert werden, um ein zusätzliches Flußdiagramm auf einer niedrigeren Ebene zu definieren, eine einzelne Seitendatei und eine einzelne Formulardatei für ein Flußdiagramm auf jeder Ebene erzeugt werden. Dies kann als eine Seitendatei für jede "Seite" des Entwurfes angenommen werden, der verwendet wird, wobei die Seitendateien und die Formulardatei immer paarweise erzeugt werden. Im Fall mehrerer Seiten- und Formulardateien, die erzeugt werden, ist eine der Seitendateien eine Hauptseitendatei, wobei dies angezeigt wird, indem der Name des Dienstes als Teil ihres Dateinamens enthalten ist - z. B. THEATER.PGE.
Die Seitendateien der Erweiterung PGE enthält Kopien der Blockfunktionsskripte aller TXT-Dateien. Die Blockfunktionsskripte sind diejenigen Abschnitte des Skripts, die zwischen den Begrenzern query_block: und end block (z. B.) in einer Textdatei enthalten sind. Die Seitendatei bietet somit eine funktionale Beschreibung des gesamten Dienstes in der Skriptsprache, die von einem menschlichen Dienstentwickler gelesen werden kann und ferner für die direkte Übersetzung in C++-Code geeignet ist.
Die Formulardatei mit der Erweiterung FRM enthält Kopien der Blockformularskripte aller TXT-Dateien. Die Blockformularskripte sind die Abschnitte des Skripts, die zwischen den Begrenzern query_form: und end form (z. B.) enthalten sind. Die Formulardatei liefert Textdaten, die einem Anrufer als synthetisierte Sprache vorgespielt werden können, als Teil einer Operation eines entsprechenden Teils der Seitendatei. Es ist zu beachten, daß nicht alle Blöcke Formulardaten erzeugen.
Die Seitendatei und die Formulardatei definieren gemeinsam die Operationen und die Daten, die zum Erstellen einer vollständigen Seite eines Dienstes erforderlich sind. Im vorliegenden Beispiel definieren die Seitendatei und die Formulardatei gemeinsam den gesamten Dienst, da nur eine Flußdiagrammseite verwendet worden ist.
Die Prozedur zum Erzeugen der Seiten- und Formulardatei ist in Fig. 33 genauer gezeigt. Beim Schritt 303 wird geprüft, ob eine weitere Flußdiagrammseite definiert werden muß. Wenn die Antwort nein ist, müssen keine weiteren PGE- oder FRM-Dateien erzeugt werden, wobei der Steuerungsablauf zum Schritt 57 der Fig. 5B (Dienstsimulation) verzweigt. Wenn eine neue Seite definiert werden muß, verzweigt die Steuerung zum Schritt 304, wo die Verbindungen zwischen den Blöcken analysiert werden, um eine logische Blockreihenfolge zu erzeugen, die lose die hierarchische Struktur eines C++- Programms darstellt, das möglicherweise aus dem in der Seitendatei enthaltenen Skript erzeugt wird.
Im Schritt 305 wird geprüft, ob ein weiterer Erstellungsblock in der Liste übrig ist, der in die Seiten- und Formulardateien kopiert werden muß. Wenn die Antwort nein ist, kehrt die Steuerung zum Schritt 303 zurück. Wenn die Antwort ja ist, verzweigt die Steuerung zum Schritt 306. Im Schritt 306 wird die Textdatei, die den spezifizierten Block enthält, geöffnet, so daß ihre Inhalte gelesen werden können. Im Schritt 306 wird der Text zwischen und einschließlich den Begrenzern xxxx_block: und end block in die aktuelle Seitendatei kopiert. Im Schritt 307 wird der Text zwischen und einschließlich den Begrenzern xxxx_form: und end form in die aktuelle Formulardatei kopiert. Somit werden eine Seitendatei und eine Formulardatei aus den Textdateien erstellt, die während der Blockparametereingabe erzeugt worden sind. Eine auf diese Weise aus dem aktuellen Theaterticketbeispiel erstellte Seitendatei ist in Fig. 34 gezeigt, wobei ihre entsprechende Formulardatei in Fig. 35 gezeigt ist.

ERWEIERTE BLOCKFUNKTIONEN UNTER VERWENDUNG DES STUMMELCODES

Stummelcode kann in dem Systementwurf im Flußdiagramm eingeführt werden, unter Verwendung eines Stummelblocks oder eines Vorblocks sowie von Nachblock-Stummelanhängen. Stummelcode ist Code, der in C oder C++ geschrieben ist und verwendet wird, um den Bereich der Funktionalität zu erweitern, der von den vorprogrammierten Funktionsblöcken geschaffen wird, so daß ein Dienstentwickler nicht durch den Bereich der vorprogrammierten Funktionsblöcke eingeschränkt wird, die als Teil des Diensterzeugungswerkzeuges zur Verfügung gestellt werden. Wenn der Dienst automatisch von den Skriptdateien in C- oder C++-Befehle übersetzt wird, wird der Stummelcode in das resultierende C- oder C++-Programm an einem geeigneten Punkt eingesetzt.
Somit bietet das Diensterzeugungswerkzeug die Flexibilität der manuellen Programmierung, während die schwierige Arbeit des Übersetzens des Skripts in ein C- oder C++-Programm automatisch durchgeführt wird.
Der in Fig. 25 gezeigte externe Block 194 kann durch einen Stummelblock ersetzt werden, der Zeilen vom C- oder C++-Code enthält.
Es gibt mehrere mögliche Gründe hierfür. Es kann möglich sein, das externe Programm, das vom externen Block aufgehoben wird, vollständig durch Unterroutinen zu ersetzen, die in C oder C++ geschrieben sind. Somit wird der Dienst größtenteils als selbstkonsistent definiert, völlig ohne Bezug auf andere Software. Dies kann Vorteile bringen hinsichtlich der Geschwindigkeit, der Verbesserung der Fehlerbeseitigungsmöglichkeiten und der größeren Flexibilität der Operationen, die implementiert werden können.
Fig. 35 zeigt ein Beispiel desselben in Fig. 25 gezeigten Dienstes, wobei jedoch der externe Block durch einen Stummelblock 351 ersetzt ist. Somit führt der Stummelblock eine identische Funktion aus unter Verwendung lokaler C/C++-Programme, wie diejenige, die vorher durch den externen Block zur Verfügung gestellt wurde, welcher Befehle in einem vollständig separaten Programm ausführt.
Fig. 36A zeigt die Stummelblockvorlage und ein Beispiel eines bestimmten C/C++-Codes, der die Operation der Gewinnung der Theatersitzverfügbarkeit aus einer Datenbank durchführt. Der Stummelblock ermöglicht dem Programmierer, Kopf und Bibliotheksdateien zu definieren für das Einschließen nm gesamten C- oder C++-Programm für den Dienst. So spezialisiert er Bibliotheken der Funktionen, die vorher durch Softwareentwickler erzeugt worden sind, können eingeschlossen werden, um die erforderlichen Unterroutinen für spezialisierte Operationen zur Verfügung zu stellen. Im Fall dieses Beispiels wird ein Datenbankkopf ausgewählt, der den Zugriff auf eine Bibliothek von Funktionen zum Erzeugen, Zugreifen und Manipulieren von Datenbanken definiert. Im gezeigten Stummelblockbeispiel definiert die Zeile #include < database.h> den Zugriff auf eine Bibliothek von Routinen, die bezeichnet ist mit database.h und database.lib.
Der C/C++-Code enthält die Variablendeklaration:
theatre*Index;
die den Zeiger *Index für die Verwendung als einen Zeiger auf Variablen in einer Datenbank deklariert, die für die Speicherung von Theaterdatensätzen strukturiert ist. Die Funktion:
LookupRecord(*THEATRES,"MADISON",CurrentDate,*Index);
schlägt einen Datensatz in einer Datenbank nach, der durch die konstante Kettenvariable THEATRES definiert ist, sucht einen bestimmten Datensatz für das Theater mit "MADISON" in seinem Namenfeld und für Informationen, die in diesem Datensatz gespeichert sind, gegen ein Feld, das denselben Wert wie die Systemvariable CurrentDate enthält. Die in der Teilmenge der Felder enthaltenen Informationen, die dem Datum zugeordnet sind, werden zurückgegeben durch Aktualisieren des Werts von *Index, welcher anschließend auf die Informationen zeigt. Die Operation:
seats Index.availability;
weist den Wert im Verfügbarkeitselement der Indexstruktur der Sitzvariablen zu, auf die anschließend von anderen Blöcken im Dienst zugegriffen werden kann.
Das vom Stummelblockbeispiel erzeugte Skript ist in Fig. 36B gezeigt. Dies kann verglichen werden mit der Skriptdefinition eines in Fig. 22B genauer gezeigten Stummelblocks.
Ein zweites alternatives Verfahren zum Implementieren der Datenbankoperation besteht darin, C/C++-Code im Vorstummelblock für den info2-Block 196 einzuschließen, wie in Fig. 37 gezeigt ist. In Fig. 37 wird der Vorteil des Vorstummelblocks deutlich, da die Funktion des Dienstes im Flußdiagramm deutlich wird, wobei der info2-Block 196 die aktuelle Operation des Holens von Informationen sowie des Abspielens für den Anrufer bietet.
In Fig. 38A ist der Infoblock erneut gezeigt. C- oder C++-Code wird in einen Vorstummel eingegeben durch Aktivieren des Vorstummelknopfes 361. Dies hat die Wirkung des Aktivierens eines Sekundärfensters, welches ein geeignetes Formular für die Eingabe von C-Code als Text bietet in ähnlicher Weise wie es von der Stummelblockvorlage geliefert wird. C/C++-Code ähnlich demjenigen, der im Stummelblock in Fig. 36A gezeigt ist, und der dieselbe Funktion bietet, ist statt dessen in der Skriptdatei für den modifizierten info2- Block in Fig. 38B gezeigt.
Der Vorstummel-C/C++-Code wird, wie sein Name andeutet, vor den Blockoperationen ausgeführt. Einfache arithmetische Operationen können für die Operation mit Systemvariablen vor den Blockoperationen definiert sein mittels des Vorarithmetik-Knopfes 363, wie in Fig. 38A gezeigt ist. Ähnlich schaffen die Knöpfe Nacharithmetik 362 und PostNachstummel 364 auf einer Blockvorlage eine Einrichtung zum Definieren der Nachblock-Arithmetikfunktionen und des Nachblock-C/C++-Codes. Ein beliebiger Block kann somit geschaffen werden mit bis zu vier Sätzen zusätzlicher Funktionscodesegmente, die verwendet werden können, um die Operation dieses Blocks zu verbessern oder zu modifizieren. Auf diese Weise wird einer vordefinierten Bibliothek von Funktionsblöcken eine gesteigerte Flexibilität verliehen.
Selbstverständlich fällt die Programmierung in C oder C++ innerhalb eines solchen Zusammenhangs nicht in den Bereich des unerfahrenen Programmierers. Es ist jedoch zu beachten, daß erheblicher Bildungsaufwand in Personal investiert werden kann, dessen Fachwissen Wissen über C/ C++ -programmierung und Diensterzeugung umfaßt. Somit kann ein System, das diese beiden Verfahren der Systementwicklungen in einer hocheffizienten graphischen Benutzerschnittstelle kombiniert, einen erheblichen Vorteil gegenüber Systemen aufweisen, die nur für Anfänger entwickelt sind und denen die beträchtliche Flexibilität fehlt, die eine C/C++-Erweiterung schaffen kann.

ERZEUGUNG HERUNTERLADBARER BEFEHLE

Die Erzeugung herunterladbarer C- oder C++-Befehle wird vom System der bevorzugten Ausführungsform automatisch durchgeführt. Obwohl die Befehle, die im folgenden als das Programm bezeichnet werden, automatisch erzeugt werden können, sind fortschrittliche Optionen für die Verwendung durch erfahrene Dienstentwickler/Programmierer verfügbar, so daß C/C++ -Bibliotheken, Objektcodebibliotheken und zugehörige Programmbibliotheken für die C- oder C++-Kopfdateien zugänglich sind. Diese Optionen nehmen die Form einer zusätzlichen Eingabeeinrichtung auf graphischer Basis an, die die Vorgabeskriptparameter in zwei Dateien überschreibt, die als Systemglobaldatei und Dienstglobaldatei bezeichnet werden. Diese Dateien liefern Informationen, die während des Prozesses der Übersetzung der Seitendateien (und ihrer zugehörigen Formulardateien) in ein C- oder C++-Programm erforderlich sind.
Prozeduren, die vom System- durchgeführt werden, um die herunterladbaren Befehle zu erzeugen, sind in Fig. 39 genauer gezeigt. Im Schritt 701 werden Variablen aus den Seitendateien extrahiert, wobei eine Darstellung der Dienststruktur aufgebaut wird. Die Seitendateien enthalten eine Systemglobaldatei und eine Dienstglobaldatei. Die Systemglobaldatei identifiziert Parameter, die für den gesamten Dienst gleich sind, während die Dienstglobaldatei die Struktur des Dienstes ausgedrückt durch die Anordnung der Seiten identifiziert. Die Dienstbeschreibung wird anschließend vollständig definiert durch das Hinzufügen entsprechender Dateien für jede der Seiten, wodurch die Blöcke innerhalb der Seite und die Art, in der diese verbunden sind, definiert werden.
Im Schritt 702 werden die Seitendateien verarbeitet, um herunterladbare Befehle zu erzeugen, vorzugsweise in einer Form kompatibel zur C++- Programmiersprache. Die Befehle enthalten eine Unterroutine für jede Seite in Kombination mit einem Steuerprogramm, das eine endliche Zahl möglicher Zustände definiert, d. h. eine endliche Zustandsmaschine. Im Schritt 703 wird die vom Menschen lesbare Darstellung der herunterladbaren Befehle erzeugt, was einem Operator ermöglicht, dem Fortschritt des Systems zu folgen, wenn es sich in einer Online-Operation befindet.
Um die Anforderungen von C++ zu erfüllen, ist es erforderlich, Variablen am Anfang eines Abschnitts der C++-Befehle (einer Funktion) zu deklarieren, in dem sie verwendet werden. Somit ist der erste Schritt beim Erzeugen des C++- Programms, die Existenz von Variablen in den Skriptdateien zu ermitteln und ihren Typ (ganze Zahl oder Kette oder dergleichen) aus dem Zusammenhang zu ermitteln, in dem sie verwendet werden.
Die Prozedur zum Extrahieren von Variablen, im Schritt 701 in Fig. 39 gezeigt, ist in Fig. 40 genauer gezeigt. Im Schritt 712 werden Variablen identifiziert durch Durchführen einer Suche für die relevanten Skript-Schlüsselwörter wie z. B.: "arg", "pre-do" und "do", wodurch es möglich wird, den Typ der Variablen aus ihrem Zusammenhang zu ermitteln. Wenn Variablen identifiziert werden, die nicht klassifiziert werden können, wird hierfür ein Bericht erstellt.
Im Schritt 713 werden weitere Maßnahmen ergriffen, um den Typ der Variablen zu identifizieren, indem die Argumente betrachtet werden, die der Seite zugeführt werden. Um die Identifikation eines Typs für jede Variable zu erleichtern, werden "Gleichartig"-Listen erzeugt, so daß alle Variablen in einer Liste klassifiziert werden können, wenn der Typ einer der Variablen in der Liste ermittelt worden ist.
Wenn Variable nicht klassifiziert werden können, werden sie im Schritt 714 angezeigt, woraufhin ein Operator die erforderlichen Informationen liefern kann oder eine Erläuterung von einem Diensterzeuger suchen kann.
Die im Schritt 702 angegebenen Prozeduren zum Verarbeiten der Seitendateien für jede Seite sind in Fig. 41 genauer gezeigt. Eine separate Seitendatei existiert für jede Seite des Dienstes, wobei dieser Lösungsansatz im C++-Code enthalten ist. Ein Haupt-C++-Programm wird erzeugt, welches dazu dient, jede Seitenunterroutine aufzurufen, wodurch die Seitendateien miteinander verknüpft werden und ihre Reihenfolge definiert wird. Somit wird im Schritt 721 die nächste Seitendatei geöffnet und eine entsprechende C++-Ausgabedatei erzeugt.
Im Schritt 722 werden Kommentare von der Skriptdatei als C++-Kommentare kopiert, bis der Seitenname identifiziert wird. Im Schritt 723 werden die von der Seite verwendeten globalen Variablen in die C++-Datei kopiert. Im Schritt 724 wird die Position der Seite in der Diensthierarchie ermittelt, wobei die an die Seitendatei übergebenen Argumente kopiert werden und lokale Variablen an die C++-Datei übergeben werden.
Im Schritt 725 wird die Seite in C++ übersetzt, bis das Ende der Seitenlegende identifiziert wird. Die Übersetzung umfaßt anfänglich das Identifizieren jedes Blocks innerhalb der Seite und das Aufrufen einer entsprechenden Übersetzungsunterroutine, um jeden dieser Blöcke zu übersetzen. Sobald die Blöcke übersetzt worden sind, wird ein Seitenfunktionsprototyp in die C++-Datei im Schritt 726 geschrieben. Im Schritt 727 wird die Steuerlogik geschrieben, die das Aufrufen der Blockunterroutinen innerhalb der Seite steuert und effektiv eine endliche Zustandsmaschine für die Seite definiert.
Im Schritt 728 werden die Variablen zurückgesetzt, wobei im Schritt 729 geprüft wird, ob mehr Seiten vorhanden sind, die eine Verarbeitung erfordern. Wenn die Antwort positiv ist, kehrt die Steuerung zum Schritt 721 zurück, und es wird die nächste Seite der Textdateien verarbeitet. Schließlich sind alle Seiten der Textdateien verarbeitet worden und die Frage im Schritt 729 wird negativ beantwortet. Somit verzweigt die Steuerung zum Schritt 730, woraufhin Hauptaufrufbefehle erzeugt werden auf der Grundlage der Hierarchie der Seiten, die den vollständigen Dienst bilden.
Auf diese Weise wird der Dienst definiert durch mehrere C++-Dateien. Die C++-Dateien sind für einen menschlichen Operator lesbar, wobei eine Dokumentation erzeugt werden kann, die sich auf die detaillierte Codierung dieser Dateien bezieht. Die C++-Dateien werden anschließend zu einem Dienstanbieter heruntergeladen, der die Einrichtungen besitzt, um die C++-Dateien in ausführbaren Code für eine bestimmte Sprachanwendungsplattform zu kompilieren. Die Dokumentation kann Einzelheiten über verschiedene kleinere Änderungen liefern, die erforderlich sein können, um den C++-Code für die Kompilierung innerhalb einer bestimmten Betriebssystem- oder Plattformumgebung geeignet zu machen. Ferner ist C++ eine populäre Programmiersprache, wobei Software, die in dieser Form geliefert wird, nützlich modifiziert werden kann, um zusätzliche oder alternative Funktionalität zu schaffen seitens des Dienstanbieters, der die notwendigen Programmiererfahrungen besitzt.

Claims

1. Vorrichtung zum Erzeugen einer Befehlssequenz, die durch eine Anwendungsplattform ausgeführt werden soll, mit

einer Eingabeeinrichtung (38, 39) zum Empfangen einer Anwendereingabe;

einer graphischen Anzeigeeinrichtung (27); und

einer Verarbeitungseinrichtung (31), die

a) als Antwort auf eine Anwendereingabe erster Daten, die gewünschte Funktionen mehrerer diskreter Funktionen spezifizieren, die durch die Anwendungsplattform ausgeführt werden können, mittels der graphischen Anzeigeeinrichtung eine graphische Darstellung der funktionalen Blöcke, die den spezifizierten Funktionen entsprechen, anzeigt;

b) als Antwort auf eine Anwendereingabe zweiter Daten, die gewünschte Verknüpfungen zwischen den spezifizierten Funktionen spezifizieren, wobei die Verknüpfungen gemeinsam eine logische Sequenz zur Ausführung der Funktionen definieren, mittels der graphischen Anzeigeeinrichtung eine graphische Darstellung von Verbindungen zwischen den den spezifizierten Verknüpfungen entsprechenden Blöcken anzeigt;

c) so betreibbar ist, daß sie die Gültigkeit der logischen Sequenz, die durch die Verknüpfungen definiert ist, prüft, um Fehler in der logischen Sequenz zu erkennen; und dadurch gekennzeichnet, daß

die Verarbeitungseinrichtung ferner nur dann, wenn keine solchen Fehler erkannt werden, so betreibbar ist, daß sie eine Anwendereingabe dritter Daten empfängt, die für eine oder mehrere der spezifizierten Funktionen Parameter spezifizieren, die die Funktion, die ausgeführt werden soll, partikularisieren, und so, daß als Antwort auf die hiermit spezifizierten Parameter eine Befehlssequenz für die Ausführung der spezifizierten Funktionen in der definierten Sequenz erzeugt wird.

2. Vorrichtung nach Anspruch 1, in der die Verarbeitungseinrichtung so beschaffen ist, daß sie für jeden der Blöcke eine Textdatei erzeugt;

aus den Textdateien eine Skriptdatei erzeugt; und

aus der Skriptdatei die Befehlssequenz erzeugt.

3. Vorrichtung nach Anspruch 2, in der die Verarbeitungseinrichtung ferner so beschaffen ist, daß sie die Operation der Anwendungsplattform simuliert, wenn sie die erzeugten Befehle ausführt, indem sie die Skriptdatei interpretiert.

4. Vorrichtung nach einem der vorhergehenden Ansprüche, in der die Fehler in der logischen Sequenz fehlende Verknüpfungen zwischen funktionalen Blöcken umfassen.

5. Vorrichtung nach einem der vorhergehenden Ansprüche, in der die Fehler in der logischen Sequenz doppelte Verknüpfungen zwischen funktionalen Blöcken umfassen.

6. Vorrichtung nach einem der vorhergehenden Ansprüche, in der die Fehler in der logischen Sequenz funktionale Blöcke ohne Eingangsverknüpfung umfassen.

7. Vorrichtung nach einem der vorhergehenden Ansprüche, in der die Anwendungsplattform eine Sprachanwendungsplattform ist und die Befehle in Form einer höheren Programmiersprache dargestellt werden.

5. Verfahren zum Erzeugen einer Befehlssequenz, die durch eine Anwendungsplattform ausgeführt werden soll, mit den folgenden Schritten:

Empfangen (75) erster Daten, die gewünschte Funktionen mehrerer diskreter Funktionen spezifizieren, die durch die Anwendungsplattform ausgeführt werden können;

Anzeigen (76) einer graphischen Darstellung funktionaler Blöcke, die den spezifizierten Funktionen entsprechen;

Empfangen (78, 79) zweiter Daten, die gewünschte Verknüpfungen zwischen den spezifizierten Funktionen spezifizieren, wobei die Verknüpfungen gemeinsam eine logische Sequenz der Ausführung der Funktionen definieren;

Anzeigen (80) einer graphischen Darstellung von Verbindungen zwischen den Blöcken, die den spezifizierten Verknüpfungen entsprechen;

Prüfen (53) der Gültigkeit der durch die Verknüpfungen definierten logischen Sequenz, um Fehler in der logischen Sequenz zu erkennen; und dadurch gekennzeichnet, daß

nur dann, wenn keine solchen Fehler erkannt werden, als Antwort auf die ersten Daten und die zweiten Daten ferner Anwenderdaten empfangen (55) werden, die für eine oder mehrere der spezifizierten Funktionen Parameter spezifizieren, die die Funktion, die ausgeführt werden soll, partikularisieren, und eine Befehlssequenz für die Ausführung der spezifizierten Funktionen in der definierten Sequenz in Übereinstimmung mit den hiermit spezifizierten Parametern erzeugt (61) wird.

9. Verfahren nach Anspruch 8, bei dem die Befehlssequenz erzeugt wird durch die folgenden Schritte:

Erzeugen (56) einer Textdatei für jeden der Blöcke;

Erzeugen (303-308) einer Skriptdatei aus den Textdateien; und

Erzeugen (702) der Befehlssequenz aus der Skriptdatei.

10. Verfahren nach Anspruch 9, bei dem die Operation der Anwendungsplattform bei der Ausführung der erzeugten Befehle durch Interpretieren der Skriptdatei simuliert wird.

11. Verfahren nach einem der Ansprüche 8 bis 10, bei dem die Fehler in der logischen Sequenz fehlende Verknüpfungen zwischen den funktionalen Blöcken umfassen.

12. Verfahren nach einem der Ansprüche 8 bis 11, bei dem die Fehler in der logischen Sequenz doppelte Verknüpfungen zwischen funktionalen Blöcken umfassen.

13. Verfahren nach einem der Ansprüche 8 bis 12, bei dem die Fehler in der logischen Sequenz funktionale Blöcke ohne Eingangsverknüpfung umfassen.

14. Verfahren nach einem der Ansprüche 8 bis 13, bei dem die Anwendungsplattform eine Sprachanwendungsplattform ist und die Befehle in Form einer höheren Programmiersprache dargestellt werden.