JP2006065861A - 継ぎ目なくオブジェクトを比較するシステムおよび方法 - Google Patents

Abstract

【課題】 同じ型、類似の型、または異なる型のオブジェクトに作用する比較手法を提供すること。
【解決手段】 複数の比較オブジェクトを１つまたは複数の参照オブジェクトと突き合わせて比較することができる。比較オブジェクトは、オブジェクトベースの環境内で稼働するｃｍｄｌｅｔｓのパイプライン内の前のｃｍｄｌｅｔから得られる。参照オブジェクトと比較オブジェクトは、順序に基づいて、またはキーに基づいて比較することができる。さらに、比較時に比較対象となる参照オブジェクトおよび比較オブジェクトのプロパティを識別する特定のプロパティを指定することができる。比較により、相違点および／または類似点を識別する出力を生成できる。出力を他のｃｍｄｌｅｔにパイプラインで送り、さらに処理することができる。
【選択図】 図１４

Description

本発明は、コンピュータ実装比較手法に関するものであり、より詳細には、複数のオブジェクトに作用するコンピュータ実装比較手法に関する。

管理業務は、ラップトップ、デスクトップなどのコンピューティング装置の日々の運用を支援する。ネットワーク接続されたコンピューティング装置を保守するシステム管理者は、多くの管理業務を実施する。管理業務の１つは、コンピューティング装置が望んだとおりに動作しないといういくつかの問題点を識別する作業を伴う。この種の問題を診断する手法の１つは、コンピューティング装置を稼働中のコンピューティング装置と比較する作業を伴う。この比較では、グラフィカルユーザインターフェイスを使用して２つの装置間の設定を目で見て再検討するか、または２つの装置上の類似ファイルの比較を実行することができる。

比較のためのさまざまなユーティリティが、かなりの長期間にわたって利用されてきた。しかし、ファイルの型毎に、ファイルのその型に固有のツールが使用され、独自の構文および独自の特徴が備わっている。例えば、ファイルの型がテキストファイルの場合には、テキスト比較ツールが使用される。同様に、ファイルの型がバイナリファイルの場合には、バイナリファイル比較ツールが使用される。一般に、これらの比較ユーティリティは、相違点が見つかるまでファイル群を見て行く。相違点が見つかったら、相違点がシステム管理者に報告される。これらの比較ユーティリティは役立つが、多くの場合、問題に関係しない相違点も報告する。したがって、より正確な結果が得られ、多目的に使える比較手法が必要とされる。

本発明の比較手法は、同じ型、類似の型、または異なる型のオブジェクトに作用する。複数の比較オブジェクトを１つまたは複数の参照オブジェクトと突き合わせて比較することができる。比較オブジェクトは、オブジェクトベースの環境内で稼働するｃｍｄｌｅｔｓのパイプライン内の前のｃｍｄｌｅｔから得られる。参照オブジェクトと比較オブジェクトとは、順序に基づいて、またはキーに基づいて比較することができる。さらに、比較時に比較対象となる参照オブジェクトおよび比較オブジェクトのプロパティを識別する特定のプロパティを指定することができる。比較により、相違点または類似点を識別する出力を生成できる。出力を他のｃｍｄｌｅｔにパイプラインで送り、さらに処理することができる。

簡単に言うと、本発明の比較手法は、同じ型、類似の型、または異なる型のオブジェクトに作用する。比較では、最終的に問題を解決することができる他のオペレーションへの入力として比較結果を自動的に使用できる。

以下の詳細な説明は、複数の節に分けられる。第１節では、比較手法を運用できるコンピューティング環境例を説明する。第２節では、本発明の比較手法を組み込むことができるオブジェクトベースの管理ツール環境のフレームワーク例を説明する。これは、フレームワーク例の個別のコンポーネントおよびそれらのコンポーネントのオペレーションの詳細な説明を含む。第３節では、比較手法およびそのオペレーションについて説明する。

第１節：コンピューティング環境の実施例
図１に、本発明の比較手法を実装する際に使用できるコンピューティング装置例を示す。最も基本的な構成では、コンピューティング装置１００は、通常、少なくとも１つの処理装置１０２およびシステムメモリ１０４を備える。コンピューティング装置の正確な構成と種類に応じて、システムメモリ１０４は、揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、またはこれら２つの何らかの組み合わせとすることができる。システムメモリ１０４は、通常、オペレーティングシステム１０５、１つまたは複数のプログラムモジュール１０６を格納し、１つまたは複数のプログラムデータ１０７を含むこともできる。システムメモリ１０４は、さらに、（プロパティおよびイベントを含む）コンポーネント、オブジェクト、継承、多態性、リフレクションをサポートするコンポーネントベースのフレームワーク１２０を格納し、ワシントン州レッドモンドのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ社製の．ＮＥＴ（商標）フレームワークなどのオブジェクト指向コンポーネントベースのアプリケーションプログラミングインターフェイス（ＡＰＩ）を提供する。システムメモリ１０４は、さらに、管理ツール（図に示されていない）の開発をサポートするコンポーネントベースのフレームワーク１２０とやり取りする管理ツールフレームワーク２００も格納する。コンポーネントベースのフレームワーク１２０および管理ツールフレームワーク２００は、オペレーティングシステム１０５の一部として常駐するか（図に示されているように）、またはプログラムモジュール１０６の一部として常駐することができる。基本構成は、図１において点線１０８内のコンポーネントにより示されている。

コンピューティング装置１００は、さらに特徴または機能を追加することもできる。例えば、コンピューティング装置１００は、磁気ディスク、光ディスク、またはテープなどの（取り外し可能および／または固定の）追加のデータ記憶装置を備えることもできる。このような追加記憶装置は、図１では、取り外し可能記憶装置１０９および固定の記憶装置１１０により例示されている。コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および固定の媒体を含むことができる。システムメモリ１０４、取り外し可能記憶装置１０９、および固定の記憶装置１１０は、すべてコンピュータ記憶媒体の実施例である。コンピュータ記憶媒体としては、限定ではないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、または所望の情報を格納するために使用することができコンピューティング装置１００によりアクセスできるその他の媒体がある。このような任意のコンピュータ記憶媒体を装置１００の一部とすることができる。さらにコンピューティング装置１００は、キーボード、マウス、ペン、音声入力装置、タッチ入力装置などの（複数の）入力装置１１２を備えることもできる。ディスプレイ、スピーカ、プリンタなどの（複数の）出力装置１１４を備えることもできる。これらの装置は、当業ではよく知られているため、本明細書でさらに詳しい説明をする必要はない。

また、コンピューティング装置１００は、装置がネットワークなどを経由して他のコンピューティング装置１１８と通信するために使用する通信接続１１６も含むことができる。通信接続１１６は、通信媒体の一実施例である。通信媒体は、通常、搬送波またはその他のトランスポート機構などの変調データ信号を介して、コンピュータ読み取り可能命令、データ構造体、プログラムモジュール、またはその他のデータによって実現されることができ、情報配信媒体を含む。「変調データ信号」という用語は、信号内の情報を符号化する方法によりその特性のうち１つまたは複数が設定または変更された信号を意味する。例えば、限定ではないが、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、ならびに、音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体がある。本明細書で使用されているコンピュータ読み取り可能媒体という用語は、記憶媒体と通信媒体の両方を含む。

第２節：管理ツールフレームワーク
図２は、管理ツールフレームワーク２００の例の概要を一般的に示すブロック図である。管理ツールフレームワーク２００は、１つまたは複数のホストコンポーネント２０２、プラットフォーム固有コンポーネント２０４、ホスト独立コンポーネント２０６、およびハンドラコンポーネント２０８を備える。ホスト独立コンポーネント２０６は、他のコンポーネントのそれぞれ（つまり、ホストコンポーネント２０２、プラットフォーム固有コンポーネント２０４、およびハンドラコンポーネント２０８）と通信することができる。これらのコンポーネントのそれぞれについて、以下で簡単に説明し、必要に応じて、後の節でさらに詳しく説明する。

（ホストコンポーネント）
ホストコンポーネント２０２は、関連付けられたアプリケーションの自動化機能をユーザまたはその他のプログラムに公開する１つまたは複数のホストプログラム（例えば、ホストプログラム２１０〜２１４）を備える。自動化機能は、ナビゲーション、診断、構成、ライフサイクル、オペレーションなどを自動化することができる。それぞれのホストプログラム２１０〜２１４は、コマンドライン、グラフィカルユーザインターフェイス（ＧＵＩ）、音声認識インターフェイス、アプリケーションプログラミングインターフェイス（ＡＰＩ）、スクリプト言語、Ｗｅｂサービスなどを介して、特定のスタイルでこれらの自動化機能を公開することができる。しかし、ホストプログラム２１０〜２１４はそれぞれ、管理ツールフレームワークが備える機構を通じて１つまたは複数の自動化機能を公開する。

この実施例では、この機構はｃｍｄｌｅｔｓを使用して、関連付けられたホストプログラム２１０〜２１４のユーザに対し管理ツール機能を表面化する。さらに、この機構は、ホストにより利用可能にされた一組のインターフェイスを使用して、管理ツール環境を、対応するホストプログラム２１０〜２１４に関連付けられたアプリケーション内に埋め込む。

以下の説明全体を通して、「ｃｍｄｌｅｔ」という用語を使用して、図２〜１３を参照しつつ説明されている管理ツール環境例の中で使用されるコマンドに言及する。そのため、ｃｍｄｌｅｔｓは、従来の管理環境内のコマンドに対応するが、それらの従来のコマンドとは大きく異なる。例えば、ｃｍｄｌｅｔｓは、通常、それに対応するコマンドと比べてサイズが小さいが、それは、ｃｍｄｌｅｔｓでは、構文解析、データ妥当性検証、エラー報告などの管理ツールフレームワークが備える共通機能を使用できるからである。このような共通機能は一度で実施し、一度でテストできるため、管理ツールフレームワーク全体でｃｍｄｌｅｔｓを使用することにより、従来の環境に比べて、アプリケーション固有の機能に関連する漸進的開発およびテストコストをかなり低くすることができる。

さらに、従来の環境とは対照的に、ｃｍｄｌｅｔｓは、スタンドアロンの実行可能プログラムである必要はない。むしろ、ｃｍｄｌｅｔｓは、管理ツールフレームワーク内の同じプロセスで実行できる。これにより、ｃｍｄｌｅｔｓ同士で「ライブ」オブジェクトをやり取りすることができる。「ライブ」オブジェクトをやり取りするこのような機能があるため、ｃｍｄｌｅｔｓはそれらのオブジェクトに対するメソッドを直接呼び出すことができる。そのため、用語「ライブ」オブジェクトは、直接呼び出し可能なメソッドを持つオブジェクトを意味する。それとは対照的に、用語「デッド」オブジェクトは、直接呼び出し可能なメソッドを持たないオブジェクトを意味する。ｃｍｄｌｅｔｓの作成および使用の詳細については、以下でさらに詳しく説明する。

概要を述べると、それぞれのホストプログラム２１０〜２１４は、ユーザが対話形式で管理ツールフレームワーク内の他のコンポーネントを操作するのを管理する。これらの対話操作は、パラメータ、エラー報告などのプトンプトを含むことができる。通常、各ホストプログラム２１０〜２１４は、独自の一組の特定のホストｃｍｄｌｅｔｓ（例えば、ホストｃｍｄｌｅｔｓ２１８）を備えることができる。例えば、ホストプログラムが電子メールプログラムの場合、ホストプログラムは、メールボックスおよびメッセージを対話形式で操作するホストｃｍｄｌｅｔｓを提供することができる。図２がホストプログラム２１０〜２１４を例示しているとしても、当業者であれば、ホストコンポーネント２０２が既存の、または新規に作成されたアプリケーションに関連付けられた他のホストプログラムを含むことができることを理解するであろう。このような他のホストプログラムは、管理ツール環境が備える機能を関連付けられたアプリケーション内にさらに埋め込む。ホストプログラムにより実行される処理は、図７を参照しつつ以下で詳述する。

図２に示されているいくつかの実施例では、ホストプログラムは、コンピューティング装置のハードウェア、ソフトウェア、およびネットワークコンポーネントを管理する管理ツールをユーザが作成し、保存し、開くための単純で、一貫性のある、管理ユーザインターフェイスを備える管理コンソール（つまり、ホストプログラム２１０）とすることができる。これらの機能を実現するために、ホストプログラム２１０は、管理ツールフレームワークの上に管理ＧＵＩを構築するための一組のサービスを提供する。ＧＵＩ対話操作は、さらに、管理ツール環境が備えるスクリプティング機能をユーザに教示するのを手助けするユーザの管理下にあるスクリプトとして公開されることもできる。

他の実施例では、ホストプログラムは、コマンドライン対話型シェル（つまり、ホストプログラム２１２）とすることができる。コマンドライン対話型シェルでは、シェルのメタデータ２１６をコマンドライン上で入力し、コマンドラインの処理に影響を及ぼすようにできる。

さらに他の実施例では、ホストプログラムは、プラットフォーム、プログラミング言語、およびアプリケーション間の分散コンピューティングおよび相互運用性に業界標準仕様を使用するＷｅｂサービス（つまり、ホストプログラム２１４）とすることができる。

これらの実施例に加えて、サードパーティは、そのホストプログラムまたは他のホストプログラムとともに使用される「プロバイダ」インターフェイスおよびプロバイダｃｍｄｌｅｔｓを作成することにより独自のホストコンポーネントを追加することができる。プロバイダインターフェイスは、管理ツールフレームワークによりアプリケーションまたはインフラストラクチャを操作できるようにアプリケーションまたはインフラストラクチャを公開する。プロバイダｃｍｄｌｅｔｓは、ナビゲーション、診断、構成、ライフサイクル、オペレーションなどを自動化する。プロバイダｃｍｄｌｅｔｓは、完全に異種の一組のデータストア上で多形的ｃｍｄｌｅｔ挙動を示す。管理ツール環境は、他のｃｍｄｌｅｔｓクラスと同じ優先度を持つプロバイダｃｍｄｌｅｔｓに作用する。プロバイダｃｍｄｌｅｔは、他のｃｍｄｌｅｔｓと同じ機構を使用して作成される。プロバイダｃｍｄｌｅｔｓは、アプリケーションまたはインフラストラクチャの特定の機能を管理ツールフレームワークに公開する。そのため、ｃｍｄｌｅｔｓを使用すると、製品開発者はその製品が多くの管理ツールで動作できる１つのホストコンポーネントを作成するだけでよい。例えば、管理ツール環境例では、システムレベルのグラフィカルユーザインターフェイスのヘルプメニューを既存のアプリケーションに統合し、移植することができる。

（プラットフォーム固有コンポーネント）
プラットフォーム固有コンポーネント２０４は、コンピューティングシステム（例えば、図１のコンピューティング装置１００）が使用するサービスの集合体を含み、フレームワークが稼働しているプラットフォームの詳細から管理ツールフレームワークを分離する。そのため、プラットフォームの種類毎に一組のプラットフォーム固有コンポーネントがある。プラットフォーム固有コンポーネントを使用すると、ユーザは、異なるオペレーティングシステム上で同じ管理ツールを使用することができる。

図３を簡単に参照すると、プラットフォーム固有コンポーネント２０４は、メタデータ／状況依存入力コンポーネント３０２、ヘルプコンポーネント３０４、構成／登録コンポーネント３０６、ｃｍｄｌｅｔセットアップコンポーネント３０８、および出力インターフェイスコンポーネント３０９を含むことができる。コンポーネント３０２〜３０８は、データベースストア３１４に関連付けられたデータベースストアマネージャ３１２と通信する。パーザ２２０およびスクリプトエンジン２２２は、メタデータ／状況依存入力コンポーネント３０２と通信する。コアエンジン２２４は、ヘルプｃｍｄｌｅｔコンポーネント３０４、構成／登録コンポーネント３０６、ｃｍｄｌｅｔセットアップコンポーネント３０８、および出力インターフェイスコンポーネント３０９と通信する。出力インターフェイスコンポーネント３０９は、ホストによって出力ｃｍｄｌｅｔｓに提供されるインターフェイスを含む。出力されるｃｍｄｌｅｔｓは、その後、ホストの出力オブジェクトを呼び出してレンダリングを実行することができる。プラットフォーム固有コンポーネント２０４は、さらに、ログ記録／監査コンポーネント３１０も備えることができ、コアエンジン２２４は、これらを使用して、ログ記録および監査機能を備えるホスト固有（つまり、プラットフォーム固有）サービスと通信する。

一管理ツールフレームワーク例では、メタデータ／状況依存入力コンポーネント３０２が、コマンド、パラメータ、およびパラメータ値の自動補完を行う。ヘルプｃｍｄｌｅｔコンポーネント３０４は、ホストユーザインターフェイスに基づくカスタマイズされたヘルプシステムを備える。

（ハンドラコンポーネント）
再び図２を参照すると、ハンドラコンポーネント２０８は、レガシーユーティリティ２３０、管理ｃｍｄｌｅｔｓ２３２、非管理ｃｍｄｌｅｔｓ２３４、リモーティングｃｍｄｌｅｔｓ（ｒｅｍｏｔｉｎｇ ｃｍｄｌｅｔｓ）２３６、およびＷｅｂサービスインターフェイス２３８を備える。それぞれについて、以下で詳述する。管理ｃｍｄｌｅｔｓ２３２（プラットフォームｃｍｄｌｅｔｓともいう）は、コンピューティング装置に関連付けられた構成情報を問い合わせ、または操作するｃｍｄｌｅｔｓを含む。管理ｃｍｄｌｅｔｓ２３２は、システム型情報を操作するので、これらは、特定のプラットフォームに依存する。しかし、それぞれのプラットフォームは、通常、他のプラットフォーム上で管理ｃｍｄｌｅｔｓ２３２と似たアクションを実行する管理ｃｍｄｌｅｔｓ２３２を備える。例えば、それぞれのプラットフォームは、システム管理属性の取得および設定を行う管理ｃｍｄｌｅｔｓ２３２をサポートする（例えば、ｇｅｔ／ｐｒｏｃｅｓｓ、ｓｅｔ／ＩＰＡｄｄｒｅｓｓ）。ホスト独立コンポーネント２０６は、公開ＡＰＩを介して管理ｃｍｄｌｅｔｓと通信する。

非管理ｃｍｄｌｅｔｓ２３４（ベースｃｍｄｌｅｔｓと呼ばれることもある）は、管理ｃｍｄｌｅｔｓ２３２およびその他のｃｍｄｌｅｔｓにより提供されるオブジェクトに対する処理のグループ分け、並べ替え、フィルタ処理、および実行の他の操作を行うｃｍｄｌｅｔｓを含む。本発明の比較手法によれば、非管理ｃｍｄｌｅｔｓ２３４は、「ｃｏｍｐａｒｅ−ｏｂｊｅｃｔ」ｃｍｄｌｅｔを含むが、これについては、図１４〜２３を参照しつつ詳しく説明する。非管理ｃｍｄｌｅｔｓ２３４は、各プラットフォーム上で同じでよく、公開ＡＰＩを介してホスト独立コンポーネント２０６とやり取りする一組のユーティリティを備える。非管理ｃｍｄｌｅｔｓ２３４とホスト独立コンポーネント２０６との間のやり取りにより、オブジェクトへのリフレクションが可能になり、またその（オブジェクト）の型と無関係にリフレクションされたオブジェクトでの処理が可能になる。そのため、これらのユーティリティを使用することにより、開発者は、非管理ｃｍｄｌｅｔｓを１回書いて、その後、コンピューティングシステム上でサポートされているオブジェクトのすべてのクラスにわたってそれらの非管理ｃｍｄｌｅｔｓを適用することができる。以前には、開発者は、処理されなければならないデータの形式をまず把握してから、そのデータのみを処理するアプリケーションを書く必要があった。その結果、従来のアプリケーションでは、非常に限られた範囲のデータしか処理できなかった。以下では、図１３を参照しつつ、そのオブジェクトの型とは独立にオブジェクトを処理する機構の一例を説明する。

レガシーユーティリティ２３０は、ｗｉｎ３２コマンドライン実行ファイルなどの既存の実行ファイルを含む。それぞれのレガシーユーティリティ２３０は、オブジェクトフレームワーク内のある種のオブジェクトである、テキストストリーム（例えば、ｓｔｄｉｎ、ｓｔｄｏｕｔ、およびｓｔｄｅｒｒ）を使用して管理ツールフレームワークと通信する。レガシーユーティリティ２３０ではテキストストリームを使用するので、管理ツールフレームワークが備えるリフレクションベースのオペレーションは利用できない。レガシーユーティリティ２３０は、管理ツールフレームワークと異なるプロセスで実行される。図に示されていないが、他のｃｍｄｌｅｔｓもプロセスから離れて動作可能である。

リモーティングｃｍｄｌｅｔｓ２３６は、Ｗｅｂサービスインターフェイス２３８と組み合わせて、インターネットまたはイントラネット（例えば、図２に示されているインターネット／イントラネット２４０）などの通信媒体を介して他のコンピューティング装置上で対話型およびプログラム管理ツール環境にアクセスするためのリモーティング機構を実現する。管理ツールフレームワークの一例では、リモーティング機構は、複数の独立の制御領域にまたがるインフラストラクチャに依存する連合サービスをサポートする。リモーティング機構により、リモートコンピューティング装置上でスクリプトを実行できる。スクリプトは、単一の、または複数のリモートシステム上で実行することができる。スクリプトの実行結果は、個々のスクリプトが完了する毎に処理するか、またはさまざまなコンピューティング装置上のスクリプトすべてが完了してからそれらの結果を集計し、一括して処理することができる。

例えば、ホストコンポーネント２０２の１つとして示されているＷｅｂサービス２１４は、リモートエージェントであってよい。他の実施形態では、Ｗｅｂサービス２１４は、通信媒体２４０を通じてエンジンと通信する別のコンポーネント（図に示されていない）とすることもできる。いずれの構成であっても、Ｗｅｂサービス２１４は、その後、ｃｍｄｌｅｔｓを制御するため他のホストコンポーネントと通信するように構成されたエンジンと通信する。リモートエージェントは、リモートコマンド要求をターゲットシステム上のパーザおよび管理ツールフレームワークにサブミットする動作を処理する。リモーティングｃｍｄｌｅｔｓは、リモートエージェントにアクセスできるようにするリモートクライアントとして使用される。リモートエージェントおよびリモーティングｃｍｄｌｅｔｓは、解析されたストリームを介して通信する。この解析されたストリームは、プロトコル層で保護されるか、または追加ｃｍｄｌｅｔｓを使用して解析されたストリームの暗号化および解読を行うようにできる。

（ホスト独立コンポーネント）
ホスト独立コンポーネント２０６は、パーザ２２０、スクリプトエンジン２２２、およびコアエンジン２２４を備える。ホスト独立コンポーネント２０６は、複数のｃｍｄｌｅｔｓをグループ分けする機構およびサービスを提供し、ｃｍｄｌｅｔｓのオペレーションを調整し、他の資源、セッション、およびジョブとｃｍｄｌｅｔｓとのやり取りを調整する。

（パーザの例）
パーザ２２０は、さまざまなホストプログラムから入力要求を受け取り、それらの入力要求をコアエンジン２２４などの中の管理ツールフレームワーク全体を通して使用される一様なｃｍｄｌｅｔｓオブジェクトにマッピングする機構を備える。さらに、パーザ２２０は、受け取った入力に基づいてデータ処理を実行できる。パーザ２２０は、同じ機能に関して異なる言語または構文をユーザに簡単に公開する機能を備える。例えば、パーザ２２０は、入力要求を解釈する役割を担っているので、予想される入力構文に影響を及ぼすパーザ２２０内のコードに変更を加えると、管理ツールフレームワークの各ユーザに本質的な影響が及ぶ。したがって、システム管理者は、異なる構文をサポートする異なるコンピューティング装置上の異なるパーザを用意することができる。しかし、同じパーザを操作する各ユーザは、ｃｍｄｌｅｔ毎に首尾一貫した構文を使用することになる。それとは対照的に、従来の環境では、それぞれのコマンドでその環境独自の構文を実装していた。そのため、数千ものコマンドがある場合には、それぞれの環境で数種類の構文をサポートし、それらの多くは互いに整合していなかった。

（スクリプトエンジンの例）
スクリプトエンジン２２２は、スクリプトを使用して複数のｃｍｄｌｅｔｓを１つに結び合わせる機構およびサービスを提供する。スクリプトは、継承の厳密な規則に従ってセッション状態を共有するコマンドラインの集合体である。スクリプト内の複数のコマンドラインは、入力要求において与えられた構文に応じて、同期または非同期で実行できる。スクリプトエンジン２２２は、ループおよび条件節などの制御構造を処理し、スクリプト内の変数を処理する機能を有する。スクリプトエンジンは、さらに、セッション状態を管理し、ポリシー（図に示されていない）に基づきセッションデータへのアクセス権をｃｍｄｌｅｔｓに与える。

（コアエンジンの例）
コアエンジン２２４は、パーザ２２０により識別されたｃｍｄｌｅｔｓを処理する役割を担う。図４を簡単に参照すると、管理ツールフレームワーク２００内のコアエンジン２２４の例が示されている。コアエンジン２２４の例は、パイプラインプロセッサ４０２、ローダ４０４、メタデータプロセッサ４０６、エラー＆イベントハンドラ４０８、セッションマネージャ４１０、および拡張型マネージャ４１２を備える。

（メタデータプロセッサの例）
メタデータプロセッサ４０６は、図３に示されているデータベースストア３１４などのメタデータストア内のメタデータにアクセスおよび格納を行うように構成されている。メタデータは、ｃｍｄｌｅｔクラス定義の範囲で、コマンドラインを介して、および類似の方法で供給することができる。管理ツールフレームワーク２００内の異なるコンポーネントは、処理を実行するときにメタデータを要求することができる。例えば、パーザ２０２は、コマンドラインにおいて供給されるパラメータの妥当性を検証するためメタデータを要求することができる。

（エラー＆イベントプロセッサの例）
エラー＆イベントプロセッサ４０８は、コマンドラインの処理中にエラーが発生する毎に、エラーに関する情報を格納するエラーオブジェクトを提供する。

（セッションマネージャの例）
セッションマネージャ４１０は、セッションおよび状態情報を管理ツールフレームワーク２００内の他のコンポーネントに供給する。セッションマネージャにより管理される状態情報は、ｃｍｄｌｅｔ、ホスト、またはコアエンジンにより、プログラミングインターフェイスを介してアクセスすることができる。これらのプログラミングインターフェイスでは、セキュリティポリシー制約条件が適用される状態情報の作成、修正、および削除を考慮している。

（パイプラインプロセッサおよびローダの例）
ローダ４０４は、メモリ内に各ｃｍｄｌｅｔをロードし、パイプラインプロセッサ４０２がｃｍｄｌｅｔを実行できるように構成される。パイプラインプロセッサ４０２は、ｃｍｄｌｅｔプロセッサ４２０およびｃｍｄｌｅｔマネージャ４２２を備える。ｃｍｄｌｅｔプロセッサ４２０は、個々のｃｍｄｌｅｔｓをディスパッチする。ｃｍｄｌｅｔが１つのリモートマシンまたはリモートマシン群上での実行を必要とする場合、ｃｍｄｌｅｔプロセッサ４２０は、図２に示されているリモーティングｃｍｄｌｅｔ２３６と実行の調整を行う。ｃｍｄｌｅｔマネージャ４２２は、ｃｍｄｌｅｔｓの集合体の実行を処理する。ｃｍｄｌｅｔマネージャ４２２、ｃｍｄｌｅｔプロセッサ４２０、およびスクリプトエンジン２２２（図２）は互いに通信し合い、ホストプログラム２１０〜２１４から受け取った入力について処理を実行する。通信は、その性質上、再帰的であってよい。例えば、ホストプログラムがスクリプトを備えている場合、スクリプトは、ｃｍｄｌｅｔマネージャ４２２を呼び出して、それ自体がスクリプトであってもよいｃｍｄｌｅｔを実行することができる。その後、スクリプトは、スクリプトエンジン２２２により実行することができる。コアエンジンに対する１つのプロセスの流れの例について、図１４を参照しつつ以下で詳述する。

（拡張型マネージャの例）
上述のように、管理ツールフレームワークは、複数のオブジェクトに対してリフレクションを実行でき、またその（オブジェクト）の型とは無関係にリフレクションされたオブジェクトに対し処理を実行できる一組のユーティリティを備えている。管理ツールフレームワーク２００は、コンピューティングシステム上のコンポーネントフレームワーク（図１のコンポーネントフレームワーク１２０）と対話し、このリフレクションを実行する。当業者であれば、リフレクションはオブジェクトにクエリを行ってそのオブジェクトの型を取得し、その後、オブジェクトのその型に関連付けられているさまざまなオブジェクトおよびプロパティに対しリフレクションを実行して他のオブジェクトをおよび／または所望の値を取得する機能を備えていることが理解されよう。

リフレクションにより管理ツールフレームワーク２００がオブジェクトに関するかなりの量の情報を得られるとしても、リフレクションはオブジェクトの型に注目する。例えば、データベースのデータテーブルがリフレクションされる場合、返される情報は、そのデータテーブルが列プロパティと行プロパティとの２つのプロパティを持つということである。これら２つのプロパティでは、そのデータテーブル内の「オブジェクト」に関する十分な詳細が得られない。拡張マークアップ言語（ＸＭＬ）および他のオブジェクト上でリフレクションが使用される場合にも同様の問題が生じる。

そのため、オブジェクトの型に注目する代わりに、拡張型マネージャ４１２では、型の使用に注目し、そのオブジェクトを必要な情報の取得に使用できるか否かを判別する。上記のデータテーブル例を続けると、データテーブルが列プロパティと行プロパティとを持つという事実は、特に関心を引くものではない。むしろ、関心を引くのは、１つの列が注目している情報を含むという点である。したがって、使用法に注目すると、拡張型マネージャ４１２は、各行を「オブジェクト」に関連付け、各列をその「オブジェクト」の「プロパティ」に関連付ける。そのため、拡張型マネージャ４１２は、任意の型の正確に解析可能な入力から「オブジェクト」を作成する機構を備える。そうする際に、拡張型マネージャ４１２は、コンポーネントベースのフレームワーク１２０が備えるリフレクション機能を補完し、「リフレクション」を任意の型の正確に解析可能な入力に拡張する。

大まかに言うと、拡張型マネージャは、正確に解析可能な入力（図に示されていない）にアクセスし、正確に解析可能な入力を要求されたデータ型と関連付けるように構成される。その後、拡張型マネージャ４１２は、要求された情報をパイプラインプロセッサ４０２またはパーザ２２０などの要求側コンポーネントに提供する。以下の説明では、正確に解析可能な入力は、プロパティおよび値を識別できる入力として定義される。いくつかの正確に解析可能な入力の例としては、Ｗｉｎｄｏｗｓ（登録商標）Ｍａｎａｇｅｍｅｎｔ Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ（ＷＭＩ）入力、ＡｃｔｉｖｅＸ Ｄａｔａ Ｏｂｊｅｃｔｓ（ＡＤＯ）入力、拡張マークアップ言語（ＸＭＬ）入力、および．ＮＥＴオブジェクトなどのオブジェクト入力がある。他の正確に解析可能な入力としては、サードパーティのデータ形式が考えられる。

図１３を簡単に参照すると、管理ツールフレームワーク内で使用するための拡張型マネージャ例のブロック図が示されている。説明のため、拡張型マネージャにより提供される機能（３）は、従来の密結合システム（１）により提供される機能およびリフレクションシステム（２）により提供される機能と対比されている。従来の密結合システムでは、アプリケーション内の呼び出し側１３０２は、直接、オブジェクトＡ内の情報（例えば、プロパティＡおよびＢ、メソッドＭ１およびＭ２）に直接アクセスする。上述のように、呼び出し側１３０２は、先験的に、コンパイル時にオブジェクトＡにより提供されるプロパティ（例えば、プロパティＡおよびＢ）およびメソッド（例えば、メソッドＭ１およびＭ２）を知っていなければならない。リフレクションシステムでは、ジェネリックコード１３２０（データ型に依存しない）は、要求されたオブジェクトに対しリフレクション１３１０を実行し、オブジェクト（例えば、オブジェクトＡ）に関する情報（例えば、プロパティＡおよびＢ、メソッドＭ１およびＭ２）をジェネリックコード１３２０に返すシステム１３０８に対しクエリを行う。オブジェクトＡでは示されていないが、返される情報は、ベンダ、ファイル、日付などの補足情報を含むことができる。そのため、ジェネリックコード１３２０は、リフレクションを通じて、密結合システムが提供するのと少なくとも同じ情報を取得する。リフレクションシステムでは、さらに、呼び出し側１３０２は、システムにクエリを行い、パラメータを先験的に知ることなく補足情報を取得することができる。

密結合システムもリフレクションシステムも、新しいデータ型を動作環境内に簡単に組み込むことはできない。例えば、密結合システムでは、動作環境は、実現された後、新しいデータ型をサポートするため構築し直さなければならないため、新しいデータ型を組み込むことができない。同様に、リフレクションシステムでは、それぞれのオブジェクトクラスのメタデータは固定されている。そのため、新しいデータ型を組み込むことは、通常は行われない。

しかし、本発明の拡張型マネージャを使用すると、新しいデータ型をオペレーティングシステムに組み込むことができる。拡張型マネージャ１３２２を使用すると、ジェネリックコード１３２０は、要求されたオブジェクトに対するリフレクションを実行し、サードパーティオブジェクト（例えば、オブジェクトＡ’およびＢ）、意味論的Ｗｅｂ（ｓｅｍａｎｔｉｃ ｗｅｂ）１３３２、オントロジーサービス（ｏｎｔｏｌｏｇｙ ｓｅｒｖｉｃｅ）１３３４などのさまざまな外部ソースにより提供される拡張データ型（例えば、オブジェクトＡ’）を取得することができる。図に示されているように、サードパーティオブジェクトは、既存のオブジェクト（例えば、オブジェクトＡ’）を拡張するか、またはまったく新しいオブジェクト（例えば、オブジェクトＢ）を作成できる。

これらの外部ソースは、それぞれ型メタデータ１３４０内に一意的構造を登録し、コード１３４２を供給することができる。オブジェクトが照会されると、拡張型マネージャは、型メタデータ１３４０を再検討し、オブジェクトが登録されているか否かを判別する。オブジェクトが型メタデータ１３４０内に登録されていない場合、リフレクションが実行される。そうでない場合、拡張リフレクションが実行される。コード１３４２は、リフレクションを実行される型に関連付けられた追加プロパティおよびメソッドを返す。例えば、入力型がＸＭＬの場合、コード１３４２は、ＸＭＬドキュメントからオブジェクトを作成するためにＸＭＬを用いる方法を記述する記述ファイルを含むことができる。そのため、型メタデータ１３４０は、拡張型マネージャ４１２がさまざまな型の正確に解析可能な入力（例えば、サードパーティオブジェクトＡ’およびＢ、意味論的Ｗｅｂ１３３２）に対しクエリを行って、その特定の入力型に対するオブジェクトを作成する所望のプロパティを取得する方法を記述し、コード１３４２は、それらの所望のプロパティを取得する命令を与える。その結果、拡張型マネージャ４１２は、あらゆる型のオブジェクトに対し「リフレクション」を実行できる間接層（ｌａｙｅｒ ｏｆ ｉｎｄｉｒｅｃｔｉｏｎ）を提供する。

拡張型マネージャ４１２は、拡張型を備えるほかに、プロパティパス機構、キー機構、比較機構、変換機構、グロバー機構（ｇｌｏｂｂｅｒ ｍｅｃｈａｎｉｓｍ）、プロパティセット機構、関係機構などの追加クエリ機構も備える。下記の「拡張型マネージャ処理例」の節で説明されているこれらのクエリ機構を使用することで、システム管理者は、コマンド文字列を入力するときに自由に作業できる。さまざまな手法を使用して、拡張型マネージャの意味論を実装することができる。以下では３つの手法について説明する。当業者であれば、請求されている発明の範囲から逸脱せずにこれらの手法の変更形態を使用できることを理解するであろう。

一手法では、静的メソッド（例えば、ｇｅｔｐｒｏｐｅｒｔｙ（））を持つ一連のクラスを提供することができる。オブジェクトが静的メソッドに入力され（例えば、ｇｅｔｐｒｏｐｅｒｔｙ（ｏｂｊｅｃｔ））、静的メソッドは一組の結果を返す。他の手法では、この動作環境はオブジェクトをアダプタで包む。そのため、入力は供給されない。アダプタのそれぞれのインスタンスは、包まれているオブジェクトに作用するｇｅｔｐｒｏｐｅｒｔｙメソッドを持ち、包まれているオブジェクトに対するプロパティを返す。この手法を例示する擬似コードを以下に示す。

さらに他の手法では、アダプタクラスがオブジェクトをサブクラス化する。従来、サブクラス化は、コンパイル前に実行されていた。しかし、いくつかの動作環境では、サブクラス化は動的に実行することができる。これらの型の環境について、この手法を例示する擬似コードを以下に示す。

そのため、図１３に例示されているように、拡張型マネージャは、開発者が新しいデータ型を作成し、データ型を登録し、他のアプリケーションおよびｃｍｄｌｅｔがその新しいデータ型を使用できるようにする。それとは対照的に、以前の管理環境では、それぞれのデータ型からインスタンス化されるオブジェクトに関連付けられたプロパティまたはメソッドに直接アクセスできるように、コンパイル時にそれぞれのデータ型が知られていなければならなかった。したがって、管理環境によりサポートされる新しいデータ型の追加は、以前には滅多に実行されることはなかった。

図２を再び参照すると、概略として、管理ツールフレームワーク２００は、ユーザによって入力されたコマンドの実行を調整するためシェルに依存せず、むしろ、機能を処理部分（例えば、ホスト独立コンポーネント２０６）とユーザ対話操作部分（例えば、ホストｃｍｄｌｅｔｓを介して）とに分割する。さらに、管理ツール環境では、構文解析およびデータ妥当性検証に必要なコードはもはやそれぞれのコマンドに含まれず、むしろ、管理ツールフレームワーク内のコンポーネント（例えば、パーザ２２０）により提供されるため、管理ツールのプログラミングが大幅に簡素化される。管理ツールフレームワーク内で実行される処理の例について以下で説明する。

（オペレーションの例）
図５〜６は、管理ツール環境内で使用されるデータ構造例を示す。図７〜１２は、管理ツール環境内の処理の流れの例を示す。当業者であれば、本発明の範囲を逸脱することなく特定の処理を後述のコンポーネントと異なるコンポーネントにより実行できることを理解するであろう。管理ツールフレームワークのコンポーネント内で実行される処理について説明する前に、管理ツールフレームワーク内で使用されるデータ構造例について説明する。

（ｃｍｄｌｅｔオブジェクトのデータ構造例）
図５に、図２に示されている管理ツールフレームワーク内で使用するのに好適なｃｍｄｌｅｔを指定するための一データ構造例を示す。完了している場合、ｃｍｄｌｅｔは、管理ｃｍｄｌｅｔ、非管理ｃｍｄｌｅｔ、ホストｃｍｄｌｅｔ、プロバイダｃｍｄｌｅｔなどであってよい。以下では、ソフトウェア開発者の視点からｃｍｄｌｅｔを作成することについて説明する（つまり、プロバイダｃｍｄｌｅｔ）。しかし、それぞれの型のｃｍｄｌｅｔは、同じ方法で作成され、似た動作をする。ｃｍｄｌｅｔは、Ｃ＃などどのような言語でも書くことができる。さらに、ｃｍｄｌｅｔは、スクリプト言語などを使用して書くこともできる。管理ツール環境が．ＮＥＴ Ｆｒａｍｅｗｏｒｋで動作する場合、ｃｍｄｌｅｔは．ＮＥＴオブジェクトとすることができる。

プロバイダｃｍｄｌｅｔ５００（これ以降、ｃｍｄｌｅｔ５００と呼ぶ）は、ｃｍｄｌｅｔクラス名（例えば、ＳｔｏｐＰｒｏｃｅｓｓ５０４）を持つパブリッククラスである。ｃｍｄｌｅｔ５００は、ｃｍｄｌｅｔクラス５０６から派生する。ｃｍｄｌｅｔクラス５０４のデータ構造例は、図６を参照しつつ以下で説明する。それぞれのｃｍｄｌｅｔ５００は、名前（例えば、Ｓｔｏｐ／Ｐｒｏｃｅｓｓ）をｃｍｄｌｅｔ５００に関連付けるコマンド属性５０２に関連付けられる。この名前は、管理ツール環境内に登録される。後述のように、その名前（例えば、Ｓｔｏｐ／Ｐｒｏｃｅｓｓ）を持つコマンド文字列がコマンドライン上の入力として、またはスクリプトで与えられる場合、パーザは、ｃｍｄｌｅｔレジストリ内を探しｃｍｄｌｅｔ５００を識別する。

ｃｍｄｌｅｔ５００は、ｃｍｄｌｅｔへの予想される入力パラメータの文法を定義する文法機構に関連付けられる。文法機構は、ｃｍｄｌｅｔに直接的にまたは間接的に関連付けられるようにできる。例えば、ｃｍｄｌｅｔ５００は、直接的文法関連付けを例示している。このｃｍｄｌｅｔ５００では、１つまたは複数のパブリックパラメータ（例えば、ＰｒｏｃｅｓｓＮａｍｅ５１０およびＰＩＤ５１２）が宣言される。パブリックパラメータの宣言は、ｃｍｄｌｅｔ５００への入力オブジェクトの構文解析を駆動する。それとは別に、パラメータの記述は、ＸＭＬドキュメントなどの外部ソース内にあってもよい。その後、この外部ソース内のパラメータの記述は、ｃｍｄｌｅｔへの入力オブジェクトの構文解析を駆動する。

それぞれのパブリックパラメータ５１０、５１２は、それに関連付けられた１つまたは複数の属性（つまり、ディレクティブ）を持つことができる。それらのディレクティブは、構文解析ディレクティブ５２０、データ妥当性検証ディレクティブ５２１、データ生成ディレクティブ５２２、処理ディレクティブ５２３、符号化ディレクティブ５２４、およびドキュメンテーションディレクティブ５２５のカテゴリのうちのいずれかとすることができる。これらのディレクティブは、角括弧で囲むことができる。それぞれのディレクティブは、以下の予想される入力パラメータ上で実行されオペレーションを記述する。これらのディレクティブには、ユーザ対話操作型ディレクティブなどのクラスレベルで適用できるものもある。これらのディレクティブは、ｃｍｄｌｅｔに関連付けられたメタデータ内に格納される。

これらの属性は、さらに、ｃｍｄｌｅｔ内で宣言されたパラメータの母集団に影響を及ぼすことがある。これらのパラメータの母集団に対する一プロセスについて、図１１を参照しつつ以下で説明する。コアエンジンは、適合性を保証するためにこれらのディレクティブを適用することができる。ｃｍｄｌｅｔ５００は、第１のメソッド５３０（これ以降、代わりにＢｅｇｉｎＰｒｏｃｅｓｓｉｎｇメソッド５３０と呼ぶ）および第２のメソッド５４０（これ以降、ＰｒｏｃｅｓｓＲｅｃｏｒｄメソッド５４０と呼ぶ）を含む。コアエンジンは、第１および第２のメソッド５３０、５４０を使用して、ｃｍｄｌｅｔ５００の処理を指令する。例えば、第１のメソッド５３０は、１回実行され、セットアップ機能を実行する。第２のメソッド５４０内のコード５４２は、ｃｍｄｌｅｔ５００によって処理される必要のあるオブジェクト（例えば、レコード）毎に実行される。ｃｍｄｌｅｔ５００は、さらに、ｃｍｄｌｅｔ５００の後にクリーンアップする第３のメソッド（図に示されていない）を含むこともできる。

そのため、図５に示すように、第２のメソッド５４０内のコード５４２は、通常は、かなり簡潔であり、構文解析コード、データ妥当性検証コードなどの従来の管理ツール環境で必要とされる機能を含まない。そのため、システム管理者は、複雑なプログラミング言語学習せずとも複雑な管理タスクを開発することができる。

図６は、ｃｍｄｌｅｔを指定するための例示的なデータ構造６００である。概略として、データ構造６００は、管理ツールフレームワークとｃｍｄｌｅｔとの間のコントラクトを明確に表すための手段を提供する。データ構造６００は、ｃｍｄｌｅｔクラス６０４から派生するパブリッククラスである。ソフトウェア開発者側では、「ｇｅｔ／ｐｒｏｃｅｓｓ」および「ｆｏｒｍａｔ／ｔａｂｌｅ」などの名詞／動詞ペアをｃｍｄｌｅｔ６００に関連付けるｃｍｄｌｅｔＤｅｃｌａｒａｔｉｏｎ６０２を指定する。この名詞／動詞ペアは、管理ツール環境内に登録される。動詞または名詞は、ｃｍｄｌｅｔ内で暗黙的であってよい。また、データ構造５００と同様に、データ構造６００は、１つまたは複数のパブリックメンバ（例えば、Ｎａｍｅ６３０、Ｒｅｃｕｒｓｅ６３２）を含み、これは、データ構造５００に関して説明されている１つまたは複数のディレクティブ５２０〜５２５に関連付けることができる。

しかし、このデータ構造６００の例では、予想される入力パラメータ６３０および６３２はそれぞれ、入力属性６３１および６３３に関連付けられる。入力属性６３１および６３３では、それぞれのパラメータ６３０および６３２に対するデータをコマンドラインから取得するように指定する。そのため、このデータ構造６００の例では、他のｃｍｄｌｅｔによって吐き出されたパイプライン化されたオブジェクトから設定（ｐｏｐｕｌａｔｅ）される予想される入力パラメータはない。そこで、データ構造６００は、ｃｍｄｌｅｔ基本クラスによって与えられる第１のメソッド（例えば、ＢｅｇｉｎＰｒｏｃｅｓｓｉｎｇ）または第２のメソッド（例えば、ＰｒｏｃｅｓｓＲｅｃｏｒｄ）をオーバーライドしない。

データ構造６００は、入力パラメータとして認識されない他のメンバ６４０も含むことができる。他のメンバ６４０は、ディレクティブの１つに基づいて生成されるデータを格納するために使用することができ、またプライベートでもパブリックでもよい。

したがって、データ構造６００に例示されているように、特定のｃｍｄｌｅｔクラス内でパブリックのプロパティおよびディレクティブを宣言することを利用して、ｃｍｄｌｅｔ開発者は、ｃｍｄｌｅｔｓへの予想される入力パラメータの文法を容易に指定することができ、かつｃｍｄｌｅｔ開発者側で基本ロジックを生成しなくても予想される入力パラメータに対し実行しなければならない処理を指定することができる。データ構造６００は、ｃｍｄｌｅｔと文法機構との間の直接的関連付けを例示している。上述のように、この関連付けは、ＸＭＬドキュメントなどの外部ソース内の予想されるパラメータ定義を指定するなどして、間接的であってもよい。

次に、管理ツール環境のプロセスの流れの例について説明する。

（ホスト処理の流れの例）
図７は、図２に示されている管理ツールフレームワーク内で実行されるホスト処理のプロセス例を示す論理流れ図である。プロセス７００は、ブロック７０１から始まり、そこでは特定のアプリケーションについて管理ツール環境を起動する要求が届いている。要求は、アプリケーションアイコンを選択するなどのキーボード入力を通じてローカルで、または異なるコンピューティング装置のＷｅｂサービスインターフェイスを通じてリモートで、送信されている可能性がある。いずれのシナリオでも、処理はブロック７０２に続く。

ブロック７０２で、「ターゲット」コンピューティング装置上の特定のアプリケーション（例えば、ホストプログラム）は、その環境をセットアップする。これは、ｃｍｄｌｅｔ（例えば、管理ｃｍｄｌｅｔｓ２３２、非管理ｃｍｄｅｌｅｔｓ２３４、およびホストｃｍｄｌｅｔｓ２１８）のどのサブセットをユーザが利用可能なようにするのかを決定すること含む。通常、ホストプログラムは、すべての非管理ｃｍｄｌｅｔｓ２３４を利用可能にし、そのホストｃｍｄｌｅｔｓ２１８を利用可能にする。さらに、ホストプログラムは、プロセス、ディスクなどを処理するｃｍｄｌｅｔｓなどの管理ｃｍｄｌｅｔｓ２３４のサブセットを利用可能にする。そのため、ホストプログラムがｃｍｄｌｅｔｓのサブセットを利用可能にすると、管理ツールフレームワークは、対応するアプリケーション内に効果的に埋め込まれる。処理は、ブロック７０４に続く。

ブロック７０４で、特定のアプリケーションを通じて入力が取得される。上述のように、入力は、コマンドライン、スクリプト、音声、ＧＵＩなどいくつかの形態を取りうる。例えば、入力がコマンドラインから得られる場合、入力は、キーボード上で入力されたキーストロークから取り出される。ＧＵＩホストについては、そのＧＵＩに関連付けられた入力機構に基づいて文字列が構成される。処理は、ブロック７０６に続く。

ブロック７０６で、その入力は、管理ツールフレームワーク内の他のコンポーネントに送られ、そこで処理される。ホストプログラムは、その入力を直接パーザなどの他のコンポーネントに転送することができる。それとは別に、ホストプログラムは、そのホストｃｍｄｌｅｔｓのうちの１つを介して入力を転送することもできる。ホストｃｍｄｌｅｔは、特定の型の入力（例えば、音声）を管理ツールフレームワークにより認識されるある型の入力（例えば、テキスト文字列、スクリプト）に変換することができる。例えば、音声入力を、その音声入力の内容に応じてスクリプトまたはコマンドライン文字列に変換することができる。それぞれのポストプログラムは、その型の入力を管理ツールフレームワークにより認識される入力に変換する役割を持つので、管理ツールフレームワークは、多数のさまざまなホストコンポーネントから入力を受け付けることができる。さらに、管理ツールフレームワークは、ｃｍｄｌｅｔｓの１つを介して入力が転送されるときにデータ型の間の変換を実行する豊富なユーティリティ群を備える。以下では、他のいくつかの図を参照しつつ、他のコンポーネントにより入力に対して実行される処理について説明する。ホスト処理は、決定ブロック７０８に続く。

決定ブロック７０８で、追加入力の要求が受け取られたか否かの判別が行われる。これは、入力を処理する役割を持つ他のコンポーネントのうちの１つが、その処理を完了するためにユーザからの追加情報を必要とする場合に実行されることがある。例えば、特定のデータにアクセスするためにパスワードが必要であったり、特定のアクションの確認が必要であったりする。いくつかの種類のホストプログラム（例えば、音声メール）では、このような要求は適切でない場合がある。そこで、ユーザが追加情報についてクエリを行う代わりに、ホストプログラムが状態をシリアライズし、状態を一時的に停止し、通知を送信して、後でその状態を再開し、入力の実行を継続できるようにする。他の変更形態では、ホストプログラムは、所定の期間の経過後に既定値を与えることができる。追加入力の要求が届いた場合、処理はブロック７０４にループバックし、そこで、追加入力が得られる。その後、処理は、上述のようにブロック７０６および７０８に続く。追加入力の要求を受け取らず、入力が処理済みの場合、処理はブロック７１０に続く。

ブロック７１０で、管理ツールフレームワーク内の他のコンポーネントから結果を受け取る。それらの結果は、エラーメッセージ、ステータス、進捗状況などを含むことができる。結果は、オブジェクト形態であり、管理ツールフレームワーク内のホストｃｍｄｌｅｔにより認識され、かつ処理される。後述のように、それぞれのホストｃｍｄｌｅｔ用に書かれたコードはまさに最小のコードである。そのため、開発コストに多大な投資を行うことなくさまざまな出力を表示することができる。処理は、ブロック７１２に続く。

ブロック７１２で、結果を表示することができる。ホストｃｍｄｌｅｔは、それらの結果をホストプログラムによってサポートされている表示スタイルに変換する。例えば、返されるオブジェクトは、アイコン、吠える犬などのグラフィック表現を使用してＧＵＩホストプログラムにより表示することができる。ホストｃｍｄｌｅｔは、データの既定の形式および出力を与える。オプションにより結果が表示された後、ホスト処理は完了である。

（入力を処理するためのプロセスの流れの例）
次にコマンド文字列を処理するプロセスの一例について説明する。図８は、図２に示されている管理ツールフレームワーク内のパーザ２２０およびコアエンジン２２４によるコマンド文字列８５０の処理をグラフィックで例示する機能流れ図である。コマンド文字列８５０の例では、複数のコマンド（つまり、ｐｒｏｃｅｓｓコマンド８６０、ｗｈｅｒｅコマンド８６２、ｓｏｒｔコマンド８６４、およびｔａｂｌｅコマンド８６６）をパイプラインで送る。コマンドライン８５０では、入力パラメータをコマンドのどれかに受け渡すことができる（例えば、「ｈａｎｄｌｅｃｏｕｎｔ＞４００」はｗｈｅｒｅコマンド８６２に渡される。）ｐｒｏｃｅｓｓコマンド８６０は、関連付けられた入力パラメータを持たないことに注意されたい。

パーザ２２０は、解析可能なストリーム（例えば、コマンド文字列８５０）を解析して、構成要素８２０〜８２６（例えば、ｗｈｅｒｅ部分８２２）に分ける。それぞれの部分８２０〜８２６は、ｃｍｄｌｅｔｓ８３０〜８３６の１つに関連付けられる。パーザ２２０およびエンジン２２４は、構文解析、パラメータ妥当性検証、データ生成、パラメータ処理、パラメータ符号化、およびパラメータドキュメンテーションなどのさまざまな処理を実行する。パーザ２２０およびエンジン２２４は、コマンドライン上で入力パラメータに対し共通機能を実行するので、管理ツールフレームワーク２００は、一貫したエラーメッセージをユーザに発行することができる。

理解できるであろうが、実行可能なｃｍｄｌｅｔｓ８３０〜８３６では、従来の管理環境のコマンドと比べて必要とするコードは小さい。それぞれの実行可能なｃｍｄｌｅｔ８３０〜８３６は、それぞれの構成要素８２０〜８２６を使用して識別される。さらに、それぞれの実行可能なｃｍｄｌｅｔ８３０〜８３６は、次のパイプライン化されたｃｍｄｌｅｔに入力オブジェクト（矢印８４１、８４３、および８４５により表される）として入力されるオブジェクト（矢印８４０、８４２、８４４、および８４６により表される）を出力する。これらのオブジェクトは、オブジェクトに参照（例えば、ハンドル）を受け渡すことにより入力することができる。その後、実行可能なｃｍｄｌｅｔｓ８３０〜８３６は、中に渡されたオブジェクト上で追加処理を実行することができる。

図９は、コマンド文字列の処理をさらに詳しく例示する論理流れ図である。コマンド文字列処理は、ブロック９０１から始まるが、そこではパーザまたはスクリプトエンジンが入力内のコマンド文字列を識別している。一般に、コアエンジンは、ｃｍｄｌｅｔｓのデータの流れのセットアップおよび順序付けを実行する。１つのｃｍｄｌｅｔのセットアップおよび順序付けについて以下で説明するが、これは、パイプライン内のそれぞれのｃｍｄｌｅｔに適用可能である。処理は、ブロック９０４に続く。

ブロック９０４で、ｃｍｄｌｅｔが識別される。ｃｍｄｌｅｔの識別は、登録を使用することもできる。コアエンジンでは、ｃｍｄｌｅｔがローカルであるか、リモートであるかを判別する。ｃｍｄｌｅｔは、１）管理ツールフレームワークのアプリケーション領域内で、２）管理ツールフレームワークと同じプロセスの他のアプリケーション領域内で、３）同じコンピューティング装置上の他のプロセス内で、または４）リモートコンピューティング装置内で実行する。同じプロセス内で動作するｃｍｄｅｌｅｔｓ同士の間の通信は、オブジェクト経由で行われる。異なるプロセス内で動作するｃｍｄｌｅｔｓ間の通信は、シリアライズされた構造化データ形式を経由する。シリアライズされた構造化データ形式の一例は、拡張マークアップ言語（ＸＭＬ）に基づく。処理は、ブロック９０６に続く。

ブロック９０６で、ｃｍｄｌｅｔオブジェクトのインスタンスが作成される。ｃｍｄｌｅｔのインスタンスを作成するプロセス例は、図１０を参照しつつ以下で説明する。ｃｍｄｌｅｔオブジェクトが作成されると、処理はブロック９０８に続く。

ブロック９０８で、ｃｍｄｌｅｔオブジェクトに関連付けられているプロパティが設定（ｐｏｐｕｌａｔｅ）される。上述のように、開発者は、ｃｍｄｌｅｔクラス内、または外部ソース内でプロパティを宣言する。簡単に言うと、管理ツールフレームワークは、そのプロパティについて宣言されている名前および型に基づきｃｍｄｌｅｔクラスからインスタンス化されたｃｍｄｌｅｔに対する（複数の）送られて来るオブジェクトを解読するということである。それらの型が異なる場合、その型が拡張データ型マネージャを介して課せられるようにできる。前述のように、パイプライン化されたコマンド文字列内のそれぞれのｃｍｄｌｅｔの出力は、オブジェクトへのハンドルのリストであってよい。次のｃｍｄｌｅｔは、このオブジェクトハンドルのリストを入力し、処理を実行し、他のオブジェクトハンドルのリストを次のｃｍｄｌｅｔに受け渡すことができる。さらに、図６に例示されているように、入力パラメータをコマンドラインから送られて来るものとして指定することもできる。ｃｍｄｌｅｔに関連付けられているプロパティの設定の方法の一例について、図１１を参照しつつ以下で説明する。ｃｍｄｌｅｔの設定が行われた後、処理はブロック９１０に続く。

ブロック９１０で、ｃｍｄｌｅｔが実行される。概略として、ｃｍｄｌｅｔにより行われる処理は、少なくとも１回実行され、これは、ｃｍｄｌｅｔへの各入力オブジェクトの処理を含む。そこで、ｃｍｄｌｅｔがパイプライン化されたコマンド文字列内の第１のｃｍｄｌｅｔである場合、処理は１回実行される。後続のｃｍｄｌｅｔｓについては、処理は、ｃｍｄｌｅｔに渡されるオブジェクト毎に実行される。ｃｍｄｌｅｔｓを実行する一方法について、図５を参照しつつ以下で説明する。入力パラメータがコマンドラインからしか来ない場合、ｃｍｄｌｅｔの実行では基本のｃｍｄｌｅｔの場合に用意される既定の方法を使用する。ｃｍｄｌｅｔの実行が終了すると、処理はブロック９１２に続く。

ブロック９１２で、ｃｍｄｌｅｔがクリーンアップされる。これは、割り当てられたメモリの解放などを受け持つ、関連付けられているｃｍｄｌｅｔオブジェクトのデストラクタを呼び出すことを含む。そこでコマンド文字列の処理は完了する。

（ｃｍｄｌｅｔオブジェクトを作成するプロセスの例）
図１０は、図９に示されているコマンド文字列の処理内で使用するのに好適なｃｍｄｌｅｔオブジェクトを作成するプロセス例を示す論理流れ図である。この時点で、ｃｍｄｌｅｔデータ構造は、作成済みであり、属性および予想される入力パラメータはすでに指定されている。ｃｍｄｌｅｔは、コンパイルされ、登録されている。登録時に、クラス名（つまり、ｃｍｄｌｅｔ名）が登録ストア内に書き込まれ、ｃｍｄｌｅｔに関連付けられたメタデータは、格納済みである。プロセス１０００は、ブロック１００１から始まり、そこで、パーザはｃｍｄｌｅｔを示す入力（例えば、キーストローク）を受け取っている。パーザは、レジストリ内から入力を検索し、その入力を登録済みのｃｍｄｌｅｔｓの１つに関連付けることにより、入力をｃｍｄｌｅｔとして認識することができる。処理は、ブロック１００６に進む。

ブロック１００６に進む前に、ｃｍｄｌｅｔオブジェクトクラスに関連付けられているメタデータが読み込まれる。メタデータは、ｃｍｄｌｅｔに関連付けられたディレクティブのいずれかを含む。それらのディレクティブを、ｃｍｄｌｅｔ自体またはパラメータのうちの１つまたは複数に適用することができる。ｃｍｄｌｅｔの登録時に、登録コードは、メタデータを永続的ストアに登録する。メタデータは、シリアライズ形式でＸＭＬファイル、および外部データベースなどに格納されることができる。各カテゴリのディレクティブは、異なる段階で処理される。それぞれのメタデータディレクティブは、それ独自のエラー処理を行う。

ブロック１００６で、ｃｍｄｌｅｔオブジェクトは、識別されたｃｍｄｌｅｔクラスに基づいてインスタンス化される。処理は、ブロック１００８に続く。

ブロック１００８で、ｃｍｄｌｅｔに関する情報が取得される。これは、リフレクションまたはその他の手段を通じて実行することができる。この情報は、予想される入力パラメータに関する情報である。上述のように、パブリックと宣言されたパラメータ（例えば、パブリック文字列Ｎａｍｅ ６３０）は、コマンドライン上のコマンド文字列で指定でき、または入力ストリーム内で与えることができる予想される入力パラメータに対応する。図１３で説明されている、拡張型マネージャを経由した管理ツールフレームワークは、情報を（必要に応じて）呼び出し側に返すための共通インターフェイスを備える。処理は、ブロック１０１０に続く。

ブロック１０１０で、適用性ディレクティブ（ａｐｐｌｉｃａｂｉｌｉｔｙ ｄｉｒｅｃｔｉｖｅｓ）が適用される。適用性ディレクティブは、そのクラスが特定のマシン役割および／またはユーザ役割で使用されることを保証する。例えば、いくつかのｃｍｄｌｅｔｓは、ドメイン管理者のみが使用できる。適用性ディレクティブの１つで指定された制約条件が満たされない場合、エラーが発生する。処理は、ブロック１０１２に続く。

ブロック１０１２で、メタデータが使用される。処理中のこの時点では、コマンド文字列全体はまだ入力されていない。しかし、管理ツールフレームワークは、使用可能なｃｍｄｌｅｔｓを知っている。ｃｍｄｌｅｔが決定されると、管理ツールフレームワークは、ｃｍｄｌｅｔオブジェクトに対してリフレクションを実行することにより使用できるようになる入力パラメータを認識する。そこで、管理ツールフレームワークは、ｃｍｄｌｅｔ名の曖昧でない部分が与えられると、ｃｍｄｌｅｔをオートコンプリートし、その後、入力パラメータの曖昧でない部分がコマンドライン上で入力されると、入力パラメータをオートコンプリートすることができる。オートコンプリートは、入力パラメータの一部が入力パラメータの１つをはっきりと識別できると、すぐに実行することができる。さらに、オートコンプリートは、ｃｍｄｌｅｔ名およびオペランドでも実行できる。処理は、ブロック１０１４に続く。

ブロック１０１４で、プロセスは、ｃｍｄｌｅｔに対する入力パラメータが入力されるまで待つ。これは、ユーザがリターンキーを押すなどによりコマンド文字列の終わりを指示すると実行される。スクリプトでは、改行がコマンド文字列の終わりを示す。この待機は、ユーザからパラメータに関する追加情報を取得し、他のディレクティブを適用することを含むことができる。ｃｍｄｌｅｔがパイプライン化されたパラメータの１つであれば、処理は即座に開始することができる。必要なコマンド文字列および入力パラメータが与えられると、処理は完了である。

（ｃｍｄｌｅｔの初期値設定のプロセスの例）
ｃｍｄｌｅｔの設定のプロセスの例は図１１に示されており、次に、図５を参照しつつ説明する。管理ツールフレームワークでは、コアエンジンは、ｃｍｄｌｅｔのパラメータの設定をする処理を実行する。処理は、ｃｍｄｌｅｔのインスタンスが作成された後、ブロック１１０１から始まる。処理は、ブロック１１０２に続く。

ブロック１１０２で、ｃｍｄｌｅｔ内で宣言されたかパラメータ（例えば、ＰｒｏｃｅｓｓＮａｍｅ）が取り出される。ｃｍｄｌｅｔでの宣言に基づき、コアエンジンは、送られて来る入力オブジェクトが「ＰｒｏｃｅｓｓＮａｍｅ」という名前のプロパティを与えることを認識する。送られて来るプロパティの型がパラメータ宣言で指定された型と異なる場合、その型は、拡張型マネージャを介して課される。データ型を課すプロセスについては、以下の「拡張型マネージャの処理の例」という表題の小節で説明する。処理は、ブロック１１０３に続く。

ブロック１１０３で、このパラメータに関連付けられている属性が取得される。この属性で、パラメータに対する入力ソースがコマンドラインであるか、それともパイプラインからであるかを識別する。処理は、決定ブロック１１０４に続く。

決定ブロック１１０４で、その属性が入力ソースをコマンドラインとして指定するか否かの決定が行われる。入力ソースがコマンドラインの場合、処理はブロック１１０９に続く。そうでない場合、処理は、決定ブロック１１０５に続く。

決定ブロック１１０５で、宣言の中で指定されたプロパティ名が使用されるか、またはプロパティ名に対するマッピングが使用されるのかの決定が行われる。この決定は、コマンド入力でパラメータに対するマッピングを指定したか否かに基づく。以下の行は、パラメータ「ＰｒｏｃｅｓｓＮａｍｅ」を送られて来るオブジェクトの「ｆｏｏ」メンバにマッピングする例を示している。

＄ｇｅｔ−ｐｒｏｃｅｓｓ｜ｗｈｅｒｅ｛＄＿．ｈｃｏｕｎｔ−ｇｔ ５００｝｜ｓｔｏｐ−ｐｒｏｃｅｓｓ−ＰｒｏｃｅｓｓＮａｍｅ＜−ｆｏｏ．
処理は、ブロック１１０６に続く。

ブロック１１０６で、マッピングが適用される。このマッピングで、予想されるパラメータの名前が「ＰｒｏｃｅｓｓＮａｍｅ」から「ｆｏｏ」に置き換えられ、その後、コアエンジンはこれを使用して、送られて来るオブジェクトを解析し、正しい予想されるパラメータを識別する。処理は、ブロック１１０８に続く。

ブロック１１０８で、拡張型マネージャに対しクエリが実行され、送られて来るオブジェクト内のパラメータの値が特定される。拡張型マネージャに関して説明するように、拡張型マネージャは、パラメータ名を受け取り、リフレクションを使用して、パラメータ名を持って送られて来るオブジェクト内のパラメータを識別する。拡張型マネージャは、さらに、必要ならば、パラメータの他の処理を実行することもできる。例えば、拡張型マネージャは、上述の変換機構を通じて、データの型をデータの予想される型に強制することができる。処理は、決定ブロック１１１０に続く。

ブロック１１０９に再び戻ると、この属性で、入力ソースがコマンドラインであると指定された場合、コマンドラインからのデータが取得される。コマンドラインからデータを取得する作業は、拡張型マネージャを介して実行することができる。その後、処理は、決定ブロック１１１０に続く。

決定ブロック１１１０で、他の予想されるパラメータがあるか否かの判別が行われる。他の予想されるパラメータがある場合、処理は、ブロック１１０２にループバックし、上述のように進行する。そうでない場合、処理は完了し戻る。

そこで、図に示されているように、ｃｍｄｌｅｔｓは、送られて来るデータをシュレッディングするためのテンプレートとして動作して予想されるパラメータを取得する。さらに、予想されるパラメータは、予想されるパラメータの値を与える、送られて来るオブジェクトの型を知らなくても得られる。これは、従来の管理環境とはかなり異なる。従来の管理環境は、密結合であり、オブジェクトの型がコンパイル時に判明している必要がある。さらに、従来の環境であれば、予想されるパラメータは、値渡しまたは参照渡しにより関数に受け渡されているところである。そのため、本発明の解析（例えば、「シュレッディング」）機構では、プログラマは、それらのパラメータの値の取得方法を具体的に知らなくてもパラメータの型を指定することができる
例えば、ｃｍｄｌｅｔ Ｆｏｏに対する以下の宣言が与えられると、

コマンドライン構文は以下のいずれかとすることができる。

所望の構文を得るために、システム管理者側で規則の集まりを修正することができる。さらに、パーザは、ユーザが複数の構文を使用できるように複数の規則の集まりをサポートできる。本質的に、ｃｍｄｌｅｔ構造（例えば、文字列ＮａｍｅおよびＢｏｏｌ Ｒｅｃｕｒｓｅ）に関連付けられた文法によりパーザが駆動される。

一般に、解析ディレクティブは、コマンド文字列として入力されたパラメータをｃｍｄｌｅｔオブジェクト内で識別された予想されるパラメータにマッピングする方法を記述する。入力パラメータ型のチェックが行われて、正しいか否かの判定が行われる。入力パラメータ型が正しくない場合、入力パラメータは、正しいパラメータになることを課すことができる。入力パラメータ型が正しくなく、修正することができない場合、使用法エラーが表示される。使用法エラーでは、ユーザは予想される正しい構文を認識することができる。使用法エラーは、ドキュメンテーションディレクティブから構文を記述する情報を取得することができる。入力パラメータ型がマッピングされるか、または検証されている場合、ｃｍｄｌｅｔオブジェクトインスタンス内の対応するメンバは設定が行われる。メンバの設定が行われると共に、拡張型マネージャは、入力パラメータ型の処理を行う。簡単に言うと、処理は、プロパティパス機構、キー機構、比較機構、変換機構、グロバー機構、関係機構、およびプロパティセット機構を含むことができる。これらの機構は、それぞれ、以下の「拡張型マネージャの処理」という表題の節で説明するが、さらに図例も含む。

（ｃｍｄｌｅｔを実行するプロセスの例）
ｃｍｄｌｅｔを実行するプロセスの例を図１２に示すが、次に説明する。管理ツール環境の一実施例では、コアエンジンがｃｍｄｌｅｔを実行する。上述のように、第２のメソッド５４０内のコード５４２は、入力オブジェクト毎に実行される。処理は、ブロック１２０１から始まるが、ｃｍｄｌｅｔはすでに設定済みである。処理は、ブロック１２０２に続く。

ブロック１２０２で、コード５４２からのステートメントが実行のため取り出される。処理は、ブロック１２０６に続く。

ブロック１２０６で、そのステートメントが処理される。その後、処理は、決定ブロック１２０８に進む。ブロック１２０８で、コードに他のステートメントが含まれているか否かの判別が行われる。他のステートメントがある場合、処理はブロック１２０２にループバックし、次のステートメントを取得し、上述のように進行する。そうでない場合、処理は、決定ブロック１２１４に続く。

決定ブロック１２１４で、処理すべき他の入力オブジェクトがあるか否かの判別が行われる。他の入力オブジェクトがある場合、処理はブロック１２１６に進み、ｃｍｄｌｅｔに次のオブジェクトからのデータが設定される。図１０で説明されている設定プロセスは、次のオブジェクトで実行される。その後、処理は、ブロック１２０２にループバックし、上述のように進行する。すべてのオブジェクトが処理された後、ｃｍｄｌｅｔを実行するプロセスが完了し、戻る。

（拡張型マネージャの処理例）
図１３を参照しつつ上で簡単に述べたように、拡張型マネージャは、供給されるオブジェクト上で追加処理を実行することができる。追加処理は、パーザ２２０、スクリプトエンジン２２２、またはパイプラインプロセッサ４０２の要求時に実行することができる。追加処理は、プロパティパス機構、キー機構、比較機構、変換機構、グロバー機構、関係機構、およびプロパティセット機構を含む。当業者であれば、請求されている発明の範囲から逸脱せずに、拡張型マネージャはさらに他の処理とともに拡張できることを理解するであろう。次に、追加処理機構のそれぞれについて説明する。

最初に、プロパティパス機構は、文字列でオブジェクトのプロパティをナビゲートすることができる。従来のリフレクションシステムでは、複数のクエリによりオブジェクトのプロパティにクエリを行うことができる。しかし、本発明の拡張型マネージャでは、オブジェクトの次々に続く複数のプロパティへのナビゲーションパスを与える文字列を指定できる。以下は、プロパティパスＡ．Ｂ．Ｃ．Ｄの構文例を説明している。

それぞれのコンポーネント（例えば、Ａ、Ｂ、Ｃ、およびＤ）は、プロパティ、パラメータ付きメソッド、パラメータなしメソッド、フィールド、ＸＰＡＴＨなどを表すことができる文字列を含む。ＸＰＡＴＨは、要素を検索するクエリ文字列を指定する（例えば、「／ＦＯＯ＠＝１３」）。この文字列内には、特にコンポーネントの型を示すために特殊文字を含めることができる。文字列が特殊文字を含まない場合、拡張型マネージャは、検索を実行し、コンポーネントの型を判別することができる。例えば、コンポーネントＡがオブジェクトの場合、拡張型マネージャは、Ｂがオブジェクトのプロパティなのか、オブジェクトに対するメソッドなのか、オブジェクトのフィールドなのか、プロパティセットなのかについてクエリを行うことができる。拡張型マネージャがＢの型を識別した後、その型に応じた処理が実行される。コンポーネントが上記の型の１つでない場合、拡張型マネージャは、さらに、拡張ソースにクエリを行って、Ａの型をＢの型に変換する変換関数があるか否かを判別することができる。これらおよび他の検索について、コマンド文字列の例を使用し、それぞれの出力を示して説明することにする。

プロパティパスを含む文字列例を以下に示す。
＄ ｇｅｔ−ｐｒｏｃｅｓｓ｜ｗｈｅｒｅ｛＄＿．ｈａｎｄｌｅｃｏｕｎｔ−ｇｔ ５００｝｜ｆｏｒｍａｔ−ｔａｂｌｅ ｎａｍｅ．ｔｏｕｐｐｅｒ，ｗｓ．ｋｂ，ｅｘｅ＊．ｖｅｒ＊．ｄｅｓｃｒｉｐｔｉｏｎ．ｔｏｌｏｗｅｒ．ｔｒｕｎｃ（３０）．
上記の文字列の中には、３つのプロパティパス、（１）「ｎａｍｅ．ｔｏｕｐｐｅｒ」、（２）「ｗｓ．ｋｂ」、および（３）「ｅｘｅ＊．ｖｅｒ＊．ｄｅｓｃｒｉｐｔｉｏｎ．ｔｏｌｏｗｅｒ．ｔｒｕｎｃ（３０）」がある。これらのプロパティパスについて説明する前に、「ｎａｍｅ」、「ｗｓ」、および「ｅｘｅ」はテーブルのプロパティを指定することに留意されたい。さらに、これらのプロパティはそれぞれ、「ｇｅｔ／ｐｒｏｃｅｓｓ」により元々生成され、その後、さまざまなｃｍｄｌｅｔｓを通じてパイプラインで送られる、送られて来るオブジェクトの直接プロパティであることに留意されたい。次に３つのプロパティパスのそれぞれについてかかわる処理について説明する。

第１のプロパティパス（つまり、「ｎａｍｅ．ｔｏｕｐｐｅｒ」）で、ｎａｍｅは、送られて来るオブジェクトの直接プロパティであり、オブジェクトそれ自体でもある。拡張型マネージャは、上述の優先度検索を使用してシステムにクエリを行い、ｔｏｕｐｐｅｒに対する型を判別する。拡張型マネージャは、ｔｏｕｐｐｅｒがプロパティでないことを発見する。しかし、ｔｏｕｐｐｅｒは、文字列型により継承され、文字列内の小文字を大文字に変換するメソッドであるかもしれない。それとは別に、拡張型マネージャは、拡張メタデータへのクエリを行って、名前オブジェクトを大文字に変換できるサードパーティコードがあるか否かを判別する場合もある。コンポーネント型を見つけた後、そのコンポーネント型に応じて処理が実行される。

第２のプロパティパス（つまり、「ｗｓ．ｋｂ」）で、「ｗｓ」は、送られて来るオブジェクトの直接プロパティであり、オブジェクトそれ自体でもある。拡張型マネージャは、「ｗｓ」が整数であると判別する。次に、拡張型マネージャは、ｋｂは整数のプロパティか、ｋｂが整数のメソッドであるかについてクエリを行い、そして最後に、コードが整数を受け取って、ｋｂ型に変換する方法を認識しているか否かについてクエリを行う。サードパーティコードは、この変換を実行するために登録され、変換が実行される。

第３のプロパティパス（つまり、「ｅｘｅ＊．ｖｅｒ＊．ｄｅｓｃｒｉｐｔｉｏｎ．ｔｏｌｏｗｅｒ．ｔｒｕｎｃ（３０）」）に、複数のコンポーネントがある。第１のコンポーネント（「ｅｘｅ」）は、送られて来るオブジェクトの直接プロパティであり、またオブジェクトでもある。ここでもまた、拡張型マネージャは、検索クエリを続けて、第２のコンポーネント（「ｖｅｒ＊」）を処理する。「ｅｘｅ＊」オブジェクトは、「ｖｅｒ＊」プロパティまたはメソッドを持たないため、拡張型マネージャは、拡張メタデータについてクエリを行い、実行可能ファイル名をバージョンに変換するために登録されているコードがあるか否かを判別する。この例については、そのようなコードが存在する。このコードは、実行可能ファイル名文字列を受け取り、それを使用してファイルを開き、その後、バージョンブロックオブジェクトにアクセスし、バージョンブロックオブジェクトの記述プロパティ（第３のコンポーネント「ｄｅｓｃｒｉｐｔｉｏｎ」）を返すことができる。次に、拡張型マネージャは、この同じ検索機構を第４のコンポーネント（「ｔｏｌｏｗｅｒ」および第５のコンポーネント（「ｔｒｕｎｃ（４０）」）に対して実行する。そこで、例示されているように、拡張型マネージャは、きわめて手の込んだ処理をコマンド文字列に対して実行することができ、しかも管理者が特定のコードを書く必要がない。表１は、例示されている文字列について生成される出力を示している。

他のクエリ機構１３２４は、キーを含む。キーは、データ型のインスタンスを一意的にする１つまたは複数のプロパティを識別する。例えば、データベース中の１つの列は、各行（例えば、社会保障番号）を一意に識別できるキーとして識別することができる。キーは、そのデータ型に関連付けられている型メタデータ１３４０内に格納される。その後、このキーは、そのデータ型のオブジェクトを処理するときに拡張型マネージャにより使用されうる。データ型は、拡張データ型でも既存のデータ型でもよい。

他のクエリ機構１３２４は、比較機構を含む。簡単に言うと、図１４〜２３を参照しつつ以下で詳しく説明するが、比較機構は２つのオブジェクトを比較する。２つのオブジェクトが比較関数を直接サポートしている場合、直接サポートされている比較関数が実行される。しかし、いずれのオブジェクトも比較関数をサポートしていない場合、拡張型マネージャは、型メタデータ内で、２つのオブジェクトの間の比較をサポートするために登録されているコードを探すことができる。比較機構を呼び出す一連のコマンドライン文字列の例を、表２の対応する出力とともに、以下に示す。

ｃｏｍｐａｒｅ−ｔｉｍｅ ｃｍｄｌｅｔは、２つの日時オブジェクトを比較するために書かれている。この場合、ＤａｔｅＴｉｍｅオブジェクトはＩＣｏｍｐａｒａｂｌｅインターフェイスをサポートする。

他のクエリ機構１３２４は、変換機構を含む。拡張型マネージャを使用することにより、特定の変換を実行する機能を記述しているコードを登録することができる。その後、型Ａのオブジェクトが入力され、ｃｍｄｌｅｔで型Ｂのオブジェクトを指定した場合、拡張型マネージャは、登録済みの変換のうちの１つを使用して変換を実行することができる。拡張型マネージャは、一連の変換を実行することで、型Ａを型Ｂに課すことができる。上述のプロパティパス（「ｗｓ．ｋｂ」）は、変換機構を例示している。

他のクエリ機構１３２４は、グロバー機構を含む。グロバーは、文字列内のワイルドカード文字を指す。グロバー機構は、ワイルドカード文字を含む文字列を入力し、オブジェクトの集合を出力する。拡張型マネージャでは、ワイルドカード処理を指定するコードを登録することができる。上述のプロパティパス（「ｅｘｅ＊．ｖｅｒ＊．ｄｅｓｃｒｉｐｔｉｏｎ．ｔｏｌｏｗｅｒ．ｔｒｕｎｃ（３０）」）は、グロバー機構を例示している。登録されているプロセスは、ファイル名、ファイルオブジェクト、送られて来るプロパティなどのグロビング（ｇｌｏｂｂｉｎｇ）機能を備えることができる。

他のクエリ機構１３２４は、プロパティセット機構を含む。プロパティセット機構では、プロパティの集合に対し名前を定義することができる。その後、管理者は、コマンド文字列内で名前を指定してプロパティの集合を取得することができる。プロパティセットは、さまざまな方法で定義できる。一方法では、「？」などの定義済みパラメータは、ｃｍｄｌｅｔの入力パラメータとして入力できる。定義済みパラメータを認識した後の動作環境では、送られて来るオブジェクトのプロパティをすべてリストに列挙する。このリストは、管理者が所望のプロパティを容易にチェック（例えば、「クリックオン」）し、プロパティセットに名前を付けるために使用されるＧＵＩであってよい。その後、プロパティセット情報は、拡張メタデータ内に格納される。プロパティセット機構を呼び出す文字列の例を、表３の対応する出力とともに、以下に示す。

＄ ｇｅｔ−ｐｒｏｃｅｓｓ｜ｗｈｅｒｅ｛＄＿．ｈａｎｄｌｅｃｏｕｎｔ−ｇｔ ５００｝｜ｆｏｒｍａｔ−ｔａｂｌｅ ｃｏｎｆｉｇ．
この文字列の例では、「ｃｏｎｆｉｇ」という名前のプロパティセットは、名前プロパティ、プロセスｉｄプロパティ（Ｐｉｄ）、および優先度プロパティを含むものとして定義されている。このテーブルの出力を以下に示す。

他のクエリ機構１３２４は、関係機構を含む。１つの関係（つまり、継承）をサポートする従来の型システムとは対照的に、関係機構では、型間の複数の関係を表すことをサポートする。ここでもまた、これらの関係は登録される。関係は、オブジェクトが消費するアイテムを見つけること、またはオブジェクトを消費するアイテムを見つけることを含むことができる。拡張型マネージャは、さまざまな関係を記述するオントロジーにアクセスすることができる。拡張メタデータおよびコードを使用することにより、ＯＷＬ、ＤＡＷＬなどのオントロジーサービスにアクセスするための仕様を記述することができる。．ＯＷＬ：“ｓｔｒｉｎｇ”は、関係機構を使用する例示文字列の一部である。

「ＯＷＬ」識別子で、オントロジーサービスを識別し、「ｓｔｒｉｎｇ」で、オントロジーサービス内の特定の文字列を指定する。そのため、拡張型マネージャは、オントロジーサービスにより与えられる型にアクセスすることができる。

第３節：比較手法の例
図１４〜２３は、上記の第２節で説明されているオブジェクトベースの管理ツールフレームワーク内で稼働する本発明の比較手法の複数の実施例を示す。本発明の比較手法は、従来の比較手法に勝るいくつかの利点を有する。例えば、本発明の比較手法を使用すると、異なるデータ型のオブジェクト同士を比較することができる。さらに、比較手法からの結果を、最終的に問題を解決することができる他のオペレーションへの入力として自動的に使用できる。これらおよびその他の利点は、以下の詳細な説明を読むと明らかになるであろう。

図１４は、図２に示されているオブジェクトベースの管理フレームワーク内に実装されているｃｏｍｐａｒｅ ｃｍｄｌｅｔの構文例のいくつかの実施形態を示している。第１の構文１４００は、図１６に示される流れ図を参照しつつ説明されるキーベースの比較に対応している。第２の構文１４０１は、図１７に示されている流れ図を参照しつつ説明される順序ベースの比較に対応する。２つの比較手法を区別するために、ｃｏｍｐａｒｅ−ｏｂｊｅｃｔ ｃｍｄｌｅｔが呼び出されるときにＫｅｙＢａｓｅｄパラメータ１４０６またはＯｒｄｅｒＢａｓｅｄパラメータ１４０８がコマンド文字列内に含まれる。ＫｅｙＢａｓｅｄパラメータ１４０６は、スイッチ（例えば、「−ＫｅｙＢａｓｅｄ」）およびキー名を伴う。キー名は、比較されるオブジェクトを識別する。その後、そのキー名に関連付けられているプロパティを持つオブジェクトのみが比較に含まれる。キー名は、単一のプロパティでも、プロパティの集合でもよい。

第１の構文１４００と第２の構文１４０１は両方とも、他のパラメータを含む。一般に、パラメータのほとんどはスイッチおよびデータを含む。スイッチは、ｃｏｍｐａｒｅ−ｏｂｊｅｃｔ ｃｍｄｌｅｔを呼び出すときにコマンド文字列内に現れる所定のテキストを表す。データは、このスイッチに依存する。例えば、いくつかのスイッチは、論理データに関連付けることができる。他のスイッチは、プロパティに関連付けることができる。これらのスイッチの一部は、関連付けられたデータを持つコマンド文字列内に含まれない場合がある。このような場合、コマンド文字列内に入力されているデータは、順序に依存することになるか、または少なくとも、ｃｏｍｐａｒｅ ｃｍｄｌｅｔの定義内の入力パラメータについて指定された属性に依存しうる。次に、これら他のパラメータのそれぞれについて、個別に説明する。

ＲｅｆｅｒｅｎｃｅＯｂｊｅｃｔパラメータ１４０２は、「−ＲｅｆｅｒｅｎｃｅＯｂｊｅｃｔ」スイッチおよび参照オブジェクトを含む。参照オブジェクトは、他のオブジェクトと比較される１つまたは複数のオブジェクトを識別する。

ＣｏｍｐａｒｉｓｏｎＯｂｊｅｃｔパラメータ１４０４は、「−ＣｏｍｐａｒｉｓｏｎＯｂｊｅｃｔ」スイッチおよび比較オブジェクトを含む。比較オブジェクトは、参照オブジェクトと比較される１つまたは複数のオブジェクトを識別する。図に示されるように、比較オブジェクトは、オブジェクトベースのパイプラインから供給されうる。

そのため、参照オブジェクトは、スタンダードとして使用され、任意の個数の比較オブジェクトと比較されることができる。例えば、参照オブジェクトは、コンピューティング装置の標準構成とすることができ、それぞれの比較オブジェクトは、システム管理者が標準構成に類似の構成をとりたい異なるコンピューティング装置に対応することができる。

Ｐｒｏｐｅｒｔｙパラメータ１４１０は、「−Ｐｒｏｐｅｒｔｙ」スイッチおよびプロパティ名を含む。プロパティ名は、１つまたは複数のプロパティをリストにしたもの、またはプロパティの集合をリストにしたものとすることができる。Ｐｒｏｐｅｒｔｙパラメータ１４１０を使用すると、複数のオブジェクト内のすべてのプロパティを比較する代わりに、特定のプロパティを比較することができる。このように特定のプロパティを指定できると、報告される重要でない相違点の数が最小限に抑えられる。例えば、Ｐｒｏｃｅｓｓ Ａが現在は動作していない（これ以降、Ｔｏｄａｙ Ｐｒｏｃｅｓｓ Ａと呼ぶ）が、昨日は動作していた（これ以降、Ｙｅｓｔｅｒｄａｙ Ｐｒｏｃｅｓｓ Ａと呼ぶ）場合、Ｐｒｏｐｅｒｔｙパラメータ１４１０は、比較の中に含まれることによってＴｏｄａｙ Ｐｒｏｃｅｓｓ ＡとＹｅｓｔｅｒｄａｙ Ｐｒｏｃｅｓｓ Ａとの間の違いが分かるプロパティ（例えば、ＣＰＵ時間、ワーキングセット）にすることができる。そのため、本発明の比較手法の出力は、より参考になる情報を提供し、失敗の理由を突き止めるのに役立つ。

ＣａｓｅＳｅｎｓｉｔｉｖｅパラメータ１４１２は、「−ＣａｓｅＳｅｎｓｉｔｉｖｅ」スイッチおよび「Ｆａｌｓｅ」または「Ｔｒｕｅ」を示すオプションの論理値を含む。「−ＣａｓｅＳｅｎｓｉｔｉｖｅ」スイッチが「Ｆａｌｓｅ」値とともに含まれる場合、参照オブジェクトおよび比較オブジェクトの中の文字列の大文字小文字の区別は考慮されない。逆に、「Ｔｒｕｅ」値が指定されている場合、文字列の大文字小文字の区別は、相違点を判別する際に考慮される。ＣａｓｅＳｅｎｓｉｔｉｖｅパラメータ１４１２は、参照オブジェクトおよび比較オブジェクトが文字列型である場合に使用できる。他のデータ型については、ＣａｓｅＳｅｎｓｔｉｖｅパラメータ１４１２は無視される。

Ｃｕｌｔｕｒｅパラメータ１４１４は、「−Ｃｕｌｔｕｒｅ」スイッチおよびカルチャ設定値を含む。指定されたカルチャ設定値は、現在のカルチャ設定をオーバーライドする。参照オブジェクトおよび比較オブジェクトは、両方とも、同じカルチャを持つものとして処理される。Ｃｕｌｔｕｒｅパラメータ１４１４は、参照オブジェクトおよび比較オブジェクトが文字列型であり、同じ言語を使用してテキストの比較が実行されることを保証する場合に使用することができる。他のデータ型については、Ｃｕｌｔｕｒｅパラメータ１４１４を無視できる。

ＩｇｎｏｒｅＷｈｉｔｅＳｐａｃｅパラメータ１４１６は、「−ＩｇｎｏｒｅＷｈｉｔｅＳｐａｃｅ」スイッチおよびオプションの論理値を含む。論理値が「Ｆａｌｓｅ」の場合、比較の際に空白類はテキストの一部であるとみなされる。逆に、論理値が「Ｔｒｕｅ」の場合、比較時にテキスト内の空白類は無視される。ＩｇｎｏｒｅＷｈｉｔｅＳｐａｃｅ １４１６は、参照オブジェクトおよび比較オブジェクトが文字列型である場合に使用できる。他のデータ型については、ＩｇｎｏｒｅＷｈｉｔｅＳｐａｃｅパラメータ１４１６は無視される。

ＲｅｃｏｒｄＤｉｆｆｅｒｅｎｃｅパラメータ１４１８は、「−ＲｅｃｏｒｄＤｉｆｆｅｒｅｎｃｅ」スイッチおよびオプションの論理値を含む。論理値が「Ｆａｌｓｅ」の場合、参照オブジェクトと比較オブジェクトとの間の相違点は出力に送られない。逆に、論理値が「Ｔｒｕｅ」の場合、相違点は出力に送られる。

ＲｅｃｏｒｄＥｑｕａｌパラメータ１４２０は、「−ＲｅｃｏｒｄＥｑｕａｌ」スイッチおよびオプションの論理値を含む。論理値が「Ｆａｌｓｅ」の場合、同じ値を持つ参照オブジェクトと比較オブジェクトのプロパティは出力に送られない。論理値が「Ｔｒｕｅ」の場合、同じ値を持つ参照オブジェクトと比較オブジェクトのプロパティは出力に送られる。

ＰａｓｓＴｈｒｕパラメータ１４２２は、「−ＰａｓｓＴｈｒｕ」スイッチおよびオプションの論理値を含む。論理値が「Ｆａｌｓｅ」の場合、比較の結果、キー名、プロパティ値、イコールインジケータ、およびｓｉｄｅＩｎｄｉｃａｔｏｒが出力される。ｓｉｄｅＩｎｄｉｃａｔｏｒは、出力が参照オブジェクトに関連付けられているか否か、または出力が比較オブジェクトに関連付けられているか否かをグラフィックで示す。例えば、左ｓｉｄｅＩｎｄｉｃａｔｏｒ「＜＝」は、後に続く情報が参照オブジェクトからであることを示す。右ｓｉｄｅＩｎｄｉｃａｔｏｒ「＝＞」は、後に続く情報が比較オブジェクトからであることを示す。イコールインジケータ「＝＝」は、比較オブジェクトと参照オブジェクトとが同じ値を持つことを示す。論理値が「Ｔｒｕｅ」の場合、参照オブジェクトと比較オブジェクトの両方が注釈され、出力される。本発明の比較手法の範囲から逸脱することなく、さまざまな文字および／またはグラフィックスをｓｉｄｅＩｎｄｉｃａｔｏｒに使用できることに留意されたい。

図１５は、ｃｏｍｐａｒｅ ｃｍｄｌｅｔを呼び出すコマンド文字列を例示し、また生成された出力を例示するいくつかの実施例を示している。これらの実施例１５１０および１５２０は両方とも、テーブル１５０２およびテーブル１５０４に示されている実施例に基づく。テーブル１５０２および１５０４は、両方とも、２行、２列、Ｐｒｏｃｅｓｓ ＮａｍｅおよびＨａｎｄｌｅｃｏｕｎｔを持つ。第１の行は、Ｐｒｏｃｅｓｓ Ｎａｍｅとして「ＭＳＨ」を持つプロセスに対応し、第２の行は、Ｐｒｏｃｅｓｓ Ｎａｍｅとして「Ｃａｌｃ」を持つプロセスに対応する。テーブル１５０２では、ＭＳＨに対するｈａｎｄｌｅｃｏｕｎｔは１００であり、Ｃａｌｃに対するｈａｎｄｌｅｃｏｕｎｔは１００である。テーブル１５０４では、ＭＳＨに対するｈａｎｄｌｅｃｏｕｎｔはそのまま１００であり、Ｃａｌｃに対するｈａｎｄｌｅｃｏｕｎｔは５００である。例示するために、テーブル１５０４内の情報は、テーブル１５０２内の情報の１０秒後に生成されていると仮定されている。

第１の実施例１５１０では、コマンドラインにコマンド「＄ａ＝ｇｅｔ−ｐｒｏｃｅｓｓ」が入力される。上記で説明されているように、オブジェクトベースの管理フレームワークでこのコマンドが実行される場合、ｇｅｔ−ｐｒｏｃｅｓｓ ｃｍｄｌｅｔから生成された情報（例えば、テーブル１５０２）は、オブジェクトａに割り当てられる。１０秒後に、以下のコマンドが入力される。

オブジェクトベースの管理フレームワークで上記コマンドが実行される場合、参照オブジェクトは、テーブル１５０２内の情報に関連付けられたオブジェクト「ａ」である。比較オブジェクトは、テーブル１５０４内の情報を生成したｇｅｔ−ｐｒｏｃｅｓｓ ｃｍｄｌｅｔから生成されたオブジェクトである。ＫｅｙＢａｓｅｄパラメータ１４０６は、「ＰｒｏｃｅｓｓＮａｍｅ」という名前のプロパティを持つオブジェクトに対しＫｅｙＢａｓｅｄ比較を実行するコマンド文字列および信号に含まれる。このコマンド文字列は、さらに、「Ｈａｎｄｌｅｃｏｕｎｔ」を比較対象のプロパティとして識別するＰｒｏｐｅｒｔｙパラメータ１４１０も含む。そのため、ＰｒｏｃｅｓｓＮａｍｅプロパティを持つ比較オブジェクト毎に、ｈａｎｄｌｅｃｏｕｎｔプロパティが参照オブジェクト内のｈａｎｄｌｅｃｏｕｎｔプロパティと比較される。その後、出力１５１２は、ＭＳＨプロセス名が参照オブジェクト内で同一の情報を持つことを示す。出力１５１２は、さらに、Ｃａｌｃプロセス名が参照オブジェクトと比較オブジェクトとで異なる情報を持つことも示す。

実施例１５２０では、第１のコマンドは、実施例１５１０と同じであるが、第２のコマンドは、以下のとおりである。

そのため、実施例１５２０は、ＲｅｃｏｒｄＤｉｆｆｅｒｅｎｃｅスイッチおよびＲｅｃｏｒｄＥｑｕａｌスイッチを含む。ＲｅｃｏｒｄＤｉｆｆｅｒｅｎｃｅスイッチは、ｆａｌｓｅで設定することができ、ＲｅｃｏｒｄＥｑｕａｌスイッチは、ｔｒｕｅで設定することができる。上記で説明されているように、これらのスイッチを使用すると、ＲｅｃｏｒｄＥｑｕａｌパラメータでは等しいプロパティのみを出力することを指定するので、出力１５２２は、参照オブジェクトまたは比較オブジェクトのいずれかに関連付けられているＣａｌｃプロセスのｈａｎｄｌｅｃｏｕｎｔをリストしない。

実施例１５１０および１５２０はｃｏｍｐａｒｅ−ｏｂｊｅｃｔ ｃｍｄｌｅｔのオペレーションを例示しているが、当業者であれば、さまざまなスイッチおよびその他のｃｍｄｌｅｔｓを使用して多数のコマンド文字列を定式化し、有用な情報を取得することができることを理解するであろう。さらに、上記の第２節で説明したように、ｃｍｄｌｅｔの結果はパイプラインで他のｃｍｄｌｅｔｓに送ることができる。そのため、ｃｏｍｐａｒｅ−ｏｂｊｅｃｔ ｃｍｄｌｅｔは、それぞれのオブジェクトおよびその相違点を識別する差分レコードを作成するので、この差分レコードは、さらに、他のｃｍｄｌｅｔｓにより操作することができる。これら他のｃｍｄｌｅｔｓは、データベースのフィルタ処理、レポート作成、フィリングなどの処理、または差分レコードにリストされている相違点を解決する制御ループを提供することができる。差分レコードを制御ループにパイプラインで送ることができるため、本発明の比較手法の有用性が大幅に高められる。

さらに、この比較手法は、これらのオブジェクトの完全な意味論が出力オブジェクト内で利用できるように、オリジナルの参照オブジェクトおよびオリジナルの比較オブジェクトをカプセル化する１つまたは複数の出力オブジェクトを生成することができる。この実施形態では、差分レコードに書き込まれる情報は、注釈として、オリジナルの参照オブジェクトに追加することができる。拡張型マネージャは、この注釈を実行することができる。出力オブジェクトは、参照オブジェクトおよび比較オブジェクト、相違点のあるオブジェクト、一致するオブジェクトなどのそれぞれを含むように構成することができる。本発明の比較手法では、オリジナルのオブジェクトの一部をカプセル化する出力オブジェクトを生成できるため、これらのオリジナルのオブジェクトは、最初に、プロパティの一方の集合に基づいて比較され、そして後から、プロパティの第１の集合に含まれるプロパティのどれも含みえないか、またはそれらの一部を含みえるプロパティの他方の集合に基づいて処理されることが可能である。さらに、差分インジケータ注釈を使用し、その後の処理においてそれ独自の必要条件に基づいてプロパティのそれ独自の集合を選択することができる。オリジナルのオブジェクトをカプセル化するオブジェクトを出力することにより得られる他の利点は、オリジナルのオブジェクトにより公開されるクエリおよび制御メソッドを出力オブジェクト上で呼び出せるという点である。次に、図１６〜２３の流れ図を参照しつつ、比較手法のオペレーションについて説明する。

図１６は、キーベースの比較プロセスを実行するプロセス例を示す論理流れ図である。このプロセスは、ブロック１６０１から始まり、ブロック１６０２に続く。

ブロック１６０２で、参照オブジェクトが取り出される。参照オブジェクトは、比較プロセスのときに他のオブジェクトと比較されるオブジェクトである。処理は、決定ブロック１６０４に続く。

決定ブロック１６０４では、参照オブジェクトがＫｅｙＢａｓｅｄパラメータで指定されたキー名に関連付けられたプロパティを含むか否かの判別が行われる。複数のキーがある場合、参照オブジェクトは、それらの複数のキーのそれぞれに関連付けられたプロパティを含む。参照オブジェクトが指定されたプロパティを含まない場合、処理はブロック１６１０に続く。他の改良では、ブロック１６１０に進む前に、参照オブジェクトは、コマンドで指定されたパラメータに基づいて出力されるリストに追加することができる。そうでない場合、処理は、決定ブロック１６０６に続く。

決定ブロック１６０６で、参照セットが見直され、参照オブジェクトがすでにキーに対する同じ値を持つ参照セット内に存在するか否かを判別する。そのような参照オブジェクトが存在する場合、処理は決定ブロック１６１０に続く。そうでない場合、処理は、ブロック１６０８に続く。

ブロック１６０８で、参照オブジェクトが参照セットに追加される。その後、処理は、決定ブロック１６１０に続く。

決定ブロック１６１０で、比較プロセスで使用する他の参照オブジェクトがあるか否かの判別が行われる。他の参照オブジェクトがある場合、処理はブロック１６０２にループバックし、上述のように続く。そうでない場合、指定された１つまたは複数のキーを含むすべての参照オブジェクトが参照セットにすでに追加されている。処理は、ブロック１６１２に続く。

ブロック１６１２で、参照セット内の各参照オブジェクトおよびそれぞれの使用可能な比較オブジェクトを使用して比較が実行される。図２１を参照しつつ以下で簡単に説明するが、Ｐｒｏｐｅｒｔｙパラメータで指定されるそれぞれのプロパティは、参照オブジェクトとそれぞれの比較オブジェクトとの間で比較される。この比較が実行された後、処理は完了する。

図２１は、それぞれの比較オブジェクトを図１６のブロック１６１２で使用するのに好適な参照オブジェクトと比較するプロセスの例を示す流れ図である。プロセス２１００は、ブロック２１０１から始まり、ブロック２１０２に進む。

ブロック２１０２で、比較オブジェクトが取得される。上述のように、複数の比較オブジェクトがありうる。そのため、それぞれの比較オブジェクトをチェックし、参照オブジェクトと比較すべきか否かを調べる。処理は、決定ブロック２１０４に続く。

決定ブロック２１０４で、比較オブジェクトがキー名と関連付けられたプロパティを持つか否かの判別が行われる。複数のキーを使用できることに留意されたい。複数のキーがある場合、参照オブジェクトと比較オブジェクトとは、両方とも、複数のキーに関連付けられたプロパティを持っていなければならない。比較オブジェクトがキー名に関連付けられたプロパティを持っていない場合、処理は決定ブロック２１１６に続き、そこで、比較オブジェクトが欠損リストに追加され、処理は後述の決定ブロック２１１８に続く。ブロック２１０４での判別により、比較オブジェクトがキー名に関連付けられたプロパティを持つと結論された場合、処理は、決定ブロック２１０６に続く。

決定ブロック２１０６で、比較オブジェクトがキー値と関連付けられた第１の比較オブジェクトであるか否かの判別が行われる。第１の比較オブジェクトでない場合、処理はさらに決定ブロック２１１８に進む。そうでない場合、処理は、決定ブロック２１０８に続く。

決定ブロック２１０８で、同じキー値を持つ参照セット内に参照オブジェクトが存在するか否かの判別が行われる。このような参照オブジェクトが存在しない場合、処理はブロック２１１４に続き、そこで、比較専用レコードが出力される。比較専用レコードは、特定のキーを持つ比較オブジェクトが存在していたが、類似の参照オブジェクトは存在していなかったことを示す。上述のように、コンピューティング装置を標準構成と比較した場合、この情報は、潜在的構成問題を知らせるために有用である。比較専用レコードが出力された後、処理は、再び、決定ブロック２１１８に続く。しかし、決定ブロック２１０８の結果から、参照オブジェクトが存在すると結論される場合、処理はブロック２１１０に続く。

ブロック２１１０で、参照オブジェクトおよび比較オブジェクトのプロパティ値が比較される。手短に言うと、以下で図２２を参照しつつ詳しく説明するが、この比較は、指定されたそれぞれのプロパティを比較するということである。そのため、上で説明したように、注目するプロパティのみが比較され、それぞれのプロパティを比較する必要がない。プロパティ値が比較された後、処理はブロック２１１２に続く。

ブロック２１１２で、参照オブジェクトが参照セットから削除される。ブロック２１０６では、比較オブジェクトがすでに処理されている他の比較オブジェクトを複製するか否かをチェックするので、参照オブジェクトはこの時点で削除できる。参照オブジェクトを削除すると、後から結果を出力する際に列挙が簡単に行える。そこで、すべての比較オブジェクトが取り出され、および比較された後、参照オブジェクトが参照セット内にまだ存在している場合、これは相違のあることを示す。処理は、決定ブロック２１１８に続く。

決定ブロック２１１８で、他の比較が処理のため利用可能か否かが判別される。他の比較オブジェクトがある場合、処理はブロック２１０２にループバックし、上述のように続く。ただし、すべての比較オブジェクトが処理された後、処理はブロック２１２０に続く。

ブロック２１２０で、比較の残りの結果が出力される。手短に言うと、図２３を参照しつつ以下で詳しく説明するが、出力される結果は、ｃｏｍｐａｒｅコマンドとともに指定されたスイッチに基づくということである。その後処理は完了する。

図２２は、図２１で使用するのに好適な参照オブジェクトと比較オブジェクトとの間のプロパティ値を比較するプロセス例を示す流れ図である。プロセスは、ブロック２２０１から始まり、ブロック２２０２に進行する。

ブロック２２０２で、比較オブジェクト内の指定されたプロパティの１つが、参照オブジェクト内の対応するプロパティと比較される。参照オブジェクトおよび比較オブジェクトのデータ型は、必ずしも、同じである必要はないことに留意されたい。データ型が異なる場合、オブジェクトベースの管理フレームワークの拡張型マネージャは、異なるデータ型を認識し、それらを類似のデータ型が比較される形式に変換する。そのため、比較オブジェクトは、参照オブジェクトのデータ型に変換することができる。逆に、比較オブジェクトは、比較オブジェクトのデータ型に変換することができる。さらに、それぞれの指定されたプロパティは、比較の実行のため、個別に変換することができる。したがって、本発明の比較手法では、異なる型のオブジェクトを比較することができる。この比較手法では、参照オブジェクトを、仮想オブジェクトとしても取り扱われる比較オブジェクトと比較できる仮想オブジェクトとして取り扱う。

さらに、ｃｏｍｐａｒｅは、ファジー比較を含むことができ、参照オブジェクトおよび比較オブジェクトのプロパティに対する「値」は、エラーを報告する前にエラーの許容範囲内にありうることにも留意されたい。例えば、エラーの許容範囲が１Ｍｂｙｔｅに設定されている場合、値１０ＭＢと１２ＭＢとでは違いが生じる。しかし、値１０．５ＭＢと１１ＭＢとでは、違いは生じない。このファジー比較により、信号対雑音比が改善される。そのため、ファジー比較を実装する比較手法では、相違点の検出が改善され、著しく関連性が高まる。

ファジー比較は、「−ｃｏｍｐａｒｅ−ｏｂｊｅｃｔ ｃｏｌｏｒＣｏｍｐａｒｅ−ＲｅｆｅｒｅｎｃｅＯｂｊｅｃｔ ＄ａ −ＣｏｍｐａｒｉｓｏｎＯｂｊｅｃｔ ＄ｂ」などのコマンド文字列の一部として与えられるカスタム比較器を使用して実装することができる。この特定の実施例について、ｃｏｌｏｒＣｏｍｐａｒｅは、「ｍｏｓｓ ｇｒｅｅｎ」および「ｓａｇｅ」が同じであると報告されるように異なる色を格納するテキスト文字列同士を比較することができる。したがって、カスタム比較器があるため、異なるオブジェクト同士の比較を実行する自由度が大幅に高まる。指定されたプロパティが比較された後、処理は決定ブロック２２０４に続く。決定ブロック２２０４で、比較オブジェクトのプロパティの値が参照オブジェクトのプロパティの値に等しいか否かの判別が行われる。値が等しくない場合、処理はブロック２２１０に続き、そこで、指定されたプロパティに関して比較オブジェクトと参照オブジェクトとの間の相違を示す差分レコードを出力することができる。この差分レコードは、ｃｏｍｐａｒｅコマンドで指定されたパラメータに依存する。処理は、決定ブロック２２１２に続く。しかし、比較オブジェクトおよび参照オブジェクトのプロパティの値が等しい場合、処理は決定ブロック２２０６に続く。

決定ブロック２２０６で、ｃｏｍｐａｒｅコマンドの呼び出しで、等しいオブジェクトが出力されることを指定したか否かの判別が行われる。上述のように、これを達成する方法として、図１４に示されているＲｅｃｏｒｄＥｑｕａｌ １４２０を使用する方法がある。等しいオブジェクトが出力の中に含まれるべきでない場合、処理は決定ブロック２２１２に続く。そうでない場合、処理は、ブロック２２０８に続く。

ブロック２２０８で、比較オブジェクトの同等性レコードが出力される。同等性レコードは、比較オブジェクトの値およびプロパティを示す。処理は、決定ブロック２２１２に続く。

決定ブロック２２１２で、比較する必要のある他の指定されているオブジェクトが存在するか否かの判別が行われる。他のプロパティがある場合、処理はブロック２２０２にループバックし、上述のように続く。そうでない場合、処理は完了し、終了する。

図２３は、図２１で使用するのに好適な結果を出力するプロセス例を示す流れ図である。プロセス２３００は、ブロック２３０１から始まり、ブロック２３０２に進む。

ブロック２３０２で、参照セット内のオブジェクトが列挙され、「参照専用」レコードが出力される。そのため、これは、対応する比較オブジェクトを持たなかった参照オブジェクトを出力する。処理は、決定ブロック２３０４に続く。

決定ブロック２３０４で、欠損リスト内で識別されたオブジェクトが出力されるべきか否かの決定が行われる。欠損キーオブジェクトを出力しない場合、処理は完了である。そうでない場合、処理は、ブロック２３０６に続く。

ブロック２３０６で、欠損リスト内で識別される参照オブジェクトが出力される。その後、処理は完了し、戻る。

図１７は、順序ベースの比較プロセスを実行するプロセス例を示す論理流れ図である。いくつかの管理タスクでは、順序ベースの比較が、キーベースの比較よりも好ましい。例えば、順序ベースの比較は、アクセス制御リスト（ＡＣＬ）を比較する場合に好ましい。ＡＣＬはユーザの許可およびアクセス権を示すので、これらの権利を分析する順序が重要である。処理はブロック１７０１から始まり、ブロック１７０２に続く。

ブロック１７０２で、参照オブジェクトが取得される。処理はブロック１７０４に続き、そこで、比較オブジェクトが取得される。上述のように、参照オブジェクトおよび比較オブジェクトのデータ型は同じである必要はない。拡張型マネージャは、比較が実行される前に、実行される必要がある変換を処理する。処理は、決定ブロック１７０６として続く。

決定ブロック１７０６で、参照オブジェクトおよび比較オブジェクトのデータ型がテキストであるか否かの判別が行われる。データ型がテキストでない場合（例えば、文字列、ファイル）、処理はブロック１７１２に続く。

ブロック１７１２で、参照オブジェクトおよび比較オブジェクトのプロパティの比較が実行される。手短に言うと、図１８を参照しつつ以下で詳しく説明するが、参照オブジェクトおよび比較オブジェクトのプロパティが値および／または順序について異なる場合に相違点を報告する。処理は、決定ブロック１７１０に続く。

決定ブロック１７１０で、他の比較オブジェクトがあるか否かの判別が行われる。もしあれば、処理はブロック１７０４にループバックし、上述のように進行する。そうでない場合、処理は完了する。

決定ブロック１７０６に戻り、参照オブジェクトおよび比較オブジェクトのデータ型がテキストの場合、処理はブロック１７０８に続く。

ブロック１７０８で、参照オブジェクトと比較オブジェクトとの間のテキスト比較が実行される。手短に言うと、図１９を参照しつつ以下で詳しく説明するが、テキスト比較は、現在利用可能な標準のテキストベースの比較手法と同様の動作をする。処理は、さらに、決定ブロック１７１０に続き、上述のように進行する。図１７は複数の参照オブジェクトを例示していないが、当業者であれば、複数の参照オブジェクトを受け入れるように他の決定ブロックを実装することができることを理解するであろう。

図１８は、図１７に示されている順序ベースのプロセス内で使用するのに好適な順序ベースのオブジェクト比較プロセスを例示する論理流れ図である。処理はブロック１８０１から始まり、ブロック１８０２に進む。

ブロック１８０２で、参照オブジェクトからのプロパティが取得される。この比較は順序依存でないため、通常、プロパティは、逐次的に取得される。処理は、ブロック１８０４に続く。

ブロック１８０４で、比較オブジェクトからのプロパティが取得される。比較オブジェクト内のプロパティが取得される順序は、参照オブジェクト内のプロパティを取得する順序と同じである。処理は、決定ブロック１８０６に続く。

決定ブロック１８０６で、参照プロパティおよび差分プロパティが比較可能か否かの判別が行われる。まず、このプロセスで、参照プロパティの名前が差分プロパティの名前と同じであることを検証する。これは、リフレクションを使用して実行することができる。リフレクションに加えて、本発明の比較手法では、さらに、図１３に例示されている拡張型システムとともに上で説明されているようなプロパティエイリアス機能も備える。そこで、プロパティエイリアス機能を使用することにより、参照オブジェクトおよび比較オブジェクトで異なるプロパティ名は、比較時に同等であるものとして処理することができる。

例えば、いくつかのオブジェクトでは、プロパティ名「ＰｒｏｃｅｓｓＮａｍｅ」を使用して、プロセスの名前に関連付けられているプロパティを識別することができる。他のオブジェクトでは、プロパティ名「Ｎａｍｅ」を使用して、プロセスの名前に関連付けられているプロパティを識別することができる。「Ｎａｍｅ」を「ＰｒｏｃｅｓｓＮａｍｅ」でエイリアスすることにより、これら２つの異なるオブジェクトのプロパティは、比較時に同じものとして処理される。

拡張型システムは、プロパティの１つに対するデータ型を他のプロパティのデータ型と同じものであることを課すことができることに留意されたい。例えば、参照プロパティが整数データ型であり、比較プロパティが文字列データ型の場合、拡張型マネージャは、図１３とともに上で説明されているように文字列を整数値にすることを課すことができる。これは、異なるデータ型であるため相違点によりエラーが発生する厳密なオブジェクト比較とは対照的である。プロパティが直に互いに比較可能でない場合には、処理はブロック１８０８に続く。

ブロック１８０８で、必要な変換が実行され、２つのプロパティの比較を行うことができる。上述のように、これは、データ型の強制などを伴う場合がある。これらのプロパティが比較可能であったら、処理はブロック１８１０に続く。

ブロック１８１０で、２つのプロパティが比較される。上述のように、比較では、カスタム比較機構を使用する、ファジー比較の実行などを行うことができる。これら２つのプロパティが比較された後、処理はブロック１８１２に続く。

ブロック１８１２で、コマンド文字列とともに与えられるスイッチに基づいて相違が報告される。相違は、値および／またはプロパティの順序の違いを含むことができる。処理は、決定ブロック１８１４に続く。

決定ブロック１８１４で、比較する他のプロパティがあるか否かの判別が行われる。オブジェクトの順序ベースの比較では、プロパティの値および／またはプロパティの順序の間の違いを識別することが重要である。他のプロパティがある場合、処理はブロック１８０２にループバックし、上述のように進む。そうでない場合、処理は完了する。

図１９は、図１７に示されている順序ベースのプロセス内で使用するのに好適なテキスト比較プロセスを例示する論理流れ図である。処理はブロック１９０１から始まり、ブロック１９０８に進む。

ブロック１９０８で、テキストを比較し、違いが識別されるまで、またはテキストの終わりになるまで比較を続ける。テキスト比較では、ブロック１９０８でよく知られているテキスト比較手法を使用することができる。相違が検出されるか、または終わりが検出されると、処理は決定ブロック１９１０に続く。

決定ブロック１９１０で、テキストの終わりに達したか否かの判別が行われる。終わりに達した場合、処理はブロック１９１８に続く。そうでない場合、処理は、ブロック１９１２に続く。

ブロック１９１２で、相違の原因となっているテキストに対して検索が実行される。この検索は、参照オブジェクトまたは比較オブジェクトに関連付けられたテキストで実行することができる。検索は、テキストが見つかるか、または指定された同期ウィンドウが完了するまで実行される。同期ウィンドウの使用は、当業者にはよく知られているため、それ以上説明する必要はない。処理は、決定ブロック１９１４に続く。

決定ブロック１９１４で、検索中にテキストが見つかったか否かの判別が行われる。テキストが見つかった場合、処理はブロック１９１６に続き、そこで、参照オブジェクトまたは比較オブジェクトのいずれかの追加テキストに注目するなどで差分レコードが更新される。その後、処理は、ブロック１９０８にループバックし、上述のように進行する。

決定ブロック１９１４でテキストが見つからなかった場合、処理はブロック１９１８に続き、そこで、差分レコードが比較の情報とともに更新される。その後処理は完了する。

図２０では、ｃｏｍｐａｒｅメソッドに対するシステム例を示している。構文２０００は、λ式をサポートする。概要としては、λ式を使用すると、本発明の比較手法により、参照オブジェクトおよび／または比較オブジェクトのプロパティから派生されたキーおよび値に基づいてオブジェクトの２つのセットを比較できるが、これらはオブジェクト自体には存在しない。そのため、拡張型システムでは、値を単に返すだけであるが、むしろ、処理を実行して必要な値を取得することができる。

構文２０００は、図１４とともに上述のパラメータの多くを含む。さらに、構文２０００は、ＲｅｆｅｒｅｎｃｅＫｅｙパラメータ２００２、ＣｏｍｐａｒｉｓｏｎＫｅｙパラメータ２００４、ＲｅｆｅｒｅｎｃｅＶａｌｕｅパラメータ２００６、およびＣｏｍｐａｒｉｓｏｎＶａｌｕｅパラメータ２００８のうちの１つまたは複数を含むことができる。ここでもまた、それらのパラメータはスイッチを含み、そのスイッチに関連付けられたデータを含むことができる。

ＲｅｆｅｒｅｎｃｅＫｅｙパラメータ２００２は、「−ＲｅｆｅｒｅｎｃｅＫｅｙ」スイッチおよび参照キーオブジェクトを含む。参照キーオブジェクトは、各参照オブジェクトのキーを計算する任意の関数、スクリプト、λ式など（以下、λ式と総称する）とすることができる。同様に、ＣｏｍｐａｒｉｓｏｎＫｅｙパラメータ２００４は、「−ＣｏｍｐａｒｉｓｏｎＫｅｙ」スイッチおよび比較キーオブジェクトを含み、比較キーオブジェクトは各比較オブジェクトのキーを計算するλ式とすることができる。

ＲｅｆｅｒｅｎｃｅＶａｌｕｅパラメータ２００６は、「−ＲｅｆｅｒｅｎｃｅＶａｌｕｅ」スイッチおよび参照値オブジェクトを含む。参照値オブジェクトは、各参照オブジェクトの値を計算するλ式とすることができる。同様に、ＣｏｍｐａｒｉｓｏｎＶａｌｕｅパラメータ２００８は、「ＣｏｍｐａｒｉｓｏｎＶａｌｕｅ」スイッチおよび比較値オブジェクトを含む。比較値オブジェクトは、各参照オブジェクトの値を計算するλ式とすることができる。

λ式の使用は、例を見ると最もよく理解できる。そこで、コマンド文字列が上記のプロパティ２００２〜２００８の各々についてλ式を含むと仮定する。さらに、λ式のそれぞれが、対応するオブジェクトのプロパティに基づきデータベース検索を実行すると仮定する。例えば、ＲｅｆｅｒｅｎｃｅＫｅｙパラメータ２００２に関連付けられた参照キーλ式は、プロパティＡに対するデータベース検索の結果を返すことができる。例えば、ＣｏｍｐａｒｉｓｏｎＫｅｙパラメータ２００４に関連付けられた比較キーλ式は、プロパティＢに対するデータベース検索の結果を返すことができる。疑似コードでは、参照キーλ式は、「｛＄ｄｂ．ｆｅｔｃｈ（＄＿．Ａ）｝」として表示することができ、＄ｄｂはデータベースオブジェクトを指し、．ｆｅｔｃｈ（＄＿．Ａ）は拡張型マネージャを使用し入力セット内の単一参照オブジェクトからｆｅｔｃｈメソッドを介してプロパティＡを取り出すことを意味する。同様に、比較キーλ式に対する擬似コードは、「｛＄ｄｂ．ｆｅｔｃｈ（＄＿．Ｂ）｝」として表示されうる。

そこで、図１６〜１９および図２３を参照しつつ上記で説明されている処理の実行時に、キーが取得され、評価されたときに、対応するキーλ式が必ず適用される。キーが等しいか否かのテストでは、上記で説明したのと同じ規則を使用する。しかし、キーの間の実際の比較を実行する他のλ式を指定することもできる。

次に、ｃｏｍｐａｒｅ ｃｍｄｌｅｔは、一致するキーを持つ参照オブジェクトおよび比較オブジェクト毎に、対応する値λ式を適用する。例えば、参照値λ式が「｛＄ｄｂ．ｆｅｔｃｈ（＄＿．Ｃ）｝“」で、比較値λ式が「｛＄ｄｂ．ｆｅｔｃｈ（＄＿．Ｄ）｝」である場合、ｃｏｍｐａｒｅ−ｃｍｄｌｅｔは、＄ｄｂ．ｆｅｔｃｈ（＄Ｒ．Ｃ）の結果を＄ｄｂ．ｆｅｔｃｈ（＄Ｃ．Ｄ）の結果と比較する。ただし、＄Ｒは参照オブジェクト、＄Ｃは比較オブジェクトである。ここでもまた、比較では、オプションの値比較λ式を実行することを含む上述の比較プロセスを使用することができる。

λ式をサポートする他の実施形態では、参照オブジェクトおよび比較オブジェクトのフィルタ処理を行って、λ式から計算されたキーおよび値を入力オブジェクト上にメモとして追加する。本発明の比較手法をサポートするλ式を指定するこれらおよびその他の変更形態は、エラーを識別する際に非常に柔軟に対応できる。

そこで、λ式を使用することにより、異なるオブジェクト型を持ち、共通プロパティを持たない参照オブジェクトは、各参照オブジェクトのキー関数が互換性のある結果を出力し、各参照オブジェクトの値関数が比較可能な結果を出力する限り、比較できる。さらに、各オブジェクトに使用されるキーまたは値関数は、外部システム機能（例えば、データベース検索）を呼び出し、ネットワークオペレーションを実行して、リモートシステムからデータを取り出すことができるいくらでも複雑な計算であってよい。他の改良では、キーまたは値関数は、異なる名前を使用する意味論的に同一のプロパティの比較を行うことができるエイリアス機能を備えることができる。

λ式が指定された場合に生成される出力オブジェクトは、計算されたキーおよび計算された値を生成されたオブジェクトの一部として、またはパススルーモードにおけるオリジナルのオブジェクトへの注釈として含めることができる。これにより、計算された値を使用して、生成された出力をさらに処理できる。他の改良では、キー関数は、入力データから除外すべきデータに対してヌルを返す動作をすることができる。

λ式を適用すると、パススルーモードで実行された１回の比較の出力を別の比較への入力として使用することにより、比較を複数の入力セット（例えば、参照オブジェクト）にまたがって適用することができる。これが実行される場合、オブジェクトのソースを示すプロパティの名前または値が異なることがある。これにより、入力セットの任意のグループ間の相違を追跡することができる。他の変更形態では、複数の入力セットを組み合わせて単一のストリームにすることにより比較を複数の入力集合にまたがって適用することができる。

特定の実装および実施形態の詳細が上で説明されているが、このような詳細は、請求項の範囲を限定するのではなく、法で定められた開示義務を満たすことが意図されている。したがって、請求項により定められている本発明は、上述の特定の機能に限定されない。むしろ、本発明は、付属の請求項の適切な範囲内に収まる形態または修正形態のいずれかで請求され、均一者の原則に従って適宜解釈される。

本発明の比較手法が実装可能なコンピューティング装置例を示す図である。 本発明の比較手法を組み込んだオブジェクトベースの管理ツールフレームワークの概要を一般的に示すブロック図である。 図２に示されているオブジェクトベースの管理ツールフレームワークのプラットフォーム固有コンポーネント内の複数のコンポーネントを例示するブロック図である。 図２に示されているオブジェクトベースの管理ツールフレームワークのコアエンジンコンポーネント内の複数のコンポーネントを例示するブロック図である。 図２に示されているオブジェクトベースの管理ツールフレームワーク内で使用するのに好適なｃｍｄｌｅｔを指定するための一データ構造例を示す図である。 図２に示されているオブジェクトベースの管理ツールフレームワーク内で使用するのに好適なｃｍｄｌｅｔを指定するための一データ構造例を示す図である。 図２に示されているオブジェクトベースの管理ツールフレームワーク内で実行されるホスト処理のプロセス例を示す論理流れ図である。 図２に示されているオブジェクトベースの管理ツールフレームワークでのコマンド文字列の処理を例示する機能流れ図である。 図８に示されているようにコマンド文字列を処理するためのプロセスを例示する論理流れ図である。 図９に示されているコマンド文字列の処理内で使用するのに好適なｃｍｄｌｅｔのインスタンスを作成するプロセス例を示す論理流れ図である。 図９に示されているコマンドの処理内で使用するのに好適なｃｍｄｌｅｔのプロパティに初期値を設定するプロセス例を示す論理流れ図である。 図９に示されているコマンドの処理内で使用するのに好適なｃｍｄｌｅｔを実行するプロセス例を示す論理流れ図である。 図２に示されているオブジェクトベースの管理ツールフレームワーク内で使用するのに好適な拡張型マネージャ例を示す機能ブロック図である。 図２に示されているオブジェクトベースの管理ツールフレームワーク内に実装されている比較ｃｍｄｌｅｔの構文例を示す図である。 生成された結果とともに比較ｃｍｄｌｅｔの呼び出し例を示す図である。 キーベースの比較プロセスを実行するプロセス例を示す論理流れ図である。 順序ベースの比較プロセスを実行するプロセス例を示す論理流れ図である。 図１７に示されている順序ベースのプロセス内で使用するのに好適な順序ベースのオブジェクト比較プロセスを例示する論理流れ図である。 図１７に示されている順序ベースのプロセス内で使用するのに好適な順序ベースのテキスト比較プロセスを例示する論理流れ図である。 ラムダ式を実装する比較ｃｍｄｌｅｔの他の構文例を示す図である。 図１６で使用するのに好適な各比較オブジェクトとのキーベースの比較を実行するプロセス例を示す流れ図である。 図２１で使用するのに好適な参照オブジェクトと比較オブジェクトとの間のプロパティ値を比較するプロセス例を示す流れ図である。 図２１で使用するのに好適な結果を吐き出すプロセス例を示す流れ図である。

符号の説明

１２０ コンポーネントベースのフレームワーク
２００ 管理ツールフレームワーク
５００、６００ ｃｍｄｌｅｔ
８４０、８４２、８４４、８４６ オブジェクト
８４１、８４３、８４５ 入力オブジェクト
１５０２、１５０４ テーブル

Claims (40)

1. 方法を実行するコンピュータ実行可能命令を格納する少なくとも１つのコンピュータ読み取り可能媒体であって、
   参照オブジェクトを取得するステップと、
   少なくとも１つの比較オブジェクトを取得するステップと、
   オブジェクトベースの環境内のコマンド文字列内で指定された少なくとも１つのパラメータに基づいて前記参照オブジェクトと前記少なくとも１つの比較オブジェクトとの間の比較を実行するステップと
   を備えたことを特徴とするコンピュータ読み取り可能媒体。
2. 前記少なくとも１つの比較オブジェクトは、前記オブジェクトベースの環境内で実行されるｃｍｄｌｅｔから生成されることを特徴とする請求項１に記載のコンピュータ読み取り可能媒体。
3. 前記少なくとも１つのパラメータは、キーベースのスイッチおよびキーワードを含み、前記比較は、前記参照オブジェクトおよび前記比較オブジェクトが前記キーワードに関連付けられたプロパティを含むことを確認した後に実行されることを特徴とする請求項１に記載のコンピュータ読み取り可能媒体。
4. 前記少なくとも１つのパラメータは、キーベースのスイッチおよびキーワードを含み、前記キーワードは前記コマンド文字列上で式を指定し、前記式は前記参照オブジェクトに関連付けられた参照キーを生成し、前記比較は前記参照キーと前記比較オブジェクトに関連付けられた比較キーが一致していることを確認した後に実行されることを特徴とする請求項３に記載のコンピュータ読み取り可能媒体。
5. 前記少なくとも１つのパラメータは、プロパティスイッチおよび少なくとも１つのプロパティを含み、前記比較は、前記少なくとも１つのプロパティに対してのみ実行されることを特徴とする請求項１に記載のコンピュータ読み取り可能媒体。
6. 前記少なくとも１つのパラメータは、順序スイッチを含み、前記比較は、順序ベースの方法で実行されることを特徴とする請求項１に記載のコンピュータ読み取り可能媒体。
7. 前記参照オブジェクトおよび前記少なくとも１つの比較オブジェクトは、テキストデータ型を含み、前記比較は、テキスト比較を含むことを特徴とする請求項６に記載のコンピュータ読み取り可能媒体。
8. 前記少なくとも１つのパラメータは、さらに、大文字小文字を区別するスイッチを含み、前記テキスト比較は、大文字小文字を区別することを特徴とする請求項７に記載のコンピュータ読み取り可能媒体。
9. 前記少なくとも１つのパラメータは、さらに、空白類を区別するスイッチを含み、前記テキスト比較は、前記参照オブジェクトおよび前記比較オブジェクトを比較したときに空白類を除外することを特徴とする請求項７に記載のコンピュータ読み取り可能媒体。
10. 前記参照オブジェクトおよび前記少なくとも１つの比較オブジェクトは、非テキストデータ型を含み、前記比較では、前記参照オブジェクトのプロパティの参照値を前記比較オブジェクトの対応するプロパティの比較値と比較することを特徴とする請求項６に記載のコンピュータ読み取り可能媒体。
11. 前記少なくとも１つのパラメータおよび前記比較に基づいて出力レコードを生成するステップをさらに備えたことを特徴とする請求項１に記載のコンピュータ読み取り可能媒体。
12. 前記出力レコードは、前記参照オブジェクトと前記比較オブジェクトとの間の相違を含むことを特徴とする請求項１１に記載のコンピュータ読み取り可能媒体。
13. 前記出力レコードは、前記参照オブジェクトをカプセル化し、前記比較時に識別された相違点は、前記出力レコードに注釈として追加されることを特徴とする請求項１１に記載のコンピュータ読み取り可能媒体。
14. 前記出力レコードは、前記比較オブジェクトをカプセル化し、前記比較時に識別された相違点は、前記出力レコードに注釈として追加されることを特徴とする請求項１１に記載のコンピュータ読み取り可能媒体。
15. 前記比較は、前記コマンド文字列内の式として指定されたカスタム比較を含むことを特徴とする請求項１に記載のコンピュータ読み取り可能媒体。
16. 前記参照オブジェクトの参照値は、前記コマンド文字列内で指定された式により生成され、前記参照値は、前記比較時に前記比較オブジェクトに関連付けられた比較値と比較されることを特徴とする請求項１に記載のコンピュータ読み取り可能媒体。
17. 前記参照オブジェクトの比較値は、前記コマンド文字列内で指定された式により生成され、前記比較値は、前記比較時に前記参照オブジェクトに関連付けられた参照値と比較されることを特徴とする請求項１に記載のコンピュータ読み取り可能媒体。
18. 前記参照オブジェクトは、第１のデータ型であり、前記比較オブジェクトは、第２のデータ型であり、前記データ型の少なくとも一方は、前記参照オブジェクトおよび前記比較オブジェクトが前記比較を実行する前に同じデータ型を持つことを課されることを特徴とする請求項１に記載のコンピュータ読み取り可能媒体。
19. コンピュータ実行可能命令を格納するコンピュータ読み取り可能媒体であって、前記命令は、
    オブジェクトベースの環境のコマンド文字列内でｃｏｍｐａｒｅ ｃｍｄｌｅｔを識別するステップと、
    前記コマンド列内の参照オブジェクトの指定に基づいて参照オブジェクトを取得するステップと、
    前記コマンド列内の比較オブジェクトの指定に基づいて比較オブジェクトを取得するステップと、
    前記参照オブジェクトと前記比較オブジェクトとの間の比較を実行するステップと
    を備えたことを特徴とするコンピュータ読み取り可能媒体。
20. 前記比較の結果として差分レコードを生成するステップをさらに備えたことを特徴とする請求項１９に記載のコンピュータ読み取り可能媒体。
21. 前記差分レコードは、前記ｃｏｍｐａｒｅ ｃｍｄｌｅｔからパイプラインで送られる他のｃｍｄｌｅｔに入力として供給されることを特徴とする請求項２０に記載のコンピュータ読み取り可能媒体。
22. 前記コマンド文字列内の式を取得し、前記式が前記参照オブジェクトと前記比較オブジェクトとの間で実行すべき前記比較を識別するステップをさらに備えたことを特徴とする請求項１９に記載のコンピュータ読み取り可能媒体。
23. 前記コマンド文字列内の式を取得し、前記式が、前記比較を実行するために必要な前記参照オブジェクトのプロパティを識別するキーワードを生成するステップをさらに備えたことを特徴とする請求項１９に記載のコンピュータ読み取り可能媒体。
24. 前記コマンド文字列内の式を取得し、前記式は前記参照オブジェクトの参照値を生成し、前記参照値が、前記比較時に前記比較オブジェクトに関連付けられた比較値と比較されるステップをさらに備えたことを特徴とする請求項１９に記載のコンピュータ読み取り可能媒体。
25. 指定されたプロパティを取得し、前記指定されたプロパティが、前記比較を実行する際に比較される前記参照オブジェクトおよび前記比較オブジェクトの特定のプロパティを識別するステップをさらに備えたことを特徴とする請求項１９に記載のコンピュータ読み取り可能媒体。
26. 前記比較は、順序ベースの方法で実行されることを特徴とする請求項１９に記載のコンピュータ読み取り可能媒体。
27. 前記参照オブジェクトは、第１のデータ型であり、前記比較オブジェクトは、第２のデータ型であり、前記参照オブジェクトは、前記比較の前に前記第２のデータ型を課されることを特徴とする請求項１９に記載のコンピュータ読み取り可能媒体。
28. 前記参照オブジェクトは、第１のデータ型であり、前記比較オブジェクトは、第２のデータ型であり、前記比較オブジェクトは、前記比較の前に前記第１のデータ型を課されることを特徴とする請求項１９に記載のコンピュータ読み取り可能媒体。
29. 前記参照オブジェクトは、第１のデータ型であり、前記比較オブジェクトは、第２のデータ型であり、前記参照オブジェクトおよび前記比較オブジェクトは、前記比較の前に同じデータ型を持つことを課されることを特徴とする請求項１９に記載のコンピュータ読み取り可能媒体。
30. プロセッサと、
    複数の命令がロードされるメモリであって、前記複数の命令は、
    参照オブジェクトを取得するステップと、
    少なくとも１つの比較オブジェクトを取得するステップと、
    オブジェクトベースの環境内のコマンド文字列内で指定された少なくとも１つのパラメータに基づいて前記参照オブジェクトと前記少なくとも１つの比較オブジェクトとの間の比較を実行するステップと
    を含むメモリと
    を備えたことを特徴とするシステム。
31. 前記少なくとも１つの比較オブジェクトは、前記オブジェクトベースの環境内で実行されるｃｍｄｌｅｔから生成されることを特徴とする請求項３０に記載のシステム。
32. 前記比較は、前記参照オブジェクトおよび前記比較オブジェクトが前記コマンド文字列上で指定されたキーワードに関連付けられたプロパティを含むことを確認した後に実行されることを特徴とする請求項３０に記載のシステム。
33. 前記少なくとも１つのパラメータは、プロパティスイッチおよび少なくとも１つのプロパティを含み、前記比較は、前記参照オブジェクトおよび前記比較オブジェクト内の前記少なくとも１つのプロパティに対してのみ実行されることを特徴とする請求項３０に記載のシステム。
34. 前記少なくとも１つのパラメータは、順序スイッチを含み、前記比較は、順序ベースの方法で実行されることを特徴とする請求項３０に記載のシステム。
35. 前記少なくとも１つのパラメータおよび前記比較に基づいて出力レコードを生成する手段さらに備えたことを特徴とする請求項３０に記載のシステム。
36. 前記出力レコードは、前記参照オブジェクトと前記比較オブジェクトとの間の相違を含むことを特徴とする請求項３４に記載のシステム。
37. 前記出力レコードは、前記参照オブジェクトをカプセル化し、前記比較時に識別された相違点は、前記出力レコードに注釈として追加されることを特徴とする請求項３５に記載のシステム。
38. 前記比較は、前記コマンド文字列内の式として指定されたカスタム比較を含むことを特徴とする請求項３０に記載のシステム。
39. 前記参照オブジェクトの参照値は、前記コマンド文字列内で指定された式により生成され、前記参照値は、前記比較時に前記比較オブジェクトに関連付けられた比較値と比較されることを特徴とする請求項３０に記載のシステム。
40. 前記参照オブジェクトは、第１のデータ型であり、前記比較オブジェクトは、第２のデータ型であり、前記データ型の少なくとも一方は、前記参照オブジェクトおよび前記比較オブジェクトが前記比較を実行する前に同じデータ型を有することを課されることを特徴とする請求項３０に記載のシステム。
    
    

Images