JP2010117897A - プログラム静的解析システム - Google Patents

Abstract

【課題】ルールの重要度を不具合の発生と連携させることによって、実際に稼動しているプログラムでの不具合発生を未然に防ぐことに貢献できるプログラム静的解析システムを提供することを目的とする。
【解決手段】複数のフェーズの各段階でソースプログラムを編集しながら、フェーズを進めていくことでソースプログラムの開発を行う際に、各フェーズでの修正によって解消された指摘の件数に重み付けを行い、コーディングルールの重要度を、より後のフェーズのプログラム修正によって改善されたルールの重要度を上げるように、フェーズに応じた重み付けを行って変更する。これにより、プログラム開発者がプログラム修正の順序を決定する際に、不具合発生を回避する可能性の高い修正から行えるようになり、プログラムに対する不具合混入の度合いを減少させることに役立つ。
【選択図】図１

Description

本発明は、プログラム開発時において、ソースコードの解析を自動的に行い、不具合の可能性のある部分を指摘するプログラム静的解析の技術に関し、特に、静的解析結果に伴う不具合の修正の実施結果に伴って、不具合修正の必要性に対する重要度を変更することで、プログラム開発者のプログラム修正に対する順序付けの判断等を支援するための技術に関する。

プログラム開発においては、従来から、担当者が開発したソースプログラムを経験者がレビューすることで、コーディング基準からの逸脱を防ぎ、不具合の発生率を減少させるための努力がされてきている。しかしながら、プログラム開発期間の短縮に伴い、レビュー時間が短縮され、全てのソースコードのレビューが実施されなくなったうえ、開発費用の削減のために開発単価の安い海外ベンダで開発させるケースも増加し、その場合、開発時の仕様理解不足に伴う多数の不具合の混入などが問題になってきた。

この問題の解決を目的として、プログラム静的解析システムが開発されてきている。プログラム静的解析システムは、各プログラムがコーディング基準に則って作成されているかを、ソースコードレベルでチェックするシステムである。プログラム静的解析システムでは、不具合が発生しやすいコーディングが混入していないかどうかを自動的に解析することで、ソースコード全体のレビューを実施することに該当する機能を提供するとともに、問題のあるソースコードの場所を明示的に表示することで、修正すべき箇所が明確にわかるようになっている（特許文献１参照）。

静的解析に使用するコーディング基準に対するルールには、不具合に直結するものや、保守性の向上のためにコーディングスタイルを統一するものなど、様々な種類がある。一般的に、ルールに重要度を設け、重要度の高いルールを満たしていないことに対する指摘があるソースコードを優先して修正することが推奨されている。しかしながら、ルールの重要度は、熟練者の意見や開発部門の意思に基づいて設定されるため、不具合の発生と直結せずに決定されてきていた。この問題を解決するために、ソースコードの修正前と修正後での各ルールの指摘件数の減少率を用いてルールの重要度を決定する技術が、例えば特許文献２に記載されている。
特開２００４−１４５３８１号公報 特開２００８−５２４２４号公報

しかしながら、上記特許文献１に記載の技術では、ルールに重要度がないために、多数のルールを使用した場合に、どのルールの指摘に対して修正すべきかを判断する基準がなく、開発者または管理者の基準に則ってソースプログラムを修正することになってしまい、不具合混入の度合いを減少させるためには機能が不足している。

また、上記特許文献２に記載の技術は、上記特許文献１で不足している機能を補うことを目的として開発されているが、単純に指摘の減少率だけで重要度を決める方法では、コーディングスタイルの統一のために全てのソースコードを修正した場合など、不具合の発生可能性とは無関係に実施された修正に伴う高い減少率を示したルールの重要度が高くなり、開発者にとって不具合の発生を防ぐことに貢献しない場合が発生する。

本発明の目的は、ルールの重要度を不具合の発生と連携させることによって、実際に稼動しているプログラムでの不具合発生を未然に防ぐことに貢献できるプログラム静的解析システムを提供することである。

上記目的を達成するために、本発明は、複数のフェーズの各段階でソースプログラムを編集しながら、フェーズを進めていくことでソースプログラムの開発を行う際に、前記各フェーズにおいてソースプログラムを解析し、コーディングルールに即したコーディングが実施されていない箇所を指摘するプログラム静的解析システムであって、複数のコーディングルールを、各ルールの重要度とともに、格納したルール格納手段と、前記ルール格納手段に格納されているコーディングルールを用いて、指定されたフェーズのソースプログラムを解析し、前記コーディングルールを満たしていない箇所を求める静的解析手段と、前記静的解析手段で前記コーディングルールを満たしていないと指摘された箇所について、前記コーディングルール毎の指摘件数を求め、求めたコーディングルール毎の指摘件数を記憶する手段と、前回の静的解析で記憶した前記コーディングルール毎の指摘件数と今回の静的解析で記憶した前記コーディングルール毎の指摘件数とを比較し、コーディングルール毎にその減少分を求める手段と、前記コーディングルール毎に、前記減少分がより大きく、前記指定されたフェーズがより後のフェーズである場合に、より高い重要度となるように、前記ルール格納手段に格納されている当該コーディングルールに対応する重要度を変更する重要度変更手段と、前記静的解析手段により求めた前記ソースプログラム中のコーディングルールを満たしていない箇所を、そのコーディングルールの重要度とともに、表示する手段とを備えることを特徴とする。

特に、コーディングルールの重要度を、より後のフェーズのプログラム修正によって改善されたルールの重要度を上げるように、フェーズに応じた重み付けを行って変更する。例えば、テスト工程のフェーズでソースを修正してルールの指摘件数が減少した場合と、それより後の工程である運用のフェーズでソースを修正してルールの指摘件数が減少した場合とでは、後の工程である運用のフェーズでのソース修正での改善の方が重要であると考えられる。そこで、本来はもっと早い段階で修正しておく必要があったものと指摘するために、当該ルールの重要度を、より後のフェーズでのソース修正で改善されたルールが高い重み付けになるように、変更する。このように重要度を変更することによって、プログラム開発者がプログラム修正の順序を決定する際に、不具合発生を回避する可能性の高い修正から行えるようになり、プログラムに対する不具合混入の度合いを減少させることに役立つ。

以上説明したように、本発明によれば、不具合が発生した工程（フェーズ）に応じて、各ルールによって指摘されたプログラムの修正件数に重み付けを行うことで、より後工程で発生した不具合修正に関連した指摘の重要度をより高め、開発者に対して修正すべき箇所の判断に役立てるとともに、後工程で発生する不具合に伴う手戻りによる作業増加を防ぐことが可能になる。また、開発を繰り返していくことで、ルールの重要度が洗練されていくので、開発者のグループあるいは開発者個人で、どのようなルールを重視すべきかが明確になっていくというメリットがある。

以下、本発明を実施する場合の一形態を図面を参照して具体的に説明する。

図１は、本発明を適用したプログラム静的解析システムの一実施の形態を示すシステム構成図である。このシステムは、プログラム静的解析サーバコンピュータ１と、プログラムソース管理サーバコンピュータ２と、プログラム開発・修正を行うクライアントコンピュータ３とが、ネットワーク４によって接続されて構成される。プログラム静的解析サーバコンピュータ１は、ＣＰＵ１１Ａおよびメモリ１１Ｂを備える端末装置１１、プログラム静的解析プログラム１２Ａ、ルール適用結果指摘一覧テーブル１２Ｂ、およびルール一覧テーブル１２Ｃが格納されている外部記憶装置１２、並びに、ネットワーク接続のための通信ポート１３を備えている。

プログラムソース管理サーバコンピュータ２は、ＣＰＵ２１Ａおよびメモリ２１Ｂを備える端末装置２１、ソース管理プログラム２２Ａ、プログラムソース２２Ｂ、およびプログラム修正履歴テーブル２２Ｃが格納されている外部記憶装置２２、並びに、ネットワーク接続のための通信ポート２３を備えている。

クライアントコンピュータ３は、ＣＰＵ３１Ａおよびメモリ３１Ｂを備える端末装置３１、プログラム編集プログラム３２Ａが格納されている外部記憶装置３２、並びに、通信ポート３３を備えている。

図２は、プログラム静的解析サーバコンピュータ１上の外部記憶装置１２に格納されているルール適用結果指摘一覧テーブル１２Ｂの一つの例である。ルール適用結果指摘一覧テーブル１２Ｂには、ルールＩＤ２０１、静的解析対象ソースプログラム名称２０２、指摘件数２０３、および解析実行日時２０４の組データ（エントリ）が格納される。この組データは、後述する図６のステップ６０５の処理により格納される。格納された組データは、解析実行日時２０４の日時に実行したプログラム静的解析の処理において、プログラム名称２０２のソースプログラム中にルールＩＤ２０１で特定されるルールを満たしていないと指摘された箇所が指摘件数２０３で示す数だけあったことを示している。

図３は、プログラム静的解析サーバコンピュータ１上の外部記憶装置１２に格納されているルール一覧テーブル１２Ｃの一つの例である。ルール一覧テーブル１２Ｃには、ルールＩＤ３０１、ルール名称３０２、および重要度３０３の組データが格納される。本テーブル１２Ｃには、予め、静的解析を実施する際に適用する全ルールについてルールＩＤ３０１とルール名称３０２と重要度３０３が格納されている。なお、重要度３０３は、初めは初期値が格納されているが、後述する図６の処理により更新されていくものである。また、静的解析を実施する際に適用するルールそのものについては、ルールＩＤ３０１から取得できるものとする。

図４は、プログラムソース管理サーバコンピュータ２上の外部記憶装置２２に格納されているプログラム修正履歴テーブル２２Ｃの一つの例である。プログラム修正履歴テーブル２２Ｃには、プログラム名称４０１、修正前のプログラムソースから削除された部分を格納する削除ソース４０２、修正前のプログラムソースに追加された部分を格納する追加ソース４０３、および修正実行日時４０４の組データが格納される。この組データは、後述する図７のステップ７０６の処理により格納される。

図５は、プログラムソース管理サーバコンピュータ２上の外部記憶装置２２に格納されているプログラムソース２２Ｂの構成例である。ここでは、各プログラムソースをパス名で示している。プログラムソース２２Ｂは、プログラム開発・運用のフェーズに応じて、コーディングフェーズ(501)、単体テストフェーズ(502)、結合テストフェーズ(503)、システムテストフェーズ(504)、運用フェーズ(505)といったフェーズＩＤをルートディレクト名称に持ったファイルシステム上に格納されている。501〜505がそれぞれフェーズＩＤである。

例えば、プロジェクトがコーディングフェーズにある間は、ユーザはディレクトリ/501/の下にあるソースプログラムを修正しながら作業を進め、次にプロジェクトが単位テストフェーズに入ったときは、ディレクトリ/502/の下にあるソースプログラムを修正していくことで作業を進める。

図６は、プログラム静的解析サーバコンピュータ１上で動作する、プログラム静的解析プログラム１２Ａの動作を示すフローチャートである。プログラム静的解析プログラム１２Ａは、任意のタイミングで、解析対象プログラムのフェーズＩＤを指定して実行させることができる。

プログラム静的解析プログラム１２Ａが起動すると、解析対象プログラムのフェーズＩＤの入力を受け付け（ステップ６０１）、プログラムソース管理サーバコンピュータ２上のソース管理プログラム２２Ａに接続して当該フェーズＩＤを送信し（ステップ６０２）、そのフェーズに属する全てのプログラムソースを入手する（ステップ６０３）。入手した各プログラムソースに対してルール一覧テーブル１２Ｃの各ルールを適用して静的解析を実施する（ステップ６０４）。静的解析の結果、ルールを満たしていないと指摘した箇所があった場合には、そのルールＩＤ、プログラム名称、ルールを満たさなかったと指摘した箇所の件数、および、静的解析を実施した日時を、ルール適用結果指摘一覧テーブル１２Ｂ（図２）に登録する（ステップ６０５）。

テーブル１２Ｂへは、ソースプログラム毎、かつ、ルール毎に、１エントリが登録される。指摘件数が０件の場合も登録する。結果として、ステップ６０４の静的解析を１回行うと、各プログラム毎に、全ルールについての各指摘件数がテーブル１２Ｂへ登録される。また、各フェーズの開始日時と終了日時は分かるので、テーブル１２Ｂの解析実行日時２０４の値から、そのエントリがどのフェーズの解析結果を示しているかが分かる。なお、ここでは、ステップ６０１で入力されるフェーズＩＤは現状の（すなわち最新の）フェーズを示すものとし、フェーズが変わってから以前のフェーズの解析を行うことはないものとする。従って、解析実行日時２０４は最新のフェーズの期間に属するのに実際には以前のフェーズの解析を行っている、ということは想定していない。ただし、テーブル１２Ｂに、ステップ６０１で入力されたフェーズＩＤを登録するようにして、各エントリがどのフェーズの解析結果か分かるようにしてもよい。そのようにすることで、例えばプロジェクトが第１フェーズから第３フェーズに進んだ段階で、第２フェーズを指定して図６の解析を行うことも可能である。

次に、各ルールＩＤ毎に、前回の解析時の指摘件数と今回の解析時の指摘件数とを比較し、各ルールＩＤ毎の指摘件数の減少分を計算する（ステップ６０６）。この処理は、今回のステップ６０５の処理で新たにテーブル１２Ｂに登録されたエントリから、各ルール毎に指摘件数２０３を合計し（１つのルールに対して複数のプログラムのエントリがある場合は、それらの各プログラム毎の指摘件数を集計して、１つのルールについての合計指摘件数を求める）、同様にして、解析実行日時２０４から前回の解析時の各ルール毎の指摘件数２０３を取得してそれらの合計を求め、各ルール毎に前回解析時から今回解析時の指摘件数の減少分を計算するものである。計算された各ルール毎の指摘件数の減少分は、要するに、前回解析時から今回の解析時までの間に行った現フェーズにおけるソースプログラムの修正によって、この減少分だけの改善が為されたことを意味している。なお、最初のフェーズの最初の静的解析を行った時点では、「前回の解析時の指摘件数」はテーブル１２Ｂに無いので、ステップ６０６〜６０８の処理は行わないものとする。

次に、各ルール毎に、前記計算した減少分にステップ６０１で入力されたフェーズＩＤ（ここでは現在のフェーズＩＤ）に対応する重みを加重計算し、ルール一覧テーブル１２Ｃの各ルールＩＤに対応する重要度を更新する（ステップ６０７）。プログラムの修正は各フェーズで行われるが、より後のフェーズで行う修正の方が重要度は高い。後のフェーズでプログラムに施す修正は、より運用に近い場面で修正せざるを得なかった部分と考えられるからである。また、上述の各ルール毎の指摘件数の減少分は、それ自体が各ルールの重要度を示している。プログラムの修正によって、そのルールについて、指摘件数の減少分だけ改善されているからである。そこで、ステップ６０７では、各ルールＩＤ毎に減少分を重み付けして重要度を更新している。要するに、より減少分が大きく、より後のフェーズの場合に、より重要度が増加するように更新すると言うことである。次に、更新した重要度の順に、当該重要度と、ルール名称と、プログラム中のそのルールが指摘された指摘箇所とを表示し（ステップ６０８）、ステップ６０１に戻って次のフェーズＩＤの入力の待ち状態に入る。

なお、ここでは重要度を更新した後にステップ６０８でその重要度と指摘箇所を表示しているが、更新する前の重要度を用いて重要度と指摘箇所の表示を行ってもよい。

図７は、プログラムソース管理サーバコンピュータ２上で動作する、プログラムソース管理プログラム２２Ａの動作を示すフローチャートである。

プログラムソース管理プログラム２２Ａが開始すると、プログラム静的解析プログラム１２Ａまたはプログラム編集プログラム３２Ａからの接続を待つ（ステップ７０１）。プログラム静的解析プログラム１２Ａからの接続要求は、図６のステップ６０２で発行されるフェーズＩＤを指定した全プログラムソースの参照要求である。プログラム編集プログラム３２Ａからの接続要求は、後述する図８のステップ８０３で発行される参照要求またはステップ８０７で発行される更新要求である。接続後、要求元から送られたコマンドとフェーズＩＤを受け取る（ステップ７０２）。なお、上記コマンドは、参照あるいは更新する対象ファイルを特定する情報を含むものとする。

次に、コマンドが参照か更新かを判断し（ステップ７０３）、参照の場合には、指定されたフェーズＩＤに対応するプログラムソースをファイル接続元のプログラムに送信して（ステップ７０４）、ステップ７０１に戻る。コマンドが更新の場合は、接続元のプログラムからプログラムソースを受信し（ステップ７０５）、対応するフェーズＩＤのディレクトリ下に格納されているプログラムソースと比較して、プログラム名称、比較した結果の差分の削除ソース分と追加ソース分、及び修正日時を、プログラム修正履歴テーブル２２Ｃ（図４）に登録し(ステップ７０６)、ステップ７０５で受信したプログラムソースを対応するフェーズＩＤのディレクトリ下に格納（上書き）し（ステップ７０７）、ステップ７０１に戻って次の接続要求待ち状態に入る。

図８は、クライアントコンピュータ３上で動作する、プログラム編集プログラム３２Ａの動作を示すフローチャートである。

プログラム編集プログラム３２Ａが開始すると、編集対象のプログラムソースを特定する情報とフェーズＩＤの入力を受け（ステップ８０１）、プログラムソース管理プログラム２２Ａに接続し（ステップ８０２）、編集対象のプログラムソースを特定する情報を含む参照コマンドとフェーズＩＤを送信する（ステップ８０３）。プログラムソース管理プログラム２２Ａからプログラムソースを受信し（ステップ８０４）、そのプログラムを修正する（ステップ８０５）。修正が完了すると、プログラムソース管理プログラム２２Ａに接続し（ステップ８０６）、更新コマンドとフェーズＩＤを送信（ステップ８０７）した上で、修正後のプログラムソースを送信し（ステップ８０８）、ステップ８０１に戻る。

なお、図８では、ステップ８０８から８０１に戻って次のフェーズＩＤの入力の待ち状態に入るようにしているが、一旦図８の処理を終了して、ユーザによる図８の処理の実行指示があったとき再度ステップ８０１からの処理を行うようにしてもよい。

本発明を適用したプログラム静的解析システムの一実施の形態を示すシステム構成図である。 プログラム静的解析サーバコンピュータ上の外部記憶装置に格納されているルール適用結果指摘一覧テーブルの一つの例である。 プログラム静的解析サーバコンピュータ上の外部記憶装置に格納されているルール一覧テーブルの一つの例である。 プログラムソース管理サーバコンピュータ上の外部記憶装置に格納されているプログラム修正履歴テーブルの一つの例である。 プログラムソース管理サーバコンピュータ上の外部記憶装置に格納されているプログラムソースの構成例である。 プログラム静的解析サーバコンピュータ上で動作する、プログラム静的解析プログラムの動作を示すフローチャートである。 プログラムソース管理サーバコンピュータ上で動作する、プログラムソース管理プログラムの動作を示すフローチャートである。 クライアントコンピュータ上で動作する、プログラム編集プログラムの動作を示すフローチャートである。

符号の説明

１…プログラム静的解析サーバコンピュータ、２…プログラムソース管理サーバコンピュータ、３…クライアントコンピュータ、４…ネットワーク、１１、２１、３１…端末装置、１２、２２、３２…外部記憶装置、１２Ａ…プログラム静的解析プログラム、１２Ｂ…ルール適用結果指摘テーブル、１２Ｃ…ルール一覧テーブル、２２Ａ…プログラムソース管理プログラム、２２Ｂ…プログラムソース、２２Ｃ…プログラム修正履歴テーブル、３２…Ａプログラム編集プログラム。

Claims (1)

1. 複数のフェーズの各段階でソースプログラムを編集しながら、フェーズを進めていくことでソースプログラムの開発を行う際に、前記各フェーズにおいてソースプログラムを解析し、コーディングルールに即したコーディングが実施されていない箇所を指摘するプログラム静的解析システムであって、
   複数のコーディングルールを、各ルールの重要度とともに、格納したルール格納手段と、
   前記ルール格納手段に格納されているコーディングルールを用いて、指定されたフェーズのソースプログラムを解析し、前記コーディングルールを満たしていない箇所を求める静的解析手段と、
   前記静的解析手段で前記コーディングルールを満たしていないと指摘された箇所について、前記コーディングルール毎の指摘件数を求め、求めたコーディングルール毎の指摘件数を記憶する手段と、
   前回の静的解析で記憶した前記コーディングルール毎の指摘件数と今回の静的解析で記憶した前記コーディングルール毎の指摘件数とを比較し、コーディングルール毎にその減少分を求める手段と、
   前記コーディングルール毎に、前記減少分がより大きく、前記指定されたフェーズがより後のフェーズである場合に、より高い重要度となるように、前記ルール格納手段に格納されている当該コーディングルールに対応する重要度を変更する重要度変更手段と、
   前記静的解析手段により求めた前記ソースプログラム中のコーディングルールを満たしていない箇所を、そのコーディングルールの重要度とともに、表示する手段と
   を備えることを特徴とするプログラム静的解析システム。

Images