JPH113237A

JPH113237A - 複数のプラットフォーム間でのオブジェクト指向インタフェースの移植性を向上させる方法および装置

Info

Publication number: JPH113237A
Application number: JP20433397A
Authority: JP
Inventors: Laurence P G Cable; ローレンス・ピイ・ジイ・ケーブル
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1996-07-30
Filing date: 1997-07-30
Publication date: 1999-01-06
Also published as: EP0822484A3; DE69734545T2; DE69734545D1; EP0822484A2; US5999728A; EP0822484B1

Abstract

(57)【要約】【課題】オブジェクト指向グラフィカル・ユーザ・イ
ンタフェース処理系をあるネイティブ・ウィンドウ・ベ
ース・プラットフォームまたは環境から他のウィンドウ
・ベース・プラットフォームまたは環境に再ホストまた
は移植できるようにする。【解決手段】ネイティブ環境で行われる通知（たとえ
ば、事象や、状態変化や、「関心」）を動作仕様として
抽象化する。この動作仕様は、グラフィカル・ユーザ・
インタフェースの実行継続期間中に、特定のクライアン
ト側オブジェクトが、異なるオブジェクトに関連付けら
れたサーバ側事象から抽象化された動作仕様に適合して
いるかどうかを判定するために、適合性交渉の一部とし
て使用することができる。適合性交渉が成功した場合、
事象のネイティブ処理系を使用するのではなく、抽象化
通知がオブジェクトの特定のインスタンス間を流れシス
テムの状態をモデル化する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、全般的には、ネッ
トワーク・ベースのグラフィカル・ユーザ・インタフェ
ースに関する。詳細には、本発明は、オブジェクト指向
インタフェースを、様々な異なるハードウェア・プラッ
トフォームまたはソフトウェア・プラットフォーム、あ
るいはその両方を統合するクライアント／サーバ環境と
共に使用できるように、このインタフェースの複数のプ
ラットフォーム間での移植性および保守容易性を向上さ
せるシステムおよび方法に関する。

【０００２】

【従来の技術】既知のグラフィカル・ユーザ・インタフ
ェースは、アプリケーション開発者に、スクロール・バ
ー、プッシュ・ボタン、テキスト入力フィールドなどの
オブジェクトの集合を含むアプリケーション・プログラ
ム・インタフェース（ＡＰＩ）を備えている。オブジェ
クト指向グラフィカル・ユーザ・インタフェース（ＧＵ
Ｉ）は通常、これらのオブジェクトの階層化集合を「ツ
ールキット」内に含んでいる。

【０００３】システム内のグラフィカル・ユーザ・イン
タフェースの動作は、クライアント／サーバ環境のクラ
イアントのオブジェクトとウィンドウ・ベースのシステ
ム・サーバのオブジェクトとの間の対話として定義され
る。オブジェクト間の定義された対話を表すために使用
されるパラダイムは、オブジェクト対話の「モデル・ビ
ュー・コントローラ」（ＭＶＣ）パラダイムとも呼ばれ
る。モデル・ビュー・コントローラ・パラダイムは、シ
ステムの少なくとも一部（たとえば、システムのタイ
マ）内で状態の変化がどのように起こるかと、このよう
な状態変化（クロックの遅延など）を観測することに対
する関心を確立しているシステムの他の部分に、その変
化をどのように伝達または反映するかを形式的に定義す
る。コントローラは、モデルに応答して実施される状態
変化がどのようにビューに影響を及ぼすかを定義する１
組の規則とみることができる。モデル・ビュー・コント
ローラ・パラダイムを使用すると、ツールキットは、グ
ラフィカル・ユーザ・インタフェースを実施するモデ
ル、ビュー、コントローラの階層化集合とみることがで
きる。

【０００４】図１Ａは、モデル１０２とビュー１０４と
コントローラ１０６との間の対話の抽象表現を示してい
る。この場合、モデルは、記憶されているデータとみる
ことができ、コントローラは、モデルとビューが対話す
るための規則とみることができる。図１Ａの矢印１０８
は、最も一般的なモデル・ビュー・コントローラ・パラ
ダイムを示し、この場合、状態変化は両方向に流れるこ
とができる。

【０００５】当業者には、図１Ｂを参照すると理解され
るように、モデルとビューとコントローラが概念的には
異なるものであっても、処理系においてモデルとビュー
とコントローラとの間の区別がなくなることが多い。た
とえば、オブジェクト指向グラフィカル・ユーザ・イン
タフェースのスクロール・バー・オブジェクト１１２
は、コントローラとビューの両方を表すことができる。
図１Ｂのスクロール・バーは、たとえば、テキスト・ビ
ュー１１６に表示されているテキスト・ファイル１１４
の割合（すなわち、０％ないし１００％）をグラフィカ
ルに表すときはビューである。スクロール・バーは、モ
ニタ上のスクロール・バーの現在の位置を表示するため
にマウスによって生成される一連の制御事象に応答す
る。本明細書では、「事象」は、１つのウィンドウ・ベ
ース・プラットフォーム上の処理系に特有のものであ
り、移植性が必要なウィンドウ・ベースのプラットフォ
ーム間では概念的に汎用である状態変化の情報を表す。

【０００６】この例では、スクロール・バー１１２はコ
ントローラであってもよく、マウスの移動に応答してテ
キスト・ファイル１１４から得たテキストの表示の更新
を開始または制御するために使用される。すなわち、ス
クロール・バーを「クリック」し、その画像１１２を垂
直に移動させることによって、スクロール・バーはコン
トローラとして働き、スクロール・バーがディスプレイ
内を上下に移動するにつれてスクロール・バーを連続的
に再描画し、それによってスクロール・バーの表示、し
たがって表示されるファイル１１４の内容を変更するた
めに送信され、ビュー１１６によって使用される通知の
ストリームを生成する。図１Ｂの例では、モデル（すな
わち、テキスト・ファイル１１４）は、マウスのユーザ
作動が、スクロール・バー、したがってテキスト・ファ
イルの表示ビューにどのように影響を及ぼすかを定義す
る。

【０００７】Massachusetts Institute of Technology
から市販されているＵＮＩＸベースのＸ−Ｗｉｎｄｏｗ
Ｓｙｓｔｅｍ^TMなど通常のウィンドウ・ベースのシス
テムでは、システム内の状態変化は、上記でモデル・ビ
ュー・コントローラ・パラダイムに関して説明した方式
と同様な方式で「事象」を介してグラフィカル・ユーザ
・インタフェース・クライアントに伝達される。ウィン
ドウ・ベースのシステムがオブジェクト指向グラフィカ
ル・ユーザ・インタフェース・ツールキットに関連付け
られると、ツールキットは、ウィンドウ・システム事象
を介して報告されるウィンドウ・ベースのシステムの状
態変化をオブジェクト指向モデル・ビュー・コントロー
ラ上にマップする。ウィンドウ・ベースのシステムの事
象によって、グラフィカル・ユーザ・インタフェースの
オブジェクト上でメソッドが呼び出され、メソッドに状
態変化が通知される。

【０００８】モデルとビューとコントローラとの間の関
係の定義は、オブジェクト「クラス」の処理系特有の定
義によって確立される。アプリケーションの継続期間中
にモデル、ビュー、コントローラの特定のインスタンス
間の関係を動的に指定することができるが、このような
関係は、モデルおよびビューの特定の処理系のインスタ
ンス間の割り当てを用いる場合を除いて、クライアント
側アプリケーションの実行時に変更することはできな
い。これはたとえば、オブジェクト指向システムがＣ＋
＋などのプログラミング言語で実施される場合にそうで
ある。

【０００９】オブジェクト間の対話は、特定のウィンド
ウ・ベース環境と共に使用されるプラットフォーム特有
の処理系として開発されるモデル・ビュー・コントロー
ラによって定義されるので、ツールキットをあるウィン
ドウ・ベース・プラットフォームから他のプラットフォ
ームに容易に移植することはできない。すなわち、ある
ツールキットが実施されたネイティブ・ウィンドウ・ベ
ース・プラットフォームに存在する「事象」の処理系
は、そのツールキットを移植する他のウィンドウ・ベー
ス・プラットフォームと著しく異なることがある。さら
に、ネイティブ処理系は、他の環境への移植性を目標と
して設計されるわけではなく、そのため、プラットフォ
ーム依存性は通常、ネイティブ・プラットフォーム内で
はローカライズまたは抽象化されない。あるプラットフ
ォームに関して定義される「事象」の処理系は通常、与
えられる情報（すなわち、異なる意味）と、そのような
情報を与えるために用いられるフォーマット（すなわ
ち、異なる構文）の点で他のプラットフォームとは異な
る。したがって、あるウィンドウ・ベース・プラットフ
ォームに関して定義されたツールキットを他のウィンド
ウ・ベース・プラットフォームと共に使用するために改
定しなければならないコンピュータ・コードの量は過度
であり、実際的なものではない。そのため、オブジェク
ト指向グラフィカル・ユーザ・インタフェースの、ある
ネイティブ・ウィンドウ・ベース・プラットフォームか
ら他のウィンドウ・ベース・プラットフォームへの移植
（たとえば、ＮｅＸＴＣｏｍｐｕｔｅｒＣｏｍｐａ
ｎｙのＮｅＸＴＳＴＥＰ環境からＸＷｉｎｄｏｗＳｙ
ｓｔｅｍ^TMなど他のウィンドウ・ベース・プラットフォ
ーム上への移植）には顕著な問題が存在する。

【００１０】

【発明が解決しようとする課題】したがって、プラット
フォーム依存性をオブジェクト指向グラフィカル・ユー
ザ・インタフェースと共に使用できるようにローカライ
ズし、抽象化する方法を開発することが望ましい。そこ
ではオブジェクトの対話が抽象モデル・ビュー・コント
ローラに対して定義される。たとえば、オブジェクト指
向グラフィカル・ユーザ・インタフェースのツールキッ
トを表すために使用されるコードの主要な部分を変更で
きないようにし、したがって様々なウィンドウ・ベース
・プラットフォームに容易に移植することができるよう
に、ウィンドウ・ベースのシステムから受け取る事象を
抽象化することが望ましい。

【００１１】

【課題を解決するための手段】本発明は、オブジェクト
指向グラフィカル・ユーザ・インタフェース処理系をあ
るネイティブ・ウィンドウ・ベース・プラットフォーム
または環境から他のウィンドウ・ベース・プラットフォ
ームまたは環境に再ホストまたは移植できるようにする
ことに関する。例示的な実施態様によれば、ネイティブ
環境で行われる通知（たとえば、事象や、状態変化や、
「関心」）は動作仕様として抽象化される。このような
動作仕様（すなわち、トレイト（trait ）またはプロト
コル）は、グラフィカル・ユーザ・インタフェースの実
行継続期間中に、特定のクライアント側オブジェクト
が、異なるオブジェクトに関連付けられたサーバ側事象
から抽象化された動作仕様に適合しているかどうかを判
定するために、適合性交渉の一部として使用することが
できる。適合性交渉が成功した場合、事象のネイティブ
処理系を使用するのではなく、抽象化通知がオブジェク
トの特定のインスタンス間を流れ、システムの状態をモ
デル化することができる。実行継続期間中に、他のオブ
ジェクトは、抽象化通知を受取るために、抽象化通知を
含むオブジェクト・クラスとの関係を動的に確立するこ
とができる。

【００１２】本発明の例示的な実施態様は、オブジェク
ト指向グラフィカル・ユーザ・インタフェースのツール
キット全体にわたってプラットフォーム処理系依存性を
分離し、ローカライズする抽象化層をネイティブ処理系
内に作成する。例示的な実施態様は、クライアント側モ
デル・ビュー・コントローラ・パラダイムと、ユーザ・
インタフェース内のこのパラダイムのアプリケーション
を著しく拡張し、移植タスクの規模を縮小し、いくつか
の異なるウィンドウ・ベース・プラットフォーム間での
インタフェースの移植を可能にする。

【００１３】一般的に言えば、本発明の例示的な実施態
様は、ウィンドウ・ベースのプラットフォームから状態
変化のネイティブ通知を受取るステップと、グラフィカ
ル・ユーザ・インタフェースの実行時に、前記ウィンド
ウ・ベースのプラットフォームに特有の処理系とは独立
のネイティブ通知の動作仕様を構成する抽象化通知とし
て前記ネイティブ通知を表すステップとを含む、グラフ
ィカル・ユーザ・インタフェースのツールキットをウィ
ンドウ・ベースのプラットフォームに移植する方法およ
び装置に関する。本発明によれば、モデル、ビュー、コ
ントローラの任意の処理系は任意に、抽象化通知に適合
する。オブジェクト指向グラフィカル・ユーザ・インタ
フェース・ツールキットに定義されている抽象化通知
は、グラフィカル・ユーザ・インタフェースのプログラ
ミング言語を使用して実施することができる。したがっ
て、グラフィカル・ユーザ・インタフェースの一部とし
て確立されたツールキットは、様々なウィンドウ・ベー
ス・システムを介して迅速にかつ費用有効に移植するこ
とができる。

【００１４】当業者には、本発明の前述およびその他の
特徴が、本発明の下記の好ましい実施形態の説明を添付
の図面に関連して読んだときに明らかになろう。

【００１５】

【発明の実施の形態】図２は、グラフィカル・ユーザ・
インタフェースのツールキットの、ウィンドウ・ベース
のプラットフォームへの（たとえば、第１のウィンドウ
・ベース・プラットフォームから第２のウィンドウ・ベ
ース・プラットフォームへの）移植に関する例示的なフ
ローチャート２００を示す。図２のフローチャートの第
１のフェーズは定義フェーズを構成し、このフェーズで
は、ウィンドウ・ベースのプラットフォームの抽象化通
知を使用してツールキットが定義される。図２のフロー
チャートの第２のフェーズは実行フェーズを構成し、こ
のフェーズ中には、ウィンドウ・ベースのシステムから
の通知が、ウィンドウ・ベースのシステムとグラフィカ
ル・ユーザ・インタフェース・ツールキットとの間の対
話を確立するために使用される抽象通知として表され
る。

【００１６】開始論理ブロック２０２ならびにステップ
２０４および２０６は定義フェーズを構成し、それに対
して残りのステップは実行フェーズを構成する。図２の
フローチャートのステップ２０４で、第１のウィンドウ
・ベース・プラットフォーム（すなわち、ネイティブ・
プラットフォーム）に関して実施される１つまたは複数
のネイティブ通知（すなわち、事象または状態変化また
は「関心」）は、グラフィカル・ユーザ・インタフェー
スを定義する際に使用される抽象化通知に変換される。
その結果、グラフィカル・ユーザ・インタフェース・ツ
ールキットの各オブジェクトに、複数のウィンドウ・ベ
ース・プラットフォームから受取った抽象化通知を登録
することができる。

【００１７】当業者には理解されるように、通知は、キ
ー・ストロークや、プッシュ・ボタンやアイコン化ウィ
ンドウなどの活動化などの事象に対応させることができ
る。例示的な実施形態によれば、ホスト・ウィンドウ・
ベースのプラットフォームから受取った、状態変化を示
す事象は、オブジェクト・インタフェース定義の機能シ
グニチャとして表された抽象通知としてカプセル化され
る。抽象通知を表すために使用される機能シグニチャ
は、モデル、ビュー、コントローラ・オブジェクト処理
系を適合させることのできる動作仕様（たとえば、フォ
ーマル・トレイトまたはプロトコル）を構成する。

【００１８】モデル・ビュー・コントローラ・パラダイ
ムはさらに、単一のモデルまたはコントローラに対する
同じ関心を表す複数のビューをサポートし、複数のモデ
ルまたはコントローラに対する関心を表すことのできる
単一ビューをサポートするために拡張される。すなわ
ち、グラフィカル・ユーザ・インタフェースの複数のオ
ブジェクトに、複数のウィンドウ・ベース・プラットフ
ォームから受取った抽象通知を登録することができる。

【００１９】定義フェーズのステップ２０６で、任意の
オブジェクト処理系を使用して通知が動作仕様として実
施される（たとえば、グラフィカル・ユーザ・インタフ
ェースの処理系言語で形式的に表される）。すなわち、
グラフィカル・ユーザ・インタフェースの少なくとも１
つのオブジェクト・クラスで動作仕様を介して抽象化通
知が実施される。しかし、抽象化通知は、オブジェクト
指向グラフィカル・ユーザ・インタフェース・ツールキ
ット内の任意の処理系のオブジェクト間で転送すること
ができる。

【００２０】抽象化通知が、処理系言語によってサポー
トされる動作仕様として実施されるので、動作仕様に適
合しているオブジェクトの任意のインスタンスは、グラ
フィカル・ユーザ・インタフェースの実行継続期間にわ
たって、同じ動作仕様に適合している他のオブジェクト
との任意の関係を動的に確立し、それによって移植性の
高いシステムを形成することができる。具体的には、事
象の機能シグニチャとしてのカプセル化を使用して、オ
ブジェクト適合性検証が実施される。ネイティブ・ウィ
ンドウ・ベース・システムの事象を、１つまたは複数の
オブジェクトのインタフェース定義に対応する機能シグ
ニチャとしてカプセル化することによって、オブジェク
トが使用されるグラフィカル・ユーザ・インタフェース
の実行継続期間中に、所与のオブジェクトとウィンドウ
・ベースのシステムから受取った事象との適合性を検証
することができる。

【００２１】定義フェーズの後に続いて、グラフィカル
・ユーザ・インタフェース・ツールキットがウィンドウ
・ベースのシステム（すなわち、ツールキットまたは他
のウィンドウ・ベース・プラットフォームを実施するた
めに使用されるネイティブ・プラットフォーム）と対話
する実行フェーズを開始することができる。これはステ
ップ２０８で表されており、このステップでは、アプリ
ケーションの実行時に適合性検証を使用して少なくとも
１つのオブジェクトと他のオブジェクトとの間の関係が
動的に確立される。

【００２２】オブジェクト間の適合性は、オブジェクテ
ィブＣなどのプログラミング言語が有するような動的
（すなわち、実行時）結合機構を使用して、各オブジェ
クトと抽象化通知の適合性を検証することによって確立
される。このような動的結合機構は、通知をネイティブ
・ウィンドウ・ベース・プラットフォームの処理系言語
で形式的に定義するために使用される。そのため、任意
の通知に適合しているモデル、ビュー、コントローラの
任意の処理系が与えられる。本発明によれば、適合性検
証は、実行時交渉を任意のオブジェクトと共に使用して
確立される。

【００２３】オブジェクト間に関係が確立された後、オ
ブジェクトは、ステップ２１０で表したように自由に通
知を送受することができる。当業者には理解されるよう
に、任意の数の任意のオブジェクトに対して実行時交渉
を実行し、それによってステップ２１２および２１４で
表したように、オブジェクト指向グラフィカル・ユーザ
・インタフェースの実行継続期間中に動的多面関係を確
立し破壊することができる。

【００２４】したがって、例示的な実施形態によれば、
グラフィカル・ユーザ・インタフェースのモデル・ビュ
ー・コントローラ・パラダイムは、ビューが複数のモデ
ルおよびコントローラにおけるいくつかの異なる関心を
表すことができる「関心」モデルに拡張される。前述の
ステップは、グラフィカル・ユーザ・インタフェースの
実行継続期間がステップ２１６の「終了」で完了するま
で、任意の数の通知に対して、ステップ２１２および２
１４に関連付けられたループを介して繰り返すことがで
きる。

【００２５】例示的な実施形態によれば、オブジェクト
指向グラフィカル・ユーザ・インタフェースは様々なウ
ィンドウ・ベース・システムに容易にかつ動的に移植さ
れる。すなわち、グラフィカル・ユーザ・インタフェー
ス・ツールキットは、ツールキットをあるプラットフォ
ームから他のプラットフォームに再ホストすることに関
連する従来の難点を経験せずに、インタフェースが最初
に実施されたネイティブ環境（たとえば、Ｍｉｃｒｏｓ
ｏｆｔ^TM Ｗｉｎｄｏｗｓ）から他のターゲット・ウィ
ンドウ・ベース・プラットフォーム（たとえば、ＸＷ
ｉｎｄｏｗＳｙｓｔｅｍ^TM）に動的に移植することが
できる。

【００２６】例示的な実施形態によれば、ターゲット・
プラットフォームに、直接対応する概念的特徴および処
理系機能を有さない、ネイティブ・プラットフォームの
概念的特徴および処理系機能に対するシステム依存性を
除去するために抽象が使用される。当該の機能がグラフ
ィカル・ユーザ・インタフェース・システムに基本的な
ものであり、最初の処理系内で広く使用されているの
で、対応する処理系機能のために、グラフィカル・ユー
ザ・インタフェースの従来型の再ホスティングは顕著な
影響を受けていた。したがって、通常、最初に処理系コ
ードを移植し、それを維持するのに必要な作業の量が多
く、コストが非常に高かった。しかし、本発明の例示的
な実施形態によれば、ネイティブ・プラットフォームと
ターゲット・プラットフォームとの間の顕著な差は、抽
象化動作仕様を使用して、たとえばクライアント側に影
響を与えるウィンドウ・ベースのシステムの状態変化を
クライアント側に知らせることによって処理される。

【００２７】図３は、図２のフローチャートを実施する
例示的なシステムを示す。例示的な図３のシステム３０
０は、サーバ側３０２と、クライアント側３０４と、キ
ーボード入力やマウス入力などサーバ側への周辺入力３
０６とを含む。通知は、プロセス間通信接続３０８を介
してサーバ側のウィンドウ・ベース・プラットフォーム
からクライアント側のグラフィカル・ユーザ・インタフ
ェースへ転送される。図３のシステムでは、キーボード
の活動化、アイコン化ウィンドウの活動化、マウスの移
動など、ウィンドウ・ベースのプラットフォームの事象
は、クライアント側ツールキットによって抽象通知とし
て表される（たとえば、変換される）。

【００２８】図２に関して説明したように、従来型のシ
ステムとは異なり、ウィンドウ・ベースのシステムの事
象は、グラフィカル・ユーザ・インタフェースのオブジ
ェクトへは渡されない。その代わり、グラフィカル・ユ
ーザ・インタフェースの各オブジェクトは最初、ウィン
ドウ・ベースのシステムから受取ることができる１つま
たは複数の通知の抽象（すなわち、動作仕様）を備えた
実行時交渉中に関心を登録しなければならない。図３の
例では、グラフィカル・ユーザ・インタフェースの事象
ディスパッチ・オブジェクトを使用して、抽象化通知が
ウィンドウ・ベースのプラットフォームから、実行時交
渉中に特定の通知に関心を登録したグラフィカル・イン
タフェースの１つまたは複数の任意のオブジェクトにマ
ップされる。

【００２９】動作時に、事象ディスパッチ・オブジェク
トは、サーバ側のウィンドウ・ベースのプラットフォー
ムから具体的な事象を受取ると、この事象を抽象通知に
マップし、この抽象通知をグラフィカル・ユーザ・イン
タフェースの１つまたは複数のオブジェクトに渡す。そ
の結果、最初にその通知に関心を持つオブジェクトとし
て登録したオブジェクトがその通知を受取る。従って、
事象ディスパッチ・オブジェクトは、クライアント側オ
ブジェクトに通知を渡す機構を構成する。

【００３０】当業者には理解されるように、前述の機能
は、コンピュータ読取り可能な任意の媒体上で実施する
ことができる。たとえば、そのような媒体は図３のグラ
フィカル・ユーザ・インタフェース３０４に存在するこ
とも、あるいはグラフィカル・ユーザ・インタフェース
３０４と共に使用できるコンピュータ読取り可能な媒体
に存在することもできる。この後者のケースでは、グラ
フィカル・ユーザ・インタフェースのツールキットをウ
ィンドウ・ベースのプラットフォームに移植するコンピ
ュータ・プログラムを用いてコンピュータ・プログラム
製品３１０をコード化することができる。コンピュータ
・プログラム製品はたとえば、ネイティブ・ウィンドウ
・ベース・プラットフォームからの通知の抽象や、事象
をターゲット・ウィンドウ・ベース・プラットフォーム
から様々な抽象化通知にマップするためのテーブルなど
のデータを記憶するコンピュータ読取り可能な記憶媒体
３１２を含むことができる。

【００３１】コンピュータ・プログラム製品３１０はさ
らに、コンピュータ読取り可能な記憶媒体にコンピュー
タ・コードを実行させるコンピュータ読取り可能な記憶
媒体に埋め込まれたコンピュータ・コード機構を含むこ
とができる。たとえば、コンピュータ・コード機構は、
ウィンドウ・ベースのプラットフォームから状態変化の
ネイティブ通知を受取るように構成された第１のコンピ
ュータ・コード装置３１４と、グラフィカル・ユーザ・
インタフェースの実行時にネイティブ通知を抽象化通知
として表すために第１のコンピュータ・コード装置に結
合された第２のコンピュータ・コード装置３１６とを含
むことができる。前述のように、ネイティブ通知は１つ
または複数の抽象化通知にマップすることができる。例
示的な実施形態によれば、抽象化通知は、ネイティブ・
ウィンドウ・ベース・プラットフォームとターゲット・
ウィンドウ・ベース・プラットフォームの両方に特有の
処理系とは独立のネイティブ通知の動作仕様を構成す
る。

【００３２】例示的な図３の実施形態では、コンピュー
タ・コード機構は任意の数のコンピュータ・コード装置
を含むことができる。たとえば、グラフィカル・ユーザ
・インタフェース・ツールキット内の少なくとも１つの
オブジェクトの、抽象化通知で構成された動作仕様との
適合性を検証する第３のコンピュータ・コード装置３１
８を含めることができる。

【００３３】前述の機能をさらに、下記の例に関して例
示する。ユーザが周辺入力３０６のキーボード上のキー
を活動化したものと仮定する。この動作によって、キー
プレス事象がウィンドウ・ベースのプラットフォームか
らクライアント側のグラフィカル・ユーザ・インタフェ
ースへ送られる。キープレス事象は、（１）事象の意
味、（２）事象のフォーマットまたは構文の２つの重要
な態様を含む。キープレス事象は、プロセス間通信接続
３０８を介してクライアント側へ転送される。

【００３４】クライアント側のオブジェクト指向グラフ
ィカル・ユーザ・インタフェースによってキープレス事
象が受取られると、事象ディスパッチ・オブジェクトは
この情報を見て、それを転送すべきかどうかを判定す
る。事象ディスパッチ・オブジェクトは次いで、判定に
応じて情報を転送する。たとえば、キープレスが、文字
「Ａ」キーと「シフト」キーを組み合わせて押すことに
対応するものである場合、事象ディスパッチ・オブジェ
クトは、キープレス事象情報の受取時に、「Ａ」を表す
情報をテキスト・フィールドに渡し、テキスト・フィー
ルドは次いで、ディスプレイ上で「Ａ」の描画を実施す
る。すなわち、事象情報は、実行時交渉を介して抽象通
知に関心を登録したオブジェクトへ転送できる抽象通知
として表される。

【００３５】本発明の例示的な実施形態によれば、ツー
ルキットは、ウィンドウ・ベースの処理系に必然的に存
在する事象の動作仕様（すなわち、機能シグニチャ）の
みを表すように抽象化された事象の通知に対して実施さ
れている。たとえば、通常、事象にカプセル化され、そ
れによって異なるウィンドウ・ベース・プラットフォー
ムのために実施されるオブジェクト指向インタフェース
へのその事象の移植性を制限していた意味および構文は
なくなる。その代わり、事象は、特定のウィンドウ・ベ
ース・システムに特有の処理系から独立するように抽象
化される（すなわち、もはや最初のネイティブ・プラッ
トフォームに特有のものではない）。（１）ネイティブ
・ウィンドウ・ベース・プラットフォームおよび（２）
ツール・キットが移植されたターゲット・ウィンドウ・
ベース・プラットフォームに共通の通知の情報のみを使
用して、事象が認識されクライアント側のオブジェクト
と相関付けされる。前述の例では、事象から共通の情報
が抽出されることによって、単に、どの文字が押された
か（すなわち、「ａ」）を、通知をクライアント側のオ
ブジェクトにマップするための動作仕様として示すこと
ができる。

【００３６】事象の抽象化を例示するために、ボタンに
関連付けられた事象（たとえば、キープレス事象）のコ
ード化に関する簡略化された例を与える。この例で述べ
るコード・フラグメントは、当業者に周知の構造を表
す。この例は、２つの異なる具体的なウィンドウ・シス
テム事象の、単一の「抽象」表現としての抽象化と、そ
の表現の、事象ソースとシンクとの間の形式的なプロト
コルとしての表現を示すものである。この例では、プラ
ットフォーム依存性をローカライズし、大部分のグラフ
ィカル・ユーザ・インタフェース・フレームワークにプ
ラットフォーム依存性を有させ、事象ソースとシンクと
の間の形式的なプロトコルを作成し、それによってアプ
リケーションの継続期間中にソースとシンクとの間の関
係を修正することができる有効な動的事象モデルを得
る、本発明の実際の応用例が強調される。

【００３７】この例では、マウスまたはポインタ・ボタ
ン・プレス事象の具体的なウィンドウ・システム事象通
知が存在する、ＸＷｉｎｄｏｗＳｙｓｔｅｍ^TMおよ
びＮｅＸＴＳＴＥＰ^TM Ｗｉｎｄｏｗシステムを考え
る。どちらのシステムでも、この事象通知は、プラット
フォーム依存アプリケーション・プログラム・インタフ
ェースおよびプロセス間通信機構を介して、ウィンドウ
・システム・サーバから、システムからそのような通知
を受取るアプリケーションとして選択されたクライアン
ト・アプリケーションへ転送される。しかし、各システ
ムは、構文と意味の両方に関して、そのような通知の意
味的に異なる具体的表現を有する。たとえば、ＸＷｉ
ｎｄｏｗＳｙｓｔｅｍでは、事象は下記のＣタイプ定
義および定数によって記述される（詳細については、Ｓ
ｃｈｅｉｆｌｅｒ＆Ｇｅｔｔｙｓ著「ＴｈｅＸＷｉ
ｎｄｏｗＳｙｓｔｅｍ」（ＤｉｇｉｔａｌＰｒｅｓ
ｓ、１９９２ＩＳＢＮ１−５５５５８−０８８−２）を
参照されたい）。 typedef struct { int type; ／／＝＝ボタンプレス unsigned long serial; ／／最後に処理した要求の通し番号 Bool send_event; ／／合成生成 Display^*display; ／／ウィンドウ・サーバ・クライアント参照 Window window; ／／事象の転送先のウィンドウ Window root; ／／画面のルート・ウィンドウ Window subwindow; ／／事象が発生したウィンドウ Time time; ／／サーバ・タイムスタンプ int x, ／／画素ベース、原点左上 y; int x_root, ／／画面関係のコード y_root; unsigned int state; ／／キーボード修飾子の状態 unsigned int button; ／／どのボタンを押したか。 Bool same_screen; } XButtonEvent; typedef XButtonEvent XButtonPressedEvent; typedef XButtonEvent XButtonReleasedEvent; ／^*上記の「ｔｙｐｅ」フィールドに関する定数^*／ #define ButtonPress 4 ／^*上記の「ｓｔａｔｅ」フィールドに関する定数^*／ #define ShiftMask (1<<0) #define LockMask (1<<1) #define ControlMask (1<<2) #define Mod1Mask (1<<3) #define Mod2Mask (1<<4) #define Mod3Mask (1<<5) #define Mod4Mask (1<<6) #define Mod5Mask (1<<7) ／^*上記の「ｂｕｔｔｏｎ」フィールドに関する定数^*／ #define Button1 1 #define Button2 2 #define Button3 3 #define Button4 4 #define Button5 5

【００３８】ＮｅＸＴＳＴＥＰＷｉｎｄｏｗＳｙｓ
ｔｅｍでは、Ｂｕｔｔｏｎ事象は下記のように定義され
る（詳細については、ＮｅＸＴＣｏｍｐｕｔｅｒＩ
ｎｃ、ＡｄｄｉｓｏｎＷｅｓｌｅｙ著「ＮｅＸＴＳＴ
ＥＰＧｅｎｅｒａｌＲｅｆｅｒｅｎｃｅ（ｖｏｌｕ
ｍｅ２）」（１９９２ＩＳＢＮ０−２０１−６２２２１
−２）を参照されたい）。／^*EventDataタイプ：事象のデータ・フィールドを定義する^*／ typedef union { struct { /^*マウス事象の場合^*/ short reserved; short eventNum; /^*このボタンに関する一意の識別子^*/ int click; /^*この事象のクリック状態^*/ unsigned char pressure; /^*圧力値：０＝なし、２５５＝フル^*/ char reserved1; short reserved2; } mouse; /^*話を明確にするために他の事象タイプ・データを削除する。^*/ } NXEventData; /^*The event record!^*/ typedef struct { float x; float y; } NXPoint; typedef struct_NXEvent { int type; /^*上記からの事象タイプ^*/ NXPoint location; /^*ウィンドウ内のベース座標、左下から^*/ long time; /^*開始時からの垂直間隔^*/ int flags; /^*キー状態フラグ^*/ unsigned int window; /^*割り当てられたウィンドウのウィンドウ番号^*/ NXEventData data; /^*タイプ依存データ^*/ DPSContext ctxt; /^*事象が発生したコンテキスト ^*/ } NXEvent, ^*NXEventPtr; /^*上記の「ｔｙｐｅ」フィールドに関する定数^*/ #define NX_LMOUSEDOWN 1 /^*左マウス下降事象^*/ #define NX_LMOUSEUP 2 /^*左マウス上昇事象^*/ #define NX_RMOUSEDOWN 3 /^*右マウス下降事象^*/ #define NX_RMOUSEUP 4 /^*右マウス上昇事象^*/ #define NX_MOUSEMOVED 5 /^*マウス移動事象^*/ #define NX_LMOUSEDRAGGED 6 /^*左マウス・ドラッグ事象^*/ #define NX_RMOUSEDRAGGED 7 /^*右マウス・ドラッグ事象^*/ #define NX_MOUSEDOWN NX_LMOUSEDOWN /^*シノニム^*/ #define NX_MOUSEUP NX_LMOUSEUP /^*シノニム^*/ #define NX_MOUSEDRAGGED NX_LMOUSEDRAGGED /^*シノニム^*/ /^*上記の「ｆｌａｇｓ」フィールドに関する定数^*/ #define NX_ALPHASHIFTMASK (1 << 16)/^*アルファ・ロックがオンの場合^*/ #define NX_SHIFTMASK (1 << 17)/^*シフト・キーが押された場合^*/ #define NX_CONTROLMASK (1 << 18)/^*コントロール・キーが押された場合 ^*/ #define NX_ALTERNATEMASK (1 << 19)/^*ａｌｔキーが押された場合^*/ #define NX_COMMANDMASK (1 << 20)/^*コマンド・キーが押された場合^*/ #define NX_NUMERICPADMASK (1 << 21)/^*数値パッド上のキーである場合^*/ #define NX_HELPMASK (1 << 22)/^*ヘルプ・キーが押された場合^*/ /^*装置依存ビット^*/ #define NX_NEXTCTRLKEYMASK (1 << 0) /^*コントロール・キー^*/ #define NX_NEXTLSHIFTKEYMASK (1 << 1) /^*左側シフト・キー ^*/ #define NX_NEXTRSHIFTKEYMASK (1 << 2) /^*右側シフト・キー ^*/ #define NX_NEXTLCMDKEYMASK (1 << 3) /^*左側コマンド・キー^*/ #define NX_NEXTRCMDKEYMASK (1 << 4) /^*右側コマンド・キー^*/ #define NX_NEXTLALTKEYMASK (1 << 5) /^*左側ａｌｔキー^*/ #define NX_NEXTRALTKEYMASK (1 << 6) /^*右側ａｌｔキー^*/ #define NX_STYLUSPROXIMITYMASK (1 << 7) /^*スタイラスが近接している場合（タブレットの場合） ^*/ #define NX_NONCOALSESCEDMASK (1 << 8) /^*事象合体がディスエーブルされた状態で事象が生成された。^*/

【００３９】上記の定義から、２つの処理系が具体的な
構文および意味において著しく異なることは明らかであ
る。したがって、これらの定義をネイティブ形で使用し
て、各ターゲット・ウィンドウ・システムごとの並列処
理系を作成する包括的な条件付きコンパイル命令なしに
両方のプラットフォーム間で移植できるグラフィカル・
ユーザ・インタフェース・ツールキットの処理系を作成
することはできない。しかし、本発明の例示的な実施形
態によれば、両方のウィンドウ・システム間で移植でき
るボタン・プレスの共通の定義を抽象化し、プラットフ
ォーム依存コードをツールキットの単一または比較的少
数の構成要素としてローカライズすることによって、ツ
ールキットを実施する大部分のコードにプラットフォー
ム依存性を有させることができる。

【００４０】上記で定義した具体的なウィンドウ・シス
テム事象通知が与えられた場合、例示的な実施形態によ
る処理系の第１のステップは、具体的な事象の共通の抽
象を定義することである。この例では、オブジェクティ
ブＣプログラミング言語を使用する。なぜなら、これは
ＮｅＸＴＳＴＥＰや（ＸＷｉｎｄｏｗＳｙｓｔｅｍ
用の）ＯｐｅｎＳｔｅｐなどのプログラミング・システ
ムで使用される処理系言語であるからである。抽象事象
を使用して、すべての事象抽象に共通する事象タイプ、
そのソース、その他の基本情報が定義される。 @interface AbstractEvent: Object { enum { AEButtonPress, AEButtonRelease, AEMouseMoved, // ... } eventType; SystemEventDispatcher eventDispatcher;//プラットフォーム・ウィンドウ・システムから事象をマップしディスパッチするオブジェクト // unsigned int eventSerial;//通し番号 unsigned long eventTimestamp;//システム・タイムスタンプ } // ... @end

【００４１】次に、「ウィンドウ」に関連付けられた事
象の概念、すなわち両方のターゲット・プラットフォー
ムに共通の概念が導入される。 @interface AbstractWindowEvent: AbstractEvent { unsigned int eventWindow; //事象が発生したウィンドウのＩＤ } // ... @end

【００４２】最後に、両方のターゲット・プラットフォ
ームに関連する情報を含む、ボタン・プレス事象に関す
る特定の抽象が、具体的な事象の構文および意味とは異
なる合成構文および意味を用いて定義される。 typedef enum { AKbdEShiftModifier = (1 < 0), AKbdECtrlModifier = (1 < 1), // ... } AKbdEventModifiers; @interface AbstractButtonPressEvent : AbstractWindowEvent { float eventX; float eventY; enum { ABPELeftButton, ABPEMiddleButton, ABPERightButton } eventButton; AKbdEventModifiers eventKbdModifiers; } // ... @end

【００４３】したがって、抽象ウィンドウ・システム事
象オブジェクトの階層は、当業者なら認識可能であり、
マウス・ボタン・プレス事象に関してＸＷｉｎｄｏｗ
ＳｙｓｔｅｍおよびＮｅＸＴＳＴＥＰＷｉｎｄｏｗ
Ｓｙｓｔｅｍの具体的な事象システムで使用される情
報の合成を含むものとして定義されている。次に、任意
のオブジェクト（オブザーバまたはシンク）が、特定の
プロトコルまたはインタフェース仕様を介して他のオブ
ジェクト（オブザービーまたはソース）からの通知を観
測する際に関心を表すことができるようにするオブジェ
クト階層のインタフェースが定義される。

【００４４】次いで、抽象事象定義に基づいて１組のプ
ロトコルが定義される。これらのプロトコルは、上記で
詳述した抽象事象記述で表されるシステムの状態の変化
の通知を発行し受取ることができる任意のオブジェクト
間の形式的なインタフェースを記述する。 @protocol AbstractEventObserverProtocol -(void) gotEvent:(AbstractEvent^*)theEvent fromSource: (Object ^*)theEventSource; @end @protocol AbstractWindowEventObserverProtocol -(void)gotWindowEvent:(AbstractWindowEvent^*) theWindowEvent fromSource:(Object ^*)theEventSource; @end @protocol AbstractButtonPressEventObserverProtocol - (void)gotButtonPressEvent:(AbstractButtonPressEvent^*) theWindowEvent fromSource:(Object ^*) theEventSource; @end

【００４５】これらの抽象プロトコルを定義した後、こ
れらの通知を受信したい「ＢｕｔｔｏｎＣｏｎｔｒｏ
ｌ」オブジェクトを定義することができる。 @interface ButtonControl : Control <AbstractButtonPressEventObserverProtocol, AbstractWindowEventObserverProtocol, // ... > // ... -(ButtonControl)newButtonControl; -(void) dealloc; -(void)gotButtonPressEvent:(AbstractButtonPressEvent^*) theWindowEvent fromSource:(Object ^*) theEventSource; -(void)gotWindowEvent:(AbstractWindowEvent^*) theWindowEvent fromSource: (Object ^*) theEventSource; // ... @end

【００４６】次いで、処理系の関連する部分が与えられ
る。 @implementation ButtonControl -(ButtonControl) newButtonControl {

【００４７】このメソッドは、ＢｕｔｔｏｎＣｏｎｔｒ
ｏｌの新しいインスタンスを作成する。副作用として、
ＢｕｔｔｏｎＣｏｎｔｒｏｌは、ＢｕｔｔｏｎＰｒｅｓ
ｓ事象の通知を受取るために、それ自体にツールキット
の「ｅｖｅｎｔＤｉｓｐａｔｃｈｅｒ」オブジェクトを
登録する。 self = [super init];

【００４８】これで、このオブジェクトはウィンドウ・
システム事象ディスパッチャに登録され、プロトコル通
知を受け取ることができるようになる。 [[SystemEventDispatcher eventDispatcher] addObserver: self forProtocol: @protocol(AbstractButtonPressEventObserverProtocol) ]; return(ButtonControl^*)self; } -(void) dealloc {

【００４９】このメソッドは、ＢｕｔｔｏｎＣｏｎｔｒ
ｏｌのインスタンスを解放するために呼び出される。副
作用として、ＢｕｔｔｏｎＣｏｎｔｒｏｌはそれ自体を
ｅｖｅｎｔＤｉｓｐａｔｃｈｅｒオブジェクトから削除
する。 [[SystemEventDispatcher eventDispatcher] removeObserver: self forProtocol: @protocol(AbstractButtonPressEventObserverProtocol) ]; [super dealloc]; } - (void) gotButtonPressEvent:(AbstractButtonPressEvent^*) theWindowEvent fromSource:(Object^*) theEventSource { //このメソッドは、これに対してボタン・プレスが行われたときに呼び出される //制御... //...次に、ButtonControl活動化処理を行う。... } @end

【００５０】グラフィカル・ユーザ・インタフェース・
ツールキット・オブジェクトをこれらの抽象プロトコル
で定義した後、「ＳｙｓｔｅｍＥｖｅｎｔＤｉｓｐａｔ
ｃｈｅｒ」クラスが実施される。本発明の例では、これ
は、ウィンドウ・システム依存コードを含む、グラフィ
カル・ユーザ・インタフェース・ツールキットの事象サ
ブシステム内の唯一のクラスである。 @interface SystemEventDispatcher : Object + (SystemEventDispatcher) eventDispatcher; - (void) run; - (Bool) addObserver:(Object ^*)observer forProtocol:(Protocol^*)interestProtocol; - (Bool) removeObserver:(Object ^*)observer orProtocol:(Protocol^*)interestProtocol; -(void) dispatchAbstractEvent:(AbstractEvent^*)absev; @end

【００５１】すべてのプラットフォーム依存コードをカ
プセル化するＳｙｓｔｅｍＥｖｅｎｔＤｉｓｐａｔｃｈ
ｅｒのクラス専用インタフェースが定義される。 @interface SystemEventDispatcher(PlatformDependentStuff) @private #ifdef XWindows -(XEvent)_nextEvent; //XWindowサーバから次のXEventを取り込む -(void) _mapXEvent:(XEvent ^*)xEvent OntoAbstractEvent:(AbstractEvent^**)returnEvent; // ... #endif #ifder NeXTSTEP -(NXEvent)_nextNXEvent; //NeXTSTEP DPSから次のNXEventを取り込む。 -(void) _mapNXEvent:(NXEvent^*)nxEvent OntoAbstractEvent:(AbstractEvent^**)returnEvent; // ... #endif // ... @end @implementation SystemEventDispatcher { // ... HashTable^* buttonPressEventObservers;//ウィンドウIDでハッシュされた //ボタン・プレス事象に関心を持 //つすべてのControlを含む。 // ... } + (SystemEventDispatcher)eventDispatcher { //システム事象ディスパッチャの新しいインスタンスを作成する。 static SystemEventDispatcher^*eventDispatcher = nil; if (eventDispather = = nil) { eventDispatcher = [[SystemEventDispatcher alloc] init]; } return eventDispatcher; } - run { //事象ディスパッチャを実行し、システムから事象を取り込み、事象をプラ //ットフォーム特有の形式から抽象マッピングにマップし、その後、すべて //の適格なオブザーバにディスパッチする。... for(;;){ AbstractEvent^*absev; #ifdef XWindows [self _mapXEvent:[self_nextXEvent] OntoAbstractEvent: &absev ]; #endif #ifdef NeXSTSTEP [self _mapNXEvent:[self_nextNXEvent] OntoAbstractEvent: &absev ]; #endif [self dispatchAbstractEvent: absev]; } } - (void) dispatchAbstractEvent:(AbstractEvent^*)absev { //抽象事象を適格なオブザーバにディスパッチする。 switch([absev eventType] { // ... case AEButtonPress: //抽象事象のウィンドウIDに関連付けられたCOntrolを見つけ、事象をそのCOntrolにディスパッチする。... Control^*c = [buttonPressEventObserversvalueForKey: [absev eventWindow] ]; [c gotButtonPressEvent: absev FromSource: self ]; break; // ... } } - (Bool)addObserver: Object^*observer forProtocol:Protocol^*interestProtocol { //特定のオブザーバ・プロトコルに関するオブザーバ（適格な場合）を登録する。 // ... if(interestProtocol = =) @protocol(AbstractButtonPressEventObserverProtocol) && [observer conformsTo: interestProtocol]) { //オブザーバがプロトコルに適合している場合、その //ウィンドウ識別子で索引付けされたハッシュ・テー //ブルにそのオブザーバを保存する。 [buttonPressEventObservers insertkey:(const void^*)[observer window]; value: (void ^*)observer ]; } // ... return(Bool)True; } // ... @end @implementation SystemEventDispatcher(PlatformDependentStuff) #ifdef XWindows // ... - (void) _mapXEvent:(XEvent^*)xEvent OntoAbstractEvent:(AbstractEvent^**)returnEvent { //システム事象を事象抽象上にマップするためのプラットフォーム依存コード switch(xEvent->type){ // ... case ButtonPress:{ XButtonPressedEvent^* xPress = (XButtonPressedEvent^*)xEvent; //新しいAbstractButtonPressEventを作成する。 ^*returnEvent = [AbstractButtonPressEvent new]; //次に、XButtonPressedEventに存在するプラ //ットフォーム依存情報に基づいてAbstract //ButtonPressEventのメンバー変数を初期設定 //する。 // ... } break; // ... } } // ... #endif #ifdef NeXTSTEP // ... #endif @end

【００５２】簡単な例示的な「メイン」プログラムによ
って、ＳｙｓｔｅｍＥｖｅｎｔＤｉｓｐａｔｃｈｅｒか
らボタン・プレスの抽象通知を受取るＢｕｔｔｏｎＣｏ
ｎｔｒｏｌを示す。 int main(const int argc, const char ^**const argv) { [ButtonContrl newButtonCotnrol]; //ButtonControlを作成する [[SystemEventDispatcher eventDispatcher]run]; //ディスパッチャを実行する。 }

【００５３】本発明によれば、動作仕様の抽象通知は、
事象ディスパッチ・オブジェクトと共に、図２のステッ
プ２０８に関して説明したように、グラフィカル・ユー
ザ・インタフェース・ツールキット内の特定のオブジェ
クトが通知に適合しているかどうかを実行時交渉する能
力を与える。本明細書では実行時交渉と呼ばれる実行時
適合性試験を行う能力によって、ビュー・フィールド内
のオブジェクトと制御フィールドまたはモデル・フィー
ルド内のオブジェクトとの間の関係は、システムの実行
継続期間中に動的に変化することができる。例示的な図
３のシステムでは、実行時交渉によって、事象ディスパ
ッチ・オブジェクト内の再マッピングを介して関係を動
的に変更（すなわち、確立または確立解除）することが
できる。

【００５４】前述の機能、特に実行時交渉機能をより明
確に例示するために、一方はウィンドウ・ベースのプラ
ットフォーム内のオブジェクトであり、他方はグラフィ
カル・ユーザ・インタフェース内のオブジェクトである
２つの匿名オブジェクトを考える。この２つのオブジェ
クトは、互いの存在のみを知り、他のことは何も知らな
い。この２つのオブジェクトを本明細書では、「ベン
ダ」および「顧客」と呼ぶ。ベンダ４０２および顧客４
０４を図４に示す。

【００５５】ベンダの動作仕様が、キープレス事象な
ど、顧客（たとえば、クライアント側アプリケーション
の顧客）が使用したいプロトコルを含むと仮定すると、
ベンダは、キープレス事象の何らかの通知を顧客にエク
スポートできなければならない。顧客は、ベンダの存在
を知り、ベンダに情報（たとえば、通知）を渡す能力を
検証するために実行時交渉を開始することに関心を抱
く。したがって、顧客は、ベンダが顧客の動作仕様に適
合しているかどうかを知る必要がある。

【００５６】この開始位置が与えられた場合、実行時交
渉は、顧客が、動作仕様「Ａ」（すなわち、顧客が使用
したいプロトコル）を扱っているかどうかをベンダに問
い合わせることによって開始される。ベンダが動作仕様
「Ａ」を扱っていない場合、顧客はベンダとの情報転送
を確立する試みを中断する。しかし、ベンダが動作仕様
「Ａ」を取り扱っていることを示した場合、顧客は、
「Ａ」に対応する動作仕様に関する「関心」をベンダに
登録する。ベンダはこの動作仕様をサポートしているの
で、顧客は、この動作仕様に関連する状態変化が起こっ
たときにベンダが顧客のビューに情報を転送できるよう
にベンダと共にこの動作仕様に参加したいことをベンダ
に知らせる。

【００５７】顧客が、状態変化に関する通知を受取るた
めに動作仕様に参加し、ベンダと交渉したいことを確認
した後、ベンダは、動作仕様「Ａ」に適合（すなわち、
動作仕様「Ａ」を遵守）しているかどうかに関して顧客
に問い合わせる。顧客が動作仕様「Ａ」に適合している
と仮定すると、関係（すなわち、実行時契約）が確立さ
れ、この２つのオブジェクト間で抽象通知が流れること
ができる。

【００５８】例示的な実施形態によれば、システムも実
行継続期間中の任意の時間に、ベンダまたは顧客、ある
いはその両方はこの関係を取り消すことができる。すな
わち、どちらのオブジェクトもそれ自体をこの関係から
削除することができる。そのような削除が望ましいのは
たとえば、顧客がジョブを完了しこの関係を放棄する場
合である。どちらかのオブジェクトがこの関係を放棄す
る場合、前述のように新しい関係を確立することができ
る。

【００５９】例示的な実行時交渉について説明したが、
次に、本発明によるオブジェクトどうしの例示的なマッ
ピングについて述べる。これに関しては、図５を参照す
る。図５では、ウィンドウ・ベースのシステムのディス
プレイ上のプッシュボタンの活動化に対応する事象を使
用してある事象がトリガされる。例示的な実施形態によ
れば、この事象に対応する具体的な情報は、グラフィカ
ル・ユーザ・インタフェースによって前述のようにウィ
ンドウ・ベースのプラットフォームから抽象情報にマッ
プされる。この場合、プッシュボタン５０２は、クライ
アント側オブジェクト指向グラフィカル・ユーザ・イン
タフェースで、モデル・ビュー・コントローラ・パラダ
イムのビューとコントローラの両方に対応するオブジェ
クトとして表される。このオブジェクトは、ビューとし
ては、ディスプレイ上にプッシュボタンを描画する責任
を負う。コントローラとしては、プッシュボタンが押さ
れ、あるいは解放されたことを示すために発生した状態
変化を記述する。

【００６０】プッシュボタンに関する動作仕様が、
（１）「プッシュボタンが押された」と（２）「プッシ
ュボタンが解放された」という２つのメッセージを生成
するプロトコル「ＢｕｔｔｏｎＣｌｉｃｋｓ」を含む
と仮定する。プッシュボタンの場合、抽象化通知はさら
に、プッシュボタンが押された時間（すなわち、タイム
・スタンプ）、またはプッシュボタンを用いて活動化さ
れたキーボード修飾子（たとえば、文字キーを用いたシ
フト・キーの活動化）、またはプッシュボタン活動化時
のマウスの位置（たとえば、マウス上のボタンが活動化
された場所）を識別する情報を含むことができる。さら
に、事象ディスパッチ・オブジェクトが「Ｂｕｔｔｏｎ
Ｃｌｉｃｋｓ」プロトコルを扱っていると仮定する。
実行時交渉時に、プッシュボタンは、事象ディスパッチ
・オブジェクトに「ＢｕｔｔｏｎＣｌｉｃｋｓ」プロ
トコルを扱っているかどうかを問い合わせる。事象ディ
スパッチ・オブジェクト５０４がこのプロトコルを扱っ
ている場合、プッシュボタンは、事象ディスパッチ・オ
ブジェクトと共に「ＢｕｔｔｏｎＣｌｉｃｋｓ」プロ
トコルに参加したいことを示すことによって応答する。
したがって、プッシュボタンは「ＢｕｔｔｏｎＣｌｉ
ｃｋｓ」プロトコルに「関心」を登録する。

【００６１】事象ディスパッチ・オブジェクトは次に、
プッシュボタンに「ＢｕｔｔｏｎＣｌｉｃｋｓ」プロト
コルに適合しているかどうかを問い合わせる。プッシュ
ボタンが肯定応答した場合、関係が確立される。そのた
め、事象ディスパッチ・オブジェクトは、ウィンドウ・
ベースのプラットフォーム５０６からボタンプレス事象
を受取ると、プッシュボタンに「プッシュボタン・ディ
プレス」事象を通知する。

【００６２】本発明の例示的な実施形態は事象を抽象化
するので、もちろん、処理系固有のある種の情報は失わ
れることがある。しかし、情報が失われる代わりに、シ
ステムの移植性が向上する。さらに、当業者には理解さ
れるように、処理系固有の情報は、このプラットフォー
ム特有の処理系用のクライアント側オブジェクト指向グ
ラフィカル・ユーザ・インタフェースにおいて情報を個
別にコード化することによって保持することができる。

【００６３】再び図５を参照すると分かるように、当業
者には、前述のように通知を抽象化すると、オブジェク
ト間の１：１関係を維持する必要がなくなることが理解
されよう。その代わり、抽象通知に「関心」を持つすべ
てのオブジェクトを通知を受取るようにマップすること
ができる。たとえば、抽象通知がタイマ５０８の出力に
対応する場合、関連するプロトコル「ティック」を確立
し、１秒経過するたびに事象ディスパッチ・オブジェク
トに通知することができる。事象ディスパッチ・オブジ
ェクトと、時間の追跡に「関心」を持つすべてのオブジ
ェクト（たとえば、オブジェクト５１０および５１２）
との間に独立の「Ｔｉｍｅｆｌｏｗ」プロトコルを確立
することができる。そのようなオブジェクトは、たとえ
ば、ディスプレイ上のクロックや、株式市場ティッカ・
フィードや、タイマなどを含むことができる。したがっ
て、時間の追跡に関心を持つすべてのオブジェクトのビ
ューに、「Ｔｉｍｅｆｌｏｗ」プロトコルを介して時間
の変化が通知される。したがって、「ティック」プロト
コルが事象ディスパッチ・オブジェクトと１：１の関係
を有する場合でも、「Ｔｉｍｅｆｌｏｗ」プロトコル
は、事象ディスパッチ・オブジェクトと、時間の追跡に
関心を持つすべてのオブジェクトとの関係を表す。

【００６４】当業者には、本発明の例示的な実施形態が
多数の異なる方法で実施できることが理解されよう。た
とえば、例示的な実施形態を使用して、グラフィカル・
ユーザ・インタフェースの機能を、ソフトウェアとハー
ドウェアのどちらかで実施されるウィンドウ・ベースの
システムに移植することができる。さらに、例示的な実
施形態をクライアント・サーバ・システムに関して説明
したが、当業者には、本発明を使用して、ウィンドウ・
ベースのシステムがどこに存在するかにかかわらずにグ
ラフィカル・ユーザ・インタフェースのツールキットを
ウィンドウ・ベースのシステムに移植できることが理解
されよう。

【００６５】当業者には、本発明の趣旨または必須の特
性から逸脱せずに本発明を他の特定の形態で実施できる
ことが理解されよう。したがって、現在開示している実
施形態はすべての点で例示的なものとみなされ、制限さ
れない。本発明の範囲は、上記の説明ではなく添付の特
許請求の範囲によって示され、本発明の意味および範囲
ならびに等価物内のすべての変更は本発明に包含される
ものとする。

【図面の簡単な説明】

【図１】モデル・ビュー・コントローラ・パラダイム
の抽象表現を示す図（Ａ）と図１Ａに示した抽象表現の
例示的な応用例を示す図（Ｂ）である。

【図２】本発明の例示的な実施形態による、ユーザ・
インタフェースの、第１のウィンドウ・ベース・プラッ
トフォームから第２のウィンドウ・ベース・プラットフ
ォームへの移植に関する例示的なフローチャートであ
る。

【図３】クライアント側インタフェースを第１のウィ
ンドウ・ベース・プラットフォームから第２のウィンド
ウ・ベース・プラットフォームに移植するために本発明
によって構成された例示的なシステムを示す図である。

【図４】本発明の形態を示す図である。

【図５】本発明によって構成されたシステムの、所与
の動作仕様に適合しているオブジェクトの任意のインス
タンスと、同じ動作仕様に適合している他のオブジェク
トとの関係を動的に確立する能力を示す図である。

【符号の説明】

１０２モデル１０４、１１６ビュー１０６コントローラ１０８矢印１１２スクロール・バー・オブジェクト１１４テキスト・ファイル

【手続補正書】

【提出日】平成９年１１月２１日

【手続補正１】

【補正対象書類名】図面

【補正対象項目名】全図

【補正方法】変更

【補正内容】

【図１】

【図３】

【図４】

【図２】

【図５】

───────────────────────────────────────────────────── フロントページの続き (71)出願人 591064003 901 ＳＡＮＡＮＴＯＮＩＯＲＯＡＤＰＡＬＯＡＬＴＯ，ＣＡ 94303，Ｕ. Ｓ．Ａ.

Claims

【特許請求の範囲】

【請求項１】グラフィカル・ユーザ・インタフェース
のツールキットをウィンドウ・ベースのプラットフォー
ムに移植する方法であって、ウィンドウ・ベースのプラットフォームから状態変化の
ネイティブ通知を受取るステップと、グラフィカル・ユーザ・インタフェースの実行時に、前
記ネイティブ通知を、前記ウィンドウ・ベースのプラッ
トフォームに特有の処理系とは独立のネイティブ通知の
動作仕様を構成する抽象化通知として表すステップとを
含むことを特徴とする方法。
【請求項２】さらに、前記グラフィカル・ユーザ・イ
ンタフェースの実行時に、グラフィカル・ユーザ・イン
タフェース・ツールキット内の少なくとも１つのオブジ
ェクトと前記動作仕様との適合性を検証するように前記
グラフィカル・ユーザ・インタフェースを構成するステ
ップを含むことを特徴とする請求項１に記載の方法。
【請求項３】ウィンドウ・ベースのプラットフォーム
と共に使用できるグラフィカル・ユーザ・インタフェー
ス・ツールキットであって、ウィンドウ・ベースのプラットフォームから状態変化の
ネイティブ通知を受取る入力と、前記ウィンドウ・ベースのプラットフォームに特有の処
理系とは独立のネイティブ通知の動作仕様を構成する抽
象化通知として表された前記ネイティブ通知の抽象を用
いて関係を確立するオブジェクトの階層集合とを備える
グラフィカル・ユーザ・インタフェース・ツールキッ
ト。
【請求項４】さらに、前記抽象化通知をウィンドウ・ベースのプラットフォー
ムへ送信する出力を備えることを特徴とする請求項３に
記載のグラフィカル・ユーザ・インタフェース・ツール
キット。
【請求項５】グラフィカル・ユーザ・インタフェース
のツールキットをウィンドウ・ベースのプラットフォー
ムに移植する方法を実行するために使用される命令のプ
ログラムをコード化するコンピュータ読取り可能な媒体
であって、ウィンドウ・ベースのプラットフォームから状態変化の
ネイティブ通知を受取るステップと、グラフィカル・ユーザ・インタフェースの実行時に、前
記ネイティブ通知を、前記ウィンドウ・ベースのプラッ
トフォームに特有の処理系とは独立のネイティブ通知の
動作仕様を構成する抽象化通知として表すステップとを
含むプログラムを記録したことを特徴とするコンピュー
タ読取り可能な媒体。
【請求項６】さらに、グラフィカル・ユーザ・インタフェースの少なくとも１
つのオブジェクト・クラスに抽象化通知を含めるステッ
プを実施するプログラムを記録したことを特徴とする請
求項５に記載のコンピュータ読取り可能な媒体。
【請求項７】さらに、前記グラフィカル・ユーザ・インタフェースの実行時
に、グラフィカル・ユーザ・インタフェース・ツールキ
ット内の少なくとも１つのオブジェクトと前記動作仕様
との適合性を検証するステップを実施するプログラムを
記録したことを特徴とする請求項５に記載のコンピュー
タ読取り可能な媒体。
【請求項８】グラフィカル・ユーザ・インタフェース
のツールキットをウィンドウ・ベースのプラットフォー
ムに移植するコンピュータ・プログラムを用いてコード
化されたコンピュータ・プログラム製品であって、データを記憶するコンピュータ読取り可能な記憶媒体
と、コンピュータ読取り可能な記憶媒体に前記コンピュータ
・コードを実行させるようにコンピュータ読取り可能な
記憶媒体に記録されたコンピュータ・コード機構とを備
え、そのコンピュータ・コード機構が、ウィンドウ・ベースのプラットフォームから状態変化の
ネイティブ通知を受取る第１のコンピュータ・コード装
置と、グラフィカル・ユーザ・インタフェースの実行時に、前
記ネイティブ通知を、前記ウィンドウ・ベースのプラッ
トフォームに特有の処理系とは独立のネイティブ通知の
動作仕様を構成する抽象化通知として表すために第１の
コンピュータ・コード装置に結合された第２のコンピュ
ータ・コード装置とを備えることを特徴とするコンピュ
ータ・プログラム製品。