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

OSS ベース開発のための由来と機能レイヤーに基づいたメトリクス可視化手法
礎 良輔

鷲崎 弘宣

深澤 良彰

井上 栄

華井 克育

金澤 昌信

難波 克司

複数組織が関わるソフトウェア開発, 例えば OSS (Open Source Software) をもとにしたプロジェクトではある組織が作成したプログラムのソースコードを別の組織が編集した場合などに多くの欠陥を含む傾向にある. 複雑な由来や機能レイヤーを伴った開発は OSS べースの開発においてますます増えている. 本稿ではその一例として Android
スマートフォン開発プロジェクトに注目し, ファイルの由来と機能レイヤーに基づいたプロダクトメトリクスの新しい可視化手法を提案する. 一つは図形の重なりを用いることで直感的に複数組織による編集の重複を表現できるメト
リクス領域図という手法である. もう一つは機能レイヤー, メトリクス測定値, ファイル数を 3D 空間の建物として同時に表現する Origin City という手法である.Origin City は Code City という過去の関連研究に大きな影響を受けている. 本稿の貢献はそれらの新しい可視化手法の提案, その Web アプリとしての実装, この手法に関するアンケー
ト実験の結果の共有である. ここで提案する手法はメトリクス測定値の可視化だけでなく, 製品の品質の改善にも役立つことが明らかとなった.

Software developments involving multiple organizations such as, like OSS (Open Source Software)-based
projects, tend to have a lot of numerous defects when one organization develops the program source code
files and another organization edits the program source code filesthem.when editing program source code
files that other organizations created. Developments with complex file s creation, and modification history(origin), and software architecture (functional layer) are increasing in OSS-based development. As an example, here we focus on an Android smart phone development project and propose new visualization techniques
for product metrics based on the file origin and functional layers. One is the Metrics Area Figure, which
can express duplication of edits by multiple organizations intuitively using overlapping figures. The otheris Origin City, which was inspired by Code City. It can represent the scale and other measurements, while
simultaneously stacking functional layers as 3D buildings. The contributions of our paper are to propose
new techniques, implement them as web applications, and share the results of our questionnaire experiment.
Our proposed techniques are useful not only to visualize measured metrics, but also to improve productquality.

1 はじめに複数のグループや組織が関わるソフトウェア開発
ではソースファイルの由来や機能レイヤーの分類がMetrics visualization technique based on the origins
and function layers for OSS-based development
This is an unrefereed paper. Copyrights belong to
the Author(s).
Ryosuke Ishizue, Hironori Washizaki and Yoshiaki
Fukazawa, 早稲田大学理工学術院情報理工学科, Dept.
of Computer Science and Engineering, Waseda
University.
Sakae Inoue, Yoshiiku Hanai Masanobu Kanazawa
and Katsushi Namba, 富士通コネクテッドテクノロ
ジーズ, Fujitsu Connected Technologies Limited.

ますます複雑になってきている. そのような開発プロ
ジェクトの例として本研究が注目している Andoird
スマートフォン開発でもしばしばそのような問題に直面する. なぜなら Android のベースは OSS としてプ
ラットフォームを提供する組織が開発し, 様々な開発組織がそれを使用している. そのような複数組織が関わる開発ではどの組織がプログラムのソースコードを作成し, どのファイルを編集したかに注目することが重要となる. なぜなら複数の組織が編集したファイルは欠陥を多く含む傾向にあるからである [1]. さらにそれらのファイルがどの機能レイヤー (例, Kernel,

Driver, Framework, Application, etc.) に属するかを知ることも重要となる.
初めに, 本研究で用いる用語を定義する.
定義 1 由来 (origin): あるファイルがどの組織によって作成・変更されたかを表す.(この用語は過去の研究で定義されたものである [1])定義 1 機能レイヤー (function layer ): ソフト
ウェアの構造に基づいた機能ごとの分類. 本研究では基本的なソフトウェアアーキテクチャとして layerarchitecture を想定している [2].
過去の研究ではファイルの作成と変更の履歴をもとに由来 (origin) という概念を定義した [1]. ここに機能

図1

Android スマートフォンプロジェクトにおける由来

レイヤーの分類が加わることで開発はより一層複雑で困難になる. そのためファイルの由来と機能レイヤー

Platformer の合計=O1 + O12 + O13 + O123 ), 全体にを把握することは欠陥を回避するためにも役に立つ.

対して別の組織が手を加えたファイルの割合, それらのさらに, プロダクトメトリクスは由来や機能レイヤー

比較は難しい. これらの問題を解決するために, 本研究に基づいているため, この情報は製品の品質の改善に

ではメトリクス領域図 (Metrics Area Figure:MAF)もつながる.

と呼ぶ手法を提案する.MAF はメトリクス測定値を本研究で注目している Android スマートフォン開由来に対応した図形の重なりを用いて表現する.

発の例では Platformer,Chipset Vendor,Fujitsu Con-

メトリクスの測定値を 2D だけでなく 3D で可視

nected Technologies(FCNT) の 3 社が関わっている化する研究も過去に多くあった.3D の可視化によって(図 1). 例えば, O1 , O2 と O3 はそれぞれ Platformer,

2D の可視化よりも多くの情報を持たせることができ

Chipset Vendor,FCNT が作成したファイルが分類さる. 特に有名な可視化手法に Code City がある.Code

れる. 一方 O12 は Platformer が作成し Chipset Ven-

City はソフトウェアの規模やメトリクス測定値を 3D

dor が編集したファイルを意味する. また機能レイヤーの街並みとして表現する [2][3]. 本研究では Code Cityは Android のアーキテクチャーとして知られている以から着想をえた Origin City(OC) という手法を提案

下の 7 つを用いた.(1) Linux Kernel, (2) Library, (3)する.OC は由来ごとのメトリクス測定値を機能レイ

Android Runtime, (4) Library (外部 OSS), (5) Ap-

ヤーごとに色付けして 3D の建物として表現する.

plication Framework, (6) Applications, (7) その他.

本研究の貢献は製品の品質の改善に役立つ 2 つのこのように機能レイヤーや由来などの要素を持った可視化手法 (MAF,OC) を提案したことである.MAF

複雑なソフトウェアのレビューをするとき, それぞれ

は由来を示すのに役立ち,OC は機能レイヤーを示すのファイルのメトリクス測定値を表や棒・円グラフなのに役立つという特徴がある.

ど素朴な手法のみで理解することは難しいという問題がある. 過去にはこれらの問題に取り組んだ研究も存

2 可視化手法

在する [4] [5]. 例えば, メトリクス測定値の中で最大値

本研究では 2 つの可視化手法を HTML5 の Canvas

はどのレイヤー, 由来にあるかは単純な表でもわかる.

と JavaScript によって実装した. 図 2 がシステムのしかし, その組織全体のメトリクス測定値の合計 (例：

概要となる. はじめに, ユーザーはメトリクスの測定

結果を csv ファイルで用意する. 可視化のためのこれ
らの解析は Understand などの静的解析ツールを用形に近い形状で同一組織が含まれるものはお互
いに接触するように生成される.

いる. またファイルパスから機能レイヤーの分類は可MAF は図形の重なりによって複数の組織の編集の能となる (例 kernel/*.* なら kernel レイヤー) . ファ

重複を直感的に表す.N 組織の MAF を生成するため

イルを組織別のディレクトリに分類し,diﬀ コマンドには, まず円を一つ配置する. この円の面積は由来がなどを利用することで由来は特定する. これらを csv

x1 = 1 のファイルの合計メトリクス測定値に相当す

ファイルに加えたものを可視化ツールのデータアップ

る. 次にもう一つ円を配置する. こちらの面積は由来

ロードフォームより送信しサーバーのデータベースにが x2 = 2 のファイルの合計メトリクス測定値に相当加工したデータを格納する. 最後に, ユーザーは可視する.2 つの円は重なる面積が x1 = 1, x2 = 2 のファ化手法と対象データ選択し, グラフの生成を実行する

イルの合計メトリクス測定値に相当するように配置ことでブラウザ上に可視化された図・グラフが表示さする. 次にもし 3 ≤ N ならば以下の手順を n ≤ N のれる.

間繰り返す.

N 組織の場合の MAF と OC の生成手順を以下に

1. もっと も 多 く の 領 域 に 囲 ま れ た 交 点 を 一 つ示す.MAF,OC にはそれぞれ 2N − 1 個の領域・建物

選 ぶ. 囲 む 領 域 は Ox1 ···x(n−1) ま で が あ り えが生成される. それぞれの領域・建物は Ox1 ···xn ···xNる.(例:n = 3 なら O1 , O2 , O12 がありえる.)で表される由来に対応する. 式中の N は組織の数,n2. 選択した交点からそれぞれの領域に向かって新は特定の組織を表している.xn はその由来に組織しい領域を拡張していく. 新しい領域は拡張方向

n が関わっていれば n, そうでなければ 0 の値をとの領域の由来に xn = n を加えた由来に対応し,り,xn = 0 の場合は省略される. 例えば 5 つの組織

拡張する領域はその由来のメトリクス測定値の合が存在する場合に O124 は次のように定義される.

計に相当する.(例:n = 3 なら O13 , O23 , O123 , O3

N = 5 : Ox1 x2 x3 x4 x5 {x1 = 1, x2 = 2, x3 = 0, x4 =がありえる.)

4, x5 = 0} = O124

3. 2n − 1 の領域を生成した後に n を 1 増やす.

この例は組織 1 が作成し, 組織 2 と組織 4 が変更を加上記の手順で全ての領域を配置・生成することで N

え組織 3 と組織 5 は関わっていないファイル, の由来

組織の MAF を生成する. 図 3 は 3 組織の MAF の例を表している。

を示している. 赤色の円は一つ目の組織 (O1 ) によっ

しかしながら, 本研究で提案する可視化手法, 特にて作成されたファイルのメトリクス測定値の合計を表

MAF は数組織から十数程度の由来を想定している. なしている. 緑色の円は二つ目の組織 (O2 ) によって作ぜならばあまりにも多くの領域が存在した場合, ユー

成・編集されたファイルのメトリクス測定値の合計を

ザーを混乱させてしまうと考えられるからである.

表している. 一方で, 青色の図形は三つ目の組織 (O3 )によって作成・編集されたファイルのメトリクス測定

2. 1 メトリクス領域図

値の合計を表している. 青色の図形が円でないのは数

MAF は以下の特徴を持つ。

学的に不可能なためである.

1. 一つの領域は一つの由来を表す.
2. それぞれの領域の面積はその由来のメトリクス
測定値と等しい.

3. それぞれの組織はその組織を表す特有の色を持つ.

4. それぞれの領域はその由来に関わる組織特有の色を混ぜた色を持つ.

5. 各領域の形状は決まっていないが, 円形や長方

この図形を生成するためにはまず, 赤色の円を塗り,次に緑色の円を塗る. このとき, ２つの円の交わる領域 (O12 ) は黄色で塗る. 次に円と円の交点の一つから外側に向かって青色の図形を塗る. 同様にして紫色(O13 ), 水色 (O23 ), 灰色 (O123 ) の図形をそれぞれの領域に向かって塗る.

図2

可視化ツールの概要の積み重なりを同時に 3D の建物として表現する.OCは 3D 空間に 2N − 1 棟の建物として描かれる. それぞれの建物が由来に対応している. また建物の高さはメトリクス測定値を表している. さらに建物の色は機能レイヤー毎のメトリクス測定値の比で塗り分けられている.

OC を生成するためはじめに建物同士の位置関係を決める. まず N 組織の場合は O1 , O2 , · · · , ON の建物を同心円上に配置する. その後,Oxa xb ···xn (1 ≤ a <b < · · · < n ≤ N, xa = a, xb = b, · · · , xn = n) に対
図3

メトリクス領域図

応する建物は Oa , Ob , · · · , On の建物を結んだ図形の重心に配置していく. 例えば O12 は O1 と O2 を結ん

2. 2 Origin City

だ直線の中点に,O123 は O1 , O2 , O3 を結んだ三角形

OC は以下の特徴を持つ。

の重心に,O1234 は O1 , O2 , O3 , O4 を結んだ四角形の

1. 一つの建物は一つの由来を表す.

重心に配置される. 全ての建物の配置が決まった後,

2. 建物の底面積はその由来の規模を表す (例では中心から順に図形を実際に配置していく. 中心からのファイル数を用いている).

3. 建物はそれぞれが機能レイヤーを表す複数の層で構成される.

4. それぞれの層は機能レイヤーを表す固有の色を持つ.

5. それぞれの層の高さはその由来における機能レ
イヤーごとのメトリクス測定値と等しい.

OC はファイル数, メトリクス測定値, 機能レイヤー

半径はそれぞれの建物がお互いに衝突しないように決定する. 上記の手順によって N 組織の OC は生成される.
図 4 に 3 組織の OC を示す. 中心は O123 に対応している. 外側には O1 , O2 , O3 の建物がある.O12 の建物は O1 と O2 の間にあることがわかる.O13 , O23 も同様に配置されている.

図4

Origin City表している. このような分析は多くの欠陥と由来を直

3 実験

感的に把握することを容易にする.

本研究では Android スマートフォン開発プロジェ

図 6 は MAF の別の例を示している. 左右の図はそクトに対してこれらの可視化手法を適用することでれぞれ同じ Android スマートフォン開発プロジェク

その効果を確認した.

トの異なる時点のデータを可視化した結果を示している. 右の図は左の図より新しいデータを使用している.

3. 1 実験対象と可視化結果

またこの例のメトリクス測定値はコード行数を用い本研究では提案する手法を任意の開発時点の状況ている. 緑色の円は左より右の図の方が大きいことがを可視化する場合, あるいは過去の開発と比較する場わかる. これは Android のバージョンがアップデート

合に効果的と推測している. また, そのような状況のされたことの影響を反映している. さらに Platformer

比較はマネージャーなどの役職にとって必要である.

と Chipset Vender の円が重なる領域は左より右のほ

そこで, 本研究の手法を Android スマートフォンプロ

うが小さいが, 赤色の円はほとんど同じ大きさになっ

ジェクトに適用しそれら効果を検証する. この例ではていることがわかる. このように MAF は開発者が過3 組織が関わっている.

去のプロジェクトのレビュー時に効果的な分析の手法

1. Platformer
2. Chipset Vendorとして用いられる.
図 7 はメトリクス測定値として欠陥数を表

3. Fujitsu Connected Technologies（FCNT)す OC の 例 を 示 し て い る. 建 物 の 底 面 積 か ら

図 5 の MAF は欠陥数を示している. 大きな青色のPlatformer(O1 ),Chipset Vendor(O2 ) は FCNT(O3 )領域は FCNT が作成したファイルの欠陥数が大きい

より多くのファイルを作成していることがわかる. さことを表している. さらに赤色と緑色の円はほぼ他のらに O123 の底面積は O13 とほとんど同じだが, その高色で塗りつぶされている. これは FCNT が他組織がさは 10 倍程度となっている. これは O13 より O123 の作成したファイルに編集を加えた欠陥数が多いことを方が欠陥の割合が大きいことを表している. また O13

図7

図8
図5

Origin City の例

Origin City の例 (旧モデル (左) 新モデル (右))メトリクス領域図の例の建物の色は黒色と赤色が大半を占めているが,O123の建物の色は紫色と水色が大半を占めている. これは

O13 は低いレイヤー (Kernel や HW Library) に欠陥が多く,O123 は高いレイヤー（APP や FW）に欠陥が多いことを表している.
このような分析によって, 由来や機能レイヤー, 欠
陥の数などのメトリクス測定値を同時に直感的に把握することが容易になる. 結果として開発者はそのよ
図6

メトリクス領域図の例 (旧モデル (左) 新モデル

(右))うなファイルを注意して編集するべきだと気づくことができる.
図 8 は図 6 と同じデータについて OC を適用した
例を示している.O2 の建物は左より右の方が大きく,高くなっていることがわかる. これも Android のバー
ジョンが更新された影響を反映している. さらに左側

の O1 には黒色のレイヤーが多く存在しているが, 右側の O1 には黒色のレイヤーはほとんどなく,O2 に多くの黒色のレイヤーが存在していることがわかる.OCはこのように過去のプロジェクトの比較やレビュー,
分析の手法として用いられる.
開発者にとって由来, 機能レイヤーに基づいたメト
リクス測定値を分析することは MAF や OC を用いることでずっと容易になる.MAF は複数組織の由来に基づいたメトリクス測定値を用いての分析が困難であるという問題を図形の重複を用いた表現によって解決する. 同様に,OC は色分けされたレイヤーの積み重なりによって複雑な由来と機能レイヤーの問題を解決する.

3. 2 有用性についての実験設定
本研究では２つの可視化手法について Android ス
マートフォンプロジェクト開発者に対して調査を実施
した.2 つの可視化手法はどちらもプロジェクトマネー
ジャーや開発チームリーダーなどの上級職の開発者

図9

全体の回答

が過去のプロジェクトのレビュー, 現在のプロジェク
トとの比較の場面でより有用であると推測している.

した.Q14 から Q17 は表, 円・棒グラフ,MAF,OC の

この仮説を検証するために以下の研究課題 (Research

どの手法が, それぞれの目的に最も適していると思う

Questions:RQ) について調査, 実験を実施した.

かを選択する形式とした.

RQ1. MAF は開発時に由来を意識するのに役立
つかRQ2. OC は開発時に機能レイヤーを意識するのに役立つか

RQ3. 提案する可視化手法は製品の品質を改善する

今回の実験は作成したアンケートを 18 人の An-

droid スマートフォン開発プロジェクト参加者に対して実施した. 参加者はマネージャー, 開発チームリー
ダー, メンバーの 3 役職であり, さらに設計, レビュー,
テスト, 実装など様々な業務に関わっていた.

のに役立つかRQ4. 提案する可視化手法の目的は何か

3. 3 有用性についての実験結果

RQ5. 提案する可視化手法を役立つを思うのはどの

図 9 と表２は結果の概要を示している. 図 10,11 お

ような人か
これらの研究課題に答えるため, 本研究では提案しよび 12 は参加者の役職毎に集計した結果を示している.

た可視化手法についてのアンケートを作成・実施した.

RQ1:Q5 から Q7 は 70%から 80%の回答者が本研

表１は質問項目の一覧を示している. メトリクス,

究の提案する新しい可視化手法を由来に基づいたメト

由来, 機能レイヤーについての 13 個の意識調査と, どリクスの意識改善に役立つと思う, と回答した結果をの可視化手法がどの目的に適しているかについての示している.Q7 より予想通り, 多くの人が MAF は由4 つの質問を実施した.Q1 から Q13 の回答はそう思来を理解するのに役立つ, と回答した結果を得られた.

う, どちらかと言えばそう思う, どちらかと言えばそRQ2:Q4 はそれまで機能レイヤーを意識していう思わない, そう思わない, の 4 段階評価の選択式とた開発者は 50%以下であることを示している. 一方

表1

質問一覧

Q

質問文

1

これまでの開発時に普段から

由来

を意識

して開発をしていましたか？

2

これまでの開発時に普段からメトリクスを意識して開発をしていましたか？

3

これまでの開発時に普段からリクス

4

由来毎のメトを意識して開発をしていましたか？

これまでの開発時に普段からメトリクス

レイヤー毎のを意識して開発をしていましたか？

5

由来領域図を用いることでこれまでより来

6

由を意識した開発に役立つと思いますか？

由来領域図を用いることでこれまでよりトリクス

メを意識した開発に役立つと思いますか？

7

由来領域図を用いることでこれまでより
来毎のメトリクス

由を意識した開発に役立つ

図 10

マネージャーの回答と思いますか？

8

Origin City を用いることでこれまでより メトリクスを意識した開発に役立つと思いますか？

9Origin City を用いることでこれまでより レイヤー毎のメトリクスを意識した開発に役立つと思いますか？

10

由来領域図を用いることでこれからの品質の改善に役立つと思いますか？

11

Origin City を用いることでこれからの品質の改善に役立つと思いますか？

12

由来領域図はあなたの普段の業務に役に立つと思いますか？

13

Origin City はあなたの普段に役に立つと思
いますか？

14

どの手法が詳細な値の把握に最適だと思いま
すか？

15

どの手法が傾向の大枠の把握に最適だと思い
ますか？

16

どの手法が機能レイヤーごとの値の把握に最適だと思いますか？

17

どの手法が由来ごとの値の把握に最適だと思
いますか？

図 11

開発チームリーダーの回答たことだが, 由来ごとの割合の把握は OC と MAF が同率一位で適しているという結果を得られた (Q17).
これらの結果は本研究で提案する手法は由来とメト
リクスレイヤーに基づいたメトリクス測定値の可視化にとても効果的であるということを示している.

RQ5:図 10,11 および 12 は回答者の役職別の結果を示している. マネージャーは開発チームリーダーより,
リーダーはメンバーよりも積極的な回答が多い結果であることがわかる. ゆえに, 提案する手法はマネジ
メントに効果的であると推測できる. なぜならば, 一
般的にマネージャーは開発チームリーダーより, リー
ダーはメンバーよりもマネジメントに関わる業務により多く携わっているからである.

3. 4 妥当性への脅威
このアンケート実験は開発者に対しての本稿でここまで説明したものと同じようの説明とデモを行った
図 12
表2

Q

後に実施した. ゆえに, 開発者が実際に日々の業務に開発チームメンバーの回答

おいてこの可視化ツールを用いた後に質問した場合

目的別の最適な可視化手法についての回答

結果が異なる可能性が考えられる. これは内的妥当性への脅威である.

回答者数 [人]表

円・棒グラフ

MAF

OC

またこれらの結果は一組織の一グループに対して

14

11

5

0

0

実施したものである. 参加者の中には既にメトリクス

15

1

5

7

3

や由来, 機能レイヤーなどについて馴染みのあるもの

16

1

2

3

10

もいた. もしこの実験を全員が由来という概念を知ら

17

1

1

6

6

ない, 別組織, 別グループに対して実施した場合結果が異なる可能性が考えられる. これは外的妥当性へので,Q8,Q9 より 70%から 80%の人が新しい可視化手脅威である.

法は機能レイヤーに対する意識の改善に役立つと感じた, という結果を得られた.

4 関連研究RQ3:Q10,Q11 より回答者の半分以上が 2 つの可視最後に由来と Code City, メトリクスの可視化ソフ

化手法は製品の改善に役立つと思う, と回答したとい

トウェアについての関連研究について述べる. 佐藤はう結果を得られた.

複数組織によるソフトウェア開発プロジェクトに対

RQ4:表２より, 表, 円・棒グラフは詳細な値を把握して, 組織の移り変わりがプロダクトメトリクスと欠するためには本研究で提案する手法より役に立つ, と陥に与える影響に注目した [1] [8]. 彼らはオープンソー

いう結果であった（Q14). しかしながら傾向の大枠

スプロジェクトを分析し, ファイルの作成・編集の履の把握には MAF が最も適しているという回答者が歴とメトリクスの間の関係について調査した. 彼らは多かった (Q15). さらに, 予想通り, 約 6 割の回答者がファイルの作成・変更の履歴としてファイルの由来とOC は機能レイヤー毎の値の把握に適しているといういう概念を定義した. 本研究で提案する手法はこの概結果となった (Q16). また, これは予想していなかっ念に基づいている.

R. Wettel と M. Lanza は 3D の可視化手法を提案

報を持たせる必要となった場合の手法として考えらした. 彼らの提案した手法は街並みで表現するといれる.MAF と類似の手法は H. Byelas らが提案した.

うアプローチであった [6] [7].OC は Code City に影響

彼らは UML の共通要素を図形の重なりで表現し, コ

を受けている.Code City において建物や街の一角はンター図のような色分けを行い可視化した [17] [18].S.

パッケージ, クラスといったソフトウェアのコンテキ

Ducasse らは Distribution map という手法を提案しストを表現している. それらの建物の高さはメトリク

た [4].Disribution map はパッケージ, エレメンツ, プ

ス測定値を表している. それと比較して,OC は建物をロパティという要素を用いており, エレメンツ一つ一由来という単位で分けている. また, 機能レイヤーにつは正方形であり, プロパティに対応する色になり,よる色分けされた層の積み重ねの表現を用いている.

パッケージという枠の中で並ぶという可視化手法でソフトウェアの可視化についての研究は多くあある. エレメンツはソースファイルなど, パッケージ

る.P.Caserta らは 2D と 3D の可視化手法について調は Java のパッケージなど, プロパティは機能の種類,

査と評価を行った [9].3D の街並みによる可視化手法

メトリクスの値などを表す.MAF を対応させるならも短くない歴史がある.C. Knight らの Java のソース

エレメンツはソースファイル, プロパティが由来, パッ

コードを抽象的に可視化する Software World という

ケージは機能レイヤーなどの対応が考えられる. この手法は 3D 可視化手法の始まりの一つである [10]. レ

手法と MAF の明確な差は,MAF は図形の重ね合わ

イヤーという観点で OC と同様のアプローチのもの

せを用いていることで編集が重複するファイルなどに J. I. Maletic らの手法がある. 彼らは UML のクラ

Disribution map では表現が難しい部分に対応していス図を階層を持った 3D オブジェクトとして可視化しることが挙げられる.F. Buschmann らは Ownership

た [11]. T. Panas らは 3D City というソフトウェア

map という手法を提案した [5].Ownership map は gitのメンテナンスコストなどを街並みというメタファーなどのブランチ変遷の表現に似た可視化手法である.

で可視化する手法を提案した. 彼らの可視化手法ではファイル毎にそのファイルの所有者の変遷を所有者に危険なソースコードは古い・崩れかけの建物のよう対応した色で可視化している. この可視化手法の特徴に表現される [12]. このような手法は本研究で提案すははファイルの所有者 (作成者, 編集者) の変遷のようる可視化手法でも例えば欠陥の重要度などにもとづに連続した情報に可視化する点である. 一方で MAF

いての可視化などに適用することでより有用なもの

はある時点の情報のみを可視化する. またこの手法でとなる可能性が考えられる. 本研究で提案した手法

は同時に表現できる情報はファイル, 所有者 (色) だけ

は Web アプリとして実装したが F. Fittkau らの提だが MAF は由来, メトリクス測定値なども同時に表案した ExplorViz というプログラムの動的解析結果

現することができる.

を可視化する手法は WebGL を用いた Web アプリとして実装された [13] [14]. 由来に注目した本研究の手

5 おわりに法と比較すると, 彼らの手法はシステムを理解するた本研究では MAF と OC という 2 つの可視化手法

めにランドスケープレベル, 個々のアプリケーションを提案した. 前者はそれぞれの由来ごとのメトリクス

レベルのように複数視点での可視化手法を提案した.

測定値を把握するのに役立ち, 後者は機能レイヤーごレイヤーという共通点では K. Kobayashi らは SarFとのメトリクス測定値を把握するのに役立つ. これら

Map という特徴やレイヤーを可視化する手法を提案の新しい手法は素朴な手法 (例えば表, 棒・円グラフな

した [15]. また G. Langelier らは VERSO という手ど) よりも効果的であることが実験の結果からわかっ法を提案した. 彼らは建物の高さ, 色だけではなく角た. さらに多くの開発者たちが提案された手法は製品度というパラメータを用いて可視化を行った [16]. 色の品質を改善するだろうと感じたことを示していた.

を用いたという点は本研究の手法と共通し, 角度と今後は, これらの可視化手法が実際に製品の品質をいうパラメータを用いた点は可視化時にさらなる情改善するのか, 継続的な運用による実験を行い調査することを計画している. また作成した可視化ツールをさらに充実させることも計画している. 例えば, 現在の可視化ツールは Android の由来や機能レイヤーに対応する形で実装しているため, これを一般化すること, さらには現在 2 つの手法は独立しているが, 製品品質の管理や意思決定に役立つ様々な手法を実装したツールをひとまとめにしたダッシュボードのようなツールを作成するつもりである.
参 考 文 献[1] S. Sato, H. Washizaki, Y. Fukazawa, S. Inoue, H.
Ono, Y. Hanai, and M. Yamamoto, ”Eﬀects of organizational changes on product metrics and defects,”
APSEC 2013, 2013.
[2] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. 1996. Pattern-Oriented Software
Architecture, A System of Patterns. New Jersey:
Wiley.
[3] Android Interfaces and Architecture, available from https://source.android.com/devices/
index.html (2016.08.02)[4] S. Ducasse, T. Girba, & A. Kuhn. Distribution
map. ICSM 2006, 2006.
[5] T. Girba, A. Kuhn, M. Seeberger, & S. Ducasse.
How developers drive software evolution. In 8th IWPSE’05 (pp. 113-122). IEEE.
[6] R. Wettel and M. Lanza, Visualizing Software
Systems as Cities, VISSOFT 2007, 2007.
[7] R. Wettel, M. Lanza, and R. Robbes, ”Softwaresystems as cities: a controlled experiment,” ICSE
2011, 2011.
[8] R. Ando, S. Sato, C. Uchida, H. Washizaki,
Y. Fukazawa, S. Inoue, H. Ono, Y. Hanai, M.

Kanazawa, K. Sone, K. Namba, M. Yamamoto,”How Does Defect Removal Activity of Developer
Vary with Development Experience?,” SEKE 2015,
2015.
[9] P. Caserta, O. Zendra, ”Visualization of the Static
Aspects of Software: A Survey,” Visualization andComputer Graphics, IEEE Transactions on, On
page(s): 913 - 933 Volume: 17, Issue: 7, 2011[10] C. Knight and M. Munro, Virtual but visible
software, IEEE Int. Conf. on Info. Visualisation,
2000.
[11] J. I. Maletic, J. Leigh, and A. Marcus, Visualizing software in an immersive virtual reality environment, ICSE 2001, 2001.
[12] T. Panas, R. Berrigan, and J. Grundy, A 3D
metaphor for software production visualization,
IEEE Int. Conf. on Info. Visualisation, 2000.
[13] F. Fittkau, J. Waller, C. Wulf, and W. Hasselbring,
Live trace visualization for comprehending large software landscapes: The ExplorViz approach, VISSOFT 2013, 2013.
[14] F. Fittkau, A. Krause,and W. Hasselbring. ”Software landscape and application visualization for system comprehension with ExplorViz.” Informationand Software Technology (2016).
[15] K. Kobayashi, M. Kamimura, K. Yano, K. Kato,and A. Matsuo, ”SArF map: Visualizing softwarearchitecture from feature and layer viewpoints,”
ICPC 2013, 2013.
[16] G. Langelier, H. Sahraoui, and P. Poulin,
Visualization-Based Analysis of Quality for LargeScale Software Systems, ASE 2005, 2005.
[17] H. Byelas and A. Telea, Visualization of Areas ofInterest in Software Architecture Diagrams, Symp.
Software Visualization, 2006.
[18] H. Byelas and A. Telea,
Visualizing Metrics
on Areas of Interest in Software Architecture Diagrams, Proc. Pacific Visualization Symp., 2009.