ソースコード診断システム
【課題】ソースコード診断システムに、プロジェクトに特化したルールを自動的に作成させ、作成されたルールに従ってソースコードがコーディングされているか否かを診断させる。
【解決手段】診断部２１０は、ソースコード３１０の各行がルール定義ファイル３２０に格納されている複数のルールに適合しているか否か診断し、適合していない行について、ルールとその行の位置とを示す情報を指摘ファイル３３０に格納する。また、診断部２１０は、各行を診断しているとき、各行を構成する各構文要素について、各構文要素の使われ方の傾向を示す傾向データを傾向テーブル３４０に格納する。ルール更新部２２０は、傾向テーブル３４０に格納されている傾向データに基づいてルール定義ファイル３２０に新しいルールを追加する。
【解決手段】診断部２１０は、ソースコード３１０の各行がルール定義ファイル３２０に格納されている複数のルールに適合しているか否か診断し、適合していない行について、ルールとその行の位置とを示す情報を指摘ファイル３３０に格納する。また、診断部２１０は、各行を診断しているとき、各行を構成する各構文要素について、各構文要素の使われ方の傾向を示す傾向データを傾向テーブル３４０に格納する。ルール更新部２２０は、傾向テーブル３４０に格納されている傾向データに基づいてルール定義ファイル３２０に新しいルールを追加する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア開発プロジェクトにおいて、開発者により作成されたソースコードがコーディング規準に適合するか否かを診断するソースコード診断システムに関する。
【背景技術】
【０００２】
一般に、ソフトウェア開発プロジェクトでは、開発対象となるシステムを構成するソースコードに対し、コーディング規準に従うルール集が予め定義されており、各開発者はこれに従ってコーディングする。この場合、実際にコーディング規準に従ってコーディングされているか否かを各開発者自身がチェックするとともに、プロジェクト全体のソースコードについて、インスペクション（検査）担当者がチェックする。
【０００３】
しかし、ソースコードのチェック作業は、ルール集に基づき、ソースコードを目視することにより行われるため、チェック作業の工数は多大なものとなる。
そこで、チェック作業の工数を削減するためのツールとして、予め定義されたルール集に基づき、開発者により作成されたソースコードをチェックする診断装置が知られている（例えば、特許文献１参照。）。
また、多数の開発者により作成されたソースコードについて、コーディング規準遵守状況のチェック及びチェック結果の集計等を定期的に行い、集計結果をプロジェクト関係者に提示するコーディング基準遵守状況監視システムが知られている（例えば、特許文献２参照。）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平０６−０２８１６５号公報
【特許文献２】特開２００６−１８７３５公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
特許文献１や特許文献２に開示されているようなソースコード診断ツールを利用する場合、コーディング規準に従うルール集を予め定義しておく必要がある。ソースコード診断ツールはソースコードを読み込み、そのルール集に基づいて診断する。このように、通常は、ソースコード診断ツールが予め定義されたルール集を持っており、ユーザはそのルール集の中から必要なものだけを選択する。
しかし、プロジェクトに特化したルールに従ってソースコードがコーディングされているか否かをソースコード診断ツールに診断させたい場合には、ユーザはそのプロジェクト用に特化したルールを作成し、ソースコード診断ツールに組み込まなければならない。
【０００６】
本発明の目的は、プロジェクトに特化したルールを自動的に作成し、作成されたルールに従ってソースコードがコーディングされているか否かを診断するソースコード診断システムを提供することである。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明のソースコード診断システムは、
ソースコードと、複数のルールが格納されているルール定義ファイルと、前記各ルールに適合しない行の位置を示す情報が格納される指摘ファイルと、前記ソースコードの各行に含まれる所定の各構文要素の使われ方の傾向を示す傾向データが格納される傾向テーブルとを記憶する記憶部と、
前記ソースコードの各行が前記ルール定義ファイルに格納されている各ルールに適合しているか否か診断し、適合していない行について、ルールと当該行の位置とを示す情報を指摘ファイルに格納し、前記各行を診断しているとき、前記各行に含まれる所定の各構文要素について、当該各構文要素の使われ方を示す傾向データを前記傾向テーブルに格納する診断部と、
前記傾向テーブルに格納されている傾向データに基づいて新しいルールを前記ルール定義ファイルに追加するルール更新部と、
を備えることを特徴とする。
【０００８】
好ましくは、本発明のソースコード診断システムは、
前記所定の各構文要素が、関数であり、
前記傾向データが、ユニーク関数名と呼び出し回数を含み、
前記診断部が、前記各行が関数の呼び出しを含む場合に、当該関数に基づいてユニーク関数名を作成し、当該作成されたユニーク関数名に基づいて前記各ルールに適合しているか否か診断し、前記傾向テーブルに格納されている傾向データの中に当該作成されたユニーク関数名が存在する場合、当該作成されたユニーク関数名の呼び出し回数を１だけ増加させ、前記傾向テーブルに格納されている傾向データの中に当該作成されたユニーク関数名が存在しない場合には、呼び出し回数を１として当該作成されたユニーク関数名を含む傾向データを前記傾向テーブルに追加し、
前記ルール更新部が、前記傾向テーブルに格納されている傾向データが同じ関数の呼び出しに基づいて作成された複数のユニーク関数名を含む場合に、当該各ユニーク関数名に対応する呼び出し回数に基づいて当該ユニーク関数名に関するルールを前記ルール定義ファイルに追加するか否かを判断する、
ことを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ソースコード診断システムに、プロジェクトに特化したルールを自動的に作成させ、作成されたルールに従ってソースコードがコーディングされているか否かを診断させることができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態に係るソースコード診断システムの構成の一例を示す図である。
【図２】ソースコード診断システムの動作の一例を示す図である。
【図３】ルール定義ファイルのフォーマットとその一例を示す図である。
【図４】指摘ファイルの一例を示す図である。
【図５】診断対象となるソースコードの一例を示す図である。
【図６】傾向テーブルの２つの例を示す図である。
【図７】ソースコード診断システムの処理の流れの一例を示す図である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施形態に係るソースコード診断システムについて図面を参照しながら詳細に説明する。
【００１２】
図１は、本発明の実施形態に係るソースコード診断システム１００の構成の一例を示す。
ソースコード診断システム１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１０と、メモリ１２０と、記憶部１３０と、入力部１４０と、表示部１５０とを有している。
メモリ１２０は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）やＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等で構成される。メモリ１２０は、ソースコード診断プログラム２００を記憶している。ＣＰＵ１１０が、ソースコード診断プログラム２００を実行することにより、診断部２１０とルール更新部２２０との各機能が実現される。
記憶部１３０は、ハードディスク装置等の磁気ディスク装置やＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）等の光ディスク装置等で構成される。記憶部１３０は、ソースコード３１０と、ルール定義ファイル３２０と、指摘ファイル３３０と、傾向テーブル３４０とを記憶する。なお、ソースコード３１０は、単一のファイルとして記憶されていても、分割されて複数のファイルとして記憶されていてもよい。
入力部１４０は、キーボードやマウス等で構成される。表示部１５０は、ディスプレイやプリンタ等で構成される。
【００１３】
図２は、ソースコード診断システム１００の動作の一例を示す。
診断部２１０は、ソースコード３１０とルール定義ファイル３２０を記憶部１３０からメモリ１２０に読み込み、診断する。診断部２１０は、ソースコード３１０の各行がルール定義ファイル３２０に記憶されているルール集に適合しているか否か診断し、適合していない行について、そのルールとその行の位置（例えば、その行が含まれるファイル名と、そのファイル内における行の番号）とを示す情報を指摘ファイル３３０に書き込む。
例えば、「二項演算子の前後には空白を入れる」というルールであれば、診断部２１０は、ソースコード３１０から「二項演算子」（例えば’＋’，’／’など）が含まれている行を抽出する。そして、診断部２１０は、抽出された各行について、「二項演算子」の前後に空白があるか否かを検査する。このような検査を行い、「二項演算子」の前後に空白が存在しない場合には、指摘ファイル３３０に当該行を追加する。
【００１４】
既存のソースコード診断ツールはここで処理を終えるが、本実施形態に係るソースコード診断システム１００では、診断部２１０がソースコード３１０の各行を診断しているときに、各行に含まれる所定の各構文要素について、その各構文要素の使われ方を示す傾向データを作成し、作成された傾向データを傾向テーブル３４０に格納する。ここで、構文要素とは、関数、変数、配列、構造体、共用体などの文法的な塊を表す単位をいう。そして、診断部２１０による診断処理が終了した後に、ルール更新部２２０が傾向テーブル３４０に格納されている傾向データに基づいて予め定められていない新しいルールを作成し、作成されたルールをルール定義ファイル３２０に追加する。ルール定義ファイル３２０を自動的に更新することで、次回診断時にはソースコード３１０は新しいルールで診断される。
【００１５】
診断部２１０は、ソースコード３１０の各行を診断しているとき、各行に含まれる所定の各構文要素について、他の行と使われ方が異なるか否かを検査し、各構文要素の使われ方の傾向を示す傾向データを傾向テーブル３４０に格納する。傾向テーブル３４０には、複数の傾向データを格納できる。
傾向データは、例えば、ある行に含まれる構文要素が関数である場合、ユニーク関数名と呼び出し回数で構成される。ユニーク関数名とは、呼び出すべき関数が一意に特定できる関数の名前である。関数のオーバーロードが可能な高級言語ではユニーク関数名としてname mangleなどが知られている。name mangleでは、関数名と引数型を文字列で連結させることにより、呼び出すべき関数を一意に特定できるようにしている。どのような方法であれ、ユニーク関数名が作成できればよい。ただし、ユニーク関数名には、引数の型情報が含まれており、引数の数と、その数分の型情報をすべて再現できる必要がある。呼び出し回数は、各ユニーク関数名による関数の呼び出しが行われた回数を記録する。
【００１６】
図３（Ａ）はルール定義ファイル３２０のフォーマットの一例を示す。
ルール定義ファイル３２０は、例えば、図３（Ａ）に示すように、ルールＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）と、プロパティおよびその値とを設定できるフォーマットを有する。ルールＩＤは、各ルールを一意に特定するための記号である。プロパティは、各ルールの動作の詳細を規定するためのオプションを指定する。指定されたルールＩＤに応じてどのような検査が行われるかは、診断部２１０に規定されている。診断部２１０は、各ルールＩＤに対応する検査を行う。
【００１７】
図３（Ｂ）はルール定義ファイル３２０に定義されたルールの一例を示す。このルール定義ファイル３２０は、SpaceAroundBinaryOperatorとAvoidSpecifiedFunctionという２つのルールを含んでいる。
診断部２１０は、１行目のSpaceAroundBinaryOperatorルールが指定されると、二項演算子の前後に空白が入っているか否かを検査する。SpaceAroundBinaryOperatorルールのプロパティとして、AllowEqualAssignmentがtrueに設定されている。このプロパティは、代入演算子である'＝'については前後に空白がなくても指摘しないようにするものである。本例では、trueに設定されているため、診断部２１０は、代入演算子'＝'の前後に空白がなくても指摘しない。なお、このような規則は予め定義され、ルール定義ファイル３２０に内包されている規則であり、ルールＩＤを指定することで、予め定められた検査を行う。
次の行では、AvoidSpecifiedFunctionルールが指定されている。このルールが指定されると、診断部２１０は、プロパティで指定された名前を持つ関数名を使用している箇所をすべて指摘する。プロパティFunctionNameでは、ソースコードの中で使用が禁止される関数名が指定される。ここではfunction2(int)という関数名がプロパティで指定されているため、診断部２１０は、function2(int)関数を使っている箇所を指摘する。
【００１８】
図４は、指摘ファイル３３０の一例を示す。
診断部２１０は、各ルールに違反する行を検出すると、指摘ファイル３３０に、そのルールのルールＩＤと、その行が含まれるファイル名と、ファイル内におけるその行の番号とを順番に出力する。
例えば、図４の１行目と２行目は、ファイル名がfile1.cであるファイルの３３行目と３５行目に含まれる二項演算子の前後に空白がないことを示す。
また、図４の３行目は、ファイル名がfile5.cであるファイルの７２行目で変数が初期化されずに使用されたことを示す。
【００１９】
図５は、診断対象となるソースコード３１０の一例を示す。
図５のソースコード３１０は、functionという関数を定義しており、引数ｘと自動変数ｚとｂとを使用して演算を行ったあと、戻値ｂを返す。
【００２０】
図６（Ａ）は、傾向テーブル３４０の一例を示す。
傾向テーブル３４０は、ユニーク関数名と、呼び出し回数と、対応との各フィールドを有する。
図６（Ａ）に示す関数３４１と関数３４２は同じ関数から作成されたユニーク関数であるが、関数３４１の呼び出し時の引数は整数型であり、関数３４２の呼び出し時の引数は整数ポインタ型である。このため、傾向テーブル３４０では二つに分けて登録されている。
【００２１】
ルール更新部２２０は、同じ関数から作成されたユニーク関数について呼び出し回数の比率を求め、それが所定の閾値未満のとき、異常ケースと判断する。ソースコード３１０における関数３４１と関数３４２の呼び出し回数はそれぞれ２０回と、１回である。関数３４２は、呼び出し回数比率が1/(20+1)=4.8%である。例えば、所定の値を5%とすると、ルール更新部２２０は、関数３４２を異常ケースであると認定する。一方、関数３４１は呼び出し回数比率が20/(20+1)=95%であるため、ルール更新部２２０は、正常引数型と認定する。
この場合、ルール更新部２２０は、ルール定義ファイル３２０に含まれるルールAvoidSpecifiedFunctionのプロパティとしてユニーク関数名"function$int*"を追加し、傾向テーブル３４０の関数３４１と関数３４２の対応フィールドにそれぞれ「正常引数型に認定」および「新ルールに登録」と記録する。
これにより、診断部２１０が、更新されたルール定義ファイル３２０を用いてソースコード３１０を診断すると、function(int*)の間違った呼び出し箇所がすべて指摘され、function(int*)を呼び出している行が全て指摘ファイル３３０に記録されることとなる。
【００２２】
図６（Ｂ）は、傾向テーブル３４０の別の例を示す。
ルール更新部２２０は、関数３４３を正常引数型と認定し、関数３４４を指摘対象関数としてルール定義ファイル３２０に登録する。
一方、関数３４５については、同じ関数から作成された別のユニーク関数が存在しない。このため、ルール更新部２２０は、関数３４５については正常引数型か否かの判定は行わない。関数３４５は、正常引数型に認定されたわけではないが、指摘もされない、という状態である。
【００２３】
図７は、ソースコード診断システム１００の処理の流れの一例を示す。
診断部２１０は、傾向テーブル３４０を初期化し（Ｓ１０１）、ルール定義ファイル３２０を記憶部１３０からメモリ１２０に読み込む（Ｓ１０２）。
次に、診断部２１０は、ソースコード３１０が分割されて複数のファイルに含まれている場合、全ファイルをターゲットにしてステップＳ１０３からステップＳ１０５までをループする。なお、診断部２１０は、ソースコード３１０が単一のファイルに含まれている場合、ステップＳ１０３からステップＳ１０５を１回のみ実行する。
【００２４】
診断部２１０は、ソースコード３１０を１行ずつ記憶部１３０からメモリ１２０に読み込みながら（Ｓ１０３）、ルール定義ファイル３２０に基づいてルールに違反する箇所が有るか否か診断を進める（Ｓ１０４）。
診断部２１０は、当該行で関数を呼び出しているかどうかを調べる。関数を呼び出している場合には、当該関数に基づいてユニーク関数の名前であるユニーク関数名を作成する。その際、ユニーク関数名に含まれる引数は実際に呼ばれる関数の引数(仮引数)ではなく、呼び出す側の引数（実引数）をユニーク関数名に含める。そして、診断部２１０は、傾向テーブル３４０から、作成されたユニーク関数名を探し、傾向テーブル３４０の中にユニーク関数名が存在する場合、該当のユニーク関数名の呼び出し回数を１増やす。一方、診断部２１０は、傾向テーブル３４０にユニーク関数名が存在しない場合には、呼び出し回数を１として新たなユニーク関数名を含む傾向データを傾向テーブル３４０に追加する（Ｓ１０５）。
【００２５】
診断部２１０が全てのファイルについて診断を終えると、ルール更新部２２０は、
傾向テーブル３４０内をすべて走査する。
ルール更新部２２０は、傾向テーブル３４０から同じ関数から作成されたユニーク関数名を含む傾向データを見つけ、当該関数の全呼び出し回数を１００％として、呼び出し回数の比率が所定の閾値未満（例えば、５％未満）であるユニーク関数を異常ケースであると判断する（Ｓ１０６）。また、ルール更新部２２０は、呼び出し回数の比率が所定の閾値以上である同じ関数から作成されたユニーク関数の中で最も呼び出し回数比率が高いものを正常引数型と認定する（Ｓ１０９）。なお、呼び出し回数が所定の閾値以上である同じ関数から作成されたユニーク関数の中で最も呼び出し回数比率が高いもの以外のユニーク関数は正常引数型に認定されたわけではないが、指摘もされない、という状態である。
【００２６】
ルール更新部２２０は、異常ケースであると判断したユニーク関数について、「異常と判断された関数の呼び出し引数で、関数呼び出しを行っている箇所を指摘する」新ルールを作成する（Ｓ１０７）。例えば、function2(int)関数に対して、function2(int*)が呼ばれるケースが発見された場合、ルール更新部２２０は、「function2(int*)関数を呼び出している箇所を指摘する」新ルールを作成する。これは、AviodFunctionルールを追加することである。そして、ルール更新部２２０は、作成されたルールを、ルール定義ファイルに追加する（Ｓ１０８）。すなわち、ルール定義ファイルに、ルールＩＤがAvoidFunctionルールで、プロパティFunctionが"function2$int*"となる行を追加する。
【００２７】
なお、ステップＳ１０１〜Ｓ１０５の処理は診断部２１０が行い、ステップＳ１０６〜Ｓ１０９の処理はルール更新部２２０が行うが、診断部２１０がステップＳ１０１〜Ｓ１０５の処理を行うとルール更新部２２０が必ずステップＳ１０６〜Ｓ１０９の処理を行うとしてもよいし、診断部２１０がステップＳ１０１〜Ｓ１０５の処理を複数回行うとルール更新部２２０がステップＳ１０６〜Ｓ１０９の処理を行うとしてもよい。
【００２８】
以上説明したように、本発明によれば、ソースコード診断システムに、プロジェクトに特化したルールを自動的に作成させ、作成されたルールに従ってソースコードがコーディングされているか否かを診断させることができる。
【符号の説明】
【００２９】
１００…ソースコード診断システム、１１０…ＣＰＵ、１２０…メモリ、１３０…記憶部、１４０…入力部、１５０…表示部、２００…ソースコード診断プログラム、２１０…診断部、２２０…ルール更新部、３１０…ソースコード、３２０…ルール定義ファイル、３３０…指摘ファイル、３４０…傾向テーブル
【技術分野】
【０００１】
本発明は、ソフトウェア開発プロジェクトにおいて、開発者により作成されたソースコードがコーディング規準に適合するか否かを診断するソースコード診断システムに関する。
【背景技術】
【０００２】
一般に、ソフトウェア開発プロジェクトでは、開発対象となるシステムを構成するソースコードに対し、コーディング規準に従うルール集が予め定義されており、各開発者はこれに従ってコーディングする。この場合、実際にコーディング規準に従ってコーディングされているか否かを各開発者自身がチェックするとともに、プロジェクト全体のソースコードについて、インスペクション（検査）担当者がチェックする。
【０００３】
しかし、ソースコードのチェック作業は、ルール集に基づき、ソースコードを目視することにより行われるため、チェック作業の工数は多大なものとなる。
そこで、チェック作業の工数を削減するためのツールとして、予め定義されたルール集に基づき、開発者により作成されたソースコードをチェックする診断装置が知られている（例えば、特許文献１参照。）。
また、多数の開発者により作成されたソースコードについて、コーディング規準遵守状況のチェック及びチェック結果の集計等を定期的に行い、集計結果をプロジェクト関係者に提示するコーディング基準遵守状況監視システムが知られている（例えば、特許文献２参照。）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平０６−０２８１６５号公報
【特許文献２】特開２００６−１８７３５公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
特許文献１や特許文献２に開示されているようなソースコード診断ツールを利用する場合、コーディング規準に従うルール集を予め定義しておく必要がある。ソースコード診断ツールはソースコードを読み込み、そのルール集に基づいて診断する。このように、通常は、ソースコード診断ツールが予め定義されたルール集を持っており、ユーザはそのルール集の中から必要なものだけを選択する。
しかし、プロジェクトに特化したルールに従ってソースコードがコーディングされているか否かをソースコード診断ツールに診断させたい場合には、ユーザはそのプロジェクト用に特化したルールを作成し、ソースコード診断ツールに組み込まなければならない。
【０００６】
本発明の目的は、プロジェクトに特化したルールを自動的に作成し、作成されたルールに従ってソースコードがコーディングされているか否かを診断するソースコード診断システムを提供することである。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明のソースコード診断システムは、
ソースコードと、複数のルールが格納されているルール定義ファイルと、前記各ルールに適合しない行の位置を示す情報が格納される指摘ファイルと、前記ソースコードの各行に含まれる所定の各構文要素の使われ方の傾向を示す傾向データが格納される傾向テーブルとを記憶する記憶部と、
前記ソースコードの各行が前記ルール定義ファイルに格納されている各ルールに適合しているか否か診断し、適合していない行について、ルールと当該行の位置とを示す情報を指摘ファイルに格納し、前記各行を診断しているとき、前記各行に含まれる所定の各構文要素について、当該各構文要素の使われ方を示す傾向データを前記傾向テーブルに格納する診断部と、
前記傾向テーブルに格納されている傾向データに基づいて新しいルールを前記ルール定義ファイルに追加するルール更新部と、
を備えることを特徴とする。
【０００８】
好ましくは、本発明のソースコード診断システムは、
前記所定の各構文要素が、関数であり、
前記傾向データが、ユニーク関数名と呼び出し回数を含み、
前記診断部が、前記各行が関数の呼び出しを含む場合に、当該関数に基づいてユニーク関数名を作成し、当該作成されたユニーク関数名に基づいて前記各ルールに適合しているか否か診断し、前記傾向テーブルに格納されている傾向データの中に当該作成されたユニーク関数名が存在する場合、当該作成されたユニーク関数名の呼び出し回数を１だけ増加させ、前記傾向テーブルに格納されている傾向データの中に当該作成されたユニーク関数名が存在しない場合には、呼び出し回数を１として当該作成されたユニーク関数名を含む傾向データを前記傾向テーブルに追加し、
前記ルール更新部が、前記傾向テーブルに格納されている傾向データが同じ関数の呼び出しに基づいて作成された複数のユニーク関数名を含む場合に、当該各ユニーク関数名に対応する呼び出し回数に基づいて当該ユニーク関数名に関するルールを前記ルール定義ファイルに追加するか否かを判断する、
ことを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ソースコード診断システムに、プロジェクトに特化したルールを自動的に作成させ、作成されたルールに従ってソースコードがコーディングされているか否かを診断させることができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態に係るソースコード診断システムの構成の一例を示す図である。
【図２】ソースコード診断システムの動作の一例を示す図である。
【図３】ルール定義ファイルのフォーマットとその一例を示す図である。
【図４】指摘ファイルの一例を示す図である。
【図５】診断対象となるソースコードの一例を示す図である。
【図６】傾向テーブルの２つの例を示す図である。
【図７】ソースコード診断システムの処理の流れの一例を示す図である。
【発明を実施するための形態】
【００１１】
以下、本発明の実施形態に係るソースコード診断システムについて図面を参照しながら詳細に説明する。
【００１２】
図１は、本発明の実施形態に係るソースコード診断システム１００の構成の一例を示す。
ソースコード診断システム１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１０と、メモリ１２０と、記憶部１３０と、入力部１４０と、表示部１５０とを有している。
メモリ１２０は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）やＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等で構成される。メモリ１２０は、ソースコード診断プログラム２００を記憶している。ＣＰＵ１１０が、ソースコード診断プログラム２００を実行することにより、診断部２１０とルール更新部２２０との各機能が実現される。
記憶部１３０は、ハードディスク装置等の磁気ディスク装置やＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）等の光ディスク装置等で構成される。記憶部１３０は、ソースコード３１０と、ルール定義ファイル３２０と、指摘ファイル３３０と、傾向テーブル３４０とを記憶する。なお、ソースコード３１０は、単一のファイルとして記憶されていても、分割されて複数のファイルとして記憶されていてもよい。
入力部１４０は、キーボードやマウス等で構成される。表示部１５０は、ディスプレイやプリンタ等で構成される。
【００１３】
図２は、ソースコード診断システム１００の動作の一例を示す。
診断部２１０は、ソースコード３１０とルール定義ファイル３２０を記憶部１３０からメモリ１２０に読み込み、診断する。診断部２１０は、ソースコード３１０の各行がルール定義ファイル３２０に記憶されているルール集に適合しているか否か診断し、適合していない行について、そのルールとその行の位置（例えば、その行が含まれるファイル名と、そのファイル内における行の番号）とを示す情報を指摘ファイル３３０に書き込む。
例えば、「二項演算子の前後には空白を入れる」というルールであれば、診断部２１０は、ソースコード３１０から「二項演算子」（例えば’＋’，’／’など）が含まれている行を抽出する。そして、診断部２１０は、抽出された各行について、「二項演算子」の前後に空白があるか否かを検査する。このような検査を行い、「二項演算子」の前後に空白が存在しない場合には、指摘ファイル３３０に当該行を追加する。
【００１４】
既存のソースコード診断ツールはここで処理を終えるが、本実施形態に係るソースコード診断システム１００では、診断部２１０がソースコード３１０の各行を診断しているときに、各行に含まれる所定の各構文要素について、その各構文要素の使われ方を示す傾向データを作成し、作成された傾向データを傾向テーブル３４０に格納する。ここで、構文要素とは、関数、変数、配列、構造体、共用体などの文法的な塊を表す単位をいう。そして、診断部２１０による診断処理が終了した後に、ルール更新部２２０が傾向テーブル３４０に格納されている傾向データに基づいて予め定められていない新しいルールを作成し、作成されたルールをルール定義ファイル３２０に追加する。ルール定義ファイル３２０を自動的に更新することで、次回診断時にはソースコード３１０は新しいルールで診断される。
【００１５】
診断部２１０は、ソースコード３１０の各行を診断しているとき、各行に含まれる所定の各構文要素について、他の行と使われ方が異なるか否かを検査し、各構文要素の使われ方の傾向を示す傾向データを傾向テーブル３４０に格納する。傾向テーブル３４０には、複数の傾向データを格納できる。
傾向データは、例えば、ある行に含まれる構文要素が関数である場合、ユニーク関数名と呼び出し回数で構成される。ユニーク関数名とは、呼び出すべき関数が一意に特定できる関数の名前である。関数のオーバーロードが可能な高級言語ではユニーク関数名としてname mangleなどが知られている。name mangleでは、関数名と引数型を文字列で連結させることにより、呼び出すべき関数を一意に特定できるようにしている。どのような方法であれ、ユニーク関数名が作成できればよい。ただし、ユニーク関数名には、引数の型情報が含まれており、引数の数と、その数分の型情報をすべて再現できる必要がある。呼び出し回数は、各ユニーク関数名による関数の呼び出しが行われた回数を記録する。
【００１６】
図３（Ａ）はルール定義ファイル３２０のフォーマットの一例を示す。
ルール定義ファイル３２０は、例えば、図３（Ａ）に示すように、ルールＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）と、プロパティおよびその値とを設定できるフォーマットを有する。ルールＩＤは、各ルールを一意に特定するための記号である。プロパティは、各ルールの動作の詳細を規定するためのオプションを指定する。指定されたルールＩＤに応じてどのような検査が行われるかは、診断部２１０に規定されている。診断部２１０は、各ルールＩＤに対応する検査を行う。
【００１７】
図３（Ｂ）はルール定義ファイル３２０に定義されたルールの一例を示す。このルール定義ファイル３２０は、SpaceAroundBinaryOperatorとAvoidSpecifiedFunctionという２つのルールを含んでいる。
診断部２１０は、１行目のSpaceAroundBinaryOperatorルールが指定されると、二項演算子の前後に空白が入っているか否かを検査する。SpaceAroundBinaryOperatorルールのプロパティとして、AllowEqualAssignmentがtrueに設定されている。このプロパティは、代入演算子である'＝'については前後に空白がなくても指摘しないようにするものである。本例では、trueに設定されているため、診断部２１０は、代入演算子'＝'の前後に空白がなくても指摘しない。なお、このような規則は予め定義され、ルール定義ファイル３２０に内包されている規則であり、ルールＩＤを指定することで、予め定められた検査を行う。
次の行では、AvoidSpecifiedFunctionルールが指定されている。このルールが指定されると、診断部２１０は、プロパティで指定された名前を持つ関数名を使用している箇所をすべて指摘する。プロパティFunctionNameでは、ソースコードの中で使用が禁止される関数名が指定される。ここではfunction2(int)という関数名がプロパティで指定されているため、診断部２１０は、function2(int)関数を使っている箇所を指摘する。
【００１８】
図４は、指摘ファイル３３０の一例を示す。
診断部２１０は、各ルールに違反する行を検出すると、指摘ファイル３３０に、そのルールのルールＩＤと、その行が含まれるファイル名と、ファイル内におけるその行の番号とを順番に出力する。
例えば、図４の１行目と２行目は、ファイル名がfile1.cであるファイルの３３行目と３５行目に含まれる二項演算子の前後に空白がないことを示す。
また、図４の３行目は、ファイル名がfile5.cであるファイルの７２行目で変数が初期化されずに使用されたことを示す。
【００１９】
図５は、診断対象となるソースコード３１０の一例を示す。
図５のソースコード３１０は、functionという関数を定義しており、引数ｘと自動変数ｚとｂとを使用して演算を行ったあと、戻値ｂを返す。
【００２０】
図６（Ａ）は、傾向テーブル３４０の一例を示す。
傾向テーブル３４０は、ユニーク関数名と、呼び出し回数と、対応との各フィールドを有する。
図６（Ａ）に示す関数３４１と関数３４２は同じ関数から作成されたユニーク関数であるが、関数３４１の呼び出し時の引数は整数型であり、関数３４２の呼び出し時の引数は整数ポインタ型である。このため、傾向テーブル３４０では二つに分けて登録されている。
【００２１】
ルール更新部２２０は、同じ関数から作成されたユニーク関数について呼び出し回数の比率を求め、それが所定の閾値未満のとき、異常ケースと判断する。ソースコード３１０における関数３４１と関数３４２の呼び出し回数はそれぞれ２０回と、１回である。関数３４２は、呼び出し回数比率が1/(20+1)=4.8%である。例えば、所定の値を5%とすると、ルール更新部２２０は、関数３４２を異常ケースであると認定する。一方、関数３４１は呼び出し回数比率が20/(20+1)=95%であるため、ルール更新部２２０は、正常引数型と認定する。
この場合、ルール更新部２２０は、ルール定義ファイル３２０に含まれるルールAvoidSpecifiedFunctionのプロパティとしてユニーク関数名"function$int*"を追加し、傾向テーブル３４０の関数３４１と関数３４２の対応フィールドにそれぞれ「正常引数型に認定」および「新ルールに登録」と記録する。
これにより、診断部２１０が、更新されたルール定義ファイル３２０を用いてソースコード３１０を診断すると、function(int*)の間違った呼び出し箇所がすべて指摘され、function(int*)を呼び出している行が全て指摘ファイル３３０に記録されることとなる。
【００２２】
図６（Ｂ）は、傾向テーブル３４０の別の例を示す。
ルール更新部２２０は、関数３４３を正常引数型と認定し、関数３４４を指摘対象関数としてルール定義ファイル３２０に登録する。
一方、関数３４５については、同じ関数から作成された別のユニーク関数が存在しない。このため、ルール更新部２２０は、関数３４５については正常引数型か否かの判定は行わない。関数３４５は、正常引数型に認定されたわけではないが、指摘もされない、という状態である。
【００２３】
図７は、ソースコード診断システム１００の処理の流れの一例を示す。
診断部２１０は、傾向テーブル３４０を初期化し（Ｓ１０１）、ルール定義ファイル３２０を記憶部１３０からメモリ１２０に読み込む（Ｓ１０２）。
次に、診断部２１０は、ソースコード３１０が分割されて複数のファイルに含まれている場合、全ファイルをターゲットにしてステップＳ１０３からステップＳ１０５までをループする。なお、診断部２１０は、ソースコード３１０が単一のファイルに含まれている場合、ステップＳ１０３からステップＳ１０５を１回のみ実行する。
【００２４】
診断部２１０は、ソースコード３１０を１行ずつ記憶部１３０からメモリ１２０に読み込みながら（Ｓ１０３）、ルール定義ファイル３２０に基づいてルールに違反する箇所が有るか否か診断を進める（Ｓ１０４）。
診断部２１０は、当該行で関数を呼び出しているかどうかを調べる。関数を呼び出している場合には、当該関数に基づいてユニーク関数の名前であるユニーク関数名を作成する。その際、ユニーク関数名に含まれる引数は実際に呼ばれる関数の引数(仮引数)ではなく、呼び出す側の引数（実引数）をユニーク関数名に含める。そして、診断部２１０は、傾向テーブル３４０から、作成されたユニーク関数名を探し、傾向テーブル３４０の中にユニーク関数名が存在する場合、該当のユニーク関数名の呼び出し回数を１増やす。一方、診断部２１０は、傾向テーブル３４０にユニーク関数名が存在しない場合には、呼び出し回数を１として新たなユニーク関数名を含む傾向データを傾向テーブル３４０に追加する（Ｓ１０５）。
【００２５】
診断部２１０が全てのファイルについて診断を終えると、ルール更新部２２０は、
傾向テーブル３４０内をすべて走査する。
ルール更新部２２０は、傾向テーブル３４０から同じ関数から作成されたユニーク関数名を含む傾向データを見つけ、当該関数の全呼び出し回数を１００％として、呼び出し回数の比率が所定の閾値未満（例えば、５％未満）であるユニーク関数を異常ケースであると判断する（Ｓ１０６）。また、ルール更新部２２０は、呼び出し回数の比率が所定の閾値以上である同じ関数から作成されたユニーク関数の中で最も呼び出し回数比率が高いものを正常引数型と認定する（Ｓ１０９）。なお、呼び出し回数が所定の閾値以上である同じ関数から作成されたユニーク関数の中で最も呼び出し回数比率が高いもの以外のユニーク関数は正常引数型に認定されたわけではないが、指摘もされない、という状態である。
【００２６】
ルール更新部２２０は、異常ケースであると判断したユニーク関数について、「異常と判断された関数の呼び出し引数で、関数呼び出しを行っている箇所を指摘する」新ルールを作成する（Ｓ１０７）。例えば、function2(int)関数に対して、function2(int*)が呼ばれるケースが発見された場合、ルール更新部２２０は、「function2(int*)関数を呼び出している箇所を指摘する」新ルールを作成する。これは、AviodFunctionルールを追加することである。そして、ルール更新部２２０は、作成されたルールを、ルール定義ファイルに追加する（Ｓ１０８）。すなわち、ルール定義ファイルに、ルールＩＤがAvoidFunctionルールで、プロパティFunctionが"function2$int*"となる行を追加する。
【００２７】
なお、ステップＳ１０１〜Ｓ１０５の処理は診断部２１０が行い、ステップＳ１０６〜Ｓ１０９の処理はルール更新部２２０が行うが、診断部２１０がステップＳ１０１〜Ｓ１０５の処理を行うとルール更新部２２０が必ずステップＳ１０６〜Ｓ１０９の処理を行うとしてもよいし、診断部２１０がステップＳ１０１〜Ｓ１０５の処理を複数回行うとルール更新部２２０がステップＳ１０６〜Ｓ１０９の処理を行うとしてもよい。
【００２８】
以上説明したように、本発明によれば、ソースコード診断システムに、プロジェクトに特化したルールを自動的に作成させ、作成されたルールに従ってソースコードがコーディングされているか否かを診断させることができる。
【符号の説明】
【００２９】
１００…ソースコード診断システム、１１０…ＣＰＵ、１２０…メモリ、１３０…記憶部、１４０…入力部、１５０…表示部、２００…ソースコード診断プログラム、２１０…診断部、２２０…ルール更新部、３１０…ソースコード、３２０…ルール定義ファイル、３３０…指摘ファイル、３４０…傾向テーブル
【特許請求の範囲】
【請求項１】
ソースコードと、複数のルールが格納されているルール定義ファイルと、前記各ルールに適合しない行の位置を示す情報が格納される指摘ファイルと、前記ソースコードの各行に含まれる所定の各構文要素の使われ方の傾向を示す傾向データが格納される傾向テーブルとを記憶する記憶部と、
前記ソースコードの各行が前記ルール定義ファイルに格納されている各ルールに適合しているか否か診断し、適合していない行について、ルールと当該行の位置とを示す情報を指摘ファイルに格納し、前記各行を診断しているとき、前記各行に含まれる所定の各構文要素について、当該各構文要素の使われ方を示す傾向データを前記傾向テーブルに格納する診断部と、
前記傾向テーブルに格納されている傾向データに基づいて新しいルールを前記ルール定義ファイルに追加するルール更新部と、
を備えることを特徴とするソースコード診断システム。
【請求項２】
前記所定の各構文要素が、関数であり、
前記傾向データが、ユニーク関数の名前であるユニーク関数名と呼び出し回数を含み、
前記診断部が、前記各行が関数の呼び出しを含む場合に、当該関数に基づいてユニーク関数名を作成し、当該作成されたユニーク関数名に基づいて前記各ルールに適合しているか否か診断し、前記傾向テーブルに格納されている傾向データの中に当該作成されたユニーク関数名が存在する場合、当該作成されたユニーク関数名の呼び出し回数を１だけ増加させ、前記傾向テーブルに格納されている傾向データの中に当該作成されたユニーク関数名が存在しない場合には、呼び出し回数を１として当該作成されたユニーク関数名を含む傾向データを前記傾向テーブルに追加し、
前記ルール更新部が、前記傾向テーブルに格納されている傾向データが同じ関数の呼び出しに基づいて作成された複数のユニーク関数名を含む場合に、当該各ユニーク関数名に対応する呼び出し回数に基づいて当該ユニーク関数名に関するルールを前記ルール定義ファイルに追加するか否かを判断する、
ことを特徴とする請求項１に記載のソースコード診断システム。
【請求項１】
ソースコードと、複数のルールが格納されているルール定義ファイルと、前記各ルールに適合しない行の位置を示す情報が格納される指摘ファイルと、前記ソースコードの各行に含まれる所定の各構文要素の使われ方の傾向を示す傾向データが格納される傾向テーブルとを記憶する記憶部と、
前記ソースコードの各行が前記ルール定義ファイルに格納されている各ルールに適合しているか否か診断し、適合していない行について、ルールと当該行の位置とを示す情報を指摘ファイルに格納し、前記各行を診断しているとき、前記各行に含まれる所定の各構文要素について、当該各構文要素の使われ方を示す傾向データを前記傾向テーブルに格納する診断部と、
前記傾向テーブルに格納されている傾向データに基づいて新しいルールを前記ルール定義ファイルに追加するルール更新部と、
を備えることを特徴とするソースコード診断システム。
【請求項２】
前記所定の各構文要素が、関数であり、
前記傾向データが、ユニーク関数の名前であるユニーク関数名と呼び出し回数を含み、
前記診断部が、前記各行が関数の呼び出しを含む場合に、当該関数に基づいてユニーク関数名を作成し、当該作成されたユニーク関数名に基づいて前記各ルールに適合しているか否か診断し、前記傾向テーブルに格納されている傾向データの中に当該作成されたユニーク関数名が存在する場合、当該作成されたユニーク関数名の呼び出し回数を１だけ増加させ、前記傾向テーブルに格納されている傾向データの中に当該作成されたユニーク関数名が存在しない場合には、呼び出し回数を１として当該作成されたユニーク関数名を含む傾向データを前記傾向テーブルに追加し、
前記ルール更新部が、前記傾向テーブルに格納されている傾向データが同じ関数の呼び出しに基づいて作成された複数のユニーク関数名を含む場合に、当該各ユニーク関数名に対応する呼び出し回数に基づいて当該ユニーク関数名に関するルールを前記ルール定義ファイルに追加するか否かを判断する、
ことを特徴とする請求項１に記載のソースコード診断システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１３−５４６１５（Ｐ２０１３−５４６１５Ａ）
【公開日】平成２５年３月２１日（２０１３．３．２１）
【国際特許分類】
【出願番号】特願２０１１−１９３４５０（Ｐ２０１１−１９３４５０）
【出願日】平成２３年９月６日（２０１１．９．６）
【出願人】（０００２３３０５５）株式会社日立ソリューションズ (1,610)
【Ｆターム（参考）】
【公開日】平成２５年３月２１日（２０１３．３．２１）
【国際特許分類】
【出願日】平成２３年９月６日（２０１１．９．６）
【出願人】（０００２３３０５５）株式会社日立ソリューションズ (1,610)
【Ｆターム（参考）】
[ Back to top ]