JP2004342108A - コマンドへの入力パラメータに対するリフレクションベース処理 - Google Patents

Abstract

【課題】 コマンドについての入力パラメータをリフレクションベースで処理することを可能にするリフレクションベースのシェルを提供すること。
【解決手段】 リフレクションベースの処理には、解析、データ生成、データ妥当性検査、オブジェクトエンコーディング、オブジェクト処理、文書化などが含まれる。リフレクションベースのシェルは、クラスを使用して入力パラメータに関する文法を指定するための機構を提供する。この方法は、コマンドと少なくとも１つのパラメータとを含む解析可能ストリームを受け取ること、コマンドについての予想されるパラメータを記述する定義情報を取り出すこと、定義情報を使用して、予想されるパラメータの記述に従ったフォーマットで少なくとも１つのパラメータを記憶するためのオブジェクトを生成すること、および、オブジェクトをコマンドに渡すことを含む。
【選択図】 図２

Description

本発明は、コマンドについての入力パラメータをリフレクションベースで処理することを可能にするリフレクションベースのシェルに関する。

マルチユーザコンピュータシステムのシステム管理は、非常に専門化されている。システム管理を担うシステム管理者は、一貫性のない構文やエラー報告などを使用するコマンドを知って理解することが求められる。コマンド間におけるこれらの非一貫性は、コマンドが複数の異なるソフトウェア開発者によって書かれ、各開発者が独自のスタイルを使用するために生じる。これらの非一貫性は、システム管理者にとって困難を引き起こす。

困難の１つは、コマンドのユーザビリティに関係がある。一貫性のないコマンドがあることにより、システム管理を学習し用いることは、より難しくなる。例えば、パラメータ間にダッシュ（「−」）を使用するのを好む開発者もいれば、フォワードスラッシュ（「／」）を好む開発者もおり、さらに別の独特の構文を使用するのを好む開発者もいる。また、開発者はそれぞれ、エラーメッセージの報告でも独自のスタイルを持っていることがある。したがってシステム開発者は、各コマンドごとの構文を知り、各エラーメッセージごとのフォーマットを学習しなければならない。

もう１つの困難は、コマンドの維持に関係がある。例えば、コマンドの１つを書いた開発者が去ってしまったときは、他の誰かが、使用されたロジックを発見しなければならない。ロジックを発見するために、他の開発者は、コード自体を見るか、またはコマンドに関する資料を見なければならない。これらの方法はどちらも、あまり望ましいものではない。

コマンドをより一貫性のあるものにしようとする従来の試みは、共通の機能を実施するルーチンのライブラリを提供することに焦点を合わせていた。このライブラリは、ライブラリルーチンによって提供される共通の機能を実施するのに使用されるコードの量を削減することができるが、開発者はやはり、いずれかのライブラリルーチンを使用することで生じるエラー状況を処理する際に、独自のスタイルを使用する。さらに、ライブラリを使用しても、コマンドラインから入力パラメータを得るためのロジックを各コマンドが含む必要があることには変わりない。このため、ルーチンのライブラリを使用すると、書く必要のあるコードのいくらかを削減することはできるが、依然として、解析、データ妥当性検査、およびエラー報告を実施するために各コマンドごとに生成される重複コードはかなりある。

したがって、コマンドへの入力パラメータがより一貫性のある方式で獲得および処理されると共に、コマンドに必要なコードの量が削減され、すべてのコマンドについてのパラメータ獲得段階の間に一貫性のあるエラーメッセージが提供される環境が必要とされている。

本発明は、コマンドについての入力パラメータをリフレクションベースで処理することを可能にするリフレクションベースのシェルを対象とする。リフレクションベースの処理には、解析、データ生成、データ妥当性検査、オブジェクトエンコーディング、オブジェクト処理、文書化などが含まれる。このリフレクションベースのシェルは、クラスを使用して入力パラメータに関する文法を指定するための機構を提供する。第三者の開発者は、クラスを使用して、自分のコマンドに関する文法を指定する。動作時、本発明は、解析可能ストリームを受け取る。解析可能ストリームは、コマンドライン、音声入力、スクリプトなどから得ることができる。解析可能ストリームは、コマンドと、少なくとも１つのパラメータを含む。解析可能ストリームに基づき、コマンドについての予想されるパラメータを記述する定義情報を取り出す。定義情報を使用して、オブジェクトを生成する（すなわち開発者はクラスのインスタンスを生成する）。オブジェクトは、少なくとも１つのパラメータを、予想パラメータの記述に従ったフォーマットで記憶する。次いで、オブジェクトはコマンドに渡され、コマンドはそれ自体の固有の処理を行う。定義情報は、どのようにパラメータを予想パラメータにマッピングするか、どのようにパラメータを得るか（例えば対話式）など、解析可能ストリームに対して実施されるアクションを指定する命令（ディレクティブ：directive）を含むものとすることができる。命令はまた、解析、妥当性検査、文書化、データ生成、およびデータ処理に関係するアクションを含むものとすることもできる。

したがって、本発明の利点の１つは、コマンド開発者が、自分のコマンドへの入力パラメータを得るためにコマンドラインを解析するロジック、または入力パラメータを妥当性検査するロジックを書く必要なしに、入力パラメータに関する文法を容易に指定できることである。このようにすることで本発明は、開発者が書く必要のあるコードの量を削減し、コマンドに関する構文を、より一貫性のある、しかも非常に用途の広いものにすることができる。

簡単に言えば、本発明は、コマンドについての入力パラメータをリフレクションベースで処理することを可能にするリフレクションベースのシェルを対象とする。以下の詳細な記述を読んだ後には明らかになるであろうが、本発明は、第三者の開発者が書く必要のあるコードの量を最小限に抑え、システム管理者がシステム管理作業を実施するために知る必要のある知識の量を最小限に抑える。したがって本発明は、システム管理作業を大幅に削減する。さらに本発明は、入力パラメータに関するより一貫性のある構文を提供し、入力パラメータに関連する処理のために共通の機能を提供する。

図１に、本発明の例示的な一実施形態で使用することのできる例示的なコンピューティングデバイスを示す。ごく基本的な一構成では、コンピューティングデバイス１００は通常、少なくとも１つの処理ユニット１０２およびシステムメモリ１０４を備える。コンピューティングデバイスの正確な構成および種類に応じて、システムメモリ１０４は、揮発性（ＲＡＭなど）、不揮発性（ＲＯＭやフラッシュメモリなど）、またはこの２つの何らかの組合せとすることができる。システムメモリ１０４は通常、オペレーティングシステム１０５および１つまたは複数のプログラムモジュール１０６を含み、プログラムデータ１０７も含むことができる。オペレーティングシステム１０５は、オペレーティングシステムコマンドを実行するコマンドプロセッサ１３０を含む。コマンドプロセッサ１３０は、オペレーティングシステムコマンドを受け入れるシェル１３１（すなわちコマンドプロセッサインターフェース）を含む。シェルは、コマンドプロンプトを表示することができ、また、グラフィカルユーザインターフェース、またはユーザ入力を入力し解釈するためのその他任意の手段を表示することができる。シェル１３１は、入力されたコマンドが有効であることを検証し、検証したコマンドを、実行に向けてコマンドプロセッサ１３０の別の部分に送る。図１では、この基本的な構成を破線１０８内のコンポーネントで示す。

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

コンピューティングデバイス１００はまた、ネットワークなどを介して他のコンピューティングデバイス１１８と通信することを可能にする通信接続１１６を備えることもできる。通信接続１１６は、通信媒体の一例である。通信媒体は通常、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータによって、搬送波やその他のトランスポート機構などの変調データ信号に組み入れることができ、任意の情報送達媒体が含まれる。「変調データ信号」という用語は、情報が信号中に符号化される形で１つまたは複数の特性が設定または変更された信号を意味する。限定ではなく例として、通信媒体には、配線式ネットワークや直接配線式接続などの配線式媒体と、音響、無線周波、赤外線、その他の無線媒体などの無線媒体とが含まれる。本明細書で使用するコンピュータ可読媒体という用語には、記憶媒体と通信媒体の両方が含まれる。

図２は、本発明による、リフレクションベースのシェル２００内のパーサ２０２およびエンジン２０４を介したコマンドライン２５０の処理を示す機能流れ図である。例示的なコマンドライン２５０は、複数のコマンド（すなわちｐｒｏｃｅｓｓコマンド２６０、ｗｈｅｒｅコマンド２６２、ｓｏｒｔコマンド２６４、ｔａｂｌｅコマンド２６６）をパイプラインしている。ただし、以下の考察では、１つのコマンド（例えばｗｈｅｒｅコマンド）についての入力パラメータをリフレクションベースで処理することに焦点を合わせる。他のコマンドに対するリフレクションベース処理も、同様にして行われる。コマンドライン２５０は、任意のコマンドに入力パラメータを渡すことができる（例えばｗｈｅｒｅコマンド２６２に「ｈａｎｄｌｅｃｏｕｎｔ＞４００」を渡す）。ｐｒｏｃｅｓｓコマンド２６０には、関連する入力パラメータがないことに気付くであろう。従来は、各コマンドが、そのコマンドに関連する入力パラメータを解析して、入力パラメータが有効かどうかを決定し、有効でない場合はエラーメッセージを発行することを担っていた。コマンドは通常、様々なプログラマによって書かれていたので、コマンドライン上の入力パラメータに関する構文は、あまり一貫性のあるものではなかった。さらに、エラーが発生した場合のエラーメッセージは、同じエラーに対してであっても、コマンド間であまり一貫性のあるものではなかった。

例えばＵｎｉｘ（登録商標）環境では、「Ｉｓ」コマンドと「ｐｓ」コマンドの間に、多くの非一貫性がある。両方ともオプション「−ｗ」を受け入れるが、「Ｉｓ」コマンドは、「−ｗ」オプションを使用してページ幅を示し、「ｐｓ」コマンドは、「−ｗ」オプションを使用して印刷幅出力を示す（本質的にページ幅は無視する）。「Ｉｓ」コマンドと「ｐｓ」コマンドに関連するヘルプページにもいくつかの非一貫性がある。例えば、一方はオプションを太字にするが他方はそうではなく、一方はオプションをアルファベット順にソートするが他方はそうではなく、いくつかのオプションはダッシュを必要とするが他はそうではないなどである。

以下に詳述するように、本発明は、より一貫性のある手法を提供し、各開発者が書かなければならない重複コードの量を最小限に抑える。リフレクションベースのシェル２００は、構文（例えば文法）、対応するセマンティクス（例えば辞書）、および参照モデルを提供して、リフレクションベースのシェル２００によって提供される共通機能を開発者が容易に利用できるようにする。

本発明についてさらに述べる前に、本明細書全体を通して出てくる用語の定義を示す。「コマンド」は、スタンドアロンの実行可能プログラムを指す。「コマンドレット（ｃｏｍｍａｎｄｌｅｔまたはｃｍｄｌｅｔ）」は、コマンドよりもかなり小さいプログラムを指す。一実施形態では、各コマンドレットは、名詞と動詞の対（例えばコマンドライン２５０中のｇｅｔ／ｐｒｏｃｅｓｓ）を定義する。以下の考察では、本発明によって書かれたコマンドについて言うとき、用語コマンドレットを使用する。ただし場合によっては、より一般的な用語「コマンド」を使用してコマンドレットを指すこともできる。入力パラメータは、コマンドレットについての入力フィールドを指す。引数は、ａｒｇｖアレイ中の単一のストリングと等価な、またはＲｅｑｕｅｓｔＯｂｊｅｃｔ中の単一の要素として渡される、コマンドまたはコマンドレットに渡される入力パラメータを指す。後述するように、ＲｅｑｕｅｓｔＯｂｊｅｃｔは、コマンドレットに関する文法を指定する機構を指す。引数は、オプションと、オプション−引数と、コマンド−名前に続くオペランドとのうちの１つである。引数の例を、以下のコマンドラインに基づいて示す。
findstr/i/d:＼winnt;＼winnt＼system32aa*b.*ini

このコマンドラインで、「ｆｉｎｄｓｔｒ」は引数０であり、「／ｉ」は引数１であり、「／ｄ：＼ｗｉｎｎｔ；＼ｗｉｎｎｔ＼ｓｙｓｔｅｍ３２」は引数２であり、「ａａ＊ｂ」は引数３であり、「＊．ｉｎｉ」は引数４である。「オプション」は、プログラムのデフォルト挙動の変更を指定するのに一般に使用される、コマンドまたはコマンドレットへの引数である。引き続き上の例示的なコマンドラインを参照すると、「／ｉ」および「／ｄ」はオプションである。「オプション−引数」は、一定のオプションに続く入力パラメータである。いくつかの場合では、オプション−引数は、オプションと同じ引数ストリング内に含まれる。他の場合では、オプション−引数は、次の引数として含まれる。やはり上のコマンドラインを参照すると、「ｗｉｎｎｔ；＼ｗｉｎｎｔ＼ｓｙｓｔｅｍ３２」はオプション−引数である。「オペランド」は、プログラム処理を完了させるのに必要な情報をプログラムに供給するオブジェクトとして一般に使用される、コマンドまたはコマンドレットへの引数である。オペランドは一般に、コマンドライン中のオプションに続く。再び、上の例示的なコマンドラインを参照すると、「ａａ＊ｂ」および「＊．ｉｎｉ」はオペランドである。「解析可能ストリーム」は、引数を含む。

「クラスメンバ」は、サブクラス、フィールド、定数、メソッド、構造、プロパティ、アレイ、インデクサ、インターフェース、イベント、例外などの要素を指す。「命令」は、メタデータ属性を指す。「カテゴリ」は、命令の１組の特定の型を指す。後で詳細に説明するが、本発明のリフレクションベースのシェルは、解析命令やデータ生成命令など、いくつかのカテゴリの命令を提供する。各カテゴリ内で、リフレクションベースのシェルは複数の命令を提供する。カテゴリおよび命令は、ソフトウェア開発者によって拡張することができる。

図２を参照すると、パーサ２０２は、解析可能ストリーム（例えばコマンドライン２５０）をＲｅｑｕｅｓｔＯｂｊｅｃｔ２２０〜２２６（例えばｗｈｅｒｅ要求２２２）に解析する。各ＲｅｑｕｅｓｔＯｂｊｅｃｔ２２０〜２２６は、コマンドレット２６０〜２６６のうちの１つに関連する。後で図３に関して詳述するが、簡単に言えば、ＲｅｑｕｅｓｔＯｂｊｅｃｔ２２０〜２２６は、コマンドレットへの入力パラメータに関する文法を開発者が指定するための手段または機構を提供する。ＲｅｑｕｅｓｔＯｂｊｅｃｔは、対応するコマンドレット実行ファイル（例えばｗｈｅｒｅ実行ファイル２３２）に渡される。ただし、後で図４に関して述べるように、パーサ２０２およびエンジン２０４は、ＲｅｑｕｅｓｔＯｂｊｅｃｔをコマンドレット実行ファイルに渡す前に、コマンドライン２５０上で指定された入力パラメータに対して様々な処理を実施する。処理には、解析、パラメータ妥当性検査、データ生成、パラメータ処理、パラメータエンコーディング、パラメータ文書化が含まれる。パーサ２０２およびエンジン２０４がコマンドライン上の入力パラメータに対して共通機能を実施するので、リフレクションベースのシェル２００は、一貫性のあるエラーメッセージをユーザに発行することができる。理解されるように、本発明によって書かれた実行可能コマンドレット２３０〜２３６は、必要なコードが従来のシステムにおけるコマンドよりも少ない。各実行可能コマンドレット２３０〜２３６は、対応するＲｅｑｕｅｓｔＯｂｊｅｃｔ２２０〜２２６を受け入れる。さらに、各実行可能コマンドレット２３０〜２３６は、パイプラインされた次のコマンドレットに入力されるオブジェクトを出力する。通常、これらのオブジェクトは、そのオブジェクトへの参照（例えばハンドル）を渡すことによって入力される。次いで、実行可能コマンドレット２３０〜２３６は、渡されたオブジェクトに対して追加の処理を実施することができる。

図３は、コマンドレットへの入力パラメータに関する文法を指定するためのデータ構造３００の一実施形態である。本質的に、データ構造３００は、リフレクションベースのシェルとコマンドレットとの間の規約を明確に表す手段を提供するものである。以下の考察では、米国ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって生み出された．ＮＥＴ Ｆｒａｍｅｗｏｒｋを用いて本発明について述べる。ただし、本発明の範囲を逸脱することなく、他の環境を使用することもできる。

ソフトウェア開発者は、データ構造３００を、対応する実行可能コマンドレットについてのコード内にコーディングする。実際には、この要求を実行するメソッドおよびプロパティが、どんな入力パラメータがコマンドラインを介してユーザに呈示されるかを定義する。データ構造３００は、ＲｅｑｕｅｓｔＯｂｊｅｃｔクラス３０４から派生する公開クラスである。ソフトウェア開発者は、データ構造３００のクラス名３０２を提供する。クラス名３０２は、このコマンドレットに対してコマンドライン上で指定される引数の名前を識別する。各コマンド名３０２は、図２に示した例示的なコマンドライン２００中の「ｇｅｔ／ｐｒｏｃｅｓｓ」や「ｆｏｒｍａｔ／ｔａｂｌｅ」など、動詞／名詞の対を表す。「ｗｈｅｒｅ」コマンドなどのように、動詞または名詞がコマンド名の中で暗黙的な場合もある。一実施形態では、クラス名３０２がコマンドレットと同一ではないことに気付くであろう。その実施形態では、他の注釈を使用してコマンドレットの名前を識別する。データ構造３００は、少なくとも１つの公開メンバ（例えばＮａｍｅ３３０）を含む。公開メンバ３３０、３３２は、コマンドレットに関連する入力パラメータを表す。各公開メンバ３３０、３３２は、解析命令３１０、データ妥当性検査命令３１２、データ生成命令３１４、処理命令３１６、エンコーディング命令３１８、文書化命令３２０の各カテゴリの中の、１つまたは複数の命令を有することができる。命令は、角括弧で囲まれ、それらに続く入力パラメータを記述する。ユーザ対話型の命令など、いくつかの命令は、クラスレベルでも適用される場合がある。データ構造３００は、パーサによって入力パラメータとして認識されない非公開メンバ３４０を含むこともできる。非公開メンバ３４０は、命令の１つに基づいて生成されたデータを記憶するのに使用することができる。

公開メンバの名前をコマンドライン上で使用して、コマンドライン上の入力パラメータを修飾することができる。他の場合では、公開メンバを使用して、入力パラメータをコマンドライン上におけるその位置に基づいて記憶することができる。以下はこの概念を示す例であり、ＲｅｑｕｅｓｔＯｂｊｅｃｔは以下のようになる。

ＰａｒｓｉｎｇＰａｒａｍｅｔｅｒＰｏｓｉｔｉｏｎＡｔｔｒｉｂｕｔｅは、どのように非修飾パラメータを位置に基づいてマッピングするかを記述する解析命令である。前述のように、非修飾パラメータは、入力パラメータに関連して公開メンバ名を使用しないパラメータである。以下は、上の解析命令を「Ｔｏ」および「Ｆｒｏｍ」メンバに適用した後の適切な構文である。

以下の構文は無効になる。

後述するように、その他の命令も、コマンドライン上で指定された入力パラメータの処理に影響を与える。このように、命令を使用することによってコマンドレット開発者は、自分のコマンドレットへの入力パラメータに関する文法を容易に指定することができ、基礎をなすロジックを生成する必要なしに、入力パラメータに対する処理を実施することができる。

命令は、コマンドレットに関連するメタデータ中に記憶される。後で図４に関して述べるが、メタデータ処理は、リフレクションベースのシェル全体に分散する。例えば、適用可能性命令、文書化命令、および解析ガイドライン命令は、パーサ内で非常に早い段階で処理される。データ生成命令および妥当性検査命令は、パーサがすべての入力パラメータを解析し終えた後で、エンジン中で処理される。

以下のテーブルに、様々なカテゴリについての代表的な命令を、命令に応答してリフレクションベースのシェルによって実施される処理の説明と共に示す。

．ＮＥＴ Ｆｒａｍｅｗｏｒｋを使用する実施形態では、各カテゴリは、基本カテゴリクラス（例えばＣｍｄＡｔｔｒｉｂｕｔｅ）から派生するベースクラスを有する。基本カテゴリクラスは、Ｓｙｓｔｅｍ．Ａｔｔｒｉｂｕｔｅクラスから派生する。各カテゴリは、カテゴリ処理中にパーサによって呼び出される事前定義済みの関数（例えばａｔｔｒｉｂ．ｆｕｎｃ（））を有する。コマンドレット開発者は、カスタムカテゴリクラス（例えばＣｍｄＣｕｓｔｏｍＡｔｔｒｉｂｕｔｅ）から派生するカスタムカテゴリを生み出すことができる。コマンドレット開発者はまた、カテゴリについての基本カテゴリクラスから命令クラスを得ることにより、既存のカテゴリクラスを拡張し、事前定義済みの関数を自分の実装でオーバーライドすることもできる。コマンドレット開発者はまた、命令をオーバーライドして、事前定義済みの命令セットに新しい命令を追加することもできる。

これらの命令を処理する順序は、パーサからアクセスできる外部データ記憶域に記憶することができる。リフレクションベースのシェルは、登録済みのカテゴリを探し、カテゴリ中の各命令ごとに関数（例えばＰｒｏｃｅｓｓＣｕｓｔｏｍＤｉｒｅｃｔｉｖｅ）を呼び出す。したがって、カテゴリ実行情報を持続的な記憶域に記憶しておくことにより、カテゴリ処理の順序は動的とすることができる。種々の処理段階で、パーサは、持続的な記憶域をチェックして、その時点で実行する必要のあるメタデータカテゴリがあるかどうかを決定する。この実施形態では、持続的な記憶域からカテゴリエントリを削除することによって、カテゴリを容易に非推奨とすることができる。

図４は、コマンドについて入力された入力パラメータを処理するプロセス４００を示す論理流れ図である。この時点で、コマンドレッドは開発済みであり、メタデータは、図３のＲｅｑｕｅｓｔＯｂｊｅｃｔを使用してコマンドレットソースファイルに挿入されている。コマンドレットは、コンパイルされて登録されている。登録中に、クラス名（すなわちコマンドレット名）が登録記憶域に書き込まれている。プロセス４００はブロック４０１で開始し、リフレクションベースのシェルは、コマンドレットを示す入力（例えばキーストローク）を受け取った。リフレクションベースのシェルは、入力をレジストリ内から調べて、タイプされた入力を登録済みコマンドレットの１つに関連付けることによって、入力をコマンドレットとして認識することができる。処理はブロック４０２に進む。

ブロック４０２において、識別されたコマンドレットに関連するクラスを識別する。このクラスもまたレジストリを介して識別することができる。処理はブロック４０４に進む。

ブロック４０４において、クラスに関連するメタデータを読み取る。メタデータは、コマンドレットに関連するいずれかの命令を含む。命令は、コマンドレット自体、またはＲｅｑｕｅｓｔＯｂｊｅｃｔ中で指定された１つまたは複数のパラメータに適用することができる。コマンドレット登録中に、登録コードは、メタデータを持続的な記憶域に登録する。メタデータは、シリアライズされたフォーマットのＸＭＬファイルや、外部データベースなどに記憶することができる。上の表に示したように、メタデータ中で指定された命令はそれぞれ、適用可能性命令や解析ガイドライン命令などのカテゴリに関連する。各カテゴリの命令は、リフレクションベースのシェル中の様々な段階で処理される。各メタデータ命令は、それ自体のエラー処理を扱う。処理はブロック４０６に進む。

ブロック４０６において、識別されたクラスに基づいてＲｅｑｕｅｓｔＯｂｊｅｃｔをインスタンス化する。処理はブロック４０８に進む。

ブロック４０８において、ＲｅｑｕｅｓｔＯｂｊｅｃｔに対してリフレクションを実施して、入力パラメータに関する情報を得る。リフレクションベースのシェルは、リフレクションデータを（必要に応じて）呼出し元に返すための共通インターフェースを提供する。前述の実施形態では、リフレクションは．ＮＥＴリフレクションを使用する。処理はブロック４１０に進む。

ブロック４１０において、適用可能性命令（例えば表１）を適用する。適用可能性命令は、クラスが一定のマシンロールおよび／またはユーザロールで使用されるようにする。例えば、いくつかのコマンドレットは、ドメイン管理者だけしか使用することができない。適用可能性命令の１つにおいて指定された制約が満たされない場合は、エラーが発生する。処理はブロック４１２に進む。

ブロック４１２において、メタデータを使用してインテリセンスを提供する。処理のこの時点で、コマンドライン全体はまだ入力されていない。しかし、リフレクションベースのシェルには、コマンドレットに関連するＲｅｑｕｅｓｔＯｂｊｅｃｔに対してリフレクションを介して許容される入力パラメータがわかっている。したがって、入力パラメータを一義化する部分がコマンドライン上でタイプ入力されると、リフレクションベースのシェルは、エンジンを介して、入力パラメータをオートコンプリートすることができる。オートコンプリートは、入力されたパラメータの一部が入力パラメータのうちの１つを一義的に識別するようになればすぐに行うことができる。処理はブロック４１４に進む。

ブロック４１４において、コマンドレットについての入力パラメータの入力が終わるまで待機する。これは通常、ユーザがリターンキーを押すなどしてコマンドラインの終わりを示すと発生する。処理はブロック４１６に進む。

ブロック４１６において、解析ガイドライン命令を適用し、ＲｅｑｕｅｓｔＯｂｊｅｃｔインスタンスを入力パラメータでポピュレートする。パーサは、解析中に使用する規則のセットを有する。規則セットは、ＲｅｑｕｅｓｔＯｂｊｅｃｔデータ構造中で指定された文法がコマンドライン上の入力パラメータに関する構文に変換される方式を指定する。例えば、コマンドＦｏｏに関する以下のＲｅｑｕｅｓｔＯｂｊｅｃｔ宣言があるとする。

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

規則セットは、所望の構文を生み出すためにシステム管理者によって修正することができる。さらに、パーサは複数の規則セットをサポートすることができ、それによりユーザは複数の構文を使用することができる。したがって、ＲｅｑｕｅｓｔＯｂｊｅｃｔ構造中で指定された文法（例えばｓｔｒｉｎｇＮａｍｅやＢｏｏｌ Ｒｅｃｕｒｓｅ）がパーサを駆動する。

一般に、解析命令は、コマンドライン上に入力されたパラメータがどのようにＲｅｑｕｅｓｔＯｂｊｅｃｔ中で識別される予想パラメータにマッピングすべきかを記述する。以下の例に、位置情報を指定する解析命令を示す。

入力パラメータ型をチェックして、正しいかどうかを決定する。入力パラメータ型が正しくない場合は、入力パラメータを強制的に正しくすることができる。入力パラメータが正しくなく、かつ強制的に正しくすることができない場合は、使用エラーをプリントする。使用エラーにより、ユーザは、予想される正しい構文を認識することができる。使用エラーの場合は、この構文を記述する情報を文書化命令４１８から得ることができる。入力パラメータ型をマッピングするかまたは検証した後、ＲｅｑｕｅｓｔＯｂｊｅｃｔインスタンス中の対応するメンバをポピュレートする。処理は決定ブロック４２０に進む。

決定ブロック４２０において、ユーザとの対話を必要とする入力パラメータがあるかどうかを決定する。ユーザ対話を必要とするパラメータがある場合は、処理はブロック４２２に進む。そうでない場合はブロック４２４に進む。

ブロック４２２において、リフレクションベースのシェルは、ユーザと対話して入力パラメータを得る。開発者は、ＲｅｑｕｅｓｔＯｂｊｅｃｔ中でパラメータについてＣｍｄＰｇＲｅｑｕｉｒｅＩｎｔｅｒａｃｔｉｏｎ命令を指定することにより、入力パラメータがユーザ対話を介して得られることを指定することができる。さらに、リフレクションベースのシェルは、すべての入力パラメータがコマンドライン上に入力されていない場合にも、ユーザ対話が必要であると決定することができる。入力パラメータ、コマンドレッド自体、およびその他の設定のせいで対話が不可能にならない限り、リフレクションベースのシェルは、ユーザと対話して必要な入力パラメータを得ることになる。フラグを使用して、ユーザ対話がユーザレベル、グループレベル、および企業レベルで許可されるかどうかを指定することができる。レベルの１つがユーザ対話を許可しない場合は、エラーメッセージが発行される。ユーザ対話が実施されると、処理はブロック４２４に進む。

ブロック４２４において、エンジンは、ＲｅｑｕｅｓｔＯｂｊｅｃｔインスタンスに対して別のパスを実施して、いずれかの残りの命令を入力パラメータに適用する。残りの命令には、データ生成命令、データ妥当性検査命令、オブジェクト処理命令、およびオブジェクトエンコーディング命令が含まれる。これらの命令は、パーサが入力パラメータの解析を終えた後で、エンジン中で処理される。次に、上の表３〜５に示した各カテゴリからの代表的な命令について述べる。

第１の代表的な命令は、データ生成命令からのものである。ＲｅｑｕｅｓｔＯｂｊｅｃｔは、以下のステートメントを含むことができる。

Ａｒｒａｙｌｉｓｔ Ｆは非公開なので、パーサは、この宣言をコマンドレットへの入力パラメータとして扱わない。そうではなく、Ａｒｒａｙｌｉｓｔ Ｆは、データ生成命令中で指定されたサービスによって生成されるデータのための一時的な記憶域である。この例では、サービスは「Ｆｉｌｅｎａｍｅ」である。Ｆｉｌｅｎａｍｅは、リフレクションベースのフレームワークによって提供されるユーティリティ、あるいは第三者の機能またはユーティリティとすることができる。エンジンがこの命令に遭遇すると、エンジンは、「Ｆｉｌｅｎａｍｅ」という名前のサービスをレジストリ中で識別する。サービスの登録は、サービスのインストール中に行われる。データ生成命令は、入力パラメータに対して固有の処理を行うことを可能にする。例えばサービスは、コマンドライン上で「Ａ＊」として入力されたファイル名に対するワイルドカード拡張を実施することができる。第２のパスの前に、「Ａ＊」がコマンドライン上に入力されたので、Ｎａｍｅメンバは「Ａ＊」を含む。第２のパスの間、Ｆｉｌｅｎａｍｅサービスは、Ａで始まるファイルのセットを突き止め、それらをＡｒｒａｙｌｉｓｔ Ｆに記憶することができる。当業者なら理解するであろうが、データ生成命令は、ファイル名のワイルドカーディング拡張を提供するだけでなく、ユーザ名やプロセスなどのワイルドカード拡張を実施することもできる。さらに、データ生成命令は、入力パラメータに対してその他の処理を実施することもできる。

例示的なデータ妥当性検査命令は、以下のステートメントをＲｅｑｕｅｓｔＯｂｊｅｃｔ内に含むことができる。

このデータ妥当性検査命令がある場合、パーサは、Ｎａｍｅが必須入力パラメータであり、ストリングがＤｅｂｕｇとＰｒｏｄｕｃｔｉｏｎとＴｅｓｔのいずれかでなければならないことを認識する。そうでない場合は、データ妥当性検査命令はエラーを返すことになる。エラーの場合は、エラーメッセージを供給するために文書化命令を使用することができる。

例示的なオブジェクト処理命令は、以下のステートメントをＲｅｑｕｅｓｔＯｂｊｅｃｔ内に含むことができる。

このオブジェクト処理命令がある場合、ＨｏｓｔＮａｍｅに対して指定された引数は、ＲｅｑｕｅｓｔＯｂｊｅｃｔが実行可能コマンドレットに渡される前に、小文字のストリングに変換される。

例示的なオブジェクトエンコーディング命令は、以下のステートメントをＲｅｑｕｅｓｔＯｂｊｅｃｔ内に含むことができる。

このオブジェクトエンコーディング命令がある場合、ＨｏｓｔＮａｍｅとして入力されたストリングはＩＰアドレスに変換される。ＨｏｓｔＩＰパラメータは非公開として宣言されているので、パーサは、これを入力パラメータとして扱わない。しかし、実行可能コマンドレットはＨｏｓｔＩＰメンバを参照することができる。このオブジェクトエンコーディング命令は多くのコード行を節約するようには見えないかもしれないが、実際には、この命令は、第三者の開発者によって書かれるコードの量をかなり削減する。例えば、従来の環境では、第三者の開発者がエラー処理を扱う。さらに、エラーメッセージがストリングである場合、ストリングを複数の言語に変換することが必要な場合がある。しかし本発明は、一様なエラー処理を実現する。さらに本発明は、エラーメッセージを複数の言語に一様に変換する機構も提供する。処理はブロック４２６に進む。

ブロック４２６において、ＲｅｑｕｅｓｔＯｂｊｅｃｔインスタンスを実行可能コマンドレットに渡す。次いで実行可能コマンドレットは、これらの入力パラメータをその処理で使用する。したがって、従来のコマンド実装とは反対に、本発明のコマンドレットでは、入力パラメータを解析または妥当性検査するための固有のコードを書く必要はない。さらに本発明は、ソフトウェア開発者が命令を介して入力パラメータに対する追加の処理を指定することのできる、より一層リッチな環境を提供する。

各命令は、それ自体のエラーメッセージを扱う。エラーメッセージを表示する必要がある場合、命令は、ローカライズされたストリングを文書記憶域から得て、表示インターフェースを呼び出してエラーメッセージを表示する。文書化命令に関係するデータは、コマンドレットに、あるいはＸＭＬ記憶域または外部データベースに、あるいはリソースファイルに記憶することができる。したがって本発明は、すべてのコマンドレットに対して一貫性のあるエラーメッセージを提供することができ、第三者によるローカリゼーションの手間を削減する。

さらに、このリフレクションベースのシェルは、ある命令によって生成されたデータをオブジェクトの形で呼出し元命令に返す共通インターフェースを提供する。呼出し元命令は、このデータを、要求されるデータ型にキャストすることを担う。いくつかのカテゴリについての代表的な命令を表１〜５に示したが、本発明の範囲を逸脱することなく、その他の命令およびその他のカテゴリを追加することもできる。

したがって、以上に述べたように本発明は、コマンドレットへの入力パラメータに関する文法を定義するための機構を提供する。この機構により、開発者はコマンドレットを開発、テスト、およびサポートすることができる。コマンドレットは、コード行がより少なく、より迅速に実装され、欠陥がより少なく、欠陥への対処がより容易である。この機構は、より一貫性のある構文、セマンティクス、エラー処理、リソース管理、セキュリティなどを実現する。以上の考察では、本発明を．ＮＥＴ Ｆｒａｍｅｗｏｒｋ内で述べた。ただし、リフレクション機能を備える任意のオペレーティングシステム内で本発明を実施できることは、当業者なら理解するであろう。また、本発明をコマンドライン実施形態で述べた。ただし、解析される解析可能データは、本発明の範囲を逸脱することなく、音声、グラフィカルユーザインターフェース、スクリプトなどを介して得ることもできる。さらに、本発明を使用して、あるＲｅｑｕｅｓｔＯｂｊｅｃｔクラスが別のＲｅｑｕｅｓｔＯｂｊｅｃｔクラスを宣言できるようにすることによってリッチな文法セットを記述することもできる。したがって本発明は、高い汎用性をシステム管理者にもたらす。

以上の仕様、例、およびデータは、本発明の構成の製造および使用に関する完全な記述を提供するものである。本発明の趣旨および範囲を逸脱することなく、本発明に関する多くの実施形態を生み出すことができるので、本発明は、添付の特許請求の範囲にあるものとする。

本発明の例示的な一実施形態で使用することのできる例示的なコンピューティングデバイスを示す図である。 本発明による、リフレクションベースのシェル内のパーサおよびエンジンを介したコマンド処理を示す機能流れ図である。 本発明による、コマンドへの入力パラメータに関する文法を指定するためのデータ構造の一実施形態を示す図である。 本発明による、リフレクションベースのシェル内でコマンドライン上に入力された入力パラメータを処理するための例示的なプロセスを示す論理流れ図である。

符号の説明

１００ コンピューティングデバイス
１０２ 処理ユニット
１０４ システムメモリ
１０５ オペレーティングシステム
１０６ プログラムモジュール
１０７ プログラムデータ
１０９ 取外し可能記憶装置
１１０ 取外し不可能記憶装置
１１２ 入力デバイス
１１４ 出力デバイス
１１６ 通信接続
１１８ 他のコンピューティングデバイス
２００ リフレクションベースのシェル
２０２ パーサ
２０４ エンジン
２２０ ＲｅｑｕｅｓｔＯｂｊｅｃｔ、ｐｒｏｃｅｓｓ要求
２２２ ＲｅｑｕｅｓｔＯｂｊｅｃｔ、ｗｈｅｒｅ要求
２２４ ＲｅｑｕｅｓｔＯｂｊｅｃｔ、ｓｏｒｔ要求
２２６ ＲｅｑｕｅｓｔＯｂｊｅｃｔ、ｔａｂｌｅ要求
２３０ 実行可能コマンドレット、ｇｅｔ／ｐｒｏｃｅｓｓ実行ファイル
２３２ 実行可能コマンドレット、ｗｈｅｒｅ実行ファイル
２３４ 実行可能コマンドレット、ｓｏｒｔ実行ファイル
２３６ 実行可能コマンドレット、ｆｏｒｍａｔ／ｔａｂｌｅ実行ファイル
２５０ コマンドライン
２６０ コマンドレット、ｐｒｏｃｅｓｓコマンド
２６２ コマンドレット、ｗｈｅｒｅコマンド
２６４ コマンドレット、ｓｏｒｔコマンド
２６６ コマンドレット、ｔａｂｌｅコマンド
３００ データ構造
３０２ クラス名
３０４ ＲｅｑｕｅｓｔＯｂｊｅｃｔクラス
３１０ 解析命令
３１２ データ妥当性検査命令
３１４ データ生成命令
３１６ 処理命令
３１８ エンコーディング命令
３２０ 文書化命令
３３０ 公開メンバ
３３２ 公開メンバ
３４０ 非公開メンバ

Claims (28)

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. コンピュータ実行可能命令を有するコンピュータ可読媒体であって、前記命令は、
    少なくとも１つのコマンドと、前記少なくとも１つのコマンドに関連する少なくとも１つのパラメータとの解析可能ストリームを受け取る手段と、
    前記少なくとも１つのコマンドについての予想されるパラメータを記述する定義情報を取り出す手段と、
    前記定義情報を使用して、前記予想されるパラメータの記述に従ったフォーマットで前記少なくとも１つのパラメータを記憶するためのオブジェクトを生成する手段と、
    前記オブジェクトを前記少なくとも１つのコマンドに渡す手段と
    を含む方法を実施することを特徴とするシステム。
    

Images