JP4716681B2 - ソフトウェアを拡張するための方法、システムおよび記録媒体 - Google Patents

Description

本技術分野は、拡張可能ソフトウェアシステムに関する。より詳細には、本技術分野は、拡張可能クラスの使用に関する。

コンピューティングの分野は、複数のプログラミング言語、多種多様なプロセッサ、および複数のオペレーティングシステム環境の普及によって、日ごとにますます複雑になりつつある。特別な機能を伴ういくつかのプログラミング言語（例えば、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｃ＃）が今や使用可能で、様々な計算機タスクをプログラムする際にプログラマに特別な利点を提供することができる。同様に、様々なプロセッサ（例えば、Ｘ８６、ＩＡ−６４、ＡＭＤなど）が使用可能で、特定のタスクを実行するための特別な利点を提供することができる。例えば、埋込みプロセッサは、特に電子装置内のよく定義されたタスクを処理するのに適しており、一方、インテル（Ｉｎｔｅｌ）（登録商標）ペンティアム（登録商標）（Ｐｅｎｔｉｕｍ（登録商標））プロセッサなどの汎用プロセッサは、より柔軟性があり、複雑なタスクを処理することができる。したがって、計算機環境、計算機構成および計算機装置における多様性は、増大しつつある。

この多様性の必要性が増大することにより、コンパイラプログラムを構築するというすでにかなり複雑な分野がさらに複雑になってきている。従来、コンパイラプログラムは、特定のソースコード言語で書かれたソフトウェアをコンパイルするために書かれ、特定のタイプのプロセッサアーキテクチャ（例えば、ＩＡ−６４、Ｘ８６、ＡＭＤ、ＡＲＭなど）をターゲットにしていた。より最近では、複数のソースコード言語で書かれたプログラムを単一の中間言語表現（例えば、ＣＩＬ（Ｃ＋＋中間言語）およびＭＳＩＬ（ドットネット（．ＮＥＴ）用のマイクロソフト（Ｍｉｃｒｏｓｏｆｔ）（登録商標）中間言語））に変換するトランスレータプログラムが導入されてきている。しかし、１つのソースコードプログラムのコンパイルをいくつかの異なるタイプのターゲットアーキテクチャ間で再ターゲット化することは、依然として複雑で時間がかかるものになっている。

複数の言語および複数のターゲットなど複数のソフトウェア開発シナリオのためのコンパイラおよび他のソフトウェア開発ツール（例えば、分析ツール、オプティマイザ）を構築する複雑さを低減するための１つの適した方法は、ソフトウェアの拡張性を追加して特別に構成したコンパイラおよび他のソフトウェア開発ツールを構築することができる拡張可能なコアインフラストラクチャまたはコアフレームワークを開発することである。例えば、ユーザが、ある種のターゲットアーキテクチャ用に構成されたＪＩＴ（ｊｕｓｔ−ｉｎ−ｔｉｍｅジャストインタイム）のコンパイラを構築したいと望む場合、コアコンパイラフレームワークのコードを再利用し、ＪＩＴコンパイラタイプのシナリオに特有のコードを伴う拡張を追加することによりＪＩＴコンパイラを生成することによってユーザのタスクをより簡単にすることができる。最適化ツール、分析ツール、性能ツール、テストツールなど他のソフトウェア開発ツールについても同じことを想定することができる。

かかる拡張可能なコアコンパイラおよびツールフレームワークを使用してかかるカスタマイズされたコンパイラおよび他のソフトウェア開発ツールを構築することは、それ自体一連の複雑さを伴わないわけではない。以上は、言語、ターゲットアーキテクチャ、および構築すべきコンパイラタイプ（例えば、ＪＩＴ、Ｐｒｅ−ＪＩＴ、ネイティブ最適化コンパイラ（Ｎａｔｉｖｅ Ｏｐｔｉｍｉｚｉｎｇ Ｃｏｍｐｉｌｅｒ）など）に依存する複数の異なるソフトウェアシナリオを反映する複数の異なる方法で構成することができる拡張可能なコンパイラおよびツールフレームワークの場合には、特に正しい。かかる複雑さの１つは、複数の異なるソフトウェアシナリオに依存した拡張フィールドを追加してそのコアフレームワークのデータ構造を拡張するようにした拡張可能な方法でコアフレームワークのデータ構造（例えば、オブジェクト指向言語におけるオブジェクトクラス）を定義することに関連している。クラス定義に拡張フィールドを追加する従来技法を使用することができるが、これは性能の低下およびコードの複雑さの増大による大幅な代償を支払うことによってのみ可能であり、開発コストおよびメンテナンスコストの増大がもたらされ得る。

したがって、複数の異なる可能なソフトウェア開発シナリオに依存する複数の異なるクラス拡張を使用してコアフレームワークソフトウェアシステムのオブジェクトクラスを拡張するための簡単ではあるが有効な方法が必要になっている。

本明細書中では、構成に依存する拡張クラス（ｅｘｔｅｎｄｅｄ ｃｌａｓｓ）を提供することによってソフトウェアプログラムを拡張するための方法およびシステムについて説明している。一態様では、様々なソフトウェア開発シナリオに依存するクラス拡張を提供し追加してコアクラス（ｃｏｒｅ ｃｌａｓｓ）を拡張する。様々なクラス拡張を組み合わせて、特別に構成されたクラスを開発する。一態様では、コアソフトウェアプログラムのクラスを静的または動的に拡張可能であるものとして定義することができる。コアクラスを静的に拡張可能であると宣言する場合には、コアクラス定義およびそれらの対応するクラス拡張を組み合わせたヘッダファイルを生成し一緒にコンパイルして拡張クラスを生成することができる。かかる拡張クラスを使用してコアソフトウェアプログラムを構成に依存する方法で拡張することができる。

しかし、コアクラスを実行時に動的に拡張可能であると宣言する場合には、コアクラス宣言を含む別個のヘッダファイルと拡張宣言を含む別個のファイルを生成することができる。次いで、コアクラスに対応するヘッダファイルとクラス拡張に対応するヘッダファイルを別々にコンパイルして、実行時にクラス拡張を追加してコアクラスを拡張するようにして互いにリンクを有するコンピュータ実行可能なファイルを生成する。

さらに別の態様では、拡張ポイントをコアクラス宣言内で提供してクラス拡張を挿入すべきコアクラス宣言内にこのポイントを特に指し示すことができる。拡張可能クラスおよびクラス拡張を定義する適切な構文を伴うオブジェクト記述言語についても本明細書中で説明している。

また、オブジェクト記述言語による入力を受け取り、ソースコード表現による出力を生成してソフトウェアプログラムの拡張バージョンを生成することができるプリプロセッサプログラムについても本明細書中で説明している。他の態様では、このプリプロセッサは、最終的にコンピュータが実行可能な形式にコンパイルすることができる任意の言語による出力を生成することができる。

ソフトウェア開発ツールの例
本明細書中に説明した技法では、主としてコンパイラを使用した例を用いて示しているが、これらの技法はどれも、他のソフトウェア開発ツール（例えば、デバッガ、オプティマイザ、逆アセンブラ、シミュレータ、およびソフトウェア分析ツール）に関連して使用することもできる。

拡張可能ソフトウェア開発ツールフレームワーク
図１は、複数のソフトウェア開発シナリオを反映した複数の異なる構成のカスタムコンパイラおよび他のソフトウェア開発ツールを構築するように拡張することができるコアソフトウェアフレームワークの一例を示している。このコア１１０は、カスタマイズされたソフトウェア開発ツール１１１〜１１４を構築するビルディングブロックとして使用することができる拡張可能なアーキテクチャを提供する。このコア１１０のソフトウェアは、１つまたは複数のソフトウェア開発シナリオに関連するソフトウェア拡張を加えることによって拡張することができる。例えば、ＩＡ−６４プロセッサ１２１をターゲットとするＪＩＴ（ジャストインタイム）コンパイラ１１１を、コア１１０に対するソフトウェア拡張を提供することによって構築することができる。このケースでは、コンパイラがＪＩＴコンパイラ１１１であり、特定のプロセッサアーキテクチャ（１２１におけるＩＡ−６４プロセッサ）をターゲットとしていることにより、コア１１０に対するソフトウェア拡張の形式および内容を決定することができる。したがって、ＪＩＴコンパイラシナリオおよびＩＡ−６４ターゲットシナリオに関連するソフトウェア拡張を使用してカスタマイズされたソフトウェア開発ツールを構築するための構成を指定することができる。ソース言語１０１〜１０４や、特定のソフトウェア開発シナリオに基づいて作動させ停止させることができるツールの機能など他のシナリオファクタが、図１のフレームワークなど標準のコアフレームワークを拡張することによりカスタムソフトウェア開発ツールを構築するタスクをより複雑にすることもある。

ソフトウェア開発シナリオの例
コアフレームワーク１１０に組み入れるべきソフトウェア拡張の選択に影響を与える可能性がある多数のソフトウェア開発シナリオがあり得る。例えば、特定のソフトウェア開発ツールについてのソフトウェア開発シナリオは、ツールのターゲットとなる様々なプロセッサアーキテクチャ（例えば、ＩＡ−６４、Ｘ８６、ＡＭＤ、ＡＲＭなど）を含み得る。また、実施されるコンパイルのタイプ（例えば、ＪＩＴ、Ｐｒｅ−ＪＩＴ、ネイティブ最適化コンパイラ）にソフトウェア開発シナリオを関係づけることもできる。分析、最適化、シミュレーション、デバッギング、コード生成などのタイプなどソフトウェア開発ツールが実施する他のタイプの機能にソフトウェア開発シナリオを関係づけることもできる。特定のプログラミング言語（例えば、Ｊａｖａ（登録商標）、Ｃ＋＋、Ｃ＃など）にさらに他のソフトウェア開発シナリオを関係づけることもでき、その言語用にソフトウェア開発ツールを特別に構成することができる。さらに、管理実行環境（例えばマイクロソフトのドットネットフレームワークが提供するマイクロソフトＣＬＲ環境）と共にそのツールを使用すべきか否かにもソフトウェア開発シナリオを関係づけることもできる。上述の例は、コアフレームワーク１１０を適切に拡張するのに必要とされる拡張の選択に影響を与え得る限定された１組のソフトウェア開発シナリオまたはファクタを提供しているにすぎない。同様に、他のシナリオでも、カスタムソフトウェア開発ツールを構成するのに必要とされるソフトウェア拡張の選択に影響を与える可能性がある。かかるシナリオを一括して、構成と呼ぶことができる。しかし、カスタムソフトウェア開発ツールの特定の構成に、単一のシナリオが影響を与えることもある。

オブジェクトの例
オブジェクト指向プログラミングでは、オブジェクトを使用してデータを記憶しそのデータについての機能にアクセスすることができる。オブジェクトは、クラス定義を提供することによって定義され、次いでこれらのクラス定義を使用してそのクラスに属するオブジェクトをインスタンス化することができる。

図２Ａは、変数またはデータメンバ（例えば、またはフィールド）２０１Ａ〜Ｃおよびメソッド（ｍｅｔｈｏｄ）２０２Ａ〜Ｃを有する例示のタイプ「自転車（ｂｉｃｙｃｌｅ）」についてのクラス定義２０１を示している。クラス２０１の特定のインスタンスは、オブジェクト２０２である。一般的に言うと、データメンバは、オブジェクトの状態を記述することができるのに対して、メソッドを使用して振る舞い（ｂｅｈａｖｉｏｒ）をそのオブジェクトに帰している。この例では、変数２０１Ａ〜Ｃには、クラス２０１のオブジェクト２０２をインスタンス化する場合、特定の値２０２Ａ〜Ｃが付与される。データメンバおよびメソッドは、ときに一括して「クラスメンバ」と呼ばれる。

同様に、１１０など拡張可能なコアフレームワークについてのクラス定義を提供してコア１１０を実装するために必要とされるデータ構造を記述することができる。さらに、様々なソフトウェア開発シナリオに従ってコアフレームワーク１１０を拡張するために、かかるソフトウェア開発シナリオに応じてコアクラスを変更することができ、また拡張することができる。

ソフトウェア拡張の例
選択済みのソフトウェア開発シナリオに従ってコアソフトウェアフレームワークを拡張する一方法は、ソフトウェアクラスを拡張することである。ソフトウェアクラスは、オブジェクトクラスの定義を変更することにより拡張することができる。

クラス拡張の例は、１つまたは複数のクラス拡張メンバ（例えば、データメンバまたはメソッド）を含み得る。クラスを拡張する場合には、クラス定義を修正して指定されたクラス拡張メンバを含める。

したがって、追加のクラスメンバを定義しそれらのコアクラス定義に組み込むことによってコアクラスを拡張することができる。これら追加のクラスメンバは、コアクラスを拡張するクラス拡張メンバと呼ぶこともある。一括して、かかるクラス拡張メンバを「クラス拡張（ｃｌａｓｓ ｅｘｔｅｎｓｉｏｎ）」と呼ぶこともある。

これらのクラス拡張は、いくつかの異なる方式で大いに異なり得る。例えば、一部のクラス拡張では必要とされるある種のクラスメンバが、他のクラス拡張では必要とされないこともある。またある種のクラス拡張内のメソッド、ファンクション、およびインターフェースは、他のクラス拡張では全く存在しないこともあり、あるいは存在する場合にも異なるように定義することができる。かかるクラス拡張メンバは、ソフトウェア開発シナリオに関係することもある。例えば、ＪＩＴコンパイラ１１１を構築するためにコンパイラフレームワークのコアクラスに追加すべき余分のフィールドまたはクラスメンバは、ネイティブ最適化コンパイラ１１３に関係するクラス拡張では必要とされ得るフィールドまたはクラスメンバの数に比べてずっと少ないこともある。

ソフトウェア開発シナリオクラス拡張セットの例
ソフトウェア開発ツールを構成するためのソフトウェア開発シナリオを開発者が決定した後、これらのそれぞれのクラス拡張を指定してコアソフトウェアフレームワークの拡張バージョンを開発することができる。次いで、適切なソフトウェア（例えば、プリプロセッサまたはコンパイラ）には、指定済みのシナリオを受け取りそのシナリオにとって適切な拡張セットを含めることができる。したがって、特定のソフトウェア開発シナリオについてのクラス拡張は、そのシナリオにとって適切な１つまたは複数のクラス拡張を有するソフトウェア開発シナリオクラス拡張セットにグループ化することができる。ソフトウェア開発ツールを開発する際に、このソフトウェア開発シナリオクラス拡張セットを呼び出して適切なクラスを拡張することができる。開発中または実行時にこれらのクラスを拡張することができる。

例えば、様々なソフトウェアクラスを使用してコア１１０を実装する。開発者が、ＪＩＴコンパイルおよびＩＡ−６４ターゲットアーキテクチャのソフトウェア開発シナリオを指定する場合、ＪＩＴコンパイラに関係するクラス拡張およびＩＡ−６４ターゲットアーキテクチャに関係するクラス拡張をコアクラス定義に組み込んでコアフレームワーク１１０のクラスを拡張してコアフレームワークの拡張バージョンを生成する際に使用する。

コアクラスとその拡張の間の関係を表現すること
図２Ｂは、コアクラス定義とそのクラス拡張の間の関係を示すブロック図である。コアノード２１０をコアクラスの定義に関係づけることができ、クラスメンバ１および２を有しているとして示している。２２０における拡張クラス定義が、特定のソフトウェア開発シナリオを実装するために必要なこともあり、この拡張定義は、拡張２２５を介して追加のクラスメンバ３および４を追加することができる。拡張クラス定義２３０は、２２０と同じであり、拡張２２５における同じ追加のクラスメンバ３および４をコアクラス定義２１０に追加することによって生成することができる。しかし、拡張クラス定義２６０は、異なっており、拡張２６５における追加のクラスメンバ５および６を追加することによって生成することができる。同様にして、拡張２４５および２５５をそれぞれクラス定義２２０および２３０に追加することによって拡張クラス定義２４０および２５０を拡張することができる。また、拡張２５５を拡張クラス定義２６０に追加することによって拡張クラス定義２７０を生成することができる。

図２Ｂの例では、クラス拡張は、複数のクラス拡張メンバを有するようにして示されている。しかし、クラス拡張は、１つまたは複数のクラス拡張メンバを有することもあり、コアクラス定義の１つまたは複数の既存のクラスメンバを置き換えることもあり得る。さらに、クラス拡張は、コアクラス定義中に見出されるメソッドメンバのファンクションの定義の形式のこともある。

したがって、コアソフトウェア開発ツールフレームワークについてのクラス定義の拡張は、図１の例示の拡張可能ソフトウェア開発ツールフレームワークの拡張バージョンの特定の構成に影響を与えることもある、コンパイルシナリオ（ＪＩＴ、Ｐｒｅ−ＪＩＴ、ネイティブ最適化コンパイラなど）、言語シナリオ（Ｃ＃、Ｖｉｓｕａｌ Ｂａｓｉｃなど）、ターゲットシナリオ（ＩＡ−６４、Ｘ８６、ＡＭＤ、ＡＲＭなど）および他の変数に依存した追加のクラス拡張と共に図２Ｂに示すように表現することができる。

しかし、多数のソフトウェア開発シナリオ（すなわち、ターゲット、コンパイルなど）に依存し得る特定の構成を用いてコアフレームワークについてのクラス拡張を表現し、または表すことによって、すぐにも非常に複雑になってしまう可能性がある。例えば、図２Ｂは、一部の簡略化された拡張ケースを示しており、それによって、拡張クラス定義２２０、２３０、２４０および２５０は、どれか１つの拡張を使用して複数の親クラスを拡張することなく、以前に定義済みのクラスから順番に継承している。しかし、これは、ソフトウェア開発ツールの特定の構成についての拡張クラスを表現する際における、クラス階層の様々なレベルで複数の異なる方法で拡張する必要があり得るケースとは異なる可能性がある。

例えば、１つの親クラスを拡張する代わりに、同じ拡張の一部を使用して複数の親クラスを拡張する必要もある可能性がある。例えば、拡張２５５を使用してクラス定義２３０ならびにクラス定義２６０を拡張することができる。したがって、ソフトウェア開発シナリオによっては、同じ拡張を使用して異なる親クラスを拡張することができる。かかる多重継承の可能性は、ソフトウェア開発シナリオおよび関係する拡張構成の純然たる数と相まって、コンピュータプログラマに途方もなく大きな重荷を負わせることになる。

１つのアプローチでは、コアクラス定義と拡張コアクラス定義の間の関係を、基底クラスとそのサブクラスの間の継承チェーンとしてプログラムすることができる。しかし、かかるアプローチは、クラスの肥大化をもたらす傾向があり、すぐにもプログラマに対する重荷になり得る。このアプローチでは、プログラマには、拡張サブクラスを手操作で開発するというタスクがあるだけでなく、未使用のオブジェクトを消滅させて限られたメモリリソースの使用を管理するという追加のタスクも存在することになる。

基底クラス定義の拡張に対するさらに別の手作業のアプローチは、条件付きコンパイルを実装するためのＩＦ−ＤＥＦステートメントまたは他の方法を使用したアプローチでもよい。かかるアプローチでは、プログラマは、基底クラス定義を提供することができ、また基底に対して拡張を条件付きで追加するためにその本体に拡張定義を含むＩＦ−ＤＥＦステートメントまたは他の条件付きコンパイルステートメントを手操作で追加することができる。このアプローチには、必要な場合だけにクラスを拡張する利点があり、したがって、望ましくないオーバーヘッドをもたらし得る、拡張ごとに新しいサブクラスを生成するアプローチに比べて、より良いアプローチになり得るものである。しかし、このアプローチも本質的には手操作によるアプローチであり、プログラマがＩＦ−ＤＥＦステートメントを可能な各構成ごとの多数のロケーションに含める必要があり、コードには多数のかかるＩＦ−ＤＥＦステートメントが散乱することになってしまう。

クラス拡張の生成、およびクラス拡張のオブジェクト記述言語を使用したコアクラスへの関連付けのための全体的な方法の一例
図３Ａは、コアフレームワークを拡張することによってコンパイラまたはツールを構築するためのコアクラス定義を拡張するための全体的な方法を示している。最初に３０２で、拡張を示すデータに出会い、３０４でソフトウェア開発ツールのクラスを拡張が指し示すように拡張する。

図３Ｂは、コアフレームワークを拡張するためのソフトウェアシナリオ依存の拡張を使用することによってコンパイラまたはソフトウェア開発ツールを構築するための全体的な方法を説明している。３１０で、簡略化されたＯＤＬ（ｏｂｊｅｃｔ ｄｅｆｉｎｉｔｉｏｎ ｌａｎｇｕａｇｅオブジェクト定義言語）を使用してコアクラスを定義することができる。次いで、３２０で、そのコンパイラタイプシナリオおよび構築する対象の特定のターゲットシナリオを含むソフトウェア開発シナリオに基づく特定のソフトウェア開発ツールのための構成を決定することができる。次いで、３３０で、構成に影響を与える各シナリオファクタに基づいて、オブジェクト記述言語を使用して拡張を定義してコアクラスを拡張するために必要とされる追加のまたは異なるクラス拡張メンバを表現する。３４０で、この拡張をコアクラスに関連づけてそのコアクラス定義を適切に拡張することができる。オブジェクト記述言語用の構文は、拡張可能または不可能であるとしてコアクラスの定義を規定し、さらに特定の１組のクラス拡張メンバを選択済みのコアクラスの拡張として関連づけるために提供される。かかる記述言語のための適切な構文については、以下でさらに例を用いて説明する。さらに、プリプロセッサ変換プログラムを使用してデータまたはオブジェクト記述言語をプログラミング言語のソースコードに変換することができる。かかる前処理の後、３５０で、拡張クラス定義をさらに処理し、拡張クラス定義を使用してコアフレームワークを拡張することにより、特定の構成のコンパイラまたは他のソフトウェア開発ツールを実装することができる。

上述の方法を使用して、複数の異なる拡張定義を別々に提供することができ、各拡張により、複雑な継承関係を全く保持する必要なしに必要なだけコアクラスまたは基底クラスを簡単に拡張することができる。コアクラスの特定の拡張を提供するプログラマは、コアクラスの他の拡張については知る必要がない。これによって、拡張を定義するタスクが簡単になるだけでなく、拡張コアクラスのユーザには、この拡張コアクラスを使用するためにコアクラス名を知る必要があるだけである。したがって、拡張クラス定義を使用する際に、クラス定義間の複雑な階層関係を記憶に留めるタスクからプログラマを解放することができる。

実行時にコアフレームワークプログラムを動的に拡張し、コアプログラムをコンパイルするのに先立ってコアフレームワークプログラムを静的に拡張すること
コアフレームワークプログラムを拡張するための１つのアプローチは、そのコアプログラムのソースコードファイルに対するアクセスを取得するアプローチ、およびこのオブジェクト記述言語を使用してこれらの拡張を定義することにより、コアクラスを必要に応じて静的に拡張するアプローチでもよく、次いでこれらの拡張を処理してこれらの拡張されたクラスに関係するソースコードを生成することができる。代わりに、ソースコードプログラミング言語中のソースコードに直接に手操作で拡張を追加することによって拡張クラスを生成することもできる。図４Ａにこのアプローチを示しており、それによって拡張４２０、４３０、および４４０をコアフレームワークファイル４１０に追加してそれを拡張し、次いで、拡張４２０、４３０、および４４０を今や拡張済みのコアフレームワークファイル４１０の一部としてコンパイルする。

しかし、４２０、４３０、４４０などの拡張の定義を提供するプログラマには、コアフレームワーク４１０のソースコードにアクセスできる必要があるはずなので、このアプローチは、すべての場合に適切ではない可能性がある。コアフレームワーク４１０の提供者がこのコアフレームワークソースコードを秘密または非変更のままに保ちたいと思っているような環境では、これが望ましくないこともある。このケースでは、図４Ｂに示す第２のアプローチを使用し、それによって拡張４６０、４７０および４８０とは別のファイルとしてコアコンパイラおよびツールフレームワーク４５０をコンパイルすることができる。

第２のアプローチでは、実行時に拡張をこのコアフレームワークに関連づけてこのコアフレームワークを適切に拡張するようにして、拡張４６０、４７０および４８０、ならびにコアフレームワーク４５０が、互いにリンクをもつようにすることができる。どの拡張を使用して特定のコアクラスを拡張すべきかを指定する簡単なリンクリストとしてこれらのリンクを実装することができる。これらの拡張をコアクラスに必要に応じ必要な場合に適切に関係づける簡単な命名規則を使用することによって、これを実現することもできる。第１のアプローチに比べてこの第２のアプローチでは、実行時にリンクするという態様に関係する追加のオーバーヘッド処理が必要とされることもあり、したがって、より低速な実装形態になることもある。他方、この第２のアプローチでは、コアフレームワークのソースコードへのアクセス権を持たない開発者によるコアクラスの拡張が可能になるという柔軟性がもたらされる。

コンパイルに先立ってコアクラスを静的に拡張する方法の一例
図５に、前述の図４Ａを参照して示すような、コンパイル時に先立ってコアフレームワークプログラムに関係するクラスを静的に拡張する方法を示す。オブジェクト記述言語を使用して、これらのコアクラスとその拡張を定義することができる。これらのコアクラスおよびそのクラス拡張の定義を同時または一緒に生成する必要はない。しかし、クラス拡張を追加するにはコアプログラムのソースコードに何らかのアクセスをする必要があるはずである。かかるクラス定義が取得された後に、次いで５１０で、オブジェクト記述言語表現をソースコード表現に変換することができるＯＤＬプリプロセッサによって、コアクラスおよびその拡張の定義を一緒に処理することになる。したがって５２０で、このＯＤＬプロセッサによる前処理の結果は、Ｃ＋＋などのソースコード言語におけるコアクラスの定義およびその拡張を表す、ヘッダファイルおよびたぶん何らかの他のコードとなるはずである。次いで、さらに５３０で、コアクラスメンバおよびそのクラス拡張メンバを含む拡張クラス定義をもつヘッダファイルは、今や拡張済みのコアフレームワークに関係するコードの残りと一緒にコンパイルされてカスタム構成されたコンパイラおよび他のソフトウェア開発ツールを生成するはずである。

図６に、図５の方法を実装するシステムの一例を示す。図６に示すように、コアクラス定義６２０に至る複数の拡張定義６１０をオブジェクト記述言語ファイルとして記憶することができる。コアクラス定義およびクラス拡張定義にそれぞれ対応するファイル６１０および６２０を受け取ることができるＯＤＬプリプロセッサ６３０を提供することができる。このプリプロセッサはまた、ファイル６１０および６２０をこれらのオブジェクト記述言語形式からソースコード表現６４０に変換することもできるべきである。このソースコード表現はどの言語で表すことも可能であり、これを最終的にはコンピュータプロセッサが実行可能な形式にコンパイルすることができる。プリプロセッサ６３０が生成するソースコード６４０は、ヘッダファイルを含むことができ、一般にこれらのヘッダファイルにクラス定義を記憶する。ソースコード表現６４０をコンパイルするためにプリプロセッサ６３０が出力するソースコード６４０の言語用に適切なソースコードコンパイラ６５０を提供して、コンパイラや他のソフトウェア開発ツールなどのコアソフトウェアプログラムのカスタマイズされた拡張バージョンを作成することができる。

実行時にコアクラスを動的に拡張する方法の一例
図７は、実行時に拡張を適切なコアクラスに関連づけることにより、拡張可能なコアフレームワークソフトウェアプログラムのコアクラス定義を拡張する方法を示している。これらのコアクラス定義およびその拡張は、オブジェクト記述言語を使用して別々に表現することができる。この記述言語は、コアクラス定義が動的に拡張可能であることを表現するのに適していることもある。また、かかる言語は、特定のコアクラス定義とその拡張の間の関連付けを表現するのに適していることもある。かかる１つの好適な言語のための構文について以下でさらに詳細に説明する。定義を表現した後に、７１０でＯＤＬプリプロセッサを使用して、７２０でこのオブジェクト記述言語表現中の定義をソースコード表現に変換する。しかし、静的プロセス（図６）と違って、図７の動的プロセスでは、コアクラス定義が、ＯＤＬプリプロセッサによってこれらの拡張の定義と一緒に処理されることはない。そうではなくて、コアクラス定義に対応するソースコードヘッダファイルとクラス拡張定義に対応するソースコードヘッダファイルは、別々に生成される。異なるＯＤＬプリプロセッサによってこれらを生成することができるが、必ずしもそのようにする必要はない。さらに７３０で、コアクラス定義を含むヘッダファイルとクラス拡張定義を含むヘッダファイルを別々にコンパイルしてコンピュータが実行可能な別々のファイルを作成する。しかし、７４０で、実行時にクラス拡張定義を適切なコアクラス定義に関連づけてこれらのコアクラスを定義に応じて拡張することができる。

図８に、図７の方法を実装するシステムの一例を示す。図８に示すように、クラス拡張定義が、オブジェクト記述言語で提供されファイル８１０に記憶される。図に示すように各クラス拡張を別のファイルとして記憶することは必ずしも必要ではない。コアクラス定義もまた、オブジェクト記述言語で提供され、ファイル８２０に記憶される。図７で説明した方法に従って、ＯＤＬプリプロセッサ８２５を提供して、コアクラス定義をオブジェクト記述言語表現からソースコード言語表現に変換することによってコアクラス定義を処理して、ヘッダファイル８３５として記憶する。同様にして、さらに別のＯＤＬプリプロセッサ８３０を提供してクラス拡張ファイル８１０を処理してクラス拡張を含むソースコードヘッダファイル８４０を生成することができる。ソースコードコンパイラ８４５を提供してクラス拡張ヘッダファイル８４０をコンパイルしてクラス拡張定義を含むコンピュータ実行可能ファイル８６０を生成することができる。同様に、ソースコンパイラ８５０を提供してコアクラス定義を含むヘッダファイル８３５をコンパイルしてコアクラス定義を含むコンピュータ実行可能ファイル８５５を生成することができる。次いで実行時に、コアクラス８５５に対応する実行可能ファイルとクラス拡張に対応する実行可能ファイルが実行される場合、コアと拡張クラスの間に提供されるリンク８７０によって、コアクラスが適切に拡張されるようにすることができる。

静的に拡張可能なクラス定義を提供するオブジェクト記述言語
以上で指摘したように、簡単なオブジェクト記述言語を使用して拡張可能コアフレームワークプログラムの所望の構成に依存したクラス定義を提供することができる。例えば、コアフレームワークの特定の構成は、コンパイラのタイプ（例えば、ＪＩＴ、Ｐｒｅ−ＪＩＴ、ネイティブ最適化など）、ターゲットのタイプ（例えば、ＩＡ−６４、Ｘ８６、ＡＲＭなど）、他のシナリオファクタなどのソフトウェア開発シナリオに基づいてクラス定義に異種の要求を行う可能性がある。以下の数段落では、以上の図５ないし図８を参照して説明したようなＯＤＬプリプロセッサで処理してソースコード言語によるクラス定義を生成することが可能な、かかる言語について説明している。

図９Ａは、オブジェクト記述言語を使用した標準的なクラス宣言を示している。一般的に、宣言９００は、ヘッダ９１１および本体９１２を含む。このヘッダを使用してクラスの可視性（ｖｉｓｉｂｉｌｉｔｙ）（例えば、公開、非公開など）、クラス名などを宣言することができる。９１３に示すように、ヘッダは、以下の例のような角括弧内に囲まれた属性定義も含む。

［ａｔｔｒｉｂｕｔｅ＿ｎａｍｅ］
この宣言を使用して、クラスが（例えば、ドットネットシナリオにおける）管理されたクラスであるか否かなどクラスの属性、およびクラスの拡張属性を定義することができる。例えば、それが管理されたクラスであるかどうかを定義することを、［ｇｃ］属性を宣言することによって行ってこのクラスのオブジェクトに対するガーベージコレクションが（例えば、ドットネットフレームワークによって）自動的に行われることを示すことができる。クラス拡張属性では、１つのアプローチは、すべてのクラスが前述のように静的に拡張可能であることを想定することである。したがって、クラスが静的に拡張可能であることを特に宣言するために特別な属性が必要とされないこともある。しかし、図１０Ａに示すように、実行時に（すなわち、動的に）拡張すべきクラスを［ｅｘｔｅｎｓｉｂｌｅ］などの特定の属性を用いて宣言することができる。

図９Ａに示す例では、クラスＳＹＭは、その本体にコアクラスメンバ９１４および９１５を有する静的に拡張可能なクラスである。クラス９００は、コアクラスとすることができ、クラスメンバＴＹＰＥ９１４およびＮＡＭＥ９１５は、コアクラスを用いたすべての構成依存の拡張クラスに共通のクラスメンバとすることができる。コアクラス９００を定義した後に、コアフレームワークの特定の構成についてのコアクラス定義の拡張バージョンを生成するクラス拡張を提供することができる。

図９Ｂは、オブジェクト記述言語によるかかる２つのクラス拡張定義９２０を示している。簡単にするために、クラス拡張の形式は、コアクラスの宣言または定義の形式に非常に類似している。拡張９２５は、ＪＩＴコンパイラをコアフレームワークから構築するためのＪＩＴコンパイルシナリオに関係するクラスメンバ９２６を示している。このＪＩＴコンパイルシナリオは、ＪＩＴコンパイラ構成に特有であるが他の構成に対しては必ずしもそうではない、インターフェース、メソッド、および変数などの特定のクラスメンバ９２６を必要とすることもある。したがって、ＯＤＬプリプロセッサが処理する場合に図９Ａのコアクラス定義を拡張する拡張９２５を提供することができる。９２７におけるキーワード「ｅｘｔｅｎｄ」は、これがコアクラスＳＹＭに対する静的な拡張であることを意味する。また、属性指定［ＪＩＴ］９２８は、コアフレームワークを拡張してＪＩＴコンパイラを実装する際だけにこの拡張を適用すべきであることを意味している。同様に、拡張９３０を適用してＩＡ−６４プロセッサをターゲットにするツールを構築するのに特有のクラスメンバ９３１を追加することができる。２つの拡張９２５および９３０は互いに独立であり、異なるパーティが提供することができ、これらの拡張は、従来のクラス−サブクラス間の依存性を使用してコアクラス定義を拡張するケースのように互いに依存し合う必要はない。さらに、プログラマは、複雑な依存関係を追跡する必要がない。

他のファクタによる他の拡張を提供することができる。例えば、Ｃ＋＋用の中間言語では、２つのファンクションシンボルを一緒に関連づける必要があることもある。このファンクションは、Ｃ＋＋用の中間言語を処理するように構成されたソフトウェア開発ツールに特有の拡張として追加することができ、そこでは、この拡張は、２つのファンクションシンボルを一緒に関連づけるメソッドを含むはずである。

例示のＪＩＴコンパイラに関係した拡張９２５および例示のＩＡ−６４ターゲットに関係した拡張９３０の実際の条件付き実装形態は、図９Ｃに示すようにＯＤＬプリプロセッサがその拡張クラス定義のソースコード表現を生成する場合に実装することができる。拡張クラス９４０は、コアクラス定義に関係する最初のクラスメンバをもつように示されるだけでなく、今や追加されたクラスメンバ９２６および９３１をもつようにも示されている。したがって、図に示す拡張クラスは、ＩＡ−６４プロセッサをターゲットとしたＪＩＴコンパイラを構成するためのクラス定義である。同様にして、複数の異なるソフトウェア開発シナリオに基づいた複数の異なる拡張を条件付きで追加してコアクラスを静的に拡張することができる。適切なソースコードコンパイラを使用してコンパイルする際に、拡張コアクラス９４０は、コアフレームワークのカスタマイズされたバージョンを生成する助けをすることになる。

動的な拡張クラス定義を提供するオブジェクト記述言語
静的な拡張の１つの不利な点は、コアフレームワークとその拡張を一緒にコンパイルしてコンピュータが実行可能な単一のファイルを生成することが必要なことにある。これは、拡張を提供している者が、拡張と一緒に再コンパイルするためにコアフレームワークのソースコードにアクセスできる必要もあることを意味する。いくつかの異なる理由から望ましくないこともあるこの状況を回避するためには、拡張クラス定義を実行時に生成することもできる。

図１０Ａは、オブジェクト記述言語（ＯＤＬ）を使用してコアフレームワークの拡張バージョンの特定の構成に基づいてコアクラス定義を動的に拡張するクラス宣言の一例を示している。クラスＩＮＳＴＲ１０１０についてのコアクラス定義は、これが動的に拡張可能なクラス宣言であることを意味する１０１１における属性「ｅｘｔｅｎｓｉｂｌｅ」を伴うヘッダを有している。クラス宣言１０１２の本体は、このフレームワークに共通のクラスメンバを有する。しかし、１０１１における属性［ｅｘｔｅｎｓｉｂｌｅ］は、ＯＤＬプリプロセッサで処理する場合、そのソースコードに対する拡張オブジェクトを生成し挿入し、これが、適切に関連づけられた拡張によってさらなるクラスメンバを追加して後ほど実行時に提供すべきプレースホルダとしての役割を果たすことが可能になる。図１０Ｂに、特定のターゲットシナリオに関連する、かかる１つの拡張１０２０を示す。この例では、拡張１０２０は、ＩＡ−６４ターゲットプロセッサ用のソフトウェア開発ツールを実装することに特有のＨＩＮＴＢＩＴＳ１０２１クラス拡張メンバおよびＰＲＥＤＩＣＡＴＥＳ１０２２クラス拡張メンバを追加する。属性［ＩＡ−６４］１０２３を使用して、この特定の拡張が、ＩＡ−６４プロセッサをターゲットとしたコアコンパイラおよびツールフレームワークのカスタマイズされた構成に適用可能であるにすぎないことを指し示す。キーワード１０２４「ｅｘｔｅｎｄ」を追加して、この拡張１０２０が１０２５におけるクラスＩＮＳＴＲの動的な拡張であることを指し示す。

以前に指摘したように、拡張クラスを動的に生成するケースでは、コアクラス定義１０１０およびクラス拡張定義１０２０を処理してコアクラス定義およびこれらの拡張の別々のソースコード表現が作成される。さらに、これらの別々のソースコード表現を後で別々にコンパイルしてコンピュータによって実行可能な別々のファイルを生成する。このケースでは、前述の静的な拡張とは異なり、コアクラス定義を拡張するのに必要とされるクラス拡張メンバは、拡張クラス定義と共にソースコードヘッダファイルに簡単には追加されない。そうではなくて、図１０Ｃに示すように、動的に拡張可能なクラス定義が実行時にコアクラス定義１０１０に追加すべきであると期待するＧＥＴクラス拡張およびＳＥＴクラス拡張に他のコード１０３１を追加することができる。したがって、静的な拡張に比べると、動的な拡張では、一部の追加のプロシージャ１０３１を実行して実行時にクラス定義を適切に拡張する必要があるという追加されたオーバーヘッドを有することがある。したがって、一般に、動的拡張では、プロセスの速度が低下するが、他方、このアプローチではコアおよびその拡張を別々にコンパイルすることができるので、拡張を提供するための柔軟性が追加される。これによって、サードパーティは、このコアフレームワークのソースコードにアクセスする必要なしにコアクラス定義に対して拡張を提供できるようになる。

図１１Ａに、動的に拡張可能なコアクラス定義１１１０のさらに他の例を示す。キーワード「ｅｘｔｅｎｓｉｂｌｅ」１１１１は、このクラスＩＮＳＴＲが拡張可能であり、このクラスの本体はまた、どのような拡張を追加するのにも先立ってそのクラスについてのクラスメンバを追加することを指し示す。クラスメンバメソッド１１１２のうちの１つはキーワード「ｅｘｔｅｎｓｉｏｎ ｐｏｉｎｔ」を有しており、これは、クラス拡張のうちの１つが、指定された拡張ポイント１１１２にメソッドまたはインターフェースＦＯＯ（）を具体的に定義することによって組み込まれることを意味する。

図１１Ｂは、ＩＡ−６４プロセッサをターゲットとした構成に必要とされるＨＩＮＴＢＩＴＳ１１２１クラス拡張およびＰＲＥＤＩＣＡＴＥＳ１１２２クラス拡張だけでなく、拡張ポイント１１１２によって示されるＦＯＯ（）メソッド１１２３の定義も提供することにより、図１１Ａに示す拡張可能クラスを拡張するための適切な動的拡張１１２０を示している。この「ｅｘｔｅｎｓｉｏｎ ｐｏｉｎｔ」というキーワードは、拡張を挿入できる、コアクラス定義の特定のポイントを示すためのさらにきめ細かい制御を提供する。さらに、適切な拡張に対して適切なポインタを自動的に生成するオブジェクト定義言語を使用することによってこれを簡単に行うことができる。同様にして、静的に拡張可能なコアクラス定義で拡張ポイントを表現することもできる。

ソフトウェア開発ツールをカスタマイズするための実装形態の一例
図１２は、複数のソフトウェア開発シナリオに従ってソフトウェア開発ツールを構築する実装形態の一例を示している。様々なソフトウェア開発シナリオに関係するクラス拡張を追加することによってコアクラス１２１０を拡張することができる。例えば、特定のターゲットアーキテクチャ１２２０（例えば、Ｘ８６、ＩＡ−６４など）のソフトウェア開発シナリオにクラス拡張を関係づけることができ、コンパイルシナリオ１２３０（例えば、ＪＩＴ、ネイティブなど）に他の拡張を関係づけることができる。同様に、他のソフトウェア開発シナリオが、拡張の選択に影響を与えることもある。例えば、ソフトウェア開発ツールの管理されたコード実装１２４０に特有な拡張もあり得るし、また拡張が１組のプログラミング言語のうちの１つを指し示すこともある。したがって、これらの様々な拡張の構成を追加して、コアクラス１２１０を拡張して拡張可能コアフレームワークを使用してソフトウェア開発ツール１２５０を構築することができる。

代替形態
本発明の原理を説明済みの実施形態に関して説明し例示してきたが、この説明済みの実施形態は、かかる原理を逸脱することなく、構成および詳細を変更することができることが理解されよう。本明細書中で説明した技術は、コンパイラを使用した例を用いて示してきたが、これら技術のいずれでも他のソフトウェア開発ツール（例えば、デバッガ、オプティマイザ、シミュレータ、およびソフトウェア分析ツール）を使用することができる。さらに、拡張を生成する原理を、主として本明細書中ではコアクラスを拡張することに関して説明してきたが、同じ原理を同様に適用してコアクラスの任意の拡張またはサブクラスを拡張することもできる。また、ＯＤＬプロセッサについて、以上ではオブジェクト記述言語を受け取りソースコード言語を生成することが可能であると言及している。しかし、ＯＤＬプリプロセッサの出力はソースコード言語だけに限定される必要はない。ＯＤＬプリプロセッサの出力は、マイクロソフトのドットネットのＣＩＬなど中間表現または中間言語、あるいはプロセッサが実行可能な任意の形式を出力として提供することもできる。

また、本明細書中で説明したプログラム、プロセス、または方法は、どのような特定のタイプのコンピュータ機器にも関係づけられ、または限定されないことを理解されたい。本明細書中で説明した教示に従って、様々なタイプの汎用または専用のコンピュータ機器を使用し、またはこれらによって動作を実施することができる。本明細書中で説明した動作を、かかる動作を実施するためのコンピュータ実行可能な命令を含むコンピュータ読取り可能媒体によって実現することができる。ソフトウェアで示された例示の実施形態の要素をハードウェアで実装することができ、逆もまた同様に可能である。本発明の原理を適用できる多くの可能な実施形態を考慮して、詳述された実施形態が例示にすぎず、本発明の範囲を限定するものと解釈すべきではないことを理解されたい。そうではなくて、本出願人は、以下の特許請求の範囲およびその等価物の範囲および趣旨に含まれ得るかかるすべての実施形態を、本発明として請求するものである。

構成に依存する拡張可能コアソフトウェアフレームワークの一例を示すブロック図である。 オブジェクト指向プログラミング言語の一例におけるクラスおよびオブジェクトとして実装されるデータ構造を示すブロック図である。 拡張可能なコアソフトウェアプログラムのクラスとその対応する拡張の間の関係を示すブロック図である。 クラス拡張を追加することによってクラス定義を拡張するための全体的な方法のフローチャートである。 構成に依存する、コアソフトウェアプログラムの拡張バージョンを生成する全体的な方法のフローチャートである。 拡張をコンパイル時に先立って静的に実装する、コアソフトウェアフレームワークの拡張バージョンを示すブロック図である。 拡張を実行時に動的に実装する、コアソフトウェアプログラムの拡張バージョンを示すブロック図である。 コアソフトウェアプログラムを静的に拡張する方法のフローチャートである。 図５に示す、コアソフトウェアプログラムを静的に拡張するシステムを示すブロック図である。 コアソフトウェアプログラムを動的に拡張する方法のフローチャートである。 図７に示す、コアソフトウェアプログラムを動的に拡張するシステムを示すブロック図である。 オブジェクト記述言語による静的に拡張可能なコアクラスのコアクラス宣言のリストである。 図９Ａの静的に拡張可能なコアクラス宣言に対する２つのクラス拡張のリストである。 図９Ａのコアクラス宣言を図９Ｂのクラス拡張に関連づけることによって生成される拡張クラス宣言のソースコード表現のリストである。 オブジェクト記述言語による動的に拡張可能なコアクラスのコアクラス宣言のリストである。 図１０Ａの動的に拡張可能なコアクラス宣言に対する拡張のリストである。 図１０Ａのコアクラス宣言を図１０Ｂのクラス拡張に関連づけることによって生成される拡張クラス宣言のソースコード表現のリストである。 クラス拡張を挿入する拡張ポイントを指し示すコアクラス宣言のリストである。 図１１Ａのコアクラス定義に対する拡張のリストである。 複数のソフトウェア開発シナリオに従ってソフトウェア開発ツールを構築する実装形態の一例を示すブロック図である。

符号の説明

１０１〜１０４ ソース言語
１１０ コアフレーム
１１１ ソフトウェア開発ツール（コンパイラ）
１１２〜１１４ ソフトウェア開発ツール
１２１ プロセッサ

Claims (11)

1. コアクラスの定義および拡張クラスの定義を格納するメモリ、プリプロセッサ、およびコンパイラを備えたシステムにおいて、ソフトウェアのコアクラスを拡張して、特定のソフトウェア開発シナリオに依存する前記ソフトウェアの拡張バージョンを生成することによって前記ソフトウェアを拡張する方法であって、前記ソフトウェア開発シナリオは、１または複数のシナリオファクタを定義し、前記シナリオファクタには、少なくともプロセッサアーキテクチャのタイプ、コンパイラのタイプ、およびプログラミング言語のタイプが含まれ、前記拡張クラスは、前記ソフトウェア開発シナリオの前記１または複数のシナリオファクタに基づいて選択される拡張メンバを含み、
   前記プリプロセッサが、前記コアクラスの定義を受け取るステップであって、前記コアクラスの定義には、当該コアクラスがコンパイル時に先立って静的に拡張可能、または実行時に動的に拡張可能のいずれであるかが定義されている、ステップと、
   前記プリプロセッサが、特定のソフトウェア開発シナリオを受け取るステップと、
   前記プリプロセッサが、前記受け取ったソフトウェア開発シナリオに従って、前記コアクラスを拡張するために必要な拡張クラスの定義を受け取るステップと
   を含み、
   前記コアクラスが静的に拡張可能であると示される場合、前記プリプロセッサが、前記コアクラスの定義および前記拡張クラスの定義を含むヘッダファイルを生成し、前記コンパイラが、当該ヘッダファイルをコンパイルして前記ソフトウェアの拡張バージョンを生成し、
   前記コアクラスが動的に拡張可能であると示される場合、前記プリプロセッサが、前記コアクラスの定義を含むヘッダファイル、および前記拡張クラスの定義を含むヘッダファイルを別々に生成し、前記コンパイラが、前記コアクラスの定義を含むヘッダファイル、および前記拡張クラスの定義を含むヘッダファイルを別々にコンパイルして、互いにリンクを有するコンピュータ実行可能ファイルを別々に生成し、実行時に前記拡張クラスを前記コアクラスに関連付けることにより、前記ソフトウェアの拡張バージョンを生成することを特徴とする方法。
2. 前記コアクラスの定義は、前記拡張クラスに含まれる前記拡張メンバを挿入する、前記コアクラス内のポイントを指し示す１つまたは複数の拡張ポイントを含むことを特徴とする請求項１に記載の方法。
3. 前記ソフトウェアは、拡張可能なコアコンパイラフレームワークであり、前記ソフトウェア開発シナリオは、生成されるコンパイラが対象とするコンパイラのタイプを前記シナリオファクタの１つとして含み、前記コンパイラのタイプに特有の拡張メンバを含む拡張クラスを用いて拡張されたコンパイラが生成されることを特徴とする請求項１に記載の方法。
4. 前記コンパイラのタイプは、ＪＩＴコンパイラ、Ｐｒｅ−ＪＩＴコンパイラ、およびネイティブ最適化コンパイラからなる群から選択されることを特徴とする請求項３に記載の方法。
5. 前記ソフトウェアは、拡張可能なコアソフトウェア開発ツールフレームワークであり、前記ソフトウェア開発シナリオは、生成されるソフトウェア開発ツールが対象とするプロセッサアーキテクチャのタイプを前記シナリオファクタの１つとして含み、前記プロセッサアーキテクチャのタイプに特有の拡張メンバを含む拡張クラスを用いて拡張されたソフトウェア開発ツールが生成されることを特徴とする請求項１に記載の方法。
6. ソフトウェアのコアクラスを拡張して、特定のソフトウェア開発シナリオに依存する前記ソフトウェアの拡張バージョンを生成することによって前記ソフトウェアを拡張するためのシステムであって、前記ソフトウェア開発シナリオは、１または複数のシナリオファクタを定義し、前記シナリオファクタには、少なくともプロセッサアーキテクチャのタイプ、コンパイラのタイプ、およびプログラミング言語のタイプが含まれ、前記システムは、
   コアクラスの定義および拡張クラスの定義を格納するメモリであって、前記コアクラスの定義には、当該コアクラスがコンパイル時に先立って静的に拡張可能、または実行時に動的に拡張可能のいずれであるかが定義されている、前記拡張クラスは、前記ソフトウェア開発シナリオの前記１または複数のシナリオファクタに基づいて選択される拡張メンバを含む、メモリと、
   前記コアクラスの定義および特定のソフトウェア開発シナリオを受け取り、当該ソフトウェア開発シナリオに従って、前記コアクラスを拡張するために必要な拡張クラスの定義を受け取り、クラスの定義を含むヘッダファイルを生成するプリプロセッサと、
   前記プリプロセッサが生成したヘッダファイルをコンパイルするコンパイラと
   を備え、
   前記コアクラスが静的に拡張可能であると示される場合、前記プリプロセッサが、前記コアクラスの定義および前記拡張クラスの定義を含むヘッダファイルを生成し、前記コンパイラが、当該ヘッダファイルをコンパイルして前記ソフトウェアの拡張バージョンを生成し、
   前記コアクラスが動的に拡張可能であると示される場合、前記プリプロセッサが、前記コアクラスの定義を含むヘッダファイル、および前記拡張クラスの定義を含むヘッダファイルを別々に生成し、前記コンパイラが、前記コアクラスの定義を含むヘッダファイル、および前記拡張クラスの定義を含むヘッダファイルを別々にコンパイルして、互いにリンクを有するコンピュータ実行可能ファイルを別々に生成し、実行時に前記拡張クラスを前記コアクラスに関連付けることにより、前記ソフトウェアの拡張バージョンを生成することを特徴とするシステム。
7. 前記コアクラスの定義は、前記拡張クラスに含まれる前記拡張メンバを挿入する、前記コアクラス内のポイントを指し示す１つまたは複数の拡張ポイントをさらに含むことを特徴とする請求項６に記載のシステム。
8. 前記システムは、前記コアクラスのコンピュータ実行可能ファイルを呼び出し、実行時に前記コアクラスに、前記拡張クラスに含まれる前記拡張メンバを挿入することによって、前記ソフトウェアの拡張バージョンを生成することを特徴とする請求項６に記載のシステム。
9. 前記ソフトウェアは、拡張可能なコアソフトウェア開発ツールフレームワークであり、前記ソフトウェア開発シナリオは、生成されるソフトウェア開発ツールが対象とするプロセッサアーキテクチャのタイプを前記シナリオファクタの１つとして含み、前記プロセッサアーキテクチャのタイプに特有の拡張メンバを含む拡張クラスを用いて拡張されたソフトウェア開発ツールが生成されることを特徴とする請求項６に記載のシステム。
10. 前記ソフトウェアは、拡張可能なコアソフトウェア開発ツールフレームワークであり、前記ソフトウェア開発シナリオは、生成されるソフトウェア開発ツールが対象とするコンパイラのタイプを前記シナリオファクタの１つとして含み、前記コンパイラのタイプに特有の拡張メンバを含む拡張クラスを用いて拡張されたソフトウェア開発ツールが生成されることを特徴とする請求項６に記載のシステム。
11. コアクラスの定義および拡張クラスの定義を格納するメモリ、プリプロセッサ、およびコンパイラを備えたシステムにおいて、ソフトウェアのコアクラスを拡張して、特定のソフトウェア開発シナリオに依存する前記ソフトウェアの拡張バージョンを生成することによって前記ソフトウェアを拡張する方法をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記ソフトウェア開発シナリオは、１または複数のシナリオファクタを定義し、前記シナリオファクタには、少なくともプロセッサアーキテクチャのタイプ、コンパイラのタイプ、およびプログラミング言語のタイプが含まれ、前記拡張クラスは、前記ソフトウェア開発シナリオの前記１または複数のシナリオファクタに基づいて選択される拡張メンバを含み、前記方法は、
    前記プリプロセッサが、前記コアクラスの定義を受け取るステップであって、前記コアクラスの定義には、当該コアクラスがコンパイル時に先立って静的に拡張可能、または実行時に動的に拡張可能のいずれであるかが定義されている、ステップと、
    前記プリプロセッサが、特定のソフトウェア開発シナリオを受け取るステップと、
    前記プリプロセッサが、前記受け取ったソフトウェア開発シナリオに従って、前記コアクラスを拡張するために必要な拡張クラスの定義を受け取るステップと
    を含み、
    前記コアクラスが静的に拡張可能であると示される場合、前記プリプロセッサが、前記コアクラスの定義および前記拡張クラスの定義を含むヘッダファイルを生成し、前記コンパイラが、当該ヘッダファイルをコンパイルして前記ソフトウェアの拡張バージョンを生成し、
    前記コアクラスが動的に拡張可能であると示される場合、前記プリプロセッサが、前記コアクラスの定義を含むヘッダファイル、および前記拡張クラスの定義を含むヘッダファイルを別々に生成し、前記コンパイラが、前記コアクラスの定義を含むヘッダファイル、および前記拡張クラスの定義を含むヘッダファイルを別々にコンパイルして、互いにリンクを有するコンピュータ実行可能ファイルを別々に生成し、実行時に前記拡張クラスを前記コアクラスに関連付けることにより、前記ソフトウェアの拡張バージョンを生成することを特徴とするコンピュータ読取り可能な記録媒体。

Images