JPH11514114A

JPH11514114A - 動的オブジェクト指向言語のオブジェクトの間の動的関係を管理するための方法

Info

Publication number: JPH11514114A
Application number: JP9516726A
Authority: JP
Inventors: ディヴィッドシーミッチェル; ケリーエルアンダーソン; アンドリューヴィーオズマン; デイルケイミッチェル
Original assignee: ヴィューソフトインコーポレイテッド
Priority date: 1995-10-26
Filing date: 1996-10-22
Publication date: 1999-11-30
Also published as: ATE195028T1; WO1997015883A1; EP0857331B1; DE69609516D1; US5872973A; EP0857331A1; DE69609516T2

Abstract

(57)【要約】マッパを介して動的オブジェクト指向プログラミング環境におけるクラス間の名前を表示した関係を生成するための方法及びシステムが開示されている。マッピング・オブジェクトは、関連するクラスのクラス・インターフェースと動的に結合する。クラス間のこれらの結合は、ビジュアル環境内で定義される。関係は、プログラム実行中に、オブジェクト・インスタンスに名前によってプログラム的に取り付けられうる。これらの関係がリソースにストアされ、オブジェクトに対する名前によって動的に結合されるので、それらは、変更されるべく関連しているオブジェクトのソースコードを要求することなしに、生成され、修正され得る。このことは、他のコンテキストのオブジェクトの再利用を妨げるオブジェクト間のハード・コード従属を削除する。本発明は、メタデータの十分な利点、本発明と関係しているオブジェクトの十分な動的結合及びプローブ・サポートを要求し、得ている。

Description

【発明の詳細な説明】動的オブジェクト指向言語のオブジェクトの間の動的関係を管理するための方法この特許出願の一部には、著作権保護の対象である資料を含む。著作権者は、米国特許商標庁の特許ファイル又は記録に現れているような、特許書面又は特許開示のファクシミリ複写に対しては、どんな人によるものでも、異議を有さないが、その他の点ではいかなるものに対しても全ての著作権を留保する。種々の商標が、この開示に言及されている。これらの商標は、それらの商標保持者に属する。技術分野本発明は、一般的にはオブジェクト指向プログラミングの分野に関し、より詳細には、オブジェクト自身の部分の特別の挙動を要求することなくプログラムを実行する間、オブジェクト指向言語のオブジェクト間の関係を動的に生成するための構造及び方法に関する。背景技術オブジェクト指向プログラミング最も現代的なシステムの複雑性は、人間の知的能力を超えている。このことは、コンピュータ及びソフトウェアに関する必要性を作り出す。ソフトウェア開発者の基本的な仕事は、広大で、しばしば任意の外部の複雑さからユーザを保護するために簡単な幻想を作り出すことである。プログラミングは、取り扱いが複雑な仕事を、人が働く現実の世界から、プログラマがシミュレートするコンピュータ内のそれらのシステムに移す。問題は、コンピュータの内部に移されることによって、複雑性が減らないことである。複雑なコンピュータプログラムだけが、現実の世界の複雑な問題を解くことができる。複雑なソフトウェアシステムを作るとき、プログラマは、他の人と同じように知的限界を経験する。それゆえ、複雑なシステムをより小さなパーツ又はモジュールに分解することで、それらが個別に理解され、洗練され得るようにすることがプログラマにとって不可欠である。次いで、ソフトウェアツールの開発者に関する基本的な仕事は、ソフトウェアの固有の複雑性を制御し、それを保持することである。構造化プログラミング及びトップダウン設計は、前の世代のモジュラ・プログラム設計の典型である。このアプローチを使用して、プロセッサ又はアルゴリズムをより簡単なサブ・プロセッサに分解する。次いで、これらのプロセッサを実行し、複雑な全部のタスクを成し遂げるためにビーズのようなストリングで互いに繋ぐ。オブジェクト指向プログラミング（ＯＯＰ）はまた、複雑なシステムを管理しやすいサブ・システムに分解するように努力する。しかし、オブジェクト指向プログラマは、幾つかのより高いレベルの挙動を実行するために共同する自律エージェントのセットとして世界を見る。これらのエージェントの意味のある収集の構造を通してだけ、より高いレベルの機能性が達成される。全体の挙動がそのパーツの合計よりも大きいとき、これは不意の挙動である。この形態は、ＯＯＰの強力な利益である。離れ離れのオブジェクトの簡単な収集は小さな価値を有する。システムによって加えられた価値は、パーツ間の関係からきており、パーツそれ自体からはこない。その非線型分解の方法により、ＯＯＰは、マウス及びウィンドウタイプ・インターフェースで直面するランダムな入力に対してより適合する。オブジェクト指向デザイン及びプログラミングの更なる情報は、Grady Booch による「Object-Oriented Analysis and Design with Applications − 2^nded. 」(The Benjamin/Cummings Publishing Company，Inc.，1994．ISBN:0-8053-534 0-2)に与えられており、これをここにリファレンスとして組み込む。コード再利用オブジェクトをスクラッチから生成する際に費やされる出費及び労力のために、予め作られたオブジェクトを再利用することが高く望まれている。実際に、再利用可能なビルディングブロックをアセンブリすることによってプログラミング・コンプレックス・アプリケーションの目標は、コンピュータサイエンスそれロニクス・コンポーネントのエレクタセットの再利用をエミュレートすることを試みる際に、コンピュータの研究者は、より複雑な構造を作り出すことができる一般的なコンポーネントを生成するために努力する。再利用において幾らかの成功があるが、ほとんどのプログラマは依然として道のりは長いと信じている。オブジェクト指向プログラミングは、人々が現実の世界のシステム及びオブジェクトについて自然に考える方法で、より正確なモデルでありうるコンピュータ言語を作り出すための試みの外で発展してきた。より正確なプログラムのオブジェクトが現実の世界のオブジェクトを反映しているとき、次いで、プログラミングオブジェクトは、それらの現実の世界のオブジェクトのモデルが要求する他のコンテキストにおいて、より再利用可能であり得る。プログラミング・オブジェクトが、モデルにされている現実の世界のオブジェクトと無関係であるエレメントを包含するとき、次いで、それらの無関係な部分は、該モデルと密接な関係がない従属物を生成することによって、オブジェクトを再利用することを邪魔しうる。従属オブジェクトの分離は全く面白くない。満足のいく不意の挙動を作り出すために、オブジェクトは共同すべきである。関係を介するオブジェクトの共同は、リンクと呼ばれる。リンクは、オブジェクト間の物理的又は概念的な接続である。リンクは、あるオブジェクト（クライアント）が別のオブジェクト（サーバ）のサービスを請う特定の結合を示す。各リンクに関して、クライアント（トランザクションを要求するオブジェクト）とサーバ（クライアントの要求を処理するオブジェクト）がある。サーバオブジェクトはクライアントに対して可視的でなければならない。これは、典型的には４つの方法のうちの１つで成し遂げられる：１）サーバオブジェクトがクライアントに対して汎用である、２）サーバオブジェクトがクライアントの幾つかのオペレーションに対してパラメータである、３）サーバがクライアントの一部分である、或いは４）サーバがクライアントの幾つかのオペレーションに対して局所的に宣言されたオブジェクトである。１つのオブジェクトがメッセージを別のオブジェクトにリンクを越えて通すときはいつでも、２つのオブジェクトが同期されていると呼ばれる。リンクを介したオブジェクトの同期は、オブジェクト指向プログラミングの中心であり、不意の挙動のソースである。上述した４つのタイプのリンクが、サーバオブジェクトのアプリケーション・プログラミング・インターフェース（ＡＰＩ）を呼び出すコードを書くためにクライアントオブジェクトを要求することに注意することが重要である。言い換えれば、クライアントはサーバから独立ではない。実用的な用語では、このことは、クライアントが、サーバをまた再利用すること無しで、再利用されることはないことを意味する。このことはクライアントオブジェクトの再利用を減少させる。典型的には、オブジェクトが種々のサーバオブジェクトのユーティリティを当てにし得る。複数のサーバに接続することは、再利用を減少させる累積的な効果を更に有する。これは、サーバの少なくとも１つが新しいコンテキストに望ましくないことがより適当であるからである。サーバがクライアントでもあるとき、従属のウェブはプログラムのいたるところに生成される。クライアントオブジェクトコードのこれらの従属の影響は、コールバックの使用及び仮想関数を介して減少され得る。コールバックは一般的なインターフェースを備える関数であり、何か関心事が起こるとき、サーバのためにクライアントを戻すようにコールするボイド・ポインタをしばしば含む。コールバックは、クライアントが従属をセットアップしてから、クライアントの従属を発展させないようにする。仮想関数により、クライアントがサブクラス・サーバの従属を生成することなく、サブクラス・サーバがベース・サーバの挙動を特殊化することを可能にする。それにもかかわらず、クライアントはベース・クラス・サーバの従属を依然として有する。コールバック及び仮想関数は、クラスの再利用を増加させることができるが、大変な努力なしで従属の問題に完全に取り組むことはできない。クライアントが、それらのサービスにアクセスすることができるようにサーバを認識するように要求されるので、最後の結果は、それらのオブジェクトの再利用が消極的に影響する。トレードオフオブジェクトの独立を保持するための要請は、オブジェクト再利用を使用することを望む当業者にとって強い。今日、減少したほとんどのオブジェクトはサーバオブジェクトである。多くのオブジェクトはクライアントとサーバの両方である。これらのオブジェクトは、それらがクライアントとして従属する他のオブジェクトの全てと一緒に実行されることなしに、サーバとして再利用されることはない。それゆえ、そのサーバがもたらされる要求なしに、別のコンテキストにサーバとしてクライアントオブジェクトを再利用するのが望ましい。実際に、オブジェクトを一緒にリンクすることが、見込まれた不意の挙動を達成するために共有されるので、再利用はより困難である。あいにく、Ｃ＋＋のような今日の最も人気のあるオブジェクト指向言語では、これらの全てのリンクは、従属を生成するようにハード・コードされている。オブジェクト共同とオブジェクト再利用との間の緊張は、部分的に分解できるだけであり、次いで、高度な技術を持ったオブジェクト指向プログラマによってだけ可能である。ほとんどのプログラマは、問題の存在を十分には知らず、より少数のプログラマだけがそれを解明することができ、実質的には、毎日の基礎としてそれに取り組める人はいない。大抵、このことによってプログラミング言語、及び、一般に使用され今日教示されているパラダイムを制限している。望ましいオブジェクト指向の特徴Ｃ＋＋は、単一及び多重承継、多相性、カプセル封じ、メッセージング及びデータ抽象化のような人気のあるオブジェクト指向の特徴をサポートしている。これらの特徴は、これらの特徴は、ここでそれらを再評価する必要がないほど他で良く示されている。ここでリファレンスとして組み込む、Bjarne Stroustrup 著「The C++ Programming Language(2^ndedition)」(Addison Wesley - ISBN 0-2 01-53992-6)、又は、Lippman，Stanley B.著「C++ Primer(2^ndedition)」（Addi son Wesley − ISBN 0-201-54848-8）を参照のこと。これらのオブジェクト指向言語の特徴は、プログラマに直面している共通の問題の大きなクラスを解くために有用であるが、しかし、前述のクラスの間のハード・コード化したリンクを防ぐ際には役立たない。Ｃ＋＋で一般に入手可能でない４つの特徴であり、他のオブジェクト指向言語（及び、本発明に関する前提条件として要求される他のオブジェクト指向言語）のいくつかで実行される特徴は：・メタデータ（内観、反射、又は、ランタイム・タイプ情報（ＲＴＴＩ）をも指す）・十分な動的結合（ランタイム又はダイナリンク結合をも指す）・調査（残りを監視する変数又は書き込み障害をも指す）・クラス名によるデフォルトオブジェクトの例示（一般的なファクトリメソッドをも指す）である。オブジェクト指向プログラマの夢のリストを完成させる必要はないが、これらのオブジェクト指向言語の改良によって、それらを実行することなしに強力なプログラミング技術を適用することができる。これらの改良は、それらの独立を犠牲にすること、オブジェクトの再利用を容易にすること、及び、プログラムの複雑性を低減することなく、オブジェクトを共同させることができる、ここに記載されたようなシステムと一緒に使用される。メタデータは、プログラムを作るのに使用されるクラスを記述するランタイム（プログラム実行中）で利用可能なデータベースである。それによって、オブジェクトはランタイムで「自己記述」されることができる。メタデータが拡張可能であるとき、これは、アプリケーションに特化したワイド・リード・オンリー・データのクラスを有するための機会を生成する。このアプリケーションに特化したメタデータは、プロパティと呼ばれ、本発明で十分に利用される重要な言語の特徴である。しかしながら、拡張可能なめたデータを欠く言語システムでは、プロパティ情報は他のデータ構造に容易にストアされ得ることができる。十分な動的結合は、オブジェクトがそのメンバの名前だけを使用してランタイムで操作され得ることを意味する。例えば、(フィールド又はメンバがＣ＋＋において守る)属性は設定され得ることができ、照会され、関数は名前によってコールされ得ることができる。通常のリンクはマシーンアドレスに対する名前を減少させ、該名前はプログラムの使用から無くされる。調査は、データ（典型的にはオブジェクトの属性）が変更するとき、呼び出されるコールバック関数である。名前によってオブジェクトをインスタンス生成する能力はまた、本発明の実施を完成させるために必要であるけれども、これは、組み込みの特徴としてそれをサポートしない言語で容易に実行される。付録Ａ，Ｂ，Ｃ及びＤは、これら４つのオブジェクト指向言語の特徴のより長い議論を含む。特許出願 08/421,400は、言語の定義を変更することなしにこれらの特徴を欠く（Ｃ＋＋のような）エンハンス言語に関するメソッドを記載し、ここにリファレンスとして組み込む。これらの言語の特徴は、オブジェクト自身の一部の特別な挙動を要求することなく、プログラム実行中に動的に再構成可能な入力及び出力を有するための能力を一緒に備えるオブジェクトを提供する。用語「動的な言語」は、メタデータ、十分動的な結合、及び、調査をサポートし、又は、サポートするために改良された言語を意味するように定義される。オブジェクト・システム動的「オブジェクト」を生成するための多くのシステムがある。これらのシステムは、「コンポーネント・ベース」システムと呼ばれる。デスクトップに関しては、(MicrosoftのCOM及びOLE Automationを含む）ＯＬＥ及び（IBMのＳＯＭ及び AppleのOpen Scripting Architectureを同様に含む）ＯｐｅｎＤｏｃ、及び、分離されたアプリケーションに関しては、Hewlett Packard のＯＲＢ＋、IonaのOR BIX、NeXTのPDO及びSunのDOEのようなプラットフォーム・オブジェクト・システムがある。ViewSoft のエンハンスド・オブジェクト・システム (ＥＯＳ)、StepStoneのObjective C、及び、種々のSmallTalkインプリメンテーションのようなシステムに基づいた言語である。Microsoft の DLL 及び UNIX共用ライブラリの種々のフレーバーズのような動的リンクシステムがある。専用の要求（例えば、グループウェアに関するロータス・ノーツ及びデータベースに関するＳＱＬ３オブジェクトモデル）のために設計された動的オブジェクトシステムもある。最後に、Microsoft のＶＢＸオブジェクトシステム、Powersoft のPo werBuilder オブジェクトシステム、Novell AppWare Bus などのようなアプリケーションに組み込むオブジェクトシステムがある。これらの全てのシステムにおいて、「コンポーネント」は、プログラム実行中に、動的インターフェースを介してアクセス可能であるサーバオブジェクトである。これらのシステムのほとんどにおいて、クライアントは、意図しているコンポーネントシステムで特別に書かれる必要があるけれども、それらのうちの幾つか（ＥＯＳ、ＳｍａｌｌＴａｌｋ、ＰＤＯ、ＤＬＬ）では、クライアント・コードは、オブジェクトに基づいた別の通常の言語にアクセスするときより異なっておらず、かかるシステムはオブジェクトとの動的なリンクを大切にする。しばしば動的のリンクは、言語独立の方法で実行されるけれども、それらは、オブジェクト指向言語の世界として物事を処理する傾向がある。幾らかのコンポーネントシステムは、クライアントがコンポーネントに関するサーバとしてそれ自身をインストールすることができるように、コールバック・アーキテクチャを許し、この方法では、典型的には、クライアントがコールバック機能、コールバックを備えるサーバを初期化するためのコード、及び、ある場合においては、クライアントによってディスパッチされるサーバからのメッセージを提供しなければならないけれども、双方向通信が確立されうる。それにもかかわらず、システムに基づいたこれらの動的コンポーネントの人気の上昇は、コンポーネントに対する動的なリンクの基本的なアプローチを証明する。人がこれらのシステムにおいてクライアント及びコンポーネント（サーバ・オブジェクト）を生成することができることの容易さは、自明なものから本当に困難なものまで及ぶ。２つのピュア・サーバ・コンポーネントの間の同期するリンクを生成すること（即ち、あるサーバから別のサーバへの通信）は、両サーバオブジェクトについて知っているクライアントコードを生成することを要求する。サーバオブジェクト間の通信が双方向であるならば、それはクライアントが、サーバを定期的にポーリングするために両サーバ又はより少ないエレガントなコードからのコールバックを確立することを要求する。このクライアントコードは、手によるタスクに対して非常に固有であり、ほとんど再利用可能でない。クライアントが、情報を両サーバオブジェクトに適用させるために、情報を順番に変換する必要があるならば、追加のコードを書き出す必要がある。これらのコンポーネントシステムにおいて全体的に欠けていることは、サーバが互いに従属を生成することなく同期するような方法において、２つのサーバオブジェクトに対して動的にアタッチすることができる一般的なクライアントを生成することに関して無矛盾な方法であることである。クライアント／サーバネットワークットワーク(ＬＡＮ)、若しくは、インターネットのようなワイド・エリア・ネットワーク（ＷＡＮ）のようなハードウェア及びソフトウェアネットワーキングを介して接続された個々のＰＣ又はワークステーションは、現在普通に入手することができる。多くのプログラムはより効率的に作られ、ネットワークを介して配布されることによって有用である。即ち、プログラムにおけるオブジェクトのいくつかが１つのマシーン上のものであり、他のオブジェクトが複数の別のマシーン上のものであるならば、そのとき、ネットワークのパワーを処理することはより有効でありうる。しばしば、プログラムは、クライアントとサーバの２つに分けられる。クライアントプログラムは、典型的には、例えばデータベース・サーバである、サーバで走るプログラムに関してＧＵＩ（グラフィカル・ユーザ・インターフェース）フロント・エンドである。多くのかかるシステムは、複数の同時のクライアントをサポートする。ネットワーク・クライアント／サーバは、単一のプログラム内でのオブジェクト間のクライアント／サーバ関係で混乱すべきではない。ネットワーク・クライアント／サーバ関係は、オブジェクトではなく、通常は、プログラム間の通信に基づくＡＰＩ（アプリケーション・プログラミング・インターフェース）である。これらの接続は、ＲＰＣ（遠隔手順呼び出し）、ソケット、又は、他の一般的に入手可能なＡＰＩを介して作られうる。ＲＰＣは、あるマシーンのコードに関して別のマシーンの関数を呼び出させる。このアプローチは、制御のフローに関して良いが、データ共有能力は幾分制限される。対照的に、ソケットはデータを良く転送するが、プログラムフロー制御において制限される。 X-Windows システムは、ネットワークを超えて双方向イベントストリームを自動的に送信することによって、プロセッシング・サーバからＧＵＩクライアントの分離を自動化する。このことは制限されているが、分散ユーザ・インターフェースに関するアーキテクチャについて有効であり、非常に大きなネットワーク・バンド幅を要求する。依然として、このレベルのネットワーク自動化はエミュレーションの価値がある。ネットワーキング・オブジェクト典型的な複数クライアント／単一サーバ・アーキテクチャを超えた更なるディビジョンはまた、多くの場合に有用である。あいにく、現在のＡＰＩアプローチを備えたプログラムを配布することは、開発環境又は言語に普通に集積されない事実のために、プログラマに関してうんざりである。しっかりしたクライアント／サーバ・プログラムを生成するためのプログラマの学習曲線は、典型的には、非常に大きい。分散オブジェクトシステムの現在の技術水準は、Ｃｏｒｂａ，ＤＳＯＭ，ＯＲＢ＋，ＯＲＢＩＸ，ＰＤＯ及びＤＯＥによって現されている。これらのオブジェクトシステムは、データ共有及び制御のフローで優れているが、高度にＡＰＩベースである。あるシステムから別のシステムへのオブジェクトのスイッチングは、プログラマのオブジェクトとオブジェクトシステムとの間に生成された従属によって非常に困難である。即ち、オブジェクトシステムに対する特定のコードは、ネットワークを超えたオブジェクトと接続し且つ同期するように書く必要がある。これらのシステムのほとんどは、また、プログラマに極端な学習曲線を上ることを強いる。幾つかのオブジェクトシステム（特にＰＤＯ）は、動的な結合に基づく名前を直接的に介して互いにプログラムアドレスに個々のオブジェクトを有する点で達している。即ち、マシーンＡのオブジェクトが、属性にアクセスすることができ、若しくは、マシーンＢの名前による動的な結合を介して別のオブジェクトの関数を呼び出す。オブジェクト間に接続を直接的に生成することは、あるマシーンのプログラミングと分散環境のプログラミングとの間のインピーダンス・ミスマッチを減らす。言い換えれば、プログラムのオブジェクトがネットワークを超えて直接通信するとき、プロキシ・オブジェクトがオブジェクト自身内のコードに影響を及ぼすことなくネットワークの態様を取り扱うので、ネットワークＡＰＩが採用される必要はない。ネットワークを超えてアプリケーションを配布するほとんどの努力からプログラマを開放するので、それは分散プログラミングにおいて著しい進歩である。しかしながら、この場合において、クライアントオブジェクトがサーバオブジェクトのパブリック・インターフェース（ＡＰＩ）を知っていなければならず、従って、従属は、同じプログラムのオブジェクト間のクライアント／サーバ関係と同じように生成されることに注意すべきである。発明の概要目的本発明の明確な目的は、依存し、又は、お互いの知識を有するためにそれらのオブジェクトを要求することなく、ランタイムでオブジェクト間に（転送を備える）動的で再構成可能なリンクを一般的に設けるための方法及びシステムを提供することである。更なる目的は、生成されたクラスの実行に最小の影響を有するこれを行うことである。シークされるアーキテクチャは、単一のプログラム内のオブジェクト間と、同じマシンで走るプログラム及び／又はプロセス間と、ネットワークを超えて接続されたマシーンで走るプログラム及び／又はプロセス間とのサーバ／サーバ・アーキテクチャである。本発明の更なる目的は、言語がメタデータと、十分な動的結合と、プロービングと、一般的なファクトリ・メソッド能力とを支持する（又は、支持を強化する）オブジェクトの動的リンク（結合）の仕様を支持するビジュアル・プログラミング環境を提供することである。本発明の別の目的は、オブジェクトを生成するのに使用されるプログラミング言語に対する修正なしにこれらの改良を提供することである。本発明の別の目的は、リンク自身が、１つのデータ・タイプ又はスケールから別のものに転送するような追加のプログラミング・ロジックを提供することができることである。本発明の別の目的は、プログラム実行中に、インスタンス生成し、オブジェクト間のこれらの結合を破壊するための方法を提供することである。本発明の別の目的は、プログラマが、絶対に必要なもの以上に馴染んでいるプログラミング環境を修正することなくこれを達成することである。しかしながら、プログラマが使用する設計技法は、本発明によって提供される機構の適当なアプリケーションを介して、かなり変更すべきである。本発明の別の目的は、同じワークステーションで走らないオブジェクトを接続するための能力を備える動的リンクを提供することである。最後に、本発明は、ユーザ・インターフェースを構築する舞台の問題を解決するのに適用される。本目的は、それらのユーザ・インターフェースから独立したアプリケーション・オブジェクトを生成するために、本発明を使用するためのものである。これらの目的は、以下に記載された発明によって満たされる。意味論はじめに、ワードに関するワードである。一般的に、意味論は意味についての研究である。オブジェクト指向プログラミングのコンテキストではクラスの意味論はクラスが何を表現するのかを意味する。クラスの意味は発行インターフェースを通じて最も明確な証拠となる。即ち、オブジェクトが保全する属性及びオブジェクトが行う機能である。理想的には、クラスは実際のオブジェクト又は実際のシステムを設計する。実際の世界のオブジェクトの純粋モデルを作成する能力によって減じられたプログラミングシステムにより課された要求は、オブジェクトが真の意味を見失うもととなるため、あまり意味論的でない。例えば、もしオブジェクトが犬を表すとすると、本物の犬は自己を描き直さないため、描き直す機能を有する必要がない。犬オブジェクトが孤立して機能すると言うのではない。犬は猫やドッグフードやボールと交流する。コンピュータプログラムの犬オブジェクトは、後の使用のために保管する手段としてそれ自体又はデータベースシステムに表示させるためにユーザインターフェースシステムと相互作用を行う。犬は飼い主と関わるが、犬は己の内でデータベースと関わりを持たない。データベースとの関わりは犬オブジェクト自体に外部的に管理される。意味論的リンク意味論的リンクは、リンクの追加に拠る実際の世界のモデルにおける正確さをいずれのオブジェクトも失わないような方法で作られた、２つのパトロンオブジェクトの間のリンクである。パトロンオブジェクトを実現するコードはリンクを認識するべきでない。更に具体的には、本発明の意味論的リンクはサーバ間の総称クライアントをつくることにより２つのサーバオブジェクトを同期化させるシステムである。サーバオブジェクトは動的結合を経由して発行インターフェースを通して総称クライアントによりアクセスされる。同期化は、サーバにおいて興味の属性が変化する時、あるいはパトロンオブジェクトの１つが全ての興味のある集まりに明確に信号を送る時に起きる。犬は吠えるが、犬の属性を変えない。しかしながら、もしその特定の犬の吠え声に関心があれば、注意を引くかもしれない。本発明の主要機能は、動的オブジェクト指向言語において明確となったオブジェクト間の意味論的リンクを指定し、次いでインスタンス生成することである。本発明では、動的オブジェクト指向言語は、メタデータ、動的結合、及びプローブを支持、あるいは支持するように強められたオブジェクト指向言語に関する。それは、１つのクラスの１以上のメンバ（属性、機能、及びプロパティー）を拡張可能メタデータ、完全動的結合、及びプローブを支持する言語における他のクラスの１以上のメンバと動的にリンクさせることである。これは、再帰的に属性のメンバのメンバに動的に結合させる、かつ／又は調査させることを含む。意味論的リンクはマッパと呼ばれる代用オブジェクトのインスタンス生成を通して作られ、それはパトロンオブジェクトの両者に接続させるために調査及び動的結合させるのに使用する。マッパはクライアントであり、両パトロンオブジェクトはマッパに対するサーバーである。各種のマッパは固有の方法で２つのパトロンオブジェクトを接続させる。資源ファイルは各マッパの性質を更にリファインさせるために情報を有する。マッパは、数から列までのような変換を行い、あるいはメーターからフィートまでのようにあるシステムから別のシステムまでを測り、若しくはいっそう複雑なプログラミングタスクを行っても良い。マッパクラスは一般目的プログラミング言語（定まった言語条件とともに）を使用して書かれるため、多様性に対してほぼ無限の潜在性を有する。リンクインスタンスの性質は各タイプのマッパ特有のユーザ構成可能プロパティーの利用を通して更にリファインされる。マッパプロパティーはあるマッパクラスがいくつかの関連機能を行うようにする。例えば、全てのマッパは、結合が左から右へ、又は右から左へ、若しくは双方向に同期化されるかのプロパティー指定を有する。マッパ、及び要するに意味論的リンクは形式において包括的であり、機能において非常に柔軟である。意味論的リンク（問題の言語条件を超えて）におけるパトロンオブジェクトのための唯一の一般的条件は、結合されているパトロンオブジェクトの少なくとも１つの少なくとも１つのメンバがプローブをセット可能になっている必要があるということである。これは公的属性、あるいは Signal（S Ignalについての情報に関する付録Cを見よ）の使用を通して備えられる。オブジェクトは属性がその価値を変え、プローブが呼び出された時、マッパを通して同期化される(それはあるオブジェクトから他のオブジェクトへ渡された「メッセージ」である)。プローブが呼び出されずにいたら、リンクはパトロンオブジェクトを決して同期化させない。プロパティーはこのルールにおいて例外であり、プロパティーからの同期化はリンクの初期設定中に１度だけ起きる。プローブが同期化のもととなるため、システムはポーリングよりも割り込み又は需要駆動される。もし適切であれば、複数の属性がプローブされ、1 つ又は全てが変わってプローブが呼び出された時、マッピングが同期化する。マッパは、意味論的リンクのインスタンス生成の１部としてパトロンオブジェクトにプローブをセットする。換言すれば、最初の２つのオブジェクトがクライアントにならずに、第３オブジェクトによってオブジェクトが２つ互いに接続可能であり、このようにして 2 つのオブジェクト間のサーバ／サーバ体系をつくりあげる。両オブジェクトがサーバである時、不必要な従属から解放され、再利用の機会は増す。これら拡張オブジェクトの動的再構成はプログラミング又はスクリプト若しくは資源情報の解釈によって得られる。ここに説明した方法はこれら方法の全てを伴ったハイブリッドアプローチを組み入れる。我々のシステムの殆どの要求は、述べられた言語改良を介して入手可能である。このことの結果は、我々のシステムに書かれたコンポーネントに関するソースコードが、一般的に、動的に再構成可能なオブジェクトを生成するための非常に浅い学習曲線であることと実際には見分けがつかないことである。例単純な例として、クラスＢの整数ｙと同じ値を通常有する、クラスＡの整数ｘを有するのが望ましいと仮定する。意味論的リンクは、ｙが変化するときはいつでもｘを更新し、逆も同様である、ｘ及びｙの間に生成される。２つの属性の間のこの簡単なフィールド−フィールド同期は、意味論的リンクの最も簡単なタイプの一つである。その簡単さにもかかわらず、それは、実際には非常に有用であると見られていた。このリンクは、後で詳細に検討する。別のタイプの意味論的リンクは、他のパトロン・オブジェクトの関数に対する１つのパトロン・オブジェクトに１又はそれ以上の属性を関係付ける。第１のパトロン・オブジェクトの関数が、２つのパラメータをとるならば、次いで、２つの属性は他のパトロン・オブジェクトから選択される。「トリガ」属性（ユーザによって選択されたマッパのプロパティ）が変化するときはいつでも、値は意味論的リンクによって集められ、第２のオブジェクトの関数に対するパラメータとして使用される。即ち、第２のオブジェクトの関数は呼び出され、第１のオブジェクトのトリガ値が変化するときはいつでも、パラメータとして第１のオブジェクトから属性を通す。更に複雑な意味論的リンクが、パブリック属性（又は信号）とオブジェクトのアレイとの間に作られる。属性のプローブが呼び出されるときはいつでも、アレイの次のオブジェクトは、それに呼び出された関数を有する。オブジェクトが異なるマシーンに物理的に配置されているので、このマッパはディストリビュータとして作用し、ネットワークを横切って雑用を処理することを広める。実際には、多くの意味論的リンクは、これらのような一般的な特徴のものであり、それらのアプリケーションの特定の知識を有さない。もちろん、これは必要条件ではなく、本発明の現在の利用に基づく単なる観測である。単一の意味論的リンクは、リンクされている２つのパトロン・オブジェクトと第３のオブジェクトである、３つのオブジェクトを含み、セットアップの際に含まれる作業をするマッパは、意味論的リンクを維持し、編集する。マッパは、決して参照されず、若しくは、パトロン・オブジェクトのプログラム・コードに対して可視的である。それは、メタデータ・リソースファイルにストアされた使用から動的に作られる。これらの意味論的リンクが、リソースに完全にストアされ、ランタイムで動的にインスタンス生成されるので、リンクは、パトロン・クラスを実行するのに使用されるコードを変更することなく、変更され得る。マッパが、一般的な発行を処理する上で呼び出すヘルパー・オブジェクトが更にある。新しいタイプのマッパが容易に生成され、それらが任意のセットのクラス・メンバを互いにリンクすることができるので、可能な意味論的リンク・タイプのメンバは無限であるが、１００以下のマッパの慎重に作られたセットで達成される。接続接続は、意味論的リンクの名前を表示した収集である。所定の接続の意味論的リンクの全ては、同じパトロン・クラスのメンバをリンクする。それゆえ、接続は、オブジェクト同期の特定のアプリケーションの特定なタスクを実行するために調整する意味論的リンクの集約である。集約は、それがデータ構造内にあるよりも、接続のアリーナにおいて少なくとも強力でなくはない。接続はまた、他の接続の集約の目的に関して、意味論的リンクのタイプを考慮すべきである。接続は、ＡＰＩコール「edit」を介してランタイムでインスタンス生成される。編集するためのパラメータは、(それがデフォルト接続名を暗に意味することが道理にかなっているならば)接続の名前を少なくとも含む。エディット関数は、接続のメタ記述を検索するために接続の名前を使用し、次いで、ファクトリ・メソッドを使用する名前によって要求されるマッパ・クラスをインスタンス生成し、接続されるオブジェクト・インスタンス並びにプロパティにマッパを通し、マッパはそれら自身を初期化するために使用されるべきである。いったん、エディットがオブジェクトを接続して完了したならば、制御のプログラムフローは続く。エディットが返された後、パトロンオブジェクトのうちの一つの属性が変化するので、プローブが呼び出されるとき、マッパは単にアクティブになるだけである。好ましい実施形態では、各接続は、生成され、特定のクラスに属し、そのクラス（又は関連するクラス）のインスタンスで使用され得るだけである。ある意味では、接続はクラスのメタ「メンバ」である。それにもかかわらず、クラスのメタデータから幾つかの接続を別々にストアする幾つかの利点がまたありうる。接続の種類もしかすると何千もの有用なタイプのマッパがある一方、比較的少ない種類の接続がある。接続の種類は、オブジェクトを接続する基本的な技術によって区別されないが、むしろ、オブジェクトのソートが接続されることによって、ユーザ・インターフェースは接続を構築するために使用され、「edit」関数の詳細はそれらのインスタンス生成をするのに使用される。接続の種類の相違は、一般的なクラスの問題を解決する。最も一般的且つ柔軟な接続の種類は、外部オブジェクト接続である。外部オブジェクト接続は、意味論的リンクのリストと一緒に２つの異なるオブジェクト・インスタンスをリンクする。各意味論的リンクは、異なる属性と、包含される２つのクラスの関数とを一緒に関係付けることができるが、名前を表示した接続の意味論的リンクの全ては、同じ２つのパトロン・クラス・タイプ（又は、それらの同じ２つのパトロン・オブジェクトの２次属性）と一緒に関係付ける。外部オブジェクト接続は集約され得る。人が、「Ａ−Ｂ」と呼ばれる接続を有する２つのクラスＡ及びＢを有するならば、次いで、人はクラスＸとＹとの間に接続を生成することができ、ＸはタイプＡのフィールドａＦｉｅｌｄを有し、ＹはタイプＢのフィールドｂＦｉｅｌｄを有し、次いで、Ｘ及びＹの間の接続は、ａＦｉｅｌｄとｂＦｉｅｌｄとを関係付けるための「Ａ−Ｂ」接続を使用することができる。「Ａ−Ｂ」はまた、Ａと、ＹのｂＦｉｅｌｄにＡ自身を接続するＹとの間の接続に使用することができる。他の全ての接続タイプは、外部オブジェクト接続の特殊化である。追加のプロパティ情報は、他のタイプの接続に関する特定の機能性の問題を提供する。内部オブジェクト接続は、両パトロン・オブジェクトが同じインスタンスであることを除いて、外部オブジェクト・マッピングと正確に同じである。即ち、内部オブジェクト接続は、単一のオブジェクト・インスタンス内で互いにエレメントと関係する。単一のオブジェクトの２つの複雑な属性は一緒に接続されることができることを覚えているとき、内部オブジェクト接続はより意味をなす。パブリック属性のパブリック・メンバが、機能的に開けられ、互いにリンクされ売ることを記憶する。即ち、クラスＡのメンバは、クラスＡ又はクラスＢのいずれかの実行の影響なしに、(両方が、接続を有する第３のクラスのフィールドとして使用されることを仮定する)クラスＢのメンバに接続されることができる。同じクラス・タイプの２つの別のオブジェクト・インスタンスを一緒に接続することが所望されるならば、外部オブジェクト接続は、そのように行われるのに使用され得る。特注のビュー接続は、特別の問題領域に特有である接続タイプの例であり、この場合はユーザ・インターフェースを構築することである。特注のビュー接続の場合では、接続されているクラスのうちの一つは、ユーザ・インターフェース・システムのビジュアル・コンポーネントであるベース・インタラクタ・クラスをサブクラスする。インタラクタは、ダイアログ、又は、メニュー・アイテム、又は、ユーザ・インターフェース・ライブラリからの他の幾つかのオブジェクトのウィジェットでありうる。特注ビュー接続は、接続するためのオブジェクトのリストがインタラクタ・ベース・クラスのサブクラスに制限されており、プロパティがビュー・オブジェクトのデフォルト設定に関して設定されることができることを除いて、外部オブジェクト・マッピングと同じである。ビジュアル・オブジェクトに関するデフォルト設定であるこの手段が、マッピングと一緒にストアされる。特注ビュー接続は、複合ビュー接続を生成する際に使用され得る資格がある。複合ビュー接続は、特注ビュー接続の集約器である。それは、ユーザ・インターフェースのビジュアル外観の仕様を考慮に入れるプロパティを追加する。複合ビュー接続は、アプリケーション・オブジェクトをビジュアル・インタラクタ・クラスのグループに接続する。各ビュー・クラスは、以前に生成された特注ビュー接続を介して、アプリケーション・クラスのエレメントに接続される。複合ビュー接続を生成するためのユーザ・インターフェースは、ユーザ・インタフェース・ビルダのように見え、且つ、ユーザ・インターフェース・ビルダのように作用し、その上、それは、ユーザ・インターフェース・アプリケーションに関する幾つかの追加のプロパティを備える一般的な接続技術の簡単な別のインターフェースである。当業者は、これが接続の種類の包括的なリストではなく、単なる代表のリストであることをが分かるであろう。他の一般的な問題の領域は、接続の異なる種類でアプローチされうる。例えば、データベース接続は、プログラム中のクラスの構造に適合するスキーマを備えるデータベースの使用を考慮するプロパティを有する。活動がオブジェクトで生じるとき、それらはデータベースに接続される。データベースのエレメントが変更するとき、オブジェクトは従って同期される。同様に、ハードウェアであれ、ソフトウェアであれ、又は、ネットワーク・リソースであれ、どんなリソースでも要求されるときはいつでも、接続の新しいタイプが、ドメインの特定の仕方のリソースをアセンブリするように工夫され得る。これらの接続コンポーザは、根本的に異なるインターフェースを備える多数の形態をとることができる。Ｅｄｉｔ殆どのオブジェクト指向言語では、接続モデルは仕様を例示から分離する。仕様は、ビルダとして以下に記載する対話型環境で行われる。例示は、「edit」と呼ばれる関数に対してＡＰＩコールを介して達成される。この関数は、２つのオブジェクト間の接続のインスタンスを生成するために、プログラム実行中に呼び出される。一般的な種類の接続の各々は、少なくとも１つの関連するオーバーロード・エディット関数を有する。接続の名前は、(デフォルト接続が適切でなければ)通常はエディット内に通される。他のパラメータは、各タイプの接続に関して異なる。好ましい実施形態では、エディットは、共通のベース・クラスのメンバ関数であり、グローバル関数はまた、別の実施において十分である。エディット関数は接続を記述するメタデータ情報を読み込み、プローブを配置し、必要なパトロン・オブジェクトの動的結合をあらかじめ計算することによって接続に各意味論的リンクをインスタンス生成する。プロパティに対するどんな意味論的リンクも、この時に同様に同期される。プログラムの制御のフローは、エディットが接続にインスタンス生成した後に、復帰する。接続は、パトロン・オブジェクトのうちの一つのプローブのうちの一つが発射するまで、決して活性化しない。この受動的アプローチは、ポーリングよりもより効果的である。コードの構造が、従属を本当に防止するように、幾分慎重に構成されなければならないことに注意し、本発明は防止するように努めている。第１のパトロン・オブジェクトが属性として第２のパトロン・オブジェクトに対してポインタを有し、単にそれを外部オブジェクト・マッピングを備えるエディット内に通すならば、次いで、依存の複雑性は小さくなるが、コードのオブジェクト間の同じ基本的な相互依存性は依然として存在し、第１のパトロン・オブジェクトのモジュール性は強調されていない。幸運にも、オブジェクト自身のコードを修正することなくエディットを呼び出すコードを書き出すことは当業者にとって非常に容易である。外部オブジェクト接続に関するエディット関数は、接続の名前と、マップするためのパトロン・オブジェクトとをとる。Ｃ＋＋インプリメンテーションでは、パトロン・オブジェクトのうちの一つは、典型的には、「この」ポインタである。２つのオブジェクトポインタと、接続の名前とをとる、エディットの非メンバ・バージョンがまた存在する。内部オブジェクト・マッピングに関するエディット関数は、接続の名前だけを必要とする。静的バージョンはまた、オブジェクトに対するポインタをとる。これは、最も簡単なエディット関数プロトタイプである。特注ビュー接続に関するエディット関数はユーザによって直接呼び出されることは決してないが、むしろ、複合ビュー接続によって内面的に使用される。複合ビュー接続に関するエディット関数は、接続の名前と、それが現れる場所のように、上げられるインターフェースに関する情報を特定するパラメータとをとる。ビュー・クラスは、プログラマのコードには現れないように、一般的なファクトリ・メソッドを介して常にインスタンス生成される。データベース接続に関するエディットは、接続名に加えてデータベース名をとる。システムのコンポーネント本発明は１組の共同システムから構成される。プログラマは、ビルダに利用可能となるメタデータのオブジェクト間の接続を特定する視覚対話型ビルダプログラムを使用する。好ましい実施形態において、リンクされるクラスは、該クラス間の接続を特定するために使用される同じビルダを用いても生み出される。プログラマが、クラスを組立て接続し終えると、接続の特定化を含めクラスのメタデータを情報ファイルに蓄える。プログラムが実行されている間、該情報ファイルは“エディット”によってメモリーに読取られ、該リンクは、力学的な巻き付けや、情報ファイルの青写真に従って動くオブジェクトを取り付けるための調査を使用することによって力学的に確立される。ビルダ本発明に関する相互作用ビルダの主な目的は、互いにマップされ、指名された接続を生み出すクラスを選択することである。異なるクラスの接続があるため、マッピングを作り出すインターフェイスは根本的に異なる。使用者の行いが接続を生み出しているということが明らかであるときがある。他には、使用者は全く無関係なこと、例えば使用者のインターフェイス又はデータベースを生み出していることが明確であるときもある。優れたビルダは、特別な接続タイプのために手近に機能させる必要な詳細レベルを提示するだけである。例えばマッパの特性を制御することは必ずしも必要ではない。マッパを直接使用する複雑さは、ある目的のために隠されている。接続を作り出すインターフェイスは、接続の所有者としてクラスを選ぶことである。次に新しい接続指示を選択する。以上が達成されると、使用者に様々なオブジェクトの機能、属性、プロパティ、補助機能、補助プロパティ、補助属性間のリンクリストを作り出せるようにダイアログが表示される。該クラスは、その属性、プロパティ、機能を階層的視点で示される。属性はクラス自体であるとき、該階層は拡大する。かつ、全ての要素はプロパティを有し、これらのプロパティが特定の整数分野に存在する場合、整数分野は“最小価値”及び“最大価値” プロパティを示すために拡大される。機能及びクラス自体もプロパティを有する。所定部材を一緒にマップするようにマッパが組立られる場合、プロパティ及び又は属性及び又は機能は、他の１組にマップされる。１組の部材が、マッピングダイアログの両サイドに選択されると、これら２組の部材をマップするために使用される全ての接続リストが生じる。各マッパは、実証機能を使用して所定のセットに接続するか否かを決定する。特定のマッパが選択されると、接続を構成するリンクのリストに加えられる。マッパは、マッピングの動きを改良するようにエディットされる属性を備える。これらの属性は各マッパタイプに特定されるが、引き出されたマッパの属性が、上鋼から受け継ぐ属性を必ず有する。全てのマッパが共通の基本クラスを共有するので、それらは全て少なくとも基本クラスを備えている。リソース・ファイル好ましい実施形態では、ビルダによって作り出されたリソース・ファイルは、ビルダに特定されるクラスを定義する各プログラマに関するエントリを備えたメタデータのデータベースを包含する。接続は、それらが異なるインプリメンテーションに別々にストアされているとしても、接続に含まれているクラスのうちの 1 つとともにストアされる。リソース・ファイルは、テーブルとして知られる階層構造の属性を持ったデータ構造である。テーブルは、容易に拡張可能な仕方で、（データベースと同様に）一般的な情報をストアする能力がある。クラスに関してストアされた情報の一部は、それ自身内のそのクラス及び他のクラスを接続するためにビルダに接続された全ての接続のリストである。情報は、(特定のクラスに関する各接続が一意的な名前を有する必要がある)マッピングの名前と、このマッピングがリンクするクラスと、接続を作る（プロパティと）リンクする個々のリストとからなる。各意味論的リンクに関するメタデータは、属性と、プロパティと、２つのクラスに接続されている関数名と、マッパが要求するいなかるプロパティ情報とをストアする。ランタイム・ライブラリ本発明は、コンパイラ自身を修正することなく、オフザシェルフ・コンパイラをサポートする。接続は、ランタイム・ライブラリの関数を呼び出すことを介して、完全にサポートされる。ランタイム・ライブラリは、実行可能なプログラム内にリンクされている。このライブラリは、オブジェクト間のインスタンス生成（edit）及び破壊（stopEdit）接続に関するルーチンにアクセスを提供するクラスを包含する。また、これを援助するランタイム・ライブラリの他のクラスがある。この開示に関するクラスの最も顕著なファミリはＥｏｓＭａｐＥｌｅｍｅｎｔのサブクラスである。このベース・クラスは、選択された２つのクラスのセット間の単一なリンクを生成する基本的な機能性を提供する。それは、適当なマッパのリストのメンバーシップを判断するためのルーチンと、マップされているクラスに対してストアされたそのプロパティを介して、それ自身を取り付けるためのルーチンと、マッピングのランタイム挙動を判断するのに使用されるプロパティを得、設定するためのルーチンとを包含する。実行可能なプログラムライブラリが、プログラマのコードとリンクされるとき、実行可能なイメージが生じる。実行可能なプログラムは、プログラマノクラスと、(リソース・フォークに実行可能に結び付けられ得る)リソース・ファイルとからなる。プログラムが走るとき、メタデータがアクセスされ得るように、プログラムはリソース情報をメモリ内にロードする。接続は、接続されているクラスのメタデータにストアされる。プログラマノクラスは、メタデータを翻訳させることができるランタイム・ライブラリからのエディット関数にアクセスし、接続は、この実行可能なイメージの実行中に動的に確立される。図面の簡単な説明図１は、簡単なフィールド−フィールド意味論的リンクの詳細な図である。図２は、ネットワークを超えて接続された別々のマシーンの一つのパトロン・オブジェクトを備える、図１のような同じ簡単な意味論的リンクを示す。図３は、タイプ・エレメントに関するクラス階層構造を示す。図４は、接続を特定するための好ましい実施形態に対するインターフェースを示す。発明の詳細な説明序論次に、本発明の好ましい実施形態が示されている添付図面を十分に参照して本発明を説明する。しかしながら、本発明は多くの異なる形態で実施され、ここで説明する実施形態に限定して構成される必要はないが、この実施形態は完全に完了しており、本発明の範囲を当業者に十分に伝え得るように提供されている。本発明は、一般にパーソナル・コンピュータ（ＰＣ）又はワークステーションと呼ばれる汎用コンピュータで実施される。本発明の幾つかの態様は、コンピュータがネットワークに接続されていることを要求する。明細書のこの部分は、最初に、例示され接続された後の接続の構造及び管理を、次いで、記述子データからの接続の例示、最後に、ビルダ・プログラム内の対話式のそれらの接続の使用に関する方法を説明する。付録としてここに添付したものは、本発明の要素の例示的な実施形態である。本発明の実施に適当な変形実施形態があることは当業者には明らかであろう。単純な意味論的リンク図１は、２つのオブジェクト間に単純な意味論的リンクを備える接続に含まれるオブジェクトを示す。以下に記載するような機構を介して接続が既に生成されていると仮定すると、このことによってオブジェクトの構成が生じる。EosMapFi eldToField オブジェクト（１０３）は、好ましくは各パトロン・オブジェクトのフィールド(１０１)、(１０５)にプローブを設定する。これらのフィールドのうちの１つを変更することは、マッパを介して同期を開始する。以下のステップは、左のフィールド（１０１）が変更されたときに生じる。１．左側のフィールド（１０１）が変更されたとき、そのプローブ・コールバックの全ては呼び出される。２．EosMapElement::leftHandSideCallback 即ち、EosMapFieldToField（１０３）のメンバが呼び出される(これは生のプローブ・コールバックである)。変形実施形態では、このコールバックは EosFieldElement（１０７）になされることに注意すべきである。３．フラグは、マッパが稼動中である指示を設定する。(フラグは、leftHandSid eChangedが復帰した後、消される) ４．次いで、leftHandSideCallback は、leftHandSideChanged と呼ばれるマッパ・クラスの仮想関数を呼び出す。５．leftHandSideChangedのベース・クラスの実行は、valueChangedと呼ばれるマッパの仮想関数を呼び出す。殆どのマッパが、方向にかまわずに変形を行うために、leftHandSideChanged の代わりに valueChanged を置き換える。パラメータは、変更するフィールド、変更するタイプ・エレメント(この場合は左側(１０７))、及び、別の側の（１０４）に関するタイプ・エレメントである。タイプ・エレメントは、フィールド、関数、プロパティ、又は、メンバのリストを表し得る。 void EosMapElement::valueChange(EosProbeObject *scr,EosTypeElement *scrEl,EosTypeElement *destEl); フィールド・マッパに対するフィールドの単純な場合では、valueChangedは単純に、(変更される)ソース側パラメータから値を得て、宛先側の値を右タイプ・エレメント（１０４）を介してこの新しい値に設定する。６．右タイプ・エレメント（１０４）は、フィールド（１０５）を動的結合機構を介して右側オブジェクト（１０６）に設定する。できる限り効率的に行われるように、タイプ・エレメントは既に、フィールド名からフィールドのインデックスをあらかじめ計算してある。７．次に、プローブは、マッパのrightHandSideCallbackを呼び出させうる右側フィールド（１０５）に発射する。(また、変形実施形態では、これはマッパに直接なされるのではなく、フィールド・エレメント（１０４）になされうる。) このコールバックは再び、マッパ・アクティブ・フラグが設定されているか否か見るために検査し、それまで、プロセッシングは停止し、即ち、値は左側フィールド（１０１）に転送されない。この検査は、マッピング機械内の無限ループを避けるのを助ける。(プローブ機構はまた、循環整理編集機構を有するが、それをマッパに加えることはより有効であり、より安全である。)もちろん、この挙動は、そのように行うことが道理に適う場合に置き換えられる。他のオブジェクトはこの値に配置されたプローブを有し、プローブが発射されていないならば、それらは同期され得ないので、プローブはフィールド（１０５）に発射されなければならない。まず右側フィールド（１０５）が変更し、次いで、rightHandSideCallback が情報を valueChanged に転送しうるが、パラメータは方向の変更を反映するように反転される。 valueChanged、leftHandSideChanged 及び rightHandSideChanged の実施の正確な詳細は、もちろん、各マッパ・サブクラスのために変更しうる。一般的な機構は、殆どの重要な場合を取り扱うのに十分柔軟である。この単純な場合では、マッパは値に沿って変更されずに、左側パトロン・オブジェクトから右側パトロン・オブジェクトに通される。しかしながら、マッパが、値を備えるどんなものも行うことができることに注意すべきである。それを韻律ユニットから英語ユニットに変換することができ、数をデータベース内のインデックスとして使用することができ、フィールドをレコードＮから第２のパトロン・オブジェクトに通すことができる。強健なブログラミング言語でなされるどんなことも、マッパの内部でなされ得る。しかしながら、マッパが双方向ならば、変形はいつも推移されるべきである。即ち、変形は両方向であり得る。さもなければ、循環整理編集機構は、幾つかの場合に生ずる偽物を作り出し得る。一般的に得られるものの多くは、マッパに関するベース・クラスEosMapElementのＡＰＩからきており、また、意味論的リンクの各側を備えて包含するメンバを表すタイプ・エレメントからもくる。図１に示したように、接続されている各オブジェクトに関する単一のタイプ・エレメントがある。複数のメンバがマップされるならば、タイプ・エレメントは他のタイプ・エレメントのリストを保持する。ネットワーク考察図２は、第２のマシーンの右側パトロン・オブジェクト（２０６）を備える図 1 と同じ意味論的リンクを示す。図１（１０１）又は（１０５）のパトロン・オブジェクトのフィールドのいずれか又は両方が、ネットワーク・プロキシ・オブジェクトによって置換され得ることに注意すべきである。パトロン・オブジェクト（１０６）が実際にネットワーク・プロキシ・オブジェクト（２０６）であるとき、細部はわずかに変更する。本質的に、プロキシ・オブジェクトは、それがあらわすオブジェクトであるように装う。このような一般的なプロキシは、オブジェクトを直接オフにする関数を含むような、通常の非動的言語構文を取り扱うことができないが、それがパトロン・オブジェクトであるかのように、検査及び動的結合のサービスを提供する。これは、動的結合及び検査が、言語において全てのクラスに関して同じだからである。タイプ・エレメントは、データを動的結合を介して通常の方法でプロキシ・オブジェクトに設定するが、プロキシ・オブジェクトは、ネットワークを超えて実在のオブジェクトへのメッセージをパッケージ化し且つ送信する面倒を見る。好ましい実施形態では、ネットワークプロトコルは、一般に入手可能なＲＰＣベース・ネットワーク・ライブラリを使用して実行され、それらはメッセージ、変更されたデータ、及び、設定されるエレメントのフィールドに対するパスを送信するためのオブジェクトに関する識別子を有する。それがネットワークの他の側に対するＲＰＣコールを作り上げるとき、プロキシ・オブジェクトが情報の３つの形態を取り扱うことができるように、動的結合は、インデックスによってフィールドを得て、且つ、設定し、若しくは、インデックスによって関数を呼び出す。異なるマッパが全て標準形態に入れられるように、異なるマッパはこれらの異なるタイプの情報を生成する。ＲＰＣ実行の詳細は、この明細書の範囲を超えているが、一般に入手可能である。ＥｏｓＰｒｏｘｙプロキシ・オブジェクトは、接続オブジェクトと、接続に含まれるルート・オブジェクトをポイントするためのオブジェクトと、(以下に説明する)サブフィールドを得るためのパスと、それが示すフィールドの名前とを備えて構成されている。 EosProxyProbeObject(EosConnection *connection,EosObject *object,const EosObjectPath &path,const EosAtom &name); 各プロキシがセットアップされるとき、一意的な識別子はネットワークの両側のオブジェクト・インスタンスのために生成される。セットアップ中にｉｄが他のマシーンに通されるように、各マシーンのｉｄは異なっていても良く、この場合、オブジェクトは後でアクセス可能であり得る。両マシーンは、ＩＤをそのマシーンのアドレス空間の実際のポインタに変形するのに使用されるルックアップ・テーブルを有する。プロキシ・オブジェクトはまた、サブクラス・パスのエレメントが変更するときはいつでも、それ自身をリセットしなければならない。プロキシ・オブジェクトの例示的な実施形態を付録Ｉに与える。プローブ・オブジェクト・クライアントとプローブ・オブジェクト・サーバがあることに注意すべきである。クライアントがリンクを初期化することだけが異なる。例示した後、双方向通信リンクが確立される。クライアントは、クライアントＩＤ番号を通すサーバのsetupServer関数を呼び出すためにＲＰＣを使用し、次いで、サーバＩＤ番号バックを通すクライアント・バックを呼び出す。ネットワークを超えてオブジェクトをはじめに分散することの詳細は、この明細書の範囲を超えている。ＥｏｓＣｏｎｎｅｃｔｉｏｎ EosConnection クラスは、ネットワーク接続に使用されるＲＰＣコールのまわりの単純なラッパである。しかしながら、同じマシーンのオブジェクトと通信する種々のプロキシ・サーバ・オブジェクトがあるならば、各 EosProxy は接続に対するポインタを有し、次いで、それらの全てのサービスに対して１つのEosCon nection インスタンスである必要がある。(付録Ｉで分かるような)接続は、それが一緒に通ることができる種々のタイプのメッセージを有する。それは、正しいインスタンスに対する正しいメッセージを得るために、前述したオブジェクトｉｄを使用する。それは、データを変更するよりプローブを発射するために、わずかに異なるプロトコルを使用する。ある違いは、プローブが発射のプロセスにあるならば、接続は、(マッパそれ自身が無限ループを減少させることと同じように)第２のプローブ発射が交換をはじめるのではなくマッパに戻らないことがわかることである。この場合、マッパ・オブジェクトが第３のマシーンにあるならば、それは第３のマシーンによってネットワーク・トラフィックを低減させる。パス・オブジェクトパス・オブジェクトは、オブジェクトに動的結合を介して接続するタイプ・エレメントのパスである。本発明の重要な特徴の１つは、パトロン・オブジェクトのサブメンバのサブメンバのサブメンバが、必要な限り下方へ接続され得ることである。パス・オブジェクトは、重要なメンバを得るためにオブジェクトをトランスバースするための情報を包含する。複数のメンバ・マッピングの場合では、各メンバは、それ自身のパスを有し、サブ・メンバと異なり得る。パス・オブジェクトは、実際のメンバを得るためのこのパスのメンテナンスの処理をする。このことは、マッパが、プローブを配置し、若しくは、それと動的に結合する実際のフィールドにアクセスすることができるようにすることが重要である。インデックスによってフィールドの値を設定するために動的結合機構を使用することができるように、メンバ（親オブジェクト）を含むオブジェクトを見つけることは、タイプ・エレメントによってまた使用される。(これは、メンバとの動的結合が、メンバを包含するオブジェクトに関する指標付けされたメンバとして実行されるので、必要である。)もちろん、これは関数に適用できるが、関数は、プロパティを有しないならば、サブ・メンバを有さず、関数は通常パスの葉ノードであり得る。プロパティに関して、親オブジェクトが、プロパティを備えるメンバを包含するオブジェクトであることに注意すべきである。プロパティは、理論的にはサブ・プロパティを有し得るけれども、パスの葉ノードでもある。整数のような基本フィールドは、(プロパティではなく)サブ・メンバのいずれも有さない。それゆえ、サブ・メンバは、それら自身のクラスであるフィールドに関してのみ存在する。ルート・オブジェクト自身に関する特別な場合が存在する。即ち、意味論的接続が、そのオブジェクトのメンバ又はサブ・メンバではないマッピングを有するオブジェクトに対して生成されるならば、次いで、パスは空である。この場合、親オブジェクトは無く、タイプ・エレメントは、オブジェクトそれ自身に対するその意味論的リンクと単に接続する。パス・オブジェクトはまた、作動中のプログラムにおけるオブジェクトの動的特性に関連する幾つかの本当に困難な状況を解く。例えば、意味論的リンクがポインタ・フィールドの内部のフィールドに作られ、ポインタ・フィールドが新しいオブジェクトをポイントするために返還されるならば、次いで、マッパは、第１のオブジェクトに対してそのプローブを分離しなければならず、そして、新しいオブジェクトに対して再接続しなければならない。サブ・フィールドのサブ・フィールドに対する添付は、フィールド名のパスを保持することによってトラックを保持する、例えば、fieldA.fieldB.fieldCは、fieldCが、fieldAのメンバであるfieldBのメンバであることを意味する。パス・オブジェクトは、これらの中間レベルの各々にプローブを配置し、中間レベルが変化するとき、それはそれらのプローブをリセットするためにマッパの関数を呼び出す。マッパは古いオブジェクトから切り離すことができなければならず、それらがランタイムで変更するときに、それら自身を新しいオブジェクトに再び取り付けるが、パス・オブジェクトは複雑な簿記を全て行う。生のプローブ機械は、プローブに対する個々のインスタンスに気づいているだけであり、マッパ及びパスが行うような必要があるので、切り離し及び再取り付けをする文脈上の能力を有していない。プローブが手によって配置されるならば、この関数は自動的には得られない。動的結合及びメタ・データは、プローブを配置するための新しいアイテムを見つけるのに使用される。パス内の中間ポインタ・フィールドの値が、ＮＵＬＬに設定されるならば、次いで、プローブは古いオブジェクトから除去されるが、もはや接続されるオブジェクトがないので、再び接続されることはない。また、パスを更に下げるパス・メンバのどんなプローブ・セットも除去され得る。同様に、ＮＵＬＬポインタが、有効なオブジェクト・ポインタに割り当てられているならば、プローブは除去されないが、単純に加えられる。プローブは、オブジェクトのマッパによって、及び、更なる中間パス・エレメントのパス・オブジェクトによって配置され得る。同様に、接続に含まれたオブジェクトのうちの１つが、ある理由で削除されるならば、接続は自動的に切断される。パス・オブジェクトは、この発生を判断する際に、役立ち得る。リファレンス・カウント・ポインタリファレンス・カウント・ポインタとは、このシステムにおける全てのポインタの好ましい実施形態の事実の全ての実行を大いに簡単にするものであり、即ち、あなたは他人によってポイントされるかもしれないアイテムを直接削除できず、それに対するあなたのリファレンスを移動させることができるだけであり、それがそのリファレンス・カウントを減少させる。リファレンス・カウントがゼロに向かうならば、それはそれ自身を壊す。パスを変更することの例では、ポインタをＮＵＬＬに対して設定し、次いで、それが他のオブジェクトに対する最後のリファレンスならば、それを削除し得る。しかしながら、パス・オブジェクトが、ポインタを再び割り当てることの部分として、オブジェクトのプローブを移動させるためにマッパを知らせる。次いで、パス・オブジェクトは、削除する前のプローブの移動を管理する際に、非常に重要である。このことが正しいオーダーで行われるならば、次いで、あなたは既に自由になっているリファレンス・メモリであってよく、そこで、リファレンス・カウント・ポインタとパス・オブジェクトとの組合せは、含まれた発行の全てを十分にアドレッシングするのに基本である。パスはまた、早まって壊されないように、リファレンスをオブジェクトに保持する。リファレンス・カウント・ポインタは、不要部分の整理と呼ばれる技術の実施である。タイプ・エレメントシステムの設計の目標の一つは、できるだけ容易な新しいマッパ・クラスを構築させることである。単純なマッパを要求することは、メタ・データの発行を直接配り、動的な結合はそれらの実行を過度に複雑にする。タイプ・エレメントは、できるだけ一般的に、(マッパの観点から)パトロン・オブジェクトにアクセスさせるように導入される。各マッパ・クラスは、左側に関するものと、右側に関するものとの２つのタイプ・エレメントを有する。もちろん、左及び右という名前は、コンピュータに対して特別な意味を有しておらず、(後で説明するユーザ・インターフェースに関連するものであるが)人の消費に関するものである。タイプ・エレメントの一つの主要な関数は、関数、プロパティ、及び、可能な限りフィールドのようにみえるメンバのリストを作る標準的なインターフェースを有することである。マッパと可能な限り同じように見えるこれらの言語エレメントの全てを有することは、マッパが、特別な目的コードに共通の一般的なケースを取り扱わせないことを意味する。図３は、タイプ・エレメントの階層構造を示す。ＥｏｓＴｙｐｅＥｌｅｍｅｎｔＥｏｓＴｙｐｅＥｌｅｍｅｎｔ（３０１）は、他の全てのタイプ・エレメントに関するベース・クラスである。それは、他のタイプ・エレメント・サブクラスに関する共通のベース・レベルＡＰＩを提供する。それは、他の全てのタイプに関する同様なサービスを提供するよう努力するが、それはフィールドに最も良く似ている。特に、そのようにするのを検知させる多くの場合と同じようなフィールドのように作用する、関数及びプロパティを作ることを試みる。例えば、リスト・エレメントを除く全てのタイプ・エレメントは、データを設定するための関数と、データを得るための関数とを有する。ＥｏｓＴｙｐｅＥｌｅｍｅｎｔｓ（並びにマッパ）は、それらが名前などで生成されることができるように、パトロン・オブジェクトとして同じ言語要求（プローブ、メタ・データ、動的結合及び一般的ファクトリ方法）を言語でプログラムされるべきである。実際に、タイプ・エレメント及びマッパは、それらが同じ言語ならば、最も便利であるように、同じ実行可能なプログラムでなければならない。全てのタイプ・エレメントの殆どの機能性は、ＥｏｓＴｙｐｅＥｌｅｍｅｎｔとのインターフェースを介してアクセスされる。即ち、機能性は、アクセスされ、ＥｏｓＴｙｐｅＥｌｅｍｅｎｔの共通ＡＰＩを介してアクセスされる殆どの部分であるサブクラスの仮想関数に曝される。これは、そのようにすることを検知するとき、同様な仕方で各タイプの仕事を作る。動的結合は、クラスレベルで行われ、フィールドレベルでは行われないので、メンバ自身に加えて、メンバを保持するオブジェクト・インスタンスに気づいているべきであることは各タイプ・エレメントに関して重要である。親ポインタは、タイプ・エレメントにとっての関心事のメンバを包含するオブジェクトをポイントすることによってこのタスクを成し遂げる。また、これはリファレンス・カウント・ポインタであり、親オブジェクトが自由になることができる前に、タイプ・エレメントが自由にならなければならないことを意味する。タイプ・エレメントはこれを（タイプ・エレメントのメンバである）パス・オブジェクトから得る。タイプ・エレメントはまたプロパティを有するが、これらのプロパティは、タイプ・エレメントの状態をストアするのに簡単に使用される。ユーザは、これらのプロパティに決して曝されず、持続性機構として使用されるだけである。これらのプロパティをユーザに曝すことによって得られ得る更なる機能性はなく、それはシステムを理解するのをより困難にさせ得る。マッパは、必要ならばそれが所有するタイプ・エレメントのプロパティを設定し、得る。最も重要なタイプ・エレメント・プロパティは、情報が流れることができる方向に関する。タイプ・エレメントはまた、タイプ・エレメントの種類を報告することができる。ＥｏｓＦｉｅｌｄＥｌｅｍｅｎｔマップされるべき言語エレメントがパトロン・オブジェクトのデータ・フィールド・メンバ（属性）であるとき、ＥｏｓＦｉｅｌｄＥｌｅｍｅｎｔが使用される。ＥｏｓＦｉｅｌｄＥｌｅｍｅｎｔ（３０２）に対するインターフェースは、実質的に全く同じＥｏｓＴｙｐｅＥｌｅｍｅｎｔのものであり、即ち、ベース・クラスである。フィールド・エレメント（及び他のエレメント・タイプ）は、情報が流れ得る方向を判断するためにマッパと相互作用する。殆どの現実のフィールドに関して、情報はフィールドへ及びフィールドから流すことができる。マッパは、一方向に情報を転送することを決定するだけであるが、それはフィールドの情報に限られない。これに関する必要性は、種々のタイプ・エレメント・サブクラスがフィールドの挙動をどのようにエミュレートするか議論されるので、明らかになるはずである。それは、マッピングが、いずれか若しくは両方の方向に情報の流れを有し得ることを説明するのに十分である。ＥｏｓＦｕｎｃｔｉｏｎＥｌｅｍｅｎｔマップされるべき言語エレメントがパトロン・オブジェクトのメンバ関数であるとき、ＥｏｓＦｕｎｃｔｉｏｎＥｌｅｍｅｎｔは使用される。このエレメントは、関数パラメータ・リスト・メタデータ情報にアクセスするための追加の能力を有する。関数は、これらの形に続く： void func(Type); Type func(void); は、クラスＴｙｐｅのフィールドとして処理される。Ｔｙｐｅは、一般的な形の損失を除いて、定数、＆、＊等によって修正され得る。この抽象化は、データを得るか又は設定するための関数を呼び出すことを意味するようにデータを設定し及び得ることを無効にするＥｏｓＦｕｎｃｔｉｏｎＥｌｅｍｅｎｔによって提供される。タイプ・エレメントを読み且つ書き込む方向を決定する関数は重要なものであり、一つは、値を返す関数に値を書き込まず、又は、パラメータを得る関数から読み込む。言い換えれば、タイプを返す関数は読み込み専用フィールドのタイプとして処理され、パラメータを得る関数は、書き込まれることだけが可能なフィールドとして処理される。この特別な場合は、特別なケース・コードを要求する各マッパなしで、フィールド（又は他の関数）に対して関数を関係付けるように、フィールドを一緒に関係付けるように書き出されたマッパに関してそれを可能にさせる。このことは、方向を決定する仮想関数のアクセス、値を返すｇｅｔＲｅａｌＰｒｏｂｅＯｂｊｅｃｔ、値を設定するｓｅｔＰｒｏｂｅＯｂｊｅｃｔＶａｌｕｅを介して達成される。もちろんアクセスに依存するので、ｇｅｔ又はｓｅｔ関数は、呼び出すのに有効でないかもしれず、マッパはそれを呼び出さないかもしれない。関数が上の形に適合しない多くの場合では、関数エレメントは、関数パラメータにアクセスし、関数パラメータを作るために関係付けるためのマッパに関する追加のＡＰＩインターフェースを提供する。マッパに関して、より一般的な関数インターフェースとインターフェースするために、それが関数を扱うことを知らなければならず、従って、作動する。これがしばしば使用されないかもしれないので、十分な関数インターフェースにアクセスすることは、より柔軟且つ強力である。Ｇｅｔ／Ｓｅｔ関数ペアＧｅｔ／Ｓｅｔ関数は、それらと互いに関連する特別なプロパティを備える関数である。ｇｅｔ／ｓｅｔ関数ペアを包含する３つのエンティティがある。ｇｅｔ関数については、 Type getFunc(void); の形態の関数であり、ｓｅｔ関数の形態は、 void setFunc(Type); であり、プローブは、利害関係があるサード・パーティが、ｇｅｔ関数を呼び出すとき知るのに使用するフィールド（可能ならば信号）を使用可能にする。ＥｏｓＦｕｎｃｔｉｏｎＥｌｅｍｅｎｔの助けと一緒に、計算されたフィールドとして３つのエンティティ関数がある。ｇｅｔ関数は、プロパティとしてプローブ使用可能なフィールドの名前を有し、ｓｅｔ関数は、プロパティとしてｇｅｔ関数の名前を有する。ｓｅｔ関数はオプションであり、この場合、ｇｅｔ／ｐｒｏｂｅの組合せは、オブジェクトの読み込み専用フィールドとして作用する。ＥｏｓＦｕｎｃｔｉｏｎＥｌｅｍｅｎｔはＥｏｓＴｙｐｅＥｌｅｍｅｎｔのサブクラスなので、マッパは、それらが取り付ける（フィールドではなく）関数である知識なしで、関数エレメントに接続することができる。ベース・クラス・マッパは、マッピングが生じうる方向について知っているので、タイプ・エレメントは、情報に関するソース又は宛先であり得るその能力として、マッパにフィードバックを与えなければならない。ＥｏｓＦｕｎｃｔｉｏｎＥｌｅｍｅｎｔがｇｅｔ／ｓｅｔ関数ペアを取り扱うとき、次いで、それは双方向情報フローを備えるフィールドとして正確に作用する。ｇｅｔ関数に関して、フィールドのようなものを見る際に参加するために、それらは関連するプローブ・フィールドを有しなければならない。ｇｅｔ関数及び（ｓｅｔ関数を除く）信号があるならば、次いで、それはインフォレーションのソースのみとなるであろう。ＥｏｓＰｒｏｐｅｒｔｙＥｌｅｍｅｎｔＥｏｓＰｒｏｐｅｒｔｙＥｌｅｍｅｎｔは、クラス、フィールド又は関数のプロパティにマッピングするとき、使用される。同様に、値が、フィールドを取り扱うことにだけ気づいているマッパによって、プロパティから他の言語エレメントにマップされ得るように、ＥｏｓＰｒｏｐｅｒｔｙＥｌｅｍｅｎｔは、フィールドとして処理される。言い換えれば、ＥｏｓＭａｐＦｉｅｌｄＴｏＦｉｅｌｄマッパは、たとえマッパがプロパティに気づいていないとしても、別のパトロン・オブジェクトの整数に対するプロパティをマップすることができる。タイプ・エレメントの各クラスはまた、マッパが知るのに必要な場合、仮想関数を介するそのタイプに対してそれ自身を識別することができる。プロパティはプローブを有しておらず、それゆえ、それらは、初期化中、紹介されるだけである。好ましい実施形態では、プロパティはランタイムで変化しない。ランタイムでの変化が要求されるならば、フィールドはこの役割を十分に果たす。また、プロパティ情報がインスタンス・ベースではなく広いクラスなので、マッパがランタイムでのプロパティ値を変更することができることは、所望しない影響を導くかもしれない。静的フィールドは、要求されたとき、データに基づいたクラスの役割を果たすことができる。次いで、プロパティは、マップされるオブジェクトのフィールドを初期化する（又は関数を呼び出す）ためのソース情報として使用される。例として、整数値が、ＧＵＩシステムのスクロールバー・オブジェクトにマップされることを想定する。スクロールバーは、最大値、最小値及び現在の値を有する。この場合、一つは、スクロールバーの最小値に対するｉｎｔの最小プロパティをマップし、最大プロパティを最大値に、整数自身をスクロールバーの現在の値にマップする。プロパティがソースだけであるので、初期化の方向は、プロパティからスクロールバーに暗に示されている。しかしながら、インテジャに関する初期化の方向は、両方に流れることができるので暗に示されない。インテジャに関するこの場合では、スクロールバーを初期化することは重要であり、スクロールバー・オブジェクトが、アプリケーションの意味論としてのアイデアを有さないので逆もまた同様である。従って、ちょうどそのような場合における初期の初期化の方向を決定するベース・マッパ・オブジェクトの追加のプロパティがある。ＥｏｓＴｙｐｅＥｌｅｍｅｎｔＬｉｓｔＥｏｓＴｙｐｅＥｌｅｍｅｎｔＬｉｓｔは、１以上のメンバにマッピングするときに使用される。それは他のタイプ・エレメントのリストを取り扱うために追加の機能性を包含し、エレメント自身のアレイと、インデックス機構を介してエレメントにアクセスするための関数とを包含する。マッパが（妥当性検査を備えて）指定される仕方のために、複数のタイプ・エレメントを取り扱う仕方は、ランタイムで取り扱うＥｏｓＴｙｐｅＥｌｅｍｅｎｔＬｉｓｔを決して有さず、これを取り扱うための特別のケース・コードが最も簡単なマッパに関して必要ではない。マッパ・クラスの好ましい実施形態では、単一のメンバに対するメンバのリストを取り扱うための別の仮想関数である。ことことにより、単一のメンバを互いに関係付けるマッパ・クラスの実行を大いに簡単にする。複数のメンバを関係付ける必要があるこれらのマッパに関して、直接結合すること、及び／又は、適当なフィールドを調べることを要求する全てのエレメントにアクセスするための関数がある。これらのタイプのマッパは、更なる知識を備えることが要求されるそれらに関して適当であるので、単一のフィールドを単一のフィールドにマップする簡単なマッパよりもより特別である。タイプ・エレメントタイプ・エレメントは多くのケースに及び、単一のマッパはマッパクラスの実行を更に複雑にすることなく適用され得る。マッパがフィールドをフィールドにマップするならば、次いで、タイプ・エレメントを備えるそれはまた、単一のパラメータを得る関数にプロパティをマップするのに使用され得る。この汎化は、それらの実行を複雑にさせることなく、マッパの使用を増加させる。ＥｏｓＭａｐＥｌｅｍｅｎｔＥｏｓＭａｐＥｌｅｍｅｎｔは、全てのマッパ・クラスに関するベース・クラスである。付録Ｅは、ＥｏｓＭａｐＥｌｅｍｅｎｔの具体的なＣ＋＋インプリメンテーションに関するヘッダ・ファイルであり、付録Ｈは、ＥｏｓＴｙｐｅＥｌｅｍｅｎｔに関する具体的なヘッダ・ファイルを含む。ベース・マッパは、２つの重要なプロパティを有する。１つ目は、同期が左から右へ、右から左へ、若しくは、双方向に生じるかどうか判断するｆＭａｐＴｙｐｅフィールドである。２つめは、初期化の場合における情報のフローを指示するプロパティである。マッパは、リンクを含む、左及び右Ｔｙｐｅエレメントを有する。それは、ループを低減させるためのフラグを有する。関数ｔｙｐｅＥｌｅｍｅｎｔＣｈａｎｇｅｄは、パスが変更され、マッパがそのプローブをリセットする必要があるとき、呼び出される。各マッパ・クラスは、それらの挙動に特有の追加のプロパティを加えるために、ｇｅｔＰｒｏｐｅｒｔｉｅｓ及びｓｅｔＰｒｏｐｅｒｔｉｅｓを置き換えることができる。マッパ・クラスはまた、その上含まれるベース・プロパティを得るために、それらのスーパークラス・プロパティを呼び出さなければならない。マッパはまた、ビルダにのみ使用される、検査、アクセス、及び、ｇｅｔＰｒｉｎｔｎａｍｅのような関数を有する。スクリプトからの接続のセットアップ意味論的リンクは、タイプ・エレメントと結合するマッパ・クラスと、パス・エレメントとを実行することができる関係のどんなタイプも生成することができる。しかしながら、そのサービスを実行するために、意味論的リンクを構成するオブジェクトは、インスタンス生成され、初期化され、且つ、パトロン・オブジェクトを参照するためにセットアップされなければならない。それが各時間にプログラム的にこれらのリンクをセットアップすることが可能でありうるが、人が要求され、このアプローチはエラーの傾向があり、単調で飽き飽きする。一つの解は、スクリプトがランタイムで読み込まれるように接続とそれらの個々の意味論的リンクとを記述する翻訳スクリプトと、パトロン・オブジェクトのインスタンス生成を超えるどんなコードをも有することなく形成される接続と、スクリプトを読み込むためのコールとを有する。かなり多くのスクリプト言語は、接続を記述するために工夫され得る。それらは、人間が容易に読むことができるフォーマットに特定されるが、これは、以下に示すように自動的に作り出すのがより困難である。好ましい実施形態では、接続は、データ構造として完全に特定され得る。即ち、スクリプト言語を選択する必要性はデータを提供するだけであり、ステートメント等ならば、ループのような命令をプログラミングしない。それは、典型的なオブジェクト指向又はリレーショナル・データベースに更にストアされ得る。実際に、持続性モデルは、該モデルの部分が個々にインスタンス生成されるならば、十分であり得る。公開された本発明は、クラス及びクラス間の接続を記述するメタデータをストアするためのテーブルとして知られる階層化属性データ構造を使用する。使用されているデータ構造は、そこにストアされていることとおなじくらい重要ではない。データが、２つの比較的簡単な接続に関するメタデータを含む付録Ｆ及びＧの例から要求されることに関して、多くを学ぶことができる。エディット関数は、接続がストアされるクラスをはじめに見つけるために、テーブルに情報を翻訳し、次いで、各クラスの接続のテーブルにそれを見ることによって、名前を表示した接続を見つけ、次いで、テーブルの外の接続に関する仕様を読み込み、以前に示したリンクに記載したような個々の意味論的リンクをセットアップするために適当なデータ構造を生成し、初期化する。外部オブジェクト・マッピングがＮＵＬＬパトロン・オブジェクトに生成されるならば、次いで、第２のパトロン・オブジェクトはまた、一般的なファクトリ・メソッドを介して動的に構築される。記述子からの接続のセットアップ接続の記述からの接続をセットアップする仕事は、エディット関数の仕事である。外部オブジェクト・マッピングに関するエディット関数は、典型的にはプログラム的に呼び出され、通常は、(メタデータをストアする)プライマリ・パトロン・オブジェクトによって呼び出される。好ましい実施形態では、エディットはベースクラスからの承継された関数である。Ｃ＋＋では、編集するためのコールを以下のようにあらわす。 myjob.edit(“connectionName”,connectedObj); 編集するためのこのコールに関して、以下のようなことが生じる：１．エディット関数が呼び出されるオブジェクトに関するメタデータ情報は、クラスの名前を使用してリソース・テーブルから検索される。このことは、ランタイムで「自己記述」であるオブジェクトの能力を利用する。２．ＥｏｓＯｂｊｅｃｔＶｉｅｗＭａｐｐｅｒの新しいインスタンスが生成される。このオブジェクトは、メタデータを読み込み、翻訳することと、個々の意味論的リンクを構築することとを統合するために応答可能である。３．通された右側パトロン・オブジェクトがＮＵＬＬならば、次いで、このオブジェクトは、一般的なファクトリ・メソッドを介して名前によって生成される。４．接続記述子を包含するテーブル（この場合「ｃｏｎｎｅｃｔｉｏｎＮａｍｅ」）は、メタデータ・データベースから得られ、ＥｏｓＯｂｊｅｃｔＶｉｅｗＭａｐｐｅｒの新しいインスタンスに設定される。接続記述子が、呼び出されるクラス・エディットに関するメタデータで入手可能ならば、次いで、そのクラスのスーパークラスのメタデータは検索され、記述子はそこで探索される。これは、ベース・クラスが達成され、若しくは、名前を表示した接続が見つけられるまで、繰り返し起こる。これは、仮想関数として同じ挙動を接続に与えるので、重要なオペレーションである。接続が複合ビュー接続であるとき、これは、「仮想ビュー」として知られている一意的な技術を可能にし、ここでビューが使用されることは、ビューに対してマップされたアプリケーション・クラス・インスタンスのタイプに依存して変化する。コールがメタデータを得るか、又は、メタデータから無効な条件をエディット故障に返す接続記述子を得るかのいずれかならば、ＮＵＬＬは返される。５．マッパ・オブジェクトを見るオブジェクトは、いま、接続記述子を包含するテーブルをトラバースする。各意味論的リンクに関するエントリがある。各意味論的リンクの記述に関して、個々のマッパは、一般的なファクトリ・メソッドを介して名前によって生成され、各意味論的リンクに関するテーブルにストアされたプロパティ情報を使用して初期化される。これは、ＥｏｓＴｙｐｅＥｌｅｍｅｎｔメンバ（ｆＬｅｆｔＳｉｄｅ及びｆＲｉｇｈｔＳｉｄｅ）の生成及び初期化と、それらのそれぞれのパス・オブジェクトとを含む。マッパのようなこれらは、記述子情報にストアされた情報によるタイプ名によって生成される。ｓｅｔＰｒｏｐｅｒｔｉｅｓコールによって、この接続に関する個々のマッパは、ビルダにセットアップされるように接続を実行する適切なプロパティ情報を得ることができる。全てのマッパに関して、少なくとも以下のものがある。Ａ．プローブが発射するとき、更新され得る側を定義する方向情報。Ｂ．初期値であり得る側を定義する初期化情報。Ｃ．左及び右側ＥｏｓＴｙｐｅＥｌｅｍｅｎｔを初期化するプロパティ情報。Ｄ．マッパに関するタイプ情報。(これは、ＥｏｓＭａｐＥｌｅｍｅｎｔインスタンス・サブクラスが構築されるか判断する。) Ｅ．特定のマッパ・クラスに関する任意のプロパティ。全てのタイプ・エレメントに関しては、以下のとおりである。Ａ．タイプ情報(これは、どんな種類のタイプのエレメントが構築されているか判断する。) Ｂ．メンバへのパスを含む（属性、プロパティ、若しくは、このエレメントを表すメソッドの名前を定義する）メンバ名。Ｃ．メンバ・タイプ情報（メンバのタイプ。例えば、ｉｎｔ、ｆｌｏａｔ、ＥｏｓＳｔｒｉｎｇ。）この情報は主に妥当性検査のために使用される。Ｄ．メンバの親のタイプ６．次に、マッパ・オブジェクトがインスタンス生成され、初期化され、接続における全てのマッパオブジェクトは、パトロン・オブジェクトの適当なメンバにプローブを配置するためにオブジェクト・ビュー・マッパによって命令される。このプロセスでは、２つのトップレベル・オブジェクトは、ｉｎｓｅｒｔＰｒｏｂｅｓと呼ばれるＥｏｓＯｂｊｅｃｔＶｉｅｗＭａｐｐｅｒの関数に通される。このメソッドは、ｉｎｓｅｒｔＲｉｇｈｔＨａｎｄＳｉｄｅ及びｉｎｓｅｒｔＬｅｆｔＨａｎｄＳｉｄｅと呼ばれる各マッパに２つの関数を呼び出す。これらの関数は、個々のマッパ、又は、それらと関連するそれぞれのタイプ・エレメントによって定義された関係のオブジェクトにプローブを設定する。プローブを挿入するプロセスでは、マッパは、それらが現すオブジェクトに関係するそのタイプ・エレメント・メンバの各々をセットアップする。各タイプ・エレメントは、この時に親オブジェクトを分離し、関数、若しくは、関心事のメンバに対するフィールド・インデックスをあらかじめ計算する。プローブされる必要があるオブジェクトを得るために、マッパは、ＥｏｓＴｙｐｅＥｌｅｍｅｎｔ：：ｇｅｔＰｒｏｂｅＯｂｊｅｃｔを呼び出す。この関数は、マッパが、それを見つけるためのパスを使用してプローブを設定するオブジェクトを返す。フィールドの場合では、返されたオブジェクトは、その名前フィールドによって参照されているフィールドでありうる。メソッドの場合では、関連したプローブ・フィールドは、返される。メソッド又は属性が情報のソースでなく、宛先だけであったならば、次いで、プローブはそのために設定されないであろう。マッパのプロパティにストアされる方向属性を使用して、コードは、どちらの側にプローブが必要であるか判断する。両方の方向が許されるならば、次いで、プローブは、両パトロン・オブジェクトに設定される。右又は左側だけがモニタされるのが許容されるならば、次いで、特定の側だけがプローブされ得る。７．各マッパが次いで、適当なプロパティ・テーブルをそのタイプ・エレメントの両方に通す。８．オブジェクト初期化が生じる。このプロセスでは、マッパは、はじめに同期される。これは、まるでプローブが発射されたかのように、同じ効果を有する。これは、テーブルにストアされた定義によって制御される。(以下に列挙する)４つの可能性がある。これらの可能性の各々は、ランタイムで数値を有するが、人間が読むことが可能な形式でユーザに提示される。初期化は、有効なマッピングのＥｏｓＯｂｊｅｃｔＶｉｅｗＭａｐｐｅｒのリストに定義された全ての子に適用する。非初期化―立ち上げ時の非同期。(オブジェクト値が明らかに変更するとき、接続がただ有効であれば、有用である) 左初期化―左側が最初に右側を更新する。(ビュー・ウィジェット初期状態を設定することが必要なアプリケーション・オブジェクトに最初にストアされたデータ値を現すならば、有用である) 右初期化―右側が左側に向かって最初に同期する。両初期化―最初に右側を初期化し、次いで左を初期化する。(一方の側の初期値が、反対側のコンテキストにおいて無効と考えられるが、逆は真でないならば、有用である) エディットの他のバージョン接続の各々の大きな種類は、それ自身のバージョンのエディットを有する。これらのバージョンは、この一つのものから僅かに変化している。内部オブジェクト・マッピングは、左及び右側に同じオブジェクトを通すこの一つのものを呼び出す。カスタム・ビュー接続はまた、右側が常に相互作用するサブクラスであり、殆ど全てＮＵＬＬであることを除いて、非常に似ている。また、ビュー・クラスを初期化するのに使用される追加のプロパティがある。複合ビュー接続は、これらのバージョンから最も異なる。複合ビューに関するエディット関数が、ウィンドウをいつも持ち上げるので、差の殆どは、ウィンドウのセットアップ、その挙動、位置、幾何学構造の制御を含む。エディットのこのバージョンは、ポインタをウィンドゥに返し、一方、他のバージョンはオブジェクト・ビュー・マッパを返す。他の種類の接続は、データベース・ポインタ、又は、接続に対して適当な他の情報を返す。ＳｔｏｐＥｄｉｔエディット・プロセスを介して動的接続を生成することは、オブジェクト間にリンクを生成し、包含されたオブジェクトの独立を妥協することなく不意の挙動を生成する。しかしながら、接続を生成することができることは、それらが必要とされるとき、接続がまた破壊され得るならば、より有用とされ得る。ｓｔｏｐＥｄｉｔ関数は、プローブを取り除き、接続を構成するマッパ・オブジェクトを解放する。エディットするためのコールは、新しく構築された接続（ＥｏｓＯｂｊｅｃｔＶｉｅｗＭａｐｐｅｒの例）にポインタを返し得る。オブジェクト接続がもはや必要でないとき、このポインタは削除され得る。このことにより、接続は、その接続リストに含まれている全てのマッピングにｒｅｍｏｖｅＰｒｏｂｅｓを呼び出させることができうる。各マッパは、それを設定するプローブを取り除くために呼び出される。このプロセスは、プローブを取り除くために、２つの関数ｃａｎＭａｐｌｅｆｔとｃａｎＭａｐＲｉｇｈｔに再び頼る。また、リンクされるオブジェクトのいずれかが破壊されるならば、次いで、リンクは、オブジェクトが削除される際に、安全に下げられ得る。記述子の相互作用の特定手によってオブジェクトを互いに関係付けるためにスクリプトを書くことは、接続を生成するために、オブジェクトをインスタンス生成するためのコードを上書きすることを改良することである。しかしながら、記述されたスクリプトが、接続を特定する情報で満たされた簡単なデータ構造であるので、それは、ユーザがこの情報を相互作用的に特定することができるプログラムを生成するために、適切で簡単なプロセスである。ビルダは、プログラマがクラスの間の名前を表示した接続の宣言を特定するのに使用する、対話型ＧＵＩプログラムである。好ましい実施形態では、このプログラムはまた、クラス自身を生成するのに使用されるクラス・ブラウザである。これらの関数の組合せが厳密に要求されていない間、それは、使用するのによりやさしいプログラムを作らせる。この情報を編集するのに選択されたインターフェースは、簡単なものである。改良は、殆ど確かになされうる。幾つかに関しては、たぶんノードを備えたより高度なグラフィカル・インターフェースであり、動作はより直感的であるが、開示されたインターフェースはより直接的である。ビルダにおける結合を生成する上でのユーザ・ビューリンクの仕様はユーザの観点からすると、実に非常に容易なものである。これは、以下のステップを含む。（１）結合が属することになる主要クラスを選択せよ。このクラスは、結合において伴われる主要パトロンオブジェクトとなり、結合を記述するメタデータが格納されるクラスとなる。（２）被選択クラスのための新結合を生成するコマンドを選択せよ。これは、情報収集ダイアログをポップアップさせる。（３）結合（後に結合をインスタンス生成するように編集するためのパラメタとして使用される）の名前を入力せよ。（４）結合のタイプを選択せよ。好ましい実施形態においては４タイプの結合がある。外部オブジェクト結合内部オブジェクト結合カスタムビュー結合複合ビュー選択された結合のタイプに拠れば、結合を生成するためのインターフェースはかなり異なる。外部オブジェクト結合のためのインターフェースは、基本的なデータ構造をもっとも綿密に反映するため、最も代表的なインターフェースである。内部オブジェクト結合及びカスタムビュー結合のためのインターフェースは、外部オブジェクト結合のためのものとほぼ同一である。複合ビューのためのものはかなり異なり、簡単に説明することにする。外部オブジェクト結合ユーザが外部オブジェクト結合を生成することを選んだ場合、結合させるためのオブジェクトの他のタイプを指定しなければならない。この簡単なタスクは、システム内の全てのタイプのリストからタイプを選択することに達成される。存在しないクラスがタイプされ得ないように、これは選択のためのリストにおいて提示される。両サイドにおいて同じタイプが選択されることに注意すべきであるが、２つのインスタンスを結合させるため、内部で結合させるというよりも、むしろ内部オブジェクトマッピングと依然として異なる。今度は、図４のダイアログをユーザに提示する。これは４panes を有する。ボトム panes（４０４）はこの結合を作り上げる意味論的リンクのリストを示す。このリストを築くのがダイアログの目的である。トップ左の panes（４０１）は第１パトロンクラスの階層ツリービューを示す。機能、基本属性、及び各タイプを表現するビットマップの使用を通したクラスである属性の間で明確に識別する。ツリーにおけるデータメンバは、機能及び属性を帰納的に示すのに拡張可能である。右の panes（４０３）は第２パトロンクラスを示す。ユーザのタスクは各パトロンクラスから１以上のメンバを選択することである。好ましい実施形態においては、マッパはオブジェクト自体のための内部オブジェクトマッピングのコンテキストにおける私的メンバに結合させるだけで良い。保護されているメンバは導出クラスにおける内部オブジェクトマッピングのコンテキストにおいて使用されても良い。公的メンバのみが外部オブジェクトマッピングにおいてマッパによりアクセスされる。例えば、マルチパラメタ機能のためのトリガは、結合された入手機能のプロパティを通してアクセスされるために、公的である必要はないといった例外もある。現行のインプリメンテーションは私的かつ保護されたメンバへのリミティッドアクセスを強要せず、全てのメンバがマップされるようにするが、好ましい方法で再実行することを意図している。ユーザがいずれかのパトロンクラスのメンバを選択、又は選択解除する度に、ミドルリスト（４０２）は再構築される。メンバの被選択セットを互いにリンクさせることができるマッパタイプの全てを含む。全てのマッパが、いかにして任意要素を一緒にリンクさせるかを知っているわけではない。例えば、もし多重パラメタ機能が選択されたとしたら、フィールドマッパにとってのフィールドは適切でないであろう。マッパは、列が１つのクラスにおいて選択され、他でintが選択されることを要求しても良い。マッパが要求するように明確又は一般的であって良い。使用可能マッパのリストは列の単純リストとして、又は階層編成ツリーとして、若しくは別の様式でみなされても良いことに注意すべきである。多くの特定用途向けマッパがシステムに加えられる時、単純線形列リストと可能であるよりも編成するのに更に有効である。例えば、複合ビュー結合を構築する時、ユーザにビットマップのパレットが提示され、インターフェース要素がどのようにみえるものかを理解させるようにする。ビットマップはカスタムビュー結合の属性である。一旦マッパタイプがミドルpanesに表れたら、ユーザは選択しても良い。一度選択されたら、この結合のために意味論的リンクのリストに加えられる。これが加えられたために、このコンテキストにおいて使用された時、ユーザがその特定のマッパのための属性をセットするようにダイアログがポップアップする(十分興味深いことには、各マッパタイプのために異なるビューをつくるのに仮想ビューが用いられる)。各マッパタイプは、その属性を表示するための独自の固有のダイアログを有する。ユーザは複合結合を構築するのに要するだけ多く、結合のための意味論的リンクを加えても良い。個別の意味論的リンクはまた、容易に抹消される。全ての結合宣言ダイアログもまた、随意閉じられ、再編集される。結合自体も、それ以上必要でない場合、抹消される。ユーザの観点によると、結合を宣言するのは単純にポイントとシュートの問題である。当然、個々のマッパが何を行うのかを知るべきであり、そのマッパのための属性がどのように働くかを知るべきである。新たなマッパクラスがこれほどに容易に構成される事実のために、唯一の現実解は各属性のためのドキュメンテーションを含む各マッパクラスに使用可能なオンラインヘルプを有することである。複合ビュー結合複合ビュー結合をつくるためのインターフェースは開示される他の種類の結合に比べてはるかに異なる。この種の結合においては、ユーザの主要目的はアプリケーションオブジェクトの言語要素に縛られる要素を有するユーザインターフェースを構築することにある。複合ビュー結合をつくるために、新たな結合をつくることを選択し、次いで複合ビュー結合をつくることを選択する。この後、結合のための名前を入力し、ウィンドウ又はメニュー結合をつくるか否かを選択する。ウィンドウ結合が選択された場合、デフォルトビューがつくられる。それからユーザは、ビューオブジェクトを結合するところのビジネスオブジェクトにおけるフィールド又は機能のいずれかを選択する。選択されたフィールド又は機能のタイプに拠れば、ユーザがそこから選べるように構成要素（現実的カスタムビュー結合）のリストが構築される。ビューが選ばれると、構築されたダイアログのどこに置くかを選び、それに視覚的プロパティーをセットしても良い(これらプロパティーは拡張可能メタデータフォーマットに保管される)。ユーザはこの時点でマッパプロパティーに直接アクセスできないが、それを行うために新たなカスタムビュー結合をつくっても良い。マッパ仕様の実施の詳細結合仕様のためのビルダをつくることは、図的表現の生産におけるエクササイズを伴う。近代プログラムの共通の要求事項であるため、当業者がGUI プログラミングの要求事項に熟知しており、従ってGUI実施の詳細は当開示から除外される。極めて適切なマッパに関する建築上の事由も当然にしてある。これらは十分に開示されている。基本的情報収集上記ステップ２に説明されるダイアログはダイアログを集めた単純な情報である。収集された情報は、(１)結合をインスタンス生成するためにみるのに後に使用される、意味論的リンクの集まりに与えられた名前、(２)これが内部あるいは外部オブジェクトマッピング（若しくはその他のタイプのマッピング）のいずれであるか、を含む。内部オブジェクトマッピングの場合、要求される追加的情報のみがマッピングあることのクラスの名前である。これはダイアログが提示されるコンテキストから集められている。主要クラスは、内部に結合のメタデータが格納されるクラスである。当然、ダイアログのフィールドにこのクラスタイプを単純に入れ、この文脈上の事由からインターフェースを開放することも可能である。外部オブジェクトマッピングの場合、ユーザには結合したいと思うシステム内に他の全てのクラスの選択を提示される。他のクラスタイプは、その内１つが選択されるように結合をつくることを要する。第２のタイプは、ユーザにより明示して選択される。もしユーザが主要タイプを再度選択したら、同一のオブジェクトの２つのインスタンスが実行時に結合されることを暗示する。内部オブジェクト結合は、２つのインスタンスを結合するよりもむしろ、オブジェクトの単一のインスタンスの要素を一緒に結合させる。内部オブジェクトマッピングは、他のオブジェクトが第１オブジェクトの結合される同一のインスタンス（及び、当然それと同一のタイプの）である外部オブジェクトマッピングの特別の場合として考えられる。結合の他の結合タイプは、もちろん可能である。好ましい実施形態において、メニューやダイアログのような構成されたユーザインターフェース、並びにスクロールバー等のようなウィジェットに対するカスタム結合もまた結合タイプのように選択可能である。これら結合のタイプはインターフェースの見た目と感覚を説明するメタデータのプロパティーを更に有するが、オブジェクトの基本的結合が全く同一である。この特別の場合においてはオブジェクト結合の一面は常にユーザインターフェースクラスであるというだけである。この情報の全てはダイアログを持ち出すコードによってメタデータ内に格納される。メタデータの正確なフォーマットはその中に含まれる情報に比べて重要でない。意味論的リンクの仕様基本の新結合ダイアログから収集された情報を使用すると、図４のダイアログは情報で満載である。第１ステップは結合に伴うクラスの階層ビューを構築することである。伴われるクラスタイプは第１ダイアログから決定される。内部オブジェクト結合の場合、両サイドは同一のクラスのビューである。即ち、この結合が構築されたことのタイプである。メタデータのデータベースにアクセスすると、属性、プロパティー、及び機能において各オブジェクトが決定可能である。これら要素はユーザが拡張可能ノードを拡張させるに従って加えられる。機能又はフィールドが属性を有しない限り、クラス属性ノードのみが拡張可能である。各ノードが拡張されるに従い、メタデータデータベースはアクセスされ、適切なサブツリーがビューに加えられる。ユーザに回線がプロパティー、機能、基本属性あるいはクラス属性のいずれを表現するかに関する情報を与えるために、アイコンがツリーの各回線に置かれている。単純な例がこれを明確にする。クラスＡがその他のクラスに結合していると仮定する。クラスＡの定義は以下の通りである。クラスＡの完全に拡張されたビューはツリーにのように表れる。このツリーのビューにおいて、行が選択される。実際は複数の行が選択されうる。この選択は「マッパ」のリストの構築をトリガする。いずれのツリーの選択、あるいは切断において、マッパのリストは完全にスクラッチから再構築される。リストを構築するアルゴリズムは以下の疑似コードに開示される。要点は検査機能である。これは、ほぼどのマッパクラスもオーバーライドする仮想の機能である。これは各サイドの被選択要素のリストを見て、もし２セットのメンバを一緒にマップすることのみができたとしたら、真に戻る。例えば、機能にフィールドを接続させるマッパは、どちらのサイドにおいても機能が選択されない場合、偽に戻る。一方のサイドに複数のアイテムが選択された場合、タイプ要素のリストを扱うためのパラメタタイプを有する、異なる検査機能が呼び出される。この方が、どのサイドにも複数のアイテムを扱わない場合、更に複雑な検査を暗示する必要がない。マッパクラスはビルダ内におけるクラスの指定中に使用される機能や、エグゼキューション初期設定、プローブ再配置、及び結合の破壊の間、使用される他の機能を有する。各マッパクラスはまた、マッパリスト（４０２）に入れる名前の「人間可読」バージョンを備える。全てのマッパクラスはベースEosMapElementクラスを下位に分類する。このクラスはほとんどのマッパがオーバーライドする仮想の機能の多くのデフォルト実施を構成する。検査のデフォルト実施は、ベースクラスが何もマッピングできないために単純に偽に戻る。マルチパラメタ検査のベースクラス実行はまた、ベースクラス内において偽に戻る。目標は単純なマッパを単純にすることであり、これら単純な事柄から各サイドの複数のメンバと複雑なマッピングの実施詳細を隠すことである。機能マッピングへの複数の引数フィールドのような更に複雑なマッパは、検査の第２形態に密接に精通していなければならない。ユーザが特定のマッパを選択し、リストに加えること（これはダブルクリック、又は加算マッパボタンの選択によってなしうる）を選ぶと、マッパのプロパティーへの編集する機会を有する。これは多くの仕方でなしえるが、好ましい実施形態においては、各マッパクラスと対応する名前付きダイアログビューがある。このビューは選択された特定のマッパのために持ち出され、ユーザはそれと相互に作用しても良い。新たなマッパがシステムに加えられると、プロパティーを編集するためのダイアログをも加えなければならない。幸いにも、仮想ビューとして知られるユーザインターフェース技法の使用により、かなりトリビアルである。ビルダプログラムは、最終的に、プログラムを実行することにより読まれるテーブルを含む資源ファイルへの結合の仕様を保管する。テーブルは結合の圧縮記憶装置及び高速ローディングのための２進フォーマットを有する。結論ユーザはここに開示されるものの反対の順序で本発明と相互作用を行う。ビルダと相互に作用し合い、資源ファイルを生成し、結合を設定するのに編集を呼び出す。マッピングは固有の技法である。これは、オブジェクトが言語レベルで違いに独立して動作するようにし、要求されるだけプログラムレベルで相互作用を行う。これは、再利用言語レベルのオブジェクトを標準オブジェクト指向言語では達成不可能な程度に作成する能力を備える。図面及び詳細な説明において、本発明の種々の好ましい実施形態が開示され、特定の用語が用いられているが、これは例示であり、これに限定されない。従って、本発明の精神及び領域は上に説明した実施形態に限定するものではなく、添付の請求の範囲によってのみ明確となる。付録Ａメタデータメタデータとはデータ構造を説明するデータである。実施につき、メタデータはプログラム実行中、クラスデータタイプ、構造、及び機能性に関してオブジェクトが照会されるようにする。例えば、オブジェクトについて、名前は何であるか、機能はどれだけ有するか、若しくは第３分野の名前及びタイプは何であるかを尋ねることができる。メタデータを支持するオブジェクト指向の言語は、再考、内省、又はランタイムタイプインフォメーション(RTTI)を有すると言われている。C⁺⁺は提案された RTTI 拡張を有するが、最も広く利用できるコンパイラーにおいて依然として実行されていない。メタデータ自体は新たな概念ではない。コンパイラーがコードをスキャンし、編集プロセスの一部としてシンボルテーブルを作成する時は常に、シンボルテーブルはメタデータのデータベースである。このメタデータは、通常、プログラムの実行可能イメージに編集プロセスを通して送られ、一般にプログラムの開発中、デバッガにより使用される。しかしながら、多くの言語において、プログラム実行の間、プログラムに基づいてこのインフォメーションにアクセスする標準的なやり方はない。事実、プログラムが最終搬出のために準備されるにつれ、このデバッガメタデータインフォメーションは、最終生産プログラムにおいて機能しないため、実行可能にプログラムから取り除かれる。スモールトーク、LISP、及び他の解釈言語は、備えたメタデータの量及びタイプが広く変化するけれども、典型的に言語の統一部分としてメタデータアクセスを支持する。パスカル、モデュラ、C 及び C⁺⁺のようなもっともコンパイルされた言語はメタデータを備えない。当然、一般的規則の両サイドに顕著な例外はある。メタデータは広域のクラスにわたって実行されている。それは、データは物から物へ瞬時に変容しないからである。従って、メタデータは１つの場所に効率良く格納することができる。また、メタデータは、普通、読み出し専用のものとして扱われ、プログラムの実行中は変化しない。新たなコードが発生した時、インタープリターは興味深い例外を与え、それから止まらずに同じプログラムにより実行される。これに対して、動的結合及びプローブは典型的にクラス原理よりもむしろ実証原理に基づいて実行される。備えられたメタデータモデルは伸縮自在である。メタデータへの拡張はプロパティーと呼ばれる。プロパティーはクラス、フィールド、機能、マッパー、及び他のメタデータ要素に応用できる。プロパティーの設備はシステムの使用者が種々のタイプのための言語水準で新しい機能を加えられるようにする。マッパークラスは種々の手段によってプロパティーに応答可能である。これは、使用者が種々のデータタイプにプロパティーを加え、次いで作成した種々のマッパー内のプロパティーに応答することができるということである。これはプログラマーが別の自由の度合いでマッパーモデルを拡張することができるようにする。性質を設けるためにマッパーにプロパティーを加えるほかに、それは、プロパティーがマッパーに接続されている要素に加えることができるということである。付録Ｂ完全動的結合動的結合とは、プログラムの実行中、オブジェクトはそのメンバーの名前を使用することにより操縦可能である。例えば、フィールドはセットされて照会され、機能は名前で呼ばれる。プログラムのいかなる部分も、クラス及び機能の名前以外は何も知らずにXの例に基づいてプログラム実行中func of class Xのメンバー機能を引き起こす。メタデータはオブジェクト自体から名前を得るのに有効である。 C⁺⁺は、クラス又は機能の名前を知らずにプログラム実行中正確なコードを引き起こすように、機能の静的結合を行うためのリンカーを使用する。多くの場合、このアプローチは効果的であり、常に僅かにいっそう効果的である。しかしながら、ライブラリーにないものをライブラリーコードによって機能と呼びたいのであれば、動的結合によって容易に行うことができる。動的結合はコンピューター言語においてかなり一般的な特徴である。また、これはインタープリター言語において更に一般的であり、しばしばメタデータを支持する同一の言語において見出される。 C⁺⁺は実際上の機能を通じて「動的結合」を有する。実際上の動的結合は実際上の機能を有する各クラスのための機能ポインタのアレーを作成する。この「V テーブル」へのポインタは構築されるに従って各オブジェクトインスタンスに格納される。このVテーブルポインタはVテーブルを通したインデックスにより機能を引き起こすのに使用される。各サブクラスは、異なる機能を実行するために、実際上の機能（異なる機能を局部的なvテーブルに挿し込むようにする）を「オーバーライド」可能である。従って、どの機能が呼ばれたかを決定するにはオブジェクトの例のタイプに基づく。米国特許第５，３２７，５６２号及び第５，３７１，８９１号は実際上の機能及びC⁺⁺タイプ言語におけるその実行について明示的に詳しく論じている。ここに論じられた動的結合はクラスメンバーの名前を使用して実行時に解決される。メタデータは、C⁺⁺タイプの動的結合を行う必要がない一方で、ここに論じた動的結合の形を行う必要がある。全ての拡張された機能（実際上の機能を含む）が本発明により動的に結合可能である一方で、C⁺⁺ クラスの特定の機能のみが事実上のものである。最近、機能のための動的な結合のいくつかの形態をコンピューターシステムを操作させる作動システムソフトウェアに合体させることもかなり一般的になっている。マイクロソフトウィンドウズ Dynamic Link Libraries(DLLs)は非言語ベースの動的リンキングの１形態の顕著な例である。このタイプの OS 水準の動的リンキングは言語ベースの動的リンキングから見るとかなり異なる。米国特許第５，３６９，７６６号は動的リンキングがプログラム実行のインターラプションなしに達成、かつ再リンクすることができる追加の特徴とともに動的このタイプのリンキングの興味深い概観を提供する。動的リンキングの別のタイプは、連続的に作動するシステムにおいてでバッギングするためのオブジェクトの例において機能が呼ばれる変化させる能力のために与えられた米国特許第５，３３９，４３０号に説明される。再び、このタイプの動的リンキングは特徴を支持する言語において利用できるものから本質的に異なる。付録Ｃプローブ興味の第３オブジェクト指向エンハンスはプローブである。プローブはデータ（オブジェクトフィールドにおいて典型的に）が変更する時に呼び出されたコールバック機能である。メンバーそのものにクラスによってセットされもするが、プローブは他のオブジェクトによってしばしばプラントされる。プローブは、興味深いオブジェクトが観察されるオブジェクトの前行掛かり合いなしにプローブされたデータ価値を監督するようにする。換言すれば、プローブされたオブジェクトは、オブジェクトのデータにおいて起きる変更について興味深いパーティーに知らせるために性質を変更する必要はない。これは、プローブされたオブジェクトからの他のオブジェクトとともにオブジェクトの性質を同期化させるための責任をシフトし、そうしてプローブされたオブジェクトの実施を簡易化する。メタデータ及び動的結合はスモールトークにおいて実施されるけれども、プローブはそうではない。本発明は当業者によってプローブを支持するためにスモールトークのエンハンスに適用されうる。同様に、プローブを支持しない他の言語も本発明を使用しながら拡張される。プローブはプログラム言語においてはかなり珍しい特徴である。大変役立つが、ほんの僅かな調査言語が内臓された直接の完全な支持を有することで知られている。プローブの他の実施もここに説明されるものほど完全ではない。プローブは、効率目的のためにプログラム遂行中付けたり消したりすることができる。これは、もしプローブされた価値が複合計算中に中間価値を含む場合にしばしば必要である。 SIMULA プログラム言語は「左モニターされた変数」を有し、それは、単一の機能がそのフィールドと結合し、機能がオブジェクトの例示機関のための変数に接続するのを除いてプローブに関して似たように機能する。SIMULA におけるプログラム遂行中コールバックを消す方法はない。エッフェルのいくつかのスタンダードでないバージョンは、プローブに類似の「書込みバリア」という特徴を有する。これは、変数に対する割り当てを制御させる。しかしながら、エッフェルは上記メタデータ及び動的結合の特徴のいくつかを欠く。プログラム遂行中クラスのメンバーでない基本フィールドのプローブのリストに追加のコールバックを加える能力は本発明には固有のものと思われる。換言すれば、いくつかの言語はこの特徴を有するが、これほどの動的流儀で問題に取り組むことはないように思われるということである。信号と呼ばれる特殊なフィールドは使用されるシステム内に備えられている。信号はプローブをプラントするためのポートを備えるが、データを有しない。オブジェクトは明示的に信号（変更するデータがないため）においてファイヤされるためのプローブを起こすべきであるが、どのオブジェクト（もしあるならば）が信号上にプラントされたプローブを有するかについての知識がなく、このようにしてオブジェクトの独立性が維持される。A 信号は、オブジェクトのコールバックのシリーズをプラントする便利な方法を簡易化する。付録Ｄ名前によるインスタンス生成動的結合に関する他の特徴は、名前によってデフォルトオブジェクトを創る能力である。それは、クラスの名前が通過するためのオブジェクトの新たに作られたインスタンスの戻ると言われる機能があることである。例えば、ユーザーに箱の中のタイプにあるクラスの名前をタイプするように言って、名前のみを使用してそのオブジェクトのインスタンスを築きあげる。通常、コードは特有のタイプを創るために書かれ、１つの特別のクラスタイプのみがそのコードによって構築される。動的結合及び名前によるインスタンスによって備えられた利点は、電話帳を使用することによって得るものに似ている。コンパイル言語の普通の仕組みは、親友の電話番号を暗記する時の方法に似ている。これは、この僅かな番号には非常に有効であるが、必要性を感じた場合にのみ盤お愚を覚えることができるのであろう。しかしながら、電話帳があれば、電話をかけられる人の潜在的な数はさらに大きい。かける前に電話番号を「知る」必要はない。付録Ｅ付録Ｆフィールドーフィールド接続に関するメタデータこのメタデータは、内部オブジェクトマッピングとして一緒に「ｏｎｅ」及び「ｔｗｏ」と名付けられた、クラスＰｒｏｊｅｃｔＦｒａｍｅの２つのＥｏｓＩｎｔフィールドをマップするように要求された情報を含む。２つのフィールドを接続するマッパは、ＥｏｓＭａｐＦｉｅｌｄＴｏＦｉｅｌｄである。付録Ｇ関数リンクに関するメタデータこれは、「Example Function Connection」からのＥｏｓＭａｐＭｕｌｔｉＡｒｇＦｕｎｃｔｉｏｎを特定するメタデータである。付録Ｈ付録Ｉネットワーキング・オブジェクト

───────────────────────────────────────────────────── フロントページの続き (72)発明者オズマンアンドリューヴィーアメリカ合衆国ユタ州 84606 プロヴォサウス 100 イースト 231 (72)発明者ミッチェルデイルケイアメリカ合衆国ユタ州 84601 プロヴォノース 300 ウェスト 361−＃303

Claims

【特許請求の範囲】１．動的オブジェクト指向言語を使用して書かれた第１のオブジェクト・インスタンスと第２のオブジェクト・インスタンスとを動的にリンクするためのシステムであって、動的結合と、前記第１のオブジェクト及び前記第２のオブジェクトのプローブ能力とを使用して前記第１のオブジェクト及び前記第２のオブジェクトのクラス・インターフェースを介して前記第１のオブジェクト及び前記第２のオブジェクトを関連させる少なくとも１つの意味論的リンクを有する。２．前記第１及び第２のオブジェクトが同じオブジェクト・インスタンスである、請求の範囲第１項に記載のシステム。３．複数の意味論的リンクと、前記複数のリンクの名前を表示したリストを備える接続を生成するための手段とを更に有する、請求の範囲第１項に記載のシステム。４．前記接続の仕様をストアするためのリソースを更に有する、請求の範囲第３項に記載のシステム。５．前記仕様に従ってプログラム実行中に前記接続を生成し、初期化するための手段を更に有する、請求の範囲第４項に記載のシステム。６．第３のオブジェクトと、前記第１のオブジェクト及び前記第２のオブジェクトのうちの一つの特性が変化するとき、前記第１及び前記第３のオブジェクトに関連するように前記一つのリンクを変化させることによってプログラムを実行中に、前記接続を保持するための手段とを更に有する、請求の範囲第３項に記載のシステム。７．プログラム実行中に、前記接続を破壊するための手段を更に有する、請求の範囲第３項に記載のシステム。８．前記リンクが、前期第１及び前記第２のオブジェクト間に通された情報の転送を行う、請求の範囲第１項に記載のシステム。