(57)【要約】【課題】ソフトウェアポーティングの間のビルドエラーの訂正を自動化するツールを提供する。【解決手段】ソースコードをビルドするコンパイラを備えたツールチェーンを含むランタイム環境における使用のためにソースコードをポーティングする方法に関する。方法は、ソースコードがランタイム環境においてビルドされる間のビルドエラーに関連するソースコードフラグメントを取得し、そのシグニチャを作成し、シグニチャを、以前のビルドエラーとそれらの修正との履歴から構成されるエラーデータベースに含まれるエンティティと自動的に比較し、１以上の類似した以前のビルドエラーを当該ビルドエラーとし、１以上の修正を当該ビルドエラーに対する解決案の候補とし、当該ビルドエラーを再現することなくソースコードがコンパイルできるまでソースコードを候補のソースコード及び／又はツールチェーン変更の夫々により順にコンパイルし、当該ビルドエラーとその修正としての変更とを記憶する。【選択図】図３Ａ
2015026365.tif 000002
【特許請求の範囲】
【請求項１】
ソースコードをビルドするコンパイラを備えたツールチェーンを含むランタイム環境における使用のために前記ソースコードをポーティングする方法であって、
前記ソースコードが前記ランタイム環境においてビルドされる間のビルドエラーに関連するソースコードフラグメントを取得し、
前記ソースコードフラグメントのシグニチャを作成し、
前記シグニチャを、前記ランタイム環境における以前のビルドエラーとソースコード及び／又はツールチェーン変更の形をとる前記以前のビルドエラーの修正との履歴から構成されるエラーデータベースに含まれるエンティティと自動的に比較し、
前記比較を使用して、１又はそれ以上の類似した以前のビルドエラーを当該ビルドエラーとし、前記ソースコード及び／又はツールチェーン変更のうちの１又はそれ以上を当該ビルドエラーに対する解決案の候補として識別し、
当該ビルドエラーを再現することなく前記ソースコードがコンパイルできるまで、前記ソースコードを前記候補のソースコード及び／又はツールチェーン変更の夫々により順にコンパイルし、
当該ビルドエラーを前記エラーデータベースに記憶し、当該ビルドエラーの修正として、当該ビルドエラーを再現することなく前記ソースコードがコンパイルできる変更を記憶する、方法。
【請求項２】
前記ソースコードフラグメントの前記シグニチャは、前記ソースコードフラグメントを非言語依存表現に変換し、次いで中間表現からシグニチャ、望ましくはハッシュシグニチャを作成することによって、作成される、
請求項１に記載の方法。
【請求項３】
前記ソースコードフラグメントの前記シグニチャは、当該ビルドエラー前後の複数の範囲レベルの夫々について範囲レベルシグニチャを含む、
請求項１又は２に記載の方法。
【請求項４】
初期学習フェーズが実行され、ビルドエラー及びそれらの既知の解決法のトレーニングセットが前記データベースにおいて確立されることを可能にする、
請求項１乃至３のうちいずれか一項に記載の方法。
【請求項５】
解決法の候補は、当該ビルドエラーの現在のランタイム環境における修正の有効性、及び／又は関連性に従って優先順位をつけられる、
請求項１乃至４のうちいずれか一項に記載の方法。
【請求項６】
前記修正の有効性は、該修正の使用に成功してビルドエラーが解決されるたびにインクリメントされるスコアに基づく、
請求項５に記載の方法。
【請求項７】
当該ビルドエラーの前記関連性は、前記以前のビルドエラーにおけるシグニチャがどの程度前記ソースコードフラグメントの前記シグニチャに一致するかに基づく、
請求項５又は６に記載の方法。
【請求項８】
前記エラーデータベースは、異なるランタイム環境におけるビルドエラーと、異なるアプリケーションのソースコードとを含むビルドエラーを記憶する、
請求項１乃至７のうちいずれか一項に記載の方法。
【請求項９】
前記エラーデータベースにおけるビルドエラーフィールドは、エラーメッセージと、フラグメントシグニチャ、エラー分類、ランタイム環境詳細、及びアプリケーション詳細のうちの１又はそれ以上とを含み、当該ビルドエラーは、前記ビルドエラーデータベースフィールドのいずれか又は全てと比較される、
請求項１乃至８のうちいずれか一項に記載の方法。
【請求項１０】
前記ソースコードフラグメントが取得される場合にエラーメッセージを取得し、該エラーメッセージを、前記ソースコードフラグメントの前記シグニチャが作成される場合に分類し、該エラーメッセージの分類を、前記シグニチャと前記エラーデータベースに含まれる前記エンティティとの比較の前に、前記エラーデータベースに含まれる前記エンティティと自動的に比較する
請求項１乃至９のうちいずれか一項に記載の方法。
【請求項１１】
前記エラー分類は、前処理、コンパイルタイム、及びリンクタイムエラーを識別し分けるように、望ましくは、エラーのタイプに関する更なる細分を有して、分割される、
請求項９又は１０に記載の方法。
【請求項１２】
前記エラー分類は、与えられるエラーメッセージ、ソースコード分析及び何らかのエラーコード又は診断メッセージに基づき割り当てられる、
請求項９乃至１１のうちいずれか一項に記載の方法。
【請求項１３】
前記ビルドエラーの前記関連性は、前記類似した以前のビルドエラーのデータベースフィールドがどの程度当該ビルドエラーと一致するかに基づく、
請求項９乃至１２のうちいずれか一項に記載の方法。
【請求項１４】
前記ソースコードと同じアプリケーションからのエラーデータベースに含まれるエンティティ又は以前のビルドエラーは最初に前記シグニチャと比較され、修正が見つけられない場合に、何らかの他のアプリケーションからの以前のビルドエラーのエラーデータベースに含まれるエンティティが前記シグニチャと比較される、
請求項１乃至１３のうちいずれか一項に記載の方法。
【請求項１５】
ソースコードをビルドするコンパイラ（を備えたツールチェーン）を含む新しいランタイム環境による使用のために前記ソースコードをポーティングする際にエラーを訂正するよう配置される装置であって、
前記ソースコードが前記ランタイム環境においてビルドされる間のビルドエラーに関連するソースコードフラグメントを取得するよう配置される入力部と、
前記ソースコードフラグメントのシグニチャを作成するよう配置されるシグニチャ作成部と、
前記ランタイム環境における以前のビルドエラーとソースコード及び／又はソフトウェア構成変更の形をとる前記以前のビルドエラーの修正との履歴から構成されるエラーデータベースと、
前記シグニチャを前記エラーデータベースに含まれるエンティティと自動的に比較するよう配置される比較部と、
前記比較を使用して、１又はそれ以上の類似した以前のビルドエラーを当該ビルドエラーとし、前記ソースコード及び／又はソフトウェア構成変更のうちの１又はそれ以上を当該ビルドエラーに対する解決案の候補として識別するよう配置される識別部と、
当該ビルドエラーを再現することなく前記ソースコードがコンパイルできるまで、前記識別をされたソースコード及び／又はソフトウェア構成変更の夫々による前記ソースコードのコンパイルを順に可能にするよう配置されるループインプッタ部と、
当該ビルドエラーと、当該ビルドエラーの修正として、当該ビルドエラーを再現することなく前記ソースコードがコンパイルできる変更とを前記エラーデータベースに記憶するよう配置されるデータベース更新部と
を有する装置。
【請求項１６】
前記エラーデータベースは、前記ランタイム環境に関する情報を記憶するシステムテーブルと、ビルドされるアプリケーションコードに関する詳細を記憶するアプリケーションテーブルと、コードフラグメント及びそれらのビルドが成功可能であるかどうかのインジケーションを記憶するコードフラグメントテーブルと、前記以前のビルドエラーを記憶するエラーテーブルとを有する、
請求項１５に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソースコードをポーティングする方法及び装置に関する。
【背景技術】
【０００２】
ポーティングは、実行可能なプログラム又は他のユーザレディのソフトウェアプロダクトが、そもそもそれが設計されたものとは異なるコンピューティングコンテキストのために作成され得るように、ソフトウェア（例えば、アプリケーションソフトウェア又はライブラリ）を適応させるプロセスである。よって、ソフトウェアは、異なるプラットフォーム（ハードウェアアーキテクチャ及びセットアップ）、異なるシステム（ここでは、オペレーティングシステムを付加したプラットフォームを指すために使用される。）、又は異なるランタイム環境（ここでは、プラットフォーム及びシステム、コンパイラ、ライブラリ並びに他の設定をユーザ環境に含めるために使用される。）へポーティングされてよい。
【０００３】
ソフトウェアは、それが多種多様な異なるコンピューティング環境で実行される場合に、又はそれを新しい環境へポーティングする費用がそれをスクラッチから書き込む費用よりも安い場合に、移植性がある（potable）と呼ばれ得る。ソフトウェアをポーティングする費用がその実装費用に対して安ければ安いほど、そのソフトウェアはますます移植性があると言われる。
【０００４】
本発明は主に、実行可能なプログラム又は他のプロダクトを作成するために使用されるプログラミングツール（コンパイラ、パラレルライブラリ等）のツールチェーンを形成する異なるアーキテクチャ及びセットアップ及びソフトウェアスタックを有する幅広いスーパーコンピューティングプラットフォームへコードをポーティングすることが一般的である高性能コンピューティング（ＨＰＣ；High  Performance  Computing）アプリケーション、ライブラリ及びツールを対象とする。なお、本発明はまた、例えば、他のフィールドから及び他のプラットフォームへアプリケーションをポーティングすることにおいて、より幅広く適用可能である。
【０００５】
本発明が有益である幾つかの分野は、利用可能になってきている新しい低電力且つあつらえのスーパーコンピューティングプラットフォームへのアプリケーションのポーティングにある。そのようなシステムは、低電力プロセッサ（例えば、ＡＲＭ）、複数コアプロセッサ（例えば、インテルのＭＩＣアーキテクチャ）、又は特にＨＰＣ市場のために設計されたプロセッサ（富士通のＳＰＡＲＣ６４ＩＸｆｘ）からビルドされる。それらのプラットフォームへアプリケーションをポーティングすることは、商品ｘ８６系のシステムに由来するそれらにとって大きな課題である。
【０００６】
図１は、場合によりコンパイラ、パラレルプログラミングライブラリ（例えば、ＭＰＩライブラリ）又は他のシステム固有のツールの異なる組により、新しいアーキテクチャへアプリケーション、ライブラリ又はソフトウェアの他の片をポーティングする際に必要とされるステップを表す。これに関連して、語ライブラリは、動作を呼び出す特定のインターフェースによる動作の実施の集合を含むと考えられてよい。
【０００７】
ステップＰ１０で、ソースコードが取得され、ステップＰ２０でそれは解凍され、続くステップＰ３０でコンパイルに備える。ステップＰ４０はコードをコンパイルし、次いで、コンパイルエラーがある場合は、Ｐ５０で修正され、コードは再びコンパイルされる。そうではなく、コンパイルエラーがない場合は、品質保証（ＱＡ；Quality  Assurance）試験がステップＰ６０で行われ、試験に合格した場合は、コードはステップＰ７０でパッケージ化され、ステップＰ８０でインストールされ、ステップＰ９０で文書化される。
【０００８】
ＱＡ試験に失敗した場合は、ステップＰ１００でデバッギングが行われ、ステップＰ３０でのコンパイルの準備に至る。
【０００９】
この説明から、コンパイル段階の間に反復ステップが存在することが分かる。‘コンパイル’段階はここでは、ソフトウェアの片がＱＡ試験及びインストールの準備ができていると考えられる全ての（ビルド）ステップ、例えば、ライブラリのためのオブジェクトファイルのコンパイル及びパッケージ化並びにアプリケーションのためのコンパイル及び連結を表す点に留意されたい。何らかのエラーがこの時点で起こる場合は、通常のポーティングフローから枝分かれし、それらのエラーを修正することが必要である。
【００１０】
図２は、コンパイル時エラーを修正する際に呼び出される反復プロセスをより詳細に示す。エラーが起こる場合に、通常は、記述的なエラーメッセージがコンパイラから出力される。ユーザ、アプリケーション開発者又はシステム管理者はその場合に、それらのエラーを解決するために必要とされる修正のタイプを特定するよう（手動により）それらのエラーを解析する。起こりえるエラーの例には、不正確な又は欠けているコンパイラオプション、非標準のコード又は不正確なプリプロセッサ指令によるソースコードにおける不一致、あるいは、欠けている従属ライブラリ又はユーティリティがある。エラーの修正が適用されると、コードは再コンパイルされる。プロセスの更なる繰り返しは、他のコンパイル時エラーが起こる場合に行われる。
【００１１】
図１に関して既に記載されたステップＰ２０乃至Ｐ６０は、コンパイル時エラーを修正するためのステップＰ５０の展開とともに示される。エラーは、ステップＰ５１で解析され、修正のタイプに応じて、例えば、Ｐ５２、Ｐ５３又はＰ５４において修正される。
【００１２】
ステップＰ５２は、欠けているライブラリ又は他のユーティティのための修正を提供し、ステップＰ５３は、不正確な又は欠けているコンパイラオプションであってよく、ステップＰ５４は、ソースコード“パッチ”又は変更を必要とするソースコードにおける不一致である。
【００１３】
目下、上記のプロセスは主として手動プロセスであり、コードをポーティングするヒトからの又はエラーの性質に依存するシステム開発チームからの相当の時間及び尽力を必要とする。ポーティングの取り組みを助けることができる幾つかのツールが存在し、例えば、不審な且つ移植性がないコード構造にフラグを出すＬｉｎｔ、ポーティング及びセキュリティのエラーを見つけるＩｎｔｅｌ  Ｓｔａｔｉｃ  Ｓｅｃｕｒｉｔｙ  Ａｎａｌｙｓｉｓツール、並びにクローン及び不能のソースコードを検出するＢａｕｈａｏｕプロジェクトがある。多くの技術報告、ウェブサイト及びブログがまた、如何にして特定のアーキテクチャへポーティングすべきかに関して利用可能である。しかし、それらの解決法はただ１つの特定の範囲のみを自動化するか、又はオフラインのガイドであり、ソフトウェアをポーティングする個人の部分において大きな労力を依然として必要とする。
【発明の概要】
【発明が解決しようとする課題】
【００１４】
このように、ソフトウェアポーティングの間のビルドエラーの訂正を自動化するツールを提供することが望ましい。
【課題を解決するための手段】
【００１５】
本発明の第１の態様の実施形態に従って、ソースコードをビルドするコンパイラを備えたツールチェーンを含むランタイム環境における使用のために前記ソースコードをポーティングする方法であって、
前記ソースコードが前記ランタイム環境においてビルドされる間のビルドエラーに関連するソースコードフラグメントを取得し、
前記ソースコードフラグメントのシグニチャを作成し、
前記シグニチャを、前記ランタイム環境における以前のビルドエラーとソースコード及び／又はツールチェーン変更の形をとる前記以前のビルドエラーの修正との履歴から構成されるエラーデータベースに含まれるエンティティと自動的に比較し、
前記比較を使用して、１又はそれ以上の類似した以前のビルドエラーを当該ビルドエラーとし、前記ソースコード及び／又はツールチェーン変更のうちの１又はそれ以上を当該ビルドエラーに対する解決案の候補として識別し、
当該ビルドエラーを再現することなく前記ソースコードがコンパイルできるまで、前記ソースコードを前記候補のソースコード及び／又はツールチェーン変更の夫々により順にコンパイルし、
当該ビルドエラーを前記エラーデータベースに記憶し、当該ビルドエラーの修正として、当該ビルドエラーを再現することなく前記ソースコードがコンパイルできる変更を記憶する、方法が提供される。
【００１６】
本発明の様々な実施形態は、しばしば自動コード訂正エンジン（Automatic  Code  Correction  Engine）（ＡＣＣＥ）と呼ばれ、ツールチェーンの幾つかの態様に又はソースコード自体に関連したビルドエラーの自動訂正の使用により、ソースコードが新しいプラットフォーム及び／又は新しいランタイム環境へポーティングされることを可能にする。このポーティングは、新しいコンパイラのような新しいツールチェーン要素への移動を含んでよい。発明者は、失敗したコンパイル実行からの膨大なデータ及び適用されたその後の修正が存在し、それらがユーザ入力の必要なしにエラーの原因を特定し訂正するよう異なるポーティングプロジェクトにわたって使用され得るとの認識に達した。自動コード訂正エンジンの目的は、アプリケーション又はライブラリを、それが前に試験されていなかったアーキテクチャにおいて又は、例えば、所与のコンパイラ／ＭＰＩ／他のライブラリ設定のために（すなわち、何らかの以前のランタイムアプリケーションとはどこか異なるランタイム環境において）、自動的にビルドすることができるツールを提供することである。それは、アプリケーションがビルドエラーを生成する時点からアプリケーションを取り込み、エラーを自動的に解析し、適切な修正を適用することができる。自動コード訂正エンジンは、ソースコードシグニチャの使用によりソースコードに対して“深コード検査（deep  code  inspection）”を実行することができる。これは更に、コード品質がより移植可能な且つ標準準拠のソースコードを与えるよう改善され得る範囲を識別するために使用され得る。ポーティングエラー回復のプロセスを自動化することによって、ユーザ及びシステム管理者から必要とされる時間、労力及び問題領域の知識は有意に低減され得る。
【００１７】
発明実施形態は、ポーティングエラーを解析し訂正するプロセスを自動化することによって、先行技術における上記の問題に対処する。これは、深コードソース解析と組み合わされてよい。システム全体の学習データベースは、ビルドエラー及びそれらの続く修正を記憶し、如何なるユーザ入力も伴わずにエラーを自動的に修正するために使用されてよい。
【００１８】
当業者には明らかなように、コンパイルの間又は他のビルド段階の間にビルドエラーを解消するために、ソースコードが変更されてよく、あるいは、ツールチェーンに対する変更が存在してよい。いずれの場合にも、同じ修正が、将来のビルドエラーとの何らかの類似性が存在する場合に再使用のために適切であり、このことは本発明の基礎を形成する。
【００１９】
ソースコードフラグメントとのここでの言及は、ビルドエラーに関連したコードの部分を指し、全コード長の何割かを形成してよいが、通常は全コード長よりも短い。ソースコードフラグメントは、短文式表現、又はコンパイルを妨げるエラー・セクションの前後のソースコードの省略表現と考えられ得るシグニチャを有する。シグニチャは、ソースコードを表すための何らかの適切な方法によって作成されてよい。望ましくは、ＡＣＣＥ及び発明実施形態の方法は言語非依存である。
【００２０】
幾つかの発明実施形態において、前記ソースコードフラグメントの前記シグニチャは、前記ソースコードフラグメントを非言語依存表現に変換し、次いで中間表現からシグニチャ、望ましくはハッシュシグニチャを作成することによって、作成される。これは、異なる言語におけるソースコードが、原の言語において適用された修正（又は解決法）から恩恵を受けることを可能にする。
【００２１】
当業者ならば、ハッシュシグニチャが、データのブロックを取って一定サイズのビット列を返し、データに対する如何なる変更もハッシュ値を変更するようにするアルゴリズムであってよいハッシュ関数の結果であることに気付くであろう。
【００２２】
有利に、前記ソースコードフラグメントの前記シグニチャは、当該ビルドエラー前後の複数の範囲レベルの夫々について範囲レベルシグニチャを含む。
【００２３】
ここでの範囲（scope）の使用は、プログラムに含まれるがエラーのコンテキスト範囲内にあるエンティティ範囲（すなわち、変数オブジェクト、変数、オブジェクト、イレース、関数等）を含む。一般的な意味で、範囲は、識別子が実施されておりエンティティに対して決定され得る（すなわち、エンティティが可視的である場合）コンピュータプログラム内のコンテキストである。よって、１範囲レベルはエラーが起こる範囲であってよく、次の範囲レベルはループであってよく、更なる範囲レベルはプロシージャであってよい、等。コードの一義的な表現から生成される各範囲レベルについてシグニチャが存在する。これに加えて、原のソースコードを使用する最後の範囲レベルについて他のシグニチャが存在し、これはコンテキストハッシュである。コンテキストハッシュは、まさに同じソースファイルが確かめられ以前に訂正されているエラーの解決法を可能にする。
【００２４】
一実施形態において、全体のプログラム範囲レベルまでのソースコードフラグメント前後の各範囲レベルは、範囲レベルシグニチャを有する。
【００２５】
エラーデータベースは、発明実施形態にとって重要な概念であり、よって自動コード訂正にとって重要な構成要素である。エラーデータベースは学習データベースであり、望ましくは、初期学習フェーズが実行され、ビルドエラー及びそれらの既知の解決法のトレーニングセットが前記データベースにおいて確立されることを可能にする。学習フェーズは自動化されてよく、又は半自動化され若しくは手動であってよい。
【００２６】
例えば、アプリケーションを新しいシステムへポーティングする場合に、トレーニングコードの組は自動的に実行されてよく、既知のエラー及び既知の解決法ともにコードを提示する。
【００２７】
発明実施形態に従って、候補の変更が識別されると、それらは順に、ソースコードがビルドエラーを再現することなくコンパイルするまで、コンパイルの間用いられる。候補の解決法は、如何なる順序でも、例えば、識別の順序において、又はとり得る修正に関与する変更の程度の順序において、試されてよい。幾つかの実施形態において、解決法の候補は、当該ビルドエラーの現在のランタイム環境における修正の有効性、及び／又は関連性に従って優先順位をつけられる。
【００２８】
例えば、前記修正の有効性は、該修正の使用に成功してビルドエラーが解決されるたびにインクリメントされるスコアに基づいてよい。
【００２９】
追加的に、又は代替的に、当該ビルドエラーの前記関連性は、前記以前のビルドエラーにおけるシグニチャがどの程度前記ソースコードフラグメントの前記シグニチャに一致するかに基づいてよい。マッチングプロセスは、単一のシグニチャ又は上記の範囲レベルシグニチャの一部若しくは全てに基づいてよい。
【００３０】
幾つかの発明実施形態に係る１つの利点は、エラーデータベースが、アプリケーション又は他のソースコードが実行されるハードウェア及びソフトウェア環境の異なる構造に対応するエラーを記憶することができる点である。これは、現在のエラーを解決するのを助けるよう他の環境からの以前のエラーの使用を可能にする。
【００３１】
よって、エラーデータベースは、僅かに異なるツールチェーン／ソフトウェアスタックにより以前に実行されたソースコードからのみならず、異なるプラットフォームから並びに異なるシステム及びハードウェアアーキテクチャからもビルドエラーを記憶する（なお、後者の場合には、それらのビルドエラーは、上記の初期学習フェーズを用いて導入されると期待される。）。エラーデータベースは、異なるアプリケーションからのソースコードと、更に、現在ポーティングされているソースコードと同じアプリケーションからのソースコードとを、関連する修正が同じアプリケーションにおいて再び適用され得る多くの場合における付随するより高い可能性を有して、記憶することができる。
【００３２】
エラーデータベースは、エラーを識別しそれらを他のエラーと比較するのに有用であるあらゆる適切なビルドエラーフィールドを含んでよい。例えば、ビルドエラーフィールドは、エラーメッセージ、シグニチャ、並びにエラー分類、ランタイム環境詳細（ハードウェア及び／又はソフトウェア詳細であってよい。）、及びアプリケーション詳細のうちのいずれか又は全てを含むことができる。
【００３３】
これまでの態様は、シグニチャによる現在のビルドエラーと以前に修正されたビルドエラーとの比較に焦点を合わせてきた。しかし、他の態様は、ビルドエラーと以前のビルドエラーとの間の比較のためにエラー分類及び／又は他のエラー詳細の使用を参照する。上記のビルドエラーフィールドのいずれか又は全ては、現在処理されているビルドエラーとの比較のために使用されてよい。１つの望ましい実施形態では、様々なフィールドが累積フィルタリングプロセスにおいて、望ましくは、第１のフィルタとしてのエラーメッセージ分類とともに使用される。
【００３４】
よって、本発明の更なる態様の実施形態に従って、ソースコードをビルドするコンパイラを備えたツールチェーンを含むランタイム環境における使用のために前記ソースコードをポーティングする方法であって、
前記ソースコードが前記ランタイム環境においてビルドされる間のビルドエラーに関連するエラーメッセージ及びソースコードフラグメントを取得し、
前記エラーメッセージを分類し、
前記エラーメッセージの分類を、前記ランタイム環境における以前のビルドエラーとソースコード及び／又はツールチェーン変更の形をとる前記以前のビルドエラーの修正との履歴から構成されるエラーデータベースに含まれるエンティティと自動的に比較し、
前記比較を使用して、１又はそれ以上の類似した以前のビルドエラーを当該ビルドエラーとし、前記ソースコード及び／又はツールチェーン変更のうちの１又はそれ以上を当該ビルドエラーに対する解決案の候補として識別し、
当該ビルドエラーを再現することなく前記ソースコードがコンパイルできるまで、前記ソースコードを前記候補のソースコード及び／又はツールチェーン変更の夫々により順にコンパイルし、
当該ビルドエラーを前記エラーデータベースに記憶し、当該ビルドエラーの修正として、当該ビルドエラーを再現することなく前記ソースコードがコンパイルできる変更を記憶する、方法が提供される。
【００３５】
本発明のこの態様は、他の態様の特徴及び従属する特徴のいずれかと、それらが互換性を有する限り組み合わされてよい。
【００３６】
多くの実施形態において、現在のビルドエラーをエラーデータベースに含まれる以前のビルドエラーと比較するいずれの方法も利用可能であってよい。一実施形態において、エラーメッセージの分類についての比較が最初に行われ、次いで、シグニチャによる比較が、変更の候補が分類の比較によっては見つけられない場合（又は変更の候補が成功しなかった場合）にのみ行われる。代替的に、分類による比較及びシグニチャによる比較は、並行して行われてよく、あるいは、比較の他の順序に関して上述されたのと同じように、シグニチャによる比較が最初に行われ、シグニチャによる比較の方法が失敗した場合にのみ分類による比較が行われる。
【００３７】
本発明の更なる他の態様の実施形態に従って、ソースコードをビルドするコンパイラを備えたツールチェーンを含むランタイム環境における使用のために前記ソースコードをポーティングする方法であって、
前記ソースコードが前記ランタイム環境においてビルドされる間のビルドエラーに関連するエラーメッセージ及びソースコードフラグメントを取得し、
前記エラーメッセージを分類し且つ前記ソースコードフラグメントのシグニチャを作成し、
前記エラーメッセージの分類及び／又は前記シグニチャを、前記ランタイム環境における以前のビルドエラーとソースコード及び／又はツールチェーン変更の形をとる前記以前のビルドエラーの修正との履歴から構成されるエラーデータベースに含まれるエンティティと自動的に比較し、
前記比較を使用して、１又はそれ以上の類似した以前のビルドエラーを当該ビルドエラーとし、前記ソースコード及び／又はツールチェーン変更のうちの１又はそれ以上を当該ビルドエラーに対する解決案の候補として識別し、
当該ビルドエラーを再現することなく前記ソースコードがコンパイルできるまで、前記ソースコードを前記候補のソースコード及び／又はツールチェーン変更の夫々により順にコンパイルし、
当該ビルドエラーを前記エラーデータベースに記憶し、当該ビルドエラーの修正として、当該ビルドエラーを再現することなく前記ソースコードがコンパイルできる変更を記憶する、方法が提供される。
【００３８】
本発明の第１の態様に従うシグニチャによる比較を含む望ましい実施形態は、ソースコードフラグメントが取得される場合にエラーメッセージを取得し、ソースコードフラグメントのシグニチャが作成される場合にエラーメッセージを分類し、エラーメッセージの分類を、シグニチャとデータベース内のエンティティとの比較の前に、エラーデータベース内のエンティティと自動的に比較する。かかる実施形態では、シグニチャの比較は、分類の比較が如何なる適切な変更ももたらさない場合にのみ実行されてよい。
【００３９】
エラー分類の如何なる適切な方法も、本発明の如何なる態様においても使用されてよい。例えば、幾つかの実施形態において、エラー分類は、前処理、コンパイルタイム、及びリンクタイムエラーを識別し分けるように、望ましくは、エラーのタイプに関する更なる細分を有して、分割される。
【００４０】
前記エラー分類は、与えられるエラーメッセージ、ソースコード分析及び何らかのエラーコード又は診断メッセージに基づき割り当てられてよい。
【００４１】
解決法の候補が前記ビルドエラーの関連性に従って優先順位をつけられる場合に、前記ビルドエラーの前記関連性は、前記類似した以前のビルドエラーのデータベースフィールドがどの程度当該ビルドエラーと一致するかに基づいてよい。この場合に、エラー分類は、他のフィールドよりも、関連性を評価する際に高い重み付けを与えられてよく、１又はそれ以上の他のデータベースフィールドはより高い重み付けを与えられてよく、あるいは、全てのデータベースフィールドは等しい重みを有してよい。
【００４２】
シグニチャの比較は如何なる適切な形態においても行われてよい。なお、上述されたように、同じアプリケーションのための修正は、より高い成功の確率を有し、従って、一実施形態において、前記ソースコードと同じアプリケーションからのエラーデータベースに含まれるエンティティ又は以前のビルドエラーは最初に前記シグニチャと比較され、修正が見つけられない場合に、何らかの他のアプリケーションからの以前のビルドエラー又はエラーデータベースに含まれるエンティティが前記シグニチャと比較される。
【００４３】
この方法は、現在のランタイム環境とより類似したランタイム環境のためのビルドエラーが最初に、より類似しないランタイム環境より前に比較されるように拡張され得る。
【００４４】
本発明の装置態様に従って、ソースコードをビルドするコンパイラを備えたツールチェーンを含む新しいランタイム環境による使用のために前記ソースコードをポーティングする際にエラーを訂正するよう配置される装置であって、
前記ソースコードが前記ランタイム環境においてビルドされる間のビルドエラーに関連するソースコードフラグメントを取得するよう配置される入力部と、
前記ソースコードフラグメントのシグニチャを作成するよう配置されるシグニチャ作成部と、
前記ランタイム環境における以前のビルドエラーとソースコード及び／又はソフトウェア構成変更の形をとる前記以前のビルドエラーの修正との履歴から構成されるエラーデータベースと、
前記シグニチャを前記エラーデータベースに含まれるエンティティと自動的に比較するよう配置される比較部と、
前記比較を使用して、１又はそれ以上の類似した以前のビルドエラーを当該ビルドエラーとし、前記ソースコード及び／又はソフトウェア構成変更のうちの１又はそれ以上を当該ビルドエラーに対する解決案の候補として識別するよう配置される識別部と、
当該ビルドエラーを再現することなく前記ソースコードがコンパイルできるまで、前記識別をされたソースコード及び／又はソフトウェア構成変更の夫々による前記ソースコードのコンパイルを順に可能にするよう配置されるループインプッタ部と、
当該ビルドエラーと、当該ビルドエラーの修正として、当該ビルドエラーを再現することなく前記ソースコードがコンパイルできる変更とを前記エラーデータベースに記憶するよう配置されるデータベース更新部と
を有する装置が提供される。
【００４５】
装置は、ビルドエラーに関連するエラーメッセージを分類するよう配置される分類部と、上記の方法の従属する特徴を反映する装置の他の構成要素とを有してよい。
【００４６】
本態様の有利な発展に従って、前記エラーデータベースは、前記ランタイム環境に関する情報を記憶するシステムテーブルと、ビルドされるアプリケーションコードに関する詳細を記憶するアプリケーションテーブルと、コードフラグメント及びそれらのビルドが成功可能であるかどうかのインジケーションを記憶するコードフラグメントテーブルと、前記以前のビルドエラーを記憶するエラーテーブルとを有してよい。
【００４７】
更なる態様に従って、コンピューティングシステムにロードされる場合に、当該システムを上記の装置を提供するよう構成するプログラムが提供される。他の定義では、実行される場合に上記の説明に従ってソースコードをポーティングする方法を実行するコンピュータプログラムが提供される。
【００４８】
本発明の種々の態様のいずれかの特徴及び従属する特徴は自由に組み合わされてよい。例えば、装置（又はエンジン若しくはコンピュータシステム）の望ましい実施形態は、方法態様のうちの１又はそれ以上の１又はそれ以上の望ましい特徴に対応する機能を組み込むよう構成されてよい。
【００４９】
本発明は、コンピュータハードウェア、ファームウェア、ソフトウェア、又はそれらの組み合わせにおいて実施され得る。本発明は、１又はそれ以上のハードウェアモジュールによる実行のために、又はそれらの動作を制御するために、コンピュータプログラム又はコンピュータプログラムプロダクト、すなわち、情報媒体において、例えば、機械により読み取り可能な記憶装置において又は伝播される信号において有形に具現されるコンピュータプログラムとして実施され得る。
【００５０】
コンピュータプログラムは、コンピュータプログラム部分又は１よりも多いコンピュータプログラムの形をとることができ、コンパイル又はインタープリットされた言語を含む如何なる形式のプログラミング言語においても記述され得、それは、スタンドアローンのプログラムとして又はモジュール、コンポーネント、サブルーチン、若しくはデータ処理環境における使用に適した他のユニットとして、を含む如何なる形態でも開発され得る。コンピュータプログラムは、１つのサイトにあるか又は複数のサイトにわたって展開されて通信ネットワークによって相互に接続される１つのモジュールで又は複数のモジュールで実行されるよう開発され得る。
【００５１】
本発明の方法ステップは、入力データに対して作用して出力を生成することによって本発明の機能を実行するようコンピュータプログラムを実行する１又はそれ以上のプログラム可能なプロセッサによって実行され得る。夫々のプロセッサは１又はそれ以上のコアを有してよい。
【００５２】
コンピュータプログラムの実行に適したプロセッサには、一例として、汎用及び特別目的の両方のマイクロプロセッサと、あらゆる種類のデジタル又はバイロジカルコンピュータのいずれかの１又はそれ以上のプロセッサとがある。一般に、プロセッサは、読み出し専用メモリ若しくはランダムアクセスメモリ又はその両方から命令及びデータを受け取る。コンピュータの必須要素は、命令及びデータを記憶する１又はそれ以上のメモリ装置へ結合される、命令を実行するためのプロセッサである。
【００５３】
本発明は、特定の実施形態に関して記載される。他の実施形態は、特許請求の範囲の適用範囲内にある。例えば、本発明のステップは、異なる順序において実行され、依然として望ましい結果を達成することができる。
【００５４】
望ましい実施形態に従う装置は、特定の機能を実行するよう構成され、動作し、又は配置されるように記載される。この構成又は配置は、ハードウェア若しくはミドルウェア又は何らかの他の適切なシステムの使用によってよい。望ましい実施形態において、構成又は配置はソフトウェアによる。
【００５５】
ここで、本発明は、図面に示される具体的な限定されない実施形態を参照して記載される。
【発明の効果】
【００５６】
本発明の実施形態によれば、ソフトウェアポーティングの間のビルドエラーの訂正を自動化するツールを提供することが可能となる。
【図面の簡単な説明】
【００５７】
【図１】新しいアーキテクチャへソフトウェアをポーティングする場合に伴うステップを示すフローチャートである。
【図２】コンパイル時エラーを扱う場合に必要とされるステップを示すフローチャートである。
【図３Ａ】本発明の実施形態のフローチャートである。
【図３Ｂ】本発明の他の実施形態のフローチャートである。
【図４】先行技術及び本発明の実施形態の図表比較である。
【図５】自動コード訂正エンジン（ＡＣＣＥ）のハイレベル図である。
【図６】ＡＣＣＥの詳細図である。
【図７】ライブラリ機能を比較するグラフである。
【図８】深コード検査の図である。
【図９】エラーデータベースの直接サーチを示すフローチャートである。
【図１０】データベースによるシグニチャ比較のフローチャートである。
【図１１】学習データベース及びそれと本発明の実施形態のＡＣＣＥ／方法との関係の絵による表現である。
【図１２】学習データベースのためのエンティティ関係図である。
【図１３】自動コード訂正データベースのためのトレーニングフェーズを表す。
【発明を実施するための形態】
【００５８】
発明実施形態は、コンパイルエラー、リンクエラー又はプリプロセッサビルドエラーを、学習データベースから自動の深コード検査（シグニチャ比較）を用いて識別される同じか又は類似するエラーの解決法によって訂正する方法を記載する。加えて、システムは、コンピューティングシステムのために最適化されたライブラリの使用及び高度化されたエラー訂正を提供するようコンピューティングシステムにおいてコンパイラを含むツールチェーンとしっかりと一体化され得る。
【００５９】
概して、以下で記載されるツール／エンジンは、コンピューティングシステムへのアプリケーションのポーティングの間に直面されるビルドエラーを解消するようエラー及び解決法のデータベースを検索することによって働く。
【００６０】
エラーに対する直接的な解決法が見つけられない場合は、ツールは、同じアプリケーションからの及び／又は同じハードウェア及びソフトウェア環境による同様の解決法を自動適応させることによって、エラーを解消しようと試みることができる。
【００６１】
データベースは、エラー及び既知の解決法のトレーニングセットを用いて自動的に入力されてよい。トレーニングセットは、新しいアプリケーションから分かるエラーにより引き続き更新され得、それにより、それらは新しいシステムへ移動する際に使用され得る。
【００６２】
前処理ビルドエラーは、データベースからの知識と組み合わされるプリプロセッサフラグ解析及び検査を実行することによって、解消され得る。
【００６３】
欠けているか又は不正確なフラグに関連するコンパイルエラーは、発明実施形態がシステムで利用可能なコンパイラの認識を得ることができるので、解消され得る。これは、データベースのトレーニングフェーズの間に学習され、ツール使用の間に引き続き更新される。
【００６４】
発明実施形態は、ビルドエラーに直面しているアプリケーションにおいて不一致を識別するよう異なるアプリケーションにわたってソースコードフラグメントを解析するために深コード検査を使用する。望ましくは、深コード検査はシグニチャを使用するが、代替案は中間表現のライン毎又はバイト毎の比較である。
【００６５】
新しいシステムへ移動する場合に、増え続けるトレーニングセットはその新しいシステムで継続され得、解決法の学習データベースは、新しいシステムへ自動的に適応され得る。次いで、データベース及びツールは、この新しいシステムで、他のシステムで既に見られたアプリケーションビルドエラーを解消することができる。
【００６６】
図３Ａは、ビルドエラーから始まる発明実施形態の例示である。ステップＳ１０で、ソースコードフラグメントが取得され、ステップＳ２０で、そのシグニチャが作成される。ステップＳ３０で、シグニチャはエラーデータベースと（例えば、エラーデータベース内の以前のビルドエラーのシグニチャと）比較される。ステップＳ４０で、ビルドエラーを解消し得る１又はそれ以上の変更が識別される。ステップＳ５０で、ソースコードがコンパイルされ、コンパイルが成功する場合は、ビルドエラー及び適用される修正がステップＳ６０でデータベースに記憶される。コンパイルが成功しない場合は、次の変更がステップＳ７０で試される。簡単のために、フローチャートは、不成功の変更が見つけられる場合の処理の頓挫及び手動による変更を示さない。
【００６７】
図３Ｂは、シグニチャ及びエラー分類の両方がエラーデータベースとの比較のために使用されるフローチャートを示す。ステップＳ１００で、ソースコードフラグメントが取得される。ステップＳ１１０で、シグニチャが作成され、エラーが分類される。ステップＳ１２０で、エラー分類及び／又はシグニチャは、エラーデータベース内の以前のビルドエラーと比較される。このように、処理は、１又はそれ以上の識別されることをステップＳ１３０で続ける。コンパイルステップＳ１４０及びコンパイルの失敗時におけるステップＳ１６０で、異なる変更が適用され、コードが繰り返しコンパイルされる。コンパイルが成功する場合は、ビルドエラー及び変更がステップＳ１５０でデータベースに記憶される。
【００６８】
当然に、発明実施形態に従う自動の比較及び変更の考えられる多くの方法のうちの２つにすぎない。
【００６９】
図４は、先行技術と発明実施形態との高度な比較である。先行技術におけるビルドエラーの手動による修正は、システムエキスパート及びアプリケーションエキスパートの両方を必要とする。それは時間がかかり、アプリケーションエキスパートとシステムエキスパートとの間の直接的なやり取りを必要とする。
【００７０】
対照的に、幾つかの発明実施形態はトレーニングフェーズを含む。トレーニングフェーズは、システムエキスパートからのシステムセットアップフェーズにおけるオフラインの入力がシステム全体の知識データベースを提供するのに役立つことを可能にする。エラーデータベースは、ライブシステムにおいて使用される学習データベースとして提供される。エラーがデータベースの使用によって自動的に修正されない場合は、アプリケーションエキスパートは助言を求めてよい。方法は全体として又は少なくとも大部分は自動である。システムエキスパートとアプリケーションエキスパートとの間のやり取りは分断され、そして、データベースはシステム知識及びアプリケーション履歴を含み、学習し続ける。
【００７１】
図５は、自動コード訂正エンジン（ＡＣＣＥ；Automatic  Code  Correction  Engine）のハイレベル図を示す。破線囲みは、コンパイルタイムエラーのポーティング及び修正のフロー内でＡＣＣＥが適合することを示す。エンジンは本質的にデータベースと協調するソフトウェアツールであり、多数の機能から成り、それらの機能は全て、ソフトウェアの片を新しいプラットフォームにポーティングする処理を簡単化する手段を提供するよう組み合わさる。
【００７２】
それらの特徴は、次のことを含むことができる：
●外部依存を識別し解消すること；
●ハードウェア特有のコード又は関数呼び出しに関連するコンパイルエラーを識別し訂正すること；
●ビッグエンディアン又はリトルエンディアンのバイト順を正確に選択することのようなアーキテクチャ特有の入力／出力問題；
●プリプロセッサ指令解析；
・他の部分でのコンパイルタイムエラーを解消し得るソースコードの一部分で使用される指令を見つけること；及び
・エラーを引き起こしている可能性がある如何なる悪用された指令も特定すること；
●エラーを解消するコンパイラフラグへのエラーのマッピングを通じて欠けているコンパイラフラグに関連するエラーを認識すること；
●共通のコンパイラ（又は他のツールチェーン）エラーのデータベースを提供するようエラー及びそれらの後の修正を記憶すること。この学習データベースは、コード訂正エンジンの中心にある。それは、あらゆる新しいアプリケーション又はライブラリのためのコンパイルタイムエラーを訂正するために使用されるよう、プラットフォームで実行される全てのポーティングからの履歴データのインテリジェントな使用を可能にする；
●より良いコード再利用を可能にするよう、共通の又は類似するコードブロックを検索してそれらをプロシージャ／メソッドにカプセル化することができる深コード検査。
【００７３】
図６は、ＡＣＣＥの詳細なフローを示す。ツールは、新しいシステムへポーティングされているアプリケーション又はライブラリがビルドエラーに直面する場合にトリガされ得る。これは、ビルド処理の前処理段階、コンパイル段階、若しくはリンク段階又はあらゆる他の段階でのエラーであってよい。
【００７４】
エラー及びその関連するエラーメッセージを伴うコードのフラグメントはエンジンによってパースされ解析される。これから、エラーは、データベース内で類似のエラーを検索することによって分類され得る。データベースの検索は、エラーの分類を可能にすることができ、分類はまた、見つけられる可能な解決法の精査を可能にすることができる。エラークラスは、エラーのタイプの更なる細分により前処理、コンパイルタイム及びリンクタイムエラーを識別し分けるように分類される。例えば、コンパイルタイムエラーのクラスは、誤ったコンパイラフラグ、無効な変数の型、又は関数実引数の間の不一致からのエラーを含んでよい。それらのクラスは、エラーメッセージ及びコード解析を通じて、更に、コンパイラに付随するマニュアルにおいてしばしば文書化される診断メッセージ及びコンパイラエラーコードから導出され得る。
【００７５】
後により詳細に記載されるデータベースの構造によれば、幾つかの発明実施形態は、次の３つの方法のうちの全て又は何れかによりエラーに対する解決法を見つけることができる。
【００７６】
１．例えば、検索キーとして記述されるエラークラス及びデータベースフィールドにより、データベースの直接検索を実行すること。直接一致がデータベース内で見つけられる場合は、その解決法が使用される。
【００７７】
２．コードにおいて他のどこかで適用された解決法を見つけるよう同じアプリケーションの他の部分を解析するために自動深コード検査を使用すること。この方法は、コード内で同じポーティングエラーの複数のインスタンスが存在する新しいシステムへアプリケーションをポーティングする場合に直面される極めて一般的なシナリオをカバーする。最初のエラーを（手動により又は自動で）修正し、解決法をデータベースに加えると、残りのエラーの全てがこの情報を用いて自動で修正され得る。
【００７８】
３．データベースに記憶される他のアプリケーションからのコードの自動深コード検査を使用すること。見つけられるいずれかの一致したソースコードフラグメントに対する解決法が、エラーを解消するために適用される。他のアプリケーションコードの解析は事前に、すなわち、以前のエラーが直面された場合に、又は学習データベースのトレーニングフェーズの間に、実行される。
【００７９】
幾つかの実施形態において、エラーに対する直接的な解決法が（直接検索を用いて）見つけられない場合は、ツールは、同じアプリケーション、又はその後に異なるアプリケーション若しくはシステムからの類似した解決法を自動的に適応させることによって、エラーを解消しようと試みる。解決法がデータベースで見つけられる場合に、それらの解決法は、所与のプラットフォーム、例えば、すなわち、ルーチン環境のための夫々の解決法の有効性のスコア及び／又はエラーに対する解決法の関連性に基づき、優先順位をつけられ得る。コード及びその状態のチェックポイントが次いで、最も高い優先度を有する解決法を適用してアプリケーションを再ビルドする前に、作られる。
【００８０】
この実施形態において、優先度スコアが評価され得る２つの方法がある。
【００８１】
１．所与のプラットフォームにおける解決法の有効性。
●これは、システムのためにこれまで働いていた解決法に優先度を与える。夫々のシステムにおける夫々の解決法について、その使用がシステムにおいてエラーを解消するために成功した場合は、スコアがインクリメントされる。スコアが高ければ高いほど、それが使用される可能性も高くなる。このために、余分のフィールドが、システムにおける解決法のスコアを追跡するようデータベースにおいて必要とされる。
●異なる解決法が適用される順序に優先順位をつけるために“データベースの直接検索”機能に使用される。
●最も可能性が高い解決法を最初に適用しようと試みるために、解決法が“直接検索”又は“深コード検査”から見つけられなかった場合に再び“類似の解決の適応”機能に使用される。
【００８２】
２．エラーとの関連性。
●直面されるエラーに最も近い一致を示すエラーの解決法が最初に試される。エラーとの関連性に基づく優先度は、後述されるように、解決法発見アルゴリムが作用する方法に固有である。
●“深コード検査”のために、優先度は、直面されるエラーにほとんどの範囲レベルで一致するソースコードシグニチャを有するエラーの解決法に与えられる。
●“データベースの直接検索”のために、可能な解決法の組は、それらのエラーの詳細（エラーコード、エラーメッセージ、コンパイラタイプ及びフラグ、等）に基づきフィルタリングされる。
【００８３】
同じエラーがアプリケーションの再ビルド後に起こる場合は、コードは、次の解決法が試されることを可能にするように、その前の状態に戻され得る。異なるエラーが起こる場合は、これは、適用される解決法に関係があり、その場合にコードは上記のように戻され得る。あるいは、それは、ビルド処理の間に更に起こったエラーであり、その場合にエラー解析及びデータベース検索のもう１つの繰り返しが実行される
この処理は、アプリケーションのビルドがエラーなしで成功するまで続いてよい。この時点で、コードはＱＡ試験、インストールおよび使用に備える。
【００８４】
ＡＣＣＥの使用の全体を通して、各段階で必要とされたステップを詳述するレポートが開発者のために作られてよい。これは、開発者がどのようなステップが必要とされるのかを制御することを可能にするようインタラクティブであっても、あるいは、ツールが完全に自動で実行されることを可能にするようログの形をとってもよい。
【００８５】
図６は、ＡＣＣＥが機能することができる１つの方法の詳細図である。ステップＳ２００で、コードは解凍され、ステップＳ２１０で、コードはコンパイルのために準備される。ステップＳ２２０で、コードはコンパイルされ、クエリＳ２３０でコンパイルエラーがない場合は、ログがステップＳ２４０で作成され、情報が学習データベースへ送信される。処理は、ステップＳ２５０におけるＱＡ試験で終了する。
【００８６】
コンパイルエラーが検出される場合は、最初にステップＳ２６０で、エラーが前に見えられたかどうかを確かめるチェックがある。これは、例えば、プロシージャがコード変更を試みるループから戻っている場合に起こりえる。エラーが前に見えられていた場合は、コードはステップＳ２７０で（変更前の状態へ）戻され、ステップＳ２８０で、他の解決法が利用可能であるかどうかのクエリが起こる。ステップＳ２９０で開発者へのレポートがない場合は、開発者はステップＳ３００でエラーを修正するようヒューリスティクスを適用し、解決法がステップＳ３００でデータベースに加えられる。
【００８７】
よって、幾つかの発明実施形態の変形例においては、自動的に検出される適切な変更がない場合は、レポートが開発者に適用され、手動による修正が適用され、手動による修正はその後に、将来の使用のために自動的に又は手動によりデータベースに入力される。その段階で、ステップＳ３２０でコードが再ビルドされ、ステップＳ２３０へループバックして、再ビルドされたコードにおけるコンパイルエラーが検出される。
【００８８】
ステップＳ２６０へ戻り、エラーが前に見られていなかった場合は、エラーはステップＳ３３０で分類される。シグニチャが同段階で作成されてよく、現在のビルドエラーのためのエラーテーブルに入力される。エラークラスは、データベースとの比較によって見つけられてよい。ステップＳ３４０で、解決法は、（例えば、後により詳細に説明されるように）分類又は深コード検査を用いてデータベースにおいて見つけられる。この段階で、前のエラー分類段階と同じように、学習データベースによる情報転送が起こる。クエリＳ３５０で、解決法が見つけられなかった場合は、プロシージャは、ステップＳ２９０、Ｓ３００及びＳ３１０へ進み、前述同様に再ビルド及び再コンパイルを伴って、開発者へレポートを提供し、エラーを修正し、解決法をデータベースに加える。解決法が見つけられる場合は、ステップＳ３６０でコード（及び、例えば、使用されるコンパイル設定、ライブラリ及びコンパイラを含む設定）のチェックポイントが作られ、ステップＳ３７０で修正が適用される。コードは次いで、ステップＳ３２０で再ビルドされ、再コンパイルされる。
【００８９】
如何にしてＡＣＣＥが実際に働くかについての３つの例が先の段落では与えられている。
【００９０】
［１．型不一致によるコンパイルエラー］
発明実施形態は、データベースのトレーニングフェーズの間に学習され、続けてツール使用の間に更新される、システムで利用可能なコンパイラの知識を得ることができるので、それらは誤った又は欠けているコンパイラフラグに関連するエラーを修正することができる。
【００９１】
型不一致エラーを患うコードのサンプルスニペットが以下に示される。サブルーチンｆｏｏは、引数として８バイトの整数を要求する。サブルーチン呼び出しにおける実引数はデフォルト整数型であり、ＳＰＡＲＣ６４  ＩＸｆｘシステムでのコンパイラについては４バイトである。
【表１】
2015026365.tif 000003
【００９２】
先に示されるように、コードがコマンドｇｆｏｒｔｒａｎ  ｅｘ１．ｆ９０によりＳＰＡＲＣ６４  ＩＸｆｘシステムでのＧＮＵ  Ｆｏｒｔｒａｎコンパイラを用いてコンパイルされる場合に、次のエラーが起こる：
【数１】
2015026365.tif 000004
この時点で、ＡＣＣＥが引き継ぐ。ＡＣＣＥは、エラーをコンパイルタイムエラーとして、特に、サブルーチン型不一致エラーとして分類し、実引数及び仮引数をセーブする。このようなエラーのデータベース検索が次いで実行され、それが一般的なエラーである場合は、データベースによって学習されている可能性がある。データベース検索の部分として仮引数及び実引数を用いることによって、返される最も高い優先度の解決法のうちの１つは、−ｆｄｅｆａｕｌｔ−ｉｎｔｅｇｅｒ−８のコンパイラフラグを使用することであるべきである。ＡＣＣＥがこの解決法を適用する場合に、エラーは訂正され、コードのビルドは成功する。
【００９３】
［２．誤ったプリプロセッサフラグによるビルドエラー］
サンプルコードセグメントが以下に示される。これは、プリプロセッサの条件付きコンパイル指令が、異なるアーキテクチャに最適化されるコードセグメント、以下に示される場合では、インテルｘ８６アーキテクチャのために最適化されたコードセグメント及びあらゆる機械に作用する一般的なコードセグメントから選択するために使用される一般的な符号化／最適化技術を用いる。
【表２】
2015026365.tif 000005
【００９４】
ＳＰＡＲＣ６４  ＩＸｆｘのような非ｘ８６ベースのシステムでのＤＸ８６プリプロセッサ条件付きコンパイルフラグによるコンパイルは、ビルドエラーを生じさせる（エラーのタイプ、すなわち、コンパイラエラー又はリンクエラーは、このプリプロセッサ領域におけるコードに依存する。）。
【００９５】
ＡＣＣＥは、このソースファイルのためのビルドコマンドを見て、プリプロセッサフラグが使用されたことを認識することによって、自動的にこのエラーを解消する。ソースコードの解析は次いで、利用可能な異なるプリプロセッサ指令値を取り出す。夫々のオプションは、ビルドエラーに対する可能な解決法として順に試される。ＤＧＥＮＥＲＩＣオプションが試される場合に、コードのビルドは成功する。
【００９６】
データベースからの知識とプリプロセッサフラグの解析及び検査とを組み合わせると、ＡＣＣＥはまた、プリプロセッサフラグ又は指令により引き起こされるアプリケーションにおけるエラーを解消することができる。
【００９７】
例えば、２つのコンパイラ、コンパイラＡ及びコンパイラＢが存在してよく、データベースは、それらのコンパイラの両方が同様に機能すると学習している。コンパイラＡ及びコンパイラＢのためのコードパスは、ＣＯＭＰＬＩＥＲ−Ａ及びＣＯＭＰＬＩＥＲ−Ｂプリプロセッサマクロによって夫々制御され得る。アプリケーションは、それがコンパイラＡにより正確に動作するようにＣＯＭＰＬＩＥＲ−Ａプリプロセッサフラグマクロを使用する以下のコードスニペットを有する。
【表３】
2015026365.tif 000006
なお、このアプリケーションは、コンパイラＢによりコンパイルされる場合に失敗する。
【００９８】
エラーを解消するよう、コード訂正ツールは、使用されるプリプロセッサフラグの検査を実行する。それはＣＯＭＰＬＩＥＲ−Ａマクロを見つける。データベース及びコンパイラツールチェーンの知識を通じて、ツールは、コンパイラＡ及びコンパイラＢが同様に機能すると知る。従って、それは、以下に示されるように、コンパイラＢがコンパイラＡと同じコードパスを実行するようにコードを変更する：
【表４】
2015026365.tif 000007
【００９９】
［３．リンクエラー］
ＡＣＣＥがシステムで利用可能なツールチェーンを知っている場合に、それは、外部のライブラリ及び他の依存性から引き起こされるエラーを扱うことができる。以下に示されるサンプルＭａｋｅｆｉｌｅは、離散型フーリエ変換（ＤＦＴ；Discrete  Fourier  Transform）を実行するためにＦＦＴＷライブラリを利用するコードのためのビルドルールを与える。ＦＦＴＷライブラリの場所はビルドスクリプトにハードコーディングされ、この場合には、ＳＰＡＲＣ６４  ＩＸｆｘシステムのためのインストールを指し示す。これがｘ８６システムでコンパイルされる場合は、リンクエラーが以下に示されるように起こる。
【表５】
2015026365.tif 000008
【０１００】
ビルドからの出力を用いて、ＡＣＣＥはエラーをリンクエラーであると分類する。エラー出力をセーブし解析することによって、エラーは特にＦＦＴＷライブラリに関係があることが分かる。この場合に、データベースから提案される解決法のうちの１つは、ＦＦＴＷライブラリの正確な場所が使用されることを確かにするようリンクコマンドを確認することであるべきである。ＡＣＣＥがこの修正を実施する場合に、コードはエラーなしでビルドされる。
【０１０１】
発明実施形態は、欠けている、誤った又は間違いだらけのライブラリ又は支援ファイルに起因するエラーを扱うことができる。実施形態はシステム及びツールチェーンの知識を記憶することができるので、かかる実施形態は、欠けているライブラリ又はファイルが既にシステムで利用可能であるかを特定し、それらのファイルをダウンロードせずに使用することができる。この追加のステップは、既にシステムにあるライブラリがシステムのハードウェアに最適化されている可能性が高いので、結果として得られる性能に関して大きな意味を有する。
【０１０２】
これは図７において明らかに示される。図７において、マトリクス乗算ベンチワークのために、システムで予め利用可能なライブラリは、ダウンロードされたライブラリよりも性能が全てのとり得るサイズについて５倍優れていることが分かる。ＡＣＣＥは、欠けているライブラリをダウンロードしようと試みる前に、システムで予め利用可能なライブラリの使用を可能にする。
【０１０３】
発明実施形態の利点が以下に与えられる他の潜在的な特徴及びシナリオ：
［●深コード検査］
発明実施形態は、ビルドエラーに直面しているアプリケーションにおいて不一致を特定するようアプリケーション内で又は異なるアプリケーションにわたってソースコードフラグメントを解析するために自動の深コード検査を実行する。
【０１０４】
この深コード検査機能の新規の使用の例が図８に示される。ここで、２つのコード、コードＡ及びコードＢを有するとする。コードＢは、コードＡからのコードフラグメント（コードフラグメントＺ）を再利用する。いずれのコードもシステムＸにおいて働く。コードＡが他のシステム、システムＹへポーティングされた場合に、コードＡをシステムＹで正確に働かせるようこのコードフラグメントを変更する必要がある（このとき、コードフラグメントＺ′）。
【０１０５】
データベースは、ソースコードと、夫々のシステムでコードを正確に働かせるのに必要な変更とを記憶するので、コードＢがシステムＹへポーティングされる場合に、深コード検査は、コードＢにおいてコードＡにあったのと同じコードフラグメントＺを見つける。コードＢをシステムＹで働かせるよう適用される同じ変更、すなわち、コードフラグメントＺをコードフラグメントＺ′により置換することが次いで、コードＢをシステムＹで働かせるよう適用され得る。
【０１０６】
［●システムのツールチェーンの認識］
特定のエラーは、システムで利用可能なツールチェーン及びコンパイラに関する文脈情報によらずに解決でない。発明実施形態は、ツールチェーンとの堅固な一体化を使用し、エラー訂正を強化するようコンパイラの深い知識を開発することができる。
【０１０７】
［●新しい未知のシステムへの移動］
新しいシステムへ移動する場合に、増え続けるトレーニングセットが新しいシステムで実行され、解決法の学習データベースは自動的に新しいシステムに適応される。データベース及びツールは次いで、他のシステムで予め見られたアプリケーションビルドエラーをこの新しいシステムで解消することができる。
【０１０８】
［●試験されていないシステムへのアプリケーションの移動］
ツールがシステムＸでのアプリケーションＡの知識と、システムＹでのアプリケーションのＢ，Ｃ，Ｄ，．．．の知識とを有する場合は、それは、システムＹでのアプリケーションＡに係るエラーを自動的に修正するために使用され得る。
【０１０９】
［データベースの直接検索］
データベースの直接検索は、アプリケーションによって直面されるビルドエラーに適用可能である解決法の一部を見つけるために、データベースに記憶されている全ての可能な解決法の反復フィルタリング処理を使用することによって働くことができる。
【０１１０】
処理の開始時に、データベースに記憶されている全ての解決法は、所与のビルドエラーを解決するための候補として適格である。
【０１１１】
次いで、エラーが起こる場合に取り出される情報項目、例えば、エラーコード；エラーメッセージ、コンパイラタイプ、コンパイラフラグ、前処理フラグ、ロードされたライブラリ、及び環境変数の夫々は、解決法の候補数を減らすよう（データベースフィールドとして）データベースに記憶されている同じ情報と比較される。この処理の終わりに、夫々の残りの解決法の候補が適用される。解決法が適用される順序は、夫々の解決法の有効性スコアに基づき優先順位をつけられる。図９は、如何にしてデータベースの直接検索が働くかを表す。最初のステップＳ４００で、解決法は同じエラーコードにより見つけられる。ステップＳ４１０で、前のセットアップにおいて見つけられた全ての解決法はエラーメッセージによってフィルタリングされる。ステップＳ４２０で、同じコンパイラからのｋ個の解決法のみが保持される（解決法は除去されない。）。ステップＳ４３０で、同じ前処理フラグを有する解決法のみが保持される。２つの解決法の候補が残る。それらは順に試される。
【０１１２】
図９は、エラー分類に従うフィルタリングの第１の可能なステップを省略する。この第１のステップは特に有用なフィルタである。ツール及び直接検索機能は、分類によらずに働くことができるが、解決法を見つけるにはより有効ではなく且つより時間がかかる。
【０１１３】
［深コード検査］
ビルドエラーが起こる場合に、エラーの周りのアプリケーションのソースコードフラグメントはまたデータベースに記憶され得る（エラー特性並びにコンパイラ及びシステム環境を捕捉するための他の情報とともに）。深コード検査は、以下の処理（図１０に示される。）によって働く：
●ステップＳ５００で、エラーの周りのソースコードフラグメントが取り出される。
【０１１４】
●コードフラグメントは、一義的な中間表現へ変換される（Ｓ５１０）。これは、ソースコード、変数及び機能名を非言語の又はプログラミングスタイル特有の表現に変換する。
【０１１５】
●これから、シグニチャ（又はハッシュ値）が、コードフラグメントで利用可能な範囲レベル（例えば、ソースファイル、プロシージャ、ループ）ごとに作成される（Ｓ５２０）。これは、複数段の比較が行われることを可能にし、それにより解決法の候補は、それがコードフラグメントのためのシグニチャの夫々とどの程度一致するのかに依存してフィルタリングされる。
【０１１６】
●最深の範囲レベルから外側へ作用して、各範囲レベルでのコードフラグメントのためのシグニチャは、類似の範囲レベルにあるデータベースからのシグニチャと比較される（Ｓ５３０）。ほとんどの範囲レベルと一致する解決法は次いで、ビルドエラーを訂正しようと試みるために適用される。
【０１１７】
●最後に、コードのチェックポイントが作られ、解決法の候補がステップＳ５４０で適用される。
【０１１８】
ここで、範囲は、コードがアクセス可能である最深のブロックから最も外側へ作用するプログラムの全てのブロックを含む。
【０１１９】
エラーの周りの異なる範囲レベルを示すソースコードの片の例は、以下のソースコードにおいて示される。
【表６】
2015026365.tif 000009
【表７】
2015026365.tif 000010
【０１２０】
発明実施形態において、ハッシュシグニチャは、直面されるエラーごとに作成され、データベースエラーテーブルに入力されてよい。たとえ特定のエラーが解決法を見つけるために深コード検査を使用しないとしても、シグニチャの作成は、将来のエラーがそれらのエラーを検索することができるよう深コード検査を利用することを可能にする。
【０１２１】
中間表現の夫々の範囲レベルでシグニチャを作成することに加えて、ソースファイルのためのコンテキストシグニチャが作成され記憶される。これは、正確な同じソースファイルが以前に見られて訂正されているエラーの解決法を可能にする。
【０１２２】
一例として、上記のテーブルは、如何にしてＡＣＣＥが実際に働くことができるのかの第１の例として記載されるコンパイラエラーの例のためのデータベース内のエラーテーブルの内容を示す。
【０１２３】
最初にハッシュシグニチャを得るよう、エラーの様々な範囲レベルが決定される。型不一致によるコンパイルエラーの同じ例のための範囲レベルが以下に示される。
【表８】
2015026365.tif 000011
【０１２４】
ソースコードは次いで、以下に示されるように非言語の特定の中間表現へ変換される。
【表９】
2015026365.tif 000012
【０１２５】
中間表現コードを用いて、ハッシュシグニチャは、特定される範囲レベルの夫々について生成される。標準のハッシュ関数は、テーブルに加えるべきコード与えるシグニチャを生成するために使用され得る（ＳＨＡ−１関数が以下の例のために使用される。）。
【０１２６】
範囲レベル１のためのハッシュシグニチャ：
【数２】
2015026365.tif 000013
範囲レベル２のためのハッシュシグニチャ：
【数３】
2015026365.tif 000014
範囲レベル３のためのハッシュシグニチャ：
【数４】
2015026365.tif 000015
【０１２７】
全ソースファイルのたけのハッシュシグニチャ（コンテキストハッシュ）：
エラーを含む全ソースファイルのためのハッシュシグニチャがまた作成される。これはコンテキストシグニチャと呼ばれる。例となるコードのためのコンテキストシグニチャは以下に示される。
【数５】
2015026365.tif 000016
【０１２８】
学習データベースはＡＣＣＥにとって重要な構成要素である。その設計及びレイアウトは、ツールが、プラットフォームにおいて以前に試験されていない新しいアプリケーションについて自動的にビルドエラーを訂正することができるプラットフォームの全体にわたるポーティング知識及び熟練したシステムを開発することを可能にする。
【０１２９】
データベースは、エラーが起きる場合に、エラー自体並びにエラーの時点でのコンパイラ及びシステム環境の状態に関する情報がセーブされるように、構造化される。この情報は次のものを含むことができる：
●プラットフォームのハードウェア及びソフトウェアスタックに関する詳細；
●コンパイラからのエラーコード；
●コンパイラバージョン；
●コンパイラフラグ；
●プリプロセッサマクロ；
●ロードされたライブラリ及びパス環境変数；
●エラーを含むソースコードのフラグメント；
●ソースコードパッチ、変更された命令、又は実行すべき一連のコマンド若しくはスクリプトのような、エラーのためのその後の修正。夫々の解決法の格付け及び優先度が更に記憶されてよい。
【０１３０】
それらの項目は、データベース内で異なるアプリケーションについて類似のエラーを分類し見つける際に十分な情報を提供する。図１１は、アプリケーションがビルドエラーに直面する場合にデータベースに記憶される情報と、エラーに対する可能な解決法を見つけるために実行されるステップとを表す。
【０１３１】
エラーの詳細は、図示されるように学習データベースへセーブされる。エンジンは、セーブされたエラー詳細を用いて直接検索を適用し、深コード検査を用いて類似の解決法についてアプリケーションの他の部分を解析する。データベースとのインタラクションはこの段階で行われる必要がない。この機能性は、夫々のエラーについてデータベースの参照を必要とせずに、同じアプリケーション内の同じエラーの複数回の発生の解決を可能にする。
【０１３２】
それは次のステップにより働く：
ステップＡ−バグＡの第１のインスタンスを見つける；
ステップＢ−バグＡを修正する；
ステップＣ−アプリケーションにおいてバグＡの更なるインスタンスを探す；
ステップＤ−それらを同様に修正する。
【０１３３】
修正が見つけられると、これはエラー詳細と共にデータベースへセーブされる。
【０１３４】
図１２は、学習データベースの様々なエンティティ／テーブルの間の関係を示す。それらの関係は、自動コード訂正が完全に、アプリケーションにおけるエラーのその直接検索と、深コード検索機能性とを両方とも容易に実施することを可能にする。
【０１３５】
●システムテーブルは、ＡＣＣＥが動作するコンピューティングシステムに関する情報、例えば、アーキテクチャ詳細やソフトウェア環境を記憶する。例えば、このテーブルは、システムのハードウェアに関する情報（ＣＰＵスペック、メモリ、インターコネクトの詳細）と、オペレーティングシステム詳細並びにＯＳチューニングパラメータ及び設定、システムで実行され得るサービス、システムにインストールされるパッケージ及びライブラリ、システムで利用可能なコンパイラの詳細（コンパイラファミリ、バージョン番号）のようなシステムの環境及びソフトウェアに関する詳細とを含む。このコンパイラ情報から、同じシステムにおける及び異なるシステムにわたる異なるコンパイラの間の類似性のレベルを評価することが可能である。最も明らかな類似性のレベルは、同じファミリ（例えば、インテル、ＧＮＵ、富士通）からのコンパイラ、又は異なるシステムにおける全く同じコンパイラに関する。異なるファミリからのコンパイラに関し、コンパイラのフロントエンドにあるトークナイザ（tokenizer）及びパーサ（parser）又はバックエンドにあるコード発生器のようなコンパイラの異なる部分の間には依然として何らかの類似性がある。この情報を保持するために“システム”テーブル内にフィールドが存在すべきである。それらのフィールドは、トレーニングデータセットから又はコンパイラに関するユーザ指定の情報から取得されるパターンによって満たされる。
【０１３６】
●アプリケーションテーブルは、コードの依存性のような、システムでビルドされる夫々のアプリケーションコードに関する高レベルの詳細を保持する。これは、ＡＣＣＥによって使用されたアプリケーションコードの抽出部分を記憶するコードフラグメントテーブルに関連している。
【０１３７】
●コードフラグメントテーブルは、コードフラグメントのビルドに夫々のシステムで成功するかどうかを特定するＯｐｅｒａｂｌｅＯｎＳｙｓｔｅｍと呼ばれるフィールド／属性を更に含む。コードフラグメントが特定のシステムで働かなかった場合に、エラーテーブルにおけるエントリはそのコードフラグメントについて作成される。
【０１３８】
●エラーテーブルは次いで、コードフラグメントが所与のシステムでのビルドに失敗する場合に、エラーコード、エラーメッセージ、コンパイラ、ライブラリ及び他の環境設定を記憶する。このテーブルは、コードフラグメントをシステムで働かせるのに必要とされるステップの組が記憶される解決法フィールドを更に含む。
【０１３９】
●これは、解決法によらずに新しいビルドエラーに適用可能であり得る解決法を見つけるよう（１０で示される記載される自動の深コード検査処理によって）類似のコードフラグメントにおけるビルドエラーの検索を可能にする。
【０１４０】
データベースは２通りの方向においてデータを投入され得る。第１に、それは、それが使用される場合にコンピューティングシステムの詳細を学習することができる。これは、利用可能なシステムツールチェーンのコンパイラ、ライブラリ及び他の部分の知識を得ることと、システムにおける新しい及び既存のアプリケーションのビルドエラーから学習することとを含む。
【０１４１】
また、データベースがビルドエラーのタイプ及びエラーメッセージのフォーマットに対する意識を高めることを可能にするトレーニングフェーズが存在することができる。これは、自動的に実行されるトレーニングコードスイートの形をとる。それは、コンピューティングシステムへ既知のエラーを伴うコードを提示する。結果として得られるエラーメッセージ及び出力は次いで、特定のエラークラスと関連付けられ、エラーの解決法と共にデータベースにおいて記憶され得る。
【０１４２】
図１３は、ＳＰＡＲＣ６４  ＩＸｆｘシステムでの型不一致エラーのためのトレーニングフェーズの例を示す。第１に、既知のバグを伴うコードがシステムでコンパイルされる。そのコードに関する結果として得られるエラーメッセージはデータベースへセーブされる。エラーのための既知の修正が次いで適用され、このようなビルドエラーのための解決法としてセーブされる。類似のエラーメッセージを生成するその後のコードは次いで、可能な解決法としてこの修正を利用することができる。上記のトレーニングフェーズは、エラークラス及び解決法をデータベースに投入するために使用される。
【０１４３】
更に、データベースは、確認される全てのエラーのためのソースコードを記憶するので、それらは、データベースのためのトレーニングセットへ加えられ、新しいシステムへ移動する場合に使用される。
【０１４４】
ＡＣＣＥは、ポーティング処理を高速化し且つ自動化することができ、様々なプラットフォームへアプリケーションをポーティングするのをより容易に且つより速くする。それは、システムに精通していないことがあるアプリケーション開発者や特定分野のエキスパート及びアプリケーションに不慣れであるシステム管理者への負担を軽減することができる。
【０１４５】
更に、このツールは様々なプラットフォームでアプリケーションを実行するのをより容易にするので、それは、アプリケーション開発者がコードにおいて如何なるバグも特定するのを助けることができる。これは、アプリケーションの品質及びロバスト性への信頼を高めるのに役立つ。このようなポーティングの容易さとデータベースに記憶される履歴情報とを組み合わせることによって、ツールは、ソフトウェア製品のライフサイクルの欠くことのできない部分となり得る。
【０１４６】
上記の実施形態に加えて、更に以下の付記を開示する。
（付記１）
ソースコードをビルドするコンパイラを備えたツールチェーンを含むランタイム環境における使用のために前記ソースコードをポーティングする方法であって、
前記ソースコードが前記ランタイム環境においてビルドされる間のビルドエラーに関連するソースコードフラグメントを取得し、
前記ソースコードフラグメントのシグニチャを作成し、
前記シグニチャを、前記ランタイム環境における以前のビルドエラーとソースコード及び／又はツールチェーン変更の形をとる前記以前のビルドエラーの修正との履歴から構成されるエラーデータベースに含まれるエンティティと自動的に比較し、
前記比較を使用して、１又はそれ以上の類似した以前のビルドエラーを当該ビルドエラーとし、前記ソースコード及び／又はツールチェーン変更のうちの１又はそれ以上を当該ビルドエラーに対する解決案の候補として識別し、
当該ビルドエラーを再現することなく前記ソースコードがコンパイルできるまで、前記ソースコードを前記候補のソースコード及び／又はツールチェーン変更の夫々により順にコンパイルし、
当該ビルドエラーを前記エラーデータベースに記憶し、当該ビルドエラーの修正として、当該ビルドエラーを再現することなく前記ソースコードがコンパイルできる変更を記憶する、方法。
（付記２）
前記ソースコードフラグメントの前記シグニチャは、前記ソースコードフラグメントを非言語依存表現に変換し、次いで中間表現からシグニチャ、望ましくはハッシュシグニチャを作成することによって、作成される、
付記１に記載の方法。
（付記３）
前記ソースコードフラグメントの前記シグニチャは、当該ビルドエラー前後の複数の範囲レベルの夫々について範囲レベルシグニチャを含む、
付記１又は２に記載の方法。
（付記４）
初期学習フェーズが実行され、ビルドエラー及びそれらの既知の解決法のトレーニングセットが前記データベースにおいて確立されることを可能にする、
付記１乃至３のうちいずれか一項に記載の方法。
（付記５）
解決法の候補は、当該ビルドエラーの現在のランタイム環境における修正の有効性、及び／又は関連性に従って優先順位をつけられる、
付記１乃至４のうちいずれか一項に記載の方法。
（付記６）
前記修正の有効性は、該修正の使用に成功してビルドエラーが解決されるたびにインクリメントされるスコアに基づく、
付記５に記載の方法。
（付記７）
当該ビルドエラーの前記関連性は、前記以前のビルドエラーにおけるシグニチャがどの程度前記ソースコードフラグメントの前記シグニチャに一致するかに基づく、
付記５又は６に記載の方法。
（付記８）
前記エラーデータベースは、異なるランタイム環境におけるビルドエラーと、異なるアプリケーションのソースコードとを含むビルドエラーを記憶する、
付記１乃至７のうちいずれか一項に記載の方法。
（付記９）
前記エラーデータベースにおけるビルドエラーフィールドは、エラーメッセージと、フラグメントシグニチャ、エラー分類、ランタイム環境詳細、及びアプリケーション詳細のうちの１又はそれ以上とを含み、当該ビルドエラーは、前記ビルドエラーデータベースフィールドのいずれか又は全てと比較される、
付記１乃至８のうちいずれか一項に記載の方法。
（付記１０）
前記ソースコードフラグメントが取得される場合にエラーメッセージを取得し、該エラーメッセージを、前記ソースコードフラグメントの前記シグニチャが作成される場合に分類し、該エラーメッセージの分類を、前記シグニチャと前記エラーデータベースに含まれる前記エンティティとの比較の前に、前記エラーデータベースに含まれる前記エンティティと自動的に比較する
付記１乃至９のうちいずれか一項に記載の方法。
（付記１１）
前記エラー分類は、前処理、コンパイルタイム、及びリンクタイムエラーを識別し分けるように、望ましくは、エラーのタイプに関する更なる細分を有して、分割される、
付記９又は１０に記載の方法。
（付記１２）
前記エラー分類は、与えられるエラーメッセージ、ソースコード分析及び何らかのエラーコード又は診断メッセージに基づき割り当てられる、
付記９乃至１１のうちいずれか一項に記載の方法。
（付記１３）
前記ビルドエラーの前記関連性は、前記類似した以前のビルドエラーのデータベースフィールドがどの程度当該ビルドエラーと一致するかに基づく、
付記９乃至１２のうちいずれか一項に記載の方法。
（付記１４）
前記ソースコードと同じアプリケーションからのエラーデータベースに含まれるエンティティ又は以前のビルドエラーは最初に前記シグニチャと比較され、修正が見つけられない場合に、何らかの他のアプリケーションからの以前のビルドエラーのエラーデータベースに含まれるエンティティが前記シグニチャと比較される、
付記１乃至１３のうちいずれか一項に記載の方法。
（付記１５）
ソースコードをビルドするコンパイラ（を備えたツールチェーン）を含む新しいランタイム環境による使用のために前記ソースコードをポーティングする際にエラーを訂正するよう配置される装置であって、
前記ソースコードが前記ランタイム環境においてビルドされる間のビルドエラーに関連するソースコードフラグメントを取得するよう配置される入力部と、
前記ソースコードフラグメントのシグニチャを作成するよう配置されるシグニチャ作成部と、
前記ランタイム環境における以前のビルドエラーとソースコード及び／又はソフトウェア構成変更の形をとる前記以前のビルドエラーの修正との履歴から構成されるエラーデータベースと、
前記シグニチャを前記エラーデータベースに含まれるエンティティと自動的に比較するよう配置される比較部と、
前記比較を使用して、１又はそれ以上の類似した以前のビルドエラーを当該ビルドエラーとし、前記ソースコード及び／又はソフトウェア構成変更のうちの１又はそれ以上を当該ビルドエラーに対する解決案の候補として識別するよう配置される識別部と、
当該ビルドエラーを再現することなく前記ソースコードがコンパイルできるまで、前記識別をされたソースコード及び／又はソフトウェア構成変更の夫々による前記ソースコードのコンパイルを順に可能にするよう配置されるループインプッタ部と、
当該ビルドエラーと、当該ビルドエラーの修正として、当該ビルドエラーを再現することなく前記ソースコードがコンパイルできる変更とを前記エラーデータベースに記憶するよう配置されるデータベース更新部と
を有する装置。
（付記１６）
前記エラーデータベースは、前記ランタイム環境に関する情報を記憶するシステムテーブルと、ビルドされるアプリケーションコードに関する詳細を記憶するアプリケーションテーブルと、コードフラグメント及びそれらのビルドが成功可能であるかどうかのインジケーションを記憶するコードフラグメントテーブルと、前記以前のビルドエラーを記憶するエラーテーブルとを有する、
付記１５に記載の装置。
【図１】
2015026365.tif 000017
【図２】
2015026365.tif 000018
【図３Ａ】
2015026365.tif 000019
【図３Ｂ】
2015026365.tif 000020
【図４】
2015026365.tif 000021
【図５】
2015026365.tif 000022
【図６】
2015026365.tif 000023
【図７】
2015026365.tif 000024
【図８】
2015026365.tif 000025
【図９】
2015026365.tif 000026
【図１０】
2015026365.tif 000027
【図１１】
2015026365.tif 000028
【図１２】
2015026365.tif 000029
【図１３】
2015026365.tif 000030
【手続補正書】
【提出日】平成26年8月14日(2014.8.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ソースコードをビルドするコンパイラを備えたツールチェーンを含むランタイム環境における使用のために前記ソースコードをポーティングする方法であって、
前記ソースコードが前記ランタイム環境においてビルドされる間のビルドエラーに関連するソースコードフラグメントを取得し、
前記ソースコードフラグメントのシグニチャを作成し、
前記シグニチャを、前記ランタイム環境における以前のビルドエラーとソースコード及び／又はツールチェーン変更の形をとる前記以前のビルドエラーの修正との履歴から構成されるエラーデータベースに含まれるエンティティと自動的に比較し、
前記比較を使用して、１又はそれ以上の類似した以前のビルドエラーを当該ビルドエラーとし、前記ソースコード及び／又はツールチェーン変更のうちの１又はそれ以上を当該ビルドエラーに対する解決案の候補として識別し、
当該ビルドエラーを再現することなく前記ソースコードがコンパイルできるまで、前記ソースコードを前記候補のソースコード及び／又はツールチェーン変更の夫々により順にコンパイルし、
当該ビルドエラーを前記エラーデータベースに記憶し、当該ビルドエラーの修正として、当該ビルドエラーを再現することなく前記ソースコードがコンパイルできる変更を記憶する、方法。
【請求項２】
前記ソースコードフラグメントの前記シグニチャは、前記ソースコードフラグメントを非言語依存表現に変換し、次いで中間表現からシグニチャ、望ましくはハッシュシグニチャを作成することによって、作成される、
請求項１に記載の方法。
【請求項３】
前記ソースコードフラグメントの前記シグニチャは、当該ビルドエラー前後の複数の範囲レベルの夫々について範囲レベルシグニチャを含む、
請求項１又は２に記載の方法。
【請求項４】
初期学習フェーズが実行され、ビルドエラー及びそれらの既知の解決法のトレーニングセットが前記データベースにおいて確立されることを可能にする、
請求項１乃至３のうちいずれか一項に記載の方法。
【請求項５】
解決法の候補は、当該ビルドエラーの現在のランタイム環境における修正の有効性、及び／又は関連性に従って優先順位をつけられる、
請求項１乃至４のうちいずれか一項に記載の方法。
【請求項６】
前記修正の有効性は、該修正の使用に成功してビルドエラーが解決されるたびにインクリメントされるスコアに基づく、
請求項５に記載の方法。
【請求項７】
当該ビルドエラーの前記関連性は、前記以前のビルドエラーにおけるシグニチャがどの程度前記ソースコードフラグメントの前記シグニチャに一致するかに基づく、
請求項５又は６に記載の方法。
【請求項８】
前記エラーデータベースは、異なるランタイム環境におけるビルドエラーと、異なるアプリケーションのソースコードとを含むビルドエラーを記憶する、
請求項１乃至７のうちいずれか一項に記載の方法。
【請求項９】
前記エラーデータベースにおけるビルドエラーフィールドは、エラーメッセージと、フラグメントシグニチャ、エラー分類、ランタイム環境詳細、及びアプリケーション詳細のうちの１又はそれ以上とを含み、当該ビルドエラーは、前記ビルドエラーデータベースフィールドのいずれか又は全てと比較される、
請求項１乃至８のうちいずれか一項に記載の方法。
【請求項１０】
前記ソースコードフラグメントが取得される場合にエラーメッセージを取得し、該エラーメッセージを、前記ソースコードフラグメントの前記シグニチャが作成される場合に分類し、該エラーメッセージの分類を、前記シグニチャと前記エラーデータベースに含まれる前記エンティティとの比較の前に、前記エラーデータベースに含まれる前記エンティティと自動的に比較する
請求項１乃至９のうちいずれか一項に記載の方法。
【請求項１１】
前記エラー分類は、前処理、コンパイルタイム、及びリンクタイムエラーを識別し分けるように、望ましくは、エラーのタイプに関する更なる細分を有して、分割される、
請求項９又は１０に記載の方法。
【請求項１２】
前記エラー分類は、与えられるエラーメッセージ、ソースコード分析及び何らかのエラーコード又は診断メッセージに基づき割り当てられる、
請求項９乃至１１のうちいずれか一項に記載の方法。
【請求項１３】
前記ビルドエラーの前記関連性は、前記類似した以前のビルドエラーのデータベースフィールドがどの程度当該ビルドエラーと一致するかに基づく、
請求項９乃至１２のうちいずれか一項に記載の方法。
【請求項１４】
前記ソースコードと同じアプリケーションからのエラーデータベースに含まれるエンティティ又は以前のビルドエラーは最初に前記シグニチャと比較され、修正が見つけられない場合に、何らかの他のアプリケーションからの以前のビルドエラーのエラーデータベースに含まれるエンティティが前記シグニチャと比較される、
請求項１乃至１３のうちいずれか一項に記載の方法。
【請求項１５】
ソースコードをビルドするコンパイラ（を備えたツールチェーン）を含む新しいランタイム環境による使用のために前記ソースコードをポーティングする際にエラーを訂正するよう配置される装置であって、
前記ソースコードが前記ランタイム環境においてビルドされる間のビルドエラーに関連するソースコードフラグメントを取得するよう配置される入力部と、
前記ソースコードフラグメントのシグニチャを作成するよう配置されるシグニチャ作成部と、
前記ランタイム環境における以前のビルドエラーとソースコード及び／又はソフトウェア構成変更の形をとる前記以前のビルドエラーの修正との履歴から構成されるエラーデータベースと、
前記シグニチャを前記エラーデータベースに含まれるエンティティと自動的に比較するよう配置される比較部と、
前記比較を使用して、１又はそれ以上の類似した以前のビルドエラーを当該ビルドエラーとし、前記ソースコード及び／又はソフトウェア構成変更のうちの１又はそれ以上を当該ビルドエラーに対する解決案の候補として識別するよう配置される識別部と、
当該ビルドエラーを再現することなく前記ソースコードがコンパイルできるまで、前記識別をされたソースコード及び／又はソフトウェア構成変更の夫々による前記ソースコードのコンパイルを順に可能にするよう配置されるループインプッタ部と、
当該ビルドエラーと、当該ビルドエラーの修正として、当該ビルドエラーを再現することなく前記ソースコードがコンパイルできる変更とを前記エラーデータベースに記憶するよう配置されるデータベース更新部と
を有する装置。
【請求項１６】
前記エラーデータベースは、前記ランタイム環境に関する情報を記憶するシステムテーブルと、ビルドされるアプリケーションコードに関する詳細を記憶するアプリケーションテーブルと、コードフラグメント及びそれらのビルドが成功可能であるかどうかのインジケーションを記憶するコードフラグメントテーブルと、前記以前のビルドエラーを記憶するエラーテーブルとを有する、
請求項１５に記載の装置。
【請求項１７】
ソースコードをビルドするコンパイラを備えたツールチェーンを含むランタイム環境における使用のために前記ソースコードをポーティングする方法であって、
前記ソースコードが前記ランタイム環境においてビルドされる間のビルドエラーに関連するエラーメッセージ及びソースコードフラグメントを取得し、
前記エラーメッセージを分類し、
前記エラーメッセージの分類を、前記ランタイム環境における以前のビルドエラーとソースコード及び／又はツールチェーン変更の形をとる前記以前のビルドエラーの修正との履歴から構成されるエラーデータベースに含まれるエンティティと自動的に比較し、
前記比較を使用して、１又はそれ以上の類似した以前のビルドエラーを当該ビルドエラーとし、前記ソースコード及び／又はツールチェーン変更のうちの１又はそれ以上を当該ビルドエラーに対する解決案の候補として識別し、
当該ビルドエラーを再現することなく前記ソースコードがコンパイルできるまで、前記ソースコードを前記候補のソースコード及び／又はツールチェーン変更の夫々により順にコンパイルし、
当該ビルドエラーを前記エラーデータベースに記憶し、当該ビルドエラーの修正として、当該ビルドエラーを再現することなく前記ソースコードがコンパイルできる変更を記憶する、方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０１４６
【補正方法】変更
【補正の内容】
【０１４６】
上記の実施形態に加えて、更に以下の付記を開示する。
（付記１）
ソースコードをビルドするコンパイラを備えたツールチェーンを含むランタイム環境における使用のために前記ソースコードをポーティングする方法であって、
前記ソースコードが前記ランタイム環境においてビルドされる間のビルドエラーに関連するソースコードフラグメントを取得し、
前記ソースコードフラグメントのシグニチャを作成し、
前記シグニチャを、前記ランタイム環境における以前のビルドエラーとソースコード及び／又はツールチェーン変更の形をとる前記以前のビルドエラーの修正との履歴から構成されるエラーデータベースに含まれるエンティティと自動的に比較し、
前記比較を使用して、１又はそれ以上の類似した以前のビルドエラーを当該ビルドエラーとし、前記ソースコード及び／又はツールチェーン変更のうちの１又はそれ以上を当該ビルドエラーに対する解決案の候補として識別し、
当該ビルドエラーを再現することなく前記ソースコードがコンパイルできるまで、前記ソースコードを前記候補のソースコード及び／又はツールチェーン変更の夫々により順にコンパイルし、
当該ビルドエラーを前記エラーデータベースに記憶し、当該ビルドエラーの修正として、当該ビルドエラーを再現することなく前記ソースコードがコンパイルできる変更を記憶する、方法。
（付記２）
前記ソースコードフラグメントの前記シグニチャは、前記ソースコードフラグメントを非言語依存表現に変換し、次いで中間表現からシグニチャ、望ましくはハッシュシグニチャを作成することによって、作成される、
付記１に記載の方法。
（付記３）
前記ソースコードフラグメントの前記シグニチャは、当該ビルドエラー前後の複数の範囲レベルの夫々について範囲レベルシグニチャを含む、
付記１又は２に記載の方法。
（付記４）
初期学習フェーズが実行され、ビルドエラー及びそれらの既知の解決法のトレーニングセットが前記データベースにおいて確立されることを可能にする、
付記１乃至３のうちいずれか一項に記載の方法。
（付記５）
解決法の候補は、当該ビルドエラーの現在のランタイム環境における修正の有効性、及び／又は関連性に従って優先順位をつけられる、
付記１乃至４のうちいずれか一項に記載の方法。
（付記６）
前記修正の有効性は、該修正の使用に成功してビルドエラーが解決されるたびにインクリメントされるスコアに基づく、
付記５に記載の方法。
（付記７）
当該ビルドエラーの前記関連性は、前記以前のビルドエラーにおけるシグニチャがどの程度前記ソースコードフラグメントの前記シグニチャに一致するかに基づく、
付記５又は６に記載の方法。
（付記８）
前記エラーデータベースは、異なるランタイム環境におけるビルドエラーと、異なるアプリケーションのソースコードとを含むビルドエラーを記憶する、
付記１乃至７のうちいずれか一項に記載の方法。
（付記９）
前記エラーデータベースにおけるビルドエラーフィールドは、エラーメッセージと、フラグメントシグニチャ、エラー分類、ランタイム環境詳細、及びアプリケーション詳細のうちの１又はそれ以上とを含み、当該ビルドエラーは、前記ビルドエラーデータベースフィールドのいずれか又は全てと比較される、
付記１乃至８のうちいずれか一項に記載の方法。
（付記１０）
前記ソースコードフラグメントが取得される場合にエラーメッセージを取得し、該エラーメッセージを、前記ソースコードフラグメントの前記シグニチャが作成される場合に分類し、該エラーメッセージの分類を、前記シグニチャと前記エラーデータベースに含まれる前記エンティティとの比較の前に、前記エラーデータベースに含まれる前記エンティティと自動的に比較する
付記１乃至９のうちいずれか一項に記載の方法。
（付記１１）
前記エラー分類は、前処理、コンパイルタイム、及びリンクタイムエラーを識別し分けるように、望ましくは、エラーのタイプに関する更なる細分を有して、分割される、
付記９又は１０に記載の方法。
（付記１２）
前記エラー分類は、与えられるエラーメッセージ、ソースコード分析及び何らかのエラーコード又は診断メッセージに基づき割り当てられる、
付記９乃至１１のうちいずれか一項に記載の方法。
（付記１３）
前記ビルドエラーの前記関連性は、前記類似した以前のビルドエラーのデータベースフィールドがどの程度当該ビルドエラーと一致するかに基づく、
付記９乃至１２のうちいずれか一項に記載の方法。
（付記１４）
前記ソースコードと同じアプリケーションからのエラーデータベースに含まれるエンティティ又は以前のビルドエラーは最初に前記シグニチャと比較され、修正が見つけられない場合に、何らかの他のアプリケーションからの以前のビルドエラーのエラーデータベースに含まれるエンティティが前記シグニチャと比較される、
付記１乃至１３のうちいずれか一項に記載の方法。
（付記１５）
ソースコードをビルドするコンパイラ（を備えたツールチェーン）を含む新しいランタイム環境による使用のために前記ソースコードをポーティングする際にエラーを訂正するよう配置される装置であって、
前記ソースコードが前記ランタイム環境においてビルドされる間のビルドエラーに関連するソースコードフラグメントを取得するよう配置される入力部と、
前記ソースコードフラグメントのシグニチャを作成するよう配置されるシグニチャ作成部と、
前記ランタイム環境における以前のビルドエラーとソースコード及び／又はソフトウェア構成変更の形をとる前記以前のビルドエラーの修正との履歴から構成されるエラーデータベースと、
前記シグニチャを前記エラーデータベースに含まれるエンティティと自動的に比較するよう配置される比較部と、
前記比較を使用して、１又はそれ以上の類似した以前のビルドエラーを当該ビルドエラーとし、前記ソースコード及び／又はソフトウェア構成変更のうちの１又はそれ以上を当該ビルドエラーに対する解決案の候補として識別するよう配置される識別部と、
当該ビルドエラーを再現することなく前記ソースコードがコンパイルできるまで、前記識別をされたソースコード及び／又はソフトウェア構成変更の夫々による前記ソースコードのコンパイルを順に可能にするよう配置されるループインプッタ部と、
当該ビルドエラーと、当該ビルドエラーの修正として、当該ビルドエラーを再現することなく前記ソースコードがコンパイルできる変更とを前記エラーデータベースに記憶するよう配置されるデータベース更新部と
を有する装置。
（付記１６）
前記エラーデータベースは、前記ランタイム環境に関する情報を記憶するシステムテーブルと、ビルドされるアプリケーションコードに関する詳細を記憶するアプリケーションテーブルと、コードフラグメント及びそれらのビルドが成功可能であるかどうかのインジケーションを記憶するコードフラグメントテーブルと、前記以前のビルドエラーを記憶するエラーテーブルとを有する、
付記１５に記載の装置。
（付記１７）
ソースコードをビルドするコンパイラを備えたツールチェーンを含むランタイム環境における使用のために前記ソースコードをポーティングする方法であって、
前記ソースコードが前記ランタイム環境においてビルドされる間のビルドエラーに関連するエラーメッセージ及びソースコードフラグメントを取得し、
前記エラーメッセージを分類し、
前記エラーメッセージの分類を、前記ランタイム環境における以前のビルドエラーとソースコード及び／又はツールチェーン変更の形をとる前記以前のビルドエラーの修正との履歴から構成されるエラーデータベースに含まれるエンティティと自動的に比較し、
前記比較を使用して、１又はそれ以上の類似した以前のビルドエラーを当該ビルドエラーとし、前記ソースコード及び／又はツールチェーン変更のうちの１又はそれ以上を当該ビルドエラーに対する解決案の候補として識別し、
当該ビルドエラーを再現することなく前記ソースコードがコンパイルできるまで、前記ソースコードを前記候補のソースコード及び／又はツールチェーン変更の夫々により順にコンパイルし、
当該ビルドエラーを前記エラーデータベースに記憶し、当該ビルドエラーの修正として、当該ビルドエラーを再現することなく前記ソースコードがコンパイルできる変更を記憶する、方法。