論 文
多言語対応メトリックス計測プラグイン開発基盤 MASU の開発
三宅 達也†

肥後 芳樹†

楠本 真二†

井上 克郎†

MASU: A Metrics Measurement Framework for Multiple Programing Languages
Tatsuya MIYAKE† , Yoshiki HIGO† , Shinji KUSUMOTO† , and Katsuro INOUE†

あらまし 筆者らは複数の言語に対して適用可能なメトリックス計測プラグインの開発基盤 MASU を開発している．MASU はソースコードを解析し，メトリックス計測に必要な情報をユーザに提供する．また，計測する
メトリックスに応じたソースコード解析や新規メトリックスへの対応を容易にするため，MASU はソースコー
ドから抽出する情報を柔軟に変更・追加できるように設計されている．ユーザは MASU が提供する情報を利用することにより，必要最低限のメトリックス計測ロジックを記述するだけでメトリックスを計測できる．本論文では MASU の詳細について述べる．
キーワード

ソフトウェアメトリックス，メトリックス計測ツール，ソースコード解析

また，メトリックスを計測するツールの多くは単一

1. ま え が き

言語を対象としているため [3], [7], [16], [18], [28]，様々ソフトウェアメトリックスとは，ソフトウェアの品な言語のソースコードのメトリックスを計測するには，質評価に用いられる尺度であり [25]，ソースコードなそれぞれの言語に対応した計測ツールを個別に用意すどのソフトウェアプロダクトから計測される．ソフト

る必要がある．しかし，ツールごとに対応しているメ

ウェアメトリックスには単純にソースコードの行数をトリックスの種類は異なる．また，同一のメトリック

表す LOC から，オブジェクト指向言語におけるクラスに対応している計測ツールであっても定義のあいまスやメソッド，フィールド間の関連性を評価する CK

いな部分の解釈はツールごとに異なる．このため，複メトリックス [6]，関数やメソッド内の処理の複雑さを数の言語から統一的にメトリックス値を計測すること表すサイクロマチック数 [23] などの様々な種類が存在は難しい．

する．これらのメトリックスはソフトウェアの概念的な要素に対して定義されているため，プログラミング
言語間の記述様式の差異にとらわれることなく，同じ概念を共有する言語に共通して適用することができる．

これらのことを踏まえると，以下の特徴をもつメト
リックス計測ツールが必要であるといえる．

•

複数のプログラミング言語のソースコードに対して適用可能である．

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

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

コードを解析しソフトウェアの概念的な要素の情報を•ユーザは，必要最低限のメトリックス計測ロ

取得するには大きなコストを必要とする．これまでにジックを記述するだけで，新たなメトリックスを計測

種々のコンパイラコンパイラ [1], [17] が開発されていできる．

るが，それらが支援しているのは抽象構文木構築など

本論文では，これらの要求を満たすべく我々が開の構文解析までであり，変数の参照・代入や関数の呼発 し て い る メ ト リック ス 計 測 プ ラ グ イ ン 開 発 基 盤

出しなど，どのようにプログラム内の要素が関連してMASU [22] を紹介する．

いるかを調査するためには，開発者自らが意味解析を行う処理を実装しなければならない．
†

2. 背

景

2. 1 ソフトウェアメトリックス
大阪大学大学院情報科学研究科，豊中市
Graduate School of Information and Science Technology,
Osaka University, Toyonaka-shi, 560–8531 Japan1518

電子情報通信学会論文誌

ソフトウェアメトリックスとは，ソフトウェアの品
質評価や工数・保守コスト予測などに用いられる尺c （社）電子情報通信学会 2009
D Vol. J92–D No. 9 pp. 1518–1531 

論文／多言語対応メトリックス計測プラグイン開発基盤 MASU の開発度である [25]．代表的なソフトウェアメトリックスにし，既存のツールを用いて，異なる言語で記述されたは，オブジェクト指向言語におけるクラスやメソッド，

複数のソフトウェアから統一的にメトリックス値を計

フィールド間の関連性からソフトウェアの複雑度を評測することは難しい．これは次の問題に起因する．

価する CK メトリックス [6]，関数やメソッド内の処(a) ソースコード解析器は言語ごとに用意する必理の複雑さを表すサイクロマチック数 [23] などが存在

要があるが，ソースコード解析器の実装は高いコストする．

を必要とするため，既存のメトリックス計測ツールの多くのソフトウェアメトリックスは，CK メトリッ

多くは単一の言語を対象としている．

クスやサイクロマチック数のようにファイルやクラス，(b) 問題 (a) のため，異なる言語で記述された複メソッド，関数，制御フローといったソフトウェアの数のソフトウェアのメトリックス計測を行うには，そ

概念的な要素に対して定義されるものであるため，プれぞれの言語に対応した複数のメトリックス計測ツー

ログラミング言語間の記述様式の差異にとらわれる

ルを用意する必要がある．しかし，ソフトウェアメト

ことなく，同じ概念を共有する言語に共通して適用でリックスの定義はあいまいなものが多いため，既存のきる．

メトリックス計測ツールは，同一のメトリックスであっソフトウェアメトリックスの多くは厳密な定義がさてもツールごとに計測結果が大きく異なる [19]．

れていない．例えば，CK メトリックスの一つである

また，メトリックスごとに，計測に必要とするソー

WMC はクラス当りの重み付きメソッド数を表すが，スコードの情報は異なるため，新規メトリックスの計

メソッドの重みに関する厳密な定義は存在しない．こ測において既存のツールのソースコード解析を再利用のような，ソフトウェアメトリックスの定義のあいますることは難しい．

いさはメトリックス値の計測結果に大きな影響を及
ぼす．
また，既存のソフトウェアメトリックスが必ずしもこのように，メトリックス計測において発生する問
題は，ソースコード解析に対する支援不足が大きな原因の一つとなっている．

最善であるとは限らない．このため，既存のメトリック

2. 3 ソースコード解析

スの改善案が提案されたり，同じ目的で使用される新ソースコード解析とは，ソースコードを解析器と呼規メトリックスが提案されることもある．例えば，CK

ばれるプログラムを用いて，自動で必要な情報を抽出

メトリックスの一つである LCOM は Chidamer とする技術である．抽出された情報は，ソフトウェアメ

Kemerer による定義では，メソッドの凝集の欠如を正トリックスやその組織独自の方法を用いて調査され，確に表せない場合があることが知られており，異なる定ソフトウェアの品質を評価するためなどに用いられる．

義をもつ LCOM もいくつか提案されている [13], [14]．

しかし，ソースコードを解析し，その情報からメト2. 2 ソフトウェアメトリックス計測

リックスなどを算出するには，例えば，関数間の呼出ソースコードを対象としたメトリックス計測は基本

し関係などの，意味解析以上の深い解析をしなければ的に次の 2 ステップに分けることができる．

得ることのできない情報を必要とするため，解析器自［ソースコード解析］ メトリックス値の計測に必要な体を作成することに高いコストが必要である．既に，情報をソースコードから抽出．

JavaCC [17] や ANTLR [1] などに代表される多くの［メトリックス値計測］ ソースコードから抽出した情コンパイラコンパイラが開発されているが，それらが報を利用してメトリックス値を計測．

支援するのは構文解析までであり，それ以上の深い解2. 1 で述べたように，ソフトウェアメトリックスは析を行う場合は，多大な時間と労力を必要とする．

プログラミング言語間の記述様式の差異にとらわれる

一方，ソフトウェアのソースコードが調査される機ことなく，同じ概念を共有する言語に共通して適用で会は増加しており，ソースコード解析技術の重要性はきる．このため，メトリックス値計測のロジックは言増している．例えば，ソフトウェア開発企業では，QA語が異なっても共通して利用することができる．一方，(Quality Assurance) のために，開発したソフトウェ

異なる記述様式に対応するためには，各記述様式ごと

アをソフトウェア工学的な手法を用いて調査することにソースコード解析器を用意しなければならない．

が増えてきた．この調査の一環として，ソースコード

既存の研究や開発において様々なメトリックス計測

解析を行い，その品質や今後の保守コストなどを予測ツールが開発されている [3], [7], [16], [18], [28]．しかすることが多い．しかし，近年顕著に見られる開発期
1519

電子情報通信学会論文誌 2009/9 Vol. J92–D No. 9間の短縮化や，対象ソフトウェアによって適用する解［メトリックス計測部とソースコード解析部の分離］

析手法が異なることから，満足に QA が行われている

メトリックス計測部とソースコード解析部を分離してとはいえない．

おくことにより，異なる言語で記述されたソフトウェ

このような問題は，深い解析を行う解析器を実装す

アのメトリックス計測の際にも，メトリックス計測部

るコストが高いことや，そのような解析器を実装できは再利用することができる．これにより，複数言語へる開発者を確保することが困難であることに起因しての対応に必要とするコストの削減が期待できる．まいる [12]．このため，ソフトウェアの品質を評価する

た，メトリックス計測部を再利用することは，言語が技術者は，品質評価を行うためのアルゴリズムの実装異なっても同一のメトリックス計測ロジックを使用すではなく，そのアルゴリズムで用いる情報を抽出するることを意味する．つまり，統一的なメトリックス計

解析器の実装に悩まされたり，若しくは，解析器を必測を実現できる．

要とするソフトウェアの品質評価自体を断念したりし［言語間の差異の吸収］ メトリックス計測ツールの実ている．

装には，メトリックス計測部よりもソースコード解析

3. 要求されるメトリックス計測ツール

部の実装の方が高いコストを必要とする．このため，本章ではソフトウェアメトリックスの特徴や既存のソースコード解析の初期段階に言語間の差異を吸収し，メトリックス計測ツールの問題を考慮した上で，メト

ソースコード解析部も可能な限り再利用することが望

リックス計測ツールに要求されるであろう機能と，そましい．また，メトリックス計測部を再利用ためには，

複数言語への対応に必要とするコストを削減するには，の機能を実装するための設計・実装方針について述

言語非依存な共通データを構築しなければならない．

べる．

［メトリックスとメトリックス計測部の 1 対 1 対応］

3. 1 機 能 要 求

一つのソフトウェアメトリックスにつき，一つのメトメトリックス計測ツールに要求される機能として次リックス計測部が用意されることが望ましい．このよのものが考えられる．

うな設計を適用することにより，計測対象メトリック［複数言語への対応］ 複数言語に対応したツールの供スを追加するする際にも，新たなメトリックス計測部

給不足を解消し，ソフトウェアメトリックスを幅広くを追加するだけでよく，既存のメトリックス計測部を活用するために，複数の言語に適用可能なメトリック

変更する必要はない．また，改善したいメトリックス

ス計測ツールが必要である．

に対応したメトリックス計測部を継承することにより，［統一的なメトリックス計測］ 異なる言語で記述され改善したメトリックスの計測を低コストで実現するこた複数のソフトウェアから同一のメトリックス計測ロとができる．

ジックでメトリックスを計測するために，異なる言語

つまり，計測対象メトリックスとメトリックス計測で記述された複数のソフトウェアの解析結果を統一的

部を 1 対 1 対応にすることにより，ユーザが計測対象に扱えるメトリックス計測ツールが必要である．

メトリックスを自由に追加したり，計測ロジックの定［ユーザがメトリックス計測部の定義を自由に変更可

義を自由に変更したりすることが可能となる．

能］ 将来提案されるであろうソフトウェアメトリック［解析対象要素を変更可能なソースコード解析器］ あスの計測に対応するために，計測するメトリックスをるメトリックスの計測に必要な情報が，必ずしも他のユーザが自由に追加し，その計測ロジックを自由に定メトリックスの計測に必要であるとは限らない．必要

義可能な環境が必要である．ただし，ユーザ参加型のとしない情報の解析は時間やメモリ空間の無駄となる．

システムを構築する際には，システムの安全性を確保

また，新規メトリックスの計測を行いたいが，必要なするために，ユーザに許可する権限を明確にし，ユー

ソースコードの情報が不足しているという状況も考えザの行う処理を管理する必要がある．

られる．

3. 2 設計・実装方針
メトリックス計測ツールに要求される機能を実現するために，次に述べる設計・実装方針が必要であると筆者は考える．

1520

このため，ソースコード解析器には拡張・変更容易
性の高い設計を適用し，解析対象要素を柔軟に追加・変更できるようにすることが望ましい．

論文／多言語対応メトリックス計測プラグイン開発基盤 MASU の開発

4. MASU の仕様

インモジュールは更にソースコード解析部，プラグイ
ン制御部，メトリックス集計部から構成される．

3. 2 で述べた方針に基づき，複数言語の解析結果か

メインモジュールはソースコード解析部でソース

ら統一的にメトリックス計測を行えるプラグインの開

コードの情報を抽出し言語非依存なデータを構築する．

発基盤 MASU (Metrics Assessment plugin platform

次に，メトリックス制御部が指定されたプラグインを

for Software Unit) を開発した [22]．

実行する．計測されたメトリックス値はメトリックス

MASU は Java を用いて実装されており，現在，規模はファイル数は 460，行数は約 99,000 行（ANTLRによる自動生成部分が約 41,000 行）である．オブジェ

集計部で集計され，ユーザに提供される．
プラグインはメインモジュールが構築したデータを用いて個別のメトリックス値を計測する．

クト指向言語のソースコードを入力とし，対象ソース

3. 2 で述べた設計・実装方針は主にソースコード解

コードに含まれるクラスやメソッドなどのメトリック

析部とプラグインに適用されている．以降では，ソー

ス値やソースコード解析結果を出力する．
現在，MASU は解析対象として Java と C#に対応

スコード解析部とプラグインの詳細，及び，MASU が提供するセキュリティマネージャについて説明する．

している．Java に関しては Annotation を除くすべて

4. 1 ソースコード解析部の要素の情報を解析できる．C#に関してはクラスや

ソ ー ス コ ー ド 解 析 部 は AST（Abstract Syntax

メソッドなどのオブジェクト指向言語共通の要素の解

Tree：抽象構文木）構築部と AST 解析部，データ析を行うことができる．ただし，C#に関しても構造

構造構築部に分けられる．図 2 にソースコード解析部

体（クラスと意味的に等しい）やプロパティ（メソッの構成と処理の流れを示す．

ドと意味的に等しい）のような，メトリックス計測の4. 1. 1 AST 構築部

際にオブジェクト指向言語共通の要素とみなす必要が入力として与えられたソースコードをもとに言語非あると考えられる特有要素は解析できる．

依存な AST を生成する．図 2 に示されてある三つのMASU のアーキテクチャを図 1 に示す．本ツール

ソースコードは意味的には同じであるが，異なるプロ

はメインモジュールとプラグインから構成される．メグラミング言語（Java，C#，Visual Basic）で記述されているため，構文的には異なっている．AST 構築部ではこのような各言語間の構文的な差異を吸収し，
図 2 の右部に示してあるような共通の AST に変換す
る．AST 構築時に言語の記述様式の差異が吸収されるため，AST 解析部及びデータ構造構築部の大部分
は様々な言語の解析に共通して利用することができる．
言語非依存な AST 構築の方針を以下に示す．
（方針 1） AST 構築部は一つの大きな AST を構築す
るが，構築された AST は AST 解析部において複数の部分 AST とみなして解析される．例えば，図 3 の左上部の AST(Java) は図下部の部分 AST 集合とみなして解析される（AST(Java) はコンストラクタ定
義を表す）．このため，AST 構築部では AST 全体を
言語非依存にするのではなく，部分 AST が言語非依存になるように構築する．
部分 AST はデータが構築される要素ごとに定義され，構築される要素の内容を示すノード（図 3 の場
合，CTOR DEFINITION，PARAM DEF など）が部分 AST のルートノードとなる．各要素間の所有関図 1 MASU の構成図
Fig. 1 Architecture of MASU.

係は部分 AST のルートノードの位置関係で表される．具体的には，要素 A が要素 B を所有することを
1521

電子情報通信学会論文誌 2009/9 Vol. J92–D No. 9

Fig. 2

図 2 ソースコード解析部の構成
Architecture of source code analysis unit.

これにより，AST 全体の構造は異なっていたとしても，部分 AST が言語非依存であれば同一の AST として解析できる．例えば，図 3 の AST(Java)，AST(C#)
はともにコンストラクタ定義を表すが AST(C#) ではコンストラクタ呼出しを表す部分 CTOR CALL が“{}” を表す BLOCK START ノードの子ノードではない（C#では同一クラスのコンストラクタ呼出しは“{}” の外側に記述されるため AST(C#) のようになる）．しかし，部分 AST は AST(Java)，AST(C#) ともに等しく，部分 AST の頂点ノード間の位置関係も同じであるため，解析時に全体的な構造の差異は影響しない．
また，このように AST を部分 AST の集合とみなして構築することにより，次の利点をもつ．

•

言語非依存な共通 AST を定義し，構築することは容易ではない．しかし，AST 全体の共通化に比図 3 部分 AST 集合の例
Fig. 3 An example of a set of partial ASTs.

べると，部分 AST の共通化は比較的容易に行える．

•

対応言語の追加が容易になる．対応言語を追加する際，AST 全体が共通化されていると，AST 全

inclue(A, B)，要素 A の部分 AST のルートノードをRoot(A)，ノード N1 がノード N2 の祖先ノードであることを Ancestor(N1 , N2 ) で表すとき，次の条件を満たすように AST が構築される．

include(A, B) =⇒ Ancestor(Root(A), Root(B))
1522

体の仕様を理解した上で AST 構築部を実装しなければならない．部分 AST の集合とみなすことにより，各部分 AST ごとの仕様を個別に理解すればよい．部分 AST 間の関係はルートノードの位置関係のみを把握すればよい．例えば，Visual Basic のようにコードブロックの開始を表すトークンがないため，

論文／多言語対応メトリックス計測プラグイン開発基盤 MASU の開発

BLOCK START ノードが AST 上に存在しない場合を述べる．

でも，コンストラクタ定義を表す AST 全体の構造を［共通ノードの定義］ ソースコード上で意味的に等考慮して BLOCK START ノードを追加するという価な予約語に対して共通の AST ノードを定義する．

作業を行う必要はない．

例えば，図 2 の三つのプログラミング言語のソース•

言語特有の情報を AST 上に残すことができる．

コードにおいて，継承関係はそれぞれ “extends”，“:”，

部分 AST 間の関係はルートノードの位置関係のみを“inherits” で記述されているが，AST 上では共通ノー

把握すればよいため，図 3 の AST(C#) のように言ド “INHERITANCE”（AST6 行目）で表す．図 2 の語特有の AST 構造をある程度残すことができる．まAST において，下線付きノードが共通ノードである．

た，部分 AST にはデータ構築に不要なノードは含ま［要素定義ノードの埋込］ AST の各ノードがソースれないため，図 3 の AST(C#) の SPECIFIC ノード

コード上のどの要素に対応するかを示すノードを埋のような言語特有の要素を表すノードを AST 上に残め込むことにより，記述順序の差異を吸収する．例

すことができる．これらの情報は特定の言語に特化しえば，図 2 のソースコードが示すように，Java やた解析には有用である．

C#の変数は先に型を宣言し，後に変数名を宣言する（方針 2） 同一の概念を表す部分 AST が言語間で異が，Visual Basic では先に変数名を宣言する．AST 上なる場合，定義できる情報の量や種類が多い方を基準

では “TYPE”（AST18 行目）や “NAME”（AST20にして AST を定義する．例えば，Java の場合，一つ行目）のようにソースコード上のどの要素に対応すのファイル内で一つの名前空間 (package) しか宣言でるかを示すノードを埋め込むことにより，その子ノー

きないが，C#の場合，複数の名前空間 (namespace)

ドである識別子が何を意味しているのかを特定する．

を定義することが可能であり，名前空間の階層構造も

図 2 の AST において，太字のノードが要素定義ノー定義できる．つまり，C#の AST で Java の名前空間

ドである．

を表すことはできるが，Java の AST で C#の名前空［ノードの移動・削除］ AST のノードの移動や削除間を表すことはできない．このような場合，AST 構を行うことにより，ノード間の関係の差異を吸収する．

築部は C#の AST を基準にして名前空間を表す部分

例えば，通常 Java の AST において名前空間を示す

AST を構築する．

ノードは，その名前空間内のクラスを示すノードと兄（方針 3） 部分 AST の構造は異なるが，定義できる

弟関係をもつが，C#の場合は親子関係をもつ．この情報の量や種類が等しい場合は Java の AST を基準

ような場合，Java のクラスを示す部分木を，その頂点にする．Java は現在存在する様々なプログラミング言

ノードが名前空間を示すノードと親子関係をもつ位置

語の中で開発者の関心が最も高く [27]，また，現在もに移動することにより，ノード間の関係の差異を吸収継続的に言語機能の拡張が行われている．このため，する．

Java の解析に関する拡張や変更を他の言語よりも行

4. 1. 2 AST 解析部

いやすくしている．

AST を解析し言語非依存な共通データを構築する．

（方針 4） 言語特有の概念は，その言語の AST を基

図 4 が示すように，AST 解析部は複数の解析器と準として部分 AST を構築する．意味的に等しいオブ

構築中データ管理部で構成される．解析器はソフト

ジェクト指向共通の要素が存在する場合でも，共通のウェアを構成するそれぞれの要素に対して一つずつ用要素を表す部分 AST を構築することによる意味的な意される．各解析器は 4. 1. 1 で説明した部分 AST 一

差異の吸収は行わない．これは AST 構築時に言語特つを入力とし，部分 AST に対応する要素の情報のみ有の概念を表す部分 AST をオブジェクト指向共通のを解析する．

要素を表す部分 AST に変換すると，特定の言語に特化した解析が困難になるためである．言語特有の概念

各要素間の関係は，構築中データ管理部を通して，他の解析器と連携しながら解析する．

をオブジェクト指向共通の要素とみなして，メトリッ

例えば，メソッド情報解析器はメソッドの情報のみ

クスを計測する場合は，AST 解析部で言語非依存なを解析する．具体的には，変数情報解析器や識別子情

共通データを構築する際に意味的な差異を吸収する．

報解析器と連携し，メソッドの引数やメソッド名など

上記の方針に基づいて言語非依存な部分 AST を構の情報を抽出する．また，構築中データ管理部から構築する際，言語差異を吸収のために行う処理の具体例

築中のクラス情報を取得し，解析対象のメソッドを宣1523

電子情報通信学会論文誌 2009/9 Vol. J92–D No. 9はオブジェクト指向言語共通の概念に対して定義される．また，MASU の目的は共通の概念に対して定義されたメトリックスを，異なる言語で記述された複数のソフトウェアから統一的に計測することであるため，特有要素を特有要素として解析する解析器は現在未実
装である．

4. 1. 3 データ構造構築部
AST 解析部で解析した情報をもとに，言語非依存な
共通データを構築する．ここで言語非依存な共通デー
タとは複数の言語で一般的に利用されるようなソフト
ウェアの要素に対するデータを意味する．
図 4 AST 解析部の構成
Fig. 4 Architecture of AST analysis unit.

MASU が計測対象としているメトリックスは，ソー
スコードに記述されるソフトウェアの要素に対して定義され，その計測にソースコードに記述される様々な言しているクラスとの所有関係を解析する．

要素の情報を必要とする．このようなメトリックスの異なる言語間で共通している要素の構文的な違いは計測に関して広く有効なデータを提供するには，ソーAST 構築部で吸収されるため，共通要素に対する解

スコードに記述される要素に関する情報の粒度が細か析器は言語が異なっても正常に動作する．これにより，く，精度が高いほど望ましい．データ構造構築部で構多言語対応に必要とするコストを大幅に削減すること築されるデータが提供する情報の粒度や精度は基本的ができる．
また，AST 解析部を複数の解析器で構成すること
により，次のような解析を実現できる．

に次の方針で決定されている．
［粒度］ プログラム言語の文法は EBNF 記法などを用いて，プログラムの要素ごとに生成規則が厳密に定［計測するメトリックスに応じたソースコード解析］

義されている．MASU はプログラミング言語の文法

AST 解析部に登録する解析器を変更することにより，に生成規則が定義されている要素ごとにデータを構築

容易に解析対象要素の変更が行える．より深い解析をする．ただし，構築されるデータにはファイルなどの行うために解析する要素を追加する場合は，その要素ようにプログラムの文法上に現れない要素も一部存在に対応した解析器を作成，登録するだけでよく，既存する．

のコードを変更する必要はない．不要な要素の解析を［精度］ 生成規則から得られる情報と等価な情報を得行いたくないときは，その要素に対応した解析器をられるデータを構築する．要素の使用（変数参照やメ

無効にすればよい．例えば，CK メトリックスの計測

ソッド呼出しなど）を表す識別子に関しては，生成規には，制御フローの情報は必要ないため，制御フロー

則上では文字列情報しか得られないが，意味解析を行

情報解析器を無効にすれば，ソースコード解析のパ

うことにより，要素の使用を表すデータ（要素の定義

フォーマンスが向上する．

を表すデータと依存関係をもつ）を構築する．

［言語特有要素の解析］ AST 解析部は言語特有の要

ソースコードにはプログラミング言語の文法に定義

素を，図 4 のように言語特有要素解析器を用いて，意されている内容以外は記述できない（コードコメント

味的に等価な言語共通要素とみなして AST を解析すなど一部の例外は存在する）．このため，上記のようにる．例えば，C#のプロパティは意味的にはアクセサ

文法に定義されている要素ごとにデータを構築するこメソッドと等しいため，MASU のプロパティ解析器はとにより，精度の高い情報を細かい粒度でソースコー

プロパティの AST を解析し，意味的に等価なメソッドから取得することができる．

ドの情報を構築する．これにより，意味的には等しいが異なる要素の情報を統一的に扱える．

また，言語拡張が行われたときメトリックス計測に必要な情報が増えたり，新しく追加された要素に対し特定の言語に特化した解析を行う必要がある場合は，てメトリックスが定義される可能性がある．多くの場特有要素を特有要素として解析する解析器を登録する

合，言語拡張は既存の生成規則を変更することなく，ことにより実現できる．しかし，メトリックスの多く

生成規則を追加することによって実現される．このた

1524

論文／多言語対応メトリックス計測プラグイン開発基盤 MASU の開発

め，上記の方針に従うことにより，既存の実装をそのリックス計測用のメソッド（measureClassMetric メ

まま利用し，追加された生成規則に対する実装のみをソッドなど）にメトリックス計測ロジックを記述し，必追加することにより，言語拡張に対応できる．

要に応じてメインモジュールと協調するためのメソッ

上記の方針でデータを構築する際，複数のプログラ

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

ミング言語の文法に共通して定義されている要素（ク

作成された Plugin クラスはアーカイブ化して専用

ラス，メソッド，文，式など）の情報を，言語非依存の plugins フォルダに配置すればメインモジュールがな共通データとして提供する．

自動的にプラグインを認識し，プラグイン制御部で使4. 2 プラグイン
メインモジュールは，メトリックス計測のための用可能になる．

4. 3 セキュリティ

データ構造を提供し，個々のメトリックス値を計算す

メインモジュールが提供するデータは複数のプラグるためのメトリックス計測ロジックはプラグインとしインで共有される．このため，プラグインが実行するて記述される．これにより，ソースコード解析部とメ処理によりメインモジュールが提供するデータが不正

トリックス計測部が分離される．

に変更されると，後に実行されるプラグインによって各プラグインは基本的に，一つのメトリックスを計測するように実装される．個々のプラグインはメイン計測されるメトリックスを正しく計測できなくなるおそれがある．

モジュールが提供する解析結果取得用 API を用いて，このような問題を回避するため，MASU はそれぞ

メインモジュールが構築したデータを取得する．そしれのプラグインを異なるスレッドで実行し，メインモて，計測対象要素のメトリックスを計測し，メトリッ

ジュールが提供するデータや各プラグインのデータへ

クス値格納用 API を用いて計測結果を登録する．

のアクセス制御をスレッド単位で動的に行うセキュリ

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

ティマネージャを提供する．セキュリティマネージャはメインモジュールと協調するための API をもった抽象

メインモジュールが構築したデータ構造をユーザ（プクラスを提供する．ユーザはメトリックスの計測対象

ラグイン側）が勝手に変更できないよう管理している．

となる要素に対応した抽象クラスのサブクラスを実装

また，あるプラグインが他のプラグインの情報を不正すればよい．現在，MASU がメトリックス計測対象とに変更できないようにしている．具体的には，次の処している要素はファイル，クラス，メソッド，フィー

理を行う．

•

ルドである．
例えば，CK メトリックスを計測する場合は計測対象となる要素はクラスであるので，AbstractClass-

MetricPlugin クラスのサブクラスを実装する．メト

各プラグインの実行時のみ，実行中のプラグイ

ンスレッドに許可される権限の管理．

•

他のプラグインスレッドに不正に譲渡されない

スレッド単位での権限管理．

•

メインモジュール，プラグイン，GUI に共通して許可される権限の管理．

•

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

制御．

5. 評

価

5. 1 設計・実装方針の効果
MASU は 4. 1 で述べた設計・実装を行うことにより，多言語対応に必要とするコストを削減している．

MASU の設計・実装の有効性を評価するために，筆者が多言語対応の実装を行う際に必要とした開発労力を評価した．実装は筆者が大学院在籍（博士前期課程）時に行った．実装当時の筆者のプログラミング経験はFig. 5図 5 プラグイン作成の概略
Outline of plug-in development.

2.5 年間であり，MASU の開発参加期間は 0.5 年である．また，AST を構築する際に必要となる構文解析1525

電子情報通信学会論文誌 2009/9 Vol. J92–D No. 9

器は ANTLR を用いて生成した．ANTLR は入力となる構文定義ファイルに基づいて，構文解析器を自動生成するツールである．ANTLR の構文定義ファイル
は既存のもの [1] を利用した．

5. 1. 1 言語非依存 AST 及び共通要素解析器の有効性評価
言語非依存の AST を構築し，共通要素解析器を再表1

オブジェクト指向言語共通要素と Java 特有要素の解析に要した開発労力（クラス数）
Table 1 The number of classes that were implemented for analyzing common elements of
Object-Oriented Language and unique elements of Java.
対象要素

解析器

情報保存

その他

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

118
15

157
5

19
7

利用可能にしたとしても，言語非依存の AST の実装に必要とする開発労力が大きすぎるようであれば，言語非依存 AST 及び共通要素解析器の効果は低くなる．

効性は高いといえる．

5. 1. 3 考察

そこで，我々は C#のソースコードから言語非依存

Java と C#のオブジェクト指向共通要素に関する言

AST を構築し，言語共通要素を解析する機能を実装す

語間の比較と，言語間の差異を吸収するために必要とるために必要としたコストを計測した．共通要素解析した労力に関して考察する．同時に，他言語への対応

器は Java のソースコードを解析するために実装したに必要な労力に関しても定性的に評価する．

解析器を再利用した．その結果，Java を解析する機能•

対応言語の追加を容易にするため，MASU は部の実装には共通要素解析器を新規実装する必要があっ

分 AST が言語非依存になるように AST を構築してたため，6 人月以上のコストを必要としたが，C#をいる．AST の構築自体は，AST の構造に関するルー解析する機能の実装に必要としたコストは，3 人日でルを構文定義ファイルに記述することで，ANTLR なあった．

ど構文解析器生成系が自動的に行う．構文定義上で各

このことより，言語非依存 AST 及び共通要素解析
器の有効性は高いといえる．

5. 1. 2 AST 解析部の設計及び共通要素解析器の有効性評価

要素の生成規則は他の要素を参照する．ある要素 P Eを表す部分 AST が要素 CE1 ∼ CEn に対応する n 個のノードで構成されるとき，要素 P E の生成規則上
で要素 CE1 ∼ CEn が直接参照されていると，要素

AST 解析部は高い拡張性を提供することにより，共P E を表す部分 AST を共通化するためのルールが記

通要素解析器などの既存のコードに変更を加えること述しやすい．筆者らが C++，Visual Basic の文法になく特有要素の解析を可能にしている．しかし，AST関して調査した結果，少なくともオブジェクト指向共解析部が高い拡張性を提供したとしても，共通要素解

通要素に関してはどちらの言語も，ほとんどの要素の析器の実装に必要とする開発労力に比べて，特有要素

生成規則上で部分 AST の構成ノードに対応する要素

解析器の実装に必要とする開発労力が大きすぎるようが直接参照されていた．このことから C++，Visual

であれば，AST 解析部に拡張性の高い設計を適用し，Basic ともに，部分 AST を言語非依存にする労力は共通要素解析器を再利用することの効果は低い．

小さいと考えられる．

そこで，我々は AST 解析部の設計及び共通要素解•C#は一部のアクセス修飾子やブロックの開始・析器の有効性を示すために，オブジェクト指向言語共終了を表す予約語などが Java と一致しているが，継通要素の解析と Java 特有要素の解析に必要とした開承関係やクラスのインポートを表す予約語は Java と発労力をクラス数を用いて評価した．結果を表 1 に示は異なる．このように，意味的に等しい予約語にはす．表 1 の列「解析器」は 4. 1. 2 で述べて AST 解4. 1. 1 で述べた共通ノードを割り当てる必要があった

析部を構成する解析器群の実装に必要としたクラスのが，予約語に対する AST ノードの割当は構文定義ファ数，「情報保存」は解析した情報を保存するためのク

イルに記述することで，ANTLR が自動的に行うためラスの数，「その他」はその他の処理に必要としたク

容易に実装することができた．このことから，C#のラスの数を示す．

ように頻繁に記述される予約語が Java と同じである

表 1 より，少なくとも Java 特有要素の解析にかかためソースコードが視覚的に似ている言語であっても，る実装はオブジェクト指向言語共通要素の解析にかか

Visual Basic のようにソースコードが視覚的に異なる開発労力に比べ非常に小さいことが分かる．このこ

る言語であっても，視覚的な差異を吸収し，言語非依とより，AST 解析部の設計及び共通要素解析器の有存な AST を構築する労力はどちらも小さいと考えら

1526

論文／多言語対応メトリックス計測プラグイン開発基盤 MASU の開発

モリ容量が 2 GByte，OS が Windows XP の PC をれる．

•

C#のプロパティや構造体などは，Java には明

示的には存在しないが，意味的には Java のメソッド利用して，次の二つのソースコードを解析した．
［Java Platform Standard Edition 6］ 解析対象の開やクラスと等しい．このため，プロパティや構造体の発言語は Java，規模はファイル数が 3,852，ソースコー

情報は，それと等価なメソッドやクラスを表すデータ

ドの行数が約 12 万行，であった．解析に要した時間はとして構築した．これを実現するためには，4. 1. 2 で

約 392 秒，メモリ空間の使用量は最大約 838 MByte

説明した解析器を新規実装する必要があった．また，であった．

プロパティの呼出しは，フィールドの参照・代入と区［CSgL］ 解析対象の開発言語は C#，規模はファイ

別することができないため，データ構造構築部にもプ

ル数が 61，ソースコードの行数が約 3 万行，であった．

ロパティを考慮した意味解析のロジックの実装した．

解析に要した時間は約 59 秒，メモリ空間の使用量は

意味解析のロジックに影響を与える差異は，AST の

最大約 51 MByte であった．CSgL は Java Platform

構築段階では吸収することができなかった．これらのStandard Edition 6 と比較すると小規模であるが，実作業に必要とした労力は，共通ノードの割当や AST

装には C#特有の要素（構造体，プロパティ，#if なの構造を変更する労力と比較するとかなり大きかった．

どの前処理命令，as 演算子，C#特有の型，など）がこのことから，C#のようにソースコードが視覚的に多く使用されている．MASU はこれらの特有要素を似ている言語であっても，メトリックスを計測する際

オブジェクト指向共通の要素として解析することがでに言語共通の要素とみなして計測することが望ましい

きた．

と考えられる要素をもっている言語や，特殊な意味解

5. 3 MASU を用いたプラグイン実装

析を必要とする言語への対応は大きな労力を必要とす

MASU を用いたメトリックス計測プラグインの試ると考えられる．ただし，オブジェクト指向共通要素

作として，CK メトリックスとサイクロマチック数をに関しては，意味解析のロジックも再利用できる場合計測するプラグインを実装した．

が多いため，ソースコード解析器を個別に作成する労5. 3. 1 プラグインの規模力に比較すると遥かに小さい労力で他言語に対応でき

各メトリックス計測プラグインの規模と実装に要しると考えられる．また，言語特有要素に関する意味解た時間を表 2 に示す．いずれのプラグインも実装は 1

析のロジックに関しても，言語を 1 対 1 で比較すると人で行われた．表の列「メトリックス」は計測される再利用できないが，複数の言語を考慮するとある程度

メトリックス名を，「総行数」は実装されたプラグイ

再利用できる．例えば，Visual Basic において引数なンの行数（カッコ内は空白・コメント込みの総行数）

しの関数呼出しは関数名の後に “()” を記述する必要を，「ML 行数」はメトリックス計測ロジックの行数がないため，フィールドの参照と区別することができを，「時間」は実装に要したおおよその時間を示す．まない．しかし，これに対処するための意味解析ロジッ

た，WMC はすべてのメソッドの複雑度が一律である

クは既に実装されている C#のプロパティ呼出しに対と仮定して実装した．

する意味解析ロジックが再利用できる．また，C#の5. 3. 2 プラグイン実装例

特有の概念であるパーシャルクラスに対処するためのMASU のプラグイン実装の例を図 6 に示す．

意味解析ロジックは，C++のメソッドの非インライン
定義に対処するために利用できると考えられる．このように Java では利用されない C#特有の意味解析ロジックも，C++や Visual Basic などの他言語を考慮すると，再利用することが可能であり，開発労力の削減に貢献すると考えられる．

5. 2 実 行 性 能
MASU の実行性能を評価するため，実際にソースコード解析を行い，使用した時間とメモリ空間を調査した．
具体的には，CPU が Pentium4 CPU 3.00 GHz，メ

表2

試作プラグインの規模と実装に要した時間（総行数の括弧内は空白・コメント込みの行数）
Table 2 Size of sample plugins and time taken to
implement them.
メトリックス
WMC
DIT
NOC
CBO
RFC
LCOM
サイクロマチック数

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

ML 行数
2
8
1
29
7
48
21

時間（分）
10
20
10
20
15
40
25

1527

電子情報通信学会論文誌 2009/9 Vol. J92–D No. 9

る定義は異なるであろうし，様々な定義を用いて計測結果を比較したいという要求も考えられる．MASUを利用すれば，図 6 のように measureClassMetric メ
ソッド（クラスのメトリックスを計測する場合）を自由に実装することにより，ユーザ独自のメトリックス
計測ロジックを用いてメトリックス計測を行うことができる．

6. 関 連 研 究
6. 1 バイトコード解析ツール
Soot [26] McGill 大学のプロジェクトとして開発されている Java バイトコード最適化フレームワーク．最適化のための情報としてバイトコード解析情報を提供するため，プログラム解析ツールとしても利用できる．

WALA [29] IBM Research が開発した Java バイ
トコード解析ライブラリ．
バイトーコードを解析することにより，実際に実行されるコードの情報を得ることができるが，制御文の種類などのようにソースコードからでなければ得られない情報も多く存在する．また，バイトコードはコン
パイラが生成したコードであり，人間が保守しなければないらないのはソースコードである．そして，メトリックスが示すのは，人間が作成したプロダクトの品質評価や，人間が行う保守のコスト予測などに使われFig. 6図 6 RFC 計測プラグイン実装例
An example of implementation for the plug-inthat measures RFC.

る尺度である．ゆえに，メトリックスの計測は，バイ
トコードの特徴ではなく，ソースコードの特徴を測ることに意味があるといえる．
また，Soot や WALA は Java のバイトコードのみ

図 6 は CK メトリックスの一つである RFC を計測するためのプラグインを実装している．一般に，RFCを対象としており，多言語対応はされていない．

6. 2 ソースコード解析ツールを計測するには，各クラスに定義されているメソッド

Ducasse らは言語非依存のリエンジニアリングプと，それらのメソッドの中で呼び出されているメソッ

ラットフォームとして MOOSE を開発している [4]．

ドの情報を抽出しなければならず，大きな開発労力を

MOOSE は MASU と同様にソースコードを入力とし必要とする．しかし，MASU のプラグインとして実たソフトウェアメトリックスの評価機能を提供する．

装することにより，表 2 や図 6 に示す程度のソース

しかし，MOOSE はソースコードを直接解析するわ

コードで実装することができる．図 6 から分かるよう

けではなく，CDIF や XMI などに変換された情報をに，メインモジュールと協調するための API は 1 行程

解析するため，提供される情報はモデルベースの情報度で実装することができ，プラグイン作成に必要な開となる．モデルベースの情報はソフトウェアの視覚化

発労力は実質的にはメトリックス計測ロジックを記述などには有用であるが，ソースコードから直接得らするメソッドの実装のみである．メトリックス計測ロ

れる情報と比較すると情報量が減少する．また，ソージックの記述もメインモジュールが提供する情報を利

スコードから CDIF や XMI への変換部はサードパー

用することにより，低コストで実装することができる．
また，WMC のように厳密な定義がされていない
メトリックスを計測する場合，ユーザによって要求す
1528

ティーのツールに依存しており，MASU が提供するような拡張・変更容易性は備えていない．

Collard らはソースコードの情報を XML 形式で保

論文／多言語対応メトリックス計測プラグイン開発基盤 MASU の開発

存するために srcML と呼ばれる XML の活用法を提トの解析を実現している [11]．MASU は将来 C/C++

案している [8]．srcML は C，C++，Java を対象としの対応を検討しており，実装には，TUAnalyzer 同様ている．srcML から得られる情報は構文解析で得られに解析の事前準備として GNU の C/C++コンパイラる情報のみであり，意味解析で得られる情報は含まなを利用することを考えている．

い．このため，構文情報を利用したコードコメントの

6. 3 AST 変換技術

管理などには有用であるが，意味解析で得られる情報

長谷川はあるプログラミング言語 G1 のツールを他を必要とするソフトウェアメトリックスの計測には利の言語 G2 に適用可能にする手法を提案している [12]．

用できない．

この手法は言語 G2 の AST を言語 G1 の AST に変換

Antoniol らは GCC (GNU Compiler Collection)

することにより実現される．この手法により，特定のが生成する AST を解析することにより，多言語に対言語を対象とした既存のメトリックス計測ツールを他応したソースコード解析ツール XOgastan を開発しての言語に適用することが可能となる．しかし，同一のいる [2]．XOgastan は原理的には GCC が対応してい言語を対象としたツールであっても，そのツールが扱るすべての言語を解析できる．しかし，GCC が対応

う AST はツールごとに異なる．このため，AST の変

していない言語の解析を行うための設計上の工夫に関換ルールは各ツールごとに実装する必要がある．

しては述べられていない．また，XOgastan は意味解

MASU は既存のツールの再利用には応用できない

析が不十分であるため，各変数の関数内における使用が，5. 3 で示したようにメトリックス計測ロジックの回数などに関する情報は取得できるが，関数内に記述記述のみであれば低コストで再実装することができる．

されている式などの文脈に関する情報は取得できない．

AST 変換ルールの実装には構文解析の専門的な知識がMASU の AST 解析部のような解析対象要素の追加を要求されるため，AST 変換を用いるよりも，MASU

容易にするための設計に関しても述べられていない．

を用いて再実装した方が低コストで等価なツールを用

福安らは細粒度のソフトウェアリポジトリに基づい意できる可能性は高い．また，MASU のソースコー

た CASE ツールプラットホームとして Sapid を開発

ド解析部で言語間の差異が吸収されるため，ツールごしている [10]．Chen らは C 言語を対象としたプログとに AST 変換ルールなどを実装する必要はない．つラムの情報の抽象化システムを開発している [5]．こまり，MASU が言語 G に対応すれば，MASU のソー

れらのシステムは MOOSE，srcML，XOgastan に比スコード解析部を利用したすべてのツールが言語 G にべ，細かい粒度でソフトウェアの要素を解析している

適用可能となる．

ため，これらのシステムの有効性は高く，MASU と同じようにメトリックス計測ツールの開発基盤としても利用できる．ただし，MASU はメトリックス計測を行

7. む す び
本論文では，メトリックス計測プラグイン開発基盤

う上で，次の点に関して，これらのツールよりも洗練

MASU について述べた．MASU は次の特徴をもってされている．

おり，MASU を用いることによって，従来に比べて低•複数のプログラミング言語を統一的に扱う．

いコストでソースコードからメトリックスを計測する•

複数のメトリックスの計測に対応するために，ことが可能になる．

提供するデータを容易に変更・追加できるよう設計さ
れている．

•

メトリックス計測ツールをプラグイン化している．

C/C++のソースコードを正確に解析するには，テンプレートの情報を解析する必要がある．しかし，テン
プレートの解析は複雑であるため，C/C++を対象と•複数のプログラミング言語のソースコードに対して適用可能である．

•

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

•

複数のメトリックスの計測に対応するために，提供するデータの追加や変更を容易に行える．

•

必要最低限のメトリックス計測ロジックを記述するだけで，新たなメトリックスを計測可能である．

したソースコード解析ツールの多くはテンプレートのMASU の開発は実用的な段階にまで到達しており，解析に十分に対応していない．Gschwind らが開発し実際にいくつかの研究で活用されている [9], [15], [20],ている TUAnalyzer は，解析の前準備として GNU の[21], [24]．

C/C++コンパイラを利用することにより，テンプレー

現在，MASU は Java 若しくは C#のソースコー
1529

電子情報通信学会論文誌 2009/9 Vol. J92–D No. 9

ドを入力とすることができる．今後，C++，Visual[14]

tional Symposium on Applied Corporate Computing,

していく予定である．また，解析対象をソースコード
以外に広げることも考えている．例えば，実行履歴を

M. Hitz and B. Montazeri, “Measuring coupling andcohesion in object-oriented systems,” Proc. Interna-

Basic などの他のオブジェクト指向言語にも順次対応

pp.78–84, Oct. 1995.
[15]

堀 直哉，岡野浩三，楠本真二，“モデル検査技術を用いた
インバリアント被覆テストケースの自動生成による Daikon
出力の改善，” ソフトウェア工学の基礎 XV，pp.41–50,[16]

instantiations inc. CodePro AnalytiX.

構築のための研究開発」（研究開発領域名：ソフトウェ[17]

JavaCC. http://javacc.dev.java.net/

ア構築状況の可視化技術の開発普及）の委託に基づい[18]

JMetric. http://www.it.swin.edu.au/projects/[19]

R. Lincke, J. Lundberg, and W. Lowe, “Compar-

解析して共通データを構築するような解析部を作成することで，動的なデータをもとにしたメトリックス計

Nov. 2008.

測が可能になる．
謝辞

本研究は一部，文部科学省「次世代 IT 基盤て行われた．
文

http://www.instantiations.com/

jmetric/products/jmetric/default.htm
ing software metrics tools,” International Symposium

献on Software Testing and Analysis, pp.131–141, July

[1]

ANTLR. http://www.antlr.org/[2]

G. Antoniol, M.D. Penta, G. Masone, and U.
Villano, “XOgastan: XML-oriented gcc AST analysis

2008.
[20]

宮崎宏海，肥後芳樹，井上克郎，“アイテムセットマイニ” 信
ングを利用したコードクローン分析作業の効率向上，
学技報，SS2008-18, July 2008.

[21]

三宅達也，肥後芳樹，井上克郎，“ソフトウェアメトリク
スとメソッド内の構造を用いたリファクタリング支援手法” 信学技報，SS2008-25, July 2008.
の提案，

and transformations,” Proc. 3rd IEEE International
Workshop on Source Code Analysis and Manipulation, pp.173–182, Sept. 2003.
[3]

Aqris software. RefactorIT. http://www.aqris.com/[4]

A.L. Baroni and F.B. Abreu, “An OCL-based formalization of the MOOSE metric suite,” Proc. 7th
ECOOP Workshop on Quantitative Approaches in
Object-Orietend Software Engineering, 2003.

[5]

Y.F. Chen, M.Y. Nishimoto, and C.V. Ramaoorthy,“The C information abstraction system,” IEEE
Trans. Softw. Eng., vol.16, no.3, pp.325–334, March
1990.

[6]

S. Chidamber and C. Kemerer, “A metric suite forobject-oriented design,” IEEE Trans. Softw. Eng.,
vol.25, no.5, pp.476–493, June 1994.

三宅達也，肥後芳樹，井上克郎，“メトリクス計測プラグ” ソフトウェアエン
インプラットフォーム MASU の開発，
ジニアリング最前線，pp.63–70, Sept. 2008.
[23] T. McCabe, “A Complexity Measure,” IEEE Trans.

[22]

[24]

” 信学論（D），vol.J91-D, no.12, pp.2915–2925,の提案，Dec. 2008.
[25] P. Oman and S.L. Pleeger, Applying Software Metrics, IEEE Computer Society Press, 1997.

[7]

Clarkware consulting inc. JDepend.

[8]

M.L. Collard, J.I. Maletic, and A. Marcus, “Support-

http://www.clarkware.com/
ing document and data views of source code,” Proc.

[26]

Soot: a Java Optimization Framework.

[27]

TIOBE Software: The Coding Standards Company.

http://www.sable.mcgill.ca/soot/
http://www.tiobe.com/index.php/content/

ACM Symposium on Document Engineering, pp.34–
41, Nov. 2002.
[9]

枝川拓人，赤池輝彦，肥後芳樹，楠本真二，“画面遷移とデータベース処理を考慮したトランザクションファンク” 信学技報，SS2008-17,
ション識別手法の詳細化と実装，
July 2008.

[10]

福安直樹，山本晋一郎，阿草清滋，“細粒度ソフトウェ
ア・リポジトリに基づいた case ツール・プラットフォー” 情処学論，vol.39, no.6, pp.1990–1998, June
ム sapid，
1998.

[11]

T.

Gschwind,M.

Pinzger,

and

H.

Gall,

“TUAnalyzer—Analyzing templates in C++ Code,”
Proc. 11th Working Conference on Reverse Engineering, pp.48–57, Nov. 2004.
[12]

長谷川勇，“AST 変換を用いた他言語へのツール適用，”
信学技報，SS2008-22, July 2008.

[13]

B. Henderson-Sellors, Object-Oriented Metrics: Measures of Complexity, Prentice Hall, 1996.

1530

Softw. Eng., vol.2, no.4, pp.308–320, Dec. 1976.
村尾憲冶，肥後芳樹，井上克郎，“ソフトウェアメトリクス
値の変遷に基づいた注力すべきモジュールを特定する手法

paperinfo/tpci/index.html[28]

Virtual machinery. JHawk.

[29]

WALA. http://wala.sourceforge.net/wiki/index.php/

http://www.virtualmachinery.com/
Main Page（平成 20 年 10 月 31 日受付，21 年 3 月 9 日再受付）

三宅達也

平 19 阪大・基礎工・情報卒．現在同大大学院博士前期課程 2 年．リファクタリン
グの研究に従事．

論文／多言語対応メトリックス計測プラグイン開発基盤 MASU の開発

肥後

芳樹 （正員）平 14 阪大・基礎工・情報中退．平 18 同大大学院博士後期課程修了．平 19 阪大・
情報・コンピュータサイエンス・助教．博士（情報科学）．コードクローン分析やリファクタリングに関する研究に従事．情報処理学会，IEEE 各会員．

楠本

真二 （正員）昭 63 阪大・基礎工・情報卒．平 3 同大
大学院博士課程中退．同年同大・基礎工・情報・助手．平 8 同大講師．平 11 同大助教授．平 14 阪大・情報・コンピュータサイ
エンス・助教授．平 17 同学科教授．博士（工学）．ソフトウェアの生産性や品質の定量的評価，プロジェクト管理に関する研究に従事．情報処理学会，IEEE，JFPUG 各会員．

井上克郎 （正員）昭 54 阪大・基礎工・情報卒．昭 59 同大
大学院博士課程了．同年同大・基礎工・情報・助手．昭 59〜昭 61 ハワイ大マノア校・情報工学科・助教授．平元阪大・基礎工・情報・講師．平 3 同学科・助教授．平 7 同学科・教授．博士（工学）．平 14 阪大・情報・コンピュータサイエンス・教授．ソフトウェア工学の研究に従事．情報処理学会，日本ソフトウェア科学会，IEEE，ACM各会員．

1531