日本ソフトウェア科学会第 32 回大会 (2015 年度) 講演論文集

類似ソフトウェア比較のための統一されたディレクト
リ構造の可視化ツール
坂口 雄亮

石尾 隆

神田 哲也

井上 克郎

ソフトウェア開発において，ソースコードの再利用が行われた結果，類似したソフトウェアが数多く生まれることがある．そのような類似ソフトウェアの共通性や独自性を理解するにはソースコードの比較が重要となるが，類似ソフトウェアといってもディレクトリ構造は異なる場合があり，対応したディレクトリを見つけることは困難である．本
研究では，そのような類似ソフトウェアのソースコードからから，それらを統合した単一のディレクトリ構造を抽出し，可視化するツールを実装する．抽出されるディレクトリ構造は，与えられたソフトウェアのディレクトリを全て含み，ソフトウェア間で対応関係にあると推定されたディレクトリを 1 つのディレクトリとして表現する．そして，対応関係にあるディレクトリでは，それらのファイル内容の比較を容易に行うことができる．試作したツールのケーススタディとして，4 つの Android 製品に対して可視化を適用した例を示す．

Source code is often reused in software development. Such reuse activity may result in a large numberof similar software products. To understand commonalities and variabilities among such similar products,comparison of their source code is important. However, each product may change its own directory structure; it is hard to identify corresponding directories among products. In this paper, we propose a techniqueto extract and visualize a unified directory tree. The extracted directory tree includes all the directories ofgiven products and merges corresponding directories into a single node. Since a node in a tree corresponds
to multiple directories in products, developers can easily compare the contents of files. As a case study ofour protoype, we conducted a case study with four Android products.

トが数多く生まれる．このようなソフトウェアを管理

1 はじめにする，ソフトウェアプロダクトラインエンジニアリン

ソフトウェア開発において，開発コストを削減する

グという概念があるが，既存のプロダクトにこの概念ためにソースコードの再利用は重要である．開発者を適応するためには，機能の共通部分と固有部分を理は，しばしば，既存ソフトウェアのソースコードをコ解する必要がある [1]．

ピーや編集を行ったり，ライブラリを取り込むことでソフトウェアの機能を理解するにあたって，ソー新しいソフトウェアを開発する [8] [12]．さらに，新たスコードの比較は重要である [9]．一般的に，Java のなソフトウェアを開発するために，既存ソフトウェアパッケージのように，ソフトウェアのディレクトリの必要な部分のみに機能の変更や追加を行う．この開は 1 つの機能を表すため，複数のソフトウェアをディ発方法は，“派生開発” と呼ばれる．

レクトリ単位で比較することは効果的である [2] [3]．

派生開発が進むことで，派生ソフトウェアプロダク

Duszynski ら [5] は，類似したソフトウェア間の対応しているディレクトリの比較を行う手法として，ソーA Tool Visualizing a Unified Directory Tree to Compare Similar Software
Yusuke Sakaguchi, Takashi Ishio, Tetsuya Kanda,
Katsuro Inoue, 大 阪 大 学 大 学 院 情 報 科 学 研 究 科 コ
ンピュータサイエンス専攻, Dept. of Computer Science, Graduate School of Information Science andTechnology, Osaka University.

スコードの共通部分の行数と固有部分の行数を可視化する手法を提案した．しかし，この手法を適用するには，比較を行う前に対応したディレクトリを知ることが必要となるが，類似ソフトウェア間でディレクトリの移動やリネームが行われた場合，対応を取ることは困難である．2 つのソフトウェア間でのディレクて，派生開発で作成された Linux カーネルを分析をトリの対応関係をとる手法 [7] [13] はいくつかあるが，実施した結果を報告している．

3 つ以上のソフトウェアを一度に比較する研究はなされていない．

Duszynski ら [5] は，ソフトウェアのソースコードから共通部分を区別し，可視化する手法を提案した．

本研究では，複数のソフトウェアのソースコードかこの可視化は，入力されるソフトウェアのディレクトら，それらのディレクトリ構造を単一のディレクトリリ構造が同一であることを前提としているため，移構造に統一し，可視化するツールを実装する．抽出さ動やリネームされたディレクトリを識別するために，れるディレクトリ構造は，元のソースコードに含まれディレクトリ構造を手動で調べる必要がある．

るディレクトリを全て含む．ディレクトリの移動やリ

Yoshimura ら [13] は，2 つの類似したソフトウェアネームが行われた場合でも，類似したファイルをもつをマージするために，コードクローン検出技術を用いディレクトリの対応関係を自動で判定することによて 2 つのソフトウェア間のディレクトリの対応付けをり，1 つのディレクトリにマージされる．このため，行った．この手法は，3 つ以上のソフトウェアを比較抽出されたディレクトリ構造上で開発者はコンテンツするために設計はされていない．Holten ら [7] は，2の比較を容易に行うことができる．

つのソフトウェアのディレクトリが，相互にどのようツールの入力はソフトウェアのソースコード，出力に対応しているかを可視化する手法を提案した．こは単一のディレクトリ構造である．ディレクトリ構造の手法は構造の違いの全体的な概観を示すことがでは一般に木構造として知られているので，各ソフトきるが，この手法も複数ソフトウェアの比較を目的

ウェアのディレクトリ構造を連結した有向グラフに変とはしていない．リネームされたファイルの追跡は，換し，そのグラフからスパニングツリーを抽出する．

Lavoie ら [10] によって提案されている．この技術は，このスパニングツリーをディレクトリ構造とみなし，ソフトウェアのバージョン間で最も類似しているソー専用のビューアにより可視化する．このビューアは一スファイルのペアを識別する．本研究では，ディレク般的なファイル管理ツールと同様に，ディレクトリ構トリ間でのファイル類似度を使用して，ディレクトリ造から 1 つのディレクトリを選択することで，そのの対応付けを行う．

ディレクトリに所属するファイルの一覧を表示する．

Lin ら [11] は，コードクローンの複数の特性に特化開発者は，一覧からファイルの類似度を調べることがしたソースコード比較ツールを提案した．ツールはでき，必要に応じて外部ソースコード差分ツールを用

ソースコードの部分的なコードクローンの共通点のいてファイルを比較することができる．

可視化をするが，ディレクトリレベルの類似性を見つ

ケーススタディでは，2 社の Android スマートフォけるツールではない．

ンの公開されたカーネルのソースコードを使用し，それらの比較作業を実施した．

3 統一ディレクトリ構造の抽出と可視化

以降，2 章では，研究の背景を述べる．3 章では，

本研究では，類似したソフトウェアのソースコード単一の統合されたディレクトリ構造を抽出し，可視化の構造を単一のディレクトリ構造に統一し，その可する手法を説明する．4 章でケーススタディを示し，視化を行う．提案手法の入力は，ディレクトリの集合

5 章でまとめを述べる．

R = {r1 , r2 , · · · , r|R| } とする．ここで ri は，1 つのソフトウェアのソースコードを含むディレクトリ構造

2 背景のルートディレクトリを表す．このディレクトリ集合

派生開発は一般的に行われている．Dubinsky ら [4]に対して，以下の 3 つのステップを実行することには，企業のソフトウェア開発者は既存ソフトウェアのソースコードをコピーする傾向にある，と述べている．Homel ら [6] は，コードクローン検出技術を用いより，統合されたディレクトリ構造を抽出する．

1. 類似したソースファイルを含むディレクトリの集合に対応するノードを生成する．

2. ソフトウェアのサブディレクトリ関係を表す重s1

み付き辺でノードを接続する．

3. 得られたグラフから，有向スパニングツリーをs3

src

src

src抽出する．
得られた有向スパニングツリーが求めるディレクトリs2ac構造であり，これを可視化するビューアを作成した．

a

このビューアは，ディレクトリ構造内のソースファイbルを比較する機能を備えている．

図1bcab

入力ソフトウェアのディレクトリ構造の例

3. 1 ディレクトリ構造の統一なるディレクトリに格納されていたとすると，それぞ開発者が，複数ソフトウェア間の類似したソースれのコンポーネントに対応する 3 つのノード na, nb,

ファイルを比較できるようにするために，類似したnc が以下のようにディレクトリに対応付けられる．

ファイルを含むディレクトリの集合を表現するノード

D(na)

=

{s1/src/a, s2/src/a, s3/src/a}を生成する．2 つのディレクトリの内容の類似度を表

D(nb)

=

{s1/src/a/b, s2/src/b, s3/src/b}

すメトリクスとして，sim(d1 , d2 ) を導入する．ここ

D(nc)

=

{s1/src/c, s2/src/c}

で，d1 と d2 は，それぞれ異なるソフトウェアのディディレクトリの類似度をそこに所属するファイルレクトリである．sim(d1 , d2 ) が予め設定した閾値 thの類似度によって定義したが，ソフトウェアのソース以上である場合，d1 と d2 を単一のノードで表現す

コードの管理には，ファイルを持たないディレクトリ

る．sim(d1 , d2 ) ≥ th かつ sim(d2 , d3 ) ≥ th であっも使用されている．例えば，多くの Java プログラムても sim(d1 , d3 ) ≥ th となるとは限らないが，それの src ディレクトリは，Java パッケージ名を表すサでも開発者がディレクトリ間の差異を分析できるようブディレクトリしか含まない．そこで，このようなに，これら全てのディレクトリを同じノードに割り当ファイルを持たないディレクトリについては，サブてる．以降，ノード n によって表されるディレクトディレクトリが同一ノードで表される場合，それらのリの集合を D(n) と表現する．

ディレクトリを単一のノードに割り当てる．言い換え

2 つ の ディレ ク ト リ の 内 容 の 類 似 度 を 表 す

ると，2 つのディレクトリ d1 , d2 が，単一のノード nsim(d1 , d2 ) は，以下のようにジャッカード類似度に割り当てられている時 (d1 , d2 ∈ D(n))，それらのによって定義される．

親ディレクトリ dp1 , dp2 は共通の親ノードに割り当

sim(d1 , d2 ) =|L(d1 ) ∩ L(d2 )||L(d1 ) ∪ L(d2 )|ここで，L(d) は，ディレクトリ d に含まれるテキスてられる．図 1 の例のディレクトリ構造の場合，それぞれのソフトウェアのディレクトリ src が，たとえソースファイルを持っていなくても，単一のノードに割り当てられる．

トファイルの行の集合である（テキストかどうかは得られるグラフが連結グラフであることを保証すファイルの拡張子で判定する）．ソフトウェアによっるために，ソフトウェアの類似性に関わらず，全てのてソースコードのレイアウトが変更されたり改行文ルートディレクトリを表すルートノード r を設定す字が変更されたりする場合があるので，各行を取り出る．このルートノードが，抽出される統一されたディした時点で空白，改行文字を行中からすべて取り除いレクトリ構造のルートディレクトリとなる．て使用する．
例として，3 つのコンポーネント a, b, c で構成されている 3 つのソフトウェア s1, s2, s3 が入力された場合を考える．図 1 のように各コンポーネントが異ノードの生成が完了したら，それらのノードを重み付き辺で接続する．すべてのノードの組 n1 , n2 に対{r}, E = ϕ を生成する．V は，頂点の集合を
r: {s1, s2, s3}表し，E は，選択された辺の集合を表す．

32. t ∈ V, n ∈/ V を満たす最大の重み w(t, n) を持

nsrc: {s1/src, s2/src, s3/src}

つ辺 (t, n) を選択する．複数ある場合，r に最も3近いものを選択する．

na: {s1/src/a, s2/src/a, s3/src/a}2
2

nc: {s1/src/c, s2/src/c}

3. スパニングツリーに (t, n) を加える．すなわちV ← V ∪ {n}, E ← E ∪ {(t, n)} とする．

1

4. 全てのノードが V に含まれるまで，ステップ 2,nb: {s1/src/a/b, s2/src/b, s3/src/b}

3 を繰り返す．最終的に E がスパニングツリー
図2

図 1 の例から得られるディレクトリグラフの辺の集合となる．
このアルゴリズムによって，図 2 のグラフから図 3 のようなスパニングツリーを得ることができる．このr: {s1, s2, s3}

ツリーは，nsrc から na, nb, nc への辺を含み，na から nb への辺は含まない．従って，このスパニングツ

nsrc: {s1/src, s2/src, s3/src}

リーが表すディレクトリ構造は，s2 のディレクトリ構造と同じになる．ディレクトリ s1/src/a/b は，他

na:{s1/src/a,s2/src/a,sp3/src/a}nb:{s1/src/a/b,s2/src/b,s3/src/b}

nc:{s1/src/c,s2/src/c}の 2 つのソフトウェアの類似したディレクトリが srcのサブディレクトリに位置するため，src のサブディレクトリとみなされたことになる．

図3

図 1 の例から得られる統一ディレクトリ構造

3. 2 特定のソフトウェアの構造への統一して，それらの重みを以下のように計算する．

w(n1 , n2 ) = |{(d1 , d2 ) :

先に示したアルゴリズムは，入力されたすべてのソd1 ∈ D(n1 ) ∧ d2 ∈ D(n2 )フトウェアのディレクトリ構造を公平に扱う．そのた∧subdir(d1 , d2 )}|め，統一されたディレクトリ構造は，入力された全て

ここで， subdir(d1 , d2 ) は，d1 が d2 の直接の親ディのソフトウェアのディレクトリ構造のいずれとも異なレクトリであることを意味する．w(n1 , n2 ) > 0 である可能性がある．一方で，開発者が特定のソフトウェる場合，その重みを持つノード間の有向辺を作成す

アについて既に情報を持っている場合には，他のソる．ディレクトリを表すノードは必ずそのサブディフトウェアのディレクトリ構造をそのソフトウェアのレクトリを表すノードへの辺を持つことになるため，ディレクトリ構造に揃えて閲覧することも可能とした

ルートノード r からは全てのノードへ到達可能にない．そのために，特定のソフトウェア P が選択される．この手順の結果，例のディレクトリ構造は，図たとき，そのディレクトリ構造に統一できるように，2 のような有向グラフへ変換される．ディレクトリ b

以下のように辺の重みを拡張する．

∞
は，s1 では a のサブディレクトリであり，s2, s3 では src のサブディレクトリであるため，対応するノード nb にはそれらの関係を表現した 2 本の辺が接続されている．
辺の接続によって得られた有向グラフからスパニングツリーを抽出する．この抽出は，以下のような貪欲法の一種である．

1. 初 期 状 態 と し て ，ス パ ニ ン グ ツ リ ー V =w(n1 , n2 , P ) =if ∃d1 ∈ D(n1 ),d2 ∈ D(n2 ) :d ∈ P ∧ d ∈ P∧

12
subdir(d1 , d2 )w(n , n ) otherwise.
12

この関数を用いることで，目的のソフトウェアにおけるサブディレクトリの関係を表す辺は，スパニング示される．

ツリーを抽出する際に優先して選択される．そして，“移動した” ディレクトリ，すなわち，ディレクトその後に，他のソフトウェアに固有のディレクトリをリ名やルートからの経路が Tree View 上での見た目接続する辺が選択される．とは異なるディレクトリを含むノードには，ノードの名前の横にさらに “*” の印が付与される．

3. 3 ディレクトリビューア

3. 3. 2 File List View

統一されたディレクトリ構造を可視化する専用のFile List View は，選択したノード内に含まれるビューアを設計，実装した．このビューアは，統一さファイルの一覧を示す．複数のソフトウェアに存在すれたディレクトリ構造を扱うことができ，各ノードのるディレクトリの内容をまとめて表示するため，縦ディレクトリのファイルの内容の違いについて調べる

方向（１列目）にファイル名を一覧表示し，横方向をことができる．ツールのスクリーンショットを図 4 にノードに含まれるディレクトリに対応付けた表形式で示す．ツール上部に，ソフトウェアを指定しない状態表現する．それぞれのセルは，ディレクトリ内のファでの統一ディレクトリの表示と，特定のソフトウェアイルのハッシュ値を表す．その行に並ぶすべてのハッのディレクトリ構造に合わせた表示とを切り替える

シュ値が等しいとき，その値は灰色で表現される．黒選択ボタンがある．残りの領域は，ディレクトリ構造で描画された値は，ファイル間で異なる内容を持つこを示す Tree View，選択ノード内のファイルを示すとを表す．

File List View，各ソフトウェアのファイルの類似度異なる内容を持つファイルにすばやく注目できるよを示す File Matrix View の 3 つの領域からなる．

うに，この表は，ファイル名かハッシュ値の色によっ

3. 3. 1 Tree Viewてソートが可能である．

Tree View は統一されたディレクトリ構造を示す．

表に含まれるディレクトリのフルパス名は，リスト

各ノードは，抽出されたスパニングツリーのノードにの下に表記されている．このフルパス名をクリック対応しており，元となったソースコードの 1 つ以上すると，既定のファイル管理ツール（Microsoft Win-のディレクトリに対応する．それぞれのノードの名前

dows 環境では Explorer）でそのディレクトリが開かは，ノードに表現されているディレクトリ名を元にしれるので，開発者はすぐに必要なファイル操作を行うており，複数のディレクトリに対応するノードでは，ことができる．

最も多いディレクトリ名が選ばれる．

3. 3. 3 File Matrix View

ノードの名前の横に，それぞれのノードに含まれるFile Matrix View は，File List View から選択しディレクトリ数 x と，その内の変種の数 y を，(y inた同名のファイルの類似度を示す．行と列は，Filex) として示す．変種の数とは，互いに異なるファイ

List View のディレクトリの順に対応している．セル

ル内容を含むディレクトリ数のことである．例えば，(i, j) は，選択したディレクトリのファイル間の類似(2 in 3) とあるノードは，3 つのディレクトリを含む

度 sim(fi , fj ) を示す．各セルは，類似度 sim の値にが，そのうち 1 つが，他とは異なるファイル内容を持応じて白 (sim=1) から黄 (sim=0.5)，赤 (sim=0) のつことを表す．(1 in 3) とあるノードは，それらすべカラースケールで色づけされる．そのため，入力したてのディレクトリに同一の内容が含まれていることをソフトウェア間のファイルがどのくらい異なっている表す．変種の数は，ノードで表されるディレクトリにのかを確認することができる．

直接含まれるファイル内容を基にしていることに注

詳細を確認したい場合は，セルを 1 つ選択する意が必要である．たとえば (1 in 3) とあるノードのと，外部の比較ツール（本ツールの現在の実装ではWinMerge †1 ）を起動して対応するファイルの比較

各ディレクトリのサブディレクトリには，変更が行われている場合がある．2 つ以上の変種を含む（ソフトウェア間に何らかの変更がある）ノードは青文字で表†1 http://winmerge.org

図4

実装したビューアのスクリーンショット結果を可視化する．

ディレクトリ群を表現していた．
ディレクトリ /kernel （図 5）を見ると，内容が異4 ケーススタディなるファイルがいくつかあることがわかった．例えば，ツールの機能を確認するために，ケーススタディをSO-01F のファイル AndroidKernel.mk と Makefile

実装した．ツールの入力には，2013 年の第 4 四半期は，他の機種のものとは異なっている．Fujitsu 製品にリリースされた Android スマートフォン 4 機種のの Makefile は，互いに少しの変更があり，SO-01F公開されているソースコードを使用した．この 4 機種との類似度も 95.01%であった．一方，図 5 の Fileは，Fujitsu の 3 機種と Sony の 1 機種からなり，いMatrix View に示すように，AndroidKernel.mk のずれも CPU は Qualcomm MSM8974，Android の類似度は 40.52%であった．開発者は，カーネルビルバージョンも 4.2 と共通している．各機種の発売時期

ドのための特別な設定を，主にこのファイルで行っや規模の情報を表 1 に示す．ているということがわかる．F-01F の MAINTAINERS

この事前情報だけからでも，類似したソフトウェアは，他の製品とは異なっている．すべての製品は，同のバージョンを入力としたため，ほとんどのソース

じカーネルバージョンを使用しているが，F-01F のコードは共通であり，いくつか特定の部分が互いに異いくつかのファイルには非アスキー文字（たとえばウなっていると予測できる．さらに，ベンダーが異なるムラウトの付いた文字）が含まれていない．これは，SO-01F のいくつかのディレクトリとファイルが，他そのような文字が開発途中に何らかの理由で置換さの機種のものとは異なるとも予測できる．ケーススタれたと思われる．

ディでは，実装したツールを使用して，これらの製品のコードを実際に探索する．

Fujitsu の 3 機種のディレクトリ /vendor に含まれるファイルは，SO-01F の /vendor に含まれるもまず，4 つのソフトウェアをツールに入力すると，のとは全て異なっているので，それらのディレクト解析が実行された．ファイルの読み込み，ディレクトリは，統一されたディレクトリ構造で独立したノーリ間の類似度比較，統一されたディレクトリ構造の抽ドとして表された．同様に，/external/chronium

出に約 42 分を要した．類似度の閾値は，th = 0.8 とディレクトリも，SO-01F とは区別された．このディしている．

レクトリでは，例えば Android.mk というファイル得られた統一されたディレクトリ構造は，9,037が Fujitsu のソースコードからはなくなっていた．

ノードで構成されていた．そのうち 245 ノードは移

一方，/external/chronium の共通のサブディレク

動ないし名前が変更されたディレクトリを含んでいトリは 4 機種間でほとんど類似している．その結た．また，673 ノードが互いに異なるファイルを含む

果，共通のサブディレクトリは，Fujistu 側の機種に

表1

ケーススタディの入力一覧．すべて Android4.2 を搭載

製品名

ベンダー

通信事業者

発売時期

#Dirs

#Files#Lines

FJL22

Fujitsuau

2013/11

7,683

107,945

26,178,588

301F

Fujitsu

SoftBank

2013/12

7,708

108,334

25,629,778

F-01F

Fujitsu

NTT DOCOMO

2013/10

7,582

105,397

25,740,695

SO-01FSonyNTT DOCOMO

2013/10

5,840

90,73622,225,611

図5ツールで /kernel ディレクトリ内部の AndroidKernel.mk ファイルを選択した状態の画面対応する /external/chronium ノードのサブディレすることもできた．

クトリとして表示されていた．SO-01F に対応する/external/chronium は，SO-01F に固有のサブディ

5 まとめレクトリだけを保有した状態となっていた．

ソースコード比較は，ソフトウェア間の共通部分

ノード /external/llvm は，Fujitsu 製品の 6 つや固有部分を理解するために重要である．本研究での ディレ ク ト リ か ら 成 り，そ の う ち 3 ディレ ク ト

は，複数ソフトウェアの全てのディレクトリを含む，リは，/external/llvm，残りの 3 ディレクトリは統一されたディレクトリ構造を抽出する手法を提案/external/llvm/projects/sample であった．ディした．統一されたディレクトリ構造を可視化するためレクトリ sample が偶然にマージされてしまったののビューアを設計し，4 つの Android 製品に対しては，ファイル configure のような類似したファイルケーススタディを実施した．その結果，ツールがソフをもつためである．

トウェア間の異なるファイルの発見，比較を容易にす

ケーススタディでは，4 つの個別に公開されているることを定性的に確認した．

ソフトウェアが 1 つの製品であるかのように統一さ今後の課題としては，抽出された統一ディレクトリれたディレクトリ構造扱うことができ，そして，違い構造の質について評価を行うことが挙げられる．まを持つディレクトリに簡単に焦点を当てることがでた，実装したツールがソースコード比較のために有効きた．4 つの Android 製品のソースコードは，合計であるかどうかを，対照実験によって評価したい．

で 28,813 ディレクトリであったが，統一されたディレクトリ構造は，その全てを 9,037 ノードで表した．

謝辞 本研究は JSPS 科研費（課題番号 25220003，26280021）の助成を受けたものです．

ディレクトリが著しく異なるファイル内容を持つときは，それらは独立したノードとして表されるため，そ参 考 文 献のようなディレクトリについては詳細な分析を行わず[ 1 ] Bosch, J.: Maturity and Evolution in Software
Product Lines: Approaches, Artefacts and Organization, Proceedings of the 2nd Conference Software
Product Line Conference, 2002, pp. 257–271.
[ 2 ] de Jonge, M.: Multi-level component composition, Proceedings of the 2nd Groningen Workshopに済ませることができた．さらに，サブディレクトリは，親ディレクトリとは独立に対応関係が計算されるため，ディレクトリごとに個別に類似ファイルを比較Software Variability Modeling, No. 2004-7, 2004.
[ 3 ] de Jonge, M.: Build-level components, IEEE
Transactions on Software Engineering, Vol. 31,
No. 7(2005), pp. 588–600.
[ 4 ] Dubinsky, Y., Rubin, J., Berger, T., Duszynski,S., Becker, M., and Czarnecki, K.: An Exploratory
Study of Cloning in Industrial Software ProductLines, Proceedings of the 17th European Conference
on Software Maintenance and Reengineering, 2013,
pp. 25–34.
[ 5 ] Duszynski, S., Knodel, J., and Becker, M.: Analyzing the source code of multiple software variants
for reuse potential, Proceedings of the 18th Working
Conference on Reverse Engineering, 2011, pp. 303–307.
[ 6 ] Hemel, A. and Koschke, R.: Reverse Engineering Variability in Source Code Using Clone Detection: A Case Study for Linux Variants of Consumer
Electronic Devices, Proceedings of the 19th Working
Conference on Reverse Engineering, 2012, pp. 357–366.
[ 7 ] Holten, D. and van Wijk, J. J.: Visual Comparison of Hierarchically Organized Data, Proceedings of the 10th Joint Eurographics / IEEE - VGTC
Conference on Visualization, 2008, pp. 759–766.
[ 8 ] Kawamitsu, N., Ishio, T., Kanda, T., Kula,
R. G., De Roover, C., and Inoue, K.: Identifying
Source Code Reuse across Repositories using LCS-

based Source Code Similarity, Proceedings of the
14th International Working Conference on Source
Code Analysis and Manipulation, 2014, pp. 305–314.
[ 9 ] Krueger, C. W.: Easing the Transition to Software Mass Customization, Revised Papers from the
4th International Workshop on Software ProductFamily Engineering, 2002, pp. 282–293.
[10] Lavoie, T., Khomh, F., Merlo, E., and Zou, Y.:
Inferring Repository File Structure Modifications
Using Nearest-Neighbor Clone Detection, Proceedings of the 19th Working Conference on ReverseEngineering, 2012, pp. 325–334.
[11] Lin, Y., Xing, Z., Xue, Y., Liu, Y., Peng, X.,
Sun, J., and Zhao, W.: Detecting Diﬀerences acrossMultiple Instances of Code Clones, Proceedings ofthe 36th International Conference on Software Engeneering, 2014, pp. 164–174.
[12] Rubin, J., Kirshin, A., Botterweck, G., andChechik, M.: Managing forked product variants,
Proceedings of the 16th International Software
Product Line Conference, 2012, pp. 156–160.
[13] Yoshimura, K., Ganesan, D., and Muthig, D.:
Assessing Merge Potential of Existing Engine Control Systems into a Product Line, Proceedings ofthe International Workshop on Software Engineering for Automotive Systems, 2006, pp. 61–67.