Document

ソースコード更新履歴を利用した
変更危険度計測システムの試作
大阪大学基礎工学部情報科学科
井上研究室
村尾憲治
ソフトウェア開発
• 開発の大規模化・複雑化
• 開発の多人数化
開発の管理が重要
版管理システムが広く利用されている
2
版管理システム
• ソフトウェアの開発履歴を保
存・提供するシステム
開発者
開発者
– 開発者はソースコードの作業用コ
ピーを得る（チェックアウト）
• 開発者は作業用コピーを更新
– ソースコードの更新内容を版管
理システムに反映（チェックイン）
– 全ての更新の内容は版管理シス
テムに蓄積される
版管理システムには過去の開発
過程の情報が保存されている
版管理
システム
チェック
アウト
チェック
イン
更新
作業用
コピー
開発者
3
ソフトウェア開発の問題点
開発の複雑化・多人数化
変更すると問題が発生する危険性のある
箇所の判断が難しい
開発者
この箇所は変更して
もいいのだろうか？
変更すると
• 仕様に反する可能性
• 開発を混乱させてしまう可能性
 適確な判断にはソフトウェアの十分な理解が必要
しかし，十分な理解は困難で時間がかかる
4
研究の目的
変更すると問題が発生する危険性の
ある箇所を知りたい
• メトリクスを定義
「変更危険度」
＝変更すると問題が発生する可能性の大きさ（粒度：行）
• 変更の難しい箇所を判断
– その箇所への変更を避ける
– 他の開発者に相談
• 変更危険度を計測するシステムを作成
5
変更危険度の大きい箇所
• 過去に変更が行われたが，後に変更前の状
態に戻された箇所
– 変更を行っても以前と同じように戻される可能性
• 現在頻繁に更新されている箇所
– 迂闊に変更を加えると開発を混乱させる可能性
過去の開発過程から知ることができる
版管理システムに蓄積されている
6
提案する手法（概要）
• 過去の更新過程から変更危険度を計測
→ 版管理システムから入手できる情報を利用
• 更新パターンを分析
「更新パターン」
＝過去の更新過程にみられる
「どのように更新されてきたか」という情報
• 変更危険度は複数の更新パターン毎に計測
– 対象：最新ソースコードの各行
7
提案する手法（図）
版管理システム
更
新
ソースコードの
過去の更新内容
（変更された行，
更新日時など）
更
新
更
新
更
新
更新パターン
の検出
変更危険度の計測
更
新
更
新
更新パターン毎の
変更危険度
更新の過程を再現
最新のソースコード
8
更新過程の再現
版管理システム
• 各時点について
– 取得した更新日時情報の保存更
• 変更危険度の計測などに利用
ソースコードの
過去の更新内容
（変更された行，
更新日時など）
新
更
新
更
新
更新パターン
の検出
– 更新された行の情報から，更新前後の行と行間
変更危険度の計測
の対応関係を導出
• 更新パターンの検出や変更危険度の計測に利用
更
新
更
新
更
新
更新パターン毎の
変更危険度
更新の過程を再現
最新のソースコード
9
更新前後の行と行間の対応
• 行だけでなく，行間についても対応関係を把握
追加
削除
i
i+1
i
i+1
k
k+1
l
l+1
行k と行k+1 の行間から
行l と行l+1 の行間まで
k
k+1
行i と行i+1 の行間から
行j と行j+1 の行間まで
j
j+1
変更
i
i+1
j
j+1
行i と行i+1 の行間
行k と行k+1 の行間
k
k+1
行i と行i+1 の行間から
行j と行j+1 の行間まで
l
l+1
行k と行k+1 の行間から
行l と行l+1 の行間まで
10
更新パターンの検出
• 今回対象とする更新パターン
版管理システム
– 一度更新された部分が，後になって戻されている
• 更新したがうまくいかなかった可能性
更
更
更
• 検出箇所・・・更新後の内容が以前にも存在した箇所
新
新
新
• 値・・・戻されている行数
ソースコードの
更新パターン
過去の更新内容
– 変更されている量が多い
の検出
（変更された行，
更新日時など）
• 大規模な修正がなされた可能性
変更危険度の計測
• 検出箇所・・・更新が行われた箇所
• 値・・・変更された行数
– 頻繁に更新されている
更
更
更
新
新
• 開発途中である可能性
更新パターン毎の
• 検出箇所・・・更新が行われた箇所変更危険度
更新の過程を再現
最新のソースコード
• 値・・・更新された回数
新
11
「戻されている」とは
変更
変更・追加
同じ内容の行が存在
＝戻されている
削除
変更・追加
同じ内容の行が存在
＝戻されている
追加
削除
追加された行が
削除されている
＝戻されている
12
変更危険度の計測
版管理システム
• 更新パターンの検出結果を統合
– 更新パターン毎に変更危険度を計測
更
更
更
新
新
• 戻されているパターン・・ CR(U)新
ソースコードの
• 変更されている量が多いパターン
・・ CR(A)
更新パターン
過去の更新内容
の検出
（変更された行，
• 頻繁に更新されているパターン・・ CR(F)
変更危険度の計測
更新日時など）
– 検出した値に時間的な重み付けを行う
• 古い情報ほど重要度を下げる
更
–更最近の更新の方が影響が強い
新
新
更新パターン毎の
– ソースコードの改善による変更危険度の低下を表現
変更危険度
更新の過程を再現
更
新
最新のソースコード
13
時間的な重み
• 必要条件
– 古いほど重みが小さい
– 無限大に古い → 重みが0に収束
– 乗算で用いるため，以下のような式が成り立つ
（1ヶ月前の重み）×（2ヶ月前の重み）＝（3ヶ月前の重み）
時間的な重み w αx
0 α 1 ， x ：経過時間
14
計測の手順
1. 各開発時点の時間的な重み wi を決定
2. 各開発時点において，変更危険度を求める行に対応する
範囲を調べる
3. 対応する範囲で検出された値の合計値 vi を取得
4. 各開発時点の vi  wi の値を合計する
時間的な重み： w2 時間的な重み： w1 時間的な重み： w0 ( 1)
w2
検出した値：v2
検出した値：v1
検出した値：v0
 w1  w0
変更危険度
  (vi  wi )
i 0
過去のソースコード
最新のソースコード
15
変更危険度計測システムの実装
• 提案手法を実装するシステムを試作した
– 開発言語・・Java
– 総行数・・約6000行
– 出力結果の閲覧はウェブブラウザを利用
– 表示する変更危険度の値に色付け
• 更新パターン別に値の大きさに応じた色
低
←
ソースコード内の最小値
変更危険度の値
→
高
ソースコード内の最大値
16
出力例
17
出力例（詳細情報）
18
評価実験
• 実験対象
– CREBASS
• CVSリポジトリ閲覧・検索システム
• 開発言語・・Java
• 実験目的
– 変更危険度の出力結果を見ることで，変更する
と問題が発生する危険性のある箇所を知ること
ができることを確認
19
評価方法
• 3種いずれかの変更危険度の値が大きい箇所につ
いて開発者にアンケート
– データベース作成の機能を実装する8つのソースコード
から26箇所（コメント部などは除いた）
– アンケート内容
•
•
•
•
•
過去にバグを発生したことがあったか
アルゴリズムが複雑であるか
他のモジュールに影響を及ぼしやすいか
実装方法を何度も変更したか
上記以外の問題が過去に存在したか
– アンケートのいずれかの項目に該当
→ 変更により問題が発生する危険性あり
20
アンケート結果
箇
所
数
過去にバグが発生
6
アルゴリズムが複雑
0
他のモジュールに影響
0
実装方法を何度も変更
12
上記以外の問題
1
小計 19
該当なし
内訳
CR(A) CR(F) CR(U), CR(A),
CR(F) CR(F)
1
5
1
3
上記以外の問題・・・仕様の変更
6
1
1
2
7
合計 26
1
全て
8
1
7
1
1
7
1
7
2
15
適合率： 0.73
21
考察（1/2）
• 適合率 0.73
– 本手法は概ね有効
• CR(U)
– CR(U)の値が大きい箇所
• 全て「実装を何度も変更」した箇所
→ 仕様や設計上の問題による危険性把握に有効
• CR(A)
– CR(A)の値が大きい箇所
• CR(F)の値も大きい場合が多い
• CR(A)単体の特徴は明確に発見できず
→ 更なる実験が必要
22
考察（2/2）
• CR(F)
– CR(F)の値のみが大きい箇所・・ 15箇所
• 内7箇所は「該当なし」の箇所
– 設計やアルゴリズムの変更に伴い最近更新
» 実質一人で開発しているため，危険とは思わなかった
→ 多人数の開発では危険である可能性
• 対象とした箇所以外にも危険な箇所は存在
– 本手法では抽出できていない
• 新たな更新パターンの考案が必要
23
まとめと今後の課題
• 版管理システムに保存されたソースコードの更新履
歴を利用し，変更危険度を計測する手法を提案
• 手法を実装するシステムを試作し，実際のソフトウェ
アに適用
– 手法の有効性を確認
• 今後の課題
– 構文解析の導入
– 新しい更新パターンの考案
– 多人数で開発されているソフトウェアに対する評価実験
24

Download Report