Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR GENERATING GRAPHIC USER EXITS FOR COMPUTER PROGRAMS
Document Type and Number:
WIPO Patent Application WO/2001/040930
Kind Code:
A2
Abstract:
The invention relates to a method for generating graphic user exits for computer programs. The graphic user exits are generated entirely on the basis of rules stored in a database and the database commands are composed of the rules stored. Wildcards are replaced by the properties of superordinate display elements, thereby generating new display elements.

Inventors:
JESCHKE ROLAND (DE)
Application Number:
PCT/DE2000/004233
Publication Date:
June 07, 2001
Filing Date:
November 28, 2000
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
JESCHKE ROLAND (DE)
International Classes:
G06F8/34; G06F8/38; G06F9/44; (IPC1-7): G06F9/00
Foreign References:
US5509116A1996-04-16
US5892510A1999-04-06
Attorney, Agent or Firm:
Beck, Alexander (Brose + Brose Leutstettener Strasse 13 Starnberg, DE)
Download PDF:
Claims:
PATENTANSPRÜCHE
1. Verfahren zur Erzeugung graphischer Benutzerschnittstellen für Computerprogramme, die vollständig aufgrund von in einer Datenbank abgelegten Regeln erzeugt werden, dadurch gekenn zeichnet, daß jeder Programmzustand der graphischen Benutzer schnittstelle durch a) eine Menge von Listen, die die AnzeigeElemente und deren Inhalt repräsentieren, b) eine hierarchische Ordnung, die den Einträgen in einer Liste aus der Menge von Listen andere Li sten aus der Menge von Listen zuordnet und so das"enthalten sein"von AnzeigeElementen in einander repräsentiert und c) eine Beziehung zwischen den Einträgen in den Li sten der Menge von Listen, die festlegt, welches AnzeigeElement von dem Inhalt welches anderen, übergeordneten AnzeigeElements abhängt, festgelegt ist.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Regeln eine Struktur bilden, die eine Programmspezifikation enthält, die von einem allgemein gültigen Algorithmus inter pretiert wird, der Struktur und Inhalt der Menge von Listen für die graphische Benutzeroberfläche für jeden Programm zustand allein durch Datenbankabfragen aufbaut, die sowohl auf Regeldaten als auch auf die zu verarbeitenden Daten zugreifen, und deren syntak tische Zusammensetzung anhand der Regeln vorge nommen wird, dabei die hierarchische Ordnung zwischen den Li sten aus der Menge der Listen aufrecht erhält, und bei Datenbankabfragen die Beziehung zwischen den Einträgen in den Listen der Mengen von Listen nutzt, um Platzhalter in den Datenbankabfragen durch Inhalte des übergeordneten AnzeigeElements zu ersetzen.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß der allgemeingültige Algorithmus aufgrund von Benutzereingaben den Programmzustand so verändert, wie er durch die durch die Regeln gebildete Struktur und den Inhalt der Regeln sowie durch seine eigene Implementierung vorgesehen ist.
Description:
Verfahren zur Erzeugung grafischer Benutzerschnittstellen für Computerprogramme Die vorliegende Erfindung betrifft ein Verfahren zur Erzeu- gung grafischer Benutzerschnittstellen für Computerprogramme.

Die Erzeugung solcher grafischer Benutzerschnittstellen wird immer wichtiger, da zunehmend bei allen Anwendungen von den Nutzern solche grafischen Oberflächen erwartet werden. Bisher war die Programmierung solcher grafischer Benutzerschnitt- stellen sehr umständlich und zeitaufwendig.

Der nächstgelegene Stand der Technik hinsichtlich der Erzeu- gung graphischer Benutzerschnittstellen für Computerprogramme wird von der US 5,509,116 gebildet. Diese Druckschrift be- schreibt ein System zur Verwaltung graphischer Benutzer- schnittstellen. Dieses setzt als wesentlichen Bestandteil ei- nen"Application Logic Enabler" (ALE) voraus, der aus einem Satz von Anwendungsprogrammen besteht, die ihre Funktionali- tät über eine eigene Benutzerschnittstelle bereitstellen.

Hauptfunktion dieses Verfahrens gemäß dem Stand der Technik ist es, Interaktionen des Benutzers mit diesen Anwendungspro- grammen auf Betriebssystemebene mitzuschneiden, diese Mit- schnitte zu verwalten, zu Stories zu kombinieren, mit einer neuen graphischen Benutzerschnittstelle zu verknüpfen und ab-

hängig von Benutzereingaben wieder abzuspielen (Event Play- back Section). Auf diese Art werden bei dem genannten Stand der Technik existierende Anwendungsprogramme durch eine gra- phische Benutzerschnittstelle gekapselt. Auch dieses Verfah- ren gemäß dem Stand der Technik verwendet ein relationales Datenbankmodell, um die Regeln abzulegen, nach denen die gra- phische Benutzerschnittstelle aufgebaut und interpretiert werden soll.

Weiterer Stand der Technik hinsichtlich der Erzeugung von graphischen Benutzerschnittstellen findet sich in der US 5,892,510. Diese beschreibt Feldobjekte und ein Verfahren zur Entwicklung einer graphischen Benutzerschnittstelle, die die- se Feldobjekte enthält. Dabei wird ein Verfahren beschrieben, das dazu dient, objektorientiertes Sourcecoding zu generie- ren, das nach dem Übersetzen und Binden als Programm ausge- führt werden kann. Dabei werden ebenfalls Anzeige-Elemente der graphischen Benutzeroberfläche mit Spalten von Datenbank- tabellen assoziiert.

Ausgehend von diesem Stand der Technik ist es Aufgabe der vorliegenden Erfindung, eine graphische Benutzeroberfläche und ihre Beziehung zu den verwalteten Daten und ihren Funk- tionen allein durch Tabelleneinträge zu ermöglichen, und so die Erstellung einer solchen graphischen Benutzerschnittstel- le im wesentlichen automatisierbar und gleichzeitig erheblich vereinfacht und beschleunigt zu gestalten.

Erfindungsgemäß wird diese Aufgabe dadurch gelöst, daß ein Verfahren zur Erzeugung graphischer Benutzerschnittstellen für Computerprogramme angegeben wird, bei dem die graphischen Benutzerschnittstellen vollständig aufgrund von in einer Da- tenbank abgelegten Regeln erzeugt werden und jeder Programm- zustand der graphischen Benutzerschnittstelle durch eine Men-

ge von Listen, die die Anzeige-Elemente und deren Inhalt re- präsentieren, eine hierarchische Ordnung, die den Einträgen in einer Liste aus der Menge von Listen andere Listen aus der Menge von Listen zuordnet und so das"Enthaltensein"von An- zeige-Elementen ineinander repräsentiert, und eine Beziehung zwischen den Einträgen in den Listen der Menge von Listen, die festlegt, welches Anzeigeelement von dem Inhalt welches anderen, übergeordneten Anzeige-Elementes abhängt, festgelegt ist.

Vorteilhafte Weiterbildungen der Erfindung sind in den Un- teransprüchen beschrieben.

Die vorliegende Erfindung wird anhand des im folgenden be- schriebenen Ausführungsbeispiels, welches auch in der Zeich- nung dargestellt ist, näher erläutert. Es zeigt : Figur l beispielhaft eine mit dem erfindungsgemäßen Verfahren erzeugte Programmoberfläche (Darstellung auf dem Bildschirm) ; Figur 2 ein erfindungsgemäßes Datenmodell für die Daten der beispielhaften Programmoberfläche ; Figur 3 ein erfindungsgemäßes Datenmodell für die Regeln der beispielhaften Programmoberfläche ; und Figur 4 die erfindungsgemäßen Programmzustände der beispiel- haften Programmoberfläche.

Das erfindungsgemäße Verfahren erlaubt die vollständige Gene- rierung grafischer Programmoberflächen aufgrund von in einer Datenbank abgelegten Regeln. Es ist vorzugsweise anwendbar, wenn die zu verarbeitenden Daten in einer Datenbank gespei- chert sind, und die Verarbeitungsfunktionalität der gewünsch-

ten Applikation ebenfalls in der Datenbank abgebildet ist (in einer ORACLE-Datenbank würde das beispielsweise durch Tabel- len, Tabelleninhalte, Constraints, Functions, Stored Procedu- res und Packages erreicht). Das Verfahren ist somit besonders geeignet für die Erstellung klassischer Client-Server-Syste- me.

Grundlage des erfindungsgemäßen Verfahrens ist der Ansatz, die Programmoberfläche mit allen enthaltenen Anzeige- Elementen vollständig anhand von Regeln aus Steuertabellen der Datenbank zu laden. Die Struktur und der Inhalt dieser Tabellen legen fest, wie eine Programmoberfläche auszusehen hat, und welche Eingaben sie verarbeitet. Ein auf die Struk- tur der Steuertabellen abgestimmter, ansonsten aber allge- meingültiger Algorithmus wertet die Regeln aus, erzeugt die gewünschten Anzeige-Elemente auf dem Client, interpretiert die Benutzereingaben und leitet sie zur Ausführung an das Da- tenbanksystem weiter. Nach dieser Methode lassen sich alle gebräuchlichen Anzeige-Elemente eines Programms wie Programm- fenster, Befehlsmenüs, Tabellen, Baumstrukturen und Dialoge generieren und mit Daten füllen.

Die Struktur der Steuertabellen und der Algorithmus, der ihre Inhalte interpretiert, sind insoweit allgemeingültig, als sie nicht auf ein bestimmtes Datenmodell oder eine bestimmte Funktionalität zugeschnitten werden, sondern eine ganze Klas- se von Programmoberflächen auf beliebigen Datenmodellen mit beliebigen Funktionalitäten ermöglichen. Um das gewünschte Programm zu erzeugen, braucht der Anwendungsentwickler nur noch die Verarbeitungsfunktionalität auf dem Server zu pro- grammieren. Für die Erzeugung der Programmoberfläche reicht es aus, Daten in die Steuertabellen einzutragen. Die auf die- se Art erzielbare Komplexität von Programmoberflächen ist nur begrenzt durch die Komplexität des Regelwerks, das der Algo- rithmus interpretiert.

Das erfindungsgemäße Verfahren soll anhand eines durchgängi- gen Beispiels für einen"Explorer"erläutert werden. Der Ex- plorer hat im Beispiel die Bezeichnung"Aufgaben", er enthält als Kontrollelemente eine Baumstruktur und eine Liste, wie in Figur l dargestellt.

Der Explorer soll die Baumstruktur anhand der Mitarbeiter- hierachie aufbauen und immer, wenn in der Baumstruktur ein Knoten aktiviert wird (z. B. durch Anklicken), die Listen- struktur mit den Aufgaben des jeweiligen Mitarbeiters füllen.

Die Inhalte von Baum-und Listenstruktur werden anhand dieser Regeln aus Datentabellen geladen. Für unser Beispiel gehen wir von zwei Tabellen aus : Die Tabelle der Mitarbeiter : ID NAME ID VORGESETZTER 1 Frau Müller 2 Herr Maier 1 3 Frau Schulze 1 4 Herr Krüger 1 5 Frau Schmidt 2 6 Herr Wagner 2 7 Herr Bäcker 6 8 Frau Schröder 2 Jeder Eintrag steht für einen Mitarbeiter, identifiziert durch eine eindeutige Nummer, repräsentiert durch den Namen, in die Hierarchie eingeordnet durch die eindeutige Nummer des Vorgesetzten.

Die Tabelle der Aufgaben : IDBEZEICHNUNG ID MITARBEITER 1 Geschäftsführung 1 2 Leitung Finanzen 2 3 Geschäftsbericht erstellen 2 4 Buchhaltung 5 5 Kontierun 6 Monatsabschluß 6 7 Jahresabschluß 6 8 Umsatzsteuererklärunq 5 9 Personalabrechnunq 8 10 Leitung Anwendungsentwicklung 3 11 Vertrieb 3 12Marketing 3 13Projektierung 4 14Projektplanung 4 15Angebotserstellung 4 167

Jeder Datensatz steht für eine Aufgabe eines Mitarbeiters, identifiziert durch eine eindeutige Nummer, repräsentiert durch eine Bezeichnung, dem Mitarbeiter zugeordnet durch des- sen eindeutige Nummer.

Die in einer Programmoberfläche möglichen Anzeige-Elemente werden erfindungsgemäß durch Regeln bestimmt, die in Tabellen abgelegt werden. So können beispielsweise die in einem Pro- gramm verwendeten Baum-und Listenstrukturen in Tabellen ein- getragen werden.

Tabelle der Baumstrukturen IDBEZEICHNUNG BEMERKUNG 1 Mitarbeiter Baut die Struktur Struktur Mitarbeiter Mitarbeiter Tabelle der Listenstrukturen ID BEZEICHNUNG BEMERKUNG SELECT FROM 1 Aufgaben Baut die Liste der Aufgaben PERSONAL. AUFGABEN auf Ebenso können die für das Programm vorgesehenen"Explorer" durch Einträge in einer weiteren Tabelle repräsentiert wer- den : Tabelle der"Explorer" JIDSEZEICHNUNG ID BAUM ID LISTE SELECT WHERE 1 Aufgaben 1 1 I D_M ITARBEITER=\% ID% \

Durch Struktur und Inhalte der Regel-Tabellen, aber auch durch die Inhalte der"Daten-Tabellen"wird eine Hierarchie der Anzeige-Elemente festgelegt : Jedes Anzeige-Element ordnet sich in die Hierarchie aller Objekte ein, es ist zusammen mit anderen Objekten einem übergeordneten Objekt zugeordnet. So sind die Baum-und Listenstruktur immer demjenigen Objekt un- tergeordnet, das den Explorer als Ganzes repräsentiert. Eben- so nimmt innerhalb einer Baumkontrolle jeder Knoten einen Platz in der Baumhierarchie ein. Nur das Applikationsobjekt hat kein übergeordnetes Objekt ; es ist allen anderen Objekten übergeordnet.

Außer der für die Objekte geltenden Hierarchie wird durch die Regeln festgelegt, welche Eigenschaften ein Objekt hat. So hat im Beispiel jeder Knoten im Baum die Eigenschaften"Na- me","Nummer","Symbol"und"HatNachfolger".

Wenn der so definierte"Explorer"gestartet wird, werden auf der Grundlage der Regeln Objekte erzeugt, die die konkrete Ausprägung des Explorers und aller darin enthaltenen Anzeige- Elemente beschreiben. Die sichtbare Repräsentation ist der mit Daten gefüllte Explorer als Bestandteil der Programmober- fläche, die zugehörigen Objekte werden intern als Einträge in Listen repräsentiert. So entspricht der Explorer im in Figur l abgebildeten Zustand folgenden Listen : Aktive Explorer : ID BEZEICHNUNG ID BAUM ID LISTE SELECT WHERE 1 Aufqaben 1 1 ID MITARBEITER=\%ID%\

Darin enthaltene Baumstruktur : IDBEZEICHNUNG 1 Mitarbeiter Darin enthaltener oberster Knoten : Text ID Symbol HatNachfolger Frau Müller 1 10 1 Dessen Nachfolger : Text ID Symbol HatNachfolger Frau Schulze 3 10 0 HerrKrüger4100 HerrMaier 2 10 1 Nachfolger von Hr. Maier : Text ID Symbol HatNachfolger FrauSchmidt 5 10 0 FrauSchröder 8 10 0 HerrWagner 6 10 1 Die im Explorer sichtbare Listenstruktur : JDBEZEICHNUNG SELECTFROM 1 Aufgaben PERSONAL. AUFGABEN Die in der Listenstruktur enthaltenen Einträge : IDBEZEICHNUNG 2 Leitung Finanzen 3 Geschäftsbericht erstellen Neben den Inhalten der Listen muß der Algorithmus noch die hierarchische Ordnung der Listen untereinander verwalten.

Um die untergeordneten Objekte eines Anzeige-Elements zu er- zeugen und zur Anzeige zu bringen, reicht es aus, die durch die Regeln festgelegten Datenbankinhalte abzufragen, daraus Listen zu bilden und diese durch allgemeingültig programmier- te Algorithmen anzeigen zu lassen. Um z. B. einen Knoten eines Baums aufzuklappen, muß festgelegt sein, wie die Liste der untergeordneten Knoten aus der Datenbank abgefragt werden kann, z. B. durch folgende Tabellen : Knotentypen : ID BEZEICHNUNG ID SELECT FROM SELECT WHERE SELECT NACH-ORDER FOLGER 1 Unsichtbare 2 PERSONAL. ID-VORGESETZTER NAME Wurzel V_MITARBEITER IS NULL 2 Mitarbeiter 2 PERSONAL. ID VORGESETZTER NAME VMITARBEITER = \% ID% \ Knoten-Eigenschaften : ID KNOTENTYP BEZEICHNUNG FELDNAME 2 Text NAME 2 ID ID 2 HatNachfolger HAT NACHFOLGER Symbol 10 Die Tabelle der Knotentypen beschreibt in diesem Beispiel zwei verschiedene Arten von Knoten : Die unsichtbare Wurzel des Baums und den Mitarbeiter-Knoten. Zu den Regeln gehört unter anderem der Name der Tabelle, aus der die Nachfolger im Baum abgefragt werden sollen, die Bedingung, die bei der Ab- frage verwendet werden soll, der Feldname, nach dem die un- tergeordneten Knoten sortiert werden sollen, und der Knoten- typ, den die untergeordneten Knoten haben.

Die Tabelle der Knoten-Eigenschaften legt für jeden Knotentyp fest, welche Eigenschaften alle Objekte dieses Typs haben. Im

Beispiel hat die Wurzel keine Eigenschaften, Mitarbeiterkno- ten haben die Eigenschaften"ID","Text","HatNachfolger", und"Symbol". Zu den Regeln einer solchen Knoten-Eigenschaft gehört unter anderem der Ausdruck, mit dem die Eigenschaft aus der Datenbank abgefragt werden kann. Der Algorithmus setzt all diese Texte zu einer Abfrage zusammen und lädt so alle benötigten Objekte. Um die Wurzel des Baums zu öffnen, wird folgende Abfrage erzeugt (Im Beispiel in SQL-Syntax) : SELECT NAME, ID, HATNACHFOLGER, 10 FROM PERSONAL. VMITARBEITER WHERE IDVORGESETZTER IS NULL wobei VMITARBEITER ein View ist, der ermittelt, ob ein Mit- arbeiter Nachfolger hat, oder nicht. Dieser View ist folgen- dermaßen programmierbar : CREATE VIEW VMITARBEITER AS SELECT M. NAME, M. ID, M. IDVORGESETZTER DECODE (COUNT (U. ID), NULL, 0,1) HATNACHFOLGER FROM MITARBEITER M, MITARBEITER U WHERE M. ID = U. IDVORGESETZTER (+) GROUP BY M. NAME, M. ID, M. IDVORGESETZTER Damit ein beliebiger Mitarbeiterknoten des Baums geöffnet werden kann, müssen bei der Konstruktion der Objekte auch die

Eigenschaften des übergeordneten Objekts ausgewertet werden.

Nach dem erfindungsgemäßen Verfahren werden dazu Platzhalter in den Regeln verwendet, die bei der Interpretation als Ver- weis auf die konkreten Eigenschaften des übergeordneten Ob- jekts gelten. Um also einen Mitarbeiterknoten zu öffnen wird zunächst folgende Abfrage erzeugt : SELECT NAME, ID, HATNACHFOLGER, 10 FROM PERSONAL. VMITARBEITER WHERE IDVORGESETZTER = \% ID\ Anschließend werden alle Platzhalter anhand der Eigenschaften des übergeordneten Objekts ersetzt, also z. B. für den Knoten, der Herrn Maier repräsentiert : SELECT NAME, ID, HATNACHFOLGER, 10 FROM PERSONAL. VMITARBEITER WHERE IDVORGESETZTER = 7 Die dabei entstehende Liste wird nun in der Baumstruktur des Explorers zur Anzeige gebracht. Jeder Knoten bekommt als Be- schriftung den Inhalt der Eigenschaft"Text", also den Namen des Mitarbeiters. Ob vor dem Namen eine Schaltfläche zum Auf- klappen angezeigt wird, oder nicht, hängt vom Inhalt der Ei- genschaft"HatNachfolger"ab. Das für die Anzeige verwendete Symbol wird aus der Eigenschaft"Symbol"ermittelt, im Bei- spiel ist es für alle Knoten gleich.

Das Konzept, Datenbankbefehle aus Regeln zusammenzusetzen, dabei Platzhalter durch Eigenschaften übergeordneter Anzeige- Elemente zu ersetzen, und so neue Anzeige-Elemente zu kon- struieren, ist der zentrale Bestandteil des erfindungsgemäßen Verfahrens. Im Beispiel kann anhand der Steuertabellen für Listenstrukturen und Explorer (siehe oben) und der Tabelle

der Spaltenbeschreibungen die Liste der Aufgaben eines Mitar- beiters erzeugt werden, sobald der Benutzer einen Mitarbei- ter-Knoten anklickt.

Tabelle der Spaltenbeschreibungen : ID LISTE ID BEZEICHNUNG FELDNAME BREITE 1 1 ID ID 150 1 2 Aufgabe BEZEICHNUNG 400 Der für die Liste aus den Regeln generierbare Datenbankbefehl lautet : SELECT ID, BEZEICHNUNG, IDMITARBEITER FROM PERSONAL. AUFGABEN ORDER BY BEZEICHNUNG Der Eintrag in der Explorer-Tabelle ergänzt diesen Befehl um eine Bedingung : SELECT ID, BEZEICHNUNG, IDMITARBEITER FROM PERSONAL. AUFGABEN WHERE IDMITARBEITER = \% ID% \ ORDER BY BEZEICHNUNG Der Platzhalter wird nun ersetzt durch die konkrete Eigen- schaft"ID"des der Listenstruktur übergeordneten Anzeige- Elements (des angeklickten Knotens), so daß nur die Aufgaben dieses Mitarbeiters in die Listenstruktur geladen werden.

Nach dem gleichen Verfahren können auch alle anderen Anzeige- Elemente einer Programmoberfläche zur Laufzeit ermittelt wer- den (Programmrahmen, Befehlsmenüs, Dialogboxen, Dialogfelder, Schaltflächen, Charts...). Dazu reicht es aus, entsprechende Steuertabellen zu definieren, und einen Algorithmus zu er- stellen, der deren Inhalte und die Eigenschaften des überge-

ordneten Objekts so izterpretiert, daß die gewünschten Anzei- ge-Elemente entstehen.

Um aufgrund von Benutzereingaben Aktionen auszuführen zu kön- nen, müssen die Regeln außerdem festlegen, wie Datenbankbe- fehle aufgrund der Eingaben zusammengesetzt werden, um die gewünschte Funktionalität zu bieten. So könnte der Explorer des Beispiels drei Schaltflächen"Neu","Ändern"und"Lö- schen"enthalten, mit denen der Benutzer die Daten der Tabel- le AUFGABEN modifizieren kann. Der Algorithmus müßte, wenn der Benutzer die Bezeichnung einer Aufgabe überschreibt und die Schaltfläche"Ändern"betätigt, aus den weiter oben be- reits aufgestellten Regeln folgenden Datenbankbefehl zusam- mensetzen : UPDATE PERSONAL. AUFGABEN SET BEZEICHNUNG ='\%Text%' WHERE ID =\% ID% \ Vor der Ausführung werden dann die Platzhalter des Befehls ersetzt durch die Eigenschaften des Listeneintrags, auf den sich der Befehl bezieht.

Neben den elementaren Datenmanipulationsbefehlen (INSERT, UPDATE, DELETE) können auch komplexere Funktionen aufgerufen werden, die als Parameter bestehende Objekte oder Eigenschaf- ten von Objekten verarbeiten.

So könnte eine Stored Procedure"BERECHNEKOSTEN"als Parame- ter einen Mitarbeitereintrag aus der Baumstruktur erwarten.

Immer wenn der Benutzer einen Mitarbeiterknoten angeklickt hat und aus dem (ebenfalls anhand von Regeln geladenen) Be- fehlsmenü den dazu vorgesehenen Befehl auswählt, würde der Algorithmus zuerst die Parameter bereitstellen-also den

Verweis auf die Liste, die den Eintrag enthält und die lau- fende Nummer des Knotens innerhalb dieser Liste-und an- schließend den Befehl BERECHNEKOSTEN (refListe, nEintrag), an die Datenbank weiterleiten.

Figur 2 zeigt das Datenmodell der Daten, die der oben be- schriebene"Explorer"verarbeiten soll. Es steht stellvertre- tend für in Unternehmen übliche, jedoch weitaus komplexere relationale Datenbanken, in denen die Geschäftsdaten gespei- chert und verarbeitet werden.

Figur 3 zeigt das Datenmodell der Regelstruktur, wie sie auch in dem beigefügten Anspruch 2 beschrieben ist, wobei hier die in dem oben beschriebenen Beispiel verwendete Regelstruktur dargestellt ist. In der Praxis werden weitaus komplexere Re- gelstrukturen herangezogen, um entsprechend komplexe Pro- grammoberflächen zu unterstützen.

Figur 4 zeigt den Programmzustand der graphischen Benut- zeroberfläche aus Figur 1. Die durchgezogenen Pfeile reprä- sentieren die Hierarchie gemäß Merkmal b des Anspruchs 1, der gestrichelte Pfeil repräsentiert die Beziehung gemäß Merkmal c des Anspruchs 1. Zum besseren Verständnis sind in Figur 4 oberhalb jeder Liste die Datenbankabfragen angegeben, mit de- nen die Listen wie in Anspruch 2 angegeben, unter Anwendung der Platzhalterersetzung aufgebaut werden können.

Die erfinderische Leistung der vorliegenden Erfindung ergibt sich demgemäß aus der Kombination einer Reihe von Techniken, nämlich

-der Speicherung von Regeln in einem relationalen Datenbankmodell -dynamischer Generierung von Datenbankbefehlen -Platzhaltersetzung in Datenbankbefehlen -Verknüpfung von Anzeige-Elementen mit Feldern von Tabellen einer Datenbank -Verwaltung einer Hierarchie von Listen als Reprä- sentation des Programmzustandes Diese Merkmale werden erfindungsgemäß in Verbindung mit einer geeigneten Struktur von Regeln gebracht. Auf diese Art wird die Beschreibung einer graphischen Benutzerschnittstelle und ihrer Beziehung zu den verwalteten Daten und ihren Funktionen allein durch Tabelleneinträge möglich. Die Regeln können so- zusagen als"formale Spezifikation"angesehen werden, die zur Laufzeit durch den allgemein gültigen Algoritmus interpre- tiert wird, der den jeweiligen Programmzustand allein dadurch erzeugt, daß er zusammengesetzte Datenbankabfragen ausführt.

Hervorzuheben ist, daß die Datenbankabfragen erfindungsgemäß sowohl auf Regeldaten als auch auf die zu verarbeitenden Da- ten zugreifen, und diese in geeigneter Form verknüpfen.

Die verwendete Struktur der Regeln und die jeweilige Imple- mentierung des allgemein gültigen Algorithmus legen zusammen die Klasse aller graphischer Benutzeroberflächen fest, die in dem jeweiligen Ausführungsbeispiel durch Regeln spezifiziert werden können. So ist die für das oben beschriebene Beispiel gewählte Struktur von Regeln relativ klein, sie erlaubt al- lerdings die Erstellung beliebiger Explorer, solange diese im linken Teil aus einem Baum, und im rechten Teil aus einer da- von abhängigen Liste bestehen. Komplexere Regelstrukturen er- lauben entsprechend komplexere graphische Benutzerschnitt- stellen. Für eine kommerzielle Nutzung der Erfindung könnte daher beispielsweise eine Regelstruktur erstellt werden, in

der auch Dialogboxen, Comboboxen, Befehlsmenüs usw. spezifi- ziert werden können.

Der Nutzen der Erfindung besteht in der erheblichen Reduzie- rung sowohl des Aufwandes als auch des technischen Know How's, die nach dem heutigen Stand der Technik für die Er- stellung einer graphischen Benutzerschnittstelle notwendig sind. Darüber hinaus legt die Erfindung die Implementierung des allgemein gültigen Algoritmus in Mehrschichtarchitektur nahe (beispielsweise in"Client Server"oder"3 Tier"Archi- tektur). Der jeweilige Programmzustand läßt sich erfindungs- gemäß nämlich zur Laufzeit auf einem Server generieren, und muß anschließend nur noch zum Client transferiert und dort zur Anzeige gebracht werden. Dadurch reduzieren sich vorteil- hafterweise -die auf dem Client benötigte Programmfunktionali- tät auf ein absolutes Minimum (Thin Client), das zudem allgemeingültig und damit von der jeweili- gen graphischen Benutzeroberfläche unabhängig ist, -der notwendige Nachrichtentransport zwischen Cli- ent und Server auf die für die Anzeige in der graphischen Benutzeroberfläche notwendigen Daten.