DE10006532A1 - Verfahren zum automatischen Generieren von kundenspezifischen Funktionsmodulen - Google Patents

Abstract

Verfahren zum nutzerseitig veranlaßten, automatischen Generieren von kundenspezifischen Funktionsmodulen für den Einsatz in Diensten intelligenter Netze, insbesondere intelligenter Telekommunikationsnetze, mit den Schritten: DOLLAR A - Erstellen eines aufgabenspezifischen Ablauf- und Entscheidungsgraphen unter Anwendung einer graphischen Entwurfs- und Entwicklungsoberfläche, wobei den graphischen Elementen jeweils dezidiert diensteunabhängige funktionale, mehrfach einsetzbare Bausteine zugeordnet sind, und wobei weiterhin DOLLAR A - die funktionalen Bausteine über eine formale Komponentendefinitionssprache beschrieben sind; DOLLAR A - den funktionellen Bausteinen über diese formale Komponentendefinitionssprache Datenbausteine zugeordnet werden, DOLLAR A - selbständiges Validieren der gewählten Verknüpfungen und Prüfen der logischen Richtigkeit der Knoten im Ablauf- und Entscheidungsbaum; DOLLAR A - Ableiten von Zielspracheschnittstellen auf der Basis der formalen Komponentendefinitionssprache, so daß vorhandene und/oder bereitzustellende Komponenten oder Programme zum Erhalt des oder der kundenspezifischen Funktionsmodule und eines Gesamtdatenmodells einbindbar sind, und wobei DOLLAR A - die Komponentendefinitionssprache die funktionalen Bausteine mindestens mittels Eingabeparametern, Ausgabeparametern, Funktionsangaben und Daten zur graphischen Darstellung der Bausteine beschreibt.

Description

Die Erfindung betrifft ein Verfahren zum nutzerseitig veran­ laßten, automatischen Generieren von kundenspezifischen Funk­ tionsmodulen für den Einsatz in Diensten intelligenter Netze, insbesondere intelligenter Telekommunikationsnetze.

Die Telekommunikation ist derzeit einer der dynamischsten Wirtschaftszweige. Die hier zu verzeichnenden Wachstumsraten beruhen bereits jetzt zu einem großen Teil darauf, daß im Rahmen von Telekommunikationsnetzen ein ständig wachsender Umfang an Dienstleistungen angeboten wird, die nicht system­ immanent sind. Die zukünftige Entwicklung dieses Gebietes hängt entscheidend davon ab, daß neue Dienste auf flexible und kostengünstige Weise implementiert werden können.

Die Entwicklung von Diensten für intelligente Netze (IN = Intelligent Networks) betrifft verschiedene Komponenten und schließt verschiedene Teilprozesse ein, von denen vor allem die folgenden erwähnenswert sind:

SIB Creation

Dieser Teilprozeß betrifft die Entwicklung von Software-Bau­ steinen bzw. -modulen, aus denen Dienste aufgebaut werden, in einer etablierten Programmiersprache. Diese Bausteine werden als SIBs (Service Independent Building Blocks) bezeichnet. Sie werden etwa in den Programmiersprachen C oder C++ entwi­ ckelt.

Service Creation

Dieser Teilprozeß betrifft den Aufbau von Diensten als Stan­ darddienste oder in kundenspezifischer Weise durch Verknüpfen von SIBs. SIBs können dabei mehrfach benutzt werden und wer­ den in einer den Erfordernissen des jeweiligen Dienstes Rech­ nung tragenden Weise parametrisiert. Die Entwicklung wird nicht notwendigerweise mit der gleichen Programmiersprache wie die SIB Creation ausgeführt. Typischerweise wird eine grafische Oberfläche eingesetzt, in der die SIBs als Knoten auftreten und die Kanten des Kontrollfluß beschreiben.

DB Creation

Die SIBs und die Dienste benötigen kunden- oder anruferspezi­ fische Daten, die im Rahmen des Entwurfes von Datenbasen (DB = Data Bases) bzw. Datenbanken zu beschreiben und über gra­ fische Oberflächen zu erfassen sind.

Für die rationelle Dienste-Entwicklung kommt es wesentlich darauf an, daß die Schnittstellen dieser Komponenten bzw. Teilprozesse hinreichend genau und konsistent beschrieben, implementiert und über ihre Lebensdauer konsistent gehalten werden.

Bei bisherigen Entwicklungsprozessen werden die erwähnten Schnittstellen in der Syntax und Semantik ihrer Implementie­ rungssprache mehrfach formal definiert. Die erforderliche Konsistenz kann nur durch Überblicks-Prüfung der Schnittstel­ lenspezifikationen und vor allem den anschließenden Test der entsprechenden Komponenten-Implementierung gewährleistet wer­ den, wobei das Auftreten von Inkonsistenzen während der Le­ bensdauer des Dienstes dennoch nicht ausgeschlossen werden kann.

Der Erfindung liegt daher die Aufgabe zugrunde, ein rationel­ les und zuverlässiges Verfahren der oben genannten Art anzu­ geben, welches insbesondere die Implementierung von in sich dauerhaft konsistenten Diensten intelligenter Netze ermög­ licht.

Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 1 gelöst.

In einer zweckmäßigen Ausführung des Verfahrens umfaßt die Komponentendefinitionssprache Verweis-Parameter, welche eine individuelle Festlegung der Beziehungen von Werten der Einga­ beparameter zur Selektion der Ausgänge ermöglichen.

In einer weiteren zweckmäßigen Fortbildung des Erfindungsge­ dankens erfolgt die individuelle Ausprägung des Gesamtdaten­ modells über Datentabellen von Datenbanken. Hierbei stellt die Komponentendefinitionssprache eine automatische Ableitung von Eingabemasken bei Aufruf bereit. Damit sind nutzerseitig kundenspezifische Änderungen am Datenmodell oder am Ablauf des Entscheidungsgraphen ohne Eingriff in das eigentliche Funktionsmodul eingebbar.

Eine besonders vorteilhafte Ausführung des Verfahrens ergibt sich, wenn in einer bevorzugten Implementierung die Funk­ tionsmodule einschließlich der funktionalen Bausteine und der Datenbausteine beim Diensteanbieter installiert sind. In die­ sem Fall wird dem Netzbetreiber der sich aus dem jeweils ge­ prüften Funktionsmodul ergebende Ablauf des Datenverkehrs und der Herstellung von Verknüpfungen online mitgeteilt.

Vorteile und Zweckmäßigkeiten der Erfindung ergeben sich im übrigen aus den Unteransprüchen sowie der nachfolgenden Be­ schreibung einer bevorzugten Ausführungsform des Verfahrens anhand der Figuren. Von diesen zeigen:

Fig. 1 ein allgemeines Beispiel eines SIB-Templates,

Fig. 2 ein konkretes Beispiel eines SIB-Templates,

Fig. 3 ein konkretes Beispiel für ein aus dem SIB-Template COPY gemäß Fig. 2 generiertes Code-Fragment in der Programmiersprache C++,

Fig. 4 ein konkretes Beispiel für ein Testrahmenfragment entsprechend dem SIB-Template COPY gemäß Fig. 2,

Fig. 5 ein allgemeines Beispiel für die Instanziierung eines SIBs X,

Fig. 6 ein konkretes Beispiel für eine automatisch generierte Dialogmaske bei SIB-Instanziierung nach dem SIB-Template COPY,

Fig. 7 ein allgemeines Beispiel für einen Dienstgraphen aus Bausteininstanzen und

Fig. 8 ein konkretes Beispiel für einen Dienstgraphen als Verknüpfung von SIBs.

Die Figuren dienen insgesamt zur Skizzierung eines Programm­ ablaufes im Rahmen der Ausführung der Erfindung, wobei von formalen Komponentenbausteinen (SIB-Templates) ausgegangen wird, die in der Beschreibungssprache STL spezifiziert sind. Ein allgemeines sowie ein spezielles Beispiel hierfür sind in Fig. 1 bzw. Fig. 2 dargestellt.

Aus der formalen Komponentendefinition (SIB-Template) wird automatisch eine Implementierung der jeweiligen Komponente in einer Programmiersprache generiert. Fig. 3 zeigt ein konkre­ tes Beispiel für ein solchermaßen generiertes Code-Fragment.

Zudem kann - wofür in Fig. 4 ein konkretes Beispiel angegeben ist - zu einer formalen Komponentendefinition (SIB-Template) automatisch ein Testrahmen in einer Programmiersprache gene­ riert werden.

Im weiteren können zu einer formalen Komponentendefinition (SIB-Template) beliebig viele individuelle Bausteininstanzen (SIB-Instanzen) ausgeprägt werden. In Fig. 5 ist die Instan­ ziierung eines SIBs X allgemein skizziert. Das SIB X umfaßt mögliche formale Ein- und Ausgabeparameter P_j, mögliche Aus­ gänge A_k und mögliche Datenkomponenten D_j und erlaubt indivi­ duelle Ausprägungen von X_i. Die abgeleitete SIB-Instanz X_i umfaßt konkret zugewiesene Parameterwerte P_j = V_j, gewählte Ausgänge A_n und gewählte Datenkomponenten D_m.

Aus der formalen Komponentendefinition wird auch eine graphi­ sche Oberfläche zur Ausprägung individueller Bausteininstan­ zen erzeugt.

Eine Dialogführung bei der SIB-Instanzilerung nach SIB-Tem­ plate X umfaßt - als allgemeines Beispiel - insbesondere die folgenden Abfrageschritte:

• - Welchen Wert soll Parameter X.P₁ annehmen?
• - Welchen Wert soll Parameter X.P₂ annehmen?
• - Auf welche Nachfolgerinstanz soll Ausgang A₁ zeigen?
• - Auf welche Nachfolgerinstanz soll Ausgang A₂ zeigen?
• - Welche Eigenschaften soll die Datenkomponente D₁ erhalten?
• - Welchen Anfangswert soll die Datenkomponente D₁ erhalten?
• - Soll die Datenkomponente D₁ während der Dienstausführung veränderbar sein?

In Fig. 6 ist ein entsprechendes konkretes Beispiel für eine automatisch generierte Dialogmaske dargestellt.

Weiterhin werden die gewonnenen Bausteininstanzen zu einem Dienstgraphen verbunden, in dem die möglichen Ausgänge einer Instanz durch Vorgabe von Nachfolgerinstanzen festgelegt wer­ den. In Fig. 7 ist ein solcher Dienstgraph allgemein skiz­ ziert.

Aus diesem Dienstgraphen wird sodann automatisch das relevan­ te Datenmodell erzeugt, aus dem automatisch beispielsweise Datenbanktabellen und geeignete Oberflächen zur Eingabe von Datensätzen generiert werden können. Eine solche Eingabe von Datensätzen stellt beispielsweise das "Einrichten" von Dienstkunden und die Eingabe von deren dienstrelevanten Daten dar, in einem Telekommunikationsnetz beispielsweise Kunden mit rufnummernspezifischen Angaben oder Prepaid-Konten bzw. - Karten für die Dienstnutzung.

Unterschiedliche Datenmodelle und unterschiedliche Abläufe bzw. ein unterschiedliches "Verhalten" von Dienstprogrammen können in vorteilhafter Weise ohne Veränderung der Verbindung in relevanten Dienstgraphen allein durch Änderung der Parame­ ter in SIB-Instanzen erzeugt werden.

Der Dienst kommt beim Abarbeiten des Dienstgraphen zur Aus­ führung, wobei ein Zugriff auf die eingegebenen Datensätze und deren Modifikation sowie die Erstellung von statistischen Daten über die Veränderung von Datensätzen möglich sind. Die Abarbeitung wird bei einem Telekommunikationsdienst zum Bei­ spiel durch einen Anruf oder im Internet durch die Auswahl einer Internetadresse über einen Browser ausgelöst. Die er­ wähnte Modifikation der Datennetze stellt sich in einer Tele­ kommunikationsapplikation zum Beispiel als Einrichten tempo­ rärer alternativer Rufnummern (Rufumleitung) oder als Abbu­ chen von einem Prepaid-Guthaben dar.

Die Ausführung der Erfindung ist nicht auf die oben erwähnten Schritte bzw. Abläufe und die in den Figuren gezeigten Bei­ spiele beschränkt, sondern ebenso auch in Abwandlungen mög­ lich, die im Rahmen fachgemäßen Handelns liegen.

Claims (4)

1. Verfahren zum nutzerseitig veranlaßten, automatischen Ge­ nerieren von kundenspezifischen Funktionsmodulen für den Ein­ satz in Diensten intelligenter Netze, insbesondere intelli­ genter Telekommunikationsnetze, gekennzeichnet durch

• - Erstellen eines aufgabenspezifischen Ablauf- und Entschei­ dungsgraphen unter Anwendung einer graphischen Entwurfs- und Entwicklungsoberfläche, wobei den graphischen Elementen je­ weils dezidiert diensteunabhängige funktionale, mehrfach ein­ setzbare Bausteine zugeordnet sind, und wobei weiterhin
• - die funktionalen Bausteine über eine formale Komponenten­ definitionssprache beschrieben sind;
• - den funktionellen Bausteinen über diese formale Komponen­ tendefinitionssprache Datenbausteine zugeordnet werden,
• - selbständiges Validieren der gewählten Verknüpfungen und Prüfen der logischen Richtigkeit der Knoten im Ablauf- und Entscheidungsbaum;
• - Ableiten von Zielspracheschnittstellen auf der Basis der formalen Komponentendefinitionssprache, so daß vorhandene und/oder bereitzustellende Komponenten oder Programme zum Erhalt des oder der kundenspezifischen Funktionsmodule und eines Gesamtdatenmodells einbindbar sind, und wobei
• - die Komponentendefinitionssprache die funktionalen Baustei­ ne mindestens mittels Eingabeparametern, Ausgabeparametern, Funktionsangaben und Daten zur graphischen Darstellung der Bausteine beschreibt.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Komponentendefinitionssprache Verweis-Parameter umfaßt, welche eine individuelle Festlegung der Beziehung von Werten der Eingabeparameter zur Selektion der Ausgänge ermöglichen.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß die individuelle Ausprägung des Gesamtdatenmodells über Da­ tentabellen von Datenbanken erfolgt, wobei die Komponentende­ finitionssprache eine automatische Ableitung von Eingabemas­ ken bei Aufruf bereitstellt, so daß ohne Eingriff in das ei­ gentliche Funktionsmodul nutzerseitig kundenspezifische Ände­ rungen am Datenmodell oder dem Ablauf des Entscheidungsgra­ phen eingebbar sind.

4. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, daß die Funktionsmodule einschließlich der funktionalen Bausteine und der Datenbausteine beim Diensteanbieter installiert sind, wobei dem Betreiber des Netzes der sich aus dem geprüften Funktionsmodul ergebende Ablauf des Datenverkehrs und der Herstellung von Verknüpfungen online mitgeteilt wird.