(57)【要約】【課題】アプリケーションプログラムインターフェース（ＡＰＩ）など、ソースコードを利用できない外部関数を処理する際に、モデルを提供してその外部関数が適切に呼び出されるかどうかを評価する。【解決手段】外部関数の不適切な呼び出しから結果として生じる可能性のあるエラー、およびその潜在的なエラーにつながる少なくとも１つの条件が識別される。モデルを作成してその潜在的なエラーにつながる条件についてテストする。その条件が見つかると、エラーメッセージの生成がトリガーされる。このモデルは、ソースコードがソースコードアナライザによって分析されるときに、このモデルを適用して外部関数の呼び出しを評価するように、ソースコードアナライザに関連付けられる。潜在的なエラー、ならびに入力／出力パラメータのエラーおよび依存関係のエラーなどのエラーにつながる条件は、外部関数またはＡＰＩのオペレーションについて記述する文書から導き出すことができる。【選択図】図４
2006236336.tif 000002
【特許請求の範囲】
【請求項１】
関数のソースコード実装を利用できない外部関数の呼び出しを分析する方法であって、
（ａ）ソースコードによって前記外部関数の不適切な呼び出しから生じる少なくとも１つの潜在的なエラーを識別するステップと、
（ｂ）前記潜在的なエラーにつながる少なくとも１つの条件を識別するステップと、
（ｃ）前記関数のモデルを作成して前記潜在的なエラーにつながる前記少なくとも１つの条件についてテストするステップであって、前記条件が見つかるとエラーメッセージの生成をトリガーするステップと、
（ｄ）前記ソースコードが前記ソースコードアナライザによって分析されるとき、前記モデルを適用して前記外部関数の呼び出しを評価するように前記モデルをソースコードアナライザに関連付けるステップと
を備えることを特徴とする方法。
【請求項２】
前記外部関数は、アプリケーションプログラムインターフェースを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記外部関数を実装するための要件に基づいて、前記潜在的なエラーにつながる前記少なくとも１つの条件を識別するステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項４】
前記少なくとも１つの条件は、
（ａ）前記アプリケーションプログラムインターフェースにとって許容可能な入力パラメータの正しくない入力タイプ、
（ｂ）前記アプリケーションプログラムインターフェースにとって許容可能な前記入力パラメータの正しくない入力コンテンツ範囲、
（ｃ）前記アプリケーションプログラムインターフェースによって生成可能な出力パラメータについての正しくない出力タイプ、
（ｄ）前記アプリケーションプログラムインターフェースによって生成可能な前記出力パラメータの正しくない出力コンテンツ範囲、
（ｅ）前記外部関数の呼び出しに先立って呼び出されなければならない前提となる関数を呼び出すことの失敗、および
（ｆ）前記外部関数の呼び出しの後に呼び出されなければならない事後の関数を呼び出すことの失敗
のうちの少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記モデルは、前記潜在的なエラーにつながる前記少なくとも１つの条件についてテストするのに使用できる複数のプリミティブを用いて作成されることを特徴とする請求項１に記載の方法。
【請求項６】
前記ソースコードアナライザは、作成された前記モデルを格納するように構成されたモデルリポジトリを含み、これによって前記ソースコードアナライザがソースコードを評価し、前記外部関数への参照を識別すると前記モデルにアクセスできることを特徴とする請求項５に記載の方法。
【請求項７】
請求項１に記載のステップを履行するための機械実行可能命令を格納したことを特徴とするメモリメディア。
【請求項８】
ソースコードアナライザを適合させて関数のソースコード実装が利用できない外部関数を評価する方法であって、
（ａ）前記ソースコードアナライザを適合させて前記外部関数を認識および分析するステップと、
（ｂ）ソースコードによって前記外部関数の不適切な呼び出しから生じる少なくとも１つの潜在的なエラーを識別するステップと、
（ｃ）前記潜在的なエラーにつながる少なくとも１つの条件を識別するステップと、
（ｄ）前記関数のモデルを作成して前記潜在的なエラーにつながる前記少なくとも１つの条件についてテストするステップであって、前記条件が見つかるとエラーメッセージの生成をトリガーするステップと、
（ｅ）前記ソースコードが前記ソースコードアナライザによって分析されるとき、前記モデルを適用して前記外部関数の呼び出しを評価するように前記モデルを前記ソースコードアナライザ内に組み込むステップと、
（ｆ）前記ソースコードを分析するときに前記ソースコードアナライザによって作成されるエラーレポートに前記モデルによってトリガーされた前記エラーメッセージを含めるステップと
を備えることを特徴とする方法。
【請求項９】
前記外部関数は、アプリケーションプログラムインターフェースを含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記外部関数を実装するための要件に基づいて、前記潜在的なエラーにつながる前記少なくとも１つの条件を識別するステップをさらに備えることを特徴とする請求項８に記載の方法。
【請求項１１】
前記少なくとも１つの条件は、
（ａ）前記アプリケーションプログラムインターフェースにとって許容可能な入力パラメータの正しくない入力タイプ、
（ｂ）前記アプリケーションプログラムインターフェースにとって許容可能な前記入力パラメータの正しくない入力コンテンツ範囲、
（ｃ）前記アプリケーションプログラムインターフェースによって生成可能な出力パラメータについての正しくない出力タイプ、
（ｄ）前記アプリケーションプログラムインターフェースによって生成可能な前記出力パラメータの正しくない出力コンテンツ範囲、
（ｅ）前記外部関数の呼び出しに先立って呼び出されなければならない前提となる関数を呼び出すことの失敗、および
（ｆ）前記外部関数の呼び出しの後に呼び出されなければならない事後の関数を呼び出すことの失敗
のうちの少なくとも１つを含むことを特徴とする請求項８に記載の方法。
【請求項１２】
前記モデルは、前記潜在的なエラーにつながる前記少なくとも１つの条件についてテストするのに使用できる複数のプリミティブを用いて作成されることを特徴とする請求項８に記載の方法。
【請求項１３】
前記ソースコードアナライザは、作成された前記モデルを格納するように構成されたモデルリポジトリを含み、これによって前記ソースコードアナライザがソースコードを評価し、前記外部関数への参照を識別すると前記モデルにアクセスできることを特徴とする請求項１２に記載の方法。
【請求項１４】
前記ソースコードアナライザを適合させて選択されたコンピューティング環境と共に使用するために提供されるソフトウェア開発キットに含まれるバイナリライブラリに含まれる複数の外部関数を評価するステップをさらに備えることを特徴とする請求項８に記載の方法。
【請求項１５】
請求項８に記載のステップを履行するための機械実行可能命令を格納したことを特徴とするメモリメディア。
【請求項１６】
関数のソースコード実装が利用できない外部関数の呼び出しを分析するためのシステムであって、
（ａ）少なくとも１つのユーザ入力デバイスと、
（ｂ）ディスプレイと、
（ｃ）前記入力デバイスおよび前記ディスプレイと通信状態にあるプロセッサと、
（ｄ）前記プロセッサと通信状態にあるメモリであって、
（ｉ）ソースコードによって前記外部関数の不適切な呼び出しから生じる少なくとも１つの潜在的なエラーを識別することと、
（ｉｉ）前記潜在的なエラーにつながる少なくとも１つの条件を識別することと、
（ｉｉｉ）前記関数のモデルを作成して前記潜在的なエラーにつながる前記少なくとも１つの条件についてテストすることであって、前記条件が見つかるとエラーメッセージの生成をトリガーすることと、
（ｉｖ）前記ソースコードが前記ソースコードアナライザによって分析されるとき、前記モデルを適用して前記外部関数の呼び出しを評価するように前記モデルをソースコードアナライザに関連付けることと
を含む複数の関数を前記プロセッサに実行させるデータおよび機械命令を格納したメモリと
を備えたことを特徴とするシステム。
【請求項１７】
前記外部関数は、アプリケーションプログラムインターフェースを含むことを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記機械命令は、前記外部関数を実装するための要件に基づいて、前記潜在的なエラーにつながる前記少なくとも１つの条件を前記プロセッサに識別させることを特徴とする請求項１６に記載のシステム。
【請求項１９】
前記少なくとも１つの条件は、
（ａ）前記アプリケーションプログラムインターフェースにとって許容可能な入力パラメータの正しくない入力タイプ、
（ｂ）前記アプリケーションプログラムインターフェースにとって許容可能な前記入力パラメータの正しくない入力コンテンツ範囲、
（ｃ）前記アプリケーションプログラムインターフェースによって生成可能な出力パラメータについての正しくない出力タイプ、
（ｄ）前記アプリケーションプログラムインターフェースによって生成可能な前記出力パラメータの正しくない出力コンテンツ範囲、
（ｅ）前記外部関数の呼び出しに先立って呼び出されなければならない前提となる関数を呼び出すことの失敗、および
（ｆ）前記外部関数の呼び出しの後に呼び出されなければならない事後の関数を呼び出すことの失敗
のうちの少なくとも１つを含むことを特徴とする請求項１６に記載のシステム。
【請求項２０】
前記モデルは、前記潜在的なエラーにつながる前記少なくとも１つの条件についてテストするのに使用できる複数のプリミティブを用いて作成されることを特徴とする請求項１６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にコンピュータソフトウェアの開発に関し、より詳細には、プログラミングエラーを検出するためにコンピュータソースコードの評価を改善するための方法およびシステムに関する。
【背景技術】
【０００２】
過去１０年間にわたって向上の一途をたどっているマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）、およびストレージシステムのコストパフォーマンスは、コンピュータソフトウェアの開発のあり方に影響を与えてきた。かつて、ハードウェアリソースがより高価だった時代には、ソースコードはアセンブリ言語で書かれることが多かった。低水準言語（ｌｏｗ−ｌｅｖｅｌ  ｌａｎｇｕａｇｅ）でコードを書くことは、開発者にとってはより多くの時間を費やすことになったが、結果として、いくらか効率のよいコンパクトなコードになった。しかし、プロセッサ、メモリ、およびストレージのコストパフォーマンスが向上した結果、ソフトウェア開発のコストを最小限に抑えるために、ますます多くのプログラミングが、Ｃ／Ｃ＋＋、Ｖｉｓｕａｌ  Ｂａｓｉｃその他の高水準言語（ｈｉｇｈ−ｌｅｖｅｌ  ｌａｎｇｕａｇｅ）で行われている。
【０００３】
ソフトウェアの作成をより効率的で生産的にし、利用可能な改良されたコンピューティングシステムをさらに活用するソフトウェア開発者向けのよりよいツールが作成されている。例えば、静的ソースコード分析ツールは、ソースコードの起こりうる振る舞いを演繹することによって、ソフトウェア開発者がエラーを識別するのを補助する。いくつかの静的ソースコード分析ツールは、コードをコンパイルして、従来のコンパイラが検出しなかった可能性のある、プログラミング言語のルールの違反につながる構文上の欠陥を識別する。いくつかの静的ソースコード分析ツールは、コンパイラを含まないが、その代わりに外部のコンパイラの出力をインターセプトし、そのコンパイルされたコードを構文解析（ｐａｒｓｅ）し、分析する。静的ソースコード分析ツールが、発生しうる構文上のエラー（ｓｙｎｔａｘ  ｅｒｒｏｒ）についてソースコードを評価すると、コードアナライザによって作成されたソースコードの表現によって、そのコードをシミュレータが意味上の問題について評価できるようになる。そのため、静的ソースコード分析ツールは、コンパイラによって検出されなかった可能性のある構文上のエラー、ならびにコンパイラによって検出されないであろう意味上のエラー（ｓｅｍａｎｔｉｃ  ｅｒｒｏｒ）を検出するのを補助する。
【０００４】
図１Ａは、従来の（従来技術の）静的ソースコードアナライザ１００ａのブロック図を示している。ソフトウェア開発者によって用意されたソースコード１０２ａが、静的ソースコードアナライザ１００ａに入力される。このソースコードは、はじめに入力プロセッサ１０４ａによって構文解析され、この入力プロセッサは、ヘッダブロックおよびコメントを無視し、ソースコードを標準プログラミング命令１０６ａのリストに縮減し、この標準プログラミング命令がシミュレータ１０８ａにサブミットされる。シミュレータ１０８ａは、ソースコードにおける構文上のエラーおよび意味上のエラーを識別する。例えば、誤用されている式（ｅｘｐｒｅｓｓｉｏｎ）、スペルミスのある式、あるいは適切な引数（ａｒｇｕｍｅｎｔ）または区切り文字（ｄｅｌｉｍｉｔｅｒ）を含んでいない式が、構文上のエラーとして識別される。さらに、シミュレータ１０８ａは、リテラル（ｌｉｔｅｒａｌ）や構文上のエラー以外のエラーを識別する。例えば、ソースコードが、適切に初期化されていない可能性のあるメモリにアクセスする場合、シミュレータ１０８ａは、そのエラーを識別する。別の例としては、ある変数が初期化され、一定の境界内にあることをソースコードが要求しているにもかかわらず、その変数が初期化されていないか、またはその変数の値が所定の境界を超えているために無効となる場合、シミュレータ１０８ａは、このエラーも識別する。シミュレータ１０８ａによって識別されたエラーは、エラーレポート１１０ａにおいて提示され、ソフトウェア開発者は、これを使用して、自分のソースコードを改訂および修正することができる。
【０００５】
図１Ｂは、従来技術のソースコードアナライザからの例示のスクリーン１２０を示している。このソースコードアナライザでは、分析のためにサブミットされたソースコード１２２をソースコードウィンドウ１２４で閲覧可能であり、その一方でエラーメッセージ１２６が分析ウィンドウ１２８に提示される。エラーメッセージ１２６は、ソフトウェア開発者がエラーを訂正する際の助けとなるようにソースコード１２２の行１３２との関連１３０を含む。
【０００６】
静的ソースコードアナライザは、ソースコードのコンパイルと干渉する可能性のある問題、またはソースコードが無事にコンパイルされてもソフトウェアを動作中に失敗させる可能性のある問題をソフトウェア開発者が識別するのを補助するという両方の点で、ソフトウェア開発者にとって大いに有用である。静的ソースコードアナライザは、でき上がるソフトウェアが意図したとおりに機能するかを判定するテストを代替するものではない。しかし、静的ソースコードアナライザは、ソースコード１２２の具体的な行１３２との関連を含むエラーメッセージ１２６を開発者に提示することによって、開発者が自分のソースコードにおける潜在的な構文上の問題および意味上の問題に迅速に対処できるようにする。
【０００７】
静的ソースコードアナライザの精度は、提示されたソースコードをインタープリットする能力に依存している。その結果、ソースコード中のいくつかのエラーは見逃される可能性がある。さらに静的ソースコードアナライザが、分析中のソースコードを間違ってインタープリットすると、評価中のソースコードが正しいときにはフォールスポジティブ（ｆａｌｓｅ  ｐｏｓｉｔｉｖｅ）が生じる可能性がある。残念ながら、フォールスポジティブの発生はノイズにつながり、ソースコードの実際のエラーを示すエラーメッセージを分かりにくくする。その結果、分析中のソフトウェアコードの実際のエラーが、ソフトウェア開発者によって見逃されることがある。
【０００８】
ソフトウェア開発者にとって非常に有用な他のツールは、ソフトウェア開発者キットである。ソフトウェア開発者キットは通常、以前に作成されたソフトウェアツールへのアクセスを可能にすることによってソフトウェアの開発をより容易にするために、Ｍｉｃｒｏｓｏｆｔ  ＷＩＮＤＯＷＳ（登録商標）などの特定のオペレーティングシステム、あるいはＭｉｃｒｏｓｏｆｔ  ＸＢＯＸ（登録商標）などのコンピューティングプラットフォームまたはゲームプラットフォーム向けに作成される。これらのソフトウェア開発キットは、開発者によって自分のコードに含められる可能性の高い共通の機能を実行する事前に書かれたルーチンのソースコードを含むことがある。そのようなソフトウェアルーチンに対する便利なアクセスを提供することによって、開発者は、既に作成されている共通のルーチンを再び書くことに時間を浪費する必要はない。
【０００９】
ソフトウェア開発キットは、開発者がソフトウェアを作成している動作環境でアクセスできるアプリケーションプログラムインターフェースまたはアプリケーションプログラミングインターフェース（ＡＰＩ）を含むこともある。ＡＰＩを使用して、グラフィックスを生成するサービス、音声を生成するサービス、および任意の数のその他の機能を呼び出すことができる。さらに、実装は異なるが機能的に類似したサービスを呼び出すＡＰＩを使用して、そのソースコードがコンパイルできる様々なプラットフォーム間でのソースコードソフトウェアポータビリティを提供することができる。おそらく最も顕著なこととして、ＡＰＩは、高水準言語のソースコードと、動作環境のハードウェアデバイスとより直接的に動作するより低水準のユーティリティとのインターフェースを提供するのに有用である。
【００１０】
ＡＰＩは、別個に、またはソフトウェア開発キットの一部として、バイナリライブラリのコレクションとして配布されることが多い。通常、ＡＰＩを作成するために使用されるソースコードは、配布またはその他の形で開発者に利用可能にはなされていない。ソースコードは、動作環境の開発者の様々な独自の懸念を保護するために利用可能になされていない。しかし、たとえＡＰＩのソースコードの実装が利用可能になされていなくても、ＡＰＩの動作、ＡＰＩを呼び出すための適切な構文、ＡＰＩに渡されるべき引数、およびＡＰＩによって返される値の特徴を説明する文書またはその他の情報が、ソフトウェア開発キットと共に利用可能になされることがある。
【００１１】
残念ながら、１つまたは複数のＡＰＩを呼び出すソースコードを静的ソースコードアナライザにサブミットすることにより、結果としていくつかのエラーが生じることがある。前述のように、ソースコードアナライザは、ソースコードを理解するように構成されている限度でしか正確ではない。このため、静的ソースコードアナライザは、ＡＰＩ署名を提示されるのみで、ＡＰＩのソースコード実装にアクセスできないため、ＡＰＩ署名を分析できないことがある。
【００１２】
図１Ｃの従来技術の例に示されているように、ソースコード１０２ｃを分析するとき、静的ソースコードアナライザ１００ｃの入力プロセッサ１０４ｃは、ＡＰＩ署名１５２を標準プログラミング命令１０６ｃとは区別して認識するであろう。ＡＰＩ署名は非標準の式に表すので、ＡＰＩ署名１５２は、エラーレポート１１０ｃで構文上のエラーとみなされることがある。あるいは、Ｃ＋＋では、例えば、「エクスターン（ｅｘｔｅｒｎ）」指定をＡＰＩ署名１５２に付加することができ、これによって、シミュレータ１０８ｃがＡＰＩ署名１５２の意味（ｓｅｍａｎｔｉｃｓ）を評価しようと試みることを防止することになる。ＡＰＩのソースコード実装なしで、静的ソースコードアナライザは、ＡＰＩ署名に従って適切な引数がＡＰＩに渡されるかどうかを判定することによって、ＡＰＩコールの構文を評価できることがある。しかし、ソースコードなしでは、静的ソースコードアナライザは、ＡＰＩ署名１５２、それらの動作、またはＡＰＩ署名１５２を呼び出すソースコード上の影響を意味的に評価することはできない。「エクスターン」指定に出くわすと、静的ソースコードアナライザは、後に続く式を意味的に評価しようと試みない。
【００１３】
ＡＰＩのソースコード実装へのアクセスなしで、静的ソースコードアナライザは、例えばＡＰＩに渡された引数に関してそのＡＰＩがどのような影響を有する可能性があるかを判定することはできない。その結果、静的ソースコードアナライザ１０８ｃは、変数に伴う問題が実際にＡＰＩに関連しているときに、その問題に関するエラーメッセージを生成することがある。結果として、ＡＰＩ署名をソースコード内に含めることは、多くのフォールスポジティブのエラーメッセージまたはノイズがソースコードアナライザによって生成されることになる可能性があり、これによって残念ながら、実際の真のエラーメッセージから注意がそらされる可能性がある。さらに、ソースコードアナライザは、ＡＰＩコールまたはその影響を評価できないことがあるため、そのようなＡＰＩコールから結果として生じるエラーを検出できないであろう。ＡＰＩは、それに渡された引数に関するあるオペレーションを実行し、それがソースコードの後のどこかのポイントで正しくないオペレーションになることがある。したがって、ソースコードアナライザは、ＡＰＩのオペレーションを評価できない場合、ソースコード中の関連するエラーを検出できないことがある。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
そのため、ＡＰＩのソースコード実装へのアクセスがなくてもＡＰＩコールを評価することができる方法およびシステムを提供することが望まれるであろう。
【課題を解決するための手段】
【００１５】
したがって、本発明の１つの利点は、外部関数コールのソースコード実装が利用可能でないときでも、ＡＰＩコールなどの外部関数コールを評価するための方法およびシステムを提供することである。典型的な既知のソースコードアナライザは、外部関数コールを無視し、その結果、外部関数の呼び出しにおけるエラーを見逃すか、または検出されたエラーが実際は外部関数コールによって解決されたときにフォールスポジティブをフラグすることがある。外部関数のソースコードは利用可能でないので、関数のソースコード自体をソースコードに組み込み、分析することはできない。しかし、関数のソースコードが利用可能になされていないので、外部関数のプロバイダは、外部関数のオペレーションについて記述する文書やその他の情報を提供することがある。この文書によって、ソフトウェア開発者は、どのようなパラメータが外部関数に渡されるか、どのようなパラメータが外部関数によって出力されるか、ＡＰＩが依存する前提となる関数は何であるか、ならびにその他の重要な情報を理解することができる。この記述情報から、ＡＰＩが適切に呼び出されることを保証するモデルを開発することができる。本発明の一実施形態に従って静的ソースコードアナライザと共に含められるプリミティブのセットは、静的ソースコードアナライザがＡＰＩコールの振る舞いおよび影響を評価できるようにＡＰＩの関数をモデル化する方法をユーザに提供する。
【００１６】
そのため、本発明の一態様は、関数のソースコード実装が利用可能でない外部関数の呼び出しを分析する方法を対象としている。ソースコードによって外部関数の不適切な呼び出しから生じる少なくとも１つの潜在的なエラーが識別され、その潜在的なエラーにつながるであろう少なくとも１つの条件が識別される。潜在的なエラーにつながる少なくとも１つの条件についてテストするのに有用で、その条件が見つかるとエラーメッセージの生成を開始することができる外部関数のモデルが採用される。このモデルは、ソースコードがソースコードアナライザによって分析されるときに、このモデルを適用して外部関数の呼び出しまたはオペレーションを評価するように、ソースコードアナライザに関連付けられる。
【００１７】
外部関数は、ＡＰＩを含むことができる。潜在的なエラーにつながるであろう少なくとも１つの条件を識別することは、外部関数のオペレーションについて記述する情報に基づいてなされる。この条件は、アプリケーションプログラムインターフェースにとって許容可能な入力パラメータの正しくない入力タイプ、またはＡＰＩにとって許容可能な入力パラメータの正しくない入力コンテンツ範囲を含むことができる。同様に、この条件は、ＡＰＩによって生成可能な出力パラメータの正しくない出力、またはＡＰＩによって生成可能な出力パラメータの正しくない出力コンテンツ範囲を含むことができる。この条件は、外部関数の呼び出しに先立って呼び出されなければならない前提となる関数（ｐｒｅ−ｒｅｑｕｉｓｉｔｅ  ｆｕｎｃｔｉｏｎ）を呼び出すことの失敗、または外部関数の呼び出しの後に呼び出されなければならない事後の関数（ｐｏｓｔ−ｒｅｑｕｉｓｉｔｅ  ｆｕｎｃｔｉｏｎ）を呼び出すことの失敗を含むこともできる。
【００１８】
このモデルは、潜在的なエラーにつながる少なくとも１つの条件についてテストに使用できる複数のプリミティブを用いて作成することができる。ソースコードアナライザは、作成されたモデルを格納するように構成されたモデルリポジトリを含み、これによってソースコードアナライザは、ソースコードを評価し、外部関数への参照を識別する際に、このモデルにアクセスすることができる。
【００１９】
本発明の前述の態様および付随する利点の多くは、以降の詳細な説明を添付の図面と併せて参照することによってよりよく理解するにつれて、より容易にその真価を認識できるであろう。
【発明を実施するための最良の形態】
【００２０】
（本発明を実装するための例示のコンピューティングシステム）
図２を参照すると、本発明の実施形態と共に使用するのに適した例示の従来のコンピューティングシステムが示されている。このシステムは、ＰＣ２２０ａの形態の汎用コンピューティングデバイスを含み、これは、処理装置２２１、システムメモリ２２２、およびシステムバス２２３を備えている。システムバスは、システムメモリを含む様々なシステムコンポーネントを処理装置２２１に結合し、メモリバスまたはメモリコントローラ、ペリフェラルバス、様々なバスアーキテクチャのいずれかを使用するローカルバスを含むいくつかのタイプのバス構造のいずれとすることもできる。システムメモリは、読み取り専用メモリ（ＲＯＭ）２２４およびランダムアクセスメモリ（ＲＡＭ）２２５を含む。基本入出力システム２２６（ＢＩＯＳ）は、起動中などにＰＣ２２０内の要素間における情報伝達を補助する基本ルーチンを含み、ＲＯＭ２２４に格納されている。ＰＣ２２０は、ハードディスク（図示せず）との間で読み取りおよび書き込みを行うためのハードディスクドライブ２２７、リムーバブルな磁気ディスク２２９との間で読み取りや書き込みを行うための磁気ディスクドライブ２２８、およびコンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）やその他の光メディアなどのリムーバブルな光ディスク２３１との間で読み取りや書き込みを行うための光ディスクドライブ２３０をさらに含む。ハードディスクドライブ２２７、磁気ディスクドライブ２２８、および光ディスクドライブ２３０は、それぞれハードディスクドライブインターフェース２３２、磁気ディスクドライブインターフェース２３３、および光ディスクドライブインターフェース２３４によってシステムバス２２３に接続される。これらのドライブおよびその関連するコンピュータ可読メディアは、ＰＣ２２０ａのためのコンピュータ可読機械命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性のストレージを提供する。本明細書に記載された例示の環境では、ハードディスク、リムーバブルな磁気ディスク２２９、およびリムーバブルな光ディスク２３１を採用しているが、磁気カセット、フラッシュメモリカード、デジタルビデオディスク（ＤＶＤ）、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭなど、コンピュータによってアクセス可能なデータおよび機械命令を格納できるその他のタイプのコンピュータ可読メディアも、この例示の動作環境において使用できることが当業者によって理解されるであろう。
【００２１】
オペレーティングシステム２３５、１つまたは複数のアプリケーションプログラム２３６、その他のプログラムモジュール２３７、およびプログラムデータ２３８を含むいくつかのプログラムモジュールをハードディスク、磁気ディスク２２９、光ディスク２３１、ＲＯＭ２２４、またはＲＡＭ２２５上に格納することができる。ユーザは、Ｉ／Ｏデバイスインターフェース２４６を介してシステムバス２２３と通信するキーボード２４０およびポインティングデバイス２４２などの入力デバイスを介して、ＰＣ２２０にコマンドおよび情報を入力し、制御入力を提供することができる。ポインティングデバイス２４２は、マウス、スタイラス（ｓｔｙｌｕｓ）、ワイヤレスリモコン、またはその他のポインタを含むことができるが、本発明に関して、ユーザは入力および制御のためのインタラクティブディスプレイを採用できるので、このような従来のポインティングデバイスを省略することができる。以降で使用するように「マウス」という用語は、スクリーン上のカーソルの位置を制御するのに有用な事実上すべてのポインティングデバイスを包含することを意図している。ヘッドセット、スピーカ、およびマイクロフォンを含む１つまたは複数のオーディオ入力／出力デバイス２４３も、Ｉ／Ｏデバイスインターフェース２４６を介してパーソナルコンピュータ２２０と連動する。さらなる入力デバイス（図示せず）には、ジョイスティック、ハプティック（ｈａｐｔｉｃ）ジョイスティック、操縦桿、フットペダル、ゲームパッド、衛星アンテナ、スキャナなどが含まれ得る。これらおよびその他の入力／出力（Ｉ／Ｏ）デバイスは、システムバス２２３に結合されているＩ／Ｏインターフェース２４６を介して処理装置２２１に接続されることが多い。Ｉ／Ｏインターフェースという用語は、シリアルポート、パラレルポート、ゲームポート、キーボードポート、および／またはユニバーサルシリアルバス（ＵＳＢ）のために特に使用されるそれぞれのインターフェースを包含することを意図している。モニタ２４７は、ビデオアダプタ２４８などの適切なインターフェースを介してシステムバス２２３に接続される。ＰＣは、（サウンドカードまたはその他のオーディオインターフェース（図示せず）を介した）スピーカおよびプリンタなどのその他の周辺出力デバイス（図示せず）に結合されることが多いことが理解されるであろう。
【００２２】
ＰＣ２２０はまた、リモートコンピュータ２４９などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することもできる。リモートコンピュータ２４９は、別のＰＣ、（通常は一般にほとんどＰＣ２２０ａのように構成された）サーバ、ルータ、ネットワークＰＣ、ピアデバイス、あるいは人工衛星またはその他の共通ネットワークノードとすることができ、図２には外部メモリストレージデバイス２５０しか示されていないが、通常はＰＣ２２０ａに関連して上述した要素の多くまたはすべてを含む。図２に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）２５１およびワイドエリアネットワーク（ＷＡＮ）２５２を含む。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいてよく見受けられる。
【００２３】
ＬＡＮネットワーキング環境において使用する場合、ＰＣ２２０は、ネットワークインターフェースまたはアダプタ２５３を介してＬＡＮ２５１に接続される。ＷＡＮネットワーキング環境において使用する場合、ＰＣ２２０は通常、モデム２５４か、またはケーブルモデム、ＤＳＬ（Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ）インターフェース、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅ  Ｄｉｇｉｔａｌ  Ｎｅｔｗｏｒｋ）インターフェースなど、インターネット等のＷＡＮ２５２を介して通信を確立するためのその他の手段を含む。モデム２５４は、内蔵または外付けとすることができ、システムバス２２３に接続されるか、またはＩ／Ｏデバイスインターフェース２４６経由で、すなわちシリアルポートを介してバスに結合される。ネットワーク化された環境では、ＰＣ２２０によって使用されるプログラムモジュール、またはその一部をリモートメモリストレージデバイスに格納することができる。図示したネットワーク接続は例示的なものであり、無線通信および広帯域ネットワークリンクなど、コンピュータ間に通信リンクを確立するその他の手段を使用できることが理解されるであろう。
【００２４】
（ＡＰＩを評価するように適合されたソースコードアナライザ）
図３は、図１Ａおよび１Ｃに関連して前述した従来の静的ソースコードアナライザのいくつかの属性を含む静的ソースコードアナライザ３００のブロック図を示している。ソースコード３０２がソフトウェア開発者によって用意され、潜在的なエラーの検出のために静的ソースコードアナライザ３００にサブミットされる。このソースコードは、入力プロセッサ３０４によって構文解析される。入力プロセッサは、コメント、ヘッダブロック、「エクスターン」または類似の構文をプレフィックスされた行などを無視し、これによって、シミュレータ３０８によって分析される標準プログラミング命令３０６を識別する。さらに、１つまたは複数の外部関数コールまたはＡＰＩ署名３５２が入力プロセッサ３０４によって認識できる。以降の説明では、呼び出される外部関数はＡＰＩとして説明される。それにもかかわらず、本発明の実施形態は、ソースコードが静的ソースコードアナライザ３００に利用可能でなく他の外部関数コールの不適切な呼び出しまたはオペレーションの結果として生じる可能性のあるエラーを評価するのに有用である。
【００２５】
前述のように、従来、指定「エクスターン」または類似の識別子をＡＰＩ署名の宣言に付加することは、ＡＰＩを表す式が、ソースコード実装が利用可能でない外部ルーチンを呼び出すことを示している。当技術分野で理解されるように、「エクスターン」指定は、外部ルーチンの任意のその後の呼び出しを解決することを試みないようにコンパイラに伝達される。リンカーは、呼び出された関数のオブジェクトコードを見つけ出し、外部関数のコード実装をコンパイル後にバイナリレベルで解決する役割を担うことになる。さらに、「エクスターン」指定は、指定された外部関数を意味的に分析することを試みないように従来の静的ソースコードアナライザに伝達される。それにもかかわらず、静的ソースコードアナライザは、その後の外部関数コールの構文を評価して、その外部関数の呼び出しが指定された関数の構文に一致することを保証することができる。
【００２６】
本発明の実施形態によれば、識別された潜在的なＡＰＩ署名３５２は、ＡＰＩシミュレータ３６０にサブミットされる。ＡＰＩシミュレータ３６０は、構文が正しいかどうか、適切な引数がＡＰＩに渡されているかどうか、渡された引数は適切なタイプかどうかを判定するために潜在的なＡＰＩ署名３５２を評価し、またコーディングエラーの存在についてＡＰＩ署名３５２をその他の形で評価する。ＡＰＩ署名３５２が正しいフォームかどうかという判定は、ＡＰＩシミュレータ３６０によってシミュレータ３０８へ伝達される。ＡＰＩシミュレータ３６０によって提供された情報を使用して、シミュレータ３０８は、エラーを含むＡＰＩ署名３５２のエラーレポート３１０中のエラーメッセージを生成する。逆に、ＡＰＩ署名３５２になじみがないためにシミュレータ３０８によってエラーとしてフラグが立てられたかもしれないフォールスポジティブは、エラーレポート３１０ではエラーとして報告されない。
【００２７】
ソフトウェア開発者は、ＡＰＩのソースコード実装が利用可能な場合、シミュレータ３０８が評価できるようにそのＡＰＩのソースコード実装をソースコード３０２の残りと共に自分のソースコード３０２に組み込むことができることが理解されるであろう。しかし前述のように、一般にＡＰＩは、そのＡＰＩがソースコード３０２からコンパイルされた他のオブジェクトコードモジュールとリンクできるようにするバイナリライブラリにおけるそのオブジェクトコードの形態でのみ提供される。有益なことに、本発明の実施形態では、ＡＰＩのプロバイダがＡＰＩのソースコード実装を提供する必要はない。
【００２８】
代わりに、ソースコード３０２と共に使用するように企図され、予期され、または希望される各ＡＰＩ署名について、ＡＰＩシミュレータ３６０は、各ＡＰＩ署名の評価のためのモデルを含む。例えばモデルは、最もコールされる可能性が高いものとして識別されたＡＰＩのグループのために開発することができる。その結果、フォールスポジティブのためにエラーレポート３１０にその他の形で含まれるであろう大半のノイズは、コールされる可能性のあるあらゆるＡＰＩのモデルを含む必要なく、除去することができる。
【００２９】
ＡＰＩシミュレータ３６０は、ソフトウェア開発者に利用可能になされたＳＤＫおよび／またはＡＰＩ文書３８０においてＡＰＩ開発者によって提供されることが好ましい情報から導き出されるモデルを含む。一般に、ＳＤＫ／ＡＰＩ文書３８０は、そのＡＰＩの機能について記述し、そのＡＰＩに提供されるべき引数、そのＡＰＩによってどのような形態の値が要求されるかまたは使用可能か、およびそのＡＰＩのその他の機能的な特徴を示す。ＳＤＫ／ＡＰＩ文書３８０は、ＡＰＩプリミティブ３７０を用いてＡＰＩをモデル化するために使用される。ＡＰＩプリミティブ３７０は、ＡＰＩの関数をモデル化するためにユーザによって採用できるシミュレータに関連付けられたモデリングライブラリにパッケージ化されたルーチンのセットを含み、その結果、ＡＰＩシミュレータ３６０は、ソースコードによって呼び出されるＡＰＩの影響を評価することができる。ＡＰＩプリミティブ３７０の使用については、以降でさらに説明する。
【００３０】
したがって、ＡＰＩプリミティブ３７０を使用して、ＳＤＫ／ＡＰＩ文書３８０を検討すれば、ＡＰＩのソースコードにアクセスしなくても、静的ソースコードアナライザ３００にサブミットされるソースコード３０２に含められる可能性のあるＡＰＩ署名３５２の呼び出しおよび／またはオペレーションを評価するためにいくつかのルールを導き出すことができる。これらのルールは、ＡＰＩシミュレータ３６０に含められ、識別される潜在的なＡＰＩ署名３５２に適用することができる。そして、これらの識別されたＡＰＩ署名を評価して、ソースコード３０２のＡＰＩ署名が有効であるかどうかを評価するために、適切な構文を使用しているか、適切な引数をそのＡＰＩに渡しているか、またその他の点でＡＰＩのルールに忠実であるかが判定される。ソースコードで識別されるＡＰＩ署名３５２が正しく実装されているかどうかを判定するためにＡＰＩシミュレータ３６０が適用される場合、エラーレポート３１０でエラーメッセージは報告されないであろう。その一方で、ソースコード３０２のＡＰＩを呼び出す際に誤りが生じると、ＡＰＩシミュレータ３６０は、このエラーメッセージをシミュレータ３０８に伝達する。したがって、シミュレータ３０８は、ソースコード３０２で識別されたＡＰＩ署名に関する適切なエラーメッセージをエラーレポート３１０に含むことができる。
【００３１】
好ましくは、ＡＰＩシミュレータ３６０は、ＡＰＩの表示の単独の構文および署名構造を評価するだけでなく、ソースコード３０２に含まれたＡＰＩ署名が、シミュレータ３０８によって検出されたソースコード３０２中の他の潜在的なエラーを解決するかどうかをシミュレータ３０８に伝達するようにも構成される。簡単な例として、ＡＰＩは、そのＡＰＩに渡される引数を評価し、一定の限度を超えるその値を切り捨てまたは四捨五入して、許容可能な値にすることができる。したがって、ソースコード３０２に基づいて、特定の値が範囲を超えていることをシミュレータ３０８が検出すると、シミュレータ３０８は、ＡＰＩがその潜在的なエラーを解決するかどうかを判定するためにＡＰＩシミュレータ３６０に問い合わせることができる。解決する場合は、エラーレポート３１０でエラーメッセージは報告されず、フォールスポジティブのエラーメッセージの発生をさらに低減する。
【００３２】
さらに、ＡＰＩシミュレータ内に含まれるＡＰＩモデルは、依存関係のルールを含むことができる。例えば、ＡＰＩがコールされる前に、そのＡＰＩに渡される引数が初期化されなければならないか、あるいはＡＰＩが依存する別のＡＰＩまたはその他の何らかの関数が呼び出されなければならないことが考えられる。ＡＰＩシミュレータ３６０は、この依存関係のルールを含むことができ、その結果、ＡＰＩが呼び出される前に依存している関数が呼び出されない場合、静的ソースコードアナライザ３００によってエラーが生成されることになる。同様にＡＰＩが、コールされた後に別の関数またはＡＰＩを呼び出す必要がある場合、ＡＰＩシミュレータ３６０は、その関数またはＡＰＩが要求に応じてコールされなければエラーを生成するというルールを含むこともできる。
【００３３】
前述のように、多くのＡＰＩはバイナリライブラリで提供され、ＡＰＩを実装するために使用されるソースコードは、それらを使用することになるソフトウェア開発者に利用可能になされない。本発明のモデルの実施形態は、ＡＰＩまたはＳＤＫと共に提供される文書に基づいて予期されるＡＰＩを識別して、静的ソースコードアナライザ３００がＡＰＩコールを実質的に評価できるようにする。これについては、以降でさらに説明する。
【００３４】
静的ソースコードアナライザ３００は、入力プロセッサ３０４を、標準的なプログラミング命令とＡＰＩ署名３５２を独立に処理させるものとして示しているが、シミュレータ３０８およびＡＰＩシミュレータ３６０は、ＡＰＩが適切に呼び出されるかどうか、またＡＰＩがソースコードと共に適切に機能するかどうかを評価するために協調して動作することが好ましいということが理解されるであろう。
【００３５】
（従来の静的ソースコードアナライザの例示的なＡＰＩの取り扱い）
例示の目的で、２つの引数を受け取り、成功／失敗の値を返す例示的なＡＰＩを提示する。このＡＰＩがコールされる前に、第２のパラメータによって指し示されたメモリブロックは、初期化されていない。このＡＰＩは、第２のパラメータによって指し示されたメモリブロック上でいくつかのオペレーションを実行する。しかし、第１のパラメータがある条件を満たすことができない場合、この関数は、第２のパラメータによって指し示されたメモリブロック上で実行されないことになり、実際にはこのメモリは初期化すらされないことになる。したがって、メモリブロックを初期化するのに失敗することが問題である場合、この問題は、ＡＰＩの影響を評価するように動作できる従来の静的ソースコードアナライザによっては検出されないことになる。
【００３６】
より具体的には、この例示のＡＰＩは、下記のＡＰＩ署名およびソースコード実装を使用する。
【００３７】
#define SOME_VALUE           10
bool SomeFunctionAPI(int a, int* b)
{
if(a>0){
*b=SOME_VALUE*a;
// 開発者に開示されていないさらなるコード
．
．
．
// 開発者に開示されていないさらなるコード
return true;
}
return false;
}
【００３８】
「さらなるコード」によっていかなるアクションが実行されようとも、第１のパラメータａがゼロより大きい場合は、ｂが指し示しているメモリブロックが初期化され、作用されるだけである。
【００３９】
さらに、このＡＰＩは、ユーザが静的ソースコード分析のために提示したいと希望するソースコードによって参照されると想定する。
【００４０】
【表１】
2006236336.tif 000003
【００４１】
静的ソースコードアナライザは、SomeFunctionAPIのソースコード実装にはアクセスできない。したがって、従来の静的ソースコードアナライザは、SomeFunctionAPIを呼び出すために使用される構文を分析することはできるが、ソースコード実装にアクセスすることなく、ＡＰＩコールの意味を評価しないであろう。
【００４２】
潜在的な問題が、ＡＰＩコールに続くソースコードの行、ｙ＝１／ｘにおいて発生する。ＡＰＩのソースコード実装へのアクセスなしに従来の静的ソースコードアナライザは、ｘのどんな値がＡＰＩによって返される可能性があるかを判断することができない。ＡＰＩのソースコード実装を調べる際、ｘは、ｚがゼロより大きい場合は初期化されるが、ｚがゼロ以下の値を有する場合は初期化されないことになる。変数ｘは、ＡＰＩを呼び出すソースコードによって、その他の形では初期化されない。したがって、ｘが初期化されない場合、式ｙ＝１／ｘは、初期化されていない変数による除算となるであろう。その一方で、ｚがゼロ以上である場合、ｘは初期化されて、ゼロ以外の値に設定され、したがって式ｙ＝１／ｘによって、定義された許容可能な結果が生じることになる。さらに、ｚが初期化されなかった場合でさえ、ｘの値に関してＡＰＩの結果を予測することは、ソースコード実装にアクセスできても可能ではない。
【００４３】
いくつかの従来のシミュレータは、ｘについての想定を行うことができる。仮定として、例えば、静的ソースコードアナライザは、ｘが初期化されていると想定することができる。その一方で、静的ソースコードアナライザは、ＡＰＩを呼び出すソースコードによってｘが初期化されていない場合に、ｘがそのＡＰＩによって初期化されることはないと想定するように構成することもできる。同様の仮定として、静的ソースコードアナライザは、ＡＰＩによって返されるｘの値がゼロであるか、またはゼロに等しくないと想定することができる。いずれの場合も、従来の静的ソースコードアナライザは、ｘのどんな値がＡＰＩによって返される可能性があるかを判断できないため、静的ソースコードアナライザは、ｘの値を推測することしかできない。
【００４４】
その結果、従来の静的ソースコードアナライザによってｘの値を判定することができないため、ｙ＝１／ｘの式は問題を提示する。従来の静的ソースコードアナライザによってどんな想定が行われるかに応じて、静的ソースコードアナライザは、エラーを検出できなかったり、誤ったエラーメッセージを生成したり、またはまったくの偶発によって適切な応答を行ったりすることがあり、これについては、以降でさらに説明する。
【００４５】
（本発明の実施形態に従ってモデル化された例示的なＡＰＩ）
ＡＰＩの開発者がＡＰＩのソースコード実装を開示しなくても、本発明の実施形態によれば、静的ソースコードアナライザが、ソースコードの潜在的なエラーを正しく識別するように適合される。
【００４６】
図４は、本発明の一実施形態に従ってＡＰＩをモデル化するための論理的なステップを示す流れ図４００を示している。ＡＰＩのモデル化は、ステップ４０２において開始する。ステップ４０４において、ＡＰＩの機能についてのＡＰＩ文書やその他の情報が検討される。ＡＰＩ情報のこの検討に基づいて、ステップ４０６において、ＡＰＩについての適切な構文が識別される。ステップ４０８において、ＡＰＩについての依存関係のルールが識別される。例えば、依存関係のルールは、ＡＰＩに渡されるポインタによって示されるある引数やメモリが初期化されなければならないかどうかや、関数がＡＰＩの後に呼び出されなければならないかどうかなどを指定することができる。ステップ４１０において、ＡＰＩの機能および／または依存関係をモデル化するために、状態オブジェクトが作成される。ＡＰＩモデル化は、ステップ４１２において終了する。
【００４７】
静的ソースコードアナライザは通常、状態オブジェクトを使用して、プログラムの要素および変数の状態を追跡する。したがって、例えば、ＡＰＩを呼び出すルーチンの先の例では、ソースコード実装が既知の関数が呼び出され、ｘの値に影響を与える場合、ｘの値を追跡して、ｙ＝１／ｘというステートメント中のｘによる除算によって有効な結果が生じるかどうかを判定するために、状態オブジェクトを使用することができる。ソースコードの既知の構文およびルールを認識し、例えば符号なしの整数などのプリミティブが、符号なしの整数であるプリミティブと整合する仕方で使用されているかどうかを判定するために、状態マシンを使用することができる。
【００４８】
本発明の実施形態によれば、ユーザは、ＡＰＩについて記述する文書を調べることができ、ＡＰＩプリミティブ３７０（図３）を使用して、静的ソースコードアナライザがＡＰＩの関数を評価するためにアクセスおよび採用できるモデルを作成することができる。ＡＰＩプリミティブ３７０は、複数の引数を指定できる署名を含み、これらの引数を評価するためにこれらの署名を使用して、ＡＰＩが適切に呼び出されるか、ＡＰＩによって有効な結果が生じるかどうかを判定するためにそれらが一定の条件を満たしているかどうかや類似の判定を行うことができる。
【００４９】
例示のＡＰＩを考察して、ＡＰＩ文書が下記の情報を提供すると想定する。
構文：
bool SomeFunctionAPI(int A, int* pB)
パラメータ：
Ａは［ｉｎ］パラメータであり、符号付き整数であり、ＩＮＴ＿ＭＩＮとＩＮＴ＿ＭＡＸの間の値に初期化されなければならない。ｐＢは［ｏｕｔ］パラメータであり、符号付き整数へのポインタであり、ＮＵＬＬとすることはできない。
戻り値：
メソッドが成功した場合、戻り値は真であり、そうでなければ、戻り値は偽である。
機能：
パラメータｐＢによって指し示されているメモリブロックをパラメータＡの値に基づいて初期化する。
依存関係：
なし
制限：
−  パラメータＡが初期化されない場合、メソッドの振る舞いは未定義である。
−  パラメータＡが値＞０に初期化され、パラメータｐＢによって指し示されるメモリブロックがゼロ以外の値に初期化される場合、メソッドコールは成功し、真を返す。
−  パラメータＡが０以下の値に初期化され、パラメータｐＢによって指し示されるメモリブロックがアクセスされず、またそれまでに初期化されていないならば初期化されないままとなる場合、メソッドは失敗し、偽を返す。
【００５０】
ＡＰＩの機能、およびＡＰＩの使用に関する制限の記述によって、ソース実装へのアクセスなしでも、ＡＰＩのオペレーションを、本発明の実施形態による静的ソースコードアナライザによってモデル化およびシミュレートすることができる。
【００５１】
図３に関連して前述したように、本発明の一実施形態では、ＡＰＩプリミティブはモデリングライブラリ中の静的ソースコードシミュレータと共に提供され、これにによって、静的ソースコードシミュレータがＡＰＩの振る舞いをモデル化することができる。ＡＰＩプリミティブは、メモリの初期化、バッファ、ポインタ、メモリの割り当てを処理する関数、およびＡＰＩによって実行できるその他の関数に関連する。ＡＰＩプリミティブは、ＡＰＩがコールされるときに一定の条件が保持されなければならないこと、およびＡＰＩに対するコールが返されるときに特定の結果が予期されるかまたは当てはまることを指定するために使用することができる。
【００５２】
前述のＡＰＩ文書を使用すると、SomeFunctionAPIというＡＰＩは、プリミティブの署名および機能を指定したいくつかの例示のＡＰＩプリミティブを使用してモデル化することができる。例えば、ソースコード実装へのアクセスがなくてもＡＰＩまたはＳＤＫの文書からそのＡＰＩについて分かることに基づいてＡＰＩの関数をモデル化するために使用できる４つのＡＰＩプリミティブについての構文および機能の記述を提供する。
【００５３】
CheckIntegerIsInitialized(int x)−整数パラメータｘが初期化されているかどうか、およびＩＮＴ＿ＭＩＮとＩＮＴ＿ＭＡＸの境界内にあるかどうかの両方を検証するプリミティブ署名。整数パラメータｘが、指定された条件を満たさない場合、シミュレータは、初期化されていない変数の警告を生成する。
【００５４】
CheckIntegerBoundsGreaterEqual(int x, int lower_bound, int upper_bound)−整数パラメータｘの値が、整数パラメータｌｏｗｅｒ＿ｂｏｕｎｄの値以上であり、整数パラメータｕｐｐｅｒ＿ｂｏｕｎｄの値以下であることを検証するプリミティブ署名。パラメータｘが、指定された条件を満たさない場合、シミュレータは、境界違反の警告を生成する。
【００５５】
CheckPointerIsValid(int* p)−整数の変数へのポインタであるパラメータｐが有効なメモリを指し示していることを検証し、それによって、有効なメモリがデータの格納に利用可能であることを検証するプリミティブ署名。整数ポインタが、有効なメモリを指し示していない場合、シミュレータは、ＮＵＬＬポインタ参照解除（ｄｅｒｅｆｅｒｅｎｃｅ）の警告を生成する。
【００５６】
ReturnIntegerValueGreaterThan(int* p, int lower_bound)−整数の変数へのポインタであるパラメータｐが、パラメータｌｏｗｅｒ＿ｂｏｕｎｄの値より大きい値に初期化されることをシミュレータに示すプリミティブ署名。したがってシミュレータが、ＡＰＩコールに続いてポインタｐによってアクセスされる整数の変数による除算を伴う式を構文解析するときに、シミュレータは、ゼロによる除算または未定義の値による除算の警告を生成しないことになる。
【００５７】
理解されるであろうが、ＡＰＩまたはその他の外部関数によって実行される可能性のある任意の数のアクションに対応する任意の数のＡＰＩプリミティブが存在することができる。
【００５８】
これらのＡＰＩプリミティブのいくつかを使用して、ＡＰＩ文書から導き出すことができるＡＰＩに関する情報に基づいて、SomeFunctionAPIというＡＰＩは、静的ソースコードアナライザによってソースコードのより正確な評価を容易にするようにモデル化することができる。
【００５９】
【表２】
2006236336.tif 000004
【００６０】
このように、シミュレータが、SomeFunctionAPIに対するコールを識別するとき、シミュレータＡＰＩは、静的ソースコードシミュレータによってチェックされるモデルのリポジトリを検索する。SomeFunctionAPIのモデルが見つかると、モデルのリポジトリ中のモデルによって表されるＡＰＩの振る舞いを含め、ソースコードの振る舞いを評価するにあたって補助するために、そのモデルにアクセスする。したがって、以降でさらに説明するように、静的ソースコードアナライザは、見逃される可能性のあるＡＰＩの使用に関連する意味上のエラーを識別し、ならびにソースコードによって呼び出されるＡＰＩのソースコード実装にアクセスできない静的ソースコードアナライザによって生成される可能性のあるノイズおよびフォールスポジティブのエラーメッセージを低減することができる。
【００６１】
（ＡＰＩの潜在的なモデルを表す状態オブジェクトのグラフィカルな記述）
図５は、例示的なＡＰＩをモデル化するために作成された状態オブジェクト５００のグラフィカルな表現である。状態オブジェクト５００は、ＡＰＩ文書で提供される情報のみを使用するが、静的ソースコードアナライザを補強してソースコードのコンテキスト内でＡＰＩの呼び出しを有意に評価するという点に留意されたい。
【００６２】
状態オブジェクト５００は、ＡＰＩコールの構文を評価するために状態５０２を含む。ＡＰＩは、「エクスターン」構文を使用して宣言を行うことによって外部関数として指定されるため、従来の静的ソースコードアナライザは、その「エクスターン」構文が、ソースコードを利用できないモジュールを呼び出すと認識し、その式の残りの構文を無視するであろう。したがって、状態５０２は、静的ソースコードアナライザを補強してＡＰＩコールの定義された構文が使用されるかどうかを判定できるようにする。状態５０２は、要求された一連の引数が供給されるかどうかを判定するために順次テストされる複数の状態を含むことができる。供給されない場合、状態５０４において、静的ソースコードアナライザによって生成されるエラーレポートに含まれる構文上のエラーが作成される。一方、構文が正しい場合、または状態５０４において構文上のエラーが作成されると、状態オブジェクト５００は状態５０６に進む。
【００６３】
状態５０６において、ＡＰＩの依存関係の条件が満たされるかどうかが判定される。満たされない場合、状態５０８において、静的ソースコードアナライザによって生成されるエラーレポートに含まれる依存関係のエラーが作成される。依存関係のエラーは、例えば、ＡＰＩが呼び出される前に必ず、ＡＰＩ文書で指定されたように別のＡＰＩが呼び出されるか、または他の何らかの関数が実行されなければならない場合に存在する可能性がある。依存関係をチェックする複数の状態５０６を含むことができ、そのそれぞれは、特定の依存関係を評価する。依存関係が満たされる場合、または状態５０８において依存関係のエラーが生成されると、状態オブジェクト５００は状態５１０に進む。
【００６４】
状態５１０において、第１の変数がゼロより大きいかどうかが判定される。そうでない場合、状態５１２において、第２の変数は、初期化または処理されたものとしてフラグされない。一方、状態５１０において第１の変数がゼロより大きいと判定された場合、状態５１４において、第２の変数が、初期化および処理されたものとしてフラグされる。
【００６５】
状態オブジェクト５００は、静的ソースコードアナライザによって採用されるその他の状態オブジェクトと協調して動作する。このように、例えば、ｘが定義されると、状態オブジェクトが、それのために静的ソースコードアナライザによって作成される。ｘは初期化されていないため、その状態オブジェクトは、それが初期化されていないことを示す。ＡＰＩの機能についての一定の理解がなければ、静的ソースコードアナライザは、ＡＰＩが［ｏｕｔ］変数を初期化することはなく、したがってフォールスポジティブという結果になるか、または常に［ｏｕｔ］変数を初期化し、それによって潜在的な問題を見落とすかのいずれかになると想定することができる。このように、本発明におけるＡＰＩのモデル化は、より良くより正確な情報がユーザに提供されることを保証する。
【００６６】
（例示的なＡＰＩを呼び出すコードの静的ソースコード分析）
一方で、図６Ａに示されているように、ＡＰＩをモデル化しない静的ソースコードアナライザ６００は、提示されているようなソースコード６１０（これは、ＡＰＩソースコードを含まない）によってｘが初期化されない限り、ｘは初期化されないと想定することができる。このように、（ｚがゼロより大きい場合は）ＡＰＩコール６２０がｘを初期化する可能性があるにもかかわらず、行１１の式６３０、ｙ＝１／ｘは、ｘが初期化されていない場合に未定義の値による除算となる可能性があるため、エラーメッセージ６４０ａをもたらす結果となるであろう。式６５０ａでは変数ｚがゼロに設定されているためにｘはＡＰＩによって初期化されず、ｚがゼロより大きくないためにｘは初期化されないので、図６Ａのエラーメッセージ６４０ａは正確なステートメントであることが分かる。しかし、従来の静的ソースコードアナライザは、ＡＰＩの関数を評価するように適合されておらず、したがってＡＰＩがｘを初期化するかどうかを判定できないため、エラーメッセージ６４０が正確であることは、まったくの偶然である。
【００６７】
しかし、ＡＰＩモデルの恩恵なしで、静的ソースコードアナライザ６００ａは、図６Ｂに示されているように、ｘが初期化されるときでも同じエラーメッセージを作成するであろう。図６Ｂにおいて、静的ソースコードアナライザ６００は、ソースコード６１０’を分析する。このソースコード６１０’は、ステートメント６５０ａ（図６Ａ）では、ｚが初期化され、０に設定されていたが、ＡＰＩコール６２０に先立つステートメント６５０ｂでは、ｚが初期化され、１に設定されているという変更以外はソースコード６１０とほぼ同じである。したがって、上記のようにｚが初期化されてゼロより大きいので、ＡＰＩは、ｘに関する関数を実行し、ｘをなんらかのゼロ以外の数として返すであろう。したがって、式６３０は、初期化されていない変数による除算という結果にはならない。それにもかかわらず、ステートメント６５０ｂによってＡＰＩコール６２０が、有効でありゼロではないｘについての値を返すことを判定する方法をソースコードアナライザ６００が有していないため、初期化されていない変数による除算の問題を示すエラーメッセージ６４０ｂが生成される。式６３０は、未定義の初期化されていない値による除算という結果にはならないであろうため、エラーメッセージ６４０ｂは、明らかに正しくないフォールスポジティブを構成する。
【００６８】
図６Ａの結果も、図６Ｂの結果も、許容することはできない。エラーメッセージ６４０ａは、真実ではないかもしれないステートメントを提示し、ソフトウェア開発者は、静的ソースコードアナライザ６００ａにこのメッセージを生成させる原因となった問題を識別し、場合によってはその問題を修正するためにコードをデバッグしようと試みる際に、困難なタスクを抱える可能性がある。静的ソースコードアナライザによって作成されるエラーメッセージ６４０ｂも、エラーのないエラーを示すため、許容することはできず、ソフトウェア開発者は、おそらくこのメッセージを防止するためにコードを改訂することができず、結果としてソフトウェア開発者は、エラーメッセージ６４０ｂを無視しなければならない。
【００６９】
別法として、図７Ａに示されているように、静的ソースコードアナライザ７００は、ソースコード６１０’ではＡＰＩコール６２０で呼び出される引数などの外部関数に渡される引数が初期化される、という想定で動作するように構成される。この想定を行う際、静的ソースコードアナライザ７００は、行１１の式６３０、ｙ＝１／ｘを、エラーをもたらす可能性があるとはみなさない。したがって、静的ソースコードアナライザ７００は、エラーが検出されていないことを示すメッセージ７４０ａを生成する。偶然にも、ｚが式６５０ｂによって初期化され、１に設定され、ＡＰＩが初期化し、ｘのゼロ以外の値を返す結果となったので、メッセージ７４０ａは正しい。
【００７０】
しかし、静的ソースコードアナライザ７００が、ＡＰＩを分析するように構成されていなければ、この想定は間違っている可能性がある。図７Ｂに示されているように、静的ソースコードアナライザ７００はソースコード６１０を分析し、ここでは変数ｚが初期化され、ステートメント６５０ａにおいて０に設定されており、この行われた想定は間違っている。ソースコード６００では、ｚがゼロに初期化されるため、ＡＰＩコール６２０はｘを初期化しない。このように、式６３０は、未定義の値による除算となる。しかし、メッセージ７４０ｂは、エラーが見つかっていないことを示している。したがって、ＡＰＩをモデル化するように構成されておらず、静的ソースコードアナライザは、不正確なメッセージ７４０ｂを再び生成する。再度、静的ソースコードアナライザ７００は、不正確なフォールスポジティブの可能性があるメッセージや、実際のエラーを含んでいない可能性があるメッセージを生成する。
【００７１】
対照的に、静的ソースコードアナライザ８００がＡＰＩをモデル化する本発明の実施形態を使用すれば、上記の問題は回避される。図８Ａに示されているように、静的ソースコードアナライザ８００はソースコード６１０を分析し、ここでは変数ｚが初期化され、ステートメント６５０ａによってゼロに設定される。その結果、ＡＰＩコール６２０は、変数ｘが初期化されないことになり、式６３０では未定義の値による除算となる。静的ソースコードアナライザ８００は、ＡＰＩプリミティブを使用したＡＰＩのモデルを含み、静的ソースコードアナライザは、ＡＰＩの関数を正しくモデル化するため、静的ソースコードアナライザは、不正な関数を認識し、正確なエラーメッセージ８４０ａを生成する。
【００７２】
さらに、図８Ｂに示されているように、静的ソースコードアナライザ８００が、ＡＰＩコール６２０の前にｚを１に初期化する式６５０ｂを含むソースコード６１０’を分析するとき、ＡＰＩはｘのゼロ以外の値を返し、式６３０は不正なオペレーションを表していない。静的ソースコードアナライザ８００は、前述のようにＡＰＩプリミティブを使用してＡＰＩの関数をモデル化するため、静的ソースコードアナライザは、式６５０におけるｚの初期化がｘを初期化してゼロ以外の値を返すことを正しく判定し、それゆえ、エラーが見つからなかったことを示すメッセージ８４０ｂを返す。このように、ソースコード６１０と６１０’の両方のケースにおいて、静的ソースコードアナライザ８００は正確なレポートを生成し、このレポートは真のエラーを識別するが、フォールスポジティブは含まない。
【００７３】
（ＡＰＩモデルを使用した静的ソースコード分析のプロセス）
図９は、本発明の実施形態に従ってソースコードを分析するための論理的なステップを示す流れ図９００である。分析は、ステップ９０２において開始する。ステップ９０４において、ソースコードが受け取られる。ステップ９０６において、コメントおよびその他のプログラミング命令以外のコンテンツがマスクされるか、そうでなければ無視される。ステップ９０８において、ソースコード要素がシミュレートされる。判定ステップ９１０において、そのソースコード要素が、ＡＰＩコールやその他の外部関数コールなどの非標準の要素を表すかどうかが判定される。その要素が非標準的な要素であると識別された場合、決定ステップ９１２において、その非標準の要素がＡＰＩコールを表すかどうかが判定される。表さない場合、ステップ９１４において、「認識されない式」というメッセージが生成される。一方、その非標準の要素がＡＰＩコールであると判定ステップ９１２において判定された場合、決定ステップ９１６において、そのＡＰＩについての分析モデルが存在するかどうかが判定される。存在しない場合、ステップ９１８において、そのＡＰＩについてのモデルが利用可能でないことを示すエラーメッセージが生成される。
【００７４】
一方、ＡＰＩモデルが利用可能であると決定ステップ９１６において判定された場合、またはそのソースコード要素が標準のソースコード要素であると以前に決定ステップ９１０において判定されていた場合、決定ステップ９２０において、そのソースコード要素でエラーが検出されるかどうかが判定される。エラーが検出される場合、ステップ９２２において適切なエラーメッセージが作成される。一方、決定ステップ９２０においてエラーが検出されない場合、あるいは以前にステップ９１４、９０８のグループ、または９２２において適切なメッセージが生成されていた場合、流れ図９００は決定ステップ９２４に進む。決定ステップ９２４において、すべてのソースコード要素がシミュレートされているかどうかが判定される。シミュレートされていない場合、ステップ９２６において、評価されるべき次のソースコード要素が識別され、次のソースコード要素はステップ９０８において評価される。あるいは、すべてのソースコード要素がシミュレートされていると以前に決定ステップ９２４において判定されると、ステップ９２８において、先のステップで生成されたすべてのエラーメッセージを含むレポートが生成される。静的ソースコード分析は、ステップ９３０において終了する。
【００７５】
本発明について、本発明およびその変更を実施する好ましい形態との関連で説明したが、添付の特許請求の範囲内で本発明に対して他にも多くの変更を行うことができることを当業者は理解するであろう。したがって、本発明の範囲は、けっして上述の説明によって限定されるものではなく、むしろ添付の特許請求の範囲を参照することによってのみ決定されるものである。
【図面の簡単な説明】
【００７６】
【図１Ａ】典型的な静的ソースコードアナライザの機能ブロック図である。
【図１Ｂ】典型的な静的ソースコードアナライザのスクリーンを示す図である。
【図１Ｃ】ＡＰＩ署名に直面している典型的な静的ソースコードアナライザの機能ブロック図である。
【図２】本発明の実施形態を使用するように適合可能なコンピューティングデバイスまたはパーソナルコンピュータ（ＰＣ）を示す機能ブロック図である。
【図３】ＡＰＩ署名を評価するために本発明の実施形態を採用する静的ソースコードアナライザの機能ブロック図である。
【図４】静的ソースコードアナライザ用のＡＰＩモデルを作成するための論理的なステップを例示する流れ図である。
【図５】ＡＰＩの関数の記述から導き出されたＡＰＩの関数をモデル化する状態オブジェクトの状態図である。
【図６Ａ】ＡＰＩに渡される引数がそのＡＰＩによって初期化されないという前提で構成された静的ソースコードアナライザのスクリーンを示す図である。
【図６Ｂ】ＡＰＩに渡される引数がそのＡＰＩによって初期化されないという前提で構成された静的ソースコードアナライザのスクリーンを示す図である。
【図７Ａ】ＡＰＩに渡される引数がそのＡＰＩによって初期化されるという前提で構成された静的ソースコードアナライザのスクリーンを示す図である。
【図７Ｂ】ＡＰＩに渡される引数がそのＡＰＩによって初期化されるという前提で構成された静的ソースコードアナライザのスクリーンを示す図である。
【図８Ａ】ＡＰＩの関数をモデル化するために本発明の実施形態を採用している静的ソースコードアナライザのスクリーンを示す図である。
【図８Ｂ】ＡＰＩの関数をモデル化するために本発明の実施形態を採用している静的ソースコードアナライザのスクリーンを示す図である。
【図９】本発明の実施形態に従ってソースコードを分析するための論理的なステップを例示する流れ図である。
【符号の説明】
【００７７】
１００  静的ソースコードアナライザ
１０２  ソースコード
１０４  入力プロセッサ
１０６  標準的なプログラミング命令
１０８  シミュレータ
１１０  エラーレポート
１２０  スクリーン
１２２  スクリーン
１２４  ソースコードウィンドウ
１２６  エラーメッセージ
１２８  分析ウィンドウ
１３０  関連
１３２  行
１５２  ＡＰＩ署名
２２０  ＰＣ
２２１  処理装置
２２２  システムメモリ
２２３  システムバス
２２４  ＲＯＭ
２２５  ＲＡＭ
２２６  ＢＩＯＳ
２２７  ハードディスクドライブ
２２８  磁気ディスクドライブ
２２９  磁気ディスク
２３０  光ディスクドライブ
２３１  光ディスク
２３２  ハードディスクドライブインターフェース
２３３  磁気ディスクドライブインターフェース
２３４  光ディスクドライブインターフェース
２３５  オペレーティングシステム
２３６  アプリケーションプログラム
２３７  その他のプログラムモジュール
２３８  プログラムデータ
２４０  キーボード
２４２  ポインティングデバイス
２４３  オーディオ入力／出力デバイス
２４６  Ｉ／Ｏデバイスインターフェース（例えばシリアル）
２４７  モニタ
２４８  ビデオアダプタ
２４９  リモートコンピュータ
２５０  外部メモリストレージデバイス
２５１  ＬＡＮ
２５２  ＷＡＮ
２５３  ネットワークインターフェース
２５４  モデム
３００  静的ソースコードアナライザ
３０２  ソースコード
３０４  入力プロセッサ
３０６  標準的なプログラミング命令
３０８  シミュレータ
３１０  エラーレポート
３５２  ＡＰＩ署名
３６０  ＡＰＩシミュレータ
３７０  ＡＰＩプリミティブ
３８０  ＳＤＫ／ＡＰＩ付属文書
６００  静的ソースコードアナライザ
６１０  ソースコード
６２０  ＡＰＩコール
６３０  式
６４０  エラーメッセージ
６５０  式
７００  静的ソースコードアナライザ
７４０  メッセージ
８００  静的ソースコードアナライザ
８４０  エラーメッセージ
【図１Ａ】
2006236336.tif 000005
【図１Ｂ】
2006236336.tif 000006
【図１Ｃ】
2006236336.tif 000007
【図２】
2006236336.tif 000008
【図３】
2006236336.tif 000009
【図４】
2006236336.tif 000010
【図５】
2006236336.tif 000011
【図６Ａ】
2006236336.tif 000012
【図６Ｂ】
2006236336.tif 000013
【図７Ａ】
2006236336.tif 000014
【図７Ｂ】
2006236336.tif 000015
【図８Ａ】
2006236336.tif 000016
【図８Ｂ】
2006236336.tif 000017
【図９】
2006236336.tif 000018