DE69618468T2

DE69618468T2 - Verfahren zum erstellen von computergesteuerten diensten

Info

Publication number: DE69618468T2
Application number: DE69618468T
Authority: DE
Inventors: Pekka Ahmavuo; Martti Ala-Rantala; Pia Naervaenen
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 1995-10-11
Filing date: 1996-10-09
Publication date: 2002-08-22
Anticipated expiration: 2016-10-10
Also published as: US20010034878A1; EP0855059A1; JPH11513515A; CA2234463C; DE69618468D1; FI103155B; FI954838A0; ES2171721T3; EP0855059B1; FI954838A; CN1199474A; BR9610796A; AU7218196A; US6351842B2; WO1997014097A1; CA2234463A1; FI103155B1; AU710715B2

Description

Die Erfindung betrifft allgemein Systeme ähnlich Netzwerkverwaltungssystemen, die durch Software bereitgestellt sind, mit Diensten, mittels welchen der Endbenutzer das System benutzt, beispielsweise die Vorrichtungen in dem Netzwerk steuert. Genauer bezieht sich die Erfindung auf ein Verfahren gemäß dem Oberbegriff des beigefügten Patentanspruchs 1 zum Erzeugen anwendungsspezifischer computergesteuerter Dienste für einen Benutzer eines solchen Systems. Die Erfindung bezieht sich darüber hinaus auf ein System gemäß dem beigefügten Patentanspruch 8 zum Erzeugen anwendungsspezifischer computergesteuerter Dienste.
Es gibt mehrere Systeme auf dem Markt, die auf die Erzeugung von Code abzielen. Solche Generatoren sind vorwiegend zur Verwendung zu Beginn einer Programmierung beabsichtigt und können nicht zur schnellen und fehlerfreien Durchführung wesentlicher Änderungen in fertiggestellten Anwendungen verwendet werden. Mit anderen Worten ausgedrückt stellen bekannte Generatoren keine ausreichende Unterstützung für wiederholte Änderungen und Ergänzungen bereit.
Mehrere Anwendungen sind darüber hinaus derart, daß es möglich sein sollte, Änderungen in denselben so schnell und so korrekt wie möglich durchzuführen. Ein Beispiel einer solchen Anwendung ist ein Netzwerkverwaltungssystem, in welchem das zu verwaltende Netzwerk mehrere Vorrichtungen unterschiedlicher Arten umfaßt und sich das Netzwerk fortlaufend ändert, wenn der Betreiber Einrichtungen von mehreren unterschiedlichen Herstellern beschafft und eine Aktualisierung der bestehenden Einrichtungen und deren Software durchführt. Insbesondere mit dem neuen freien Wettbewerb auf dem Gebiet der Telekommunikation ist ein Bedarf dahingehend entstanden, die Benutzer kontinuierlich mit neuen Diensten zu versorgen, welche die Bedeutung flexibler Änderungsmöglichkeiten weiter erhöhen.
Die bekannten Systeme sind für Anwendungen der vorstehend beschriebenen Art nicht sehr gut geeignet. Dies ist beispielsweise auf die Tatsache zurückzuführen, daß die Systeme den Entwickler mit einer großen Zahl detaillierter und daher also sekundärer Informationen versorgen, aus welchen es schwierig ist, die wesentlichen Teile (auf die Änderungen gerichtet werden) herauszufinden. Der Entwickler muß auch in der Lage sein, diese Informationen zu steuern (zu verstehen). Daher muß die Person, welche die Änderungen durchführt, ein Experte auf dem Gebiet der Programmierung sein.
In einem solchen System besteht auch die Gefahr, daß der Entwickler einen solchen Teil der Software ändert, der nicht geändert werden darf.
Der Erfindung liegt die Aufgabe zugrunde, die vorstehend erwähnten Nachteile durch Bereitstellen einer neuen Art von Anordnung zum Erzeugen eines anwendungsspezifischen Dienstes zu beseitigen. Diese Aufgabe wird durch das erfindungsgemäße Verfahren gelöst, welches durch die Merkmale des kennzeichnenden Teils des beigefügten Patentanspruchs 1 gekennzeichnet ist.
Die Idee der Erfindung besteht darin, eine Umgebung zu erzeugen, in der Änderungen für den Entwickler bzw. Designer so einfach und so klar wie möglich sind. Dies ist möglich durch getrenntes Anordnen des zu erzeugenden Codes in (a) einen Teil (enthaltend die Standardfunktionalität) derart, daß der Entwickler diesen während der Änderungen ignorieren kann (so daß er unsichtbar bleiben kann) und (b) einen Teil, der für den Entwickler sichtbar ist und der es in jeder Änderungssituation erfordert, daß Änderungen durch den Entwickler erfolgen. Die Trennung beruht auf der Verwendung spezieller Vorlagen- bzw. Schablonendateien (template files), und die Änderungen werden ausgeführt durch Durchführen einer Änderung in Übereinstimmung mit der Änderung in der Beschreibungsdatei der Anwendung, durch Neuerzeugen des Anwendungsgefüges, und durch erforderlichenfalls danach Durchführen der Änderungen, die von dem Entwickler manuell auszuführen sind. In Verbindung mit der Erzeugung modifiziert der Codegenerator die Schablonendateien auf der Grundlage der Beschreibungsdatei der Anwendung.
Aufgrund der erfindungsgemäßen Anordnung können Änderungen so schnell und fehlerlos wie möglich ausgeführt werden. Das an den Benutzer des Dienstes zu liefernde Produkt kann somit schnell fehlerlos hergestellt werden. Erfindungsgemäß ist es sogar möglich, daß Änderungen von einer von der Organisation beschäftigten Person durchgeführt werden, wie beispielsweise dem Netzwerkbetreiber, unter Verwendung des Dienstes, in welchem Fall die Änderungen so flexibel wie möglich sein werden.
Die vorstehend beschriebenen Vorteile beruhen auf der Tatsache, daß das System den Abstraktionsgrad der Arbeit des Entwicklers erhöht. Der Entwickler sieht nur den wesentlichen Teil (die Teile, die der Änderung bedürfen) der Anwendung, und die nebensächlichen Dinge (der komplizierte Programmcode) sind unsichtbar. Daher ist es für den Entwickler leichter, die Teile zu lokalisieren, an denen Änderungen durchgeführt werden müssen. Gleichzeitig verringert dies auch die Möglichkeit für den Entwickler, unbeabsichtigterweise Teile zu ändern, die nicht zu bearbeiten sind.
Nachstehend werden die Erfindung und die bevorzugten Ausführungsbeispiele derselben unter Bezugnahme auf die Beispiele gemäß den begleitenden Zeichnungen näher beschrieben, in welchen:
Fig. 1 ein System gemäß der Erfindung darstellt;
Fig. 2 die Erzeugung einer fertiggestellten Anwendung mit dem System gemäß der Erfindung zeigt;
Fig. 3a das Hauptfenster in einer veranschaulichenden Anwendung zeigt;
Fig. 3b ein Unterfenster der veranschaulichenden Anwendung zeigt;
Fig. 4 ein Objektmodell der veranschaulichenden Anwendung zeigt;
Fig. 5 eine dem Code-Generator zugeführte Anwendungsbeschreibung zeigt;
Fig. 6 ein erzeugtes Anwendungsgefüge zeigt;
Fig. 7 das Hauptfenster der Anwendung in ihrer geänderten Form zeigt;
Fig. 8 die an dem Objektmodell durchzuführende Änderung zeigt; und
Fig. 9 eine weitere an der Anwendung durchzuführende Änderung zeigt.
Fig. 1 stellt das Netzwerkverwaltungssystem gemäß der Erfindung dar. Ein objektbasiertes Programm, das auf der MVC++ Anwendungsarchitektur (und der Verwendung der Programmiersprache C++) basiert, wird als ein Beispiel verwendet. Es kann allgemein festgestellt werden, daß das Verfahren die Verwendung einer einfachen Anwendungsarchitektur, beispielsweise der MVC++ Architektur, erfordert. Da diese Architektur nachstehend als Beispiel verwendet wird, werden Merkmale, die das Verständnis der nachfolgenden Beschreibung vereinfachen, in diesem Zusammenhang kurz beschrieben.
Die MVC++ Architektur ist ausgehend von der bekannten MVC (Model-View-Control)-Architektur modifiziert, und ihr entsprechend ist die Anwendung in drei Teile unterteilt: Modell (model), Ansicht (view) und Steuerung (control). Der Modellteil ist eine Sammlung von Objekten, die den Bereich der realen Welt beschreiben, auf die sich die Anwendung bezieht. Der Ansichtsteil ist die äußerste Schicht der Anwendung und für den Endbenutzer sichtbar. Dieser Teil legt fest, was der Benutzer auf dem Monitor sieht. Der Ansichtsteil ist in einen visuellen und einen funktionellen Teil unterteilt. Der visuelle Teil verwaltet die Anordnung der Anzeige, und der funktionelle Teil steuert die Funktionalität mit Bezug zu der Anzeige. Der Ansichtsteil wird durch den Controller- oder Steuerteil erzeugt, und für jedes Ansichtsobjekt gibt es ein Steuerobjekt. Der Steuerteil steuert die Zusammenarbeit des Modellteils und des Ansichtsteils und bildet die anwendungsspezifische Logik aus. Ein Steuerobjekt kann einen Bezug zu mehreren Modellobjekten haben, und ein und dasselbe Modellobjekt kann mit mehreren Steuerobjekten verbunden sein. In der Anwendung in Übereinstimmung mit der MVC++ Architektur sind die Objekte des Modellteils und des Ansichtsteils nicht direkt miteinander verbunden, sondern ein Ansichtsobjekt kann mit einem Modellobjekt nur über ein Steuerobjekt kommunizieren. Daher interpretiert der Ansichtsteil einen durch einen Benutzer von der Arbeitsstation aus gegebenen Befehl und zeigt dem Steuerteil an, welche Funktion in Rede steht. Der Steuerteil enthält das Wissen darüber, wie jeder Befehl zu verarbeiten ist, so daß der Steuerteil den Modellteil auffordert, die dem Befehl entsprechenden Maßnahmen auszuführen. Der Modellteil informiert den Steuerteil über die Ergebnisse der Maßnahmen, und der Steuerteil bittet im Gegenzug den Ansichtsteil, diese dem Benutzer anzuzeigen. Jede Anwendung in Übereinstimmung mit der MVC++ Architektur hat eine Hauptsteuerklasse, d. h. einen Haupt-"Controller", der die anderen Steuerklassen und somit die gesamte Anwendung steuert. Darüber hinaus erzeugt ein Hauptsteuerobjekt ein Hauptansichtsobjekt und steuert dieses. Das Hauptansichtsobjekt erzeugt das Hauptfenster der Anwendung. Für jedes andere Fenster (Dialog) gibt es getrennte Ansichts- und Steuerklassen.
Eine detailliertere Beschreibung der MVC++ Architektur ist zum Beispiel in Implementing Interactive Applications in C++ von A. Jaaksi (Software Practice & Experience, Band 25, Nr. 3, März 1995, Seiten 271-289) bereitgestellt.
Das Netzwerkverwaltungssystem gemäß der Erfindung kann in der Praxis zum Beispiel wie in Fig. 1 gezeigt ausgestaltet sein. In Betriebs- und Wartungszentren MS sitzende Netzwerkbetreiber verwenden Netzwerkverwaltungs-Arbeitsstationen WS, die mit einem separaten Arbeitsstationsnetzwerk WSN verbunden sind, das zum Beispiel ein Ethernet-Netzwerk sein kann. Das Verwaltungssystem ist vorwiegend in mehrere Computer des Arbeitsstationsnetzwerks unterteilt, wobei manche der Computer eine Datenbank DB umfassen, die die Daten enthält, die zur Steuerung des Netzwerks erforderlich sind. Das Verwaltungssystem ist über eine in den Standards definierte Schnittstelle Q3 zum Beispiel mit einem Sende- bzw. Übertragungsnetzwerk DCN verbunden, das zum Beispiel SDH-Einrichtungen 21 und PDH-Einrichtungen 23 umfassen kann. Die Steuerkanäle zwischen den SDH-Einrichtungen bestehen in der Praxis aus Kopfbytes eines STM-N-Signals (N = 1, 4, 16), so daß die Steuersignale zwischen den SDH-Einrichtung zusammen mit dem Nutzlastsignal (d. h. in demselben physikalischen Netzwerk) fortschreiten.
Konventionelle PDH-Einrichtungen 23 wiederum erfordern Anordnungen, die für jeden Hersteller spezifisch sind, weswegen sie über eine separate Anpassungseinrichtung 22 mit dem Verwaltungssystem verbunden werden müssen.
Das erfindungsgemäße System umfaßt einen Code-Generator 11, der automatisch einen Teil des anwendungsspezifischen Computerprogramms 10 erzeugt, das in dem System verwendet wird und nachstehend als Anwendungsgefüge bezeichnet wird. Dieses ist das Programmgefüge, welches abläuft, wenn der Betreiber die Netzwerkverwaltungsdienste von seiner Arbeitsstation aus benutzt. Die fertiggestellte Anwendung wird auf einem Server oder einer individuellen Arbeitsstation des Arbeitsstationsnetzwerks (oder auf beiden) gespeichert.
Für den Generator wird eine Beschreibung der Anwendung mit hohem Abstraktionsgrad erzeugt, wobei die Beschreibung die erste Eingabegruppe des Generators bildet. Diese Beschreibung ist mit dem Bezugszeichen 12 bezeichnet. Die Beschreibung kann beispielsweise manuell direkt in einer Textform geschrieben werden, die von dem Generator verstanden wird, und die Beschreibung kann danach als eine Datei in dem Systemspeicher gespeichert werden. Die Beschreibung kann auch mit einer bekannten CASE (Computer Aided Software Engineering)-Einrichtung erzeugt werden, bei der die Anwendung in Form einer graphischen Beschreibung angezeigt wird. In diesem Fall wird die durch die CASE-Einrichtung in der Datei gespeicherte Beschreibung mit einem speziellen Umwandlungsprogramm in eine Form umgewandelt, die von dem Generator verstanden wird.
Eine weitere Eingabegruppe für den Generator besteht aus Schablonendateien 13, die als Modelle für die Erzeugung des Anwendungsgefüges wirken. Der Code-Generator 11 erzeugt das Anwendungsgefüge durch Neuerzeugen des Codes für die Schablonendateien auf der Grundlage der durch den Entwickler geschriebenen Beschreibung 12. Die Schablonendateien sind in zwei Gruppen 13a und 13b unterteilt, und ein bestimmter Teil des Anwendungsgefüges wird auf der Grundlage jeder Gruppe erzeugt. Die Schablonendateien sind feste Dateien, die nicht geändert werden müssen, wenn die Anwendung modifiziert wird. In dieser Hinsicht könnten die Schablonendateien auch als ein Teil der internen Implementierung des Code-Generators 11 betrachtet werden.
Aus den vorstehend beschriebenen beiden Eingabegruppen erzeugt der Code-Generator seinen eigenen (in Fig. 1 mit dem Ausdruck "erzeugter Code" bezeichneten) Teil des anwendungsspezifischen Computerprogramms 10 (d. h. des Anwendungsgefüges), das auf der rechten Seite von Fig. 1 gezeigt ist. In Übereinstimmung mit der Erfindung ist das Anwendungsgefüge derart in drei verschiedene Gruppen oder Schichten A bis C unterteilt, daß die Eigenschaften der Gruppe A an die Gruppe B vererbt werden und die Eigenschaften der Gruppe B an die Gruppe C vererbt werden. In Fig. 1 ist die Vererbung durch ein nach oben zeigendes Dreieck angegeben.
Die erste Gruppe A (die unterste Schicht; obwohl die Schicht in der Figur als die oberste dargestellt ist, ist sie für den Entwickler die unterste) enthält nur solchen Programmcode, der unabhängig von der Anwendung gleich bleibt. Daher muß diese Gruppe nicht speziell erzeugt werden, sondern bleibt von einer Anwendung zu einer anderen gleich. Die Gruppe enthält die Funktionalität, die von einer Anwendung zu einer anderen gleich bleibt. Selbst dann, wenn einige Änderungen der Anwendung durchzuführen wären, oder die Anwendung insgesamt geändert würde, bliebe diese Gruppe immer gleich. In diesem Beispiel besteht die erste Gruppe aus MVC++ Basisklassen (die für alle Anwendungen dieselben sind).
Die zweite Gruppe B (die mittlere Schicht) und die dritte Gruppe C (die oberste Schicht) sind mit einem mit dem Code-Generator 11 erzeugten Programmcode versehen. Die Unterteilung ist derart durchgeführt, daß die zweite Gruppe nur mit einem Programmcode versehen ist, der mittels dem Generator erzeugt wurde, und die dritte Gruppe wiederum mit einem Code versehen ist, der durch sowohl den Generator als auch manuell durch den Entwickler erzeugt wurde. Während der Erzeugung wird daher die dritte Gruppe mit einem Code versehen, an dem der Entwickler Änderungen, beispielsweise Hinzufügungen, vorzunehmen beabsichtigt. Nach der Erzeugung führt der Entwickler die erforderlichen Änderungen für die dritte Gruppe durch. Die dritte Gruppe ist daher in ihrer endgültigen Form in zwei Teile unterteilt: in einen Teil C1, der nur einen durch den Generator erzeugten Code enthält, und in einen Teil C2, der einen manuell durch den Entwickler produzierten Code enthält.
Die zweite Gruppe B umfaßt die Klassen, die die anwendungsspezifische Standardfunktionalität enthalten. Diese Klassen werden mittels des Generators auf eine nachstehend beschrieben Art und Weise erzeugt, so daß der Entwickler in keiner Phase irgendwelche Änderungen in dieser Gruppe durchführen muß. Diese Standardfunktionalität ist von der Anwendungsstruktur und den mit dieser verbundenen Diensten abhängig, und kann derart geändert werden, daß die Eigenschaften, die der Entwickler zu der Anwendung (d. h. zu Gruppe C) hinzugefügt hat, erhalten werden. Die zweite Gruppe wird auf der Grundlage der entsprechenden Schablonendateien (13a) und der Beschreibung 12 erzeugt. Die Klassen der zweiten Gruppe sind in dem System in ihren eigenen Dateien gespeichert, welche keinen durch den Entwickler handgeschriebenen Code enthalten. Diese Klassen werden nachstehend als Standardklassen bezeichnet.
Die dritte Gruppe (C) besteht aus Skelettklassen, die Klassen sind, für welche der Entwickler manuell eine zusätzliche von der Anwendung benötigte Funktionalität schreibt. Aufgrund den technischen Eigenschaften von Programmiersprachen müssen auch Änderungen an den Skelettklassen während der Neuerzeugung des Anwendungsgefüges durchgeführt werden. Zu diesem Zweck wird der neu zu erzeugende Code (Teil C1) von dem Rest des Codes (Teil C2) in den die Skelettklassen enthaltenden Dateien getrennt. Die Trennung verwendet Zeichenketten, welche speziell für diesen Zweck reserviert sind und auf der Grundlage welcher der Generator die Teile der Dateien erkennt, die während der Änderung neu zu erzeugen sind.
Informationen darüber, ob der zu erzeugende Code ein Teil der Standardklassen (d. h. Gruppe B) oder der Skelettklassen (d. h. Gruppe C) ist, wird mittels der Schablonendateien an den Generator übergeben. Zu diesem Zweck umfaßt der Schablonendateiabschnitt 13 speziell einen der Gruppe B entsprechenden Teil, d. h. die Schablonendateien 13a der die Standardfunktionalität enthaltenden Klassen, und einen der Gruppe C entsprechenden Teil, d. h. die Schablonendateien 13b der Skelettklassen. Die Schablonendateien der Standardklassen sind ein Modell für die Funktionalität, die auf der Grundlage der Beschreibungsdatei 12 automatisch implementiert werden kann. Mittels der Schablonendateien 13b der Skelettklassen werden die Rahmen erzeugt, die durch den Entwickler mit dem Code ergänzt werden, der nicht automatisch erzeugt werden kann. Der begleitende Anhang 1 verwendet die Schablonendateien der Standard- und Skelett- Hauptsteuerklassen als Beispiele.
Wenn das Anwendungsgefüge das erste Mal erzeugt wird, schreibt der Code-Generator den erforderlichen Code in die Gruppen B und C. Wenn Änderungen an der endgültigen Anwendung durchzuführen sind, schreibt der Generator die Gruppen B und C neu. Der Generator kann die Gruppe B auf der Grundlage der geänderten Eingabedaten vollständig neu schreiben, jedoch müssen zunächst die Inhalte der Gruppe C (Skelettklassen) gelesen werden, so daß der Generator den manuell durch den Entwickler hinzugefügten Teil erkennt und dieser so belassen werden kann, wie er ist.
Wenn der zu erzeugende Code derart ist, daß er einen Code des Generators enthält, wird der zu erzeugende Code um einen Identifikator ergänzt, mittels dem der zu erzeugende Code und der manuell geschriebene Code verbunden werden. Dies wird nachstehend näher beschrieben.
Der Generator liest Schablonendateien. Wenn der Generator eine bestimmte Zeichenkette, die zu diesem Zweck rserviert wurde, in den Schablonendateien findet, ersetzt der die Kette bzw. den String durch den Codeteil, den er erzeugt hat. Der Generator erzeugt diese Codeteile in Übereinstimmung mit seinen eigenen Erzeugungsregeln und der Anwendungsbeschreibung. Die Erzeugungsregeln hängen von der verwendeten Anwendungsarchitektur ab, sind jedoch unabhängig von einer einzelnen Anwendung. (Die Erzeugungsregeln bilden daher eine Art einer Funktion, die ein Ergebnis bereitstellt, das von dem verwendeten Parameter, d. h. von der Beschreibung 12 der Anwendung, abhängig ist.)
Wie aus dem Vorstehenden ersichtlich ist, hat das zu erzeugende Anwendungsgefüge die folgenden Eigenschaften:
1. Der manuell geschriebene Code und der automatisch erzeugte Code werden durch Aufteilen der Anwendung in Standardklassen und Skelettklassen voneinander getrennt.
2. Der manuell geschriebene Code und der zu erzeugende Code werden innerhalb der Skelettklassen mittels für diesen Zweck reservierten Zeichenketten getrennt.
3. Der manuell geschriebene Code und der zu erzeugende Code werden mit speziellen Identifikatoren kombiniert, wenn der zu erzeugende Code einen direkt handgeschriebenen Code enthält.
Fig. 2 veranschaulicht ein Beispiel der Erzeugung einer fertiggestellten Anwendung mit dem erfindungsgemäßen Verfahren. Der Entwickler erstellt zunächst ein Objektdiagramm mit beispielsweise einer CASE-Einrichtung. Die Beschreibung wird entweder durch manuelles Schreiben derselben oder alternativ mittels eines Umwandlungsprogramms in eine Form umgewandelt, die von dem Code-Generator 11 verstanden wird. Der Code-Generator erzeugt dann das Anwendungsgefüge 10, welches in diesem Beispiel aus Dateien in der Sprache C++ (Steuerklassen und funktionelle Ansichtsklassen) und aus Dateien (visuelle Ansichtsklassen) im Format des Benutzerschnittstellenwerkzeugs (beispielsweise X-DesignerTM, dem Warenzeichen von Imperial Software Limited) besteht. Der Entwickler ergänzt die Funktionalität der Anwendung mittels manueller Codierung und (beispielsweise dem vorstehend erwähnten) Benutzerschnittstellenwerkzeug der Benutzerschnittstelle. Das Programm kann dann zu einem Programm kompiliert und verbunden bzw. gelinkt werden, welches in zum Beispiel einem Netzwerkverwaltungssystem lauffähig ist, in welchem das Netzwerk und seine Netzwerkelemente (physikalischen Einrichtungen) von einer Arbeitsstation WS aus über ein Übertragungsnetzwerk gesteuert werden. Die vorstehend beschriebenen Entwicklungswerkzeuge können sich auch in einer Arbeitsstation des Netzwerkverwaltungssystems befinden, so daß das Personal des Betreibers selbst die in dem Netzwerkverwaltungssystem erforderlichen Änderungen durchführen kann.
Nachfolgend wird die Implementierung der Anwendung unter beispielhafter Verwendung einer imaginären Anwendung Die Funknetzwerkparameter der Basisstation mit Bezug zu der Netzwerkverwaltung veranschaulicht, wobei es die Anwendung möglich macht, Parameter mit Bezug zu dem Funknetzwerk der Basisstation zu betrachten und festzulegen.
Fig. 3a zeigt das Hauptfenster der Anwendung, wie es auf der Anzeige der Arbeitsstation WS des Steuerzentrums in dem Netzwerkverwaltungssystem MS von Fig. 1 zu sehen ist. Die Anwendung wird über die Hauptbenutzerschnittstelle des Netzwerkverwaltungssystems gestartet, woraufhin das Hauptfenster der Anwendung auf der Anzeige erscheint. In diesem Fenster können die Daten mit Bezug zu der Sendeleistung der Basisstation gelesen und festgelegt werden. Die Anwendung umfaßt auch ein Unterfenster, das in Fig. 3b gezeigt ist. Die zu behandelnde Basisstation kann in diesem Unterfenster ausgewählt werden.
Der Entwickler zeichnet zunächst mit der CASE-Einrichtung ein die Anwendung beschreibendes Objektmodell. Das erhaltene Modell ist in Fig. 4 gezeigt, unter Verwendung der weithin verwendeten OMT-Notation, die in beispielsweise Object Oriented Modelling and Design von James Rumbaugh et al. (Prentice-Hall, New Jersey, USA, 1991, Kapitel 3) beschrieben ist. (Es wird angemerkt, daß der auf der linken Seite von Fig. 4 gezeigte und nicht mit irgendeiner Klasse verbundene Rahmen 4a zusätzliche Informationen über die nachstehend im Einzelnen beschriebene gesamte Anwendung bereitstellt. Mittels der Ansichtsartendefinitionen 4B und 4C werden die den Ansichtsklassen vererbten Benutzerschnittstellenkomponenten ausgewählt.)
Diese graphische Beschreibung wird durch ein Umwandlungsprogramm oder durch manuelles Umschreiben in eine von dem Code-Generator verstandene Form umgewandelt. Der so erhaltene Code ist in Fig. 5 gezeigt. Um diese Beschreibungsdatei zu verstehen, zeigt der begleitende Anhang 2 die Syntax der verwendeten Beschreibungssprache. (Fig. 5 zeigt mittels geklammerten Ausdrücken eine ähnliche hierarchische Struktur wie in Fig. 4 mit der OMT- Notation gezeigt.)
Das Anwendungsgefüge 10 wird dann unter Verwendung des Anwendungsgenerators 11 erzeugt. Das in Fig. 5 gezeigte Listing wird dann in das in Fig. 6 gezeigte Anwendungsgefüge generiert. Fig. 6 zeigt die vorstehend beschriebene Gruppenteilung derart, daß von dem erzeugten Code die zu der Gruppe B (d. h. den Standardklassen) gehörenden Klassen mit dünnen Rahmen dargestellt sind, und die Klassen der Gruppe C (d. h. die Skelettklassen) mit dicken Rahmen gezeigt sind. Der Programmierer erkennt folglich aus dem Anwendungsgefüge als dem C++ Quellcode die mit dicken Rahmen gezeigten (Ansichts-, Steuer- und Abstraktpartner-) Klassen. Der Entwickler implementiert die Funktionalität der Anwendung durch Hinzufügen einer notwendigen Codemenge zu diesen Skelettklassen. (Ein abstrakter Partner ist eine Klasse, die beschreibt, was ein Objekt von einem aufrufenden Objekt erwartet. Da das Konzept des abstrakten Partners keinen Bezug zu der tatsächlichen erfinderischen Idee hat, wird es in diesem Zusammenhang nicht näher beschrieben. Eine tiefergehende Beschreibung des abstrakten Partners ist in dem vorstehend erwähnten Artikel über MVC++ bereitgestellt.)
Der Entwickler implementiert die Anordnung der Benutzerschnittstelle durch Editieren der visuellen Ansichtsklassen (der Klassen, die in den Figuren mit durchbrochenen dicken Rahmen gezeigt sind) mit einem Benutzerschnittstellenwerkzeug (beispielsweise X-DesignerTM). Die anderen in Fig. 6 gezeigten Klassen sind für den Entwickler nicht sichtbar. (Die in der Figur gezeigten und an die visuellen Ansichtsklassen vererbten Benutzerschnittstellenkomponenten werden auf der Grundlage der in der Beschreibungsdatei 12 angegebenen Ansichtsartendefinition ausgewählt.)
Wenn die Fig. 4 und 6 verglichen werden, wird ersichtlich, wie es die erfindungsgemäße Anordnung möglich macht, den Abstraktionsgrad der Programmierarbeit zu erhöhen. Eine Beschreibung des Abstraktionsgrads von Fig. 4 kann in die (ziemlich komplizierte) Klassenhierarchie von Fig. 6 umgewandelt werden. Von den Klassen der Fig. 6 sieht der Entwickler nur die mit dicken Rahmen dargestellten Klassen, so daß der Entwickler auch den erzeugten Code auf einem hohen Abstraktionsgrad sieht.
Die Namengebung der zu erzeugenden Klassen verwendet die in der folgenden Tabelle gezeigte Namengebungsregel. In der Tabelle ist die Zeichenkette "abc" ein Präfix mit drei Buchstaben der in der Beschreibungsdatei gegebenen Anwendung (Fig. 5).
abcDefaultProgram_c Standardhauptprogrammklasse der Anwendung
abcProgram_c Skeletthauptprogrammklasse der Anwendung
abcDefaultMainController_c Standardhauptsteuerklasse der Anwendung
abcMainController_c Skeletthauptsteuerklasse der Anwendung
abcDefaultMainView_c Standardhauptansichtsklasse der Anwendung
abcMainView_c Skeletthauptansichtsklasse der Anwendung
abcDefaultMainViewAbsVP_c Standardhauptansichtsabstraktpartnerklasse der Anwendung
abcMainViewAbsVP_c Skeletthauptansichtsabstraktpartnerklasse der Anwendung
abcDefault Controller_c Standarduntersteuerklasse, worin der in der Beschreibungsdatei gegebene Untersteuerungsname ist
abc Controller_c Sekelettuntersteuerklasse, worin der in der Beschreibungsdatei gegebene Untersteuerungsname ist
abcDefault ControllerAbsCP_c Standarduntersteuerklassenabstraktpartnerklasse, worin der in der Beschreibungsdatei gegebene Untersteuerungsname ist
abc ControllerAbsCP_c Skelettuntersteuerklassenabstraktpartnerklasse, worin der in der Beschreibungsdatei gegebene Untersteuerungsname ist
abcDefault View_c Standardunteransichtsklasse, worin der in der Beschreibungsdatei gegebene Untersteuerungsname ist
abc View_c Skelettunteransichtsklasse, worin der in der Beschreibungsdatei gegebene Untersteuerungsname ist
abcDefault ViewAbsVP_c Standardunteransichtsabstraktpartnerklasse, worin der in der Beschreibungsdatei gegebene Untersteuerungsname ist
abc ViewAbsVP_c Skelettunteransichtsabstraktpartnerklasse, worin der in der Beschreibungsdatei gegebene Untersteuerungsname ist
Die folgenden Elemente A bis E zeigen beispielhaft die Erzeugung der Deklaration der Standardhauptsteuerklasse (der Klasse "abcDefaultMainController_c" von Gruppe B) auf der Grundlage der Schablonendatei und der Daten in der Beschreibungsdatei. Die Rahmen zeigen die Teile der Dateien, die geändert sind. Der Rahmen besitzt auf einer Linie einen Pfeil, und der dem Pfeil vorangehende Teil beschreibt die Situation vor der Änderung, wohingegen der auf den Pfeil folgende Teil die Situation nach der Änderung beschreibt.
A. Der Name der Klasse wird durch Ersetzen der Zeichenkette "fft" in dem Klassennamen (vgl. Anhang 1) der Schablonendatei durch ein in der Beschreibungsdatei bereitgestelltes Anwendungspräfix, in diesem Fall "abc", erhalten:
B. Der Name der Hauptansichtsabstraktpartnerklasse, der an die Standardklasse zu vererben ist, wird durch Ersetzen des Teils "fft" durch "abc" in der Zeichenkette "fftMainViewAbsVP_c" erhalten. Die Namen der Untersteuerabstraktpartnerklassen, die an die Hauptsteuerung zu vererben sind, werden in Übereinstimmung mit der Namengebungsregel gebildet. Sie werden in eine Zeichenkette ausgebildet, in der die Namen der Abstraktpartnerklassen durch ein Komma und ein Zeilenvorschubzeichen getrennt sind. Die so erhaltene Zeichenkette ersetzt die Zeichenkette INHERIT ABS in der Schablonendatei:
C. In der Deklaration der Verfahren des öffentlichen (public) Teils in der Schablonendatei wird die Zeichenkette "fft" durch "abc" ersetzt:
D. In der Deklaration des geschützten (protected) Teils der Schablonendatei wird die Zeichenkette "fft" durch "abc" ersetzt, und wird MAINVIEW_C durch einen in Übereinstimmung mit der Namengebungsregel gebildeten Hauptansichtsnamen ersetzt. Die Zeichenkette SUB_CONT_DECLARATIONS wird durch eine auf die folgende Art und Weise gebildete Zeichenkette ersetzt:
Die folgenden Schritte werden für jede in der Beschreibungsdatei definierte Untersteuerung wiederholt:
1. Eine Zeichenkette in Übereinstimmung mit der Namengebungsregel wird als der Name einer Untersteuerklasse auf der Grundlage des bei der Definition sub_controller der Schablonendatei vergebenen Namens gebildet.
2. Die Zeichenkette wird, in der genannten Reihenfolge, um ein Leerzeichen und ein Sternzeichen ergänzt.
3. Falls ein Instanzenname für die Untersteuerung mittels der Instanzendefinition definiert worden ist, wird dieser zu der Zeichenkette hinzugefügt, andernfalls wird ein bei der Definition sub_controller vergebener Name zu der Zeichenkette hinzugefügt.
4. Die Zeichenkette wird um ein Semikolon und ein Zeilenvorschubzeichen ergänzt.
Die auf diese Art und Weise erhaltenen Zeichenketten werden kombiniert.
E. Der private (private) Teil wird durch Ersetzen der Zeichenkette "fft" durch "abc" wie in der Beschreibungsdatei 12 gegeben gebildet:
Die durch die veranschaulichende Anwendung erzeugten Dateien sind in der nachstehenden Tabelle gezeigt:
Wie die Tabelle und Fig. 4 zeigen, wird eine Steuerklasse der Anwendungsbeschreibung in zwei Klassen, d. h. eine Skelettklasse (zu Gruppe C gehörend) und eine Standardklasse (zu Gruppe B gehörend), umgewandelt. Die Ansichtsklassen wiederum werden in drei Klassen umgewandelt: für den funktionellen Teil der Ansicht Standard- und Skelettklassen, und für den visuellen Teil der Ansicht nur eine Skelettklasse (da dieser Teil mit dem Benutzerschnittstellenwerkzeug auf einer höheren Ebene als der des Quellcodes verarbeitet werden kann).
Nachstehend sind Beispiele der Hauptsteuer-Standard- und -Skelettklassen gezeigt. Die Kopf- und die Implementierungsdateien der Standardklasse sind zuerst gezeigt, und die Kopf- und die Implementierungsdateien der Skelettklassen sind als nächstes gezeigt. Eine Kopfdatei zeigt die Schnittstelle des nach außen hin sichtbaren Objekts, d. h. die Funktionen, die ein anderes Objekt aufrufen kann. Eine Implementierungsdatei wiederum enthält den tatsächlichen Code, der ausgeführt wird, wenn eine Funktion aufgerufen wird.
Die Kopfdatei (in der Sprache C++) "abccontmadfmx.h" der Standardhauptsteuerklasse ist wie folgt (wenn die im Anhang gezeigte Schablonendatei auf die vorstehend beschriebene Art und Weise geändert worden ist):
Die Implementierungsdatei "abccontmadfmx.cc" der Standardhauptsteuerklasse ist wie folgt:
Eine Skeletthauptsteuerklasse wird als nächstes beschrieben. Die Kopfdatei "abccontmainmx.h" der Skelettklasse ist wie folgt (vgl. die im Anhang 1 gezeigte entsprechende Schablonendatei).
Die Implementierungsdatei "abccontmainmax.cc" der Skeletthauptsteuerklasse dagegen ist wie folgt.
Der Entwickler implementiert die von der Anwendung benötigte Funktionalität durch Hinzufügen einer ausreichenden Menge von Code zu den Skelettklassen. Die Benutzerschnittstelle wird beispielsweise um das vorstehend erwähnte X-DesignerTM-Werkzeug unter Verwendung erzeugter Beschreibungen der visuellen Ansichtsklassen mit dem Format des X-DesignersTM ergänzt.
Die Klassen des Modellteils, BaseStation_c and BaseStation- Group_c (vgl. Fig. 4), wurden bereits in der Klassenbibliothek des Modellteils implementiert, weswegen sie in Verbindung mit der vorliegenden Anwendung nicht ausgeführt zu werden brauchen.
Wie aus dem Vorstehenden ersichtlich ist, erzeugt der Code- Generator Standard- und Skelettklassen automatisch durch Modifizieren der entsprechenden Schablonendateien auf der Grundlage der in der Beschreibungsdaten der Anwendung bereitgestellten Daten.
Vorstehend wurde im Einzelnen beschrieben, wie das Anwendungsgefüge erzeugt wird. Dieses Beispiel beschrieb somit eine Situation, in der eine Anwendung erstmalig erzeugt wird. Als nächstes wird eine Situation untersucht, in der Änderungen an dem Anwendungsgefüge durchgeführt werden müssen. Das Beispiel bezieht sich auf eine Situation, in der der das Netzwerkverwaltungssystem verwendende Betreiber die Hinzufügung einer neuen Eigenschaft, eines sogenannten Prioritätsdienstes, zu der Basisstation-Steuereinrichtung benötigt. In dem Netzwerk dieses Betreibers sind die Kunden in zwei Klassen unterteilt: diejenigen, die eine Goldkarte haben, und diejenigen, die eine Silberkarte haben. Falls während hohen Datenaufkommens alle Kanäle in Benutzung sind und ein Benutzer mit einer Goldkarte einen Anruf tätigt, wird einer der Benutzer einer Silberkarte aus dem Kanal entfernt. Dieser Dienst erfordert einen neuen Parameter, der anzeigt, ob der Prioritätsdienst verwendet wird.
Fig. 7 veranschaulicht die in der Benutzerschnittstelle erforderliche Änderung. Wie Fig. 3a und 7 zeigen, wird das Fenster mit einem neuen Parameter "Prioritätsmodus" versehen, welcher zwei Werte (Ja oder Nein) haben kann.
Fig. 8 veranschaulicht die in dem Objektdiagramm, das an früherer Stelle in Fig. 4 gezeigt wurde, erforderliche Änderung. Fig. 8 zeigt nur den Teil des Diagramms, der geändert wird. Das Diagramm ist folglich mit einer neuen Klasse "BaseStationeontroller_c" versehen, deren Attribut "priorityMode" ist, und das Verfahren "SetPriorityMode".
Es wird in diesem Zusammenhang auch angemerkt, daß die Aktualisierung der Funknetzwerkparameter in einer Basisstation eine lange Zeit in Anspruch nimmt. Daher muß die Anwendung mit einem sogenannten Arbeitsdialog versehen sein, der dem Benutzer anzeigt, daß der Betriebsablauf noch im Gange ist. Fig. 9 veranschaulicht ein Arbeitsdialogfenster.
Zunächst wird die Hinzufügung des Prioritätsdienstes beschrieben. Um diese Änderung (die Hinzufügung eines neuen Parameters zu den Verfahren "ShowParametersFM" und "AbcUpdateßuttonActivated", welche die Änderung betrifft) zu implementieren, wird der neue boolean_t-Parameter "priorityMode" zu der Deklaration der Verfahren in der Beschreibungsdatei 12 der Anwendung hinzugefügt. Der nachstehende Rahmen zeigt einen Teil der vorstehend gezeigten Beschreibungsdatei. Der Rahmen zeigt fett gedruckt die Hinzufügungen zu der Beschreibungsdatei, wenn der Prioritätsdienst hinzugefügt wird.
Die Identifikatoren #abc1# und #abc2# zeigen, daß logisch noch immer dieselben Verfahren verwendet werden (d. h. die für die Verfahren geschriebene Implementation dieselbe bleibt), obwohl sich die Deklaration ändert.
Wenn die erforderlichen Änderungen der Beschreibungsdatei durchgeführt worden sind, wird der Code mittels dem Code-Generator neu erzeugt. Der Code-Generator aktualisiert dann in den Kopfdateien der Skeletthauptansichts- und -hauptsteuerklassen die Teile, die neu zu erzeugen sind. Die neu zu erzeugenden Teile sind durch die Zeichenketten AF_TOKEN_END und AF_TOKEN_START angegeben und können daher aktualisiert werden, ohne daß irgendwelche anderen Teile in der Datei geändert werden (AF_TOKEN_START ist das Anfangs zeigen, und AF_TOKEN_END ist das Endezeichen für den neu zu erzeugenden Teil.)
Vor der Änderung ist die gemeinsame Kopfdatei der Skeletthauptansichts- und -abstraktpartnerklassen wie folgt:
Nach der Änderung ist die Situation wie folgt (die hinzugefügten Teile sind fett gedruckt gezeigt).
Die vorstehend beschriebene Kopfdatei der Skeletthauptsteuerklasse wiederum ist nach der Änderung wie folgt (nur ein Teil der Datei ist gezeigt, die geänderten Teile sind fett gedruckt).
Die automatische Hinzufügung desvorstehend erwähnten Parameters (boolean_t priorityMode) zu der Deklaration des "void AbcUpdateButtonActivated()"-Verfahrens in den Deklarationen der Skeletthauptsteuerklassen und den Skeletthauptansichtsabstraktpartnerklassen veranschaulicht, wie leicht es ist, mit der erfindungsgemäßen Anordnung neue Eigenschaften zu dem Anwendungsgefüge hinzuzufügen. Die vorstehend erwähnte Hinzufügung wurde ausgeführt durch Durchführen der Hinzufügung zu der Beschreibungsdatei und durch Neuerzeugen des Codes durch den Code-Generator. Es wird angemerkt, daß auch die Standardklassen in diesem Zusammenhang neu erzeugt werden, aber in diesem Beispiel keine Änderungen in den Standardklassen auftreten (da keine diese betreffenden Änderungen an der Beschreibungsdatei erfolgten).
Das in der Implementierungsdatei der Skeletthauptsteuerklasse zu ändernde Partnerverfahren wird mit dem auf AF_TOKEN folgenden (in der Beschreibungsdatei bereitgestellten) Identifikator #abc2# identifiziert. Die Änderung findet in der folgenden Art und Weise statt: Der Code-Generator liest die Datei und eliminiert die Zeichen beginnend mit der auf AF_TOKEN folgenden Zeile bis zu dem ersten "{"-Zeichen und schreibt an diese Stelle die neue Deklaration des Partnerverfahrens (auf der Grundlage der neuen Deklaration der Beschreibungsdatei). Der Code-Generator fährt sodann fort, die Datei zu durchsuchen, bis er auf die erste AF_TRACE-Zeichenkette stößt. Der Code-Generator ersetzt die Zeichen in den Klammern, die auf AF_TRACE folgen, durch eine neue Partnerverfahrendeklaration. Der Code-Generator durchsucht dann die Datei rückwärts, bis er auf die Zeichenkette < PUBLIC> FUNCTION: stößt. Der Code-Generator eliminiert die auf < PUBLIC> FUNCTION: folgenden Zeichen bis zu dem nächsten Zeilenvorschubzeichen und schreibt an deren Stelle die neue Partnerverfahrendeklaration (Anmerkung: Obwohl in dem nachstehend gegebenen Code-Beispiel die Deklaration des abstrakten Partnerverfahrens in der folgenden Zeile fortgesetzt wird, erscheint das Zeilenvorschubzeichen nur am Ende der Deklaration des Verfahrens).
Das vorstehend beschriebene Ändern der Verfahrensdeklaration (d. h. Hinzufügen des Parameters zu der Deklaration) ist ein Beispiel dafür, wie ein Zusammenhang zwischen einem durch den Code-Generator erzeugten Code und einem durch den Programmierer geschriebenen Code beibehalten wird. In diesem Beispiel ist die Zeichenkette "abc2" ein Identifikator, welcher dem Verfahren (UpdatefluttonActivated) entspricht und mittels dem der Zusammenhang beibehalten wird. Der Programmierer hatte früher einen Code manuell in den für dieses Verfahren erzeugten Rahmen geschrieben, um die Parameter für die Basisstation-Steuereinrichtung zu aktualisieren.
Das Verfahren "ShowParametersFM()" wird in der Implementierungsdatei "abcviewmainmx.cc" der Hauptansichtsklasse auf dieselbe Art und Weise wie das vorstehend beschriebene abstrakte Partnerverfahren in der Implementierungsdatei der Hauptsteuerung geändert. Der diesem Verfahren entsprechende Identifikator ist "abc1", wie die Beschreibungsdatei der Anwendung zeigt. Mittels diesen in der Beschreibungsdatei gegebenen Indentifikatoren ist es auch dann, nachdem die Änderungen der Beschreibungsdatei und die Neuerzeugung der Skelettklassen erfolgt sind, bekannt, welchem Teil der Skelettklasse jede Änderung entspricht.
Die Hinzufügung des Prioritätsdienstes zu der Anwendung wurde vorstehend beschrieben. Nachstehend wird die Hinzufügung des vorstehend erwähnten Arbeitsdialogs beschrieben.
Um diese Änderung durchzuführen, müssen die Kopfdateien der Hauptsteuerklassen um die Kopfdatei der Arbeitsdialogkomponente ergänzt werden, muß die abstrakte Partnerklasse des Arbeitsdialogs an die Hauptsteuerung vererbt werden, müssen die abstrakten Partnerverfahren des Arbeitsdialogs deklariert werden, und muß eine Variable als ein Zeiger auf das Arbeitsdialogobjekt deklariert werden. Ein Zeiger muß in der Implementierungsdatei der Hauptsteuerklasse auf den Arbeitsdialog initialisiert werden, eine neue Arbeitsdialog-Objektinstanz muß erzeugt werden, der Arbeitsdialog-Objektdialog muß gelöscht werden, und die abstrakten Partnerverfahren des Arbeitsdialogs müssen implementiert werden.
In der Praxis wird die Änderung durch Schreiben der Zeile:
in den Definitionsteil der Hauptsteuerung in der Beschreibungsdatei (Bezugszeichen 12, Fig. 1) der Anwendung und durch Neuerzeugen des Anwendungsgefüges ausgeführt. Nachstehend sind die bei der Neuerzeugung durch eine in der Beschreibungsdatei durchgeführte Änderung verursachten Änderungen gezeigt.
Der Code-Generator erzeugt die Kopfdatei "abccontmadfmx.h" der Standardklasse neu, zu deren Kopfdatei die Kopfdatei der Arbeitsdialogkomponente hinzugefügt wurde, an welche Kopfdatei die abstrakte Partnerklasse des Arbeitsdialogs vererbt wurde, und welcher Kopfdatei eine Verbindung zu dem Arbeitsdialogobjekt zu dem geschützten Teil der Klasse hinzugefügt wurde (diese Änderungen sind fett gedruckt gezeigt):
Der Code-Generator erzeugt auch die Implementierungsdatei "abccontmadfmx.cc" der Standardklasse neu, wobei
1. der Arbeitsdialogzeiger initialisiert wird:
2. der Arbeitsdialog gelöscht wird:
und
3. eine neue Arbeitsdialog-Objektinstanz erzeugt wird:
Abstrakte Partnerdeklarationen werden in der Kopfdatei "abccontmainmx.h" der Skeletthauptsteuerklassen neu erzeugt, wobei das abstrakte Partnerverfahren des Arbeitsdialogs in diese eingeschlossen wird:
Der Code-Generator identifiziert den neu zu erzeugenden Teil mittels AF_TOKEN_START und AF_TOKEN_END und kann daher einen Teil der Datei so ändern, daß der Rest des Codes gleich bleibt.
Ein Rahmen wird in der Implementierungsdatei "abccontmainmx.cc" der Skeletthauptsteuerklasse für die Implementierung des abstrakten Partnerverfahrens erzeugt:
In diesem Rahmen des abstrakten Partnerverfahrens implementiert der Entwickler eine Funktionalität, die auf das Drücken des Abbrechen-Schalters des Arbeitsdialogs folgen soll.
Der Entwickler aktiviert (zeigt auf der Anzeige) den Arbeitsdialog durch Schreiben der Anforderung workingDialog→ ShowLongDelay(MESSAGE_TEXT) vor den Teil des Codes, der den zeitraubenden Betriebsablauf beginnt, zum Beispiel:
Das vorstehende Beispiel (die Hinzufügung des Arbeitsdialogs) zeigt, wie leicht es ist, eine neue Eigenschaft zu dem Anwendungsgefüge hinzuzufügen. Die Änderung wurde durch Hinzufügen einer Zeile zu der Beschreibungsdatei und Neuerzeugen des Anwendungsgefüges auf der Grundlage der geänderten Beschreibungsdatei implementiert. Der Abstraktionsgrad der Anwendung bleibt ebenfalls hoch, da nur die Verfahren "KuiCancelwanted()" und "ShowLongDelay()" in dem für den Entwickler aus dem Arbeitsdialogdienst sichtbaren Anwendungsteil gezeigt sind. Der kompliziertere Code zum Hinzufügen des Arbeitsdialogobjekts zu der Anwendung wurde (automatisch) für eine Standardklasse, die für den Entwickler nicht sichtbar ist, erzeugt.
Obwohl die Erfindung vorstehend unter Bezugnahme auf die Beispiele in Übereinstimmung mit den begleitenden Zeichnungen beschrieben wurde, ist klar, daß die Erfindung nicht hierauf beschränkt ist, sondern innerhalb des Schutzbereichs der vorstehend und in den beigefügten Patentansprüchen offenbarten erfinderischen Idee modifiziert werden kann. Obwohl vorstehend eine objektbasierte Anwendung beschrieben wurde, ist es im Prinzip möglich, eine ähnliche Anordnung auch in anderen Arten von Anwendungen zu verwenden. Auf vergleichbare Art und Weise kann das Verfahren auch zur Erzeugung von Diensten in anderen Systemen außer den Netzwerkverwaltungssystemen verwendet werden, obwohl die letztgenannten Systeme aus den eingangs dargelegten Gründen eine vorteilhafte Umgebung zur Implementierung bilden.
Die erfindungsgemäße Einrichtung kann einen Teil eines solchen Dienste bereitstellenden Systems bilden, oder das Verfahren kann getrennt von dem System ausgeführt und danach eine fertiggestellte Anwendung an das System übertragen werden.

Anhang 1 - Beispiele von Schablonendateien

Schablone für die Kopfdatei der Standardhauptsteuerklasse.
Schablone für die Implementierungsdatei der Standardhauptsteuerklasse.
Schablone für die Implementierungsdatei der Skeletthauptsteuerklasse.

Anhang 2 - Die Syntax der Beschreibungsdatei des Code-Generators

Die nachfolgende Tabelle zeigt die Syntax der Beschreibungsdatei des Code-Generators. Die kursiv gedruckten Symbole sind Metasymbole. Die Metasymbole sind nicht als solche in der Beschreibungsdatei gezeigt, sondern ihr Zweck besteht lediglich darin, die Syntax in einer leichter lesbaren Form zu zeigen. Die Anfangs- und Ende-Symbole sind in Anführungszeichen gezeigt. Die Anfangs- und Ende-Symbole sind in der Beschreibungsdatei in derselben Form wie in der nachstehenden Tabelle gezeigt. Symbole, die in eckigen Klammern "[","]" gezeigt sind, sind optional. Symbole, die in runden Klammern "{","}" gezeigt sind, können null Mal oder öfter wiederholt sein. Die Kommentarzeilen beginnen mit dem Zeichen #.
Der Entwurf der Struktur der Beschreibungsdatei war durch die allgemeine Struktur der Konfigurationsdateien beschränkt, welche die folgende Form hat:
worin token eine beliebige alphanumerische Zeichen enthaltende Zeichenkette ist, und value eine beliebige Zeichenkette in Anführungszeichen ist.
Das folgende Beispiel stellt die Semantik der Konfigurationsdatei klar.

Claims

1. Verfahren zur Erzeugung anwendungsspezifischer computergesteuerter Dienste für einen Benutzer, umfassend:

- Anlegen einer Beschreibungsdatei, in der die Anwendung, für welche der Dienst beabsichtigt ist, mit den Begriffen der verwendeten Anwendungsarchitektur beschrieben wird;

- automatische Erzeugung eines anwendungsspezifischen Programmcodes, aus dem das anwendungsspezifische Computerprogramm unter Verwendung einer Software-Erzeugungseinrichtung (11) und durch Befolgen der Regeln der verwendeten Anwendungsarchitektur gebildet wird, und

- Ablaufenlassen des Computerprogramms, um den Dienst für den Benutzer bereitzustellen,

dadurch gekennzeichnet, daß das Computerprogramm derart in verschiedene Gruppen aufgeteilt wird, daß

- die erste Gruppe (A) nur aus Programmcode besteht, der unabhängig von der Anwendung gleich bleibt,

- die zweite und die dritte Gruppe mit Programmcode versehen sind, der durch die Erzeugung derart erstellt ist, daß (a) die zweite Gruppe (B) nur einen mittels der Erzeugung erstellten Programmcode enthält und (b) die dritte Gruppe (C) einen mit der Erzeugung erstellten Code enthält, den der Entwickler nach der Erzeugung ändern soll, und

- die Erzeugungseinrichtung (11) darüber informiert wird, ob der zu erzeugende Code für die zweite oder die dritte Gruppe erstellt wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Anwendung objektbasiert ist und die Eigenschaften der ersten Gruppe auf die zweite Gruppe und die Eigenschaften der zweiten Gruppe auf die dritte Gruppe vererbt werden.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß innerhalb der dritten Gruppe der durch den Entwickler zu modifizierende Teil von dem Rest der Gruppe durch zu diesem Zweck reservierte Zeichenketten getrennt wird.

4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß in der Beschreibung ein individueller Identifikator für die Information vergeben wird, der mittels der Erzeugung durch einen Code ergänzt wird, zu dem von dem Entwickler durchgeführte Änderungen hinzuzufügen sind.

5. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß die an die Erzeugungseinrichtung gelieferten Eingangsdaten derart in zwei Teile aufgeteilt werden, daß ein Teil der zweiten Gruppe entspricht und der andere Teil der dritten Gruppe entspricht.

6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß die Teile aus Vorlagendateien bestehen und die Erzeugung durch Ergänzen der Vorlagendateien auf der Grundlage der Anwendungsbeschreibung erfolgt.

7. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Verfahren Netzwerkverwaltungsdienste erzeugt, mit welchen der Benutzer des Netzwerkverwaltungssystems das Telekommunikationsnetzwerk steuert.

8. System zur Erzeugung anwendungsspezifischer computergesteuerter Dienste, umfassend:

- eine in einem Speicher gespeicherte Beschreibung der Anwendung, für welche der Dienst beabsichtigt ist, wobei die Beschreibung mit den Begriffen der verwendeten Anwendungsarchitektur erstellt ist, und

- eine Software-Erzeugungseinrichtung (11) zur Erzeugung eines anwendungsspezifischen Programmcodes in Übereinstimmung mit den Regeln der verwendeten Anwendungsarchitektur,

dadurch gekennzeichnet, daß die Erzeugungseinrichtung betrieblich mit einer Trenneinrichtung (12, 13) verbunden ist zum Trennen des erzeugten Codes in zwei verschiedene Gruppen derart, daß eine Gruppe (B) nur einen mittels der Erzeugung erstellten Programmcode enthält und die andere Gruppe (C) einen durch die Erzeugung erstellten Code enthält, den der Entwickler nach der Erzeugung ändern soll.

9. System nach Anspruch 8, dadurch gekennzeichnet, daß die Trenneinrichtung die Beschreibung und separate Vorlagendateien (13a, 13b) für jede Gruppe umfaßt.

10. System nach Anspruch 8, dadurch gekennzeichnet, daß es Teil eines Netzwerkverwaltungssystems ist, wobei das System dazu verwendet wird, Netzwerkverwaltungsdienste zu erzeugen, mittels welchen der Benutzer des Netzwerkverwaltungssystems das Telekommunikationsnetzwerk steuert.