JP6310865B2 - ソースコード評価システム及び方法 - Google Patents

Description

本発明は、エンタープライズシステム（業務システム）の評価に関する。その中でも、アプリケーションの保守性向上のためのソースコード評価に関する。

エンタープライズシステムのアプリケーションは場当たり的な機能追加によって時間経過と共にソースコードが複雑化することがある。複雑化するとシステムに機能追加・修正を行う際作業者は不良を入れ込みやすくなってしまう。この不良を入れ込みやすくなるソースコードの構造を「アンチパターン」という。アンチパターンはプログラミングの文法には問題なくコンパイルは通る。

しかし、可読性・保守性が悪化し、作業者がソースコードに書かれている処理フローの理解を間違えたり、機能追加・修正の作業の抜け漏れを誘発するよう構造になっている。アンチパターンはすぐにはシステム障害を引き起こしはしないが、放置すると後のシステム障害の原因になりうる。

アンチパターンには特徴によって知られているものだけでも数十種類存在する。例えば、「1メソッドが長すぎる」アンチパターンや、「引数が多すぎる」アンチパターンなどである。これら特徴に分類したアンチパターンそれぞれを「アンチパターン因子」と呼ぶ。

ソースコードに存在するアンチパターン因子を修正することをリファクタリングという。リファクタリング作業は大量のソースコードを読み、アンチパターン因子を抽出し、アンチパターン因子の特徴に合った方法でリファクタリングを行う。これは多大な工数がかかるだけでなく、リファクタリング作業者に高いスキルが必要である。

そこで、ソースコードに存在するアンチパターン因子の特徴を自動的に抽出し、少ない工数でアンチパターン抽出・リファクタリング作業を行う技術の研究がなされている。例えば特許文献１や２ではサイクロマティック複雑度やコード行数といった、ソースコードの複雑度を定量的に評価するメトリクスを利用し、その計測結果から複雑度の高いモジュールを抽出・提示している。さらにその複雑度の度合いや複雑性に起因するコストによってリファクタリングの優先度を提示する。

WO2008/020468 特開2014-032466

上記の特許文献においては、複雑化されたソースコードへの対応が困難な場合が多い。ここで、ソースコードが複雑な理由は大きく二つある。一つは処理フローそのものが複雑で、ソースコードの構造が複雑にならざるを得ないもの。もう一つは運用開始当初は単純な構造のソースコードであったが、場当たり的な機能追加を繰り返してきたため複雑な構造になったものがある。前者はリファクタリングの必要はなく、後者はリファクタリングの必要がある。

上記特許文献１，２においてはソースコードの複雑性にのみ着目している。そのため、リファクタリングの必要がある複雑なソースコードだけでなく、リファクタリングが必要ない複雑なソースコードも抽出してしまい、リファクタリング作業の効率を向上できない。

上記の課題を解決するために、本発明では、リファクタリングの必要があるソースコード、言い換えると複雑な構造のソースコードを抽出するものである。さらに、抽出したソースコードのアンチパターン因子の特徴からリファクタリング手法を提案し、リファクタリングの効果やコストの観点からモジュールごとのリファクタリング優先度を提示するものである。また、システムのログなど複数の資源から複数種類のメトリクス・情報を取得し、それを組み合わせて種々のアンチパターン因子が存在しているか否かを評価することも本発明の一態様である。

さらに、本発明の望ましい態様においては、構成管理システムからソースコードの各モジュール（クラス）単位におけるメトリクス取得手段と、ソースコードの各バージョン間の差分を取得し、差分部についてのメトリクス取得手段と、構成管理システムログについてのメトリクス取得手段と、稼動ログについてのメトリクス計測手段と、取得したメトリクス値から各種アンチパターン因子に該当するか否かを評価する手段と、該当したアンチパターン因子の種類からリファクタリング手法を提案する手段と、リファクタリング優先度を算出する手段と、リファクタリング手段・優先度を画面に表示する。

本発明によれば、大規模ソースコードに存在するアンチパターン因子を効率的により効率的に抽出可能になる。

本発明の一実施の形態における機能構成図である。 本発明の一実施の形態における機能ブロック図である。 本発明の一実施の形態における機能内のセンサ・メトリクス値テーブルの例を示す図である。 本発明の一実施の形態における差分コードメトリクス値テーブルに格納されるデータの一例を示す図である。 本発明の一実施の形態におけるソースコードメトリクス値テーブルに格納されるデータの一例を示す図である。 本発明の一実施の形態におけるアンチパターン評価の処理フローを示す図である 本発明の一実施の形態で用いるアンチパターン因子1の特徴を示す図である。 本発明の一実施の形態で用いるアンチパターン因子1に対応するアンチパターン評価ロジック定義ファイルの一例を示す図である。 本発明の一実施の形態で用いるアンチパターン因子1に対応するアンチパターン評価利用メトリクス閾値定義ファイルの一例を示す図である。 本発明の一実施の形態で用いるアンチパターン因子2の特徴を示す図である。 本発明の一実施の形態で用いるアンチパターン因子2に対応するアンチパターン評価ロジック定義ファイルの一例を示す図である。 本発明の一実施の形態で用いるアンチパターン因子2に対応するアンチパターン評価利用メトリクス閾値定義ファイルの一例を示す図である。 本発明の一実施の形態におけるアンチパターン判定テーブルに格納されるデータの一例を示す図である。 本発明の一実施の形態におけるアンチパターンリファクタリング手順テーブルに格納されるデータの一例を示す図である。 本発明の一実施の形態におけるリファクタリング手法案一覧テーブルに格納されるデータの一例を示す図である。 本発明の一実施の形態におけるリファクタリング手法・優先度一覧画面の一例を示す図である。 本発明の一実施の形態におけるアンチパターン評価ロジック定義ファイルを鑑みた効果的なセンサ実行のロジックを示す図である。

以下、本発明の一実施の形態について、図面を用いて説明する。まず、図1に本実施の形態によるソースコード評価システムの機能構成図を示す。計算機1はメモリ10と、HDD11と、CPU12と、表示装置13と、入力装置14とを備える。メモリ10は差分コードメトリクス取得部と、ソースコードメトリクス取得部と、構成管理ログメトリクス取得部と、稼動ログメトリクス取得部と、アンチパターン評価部と、リファクタリング方法提案部と、リファクタリング手法・優先度一覧画面表示部とを備える。これらは、すなわち、HDD11に格納された処理プログラムがメモリ10上に展開されたものであり、CPU12で演算が実行され、各機能が実現される。HDD11はソースコード格納部111と、稼動ログ格納部112と、差分コードメトリクス値テーブル格納部113と、ソースコードメトリクス値テーブル格納部114と、アンチパターン評価ロジック定義ファイル格納部115と、アンチパターン評価利用メトリクス閾値定義ファイル格納部116と、アンチパターン判断テーブル格納部117と、アンチパターンリファクタリング手順テーブル格納部118と、リファクタリング手法一覧テーブル格納部119とを備える。これらは、上述したメモリ10の各部、つまり、プログラムの各機能で用いる各種データがHDD11に保持されていることを示す。

図2に本発明の実施の形態によるソースコード評価システムの機能ブロック図を示す。つまり、上述したプログラムの各機能の概要を説明する。
ソースコード格納部111は、ソフトウェア構成管理システムである。ソースコードのバージョン管理や変更の記録など行っている。差分コードメトリクス取得部101は、ソースコード格納部111からあるバージョンのソースコードのクラスと1つ前のバージョンのクラスを取得し、差分の有無を算出する。差分がある場合、コード行数やネスト数などのメトリクス計測を行い、その結果を差分コードメトリクス値テーブル格納部113に出力する。また、ソースコードメトリクス取得部102は、ソースコード格納部111から各バージョンの各クラスを取得し、メトリクス計測を行いその結果をソースコードメトリクス値テーブル格納部114へ出力する。構成管理ログメトリクス取得部103はソースコード修正日などの変更履歴に関連する情報取得を行い、その結果をソースコードメトリクス値テーブル格納部114へ出力する。

稼動ログ格納部112は、システム資源の負荷の大きさやシステム障害などのシステムの稼動状況の履歴ログを格納する。稼働ログメトリクス取得部104は稼働ログ格納部112から稼働ログを取得し、障害発生日などの情報を抽出しその結果を出力する。
差分コードメトリクス取得部101と、ソースコードメトリクス取得部102と、構成管理ログメトリクス取得部103と、稼働ログメトリクス取得部104とはシステム資源からアンチパターン評価に必要な情報をとる機能であることから、まとめて「センサ部」と定義する。また各種メトリクス・情報を取得する個々の機能を「センサ」と呼ぶ。

図3にセンサとセンサに必要なパラメータ、そしてセンサが出力する値の形式の一例を示す。センサの列には取得するメトリクス・情報の種類が記述されている。パラメータの列にはセンサを実行させる際必要なソースコードの情報の形式が記述されている。値の列はセンサ実行の結果出力される値の形式が記述されている。取得手段の列はセンサが101、102、103、104のうちどこの機能によるものなのかが記述されている。

図4に、差分コードメトリクス取得部101で出力され差分コードメトリクス値テーブル格納部113に格納されるテーブルの形式の一例を示す。テーブルはソースコードの各クラスごとに作成される。あるクラスのテーブル内の”バージョン差分”行にはどのバージョンとどのバージョンのクラスの差分をとっているかが示されており、その差分部のメトリクス値が格納されている。

図5にソースコードメトリクス取得部102と、構成管理ログメトリクス取得部103と、稼働ログメトリクス取得部104とが出力し、ソースコードメトリクス値テーブル格納部114に格納されているテーブルの形式の一例を示す。テーブルはソースコードの各クラスごとに作成される。あるクラスのテーブル内の”バージョン”行にはバージョン番号が示されており、それぞれのバージョンでのメトリクス値が格納されている。
アンチパターン評価部105、は各クラスが各種アンチパターン因子に該当するか否かを評価する機能を備える。

図6に、アンチパターン評価部105における処理フローを示す。ステップ1051から実行される。ステップ1051では、アンチパターン評価ロジック定義ファイル格納部115から評価したいアンチパターン因子に対応するアンチパターン評価ロジック定義ファイルを取得する。ステップ1052では、アンチパターン評価利用メトリクス閾値定義ファイル格納部116から評価したいアンチパターン因子に対応するアンチパターン評価利用メトリクス閾値定義ファイルを取得する。ステップ1053では、ステップ1051で取得したアンチパターン評価ロジック定義ファイルからアンチパターン評価に用いるメトリクス値を把握し、それを差分コードメトリクス値テーブル格納部113と、ソースコードメトリクス値テーブル格納部114から取得する。ステップ1054では、ステップ1051で取得したアンチパターン評価ロジック定義ファイルに記されたロジックに従い、各クラスがアンチパターン因子に該当するか否かを判断する。ステップ1055で、もしあるクラスがアンチパターン因子に該当すると判明したなら、ステップ1056で、アンチパターン判定テーブル格納部117の該当アンチパターン因子の欄に「○」を格納する。ステップ1055で、もしあるクラスがアンチパターン因子に該当しないと判明したなら、ステップ1056で、アンチパターン判定テーブル格納部117の該当アンチパターン因子の欄に「×」を格納する。

次に、評価対象であるアンチパターン因子1に該当するか否かを評価する処理の具体例を図7乃至図9を用いて説明する。
まず、図7にアンチパターン因子1の特徴を示す。アンチパターン因子1は業務共通クラスに個々の業務処理を場当たり的にif文で追加し、巨大になったクラスである。よって処理フローを追うのが複雑になり可読性が悪化しているアンチパターンである。これはコード規模が大きく、新バージョンソースコードは旧バージョンソースコードと比べ新たな差分が加わり、その差分がif文節であり、同じクラスのバージョン間での差分発生回数が多く、結果現状ソースコードのネスト数が大きい、という特徴を有している。
上記からアンチパターン因子1は、「コード行数」が100以上、「コード比較」で差分が存在し、「分岐」で差分がif文節であり、if文節の差分が5回以上あり、現状版ソースコードのネスト数が5以上であれば該当するというロジックとする。

図8に、上記ロジックを記述言語で示す。図8はアンチパターン評価ロジック定義ファイル格納部115に格納されている。
図8で記述されているロジックは以下の内容である。

まず、アンチパターン評価を行うソースコードのクラスを宣言（特定）し、センサ「過去コード」を利用し対象クラスの過去バージョンのコードを宣言する。ここでは、各クラス、コードについて、対象となるもののすべてを特定するようにしてもよい。センサ「コード比較」を利用し1つのクラスの各バージョンの差分をとり、センサ「分岐」を利用し各差分が分岐文であるか否かを判定する。分岐文であれば判定値1、分岐文であれば判定値0と判定され、各差分の分岐文判定値の総和を導出する。その上で分岐文判定値の総和がi以上、かつ、センサ「コード行数」を利用し導出した最新のソースコードのコード行数がj以上、かつ、センサ「ネスト」を利用し導出した最新のソースコードのネスト数がk以上であればアンチパターン因子1に該当する。なお、i、j、kに入る値は、アンチパターン評価利用メトリクス閾値定義ファイル格納部内116で設定される。その内容を、以下で説明する。

図9は、上記ロジックで利用されているメトリクス閾値を定義したものである。図9はアンチパターン評価利用メトリクス閾値定義ファイル格納部116に格納されている。図8のロジック記述言語内で設定されたi、j、kのパラメータはそれぞれ分岐文の修正回数、上限行数、上限ネスト数である。アンチパターン因子1であると判定するための閾値はi、j、kそれぞれ5以上、100以上、4以上と設定されている。

さらに、アンチパターン因子2に該当するか否かを評価する処理の具体例を図10乃至図12を用いて説明する。
まず、図10にアンチパターン因子2の特徴を示す。アンチパターン因子2は機能追加の際、同じような処理を複数個所にif文で追加したものである。よって追加部を修正する際、他の同様の処理の箇所にも修正を行う必要があり、修正ミスの可能性があるアンチパターンである。これは、新バージョンソースコードは旧バージョンソースコードと比べ新たな差分が加わり、同じクラスのバージョン間での差分発生が複数回あり、その差分がif文節であり、その差分が他ソースコードとコードクローンである。

上記からアンチパターン因子2は、「コード比較」で差分が存在し、「分岐」で差分はif文節が存在し、if文節の差分が2回以上あり、その差分がクローンであれば該当するというロジックとする。

次に、図11に上記ロジックを記述言語で示す。図11はアンチパターン評価ロジック定義ファイル格納部115に格納されている。
図11で記述されているロジックは以下の内容である。
最初にアンチパターン評価を行うソースコードクラスを宣言し、センサ「過去コード」を利用し対象クラスの過去バージョンのコードを宣言する。ここでは、各クラス、コードについて、対象となるもののすべてを特定するようにしてもよい。

まず、センサ「コード比較」を利用し1つのクラスの各バージョンの差分をとり、センサ「分岐」を利用し各差分が分岐文であるか否かを判定する。分岐文であれば判定値1、分岐文であれば判定値0と判定され、各差分の分岐文判定値の総和を導出する。さらに、センサ「クローン」を利用し各差分がコードクローンであるかを検査する。その上で、分岐文判定値の総和かm以上、かつ、差分がクローンであればアンチパターン因子2に該当する。なお、mに入る値は、アンチパターン評価利用メトリクス閾値定義ファイル格納部内116で設定される。これらについて、以下で説明する。

図12は、上記ロジックで利用されているメトリクス閾値を定義したものである。図12はアンチパターン評価利用メトリクス閾値定義ファイル格納部116に格納されている。図11のロジック記述言語内で設定されたmのパラメータはコード修正回数である。アンチパターン因子1であると判定するための閾値はmが2以上と設定されている。
図13に、アンチパターン評価部105から出力されアンチパターン判定テーブル格納部117に格納されるテーブルの例を示す。各クラスが各種アンチパターン因子に該当していれば「○」、該当していなければ「×」が格納されている。

次に、図14に、アンチパターン因子ごとのリファクタリング手順と過去の実績から計算した1Kstepあたりのリファクタリング想定工数のテーブルの例を示す。このテーブルはアンチパターンリファクタリング手順テーブル格納部118に格納されている
ここで、リファクタリング方法提案部106は、アンチパターン判定テーブル格納部117から図13のテーブルと、アンチパターンリファクタリング手順テーブル格納部118から図14のテーブルと、ソースコードメトリクス値テーブル格納部114から各クラスの障害発生回数とを取得し、リファクタリング要素一覧テーブルを作成する。

次に、図15にリファクタリング方法提案部106で作成され、リファクタリング要素一覧テーブル格納部に格納されたリファクタリング要素一覧テーブルの一例を示す。各クラスが各種アンチパターン因子に該当するか否を示す欄と、各クラスの1年あたりの障害発生回数を示す欄と、クラス各々に該当するアンチパターン因子の種類からどのようなリファクタリング手法をとるべきか提示する欄と、各クラスのリファクタリング想定工数を各クラスのステップ数にあわせて計算し示す欄とがある。
図16に、リファクタリング手法・優先度一覧画面表示部107で表示される内容の一例を示す。画面にはそのプロジェクトの運用予定期間を入力する欄と、そのプロジェクトにおいて1回の障害修正にかかるコストを入力する欄とがあり、さらに、リファクタリング優先度ランキング番号を示す欄と、クラス名を示す欄と、各クラスに存在するアンチパターン因子の種類を示す欄と、各クラスのとるべきリファクタリング手法を提示する欄と、リファクタリング優先度評価値を示す欄とを有するテーブルが表示されている。
リファクタリング優先度評価値は以下の式で導出する。
リファクタリング 優先度評価値＝リファクタリング効果−リファクタリング工数
＝{年平均障害発生回数（回/365日）
×運用予定期間（日）
×1回の障害修正にかかるコスト（人月/回）}
− リファクタリング想定工数（人月）…（数1）
リファクタリング優先度ランキングは、リファクタリング工数に対してリファクタリング効果が大きいクラス、つまりリファクタリング優先度評価値が大きいクラスの優先度が高くなるように順位づけし、表示する。

図17に101、102、103、104のセンサ部の実行を効率的に行うための処理フローを示す。ステップ1001から実行される。ステップ1001では、アンチパターン評価ロジック定義ファイル格納部115からアンチパターン評価ロジック定義ファイルを読み込み、アンチパターン評価に必要なメトリクスの種類を取得する。ステップ1002ではアンチパターン評価利用メトリクス閾値定義ファイル格納部116からアンチパターン因子評価に必要なメトリクスの閾値の判定条件を取得する。ステップ1003では、取得したメトリクスの中で、102の機能のみでアンチパターンか否かを判断できるメトリクスを列挙する。ステップ1004では、各クラスの上記メトリクス計測を行う。ステップ1005では、ステップ1004で得られたメトリクス値に対して、ステップ1002で得られた閾値の判定条件を利用して閾値判定を行う。

ステップ1006で、もし閾値判定の結果、判定条件に合致していれば、ステップ1007でそのクラスは以後メトリクス計測対象であると判定され、アンチパターン評価部105において計測対象となる。一方ステップ1006で、もし閾値判定の結果、判定条件に合致してなければ、ステップ1008でそのクラスは以後メトリクス計測対象外であると判定され、アンチパターン評価部105において計測対象とはならない。
なお、上記のセンサ実行の処理フローを用いることで、アンチパターン評価部105において対象となるクラスの数を絞り込むことができ、効率的である。

以上、本発明の一実施形態によれば、アンチパターン因子の抽出を、少ない工数かつ高精度で抽出することが可能である。またアンチパターン因子抽出・リファクタリングの作業者が熟練者でなくても容易にそれを行うことができる。

１…計算機、１０…メモリ、１１…ＨＤＤ、１２…ＣＰＵ、１３…表示装置、１４…入力装置、１０１…差分コードメトリクス取得部、１０２…ソースコードメトリクス取得部、１０３…構成管理ログメトリクス取得部、１０４…稼働ログメトリクス取得部、１０５…アンチパターン評価部、１０６…リファクタリング方法提案部、１０７…リファクタリング手法・優先度一覧画面表示部、１１１…ソースコード格納部、１１２…稼働ログ格納部、１１３…差分コードメトリクス値テーブル格納部、１１４…ソースコードメトリクス値テーブル格納部、１１５アンチパターン評価ロジック定義ファイル格納部、１１６…アンチパターン評価利用メトリクス閾値定義ファイル格納部、１１７…アンチパターン判定テーブル格納部、１１８…アンチパターンリファクタリング手順テーブル格納部、１１９…リファクタリング要素一覧テーブル格納部

Claims (5)

1. システムで用いられるプログラムを分析し、当該プログラムのアンチパターンを抽出するソースコード評価システムにおいて、
   前記システムのソースコードを含む稼働に関する情報からメトリクスを計測する手段と、
   前記計測されたメトリクスを用いて、前記ソースコードがアンチパターンの該当可否をその複雑さ示す指標を用いて評価する手段と、
   前記評価された結果について、前記ソースコードのリファクタリングの優先度を算出・提示する手段を有することを特徴とするソースコード評価システム
2. 請求項１に記載のソースコード評価システムにおいて、
   前記メトリクスの項目を要素とし、前記アンチパターンを記述する手段をさらに有することを特徴とするソースコード評価システム。
3. 請求項１に記載のソースコード評価システムにおいて、
   前記ソースコードの各バージョン間の差分を取得し、取得された差分についてのメトリクスを取得する手段と、
   取得された前記差分を用いて、前記ソースコードがアンチパターンの該当可否を評価する手段をさらに有することを特徴とするソースコード評価システム。
4. 請求項１に記載のソースコード評価システムにおいて、
   リファクタリング実施による障害発生削減効果とリファクタリング実施の際の工数を見積もり、当該見積もり結果からリファクタリング優先度を掲示する手段をさらに有することを特徴とするソースコード評価システム。
5. 請求項１に記載のソースコード評価システムにおいて、
   前記ソースコードから計測した前記メトリクスに基づいて、特定条件を満たすメトリクスの絞込みを行い、絞り込まれた前記メトリクスに基づいて、他のメトリクスの取得可否を判定する手段をさらに有することを特徴とするソースコード評価システム。

Images