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

(1)

Department of Computer Science,

Graduate School of Information Science & Technology,

Osaka University

ソースコードの静的解析による

ソフトウェア保守支援に関する研

究

大阪大学大学院情報科学研究科

コンピュータサイエンス専攻井上研究

室

小堀一雄

1

(2)

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

ソフトウェア保守とは



ソフトウェア保守とは



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

性能などの改善，変更された環境に適合させるための修正

． [IEEE Std 1219]



保守に関するコスト



全ライフサイクルの 3 分の２を占める



₂₀

年以上も保守を続けているシステムも存在する

2

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

い

(3)

ソフトウェア保守の課題



課題



保守担当者に以下を理解させるのが重要である

1. どのように修正すべきか？

2. どこを（どこまで）修正すべきか？



保守を難しくする要因



社会基盤を担う重要なソフトウェアは、大規模化

・複雑化・ライフサイクルの長期化が進む



保守期間中にドキュメント最新化が成されず、実

際の動作と乖離が発生



保守のアウトソーシングやオフショアが進み、仕

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

3

(4)

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



保守支援に関する様々な手段



リバースエンジニアリング



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



回帰テスト



修正することでデグレードした箇所を特定する



ソースコード動的分析



ソースコードの実行結果から振る舞いや特徴を分析



動作環境とテストケースが必要



ソースコード静的解析



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

析



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

4

(5)

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

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

援



ソースコード静的解析

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

た情報をもとに，プログラム保守の支援を目的として様々な

解析が行われている．代表的な例を以下に示す．



デバッグ支援



プログラムスライスを用いることで，デバッグ対象を限定する



影響波及解析



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



ソフトウェア部品の評価



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



コピー部品の把握



メトリクス計測された情報を配列化し，解析効率を上げる



理解支援



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

(6)

研究の目的



プログラム保守支援を目的としたソースコ

ード解析手法の提案



アクセス修飾子過剰性の解析手法



ソフトウェア類似部品の高速な解析手法



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

6

本論文では、下記の 2 つのソースコード解析技術に着目し、保守や再利用に

おける支援を目的とした以下の解析手法の提案、提案手法を実現したツール

の評価を行う．

(7)

研究対象とする課題①　

　　　　　　　　　「アクセス修飾子過剰性の解析

」

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

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



課題の具体例

(8)

研究対象とする課題①　

　　　　　　　　　「アクセス修飾子過剰性

の解析」



既存研究の問題



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



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



アクセス修飾子の修正に関する支援が無い



_private

にすべきメソッドやフィールドに関する警告を提示する



private

のみでなく、全アクセス修飾子について過剰性を解析

・修正を支援する必要がある

アクセス修飾子過剰性の解析・修正

を支援する手法を提案する

(9)

研究対象とする課題②

　　　　　　　「類似部品の高

速な解析」

保守の課題２：「どこを ( どこまで ) 修正すればよいか？」



課題の具体例

想定シナリオ「類似部品に存在する類似バグを修正した

い」

1. 生産性を上げたい！

2. ネットやリポジトリに過去の部品が大量に蓄積されている

3. 再利用して素早く実装した（コピー＆ペーストによる類似部品作

成）．

～しばらくして～

4. ある類似部品に修正・デバッグを行った．

5. 他の類似部品にも同じ修正・デバッグを行う必要がある．

6. 大量の既存部品から、いますぐ類似部品見つけたい！

9

(10)

研究対象とする課題②

　　　　　　　「類似部品の高

速な解析」



既存研究の課題



文字列比較による類似測定手法が多い



解析に時間がかかるため、解析対象が大規模化する場合、

バッチ処理的な運用が想定される。



しかし、類似部品の検索対象は随時作成されていくため、

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

ソースコード部品類似性の高速な

解析手法を提案する

(11)

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

 _{博士論文構成}  _{第１章　はじめに}  _{第２章　アクセス修飾子過剰性に関する研究　[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. ( 国内会議録)

(12)

Department of Computer Science,

Graduate School of Information Science & Technology,

Osaka University

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

究

12 博士論文　第２章

(13)

背景：アクセス修飾子



アクセス修飾子



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

飾子

( )

※



_{public, protected, default(}

宣言なし ),private が存

在



過剰に設定すると不具合の原因となりうる



過剰：アクセス可能な範囲 > 実際のアクセス範囲

13

アクセス修飾子

アクセス可能な範囲

public

_{あらゆる部品}

protected

_{自身と同じパッケージに属する部品}

及び自身のサブクラス

default(

宣言なし )

自身と同じパッケージに所属する部

品

private

_{自身と同じクラス}

※ 本研究ではクラスのアク

セス

修飾子については考慮しない

(14)

アクセス修飾子過剰性を表すメトリクス

　 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

def-def

def-pri

def-na

Private

x

pri-pri

pri-na

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

現在宣言してい

る

アクセス修飾子

(15)

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

ル ModiChecker

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

ている

アクセス修飾子を抽出

フィールド / メソッドの

呼び出される範囲を抽出

ModiChecker

ソースコードの内容・

呼び出し関係を解析する

AST(

抽象構文木

)

データベース

MASU

（既存の Java 解析ツー

ル

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

抽出

入

力：

解析対象の

ソースコード群

必要なライブラ

リ (.jar など )

各フィールド / メソッドの

AE

種別

出

力：

₁₅

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

(16)

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)}

(17)

MASU

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

JSSST11 21/07/10

17

(18)



_AE

であるフィールド　



総数（割合）　 : 280(35.7%)

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

2. 自動生成　 : 255

3. 設定ミス　 : 5



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

ドが多かった



_AE

であるメソッド　

1. 総数（割合）　 : 253(14.3%)

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

2. 自動生成　 : 6

3. 設定ミス　 : 66

2. Java Bean

の使用上機械的に public と設定されたメソッド

(setter/getter)

が多かった

JSSST11 21/07/10

18

(19)

応用実験（１）　概要

19



_目的：

• _{先の実験で、ソフトウェアのある時点における AE の解析}

をおこなうことができた

• _{次に、応用として、ソフトウェアの開発履歴を追って AE}

の状態がどのように遷移するか分析することで、 AE を解

析すべき契機に関する情報を開発者に提案したい



_{実験内容：}

• _{バージョンアップ時に、アクセス修飾子が適切・ AE ・}

NA

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



_{計測事項：全バージョンにおける状態遷移総数における、}

状態遷移の種別ごとの割合を調査する

(20)

応用実験（１）　実験対象



実験対象： 7 つの Java プロジェクト（バージョン数があ

り、最近まで開発が行われていて、世の中で利用されてい

るソフトウェア）

20

番号プロジェクト

名

バージョン番号

バージョン

数

開発期間

(

_{年 )}

1 Apache Ant

_1.1

_{～ 1.8.4}

23 ₂₀₀₃

_{～ 2012}

2 Areca Backup

5.0 ～ 7.2.17

66 2007

_{～ 2012}

3 ArgoUML

_0.10.1

_{～ 0.34}

19 ₂₀₀₂

_{～ 2011}

4 FreeMind

_0.0.2

_{～ 0.9.0}

16 ₂₀₀₀

_{～ 2011}

5 JDT_Core

2.0.1 ～ 3.7

16 2002

_{～ 2012}

6 jEdit

_3.0

_{～ 4.5.2}

21 ₂₀₀₀

_{～ 2012}

7 Apache Struts

1.0.2 ～ 2.3.7

34 2002

_{～ 2012}

(21)

バージョン間における状態遷移



₂

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

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



状態数：４



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

）



状態遷移数： 18



_{a ~ r}

21

適切

NA

AE

なし

a,p

b

c

d

e,q

f

g

h

i,r

o

l

j

m

k

n

(22)

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

(23)

応用実験（１）　結果考察



フィールド / メソッドに共通して得られた知見



一度、アクセス修飾子が設定されると、その後アクセス修

飾子が変更されるケースは少ない



用途が変わる場合は、フィールド / メソッド自体を変更す

る傾向にある



フィールドについて得られた知見



アクセス範囲を明確にして作成されるものが大半



メソッドについて得られた知見



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

多い

23

(24)

応用実験（２）　概要

24



_目的：

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

アクセス修飾子の状態がどのように遷移するか分析できた

• _{次に、さらなる応用として、どのようなバージョンアップ}

の際に AE の変化が大きくなるのか分析することで、 AE

解析を行うべきタイミングを提案したい



_仮説

• Major version up

時に AE が大きく変化する

• _{過剰なアクセス修飾子を設定されたフィールド・メソッ}

ドが追加される

• Minor version up

_{時には AE はほとんど変化しない}

• _{一度作成された AE は修正されることはない}

（先の応用実

験結果）

(25)

Ant

の 22 バージョンにおける AE 変

化量



仮説に合致しそうな結果を得たので検定を行う

(26)

応用実験（２）　結果考察



フィールド：全 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)

Department of Computer Science,

Graduate School of Information Science & Technology,

Osaka University

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

27 博士論文　第３章

(28)

研究対象とする課題②

　　　　　　「類似部品（ Java クラス）の高

速な解析」



解決したい課題（その２）

「どこまで修正すればよいか？」



課題の具体例

想定シナリオ「類似部品に存在する類似バグを修正した

い」

1. 生産性を上げたい！

2. ネットやリポジトリに過去の部品が大量に蓄積されている

3. 再利用して素早く実装した（コピー＆ペーストによる類似部品作

成）．

～しばらくして～

4. ある類似部品に修正・デバッグを行った．

5. 他の類似部品にも同じ修正・デバッグを行う必要がある．

6. 大量の既存部品から、いますぐ類似部品見つけたい！

28

(29)

研究対象とする課題②

　　　　　　　「類似部品の高

速な解析」



既存研究の課題



文字列比較による類似測定手法が多い



解析に時間がかかるため、解析対象が大規模化する場合、

バッチ処理的な運用が想定される。



しかし、類似部品の検索対象は随時作成されていくため、

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

ソースコード部品類似性の高速な

解析手法を提案する

(30)

類似度メトリクス



₂

つの視点から類似度メトリクスを計測する



トークン構成



メトリクス：ソースコードにおける各トークンの出現数



トークン＝予約語 + 記号 + 演算子 + 識別子

　　　（ 96 種）（ 49 種）（ 9 種）（ 37 種）（１種

）

※

jdk1.3

の場合



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



複雑度



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

の数）など



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



数値比較のため、文字列比較に比べて解析コストの

低下が期待できる

(31)

類似判定法

トークン構成に関するメトリクスと複雑度に関するメトリクスの全てにおいて

部品 A と B のメトリクス値差分があらかじめ設定した閾値以内になった場合

類似部品と判定する

分類

メトリクス

_閾値

※

トークン構

成

各トークンの出現数差分の和

_{／小さいほうの部品のトーク}

ン総数

0.03 複雑度

サイクロマチック数

0 メソッドの宣言数

1 メソッド呼び出し数

2 ネストの深さ

0 “class”

_{トークン数}

0 “interface”

_{トークン数}

_（

0 ※

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

(32)

類似判定の効率化

1. メトリクス計測時に、いくつかのメト

リクスでハッシュキーを作成する

2. 部品と、部品の持つメトリクス値

から作成したハッシュキーを対応

させた表を構築しておく

[ 0. 0. 0]= null

[ 10. 62.124]=

部品 A

[ 10. 62.125]=

部品 B ，部品

C

[ 10. 62.126]= null

[255.255.255]=

部品 Z

・

8bit

メトリクス

A

ハッシュ

キー

(24bit)

＝

3. 新しく類似測定をしたい部品 P が追加

される



_{部品 P のハッシュキー＝}

[10.62.125]



_{メトリクス [A,B,C] の閾値＝}

[0.0.1]

最終結果を変えずに解析コスト

を下げることが可能

4. 残りの全メトリクスを用いた類似判

定の計算を行うのは、左下図の部品 A

， B ， C の 3 つのみに限定する

メトリクス

B

メトリクス C

(33)

適用実験の概要



実験目的



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

　　従来の文字列比較による類似判定手法より解析コス

トが低くなることを確かめる



実験内容



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

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



比較するツール



既存の文字列比較を用いた類似度測定ツール SMMT



今回提案したメトリクス比較を用いた類似度測定ツール Luigi



実験対象のソースコード



_JDK1.3

に属する 431 個のクラス

33

(34)

ハッシュキーを構成

するメトリクス

事前分類

_クラスタ

数

計算コス

ト

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

Department of Computer Science,

Graduate School of Information Science & Technology,

Osaka University

むすび

35 博士論文　第４章

(36)

まとめ



下記のソースコード静的解析技術を提案・評価した

1. アクセス修飾子の解析手法



_AE

メトリクスを用いたアクセス修飾子解析手法を提案した



上記手法をツール ModiChecker に実装した



_ModiChecker

の適用実験により、以下を示した



_AE

・ NA の解析・可視化を実現した



_AE

は一度作り込まれると、 version up しても修正されず残る傾向にある



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

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

2. 高速なソースコード類似度判定手法



メトリクス比較を用いた類似判定手法を提案した



上記手法をツール Luigi に実装した



_Luigi

の適用実験により、以下を示した



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

度をもつことを示した

36

(37)

今後の研究方針



アクセス修飾子解析手法



_AE

が発生した原因をインタビューなどで調査する



AE

の発生を防ぐ開発環境を提供する



外部からの利用を想定した AE を自動判別する



テストケースも合わせて ModiChecker で解析する



品質（バグ）と AE の関連性を分析する



類似判定手法



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

として利用しやすいようにする



各メトリクスの閾値の設定を簡単にできるようにす

る



_Java

以外の言語への対応

37

(38)

発表おわり

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

(39)

以下、補足資料

(40)

業績一覧

主要論文

[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

(41)

(42)

ソフトウェア保守とは



ソフトウェア保守とは



納入後，ソフトウェアに対して加えられる，欠陥の修正，性能など

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



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

42

訂正

改良

是正保守

予防保守

適応保守

完全化保守

緊急保守

分類名

定義

是正保守ソフトウェア製品の引渡し後に発見された問題

を訂正するために行う受身の修正

緊急保守是正保守の内，実施までシステム運用を確保す

るための，計画外で一時的な修正

予防保守引渡し後のソフトウェア製品の潜在的な障害が

運用障害になる前に発見し，是正を行うための

修正

適応保守引渡し後，変化した又は変化している環境にお

いて，ソフトウェア製品を使用できるように保

ち続けるために実施するソフトウェア製品の修

正

完全化

保守

引渡し後のソフトウェア製品の潜在的な障害が

故障として現れる前に，検出し訂正するための

修正

修正の

分類

ソフトウェア保守の

分類

(43)

ソースコード解析



ソースコード解析の分類



ソースコード静的解析



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

る舞い情報を抽出する技術



ソースコードの中身を扱うため，網羅性の高い解析をすることが可能



ソースコード動的解析



ソースコードを動作環境上で実際に動作させ，その動作結果や動作中

のログなどを解析することで性質や振る舞い情報を抽出する技術



マルチスレッド処理など，ソースコード静的解析では発見が難しい　

振る舞いを解析することが可能



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



動作環境やテストケースの準備が不要であるため、　

現場への適用が容易な「ソースコード静的解析」に　

注目する。

(44)

研究対象とする課題①　

　　　　　　　　　「アクセス修飾子過剰性

の解析」



解決したい課題（その１）

「過剰に広いアクセス修飾子をもつフィールド，メ

ソッドに関する理解支援」



課題の具体例

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

対策の考察：

対策１：ドキュメントにプログラム内部構造を詳細に書く

　　　　　　　→作成コスト、メンテナンスコストが大きすぎる

　　　　　　　→膨大な資料を説明・理解するコストが大きすぎる

対策２：不正な呼び出しができないようにリファクタリングする

　　　　　　　→不正な呼び出しの可能性がある箇所の特定が難しい

　　　　　　　→設計時に想定した範囲より過剰に広い範囲からアクセスされる

　　　　　　　　フィールド・メソッドの解析・修正を支援したい

(45)

適用実験

(46)

ModiChecker

適用実験の概要



実験の目的



Validation of our approach



_{Quantitative analysis of AE Id in some software}

systems



_{Reasons for excessive/unused fields/methods}

(found by interviewing developers)

1. Reason 1 : Set for future use

2. 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}

₎

(47)

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

実際の

被アクセス

宣言

Public

Protected

Default

Private

NoAccess

Public

207

0

59

936

33 Protected

x

0

9

18

0 Default

x

4

5

2 Private

x

1123

5

47

AE

であるフィールドの数

NA

であるフィールドの数

(48)

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

実際の被

アクセス

宣言

Public

Protected

Default

Private

NoAccess

Public

816

14

23

190 1005

Protected

x

13

36

48

9 Default

x

0

3

0 Private

x

488

4

48

AE

であるメソッドの数

NA

であるメソッドの数

(49)

適用結果の考察



_AE

もしくは NA のフィールド / メソッドの数は以下のとおり



_AE

であるフィールド　 : 1027



_AE

であるメソッド　 : 512



_NA

であるフィールド : 40



_NA

であるメソッド　 : 1018



_NA(NoAccess)

であるフィールド（ 40 個）について内容を確認した

結果



将来的な利用を想定したもの： 8



外部からの利用を想定したもの： 5



_{serialVersionUID （直列化}

ランタイムからの使用を想定）



実際に未使用だったもの： 27



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

49

(50)

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

(51)

Ant

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

51

18.9%

(52)



_AE

フィールド　



総数（割合）　 : 611

_(18.9%)

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

2. 自動生成　 : 0

3. 設定ミス　 : unknown



_AE

メソッド



総数（割合）　 : 1520

_(35.5%)

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

2. 自動生成　 : 0

3. 設定ミス　 : unknown

1. AE

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

1. java bean

の制約上、実際のアクセス範囲に関わらず、 getter, setter メソッ

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

21/07/10 52

(53)

jEdit

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

53

(54)



_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)

応用実験②

(57)

バージョン毎のフィールド / メソッド分類



_AE

以外の状態を 2 つにグループ化し，

計 3 つの状態を定義

57

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

def-def

def-pri

def-na

Private

x

pri-pri

pri-na

③NA

宣言されてはいるが

どこからもアクセスされていな

い

①AE

アクセス可能な範囲が

実際のアクセス範囲より広い

② 適切

アクセス可能な範囲と

実際のアクセス範囲が一致

(58)

応用実験　概要

58

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

分析

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

況分析

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

の修正

　　　　　　　

がどれ程の頻度で行われているのかを明確にする

• _{計測データ：}

_{全バージョン間での ( 各種状態遷移総数 ÷ 全状態遷移}

総数 )

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

うかを

明確にする

• _{計測データ：修正された AE 数 ÷ 全バージョン内の AE 総数}



_{データの取得にはアクセス修飾子過剰性検出ツー}

ル ModiChecker を利用

(59)

バージョン間での状態遷移の分類

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

(60)

バージョン間での状態遷移の分類

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

(61)

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

遷移

61

適切

NA

AE

なし

0.02,71.42

0.16

0.02

0.04 0.07,15.28

0.00

0.03

0.03 0.00,2.28

0.13

0.21

6.41

2.03

1.41

0.46

(62)

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

%)

68

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

97%

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

71%

<

フィールド作成 >

「適切」で作成される場合が最も多い

<AE

修正， AE 発生，アクセス消失 >

アクセス修飾子の修正を伴う遷移は全体の 1% に満た

ない

(63)

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

%)

69

<AE

修正， AE 発生，アクセス消失 >

アクセス修飾子の修正を伴う遷移は全体の 1% に満た

ない

<

メソッド作成 >

比較的「 NA 」で作成される場合が多

い

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

96%

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

(64)

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

%)

70

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

97%

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

71%

<

フィールド作成 >

「適切」で作成される場合が最も多い

<AE

修正， AE 発生，アクセス消失 >

アクセス修飾子の修正を伴う遷移は全体の 1% に満た

ない

(65)

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

71

<AE

修正， AE 発生，アクセス消失 >

アクセス修飾子の修正を伴う遷移は全体の 1% に満た

ない

<

メソッド作成 >

比較的「 NA 」で作成される場合が多

い

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

96%

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

(66)

分析２結果 - フィールド AE 修正状況 (

単位 :%)

72

pub-def,pub-pri →

_{全 7 プロジェクトにて修正作業が行われている}

pro-def,pro-pri,def-pri →

6 プロジェクトにて修正作業が行われて

いる

AE

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

(67)

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

位 :%)

73

pub-def,pub-pri →

_{全 7 プロジェクトにて修正作業が行われて}

いる

pub-pro,pro-pri →

6 プロジェクトにて修正作業が行われている

AE

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

ない

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

(68)

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

%)

74

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

97%

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

71%

<

フィールド作成 >

「適切」で作成される場合が最も多い

<AE

修正， AE 発生，アクセス消失 >

アクセス修飾子の修正を伴う遷移は全体の 1% に満た

ない

(69)

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

75

<AE

修正， AE 発生，アクセス消失 >

アクセス修飾子の修正を伴う遷移は全体の 1% に満た

ない

<

メソッド作成 >

比較的「 NA 」で作成される場合が多

い

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

96%

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

(70)

Department of Computer Science,

Graduate School of Information Science & Technology,

Osaka University

76

ソースコードの静的特性を用いた

Java

プログラム間類似度測定ツール

(71)

背景

これらのソースコードは，開発者に

とって

有益な再利用部品である可能性があ

る

再利用を活用するためには，過去に

開発された類似なソフトウェア部品

に関する情報を入手することが必要

インターネットの普及により

大量のソースコードが比較的

容易に入手可能となった

ソフトウェアを収集して

再利用部品検索システムを構築

ソフトウェア開発効率を飛躍

的に向上するための手法とし

て、再利用が注目されている

再利用とは既存の類似ソフト

ウェア部品を参照し，一部手

直しをして用いること

(72)

背景

これらのソースコードは，開発者に

とって

有益な再利用部品である可能性があ

る

再利用を活用するためには，過去に

開発された類似なソフトウェア部品

に関する情報を入手することが必要

インターネットの普及により

大量のソースコードが比較的

容易に入手可能となった

ソフトウェアを収集して

再利用部品検索システムを構築

ソフトウェア開発効率を飛躍

的に向上するための手法とし

て、再利用が注目されている

再利用とは既存の類似ソフト

ウェア部品を参照し，一部手

直しをして用いること

(73)

背景

これらのソースコードは，開発者に

とって

有益な再利用部品である可能性があ

る

再利用を活用するためには，過去に

開発された類似なソフトウェア部品

に関する情報を入手することが必要

インターネットの普及により

大量のソースコードが比較的

容易に入手可能となった

ソフトウェアを収集して

再利用部品検索システムを構築

ソフトウェア開発効率を飛躍

的に向上するための手法とし

て、再利用が注目されている

再利用とは既存の類似ソフト

ウェア部品を参照し，一部手

直しをして用いること

(74)

背景

これらのソースコードは，開発者に

とって

有益な再利用部品である可能性があ

る

再利用を活用するためには，過去に

開発された類似なソフトウェア部品

に関する情報を入手することが必要

インターネットの普及により

大量のソースコードが比較的

容易に入手可能となった

ソフトウェアを収集して

再利用部品検索システムを構築

ソフトウェア開発効率を飛躍

的に向上するための手法とし

て、再利用が注目されている

再利用とは既存の類似ソフト

ウェア部品を参照し，一部手

直しをして用いること

(75)

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

(76)

SPARS-J

（ 2/2 ）



_{Component Rank}

の計算では，部品間のコピー関係を把握す

るために類似度を測定している



類似部品を一つの部品群として扱い，利用関係を合成する



評価値にコピー関係を反映させることが可能

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

B

E

部品 A

C

F

D

部品 A´

F

C

部品群 A

B

D

+

類似

E

合成

(77)

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



ハッシュ関数 h(

_T

_total

₎

を用いた加工



｜ h(

_T

_total

₎

－ h(

_T

_total

_×0.97

₎

｜≦ １



｜ h(

_T

_total

_×1.03

₎

－ h(

_T

_total

₎

｜≦ １



　

_log

_1.04

_{（ T}

_total

_）

h(

T

_total

)

T

_total

2

1

3

4

6

5 T

_total

(78)

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



ハッシュ関数 h(

_T

_total

₎

を用いた加工



｜ h(

_T

_total

₎

－ h(

_T

_total

_×0.97

₎

｜≦ １



｜ h(

_T

_total

_×1.03

₎

－ h(

_T

_total

₎

｜≦ １

h(

T

_total

)

T

_total

2

1

3

4

6

5 T

_total

×0.97

T

_total

×1.03

(79)

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



現状の問題点

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

スを

用いて比較を行っている。

新しい部品が入ってきた場合、全部の既存部品と 102 種類のメトリクスの

比較を行なわないとならない



アイデア

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

？

1. トークンの総出現回数が 0.97 倍未満 or 1.03 倍超である部品

2. 複雑度メトリクスが閾値を超える部品



実現方法

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

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

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

Department of Computer Science,

Graduate School of Information Science & Technology,

Osaka University

ソースコードの静的解析による

ソフトウェア保守支援に関する研

究

大阪大学大学院情報科学研究科

コンピュータサイエンス専攻 井上研究

室

小堀 一雄

1

ソフトウェア保守とは



ソフトウェア保守とは



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

性能などの改善，変更された環境に適合させるための修正

． [IEEE Std 1219]



保守に関するコスト



全ライフサイクルの 3 分の２を占める



20

年以上も保守を続けているシステムも存在する

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

い

ソフトウェア保守の課題



課題



保守担当者に以下を理解させるのが重要である

1.

どのように修正すべきか？

2.

どこを（どこまで）修正すべきか？



保守を難しくする要因



社会基盤を担う重要なソフトウェアは、大規模化

・複雑化・ライフサイクルの長期化が進む



保守期間中にドキュメント最新化が成されず、実

際の動作と乖離が発生



保守のアウトソーシングやオフショアが進み、仕

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

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



保守支援に関する様々な手段



リバースエンジニアリング



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



回帰テスト



修正することでデグレードした箇所を特定する



ソースコード動的分析



ソースコードの実行結果から振る舞いや特徴を分析



動作環境とテストケースが必要



ソースコード静的解析



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

析



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

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

援



ソースコード静的解析

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

た情報をもとに，プログラム保守の支援を目的として様々な

解析が行われている．代表的な例を以下に示す．



コンピュータサイエンス専攻井上研究

小堀一雄

₂₀

研究対象とする課題①　

　　　　　　　　　「アクセス修飾子過剰性の解析