Upload
illana-combs
View
32
Download
0
Embed Size (px)
DESCRIPTION
セッション K. Analysis for Evolution. 阪大 井上研 神田 哲也・石尾 隆. 論文 K1. A utomated Analysis of CSS Rules to Support Style Maintenance. Ali Mesbah and Shabnam Mirshokraie. 概要. Cascading Style Sheets(CSS) 中の不要な記述を特定する 不要な 記述: CSS 適用先のドキュメントに記述に対応する要素がない、 対応する要素はあるが他の記述が優先される 不要 な記述の問題点: - PowerPoint PPT Presentation
Citation preview
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 のウェブベースシステム
• 2つはオープンソース• 7つは Yahoo! のランダムリンクから• さらに6つのウェブサイトを追加• 正解集合は 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 年以上開発が続いているもの• 調査方法
• 関数のコールグラフ,モジュール間の参照グラフを使って3つの調査• 開発者間の関係グラフ 2 種を使って1つの調査• 調査ごとに,使用したグラフ・メトリクス・システムは異なることに注意• グラフに関するメトリクスを多数のバージョンについて調査したことが新
規性
8
論文で報告されている内容• グラフに関するメトリクスの用途を4つ示した
• 関数のコールグラフに関するメトリクスは,ソフトウェアが違っても似たような値の変動をする (4 章 )
• メトリクスの突然の変化は,システム構造の大きな変化に対応する
• 関数・モジュールは,多くの関数・モジュールから参照されているものほど,そこで発生したバグの Severity が高い (5 章 )
• モジュール性を表現する ModularityRatio メトリクスが高いほど,そのモジュールの Maintenance Effort は小さい (6 章 )
• 開発者間でのバグ対応の協力関係グラフ(1年単位)が変化するほど,そのシステムはバグが多い (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• グラフの任意の2頂点間での最短経路長の最大値
• Assortativity• 各辺が接続している2頂点が同じぐらいの次数を持っているかどうかを判定す
る値• 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)
• バージョン管理システムに履歴が存在しており,かつ,1つのメソッドが「正解」と判明している場合( IRCRHistseed )1. 編集内容が同時にコミットされているメソッドを Itemset Mining で探索
2. あるメソッドが編集されたら他のメソッドも編集されている,という Association Rules へと変換
3. 開発者がどうにかして( Feature Location などで)選んだ「正解」メソッドを基点に,適用可能な Association Rules の強い順にメソッドをランキング
• 同時に変更される可能性が高いものほど上位4. IRCR のランキング上位 N/2 件と Histseed の上位 N/2 件を足して N 個
のランキングを作る• N 個に達するまで,2つのランキングから交互に追加候補を取り込む
• 3種の組み合わせ IRCRDynCRHistseed
• IRCRHistseed の最後のステップで使うランキングを IRCR から IRCRDynCR
に変更
17
評価実験• 4つの Java システムを対象 : ArgoUML, JabRef, jEdit,
muCommander
• Change Request 対応のコミットで変更されたメソッドを特定できるか実験• 1つの CR に対応する「正解」メソッド数は,中央値で 5 個,第 3四分位点で 12
個
• IRCR のみと,他の手法との組み合わせを評価• 上位 40件抽出で Precision 4-7%, Recall 18-75%
• Feature Location での類似の実験に比べるとかなり悪い• 「正解」メソッド数が小さいので, Precision は悪くなりがち
• DynCR が recall/precision 両方を向上させる• Histseed は recall のみ統計的に有意に向上( ArgoUML では precision もかなり向
上)
• 論文で不明瞭な点: Histseed における「正解1つ」の選び方が不明• 途中の具体例だけからみると, 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• ある1つのセルが,他のワークシートの多数のセルを参照してい
る.• 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 だけは,「データ保存用シート」「計算用シート」という
2つの役割になっている場合があった
24