開発履歴に基づく分散処理フレームワークとアプリケーション間の関係の構築過程の調査
2009SE157 松波直弘 2009SE308 山田翔平
指導教員：横森励士

はじめに1

ソフトウェアの保守工程ではシステムの現在の機能の維持，システムの変更への対応，現在の受け入れ可能な機能

ムワークにはモデル，コードパターンのような再利用可能な機構が含まれており，開発者は品質を維持しながら，独自の機能を備えたアプリケーションの開発期間を削減することができる．の改善，システム効率が容認できないレベルに落ちないよ

フレームワークに関連したクローン関係は 2 種類考えらう予防などの要求に対応するような作業が行われ，それにれる．ソフトウェアをフレームワークを用いて実現しよう

伴いソフトウェア自身は大きく成長していく．成長に伴いとしたとき，フレームワークの利用例を参考に，アプリケー

ソフトウェア内部の関係は複雑化し，把握が困難なものにション側でよく似たコードを用いて実現することがある．

なっていく．[1] では GUI フレームワークとそれを利用す

この場合，図 1 のような形でフレームワークとアプリケーるアプリケーション間の利用関係及びクローン関係についション間のクローン関係が生成する．もう一方は，フレーて，バージョンごとに調査を行い，開発を通してどのようムワークを利用しているコードを似た場面で同じように利に複雑化しているかを調査している．しかし，1 組の関係用することがある．この場合，図 2 のような形のクローンしか分析しておらず，分析として不十分であるとともに， 関係がアプリケーション側の部品間で生成される．本研究より詳細な分析が必要である．
では，それらの 2 種類のクローン関係に注目し，バージョ本研究では，[1] と異なるドメインのフレームワークとンを通してこれらがどのように解消されるか分析する．

して分散処理フレームワークに注目し，分散処理フレームワークとそれを利用するアプリケーション内部の関係が開発を通してどう複雑化しているかを調査する．さらに，フレームワーク利用初期に生成されたクローン関係がどのようなものか，それらがどのように解消されているかを調査することで，分散処理フレームワークを利用した開発において注意すべき点などを考察する．

2

背景技術

2.1

部品間の関係と部品グラフ

図 1 フレームワーク利用時に生じるクローン関係 1

一般的にソフトウェア部品とは，再利用できるように設計された部品とされている．それぞれの部品に注目すると，それらは互いに様々な関係を持っているといえる．例
えば変数の宣言，インスタンスの作成，メソッドの呼び出し，フィールドなどで利用関係 [2] を構築している．一方

図 2 フレームワーク利用時に生じるクローン関係 2で，類似したコード断片を共有している部品間にはコードクローンの関係が存在していると考えることができる．
本研究では，それらの関係を部品グラフとして表す．部
品グラフにおいて，頂点は各部品を表し，辺は部品間の関係を表す．以下ではクローン関係，利用関係を対象として２種類の部品グラフを紹介する．それぞれ２つの部品間に複数の関係が存在する場合でも１つの関係として扱う．部
品グラフでは，クローン関係を無向辺を使って表し，利用関係を有向辺を使って表す．

2.2

フレームワークとその利用によって生成されるクローン関係

3

部品間の関係調査に関する研究

3.1

先行研究

[1] では GUI フレームワークである JHotDraw とそれを利用するアプリケーションである JARP 間の関係について，バージョンごとに調査を行い，どのように変化しているか分析した．
アプリケーションからフレームワークへの利用関係を分析して得られた傾向として以下の２点が挙げられていた．

• フレームワーク側の各部品への入力辺はバージョンが近年のソフトウェア開発ではフレームワーク上にアプリ進むごとに増加し，入力辺の最大数も増加した．

ケーションを構築する手法が広く確立されている．フレー• アプリケーション側の各部品からの出力辺はバージョ

ンが進むごとに増加するが，出力辺の最大数には大きで，分散処理フレームワークにおける特徴を分析し，注意な変化が見られなかった．

するべき点などを考察する．分散処理フレームワーク特有

クローン関係を分析して得られた傾向として以下の 3 点が挙げられていた．

• フレームワーク内のコードをコピーペーストして生成するクローン関係が存在した．

• 図 3 のように，フレームワークを利用する部分をクラスとして分離したり，継承関係でまとめた上でクラス構造が構築されているクローン関係が存在した．

• 図 4 右のように，フレームワークを利用する部分がコピーされてアプリケーション内にクローン関係が広がるとあると推測しているが，それらの存在を確認するの特徴的な処理手順を考慮すると，GUI フレームワークでのクローン関係生成の傾向と違いがあると考えられる．
また，機能が実現可能であることを示すことが主な目的となるフレームワークの利用初期では，クローン関係が生成されやすいと考える．本研究では，この時期に生成されるクローン関係に着目して，フレームワークの利用初期にどのようなクローン関係が生成されやすいか，どう解消されるかを分析し，分散処理フレームワークを用いた開発におけるクローン関係に関するノウハウを取得する．

4.2

ことはできなかった．

調査方法

本研究では，フレームワークに関連したクローン関係と利用関係を調査する．利用関係の分析は Java のクラスとパッケージの依存関係のための分析ツールである

Classycle[3] を使用する．クローン関係の分析はコードクローン抽出ツールである CCFinder[4] を使用する．本研
究ではお互い 25 トークンより長い類似したコード断片を持っている場合，それら 2 つのファイルはクローン関係を構築しているとする．得られた結果から 2.2 節で説明したクローン関係を抽出する．

4.3
図 3 フレームワークの利用がまとめられたクラス構造

調査対象

本研究では実験に Java で書かれたオープンソースのソフトウェアを使用する．本研究では分散処理フレームワー
クとして Hadoop を選択した．Hadoop とそれを利用するアプリケーション間の関係を分析する．調査対象のアプリ
ケーションとして機械学習やデータマイニングを行うアプ
リケーションである Mahout，Web 検索ソフトウェアである Nutch を選択した．Mahout は 7 バージョンに関して分析を行い，Nutch は ver0.1.0 から 0.7.2 の Hadoop 未対

図 4 アプリケーション内に広がるクローン関係応分を除いた 12 バージョンに関して分析を行った．

53.2

先行研究の問題点

利用関係の分析結果
Mahout，Nutch を対象にそれぞれのアプリケーション[1] では，JARP と JHotDraw という単一の GUI フレー側の各部品がどれくらいフレームワーク側の部品を利用

ムワークとそれを利用するアプリケーション間の関係のしているか，フレームワーク側の各部品がどれくらいアプみ分析しており，分析として不十分である．複数のアプリリケーション側の部品から利用されているかを調査した．

ケーションとフレームワーク間の関係を調査，分析する必

図 5，図 6 は Mahout の利用関係の数の推移を表してお要がある．また，アプリケーションにおいてフレームワーり，それぞれフレームワーク側の各部品への入力辺の数のクを利用する初期段階でクローン関係がどう生成されてい推移，アプリケーション側の各部品からの出力辺の数の推るか，どう解消されているか分析されていないが，それら移を表している．フレームワーク側の各部品への入力辺のの情報は開発初期の指針として有益であると考えた．

数はバージョンを通して全体的に増加しており，クラス数4

分散処理フレームワークにおける部品間の関係の変化に関する分析や LOC が増加していくにつれて最大値も上昇した．一方

4.1

分析の目的

ら 0.7 にかけて利用関係が減少している点が存在した．まで，アプリケーション側の各部品からの出力辺の数は最大数が頭打ちした．Mahout では ver0.3 から 0.4，ver0.6 か

本研究では，分散処理フレームワークを対象に，フレーた，Nutch でも同様の傾向が得られ，フレームワーク側のムワークとアプリケーションの間に存在する利用関係の変各部品への入力辺の数がアプリケーション側の各部品から化を分析する．全体的な傾向や減少点などに着目することの出力辺の数が ver1.4.0 から 1.5.0 にかけて利用関係が減少している点が存在した．

図 7 フレームワークの利用がまとめられたクラス構造の構築

図 5 Mahout アプリケーション側の各部品からの出力辺の数の推移

図 8 継承元の利用クローン関係の分析結果

6

フレームワーク利用初期に生成されたクローン関係を分類した結果，次のようなクローン関係が得られた．Mahoutのフレームワークの利用初期に生成されたクローン関係を分析した．
図 6 Mahout フレームワーク側の各部品への入力辺の数

6.1

フレームワークを利用している部品間におけるクローン関係 (Mahout)の推移

Mahout のフレームワークを利用している部品間におけ以下に利用関係が減少した原因とその例を示す．

5.1(原因 1) Mapper，Reducer の変更

Mahout の ver0.3 か ら 0.4 に か け て DirichletMapper が org.apache.hadoop.mapred.Mapper か ら
org.apache.hadoop.mapreduce.Mapper を利用するようになり DirichletMapper の利用関係の数が減少した．
5.2

るクローン関係を分析した結果，以下の 3 種類のクローン関係が存在した．

6.1.1

分散処理の実行内容の記述部分におけるクローン分散処理の実行内容が規定されている場所が複数あり，その中で同一の設定が与えられた場合にクローン関係が生成した．図 9 のように Mahout の ver0.1 から 0.2 にかけて Hadoop の JobConf を利用していた部品がその継承元(原因 2) フレームワークの利用がまとめられたクラである Configuration を直接利用するようになった．これ

ス構造の構築によりアプリケーションの部品間に構築されていたクロー

図 7 の よ う に Mahout の ver0.3 か ら 0.4 に か け てン関係の一部が検出されなくなった．しかし，これらのク

BayesDriver，CBayesDriver がフレームワークを利用する部分を継承関係でまとめられて BayesDriver，CBayesDriver の利用関係の数が減少した．

ローンは本質的な解消が難しく，多くのクローン関係は解5.3(原因 3) 継承元の利用

図 8 のように Mahout の ver0.3 から 0.4 にかけて OutputUtil が JobConf を利用していたのをその継承元である Configuration を利用するように変更したことで，OutputUtil の利用関係の数が減少した．

5.4(原因 4) 消滅

消されなかった．

6.1.2

アルゴリズムに関するクローン

同一の目的を持つ複数のアルゴリズム内で類似した処理が現れることでクローン関係が生成した．Mahout のver0.6 から 0.7 にかけて Bayes，CBayes が NaiveBayesに移行したことにより Bayes，CBayes で構築されていたクローン関係は実質的に解消された．

6.1.3

コンバイナとリデューサに関するクローン

Mahout の ver0.3 から 0.4 にかけて MeanShiftCanopyClusterer の中のメソッド emitCanopy が消滅したことに複数あるコンバイナとリデューサにおいて，似た機能を提供しているのでクローン関係が生成した．Mahout のより，フレームワークの利用辺が消滅した．

ver0.6 から 0.7 にかけて FuzzyKMeans，KMeans におい

て Mapper，Combiner，Reducer が ClusterIterator に置頭打ちした．フレームワークとそれを利用するアプリケー換されたことにより FuzzyKMeans，KMeans で構築されション間の利用関係の減少した地点を調査することで，クていたクローン関係も消滅した．

ラス構造などがどのように整理されたかを追跡できる．

6.2

フレームワークとアプリケーション間のクローン関7.2

係 (Mahout)クローン関係

Mahout のフレームワークとアプリケーション間のク

Mahout，Nutch のクローン関係を調査した結果，Mahout の分析結果のように同じような機能を実現するためローン関係を分析した結果，以下の 2 種類のクローン関係に複数のアルゴリズムを使用していることでクローン関が存在した．

係が生成された例を確認した．これらのクローン関係は機

6.2.1

分散処理の実行内容の記述部分におけるクローン

6.1.1 節で示したようなクローン関係が生成され，同様な結果が得られた．

6.2.2

リデュース操作に関するクローンリデュースを実現するコードにおいて，ほぼ操作内容が同一であったのでクローン関係が生成した．Mahoutの ver0.1 から 0.2 にか けて BayesThetaNormalizerRe-ducer，BayesFeatureReducer，BayesWeightSummerReducer，CBayesThetaNormalizerReducer においてそれぞれの機能ごとに成長してクローン関係が解消した．

能の実現を主な目的とした場合には起こりうるものであるが，最終的には整理されるべきものである．実際に開発の進行につれて，これらのクローンは解消された．再設計するにあたりこれらのクローン関係をまとめておき，整理することによってクローンを解消することができると考える．しかし，分散処理の実行内容の記述部分におけるクローン関係は実行内容によって個々に異なるので解消は難しく，解消されない傾向があるものも存在するので注意が必要である．

8

おわりに本研究では，[1] と異なるドメインのフレームワークとして分散処理フレームワークに注目し，分散処理フレームワークとそれを利用するアプリケーション内部の関係が開発を通じてどう複雑化しているか調査した．利用関係に関して [1] と同じ傾向が得られた．クローン関係に関して，フレームワーク利用初期には実装優先で開発するので多く生成される傾向があるが，それらが開発が進むにつれてまとめられて解消されていく．その際，無理にクローン関係を解消すべきでないものも存在するので注意が必要である．フレームワーク利用初期には実装優先で開発してどのように動作するかを確認した上で再設計するというアプローチが実際のソフトウェア開発においてよく用いられ，有力な方法であると確認した．
図 9 分散処理の実行内容の記述部分におけるクローン

6.3

フレームワークに関連するクローン関係 (Nutch)

フレームワークを利用している部品間におけるクローン関係，フレームワークとアプリケーション間のクローン関係ともに 6.1 節と同様の分散処理の実行内容の記述部分におけるクローン関係が生成され，これらのクローン関係の解消は難しく，解消されなかった．

7

考察

7.1

利用関係

Mahout，Nutch の利用関係を調査した結果，分散処理フレームワークとそれを利用するアプリケーションの間でも [1] と同様にソフトウェアの成長に伴ってフレームワー
ク側の各部品への入力辺の数は単調に増加した．また，アプリケーション側の各部品からの出力辺の数は最大数が参考文献[1] R. Yokomori, H. Siy, N. Yoshida, M. Noro, andK. Inoue, ”Evolution of Component Relationships
between Framework and Application,” Journal ofComputers, Computer Society of The Republic ofChina, vol. 23, no.2, pp.61-79, 2012.
[2] I. Jacobson, M. Friss, and P. Jonsson, Software
Reuse, Addison-Wesley Professional, 1997.
[3] Franz-Josef Elmer, ”Classycle: Analysing Tools forJava Class and Package Dependencies,” http://classycle.sourceforge.net/, 2012.
[4] T. Kamiya, S. Kusumoto, and K. Inoue, ”CCFinder:
A multilinguistic token-based code clone detection
system for large scale source code,” IEEE Transactions on Software Engineering, vol. 28, no. 7, pp.654670, 2002.