Code Clone Analysis Environment for Supporting Software Development andMaintenanceYasushi Ueda† , Toshihiro Kamiya†† , Shinji Kusumoto† , and Katsuro Inoue††

Graduate School of Information Science and Technology, Osaka University, Toyonaka-shi, 560-8531, Japan
PRESTO, Japan Science and Technology Corporation, JAPAN††

Abstract
It is generally said that code clones are one of the factors to make software maintenace diﬃcult. They arepairs or sets of code portions in source ﬁles that are identical or similar to each other. If some bugs arefound in a code portion, it is nessesary to correct them in its all clones. However, in large-scale sofrware,
it is very diﬃcult to ﬁnd all clones by hand. In this paper, we develop a code clone analysis environment,
Gemini, that uses a clone detection tool, CCFinder. Also, we conduct a case study for the evaluation.
keywordSoftware maintenance, Code clone, Software metrics

論

文

開発保守支援を目指したコードクローン分析環境
植田 泰士†神谷年洋††

楠本 真二†

井上 克郎†

Code Clone Analysis Environment for Supporting Software Development andMaintenanceYasushi UEDA† , Toshihiro KAMIYA†† , Shinji KUSUMOTO† , and Katsuro INOUE†

あらまし ソフトウェアの保守作業を難しくしている要因の一つとしてコードクローンがある．コードクロー
ンとは，ソースコード中の同一，または類似した部分を指す．あるコード片にバグが含まれていた場合には，そのコード片のコードクローン全てについて修正の是非を考慮する必要がある．しかし，大規模なソフトウェアの場合，それら全ての箇所を手作業で発見し，修正の是非を考慮することは非常に困難である．本研究では，コー
ドクローン検出ツール CCFinder の検出結果を利用したコードクローン分析環境 Gemini の構築を行う．本シス
テムは，開発保守におけるコードクローンの利用を支援するため，コードクローンの位置情報の視覚化，コードクローンに関するメトリクス値の算出，および対応したソースコードを参照する機能を実装する．適用実験の結果，本システムを用いることで，特徴的なコードクローンなどを抽出できることを確認した．
キーワード

ソフトウェア保守，コードクローン，ソフトウェアメトリクス

コードクローンの存在は保守作業を困難にする [7]．

1. ま え が き

これは，修正されるコード片がコードクローンであれ

ソフトウェア保守とは，「納入後，ソフトウェア・プ

ば，すべての類似コード片を何らかの手段で同様に修ロダクトに対して加えられる，フォールトの修正，性正する必要性が生じるためである．対策としては，

能またはその他の性質改善，変更された環境に対する• コードクローン情報を文書化しておくことで一

プロダクトの適応のための改訂」であると定義されて貫した修正を可能にする，いる [9]．近年，ソフトウェアシステムの大規模化，複• コードクローンを必要に応じて検出するの 2 つがある [10]．

雑化に伴い，ソフトウェアの保守・デバッグ作業に要するコストは増大しており，大企業では既存システムの保守に多くのコストを費やすようになった．

しかし，前者の方法はコードクローン情報を常に最新の状態に保つ手間がかかり，実現困難である．後者のコードクローンは保守作業を困難にする要因の一つ方法として，いくつかのコードクローン検出手法やツーである．コードクローンとは，ソースコード中の同一，ルが提案されている [1] [2] [3] [4] [5] [6] [12] [13] [14]．

または類似した部分のことであり，「重複コード」とも我々が開発してきているコードクローン検出ツール呼ばれる．コードクローンがソフトウェア中に作り込

CCFinder [11] は，大規模なソフトウェアから実用的まれる原因として，既存コードのコピーとペーストにな時間でコードクローンを検出することが可能である．

よる再利用，頻繁に用いられる定型処理，パフォーマ

しかし，(1)CCFinder の出力はコードクローンの位置

ンス改善のための意図的な繰り返し，コード生成ツー

情報（ファイル名，行，カラム）であり，直感的な理ルによって生成されたコードなどがある．

解が困難である．また，(2) 大規模なソフトウェアか† 大阪大学 大学院情報科学研究科，豊中市

Graduate School of Engineering Science, Osaka University,
Toyonaka-shi, 560-8531 Japan†† 科学技術振興事業団 若手個人研究推進事業

PRESTO, Japan Science and Technology Corporation,Japan

ら検出された膨大なコードクローンを分類・整理する機能が提供されないなど，実際の保守作業に利用するには問題があった．
本論文では，大規模ソフトウェアにおけるコードク
ローンの分析を行うための統合環境 Gemini を構築す

電子情報通信学会論文誌 X Vol. Jxx–X No. xx

pp. 1–8xxxx 年 xx 月

1

電子情報通信学会論文誌 ’xx/xx Vol. Jxx–X No. xx

る．Gemini は内部的に CCFinder を利用してコードステップ 3(検出処理): トークン列の中から，指定クローンの検出を行い，様々なユーザインタフェース

された長さ以上一致しているような部分クローン列をを通して，ソフトウェア技術者に対して有益なコード

すべて検出する．

クローン情報を視覚的に提示する機能を備えている．

ステップ 4(出力整形処理): 検出されたクローンペ

また，本システムを大学におけるプログラミング演習

アについて，元のソースコード上での位置情報を出力で開発されたプログラムに適用するケーススタディにする．

より，その有用性を評価する．
以 降 ，2. 節 で は ，コ ー ド ク ロ ー ン 検 出 ツ ー ル

2. 2 コードクローンに関するメトリクス
Gemini ではコードクローンを識別するために，以CCFinder，および Gemini において用いられるコー

下の 6 つのメトリクスを利用する．

ドクローンに関するソフトウェアメトリクス等についLEN(C) (Length) [11]:て説明する．3. 節では，Gemini の設計と実装についクローンクラス C 内に含まれるコード片の最大トーて，4. 節では，適用実験の結果とその分析と考察につクン長を表す．

いて述べる．最後に 5. 節で，まとめと今後の課題を述POP(C) (Population) [11]:クローンクラス C 内のコード片の数を表す.
DFL(C) (Deﬂation) [11]:クローンクラス C を再構築した場合に減少するコー

べる．

2. 準

備

2. 1 コードクローン検出ツール CCFinder
本節では，Gemini がコードクローン検出に利用するツールである CCFinder に関する説明を行う．

ドの量の予測値を表す．ここで，再構築とは，クロー2. 1. 1 コードクローンの定義と関連用語あるトークン列中に存在する 2 つの部分トークン列
α, β が等価であるとき，α と β は互いにクローンであるという．また，ペア (α, β) をクローンペアと呼ぶ．

をそのサブルーチンの呼び出しに置き換えることであα，β それぞれを真に包含するいかなるトークン列も等価ではないとき，α，β を極大クローンという．まン呼び出しの大きさの大きさの和+共通ロジックを実た，クローンの同値類をクローンクラスと呼ぶ．ソー義される．実際には，クローンクラスのなかには再構

スコード中でのクローンを特にコードクローンという．

築が不可能なものも存在するので，DF L は再構築を

2. 1. 2 コードクローン検出処理手順
CCFinder は単一または複数のソースファイル中かンクラス C 内のコード片集合から抜き出した共通のロジックを実装するサブルーチンを作り，各コード片る．DF L(C) は，再構築前のコードの大きさ (すなわち，クローンクラス C 内のコード片の大きさの和) から，構築後のコードの大きさ (すなわち，サブルーチ
装するサブルーチンの大きさ) を引いたものとして定行うべきクローンクラスの優先順位を付けるために用いることを想定している．

ら，極大クローンのクローンペアを検出し，その位置

RAD(C) (Radius of clone class) [11]:情報を出力する．処理は以下の 4 つのステップから

ソースファイルが階層型ファイルシステムに格納されなる．

ている場合に，クローンクラスのファイルシステム内ステップ 1(字句解析): ソースファイルを字句解析での「広がり」を表す．クローンクラス C 内のコード(lexical analysis) によってトークン列に変換する．入片を含むソースファイルの集合を F として，F の各

力ファイルが複数の場合には，個々のファイルから得要素のファイルパス全てに共通した最も下位 (ルートられたトークン列を連結した単一のトークン列を生成から遠い) ディレクトリから，各要素のファイルまでする．

の距離の最大値と定義する．

ステップ 2(変換処理): 実用上意味を持たないコー

直観的には，RAD 値が低ければ，同一ファイル内

ドクローンを取り除くこと，および，些細な表記上のや同一ディレクトリに閉じているため，そのクローン

違いを吸収することを目的とした変形ルールによって，クラスをサブルーチンに置き換えることは比較的容

トークン列を変換する．例えば，この変換によって変易であると考えられる (修正を行う場合も同様)．逆

数名は同一のトークンに置換されるので，変数名が付に，RAD 値が高ければ，それらのコード片が様々なけ替えられたコード片もコードクローンであると判定

モジュールに分散している，あるいは，(特に複数の開することができる．

発者が関わる場合は) 異なる開発者のモジュールに含2

論文／開発保守支援を目指したコードクローン分析環境

まれるなど，修正の難易度は高くなると考えられる．

RSA(f ) (Ratio of similarity to all other ﬁles):
RSA は，ファイル f と，ファイル f 以外の全てのファ

Clone pair manager
Clone selection
information

イルそれぞれとの間に存在するクローンペアによって，ファイル f のコードがどれだけカバーされているかの

Code clone detector
Source files

=



1

Len(f )

Clone scatter plot view

User

Source code manager
Code clone database

割合を表し，次の式で定義される．
RSA(f )

Interfaces

Code clone analysis environment, Gemini

Source code view
Clone selection
information

Metrics manager

Len(cf )Metric graph views

cf∈CF (f)

図 1 システムの構成
Fig. 1 Architecture(Len(f ): ファイル f のトークン長 )(Len(cf ): コード片 cf のトークン長 )ここで，CF (f ) は，ファイル f 以外のファイルとクローンの関係を持つファイル f 内のコード片の集合を表し，cf は 1 コード片を表す．ただし，本総和におされてきている．中でも，Duploc [6] はコードクロー
ン情報を，クローン散布図を用いて視覚化する機能を持つ．クローン散布図はクローンペアを視覚的にする図であり，プロットされたそれぞれの点は，その座標いては，重複しているコード部分は，1 度しか考慮しに対応する行が一致していることを表す (詳細は 3. 2. 2ないものとする．

節で述べる)．Duploc では，クローン散布図がウィン

高い RSA を持ったファイルが生成する原因の一つに，開発者が，あるソースファイル全体をコピーした
上で，一部を修正して再利用するといった作業を行う

ドウ内に表示され，点をクリックすることで対応した
ソースコードを参照することができる．
クローン散布図を使うことで，クローンペア全体のことがある．Gemini において RSA は，コードクロー

分布状態を俯瞰的に表示し，ソースコードを素早く参ン情報を視覚的に表示するために利用される (3. 2. 2

照することが可能となるなど，対話的操作に有効な視節参照)．

覚化手法であるため，Gemini においても，クローン

RST(f1 , f2 ) (Ratio of similarity between two ﬁles):
RST (f1 , f2) は，ファイル f1 がファイル f2 とのクロー散布図を GUI の一部として利用している．

ンペアによってどれだけカバーされているかの割合をウェアのコードクローン分析においては散布図は膨大表し，次の式で定義される．

な数の点を含むため，単にクローン散布図を表示する

RST (f1 , f2 )

=

1



Len(f1 )Len(cf )cf∈CF (f1 ,f2 )ここで，CF (f1 , f2 ) は，ファイル f2 とクローンの関係を持つファイル f1 内のコード片の集合を表す．

RSA 同様，本総和においては，重複しているコード

ただし，本研究が想定するような大規模なソフトだけではなく，着目すべき部分を強調する，フィルタリングを行うなど，利用者を補助するためのさらなる方法が必要である．本課題に対して提案する我々の手法は，3. 2. 2 節で述べる．
また，Gemini はクローン散布図以外にも，2. 2 節

部分は，1 度しか考慮しないものとする．

で定義したコードクローンメトリクスのグラフを表示

RST は，2 ファイル間の類似度として用いることができる．もし f1 ，f2 が，あるソースファイルの 2 つのバージョンであれば，RST の計測値はバージョン間する機能を持つ．これらのグラフは，クローンクラスの類似度を意味する．計測値が小さければ，バージョ

供する．詳細は 3. 2. 3 節で述べる．

ンアップの際に多くの変更が加えられた可能性がある．

Gemini において RST は，RSA 同様，コードク
ローン情報を効果的に視覚化するために利用される(3. 2. 2 節参照)．

3. コードクローン分析環境 Gemini
3. 1 設 計 方 針
これまでに様々なコードクローン検出ツールが開発

やファイルを対象としており，クローンペアを表示するクローン散布図とは異なった対話的な分析機能を提3. 2 システム構成
本 シ ス テ ム は ，内 部 的 に CCFinder を 実 行 し ，CCFinder から得られた解析結果を基に分析環境を提供する．システムの構成を図 1 に示す．
Gemini は主に 5 つのコンポーネント: (1) コード
クローン検出部 (Code clone detector)，(2) クロー
ンペア管理部 (Clone pair manager)，(3) メトリクス
管理部 (Metrics manager)， (4) ソースコード管理部
3電子情報通信学会論文誌 ’xx/xx Vol. Jxx–X No. xx
f1

f6

a b a a b c

f3

f4

b c b d c e

f2
f

g h

f5
i

j k

f1
f6

a b a a b c
b

f4

f

図 2 クローン散布図ビューの表示例
GUI snapshot of clone scatter plot view

f4

f5
i

j

f6
k a

b c

j k

f3

g h b c b d c e

f5

f2

g h i

f2

f1
a b a fc b d c ef3

Fig. 2

f1

a b a

f2

f g h bFig. 4図 4 図 3 のクローン散布図のソート後Sorted model of clone scatter plot in Figure3

f4

c b d c e i

f3

3. 2. 2 クローンペア管理部
クローンペア位置情報をもとにして，利用者の要求

jf5に応じて，クローン散布図を表示する．クローン散布

k a
b c

f6

f1, f2, …, f6 : Filea, b, …, k : Token: Matched position

図 3 クローン散布図モデル
Fig. 3 Simple model of clone scatter plot

図上での GUI による操作として，拡大・縮小，および，任意のクローンペア集合を「選択状態」にすること，がある (選択状態は，後述する他のサブシステムと連携した操作で使われる)．図 2 に選択状態のクロー
ンペア集合を含んだクローン散布図の例を示す．矩形で囲まれたクローンペアが選択状態になっている．
クローン散布図(Source code manager)， (5) ユーザインターフェー

Gemini が表示するクローン散布図の簡単なモデルを図 3 に示す．散布図の原点は左上隅にあり，水平軸，スで構成されている．

垂直軸は，それぞれソースコードの並びに対応していまず始めに，コードクローン検出部にソースファイ

る．両軸上で，原点から順に，それぞれのソースファルが入力され，全てのコードクローンを検出する．次

イルに含まれるトークンが並んでいる．座標平面内にに，クローンペア管理部と，メトリクス管理部がその解点がプロットされている部分は，その両軸の対応する

析結果であるコードクローン情報を各インターフェー

トークンが一致することを意味する．したがって，散スを通して視覚化する．それらのインターフェース上

布図の主対角線は，両軸の同じ位置のトークンを比では，ユーザは任意のクローンペア (あるいは，クロー

較することになり，すべての点がプロットされることンクラス) を選択することができ，その選択によって，になる．また，点の分布は主対角線に対して線対称と実際のソースコードをソースコード管理部とそのインなる．一定の長さ (CCFinder で設定される最小一致

ターフェースを通して参照することができる．

トークン数) 以上の対角線分が，検出されたクローン

次節から図 1 における各コンポーネントについて順に述べる．

ペアである．図 3 では，f1 から f6 までのファイルが，それぞれ 3 つのトークンを含んでいる．ファイルの並

3. 2. 1 コードクローン検出部

びはファイル名の辞書順となっている．検出されるク

解析対象のファイルや，コードクローン検出のパラ

ローンペアは f1 と f6 に含まれる “ab” というトーク

メータを管理する．CCFinder を利用して検出した

ン列と，f3 と f6 に含まれる “bc” というトークン列

コードクローンの位置情報も管理する．

である．

4

論文／開発保守支援を目指したコードクローン分析環境

クローン散布図のソート
一般に，ソースファイルにはコードクローンを含まないものがあり，クローンペアのクローン散布図内で疎に分布する可能性がある．大規模なソフトウェアのクローン散布図を操作する場合，疎な分布であること
は，すなわち，広大なクローン散布図を全体に渡って参照しながら分析を行うことを意味し，分析の手間が増えることになる．
これを解決するため，クローン散布図のファイル順

図 5 ソースコードビューの表示例
Fig. 5 GUI snapshot of source code view

序を調節することで，分布を密にする方法 (クローン
散布図のソート) を提案する．ソートにより，クロー

スコードを表示する，(2) メトリクスグラフで一部のン散布図内の点の分布が密になり，大規模ソフトウェ

クローンクラスを選択した後，そのソースコードを表

アのコードクローン分析労力を軽減することができる．

示する，(3) メトリクスグラフで長い (LEN が大き

ソートにより，類似したファイルほど近くに配置さい) クローンクラスだけを選択した後，クローン散布

れ，また，原点周りにクローンを集めることができる．

図ではそれらがどこにあるのか調べる，といった対話

本ソートの手順は次のようになる．
ステップ 1: 対象ファイルのうち，RSA 計測値が最も高いファイル f を先頭のファイルとする．
ステップ 2: 順序が決定されていない対象ファイルのうち，f との間で RST が最も高いファイル f  を次のファイルとする．f  を f として，すべての対象ファ
イルの順位が決定するまで，ステップ 2 を繰り返す．
図 3 のファイルでは，f1 が最も高い RSA を持つので，f1 が先頭のファイルになり，以下，f1 との RSTが最も高い f6，f6 との RST が最も高い f3，等々と的操作を行うことができる．

3. 4 実装本システムは，Java で実装されており (約 13,000行)，JDK1.3VM が実行可能な環境で動作する．表示画面の例を図 2，5 に示す．

4. 適 用 実 験
4. 1 概要

大阪大学のあるプログラミング演習で作成されたプ
ログラムに対し，Gemini の適用実験を行った．

いう順番になる．ファイルソート後にクローン散布図

本演習において，各学生は，Pascal 言語 (のサブセッを求めたものは図 4 であり，原点近くに点が集まってト) でかかれたプログラムを CASL 言語 (アセンブリいることがわかる．

言語) に変換するコンパイラを C 言語で作成する．作3. 2. 3 メトリクス管理部

成にあたり，学生にはコンパイラの仕様が掲載されたクローンペア位置情報から，6 種のメトリクスを算指導書が与えられた．また，学生は，他の講義で，簡出する．利用者の要求に応じて，メトリクスグラフ

単なコンパイラのサンプルプログラムが記載されたテビューによってメトリクス計測値を表示する．クロー

キストを用いてコンパイラの設計方法についての説明

ンクラスに関するグラフ (RAD, LEN , P OP , DF Lを受けている．本演習は，次の 3 つのステップ (課題)を表示) とファイルに関するグラフ (RSA，RST を表で構成されている．

示) がある．利用者は，GUI による操作を行い，グラステップ 1(課題 1): 構文解析器 (P arser) の作成.

フの一部を「選択状態」にすることができる．

ステップ 2(課題 2): 意味解析器 (Checker) の作成.

3. 2. 4 ソースコード管理部
指定されたソースファイルの内容を表示する．選択状態の部分は強調表示される (図 2 参照)．

3. 3 サブシステム間の連携
クローンペア管理部，ソースコード管理部，メトリ
クス管理部の間で「選択状態」を用いた連携が可能にステップ 3(課題 3): コンパイラ (SP C) の作成．
また，Checker と SP C を作成するにあたり，各
課題の前課題のプログラムを拡張して作成することが課題として要求されている．つまり，Checker はP arser を，SP C は Checker を拡張することで作成される．

なっている．この連携により，利用者は例えば (1) ク

本適用実験に際し，69 人の学生 (S1 ..S69 ) のプロ

ローン散布図でクローンペアを選択した後，そのソー

グ ラ ム (P arser，Checker，SP C) を 収 集 し た (計5

電子情報通信学会論文誌 ’xx/xx Vol. Jxx–X No. xx

れぞれ 0.089，0.032，0.019 となっており，課題が進B

むにつれ，各個人間での類似性は低くなっていくことが確認された．これは，後の課題 (課題 2 や課題 3) のA

方がより学生のオリジナリティを必要としているため，自然な結果と考えられる．
しかしながら，幾人かの学生は，課題 3 においても高い RSA 値を持っていた．そこで，クローン散布図
を用い，学生間のコードクローンがどのように分布しているのか調べた．図 7 のクローン散布図は，全学生の SP C のソースコードを比較した結果であり，格子は各個人間の区切りを表している．本散布図上では，初め，コードクローンが散布図全体に広く分散し

図 6 全学生の SP C を比較したクローン散布図 (ソート済み)
図 7 Sorted scatter plot of all students

SP Cていたため，Gemini に実装されたソート機能を用いて，ファイル順序の並べ替えを行った．ソートによってコードクローンの分布は，図 7 のように原点近くに密集した．図 7 中の A が付されたコードクローンが360KLOC)．
4. 2 分

密集している部分では，S1 と S2 (以降，S1 ，S2 を合析

本適用実験において，次の項目について分析を行った．

(1) 全プログラムの間での類似性: プログラミング
演習では，作成期限に間に合わせるなどのために，他の学生のプログラムをコピーおよび修正することで，プログラムを作成するといったことが起こり得る．そこで，RSA 値等を調べることで，学生が作ったプロ
グラム間の類似性を確認する．

わせて A グループと呼ぶ) の SP C 間の比較が行われ，B が付されたコードクローンが密集している部分では，S3 ，S4 ，S5 (以降，S3 ，S4 ，S5 を合わせて B グ
ループと呼ぶ) の SP C 間の比較が行われていた．
まず，S1 ，S2 ，S3 ，S4 ，S5 の RSA 値を参照した
ところ RSA(SP C) と RSA(Checker) の値について
は，全学生の中で上位 5 位を占めていた．さらに B グ
ループの学生の RSA(P arser) 値は，上位 10 位内に(2) メトリクスグラフの有効性: いくつかのモジュー入っていた．実際に，ソースコードビューを用いて対ルに再構築できるような特徴的なコードクローンを抽応したコードクローンを調べてみたところ，まず A グ

出できるかどうかを調べることで，メトリクスグラフ

ループにおける類似コードのほとんどは，テキストにの有効性を確認する．

記載されたサンプルコンパイラのコードであることが4. 2. 1 全プログラムの間での類似性
RSA 値の計測結果を表 1 に示す．表 1 における
P arser，Checker，SP C の RSA 値の平均値は，そ

表 2 各プログラムにおける DF L 値の最大値
Table 2 The maximum values of DF L in each program

表 1 RSA
値
Table 1 Values of RSA

≈

6

S1
S2
S3
S4
S5
S6
S7

Parser
0.029
0.162
0.326
0.297
0.348
0.028
0.000

S69
ave.
max.
min.

0.032
0.089
0.407
0.000

Checker
0.244
0.271
0.211
0.244
0.151
0.009
0.000
···
0.004
0.032
0.271
0.000

確認された．一方，B グループにおける類似コードは，
変数名やコメントまで類似が見られた．つまり，B グ

SPC
0.159
0.148
0.137
0.160
0.142
0.011
0.000

ave.
0.144
0.194
0.224
0.234
0.214
0.016
0.000

0.003
0.019
0.160
0.000

0.013
0.046
0.234
0.000

≈

≈

S1
S2
S3
S4
S5
S6
S7
S69
max.
min.
ave.

Parser
79
145
75
75
75
3538
100

Checker
131
199
97
75
119
163
211
···
223
211
3538
603
0
47
196
183

SPC
131
199
199
391
233
189
3439
≈
258
3439
51
311

論文／開発保守支援を目指したコードクローン分析環境
ParserChecker

SPC

DF L 値に関して特に突出した値を持っていることが確認された．

Parser

表 2 から，S6 の DF L(P arser)，DF L(Checker)，
DF L(SP C) の値は，それぞれ 3538，163，189 となっていることが分かるが，DF L(P arser) は非常に高い値であるのに対し，DF L(Checker)，DF L(SP C) のC

CheckerED

値は，ほぼ平均値に近くなっている．これは，P arser
から Checker へ拡張が行われる際に，コードクロー

SPC

ンを除去する再構築が行われたことを意味する．
一方，S6 のプログラムに関するクローン散布図を
図 8 に示す．本散布図では，両座標軸上に P arser，

図 8 S6 のクローン散布図
Fig. 8 Clone scatter plot for S6 ’ programs
Parser Checker

SPC

Checker，SP C が課題の順に並んでいる．P arser
は，DF L 値が突出したクローンクラスを含んでいた(図中 C の部分)．P arser と Checker の比較 (図中
D の部分) においては，このような密集したクローン

Parser Checkerは存在せず，代わりに，一本の線分が現れている (図中 E の部分)．これは，S6 が Checker を作成する際に，P arser に多く存在したコードクローンを一つのサブルーチンにマージしたことを意味している．実際，
ソースコードを参照すると，そのような再構築が行われたことが確認できた．

SPC

F

次に，図 9 に S7 のクローン散布図を示す．C と同様の，コードクローンが密集した部分が存在した (F )．
ソースコードを参照することで，これらのコードク
ローンが，S6 の場合と同様に再構築可能かを確認した．これらのコード片で異なっている部分は，ある 2

Fig. 9図 9 S7 のクローン散布図
Clone scatter plot for S7 ’ programs

箇所の定数名のみであり，それらをパラメータ化することで，容易に一つのサブルーチンにまとめることが可能であった．

ループ内において互いに何らかの参照が行われた可能性が高いと考えられる．

4. 2. 2 メトリクスグラフの有効性
ここでは，各学生の各プログラム内での比較を行い，特に DF L 値の有効性確認を行った．
こ こ で DFL を 算 出 す る に 当 たって ，各 サ ブ
ル ー チ ン 呼 び 出 し は 5 ト ー ク ン (“サ ブ ル ー チ
ン 名”, “(”, “引 数”, “)”, “;”) と し ，共 通 ロ ジッ

このように，「パラメータを追加して共通ロジックをサブルーチンにまとめる」場合は，パラメータの追加
がモジュールの結合を増大させるため，保守容易性の観点からはトレードオフを考慮する必要がある．S7 の場合には，追加されるパラメータは定数 2 つであり，モジュールの結合はそれほど増大しないと考えられる．

5. まとめと今後の課題

クを実装するサブルーチンの大きさはコードク

本論文では，開発保守支援を目指したコードクロー

ロ ー ン の 各 コ ー ド 片 と 同 じ と す る ．し た がって ，ン分析環境 Gemini の構築を行った．Gemini を用い

DF L(C) = LEN (C) × P OP (C)−(P OP (C) × 5 + LEN (C))．
表 2 に 各 プ ロ グ ラ ム に お け る DF L 値 の 最 大
値 を 示 す．メ ト リ ク ス グ ラ フ よ り，S6 の P arser(DF L=3528) および S7 の SP C (DF L=3439) は，ることで，クローン散布図やメトリクスグラフ等のイ
ンターフェースを介して，特徴的なコードクローンを識別することができ，それらに対応した実際のソースコードを参照することができる．また，本システムの有効性の確認のため，大学におけるプログラミング演7電子情報通信学会論文誌 ’xx/xx Vol. Jxx–X No. xx

習で作成されたプログラムに適用した．クローン散布

dependence graphs”, Proc. 8th Working Conference

図においては，ソート機能の有効性等が確認された．

on Reverse Engineering, pp.562-584, Stuttgart, Ger-

また，メトリクスを用いた分析においては，特徴あるmany, Oct. 2001.
[14]

J. Mayland, C. Leblanc, and E. Merlo, “Experiment

コードクローンが容易に識別できることを確認した．

on the automatic detection of function clones in a

今後の課題としては，大規模なソフトウェアや実際

software system using metrics”, Proc. IEEE Interna-の開発現場へ Gemini を適用し，評価を行うことが挙tional Conference on Software Maintenance-1996,
pp. 244-253, Monterey, USA, Nov. 1996.

げられる．

（平成年月日受付，月日再受付）

文
[1]

献

B.S. Baker, “A program for identifying duplicatedcode”,

Computing Science and Statistics, vol.24,

pp.49-57, 1992.
[2]

B.S. Baker,

植田“On finding duplication and near-

duplication in large software systems”,

Proc. the平 13 阪大・基礎工・情報卒．平 15 同大

2nd Working Conference on Reverse Engineering,

大学院博士前期課程修了．現在，宇宙開発事業団所属．在学中，コードクローン分析の研究に従事．

pp.86-95, Tronto, Canada, July 1995.
[3]

M. Balazinska , E. Merlo, M. Dagenais, B. Lagüe, andK. Kontogiannis, “Measuring clone based reengineering opportunities”,

泰士

Proc. 6th IEEE International

Symposium on Software Metrics, pp.292-303, Boca
Raton, USA, Nov. 1999.
[4]神谷

M. Balazinska , E. Merlo, M. Dagenais, B. Lagüe, andK. Kontogiannis, “Partial redesign of Java software

平 8 阪大・基礎工・情報中退．平 13 同大

systems based on clone analysis”, Proc. 6th IEEE

大学院博士課程了．現在，科学技術振興事
業団 PRESTO 研究員．博士 (工学)．オブ
ジェクト指向関連技術，ソフトウェア保守(メトリクス，コードクローン)，認知科学

International Working Conference on Reverse Engineering, pp.326-336, Atlanta, USA, Oct. 1999.
[5]

年洋I.D. Baxter, A. Yahin, L. Moura, M. Sant’Anna,
and L. Bier,“Clone detection using abstract syn-tax trees”, Proc. IEEE International Conference on

に関する研究に従事．情報処理学会，IEEE
各会員．

Software Maintenance-1998, pp.368-377, Bethesda,
USA, Nov. 1998.
[6]楠本

S. Ducasse, M. Rieger, and S. Demeyer. “A language

昭 63 阪大・基礎工・情報卒．平 3 同大
学院博士課程中退．同年同大・基礎工・情報・助手．平 8 同大講師．平 11 同大助教
授．平 14 阪大・情報・コンピュータサイ
エンス・助教授．博士 (工学)．ソフトウェ

1999.
Refactoring: improving the design of

M. Fowler,

existing code, Addison-Wesley, 1999.
[8]

（正員）

Proc. IEEE International Conference on Software
Maintenance-1999, pp.109-118, Oxford, UK, Sept.
[7]

真二

independent approach for detecting duplicated code”,

D. Gusfield, Algorithms on strings, trees, and se-

アの生産性や品質の定量的評価，プロジェ
クト管理に関する研究に従事．情報処理学会，IEEE 各会員．

quences, Cambridge University Press, 1997.
[9]IEEE Std 1219: Standard for software mainte-

井上

nance, 1997.
[10]

井上克郎, 神谷年洋, 楠本真二, “コードクローン検出法”,
コンピュータソフトウェア, vol.18, no.5, pp.47-54, 2001.

[11]

T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder:

情報・助手．昭 59 〜昭 61 ハワイ大マノア
校・情報工学科・助教授．平 1 阪大・基礎
工・情報・講師．平 3 同学科・助教授．平system for large scale source code”, IEEE Trans.
vol.28,

no.7,

pp.654-670,

2002.
[12]

R. Komondoor, and S. Horwitz,“Using slicing to

identify duplication in source code”, Proc. 8th International Symposium on Static Analysis, pp.40-56,
Paris, France, July 2001.
[13]

8

J. Krinke,“Identifying similar code with program（正員）

昭 54 阪大・基礎工・情報卒．昭 59 同大大学院博士課程了．同年同大・基礎工・A multilinguistic token-based code clone detection
Software Engineering,克郎

7 同学科・教授．工学博士．平 14 阪大・情報・コンピュータサイエンス・教授．ソフトウェア工学の研究に従事．情報処理学会，日本ソフトウェア科学会，IEEE，ACM各会員．