Analysis for Evolution

ANALYSIS FOR EVOLUTION阪大井上研神田哲也・石尾隆

1

セッション K

AUTOMATED ANALYSIS OF CSS RULES TO SUPPORT STYLE MAINTENANCEAli Mesbah and Shabnam Mirshokraie

2

論文 K1

概要• Cascading Style Sheets(CSS) 中の不要な記述を特定する

• 不要な記述： CSS 適用先のドキュメントに記述に対応する要素がない、

対応する要素はあるが他の記述が優先される• 不要な記述の問題点：

• 通信路やメモリの容量圧迫• ブラウザへの負荷• 可読性の低下

• これまでの CSS に関する解析は静的解析が主• 精度もあまりよくない• 動的解析を使う

CSS の適用例• CSS:HTML 要素の表示に関する指示

• 継承、波及、セレクタの詳細度など数々の特徴• Document Object Model （ DOM ）

• 実行時の HTML を表す標準的なオブジェクトモデル

• CSS の適用先

4

#news { background-color: silver; font: italic; color: black; }.sports { color: blue; text-decoration: underline; }H3 , H4 { font−family : sans−serif; }.latest { color: green;}#news span{ color: red; }P.Select { font−size: medium; }

<HTML>　 <HEAD>　　 <LINK href="example.css" rel="stylesheet“　　　 type="text/css" />　 </HEAD>　 <BODY>　　 <P id=‘news’ style='font:normal'>World　　　 <SPAN class = 'latest'>latest news</SPAN>　　 </P>　 </BODY></HTML>

<HTML>　 <HEAD>　　 <LINK href="example.css" rel="stylesheet“　　　 type="text/css" />　 </HEAD>　 <BODY>　　 <P id='news' style='font:normal'>World　　　 <SPAN class='sports'>Sports news</SPAN>　　 </ P>　　 <DIV class='sport'>Football</DIV>　 </BODY></HTML>

例：赤のプロパティのみが右の 2 つの DOM で有効になっている

↓ セレクタ　　　　↓プロパティ CSS

DOM

CSS と DOM の関係• Matched Selector ：

CSS セレクタに対応する DOM 要素が存在する• Unmatched ：対応する DOM 要素が存在しないので不要

• Effective Selector ：CSS セレクタが実際に適用される DOM 要素が存在する• Ineffective ：ほかのセレクタの優先度が高いため適用されないので不要• 個々のプロパティについても同様に考えることができる

• Unused = Unmatched + Ineffective

• Defined Class Values ：DOM 要素のクラスに対応する CSS セレクタが存在する• Undefined ： JavaScript など他の目的で利用される場合を除き不要

5

評価実験• 対象： 15 のウェブベースシステム

• ２つはオープンソース• ７つは Yahoo! のランダムリンクから• さらに６つのウェブサイトを追加• 正解集合は CSS ルールのうちランダムに選んだ max( 全体の 2

割 ,20 個 ) を手動で分析して決定• 結果

• Recall は 100%,F 値 90 ～ 100%• 比較対象の 2 ツールは Recall が 65 ～ 100% 、 F 値 40 ～ 90%

• 平均 59.47% の未使用 CSS セレクタ、 52.07% のプロパティを検出

• Unused なセレクタのうち 71.4% が Ineffective

6

GRAPH-BASED ANALYSIS AND PREDICTION FOR SOFTWARE EVOLUTIONPamela Bhattacharya, Marios Iliofotou, Iulian Neamtiu and Michalis Faloutsos

7

論文 K2

論文の概要• 長期間開発されているシステムを対象として，グラフに関するメ

トリクスの有効性を調査した• 調査対象

• C/C++ (10 システム ): Firefox, Blender, VLC, MySQL, Samba, Bind,

Sendmail, OpenSSH, SQLite, Vsftpd

• Java (1 システム ): Eclipse

• 9 年以上開発が続いているもの• 調査方法

• 関数のコールグラフ，モジュール間の参照グラフを使って３つの調査• 開発者間の関係グラフ 2 種を使って１つの調査• 調査ごとに，使用したグラフ・メトリクス・システムは異なることに注意• グラフに関するメトリクスを多数のバージョンについて調査したことが新

規性

8

論文で報告されている内容• グラフに関するメトリクスの用途を４つ示した

• 関数のコールグラフに関するメトリクスは，ソフトウェアが違っても似たような値の変動をする (4 章 )

• メトリクスの突然の変化は，システム構造の大きな変化に対応する

• 関数・モジュールは，多くの関数・モジュールから参照されているものほど，そこで発生したバグの Severity が高い (5 章 )

• モジュール性を表現する ModularityRatio メトリクスが高いほど，そのモジュールの Maintenance Effort は小さい (6 章 )

• 開発者間でのバグ対応の協力関係グラフ（１年単位）が変化するほど，そのシステムはバグが多い (7 章 )

9

関数・モジュールに関するグラフ一般的に使われている定義と同様

• 関数のコールグラフ• 関数をノードとする有向グラフ• 関数 f1, f2 について， f1 が f2 を呼び出しているとき辺 f1 f2 を持つ• Dynamic Dispatch はすべての可能性を考慮

• モジュール間の参照関グラフ• モジュールをノードとする有向グラフ• モジュール A, B について， A の関数が B の関数を呼び出している，

もしくは， A の関数が B の変数にアクセスしているとき，辺 A B を持つ

10

グラフに対するメトリクスソフトウェアごとにあまり違いはない（進化には共通性がある）．値の大きな変化から，構造の変化が検知できると述べている．• Average clustering coefficient

• ある頂点 u に接続されている頂点が，互いに接続されている確率（密結合なグラフで値が高い）

• Graph diameter• グラフの任意の２頂点間での最短経路長の最大値

• Assortativity• 各辺が接続している２頂点が同じぐらいの次数を持っているかどうかを判定す

る値• Number of nodes in cycles

• グラフ内で，有向辺で循環的に接続された頂点の数

11

頂点に対するメトリクス• Node Rank

• Page Rank 系メトリクス．多数のノードから直接・間接的に参照されているノードほど値が高い

• Bug Severity と相関あり（値が高いノードほど， Bug Severity が高い）

• Modularity Ratio• モジュール間よりもモジュール内の呼び出し・変数アクセスが多い

ほど値が高い

• 値が高いノードほど， Maintenance Effort （リリースごとの「コミット回数 ÷編集行数」）が低い

12

収束するまで反復計算 .総和が 1 になるよう正規化

開発者間のグラフに関する調査• 開発者を頂点とするグラフ 2 種を定義

• 同じチームで仕事をしていると生産性が高くなると仮定• グラフの変化量と，バグの個数を調べた

• Bug-tossing collaboration: 開発者 A が担当していたバグが（ A には解決できなかったので）開発者 B に割り当てられたとき A B

• File-based collaboration: 開発者 A と B が同じファイルを編集していれば A—B (無向辺 )

• 1 年ずつの活動に対して作った Bug-tossing グラフの Edit

distance ( 変化量 ) が大きいほど，バグ数が多い• File-based collaboration では相関が認められなかった

13

INTEGRATED IMPACT ANALYSIS FOR MANAGING SOFTWARE CHANGES

Malcon Gethers, Bogdan Dit,

Huzefa Kagdi, Denys Poshyvanyk

14

論文 K3

論文の概要•「追加情報があれば使う」 Impact Analysis の提案本論文での Impact Analysis とは： Change Request に対して，変更する必要があるすべてのメソッドを特定すること Impact Analysis: CR a set of methods

• 著者らが従来行ってきた Feature Location は，ある機能に対応するソースコード位置を特定する技術．• Feature Location した範囲を基点に Impact Analysis を実行する，と別論文

で述べられている• 要素技術としては，これまでの Feature Location 技術を少し改変したもの

• 再テストが必要な範囲を特定する技術ではない

• 単純な IR 手法と比較して，追加情報による出力の改善度合いを示した

15

Impact Analysis の計算手順 (1/2)

• 基本形 (IRCR) ： LSI を使用した文書類似度の計算1. メソッド単位を文書として tf-idf の単語出現頻度行列を作成

• 予約語除去，長い識別子の単語への分解，動詞の原型への変換2. LSI を適用3. Change Request を文書とみなした場合の，各メソッドとのコ

サイン尺度を計算し，類似度の高い順でランキングを作る

• 実行履歴が存在する場合 (IRCRDynCR)1. Change Request に書かれている機能実行手順を使ってプログ

ラムを実行し，実行されたメソッド情報を記録2. IRCR のランキングから，実行されてないメソッドを取り除く

16

Impact Analysis の計算手順 (2/2)

• バージョン管理システムに履歴が存在しており，かつ，１つのメソッドが「正解」と判明している場合（ IRCRHistseed ）1. 編集内容が同時にコミットされているメソッドを Itemset Mining で探索

2. あるメソッドが編集されたら他のメソッドも編集されている，という Association Rules へと変換

3. 開発者がどうにかして（ Feature Location などで）選んだ「正解」メソッドを基点に，適用可能な Association Rules の強い順にメソッドをランキング

• 同時に変更される可能性が高いものほど上位4. IRCR のランキング上位 N/2 件と Histseed の上位 N/2 件を足して N 個

のランキングを作る• N 個に達するまで，２つのランキングから交互に追加候補を取り込む

• ３種の組み合わせ IRCRDynCRHistseed

• IRCRHistseed の最後のステップで使うランキングを IRCR から IRCRDynCR

に変更

17

評価実験• ４つの Java システムを対象 : ArgoUML, JabRef, jEdit,

muCommander

• Change Request 対応のコミットで変更されたメソッドを特定できるか実験• １つの CR に対応する「正解」メソッド数は，中央値で 5 個，第 3四分位点で 12

個

• IRCR のみと，他の手法との組み合わせを評価• 上位 40件抽出で Precision 4-7%, Recall 18-75%

• Feature Location での類似の実験に比べるとかなり悪い• 「正解」メソッド数が小さいので， Precision は悪くなりがち

• DynCR が recall/precision 両方を向上させる• Histseed は recall のみ統計的に有意に向上（ ArgoUML では precision もかなり向

上）

• 論文で不明瞭な点： Histseed における「正解１つ」の選び方が不明• 途中の具体例だけからみると， IRCR のランキングとは無関係の様子• 「正解を指定する」こと自体の recall/precision への影響が不明瞭

18

DETECTING AND VISUALIZING INTER-WORKSHEET SMELLS IN SPREADSHEETS

19

論文 K4

Felienne Hermans, Martin Pinzger and Arie van Deursen

論文の概要• 業務に使う表計算のスプレッドシートから，まずい設計

（ Smells ）を見つける• 数式によるデータの参照を，ソースコードの依存関係に見立てて，

Code Smells の定義を持ち込んだ• Smells の条件をメトリクスで定義した• ICSE2011 で提案したデータフロー可視化手法に， Smells の情報

を追加して提供するツールを構築した• ケーススタディによって， Smells の指摘が利用者に有用

であることを示した

20

用語• スプレッドシート

• 表計算ソフトで保存されるファイル単位．複数のワークシートを含む．

• ワークシート• 行・列に並んだセルによって構成されるシート．

• セル• 「数式」を使って他のセルの値から数値を計算することができる．

• Connection• セルの組 (A, B) で表現．セル A が， B の内容を参照する式を持

つことを意味する．• 主にこれを使ってメトリクスを定義．

21

定義した Smells• Inappropriate Intimacy

• スプレッドシート内部で，ワークシート間の Connection が多いようなワークシートの組がある．

• Feature Envy• ある１つのセルが，他のワークシートの多数のセルを参照してい

る．• Middle Man

• ワークシート内で，セルの値を “ =” によって中継している経路が多い．

• Shotgun Surgery• Formulas: 1 つのワークシートの内容が，他のワークシートの多数

のセルに参照されている．• Worksheets: 1 つのワークシートの内容が，多数のワークシートに

参照されている．

22

メトリクスによる Smells の検出• 各 Smells は，問題となる参照関係などが「多い」ことが条件• カウント条件をそれぞれ定義し，メトリクス値でソートしたときの上位

10 ～ 30% を Smells 検出の閾値とする

• メトリクスはセル単位，ワークシート単位で定義．検出結果はスプレッドシート単位で集計．

• Euses corpus からの検出結果 ( 上位 10% の場合 )• Feature Envy (5.8%)

• Inappropriate Intimacy (4.2%)

• Middle Man (4.0%)

• Shotgun Surgery (1.5%)

23

ケーススタディ• 方法

• 資産管理会社のアナリストが使っているプレッドシート10 個

• うち 7 個から検出された Smells を利用者に確認してもらった

• 結果：• ワークシート間の参照関係が複雑である (Feature Envy

などが多い ) のは，作成した人にメンタルモデルがないから• ワークシート間の関係が整理されていない• あとから見て「なぜこうしたのか」思い出せない・記録していない

• Smells には対応を行ったほうがよいという回答が得られた• Smells の自動検出が，きちんと問題点を指摘している• Feature Envy だけは，「データ保存用シート」「計算用シート」という

２つの役割になっている場合があった

24

Documents

Analysis for Evolution