DE69736748T2

DE69736748T2 - Editierumgebung für objektmodelle und verfahren zu deren anwendung

Info

Publication number: DE69736748T2
Application number: DE69736748T
Authority: DE
Inventors: Craig Mountain View FEDERIGHI; Eric Mountain View NOYAU; Dan San Francisco WILLHITE
Original assignee: Next Software Inc
Current assignee: Next Software Inc
Priority date: 1996-07-17
Filing date: 1997-07-15
Publication date: 2007-08-16
Anticipated expiration: 2017-07-16
Also published as: EP1628230A1; US6604109B1; WO1998002832A1; US20040015480A1; US8429126B2; US5956728A; US20060271586A1; US20110119683A1; US7111013B2; DE69736748D1; EP2341453A2; AU3822297A; US7860831B2; EP0978061B1; EP0978061A1; EP2341453A3; US6085197A

Description

HINTERGRUND DER ERFINDUNG
1. GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft das Gebiet von objektorientierten Anwendungsprogrammierumgebungen und insbesondere Anwendungen, die auf Datenbanken zugreifen.
2. ALLGEMEINER STAND DER TECHNIK
Objektorientierte Programmiersprachen sind nichtverfahrensorientierte Programmiersprachen, in welchen Programmelemente als Objekte betrachtet werden, die einander Nachrichten übermitteln können. Ein Objekt enthält seine eigenen Daten und seinen eigenen Programmiercode und ist intern von außen unabhängig. Der Programmiercode eines Objekts enthält Prozeduren oder Verfahren. Die Verfahren eines Objekts werden durch Nachrichten aufgerufen, die von einem anderen Objekt empfangen werden. Jedes Objekt ist ein Exemplar einer Objektklasse. Die Eigenschaften der Objekte in einer Klasse sind durch eine Klassendefinition definiert. Eine Klassendefinition kann eine hierarchische Klassenstruktur verwenden, in welcher Objekte in der Klasse Eigenschaften einer übergeordneten Klasse zusätzlich zu Eigenschaften erben, die ausdrücklich für die Klasse definiert sind. Diese Vererbungseigenschaft ermöglicht es, einen Code für Objektklassen zur Wiederverwendung in verschiedenen Anwendungen anzupassen, wodurch die gemeinsame Benutzung eines Programmiercodes durch verschiedene Programme ermöglicht wird.
Um ein Anwendungsprogramm in einer objektorientierten Programmiersprache zu schreiben, bestimmt ein Programmierer die Realwelt-Objekte eines Problems, die Daten und Verarbeitungsanforderungen dieser Objekte, sowie die Kommunikationen, die zwischen den Objekten benötigt werden, und verkapselt diese in Klassendefinitionen. Dieser Prozess wird dadurch vereinfacht, dass die Vererbungseigenschaft von Objektklassen genutzt wird, indem die Klassendefinitionen soweit als möglich auf bereits bestehenden Objektklassen aufgebaut werden.
Objekte werden in einer modularen Weise zusammengesetzt, um Anwendungen zu erzeugen. Die Objekte fordern andere Objekte durch Senden von geeigneten Nachrichten dazu auf, Operationen oder Prozeduren durchzuführen. Eine geeignete Nachricht ist eine Nachricht, auf welche das empfangende Objekt antworten kann. Das sendende Objekt muss daher die Art von Funktionen kennen, die ein empfangendes Objekt ausführen kann, und zum Erzeugen der entsprechenden Nachricht imstande sein, welche die gewünschte Operation aufruft. Das sendende Objekt muss auch bereit sein, jegliche resultierende Antwort anzunehmen und zu verarbeiten.
Obwohl Objekte im Allgemeinen intern von außen unabhängig sind und daher als Module betrachtet werden können, die mit anderen Objekten zu einer Vielzahl von Anwendungsprogrammen zusammengesetzt werden können, erzeugt das einfache Zusammensetzen von Objekten noch kein funktionales Programm. Die Objekte müssen auch imstande sein, richtig miteinander zu interagieren und zu kommunizieren. Obwohl Objekte einen wieder verwendbaren Code darstellen, muss ein zusätzlicher Code geschrieben werden, um für die Erzeugung von geeigneten abgehenden Nachrichten und für die Verarbeitung und Beantwortung von ankommenden Nachrichten zu sorgen.
Eine Art von Anwendungsprogramm, das im Geschäftsleben verwendet wird, ist ein Datenbankanwendungsprogramm. Ein Datenbankanwendungsprogramm ist ein Programm, das Daten bearbeitet, die in einer Datenbank gespeichert sind. Die Datenbank wird oft durch ein getrenntes Programm verwaltet, genannt Datenbankverwaltungsprogramm, welches die Fähigkeit besitzt, auf Anforderungen zum Speichern, Abrufen, Suchen, Extrahieren und Aktualisieren von Daten in der Datenbank zu antworten. Um auf Daten in der Datenbank zuzugreifen, muss das Datenbankanwendungsprogramm geeignete Datenbankanforderungen an das Datenbankverwaltungsprogramm erzeugen.
Es gibt viele Arten von Datenbankstrukturen und viele Aren von Datenbankverwaltungsprogrammen. Um auf eine bestimmte Datenbank zugreifen zu können, muss ein Datenbankanwendungsprogramm die Struktur der Datenbank und die Syntax, die durch das Datenbankverwaltungsprogramm verwendet wird, kennen. Da diese von einer Datenbank zur anderen variieren können, kann im Allgemeinen nicht ein einziges Datenbankanwendungsprogramm bei verschiedenen Datenbanken verwendet werden. Stattdessen werden getrennte Versionen eines Datenbankanwendungsprogramms benötigt, um mit verschiedenen Datenbanken und verschiedenen Datenbankverwaltungsprogrammen umzugehen.
Zwei Arten von Datenbankstrukturen sind Einfachdatei-Datenbanken und relationale Datenbanken.
Eine Einfachdatei-Datenbank kann als eine einzige große Tabelle mit einer Anzahl von Reihen und einer Anzahl von Spalten betrachtet werden. Jede Reihe („Datensatz") entspricht einer bestimmten Entität, und jede Spalte dieser Reihe („Feld") entspricht einem bestimmten Attribut dieser Entität. Zum Beispiel kann eine Angestelltendatenbank Informationen über Angestellte enthalten, welche Namen, Adresse, Sozialversicherungsnummer, Gehalt, Abteilung usw. umfassen. Jede Reihe entspricht einem bestimmten Angestellten. Getrennte Spalten entsprechen jeweils Namen, Adresse, Sozialversicherungsnummer, Gehalt, Abteilung usw. Eine der Spalten enthält einen Eintrag, der jede Reihe eindeutig identifiziert. Dieser Eintrag wird oft „Primärschlüssel" genannt. Für das Beispiel der Angestelltendaten bank kann der Primärschlüssel der Name, die Sozialversicherungsnummer oder eine Indexnummer, die durch das Datenbankverwaltungsprogramm erzeugt wird, sein. Um zum Beispiel das Gehalt für Jane Doe in der Angestelltendatenbank zu ermitteln, würde man in der Reihe nachsehen, die Jane Doe entspricht, und das Gehalt in der Gehaltsspalte ablesen. In einer Einfachdatei sind die einzigen Daten, die über eine Entität verfügbar sind, die Informationen, die in der Reihe enthalten sind, die der Entität entspricht, das heißt nur die Informationen, für welche eine Spalte oder ein „Feld" in der Tabelle vorhanden ist.
In einer relationalen Datenbank können Informationen in einer Tabelle mit Informationen in anderen Tabellen in Beziehung gesetzt werden. Zum Beispiel kann eine Firmendatenbank eine Tabelle für die Namen und Adressen von Angestellten umfassen, die eine Reihe für jeden Angestellten mit Feldern für den Namen und die Adresse jedes Angestellten in jeder Reihe enthält. Die Datenbank kann auch eine Abteilungstabelle enthalten, die Reihen für jede Abteilung enthält, wobei jede Reihe ein Abteilungskennungs- oder -ID-Feld, sowie Felder für die Namen aller Angestellten in der Abteilung enthält. Die Abteilungstabelle kann mit der Tabelle für die Namen und Adressen der Angestellten durch Aufnehmen eines Feldes für die Abteilungs-ID in die Tabelle für die Namen und Adressen der Angestellten verknüpft werden. Diese Abteilungs-ID, genannt „Fremdschlüssel", kann als ein Zeiger von der Tabelle für die Namen und Adressen der Angestellten zur Abteilungstabelle betrachtet werden, der anzeigt, wo zusätzliche verbundene Daten gefunden werden können.
Ein Beispiel für ein Datenbankanwendungsprogramm, das die im vorstehenden Absatz beschriebene relationale Datenbank verwenden könnte, ist eine Anwendung, welche die Namen und Adressen aller Angestellten einer bestimmten Abteilung zusammenstellt. Diese Anwendung könnte folgender maßen funktionieren. Zunächst fordert das Anwendungsprogramm das Datenbankverwaltungsprogramm auf, die Namen aller Angestellten in der betreffenden Abteilung aus der Abteilungsdatenbank zu extrahieren. Dazu muss das Anwendungsprogramm die Struktur der Abteilungstabelle kennen, und es muss die Aufforderung in der spezifischen Syntax des Datenbankverwaltungsprogramms vornehmen. Dann fordert das Anwendungsprogramm für jeden erhaltenen Angestelltennamen die entsprechende Adresse aus der Tabelle für die Namen und Adressen der Angestellten an. Wiederum muss das Anwendungsprogramm die Struktur der Namen- und Adressentabelle kennen, und es muss die Anforderung oder in diesem Fall die Reihe von Anforderungen, eine für jeden Angestelltennamen, in der korrekten Syntax formulieren. Das Anwendungsprogramm muss dann die empfangenen Daten zu einer kohärenten Form zusammensetzen und sie dem Benutzer anzeigen. Selbst für diese einfache Funktion ist das Anwendungsprogramm kompliziert: das Programm muss über die Struktur der Tabellen in der Datenbank Bescheid wissen, es muss eine Vielzahl von Datenbankanforderungen in der jeweiligen Syntax des Datenbankverwaltungsprogramms erzeugen können, es muss die empfangenen Daten verarbeiten können, und es muss die Daten zusammensetzen und sie auf einer Benutzerschnittstelle anzeigen können.
Das Schreiben eines Datenbankanwendungsprogramms kann durch Verwenden von objektorientierten Programmiertechniken vereinfacht werden. Es können Objekte konstruiert werden, die Eingabe- und Ausgabefunktionen, wie beispielsweise das Anfordern von Daten von einem Datenbankverwaltungsprogramm oder das Anzeigen von Daten auf einer Benutzerschnittstelle, ausführen. Ein Anwendungsprogramm braucht daher nicht mit einem Code zum Bearbeiten dieser untergeordneten Funktionen versehen sein. Das Anwendungsprogramm kann die Erledigung dieser und anderer Anforderungen geeigneten Objekten überlassen. Das Schreiben des Anwendungsprogramms wird vereinfacht.
Objektorientierte Programmierumgebungen versehen Programmierer mit Werkzeugen, wie beispielsweise vordefinierten Objektklassen, welche die Erstellung von Anwendungen vereinfachen können.
Ein Satz von Werkzeugen und Betriebsmitteln des Standes der Technik für eine objektorientierte Programmierumgebung, die verwendet werden können, um Datenbankanwendungen zu erstellen, ist Enterprise Objects Framework 1x (TM), ein Satz von Werkzeugen und Betriebsmitteln für die objektorientierte Programmierumgebung NEXTSTEP (TM) von der NeXT Computer, Inc.
Siehe zum Beispiel „Enterprise Objects Framework: A second generation object relational enabler", von C. KLEISSNER, veröffentlich in SIGMOD RECORD, Juni 1995, Bd. 24, Nr. 2, Seite 455–459.
Die Architektur und der Datenfluss einer Enterprise Objects Framework 1x-Anwendung ist in 1 dargestellt. Bei der Anwendung, die in 1 dargstellt ist, fließen Daten von einer relationalen Datenbank 100 über eine Anzahl von beteiligten Modulen und Stufen zu einer Benutzerschnittstelle 160 und umgekehrt. Jeder der Blöcke, die in 1 dargestellt sind, bildet einen Abschnitt des gesamten Anwendungsprogramms und kann aus einem oder mehr Objekten bestehen.
Der Fluss von Daten von der relationalen Datenbank 100 zur Benutzerschnittstelle 160 geht folgendermaßen vor sich. Daten in der Form von Reihen von Daten von der relationalen Datenbank 100 werden unter Verwendung von allgemein bekannten Techniken zum Zugriff auf relationale Datenbanken aus der relationalen Datenbank 100 auf eine Adaptorstufe 110 abgerufen. Auf der Adaptorstufe 110 werden die Ursprungsdaten, die von der relationalen Datenbank 100 empfangen werden, in „Wörterbuchobjekte" verpackt. Wörter buchobjekte enthalten Schlüsselwertpaare: jeder Schlüssel stellt normalerweise den Namen einer Datenbankspalte dar, und der Schlüsselwert entspricht den Daten für die Spalte der jeweiligen Reihe, die aus dem relationalen Datenbank 100 ausgelesen wurde. Wie in 1 dargestellt, werden Daten in der Form dieser Wörterbuchobjekte von der Adaptorstufe 110 an die Datenbankstufe 120 übermittelt.
Die Datenbankstufe 120 erzeugt „Firmenobjekte" aus den Wörterbuchobjekten. Firmenobjekte sind wie andere Objekte, die in objektorientierten Programmiersprachen verwendet werden, indem sie Daten mit Verfahren zum Bearbeiten dieser Daten koppeln. Unter dem Enterprise Objects Framework 1x weist ein Firmenobjekt jedoch bestimmte Charakteristiken auf, die es von anderen Objektklassen unterscheiden. Ein Firmenobjekt besitzt Eigenschaften, welche auf gespeicherte Daten abbilden, und ein Exemplar eines Firmenobjekts entspricht normalerweise einer einzigen Reihe oder einem einzigen Datensatz in einer Datenbank. Ferner weiß ein Firmenobjekt, wie es mit anderen Teilen des Enterprise Object Framework zu interagieren hat, um Werte für seine Eigenschaften zu erteilen und zu empfangen. Die Bestandteile, die ein Firmenobjekt ausmachen, sind seine Klassendefinition und die Datenwerte für die Reihe oder den Datensatz, denen es entspricht. Das Firmenobjekt enthält auch Zeiger auf andere Firmenobjekte, die von Reihen von verbundenen Datenbanktabellen erzeugt werden. Diese anderen Firmenobjekte enthalten normalerweise noch andere Zeiger auf andere verbundene Objekte. Der gesamte Satz von Firmenobjekten, der durch ein Anwendungsprogramm verwendet wird, bildet demnach einen Verbindungsgraphen von datentragenden Firmenobjekten. Dieser Graph stellt eine bestimmte Ansicht der zugrunde liegenden Datenbank dar.
Die Firmenobjekte, die auf der Datenbankstufe 120 erzeugt werden, werden von der Datenbankstufe 120 an die Datenquelle 130 übermittelt. Die Datenquelle 130 ist ein Objekt, das die Fähigkeit besitzt, Firmenobjekte abzurufen, einzufügen, zu aktualisieren und zu löschen. Entsprechend ist sie sowohl eine Quelle als auch eine Senke für Firmenobjekte. Änderungen, die durch die Datenquelle 130 an einem Firmenobjekt vorgenommen werden, werden über die Datenbankstufe 120 und die Adaptorstufe 110 hinunter an die relationale Datenbank 100 übermittelt, damit eine entsprechende Änderung an der Datenbank für eine an einem Firmenobjekt erfolgte Änderung vorgenommen wird. Die Datenquelle 130 kennt die Struktur der zugrunde liegenden Datenbank nicht. Um diese Details kümmert sich die Adaptorstufe 110. Demgemäß kann, solange die geeignete Adaptorstufe 110 verwendet wird, dieselbe Datenquelle 130 für eine Vielzahl von verschiedenen Datenbanken verwendet werden.
Die Datenquelle 130 liefert Firmenobjekte, die auf der Datenbankstufe 120 erzeugt wurden, an die Steuereinheit 140. Wie in 1 dargestellt, befördert die Steuereinheit 140 Daten in der Form von Werten von den Firmenobjekten über Assoziationsobjekte 150 zur Benutzerschnittstelle 160. Die Steuereinheit 150 koordiniert die Werte, die auf der Benutzerschnittstelle angezeigt werden, mit den entsprechenden Firmenobjektwerten. Wenn Firmenobjektwerte auf der Benutzerschnittstelle modifiziert werden, benachrichtigt die Steuereinheit 140 die Datenquelle 130, welche für die Übertragung von Änderungen an die relationale Datenbank 100 verantwortlich ist.
Im Enterprise Object Framework 1x müssen Änderungen an Firmenobjekten durch Editieren von Werten auf der Benutzerschnittstelle oder durch Verwenden des Steuerverfahrens „set-Values: for Object:" (Werte setzen: für Objekt) erfolgen. Da Firmenobjekte normalerweise die Prozesslogik enthalten, die für die Anwendung benötigt wird, wäre es nützlich, wenn Firmenobjekte durch ein Anwendungsprogramm auf dieselbe Weise bearbeitet werden könnten, wie die meisten Objekte bearbeitet werden, d.h. durch Senden einer geeigneten Nachricht an ein Firmenobjekt. Da jedoch die Integrität der zugrunde liegenden Datenbank aufrechterhalten werden muss, müssen bestimmte Prozeduren, die an Firmenobjekten durchgeführt werden, wie beispielsweise Prozeduren, die Änderungen an den Daten im Firmenobjekt vornehmen, speziell gehandhabt werden. Zum Beispiel umgehen Änderungen, die durch Senden einer Nachricht an ein Firmenobjekt im Enterprise Object Framework 1x direkt vorgenommen werden, die Steuereinheit 140. Demgemäß werden, da die Steuereinheit 140 Nachrichten an die Benutzerschnittstelle 160 und die Datenbankstufe 120 steuert, diese Änderungen auf der Benutzerschnittstelle nicht aktualisiert und in der Datenbank nicht gespeichert. Um diese Änderungen an die Benutzerschnittstelle und die Datenbankstufe zu übertragen, muss das Firmenobjekt selbst Änderungen verfolgen und die Steuereinheit 140 ausdrücklich benachrichtigen, wenn eine Änderung stattfindet. Diese Aufgabe erfordert einen zusätzlichen Code in jedem Firmenobjekt, wodurch die Erstellung von Firmenobjekten und Anwendungen, welche Firmenobjekte verwenden, komplizierter und zeitaufwändiger als andere Arten von objektorientiertem Programmieren gemacht wird.
Eine weitere Beschränkung des Enterprise Object Framework 1x ist, dass, da die Steuereinheit 140 fest mit der Benutzerschnittstelle 160 gekoppelt ist, die Steuereinheit 140 nicht für Datenbankserver- und andere Nicht-Benutzerschnittstellenanwendungen verwendbar ist. Demgemäß sind Puffer- und Undo-Funktionen, die im Enterprise Object Framework 1x in der Steuereinheit 140 implementiert sind, nicht verfügbar für Anwendungen, die für Serverplattformen geschrieben werden.
KURZDARSTELLUNG DER ERFINDUNG
Die vorliegende Erfindung umfasst ein neuartiges System zum Verwalten von Änderungen an einem Graphen von datentragenden Objekten. In einer Ausführungsform wird ein Objektgraph-Manager, der als Editierkontext bezeichnet wird, verwendet, um Änderungen zu bestimmen, die an datentragenden Firmenobjekten vorgenommen werden, und andere interessierte Objekte zu benachrichtigen, wenn Änderungen stattfinden. Als Ergebnis brauchen datentragende Objekte selbst keinen Code enthalten, der zum Überwachen von Änderungen notwendig ist. In dieser Ausführungsform überträgt ein datentragendes Objekt eine „willChange"- oder „werdeGeändert"-Nachricht an eine Liste von Beobachterobjekten, von welchen eines der Editierkontext ist, bevor es irgendeiner Änderung unterzogen wird. Nach Empfang der „willChange"-Nachricht nimmt der Editierkontext eine Momentaufnahme des Objekts vor der Änderung auf. Sobald die Änderung erfolgt und die Änderung an die Datenbank zu übergeben ist, nimmt der Editierkontext eine zweite Momentaufnahme des Objekts auf. Der Editierkontext verwendet eine Momentaufnahmenunterscheidung, um die Änderung zu bestimmen, die stattgefunden hat, und speichert die Änderung dann in der Datenbank. Der Editierkontext registriert auch andere Objekte, zum Beispiel Benutzerschnittstellenobjekte, die benachrichtigt werden müssen, wenn sich das Objekt geändert hat, und benachrichtigt diese registrierten Objekte, wenn eine Änderung stattfindet.
In einer anderen Ausführungsform der Erfindung werden die Momentaufnahmen, die durch den Editierkontext gespeichert werden, verwendet, um ereignisbasierte „Undo"- oder Rückgängigmachungsfähigkeiten bereitzustellen. In dieser Ausführungsform beginnt ein Änderungsereignis, und ein datentragendes Objekt, das im Begriff ist, geändert zu werden, überträgt eine „willChange"-Nachricht. Der Editierkontext empfängt die „willChange"-Nachricht und nimmt eine Momentaufnahme auf. Der Editierkontext ignoriert nachfolgende „willChange"-Nachrichten von dem Objekt, bis das Änderungsereignis abgeschlossen ist. An diesem Punkt speichert der Editierkontext die Momentaufnahme auf einem Undo-Stack (Rückgängigmachungsstapelspeicher). Auf diese Weise werden Undos (Rückgängigmachungen) durch eine „willChange"-Nachricht und das Ende eines Änderungsereignisses eingeklammert. Zwischenänderungen werden nicht gespeichert.
In einer anderen Ausführungsform der Erfindung werden mehrere Stufen von Editierkontexten verwendet, um mehrere isolierte Objektgraphen bereitzustellen, welche jeweils eine unabhängige Handhabung der zugrunde liegenden datentragenden Objekte ermöglichen. In dieser Ausführungsform liefert ein zugrunde liegender Editierkontext Objekte aus seinem Objektspeicher an einen oder mehrere darüber liegende Editierkontexten. Jeder der darüber liegenden Editierkontexte erzeugt und verwaltet seinen eigenen Objektspeicher, der Kopien der Objekte im zugrunde liegenden Editierkontext enthält. Änderungen an Objekten in einem darüber liegenden Objektgraphen können ohne Beeinflussen des Zustands derselben Objekte im zugrunde liegenden Objektgraphen oder in den anderen Objektgraphen vorgenommen werden. Wenn eine Änderung endgültig ist, kann die Änderung hinunter an den zugrunde liegenden Editierkontext übermittelt werden und hinauf an die darüber liegenden Objektgraphen übermittelt werden.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Stufenblockdiagramm, das eine Datenbankanwendung des Standes der Technik veranschaulicht.
2 ist ein Stufenblockdiagramm, das eine Ausführungsform einer Datenbankanwendung der vorliegenden Erfindung veranschaulicht.
3 ein Blockdiagramm, das zeigt, wie der Editierkontext einer Ausführungsform der vorliegenden Erfindung die Funktionen der Änderungsverfolgung und Änderungsbekanntgabe ausführt.
4 ist ein Blockdiagramm, das zeigt, wie die Benutzerschnittstelle in Erwiderung einer Aktualisierungsnachricht vom Editierkontext in einer Ausführungsform der vorliegenden Erfindung aktualisiert wird.
5 ist ein Blockdiagramm, das zeigt, wie ein Beispiel des Editierkontextes der vorliegenden Erfindung die Funktion der Objekteindeutigmachung ausführt.
6 ist ein Blockdiagramm, das zeigt, wie eine Ausführungsform des Editierkontextes der vorliegenden Erfindung die Funktion des Speicherns von Änderungen an Firmenobjekten ausführt.
7 ist ein Blockdiagramm, das zeigt, wie eine Ausführungsform des Editierkontextes der vorliegenden Erfindung eine Undo-Funktionalität bereitstellt.
8 ist eine schematische Darstellung, welche die Struktur einer Ausführungsform der vorliegenden Erfindung darstellt.
9 ist eine schematische Darstellung, welche die Struktur einer Ausführungsform des Objektspeichers der vorliegenden Erfindung darstellt, der mehrere Adaptorstufen und mehrere Datenbanken umfasst.
10 ist eine schematische Darstellung, welche die Struktur einer Ausführungsform des Objektspeichers der vorliegenden Erfindung darstellt, der mehrere netzverknüpfte Datenbanken umfasst.
11 ist eine schematische Darstellung, welche die Struktur einer Ausführungsform der vorliegenden Erfindung darstellt, die mehrere verschachtelte Editierkontexte umfasst.
12 ist eine schematische Darstellung einer Ausführungsform eines Computersystems, auf welchem die vorliegende Erfindung implementiert werden kann.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt, um ein völliges Verständnis der vorliegenden Erfindung zu ermöglichen. Für Fachleute ist jedoch zu erkennen, dass die vorliegende Erfindung ohne diese spezifischen Einzelheiten realisiert werden kann. In anderen Fällen wurden allgemein bekannte Merkmale nicht im Einzelnen beschrieben, um die vorliegende Erfindung nicht unnötig zu verkomplizieren.
Die allgemeine Struktur einer Ausführungsform eines Datenbankanwendungsprogramms, das die vorliegende Erfindung verwendet, ist in 2 dargestellt. Diese Ausführungsform wird im Datenbankanwendungsprogrammierpaket Enterprise Objects Framework 2.0 von der NeXT Software Inc., der Rechtsnachfolgerin der vorliegenden Erfindung, verwendet.
Wie in der Anwendung des Standes der Technik, die in 1 dargestellt ist, fließen in der Anwendung, die in 2 dargestellt ist, Daten von einer relationalen Datenbank 200 über eine Anzahl von beteiligten Modulen und Stufen zu einer Benutzerschnittstelle 260 und umgekehrt. Jeder der Blöcke, die in 2 dargestellt sind, bildet einen Abschnitt des gesamten Anwendungsprogramms und kann aus einem oder mehr Objekten bestehen. Obwohl bestimmte der in 2 dargestellten Module jenen ähneln, die in 1 dargestellt sind, gibt es gewisse signifikante Unterschiede, wie im Folgenden kurz dargestellt.
Die Module, die in 2 dargestellt sind, sind eine Datenbank 200, eine Adaptorstufe 210, eine Datenbankstufe 220, ein Editierkontext 225, eine Datenquelle 230, eine Anzeigegruppe 240, Assoziationen 250 und eine Benutzerschnittstelle 260. Wie in 2 dargestellt, sind diese Module in drei Schichten unterteilt. Die Datenbank 200, die Adaptorstufe 210 und die Datenbankstufe 220 bilden eine Zugriffsschicht 270. Der Editierkontext 225, die Datenquelle 230 und die Anzeigegruppe 240 bilden eine Steuerschicht 280. Die Assoziationen 250 und die Benutzerschnittstelle 260 bilden eine Schnittstellenschicht 290.
Der Fluss von Daten von der relationalen Datenbank 200 zur Benutzerschnittstelle 260 geht folgendermaßen vor sich. Daten in der Form von Reihen von Daten von der relationalen Datenbank 200 werden unter Verwendung von allgemein bekannten Techniken zum Zugriff auf relationale Datenbanken aus der relationalen Datenbank 200 auf eine Adaptorstufe 210 abgerufen. Die Adaptorstufe 210 besteht aus einem Adaptor, der Datenbankanforderungen, die von der Datenbankstufe 220 empfangen werden, in die korrekte Syntax und das korrekte Format für die jeweilige Datenbank 200, auf die zugegriffen wird, übersetzt. Wenn die Datenbank 200 zum Beispiel eine Oracle-Datenbank ist, wird eine Oracle-Adaptorstufe 210 verwendet. Wenn die Datenbank 200 eine Sybase-Datenbank ist, wird eine Sybase-Adaptorstufe 210 verwendet. Auf diese Weise ist jedes Modul über der Adaptorstufe 210 datenbankunabhängig.
Auf der Adaptorstufe 210 werden die Ursprungsdaten, die von der relationalen Datenbank 200 empfangen werden, in „Wörterbuchobjekte" verpackt. Wörterbuchobjekte enthalten Schlüsselwertpaare: jeder Schlüssel stellt normalerweise den Namen einer Datenbankspalte dar, und der Schlüsselwert entspricht den Daten für die Spalte der jeweiligen Reihe, die aus dem relationalen Datenbank 100 ausgelesen wurde. Wie in 2 dargestellt, werden Daten in der Form dieser Wörterbuchobjekte von der Adaptorstufe 110 an die Datenbankstufe 120 übermittelt.
Die Datenbankstufe 220 erzeugt „Firmenobjekte" aus den Wörterbuchobjekten. Im Gegensatz zur Ausführungsform von 1 brauchen die Firmenobjekte der vorliegenden Erfindung weder besondere Kenntnisse über die zugrunde liegende Datenbank zu haben noch Verfahren zum Überwachen von Änderungen umfassen, mit der Ausnahme, dass sie zum Senden von „willChange"-Nachrichten imstande sein müssen, wie im Folgenden beschrieben. Außerdem ist im Gegensatz zur Ausführungsform von 1, in welcher die Firmenobjekte, die auf der Datenbankstufe 120 erzeugt wurden, direkt an die Datenquelle 130 übermittelt wurden, in der Ausführungsform von 2 ein zusätzliches Modul, der Editierkontext 225, zwischen der Datenbankstufe 220 und der Datenquelle 230 vorhanden. Wie im Folgenden ausführlich erörtert wird, stellt der Editierkontext 225 viele der erfinderischen Merkmale der vorliegenden Erfindung bereit. Firmenobjekte, die auf der Datenbankstufe 220 erzeugt werden, werden von der Datenbankstufe 220 an den Editierkontext 225 übermittelt.
Der Editierkontext 225 fungiert als Manager des Objektgraphen, der durch die Anwendung von 2 von der Datenbank 200 erzeugt wurde. Wichtige Funktionen, die durch den Editierkontext ausgeführt werden, umfassen Objekteindeutigmachung, Benutzerschnittstellenbenachrichtigung, Änderungsbekanntgabe, Änderungsverfolgung und die Bereitstellung von Undo-Funktionen.
Nach Empfang eines Firmenobjekts von der Datenbankstufe 220 registriert der Editierkontext 225 jedes Firmenobjekt in einer Nachschlagetabelle unter Verwendung seines Primärschlüssels oder einer anderen eindeutigen Kennung, um das Objekt als Teil seiner Eindeutigmachungsfunktion für die externe Datenbank 200 eindeutig zu bestimmen, um sicherzustellen, dass für jede Datenbankreihe nur ein Firmenobjekt im Objektgraphen erzeugt wird, der durch den Editierkontext 225 verwaltet wird.
Firmenobjekte im Enterprise Objects Framework 2.0 besitzen die Fähigkeit, jedes andere Objekt als einen Beobachter zu registrieren. Ein Beobachter ist ein Objekt, das an allen Änderungen interessiert ist, die an den Objekten vorgenommen werden, bei welchen er als ein Beobachter registriert ist. Der Editierkontext 225 registriert sich selbst als einen Beobachter jedes Firmenobjekts, das zu seinem Objektgraphen gehört.
Die Datenquelle 230 ist ein Objekt, das als eine Schnittstelle zwischen der Anzeigegruppe 240 und dem Editierkontext 225 fungiert. Sie gibt Anforderungen zur Einfügung oder Löschung von Objekten von der Anzeigegruppe 240 an den Editierkontext 225 weiter. Änderungen, die durch den Editierkontext 225 an einem Firmenobjekt vorgenommen werden, werden über die Datenbankstufe 220 und die Adaptorstufe 210 hinunter zur relationalen Datenbank 200 übermittelt.
Die Anzeigegruppe 240 fungiert als die Schnittstelle zwischen der Schnittstellenschicht 290 und der Steuerschicht 280. Sie ist ein Mechanismus, durch welchen die Schnittstellenschicht 290 auf gespeicherte Daten zugreift. Der Editierkontext 225 liefert Firmenobjekte, die auf der Datenbankstufe 220 erzeugt werden, über die Datenquelle 230 an die Anzeigegruppe 240. Wie in 2 dargestellt, befördert die Anzeigegruppe 240 Daten in der Form von Werten von den Firmenobjekten über die Assoziationsobjekte 250 zur Benutzerschnittstelle 260. Die Anzeigegruppe 240 koordiniert die Werte, die auf der Benutzerschnittstelle 260 angezeigt werden, mit den entsprechenden Firmenobjektwerten. Wenn Firmenobjekte auf der Benutzerschnittstelle 260 modifiziert werden, verfolgt der Editierkontext 225 die Änderungen und überträgt Änderungen, soweit angemessen, an die relationale Datenbank 200.
3 ist ein Blockdiagramm das zeigt, wie der Editierkontext einer Ausführungsform der vorliegenden Erfindung die Funktion der Änderungsverfolgung und Änderungsbekanntgabe ausführt. Wie in 3 dargestellt, registriert sich der Editierkontext 225 bei Block 320 selbst als einen Beobachter aller Firmenobjekte in seinem Objektgraphen. Dies gewährleistet, dass jedes Firmenobjekt, das im Begriff ist, einer Änderung unterzogen zu werden, zuerst eine „willChange"-Nachricht an den Editierkontext sendet. In der Ausführungsform, die in 3 dargestellt ist, empfängt der Editierkontext bei Block 330 solch eine „willChange"-Nachricht von einem Firmenobjekt, das im Begriff ist, einem Änderungsereignis unterzogen zu werden.
Nach Empfang der „willChange"-Nachricht nimmt der Editierkontext bei Block 340 eine Momentaufnahme des Objekts auf, das die Nachricht sendete. Bei Block 350 wartet der Editierkontext auf eine Ereignisende-Nachricht, die das Ende des Ereignisses anzeigt, das die Ausgabe der „willChange"-Nachricht verursachte.
Das Erzeugen von „willChange"- und Ereignisende-Nachrichten kann zum Beispiel folgendermaßen vor sich gehen. Das Betriebsystem des Computersystems, welches die Ausführungsform von 3 verwendet, empfängt eine Bekanntgabe eines Ereignisses. Ereignisse können in Abhängigkeit vom Betriebssystem eine Vielzahl von Formen aufweisen. Beispiele für Ereignisse sind Benutzerereignisse, wie beispielsweise das Bewegen einer Maus, das Anklicken einer Maustaste oder das Drücken einer Taste, sowie Netzer eignisse, wie beispielsweise Fernprozeduraufrufe oder andere Netznachrichten.
Nach Empfang der Bekanntgabe eines Ereignisses sendet der Ereignismanager des Betriebssystems seinerseits eine Bekanntgabe des Ereignisses an den Anwendungscode. Der Anwendungscode läuft dann in Erwiderung des Ereignisses ab, soweit angemessen. Wenn als Teil der Ausführung des Anwendungscodes eine Änderung an einem Firmenobjekt vorgenommen wird, überträgt das Firmenobjekt eine „willChange"-Nachricht an seine Beobachterobjekte, welche den Editierkontext umfassen. Nach Empfang der „willChange"-Nachricht sendet der Editierkontext dem Ereignismanager des Betriebssystems eine Nachricht mit der Aufforderung, dass der Editierkontext durch das Betriebssystem zurückgerufen werden soll, sobald die Ausführung des Anwendungscodes, der durch das Ereignis ausgelöst wurde, abgeschlossen ist. Der Anwendungscode läuft vollständig ab, und das Betriebssystem sendet dem Editierkontext eine Nachricht, die das Ende des Ereignisses anzeigt.
Sobald der Editierkontext bei Block 360 eine Ereignisende-Nachricht empfängt, überträgt der Editierkontext bei Block 370 eine Änderungsnachricht an jene anderen Objekte, die sich selbst beim Editierkontext als Beobachter des geänderten Objekts registriert haben. In bestimmten Situationen, zum Beispiel wenn gewünscht wird, eine referentielle Integrität zu bewahren, wie beispielsweise durch Übertragen von Löschungen, kann der Editierkontext an diesem Punkt auch eine zweite Momentaufnahme des Objekts nach der Änderung aufnehmen.
Um sicherzustellen, dass die Benutzerschnittstelle als Erwiderung von Änderungen, die an einem Firmenobjekt vorgenommen werden, richtig aktualisiert wird, kann die Anzeigegruppe 240 sich selbst beim Editierkontext als einen Beobachter registrieren. Die Anzeigegruppe 240 wird daher benachrichtigt, wenn irgendwelche Firmenobjekte geändert werden, deren Werte auf der Benutzerschnittstelle angezeigt werden. Die Anzeigegruppe 240 kann dann alle der Werte in der Anzeige aktualisieren. Der Zweck des Aktualisierens aller angezeigten Werte ist es, sicherzustellen, dass alle Werte, die auf der Benutzerschnittstelle angezeigt werden, die an dem Firmenobjekt vorgenommene Änderung reflektieren. Einige der auf der Schnittstelle angezeigten Werte können von Werten abgeleitet werden, die aus den geänderten Daten berechnet werden. Wenn nur die geänderten Daten in Erwiderung der Daten-Geändert-Nachricht, die durch den Editierkontext bei Block 370 gesendet wird, aktualisiert werden, aber keine angezeigten Daten, die von den geänderten Daten abgeleitet sind, dann wären die auf der Benutzerschnittstelle angezeigten Daten inkonsistent. Durch Aktualisieren aller Daten, die auf der Benutzerschnittstelle angezeigt werden, stellt die Anzeigegruppe sicher, dass die Benutzerschnittstelle konsistent ist,
4 ist ein Blockdiagramm, das zeigt, wie die Benutzerschnittstelle durch die Anzeigegruppe in Erwiderung einer Objekt-Geändert-Nachricht vom Editierkontext in einer Ausführungsform der vorliegenden Erfindung aktualisiert wird. Wie in 4 dargestellt, empfängt die Anzeigegruppe bei Block 410 eine Nachricht, die Änderungen anzeigt, die an einem Firmenobjekt vorgenommen wurde, und der Nachricht entspricht, die durch den Editierkontext bei Block 370 von 3 gesendet wurde. Die Benutzerschnittstelle erhält dann die neuen Werte für das geänderte Firmenobjekt bei Block 430. In einer Ausführungsform sind die geänderten Werte in der Nachricht enthalten, die bei Block 410 vom Editierkontext empfangen wird. In einer anderen Ausführungsform enthält die Nachricht, die bei Bock 410 vom Editierkontext empfangen wird, die Kennung des geänderten Objekts, aber nicht die Änderungen selbst. In dieser Ausführungsform erhält die Benutzerschnittstelle die geänderten Werte durch direktes Abfragen des geänderten Firmenobjekts.
Nach Erhalt der geänderten Werte berechnet die Benutzerschnittstelle bei Block 440 alle abgeleiteten Werte. Schließlich werden bei Block 450 alle Werte, die durch die Benutzerschnittstelle angezeigt werden, aktualisiert.
5 ist ein Blockdiagramm, das zeigt, wie ein Beispiel eines Editierkontextes der vorliegenden Erfindung die Funktion der Objekteindeutigmachung ausführt. Wie in 5 dargestellt, empfängt der Editierkontext die Anforderung eines neuen Firmenobjekts bei Block 510. Diese Anforderung kann zum Beispiel von der Datenquelle 230 von 2 kommen. Nach Empfang der Anforderung prüft der Editierkontext bei Entscheidungsblock 520 nach, um zu sehen, ob bereits ein Exemplar des angeforderten Objekts vorhanden ist. Wenn bereits ein Exemplar des Objekts vorhanden ist, überträgt der Editierkontext das bestehende Objekt bei Block 570 an den Anforderer. Wenn noch kein Exemplar des Objekts vorhanden ist, übermittelt der Editierkontext eine Anforderung des Objekts aus seinem zugrunde liegenden Objektspeicher, welcher zum Beispiel aus der Datenbankstufe 220, der Adaptorstufe 210 und der Datenbank 200 von 2 bestehen kann. Nach Empfang des angeforderten Objekts aus dem Objektspeicher bei Block 540 registriert der Editierkontext eine eindeutige Kennung des Objekts bei Block 550 und überträgt das neue Objekt bei Block 560 an den Anforderer.
6 ist ein Blockdiagramm, das zeigt, wie eine Ausführungsform der vorliegenden Erfindung die Funktion des Erkennens und Speicherns von Änderungen an Firmenobjekten in der zugrunde liegenden Datenbank oder einem anderen Objektspeicher ausführt. Wie in 6 dargestellt, nimmt der Editierkontext, nachdem der Editierkontext bei Block 610 eine „willChange"-Nachricht von einem Firmenobjekt empfängt, bei Block 620 eine Momentaufnahme des Objekts in seinem unveränderten Zustand auf. Der Editierkontext wartet dann bei Block 630 auf eine Übergabenachricht, die anzeigt, dass eine Änderung abgeschlossen ist und dass die geänderten Daten an die Datenbank zu übergeben sind. Der Editierkontext kann in der Zeit zwischen dem Empfang der anfänglichen „willChange"-Nachricht und der Übergabenachricht zusätzliche „willChange"-Nachrichten vom Firmenobjekt empfangen, aber diese zusätzlichen „willChange"-Nachrichten werden ignoriert. Nachdem der Editierkontext bei Block 640 eine Übergabenachricht empfängt, nimmt der Editierkontext bei Block 650 eine zweite Momentaufnahme des Firmenobjekts auf. Bei Block 660 sendet der Editierkontext eine Änderungsanforderung an den Objektspeicher, um die an dem Firmenobjekt vorgenommene Änderung zu speichern. Der Objektspeicher erkennt die Änderung durch Vergleichen der ersten und zweiten Momentaufnahmen und speichert die Änderung bei Block 670.
In der Ausführungsform von 2 umfasst der Objektspeicher die Zugriffsschicht 290 und die Datenbank 200. Der Objektspeicher kann auch jede andere Entität oder jeder andere Mechanismus sein, der dem Editierkontext auf eine datenbankstufenähnliche Weise zu funktionieren scheint: das heißt, der Firmenobjektdaten in Erwiderung von Datenbankanforderungen vom Editierkontext speichert und abruft.
7 ist ein Bockdiagramm, das zeigt, wie eine Ausführungsform des Editierkontextes der vorliegenden Erfindung eine Undo-Funktionalität bereitstellt. Bei Bock 710 empfängt der Editierkontext eine „willChange"-Nachricht von einem Firmenobjekt, die anzeigt, dass das Firmenobjekt ankündigt, dass es einer Änderung unterzogen wird. Bei Block 715 prüft der Editierkontext nach, um zu sehen, ob bereits eine Momentaufnahme für die aktuelle Änderung aufgenommen wurde. Ein Änderungsereignis ist ein Satz von einer oder mehr aufeinander folgenden Änderungen, die an einem Firmenobjekt innerhalb der vordefinierten Grenzen des Änderungsereignisses vorgenommen werden. Zum Beispiel kann ein Änderungsereignis stattfinden, wenn ein Benutzer mehrere aufeinander folgende Änderungen auf einer Benutzerschnittstelle vornimmt, um die Ergebnisse zu beobachten. In diesem Fall würde das Änderungsereignis beginnen, wenn die erste Änderung eingegeben wird und das Firmenobjekt eine anfängliche „willChange"-Nachricht aussendet. Das Änderungsereignis kann als so lange andauernd gelten, bis der Benutzer eine Speicheranweisung aktiviert oder einen Mauszeiger auf ein anderes Datenfeld bewegt.
Wenn bereits während des aktuellen Änderungsereignisses eine Momentaufnahme aufgenommen wurde, wird die aktuelle „willChange"-Nachricht ignoriert. Wenn noch keine Momentaufnahme aufgenommen wurde, nimmt der Editierkontext bei Block 720 eine Momentaufnahme auf. Bei Block 730 ordnet der Editierkontext die Momentaufnahme in einer „Tabelle für kürzlich erfolgte Momentaufnahmen" an. Die Tabelle für kürzlich erfolgte Momentaufnahmen fungiert als ein Warteplatz für die Momentaufnahme, bis sie auf dem Undo-Stack angeordnet wird, wie im Folgenden beschrieben.
Nach dem Anordnen der Momentaufnahme in der Tabelle für kürzliche erfolgte Momentaufnahmen wartet der Editierkontext bei Block 740 auf eine Ereignisende-Nachricht, die anzeigt, dass das aktuelle Änderungsereignis beendet ist. Nach Empfang der Ereignisende-Nachricht bei Block 750 speichert der Editierkontext die Momentaufnahme, die bei Block 730 in der Tabelle für kürzlich erfolgte Momentaufnahmen gespeichert wurde, bei Block 760 auf dem Undo-Stack. Schließlich löscht der Editierkontext bei Block 770 die Tabelle für kürzlich erfolgte Momentaufnahmen. Das Ergebnis ist, dass die oberste Stufe des Undo-Stacks nun eine Momentaufnahme des Objekts vor den Änderungen enthält, die während des Änderungsereignisses vorgenommen werden. Die vorgenommenen Änderungen können daher durch Umändern des Firmenobjekts zurück in den Zustand, der in der obersten Momentaufnahme im Undo-Stack reflektiert ist, rückgängig gemacht werden.
Die Momentaufnahmen auf dem Undo-Stack ermöglichen eine anschließende Rücksetzung des Zustands des Firmenobjekts in die Zustände, die in jeder Momentaufnahme des Stacks festgehalten sind. Durch Einklammern der Momentaufnahmen und demnach der festgehaltenen Zustände des Objekts zwischen der anfänglichen „willChange"-Nachricht" und einem entsprechenden Ende eines Änderungsereignisses werden kurzfristige Zwischenänderungen im Firmenobjekt ignoriert. Anstelle eines ineffizienten Füllens des Undo-Stacks mit jeder kleinen inkrementellen Änderung im Zustand des Firmenobjekts werden nur signifikante Änderungen gespeichert, was zu einer wirksamen und schnellen Undo-Einrichtung führt.
Im Stand der Technik musste, um eine Undo-Fähigkeit bereitzustellen, ein Undo-Code in das Anwendungsprogramm geschrieben werden, was zum Aufbringen einer beträchtlichen Codierungszeit und einem beträchtlichen Codierungsaufwand führte und die Gelegenheit für zahlreiche Fehler schuf. Durch Verwenden der zuvor beschriebenen Undo-Einrichtungen der vorliegenden Erfindung jedoch erhält ein Anwendungsprogramm automatisch Undo-Fähigkeiten ohne Notwendigkeit einer komplexen Codierung und mit einer geringen Fehlergefahr.
Obwohl die Benutzerschnittstellenaktualisierungs-, Datenspeicherungs- und Undo-Fähigkeiten des Editierkontextes der vorliegenden Erfindung in Bezug auf getrennte Ausführungsformen 3, 6 beziehungsweise 7 beschrieben wurden, kann ein einziger Editierkontext der vorliegenden Erfindung einige oder alle dieser Fähigkeiten gleichzeitig bereitstellen.
In jeder der Ausführungsformen der vorliegenden Erfindung, die zuvor in Bezug auf 2 bis 4, 6 und 7 beschrieben wurden, fungiert der Editierkontext für ein oder mehr Anwendungsprogramme als Manager eines Objektgraphen, der von einer zugrunde liegenden Datenspeicherentität erhalten wurde, die mit dem generischen Namen „Objektspeicher" bezeichnet wurde. Diese Grundstruktur ist in 8 dargestellt, welche den Editierkontext 820 zeigt, der den Objektgraphen 825 für die Anwendungen 805, 810 und 815 verwaltet.
Der Objektgraph 825 stellt eine bestimmte Ansicht der Datenbankstruktur dar, die dem Objektspeicher 830 zugrunde liegt. Vom Gesichtspunkt des Editierkontextes 820 stellt der Objektspeicher 830 eine Quelle von neuen Objekten und eine Senke für geänderte Objekte dar. Wie bereits erwähnt, kann der Objektspeicher 830 aus der Zugriffsschicht 290 und der Datenbank 200 von 2 bestehen. Der Objektspeicher 830 kann jedoch aus anderen Entitäten und/oder Systemen bestehen, die auf Anforderungen vom Editierkontext 820 antworten, um Datenbankfunktionen in Bezug auf den Objektgraphen 825 auszuführen, der durch den Editierkontext 820 verwaltet wird.
9 und 10 veranschaulichen beispielhafte Ausführungsformen von Strukturen, die als Objektspeicher 830 verwendet werden können. Von diesem Gesichtspunkt des Editierkontextes sieht jede dieser Ausführungsformen gleich aus.
9 ist eine schematische Darstellung, welche die Struktur einer Ausführungsform des Objektspeichers der vorliegenden Erfindung darstellt, der mehrere Adaptorstufen und mehrere Datenbanken umfasst. In dieser Ausführungsform besteht der Objektspeicher aus einem Objektspeicher-Koordinator 905, drei verschiedenen Datenbanken 940, 945 beziehungsweise 950, drei entsprechenden Adapatorstufen 925, 930 beziehungsweise 935 und drei entsprechenden Datenbankstufen 910, 915 beziehungsweise 920. Die drei Datenbanken können durch verschiedene Datenbankverwaltungssysteme verwaltet werden. Zum Beispiel kann die Datenbank 940 eine Oracle-Datenbank sein, die Datenbank 945 kann eine Sybase-Datenbank sein, und die Datenbank 950 kann eine andere Datenbank sein. Der Objektspeicher-Koordinator 905 koordiniert Datenbankanforderungen, die vom Editierkontext 900 empfangen, entscheidet, welche Datenbank jeder empfangenen Anforderung entspricht, und sendet die geeignete Nachricht an die geeignete Datenbankstufe, welche die angeforderte Datenbankfunktion über die entsprechende Adaptorstufe ausführt. Wenn die Anforderung vom Editierkontext 900 eine Aktualisierung von Daten umfasst, die in einem Firmenobjekt enthalten sind, bestimmt der Objektspeicher-Koordinator 905 die Datenbank, die den geänderten Daten entspricht, und sendet eine geeignete Nachricht an die entsprechende Datenbankstufe. Wenn die Anforderung vom Editierkontext 900 die Erzeugung eines neuen Firmenobjekts umfasst, führt der Objektspeicher-Koordinator 905 die angeforderte Objekt-in-Datenbank-Abbildung durch und extrahiert die geeigneten Daten aus einer oder mehreren der Datenbanken.
In der Ausführungsform von 9 gehören die mehreren Datenbanken alle zu einem einzigen Computersystem. Die Datenbanken können jedoch über verschiedene Maschinen in einem Computernetzwerk verstreut sein, wie in 10 dargestellt.
Die Ausführungsform von 10 umfasst wie die Ausführungsform von 9 einen Editierkontext 1000, einen Objektspeicher-Koordinator 1005, drei Datenbankstufen 1010, 1015 und 1020 und drei entsprechende Adaptorstufen 1025, 1030, 1035. Die Ausführungsform von 10 umfasst auch drei verschiedene Datenbanken 1060, 1065 und 1070. Anstatt aber direkt mit ihren entsprechenden Adaptorstufen verbunden zu sein, sind die Datenbanken 1060, 1065 und 1070 über ein Netzwerk verteilt und werden durch getrennte Datenbankserver 1045, 1050 beziehungsweise 1055 verwaltet. Demgemäß kontaktiert eine Adaptorstufe in der Ausführungsform von 10 ihre entsprechende Datenbank durch Senden einer Netzwerknachricht an den geeigneten Datenbankserver, anstatt eine verbundene Datenbank direkt zu adressieren, wie in 9. In dieser Ausführungsform koordiniert der Objektspeicher-Koordinator 1005 Datenbankanforderungen, die vom Editierkontext 1000 empfangen, entscheidet, welche Datenbank jeder empfangenen Anforderung entspricht, und sendet eine geeignete Nachricht an die anwendbare Datenbankstufe. Die Datenbankstufe überträgt eine entsprechende Nachricht an ihre Adaptorstufe, welche die geeignete Netzwerknachricht an den geeigneten Datenbankserver formuliert, um die angeforderte Datenbankfunktion auszuführen. Wenn die Anforderung vom Editierkontext 1000 eine Aktualisierung von Daten umfasst, die in einem Firmenobjekt enthalten sind, bestimmt der Objektspeicher-Koordinator 1005 die Datenbank, die den geänderten Daten entspricht, und sendet eine geeignete Nachricht an die entsprechende Datenbankstufe. Die Datenbankstufe sendet eine entsprechende Nachricht an ihre Adaptorstufe, welche eine geeignete Netzwerknachricht an den anwendbaren Datenbankserver überträgt. Wenn die Anforderung vom Editierkontext 1000 die Erzeugung eines neuen Firmenobjekts umfasst, führt der Objektspeicher-Koordinator 1005 die angeforderte Objekt-in-Datenbank-Abbildung durch und extrahiert die geeigneten Daten aus einer oder mehren der Datenbanken wieder über die anwendbare Datenbankstufe, Adaptorstufe, Netzwerk und Datenbankserver. Wieder sind die Komplexitäten, die dem Editierkontext 1000 zugrunde liegen, verborgen. Der Editierkontext 1000 interagiert mit dem Objektspeicher-Koordinator 1005 auf dieselbe Art und Weise wie mit der Datenbank 220 in der einfachen Struktur von 2.
11 ist eine schematische Darstellung, welche die Struktur einer Ausführungsform der vorliegenden Erfindung darstellt, die mehrere verschachtelte Editierkontexte umfasst. Diese Ausführungsform ist der Ausführungsform von 8 ähnlich. Anstatt jedoch einen Editierkontext 820 aufzuweisen, der einen Objektgraphen 825 für mehrere Anwendungen 805, 801 und 815 verwaltet, wie in 8, verwaltet der Editierkontext 1145 in der Ausführungsform von 11 einen Objektgraphen 1150 für drei andere Editierkontexte 1115, 1120 beziehungsweise 1125. Jeder dieser anderen Editierkontexte verwaltet seinen eigenen Objektgraphen für seine eigene Anwendung, welche ein getrenntes Anwendungsprogramm sein kann, aber normalerweise eher eine getrennte Aufgabe ist, die durch ein einziges Anwendungsprogramm ausgeführt wird. Zum Beispiel kann jede Anwendung aus einem getrennten Fenster bestehen, das auf verschiedene oder dieselben Ansichten der zugrunde liegenden Daten schaut. Entsprechend verwaltet der Editierkontext 1115 den Objektgraphen 1130 für die Anwendung 1100, der Editierkontext 1120 verwaltet den Objektgraphen 1135 für die Anwendung 1105 und der Editierkontext 1125 verwaltet den Objektgraphen 1140 für die Anwendung 1110. Für jeden der Editierikontexte 1115, 1120 und 1125 sieht der Editierkontext 1145 wie ein Objektspeicher 830 von 8 aus. Umgekehrt sieht jeder der Editierkontexte 1115, 1120 und 1125 für den Editierkontext 1145 von 11 wie ein Anwendungsprogramm 805, 810 oder 815 von 8 aus. Jeder der Editierkontexte 1115, 1120 und 1125 verwaltet einen getrennten Objektgraphen 1130, 1135 beziehungsweise 1140. Die Objektgraphen 1130, 1135 und 1140 stellen unabhängige Ansichten der Daten dar, die durch den Editierkontext 1145 bereitgestellt werden. Da jeder Objektgraph unabhängig erzeugt wird, können mehrere Exemplare von Firmenobjekten vorhanden sein, die über die Objektgraphen 1130, 1135 beziehungsweise 1140 verstreut sind. Jede der Anwendungen 1100, 1105 und 1110 kann daher unabhängig arbeiten und Änderungen an getrennten Exemplaren derselben Firmenobjekte vornehmen. Wenn ein Anwendungsprogramm 1100, 1105 oder 1110 wünscht, eine Änderung an die Datenbank zu übergeben, wird eine Änderungsübergabe-an-Datenbank-Nachricht an den Editierkontext 1145 gesendet. Der Editierkontext 1145 aktualisiert dann die geeigneten Firmenobjekte in seinem Objektgraphen 1150 und überträgt außerdem eine Änderungsnachricht an die Editierkontexte 1115, 1120 beziehungsweise 1125. Die Editierkontexte 1115, 1120 und 1125 können diese Änderungen in Abhängigkeit von der jeweiligen Konfiguration und dem jeweiligen Zweck der Anwendungsprogramme an ihre jeweiligen Anwendungen 1100, 1105 und 1110 übermitteln oder auch nicht. Der Editierkontext 1145 übergibt die Änderungen nicht an den zugrunde liegenden Objektspeicher 1155, sofern er nicht eine ausdrückliche Nachricht empfängt, dies zu tun. Jeder der Editierkontexte 1115, 1120 und 1125 kann im Allgemeinen jede der Funktionen für einen Editierkontext, wie in Bezug auf 2 bis 7 beschrieben, ausführen.
Die verschachtelte Editierkontextstruktur von 11 stellt ein vereinfachtes Mittel zum Erzeugen eines Datenbankanwendungsprogramms bereit, das „Herunterhangel-Benutzerschnittstellen" verwendet. Herunterhangel-Benutzerschnittstellen bestehen zum Beispiel aus einer Reihe von Einblendfenstern, die verwendet werden können, um Änderungen an Daten vorzunehmen, die in einem Fenster angezeigt werden. Zum Beispiel kann ein Fenster die Angestellten einer Abteilung, ihre Gehälter und die Abteilungsbudgetdaten anzeigen. Ein Abteilungsleiter wünscht möglicherweise, verschiedene „Was-wäre-wenn"-Szenarien zu erforschen, ohne die zugrunde liegende Datenbank tatsächlich zu ändern. Es kann ein Anwendungsprogramm kann so ausgelegt sein, dass es dem Abteilungsleiter ermöglicht, ein zweites Fenster einzublenden, in welchem der Abteilungsleiter verschiedene Änderungen an den angezeigten Daten vornehmen kann, um zu sehen, welche Folgen daraus entstehen. Es könnte eine Befehlstaste vorgesehen sein, damit, wenn der Abteilungsleiter mit den Änderungen zufrieden ist, die Änderungen an die Datenbank übergeben werden.
Im Stand der Technik war das Entwickeln solch einer Anwendung komplex. Um ein Einblendfenster zu erzeugen, hatte die Anwendung Werte aus den zugrunde liegenden Datenbankobjekten auf lokale Variable zu kopieren, welche im Einblendfenster angezeigt wurden. Die Anwendung musste außerdem die Validierungsverfahren der zugrunde liegenden Objekte neu erzeugen und alle abgeleiteten Werte berücksichtigen. Sobald Änderungen an den lokalen Variablen zu übergeben waren, musste die Anwendung die geänderten Werte manuell ernten und sie an die zugrunde liegenden Objekte senden.
Die vorliegende Erfindung stellt eine wesentlich weniger komplexe Möglichkeit bereit, Herunterhangelschnittstellen zu entwickeln. Durch Verwenden von verschachtelten Editierkontexten und demnach Erzeugen von unabhängigen Kopien der zugrunde liegenden Firmenobjekte können die Firmenobjekte selbst in einem Einblendfenster verarbeitet werden, anstatt dass lokale Variable erzeugt und bearbeitet werden müssen. Demgemäß kann derselbe Code wie der im Hauptfenster verwendet werden, um Daten im Einblendfenster verarbeiten. Da der Benutzer mit Kopien der Objekte statt mit abgeleiteten lokalen Variablen arbeitet, werden alle Verfahren des Objekts bewahrt. Die vorliegende Erfindung stellt demnach eine einfachere und weniger fehleranfällige Möglichkeit bereit, Anwendungsprogramme zu erzeugen, welche Herunterhangelschnittstellen verwenden.
Die vorliegende Erfindung kann durch Softwareprogrammierung auf jeder einer Vielzahl von einem oder mehreren Computersystemen, wie sie im Stand der Technik allgemein bekannt sind, implementiert werden, welche, ohne Einschränkung, solche Computersysteme, wie beispielsweise jenes umfassen, das in 12 dargestellt ist. Das Computersystem, das in 12 dargestellt ist, umfasst eine CPU-Einheit 1200, die einen zentralen Prozessor, einen Hauptspeicher, periphere Schnittstellen, Eingabe-Ausgabe-Einrichtungen, eine Leistungsversorgung und eine zugehörige Schaltungsanordnung und Bauelemente aufweist; eine Anzeigeeinrichtung 1210, welche eine Kathodenstrahlröhrenanzeige, eine LCD-Anzeige, eine Gas-Plasma-Anzeige oder jede andere Computeranzeige sein kann; und eine Eingabevorrichtung 1230, welche eine Tastatur, eine Maus, eine Grafiktablett oder eine andere Eingabevorrichtung umfassen kann. Das Computersystem kann einen nichtflüchtigen Speicher 1220, welcher magnetische, optische oder andere Massenspeichereinrichtungen umfassen kann, aufweisen oder nicht. Das Computersystem kann außerdem eine Netzschnittstelle 1240 umfassen, welche es dem Computersystem ermöglicht, mit anderen Systemen über ein Kommunikationsnetz zu kommunizieren. Es kann auch jede andere einer Vielzahl von Konfigurationen von Computersystemen verwendet werden.
Somit wurde ein neuartiges Verfahren und eine neuartige Vorrichtung zum Verwalten eines Objektgraphen von datentragenden Objekten vorgestellt.

Claims

In einem Computersystem, ein Verfahren zum Überwachen von an einem Objektgraph vorgenommenen Veränderungen, wobei der Objektgraph eine Mehrzahl von datentragenden Objekten mit Daten von einer Datenbank aufweist, dadurch gekennzeichnet, daß es die Schritte enthält: bevor irgendwelche Veränderungen an einem ersten datentragenden Objekt in dem Objektgraph vorgenommen werden, Übertragen einer Nachricht von dem ersten datentragenden Objekt an einen Objektgraph-Manager, die anzeigt, daß an dem ersten datentragenden Objekt eine Änderung zu erwarten ist; Aufnehmen einer Momentaufnahme des ersten datentragenden Objekts, sobald der Objektgraph-Manager die erste Nachricht mit der Anzeige der zu erwartenden Veränderung erhält; dann Ausführen einer Veränderung an dem ersten datentragenden Objekt; Erwarten einer den Abschluß der Veränderung anzeigenden Nachricht; Bestimmen der an dem ersten datentragenden Objekt vorgenommenen Veränderung durch Vergleichen des datentragenden Objekts nach der Vornahme der Änderung mit der Momentaufnahme des Objekts.
Das Verfahren gemäß Anspruch 1, wobei der Schritt des Übertragens der Nachricht, die anzeigt, daß an dem ersten datentragenden Objekt eine Änderung zu erwarten ist, in Erwiderung auf ein Ereignis erfolgt, welches die Ausführung eines Anwendungscodes initiiert, und wobei die Änderung an dem ersten datentragenden Objekt während der Ausführung des Anwendungscodes vorgenommen wird, wobei das Verfahren ferner aufweist: Übertragen einer ein Ende der Ausführung des Anwendungscodes anzeigenden Nachricht an den Objektgraph-Manager.
Das Verfahren gemäß Anspruch 1, ferner mit dem Schritt: Übertragen einer eine Änderung an dem ersten datentragenden Objekt anzeigenden Nachricht von dem Objektgraph-Manager an ein interessiertes Objekt.
Das Verfahren gemäß Anspruch 3, wobei das interessierte Objekt ein bei dem Objektgraph-Manager als über alle an dem ersten datentragenden Objekt stattfindenden Änderungen zu informierendes Objekt registriert ist.
Das Verfahren gemäß Anspruch 1, wobei der Schritt des Übertragens einer Nachricht, welche anzeigt, daß an dem ersten datentragenden Objekt eine Änderung zu erwarten ist, die Schritte umfaßt: Registrieren des Objektgraph-Managers als Beobachter bei dem ersten datentragenden Objekt; und Übertragen der Nachricht, welche anzeigt, daß bei dem ersten datentragenden Objekt eine Änderung zu erwarten ist, von dem ersten datentragenden Objekt zu registrierten Beobachtern des ersten datentragenden Objekts.
Das Verfahren gemäß Anspruch 3, wobei das interessierte Objekt ein Benutzerschnittstellen-Manager-Objekt aufweist, welches die in einer Benutzerschnittstelle angezeigten Werte verwaltet und ferner mit den Schritten: nachdem das Benutzerschnittstellen-Manager-Objekt die Nachricht empfangen hat, welche eine Änderung an dem ersten datentragenden Objekt anzeigt, Übertragen einer Nachricht von dem Benutzerschnittstellen-Manager-Objekt an das erste datentragende Objekt, mit der Werte für Daten des ersten datentragenden Objekts abgefragt werden; Übertragen der Werte der Daten des ersten datentragenden Objekts von den ersten datentragenden Objekt an das Benutzerschnittstellen-Manager-Objekt; und Aktualisieren der in der Benutzerschnittstelle angezeigten Werte, entsprechend den Werten der Daten des ersten datentragenden Objekts.
Das Verfahren gemäß Anspruch 1, ferner mit: Übertragen einer Übergabenachricht an den Objektgraph-Manager, die eine Übergabe der an dem ersten datentragenden Objekt erfolgten Änderungen an die Datenbank anfordert; und Speichern von einer oder mehreren erfaßten Änderungen entsprechenden Daten in der Datenbank; wobei der Schritt des Bestimmens der an dem ersten datentragenden Objekt erfolgten Änderungen aufweist: Aufnehmen einer zweiten Momentaufnahme des ersten datentragenden Objekts, wenn der Objektgraph-Manager die Übergabenachricht empfängt; und Erkennen einer oder mehrerer Änderungen an dem ersten datentragenden Objekt durch Vergleichen der zweiten Momentaufnahme mit der ersten Momentaufnahme.
Das Verfahren gemäß Anspruch 7, wobei der Schritt des Speicherns der einer oder mehrerer erkannter Änderungen entsprechenden Daten aufweist: Senden einer Änderungsanforderung von dem Objektgraph-Manager an einen Objektspeicher.
Das Verfahren nach Anspruch 8, wobei der Objektspeicher einen Objektspeicher-Koordinator aufweist, der eine Schnittstelle zwischen dem Objektgraph-Manager und einer Mehrzahl von Datenbanken bildet.
Das Verfahren gemäß Anspruch 9, wobei die Mehrzahl von Datenbanken über ein Computernetzwerk verteilte Datenbanken aufweist.
Das Verfahren gemäß Anspruch 2, ferner mit: Speichern der Momentaufnahme auf einem Undo-Stack.
Das Verfahren gemäß Anspruch 11, ferner mit dem Schritt des Bestimmens, ob eine vorhergehende Momentaufnahme des ersten datentragenden Objekts während der Ausführung des Anwendungscodes bereits aufgenommen wurde, in Erwiderung des Ereignisses und vor dem Aufnehmen der Momentaufnahme des ersten datentragenden Objekts, und wobei die Momentaufnahme nur aufgenommen wird, wenn solch eine vorhergehende Momentaufnahme nicht aufgenommen wurde.
Das Verfahren gemäß Anspruch 11, ferner mit den Schritten: Aufnehmen der Momentaufnahme in einer Tabelle für kürzlich erfolgte Momentaufnahmen, nachdem die Momentaufnahme aufgenommen wurde; und Löschen der Tabelle für kürzlich aufgenommene Momentaufnahmen, nachdem die Momentaufnahme auf dem Undo-Stack gespeichert wurde.
Das Verfahren gemäß Anspruch 1, ferner mit den Schritten: Erzeugen eines zweiten Objektgraphen, der durch einen zweiten Objektgraph-Manager verwaltet wird, wobei der zweite Objektgraph eine Kopie des ersten datentragenden Objekts aufweist; Durchführen von einer oder mehrerer Änderungen an der Kopie in dem zweiten Objektgraph; Senden einer Änderungsanforderung von dem zweiten Objektgraph-Manager an den ersten Objektgraph-Manager nachdem eine Anweisung zur Speicherung einer oder mehrerer Änderungen an der Kopie in dem zweiten Objektgraph empfangen wurde; in Erwiderung auf die Änderungsanforderung, Verändern des entsprechenden Originals des ersten datentragenden Objekts in dem ersten Objektgraph, um der einen oder den mehreren Änderungen an der Kopie in dem zweiten Objektgraph zu entsprechen.
Das Verfahren gemäß Anspruch 14, wobei ein dritter Objektgraph eine zweite Kopie des ersten datentragenden Objekts in dem ersten Objektgraph enthält und wobei der dritte Objektgraph von einem dritten Objektgraph-Manager verwaltet wird, wobei das Verfahren ferner den Schritt aufweist: Übertragen einer Nachricht bezüglich der Änderungen an dem ersten datentragenden Objekt von dem ersten Objektgraph-Manager zu dem dritten Objektgraph-Manager.
Eine Programmspeichereinrichtung, die von einer Maschine lesbar ist, die eine greifbare Ausführungsform eines Programms von Anweisungen darstellt, das von einer Maschine zur Ausführung eines Verfahrens gemäß einem der Ansprüche 1 bis 15 ausführbar ist.