DE69734545T2

DE69734545T2 - Verfahren und Vorrichtung zur Verbesserung der Portierbarkeit einer objektorientierten Schnittstelle zwischen verschiedenen Umgebungen

Info

Publication number: DE69734545T2
Application number: DE69734545T
Authority: DE
Inventors: Laurence P.G. Mountain View Cable
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1996-07-30
Filing date: 1997-07-14
Publication date: 2006-07-20
Anticipated expiration: 2017-07-15
Also published as: EP0822484A3; JPH113237A; DE69734545D1; EP0822484A2; US5999728A; EP0822484B1

Description

HINTERGRUND DER ERFINDUNG
Gebiet der Erfindung
Die Erfindung betrifft allgemein netzwerkbasierte graphische Benutzeroberflächen. Insbesondere betrifft die Erfindung Systeme und Verfahren zum Verbessern der Portabilität und Aufrechterhaltbarkeit einer objektorientierten Oberfläche in einer Mehrzahl von Plattformen, so dass die Oberfläche zum Beispiel mit einer Client/Server-Umgebung verwendet werden kann, die eine aus einer Mehrzahl von unterschiedlichen Hardware- und/oder Software-Plattformen integriert.
Stand der Technik
Bekannte graphische Benutzeroberflächen stellen Anwendungsentwicklern eine Anwendungsprogrammierschnittstelle (API, application program interface) bereit, die eine Sammlung von Objekten, wie zum Beispiel Bildlaufleisten, Schaltflächen, Texteingabefelder und so weiter, aufweist. Eine objektorientierte graphische Benutzeroberfläche (GUI, graphical user interface) weist typischerweise eine hierarchische Sammlung dieser Objekte in einem "Toolkit" auf.
Das Verhalten einer graphischen Benutzeroberfläche innerhalb eines Systems ist durch Wechselwirkungen zwischen den Objekten in dem Client einer Client/Server-Umgebung und dem Fenster-basierten Systemserver definiert. Ein Paradigma, das zum Darstellen definierter Wechselwirkungen zwischen den Objekten verwendet wird, wird oft als ein "Modell-Darstellung-Steuerungs" (MVC, model-view-controller)-Paradigma der Objekt-Wechselwirkung bezeichnet. Das Modell-Darstellungs-Steuerungs-Paradigma definiert formell die Weise, durch die Änderungen im Zustand innerhalb wenigstens eines Teils des Systems (z.B. einem Timer des Systems) auftreten, und wie diese Änderungen an andere Teile des System übertragen werden, oder darin reflektiert werden, die ein Interesse am Beobachten solcher Systemänderungen (wie zum Beispiel eine angezeigte Uhr) eingerichtet haben. Die Steuerung kann als ein Satz von Regeln betrachtet werden, der definiert, wie Zustandsänderungen, die in Antwort auf ein Modell implementiert sind, eine Darstellung beeinflussen. Unter Verwendung des Modell-Darstellungs-Steuerungs-Paradigmas kann das Toolkit als eine hierarchische Sammlung von Modellen, Darstellungen und Steuerungen betrachtet werden, die die graphische Benutzeroberfläche implementieren.
1A stellt eine abstrakte Darstellung einer Wechselwirkung zwischen einem Modell 102, einer Darstellung 104 und einer Steuerung 106 dar, wobei das Modell als gespeicherte Daten betrachtet werden kann, und die Steuerung als die Regeln betrachtet werden kann, mittels denen das Modell und die Darstellung wechselwirken. Pfeile 108 in 1A bilden das allgemeinste Modell-Darstellungs-Steuerungs-Paradigma ab, worin Zustandsänderungen in beiden Richtungen fließen können.
Mit Bezugnahme zu 1B werden sich Fachleute bewusst sein, das die Unterscheidungen zwischen dem Modell, der Darstellung und der Steuerung oft in einer Implementierung überlappen, obwohl das Modell, die Darstellung und die Steuerung konzeptionell getrennt sind. Zum Beispiel kann ein Bildlaufleisten-Objekt 112 einer objektorientierten grafischen Benutzeroberfläche sowohl eine Steuerung als auch eine Darstellung darstellen. Die Bildlaufleiste aus 1B ist eine Darstellung, wenn sie zum Beispiel den Prozentsatz einer Textdatei 114 darstellt, die in einer Textdarstellung 116 dargestellt wurde oder wird (d.h. irgendwo von Null Prozent bis 100 Prozent). Die Bildlaufleiste antwortet auf eine Reihe von Steuerereignissen, die von einer Maus erzeugt werden, zum Anzeigen der aktuellen Position der Bildlaufleiste auf einem Monitor. Wie hierin benannt, stellt ein "Ereignis" eine Information einer Zustandsänderung dar, die für eine Implementierung auf einer Fenster-basierten Plattform besonders ist, und im Konzept über Fenster-basierte Plattformen hinweg generisch ist, zwischen denen Portierbarkeit gewünscht ist.
In diesem Beispiel kann die Bildlaufleiste 112 auch eine Steuerung sein, die zum Initiieren oder Steuern des Auffrischens einer Textanzeige der Textdatei 114 in Antwort auf Bewegungen der Maus verwendet wird. Das heißt, durch "Klicken" auf die Bildlaufleiste und vertikales Bewegen seines Bilds 112, dient die Bildlaufleiste als eine Steuerung, die einen Strom von Benachrichtigungen erzeugt, die an die Darstellung 116 gesendet und davon verwendet werden zum kontinuierlichen Neu-Zeichnen der Bildlaufleiste, wenn sie auf der Anzeige auf- und abbewegt wird, wodurch die Darstellung der Bildlaufleiste und daher die Inhalte der Datei 114 geändert werden. In dem Beispiel von 1B definiert das Modell (d.h. die Textdatei 114), wie sich eine Benutzer-Aktivierung der Maus auf eine dargestellte Darstellung der Bildlaufleiste und daher die Textdatei auswirkt.
In einem typischen Fenster-basierten System, wie zum Beispiel dem UNIX-basierten X-Windows-System^TM vom Massachusetts Institute of Technology, werden Zustandsänderungen innerhalb des Systems über "Ereignisse" in einer Weise an Clients graphischer Benutzeroberflächen kommuniziert, die der ähnlich ist, die oben mit Bezugnahme zu dem Modell-Darstellungs-Steuerungs-Paradigma beschrieben wurde. Wenn ein Fenster-basiertes System einem Toolkit einer objektorientierten graphischen Benutzeroberfläche zugeordnet ist, bildet das Toolkit Zustandsänderungen in dem Fenster-basierten System, die über Fenstersystem-Ereignisse berichtet wurden, auf einen objektorientierten Modell-Darstellung-Steuerung ab. Das Fenster-basierte Systemereignis resultiert in einem Methodenaufruf auf einem Objekt der graphischen Benutzeroberfläche zum Benachrichtigen desselben von der Zustandsänderung.
Die Definition der Beziehungen zwischen Modellen, Darstellungen und Steuerungen wird durch Implementationsspezifische Definitionen von Objekt-"Klassen" eingerichtet. Obwohl die Beziehungen zwischen bestimmten Instanzen von Modellen, Darstellungen und Steuerungen dynamisch während der Laufzeit einer Anwendung spezifiziert werden können, sind diese Beziehungen zum Zeitpunkt der Ausführung einer Clientseitigen Anwendung nicht änderbar, außer durch eine Zuteilung zwischen Instanzen von bestimmten Implementierungen der Modelle und Darstellungen. Das ist zum Beispiel der Fall, wo objektorientierte Systeme in Programmiersprachen wie zum Beispiel C++ implementiert sind.
Da Wechselwirkungen zwischen Objekten mittels einer Modell-Darstellung-Steuerung definiert sind, die als eine Plattform-spezifische Implementierung zur Verwendung mit einer spezifischen Fenster-basierten Umgebung entwickelt ist, kann das Toolkit nicht ohne weiteres von einer Fenster-basierten Plattform auf eine andere portiert werden. Das heißt, ein "Ereignis", das in einer ursprünglichen Fenster-basierten Plattform gefunden wird, für das ein Toolkit implementiert ist, kann in der Implementierung signifikant von einer anderen Fenster-basierten Plattform abweichen, auf die das Toolkit zu portieren ist. Ferner sind ursprüngliche Implementierungen einfach nicht mit einem Ziel einer Portabilität auf andere Umgebungen entworfen, so dass Plattform-Abhängigkeiten typischerweise nicht innerhalb der ursprünglichen Plattform lokalisiert oder abstrahiert sind. Ein "Ereignis", das für eine Plattform definiert ist, ist normalerweise in der Implementierung bezüglich anderer Plattformen von der Information, die bereitgestellt wird (d.h. unterschiedlicher Semantiken), genauso wie dem Format, mit dem jede solche Information bereitgestellt wird (d.h. unterschiedliche Syntax), unterschiedlich. Die Menge an Computerkodes, der überarbeitet werden muss, um ein Toolkit, das für eine Fenster-basierte Plattform definiert ist, mit einer anderen Fenster-basierten Plattform zu verwenden, ist daher übermäßig und unpraktisch. Daher gibt es bedeutende Probleme beim Portieren einer objektorientierten graphischen Benutzeroberfläche von einer ursprünglichen Fenster-basierten Plattform auf eine andere Fenster-basierte Plattform (z.B. wie dem Portieren von der NeXSTEP-Umgebung der NeXT-Computer-Gesellschaft auf eine andere Fenster-basierte Plattform, wie zum Beispiel dem X-Windows-System^TM).
BOSCH R. ET. AL.: "EIN TOOL BÄNDIGT RECHNERWELTEN/PORTIERBARE BENUTZERSCHNITTSTELLE GREIFT ENTWICKLERN UNTER DIE ARME"; ELECTRONIK, DE, FRANZIS VERLAG GMBH, MÜNCHEN, Vol. 40, Nr. 21, 15. Oktober 1991) (1991 10-15), S. 50-53, 58-59, XP000246070 ISSN: 0013-5658 offenbart ein Toolkit zum Erzeugen graphischen Benutzeroberflächen, die auf andere Plattformen und Betriebssysteme ohne Umprogrammieren übertragen werden können. Ein virtuelles Fenstersystem (virtual graphics machine) stellt einen vollständigen Satz von Grafik-Elementarobjekten (graphics primitives) bereit, der auf jeder der Plattformen verwendet werden kann.
Es wäre wünschenswert, ein verfahren zu entwickeln, mit dem Plattform-Abhängigkeiten lokalisiert und abstrahiert werden können, zum Gebrauch mit einer objektorientierten graphischen Benutzeroberfläche, wobei Objekt-Wechselwirkungen bezüglich einer abstrahierten Modell-Darstellungs-Steuerung definiert sind. Zum Beispiel wäre es wünschenswert, die Ereignisse, die von einem Fenster-basierten System empfangen werden, zu abstrahieren, so dass die Hauptabschnitte des Codes, die zum Darstellen eines Toolkits einer objektorientierten graphischen Benutzeroberfläche verwendet werden, unverändert bleiben können, und daher auf einfache Weise auf jede einer Mehrzahl von Fenster-basierten Plattformen portiert werden können.
OFFENBARUNG DER ERFINDUNG
Die Erfindung ist auf ein Verfahren und eine Vorrichtung zum Portieren eines Toolkits einer graphischen Benutzeroberfläche auf eine Fenster-basierte Plattform gerichtet, das den Schritt aufweist Empfangen einer ursprünglichen Benachrichtigung eines Zustandwechsels von einer Fenster-basierten Plattform, und gekennzeichnet ist durch das Aufweisen der Schritte: Darstellen der ursprünglichen Benachrichtigung als einer abstrahierten Benachrichtigung während des Ausführens der graphischen Benutzeroberfläche, wobei die abstrahierte Benachrichtigung eine Verhaltens-Spezifikation der ursprünglichen Benachrichtigung bildet, die von Implementierungen unabhängig ist, die für die Fenster-basierte Plattform spezifisch sind; und Einrichten der graphischen Schnittstelle zum Verifizieren einer Übereinstimmung von wenigstens einem Objekt in dem Toolkit der graphischen Benutzeroberfläche mit der Verhaltens-Spezifikation während des Ausführens der graphischen Benutzeroberfläche.
Die Erfindung ist auf das Bereitstellen einer Fähigkeit zum Wieder-Hosten oder Portieren einer Implementierung einer objektorientierten graphischen Benutzeroberflächen von einer ursprünglichen Fenster-basierten Plattform, oder Umgebung, auf eine andere Fenster-basierte Plattform, oder Umgebung, gerichtet. In Übereinstimmung mit beispielhaften Ausführungsformen werden alle Benachrichtigungen (z.B. Ereignisse, Zustandsänderungen oder "Interessen"), die in der ursprünglichen Umgebung auftauchen, als Verhaltens-Spezifikationen abstrahiert. Diese Verhaltens-Spezifikationen (d.h. Eigenschaften oder Protokolle) können als ein Teil einer Entsprechungs-Verhandlung verwendet werden, um während der Ausführungs-Laufzeit der graphischen Benutzeroberfläche zu bestimmen, ob ein bestimmtes Client-seitiges Objekt mit den Verhaltens-Spezifikationen übereinstimmen wird, die aus Server-seitigen Ereignissen abstrahiert wurden, die einem unterschiedlichen Objekt zugeordnet sind. Wo sich die Übereinstimmungs-Verhandlung als erfolgreich erweist, können abstrahierte Benachrichtigungen zwischen bestimmten Instanzen von Objekten zum Modellieren des Zustands des Systems fließen, vielmehr als das ursprüngliche Implementierungen von Ereignissen verwendet werden. Während der Ausführungs-Laufzeit können andere Objekte zum Zweck des Empfangens der abstrahierten Benachrichtigungen dynamisch Beziehungen mit Objektklassen einrichten, die abstrahierte Benachrichtigungen aufweisen.
Beispielhafte Ausführungsformen der Erfindung schaffen dadurch eine Abstraktionsschicht innerhalb der ursprünglichen Implementierung, die Plattform-Implementierungsabhängigkeiten im ganzen Toolkit der objektorientierten graphischen Benutzeroberfläche trennt und lokalisiert. Beispielhafte Ausführungsformen erweitern das Client-seitige Modell-Darstellungs-Steuerungs-Paradigma und seine Anwendungen innerhalb der Benutzeroberflächen beträchtlich zum Reduzieren der Größe der Portier-Aufgabe und zum Unterbringen eines Portierens einer Oberfläche unter unterschiedlichen Fenster-basierten Plattformen.
Gemäß der Erfindung entsprechen willkürliche Implementierungen von Modellen, Darstellungen und Steuerungen willkürlich abstrahierten Benachrichtigungen. Abstrahierte Benachrichtigungen, die in dem Toolkit der objektorientierten graphischen Benutzeroberfläche definiert wurden, können unter Verwendung einer Programmiersprache der graphischen Benutzeroberfläche implementiert werden. Folglich kann ein Toolkit, das als ein Teil einer graphischen Benutzeroberfläche eingerichtet ist, schnell und kosteneffektiv über jede einer Mehrzahl von Fenster-basierten Systemen hinweg portiert werden.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die vorangegangenen und anderen Merkmale der Erfindung werden für Fachleute beim Lesen der folgenden Beschreibung von bevorzugten Ausführungsbeispielen der Erfindung in Verbindung mit den begleitenden Zeichnungen offensichtlich, wobei.
1A eine abstrahierte Darstellung eines Modell-Darstellungs-Steuerungs-Paradigmas zeigt;
1B eine beispielhafte Anwendung der in 1A gezeigten abstrahierten Darstellung ist;
2 ein beispielhaftes Flussdiagramm zum Portieren einer Benutzeroberfläche von einer ersten Fenster-basierten Plattform auf eine zweite Fenster-basierte Plattform gemäß einem beispielhaften Ausführungsbeispiel der Erfindung darstellt;
3 ein beispielhaftes System darstellt, das gemäß der Erfindung eingerichtet ist, zum Portieren einer Clientseitigen Oberfläche von einer ersten Fenster-basierten Plattform auf eine zweite Fenster-basierte Plattform;
4 eine graphische Illustration von Aspekten der Erfindung ist; und
5 eine graphische Abbildung einer Fähigkeit eines Systems darstellt, das gemäß der Erfindung eingerichtet ist, zum dynamischen Einrichten von Beziehungen zwischen willkürlichen Instanzen von Objekten, die mit einer gegebenen Verhaltens-Spezifikation übereinstimmen, mit anderen Objekten, die mit der gleichen Verhaltens-Spezifikation übereinstimmen.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE
2 stellt ein beispielhaftes Flussdiagramm 200 zum Portieren eines Toolkits einer graphischen Benutzeroberfläche auf eine Fenster-basierte Plattform (z.B. von einer ersten Fenster-basierten Plattform auf eine zweite Fenster-basierte Plattform) dar. Eine erste Phase des Flussdiagramms aus 2 bildet eine Definitions-Phase, wobei das Toolkit unter Verwendung abstrahierter Benachrichtigungen einer Fenster-basierten Plattform definiert wird. Eine zweite Phase des Flussdiagramms aus 2 bildet eine Ausführungs-Phase, während der Benachrichtigungen von irgendeinem Fenster-basierten System als abstrakte Benachrichtigungen dargestellt werden, die zum Einrichten einer Wechselwirkung zwischen dem Fenster-basierten System und dem Toolkit der graphischen Benutzeroberfläche dargestellt werden.
Der Startblock 202 und die Schritte 204 und 206 bilden die Definitions-Phase, während die übrigen Schritte die Ausführungs-Phase bilden. Im Schritt 204 im Flussdiagramm aus 2 werden eine oder eine Mehrzahl ursprünglicher Benachrichtigungen (d.h. Ereignisse, Zustandsänderungen oder "Interessen"), die bezüglich einer ersten Fenster-basierten Plattform (d.h. der ursprünglichen Plattform) implementiert sind, in abstrahierte Benachrichtigungen übersetzt, zum Gebrauch beim Definieren der graphischen Benutzeroberfläche. Als ein Ergebnis kann jedes Objekt des Toolkits der graphischen Benutzeroberfläche mit einer abstrahierten Benachrichtigungen registriert werden, die von irgendeiner einer Mehrzahl von Fenster-basierten Plattformen empfangen wird.
Wie Fachleute verstehen werden, kann eine Benachrichtigung einem Ereignis, wie zum Beispiel einem Tastendruck, einer Aktivierung einer Schaltfläche, einem als Icon dargestellten Fenster und so weiter, entsprechen. Die Ereignisse, die von der Host-Fenster-basierten Plattform empfangen werden, zum Anzeigen von Zustandsänderungen sind gemäß beispielhaften Ausführungsformen in abstrakte Benachrichtigungen eingekapselt, die als funktionelle Signaturen von Objekt-Schnittstellendefinitionen dargestellt werden. Die funktionelle Signatur, die zum Darstellen einer abstrahierten Benachrichtigung verwendet wird, bildet eine Verhaltens-Spezifikation (z.B. formelle Eigenschaft oder ein formelles Protokoll), mit der Modell-, Darstellungs- und Steuerungsobjekt-Implementierungen in Übereinstimmung gebracht werden können.
Das Modell-Darstellungs-Steuerungs-Paradigma wird weiter zum Unterstützen einer Mehrzahl von Darstellungen, die dasselbe Interesse an einem einzelnen Modell oder einer einzelnen Steuerung ausdrücken, und zum Unterstützen einzelner Darstellungen, die Interessen an einer Mehrzahl von Modellen oder Steuerungen ausdrücken können, erweitert. Das heißt, eine Mehrzahl von Objekten der graphischen Benutzeroberfläche kann mit einer abstrakten Benachrichtigung registriert werden, die von jeder einer Mehrzahl von Fenster-basierten Plattformen empfangen werden kann.
In Schritt 206 der Definitions-Phase werden die Benachrichtigungen als eine Verhaltens-Spezifikation unter Verwendung willkürlicher Objektimplementierungen implementiert (z.B. in einer Implementationssprache der graphischen Benutzeroberfläche formell ausgedrückt). Das heißt, eine abstrahierte Implementierung ist in wenigstens einer Objektklasse der graphischen Benutzeroberfläche über die Verhaltens-Spezifikation implementiert. Jedoch kann die abstrahierte Benachrichtigung zwischen Objekten willkürlicher Implementierung innerhalb der objektorientierten graphischen Benutzeroberfläche weitergegeben werden.
Aufgrund der Implementierungen der abstrahierten Benachrichtigungen als Verhaltens-Spezifikationen, die von der Implementationssprache unterstützt werden, können willkürliche Objektinstanzen, die mit den Verhaltens-Spezifikationen übereinstimmen, über die Ausführungs-Laufzeit der graphischen Benutzeroberfläche willkürliche Beziehungen mit anderen Objekten, die mit der gleichen Verhaltens-Spezifikation übereinstimmen, dynamisch einrichten, wodurch ein hoch-portables System erzeugt wird. Insbesondere wird die Einkapselung von Ereignissen in funktionale Signaturen zum Implementieren einer Objekt-Übereinstimmungs-Verifikation ausgenutzt. Indem Ereignisse der ursprünglichen Fenster-basierten Systems als funktionale Signaturen eingekapselt werden, die beabsichtigt sind, mit Schnittstellendefinitionen von einem oder mehreren Objekten übereinzustimmen, kann eine Übereinstimmung von jedem gegebenen Objekt mit einem Ereignis, das von einem Fenster-basierten System empfangen wird, während der Ausführungs-Lebenszeit der graphischen Benutzeroberfläche verifiziert werden, in dem das Objekt eingesetzt wird.
Der Definitions-Phase folgend kann eine Ausführungs-Phase initiiert werden, wobei das Toolkit der graphischen Benutzeroberfläche mit einem Fenster-basierten System (d.h. der ursprünglichen Plattform, die zum Implementieren des Toolkits verwendet wird, oder jede andere Fenster-basierte Plattform) interagiert. Das wird durch Schritt 208 dargestellt, wobei eine Beziehung unter Verwendung einer Übereinstimmungs-Verifikation zwischen dem wenigstens einen Objekt mit anderen Objekten während der Laufzeit einer Anwendung dynamisch eingerichtet werden kann.
Übereinstimmung unter Objekten wird eingerichtet, indem die Übereinstimmung von jedem Objekt mit der abstrahierten Benachrichtigung unter Verwendung dynamischer (d.h. Laufzeit) Verbindungs-Mechanismen, wie z.B. jene, die durch solche Programmiersprachen wie Objective-C gezeigt werden, verifiziert werden. Diese dynamischen Verbindungs-Mechanismen werden zum formellen Definieren der Benachrichtigungen in der Implementierungs-Sprache der ursprünglichen Fenster-basierten Plattform verwendet. Als solche werden willkürliche Implementierungen von Modellen, Darstellungen und Steuerungen geschaffen, die mit einer willkürlichen Benachrichtigung übereinstimmen. Gemäß der Erfindung wird eine Übereinstimmungs-Verifikation unter Verwendung einer Laufzeit-Verhandlung mit einem willkürlichen Objekt eingerichtet.
Wenn einmal Beziehungen zwischen Objekten eingerichtet wurden, können die Objekte Benachrichtigungen, wie in Schritt 210 dargestellt, frei senden und empfangen. Wie Fachleute anerkennen werden, kann die Laufzeit-Verhandlung bezüglich irgendeiner Anzahl von willkürlichen Objekten durchgeführt werden, um dadurch dynamische polymorphe Beziehungen während der Ausführungs-Lebenszeit der objektorientierten graphischen Benutzeroberfläche einzurichten und zu zerstören, wie durch die Schritte 212 und 214 dargestellt wird.
Daher wird gemäß beispielhaften Ausführungsformen das Modell-Darstellungs-Steuerungs-Paradigma der graphischen Benutzeroberfläche in ein "Interessen"-Modell erweitert, wobei Darstellungen unterschiedliche Interessen an einer Mehrzahl von Modellen und Steuerungen ausdrücken können. Die vorangegangenen Schritte können mittels der Schleifen, die den Schritten 212 und 214 zugeordnet sind, für jede Anzahl von laufenden Benachrichtigungen wiederholt werden, bis die Ausführungszeit der graphischen Benutzeroberfläche im "Ende"-Schritt 216 vervollständigt ist.
Gemäß beispielhaften Ausführungsformen wird eine objektorientierte graphische Benutzeroberfläche leicht und dynamisch auf irgendeins einer Mehrzahl von Fenster-basierten Systemen portiert. Das heißt, ein Toolkit einer graphischen Benutzeroberfläche kann dynamisch von einer ursprünglichen Umgebung, für die es ursprünglich implementiert wurde (z.B. Microsoft^TM Windows), auf irgendeine andere Ziel-Fenster-basierte Plattform (z.B. das X-Windows-System^TM) portiert werden, ohne auf die herkömmlichen Schwierigkeiten zu treffen, die dem Wieder-Hosten eines Toolkits von einer Plattform auf eine andere zugeordnet sind.
Gemäß beispielhaften Ausführungsformen werden Abstraktionen zum Entfernen von Systemabhängigkeiten auf konzeptuellen Merkmalen und Implementierungs-Merkmalen der ursprünglichen Plattform verwendet, die kein direktes Gegenstück in der Ziel-Plattform aufweisen. Das Gegenstück-Implementierungs-Merkmal untergräbt ein herkömmliches Wieder-Hosten einer graphischen Benutzeroberfläche wesentlich, da die fraglichen Merkmale für das graphische Benutzer-Schnittstellensystem fundamental sind und in ihrer Anwendung innerhalb der Original-Implementierung weit verbreitet sind. Folglich ist das Ausmaß an Anstrengung, das typischerweise zum ursprünglichen Portieren des Implementierungskodes benötigt wird, und um ihn aufrechtzuerhalten, recht kostenintensiv. Jedoch werden wesentliche Unterschiede, gemäß beispielhaften Ausführungsformen der Erfindung, zwischen einer ursprünglichen Plattform und einer Ziel-Plattform unter Verwendung abstrahierter Verhaltens-Spezifikationen verwendet, um, zum Beispiel, eine Client-Seite von Zustandsänderungen von Fenster-basierten System, die die Client-Seite beeinflussen, zu benachrichtigen.
3 stellt ein beispielhaftes System zum Implementieren des Flussdiagramms aus 2 dar. Das beispielhafte Figur 3-System 300 weist eine Server-Seite 302, eine Client-Seite 304 und Peripherie-Eingänge 306 für die Server-Seite auf, wie zum Beispiel einen Tastatur- und/oder einen Maus-Eingang. Benachrichtigungen werden von der Fenster-basierten Plattform der Server-Seite mittels einer Interprozess-Kommunikationsverbindung 308 auf die graphische Benutzeroberfläche auf der Client-Seite übergeben. In dem Figur 3-System werden Ereignisse Fenster-basierter Plattformen, wie zum Beispiel eine Tastaturbetätigung, eine Betätigung eines als Icon dargestellten Fensters, oder eine Mausbewegung, von dem Client-seitigen Toolkit als abstrahierte Benachrichtigungen dargestellt (z.B. übersetzt).
Wie bezüglich 2 beschrieben, werden Ereignisse eines Fenster-basierten Systems nicht bloß auf ein anderes Objekt der graphischen Benutzeroberfläche übertragen, wie es bei herkömmlichen Systemen der Fall ist. Vielmehr muss jedes Objekt der graphischen Benutzeroberfläche anfangs ein Interesse während einer Laufzeit-Verhandlung mit Abstraktionen (d.h. Verhaltens-Spezifikationen) von einer oder einer Mehrzahl von Benachrichtigungen registrieren, die von einem Fenster-basierten System empfangen werden können. In dem Figur 3-Beispiel wird ein Ereignis-Zuteilungs-Objekt der graphischen Benutzeroberfläche zum Abbilden abstrahierter Benachrichtigungen von der Fenster-basierten Plattform auf eines oder eine Mehrzahl von willkürlichen Objekten der graphischen Oberfläche verwendet, die ein Interesse an einer bestimmten Benachrichtigung während einer Laufzeit-Verhandlung registrierten.
Im Betrieb bildet das Ereignis-Zuteilungs-Objekt, wenn es ein konkretes Ereignis von der Fenster-basierten Plattform der Server-Seite empfängt, dieses Ereignis in eine abstrakte Benachrichtigung ab, und übergibt die abstrakte Benachrichtigung auf ein oder eine Mehrzahl von Objekte der graphischen Benutzeroberfläche. Als ein Ergebnis werden alle Objekte, die sich ursprünglich selbst registrierten, dass sie ein Interesse in der Benachrichtigung haben, die Benachrichtigung empfangen. Daher bildet das Ereignis-Zuteilungs-Objekt einen Mechanismus zum Übergeben der Benachrichtigungen an Client-seitige Objekte.
Wie Fachleute anerkennen werden, kann die oben beschriebene Funktionalität auf jedem Computerlesbaren Medium implementiert werden. Zum Beispiel kann solch ein Medium in der graphischen Benutzeroberfläche 304 aus 3 resistent sein, oder in einem Computerlesbaren Medium resistent sein, das in Verbindung mit der graphischen Benutzeroberfläche 304 verwendet werden kann. In diesem letzteren Fall kann ein Computer-programmiertes Produkt 310 mit einem Computerprogramm zum Portieren eines Toolkits einer graphischen Benutzeroberfläche auf eine Fenster-basierte Plattform kodiert sein. Das Computer-programmierte Produkt kann zum Beispiel ein computerlesbares Speichermedium 312 zum Speichern von Daten, wie zum Beispiel den Abstraktionen der Benachrichtigungen von der ursprünglichen Fenster-basierten Plattform, und/oder eine Tabelle zum Abbilden von Ereignissen der Ziel-Fenster-basierten Plattform auf die verschiedenen abstrahierten Benachrichtigungen aufweisen.
Das Computer-programmierte Produkt 310 kann ferner einen Computercodemechanismus aufweisen, der in dem computerlesbaren Speichermedium eingebettet ist, um zu bewirken, dass das computerlesbare Speichermedium den Computercode ausführt. Zum Beispiel kann der Computercodemechanismus eine erste Computercodevorrichtung 312 aufweisen, die zum Empfangen einer ursprünglichen Benachrichtigung einer Zustandsänderung von einer Fenster-basierten Plattform eingerichtet ist, und eine zweite Computercodevorrichtung 314, die mit der ersten Computercodevorrichtung gekoppelt ist, zum Darstellen der ursprünglichen Benachrichtigung als einer abstrahierten Benachrichtigung während des Ausführens der graphischen Benutzeroberfläche. Wie vorher beschrieben, kann die ursprüngliche Benachrichtigung auf eine oder eine Mehrzahl von abstrahierten Benachrichtigungen abgebildet werden. Die abstrahierten Benachrichtigungen bilden, gemäß beispielhaften Ausführungsformen, eine Verhaltens-Spezifikation der ursprünglichen Benachrichtigung, die unabhängig von Implementierungen ist, die für sowohl die ursprüngliche als auch die Ziel-Fenster-basierte Plattform spezifisch ist.
In der beispielhaften Figur 3-Ausführungsform kann der Computercodemechanismus jede Anzahl von Computercodevorrichtungen aufweisen. Zum Beispiel kann eine dritte Computercodevorrichtung 318 zum Verifizieren einer Übereinstimmung wenigstens eines Objekts in dem Toolkit der graphischen Benutzeroberfläche mit der Verhaltens-Spezifikation, die von der abstrahierten Benachrichtigung gebildet wird, enthalten sein.
Die vorangegangenen Merkmale werden bezüglich dem folgenden Beispiel weiter dargestellt. Vorausgesetzt, dass ein Benutzer eine Taste auf der Tastatur des peripheren Eingangs 306 betätigt. Diese Aktion führt zu dem Senden eines Tastendruck-Ereignisses von der Fenster-basierten Plattform zu der graphischen Benutzeroberfläche auf der Client-Seite. Das Tastendruck-Ereignis weist zwei wesentliche Aspekte auf: (1) die Semantiken des Ereignisses; und (2) das Format, oder die Syntax, des Ereignisses. Das Tastendruck-Ereignis wird über die Interprozess-Kommunikationsverbindung 308 zu der Client-Seite übertragen.
Wenn das Tastendruck-Ereignis von der objektorientierten graphischen Benutzeroberfläche der Client-Seite empfangen wurde, schaut das Ereignis-Zuteilungs-Objekt auf die Information und bestimmt, wohin es weitergegeben werden soll. Das Ereignis-Zuteilungs-Objekt gibt dann die Information entsprechend weiter. Zum Beispiel wird das Ereignis-Zuteilungs-Objekt, wo der Tastendruck dem Niederdrücken der Buchstabe-"A"-Taste in Verbindung mit der "Shift"-Taste entspricht (d.h. um ein großes "A" zum Ausdruck zu bringen), beim Empfang der Tastendruck-Ereignis-Information eine Information, die ein "A" darstellt, zu einem Textfeld übergeben, das dann das Zeichnen eines "A" auf einer Anzeige implementiert. Das heißt, die Ereignisinformation wird als eine abstrakte Benachrichtigung dargestellt, die auf Objekte gerichtet sein kann, die ein Interesse an der abstrakten Benachrichtigung über eine Laufzeit-Verhandlung registriert haben.
Gemäß beispielhaften Ausführungsformen der Erfindung wurde das Toolkit bezüglich Benachrichtigungen von Ereignissen eingerichtet, die nur zum Darstellen von Verhaltens-Spezifikationen der Ereignisse abstrahiert wurden, die notwendigerweise in jeder Fenster-basierten Implementierung (d.h. einer funktionellen Signatur) existieren werden. Zum Beispiel sind die Semantiken und die Syntax eliminiert, die typischerweise in einem Ereignis eingekapselt sein würden, und dadurch die Portabilität des Ereignisses auf eine objektorientierte Oberfläche beschränken, die für eine unterschiedliche Fenster-basierte Plattform implementiert ist. Vielmehr ist das Ereignis abstrahiert, so dass es von Implementierungen unabhängig ist, die für irgendein bestimmtes Fenster-basiertes System spezifisch sind (d.h. es ist nicht länger für die ursprüngliche Plattform spezifisch, für die es ursprünglich beabsichtigt war). Nur Informationen der Benachrichtigung, die normal sind für: (1) die ursprüngliche Fenster-basierte Plattform, und (2) eine Ziel-Fenster-basierte Plattform, auf die das Toolkit portiert wurde, wird zum Erkennen und Korrelieren des Ereignisses mit einem Objekt an der Client-Seite verwendet. In dem vorangegangenen Beispiel kann eine übliche Information, die aus dem Ereignis extrahiert ist, als Verhaltens-Spezifikation zum Abbilden der Benachrichtigung auf ein Objekt auf der Client-Seite bloß darauf hinweisen, welcher Buchstabe niedergedrückt (d.h. "a") wurde.
Zum Darstellen des Abstrahierens eines Ereignisse wird ein vereinfachtes Beispiel bezüglich dem Kodieren von Ereignissen bereitgestellt, die einer Taste (z.B. Tastendruck-Ereignisse) zugeordnet sind. Die in dem Beispiel erklärten Code-Fragmente drücken Konstrukte aus, die Fachleuten ohne weiteres vertraut sind. Das Beispiel demonstriert das Abstrahieren von zwei unterschiedlichen konkreten Fenstersystem-Ereignissen in eine einzelne "abstrakte" Darstellung, und das Ausdrücken der Darstellung als einem formellen Protokoll zwischen Ereignis-Quellen und -Senken. Das Beispiel markiert die praktischen Anwendung der Erfindung beim Lokalisieren von Plattform-Abhängigkeiten, die darin resultieren, dass die Mehrheit des Rahmens der graphischen Benutzeroberfläche Plattform-unabhängig wird, und beim Erzeugen eines formellen Protokolls zwischen Ereignis-Quellen und -Senken, die in einem robusten dynamischen Ereignismodell resultieren, wo Beziehungen zwischen Quellen und Senken während der Laufzeit einer Anwendung modifiziert werden können.
Für dieses Beispiel betrachte das X-Windows-System^TM und das NeXTSTEP^TM-Windows-System, wobei eine konkrete Fenstersystem-Ereignisbenachrichtigung einer Maus, oder eines Zeigertaste-Drückereignisses existiert. In beiden Systemen wird diese Ereignisbenachrichtigung von dem Fenstersystem-Server über Plattform-abhängige Anwendungsprogramm-Schnittstellen und Interprozess-Kommunikationsverbindungen an eine Client-Anwendung geliefert, die zum Empfangen solcher Benachrichtigungen von dem System ausgewählt wurde. Jedoch weist jedes System semantisch unterschiedliche konkrete Darstellungen für solche Benachrichtigungen auf, sowohl bezüglich ihrer Syntax als auch ihrer Semantiken. Zum Beispiel wird in dem X-Windows-System das Ereignis durch die folgende C-Typendefinition und die folgenden Konstanten beschrieben, für Details siehe "The X Windows System", von Scheifler & Gettys, Digital Press, 1992, ISBN 1-55558-088-2):
In dem NeXTSTEP-Fenster-System ist die Taste wie folgt definiert (für Details siehe "NeXTSTEP General Reference (volume 2)" von NeXT Computer Inc., Addison Wesley, 1992 ISBN 0-201-62221-1):
Es ist aus den obigen Definitionen offensichtlich, dass sich die zwei Implementierungen signifikant in sowohl ihrer konkreten Syntax als auch ihrer Semantik unterscheiden. Daher können diese Definitionen, ohne umfassende bedingte Kompilationsdirektiven zum Erzeugen von parallelen Implementierungen für jedes Ziel-Fenstersystem, nicht in ihrer ursprünglichen Form zum Erzeugen einer Implementation eines Toolkits einer graphischen Benutzeroberfläche verwendet werden, die zwischen beiden Plattformen portierbar ist. Jedoch kann, in Übereinstimmung mit beispielhaften Ausführungsformen der Erfindung, durch das Lokalisieren des Plattform-abhängigen Codes in einzelne, oder relativ wenige Komponenten des Toolkits, eine gemeinsame Definition für ein Tastendruck-Ereignis abstrahiert werden, die über beide Fenstersysteme hinweg portierbar sein wird, was die riesige Mehrheit des Codes, der die Toolkit-Plattform implementiert, unabhängig macht.
Die oben definierten konkreten Fenstersystem-Benachrichtigungen gegeben, ist ein erster Schritt einer Implementierung gemäß den beispielhaften Ausführungsformen, eine gemeinsame Abstraktion der konkreten Ereignisse zu definieren. Dieses Beispiel wird die Objective-C-Programmiersprache verwenden, da das die Implementierungs-Sprache ist, die beim Programmieren von Systemen wie zum Beispiel NeXTSTEP und OpenStep (für das X-Windows-System) verwendet wird. Ein abstraktes Ereignis wird zum Definieren des Ereignistyps, seiner Quelle und anderer fundamentaler Informationen, die allen Ereignis-Abstraktionen gemeinsam sind, verwendet:
Als Nächstes wird das Konzept eines Ereignisses eingeführt, das einem "Fenster" zugeordnet ist; das heißt, ein Konzept, das für beide Ziel-Plattformen gewöhnlich ist:
Schließlich wird eine bestimmte Abstraktion für ein Tastendruck-Ereignis definiert, das Informationen aufweist, die für beide Ziel-Plattformen relevant sind, aber mit einer synthetisierten Syntax und Semantiken, die von denjenigen verschieden sind, die in den konkreten Ereignissen gefunden werden:
Eine Hierarchie von abstrakten Fenster-System-Ereignisobjekten, die für Fachleute erkennbar ist, wurde daher definiert, indem sie eine Synthese der Information aufweisen, die in den konkreten Ereignissystemen des X-Fenstersystems und des NeXTSTEP-Fenstersystem für Maustasten-Drückereignisse definiert wurden. Als Nächstes wird eine Schnittstelle zu einer Objekthierarchie definiert, die einem willkürlichen Objekt (dem Beobachter oder der Senke) erlaubt, ein Interesse am Beobachten von Benachrichtigungen von einem anderen Objekt (der Beobachtete oder die Quelle) über ein bestimmtes Protokoll oder eine bestimmte Schnittstellen-Spezifikation auszudrücken:
Ein Satz von Protokollen wird dann definiert auf der Basis der abstrakten Ereignisdefinitionen. Diese Protokolle beschreiben die formelle Schnittstelle zwischen willkürlichen Objekten, die Benachrichtigungen von Zustandsänderungen des Systems ausgeben und empfangen können, wie durch die abstrakten Ereignisbeschreibungen dargestellt ist, die oben detailliert sind.
Indem diese abstrakten Protokolle definiert wurden, kann ein "ButtonControl"-Objekt definiert werden, dass diese Benachrichtigungen empfangen will:
Relevante Teile der Implementierung werden dann bereitgestellt:
Dieses Verfahren erzeugt eine neue Instanz einer ButtonControl. Als Nebeneffekt registriert sich ButtonControl bei dem "eventDispatcher"-Objekt des Toolkits selbst zum Empfangen von Benachrichtigungen von ButtonPress-Ereignissen.
self – [super init];
Jetzt ist dieses Objekt bei dem Fenstersystem-Ereignis-Zuteiler registriert, um die Protokoll-Benachrichtigungen zu empfangen.
Diese Methode wird zum Freimachen von Instanzen der ButtonControl aufgerufen. Als ein Nebeneffekt entfernt sich die ButtonControl selbst aus dem eventDispatcher-Objekt:
Indem die Toolkit-Objekte der graphischen Benutzeroberfläche bezüglich dieser abstrakten Protokolle definiert wurden, ist die "SystemEventDispatcher"-Klasse implementiert. Für das Beispiel ist das die einzige Klasse in dem Ereignis-Subsystem des Toolkits der graphischen Benutzeroberfläche, die Fenstersystem-abhängigen Code aufweist:
Eine Klasse-Privat-Schnittstelle zu dem SystemEventDispatcher ist definiert, die den ganzen Plattform-abhängigen Kode einkapselt:
Eine einfaches beispielhaftes "Haupt"-Programm demonstriert eine ButtonControl, die abstrakte Benachrichtigungen von Tastenbetätigungen von dem SystemEventDispatcher erhalten wird:
Gemäß der Erfindung schafft die abstrakte Benachrichtigung von Verhaltens-Spezifikationen in Verbindung mit dem Ereignis-Zuteilungs-Objekt eine Fähigkeit zu Laufzeit-Verhandlung, ob ein bestimmtes Objekt in dem Toolkit der graphischen Benutzeroberfläche mit der Benachrichtigung übereinstimmt, wie bezüglich Schritt 208 aus 2 beschrieben ist. Die Fähigkeit zum Bereitstellen von Laufzeit-Übereinstimmungs-Tests, die hier als Laufzeit- Verhandlung bezeichnet wird, erlaubt es Beziehungen zwischen Objekten in einem Darstellungsfeld gegenüber Objekten in einem Steuerungs- oder Modell-Feld sich dynamisch während der Ausführungs-Laufzeit des Systems zu ändern. In dem beispielhaften Figur 3-System erlaubt Laufzeit-Verhandlung, das Beziehungen über ein Um-Abbilden innerhalb des Ereignis-Zuteilungs-Objekts dynamisch geändert (d.h. eingerichtet und ent-eingerichtet) werden.
Zum besseren Darstellen der vorangegangenen Merkmale und insbesondere des Laufzeit-Verhandlungs-Merkmals, betrachtet man zwei anonyme Objekte: eines in einer Fenster-basierten Plattform und das andere in der graphischen Benutzeroberfläche. Die zwei Objekte wissen nur von der Existenz des anderen und sonst nichts. Die zwei Objekte werden hierin als ein "Anbieter" und als ein "Abnehmer" bezeichnet. Ein Anbieter 402 und ein Abnehmer 404 sind in 4 graphisch dargestellt.
Angenommen, dass die Verhaltens-Spezifikation des Anbieters ein Protokoll aufweist, das der Abnehmer (z.B. der Abnehmer einer Client-seitigen Anwendung) verwenden will, wie zum Beispiel ein Tastendruck-Ereignis, muss der Anbieter fähig sein, eine Benachrichtigung von Tastendruck-Ereignissen an den Benutzer zu exportieren. Der Benutzer weiß von der Existenz des Anbieters und ist am Eintreten in eine Laufzeit-Verhandlung zum Verifizieren seiner Fähigkeit zum Übergeben von Informationen (z.B. Benachrichtigungen) an den Anbieter interessiert. Der Abnehmer muss daher wissen, ob der Anbieter mit den Verhaltens-Spezifikationen des Abnehmers übereinstimmt.
Diese Startposition vorausgesetzt, wird die Laufzeit-Verhandlung von dem Abnehmer initiiert, der beim Anbieter nachfragt, ob er die Verhaltens-Spezifikation "A" (d.h. das Protokoll, das der Abnehmer verwenden will) anbietet. Falls der Anbieter die Verhaltens-Spezifikation "A" nicht anbietet, unterbricht der Abnehmer seinen Versuch zum Einrichten einer Informationsübertragung mit dem Anbieter. Falls jedoch der Anbieter anzeigt, dass er die Verhaltens-Spezifikation "A" anbietet, registriert der Abnehmer bei dem Anbieter ein Interesse an der Verhaltens-Spezifikation, die "A" entspricht. Da der Anbieter diese Verhaltens-Spezifikation unterstützt, informiert der Abnehmer den Anbieter, dass er in dieser Verhaltens-Spezifikation mit dem Anbieter teilnehmen will, so dass der Anbieter Informationen an eine Darstellung des Abnehmers übertragen kann, wann immer Zustandsänderungen auftreten, die dieser Verhaltens-Spezifikation zugeordnet sind.
Wenn der Abnehmer bestätigt, dass er bei der Verhaltens-Spezifikation teilnehmen will und mit dem Anbieter zum Empfangen von Benachrichtigungen bezüglich Zustandsänderungen verhandeln will, fragt der Anbieter bei dem Abnehmer nach, ob er mit der Verhaltens-Spezifikation "A" übereinstimmt (d.h. sich daran hält). Vorausgesetzt, dass der Abnehmer nicht mit der Verhaltens-Spezifikation "A" übereinstimmt, wird eine Beziehung (d.h. ein Laufzeit-Vertrag) eingerichtet, so dass abstrakte Benachrichtigungen zwischen diesen zwei Objekten fließen können.
Gemäß beispielhaften Ausführungsformen können sich der Anbieter und/oder der Abnehmer zu jeder Zeit während der Ausführungszeit des Systems von der Beziehung zurückziehen. Das heißt, jedes Objekt kann sich selbst aus der Beziehung entfernen. Solch ein Entfernen kann wünschenswert sein, falls zum Beispiel der Abnehmer seine Aufgabe komplettiert hat und von der Beziehung zurücktritt. Falls irgendein Objekt von der Beziehung zurücktritt, dann können neue Beziehungen in der bereits beschriebenen Weise eingerichtet werden.
Nachdem eine beispielhafte Laufzeit-Verhandlung beschrieben wurde, wird die Aufmerksamkeit jetzt auf ein beispielhaftes Abbilden von Objekten aufeinander gemäß der Erfindung gerichtet. In dieser Hinsicht wird auf 5 Bezug genommen, wobei ein Ereignis, das der Aktivierung einer Drucktaste auf einer Anzeige eines Fenster-basierten Systems entspricht, zum Auslösen eines Ereignisses zu verwenden ist. Gemäß beispielhaften Ausführungsformen wird eine konkrete Information, die diesem Ereignis entspricht, von der Fenster-basierten Plattform mittels der graphischen Benutzeroberfläche in der oben beschriebenen Weise in eine abstrakte Information abgebildet. Hier ist eine Drucktaste 502 in einer Client-seitigen objektorientierten graphischen Benutzeroberfläche als ein Objekt dargestellt, das sowohl einer Darstellung als auch einer Steuerung des Modell-Darstellungs-Steuerungs-Paradigmas entspricht. Als Darstellung ist sie für das Zeichnen der Drucktaste auf einer Anzeige verantwortlich. Als Steuerung beschreibt sie Zustandsänderungen, die auftreten, um anzuzeigen, dass die Drucktaste niedergedrückt oder losgelassen ist.
Vorausgesetzt, dass die Verhaltens-Spezifikation für die Drucktaste ein Protokoll "Tastenklicks" aufweist, das zwei Nachrichten erzeugt: (1) Drucktaste niedergedrückt; und (2) Drucktaste losgelassen. In dem Fall einer Drucktaste kann die abstrahierte Benachrichtigung ferner Informationen aufweisen, die die Zeit identifizieren, zu der sie niedergedrückt wurde (d.h. ein Timestamp), Tastatur-Modifizierer, die mit der Drucktaste aktiviert werden (z.B. Aktivierung der Shift-Taste mit einer Buchstaben-Taste), oder die Position einer Maus zum Zeitpunkt der Drucktaste-Aktivierung (z.B. wo die Taste auf der Maus aktiviert wurde). Ferner vorausgesetzt, dass das Ereignis-Zuteilungs-Objekt das "Tastenklicks"-Protokoll anbietet. Während einer Laufzeit-Verhandlung fragt die Drucktaste bei dem Ereignis-Zuteilungs-Objekt an, ob es das "Tastenklicks"-Protokoll anbietet. Falls das Ereignis-Zuteilungs-Objekt 504 dieses Protokoll anbietet, antwortet die Drucktaste, indem angezeigt wird, dass sie in dem "Tastenklicks"-Protokoll mit dem Ereignis-Zuteilungs-Objekt teilnehmen will. Die Drucktaste registriert daher ein "Interesse" in dem "Tastenklicks"-Protokoll.
Das Ereignis-Zuteilungs-Objekt fragt als nächstes die Drucktaste ab, inwieweit sie mit dem "Tastenklicks"-Protokoll übereinstimmt. Falls die Drucktaste bejahend antwortet, wird eine Beziehung eingerichtet. Als solche benachrichtigt es dann die Drucktaste von einem "Drucktaste-Niederdrückungs"-Ereignis, wenn das Ereignis-Zuteilungs-Objekt ein Tastendruck-Ereignis von der Fenster-basierten Plattform 506 empfängt.
Da beispielhafte Ausführungsformen der Erfindung Ereignisse abstrahieren, können, natürlich, bestimmte Informationen, die implementations-spezifisch sind, verloren gehen. Jedoch wird zum Ausgleich für jede verlorene Information eine verbesserte Portabilität des Systems erzielt. Ferner kann, wie Fachleute erkennen werden, jede implementations-spezifische Information erhalten bleiben, indem diese in der Client-seitigen objektorientierten graphischen Benutzeroberfläche für die Plattform-spezifische Implementierung spezifisch kodiert wird.
Wieder mit Bezugnahme auf 5 werden Fachleute anerkennen, dass eine 1:1-Beziehung zwischen Objekten nicht aufrechterhalten zu werden braucht, wenn Benachrichtigungen wie oben beschrieben abstrahiert sind. Vielmehr können alle Objekte mit einem "Interesse" in der abstrakten Benachrichtigung abgebildet werden zum Empfangen der Benachrichtigung. Zum Beispiel kann, wo die abstrakte Benachrichtigung der Ausgabe einer Stopuhr 508 entspricht, ein zugeordnetes Protokoll "Tick" eingerichtet werden, um das Ereignis-Zuteilungs-Objekt jedes Mal zu informieren, wenn eine Sekunde vergeht. Ein separates "Zeitablauf"-Protokoll kann dann zwischen dem Ereignis-Zuteilungs-Objekt und allen Objekten (z.B. Objekten 510 und 512) mit einem "Interesse" am Verfolgen von Zeit eingerichtet werden. Solche Objekte können, zum Beispiel, eine Uhr auf der Anzeige, eine Börsenkursticker-Einspeisung, eine Stopuhr und so weiter sein. Die Darstellungen von allen Objekten mit einem Interesse am Verfolgen von Zeit werden daher über das "Zeitablauf"-Protokoll von Änderungen in der Zeit benachrichtigt. Folglich stellt das "Zeitablauf"-Protokoll eine Beziehung des Ereignis-Zuteilungs-Objekts mit allen Objekten mit einem Interesse am Verfolgen von Zeit dar, obwohl das "Tick"-Protokoll eine 1:1-Beziehung mit dem Ereignis-Zuteilungs-Objekt aufweist.
Fachleute werden anerkennen, dass beispielhafte Ausführungsformen der Erfindung auf viele unterschiedliche Weisen implementiert werden können. Zum Beispiel können beispielhafte Ausführungsformen zum Portieren von Merkmalen einer graphischen Benutzeroberfläche eines Fenster-basierten System verwendet werden, die entweder mittels Software oder mittels Hardware implementiert sind. Ferner werden Fachleute anerkennen, dass Merkmale der Erfindung zum Portieren eines Toolkits einer graphischen Benutzeroberfläche verwendet werden können, ungeachtet davon, wo das/die Fenster-basierte(n) System e) liegt/liegen, obwohl beispielhafte Ausführungsformen im Kontext eines Client-Server-Systems beschrieben wurden.

Claims

Verfahren zum Portieren eines Toolkits einer graphischen Benutzeroberfläche auf eine Fenster-basierte Plattform, das den Schritt aufweist: Empfangen einer ursprünglichen Benachrichtigung eines Zustandwechsels von einer Fenster-basierten Plattform, und gekennzeichnet ist durch das Aufweisen der Schritte: Darstellen der ursprünglichen Benachrichtigung als einer abstrahierten Benachrichtigung während des Ausführens der graphischen Benutzeroberfläche, wobei die abstrahierte Benachrichtigung eine Verhaltens-Spezifikation der ursprünglichen Benachrichtigung bildet, die von Implementierungen unabhängig ist, die für die Fenster-basierte Plattform spezifisch sind; und Einrichten der graphischen Schnittstelle zum Verifizieren einer Übereinstimmung von wenigstens einem Objekt in dem Toolkit der graphischen Benutzeroberfläche mit der Verhaltens-Spezifikation während des Ausführens der graphischen Benutzeroberfläche.
Verfahren gemäß Anspruch 1, wobei der Schritt des Darstellens einer ursprünglichen Benachrichtigung ferner aufweist einen Schritt des: Definierens der Verhaltens-Spezifikation als einer funktionalen Signatur eines Ereignisses einer Fenster-basierten Plattform.
Verfahren gemäß Anspruch 1, ferner aufweisend den Schritt des: dynamischen Registrierens wenigstens einer abstrahierten Benachrichtigung mit wenigstens einem Objekt des Toolkits während einer Laufzeit-Ausführung der graphischen Benutzeroberfläche.
Verfahren gemäß Anspruch 3, wobei der Schritt des Registrierens ferner aufweist einen Schritt des: dynamischen Registrierens der abstrahierten Benachrichtigung mit einer Mehrzahl von Objekten des Toolkits während einer Laufzeit-Ausführung des Toolkits der graphischen Benutzeroberfläche.
Toolkit einer graphischen Benutzeroberfläche zum Gebrauch mit einer Fenster-basierten Plattform, wobei das Toolkit einer graphischen Benutzeroberfläche aufweist: einen Eingang zum Empfangen ursprünglicher Benachrichtigungen von Zustandsänderungen von einem Fenster-basierten Plattform, und gekennzeichnet ist durch Aufweisen: einer hierarchischen Sammlung von Objekten die Beziehungen mit Abstraktionen der ursprünglichen Benachrichtigungen einrichtet, die als abstrahierte Benachrichtigungen dargestellt sind, wobei die abstrahierten Benachrichtigungen Verhaltens-Spezifikationen der ursprünglichen Benachrichtigungen bilden, die von Implementierungen unabhängig ist, die für die Fenster-basierte Plattform spezifisch sind; und wobei wenigstens eine der abstrahierten Benachrichtigungen mit einer Mehrzahl von Objekten der hierarchischen Sammlung von Objekten registriert ist.
Toolkit einer graphischen Benutzeroberfläche gemäß Anspruch 5, ferner aufweisend: einen Ausgang zum Senden der abstrahierten Benachrichtigungen an die Fenster-basierte Plattform.
Toolkit einer graphischen Benutzeroberfläche gemäß Anspruch 5, wobei die hierarchische Sammlung zum dynamischen Registrieren von wenigstens einer abstrahierten Benachrichtigung mit wenigstens einem Objekt der hierarchischen Sammlung während einer Laufzeit-Ausführung der graphischen Benutzeroberfläche eingerichtet ist.
Toolkit einer graphischen Benutzeroberfläche gemäß Anspruch 7, wobei die hierarchische Sammlung zum Verifizieren einer Übereinstimmung des wenigstens einen Objekts zu der wenigstens einen abstrahierten Benachrichtigung während einer Laufzeit-Ausführung des Toolkits der graphischen Benutzeroberfläche eingerichtet ist.
Toolkit einer graphischen Benutzeroberfläche gemäß Anspruch 5, wobei das Toolkit in einer Client-Seite eines Client/Server-Netzwerks eingerichtet ist.
Toolkit einer graphischen Benutzeroberfläche gemäß Anspruch 5, wobei die ursprünglichen Benachrichtigungen von Zustandsänderungen in der Fenster-basierten Plattform für Datenmodelle, Darstellungen und Steuerungen vorgesehen sind, die zum Definieren von Wechselbeziehungen zwischen den Objekten der hierarchischen Sammlung verwendet werden.
Computer-lesbares Medium, das ein Programm von Befehlen kodiert, die zum Ausführen eines Verfahrens zum Portieren eines Toolkits einer graphischen Benutzeroberfläche auf eine Fenster-basierte Plattform verwendet wird, das die Schritte aufweist: Empfangen einer ursprünglichen Benachrichtigung eines Zustandwechsels von einer Fenster-basierten Plattform; Darstellen der ursprünglichen Benachrichtigung als einer abstrahierten Benachrichtigung während des Ausführens der graphischen Benutzeroberfläche, wobei die abstrahierte Benachrichtigung eine Verhaltens-Spezifikation der ursprünglichen Benachrichtigung bildet, die von Implementierungen unabhängig ist, die für die Fenster-basierte Plattform spezifisch sind; und Einrichten der graphischen Schnittstelle zum Verifizieren einer Übereinstimmung von wenigstens einem Objekt in dem Toolkit der graphischen Benutzeroberfläche mit der Verhaltens-Spezifikation während des Ausführens der graphischen Benutzeroberfläche.
Computer-lesbares Medium gemäß Anspruch 11, das ferner programmiert ist zum Einrichten eines Schrittes des: Einschließens der abstrahierten Benachrichtigung in wenigstens einer Objektklasse der graphischen Benutzeroberfläche.
Computer-lesbares Medium gemäß Anspruch 11, das ferner programmiert ist zum Einrichten eines Schrittes des: Verifizierens einer Übereinstimmung von wenigstens einem Objekt in dem Toolkit der graphischen Benutzeroberfläche mit der Verhaltens-Spezifikation während des Ausführens der graphischen Benutzeroberfläche.