JP5981327B2 - ソフトウェア複雑度測定装置及び方法並びにプログラム - Google Patents

Description

本発明は、ソフトウェア複雑度測定装置及びソフトウェア複雑度測定方法並びにプログラムに関する

近年のソフトウェアの巨大化、複雑化は著しく、ソフトウェアに含まれるモジュール数も膨大となり、またモジュール間の依存関係も著しく複雑化してきている。しかし、モジュール間の依存関係がスパゲティ状に複雑になるほど、ソフトウェアの保守性は低くなる。

そこで、モジュール間の依存関係の複雑さを表す指標によって、保守性に問題のあるモジュール構造を定量的に判断し、改善につなげることが試みられてきた。モジュール間の依存関係の複雑さを表す従来の一般的な指標として、以下の指標が提案されている。Inter-Module Complexity（Henry-Kafura）は、モジュールのfan-in数とfan-out数に着目し、(fan-in * fan-out)^2 をモジュールの複雑さとして評価する指標である。

特開２００１−３２５１００号公報 特開２０００−２１５０４５号公報 特開２００８−０８３９１２号公報

既存の指標では、依存関係の複雑さを引き起こしている、関数の呼び出しとデータ参照の依存だけを指標化している。しかしながら、関数の呼び出しが循環して行われる場合や、上位モジュールのデータを下位モジュールが直接参照する場合などでは、依存が一定方向に流れない。依存が一定方向に流れないこと（逆方向の依存性）は、人間の理解度を落とす要因を作る。

この点、上記の「Inter-Module Complexity（Henry-Kafura）」は、個々のモジュールにつながる依存関係の多さは判断できるが、依存関係の複雑さを引き起こしている逆方向の依存性を定量化することはできない。

そこで、本発明は、階層構造を持つソフトウェア内の同一粒度の複数の構成単位間の依存関係について逆方向の依存性を定量化することができるソフトウェア複雑度測定装置等の提供を目的とする。

上記目的を達成するため、本発明の一局面によれば、階層構造を持つソフトウェア内の同一粒度の複数の構成単位間の依存関係について、順方向の依存の経路の数と逆方向の依存の経路の数との関係を表す指標値を算出する、ソフトウェアの複雑度測定装置において、
ある３つ以上の構成単位間で循環する依存関係があるとき、循環全体の中で最も依存の数が少ない方向を逆方向として、前記順方向の依存の経路の数及び前記逆方向の依存の経路の数をカウントする、複雑度測定装置が提供される。

本発明によれば、階層構造を持つソフトウェア内の同一粒度の複数の構成単位間の依存関係について逆方向の依存性を定量化することができるソフトウェア複雑度測定装置等が得られる。

ソフトウェア複雑度測定装置１の一例を示す構成図である。 測定対象の１つのソフトウェアの概略構造の一例を示す図である。 モジュール間における依存関係の一例を示す図である。 図４（Ａ）は、図３のモジュールＸのソースコードの一部を示す図であり、図４（Ｂ）は、図３のモジュールＹのソースコードの一部を示す図である。 依存関係の他の一例を示す図である。 図６（Ａ）は、図５のモジュールＸのソースコードの一部を示す図であり、図６（Ｂ）は、図５のモジュールＹのソースコードの一部を示す図である。 依存関係の更なる他の一例を示す図である。 図８（Ａ）は、図７のモジュールＸのソースコードの一部を示す図であり、図８（Ｂ）は、図７のモジュールＹのソースコードの一部を示す図である。 ソフトウェア複雑度測定装置１の処理装置１０により実行される処理の一例を示すフローチャートである。 逆方向経路及び順方向経路の決定方法（その１）の説明図である。 逆方向経路及び順方向経路の決定方法（その２）の説明図である。 ＤＳＭを用いた逆方向経路率の算出方法の流れの一例を示す図である。

以下、図面を参照して、本発明を実施するための最良の形態の説明を行う。

図１は、ソフトウェア複雑度測定装置１の一例を示す構成図である。ソフトウェア複雑度測定装置１は、処理装置１０を含む。処理装置１０は、典型的には、コンピューターから構成される。コンピューターは、任意のコンピューターであり、汎用性のあるコンピューターであってもよい。

処理装置１０は、ＣＰＵ１２と、記憶部１４とを含んでよい。記憶部１４は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）等を含んでよい。以下で説明する処理装置１０の機能は、例えばＣＰＵ１２が記憶部１４内のプログラムを読み出して実行することにより実現されてよい。尚、記憶部１４内には、外部との有線又は無線通信を介してプログラムがダウンロードされ若しくは記録媒体を介してプログラムが格納されてもよい。尚、プログラムは、以下で説明する処理（例えば図９に示す処理）を実現するためのプログラムを含む。尚、記録媒体は、ＣＤ−ＲＯＭ、フレキシブルディスク、光磁気ディスク等の様に情報を光学的，電気的或いは磁気的に記録する記録媒体、ＲＯＭ、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等を含んでよい。

処理装置１０には、表示装置１６が接続されてもよい。表示装置１６は、コンピューターのディスプレイに相当してよい。表示装置１６は、液晶ディスプレイであってもよいし、他のタイプのディスプレイであってもよい。表示装置１６には、処理装置１０によるソフトウェアの複雑度の測定結果（例えば、後述の指標値等）が表示されてよい。尚、処理装置１０と表示装置１６との間の接続は、有線又は無線若しくはそれらの組合せで実現されてよく、また、表示装置１６は、処理装置１０に対して遠隔位置に存在してもよい。例えば、処理装置１０は、ホストコンピューターであり、表示装置１６は、クライアントコンピューターのディスプレイであってもよい。

ソフトウェア複雑度測定装置１は、ソフトウェアの複雑度を測定する。測定対象のソフトウェアは任意である。例えば、測定対象のソフトウェアは、設計段階（開発段階）のソフトウェアであってもよいし、開発済み（実装済み）のソフトウェアであってもよい。

図２は、測定対象の１つのソフトウェアの概略構造の一例を示す図である。１つのソフトウェアは、図２に示すように、複数のコンポーネントを含んでよい。１つのコンポーネントは、複数のモジュールを含んでよい。１つのモジュールは、複数の関数を含んでよい。このようにソフトウェアの構造は、関数（及び共有変数）、モジュール、コンポーネントなどの構成単位と、構成単位間の依存関係とで定義することができる。尚、構成単位を"箱"、依存関係を方向のついた線とみなすと、ソフトウェア構造は箱と線との組合せで表現することができる。一般的には、コンポーネント内部には複数のモジュールが含まれ、モジュール内部には複数の関数が含まれる。従って、ソフトウェア全体は、大きな粒度（例えばコンポーネント）の箱の中に、より小さい粒度（例えばモジュール）の箱と線が含まれる階層的な構造として表現することができる。尚、以下では、一例として、ソフトウェア全体がコンポーネントに分割され、コンポーネントがモジュールに分割され、モジュールが関数に分割された３階層のソフトウェア構造を前提として説明を続ける。

尚、図２に示す例では、１つのソフトウェアは、３つのコンポーネントを含み、１つのコンポーネントは、３つのモジュールを含み、１つのモジュールは、３つの関数を含んでいるが、これらの数は任意であり、多様となりうる。

尚、モジュールとは、関数や変数といったソフトウェアの構成要素のうち、関係（例えば依存関係）がある構成要素をまとめたものをいう。なお、関係がある構成要素をまとめたものであれば、どのようなものでも「モジュール」に相当し、例えばファイル、クラス、オブジェクトなども「モジュール」に含まれる概念である。

ソフトウェア複雑度測定装置１は、ソフトウェアの複雑度について、コンポーネント粒度（コンポーネント間）、モジュール粒度（モジュール間）、及び、関数粒度（関数・共有変数間）で、それぞれ算出する。ソフトウェアの複雑度は、依存関係に基づいて算出されてもよい。例えば、コンポーネント粒度における複雑度は、コンポーネント間の依存関係に基づいて算出されてよく、同様に、モジュール粒度における複雑度は、コンポーネント毎に、コンポーネント内におけるモジュール間の依存関係に基づいて算出されてよく、同様に、関数粒度における複雑度は、モジュール毎に、モジュール内における関数・共有変数間の依存関係に基づいて算出されてよい。

ここで、「依存関係」とは、例えばモジュール粒度の場合、あるモジュールに含まれる関数が、別モジュールに含まれる関数を呼び出したり、別モジュールに含まれる変数を読み書きたりする関係にあることをいう。

図３は、モジュール間における依存関係の一例を示す図である。図３では、モジュールＸの関数がモジュールＹの関数を呼び出すタイプの依存関係が模式的に示される。即ち、図３に示す例では、モジュールＸの関数がモジュールＹの関数を呼び出す関係にある。また、このモジュールＸのソースコードの一部を図４（Ａ）に示し、モジュールＹのソースコードの一部を図４（Ｂ）に示す。図３及び図４に示すように、モジュールＸ内の関数「funcA(void)」は、内部にモジュールＹに含まれる関数「funcB()」の呼び出しが記述されている。尚、この場合、モジュールＸからモジュールＹへの依存が存在することとしてよい。

図５は、モジュール間における依存関係の他の一例を示す図である。図５では、モジュールＸの関数がモジュールＹの変数を呼び出すタイプの依存関係が模式的に示される。即ち、図５に示す例では、モジュールＸの関数がモジュールＹの変数を呼び出す関係にある。また、このモジュールＸのソースコードの一部を図６（Ａ）に示し、モジュールＹのソースコードの一部を図６（Ｂ）に示す。図５及び図６に示すように、モジュールＸ内の関数「funcA(void)」は、内部にモジュールＹに含まれる変数（共有変数）「verC」を参照することが記述されている。尚、この場合、モジュールＸからモジュールＹへの依存が存在することとしてよい。

図７は、モジュール間における依存関係の更なる他の一例を示す図である。図７では、モジュールＸの関数がモジュールＹの変数を更新するタイプの依存関係が模式的に示される。即ち、図７に示す例では、モジュールＸの関数がモジュールＹの変数を更新する関係にある。また、このモジュールＸのソースコードの一部を図８（Ａ）に示し、モジュールＹのソースコードの一部を図８（Ｂ）に示す。図７及び図８に示すように、モジュールＸ内の関数「funcA(void)」は、内部にモジュールＹに含まれる変数（共有変数）「verC」を更新することが記述されている。尚、この場合、モジュールＹからモジュールＸへの依存が存在することとしてよい。

尚、図３乃至図８では、モジュール間における依存関係について説明したが、コンポーネント間、関数・共有変数間、関数内においても実質的に同様である。例えば、あるコンポーネント内のモジュールの関数が、他のコンポーネント内のモジュールの関数を呼び出す場合、或いは、あるコンポーネント内のモジュールの関数が、他のコンポーネント内のモジュールの変数を呼び出す又は更新する場合は、コンポーネント間に依存関係が存在する。同様に、ある関数が、他の関数を呼び出す場合、或いは、ある関数が、共有変数を呼び出す又は更新する場合は、関数・共有変数間に依存関係が存在する。

尚、図３乃至図６に示す例では、モジュールＸからモジュールＹへの依存が存在し、図７乃至図８に示す例では、モジュールＹからモジュールＸへの依存が存在するとしているが、このような依存の方向（依存元と依存先との関係）については、用途に応じて自由に定義してよい。

図９は、ソフトウェア複雑度測定装置１の処理装置１０により実行される処理の一例を示すフローチャートである。図９に示す処理は、測定対象のソフトウェアが指定されることで実行されてよい。或いは、測定対象のソフトウェアを入力データ（例えば、Ｃソースコード）として入力して実行されてよい。

ステップ９００では、測定対象のソフトウェア内のコンポーネント間の依存関係の複雑度を表す第１指標値が算出される。

ステップ９０２では、モジュール間の依存関係の複雑度を表す第２指標値が算出される。第２指標値は、測定対象のソフトウェア全体に対して算出されてもよいし、測定対象のソフトウェア内のコンポーネント毎に算出されてもよい。

ステップ９０４では、測定対象のソフトウェア内の各関数・共有変数間の依存関係の複雑度を表す第３指標値が算出される。第３指標値は、測定対象のソフトウェア全体に対して算出されてもよいし、コンポーネント毎に、コンポーネント内の各関数・共有変数に基づいて算出されてもよいし、モジュール毎に、モジュール内の各関数・共有変数に基づいて算出されてもよい。

ステップ９０６では、上記ステップ９００，９０２，９０４でそれぞれ算出された第１乃至第３指標値が所定基準値と比較される。所定基準値は、保守性の良好なソフトウェア構造で得られる同指標値の上限値に対応し、適合された固定値であってもよいし、可変値であってもよい。また、所定基準値は、第１乃至第３指標値に対してそれぞれ別々に設定されてもよい。尚、保守性の良好なソフトウェア構造とは、保守作業（変更時の内容理解、修正、テストなど）に必要な努力（工数）が少なくて済む構造を指す。

ステップ９０８では、第１乃至第３指標値のうち、所定基準値を超えた指標値については、第１出力態様で表示装置１６に出力される。第１出力態様は、ユーザに注意喚起を促す態様であってよい。例えば、所定基準値を超えた指標値が赤色等で表示されてもよいし、点滅等する態様で表示されてもよい。他方、第１乃至第３指標値のうち、所定基準値を超えない指標値については、第２出力態様で表示装置１６に出力される。第２出力態様は、第１出力態様よりも注意喚起度の低い通常態様であってよい。尚、第１出力態様は、警告を含むメッセージの出力を伴ってもよい。

尚、図９に示す例では、第１乃至第３指標値の全てが算出されているが、第１乃至第３指標値のうちのいずれか１つ又は２つが算出され、所定基準値と比較されてもよい。

次に、第１乃至第３指標値の算出方法の例について説明する。

第１乃至第３指標値は、それぞれ、例えば、逆方向経路率を表す値であってよい。逆方向経路率は、例えば、以下の式で定義されてもよい。
（逆方向経路率）＝（逆方向経路数）／（順方向経路数） 式（１）
ここで、上述の如く、箱Ａから箱Ｂへの依存が存在するとき、これを箱Ａから箱Ｂへの依存の経路が存在する。このとき、箱Ａから箱Ｂへの依存が何本あったとしても（例えば、箱Ａに対応するモジュール内の関数が、箱Ｂに対応するモジュール内の関数を呼び出す関係が、複数本あったとしても）、経路数は"１"と数える。但し、箱Ａから箱Ｂへの依存と、箱Ｂから箱Ａへの依存は別の依存経路であると考え、双方向の依存が存在する場合、経路数は"２"と数える。逆方向とは、ある２つの箱間において、依存の本数が少ない方向に対応し、順方向は、依存の本数が多い方向に対応する。

図１０は、逆方向経路及び順方向経路の決定方法（その１）の説明図である。

図１０（Ａ）に示す例では、箱Ａから箱Ｂへ３本の依存があり、箱Ｂから箱Ａへ２本の依存がある。この場合、依存の本数が少ない方向の経路、即ち箱Ｂから箱Ａへの経路が逆方向経路となり、依存の本数が多い方向の経路、即ち箱Ａから箱Ｂへの経路が順方向経路となる。

図１０（Ｂ）に示す例では、箱Ａから箱Ｂへ１本の依存があり、箱Ｂから箱Ａへ１本の依存がある。このように依存の最小本数が同数である場合は、ランダムにいずれか一方が逆方向とされてよい。例えば、箱Ｂから箱Ａへの経路が逆方向経路となり、箱Ａから箱Ｂへの経路が順方向経路となってもよい。

図１１は、逆方向経路及び順方向経路の決定方法（その２）の説明図である。

図１１（Ａ）に示す例では、３つの箱Ａ，Ｂ，Ｃ間で依存が循環している。この場合、循環全体の中で最も本数の少ない依存の経路が逆方向となる。図１１（Ａ）に示す例では、箱から箱Ｂへの依存の本数が"２"であり、箱Ｂから箱Ｃへの依存の本数が"２"であり、箱Ｃから箱Ａへの依存の本数が"１"である。従って、この場合、箱Ｃから箱Ａへの経路が逆方向経路となり、箱Ａから箱Ｂへの経路、及び、箱Ｂから箱Ｃへの経路が順方向経路となる。

図１１（Ｂ）に示す例では、図１１（Ａ）に示す例と同様、３つの箱Ａ，Ｂ，Ｃ間で依存が循環しているが、箱から箱Ｂへの依存の本数が"２"であり、箱Ｂから箱Ｃへの依存の本数が"１"であり、箱Ｃから箱Ａへの依存の本数が"１"である。このように依存の最小本数が同数である場合は、ランダムにいずれか一方が逆方向とされてよい。例えば、箱Ｃから箱Ａへの経路が逆方向経路とされ、箱Ａから箱Ｂへの経路、及び、箱Ｂから箱Ｃへの経路が順方向経路とされてよい。

尚、図１０及び図１１に示したように、最も少ない依存本数の経路を切ることで双方向依存（図１０）や循環依存（図１１）を解消できるような経路が逆方向経路ということができる。

逆方向経路数及び順方向経路数は、例えば以下の方法で算出されてもよい。先ず、ＤＳＭ（Dependency Structure Matrix）によって箱間の依存関係を表現する。ＤＳＭとは、列と行の交差するセルに依存元から依存先への依存関係の本数（依存の数）を記述した行列である。ＤＳＭの項目は、各箱を表す。従って、例えばモジュール粒度の場合（即ち第２指標値の場合）は、ＤＳＭの各項目は、あるコンポーネント内の各モジュールであってよい。また、関数粒度の場合（即ち第３指標値の場合）は、ＤＳＭの各項目は、各関数及び各共有変数であってよい。ＤＳＭにおける箱の並び方は、対角線より上のセル内の数字の合計（逆方向の依存数）が最小となるように最適化される。かかる最適化を行ったＤＳＭにおいて、対角線より上の各セルのうち、"１"以上の数字が入っているセルの数が、逆方向経路数となり、対角線より下の各セルのうち、"１"以上の数字が入っているセルの数が、順方向経路数となる。

図１２は、ＤＳＭを用いた逆方向経路率の算出方法の流れの一例を示す図である。図１２（Ａ）に示す例では、箱Ａから箱Ｂへの依存の本数が"１０"であり、箱Ｂから箱Ｃへの依存の本数が"１"であり、箱Ｃから箱Ａへの依存の本数が"２０"である構成が示される。このような構成について、先ず、箱Ａ，Ｂ，Ｃの並びにてＤＳＭで表現すると、図１２（Ｂ）に示すＤＳＭが得られる。このＤＳＭでは、対角線より上のセル内の数字の合計が"２０"である。対角線より上のセル内の数字の合計が最小となるように、箱Ａ，Ｂ，Ｃの並びを最適化すると、図１２（Ｃ）に示すＤＳＭが得られる。このＤＳＭによれば、図１２（Ｄ）に示すような箱Ｃ，Ａ，Ｂの並びで対角線より上のセル内の数字の合計が最小値"１"となり、最適な並びであることが分かる。従って、この例では、箱Ｂから箱Ｃへの経路が逆方向経路となり、箱Ｃから箱Ａへの経路、及び、箱Ａから箱Ｂへの経路が順方向経路となる。従って、逆方向経路数は、"１"であり、順方向経路数は、"２"であり、逆方向経路率は、"１／２"となる。

ここで、保守性の高いソフトウェア構造は、依存の方向がそろっているという特徴がある。即ち、逆方向経路数が少ないという特徴がある。従って、本実施例によれば、第１乃至第３指標値として逆方向経路率を使用することで、ソフトウェア構造の保守性の良さを定量的に評価することができる。

以上、本発明の好ましい実施例について詳説したが、本発明は、上述した実施例に制限されることはなく、本発明の範囲を逸脱することなく、上述した実施例に種々の変形及び置換を加えることができる。

例えば、上述した実施例では、各指標値は、順方向経路数に対する逆方向経路数の比であったが、順方向経路数と逆方向経路数との関係を表す限り、かかる比以外の指標値が使用されてもよい。例えば、各指標値は、全経路数（＝順方向経路数＋逆方向経路数）に対する逆方向経路数の比であってもよい。また、各指標値は、逆方向経路数に対する順方向経路数の比であってもよい。

また、上述した実施例では、測定対象のソフトウェアは、コンポーネント、モジュール、関数・共有変数の構成単位で階層構造を有しているが、階層構造における階層数は任意である。また、同一階層における各構成単位の区分け、例えばコンポーネント間の区分け（例えば、どのモジュールがどのコンポーネントに含まれるか）についても任意である。但し、典型的には、モジュールは、ソースファイル毎に存在し、コンポーネントは、ソースファイルを格納するフォルダ毎に存在する。

１ ソフトウェア複雑度測定装置
１０ 処理装置
１２ ＣＰＵ
１４ 記憶部
１６ 表示装置

Claims (8)

1. 階層構造を持つソフトウェア内の同一粒度の複数の構成単位間の依存関係について、順方向の依存の経路の数と逆方向の依存の経路の数との関係を表す指標値を算出する、ソフトウェア複雑度測定装置において、
   ある３つ以上の構成単位間で循環する依存関係があるとき、循環全体の中で最も依存の数が少ない方向を逆方向として、前記順方向の依存の経路の数及び前記逆方向の依存の経路の数をカウントする、ソフトウェア複雑度測定装置。
2. ある２つの構成単位間で順方向の依存の数が複数存在する場合でも、該2つの構成単位間における順方向の依存の経路の数は、“１”としてカウントし、ある２つの構成単位間で逆方向の依存の数が複数存在する場合でも、該２つの構成単位間における逆方向の依存の経路の数は、“１”としてカウントする、請求項１に記載のソフトウェア複雑度測定装置。
3. ある２つの構成単位間で双方向の依存があるとき、依存の数が多い方向を順方向として、前記順方向の依存の経路の数及び前記逆方向の依存の経路の数をカウントする、請求項１又は２に記載のソフトウェア複雑度測定装置。
4. 前記指標値は、ＤＳＭ（Dependency Structure Matrix）を用いて算出され、
   前記ＤＳＭの項目には、前記複数の構成単位のそれぞれが入り、前記ＤＳＭの各セルには、各構成単位間における依存の数が入る、請求項１〜３うちのいずれか1項に記載のソフトウェア複雑度測定装置。
5. 前記ＤＳＭの項目は、前記ＤＳＭの対角線よりも上側のセル内の数が最小となるように、並び順が変更される、請求項４に記載のソフトウェア複雑度測定装置。
6. 前記指標値は、前記ＤＳＭの対角線よりも下側のセル内の数が１以上のセル数と、前記ＤＳＭの対角線よりも上側のセル内の数が１以上のセル数との比に基づいて、算出される、請求項５に記載のソフトウェア複雑度測定装置。
7. 階層構造を持つソフトウェア内の同一粒度の複数の構成単位間の依存関係について、順方向の依存の経路の数と逆方向の依存の経路の数との関係を表す指標値を算出する、ソフトウェア複雑度測定方法において、
   ある３つ以上の構成単位間で循環する依存関係があるとき、循環全体の中で最も依存の数が少ない方向を逆方向として、前記順方向の依存の経路の数及び前記逆方向の依存の経路の数をカウントする、ソフトウェア複雑度測定方法。
8. 階層構造を持つソフトウェア内の同一粒度の複数の構成単位間の依存関係について、順方向の依存の経路の数と逆方向の依存の経路の数との関係を表す指標値を算出する、
   処理をコンピューターに実行させるプログラムにおいて、
   ある３つ以上の構成単位間で循環する依存関係があるとき、循環全体の中で最も依存の数が少ない方向を逆方向として、前記順方向の依存の経路の数及び前記逆方向の依存の経路の数をカウントする、プログラム。

Images