JP2016071895A - クラスタ化されたコード解析警告のレビューのための方法およびシステム - Google Patents

Abstract

【課題】複数の警告の報告およびレビューにおける冗長性を除去し、手作業によるレビュー労力を削減する。【解決手段】ソフトウェアコードに関連付けられた複数の警告から、複数の共通ポイント警告と、複数のユニーク警告とを特定する工程と、複数の共通ポイント警告のそれぞれの必須重複関数のトップをさらに特定する工程と、必須重複関数のトップに基づいて、複数の共通ポイント警告の１つ以上のグループを生成する工程と、必須重複関数のトップを、複数の共通ポイント警告の対応するグループ用の制約として割り当てる工程と、レビュー出力を用いて、複数の警告を、１つ以上のグループから除去する工程を含む。レビュー出力は、制約下における共通ポイント警告のレビューが、グループの残存する全ての共通ポイント警告のレビューに対応するように、制約下において１つ以上のグループからの共通ポイント警告をレビューすることにより特定される。【選択図】図４

Description

関連出願への相互参照および優先権
本出願は、２０１４年９月２９日に出願されたインド国仮特許出願番号第３１０３／ＭＵＭ／２０１４号に基づく優先権を主張する。該インド国仮特許出願の開示内容の全ては、参照により、本明細書に組み込まれる。

本発明は、一般に、プログラムコードの静的解析に基づいて生成される複数の警告のレビューに関する。特に、本発明は、クラスタ化されたコードの静的解析の間に生成される複数の警告をレビューするための方法およびシステムを提供する。

静的解析は、安全を最重視すべき（セーフティクリティカルな）アプリケーションの認証（validation）および検証（verification）において最も重要である。しかしながら、大規模アプリケーションの場合、多くのリソースを必要するため（high demand of resources）、コードの数千もの行の解析には不向きである。そのため、静的コード解析ツールにおいて、拡張性（スケーラビリティ）がボトルネックとして存在している。米国特許出願２０１２／０２９１００４Ａ１（Shrawan Kumar et. al.）は、静的解析ツールを非常に大きな規模のシステムに拡張するための技術として、クラスタ化（clustering）を開示している。

ある特定の機能を実現するソフトウェアコードは、「クラスタ」と称され、クラスタは、ソフトウェアコードの機能にエントリーする関数によって示される。クラスタは、オリジナルのソフトウェアよりも、コードサイズが小さく、よりシンプルである。静的解析ツールは、複数のクラスタを個別かつ独立して解析することによって、クラスタ固有解析結果（cluster-specific analysis results）を生成することができる。

しかしながら、クラスターコードの静的解析を実行している間、静的解析の不正確な特性およびクラスタ間通信（データ共有）のために用いられる従来のアプローチによって、膨大な数の解析警告が生成されてしまう。このような場合、警告が実際の欠陥を表すものかどうか判断するために、全ての警告を手作業でレビューする必要がある。この作業は、多大な労力と時間を要するものである。さらに、複数のクラスタに属するプログラムポイントの警告は、複数回報告される。すなわち、プログラムポイントの関連付けられた複数のクラスタのそれぞれに警告が生成される。そのため、クラスタ化されたソフトウェアコードの警告の数が増加するという問題がある。

近年、静的解析における主な研究は、静的解析をより正確にすることを目的としている。しかしながら、複数の警告のレビューの間に費やされる手作業の労力を削減することを目的とする研究が、数は少ないが行われている。本分野の現状では、静的解析ツールは、クラスタ化されたコード解析（clustered-code analysis）において、クラスタワイズ（cluster-wise:クラスタ指向、クラスタベース）に生成された複数の警告を報告するだけである。さらに、複数の共通ポイント警告（common point warnings）は、クラスタワイズにレビューされる。なぜならば、複数のクラスタのコンテキスト（context:内容）における複数の共通ポイント警告を同時にレビューするためには、複数のクラスタ間の切り替え（スイッチング）を実行することが必要であり、複数のクラスタ間の切り替えは、冗長で退屈だからである。さらに、関連付けられたクラスタのコンテキストにおける全ての共通ポイント警告を同時にレビューする間に必要とされる情報は、手作業で解析するには量が多すぎるであろうし、任意のレビュー支援ツールが使用されるとしても、そのレビュー支援ツールは、複数のクラスタに拡張できないであろう。

既存の解決法の大多数は、静的バグ報告（static bug report）において利用可能な構文的（syntactic）かつ構造的(structural)な情報を活用することにより、クラスタリングマシーン生成欠陥報告（clustering machine-generated defect reports）に基づいて、静的解析の間に生成された複数のエラー報告をグループ化することに依拠している。

しかしながら、従来技術文献は、構文的かつ構造的な情報に基づき、静的解析の間に生成された複数のエラー報告をクラスタ化（クラスタリング）することを基礎としており、そうして形成されるグループ／クラスタは、複数の異なるプログラムポイントに属する複数の警告／欠陥を含むことができるが、一般的に、複数のクラスタに属する複数の警告をグループ化することはできない。

さらに、現実のシステム（real world system）は、非常に大規模で複雑なので（通常、数百万行のコードからなる）、静的解析ツールの大部分は、現実のシステムを解析できない。クラスタ化（システムを複数のクラスタに分割すること）は、この問題を克服するために一般に用いられる技術である。

本技術では、システムコードを、複数のより小さなコードクラスタに分割することによって、解析ツールの拡張性が実現される。このような、オリジナルのシステムより小さく、よりシンプルなクラスタは、静的解析ツールによって解析され、クラスタ固有の結果（cluster-specific results）を生成する。システムのクラスタワイズ解析は、さらに、共有変数用の従来の解析による警告数の増加に繋がる。さらに、複数のクラスタに属するプログラムポイントの警告は、複数回報告される。すなわち、関連付けられた複数のクラスタのそれぞれ毎に、複数のクラスタに属するプログラムポイントの警告が報告される。そのため、クラスタ化されたコードの警告の数が増加し、膨大な数になるという問題がある。

近年の静的解析分野における主な研究は、静的解析をより正確にすることを目的とするものであり、生成された複数の警告のレビューの間に費やされる手作業による労力を削減するための研究は多くは行われていなかった。現状、複数のクラスタ化されたコード警告をレビューしている間に費やされる労力を削減することを目的とする技術／方法／システムが存在していない。

従来技術文献は、明らかに、クラスタコードソフトウェアの静的解析の間に生成された複数の警告用の効果的なレビュー技術を開示しておらず、そのため、そのような技術が本技術領域における最も大きな課題の１つとして未だ認識されている。

本発明の方法、システムおよびハードウェアの実施可能性を説明する前に、本発明は、以下説明される特定のシステムおよび方法に限定されず、本開示において明示的に説明されない本発明の複数の実施形態が存在し得ることを理解されたし。また、本開示において用いられる専門用語は、特定のバージョンまたは実施形態を説明するためにのみ用いられるものであって、本発明の範囲を限定する意図で用いられることはなく、本発明の範囲は、添付の特許請求の範囲によってのみ限定されることを理解されたし。

本出願は、複数の警告の報告およびレビューにおける冗長性（redundancy）を除去し、手作業によるレビュー労力を削減するための、クラスタ化されたソフトウェアコードに関連付けられた複数の警告の改良されたレビュー用のシステムおよび方法を提供する。

本出願は、ソフトウェアコードに関連付けられた複数の警告をレビューするためのコンピューター実施方法（computer implemented method）を提供する。実施形態の１つにおいて、該方法は、プロセッサーによって、ソフトウェアコードに関連付けられた複数の警告から、複数の共通ポイント警告および１つ以上のユニーク警告を特定する工程を含む。ソフトウェアコードは、複数のクラスタに区分け（セグメント化）され、ソフトウェアコードのクラスタワイズ解析において複数の警告が生成される。共通ポイント警告は、複数のクラスタの２つ以上のクラスタに共通している。共通ポイント警告は、コード中の単一のユニークプログラムポイントに対応していてもよく、２つ以上のクラスタ内のプログラムポイントの包含（inclusion of the program point）に起因して、複数回報告される。さらに、該方法は、プロセッサーによって、複数の共通ポイント警告のそれぞれの必須重複関数のトップ（a top of must overlapped function）を特定する工程を含む。共通ポイント警告の必須重複関数のトップは、警告プログラムポイントから、共通ポイント警告の２つ以上のクラスタに関連付けられたクラスタエントリー関数まで到達する間に必ず通過される（always traversed）トップ必須関数（top most function）である。さらに、該方法は、必須重複関数のトップに基づいて、複数の共通ポイント警告の１つ以上のグループを生成する工程を含む。さらに、該方法は、必須重複関数のトップを、複数の共通ポイント警告の対応するグループ用の制約（constraint）として割り当てる工程を含む。制約に基づくレビューは、同じグループの複数の共通ポイント警告のそれぞれのレビューに対して適用可能である。さらに、該方法は、プロセッサーによって、共通ポイント警告のレビュー出力を用いて、１つ以上のグループのそれぞれから、該共通ポイント警告以外の警告を除去する工程を含む。ここで、レビュー出力は、制約下での共通ポイント警告のレビューが、対応するグループの全ての残存共通ポイント警告のレビューに適合（satisfy）するように、１つ以上のグループのそれぞれからの共通ポイント警告をレビューすることによって特定される。

異なる実施形態によれば、本出願は、ソフトウェアコードに関連付けられた複数の警告をレビューするためのシステム（１０２）を提供する。システム（１０２）は、ソフトウェアコードに関連付けられた複数の警告から、複数の共通ポイント警告および１つ以上のユニーク警告を特定する警告解析モジュール（２１４）を備える。ソフトウェアコードは、複数のクラスタを有しており、複数の警告は、共通ポイント警告が複数のクラスタの２つ以上のクラスタに共通するように、ソフトウェアコードのクラスタワイズ解析において生成される。システム（１０２）は、複数の共通ポイント警告の必須重複関数のトップを特定するグループ特定モジュール（２１６）を備える。共通ポイント警告の必須重複関数のトップは、警告プログラムポイントから、複数の共通ポイント警告の２つ以上のクラスタに関連付けられたクラスタエントリー関数まで到達する間に必ず通過されるトップ必須関数である。さらに、グループ特定モジュール（２１６）は、必須重複関数のトップに基づいて、複数の共通ポイント警告の１つ以上のグループを生成する。さらに、システム（１０２）は、プロセッサーによって、必須重複関数のトップを、複数の共通ポイント警告の対応するグループ用の制約として割り当てる制約特定モジュール（２１８）を備える。制約に基づくレビューは、同じグループの複数の共通ポイント警告のそれぞれのレビューに対して適用可能である。また、システムは、共通ポイント警告のレビュー出力を用いて、１つ以上のグループのそれぞれから、該共通ポイント警告以外の警告を除去する警告レビューモジュール（２２６）を備える。ここで、レビュー出力は、制約下での共通ポイントのレビューが、対応するグループの全ての残存共通ポイント警告のレビューに適合するように、１つ以上のグループのそれぞれからの共通ポイント警告をレビューすることによって特定される。

さらに別の実施形態によれば、システム（１０２）のプロセッサーにより実行される命令を保存している非一時的コンピューター可読媒体（non-transitory computer readable medium）が提供される。該命令は、システム（１０２）のプロセッサーによって実行されたとき、プロセッサーによって、ソフトウェアコードに関連付けられた複数の警告から複数の共通ポイント警告および１つ以上のユニーク警告を特定するための方法をプロセッサーに実行させる。ソフトウェアコードは、複数のクラスタに区分け（セグメント化）され、複数の警告は、ソフトウェアコードのクラスタワイズ解析において生成される。共通ポイント警告は、複数のクラスタの２つ以上のクラスタに共通している。共通ポイント警告は、コード中の単一のユニークプログラムポイントに対応していてもよく、２つ以上のクラスタ内のプログラムポイントの包含に起因して、複数回報告される。さらに、該方法は、プロセッサーによって、複数の共通ポイント警告のそれぞれの必須重複関数のトップを特定する工程を含む。共通ポイント警告の必須重複関数のトップは、警告プログラムポイントから、共通ポイント警告の２つ以上のクラスタに関連付けられたクラスタエントリー関数まで到達する間に必ず通過されるトップ必須関数である。さらに、該方法は、必須重複関数のトップに基づいて、複数の共通ポイント警告の１つ以上のグループを生成する工程を含む。さらに、該方法は、必須重複関数のトップを、複数の共通ポイント警告の対応するグループ用の制約として割り当てる工程を含む。制約に基づくレビューは、同じグループの複数の共通ポイント警告のそれぞれのレビューに対して適用可能である。さらに、該方法は、プロセッサーによって、共通ポイント警告のレビュー出力を用いて、１つ以上のグループのそれぞれから、該共通ポイント警告以外の警告を除去する工程を含む。ここで、レビュー出力は、制約下での共通ポイント警告のレビューが、対応するグループの全ての残存共通ポイント警告のレビューに適合するように、１つ以上のグループのそれぞれからの共通ポイント警告をレビューすることによって特定される。

以下の好適な実施形態についての詳細な説明と同様、上述の概要は、添付の図面と共に参照されることによって、よりよく理解される。本発明の説明の目的のため、本発明の例示的な構成が図面中に示されるが、本発明は開示される特定の方法およびシステムに限定されるものではない。

図１は、本発明の実施形態に係るソフトウェアコードに関連付けられた複数の警告の改良されたレビューのためのシステムのネットワーク実施を示す図である。

図２は、本発明の実施形態に係るソフトウェアコードに関連付けられた複数の警告をレビューするためのシステムを示す図である。

図３は、本発明の例示的な実施形態に係る重複範囲チェーン（OSC: Overlapped Scope Chain）の例を示す図である。

図４は、本発明の例示的な実施形態に係るソフトウェアコードに関連付けられた複数の警告をレビューするための方法を示すフローチャートである。

本発明の全ての特徴を示す本発明のいくつかの実施形態が、詳細に説明される。

以下、「構成される」、「有する」、「含む」、「備える」およびそれらの他の形式は、同等な意味であり、これら文言は、これらの文言のいずれか１つに続く事項または複数の事項のオープンなリストを意味するが、そのような事項に限定されるような排他的でクローズドなリストを意味するものではなく、また、列挙された事項のみに限定されることを意味するものではない。

また、本明細書及び添付の特許請求の範囲において用いられる、単数形“a”、“an”、“the”は、文脈が明確に示していなければ、複数形も含むことを留意されたし。ここで説明されるシステムおよび方法と同等または対応する任意のシステムおよび方法は、本発明の実施形態の実施またはテストに使用することができ、好適例、システムおよび方法が以下に説明される。

開示される実施形態は、本発明の例示にすぎず、様々な形態で実施可能である。

以下、各実施形態において、図中に示される各要素が、より詳細に説明される。また、詳細な説明を提供する前に、以下の議論は全て、説明される特定の実施形態に関わらず、限定を示すものではなく、特徴の例示であることを留意されたし。例えば、実施形態の選択された様態、特徴またはコンポーネントがメモリー内に保存されているものとして図示されているが、用いられる警告システムおよび方法に一致するシステムおよび方法の全てまたは一部が、分散されて保存されていてもよいし、他の機械可読媒体（machine-readable media）から読み込まれてもよい。

上述の技術は、１つ以上のコンピュータープログラムにおいて実施することができる。１つ以上のコンピュータープログラムは、プログラム可能（programmable）コンピューター上で実行され（または、プログラム可能コンピューターによって実行可能であり）、プログラム可能コンピューターは、任意の数の以下の要素の組み合わせ、すなわち、プロセッサー、プロセッサーによって読み込み可能および／または書き込み可能な記憶（ストレージ）媒体（例えば、揮発性および非揮発性メモリー並びに／または記憶要素）、複数の入力ユニット、および複数の出力デバイスの任意の数の組み合わせ備えている。プログラムコードは、任意の複数の入力ユニットを用いて入力され、説明される機能を実行し、さらに、任意の複数の出力デバイス上に表示される出力を生成することができる。

以下の本発明の範囲内の各コンピュータープログラムは、任意のプログラミング言語（例えば、アセンブリ言語、機械言語、高レベル手続き型プログラミング言語、オブジェクト指向プログラミング言語）によって実施することができる。プログラミング言語は、例えば、コンパイル型またはインタプリタ型プログラミング言語であってもよい。このようなコンピュータープログラムのそれぞれは、コンピュータープロセッサーによる実行のために、機械可読記憶デバイス内に実体的に具体化された（tangibly embodied）コンピュータープログラム製品において実施される。

本発明の方法の工程は、コンピューター可読媒体上に実体的に具体化されたプログラムを実行する１つ以上のコンピュータープロセッサーによって実行され、入力を操作し、出力を生成することにより、本発明の機能を実行する。適切なプロセッサーは、例として、一般的マイクロプロセッサーおよび特殊用途のマイクロプロセッサーの双方を含む概念である。一般的に、プロセッサーは、メモリー（例えば、ＲＯＭおよび／またはＲＡＭ）から命令およびデータを受信し（読み込み）、メモリーに命令およびデータを書き込む（保存する）。記憶デバイスは、コンピュータープログラム命令およびデータを実体的に具体化するために適したものであり、例えば、ＥＰＲＯＭ，ＥＥＰＲＯＭ、フラッシュメモリー等の非揮発性メモリー（半導体メモリーデバイス等）、内部ハードディスクおよびリムーバブルディスク等の磁気ディスク、光磁気ディスクおよびＣＤ−ＲＯＭｓの全ての形態を含む。上述のうちの任意のものは、特殊設計されたＡＳＩＣｓ（Application-Specific Integrated Circuits）やＦＰＧＡｓ（Field-Programmable Gate Arrays）によって補完またはこれらに組み込まれていてもよい。また、コンピューターは、一般的に、非揮発性コンピューター可読記憶媒体（例えば、図示しない内部ディスク、リムーバブルディスク）から、プログラムおよびデータを受信し（読み込み）、非揮発性コンピューター可読記憶媒体に、プログラムおよびデータを書き込む（保存する）。

ここに開示される任意のデータは、例えば、非揮発性コンピューター可読媒体上に実体的に保存されている１つ以上のデータ構造体内で実施されている。本発明の実施形態は、このような１つまたは複数のデータ構造体内にこのようなデータを保存し、このような１つまたは複数のデータ構造体からこのようなデータを読み出す。

本出願は、ソフトウェアコードに関連付けられた複数の警告のレビューのためのコンピューター実施方法およびシステムを提供する。ソフトウェアコードは、複数のクラスタを有する。より具体的には、システムおよび方法は、複数の共通ポイント警告（common point warnings）の報告およびレビューにおける冗長性（redundancy）を除去することによって、クラスタ化されたコード解析（clustered code analysis）において生成された複数の共通ポイント警告の改良された報告およびレビューを容易にする。

図１には、本発明の実施形態に係るクラスタ化されたコード解析において生成された複数の警告の改良されたレビューのためのシステム１０２のネットワーク実施１００が示されている。本発明は、システム１０２がサーバー上に実施されているものとして説明されるが、システム１０２は、様々な演算システム（例えば、ラップトップコンピューター、デスクトップコンピューター、ノートコンピューター、ワークステーション、メインフレームコンピューター、サーバー、ネットワークサーバー）において実施されていてもよいことは理解されるであろう。実施形態の１つにおいて、システム（１０２）は、クラウドベース環境（cloud-based environment）において実施されていてもよい。システム（１０２）は、１つ以上のユーザーデバイス１０４−１、１０４−２・・・１０４−Ｎ（以下、集合的にユーザーデバイス（１０４）と称される）、またはユーザーデバイス（１０４）上に駐在するアプリケーションを介して、複数のユーザーからアクセス可能であることは理解されるであろう。ユーザーデバイス（１０４）の例としては、これに限られるものではないが、携帯型コンピューター、ＰＤＡ（Personal Digital Assistant）、ハンドヘルドデバイス、ワークステーション等が挙げられる。ユーザーデバイス（１０４）は、ネットワーク（１０６）を介して、システム（１０２）に通信可能に接続される。

実施形態の１つにおいて、ネットワーク（１０６）は、無線ネットワーク、有線ネットワーク、またはこれらの組み合わせであってもよい。ネットワーク（１０６）は、異なる種類のネットワーク（例えば、イントラネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネット等）のいずれか１つとして実施することができる。ネットワーク（１０６）は、専用ネットワークであってもよいし、共有ネットワークであってもよい。共有ネットワークは、異なる種類のネットワークの接続を意味し、様々なプロトコル（例えば、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）、トランスミッションコントロールプロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、ワイヤレスアプリケーションプロトコル（ＷＡＰ）等）を用いて、互いに通信する。さらに、ネットワーク１０６は、様々なネットワークデバイス（例えば、ルーター、ブリッジ、サーバー、演算デバイス、ストレージ装置等）を含んでいてもよい。

図２を参照して、本発明の実施形態の１つにおける、システム（１０２）の様々なコンポーネントの詳細な動作を説明する。実施例の１つにおいて、静的解析ツールは、クラスタ化されたソフトウェアコードを解析し、１つ以上の警告を生成する。複数の警告は、図示しない静的解析報告ビューワー（static analysis report viewer）を用いて報告される。静的解析報告ビューワーは、解析の間に生成された複数の警告を含む解析の出力を表示するために用いられる。

本発明の実施形態の１つにおいて、ソフトウェアコードの解析の間に生成される複数の警告は、警告解析モジュール（２１４）を用いてさらに解析される。警告解析モジュール（２１４）は、静的解析ツールによって生成された複数の警告から、複数の共通ポイント警告および複数のユニーク警告を個別に特定する。このような特定を実行するため、警告解析モジュール（２１４）は、複数の共通ポイント警告を、コード内における単一のユニークプログラムポイントに対応する複数の警告のセットとして特定するが、ソフトウェアコードの複数のクラスタ内のプログラムポイントの包含（inclusion of the program point）に起因して、該複数の共通ポイント警告を複数回報告する。複数のユニーク警告は、単一のクラスタ用に報告されるが、その他のクラスタ用には報告されない警告である。複数のクラスタにおける単一のユニークプログラムポイントの包含は、複数のクラスタ内において関数が再利用される（呼び出される）ことに起因するものである。

例えば、表１を参照すると、ｗ１警告（ゼロ除算エラーに対応する）は、ｗ１警告が再利用される関数ｆ２における同じプログラムポイントに対応するため、タスク１およびタスク２の双方用に報告される。同様に、ｗ２警告（境界外の配列インデックスのチェック（array index out bound check）に対応）も、共通ポイント警告として２回報告される。

例えば、表１を参照すると、警告ｗ１およびｗ２がそれぞれ生成される。なぜならば、静的解析機（static analyzer）は、「ｐ２」の正確な値および「＊」によって示される式を算出することができないためである。複数の共通ポイント警告における安全性またはエラーは、複数の共通ポイントに関連付けられた複数のクラスタのコンテキストに応じて変化するため、複数の共通ポイント警告のクラスタワイズ報告は、必要不可欠である。例えば、警告ｗ２は、タスク１における欠陥（配列の境界外アクセス）を表す一方、同じ警告ｗ２は、タスク２用には安全なアレイアクセスであり、その逆もまた同様である。

表１：クラスタ化されたコード解析において生成される複数の警告の例

複数のクラスタを有するソフトウェアに対するクラスタ化されたコード解析の複数の結果は、クラスタ固有（cluster-specific）である。複数の警告は、クラスタワイズに生成される。よって、クラスタ化されたコード解析によって生成された警告は、クラスタワイズにレビューされる。そのため、複数の共通ポイント警告も、クラスタワイズにレビューされる。このような複数のレビューによって、複数の共通ポイント警告のレビューにおいて冗長性が生じる。

さらに、複数の共通ポイント警告の個々の報告の後、グループ特定モジュール（２１６）は、複数の共通ポイント警告のグループ化およびグループ化された複数の共通ポイント警告の報告を容易にする。複数の共通ポイント警告および複数のユニーク警告を区別して識別し、複数の共通ポイント警告をグループ化するために、システム（１０２）のその他のコンポーネントの動作と併せて、範囲チェーン特定モジュール（scope chain identifier module）（２２０）の詳細な動作が、本発明の実施形態に従って説明される。複数の警告を生成した後、範囲チェーン特定モジュール（２２０）は、最初に、複数の関数、すなわち、複数の関数のリストを特定する。該複数の関数のリストでは、警告がレビューされている。実施形態の１つにおいて、警告の認証（validation）は、最低限のコード範囲（lowest code scope）において開始されてもよく、その後の範囲は、警告に関する決定がなされるまで、増分（increment）されてもよい。例えば、表１を参照すると、タスク１における警告ｗ２の認証は、ｆ２の範囲において開始され、意思決定（decision-making）におけるｆ２の観察の不十分さ（observing insufficiency）がある場合、範囲はｆ１まで増加され、その後、タスク１まで増加される。関数の範囲内の複数の警告をレビューするために関数にアクセス（visit）する関数は、範囲関数（scope function）と称される。

さらに、範囲チェーン特定モジュール（２２０）は、警告の手作業のレビューの間に通過される（traversed）複数の範囲関数の順序付きリスト（ordered list）を生成してもよい。例えば、（ａ）タスク２における警告２の認証は、意思決定においてタスク２の範囲を必要とするため、ｆ２→ｆ１→タスク２によって示される範囲チェーンを有しており、（ｂ）任意のクラスタの警告ｗ１の検査（inspecting）は、警告がｆ２の範囲において、それ自身が無効化（invalidate）されるので（偽の警告と特定されるので）、ｆ２→ｆ１の範囲チェーンを有する。範囲チェーンの最後における関数は、範囲関数の「トップ（top）」として参照される。例えば、ｆ１は、ｆ２→ｆ１の範囲チェーンのトップである。

１つの共通ポイント警告の複数の関連付けられたクラスタに対する共通ポイント警告の認証の間に通過された複数の範囲チェーンは、重複する（overlapped）初期部分（initial portion）を有していることが見て取れる。共通ポイント警告に関連している複数のクラスタの逆および結合コールグラフ（reversed and joint call-graph）は、複数の重複範囲チェーン（ＯＳＣｓ: Overlapped Scope chains）を算出するのに適している。例えば、図３は、複数の重複範囲チェーン（ＯＳＣｓ）を示すコールグラフのいくつかの例を示している。さらに、必須重複範囲チェーン特定モジュール（must overlapped scope chain identifier module）（２２２）は、共通ポイント警告に関連しているソフトウェアコードの複数のクラスタの逆および結合コールグラフから、複数の重複範囲チェーン（ＯＳＣｓ）を特定することができる。図３（ａ）は、表１内のコードサンプルに対応し、ｆ２→ｆ１が、双方のクラスタに対する警告ｗ１（または警告ｗ２）の検査の間のＯＳＣであることを示している。さらに、共通ポイント警告は、複数のＯＳＣｓを有することができ、図３（ｂ）に示す例では、ｆ３→ｆ１の範囲チェーンおよびｆ３→ｆ２の範囲チェーンの双方がＯＳＣｓである。

さらに、必須重複範囲チェーン特定モジュール（２２２）は、複数の共通ポイント警告に対応する複数の必須重複範囲チェーン（必須ＯＣＳｓ：must-OSCs）を特定してもよい。もし、（ａ）複数の共通ポイント警告に関連付けられた複数のクラスタの複数のエントリー関数の全てが厳密にＯＳＣのトップから到達可能であり、さらに、（ｂ）これらエントリー関数がトップを通過しない警告関数から到達可能ではない場合、最大長のＯＳＣは、必須ＯＳＣとして参照される。例えば、図３（ａ）中のｆ２→ｆ１と、図３（ｂ）中のＯＳＣｓの双方（ｆ３→ｆ１およびｆ３→ｆ２）は、必須ＯＳＣｓである。図３（ｃ）は、図３（ｃ）のクラスタの単一の必須ＯＳＣとしてｆ２を有している。

実際、全てのクラスタは、コードの数千もの行に及ぶ（span）ものであり、複数のクラスタ間で再利用される数百もの関数への複数の呼び出し（コール）を含んでいる。複数の共通ポイント警告を検査している間、レビュワー（reviewer）は、通常、必須ＯＳＣｓを認識していない。そのため、複数のＯＳＣｓの手作業のチェックを繰り返すことになり、冗長な労力をかけることに繋がってしまう。複数のＯＳＣｓの反復される手作業のチェックの冗長性は、複数の共通ポイント警告のシステマティック（系統的）なグループ化を通じて除去される。

複数の共通ポイント警告のグループ化は、１）複数の警告がユニークであるか、複数のクラスタに対して共通であるかを区別して識別する工程と、２）複数のユニークな警告をクラスタワイズに報告し、さらに、共通ポイント警告を共にクラスタワイズにグループ化し、報告する工程と、３）各グループ毎に、複数のグループ化された共通ポイント警告に関連付けられた各必須ＯＳＣのトップと長さ（範囲関数の数）を報告する工程と、を含んでいてもよい。

複数の共通ポイント警告の必須重複範囲チェーン（必須ＯＳＣｓ）を特定した後、グループ特定モジュール（２１６）は、複数の共通ポイント警告を１つのグループにグループ化する。グループ特定モジュール（２１６）は、必須重複範囲チェーンのトップに基づいて、複数の共通ポイント警告をグループ化する。必須ＯＳＣのトップは、複数の共通ポイント警告のプログラムポイントから、複数の共通ポイント警告の２つ以上のクラスタに関連付けられた複数のクラスタエントリー関数に到達するまでの間に、必ず通過されるトップ必須関数（top most function）である。さらに、制約特定モジュール（２１８）は、そうして形成されたグループのそれぞれ用の制約を特定する。特定された制約は、警告プログラムポイントから、関連付けられたクラスタのそれぞれのエントリーポイント／関数まで到達する間に必ずアクセス（visit）される必須ＯＳＣのトップ必須関数であってもよい。制約特定モジュール（２１８）は、警告レビューモジュール（warning reviewer module）（２２６）によって生成されたレビュー出力が、共通ポイント警告用のレビュー出力を用いて、１つ以上のグループのそれぞれから、該共通ポイント警告以外の複数の警告を除去できるように、そうして形成されたグループのそれぞれ用の制約を報告する。ここで、レビュー出力は、該制約下での共通ポイント警告のレビューが、対応するグループの残存する全ての共通ポイント警告のレビューに対して適用可能となるように、該制約下で１つ以上のグループのそれぞれからの共通ポイント警告をレビューすることにより特定される。所与の制約下において、警告を判別(judge)できないとき、グループ特定モジュール（２１６）は、同じグループのその他の警告をレビューしている間に、レビュー情報のいくつかの部分を記録(log)し、再利用することを容易にする。

さらに、システム（１０２）は、１つ以上のグループの１つの共通ポイント警告用に生成されたレビュー出力が安全であると判断される場合、その後、警告レビューモジュール（２２６）が同じグループのその他の全ての共通ポイント警告、すなわち、グループの全ての警告を除去し、同じグループの全ての警告を自動的に安全な警告であると判断する。

表２：複数の共通ポイント警告の複数のグループの報告

さらに、サブグループ特定モジュール（２２４）は、複数の共通ポイント警告の複数のグループを、複数のサブグループに区分けしてもよい。複数のサブグループは、複数のサブグループの必須重複範囲チェーンのトップに個々に関連付けられている。複数のサブグループは、各サブグループに関連付けられた個別の制約を有しており、サブグループ化は、グループ化技術から最大の利益（maximum benefits）を受け取るようになされる。グループ化アプローチから最大の利益を得るために、複数の共通ポイント警告は、複数のサブグループの複数の必須ＯＳＣｓの長さに基づいて、複数のサブグループに、さらに区分けされる。表２は、図３（ｄ）内の４つの共通ポイント警告（ｗ５）に対応する２つのサブグループの例をも示している。クラスタであるタスク１、タスク２、タスク３およびタスク４内の複数の警告は、それぞれの必須ＯＳＣｓの長さが異なるため、複数のそれぞれ異なるサブグループ内に配置される。各サブグループに対応するトップも報告される。

さらに、システム（１０２）は、複数の共通ポイント警告の複数のグループおよび複数のサブグループの改良されたレビューを可能とする。共通ポイント警告の検査の間、（ａ）もし、警告が、該警告のグループ用に報告された任意のトップ間を横断せず(without crossing any of tops)、誤判定（false positive）と判断される場合、グループ化されたその他の全ての警告もまた誤判定であり、それらは一度に除去される。（ｂ）もし、（ａ）でなく、さらに、警告が、該警告のサブグループのトップ間を横断せず、無効化される場合、該警告のサブグループの全ての警告は、共に除去される。（ｃ）もし、（ａ）および（ｂ）の双方に該当しない場合、ユーザーは、複数のトップ関数において利用可能なレビュー情報を記録（log）し、さらに、後に、残りの複数の共通ポイント警告（rest common point warnings）が、それらの関連する複数のクラスタのコンテキストにおいてレビューされるとき、レビュー情報を再利用することができる。例えば、タスク１の警告２（表１のグループ１）のレビューの間、レビュワーは、警告判断が「ｐ」に依存することを記録することができる。記録された情報は、タスク２の警告２をレビューする間に再利用することが可能であり、それにより、ユーザーが、呼び出し（コール）から、ｆ１関数までの検査を開始することを支援することができる。このように、レビュー情報の記録によっても、レビューの冗長性のいくつかを回避することができる。

表３には、システム（１０２）の実施の実験結果が提供されている。提案のグループ化技術が適用され、レビュー労力の削減におけるグループ化技術の影響がチェックされる。Ａｐｐ（アプリケーション）１は、１４ＭＬＯＣのコードサイズを有し、平行して実行される９８個のクラスタから構成されるインフォテインメント（infotainment：情報と娯楽の双方を提供するプログラムの形態）システムである。これらのクラスタは、４ＫＬＯＣから７００ＫＬＯＣのサイズを有しており、これら複数のクラスタは、合計３１２８８個の関数から構成されている。３１２８８個の関数のうち、９３２７個は、複数のクラスタ間で再利用される。Ａｐｐ２は、２９個のクラスタ内に分配された（１０ＫＬＯＣのサイズの）組み込みシステム（embedded system）である。組み込みシステムは、８３個の関数に及ぶものであり、これらのうち１４個の関数が再利用される。アプリケーションＡｐｐ１およびＡｐｐ２は、ゼロ除算（ＺＤ：Zero Division）、境界外の配列インデックス（ＡＩＯＢ：Array Index Out of Bound）、ポインタの不正な逆参照（ＩＤＰ：Illegal Dereference of a Pointer）およびオーバーフロー―アンダーフロー（ＯＦＵＦ：OverFlow-UnderFlow）に関して検証（verified）される。これらチェック項目は、ソフトウェア検証に共通するチェック特性である。実験結果が表３に示されている。表３中のグループＡＬＭおよびサブグループＡＬのような列は、形成された複数のグループに関連付けられた複数の必須ＯＳＣｓの平均長を意味する。

表３：実験結果

表３において提供された結果から得られたいくつかの観察が、以下にリストされる。（１）全警告の約４５％は、共通ポイント警告としてグループ化され、それらのうち、１８％のみがユニークである。（２）形成されたグループの高い割合（２５％）が、５個以上の警告を含んでいる。（３）グループの約６％は、複数のトップを有しており、これは、複数のトップを有する複数のグループのこれら警告のレビューには、単一のトップを有するグループ化された複数の警告をレビューするための労力よりも、より多くの労力が必要であることを示している。（４）複数のサブグループのＡＬＭは、複数のグループのＡＬＭよりも常に大きい。なぜならば、グループの必須ＯＳＣｓは、グループのサブグループの複数の必須ＯＳＣｓに含まれるからである。

表４：手作業によるレビュー結果

グループ化技術の影響をチェックするため、それぞれ異なるグループに属する１８０個の警告がランダムに選択され、手作業でレビューされる。表４は、複数の警告の複数のグループのレビュー結果を示している。この結果は、以下を示している。（１）１３１個の警告のレビューが、合計で５１７個の警告の除去に繋がった。（２）約６６％のグループ（１８０個のうち、１１９個）が、各グループからの単一の警告を検査するだけで除去された。（３）トップレベルのグループ化（top level grouping）がいくつかの警告を除去していない場合、サブグループ化がその除去されない警告の除去に有用であった。（４）３３個の警告を検査している間に収集されたレビュー情報が、その他の４２個の警告をレビューする間に再利用された。労力削減についてのグループ化技術の影響をチェックするため、上記１８０個のグループに属する６４０個の警告が以下の２つの異なる設定でレビューされた。（１）個別のレビュー（グループ化なし）、（２）グループベースのレビュー（groups-based reviewing）。

この実験は、レビュー労力の約５０％〜７０％が、グループベースの警告除去、レビュー情報の記録および再利用によって削減されたことを示している。この削減は、レビュワーの能力、用いる支援ツール、コードの事前知識等によって変化することがわかっている。なお、クラスタにユニークな警告は、グループ化の対象ではないため、達成された削減は、共通ポイント警告のみに対するものであることに留意されたし。

本開示は、警告の高い割合（約４５％）が共通ポイント警告として観察されることを開示しているが、これは、ソフトウェアアプリケーションが多くのコードを再利用するためである。多くのコードの再利用に起因して、多くの警告が複数回報告される。解析結果がクラスタ固有（cluster-specific）であっても、全ての警告を個別にレビューする必要がないことが実証された。複数の警告の関連付けられた複数のタスクのコンテキスト内の複数の警告を個別にレビューする間に発生した冗長性は、複数の警告のグループ化によって除去される。本開示の主な寄与は、必須ＯＳＣｓベースのグループ化基準を特定すること、各グループの特定された必須ＯＳＣｓのトップを報告すること、および、必須ＯＳＣｓを警告レビュープロセスの一部とすることにある。実験は、形成されたグループの合計の約６６％が、各グループからの単一の警告をレビューするだけで除去されることを明らかにしている。グループベースの除去、および、トップ関数における警告に対する決定を成すことができない場合のレビュー情報の記録は、合計で６０％の手作業労力の削減に繋がる。

グループ化アプローチを用いない場合、削減される不必要な労力が、同じコードを複数回検査するために費やされるであろう。さらに、実験結果は、第１のレベルのグループ化がいくつかの警告を除去しない場合、サブグループ化がその除去されない警告の除去に有用であることも実証している。ＡＩＯＢ、ＺＤ、ＯＦＵＦおよびＩＤＰ特性が実験の中で検討されたが、提案のグループ化技術は、初期化されていない変数（un-initialized variables）のようなその他の特性用に生成された警告にも適用することが可能である。「Ｃ」言語で記載された組み込みドメインアプリケーション（embedded domain application）を実験に用いられたか、一般的に用いられているコーディング慣習（common coding practices）によって、その他のドメイン／言語のアプリケーションと同様の同じような利益が得られることが予見される。

実施形態の１つにおいて、本開示のシステム１０２は、必須重複範囲チェーンを算出する技術を提供する。必須重複範囲チェーンを算出するため、システム１０２は、アプリケーションコールグラフを構築する。レビュー（グループ化）制約の算出は、必須重複範囲チェーンのトップの関数の適合性（suitability）（すなわち、制約）のために、共通ポイント警告関数が呼び出される全ての関数のチェックを行う必要がある。そのため、本開示において開示される技術は、非常に短い時間でレビュー（グループ化）制約を算出する軽量技術（light weight technique）である。本システム１０２によるＧＵＩ／インターフェースは、ユーザーフレンドリーであり、重要情報をターゲティング提供（targeting presentation）し、ユーザーがレビュー情報を記録し、再利用することを可能とする。本開示のシステムおよび方法を用いることにより、複数の共通ポイント警告のレビューにおいて必要とされる手作業のレビュー労力の約６０％が削減される。

上述の例示的な実施形態は、複数の利点を提供することができる。本開示の様態で実施されることは必須ではなく、これら利点は、以下の特徴によって提供される利点を含んでいてもよい。

いくつかの実施形態は、システムおよび方法が、複数の共通ポイント警告と複数のユニーク警告とを区別して識別し、さらに、複数のユニーク警告および複数の共通ポイント警告の報告を分離することを可能とする。

いくつかの実施形態は、システムおよび方法が、複数の共通ポイント警告の報告およびレビューにおける冗長性を除去することにより、クラスタ化されたコード解析において発生した複数の共通ポイント警告の改良された報告およびレビューを容易とすることを可能とする。

いくつかの実施形態は、システムおよび方法が、複数の共通ポイント警告をレビューしている間に、ユーザーに有用なレビュー支援情報を記録し、後に提供することを容易にすることを可能とする。

いくつかの実施形態は、システムおよび方法が、必須重複範囲チェーンのトップ、並びに、複数の共通ポイント警告の複数のグループおよび複数のサブグループの制約ベースのレビューに基づいて、複数の共通ポイント警告をグループ化およびサブグループ化することにより、複数の共通ポイント警告のレビューにおける冗長性を排除し、レビュー労力を削減することを容易とすることを可能とする。

図４には、クラスタ化されたコード解析において生成された複数の警告の改良されたレビューのための工程を含む方法を説明するフローチャートが、本発明の実施形態にしたがって、示されている。

該方法は、一般に、コンピューター実行可能命令の観点から、記述することができる。一般的に、コンピューター実行可能命令は、特定の機能を実行または特定の抽象データ型（abstract data types）を実施するルーティーン（routines）、プログラム、オブジェクト、コンポーネント、データ構造、プロシージャー(procedures)、モジュール、関数等を含む。また、図４の方法は、通信ネットワークを介してリンクされた複数の遠隔処理デバイスによって機能が実行される分散型演算環境（distributed computing environment）内において実施されてもよい。分散型演算環境内では、コンピューター実行可能命令は、ローカルコンピューター記憶媒体およびメモリー保存デバイス等の遠隔コンピューター記憶媒体の双方内に位置していてもよい。

該方法が説明される順番は、限定を構築する意図はなく、任意の数の説明される方法のブロックが任意の順番で組み合され、図４に示す方法または任意の代替的方法を実施することができる。さらに、個々のブロックが、ここに説明される本発明の原理および範囲から逸脱することなく、図４に示す方法から削除されてもよい。さらに、該方法は、任意の適切なハードウェア、ソフトウェア、ファームフェア、およびこれらの組み合わせにおいて実施することができる。しかしながら、説明の簡略化のため、以下に説明される実施形態では、図４の方法は、上述のシステム（１０２）において実施されているものとして考える。

工程（４０２）において、処理が開始する。ここで、複数の警告が解析され、該複数の警告がそれぞれユニーク警告もしくは共通ポイント警告として特定される。特定された共通ポイント警告は、２つ以上のクラスタに共通する複数の警告のセット（共通ポイント警告）であり、特定されたユニーク警告は、単一のクラスタ用にのみ報告された警告である。

工程（４０４）において、複数の警告のそれぞれがユニーク警告であるか、各クラスタの共通ポイント警告であるかの判別が行われる。このように警告が特定されると、特定された警告がユニーク警告の場合は、工程（４０６）において報告され、特定された警告が共通ポイント警告の場合は、工程（４０８）においてそれぞれ報告される。

工程（４１０）において、工程（４０８）において報告された複数の共通ポイント警告がグループ化される。実施形態の１つにおいて、複数の共通ポイント警告のグループ化は、工程（４０４）に示されているように、（１）複数の警告がユニークであるか、複数のクラスタに共通であるかを区別して識別する工程と、（２）複数のユニーク警告をクラスタワイズに報告し、さらに、複数の共通ポイント警告を共にグループ化し、報告する工程と、（３）各グループ毎に、グループ化された複数の共通ポイント警告に関連付けられた各必須重複範囲チェーンのトップおよび長さ（範囲関数の数）を報告する工程と、を含む。

工程（４１２）において、工程（４１０）において形成された複数の共通ポイント警告の各グループにおける複数の警告のレビューのために、制約が特定される。特定された制約は、警告プログラムポイントから、関連付けられた複数のクラスタのそれぞれのエントリーポイント／関数まで到達するまでの間に必ずアクセス（visit）されるトップ必須関数であってもよい。

工程（４１４）において、レビュー判断を示すレビュー出力が、所与の制約下におけるグループ化された１つの警告のレビュー判断が、同じグループの他の全ての警告のレビューに対して適用可能となるように、生成される。この方法は、グループ内の１つの警告のみのレビューを必要とするものである。さらに、所与の制限下において、警告を判断することができない場合、関連付けられたトップ関数において利用可能なレビュー情報が記録されてもよく、さらに、同じグループにおけるその他の複数の警告をレビューする間にレビュー情報の全部またはいくつかの部分が用いられてもよい。

工程（４１６）において、処理は終了する。工程（４１４）において生成されたレビュー判断は、同じグループのその他の複数の警告が安全な警告（safe warnings）であるか、偽警告（false warnings）であるかを判断するために用いられる。

グループ化アプローチから最大の利益を得るために、複数の共通ポイント警告は、さらに、必須ＯＳＣｓの長さに基づいて、複数のサブグループに区分けされてもよい。さらに、図４に示す方法は、複数の共通ポイント警告の複数のグループ（１つのグループ内の複数の警告）を、複数のサブグループに区分けする工程を含む。図４の方法は、複数の共通ポイント警告の複数のグループを、各サブグループに対応する必須重複範囲チェーンのトップに個別に関連付けられた複数のサブグループに区分けする工程を含む。

共通ポイント警告の検査の間、（ａ）もし、警告が、該警告のグループ用に報告された任意のトップ間を横断せず、誤判定と判断される場合、グループ化されたその他の全ての警告もまた誤判定であり、それらは一度に除去される。（ｂ）もし、（ａ）でなく、さらに、警告が、該警告のサブグループのトップ間を横断せず、無効化される場合、該警告のサブグループの全ての警告は、共に除去される。（ｃ）もし、（ａ）および（ｂ）の双方に該当しない場合、ユーザーは、複数のトップ関数において利用可能なレビュー情報を記録し、さらに、後に、残りの複数の共通ポイント警告が、それらの関連する複数のクラスタのコンテキストにおいてレビューされるとき、レビュー情報を再利用することができる。

図４の方法は、１つ以上のグループの１つの共通ポイント警告用のレビュー出力が安全と判断された場合、その後、プロセッサーを用いて、同じグループのその他の全ての共通ポイント警告を除去することができる。すなわち、グループの全ての警告を、自動的に安全な警告と判断することができる。

さらに、図４の方法は、関連付けられた複数の制約と共に、複数の共通ポイント警告、複数の共通ポイント警告のグループ、および複数の共通ポイント警告の複数のグループの複数のサブグループの全てを有する報告を生成する工程を含んでいてもよい。

クラスタ化されたコード解析において生成された複数の警告の改良されたレビューのための方法およびシステムの実施形態が、特定の構造的特徴および／または方法の文脈において説明されたが、添付の特許請求の範囲は、説明された特定の特徴または方法に必ずしも限定されないことに留意されたい。むしろ、特定の特徴および方法は、クラスタ化されたコード解析において生成された複数の警告の改良されたレビューのための実施形態の例示として開示されたにすぎない。

Claims (14)

1. ソフトウェアコードに関連付けられた複数の警告をレビューするための方法であって、
   プロセッサーによって、
   複数のクラスタを有する前記ソフトウェアコードに関連付けられ、前記ソフトウェアコードのクラスタワイズな静的解析において生成された前記複数の警告から、前記複数のクラスタの２つ以上のクラスタに共通する複数の共通ポイント警告と、１つ以上のユニーク警告と、を特定し、さらに、
   警告プログラムポイントから、前記複数の共通ポイント警告の前記２つ以上のクラスタに関連付けられたクラスタエントリー関数まで到達するまでの間に必ず通過されるトップ必須関数である前記複数の共通ポイント警告のそれぞれの必須重複関数のトップを特定する工程と、
   前記プロセッサーによって、前記必須重複関数の前記トップに基づいて、前記複数の共通ポイント警告の１つ以上のグループを生成する工程と、
   前記プロセッサーによって、前記必須重複関数の前記トップを、前記複数の共通ポイント警告の対応するグループ用の制約として割り当てる工程であって、
   前記制約に基づくレビューは、同じグループの前記複数の共通ポイント警告のそれぞれのレビューに適用可能である、割り当てる工程と、
   前記プロセッサーによって、共通ポイント警告用のレビュー出力を用いて、該共通ポイント警告以外の複数の警告を、前記１つ以上のグループのそれぞれから除去する工程であって、
   前記レビュー出力は、前記制約下における前記共通ポイント警告のレビューが、対応する前記グループの残存する全ての共通ポイント警告のレビューに対して適用可能となるように、前記制約下において前記１つ以上のグループのそれぞれからの前記共通ポイント警告をレビューすることによって特定される、除去する工程と、を含むことを特徴とする方法。
2. 前記複数の警告は、静的解析ツールを用いた前記ソフトウェアコードのクラスタワイズな静的解析において生成される請求項１に記載の方法。
3. 前記共通ポイント警告は、前記２つ以上のクラスタにおける前記プログラムポイントンの包含に起因して、複数回報告される前記ソフトウェアコード内の単一のユニークプログラムポイントに対応する請求項１に記載の方法。
4. 前記複数の共通ポイント警告のそれぞれの前記必須重複関数のトップを特定する工程は、さらに、
   前記プロセッサーによって、１つ以上の範囲関数チェーンを特定する工程であって、
   前記１つ以上の範囲関数チェーンは、複数の関数間のチェーンであり、前記関数は、前記複数の関数間の前記チェーンのクラスタエントリー関数から呼び出され、前記複数の関数は、警告のレビューの間に通過される、前記１つ以上の範囲関数チェーンを特定する工程と、
   前記プロセッサーによって、前記１つ以上のグループのそれぞれの１つ以上の必須重複範囲チェーンを特定する工程であって、
   前記１つ以上の必須重複範囲チェーンは、前記１つ以上のグループのそれぞれの共通ポイント警告をレビューする間に必ず通過される前記１つ以上の範囲関数チェーンの一部である、前記１つ以上の必須重複範囲チェーンを特定する工程と、を含む請求項１に記載の方法。
5. 前記複数の共通ポイント警告の前記１つ以上のグループを分割することによって、１つ以上のサブグループを生成する工程をさらに含み、
   前記複数の共通ポイント警告の前記サブグループを生成する工程は、前記必須重複関数の第２のトップが、警告プログラムポイントから、前記サブグループ内の前記複数の警告に関連付けられた前記複数のクラスタの複数のクラスタエントリー関数まで到達するまでの間に必ず通過されるトップ必須関数となるように、前記必須重複関数の前記第２のトップに基づいて行われる請求項１に記載の方法。
6. 前記プロセッサーによって、前記制約が、前記１つ以上のサブグループのそれぞれの警告の全てのレビューに適用可能となるように、前記１つ以上のサブグループのそれぞれ用の第２の制約を示す第２の出力を生成する工程を含む請求項５に記載の方法。
7. ソフトウェアコードに関連付けられた複数の警告をレビューするためのシステムであって、
   プロセッサーと、
   複数のクラスタを有する前記ソフトウェアコードに関連付けられ、前記ソフトウェアコードのクラスタワイズな解析において生成された前記複数の警告から、前記複数のクラスタの２つ以上のクラスタにおいて共通する複数の共通ポイント警告と、１つ以上のユニーク警告と、を特定する警告解析モジュールと、
   警告プログラムポイントから、前記複数の共通ポイント警告の前記２つ以上のクラスタに関連付けられた複数のクラスタエントリー関数まで到達するまでの間に必ず通過されるトップ必須関数である前記複数の共通ポイント警告のそれぞれの必須重複関数のトップを特定し、さらに、
   前記必須重複関数の前記トップに基づいて、前記複数の共通ポイント警告の１つ以上のグループを生成するグループ特定モジュールと、
   前記必須重複関数の前記トップを、前記複数の共通ポイント警告の対応するグループ用の制約として割り当てる制約特定モジュールであって、
   前記制約に基づくレビューは、同じグループの前記複数の共通ポイント警告のそれぞれのレビューに適用可能である、制約特定モジュールと、
   共通ポイント警告用のレビュー出力を用いて、該共通ポイント警告以外の複数の警告を、前記１つ以上のグループのそれぞれから除去する警告レビューモジュールであって、
   前記レビュー出力は、前記制約下における前記共通ポイント警告のレビューが、対応する前記グループの残存する全ての共通ポイント警告のレビューに対して適用可能となるように、前記制約下において前記１つ以上のグループのそれぞれからの前記共通ポイント警告をレビューすることによって特定される、警告レビューモジュールと、を含むことを特徴とするシステム。
8. １つ以上の範囲関数チェーンを特定する範囲チェーン特定モジュールであって、
   前記１つ以上の範囲関数チェーンは、複数の関数間のチェーンであり、前記関数は、前記複数の関数間の前記チェーンのクラスタエントリー関数から呼び出され、前記複数の関数は、警告のレビューの間に通過される、範囲チェーン特定モジュールと、
   前記１つ以上のグループのそれぞれの１つ以上の必須重複範囲チェーンを特定する必須重複範囲チェーン特定モジュールであって、
   前記１つ以上の必須重複範囲チェーンは、前記１つ以上のグループのそれぞれの共通ポイント警告をレビューする間に必ず通過される前記１つ以上の範囲関数チェーンの一部である、必須重複範囲チェーン特定モジュールと、をさらに含む請求項７に記載のシステム。
9. 前記複数の共通ポイント警告の前記１つ以上のグループを分割することによって、１つ以上のサブグループを生成するサブグループ特定モジュールをさらに含み、
   前記複数の共通ポイント警告のグループ化は、前記必須重複関数のトップが、前記複数の警告プログラムポイントから、それぞれの前記クラスタエントリー関数まで到達するまでの間に必ず通過されるトップ必須関数となるように、前記必須重複関数の前記トップに基づいて行われる請求項８に記載のシステム。
10. 前記制約特定モジュールは、さらに、前記制約が、前記１つ以上のサブグループのそれぞれの警告の全てのレビューに適用可能となるように、前記１つ以上のサブグループのそれぞれ用の第２の制約を示す第２の出力を生成するよう構成されている請求項９に記載のシステム。
11. システム上のプロセッサーによって実行されたとき、前記プロセッサーに以下の方法を実行させる命令を保存している非一時的コンピューター可読媒体であって、該方法は、
    プロセッサーによって、
    複数のクラスタを有する前記ソフトウェアコードに関連付けられ、前記ソフトウェアコードのクラスタワイズな静的解析において生成された前記複数の警告から、前記複数のクラスタの２つ以上のクラスタに共通する複数の共通ポイント警告と、１つ以上のユニーク警告と、を特定し、さらに、
    警告プログラムポイントから、前記複数の共通ポイント警告の前記２つ以上のクラスタに関連付けられたクラスタエントリー関数まで到達するまでの間に必ず通過されるトップ必須関数である前記複数の共通ポイント警告のそれぞれの必須重複関数のトップを特定する工程と、
    前記プロセッサーによって、前記必須重複関数の前記トップに基づいて、前記複数の共通ポイント警告の１つ以上のグループを生成する工程と、
    前記プロセッサーによって、前記必須重複関数の前記トップを、前記複数の共通ポイント警告の対応するグループ用の制約として割り当てる工程であって、
    前記制約に基づくレビューは、同じグループの前記複数の共通ポイント警告のそれぞれのレビューに適用可能である、割り当てる工程と、
    共通ポイント警告用のレビュー出力を用いて、該共通ポイント警告以外の複数の警告を、前記１つ以上のグループのそれぞれから除去する工程であって、
    前記レビュー出力は、前記制約下における前記共通ポイント警告のレビューが、対応する前記グループの残存する全ての共通ポイント警告のレビューに対して適用可能となるように、前記制約下において前記１つ以上のグループのそれぞれからの前記共通ポイント警告をレビューすることによって特定される、除去する工程と、を含むことを特徴とする非一時的コンピューター可読媒体。
12. 前記方法は、前記プロセッサーによって、１つ以上の範囲関数チェーンを特定する工程であって、
    前記１つ以上の範囲関数チェーンは、複数の関数間のチェーンであり、前記関数は、前記複数の関数間の前記チェーンのクラスタエントリー関数から呼び出され、前記複数の関数は、警告のレビューの間に通過される、前記１つ以上の範囲関数チェーンを特定する工程と、
    前記プロセッサーによって、前記１つ以上のグループのそれぞれの１つ以上の必須重複範囲チェーンを特定する工程であって、
    前記１つ以上の必須重複範囲チェーンは、前記１つ以上のグループのそれぞれの共通ポイント警告をレビューする間に必ず通過される前記１つ以上の範囲関数チェーンの一部である、前記１つ以上の必須重複範囲チェーンを特定する工程と、をさらに含む請求項１１に記載の非一時的コンピューター可読媒体。
13. 前記方法は、前記プロセッサーによって、前記複数の共通ポイント警告の前記１つ以上のグループを分割することによって、１つ以上のサブグループを生成する工程をさらに含む請求項１１に記載の非一時的コンピューター可読媒体。
14. 前記方法は、前記プロセッサーによって、前記制約が、前記１つ以上のサブグループのそれぞれの警告の全てのレビューに適用可能となるように、前記１つ以上のサブグループのそれぞれ用の第２の制約を示す第２の出力を生成する工程を含む請求項１３に記載の非一時的コンピューター可読媒体。

Images