(57)【要約】【課題】  ソフトウェアのコンポーネント化を提供すること。【解決手段】  コンポーネント化スキーマはオペレーティングシステムまたはその他のソフトウェア製品が構築される元になるファイルを表す。このスキーマによれば、コンポーネントオブジェクトはそれらのファイルのうちの１つまたは複数を表す。このコンポーネントオブジェクトは、そのコンポーネントを識別し、そのコンポーネントと他のオブジェクトの間の依存関係があればそれを指定するマニフェストを持つ。マニフェストで指定された依存関係に従ってオブジェクトをグループ化することによってソフトウェア製品を構築することが可能になる。少なくとも１つのコンポーネントオブジェクトによって定義される機能オブジェクトはそのソフトウェア製品の一機能を表し、少なくとも１つの機能オブジェクトによって定義される製品オブジェクトはそのソフトウェア製品を表す。【選択図】  図１
2005078650.tif 000002
【特許請求の範囲】
【請求項１】
複数のファイルからソフトウェア製品を構築する方法であって、
前記ファイルをオブジェクトに編成するステップであって、複数の前記オブジェクトはコンポーネントを表し、前記コンポーネントはそれぞれ前記ファイルのうちの少なくとも１つを含むステップと、
前記コンポーネントの各々をそれに関連するマニフェストを用いて識別するステップと、
前記マニフェストを用いて、前記コンポーネントと他のオブジェクトの間の１つまたは複数の依存関係を指定するステップと、
前記ソフトウェア製品を構築するために前記マニフェストで指定された依存関係に従って前記オブジェクトをグループ化するステップと
を含むことを特徴とする方法。
【請求項２】
様々なソフトウェア製品を様々な選択コンポーネントのセットの一機能として記述するために、前記コンポーネントに関連するメタデータを生成するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記オブジェクトの少なくとも１つは前記ソフトウェア製品の一機能を表し、選択オブジェクトのファイルによって実装される前記ソフトウェア製品の機能を定義するために前記選択オブジェクトをグループ化するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記機能を定義するためにグループ化された前記選択オブジェクトは、前記マニフェストで指定された依存関係に従ってグループ化された前記コンポーネントのうちの１つまたは複数を含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記オブジェクトのうちの少なくとも１つは、前記ソフトウェア製品中のファイルの一カテゴリを表し、１つまたは複数の他のオブジェクトが前記カテゴリでのメンバーシップを宣言するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記カテゴリでのメンバーシップを宣言する前記オブジェクトの各々は、コンポーネント、機能、およびパッケージのうちの少なくとも１つを表すことを特徴とする請求項５に記載の方法。
【請求項７】
前記選択コンポーネントをコンピュータ上にオペレーティングシステムイメージとしてインストールするステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記コンポーネントは、別のコンポーネント、カテゴリ、および機能のうちの１つまたは複数を表すオブジェクトに依存することを特徴とする請求項１に記載の方法。
【請求項９】
前記オブジェクトの各々は、コンポーネント、カテゴリ、機能、製品、在庫管理単位およびパッケージのうちの少なくとも１つを表すことを特徴とする請求項１に記載の方法。
【請求項１０】
前記コンポーネントの各々はそれに関連する前記マニフェストを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
前記コンポーネントの各々は識別情報を含むことを特徴とする請求項１に記載の方法。
【請求項１２】
１つまたは複数のコンピュータ可読媒体が請求項１に記載の方法を実施するコンピュータ実行可能命令を含むことを特徴とする請求項１に記載の方法。
【請求項１３】
複数のファイルからソフトウェア製品を構築する際に使用するためのオブジェクトが記憶された１つまたは複数のコンピュータ可読媒体であって、
各々が前記ファイルのうちの１つまたは複数およびそれらに関連するマニフェストを含む複数のコンポーネントオブジェクトであって、前記マニフェストは、前記コンポーネントオブジェクトを識別すると共に前記コンポーネントオブジェクトと１つまたは複数の他のオブジェクトの間の依存関係を指定するメタデータを含むコンポーネントオブジェクトと、
前記マニフェストで指定された依存関係に従ってグループ化された１つまたは複数の選択オブジェクトを含む、前記ソフトウェア製品の一機能に対応する少なくとも１つの機能オブジェクトと
を含むことを特徴とするコンピュータ可読媒体。
【請求項１４】
前記機能オブジェクト中の前記選択オブジェクトは、前記オブジェクト間の依存関係に従ってグループ化され、コンポーネントオブジェクトおよび機能オブジェクトのうちの１つまたは複数を含むことを特徴とする請求項１３に記載のコンピュータ可読媒体。
【請求項１５】
前記ソフトウェア製品はオペレーティングシステムを含むことを特徴とする請求項１３に記載のコンピュータ可読媒体。
【請求項１６】
関連するオブジェクトをグループ化するためのカテゴリオブジェクトをさらに含むことを特徴とする請求項１３に記載のコンピュータ可読媒体。
【請求項１７】
前記カテゴリオブジェクト中の前記オブジェクトは、前記カテゴリオブジェクトでのメンバーシップを宣言すると共に、コンポーネントオブジェクト、機能オブジェクト、およびパッケージオブジェクトのうちの１つまたは複数を含むことを特徴とする請求項１６に記載のコンピュータ可読媒体。
【請求項１８】
前記オブジェクトの各々は、コンポーネント、カテゴリ、機能、製品、在庫管理単位、およびパッケージのうちの少なくとも１つを表すことを特徴とする請求項１３に記載のコンピュータ可読媒体。
【請求項１９】
前記オブジェクトの各々は識別情報を含むことを特徴とする請求項１３に記載のコンピュータ可読媒体。
【請求項２０】
前記コンポーネントは、別のコンポーネントオブジェクト、カテゴリオブジェクト、および機能オブジェクトのうちの１つまたは複数に依存することを特徴とする請求項１３に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態はソフトウェアアーキテクチャの分野に関する。詳細には、本発明の実施形態はオペレーティングシステムを含むソフトウェア製品のためのコンポーネント化アーキテクチャ（ｃｏｍｐｏｎｅｎｔｉｚｅｄ  ａｒｃｈｉｔｅｃｔｕｒｅ）に関する。
【背景技術】
【０００２】
ソフトウェア製品がより大型化、複雑化するにつれて、既存のソフトウェア製品に基づいて新製品を作成し、それらの製品を市場および競争上のニーズに応じて修正することがますます困難になってきている。オペレーティングシステム（ＯＳ）は比較的大規模で、複雑なソフトウェア製品の一例である。
【０００３】
オペレーティングシステムは、それが常駐するコンピュータまたは装置のリソースを管理、スケジュールし、アプリケーションが様々なタスクを成し遂げるのに使用し得る様々な機能モジュールおよびインターフェースを提供する。従来のコンピュータは、一般に、そのコンピュータが稼動する際の様々な態様を管理するためにそのオペレーティングシステムを実行する。例えば、オペレーティングシステムは、通常、記憶装置、入力および／または出力装置へのアクセスの管理、および１つまたは複数の追加アプリケーションの実行の制御を担う。インストールは、普通、そのコンピュータがオペレーティングシステムを実行する前に（例えば、ＣＤ−ＲＯＭなどの配布媒体からコンピュータのハードディスクに複数のファイルをコピーすることによって）行われる。
【０００４】
従来のオペレーティングシステムは命令および／またはデータ用の多数の（例えば何千もの）ファイルを含む。そうした命令は、コンピュータによって実行されると、オペレーティングシステムの機能を提供する。それら多数のファイル以外に、オペレーティングシステムは、普通、ファイル間での多数の依存関係を有する。例えば、多くのファイルは、その意図された機能を実行するために１つまたは複数の他のファイルのインストールを必要とすることがある。オペレーティングシステムの製造者はインストール時にそうした依存関係について知り得るであろうが、ユーザ、管理者、またはその他のソフトウェア開発者がそれらの依存関係について知ることは困難であると考えられる。これは、ソフトウェア開発者が、自分の関与する個々のファイルに他のファイル中のどのデータまたは命令が影響を与えるのかを知り得ないので、厄介であることが分かる。同様に、誤作動するコンピュータのトラブルシューティングを行う管理者またはユーザも、依存関係の知識がなければ、どのファイルをその問題に適用し得るか知ることができない。
【０００５】
また、一般に、典型的なオペレーティングシステムは事実上モノリシックである。当業者は従来のオペレーティングシステムについて熟知しており、それらにおいてはサーバとクライアント両方のＯＳ製品が、バイナリファイルのすべてを含む巨大なセントラルファイルから構築されている。この例では、それら様々な製品にどのファイルが含まれているかをセットアップ実行可能プログラムが指定する必要がある。したがって、各製品の様々な部品間の関係は理解しにくい。この情報の欠如は、オペレーティングシステムのライフサイクルの間にその各部分を修正する際の妨げになる。すなわち、オペレーティングシステムがより大型化、複雑化するにつれて、開発者その他が、オペレーティングシステムの様々なモジュールおよびファイルすべてが一緒でも個々にも正しく動作することを保証するためにそれらの状況を把握し続けることが一層困難になってきている。
【０００６】
例を挙げると、あるＯＳ製品が「家庭用」バージョンとして販売され、付加機能を備える高価格製品が「専門家用」バージョンとして販売されることがある。この例では、それらの家庭用および専門家用製品は、しばしば、それぞれの製品を構成する多くのバイナリファイル全体に散在するブランド情報その他の参照を含むことがある。残念ながら、製品の作成および修正には極めて多くの労力を要し、バイナリファイル間の関係、および（その各々を新製品ごとに変更する必要のある）これらのブランド参照の存在が原因で広範囲にわたる試験を必要とする。
【０００７】
オペレーティングシステムは、種々様々な人々（ユーザ、管理者、そのオペレーティングシステムの開発者以外のソフトウェア開発者など）のいずれかによって、１つまたは複数の特定のバイナリファイルを付加または置換するなど種々様々な方式のいずれかで、変更（更新、修正など）され得る。そうした変更が行われると、コンピュータ上に存在するファイル間の依存関係の識別がますます困難になる。例えば、１つのファイルへの変更が他の依存ファイルへの変更を必要とすることがある。さらに、ユーザまたは管理者が、コンピュータ上に正確にはどの機能がインストールされており、またはどの機能をインストールすべきであるのかを容易に知り得ないため、誤作動するコンピュータのトラブルシューティングやオペレーティングシステムの更新がより一層困難になる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
したがって、上記その他の欠点の１つまたは複数に対処すると共に、特に、改良型のオペレーティングシステムの構築を可能にするために、ソフトウェアのコンポーネント化（ｃｏｍｐｏｎｅｎｔｉｚａｔｉｏｎ）が求められている。
【課題を解決するための手段】
【０００９】
本発明の実施形態は、オペレーティングシステムなどのソフトウェア製品をコンポーネントの集合体として表すことによって従来技術での１つまたは複数の欠陥を克服する。本発明の一態様は、ソフトウェア製品をコンポーネント化して構築するためにいくつかの抽象化を導入することを含む。このようにして、本発明の実施形態は、コンポーネント化された製品に基づく新製品の作成およびその製品の修正（ｓｅｒｖｉｃｅ）を容易にする。そのコンポーネント定義を使用して、アプリケーションコンポーネントを一般的に記述することが可能である。すなわち、このコンポーネント定義を使用して任意のアプリケーションを記述することができる。あるいは、このコンポーネント定義を使用してオペレーティングシステムコンポーネントをより詳細に記述することもできる。さらに、本明細書で述べる本発明の諸機能は、現在利用可能な技法よりも実施に際して手間がかからず容易であると共に、経済的採算性があり、商業的実用性がある。
【００１０】
簡単に述べると、本発明の諸態様を実施する方法は、複数のファイルからソフトウェア製品を構築する。この方法はそれらのファイルをオブジェクトに編成することを含む。この例では、複数のオブジェクトがコンポーネントを表し、それらのコンポーネントは、それぞれ、それらのファイルのうちの少なくとも１つを含む。また、この方法は、マニフェストで各コンポーネントを識別すると共に、それらのマニフェストを用いて、それらのコンポーネントと他のオブジェクトの間の１つまたは複数の依存関係を指定することも含む。マニフェストで指定された依存関係に従ってオブジェクトをグループ化することによって、ソフトウェア製品を構築することが可能になる。
【００１１】
本発明の別の実施形態は、１つまたは複数のコンピュータ可読媒体に関連するものである。複数のコンポーネントオブジェクトを含む、その媒体上に記憶されたオブジェクトを使用して複数のファイルからソフトウェア製品が構築される。各コンポーネントオブジェクトはそれらのファイルのうちの１つまたは複数およびマニフェストを含む。マニフェストはそれらのコンポーネントオブジェクトを識別すると共に、それらのコンポーネントオブジェクトと１つまたは複数の他のオブジェクトの間の依存関係を指定するメタデータを含む。この媒体は、ソフトウェア製品の一機能に対応する少なくとも１つの機能オブジェクトも含む。機能オブジェクトは、マニフェストで指定された依存関係に従ってグループ化された１つまたは複数の選択オブジェクトを含む。
【００１２】
別の実施形態では、コンポーネント化スキーマは、コンポーネントオブジェクトを用いて、ソフトウェア製品が構築される元になる１つまたは複数のファイルを表す。そのコンポーネントオブジェクトに関連するマニフェストがそれを識別し、そのコンポーネントオブジェクトと少なくとも１つの他のオブジェクトの間の１つまたは複数の依存関係を指定する。このスキーマは機能オブジェクトおよび製品オブジェクトも含む。機能オブジェクトは少なくとも１つのコンポーネントオブジェクトによって定義され、そのソフトウェア製品の一機能を表す。製品オブジェクトは少なくとも１つの機能オブジェクトによって定義され、そのソフトウェア製品を表す。
【００１３】
コンポーネント化の方法を実施するコンピュータ実行可能命令を含むコンピュータ可読媒体は、本発明のさらなる諸態様を実施する。
【００１４】
あるいは、本発明は他の様々な方法および装置も含み得る。
【００１５】
他の特徴の一部は明らかであり、一部を以下で指摘する。
【発明を実施するための最良の形態】
【００１６】
図面全体を通して、対応する参照文字は対応する部分を示す。
【００１７】
次に図面を参照すると、図１には、本発明の特定の実施形態による計算処理装置１５０の一例が示されている。計算処理装置１５０は、オペレーティングシステム１５２や１つまたは複数のアプリケーションプログラム１５４などのソフトウェア製品を有するものとして示されている。
【００１８】
オペレーティングシステム１５２は、計算処理装置１５０の根底をなすソフトウェア制御プログラムであり、ユーザインターフェースの提供、１つまたは複数のアプリケーション１５４実行の管理、および様々な入出力（Ｉ／Ｏ）装置との間のデータ入力およびデータ出力の制御を含む様々な機能を実施する。アプリケーションプログラム１５４は、計算処理装置１５０上で実行され得る多種多様なソフトウェアアプリケーションプログラムのうちの１つまたは複数を表す。そうしたアプリケーションプログラム１５４の例には、教育プログラム、参照プログラム、生産性向上プログラム（例：ワードプロセッサ、スプレッドシート、データベース）、レクリエーション用プログラム、ユーティリティプログラム（例：通信プログラム）などが含まれる。アプリケーションプログラム１５４はユーザによって計算処理装置１５０にインストールされ、あるいは計算処理装置１５０の製造者および／または販売者によって事前インストールされ得る。
【００１９】
図１のオペレーティングシステム１５２は、その機能を、図示の実施形態でのコンポーネント＃１からコンポーネント＃Ｎといった複数のコンポーネント１５６に区分する。各コンポーネント１５６は、それぞれ、マニフェスト＃１からマニフェスト＃Ｎといった対応するマニフェスト１５８を有する。コンポーネント１５６は１つまたは複数のファイル（またはファイル識別子）の集合体を含む。これらのファイルは、実行可能ファイル、ダイナミックリンクライブラリ（ＤＬＬ）、コンポーネントオブジェクトモジュール（ＣＯＭ）などのソフトウェア命令を含み得る。これらのファイルは、コンポーネント１５６のうちの１つまたは複数が使用するためのデータも含み得る。一実装形態では、オペレーティングシステム１５２の個々の機能に対応するファイル（データおよび／または命令など）は、同じコンポーネント１５６中にまとめてグループ化される。例えば、ゲームコンポーネント、通信コンポーネント、ファイルシステムコンポーネントなどがあり得る。コンポーネント化されることになるファイルのグループ化は、静的であることも、経時的に変化することもある。一例では、オペレーティングシステム１５２への更新の結果、特定のコンポーネント１５６からの選択ファイルが削除され、他のコンポーネント１５６に付加されることがある。
【００２０】
図１をさらに参照すると、各マニフェスト１５８は、対応するコンポーネント１５６を記述する情報を含む。各マニフェスト１５８には、対応するコンポーネント１５６に関する多種多様なメタデータのいずれかが含まれ得る。一実装形態では、マニフェスト１５８は、対応するコンポーネント１５６のバージョン、およびその対応するコンポーネント１５６が、もしあれば、他のどのコンポーネント１５６に依存するかを識別する。例を挙げると、コンポーネント１５６中の１つまたは複数のファイルが適正に実行されるように、計算処理装置１５０に別のコンポーネントからの他の１つまたは複数のファイル（ＤＬＬファイルなど）をインストールする必要があることがある。この例では、マニフェスト１５８は、コンポーネント１５６が他方のコンポーネントに依存することを示すはずである。
【００２１】
既存のオペレーティングシステムの複雑さとサイズが原因で、市場や競争上のニーズを満たす新製品を作成することがますます困難になってきている。今日のオペレーティングシステムは、事実上、むしろモノリシックであり、したがって、様々な構成部分間の関係を理解しにくいことがある。この情報が欠如すると、オペレーティングシステムのライフサイクルの間にその製品を修正することが極めて困難になる。上記その他の問題を克服するために、本発明の実施形態は、オペレーティングシステムをコンポーネント化する。すなわち、本発明は、ソフトウェア製品をコンポーネントの集合体として表すことを可能にする。本発明の諸態様は、新製品の作成および既存製品の修正を容易にするためにオペレーティングシステムをコンポーネント化して構築するのに使用されるいくつかの抽象化を伴う。それらの抽象化は、アプリケーションプログラムや任意のオペレーティングシステムを含む任意のソフトウェア製品に適用され得る。
【００２２】
本発明の諸態様を例示するコンポーネント定義スキーマは、いくつかの抽象化、すなわち、コンポーネント（組み立て部品ともいう）、カテゴリ、機能、パッケージ、製品およびＳＫＵ（在庫管理単位（ｓｔｏｃｋ  ｋｅｅｐｉｎｇ  ｕｎｉｔ）を導入する。この例では、コンポーネント１５６は、再利用可能、共用可能な、自己説明型（ｓｅｌｆ−ｄｅｓｃｒｉｂｉｎｇ）の配布、修正、および／または結合の原子単位（ａｔｏｍｉｃ  ｕｎｉｔ）を表す。これは、コンポーネント自体、およびインストール、修正、および／または必要なリソースへの結合に使用されるすべての関連情報（すなわちメタデータ）を宣言型で記述する最も基本的な抽象化である。
【００２３】
本発明の一実施形態に関連して以下でより詳細に説明するように、カテゴリオブジェクト（単に、カテゴリとも呼ぶ）１６２（図４参照）は共通のコンポーネント１５６のセットをグループ化する機構を表し、機能オブジェクト（単に機能とも呼ぶ）１６４（図５参照）はコンポーネント１５６および／または機能オブジェクト１６４からなる構成物を表し、製品オブジェクト（単に製品とも呼ぶ）１６６（図７参照）を作成するための基本構成要素として使用され、パッケージオブジェクト（単にパッケージとも呼ぶ）１６８（図６参照）はコンポーネント１５６、機能オブジェクト１６４、カテゴリオブジェクト１６２、および／またはその他のパッケージオブジェクト１６８からなる構成物を表す。一例を挙げると、パッケージオブジェクト１６８は、管理のために１組のコンポーネント１５６をグループ化するのに使用される。さらに、この実施形態での製品オブジェクト１６６は、機能オブジェクト１６４および／またはコンポーネント１５６からなる最上位レベルの構成物を表し、ＳＫＵオブジェクト（単にＳＫＵとも呼ぶ）１７０（図８参照）は、製品オブジェクト１６６の出荷機構を表す（例えば、１つのＳＫＵオブジェクト１７０は複数の製品オブジェクト１６６を含み得る）。
【００２４】
本明細書で述べるコンポーネント定義は、オペレーティングシステムコンポーネントだけに限定してではなく、アプリケーションコンポーネントを一般的に記述するのにも使用できる。すなわち、このコンポーネント定義を使用して任意のアプリケーションを記述することが可能である。
【００２５】
本発明の実施形態によるコンポーネント化アーキテクチャは、設計時と実行時の両方でコンポーネントを管理するための概念、コンポーネントリポジトリ、およびプログラミングモデルを定義する。敏捷性、速度、支援性、および収益機会の増加を含めて、コンポーネント化にはいくつかの戦略的利点がある。製品オブジェクトまたはＳＫＵオブジェクトで表される新規ソフトウェア製品の作成は、クライアントおよびサーバラインをまたぐ場合でさえも、はるかに容易に行われる。それは、適切なコンポーネントを選択し、新製品を構築するための若干の補足的構成を提供するという比較的単純なタスクである。比較的短期間で新製品を作成する際のこの敏捷性よって、効率よく競争し、市場機会の喪失を回避することができる。例えば、現行の製品に後で追加するための付加コンポーネントを提供することが可能であり、それによって顧客は高価格製品にアップグレードすることができるようになり、全体のライセンス数などが増加する。これらの付加的アクティビティのすべてがそれらの製品でのさらなる収益を生じ得る。
【００２６】
また、コンポーネント化は、ＯＥＭ（ｏｒｉｇｉｎａｌ  ｅｑｕｉｐｍｅｎｔ  ｍａｎｕｆａｃｔｕｒｅｒ）または企業が維持する必要のある製品イメージ数の削減を容易にし、大幅のコスト節約をもたらし得る。本発明の少なくとも１つの実施形態によれば、コンポーネントがオフラインでインストールされ得るように大部分のコンポーネント情報は宣言型である。これは、ターゲット装置に製品全体をインストールするのに要する時間を短縮し、ＯＥＭ、企業、エンドユーザなどにとっての大幅なコスト削減をもたらすと同時に、顧客満足を増大させる。
【００２７】
当業者は、製品サイクルの一部としての修正の重要性を理解している。本発明の実施形態によるコンポーネント化製品の修正は比較的単純である。というのは、各コンポーネントによって提供される宣言型情報に基づいて変更の影響を評価することが容易であるからである。また、試験効率を向上させるために、より隔離された環境で各コンポーネントを試験することもはるかに容易である。これによって、ソフトウェア製品での全体的脆弱性が低減される。
【００２８】
本明細書で述べるコンポーネント定義スキーマは、コンポーネント１５６がインストール、サービスのアップグレード、適当なリソースへの結合を行うために記述する情報をカバーする。これに関して、図２に、本発明の特定の実施形態による例示的コンポーネント１５６および対応するマニフェスト１５８を示す。本発明の実施形態によれば、各コンポーネント１５６は、対応するマニフェスト１５８によって表される。コンポーネント１５６は、少なくとも１つのファイル１７４を含み、任意選択で、２つ以上（Ｎ個の）ファイルを含み得る。図２にはファイルとして示してあるが、コンポーネント１５６は、代替として、実際のファイルではなく、１つまたは複数のファイル１７４のポインタその他の識別子を含むこともできる。
【００２９】
コンポーネント１５６はマニフェスト１５８に対応する。図示の例では、マニフェスト１５８はコンポーネント１５６を（名前または他の何らかの一意の識別子などによって）識別するコンポーネント識別子を含む。この対応は、別法として、コンポーネント１５６にマニフェスト１５８の識別子（図示せず）を含めること、コンポーネント１５６とマニフェスト１５８の間の固有の対応を維持するデータ構造にコンポーネント１５６とマニフェスト１５８（またはそられの識別子）の両方を記憶することなどといった、様々な方式で維持され得る。マニフェスト１５８は、拡張マークアップ言語（ＸＭＬ）文書とすることもできる。
【００３０】
図２の例示的リストに示すように、マニフェスト１５８は、コンポーネント１５６が依存する０個以上のコンポーネントを識別する依存コンポーネントリストも含む。識別される依存コンポーネントは、コンポーネント１５６が適正に機能するためにオペレーティングシステムイメージの一部としてやはりインストールされる必要のあるコンポーネントである。図示の例では、各識別子は、コンポーネント１５６が適正に機能するのに必要なコンポーネントを識別するが、あるいは、含まれることが望ましいコンポーネント（すなわち、コンポーネント１５６がオペレーティングシステムの一部として含むことを選択するが必要ではないコンポーネント）を含むこともできる。識別および依存関係に加えて、この例でのマニフェスト１５８は、コンポーネント１５６のいくつかの他の詳細、すなわち、一般情報（所有者、試験者、開発者、内容などを含む）、リソース（ファイル、レジストリ情報などを含む）、設定（構成）、メンバーシップその他の情報も記述する。
【００３１】
別の実施形態でのマニフェスト１５８は、インストールおよび／またはアップグレードを支援するための優先順位およびバージョン識別子も含み得る。
【００３２】
あるいは、マニフェスト１５８に維持される情報の一部または全部を様々な場所に維持することもできる。例を挙げると、その情報の一部または全部を、図１のコンポーネント１５６に組み込むことも可能である。
【００３３】
付録Ａの例は、マニフェスト１５８に関する本発明の諸態様を詳細に示すものである。
【００３４】
以下の説明では、本発明の諸態様を例示するコンポーネント化アーキテクチャで使用される主要な抽象化に関するさらなる詳細を提供する。
【００３５】
前述のように、コンポーネント１５６（または組み立て部品）と呼ばれるオブジェクトは、配布、修正、および結合の再利用可能または共用可能な、自己説明型原子単位を表す。図３の実施形態では、コンポーネント１５６は他のコンポーネント１５６および／または機能１６４に依存して実行され得る。すなわち、それらは、そうした他のオブジェクトに対する依存関係を呈する。また、コンポーネント１５６は、様々な開いたグループ、すなわち、カテゴリ１６２のメンバとすることもできる。この例では、「識別情報」と呼ばれる、開発者にとって使いやすい、拡張可能な、マルチパート属性「バッグ」が各コンポーネント１５６を識別する。このコンポーネント識別情報は、例えば、名前、バージョン、プロセッサアーキテクチャ、言語（「ｕｓ−ｅｎｇ（米語）」や「ｊｐｎ（日本語）」など）、構築タイプ（フリーまたはデバッグなど）、開始元ＩＤなどの属性を持つ。名前属性は、一実施形態ではその個々のコンポーネント１５６を記述するロケールと無関係な文字列の形を取る。識別情報のバージョン属性では、例えば、一般には、「主版数．副版数．構築．改訂」形式に従った、４部分からなるバージョン番号が提供される。この識別情報の開始元ＩＤ属性には、そのコンポーネント識別情報がセキュアであることを可能にする暗号で保護された情報が含まれる。
【００３６】
前述のように、各コンポーネント１５６は、１つまたは複数のファイルおよび関連するマニフェスト１５８で構成される。マニフェスト１５８は、図３に示すように、コンポーネント１５６の詳細を記述する。図３の実施形態では、コンポーネントまたは組み立て部品と呼ばれるオブジェクトは、別のコンポーネント１５６、カテゴリ１６２、および／または機能１６４に対する依存関係を持ち得る。
【００３７】
図４に示すカテゴリオブジェクト１６２は、メンバーシップ情報が、カテゴリマニフェストに存在するのではなくそこにそのカテゴリのメンバと共に存在する、開いたグループを定義する。例えば、ノートパッドやワードパッドといったテキストエディタに関連する１つまたは複数のコンポーネント１５６をグループ化するために１つのカテゴリ１６２を設けることができる。また、カテゴリ１６２も、やはり、コンポーネント１５６と同様の識別情報機構を使用して識別される。一実施形態では、カテゴリ１６２は、識別情報、一般情報、その他の情報などの詳細を有する。
【００３８】
次に図５を参照すると、機能オブジェクト１６４はコンポーネント１５６および／または他の機能１６４からなる構成物を表す。機能１６４はソフトウェア製品基本構成要素として使用され、インストールへの追加、またはインストールから削除が可能である。機能１６４は、他のオブジェクトに依存するのではなく、コンポーネント１５６、他の機能１６４、およびカテゴリ１６２に対する包含関係を有する。すなわち、機能１６４は、この実施形態によれば依存関係を持たない。例を挙げると、１つの機能オブジェクト１６４は、統合Ｗｅｂブラウザ機能を表し、別の機能オブジェクト１６４はメディアプレーヤアプリケーションを表し、その両方が１つのオペレーティングシステムに同梱される。機能１６４は、識別情報、一般情報（所有者、試験者、開発者、内容など）、メンバーシップ、構成物、その他の情報からなる。本発明の一実施形態では、機能識別情報はコンポーネント識別情報と構造が類似しており、各機能１６４を識別するのに使用される。機能１６４は複数の異なるカテゴリ１６２（図４参照）のメンバであり得る。
【００３９】
図６に、パッケージオブジェクト１６８を図式的に示す。図示のように、パッケージ１６８は、コンポーネント１５６、機能１６４、カテゴリ１６２、および他のパッケージ１６８からなる構成物である。カテゴリ１６２とは対照的に、パッケージ１６８は閉じたグループである。パッケージ１６８は、主として、管理目的で使用される。例えば、あるＯＳの家庭用バージョンは、「ｃａｂ１」、「ｃａｂ２」、「ｃａｂ３」、「ｃａｂ４」で示される４つの異なるパッケージ１６８を用いて出荷され得る。この例でのパッケージオブジェクト１６８は、セットアップのために形成されたグループである。パッケージ１６８は、図６の実施形態では、他のパッケージ１６８だけに対する依存関係を指定する。本明細書で述べるコンポーネント化定義による各パッケージ１６８は、識別情報、一般情報、メンバーシップ、構成物、依存関係、その他の情報などの詳細からなる。
【００４０】
図７の製品オブジェクト１６６は、機能１６４および／またはコンポーネント１５６からなる最上位構成物を表す。これは、構成された機能１６４およびコンポーネント１５６を設定するのに使用される属性も有する。本発明の実施形態によれば、製品設計者は製品１６６（図１３参照）用の機能１６４を選択する。製品オブジェクト１６６は、識別情報、一般情報、構成物、およびその他の情報に関する詳細を含む。
【００４１】
次に、図８を参照すると、ＳＫＵオブジェクト１７０は、製品１６６用の出荷媒体（すなわち、出荷用ディスクにどの製品が含まれるか）を表す。適当な出荷媒体には、フロッピー（登録商標）またはコンパクトディスク、およびＷｅｂダウンロードキャビネットファイルが含まれる。また、ＳＫＵ１７０は、複数の製品１６６（図１３参照）から構成することもできる。本発明の少なくとも１つの実施形態では、ＳＫＵ設計者用ツールを使用してＳＫＵマニフェストを生成する。前述のその他の抽象化と同様に、ＳＫＵ１７０は、識別情報、一般情報、製品、およびその他の情報を含む。
【００４２】
図９から図１２は、コンポーネント１５６と他のオブジェクトの間の例示的関係をさらに示すものである。具体的には、図９には、コンポーネント１５６が１つまたは複数のカテゴリ１６２、１つまたは複数の機能１６４、および／または１つまたは複数の他のコンポーネント１５６に含まれるバイナリファイルのうちの１つまたは複数に依存し得ることが示されている。また、コンポーネント１５６はカテゴリ１６２でのメンバーシップを宣言し得る。図１０の例示的関係図では、カテゴリ１６２を使用して、１つまたは複数の機能１６４、１つまたは複数のコンポーネント１５６、および／または１つまたは複数のパッケージ１６８をグループ化することが可能である。前述のように、カテゴリオブジェクト１６２は、他のオブジェクトがそれへのメンバーシップを宣言するための開いたグループを表す。図１１には、さらに、機能１６４が１つまたは複数の他の機能１６４および／またはコンポーネント１５６を含むこと、および機能１６４がカテゴリ１６２のうちの１つまたは複数でのメンバーシップを宣言し得ることが示されている。次に、図１２を参照すると、パッケージ１６８は、１つまたは複数の他のパッケージ１６８、カテゴリ１６２、機能１６４、および／またはコンポーネント１５６のグループを表す。この例では、パッケージ１６８は、カテゴリ１６２などの開いたグループに属することも、別のパッケージ１６８などの閉じたグループに依存することも可能である。
【００４３】
図１３には、機能１６４を定義するためにＯＳバイナリファイルのさまざまなコンポーネント１５６をグループ化する例が提供されている。その場合、機能１６４は、製品１６６を定義するためにグループ化され、次にはそれらが出荷用にＳＫＵ１７０に含まれる。コンピュータによって、同じオペレーティングシステムに基づく異なるオペレーティングシステムイメージを持つことが可能である。例えば、異なるＯＥＭは、同じオペレーティングシステムを異なったやり方でカスタマイズし得る（例えば、そのオペレーティングシステムがそのＯＥＭを識別する初期画面と共に起動するように、異なるデフォルト設定が使用され得るなど）。また、異なる機能（例えば、スクリーンセーバ、背景またはテーマ、通信プログラム、ゲームといったソフトウェアアプリケーションなど）を含めることも可能である。この付加機能は、ＯＥＭ、あるいは他の製造者または販売者によっても提供され得る。したがって、多種多様なコンポーネントをオペレーティングシステムの一部とすることができ、実際には、そのうちの部分セットだけが個々のコンピュータ上にオペレーティングシステムイメージとしてインストールされる。他方、ＯＥＭ別のコンポーネントとマニフェストのセットは、そのＯＥＭによってオペレーティングシステムイメージの一部としてインストールされ得る付加コンポーネントを含む。
【００４４】
このオペレーティングシステムは、多種多様な理由のうちのどれによっても更新され得る。例を挙げると、特定のコンポーネントの特定のファイルへのバグ修正、コンポーネントでの新機能（置換や追加ファイルなど）、新規コンポーネントなどを使用可能とすることができる。
【００４５】
さらに、以前のコンポーネントを置き換えるのではなくそれと一緒に、オペレーティングシステムの一部として新しいコンポーネントをインストールすることもできる。これによって、様々なアプリケーションは、どれでもそれらが好む（または使用するようにプログラムされている）そのコンポーネントのバージョンを使用することが可能になる。
【００４６】
例を挙げると、ＯＥＭは家庭用、業務用、サーバ用などに対応する様々な基本コンピュータ構成を提供することができる。この例でのそれらの構成のうちの各々は、同じオペレーティングシステムに基づくものであるが、異なる機能を含む。サーバ構成には、家庭用構成にも業務用構成にも含まれない付加的ネットワークおよび通信機能を含めることが可能であり、家庭用構成には、業務用構成にもサーバ構成にも含まれない、付加的ゲームまたはオーディオ再生機能を含めることが可能である。図１３に、基本の家庭用製品を含む高価格製品の一例を示す。
【００４７】
一実施形態では、ソフトウェア製品を構築することは、製品オブジェクトに記載されたコンポーネントのリポジトリから実行時イメージを作成する行為である。構築は、一般に、オフラインで実施される。すなわち、マシンＸでの実行時イメージがマシンＹ上で作成される。依存関係は、最上位製品から完全に解決される。依存関係が解決されると、依存ツリー中の各ノードがターゲットにインストールされる。ターゲットは、オフラインで作成されているインストールを表す。各コンポーネントのインストールには、そのコンポーネントの一部である各リソース（レジストリキーやファイルなど）をインストールすること、およびインストール済みコンポーネントを追跡するためにインストール済みコンポーネントリポジトリにエントリを記入することを伴う。
【００４８】
図１４に、本発明の実施形態によるプログラミングモデルの第１レベルの抽象化を示す。具体的には、この図の例には、例えば、統一モデル化言語（ＵＭＬ）を使用して様々な第１レベルオブジェクト（またはクラス）が公開されている。これらのオブジェクトは、この例では、ＵＭＬを使用してプログラマに公開される。それらのインターフェースの各々は、コンポーネント化の第１レベル概念に直接マップされる。
【００４９】
オペレーティングシステムのインストールプロセスは、オペレーティングシステムのコンポーネント化によって大幅に単純化される。ＯＥＭ別機能は、適当なコンポーネントおよび対応するマニフェストを含めることによって容易にコンピュータに追加され得る。さらに、機能の改善、バグ修正などのためのオペレーティングシステムへの更新も、単に対応するコンポーネントを置換するだけで、インストールプロセスに容易に組み込むことが可能である。あるいは、追加の更新コンポーネントとマニフェストのセットを、そうした更新を含むオペレーティングシステムインストール装置から利用可能にすることもできる。
【００５０】
図１５に、本発明と共に使用するための例示的コンポーネント化アーキテクチャを示す。図１５に示す拡張可能なアーキテクチャは、コンポーネントのインストールおよびアンインストールを含めて、ＯＳインストールの構築を可能にし、製品／ＳＫＵの敏捷性を実現する。さらに、このアーキテクチャは、実行中のＯＳおよびＯＳイメージを修正するためのインフラストラクチャを提供し、ＯＳコンポーネントの在庫目録を提供し、インストール済みシステム上で存続する。このコンポーネント化アーキテクチャは、コンポーネントの作成および管理のための一般化された枠組みを提供する。また、一般的な方法で構成から実行時イメージを構築することも可能にする。ＣＭＩ（ｃｏｍｐｏｎｅｎｔ  ｍａｎａｇｅｍｅｎｔ  ｉｎｔｅｒｆａｃｅ）は、様々な消費者がコンポーネント化アーキテクチャによって公開される機能にアクセスするのに使用し得るプログラミングモデルインターフェースである。それらのツールは、一般に、設計時ツール、実行時ツール、および構築時ツールというクラスに分けられる。設計時ツールは、設計時に使用されるツールである（コンポーネントを設計または作成するコンポーネント設計者、および構成を設計または作成するターゲット設計者など）。実行時ツールは、実行時イメージ上の既存のコンポーネントを管理するのに使用される（インストール）。これは、システムにインストールされたコンポーネントを管理するＯＣＭなどの機能を含み得る。実行時ツールの別の例としては、リモートサーバと対話してコンポーネント更新を取得し、インストール時にインストールされたコンポーネントを更新する修正クライアントもあり得る。構築時ツールは構築ラボで使用される。それらは、主に、構成から実行時イメージを作成するのに使用される。
【００５１】
図１５に示すように、ＣＭＩにはコア層およびユーティリティ層がある。ＣＭＩコア層は、一般に、公開され、公知のインターフェースとして消費される様々な機能ブロックからなる。この層は、コアＣＭＩオブジェクトモデル、リポジトリおよびファイルリポジトリ、シリアライザ／デシリアライザからなる。コアＣＭＩオブジェクトモデルブロックは、プログラミングを容易にするために、複数の異なる第１クラス抽象化をＣＭＩクライアントへのインターフェースとして公開する。それらは、一般に、比較的使用しやすい形式でコンポーネント化抽象化を反映する。例えば、ＩＡｓｓｅｍｂｌｙは「コンポーネント」概念を抽象する。この実施形態での抽象化は、それらに関連する機能を持たない。それらは、それらの抽象化上で公開される方法によって取り出され、設定され得る属性の集合体である。以下のリストには、コアＣＭＩオブジェクトモデル中のインターフェースを介して公開される抽象化の一部が含まれる：ＩＡｓｓｅｍｂｌｙ；ＩＦｅａｔｕｒｅ；ＩＣａｔｅｇｏｒｙ；ＩＰａｃｋａｇｅ；ＩＰｒｏｄｕｃｔ；ＩＳｋｕ；ＩＣｏｎｆｉｇｕｒａｔｉｏｎ；ＩＲｅｐｏｓｉｔｏｒｙ。
【００５２】
図１５の例でのコンポーネントリポジトリは、リポジトリの１つに存在するコンポーネントを管理するのに使用される。前述のように、各コンポーネントはメタデータ（すなわちそのデータに関する情報）および実際のデータ（すなわちコンポーネントのファイル）を含む。メタデータにはメタデータリポジトリインターフェース（ＩＲｅｐｏｓｉｔｏｒｙ）を介してアクセス可能であり、データにはファイルリポジトリインターフェース（ＩＦｉｌｅＲｅｐｏｓｉｔｏｒｙ）を介してアクセス可能である。一実施形態では、メタデータリポジトリインターフェースは、コンポーネントのメタデータを記憶し、それらに索引付けする関係データベースを使用して実装される。ファイルリポジトリインターフェースは、各クライアントが一貫した方式でコンポーネントデータ（ファイル）にアクセスできるようにする。
【００５３】
コンポーネントメタデータおよびデータのインターフェースは、図１５のコンポーネントリポジトリインターフェースの下で分割されて、様々なシナリオに基づく様々な交換可能メタデータリポジトリの実装を可能にする。例えば、設計マシン上では、使用可能な記憶およびメモリが制約されないと考えられるのでＳＱＬメタデータリポジトリを使用できるはずであるが、実行時システム上では、逼迫したメモリ所要量を管理するために、メタデータリポジトリは小型の省スペースデータベース（レジストリなど）によって支援され得る。
【００５４】
シリアライザ／デシリアライザインターフェースは、ＣＭＩ中の第１クラスオブジェクトの、テキストファイルへの直列化およびテキストファイルからの非直列化を可能にする。例えば、ＸＭＬシリアライザ／デシリアライザは、ＸＭＬファイルの読取りおよび書込みを行う。シリアライザおよびデシリアライザは、一般に、以下で述べるようにキャリアおよび構成の読取りおよび書込みを行う。
【００５５】
直列化形式で第１クラス抽象化のいずれかを保持するファイルをキャリアまたはマニフェストと呼ぶ。キャリアは、コンポーネントリポジトリデータを取り込む手段を提供する。すなわち、ツールがキャリアファイル中のコンポーネントの直列化インスタンスを作成または編集し、コンポーネントリポジトリインターフェースがそのキャリアのコンポーネントリポジトリへのインポートを可能にする。
【００５６】
情報交換にキャリアを使用することの主要な利点は、それがツールをコンポーネントリポジトリから切り離せるようにすることである。別の利点は、キャリア情報をインポートする間に、データが、より一貫した（または完全な）形式でコンポーネントリポジトリにインポートされ得ることである。また、シリアライザ／デシリアライザインターフェースの隔離は、他の種類のキャリア（ＩＮＦなど）の実装も可能にする。
【００５７】
構成は、ＣＭＩのＩＣｏｎｆｉｇｕｒａｔｉｏｎオブジェクトの直列化表現であり、実行時イメージの構築に使用されるコンポーネントおよび設定の集合体を表す。構成がキャリアファイルではなく別のファイルで直列化される理由は、構成をデータベースにインポートすることができないからである。
【００５８】
ＣＭＩユーティリティ層は、頻繁に変更される機能ブロックからなる。図１５の実施形態では、それらの機能ブロックは公開され、公知のインターフェースとして消費される。ユーティリティ層は、インストーラ、アップグレーダ、依存リゾルバ、ＣＭＩオブジェクトモデル、およびクライアントのためのブロックを含む。インストーラブロックは、コア層によって公開される個々のコンポーネント化抽象化をインストール（または構築）し、除去するための論理を含む。例えば、ＩＡｓｓｅｍｂｌｙはオンラインまたはオフラインでインストールされ、ＯＳインストールから除去される。組み立て部品をインストールし、除去する論理はこのブロックに存在する。すべてのコア層抽象化は、「ＩＩｎｓｔａｌｌａｂｌｅ」インターフェースを使用してインストールされ、除去される。これらの方法の実装形態は、各コア抽象化ごとに変化する。例えば、組み立て部品の場合は、「ＩＡｓｓｅｍｂｌｙＩｎｓｔａｌｌｅｒ」と呼ばれるインストーラ抽象化がある。ＩＡｓｓｅｍｂｌｙＩｎｓｔａｌｌｅｒは、「ＩＡｓｓｅｍｂｌｙ」インターフェースを集約し、組み立て部品インスタンスをインストールし、アンインストールするために「ＩＩｎｓｔａｌｌａｂｌｅ」を実施する。
【００５９】
この種の個々の機能がコア抽象化と結合すると、コアＩＡｓｓｅｍｂｌｙインターフェースに影響を与えずに、必要に応じて組み立て部品のインストール論理の実装形態を変更させることが可能になる。同じことが他のコア抽象化にも当てはまる。
【００６０】
アップグレーダブロックは、ウィンドウズ（登録商標）インストール上での個々のコア抽象化のアップグレードおよびダウングレードのための論理を含む。例えば、ＩＡｓｓｅｍｂｌｙはオンラインまたはオフラインでＯＳインストールからアップグレードまたはダウングレードされる。組み立て部品をアップグレードおよびダウングレードする論理はこのブロックに存在する。すべてのコア抽象化は、「ＩＵｐｇｒａｄａｂｌｅ」インターフェースを使用してアップグレードされ、ダウングレードされる。
【００６１】
各コア抽象化ごとに、これらの方法の別々の実装形態がある。アップグレードプロセス時にはインストールおよびアンインストール機能が必要とされるので、「ＩＵｐｇｒａｄａｂｌｅ」はインストールおよびアンインストールの既存の機能を再利用するために「ＩＩｎｓｔａｌｌａｂｌｅ」から継承する。例えば、組み立て部品は、「ＩＡｓｓｅｍｂｌｙＵｐｇｒａｄｅｒ」と呼ばれるアップグレーダ抽象化を持つ。「ＩＡｓｓｅｍｂｌｙＵｐｇｒａｄｅｒ」は、「ＩＡｓｓｅｍｂｌｙ」、「ＩＡｓｓｅｍｂｌｙＩｎｓｔａｌｌｅｒ」を集約し、ウィンドウズ（登録商標）インストール上で組み立て部品インスタンスをアップグレードし、ダウングレードするために「ＩＵｐｇｒａｄａｂｌｅ」を実施する。その場合も、この種の結合は、組み立て部品アップグレード論理の実装形態が、コアＩＡｓｓｅｍｂｌｙインターフェースおよびインストールまたはアンインストール論理に影響を与えずに、必要に応じて変更され得るようにする。同じことが、他のコア抽象化のアップグレード機能にも当てはまる。
【００６２】
依存リゾルバブロックは、個々のコア抽象化のための依存解決論理を実装する。この例では、このブロックは、各コア抽象化ごとに、自動または手動のどちらかでの依存解決に関する論理を含む。依存リゾルバは、クライアントプログラムが、個々のクライアント状況での必要に応じてデフォルトの依存解決機能を拡張するように拡張することが可能である。このブロックの機能は、「ＩＤｅｐｅｎｄｅｎｃｙＲｅｓｏｌｖｅｒ」インターフェースを介して公開される。依存関係を解決する方法は、それが使用されるシナリオに基づいてＣＭＩオブジェクトまたはインスタンスオブジェクトのツリーを返す。本発明の少なくとも１つの実施形態によれば、依存解決は、一般に、構成またはリポジトリに関して行われる。リポジトリは、インストール可能リポジトリでもインストール済みリポジトリでもよい。
【００６３】
一般に、実行時システムでは、依存解決はインストール済みリポジトリおよび既存の構成に対して実施され、設計時シナリオでは、依存解決は、インストール可能リポジトリおよび編集中の現行構成に対して実施される。
【００６４】
ＣＭＩオブジェクトモデルは、ＣＭＩコアオブジェクトモデルおよびユーティリティ層で公開される機能の様々な部分の集約された形である。また、キャリア（またはマニフェスト）を直列化、非直列化する間にオーサリングツールが抽象化を直接操作するために、コアＣＭＩオブジェクトモデルも公開される。
【００６５】
前述のアーキテクチャで留意すべき重要事項の一つは、設計時、実行時および構築時のシナリオについて同じプログラミングモデルが有利に公開されることである。これは、様々な要件に関してオブジェクトモデルの一貫性を保つのに役立ち、プログラマの生産性を支援する。また、これは、設計時および実行時など様々なシナリオに使用されるＣＭＩの単一の実装形態を再利用する際にも役立ち、したがって、設計時シナリオと実行時シナリオでの異なる実装形態に比べてより保守が容易である。
【００６６】
図１６に、コンピュータ７０の形で汎用計算処理装置の一例を示す。本発明の一実施形態では、コンピュータ７０などのコンピュータが、コンピュータ１５０としての使用に適する。
【００６７】
図示の実施形態では、コンピュータ７０は１つまたは複数のプロセッサまたは処理装置７２およびシステムメモリ７４を備える。図示の実施形態では、システムバス７６は、システムメモリ７４を含む様々なシステムコンポーネントをプロセッサ７２に結合する。バス７６は、メモリバスまたはメモリ制御機構、周辺バス、アクセラレーテッドグラフィックスポート、および様々なバスアーキテクチャのいずれかを使用するプロセッサまたはローカルバスを含めて、数種類のバス構造のうちのいずれか１つまたは複数を表す。例を挙げると、それだけに限らないが、そうしたアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｉｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。
【００６８】
コンピュータ７０は、通常、少なくとも何らかの形のコンピュータ可読媒体を備える。コンピュータ可読媒体には、揮発性と不揮発性媒体の両方、取り外し可能と取り外し不能媒体の両方が含まれ、コンピュータ７０からアクセス可能な任意の使用可能媒体とすることができる。例を挙げると、それだけに限らないが、コンピュータ可読媒体には、コンピュータ記憶媒体および通信媒体が含まれる。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュールまたはその他のデータといった情報の記憶のための任意の方法または技術で実装される揮発性および不揮発性媒体、取り外し可能および取り外し不能媒体が含まれる。例えば、コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）またはその他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたはその他の磁気記憶装置、または所望の情報を記憶するのに使用でき、コンピュータ７０からアクセスすることのできるその他任意の媒体が含まれる。通信媒体は、通常、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを、搬送波やその他の搬送機構などの変調データ信号として実施し、任意の情報送達媒体を含む。この変調データ信号は、当業者にはよく知られており、それは、その信号中に情報を符号化するようにその特性の１つまたは複数を設定または変形させたものである。有線ネットワークや直接配線接続などの有線媒体、および音響、無線周波数、赤外線、およびその他の無線媒体などの無線媒体が通信媒体の例である。上記のいずれかの組合せもコンピュータ可読媒体の範囲に含まれる。
【００６９】
システムメモリ７４は、取り外し可能および／または取り外し不能、揮発性および／または不揮発性メモリの形でコンピュータ記憶媒体を含む。図示の実施形態では、システムメモリ７４は、読取り専用メモリ（ＲＯＭ）７８およびランダムアクセスメモリ（ＲＡＭ）８０を含む。基本入出力システム８２（ＢＩＯＳ）は、起動時などに、コンピュータ７０内の要素間での情報の転送を支援する基本ルーチンを含み、通常は、ＲＯＭ７８に記憶される。ＲＡＭ８０は、通常、処理装置７２に即座にアクセス可能であり、かつ／またはそれによって現在操作されているデータおよび／またはプログラムモジュールを含む。例として、それだけに限らないが、図１６には、オペレーティングシステム８４、アプリケーションプログラム８６、その他のプログラムモジュール８８、およびプログラムデータ９０が示されている。
【００７０】
コンピュータ７０は、他の取り外し可能／取り外し不能、揮発性／不揮発性コンピュータ記憶媒体も含み得る。例えば、図１６には、取り外し不能不揮発性磁気媒体との間で読取りまたは書込みを行うハードディスクドライブ９４が示されている。図１６には、取り外し可能不揮発性磁気ディスク９８との間で読取りまたは書込みを行う磁気ディスクドライブ９６、およびＣＤ−ＲＯＭやその他の光媒体などの取り外し可能不揮発性光ディスク１０２との間で読取りまたは書込みを行う光ディスクドライブ１００も示されている。この例示的動作環境で使用され得る他の取り外し可能／取り外し不能、揮発性／不揮発性記憶媒体には、それだけに限らないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどが含まれる。ハードディスクドライブ９４、磁気ディスクドライブ９６および光ディスクドライブ１００は、通常、インターフェース１０６などの不揮発性メモリインターフェースによってシステムバス７６に接続される。
【００７１】
前述の図１６に示す各ドライブまたはその他の大容量記憶装置およびそれらに関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュールおよびコンピュータ７０用のその他のデータの記憶を提供する。図１６には、例えば、ハードディスクドライブ９４が、オペレーティングシステム１１０、アプリケーションプログラム１１２、その他のプログラムモジュール１１４、およびプログラムデータ１１６を記憶するものとして示されている。これらのコンポーネントは、オペレーティングシステム８４、アプリケーションプログラム８６、その他のプログラムモジュール８８、およびプログラムデータ９０と同じものであっても、異なったものであってもよいことに留意されたい。オペレーティングシステム１１０、アプリケーションプログラム１１２、その他のプログラムモジュール１１４、およびプログラムデータ１１６には、少なくとも、それらが異なるコピーであることを示すために、ここでは異なる番号を付与する。
【００７２】
ユーザは、キーボード１２０やポインティング装置１２２（マウス、トラックボール、ペン、タッチパッドなど）といった入力装置またはユーザインターフェース選択装置を介してコンピュータ７０にコマンドおよび情報を入力することができる。他の入力装置（図示せず）には、マイク、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどが含まれ得る。上記その他の入力装置は、システムバス７６に結合されたユーザ入力インターフェース１２４を介して処理装置７２に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など、他のインターフェースおよびバス構造によっても接続され得る。また、モニタ１２８またはその他の種類の表示装置も、ビデオインターフェース１３０などのインターフェースを介してシステムバス７６に接続される。モニタ１２８以外にも、コンピュータは、しばしば、印刷装置やスピーカなど他の周辺出力装置（図示せず）を含むことがあり、それらは出力周辺インターフェース（図示せず）を介して接続され得る。
【００７３】
コンピュータ７０は、リモートコンピュータ１３４など、１つまたは複数のリモートコンピュータへの論理接続を使用したネットワーク化環境で動作し得る。リモートコンピュータ１３４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置またはその他一般のネットワークノードとすることができ、通常は、コンピュータ７０に関連して前述した各要素の大部分またはすべてを含む。図１６に示す論理接続には、ローカルエリアネットワーク（ＬＡＮ）１３６および広域ネットワーク（ＷＡＮ）１３８が含まれるが、他のネットワークも含まれ得る。ＬＡＮ１３６および／またはＷＡＮ１３８は、有線ネットワーク、無線ネットワーク、それらの組合せなどとすることができる。そうしたネットワーク環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、および世界規模のコンピュータネットワーク（インターネットなど）ではよく見受けられるものである。
【００７４】
ローカルエリアネットワーク環境で使用されるときには、コンピュータ７０はネットワークインターフェースまたはアダプタ１４０を介してＬＡＮ１３６に接続される。広域ネットワーク環境で使用されるときには、コンピュータ７０は、通常、モデム１４２またはインターネットなどのＷＡＮ１３８を介して通信を確立するためのその他の手段を含む。モデム１４２は、内蔵とすることも外付けとすることもでき、ユーザ入力インターフェース１３４、またはその他の適当な機構を介してシステムバス７６に接続される。ネットワーク化環境では、コンピュータ７０に関連して示したプログラムモジュール、またはそれらの一部は、リモートメモリ記憶装置（図示せず）にも記憶され得る。例を挙げると、それだけに限らないが、図１６には、リモートアプリケーションプログラム１４４がメモリ装置上にあるものとして示されている。図示のネットワーク接続は例示のためのものであり、コンピュータ間で通信リンクを確立する他の手段も使用され得ることが理解されるであろう。
【００７５】
一般に、コンピュータ７０のデータプロセッサは、様々なときに、このコンピュータの様々なコンピュータ可読記憶媒体に記憶された命令によってプログラムされる。プログラムおよびオペレーティングシステムは、通常、例えば、フロッピー（登録商標）ディスクやＣＤ−ＲＯＭなどで配布される。それらは、そこから、コンピュータの２次メモリにインストールまたはロードされる。実行時に、それらの少なくとも一部が、コンピュータの１次電子メモリにロードされる。本明細書で説明した発明は、上記その他の様々な種類のコンピュータ可読記憶媒体が、マイクロプロセッサまたはその他のデータプロセッサと共に本明細書で述べた各ステップを実施するための命令またはプログラムを含むときには、それらの媒体を含むものである。また、本発明は、コンピュータが、本明細書で述べた方法および技法に従ってプログラムされたときには、そのコンピュータ自体も含むものである。
【００７６】
本明細書では、例示のために、オペレーティングシステムなどのプログラムおよびその他の実行可能プログラムコンポーネントを別々のブロックとして示してある。しかしながら、そうしたプログラムおよびコンポーネントは、様々なときに、コンピュータの様々な記憶コンポーネントに存在し、コンピュータの１つまたは複数のデータプロセッサによって実行されることが理解される。
【００７７】
以上本発明を、コンピュータ７０を含む例示的計算処理システム環境との関連で説明したが、本発明は、他の多数の汎用または専用計算処理システム環境または構成と共に動作する。この計算処理システム環境は、本発明の使用または機能の範囲に関するどんな限定も示唆するものではない。さらに、この計算処理システム環境は、例示的動作環境に示したコンポーネントのいずれか１つまたはそれらの組合せに関連するどんな依存性または要件も持つものではないと解釈すべきである。本発明と共に使用するのに適していると考えられる公知の計算処理システム、環境、および／または構成の例には、それだけに限らないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、携帯電話を含むプログラム可能な家庭用電化製品、ネットワークＰＣ、マイクロコンピュータ、メインフレームコンピュータ、前述のシステムまたは装置のいずれかを含む分散計算処理環境などが含まれる。
【００７８】
本発明の実施形態は、１つまたは複数のコンピュータまたはその他の装置によって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的状況で説明され得る。一般に、プログラムモジュールには、それだけに限らないが、ルーチン、プログラム、オブジェクト、コンポーネント、および個々のタスクを実施し、または個々の抽象データ型を実装するデータ構造が含まれる。また、本発明は、通信ネットワークを介してリンクされたリモート処理装置によってタスクが実施される、分散計算処理環境でも実施され得る。分散計算処理環境では、プログラムモジュールは、メモリ記憶装置を含む、ローカルとリモート両方のコンピュータ記憶媒体に位置し得る。
【００７９】
動作に際して、コンピュータ７０は、本明細書で述べたようなコンピュータ実行可能命令を実行して各ファイルをオブジェクトに編成する。この例では、それらのオブジェクトの少なくとも一部はコンポーネントを表し、それらのコンポーネントは、それぞれ、それらのファイルの少なくとも１つを含む。コンピュータ実行可能命令に従って、マニフェストが各コンポーネントを識別し、そのコンポーネントと他のオブジェクトの間の依存関係があればそれを指定する。マニフェストで指定された依存関係に従ってオブジェクトをグループ化することによって、ソフトウェア製品を構築することが可能になる。
【００８０】
本明細書で例示し、説明した方法の実行または実施の順序は、特に指定しない限り、必須ではないことに、当業者は気付くであろう。すなわち、特に指定しない限り、これらの方法の諸要素が任意の順序で実施され得ること、およびこれらの方法が、本明細書に開示したものより多い、または少ない要素を含み得ることが、発明者によって企図されている。
【００８１】
ユニフォームリソースロケータおよびその他のインターネットＷｅｂサイト参照を含めて、この文書中の情報は、予告なしに変更することがある。特に言及しない限り、本明細書に示した企業、組織、製品、ドメイン名、電子メールアドレス、ロゴ、人、場所または事象の例は、架空のものであり、実在の企業、組織、製品、ドメイン名、電子メールアドレス、ロゴ、人、場所または事象との関連は意図されず、あるいは推論すべきではない。
【００８２】
本発明の諸要素またはその実施形態を提示する際の、冠詞「ａ」、「ａｎ」、「ｔｈｅ」、および「ｓａｉｄ」は、それらの要素のうちの１つまたは複数が存在することを意味するためのものである。「備える」、「含む」、および「有する」という用語は包含的であることが意図され、列挙された要素以外の付加的要素があり得ることを意味するものである。
【００８３】
上記を考慮すると、本発明のいくつかの目的が達成され、その他の有利な結果が得られることが分かるであろう。
【００８４】
例えば、本発明の実施形態は、スケーラブルであり、拡張可能である。このコンポーネントリポジトリは、実行時システム上での比較的少数のコンポーネント（数百）から設計時システム上での比較的膨大な数のコンポーネント（数十万）まで追跡することができる。また、本発明によって実施されるスキーマは、追加のメタデータおよび新しいコンポーネントが様々な製品部門や第３者によって付加され得るように、十分に拡張可能である。このプログラミングモデルは、そのコアコンポーネント化枠組みを拡張するために一貫したやり方でそこに機能を付加することができるように、十分に拡張可能である。
【００８５】
本発明の範囲から逸脱することなく前述の構成および方法に様々な変更を加えることが可能であるため、前述の説明に含まれ、添付の図面に示されているあらゆる事柄は例示のためのものであり、限定的な意味でのものではないと解釈すべきである。
【００８６】
付録Ａ  
データ記憶および形式：オーサリングツールは、コンポーネント、機能、カテゴリ、パッケージ、製品およびＳＫＵを作成する。この例では、それらを（キャリアまたはマニフェストと呼ばれる）ＸＭＬファイルで表す。各キャリアは、機能またはカテゴリまたはパッケージまたは製品またはＳＫＵの１つのインスタンスだけを含む。ノートパッドマニフェストの一例を以下に示す。
【００８７】
【表１−１】
2005078650.tif 000003
【００８８】
【表１−２】
2005078650.tif 000004
【図面の簡単な説明】
【００８９】
【図１】本発明の実施形態によるコンピュータの一例を示す構成図である。
【図２】図１の１つのコンポーネントおよび対応するマニフェストを示す例示的構成図である。
【図３】本発明の実施形態によるコンポーネント定義スキーマの一例を示す図である。
【図４】本発明の実施形態によるコンポーネント定義スキーマの一例を示す図である。
【図５】本発明の実施形態によるコンポーネント定義スキーマの一例を示す図である。
【図６】本発明の実施形態によるコンポーネント定義スキーマの一例を示す図である。
【図７】本発明の実施形態によるコンポーネント定義スキーマの一例を示す図である。
【図８】本発明の実施形態によるコンポーネント定義スキーマの一例を示す図である。
【図９】図３〜図８のコンポーネント定義スキーマのオブジェクトをさらに示す図である。
【図１０】図３〜図８のコンポーネント定義スキーマのオブジェクトをさらに示す図である。
【図１１】図３〜図８のコンポーネント定義スキーマのオブジェクトをさらに示す図である。
【図１２】図３〜図８のコンポーネント定義スキーマのオブジェクトをさらに示す図である。
【図１３】本発明の実施形態による、ソフトウェア製品に含まれるべきコンポーネントを選択する設計プロセスの一例を示す図である。
【図１４】本発明の実施形態によるプログラミングオブジェクトモデルの一例を示す図である。
【図１５】図３〜図８のコンポーネント定義スキーマと共に使用するためのコンポーネント化アーキテクチャの一例を示す構成図である。
【図１６】図１での使用のためのコンピュータの例示的コンポーネントを示す構成図である。
【符号の説明】
【００９０】
１５０    コンピュータ
１５２    オペレーティングシステム
１５４    アプリケーション
１５６    コンポーネント
１５８    マニフェスト
【図１】
2005078650.tif 000005
【図２】
2005078650.tif 000006
【図３】
2005078650.tif 000007
【図４】
2005078650.tif 000008
【図５】
2005078650.tif 000009
【図６】
2005078650.tif 000010
【図７】
2005078650.tif 000011
【図８】
2005078650.tif 000012
【図９】
2005078650.tif 000013
【図１０】
2005078650.tif 000014
【図１１】
2005078650.tif 000015
【図１２】
2005078650.tif 000016
【図１３】
2005078650.tif 000017
【図１４】
2005078650.tif 000018
【図１５】
2005078650.tif 000019
【図１６】
2005078650.tif 000020