JP2006228200A - リレーションシップモデリング - Google Patents

Abstract

【課題】複数のアイテムの間のリレーションシップを、アイテム自体の外部で定義することにより、モジュラーで柔軟性のある拡張可能なシステムを提供する。
【解決手段】課題の開示は、複数のアイテムの間のリレーションシップに関係する。例えば、複数のアイテムの間のリレーションシップを、指定されたリレーションシップによる特定のエレメントまたは値を戻すためのメソッドを含む、クラス内で定義することができる。また、コンパイラまたは類似のシステムを、単純なプロパティフォーマット内のリレーションシップ表現を受け入れ、このようなコールを特定のメソッドにダイレクトするように、拡張することができる。
【選択図】図１

Description

本発明は、一般には、オブジェクト指向プログラミングに関し、より詳細には、オブジェクト指向のリレーションシップモデリングに関する。

プログラミング言語は、タスク実行のためにコンピュータまたはマイクロプロセッサへ命令を通信するのに特に使用される形式言語である。長年の間、オブジェクト指向プログラミングは、設計者およびプログラマがコンピュータシステム内で機能を実装するために利用する、多数の見慣れた、よく知られているモデルの１つになっている。オブジェクト指向プログラミングはユニークであり、これは少なくとも、他のモデルのようにアクションではなく、オブジェクトや物に関してプログラミングを考慮することを前提としているからである。

オブジェクト技術の利点は、３つの基本的原理、すなわち、カプセル化、ポリモルフィズムおよび継承のうち１つから生じる。オブジェクトはそれらのデータおよび関連付けられたメソッドの内部構造を隠す、またはカプセル化する。実装詳細を公開するのではなく、オブジェクトはそれらの抽象化を、無関係な情報なしに明示的に表現するインターフェイスを提示する。ポリモルフィズムは、カプセル化をさらにもう一歩進ませる。ポリモルフィズムは、異なるデータ型に対する同じコードの使用を可能にし、この考えは、多数の形状、１つのインターフェイスである。よって、ソフトウェアコンポーネントは別のコンポーネントの要求を、そのコンポーネントが厳密に何であるかを知ることなく、作成することができる。要求を受信するコンポーネントは要求を解釈し、その変数およびデータに従って、要求を実行するための方法を解明する。第３の原理は継承であり、開発者が前から存在する設計およびコードを再使用することができるようにする。この能力で、開発者がすべてのソフトウェアを最初から作成することを回避することが可能となる。むしろ、継承を通じて、開発者は、他のクラスの状態およびビヘイビアを継承および修正するサブクラスを派生させることができる。

オブジェクト指向プログラミングモデルは、クラスベースの手法を介して定義されることが多い。このシステムでは、オブジェクトは、状態およびビヘイビアを含むエンティティである。オブジェクトの状態およびビヘイビアはクラスによって定義され、クラスは特定の型のオブジェクトを識別する。クラス定義に基づいて作成されたオブジェクトは、動的な型において反映されたそのクラスのインスタンスと見なされる。したがって、クラスは、オブジェクトが含むことができるデータ（すなわち、状態）、ならびに、オブジェクトが実行することができるメソッド、関数またはビヘイビアを指定する。メソッドは、関連付けられたオブジェクトの内部状態を、その中に含まれたデータを変更することによって、修正するように動作する。オブジェクト内のこのようなデータおよびメソッドの組み合わせはしばしば、オブジェクト指向プログラミングにおいてカプセル化と呼ばれる。カプセル化は、オブジェクトの状態が、オブジェクトに関連付けられた明確なメソッドによってのみ変更されることに備える。オブジェクトのビヘイビアが、このように明確なロケーションおよびインターフェイスに限定されるとき、オブジェクト内の変化（例えば、コード修正）は、システム内の他のオブジェクトおよびエレメントに最小限の影響を与えるようになる。

以下で、主張された内容のいくつかの態様の基本的理解を提供するために、簡単な要約を提示する。要約は、広範な概観ではない。主張された内容の重要／重大な要素を識別するように、または、主張された内容の範囲を線引きすることを意図しない。唯一の目的は、いくつかの概念を簡単な形態で、以下で提示するより詳細な説明の前置きとして提示することである。

簡潔に説明される課題の開示は、アイテムおよび／またはそのエレメントの間のリレーションシップの表現に関係する。

具体的には、リレーションシップは第１のクラス概念として扱われる。課題の開示の一態様にかかるリレーションシップを、クラスなど、リレーションシップを計算するおよび／またはナビゲートするメカニズムまたはメソッドを提供するアイテムの外部のコンストラクト（ｃｏｎｓｔｒｕｃｔ）によって表現することができる。課題の革新の別の態様によれば、リレーションシップメソッドを、データ型プロパティ表記を利用して呼び出すことができる。

課題の革新の態様は、少なくとも、これらの態様が、複数のアイテムの間のリレーションシップと対話するための、拡張可能および使いやすいシステムおよび方法を提供することにおいて有利である。リレーションシップを第１のクラスプログラミングオブジェクトにすることによって、新しいリレーションシップを既存のアイテムの間で、アイテムを修正することなく、作成することができる。これは少なくとも価値がある。なぜならば、プログラマのコントロール下にない、またはエレメントを修正して新しいリレーションシップを反映することが実行不可能な場合の、一部または全部のアイテムまたはエレメントの間のリレーションシップの定義を可能にするからである。なおさらに、クラスメソッドの呼び出しを、プロパティ表現を介して容易に実施し、および実際のメソッド表記にマップさせることができる。

前述および関連の目的の達成に向かって、主張された内容のある例示的態様を、以下の説明および添付の図面に関連して本明細書で説明する。これらの態様は、内容を実施することができる様々な方法を示し、そのすべてが主張された内容の範囲内になるように意図される。他の利点および新規の特徴は、図面と共に考慮されるとき、以下の詳細な説明から明らかになるであろう。

課題の革新の様々な態様をこのとき添付の図面を参照して説明し、図面において、類似の番号は全体に渡って類似または対応するエレメントを指す。しかし、これに関係する図面および詳細な説明は、主張された内容を、開示された特定の形態に限定するように意図されないことを理解されたい。むしろ、意図することは、主張された内容の精神および範囲内に入るすべての修正、等価物、および代替物を包含することである。

本出願で使用されるとき、「コンポーネント」および「システム」などの語はコンピュータ関連エンティティを指すように意図され、このエンティティは、ハードウェア、ハードウェアおよびソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアのいずれでもよい。例えば、コンポーネントは、限定されないが、プロセッサ上で実行するプロセス、プロセッサ、オブジェクト、インスタンス、実行可能なファイル、実行のスレッド、プログラム、および／またはコンピュータであってもよい。例示として、コンピュータ上で実行するアプリケーションおよびコンピュータの両方がコンポーネントである可能性がある。１つまたは複数のコンポーネントはプロセスおよび／または実行のスレッド内に存在することができ、コンポーネントは１つのコンピュータ上でローカライズされるか、および／または２つ以上のコンピュータの間で分散される場合がある。

「例示的」という語は本明細書で、例、場合または例示としての機能を果たすことを意味するために使用される。本明細書で「例示的」として説明されたいかなる態様または設計も、必ずしも他の態様または設計よりも好ましいまたは有利と解釈されるとは限らない。さらに、様々な例示的コードスニペットが本明細書で提供される。これらの実施例は、明瞭にするため、および理解のために提供され、開示された内容の範囲を、主張された内容の様々な態様の説明において使用されたその言語、アーキテクチャおよび／または特徴に限定するように意味されないことを理解されたい。

人工知能ベースのシステム（例えば、明示的および／または暗示的にトレーニングされた分類子、ナレッジベースシステム．．．）を、後述の課題の革新の１つまたは複数の態様によって、推論および／または確率的決定および／または統計ベースの決定を実行することに関連して使用することができる。本明細書で使用されるとき、「推論」という語は一般に、イベントおよび／またはデータを介してキャプチャされたような観察のセットから、システム、環境および／またはユーザーの状態について判断または推論するプロセスを指す。推論を使用して、特定のコンテキストまたはアクションを識別することができ、または例えば、推論は複数の状態に渡る確率分布を生成することができる。推論は確率的である可能性があり、すなわち、データおよびイベントの考慮に基づいた、関心のある複数の状態に渡る確率分布の計算である可能性がある。推論はまた、イベントおよび／またはデータのセットからより高いレベルのイベントを構成するために使用される技術を指す可能性もある。このような推論は結果として、イベントが時間的に密接に近接して相関されるかどうかにかかわらず、ならびに、イベントおよびデータが１つのイベントおよびデータソースから来るか、複数のイベントおよびデータソースから来るかにかかわらず、観察されたイベントおよび／または格納されたイベントデータのセットからの、新しいイベントまたはアクションの構築となる。様々な分類スキームおよび／またはシステム（例えば、サポートベクトルマシン、ニューラルネットワーク、エキスパートシステム、ベイジアンネットワーク、ファジー理論、データフュージョンエンジン．．．）を、課題の発明に関連した自動および／または推論されたアクションを実行することに関連して使用することができる。

加えて、開示された内容を、標準のプログラミングおよび／またはエンジニアリング技術を使用して、ソフトウェア、ファームウェア、ハードウェアまたはそれらのいかなる組み合わせをも生成する、システム、方法、装置または製造品として実施して、コンピュータまたはプロセッサベースの装置をコントロールして、本明細書で詳述した態様を実施することができる。本明細書で使用されるとき、「製造品」（または、代替として「コンピュータプログラム製品」）という語は、いかなるコンピュータ読取可能な装置、搬送波または媒体からもアクセス可能なコンピュータプログラムを包含するように意図される。例えば、コンピュータ読取可能な媒体は、限定されないが、磁気ストレージデバイス（例えば、ハードディスク、フロッピー（登録商標）ディスク、磁気ストリップ．．．）、光ディスク（例えば、コンパクトディスク（ＣＤ）、デジタル多用途ディスク（ＤＶＤ）．．．）、スマートカード、およびフラッシュメモリデバイス（例えば、カード、スティック、ジャンプドライブ．．．）を含むことができる。加えて、搬送波を、電子メールの送信および受信において、または、インターネットもしくはローカルエリアネットワーク（ＬＡＮ）など、ネットワークへのアクセスにおいて使用されるものなど、コンピュータ読取可能な電子データを搬送するために使用することができることを理解されたい。言うまでもなく、主張された内容の範囲または精神から逸脱することなく多数の修正をこの構成に行うことができることは、当業者には理解されよう。

最初に図１を参照すると、本開示の一態様によるリレーションシップシステム１００が示される。リレーションシップシステム１００は、アイテムレシーバコンポーネント１１０およびリレーションシップ生成コンポーネント１２０を含むことができる。アイテムレシーバコンポーネント１１０は、アイテムおよび／またはそのエレメントを受信、検索、またはそうでない場合は取得する。アイテムは、限定されないが、データ型、オブジェクト、ウェブページ、およびＸＭＬドキュメントを含むことができる。リレーションシップ生成コンポーネント１２０は、複数のアイテムをアイテムレシーバコンポーネント１１０から受信、検索、またはそうでない場合は獲得する。リレーションシップ生成コンポーネント１２０はこれらのアイテムを解析し、アイテムの間のリレーションシップを指定および／または定義する。例えば、リレーションシップを、クラス、またはより具体的には静的クラスなど、プログラムコンストラクト内で定義することができる。クラスは、特定のリレーションシップに従ってアイテムまたはそのエレメントの様々なセットを検索するための機能性をカプセル化する、メソッドまたはメソッドへの参照を、クラスの外側で含むことができる。

リレーションシップシステム１００は、複数の意味で有益であることに留意されたい。例えば、システム１００は、開発において、このようなアイテム、および、これらのアイテムの間のリレーションシップまたはリンク、ならびに、モジュール性の概念の分離をサポートする。なおさらに、アイテムおよびリレーションシップの分離は柔軟性および拡張可能性を提供し、これは、これらのアイテムが常に変更のために使用可能であるとは限らない場合があり、または、これらのアイテムを修正することが実用的ではない場合があるからである。例えば、数十年前にあるレガシーフォーマットにおいて定義された、人、および、各人についてのデータまたはプロパティのコレクションがある状況を考察されたい。続いて、そのコレクションを修正して、各人に対して携帯電話番号を追加することは、可能または実現可能ではない場合がある。このとき、別のリレーションシップコンストラクトを生成して、人コレクションおよび別の携帯電話コレクションを関連付けることができる。

図２は、例示的リレーションシップ対話システム２００を例示する。システム２００は、課題の革新の態様の説明および考察を容易にするために提供される。システム２００は、１つまたは複数のリレーションシップメソッド２１０、ならびに、２つのアイテムＡ２２０およびＢ２３０を含む。グラフィカルに示すように、アイテムＡ２２０とアイテムＢ２３０の間のリレーションシップは、これらのアイテムのプロパティ内で、またはプロパティとして定義されない。むしろ、リレーションシップは、これらのアイテムの外部で、第１のクラス概念として定義される。リレーションシップメソッド２１０は、アイテムおよびアイテムエレメントと対話するために、計算をカプセル化する。

例として、限定ではなく、リレーショナルマッピングシナリオへのオブジェクトを考察する。具体的には、この状況は、オブジェクトを有するデータベースリレーションに対してプログラムすることが望ましい状況である。概念上、型Ｔのオブジェクトを含むデータベーステーブルをプログラミング言語において、Ｃ＃におけるＩＥｎｕｍｅｒａｂｌｅ＜Ｔ＞など、コレクション型により表現することができ、ただしＴは、テーブルのフィールドにマップするプロパティを有するクラスである。データベースリレーションシップを次いで、プログラミング言語において静的クラスにより表現することができる。そのクラスは、結合条件をカプセル化することによって、これらのリレーションシップをナビゲートする静的メソッドを提供する。例えば、アイテムＡ２２０を、顧客テーブルに対応するオブジェクト、型、またはクラスにすることができ、アイテムＢ２３０を、注文テーブルに対応するオブジェクト、型、またはクラスにすることができる。例えば、以下の通りである。

リレーションシップ２１０を、アイテムＡ２２０およびＢ２３０から分離して、以下のように、静的クラスなど、プログラムコンストラクトにおいて定義することができる。

ここで、クラスメソッドは、データストアを、顧客と注文との間に存在する可能性のある複数のリレーションシップに従ってナビゲートするためのメカニズムを提供する。ここで、２項（ｂｉｎａｒｙ）のリレーションシップは、クラスおよびクラスメソッドによってカプセル化される。２項のリレーションシップには、１対１、１対多数、多数対１、および多数対多数リレーションが含まれる可能性がある。第１のメソッド「ＧｅｔＣｕｓｔｏｍｅｒＧｉｖｅｎＯｒｄｅｒ」は、特定の注文が与えられると顧客が検索される１対１リレーションシップを取り込む。第２のメソッド「ＧｅｔＯｒｄｅｒｓＧｉｖｅｎＣｕｓｔｏｍｅｒ」は、多数対１リレーションシップである。ここで、特定の顧客に関連付けられた複数の注文が検索される。第３のメソッドおよび第４のメソッド「ＧｅｔＣｕｓｔｏｍｅｒｓＧｉｖｅｎＯｒｄｅｒｓ」および「ＧｅｔＯｒｄｅｒｓＧｉｖｅｎＣｕｓｔｏｍｅｒｓ」は、多数対多数である。具体的には、第１のメソッドは、指定された注文に関連付けられた顧客のコレクションを検索する。注文のセットが与えられると、第４のメソッドは、関係付けられた顧客を検索することができる。

前述および後続の実施例は、付属の特許請求の範囲の範囲を限定するように意味されない。この開示の態様は、複数のアイテムの間にリレーションシップまたはナビゲーションがあるいかなる状況にも適用可能である。例えば、リンクされたドキュメントシナリオを考察されたい。アイテムＡ２２０およびアイテムＢ２３０は、限定されないが、ハイパーテキストおよびＸＭＬを含む、様々なフォーマットのいずれか１つにおける電子ドキュメントとすることができる。アイテムＡ２２０からアイテムＢ２３０へのハイパーリンクなど、リンクを含むのではない。これらのドキュメントの間のリレーションシップ２１０を、その外部で定義することができる。これにより、ドキュメントの１つの修正を必要とすることなく、リレーションシップが定義されることが可能となる。

２項およびリンクの他に、他のリレーションシップもまた企図され、付属の特許請求の範囲の範囲内であり、リレーションシップは、限定されないが、コンポジションおよび関連付けを含む。アイテムは、他のアイテム内でネストされる場合、別のアイテムとのコンポジションリレーションシップを有する。したがって、アイテムまたはエンティティは、他のいかなるアイテムまたはエンティティを構成することもできる。以下のテーブルは、メッセージ参加者コンポジションリレーションシップを例示する。

関連付けにより、参照、共通値、条件およびエンティティを含む、いくつかの異なる型がある。参照関連付けは、主キー外部キーリレーションシップに対応する可能性がある。以下の例は、顧客−注文参照関連付けリレーションシップを示し、ただし、テーブル２は顧客に対応し、テーブル３は注文に対応する。

共通値関連付けは、共通値が２つ以上のアイテムに渡って共有されるリレーションシップである。例えば、以下のテーブルは、音楽家共通値関連付けが人（テーブル４）と器具（テーブル５）の間で示されることを例示する。

条件関連付けは、クエリ基準によって表現されたリレーションシップである。後続の例は、連絡先ドキュメント条件関連付けを提供する。

エンティティ関連付けは、他の型のリレーションを介して他のエンティティへのハブの機能を果たす、ｎ個のエンドポイントをアイテムまたはエンティティの周囲で有する。リンクリレーションを単に、１つのハブおよび２つの参照ベースのエンドポイントを有する、エンティティ関連付けの特殊な場合にすることができる。以下の例示的テーブルは雇用エンティティ関連付けを示し、ただし、テーブル８は雇用に対応し、テーブル９は人に対応し、テーブル１０は雇用者に対応する。

図３は、課題の発明の一態様によるリレーションシップシステム３００を例示する。図１のシステム１００と同様に、システム３００は、アイテムレシーバコンポーネント１１０およびリレーションシップ生成コンポーネント１２０を含む。上述のように、レシーバコンポーネント１１０は、２、３だが例を挙げると、データオブジェクト、ウェブページ、またはＸＭＬドキュメントなど、複数のエレメントを受信および／または検索することができる。リレーションシップ生成コンポーネント１２０は、エレメントをレシーバコンポーネント１１０から受信および／または検索することができる。リレーションシップ生成コンポーネント１２０は、これらのアイテムの間のリレーションシップまたはリンクを定義または指定することができる。さらに、生成コンポーネント１２０は、指定されたリレーションシップに応答して特定のアイテムまたはそのエレメントを検索するための、メソッドまたはその参照を提供することができる。再びシステム１００と同様に、システム３００はリレーションシップをクラス内で定義することができ、クラスは、リレーションシップを計算するためのメソッドを含むことができる。しかし、システム３００はまた、影響コンポーネント３１０を含むこともできる。影響コンポーネント３１０は、リレーションシップの名前付けに影響を及ぼすためのメカニズムである。課題の革新の一態様によれば、影響コンポーネント３１０は、関係付けられたエレメントの名前に基づいてリレーションシップ名を推論または推定するためのヒューリスティックまたは人工知能コンポーネント、メソッドまたはメカニズムを含むことができ、またはこれらに通信的に結合されることが可能である。例えば、２つのアイテム「顧客」および「注文」は、上の例のように、「ＧｅｔＣｕｓｔｏｍｅｒＧｉｖｅｎＯｒｄｅｒ」という名前のリレーションシップメソッドを有することができる。加えて、または代替として、影響コンポーネント３１０は、例えば、外部メタデータ情報によって駆動された名前付けスキームを受信および／または提供することによって、リレーションシップ生成コンポーネント１２０を支援することができる。

前述のように、リレーションシップを、数ある中でも、２項のリレーションシップまたは汎用のｎ項（ｎ−ａｒｙ）のリレーションシップ（例えば、ハブ−スポークリレーションシップ）にすることができる。２項のリレーションシップを、エンティティリレーションシップの話で利用されたように、１対１、１対多数、多数対１、または多数対多数リレーションシップにすることができる。型ＳおよびＴの間のリレーションシップを、静的クラスによりモデリングすることができる。以下の２項のいくつかのリレーションシップを取り込むクラスの例を考察されたい。

１対１リレーションシップの場合、ＧｅｔＴｓＧｉｖｅｎＳメソッドはＴの単一のインスタンスを戻し、多数対多数リレーションシップの場合、ＧｅｔＳＧｉｖｅｎＴメソッドは、ＩＥｎｕｍｅｒａｂｌｅなど、コレクション型を戻す。

リレーションシップクラス、静的メソッド、および引数名の名前を、限定されないが、ヒューリスティックスを型名に基づいて利用すること、および、外部メタデータ情報によって駆動された名前付けスキームを使用することを含む、様々な方法で派生させることが可能である。また、以前に提供したように、以下は「顧客」と「注文」の間のリレーションシップをモデリングする。

以下など、顧客テーブル内で顧客のセットを表現する変数が与えられる。

以下の静的メソッドを利用して、以下のようにその顧客のセットに関係付けられた注文のセットを検索することができる。

この静的メソッドコールは、結合条件をカプセル化する。

ｎ項のリレーションシップ（本明細書で、エンティティ関連付けとも称する）は、例えば特定の型の、または他の型を有する、２項のリレーションシップのセットである。一例は、ハブおよびスポークリレーションシップである。このようなリレーションシップのための設計パターンは以下の通りである。

技術的に、リレーションシップの様々な面におけるカーディナリティを区別することができるが、簡単にするために、ハブとスポークの間のすべての個々の２項のリレーションシップは１対多数であると仮定する。

単純な２項のリレーションシップの場合のように、リレーションシップクラスおよび静的メソッドの名前を、型名に基づいたヒューリスティックスから、外部メタデータ情報によって駆動された名前付けスキームまでに及ぶ、様々な方法で派生させることができる。以下の実施例は、「雇用」、「人」および「組織」の間のリレーションシップをモデリングする。「雇用」と「人」、および、「雇用」と「組織」の間の、２つの１対多数の２項のリレーションシップがある。「雇用」はハブの機能を果たす。

以下など、人テーブル内で人のセットを表現する変数が与えられる。

以下の静的メソッドは、その人のセットに関係付けられた雇用のセットを取得するために使用される。

以下の静的メソッドは、その雇用のセットに関係付けられた組織のセットを取得するために使用される。

後者の静的メソッドコールは、結合条件をカプセル化する。

型またはクラスリレーションシップを、型プロパティとのリレーションシップとしてモデリングすることができる。例えば、人という型および組織という型を含むシナリオであって、組織は人を雇用し、人は組織によって雇用されるシナリオを考察されたい。これは、Ｃ＃など、オブジェクト指向言語において以下のように表現される。

しかし、別々のクラスによるモデリングには、プロパティによるリレーションシップのモデリングに勝る利点がある。例えば、新しいリレーションシップを、複数の既存の型の間で、これらの型を修正することなく、作成することができる。プロパティを使用する上記のシナリオでは、「人」および「組織」型は、「雇用」型における依存を有する。さらに、プロパティによるリレーションシップのモデリングは、インスタンスからのナビゲーションのみを可能にするが、静的クラスからのリレーションシップのモデリングは、インスタンスのコレクションからのナビゲーションを可能にする。

静的メソッドを使用してリレーションシップを第１のクラス概念として表現する設計パターンは、プログラマに多大な表現力を与えるが、構文的には冗長である。また、これらのリレーションシップは異なるように見え、プロパティとしてモデリングされたリレーションシップよりも発見可能ではない。

図４は、課題の革新の一態様による、リレーションシップにアクセスする方法を構文的に単一化するコンパイルシステム４００を例示する。システム４００は、表現レシーバコンポーネント４１０、コード生成コンポーネント４２０、およびメタデータコンポーネント４３０を含む。レシーバコンポーネント４１０は、限定されないが、データ型を含む、複数のアイテムの間のリレーションシップを含む、プログラム表現を受信する。このプログラム表現を、リレーションシップがプロパティであるかのように指定される、簡略化された表現にすることができる。例えば、顧客テーブル内で顧客のセットを表現する変数、すなわち「ＩＥｎｕｍｅｒａｂｌｅ＜Ｃｕｓｔｏｍｅｒ＞ ｃｕｓｔｏｍｅｒｓ＝．．．；」が与えられると、以下の構文を使用して、その顧客のセットに関係付けられた注文のセットを取得することができ、すなわち「ＩＥｎｕｍｅｒａｂｌｅ＜Ｏｒｄｅｒ＞ ｏｒｄｅｒｓ＝ｃｕｓｔｏｍｅｒ．Ｏｒｄｅｒｓ」である。コード生成コンポーネントはこの表現を受信し、この表現から、より冗長なコード、または、「ＯｒｄｅｒＲｅｌａｔｉｏｎｓｈｉｐ．ＧｅｔＯｒｄｅｒＧｉｖｅｎＣｕｓｔｏｍｅｒｓ（ｃｕｓｔｏｍｅｒｓ）」など、メソッドへのコールを生成する。この機能性は、コード生成コンポーネント４２０によってメタデータコンポーネント４３０を介して可能にされる。メタデータコンポーネント４３０は、クラスに関するメタデータを検索または受信し、このメタデータをコード生成コンポーネント４２０に提供して、簡素化された表現から実際の、またはより冗長な表現へのマッピングを可能にすることができる。このメタデータは、「ＯｒｄｅｒＲｅｌａｔｉｏｎｓｈｉｐ．ＧｅｔＯｒｄｅｒＧｉｖｅｎＣｕｓｔｏｍｅｒｓ（ｃｕｓｔｏｍｅｒｓ）」が「ｃｕｓｔｏｍｅｒ．Ｏｒｄｅｒ」にマップすると指定することができる。課題の革新の一態様によれば、このようなメタデータを、複数のエレメントの間のリレーションシップを定義するクラスにおいて提供することができる。代替として、このメタデータを、コンパイルシステムおよび／またはコード生成コンポーネント４２０によって利用される、ある外部ファイルまたはスキーマによって提供することができる。

図５を参照すると、データ対話を容易にするためのインターフェイスシステム５００が例示される。インターフェイスシステム５００は、通信的に結合されたナビゲーションインターフェイスコンポーネント５１０およびデータインターフェイスコンポーネント５２０を含む。例として、データインターフェイスコンポーネント５２０は、ナビゲーションインターフェイスコンポーネント５１０によってコールまたは実行することができるメソッドを実装することができ、逆もまた同様である。ナビゲーションインターフェイスコンポーネント５１０は、リレーションシップ表現を受信することができる。インターフェイスコンポーネント５１０は、それぞれ「ｃｕｓｔｏｍｅｒ．Ｏｒｄｅｒｓ」または「ＯｒｄｅｒＲｅｌａｔｉｏｎｓｈｉｐ．ＧｅｔＯｒｄｅｒＧｉｖｅｎＣｕｓｔｏｍｅｒｓ（ｃｕｓｔｏｍｅｒｓ）」など、省略された、または、完全な長さの表現のいずれかを受信することができる。省略形が提供される場合、ナビゲーションインターフェイスコンポーネント５１０はこの表現を完全な長さの表現に変換することができる。この表現を次いで、ナビゲーションインターフェイスコンポーネント５１０からデータインターフェイスコンポーネント５２０に送信することができる。データインターフェイスコンポーネント５２０は、１つまたは複数のアイテムにおける実行のためにこの表現を提供することができる。データが検索される場合、データインターフェイスコンポーネント５２０は結果を、ナビゲーションインターフェイスコンポーネント５１０に戻すように送信することができる。したがって、ナビゲーションインターフェイスコンポーネント５１０およびデータインターフェイスコンポーネント５２０は、アプリケーションプログラムインターフェイス（ＡＰＩ）に対応する可能性がある。

図６は、課題の開示の一態様による統合された開発環境またはシステム６００を示す。システム６００は、エディタコンポーネント６１０およびプログラム支援コンポーネント６２０を含むことができる。エディタコンポーネント６１０は、コンピュータソースコードの編集および／または開発のために専門化されたテキストエディタである。具体的には、エディタコンポーネント６１０はリレーションシップの指定を受信することができる。テキストエディタは、プログラム支援コンポーネント６２０に通信的に結合される。支援コンポーネント６２０は、数ある中でも、ヒンティング、フォーマッティング、カラー化、ツールチップ、および、エラー指示または警告を含む、コーディング支援を提供することができる。例えば、ドットなど、アイテムおよびトリガを受信することに応答して、プログラム支援コンポーネント６２０は、テキストエディタコンポーネント６１０を提供すること、および／または、テキストエディタコンポーネント６１０にステートメート完成のための提案を表示させることができる。提案を、本明細書で提供されるようなリレーションシップに関して行うことができる。例えば、「ｃｕｓｔｏｍｅｒ．」を受信すると、「ｃｕｓｔｏｍｅｒ」についてのすべての注文が検索されることを示す、完全なステートメント「ｃｕｓｔｏｍｅｒ．Ｏｒｄｅｒｓ」のために、「Ｏｒｄｅｒｓ」を提案することができる。したがって、アイテムのプロパティとして現れるが、別々のリレーションシップ方法に対応する、ヒントまたは提案を行うことができる。

前述のシステムは、いくつかのコンポーネントの間の対話に関して説明された。このようなシステムおよびコンポーネントには、これらのコンポーネントまたはその中で指定されたサブコンポーネント、指定されたコンポーネントまたはサブコンポーネントのいくつか、および／または追加のコンポーネントが含まれる可能性があることを理解されたい。サブコンポーネントをまた、親コンポーネント内に含まれるのではなく、他のコンポーネントに通信的に結合されたコンポーネントとして実装することもできる。さらに、１つまたは複数のコンポーネントおよび／またはサブコンポーネントを単一のコンポーネントに結合して、集約機能性を提供することができる。これらのコンポーネントはまた、簡潔にするために本明細書で特に説明されないが、当業者には知られた、１つまたは複数の他のコンポーネントと対話することもできる。

さらに、理解されるように、開示された上記のシステムおよび以下の方法の様々な部分は、人工知能またはナレッジまたはルールベースのコンポーネント、サブコンポーネント、プロセス、手段、方法またはメカニズム（例えば、サポートベクトルマシン、ニューラルネットワーク、エキスパートシステム、ベイジアンネットワーク、ファジー理論、データフュージョンエンジン、分類子．．．）を含み、またはこれらからなる場合がある。このようなコンポーネントはとりわけ、それによってこれらのシステムおよび方法の部分をより適応的、ならびに効率的およびインテリジェントにするために実行された、あるメカニズムまたはプロセスを自動化することができる。例として、限定ではなく、影響コンポーネント３１０はこのような方法またはメカニズムを使用して、生成されたリレーションシップ名を推論し、これらに影響を及ぼすことができる。

上述の例示的システムに鑑みて、開示された内容によって実施することができる方法は、図７〜１０のフローチャートを参照してよりよく理解されるであろう。説明を簡単にするため、これらの方法を一連のブロックとして図示および説明するが、主張された内容はこれらのブロックの順序によって限定されず、これは、いくつかのブロックが異なる順序で、および／または、本明細書で図示および説明されるものとは別のブロックと同時に発生する場合があるからであることを理解されたい。また、すべての例示されたブロックが、以下に説明する方法を実施するために必要とされるとは限らない場合がある。

加えて、以下で、および、本明細書を通じて開示される方法は、このような方法をコンピュータにトランスポートおよび転送することを容易にするために製造品上に格納されることが可能であることを、さらに理解されたい。製造品という語は、本明細書で使用されるとき、いかなるコンピュータ読取可能な装置、搬送波または媒体からもアクセス可能なコンピュータプログラムをも包含するように意図される。

図７を参照すると、リレーションシップを定義する方法７００が示される。７１０では、アイテムが受信される。これらは、限定されないが、データ型およびドキュメント（例えば、ＸＭＬ、ワードプロセッシング、ＨＴＴＰ．．．）など、プログラムアイテムを含むことができる。７２０では、複数のアイテムの間のリレーションシップを定義する、クラスなど、コンストラクトが生成される。例えば、クラスを、オブジェクト指向の静的クラスにすることができる。さらに、クラスは、アイテムまたはエレメントリレーションシップの計算および／またはナビゲートをカプセル化する、静的メソッドを含むことができる。数ある中でも、リレーションシップを２項またはｎ項にすることができる。加えて、リレーションシップまたはメソッドの名前に、関係付けられるべきアイテムに関連付けられた名前または他のメタデータによって影響を及ぼすことができる。クラスを自動的に生成することができるが、例えば、データ型など、無数のエレメントを識別すること、および、ＩＤＥ（統合開発環境）または類似のシステムの助けの有無に関わらず、オブジェクト指向プログラミング言語において複数の要素の間のリレーションシップを定義するクラスを手動で指定することによって、方法４００をまた手動で実施することもできることを理解されたい。

図８は、本開示の一態様によるコンパイル方法８００を示す。８１０では、リレーションシップ表現が受信される。リレーションシップ表現を、「ｃｕｓｔｏｍｅｒ．Ｏｒｄｅｒｓ」など、クラスのプロパティとして表現することができる。８２０では、コンパイラまたは他のシステムはこの表現を受信し、例えば、複数のアイテムの間のリレーションシップを指定する、クラス内で定義されたメソッドに関連付けられたコードを生成、またはそのコードに拡張することができる。このようなコード生成を容易にするために、コンパイラは、例えば、リレーションシップクラスに関連付けられたメタデータを利用して、表現とより冗長なメソッド呼び出しの間のマッピングを決定することができる。したがって、コンパイラは、静的メソッドの呼び出しを、型など、アイテム上で直接定義されたプロパティとして現れるようにする。

図９を参照すると、データと対話するための方法９００が例示される。参照符号９１０では、リレーションシップ表現が受信される。リレーションシップ表現は、２つ以上のアイテムまたはエレメント、および、複数のアイテムの間のリレーションシップを識別する。本開示の一態様によれば、この表現をプロパティフォーマット内で指定して、例えば、「ｃｕｓｔｏｍｅｒ．Ｏｒｄｅｒｓ」、「ｏｒｄｅｒ．Ｃｕｓｔｏｍｅｒ」または「ｏｒｄｅｒｓ．Ｃｕｓｔｏｍｅｒｓ」など、リレーションシップがアイテムのプロパティであるように見えるようにすることができる。参照符号９２０では、リレーションシップ表現に関連付けられたメソッドが探し出される。ある場合では、このメソッドは、それによりアイテム自体から独立して定義された別のリレーションシップクラス内に存在する可能性がある。例えば、「ｃｕｓｔｏｍｅｒ．Ｏｒｄｅｒｓ」は注文リレーションシップクラス、および特にメソッド「ＧｅｔＯｒｄｅｒｓＧｉｖｅｎＣｕｓｔｏｍｅｒ（Ｃｕｓｔｏｍｅｒ ｃｕｓｔｏｍｅｒ）」にマップすると、決定することができる。９３０では、このメソッドを実行することができる。このメソッドはデータナビゲーション、およびオプショナルで、検索、追加、除去または他のデータ対話もしくは操作など、追加の機能性を容易にすることができる。参照符号９４０では、適切な場合には結果を戻すことができる。

図１０は、本開示の一態様によるプログラム支援方法１０００である。方法１０００は、リレーションシップの指定において支援することができる。参照符号１０１０では、特定の型のアイテムが受信、検索またはそうでない場合は獲得される。アイテムの後に続いて、１０２０では、トリガが受信、検索またはそうでない場合は得られる。トリガは、数ある中でも、スペース（「 」）、ドット（「．」）、およびキャリッジリターンのようなものに対応する可能性がある。参照符号１０３０では、支援が、例えば、定義されたリレーションシップに基づいたヒントの形態において提供される。例えば、ユーザーが「ｃｕｓｔｏｍｅｒ．」と入力する場合、数ある中でも「Ｏｒｄｅｒｓ」など、完成ヒントを提供することができる。ヒントをユーザーに対し、例えばドロップダウンメニュー内で表示することができる。選択すると、ステートメントを完成させ、「ｃｕｓｔｏｍｅｒ．Ｏｒｄｅｒｓ」と読むことができる。これは、所与のアイテムに関連付けられたすべての可能性のあるリレーションシップを記憶または思い出す負担を軽減し、とりわけ誤字を最小限にする。

ヒンティングに加えて、リレーションシップ表現に関係付けられたユニークなフォーマッティングおよび／またはカラー化など、他の形態のプログラム支援を提供することができることに留意されたい。さらに、ツールチップを提供することができ、ツールチップでは、カーソルのロールオーバーまたはホバーがあると、および／または、所定の組み合わせのキーの押し下げがあると、例えば型情報がテキストボックスまたは吹き出し内でバブルアップされる。リレーションシップ表現に関するさらなるプログラム支援もまた企図され、内容の特許請求の範囲の範囲内である。

図１１は、実装コード（例えば、実行可能なファイル、中間言語．．．）を生成するために利用することができる、コンパイラ環境１１００を示すブロック図である。しかし、環境１１００の態様をまた、例えばコードエディタに関係付けられた、バックグラウンドコンパイラの一部として使用して、インテリジェントまたはコンテキスト依存プログラミング支援が提供されることを可能にすることもできる。コンパイラ環境１１００は、フロントエンドコンポーネント１１２０、コンバータコンポーネント１１３０、バックエンドコンポーネント１１４０、エラーチェッカーコンポーネント１１５０、シンボルテーブル１１６０、パースツリー１１７０、および状態１１８０を含む、コンパイラ１１２０を含む。コンパイラ１１２０はソースコードを入力として受け入れ、実装コードを出力として作成する。入力は、限定されないが、リレーションシップ表現、クラス、および／または、本明細書で説明された他のコンストラクトを含むことができる。コンパイラ環境１１００のコンポーネントおよびモジュールの間のリレーションシップは、データのメインフローを例示する。他のコンポーネントおよびリレーションシップは、明瞭および簡単にするために例示されない。実装に応じて、コンポーネントを追加、省略、複数のモジュールへ分割、他のモジュールおよび／またはモジュールの他の構成と結合することができる。

コンパイラ１１２０は入力として、一連のエレメントの処理に関連付けられたソースコードを有するファイルを受け入れることができる。ソースコードには、リレーションシップ表現、クラス、他の表現、メソッド、および／またはプログラムコンストラクトが含まれる場合がある。コンパイラ１１２０は、コンストラクトを解析し、コードを生成または注入するための１つまたは複数のコンポーネントと共に、ソースコードを処理することができる。

フロントエンドコンポーネント１１２０は、字句解析をソースコード上で読み取り、実行する。本質的には、フロントエンドコンポーネント１１２０は、一連の文字（例えば、英数字）をソースコード内で読み取り、数ある中でも定数、識別子、演算子記号、キーワード、および句読点を指示する、構文エレメントまたはトークンに変換する。

コンバータコンポーネント１１３０は、トークンを中間表現に解析する。例えば、コンバータコンポーネント１１３０は構文をチェックし、トークンを表現または他の構文構造にグループ化することができ、これらの表現または他の構文構造はステートメントツリーに合体する。概念上では、これらのツリーはパースツリー１１７０を形成する。さらに、および適切なように、コンバータコンポーネント１１３０はエントリを、関係付けられた特性と共にソースコード内で使用されたシンボル名および型情報をリストするシンボルテーブル１１６０に入れることができる。

状態１１８０を使用して、受信または検索されたソースコードの処理およびパースツリー１１７０の形成において、コンパイラ１１２０の進行を追跡することができる。例えば、異なる状態値は、コンパイラ１１２０がクラス定義または関数の開始であり、クラスメンバを宣言したばかりであり、または表現を完成させたことを指示する。コンパイラが進行するにつれて、コンパイラは引き続き、状態１１８０をアップデートする。コンパイラ１１２０は部分的または完全に状態１１８０を外部エンティティに公開する場合があり、外部エンティティは次いで入力をコンパイラ１１２０に提供することができる。

ソースコード内のコンストラクトまたは他の信号に基づいて（または、その機会が別の方法で認識される場合）、コンバータコンポーネント１１３０または別のコンポーネントはコードを注入して、効率的および適切な実行を容易にすることができる。例えば、コードを注入して、包含省略形（ｃｏｍｐｒｅｈｅｎｓｉｏｎ ａｂｂｒｅｖｉａｔｉｏｎ）を拡張し、または、クエリ包含（ｑｕｅｒｙ ｃｏｍｐｒｅｈｅｎｓｉｏｎ）からシーケンス演算子へ変換することができる。コンバータコンポーネント１１３０または他のコンポーネントにコーディングされたルールは、所望の機能性を実装するために何が行われなければならないかを指示し、このコードが注入されるべきである、または、他の演算が実行されるべきであるロケーションを識別する。注入されたコードは通常、追加されたステートメント、メタデータ、または他のエレメントを１つまたは複数のロケーションで含むが、この語にはまた、既存のソースコードを変更、削除、またはそうでない場合は修正することが含まれる可能性もある。注入されたコードを１つまたは複数のテンプレートとして、またはある他の形態で格納することができる。加えて、シンボルテーブル操作およびパースツリー変換が行われる可能性があることを理解されたい。

シンボルテーブル１１６０およびパースツリー１１７０に基づいて、バックエンドコンポーネント１１４０は中間表現を出力コードに変換することができる。バックエンドコンポーネント１１４０は中間表現を、ターゲットプロセッサ内で、またはターゲットプロセッサによって実行可能な命令、変数のためのメモリ割り振りなどに変換する。出力コードは実際のプロセッサによって実行可能にすることができるが、本発明はまた、仮想プロセッサによって実行可能である出力コードをも企図する。

さらに、フロントエンドコンポーネント１１２０およびバックエンドコンポーネント１１４０は、コード最適化など、追加の機能を実行することができ、説明された演算を単一のフェーズとして、または複数のフェーズにおいて実行することができる。コンパイラ１１２０のコンポーネントの様々な他の態様は、性質において従来のものであり、同等の機能を実行するコンポーネントで代用することができる。加えて、ソースコードの処理中の様々なステージで、エラーチェッカーコンポーネント１１５０は、字句構造におけるエラー、構文エラー、および意味エラーなどのエラーもチェックすることができる。検出エラーにおいて、チェッカーコンポーネント１１５０はコンパイルを停止し、エラーを示すメッセージを生成することができる。

開示された内容の様々な態様のための状況を提供するために、図１２および１３ならびに以下の考察は、開示された内容の様々な態様を実装することができる適切な環境の簡単な全体的説明を提供するように意図される。内容を一般に、１台のコンピュータおよび／または複数のコンピュータ上で実行するコンピュータプログラムのコンピュータ実行可能な命令との関連で上述したが、本発明をまた他のプログラムモジュールとの組み合わせで実装することもできることは、当業者には理解されよう。一般に、プログラムモジュールには、ルーチン、プログラム、コンポーネント、データ構造などが含まれ、これらは特定のタスクを実行するか、および／または、特定の抽象データ型を実装する。また、本発明の方法を他のコンピュータシステム構成により実装することができ、これらの構成には、シングルプロセッサまたはマルチプロセッサコンピュータシステム、ミニコンピューティング装置、メインフレームコンピュータ、ならびに、パーソナルコンピュータ、ハンドヘルドコンピューティング装置（例えば、携帯情報端末（ＰＤＡ）、電話、腕時計．．．）、マイクロプロセッサベースまたはプログラマブルコンシューマまたは産業エレクトロニクスなどが含まれることは、当業者には理解されよう。例示された態様をまた分散コンピューティング環境で実装することもでき、この環境ではタスクが、通信ネットワークを通じてリンクされるリモート処理装置によって実行される。しかし、課題の革新の、すべてではない場合はいくつかの態様を、スタンドアロンコンピュータ上で実装することができる。分散コンピューティング環境では、プログラムモジュールはローカルおよびリモートのメモリストレージデバイス内に位置することができる。

図１２を参照すると、本明細書で開示された様々な態様を実装するための例示的環境１２１０には、コンピュータ１２１２（例えば、デスクトップ、ラップトップ、サーバ、ハンドヘルド、プログラマブルコンシューマまたは産業エレクトロニクス．．．）が含まれる。コンピュータ１２１２には、処理装置１２１４、システムメモリ１２１６、およびシステムバス１２１８が含まれる。システムバス１２１８は、限定されないが、システムメモリ１２１６を含むシステムコンポーネントを処理装置１２１４に結合する。処理装置１２１４を様々な使用可能なマイクロプロセッサのいずれにすることもできる。デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャもまた、処理装置１２１４として使用することができる。

システムバス１２１８を、いくつかの種類のバス構造のいずれにすることもでき、これらのバス構造には、様々な使用可能なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バスまたは外部バス、および／またはローカルバスが含まれ、このようなバスアーキテクチャは、限定されないが、１１ビットバス、業界標準アーキテクチャ（ＩＳＡ）、マイクロチャネルアーキテクチャ（ＭＣＡ）、拡張ＩＳＡ（ＥＩＳＡ）、Ｉｎｔｅｌｌｉｇｅｎｔ Ｄｒｉｖｅ Ｅｌｅｃｔｒｏｎｉｃｓ（ＩＤＥ）、ＶＥＳＡローカルバス（ＶＬＢ）、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）、ユニバーサルシリアルバス（ＵＳＢ）、Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）、Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ Ｍｅｍｏｒｙ Ｃａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ａｓｓｏｃｉａｔｉｏｎバス（ＰＣＭＣＩＡ）、およびＳｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ（ＳＣＳＩ）を含む。

システムメモリ１２１６には、揮発性メモリ１２２０および不揮発性メモリ１２２２が含まれる。基本入出力システム（ＢＩＯＳ）は、起動中など、コンピュータ１２１２内の複数の要素の間で情報を転送するための基本ルーチンを含み、不揮発性メモリ１２２２に格納される。例示のため、限定ではなく、不揮発性メモリ１２２２には、読み取り専用メモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、電気的プログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）、またはフラッシュメモリが含まれる可能性がある。揮発性メモリ１２２０にはランダムアクセスメモリ（ＲＡＭ）が含まれ、ＲＡＭは外部キャッシュメモリとしての機能を果たす。例として、限定ではなく、ＲＡＭは多数の形態において使用可能であり、これらの形態は、シンクロナスＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、拡張ＳＤＲＡＭ（ＥＳＤＲＡＭ）、シンクリンクＤＲＡＭ（ＳＬＤＲＡＭ）、および直接Ｒａｍｂｕｓ ＲＡＭ（ＤＲＲＡＭ）などである。

コンピュータ１２１２はまた、取外し可能／固定の、揮発性／不揮発性のコンピュータストレージメディアも含む。図１２は、例えば、ディスクストレージ１２２４を例示する。ディスクストレージ１２２４は、限定されないが、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカードまたはメモリスティックを含む。加えて、ディスクストレージ１２２４はストレージメディアを別々に、または、他のストレージメディアと組み合わせて含むことができ、媒体は、限定されないが、コンパクトディスクＲＯＭ装置（ＣＤ−ＲＯＭ）、書き込み可能ＣＤドライブ（ＣＤ−Ｒドライブ）、再書き込み可能ＣＤドライブ（ＣＤ−ＲＷドライブ）またはデジタル多用途ディスクＲＯＭドライブ（ＤＶＤ−ＲＯＭ）など、光ディスクドライブを含む。ディスクストレージデバイス１２２４をシステムバス１２１８に接続することを容易にするために、インターフェイス１２２６など、取外し可能または固定のインターフェイスが通常は使用される。

図１２は、ユーザーと、適切なオペレーティング環境１２１０において説明した基本コンピュータリソースの間の、媒介物の機能を果たすソフトウェアを説明することを理解されたい。このようなソフトウェアにはオペレーティングシステム１２２８が含まれる。オペレーティングシステム１２２８をディスクストレージ１２２４上に格納することができ、オペレーティングシステム１２２８は、コンピュータシステム１２１２のリソースをコントロールし、割り振るように動作する。システムアプリケーション１２３０は、システムメモリ１２１６内またはディスクストレージ１２２４上に格納されたプログラムモジュール１２３２およびプログラムデータ１２３４を通じて、オペレーティングシステム１２２８によるリソースの管理を利用する。本発明を様々なオペレーティングシステムまたはオペレーティングシステムの組み合わせにより実装することができることを理解されたい。

ユーザーはコマンドまたは情報をコンピュータ１２１２へ、入力装置１２３６を通じて入力する。入力装置１２３６は、限定されないが、マウスなどのポインティングデバイス、トラックボール、スタイラス、タッチパッド、キーボード、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、ウェブカメラなどを含む。これらおよび他の入力装置は処理装置１２１４へ、システムバス１２１８を通じて、インターフェイスポート１２３８を介して接続する。インターフェイスポート１２３８には、例えば、シリアルポート、パラレルポート、ゲームポートおよびユニバーサルシリアルバス（ＵＳＢ）が含まれる。出力装置１２４０は、入力装置１２３６と同じ種類のポートのいくつかを使用する。したがって、例えば、ＵＳＢポートを使用して入力をコンピュータ１２１２に提供し、情報をコンピュータ１２１２から出力装置１２４０に出力することができる。出力アダプタ１２４２が提供されて、他の出力装置１２４０の中でも特殊なアダプタを必要とするディスプレイ（例えば、フラットパネルおよびＣＲＴ）、スピーカおよびプリンタのようないくつかの出力装置１２４０があることが例示される。出力アダプタ１２４２には、例として、限定ではなく、ビデオおよびサウンドカードが含まれ、これらは出力装置１２４０とシステムバス１２１８の間の接続の手段を提供する。リモートコンピュータ１２４４など、他の装置および／または装置のシステムが入力および出力機能を提供することに留意されたい。

コンピュータ１２１２はネットワーク環境において、リモートコンピュータ１２４４など、１つまたは複数のリモートコンピュータへの論理接続を使用して動作することができる。リモートコンピュータ１２４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースのアプライアンス、ピアデバイスまたは他の共通ネットワークノードなどにすることができ、通常は、コンピュータ１２１２に関連して上述した要素の多数またはすべてが含まれる。簡潔にするため、メモリストレージデバイス１２４６のみをリモートコンピュータ１２４４と共に例示する。リモートコンピュータ１２４４はコンピュータ１２１２に、ネットワークインターフェイス１２４８を通じて論理的に接続され、次いで通信接続１２５０を介して物理的に接続される。ネットワークインターフェイス１２４８は、ローカルエリアネットワーク（ＬＡＮ）およびワイドエリアネットワーク（ＷＡＮ）など、通信ネットワークを包含する。ＬＡＮ技術には、ファイバー分散データインターフェイス（ＦＤＤＩ）、Ｃｏｐｐｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ（ＣＤＤＩ）、イーサネット（登録商標）／ＩＥＥＥ ８０２．３、トークンリング／ＩＥＥＥ ８０２．５などが含まれる。ＷＡＮ技術は、限定されないが、ポイントツーポイントリンク、統合デジタルサービス通信網（ＩＳＤＮ）およびその変形形態のような回線交換網、パケット交換網およびデジタル加入者線（ＤＳＬ）を含む。

通信接続１２５０は、ネットワークインターフェイス１２４８をバス１２１８に接続するために使用されるハードウェア／ソフトウェアを指す。通信接続１２５０を、例示的に明瞭にするためにコンピュータ１２１２内に示すが、コンピュータ１２１２の外部にすることもできる。ネットワークインターフェイス１２４８への接続のために必要なハードウェア／ソフトウェアには、例示のためにのみ、内部および外部技術が含まれ、これらの技術は、通常の電話のグレードのモデム、ケーブルモデム、パワーモデム、およびＤＳＬモデムを含むモデム、ＩＳＤＮアダプタ、および、イーサネット（登録商標）カードまたはコンポーネントなどである。

図１３は、本発明が対話することができるサンプルコンピューティング環境１３００の概略なブロック図である。システム１３００は１つまたは複数のクライアント１３１０を含む。クライアント１３１０を、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティング装置）にすることができる。システム１３００はまた、１つまたは複数のサーバ１３３０をも含む。したがって、システム１３００は、他のモデルの中でも、２層クライアントサーバモデルまたは多層モデル（例えば、クライアント、中間層サーバ、データサーバ）に対応する可能性がある。サーバ１３３０もまた、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティング装置）にすることができる。サーバ１３３０は、例えば、本発明を使用することによって変換を実行するためのスレッドを収容することができる。クライアント１３１０とサーバ１３３０の間の１つの可能な通信は、２つ以上のコンピュータプロセスの間で送信されるように適合されたデータパケットの形態であってもよい。

システム１３００は、クライアント１３１０とサーバ１３３０の間の通信を容易にするために使用することができる、通信フレームワーク１３５０を含む。クライアント１３１０は、クライアント１３１０のローカルで情報を格納するために使用することができる１つまたは複数のクライアントデータストア１３６０に、動作可能に接続される。同様に、サーバ１３３０は、サーバ１３３０のローカルで情報を格納するために使用することができる１つまたは複数のサーバデータストア１３４０に、動作可能に接続される。

上述したものには、主張された内容の態様の実施例が含まれる。言うまでもなく、主張された内容を説明するためのコンポーネントまたは方法のあらゆる考えられる組み合わせを説明することは可能ではないが、開示された内容の多数のさらなる組み合わせおよび置換が可能であることは、当業者には理解されよう。したがって、開示された内容は、付属の特許請求の範囲の精神および範囲内に入るこのようなすべての変更、修正および変形形態を包含するように意図される。さらに、「含む」、「有する」もしくは「有している」という語、またはそれらの変形物が詳細な説明または特許請求の範囲において使用される範囲で、このような語は、「備える」という語が、特許請求の範囲内の前後を接続させる語として使用されるときに解釈されるときの「備える」と同様に、包含的であるように意図される。

リレーションシップシステムのブロック図である。 例示的リレーションシップシステムのブロック図である。 影響コンポーネントを含むリレーションシップシステムのブロック図である。 コンパイルシステムのブロック図である。 データとの対話を容易にするためのインターフェイスシステムのブロック図である。 統合された開発システムまたは環境のブロック図である。 リレーションシップを定義する方法のフローチャートである。 コンパイル方法のフローチャートである。 データ対話方法のフローチャートである。 プログラム開発を支援する方法のフローチャートである。 例示的コンパイル環境の概略的なブロック図である。 適切なオペレーティング環境を例示する概略的なブロック図である。 サンプルコンピューティング環境の概略的なブロック図である。

符号の説明

１１０ アイテムレシーバコンポーネント
１２０ リレーションシップ生成コンポーネント

Claims (20)

1. コンピュータ実行可能なコンポーネントを有するコンピュータに実装されたリレーションシップシステムであって、
   ２つ以上のプログラムアイテムを取得するアイテムレシーバコンポーネントと、
   前記レシーバコンポーネントからアイテムを受信し、および１つまたは複数のリレーションシップを前記アイテムの間で定義するコンストラクトを生成するリレーションシップ生成コンポーネントと
   を備えたことを特徴とするシステム。
2. 前記アイテムは、データ型およびＸＭＬドキュメントのうち１つであることを特徴とする請求項１に記載のシステム。
3. コンストラクトは、クラスであることを特徴とする請求項１に記載のシステム。
4. 前記クラスは、特定のアイテムエレメントを、指定されたリレーションシップにより検索するためのメソッドを含むことを特徴とする請求項３に記載のシステム。
5. 前記クラスは、静的クラスであることを特徴とする請求項４に記載のシステム。
6. 前記１つまたは複数のリレーションシップは、１対１、１対多数、多数対１、および多数対多数を含む２項であることを特徴とする請求項１に記載のシステム。
7. 前記１つまたは複数のリレーションシップは、前記アイテムに関するナビゲーション計算をカプセル化するメソッドにより指定されることを特徴とする請求項１に記載のシステム。
8. 前記１つまたは複数のリレーションシップは、コンポジション、関連付けおよびリンクのうち１つを含むことを特徴とする請求項１に記載のシステム。
9. 前記関連付けは、共通値、条件およびエンティティのうち１つであることを特徴とする請求項１に記載のシステム。
10. リレーションシップについてアイテム固有の名前を生成するための影響コンポーネントをさらに備えたことを特徴とする請求項１に記載のシステム。
11. データ構造を格納しているコンピュータ読取可能な媒体であって、
    第１のデータ型と、
    第２のデータ型と、
    前記第１のデータ型と前記第２のデータ型との間のリレーションシップを、前記型から独立して定義するクラスと
    を備えたことを特徴とするコンピュータ読取可能な媒体。
12. 前記クラスは、型の間の前記リレーションシップを定義する計算をカプセル化するメソッドを含むことを特徴とする請求項１１に記載のコンピュータ読取可能な媒体。
13. 前記リレーションシップは、２項、コンポジション、関連付けおよびリンクのうち１つを含むことを特徴とする請求項１２に記載のコンピュータ読取可能な媒体。
14. 前記型は、データベーステーブルにマップし、および前記リレーションシップは、前記テーブル間の共通プロパティ上で結合を取り込むことを特徴とする請求項１２に記載のコンピュータ読取可能な媒体。
15. コンピュータ実行可能な動作を有し、データ対話を容易にするコンピュータに実装された方法であって、
    ２つ以上のアイテム間のリレーションシップ表現を受信するステップと、
    前記表現に関連付けられた前記アイテムの外部でメソッドを探し出すステップと、
    前記メソッドを実行して、前記リレーションシップを計算し、および／または前記アイテムの間でナビゲートするステップと
    を備えたことを特徴とする方法。
16. 結果を戻すステップをさらに備えたことを特徴とする請求項１５に記載の方法。
17. リレーションシップ表現を受信するステップは、プロパティ表記における型間のリレーションシップを受信するステップを備えたことを特徴とする請求項１５に記載の方法。
18. メソッドを探し出すステップは、前記表現をプロパティ表記からメソッド名に拡張するステップを含むことを特徴とする請求項１７に記載の方法。
19. メソッドを探し出すステップは、１つまたは複数のリレーションシップメソッドを含んでいるリレーションシップクラスを識別するステップを含むことを特徴とする請求項１８に記載の方法。
20. 前記リレーションシップは、２項、コンポジション、関連付けおよびリンクのうち１つを含むことを特徴とする請求項１５に記載の方法。
    

Images