ソースコードの類似性分析に基づくソフトウェア保守

ソースコードの静的解析による
ソフトウェア保守支援に関する研究
大阪大学大学院情報科学研究科
コンピュータサイエンス専攻井上研究室
小堀一雄
Department of Computer Science,
Graduate School of Information Science & Technology,
Osaka University
1
ソフトウェア保守とは

ソフトウェア保守とは
 納入後，ソフトウェアに対して加えられる，欠陥の修正，性能な
どの改善，変更された環境に適合させるための修正．[IEEE
Std 1219]

保守に関するコスト
 全ライフサイクルの3分の２を占める
 20年以上も保守を続けているシステムも存在する
ソフトウェア保守を支援したい
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
2
ソフトウェア保守の課題
 課題
 保守担当者に以下を理解させるのが重要である
1. どのように修正すべきか？
2. どこを（どこまで）修正すべきか？
 保守を難しくする要因
 社会基盤を担う重要なソフトウェアは、大規模化・複
雑化・ライフサイクルの長期化が進む
 保守期間中にドキュメント最新化が成されず、実際の
動作と乖離が発生
 保守のアウトソーシングやオフショアが進み、仕様決
定時の情報を持たない人が保守を担当
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
3
ソフトウェア保守を支援する方法

保守支援に関する様々な手段
 リバースエンジニアリング
 ソースコードから設計情報を抽出する
 回帰テスト
 修正することでデグレードした箇所を特定する
 ソースコード動的分析
 ソースコードの実行結果から振る舞いや特徴を分析
 動作環境とテストケースが必要
 ソースコード静的解析
 ソースコードの記述を分析して振る舞いや特徴を分析
 動作環境やテストケースは不要
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
4
ソースコード静的解析を用いたソフトウェア保守支援
ソースコード静的解析
ソースコード静的解析技術を利用してプログラムから抽出された
情報をもとに，プログラム保守の支援を目的として様々な解析が
行われている．代表的な例を以下に示す．


デバッグ支援


影響波及解析


メトリクス値化された部品の性質から再利用性や品質を評価
コピー部品の把握


再テストすべきテストケースを限定することで，テスト工程を効率化する
ソフトウェア部品の評価


プログラムスライスを用いることで，デバッグ対象を限定する
メトリクス計測された情報を配列化し，解析効率を上げる
理解支援

解析結果情報を選別の基準とし，大量の部品からの選別作業を支援する
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
5
研究の目的
本論文では、下記の2つのソースコード解析技術に着目し、保守や再利用における
支援を目的とした以下の解析手法の提案、提案手法を実現したツールの評価を行う．

プログラム保守支援を目的としたソースコード
解析手法の提案
 アクセス修飾子過剰性の解析手法
 ソフトウェア類似部品の高速な解析手法

手法を実現したツールの評価
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
6
研究対象とする課題①
「アクセス修飾子過剰性の解析」
保守の課題１：「どのように修正すべきか？」

課題の具体例
public class X {
private String str = null;
private void setString( ) { // ①
str = "hello";
}
public int getLength() { // ②
return str.length();
}
public int getCorrectLength() {
this.setString();
return this.getLength();
}
<開発者の想定する正しい手順>
① 初期値がnullである変数strにStringオ
ブジェクトを代入
② 変数strの文字列長を取得
外部からの呼び出しを想定したメソッド
に①→②の呼び出し順序を実装
getLength()のアクセス修飾子が
privateではなくpublic
外部から①を飛ばして②を直接実行可能
}
NullPointerExceptionの発生
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
7
研究対象とする課題①
「アクセス修飾子過剰性の解析」

既存研究の問題
 アクセス修飾子の過剰性に関しての詳細な研究はあまり無
い



アクセス修飾子のチェックのみ行い、適切さについて議論していない
アクセス修飾子の修正に関する支援が無い
privateにすべきメソッドやフィールドに関する警告を提示する
 privateのみでなく、全アクセス修飾子について過剰性を解
析・修正を支援する必要がある
アクセス修飾子過剰性の解析・修正を
支援する手法を提案する
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
8
研究対象とする課題②
「類似部品の高速な解析」
保守の課題２：「どこを(どこまで)修正すればよいか？」

課題の具体例
想定シナリオ「類似部品に存在する類似バグを修正したい」
1. 生産性を上げたい！
2. ネットやリポジトリに過去の部品が大量に蓄積されている
3. 再利用して素早く実装した（コピー＆ペーストによる類似部品作成）．
～しばらくして～
4. ある類似部品に修正・デバッグを行った．
5. 他の類似部品にも同じ修正・デバッグを行う必要がある．
6. 大量の既存部品から、いますぐ類似部品見つけたい！
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
9
研究対象とする課題②
「類似部品の高速な解析」

既存研究の課題
 文字列比較による類似測定手法が多い
 解析に時間がかかるため、解析対象が大規模化する場合、
バッチ処理的な運用が想定される。
 しかし、類似部品の検索対象は随時作成されていくため、現
在のリポジトリに対して即時に類似部品を発見したい。
ソースコード部品類似性の高速な
解析手法を提案する
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
10
博士論文構成と業績一覧の関連

博士論文構成
第１章
 第２章
 第３章
 第４章


はじめに
アクセス修飾子過剰性に関する研究 [1-1], [1-2], [2-1], [2-2]
ソフトウェア部品類似性に関する研究 [1-3], [1-4], [2-4]
むすび
業績一覧
主要論文
[1-1] 小堀一雄, 石居達也, 松下誠, 井上克郎: “Javaプログラムのアクセス修飾子過剰性分析ツールModiCheckerの機能拡張と
その応用例”. SEC journal, Vol.33, 2013.（学術論文，採録決定）
[1-2] D. Quoc, K. Kobori, N. Yoshida, Y. Higo and K. Inoue,: ModiChecker: Accessibility Excessiveness Analysis Tool for Java
Program, コンピュータソフトウェア, Vol.29, No.3, pp.212-218, 2012.（学術論文）
[1-3] 小堀一雄, 山本哲男, 松下誠, 井上克郎: “コードの静的特性を利用したJavaソフトウェア部品類似判定手法” ，電子情報通信学会
論文誌D，Vol.J90-D(4) , pp.1158-1160, 2007.（学術論文）
[1-4] Kazuo Kobori, Tetsuo Yamamoto, Makoto Matsushita, Katsuro Inoue: “Classification of Java Programs in SPARS-J”, International Workshop on
Community-Driven Evolution of Knowledge Artifact, Session 4-3, Irvine, CA, 2003.（国際会議録）
関連論文
[2-1] 石居達也, 小堀一雄, 松下誠, 井上克郎: “アクセス修飾子過剰性の変遷に着目したJavaプログラム部品の分析”, 情報処理学会研究報告 Vol.2013SE-180, No.1, pp.1-8, 2013. (国内会議録)
[2-2] Dotri Quoc，Kazuo Kobori，Norihiro Yoshida，Yoshiki Higo，Katsuro Inoue: “Modi Checker : Accessibility Excessiveness Analysis Tool for Java
Program”日本ソフトウェア科学会大会講演, Vol28, 6C-2, pp.1-7，2011. (国内会議録)
[2-3] 小堀一雄，山本哲男，松下誠，井上克郎: “メソッド間の依存関係を利用した再利用支援システムの実装”, 電子情報通信学会技術研究報告, SS200458, Vol.104, No.722, pp.13-18, 2005.（国内会議録）
[2-4] 小堀一雄，山本哲男，松下誠，井上克郎: “類似度メトリクスを用いたJavaソースコード間類似度計測ツールの試作”, 電子情報通信学会技術研究報告,
SS2003-2, Vol.103, No.102, pp.7-12, 2003. (国内会議録)
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
11
アクセス修飾子過剰性に関する研究
博士論文第２章
Department of Computer Science,
Graduate School of Information Science & Technology,
Osaka University
12
背景：アクセス修飾子

アクセス修飾子
 フィールド/メソッドへのアクセスを制限する修飾子(※)
 public,
protected, default(宣言なし),privateが存在
 過剰に設定すると不具合の原因となりうる
 過剰：アクセス可能な範囲
> 実際のアクセス範囲
アクセス修飾子
アクセス可能な範囲
public
あらゆる部品
protected
自身と同じパッケージに属する部品及
び自身のサブクラス
default(宣言なし)
自身と同じパッケージに所属する部品
private
自身と同じクラス
※本研究ではクラスのアクセス
修飾子については考慮しない
Department of Computer Science, Graduate School of Information Science
& Technology, Osaka University
13
アクセス修飾子過剰性を表すメトリクス
AE(Accessibility Excessiveness)

1.
フィールド/メソッドのアクセス修飾子を以下の３つに分類
適切：実際の被アクセス状況通りのアクセス修飾子が宣言されている（
表中緑色）
2.
AE：実際の被アクセス状況に比べて過剰に広いアクセス修飾子が宣言
されている状態（表中オレンジ色）
3.
NA(NoAccess)：どこからもアクセスされていない状態（表中黄色）
実際の被アクセス範囲に対応するアクセス修飾子
Public
Public
Protected Default
Private
NoAccess
pub-pub
pub-pro
pub-def
pub-pri
pub-na
pro-pro
pro-def
pro-pri
pro-na
x
def-def
def-pri
def-na
x
x
pri-pri
pri-na
現在宣言している Protected x
アクセス修飾子 Default
x
Private
x
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
14
アクセス修飾子過剰性の解析・自動修正ツール
ModiChecker
ModiChecker
入力：
MASU（既存のJava解析ツール
解析対象の
ソースコード群
ソースコードの内容・
呼び出し関係を解析する
必要なライブラリ
(.jarなど)
AST(抽象構文木)
データベース
フィールド/メソッドに宣言している
アクセス修飾子を抽出
フィールド/メソッドの
呼び出される範囲を抽出
アクセス修飾子の過剰性（AE）を抽出
MASU - http://sourceforge.net/projects/masu/
出力：
各フィールド/メソッドのAE種別
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
15
ModiCheckerの適用実験

目的
 複数のオープンソースにおける各AEの分布状況を確
認する

考察事項
 AEの原因別の数を確認する
 将来的な利用を想定したことによるAE
 自動生成によるAE
 設定ミスによるAE

対象ソフトウェア
 MASU(519 files, 10200 LOC)
 Ant 1.8.2 (1141 files, 127235 LOC)
 jEdit 4.4.1(546 files, 109479 LOC)
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
16
MASUに対する結果～各AEの割合～
35.7%
14.3%
JSSST11
2015/10/1
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
17
MASUに対する結果～考察～

AEであるフィールド
 総数（割合） : 280(35.7%)
1.
2.
3.
将来的な利用を想定 : 20
自動生成 : 255
設定ミス : 5
自動生成ツールによって、一律publicと設定されたフィールドが
多かった
 AEであるメソッド
 総数（割合） : 253(14.3%)

1.
2.
3.

将来的な利用を想定 : 181
自動生成 : 6
設定ミス : 66
Java Beanの使用上機械的にpublicと設定されたメソッド(setter/getter)
が多かった
JSSST11
2015/10/1
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
18
応用実験（１）概要
 目的：
• 先の実験で、ソフトウェアのある時点におけるAEの解析をおこ
なうことができた
• 次に、応用として、ソフトウェアの開発履歴を追ってAEの状態が
どのように遷移するか分析することで、AEを解析すべき契機に
関する情報を開発者に提案したい
 実験内容：
• バージョンアップ時に、アクセス修飾子が適切・AE・NAのう
ち、どの状態に遷移していくのか可視化する
 計測事項：全バージョンにおける状態遷移総数における、状態
遷移の種別ごとの割合を調査する
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
19
応用実験（１）実験対象

実験対象：7つのJavaプロジェクト（バージョン数があり、最近ま
で開発が行われていて、世の中で利用されているソフトウェア）
番号
プロジェクト名
バージョン番号
バージョン数
開発期間(年)
1
Apache Ant
1.1 ～ 1.8.4
23
2003～2012
2
Areca Backup
5.0 ～ 7.2.17
66
2007～2012
3
ArgoUML
0.10.1 ～ 0.34
19
2002～2011
4
FreeMind
0.0.2 ～ 0.9.0
16
2000～2011
5
JDT_Core
2.0.1 ～ 3.7
16
2002～2012
6
jEdit
3.0 ～ 4.5.2
21
2000～2012
7
Apache Struts
1.0.2 ～ 2.3.7
34
2002～2012
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
20
バージョン間における状態遷移


2バージョン間におけるフィールド/メソッドの状態遷移は以下を
状態遷移図で表現する
状態数：４


適切、AE、NA、なし（フィールド/メソッドが削除された状態）
状態遷移数：18

a~r
a,p
適切
d
e,q
j
なし
g m
k
b n
AE
f
h
l
o
c
NA
i,r
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
21
結果考察-メソッド状態遷移(単位:%)
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
22
応用実験（１）結果考察

フィールド/メソッドに共通して得られた知見
 一度、アクセス修飾子が設定されると、その後アクセス修飾子
が変更されるケースは少ない
 用途が変わる場合は、フィールド/メソッド自体を変更する傾向
にある

フィールドについて得られた知見
 アクセス範囲を明確にして作成されるものが大半

メソッドについて得られた知見
 作成時点ではアクセス範囲が定まっていないもの(NA)が多い
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
23
応用実験（２）概要
 目的：
• 先の応用実験（１）で、ソフトウェアの開発履歴を追ってアクセス
修飾子の状態がどのように遷移するか分析できた
• 次に、さらなる応用として、どのようなバージョンアップの際に
AEの変化が大きくなるのか分析することで、AE解析を行うべき
タイミングを提案したい
 仮説
• Major version up時にAEが大きく変化する
• 過剰なアクセス修飾子を設定されたフィールド・メソッドが追
加される
• Minor version up時にはAEはほとんど変化しない
• 一度作成されたAEは修正されることはない（先の応用実験結果）
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
24
Antの22バージョンにおけるAE変化量

仮説に合致しそうな結果を得たので検定を行う
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
25
応用実験（２）結果考察
フィールド：全AE・NAでMajorVU時とMinorVU 時の間
で有意差（有意水準0.05）がみられた
 メソッド：pub-pri,def-pri,def-na 以外のAE・NAについ
MajorVU 時とMinorVU 時の間で有意差（有意水準
0.05）がみられた

 上記のAEは他のAE・NAに比べて各バージョン間の値の変
化量が小さく，順位がタイとなる値が多かったためマン・ホイ
ットニーの U 検定では誤差が出やすい状況下にあった．
下記仮説を裏付ける結果が得られた
• Major version up時にAEが大きく変化する
• Minor version up時にはAEはほとんど変化しない
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
26
ソフトウェア類似部品に関する研究
博士論文第３章
Department of Computer Science,
Graduate School of Information Science & Technology,
Osaka University
27
研究対象とする課題②
「類似部品（Javaクラス）の高速な解析」

解決したい課題（その２）
「どこまで修正すればよいか？」

課題の具体例
想定シナリオ「類似部品に存在する類似バグを修正したい」
1. 生産性を上げたい！
2. ネットやリポジトリに過去の部品が大量に蓄積されている
3. 再利用して素早く実装した（コピー＆ペーストによる類似部品作成）．
～しばらくして～
4. ある類似部品に修正・デバッグを行った．
5. 他の類似部品にも同じ修正・デバッグを行う必要がある．
6. 大量の既存部品から、いますぐ類似部品見つけたい！
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
28
研究対象とする課題②
「類似部品の高速な解析」

既存研究の課題
 文字列比較による類似測定手法が多い
 解析に時間がかかるため、解析対象が大規模化する場合、
バッチ処理的な運用が想定される。
 しかし、類似部品の検索対象は随時作成されていくため、現
在のリポジトリに対して即時に類似部品を発見したい。
ソースコード部品類似性の高速な
解析手法を提案する
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
29
類似度メトリクス

2つの視点から類似度メトリクスを計測する
 トークン構成
 メトリクス：ソースコードにおける各トークンの出現数
 トークン＝予約語 + 記号 + 演算子 + 識別子
（96種）（49種）（9種）（37種）（１種） ※ jdk1.3の場合
 意味：ソフトウェア部品の表層的特徴を表す

複雑度



メトリクス：クラス内のメソッド数, サイクロマチック数（分岐の数）など
意味：ソフトウェア部品の構造的特徴を表す
数値比較のため、文字列比較に比べて解析コストの
低下が期待できる
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
30
類似判定法
トークン構成に関するメトリクスと複雑度に関するメトリクスの全てにおいて
部品AとBのメトリクス値差分があらかじめ設定した閾値以内になった場合
類似部品と判定する
分類
メトリクス
トークン構成
各トークンの出現数差分の和
／小さいほうの部品のトークン総数
複雑度
サイクロマチック数
0
メソッドの宣言数
1
メソッド呼び出し数
2
ネストの深さ
0
“class”トークン数
0
“interface”トークン数
0
閾値※
0.03
（※今回の実験で経験的に設定した値）
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
31
類似判定の効率化
1.
メトリクス計測時に、いくつかのメトリクス
でハッシュキーを作成する
ハッシュキー＝ 8bit
8bit
8bit
(24bit)
メトリクスA メトリクスB メトリクスC
2. 部品と、部品の持つメトリクス値から
作成したハッシュキーを対応させた表
を構築しておく
[
0.
0. 0]= null
・・
・
[ 10. 62.124]= 部品A
[ 10. 62.125]= 部品B，部品C
[ 10. 62.126]= null
・・
・
[255.255.255]= 部品Z
3. 新しく類似測定をしたい部品Pが追加される
 部品Pのハッシュキー＝[10.62.125]
 メトリクス[A,B,C]の閾値＝[0.0.1]
4. 残りの全メトリクスを用いた類似判定の
計算を行うのは、左下図の部品A，B，C
の3つのみに限定する
最終結果を変えずに解析コストを
下げることが可能
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
32
適用実験の概要

実験目的
 今回提案したメトリクス値比較による類似判定手法が、
従来の文字列比較による類似判定手法より解析コストが
低くなることを確かめる

実験内容
 同じソースコード群に対して、各手法を実装した２ツールに
よる類似判定を行った際の解析コストを比較する

比較するツール



既存の文字列比較を用いた類似度測定ツールSMMT
今回提案したメトリクス比較を用いた類似度測定ツールLuigi
実験対象のソースコード
 JDK1.3に属する431個のクラス
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
33
考察（解析コスト）
文字列比較を用いた類似度測定ツールSMMTの計算コスト：24.35（sec）
メトリクス値比較を用いた類似度測定ツールLuigiの計算コスト
ハッシュキーを構成する事前分類計算コスト
メトリクス
クラスタ数 (sec)
未使用
1
05.02
[C]
21
00.56
[ C,M ]
85
00.29
[ C,M,T ]
232
00.16
対象： JDK1.3
431クラス
解析コストは1/150になった
メトリクス値比較だけで1/5に低下
ハッシュキーにより、さらに1/30に低下
C：サイクロマチック数
M：宣言メソッド数
T : トークン構成メトリクス
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
34
むすび
博士論文第４章
Department of Computer Science,
Graduate School of Information Science & Technology,
Osaka University
35
まとめ

下記のソースコード静的解析技術を提案・評価した
1.
アクセス修飾子の解析手法



AEメトリクスを用いたアクセス修飾子解析手法を提案した
上記手法をツールModiCheckerに実装した
ModiCheckerの適用実験により、以下を示した



2.
AE・NAの解析・可視化を実現した
AEは一度作り込まれると、version upしても修正されず残る傾向にある
多くのAE・NAにおいて、major version upの方がminor version upより多く
のAEが発生する傾向にある
高速なソースコード類似度判定手法



メトリクス比較を用いた類似判定手法を提案した
上記手法をツールLuigiに実装した
Luigiの適用実験により、以下を示した

既存の文字列比較を用いた類似度測定ツールSMMTと比べて150倍の速
度をもつことを示した
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
36
今後の研究方針

アクセス修飾子解析手法
 AEが発生した原因をインタビューなどで調査する
 AEの発生を防ぐ開発環境を提供する
 外部からの利用を想定したAEを自動判別する
 テストケースも合わせてModiCheckerで解析する
 品質（バグ）とAEの関連性を分析する

類似判定手法
 現在、類似判定エンジンのみなので、単独のツールとし
て利用しやすいようにする
 各メトリクスの閾値の設定を簡単にできるようにする
 Java以外の言語への対応
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
37
発表おわり
ご清聴ありがとうございました．
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
38
以下、補足資料
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
39
業績一覧
主要論文
[1-1] 小堀一雄, 石居達也, 松下誠, 井上克郎: “Javaプログラムのアクセス修飾子過剰性分析ツール
ModiCheckerの機能拡張とその応用例”. SEC journal, Vol.33, pp.151-158, 2013.（学術論文）
[1-2] D. Quoc, K. Kobori, N. Yoshida, Y. Higo and K. Inoue,: ModiChecker: Accessibility Excessiveness
Analysis Tool for Java Program, コンピュータソフトウェア, Vol.29, No.3, pp.212-218, 2012.（学術論文）
[1-3] 小堀一雄, 山本哲男, 松下誠, 井上克郎: “コードの静的特性を利用したJavaソフトウェア部品類似判定手
法” ，電子情報通信学会論文誌D，Vol.J90-D(4) , pp.1158-1160, 2007.（学術論文）
[1-4] Kazuo Kobori, Tetsuo Yamamoto, Makoto Matsushita, Katsuro Inoue: “Classification of Java Programs
in SPARS-J”, International Workshop on Community-Driven Evolution of Knowledge Artifact, Session 4-3,
Irvine, CA, 2003.（国際会議録）
関連論文
[2-1] 石居達也, 小堀一雄, 松下誠, 井上克郎: “アクセス修飾子過剰性の変遷に着目したJavaプログラム部品
の分析”, 情報処理学会研究報告 Vol.2013-SE-180, No.1, pp.1-8, 2013. (国内会議録)
[2-2] Dotri Quoc，Kazuo Kobori，Norihiro Yoshida，Yoshiki Higo，Katsuro Inoue: “Modi Checker :
Accessibility Excessiveness Analysis Tool for Java Program”日本ソフトウェア科学会大会講演, Vol28, 6C-2,
pp.1-7，2011. (国内会議録)
[2-3] 小堀一雄，山本哲男，松下誠，井上克郎: “メソッド間の依存関係を利用した再利用支援システムの実装”,
電子情報通信学会技術研究報告, SS2004-58, Vol.104, No.722, pp.13-18, 2005.（国内会議録）
[2-4] 小堀一雄，山本哲男，松下誠，井上克郎: “類似度メトリクスを用いたJavaソースコード間類似度計測ツー
ルの試作”, 電子情報通信学会技術研究報告, SS2003-2, Vol.103, No.102, pp.7-12, 2003. (国内会議録)
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
40
はじめに
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
41
ソフトウェア保守とは

ソフトウェア保守とは


納入後，ソフトウェアに対して加えられる，欠陥の修正，性能などの
改善，変更された環境に適合させるための修正．[IEEE Std 1219]
「修正」と「ソフトウェア保守」の分類 [JISX0161:2008]
分類名
修正の
分類
ソフトウェア保守の
分類
是正保守
訂正
改良
予防保守
適応保守
完全化保守
緊急保守
定義
是正保守ソフトウェア製品の引渡し後に発見された問題を
訂正するために行う受身の修正
緊急保守是正保守の内，実施までシステム運用を確保する
ための，計画外で一時的な修正
予防保守引渡し後のソフトウェア製品の潜在的な障害が運
用障害になる前に発見し，是正を行うための修正
適応保守引渡し後，変化した又は変化している環境におい
て，ソフトウェア製品を使用できるように保ち続け
るために実施するソフトウェア製品の修正
完全化
保守
引渡し後のソフトウェア製品の潜在的な障害が故
障として現れる前に，検出し訂正するための修正
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
42
ソースコード解析

ソースコード解析の分類
 ソースコード静的解析
 ソースコードを実際に動作することなく解析を行うことで，性質や振る
舞い情報を抽出する技術
 ソースコードの中身を扱うため，網羅性の高い解析をすることが可能
 ソースコード動的解析
 ソースコードを動作環境上で実際に動作させ，その動作結果や動作
中のログなどを解析することで性質や振る舞い情報を抽出する技術
 マルチスレッド処理など，ソースコード静的解析では発見が難しい
振る舞いを解析することが可能
 網羅的な振る舞いを調べるには多くのテストケースが必要となる．

動作環境やテストケースの準備が不要であるため、
現場への適用が容易な「ソースコード静的解析」に
注目する。
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
43
研究対象とする課題①
「アクセス修飾子過剰性の解析」

解決したい課題（その１）
「過剰に広いアクセス修飾子をもつフィールド，メソッドに
関する理解支援」

課題の具体例
想定シナリオ：設計時に意図しなかった不正なメソッド呼び出し
対策の考察：
対策１：ドキュメントにプログラム内部構造を詳細に書く
→作成コスト、メンテナンスコストが大きすぎる
→膨大な資料を説明・理解するコストが大きすぎる
対策２：不正な呼び出しができないようにリファクタリングする
→不正な呼び出しの可能性がある箇所の特定が難しい
→設計時に想定した範囲より過剰に広い範囲からアクセスされる
フィールド・メソッドの解析・修正を支援したい
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
44
適用実験
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
45
ModiChecker適用実験の概要

実験の目的
 Validation
of our approach
 Quantitative analysis of AE Id in some software
systems
 Reasons
for excessive/unused fields/methods
(found by interviewing developers)
Reason 1 : Set for future use
Reason 2 : Created by other program(automatic code
generators or refactoring tools…) or accessed by other
programs(Java bean)
3. Reason 3 : Carelessness and immaturity
1.
2.

実験対象のソフトウェア

Industrial Software(341 Java files/ 64455 LOC)
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
46
適用実験結果（フィールド）
実際の被
アクセス
Public
Protected
Default
Private
NoAccess
Public
207
0
59
936
33
Protected
x
0
9
18
0
Default
x
x
4
5
2
Private
x
x
x
1123
5
宣言
AEであるフィールドの数
NAであるフィールドの数
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
47
適用実験結果（メソッド）
実際の被
アクセス
Public
Protected
Default
Private
NoAccess
Public
816
14
23
190
1005
Protected
x
13
36
48
9
Default
x
x
0
3
0
Private
x
x
x
488
4
宣言
AEであるメソッドの数
NAであるメソッドの数
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
48
適用結果の考察

AEもしくはNAのフィールド/メソッドの数は以下のとおり





AEであるフィールド : 1027
AEであるメソッド : 512
NAであるフィールド: 40
NAであるメソッド : 1018
NA(NoAccess)であるフィールド（40個）について内容を確認した結果



将来的な利用を想定したもの：8
外部からの利用を想定したもの：5
 serialVersionUID（直列化ランタイムからの使用を想定）
実際に未使用だったもの：27
 その内、潜在バグを伴っていたもの：5
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
49
Discussion

Validation of ModiChecker output
 Changed
all of the excessive access modifier
and deleted some unused fields/methods
 Modified programs were compiled and executed
without any error

Developer should look for the detailed result
and make decision to change/delete the
unused/excessive fields/methods
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
50
Antに対する結果～各AEの割合～
18.9%
35.5%
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
51
Antに対する結果～考察～

AEフィールド
 総数（割合） : 611(18.9%)
1.
2.
3.

AEメソッド
 総数（割合） : 1520(35.5%)
1.
2.
3.

将来的な利用を想定 : unknown
自動生成 : 0
設定ミス : unknown
将来的な利用を想定 : unknown
自動生成 : 0
設定ミス : unknown
AEメソッドの割合> AEフィールドの割合

java beanの制約上、実際のアクセス範囲に関わらず、getter, setterメソッドには機械的に
publicが設定されていた
2015/10/1
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
52
jEditに対する結果～各AEの割合～
24.1%
30.4%
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
53
jEditに対する結果～考察～

AEフィールド
 総数（割合） : 604(24.1%)
1.
2.
3.

AEメソッド
 総数（割合） : 981(30.4%)
1.
2.
3.

将来的な利用を想定 : unknown
自動生成 : 0
設定ミス : unknown
将来的な利用を想定 : unknown
自動生成 : 0
設定ミス : unknown
AEメソッドの割合> AEフィールドの割合
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
54
応用実験①
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
55
応用実験②
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
56
バージョン毎のフィールド/メソッド分類

AE以外の状態を2つにグループ化し，
計3つの状態を定義
③NA
①AE
宣言されてはいるが
どこからもアクセスされていない
アクセス可能な範囲が
実際のアクセス範囲より広い
Public
Protected Default
Private
NoAccess
pub-pub
pub-pro
pub-def
pub-pri
pub-na
Protected x
pro-pro
pro-def
pro-pri
pro-na
Default
x
def-def
def-pri
def-na
x
pri-pri
pri-na
Public
x
②適切
Private
x
x
アクセス可能な範囲と
実際のアクセス範囲が一致
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
57
応用実験概要
分析１：プロジェクト開発履歴における各状態遷移の出現頻度分析
• 目的：バージョンアップの際にAEであるアクセス修飾子の修正
がどれ程の頻度で行われているのかを明確にする
• 計測データ：全バージョン間での(各種状態遷移総数÷全状態遷移総数)
分析2：プロジェクト開発履歴における各AEの修正状況分析
• 目的：AEの種類ごとに，修正頻度に差異がみられるかどうかを
明確にする
• 計測データ：修正されたAE数 ÷ 全バージョン内のAE総数
 データの取得にはアクセス修飾子過剰性検出ツール
ModiCheckerを利用
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
58
バージョン間での状態遷移の分類(2/2)
グループ対応する記号性質
AE修正
a,b,c
アクセス修飾子の変化によりAE修正
適切→適切はアクセス修飾子が変化したもののみ
AE発生
d,e,f
アクセス修飾子の変化によりAE発生
AE→AEはアクセス修飾子が変化したもののみ
アクセス消失
g,h,i
アクセス修飾子の変化によりアクセスが消失
NA→NAはアクセス修飾子が変化したもののみ
フィールド/メソッド
作成
j,k,l
バージョンアップにより新たに作成
フィールド/メソッド
削除
m,n,o
バージョンアップにより削除
変化なし
p,q,r
バージョンアップ前後で変化がない
適切，AE，NAそれぞれ1状態ずつ
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
59
バージョン間での状態遷移の分類(2/2)
グループ対応する記号性質
AE修正
a,b,c
アクセス修飾子の変化によりAE修正
適切→適切はアクセス修飾子が変化したもののみ
AE発生
d,e,f
アクセス修飾子の変化によりAE発生
AE→AEはアクセス修飾子が変化したもののみ
アクセス消失
g,h,i
アクセス修飾子の変化によりアクセスが消失
NA→NAはアクセス修飾子が変化したもののみ
フィールド/メソッド
作成
j,k,l
バージョンアップにより新たに作成
フィールド/メソッド
削除
m,n,o
バージョンアップにより削除
変化なし
p,q,r
バージョンアップ前後で変化がない
適切，AE，NAそれぞれ1状態ずつ
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
60
分析1結果-Antにおけるフィールド状態遷移
0.02,71.42
6.41
適切
0.03
2.03
なし
0.46
0.21
0.04 0.16
1.41
0.07,15.28
AE
0.13
0.02
0.00
NA
0.00,2.28
0.03
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
61
分析１結果-フィールド状態遷移(単位:%)
<フィールド作成>
「適切」で作成される場合が最も多い
変化なし(p,q,r)→全体の約53～97%
変化なし(適切)→全体の約36～71%
<AE修正，AE発生，アクセス消失>
アクセス修飾子の修正を伴う遷移は全体の1%に満たない
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
68
分析１結果-メソッド状態遷移(単位:%)
<メソッド作成>
比較的「NA」で作成される場合が多い
変化なし(p,q,r)→全体の約51～96%
変化なし(NA)→全体の約25～55%
<AE修正，AE発生，アクセス消失>
アクセス修飾子の修正を伴う遷移は全体の1%に満たない
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
69
結果考察-フィールド状態遷移(単位:%)
<フィールド作成>
「適切」で作成される場合が最も多い
変化なし(p,q,r)→全体の約53～97%
変化なし(適切)→全体の約36～71%
<AE修正，AE発生，アクセス消失>
アクセス修飾子の修正を伴う遷移は全体の1%に満たない
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
70
結果考察-メソッド状態遷移(単位:%)
<メソッド作成>
比較的「NA」で作成される場合が多い
変化なし(p,q,r)→全体の約51～96%
変化なし(NA)→全体の約25～55%
<AE修正，AE発生，アクセス消失>
アクセス修飾子の修正を伴う遷移は全体の1%に満たない
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
71
分析２結果-フィールドAE修正状況(単位:%)
AEが修正される割合はAEの種類に関わらず0.2%に満たない
pub-def,pub-pri → 全7プロジェクトにて修正作業が行われている
pro-def,pro-pri,def-pri → 6プロジェクトにて修正作業が行われている
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
72
分析２結果-メソッドAE修正状況(単位:%)
注： × ・・・全バージョンにて一度も出現しなかったことを表す
AEが修正される割合はAEに関わらず高々0.2%に満たない
pub-def,pub-pri → 全7プロジェクトにて修正作業が行われている
pub-pro,pro-pri → 6プロジェクトにて修正作業が行われている
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
73
結果考察-フィールド状態遷移(単位:%)
<フィールド作成>
「適切」で作成される場合が最も多い
変化なし(p,q,r)→全体の約53～97%
変化なし(適切)→全体の約36～71%
<AE修正，AE発生，アクセス消失>
アクセス修飾子の修正を伴う遷移は全体の1%に満たない
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
74
結果考察-メソッド状態遷移(単位:%)
<メソッド作成>
比較的「NA」で作成される場合が多い
変化なし(p,q,r)→全体の約51～96%
変化なし(NA)→全体の約25～55%
<AE修正，AE発生，アクセス消失>
アクセス修飾子の修正を伴う遷移は全体の1%に満たない
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
75
ソースコードの静的特性を用いた
Javaプログラム間類似度測定ツールの
試作
Department of Computer Science,
Graduate School of Information Science & Technology,
Osaka University
76
背景
ソフトウェア開発効率を飛躍的に
向上するための手法として、再利
用が注目されている
インターネットの普及により大量の
ソースコードが比較的容易に入手
可能となった
再利用とは既存の類似ソフトウェ
ア部品を参照し，一部手直しをし
て用いること
再利用を活用するためには，過去に開発さ
れた類似なソフトウェア部品に関する情報
を入手することが必要
これらのソースコードは，開発者にとって
有益な再利用部品である可能性がある
ソフトウェアを収集して
再利用部品検索システムを構築
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
77
背景
ソフトウェア開発効率を飛躍的に
向上するための手法として、再利
用が注目されている
インターネットの普及により大量の
ソースコードが比較的容易に入手
可能となった
再利用とは既存の類似ソフトウェ
ア部品を参照し，一部手直しをし
て用いること
再利用を活用するためには，過去に開発さ
れた類似なソフトウェア部品に関する情報
を入手することが必要
これらのソースコードは，開発者にとって
有益な再利用部品である可能性がある
ソフトウェアを収集して
再利用部品検索システムを構築
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
78
背景
ソフトウェア開発効率を飛躍的に
向上するための手法として、再利
用が注目されている
インターネットの普及により大量の
ソースコードが比較的容易に入手
可能となった
再利用とは既存の類似ソフトウェ
ア部品を参照し，一部手直しをし
て用いること
再利用を活用するためには，過去に開発さ
れた類似なソフトウェア部品に関する情報
を入手することが必要
これらのソースコードは，開発者にとって
有益な再利用部品である可能性がある
ソフトウェアを収集して
再利用部品検索システムを構築
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
79
背景
ソフトウェア開発効率を飛躍的に
向上するための手法として、再利
用が注目されている
インターネットの普及により大量の
ソースコードが比較的容易に入手
可能となった
再利用とは既存の類似ソフトウェ
ア部品を参照し，一部手直しをし
て用いること
再利用を活用するためには，過去に開発さ
れた類似なソフトウェア部品に関する情報
を入手することが必要
これらのソースコードは，開発者にとって
有益な再利用部品である可能性がある
ソフトウェアを収集して
再利用部品検索システムを構築
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
80
SPARS-J（1/2）

利用実績に基づくソフトウェア部品検索システム
SPARS-J
（Software Product Archiving, analyzing ,and Retrieving System for Java）
システムの特徴
対象：Javaプログラムソースコード
利用実績に基づいた評価値(Component Rank*)を計算し，利用実績によるランク
付けを行う事で，利用実績の高い部品を，ユーザに提供可能
* Katsuro Inoue, Reishi Yokomori, Hikaru Fujiwara, Tetsuo Yamamoto, Makoto Matsushita, Shinji Kusumoto:
"Component Rank: Relative Significance Rank for Software Component Search", to be appeared in Proceedings
of 25th International Conference on Software Engineering (ICSE 2003), Portland, Oregon, 2003.
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
81
SPARS-J（2/2）

Component Rankの計算では，部品間のコピー関係を把握するた
めに類似度を測定している


類似部品を一つの部品群として扱い，利用関係を合成する
評価値にコピー関係を反映させることが可能
B
D
類似
B
D
合成
部品A
C
+
部品A´
E
F
部品群A
C
E
F
これまでは，ソースコードの文字列比較を行う事で，類似部品を判定していた
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
82
ハッシュ関数を用いた解決法

ハッシュ関数 h(Ttotal) を用いた加工
 ｜h(Ttotal)
－ h(Ttotal×0.97)｜≦ １
 ｜h(Ttotal×1.03) － h(Ttotal)｜≦ １

log1.04（Ttotal）
h(Ttotal)
6
5
4
3
2
1
Ttotal
Ttotal
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
83
ハッシュ関数を用いた解決法

ハッシュ関数 h(Ttotal) を用いた加工
 ｜h(Ttotal)
－ h(Ttotal×0.97)｜≦ １
 ｜h(Ttotal×1.03) － h(Ttotal)｜≦ １
h(Ttotal)
6
5
4
3
2
1
Ttotal×0.97
Ttotal×1.03
Ttotal
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
84
ハッシュによる類似判定の効率化

現状の問題点
類似判断には９６（トークン構成）＋６（複雑度）＝１０２種類のメトリクスを
用いて比較を行っている。
新しい部品が入ってきた場合、全部の既存部品と102種類のメトリクスの
比較を行なわないとならない

アイデア
下記のような部品を比較対象から除外することで、さらに高速化できないか？
1. トークンの総出現回数が0.97倍未満 or 1.03倍超である部品
2. 複雑度メトリクスが閾値を超える部品

実現方法
最終的な類似判断結果に直接影響を与えるメトリクス（＝主メトリクス）を
キーとしたハッシュを利用し、事前に分類をしておく．
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
85
類似判定の効率化
メトリクス計測時に、いくつかの主メト
リクスでハッシュキーを作成する

ハッシュキー＝ 8bit
8bit
8bit
(24bit)
主メトリクス主メトリクス主メトリクス
A
B
C
ハッシュキーと既存登録部品を
対応させた表を構築しておく
[
新しく類似測定をしたい部品Pが追加される
 部品Pのハッシュキー＝[10.62.125]
 主メトリクス[A,B,C]の閾値＝[0.0.1]
0. 0]= null
・・
・
[ 10. 62.124]= 部品A
[ 10. 62.125]= 部品B，部品C
[ 10. 62.126]= null
・・
・
[255.255.255]= 部品Z
102種のメトリクスを用いた類似判定の
計算を行うのは、部品A，B，Cの3つのみ
とする
最終結果を変えずに解析コストを
下げることが可能
0.
DB
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
86
ハッシュ関数を用いた解決法

ハッシュ関数 h(Ttotal) を用いた加工
 ｜h(Ttotal)
－ h(Ttotal×0.97)｜≦ １
 ｜h(Ttotal×1.03) － h(Ttotal)｜≦ １
h(Ttotal)
6
5
4
3
2
1
Ttotal
Ttotal
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
87
ハッシュ関数を用いた解決法

ハッシュ関数 h(Ttotal) を用いた加工
 ｜h(Ttotal)
－ h(Ttotal×0.97)｜≦ １
 ｜h(Ttotal×1.03) － h(Ttotal)｜≦ １
h(Ttotal)
6
5
4
3
2
1
Ttotal×0.97
Ttotal×1.03
Ttotal
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
88
ハッシュ関数を用いた解決法

ハッシュ関数 h(Ttotal) を用いた加工
 ｜h(Ttotal)
－ h(Ttotal×0.97)｜≦ １
 ｜h(Ttotal×1.03) － h(Ttotal)｜≦ １
h(Ttotal)
6
5
4
3
2
1
Ttotal
Ttotal
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
89
ハッシュ関数を用いた解決法

ハッシュ関数 h(Ttotal) を用いた加工
 ｜h(Ttotal)
－ h(Ttotal×0.97)｜≦ １
 ｜h(Ttotal×1.03) － h(Ttotal)｜≦ １
h(Ttotal)
6
5
4
3
2
1
Ttotal×0.97
Ttotal×1.03
Ttotal
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
90
ハッシュ関数を用いた解決法

ハッシュ関数 h(Ttotal) を用いた加工
 ｜h(Ttotal)
－ h(Ttotal×0.97)｜≦ １
 ｜h(Ttotal×1.03) － h(Ttotal)｜≦ １
h(Ttotal)
h(Ttotal)は，閾値1の主メトリクスとして機能する
6
5
4
3
2
1
Ttotal
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
91
実験結果
SPARS-Jの類似度測定部「Luigi」として実装
文字列比較を用いた類似度測定ツールの計算コスト：24.35（sec）
主メトリクス
類似クラスタ
最終クラスタ計算コスト(sec)
未使用
1
278
05.02
[C]
21
278
00.56
[ C,M ]
85
278
00.29
[ C,M,T ]
232
278
00.16
[
C：サイクロマチック数
M：宣言メソッド数
T : f(Ttotal)
0. 0]= null
・・
・
[ 10. 62.124]= 部品A
[ 10. 62.125]= 部品B，部品C
[ 10. 62.126]= null
・・
・
[255.255.255]= 部品Z
対象： JDK1.3
431クラス
0.
DB
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
92
実験結果
SPARS-Jの類似度測定部「Luigi」として実装
文字列比較を用いた類似度測定ツールの計算コスト：24.35（sec）
主メトリクス
類似クラスタ
最終クラスタ計算コスト(sec)
未使用
1
278
05.02
[C]
21
278
00.56
[ C,M ]
85
278
00.29
[ C,M,T ]
232
278
00.16
C：サイクロマチック数
M：宣言メソッド数
T : f(Ttotal)
対象： JDK1.3
431クラス
トークン構成度+複雑度の両方で類似と判定され、
最終的に類似と判定された部品群の数
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
93
実験結果
SPARS-Jの類似度測定部「Luigi」として実装
文字列比較を用いた類似度測定ツールの計算コスト：24.35（sec）
主メトリクス
類似クラスタ
最終クラスタ計算コスト(sec)
未使用
1
278
05.02
[C]
21
278
00.56
[ C,M ]
85
278
00.29
[ C,M,T ]
232
278
00.16
C：サイクロマチック数
M：宣言メソッド数
T : f(Ttotal)
対象： JDK1.3
431クラス
類似度の測定精度を落とすことなく
効率だけが上がっている
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
94
実験結果
SPARS-Jの類似度測定部「Luigi」として実装
文字列比較を用いた類似度測定ツールの計算コスト：24.35（sec）
主メトリクス
類似クラスタ
最終クラスタ計算コスト(sec)
未使用
1
278
05.02
[C]
21
278
00.56
[ C,M ]
85
278
00.29
[ C,M,T ]
232
278
00.16
対象： JDK1.3
431クラス
メトリクス比較により，コストは1/5
C：サイクロマチック数
M：宣言メソッド数
T : f(Ttotal)
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
95
実験結果
SPARS-Jの類似度測定部「Luigi」として実装
文字列比較を用いた類似度測定ツールの計算コスト：24.35（sec）
主メトリクス
類似クラスタ
最終クラスタ計算コスト(sec)
未使用
1
278
05.02
[C]
21
278
00.56
[ C,M ]
85
278
00.29
[ C,M,T ]
232
278
00.16
対象： JDK1.3
431クラス
メトリクス比較により，コストは1/5
C：サイクロマチック数
M：宣言メソッド数
T : f(Ttotal)
ハッシュキーにより，コストは1/30
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
96
SPARS-J（2/2）

Component Rankの計算では，部品間のコピー関係を把握するた
めに類似度を測定している


類似部品を一つの部品群として扱い，利用関係を合成する
評価値にコピー関係を反映させることが可能
類似
部品A
+
合成
部品A´
⇒
部品A
部品群A
これまでは，ソースコードの文字列比較を行う事で，類似部品を判定していた
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
97
Ttotalをハッシュキーに適応するときの問題
点
 類似判定の条件
トークンの差分が
diff(A,B)
＜ 0.03
min(Ttotal（A）, Ttotal（B）)
Ttotal =30 ⇒
Ttotal =150 ⇒
29～31
[
[
0. 0]= null
・・
・
[ 10. 62. 29]= 部品A
[ 10. 62. 30]= 部品B，部品C
[ 10. 62. 31]= null
・・
・
[255.255.255]= 部品Z
Ttotalの3％以内
0.
DB
[
[
[
[
[
[
[
[
[
[
[
0.
0.
145～155
0]= null
・
・
・
10. 62.145]= 部品A
10.
10.
10.
10.
10.
10.
10.
10.
10.
10.
62.146]= null
62.147]= null
62.148]= 部品B
62.149]= 部品C
62.150]= 部品D，部品E
62.151]= null
62.152]= 部品F
62.153]= null
62.154]= 部品G
62.155]= 部品H,部品I
DB
・
・
・
[255.255.255]= 部品Z
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
98
類似度判定法（トークン構成メトリクス）
部品Xのトークン構成メトリクス：（Xm1,・・・,Xm96)
96
部品X の全トークン数：
Ttotal（X）
＝
∑ ( Xm )
k
k=1
96
部品A,Bの各トークンの差分の和：
diff(A,B)
＝
∑(
Amk
Bmk
)
k=1
■部品Aと部品Bの非類似度
D(A,B)
diff(A,B)
min(Ttotal（A）, Ttotal（B）)
（※今回の実験で経験的に設定した値）
D(A,B) ＜ 0.03 ならA,Bは類似と判定
※
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
99
Overview of Experiment(1/2)

Objectives of experiment
 Validation
of our approach
 Quantitative analysis of AE Id in open source
code
 Reasons
1.
2.
3.
for excessiveness
Reason 1 : Set for future use
Reason 2 : Created by other program(automatic
code generators or refactoring tools…)
Reason 3 : Carelessness and immaturity
2015/10/1
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
100
Overview of Experiment(2/2)

Target Software
 Ant
1.8.2 (1141 files, 127235 LOC)
 jEdit 4.4.1(546 files, 109479 LOC)
 MASU(519 files, 10200 LOC)
JSSST11
2015/10/1
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
101
Result of Ant(1/2)
Ratio of each AE Id
18.9%
35.5%
JSSST11
2015/10/1
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
102
Result of Ant(2/2)

Excessive fields

Total number : 611(18.9%)
1.
2.
3.

Excessive methods

Total number : 1520(35.5%)
1.
2.
3.

Set for future use : unknown
Created by other program : 0
Carelessness and immaturity : unknown
Set for future use : unknown
Created by other program : 0
Carelessness and immaturity : unknown
Ratio of excessive methods > ratio of excessive fields

Encapsulation : Make fields private and provide public getter/setter
to access fields
JSSST11
2015/10/1
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
103
Result of jEdit(1/2)
Ratio of each AE Id
24.1%
30.4%
JSSST11
2015/10/1
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
104
Result of jEdit(2/2)

Excessive fields
 Total number : 604(24.1%)
1.
2.
3.

Excessive methods
 Total number : 981(30.4%)
1.
2.
3.

Set for future use : unknown
Created by other program : 0
Carelessness and immaturity : unknown
Set for future use : unknown
Created by other program : 0
Carelessness and immaturity : unknown
Ratio of excessive methods > ratio of excessive fields
JSSST11
2015/10/1
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
105
Result of MASU(1/2)
Ratio of each AE Id
35.7%
14.3%
JSSST11
2015/10/1
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
106
Result of MASU(2/2)

Excessive fields
 Total number : 280(35.7%)
1.
2.
3.

Excessive methods
 Total number : 253(14.3%)
1.
2.
3.

Set for future use : 20
Created by other program(automatic code generator) : 255
Carelessness and immaturity : 5
Set for future use : 181
Created by other program(automatic code generator) : 6
Carelessness and immaturity : 66
Ratio of excessive fields > ratio of excessive methods
 Caused by fields created by automatic code generator
JSSST11
2015/10/1
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
107
文献一覧 (1/5)
[1-1] M. Page-Jones,: “The Practical Guide to Structured Systems Design”, New York, Yourdon Press, 1980.
[1-2] A.April, and A.Abran,: "Software Maintenance Management: Evaluation and Continuous Improvement", IEEE Computer SocietyJohn Wiley & Sons, Inc., New Jersey, 2008.
[1-3] Nghi Truong, Paul Roe, and Peter Bancroft,: “Static analysis of students' Java programs”, In Proc. ACE '04, 317-325, 2004.
[1-4] IEEE Std 1219,: "Standard for software maintenance", 1998.
[1-5] ISO/IEC 14764:2006,: "software engineering – software life cycle processes - maintenance", 2006.
[1-6] JIS X 0161:2008,: "ソフトウェア技術−ソフトウェアライフサイクルプロセス−保守 Software Engineering-Software Life Cycle ProcessesMaintenance", 2008.
[1-7] E. J. Chikofsky, and J. H. Cross,: "Reverse engineering and design recovery: A taxonomy", IEEE Software, Vol.7, No.1, pp.13–17,
1990.
[1-8] Imagix Corporation,: "Imagix 4D", http://www.imagix.com/products/products.html.
[1-9] IBM,: "Rational software modeler", http://www-01.ibm.com/software/awdtools/modeler/swmodeler/
[1-10] T. J. Biggerstaff,: “Design recovery for maintenance and reuse”, Computer, Vol.22, No.7, pp.36–49, 1989.
[1-11] E. Gamma, R. Helm, R. Johnson, and J. M. Vlissides,: "Design Patterns: Elements of Reusable Object-Oriented Software",
Addison Wesley, 1995.
[1-12] N. Shi, and R. A. Olsson,: "Reverse engineering of design patterns from Java source code", In Proc. of ASE 2006, pp.123–134,
2006.
[1-13] N. Tsantalis, A. Chatzigeorgiou, G. Stephanides, and S. T. Halkidis,: “Design pattern detection using similarity scoring”, IEEE
Transactions on Software Engineering, Vol.32, No.11, pp.896–909, 2006.
[1-14]L. Prechelt, B. Unger-Lamprecht, M. Philippsen, and W. Tichy,: "Two controlled experiments assessing the usefulness of design
pattern documentation in program maintenance", IEEE Transactions on Software Engineering, Vol.28, No.6, pp.595–606, 2002.
[1-15] K. H. Bennet. Software maintenance: A tutorial. In M. Dorfman, and R. H.Thayer eds,: "Software Engineering", IEEE Computer
Society Press, 1997.
[1-16] X. Ren, F. Shah, F. Tip, B. G. Ryder, and O. Chesley,: "Chianti: a tool for change impact analysis of java programs", In Proc. of
OOPSLA 2004, pp.432–448, 2004.
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
108
文献一覧 (2/5)
[1-17] G. Rothermel and M. J. Harrold,: "A safe, efficient regression test selection technique", ACM Transactions on Software
Engineering and Methodology, Vol.6, No2, pp.173–210, 1997.
[1-18] S. R. Chidamber and C. F. Kemerer,: "A metrics suite for object oriented design", IEEE Transactions on Software Engineering,
Vol.20, No.6, pp.476–493, 1994.
[1-19] E. J. Weyuker,: “Evaluating software complexity measures”, IEEE Transactions on Software Engineering, Vol.14, No.9, pp.1357–
1365, 1988.
[1-20] V. R. Basili, L. C. Briand, and W. L. Melo,: "A validation of object-oriented design metrics as quality indicators", IEEE
Transactions on Software Engineering, Vol.22, No.10, pp.751–761, 1996.
[1-21] M. Weiser,: “Program slicing”, In Proc. of ICSE '81, pp.439–449, 1981.
[1-22] T. M. Meyers and D. Binkley,: "An empirical study of slice-based cohesion and coupling metrics", ACM Transactions on Software
Engineering and Methodology, Vol.17, No.1, pp.1-27, 2007.
[1-23] Y. Kataoka, T. Imai, H. Andou, and T. Fukaya,: "A quantitative evaluation of maintainability enhancement by refactoring", In Proc.
of ICSM 2002, pp.576–585, 2002.
[1-24] M. Fowler,: ”Refactoring: improving the design of existing code”, Addison Wesley, 1999.
[1-25] W. F. Opdyke,: “Refactoring object-oriented frameworks”, PhD thesis, University of Illinois at Urbana-Champaign, 1992.
[1-26] M. Weiser,: “Program slicing”, Proc. of the 5th International Conference on Software Engineering, pp.439–449, 1981.
[1-27] J.Gosling, B.Joy, G.Steele, G.Bracha, A.Buckley,: “The Java Language Specication, Java SE 7 Edition”,
[1-28] K. Khor, Nathaniel L.Chavis, S.M.Lovett and D. C. White,: “Welcome to IBM Smalltalk Tutorial ”, 1995
[1-29] A. Müller,: “Bytecode Analysis for Checking Java Access Modifiers”, Work in Progress and Poster Session, 8th Int. Conf. on
Principles and Practice of Programming in Java (PPPJ 2010), Vienna, Austria, 2010.
[1-30] T. Cohen,: “Self-Calibration of Metrics of Java Methods towards the Discovery of the Common Programming Practice”, The
Senate of the Technion, Israel Institute of Technology, Kislev 5762, Haifa, 2001.
[1-31] D. Evans, and D. Larochells,: “Improving Security Using Extensible Lightweight Static Analysis”, IEEE software, vol.19, No.1, pp.
42-51, 2002.
[1-32] J. Viega, G. McGraw, T. Mutdosch, and E. Felten,: “Statically Scanning Java Code: Finding Security Vulnerabilities”, IEEE
software, Vol.17 No.5 pp. 68-74, 2000.
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
109
文献一覧 (3/5)
[1-33] Jlint,: http://jlint.sourceforge.net/
[1-34] B. S. Baker,: “Finding clones with Dup: Analysis of an experiment”, IEEE Trans. Softw. Eng., Vol.33, No.9, pp.608–621, 2007.
[1-35] I. D. Baxter, A. Yahin, L. Moura, M. S. Anna, and L. Bier,: "Clone detection using abstract syntax trees", In Proc. of ICSM '98,
pp.368–377, 1998.
[1-36] L. Jiang, G. Misherghi, Z. Su, and S. Glondu. Deckard,: "Scalable and accurate tree-based detection of code clones", In Proc. of
ICSE 2007, pp.96–105, 2007.
[1-37] T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder: A multi-linguistic token-based code clone detection system for large scale
source code”, IEEE Transactions on Software Engineering, vol.28, no.7, pp.654-670, 2002.
[1-38] R. Komondoor, and S. Horwitz,: "Using slicing to identify duplication in source code", In Proc. of SAS 2001, pp.40–56, 2001.
[1-39] B. Laguë, D. Proulx, J. Mayrand, E. M. Merlo, and J. Hudepohl,: "Assessing the benefits of incorporating function clone detection
in a development process", In Proc. of ICSM '97, pp.314–321, 1997.
[1-40] Z. Li, S. Lu, S. Myagmar, and Y. Zhou,: "CP-Miner: Finding copy-paste and related bugs in large-scale software code", IEEE
Trans. Softw. Eng., Vol.32, No.3, pp.176–192, 2006.
[1-41] A. Zeller,: “Why Programs Fail”, Morgan Kaufmann Pub., 2005.
[1-42] M. Kim, L. Bergman, T. Lau, and D. Notkin,: "An ethnographic study of copy and paste programming practices in oopl", In Proc. of
ISESE 2004, pp.83–92, 2004.
[1-43] A. Aiken,: "Moss (measure of software similarity) plagiarism detection system", http://www.cs.berkeley.edu/ moss/
[1-44] L. Prechelt, G. Malpohl, and M. Philippsen, “Jplag: Finding plagiarisms among a set of programs”, Technical Report 2000-1,
Fakultat fur Informatik, Universitat Karlsruhe, 2000.
[1-45] K. Verco, and M. Wise,:“YAP3 : Improved detection of similarities in computer program and other texts”, Proc. of the 27th
SIGCSE Technical Symposium on Computer Science Education, pp.130–134, 1996
[1-46] 長橋賢児,: “類似性に基づくソフトウェア品質の評価,” 情処学研報2000-SE-126, Vol.2000, No.25, pp.65–72, 2000.
[1-47] 山本哲男, 松下誠, 神谷年洋, 井上克郎,: “ソフトウェアシステムの類似性とその計測ツールSMMT”, 電子情報通信学会論文誌D-1,
Vol.J85-D-I, No.6, pp.503-511, 2002.
[1-48] 日本情報システム・ユーザー協会,: "非機能要求仕様定義ガイドライン - 検収フェーズのモデル取引・整備報告書 UVC（User Vender
Collaboration）研究プロジェクトⅡ報告書 " , 2007．
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
110
文献一覧 (4/5)
[2-1] Dotri Quoc, Kazuo Kobori, Norihiro Yoshida, Yoshiki Higo, Katsuro Inoue, ModiChecker: Accessibility
Excessiveness Analysis Tool for Java Program, コンピュータソフトウェア, Vol.29, No.3, pp.212-218, 2012.
[2-2] G.Booch, R.Maksimchuk, M.Engel, B.Young, J.Conallen, and K.Houston, “ Object-Oriented Analysis and
Design with Applications ”, Addison Wesly, 2007.
[2-3] K. Arnold, J. Gosling, D. Holmes,: ”The Java Programming Language, 4th Edition”,Prentice Hall, 2005,
http://docs.oracle.com/javase/specs/jls/se7/html/index.html
[2-4] SourceForge.jp,: http://sourceforge.jp/
[2-5] T. Cohen,: “Self-Calibration of Metrics of Java Methods towards the Discovery of the Common Programming
Practice ”, The Senate of the Technion, Israel Institute of Technology, Kislev 5762, Haifa, 2001.
[2-6] D. Evans, and D. Larochells,“Improving Security Using Extensible Lightweight Static Analysis ”, IEEE
software, vol.19, No.1, pp. 42-51, 2002.
[2-7] J. Viega, G. McGraw, T. Mutdosch, and E. Felten,“ Statically Scanning Java Code: Finding Security
Vulnerabilities ”, IEEE software, Vol.17 No.5 pp. 68-74, 2000.
[2-8] FindBugs,: http://ndbugs.sourceforge.net
[2-9] Jlint,: http://jlint.sourceforge.net/
[2-10] N. Rutar,: C. Almazan, and J. Foster, “ A Comparison of Bug Finding Tools for Java ”, 15th International
Symposium on Software Reliability Engineering (ISSRE04), pp.245-256, 2004.
[2-11] Apache Ant,: http://ant.apache.org/
[2-12] jEdit,: http://www.jedit.org/
[2-13] 三宅達也, 肥後芳樹, 楠本真二, 井上克郎,: "多言語対応メトリクス計測プラグイン開発基盤MASUの開発", 電子情
報通信学会論文誌D, vol. J92-D, no. 9, pp.1518-1531, 2009.
[2-14]小堀一雄, 石居達也, 松下誠, 井上克郎: “Javaプログラムのアクセス修飾子過剰性分析ツールModiCheckerの
機能拡張とその応用例”. SEC journal, Vol.33, 2013.
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
111
文献一覧 (5/5)
[3-1]V.R.Basili, G.Caldiera, F.McGarry, R.Pajerski, G.Page, and S.Waligora,: “The software engineering – an
operational software experience”, in Proceedings of 14th International Conference on Software
Engineering(ICSE14), pp.370-381, Melbourne, Australia, 1992.
[3-2] C. Braun,: "Reuse", in John J. Marciniak, editor, Encyclopedia of Software Engineering, John Wiley & Sons,
Vol.2, pp.1055-1069, 1994.
[3-3] Diffutils,: http://www.gnu.org/software/diffutils/diffutils.html
[3-4] K. Inoue, R. Yokomori, H. Fujiwara, T. Yamamoto, M. Matsushita, and S. Kusumoto,: “Component Rank:
Relative Significance Rank for Software Component Search”, to be appeared in Proceedings of 25th
International Conference on Software Engineering (ICSE 25), pp.14-24, 2003.
[3-5] S.Isoda,: “Experience report on a software reuse project: Its structure, activities, and statistical results”, in
Proceedings of 14th International Conference on Software Engineering (ICSE 14), pp.320-326, Melbourne,
Australia, 1992.
[3-6] J.Gosling, B.Joy, G.Steele, and G.Bracha,: ”The Java Language Specification, Second Edition”, Prentice
Hall, 2000.
[3-7] B.Keepence, and M.Mannion,: “Using patterns to model variability in product families”, IEEE Software,
Vol.16, No.4, pp.102-108, 1999.
[3-8] W.Miller, and E.Myers,: “A file comparison program”, Software-Practice and Experience, Vol.15, No.11,
pp.1025-1040, 1985.
[3-9] E.Myers,: “An O(N D) difference algorithm and its variations, Algorithmica, Vol.1, pp.251-256, 1986.
[3-10] SourceForge,: http://sourceforge.net/
[3-11] E.Ukkonen: Algorithms for approximate string matching. INFCTRL: Information and Computation (formerly
Information and Control), Vol.64, pp.100-118, 1985.
[3-12] 横森励士, 梅森文彰, 西秀雄, 山本哲男, 松下誠, 楠本真二, 井上克郎,: "Javaソフトウェア部品検索システム
SPARS-J", 電子情報通信学会論文誌 D-I, VolJ87-D-I, No.12, pp.1060-1068, 2004.
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
112
考察（類似判定精度）
 SMMTとの結果と比較結果
適合率：156/201=0.776
再現率：156/199=0.783
 適合しなかった部品について
非常に規模の小さい部品（総トークン数が10数個以内）が多いことが分かった．
小さい規模の部品に関してもLuigiは類似判定の対象としていたのに対して，
SMMTでは類似対象から外していた．
 再現しなかった部品について
コピーしてメソッドを増やしたような部分的に高い類似性をもつものが多かった．
Luigiでは部品全体のメトリクス値のみを扱う方法で高速化を図ったため，このような
部分的に高い類似性を評価できないというトレードオフがあることがわかった．
全部品数
431
Luigiが類似と
判定した部品数
201
SMMTが類似と
判定した部品数
199
LuigiとSMMT両方が
類似と判定した部品数
156
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
113
類似判定法（トークン構成メトリクス）
部品X のトークン構成メトリクス：（Xm1 ,・・・, Xm96)
変数の意味
変数
部品A,B 間における
各トークンの差分の合計値
diff(A,B)
部品X の全トークン数
Ttotal (X)
部品A,B の非類似度
D(A,B)
式
D(A,B) ＜ 0.03 なら，部品A,Bは類似候補と判定する
※
（※今回の実験で経験的に設定した値）
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
114
類似判定法（複雑度メトリクス）

以下の6種類のメトリクスを使用する
メトリクス名
サイクロマチック数
閾値※
0
メソッドの宣言数
1
メソッド呼び出し数
2
ネストの深さ
0
“class”トークン数
0
“interface”トークン数
0
部品A,B の各メトリクスの差分が閾値以内に収まったら
部品A,B は類似候補と判定する
（※今回の実験で経験的に設定した値）
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University
115

Download Report