(57)【要約】      （修正有）【課題】ソフトウェアの全体構造に関する定量的評価を提供する。【解決手段】分析装置１０は、複数のコードの間の依存関係を検出し、依存関係に基づいて複数のコード１３ａ〜１３ｄをクラスタ１４ａ、１４ｂに分類し、また、複数のコード１３ａ〜１３ｄそれぞれがディレクトリ１５ａ、１５ｂ、１５ｃの何れかに属することを示すディレクトリ情報１５を取得する。分析装置１０は、少なくとも一のディレクトリ１５ａ、１５ｂ、１５ｃについて、当該一のディレクトリ１５ａ、１５ｂ、１５ｃに属するコード１３ａ〜１３ｄであってクラスタ１４ａ、１４ｂそれぞれに分類されたコード１３ａ〜１３ｄの数を計数する。分析装置１０は、クラスタ１４ａ、１４ｂの間のコード数の分布に基づいて、当該一のディレクトリ１５ａ、１５ｂ、１５ｃに属するコード１３ａ〜１３ｄの分散状況を示す評価値１６ａ、１６ｂ、１６ｃを算出する。【選択図】図１
2017068534.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータが実行する分析方法であって、
ソフトウェアの処理を記載した複数のコードの間の依存関係を検出し、前記依存関係に基づいて前記複数のコードを複数のクラスタに分類し、また、前記複数のコードそれぞれが複数のディレクトリの何れかに属することを示すディレクトリ情報を取得し、
前記ディレクトリ情報が示す前記複数のディレクトリのうち少なくとも一のディレクトリについて、前記複数のコードのうち前記一のディレクトリに属するコードであって、前記複数のクラスタそれぞれに分類されたコードの数を計数し、
前記複数のクラスタの間の前記コードの数の分布に基づいて、前記一のディレクトリに属するコードの分散状況を示す評価値を算出する、
分析方法。
【請求項２】
前記一のディレクトリを含む前記複数のディレクトリそれぞれについて、前記複数のクラスタそれぞれの前記コードの数を計数し、前記評価値を算出する、
請求項１記載の分析方法。
【請求項３】
前記コンピュータが更に、
前記複数のディレクトリに対応する第１の軸と前記複数のクラスタに対応する第２の軸とを含むマップであって、ディレクトリとクラスタの組に対応する前記コードの数に応じたマークを当該組に対応する位置に配置したマップを生成する、
請求項２記載の分析方法。
【請求項４】
前記評価値は、前記コードの数が閾値以上になるクラスタの数に関する値である、
請求項１記載の分析方法。
【請求項５】
ソフトウェアの処理を記載した複数のコードと、前記複数のコードそれぞれが複数のディレクトリの何れかに属することを示すディレクトリ情報とを記憶する記憶部と、
前記複数のコードの間の依存関係を検出し、前記依存関係に基づいて前記複数のコードを複数のクラスタに分類し、前記ディレクトリ情報が示す前記複数のディレクトリのうち少なくとも一のディレクトリについて、前記複数のコードのうち前記一のディレクトリに属するコードであって、前記複数のクラスタそれぞれに分類されたコードの数を計数し、前記複数のクラスタの間の前記コードの数の分布に基づいて、前記一のディレクトリに属するコードの分散状況を示す評価値を算出する演算部と、
を有する分析装置。
【請求項６】
コンピュータに、
ソフトウェアの処理を記載した複数のコードの間の依存関係を検出し、前記依存関係に基づいて前記複数のコードを複数のクラスタに分類し、また、前記複数のコードそれぞれが複数のディレクトリの何れかに属することを示すディレクトリ情報を取得し、
前記ディレクトリ情報が示す前記複数のディレクトリのうち少なくとも一のディレクトリについて、前記複数のコードのうち前記一のディレクトリに属するコードであって、前記複数のクラスタそれぞれに分類されたコードの数を計数し、
前記複数のクラスタの間の前記コードの数の分布に基づいて、前記一のディレクトリに属するコードの分散状況を示す評価値を算出する、
処理を実行させる分析プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は分析方法、分析装置および分析プログラムに関する。
【背景技術】
【０００２】
情報処理システム上で実行されるアプリケーションソフトウェアを新規に開発するとき、通常は各種の設計情報が作成される。新規開発時に作成された設計情報はその後に行われるアプリケーションソフトウェアの保守・改変のために有用である一方、そのような設計情報が保守・改変のときまで保管されていないことも多い。また、アプリケーションソフトウェアの運用開始後に軽微な改変を繰り返し行う場合、改変についての設計情報が作成されないことや保管されないことがあり、保管されている設計情報と現在のアプリケーションソフトウェアの実装とが整合しないこともある。
【０００３】
このため、ソースコードやオブジェクトコードなどの実装コードを分析し、現在のアプリケーションソフトウェアの構造を把握することが行われている。
例えば、ソフトウェアのモジュール間依存度を定量的に評価する依存度計測装置が提案されている。提案の依存度計測装置は、ソースコードから複数のクラスを抽出し、クラス毎に属性・メソッド引数・メソッド呼び出しなどを抽出する。依存度計測装置は、２つのクラスの組み合わせ毎に、抽出された属性・メソッド引数・メソッド呼び出しなどから、所定の算出式に従い当該２つのクラスの間の依存度を算出する。
【０００４】
また、設計者が意図したソフトウェア構造と改変された現在のソフトウェア構造との間の違いを分析するソフトウェア構造分析装置が提案されている。提案のソフトウェア構造分析装置は、複数のソースコードを分析して、関数呼び出しなどソースコード間の依存関係を抽出する。また、ソフトウェア構造分析装置は、論理ブロックの配置を示す配置情報を取得し、論理ブロックとソースコードとを対応付ける。ソフトウェア構造分析装置は、ソースコード間の依存関係を論理ブロック間の依存関係に変換し、配置情報から想定される好ましい依存関係に反するものを問題のある依存関係として検出する。
【０００５】
また、複数の開発成果物の間の依存関係に基づいて、独立の作業単位とする開発成果物群を決定する依存関係評価装置が提案されている。提案の依存関係評価装置は、設計書などの上流工程の開発成果物とソースコードなどの下流工程の開発成果物との間の依存関係を抽出し、各依存関係の複雑さを算出する。依存関係評価装置は、算出した複雑さに基づいて、上流工程と下流工程に跨がる開発成果物群であって他の開発成果物から分離が容易な開発成果物群を、分析作業や改変作業の作業単位として決定する。
【０００６】
また、設計当初のソフトウェア構造と現在のソフトウェア構造との間の乖離を可視化する分析支援装置が提案されている。提案の分析支援装置は、現在のソースコード間の依存関係に基づいてソースコード群を複数のクラスタに分割する。また、分析支援装置は、設計当初におけるソースコードと業務分類の対応関係を示す情報を取得する。分析支援装置は、クラスタ毎に二次元区間を生成し、当該クラスタに属する２以上のソースコードに対応する２以上の図形を当該二次元区画に配置する。また、分析支援装置は、二次元区間に配置された各図形を、ソースコードの属する業務分類に応じた色で表示する。１つの二次元区画内に、異なる色の図形が混在して配置される場合がある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０００−２１５０４５号公報
【特許文献２】特開２０１１−１７０６９７号公報
【特許文献３】特開２０１３−１５９５８号公報
【特許文献４】特開２０１３−１５２５７６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上記の特許文献４に記載された技術では、設計当初の業務分類と現在のクラスタとの間の乖離の全体的傾向が、図形の集合を用いて可視化される。乖離の全体的傾向は、異なる色の図形の混在状況によって表現される。しかし、特許文献４に記載された技術では、乖離の全体的傾向を直感的に理解できるにとどまる。このため、特許文献４の可視化情報のみでは、現在のソフトウェア構造の良否を客観的に判定することが容易でなく、他の分析方法を用いて詳細分析を行うことになる場合が多い。また、異なるアプリケーションソフトウェアの間でソフトウェア構造の良否を比較することも容易でない。
【０００９】
１つの側面では、本発明は、ソフトウェアの全体構造に関する定量的評価を提供する分析方法、分析装置および分析プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
１つの態様では、コンピュータが実行する分析方法が提供される。ソフトウェアの処理を記載した複数のコードの間の依存関係を検出し、依存関係に基づいて複数のコードを複数のクラスタに分類し、また、複数のコードそれぞれが複数のディレクトリの何れかに属することを示すディレクトリ情報を取得する。ディレクトリ情報が示す複数のディレクトリのうち少なくとも一のディレクトリについて、複数のコードのうち一のディレクトリに属するコードであって、複数のクラスタそれぞれに分類されたコードの数を計数する。複数のクラスタの間のコードの数の分布に基づいて、一のディレクトリに属するコードの分散状況を示す評価値を算出する。
【００１１】
また、１つの態様では、記憶部と演算部とを有する分析装置が提供される。また、１つの態様では、コンピュータに実行させる分析プログラムが提供される。
【発明の効果】
【００１２】
１つの側面では、ソフトウェアの全体構造に関する定量的評価を提供できる。
【図面の簡単な説明】
【００１３】
【図１】第１の実施の形態の分析装置の例を示す図である。
【図２】第２の実施の形態の分析装置のハードウェア例を示すブロック図である。
【図３】第２の実施の形態の分析装置の機能例を示すブロック図である。
【図４】ソースコードの例を示す図である。
【図５】呼び出しグラフの例を示す図である。
【図６】隣接行列の例を示す図である。
【図７】ソースコードのクラスタリング例を示す図である。
【図８】クラスタテーブルとラベルテーブルの例を示す図である。
【図９】ソフトウェア地図の例を示す図である。
【図１０】ソースコード数テーブルの例を示す図である。
【図１１】ヒートマップの第１の例を示す図である。
【図１２】ヒートマップの第２の例を示す図である。
【図１３】ヒートマップの第３の例を示す図である。
【図１４】ヒートマップの第４の例を示す図である。
【図１５】ガウス関数と半値半幅の例を示すグラフである。
【図１６】評価値テーブルの第１の例を示す図である。
【図１７】評価値テーブルの第２の例を示す図である。
【図１８】ソフトウェア分析の手順例を示すフローチャートである。
【図１９】クラスタリングの手順例を示すフローチャートである。
【図２０】関連付け処理の手順例を示すフローチャートである。
【図２１】評価値算出の手順例を示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
第１の実施の形態を説明する。
【００１５】
図１は、第１の実施の形態の分析装置の例を示す図である。
第１の実施の形態の分析装置１０は、ソフトウェアの全体構造の良否を定量的に評価する。分析装置１０は、クライアントコンピュータなどユーザが操作する端末装置でもよいし、サーバコンピュータなど端末装置からアクセスされるサーバ装置でもよい。
【００１６】
分析装置１０は、記憶部１１および演算部１２を有する。記憶部１１は、ＲＡＭ（Random Access Memory）などの揮発性の半導体メモリでもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性のストレージでもよい。演算部１２は、例えば、ＣＰＵ（Central Processing Unit）やＤＳＰ（Digital Signal Processor）などのプロセッサである。ただし、演算部１２は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの特定用途の電子回路を含んでもよい。プロセッサは、ＲＡＭなどのメモリに記憶されたプログラムを実行する。プログラムには、分析プログラムが含まれる。複数のプロセッサの集合（マルチプロセッサ）を「プロセッサ」と呼ぶこともある。
【００１７】
記憶部１１は、ソフトウェアの処理を記載した複数のコードを記憶する。複数のコードには、コード１３ａ（コードＣ１）、コード１３ｂ（コードＣ２）、コード１３ｃ（コードＣ３）およびコード１３ｄ（コードＣ４）が含まれる。コード１３ａ，１３ｂ，１３ｃ，１３ｄは、プロセッサに実行させる命令に対応し、プログラムと言うこともできる。コード１３ａ，１３ｂ，１３ｃ，１３ｄは、高級言語で記載されたソースコードでもよいし、機械語または中間言語で記載されたオブジェクトコードでもよい。コード１３ａ，１３ｂ，１３ｃ，１３ｄはそれぞれ、一定の纏まった処理単位に対応する。処理単位は、クラス・メソッド・関数・サブルーチンなど任意の単位でよい。例えば、コード１３ａ，１３ｂ，１３ｃ，１３ｄには、互いに異なるクラスが記載されている。
【００１８】
演算部１２は、記憶部１１に記憶された複数のコードを分析し、それら複数のコードの間の依存関係を検出する。依存関係は、例えば、処理単位の間の呼び出し関係（例えば、クラス間のメソッド呼び出し関係など）である。演算部１２は、検出した依存関係に基づいて、コード１３ａ，１３ｂ，１３ｃ，１３ｄを含む複数のコードを、クラスタ１４ａ，１４ｂを含む複数のクラスタに分類する。例えば、演算部１２は、依存関係が密である２以上のコードを同一のクラスタに分類し、依存関係が疎であるコード同士を異なるクラスタに分類するようにする。一例として、コード１３ａ，１３ｃがクラスタ１４ａに分類され、コード１３ｂ，１３ｄがクラスタ１４ｂに分類される。
【００１９】
また、演算部１２は、複数のコードそれぞれが、ディレクトリ１５ａ（ディレクトリＤ１）、ディレクトリ１５ｂ（ディレクトリＤ２）およびディレクトリ１５ｃ（ディレクトリＤ３）を含む複数のディレクトリの何れかに属することを示すディレクトリ情報１５を取得する。ディレクトリ情報１５は、記憶部１１に格納される。ディレクトリは、コード１３ａ，１３ｂ，１３ｃ，１３ｄなどのファイルを収容する入れ物であり、フォルダやパッケージなどと言うこともある。ディレクトリは、ファイルシステムに登録された実際のディレクトリでもよいし、各コードに付与された管理上の仮想的なディレクトリでもよい。
【００２０】
ディレクトリ情報１５は、ユーザが作成してもよいし、演算部１２が作成してもよい。例えば、演算部１２は、ファイルシステムが管理するディレクトリ階層の情報に基づいて、コード１３ａ，１３ｂ，１３ｃ，１３ｄそれぞれが収容されているディレクトリを特定する。また、例えば、演算部１２は、コード１３ａ，１３ｂ，１３ｃ，１３ｄそれぞれに記載されたパッケージ名を抽出し、パッケージ名をディレクトリ名として取り扱う。一例として、コード１３ａはディレクトリ１５ａに属する。コード１３ｂはディレクトリ１５ｂに属する。コード１３ｃ，１３ｄはディレクトリ１５ｃに属する。
【００２１】
演算部１２は、ディレクトリ情報１５が示す複数のディレクトリのうち少なくとも１つのディレクトリについて、以下の処理を行う。演算部１２は、複数のディレクトリそれぞれについて以下の処理を行うようにしてもよい。
【００２２】
演算部１２は、あるディレクトリに属するコードであって、複数のクラスタそれぞれに分類されたコードの数を計数（カウント）する。上記の例の場合、ディレクトリ１５ａに属するコードのうちクラスタ１４ａに分類されたものは１個であり、クラスタ１４ｂに分類されたものは０個である。ディレクトリ１５ｂに属するコードのうちクラスタ１４ａに分類されたものは０個であり、クラスタ１４ｂに分類されたものは１個である。ディレクトリ１５ｃに属するコードのうちクラスタ１４ａに分類されたものは１個であり、クラスタ１４ｂに分類されたものは１個である。
【００２３】
演算部１２は、あるディレクトリについて、複数のクラスタの間のコード数の分布を求める。演算部１２は、コード数の分布に基づいて、当該ディレクトリに属するコードの分散状況を示す評価値を算出する。上記のように、評価値はディレクトリ１５ａ，１５ｂ，１５ｃの全てについて算出されてもよいし、一部についてのみ算出されてもよい。一例として、演算部１２は、ディレクトリ１５ａに対応する評価値１６ａ（評価値Ｅ１）と、ディレクトリ１５ｂに対応する評価値１６ｂ（評価値Ｅ２）と、ディレクトリ１５ｃに対応する評価値１６ｃ（評価値Ｅ３）を算出する。
【００２４】
評価値１６ａ，１６ｂ，１６ｃは、例えば、コードが多数のクラスタに分散しているほど大きい値となり、コードが少数のクラスタに集中しているほど小さい値となる。上記の例の場合、評価値１６ｃは評価値１６ａ，１６ｂよりも大きい値となる。評価値１６ａ，１６ｂ，１６ｃは、コード数が閾値以上になるクラスタの数に関する値でもよい。例えば、演算部１２は、複数のクラスタをコード数の降順に並べてクラスタ間のコード数の分布についての関数（例えば、ガウス関数）を推定する。演算部１２は、推定した関数を用いて、半値半幅（ＨＷＨＭ：Half Width at Half Maximum）などの統計値を算出する。
【００２５】
このようにして算出された評価値１６ａ，１６ｂ，１６ｃは、ソフトウェアの全体構造の良否を示す指標値であり定量的な評価結果であると言える。例えば、複数の評価値が全体的に小さい場合、同時期に実行され得るコードが同じディレクトリに収容されており、機能分割が適切に行われたソフトウェアであると判定できる可能性がある。一方、例えば、一部のディレクトリの評価値が小さく他の一部のディレクトリの評価値が大きい場合、ソフトウェアの全体構造に一貫性がなくコードが適切に整理されていないソフトウェアであると判定できる可能性がある。その場合、全体構造に一貫性がない原因として、新規開発後の保守・改変が適切に行われなかったことが疑われることもある。
【００２６】
第１の実施の形態の分析装置１０によれば、複数のコードの間の依存関係に基づいて、複数のコードが複数のクラスタに分類される。また、複数のコードと複数のディレクトリの間の収容関係を示すディレクトリ情報１５が取得される。複数のディレクトリのうちの少なくとも一のディレクトリについて、複数のコードのうち当該一のディレクトリに属するコードであって、複数のクラスタそれぞれに分類されたコードの数が計数される。そして、複数のクラスタの間のコード数の分布に基づいて、当該一のディレクトリに属するコードの分散状況を示す評価値が算出される。
【００２７】
算出された評価値は、例えば、ディスプレイに表示されてユーザに提示される。複数の評価値のリストや、ディレクトリと評価値とを対応付けたテーブルなどをディスプレイに表示してもよい。これにより、ソフトウェアの全体構造に関する定量的評価が提供され、全体構造の良否を客観的に判定することが容易となる。また、異なるソフトウェアの間で全体構造の良否を比較することも容易となる。よって、例えば、新規開発後にソフトウェアに対して行われた保守・改変が適切であったか否かを評価することも可能となる。
【００２８】
［第２の実施の形態］
次に、第２の実施の形態を説明する。
第２の実施の形態の分析装置１００は、既存のアプリケーションソフトウェアのソースコードを分析し、アプリケーションソフトウェアの基本的構造（アーキテクチャ）を可視化する。分析装置１００が生成する可視化情報は、例えば、アプリケーションソフトウェアに対してこれまで行ってきた保守・改変の良否を評価するために用いることができる。特に、可視化情報は、保守・改変が設計当初のアーキテクチャに適合するように適切に行われたか否かを示す１つの評価を提供する。また、可視化情報は、例えば、アプリケーションソフトウェアの更新計画を立案するために用いることができる。
【００２９】
図２は、第２の実施の形態の分析装置のハードウェア例を示すブロック図である。
分析装置１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６および通信インタフェース１０７を有する。これらのユニットは、バス１０８に接続されている。分析装置１００は、第１の実施の形態の分析装置１０に対応する。ＲＡＭ１０２またはＨＤＤ１０３は、第１の実施の形態の記憶部１１に対応する。ＣＰＵ１０１は、第１の実施の形態の演算部１２に対応する。
【００３０】
ＣＰＵ１０１は、プログラムの命令を実行する演算回路を含むプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。なお、ＣＰＵ１０１は複数のプロセッサコアを備えてもよく、分析装置１００は複数のプロセッサを備えてもよく、以下で説明する処理を複数のプロセッサまたはプロセッサコアを用いて並列に実行してもよい。また、複数のプロセッサの集合（マルチプロセッサ）を「プロセッサ」と呼んでもよい。
【００３１】
ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムやＣＰＵ１０１が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、分析装置１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。
【００３２】
ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。プログラムには、分析プログラムが含まれる。なお、分析装置１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。
【００３３】
画像信号処理部１０４は、ＣＰＵ１０１からの命令に従って、分析装置１００に接続されたディスプレイ１１１に画像を出力する。ディスプレイ１１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなどを用いることができる。
【００３４】
入力信号処理部１０５は、分析装置１００に接続された入力デバイス１１２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス１１２としては、マウスやタッチパネルやタッチパッドやトラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、分析装置１００に、複数の種類の入力デバイスが接続されていてもよい。
【００３５】
媒体リーダ１０６は、記録媒体１１３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体１１３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。媒体リーダ１０６は、例えば、記録媒体１１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。
【００３６】
通信インタフェース１０７は、ネットワーク１１４に接続され、ネットワーク１１４を介して他の装置と通信を行うインタフェースである。通信インタフェース１０７は、スイッチなどの通信装置とケーブルで接続される有線通信インタフェースでもよいし、基地局と無線リンクで接続される無線通信インタフェースでもよい。
【００３７】
図３は、第２の実施の形態の分析装置の機能例を示すブロック図である。
分析装置１００は、ソースコード記憶部１２１、クラスタリング部１２２、制御情報記憶部１２３、可視化制御部１２４、可視化情報記憶部１２５、ソフトウェア地図生成部１２６、ヒートマップ生成部１２７および評価値算出部１２８を有する。ソースコード記憶部１２１、制御情報記憶部１２３および可視化情報記憶部１２５は、例えば、ＲＡＭ１０２またはＨＤＤ１０３に確保した記憶領域を用いて実装できる。クラスタリング部１２２、可視化制御部１２４、ソフトウェア地図生成部１２６、ヒートマップ生成部１２７および評価値算出部１２８は、例えば、プログラムを用いて実装できる。
【００３８】
ソースコード記憶部１２１は、分析対象のアプリケーションソフトウェアのソースコード群を記憶する。ソースコードは、理解容易な高級言語を用いて記載されたプログラムである。ソースコードは、例えば、アプリケーションソフトウェアの所有者や運用者などの分析依頼者から提供される。第２の実施の形態では、一纏まりの処理単位を１つの「ソースコード」として取り扱う。ソースコードの単位としては、クラス・メソッド・関数・サブルーチンなどが挙げられる。以下では主に、オブジェクト指向言語を用いてソースコードが記載されており、ソースコードの単位をクラスとする場合を想定する。
【００３９】
ソースコード群は、階層化されたディレクトリ構造によって管理されている。各ソースコードには、当該ソースコードが属するディレクトリの名称（パッケージ名など）が記載されていることがある。この場合、ソースコード自体から各ソースコードの属するディレクトリを特定できる。また、ソースコード群は、ファイルシステム上で、階層化された複数のディレクトリに分散して格納されていることがある。この場合、ファイルシステム上でのソースコードの位置（ファイルパス）から各ソースコードの属するディレクトリを特定できる。また、ソースコード群とは別に、各ソースコードに対して付与されたディレクトリ名を示す付加情報が、分析依頼者から提供されることもある。
【００４０】
ソースコード群のディレクトリ構造は、アプリケーションソフトウェアの全体構造を意識して作成されるものであり、アプリケーションソフトウェアの設計思想を反映していると言うことができる。そこで、分析装置１００は、アプリケーションソフトウェアの設計文書が残っていない場合であっても、ディレクトリ構造を設計に関する情報として用いて、アプリケーションソフトウェアのアーキテクチャを評価することとする。
【００４１】
クラスタリング部１２２は、ソースコード記憶部１２１からソースコード群を読み出して分析する。クラスタリング部１２２は、ソースコードに記載された処理単位の間の呼び出し関係（例えば、関数呼び出しやメソッド呼び出しなど）を抽出し、呼び出し関係に基づいてソースコード群を複数のクラスタに分類する。呼び出し関係によって密に結合された２以上のソースコードができる限り同一のクラスタに分類され、疎に結合されたソースコード同士ができる限り異なるクラスタに分類されるようにする。
【００４２】
クラスタは、同時期に実行される可能性の高い処理単位を記載したソースコードの集合を示す。クラスタは、アプリケーションソフトウェアが備える「機能」と言うこともできる。クラスタとディレクトリは、共にソースコードの分類であるが、両者は異なる概念である。同じディレクトリに属するソースコードが、少数のクラスタに集中的に分類されることもあるし、多数のクラスタに分散して分類されることもある。同じディレクトリに属するソースコードの分散の程度は、後述するように、設計時に採用したアーキテクチャに依存する。機能分割型（垂直分割型）のアーキテクチャでは、１つのディレクトリが１つまたは少数のクラスタに対応することが多い。一方、レイヤ分割型（水平分割型）のアーキテクチャでは、１つのディレクトリが多数のクラスタに対応することが多い。
【００４３】
そして、クラスタリング部１２２は、ソースコードとクラスタとの対応関係を示す情報を制御情報記憶部１２３に格納する。また、クラスタリング部１２２は、各ソースコードのディレクトリを特定し、ソースコードとディレクトリとの対応関係を示す情報を制御情報記憶部１２３に格納する。例えば、クラスタリング部１２２は、各ソースコードから当該ソースコードのパッケージ名を抽出する。また、例えば、クラスタリング部１２２は、ＯＳが管理するファイルシステムから各ソースコードのファイルパスを取得する。また、例えば、クラスタリング部１２２は、分析依頼者から提供された情報から各ソースコードのディレクトリを検索する。複数のディレクトリが階層化されている場合、ディレクトリ名は、ルートディレクトリからソースコードの直上のディレクトリまでのパスを含む。
【００４４】
制御情報記憶部１２３は、アーキテクチャの可視化に用いる各種の制御情報を記憶する。制御情報には、クラスタリング部１２２のクラスタリング結果が含まれる。すなわち、制御情報記憶部１２３は、ソースコードとディレクトリとクラスタの対応関係を示す情報を記憶する。また、ソースコードやファイルシステムなどで使用されているディレクトリ名は、省略語などを用いて簡潔に記載した英数字の列であることがある。可視化にあたっては、このようなディレクトリ名に代えて、人間がより理解容易なラベルを使用したいことがある。その場合、ディレクトリ名とディレクトリラベルとを対応付けた情報が分析依頼者から提供され、制御情報記憶部１２３に格納されることがある。
【００４５】
可視化制御部１２４は、制御情報記憶部１２３に記憶された制御情報を用いて、アプリケーションソフトウェアの全体構造を可視化した可視化情報の生成を制御する。可視化制御部１２４は、生成された可視化情報を可視化情報記憶部１２５に格納する。また、可視化制御部１２４は、可視化情報記憶部１２５に記憶された可視化情報を用いて、ディスプレイ１１１に各種の画像を表示させる。第２の実施の形態では、後述するように、ソフトウェア地図とヒートマップとディレクトリ評価値の３つが可視化情報に含まれる。可視化制御部１２４は、可視化情報の生成のために、ソフトウェア地図生成部１２６とヒートマップ生成部１２７と評価値算出部１２８を呼び出す。
【００４６】
可視化情報記憶部１２５は、可視化情報を記憶する。すなわち、可視化情報記憶部１２５は、ソフトウェア地図生成部１２６が生成したソフトウェア地図と、ヒートマップ生成部１２７が生成したヒートマップと、評価値算出部１２８が生成したディレクトリ評価値を記憶する。可視化情報記憶部１２５に記憶された可視化情報の一部または全部が、入力デバイス１１２を用いた操作に応じて、ディスプレイ１１１に表示される。
【００４７】
ソフトウェア地図生成部１２６は、ソースコードとディレクトリとクラスタの対応関係に基づいて、ソフトウェア地図を生成する。ソフトウェア地図は、ソースコード群に対応する複数のノードを含む。ソフトウェア地図の各ノードは、ソースコードの属するディレクトリに応じた視覚的表現（例えば、色・模様・形状・大きさなど）で表示される。異なるディレクトリには異なる視覚的表現が与えられる。また、ソフトウェア地図の各ノードは、ソースコードの属するクラスタに応じた位置に配置される。同じクラスタについてのノード同士は近くに配置され、異なるクラスタについてのノードは離れて配置される。ソフトウェア地図によって、ディレクトリと機能の関係を直感的に把握できる。
【００４８】
ヒートマップ生成部１２７は、ソースコードとディレクトリとクラスタの対応関係に基づいて、ヒートマップを生成する。ヒートマップは、行項目にディレクトリを対応付け列項目にクラスタを対応付けた行列形式のマップである。一の行・一の列に対応する位置には、一のディレクトリに属しかつ一のクラスタに属するソースコードの数に応じたマークが表示される。マークは、該当するソースコードが存在するか否かを示す２値的表現でもよいし、該当するソースコードの数に応じて異なる多値的表現でもよい。２種類以上のマークは、色・模様・形状・大きさなどの視覚的表現が異なる。ヒートマップによって、ディレクトリと機能の関係をソフトウェア地図よりも分析的に表現できる。
【００４９】
評価値算出部１２８は、ソースコードとディレクトリとクラスタの対応関係に基づいて、ディレクトリ毎にディレクトリ評価値を算出する。ディレクトリ評価値は、あるディレクトリに属するソースコードが、どの程度の数のクラスタに分散しているかを示す分散に関する統計値である。ソースコードが少数のクラスタに集中しているほどディレクトリ評価値は小さくなり、多数のクラスタに分散しているほどディレクトリ評価値は大きくなる。ディレクトリ評価値は、ディレクトリと機能の関係を数値化したものである。ディレクトリ評価値から、当初の設計思想と現状の実装状況との間の乖離を把握することもできる。ソフトウェア地図がディレクトリと機能の関係について全体的な俯瞰を提供するのに対し、ディレクトリ評価値はディレクトリと機能の関係について定量的な指標を提供する。
【００５０】
なお、可視化において分析単位とするディレクトリを、ディレクトリ階層の末端のディレクトリではなくそれより上位のディレクトリとすることで、分析の粒度を大きくすることもできる。可視化制御部１２４は、分析単位とするディレクトリの階層レベルの指定を受け付けることがある。階層レベルは、例えば、ルートディレクトリからの階層の深さを示す。その場合、可視化制御部１２４は、指定された階層レベルのディレクトリを単位として、そのディレクトリより下位に存在するソースコードを集計する。
【００５１】
図４は、ソースコードの例を示す図である。
ソースコード１３１ａ，１３１ｂは、ソースコード記憶部１２１に記憶されたソースコードの一例である。ソースコード１３１ａ，１３１ｂは、オブジェクト指向言語によって記載されている。ソースコード１３１ａ，１３１ｂは、それぞれ１つのクラスを含む。
【００５２】
ソースコード１３１ａには、「ｃｏｍ．…．ｊｐ．ｄｉｒＢ．ｓｕｂＢ１」というパッケージ名が記載されている。これは、ソースコード１３１ａが属するディレクトリの名称に相当する。また、ソースコード１３１ａには、クラスＣ０２が記載されている。クラスＣ０２は、他のクラスから呼び出し可能なメソッド「ｐｒｏｃｅｓｓ」を含む。メソッド「ｐｒｏｃｅｓｓ」は、クラスＣ０５のメソッド「ｃｏｌｌｅｃｔＯｒｄｅｒ」と、クラスＣ０９のメソッド「ｃｏｌｌｅｃｔＢａｃｋｌｏｇ」と、クラスＣ１４のメソッド「ｉｓｓｕｅ」と、クラスＣ０１のメソッド「ｌｏｇ」を呼び出す。
【００５３】
ソースコード１３１ｂには、ソースコード１３１ａと同じパッケージ名が記載されている。これは、ソースコード１３１ｂがソースコード１３１ａと同じディレクトリに属することを示す。また、ソースコード１３１ｂには、クラスＣ０５が記載されている。クラスＣ０５は、他のクラスから呼び出し可能なメソッド「ｃｏｌｌｅｃｔＯｒｄｅｒ」を含む。メソッド「ｃｏｌｌｅｃｔＯｒｄｅｒ」は、クラスＣ０１のメソッド「ｌｏｇ」を呼び出す。クラスタリング部１２２は、ソースコード１３１ａ，１３１ｂを分析することで、ソースコード１３１ａからソースコード１３１ｂへの呼び出し関係を抽出できる。
【００５４】
図５は、呼び出しグラフの例を示す図である。
ここでは、ソースコード群にクラスＣ０１〜Ｃ１６の１６個のクラスが記載されている場合を考える。呼び出しグラフ１３２は、クラスＣ０１〜Ｃ１６の間の呼び出し関係を示す有向グラフである。呼び出しグラフ１３２は、クラスＣ０１〜Ｃ１６に対応する複数のノードと、クラスＣ０１〜Ｃ１６の間の呼び出し関係を示す複数のリンクとを含む。矢印の元（ソース）は呼び出し元を表し、矢印の先（ターゲット）は呼び出し先を表す。例えば、クラスＣ０２は、クラスＣ０１，Ｃ０５，Ｃ０９，Ｃ１４を呼び出している。
【００５５】
呼び出しグラフ１３２が示す呼び出し関係には、重みが付与される。あるクラスを呼び出し先とする呼び出し関係それぞれの重みは、当該クラスを呼び出し先とする呼び出し関係の数に反比例する。あるクラスを呼び出し先とする呼び出し関係がＫ個存在する場合、それらＫ個（Ｋは１以上の整数）の呼び出し関係それぞれに対し１／Ｋの重みが付与される。例えば、呼び出しグラフ１３２では、クラスＣ０５を呼び出し先とする呼び出し関係が６個存在する。よって、それら６個の呼び出し関係の重みは１／６になる。
【００５６】
図６は、隣接行列の例を示す図である。
クラスタリング部１２２は、ソースコード群を分析することで隣接行列１３３（隣接行列Ａ）を生成する。隣接行列１３３の行項目は呼び出し元のソースコードに相当し、列項目は呼び出し先のソースコードに相当する。隣接行列１３３は、図５の呼び出しグラフ１３２に対応している。クラスＣ０１〜Ｃ１６に対応する１６個のソースコードが存在するため、隣接行列１３３は１６行１６列の正方行列になっている。
【００５７】
隣接行列１３３のｉ行ｊ列の要素（要素Ａij）は、ｉ番目のソースコードに記載された処理単位からｊ番目のソースコードに記載された処理単位へのメソッド呼び出しを示す。要素Ａijは、それぞれ０以上１以下の有理数である。要素Ａij＝０であることは、ｉ番目のソースコードからｊ番目のソースコードに対して呼び出し関係が存在しないことを示す。要素Ａij＝１／Ｋであることは、ｉ番目のソースコードからｊ番目のソースコードに対して重み１／Ｋの呼び出し関係が存在することを示す。例えば、隣接行列１３３の２行５列の要素は１／６である。これは、２番目のソースコードから５番目のソースコードに対して重み１／６の呼び出し関係が存在することを示している。
【００５８】
図７は、ソースコードのクラスタリング例を示す図である。
クラスタリング部１２２は、ソースコード間の呼び出し関係を示す隣接行列１３３を用いて、ソースコード群を複数のクラスタに分割する。１つのクラスタは１または２以上のソースコードを含む。原則として、呼び出し関係が密なソースコードの集合は同じクラスタに配置され、呼び出し関係が疎なソースコード同士は異なるクラスタに配置される。
【００５９】
一例として、クラスタ１３４ａ，１３４ｂ，１３４ｃ（クラスタＧ１〜Ｇ３）が生成される。クラスタ１３４ａは、クラスＣ０２，Ｃ０５，Ｃ０６，Ｃ１１，Ｃ１４に対応する５個のソースコードを含む。クラスタ１３４ｂは、クラスＣ０１，Ｃ０７，Ｃ０９，Ｃ１０，Ｃ１５，Ｃ１６に対応する６個のソースコードを含む。クラスタ１３４ｃは、クラスＣ０３，Ｃ０４，Ｃ０８，Ｃ１２，Ｃ１３に対応する５個のソースコードを含む。
【００６０】
ソースコード群を複数のクラスタに分割するにあたり、数式（１）に示すモジュラリティ評価値Ｑが用いられる。モジュラリティ評価値Ｑは、−１以上１以下の有理数である。モジュラリティ評価値Ｑが大きいほど良いクラスタリングであることを示し、モジュラリティ評価値Ｑが小さいほど悪いクラスタリングであることを示す。
【００６１】
【数１】
2017068534.tif 000003
【００６２】
数式（１）において、ｍは隣接行列１３３の全要素を合計した値である。ｋioutは、隣接行列１３３のｉ行目の要素を合計した値、すなわち、ｉ番目のソースコードを呼び出し元とする呼び出し関係の重みの合計である。ｋjinは、隣接行列１３３のｊ列目の要素を合計した値、すなわち、ｊ番目のソースコードを呼び出し先とする呼び出し関係の重みの合計である。ｇiはｉ番目のソースコードが属するクラスタを示し、ｇjはｊ番目のソースコードが属するクラスタを示す。δ（ｇi，ｇj）は、クロネッカーのデルタ関数である。ｇiとｇjが同じ場合はδ（ｇi，ｇj）＝１であり、ｇiとｇjが異なる場合はδ（ｇi，ｇj）＝０である。δ（ｇi，ｇj）は、同じクラスタ内の呼び出し関係をモジュラリティ評価値Ｑに反映させ、異なるクラスタ間の呼び出し関係を無視するものである。
【００６３】
クラスタリング部１２２は、モジュラリティ評価値Ｑが最大になるように、ソースコード群を複数のクラスタに分割する。クラスタリングの手順の詳細は後述する。これにより、各ソースコードが何れのクラスタに属するかが決定される。また、図４に示すように各ソースコードにパッケージ名が記載されている場合、ソースコード自体に基づいて各ソースコードが何れのディレクトリに属するかが特定される。
【００６４】
図８は、クラスタテーブルとラベルテーブルの例を示す図である。
クラスタリング部１２２は、クラスタテーブル１３５を生成する。クラスタテーブル１３５は、制御情報記憶部１２３に格納される。クラスタテーブル１３５は、ソースコード名、ディレクトリ名およびクラスタＩＤの項目を含む。
【００６５】
ソースコード名は、ソースコードを識別する名称である。図８のクラスタテーブル１３５では、ソースコード名としてクラス名を用いている。ディレクトリ名は、ソースコードが属するディレクトリの名称である。複数のディレクトリが階層化されている場合、ディレクトリ名は、ルートディレクトリからソースコードの属する直上のディレクトリまでのパスを含む。クラスタＩＤは、クラスタを識別する名称である。１つのソースコード名に対して、１つのディレクトリ名と１つのクラスタＩＤが対応付けられる。
【００６６】
前述のように、ディレクトリ名とディレクトリラベルとの対応関係を示す情報が分析依頼者から提供されることがある。その場合、ラベルテーブル１３６が制御情報記憶部１２３に格納される。ラベルテーブル１３６は、ディレクトリ名およびディレクトリラベルの項目を有する。１以上のソースコードを含むディレクトリまたはそれより上位のディレクトリの名称である。ディレクトリラベルは、ディレクトリの役割を示す理解容易な名称である。ディレクトリラベルは、例えば、分析依頼者によって付与される。ただし、分析者など分析依頼者以外の者がディレクトリラベルを付与してもよい。
【００６７】
前述のように、分析の粒度を大きくするため、分析単位とするディレクトリを末端のディレクトリではなくそれより上位のディレクトリにすることがある。その場合、ラベルテーブル１３６に含まれるディレクトリ名は、分析単位とするディレクトリの名称であることが好ましい。例えば、クラスＣ０１が記載されたソースコードのディレクトリ名が「ｃｏｍ／…／ｊｐ／ｄｉｒＡ／ｓｕｂＡ１」であり、クラスＣ０４が記載されたソースコードのディレクトリ名が「ｃｏｍ／…／ｊｐ／ｄｉｒＡ／ｓｕｂＡ２」であるとする。また、「ｃｏｍ／…／ｊｐ／ｄｉｒＡ」に対して「共通」というディレクトリラベルが付与されたとする。この場合、クラスＣ０１，Ｃ０４が記載されたソースコードは、分析上は同じ分析単位のディレクトリに属するものとみなされ、そのディレクトリには「共通」というディレクトリラベルが付与されているものとして取り扱われる。
【００６８】
このようなクラスタテーブル１３５およびラベルテーブル１３６に基づいて、アプリケーションソフトウェアのアーキテクチャが可視化される。次に、可視化結果であるソフトウェア地図、ヒートマップおよびディレクトリ評価値について説明する。
【００６９】
まず、ソフトウェア地図について説明する。
図９は、ソフトウェア地図の例を示す図である。
ソフトウェア地図１４１は、クラスタテーブル１３５に基づいて、ソフトウェア地図生成部１２６によって生成される。ソフトウェア地図１４１の情報が、可視化情報記憶部１２５に格納される。また、ソフトウェア地図１４１が、ディスプレイ１１１に表示される。ソフトウェア地図１４１は、ソースコードを示す複数のノードを含む。複数のノードに対して、ソースコードの属するディレクトリに応じて異なる模様が付与されている。また、複数のノードが、ソースコードの属するクラスタに応じてブロック分けされている。同じクラスタに属するソースコードに対応するノードは、同じブロック内に配置される。
【００７０】
ブロック１４１ａに含まれるノードには、全て同じ模様が付与されている。これは、ブロック１４１ａに対応するクラスタは、同じディレクトリに属するソースコードのみを含んでいることを意味する。また、ブロック１４１ｂに含まれるノードの多くには、同じ模様が付与されている。このように、図９のソフトウェア地図１４１では、多くのブロックは少数の模様のノードのみを含んでおり、ディレクトリと同時期に実行される処理単位の集合（機能）とが対応していることを把握することができる。
【００７１】
一方、ブロック１４１ｃには、様々な模様のブロックが混在している。これは、ブロック１４１ｃに対応するクラスタに属するソースコードは、様々なディレクトリに分散していることを意味する。すなわち、同時期に実行される処理単位を記載したソースコードが多数のディレクトリに分散しており、ディレクトリと機能とが対応していない。
【００７２】
ソフトウェア地図１４１の中に、ディレクトリと機能とが対応しているブロックと対応していないブロックとが混在している場合、当初の設計思想と現在の実装状況とが乖離している可能性がある。例えば、アプリケーションソフトウェアの初期開発時はディレクトリと機能とが対応していたものの、その後に初期開発時のアーキテクチャを崩すような保守・改変が行われた可能性がある。その場合、これまで行われた保守・改変が不適切であり、アプリケーションソフトウェアの修正が好ましいと判断し得る。ただし、ソフトウェア地図１４１は、ディレクトリと機能の関係について直感的な理解を可能にする一方、設計思想と実装状況の乖離の程度について定量的な指標は提供しない。
【００７３】
図１０は、ソースコード数テーブルの例を示す図である。
ヒートマップを生成しディレクトリ評価値を算出するにあたり、可視化制御部１２４は、クラスタテーブル１３５に基づいてソースコード数テーブル１３７を生成する。ソースコード数テーブル１３７は、制御情報記憶部１２３に格納される。
【００７４】
ソースコード数テーブル１３７は、ディレクトリ名を行項目としクラスタＩＤを列項目とする行列である。ディレクトリ名は、分析単位とするディレクトリの名称である。ソースコード数テーブル１３７は、一のディレクトリに属しかつ一のクラスタに属するソースコードの数を示す。ソースコード数は、クラスタテーブル１３５から該当するレコードを検索してカウントすることで算出することができる。
【００７５】
一例として、図１０のソースコード数テーブル１３７では、９１０個のソースコードのうち、「ｃｏｍ／…／ｊｐ／ｄｉｒＡ」に属しかつクラスタＧ０１に属するソースコードが５個存在する。また、「ｃｏｍ／…／ｊｐ／ｄｉｒＡ」に属しかつクラスタＧ０２に属するソースコードが３個存在する。また、「ｃｏｍ／…／ｊｐ／ｄｉｒＡ」に属しかつクラスタＧ０３に属するソースコードが１０個存在する。ソースコード数テーブル１３７に記載されたソースコード数を行方向に集計することで、各ディレクトリに属するソースコードの数を算出できる。また、ソースコード数テーブル１３７に記載されたソースコード数を列方向に集計することで、各クラスタに属するソースコードの数を算出できる。
【００７６】
次に、ヒートマップについて説明する。
図１１は、ヒートマップの第１の例を示す図である。
ヒートマップ１４２ａは、ソースコード数テーブル１３７に基づいて、ヒートマップ生成部１２７によって生成される。ヒートマップ１４２ａの情報が、可視化情報記憶部１２５に格納される。また、ヒートマップ１４２ａが、ディスプレイ１１１に表示される。
【００７７】
ヒートマップ１４２ａは、ディレクトリラベルに対応する行項目とクラスタＩＤに対応する列項目とを有する。一のディレクトリラベルと一のクラスタＩＤとによって特定される位置には、当該ディレクトリに属しかつ当該クラスタに属するソースコードの数に応じて、白または黒のマーク（二値的マーク）が配置される。白のマークは、該当するソースコードが存在しない（ソースコード数がゼロである）ことを示す。黒のマークは、該当するソースコードが存在する（ソースコード数が１以上である）ことを示す。
【００７８】
クラスタＩＤは、クラスタに属するソースコードの数の降順にソートされている。ディレクトリラベルは、黒のマークができる限り対角線に並ぶように、クラスタＩＤの順位に対応させてソートされている。すなわち、あるクラスタに属するソースコードのディレクトリのうちソースコード数が最大であるディレクトリが、当該クラスタの順位に対応する順位になるように、ディレクトリラベルがソートされる。
【００７９】
ヒートマップ１４２ａの例では、「共通」と「業務不明」のディレクトリは、様々な機能に利用される共有ライブラリであると推定される。共有ライブラリ以外のディレクトリについては、ディレクトリとクラスタとが概ね一対一に対応する傾向にある。よって、ヒートマップ１４２ａが示すアーキテクチャは、機能分割型（垂直分割型）のアーキテクチャであると言える。また、共有ライブラリ以外のディレクトリとクラスタとが概ね一対一に対応するため、設計思想と現在の実装状況の間の乖離は小さいと判断できる。
【００８０】
図１２は、ヒートマップの第２の例を示す図である。
上記のヒートマップ１４２ａは、該当するソースコードが存在するか存在しないかを示す二値的マークを使用していた。これに対し、ヒートマップ１４２ｂは、該当するソースコードの数に応じて異なる模様が付与された多値的マークを使用する。
【００８１】
クラスタＩＤがソースコード数の降順に並んでいるため、左上のマークはソースコード数が多いことを示している。また、共有ライブラリ以外のディレクトリとクラスタとが概ね一対一に対応するため、対角線上のマークはソースコード数が多いことを示している。一方、共有ライブラリに相当するディレクトリのマークなど対角線から離れた位置のマークは、ソースコード数が少ないことを示している。このように、多値的マークを使用することによって、ディレクトリとクラスタの関係が一層理解容易になる。
【００８２】
なお、ヒートマップ１４２ａ，１４２ｂは、設計思想と現在の実装状況の間の乖離が小さい例を示している。これに対し、設計思想と現在の実装状況の間の乖離が大きい場合、共有ライブラリでないと推定される一部のディレクトリについて、多数の二値的マークまたは多値的マークが対角線上から離れた位置に現れる。これにより、設計思想と現在の実装状況とが乖離していることを把握できる。また、その原因となっているディレクトリまたは機能を特定でき、適切でなかった保守・改変を特定することが可能となる。
【００８３】
図１３は、ヒートマップの第３の例を示す図である。
ヒートマップ１４２ｃは、ヒートマップ１４２ａと同様に二値的マークを使用している。ただし、ヒートマップ１４２ｃは、ヒートマップ１４２ａとは異なるソースコード群に基づいて生成されたものである。ヒートマップ１４２ａは、共有ライブラリ以外のディレクトリとクラスタとが概ね一対一に対応する機能分割型（垂直分割型）のアーキテクチャを示していた。これに対し、ヒートマップ１４２ｃは、ディレクトリが処理レイヤに対応するレイヤ分割型（水平分割型）のアーキテクチャを示している。
【００８４】
処理レイヤには、ユーザインタフェース層・コントロール層・ビジネスロジック層・データアクセス層・データ層などに相当するものが含まれる。多くの機能は、これらの複数の処理レイヤの全てまたは多数を利用して実現される。よって、レイヤ分割型のアーキテクチャでは、１つのディレクトリに属するソースコードが多数のクラスタに分散される。ヒートマップ１４２ｃの例では、「サーブレット」、「業務処理」、「論理データ処理」、「Ｂｅａｎｓ」などのディレクトリが、多数のクラスタと関連している。
【００８５】
図１４は、ヒートマップの第４の例を示す図である。
上記のヒートマップ１４２ｃは、該当するソースコードが存在するか存在しないかを示す二値的マークを使用していた。これに対し、ヒートマップ１４２ｄは、ヒートマップ１４２ｂと同様に、該当するソースコードの数に応じて異なる模様が付与された多値的マークを使用する。ヒートマップ１４２ｄの左上の一部のマークは、ソースコード数が比較的多いことを示している。しかし、各ディレクトリに属するソースコードは多数のクラスタに分散して分類されるため、多くのマークはソースコード数が少ないことを示している。
【００８６】
次に、ディレクトリ評価値について説明する。
図１５は、ガウス関数と半値半幅の例を示すグラフである。
ディレクトリ評価値は、ディレクトリ毎に、当該ディレクトリに属するソースコードがどの程度の数のクラスタに分散しているかを示す定量的な指標である。評価値算出部１２８は、あるディレクトリについて、クラスタを当該ディレクトリに属するソースコードの数の降順にソートし、クラスタに対して正の整数のクラスタ順位を付与する。図１５のグラフ１３８の例では、クラスタＧ２５，Ｇ２８，Ｇ１３，Ｇ２６，Ｇ１４，Ｇ０５，Ｇ０６，Ｇ２４，Ｇ２０，Ｇ２３の順にこれらのクラスタがソートされている。また、評価値算出部１２８は、各クラスタのソースコード数を、ディレクトリに属するソースコードの総数を用いて正規化する。すなわち、評価値算出部１２８は、各クラスタのソースコード数をソースコード総数で割って、ソースコード数をソースコード出現割合に変換する。
【００８７】
評価値算出部１２８は、グラフ１３８がクラスタ順位とソースコード出現割合との関係を最も適切に表現するように、数式（２）のようなガウス関数を算出する。数式（２）において、ｘはクラスタ順位であり、ｆ（ｘ）はクラスタ順位ｘに対応するソースコード出現割合である。Ｂは振幅を示す係数であり、μはガウス関数の平均値であり、σはガウス関数の標準偏差（分散の平方根）である。評価値算出部１２８は、係数Ｂと平均値μと標準偏差σを未知のパラメータとみなし、ガウス関数がクラスタ順位とソースコード出現割合との関係に最もフィットするようにこれらパラメータの値を決定する。
【００８８】
【数２】
2017068534.tif 000004
【００８９】
なお、ガウス関数は左右対称であるとみなして算出されるものの、クラスタ順位ｘ＝０に対応するソースコード出現割合ｆ（ｘ）が存在しないため、平均値μは０になるとは限らない。評価値算出部１２８は、例えば、係数Ｂ＝１，平均値μ＝１，標準偏差σ＝１を初期値として残差二乗和などフィッティング良否を示す指標値を算出し、試行錯誤的に最適な係数Ｂと平均値μと標準偏差σを決定することが考えられる。
【００９０】
そして、評価値算出部１２８は、決定したガウス関数に基づいて、ディレクトリ評価値として半値半幅（ＨＷＨＭ）を算出する。ガウス関数におけるソースコード出現割合ｆ（ｘ）の最大値をｆmaxとすると、半値半幅は、ソースコード出現割合ｆ（ｘ）＝ｆmax／２になるｘと中心との間の距離である。半値半幅が大きいほど、ソースコードが多数のクラスタに分散して出現していることを表し、半値半幅が小さいほど、ソースコードが少数のクラスタに集中して出現していることを表す。なお、フィッティングに用いる元データのクラスタ順位ｘは整数であるが、ガウス関数から算出される半値半幅は整数であるとは限らず小数になることがある。
【００９１】
図１６は、評価値テーブルの第１の例を示す図である。
評価値算出部１２８は、各ディレクトリについてディレクトリ評価値を算出し、評価値テーブル１４３ａを生成する。評価値テーブル１４３ａは、可視化情報記憶部１２５に格納される。また、評価値テーブル１４３ａは、ディスプレイ１１１に表示される。
【００９２】
評価値テーブル１４３ａは、ディレクトリラベル、ソースコード数および半値半幅の項目を有する。ディレクトリラベルは、ラベルテーブル１３６に記載されたものである。ソースコード数は、ディレクトリラベルが示すディレクトリに属するソースコードの総数である。ソースコード数は、ソースコード数テーブル１３７とラベルテーブル１３６から特定できる。半値半幅は、上記のようにして算出したガウス関数の半値半幅であり、ソースコードの分散の程度を示す定量的な指標値である。
【００９３】
評価値テーブル１４３ａは、ヒートマップ１４２ａ，１４２ｂと同じソースコード群の分析結果を示している。共有ライブラリであると推定される「共通」のディレクトリ以外のディレクトリの半値半幅は、１未満である。よって、評価値テーブル１４３ａが示すアーキテクチャは、機能分割型（垂直分割型）のアーキテクチャであると言える。また、設計思想と現在の実装状況の間の乖離は小さいと判断できる。
【００９４】
図１７は、評価値テーブルの第２の例を示す図である。
評価値テーブル１４３ｂは、ヒートマップ１４２ｃ，１４２ｄと同じソースコード群の分析結果を示している。「物理データ共通処理」、「日英メッセージ」および「論理データ共通処理」以外のディレクトリの半値半幅は、１以上である。よって、評価値テーブル１４３ｂが示すアーキテクチャは、レイヤ分割型（水平分割型）のアーキテクチャであると言える。ただし、一部のディレクトリの半値半幅が１未満であるため、設計思想と現在の実装状況の間に乖離が発生している可能性がある。
【００９５】
生成された評価値テーブル１４３ａ，１４３ｂを理解するにあたり、例えば、各ディレクトリの半値半幅と閾値（例えば、閾値＝１）とを比較する。大部分のディレクトリ（例えば、一定割合以上のディレクトリ）の半値半幅が閾値未満である場合、初期開発時のアーキテクチャは機能分割型（垂直分割型）であると判断できる。このとき、半値半幅が閾値以上であるディレクトリが存在する場合、初期開発時のアーキテクチャに反するような保守・改変が行われた可能性がある。すなわち、当初の設計思想と現在の実装状況との乖離が疑われる。一方、大部分のディレクトリ（例えば、一定割合以上のディレクトリ）の半値半幅が閾値以上である場合、初期開発時のアーキテクチャはレイヤ分割型（水平分割型）であると判断できる。このとき、半値半幅が閾値未満であるディレクトリが存在する場合、初期開発時のアーキテクチャに反するような保守・改変が行われた可能性がある。すなわち、当初の設計思想と現在の実装状況との乖離が疑われる。
【００９６】
次に、分析装置１００の処理手順について説明する。
図１８は、ソフトウェア分析の手順例を示すフローチャートである。
（Ｓ１０）クラスタリング部１２２は、ソースコード記憶部１２１からソースコード群を読み出し、ソースコード群を分析する。クラスタリング部１２２は、ソースコード群を複数のクラスタに分類するクラスタリングを行う。また、クラスタリング部１２２は、各ソースコードの属するディレクトリを特定する。クラスタリング部１２２は、ソースコードとディレクトリとクラスタとを対応付けたクラスタテーブル１３５を生成する。クラスタリングの詳細は後述する。
【００９７】
（Ｓ１１）可視化制御部１２４は、分析単位とするディレクトリの階層レベルの指定を受け付ける。階層レベルは、例えば、分析者が入力デバイス１１２を用いて入力する。
（Ｓ１２）可視化制御部１２４は、ステップＳ１０で生成されたクラスタテーブル１３５に基づいて、クラスタとディレクトリとを関連付ける。すなわち、可視化制御部１２４は、クラスタテーブル１３５に基づいて、ディレクトリとクラスタの組毎のソースコード数を示すソースコード数テーブル１３７を生成する。関連付け処理の詳細は後述する。
【００９８】
（Ｓ１３）ソフトウェア地図生成部１２６は、ステップＳ１０で生成されたクラスタテーブル１３５に基づいてソフトウェア地図を生成する。ソフトウェア地図生成部１２６は、クラスタテーブル１３５に記載された各ソースコードを表すノードを生成する。ソフトウェア地図生成部１２６は、当該ソースコードの属するディレクトリに応じた視覚的表現を当該ノードに付与し、属するクラスタに応じた位置に当該ノードを配置する。
【００９９】
（Ｓ１４）ヒートマップ生成部１２７は、ステップＳ１２で生成されたソースコード数テーブル１３７に基づいてヒートマップを生成する。ヒートマップ生成部１２７は、ディレクトリとクラスタの組毎に、ソースコード数に応じたマークを生成し、当該ディレクトリに対応する行と当該クラスタに対応する列とによって特定される位置に当該マークを配置する。マークは、例えば、該当するソースコードの有無を示す二値的マークまたはソースコード数に応じて異なる視覚的表現をもつ多値的マークである。
【０１００】
（Ｓ１５）評価値算出部１２８は、ステップＳ１２で生成されたソースコード数テーブル１３７に基づいて、ディレクトリ毎のディレクトリ評価値を算出する。ディレクトリ評価値は、クラスタ順位ｘに対するソースコード出現割合ｆ（ｘ）を示すガウス関数の半値半幅である。評価値算出部１２８は、複数のディレクトリそれぞれのディレクトリ評価値を含む評価値テーブルを生成する。評価値算出の詳細は後述する。
【０１０１】
（Ｓ１６）可視化制御部１２４は、ステップＳ１３で生成されたソフトウェア地図、ステップＳ１４で生成されたヒートマップ、および、ステップＳ１５で生成された評価値テーブルをディスプレイ１１１に表示させる。なお、ステップＳ１３〜Ｓ１５は任意の順序で実行することができ、並行して実行することもできる。
【０１０２】
図１９は、クラスタリングの手順例を示すフローチャートである。
クラスタリングは、上記のステップＳ１０で実行される。
（Ｓ２０）クラスタリング部１２２は、ソースコード記憶部１２１に記憶されたソースコードの数をカウントする。クラスタリング部１２２は、空の隣接行列１３３（隣接行列Ａ）として、一辺がソースコード数の正方行列を生成する。
【０１０３】
（Ｓ２１）クラスタリング部１２２は、ソースコードｉを選択する。
（Ｓ２２）クラスタリング部１２２は、ソースコードｉの中からメソッド呼び出しを抽出し、呼び出し先の処理単位を記載したソースコードｊを特定する。
【０１０４】
（Ｓ２３）クラスタリング部１２２は、ステップＳ２０で生成した隣接行列１３３のｉ行ｊ列の要素（要素Ａij）を「１」に更新する。
（Ｓ２４）クラスタリング部１２２は、ステップＳ２１で全てのソースコードが選択されたか判断する。全てのソースコードが選択された場合はステップＳ２５に処理が進み、それ以外の場合はステップＳ２１に処理が進む。
【０１０５】
（Ｓ２５）クラスタリング部１２２は、隣接行列１３３の各列を正規化する。すなわち、クラスタリング部１２２は、隣接行列１３３の列毎に「１」の要素の数（Ｋ）をカウントし、当該列の「１」の要素を１／Ｋに更新する。
【０１０６】
（Ｓ２６）クラスタリング部１２２は、仮のクラスタとしてソースコード数に相当する数のクラスタを生成し、複数のソースコードを互いに異なるクラスタに分類する。
（Ｓ２７）クラスタリング部１２２は、ステップＳ２６のクラスタリング結果について、前述の数式（１）を用いてモジュラリティ評価値Ｑを算出する。
【０１０７】
（Ｓ２８）クラスタリング部１２２は、現在のクラスタリング結果の中から２つのクラスタを選択し、選択した２つのクラスタを併合するクラスタ併合案を生成する。クラスタリング部１２２は、そのクラスタ併合案を採用した場合のモジュラリティ評価値Ｑを算出する。クラスタリング部１２２は、現在のクラスタリング結果の中から２つのクラスタを選択する選択パターンそれぞれについてクラスタ併合案の生成とモジュラリティ評価値Ｑを繰り返し、モジュラリティ評価値Ｑが最大になるクラスタ併合案を特定する。
【０１０８】
（Ｓ２９）クラスタリング部１２２は、ステップＳ２８で特定したクラスタ併合案を採用した場合のモジュラリティ評価値Ｑが、現在のクラスタリング結果のモジュラリティ評価値Ｑよりも改善しているか（例えば、前者が後者より大きいか）判断する。モジュラリティ評価値Ｑが改善している場合はステップＳ３０に処理が進み、モジュラリティ評価値Ｑが同じかまたは悪化した場合はステップＳ３１に処理が進む。
【０１０９】
（Ｓ３０）クラスタリング部１２２は、ステップＳ２８で特定したクラスタ併合案を採用し、２つのクラスタを併合する。そして、併合後のクラスタリング結果を現在のクラスタリング結果として、ステップＳ２８に処理が進む。
【０１１０】
（Ｓ３１）クラスタリング部１２２は、ステップＳ２８で特定したクラスタ併合案を採用せず、現在のクラスタリング結果を確定させる。また、クラスタリング部１２２は、各ソースコードの属するディレクトリを特定する。例えば、クラスタリング部１２２は、ソースコードからパッケージ名を抽出する。そして、クラスタリング部１２２は、ソースコードとディレクトリとクラスタを対応付けたクラスタテーブル１３５を生成する。
【０１１１】
図２０は、関連付け処理の手順例を示すフローチャートである。
関連付け処理は、上記のステップＳ１２で実行される。
（Ｓ４０）可視化制御部１２４は、ステップＳ３１で生成されたクラスタテーブル１３５から、ステップＳ１１で指定された階層レベルのディレクトリを抽出し、ディレクトリ数をカウントする。また、可視化制御部１２４は、クラスタテーブル１３５からクラスタを抽出し、クラスタ数をカウントする。可視化制御部１２４は、ディレクトリ数とクラスタ数に基づいて、空のソースコード数テーブル１３７を生成する。
【０１１２】
（Ｓ４１）可視化制御部１２４は、クラスタテーブル１３５からレコードを選択する。
（Ｓ４２）可視化制御部１２４は、ステップＳ４１で選択したレコードに含まれるディレクトリ名を、指定された階層レベルに応じたディレクトリ名に変換する。すなわち、可視化制御部１２４は、指定された階層レベルより下位のサブディレクトリの名称を、選択したレコードに含まれるディレクトリ名から削除する。
【０１１３】
（Ｓ４３）可視化制御部１２４は、ステップＳ４０で生成したソースコード数テーブル１３７の中から、ステップＳ４２で変換したディレクトリ名と選択したレコードに含まれるクラスタＩＤとによって特定される要素を選択する。可視化制御部１２４は、選択した要素の値（ソースコード数のカウント）を１加算する。
【０１１４】
（Ｓ４４）可視化制御部１２４は、ステップＳ４１においてクラスタテーブル１３５に含まれる全てのレコードが選択されたか判断する。全てのレコードが選択された場合はステップＳ４５に処理が進み、それ以外の場合はステップＳ４１に処理が進む。
【０１１５】
（Ｓ４５）可視化制御部１２４は、クラスタテーブル１３５の列毎、すなわち、クラスタ毎にソースコード数を合計する。
（Ｓ４６）可視化制御部１２４は、合計値の降順にクラスタをソートする。
【０１１６】
（Ｓ４７）可視化制御部１２４は、ステップＳ１４で生成されるヒートマップのマークが対角線に並ぶように、クラスタの順位に対応させてディレクトリをソートする。例えば、可視化制御部１２４は、あるクラスタに属するソースコードのディレクトリのうちソースコード数が最大であるディレクトリが、当該クラスタの順位に対応する順位になるように、ディレクトリをソートする。
【０１１７】
図２１は、評価値算出の手順例を示すフローチャートである。
評価値算出は、上記のステップＳ１５で実行される。
（Ｓ５０）評価値算出部１２８は、ステップＳ４０〜Ｓ４７によって生成されたソースコード数テーブル１３７の中からディレクトリを１つ選択する。
【０１１８】
（Ｓ５１）評価値算出部１２８は、ステップＳ５０で選択したディレクトリについて、ソースコード数テーブル１３７の行方向にソースコード数を合計する。すなわち、評価値算出部１２８は、選択したディレクトリに属するソースコード総数を算出する。
【０１１９】
（Ｓ５２）評価値算出部１２８は、ステップＳ５０で選択したディレクトリのクラスタ毎のソースコード数に基づいて、クラスタをソースコード数の降順にソートする。
（Ｓ５３）評価値算出部１２８は、クラスタ毎のソースコード数を正規化する。すなわち、評価値算出部１２８は、クラスタ毎のソースコード数をステップＳ５１で算出したソースコード総数で割って、ソースコード出現割合に変換する。
【０１２０】
（Ｓ５４）評価値算出部１２８は、ガウス関数のパラメータである係数Ｂ，平均値μ，標準偏差σの値を設定する。１回目は、例えば、Ｂ＝１，μ＝１，σ＝１のように所定値とする。２回目以降は、評価値算出部１２８は、ランダムにパラメータの値を変化させてもよいし、前回のステップＳ５５で算出された残差二乗和を参考にして残差二乗和が小さくなることが期待される方法でパラメータの値を変化させてもよい。
【０１２１】
（Ｓ５５）評価値算出部１２８は、ステップＳ５４で設定したパラメータの値を用いて、クラスタ順位ｘとソースコード出現割合ｆ（ｘ）の対応関係を表すガウス関数を特定する。評価値算出部１２８は、特定したガウス関数が示すソースコード出現割合の推定値とステップＳ５３で算出したソースコード出現割合の実際値の間の残差二乗和を算出する。残差二乗和は、ガウス関数のフィッティングの良否を表す指標である。
【０１２２】
（Ｓ５６）評価値算出部１２８は、ステップＳ５５で算出した残差二乗和が所定の閾値未満であるか、すなわち、十分に良好なガウス関数が得られたか判断する。また、評価値算出部１２８は、ステップＳ５４，Ｓ５５の試行回数が所定の閾値に達したか、すなわち、ガウス関数の探索を十分な回数繰り返したか判断する。上記２つの条件の少なくとも一方が満たされた場合はステップＳ５７に処理が進み、上記２つの条件の何れも満たされていない場合はステップＳ５４に処理が進む。
【０１２３】
（Ｓ５７）評価値算出部１２８は、ステップＳ５５の残差二乗和が最小になるパラメータの値を採用し、ガウス関数を確定する。なお、図２１では試行錯誤的にガウス関数のフィッティングを行ったが、他の方法でフィッティングを行ってもよい。
【０１２４】
（Ｓ５８）評価値算出部１２８は、ステップＳ５７で確定したガウス関数の半値半幅を、ステップＳ５０で選択したディレクトリのディレクトリ評価値として算出する。すなわち、評価値算出部１２８は、ガウス関数におけるソースコード出現割合の最大値ｆmaxを算出し、ｆ（ｘ）＝ｆmax／２になるｘと中心との間の距離を算出する。
【０１２５】
評価値算出部１２８は、ラベルテーブル１３６から、ステップＳ５０で選択したディレクトリに対応するディレクトリラベルを検索する。評価値算出部１２８は、検索されたディレクトリラベルとステップＳ５１で算出したソースコード数とステップＳ５８で算出した半値半幅を対応付けて、評価値テーブルに登録する。
【０１２６】
（Ｓ５９）評価値算出部１２８は、ステップＳ５０においてソースコード数テーブル１３７に記載された全てのディレクトリが選択されたか判断する。全てのディレクトリが選択された場合は評価値算出が終了し、それ以外の場合はステップＳ５０に処理が進む。
【０１２７】
第２の実施の形態の分析装置１００によれば、設計思想に関する情報としてソースコードの属するディレクトリの情報が取得され、ソースコード間の呼び出し関係に基づいてアプリケーションソフトウェアの機能に関する情報としてクラスタの情報が取得される。そして、ディレクトリと機能の関係を可視化した可視化情報として、ソフトウェア地図、ヒートマップおよび評価値テーブルが生成されて表示される。
【０１２８】
これにより、アプリケーションソフトウェアのアーキテクチャを俯瞰することができる。また、設計情報が残っていない場合であっても、初期開発時の設計思想を理解することが容易となる。また、初期開発時の設計思想と現在の実装状況との間の乖離を検出することが容易となり、これまで行ってきた保守・改変の良否を評価することができる。また、適切でなかった保守・改変を特定することが容易となる。また、設計思想と実装状況の乖離の程度が定量的に算出される。よって、説得力のある分析情報が提供されると共に、異なるアプリケーションソフトウェアの間の比較が容易となる。
【０１２９】
なお、前述のように、第１の実施の形態の情報処理は分析装置１０にプログラムを実行させることで実現できる。第２の実施の形態の情報処理は、分析装置１００にプログラムを実行させることで実現できる。
【０１３０】
プログラムは、コンピュータ読み取り可能な記録媒体（例えば、記録媒体１１３）に記録しておくことができる。記録媒体として、例えば、磁気ディスク、光ディスク、光磁気ディスク、半導体メモリなどを使用できる。磁気ディスクには、ＦＤおよびＨＤＤが含まれる。光ディスクには、ＣＤ、ＣＤ−Ｒ（Recordable）／ＲＷ（Rewritable）、ＤＶＤおよびＤＶＤ−Ｒ／ＲＷが含まれる。プログラムは、可搬型の記録媒体に記録されて配布されることがある。その場合、可搬型の記録媒体から他の記録媒体（例えば、ＨＤＤ１０３）にプログラムをコピーして実行してもよい。
【符号の説明】
【０１３１】
１０  分析装置
１１  記憶部
１２  演算部
１３ａ，１３ｂ，１３ｃ，１３ｄ  コード
１４ａ，１４ｂ  クラスタ
１５  ディレクトリ情報
１５ａ，１５ｂ，１５ｃ  ディレクトリ
１６ａ，１６ｂ，１６ｃ  評価値
【図１】
2017068534.tif 000005
【図２】
2017068534.tif 000006
【図３】
2017068534.tif 000007
【図４】
2017068534.tif 000008
【図５】
2017068534.tif 000009
【図６】
2017068534.tif 000010
【図７】
2017068534.tif 000011
【図８】
2017068534.tif 000012
【図９】
2017068534.tif 000013
【図１０】
2017068534.tif 000014
【図１１】
2017068534.tif 000015
【図１２】
2017068534.tif 000016
【図１３】
2017068534.tif 000017
【図１４】
2017068534.tif 000018
【図１５】
2017068534.tif 000019
【図１６】
2017068534.tif 000020
【図１７】
2017068534.tif 000021
【図１８】
2017068534.tif 000022
【図１９】
2017068534.tif 000023
【図２０】
2017068534.tif 000024
【図２１】
2017068534.tif 000025