JP6636873B2 - ソースコードからの仕様抽出装置 - Google Patents

Description

本発明は、既存システムにおけるソースコードからの仕様抽出に関する。

現状、旧システムから新システムへのリプレース開発では、旧システムの正確なドキュメントが残されておらず旧システムのログやソースコードから仕様を再生する必要がある。

特に、エンタープライズシステムにおけるサービス等の業務ルールの仕様を分析する場合には、ソースコードを参照し、ある業務項目がいかなる値を持ったときにどのルールが適用されるのかという業務ルールの仕様を開発者が理解する必要がある。

しかしながら、ソースコードは膨大にあり、かつ、業務ルールに直接貢献しないコードも多数含まれるため、有識者の知見に頼らないと業務ルールの仕様の理解は困難となっているが実情である。

上記に関連する従来技術として、特許第４８２０９２４号公報（特許文献１）と特許４８３８５５３号公報（特許文献２）がある。

特許文献１には、情報処理システムに使用されるソースコードから、コード種類、コード組み合せ、コード配置といった処理機能を単位プログラムとして抽出する機能と、抽出された単位プログラムの順序から単位プログラムを統合し処理プログラムの物理モデルとして出力する技術が記載されている。

また、特許文献２には、通信文およびドキュメント内のキーワード特徴、語彙特徴および文パターンの特徴について、与えられたトレーニングデータにより学習を行い、スコアリングを行うことで、通信の優先順位を決定する技術が記載されている。

特許４８２０９２４号公報 特許４８３８５５３号公報

特許文献１の発明は、ソースコードから各情報の抽出を行う。しかしながら、すべてのソースコードの文を等しく扱っているため、例えば、業務ルールの仕様を実現するための仕様と、システム構築上記述せざるを得ない実装レベルの仕様が混在してしまう。

また、特許文献２の発明は、ドキュメント内のキーワードやパターンでスコアリングを行う。しかしながら、自然言語で書かれた文章を対象としており、字面上の特徴しか把握することができず、ソースコード上で定義される構造を特徴として把握することができない。

従って、特許文献1及び２の発明は、ソースコードから業務ルールの仕様を理解するために利用することは難しい。

上記課題を解決するために、本発明では、ソースコードを条件文と処理文として分け、条件文を「業務ルール判断」「データチェック・形式変換判断」「システムエラーチェック判断」「プログラムフロー制御判断」の４種類の役割に分類した上で、以下の処理を行う。

分析対象システムのソースコードであって、条件文と処理分とからなるブロック情報で構成されるソースコードから仕様を抽出するために、分析対象システムのソースコードを受け付け、受け付けたソースコードの制御関係を分析し、受け付けたソースコードと分析された制御関係の結果を保持し、保持されるソースコードとその制御関係の結果から、ソースコードを構成する各ブロック情報の貢献役割のスコアリングを行い、貢献役割のスコアリング結果に基づき、スコアが高いソースコードの貢献役割を出力する。

本発明によれば、分析対象である既存システムのソースコードを構成する各ブロック情報の確度の高い貢献役割を出力することによって、開発者は、業務ルールの仕様の理解に必要なソースコードだけを注目して見ることができる。その結果、従来のように有識者の知見に頼らなくても業務ルール仕様の理解をすることができ、従来よりも効率的になる。また、機械化により、既存システムの業務ルールの仕様について漏れなく確認することができる。最終的には業務ルールの仕様の再生を効率的に漏れなく行うことができる。

本実施例におけるソースコードからの仕様抽出装置１００の構成図の例である。 ソースコード依存関係分析プログラム１２０によりソースコードの制御関係を分析した結果であるソースコード制御関係分析結果テーブルＴ１６１の例である。 ソースコード依存関係分析プログラム１２０により変数間の依存関係を分析した結果であるデータ依存関係分析結果テーブルＴ１６２の例である。 貢献役割スコアリングプログラム１３０内の特徴的な機能構成の一例を説明する図である。 記述評価部１３１で用いる記述評価部関連スコアリングルールテーブルＴ１８１の一例をである。 依存関係評価部１３２で用いる依存関係評価部関連スコアリングルールテーブルＴ１８２の一例である。 プロジェクト固有情報評価部１３３で用いるプロジェクト固有情報評価部関連スコアリングルールテーブルＴ１８３の一例である。 データ項目辞書テーブルＴ１７１の例および部品構成テーブルＴ１７２の例である。 相関評価部１３４で用いる、相関評価部関連スコアリングテーブルＴ１８４の一例である。 貢献役割スコアリングプログラム１３０の動作の流れの一例を示すフローチャートＳ１００である。 結果出力プログラム１５０による出力結果の一例である。

以下、実施例を図面を用いて説明する。

本実施例では、ソースコードからの仕様抽出装置１００の例を説明する。

図１は、本実施例におけるソースコードからの仕様抽出装置１００の構成図の例である。

既存システム画面仕様抽出装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１、メモリ１０２、外部記憶装置１０３、入力装置１０６、出力装置１０７、通信装置１０８を有し、バス１０４を介してＣＰＵ１０１、メモリ１０２、外部インターフェース１０５が接続されている。また外部インターフェース１０５には、外部記憶装置１０３、入力装置１０６、出力装置１０７、通信装置１０８が接続されている。

外部記憶装置１０３は、ＣＰＵ１０１において実行される処理プログラムとしてソースコード入力プログラム１１０、ソースコード依存関係分析プログラム１２０、貢献役割スコアリングプログラム１３０、結果出力プログラム１５０を保持している。これらのプログラムは外部記憶装置１０３よりメモリ１０２に読み出されＣＰＵ１０１で実行される。

また、外部記憶装置１０３は、ソースコード解析結果記録部１６０と、プロジェクト情報記録部１７０と、スコアリングルール記録部１８０とを有する。

ソースコード入力プログラム１１０の実行によって、入力装置１０６もしくは通信装置１０８を通じ、分析対象システムのソースコードが受け付けられ、ソースコード解析結果記録部１６０に格納される。

ソースコード依存関係分析プログラム１２０の実行によって、ソースコード解析結果記録部１６０よりソースコード群が読み出され、ソースコードは条件部と処理部からなるブロックへと分割される。また、ソースコードの制御関係に基づき、当該ブロック処理がすべて完了した後に実行される後続ブロックと、呼び出し関係を含む当該ブロックの処理を実現する、構造の子の関係となるブロックとが分析され、ソースコード解析結果記録部１６０へ記録される。

図２は、ソースコード依存関係分析プログラム１２０の実行によりソースコードの制御関係が分析された結果であるソースコード制御関係分析結果テーブルＴ１６１の例である。ソースコード制御関係分析結果テーブルＴ１６１は、格納される情報としてブロックの識別子であるブロックＮｏＴ１６１０と、当該ブロックが所属するクラスやメソッド、ファイルなどを一意に識別するモジュール名Ｔ１６１１と、当該ブロックの条件文、条件の判断結果及び処理文とを含む情報を保持するブロック情報Ｔ１６１２と、当該ブロック処理がすべて完了した後に実行される後続ブロックのブロックＮｏを参照する後続ブロックＮｏＴ１６１３と、呼び出し関係を含む当該ブロックの処理を実現する、構造の子の関係となるブロックのブロックＮｏを参照する子ブロックＮｏＴ１６１４とを含む。

意味をレコードＴ１６１５を用いて説明する。

ブロックＮｏ”１１”のブロックは、モジュール”ＳｔａｔｓＥｖａｌｕａｔｅｒ．ｅｖａｌｕａｔｅ”に含まれるブロックであり、当該ブロックの先頭で条件文”ｉｆ（ｃａｓｅＳｔａｔｓ ＝＝ １）”が評価される。評価の結果が真（Ｔｒｕｅ）であれば、そのままＴ１６１５の処理文を実行する。この処理文内では、子ブロックであるブロックＮｏ”２０”で示されるブロックへ制御が移る。子ブロック内の処理を含むＴ１６１５の処理がすべて完了した後、制御は後続ブロックＮｏの示すブロックＮｏ”１３”へ移る。

ソースコード依存関係分析プログラム１２０の実行によって、ソースコード解析結果記録部１６０よりソースコード群が読み出され、各ブロックをまたがる変数に関する依存関係が分析され、ソースコード解析結果記録部１６０へ記録される。データ依存関係とは、ある変数から他の変数への直接代入や、ある変数へ他のいくつかの変数に関する演算結果を代入した際に生じる関係の事を指し、例えば、”Ｘ ＝ Ｙ ＋ Ｚ”という演算代入文があった場合、変数Ｘと変数Ｙ、変数Ｘと変数Ｚの間にはデータの依存関係が生じる。

図３は、ソースコード依存関係分析プログラム１２０の実行により変数間の依存関係が分析された結果であるデータ依存関係分析結果テーブルＴ１６２の例である。データ依存関係分析結果テーブルＴ１６２は、データの依存関係群を識別するデータ依存ＩＤのＴ１６２０と、対象となる変数が所属するモジュールを識別するモジュール名Ｔ１６２１と、変数を識別する変数名Ｔ１６２２と、当該変数の属性を示す変数属性Ｔ１６２３とを含む。レコードＴ１６２４、レコードＴ１６２５およびレコードＴ１６２６はそれぞれ同一のデータ依存関係にある変数群（ＩＤはＤ１０００）であり、レコードＴ１６２４は、モジュール名”ＡｃｏｕｎｔＩｎＳｃｒｅｅｎ．ｉｎ”における変数”ａｎｋｅｎＪｏｔａｉ”を示し、変数属性として”画面フォーム”に関連付けられていることを示す。同様にＴ１６２５，１６２６もそれぞれのモジュールにおける変数名と属性を示している。

図１に戻り、貢献役割スコアリングプログラム１３０の実行によって、ソースコードの依存関係が分析され格納されたソースコード解析結果記録部１６０内のソースコード制御関係分析結果テーブルＴ１６１について、データ依存関係分析結果テーブルＴ１６２やプロジェクト情報記録部１７０に格納されている情報を参照しながら、スコアリングルール記録部１８０に格納されたスコアリングルールに基づき、各ブロックの貢献役割のスコアリングが行われる。

図４は、貢献役割スコアリングプログラム１３０内の特徴的な機能構成の一例を説明する図である。

本実施例において、貢献役割スコアリングプログラム１３０は、スコアリング対象とする特徴量のカテゴリ別に、記述評価部１３１と、依存関係評価部１３２と、プロジェクト固有情報評価部１３３と、相関評価部１３４とから構成される。

また、本実施例においては、貢献役割スコアリングプログラム１３０の実行によって、プログラムの貢献役割を、「業務ルール判断処理」「データチェック・形式変換判断処理」「システムエラーチェック判断処理」「プログラムフロー制御判断処理」として、各ブロックのどの役割の判断や処理を実現しているかが分類される。

なお、この４分類はあくまで一例であり、抽出を目的とする仕様により増減があってもかまわない。

記述評価部１３１の実行によって、ソースコードの記述そのものに対するスコアリングが行われる。例えば、プログラム文型・予約語評価部１３１０と、処理種別評価部１３１１と、プログラムイディオム評価部１３１２とから構成される。

図５に、記述評価部１３１で用いる記述評価部関連スコアリングルールテーブルＴ１８１の一例を示す。本スコアリングルールは、スコアリングルール記録部１８０にあらかじめ格納されている。記述評価部関連スコアリングルールテーブルＴ１８１は、当該ルールのカテゴリＴ１８１０と、当該ルールを識別するルールＩＤＴ１８１１と、評価内容であるスコアリングルールＴ１８１２と、当該ルールが対象とする対象言語Ｔ１８１３と、判定対象のブロックが当該ルールを満たした際に、どの役割へ貢献しているかの尤度を役割種別（「業務ルール判断処理」「データチェック・形式変換判断処理」「システムエラーチェック判断処理」「プログラムフロー制御判断処理」）ごとにスコアを定めたブロック役割種別加算スコアＴ１８１４とを含む。

なお、図５で示しているブロック役割種別加算スコアＴ１８１４はあくまで一例であり、図に掲載した数値に限られるものではない。

プログラム文型・予約語評価部１３１０の実行によって、ソースコード解析結果記録部１６０のソースコード制御関係分析結果テーブルＴ１６１より１ブロックずつ読み込み、記述評価部関連スコアリングルールテーブルＴ１８１のカテゴリＴ１８１０が”文型・予約語”であるものが順次評価されていく。

例えば、レコードＴ１８１５に示されるルールであれば、読み込んだブロックの条件文がＩＦ文であるかどうかを判定し、もし、ＩＦ文であれば、「業務ルール判断処理」「データチェック・形式変換判断処理」「システムエラーチェック判断処理」の役割に各々＋１をスコア加点する。「プログラムフロー制御判断処理」の役割には０点を加点する。尚、以下では省略するが、貢献役割スコアリングプログラム１３０の各ルール判断において、読み込んだブロックにおいてルールが成立した際は、その成立したルールＩＤをブロックＮｏに紐付け、逐次記録しておく。

同様に、処理種別評価部１３１１は、読み込んだブロックについて、カテゴリＴ１８１０が”処理種別”であるものを順次評価していく。

例えば、レコードＴ１８１６に示されるルールであれば、読み込んだブロックの処理部に文字列演算が含まれるか否かを判定し、もし、文字列演算が含まれていれば「業務ルール判断処理」、「データチェック・形式変換判断処理」、「システムエラーチェック判断処理」、および「プログラムフロー制御判断処理」の役割に、各々０、＋１、−１、−１をスコアとして加算する。

また、同様に、プログラムイディオム評価部１３１２の実行によって、読み込んだブロックについて、カテゴリＴ１８１０が”プログラムイディオム”であるものが順次評価されていく。

例えば、レコードＴ１８１７に示されるルールであれば、読み込んだブロックの条件部にＮｕｌｌとの比較演算が含まれるか否かを判定し、もし、Ｎｕｌｌとの比較演算が含まれていれば「業務ルール判断処理」、「データチェック・形式変換判断処理」、「システムエラーチェック判断処理」、および「プログラムフロー制御判断処理」の役割に、各々０、０、＋１、＋０．５をスコアとして加算する。

図４に戻り、依存関係評価部１３２の実行によって、ソースコードの依存関係について分析された結果に基づくスコアリングが行われ、例えば、データ依存関係評価部１３２０から構成される。

図６に、依存関係評価部１３２で用いる依存関係評価部関連スコアリングルールテーブルＴ１８２の一例を示す。当該スコアリングルールは、スコアリングルール記録部１８０にあらかじめ格納されている。依存関係評価部関連スコアリングルールテーブルＴ１８２は、記述評価部関連スコアリングルールテーブルＴ１８１と同様、カテゴリＴ１８２０と、ルールＩＤＴ１８２１と、スコアリングルールＴ１８２２と、対象言語Ｔ１８２３と、ブロック役割種別加算スコアＴ１８２４とを含む。なお、図６で示しているブロック役割種別加算スコアＴ１８２４はあくまで一例であり、図に掲載した数値に限られるものではない。

データ依存関係評価部１３２０の実行によって、ソースコード解析結果記録部１６０ソースコード制御関係分析結果テーブルＴ１６１より１ブロックずつ読み込み、依存関係評価部関連スコアリングルールテーブルＴ１８２のカテゴリＴ１８２０が”データ依存”であるものが順次評価されていく。

評価においては、ソースコード解析結果記録部１６０に格納されたデータ依存関係分析結果テーブルＴ１６２が参照される。

例えば、レコードＴ１８２５に記載されたルールを判定する際には、読み込んだブロックの条件文、及び処理文の変数を抽出し、モジュール名および変数名で依存関係評価部関連スコアリングルールテーブルＴ１８２を検索する。検索された変数に付与されたデータ依存ＩＤを取得し、再度当該データ依存ＩＤでデータ依存関係分析結果テーブルＴ１６２を検索する。得られた変数群の変数属性を参照し、その中に値が「画面フォーム」であるものが存在すれば、本ルールは成立したとし、評価対象であるブロックの「業務ルール判断処理」、「データチェック・形式変換判断処理」、「システムエラーチェック判断処理」、および「プログラムフロー制御判断処理」の役割に、各々＋２、＋２、−１、−１をスコアとして加算する。

図４に戻り、プロジェクト固有情報評価部１３３の実行によって、分析対象システムの開発プロジェクト固有の特徴に基づくスコアリングが行われ、例えば、項目辞書利用評価部１３３０と部品構成評価部１３３１から構成される。

図７に、プロジェクト固有情報評価部１３３の実行で用いられるプロジェクト固有情報評価部関連スコアリングルールテーブルＴ１８３の一例を示す。本スコアリングルールはスコアリングルール記録部１８０にあらかじめ格納されている。プロジェクト固有情報評価部関連スコアリングルールテーブルＴ１８３は、記述評価部関連スコアリングルールテーブルＴ１８１などと同様、カテゴリＴ１８３０と、ルールＩＤＴ１８３１と、スコアリングルールＴ１８３２と、対象言語Ｔ１８３３と、ブロック役割種別加算スコアＴ１８３４とを含む。

なお、図７で示しているプロジェクト固有情報評価部関連スコアリングルールテーブルＴ１８３はあくまで一例であり、図に掲載した数値に限られるものではない。

項目辞書利用評価部１３３０の実行によって、評価対象のブロックで利用される変数名やモジュール名などに、分析対象システムのデータ項目辞書に定められた名称が利用されているか否かに基づくスコアリングが行われ、プロジェクト情報記録部１７０にあらかじめ格納された分析対象システムのデータ項目辞書テーブルが参照される。

図８にデータ項目辞書テーブルＴ１７１の例を示す。データ項目辞書テーブルＴ１７１は、項目ＩＤと、項目名と、項目変数名と、説明とを含む情報である。

項目辞書利用評価部１３３０の実行によって、ソースコード解析結果記録部１６０のソースコード制御関係分析結果テーブルＴ１６１より１ブロックずつ読み込み、プロジェクト固有情報評価部関連スコアリングルールテーブルＴ１８３のカテゴリＴ１８３０が”項目辞書活用”であるものが順次評価されていく。

例えば、レコードＴ１８３５に記載されたルールを判定する際には、まず、項目辞書利用評価部１３３０は読み込んだブロックの条件文より変数名を抽出し、データ項目辞書テーブルＴ１７１の項目変数名に完全一致する文字列が存在するか否かが検索される。完全一致するものが存在すれば、本ルールは成立したとし、評価対象であるブロックの「業務ルール判断処理」、「データチェック・形式変換判断処理」、「システムエラーチェック判断処理」、および「プログラムフロー制御判断処理」の役割に、各々＋１、＋１、０、０をスコアとして加算する。

部品構成評価部１３３１の実行によって、評価対象のブロックが所属する、クラスやメソッドなどのモジュール名やその所属パッケージなどの構成情報に基づくスコアリングが行われ、プロジェクト情報記録部１７０にあらかじめ格納された分析対象システムの部品構成テーブルが参照される。

図８に、部品構成テーブルＴ１７２の例を示す。部品構成テーブルＴ１７２は、構成ＩＤと、構成名と、グループとを含む情報である。

部品構成評価部１３３１の実行によって、ソースコード解析結果記録部１６０のソースコード制御関係分析結果テーブルＴ１６１より１ブロックずつ読み込み、プロジェクト固有情報評価部関連スコアリングルールテーブルＴ１８３のカテゴリＴ１８３０が”部品構成”であるものが順次評価されていく。

例えば、レコードＴ１８３６に記載されたルールを判定する際には、まず、部品構成評価部１３３１は読み込んだブロックのモジュール名を抽出し、部品構成テーブルＴ１７２の構成名に一致するものが検索される。一致するものが存在すれば、本ルールは成立したとし、評価対象であるブロックの「業務ルール判断処理」、「データチェック・形式変換判断処理」、「システムエラーチェック判断処理」、および「プログラムフロー制御判断処理」の役割に、各々＋１、＋１、０、０をスコアとして加算する。

図４に戻り、相関評価部１３４の実行によって、これまで記述評価部１３１、依存関係評価部１３２、プロジェクト固有情報評価部１３３で述べてきたようなスコアリングルールの判定結果に基づくスコアリングが行われ、例えば、分類結果前後関係評価部１３４０と評価相関ルール評価部１３４１とから構成される。

図９に、相関評価部１３４の実行で用いられる、相関評価部関連スコアリングテーブルＴ１８４の一例を示す。本スコアリングルールはスコアリングルール記録部１８０にあらかじめ格納されている。相関評価部関連スコアリングテーブルＴ１８４は、記述評価部関連スコアリングルールテーブルＴ１８１などと同様、カテゴリＴ１８４０と、ルールＩＤＴ１８４１と、スコアリングルールＴ１８４２と、対象言語Ｔ１８４３と、ブロック役割種別加算スコアＴ１８４４とを含む。

なお、図９で示している相関評価部関連スコアリングルールテーブルＴ１８４はあくまで一例であり、図に掲載した数値に限られるものではない。

分類結果前後関係評価部１３４０の実行によって、評価対象であるブロックの前後のブロックにおいて貢献役割スコアリングプログラム１３０が仮付与した分類の種類に基づくスコアリングが行われる。後述するが、すでに貢献役割スコアリングプログラム１３０の実行でブロックの分類が付与されているのは、複数回の実行を想定しているためである。

項目辞書利用評価部１３３０の実行によって、ソースコード解析結果記録部１６０のソースコード制御関係分析結果テーブルＴ１６１より１ブロックずつ読み込み、プロジェクト固有情報評価部関連スコアリングルールテーブルＴ１８４のカテゴリＴ１８４０が”分類前後関係”であるものが順次評価されていく。

例えば、レコードＴ１８４５に記載されたルールを判定する際には、まず、ソースコード制御関係分析結果テーブルＴ１６１の後続ブロックＮｏに基づき、評価対象ブロックの直前のブロックが抽出される。抽出された直前ブロックのブロック貢献役割種別が「業務ルール判断処理」であれば本ルールは成立したとし、評価対象であるブロックの「業務ルール判断処理」、「データチェック・形式変換判断処理」、「システムエラーチェック判断処理」、および「プログラムフロー制御判断処理」の役割に、各々＋１、０、０、０をスコアとして加算する。

評価相関ルール評価部１３４１の実行のよって、評価対象のブロックにおいて、これまでに述べた記述評価部１３１、依存関係評価部１３２、プロジェクト固有情報評価部１３３、相関評価部１３４の各スコアリングルールの成立および不成立の結果に基づくスコアリングが行われる。評価相関ルール評価部１３４１の実行によって、ソースコード解析結果記録部１６０のソースコード制御関係分析結果テーブルＴ１６１より１ブロックずつ読み込み、プロジェクト固有情報評価部関連スコアリングルールテーブルＴ１８４のカテゴリＴ１８４０が”ルール相関”であるものが順次評価されていく。

例えば、レコードＴ１８４６に記載されたルールを判定する際には、まず、評価対象のブロックＮｏに基づき、ソースコード解析結果記録部１６０より、評価対象ブロックの成立ルールリストが取得される。抽出された成立ルールリストの中に、「Ｒ００００１」および「Ｒ３０００１」が同時に含まれれば本ルールは成立したとし、評価対象であるブロックの「業務ルール判断処理」、「データチェック・形式変換判断処理」、「システムエラーチェック判断処理」、および「プログラムフロー制御判断処理」の役割に、各々＋１、０、０、０をスコアとして加算する。尚、本例の意味は、Ｒ００００１すなわち「条件部がＩＦ文である」およびＲ３０００１「同一データＩＤに変数属性『画面フォーム』を含む変数が存在する」が同時に成立する場合、「業務ルール判断処理」である尤度がスコア上高まるということである。

なお、本例においてプロジェクト固有情報評価部関連スコアリングルールテーブルＴ１８４のカテゴリＴ１８４０が”ルール相関”であるものは２つのルールＩＤが同時に成立するもののみを挙げているが、当然２つ以上複数のルールＩＤの相関関係を扱うことができるし、不成立であることを条件とすることもできる。

以上、貢献役割スコアリングプログラム１３０の実行によって、記述評価部１３１、依存関係評価部１３２、プロジェクト固有情報評価部１３３、相関評価部１３４の各部の実行により評価されたスコアリング結果に基づき、各ブロックについて尤度の高い貢献役割分類が付与される。本実施例においては、スコアが最高となった分類を、当該ブロックの貢献役割分類として説明するが、閾値や、相対的な倍率に基づき、１つのブロックが複数の役割に属するよう分類を行ってもかまわない。

以上、図４を用いて、貢献役割スコアリングプログラム１３０を構成する各評価機能の働きについて説明した。次に、図１０を用いて、貢献役割スコアリングプログラム１３０の実行が全体としてどのように振る舞うかについて説明する。

図１０は、貢献役割スコアリングプログラム１３０で実行される動作の流れの一例を示すフローチャートＳ１００である。

まず、ソースコード解析結果記録部１６０内のブロック処理履歴が初期化され、また、現在の状態の各ブロックに割り当てられた項目役割分類が退避し記録され、以降の処理に備える（ステップＳ１００１）。

次に、ソースコード解析結果記録部１６０内のソースコード制御関係分析結果テーブルＴ１６１が参照され、未処理のブロックが存在するか否かをチェックされる（ステップＳ１０１２）。もし、未処理のブロックが存在すればステップＳ１００３が実行され、未処理のブロックが存在しなければステップＳ１００８へ処理を進める。以降では、未処理のブロックが存在した場合を説明する。

次に、ソースコード解析結果記録部１６０内のソースコード制御関係分析結果テーブルＴ１６１より未処理のブロックが１ブロック読み出される（Ｓ１００３）。

次に、Ｓ１００３で読み出したブロックに対して、記述評価部１３１を用いてスコアリング処理が実施される（Ｓ１００４）。 次に、Ｓ１００３で読み出したブロックに対して、依存関係評価部１３２を用いてスコアリング処理が実施される（Ｓ１００５）。

次に、Ｓ１００３で読み出したブロックに対して、プロジェクト固有情報評価部１３３を用いてスコアリング処理が実施される（Ｓ１００６）。

次に、Ｓ１００３で読み出したブロックに対して、相関評価部１３４を用いてスコアリング処理が実施される（Ｓ１００４７）。

以上の処理が、ソースコード制御関係分析結果テーブルＴ１６１内のブロックすべてで実施される。

さらに、Ｓ１００２で未処理のブロックが存在しないと判定された場合について、以下に説明する。

まず、スコアリングが実施されたソースコード制御関係分析結果テーブルＴ１６１の各ブロックが参照され、各々のブロックについて、スコアが最も高い役割分類について、当該ブロックの貢献役割分類が割り当てられる（Ｓ１００８）。

例えば、ブロックＮｏ”１１”のブロックの「業務ルール判断処理」、「データチェック・形式変換判断処理」、「システムエラーチェック判断処理」、および「プログラムフロー制御判断処理」の役割スコアがそれぞれ、”＋２０．３”、”＋１２．５”、”＋１．０”、”−２．１”であった場合、ブロックＮｏ”１１”の貢献役割分類は「業務ルール判断処理」である。

、Ｓ１００８で得られた各ブロックの貢献役割分類と、Ｓ１００１で退避記録されていた各ブロックの貢献分類の差分が計算される（Ｓ１００９）。

そして、Ｓ１００９の結果が参照され、差分の有無がチェックされる（Ｓ１０１０）。もし差分が存在しなければ処理を終了する。差分が存在すれば、Ｓ１００１へ処理を進める。

以上のようにして、Ｓ１００８で得られた結果が、直前の実行と比較して安定するまで処理が繰り返し実行される。繰り返しの実行がされる場合、Ｓ１００４〜Ｓ１００６は各回結果が同様となるため、省略して処理が進められてもよい。

図１に戻り、結果出力プログラム１５０の実行によって、貢献役割スコアリングプログラム１３０の実行により、ソースコード解析結果記録部１６０へ書き込まれた各ブロックの貢献役割分類に基づき、出力結果が構成され、出力装置１０７もしくは通信装置１０８を通じて、開発者に対して分類結果を提示される。

図１１は、結果出力プログラム１５０による出力結果の一例である。各ソースコードのブロックに対して、貢献役割スコアリングプログラム１３０で決定した貢献役割分類を合わせて示したり、目的に応じて、例えば、業務ルール判断処理の抽出の際には、貢献役割分類が「業務ルール判断処理」のものを強調表示（注目優先度に「◎」を付記するなど）したりすることで、着目すべきブロックの確認を容易にする。

上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれら実施形態のみに限定する趣旨ではない。例えば、上述した実施例は本説明を分かり易く説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。

また、上述の各構成、機能、処理部、処理手段などは、それらの一部または全部を例えば集積回路で設計する等によりハードウェアで実現しても良い。また、上述の各構成、機能などは、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。下記機能を実現するプログラム、テーブル、ファイルなどの情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記憶媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしもすべての制御線や情報線を示しているとは限らない。実際にはほとんどすべての構成が相互に接続されていると考えてもよい。

１００ ソースコードからの仕様抽出装置
１０１ ＣＰＵ
１０２ メモリ
１０３ 外部記憶装置
１０４ バス
１０５ 外部インターフェース
１０６ 入力装置
１０７ 出力装置
１０８ 通信装置
１１０ ソースコード入力プログラム
１２０ ソースコード依存関係分析プログラム
１３０ 貢献役割スコアリングプログラム
１３１ 記述評価部
１３２ 依存関係評価部
１３３ プロジェクト固有情報評価部
１３４ 相関評価部
１４０ 役割別ソースコード抽出プログラム
１５０ 結果出力プログラム
１６０ ソースコード解析結果記録部
１７０ プロジェクト情報記録部
１８０ スコアリングルール記録部

Claims (3)

1. 分析対象システムのソースコードであって、条件文と処理分とからなるブロック情報で構成されるソースコードから仕様を抽出するための仕様抽出装置であって、
   分析対象システムのソースコードを受け付けるソースコード入力実行部と、
   受け付けたソースコードの制御関係を分析するソースコード依存関係分析実行部と、
   受け付けたソースコードと分析された制御関係の結果が保持されるソースコード解析結果記録部と、
   保持されるソースコードと分析された制御関係の結果から、ソースコードを構成する各ブロック情報の貢献役割のスコアリングを行う貢献役割スコアリング実行部と、
   貢献役割のスコアリング結果に基づき、スコアが高いソースコードの貢献役割を出力する結果出力部と、
   を備えることを特徴とする仕様抽出装置。
2. 前記ソースコードを構成する前記各ブロック情報の貢献役割は、業務ルール判断処理、データチェック・形式変換判断処理、システムエラーチェック判断処理、及び、プログラムフロー制御判断処理であることを特徴とする請求項１に記載の仕様抽出装置。
3. 前記貢献役割のスコアリングを行うためのスコアリングルールであって、前記ソースコードの記述、前記ソースコードと分析された制御関係の結果、あるいは、分析対象システムに固有の特徴に関するスコアリングルールを保持するスコアリングルール記録部をさらに備え、
   前記スコアリングルールに基づき貢献役割のスコアリングを行うことを特徴とする請求項1に記載の仕様抽出装置。

Images