大規模収集データに基づいた ソフトウェアエンジニアリング

1. SPES2003ソフトウェアプロセスエンジニアリングシンポジウムSPES2003ソフトウェアプロセスエンジニアリングシンポジウム 大規模収集データに基づいたソフトウェアエンジニアリング 井上克郎 大阪大学大学院情報科学研究科

2. ソフトウェア開発は工学？

3. ソフトウェア開発の現状と問題点 • ソフトウェアの信頼性 • 多数のバグを含んだソフトの流通 • 一度ダウンすると多大な社会的損失 • ソフトウェアの生産性 • 開発期間の短縮要請 • 人海戦術による限界 • 経験的なノウハウや非科学的な手法，ツールを使う場合が多い

4. 科学的手法に基づくソフトウェア開発 • 多くの他の科学、工学分野では、計測して定量化し、評価を行い、それをフィードバックして改善を行うのが普通（フィードバックループ） • ソフトウェア開発の分野では？

5. Zelkowitz-Wallaceによる評価法分類 • 観測型(Observational)実際に行われているプロジェクトを横から観測して評価 • 履歴型(Historical)過去に行われたプロジェクトのデータや発表された論文に基づいて評価 • 制御型(Controlled)目的とするデータを得るために環境を整えてプロジェクトを行い評価する V. Zelkowitz, D. R.Wallace, "Experimental Models for Validating Technology", IEEE Computer, pp.23-31, May 1998.

6. 観測型評価 • プロジェクトモニタ • 対象を漠然と観察。目標不明確な場合も。簡単 • 事例研究 • 対象をより深く解析。まだ、変動要素の制御が不十分だが、比較的簡便 • アサーション • 主張がなりたつことを簡単なプロジェクトで実証。厳密な評価としては不十分。 • 野外調査(Field Study) • いろいろなプロジェクトを見て回る。条件を揃えるのが困難だが追証しやすい。

7. 履歴型 • 文献調査 • 過去発表された論文を探す。条件や視点の統一不可能。簡単 • 事例調査 • 過去のプロジェクトデータをひっくりかえす。条件不統一でデータ限られている • 経験 • 過去のプロジェクトの定性的なデータを調べる。定性的な議論できない。やりやすくて簡単に傾向がわかる • (静的解析) • 作ったプロダクトの解析をする。方法には適用できない。評価の自動化できるかもしれない。

8. 制御型 • 繰返し • 条件を揃えていくつものプロジェクトで繰り返す。高価。 • 実験室 • 条件を揃えて実験室で繰り返す。スケーラビリティ。条件を制御しやすく比較的安価。 • (動的解析) • プロダクトの効率を実行させて計測。方法には適用できない。 • (シミュレーション) • 仮想データで実行。

9. 発表された論文の分類（他の科学） 方法＼論文種類 デバイス 物理 臨床医学 人類学 評価なし 16% 58% 6% 31% プロジェクトモニタ 事例評価 40% 16% 6% 8% アサーション 8% 4% 8% 野外調査 18% 文献調査 4% 11% 24% 23% 事例調査 6% 23% 経験 5% 8% 静的解析 繰返し　　 5% 12% 実験室　　 29% 動的解析 32% 5% シミュレーション

10. ソフトウェア工学の現状 • 30年に亘って，いろいろな技法，システム，ツールなどの提案がされてきた． • あまりにも，言いっぱなしの提案が多い • 評価するために手間暇かかる －＞ 歴史で評価 （ICSE n-10)

11. ソフトウェア工学の論文が使っている評価法 実験なし プロジェクトモニタ 事例研究 アサーション 野外調査 文献調査 1985 評価法 事例調査 1990 -ICSE -TSE -IEEE Software 1995 経験 静的解析 繰返し 実験室 動的解析 シミュレーション 0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 論文の割合

12. Empirical Software Engineering

13. エンピリカルソフトウェア工学 • 定量的なデータに基づいてソフトウェア工学におけるいろいろな手法、技術、ツールなどの評価を行う • データの収集が必須 • 実際の開発現場のデータ • オープンソース開発プロジェクトのデータ • エンピリカルソフトウェア工学に関する雑誌、国際会議、研究機関ができつつある

14. Journal by KluwerEmpirical Software Engineering

15. 2002 International Symposium on Empirical Software Engineering

16. Fraunhofer IESE Model • Fraunhofer財団（政府系研究支援） • Institute for Experimental Software Engineering • 大学工房モデル • Kaiserslautern大学を基礎 • 大学から車で10分 • 仕事内容 • ソフトウェア開発に関わる技術評価 • ソフトウェア品質向上システムの設計 • 品質規格認証への支援 • ソフトウェア技術者教育の支援 • ソフトウェア購入・発注・開発管理の支援

17. Fraunhofer Institute for Experimental Software Engineering

18. これからのソフトウェアエンジニアリング

19. 計測・検索 評価・分析 フィードバック 粒度 対象 目的 形態 プロジェクト群（企業内全資産、全オープンソース等） 部品共通化、リファレンスモデル・標準化 粗 パターンや部品、知見の抽出、 利益予測 プロセス改善、資産再利用 単一プロジェクト 進捗把握、コスト管理 既存のソフトウェア工学技術 各開発者の作業や生産物 ユーザビリティ・問題把握 ヘルプ、ツール・ガイドライン 細 データの粒度による分類

20. 粗粒度データを対象としたSE ＊ （実用化はまだまだだが）ソフトウェア工学として細・中粒度はかなり研究されている 　　　→　LocalSoftware Engineering ＊粗粒度を陽に意識したソフトウェア工学まだない 　 →　GlobalSoftware Engineering ＊ 組織の利益に直結する結果が得やすい ＊ 基礎となる技術の種はいろいろある ＊ 計算機のパワーアップ、ネットワークの高速化によって、実現できそうな気配

21. ターゲットとなる研究・開発 • プロジェクトにまたがった大規模データの収集，蓄積技術(Inter-project Data Collection) • 得られたデータを大域的に解析・評価技術(Global Analysis) • 評価結果に基づいて経験や知識を資産化する技術(Software Asset Management) • 粒度間の情報交換技術(Knowledge Circulation)

22. 目指すシステム

23. システム使用イメージ • プログラムの生産性が、社内的な再利用やオープンソースの利用で劇的に上がる • 管理しきれなかった膨大な社内資産が、見通しよく整理できた • 過去の同類のプロジェクト情報を有効利用して、コスト管理が厳密になった • 蓄積した欠陥情報を利用して、信頼性を大幅に改善された

24. 関連基礎技術(1)コードクローン検出

25. クローンクラス コードクローン • ソースコード中に類似したコード片があるとき、それらをコードクローンという コードクローンはソフトウェア保守を困難にする クローンペア

26. コードクローン検出ツーCCFinder • ソースコードをトークン単位で直接比較することによりクローンを検出 • 数百万行規模のシステムにも実用時間で解析可能 • 実用的に意味のあるクローンのみを検出 • 名前空間の正規化（ユーザー定義名の置き換えに対処） • テーブル初期化部分を取り除く • モジュールの区切りを認識する

27. CCFinderの処理概要(1) ソースコード CCfinder 字句解析 トークン列 変換処理 変換後トークン列 検出処理 クローン情報 出力整形処理 クローンペア位置情報

28. CCFinderの処理概要(2) ソースコード 字句解析 1. static void foo() throws RESyntaxException { 2. String a[] = new String [] { "123,400", "abc", "orange 100" }; 3. org.apache.regexp.RE pat = new org.apache.regexp.RE("[0-9,]+"); 4. int sum = 0; 5. for (int i = 0; i < a.length; ++i) 6. if (pat.match(a[i])) 7. sum += Sample.parseNumber(pat.getParen(0)); 8. System.out.println("sum = " + sum); 9. } 10. static void goo(String [] a) throws RESyntaxException { 11. RE exp = new RE("[0-9,]+"); 12. int sum = 0; 13. for (int i = 0; i < a.length; ++i) 14. if (exp.match(a[i])) 15. sum += parseNumber(exp.getParen(0)); 16. System.out.println("sum = " + sum); 17. } トークン列 変換処理 変換後トークン列 検出処理 クローン情報 出力整形処理 クローンペア位置情報

29. CCFinderの処理概要(3) ソースコード 字句解析 トークン列 変換処理 変換後トークン列 検出処理 クローン情報 出力整形処理 クローンペア位置情報

30. CCFinderの処理概要(4) ソースコード 字句解析 トークン列 変換処理 変換後トークン列 検出処理 クローン情報 出力整形処理 クローンペア位置情報

31. CCFinderの処理概要(5) ソースコード 1. static void foo() throws RESyntaxException { 2.String a[] = new String [] { "123,400", "abc", "orange 100" }; 3.org.apache.regexp.RE pat = new org.apache.regexp.RE("[0-9,]+"); 4. int sum = 0; 5. for (int i = 0; i < a.length; ++i) 6. if (pat.match(a[i])) 7. sum += Sample.parseNumber(pat.getParen(0)); 8. System.out.println("sum = " + sum); 9. } 10. static void goo(String [] a) throws RESyntaxException { 11. RE exp = new RE("[0-9,]+"); 12. int sum = 0; 13. for (int i = 0; i < a.length; ++i) 14. if (exp.match(a[i])) 15. sum += parseNumber(exp.getParen(0)); 16. System.out.println("sum = " + sum); 17. } 字句解析 トークン列 変換処理 変換後トークン列 検出処理 クローン情報 出力整形処理 クローンペア位置情報

32. 適用例#1 JDKのライブラリ • JDK（Java Development Kit） 1.2.2（サンプルとデモプログラムを除く） • 入力ファイルは164８個，約50万行 • ツールの実行には，Pentium III 650MHzおよび1GBのRAMを持つPCで約3分を要した

33. JDKのコードクローン散布図 • 両軸はソースファイルを辞書順に並べたもの • 20行以上のコードクローンを図示 • 多くのコードクローンが密集している（A) • 最長のコードクローン（B） B A

34. コードクローンが密集している部分（A） • src/javax/swing/plaf/multi/*.java（29個） • クラス名を除いてまったく同じクラスの定義 • コード生成ツールによって生成された 31| */ 32| public class MultiButtonUI extends ButtonUI { 33| 160| public static ComponentUI createUI(JComponent a) { 161| ComponentUI mui = new MultiButtonUI(); 162| return MultiLookAndFeel.createUIs(mui, 163| ((MultiButtonUI) mui).uis, 164| a); 165| }

35. 最長のコードクローン（B） • 最長のコードクローン（349行） • src/java/util/Arrays.javaの18の“sort”メソッド • シグネチャ（引数の型と数）が異なる • アルゴリズムは同一

36. FreeBSD, Linux, NetBSDの比較 • 3つのOSの比較 • FreeBSD 4.0 (C 220万行) • Linux 2.4.0 (C 240万行) • NetBSD 1.5（C 260万行) • FreeBSDとNetBSDは同じソースコードから，Linuxは異なるソースコード • 実行には108分を要した

37. UNIXカーネル間のコードクローン

38. FreeBSDとLinuxのコードクローン • ドライバ部分に多くのクローン「ファイル」が存在する • 共通のソースから分岐したソースファイル • 名前が付け替えられたソースファイル • あるソースファイルを複数のファイルに分割している →

39. 関連基礎技術(2)ソフトウェアシステムの類似度関連基礎技術(2)ソフトウェアシステムの類似度

40. Q P 類似度の定義 • 二つのプロダクトP={p1,…,pm},Q={q1,…,qm}に対し、等価な要素の対応R⊆P×Qが得られるとする • PとQのRに対する類似度S(0≦S≦1)を以下のように定義する

41. CCFinderを利用したシステム間類似度 SMMT 前処理後のP P Step1 Step2 Step3 前処理 CCFinder の実行 CCFinder の実行結果 diff の実行 Q diff の実行結果 前処理後のQ Step4 対応の 抽出 抽出結果 Step5 類似度の 計算 類似度

42. 実験 • UNIX系OSを用いて類似度を計算した • 4.4BSDLite, 4.4BSDLite2 • FreeBSD2.0, 2.0.5, 2.1, 2.2, 3.0, 4.0 • NetBSD1.0, 1.1, 1.2, 1.3, 1.4, 1.5 • OpenBSD2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8 • 23個のOSのすべての組み合わせで類似度を求めた • カーネル部分のC言語のソースのみ

44. 同一種類のOS間での類似度 • FreeBSD 2.2との間の類似度

45. 異なる種類のOS間での類似度 • FreeBSD3.0とNetBSD1.3で4.4BSDLite2が取り込まれている

46. 類似度を距離とした系統樹

47. 関連基礎技術(3)ソフトウェア部品検索

48. ソフトウェア部品の再利用 • 膨大なソフトウェアが毎日開発され続けている • 同様なソフトウェア部品 (ライブラリやコード片、抽象的なアルゴリズム ...) が異なるところで独立に開発されているかもしれない • 高信頼性、高生産性の鍵 • 再利用 • ソフトウェアライブラリを探し回るのは大変 • サーチ機能が貧弱 • 整合性を保った管理は困難 • 人手を介さない、自動的に保存、検索ができる部品ライブラリが必須

49. 部品ランクモデル • 検索結果の表示順を決めるためのモデル • プログラム部品(component)群をグラフ化 • 部品の重み計算 • 重みの順序：部品ランクComponent Rank (CR)

50. 部品グラフ システム Y システム X A B F C G D E H I 部品 利用