メトリクス計測プラグインプラットフォーム MASU の開発
三 宅

達

也†

肥 後

芳

樹†

井 上

克

郎†

ソフトウェアメトリクスとは，ソフトウェアのさまざまな特性を評価する尺度である. 近年，ソフ
トウェアの大規模化・複雑化に伴い，ソフトウェアの特性評価はますます重要になり，さまざまなソ
フトウェアメトリクスが提案されている．しかし，メトリクスの計測は大きなコストを必要とする．
とくにソースコードを対象としたメトリクスは計測のためにソースコード解析を行う必要があるが，ソースコード解析器の実装は容易ではない．また，計測するメトリクスが異なれば，ソースコード解
析器が解析しなければならない情報は異なる．さらに，通常ソフトウェアメトリクスは，ファイルやクラス，メソッドといったソフトウェアの概念的な要素に対して定義されるものであり，同じ概念を共有する言語に共通して適用できるが，ソースコード解析器は言語ごとに用意しなければならない．
このため，メトリクスを計測するツールの多くは単一の言語を対象としており，異なる言語で記述された複数のソフトウェアから統一的にメトリクス値を計測することは難しい. そこで我々は，複数の言語に対して適用可能であり，かつ，必要最低限のビジネスロジックを記述するだけでメトリクスの計測を可能とするメトリクス計測プラグインプラットフォーム MASU を開発している. 本稿ではMASU の概要と今後の展望について述べる.

MASU: Metrics Assessment plugin-plutform
for Software Unit of multiple programming languages
Tatsuya Miyake,† Yoshiki Higo† and Katsuro Inoue†
Software metrics are quantitative measures of software quality. Recently, software evaluation is getting an important role because the size and complexity of software systems are
getting increased. Software metric is a tool for evaluating software systems. However, metrics measurement requires substantial cost because it needs source code analysis; developinga source code analyzer is an arduous task. Moreover, each metric requires diﬀerent information for computing it. Additionaly, software metrics are measured from conceptual unitsof software systems such as ﬁle, class, and method ,so that it can be applied to multiple
programming languages sharing the same consept. However, source code analyzers have tobe developed for each programming languages because the source code written in diﬀerent
language have diﬀerent grammers. Almost existing tools target only a single programming
languages, which makes it diﬃcult to measure software metrics from multiple programming
languages in a uniﬁed way. In this paper, we introduce a software platform, MASU (Metrics Assesment plugin platform for Software Unit of multiple programming languages). The
platform enables us to measure software metrics only by implementing the bussiness logics.

1. は じ め にイクロマチック数7) などのさまざまな種類のメトリクスが存在する．これらのメトリクスは，ファイルやク

ソフトウェアメトリクスとは，ソフトウェアの品質

ラス，メソッド，関数，制御フローといったソフトウェ評価に用いられる尺度であり8) ，ソースコードなどのアの概念的な要素に対して定義されているため，言語

ソフトウェアプロダクトから計測される．ソフトウェ

間の記述様式の差異にとらわれることなく，同じ概念

アメトリクスには単純にソースコードの行数を表すを共有する言語に共通して適用することができる．

LOC から，オブジェクト指向言語におけるクラスや

しかし，メトリクスを計測するために，ソースコー

メソッド，フィールド間の関連性を評価する CK メト

ドを解析しソフトウェアの概念的な要素の情報を取得

リクス4) ，関数やメソッド内の処理の複雑さを表すサ

するには大きなコストを必要とする．これまでに種々† 大阪大学大学院情報科学研究科
Graduate School of Information Science and Technology, Osaka Universityのコンパイラコンパイラが開発されているが，それらが支援しているのは抽象構文木構築などの構文解析までであり，変数の参照・代入や関数の呼び出しなど，

どのようにプログラム内の要素が関連しているかを調

ラス (根) に至る最長経路の長さとなる．

査するための意味解析を行うためには，開発者自らがNOC (Number Of Children) 計測対象クラス

実装しなければならない．また，メトリクスを計測すから直接派生しているサブクラスの数．

るツールの多くは単一言語を対象としているため5) ，CBO (Coupling Between Object classes) 計

さまざまな言語のソースコードのメトリクスを計測す

測対象クラスが結合しているクラスの数．クラス

るには，それぞれの言語に対応した計測ツールを個別間の結合とは，あるクラスが他のクラスの属性やに用意する必要がある．そのような場合，個々のツーメソッド，インスタンス変数を使用していること

ルが対応しているメトリクスの種類が異なっていたり，を意味する．

同一のメトリクスであっても定義が曖昧な部分の解釈

RFC (Response For a Class) 計測対象クラス

や計測方法などが異なることがあり，複数の言語からに対する参照．ローカルメソッドの数とリモー

統一的にメトリクス値を計測することは難しい．これトメソッドの数で定義される．ローカルメソッド

らのことを踏まえると，以下の特徴をもつメトリクス

は計測対象のクラスに定義されているメソッド，

計測ツールが必要であるといえる．

リモートメソッドは計測対象のクラス以外で定義• 複数のプログラミング言語のソースコードに対して適用可能である．

されているメソッドのうちローカルメソッドから呼び出されているメソッドである．

• 多言語の解析から得た結果を統一的に扱える．

LCOM (Lack of Cohesion in Methods) メソッ• ユーザは，必要最低限のビジネスロジックを記述

ドの凝集の欠如．メソッドの凝集度とはクラスのするだけで，新たなメトリクスを計測可能である．

メソッドと属性の関連性を意味する．凝集性が高本稿では，これらの要求を満たすべく我々が開発しいほど，意味的に「閉じた」クラス設計がなされているメトリクス計測用プラグインプラットフォームていることになり，良い設計であることを示す．

MASU を紹介する．

LCOM は計測対象クラスのメソッドのすべての

2. 背

景

2.1 ソフトウェアメトリクス
ソフトウェアメトリクスとは，ソフトウェアの品質

組み合わせのうち，共通した属性を参照していな
いメソッドの組み合わせの数から，共通した属性
を参照しているメソッドの組み合わせの数を引いた値となる．ただし，計測値が 0 より小さいさく

評価や工数・保守コスト予測などに用いられる尺度でなるときは，0 となる．

ある8) ．代表的なソフトウェアメトリクスには，オブ2.1.2 サイクロマチック数

ジェクト指向言語におけるクラスやメソッド，フィー

サイクロマチック数とは，McCabe によって提案さルド間の関連性からソフトウェアの複雑度を評価するれたメトリクスであり7) ，メソッドの複雑度を表す．プ

CK メトリクス，関数やメソッド内の処理の複雑さをログラムの制御フローを有効グラフで表現したときの表すサイクロマチック数などが存在する．

枝の数を e，節点の数を n と定義すると e − n + 2 で

2.1.1 CK メトリクス表される．この値は直観的にはソースコード上の分岐

CK メトリクスは，Chidamber と Kemerer によっの数に 1 を加えた数を表す．サイクロマチック数が大て提案されたオブジェクト指向設計を対象とする複雑

きいほど，そのメソッドの制御フローは複雑になり，度メトリクスである4) ．Basili らによって，従来のコー

保守性や可読性が低いことを意味する．

ドメトリクスの組み合わせよりもフォールトの発生を

2.1.3 ソフトウェアメトリクス計測

予測するための良い指標となることが示されている．

ソースコードを対象としたメトリクス計測は基本的

次に示す 6 つのメトリクスにより構成されている．

に次の 2 ステップに分けることができる．

WMC (Weighted Methods per Class) クラス

ソースコード解析 メトリクス値の計測に必要な情報あたりの重み付きメソッド数．通常，重み付けにはサイクロマチック数7) やソフトウェアサイエンス6) が用いられるが，厳密な定義はされていない.

をソースコードから抽出．
メトリクス値計測 ソースコードから抽出した情報を利用してメトリクス値を計測．

DIT (Depth of Inheritance Tree) 計測対象の多くのソフトウェアメトリクスは，CK メトリクス

クラスの継承木内での深さ．多重継承が可能であやサイクロマチック数のようにファイルやクラス，メる場合は，継承木における計測対象クラス (を表ソッド，関数，制御フローといったソフトウェアの概す節点) からそれ以上基底クラスが存在しないク

念的な要素に対して定義されるものであるため，言語

間の記述様式の差異にとらわれることなく，同じ概念実現されることなく，単なるアイデアとして学位論文を共有する言語に共通して適用できる．つまり，メトにまとめられてしまっている．

リクス値計測のロジックは言語が異なっても共通してこれらの問題は，深い解析を行う解析器を実装する

利用することができる．一方，異なる記述様式に対応

コストが高いことに起因している．解析者は，ビジネするためには，各記述様式用のソースコード解析器をスロジックの実装ではなく，そのビジネスロジックで用意しなければならない.

用いる情報を抽出する解析器の実装に悩まされている.

ソフトウェアメトリクスの計測に必要なコストの大部分はソースコード解析が占めている．このため，既3. MASU の概要

存のメトリクス計測ツールの多くは単一の言語を対象

ソフトウェアメトリクスの計測にともなう問題を解としており，複数の言語で記述されたソフトウェアか決するため，我々は複数言語の解析結果から統一的に

ら統一的にメトリクス値を計測することは難しい．

メトリクス計測を行えるプラグインプラットフォーム

2.2 ソースコード解析

MASU(Metircs Assesment plugin platform for Soft-

ソースコード解析とは，ソースコードを解析器と呼ware Unit) を開発した．MASU は次の特徴をもつ．

ばれるプログラムを用いて，自動で必要な情報を抽出• 複数のプログラミング言語のソースコードに対しする技術である．抽出された情報は，ソフトウェアメて適用可能である．

トリクスやその組織独自の方法を用いて調査され，ソ• 多言語の解析から得た結果を統一的に扱える．

フトウェアの品質を把握するためなどに用いられる．

• 言語依存な要素にも対応するため，解析対象ソフ

しかし，ソースコードを解析し，その情報からメト

トウェアの構成要素の追加や変更を柔軟に行える．

リクスなどを算出するには，例えば，関数間の呼び出• ユーザは，必要最低限のビジネスロジックを記述

し関係などの，意味解析以上の深い解析をしなければするだけで，新たなメトリクスを計測可能である．

得ることのできない情報を必要とするため，解析器自MASU は Java を用いて実装されており，現在，規体を作成することに大きなコストが必要である．既に，JavaCC

1)や ANTLR2)などに代表される多くのコン模は約 42000 行，クラス数は約 390 である．

3.1 入 出 力

パイラコンパイラが開発されているが，それらが支援

MASU は，広く使われているオブジェクト指向言語

するのは構文解析までであり，それ以上の深い解析をのソースコードからメトリクスを計測する．出力は対行う場合は，多大な時間と労力を必要とする．

象ソースコードに含まれるすべてのクラスやメソッド

一方，ソフトウェアのソースコードが調査される機などのメトリクスの値やソースコード解析情報である.

会は増加しており，ソースコード解析技術の重要性は3.2 アーキテクチャ

増している．たとえば，ソフトウェア開発企業では，

MASU の構成図を図 1 に示す．本ツールは次の 2

QA（Quality Assurance) のために，開発したソフト

種類のモジュールから構成される．

ウェアをソフトウェア工学的な手法を用いて調査する

メインモジュール ソースコードを解析し共通データことが増えてきた．この調査の一環として，ソース
コード解析を行い，その品質や今後の保守コストなどを予測することが多い．しかし，近年顕著に見られるを構築する．
プラグイン 共通データを用いて個別のメトリクス値を計測する．

開発期間の短縮化や，対象ソフトウェアによって適用

以下にそれぞれの詳細を示す．

する解析手法が異なることから，満足に QA が行われ3.2.1 メインモジュールているとは言えない．
また，情報化社会のニーズに応えるために，国内の多くの大学において情報系学部・学科が新設されている．そのため，卒業論文や修士論文のテーマとしてメインモジュールは図 1 が示すようにプロダクト解析部，プラグイン制御部，メトリクス集計部から構成される. 以下に各部の役割を示す.

• プロダクト解析部

ソースコード解析が行われることが増えてきている．

プロダクト解析部は言語非依存な AST(Abstract

しかし，Java や C++など，実際に社会で広く利用さ

Syntax Tree：抽象構文木) 生成部と AST 解析部，れているプログラミング言語で記述されたソースコー

データ構造構築部に分けられる. 図 2 にプロダクドを解析するのは，多くの学生にとって敷居が高いとト解析部の構成を示す．

言わざるを得ない．そのため，良いアイデア（解析手AST 構築部: 入力として与えられたソースコー

法やメトリクスなど）を思い付いたとしても，それがドをもとに言語非依存な AST を生成する. 図 2

Java

ソース
コード

メインモジュール

解析結果

プロダクト解析部

解析結果
データベース
必要な
解析結果

解析終了

ソースコードclass SampleClass extends SuperClass{public void sample(String arg) {System.out.println( arg );C#}class SampleClass : SuperClass {}public void sample(String arg){
Console.WriteLine( arg );VB}Class SampleClass Inherits SuperClass}
Public Sub Sample(arg as String)
Console.WriteLine( arg )End Sub
End Class

ソフトウェアプロダクト

解析結果取得用API
言語非依存なAST
プロダクト解析部

プラグイン３

プラグイン２

プラグイン１

ふぇ
プラグイン制御部

CLASS_DEFINITION
NAME
SampleClassINHERITANCE
SuperClass
CLASSBLOCK_STARTMETHOD_DEFINITIONMODIFIERS
publicRETURN_TYPE
void
NAME
samplePARAMETERS
METHOD_PARAMETER_DEFINITION
TYPE
String
NAME
arg
BLOCK_START
EXPRESSIONMETHOD_CALL
CALLED_METHOD_NAME
ARG_LIST
EXPRESSION
arg

AST構築部

・・・
AST

プラグイン
実行終了

AST解析部

メトリクス値格納用API
AST
解析
データ

メトリクス値

メトリクス値

メトリクス集計部

メトリクス値
データベース

データ構造構築部

全メトリクス
値

解析
結果

データの流れメトリクス計測結果

処理の流れ

図 2 プロダクト解析部の構成

図 1 MASU の構成図

言語共通要素解析器に示されてある 3 つのソースコードは意味的には同じであるが，異なるプログラミング言語（Java，

AST解析部

クラス情報解析器
メソッド情報解析器

C#，Visual Basic）で記述されているため，構

変数情報解析器
言語共通要素解析器群

・・・

文的には異なっている. たとえば，3 つの言語ではクラスの継承関係の定義の方法が異なっている.

Java特有要素解析器

また，Visual Basic は引数の型の定義の仕方や言語特有要素解析器群

アノテーション情報解析器

・・・

ブロックの開始・終了要素の記述方法が Java やC#とは異なっている. AST 構築部ではこのような各言語間の構文的な違いを吸収し，図 2 の左部

プロパティ情報解析器

構築中データ管理部

AST 解析部: AST を解析し言語非依存な共通データを構築する. ここで言語非依存な共通デー

・・・に示してあるような共通の AST に変換する.

C#特有要素解析器

連携

図 3 AST 解析部の構成

タとは複数の言語で一般的に利用されるようなソ
フトウェアの要素に対するデータを意味する．具

みを解析する．具体的には，変数情報解析器や識体的には，ファイルやクラス，メソッド，フィー

別子情報解析器と連携し，メソッドの引数やメソッ

ルド，制御フロー，名前空間，型などがある．

ド名などの情報を解析する．また，構築中データ

図 3 に AST 解析部の構成を示す．AST 解析部

管理部から構築中のクラス情報を取得し，解析対は複数の解析器と構築中データ管理部で構成され象のメソッドを宣言しているクラスとの所有関係

る．解析器はソフトウェアを構成するそれぞれのを解析する．

要素に対して 1 つずつ用意され，構築中データ管

異なる言語間で共通している要素の構文的な違い

理部や他の解析器と連携しながら対応する要素のは AST 構築部で吸収されるため，共通要素に対情報を解析する．

する解析器は言語が異なっても正常に動作する．

例えば，メソッド情報解析器はメソッドの情報のデータ構造構築部: AST 解析部で抽出した各要素

MASU提供部

AbstractPlugin・・・・・・・
メインモジュールと協調するためのメソッド群

作成された Plugin クラスはアーカイブ化して専用の plugins フォルダに配置すればメインモジュールが自動的にプラグインを認識し，プラグイン制御部で使用可能になる．

AbstractClassMetricPlugin

AbstractMethodMetricPlugin・・・・・・・

measureMethodMetricメソッド・・・・・・・

measureClassMetricメソッド

3.3 特

徴

3.3.1 ビジネスロジックの分離
メインモジュールは，メトリクス計測のためのデータ構造を提供し，個々のメトリクス値を計算するためのビジネスロジックはプラグインとして記述される.

ユーザ記述部(Plugin実装)
CBOPlugin

CyclomaticPlugin・・・・・・・・・・・・・・

measureClassMetricメソッド（ビジネスロジックを実装）

measureMethodMetricメソッド（ビジネスロジックを実装）
登録（アーカイブファイル
をファルダ内に配置）

CyclomaticPlugin.jar

図4も，プラグインのみを作成するだけでよく，ツール作
成のコストを大幅に削減することが可能となる.

Pluginsフォルダ
CBOPlugin.jar

このように，メインモジュールとプラグインを分離することにより，新しいメトリクスを計測する場合でOtherMetricPlugin.jar

プラグインの概略

3.3.2 高い拡張性
MASU のメインモジュールの設計の特徴として高い拡張性があげられる.
複数の言語間にはファイルやクラスのような共通しの関係を解析し，データ構造を構築する．例えば，た要素も多いが，そうでない要素も存在する. たと「メソッド間の呼び出し関係」や「変数宣言情報

えば，C#には JAVA には存在しない”プロパティ”ととその参照情報」などの要素間の情報を構築する.

呼ばれる要素が存在する. また，同じ言語でもその• プラグイン制御部

バージョンが異なれば，ソフトウェアを構成する要素

登録されているプラグイン群を自動的，あるいはが異なることがある. たとえば，JAVA1.5 以降にはユーザの操作によって実行する.

JAVA1.4 までには存在しなかった”generics”という要• メトリクス集計部
各プラグインによって計測されたメトリクス値を集計しファイルに出力する.

素が存在する．このような言語やバージョンに依存した情報もメトリクスの計測には必要な場合が多い.

MASU の AST 解析部はソフトウェアの構成要素ご3.2.2 プラグインとに解析器をもつため，図 3 に示すように言語依存

各プラグインは基本的に，1 つのメトリクスを計測な要素に対応した解析器を切り替えるだけで各言語特するように実装される．個々のプラグインはメインモ

有の要素に対応できる．例えば，C#を解析する際は，ジュールが提供する解析結果取得用 API を用いて，メ

言語共通要素解析器とは別にプロパティ情報解析器をインモジュールが構築したデータを取得する．そして，登録すれば，C#特有の要素であるプロパティの情報

計測対象要素のメトリクスを計測し，メトリクス値格を解析することができる．

納用 API を用いて計測結果を登録する．

より深い解析を行うために解析する要素を増やした

各プラグインの作成手順を図 4 に示す． MASU は

い場合は，その要素に対応した解析器を作成，登録す

メインモジュールと協調するための API を持った抽象るだけでよく，既存のコードを変更する必要はない．

クラスを提供する．ユーザはメトリクスの計測対象と不要な要素の解析を行いたくないときは，その要素なる要素に対応した抽象クラスのサブクラスを実装すに対応した解析器を無効にすればよい．例えば，CKればよい．現在，MASU がメトリクス計測対象としてメトリクスの計測には，制御フローの情報は必要ない

いる要素はファイル，クラス，メソッド，フィールドでため，制御フロー情報解析器を無効にすれば，ソースある．例えば，CK メトリクスを計測する場合は計測

コード解析のパフォーマンスが向上する．

対象となる要素はクラスであるので，AbstractClass-3.3.3 セキュリティの安全性

MetricPlugin クラスのサブクラスを実装する．基本的MASU はアクセス制御をスレッド単位で動的に行にはメトリクス計測用のメソッド (measureClassMet-

うセキュリティマネージャを提供する．具体的には，

ric メソッドなど) にビジネスロジックを記述し，必要次の処理を行う．

に応じてメインモジュールと協調するためのメソッド• 各スレッドの権限の動的な変更．

をオーバーライドすればよい．

• 他のスレッドに勝手に譲渡されないスレッド単位

での動的な権限管理．

として，CK メトリクスとサイクロマチック数を計測• メインモジュール・GUI・プラグインに共通して許可されるグローバルな権限の動的な管理．

• 各プラグインのファイルシステムへのアクセス
制御．

するプラグインを実装した．

4.1 プラグインの規模
各メトリクス計測プラグインの規模と実装に要した
時間を表 2 に示す．いずれのプラグインも実装は 1 人

簡単に述べると，MASU はメインモジュールが構で行われた．表の列「メトリクス」は計測されるメト

築したデータ構造をユーザ (プラグイン側) が勝手にリクス名を，「総行数」は実装されたプラグインの総行変更できないよう管理している．

数 (カッコ内は空白・コメント込みの総行数) を，「BL

3.4 言語依存要素と非依存要素

行数」はビジネスロジックの行数を，「時間」は実装にMASU の AST 解析部が高い拡張性を提供したとし要したおおよその時間を示す．また，WMC は全てのても，言語非依存要素の実装にかかるコストが高すぎメソッドの複雑度が一律であると仮定して実装した．

るようであれば，言語非依存 AST および共通要素解

4.2 プラグイン実装例

析器の効果は低くなる．そこで，我々は共通要素解析

MASU のプラグイン実装の例として，CK メトリ器の有効性を示すために，オブジェクト指向言語共通

クスの 1 つである RFC と WMC を計測するためのの要素を解析するコードと JAVA 特有の要素を解析す

プラグインの例を示す．

るコードの実装に必要としたコストを，クラス数を用

RFC 計測プラグイン RFC を計測するには，各クラ

いて定量的に評価した. 各要素に対する「解析器に必スに定義されているメソッドと，それらのメソッ要としたクラス数」と「要素の情報を保存するためにドの中で呼び出されているメソッドの情報を抽出必要としたクラス数」，「その他の処理に必要としたク

しなければならず，高いコストを必要とする．しラス数」を表 1 に示す. 表 1 より，少なくとも JAVA

かし，MASU のプラグインとして実装すること特有要素の解析にかかる実装はオブジェクト指向言語

により，表 2 や図 5 に示す程度のソースコードで共通要素の解析にかかるコストに比べ非常に小さく，実装することができる．図 5 からわかるように，

共通要素解析器の効果は高いと言える.

メインモジュールと協調するための API はほと

また，MASU の AST 解析部は言語特有の要素を，んど 1 行で実装することができ，プラグイン作成

意味的に同じであれば言語共通要素としてみなし，共に必要なコストは実質的にはビジネスロジックを通要素解析器を用いて解析する. 例えば，C#のプロ記述するメソッドの実装のみである．ビジネスロ

パティは意味的にはアクセサメソッドと等しいため，

ジックの記述もメインモジュールが提供する情報

MASU ではメソッドとして扱うことを考えている. こを利用することにより，低コストで実装すること

れにより，オブジェクト指向言語共通の概念に対してができる．

定義されたメトリクス全般を計測することを可能とす

WMC 計測プラグイン クラスに定義されているメる. 言語特有の要素に関するメトリクスを計測したい

ソッドの複雑度がすべて等しいと仮定すると，という要求も考えられるが，既存のメトリクスの多く

WMC 計測プラグインは図 6 の WmcPlugin ク

はオブジェクト指向言語共通の概念に対して定義されラスのように，非常に低コストで実装することがいる. MASU の目的は共通の概念に対して定義されできる．MASU を利用しない場合でも，クラス

たメトリクスを，異なる言語で記述された複数のソフのメソッド数を計算するだけでよいためそれほど

トウェアから統一的に計測することであるため，特定高いコストは必要としない．

の言語のためのメトリクスは計測対象としない.

しかし，WMC は，各メソッドの重み計算については定義していないが，各メソッドが一律の重み

4. MASU を用いたプラグイン実装
MASU を用いたメトリクス計測プラグインの試作
表1

オブジェクト指向言語共通要素と JAVA 特有要素の実装に要したコスト (クラス数)
対象要素

解析器

情報保存

その他

オブジェクト指向共通要素
JAVA 特有要素

118
12

157
2

19
5

表2

試作プラグインの規模と要した時間

メトリクス

WMC
DIT
NOC
CBO
RFC
LCOM
サイクロマチック数

総行数
31(74)
35(81)
36(73)
61(121)56(117)114(221)52(115)

BL 行数
2
8
1
29
7
48
21

時間 (分)

10
20
10
20
15
40
25

public class RfcPlugin extends AbstractClassMetricPlugin {@Override
protected Number measureClassMetric(TargetClassInfo targetClass) {// この数が RFC
final Set<MethodInfo> rfcMethods = new HashSet<MethodInfo>();// 現在のクラスで定義されているメソッド
final Set<TargetMethodInfo> localMethods = targetClass.getDefinedMethods();
rfcMethods.addAll(localMethods);// localMethods で呼ばれているメソッド
for (final TargetMethodInfo m : localMethods) {rfcMethods.addAll(m.getCallees());}}

return new Integer(rfcMethods.size());

ビジネスロジックを実装@Override
protected String getDescription() {return “Measuring the RFC metric.”; // プラグインの簡易説明}

public class WmcPlugin extends AbstractClassMetricPlugin {@Override
protected Number measureClassMetric(TargetClassInfo targetClass) {final Set<MethodInfo> wmcMethods = targetClass.getDefinedMethods();
return new Integer(wmcMethods.size());}

ビジネスロジックを実装@Override・・・・・・・・・・・・・・・・・省略・・・・・・・・・・・・・・・・・・
メインモジュールと協調するためのAPIをオーバーライド}
public class CustomWmcPlugin extends WmcPlugin {@Override
protected Number measureClassMetric(TargetClassInfo targetClass) {int wmc = 0; // この変数に各メソッドの重みを加算@Override
protected String getDetailDescription() {return DETAIL_DESCRIPTION; // プラグインの詳細説明}@Override
protected String getMetricName() {return “RFC”; // メトリクス名}}}// 各メソッドの重みを計算
for ( TargetMethodInfo wmcMethod : targetClass.getDefinedMethods() ) {int weight;
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 省略 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
wmc += weight;}
return wmc;
TargetMethodInfoの情報を利用して各メソッドの重みを自由に決定@Override
protected boolean useMethodInfo() {return true; // このプラグインがメソッドに関する情報を利用するかどうか}@Override
protected boolean useMethodLocalInfo() {return true; // このプラグインがメソッド内部の情報を利用するかどうか}}

static {DETAIL_DESCRIPTION = “ プラグイン詳細説明”;}

メインモジュールと協調するためのAPIをオーバーライド

図6

WMC 計測プラグイン実装例

5. 関 連 研 究
5.1 バイトコード解析ツール
バイトコード解析ツールとしては，以下の 2 つが有名である．

Soot: a java Optimization Framework9)
図 5 RFC 計測プラグイン実装例

McGill大学のプロジェクトとして開発されている Java
バイトコードを開発者の定義どおりに最適化するを持つとして計測されることは少ない．メソッド

ためのフレームワーク. Soot は最適化のための情の複雑度を示すメトリクスとしてサイクロマチッ

報としてバイトコード解析情報を提供するため，

ク数などが有名であるが，厳密な定義が存在しなプログラム解析ツールとしても使用されている．

い以上，ユーザーによって要求するメトリクスは異なるであろうし，さまざまなメトリクスを用い

WALA10)

IBM Research が開発したオープンソー

スの Java バイトコード解析ライブラリ．

て計測結果を比較したいという要求も考えられる．

バイトコードから得られる情報はソフトウェアの潜このような場合，要求されるメトリクスそれぞれ

在的な情報を多く含むが，制御文の種類などのようにに対応した計測ツールを作成することは容易ではソースコードからでなければ得られない情報も多く存ない．しかし，MASU の解析情報を利用すれば図在する. また，バイトコードはコンパイラが生成した

6 の CustomWmcPlugin クラスに示してあるよ

コードであり，人間が保守しなければないらないのは

うに，ユーザー独自のメソッド複雑度計測ロジッ

ソースコードである．そして，メトリクスが示すのは，

クを自由に記述することができる．

人間が作成したプロダクトの品質評価や，人間が行う保守のコスト予測などに使われる尺度である．ゆえに，例が示すように，MASU を利用することにより，ユーメトリクスの計測は，バイトコードの特徴ではなく，

ザーは低コストかつ自由にメトリクス計測ツールを実

ソースコードの特徴を測ることに意味があるといえる．

装することが可能となる．

また，Soot や WALA は Java のバイトコードのみを対象としており，多言語対応はされていない.

5.2 MOOSE
Ducasse らは言語非依存のリエンジニアリングプ

ラットフォームとして MOOSE を開発している3) ．

の 3 つを検討している．

MOOSE は MASU と同様にソースコードを入力とEclipse プラグインに関しては，既に開発に着手ししたソフトウェアメトリクスの評価機能を提供する．

ており，メトリクス計測用のインターフェースだけでしかし，MOOSE はソースコードを直接解析するわ

なく，Eclipse における MASU プラグイン開発プロ

けではなく，CDIF や XMI などに変換された情報をジェクト作成インターフェースの実装も検討している．

解析するため，提供される情報はモデルベースの情報となる．モデルベースの情報はソフトウェアの視覚化などには有用であるが，ソースコードから直接得られる情報と比較すると情報量が減少する．

7. ま と め
本稿では，メトリクス計測用プラグインプラット
フォーム MASU について述べた．MASU は以下の特

また，ソースコードから CDIF や XMI への変換

徴を持っており，MASU を用いることによって，従部はサードパーティーのツールに依存しているため，

来に比べてはるかに低いコストでソースコードからメ

MASU が提供するような拡張・変更容易性は備えてトリクスを計測することが可能になる．

いない．

6. 現状と今後
6.1 入力ソフトウェアプロダクトの拡大• 複数のプログラミング言語のソースコードに対して適用可能である．

• 多言語の解析から得た結果を統一的に扱える．
• 言語依存な要素にも対応するため，解析対象ソフ

MASU の開発はまだ初期段階であり，ソースコー

トウェアの構成要素の追加や変更を柔軟に行える．

ドの解析部は現在は Java 用の実装が用意されている• 必要最低限のビジネスロジックを記述するだけで，のみである．今後，C++,C#などのほかのオブジェク
ト指向言語に順次対応していく予定である．
また，解析対象をソースコード以外に広げることも考えている．例えば，実行履歴を解析して共通データを構築するような解析部を作成することで，動的なデータを基にしたメトリクス計測が可能になる．

6.2 解析部のプラグイン化
現在，MASU の解析部は拡張性の高い設計を適用することにより，解析する言語非依存な共通データを拡張しやすく，また，言語依存なデータの解析にも柔軟に対応できる．しかし，解析部はメインモジュールの一部として設計されているため，ユーザが独自に解析部を改良し，データ構造の構築の方法を変更したり，
対応言語を拡張することは難しい．
そこで解析部をプラグイン化することにより，ユーザーが独自にさまざまなソフトウェア要素に対するメ
トリクスに対応したり，データ構造を自由に構築することができるようにし，多様な入力データに柔軟に対応できるようにすることも検討していきたいと考えている．具体的には，図 3 に示してある個別要素ごとの情報解析器をプラグイン化する予定である．

6.3 GUI の作成
メインモジュールとプラグインの他に GUI を用いたユーザーインターフェースモジュールを作成することを考えている．現在のところ，Swing を用いたスタ
ンドアロンアプリケーション用のインターフェース，

SWT を用いた Eclipse プラグイン用のインターフェース，GWT を用いた Web ベースのインターフェース

新たなメトリクスを計測可能である．

MASU の開発はまだ初期段階であり，他言語への対応や GUI などは十分ではない．今後さまざまな拡張を行う予定である．

参

考

文

献

1) JavaCC. http://javacc.dev.java.net/.
2) ANTLR. http://www.antlr.org/.
3) A. L. Baroni and F. B. Abreu. An OCL-Based
Formalization of the MOOSE Metric Suite. In
Proc. of the 7th ECOOP Workshop on Quantitative Approaches in Object-Orietend Software
Engineering, 2003.
4) S. Chidamber and C. Kemerer. A Metric Suite
for Object-Oriented Design. IEEE Transactions on Software Engineering, 25(5):476–493,
Jun 1994.
5) Eclipse Metrics Plugin. http://www.teaminabox.
co.uk/.
6) M. H. Halstead. Elements of Software Science.
Elsevier Science Inc., 1977.
7) T. McCabe.
A Complexity Measure.
IEEE Transactions on Software Engineering,2(4):308–320, Dec 1976.
8) P. Oman and S. L. Pleeger. Applying Software
Metrics. IEEE Computer Society Press, 1997.
9) Soot: a Java Optimization Framework. http://www.sable.mcgill.ca/soot/.
10) WALA.
http://wala.sourceforge.net/
wiki/index.php/Main Page.