JP2009525522A - コンテクストベースのコード分析 - Google Patents

Abstract

ターゲットコードの分析チェックに関連する、形式化した一連の中間分析コンテクストの実施形態を提供する。上記の中間分析コンテクストには、ターゲットコードの開発フェーズ、ターゲットコードの種類もしくは状態、ターゲットコードを操作するソース、ターゲットコードの目的、または他の開発要件もしくは実行時要件を含むことができるがこれらに限らない。従って実施形態は、ターゲットコードがカレント分析コンテクストの下で開発されている該カレント分析コンテクストを動的に特定し、次いで、ルールを適用可能なコンテクストの知識に基づいてルールを実行することができる。より詳細には、分析ルールは（例えば、メタデータを通して）ルールを実行可能とするこれらコンテクスト条件を記述することができる。上記の記述とカレントコンテクストとに基づいて、上記コンテクスト条件に適用するよう構成したルールを実行することができる。

Description

コード分析方法及びツールに関する。

大多数のソフトウェアは多数の再利用可能なソフトウェアオブジェクトとして開発され、それぞれは１つまたは複数のタスクを実行するよう設計されている。ソフトウェア、およびそのソフトウェアを実行するコンピューティングシステムの有用性および機能性はソースコードの正確なコーディングに依存する。そのソースコードは、コンパイルまたは解釈されてプロセッサにより実行される。コーディングエラーは通常、ソフトウェアの期待される機能からの逸脱の原因となり、コンピュータシステムの他の部分（例えば、他のアプリケーション、データベース、オペレーティングシステム、等）に影響を及ぼす恐れがある。上記コーディングエラーはソフトウェアとのユーザのコンピューティングエクスペリエンスの妨げとなるだけでなく、コンピュータシステムに渡る望ましくない影響の原因ともなりうる。従って、高品質ソフトウェアの生産者は大量のテストおよび分析工数を費やしてソフトウェア内のエラーを排除する。

しかしながら、市場の要求ならびにプログラマおよび設計者の創造性により、ソフトウェアは強力とはいえ益々複雑になった。ソフトウェアの複雑性が増すと、そのソフトウェアの実装に必要なソースコードの行数も増す。直接的な結果として、ソースコード内のエラーの可能性が増え続ける。従って、ソフトウェアを多数回および様々な方法で（リリース前後に）テストまたは分析して、そのソフトウェアが意図したように動作することの保証支援をしなければならないことがよくある。

幾つかの分析環境では、テスタは、ソフトウェアの１つまたは複数の部分の動作を検証する自動化されたルールまたはテスト（本明細書では同じ意味で使用する）を開発する。例えば、ルールはグラフィカルユーザインタフェース内部の入力フィールド値の入力、様々な入力パラメータおよび広範囲の条件下でのソフトウェアオブジェクトの呼び出し、結果の出力の収集、ならびにテストが合格または失敗したかどうかの決定を自動化することができる。テスタ（テスト開発者であるかもしれずテスト開発者でないかもしれない）は、次いでテストケースを実行する。そのテストケースは、テストされるオブジェクトまたはターゲットコードが合格または失敗したかどうか（および従ってオブジェクトが意図したように動作しているかどうか）を示すものを提供する。

今日では、テスト開発者は異なるレベルのソフトウェア検証に対して異なるルールを書いている。異なるレベルとは例えば、オブジェクトまたはコード片が合格または失敗したかどうかを決定するときに、それぞれのルールが実施する分析の量などである。ソフトウェアをテストするルールに対する検証レベルは、無数の要因に依存して大きく異なる。従って、ルールまたはテストケースの実行に費やす時間とソフトウェアが徹底的にテストされる度合いとの間には一般にトレードオフが存在する。特に、生成および分析される出力が少なければ少ないほど、テストに費やされる時間は少なくなる。例えば、テスト開発者はソフトウェアのストレスまたは負荷を単純にテストするためのルールを書くことができる。上記の場合、テストケースの結果の出力は無視される恐れがあり、オブジェクトまたはターゲットコードはソフトウェアまたはシステムがクラッシュしない限り合格したと見なされる。この分析の形態によりソフトウェアの迅速なテストが可能であるが、ソフトウェアに起因する全ての効果は完全には決定されない。従って、通常、それぞれのルールが適切にソフトウェアを分析するために必要な検証レベルの決定において、多数の議論および検討事項が必要である。

広範囲のテスト検証レベルを可能とするため、コード分析ツール（例えば、静的コード分析ツール）が開発されてきた。そのコード分析ツールは、ソフトウェア開発者が自身のコードをチェックして問題および矛盾を探すための準自動的なメカニズムを提供する。より詳細には、テスト開発者は上記のツールに、ソフトウェアソース、オブジェクト、またはバイナリコードを分析してその正確性、完全性、および／または品質を特定するための様々な検証レベルを有する一連のルールを投入する。これらのツールは一般にソフトウェアの分析を、様々な形態の構成を通して制御する一体的な動作として、実施または実行する。換言すると、コードに適用した特定のチェックまたはルールを、（＃ｐｒａｇｍａのような）ソース制御表現により、ツールのコマンドラインオプションを通して、または別の制御ファイル内で表現した設定により、有効または無効のいずれかにする。これによりテスタは、開発プロセスにおける様々な段階で実行されるルールの種類を幾らか制御することができるが、上記アプローチにはなお幾つかの欠点および制限がある。

例えば、適切にコードをテストするため、テスタ（すなわち、静的コード分析ツールのユーザ）は様々なルールの豊富な知識を有する必要がある。その知識にはルールを適用すべき段階および条件が含まれるがこれらに限らない。しかしながら、上記の全てのテストケースの知識は、一般に大部分のコード開発者のスキルセットを越えている（なぜならば、コード開発者は一般にテスト開発者ほど専門的でないからである）。従って、テスタは適切な時点および適切な条件下でルールを適用することができない。さらに、上記のテストは一般に本質的に静的である（すなわち、上記のテストは通常、テスタからの明示的なジェスチャにより実行される）ので、上記のテストを実行するとき様々な時間的な非効率性がある。例えば、同じチェックが何度も何度も実行される恐れがあり、問題がプロセス内の不適切な時点（例えば、それらが繰り返し無視または保留される場所）で発生する可能性があり、および／またはエラーもしくは不良が開発プロセスにおいて十分に早期に特定されない恐れがある（すなわち、問題が特定または発見されるのがチェックインより後であればあるほど、それを解決するコストがよりかかることは自明である）。従って、一般的なコード分析ツールのこれらおよび他の関連する欠点は、過度の作業、ユーザおよび開発者の不満、性能問題、特定されないエラーまたは不良、時間的コスト、等のような多数の問題の原因となりうることがよくある。

上記のカレントコード分析ツールの欠陥および欠点を、本発明の例示的な実施形態を通して克服する。例えば、本明細書で説明する実施形態は、コードが開発される分析コンテクストを動的に追跡し、カレントコンテクスト条件に対応するルール（またはその一部）を適用することで、一連の所定ルールの実行を自動的に管理して性能の検討事項のバランスを取るコード分析ツールを提供する。本要約は、選択した概念を簡潔な形で導入するために与えることに留意されたい。これらの概念は以下の“発明を実施するための最良の形態”でさらに説明する。本要約はクレーム主題の主要な特徴または本質的な特徴を特定するようには意図しておらず、クレーム主題の範囲を決定する支援として使用するようにも意図していない。

１つの例示的な実施形態は、ターゲットコードを受信するコード分析ツールで構成したコンピューティングシステムを提供する。そのターゲットコードを、一連の所定ルールに基づいて正確性、完全性、および／または品質に関して分析する。コード分析コンテクスト情報も開発装置（複数）から受信して、ターゲットコードがカレントコード分析コンテクストのために開発されているところの該カレントコード分析コンテクストを動的に追跡する。さらに、その一連の所定ルールから選択したルールに対応するコンテクストパラメータを受信する。コンテクストパラメータは、ルールの少なくとも一部に対する実行条件をコード分析コンテクスト情報の観点で記述することに留意されたい。その後、カレントコード分析コンテクストを考慮してルールコンテクストパラメータを評価し、分析中のターゲットコードに対してルールの少なくとも一部を実行できるかどうかを動的に決定し、従ってそのルールの少なくとも一部を開発プロセスにおける適切なフェーズで適用する。

他の例示的な実施形態は、動的コンテクスト追跡モジュールを含むコード分析ツールを提供する。動的コンテクスト追跡ツールはコード分析コンテクスト情報を開発装置（複数）から受信する。そのコード分析コンテクスト情報をターゲットコードの開発対象であるカレントコード分析コンテクストの決定において使用する。コード分析ツールはルール管理モジュールも備える。そのルール管理モジュールはカレントコード分析コンテクストおよびコンテクストパラメータを評価する。そのコンテクストパラメータは、ルールの少なくとも一部に対する実行条件をコード分析コンテクスト情報の観点で示す。その評価に基づいて、ルール管理モジュールは、正確性、完全性、および／または品質に関して分析されるターゲットコードに対してルールの少なくとも一部を実行できることを動的に決定する。加えて、コード分析ツールは実行モジュールを含む。その実行モジュールは、ルールの少なくとも一部が開発プロセスにおける適切なフェーズで適用されるように、そのルールの少なくとも一部を分析中のターゲットコードに対して実行する。

本発明の追加の特徴および利点は以下の記述において説明され、その記述から部分的に明らかとなり、または本発明の実践により習得することができる。本発明の特徴および利点を、添付請求項で特に指摘した手段および組合せを用いて実現および取得することができる。本発明のこれらおよび他の特徴は、以下の記述および添付請求項からより十分に明らかとなり、または以降説明する本発明の実践により習得することができる。

本発明の上述および他の利点および特徴を取得できる方法を説明するため、簡潔に上述した本発明のより詳細な説明を、付属図面で示したその特定の実施形態を参照して与える。これらの図面は本発明の一般的な実施形態を示すに過ぎず従ってその範囲の限定として考えるべきでないことを理解し、付属図面の使用を通して本発明をさらなる特定性および詳細をもって記述および説明する。

本発明は、コードがカレントコンテクストの下で開発されているところの該カレントコンテクストに基づいて、コード分析ツールにおけるルールの実行を動的に管理する方法、システム、およびコンピュータプログラム製品に及ぶ。本発明の実施形態は、以下でさらに詳細に議論するように、様々なコンピュータハードウェアまたはモジュールを含む特殊目的または汎用目的コンピュータを備えることができる。

本明細書で提供する実施形態は、ターゲットコードの分析チェックに関連する中間数（ｉｎｔｅｒｍｅｄｉａｔｅ ｎｕｍｂｅｒ）の分析コンテクストを形式化する。従って実施形態は、ターゲットコードが開発されている該カレント分析コンテクストを動的に特定し、次いでルール（単数または複数）を適用可能なコンテクストの知識に基づいてルール（単数または複数）（またはその一部）を実行することができる。上記の中間分析コンテクストはターゲットコードの開発フェーズ、ターゲットコードの種類または状態、ターゲットコードを操作するソース、ターゲットコードの目的、または他の開発もしくは実行時の要件を含むことができるがこれらに限らない。上記の中間分析コンテクストは、コードのリテラル開発（ｌｉｔｅｒａｌ ｄｅｖｅｌｏｐｍｅｎｔ ｏｆ ｃｏｄｅ）以外にソフトウェア開発プロセスの他のフェーズに関することに留意されたい。上記の他のフェーズは例えば、ジェスチャの構築およびパッケージ化、デプロイメントテスト、およびリテラル(literal)に実行するときの実行時コード分析、例えば、様々なマシンおよびネットワーク構成で実行するときの実行時コード分析を含むことができる。勿論、コード分析コンテクストの定義または形式化に関して多数の重複および他の関係がある。従って、本明細書で定義した用語“コード分析コンテクスト”は、上述および後の実施形態でより詳細に定義する任意数の分析コンテクスト、分析コンテクストの任意の組合せ、および／または分析コンテクストの任意の階層的関係を含むように広く解釈されるべきである。

カレントコンテクスト条件の知識をシステムにより様々な方法で獲得できることに留意されたい。例えば、上記のコンテクスト情報を統合開発環境（ＩＤＥ）と結びつけて取得することができる。ＩＤＥは一般にプロジェクトタイプおよびソース言語を通信し、コンパイラ設定および／またはビルドフレーバー、等の知識を有することができる。代替として、または関連して、上記のコンテクスト情報をソースベースのインスペクションおよびコンパイラ提供のメタデータにより、および／またはそのコードに対するバイナリをホストしているマシンのインスペクションにより、取得することができる。加えて、コード分析情報を提供する他のコンテクストソースは、マシンをホストする大規模ネットワークシステムのインスペクションのようなものを含むことができる。

カレントコード分析コンテクストの条件がどのように決定されるかに関わらず、上記条件に関連するルールセットを決定するために、分析ルール（または他のデータオブジェクト）は、ルール（またはその一部）を実行可能なこれらのコンテクスト条件（および好適なルールまたはデフォルトコンテクストのような他の情報）を（例えば、メタデータを通して）記述することができる。ルールの実行または提供した（例えば、メタデータ内の）他の情報に対する上記のコンテクストに関する決定をルール開発者により行うことができるが、他の実施形態は上記のコンテクスト条件を修正、ノイズフィルタリング、および／または無効化（override）することができる。例えば、幾つかの実施形態では、ルールを適用可能なコンテクストを、ＩＤＥ内部の明示的なジェスチャにより、および／または分析実行に関連付けた制御ファイルの修正により、修正または無効化することができる。従って、開発者がコード分析オプションを構成するとき、開発者はそれぞれのルールに関連付けた一連のコンテクストを無効化するオプションを有することができる。本情報を次いで、ユーザが設定した他のコード分析オプションを含むプロジェクトファイルに記憶することができる。

それにも関わらず、無効化されていないルールに対して、様々な開発段階の最中に、カレントコンテクストを動的に決定し、提供される情報またはメタデータに基づいて上記のコンテクスト条件に適用するよう構成したルールを実行する。分かるように、これにより様々な開発段階の最中の動的なコード分析が可能となり、その結果、潜在的な問題をコード開発者に対して開発プロセスにおいてできるだけ早期に通知することができる。加えて、一般にルールに関してより具体的な知識を有するテスト開発者は、ルールを適用すべきコンテクストを検討および設定することができる。さらに条件が変化または発展すると（例えば、ターゲットコードが開発される形式化コンテクスト条件における変化）、様々なメタデータも修正および現状維持することができ、従ってルールを拡張可能とすることができる。

有利な特徴に対するより具体的な参照を図面に関連して以下でさらに詳細に説明するが、本発明の範囲内の実施形態は、自身に記憶したコンピュータ実行可能命令またはデータ構造を保持または有するコンピュータ読取可能媒体も含む。上記のコンピュータ読取可能媒体は、汎用目的または特殊目的のコンピュータによりアクセス可能な任意の利用可能な媒体であり得る。限定ではなく例として、上記のコンピュータ読取可能媒体はＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭもしくは他の光ディスク記憶、磁気ディスク記憶もしくは他の磁気記憶装置、または所望のプログラムコード手段をコンピュータ実行可能命令もしくはデータ構造の形で保持もしくは記憶するために使用可能で、かつ汎用目的もしくは特殊目的のコンピュータによりアクセス可能な任意の他の媒体を備えることができる。情報をネットワークまたはコンピュータに対する別の通信接続（ハードワイヤード、ワイヤレス、またはハードワイヤードもしくはワイヤレスの組合せのいずれか）上で転送または提供するとき、コンピュータはその接続を正しくコンピュータ読取可能媒体と見なす。従って、任意の上記接続を正しくはコンピュータ読取可能媒体と称する。上記の組合せもコンピュータ読取可能媒体の範囲内に含めるべきである。

コンピュータ実行可能命令は例えば、汎用目的コンピュータ、特殊目的コンピュータ、または特殊目的処理装置に或る特定の機能または機能群を実施させる命令およびデータを備える。主題を構造的特徴および／または方法論的動作に固有な言語で説明したが、添付請求項で定義した主題は必ずしも上述の特定の特徴または動作に限定されないことは理解されるべきである。寧ろ、上述の特定の特徴および動作は請求項を実装する例示的な形態として開示してある。

本明細書で使用するとき、用語“モジュール”または“コンポーネント”は、コンピューティングシステム上で実行されるソフトウェアオブジェクトまたはルーチンを指すことができる。本明細書で説明する異なるコンポーネント、モジュール、エンジン、およびサービスを、そのコンピューティングシステム上で実行されるオブジェクトまたはプロセスとして（例えば、別のスレッドとして）実装することができる。本明細書で説明するシステムおよび方法をソフトウェアで好適に実装するが、ハードウェアまたはソフトウェアおよびハードウェアの組合せでの実装も可能であり考慮されている。本説明では、“コンピュータエンティティ”は本明細書で前に定義した任意のコンピューティングシステム、またはコンピューティングシステム上で実行されている任意のモジュールもしくはモジュールの組合せであってよい。

本明細書で説明した実施形態は、無数の要因を考慮してルールの実行を動的に管理し、性能の検討事項のバランスを取るコード分析ツールを提供する。例えば、本明細書の実施形態では、幾つかのルールにより生成したメッセージを、コードのビルドの最中または後に検出したときに直すのはコストがよりかかると考える。従って、開発者はこれらの警告ができるだけ早期に、一般にはコードの編集中に通知されることを望むかもしれない。さらに、チェックインのような様々な開発段階に対してコードの準備ができているとき、または開発のマイルストーンが完了したとき、幾つかのルールにより生成したメッセージを処理することが最も興味深い。例として、未使用のコードを検出する分析をマイルストーンが未完了の間に実施することはあまり意味がない。なぜならば、そのコードを後の開発プロセスで使用する可能性があるからである。さらに、前述のように、幾つかのルールの実行は極度にコストがかかる。従って、開発者は全てのインクリメンタルビルドまたは完了リビルドに対する上記の分析コストの負担を望まない可能性がある。

考慮すべき他の要因は、その機能性に依存して、分析を完了するために多少のバイナリメタデータを要求するルールから成る。幾つかのルールは、ソースコード内でのみ利用可能である情報を要求することができ、従ってファイルを実際に生成したときにそのルールをコンパイルすることができる。しかしながら、他のルールはディスクに書き込まれる、または書き込まれるであろうリテラルオブジェクトコードを要求する。さらに他の実施形態は、幾つかのルールはバイナリが真のリリース状態にあることを要求するという考察から成る。そのバイナリは、クライアントボックス上の開発者が生成したビルドとは異なる。例えば、開発者は一般に、特定の企業の実際のセキュリティキーにより署名した完全署名のバイナリを生成しない。

考慮可能なさらに他の要因では、幾つかのルールはクライアント開発システムから大幅に異なるマシン構成（複数）に依存することを考慮する。例えば、幾つかのウェブアプリケーション分析は、実際にウェブサーバに展開したコードに対して実行する場合にのみ関連することができる。加えて、幾つかのルールではバイナリの実行コンテクストに関する特別な知識が要求される。例えば、決してローカライズされず、または英語以外のシステム上で実行されないコードを、一般にグローバリゼーション／ローカライゼーション問題に対して検査する必要はない。さらに、幾つかのルールは特別なコンテクストで実行されて、大規模ネットワークシステムに関連する問題を検証しなければならないことを考える。例として、インターネットに展開したウェブアプリケーション（複数）に対するセキュリティチェックをファイアウォールのイントラネット外部で実行する必要があるかもしれない。

さらに本明細書で検討することは、幾つかのルールの振る舞いは、コードの寿命に関連する状況に従って変化するという事実である。例として、外部の顧客に以前にリリースしたバイナリは、高レベルの後方互換性を維持する必要があるかもしれない。従って、解決にブレイキングチェンジ（ｂｒｅａｋｉｎｇ ｃｈａｎｇｅ）を要求する違反を引き起こすルールを引き起こすべきでない。さらに、幾つかのルールの振る舞いを、実行の振る舞いに関する実行時の予想に従って変更する。例として、幾つかの性能チェックは、頻繁に呼ばれる性能に敏感なコードに関連するのみであるかもしれない。極稀に呼ばれるコード、または特定した問題の解決という利点を打ち消す実行コストを必然的に伴うコードに対して、これらのルールを実行することは望ましくない可能性がある。上に関連して、分析は、修正が分析ターゲットコード内で可能であるか可能でないかに従って、他の状況では変化すべきである。例として、分析をコンパイラが発行したコードパターンに対して行うことができ、ユーザコードの変更によりそれに影響を及ぼすことはできない。しかしながら、コンパイラチームはこれらの問題を特定し、分析ターゲットを生成したコンパイラ内で変更を加えたいかもしれない。

さらに幾つかの実施形態においては、幾つかのルールの振る舞いは、ターゲットバイナリコードの意図した再利用（または非再利用）に従って変化することを考慮している。例えば、任意のサードパーティの開発者により消費されうるコードは、一貫性および有用性を出すために或る特定の標準に従う必要があるかもしれない。これらの標準は、異なるコーディング標準を強制するチームの全く内部的なプロジェクトに対しては無視される恐れがある。加えて、ルールの振る舞いはプロジェクトのリソースを考慮して変化するかもしれない。例えば、制約されたリソースまたは厳しい納期を有するプロジェクトに対して分析は、深刻な訂正の影響を有する高い確度の結果に制限する必要があるかもしれない。

勿論、開発プロセスにおける様々なコンテクストに基づいてルール（複数）の実行を管理するための、本明細書で説明した例示的な実施形態に従って考慮可能な無数の要因および検討事項がある。実際、以下でさらに詳細に説明するように、コードが開発される分析コンテクストは連続的に変換するので、本明細書で説明した実施形態は、様々なルールの管理および実行方法の拡張性を可能とする。従ってルール（またはその一部）を実行すべきコンテクストを決定するための本明細書で説明した検討事項は例示の目的にのみ使用し、明示的に主張しない限り本発明の範囲を限定または制限するようには意図されない。

いずれにせよ、上の検討事項の一部を考慮して、図１に上記のコードが開発されているカレントコード分析コンテクストに基づいてルールの実行を管理するコード分析ツール１００を示す。図１に示すように、ターゲットコード１２０を、１つまたは複数の無数の開発装置１０５の間で開発用に配布することができる。それらの開発装置は、ＩＤＥ１１０および、他のコンテクストソース１１５として列挙したもののようなコンテクストを提供可能な他の装置を含む。例えば、ターゲットコードはＩＤＥ１１０内のソースコードの形態であることができ、またはマシンもしくはシステム内部で実行されるバイナリコードであることができる。勿論、他の形態のターゲットコード１２０も本明細書では考慮している。例えば、以下でさらに詳細に説明するように、ターゲットコード１２０は設計フェーズにあることができ、ソースコードの抽象概念である。従って、本明細書で説明した任意の特定種類のターゲットコード１２０は適切な開発状態または実行時状態に依存するであろう。

開発状態または実行時状態に関わらず、本明細書の実施形態は動的コンテクスト追跡モジュール１３０を提供する。動的コンテクスト追跡モジュール１３０は、本明細書で説明するようにコード分析情報１２５を様々な開発装置１０５から取得することができる。以下でさらに詳細に説明するように、コード分析情報１２５は、ターゲットコード１２０が現在分析および／または開発されているコンテクストに関する情報を含む。コード分析情報１２５、および従って分析コンテクスト情報を、コード分析ツール１００または動的コンテクスト追跡モジュール１３０により様々な方法で獲得できることに留意されたい。例えば、動的コンテクスト追跡モジュール１３０をＩＤＥ１１０に接続することができる。ＩＤＥ１１０はプロジェクトタイプおよびソース言語を通信し、コンパイラ設定およびビルドフレーバー、等の知識を有することができる。

コード分析１２５内のコンテクスト情報を、ソースベースおよびコンパイラ提供のメタデータのような他のコンテクストソース１１５のインスペクションにより、バイナリもしくはターゲットコード１２０をホストしているマシンのインスペクションにより、および／またはマシンをホストする大規模ネットワークシステムのインスペクションにより、取得することもできる。勿論、理解できるように、動的コンテクスト追跡モジュール１３０により取得可能な多数のコンテクストソース１１５がある。実際、コード分析ツール１００（例えば、ルール実行モジュール１４０）内部のモジュールおよび／またはルール自身はコード分析情報１２５を提供することができる。従って、本明細書で説明するようにコード分析情報１２５を提供する任意の特定の装置、コンポーネント、モジュール、データオブジェクト、等は例示の目的に過ぎず、明示的に主張しない限り本明細書の実施形態を限定または制限するようには意図されない。

コード分析情報１２５を、要求−応答、プッシュ−プル、パブリッシュ−サブスクライブシステム、等のような任意の多数の公知なメカニズムを通して動的に取得できることにも留意されたい。例えば、１つの実施形態によりコード分析情報１２５を、イベント通知システムを使用して取得することができる。例えば、ターゲットコード１２０の開発に影響を及ぼすコンテクストの変化または他のイベントが発生すると、（一般にコード分析情報１２５の形である）通知を、動的コンテクスト追跡モジュール１３０により送信または受信することができる。勿論、コード分析情報１２５を取得する多数の方法がある。従って、コード分析情報１２５の取得方法に対する任意の特定の参照は本明細書では例示の目的にのみ使用し、明示的に主張しない限り本明細書の実施形態を限定または制限するようには意図されない。

いずれにせよ、前述のように、動的コンテクスト追跡モジュール１３０はチェックに関連する多数の分析コンテクストを形式化する。従って、コード分析情報１２５の取得場所または取得方法に関わらず、本情報１３５を次いで使用して、動的コンテクスト追跡モジュール１３０内部で定義（または動的コンテクスト追跡モジュール１３０により取得した）これらのコンテクストに基づいてカレントコード分析コンテクスト１３５を決定することができる。カレントコード分析コンテクスト１３５を、前述のような多数の検討事項の観点から定義できることに留意されたい。例えば、上記の分析コンテクストをターゲットコード１２０の開発フェーズ、ターゲットコード１２０の状態、ターゲットコード１２０を操作するソースの種類、ターゲットコード１２０の目的、ならびに／または他の開発もしくは実行時の要件および検討事項の観点から定義することができる。

上で定義した分析コンテクストは、様々な階層的項目で表現可能または表現不可能な多数の特性または条件（例えば、分析をコードの書込みからどのように除外したか）を含むことができることに留意されたい。例えば、開発のフェーズの観点で定義したコード分析コンテクストは設計、ビルド、デプロイメント、または他のフェーズもしくはプロパティから成る段階を含むことができる。さらに、分析コンテクストを以前のフェーズ、および分析を行っているカレントフェーズの観点から定義することができる。さらに、開発のそれぞれのフェーズをさらに他のサブフェーズを通して定義することができる。例えば、ビルド段階は編集フェーズ、インクリメンタルビルドに対するコンパイルフェーズのサブ段階、チェックイン前のサブフェーズを含むことができる。別の例として、分析コンテクストを、ソースコード、オブジェクトコード、バイナリコード、または抽象コード状態、のような自身の状態または型の観点で定義することができる。その分析コンテクストは一般に、コード自体を完全には記述しない。

分析コンテクスト（複数）（例えば、場合によりカレントコード分析コンテクスト１３５）を互いの間の階層的関係の観点からさらに定義できることにも留意されたい。例えば、或るコード分析コンテクストを、別の分析コンテクストが無事に（または失敗して）完了したことの観点から定義することができる。さらに、顧客にリリースされるものに正確に対応するかまたは対応しない可能性があるバイナリに対するビルド環境の観点から定義したコンテクストの場合のように、分析コンテクスト間の重複プロパティが存在する可能性がある。勿論、コード分析コンテクストの定義または形式化に対して多数の関係がある。従って、前述のように、用語“コード分析コンテクスト”（例えば、カレントコード分析コンテクスト１３５）は、本明細書で定義したように任意数の分析コンテクスト、分析コンテクストの任意の組合せ、および／または分析コンテクストの任意の階層的関係を含むように広く解釈すべきである。

定義した形式化コード分析コンテクスト（複数）に関係なく、このコンテクストリストをコード分析情報１２５ともに使用してカレントコード分析コンテクスト１３５を決定する。従って、ルール管理モジュール１５５はカレントコード分析コンテクスト１３５を使用して、分析ルール記憶１７０内のルール１７５の実行を動的に管理することができる。より詳細には、カレントコード分析コンテクスト１３５に関する実行に対して設定したルール１７５をルール管理モジュール１５５が動的に決定するために、それぞれの分析ルール１７５（または他のデータオブジェクト）は（例えば、メタデータを通して）、ルールを実行可能なコンテクストパラメータ１８０を記述する。一般に、上記のコンテクストパラメータ１８０をルール開発者により定義するが、実施形態ではルール構成モジュール１６５を使用してコンテクストパラメータ１８０の修正および／または追加を可能とすることも考慮している。より詳細に説明するように、ルールを他の様々なメカニズムを通して無効化することもできる。

いずれにせよ、コンテクストパラメータ１８０は、ルール１７５を適用可能または適用不可能なコンテクストのような情報を含むことができ、および／または、例えばサポートされるもの、好適なもの、任意なもの、必要なもの、または任意の他の公知な優先順位付けとして優先される、コンテクストのリストを有することができる。より具体的な例として、名前付けおよび場合分けルールを、全ての分析フェーズをサポートするとして印付けすることができる（すなわち、名前付けルールは任意の開発フェーズでの実行に適切である可能性がある）。しかしながら、実行に好適なフェーズはバックグラウンド期間である可能性がある。従って、これらのチェックを開発者がソースを編集している間に実行すべきであるが、他のフェーズで実行することもできる。

さらに、コンテクストパラメータ１８０は、分析の完了に対する実行時の期間、入力に必要な情報、または結果の出力、等のような振る舞いの観点からルールを定義するメタデータを含むことができる。従って、上記の追加の情報をルール管理モジュール１５５（および／またはカレントコード分析コンテクスト１３５を決定するための動的コンテクスト追跡モジュール１３０）により使用して、実行に必要な適切なルール１５０を決定することができる。勿論、コード分析コンテクスト（複数）に関して上述したものと同様に、コンテクストパラメータ１８０を重複プロパティ、階層的関係、等の観点から定義することができる。例えば、１つの実施形態では、ルールの分析を、カレント指定フェーズと等価またはカレント指定フェーズからさらに除外した任意のフェーズで行うことができる。例えば、バックグラウンドコンパイル中に実行するよう構成したルールを、ビルド、チェックイン、またはマイルストーンフェーズの最中に実行することもできる。

一般にルールに関してより具体的な知識を有するテスト開発者は一般に、ルールを適用すべきコンテクストパラメータ１８０を考慮および設定することができる。上記の検討事項は以下のもの（必ずしも特定の順序ではない）を含むことができるがこれらに限らない。第１に、本ルールにより生成したメッセージが意味を成す開発フェーズは何か？第２に、どのくらい迅速に制御をユーザに戻すべきか？例えば、コードの編集中に行う分析は一般に編集者が認識する性能に影響を及ぼすべきではない。第３に、チェックを完了するのに必要なメタデータの量はどれくらいか？例えば、オブジェクト設計図に対して行う分析は、型がサードパーティの開発者に公的に可視であるか否かに関する情報を提供できないかもしれない。第４に、問題に対する適当な修正はブレイキングチェンジを構成するか？すなわち、問題の修正は消費者に以前の版の修正ＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅｒｆａｃｅ）を破棄させるか？そうならば、本情報を開発プロセスにおいてできるだけ早く開発者に与える必要があるかもしれない。または、以前に出荷したコードに対するブレイキングチェンジが特定される場合、（高レベルの後方互換性を維持するよう分析を構成したことを仮定して）一般的な解決方法はその問題を開発者に全く明らかにしないことであろう。換言すれば、問題が出荷されており従って修正することが（以前の版の消費者に対して障害の原因となりうるので）もはや安全でない場合、その結果をフィルタすることが必要または望ましいかもしれない。第５に、問題を解決するためのコストはどれくらいか？どの程度コードが変更されるか？分析にかかる時間はどれくらいか？変更がレグレッションを導入する可能性はどれくらいか？問題に関連するソースコードが修正に対して利用可能か？第６に、どの特別なバイナリ、オペレーティングシステム（ＯＳ）、マシン、および／またはネットワークの検討事項がルールの振る舞いに影響するか？および／またはチェックを実行すべきかどうか？第７に、どの特別なプロジェクトの検討事項が、行う分析および／またはユーザに戻すべき結果に影響するか？

加えて、前述のように、本明細書の実施形態は、コンテクストパラメータ１８０が修正可能または構成可能であることを規定する。従って、ルール構成モジュール１６５を（ルールおよび／またはコード開発者のいずれかにより）使用して、ルールが実行可能な分析コンテクスト（複数）を拡張または制限することができる。代替として、または追加として、ルールを実行可能なコンテクストを構成設定／制御ファイル１６０を通して無効化することができる。例えば、ルールを、ＩＤＥ１１０内部の明示的なジェスチャのようなものを通して、または分析の実行に関連付けた制御ファイルを修正することで、無効化することができる。従って１つの実施形態により開発者は構成コード分析オプションにアクセスすることができる。構成コード分析オプションにより開発者はそれぞれのルールに関連付けた一連のコンテクストを無効化することができる。本情報および他の情報を、ユーザが設定した他のコード分析オプションを含むプロジェクトファイルに記憶することができる。

ルール／コンテクストの構成に関連して、本明細書の実施形態は幾つかの構成ジェスチャがチェックに固有でありうることも考慮し、従って本明細書で提供するものは大規模な分析コンテクストに連結可能な構成オプションである。例えば、本明細書の実施形態により、ルールを何らかの方法（例えば、０−１００％の範囲であり、ユーザに提供したノブまたは他の絞り制御メカニズムにより調整可能なノイズフィルタ設定）で絞ることができ、レビュー向けの出力を制限し、高い確度のオプションに対する出力を制限し、および／または分析にかかる時間を制限する。本ルール構成オプションはシステム内にシームレスに存在すべきであり、ルール固有の構成と大規模システムにより定義したコンテクストとの間に密接な関係がありうることに留意されたい（例えば、バックグラウンド分析を実行するときは、ノイズレベルを５０％の確度またはそれ以上に制限する）。

他の実施形態は、分析コンテクスト構成可能性をプロジェクト内の人員の役割にマップすることも提供する。より詳細には、ソフトウェア開発プロジェクトに従事する個人は一般に（１）分析コンテクストを示唆する特定の時点でコードに寄与する、自身にとって多少堅実な結果を生成する様々な専門知識を有する、（３）リソースの割り当て場所（および恐らく割り当てるリソース量）に関して決定する権限を多少有する。例えば、開発者は自身が担当するコードに対して、ここでの変更に固有な結果を理解するべきである。他方、プロジェクトマネージャは、特定の分析専用の開発者／テストサイクルを制限するために結果を元に戻すことができる。これを、バイナリ／製品の完全性（例えば、全てのバイナリが存在するか？ウイルスはないか？破損していないか？等）に関する問題の特定および修正を担当するが、技術的な能力がなく正確性の問題を修正する能力もないビルドマネージャと対比されたい。従って、本明細書の実施形態により、本明細書で説明した分析コンテクスト構成をチーム、およびコード開発および実行時プロセスに関与する他の者の様々な役割に自動的にマップすることができる。

ルールおよび／または分析コンテクストの構成方法に関わらず、カレントコード分析コンテクスト１３５とそれぞれのルール１７５内部で定義したコンテクストパラメータとの間の分析に基づいて、および／または構成設定／制御ファイル１６０に基づいて、ルール管理モジュール１５５は次いで一連のルール１５０を選択して実行することができる。従って、ルール実行モジュール１４０は一連のルール１５０をターゲットコード１２０に対して適用して、結果１４５を生成することができる。理解できるように、上記の結果１４５は、分析コンテクスト、適用しているルール、および他の要因のようなものに依存して大幅に変化するであろう。例えば、ソースコードを編集しているユーザに結果１４５を名称変換分析（ｎａｍｉｎｇ ｃｏｎｖｅｒｓｉｏｎ ａｎａｌｙｓｉｓ）のようなものに対するインテリセンスの走り書き（ＩｎｔｅｌｌｉＳｅｎｓｅ ｓｑｕｉｇｇｌｉｅｓ）として即座に報告することができ、一方で何らかのストレステストのように、他のルール１５０はユーザに対してフィードバックを全く生成しなくともよい。他の結果１４０をさらなる分析のためファイルに記録することができ、および／または何らかの他のデータフォーマットで生成することができる。勿論、本明細書で説明した実施形態に適用可能な多数の結果１４５が存在し、説明した任意のコンテクスト下で生成した任意の特定の結果は例示の目的のために過ぎず、本明細書の実施形態の範囲を限定または制限するようには意図していない。

以下で、ターゲットコードの開発フェーズ、ターゲットコードの種類または状態、ターゲットコードを操作するソース、ターゲットコードの目的、または他の開発要件もしくは実行時要件の観点から定義した中間分析コンテクストの幾つかの例を提供する。上述のように、および以下の説明にあるように、これらの中間分析コンテクストを任意の組み合わせ、重複プロパティ、および／または階層的関係の観点からさらに定義することができる。さらに、前述のように、コンテクストパラメータ１８０、定義した分析コンテクスト（例えば、カレントコード分析コンテクスト１３５、構成設定／制御ファイル１６０、およびルール自身、は拡張可能であり、従って分析コンテクストおよび／または説明したルールの以下のリスト（および本明細書で説明した他のコンテクストまたは分析）は包括的であるとは意図していない。

例えば、ルール１７５を、ＩＤＥ１１０内の編集段階の最中に行うバックグラウンド分析の観点から記述して、例えば開発者にソースコードの変更を通知することができる。他の分析を、コンテクストパラメータ１８０により定義したそれぞれのインクリメンタルビルドまたは完全なビルドのコンテクストで行うことができる。例えば、コンパイル中に、バックグラウンドおよびコンパイルフェーズに対して定義したルールを実行することができる。上記のチェックは名前付けおよび場合分けに関連することができ、一般に極度に性能が良く、ならびに／または通常は即座に対処すべき重大な問題を警告する高付加価値な正確性チェックを表す。

コンテクストパラメータ１８０および／またはカレントコード分析コンテクスト１３５を、チェックインフェーズ前に行う分析の観点から定義することができる。例えば、チェックイン前に、バックグラウンド、コンパイル、およびチェックインフェーズのルールを纏める分析を行うことができる。従って、チェックインフェーズを特に対象としたルール１７５は一般に、公式なソースベースに対して一般にチェックすべきでない問題をフラグし、実行および／または警告する上で時間がかかる高付加価値のルール１７５である。

他の分析コンテクストをマイルストーンフェーズの観点から実行中として定義または警告することができる。その分析コンテクストは一般に明示的なユーザジェスチャにより実行する。従って、マイルストーンフェーズを特に対象としたルールは実行のコストが極度にかかるものである恐れがあり、高レベルのレビューを必要とし（すなわち、他のチェックよりも誤検出の確率が高い）、および／またはスケジュールへの配慮のため、もしくはその作業がバッチとして容易に達成できるので遅延作業項目となる。

勿論、前述のように、コード分析１００に対する環境が変化すると、ルール１７５が実行される分析コンテクストも変化する可能性がある。例えば、処理速度が増すと、マイルストーンフェーズでのみ以前に実行したルールを以前のフェーズの一部で実行できると決定することができる。しかしながら、分析コンテクストを変更または分析コンテクストに影響しうるものは多数あり、そのためルール構成モジュール１６５を使用してコンテクストパラメータ１８０（およびカレントコード分析コンテクスト１３５を生成するために使用する分析コンテクストの形式化）を修正して、必要に応じてシステムを更新および調整できることに留意されたい。

他の分析コンテクストは、顧客にリリースされるものに正確に対応可能または対応不可能なバイナリに対して、ビルド環境内で行う分析を含むことができる。顧客の実行環境に必ずしも対応しない構成に展開したバイナリに対して行う分析も存在することができる。さらに、前述のように、一般には結果のコードを完全に記述しない（設計時分析のような）抽象概念に対して行う分析が存在してよい。他の分析コンテクストを、ディスクに格納したソースまたはオブジェクトコードにより定義することができる。他の分析コンテクスト（複数）はカレントビルドを最適化でビルドしたかどうかといったコンパイル設定を考慮し、またはそのコンパイル設定から成る。バイナリに対して行う他の分析は、英語以外のシステム上で実行されるもの、またはウェブアプリケーションの一部として展開されるもののような、特定のコード目的または実行時目的を考慮することができる。従って、例えばローカライズされないコードまたは英語以外のシステム上で実行されるコードはグローバリゼーション／ローカライゼーション仕様の問題に対して実行するルールを分析または有する必要はないかもしれない。別の分析コンテクストまたはコンテクストパラメータ１８５を、イントラネットサーバまたはファイアウォールの反対側のような特化した環境に展開されるかまたはされないバイナリに対して行う分析の観点で、定義することができる。上記ルールを一般に特別なコンテクストで実行して、大規模なネットワークシステムに関連する問題を検証する。

さらに、他のコンテクスト分析を、以前に出荷したかまたはしていない可能性があるコード、またはサードパーティにより提供されたかまたはされない可能性があるコードに対して行うことができる。例えば、コンテクストがサードパーティから来たと考えられる場合、コンテクストパラメータ１８０により定義されるようにウイルスチェックまたはルールを実行する必要があるかもしれない。さらに他の分析を、外部または内部の顧客により消費されるかもしくは消費されない可能性があるコード、またはプライベートチームもしくは他の実行環境に使用が制限されるコードに対して行うことができる。分析コンテクストを、性能またはセキュリティのような実行時特性に対する厳格な要件を有するかまたは有さない可能性があるターゲットの分析によりさらに定義することができる。コンポーネントは、部分的に信頼される環境を実行するものをセキュリティ関連度が低い分析者がコーディングするまで、（任意のディスク位置に書き込む能力のような）高度なセキュリティ権限を要求することができる。さらに、他の分析コンテクストは、政府承認の暗号化サービスのみが有効であるという要件のような、特定のオペレーティングシステム構成を有するシステム上に展開されるターゲットに対する分析を含む。他の分析コンテクストを、メンテナンスモードであるかもしくはそうでないターゲット、または厳しい要員配置もしくは納期への配慮の制約があるチームで開発されるターゲットに対して定義することができる。

分析は様々なコンストラクト（すなわち、ターゲットコード１２０）に対して行う可能性があることに留意されたい。そのコンストラクトは、ソースコード、バイナリコード、またはどちらにも関連付けられない（クラス図の分析、データベーステーブルの使用、データベーススキーマの妥当性検証、ストアドプロシージャの検証、名前付け／場合分け変換をデータベース固有の識別子へ適用すること、および／またはカレントプロジェクト設定に基づいて違反を引き起こすことのような）抽象概念から発生した情報に関する。さらに、カレントコンテクストの集計セットに関連するルールセットの構成は一般に動的に行う。従って、結果は一般にソフトウェア開発ライフサイクルにおける精確かつ適切な時点でユーザに返される。本明細書で述べたように、ソフトウェア開発ライフサイクルにおける正確な結果または精確かつ適切な時点は、コード／抽象概念の現在の状態、その現在のマシンまたは想定されるマシン、オペレーティングシステム、ネットワークおよび／または実行環境、セキュリティ、信頼性、後方互換性、および文字通りの性能を含む品質の態様に対する所与のプロジェクト要件、所与のプロジェクトライフサイクル、スケジュールおよび／またはリソース制約、所与の分析時間の制約、結果を受信して結果を理解し、結果に影響を及ぼす者の所与の能力、特定のチェックが与えた所与の任意の特別な構成、またはデフォルトの構成が、単なるユーザの意固地さを含む上述しなかった完全に任意の理由のため無効化されることによる所与の任意の特別な構成、といったものに依存して変化するであろう。加えて、分析コンテクスト（例えば、ルール１７５、コンテクストパラメータ１８０、等）は構成可能、拡張可能、プラグ可能、等であるので、本明細書で説明した実施形態は、分析に関連する中間数のコンテクストを記述するオープンエンドなシステムを定義する。

本発明を、機能的なステップおよび／または非機能的な動作を備える方法の観点から説明することもできる。以下は、本発明の実践において実施可能なステップおよび／または動作の説明である。通常、機能的なステップは本発明を実現結果の観点から説明し、一方で非機能的な動作は特定の結果を実現するためのより詳細な動作を説明する。機能的なステップおよび／または非機能的な動作を特定の順序で説明または主張するが、本発明は必ずしもステップおよび／または動作のどの特定の順序または組合せにも限定されない。さらに、ステップおよび／または動作の使用はクレームを記載したものであり、以下の図２のフロー図の説明において、上記項目の望ましい具体的な使用を示すように一般的に使用する。

前述のように、図２は本発明の様々な例示的な実施形態に対するフロー図を示す。以下の図２の説明はしばしば図１の対応する要素を参照する。本図の特定の要素を参照するかもしれないが、上記の参照は例示の目的に使用するに過ぎず、明示的に主張しない限り本明細書の実施形態を限定または制限するようには意図されない。

図２は、コードが開発される分析コンテクストを動的に追跡し、カレントコンテクスト条件に対応するこれらのルールの少なくとも一部を動的に適用することで、一連の所定ルールの実行を管理して性能の検討事項のバランスを取る方法２００のフロー図を示す。方法２００は、ルールをターゲットコード２２５に対して実行可能かどうかを動的に決定するステップを含む。より詳細には、２２５に対するステップは分析すべきターゲットコードの受信動作２０５を含む。例えば、コード分析ツール１００、ルール管理モジュール１５５、ルール実行モジュール１４０、開発装置１０５、またはコンピューティングシステム内部の他のモジュールおよびコンポーネントは、正確性、完全性、および／または品質を所定ルール１７５に基づいて分析すべきターゲットコード１２０を受信することができる。

２２５に対するステップは、コード分析情報の受信動作２１０も含む。例えば、動的コンテクスト追跡モジュール１３０はコード分析情報１２５を様々な開発装置１０５から受信して、ターゲットコード１２０が開発されているカレントコード分析コンテクスト１３５を動的に追跡することができる。カレントコード分析コンテクスト１３５を、ターゲットコードの開発フェーズ、ターゲットコードの種類もしくは状態、ターゲットコード１２０を操作するソース、ターゲットコード１２０の目的、または１つもしくは複数の開発要件しくは実行時要件の観点から定義できることに留意されたい。

ターゲットコードの開発フェーズを定義する場合、上記のフェーズは設計、ビルド、デプロイメント、またはその他から成る段階を含むことができる。また、ビルド段階は編集フェーズ、インクリメンタルビルドに対するコンパイルフェーズ、またはチェックインフェーズの前のようなものを含むことができることに留意されたい。従って、上記段階に対して定義されるルールは、ディスクにまだコンパイルしていないターゲットコード１２０に対して行うバックグラウンド分析であることができる。さらに、ビルド段階はマイルストーンフェーズを含むことができることに留意されたい。分析期間、要求された入力、要求された出力、誤検出の多発もしくは頻発、スケジュールへの配慮のうち１つもしくは複数の観点から実行に必要なコストのため、または実行を他のルールを伴うバッチの一部として最も容易に実現できるため、マイルストーンフェーズはルールの少なくとも一部を実行するための特定のユーザ入力を要求する。

また、カレントコード分析コンテクストをターゲットコードの種類または状態の観点から定義するとき、上記の種類または状態は、ソースコード、オブジェクトコード、バイナリコード、または抽象コード状態のようなものを含むことに留意されたい。抽象コード状態に対して、上記の状態は、ソースコードを完全には記述しないターゲットコードの設計時の分析であることができる。

２２５に対するステップはさらに、一連の所定ルールから選択したルールに対応するコンテクストパラメータの受信動作２１５を含む。例えば、ルール管理モジュール１５５は、カレントコード分析コンテクスト１３５と、ルールセット１７５から選択した１つまたは複数のルールに対応するコンテクストパラメータ１８０との両方を受信することができる。コンテクストパラメータは、少なくともコード分析コンテクスト情報の観点から、ルールの少なくとも一部に対する実行条件を（例えば、メタデータを通して）定義することに留意されたい。さらに、コンテクストパラメータ１８０は、分析の完了に対する実行時の期間、入力に対して必要な情報、および／または結果の出力のうち１つまたは複数の観点から、ルールの振る舞いに関するメタデータを含むことができる。適用すべきルールの部分（例えば、それに対する結果の量または種類）は、ルールの振る舞いに影響を及ぼすかまたはルールの振る舞いを変更する構成のような他の要因に基づくことができることに留意されたい。前述のように、上記の構成は、逐語的なルール実行、ノイズフィルタリング、または他の制御メカニズムに対して有意義である設定／制御情報に基づくことができる。

さらに、コンテクストパラメータ１８０はサポートされるコード分析コンテクストの実行条件を定義することに留意されたい。その実行条件は、好適なもの、任意なもの、必要なもの、等のうち１つまたは複数により優先順位付けする。それにも関わらず、実行条件を、構成設定および様々な開発装置１０５、コード分析ツール１００に関連付けた制御ファイルのうち１つもしくは複数により、および／またはコンテクストパラメータ１８０を構成可能とすることにより、無効化することができる。加えて、コンテクストパラメータは、既存のコンテクスト条件を拡張可能であるように構成可能であることに留意されたい。

２２５に対するステップはさらに、カレントコード分析コンテクストを考慮したルールコンテクストパラメータの評価動作２２０を含む。例えば、ルール管理モジュール１５５はルールコンテクストパラメータ１８０とカレントコード分析コンテクスト１３５を評価して、ターゲット１２０に対する実行用の一部または完全なルール１５０を動的に決定することができる。上記の評価を行って、ルール１５０を開発プロセスにおける適切なフェーズで適用できることに留意されたい。また、カレントコード分析コンテクスト１３５を考慮したルール１７５のコンテクストパラメータ１８０の評価では、コードおよび分析コンテクスト間の階層的関係、一連の所定ルール１７５、または両方を考慮できることに留意されたい。

本発明を、その精神または本質的な特徴から逸脱せずに他の特定の形態で具現化することができる。説明した実施形態は、全ての点で例示的なものに過ぎず限定的ではないと考えるべきである。本発明の範囲は従って、前述の説明によってではなく添付請求項により示される。請求項と等価な意味および範囲にある全ての変更は、請求項の範囲内に含まれるべきである。

例示的な実施形態に従い、ターゲットコードが開発されるコンテクストに基づいてソフトウェアを動的にチェックするよう構成したコード分析ツールの図である。 例示的な実施形態に従い、コードが開発される分析コンテクストを動的に追跡することによりルール（単数または複数）の実行を管理する方法のフロー図である。

Claims (20)

1. 一連の所定ルールを使用してソフトウェアをチェックするコード分析ツールを伴うコンピューティングシステムにおいて、前記の一連の所定ルールは典型的には構成設定を通して制御される一体的な動作で実行されるものであり、性能の検討事項のバランスを取るために、前記コードが分析コンテクストの下で開発される該分析コンテクストを動的に追跡しカレントコンテクスト条件に対応する前記ルールの少なくとも一部を動的に適用することによって、前記一連の所定ルールの実行を管理する方法であって、
   一連の所定ルールに基づいて正確性、完全性、または品質の１つまたは複数に関して分析されるべきターゲットコードを受信するステップと、
   コード分析コンテクスト情報を１つまたは複数の開発装置から受信し、前記ターゲットコードがカレントコード分析コンテクストのために開発されている該カレントコード分析コンテクストを動的に追跡するステップと、
   前記一連の所定ルールから選択されたルールに対応するコンテクストパラメータを受信するステップであって、前記コンテクストパラメータは前記選択されたルールの少なくとも一部に対する実行条件を前記コード分析コンテクスト情報の観点から記述するステップと、および
   前記選択されたルールの少なくとも一部を分析中の前記ターゲットコードに対して実行して前記選択されたルールの少なくとも一部を開発プロセスにおける適切なフェーズで適用できるかどうかを動的に決定するために、前記ルールコンテクストパラメータを前記カレントコード分析コンテクストの観点から評価するステップ
   を備える方法。
2. 前記カレントコード分析コンテクストを、前記ターゲットコードの開発フェーズと、前記ターゲットコードの種類もしくは状態と、前記ターゲットコードを操作するソースと、前記ターゲットコードの目的と、または１つもしくは複数の開発要件もしくは実行時要件とのうち、１つもしくは複数の観点から定義したことを特徴とする請求項１に記載の方法。
3. 前記ターゲットコードの開発フェーズは、設計、ビルド、またはデプロイメントのうち１つまたは複数の段階を含み、前記コードの種類または状態はソースコード、オブジェクトコード、バイナリコード、または抽象コード状態のうち１つまたは複数を含むことを特徴とする請求項２に記載の方法。
4. 前記抽象状態とは、前記ターゲットコードを完全には記述しない前記ターゲットコードの設計時の分析であることを特徴とする請求項３に記載の方法。
5. 前記ビルドフェーズは、ディスクにまだコンパイルされていない前記ターゲットコードに対して行ったバックグラウンド分析を含み、編集フェーズと、インクリメンタルビルドに対するコンパイルフェーズと、またはチェックインフェーズの前とのうち１つもしくは複数を含むことを特徴とする請求項３に記載の方法。
6. 前記ビルドフェーズは、前記選択されたルールの少なくとも一部を実行するための特定のユーザ入力を要求するマイルストーンフェーズを含み、これは、分析期間、要求された入力、要求された出力、誤検出の多発、スケジュールへの配慮のうち１つまたは複数という点における実行に必要なコストのため、または実行が他のルールと一緒のバッチの一部として行うことにより最も容易に実現できるためであることを特徴とする請求項３に記載の方法。
7. 前記コンテクストパラメータに対する前記実行条件はメタデータによって定義され、前記メタデータは、分析の完了に対する実行時の期間と、入力に対して必要な情報と、または結果の出力のうち１つまたは複数の観点から前記選択されたルールの振る舞いを定義することを特徴とする請求項１に記載の方法。
8. 前記コンテクストパラメータはサポートされるコード分析コンテクストの実行条件を定義し、前記の実行条件は好適なもの、任意のもの、または必要なもののうち１つまたは複数によって優先順位付けされることを特徴とする請求項１に記載の方法。
9. 前記１つまたは複数の開発装置における一つまたは複数の構成設定、前記コード分析ツールに関連付けられた制御ファイルをさらに評価すること、または前記コンテクストパラメータを構成可能とすることにより、前記評価が前記実行条件の無効化を可能とすることを特徴とする請求項８に記載の方法。
10. 前記ルールコンテクストパラメータは、既存のコンテクスト条件を拡張可能なように構成可能であることを特徴とする請求項１に記載の方法。
11. 前記カレントコード分析の観点からの前記ルールコンテクストパラメータの前記評価は、前記コード分析コンテクスト間の階層関係、前記一連の所定ルール、またはその両方を考慮することを特徴とする請求項１に記載の方法。
12. 一連の所定ルールを使用してソフトウェアをチェックするコード分析ツールであって、前記の一連の所定ルールは典型的には構成設定を通して制御される一体的な動作で実行されるものであり、性能の検討事項のバランスを取るために、前記コードが分析コンテクストの下で開発される該分析コンテクストを動的に追跡しカレントコンテクスト条件に対応するこれらのルールの少なくとも一部を動的に適用することによって、前記一連の所定ルールの実行を管理するよう構成され、
    １つまたは複数の開発装置から、ターゲットコードがカレントコード分析コンテクストのために開発されている該カレントコード分析コンテクストの決定に使用するコード分析コンテクスト情報を受信する動的コンテクスト追跡モジュールと、
    前記カレントコード分析コンテクストと、ルールの少なくとも一部に対する実行条件を前記コード分析コンテクスト情報の観点から示すコンテクストパラメータとを評価するルール管理モジュールであって、前記評価に基づいて前記ルール管理モジュールは、正確性、完全性、または品質のうち１つまたは複数に関して分析されるべきターゲットコードに対して前記ルールの少なくとも一部を実行可能であることを動的に決定することを特徴とするルール管理モジュールと、および
    前記ルールの少なくとも一部が開発プロセスにおける適切な時点で適用されるように、前記ルールの少なくとも一部を分析中の前記ターゲットコードに対して実行する実行モジュール
    を備えることを特徴とするコード分析ツール。
13. 一連の所定ルールを使用してソフトウェアをチェックするコード分析ツールを伴うコンピューティングシステムにおいて、前記の一連の所定ルールは典型的には構成設定を通して制御される一体的な動作で実行されるものであり、性能の検討事項のバランスを取るために、前記コードが開発されるところの分析コンテクストを動的に追跡しカレントコンテクスト条件に対応するこれらのルールの少なくとも一部を動的に適用することにより、前記一連の所定ルールの実行を管理する方法を実装するコンピュータプログラム製品であって、前記コンピュータプログラム製品は、前記コンピューティングシステムの１つまたは複数のプロセッサによる実行時に前記コンピューティングシステムに対し、
    一連の所定ルールに基づいて正確性、完全性、または品質の１つまたは複数に関して分析されるべきターゲットコードを受信するステップと、
    コード分析コンテクスト情報を１つまたは複数の開発装置から受信し、前記ターゲットコードがカレントコード分析コンテクストのために開発されている該カレントコード分析コンテクストを動的に追跡するステップと、
    前記一連の所定ルールから選択されたルールに対応するコンテクストパラメータを受信するステップであって、前記コンテクストパラメータは前記選択されたルールの少なくとも一部に対する実行条件を前記コード分析コンテクスト情報の観点から記述するステップと、および
    前記選択されたルールの少なくとも一部を分析中の前記ターゲットコードに対して実行して前記選択されたルールの少なくとも一部を開発プロセスにおける適切なフェーズで適用できるかどうかを動的に決定するために、前記ルールコンテクストパラメータを前記カレントコード分析コンテクストの観点から評価するステップと
    を実施させるコンピュータ実行可能命令を自身の上に記憶した１つまたは複数のコンピュータ読取可能媒体を備えたことを特徴とするコンピュータプログラム製品。
14. 前記カレントコード分析コンテクストを、前記ターゲットコードの開発フェーズと、前記ターゲットコードの種類もしくは状態と、前記ターゲットコードを操作するソースと、前記ターゲットコードの目的と、または１つもしくは複数の開発要件もしくは実行時要件とのうち、１つもしくは複数の観点から定義したことを特徴とする請求項１３に記載の方法。
15. 前記ターゲットコードの開発フェーズは、設計、ビルド、またはデプロイメントのうち１つまたは複数の段階を含み、前記コードの種類または状態はソースコード、オブジェクトコード、バイナリコード、または抽象コード状態のうち１つまたは複数を含むことを特徴とする請求項１４に記載の方法。
16. 前記抽象状態とは、前記ターゲットコードを完全には記述しない前記ターゲットコードの設計時の分析であることを特徴とする請求項１５に記載の方法。
17. 前記ビルドフェーズは、ディスクにまだコンパイルされていない前記ターゲットコードに対して行ったバックグラウンド分析を含み、編集フェーズと、インクリメンタルビルドに対するコンパイルフェーズと、またはチェックインフェーズの前とのうち１つもしくは複数を含むことを特徴とする請求項１５に記載の方法。
18. 前記コンテクストパラメータはメタデータを使用して前記実行条件を記述し、前記メタデータは分析の完了に対する実行時の期間と、入力に対して必要な情報と、または結果の出力とのうち１つまたは複数の観点から前記選択されたルールの振る舞いも記述することを特徴とする請求項１３に記載の方法。
19. 前記コンテクストパラメータは、既存のコンテクスト条件を拡張可能なように構成可能であることを特徴とする請求項１３に記載の方法。
20. 前記カレントコード分析を考慮した前記ルールコンテクストパラメータの前記評価は、前記コード分析コンテクスト間の階層関係、前記一連の所定ルール、またはその両方を考慮することを特徴とする請求項１３に記載の方法。

Images