ソースコードの静的解析によるソフトウェア保守支援に関する研究

Department of Computer Science, Graduate School of Information Science & Technology,Osaka University

ソースコードの静的解析によるソフトウェア保守支援に関する

研究

大阪大学大学院情報科学研究科コンピュータサイエンス専攻井上研究

室小堀一雄

1

Department of Computer Science, Graduate School of Information Science & Technology, Osaka University

ソフトウェア保守とは

ソフトウェア保守とは納入後，ソフトウェアに対して加えられる，欠陥の修正

，性能などの改善，変更された環境に適合させるための修正． [IEEE Std 1219]

保守に関するコスト全ライフサイクルの 3 分の２を占める20 年以上も保守を続けているシステムも存在す

る

2

ソフトウェア保守を支援したい


ソフトウェア保守の課題

課題保守担当者に以下を理解させるのが重要である1. どのように修正すべきか？2. どこを（どこまで）修正すべきか？

保守を難しくする要因社会基盤を担う重要なソフトウェアは、大規模化

・複雑化・ライフサイクルの長期化が進む保守期間中にドキュメント最新化が成されず、実

際の動作と乖離が発生保守のアウトソーシングやオフショアが進み、

仕様決定時の情報を持たない人が保守を担当3


ソフトウェア保守を支援する方法

保守支援に関する様々な手段リバースエンジニアリング

ソースコードから設計情報を抽出する回帰テスト

修正することでデグレードした箇所を特定するソースコード動的分析

ソースコードの実行結果から振る舞いや特徴を分析動作環境とテストケースが必要

ソースコード静的解析ソースコードの記述を分析して振る舞いや特徴を分

析動作環境やテストケースは不要

4

Department of Computer Science, Graduate School of Information Science & Technology, Osaka University 5

ソースコード静的解析を用いたソフトウェア保守支援

ソースコード静的解析ソースコード静的解析技術を利用してプログラムから抽出さ

れた情報をもとに，プログラム保守の支援を目的として様々な解析が行われている．代表的な例を以下に示す．デバッグ支援

プログラムスライスを用いることで，デバッグ対象を限定する影響波及解析

再テストすべきテストケースを限定することで，テスト工程を効率化する

ソフトウェア部品の評価メトリクス値化された部品の性質から再利用性や品質を評価

コピー部品の把握メトリクス計測された情報を配列化し，解析効率を上げる

理解支援解析結果情報を選別の基準とし，大量の部品からの選別作業を支援する


研究の目的

プログラム保守支援を目的としたソースコード解析手法の提案アクセス修飾子過剰性の解析手法ソフトウェア類似部品の高速な解析手法

手法を実現したツールの評価

6

本論文では、下記の 2つのソースコード解析技術に着目し、保守や再利用における支援を目的とした以下の解析手法の提案、提案手法を実現したツールの評価を行う．


研究対象とする課題①　　　　　　　　　　「アクセス修飾子過剰性の解析」

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();

}}

<開発者の想定する正しい手順 >

外部から①を飛ばして②を直接実行可能

NullPointerException の発生

外部からの呼び出しを想定したメソッドに①→②の呼び出し順序を実装

public

getLength() のアクセス修飾子が private ではなく public

① 初期値が null である変数 str にString オブジェクトを代入

② 変数 str の文字列長を取得

7

保守の課題１：「どのように修正すべきか？」課題の具体例


研究対象とする課題①　　　　　　　　　　「アクセス修飾子過剰性の解析」既存研究の問題

アクセス修飾子の過剰性に関しての詳細な研究はあまり無い

アクセス修飾子のチェックのみ行い、適切さについて議論していない

アクセス修飾子の修正に関する支援が無い private にすべきメソッドやフィールドに関する警告を提示する

private のみでなく、全アクセス修飾子について過剰性を解析・修正を支援する必要がある

アクセス修飾子過剰性の解析・修正を支援する手法を提案する


研究対象とする課題②　　　　　　　　　　　　　「類似部品の高速な解析」保守の課題２：「どこを ( どこまで ) 修正すればよいか？」

課題の具体例

想定シナリオ「類似部品に存在する類似バグを修正したい」1.生産性を上げたい！2.ネットやリポジトリに過去の部品が大量に蓄積されている3.再利用して素早く実装した（コピー＆ペーストによる類似部品作成）．

～しばらくして～

4.ある類似部品に修正・デバッグを行った．5.他の類似部品にも同じ修正・デバッグを行う必要がある．6.大量の既存部品から、いますぐ類似部品見つけたい！

9


研究対象とする課題②　　　　　　　　　　　　　「類似部品の高速な解析」既存研究の課題

文字列比較による類似測定手法が多い解析に時間がかかるため、解析対象が大規模化する場合

、バッチ処理的な運用が想定される。しかし、類似部品の検索対象は随時作成されていくため

、現在のリポジトリに対して即時に類似部品を発見したい。

ソースコード部品類似性の高速な解析手法を提案する


博士論文構成と業績一覧の関連博士論文構成

第１章　はじめに第２章　アクセス修飾子過剰性に関する研究　 [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.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. (国内会議録 )

11


アクセス修飾子過剰性に関する研究

12

博士論文　第２章


背景：アクセス修飾子

アクセス修飾子フィールド / メソッドへのアクセスを制限する修

飾子 ( )※

public, protected, default(宣言なし ),private が存在

過剰に設定すると不具合の原因となりうる過剰：アクセス可能な範囲 > 実際のアクセス範囲

13

アクセス修飾子アクセス可能な範囲

public あらゆる部品

protected 自身と同じパッケージに属する部品及び自身のサブクラス

default(宣言なし ) 自身と同じパッケージに所属する部品

private 自身と同じクラス

※本研究ではクラスのアクセス修飾子については考慮しない


アクセス修飾子過剰性を表すメトリクス　 AE(Accessibility Excessiveness)

フィールド / メソッドのアクセス修飾子を以下の３つに分類

1. 適切：実際の被アクセス状況通りのアクセス修飾子が宣言されている（表中緑色）

2. AE：実際の被アクセス状況に比べて過剰に広いアクセス修飾子が宣言されている状態（表中オレンジ色）

3. NA(NoAccess)：どこからもアクセスされていない状態（表中黄色）

14

Public Protected Default Private NoAccess

Public pub-pub pub-pro pub-def pub-pri pub-na

Protected x pro-pro pro-def pro-pri pro-na

Default x x def-def def-pri def-na

Private x x x pri-pri pri-na

実際の被アクセス範囲に対応するアクセス修飾子

現在宣言している

アクセス修飾子


アクセス修飾子過剰性の解析・自動修正ツール ModiChecker

フィールド / メソッドに宣言している

アクセス修飾子を抽出

フィールド / メソッドの呼び出される範囲を抽出

ModiChecker

ソースコードの内容・呼び出し関係を解析する

AST( 抽象構文木 ) データベース

MASU （既存の Java 解析ツール

アクセス修飾子の過剰性（ AE ）を抽出

入力：

解析対象のソースコード群

必要なライブラリ (.jar など )

各フィールド / メソッドのAE種別出

力：15

MASU - http://sourceforge.net/projects/masu/


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)

16


MASU に対する結果　～各 AE の割合～

JSSST11 23/04/21

17

35.7% 14.3%


AE であるフィールド　総数（割合）　 : 280(35.7%)

1. 将来的な利用を想定　 : 202. 自動生成　 : 2553. 設定ミス　 : 5

自動生成ツールによって、一律 public と設定されたフィールドが多かった

AE であるメソッド　1.総数（割合）　 : 253(14.3%)

1. 将来的な利用を想定　 : 1812. 自動生成　 : 63. 設定ミス　 : 66

2. Java Bean の使用上機械的に public と設定されたメソッド (setter/getter)が多かった

JSSST11 23/04/21

18

MASU に対する結果　～考察～


応用実験（１）　概要

19

目的：• 先の実験で、ソフトウェアのある時点における AE の解析

をおこなうことができた• 次に、応用として、ソフトウェアの開発履歴を追って AE

の状態がどのように遷移するか分析することで、 AE を解析すべき契機に関する情報を開発者に提案したい

実験内容：• バージョンアップ時に、アクセス修飾子が適切・ A

E ・ NA のうち、どの状態に遷移していくのか可視化する

計測事項：全バージョンにおける状態遷移総数における、状態遷移の種別ごとの割合を調査する


応用実験（１）　実験対象

実験対象： 7つの Java プロジェクト（バージョン数があり、最近まで開発が行われていて、世の中で利用されているソフトウェア）

20

番号プロジェクト名

バージョン番号バージョン数

開発期間( 年 )

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


バージョン間における状態遷移 2 バージョン間におけるフィールド / メソッドの状態遷移

は以下を状態遷移図で表現する状態数：４

適切、 AE 、 NA 、なし（フィールド / メソッドが削除された状態）

状態遷移数： 18 a ~ r

21

適切

NAAE

なし

a,p

b

c

d

e,qf

g

h i,r

ol

j

m

kn


結果考察 - メソッド状態遷移 (単位 :%)

22


応用実験（１）　結果考察

フィールド / メソッドに共通して得られた知見一度、アクセス修飾子が設定されると、その後アクセス

修飾子が変更されるケースは少ない用途が変わる場合は、フィールド / メソッド自体を変更す

る傾向にあるフィールドについて得られた知見

アクセス範囲を明確にして作成されるものが大半メソッドについて得られた知見

作成時点ではアクセス範囲が定まっていないもの (NA) が多い

23


応用実験（２）　概要

24

目的：• 先の応用実験（１）で、ソフトウェアの開発履歴を追って

アクセス修飾子の状態がどのように遷移するか分析できた• 次に、さらなる応用として、どのようなバージョンアップ

の際に AE の変化が大きくなるのか分析することで、 AE解析を行うべきタイミングを提案したい

仮説• Major version up 時に AE が大きく変化する

• 過剰なアクセス修飾子を設定されたフィールド・メソッドが追加される

• Minor version up 時には AE はほとんど変化しない• 一度作成された AE は修正されることはない（先の応用実験結果）


Ant の 22 バージョンにおける AE 変化量仮説に合致しそうな結果を得たので検定を行う

25


応用実験（２）　結果考察

フィールド：全 AE ・ NA で MajorVU 時と MinorVU 時の間で有意差（有意水準 0.05 ）がみられた

メソッド： pub-pri,def-pri,def-na 以外の AE ・ NA につい MajorVU 時と MinorVU 時の間で有意差（有意水準 0.05 ）がみられた上記の AE は他の AE ・ NA に比べて各バージョン間の値の

変化量が小さく，順位がタイとなる値が多かったためマン・ホイットニーの　 U 検定では誤差が出やすい状況下にあった．

26

下記仮説を裏付ける結果が得られた•Major version up 時に AE が大きく変化する•Minor version up 時には AE はほとんど変化しない


ソフトウェア類似部品に関する研究

27

博士論文　第３章


研究対象とする課題②　　　　　　「類似部品（ Java クラス）の高速な解析」解決したい課題（その２）「どこまで修正すればよいか？」

課題の具体例想定シナリオ「類似部品に存在する類似バグを修正したい」1.生産性を上げたい！2.ネットやリポジトリに過去の部品が大量に蓄積されている3.再利用して素早く実装した（コピー＆ペーストによる類似部品作成）．

～しばらくして～

4.ある類似部品に修正・デバッグを行った．5.他の類似部品にも同じ修正・デバッグを行う必要がある．6.大量の既存部品から、いますぐ類似部品見つけたい！ 28


研究対象とする課題②　　　　　　　　　　　　　「類似部品の高速な解析」既存研究の課題

文字列比較による類似測定手法が多い解析に時間がかかるため、解析対象が大規模化する場合

、バッチ処理的な運用が想定される。しかし、類似部品の検索対象は随時作成されていくため

、現在のリポジトリに対して即時に類似部品を発見したい。

ソースコード部品類似性の高速な解析手法を提案する


類似度メトリクス

2つの視点から類似度メトリクスを計測するトークン構成

メトリクス：ソースコードにおける各トークンの出現数トークン＝予約語 + 記号 + 演算子 + 識別子

　　　（ 96種）（ 49種）（ 9種）（ 37種）（１種） ※ jdk1.3 の場合

意味：ソフトウェア部品の表層的特徴を表す複雑度

メトリクス：クラス内のメソッド数 , サイクロマチック数（分岐の数）など

意味：ソフトウェア部品の構造的特徴を表す

数値比較のため、文字列比較に比べて解析コストの低下が期待できる


類似判定法

トークン構成に関するメトリクスと複雑度に関するメトリクスの全てにおいて部品 A と B のメトリクス値差分があらかじめ設定した閾値以内になった場合類似部品と判定する

分類メトリクス閾値※

トークン構成

各トークンの出現数差分の和／小さいほうの部品のトークン総数

0.03

複雑度サイクロマチック数 0

メソッドの宣言数 1

メソッド呼び出し数 2

ネストの深さ 0

“class” トークン数 0

“interface” トークン数 0（※今回の実験で経験的に設定した値）


類似判定の効率化

1. メトリクス計測時に、いくつかのメトリクスでハッシュキーを作成する

2. 部品と、部品の持つメトリクス値から作成したハッシュキーを対応させた表を構築しておく

[ 0. 0. 0]= null

[ 10. 62.124]= 部品 A [ 10. 62.125]= 部品 B ，部品C[ 10. 62.126]= null

[255.255.255]= 部品 Z

・・

・・

・

・

8bit 8bit8bit

メトリクスA

ハッシュキー

＝(24bit)

3. 新しく類似測定をしたい部品 P が追加される部品 P のハッシュキー＝

[10.62.125] メトリクス [A,B,C] の閾値＝

[0.0.1]

最終結果を変えずに解析コストを下げることが可能

4. 残りの全メトリクスを用いた類似判定の計算を行うのは、左下図の部品A ， B ， C の 3つのみに限定する

メトリクスB

メトリクス C


適用実験の概要

実験目的今回提案したメトリクス値比較による類似判定手法が

、　　従来の文字列比較による類似判定手法より解析コストが低くなることを確かめる

実験内容同じソースコード群に対して、各手法を実装した２ツ

ールによる類似判定を行った際の解析コストを比較する

比較するツール既存の文字列比較を用いた類似度測定ツール SMMT今回提案したメトリクス比較を用いた類似度測定ツール Luigi

実験対象のソースコードJDK1.3 に属する 431個のクラス

33


ハッシュキーを構成するメトリクス

事前分類クラスタ数

計算コスト (sec)

未使用 1 05.02

[ C ] 21 00.56

[ C,M ] 85 00.29

[ C,M,T ] 232 00.16

考察（解析コスト）

C：サイクロマチック数M：宣言メソッド数 T : トークン構成メトリクス

文字列比較を用いた類似度測定ツール SMMT の計算コスト： 24.35 （ sec ）

メトリクス値比較だけで 1/5 に低下

ハッシュキーにより、さらに 1/30 に低下

対象： JDK1.3　　　　　 431 クラス

34

メトリクス値比較を用いた類似度測定ツール Luigi の計算コスト

解析コストは 1/150 になった


むすび

35

博士論文　第４章


まとめ

下記のソースコード静的解析技術を提案・評価した1. アクセス修飾子の解析手法

AE メトリクスを用いたアクセス修飾子解析手法を提案した上記手法をツール ModiChecker に実装した ModiChecker の適用実験により、以下を示した

AE ・ NA の解析・可視化を実現した AE は一度作り込まれると、 version up しても修正されず残る傾向に

ある多くの AE ・ NA において、 major version up の方が minor version up

より多くの AE が発生する傾向にある

2. 高速なソースコード類似度判定手法メトリクス比較を用いた類似判定手法を提案した上記手法をツール Luigi に実装した Luigi の適用実験により、以下を示した

既存の文字列比較を用いた類似度測定ツール SMMT と比べて 150倍の速度をもつことを示した

36


今後の研究方針

アクセス修飾子解析手法AE が発生した原因をインタビューなどで調査するAE の発生を防ぐ開発環境を提供する外部からの利用を想定した AE を自動判別する

テストケースも合わせて ModiChecker で解析する品質（バグ）と AE の関連性を分析する

類似判定手法現在、類似判定エンジンのみなので、単独のツー

ルとして利用しやすいようにする各メトリクスの閾値の設定を簡単にできるように

するJava 以外の言語への対応

37


発表おわり

ご清聴ありがとうございました．

38


以下、補足資料

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. (国内会議録 )

40


はじめに


ソフトウェア保守とはソフトウェア保守とは

納入後，ソフトウェアに対して加えられる，欠陥の修正，性能などの改善，変更された環境に適合させるための修正． [IEEE Std 1219]

「修正」と「ソフトウェア保守」の分類 [JISX0161:2008]

42

訂正

改良

是正保守

予防保守

適応保守

完全化保守

緊急保守

分類名定義

是正保守ソフトウェア製品の引渡し後に発見された問題を訂正するために行う受身の修正

緊急保守是正保守の内，実施までシステム運用を確保するための，計画外で一時的な修正

予防保守引渡し後のソフトウェア製品の潜在的な障害が運用障害になる前に発見し，是正を行うための修正

適応保守引渡し後，変化した又は変化している環境において，ソフトウェア製品を使用できるように保ち続けるために実施するソフトウェア製品の修正

完全化保守

引渡し後のソフトウェア製品の潜在的な障害が故障として現れる前に，検出し訂正するための修正

修正の分類

ソフトウェア保守の分類


ソースコード解析ソースコード解析の分類

ソースコード静的解析ソースコードを実際に動作することなく解析を行うことで，性質や

振る舞い情報を抽出する技術ソースコードの中身を扱うため，網羅性の高い解析をすることが可

能ソースコード動的解析

ソースコードを動作環境上で実際に動作させ，その動作結果や動作中のログなどを解析することで性質や振る舞い情報を抽出する技術

マルチスレッド処理など，ソースコード静的解析では発見が難しい　振る舞いを解析することが可能

網羅的な振る舞いを調べるには多くのテストケースが必要となる．

動作環境やテストケースの準備が不要であるため、　現場への適用が容易な「ソースコード静的解析」に　注目する。


研究対象とする課題①　　　　　　　　　　「アクセス修飾子過剰性の解析」解決したい課題（その１）「過剰に広いアクセス修飾子をもつフィールド，メソッドに関する理解支援」

課題の具体例想定シナリオ：設計時に意図しなかった不正なメソッド呼び出し

対策の考察：対策１：ドキュメントにプログラム内部構造を詳細に書く　　　　　　　→作成コスト、メンテナンスコストが大きすぎる　　　　　　　→膨大な資料を説明・理解するコストが大きすぎる対策２：不正な呼び出しができないようにリファクタリングする　　　　　　　→不正な呼び出しの可能性がある箇所の特定が難しい　　　　　　　→設計時に想定した範囲より過剰に広い範囲からアクセスされる　　　　　　　　フィールド・メソッドの解析・修正を支援したい


適用実験

45


ModiChecker 適用実験の概要

実験の目的Validation of our approachQuantitative analysis of AE Id in some software

systems Reasons for excessive/unused fields/methods

(found by interviewing developers)1. Reason 1 : Set for future use2. 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　実験対象のソフトウェア

Industrial Software(341 Java files/ 64455 LOC)

46


適用実験結果（フィールド）

実際の被アクセス

宣言


Public 207 0 59 936 33

Protected x 0 9 18 0

Default x x 4 5 2

Private x x x 1123 5

47

AE であるフィールドの数

NA であるフィールドの数


適用実験結果（メソッド）

実際の被アクセス

宣言


Public 816 14 23 190 1005

Protected x 13 36 48 9

Default x x 0 3 0

Private x x x 488 4

48

AE であるメソッドの数

NA であるメソッドの数


適用結果の考察

AE もしくは NA のフィールド / メソッドの数は以下のとおり AE であるフィールド　 : 1027 AE であるメソッド　 : 512 NA であるフィールド : 40 NA であるメソッド　 : 1018

NA(NoAccess) であるフィールド（ 40個）について内容を確認した結果将来的な利用を想定したもの： 8 外部からの利用を想定したもの： 5

serialVersionUID（直列化ランタイムからの使用を想定）実際に未使用だったもの： 27

その内、潜在バグを伴っていたもの： 5

49


Discussion

Validation of ModiChecker outputChanged all of the excessive access modifier

and deleted some unused fields/methodsModified 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

50


Ant に対する結果　～各 AE の割合～

51

18.9%35.5%


AE フィールド　総数（割合）　 : 611(18.9%)

1. 将来的な利用を想定　 : unknown2. 自動生成　 : 03. 設定ミス　 : unknown

AE メソッド総数（割合）　 : 1520(35.5%)

1. 将来的な利用を想定　 : unknown2. 自動生成　 : 03. 設定ミス　 : unknown

1. AE メソッドの割合 > AE フィールドの割合1. java bean の制約上、実際のアクセス範囲に関わらず、 getter, setter メソッ

ドには機械的に public が設定されていた

23/04/21

52

Ant に対する結果　～考察～


jEdit に対する結果　～各 AE の割合～

53

24.1% 30.4%


AE フィールド　総数（割合）　 : 604(24.1%)

1. 将来的な利用を想定　 : unknown

2. 自動生成　 : 0

3. 設定ミス　 : unknown

AE メソッド総数（割合）　 : 981(30.4%)

1. 将来的な利用を想定　 : unknown

2. 自動生成　 : 0

3. 設定ミス　 : unknown

AE メソッドの割合 > AE フィールドの割合

54

jEdit に対する結果　～考察～


応用実験①

55


応用実験②

56


バージョン毎のフィールド / メソッド分類 AE 以外の状態を 2つにグループ化し，

計 3つの状態を定義

57


Public pub-pub pub-pro pub-def pub-pri pub-na

Protected x pro-pro pro-def pro-pri pro-na

Default x x def-def def-pri def-na

Private x x x pri-pri pri-na

③NA宣言されてはいるがどこからもアクセスされていない

①AEアクセス可能な範囲が実際のアクセス範囲より広い

②適切アクセス可能な範囲と実際のアクセス範囲が一致


応用実験　概要

58

分析１：プロジェクト開発履歴における各状態遷移の出現頻度分析

分析 2：プロジェクト開発履歴における各 AE の修正状況分析

• 目的：バージョンアップの際に AE であるアクセス修飾子の修正

　　　　　　　　　　　　　がどれ程の頻度で行われているのかを明確にする• 計測データ：全バージョン間での (各種状態遷移総数 ÷ 全状態遷移総数 )

• 目的： AE の種類ごとに，修正頻度に差異がみられるかどうかを

明確にする• 計測データ：修正された AE数 ÷ 全バージョン内の AE総数

データの取得にはアクセス修飾子過剰性検出ツール ModiChecker を利用


バージョン間での状態遷移の分類(2/2)

59

グループ対応する記号性質

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状態ずつ


バージョン間での状態遷移の分類(2/2)

60

グループ対応する記号性質

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状態ずつ


分析 1 結果 -Ant におけるフィールド状態遷移

61

適切

NAAE

なし

0.02,71.42

0.16

0.02

0.04

0.07,15.280.00

0.03

0.030.00,2.28

0.130.21

6.41

2.03

1.41

0.46


分析１結果 - フィールド状態遷移 (単位 :%)

68

変化なし (p,q,r)→ 全体の約 53～97%

変化なし ( 適切 )→ 全体の約 36～71%

< フィールド作成 >「適切」で作成される場合が最も多い

<AE 修正， AE 発生，アクセス消失 >アクセス修飾子の修正を伴う遷移は全体の 1% に満た

ない


分析１結果 - メソッド状態遷移 (単位 :%)

69


ない

< メソッド作成 >比較的「 NA」で作成される場合が多

い


変化なし (NA)→ 全体の約 25～ 55%


結果考察 - フィールド状態遷移 (単位 :%)

70





ない



71


ない


い




分析２結果 - フィールド AE 修正状況 (単位 :%)

72

pub-def,pub-pri → 全 7 プロジェクトにて修正作業が行われているpro-def,pro-pri,def-pri → 6 プロジェクトにて修正作業が行われている

AE が修正される割合は AE の種類に関わらず 0.2% に満たない


分析２結果 - メソッド AE 修正状況 (単位 :%)

73

pub-def,pub-pri → 全 7 プロジェクトにて修正作業が行われているpub-pro,pro-pri → 6 プロジェクトにて修正作業が行われている

AE が修正される割合は AE に関わらず高々 0.2% に満たない

注： × ・・・全バージョンにて一度も出現しなかったことを表す


結果考察 - フィールド状態遷移 (単位 :%)

74





ない



75


ない


い




76

ソースコードの静的特性を用いたJava プログラム間類似度測定ツールの試作


背景

これらのソースコードは，開発者にとって有益な再利用部品である可能性がある

再利用を活用するためには，過去に開発された類似なソフトウェア部品に関する情報を入手することが必要

インターネットの普及により大量のソースコードが比較的容易に入手可能となった

ソフトウェアを収集して再利用部品検索システムを構築

ソフトウェア開発効率を飛躍的に向上するための手法として、再利用が注目されている

再利用とは既存の類似ソフトウェア部品を参照し，一部手直しをして用いること


背景








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.


SPARS-J （ 2/2 ）

Component Rank の計算では，部品間のコピー関係を把握するために類似度を測定している類似部品を一つの部品群として扱い，利用関係を合成する評価値にコピー関係を反映させることが可能

これまでは，ソースコードの文字列比較を行う事で，類似部品を判定していた

B

E

部品 A

C F

D

部品 A´

FC

部品群 A

B D

+類似

E

合成


ハッシュ関数を用いた解決法

ハッシュ関数 h(Ttotal) を用いた加工｜ h(Ttotal) － h(Ttotal×0.97)｜≦ １｜ h(Ttotal×1.03) － h(Ttotal)｜≦ １　 log1.04 （ Ttotal ）

h(Ttotal)

Ttotal

2

1

3

4

6

5

Ttotal



ハッシュ関数 h(Ttotal) を用いた加工｜ h(Ttotal) － h(Ttotal×0.97)｜≦ １｜ h(Ttotal×1.03) － h(Ttotal)｜≦ １

h(Ttotal)

Ttotal

2

1

3

4

6

5

Ttotal×0.97 Ttotal×1.03


ハッシュによる類似判定の効率化

現状の問題点類似判断には９６（トークン構成）＋６（複雑度）＝１０２種類のメトリ

クスを用いて比較を行っている。新しい部品が入ってきた場合、全部の既存部品と 102種類のメトリクスの比較を行なわないとならない

アイデア下記のような部品を比較対象から除外することで、さらに高速化できない

か？1. トークンの総出現回数が 0.97倍未満 or 1.03倍超である部品2. 複雑度メトリクスが閾値を超える部品

実現方法最終的な類似判断結果に直接影響を与えるメトリクス（＝主メトリクス）

をキーとしたハッシュを利用し、事前に分類をしておく．


類似判定の効率化

メトリクス計測時に、いくつかの主メトリクスでハッシュキーを作成する

ハッシュキーと既存登録部品を対応させた表を構築しておく

DB

[ 0. 0. 0]= null

[ 10. 62.124]= 部品 A [ 10. 62.125]= 部品 B ，部品C[ 10. 62.126]= null

[255.255.255]= 部品 Z

・・

・・

・

・

8bit 8bit8bit

主メトリクス A

ハッシュキー

＝(24bit)

新しく類似測定をしたい部品 P が追加される部品 P のハッシュキー＝

[10.62.125] 主メトリクス [A,B,C] の閾値＝

[0.0.1]

最終結果を変えずに解析コストを下げることが可能

102種のメトリクスを用いた類似判定の計算を行うのは、部品 A ， B ， Cの 3つのみとする

主メトリクスB

主メトリクスC




h(Ttotal)

Ttotal

2

1

3

4

6

5

Ttotal




h(Ttotal)

Ttotal

2

1

3

4

6

5





h(Ttotal)

Ttotal

2

1

3

4

6

5

Ttotal




h(Ttotal)

Ttotal

2

1

3

4

6

5





h(Ttotal)

Ttotal

2

1

3

4

6

5

h(Ttotal) は，閾値 1 の主メトリクスとして機能する


実験結果

主メトリクス

類似クラスタ

最終クラスタ

計算コスト(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 クラス文字列比較を用いた類似度測定ツールの計算コスト： 24.35 （ sec ）

DB

[ 0. 0. 0]= null

[ 10. 62.124]= 部品 A [ 10. 62.125]= 部品 B ，部品C[ 10. 62.126]= null

[255.255.255]= 部品 Z

・・・

・・・

SPARS-J の類似度測定部「 Luigi」として実装


実験結果

主メトリクス

類似クラスタ

最終クラスタ


未使用 1 278 05.02

[ C ] 21 278 00.56

[ C,M ] 85 278 00.29

[ C,M,T ] 232 278 00.16


文字列比較を用いた類似度測定ツールの計算コスト： 24.35 （ sec ）

トークン構成度 + 複雑度の両方で類似と判定され、最終的に類似と判定された部品群の数

SPARS-J の類似度測定部「 Luigi」として実装対象： JDK1.3　　　　　 431 クラス


実験結果

主メトリクス

類似クラスタ

最終クラスタ


未使用 1 278 05.02

[ C ] 21 278 00.56

[ C,M ] 85 278 00.29

[ C,M,T ] 232 278 00.16



類似度の測定精度を落とすことなく効率だけが上がっている



実験結果

主メトリクス

類似クラスタ

最終クラスタ


未使用 1 278 05.02

[ C ] 21 278 00.56

[ C,M ] 85 278 00.29

[ C,M,T ] 232 278 00.16



メトリクス比較により，コストは 1/5



実験結果

主メトリクス

類似クラスタ

最終クラスタ


未使用 1 278 05.02

[ C ] 21 278 00.56

[ C,M ] 85 278 00.29

[ C,M,T ] 232 278 00.16



メトリクス比較により，コストは 1/5

ハッシュキーにより，コストは 1/30



SPARS-J （ 2/2 ）

Component Rank の計算では，部品間のコピー関係を把握するために類似度を測定している類似部品を一つの部品群として扱い，利用関係を合成する評価値にコピー関係を反映させることが可能

部品 A + 部品 A´ 部品 A部品群 A

これまでは，ソースコードの文字列比較を行う事で，類似部品を判定していた

類似

合成

⇒


Ttotal をハッシュキーに適応するときの問題点類似判定の条件

diff(A,B)

min(Ttotal （ A ） , Ttotal （ B ） )＜ 0.03

トークンの差分が

Ttotal の 3％以内

DB

[ 0. 0. 0]= null

[ 10. 62. 29]= 部品 A [ 10. 62. 30]= 部品 B ，部品 C[ 10. 62. 31]= null

[255.255.255]= 部品 Z

・・・

Ttotal =30　⇒

DB

[ 0. 0. 0]= null

[ 10. 62.145]= 部品 A [ 10. 62.146]= null[ 10. 62.147]= null [ 10. 62.148]= 部品 B[ 10. 62.149]= 部品 C[ 10. 62.150]= 部品 D ，部品 E[ 10. 62.151]= null[ 10. 62.152]= 部品 F[ 10. 62.153]= null[ 10. 62.154]= 部品 G[ 10. 62.155]= 部品 H, 部品 I

[255.255.255]= 部品 Z

・・・

・・・

Ttotal =150　⇒ 145～ 15529～ 31

・・・


類似度判定法（トークン構成メトリクス）

■部品 A と部品 B の非類似度

D(A,B) ＜ 0.03 ※ なら A,B は類似と判定

部品 X のトークン構成メトリクス：（ Xm1, ・・・ ,Xm96)

D(A,B)diff(A,B)

min(Ttotal （ A ） , Ttotal （ B ） )

（※今回の実験で経験的に設定した値）

部品 X の全トークン数

Ttotal

（ X ）

：

部品 A,B の各トークンの差分の和diff(A,B)：96

∑k=1

( Amk Bmk＝

∑＝96

k=1

Xmk(

)

)


Overview of Experiment(1/2)

Objectives of experimentValidation of our approachQuantitative analysis of AE Id in open source

codeReasons for excessiveness

1. Reason 1 : Set for future use　2. Reason 2 : Created by other program(automatic

code generators or refactoring tools…)　3. Reason 3 : Carelessness and immaturity　

23/04/21

100


Overview of Experiment(2/2)

Target SoftwareAnt 1.8.2 (1141 files, 127235 LOC) jEdit 4.4.1(546 files, 109479 LOC)MASU(519 files, 10200 LOC)

JSSST11 23/04/21

101


Result of Ant(1/2)Ratio of each AE Id

JSSST11 23/04/21

102

18.9% 35.5%


Result of Ant(2/2)

Excessive fields Total number : 611(18.9%)

1. Set for future use : unknown

2. Created by other program : 0

3. Carelessness and immaturity : unknown

Excessive methods Total number : 1520(35.5%)




Ratio of excessive methods > ratio of excessive fields Encapsulation : Make fields private and provide public getter/setter

to access fieldsJSSST11 23/04/21

103


Result of jEdit(1/2)Ratio of each AE Id

JSSST11 23/04/21

104

24.1% 30.4%


Result of jEdit(2/2)









Ratio of excessive methods > ratio of excessive fields

JSSST11 23/04/21

105


Result of MASU(1/2)Ratio of each AE Id

JSSST11 23/04/21

106

35.7% 14.3%


Result of MASU(2/2)


1. Set for future use : 20

2. Created by other program(automatic code generator) : 255

3. Carelessness and immaturity : 5


1. Set for future use : 181

2. Created by other program(automatic code generator) : 6

3. Carelessness and immaturity : 66

Ratio of excessive fields > ratio of excessive methods Caused by fields created by automatic code generator

JSSST11 23/04/21

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 Society-John 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 Processes-Maintenance", 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.

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.

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 ．

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.

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.

112


考察（類似判定精度）

113

全部品数 Luigi が類似と判定した部品数

SMMT が類似と判定した部品数

Luigi と SMMT両方が

類似と判定した部品数

431 201 199 156

SMMT との結果と比較結果適合率： 156/201=0.776再現率： 156/199=0.783

適合しなかった部品について非常に規模の小さい部品（総トークン数が 10数個以内）が多いことが分かっ

た．小さい規模の部品に関しても Luigi は類似判定の対象としていたのに対して，SMMT では類似対象から外していた．

再現しなかった部品についてコピーしてメソッドを増やしたような部分的に高い類似性をもつものが多

かった．Luigi では部品全体のメトリクス値のみを扱う方法で高速化を図ったため，こ

のような部分的に高い類似性を評価できないというトレードオフがあることがわかった．


類似判定法（トークン構成メトリクス）

D(A,B) ＜ 0.03 ※ なら，部品 A,B は類似候補と判定する

部品 X のトークン構成メトリクス：（ Xm1 , ・・・ , Xm96)


114


類似判定法（複雑度メトリクス）

以下の 6種類のメトリクスを使用する

部品 A,B の各メトリクスの差分が閾値以内に収まったら部品 A,B は類似候補と判定する

メトリクス名閾値※

サイクロマチック数 0

メソッドの宣言数 1

メソッド呼び出し数 2

ネストの深さ 0

“class” トークン数 0

“interface” トークン数 0


ソースコードの静的解析による ソフトウェア 保守支援に関する研究

Documents

ソースコードの静的解析によるソフトウェア保守支援に関する研究