【課題】動的型付け言語で記述されたソースコードを静的型付け言語のターゲットコードに変換する方法を提供する。
【解決手段】ソースコードからターゲットコードを記憶装置中に生成するステップであって、ソースコード中の呼び出し元で用いる関数／メソッドのシグネチャをバッファに格納するステップを含み、上記呼び出し元を生成するために必要なクラスであって、静的型付け言語のインタフェースを担当する当該クラス（以下、インタフェース担当クラス）の生成は、上記呼び出し元の関数／メソッド呼び出しのターゲットコードが実行される直前まで遅延される、上記生成するステップと、上記バッファに格納された全てのシグネチャに対応する１つのインタフェース担当クラスを上記記憶装置中に生成し、ロードするステップとを含む。上記バッファ中の全てのシグネチャは、上記１つのインタフェース担当クラスの生成に応じて削除される。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動的型付け言語で記述されたソースコードを静的型付け言語で記述されたターゲットコードに変換し、実行する方法、並びにそのコンピュータ・プログラム及びコンピュータ・システムに関する。
【背景技術】
【０００２】
近年、Ｗｅｂサーバ等において、例えばＰＨＰ及びＲｕｂｙのような動的型付け言語が広く使用されている。当該スクリプトは、通常、インタプリタ方式で実行されることが多い。しかし、応用によっては、高速な実行を可能にするために、当該スクリプトを例えばＪａｖａ（商標）仮想マシン（ＪａｖａＶＭ）上で直接的に動作するバイトコードに変換して実行したい場合がある。このような場合に、動的型付け言語で記述されたソースコードをＪａｖａ（商標）のような静的型付け言語で記述されたターゲットコードに変換する際に、メソッド／関数の呼び出し元を効率的に実行することは難しい。特に、現実的には、ソースコードの実行時に、上記スクリプト・ファイルをコンパイルしていくことが必要であり、そのコンパイルの効率的な方法が問題となる。この問題は、主に下記の２つの理由により生じている。第１に、Ｊａｖａ（商標）のような静的型付け言語には、単独で定義される関数が存在しない。そのために、動的型付け言語の関数／メソッドごとにＪａｖａ（商標）のクラスを用意する必要があるためである。第２に、動的型付け言語のプログラムにおいては一般に、呼び出し元の関数／メソッドを変換する際に、その呼び出し先の型を特定できないためである。Ｊａｖａ（商標）のReflection APIのようなリフレクション機構を使用すれば、簡単に変換できる。しかしながら、当該リフレクション機構は、実行時に、リフレクションによる大きなオーバヘッドを生じさせる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
上記リフレクション機構の使用を避けるために使われる方法として、動的型付け言語の関数／メソッドの実体ごとに実装を担当するクラスを用意し、固定のインタフェースを担当する特定のクラスを通じて呼び出せるようにする方法がある。しかしながら、当該方法では、呼び出し先の関数／メソッドの実装のために、関数／メソッドごとの数多くのクラスを用意しなければならない。そのため、上記クラス自体を記述するのに必要なメタ情報のために余分なメモリが積算されてしまい、結果としてＪａｖａＶＭなどの実行系の大きなメモリ領域を消費してしまうという不都合がある。
【０００４】
そこで、動的型付け言語で記述されたソースコードを静的型付け言語で記述されたターゲットコードに変換し、実行する際に、メモリ消費を抑える方法が求められている。
【課題を解決するための手段】
【０００５】
本発明は、動的型付け言語で記述されたソースコードを静的型付け言語で記述されたターゲットコードに変換する方法を提供する。当該方法は、コンピュータに下記ステップを実行させることを含む。当該ステップは、
上記ソースコードから上記ターゲットコードを記憶装置中に生成するステップであって、上記ソースコード中の呼び出し元で用いる関数／メソッドのシグネチャをバッファに格納するステップをさらに含み、上記呼び出し元を生成するために必要なクラスであって、静的型付け言語のインタフェースを担当する当該クラス（以下、インタフェース担当クラスともいう）の生成は、上記呼び出し元の関数／メソッド呼び出しのターゲットコードが実行される直前まで遅延される、上記生成するステップと、
上記バッファに格納された全てのシグネチャに対応する１つのインタフェース担当クラスを上記記憶装置中に生成し、ロードするステップであって、当該生成に応じて上記バッファ中の全てのシグネチャが削除される、上記生成し、ロードするステップと
を含む。
【０００６】
本発明の１つの実施態様では、上記方法がコンピュータは、コンピュータに下記ステップをさらに実行させることを含む。当該ステップは、
上記ソースコードに対応するターゲットコード中の関数／メソッドの呼び出し命令が実行されるときに、上記呼び出し元で用いられている関数／メソッドのシグネチャに対応するクラスであって、動的型付け言語における呼び出し先の関数／メソッドに対応する実装を担当する当該クラス（以下、実装担当クラスともいう）を上記記憶装置中に生成し、ロードするステップを含む。
【０００７】
本発明はまた、動的型付け言語で記述されたソースコードを静的型付け言語で記述されたターゲットコードに変換するコンピュータを提供する。当該コンピュータは、
上記ソースコードから上記ターゲットコードを記憶装置中に生成する生成部であって、当該生成部は上記ソースコード中の呼び出し元で用いる関数／メソッドのシグネチャをバッファに格納し、及び上記呼び出し元を生成するために必要なクラスであって、静的型付け言語のインタフェースを担当する当該クラス（インタフェース担当クラス）の生成は、上記呼び出し元の関数／メソッド呼び出しのターゲットコードが実行される直前まで遅延される、上記生成部と、
上記バッファに格納された全てのシグネチャに対応する１つのインタフェース担当クラスを上記記憶装置中に生成し、ロードする第１の処理部であって、当該生成に応じて上記バッファ中の全てのシグネチャが削除される、上記第１の処理部と
を含む。
【０００８】
本発明の１つの実施態様では、上記コンピュータは、上記ソースコードに対応するターゲットコード中の関数／メソッドの呼び出し命令が実行されるときに、上記呼び出し元で用いられている関数／メソッドのシグネチャに対応するクラスであって、動的型付け言語における呼び出し先の関数／メソッドに対応する実装を担当する当該クラス（実装担当クラス）を生成し、ロードする第２の処理部をさらに含む。
【０００９】
本発明の１つの実施態様では、上記シグネチャをバッファに格納することが、上記ソースコード内の同じ変換単位中に現れる呼び出し元の関数／メソッドのシグネチャに加えて、上記ソースコード内の別の変換単位中に現れる関数／メソッドのシグネチャを上記バッファ中に格納することをさらに含む。
【００１０】
本発明の１つの実施態様では、上記ソースコードから上記ターゲットコードを生成することが、上記ソースコード中の呼び出し元の関数／メソッド呼び出しの生成処理を含む。
【００１１】
本発明の１つの実施態様では、上記関数／メソッド呼び出しの生成処理が、
上記呼び出している関数／メソッドに対応するインタフェース担当クラスが生成済みかどうかを検査すること、
当該インタフェース担当クラスが生成済みでない場合に、上記呼び出している関数／メソッドのシグネチャを呼出関数リストに追加すること、
上記バッファに対応付けられた名前により、未生成のインタフェース担当クラスで型付けされた対象オブジェクトに対する関数／メソッド呼び出しのコードを上記記憶装置中に生成すること
を含む。
【００１２】
本発明の１つの実施態様では、上記関数／メソッド呼び出しの生成処理が、
上記呼び出している関数／メソッドに対応するインタフェース担当クラスが生成済みかどうかを検査すること、
当該インタフェース担当クラスが生成済みである場合に、当該生成済みのインタフェース担当クラスで型付けされた対象オブジェクトに対する上記関数／メソッド呼び出しのコードを上記記憶装置中に生成すること
をさらに含む。
【００１３】
本発明の１つの実施態様では、上記ソースコードから上記ターゲットコードを生成することが、上記ソースコード中の呼び出し元の関数／メソッド宣言の生成処理を含む。
【００１４】
本発明の１つの実施態様では、上記関数／メソッド宣言の生成処理が、
宣言されている関数／メソッドに対応するシグネチャがバッファ中にあるか、又はインタフェース担当クラスが生成済みであるか否かを検査すること、
上記宣言されている関数／メソッドに対応するシグネチャがバッファ中にない場合で、且つ、上記インタフェース担当クラスが生成済みでない場合に、宣言している関数／メソッドのシグネチャを宣言関数リストに追加すること
を含む。
【００１５】
本発明の１つの実施態様では、上記関数／メソッド宣言の生成処理が、
宣言されている関数／メソッドに対応するシグネチャがバッファ中にあるか、又はインタフェース担当クラスが生成済みであるか否かを検査すること、
上記宣言されている関数／メソッドに対応するシグネチャがバッファ中にない場合、又は、上記インタフェース担当クラスが生成済みでない場合に、対応するインタフェース担当クラスの名前を宣言インタフェース・リストに追加すること
を含む。
【００１６】
本発明の１つの実施態様では、上記関数／メソッド宣言の生成処理が、
上記宣言されている関数／メソッドの処理のスクリプトのバイトコードを上記記憶装置中に生成すること、
上記生成したバイトコードを宣言している関数／メソッドに対応させるコードを上記記憶装置中に生成することをさらに含む。
【００１７】
本発明の１つの実施態様では、上記インタフェース担当クラスを生成し、ロードすることが、
宣言関数リストが空であるか否かを検査すること、
上記宣言関数リストが空でない場合に、宣言インタフェース・リスト中に、バッファに対応付けられたインタフェース担当クラスの名前があるか否かを検査すること、
上記バッファに対応付けられたインタフェース担当クラスの名前がある場合に、宣言関数リスト及び呼出関数リスト中のシグネチャを上記バッファに追加すること
をさらに含む。
【００１８】
本発明の１つの実施態様では、上記インタフェース担当クラスを生成し、ロードすることが、
上記追加されたシグネチャから１つのインタフェース担当クラスを上記記憶装置中に生成し、ロードすること、
上記ロードされたインタフェース担当クラスの名前を宣言インタフェース・リストに追加すること
をさらに含む。
【００１９】
本発明の１つの実施態様では、上記インタフェース担当クラスを生成し、ロードすることが、
宣言関数リストが空であるか否かを検査すること、
上記宣言関数リストが空でない場合に、宣言インタフェース・リスト中に、バッファに対応付けられたインタフェース担当クラスの名前があるか否かを検査すること、
上記バッファに対応付けられたインタフェース担当クラスの名前がない場合に、宣言関数リスト中のシグネチャから、上記バッファとは独立した統合インタフェース担当クラスを生成及びロードすること、
上記ロードされたインタフェース担当クラスの名前を宣言インタフェース・リストに追加すること
をさらに含む。
【００２０】
本発明の１つの実施態様では、上記インタフェース担当クラスを生成し、ロードすることが、
宣言関数リストが空であるか否かを検査すること、
上記宣言関数リストが空である場合に、上記呼出関数リスト中のシグネチャを上記バッファに追加すること
をさらに含む。
【００２１】
本発明の１つの実施態様では、上記実装担当クラスを生成し、ロードすることが、上記ソースコードの変換単位に実装が存在しないシグネチャを持つ関数のダミーの実装を上記実装担当クラス中に用意することをさらに含む。
【００２２】
本発明の１つの実施態様では、上記コンピュータは、上記変換されたターゲットコードを実行する実行部をさらに含む。
【００２３】
本発明の１つの実施態様では、上記実行することが、
上記バッファ中のシグネチャ全てに対応する統合インタフェース担当クラスが利用されている場合に、当該ロードを要求すること、
当該要求に応じて、バッファ中の全てのシグネチャから１つの統合インタフェース担当クラスを生成し、ロードすること
をさらに含む。
【００２４】
本発明はさらに、コンピュータに、上記方法のいずれか１つに記載の方法の各ステップを実行させるコンピュータ・プログラムを提供する。
【発明の効果】
【００２５】
本発明の実施態様によれば、動的型付け言語で記述されたソースコードを静的型付け言語のターゲットコードに変換し、実行する際に、メモリ消費量を抑えることができ、ひいては効率的なシステム構築を可能にする。
【図面の簡単な説明】
【００２６】
【図１Ａ】変換の対象となりうるＰＨＰ言語で記述されたＰＨＰソースコード（start.php、funcs.php）の例を示す。
【図１Ｂ】図１ＡのＰＨＰソースコード（start.php）から、１スクリプト・ファイル１クラス方式により生成されるＪａｖａ（商標）クラス（Bytecode_start_php）の概要を示す。
【図１Ｃ】図１ＡのＰＨＰソースコード（funcs.php）から、１スクリプト・ファイル１クラス方式により生成されるＪａｖａ（商標）クラス（Bytecode_funcs_php）の概要を示す。
【図２Ａ】図１ＡのＰＨＰソースコード（start.php）から１関数１クラス方式により生成されるＪａｖａ（商標）の実装を担当するクラス（Bytecode_start_php）の概要を示す。
【図２Ｂ】図１ＡのＰＨＰソースコード（funcs.php）から１関数１クラス方式により生成されるＪａｖａ（商標）の実装を担当するクラス群（Bytecode_funcs_php、Bytecode_funcs_php_foo、Bytecode_funcs_php_bar）の概要を示す。
【図２Ｃ】図１ＡのＰＨＰソースコード（start.php）から１関数１クラス方式により生成される実装担当クラス、及びソースコードのターゲットコードへの変換並びにその実行の各ステップを示す。
【図３Ａ】図１ＡのＰＨＰソースコードから１関数１インタフェース方式により生成される実装担当クラス並びにインタフェース担当クラス、及びソースコードのターゲットコードへの変換並びにその実行の各ステップを示す。
【図３Ｂ】図１ＡのＰＨＰソースコードから１関数１インタフェース方式により生成される、foo()用のインタフェース担当クラス及びbar()用のインタフェース担当クラスの概要を示す。
【図３Ｃ】図１ＡのＰＨＰソースコードから１関数１インタフェース方式により生成される実装担当クラスBytecode_start_phpの概要を示す。
【図３Ｄ】図１ＡのＰＨＰソースコードから１関数１インタフェース方式により生成される実装担当クラスBytecode_funcs_phpの概要を示す。
【図４Ａ】図１ＡのＰＨＰソースコードから複数関数１インタフェース方式により生成される実装担当クラス並びにインタフェース担当クラス、及びソースコードのターゲットコードへの変換並びにその実行の各ステップを示す。
【図４Ｂ】図１ＡのＰＨＰソースコードから複数関数１インタフェース方式により生成される、foo()及びbar()共用の統合インタフェース担当クラスの概要を示す。
【図４Ｃ】図１ＡのＰＨＰソースコードから複数関数１インタフェース方式により生成される実装担当クラスBytecode_start_phpの概要を示す。
【図４Ｄ】図１ＡのＰＨＰソースコードから複数関数１インタフェース方式により生成される実装担当クラスBytecode_funcs_phpの概要を示す。
【図５】１関数１クラス方式（図２Ａ〜図２Ｃ）、１関数１インタフェース方式（図３Ａ〜図３Ｄ）及び複数関数１インタフェース方式（図４Ａ〜図４Ｃ）により生成されるインタフェース担当クラスの違いを示す。
【図６Ａ】１関数１インタフェース方式に従うバイトコード生成処理のフロー図を示す。
【図６Ｂ】図６Ａの関数／メソッド呼び出しの生成処理（ステップ６１４）及び関数／メソッド宣言の生成処理（ステップ６１６）の詳細なフロー図を示す。
【図６Ｃ】複数関数１インタフェース方式に従うバイトコード生成処理のフロー図を示す。
【図６Ｄ】図６Ｃの関数／メソッド呼び出しの生成処理（ステップ６５４）及び関数／メソッド宣言の生成処理（ステップ６５６）の詳細な処理フロー図を示す。
【図６Ｅ】図６Ｃのステップ６４３におけるバッファの処理の詳細な処理フロー図を示す。
【図６Ｆ】図６Ｃのステップ６４５−２における未ロードの統合インタフェース担当クラスの生成及びロードの詳細な処理フローを示す。
【図７】本発明の実施態様における、シグネチャ・インタフェース登録のデータ構造を示す。
【図８Ａ】変換対象となりうるＰＨＰ言語で記述されたＰＨＰソースコード（start.php、caller.php及びfuncs.php）があり、関数／メソッド呼び出しより先に関数／メソッド宣言がなされた例を示す。
【図８Ｂ】図８Ａに示すソースコードを複数関数１インタフェース方式により生成される実装担当クラス並びにインタフェース担当クラス、及びソースコードのターゲットコードへの変換及び実行の各ステップを示す。
【図９Ａ】変換対象となりうるＰＨＰ言語で記述されたＰＨＰソースコード（start.php、foo.php、bar.php）があり、未定の関数が現れる例を示す。
【図９Ｂ】図９Ａに示すソースコードを複数関数１インタフェース方式により生成される実装担当クラス並びにインタフェース担当クラス、及びソースコードのターゲットコードへの変換並びにその実行の各ステップを示す。
【図１０Ａ】ＣＲＭ（Customer Relationship Management）アプリケーションに対して、インタフェース担当クラスの数を削減した結果による効果の例を示す。
【図１０Ｂ】図１０Ａに示すＰＨＰソースコードにおける関数／メソッドの呼び出し元と呼び出し先との関係、及びファイル取り込み指示命令と指示されたファイルとの関係を示す。
【図１０Ｃ】図１０Ａに示すＰＨＰソースコードをＪａｖａ（商標）のバイトコードに変換した場合の変換及び実行ステップ、並びに各関数／メソッドの生成、宣言及び呼び出し実行の時系列を示す。
【図１０Ｄ】図１０Ａに示すＰＨＰソースコードを１関数１クラス方式により変換した場合の実装担当クラスを、図１０Ｃに記載の時系列とともに示す。
【図１０Ｅ】図１０Ａに示すＰＨＰソースコードを１関数１インタフェース方式により変換した場合の実装担当クラスを、図１０Ｃに記載の時系列とともに示す。
【図１０Ｆ】図１０Ａに示すＰＨＰソースコードを複数関数１インタフェース方式により変換した場合の実装担当クラスを、図１０Ｃに記載の時系列とともに示す。
【図１１Ａ】本発明の実施態様における、動的型付け言語で記述されたソースコードを静的型付け言語で記述されたターゲットコードに変換するためのシステム図を示す。
【図１１Ｂ】本発明の実施態様における、変換された結果としての実行オブジェクトと実行ヘルパーとの関係を示す。
【図１１Ｃ】本発明の実施態様における、バイトコード生成部及びシグネチャ・インタフェース登録部を示す図である。
【図１２】本発明の実施態様における、図１１Ａのシステムが備えているコンピュータ・ハードウェアのブロック図を示す。
【図１３Ａ】図２Ｃの変換及び実行ステップにおける処理の包含関係を示す。
【図１３Ｂ】図３Ａの変換及び実行ステップにおける処理の包含関係を示す。
【図１３Ｃ】図４Ａの変換及び実行ステップにおける処理の包含関係を示す。
【図１３Ｄ】図８Ｂの変換及び実行ステップにおける処理の包含関係を示す。
【図１３Ｅ】図９Ｂの変換及び実行ステップにおける処理の包含関係を示す。
【発明を実施するための形態】
【００２７】
特許請求の範囲及び明細書において用いている語について以下に説明をする。
【００２８】
本発明の実施態様において、「動的型付け言語」とは、変数の型がプログラミング時及びコンパイル時には決まらず、実行時になって決まる言語をいう。動的型付け言語は、例えばスクリプトで記述される。動的型付け言語は、例えばＰＨＰ、Ｒｕｂｙ、ＪａｖａＳｃｒｉｐｔ（商標）、Ｐｙｔｈｏｎ、及びＶｉｓｕａｌＢａｓｉｃ（商標）であるが、これらに限定されない。
本発明の実施態様において、「ソースコード」とは、動的型付け言語で記述されたプログラム・コードであって、変換の対象となるコードをいう。ソースコードは、スクリプトで記述されたコードであってもよい。
本発明の実施態様において、「静的型付け言語」とは、変数の型がプログラミング時又はコンパイル時に予め決まっている言語をいう。静的型付け言語は、例えば．ＮＥＴ、Ｊａｖａ（商標）、及びＣ＋＋であるが、これらに限定されない。
本発明の実施態様において、「ターゲットコード」とは、ソースコードを変換して得られる目的コードである。ターゲットコードは、中間コード又は機械語を含む。例えばＪａｖａ（商標）の場合、中間コードはバイトコードである。
本発明の実施態様において、「関数／メソッド」とは、言語によっても多少の違いはあるが、変換元の動的型付け言語及び変換先の動的型付け言語における関数／メソッドの定義がそのまま適用される。例えば、オブジェクト指向の定義では、関数とはメソッドの実装であり、メソッドとはオブジェクトに送られてきたメッセージを処理するものである。
本発明の実施態様において、「呼び出し元」とは、関数／メソッドを呼び出す側をいう。
本発明の実施態様において、「呼び出し先」とは、関数／メソッドを呼び出される側をいう。
本発明の実施態様において、「シグネチャ」とは、変換対象である呼び出し元で関数／メソッドを指定するシグネチャであり、関数／メソッドの名前と引数（パラメータ）の数をいう。動的型付け言語のシグネチャであるので、変数の型は不要である。また、静的型付け言語でもオプションであるような言語の場合には、型があってもよい。
本発明の実施態様において、「インタフェースを担当するクラス」（インタフェース担当クラス）とは、ソースコード中の呼び出し元を生成するために必要であり、静的型付け言語のインタフェース担当クラスをいう。また、インタフェース担当クラスでは、関数／メソッドのみ定義され、その動作を具体的に実現するコードが実装されていない。例えばＪａｖａ（商標）の場合、インタフェースがインタフェース担当クラスに該当する。インタフェース担当クラスの生成は、本発明の実施態様において、ソースコード中の呼び出し元の関数／メソッド呼び出し命令が実行されるまで生成されず、すなわちソースコード中の呼び出し元の関数／メソッド呼び出しのターゲットコードが実行される直前まで遅延される。言い換えれば、インタフェース担当クラスは、呼び出しのターゲットコードが実行される直前又はそれより前に生成される。呼び出しのターゲットコードが実行される前とは、例えばＪａｖａ（商標）の場合仮想マシンの実装に依存する。当該呼び出しのターゲットコードは、呼び出し元を含むコードであり、例えばＪａｖａ（商標）の場合はメソッド本体である。
本発明の実施態様において、「実装を担当するクラス」（実装担当クラス）とは、ソースコード中の呼び出し元で用いられている関数／メソッドのシグネチャに対応し、動的型付け言語における呼び出し先の関数／メソッドに対応する実装を担当するクラスをいう。また、実装担当クラスでは、関数／メソッド及び変数の動作を具体的に実現するコードが実装されている。例えばＪａｖａ（商標）の場合、抽象的クラスでなく、インタフェースで定義された関数／メソッドを全て実装するクラスが実装担当クラスに該当する。実装担当クラスからは、実行に必要なインスタンスが生成されプログラムが実行される。実装担当クラスの生成は、本発明の実施態様において、ソースコードに対応するターゲットコード中の関数／メソッドの呼び出し命令が実行されるときに行われる。
本発明の実施態様において、「変換、実行」とは、動的型付け言語のソースコードから静的型付け言語のターゲットコードに変換し、当該変換されたターゲットコードを実行することをいう。本発明の実施態様において、当該「変換」をコンパイルともいう。当該実行において、インタフェース担当クラスと、実装担当クラスとが使用される。
【００２９】
以下、図面に従って、本発明の実施態様を説明する。本実施態様は、本発明の好適な態様を説明するためのものであり、本発明の範囲をここで示すものに限定する意図はないことを理解されたい。また、以下の図を通して、特に断らない限り、同一の符号は、同一の対象を指す。
【００３０】
以下では、動的型付け言語としてＰＨＰ、静的型付け言語としてＪａｖａ（商標）を取り上げるが、本発明はこれらに限定されるものでない。
【００３１】
図１Ａは、変換の対象となりうるＰＨＰ言語で記述されたＰＨＰソースコード（start.php、funcs.php）の例を示す。
上記ＰＨＰソースコードは、２つのソースコードのファイルstart.php（１０１）及びfuncs.php（１０２）で構成されている。矢印１０３は、ファイルstart.php（１０１）のソースコード中の取り込み命令includeと、当該取り込み命令で指定されたファイルfuncs.php（１０２）との対応関係を示す。矢印１０４は、呼び出し元の関数foo()と呼び出し先の宣言及び定義された関数の対応関係を示す。同様に、矢印１０５は、呼び出し元の関数bar()と呼び出し先の宣言及び定義された関数の対応関係を示す。なお、これらのファイルを動的型付け言語で記述されたファイルという意味で、スクリプト・ファイルと呼ぶこともある。
【００３２】
次に、図１ＡのＰＨＰソースコード（start.php、funcs.php）を用いて、当該ソースコードをバイトコードに変換する際の従来技術の問題点を述べる。
ＰＨＰのような動的型付け言語で記述されたソースコードを、Ｊａｖａ（商標）のような静的型付け言語のバイトコードに変換し、実行する際に、シンボル・テーブルのふるまいの違いが問題になる。シンボルとは、変数、クラス、メソッド、関数の名前を特定する文字列である。シンボル・テーブルとは、当該シンボルとシンボルが指す変数又はクラスなどの実体との対応を格納したテーブルである。特に、変換先の言語であるＪａｖａ（商標）のクラス数の削減のために、ＰＨＰで記述された複数の関数／メソッドの実装を１つのコンパイル単位であるＪａｖａ（商標）のクラスに収めようとすると、その効率的な実装方法は自明でない。
例えば、図１Ａの２つのＰＨＰソースコードの各ファイル（１０１、１０２）がＪａｖａ（商標）の各クラスに対応するようにコンパイルする例を考えてみる。
ＰＨＰのソースコード中の１つの関数／メソッド当たり、Ｊａｖａ（商標）の１つのクラスを割り当てる方式を考えてみる。当該方法を、以下、１関数１クラス方式という。１関数１クラス方式については、図２Ａ〜図２Ｃにおいて詳述する。１関数１クラス方式では、非常に多くのクラスの生成と、そのロードが必要である。そのために、メモリフットプリントの増加乃至はクラス管理上のオーバヘッドの問題が生じる。
一方、ＰＨＰのソースコード中の１つのスクリプト・ファイル当たり、Ｊａｖａ（商標）の１つのクラスを割り当てる方式を考えてみる。当該方法を、以下、１スクリプト・ファイル１クラス方式という。１スクリプト・ファイル１クラス方式においては、図１Ｂ及び図１Ｃに示されるように、ＰＨＰソースコード（start.php（１０１）及びfuncs.php（１０２））それぞれに対応して、Ｊａｖａ（商標）の２つの実装担当Bytecode_start_php（１１１、図１Ｂ）及びBytecode_funcs_php（１１２、図１Ｃ）というをそれぞれ生成する。なお、当該Ｊａｖａクラスの名前は適当に付けられたものである。
【００３３】
図１Ｂは、図１ＡのＰＨＰソースコード（start.php）から、１スクリプト・ファイル１クラス方式により生成されるＪａｖａ（商標）クラス（Bytecode_start_php）（１１１）の概要を示す。
図１Ｃは、図１ＡのＰＨＰソースコード（funcs.php）から、１スクリプト・ファイル１クラス方式により生成されるＪａｖａ（商標）クラス（Bytecode_funcs_php）（１１２）の概要を示す。
図１Ｂ及び図１Ｃでは、Ｊａｖａ（商標）クラス（Bytecode_start_php、Bytecode_funcs_php）（１１１、１１２）を可読性のためにＪａｖａ（商標）のソースコードで示す。しかし、実際には、上記Ｊａｖａ（商標）クラス（Bytecode_start_php、Bytecode_funcs_php）（１１１、１１２）は、同等のＪａｖａバイトコードで記述されている。
【００３４】
実行は、図１ＢのＪａｖａ（商標）クラスBytecode_start_php（１１１）のメソッドexecuteScript()の呼び出し（Ａ０２）から始まる。同図３行目（Ａ０３）のinclude命令は、ファイルfuncs.php（１０２）を指定し取り込むことの命令である。図１ＣのＪａｖａ（商標）クラスBytecode_funcs_php（１１２）は、図１Ａに示すファイルfuncs.php（１０２）に対応する。上記include命令（Ａ０３）により、図１ＣのＪａｖａ（商標）クラスBytecode_funcs_php（１１２）の２行目（Ｂ０２）のメソッドexecuteScript()が呼び出される。なお、図１Ｃの８行目（Ｂ０８）の「PHPValue」は、ＰＨＰプログラムで扱われる値を保持するためのクラスを示す。
【００３５】
図１Ｂにおいて問題となるのは、４行目（Ａ０４）及び５行目（Ａ０５）のfoo()及びbar()の呼び出しの実装である。ＰＨＰプログラムでは、関数／メソッド宣言を含むスクリプトの実行（図１Ｃの３行目及び４行目）により、初めてその宣言されている名前で呼び出される関数／メソッドの実装が確定する。従って、各関数を静的（static）メソッドとして実装して、図１Ｂのfoo()又はbar()の呼び出しを、静的メソッド呼び出し（例えばinvokestatic命令）により単純に呼び出すようにすることは一般にはできない。なぜならば、それまでの実行状況により、どのような関数／メソッドが実際の呼び出し対象となるかは変わってくるためである。ある特定の呼び出し先を仮定して呼び出しコードを生成してしまうと、別のリクエストの処理の際に異なる関数宣言がなされた場合などに対応できなくなる。さらに、上記例の場合などにおいて、呼び出し元のスクリプト・ファイルstart.php（１０１）に対応する実装担当クラス（１１１）を実際に動作させてみるまで、すなわちinclude先のfuncs.phpを読み込んで動作させてみるまで呼び出し先が分からないことも多い。このような問題は、Ｊａｖａ（商標）のリフレクション機構を使用するか、或いは実直に宣言のたびにクラス・ロードを行うことにより対応可能にはなる。しかしながら、これらは、莫大な実行時オーバヘッドを伴う。
【００３６】
これらは、本質的には、ＰＨＰ、Ｒｕｂｙ等のスクリプト言語と、Ｊａｖａ（商標）言語との間で、シンボル解決の作法が違う点に起因している。Ｊａｖａ（商標）では、あるシンボルに対応するクラス又はメソッドの実体の定義のありかが、クラス・パスを通して暗黙的に特定のクラス・ファイルに定まる。また、Ｊａｖａ（商標）では、Ｓｅｒｖｌｅｔなどの標準的なサーバ側アプリケーションのプログラムは、その対応関係が複数のリクエスト処理に渡って同じであることを前提にして書かれるようになっている。一方、ＰＨＰ、Ｒｕｂｙ等では、各リクエスト処理のたびに、あるシンボルへの実体の対応を行うステップを踏むようになっており、それらアプリケーションのプログラムもそのように書かれる。あるシンボルへの実体の対応を行うステップを踏むとは、上記例のdeclare function相当である。
【００３７】
図２Ａ〜図２Ｃは、１関数１クラス方式を示す。
Ｊａｖａ（商標）の上記リフレクション機構を使用しない典型的な方法は、Ｊａｖａ（商標）のメソッド呼び出し機構を利用するものである。当該メソッド呼び出し機構を利用する方法では、PHPFunctionなどの固定のインタフェース（又は抽象クラス）によりインタフェースを担当するクラスを決め、ＰＨＰの関数ごとに当該インタフェースを実装（implements）する１つの実装担当クラスを生成する。そして、関数／メソッド呼び出しは、図２Ａに示すように常に当該インタフェースを通して行うようにする方法である。しかしながら、１関数１クラス方式により生成されるバイトコードは、図２Ｂに示すように、１つのスクリプトであるfuncs.phpから実装担当クラスが多数できてしまう。
１関数１クラス方式を図１Ａに示したＰＨＰソースコード（start.php、funcs.php）に適用した例を図２Ａ〜図２Ｃに示す。
【００３８】
図２Ａは、図１ＡのＰＨＰソースコード（start.php）から１関数１クラス方式により生成されるＪａｖａ（商標）の実装担当クラス（Bytecode_start_php）の概要を示す。当該クラスの名前は適当に付けられたものである。また、当該実装担当クラスを可読性のためにＪａｖａ（商標）のソースコードで示す。しかし、実際には、上記Ｊａｖａ（商標）の実装担当クラス（Bytecode_start_php）（２０１）は、同等のＪａｖａ（商標）バイトコードで記述されている。
実装担当クラス（Bytecode_start_php）（２０１）は、ＰＨＰのファイルstart.php（１０１）に対応して生成されたバイトコードである。
図２Ａの５行目（Ｃ０５）のconstant_Helloは、変換前の元のＰＨＰプログラム（図１Ａの１０１を参照）の”Hello”に相当する文字列リテラルを表すコンスタントであり、クラス変数などとして実装されている。関数呼び出しの実装bar()の引数は、元のＰＨＰプログラム（１０１）に応じて様々なものをとることができ、また、その返り値も様々な使われ方がされる。しかしながら、これらは本発明には直接的に関係しないので、ここではその説明を省略する。
【００３９】
図２Ｂは、図１ＡのＰＨＰソースコード（funcs.php）から１関数１クラス方式により生成されるＪａｖａ（商標）の実装担当クラス群（Bytecode_funcs_php、Bytecode_funcs_php_foo、Bytecode_funcs_php_bar）の概要を示す。当該実装担当クラス群は、それぞれ別のクラス・ファイルである。当該クラスの名前は適当に付けられたものである。また、当該実装担当クラスを可読性のためにＪａｖａ（商標）のソースコードで示す。しかし、実際には、上記Ｊａｖａ（商標）の実装担当クラス群（２０２、２０３、２０４）は、同等のＪａｖａ（商標）バイトコードで記述されている。
図２Ｂに示すように、１関数１クラス方式による変換では、ＰＨＰの１つのファイルfuncs.php（１０２）に対応して、Ｊａｖａ（商標）の３つの実装担当クラスBytecode_funcs_php（２０２）、Bytecode_funcs_php_foo（２０３）及びBytecode_funcs_php_bar（２０４）が生成される。すなわち、１つのスクリプト・ファイルから多数の実装担当クラスが生成される。多数の実装担当クラスの生成及びロードには多くのメモリが必要である。そのために、多数の実装担当クラスを生成し及びロードすることは、メモリフットプリントの増加乃至はクラス管理上のオーバヘッドの問題を生じる。
【００４０】
図２Ｃは、図１ＡのＰＨＰソースコード（start.php）から１関数１クラス方式により生成される実装担当クラス、及びソースコードのターゲットコードへの変換並びにその実行の各ステップを示す。
図２Ｃにおいて、左側が変換及び実行の各ステップ（Ｅ０１〜Ｅ１２）を示す。同右側が、１関数１クラス方式により生成される実装担当クラス（２１１、２１２、２１３及び２１４）を示す。すなわち、１関数１クラス方式では、ソースコード中の関数ごとに、１つのクラスが用意されている。さらに、同右側は、実装担当クラス（２１１）の関数executeScript()実装内容の一部として固定インタフェースを通じてinvoke()を呼び出している様子（２１５）を示す。実装担当クラスは、ボックス（２１１、２１２、２１３及び２１４、２１５）で示される。実装担当クラスの左側に付された矢印内の番号（Ｅ０２及びＥ０５）は上記ステップのステップ番号に対応する。
図２Ｃの実装を担当するクラスは、共通インタフェースを担当するクラスを拡張（extends）又は実装（implements）している。共通インタフェースとは、言語システム側で、予め準備して共通に使えるインタフェースである（図２Ｂの１１行目（Ｄ１１）と２１行目（Ｄ２１）のPHPFunction、及び図２Ｃの２行目（Ｅ０２）のthe common interface）。
【００４１】
以下、変換及び実行ステップについて説明する。
１行目（Ｅ０１）では、ＰＨＰのファイルstart.php（１０１）の取り込み命令includeが指示されている。そのサブステップとして２〜１２行目（Ｅ０２〜Ｅ１２）のステップが実行される。
２行目（Ｅ０２）では、ＰＨＰのファイルstart.php（図１Ａの１０１）中の関数foo()、bar()の呼び出し元の実装担当クラスの生成及びロードが指示されている。該指示に従い矢印（Ｅ０２）で示されるように、start.phpに対応する実装担当クラスBytecode_start_php（２１１）が、共通インタフェースで型付けされた対象オブジェクトに対するメソッド呼出しをともなって生成される。該クラスのコードは図２Ａに示され、Ｃ０4行目とＣ０5行目では、共通インタフェースPHPFunctionが、ソースコード上は明記されていないが、バイトコード上はメソッドinvoke()を備えたインタフェースとして指定されている。
３行目（Ｅ０３）では、ロードされた上記クラスBytecode_start_php（２１１）の実行が指示される。具体的には、図２Ａに示す実装担当クラスBytecode_start_php（２０１）のステップＣ０２〜Ｃ０６が実行され、先ずステップＣ０２の命令executeScript()が実行される。
４行目（Ｅ０４）では、図２ＡのステップＣ０３の取り込み命令includeが実行され、指定されたファイル funcs.php（図１Ａの１０２）が取り込まれる。
５行目（Ｅ０５）では、上記指定されたファイル funcs.phpに対応する実装担当クラスの生成及びロードが指示される。該指示に従って、矢印Ｅ０５に示すようにfuncs.phpに対応する実装担当クラスBytecode_funcs_php（２１２）が生成及びロードされる。
６行目（Ｅ０６）では、上記実装担当クラスBytecode_funcs_php（２１２）の実行が指示される。具体的には、図２Ｂに示されるBytecode_funcs_php（２０２）の２行目（Ｄ０２）のexecuteScript()の実行が行われる。
７行目（Ｅ０７）では、引き続き、図２Ｂの３行目（Ｄ０３）、４行目（Ｄ０４）の関数foo()及びbar()に対する宣言を行う。該宣言によって各関数の関数名foo及びbarと各関数の実装担当クラスBytecode_funcs_php_foo（２０３）、Bytecode_funcs_php_bar（２０４）から作られた関数オブジェクト（実体）が対応付けられる。
８行目（Ｅ０８）では、上記関数オブジェクトの関数テーブルへの登録を指示する。関数テーブルには、関数シグネチャと関数実体のオブジェクト（例えば、実装を担当するクラスのオブジェクト）との対応付けが記録される。これによって、関数呼び出しと、実際の処理を行う関数オブジェクト（実体）とが対応付けられて、Bytecode_funcs_php（２０２）の実行が終了する。そしてし、処理は実装担当クラスBytecode_start_php（２０１）のステップＣ０４に戻る。
９行目（Ｅ０９）では、上記Bytecode_start_php（２０１）のステップＣ０４の実行、すなわち関数名fooによる関数foo()の呼び出しが指示される。
１０行目（Ｅ１０）では、上記関数foo()の呼び出しに対応して、Ｅ０８で関数テーブルへ登録された関数foo()の実行が行われる。
１１行目（Ｅ１１）及び１２行目（Ｅ１２）では、関数bar()に対して上記９行目（Ｅ０９）、１０行目（Ｅ１０）と同様な実行が行われる。
【００４２】
図３Ａ〜図３Ｃは、各関数に対応する１つのインタフェースを用意する方式（以下、１関数１インタフェース方式）により生成されるインタフェース担当クラスの数の増大を示す。
１関数１インタフェース方式では、各関数／メソッドの呼び出し元ごとに対応するインタフェース担当クラスを用意する。これによって、ターゲットコードにおいて複数の関数／メソッドの実装を１つのＪａｖａ（商標）クラスにまとめることが可能になる。１関数１インタフェース方式では、ＰＨＰの関数／メソッドの実装担当クラスは、必要な関数／メソッドに対応するインタフェース担当クラス（図３Ａの３０１及び３０２を参照）を全て実装している。また、ＰＨＰの関数／メソッドの呼び出し部分は、それに対応するインタフェース担当クラスを通じて呼び出しを行う（図３Ａの３０４を参照）。インタフェース担当クラスを通じての呼び出しは例えばinvoke interfaceであり、当該invoke interfaceは図３Ａの３０４を実際のバイトコードにした場合の例である。
【００４３】
図３Ａは、図１ＡのＰＨＰソースコードから１関数１インタフェース方式により生成される実装担当クラス並びにインタフェース担当クラス、及びソースコードのターゲットコードへの変換並びにその実行の各ステップを示す。
図３Ａにおいて、左側が変換及び実行の各ステップ（Ｆ０１〜Ｆ１３）を示す。同右側が、１関数１インタフェース方式により生成される実装担当クラス（３０３及び３０４）及びインタフェース担当クラス（３０１及び３０２）を示す。さらに、同右側は、実装担当クラス（３０３）の実装内容の一部として、インタフェース担当クラスを通じて関数foo()及びbar()を呼び出している様子（３０７）を示す。すなわち、１関数１インタフェース方式では、呼び出し元の関数／メソッドごとにインタフェース担当クラスが（３０１、３０２）用意されており、該インタフェース担当クラス（３０１、３０２）に対応して実装担当クラス（３０３、３０４）が生成される。実装担当クラス及びインタフェース担当クラスの左側に付された矢印内の番号（Ｆ０２、Ｆ０３及びＦ０６）は上記ステップのステップ番号に対応する。
矢印（３０５及び３０６）は、実装担当クラス（３０４）が２つのインタフェース担当クラス（３０１及び３０２）を実装していることを示す。
【００４４】
図３Ｂは、図１ＡのＰＨＰソースコードから１関数１インタフェース方式により生成される、foo()用のインタフェース担当クラス及びbar()用のインタフェース担当クラスの概要を示す。
図３Ａのインタフェース担当クラス（３０１）の概要を、インタフェース担当クラス（３１１）として示す。同様に、図３Ａのインタフェース担当クラス（３０２）の概要を、インタフェース担当クラス（３１２）として示す。
インタフェース担当クラス（３１１）は、foo()用のインタフェース担当クラスである。インタフェース担当クラス（３１２）は、bar()用のインタフェース担当クラスである。インタフェース担当クラス（３１１及び３１２）は、可読性のためにＪａｖａ（商標）のソースコードで示されている。
【００４５】
図３Ｃは、図１ＡのＰＨＰソースコードから１関数１インタフェース方式により生成される実装担当クラスの概要を示す。
図３Ａの実装担当クラス（３０３）の概要を、実装担当クラス（３２１）として示す。実装担当クラス（３２１）は、ＰＨＰソースコード（start.php）（１０１）に対応する。実装担当クラス（３２１）は、可読性のためにＪａｖａ（商標）のソースコードで示されている。
【００４６】
図３Ｄは、図１ＡのＰＨＰソースコードから１関数１インタフェース方式により生成される実装担当クラスの概要を示す。
図３Ａの実装担当クラス（３０４）の概要を、実装担当クラス（３２２）として示す。実装担当クラス（３２２）は、ＰＨＰソースコード（funcs.php）（１０２）に対応する。実装担当クラス（３２２）は、可読性のためにＪａｖａ（商標）のソースコードで示されている。
【００４７】
以下、図３Ａの変換及び実行ステップについて説明する。
１行目（Ｆ０１）では、ＰＨＰソースコードのスクリプト・ファイルstart.php（１０１）の取り込み命令includeが指示されている。そのサブステップとして２〜１３行目（Ｆ０２〜Ｆ１３）の各ステップが実行される。
２行目（Ｆ０２）は、ＰＨＰのファイルstart.php（１０１）中の関数foo()及びbar()の呼び出し元の実装担当クラスの生成及びロードが指示されている。該指示に従い、矢印（Ｆ０２）で示すようにstart.php（１０１）に対応する実装担当クラスBytecode_start_php（３０３）が生成される。該Bytecode_start_php（３０３）のコードは図３Ｃの３２１に示されている。
３行目（Ｆ０３）では、上記関数foo()及びbar()のそれぞれの呼び出し用のインタフェース担当クラスの生成及びロードが指示されている。該指示に従い、矢印（Ｆ０３）で示すように、２つのインタフェース担当クラス（３０１及び３０２）が生成及びロードされる。なお、該インタフェース担当クラス（３０１、３０２）のコードはそれぞれ図３Ｂの３１１及び３１２に示されている。
４行目（Ｆ０４）では、ロードされている呼び出し元の実装担当クラス（３０３）の実行が指示されている。それによって、図３Ｃの実装担当クラスのコード（３２１）に示されているように、実装担当クラスのステップＨ０２のスクリプト実行命令executeScript()が実行される。
５行目（Ｆ０５）では、上記ステップＨ０２のスクリプト実行命令executeScript()の実行に応じて、ステップＨ０３の取り込み命令includeが実行され、そして指定されたファイルfuncs.php が取り込まれることを示す。ここで、これまでのstart.php（１０１）に対応する実装担当クラスBytecode_start_php（３０３）の実行は中断され、そして新たに取り込まれたＰＨＰファイルfuncs.php（１０２）に対応する実装担当クラス（３０４）の生成及びロードに移る。
６行目（Ｆ０６）では、取り込まれたファイルfuncs.phpに対応する実装担当クラスBytecode_funcs_php（３０４）のバイトコードの生成及びロードが指示される。該指示に従い、矢印（Ｆ０６）で示すようにファイルfuncs.phpに対応する実装担当クラス（３０４）が生成及びロードされる。なお、該実装担当クラス（３０４）のコードは、図３Ｄの３２２に示されている。各インタフェース担当クラスFunction_foo及びFunction_barが実装されて生成される。
７行目（Ｆ０７）では、上記funcs.phpに対応する実装担当クラス（３０４、図３Ｄの３２２）の実行が指示され、図３Ｄに示すステップ（Ｉ０２）のスクリプト実行命令 executeScriptが実行される。以下、９行目（Ｆ０９）まで当該実装担当クラス（３０４）の実行が続く。
８行目（Ｆ０８）では、スクリプト実行命令executeScriptの実行に引き続き、ステップ（Ｉ０３及びＩ０４）の関数宣言命令declareFunctionが実行されることを示す。上記関数宣言命令declareFunctionの実行によって、関数呼び出しfoo()及びbar()を実行するためのインスタンスが、実装担当クラス（３０４、図３Ｄの３２２）自身から生成される。
９行目（Ｆ０９）では、関数foo()及びbar()の実行コンテキストへの登録（declareFunction()）が行われる。具体的には、上記生成されたインスタンスと関数呼び出しfoo()及びbar()の関数名foo及びbarとが、関数テーブルに対応付けて登録される。関数呼び出しがあると関数テーブルからインスタンスを検索し、該インスタンスが有するメソッドfoo()及びbar()を利用して関数呼び出しを処理するためである。以上で、実装担当クラスBytecode_funcs_php（３０４）の実行が完了する。そして中断していた実装担当クラスBytecode_start_php（３０３）の実行に戻る。
１０行目（Ｆ１０）では、変換後のＪａｖａバイトコードを使って関数foo()の呼び出しが行われる。具体的には、中断していた実装担当クラスBytecode_start_php（３０３）のステップＨ０４（図３Ｃの３２１）で示されるように、呼び出し関数名fooから関数テーブルが検索され、対応付けていたインスタンスが見つけられる。
１１行目（Ｆ１１）では、関数foo()の実行を行う。具体的には、上記見つけられたインスタンスが備えているメソッドfoo()（関数foo()に対応）を呼び出し実行することで目的を実現している。このとき、インタフェース担当クラスFunction_foo（３０１、図３Ｂの３１１）で定義されている型に合わせるためインスタンスのキャストが行われる。
１２行目（Ｆ１２）では、変換後のＪａｖａバイトコードを使って関数bar()の呼び出しが行われる。具体的には、中断していた実装担当クラスBytecode_start_php（３０３）のステップＨ０５（図３Ｃの３２１）で示されるように、呼び出し関数名barから関数テーブルが検索され、対応付けていたインスタンスが見つけられる。
１３行目（Ｆ１３）では、関数bar()の実行を行う。具体的には、上記見つけられたインスタンスが備えているメソッドbar()（関数bar()に対応）を呼び出し実行することで目的を実現している。このとき、インタフェース担当クラスFunction_bar（３０２、図３Ｂの３１２）で定義されている型に合わせるためインスタンスのキャストが行われる。
なお、本来はこれに加えて様々なパラメータ数に対応する工夫が必要だがここでは発明に直接関係ないので省略する。
【００４８】
以上に説明したように、１関数１インタフェース方式では、呼び出し関数／メソッド毎にインタフェース担当クラスを生成してロードする必要がある。そのために、１関数１インタフェース方式では、上記１関数１クラス方式とは異なり、１関数／メソッドごとに実装担当クラスを用意する必要がなくなる。一方で、１関数１インタフェース方式では、１関数／メソッド毎にインタフェース担当クラスを用意する必要が生じる。従って、結局のところ、全体として多くのインタフェース担当クラスを生成する必要がある。ここで、インタフェース担当クラスは基本的にクラスと同じ特性を持ち、大量のものである。よって、１関数１インタフェース方式は１関数１クラス方式と比べて変わりないといえる。
【００４９】
図４Ａ〜図４Ｄは、本発明の実施態様に従う、複数の呼び出し関数／メソッドを１つの統合インタフェース担当クラスにまとめる方式（以下、複数関数１インタフェース方式）の説明を行う。当該複数関数１インタフェース方式では、単一のコンパイル単位（例えば、ファイル単位）で、生成及びロードされるインタフェース担当クラスを１つの統合インタフェース担当クラスにまとめる。それによって、インタフェース担当クラスの数を削減することが可能であり、消費メモリ量の削減に貢献する。当該統合されたインタフェース担当クラスを、以下において統合インタフェース担当クラスという。
複数関数１インタフェース方式では、ソースコードの複数の関数／メソッドの実装を１つの実装担当クラス中にまとめつつ、インタフェース担当クラスを実装担当クラスとは無関係に、投機的にまとめる。投機的とは、ソースコード中の関数の呼び出しに出会ったときという意味であり、その点においてソースコードに依存する。投機的にインタフェース担当クラスをまとめることによって、生成に必要なインタフェース担当クラスの数を減少させることが可能である。
本発明の実施態様において、動的型付け言語中の呼び出し元の関数／メソッドを、１関数１クラス方式のように静的型付け言語の１クラスに直接対応させるのではなく、静的型付け言語のインタフェース担当クラス（抽象クラス）に対応させる。それによって、呼び出し先の実装担当クラスが未定の場合或いは実行時に変化する場合であっても、効率的な呼び出し元のバイトコードの生成が可能になる。
【００５０】
図４Ａは、図１ＡのＰＨＰソースコードから複数関数１インタフェース方式により生成される実装担当クラス並びに統合インタフェース担当クラス、及びソースコードのターゲットコードへの変換並びにその実行の各ステップを示す。
図４Ａにおいて、左側が変換及び実行の各ステップ（Ｊ０１〜Ｊ１８）を示す。同右側が、複数関数１インタフェース方式により生成される実装担当クラス（４０３及び４０４）及び統合インタフェース担当クラス（４０２）を示す。すなわち、複数関数１インタフェース方式では、複数の関数／メソッドの呼び出し元に対して１つの統合インタフェース担当クラス（４０２）を生成し、統合インタフェース担当クラス（４０２）を実装した実装担当クラス（４０４）が生成される。さらに、同右側は、実装担当クラス（４０３）の実装内容の一部として統合インタフェースを通じて関数foo()及びbar()を呼び出している様子（４０６）を示す。実装担当クラス（４０３及び４０４）及び統合インタフェース担当クラス（４０２）の左側に付された矢印内の番号（Ｊ０２、Ｊ０３、Ｊ０５及びＪ０９）は上記ステップのステップ番号に対応する。
バッファ（４０１）は、個々の呼び出し元の関数／メソッドのシグネチャを一時的に格納するのに用いる記憶部である。１つの統合インタフェース担当クラスが、当該バッファに格納されていた１以上のシグネチャを用いて生成される。すなわち、統合インタフェース担当クラスは呼び出し元ごとに生成されるのではなく、同じコンパイル単位（例えばスクリプト・ファイル単位）で生成される。バッファ（４０１）は、図１１Ａで説明するバイトコード生成部（１１０６）内、又は他のＪａｖａ（商標）仮想マシン中のメモリ内に備えてもよい。本発明の実施態様において、バッファは統合インタフェース担当クラスを使用するために使用される。
複数関数１インタフェース方式では、複数の関数／メソッドの呼び出し元に対し、最初は関数／メソッドのシグネチャをバッファに記憶するのみで（４０１）、直ぐには統合インタフェース担当クラスの生成を行わない。統合インタフェース担当クラスの名前がバッファに対応付けて決められており、当該バッファにコンパイル単位で関数／メソッドのシグネチャが保存される。例えば、同じコンパイル単位（ソースコードファイルなど）中で現れる呼び出し元で使われるその他のシグネチャに加え、スクリプトをインクルードする処理などの解析によって得られる別のコンパイル単位中に現れるシグネチャもバッファにいれておいてよい。例えば、foo()及びbar()以外の関数／メソッドがあればその関数／メソッドのシグネチャをバッファにいれてもよい。呼出元の実装担当クラス（４０３）を実行する際になって初めて、上記バッファ（４０１）に格納された全てのシグネチャに対応する１つの統合インタフェース担当クラス（４０２）を記憶装置中に生成する。そして、当該関数／メソッドの呼び出しが実行されるときに、該１つの統合インタフェース担当クラス（４０２）を実装する実装担当クラス（４０４）を生成する。
【００５１】
図４Ｂは、図１ＡのＰＨＰソースコードから複数関数１インタフェース方式により生成される、foo()及びbar()共用の統合インタフェース担当クラスの概要を示す。
図４Ａの統合インタフェース担当クラス（４０２）の概要を、統合インタフェース担当クラス（４１１）として示す。統合インタフェース担当クラス（４１１）は、foo()及びbar()の両方についてのインタフェース担当クラスである。インタフェース担当クラス（４１１）は、可読性のためにＪａｖａ（商標）のソースコードで示されている。
【００５２】
図４Ｃは、図１ＡのＰＨＰソースコードから複数関数１インタフェース方式により生成される実装担当クラスBytecode_start_phpの概要を示す。
図４Ａの実装担当クラス（４０３）の概要を、実装担当クラス（４２１）として示す。実装担当クラス（４２１）は、ＰＨＰソースコード（start.php）（１０１）に対応する。実装担当クラス（４２１）は、可読性のためにＪａｖａ（商標）のソースコードで示されている。
【００５３】
図４Ｄは、図１ＡのＰＨＰソースコードから複数関数１インタフェース方式により生成される実装担当クラスBytecode_funcs_phpの概要を示す。
図４Ａの実装担当クラス（４０４）の概要を、実装担当クラス（４２２）として示す。実装担当クラス（４２２）は、ＰＨＰソースコード（funcs.php）（１０２）に対応する。実装担当クラス（４２２）は、可読性のためにＪａｖａ（商標）のソースコードで示されている。
【００５４】
以下、図４Ａの変換及び実行ステップについて説明する。
１行目（Ｊ０１）では、ＰＨＰソースコードのスクリプト・ファイルstart.php（図１Ａの１０１）の取り込み命令includeが指示されている。そのサブステップとして２〜１８行目（Ｊ０２〜Ｊ１８）の各ステップが実行される。
２行目（Ｊ０２）は、ＰＨＰのファイルstart.php（図１Ａの１０１）中の関数foo()及びbar()の呼び出し元の実装担当クラスの生成が指示されている。該指示に従い、矢印（Ｊ０２）で示すようにstart.php（図１Ａの１０１）に対応する実装担当クラスBytecode_start_php（４０３）が生成される。Bytecode_start_php（４０３）のバイトコードは図４Ｃの４２１に示されている。
３行目（Ｊ０３）では、上記関数呼び出しfoo()及びbar()のそれぞれのシグネチャがバッファ（４０１）に格納されることが指示される。該指示に従い、矢印（Ｊ０３）で示すように、バッファ（４０１）に各シグネチャが格納される。これは、インタフェース担当クラスの生成とロードを呼び出し元の実装コードを実際に実行する段階まで遅らせるためである。
４行目（Ｊ０４）では、上記実装担当クラスBytecode_start_php（４０３）がＪａｖａ（商標）仮想マシン上へロードされる。
５行目（Ｊ０５）では、上記関数呼び出しfoo()及びbar()のそれぞれのシグネチャをバッファ（４０１）からの取り出し、並びに統合インタフェース担当クラス（４０２）の生成及びロードが指示されている。該指示に従って、矢印（Ｊ０５）に示すように統合インタフェース担当クラス（４０２）が生成される。なお、統合インタフェース担当クラス（４０２）のコードは図４Ｂの４１１に示されている。
このように、呼び出し元の実装コードを生成するタイミング（２行目（Ｊ０２））ではなく、ロードするタイミング（４行目（Ｊ０４））や、好ましくは実行する段階になってクラス・ローダ（図１１Ａの１１０７）を通じてクラス（インタフェース）のロードが要求されるため、その時点で初めてバッファに溜まっているシグネチャのメソッドを全て備えたインタフェース担当クラスの生成及びロードがされる。インタフェース担当クラスが既にある場合には、ロードだけされる。
６行目（Ｊ０６）では、ロードされている呼び出し元の実装担当クラス（４０３）の実行が指示されている。それによって、図４Ｃの実装担当クラスのコード（４２１）に示されているように、実装担当クラスのステップＬ０２のスクリプト実行命令executeScript()が実行される。
７行目（Ｊ０７）では、上記ステップＬ０２に引き続き、ステップＬ０３の取り込み命令includeの実行が指示されている。そして、指定されたファイルfuncs.php（１０２）が取り込まれる。ここで、これまでのstart.php（１０１）に対応する実装担当クラスBytecode_start_php（４０３）の実行は中断され、新たに取り込まれたＰＨＰファイルfuncs.php（１０２）に対応する実装担当クラス（４０４）の生成、ロード、及び実行に移る。
８行目（Ｊ０８）では、funcs.php（１０２）で定義されている関数foo()及びbar()について、関数呼び出しfoo()及びbar()に対応するインタフェース担当クラス又は統合インタフェース担当クラス（４０２）が存在するか確認する。当該インタフェース担当クラスがなければ、それら関数呼び出しfoo()及びbar()を備えた新たな統合インタフェースを、ここで生成及びロードするが、ここでは該当しない。
９行目（Ｊ０９）では、取り込まれたファイルfuncs.php（図１Ａの１０２）に対応する実装担当クラスのバイトコード（４０４、図４Ｄの４２２）の生成及びロードが指示されている。該指示に従い、矢印（Ｊ０９）で示すようにファイルfuncs.php（図１Ａの１０２）に対応する実装担当クラス（４０４）が生成及びロードされる。なお、該実装担当クラス（４０４）のコードは、図４Ｄの４２２に示されている。該実装担当クラス（４０４）は、統合インタフェース担当クラスCallsite_start_php（４１１）を実装するものとして宣言して生成される。
ここで、ソース言語の関数の実装担当クラスのロードは、それらの関数の実行が必要になるまで遅延する。なお、すべてのコードの生成、ロード及び実行によりスクリプトの解釈実行を行う場合にはexecuteScript()のようなコードをすぐに実行する必要があるために遅延は意味をもたないが、インタプリタ方式による実行などを混在させる場合には、例えばexecuteScript()のようなコードを生成せずに、funcs.phpで定義されている関数登録のみ行うことも可能である。実装担当クラスのロードを遅延する理由は、実装担当クラスのロードがそのクラスが実装しているインタフェース担当クラスのロードを必要とするためであり、インタフェース担当クラスのロードを遅延できたほうがより多くのシグネチャをまとめて持たせることができて得策だからである。実装担当クラスをロードするときに（クラス・ローダがクラスをロードしようとすると、参照されていたりする別のクラスがある場合、解決しようとするときにその要求があることが分かる）に、まだ他のインタフェースに定義されていない関数／メソッドのシグネチャをシグネチャ・バッファに追加する。なお、実装がバッファ内のシグネチャの実装も利用もしない場合は、別個にシグネチャのリストを用意してもよい。実装担当クラス内にまだ使われていない関数（に相当する実装）が定義されていた場合には、その関数のシグネチャを備えた１つの統合インタフェース担当クラスを用意し、その上で当該統合インタフェース担当クラスの生成及びロードを行う。
１０行目（Ｊ１０）では、上記funcs.phpに対応する実装担当クラス（４０４）の実行が指示されており、図４Ｄに示すステップ（Ｍ０２）のスクリプト実行命令 executeScriptが実行される。
１１行目（Ｊ１１）では、上記ステップ（Ｍ０２）に続いて、ステップ（Ｍ０３及びＭ０４）の関数宣言命令declareFunctionが実行される。上記関数宣言命令declareFunctionの実行によって、関数呼び出しfoo()及びbar()を実行するためのインスタンスが実装担当クラス（４０４、図４Ｄの４２２）自身から生成される。
１２行目（Ｊ１２）では、上記生成されたインスタンスと関数呼び出しfoo()及びbar()の関数名foo及びbarが関数テーブルに対応付けて登録される。関数呼び出しがあると関数テーブルからインスタンスを検索し、該インスタンスが有するメソッドfoo()及びbar()を利用して関数呼び出しを処理するためである。以上で実装担当クラス（４０４）の実行は終了し、制御は実装担当クラス（４０２、図４Ｃの４２１）の分岐したステップ（Ｌ０３）の次のステップ（Ｌ０４及びＬ０５）へ進む。
１３行目（Ｊ１３）では、上記ステップ（Ｌ０４）により、関数foo()の呼び出し（invoke foo()）が実行される。
１４行目（Ｊ１４）では、上記ステップ（Ｌ０４）の準備段階として、呼び出し関数名fooから関数テーブルを検索し、対応付けていたインスタンスが見つけられる。
１５行目（Ｊ１５）では、該インスタンスが備えているメソッドfoo()（関数foo()に対応）を呼び出し実行することで目的を実現している。このとき統合インタフェース担当クラスCallsite_start_php（４０２、図４Ｂの４１１）で定義されている型に合わせるためインスタンスのキャストが行われる。
１６行目（Ｊ１６）では、上記ステップ（Ｌ０５）により、関数bar()の呼び出し（invoke bar()）が実行される。
１７行目（Ｊ１７）では、上記ステップ（Ｌ０５）の準備段階として、呼び出し関数名barから関数テーブルを検索し、対応付けていたインスタンスが見つけられる。
１８行目（Ｊ１８）では、該インスタンスが備えているメソッドbar()（関数bar()に対応）を呼び出し実行することで目的を実現している。このとき統合インタフェース担当クラスCallsite_start_php（４０２、図４Ｂの４１１）で定義されている型に合わせるためインスタンスのキャストが行われる。
以上で、ＰＨＰスクリプトをＪａｖａ（商標）のバイトコードに変換し、実行するステップは終了する。
【００５５】
図５は、１関数１クラス方式（図２Ａ〜図２Ｃ）、１関数１インタフェース方式（図３Ａ〜図３Ｄ）及び複数関数１インタフェース方式（図４Ａ〜図４Ｄ）により生成されるインタフェース担当クラスの違いを示す。
５０１は、１関数１クラス方式（図２Ａ〜図２Ｃ）により生成される実装担当クラス（２１１、２１２、２１３及び２１４）である。
５０２は、１関数１インタフェース方式（図３Ａ〜図３Ｄ）により生成されるインタフェース担当クラス（３０１、３０２）及び当該インタフェース担当クラス（３０１、３０２）の実装（３０５、３０６）を担当するクラス（３０４）を示す。
５０３は、複数関数１インタフェース方式（図４Ａ〜図４Ｄ）により生成される統合インタフェース担当クラス（４０２）及び当該統合インタフェース担当クラス（４０２）の実装（４０５）を担当するクラス（４０４）を示す。
１関数１インタフェース方式により生成されるインタフェース担当クラスの数は２である。一方、複数関数１インタフェース方式により生成される統合インタフェース担当クラスの数は１である。
なお、上記例では、２つの関数／メソッドの例で説明した。しかしながら、実際には多数の関数／メソッドに対して、複数関数１インタフェース方式を適用することが可能である。よって、複数関数１インタフェース方式を適用することで、インタフェース担当クラスの数は１つにまとめられることから、生成及びロードされるＪａｖａ（商標）のインタフェース担当クラスの数を減らすことが可能になる。
【００５６】
図６Ａ〜図６Ｂは１関数１インタフェース方式に従うバイトコード生成処理のフロー図であり、図６Ｃ、図６Ｄ及び図６Ｅは、複数関数１インタフェース方式に従うバイトコード生成処理のフロー図を示す。
【００５７】
図６Ａ及び図６Ｂは、１関数１インタフェース方式（図３Ａ〜図３Ｄ）に従うバイトコード生成処理のフロー図を示す。
図６Ａの左側の処理フロー（ステップ６０１〜６０５）は、１関数１インタフェース方式に従い、動的型付け言語で記述されたソースコードから、既にキャッシュされたものがない場合に静的型付け言語であるＪａｖａ（商標）で記述されたバイトコードを生成してキャッシュする処理を示すメインのフローである。バイトコードの生成は、下記図１１Ａに示すバイトコード生成部（１１０６）によって行われる。
ステップ６０１では、バイトコード生成部は、動的型付け言語で記述されたソースコードを静的型付け言語で記述されたターゲットコードに変換する処理を開始する。以下、動的型付け言語としてＰＨＰ言語、静的型付け言語としてＪａｖａ（商標）の場合を説明するが、これらの言語に限られるものではない。ソースコードはＰＨＰ言語の場合ＰＨＰ言語で記述されたスクリプトであり、ターゲットコードはＪａｖａ（商標）言語の場合バイトコードである。
ステップ６０２では、バイトコード生成部は、上記スクリプトからバイトコードを生成し、当該生成したバイトコードを記憶装置に格納する。ステップ６０２の詳細な内容は別途、下記ステップ６１１〜６１９、ステップ６２１〜６２６、及びステップ６３１〜６３８に示す。
ステップ６０３では、バイトコード生成部は、宣言インタフェース・リスト（図１１Ｃの１１３５）のインタフェースを持つ実装担当クラスとして、生成されたバイトコードのＪａｖａ（商標）の仮想マシンへのロードを実行する。ここで、宣言インタフェース・リスト（１１３５）とは、インタフェース担当クラス名の集合であり、上記図６Ｂのステップ６３４において追加されるインタフェースのリストである。なお、後述するように、本発明の実施態様である複数関数１インタフェース方式においても宣言インタフェース・リスト（１１３５）は使用される。しかしながら、複数関数１インタフェース方式で使用される宣言関数リスト（図１１Ｃの１１３６）及び呼出関数リスト（図１１Ｃの１１３７）は、１関数１インタフェース方式において使用されない。
なお、実装担当クラスの生成及びロードは、ステップ６０２及びステップ６０３において行われ、実装担当クラスが生成されるのは、スクリプト・ファイルがメモリ内に取り込まれバイトコードへ変換されるときである。
ステップ６０４では、Ｊａｖａ（商標）プログラム実行部（以下、プログラム実行部）（図１１Ａの１１１８）は、生成したバイトコードを実行する。ステップ６０４の詳細な内容は別途、下記ステップ６０４−１〜６０４−７に示す。
ステップ６０５で、プログラム実行部（又はＰＨＰランタイム・ヘルパー（図１１Ａの１１０５））は、上記スクリプトの処理を終了する。
【００５８】
図６Ａのステップ６０２の具体的な処理を、図６Ａの中央の処理フロー（ステップ６１１〜６１９）に従い説明する。
ステップ６１１では、バイトコード生成部は、スクリプトのバイトコードを生成する処理（６０２）を開始する。
ステップ６１２では、バイトコード生成部は、ＰＨＰスクリプト中の各命令を識別し、下記に示すステップ６１３、又はステップ６１３及び６１５の判定処理を繰り返す。
ステップ６１３では、バイトコード生成部は、上記識別された命令が関数／メソッド呼び出しか否かを判定する。当該命令が関数／メソッド呼び出しである場合（ＹＥＳ）、ステップ６１４に進む。一方、当該命令が関数／メソッド呼び出しでない場合（ＮＯ）、ステップ６１５に進む。
ステップ６１４では、バイトコード生成部は、関数／メソッド呼び出しの生成処理を実行する。当該生成処理が終了することに応じて、ステップ６１８へ進む。ステップ６１４の処理の詳細な内容は別途、下記ステップ６２１〜６２６に示す。
ステップ６１５では、バイトコード生成部は、上記識別された命令が関数／メソッド呼び出しでない場合、当該命令が関数／メソッド宣言か否かを判定する。当該命令が関数／メソッド宣言である場合（ＹＥＳ）、ステップ６１６へ進む。一方、当該命令が関数／メソッド宣言でない場合（ＮＯ）、ステップ６１７に進む。
ステップ６１６では、バイトコード生成部は、関数／メソッド宣言の生成処理を実行する。当該生成処理が終了することに応じて、ステップ６１８へ進む。ステップ６１６の処理の詳細な内容は別途、下記ステップ６３１〜６３８に示す。
ステップ６１７では、バイトコード生成部は、上記識別された命令が関数／メソッド呼び出し且つ関数／メソッド宣言でない場合、当該命令に対応するバイトコードの生成処理を実行する。当該バイトコードの生成処理の具体的な内容は、本発明の実施態様に直接関係しないのでここではその詳細は省略する。
ステップ６１８では、バイトコード生成部は、未処理の命令の有無を判定する。未処理の命令がある場合、ステップ６１２に戻り上記判定を繰り返す。未処理の命令がない場合、ステップ６１９に進む。
ステップ６１９では、バイトコード生成部は、上記スクリプトのバイトコードの生成処理（６１１）を終了し、処理の分岐元のステップ６０２へ戻る。
【００５９】
図６Ａのステップ６０４の具体的な処理を図６Ａの左側の処理フロー（ステップ６０４−１〜６０４−７）に示すが、説明の都合上、図６Ｂの説明の後にステップ６０４−１〜６０４−７の説明をする。
【００６０】
図６Ｂは、図６Ａの関数／メソッド呼び出しの生成処理（ステップ６１４）及び関数／メソッド宣言の生成処理（ステップ６１６）の詳細なフロー図を示す。
ステップ６１４の詳細な処理内容を、図６Ｂの左側の処理フロー（ステップ６２１〜６２６）に従い説明する。
ステップ６２１では、バイトコード生成部は、ソースコード中の呼び出し元の関数／メソッド呼び出しの生成処理を開始する。
ステップ６２２では、バイトコード生成部は、上記呼び出している関数／メソッドに対応するインタフェース担当クラスが生成済みであるか否かを検査する。インタフェース担当クラスが生成済みであるか否かは、シグネチャ・インタフェース登録のデータ構造を使用して判断される。なお、当該データ構造は、図７のデータ構造と基本的に同じであるが、インタフェース担当クラス名が行毎に異なる。
ステップ６２３では、バイトコード生成部は、上記呼び出している関数／メソッドに対応するインタフェース担当クラスが生成済みでない場合（ＮＯ）、ステップ６２５に進む。一方、上記呼び出している関数／メソッドに対応するインタフェースが生成済みの場合（ＹＥＳ）、ステップ６２４に進む。
ステップ６２５では、バイトコード生成部は、上記呼び出している関数／メソッドに対応するインタフェース担当クラスが生成済みでないので、当該インタフェース担当クラスを、一意になるように適当な名前で生成し、必要に応じてＪａｖａＶＭへロードできるようにしておく。なお、一意になるような名前付けは、例えば番号付けにより行われる。この際、シグネチャとインタフェース名の組を、図７のデータ構造中に登録する。ロード終了後、該ステップは、ステップ６２４に進む。
ステップ６２４では、バイトコード生成部は、上記呼び出している関数／メソッドに対応するインタフェース担当クラスを通じた関数／メソッド呼び出しのコードを生成する。当該生成されたコードが、ステップ６０４−１〜６０４−７で実行されるバイトコードである。当該関数／メソッド呼び出しコードが生成されると、当該ステップは、ステップ６２６に進む。なお、ステップ６２４は、図３ＣのＨ０４及びＨ０５に相当し、図３ＡのＦ０２の一環として、Ｆ０３の直後に行われる。
ステップ６２６では、バイトコード生成部は、上記関数／メソッド呼び出しの生成処理（６２１）を終了し、処理の分岐元のステップ６１４へ戻る。
【００６１】
次に、上記ステップ６１６の詳細な処理内容を、図６Ｂの右側の処理フローに従い説明する。
ステップ６３１では、バイトコード生成部は、ソースコードの関数／メソッド宣言の生成処理（６１６）を開始する。
ステップ６３２では、バイトコード生成部は、宣言されている関数／メソッドに対応するインタフェース担当クラスが生成済みであるか否かを検査する。
当該検査は、各関数定義の関数シグネチャが下記図７のシグネチャ・インタフェース登録のデータ構造中にあるか否かで判断される。
ステップ６３３では、バイトコード生成部は、上記宣言されている関数／メソッドに対応するインタフェース担当クラスが生成済みでない場合（ＮＯ）、ステップ６３５に進む。一方、当該インタフェース担当クラスが生成済みの場合（ＹＥＳ）、ステップ６３４に進む。
ステップ６３５では、バイトコード生成部は、上記宣言している関数／メソッドに対応するインタフェース担当クラスを、一意になるように（番号付けするなど）適当な名前で生成し、ロードする。この際、シグネチャとインタフェース名の組を、図７のデータ構造中に登録する。当該ロードが終了することに応じて、ステップ６３４に進む。
ステップ６３４では、バイトコード生成部は、上記生成されたインタフェース担当クラスに対応するインタフェース名を宣言インタフェース・リストに追加する。ここで、宣言インタフェース・リストとは、宣言された関数／メソッドに対応する呼び出し元のインタフェース名（インタフェース担当クラス名）をリスト形式で保持するデータ構造をいう。
ステップ６３６では、バイトコード生成部は、上記宣言されている関数／メソッドの処理（関数／メソッドの本体）のスクリプトのバイトコードをメモリ中（図１１Ａの１１０１）に生成する。当該生成されたバイトコードが、ステップ６０４−１〜６０４−７で実行されるバイトコードである。当該バイトコードの生成処理の具体的な内容は、既に説明した図６Ａのステップ６１１への再帰となる。
ステップ６３７では、バイトコード生成部は、上記生成したバイトコードを宣言している関数／メソッド名に対応させるコードをメモリ（１１０１）中に生成する。当該生成されたコードが、ステップ６０４−１〜６０４−７で実行されるバイトコードである。ステップ６３７で生成されるコードは、シンボル・テーブル（図１１Ａの１１０９）へ登録されるコードである。当該コードは、図３ＣのＨ０４及びＨ０５のlookupFunction()のような形で参照されるコードである。すなわち、ステップ６３７で生成されるコードは、ステップ６３６で生成されるバイトコード中の関数の実装を関数名に結びつけるコードである。
ステップ６３８では、バイトコード生成部は、上記関数／メソッド宣言の生成処理（６３１）を終了し、処理の分岐元のステップ６１６へ戻る。
【００６２】
図６Ａのステップ６０４の具体的な処理を、図６Ａの右側の処理フロー（ステップ６０４−１〜６０４−７）に従い説明する。
ステップ６０４−１では、Ｊａｖａ（商標）プログラム実行部（以下、プログラム実行部）は、ステップ６０２の一環としてステップ６２４、ステップ６３６及びステップ６３７で生成され、ステップ６０３でＶＭにロードされたバイトコードの実行を開始する。
ステップ６０４−２では、プログラム実行部は、上記生成されたバイトコードの各インストラクションを読み取る。
ステップ６０４−３では、プログラム実行部は、上記読み取ったインストラクションが“include”又は“include”相当の処理であるかどうかを判定する。
ステップ６０４−４では、プログラム実行部は、上記読み取ったインストラクションが“include”又は“include”相当の処理である場合、スクリプトの処理を行う。
ステップ６０４−５では、プログラム実行部は、上記読み取ったインストラクションが“include”且つ“include”相当の処理でない場合、その他のインストラクションの処理を行う。当該その他のインストラクションの処理は本発明の本質ではないのでここではその説明を省略する。
ステップ６０４−６では、バイトコードの各インストラクションの読み取りが全て終了するまで、ステップ６０４−２に戻る。
ステップ６０４−７では、バイトコードの実行を終了し、処理の分岐元のステップ６０４に戻る。
【００６３】
図６Ｃ、図６Ｄ及び図６Ｅは、複数関数１インタフェース方式（図４Ａ〜図４Ｄ）に従うバイトコード生成処理のフロー図を示す。
図６Ｃの左側のフロー（ステップ６４１〜６４６）は、複数関数１インタフェース方式に従い、動的型付け言語で記述されたソースコードから、既にキャッシュされたものがない場合に静的型付け言語であるＪａｖａ（商標）で記述されたバイトコードを生成してキャッシュする処理を示すメインのフローである。バイトコードの生成は、下記図１１Ａに示すバイトコード生成部（１１０６）によって行われる。
なお、図６Ｃの各ステップにおいて、図６Ａの１関数１インタフェース方式と異なる又は追加されたステップを網掛けで示す（ステップ６４３及びステップ６４５−２）。
ステップ６４１では、バイトコード生成部は、動的型付け言語で記述されたソースコードを静的型付け言語で記述されたターゲットコードに変換する処理を開始する。以下、動的型付け言語としてＰＨＰ言語、静的型付け言語としてＪａｖａ（商標）の場合を説明するが、これらの言語に限られるものではない。ソースコードはＰＨＰ言語の場合ＰＨＰ言語で記述されたスクリプトであり、ターゲットコードはＪａｖａ（商標）言語の場合バイトコードである。
ステップ６４２では、バイトコード生成部は、上記スクリプトからバイトコードを生成し、当該生成したバイトコードを記憶装置に格納する。ステップ６４２の詳細な内容は別途、下記ステップ６５１〜６５９、ステップ６６１〜６６７、及びステップ６７１〜６７８に示す。
ステップ６４３では、バイトコード生成部は、バッファの処理を実行する。当該バッファの処理は、生成した実装担当クラスにおいて、バッファ中のシグネチャの関数を宣言している場合に限り、バッファをクリアにする処理である。当該処理を行うために、宣言関数リスト（図１１Ｃの１１３６）及び呼出関数リスト（図１１Ｃの１１３７）を設ける。当該処理では、宣言関数リスト及び呼出関数リストを見ながら、条件的にバッファ（図１１Ｃの１１３３）中のシグネチャから統合インタフェース担当クラスを生成及びロード（図６Ｅ、６８８）するか、または、宣言関数リスト（１１３６）中のシグネチャからインタフェースを生成及びロード（図６Ｅの６８６）するか、または、インタフェースを生成しない（図６Ｅの６８２から６８３のパス）。バッファ処理の詳細な内容を別途、下記ステップ６８１〜６８９に示す。ステップ６４３は複数関数１インタフェース方式に特徴的なものであり、図６Ａに示す１関数１インタフェース方式にない。
ステップ６４４では、バイトコード生成部は、宣言インタフェース・リストのインタフェースを持つクラスとして、生成されたバイトコードをＪａｖａ（商標）仮想マシンへロードし、実行する。ここで、宣言インタフェース・リストとは、バッファと同じようにシグネチャの集合であり、上記「実装がバッファ内のシグネチャの実装も利用もしない場合は、別個にシグネチャのリストを用意してもよい」において別個に用意されるシグネチャのリストである。
なお、実装担当クラスの生成及びロードは、ステップ６４２〜６４４において行われ、実装担当クラスが生成されるのは、スクリプト・ファイルがメモリ内に取り込まれバイトコードへ変換されるときである。実装担当クラスは、ソースコードのスクリプト・ファイル毎に、対応する実装担当クラスが生成される。
ステップ６４５では、プログラム実行部（図１１Ａの１１１８）は、生成したバイトコードを実行する。ステップ６４５の詳細な内容は別途、下記ステップ６６４５−１〜６４５−８に示す。
ステップ６４６で、プログラム実行部（又はＰＨＰランタイム・ヘルパー（図１１Ａの１１０５））は、上記スクリプトの処理を終了する。
【００６４】
上記ステップ６４２の具体的な処理を、図６Ｃの真ん中の処理フロー（ステップ６５１〜６５９）に従い説明する。当該処理フロー（ステップ６５１〜６５９）は図６Ａに記載の処理フロー（６１１〜６１９）と、関数／メソッド呼び出しの生成処理（ステップ６５４）及び関数／メソッド宣言の生成処理（ステップ６５６）の詳細な処理内容が異なる以外、基本的に同じである。
ステップ６５１では、バイトコード生成部は、スクリプトのバイトコードを生成する処理（６４２）を開始する。
ステップ６５２では、バイトコード生成部は、ＰＨＰスクリプト中の各命令を識別し、下記に示すステップ６５３、又はステップ６５３及びステップ６５５の判定処理を繰り返す。
ステップ６５３では、バイトコード生成部は、上記識別された命令が関数／メソッド呼び出しか否かを判定する。当該命令が関数／メソッド呼び出しである場合（ＹＥＳ）、ステップ６５４に進む。一方、当該命令が関数／メソッド呼び出しでない場合（ＮＯ）、ステップ６５５に進む。
ステップ６５４では、バイトコード生成部は、関数／メソッド呼び出しの生成処理を実行する。当該生成処理が終了することに応じて、ステップ６５８へ進む。ステップ６５４の処理の詳細な内容は別途、下記ステップ６６１〜６６７に示す。
ステップ６５５では、バイトコード生成部は、上記識別された命令が関数／メソッド呼び出しでない場合、当該命令が関数／メソッド宣言か否かを判定する。当該命令が関数／メソッド宣言である場合（ＹＥＳ）、ステップ６５６へ進む。一方、当該命令が関数／メソッド宣言でない場合（ＮＯ）、ステップ６５７に進む。
ステップ６５６では、バイトコード生成部は、関数／メソッド宣言の生成処理を実行する。当該生成処理が終了することに応じて、ステップ６５８へ進む。ステップ６５６の処理の詳細な内容は別途、下記ステップ６７１〜６７８に示す。
ステップ６５７では、バイトコード生成部は、上記識別された命令が関数／メソッド呼び出し且つ関数／メソッド宣言でない場合、当該命令に対応するバイトコードの生成処理を実行する。当該バイトコードの生成処理の具体的な内容は、本発明の実施態様に直接関係しないのでここではその詳細は省略する。
ステップ６５８では、バイトコード生成部は、未処理の命令の有無を判定する。未処理の命令がある場合、ステップ６５２に戻り上記判定を繰り返す。未処理の命令がない場合、ステップ６５９に進む。
ステップ６５９では、バイトコード生成部は、上記スクリプトのバイトコードの生成処理（６５１）を終了し、処理の分岐元のステップ６４２へ戻る。
【００６５】
図６Ｃのステップ６４５の具体的な処理を図６Ｃの右側の処理フロー（ステップ６４５−１〜６４５−８）に示すが、説明の都合上、図６Ｅの説明の後にステップ６４５−１〜６４５−８の説明をする。
【００６６】
図６Ｄは、図６Ｃの関数／メソッド呼び出しの生成処理（ステップ６５４）及び関数／メソッド宣言の生成処理（ステップ６５６）の詳細な処理フロー図を示す。
なお、図６Ｄの各ステップにおいて、図６Ｂの１関数１インタフェース方式と異なる又は追加されたステップを網掛けで示す（ステップ６６５、６６６、６７２、６７３及び６７５）。
ステップ６５４の詳細な処理内容を、図６Ｄの左側の処理フロー（ステップ６６１〜６６７）に従い説明する。
ステップ６６１では、バイトコード生成部は、ソースコード中の呼び出し元の関数／メソッド呼び出しの生成処理を開始する。
ステップ６６２では、バイトコード生成部は、上記呼び出している関数／メソッドに対応するインタフェース担当クラスが生成済みであるか否かを検査する。インタフェース担当クラスが生成済みであるか否かは、図７のシグネチャ・インタフェース登録のデータ構造を使用して判断される。
ステップ６６３では、バイトコード生成部は、上記呼び出している関数／メソッドに対応するインタフェース担当クラスが生成済みでない場合（ＮＯ）、ステップ６６５に進む。一方、上記呼び出している関数／メソッドに対応するインタフェースが生成済みの場合（ＹＥＳ）、ステップ６６４に進む。
ステップ６６５では、バイトコード生成部は、上記呼び出している関数／メソッドのシグネチャを呼出関数リスト（図１１Ｃの１１３７）に追加する。ここで、呼出関数リストとは、呼び出し元に現れる（呼出対象の）関数のシグネチャをリスト形式で保存するデータ構造をいう。呼出関数リスト（１１３７）は、バイトコード生成部の一部として実装される。
ステップ６６６では、バイトコード生成部は、バッファに対応付けられた名前により、未生成のインタフェース担当クラスで型付けされた対象オブジェクトに対する関数／メソッド呼び出しコードを生成する。当該関数／メソッド呼び出しコードの生成自体は、名前を用いるだけであるので、この時点では実際に当該インタフェース担当クラスが存在する必要はない。当該コードを実行する段階になって、インタフェースなどのシンボル名の解決がクラス・ローダ（図１１Ａの１１０７）によって行われ、そのタイミングで実際の統合インタフェース担当クラスをバッファの全てのシグネチャから生成する。当該関数／メソッド呼び出しコードが生成されると、当該ステップは、ステップ６６７に進む。
ステップ６６４では、バイトコード生成部は、上記呼び出している関数／メソッドに対応するインタフェース担当クラスを通じた関数／メソッド呼び出しコードを生成する。当該生成されたコードが、ステップ６４５−１〜６４５−８で実行されるバイトコードである。当該関数／メソッド呼び出しコードが生成されると、当該ステップは、ステップ６６７に進む。なお、ステップ６６４で生成されるコードは、図４ＣのＬ０４及びＬ０５に相当し、図４ＡのＪ０２の一環として、Ｊ０３と並行して又は前後に行われる。
ステップ６６７では、バイトコード生成部は、上記関数／メソッド呼び出しの生成処理（６６１）を終了し、処理の分岐元のステップ６５４へ戻る。
【００６７】
図６Ｃのステップ６５６の詳細な処理内容を、図６Ｄの右側の処理フローに従い説明する。
ステップ６７１では、バイトコード生成部は、ソースコードの関数／メソッド宣言の生成処理（６５６）を開始する。
ステップ６７２では、バイトコード生成部は、宣言されている関数／メソッドに対応するシグネチャがバッファ中にあるか、又は、インタフェース担当クラスが生成済みであるか否かを検査する。インタフェース担当クラスが生成済みであるか否かの検査は、各関数定義の関数シグネチャが下記図７のシグネチャ・インタフェース登録のデータ構造中にあるか否かで判断される。
ステップ６７３では、バイトコード生成部は、当該シグネチャが既出でない場合、すなわち上記宣言されている関数／メソッドに対応するシグネチャがバッファ中にない場合で、且つ、インタフェース担当クラスが生成済みでない場合（ＮＯ）にステップ６７５に進む。一方、当該シグネチャが既出の場合、すなわち当該シグネチャがバッファ中にある場合、又は、当該インタフェース担当クラスが生成済みのいずれかの場合（ＹＥＳ）に、ステップ６７４に進む。
ステップ６７５では、バイトコード生成部は、上記宣言している関数／メソッドのシグネチャを宣言関数リストに追加する。追加したら、ステップ６７６に進む。
ステップ６７４では、バイトコード生成部は、対応するインタフェース担当クラスの名前（以下、インタフェース担当クラス名）を宣言インタフェース・リスト（図１１Ｃの１１３５）に追加する。当該対応するインタフェース担当クラスの名前は、バッファに対応付けられた名前（バッファ中の場合）、又は図７の対応表から得られるインタフェース名（インタフェース生成済みの場合）により得られる。ここで、宣言インタフェース・リスト（１１３５）とは、宣言された関数／メソッドに対応する呼び出し元のインタフェース担当クラス名をリスト形式で保持するデータ構造をいう。
ステップ６７６では、バイトコード生成部は、上記宣言されている関数／メソッドの処理（関数／メソッドの本体）のスクリプトのバイトコードをメモリ（図１１Ａの１１０１）中に生成する。当該生成されたバイトコードが、ステップ６４５−１〜６４５−８で実行されるバイトコードである。当該バイトコードの生成処理の具体的な内容は、既に説明した図６Ｃのステップ６５１（スクリプトのバイトコードの生成）への再帰となる。
ステップ６７７では、バイトコード生成部は、上記生成したバイトコードを宣言している関数／メソッドに対応させるコードをメモリ（１１０１）中に生成する。当該生成されたコードが、ステップ６４５−１〜６４５−８で実行されるバイトコードである。ステップ６７７で生成されるコードは、シンボル・テーブル（図１１Ａの１１０９）へ登録されるコードである。当該コードは、図４ＣのＬ０４及びＬ０５のlookupFunction()のような形で参照されるコードである。すなわち、ステップ６７７で生成されるコードは、ステップ６７６で生成されるバイトコード中の関数の実装を関数名に結びつけるコードである。
ステップ６７８では、バイトコード生成部は、上記関数／メソッド宣言の生成処理（６７１）を終了し、処理の分岐元のステップ６５６へ戻る。
【００６８】
図６Ｅは、図６Ｃのステップ６４３におけるバッファの処理の詳細な処理フロー図を示す。
ステップ６８１では、バイトコード生成部は、バッファの処理を開始する。
ステップ６８２では、バイトコード生成部は、宣言関数リストが空か否かの判定を行う。
宣言関数リストが空である場合、当該処理はステップ６８３に進む。一方、宣言関数リストが空でない場合、当該処理はステップ６８４に進む。
ステップ６８３では、バイトコード生成部は、呼出関数リスト中、及び、好ましくはinclude処理などの静的解析などによって得られる他の変換単位中に現れるシグネチャをバッファに追加する。当該シグネチャを追加後、バッファをクリアすることなく（バッファはそのまま）、該処理はステップ６８９に進む。
宣言関数リストが空でない場合、当該処理はステップ６８４に進む。
ステップ６８４では、バイトコード生成部は、宣言インタフェース・リスト中にバッファに対応付けられたインタフェース担当クラス名があるか否かを調べる。
ステップ６８５では、上記バッファに対応付けられたインタフェース担当クラス名がない場合、該処理はステップ６８６に進む。一方、上記バッファに対応付けられたインタフェース担当クラス名がある場合、該処理はステップ６８７に進む。
ステップ６８６では、バイトコード生成部は、上記バッファに対応付けられたインタフェース担当クラス名がある場合、宣言関数リスト中のシグネチャから、バッファ中のインタフェース担当クラスとは別途のバッファとは独立したインタフェース担当クラスを生成及びロードする。当該バッファとは独立したインタフェース担当クラスを生成及びロードする処理は、任意的なステップである。しかし、宣言されているセットと同じセットのシグネチャをもつ統合インタフェース担当クラスの方がダミーの実装が少なくてすむことから、当該ステップがあることが好ましい場合が多い。そのため、バッファ中にあるシグネチャはそのままにできる場合に限り、宣言されているものだけからなる統合インタフェース担当クラスを、バッファ中のシグネチャからの統合インタフェース担当クラスとは別途に生成する。上記バッファとは独立した統合インタフェース担当クラスを生成する際に、シグネチャと上記バッファとは独立した統合インタフェース担当クラスの名前の組を、図７のデータ構造中に登録する。また、当該ロードした上記バッファとは独立した統合インタフェース担当クラスの名前を宣言インタフェース・リストに追加する。追加後、当該処理はステップ６８３に進む。
ステップ６８７では、バイトコード生成部は、上記バッファに対応付けられたインタフェース担当クラス名がない場合、宣言関数リスト及び呼出関数リスト中のシグネチャをバッファに追加する。
ステップ６８８では、バイトコード生成部は、バッファ中のシグネチャから１つの統合インタフェース担当クラスを生成及びロードする。当該バッファは、スクリプト・ファイル単位中に現れる呼び出し元の関数／メソッドのシグネチャを格納している。当該１つの統合インタフェース担当クラスを生成する際に、シグネチャと当該１つの統合インタフェース担当クラスの名前の組を、図７のデータ構造中に登録する。また、当該ロードした統合インタフェース担当クラスの名前を宣言インタフェース・リストに追加する。統合インタフェース担当クラスの生成後に、バイトコード生成部は、バッファをクリアにする。すなわち、バッファ中のシグネチャを削除する。クリア後、当該処理はステップ６８９に進む。なお、バッファの処理において、ステップ６８６を経ることなく、バッファ中のシグネチャからの統合インタフェース担当クラスを生成するステップ６８８を経る場合がある。
ステップ６８９では、バイトコード生成部は、バッファの処理（６８１）を終了し、処理の分岐元のステップ６４３（図６Ｃ）へ戻る。
【００６９】
図６Ｃのステップ６４５の具体的な処理を、図６Ｃの右側の処理フロー（ステップ６４５−１〜６４５−８）に従い説明する。
ステップ６４５−１では、Ｊａｖａ（商標）プログラム実行部（以下、プログラム実行部）（図１１Ａの１１１８）は、ステップ６６４、６７６及び６７７で生成されたバイトコードの実行を開始する。
ステップ６４５−２では、プログラム実行部は、未ロードの統合インタフェース担当クラスを生成し、及びロードする。ステップ６４５−２の処理の詳細な内容は別途、下記ステップ６９１〜６９４に示す。
ステップ６４５−３では、プログラム実行部は、上記生成されたバイトコードの各インストラクションを読み取る。
ステップ６４５−４では、プログラム実行部は、上記読み取ったインストラクションが“include”又は“include”相当の処理であるかどうかを判定する。
ステップ６４５−５では、プログラム実行部は、上記読み取ったインストラクションが“include”又は“include”相当の処理である場合、スクリプトの処理を行う。当該スクリプトの処理は、ステップ６４１のスクリプトの処理に戻ることである。
ステップ６４５−６では、プログラム実行部は、上記読み取ったインストラクションが“include”且つ“include”相当の処理でない場合、その他のインストラクションの処理を行う。当該その他のインストラクションの処理は本発明の本質ではないのでここではその説明を省略する。
ステップ６４５−７では、バイトコードの各インストラクションの読み取りが全て終了するまで、ステップ６４５−３に戻る。
ステップ６４５−８では、バイトコードの実行を終了し、処理の分岐元のステップ６４５に戻る。
【００７０】
図６Ｆは、図６Ｃのステップ６４５−２における未ロードの統合インタフェース担当クラスの生成及びロードの詳細な処理フローを示す。
ステップ６９１では、未ロードの統合インタフェース担当クラスの生成及びロードの実行を開始する。
ステップ６９２では、インタフェース担当クラス生成部（図１１Ｃの１１３２）は、クラス・ローダによりバッファ中のシグネチャ全てに対応する統合インタフェース担当クラスが利用されていればそのロードが要求される。
ステップ６９３では、インタフェース担当クラス生成部は、上記ロード要求がある場合、ステップ６９４に進む。一方、プログラム実行部は、上記ロード要求がない場合にステップ６９５に進む。
ステップ６９４では、インタフェース担当クラス生成部は、ロード要求であることに応じて、バッファ中の全てのシグネチャから１つの統合インタフェース担当クラスを生成及びロードする。当該インタフェース担当クラスの生成後に、インタフェース担当クラス生成部は、バッファをクリアにする。すなわち、バッファ中のシグネチャを削除する。クリア後、当該処理は、ステップ６９５に進む。
ステップ６９５では、インタフェース担当クラス生成部は、未ロードの統合インタフェース担当クラスの生成及びロードの実行を終了し、処理の分岐元のステップ６４５−２に戻る。
【００７１】
本発明の実施態様従う上記処理フロー（ステップ６４１〜６９５）を、図１Ａに示したＰＨＰ言語で記述されたソースコードに適用した例を以下に説明する。
スクリプト・ファイルstart.php（１０１）から処理が始まるとする。
最初に、スクリプト・ファイルstart.php（１０１）について、「スクリプトの処理」（６４１）が行われる。そして、スクリプト・ファイルstart.php（１０１）の実行の過程（６４５）において、funcs.phpの「スクリプトの処理」（６４５−５）が行われる。
Ａ．スクリプト・ファイルstart.php（１０１）に対するスクリプトの処理
スクリプト・ファイルstart.php（１０１）を実行するために必要な実装担当クラスをバイトコードで生成する（ステップ６４２）。当該生成されたバイトコードは、例えば図４Ｃに示す通りである。
スクリプト・ファイルstart.php（１０１）には関数宣言がない。そのために、対応する実装担当クラスBytecode_start_php（４２１）にスクリプト自体の実行のためのインタフェースPHPScript以外のインタフェース担当クラスの実装の宣言はない。呼び出し元である実装担当クラスBytecode_start_php（４２１）のコードでは、インタフェース担当クラスCallsite_start_phpを使って、呼び出しコードを実現している。統合インタフェース担当クラスCallsite_start_phpの名前は適当に付けた名前であり、現在のバッファ中のシグネチャのメソッドを備えることになる統合インタフェース担当クラスの名前でもある。この段階において、上記インタフェース担当クラス自身は生成もロードもされていない。その代わりに、関数／メソッド・シグネチャの「foo(0)」と「bar(1)」のシグネチャがシグネチャ・バッファに入れられる。なお、実施態様の説明において、簡単のために例えば、シグネチャを名前と引数の数のみを用いるとする。
Ｂ．start.phpの実行
生成及びロードされたstart.phpの実装担当クラスBytecode_start_php（図４Ｃ、４２１）のexecuteScript()を呼び出し、このスクリプトを実行する（ステップ６４５）。元の”include”相当のincludeScript()補助関数（図４ＣのＬ０３）が呼ばれ、渡された引数が “funcs.php”であるから、スクリプト・ファイルfuncs.php（図１Ａ、１０２）が実行されることになる。funcs.php（１０２）に相当する実装担当クラスはまだ生成及びロードされていないので、funcs.php（１０２）に対するスクリプトの処理が必要である。
Ｃ．funcs.phpに対するスクリプトの処理
スクリプト・ファイルfuncs.php（１０２）を実行するために必要な実装担当クラスを生成及びロードするために、スクリプトのバイトコードを生成する処理（ステップ６４２）を実行する。その結果として得られるバイトコードは、図４Ｄに示す通りである（４２２）。funcs.php（１０２）において、未出シグネチャの関数の宣言はないので、バッファにはこれ以上特に追加しない。funcs.php（１０２）には関数が宣言されており、それらのシグネチャはまだバッファにあるために、それに対応するインタフェース担当クラスCallsite_start_phpを実装するように宣言が実行される。
【００７２】
図７は、本発明の実施態様における、シグネチャ・インタフェース登録のデータ構造を示す。
テーブル（７０１）は、ロード済みとしてＰＨＰの関数／メソッドを登録するためのデータ構造である。当該データ構造は、シグネチャ・インタフェース登録部（図１１Ｃの１１３１）に記憶される。当該テーブル（７０１）は、ＰＨＰの関数／メソッドのシグネチャとＪａｖａ（商標）のメソッド・シグネチャとの組を含む。当該メソッド・シグネチャは、該メソッドが属するインタフェース担当クラス名と該関数／メソッドのシグネチャとの組で構成される。なお、本発明の実施態様では、ソースコードは変数等が予め型付けられていない動的型付け言語で記述されるので、当該関数のシグネチャは関数名及び引数の数のみでよい。
図６Ｅのステップ６８３において、ＰＨＰの関数／メソッドのシグネチャ及びＪａｖａ（商標）のメソッド・シグネチャのいずれかがバッファに格納されればよい。この理由は、ＰＨＰの関数／メソッドのシグネチャから、対応するＪａｖａ（商標）のメソッド・シグネチャを、当該データ構造を使用して検索可能であり、一方、Ｊａｖａ（商標）のメソッド・シグネチャから、対応するＰＨＰの関数／メソッドのシグネチャを、当該データ構造を使用して検索可能なようにできるからである。
【００７３】
図８Ａ〜図８Ｂは、関数／メソッド呼び出しより先に関数／メソッド宣言がなされた例を示す。
図８Ａは、変換対象となりうるＰＨＰ言語で記述されたＰＨＰソースコード（start.php、caller.php及びfuncs.php）があり、関数／メソッド呼び出し（caller.php）の処理よりも先に関数／メソッド宣言（funcs.php）の処理がなされた例を示す。
上記ＰＨＰソースコードは、３つのソースコードのファイルstart.php（８０１）、funcs.php（８０３）及びcaller.php（８０２）で構成されている。
当該３つのファイルの関係は、下記の通りである。ファイルstart.php（８０１）中の取り込み命令include(“funcs.php”)は、取り込むべきファイルとしてファイルfuncs.php（８０３）を指定している（矢印８０４）。また、同ファイルstart.php（８０１）中の取り込み命令include(“caller.php”)は、取り込むべきファイルとしてファイルcaller.php（８０２）を指定している（矢印８０５）。さらにcaller.php（８０２）の関数／メソッドfoo()は、ファイルfuncs.php（８０３）の宣言及び定義function foo(){}に対応している（矢印８０６）。
本発明の実施態様では、図４Ａ〜図４Ｄの実施態様と異なり、ＰＨＰの関数呼び出しファイルcaller.php（８０２）の処理、すなわち関数foo()呼び出しのためのインタフェース担当クラスの生成よりも、ファイルfuncs.php（８０３）中の関数／メソッド宣言の処理が先に実行される。関数呼び出しファイルcaller.php（８０２）の処理より、宣言ファイルfuncs.php（８０３）の処理が先に実行される場合、当該実行の時点で関数のシグネチャがバッファに溜まっているＰＨＰの関数と宣言されているＰＨＰの関数とをまとめた統合インタフェース担当クラスを生成及びロードする。この統合インタフェース担当クラスを実装（implements）するようにして、宣言ファイル（funcs.php）実装を担当するＪａｖａクラスを生成及びロードする。これによって、ＰＨＰ関数の宣言を含んだコード実行が先に来た場合においても、図８Ｂのように、複数の関数に対応するメソッドが１つの統合インタフェース担当クラスにまとめられる。
【００７４】
図８Ｂは、図８Ａに示すソースコードを複数関数１インタフェース方式により生成される実装担当クラス並びにインタフェース担当クラス、及びソースコードのターゲットコードへの変換及び実行の各ステップを示す。
図８Ｂにおいて、左側が変換及び実行の各ステップ（Ｎ０１〜Ｎ１９）を示す。同右側が、複数関数１インタフェース方式により生成される実装担当クラス（８１２、８１３及び８１４）及び１つの統合インタフェース担当クラス（８１１）を示す。すなわち、複数関数１インタフェース方式では、複数の関数／メソッドの呼び出し元に対して１つの統合インタフェース担当クラス（８１１）が用意されており、統合インタフェース担当クラス（８１１）に対応して実装担当クラス（８１３）が生成される。さらに、同右側は、実装担当クラス（８１４）の実装内容として統合インタフェース担当クラス（８１１）を通じて関数foo()を呼び出している様子（８１５）を示す。実装担当クラス（８１２、８１３及び８１４）、及び統合インタフェース担当クラス（８１１）の左側に付された矢印内の番号（Ｎ０２、Ｎ０６、ＮＯ０８及びＮ１４）は上記ステップのステップ番号に対応する。
【００７５】
以下、図８Ｂの変換及び実行ステップについて説明する。
１行目（Ｎ０１）では、ＰＨＰソースコードのスクリプト・ファイルstart.php（図８Ａの８０１）の取り込み命令includeが指示されている。そのサブステップとして２〜１９行目（Ｎ０２〜Ｎ１９）の各ステップが実行される。
２行目（Ｎ０２）では、ＰＨＰスクリプト・ファイルstart.php（図８Ａの８０１）の実装担当クラス（８１２）の生成及びロードが行われる。矢印（Ｎ０２）は該実装担当クラス（８１２）の生成を示している。
３行目（Ｎ０３）では、ロードされた該実装担当クラス（８１２）のバイトコードが実行される。
４行目（Ｎ０４）では、該実装担当クラス（８１２）の実行により、スクリプト・ファイルstart.php（図８Ａの８０１）の最初の命令includeに対応するバイトコードが指示するファイルfuncs.phpが取り込まれる。ここで、これまでのstart.php（８０１）に対応する実装担当クラスBytecode_start_php（８１２）の実行は中断され、新たに取り込まれたＰＨＰファイルfuncs.php（８０３）に対応する実装担当クラスBytecode_funcs_php（８１３）の生成及びロードの実行に移る。
５行目（Ｎ０５）から９行目（Ｎ０９）までにおいて、funcs.php（８０３）に対応する実装担当クラスBytecode_funcs_php（８１３）が生成され、ロードされる。
６行目（Ｎ０６）では、funcs.php（８０３）に対応する実装担当クラスBytecode_funcs_php（８１３）が生成される。矢印（Ｎ０６）は該実装担当クラスBytecode_funcs_php（８１３）の生成を示している。この段階において、統合インタフェース担当クラスは未だ生成されていないのでロードはされない。
７行目（Ｎ０７）では、ロードもバッファリングもされていない関数呼び出しfoo()及びbar()に対応するインタフェース担当クラス又はシグネチャの有無を確認する。
８行目（Ｎ０８）では、関数宣言されているfoo()及びbar()のシグネチャを利用して１つの統合インタフェース担当クラス（８１１）を生成する。矢印（Ｎ０８）は該統合インタフェース担当クラス（８１１）の生成を示している。この場合、関数呼び出しファイルcaller.php（図８Ａの８０２）の処理より、宣言ファイルfuncs.php（図８Ａの８０３）の処理が先に実行されるので、その時点でバッファに溜まっている呼び出し元の関数のシグネチャと（本実施態様では０個）、宣言されている関数のシグネチャとから１つの統合インタフェース担当クラス（８１１）を生成及びロードする。
９行目（Ｎ０９）では、上記ステップ（Ｎ０６）で生成されたfuncs.phpに対応する実装担当クラス（８１３）をロードする。この場合、ステップ（Ｎ０８）のインタフェース担当クラス（８１１）の生成方法からも分かるように、インタフェース担当クラス（８１１）で定義された関数は既に実装担当クラス（８１３）で実装されている（８１６）。これにより、ＰＨＰ関数の宣言を含んだコード実行が先に来た場合においては、関数宣言を行っているスクリプトに対応する実装担当クラスの生成及びロードの時点でバッファにたまっているＰＨＰ関数と、宣言されているＰＨＰ関数とから、好ましくは重複の有無に基づき選択的にまとめた、複数の関数／メソッド呼び出しに対応する１つの統合インタフェース担当クラスが生成される。
１０行目（Ｎ１０）では、上記funcs.phpに対応する実装担当クラス（８１３）を実行する。
１１行目（Ｎ１１）では、上記実行に従って、関数foo()及びbar()の関数宣言が実行される。この内容は例えば、図４ＡのステップＪ１１と基本的に同じである。
１２行目（Ｎ１２）では、関数foo()及びbar()の実体を関数テーブルに登録する。図４ＡのステップＪ１２と基本的に同じである。
１３行目（Ｎ１３）では、スクリプト・ファイルstart.php（図８Ａの８０１）の実装担当クラス（８１２）へ制御権が戻り、２つめの取り込み命令includeが指示するファイルcaller.php（図８Ａの８０２）が取り込まれる。
１４行目（Ｎ１４）では、ファイルcaller.php（図８Ａの８０２）に対応する実装担当クラス関数（８１４）が生成及びロードされる。矢印（Ｎ１４）は該実装担当クラス関数（８１４）の生成を示している。
１５行目（Ｎ１５）では、呼び出し元の関数foo()に対するインタフェース担当クラスが既にロードされているか、又は該呼び出し元の関数foo()のシグネチャがバッファに格納されているかを確認する。
１６行目（Ｎ１６）では、上記caller.phpに対応する実装担当クラス（８１４）を実行する。
１７行目（Ｎ１７）では、ステップ（Ｎ１６）の実行によってバイトコードによる関数foo()の呼び出し（invoke）が実行される。
１８行目（Ｎ１８）では、呼び出し関数名fooから関数テーブルを検索し、対応付けていたインスタンスが見つけられる。
１９行目（Ｎ１９）では、該インスタンスが備えているメソッドfoo()（関数foo()に対応）を呼び出し実行することで目的を実現している。このとき統合インタフェース担当クラス（８１１）で定義されている型に合わせるためインスタンスのキャストが行われる。
【００７６】
図８Ｂの例では、１つのスクリプト（funcs.php）分だけが１つの統合インタフェース担当クラスにまとめられている。しかしながら、funcs.php中でまた別の関数を呼び出している場合など、それ以外の関数も全てが１つの上記統合インタフェース担当クラスにまとめられることになる。ただし、コンパイル処理対象のスクリプトに関数宣言又は新たな関数／メソッドの呼び出しがない場合には、その必要がないため、インタフェース担当クラスはまだ生成されない。将来的に、コンパイル処理対象のスクリプトに関数宣言又は新たな関数／メソッドの呼び出しに出会ったときに、インタフェース担当クラスが生成される。
【００７７】
図９Ａ〜図９Ｂは、あるスクリプトで宣言されているPHP関数が、あるインタフェース担当クラスを網羅していない例を示す。
図９Ａは、変換対象となりうるＰＨＰ言語で記述されたＰＨＰソースコード（start.php、foo.php、bar.php）があり、未定の関数が現れる例を示す。
上記ＰＨＰソースコードは、３つのソースコードのスクリプト・ファイルstart.php（９０１）、foo.php（９０２）及びbar.php（９０３）で構成されている。
当該３つのファイルの関係は、下記の通りである。ファイルstart.php（９０１）の取り込み命令include(“foo.php”)は、取り込むべきファイルとしてファイルfoo.php（９０２）を指定している（矢印９０４）。また、同ファイルstart.php（９０１）の取り込み命令include(“bar.php”)は、取り込むべきファイルとしてファイルbar.php（９０３）を指定している（矢印９０６）。さらに、start.php（９０１）の呼び出し元の関数／メソッドfoo()は、ファイルfoo.php（９０２）の宣言及び定義function foo(){}に対応している（矢印９０５）。また、関数／メソッドbar()は、ファイルbar.php（９０３）の宣言及び定義function bar(){}に対応している（矢印９０７）。
本発明の実施態様において、投機的にインタフェースが統合されて、インタフェース担当クラスが生成される。そのため、例えば図９Ａに示すようなファイル start.php（９０１）中の関数呼び出しfoo()及びbar()に対応して生成されるインタフェース担当クラスでは、関数のfoo()及びbar()の全てが定義される。これに対して、例えば、取り込まれたファイルfoo.php（９０２）では、関数foo()の宣言はあるが、関数bar()の宣言がないケースがでてくる。また、例えば、取り込まれたファイルbar.php（９０３）では、関数bar()の宣言はあるが、関数foo()の宣言がないケースがでてくる。このような場合の対処法として、各スクリプト・ファイル用の実装担当クラスに、宣言のない関数に対して中身がほぼ空の、擬似実装を持たせる。このように、本実施態様では、あるコンパイル単位の実装担当クラスに含まれる関数／メソッドのシグネチャを含むインタフェース担当クラスは、当該実装担当クラスが実装するものとして宣言し、元のコンパイル単位に実装が存在しないシグネチャを持つ関数のダミーの実装を上記実装担当クラス中に用意する。
【００７８】
図９Ｂは、図９Ａに示すソースコードを複数関数１インタフェース方式により生成される実装担当クラス並びにインタフェース担当クラス、及びソースコードのターゲットコードへの変換並びにその実行の各ステップを示す。
図９Ｂにおいて、左側が変換及び実行の各ステップ（Ｏ０１〜Ｏ２２）を示す。同右側が、複数関数１インタフェース方式により生成される実装担当クラス（９１３、９１５及び９１７）及び統合インタフェース担当クラス（９１２）を示す。すなわち、複数関数１インタフェース方式では、複数の関数／メソッドの呼び出し元に対して１つの統合インタフェース担当クラス（９１２）が用意されており、統合インタフェース担当クラス（９１２）に対応して実装担当クラス（９１５及び９１７）が生成される。さらに、同右側は、実装担当クラス（９１３）の実装内容としてインタフェースを通じて関数foo()及びbar()を呼び出している様子（９１４）を示す。同様に、同右側は、実装担当クラス（９１５）の実装内容としてインタフェースを通じて関数dummy()を呼び出している様子（９１６）を示す。また、同右側は、実装担当クラス（９１７）の実装内容としてインタフェースを通じて関数dummy()を呼び出している様子（９１８）を示す。実装担当クラス（９１３、９１５及び９１７）、統合インタフェース担当クラス（９１２）及びバッファの左側に付された矢印内の番号（Ｏ０３、Ｏ０４、Ｏ０５、Ｏ０８及びＯ１６）は上記ステップのステップ番号に対応する。
【００７９】
以下、図９Ｂの変換及び実行ステップについて説明する。
１行目（Ｏ０１）では、ＰＨＰソースコードのスクリプト・ファイルstart.php（９０１）の取り込み命令includeが指示されている。そのサブステップとして２〜２２行目（Ｏ０２〜Ｏ２２）の各ステップが実行される。
２行目（Ｏ０２）では、ＰＨＰのファイルstart.php（図９Ａの９０１）中の関数foo()及びbar()の呼び出し元の実装担当クラスの生成が指示されている。該指示に従い、矢印（Ｏ０４）で示すようにstart.php（図９Ａの９０１）に対応する実装担当クラスBytecode_start_php（９１３）が生成される。
３行目（Ｏ０３）では、上記関数呼び出しfoo()及びbar()のそれぞれのシグネチャがバッファ（９１１）に格納が指示される。該指示に従い、矢印（Ｏ０３）で示すように、バッファ（９１１）に各シグネチャが格納される。
４行目（Ｏ０４）では、上記実装担当クラスBytecode_start_php（９１３）がＪａｖａ（商標）仮想マシン上へロードされる。
５行目（Ｏ０５）では、上記関数呼び出しfoo()及びbar()のそれぞれのシグネチャをバッファ（９１１）から取り出し、統合インタフェース担当クラス（９１２）の生成及びロードが指示されている。該指示に従って、矢印（Ｏ０５）に示すように統合インタフェース担当クラス（９１２）が生成される。
このように、呼び出し元の実装コードを生成するタイミング（２行目（Ｏ０２））ではなく、ロードするタイミング（４行目（Ｏ０４））や、好ましくは実行する段階になって、クラス・ローダ（図１１Ａの１１０７）を通じてクラス（インタフェース）のロードが要求されるため、その時点で初めてバッファに溜まっているシグネチャのメソッドを全て備えたインタフェース担当クラスを生成及びロードする。インタフェース担当クラスが既にある場合には、ロードだけされる。
６行目（Ｏ０６）では、ロードされている呼び出し元の実装担当クラス（９１３）の実行が指示されている。
７行目（Ｏ０７）では、上記実行で取り込み命令includeの実行が指示されている。そして、指定されたファイルfoo.php（図９Ａの９０２）が取り込まれる。
８行目（Ｏ０８）では、取り込まれたファイルfoo.php（図９Ａの９０２）に対応する実装担当クラスのバイトコード（９１５）の生成及びロードが指示されている。該指示に従い、矢印（Ｏ０８）で示すようにファイルfoo.php（９０２）に対応する実装担当クラス（９１５）が生成及びロードされる。該実装担当クラス（９１５）は、統合インタフェース担当クラス（９１２）を実装して生成される必要がある（実装９１９）。なぜならば、統合インタフェース担当クラス（９１２）で定義されている関数foo()及びbar()は、Ｊａｖａ（商標）の規則によって、実装担当クラス（９１５）において必ず実装されなければならないからである。しかし、該実装担当クラス（９１５）に対応するファイルfoo.php（９０２）は、関数foo()しか宣言されておらず、関数bar()の宣言はない。そこで、関数bar()の中身がほぼ空の、擬似実装であるdummy()（９１６）をもたせることにより対処する。
９行目（Ｏ０９）では、上記foo.phpに対応する実装担当クラス（９１５）の実行が指示されている。
１０行目（Ｏ１０）では、上記実行によって関数宣言命令declareFunctionが実行される。上記関数宣言命令declareFunctionの実行によって、関数呼び出しfoo()を実行するためのインスタンスが実装担当クラス自身から生成される。
１１行目（Ｏ１１）では、上記生成されたインスタンスと関数呼び出しfoo()の関数名fooが関数テーブルに対応付けて登録される。関数呼び出しがあると関数テーブルからインスタンスを検索し、該インスタンスが有するメソッドfoo()及びbar()を利用して関数呼び出しを処理するためである。以上で実装担当クラス（９１５）の実行は終了し、制御は実装担当クラス（９１３）へ戻る。
１２行目（Ｏ１２）では、上記実装担当クラス（９１３）の実行により、関数foo()の呼び出し（invoke foo()）が実行される。
１３行目（Ｏ１３）では、上記実行により、呼び出し関数名fooから関数テーブルを検索し、対応付けていたインスタンスが見つけられる。
１４行目（Ｏ１４）では、該インスタンスが備えているメソッドfoo()（関数foo()に対応）を呼び出し実行する。
１５行目（Ｏ１５）では、上記実行が完了するとスクリプト・ファイルbar.php（図９Ａの９０３）の取り込み命令includeが実行される。
１６行目（Ｏ１６）では、取り込まれたファイルbar.php（図９Ａの９０３）に対応する実装担当クラスのバイトコード（９１７）の生成及びロードが指示されている。該指示に従い、矢印（Ｏ１６）で示すようにファイルbar.php（９０３）に対応する実装担当クラス（９１７）が生成及びロードされる。該実装担当クラス（９１７）は、統合インタフェース担当クラス（９１２）を実装して生成される必要がある（実装９２０）。なぜならば、統合インタフェース担当クラス（９１２）で定義されている関数foo()及びbar()は、Ｊａｖａ（商標）の規則によって、実装担当クラス（９１７）において必ず実装されなければならないからである。しかし、該実装担当クラス（９１７）に対応するファイルbar.php（９０３）は、関数foo()しか宣言されておらず、関数bar()の宣言はない。そこで、関数foo()の中身がほぼ空の、擬似実装であるdummy()（９１８）をもたせることにより対処する。
１７行目（Ｏ１７）では、上記bar.phpに対応する実装担当クラス（９１７）の実行が指示されている。
１８行目（Ｏ１８）では、上記実行によって関数宣言命令declareFunctionが実行される。上記関数宣言命令declareFunctionの実行によって、関数呼び出しbar()を実行するためのインスタンスが実装担当クラス自身から生成される。
１９行目（Ｏ１９）では、上記生成されたインスタンスと関数呼び出しbar()の関数名barが関数テーブルに対応付けて登録される。関数呼び出しがあると関数テーブルからインスタンスを検索し、該インスタンスが有するメソッドfoo()及びbar()を利用して関数呼び出しを処理するためである。以上で実装担当クラス（９１５）の実行は終了し、制御は実装担当クラス（９１３）へ戻る。
２０行目（Ｏ２０）では、上記実装担当クラス（９１３）の実行により、関数bar()の呼び出し（invoke bar()）が実行される。
２１行目（Ｏ２１）では、上記実行により、呼び出し関数名barから関数テーブルを検索し、対応付けていたインスタンスが見つけられる。
２２行目（Ｏ２２）では、該インスタンスが備えているメソッドbar()（関数bar()に対応）を呼び出し実行する。
以上で、ＰＨＰスクリプトをＪａｖａ（商標）のバイトコードに変換し、実行するステップは終了する。
【００８０】
図１０Ａ〜図１０Ｅは、ＣＲＭ（Custumer Relationship Management）アプリケーションに対して、インタフェース担当クラスの数を削減した結果による効果の例を示す。
当該例は、実在のＰＨＰアプリケーションから抜粋したコードについて、既存の手法と本発明の実施態様による手法とを適用してＪａｖａバイトコードを生成する例である。
【００８１】
図１０Ａは、ＣＲＭ（Custumer Relationship Manegement）アプリケーションから抜粋したＰＨＰソースコードの複数のファイル例を示す。
ＰＨＰソースコードは、index.php（１００１）、entryPoint.php（１００２）、utils.php（１００３）、Application.php（１００４）、Controller.php（１００５）、ControllerFactory.php（１００６）及びEmployees/controller.php（１００７）から構成されている。
【００８２】
図１０Ｂは、図１０Ａに示すＰＨＰソースコードにおける関数／メソッドの呼び出し元と呼び出し先との関係、及びファイル取り込み指示命令と指示されたファイルとの関係を示す。
矢印１００７は、ＰＨＰスクリプト・ファイルindex.php（１００１）における１行目の取り込み命令require_onceで指定されたファイルentryPoint.phpが、ファイルentryPoint.php（１００２）であることを示す。
矢印１００８は、ＰＨＰスクリプト・ファイルindex.php（１００１）におけるオブジェクトの生成を指令する命令newApplication();での関数Application()は、ファイルApplication.php（１００４）の関数宣言functionApplication(){}に対応していることを示す。
他の矢印（１００９〜１０２１）についても同様であるので、ここではその説明を省略する。
【００８３】
図１０Ｃは、図１０Ａに示すＰＨＰソースコードをＪａｖａ（商標）のバイトコードに変換した場合の変換及び実行ステップ、並びに各関数／メソッドの生成、宣言及び呼び出し実行の時系列を示す。
図１０Ｃにおいて、左側が変換及び実行の各ステップ（Ｐ０１〜Ｐ３０）を示す。同右側が、図１０Ａに示すＰＨＰコードの関数について、呼び出し、宣言、及び実行されるタイミングを各ステップ（Ｐ０１〜Ｐ３０）に併せて、経時的に示したものである。例えば、関数Application()は、２行目（Ｐ０２）において呼び出され、１４行目（Ｐ１４）において宣言され、そして１５行目（Ｐ１５）において実行される。その他の関数startSession()、execute()、Insert_charset_header()、Controller()、setup()、getController()、EmployeesController()、pre_editview()、及びexecute(）についても同様であるので、ここではその説明を省略する。
【００８４】
図１０Ｄは、図１０Ａに示すＰＨＰソースコードを１関数１クラス方式により変換した場合の実装担当クラスを、図１０Ｃに記載の時系列とともに示す。
実装担当クラス（１０４１〜１０５７）は、図１０Ａに示すＰＨＰの各ファイル（１００１〜１００７）に対応して生成されたバイトコードである。実装担当クラスの左側に付された矢印内の番号（Ｐ０１、Ｐ０３、Ｐ０４、Ｐ０６、Ｐ０７、Ｐ０８及びＰ２２）は、図１０Ｃの変換及び実行ステップのステップ番号に対応する。
【００８５】
図１０Ｅは、図１０Ａに示すＰＨＰソースコードを１関数１インタフェース方式により変換した場合の実装担当クラスを、図１０Ｃに記載の時系列とともに示す。
実装担当クラス（１０７０〜１０７６）及びインタフェース担当クラス（１０６１〜１０６９）は、図１０Ａに示すＰＨＰソースコードを１関数１インタフェース方式により変換して生成されるバイトコードである。実装担当クラス及びインタフェース担当クラスの左側に付された矢印内の番号（Ｐ０１、Ｐ０２、Ｐ０３、Ｐ０４、Ｐ０６、Ｐ０７、Ｐ０８及びＰ２２）は、図１０Ｃの変換及び実行ステップのステップ番号に対応する。
【００８６】
図１０Ｆは、図１０Ａに示すＰＨＰソースコードを複数関数１インタフェース方式により変換した場合の実装担当クラスを、図１０Ｃに記載の時系列とともに示す。
実装担当クラス（１０８１〜１０８５）及びインタフェース担当クラス（１０８６〜１０９２）は、図１０Ａに示すＰＨＰソースコードを１関数１インタフェース方式により変換して生成されるバイトコードである。実装担当クラス、インタフェース担当クラス及び各バッファ処理の左側に付された矢印内の番号（Ｐ０１、Ｐ０２、Ｐ０３、Ｐ０４、Ｐ０６、Ｐ０７、Ｐ０８及びＰ２２）は、図１０Ｃの変換及び実行ステップのステップ番号に対応する。
ここで、図１０Ｅに示す１関数１インタフェース方式と図１０Ｆに示す複数関数１インタフェース方式との違いを説明する。図１０Ｅにおいて、例えば、矢印（Ｐ０２）で３つのインタフェース担当クラス（１０６１、１０６２及び１０６３）が生成されている。一方、図１０Ｆにおいて、矢印（Ｐ０６）で、１つの統合インタフェース担当クラス（１０８２）が生成されている。統合インタフェース担当クラス（１０８２）は、１関数１インタフェース方式における３つのインタフェース担当クラス（１０６１、１０６２及び１０６３）に対応するものである。これによって、３つのインタフェース担当クラス（１０６１、１０６２及び１０６３）が１つの統合インタフェース担当クラス（１０８２）に統合されていることがわかる。
同様に、図１０Ｅにおいて、矢印（Ｐ０７）では２つのインタフェース担当クラス（１０６６及び１０６７）が生成されており、また矢印（Ｐ２２）では２つのインタフェース担当クラス（１０６８及び１０６９）が生成されている。一方、図１０Ｆにおいて、図１０Ｅの矢印（Ｐ０７）に対応する矢印（Ｐ０８）では図１０Ｅの２つのインタフェース担当クラス（１０６６及び１０６７）をまとめた１つの統合インタフェース担当クラス（１０８４）が生成されており、同様に、図１０Ｅの矢印（Ｐ２２）に対応する矢印（Ｐ２２）では図１０Ｅの２つのインタフェース担当クラス（１０６８及び１０６９）をまとめた１つの統合インタフェース担当クラス（１０８５）が生成されている。
このように、図１０Ｆの複数関数１インタフェース方式によると、図１０Ｅの１関数１インタフェース方式と比べて、インタフェース担当クラスの数は９つから５つに減少している。
【００８７】
図１１Ａは、本発明の実施態様における、動的型付け言語で記述されたソースコードを静的型付け言語で記述されたターゲットコードに変換するためのシステム図を示す。
図１１Ａに示すように、本システムは、メモリ（１１０１）及び記憶装置（１１０２）を備えている。記憶装置（１１０２）はハードディスク・ドライブ又はシリコン・ディスク・ドライブでありうる。Ｊａｖａ（商標）仮想マシン（１１０３）が、上記メモリ（１１０１）上で実装されうる。記憶装置は、ＰＨＰで記述されたスクリプト・ファイル（１１０４）を格納する。Ｊａｖａ（商標）仮想マシン（１１０３）上には、ＰＨＰランタイム・ヘルパー（１１０５）、バイトコード生成部（１１０６）、クラス・ローダ（１１０７）、実行可能なオブジェクト・テーブル（１１０８）及びシンボル・テーブル（１１０９）を実装している。
本システムは、記憶装置（１１０２）に記憶されたＰＨＰ言語などの動的型付け言語で記述されたソースコード（例えば、ＰＨＰのスクリプト）（１１０４）を、Ｊａｖａ（商標）などの静的型付け言語で記述されたターゲットコード（例えば、Ｊａｖａ（商標）のクラス・ファイル（図１１Ａの１１１２））に変換及びロードして、Ｊａｖａ（商標）仮想マシン上で実行する。
【００８８】
本システムの動作を、図１１Ａに従い説明する。
バイトコード生成部（１１０６）は、記憶装置（１１０２）からＰＨＰのスクリプト・ファイル（１１０４）をソースコードとして読み込み及び構文解析する（１１１０）。
バイトコード生成部（１１０６）は、図６Ｃ及び図６Ｄで示した処理フローに従って当該ソースコードをバイトコードに変換し（１１１１）、そしてＪａｖａクラス・ファイル（１１１２）を生成する。
引き続き、クラス・ローダ（１１０７）が、上記生成されたＪａｖａクラス・ファイル（１１１２）をロード（１１１３）する。そして、クラス・ローダ（１１０７）はまた、クラス（１１１５）を得る（１１１４）。クラス（１１１５）はインタフェース担当クラス又は実装担当クラスである。さらに、本システムの言語実行系は、指定されたＰＨＰ又はその他の言語のスクリプトを実行する過程で、他のスクリプトも実行する。
例えば、言語実行系は、Ｗｅｂサーバに従属して動作し、アクセスされたＵＲＬに対応するスクリプトを実行する。高速な実行を可能にするために、スクリプトは、Ｊａｖａ（商標）仮想マシン上で直接動作するバイトコードにコンパイルされ、ロードされて実行される。典型的には、コンパイルされた結果はＪａｖａ（商標）のクラスとして表現されそのクラスから生成したオブジェクト（実行オブジェクト、Executable Object）へのメソッド呼び出しとしてスクリプトの実行がなされることになる。コンパイルやロードのコストは高いため、別のアクセス時には既にロードされた実行オブジェクトやクラスはキャッシュされ、再利用されるのが通常である。
ＰＨＰランタイム・ヘルパー（１１０５）の動きを、図１１Ａに記載のステップ１〜４に従い説明する。
ステップ１では、ＰＨＰランタイム・ヘルパー（１１０５）は、記憶装置（１１０２）内のＰＨＰスクリプト・ファイル（１１０４）に対応する実行オブジェクト又はクラスのキャッシュが有効であるかどうかをチェックする。キャッシュが有効であるかどうかは、例えば、ファイルの更新時刻がキャッシュに登録されているものと同一であることにより確認する。キャッシュが有効であれば、それらを使ってスクリプトの実行をプログラム実行部（１１１８）に行わせるために、バイトコードの生成は行わない。キャッシュが有効でない場合にのみステップ２に進む。キャッシュが有効な場合には、ステップ２を飛ばして、ステップ３に進む。
ステップ２では、ＰＨＰランタイム・ヘルパー（１１０５）は、バイトコード生成部（１１０６）にスクリプトの処理（図６Ｃステップ６４１〜６４６）を依頼する。この依頼に基づき、バイトコード生成部（１１０６）はスクリプト・ファイルに対応するバイトコードを生成及びロードして得られるクラスをＰＨＰランタイム・ヘルパー（１１０５）に渡す。ＰＨＰランタイム・ヘルパー（１１０５）は、得られたクラスをインスタンス化して実行オブジェクトを生成し、キャッシュに置く。
ステップ３では、ＰＨＰランタイム・ヘルパー（１１０５）は、現在の実行スコープ（ウェブサーバの１リクエストの処理の間など）で有効なシンボル・テーブル（１１０９）に実行オブジェクトを登録する。
ステップ４では、ＰＨＰランタイム・ヘルパー（１１０５）は、シンボル・テーブル（１１０９）から実行オブジェクトを見つけて実行する。具体的には、実行オブジェクトのexecuteScript()などのメソッドを呼び出してＪａｖａ仮想マシン（１１０３）に実行を依頼する。
【００８９】
図１１Ｂは、本発明の実施態様における、変換された結果としての実行可能なオブジェクトと実行ヘルパーとの関係を示す図である。
実行ヘルパー（１１２１）は、例えばＰＨＰランタイム・ヘルパーである。実行ヘルパー（１１２１）は、スクリプトの実行に係わる処理に共通の処理が多くあるために、これらの共通の処理を補助するモジュールである。共通の処理とは、例えば値同士の足し算などの基本的な演算処理、及び既に出てきているinclude()の処理である。
実行ヘルパー（１１２１）は、実行可能なオブジェクト（１１２２）を呼び出し（１１２３）、また実行可能なオブジェクト（１１２２）からＰＨＰ命令を作動するように指示を受け（１１２４）、作動を支援する。プログラム実行部（１１１８）は、バイトコード生成部（１１０６）によってＰＨＰスクリプトから変換されたバイトコードをＰＨＰランタイム・ヘルパーに処理の一部を委譲しながらスクリプトの実行をする。プログラム実行部（１１１８）は、通常のＪａｖａ（商標）プログラムの実行部であり、インタプリタ（１１１９）及びＪＩＴコンパイラ（１１２０）からなる。インタプリタ（１１１９）又はＪＩＴコンパイラ（１１２０）により生成されたコードは、ＣＰＵ（図１２の１２０２）において実行される。
【００９０】
図１１Ｃは、本発明の実施態様における、バイトコード生成部及びシグネチャ・インタフェース登録部を示す図である。
Ｊａｖａ（商標）仮想マシン（１１０３）は、シグネチャ・インタフェース登録部（１１３１）及びバイトコード生成部（１１０６）を含む。
シグネチャ・インタフェース登録部（１１３１）は、図７のシグネチャ・インタフェース登録のデータ構造を格納する記憶装置である。
バイトコード生成部（１１０６）は、インタフェース担当クラス生成部（１１３２）、バッファ（１１３３）及び実装担当クラス生成部（１１３４）を備えている。
インタフェース担当クラス生成部（１１３２）は、統合インタフェース担当クラスを生成する（図６Ｅのステップ６８８、及び図６Ｆのステップ６９４）。
バッファ（１１３４）は、シグネチャを格納する場所である。
実装担当クラス生成部（１１３４）は、宣言インタフェース・リスト（１１３５）、宣言関数リスト（１１３６）及び呼出関数リスト（１１３７）を備えている。宣言インタフェース・リスト（１１３５）とは、宣言された関数／メソッドに対応する呼び出し元のインタフェース担当クラス名をリスト形式で保持するデータ構造をいい。例えば、図６Ｂのステップ６３４又は図６Ｄのステップ６７４において追加されるインタフェース担当クラス名のリストである。宣言関数リスト（１１３６）は、生成した実装担当クラスにおいて、バッファ（１１３３）中のシグネチャの関数を宣言している場合に限り、バッファ（１１３３）をクリアにする処理において使用される。呼出関数リスト（１１３７）は、呼び出し元に現れる（呼出対象の）関数のシグネチャをリスト形式で保存するデータ構造をいう。
【００９１】
図１２は、本発明の実施態様における、図１１Ａのシステムが備えているコンピュータ・ハードウェアのブロック図を示す。
コンピュータ・システム（１２０１）は、ＣＰＵ（１２０２）とメイン・メモリ（１２０３）と含み、これらはバス（１２０４）に接続されている。ＣＰＵ（１２０２）は好ましくは、３２ビット又は６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＸｅｏｎ（商標）シリーズ、Ｃｏｒｅ（商標）シリーズ、Ａｔｏｍ（商標）シリーズ、Ｐｅｎｔｉｕｍ（商標）シリーズ、Ｃｅｌｅｒｏｎ（商標）シリーズ、ＡＭＤ社のＰｈｅｎｏｍ（商標）シリーズ、Ａｔｈｌｏｎ（商標）シリーズ、Ｔｕｒｉｏｎ（商標）シリーズ及びＳｅｍｐｒｏｎ（商標）などを使用することができる。バス（１２０４）には、ディスプレイ・コントローラ（１２０５）を介して、ＴＦＴモニタなどのディスプレイ（１２０６）が接続されている。ディスプレイ（１２０６）は、コンピュータ・システムの管理のために、通信回線を介してネットワークに接続されたコンピュータ・システムについての情報と、そのコンピュータ・システム上で動作中のソフトウェアについての情報を、適当なグラフィック・インターフェースで表示するために使用される。バス（１２０４）にはまた、ＩＤＥ又はＳ−ＡＴＡコントローラ（１２０７）を介して、ハードディスク又はシリコン・ディスク（１２０８）と、ＣＤ−ＲＯＭ、ＤＶＤドライブ又はＢＤドライブ（１２０９）が接続されている。
【００９２】
ハードディスク（１２０８）には、オペレーティング・システム、アプリケーション・プログラム及びデータが、メイン・メモリにロード可能に記憶されている。
【００９３】
ＣＤ−ＲＯＭ、ＤＶＤ又はＢＤドライブ（１２０９）は、必要に応じて、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又はＢＤからプログラムをハードディスクに追加導入するために使用される。バス（１２０４）にはさらに、キーボード・マウスコントローラ（１２１０）を介して、キーボード（１２１１）及びマウス（１２１２）が接続されている。
【００９４】
通信インタフェース（１２１４）は、例えばイーサネット（商標）・プロトコルに従う。通信インタフェース（１２１４）は、通信コントローラ（１２１３）を介してバス（１２０４）に接続され、コンピュータ・システム及び通信回線（１２１５）を物理的に接続する役割を担い、コンピュータ・システムのオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワーク・インターフェース層を提供する。なお、通信回線は、有線ＬＡＮ環境、或いは例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎなどの無線ＬＡＮ接続規格に基づく無線ＬＡＮ環境であってもよい。
【００９５】
図１３Ａ〜図１３Ｅは、図２Ｃ、図３Ａ、図４Ａ、図８Ｂ及び図９Ｂにおいて示されている変換及び実行ステップにおける処理の包含関係を示す。
各図において処理の包含関係はインデントによって示されているが、さらに理解を容易にするために、当該包含関係が枠線によって示されている。
【００９６】
図１３Ａは、図２Ｃの変換及び実行ステップにおける処理の包含関係を示す。
１行目（Ｅ０１）に、取り込み命令includeが指示されており、そのサブステップとして２〜１２行目（Ｅ０２〜Ｅ１２）の各ステップが実行されることがわかる。２〜１２行目（Ｅ０２〜Ｅ１２）の処理の包含関係についても上記と同様である。
【００９７】
図１３Ｂは、図３Ａの変換及び実行ステップにおける処理の包含関係を示す。
１行目（Ｆ０１）に、取り込み命令includeが指示されており、そのサブステップとして２〜１３行目（Ｆ０２〜Ｆ１３）の各ステップが実行されることがわかる。２〜１３行目（Ｆ０２〜Ｆ１３）の処理の包含関係についても上記と同様である。
【００９８】
図１３Ｃは、図４Ａの変換及び実行ステップにおける処理の包含関係を示す。
１行目（Ｊ０１）に、取り込み命令includeが指示されており、そのサブステップとして２〜１８行目（Ｊ０２〜Ｊ１８）の各ステップが実行されることがわかる。２〜１８行目（Ｊ０２〜Ｊ１８）の処理の包含関係についても上記と同様である。
【００９９】
図１３Ｄは、図８Ｂの変換及び実行ステップにおける処理の包含関係を示す。
１行目（Ｎ０１）に、取り込み命令includeが指示されており、そのサブステップとして２〜１９行目（Ｎ０２〜Ｎ１９）の各ステップが実行されることがわかる。２〜１９行目（Ｎ０２〜Ｎ１９）の処理の包含関係についても上記と同様である。
【０１００】
図１３Ｅは、図９Ｂの変換及び実行ステップにおける処理の包含関係を示す。
１行目（Ｏ０１）に、取り込み命令includeが指示されており、そのサブステップとして２〜２２行目（Ｏ０２〜Ｏ２２）の各ステップが実行されることがわかる。２〜２２行目（Ｏ０２〜Ｏ２２）の処理の包含関係についても上記と同様である。
【０１０１】
実施例１
オープンソースのＣＲＭアプリケーションであるSugar CRM 5.0.0c (http://www.sugarcrm.com/)の場合において、１関数１クラス方式において生成されるインタフェース担当クラスの数は2864個であり、一方、本発明の実施態様である複数関数１インタフェース方式において生成されるインタフェース担当クラスの数は941個であった。よって、複数関数１インタフェース方式では、１関数１クラス方式に比べて、1923個のインタフェース担当クラスの数が削減された。
上記結果より、本発明の実施態様である複数関数１インタフェース方式では、従来のコンパイル方法に比べて、動作の遅いリフレクション機構を用いることなく、生成されるインタフェース担当クラスの数を削減することができる。特に、本発明の実施態様である複数関数１インタフェース方式において、ソースプログラムにおいて単一のコンパイル単位（例えば、ファイル単位）に宣言される関数／メソッドの数が多いほどインタフェース担当クラスの数を削減できることから、本発明の効果が大きく奏されている。

【特許請求の範囲】
【請求項１】
動的型付け言語で記述されたソースコードを静的型付け言語で記述されたターゲットコードに変換する方法であって、当該方法はコンピュータに下記ステップを実行させることを含み、当該ステップは、
前記ソースコードから前記ターゲットコードを記憶装置中に生成するステップであって、前記ソースコード中の呼び出し元で用いる関数／メソッドのシグネチャをバッファに格納するステップを含み、前記呼び出し元を生成するために必要なクラスであって、静的型付け言語のインタフェースを担当する当該クラス（以下、インタフェース担当クラス）の生成は、前記呼び出し元の関数／メソッド呼び出しのターゲットコードが実行される直前まで遅延される、前記生成するステップと、
前記バッファに格納された全てのシグネチャに対応する１つのインタフェース担当クラスを前記記憶装置中に生成し、ロードするステップであって、当該生成に応じて前記バッファ中の全てのシグネチャが削除される、前記生成し、ロードするステップと
を含む、前記方法。
【請求項２】
前記方法はコンピュータに下記ステップをさらに実行させることを含み、当該ステップは、
前記ソースコードに対応するターゲットコード中の関数／メソッドの呼び出し命令が実行されるときに、前記呼び出し元で用いられている関数／メソッドのシグネチャに対応するクラスであって、動的型付け言語における呼び出し先の関数／メソッドに対応する実装を担当する当該クラス（以下、実装担当クラス）を前記記憶装置中に生成し、ロードするステップを含む、請求項１に記載の方法。
【請求項３】
前記シグネチャをバッファに格納するステップが、前記ソースコード内の同じ変換単位中に現れる呼び出し元の関数／メソッドのシグネチャに加えて、前記ソースコード内の別の変換単位中に現れる関数／メソッドのシグネチャを前記バッファ中に格納するステップをさらに含む、請求項１に記載の方法。
【請求項４】
前記ソースコードから前記ターゲットコードを生成するステップが、前記ソースコード中の呼び出し元の関数／メソッド呼び出しの生成処理を含む、請求項１に記載の方法。
【請求項５】
前記関数／メソッド呼び出しの生成処理が、
前記呼び出している関数／メソッドに対応するインタフェース担当クラスが生成済みかどうかを検査するステップと、
当該インタフェース担当クラスが生成済みでない場合に、前記呼び出している関数／メソッドのシグネチャを呼出関数リストに追加するステップと、
前記バッファに対応付けられた名前により、未生成のインタフェース担当クラスで型付けされた対象オブジェクトに対する関数／メソッド呼び出しのコードを前記記憶装置中に生成するステップと
を含む、請求項４に記載の方法。
【請求項６】
前記関数／メソッド呼び出しの生成処理が、
前記呼び出している関数／メソッドに対応するインタフェース担当クラスが生成済みかどうかを検査するステップと、
当該インタフェース担当クラスが生成済みである場合に、当該生成済みのインタフェース担当クラスで型付けされた対象オブジェクトに対する前記関数／メソッド呼び出しのコードを前記記憶装置中に生成するステップと
を含む、請求項４に記載の方法。
【請求項７】
前記ソースコードから前記ターゲットコードを生成するステップが、前記ソースコード中の呼び出し元の関数／メソッド宣言の生成処理を含む、請求項１に記載の方法。
【請求項８】
前記関数／メソッド宣言の生成処理が、
宣言されている関数／メソッドに対応するシグネチャがバッファ中にあるか、又はインタフェース担当クラスが生成済みであるか否かを検査するステップと、
前記宣言されている関数／メソッドに対応するシグネチャがバッファ中にない場合で、且つ、前記インタフェース担当クラスが生成済みでない場合に、宣言している関数／メソッドのシグネチャを宣言関数リストに追加するステップと
を含む、請求項７に記載の方法。
【請求項９】
前記関数／メソッド宣言の生成処理が、
宣言されている関数／メソッドに対応するシグネチャがバッファ中にあるか、又はインタフェース担当クラスが生成済みであるか否かを検査するステップと、
前記宣言されている関数／メソッドに対応するシグネチャがバッファ中にない場合、又は、前記インタフェース担当クラスが生成済みでない場合に、対応するインタフェース担当クラスの名前を宣言インタフェース・リストに追加するステップと
を含む、請求項７に記載の方法。
【請求項１０】
前記関数／メソッド宣言の生成処理が、
前記宣言されている関数／メソッドの処理のスクリプトのバイトコードを前記記憶装置中に生成するステップと、
前記生成したバイトコードを宣言している関数／メソッドに対応させるコードを前記記憶装置中に生成するステップと
をさらに含む、請求項８又は９に記載の方法。
【請求項１１】
前記インタフェース担当クラスを生成し、ロードするステップが、
宣言関数リストが空であるか否かを検査するステップと、
前記宣言関数リストが空でない場合に、宣言インタフェース・リスト中に、バッファに対応付けられたインタフェース担当クラスの名前があるか否かを検査するステップと、
前記バッファに対応付けられたインタフェース担当クラスの名前がある場合に、宣言関数リスト及び呼出関数リスト中のシグネチャを前記バッファに追加するステップと
をさらに含む、請求項１０に記載の方法。
【請求項１２】
前記インタフェース担当クラスを生成し、ロードするステップが、
前記追加されたシグネチャから１つのインタフェース担当クラスを前記記憶装置中に生成し、ロードするステップと、
前記ロードされたインタフェース担当クラスの名前を宣言インタフェース・リストに追加するステップと
をさらに含む、請求項１１に記載の方法。
【請求項１３】
前記インタフェース担当クラスを生成し、ロードするステップが、
宣言関数リストが空であるか否かを検査するステップと、
前記宣言関数リストが空でない場合に、宣言インタフェース・リスト中に、バッファに対応付けられたインタフェース担当クラスの名前があるか否かを検査するステップと、
前記バッファに対応付けられたインタフェース担当クラスの名前がない場合に、宣言関数リスト中のシグネチャから、前記バッファとは独立した統合インタフェース担当クラスを生成及びロードするステップと、
前記ロードされたインタフェース担当クラスの名前を宣言インタフェース・リストに追加するステップと
をさらに含む、請求項１０に記載の方法。
【請求項１４】
前記インタフェース担当クラスを生成し、ロードするステップが、
宣言関数リストが空であるか否かを検査するステップと、
前記宣言関数リストが空である場合に、前記呼出関数リスト中のシグネチャを前記バッファに追加するステップと
をさらに含む、請求項１０に記載の方法。
【請求項１５】
前記実装担当クラスを生成し、ロードするステップが、
前記ソースコードの変換単位に実装が存在しないシグネチャを持つ関数のダミーの実装を上記実装担当クラス中に用意するステップ
をさらに含む、請求項２に記載の方法。
【請求項１６】
前記方法はコンピュータに下記ステップをさらに実行させることを含み、当該ステップは、
前記変換されたターゲットコードを実行するステップをさらに含む、請求項１〜１５のいずれか１項に記載の方法。
【請求項１７】
前記実行するステップが、
前記バッファ中のシグネチャ全てに対応する統合インタフェース担当クラスがに利用されている場合に、当該ロードを要求するステップと、
当該要求に応じて、バッファ中の全てのシグネチャから１つの統合インタフェース担当クラスを生成し、ロードするステップと
をさらに含む、請求項１６に記載の方法。
【請求項１８】
動的型付け言語で記述されたソースコードを静的型付け言語で記述されたターゲットコードに変換するコンピュータであって、
前記ソースコードから前記ターゲットコードを記憶装置中に生成する生成部であって、当該生成部は前記ソースコード中の呼び出し元で用いる関数／メソッドのシグネチャをバッファに格納し、及び前記呼び出し元を生成するために必要なクラスであって、静的型付け言語のインタフェースを担当する当該クラス（以下、インタフェース担当クラス）の生成は、前記呼び出し元の関数／メソッド呼び出しのターゲットコードが実行される直前まで遅延される、前記生成部と、
前記バッファに格納された全てのシグネチャに対応する１つのインタフェース担当クラスを前記記憶装置中に生成し、ロードする第１の処理部であって、当該生成に応じて前記バッファ中の全てのシグネチャが削除される、前記第１の処理部と
を含む、前記コンピュータ。
【請求項１９】
前記ソースコードに対応するターゲットコード中の関数／メソッドの呼び出し命令が実行されるときに、前記呼び出し元で用いられている関数／メソッドのシグネチャに対応するクラスであって、動的型付け言語における呼び出し先の関数／メソッドに対応する実装を担当する当該クラス（実装担当クラス）を生成し、ロードする第２の処理部をさらに含む、請求項１８に記載のコンピュータ。
【請求項２０】
コンピュータに、請求項１〜１７のいずれか１項に記載の方法の各ステップを実行させるコンピュータ・プログラム。

【図１Ａ】

【図１Ｂ】

【図１Ｃ】

【図２Ａ】

【図２Ｂ】

【図２Ｃ】

【図３Ａ】

【図３Ｂ】

【図３Ｃ】

【図３Ｄ】

【図４Ａ】

【図４Ｂ】

【図４Ｃ】

【図４Ｄ】

【図５】

【図６Ａ】

【図６Ｂ】

【図６Ｃ】

【図６Ｄ】

【図６Ｅ】

【図６Ｆ】

【図７】

【図８Ａ】

【図８Ｂ】

【図９Ａ】

【図９Ｂ】

【図１０Ａ】

【図１０Ｂ】

【図１０Ｃ】

【図１０Ｄ】

【図１０Ｅ】

【図１０Ｆ】

【図１１Ａ】

【図１１Ｂ】

【図１１Ｃ】

【図１２】

【図１３Ａ】

【図１３Ｂ】

【図１３Ｃ】

【図１３Ｄ】

【図１３Ｅ】

【公開番号】特開２０１１−１１３３９４（Ｐ２０１１−１１３３９４Ａ）
【公開日】平成２３年６月９日（２０１１．６．９）
【国際特許分類】
【出願番号】特願２００９−２７０５０６（Ｐ２００９−２７０５０６）
【出願日】平成２１年１１月２７日（２００９．１１．２７）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ　ＢＵＳＩＮＥＳＳ　ＭＡＳＣＨＩＮＥＳ　ＣＯＲＰＯＲＡＴＩＯＮ
【復代理人】
【識別番号】１０００８５５４５
【弁理士】
【氏名又は名称】松井　光夫
【復代理人】
【識別番号】１００１１８５９９
【弁理士】
【氏名又は名称】村上　博司
【Ｆターム（参考）】